A structured set of activities required to develop a software system.
Core activities:
- Specification
Defining what the system should do. - Design and implementation
Designing and coding the system. - Validation
Checking the system meets requirements. - Evolution
Changing the system to meet new needs.
Why Use a Process
Development within a defined process is systematic, traceable, and repeatable. Development without one is informal, unpredictable, and prone to compounding errors.
Without a process, developers move directly from a partial understanding of requirements to coding. There are no review checkpoints, no controlled design phase, and no systematic test strategy. The result is typically:
- Inconsistent architecture and high defect density.
- Poor maintainability and inability to scale.
- Unpredictable delivery and high rework costs.
Informal development may appear faster in very early stages of small projects. This advantage disappears as complexity grows.
Process Description
A formal record of what activities are performed, in what order, and under what conditions.
Components:
- Activities
Work steps that transform inputs into outputs (e.g. UI design, data modelling). - Products
Outputs of activities: documents, code, test results, models. - Roles
Responsibilities of people involved. Defines who performs each activity. - Pre-conditions
State that must hold before an activity can begin. - Post-conditions
State that must hold after an activity completes.
Exists at varying levels of abstraction. High-level descriptions outline major activities; detailed descriptions specify individual tasks and decision points.
Types
Plan-driven
All activities are planned before development begins. Each phase produces documented outputs consumed by the next phase. Progress is measured against the plan.
Suited for:
- Stable, well-understood requirements
- Large teams distributed across sites
- Safety-critical systems requiring extensive documentation
Requirement errors are only discovered very late in the process.
Agile
Planning is incremental and continuous. Requirements and plans are updated as understanding improves. Customer involvement is sustained throughout development.
Suited for:
- Evolving or unclear requirements
- Small, co-located teams
- Business systems where rapid delivery matters
Coping with Change
Change is driven by business changes, new technologies, and platform changes. Change cost includes rework plus implementation effort.
Two strategies to reduce rework costs:
- Change avoidance
Anticipate change early using prototyping. - Change tolerance
Design the process to allow low-cost changes. Incremental delivery supports this.
Software Prototyping
A prototype is an initial system version used to explore ideas and requirements.
Uses:
- Requirements elicitation and validation
- UI and design exploration
- Testing experiments
Benefits:
- Better usability
- Closer match to user needs
- Reduced development effort
Prototypes must not evolve into production systems: they have poor non-functional qualities, lack documentation, and degraded structure.
Incremental Delivery
System delivered in multiple increments instead of one release. High-priority requirements are delivered first. Requirements are frozen per increment.
Advantages:
- Early customer value
- Lower project risk
- Better testing of critical features
Problems:
- Hard to identify common system facilities.
- Conflicts with fixed-specification contracts.