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

CodeDebug model

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" and "debugging."

Waterfall Model

Waterfall model
View Dr. Dalbey's version
Simple, easy to understand and follow.
Highly structured, therefore good for beginners.
After specification is complete, low customer involvement required.
Inflexible - can't adapt to changes in requirements. 

Prototyping Model

Prototyping Model

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 resources.

Spiral Model

Spiral Model

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 exploratory projects.
Difficult to establish stable documents; things keep getting modified during each iteration.

Agile Model

Agile Model

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 everything.
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 customer needs.
A complete and stable design is produced.
A compromise between waterfall and agile.
Can't easily adapt to entirely new requirements.

Factors in Choosing a Software Process

Customer involvement

Stable requirements

Team size / proximity

Developer experience

Familiarity with technology

Familiarity with domain

Severity of impact of incorrect analysis

Anticipated changes in technology