1.2.B. Software Process Models - Waterfall, Prototyping And V
1.2.b. Software Process Models - Waterfall, Prototyping and V
Waterfall Model
This is a typical sequential process of software design:
- Requirements analysis and definition
- System (architecture) design
- Program (detailed) design
- Writing programs (coding/implementation)
- Testing: unit, integration, system
- System delivery (deployment)
- Maintenance
This is a simple easy-to-understand design that most people will be familiar with. This is the first and traditional model of software development that other engineering disciplines will be familiar with.
This is a diagram of the full model. Each stage flows into the next stage, it is directional and sequential.
Benefits
- It is good for well understood problems.
- If you know the requirements well already, this works well as you are unlikely to have to revise your product later in the cycle and can just work through each stage.
- Each phase has milestones and deliverables.
- After you do the analysis stage, you would have a document you could use in the software design phase to inform how you would actually create the system.
- This makes it very clear.
Drawbacks
- It doesn't state or provide guidance on how to handle changes.
- The requirements are done all in one go, therefore if in the development stage there is a need to go back and redesign things, you would have to go all the way to the start from the first activity.
- It views software development as manufacturing rather than a creative process.
- When presented with a non-trivial software problem, there are many ways and many different technologies (e.g: programming languages, techniques) to address the problem.
- Therefore, each individual project or problem will have several alternatives that could be more likely to succeed.
- There is a long wait until the client recieves the final product, and they may be unsatisfied with the final software in production, meaning you would have to restart from the very beginning and try again.
Waterfall Model with Prototyping
- A prototype is a partially developed product.
- Developers assess alternative design strategies (design prototype).
- Users understand waht the system will be like (user interface prototype)
- They have plenty of time to see what the software will be like, and they can start thinking about how they can prepare in advance for it, including giving thought to specialist training.
You can develop a prototype as you are just considering the requirements and analysis, therefore you can show the client if something works/doesn't work.
In the system design phase, you can test multiple alternatives to see what works best.
However, there is more time spent developing those individual prototypes, so it is less necessary if you have a good idea on exactly how the software should be developed.
- They have plenty of time to see what the software will be like, and they can start thinking about how they can prepare in advance for it, including giving thought to specialist training.
V Model
V Model brings testing early in the cycle to assess each phase.
- Each phase is assigned to a particular type of testing.
- We know a lot earlier on if things are on the right track in terms of quality, and if problems are found, the regular phases can be re-executed.
Prototyping Model
- This is very much based on prototypes from the beginning.
- The initial requirements analysis is done based on iterations of prototypes.
- These are incomplete, so we must be aware that these are updating overtime.
- We may have a list of revisions that will influence a number of versions of prototypes that will need to be checked.
- We have feedback from the user and customer reviews so they can check the prototype and give feedback, which could further lead to more revisions.
- There is a significant mitigation of risk during the development, we are always producing something that we can analyse and use to further make decisions about the implementation of the product, so it is useful.