|
The SDLC Development Model (Waterfall Model)
|
|
|
|
|
|
|
|
The SDLC Development Model, or Plan-based Model
The SDLC Development Model (Plan-based Model)
SDLC (Software Development Life Cycle, or System Development Life Cycle) is the
traditional, Plan-based approach to systems analysis and design.
After the project is intiated, this model starts with
a 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.
Although the paperwork can be 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 plan-based 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 Plan-based model. Air-traffic control, life-critical medical
software, large-scale government software, and other large enterprise-level
software systems should be performed using an iterative Plan-based, or SDLC
model.
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 (Plan-based) 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) 636-0043.
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...
Software Development Best Practices - Software Requirements Management (7/18/2009)
I recently hosted Red Rock Research’s second weekly software development best practices seminar for the general public. Our topic was Software Requirements Management.
Requirements Management is perhaps the most controversial topic in software development. Everyone seems to have their own technque. It is also the most important skill-set–statistically more important than development skills–to the overall success of a software [...]
How to compute % defects removed from release candidate code (6/28/2009)
Recently someone on StackOverflow.com asked me to explain how to compute the defect removal rate for release candidate software. There are two methods for producing this number and I teach both in several of my seminars, but I’ll explain the simpler method in this post…
Lawrence Putnam presented this model in his 1992 Book titled Measures for [...]
A Free Software Requirements Specification Template (SRS)! (5/20/2009)
Need a good software requirements specification (SRS) template? Use an industry-standard SRS. Can’t find one? Well now you have-get it here for free. Enjoy!
Mike J. Berry
www.RedRockResearch.com
Software Developement Process Guidance
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 |
|
|
|
|
|
|