|
The SDLC Development Model (Waterfall Model)
|
|
|
|
|
|
|
|
The SDLC Development Model, or Waterfall Model
The SDLC Development Model (Waterfall Model)
SDLC (Software Development Life Cycle, or System Development Life Cycle) is the
traditional, Waterfall approach to systems analysis and design. It starts
with a heavy, documented, requirements-planning-and-sign-off's process,
followed by coding, test-case, and user-guide generation, then finally
verification (alpha-testing), validation (beta-testing), and release.
According to a recent 2007 survey by VersionOne, nearly 70% of software
development organizations are still using the SDLC Development
Model. Others claim the model is outdated and point to the
Standish Group's famous
CHAOS report as evidence.
It's been my experience that the software development community is lacking good
models for the Waterfall Life Cycle, and that many of these project failures
are not because of the Waterfall methodology, but rather, because the
teams in question don't know how to implement a Waterfall model successfully.
Although the paperwork is heavy, if performed correctly, this paperwork becomes
your quality system, and your up-front quality investment. It does take
longer for the product development group to implement a successful waterfall
model, but the benefit to the entire organization--and the customer--is a
highly-commercialized product, complete with a thorough users-guide,
test-script, validation traceability, release-notes, and a more-accurate
timeline-estimation throughout the course of the development project.
Companies that benefit from a highly-commercialized product, like this, require
much smaller customer-support teams, enjoy higher customer-retention
rates, and have more product-informed customers.
Many mission-critical systems require the quality inherent in the Waterfall
model. Air-traffic control, life-critical medical software, large-scale
government software, and other large enterprise-level software systems should
be performed using Waterfall, or SDLC.
Stages of the SDLC Development Model
Stage 1 - Planning
The planning stage should account for 5% of the overall time spent on a
project. The Planning stage is a time where resources are allocated, and
team assignments are made. Users and stakeholders that will
participate in the project should be selected. This is a good time to
review the development process with everyone involved with the project.
Stage 2 - Requirements
The requirement stage should be about 25% of the overall time spent on a
project. This stage should involve the developers, the stakeholders, and
the future users of the system. It has several parts:
-
First, a high-level user-profile should be created listing the typical users of
the system, and a simple description of their basic needs.
-
Next, use-cases denoting the scope of the project should be created.
These evolve naturally from the user-profile.
-
The use-cases get listed in a Work-Breakdown-Structure task-list, and then
one-by-one, the team elaborates on each use-case creating a
requirements-definition document for each appropriate use-case.
Stage 3 - Development
The development stage accounts for about 40% of the overall work of the
project. This stage includes more than just coding. Developing the
test scripts to test the development code is performed during this stage.
Stage 4 - Testing
Testing represents about 20% of the project lifecycle. If verification
testing (alpha testing) is performed properly, validation (beta testing) will
be an exercise in testing relevance, rather than testing
robustness.
If the requirements stage is performed properly, the users that were involved in
identifying the requirements are able to validate their input by using the
software during the beta process.
Stage 5 - Release
The release stage represents about 10% of the software development
project. Here, the users-guide is completed, implementation checklists
get created, and the release-notes finalized.
The software is staged for production at this point.
SDLC Software Estimation Techniques
Estimating a SDLC (Waterfall) project is easier than estimating an Agile
Development project. Because the project stages are fixed, and because
requirements are gathered up front, the overall scope of a waterfall project
can be estimated effectively.
The best SDLC projects should be structured in a sequence of iterated SDLC
versions. Instead of one gigantic software deliverable planned
inside of a large SDLC project, a more effective approach is to plan several
versions of the large project in iterative, SDLC projects.
One method for estimating SDLC projects is to examine each requirement group and
assign a function-point value to it. Then, using the function-point
formula from the
International Function-Point Users Group,
you can estimate how long it would take an average group to complete a project
of that size. Over time, you can measure your own group's ability to
deliver function-point's over time, and you can create your own team's
estimates. To help with this process, RedRockResearch has a
free Function-Point counting utility available
for download.
For further ideas,
Steve McConnell has
an excellent
document on software estimation.
SDLC and EVM (Earned Value Management)
A great reporting technique for listing software development project
progress is to track the project's Earned Value progress.
A proper Earned Value progress chart tracks the predicted timeline,
predicted cost, and the actual progress altogether on the same chart.
This chart tells a story. You can see that the predicted value is the dark
baseline, comprising a start date and a predictable duration of cost and
time. This represents the 'perfect' project.
Actual Cost follows the predictable baseline for the first three weeks, but then
levels off for the next three weeks. This implies the programmers were
taken off of the project for some reason during this time. When they
re-engaged, their cost was steeper, implying more programmers were put on the
project, or overtime was worked.
Finally, the Earned Value indicator shows the actual real amount of progress,
prorated against cost, that has occurred. This graph shows how earned
value followed predicted estimates until the programmers were temporarily
removed from the project. Then, you see the earned value steeply climb
upwards as more programmers, or overtime, was applied to the project.
Based on the indicators, this chart shows that the project is not completed
yet, and still has about 20% of work until the Earned Value equals 100%.
This will occur when the Earned Value indicator finally intersects the
Predicted Value indicator.
You can see how Earned Value Management is an effective tool for project
tracking. In reality, this is more effective than the traditional Gantt
chart for showing the baseline estimate, the real progress, the cost-to-date,
and the time-to-completion.
Getting Started with SDLC Development
To get started with SDLC Development, call us for a consultation. We
can be reached at (801) 916-5516.
SDLC Software Procedure Templates
SDLC Software Project Plan Templates
SDLC Project Tracking WBS (Work Breakdown Structure) Templates,
Milestone Charts, Earned Value Charting
Recent Posts on the SDLC Development Model...
The Three P’s of a Quality Management System (3/28/2008)
A Quality Management System, sometimes referred to as a Total Quality Management (TQM) System, is a simple concept that will dramatically improve software production quality over time.
Companies that don’t have a quality system are commonly reacting to production and support issues due to omissive events.
A simple rule of thumb is to ask yourself how many fires your development team has put out this [...]
The Bat-Phone (3/28/2008)
Do you have one of those executives that harasses you with status updates to projects, yet never attends the status update meetings?
Perhaps they call you, email you, stop in to your office, and want to know what the latest on project X is?
Is the behavior effecient? What suggestions do you have about how to convey [...]
Book Review: Under Pressure and On Time (12/6/2007)
Ed Sullivan’s book, Under Pressure And On Time, is a no-nonsense guide for delivering software products to market in a timely manner.
In this industry where the average software project is late, over budget, or a complete failure, there are so many books written about what not to do. It’s refreshing to read a software development book that [...]
Book Review: Software Project Survival Guide (11/29/2007)
In Steve McConnell’s book, Software Project Survival Guide, he describes the foundation and procedures for managing a successful software development project.
Researching from NASA, IEEE, and some other industry giants like Grady Booch and Tom Demarco, McConnell summarizes software development into six stages:
Planning
Design
Construction
Testing
Release
Wrap-up
McConnell also offers some great ideas like keeping a project history to record lessons learned [...]
Meetings? We don’t need no stinkin’ meetings? (11/8/2007)
There seems to be no set standard for development meetings. Some groups complain about being ‘meetinged to death,’ while others complain about a lack of communication, direction, or group cohesion. Given the two options, it is generally agreed that overcommunication is much better than undercommunication.
One of the more innovative approaches to cutting down on meeting [...]
| Related Seminars |
Date |
Register |
|
|
|
|
|
|