We have different process models for different systems!
- Safety/Warfare Systems → need concrete specification
- Design Stuff e.g. websites → needs user feedback
Generally, the processes involve:
- Specification: what should it do
- Design & Implementation: how organised, how implemented
- Validation: checking it matches the specification
- Evolution: changing the software
- Does the specification change?
Process Model Categories
- Plan-driven:
- Agile:
Plan-Driven
The Waterfall Model
Strict linear ordering of processes.
Each stage must be completed before moving on.
- Easy for new employees to be onboarded
Requirements Analysis
System Design
“System Design helps us to maximise synergy!” - Corporate James
Implementation & Unit Testing
Unit Testing
It’s easy to get carried away with unit testing and having 700 unit tests which don’t test anything difficult/meaningful, and being satisfied with that.
Integration and System testing is often more important to find bugs because unit tests often test for bugs that you thought of; what about bugs that you haven’t thought about?
Further, if you write the tests after the code then you’ll be biased and probably write the tests to fit to the code.
When does it work?
The model works for well-understood requirements which don’t change (or change very little).
- Development can be distributed easily
- f
- Easy to onboard new employees since the system is well-documented
When break?
Rigid planning leads to some difficulties:
- Difficult to accommodate for change
- important because the world, especially tech world, is ever-changing
- Planning takes a while so customers wait a long time before results
- g
Incremental Software Development
Since plan-driven is too rigid, we can try a process that allows for change.
- Results will be seen sooner (earlier versions)
- Greater perceived value for money (visible progress)
- Feedback can be received sooner → change
Problems
Difficult to:
- estimate the cost of development
- f
Controlling Clients
Ensure clients don’t keep suggesting more and more complex additions each time you get feedback; this leads to an ever-increasing development time, and they might get frustrated when they don’t get a project for years.
Of course, the longer a project takes, the higher the chance that the project becomes outdated when it releases.
Reuse-orientated Software Engineering
A focus on building re-usable components, and checking what you’ll need to build from scratch and what you can reuse.
Coursework
Be careful about suggesting you’re using this in the coursework.
Requirements Engineering
- Feasibility Report: Is the task doable? Is it cost-effective?