Software Development Life Cycle Models

I was asked to put together this high-level and traditional software
life cycle information as a favor for a friend of a friend, so I
thought I might as well share it with everybody.

The General Model

Software life cycle models describe phases of the software cycle and
the order in which those phases are executed. There are tons of
models, and many companies adopt their own, but all have very similar
patterns. The general, basic model is shown below:

General Life Cycle Model

Each phase produces deliverables required by the next phase in the
life cycle. Requirements are translated into design. Code
is produced during implementation that is driven by the design.
Testing verifies the deliverable of the implementation phase against
requirements.

Requirements

Business requirements are gathered in this phase. This phase
is the main focus of the project managers and stake holders.
Meetings with managers, stake holders and users are held in order to
determine the requirements. Who is going to use the system?
How will they use the system? What data should be input into the
system? What data should be output by the system? These are
general questions that get answered during a requirements gathering
phase. This produces a nice big list of functionality that the
system should provide, which describes functions the system should
perform, business logic that processes data, what data is stored and
used by the system, and how the user interface should work. The
overall result is the system as a whole and how it performs, not how it
is actually going to do it.

Design

The software system design is produced from the results of the
requirements phase. Architects have the ball in their court
during this phase and this is the phase in which their focus
lies. This is where the details on how the system will work is
produced. Architecture, including hardware and software,
communication, software design (UML is produced here) are all part of
the deliverables of a design phase.

Implementation

Code is produced from the deliverables of the design phase during
implementation, and this is the longest phase of the software
development life cycle. For a developer, this is the main focus
of the life cycle because this is where the code is produced.
Implementation my overlap with both the design and testing
phases. Many tools exists (CASE tools) to actually automate the
production of code using information gathered and produced during the
design phase.

Testing

During testing, the implementation is tested against the
requirements to make sure that the product is actually solving the
needs addressed and gathered during the requirements phase. Unit
tests and system/acceptance tests are done during this phase.
Unit tests act on a specific component of the system, while system
tests act on the system as a whole.

So in a nutshell, that is a very basic overview of the general
software development life cycle model. Now lets delve into some
of the traditional and widely used variations.

Waterfall Model

This is the most common and classic of life cycle models, also
referred to as a linear-sequential life cycle model. It is very
simple to understand and use. In a waterfall model, each phase
must be completed in its entirety before the next phase can
begin. At the end of each phase, a review takes place to
determine if the project is on the right path and whether or not to
continue or discard the project. Unlike what I mentioned in the
general model, phases do not overlap in a waterfall model.

Waterfall Life Cycle Model

Advantages

Simple and easy to use.

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

Phases are processed and completed one at a time.

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

Disadvantages

Adjusting scope during the life cycle can kill a project

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

High amounts of risk and uncertainty.

Poor model for complex and object-oriented projects.

Poor model for long and ongoing projects.

Poor model where requirements are at a moderate to high risk of changing.

V-Shaped Model

Just like the waterfall model, the V-Shaped life cycle is a
sequential path of execution of processes. Each phase must be
completed before the next phase begins. Testing is emphasized in
this model more so than the waterfall model though. The testing
procedures are developed early in the life cycle before any coding is
done, during each of the phases preceding implementation.

Requirements begin the life cycle model just like the waterfall
model. Before development is started, a system test plan is
created. The test plan focuses on meeting the functionality
specified in the requirements gathering.

The high-level design phase focuses on system architecture and
design. An integration test plan is created in this phase as well
in order to test the pieces of the software systems ability to work
together.

The low-level design phase is where the actual software components
are designed, and unit tests are created in this phase as well.

The implementation phase is, again, where all coding takes
place. Once coding is complete, the path of execution continues
up the right side of the V where the test plans developed earlier are
now put to use.

V-Shaped Life Cycle Model

Advantages

Simple and easy to use.

Each phase has specific deliverables.

Higher chance of success over the waterfall model due to the development of test plans early on during the life cycle.

Works well for small projects where requirements are easily understood.

Disadvantages

Very rigid, like the waterfall model.

Little flexibility and adjusting scope is difficult and expensive.

Software is developed during the implementation phase, so no early prototypes of the software are produced.

Model doesn’t provide a clear path for problems found during testing phases.

Incremental Model

The incremental model is an intuitive approach to the waterfall
model. Multiple development cycles take place here, making the
life cycle a “multi-waterfall” cycle. Cycles are divided up into
smaller, more easily managed iterations. Each iteration passes
through the requirements, design, implementation and testing phases.

A working version of software is produced during the first
iteration, so you have working software early on during the software
life cycle. Subsequent iterations build on the initial software
produced during the first iteration.

Incremental Life Cycle Model

Advantages

Generates working software quickly and early during the software life cycle.

More flexible – less costly to change scope and requirements.

Easier to test and debug during a smaller iteration.

Easier to manage risk because risky pieces are identified and handled during its iteration.

Each iteration is an easily managed milestone.

Disadvantages

Each phase of an iteration is rigid and do not overlap each other.

Problems may arise pertaining to system architecture because not
all requirements are gathered up front for the entire software life
cycle.

Spiral Model

The spiral model is similar to the incremental model, with more
emphases placed on risk analysis. The spiral model has four
phases: Planning, Risk Analysis, Engineering and Evaluation. A
software project repeatedly passes through these phases in iterations
(called Spirals in this model). The baseline spiral, starting in
the planning phase, requirements are gathered and risk is
assessed. Each subsequent spirals builds on the baseline spiral.

Requirements are gathered during the planning phase. In the
risk analysis phase, a process is undertaken to identify risk and
alternate solutions. A prototype is produced at the end of the
risk analysis phase.

Software is produced in the engineering phase, along with testing at
the end of the phase. The evaluation phase allows the customer to
evaluate the output of the project to date before the project continues
to the next spiral.

In the spiral model, the angular component represents progress, and the radius of the spiral represents cost.

Spiral Life Cycle Model

Advantages

High amount of risk analysis

Good for large and mission-critical projects.

Software is produced early in the software life cycle.

Disadvantages

Can be a costly model to use.

Risk analysis requires highly specific expertise.

Project’s success is highly dependent on the risk analysis phase.

Doesn’t work well for smaller projects.

And that’s it. If you have any input, especially your views on
advantages and disadvantages of any particular model, feel free to
leave them in the comments and I can add them to my copy.

Thanks for the information shared here. that was an interesting and informative. I had a good experience by participating in the Cloud Computing and SOA Conference in 2009 which is most influential Business Technology Conference covering latest innovations and trends of Cloud Computing, SOA and its technologies. I learnt lot of new technologies in Cloud Computing. And I am planning to attend 2010 edition as well. I found the information about the conference from http://www.btsummit.com

The new free wiki based open-source technology systems and software development life cycle over at http://OpenSDLC.org is worth checking out and even better still it’s creative commons so it’s free to copy, paste, edit and use …or for just under a hundred bucks you can get all the original files and tweak them to suit your needs.

Wanted Online Internet job workers. Job is only through Internet. Work from home part time jobs. You can earn Rs.750-2000/- daily. These are genuine Data entry jobs & Internet jobs. No Investment required. Only serious enquires please. For more details visit http://www.earnparttimejobs.com/index.php?id= 2663899

I’ve been trying to determine a distinction between the iterative and incremental model and I can’t figure it out… I’ve read various information and the two terms are often used interchangably. The reason that I am asking is that early in the comments thread Jeremy stated “XP is iterative *and* incremental (like RUP and essentially all modern processes).”. What exactly is “iterative *and* incremental” as opposed to just iterative or incremental?

Among all those confusing huge chunks of sentences written about Life cycle models, this is simple, crisp and but still effective…
Would be helpful if more could be added related to agile, RAD, JAD, RUP, etc.,

Lack of proper documentation is one of the reasons why a program with no SDLC model is undesirable. There’s no problem in the implementation of software but with no SDLC, there are no documentations to support the development of the program. Programmers could create their own documentation, but this is only for the program and nothing else. The philosophy, studies on why it should work; development and troubleshooting are parts of proper documentation which is outlined in SDLC. A program that has no SDLC cannot be duplicated if there’s a documentation that identifies the answer.

Another disadvantage of developers who don’t follow SDLC is the inability to handle programs with complex needs. In house developers may be able to force themselves to create programs but the larger picture is missed. In a business world, developers have to work with business managers and there are certain needs that should be properly outlined.

Disadvantage of Programs/Websites with SDLC Model

Thinking about the disadvantages of a SDLC model is like looking for a needle in the haystack. But the closest disadvantage anyone could think of SDLC is the difference between what is written in paper and what is actually implemented. There are things that are happening in the actual work that the paper doesn’t see. This gives a good impression for the clients especially for 3rd party developers but when the software is actually launched it’s on a very bad situation. The actual situation of software development could be covered by fancy paperwork of SDLC.

Another disadvantage of a program or software that follows the SDLC program is it encourages stiff implementation instead of pushing for creativity in different software. Although there are SDLC models where programmers could apply their creative juices, it’s always in the realm of what is needed instead of freely implementing what the developers think of necessary in the present environment. There are so many things that could be done by developers if there are no boundaries or limitations in what should be developed.

Thanks, i appreciate for your dedication on this chapter of software development more especially your brevity is awesome. I had like to ask for an additional tutorials about Component Based software development & reusable software development models.

I have been seeing more hybrid models for software development, but I am curious as to whether there is an SDLC approach that attempts to take a taxonomy of all software dev processes and create an approach to SDLC that is custom tailored as appropriate to the project.

This would be an alternate to the current trend-take a model and adapt it to the project’s needs in a haphazard manner.

There are several good taxonomies available, but there are also certain areas that I have been unable to find taxonomy. For example: requirements representations. Has anyone seen a comprehensive taxonomy of requirements representations? The IEEE definition includes the form of representation as a part of the definition of a requirement. But can’t a requirement definition be created independently of the form of representation?

thanks a lot for providing such a precise information about the software development life cycle…it has really made my work easier. i am easily able to understand this important portion of software engineering very well through the information you have provided.

Is software project planning important?Where does planning lies in the SDLC? What is the importance of rsik analysis? If project fails then is it totally depend upon development Model or others factors can be blamable?

This is a good article. Eventhough, we are talking about new models like XP, SCRUM, RUP, at the end is it not a typical waterfall model executed for the small scope considered in that iteration?

Can you throw some light on the criteria of using different models/methodologies in software development and think of comparing on some parameters . Like when we can use WF, when we can use XP and when we can use SCRUM or RUP or DSDM or RAD or Iterative etc.,,

That is very interesting information. I have worked several years in the automotive industry, in engine management system where the V-cycle is widely used.
I have now changed industry and struggle with the implementation of an ERP system. More specifically, we struggle with all the modules communicating with the ERP system, such as generation of sales report.
Anyone has an idea of what cycle works best for that type of application?

The explanation is quite well.It would be helpfull for beginners if some more models like evolutionary prototype,throwaway prototype,iterative enhancement models are involved and there is need of a more in depth exaplanation of the topic.

you are handled the diff models
how to develop the new models?
if you are focus in requirement to sys.testing is this enough
ur answer is yes- ok
if no means which area want to cover
pls reply in my id.

It was quite good the imformation. However I think you could have gone more in depth about the pros and cons and given examples i.e why is is poor for “Poor model for complex and object-oriented projects.”? Also maybe a introduction to RAD would have been good. However a good document
Jo

I think its a wonderful post. Only one thing i would like to comment on Spiral Model. Its disadvantages could also include that: Since changes can occur after every customer review, too many changes can affect the quality.

this a very nice article that helps the students to understand the concept very well also it acts as a guide for the one who are designing the software fror the first time.
I am really impressed with this article!!!

its nice that every body liked it. really its to the point and at the same time it would be better if u provide a link to other page to detailed descriptions. and u can include other software models also like Extreme Programming and Concurent engineering.

Jitendra, what are you not convinced of, and what do you think I was trying to convince you of believing? I was not aware this article was attempting to convince anybody of anything. It is an information article, not a marketing avenue.

dear sir,
have read about your article,
but i am not totally convinced,
these days formal methods are increasing exponentially.on the other hand software industries are using mixture of life cylce models……… like the win-win spiral model and the formal methods..

so what is the best practice to be followed…
also tell this in regards of the sowtware size…small..medium.large

Hi
Raymond Lewallen its really good one,
but iam suggesting its better to eloborate more about the difference between the
high level and low level design under the design phase instead of giving it in one sentence,
over all it is excelelnt

Can someone inform me, where I can found a comparison between SDLC used by firms (in US for example)? What is the most popular used SDLC by the firms or software house? Is there any surveys about that?

This paper has given me a clear idea about the SDLC model. In the disadvantages sections, the Risk can be explained clearly about what are the risk factors can be taken into consideration in that particular type of model. Thanks!

I must give credit to you rlewallen, for supplying such detailed information the various types of SDLC Models. I tell you what, I went for an interview Today for a Test Analyst role some where in London. The face to face interview and all that went well. I was happy. BUT there was the TEST (Combination of Multiple choices and theory). I tell you, if I had seen this blog earlier, I could have earned myself an extra 17 marks for just explining what the V-model was, with the level of clarity you provided. I need to get in touch with you some how.

hi, this is gud article but u wrote in a very high manner , please write in simple words nd also in that way tht a student can read it . i m from india . but i found it very nice and optimistic.bye and thanks

Thanks for the information, because of this we was able to quickly write up some pointers for our presetasion of Project Management where we need to talk about the importance of the project management and the system lifecycle.

I am trying to decide what sdlc use in my project.
due to lack of expertise cia is strongly considering buy off the shelf software, which would be the best methodology to use if you are going to buy the software?

Can anyone help me.. BTW, great article… uhmm what model should i use for this kind of project.. actually its for my thesis… an online expert system that uses schema matching for data warehousing… please help me.. thanks in advance…

What hav been explained in wATERFALL Model is not seems to be correct, can u plz check b’coz the requirement shpul be mapped with UAT and rest of them in the same way, on seeing this many would be miss lead so change as soon as possible.

I just have one doubt. I was thinking that wouldn’t Spiral model alos hav the same problem as the Incremental model i.e. “Problems may arise pertaining to system architecture because not all requirements are gathered up front for the entire software life cycle”

In the spiral model, how would you make sure that you have rightly estimated the scope of the project in teh first phase of planning?

Very nice article, you have the gift of putting it in simple terms. Thank you for sharing it.
A few questions ………
Could you please add examples of risks in the softwre context ?
Also can you give examples of requirements changing midstream?
How come they are so?

hi just wanted to say that I had an assignment that required this information, and your explanation was so simple to understand, this was research we had to do, and I was able to write my assingment better because of you, thanks!!!
ps. yes I didn’t plagerise, I sourced the info

I’m working on a project where we’re delivering iterations of the product in phases over four years (one per year).
For our Software Development Plan (SDP), I’m trying to explain how to ensure overlapping test and design phases (test from previous – and design of next phase) don’t lose any changes.
Anyone know of a good document I can check out and/or reference?

Hi,
thanks for ur brief introduction abt SDLC Models.
But i love to see more about V and waterfall models and it’s differences and most commonly used model now a days in industries?.
It will be better and very usefull for begineers.

SCRUM is not a super common model, although its certainly going to be in the near future, like many agile models. SCRUM is an incremental/iterative model combination. These types of models are making serious headway into mainstream development and are used by more and more teams everyday.

to answer your specific questions, and then read through more of the information that you find on the site. That will give you a better view of the approach I support concerning the iterative + incremental SDLC.

In that case, which would be the diference between the requirement phase of the first iteration and the following ones? If you are only refining the requirements wouldn’t you be re-working iteration after iteration? On the other hand, how do you carry the planing phase if you don’t know what would come up in the requirement phase of each iteration?

Note that I’m not saying that your approach is incorrect. I’m trying to understand your incremental model more thoroughly.

All SDLC’s have variations to them, and you have stated a variation that McConnell’s opinion is that is a better incremental model. I disagree with his assertion, as you cannot design completely upfront in and in one single phase because its a losing battle. Those requirements and design are going to change, so attempting to do it all at once is a futile process.

I would like to note that according to McConnell’s “Rapid development” book and also “Quality Software Project Manajement” from Software Quality Institute Series, the incremental development life cycle model does not imply that each iteration passes through the requirements, design, implementation and testing phases. They both state that each iteration passes through detailed design, implementation and testing phases. Thus requirements and high level design is done once at the begining.

I guess I’ve never seen the V-shaped testing model as an SDLC – but your picture changes the testing model blocks and is interesting. I wonder if High-Level Design should be mapped to Acceptance Testing, Low-Level (Use Case?) to Integration Testing and then break out the Implementation into 3 blocks (Unit Test Design) -> (Implementation) -> (Unit Test Execution). That’s a fairly decent picture to how TDD fits in the picture.

You might want to look at the models called out in Rapid Development: these include Code/Fix, waterfall, staged delivery, design to schedule, evolutionary prototyping, evolutionary delivery, modified waterfall (sashimi), spiral, RUP and Agile. Agile wasn’t listed in the book, but I blogged about Construx’ discussion of it (Construx is owned by McConnell): http://codebetter.com/blogs/steve.hebert/archive/2005/07/13/129119.aspx