Software Development Life Cycle Models

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
usiness requirements are gathered in this phase. This phase is the main focus of the pro!ect managers and sta"e holders. #eetings with managers, sta"e holders and users are held in order to determine the requirements. $ho is going to use the system% &ow will they use the system% $hat data should be input into the system% $hat 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 wor". 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. 'rchitects 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 wor" is produced. 'rchitecture, including hardware and software, communication, software design ()#* 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. ,or a developer, this is the main focus of the life cycle because this is where the code is produced. -mplementation may overlap with both the design and testing phases. #any tools exists

(C'.E tools+ to actually automate the production of code using information gathered and produced during the design phase.

Testing
/uring testing, the implementation is tested against the requirements to ma"e sure that the product is actually solving the needs addressed and gathered during the requirements phase. )nit tests and system0acceptance tests are done during this phase. )nit 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.

aterfall Model
This is the most common and classic of life cycle models, also referred to as a linear1 sequential life cycle model. -t is very simple to understand and use. -n a waterfall model, each phase must be completed in its entirety before the next phase can begin. 't the end of each phase, a review ta"es place to determine if the pro!ect is on the right path and whether or not to continue or discard the pro!ect. )nli"e what - mentioned in the general model, phases do not overlap in a waterfall model. $aterfall consists of a sequential process, primarily in one direction /oes not accommodate real iteration Critici2ed for placing no emphasis on reuse and having no unifying model to integrate the phases $aterfall *ife Cycle #odel

!dvantages

.imple and easy to use. Easy to manage due to the rigidity of the model 3 each phase has specific deliverables and a review process. 4hases are processed and completed one at a time. $or"s well for smaller pro!ects where requirements are very well understood.

Disadvantages

'd!usting scope during the life cycle can "ill a pro!ect 5o wor"ing software is produced until late during the life cycle. &igh amounts of ris" and uncertainty. 4oor model for complex and ob!ect1oriented pro!ects. 4oor model for long and ongoing pro!ects. 4oor model where requirements are at a moderate to high ris" of changing.

"volutionary #rototyping Model

Software prototyping, an activity during certain software development, is the creation of prototypes, i.e., incomplete versions of the software program being developed. ' prototype typically simulates only a few aspects of the features of the eventual program, and may be completely different from the eventual implementation. The conventional purpose of a prototype is to allow users of the software to evaluate developers6 proposals for the design of the eventual product by actually trying them out, rather than having to interpret and evaluate the design based on descriptions.

7 7 7 7 7

/evelopers build a prototype during the requirements phase 4rototype is evaluated by end users )sers give corrective feedbac" /evelopers further refine the prototype $hen the user is satisfied, the prototype code is brought up to the standards needed for a final product.

"volutionary #rototyping Steps$ 7 7 ! preliminary pro%ect plan is developed ! partial &ig&'level paper model is created

7 7 7

T&e model is source for a partial requirements specification ! prototype is built wit& basic and critical attributes T&e designer builds 3 3 3 t&e database user interface algorit&mic functions

7 7

T&e designer demonstrates t&e prototype( t&e user evaluates for problems and suggests improvements) T&is loop continues until t&e user is satisfied

!dvantages$ 7 7 7 7 7 7 7 Customers can 8see9 the system requirements as they are being gathered /evelopers learn from customers ' more accurate end product )nexpected requirements accommodated 'llows for flexible design and development .teady, visible signs of progress produced -nteraction with the prototype stimulates awareness of additional needed functionality

Disadvantages$ 7 7 7 7 7 Tendency to abandon structured program development for 8code1and1fix9 development ad reputation for 8quic"1and1dirty9 methods :verall maintainability may be overloo"ed The customer may want the prototype delivered. 4rocess may continue forever (scope creep+

Rapid !pplication Model *R!D+

7 7 7 7

Requirements planning phase (a wor"shop utili2ing structured discussion of business problems+ )ser description phase 3 automated tools capture information from users Construction phase 3 productivity tools, such as code generators, screen generators, etc. inside a time1box. (8/o until done9+ Cutover phase 11 installation of the system, user acceptance testing and user training

!dvantages$ 7 7 7 7 7 Reduced cycle time and improved productivity with fewer people means lower costs Time1box approach mitigates cost and schedule ris" Customer involved throughout the complete cycle minimi2es ris" of not achieving customer satisfaction and business needs ,ocus moves from documentation to code ($;.-$;<+. )ses modeling concepts to capture information about business, data, and processes.

Disadvantages$ 7 7 7 'ccelerated development process must give quic" responses to the user Ris" of never achieving closure &ard to use with legacy systems *Legacy systems utilize outmoded programming languages, software and/or hardware that typically are no longer supported by the respective vendors.+ Requires a system that can be modulari2ed /evelopers and customers must be committed to rapid1fire activities in an abbreviated time frame.

7 7

,ountain model
The fountain model recogni2es that although some activities can6t start before others 11 such as you need a design before you can start coding 11 there6s a considerable overlap of activities throughout the development cycle. The ,ountain #odel is a highly iterative approach that is well1suited to ob!ect1oriented software development. The ,ountain #odel allows for the fact that there is considerable

overlap of activities throughout the development cycle = although some activities can6t start before others. >ust as a fountain?s water rises up and falls bac" to the pool below, in ob!ect1oriented software development, the general wor"flow from analysis through design to implementation is overlaid with iterative cycles across many phases.

-'S&aped Model
>ust li"e the waterfall model, the @1.haped life cycle is a sequential path of execution of processes. Each phase must be completed before the next phase begins. Testing is emphasi2ed 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 !ust li"e the waterfall model. efore development is started, a system test plan is created. The test plan focuses on meeting the functionality specified in the requirements gathering. The high1level design phase focuses on system architecture and design. 'n integration test plan is created in this phase as well in order to test the pieces of the software systems ability to wor" together. The low1level 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 ta"es place. :nce coding is complete, the path of execution continues up the right side of the @ where the test plans developed earlier are now put to use.

@1.haped *ife Cycle #odel

!dvantages

.imple and easy to use. Each phase has specific deliverables.

&igher chance of success over the waterfall model due to the development of test plans early on during the life cycle. $or"s well for small pro!ects where requirements are easily understood.

Disadvantages

@ery rigid, li"e the waterfall model. *ittle flexibility and ad!usting scope is difficult and expensive. .oftware is developed during the implementation phase, so no early prototypes of the software are produced. #odel 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. #ultiple development cycles ta"e place here, ma"ing the life cycle a 8multi1waterfall9 cycle. Cycles are divided up into smaller, more easily managed iterations. Each iteration passes through the requirements, design, implementation and testing phases. ' wor"ing version of software is produced during the first iteration, so you have wor"ing software early on during the software life cycle. .ubsequent iterations build on the initial software produced during the first iteration. -ncremental *ife Cycle #odel

!dvantages

<enerates wor"ing software quic"ly and early during the software life cycle. #ore flexible 3 less costly to change scope and requirements. Easier to test and debug during a smaller iteration. Easier to manage ris" because ris"y 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. 4roblems 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 ris" analysis. The spiral model has four phases: 4lanning, Ris" 'nalysis, Engineering and Evaluation. ' software pro!ect repeatedly passes through these phases in iterations (called .pirals in this model+. The baseline spiral, starting in the planning phase, requirements are gathered and ris" is assessed. Each subsequent spirals builds on the baseline spiral. Requirements are gathered during the planning phase. -n the ris" analysis phase, a process is underta"en to identify ris" and alternate solutions. ' prototype is produced at the end of the ris" analysis phase. .oftware 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 pro!ect to date before the pro!ect continues to the next spiral. -n the spiral model, the angular component represents progress, and the radius of the spiral represents cost.

.piral *ife Cycle #odel

!dvantages

&igh amount of ris" analysis <ood for large and mission1critical pro!ects. .oftware is produced early in the software life cycle.

Disadvantages

Can be a costly model to use. Ris" analysis requires highly specific expertise. 4ro!ect?s success is highly dependent on the ris" analysis phase. /oesn?t wor" well for smaller pro!ects.