The spiral model combines the idea of iterative development with the

systematic, controlled aspects of the waterfall model. This Spiral model is a

combination of iterative development process model and sequential linear
development model i.e. the waterfall model with a very high emphasis on
risk analysis. It allows incremental releases of the product or incremental
refinement through each iteration around the spiral.

Spiral Model - Design

The spiral model has four phases. A software project repeatedly passes
through these phases in iterations called Spirals.

Identification
This phase starts with gathering the business requirements in the baseline
spiral. In the subsequent spirals as the product matures, identification of
system requirements, subsystem requirements and unit requirements are
all done in this phase.

This phase also includes understanding the system requirements by

continuous communication between the customer and the system analyst.
At the end of the spiral, the product is deployed in the identified market.

Design
The Design phase starts with the conceptual design in the baseline spiral
and involves architectural design, logical design of modules, physical
product design and the final design in the subsequent spirals.

Construct or Build
The Construct phase refers to production of the actual software product at
every spiral. In the baseline spiral, when the product is just thought of and
the design is being developed a POC (Proof of Concept) is developed in this
phase to get customer feedback.

Then in the subsequent spirals with higher clarity on requirements and

design details a working model of the software called build is produced with
a version number. These builds are sent to the customer for feedback.

Evaluation and Risk Analysis

Risk Analysis includes identifying, estimating and monitoring the technical
feasibility and management risks, such as schedule slippage and cost
overrun. After testing the build, at the end of first iteration, the customer
evaluates the software and provides feedback.

The following illustration is a representation of the Spiral Model, listing the

activities in each phase.

Based on the customer evaluation, the software development process

enters the next iteration and subsequently follows the linear approach to
implement the feedback suggested by the customer. The process of
iterations along the spiral continues throughout the life of the software.

Spiral Model Application

The Spiral Model is widely used in the software industry as it is in sync with
the natural development process of any product, i.e. learning with maturity
which involves minimum risk for the customer as well as the development
firms.

The following pointers explain the typical uses of a Spiral Model −

• When there is a budget constraint and risk evaluation is important.

• For medium to high-risk projects.

• Long-term project commitment because of potential changes to economic

priorities as the requirements change with time.

• Customer is not sure of their requirements which is usually the case.

• Requirements are complex and need evaluation to get clarity.

• New product line which should be released in phases to get enough customer
feedback.

• Significant changes are expected in the product during the development cycle.

Spiral Model - Pros and Cons

The advantage of spiral lifecycle model is that it allows elements of the
product to be added in, when they become available or known. This assures
that there is no conflict with previous requirements and design.

This method is consistent with approaches that have multiple software

builds and releases which allows making an orderly transition to a
maintenance activity. Another positive aspect of this method is that the
spiral model forces an early user involvement in the system development
effort.

On the other side, it takes a very strict management to complete such

products and there is a risk of running the spiral in an indefinite loop. So,
the discipline of change and the extent of taking change requests is very
important to develop and deploy the product successfully.

The advantages of the Spiral SDLC Model are as follows −

• Changing requirements can be accommodated.

 • Allows extensive use of prototypes.

• Requirements can be captured more accurately.

• Users see the system early.

• Development can be divided into smaller parts and the risky parts can be
developed earlier which helps in better risk management.

The disadvantages of the Spiral SDLC Model are as follows −

• Management is more complex.

• End of the project may not be known early.

• Not suitable for small or low risk projects and could be expensive for small
projects.

• Process is complex

• Spiral may go on indefinitely.

• Large number of intermediate stages requires excessive documentation.

The V-model is an SDLC model where execution of processes happens in a

sequential manner in a V-shape. It is also known as Verification and
Validation model.

The V-Model is an extension of the waterfall model and is based on the

association of a testing phase for each corresponding development stage.
This means that for every single phase in the development cycle, there is a
directly associated testing phase. This is a highly-disciplined model and the
next phase starts only after completion of the previous phase.

V-Model - Design
Under the V-Model, the corresponding testing phase of the development
phase is planned in parallel. So, there are Verification phases on one side of
the ‘V’ and Validation phases on the other side. The Coding Phase joins the
two sides of the V-Model.
The following illustration depicts the different phases in a V-Model of the
SDLC.

V-Model - Verification Phases

There are several Verification phases in the V-Model, each of these are
explained in detail below.

Business Requirement Analysis

This is the first phase in the development cycle where the product
requirements are understood from the customer’s perspective. This phase
involves detailed communication with the customer to understand his
expectations and exact requirement. This is a very important activity and
needs to be managed well, as most of the customers are not sure about
what exactly they need. The acceptance test design planning is done at
this stage as business requirements can be used as an input for acceptance
testing.

System Design
Once you have the clear and detailed product requirements, it is time to
design the complete system. The system design will have the understanding
and detailing the complete hardware and communication setup for the
product under development. The system test plan is developed based on
the system design. Doing this at an earlier stage leaves more time for the
actual test execution later.

Architectural Design
Architectural specifications are understood and designed in this phase.
Usually more than one technical approach is proposed and based on the
technical and financial feasibility the final decision is taken. The system
design is broken down further into modules taking up different functionality.
This is also referred to as High Level Design (HLD).

The data transfer and communication between the internal modules and
with the outside world (other systems) is clearly understood and defined in
this stage. With this information, integration tests can be designed and
documented during this stage.

Module Design
In this phase, the detailed internal design for all the system modules is
specified, referred to as Low Level Design (LLD). It is important that the
design is compatible with the other modules in the system architecture and
the other external systems. The unit tests are an essential part of any
development process and helps eliminate the maximum faults and errors at
a very early stage. These unit tests can be designed at this stage based on
the internal module designs.

Coding Phase
The actual coding of the system modules designed in the design phase is
taken up in the Coding phase. The best suitable programming language is
decided based on the system and architectural requirements.

The coding is performed based on the coding guidelines and standards. The
code goes through numerous code reviews and is optimized for best
performance before the final build is checked into the repository.
Validation Phases
The different Validation Phases in a V-Model are explained in detail below.

Unit Testing
Unit tests designed in the module design phase are executed on the code
during this validation phase. Unit testing is the testing at code level and
helps eliminate bugs at an early stage, though all defects cannot be
uncovered by unit testing.

Integration Testing
Integration testing is associated with the architectural design phase.
Integration tests are performed to test the coexistence and communication
of the internal modules within the system.

System Testing
System testing is directly associated with the system design phase. System
tests check the entire system functionality and the communication of the
system under development with external systems. Most of the software and
hardware compatibility issues can be uncovered during this system test
execution.

Acceptance Testing
Acceptance testing is associated with the business requirement analysis
phase and involves testing the product in user environment. Acceptance
tests uncover the compatibility issues with the other systems available in
the user environment. It also discovers the non-functional issues such as
load and performance defects in the actual user environment.

V-Model - Pros and Cons

The advantage of the V-Model method is that it is very easy to understand
and apply. The simplicity of this model also makes it easier to manage. The
disadvantage is that the model is not flexible to changes and just in case
there is a requirement change, which is very common in today’s dynamic
world, it becomes very expensive to make the change.

The advantages of the V-Model method are as follows −

• This is a highly-disciplined model and Phases are completed one at a time.

 • Works well for smaller projects where requirements are very well understood.

• Simple and easy to understand and use.

• Easy to manage due to the rigidity of the model. Each phase has specific
deliverables and a review process.

The disadvantages of the V-Model method are as follows −

• High risk and uncertainty.

• Not a good model for complex and object-oriented projects.

• Poor model for long and ongoing projects.

• Not suitable for the projects where requirements are at a moderate to high risk
of changing.

• Once an application is in the testing stage, it is difficult to go back and change a

functionality.

• No working software is produced until late during the life cycle.

Agile SDLC model is a combination of iterative and incremental process

models with focus on process adaptability and customer satisfaction by
rapid delivery of working software product. Agile Methods break the product
into small incremental builds. These builds are provided in iterations. Each
iteration typically lasts from about one to three weeks. Every iteration
involves cross functional teams working simultaneously on various areas
like −

• Planning

• Requirements Analysis

• Design

• Coding

• Unit Testing and

• Acceptance Testing.
At the end of the iteration, a working product is displayed to the customer
and important stakeholders.

What is Agile?
Agile model believes that every project needs to be handled differently and
the existing methods need to be tailored to best suit the project
requirements. In Agile, the tasks are divided to time boxes (small time
frames) to deliver specific features for a release.

Iterative approach is taken and working software build is delivered after

each iteration. Each build is incremental in terms of features; the final build
holds all the features required by the customer.

Here is a graphical illustration of the Agile Model −

The Agile thought process had started early in the software development
and started becoming popular with time due to its flexibility and
adaptability.

The most popular Agile methods include Rational Unified Process (1994),
Scrum (1995), Crystal Clear, Extreme Programming (1996), Adaptive
Software Development, Feature Driven Development, and Dynamic Systems
Development Method (DSDM) (1995). These are now collectively referred to
as Agile Methodologies, after the Agile Manifesto was published in 2001.

Following are the Agile Manifesto principles −

• Individuals and interactions − In Agile development, self-organization and

motivation are important, as are interactions like co-location and pair
programming.

• Working software − Demo working software is considered the best means of

communication with the customers to understand their requirements, instead of
just depending on documentation.

• Customer collaboration − As the requirements cannot be gathered completely

in the beginning of the project due to various factors, continuous customer
interaction is very important to get proper product requirements.

• Responding to change − Agile Development is focused on quick responses to

change and continuous development.

Agile Model - Pros and Cons

Agile methods are being widely accepted in the software world recently.
However, this method may not always be suitable for all products. Here are
some pros and cons of the Agile model.

The advantages of the Agile Model are as follows −

• Is a very realistic approach to software development.

• Promotes teamwork and cross training.

• Functionality can be developed rapidly and demonstrated.

• Resource requirements are minimum.

• Suitable for fixed or changing requirements

• Delivers early partial working solutions.

• Good model for environments that change steadily.

• Minimal rules, documentation easily employed.

• Enables concurrent development and delivery within an overall planned context.

 • Little or no planning required.

• Easy to manage.

• Gives flexibility to developers.

The disadvantages of the Agile Model are as follows −

• Not suitable for handling complex dependencies.

• More risk of sustainability, maintainability and extensibility.

• An overall plan, an agile leader and agile PM practice is a must without which it
will not work.

• Strict delivery management dictates the scope, functionality to be delivered, and

adjustments to meet the deadlines.

• Depends heavily on customer interaction, so if customer is not clear, team can

be driven in the wrong direction.

• There is a very high individual dependency, since there is minimum

documentation generated.

• Transfer of technology to new team members may be quite challenging due to

lack of documentation.
Agile SDLC model is a combination of iterative and incremental process
models with focus on process adaptability and customer satisfaction by
rapid delivery of working software product. Agile Methods break the product
into small incremental builds. These builds are provided in iterations. Each
iteration typically lasts from about one to three weeks. Every iteration
involves cross functional teams working simultaneously on various areas
like −

• Planning

• Requirements Analysis

• Design

• Coding

• Unit Testing and

• Acceptance Testing.

At the end of the iteration, a working product is displayed to the customer

and important stakeholders.

What is Agile?
Agile model believes that every project needs to be handled differently and
the existing methods need to be tailored to best suit the project
requirements. In Agile, the tasks are divided to time boxes (small time
frames) to deliver specific features for a release.

Iterative approach is taken and working software build is delivered after

each iteration. Each build is incremental in terms of features; the final build
holds all the features required by the customer.

Here is a graphical illustration of the Agile Model −

\

The Agile thought process had started early in the software development
and started becoming popular with time due to its flexibility and
adaptability.

The most popular Agile methods include Rational Unified Process (1994),
Scrum (1995), Crystal Clear, Extreme Programming (1996), Adaptive
Software Development, Feature Driven Development, and Dynamic Systems
Development Method (DSDM) (1995). These are now collectively referred to
as Agile Methodologies, after the Agile Manifesto was published in 2001.

Following are the Agile Manifesto principles −

• Individuals and interactions − In Agile development, self-organization and

motivation are important, as are interactions like co-location and pair
programming.

• Working software − Demo working software is considered the best means of

communication with the customers to understand their requirements, instead of
just depending on documentation.

• Customer collaboration − As the requirements cannot be gathered completely

in the beginning of the project due to various factors, continuous customer
interaction is very important to get proper product requirements.
 • Responding to change − Agile Development is focused on quick responses to
change and continuous development.

Agile Model - Pros and Cons

Agile methods are being widely accepted in the software world recently.
However, this method may not always be suitable for all products. Here are
some pros and cons of the Agile model.

The advantages of the Agile Model are as follows −

• Is a very realistic approach to software development.

• Promotes teamwork and cross training.

• Functionality can be developed rapidly and demonstrated.

• Resource requirements are minimum.

• Suitable for fixed or changing requirements

• Delivers early partial working solutions.

• Good model for environments that change steadily.

• Minimal rules, documentation easily employed.

• Enables concurrent development and delivery within an overall planned context.

• Little or no planning required.

• Easy to manage.

• Gives flexibility to developers.

The disadvantages of the Agile Model are as follows −

• Not suitable for handling complex dependencies.

• More risk of sustainability, maintainability and extensibility.

• An overall plan, an agile leader and agile PM practice is a must without which it
will not work.

• Strict delivery management dictates the scope, functionality to be delivered, and

adjustments to meet the deadlines.
• Depends heavily on customer interaction, so if customer is not clear, team can
be driven in the wrong direction.

• There is a very high individual dependency, since there is minimum

documentation generated.

• Transfer of technology to new team members may be quite challenging due to

lack of documentation.
What is the Requirements Analysis?
Requirements Analysis is the process of defining the expectat ions of the users for
an applicat ion that is to be built or modified. Requirements analysis involves all the
tasks that are conducted to ident ify t he needs of different stakeholders. Therefore
requirements analysis means to analyze, document, validate and manage software or
system requirements. High-qualit y requirements are documented, actionable,
measurable, testable, traceable, helps to ident ify busin ess opportunit ies, and are
defined to a facilitate system design.
Requirements analysis process
The requirements analysis process involves the following steps:

Eliciting requirements
The process of gathering requirements by communicat ing wit h the custo mers is
known as elicit ing requirements.

Analyzing requirements
This step helps to determine the qualit y of the requirement s. It involves ident ifying
whether the requirements are unclear, incomplete, ambiguous, and contradictory.
These issues resolved befo re moving to the next step.

Requirements modeling
In Requirements modeling, the requirements are usually documented in different
formats such as use cases, user stories, natural-language documents, or process
specificat ion.

Review and retrospective

This step is conducted to reflect on the previous iterat ions of requirements
gathering in a bid to make improvements in the process going forward.

Requirements Analysis Techniques

There are different techniques used for Requirements Analysis. Below is a list of
different Requirements Analysis Techniques:

Business process modeling notation (BPMN)

This technique is similar to creating process flowcharts, alt hough BPMN has its
own symbols and elements. Business process modeling and notation is used to
create graphs for the business process. These graphs simplify understanding the
business process. BPMN is widely popular as a process improvement methodology.

UML (Unified Modeling Language)

UML consists of an integrated set of diagrams that are created to specify, visualize,
construct and document the artifacts of a software system. UML is a useful
technique while creat ing object -oriented software and working wit h the software
development process. In UML, graphical notations are used to represent the design
of a software project. UML also help in validat ing the architectural design of the
software.
Flowchart technique
A flowchart depicts the sequent ial flow and control logic of a set of act i vit ies that
are related. Flowcharts are in different formats such as linear, cross -funct ional, and
top-down. The flowchart can represent system interact ions, data flows, etc. Flow
charts are easy to understand and can be used by both the technical and non -
technical team members. Flowchart technique helps in showcasing the crit ical
attributes of a process.

Data flow diagram

This technique is used to visually represent systems and processes that are complex
and difficult to describe in text. Data flow diagra ms represent the flow of
informat ion through a process or a system. It also includes the data inputs and
outputs, data stores, and the various subprocess through which the data moves. DFD
describes various ent it ies and their relat ionships wit h the help of standardized
notations and symbols. By visualizing all the elements of the system it is easier to
ident ify any shortcomings. These shortcomings are then eliminated in a bid to
create a robust solut ion.

Role Activity Diagrams (RAD)

Role-act ivit y diagram (RAD) is a role-oriented process model that represents role -
act ivit y diagrams. Role act ivit y diagrams are a high-level view that captures the
dynamics and role structure of an organizat ion. Roles are used to grouping together
act ivit ies into units of responsibilit ies. Act ivit ies are the basic parts of a role. An
act ivit y may be eit her carried out in isolat ion or it may require coordinat ion wit h
other act ivit ies wit hin t he role.

Gantt Charts
Gant charts used in project planning as they provide a visual repres entation of tasks
that are scheduled along wit h the timelines. The Gant charts help to know what is
scheduled to be completed by which date. The start and end dates of all the tasks in
the project can be seen in a single view.

IDEF (Integrated Definition for Function Modeling)

Integrated definit ion for funct ion modeling (IDEFM) technique represents the
funct ions of a process and their relat ionships to child and parent systems wit h the
help of a box. It provides a blueprint to gain an understanding of an org anizat ion’s
system.

Gap Analysis
Gap analysis is a technique which helps to analyze the gaps in performance of a
software applicat ion to determine whether the business requirements are met or not.
It also involves the steps that are to be taken to ensure t hat all t he business
requirements are met successfully. Gap denotes the difference between the present
state and the target state. Gap analysis is also known as need analysis, need
assessment or need-gap analysis.

Analysis Principles

Over the past two decades, a large number of analysis modeling methods have been developed. Investigators have identified
analysis problems and their causes and have developed a variety of notations and corresponding sets of heuristics to overcome
them. Each analysis method has a unique point of view.

✓The information domain of a problem must be represented and understood.

✓The functions that the software is to perform must be defined.
✓The behavior of the software must be represented.
✓The models that depict information, function, and
✓The models that depict information function and behavior must be partitioned in a manner that uncovers details in a
layered fashion.
✓The analysis process should move from essential information toward implementation detail.

In addition to these operational analysis principles for requirements engineering:

✓Understand the problem before you begin to create the analysis model.
✓Develop prototype that enable a user to understand how human/machine interaction will occur.
✓Record the origin of and the reason for every requirement.
✓Use multiple views of requirements.
✓Rank requirements.
✓Work to eliminate ambiguity

SOFTWARE PROTOTYPING AND SPECIFICATION

Prototyping is a process that enables developer to create a small model of software. The IEEE 610.12
standard defines prototype as a preliminary form or instance of a system that serves as a model for later
stages for the final complete version of the system. A prototype may be categorised as follows:

1. A paper prototype, which is a model depicting human machine interaction in a form that makes the
user understand how such interaction, will occur.
2. A working prototype implementing a subset of complete features.

3. An existing program that performs all of the desired functions but additional features are added for
improvement.

Prototype is developed so that customers, users and developers can learn more about the problem.
Thus, prototype serves as a mechanism for identifying software requirements. It allows the user to
explore or criticise the proposed system before developing a full scale system.

2.4.1 Types of Prototype Broadly, the prototypes are developed using the following two techniques:

Throw away prototype: In this technique, the prototype is discarded once its purpose is fulfilled and the
final system is built from scratch. The prototype is built quickly to enable the user to rapidly interact
with a working system. As the prototype has to be ultimately discarded, the attention on its speed,
implementation aspects, maintainability and fault tolerance is not paid. In requirements defining phase,
a less refined set of requirements are hurriedly defined and throw away prototype is constructed to
determine the feasibility of requirement, validate the utility of function, uncover missing requirements,
and establish utility of user interface. The duration of prototype building should be as less as possible
because its advantage exists only if results from its use are available in timely fashion.

Evolutionary Prototype: In this, the prototype is constructed to learn about the software problems and
their solutions in successive steps. The prototype is initially developed to satisfy few requirements.
Then, gradually, the requirements are added in the same prototype leading to the better understanding
of software system. The prototype once developed is used again and again. This process is repeated till
all requirements are embedded in this and the complete system is evolved.

According to SOMM [96] the benefits of developing prototype are listed below:

1. Communication gap between software developer and clients may be identified.

2. Missing user requirements may be unearthed.

3. Ambiguous user requirements may be depicted.

4. A small working system is quickly built to demonstrate the feasibility and usefulness of the application
to management.

5. It serves as basis for writing the specification of the system.

The sequence of prototyping is shown in following Fig

 Problems of Prototyping In some organisations, the prototyping is not as successful as anticipated. A
common problem with this approach is that people expect much from insufficient effort. As the
requirements are loosely defined, the prototype sometimes gives misleading results about the working
of software. Prototyping can have execution inefficiencies and this may be questioned as negative
aspect of prototyping. The approach of providing early feedback to user may create the impression on
user and user may carry some negative biasing for the completely developed software also.

Advantages of Prototyping The advantages of prototyping outperform the problems of prototyping.

Thus, overall, it is a beneficial approach to develop the prototype. The end user cannot demand fulfilling
of incomplete and ambiguous software needs from the developer. One additional difficulty in adopting
this approach is the large investment that exists in software system maintenance. It requires additional
planning about the re-engineering of software. Because, it may be possible that by the time the
prototype is build and tested, the technology of software development is changed, hence requiring a
complete re-engineering of the product.
1. Business Process Modeling Notation (BPMN) is a flow chart method
that models the steps of a planned business process from end to end. A
key to Business Process Management, it visually depicts a detailed
sequence of business activities and information flows needed to
complete a process.

2.DFD Diagram
3.Rad Symbols and diagram

5.Gantt Chart
6.IDEF Diagram

7.Gap Analysis