LO1 Evaluate the strengths and weaknesses of the traditional and agile

systems analysis methodologies.

1.1Briefly explain the Principles of traditional Systems Development Life

Cycle (SDLC) like Waterfall, Prototyping, and Spiral and agile methodologies
like Scrum, Extreme, Lean, Scaled Agile Frameworks (Safe), Disciplined Agile
Delivery (DAD), Kanban. Disciplined Agile Delivery (DAD), Agile Modeling
(AM) models and also describe Strengths and weaknesses of traditional
models and agile methodologies

Agile methods are diverse, but they all rely upon the basic principles put forward by the
prominent software developers in 2001.

They are the following:

 Individuals and interactions over processes and tools

 Working software over comprehensive documentation
 Customer collaboration over contract negotiation
 Responding to change over following a plan

Agile methods are based upon rapid development cycles which end with incremental delivery of
software pieces and constant interaction with the customer. Each new cycle of software
development relies upon the results of the previous cycle, with the consideration of customer’s
feedback and requests as to functionality and a common vision of the project. Due to the constant
cooperation with the customer and continuous delivery of the software pieces, the development
project becomes very flexible and responsive to change.

Agile methods are considered as a panacea by many software project developers. However, like
any other development methodology, the Agile methodology has its strengths and weaknesses. It
works well with some types of projects and fails with others. Here we will try to outline the main
advantages and disadvantages of Agile methods for you to decide if they are suitable for your
own project.

Agile model strengths

 High flexibility of the project. Short cycles and constant iterations allow you to adapt
your project frequently and tailor it to the customer’s needs at any moment. You don’t
have to waste your time and resources on delivering a full project which will be rejected
by the customer. This makes the development process extremely flexible.
 High customer satisfaction over the development process. Since Agile projects are
closely coordinated with the customer, he/she has a strong impact on the development
project. Software pieces are delivered constantly, in short cycles and customer’s feedback
is always taken into consideration.
 Constant interaction among the stakeholders. With your teams constantly interacting
with each other and with the customer, you avoid producing tons of technical
documentation, processes, and tools. Each member feels like an important part of the
team participating in the decision-making process. This stimulates creativity and
initiative and leads to better results.
 Continuous quality assurance, attention to details. Quality of the product should be
ensured by the testing team from the early stages of agile development. Since the
development is conducted in short cycles, testing is run non-stop, allowing you to
produce a good final product.

Agile model weaknesses

  Problems with workflow coordination. Agile projects involve several small teams
working on their own software pieces. They should always coordinate their work with
each other, testers and management. Add to that constant interaction with the customer,
and you will get a ton of communication management to consider before starting the
project. Even though a lot of interaction is considered an advantage of Agile
methodology, it may become a weak point due to many factors.
 Difficult planning at early stages. Planning in Agile development is essential before the
process is started. It is important to assess your resources, build up teams, and
communicate an overall vision of the project to them before it is kicked off.
 Professional teams are vital. Agile projects require teams to make serious decisions
constantly. It means that only experienced software developers, testers, and managers
should be working on the project. This software development methodology provides a
very few places for rookies.
 Lack of long-term planning. A lack of final vision of the project may be disorganizing
in some cases. Your project may end up off track if the customer changes his mind too
often during the process. And remember, by the end of the project you will have to
assemble all those software pieces, which had been changed and adapted a few times
over the development cycle and make them work. Also, there will be weak
documentation, since the interactions with the customer were mostly verbal.

As you can see, Agile includes enough pluses and minuses. Therefore, it is very important for
project managers and their teams to identify and select the right and appropriate project
management tool for strategic goals and issues.

1.2 Evaluate different system development life cycle models and suggest the
most suitable SDLC model that can be applied for the given case study
provided the results of your systems investigation. Identify the problems in
given scenario and give reasons for moving from traditional to agile
methodology.

Strengths and weaknesses of the traditional systems development life

Strengths

. SDLC possesses a number of strengths that sometimes makes it relevant to the modern
information systems environment:

 The SDLC is a tried and tested approach that is very suitable for the development of
large-scale information systems
  .The traditional SDLC relies on the production of systems documentation and
s t a nd a rds o f d ev el o pm e nt t h at ca n b e u se d t o gui d e t h e de v el o pm ent o f
an information system and can be used as reference and training material for users.
 Th e se qu en t i al a nd ph as e d na t u r e of t h e S D LC al l o ws a com pl ex
s ys t em s development problem to be broken down into manageable and
understandable tasks.
 T h e S D L C r e l i e s o n t h e u s e o f f o r m a l i z e d a n a l ys i s a n d d e s i g n t o o l s
a n d techniques that graphically show the nature of data and information flows within
the system.
 The structured nature of the traditional SDLC allows the incorporation of formal
project management techniques and tools to guide the systems development
process.

Weaknesses

The main weaknesses with the traditional systems development life cycle are as
follows:
 (i)The SDLC ignores or underplays end-user involvement in the systems development
process. The end user is often faced with operating an information system that
issuer-unfriendly or fails to deliver the user’s requirements for the system.
 (ii)Over 90 per cent of IT-based systems development occurs within the
business environment. The use of computing and information technology
within business organizations is based on small desktop machines or personal
computers, usually networked locally (in a local area network within the organization)
or connected to the wider business environment (through a wide area network).
 (iii)The traditional SDLC is time consuming and costly in terms of human resourcing
and monetary expenditure. The modern day business requirement is for systems to be
developed as quickly as is practicable and within certain budgetary constraints.
 (iv)The development methodology is often too rigid, sequential and inflexible
to change. Time and cost savings can be achieved by developing stages of the
lifecycle in parallel or out of sequence.
 (v)The SDLC approach is often a slow and laborious process. This is a problem when
there is a need for information systems to be developed as quickly as possible
to meet the requirements of dynamic business environments.
 (vi)The SDLC assumes a sequential, step by step approach to development
that ignores the possibility of testing the proposed system at an early stage of the
lifecycle following the discovery of new user requirements
.Thes e failings of the traditi onal approach to s ystems devel opment have l ed to
the evolution of alternative development approaches with the aims of; reducing development
time and cost of s ystems developm ent; Im provi ng the deliver y of s yst em and
user requirements; Recognizing advances in computing and information technology,
and, Recognizing the nature of systems within modern business environments.

LO2 Produce a feasibility study for a system for a business-related problem

Business feasibility reports are analyses of a proposed venture or project that looks into the following
areas:
 A description of the idea or project
 Analysis of the market for the products or services
 Competition
 Technical issues involved
 How the organization will be structured
 Financial projections
What Is the Proposal?
A feasibility study starts with a description of the products or services to be marketed, and it
outlines a model of how the business intends to make a profit. It describes the types and quality
of products that will be offered and a timeline for preparation, implementation and the time it
will take to reach profitable production volumes.
A description of the project also includes its social, economic and environmental impact on
surrounding communities.

What Is the Market?

The market portion of the feasibility study identifies the target market segments and describes
the scope and size of the overall industry. It includes estimates of the future direction and
strength of the demand for the products and services. What are the demographics of the potential
consumers? How will the goods get distributed to the market?
Is the market stable or are future changes expected that will offer opportunities for the new
venture?

What About the Competition?

Is the competition concentrated in a few large manufacturers or spread among numerous small
producers? Who are the major competitors, and how will the new venture compete against them?
What are the barriers to entry into the market?
Your business reports should outline a pricing strategy designed to attract customers from
competitors and grow the sales of the company.

What Are the Technical Considerations?

The study will identify the type, size and location of any production facilities. It will outline the
necessary buildings, equipment, distribution areas and inventory requirements and storage.
Discuss any technologies that will be employed.
Describe the needed access to raw materials and labor. Who will be the potential suppliers and
where are they located? What is the availability of the necessary skills in the local labor market?
A section of the feasibility study should discuss the environmental impact of the project and any
potential regulatory issues or emissions problems.

How Will the Venture be Organized?

For any new project to achieve success, it must have an organizational structure designed to
manage and control its operations, marketing and sales. What are the positions that will be
required, and are there people available with the necessary skills to fill these positions?

What Are the Financial Projections?

Any new proposed ideas or ventures usually have an objective of somehow making a profit.
Projections of future sales, expenses, profits and cash flow are intended to impart some
understanding of the possible results of the project.
Financial considerations would describe the initial capital requirements, working capital needs
and availability of supplier credit. They would also discuss possible alternative sources of funds,
such as bank loans or venture capital partners.

A Business Feasibility Report Versus a Business Plan

A business feasibility report is not a business plan. A feasibility study is an investigative process
that seeks to determine the viability of a business venture. It is conducted before a business plan
is even considered.
A business plan describes the steps needed to take a proposal from an idea to the reality of
implementation after the decision has been made to go ahead with the project.

2.1Critically evaluate the solution that you propose to Suzuki based on

different feasibility criteria and develop a feasibility report.
A feasibility study is simply an assessment of the practicality of a proposed plan or project. As
the name implies, these studies ask: Is this project feasible? Do we have the people, tools,
technology, and resources necessary for this project to succeed? Will the project get us the return
on investment (ROI) that we need and expect?

The goals of feasibility studies are as follows:

  To understand thoroughly all aspects of a project, concept, or plan
 To become aware of any potential problems that could occur while implementing the
project
 To determine if, after considering all significant factors, the project is viable—that is,
worth undertaking

Example of a Feasibility Study

Suzuki motors had long desired to expand its campus. It kept putting off the project, however,
because the administration had certain reservations, including whether it could afford to expand.
The Suzuki also worried about public opinion of the neighborhood—the original home of this
suzuki for more than 100 years. As in the past, the community board had rejected similar types
of development proposals. Finally, the college wondered if specific legal and political issues
might impinge upon its plan.

All of these concerns and unknowns are apt reasons to proceed with a feasibility study, which the
college finally did undertake. As a result, the suzuki now is forging ahead with its expansion
plans without needing to leave its historic home. If it had not taken the time and effort to conduct
a feasibility study, the college would never have known whether its dreamed-of expansion could
become a viable reality.

2.2 According to given scenario briefly explain vision and goals cost-benefit
analysis, legal, economic, technical, operational, timeframes, organizational
culture security considerations.

Pak Suzuki is built on the idea of a responsible corporate citizenship thereby managing quality,
environmental, safety & occupational health matters as an integral part of our business. In
fulfilling this responsibility Pak Suzuki adheres to the following fundamental principles:

 We are committed to provide top quality products at competitive price to the satisfaction
and requirement of our customers.

 We conduct our operations in compliance with applicable environmental, occupational

health & safety laws and regulations. Even where existing laws & regulations are not
adequate we undertake to operate in a responsible manner by assuring the HS&E
integrity of our processes and facilities.

 We recognize the interrelationship between energy and the environment, and we promote
the efficient use of energy throughout our system.
  We ensure safe disposal of waste generated from our facility and will minimize the
discharge of waste materials into the environment by utilizing responsible pollution
control practices.

 We will continuously seek opportunities to improve our adherence to these principles.

Pak Suzuki, acting as a responsible corporate organization; is committed to well being of the
society through its contribution in the field of education, health, promoting environmental
care in particular and to improve quality of life of underprivileged people as a whole.

Policy

Pak Suzuki is committed to act responsibly, create value for it’s Stakeholders and to
contribute to economic development of Pakistan. Whilst enhancing the quality of life of our
employees, we also believe in positively contributing to local communities and society at
large.

Pak Suzuki believes that environment has a major impact on quality of life of people & is
directly related to health of the community. To achieve this, Pak Suzuki has Environment
Program in place throughout the company.

Plantation at PCSIR and PSTC - 2018

Plantation not only enhances the beauty of environment but it also plays a positive role in
development of Healthy Environment as it is a natural source of improving our environment;
keeping in view this, plantation activity (under CSR Program) has been executed at Pakistan
Council of Scientific & Industrial Research (PSCIR) and Pak Swiss Training Centre (PSTC) on
Friday 7th December, 2018. The Plantation project consist of planting 300 saplings (including
Mango & Sapodilla (chickoo) along with Neem) at several locations. During a visit, Mr. Ghulam
Farooq, Executive Officer –Supply Chain formally inaugurated the Plantation project under CSR
by planting a sapling. In Plantation activity, Pak Suzuki, PCSIR and PSTC Officials participated
along with students. PCSIR and PSTC management paid thanks to Pak Suzuki management for
their continuous support for the betterment of Education and Environment of local community.

Pak Suzuki firmly believes that our youth is future of Pakistan, for which Academic and
Technical education is essential. To support this obligation, Pak Suzuki is providing Training
and Equipment to Technical Schools and Rebuilding/ Renovation of Schools in under privilege
areas.

HSE & CLP Awareness Sessions at AOP - 2019

Under CSR program, Health, Safety & Environment (HSE) Awareness Session & Computer
Literacy Program was conducted on 27th September, 2019 for the children (son/daughter/brother
& sister) of Area Office Rawalpindi Officers. Total 18 children participated in these sessions. In
Computer Literacy session, Training regarding the Basic Computer Usage, MS-Office, etc. was
given them by CP Team, while in HSE Session, trainer enlightened on Health related issues,
importance of knowing safety issues and related precautions, tips to stay healthy, safe & secure
during day to day activities, including environment protection. In the end, participants were
awarded with gifts.

LO3 Analyse their system using a suitable methodology.

Your Evaluation Plan will specify how you will collect and analyse data. It is useful to plan your data
collection and analysis around a few Key Evaluation Questions. These are high level questions that the
evaluation is intended to answer (for example, "How effective was the program?").

You will need different types of options for different types of evaluation questions:

Type of question Example Where to find options for answering this type of question
 Was the policy
implemented as planned?
Descriptive
Did school attendance
What has rates increase after the
happened? government abolished
tuition fees at
government schools?

Causal

Did the policy change

What caused
contribute to increases in
these things to
school attendance rates?
happen?

Evaluative

Taking into account the

What is the
negative impacts of the
overall quality of
policy, was the policy
what is being
overall a success?
evaluated?

Action

What should we
do?

Compare the pros and cons of different options for each evaluation question

For each evaluation task you will find a range of options, each with their own advantages and
disadvantages.
 For example, when gathering data to answer descriptive questions:

An email questionnaire can gather data quickly – but response rates are often low, and it will not
include those without technological access.

A pen and paper questionnaire needs less technical support – but can be harder to distribute and
collect and take longer to analyse.

On each option page, you will find advice about when it might be appropriate to choose that
option, taking into account available time, expertise and other issues.

3.1 Identifying user and system requirements and any constraints, including
possible security issues. How to overcome the constraints and security issue.

User requirements, often referred to as user needs, describe what the user does with the system,
such as what activities that users must be able to perform. User requirements are generally
documented in a User Requirements Document (URD) using narrative text. User requirements are
generally signed off by the user and used as the primary input for creating system requirements.
An important and difficult step of designing a software product is determining what the user actually
wants it to do. This is because the user is often not able to communicate the entirety of their needs
and wants, and the information they provide may also be incomplete, inaccurate and self-conflicting.
The responsibility of completely understanding what the customer wants falls on the business
analyst. This is why user requirements are generally considered separately from system requirements.
The business analyst carefully analyzes user requirements and carefully constructs and documents a
set of high quality system requirements ensuring that that the requirements meet certain quality
characteristics.
System requirements are the building blocks developers use to build the system. These are the
traditional “shall” statements that describe what the system “shall do.” System requirements are
classified as either functional or supplemental requirements. A functional requirement specifies
something that a user needs to perform their work. For example, a system may be required to enter
and print cost estimates; this is a functional requirement. Supplemental or non-functional
requirements specify all the remaining requirements not covered by the functional requirements. I
prefer to use the term supplemental requirements instead of non-functional requirements; who wants
to be termed nonfunctional? Supplemental requirements are sometimes called quality of service
requirements. The plan for implementing functional requirements is detailed in the system design.
The plan for implementing supplemental requirements is detailed in the system architecture. The list
below shows various types of supplemental requirements.
 Accessibility
 Accuracy
 Audit, control, and reporting
 Availability
 Backup and restore
 Capacity, current and forecast
 Certification
 Compliance
 Compatibility of software, tools, standards, platform, database, and the like
 Concurrency
 Configuration management
 Dependency on other parties
 Deployment
 Documentation

Digital warfare and worldwide cyberattack rates are on the rise, and protection on corporate
networks is even more crucial.

Databases are a key target for cybercriminals due to the often valuable nature of sensitive
information locked away inside. Whether the data is financial or holds intellectual property and
corporate secrets, hackers worldwide can profit from breaching a businesses' servers and
plundering databases.
According to a new report issued by Dark Reading, there are a number of key security failures
that cybercriminals take advantage of. However, it is often the staff of an enterprise — database
developers, administrators and the like — who create the environment necessary for attacks to
gain access to data.
The researchers say that the top ten vulnerabilities often found in database-driven
systems,whether during the creation phase, through the integration of applications or when
updating and patching, are:

1. Deployment Failures
The most common cause of database vulnerabilities is a lack of due care at the moment they
are deployed. Although any given database is tested for functionality and to make sure it is
doing what the databases is designed to do, very few checks are made to check the database
is not doing things it should not be doing.

2. Broken databases
The SQL Slammer worm of 2003 was able to infect more than 90 percent of vulnerable
computers within 10 minutes of deployment, taking down thousands of databases in minutes.
This worm took advantage of a bug that was discovered in Microsoft's SQL Server database
software the previous year, but few system administrators installed a fix, leaving computers
vulnerable.
By exploiting a buffer-overflow vulnerability, the worm's success demonstrates how critical
installing security patches and fixes are. However, whether lacking time or resources, not
enough businesses keep their systems regularly patched, leaving databases vulnerable.

3. Data leaks
Databases may be considered a "back end" part of the office and secure from Internet-based
threats (and so data doesn't have to be encrypted), but this is not the case. Databases also
contain a networking interface, and so hackers are able to capture this type of traffic to
exploit it. To avoid such a pitfall, administrators should use SSL- or TLS-encrypted
communication platforms.

4. Stolen database backups

External attackers who infiltrate systems to steal data are one threat, but what about those
inside the corporation? The report suggests that insiders are also likely to steal archives —
including database backups — whether for money, profit or revenge. This is a common
problem for the modern enterprise, and businesses should consider encrypting archives to
mitigate the insider-risk.

5. The abuse of database features

The research team says that over the past three years, every database exploit they've seen has
been based on the misuse of a standard database feature. For example, a hacker can gain
access through legitimate credentials before forcing the service to run arbitrary code.
Although complex, in many cases, this access was gained through simple flaws that allow
such systems to be taken advantage of or bypassed completely. Future abuse can be limited
by removing unnecessary tools — not by destroying the possibility of zero-day exploits, but
by at least shrinking the surface area hackers can study to launch an attack.

6. A lack of segregation
The separation of administrator and user powers, as well as the segregation of duties, can
make it more difficult for fraud or theft undertaken by internal staff. In addition, limiting the
power of user accounts may give a hacker a harder time in taking complete control of a
database.

7. Hopscotch
Rather than taking advantage of buffer overflow and gaining complete access to a database in
the first stage, cybercriminals often play a game of Hopscotch: finding a weakness within the
infrastructure that can be used as leverage for more serious attacks until they reach the back-
end database system. For example, a hacker may worm their way through your accounts
department before hitting the credit card processing arena. Unless every department has the
same standard of control, creating separate administrator accounts and segregating systems
can help mitigate the risk.

8. SQL injections
A popular method for hackers to take, SQL injections remain a critical problem in the
protection of enterprise databases. Applications are attacked by injections, and the database
administrator is left to clean up the mess caused by unclean variables and malicious code
which is inserted into strings, later passed to an instance of SQL server for parsing and
execution. The best ways to protect against these threats are to protect web-facing databases
with firewalls and to test input variables for SQL injection during development.

9. Sub-standard key management

Key management systems are meant to keep keys safe, but the research team often found
encryption keys stored on company disk drives. Database administrators sometimes falsely
believe these keys have to be left on the disk because of database failures, but this isn't true
— and placing such keys in an unprotected state can leave systems vulnerable to attack.

10. Database inconsistencies

 Finally, the researchers found that the common thread which brings all of these
vulnerabilities together is a lack of consistency, which is an administrative rather than
database technology problem. System administrators and database developers need to
develop a consistent practice in looking after their databases, staying aware of threats and
making sure that vulnerabilities are taken care of. This isn't an easy task, but documentation
and automation to track and make changes can ensure that the information contained in
enterprise networks is kept secure.

3.2Identifying the team members and their roles and responsibilities in a

project team. And then assign the suitable task for appropriate member and
also identify documentation that will be produced at the different stages.

The project team includes the project manager and the group of individuals who work together
on a project to achieve its objectives. It consists of the project manager, project management
staff, and other team members who are maybe not directly involved with management but carry
out the work related to the project. This team consists of people from different teams with
precise subject matter knowledge or with the required skill set to carry out the work of the
project. The structure and characteristics of a project team usually vary, but the project
manager’s role as the leader of the team remains constant. However, the amount and nature of
authority the project manager has over the members can differ.

Project Team Roles:

Project teams include roles such as:

Project Manager

The project manager plays the chief part in the project and is responsible for its success and
quality. His job is to make sure that the project proceeds and completes within the specified time
frame and the ascertained budget, and accomplishing its goals at the same time. Project managers
ensure that resources are sufficient for the project and maintain relationships with contributors
and stakeholders.

A project manager is entrusted with various duties and responsibilities like:

 Developing a project plan

 Managing deliverables according to the decided plan

 Leading and managing the project team

 Deciding the methodology used in the project

 Establishing a project schedule and determining each phase

 Assigning tasks to project team members

 Providing regular updates to upper management

Project Team Member

Project team members are mainly the people who work on various phases of the project. They
could be in-house staff or external consultants and may be working on a full-time or part-time
basis. Their roles can differ according to each project.

Project team member duties can be summed up as the following:

 Contribute to overall project objectives

 Complete individual deliverables

 Provide expertise
 Work with users to determine and meet business needs

 Document the process

Project Sponsor

The project sponsor is the driver and in-house champion of the project. He has a vested interest
in the successful outcome of the project. They are typically members of senior management –
those with a stake in the project’s outcome. Project sponsors work closely with the project
manager. They legitimize the project’s objectives and participate in high-level project planning.
Also, they often help resolve conflicts and remove obstacles that occur throughout the project,
and they sign off on approvals needed to advance each phase.

Project sponsor duties:

 Make key business decisions for the project

 Approve the project budget

 Ensure availability of resources

 Communicate the project’s goals throughout the organization

 Business Analyst

The business analyst recognizes requirements of the organization and suggests solutions to the
problems. In a project team, they make sure that the current project’s objectives can solve
existing problems and add value to the organization. They can also help make the most of project
deliverables.

A business analyst is entrusted with:

 Helping in defining the project

 Collecting requirements from business units or users

 Documenting technical and business requirements

 Ensuring that project deliverables meet the requirements

 Testing solutions to validate objectives

Composition of Project Teams

Project team’s compositions may differ based on organization’s culture, scope, and location.

Some examples of basic project team compositions are given below:

Dedicated: This is the simplest structure for a project manager. In this composition, all or most
of the project team members are appointed to work full-time on the project. The project team has
to report directly to the project manager, and the lines of authority are well-defined so team
members can concentrate on the project’s objectives. Dedicated project teams are usually seen in
projectized organizations, where most of the resources of the organization are involved in project
work, and project managers have independence and power.

Part-Time: Some projects are assigned to a team as an additional temporary work, with the rest
of the organization’s members carrying out their regular functions. The functional managers
have the control over the team members and the resources assigned to the project, while the
project manager continues with other management duties. Part-time team members could also be
assigned to more than one project at one time. Part-time project teams are mostly seen within
functional organizations. Matrix organizations use both dedicated and part-time project teams.

Some compositions vary based on organizational structure, like a partnership-based project

where one lead organization appoints a project manager to coordinate the efforts of the partners.
Some vary based on the geographic location of its members, like virtual project teams. Virtual
teams are usually needed for projects where resources are situated onsite or offsite or both,
depending on the project activities.

The success of a project cannot be accredited to a single person. It is the contribution of every
member of the team and people associated with the project from outside. It is imperative to keep
an account of how many people are related to your project and which role should be assigned to
each one of them. A proper training and thorough knowledge of the subject can guide you with
the same.

Most individuals focus on the technical knowledge of the employee and neglect the interpersonal
and managerial skills, which is a big mistake. The latter is as important as the former because
working with an exceptional programmer who is inflexible and not willing to cooperate could be
a problem.

Learning about the specifics of the composition and contributions of a project team members
would give you an insight of what’s important and what’s not. It would also help you make the
most of the existing talent and take steps to minimize flaws present in your group.

LO4 Design the system to meet user and system requirements

4.1Design elements that could be used to design the traditional and agile
methodologies and make the Data flow diagrams and flow charts related to
the solution you provide according to the scenario.

Traditional Software Development Methodology

Traditional software development methodologies are based on pre-organized phases/stages of the

software development lifecycle. Here the flow of development is unidirectional, from
requirements to design and then to development, then to testing and maintenance. In classical
approaches like the Waterfall model, each phase has specific deliverables and detailed
documentation that have undergone a thorough review process.

Traditional approaches are suited when requirements are well understood – for example, in
industries like construction, where everyone clearly understands the final product. On the other
hand, in rapidly changing industries like IT, traditional development procedures might fail to
achieve project goals. Below are the major disadvantages of traditional SDLC methods.

 Problem statement / business need has to be defined well in advance. The solution also
needs to be determined in advance and cannot be changed or modified.
 The entire set of requirements have to be given in the initial phase without any chance of
changing or modifying them after the project development has started.

Traditional development methodologies are suitable only when the requirements are precise i.e.,
when the customer knows exactly what they want and can confidently say that there won’t be
any major changes in scope throughout the project development. It is not suitable for large
projects such as maintenance projects where requirements are moderate and there is a great scope
for continuous modification.

Agile Software Development Methodology

Unlike the traditional approaches of SDLC, Agile approaches are precise and customer friendly.
Users/Customers have the opportunity to make modifications throughout project development
phases. The advantages of Agile over traditional development methodologies include:

 Though the problem statement/business need and solution are defined in advance, they
can be modified at any time.
 Requirements/User Stories can be provided periodically implying better chances for
mutual understanding among developer and user.
 The solution can be determined by segregating the project into different modules and can
be delivered periodically.
 The user gets an opportunity to evaluate solution modules to determine whether the
business need is being met thus ensuring quality outcomes.
 It is possible to create re-usable components.
 There is less priority on documentation which results in less time consumption and
expenditure.

Agile proposes an incremental and iterative approach to development. Consider Agile Scrum
Methodology to get good understanding of how Agile processes work. Scrum Master plays an
important role in Agile Scrum Methodology. A Scrum Master interacts daily with the
development team as well as the product owner to make sure that the product development is in
sync with the customer’s expectations. The following diagram illustrates the lifecycle process in
Agile methodologies.

The main difference between traditional and agile approaches is the sequence of project phases –
requirements gathering, planning, design, development, testing and UAT. In traditional development
methodologies, the sequence of the phases in which the project is developed is linear where as in Agile, it
is iterative. Below picture illustrate this difference.

The main project variables like cost, time, quality etc., can be compared as shown in the following
picture.
Key points while making the transition from Traditional to Agile methodologies:

 Identify the factors which made the transition necessary

 Everyone, including the user, should be clear about the reasons which lead to the
transition
 Identify whether it is a small project or big project
 Note the current stage of the project to be transitioned, whether development has started
or is yet to start
 Make sure the team has a good understanding of the new approach and have adapted to
their respective roles as per the new approach

4.2 Determining the tools and techniques relevant for the design of systems
fordatabase applications, web applications and other software applications
The Structure Chart is a basic tool of Structured System Design. It is a graphic representation of
a hierarchy of modules and the relationships between them. In Section 2 two types of Structure
Charts were discussed; they were referred to as Structure Charts and Program Structure Charts.
The first type represents the detailed functional breakdown of the software without taking
packaging into account. The second type illustrates the actual programs and procedures to be
developed.

A Structure Chart represents system structure. It can also be used to illustrate

flow of information between modules. It does not illustrate flow of control; it does
not provide any information about sequencing of events or about condition tests.
The figure above provides an example of a Program Structure Chart. It illustrates the different
symbols which can be used. A box represents a module; lines connecting the modules represent
the calling hierarchy. Loops, conditional calls and parameters can also be illustrated on the
Structure Charts using the symbols shown. Illustrated parameter passing can become messy and
cumbersome; it may be preferable to describe the parameter passing in the Project
Encyclopaedia.

Data Flow Oriented Design

Data flow oriented decomposition is a method of deriving the modular design based on the data
flow diagram. It is the recommended method for processing oriented applications such as
Accounting, Payroll and Inventory.
The procedure is as follows.
1. Define the top level module.

2. Identify the major input streams, output streams, and the processing center. The processing
center can often be identified by parallelism of data flow (see Figure below where transactions
A, B, C are processed in parallel).

3. Define a module for each input or output stream and the processing center. For the processing
center, define a sub-module for each of the processes occurring in parallel.
4. For each of the lowest level modules, take the corresponding portion of the DFD and repeat
Step 2 and 3 until fully decomposed.
5. Refine the design to decrease the coupling and increase the cohesion of the modules. This is
necessary because DFD's do not take into account control flow, trivial data paths or packaging
considerations.

For more information about this technique refer to Structured Systems Analysis: Tools and
Techniques by Gane and Sarson.

Data Structure Oriented Design

Data Structure Oriented Design is a technique of modular decomposition which transforms a
representation of a data structure into a representation of software.
This method can be used for systems with a well defined, hierarchical structure of information,
heavy input/output flow and little processing logic; e.g., a library catalogue system.

Because this approach is not widely used it is not discussed here. The reader may refer to Data
Structured Program Design by Kirk Hansen.

Object-Oriented Design
Object-Oriented Design is an approach to modular decomposition which views a problem in
terms of objects and operations and defines the solution in the same terms. It is applicable to
applications such as simulation systems, real time systems, and to systems with complex or
dynamic entities which are difficult to represent using traditional techniques.

This approach requires a language in which real world objects can be represented. These
languages typically build classes of an object in the application.

For each class, the attributes and properties that each object in the class shares are defined. The
actions which each object can perform are described. These are written in the form of messages
to which each object in the class can respond. As a result, all communication between any two
objects, whether they are from the same class or not, is performed by sending messages. Thus,
object-oriented languages have a very high degree of encapsulation, in that each object is
responsible for its own operation, and no other object may access its structure directly. The net
result is that each message is like a separate black-box, a property which makes system design
more manageable.

New classes are introduced as specializations or generalizations of existing classes. For example,
in a naval simulation system, a class SHIP could be introduced, and the attributes and properties
of a ship defined. Specializations of this class, such as FRIGATE and DESTROYER, could then
be introduced. These two new classes could inherit the properties of the class SHIP, while
defining those properties which makes them unique.

Many object-oriented languages are now becoming available, such as SMALLTALK, LISP
FLAVERS, Objective C, C++, ADA, and SIMULA.

The following is an example of a temperature monitoring system which will be used to illustrate
Object Oriented Design. The system is described as follows:
'There are ten independent sensors which continually monitor temperature. Initially all of the
sensors are disabled. If any of the enabled sensors register an out of limits value the system must
immediately post an alarm condition. It must also record the status of all sensors every fifteen
minutes. Asynchronously it must be able to get a user command to enable or disable a sensor, or
set the temperature limits."

• Identify the objects and their attributes.

• Alarm: Is set for out of limits condition.

• Sensors: Each one
 - is enabled or disabled,
- has upper and lower limits,
- is polled only when enabled.
• Recording Device: The status of the sensors are logged.
• Timer: Supplies an interrupt every 15 minutes.
• User Commands: One of Enable, Disable, or Set Limits.

• Identify the operations applicable to each object.

• Alarm
- Post out of limits condition
• Sensors
- Disable
- Enable
- Set Limits
• Recording Device
- Log the status of sensors
• Timer
- Interrupt

.
4.3 Identifying the design documentation contents for different application
typese.g. for databases, web design and other software applications.

Database Documentation for SQL Server, Oracle and Access

Document! X is a combination of an automated Database Schema
Documentation Tool and a full documentation authoring environment which can be
used to create accurate, professional quality database documentation for SQL Server
Access or other OLEDB databases.

Document! X is not just an automated database documentation build tool - it is also includes a

fully featured documentation authoring environment allowing you to author supplementary

content (descriptions of database elements, hyperlinks to related pages or web sites etc.) where

required.

Why Choose Document! X for Database Documentation?

 Fast, accurate, professional quality database documentation;
 Market leading authoring tools for creating supplementary content;
 Document tables, columns, views, stored procedures, functions, triggers, indexes,
relationships, defaults, checks, roles, users, permissions, file groups,
dependencies;
 Output includes colorized SQL / T-SQL / PL-SQL source code where available;
 Customizable HTML based template driven output can be adapted to your
requirements;
 Generate documentation to HTML Help 1.x (CHM) or web ready pure HTML
including a full Table of Contents, Index and Full Text Search.

Documentation For Web Design

Developing a website is like building a house. When building a house, you ask an architect to
draw up the plans. The architect obtains building permits, city licenses, and more… All before
any actual construction begins. Similarly, Website Definition Documents act as your website’s
architectural blueprint. By using these documents, you and your design agency can build a strong
foundation.

What are Website Definition Documents?

In the web business, the initial planning phase can be referred to as “Definition”, “Scope” or
“Discovery.” During this preliminary planning phase, your website agency will create
documents that define website architecture, and identify key technical and creative requirements.

These documents will help answer questions like:

 What is the overall online strategy?

 How will the business brand be applied to the website?
 What programming framework will be used?
 What are the website features?
 How will marketing be integrated?