Skip to content
SE eBook
Menu

Software Life Cycle Models

Public section
Preferences are saved on this device.

Software Process (Life Cycle) Models

A software process model (or software life cycle model) is a simplified representation of the software development process. It shows:

  • The main phases of development.
  • The order in which these activities are carried out.
  • The typical deliverables and checkpoints at each stage.

The main goal of using a process model is to provide a framework for planning, organising and controlling software projects so that the final product meets its objectives in terms of quality, cost and schedule.

The choice of a life cycle model can significantly affect:

  • Development costs and risks.
  • The ability to handle requirement changes.
  • The ease of coordination among team members.

Different models are suitable for different types of projects – small vs large, stable vs evolving requirements, high-risk vs low-risk, and so on. The development team must select the model (or combination of models) that best matches the project’s context.

In this section, we will briefly discuss several popular software process models, including:

  • Build-and-Fix Model
  • Waterfall Model
  • Prototyping Approach
  • Spiral Model
  • Iterative Development Process
  • Object-oriented development approaches
Software life cycle models Three cards showing simplified diagrams of the Waterfall model, Prototyping approach and Spiral model. Software Life Cycle Models Waterfall Linear sequence of phases Requirements Design Implementation Verification Maintenance Prototyping Build quick models, refine using feedback Draft prototype Review Refine Clarify needs Spiral Risk-driven, iterative development 1. Determine objectives 2. Identify and resolve risks 3. Development and Test 4. Plan the next iteration
Figure 3: Common Software life cycle models – Waterfall, Prototyping and Spiral.

1.8.1 Build-and-Fix Model

The Build-and-Fix Model is the most basic and informal way of developing software. The process is essentially:

  1. Write some code.
  2. Run it and see what happens.
  3. Fix problems.
  4. Repeat.

There is no formal specification, design or documentation. Changes are made directly in the code whenever issues are found or new requirements appear.

This approach may be acceptable only for:

  • Very small programs (for example, quick utility scripts).
  • One-time, throwaway code with little or no need for maintenance.

However, for anything beyond tiny projects (around 100–200 lines of code), the build-and-fix model becomes:

  • Hard to maintain and extend.
  • Prone to many defects.
  • Difficult to estimate in terms of time and cost.
Build-and-Fix model A simple cycle showing the steps write code, run and observe, fix problems and repeat, highlighting the lack of specification and design. Build-and-Fix Model Write code Run and observe (see what happens) Fix problems Repeat (no formal process) New requests / bugs
Figure 4: Build-and-Fix model – quick for tiny programs, risky for long-lived software.

Key limitation: the absence of systematic planning, design and documentation makes the Build-and-Fix Model impractical and risky for real-world, long-lived software systems.

Login to add personal notes and bookmarks.