project lifecycle models_ how the differ and when to use them

8/3/2019 Project Lifecycle Models_ How the Differ and When to Use Them

1/5

Project Lifecycle Models: How They Differ and When to Use Them

Business eSolutions provides System Development Project Management services, Problem

Project Diagnostic and Recovery services and Project Management Training and Facilitation

courses covering strategy, project management, project estimating, business requirements,

risk management and quality assurance. We can help you define a lifecycle methodology

customized to your organizational strengths and development risks. Our mission is to help our

clients produce quality systems on time and on budget.

Project lifecycle models are not interchangeable. To deliver a quality system, it's critical toknow the risks facing your project and to use a model that reduces those risks. The following

describes standard project lifecycle models, and reviews their strengths and weaknesses.

These standard models can be adapted to fit the industry issues, corporate culture, time

constraints and team vulnerabilities which comprise your environment. Contact Us to help.

Pure Waterfall Spiral Modified Waterfall Evolutionary Prototyping Code-and-Fix

Staged Delivery Evolutionary Delivery Design-to-Schedule Design-to-Tools Off-the-Shelf

What model do you use? Or, more appropriately, what model should you be using? Here's a

summary to help you decide.

Pure Waterfall

This is the classical system development model. It consists of discontinuous phases:

Concept1.Requirements2.Architectural design3.Detailed design4.Coding and development5.Testing and implementation6.

Strengths Weaknesses

Minimizes planning overhead sinceit can be done up front.Structure minimizes wasted effort,so it works well for technicallyweak or inexperienced staff.

InflexibleOnly the final phase produces anon-documentation deliverable.Backing up to address mistakes isdifficult.

Pure Waterfall SummaryThe pure waterfall performs well for products with clearly understood requirements or

when working with well understood technical tools, architectures and infrastructures.

It's weaknesses frequently make it inadvisable when rapid development is needed. In

those cases, modified models may be more effective.

Spiral

The spiral is a risk-reduction oriented model that breaks a software project up into

mini-projects, each addressing one or more major risks. After major risks have been

addressed, the spiral model terminates as a waterfall model. Spiral iterations involve six steps:

Determine objectives, alternatives and constraints.1.Identify and resolve risks.2.Evaluate alternatives.3.Develop the deliverables for that iteration and verify that they arecorrect.

4.

ct Lifecycle Models: How the differ and when to use them http://www.business-esolutions.com

12/6/2011 1


2/5

Plan the next iteration.5.Commit to an approach for the next iteration.6.


Early iterations of the project are the

cheapest, enabling the highest risks to

be addressed at the lowest total cost.

This ensures that as costs increase,

risks decrease.

Each iteration of the spiral can betailored to suit the needs of theproject.

It is complicated and requires attentive

and knowledgeable management to

pull it off.

Spiral SummaryFor projects with risky elements, it's beneficial to run a series of risk-reduction

iterations which can be followed by a waterfall or other non-risk-based lifecycle.

Modified W aterfall

The modified waterfall uses the same phases as the pure waterfall, but is not done on a

discontinuous basis. This enables the phases to overlap when needed. The pure waterfallcan also split into subprojects at an appropriate phase (such as after the architectural design

or detailed design).


More flexibility than the pure waterfall

model.

If there is personnel continuitybetween the phases,documentation can besubstantially reduced.Inplementation of easy areas donot need to wait for the hardones.

Milestones are more ambiguous thanfor the pure waterfall.

Activities performed in parallel aresubject to miscommunication andmistaken assumptions.Unforseen interdependencies cancreate problems.

Modified Waterfall SummaryRisk reduction spirals can be added to the top of the waterfall to reduce risks prior to

the waterfall phases. The waterfall can be further modified using options such as

prototyping, JADs or CRC sessions or other methods of requirements gathering done

in overlapping phases.

Evolutionary P rototyping

Evolutionary prototyping uses multiple iterations of requirements gathering and analysis,

design and prototype development. After each iteration, the result is analyzed by thecustomer. Their response creates the next level of requirements and defines the next iteration.


Customers can see steady progress.

This is useful when requirementsare changing rapidly, when thecustomer is reluctant to commit toa set of requirements, or when noone fully understands theapplication area.

It is impossible to know at the outsetof the project how long it will take.

There is no way to know thenumber of iterations that will berequired.

Evolutionary Prototyping SummaryThe manager must be vigilant to ensure it does not become an excuse to do

code-and-fix development.

Code-and-Fix


12/6/2011 1


3/5

If you don't use a methodology, it's likely you are doing code-and-fix. Code-and-fix rarely

produces useful results. It is very dangerous as there is no way to assess progress, quality or

risk.


No time spent on "overhead" like

planning, documentation, quality

assurance, standards enforcement or

other non-coding activities.Requires little experience.

Dangerous.No means of assessing quality oridentifying risks.

Fundamental flaws in approach donot show up quickly, oftenrequiring work to be thrown out.

Code-and-Fix SummaryCode-and-fix is only appropriate for small throwaway projects like proof-of-concept,

short-lived demos or throwaway prototypes.

Staged Delivery

Although the early phases cover the deliverables of the pure waterfall, the design isbroken into deliverables stages for detailed design, coding, testing and deployment.


Can put useful functionality into the

hands of customers earlier than if the

product were delivered at the end of

the project.

Doesn't work well without carefulplanning at both management and

technical levels.

Staged Delivery SummaryFor staged delivery, management must ensure that stages are meaningful to the

customer. The technical team must account for all dependencies between different

components of the system.

Evolutionary Delivery

Evolutionary delivery straddles evolutionary prototyping and staged delivery.


Enables customers to refine interface

while the architectural structure is as

planned.

Doesn't work well without carefulplanning at both management and

technical levels.

Evolutionary Delivery Summary

For evolutionary delivery, the initial emphasis should be on the corecomponents of the system. This should consist of lower level functions whichare unlikely to be changed by customer feedback.

Design-to-Schedule

Like staged delivery, design-to-schedule is a staged release model. However, the number of

stages to be accomplished are not known at the outset of the project.



12/6/2011 1


4/5

Produces date-driven functionality,

ensuring there is a product at the

critical date.

Covers for highly suspect estimates.

Won't be able to predict the full rangeof functionality.

Design-to-Schedule SummaryIn design-to-schedule delivery, it is critical to prioritize features and plan stages so that

the early stages contain the highest-priority features. Leave the lower priority features

for later.

Design-to-Tools

When using a design-to-tools approach, the capability goes into a product only if it is directly

supported by existing software tools. If it isn't supported, it gets left out. Besides architectural

and functional packages, these tools can be code and class libraries, code generators, rapid-

development languages and any other software tools that dramatically reduce implementation

time.


When time is a constraint, may be

able to implement more totalfunctionality than possible when

building everything "from scratch".

You lose a lot of control over theproduct.You may become "locked in" to avendor. If it is for long-termfunctionality, vendor lock-in canbecome a weak link.May not be able to implement all

features desired or in the manner

desired.

Design-to-Tools SummaryConsider the tradeoffs of time-to-market versus lock-in and functionality compromises.

This may be an appropriate approach for a high-risk element of the overall project or

architecture.

Off-the-Shelf

Following requirements definition, analysis must be done to compare the package to the

business, functional and architectural requirements.


Available immediately and usually at

far lesser cost. Will rarely satisfy all system

requirements.

Off-the-Shelf SummaryIt is critical to know how the desired features compare with the packaged set and if thepackage can be customized.

These standard models can be adapted to fit the industry issues, corporate culture, time

constraints and team vulnerabilities which comprise your environment. We can customize a

methodology to fit your needs or help you with a special or problem project.

Contact Us with your project needs. We're here to help.

Copyright JJ Kuhl 2002


12/6/2011 1


5/5


project lifecycle models_ how the differ and when to use them

Documents