How do you choose between an Evolutionary, Incremental, or High-Risk software process model? Evolutionary, Incremental, and High-Risk are software process models for systems engineering ‘in the large’. In the Evolutionary model, the complete cycle of activities is repeated for each version. In the Incremental model, increments are individually designed, tested, and delivered at successive points in time. In the High-Risk model, the ‘in the large’ sequence involves successive phases in which project risks (user need, requirements, technology and fitness for purpose) are reduced in a controlled, step-wise fashion. In Scenarios, Stories, Use Cases: Through the Systems Development Life-Cycle, Ian F. Alexander and Neil Maden provide scenario-based guidance for choosing between Evolutionary, Incremental and High-Risk software process models.
Summary Table for Choosing Between Evolutionary, Incremental, and High-Risk Process Models
Alexander and Maiden provide a summary table for choosing between the Evolutionary, Incremental, and High-Risk software process models:
Questions | Evolutionary | Incremental | High-Risk |
---|---|---|---|
Is there a business need to get the product to market in the shortest time possible? | Yes | – | – |
Is there a rapid rate of technological evolution relative to design and delivery lead-times (implying very short product lifetimes)? | Yes | – | – |
Are customers prepared to accept the functionality that you and technology can offer in the short term, rather than waiting longer for a better solution? Are they likely to pay for successive versions? | Yes | – | – |
Can you tolerate loose technical linkage between successive versions of a system/product? | Yes | – | – |
Is there some reason why it is impossible to deliver total system functionality in one chunk. Do time or financial constraints mean a ‘salami slice’ approach is required? Can functionality be prioritized? Do functionality sub-sets make operational and business sense? Do successive increments have to dovetail perfectly? | – | Yes | – |
Do you really know at the outset what exactly the problem is, what the requirements are, what solutions might be relevant, or whether the stakeholders really know what they want? | – | – | No |
Is likely candidate technology proven | – | – | No |
Do you have doubts about the validity of the requirements discovery process? | – | – | Yes |
Evolutionary Model Scenarios
Alexander and Maiden suggest the Evolutionary model for the following scenarios:
- A rapid rate of technological evolution
- A tacit acceptance from customers to accept the functionality that technology can offer in the short term, rather than waiting for perfection (whatever that means). It is probably sufficient for the offering to be competitive.
- The business need is to get the product to market in the shortest time possible.
Incremental Model Scenarios
Alexander and Maiden suggest the Incremental model for the following scenarios:
- The centrality of the understanding that there is one system under consideration.
- The inability to deliver total system functionality as one big bang for some reason. Time or financial constraints will probably be the chief factors here. The functionality contained in each increment will be decided on the basis of business or operational priority.
- The functionality of Increment 1 must deliver sufficient business or operational value to make it worthwhile.
- The freedom to phase system functionality sub-sets (i.e. increments) over time.
- The ability to impose top class configuration control between increments, thus preserving the integrity of interfaces between increments.
High-Risk Model Scenarios
Alexander and Maiden suggest the High-Risk model for the following scenarios:
- You don’t really know at the outset what the problem is, what the requirements are, what solutions might be relevant and/or feasible, or whether the stakeholders really know what they want.
- There is a consensus that ‘something needs to be done’ and that (probably) some sort of improvements should be possible.
- Variants of this model are used by the US DoD and UK Ministry of Defense (in which they have a model referred to as ‘CADMID’ that stands for: Concept: Assessment, Demonstration, Manufacture, In-service, and Disposal).
Key Take Aways
Here’s my key take aways:
- If there’s short product life-times and loose technical linkages between successive versions is OK, then choose an Evolutionary model.
- If you need to deliver your system in increments, then choose an Incremental model.
- If you have high-risk, such as the requirements are not well known, choose a High-Risk model.