• SDLC Models

• There is difference between the exploratory program

development style and the software engineering
approach.
• The exploratory style is also known as the build and fix
programming. Here, a programmer typically starts to
write the program immediately after he has formed an
informal understanding of the requirements. Once
program writing is complete, he gets down to fix
anything that does not meet the user’s expectations.
• Usually, a large number of code fixes are required even
for toy programs. This pushes up the development
costs and pulls down the quality of the program.
• Further, this approach usually turns out to be a recipe for
project failure when used to develop non-trivial
programs requiring team effort.
• In contrast to the build and fix style, the software
engineering approaches emphasise software
development through a well-defined and ordered set of
activities.
• These activities are graphically modelled (represented)
as well as textually described and are variously called a
software life cycle model, software development life cycle
(SDLC) model, and software development process model.
Several life cycle models have so far been proposed.
• However, in this Chapter we confine our attention to only
a few important and commonly used ones.
• LIFE CYCLE MODEL
• A software life cycle model (also called process model) is a descriptive
and diagrammatic representation of the software life cycle.
• A life cycle model represents all the activities required to make a
software product transit through its life cycle phases.
• It also captures the order in which these activities are to be
undertaken.
• In other words, a life cycle model maps the different activities
performed on a software product from its inception to retirement.
• Different life cycle models may map the basic development activities to
phases in different ways.
• Thus, no matter which life cycle model is followed, the basic activities
are included in all life cycle models though the activities may be carried
out in different orders in different life cycle models.
• During any life cycle phase, more than one activity may also be carried
out.
• Software life cycle has been defined to imply the
different stages (or phases) over which a software
evolves from an initial customer request for it, to a fully
developed software, and finally to a stage where it is no
longer useful to any user, and then it is discarded.
• As we have already pointed out, the life cycle of every
software starts with a request for it by one or more
customers.
• At this stage, the customers are usually not clear about
all the features that would be needed, neither can they
completely describe the identified features in concrete
terms, and can only vaguely describe what is needed.
• This stage where the customer feels a need for
the software and forms rough ideas about the
required features is known as the inception
stage.
• Starting with the inception stage, a software
evolves through a series of identifiable stages
(also called phases) on account of the
development activities carried out by the
developers, until it is fully developed and is
released to the customers.
• Once installed and made available for use, the
users start to use the software.
• This signals the start of the operation (also called
maintenance ) phase.
• As the users use the software, not only do they
request for fixing any failures that they might
encounter, but they also continually suggest
several improvements and modifications to the
software.
• Thus, the maintenance phase usually involves
continually making changes to the software to
accommodate the bug-fix and change requests
from the user.
• The operation phase (maintenance) is usually the
longest of all phases and constitutes the useful life
of a software.
• Finally the software is retired, when the users do
not find it any longer useful due to reasons such
as changed business scenario, availability
of a new software having improved features and
working, changed computing platforms, etc.
• This forms the essence of the life cycle of every
software.
 Waterfall Model
• 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 catering to
certain specific software development situations to
realise all other software life cycle models.
 Classical Waterfall Model

• It is simple but idealistic. In fact, it is hard to put this

model into use in any non-trivial software
development project.
• Even then, it is studied as all other life cycle models
can be thought of as being extensions of the classical
waterfall model.
• The classical waterfall model divides the life cycle into
a set of phases as shown in Figure 2.1 . It looks like a
Waterfall.
• Phases of the classical waterfall
model
• The different phases of the classical
waterfall model have been shown in
Figure 2.1.
• As shown in Figure 2.1, the different phase
are— feasibility study, requirements
analysis and specification, design, coding
and unit testing, integration and system
testing, and maintenance.
• The phases starting from the feasibility study to the
integration and system testing phase are known as the
development phases.
• A software is developed during the development
phases, and at the completion of the development
phases, the software is delivered to the customer.
• After the delivery of software, customers start to use
the software signalling the commencement of the
operation phase.
• As the customers start to use the software, changes to
it become necessary on account of bug fixes and
feature extensions, causing maintenance works to be
undertaken. Therefore, the last phase is also known as
the maintenance phase of the life cycle.
• Phases of Waterfall Model:

1. Feasibility study: It is studied whether it is feasible to develop

the s/w technically, financially and operationally.
2. Requirements Analysis and Specification:
a) Requirements gathering and Analysis of those requirements
b) Requirements specifications after gathering and analysis. 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.
c) 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.
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. In the
following, we briefly discuss the essence of these two
approaches.
• 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 sub-functions and the data-flow
among these sub-functions 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 )
– and 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.
• Object-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.
 CODING STAGE
• 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.
• 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 shot
• 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 usually consists of three different kinds of testing
activities:
• Alpha testing: testing is the system testing performed by the
development team.
• Beta testing: This is the system testing performed by a friendly set of
customers.
• Acceptance testing: After the software has been delivered, the
customer performs system testing to determine whether to accept
the delivered software or to reject it.
• 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:
– Corrective maintenance: This type of maintenance is
carried out to correct errors that were not discovered
during the product development phase.
• 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.
• 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.
 Short comings of Waterfall model

• The classical waterfall model is a very simple and

intuitive model.
However, it suffers from several shortcomings
• 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.
– During actual development of software, there are
several errors.
• Difficult 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.
• Inefficient error corrections:
– This model defers integration of code and
testing tasks until it is very late when the problems are
harder to resolve.

• 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 utilisation 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 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, as suggested by Parnas [1972] the
final documents for the product should be written as if the
product was developed using a pure classical waterfall model.
– The documents at end of each stage are: Feasibility report, SRS
document, System Design document, detailed design document,
Code or Programs, test plan and test reports and installation
manual etc.
 Iterative Waterfall Model
• Iterative Waterfall Model
– In a practical software development project, the
classical waterfall model is hard to use.
– The classical waterfall model is an idealistic model.
– In this context, 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.
• The feedback paths allow for correcting errors committed by a
programmer during some phase, as and when these are detected in a
later phase.
• 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.
• Please notice that in the Figure 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 easily due to legal and
moral reasons.
In Iterative Waterfall Model, there is feedback for every stage EXCEPT FEASIBILITY
STUDY AS ONCE THE PROJECT IS ACCEPTED TO BE UNDERTAKEN, IT IS USUALLY NOT
GIVEN UP.

Almost every life cycle model that we discuss are iterative in nature, except
the classical waterfall model and the V-model—which are sequential in
nature. In a sequential model, once a phase is complete, no work product of
that phase are changed later.
 Disadvantages of iterative waterfall Model
• Requirements need to be frozen before the development starts.
• Accommodating change requests are not possible.
• Model is inflexible as changes are sure to be made at later
stages.
• Incremental delivery not supported.
• 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.
• Error 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.
• Limited 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.
• Heavy weight:
– The waterfall model over emphasizes 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.
• 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.
– Please recollect that software services types of projects usually
involve significant reuse.
• Incremental delivery not supported: In the iterative waterfall
model, the incremental delivery is not supported.

Phase 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 the following
Figure .
 What is phase containment?
– No matter how careful a programmer may be, he
might end up committing some mistake or other
while carrying out a life cycle activity.
– These mistakes result in errors (also called faults
or bugs ) in the work product.
– It is advantageous to detect these errors in the
same phase in which they take place, since early
detection of bugs reduces the effort and time
required for correcting those.
• For example
– If a design problem is detected in the design phase
itself, then the problem can be taken care of much
more easily than if the error is identified, say, at the
end of the testing phase.
– In the later case, it would be necessary not only to
rework the design, but also to appropriately redo the
relevant coding as well as the testing activities, thereby
incurring higher cost.
– It may not always be possible to detect all the errors in
the same phase in which they are made. Nevertheless,
the errors should be detected as early as possible.
• For achieving phase containment of errors, how
can the developers detect almost all error that
they commit in the same phase?
– After all, the end product of many phases are text or
graphical documents, e.g. SRS document, design
document, test plan document, etc.
– A popular technique is to rigorously review the
documents produced at the end of a phase.
• V-Model
– V-model is a popular development process model.
– It 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 2.5). It is also
called verification and validation model.
– In this model verification and validation activities are carried
out throughout the development life cycle, and therefore
the chances of bugs being there in the 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.
• There are 2 main phases-the left side shows development phases and the right side
shows 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 – requirement analysis and specification, design,
and coding respectively.
Fig: 2.5 V - MODEL
• 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.

• V-Model - Verification Phases

• 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 we have the clear and detailed product requirements, it is time to design the complete system.
– The system design will have the understanding and detailing of 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
• 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 versus waterfall model
– 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 2.5, 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
– 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 utilisation.
 – 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 artefacts, 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.
• DISADVANTAGE:
– 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.
– The shortcut implementation of a function, for example,
may produce the desired results by using a look-up table
rather than by performing the actual computations.
– Normally the term rapid prototyping is used when
software tools are used for prototype construction.
– For example, tools based on fourth generation languages
(4GL) may be used to construct the prototype for the
GUI parts.
• Necessity of the prototyping model
The prototyping model is advantageous to use for 2
specific types of projects.
– 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.
– The GUI part of a software system is almost always
developed using the prototyping model.
– The 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.
– For example, consider a situation where the development team
has to write a command language interpreter as part of a
graphical user interface development. Suppose none of the team
members has ever written a compiler before.
– Then, this lack of familiarity with a required development
technology is a technical risk. In such situations prototyping is
useful
– This risk can be resolved by developing a prototype
compiler for a very small language to understand the
issues associated with writing a compiler for a command
language.
– Once they feel confident in writing compiler for the small
language, they can use this knowledge to develop the
compiler for the command language.
– 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.
• An important reason for developing a prototype is that it is impossible
to “get it right” the first time.
• As advocated by Brooks [1975], one must plan to throw away the software
in order to develop a good software later.
• Thus, the prototyping model can be deployed when development of
highly optimised and efficient software is required.
• Life cycle activities of prototyping model
As shown in Figure 2.6, software is developed through two
major activities—
– prototype construction and
– iterative waterfall-based software development.
• 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.

.
• Iterative 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 invaluable for carrying out traceability analysis,
verification, and test case design during later phases.
– The requirements also should be decided upon at the
beginning.
– However, for GUI parts, the requirements analysis and
specification phase becomes redundant since the working
prototype that has been approved by the customer serves as
an animated requirements specification.
– 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
• Strengths of the prototyping model
 This model is the most appropriate for projects that suffer from technical
and requirements 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.
• Incremental Development Model/Successive
Versions 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 realised. The incremental development model has been shown
in Figure.
•
• 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. This has been pictorially depicted in Figure 2.7.
– At any time, plan is made only for the next increment and no long-term
plans are 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. The incremental model is schematically shown in
Figure 2.8.
• 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 organisation from deploying
large resources and manpower for a project in one go.
• Evolutionary Model
– This model has many of the features of the incremental model.
– As in case of the incremental model, the software is developed over a number
of increments.
– At each increment, a concept (feature) is implemented and is deployed at the
client site.
– The software is successively refined and feature-enriched until the full
software is realised.
– The principal idea behind the evolutionary life cycle model is conveyed by its
name.
– In the incremental development model, complete requirements are first
developed and the SRS document prepared. Later, the product is developed in
increments;
– In contrast, in the evolutionary model, the requirements, plan, estimates, and
solution evolve over the iterations, rather than fully defined and frozen in a
major up-front specification effort before the development iterations begin.
– Such evolution is consistent with the pattern of unpredictable feature
discovery and feature changes that take place in new product development.
– Though the evolutionary model can also be viewed as an
extension of the waterfall model.
– But it incorporates a major paradigm shift that has been
widely adopted in many recent life cycle models.
– Due to obvious reasons, the evolutionary software
development process is sometimes referred to as design
a little, build a little, test a little, deploy a little model.
– This means that after the requirements have been
specified, the design, build, test, and deployment
activities are iterated.
– A schematic representation of the evolutionary model of
development has been shown in Figure 2.9.
• Advantages
• The evolutionary model of development has several advantages. Two
important advantages of using this model are the following:

– Effective elicitation of actual customer requirements:

• In this model, the user gets a chance to experiment with a partially
developed software much before the complete requirements are
developed.
• Therefore, the evolutionary model helps to accurately elicit user
requirements with the help of feedback obtained on the delivery of
different versions of the software.
• As a result, the change requests after delivery of the complete software
gets substantially reduced.
– Easy handling change requests:
• In this model, handling change requests is easier as no long term plans are
made.
• Consequently, reworks required due to change requests are normally much
smaller compared to the sequential models.
 Disadvantages
• Feature division into incremental parts can be non-trivial:
– For many development projects, especially for small-sized projects, it is
difficult to divide the required features into several parts that can be
incrementally implemented and delivered.
– Further, even for larger problems, often the features are so dependent on each
other that even an expert would need considerable effort to plan the
incremental deliveries.
• Ad hoc design:
– Since at a time design for only the current increment is done, the design can
become ad hoc without specific attention being paid to maintainability and
optimality.
– Obviously, for moderate sized problems and for those for which the customer
requirements are clear, the iterative waterfall model can yield a better solution.
• Applicability of the evolutionary model
– The evolutionary model is normally useful for very large
products, where it is easier to find modules for incremental
implementation.
– Often evolutionary model is used when the customer prefers to
receive the product in increments so that he can start using the
different features as and when they are delivered rather than
waiting all the time for the full product to be developed and
delivered.
– Another important category of projects for which the
evolutionary model is suitable, is projects using object-oriented
development.
– Evolutionary model is appropriate for object-oriented
development project, since it is easy to partition the software
into stand alone units in terms of the classes.
– Also, classes are more or less self contained units that can be
developed independently.
• Rapid Action Development (RAD) Model
 This model was proposed in the early nineties in an attempt to overcome the
rigidity of the waterfall model (and its derivatives) that makes it difficult to
accommodate any change requests from the customer.
 It proposed a few radical extensions to the waterfall model.
 This model has the features of prototyping and evolutionary models.
 It deploys an evolutionary delivery model to obtain and incorporate the
customer feedbacks on incrementally delivered versions.
 But unlike the prototyping model, the prototypes are not thrown away but
are enhanced and used in the software construction
• The major goals of the RAD model are as follows:
 To decrease the time taken and the cost incurred to develop software systems.
 To limit the costs of accommodating change requests.
 To reduce the communication gap between the customer and the developers
• Main motivation
– In the iterative waterfall model, the customer requirements need to be
gathered, analysed, documented, and signed off upfront, before any
development could start. However, often clients do not know what
they exactly wanted until they saw a working system.
– In the iterative waterfall model, the customers do not get to see the
software, until the development is complete in all respects and the
software has been delivered and installed.
– Naturally, the delivered software often does not meet the customer
expectations and many change request are generated by the customer.
– The changes are incorporated through subsequent maintenance
efforts. This made the cost of accommodating the changes extremely
high and it usually took a long time to have a good solution in place
that could reasonably meet the requirements of the customers.
– The RAD model tries to overcome this problem by inviting and
incorporating customer feedback on successively developed and
refined prototypes.
• Working of RAD
• In the RAD model, development takes place in a series of short cycles or
iterations.
• At any time, the development team focuses on the present iteration
only, and therefore plans are made for one increment at a time.
• The time planned for each iteration is called a time box.
• Each iteration is planned to enhance the implemented functionality of the
application by only a small amount.
• During each time box, a quick-and-dirty prototype-style software for some
functionality is developed.
• The customer evaluates the prototype and gives feedback on the specific
improvements that may be necessary.
• The prototype is refined based on the customer feedback. Please note that the
prototype is not meant to be released to the customer for regular use though.
• The development team almost always includes a customer representative
to clarify the requirements. This is intended to make the system tuned to the exact
customer requirements and also to bridge the communication gap
between the customer and the development team.
• The development team usually consists of about five to six members, including a
customer representative.
• RAD model is Rapid Application Development
model.
– It is a type of incremental model.
– In RAD model the components or functions are
developed in parallel as if they were mini projects.
– The developments are time boxed, delivered and then
assembled into a working prototype. 
– This can quickly give the customer something to see and
use and to provide feedback regarding the delivery and
their requirements.
• The phases in the rapid application development (RAD) model are:

• Business modeling:
– The information flow is identified between various business functions.
• Data modeling:
– Information gathered from business modeling is used to define data objects that are
needed for the business.
• Process modeling:
– Data objects defined in data modeling are converted to achieve the business
information flow to achieve some specific business objective.
– Description are identified and created for CRUD of data objects.
• Application generation:
– Automated tools are used to convert process models into code and the actual
system.
• Testing and turnover:
– Test new components and all the interfaces.
• Advantages of the RAD model:
• Reduced development time.
• Increases reusability of components
• Quick initial reviews occur
• Encourages customer feedback
• Integration from very beginning solves a lot of 
integration issues.
• Disadvantages of RAD model:
• Depends on strong team and individual performances for
identifying business requirements.
• Only system that can be modularized can be built using RAD
• Requires highly skilled developers/designers.
• High dependency on modeling skills
• Inapplicable to cheaper projects as cost of modeling and
automated code generation is very high.
 
• When to use RAD model:
• RAD should be used when there is a need to create a
system that can be modularized in 2-3 months of time.
• It should be used if there’s high availability of
designers for modeling and the budget is high enough
to afford their cost along with the cost of automated
code generating tools.
• RAD SDLC model should be chosen only if resources
with high business knowledge are available and there
is a need to produce the system in a short span of
time (2-3 months).
 Agile Model
• Please note that agile model is being used as an umbrella term to refer
to a group of development processes. These processes share certain
common characteristics, but do have certain subtle differences among
themselves. A few popular agile SDLC models are the following:

• Crystal
• Atern (formerly DSDM)
• Feature-driven development
• Scrum
• Extreme programming (XP)
• Lean development
• Unified process
• In the agile model, the requirements are decomposed into many small
parts that can be incrementally developed.
• The agile model adopts an iterative approach. Each incremental part is
developed over an iteration. Each iteration is intended to be small and easily
manageable and lasting for a couple of weeks only. At a time, only one
increment is planned, developed, and then deployed at the customer site.
• No long-term plans are made. The time to complete an iteration is called a
time box. The implication of the term time box is that the end date for an
iteration does not change. That is, the delivery date is considered sacrosanct.
• The development team can, however, decide to reduce the delivered
functionality during a time box if necessary.
• A central principle of the agile model is the delivery of an increment to the
customer after each time box.
• Agile models are incremental models which are developed over an iteration
in a time-box.
 SPIRAL MODEL
• Refer to slides of SPIRAL MODEL in SDLC
Process Models Part 2.
• Important question: Why is Spiral Model
called Metamodel?
• Why Spiral Model is called evolutionary
approach?
• 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 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.
• The spiral model incorporates the systematic step- wise approach of the
waterfall model.
• 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)
• The classical waterfall model can be considered as the basic model and
all other life cycle models are embellishments of this model.
• Iterative waterfall model has been the most widely used life cycle model
so far, though the usage of RAD and agile models have been increasing.

• Different life cycle models have their own advantages and

disadvantages. Therefore, an appropriate life cycle model should be
chosen for the problem at hand. After choosing a basic life cycle model,
software development organisations usually tailor the standard life cycle
models according to their needs.

• Even though an organisation may follow whichever life cycle model is

appropriate to a project, the final document should reflect as if the
software was developed using the classical waterfall model. This makes it
easier for the maintainers to understand the software
documents
• The Spiral model is evolutionary model as it is
iterative 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)
The implementation phase in the waterfall model is a synonym for
which one of the following phases:
(i) Coding and unit testing phase
(ii) Integration and system testing phase
(iii) Maintenance phase
(iv) Design phase
Ans: (i) Coding and unit testing Phase
• The operation phase in the waterfall model is a synonym for which
one of the following phases:
(i) Coding and unit testing phase
(ii) Integration and system testing phase
(iii) Maintenance phase
(iv) Design phase
• Unit testing is carried out in which phase of the waterfall model:
(i) Implementation phase
(ii) Testing phase
(iii) Maintenance phase
(iv) Design phase
• Which one of the following phases accounts for the the maximum
effort during development of a typical software?
(i) Coding
(ii) Testing
(iii) Designing
(iv) Specification
(i) Which of the following is not a standard software development
process model?
(i) Waterfall Model
(ii) Watershed Model
(iii) RAD Model
• (j) Which one of the following feedback paths is not present
in an iterative waterfall model?
(i) Design phase to feasibility study phase
(ii) Implementation phase to design phase
(iii) Implementation phase to requirements specification
phase
(iv) Design phase to requirements specification phase
(k) Which one of the following is a suitable SDLC model for
developing a moderate- sized software for which the
customer is not clear about his exact requirements?
(i) RAD model
(ii) V-model
(iii) Iterative waterfall model
(iv) Classical waterfall model