S O F T WA R E L I F E C Y C L E M O D E L S

Module 1
WATERFALL MODEL AND ITS EXTENSIONS

• The waterfall model and its derivatives were extremely popular in the 1970s and

still are heavily being used across many development projects.

• The waterfall model is possibly the most obvious and intuitive way in which software

can be developed through team effort.

• We can think of the waterfall model as a generic model that has been extended in

many ways

• For this reason, after discussing the classical and iterative waterfall models, we

discuss its various extensions.

Classical Waterfall Model
• Classical waterfall model is intuitively the most obvious way to develop software.

• It is simple but idealistic.

• In fact, it is hard to put this model into use in any non-trivial software

development project.

• One might wonder if this model is hard to use in practical development

projects,then why study it at all?

• The reason is that all other life cycle models can be thought of as being

extensions of the classical waterfall model.

Classical Waterfall Model
• Therefore, it makes sense to first understand the classical waterfall model,
in order to be able to develop a proper understanding of other life cycle
models.
• Besides, we shall see later in this text that this model though not used for
software development; is implicitly used while documenting software.

• The classical waterfall model divides the life cycle into a set of phases as
shown in Figure 1.
• It can be easily observed from this figure that the diagrammatic
representation of the classical waterfall model resembles a multi-level
waterfall.

• This resemblance justifies the name of the model.

Figure 1 : Classical Waterfall Model
Phases of the classical waterfall
model
• The different phases of the classical waterfall model have been shown in Figure 1

1. Feasibility study

2. Requirement analysis and specifications

3. Design

4. Coding and Unit testing

5. Integration and system testing

6. Maintenance
1. FEASIBILITY STUDY

• The main focus of the feasibility study stage is to determine whether it would be

financially and technically feasible to develop the software.

• The feasibility study involves carrying out several activities such as collection of basic

information relating to the software such as the different data items that would be

input to the system, the processing required to be carried out on these data, the

output data required to be produced by the system, as well as various constraints on

the development.
1. Development of an overall understanding of the
problem:

• It is necessary to first develop an overall understanding of what the

customer requires to be developed.
• For this, only the the important requirements of the customer need to
be understood and the details of various requirements such as the
screen layouts required in the graphical user interface (GUI), specific
formulas or algorithms required for producing the required results, and
the databases schema to be used are ignored.
2. Formulation of the various possible strategies for solving the problem:

• In this activity, various possible high-level solution schemes to the problem are
determined.
• For example, solution in a client-server framework and a standalone application
framework may be explored.

3. Evaluation of the different solution strategies:

• The different identified solution schemes are analysed to evaluate their benefits
and shortcomings.
• Such evaluation often requires making approximate estimates of the resources
required, cost of development, and development time required.

• The different solutions are compared based on the estimations that have been

worked out.
• Once the best solution is identified, all activities in the later phases are carried out as per this

solution.

• At this stage, it may also be determined that none of the solutions is feasible due to high cost,

resource constraints, or some technical reasons.

• This scenario would, of course, require the project to be abandoned.

• We can summarise the outcome of the feasibility study phase by noting that other than

deciding whether to take up a project or not, at this stage very high-level decisions regarding

the solution strategy is defined.

• At this stage very high-level decisions regarding the solution strategy is defined. Therefore,

feasibility study is a very crucial stage in software development.

2. Requirements analysis and
specification
• The aim of the requirements analysis and specification phase is to
understand the exact requirements of the customer and to
document them properly. This phase consists of two distinct
activities, namely

1. Requirements gathering and analysis

2. Requirements specification.
1. Requirements gathering and analysis:

● The goal of the requirements gathering activity is to collect all relevant

information regarding the software to be developed from the customer
with a view to clearly understand the requirements.
● For this, first requirements are gathered from the customer and
then the gathered requirements are analysed.

● The goal of the requirements analysis activity is to weed out the

incompleteness and inconsistencies in these gathered requirements.

● Note that a n inconsistent requirement is one in which some part of the

requirement contradicts with some other part. On the other hand, a n
incomplete requirement is one in which some parts of the actual
requirements have been omitted.
2. Requirements specification:

● After the requirement gathering and analysis activities are

complete, the identified requirements are documented.
● This is called a software requirements specification (SRS)
document.
● The SRS document is written using end-user terminology.
● This makes the SRS document understandable to the customer.
● Therefore, understandability of the SRS document is an important issue.
● The SRS document normally serves as a contract between the
development team and the customer.
• Any future dispute between the customer and the developers can be

settled by examining the SRS document.

The SRS document is therefore an important document which must be

•
thoroughly understood by the development team, and reviewed jointly

with the customer.

• The SRS document not only forms the basis for carrying out all the

development activities, but several documents such as users’ manuals,

system test plan, etc. are prepared directly based on it.

3. DESIGN
• The goal of the design phase is to transform the requirements specified in
the SRS document into a structure that is suitable for implementation in
some programming language.
• In technical terms, during the design phase the software architecture is
derived from the SRS document.

• Two distinctly different design approaches are popularly being used at

present the procedural and object-oriented design approaches.
1. Procedural design approach:

• The traditional design approach is in use in many software development projects at the
present time.

• This traditional design technique is based on the data flow-oriented design approach.
• It consists of two important activities; first structured analysis of the requirements
specification is carried out where the detailed structure of the problem is examined.

• This is followed by a structured design step where the results of structured analysis are
transformed into the software design.

• During structured analysis, the functional requirements specified in the SRS document
are decomposed into subfunctions and the data-flow among these subfunctions is
analysed and represented diagrammatically in the form of DFDs.
• Structured design is undertaken once the structured analysis activity is complete.

• Structured design consists of two main activities:-

➢ Architectural design (also called high-level design )

➢ Detailed design (also called Low-level design ).

• High-level design involves decomposing the system into modules, and representing the
interfaces and the invocation relationships among the modules. A high-level software

design is some times referred to as the software architecture.

• During the detailed design activity, internals of the individual modules such as the data
structures and algorithms of the modules are designed and documented.
[Link]-oriented design approach

• In this technique, various objects that occur in the problem domain and
the solution domain are first identified and the different relationships
that exist among these objects are identified.
• The object structure is further refined to obtain the detailed design.
• The OOD approach is credited to have several benefits such as lower
development time and effort, and better maintainability of the
software.
4. Coding and unit testing
• The purpose of the coding and unit testing phase is to translate a software design into
source code and to ensure that individually each function is working correctly.

• The coding phase is also sometimes called the implementation phase, since
the design is implemented into a workable solution in this phase.

• Each component of the design is implemented as a program module.

• The end-product of this phase is a set of program modules that have been individually
unit tested.

• The main objective of unit testing is to determine the correct working of the individual
modules.

• The specific activities carried out during unit testing include designing test cases,
testing, debugging to fix problems, and management of test cases.
5. Integration and system testing
• Integration of different modules is undertaken soon after they have been coded and unit
tested.
• During the integration and system testing phase, the different modules are
integrated in a planned manner.
• Various modules making up a software are almost never integrated in one
• Integration of various modules are normally carried out incrementally over a number of
steps.
• During each integration step, previously planned modules are added to the partially
integrated system and the resultant system is tested.
• Finally, after all the modules have been successfully integrated and tested, the full
working system is obtained.
• System testing is carried out on this fully working system.
System testing consists of three different kinds of testing activities as
described below.
➢ Alpha testing: Alpha testing is the system testing performed by the
development team.
➢ Beta testing: Beta testing is the system testing performed by a
friendly set of customers.
➢ Acceptance testing: After the software has been delivered, the customer
performed
acceptance testing to determine whether to accept the delivered
software or reject it.
 6. Maintenance
• The total effort spent on maintenance of a typical software during its operation phase is much
more than that required for developing the software itself.
• Many studies carried out in the past confirm this and indicate that the ratio of relative effort of
developing a typical software product and the total effort spent on its maintenance is roughly
40:60.

• Maintenance is required in the following three types of situations:

1. Corrective maintenance: This type of maintenance is carried out to correct errors that
were not discovered during the product development phase.
2. Perfective maintenance: This type of maintenance is carried out to improve the performance
of the system, or to enhance the functionalities of the system based on customer’s requests.

3. Adaptive maintenance: Adaptive maintenance is usually required for porting the software
to work in a new environment. For example, porting may be required to get the software to
work on a new computer platform or with a new operating system.
Shortcomings of the classical waterfall model
• The classical waterfall model is a very simple and intuitive model. However, it suffers
from several shortcomings. Let us identify some of the important shortcomings of the
classical waterfall model:
1. No feedback paths:
• In classical waterfall model, the evolution of a software from one phase to the next is
analogous to a waterfall.
• Just as water in a waterfall after having flowed down cannot flow back, once a phase is
complete, the activities carried out in it and any artifacts produced in this phase are
considered to be final and are closed for any rework.
• This requires that all activities during a phase are flawlessly carried out.
• The classical waterfall model is idealistic in the sense that it assumes that no error is ever
committed by the developers during any of the life cycle phases, and therefore,
incorporates no mechanism for error correction.
• Contrary in practical development environments, the developers do commit a large
number of errors in almost every activity they carry out during various phases of the life
cycle.

• After all, programmers are humans and as the old adage says to err is humane.
• The cause for errors can be many—oversight, wrong interpretations, use of
incorrect solution scheme, communication gap, etc.

• These defects usually get detected much later in the life cycle.
• For example, a design defect might go unnoticed till the coding or testing phase.

• Once a defect is detected at a later time, the developers need to redo some of the work
done during that phase and also redo the work of later phases that are affected by the
rework.

• Therefore, in any non-trivial software development project, it becomes nearly

impossible to strictly follow the classical waterfall model of software development.
[Link] to accommodate change requests:
• This model assumes that all customer requirements can be completely and correctly
defined at the beginning of the project.

• There is much emphasis on creating an unambiguous and complete set of

requirements.

• But, it is hard to achieve this even in ideal project scenarios.

• The customers’ requirements usually keep on changing with time.
• But, in this model it becomes difficult to accommodate any requirement change
requests made by the customer after the requirements specification phase is
complete, and this often becomes a source of customer discontent.

[Link] error corrections:

• This model defers integration of code and testing tasks until it is very late when the
problems are harder to resolve.
4. No overlapping of phases:
• This model recommends that the phases be carried out sequentially—
new phase can start only after the previous one completes
• However, it is rarely possible to adhere to this recommendation and it
leads to a large number of team members to idle for extended periods.
• For example, for efficient utilization of manpower, the testing team
might need to design the system test cases immediately after
requirements specification is complete.

• In this case, the activities of the design and testing phases overlap.
• Consequently, it is safe to say that in a practical software development
scenario, rather than having a precise point in time at which a phase
transition occurs, the different phases need to overlap for cost and
efficiency reasons.
Is the classical waterfall model useful at all?
• We have already pointed out that it is hard to use the classical
waterfall model in real projects.
• In any practical development environment, as the software takes shape,
several iterations through the different waterfall stages become
necessary for correction of errors committed during various phases.

• Therefore, the classical waterfall model is hardly usable for software

development.
• But, the final documents for the product should be written as if the
product was developed using a pure classical waterfall.
Iterative Waterfall Model

Figure 2: Iterative waterfall Model

• In a practical software development project, the classical waterfall
model is hard to use.
• The iterative waterfall model can be thought of as incorporating the
necessary changes to the classical waterfall model to make it usable in
practical software development projects.

• The feedback paths introduced by the iterative waterfall model are

shown in Figure 2.
• The feedback paths allow for correcting errors committed by a
programmer during some phase, as and when these are detected in
a later phase.

The main change brought about by the iterative waterfall model to the classical waterfall
model is in the form of providing feedback paths from every phase to its preceding
phases.
• For example, if during the testing phase a design error is
identified, then the feedback path allows the design to be
reworked and the changes to be reflected in the design
documents and all other subsequent documents.

• There is no feedback path to the feasibility stage.

• This is because once a team having accepted to take up a
project, does not give up the project.
Shortcomings of the iterative waterfall
model
[Link] to accommodate change requests:
A major problem with the waterfall model is that the requirements need to be frozen
before the development starts.

• Based on the frozen requirements, detailed plans are made for the activities to be
carried out during the design, coding, and testing phases.
• Therefore, accommodating even small change requests after the development
activities are underway not only requires overhauling the plan, but also the artifacts
that have already been developed.

• several projects points to the fact that later changes to requirements are almost
inevitable.
• Requirement changes can arise due to a variety of reasons including the
following :- requirements were not clear to the customer, requirements
were misunderstood, business process o f the customer may have
changed after the SRS document was signed off, etc.
• In fact, customers get clearer understanding of their requirements only
after working on a fully developed and installed system.
[Link] delivery not supported:
• In the iterative waterfall model, the full software is completely developed
and tested before it is delivered to the customer.

• There is no provision for any intermediate deliveries to occur.

• This is problematic because the complete application may take several
months or years to be completed and delivered to the customer.
• By the time the software is delivered, installed, and becomes ready
for use, the customer’s business process might have changed
substantially.

• This makes the developed application a poor fit to the customer’s

requirements.
[Link] overlap not supported:
• For most real life projects, it becomes difficult to follow the rigid phase sequence
prescribed by the waterfall model.
• By the term a rigid phase sequence, we mean that a phase can start only after the
previous phase is
complete in all respects.
• As already discussed, strict adherence to the waterfall model creates blocking states.
• The waterfall model is usually adapted for use in real-life projects by allowing
overlapping of various phases as shown in Figure 2.1.

Figure:2.1Distribution of effort
for various phases in the
iterative waterfall model.
[Link] correction unduly expensive:
• In waterfall model, validation is delayed till the complete development of the
software.
• As a result, the defects that are noticed at the time of validation incur expensive
rework and result in cost escalation and delayed delivery.
[Link] customer interactions:
• This model supports very limited customer interactions.
• It is generally accepted that software developed in isolation from the customer is
the cause of many
problems.
• In fact, interactions occur only at the start of the project and at project completion.
• As a result, the developed software usually turns out to be a misfit to the
customer’s actual requirements.
 6. Heavy weight:

• The waterfall model overemphasizes documentation.

• A significant portion of the time of the developers is spent in preparing documents, and
revising them as changes occur over the life cycle.
• Heavy documentation though useful during maintenance and for carrying out review, is
a source of team inefficiency.

7. No support for risk handling and code reuse:

• It becomes difficult to use the waterfall model in projects that are susceptible to various types of
risks, or those involving significant reuse of existing development artifacts.
 V-Model
• A popular development process model, V-model is a variant of the
waterfall model.
• As is the case with the waterfall model, this model gets its name
from its visual appearance (see Figure 3).
• In this model verification and validation activities are carried out
throughout the development life cycle, and therefore the chances
of bugs in the work products considerably reduce.
• This model is therefore generally considered to be suitable for use in
projects concerned with development of safety-critical software that are
required to have high reliability.
Figure 3: V-Model
• As shown in Figure 2.5, there are two main phases:-

1. Development phases
2. Validation phases.
• The left half of the model comprises the development phases and the right half comprises
the validation phases.

• In each development phase, along with the development of a work product, test case design and
the plan
for testing the work product are carried out, whereas the actual testing is carried out in the
validation phase.
• This validation plan created during the development phases is carried out in the
corresponding validation phase which have been shown by dotted arcs in Figure 2.5.

• In the validation phase, testing is carried out in three steps—unit, integration, and system testing.
• The purpose of these three different steps of testing during the validation phase is to detect
defects that
arise in the corresponding phases of software development requirements analysis and

specification, design, and coding respectively.

V-model versus waterfall model
• We have already pointed out that the V-model can be considered to be an extension
of the waterfall model.
• However, there are major differences between the two.
• In contrast to the iterative waterfall model where testing activities are confined to the
testing phase only,
• In the V-model testing activities are spread over the entire life cycle.
• As shown in Figure 3, during the requirements specification phase, the system test suite
design activity takes place. During the design phase, the integration test cases are
designed. During coding, the unit test cases are designed.
• Thus, we can say that in this model, development and validation activities proceed
hand in hand.
Advantages of V-model
The important advantages of the V-model over the iterative waterfall model
are as following:
• In the V-model, much of the testing activities (test case design, test
planning, etc.) are carried out in parallel with the development
activities. Therefore, before testing phase starts significant part of the
testing activities, including test case design and test planning, is already
complete. Therefore, this model usually leads to a shorter testing phase
and an overall faster product development as compared to the iterative
model.
• Since test cases are designed when the schedule pressure has not built
up, the quality of the test cases are usually better.
• The test team is reasonably kept occupied throughout the development
cycle in contrast to the waterfall model where the testers are active only
during the testing phase. This leads to more efficient manpower
utilization.
• In the V-model, the test team is associated with the project from the
beginning. Therefore they build up a good understanding of the
development artifacts, and this in turn, helps them to carry out effective
testing of the software.
• In contrast, in the waterfall model often the test team comes on board
late in the development cycle since no testing activities are carried out
before the start of the implementation and testing phase.
 Disadvantages of V-model

• Being a derivative of the classical waterfall model, this model

inherits most of the weaknesses of the waterfall model.
 Prototyping Model
• The prototype model is also a popular life cycle model.
• The prototyping model can be considered to be an extension of the
waterfall model.
• This model suggests building a working prototype of the system, before
development of the actual software.

• A prototype is a toy and crude implementation of a system.

• It has limited functional capabilities, low reliability, or inefficient
performance as compared to the actual software.

• A prototype can be built very quickly by using several shortcuts.

• The shortcuts usually involve developing inefficient, inaccurate, or
dummy functions.
Figure 4: Prototyping model of software development.
Life cycle activities of prototyping
model

• The prototyping model of software development is graphically shown in Figure

3.
• software is developed through two major activities:-Prototype construction
and Iterative waterfall-based software development.

1. Prototype development:

• Prototype development starts with an initial requirements gathering phase.

• A quick design is carried out and a prototype is built.
• The developed prototype is submitted to the customer for evaluation.
• Based on the customer feedback, the requirements are refined and the
prototype is suitably modified.
• This cycle of obtaining customer feedback and modifying the prototype
continues till the customer approves the prototype.
[Link] development:
• Once the customer approves the prototype, the actual software is
developed using the iterative waterfall approach.
• In spite of the availability of a working prototype, the SRS document is
usually needed to be developed since the SRS document is valuable for
carrying out traceability analysis, verification, and test case design during
later phases.

• The code for the prototype is usually thrown away. However, the
experience gathered from

developing the prototype helps a great deal in developing the actual

system
• By constructing the prototype and submitting it for user evaluation, many
customer requirements get properly defined and technical issues get
resolved by experimenting with the prototype. This minimizes later
change requests from the customer and the associated redesign costs.

• The prototyping model is advantageous to use for specific types of

projects.
In the following, we identify three types of projects for which the prototyping model can be followed to
advantage:

[Link] is advantageous to use the prototyping model for development of the graphical user interface (GUI)
part of an application. Through the use of a prototype, it becomes easier to illustrate the input data
formats, messages, reports, and the interactive dialogs to the customer. This is a valuable mechanism
for gaining better understanding of the customers’ needs. In this regard, the prototype model turns
out to be especially useful in developing the graphical user interface (GUI) part of a system.
[Link] prototyping model is especially useful when the exact technical solutions are unclear to the
development team. A prototype can help them to critically examine the technical issues associated
with product development. lack of familiarity with a required development technology is a technical
risk. This risk can be resolved by developing a prototype. Once they feel confident in it, they can use
this knowledge to develop the product. Often, major design decisions depend on issues such as the
response time of a hardware controller, or the efficiency of a sorting algorithm, etc. In such
circumstances, a prototype is often the best way to resolve the technical issues.
 3. An important reason for developing a prototype is that it
is impossible to “get it right” the first time.

Thus, the prototyping model can be deployed when

development of highly optimized and efficient software is
required.
➢ Strengths of the prototyping model
• This model is the most appropriate for projects that suffer from technical and requirements
risks. A constructed prototype helps overcome these risks.

➢ Weaknesses of the prototyping model

• The prototype model can increase the cost of development for projects that are routine
development work and do not suffer from any significant risks.

• Even when a project is susceptible to risks, the prototyping model is effective only for
those projects for which the risks can be identified upfront before the development
starts.

• Since the prototype is constructed only at the start of the project, the prototyping
model is ineffective for risks identified later during the development cycle.
• The prototyping model would not be appropriate for projects for which the risks can only
be identified after the development is underway
Incremental Development Model
• This life cycle model is sometimes referred to as the successive versions
model and sometimes as the incremental model.
• In this life cycle model, first a simple working system implementing only
a few basic features is built and delivered to the customer.
• Over many successive iterations successive versions are implemented
and delivered to the customer until the desired system is realized.

• The incremental development model has been shown in Figure 2.7.

Figure 5: Incremental software development.
Life cycle activities of incremental development
model

• In the incremental life cycle model, the requirements of the software are first broken down
into several modules or features that can be incrementally constructed and delivered.

• At any time, plan is made only for the next increment and no long-term plans a re made.

• Therefore, it becomes easier to accommodate change requests from the customers.

• The development team first undertakes to develop the core features of the system.

• The core or basic features are those that do not need to invoke any services from the other
features.

• On the other hand, non-core features need services from the core features.
• Once the initial core features are developed, these are refined into increasing levels of capability
by adding new functionalities in successive versions.

• Each incremental version is usually developed using an iterative waterfall model of development.
Figure 5.1:Incremental model of software development
Life cycle activities of incremental development
model
• The incremental model is schematically shown in Figure 5.1.

• As each successive version of the software is constructed and delivered to the customer, the
customer feedback is obtained on the delivered version and these feedbacks are
incorporated in the next version.

• Each delivered version of the software incorporates additional features over the previous
version and also refines the features that were already delivered to the customer.

• After the requirements gathering and specification, the requirements are split into several
versions.
• Starting with the core (version 1), in each successive increment, the next version is
constructed using an iterative waterfall model of development and deployed at the customer
site.
• After the last (shown as version n) has been developed and deployed at the client site, the full
software is deployed.
 Advantages
The incremental development model offers several advantages. Two important ones are
the following:

➢ Error reduction: The core modules are used by the customer from the
beginning and therefore these get tested thoroughly. This reduces
chances of errors in the core modules of the final product, leading to
greater reliability of the software.
➢ Incremental resource deployment: This model obviates the need for the
customer to commit large resources at one go for development of the
system. It also saves the developing organization from deploying large
resources and manpower for a project in one go.
 SPIRAL MODEL
• This model gets its name from the appearance of its diagrammatic representation
that looks like a spiral with many loops .
• The exact number of loops of the spiral is not fixed and can vary from project to
project.
• Each loop of the spiral is called a phase of the software process.
• The exact number of phases through which the product is developed can be varied
by the project manager depending upon the project risks.
• A prominent feature of the spiral model is handling unforeseen risks that can show
up much after the project has started.
• In this context, please recollect that the prototyping model can be used effectively
only when the risks in a project can be identified upfront before the development work
starts.
• While the prototyping model does provide explicit support for risk handling,
the risks are assumed to have been identified completely before the project
start.

• This is required since the prototype is constructed only at the start of the
project.

• In contrast, in the spiral model prototypes are built at the start of every phase.

• Each phase of the model is represented as a loop in its diagrammatic

representation.
• Over each loop, one or more features of the product are elaborated and
analyzed and the risks at that point of time are identified and are resolved
through prototyping.

• Based on this, the identified features are implemented.

Figure 6: Spiral Model
Risk handling in spiral model
 A risk is essentially any adverse circumstance that might hamper the
successful completion of a software project.

 As an example, consider a project for which a risk can be that data

access from a remote database might be too slow to be acceptable by
the customer.

 This risk can be resolved by building a prototype of the data access

subsystem and experimenting with the exact access rate.

 If the data access rate is too slow, possibly a caching scheme can be
implemented or a faster communication scheme can be deployed to
overcome the slow data access rate.
 Such risk resolutions are easier done by using a prototype
as the pros and cons of an alternate solution scheme can
evaluated faster and inexpensively, as compared to
experimenting using the actual software application being
developed.

 The spiral model supports coping up with risks by providing

the scope to build a prototype at every phase of software
development
Phases of the Spiral Model
• Quadrant 1: The objectives are investigated, elaborated, and
analyzed. Based on this, the risks involved in meeting the
phase objectives are identified. In this quadrant, alternative
solutions possible for the phase under consideration are
proposed.
• Quadrant 2: During the second quadrant, the alternative
solutions are evaluated to select the best possible solution. To
be able to do this, the solutions are evaluated by developing
an appropriate prototype.
Quadrant 3: Activities during the third quadrant consist of
developing and verifying the next level of the software. At the end
of the third quadrant, the identified features have been
implemented and the next version of the software is available.

Quadrant 4: Activities during the fourth quadrant concern reviewing

the results of the stages traversed so far (i.e. the developed version
of the software) with the customer and planning the next iteration
of the spiral.
• The radius of the spiral at any point represents the cost incurred in the
project so far, and the angular dimension represents the progress made
so far in the current phase.
• In the spiral model of development, the project manager dynamically
determines the number of phases as the project progresses.
• Therefore, in this model, the project manager plays the crucial role of
tuning the model to specific projects.
• To make the model more efficient, the different features of the software
that can be developed simultaneously through parallel cycles are
identified.
Spiral model as a meta model
• As compared to the previously discussed models, the spiral model can be viewed as a
meta model, since it subsumes all the discussed models.

• For example, a single loop spiral actually represents the waterfall model.

• The spiral model incorporates the systematic step- wise approach of the waterfall
model.
• The spiral model uses the approach of the prototyping model by first building a
prototype in each phase before the actual development starts.

• This prototypes are used as a risk reduction mechanism.

• Also, the spiral model can be considered as supporting the evolutionary model—the
iterations along the spiral can be considered as evolutionary levels through which
the complete system is built.
• This enables the developer to understand and resolve the risks at each evolutionary
level (i.e. iteration along the spiral).
Disadvantages/cons of spiral model
There are a few disadvantages of the spiral model that
• restrict its to use only a few types of projects.
• To the developers of a project, the spiral model usually appears as a
complex model to follow, since it is risk driven and is more complicated
phase structure than the other models.

• It would therefore be counter productive to use, unless there are

knowledgeable and experienced staff in the project.
• Also, it is not very suitable for use in the development of outsourced
projects, since the software risks need to be continually assessed as it is
developed.
Advantages/pros of the spiral model

• For projects having many unknown risks that might show up as the
development proceeds, the spiral model would be the most appropriate
development model to follow.
• In this regard, it is much more powerful than the prototyping model.
Prototyping model can meaningfully be used when all the risks
associated with a project are known beforehand.
• All these risks are resolved by building a prototype before the actual
software development starts.