• Skip to main content
  • Skip to after header navigation
  • Skip to site footer

Shaping Software

Enduring Ideas in the Realm of Software

  • About
  • Topics
  • Best Software Books
  • Archives
  • JD Meier.com

Choosing Between Evolutionary, Incremental, and High-Risk Software Process Models

Jun 23, 2008 by JD

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.

My Related Posts

  • Evolutionary, Incremental, and High-Risk
  • Systems Engineering ‘in the large’
  • Waterfall, In the Large, and In the Small
  • Macro and Micro Software Process
Category: ProcessTag: Process, Project-Management

About JD

Previous Post:Evolutionary, Incremental, and High-Risk
Next Post:Combining Software Process Models (Evolutionary, Incremental, and High-Risk)

Sidebar

Recent Posts

  • What is ChatGPT?
  • Agile Performance Engineering
  • What is Cybersecurity?
  • Software Security Threats: A Comprehensive Guide
  • What is Software Security?

Popular Posts

Best Software Books of All Time
Best Practices for Project Management
Best Practices for Software Development
Customer-Connected Engineering
How To Frame Problems Better
How To Pitch Business Ideas Better
How To Structure Vision Scope Presentations
Intro to Lean Software Development
Lean Principles for Software Development
The Enterprise of the Future