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
- Specification - Set out requirements and constraints
- Design - Produce a paper model of the system
- Manufacture - Build the system
- Test - Check the system meets the required specifications
- Install - Deliver system to customer and ensure it is operational
- Maintain - Repair faults in the system as they are discovered
Software Process - Who is involved?
The stick men are called Actors.
Software Process Models
- Requirements Definition
- Verification and Validation
- Operation & Maintenance
- Verification and Validation
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
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.
Building a prototype to test a hypothesis. Also known as a 'spike'. Then build the real product from it.
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
- 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.
- Determine objectives
- Evaluate alternatives - resolve risks
- Use a waterfall model.
- 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
- Initial level - also called ad hoc or chaotic
- No problem statement or requirements specification
- Repeatable level - process depends on individuals ("champions)
- Defined level - process is institutionalised (sanctioned by management)
- Managed level - activities are measured and provide feedback for resource allocation
- Optimising level - process allows feedback of information to change process itself
It goes from chaos to closing managed and monitored software development through feedback.