Software Life Cycle Models
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
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:
- Write some code.
- Run it and see what happens.
- Fix problems.
- 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.
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.