Chapter 2 - Software Process (Life Cycle)

Primitive Software Process Model

For a simple programme written by one person, this works fine.



More Complex Software Process Model


Generic Engineering Process

  1. Specification - Set out requirements and constraints
  2. Design - Produce a paper model of the system
  3. Manufacture - Build the system
  4. Test - Check the system meets the required specifications
  5. Install - Deliver system to customer and ensure it is operational
  6. Maintain - Repair faults in the system as they are discovered

Software Process - Who is involved?


The stick men are called Actors.

Software Process Models

Waterfall model

  • Requirements Definition
    • Design
      • Implementation
        • Verification and Validation
          • Installation
            • Operation & Maintenance

Problems with the Waterfall Model

The requirements may not be fully understood or need to be changed, and it would be too late to change the software easily.

  • Managers love waterfall models
    • Nice milestones
    • No need to look back, one activity at a time
    • Easy to check progress
  • Software development is iterative
    • During design, problems with requirements are identified
    • During coding, design and requirement problems are found
    • During testing, coding, design and requirement errors are found
  • System development is a non-linear activity
  • Verification and Validations comes too late in the process

Evolutionary Models

Waterfall models are poor at managing risk.Waterfall assumes that all requirements are known at the beginning. Prototyping can provide the answer. Software in evolutionary strategies is grown rather than built.

Throwaway prototyping

Building a prototype to test a hypothesis. Also known as a 'spike'. Then build the real product from it.

Evolutionary prototyping

Build a prototype as a demonstration, then use it as the base for the fully functioning software. Prototyping is particularly common in designing GUI's. It is lower risk than the waterfall model as testing is very early. The risk is spread out over the process.

Difficulties with evolutionary models

  • Planning
  • Managers don't like it
  • No guarantee that the end will be reached
  • Architecture could get messy, bringing the need for a rework/refactoring job near the end of the process.

Spiral model


  1. Determine objectives
  2. Evaluate alternatives - resolve risks 
  3. Use a waterfall model.
  4. Evaluation and plan next quadrant

Incremental and iterative methods

The aim is to have a good working system at every stage of development. 

This method is good for a number of reasons:

  • Early feedback
  • Better time to market for high priority
  • Easier reaction to change
  • Better estimates
  • Lower risk



Design to schedule 

The higher priority tasks are completed first so that if there is a shortage of time or money, there won't be major components missing.

Architecture must be open at each stage so that the software can be added to and changed as needed.

The Gantt Chart

The Gantt chart allows development strands and the relationships between them, to be represented on a timeline. They are intended to represent an iterative development process involving some design, some implementation, some testing, then back to design. Lines on a gantt chart represent dependencies.

Good Gantt charts are readable at a glance

Capability Maturity Model

  1. Initial level - also called ad hoc or chaotic
    • No problem statement or requirements specification
  2. Repeatable level - process depends on individuals ("champions)
  3. Defined level - process is institutionalised (sanctioned by management)
  4. Managed level - activities are measured and provide feedback for resource allocation
  5. Optimising level - process allows feedback of information to change process itself

It goes from chaos to closing managed and monitored software development through feedback.