Software Process Models
A software process model represents the order in which the activities
of software development will be undertaken. It describes the
sequence in which the phases of the software
lifecycle will be performed.
Typical Student Programming Process
Most students are not provided much training in the process of
developing software and as a result have a very simplistic procedure
they call "programming." There understanding of their own
process is quite vague and described with very general terms "coding"
View Dr. Dalbey's version
- Each phase is carried out completely (for all requirements)
before proceeding to the next.
- The process is strictly sequential - no backing up or repeating
Simple, easy to understand and follow.
Highly structured, therefore good for beginners.
After specification is complete, low customer
Inflexible - can't adapt to changes in
A variation of the waterfall that adds a new phase, prototyping.
There are several kinds of prototypes but they all intend to reduce
risk by building a quick and dirty replica or mockup of the intended
system. It can be used to demonstrate
technical feasibility when the technical risk is high. It can
also be used to better understand and elicit user requirements.
In either case, the goal is to reduce risk and limit costs by
increasing understanding of proposed solutions before committing more
An iterative approach where multiple passes are made through each
phase. During each iteration the system is explored at greater
depth and more detail is added. Appropriate for exploratory
projects that are working in an unfamiliar domain or with unproven
technical approaches. The iterative natures allows for knowledge
gained during early passes to inform subsequent passes. Requires
low up-front commitment.
Manages uncertainty inherent in
Difficult to establish stable
documents; things keep getting modified during each iteration.
An iterative approach. During each iteration a single feature or
small set of features are chosen and implemented completely.
Can adapt to changing requirements
because you haven't committed to big design that encompasses
Easy to change direction to adapt to dynamic market conditions.
Used as an excuse for hacking -
proceeding without a plan.
Substantial refactoring or redesign may be needed between iterations.
Not suitable for large projects or large teams.
Requires huge customer involvement, which is unusual to find.
Evolutionary Model ("Staged Delivery")
Recommended by McConnell.
All analysis and design is done up front.
Each stage releases some fully functional subset of desired features.
Emphasis is on high quality releases.
Can incorporate prototyping.
Partial functionality available early.
Some flexibility in responding to changing market conditions or
A complete and stable design is produced.
A compromise between waterfall and agile.
Can't easily adapt to entirely new
Factors in Choosing a Software Process
Team size / proximity
Familiarity with technology
Familiarity with domain
Severity of impact of incorrect analysis
Anticipated changes in technology