Software Life Cycle Models

Waterfall model
Winston Royce introduced the Waterfall Model in 1970.This model has five
phases: Requirements analysis and specification, design, implementation,
and unit testing, integration and system testing, and operation and
maintenance. The steps always follow in this order and do not overlap.
The developer must complete every phase before the next phase begins.
This model is named "Waterfall Model", because its diagrammatic
representation resembles a cascade of waterfalls.

1. Requirements analysis and specification phase: The aim of this

phase is to understand the exact requirements of the customer and to
document them properly. Both the customer and the software developer
work together so as to document all the functions, performance, and
interfacing requirement of the software. It describes the "what" of the
system to be produced and not "how.”In this phase, a large document
called Software Requirement Specification (SRS) document is
created which contained a detailed description of what the system will do
in the common language.

2. Design Phase: This phase aims to transform the requirements

gathered in the SRS into a suitable form which permits further coding in a
programming language. It defines the overall software architecture
together with high level and detailed design. All this work is documented
as a Software Design Document (SDD).

3. Implementation and unit testing: During this phase, design is

implemented. If the SDD is complete, the implementation or coding phase
proceeds smoothly, because all the information needed by software
developers is contained in the SDD.
Play Video

During testing, the code is thoroughly examined and modified. Small

modules are tested in isolation initially. After that these modules are
tested by writing some overhead code to check the interaction between
these modules and the flow of intermediate output.

4. Integration and System Testing: This phase is highly crucial as the

quality of the end product is determined by the effectiveness of the
testing carried out. The better output will lead to satisfied customers,
lower maintenance costs, and accurate results. Unit testing determines
the efficiency of individual modules. However, in this phase, the modules
are tested for their interactions with each other and with the system.

5. Operation and maintenance phase: Maintenance is the task

performed by every user once the software has been delivered to the
customer, installed, and operational.

When to use SDLC Waterfall Model?

Some Circumstances where the use of the Waterfall model is most suited
are:
o When the requirements are constant and not changed regularly.
o A project is short
o The situation is calm
o Where the tools and technology used is consistent and is not changing
o When resources are well prepared and are available to use.

Advantages of Waterfall model

o This model is simple to implement also the number of resources that are
required for it is minimal.
o The requirements are simple and explicitly declared; they remain
unchanged during the entire project development.
o The start and end points for each phase is fixed, which makes it easy to
cover progress.
o The release date for the complete product, as well as its final cost, can be
determined before development.
 o It gives easy to control and clarity for the customer due to a strict
reporting system.

Disadvantages of Waterfall model

o In this model, the risk factor is higher, so this model is not suitable for
more significant and complex projects.
o This model cannot accept the changes in requirements during
development.
o It becomes tough to go back to the phase. For example, if the application
has now shifted to the coding phase, and there is a change in
requirement, It becomes tough to go back and change it.
o Since the testing done at a later stage, it does not allow identifying the
challenges and risks in the earlier phase, so the risk reduction strategy is
difficult to prepare.

Spiral Model
The spiral model, initially proposed by Boehm, is an evolutionary software
process model that couples the iterative feature of prototyping with the
controlled and systematic aspects of the linear sequential model. It
implements the potential for rapid development of new versions of the
software. Using the spiral model, the software is developed in a series of
incremental releases. During the early iterations, the additional release
may be a paper model or prototype. During later iterations, more and
more complete versions of the engineered system are produced.

The Spiral Model is shown in fig:

Each cycle in the spiral is divided into four parts:

Objective setting: Each cycle in the spiral starts with the identification
of purpose for that cycle, the various alternatives that are possible for
achieving the targets, and the constraints that exists.
Play Video

Risk Assessment and reduction: The next phase in the cycle is to

calculate these various alternatives based on the goals and constraints.
The focus of evaluation in this stage is located on the risk perception for
the project.

Development and validation: The next phase is to develop strategies

that resolve uncertainties and risks. This process may include activities
such as benchmarking, simulation, and prototyping.

Planning: Finally, the next step is planned. The project is reviewed, and a
choice made whether to continue with a further period of the spiral. If it is
determined to keep, plans are drawn up for the next step of the project.

The development phase depends on the remaining risks. For example, if

performance or user-interface risks are treated more essential than the
program development risks, the next phase may be an evolutionary
development that includes developing a more detailed prototype for
solving the risks.
The risk-driven feature of the spiral model allows it to accommodate any
mixture of a specification-oriented, prototype-oriented, simulation-
oriented, or another type of approach. An essential element of the model
is that each period of the spiral is completed by a review that includes all
the products developed during that cycle, including plans for the next
cycle. The spiral model works for development as well as enhancement
projects.

When to use Spiral Model?

o When deliverance is required to be frequent.
o When the project is large
o When requirements are unclear and complex
o When changes may require at any time
o Large and high budget projects

Advantages
o High amount of risk analysis
o Useful for large and mission-critical projects.

Disadvantages
o Can be a costly model to use.
o Risk analysis needed highly particular expertise
o Doesn't work well for smaller projects.

Prototype Model
The prototype model requires that before carrying out the development of
actual software, a working prototype of the system should be built. A
prototype is a toy implementation of the system. A prototype usually turns
out to be a very crude version of the actual system, possible exhibiting
limited functional capabilities, low reliability, and inefficient performance
as compared to actual software. In many instances, the client only has a
general view of what is expected from the software product. In such a
scenario where there is an absence of detailed information regarding the
input to the system, the processing needs, and the output requirement,
the prototyping model may be employed.
Steps of Prototype Model
1. Requirement Gathering and Analyst
2. Quick Decision
3. Build a Prototype
4. Assessment or User Evaluation
5. Prototype Refinement
6. Engineer Product

Advantage of Prototype Model

1. Reduce the risk of incorrect user requirement
2. Good where requirement are changing/uncommitted
 3. Regular visible process aids management
4. Support early product marketing
5. Reduce Maintenance cost.
6. Errors can be detected much earlier as the system is made side by side.

Disadvantage of Prototype Model

1. An unstable/badly implemented prototype often becomes the final
product.
2. Require extensive customer collaboration
o Costs customer money
o Needs committed customer
o Difficult to finish if customer withdraw
o May be too customer specific, no broad market
3. Difficult to know how long the project will last.
4. Easy to fall back into the code and fix without proper requirement
analysis, design, customer evaluation, and feedback.
5. Prototyping tools are expensive.
6. Special tools & techniques are required to build a prototype.
7. It is a time-consuming process.

Agile Model
The meaning of Agile is swift or versatile."Agile process model" refers to
a software development approach based on iterative development. Agile
methods break tasks into smaller iterations, or parts do not directly
involve long term planning. The project scope and requirements are laid
down at the beginning of the development process. Plans regarding the
number of iterations, the duration and the scope of each iteration are
clearly defined in advance.

Each iteration is considered as a short time "frame" in the Agile process

model, which typically lasts from one to four weeks. The division of the
entire project into smaller parts helps to minimize the project risk and to
reduce the overall project delivery time requirements. Each iteration
involves a team working through a full software development life cycle
including planning, requirements analysis, design, coding, and testing
before a working product is demonstrated to the client.
Phases of Agile Model:
Following are the phases in the Agile model are as follows:
1. Requirements gathering
2. Design the requirements
3. Construction/ iteration
4. Testing/ Quality assurance
5. Deployment
6. Feedback

1. Requirements gathering: In this phase, you must define the

requirements. You should explain business opportunities and plan the
time and effort needed to build the project. Based on this information, you
can evaluate technical and economic feasibility.

2. Design the requirements: When you have identified the project,

work with stakeholders to define requirements. You can use the user flow
diagram or the high-level UML diagram to show the work of new features
and show how it will apply to your existing system.

3. Construction/ iteration: When the team defines the requirements,

the work begins. Designers and developers start working on their project,
which aims to deploy a working product. The product will undergo various
stages of improvement, so it includes simple, minimal functionality.

4. Testing: In this phase, the Quality Assurance team examines the

product's performance and looks for the bug.

5. Deployment: In this phase, the team issues a product for the user's
work environment.

6. Feedback: After releasing the product, the last step is feedback. In

this, the team receives feedback about the product and works through the
feedback.

Evolutionary Process Model

Evolutionary process model resembles the iterative enhancement model.
The same phases are defined for the waterfall model occurs here in a
cyclical fashion. This model differs from the iterative enhancement model
in the sense that this does not require a useful product at the end of each
cycle. In evolutionary development, requirements are implemented by
category rather than by priority.

For example, in a simple database application, one cycle might implement

the graphical user Interface (GUI), another file manipulation, another
queries and another updates. All four cycles must complete before there
is a working product available. GUI allows the users to interact with the
system, file manipulation allow the data to be saved and retrieved,
queries allow user to get out of the system, and updates allows users to
put data into the system.

Benefits of Evolutionary Process Model

Use of EVO brings a significant reduction in risk for software projects.

EVO can reduce costs by providing a structured, disciplined avenue for

experimentation.

EVO allows the marketing department access to early deliveries,

facilitating the development of documentation and demonstration.

Better fit the product to user needs and market requirements.

Manage project risk with the definition of early cycle content.

Uncover key issues early and focus attention appropriately.

Increase the opportunity to hit market windows.

Accelerate sales cycles with early customer exposure.

Increase management visibility of project progress.

Increase product team productivity and motivations.

Software Requirement Analysis: Software Requirement Analysis means

requirement that is needed by software to increase quality of software product.
These requirements are generally a type of expectation of user from software
product that is important and need to be fulfilled by software. Analysis means
to examine something in an organized and specific manner to know complete
details about it.
Therefore, Software requirement analysis simply means complete study,
analyzing, describing software requirements so that requirements that are
genuine and needed can be fulfilled to solve problem. There are several
activities involved in analyzing Software requirements. Some of them are
given below :

1. Problem Recognition :
The main aim of requirement analysis is to fully understand main objective
of requirement that includes why it is needed, does it add value to product,
will it be beneficial, does it increase quality of the project, does it will have
any other effect. All these points are fully recognized in problem recognition
so that requirements that are essential can be fulfilled to solve business
problems.

2. Evaluation and Synthesis :

Evaluation means judgement about something whether it is worth or not
and synthesis means to create or form something. Here are some tasks
are given that is important in the evaluation and synthesis of software
requirement :
● To define all functions of software that necessary.
 ● To define all data objects that are present externally and are easily
observable.
● To evaluate that flow of data is worth or not.
● To fully understand overall behavior of system that means overall
working of system.
● To identify and discover constraints that are designed.
● To define and establish character of system interface to fully understand
how system interacts with two or more components or with one another.
3. Modeling :
After complete gathering of information from above tasks, functional and
behavioral models are established after checking function and behavior of
system using a domain model that also known as the conceptual model.

4. Specification :
The software requirement specification (SRS) which means to specify the
requirement whether it is functional or non-functional should be developed.

5. Review :
After developing the SRS, it must be reviewed to check whether it can be
improved or not and must be refined to make it better and increase the
quality.

Requirements elicitation Activities:

Requirements elicitation includes the subsequent activities. Few of them are
listed below –
● Knowledge of the overall area where the systems is applied.
● The details of the precise customer problem where the system are going to
be applied must be understood.
● Interaction of system with external requirements.
● Detailed investigation of user needs.
● Define the constraints for system development.
1. Interviews
2. Brainstorming Sessions
3. Facilitated Application Specification Technique (FAST)
4. Quality Function Deployment (QFD)
5. Use Case Approach
The success of an elicitation technique used depends on the maturity of the
analyst, developers, users, and the customer involved.
1. Interviews:
Objective of conducting an interview is to understand the customer’s
expectations from the software.
It is impossible to interview every stakeholder hence representatives from
groups are selected based on their expertise and credibility.
Interviews maybe be open-ended or structured.
1. In open-ended interviews there is no pre-set agenda. Context free
questions may be asked to understand the problem.
2. In structured interview, agenda of fairly open questions is prepared.
Sometimes a proper questionnaire is designed for the interview.
2. Brainstorming Sessions:
● It is a group technique
● It is intended to generate lots of new ideas hence providing a platform to
share views
● A highly trained facilitator is required to handle group bias and group
conflicts.
● Every idea is documented so that everyone can see it.
● Finally, a document is prepared which consists of the list of requirements
and their priority if possible.
●
3. Facilitated Application Specification Technique:
It’s objective is to bridge the expectation gap – difference between what the
developers think they are supposed to build and what customers think they
are going to get.
A team oriented approach is developed for requirements gathering.
Each attendee is asked to make a list of objects that are-
1. Part of the environment that surrounds the system
2. Produced by the system
3. Used by the system
Each participant prepares his/her list, different lists are then combined,
redundant entries are eliminated, team is divided into smaller sub-teams to
develop mini-specifications and finally a draft of specifications is written down
using all the inputs from the meeting.
4. Quality Function Deployment:
In this technique customer satisfaction is of prime concern, hence it
emphasizes on the requirements which are valuable to the customer.
3 types of requirements are identified –
● Normal requirements –
In this the objective and goals of the proposed software are discussed with
the customer. Example – normal requirements for a result management
system may be entry of marks, calculation of results, etc
● Expected requirements –
These requirements are so obvious that the customer need not explicitly
state them. Example – protection from unauthorized access.
● Exciting requirements –
It includes features that are beyond customer’s expectations and prove to
be very satisfying when present. Example – when unauthorized access is
detected, it should backup and shutdown all processes.
The major steps involved in this procedure are –
1. Identify all the stakeholders, eg. Users, developers, customers etc
2. List out all requirements from customer.
3. A value indicating degree of importance is assigned to each requirement.
4. In the end the final list of requirements is categorized as –
● It is possible to achieve
● It should be deferred and the reason for it
● It is impossible to achieve and should be dropped off

Advantages of Requirements Elicitation:

● Helps to clarify and refine the customer requirements.

● Improves communication and collaboration between stakeholders.
● Increases the chances of developing a software system that meets the
customer needs.
● Avoids misunderstandings and helps to manage expectations.
● Supports the identification of potential risks and problems early in the
development cycle.
● Facilitates the development of a comprehensive and accurate project plan.
● Increases user and stakeholder confidence in the software development
process.
● Supports the identification of new business opportunities and revenue
streams.

Disadvantages of Requirements Elicitation:

● Can be time-consuming and expensive.

● Requires specialized skills and expertise.
● May be impacted by changing business needs and requirements.
● Can be impacted by political and organizational factors.
● Can result in a lack of buy-in and commitment from stakeholders.
● Can be impacted by conflicting priorities and competing interests.
● May result in incomplete or inaccurate requirements if not properly
managed.
● Can lead to increased development costs and decreased efficiency if
requirements are not well-defined.

DFD is the abbreviation for Data Flow Diagram. The flow of data of a system
or a process is represented by DFD. It also gives insight into the inputs and
outputs of each entity and the process itself. DFD does not have control flow
and no loops or decision rules are present. Specific operations depending on
the type of data can be explained by a flowchart.
It is a graphical tool, useful for communicating with users ,managers and other
personnel. it is useful for analyzing existing as well as proposed system.
It provides an overview of
● What data is system processes.
● What transformation are performed.
● What data are stored.
● What results are produced , etc.
Data Flow Diagram can be represented in several ways. The DFD belongs to
structured-analysis modeling tools. Data Flow diagrams are very popular
because they help us to visualize the major steps and data involved in
software-system processes.
Components of DFD
The Data Flow Diagram has 4 components:
● Process Input to output transformation in a system takes place because of
process function. The symbols of a process are rectangular with rounded
corners, oval, rectangle or a circle. The process is named a short
sentence, in one word or a phrase to express its essence
● Data Flow Data flow describes the information transferring between
different parts of the systems. The arrow symbol is the symbol of data flow.
A relatable name should be given to the flow to determine the information
which is being moved. Data flow also represents material along with
information that is being moved. Material shifts are modeled in systems
that are not merely informative. A given flow should only transfer a single
type of information. The direction of flow is represented by the arrow which
can also be bi-directional.
● Warehouse The data is stored in the warehouse for later use. Two
horizontal lines represent the symbol of the store. The warehouse is simply
not restricted to being a data file rather it can be anything like a folder with
documents, an optical disc, a filing cabinet. The data warehouse can be
viewed independent of its implementation. When the data flow from the
warehouse it is considered as data reading and when data flows to the
warehouse it is called data entry or data updating.
● Terminator The Terminator is an external entity that stands outside of the
system and communicates with the system. It can be, for example,
organizations like banks, groups of people like customers or different
departments of the same organization, which is not a part of the model
system and is an external entity. Modeled systems also communicate with
terminator.