|The first and most important step in any software project is
education. This page contains a brief overview of the software
project process. Before beginning a project make sure all parties know
what is involved, and the process needed to achieve maximum success with
minimal risk. It is recommended that you read The
Software Project Survival Guide by Steve McConnell prior to
starting a project. With the proper planning your project will stay within
budget and schedule, but most of all it will work the way you work!!!!!
Design & Prototype
Design, Construction, Testing
|The project scope is an overview document describing the
concepts of the software project. It is a one page document that describes
not only what the software will do, it must also include what the software
will not do. The project scope also serves as a reference when proposed
changes are under review.
It is a good idea to give the software a name at this point, the name
will most likely change during the life cycle of the project. Referring
the software as an entity will give the project team a better sense of
purpose, common goals and motivation as opposed to "The Project"
or "The Database". This is also a time that potential project
risks can be identified and investigated.
As each stage comes to a close the entire team agrees on the state of
the project and the sign-off document for that stage is signed by all
appropriate parties, with all levels of the project team in agreement that
the software is progressing towards success.
|Software requirements development is the part of the project
during which the features of the software are gathered from the potential
users and translated into a document with the specifications of what the
system must do. Requirements development consists of four related
- Gathering candidate requirements, which is accomplished by
interviewing potential users about the system they want and reviewing
- Specifying requirements, which is accomplished by committing the
gathered requirements to a requirements document.
- Analyzing requirements, which is accomplished by looking for
commonalities and differences among requirements and breaking them
down into their essential characteristics.
- Revisiting the project risks and assessing any new risks the
requirements discovery has uncovered.
|In building construction, the architecture phase is a time
during which a general plan for a building is mapped out through the use
of scale models and blueprints before the building is actually
constructed. Scale models and blueprints provide a means of exploring
alternatives more cheaply than using steel, concrete and other building
The same applies to software development. The architecture stage is a
time when the software is mapped out through the use of design diagrams
and prototypes. As in building construction the architecture stage
provides a means of exploring alternatives at a relatively low cost.
Any project risks will be addressed and the project altered to reduce
the risks by the end of this stage. If any of the stages were skipped or
not taken serious by the team the project is destined to fail. Sadly a
large number of projects fall victim to this, due to the fear of budget
and schedule overruns. The reality.... it costs 50 to 200 times more to
make changes to the software after this stage.
|During construction, developers begin breathing life into
the software by creating the source code that becomes the working computer
program. Each developer fills in gaps in the detailed designs, creates
source code, unit tests and debugs the source code, and integrates the
source code with the projects main build.
On a well run project, the steadily accumulating functionality during
construction gives the whole project a lift. The project spins into a
high-performance hum as developers build on each others contributions, and
mangers and users grow increasingly confident in the system as they
witness the daily accumulation of new functionality. Construction can be
the most enjoyable stage of a software project.
System testing is conducted in parallel with construction or a half
step behind. It exercises the system from end to end, exposing defects
that are then corrected by the developers.
|The success of the staged delivery approach relies on
bringing the software to a reasonable quality level and embracing all the
extra quality assurance and development work that that entails. Bringing
the software to a releasable condition eliminates dark corners in which
unforeseen work can accumulate, improving status visibility. Driving to a
releasable state also eliminates the places where insidious quality
problems can hide. Without periodically raising the software's quality to
a releasable level , the software will begin a slow slide toward low
quality, whence it may never return.