See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/220631422

Software development lifecycle models

Article  in  ACM SIGSOFT Software Engineering Notes · May 2010

DOI: 10.1145/1764810.1764814 · Source: DBLP

CITATIONS READS
113 40,399

1 author:

Nayan Ruparelia
Hewlett Packard Enterprise
3 PUBLICATIONS   126 CITATIONS   

SEE PROFILE

All content following this page was uploaded by Nayan Ruparelia on 15 November 2014.

The user has requested enhancement of the downloaded file.

ACM SIGSOFT Software Engineering Notes Page 8 May 2010 Volume 35 Number 3

SDLC, then, is a conceptual framework or process that consid-

ers the structure of the stages involved in the development of an
application from its initial feasibility study through to its deploy-
ment in the field and maintenance. There are several models that
describe various approaches to the SDLC process. An SDLC
model is generally used to describe the steps that are followed
within the life-cycle framework.
It is necessary to bear in mind that a model is different from a
methodology in the sense that the former describes what to do
whereas the latter, in addition, describes how to do it. So a model
is descriptive whilst a methodology is prescriptive. As a result,
we consider SDLC models in this article in terms of their relev-
ance to particular types of software projects. This approach re-
cognizes the context in which a SDLC model is used. For
example, the waterfall model may be the best model to use when
developing an enterprise relational database but it may not be the
optimum model when developing a web-based application. I
therefore consider the models for three distinct use cases, or soft-
ware categories, in order to provide a context for their applica-
tion, as follows:
Software Development Lifecycle Category 1. Software that provides back-end functionality.
Models Typically, this is software that provides a service to
Nayan B. Ruparelia other applications.
Hewlett-Packard Enterprise Services Category 2. Software that provides a service to an end-user or to
< [email protected] > an end-user application. Typically, this would be
DOI: 10.1145/1764810.1764814 software that encapsulates business logic or formats
http://doi.acm.org/10.1145/1764810.1764814 data to make it more understandable to an end-user.
Category 3. Software that provides a visual interface to an end-
Abstract user. Typically, this is a front-end application that is a
graphical user interface (GUI).
This history column article provides a tour of the main soft- SDLC models, also, may be categorized as falling under three
ware development life cycle (SDLC) models. (A lifecycle covers broad groups: linear, iterative and a combination of linear and
all the stages of software from its inception with requirements iterative models. A linear model is a sequential one where one
definition through to fielding and maintenance.) System devel- stage, upon its completion, irrevocably leads to the initiation of
opment lifecycle models have drawn heavily on software and so the next stage. An iterative model, on the other hand, ensures that
the two terms can be used interchangeably in terms of SDLC, all the stages of the model shall be revisited in future; the idea
especially since software development in this respect encom- being that development remains a constant endeavor for im-
passes software systems development. Because the merits of se- provement throughout its lifecycle. A combined model recognizes
lecting and using an SDLC vary according to the environment in that the iterative development process can be halted at a certain
which software is developed as well as its application, I discuss stage.
three broad categories for consideration when analyzing the rela- Although there is an abundance of SDLC models in existence,
tive merits of SDLC models. I consider the waterfall model be- we shall consider the most important ones or those that have
fore the other models because it has had a profound effect on gained popularity. These include: the waterfall, spiral, unified,
software development, and has additionally influenced many incrementing, rapid application development, the v and the w
SDLC models prevalent today. Thereafter, I consider some of the models.
mainstream models and finish with a discussion of what the fu-
ture could hold for SDLC models. Waterfall Model
Keywords: SDLC, SEN History Column, Waterfall, Spiral, The waterfall model, also known as the cascade model, was
Wheel-and-spoke, Unified, RAD, Incremental, B-model, V- first documented by Benington [1] in 1956 and modified by
model. Winston Royce [2] in 1970. It has underpinned all other models
Introduction since it created a firm foundation for requirements to be defined
SDLC is an acronym that is used to describe either software or and analyzed prior to any design or development.
systems development life-cycles. Although the concepts between The original cascade model of Bennington recommended that
the two are the same, one refers to the life-cycle of software whe- software be developed in stages: operational analysis ĺ RSHU a-
reas the other to that of a system that encompasses software de- tional specification ĺGHVLJQ and coding specifications ĺGHYH l-
velopment. In this article, software development is emphasized opment ĺ WHVWLQJ ĺ GHSOR\PHQW ĺ HYDOXDWLRQ %\ UHFRJQL]LQJ
although the same principles can be transmuted to systems. Also, that there could be unforeseen design difficulties when a baseline
most of the innovation and thought leadership in terms of devis- is created at the end of each stage, Royce enhanced this model by
ing models and concepts has come from software development, providing a feedback loop so that each preceding stage could be
and systems development has borrowed heavily from software revisited. This iteration is shown in Figure 1 using red arrows for
development as a result.
ACM SIGSOFT Software Engineering Notes Page 9 May 2010 Volume 35 Number 3

the process flow; this allowed for the stages to overlap in addition The waterfall model is the most efficient way for creating
to the preceding stage to be revisited. But Royce also felt that this software in category 1 discussed earlier. Examples for this would
arrangement could prove inadequate since the iteration may need be relational databases, compilers or secure operating systems.
to transcend the succeeding-preceding stage pair’s iteration. This
would be the case at the end of the evaluation (or testing) stage B-Model
when you may need to iterate to the design stage bypassing the In 1988, Birrell and Ould discussed an extension to the water-
development stage or at the end of the design stage where you fall model that they called the b-model [3]. By extending the op-
may need to revisit the requirements definition stage bypassing erational life-cycle (denoted as the maintenance cycle) and then
the analysis stage. That way, the design and the requirements, attaching it to the waterfall model, they devised the b-model as
respectively, are redefined should the testing or the design war- shown in Figure 2. This was done to ensure that constant im-
rant. This is illustrated in Figure 1 by the dashed arrows that show provement of the software or system would become part of the
a more complex feedback loop. Further, Royce suggested that a development stages. Also, they felt that an alternative to obsoles-
preliminary design stage could be inserted between the require- cence needed to be captured so that enhanced or even newer sys-
ments and analysis stages. He felt that this would address the cen- tems could be developed as spin-offs from the initial system.
tral role that the design phase plays in minimizing risks by being
re-visited several times as the complex feedback loop of Figure 1
shows.

Figure 1: Waterfall model with Royce’s iterative feedback.

When referring to the waterfall model in this article, I shall
mean Royce’s modified version of Benington’s cascade model.
One aspect of the waterfall model is its requirement for docu-
mentation. Royce suggested that at least six distinct types of doc-
ument be produced:
1) Requirements document during the requirements stage.
2) Preliminary design specification during the preliminary
design stage.
3) Interface design specification during the design stage. Figure 2: The b-model extends the waterfall model.
4) Final design specification that is actively revised and up- In a sense, the b-model was an attempt to modify the waterfall
dated over each visit of the design stage; this is further up- by creating an evolutionary enhancement process that was cap-
dated during the development and validation stages. tured by the spiral model that we shall discuss later. The b-model,
5) Test plan during the design stage; this is later updated however, is more suitable to the development of category 1 soft-
with test results during the validation or testing stage. ware like its cousin, the waterfall.
6) Operations manual or instructions during the deployment
stage. Incremental Model
Quality assurance is built into the waterfall model by splitting The incremental model, also known as the iterative waterfall
each stage in two parts: one part performs the work as the stage’s model, can be viewed as a three dimensional representation of the
name suggests and the other validates or verifies it. For instance, waterfall model. The z-axis contains a series of waterfall models
the design stage incorporates verification (to assess whether it is to represent the number of iterations that would be made in order
fit for purpose), the development stage has unit and integration to improve the functionality of the end product incrementally.
testing, and the validation stage contains system testing as its part The incremental model, in this sense, is a modification to the wa-
and parcel. terfall that approaches the spiral model.
ACM SIGSOFT Software Engineering Notes Page 10 May 2010 Volume 35 Number 3

The main strengths of this model are: the spiral model adds user involvement during its risk reduction
i. Feedback from earlier iterations can be incorporated in activities whereas the v and the waterfall models incorporate it
the current iteration. during the initial requirements definition phase. Additionally, the
ii. Stakeholders can be involved through the iterations, and risks and opportunities feature of the vee+ mean that certain stag-
so helps to identify architectural risks earlier. es of the v at the lower decomposition levels could be truncated in
iii. Facilitates delivery of the product with early, incremental order to integrate COTS (commercial, off-the-shelf software)
releases that evolve to a complete feature-set with each packages [6]. This means that varying levels of products, at dif-
iteration. ferent levels of decomposition, can be added to the life cycle in a
iv. Incremental implementation enables changes to be seamless manner.
monitored, and issues to be isolated and resolved to Another variation of the v-model is the vee++ model [6] that
mitigate risks. adds intersecting processes to the vee+ model; a decomposition
analysis and resolution process is added to the left leg of the v
V-Model shape, and a verification analysis and decomposition process is
The v-model, also known as the vee model, first presented at added to the right one.
the 1991 NCOSE symposium in Chattanooga, Tennessee [4], was Like the waterfall, the v-model is more suited to category 1
developed by NASA. The model is a variation of the waterfall systems; the creators modified the model to the vee+ for catego-
model in a V shape folded in half at the lowest level of decompo- ries 1 and 3, and thereafter created the vee++ model for all cate-
sition, as Figure 3 shows. The left leg of the V shape represents gories. However, a key strength of the v-model is that it can be
the evolution of user requirements into ever smaller components used in very large projects where a number of different contrac-
through the process of decomposition and definition; the right leg tors, sub-contractors and teams are involved; decomposition, in-
represents the integration and verification of the system compo- tegration and verification at each stage with all the parties
nents into successive levels of implementation and assembly. The involved is made possible by the v-model prior to progressing to
vertical axis depicts the level of decomposition from the system the next stage. This factor is acknowledged by the time parameter
level, at the top, to the lowest level of detail at component level atbeing represented by the y and z axes of the model. Thus, a large
the bottom. Thus, the more complex a system is the deeper the V number of parties and stakeholders in a very large project become
shape with correspondingly larger number of stages. The v- inherently integrated using a requirements-driven approach.
model, being three-dimensional, also has an axis that is normal to
the plane, the z-axis. This represents components associated with Spiral Model
multiple deliveries. Time is therefore represented by two axes: Boehm modified the waterfall model in 1986 [7] by introduc-
from left to right and into the plane. ing several iterations that spiral out from small beginnings. An
oft- quoted idiom describing the philosophy underlying the spiral
method is start small, think big.

Figure 3: V-model's built-in quality assurance.

The v-model is symmetrical across the two legs so that the ve-
rification and quality assurance procedures are defined for the
right leg during the corresponding stage of the left leg. This en-
sures that the requirements and the design are verifiable in a
SMART (Specific, Measurable, Achievable, Realistic and Time-
bound) [5] manner, thus avoiding statements such as “user friend-
ly,” which is a valid but non-verifiable requirement. Figure 4: Boehm's spiral life-cycle.
A variation of the v-model is the vee+ model. This adds user The spiral model attempts to address two main difficulties of
involvement, risks and opportunities to the z-axis of the v-model. the waterfall model:
Thus, users remain involved until the decompositions are of no i. the two design stages can be unnecessary in some
interest to them. An application of this is that any anomalies iden- situations,
tified during the integration and assembly stages are fed to the ii. the top-down approach needs to be tempered with a look-
user for acceptance or, in the case of rejection, to be resolved at ahead step in order to account for software reusability or
the appropriate levels of decomposition; the anomalies could then the identification of risks and issues at an early stage.
be resolved as errors or accepted as design features. In contrast, The spiral model represents a paradigm shift from the water-
ACM SIGSOFT Software Engineering Notes Page 11 May 2010 Volume 35 Number 3

fall’s specification driven approach to a risk-driven one. Each management, quite flexible contract mechanisms between the
cycle traverses four quadrants, as illustrated by Figure 4. These stakeholders and between each cycle of the spiral, and it relies
are: heavily on the systems designers’ ability to identify risks correct-
i. Determine objectives. ly for the forthcoming cycle.
ii. Evaluate alternatives, and identify and resolve risks.
iii. Develop and test. Wheel-and-spoke Model
iv. Plan the next iteration. The wheel-and-spoke model is based on the spiral model and
As each cycle within the spiral progresses, a prototype is built, is designed to work with smaller teams initially, which then scale
verified against its requirements and validated through testing. up to build value faster. It is a bottom-up approach that retains
Prior to this, risks are identified and analyzed in order to manage most of the elements of the spiral model by comprising of mul-
them. The risks are then categorized as performance (or user- tiple iterations.
interface) related risks or development risks. If development risks First, system requirements are established and a preliminary
predominate, then the next step follows the incremental waterfall design is created. Thereafter, a prototype is created during the
approach. On the other hand, if performance risks predominate, implementation stage. This is then verified against the require-
then the next step is to follow the spiral through to the next evolu- ments to form the first spoke of the model. Feedback is propagat-
tionary development. This ensures that the prototype produced in ed back to the development cycle and the next stage adds value to
the second quadrant has minimal risks associated with it. create a more refined prototype. This is evaluated against the re-
Risk management is used to determine the amount of time and quirements and feedback is propagated back to the cycle; this
effort to be expended for all activities during the cycle, such as forms the second spoke. Each successive stage goes through a
planning, project management, configuration management, quali- similar verification process to form a spoke. The wheel represents
ty assurance, formal verification and testing. Hence, risk man- the iteration of the development cycle.
agement is used as a tool to control the costs of each cycle. The wheel-and-spoke model has many uses. It can be used to
An important feature of the spiral model is the review that create a set of programs that are related by a common API. The
takes place as part of the y-axis of Figure 4. This process occurs common API then forms the center of the model with each pro-
at the completion of each cycle and covers all of the products and gram verifying its conformance to the API (this in essence forms
artifacts produced during the previous cycle including the plans a common set of requirements) at each spoke. Another applica-
for the next cycle as well as the resources required for it. A pri- tion of this model is with the Architecture Development Method
mary objective of the review process is to ensure that stakehold- (ADM) of The Open Group Architecture Framework (TOGAF)
ers are committed to the approach to be taken during the next [9] where the spokes are used to validate the requirements during
cycle. the development of the architecture, as Figure 5 shows.
A set of fundamental questions arise about the spiral model: Like the spiral, it is more amenable to category 1 and 2 use
i. How does the spiral get started? cases.
ii. How and when do you get off the spiral?
iii. How does system enhancement or maintenance occur?
Boehm’s response to these questions was to use a complemen-
tary model that he called the Mission Opportunity Model (MOM)
[7]. Using the MOM as a central pivot, the operational mission is
assessed at key junctures as to whether further development or
effort should be expended. This is done by testing the spiral
against a set of hypotheses (requirements) at any given time; fail-
ure to meet those hypotheses leads to the spiral being terminated.
To initiate the spiral, however, the same process is followed using
the MOM.
In 1987, Iivari suggested a modification to the spiral model in
the January issue of this publication [8] that he called the hierar-
chical spiral model. He proposed to sub-divide each quadrant of
the spiral into two parts to allow for sub-phases. With this ap-
proach, he provisioned for baselines and milestones to be created
for each cycle in order to have greater control for that cycle. Also,
he suggested that the main phases be risk-driven, as with the spir-
al, but the sub-phases should be specification or process driven as
in the case of the waterfall. This combination of the risk-
specification paradigms would make the hierarchical spiral model
cost conscious (like the spiral) as well as disciplined (like the wa-
terfall).
A key benefit of the spiral model is that it attempts to contain
project risks and costs at the outset. Its key application is for the
category 1 use case. However, sufficient control of the cycles
could make it adoptable for the other categories as well. The main
difficulty of the spiral is that it requires very adaptive project Figure 5: TOGAF's ADM as a wheel-and-spoke model.
ACM SIGSOFT Software Engineering Notes Page 12 May 2010 Volume 35 Number 3

As Figure 6 shows, RUP has four phases: the inception, elabo-

Unified Process Model ration, construction and transition phases. Each phase may com-
Whereas the waterfall is specification driven and the spiral is prise of any number of iterations by engaging with six core
risk driven, the unified process model is model (or architecture) disciplines (shown horizontally in the figure). These disciplines
based and use case driven [10]; at the same time, it is iterative in are supported by three other disciplines: change and configuration
nature. management, project management, and environment.
The unified model was created to address the specific devel- Although more suitable for the category 2 and 3 applications,
opment requirements of object-oriented software and its design. A RUP could be adapted for mid-scale category 1 applications pro-
descendent of the Objectory model, it was developed in the 1990s vided that risk and contractual links are well managed. However,
by Rational Software; it is therefore commonly known as the Ra- for very large system development, RUP would not be the ideal
tional Unified Process (RUP) model. IBM acquired Rational model to use because of its model-based and use-case driven ap-
Software in 2003 and continues to develop and market the proach. The iterative waterfall, the V-model (including its cou-
process as part of various software development toolsets. sins, vee+ and vee++), and the spiral models would be more
RUP encapsulates seven best practices within the model: suitable. At the other extreme, for very small projects, RUP could
i. Develop iteratively using risk management to drive the be used provided that the number and type of artifacts are opti-
iterations. mized to the minimum required for rapid development.
ii. Manage requirements.
iii. Employ a component-based architecture. Rapid Application Development
iv. Use visual models. Principally developed by James Martin in 1991, Rapid Appli-
v. Verify quality continuously. cation Development (RAD) is a methodology that uses prototyp-
vi. Control changes. ing as a mechanism, as per Figure 7, for iterative development.
vii. Use customization.

Figure 7: Prototyping approach used by RAD.

RAD promotes a collaborative atmosphere where business
stakeholders participate actively in prototyping, creating test cas-
es and performing unit tests. Decision making is devolved away
from a centralized structure (usually comprising of the project
manager and developers) to the functional team.
The open source software development model (also known as
the Cathedral and the Bazaar model that was first documented by
Figure 6: Unified process model. Raymond [11]), espousing a ‘release early; release often; listen
RUP uses models extensively and these are described using the to your customers’ philosophy, is quite similar to RAD and some
Unified Modeling Language (UML), which comprises of a collec- of its spin-off methodologies such as Agile.
tion of semi-formal graphical notations and has become the stan- Recently, RAD has come to be used in a broader, generic
dard tool for object-oriented modeling. It facilitates the sense that encompasses a variety of techniques aimed at speeding
construction of several views of a software system, and supports software development. Of these, five prominent approaches are
both static and dynamic modeling. The notations include use case, discussed below in alphabetical order.
activity, class, object, interaction and state diagrams amongst oth-
ers. Use cases are central to RUP because they lay the foundation Agile
for subsequent development. They provide a functional view by Scope changes, as well as feature creep, are avoided by break-
modeling the way users interact with the system. Each use case ing a project into smaller sub-projects. Development occurs in
describes a single use of the system, and provides a set of high- short intervals and software releases are made to capture small
level requirements for it. Moreover, use cases drive the design, incremental changes.
implementation and testing (indeed, the entire development Applying Agile to large projects can be problematic because it
process) of the software system. emphasizes real-time communication, preferably on a personal,
RUP is iterative and incremental as it repeats over a series of face-to-face basis. Also, Agile methods produce little documenta-
iterations that make up the life cycle of a system. An iteration tion during development (requiring a significant amount of post-
occurs during a phase and consists of one pass through the re- project documentation) whilst de-emphasizing a formal process-
quirements, analysis, design, implementation and test workflows driven steps. Thus, it is more suited to a Category 3 application.
(based on disciplines), building a series of UML models that are
inter-related.
ACM SIGSOFT Software Engineering Notes Page 13 May 2010 Volume 35 Number 3

compared easily without considering their particular category of

Extreme Programming (XP) application.
With XP, development takes place incrementally and on the Second, a repository containing lessons learned will enable
fly with a business champion acting as a conduit for user-driven key parameters to be distilled from the model and a statistical
requirements and functionality; there is not an initial design stage.
analysis to be performed on their use and efficacy in various cate-
(This could lead to higher costs later when new, incompatible, gories of projects. Also, parameters for comparison could include
requirements surface.) In order to lower costs, new requirements non-functional attributes such as risks and costs at each stage.
are accounted for in short, fast spiral steps and development takesThis will provide us with a better foundation with which to make
place with programmers working in pairs. decisions since the lessons learned analysis will be something that
comes from experience on the ground rather than just theory.
Joint Application Development (JAD) Perhaps the ACM could host such a lessons learned wiki and a
JAD advocates collaborative development with the end user or back-end statistical analysis engine. This can be applied beyond
customer by involving him during the design and development SDLCs and encompass a wide range of techniques and technolo-
phases through workshops (known as JAD sessions). This has the gies.
possibility of creating scope creep in a project if the customer’s
requirements are not managed well. References
[1] Benington, H.D. (1956): Production of large computer programs. In Pro-
ceedings, ONR Symposium on Advanced Programming Methods for Digital Com-
Lean Development (LD) puters, June 1956, pp 15-27.
In pursuance to the paradigm ‘80% today is better than 100% [2] Royce, Winston W. (1970): Managing the development of large software
tomorrow’, Lean Development attempts to deliver a project early systems. In Proceedings, IEEE Wescon, August 1970, pp 1-9.
with a minimal functionality. [3] Birrell, N. D. and Ould, M.A. (1988): A practical handbook to software
development; Cambridge University Press. ISBN 978-0521347921. pp 3-12.
[4] Forsberg, Kevin and Mooz, Harold (1991): The relationship of system en-
Scrum gineering to the project cycle. At NCOSE, Chattanooga, Tennessee, October 21-
Development takes place over a series of short iterations, or 23, 1991.
sprints, and progress is measured daily. Scrum is more suited to [5] Doran, George T. (1981): There's a S.M.A.R.T. way to write manage-
ment’s goals and objectives. In Management Review, vol. 70.11.
small projects because it places less emphasis on a process driven [6] Mooz, H and Forsberg, K. (2001): A visual explanation of the develop-
framework (needed on large projects) and also the central com- ment methods and strategies including the waterfall, spiral, vee, vee+, and vee++
mand structure can cause power struggles in large teams. models, pp 4-6.
RAD, as well as its affiliated methodologies described above, [7] Boehm, Barry W. (1986): A spiral model of software development and
enhancement. In ACM SigSoft Software Engineering Notes, Vol. II, No. 4, 1986,
is generally much less suited to Category 1 and 2 applications and pp 22-42.
much more suited to Category 3 applications because of its em- [8] Iivari, Juhani (1987): A hierarchical spiral model for the software process:
phasis on less formal, process independent approaches. notes on Boehm’s spiral model. In ACM SIGSOFT Software Engineering Notes,
vol. 12, no. 1, January 1, 1987. Pp 35-37.
[9] TOGAF 9:The Open Group; http://www.opengroup.org/togaf/.
The Future [10] Jacobson I., Booch G. & Rumbaugh J. (1999): The unified software de-
This history column invariably ends with a consideration of velopment process; Addison-Wesley, Reading, Massachusetts.
the future; history’s importance is in creating a framework for the [11] Raymond, Eric (2001): Cathedral and the Bazaar, 1st Edition; O'Reilly
future. Although in the past software development has influenced Media; ISBN: 978-0596001087.
systems design in an inordinate way, there should be a fusion of
knowledge sharing between the two in both directions in future.
Moreover, SDLC models for both disciplines can draw from do-
mains outside their technological boundaries. A large amount of
work has been done in other spheres such as behavior analysis,
time management, and business management (the Japanese Kan-
ban or Just-In-Time model, for example) that could be borrowed
by future SDLC models. To some extent, this is already happen-
ing with some models. For example, the Behavior Driven Devel-
opment technique (facilitates collaboration between various
participants) that is part of the Agile model has drawn from beha-
vior analysis. This sharing of ideas from disparate sources to in-
corporate them in an SDLC model should gather momentum in
future.
Since there is a proliferation of SDLC models, it would be
good to have a central repository, perhaps hosted on a wiki, where
various experiences could be shared. This will fulfill two purpos-
es.
First, the insatiable desire to compare models will be ad-
dressed. However, this should be done in the context of the appli-
cation of the SDLC, much like the three categories proffered in
this article. This is important because SDLC models cannot be

View publication stats