• 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

Combining Software Process Models (Evolutionary, Incremental, and High-Risk)

Jun 23, 2008 by JD

You can combine the Evolutionary, Incremental and High-Risk software process models.  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 explain how to effectively combine the Evolutionary, Incremental, and High-Risk process models.

Combined Software Process Models

Alexander and Maiden identify four potential software process model combinations:

  • Evolutionary and Incremental
  • Evolutionary and High Risk
  • Incremental and High Risk
  • Evolutionary, Incremental and High Risk

Evolutionary and Incremental

Alexander and Maiden write:

The combination of Evolutionary and Incremental probably means that the Evolutionary Model dominates but that due to timescale or resource constraints, the full functionality of a version cannot be delivered all at once.  However, getting some critical and useful initial functionality into the field makes business and marketing sense.  Once this is achieved, the remaining increment(s) can be added.

Example Project Structure:

  • Increment 1: Version 1.1, Version 1.2, … Version 1.N
  • Increment 2: Version 2.1, Version 2.2, … Version 2.N
  • … Increment M: Version M.1, Version M.2, … Version M.N

Evolutionary and High Risk

Alexander and Maiden write:

The combination of Evolutionary and High Risk only seem to make complete sense if the project falls predominantly into the High-Risk category and the evolutionary aspects relate to the mid-life improvements and upgrades within In-Service Support.

Example Project Structure:

  • Concept Exploration
  • Proof of Concept
  • Full Development
  • Production
  • Installation
  • In-Service Support: Version 2, Version 3, … Version N.

Incremental and High Risk

Alexander and Maiden write:

The combination of Incremental and High-Risk almost certainly means the High Risk model dominates with the Incremental aspect fitting inside it.  So, you Explore Concept, do Proof of Concept and Baseline Architecture, then do Full Development, Installation, and Production N-times on an Incremental basis.  Doing it the other way around does not seem to make much sense.

Example Project Structure:

  • Concept Exploration
  • Proof of Concept
  • Baseline Architecture
  • Increment 1:  Full Development, Production, Installation, In-Service Support
  • Increment 2:  Full Development, Production, Installation, In-Service Support
  • …
  • Increment N:  Full Development, Production, Installation, In-Service Support
  • Disposal

Evolutionary, Incremental and High Risk

Alexander and Maiden write:

The combination of Evolutionary, Incremental, and High-Risk probably means that the situation as described in the previous section on Incremental and High Risk exists, but with the Evolutionary aspects confined to mid-life improvements and upgrades within In-Service Support.

Example Project Structure:

  • Concept exploration
  • Proof of Concept
  • Baseline Architecture
  • Increment 1: Full Development, Production, Installation, In-Service Support
  • Increment 2: Full Development, Production, Installation, In-Service Support
  • …
  • Increment N: Full Development, Production, Installation, In-Service Support
  • Mid-life improvements and upgrades: Version 2, Version 3, … Version N

Alternative Project Structure:

  • Concept exploration
  • Proof of Concept
  • Full Development
  • Production
  • Installation
  • In-Service Support: Version 2 (Increment 2.1, Increment 2.2, … Increment 2.N), Version 3 (Increment 3.1, Increment 3.2, … Increment 3.N), … Version M (Increment M.1, Increment M.2, … Increment M.N)

Key Take Aways

  • If the Evolutionary model dominates, but that due to timescale or resource constraints, the full functionality cannot be delivered all at once, consider the Evolutionary and Incremental process model.
  • If the project falls predominantly into the High-Risk category and the evolutionary aspects relate to mid-life improvements and upgrades within In-Service Support, consider the Evolutionary and High-Risk process model.
  • If the High-Risk model dominates with the Incremental aspect fitting inside it, consider the Incremental and High-Risk process model.
  • If the High-Risk model dominates with the incremental aspect fitting inside it, and the Evolutionary aspects are confined to mid-life improvements and upgrades within In-Service support, consider the Evolutionary, Incremental, and High-Risk process model.

My Related Posts

  • Choosing Between Evolutionary, Incremental and High-Risk Software Process Models
  • Evolutionary, Incremental, and High-Risk
  • Waterfall, In the Large, and In the Small
Category: ProcessTag: Process

About JD

Previous Post:Choosing Between Evolutionary, Incremental, and High-Risk Software Process Models
Next Post:Mission Impossible

Reader Interactions

Comments

  1. Kevin Lam

    Jun 25, 2008 at 6:09 pm

    Very interesting, most of the models I’ve seen and work with don’t even consider (or entertain) the notion of combining models to meet objectives. For certification purposes (which I am most of the time not a big fan of because assessing compliancy to those models is always a big question market), this non-negotiable attitude simplifies things so I can see the point there.

    Do the authors talk about how process certification can be achieved in hybrid scenarios?

    –Kevin
    http://www.impactalabs.com

  2. JD

    Jun 25, 2008 at 7:22 pm

    Good question.

    I don’t remember anything specific to certification, (I suspect they might suggest the high-risk model — split the life cycle into stages — Explore Concept, Proof of Concept, Full Development, and Operations — and push the certification downstream, but with guidelines along the way.)

    Personally, I think the most effective approach for certification is through design, code, and deployment inspections where you’ve identified the criteria and codified the checks where you can. Living checklists can be a great tool here. This is partly why Guidance Explorer is designed the way it is (share and build custom checklists for various purposes.)

  3. Kevin Lam

    Jun 26, 2008 at 6:50 pm

    Spot on! You want to certify against tangible or at least measurable things, not vaporware. “If you can’t measure it, then it never happend” <– a lot of existing models miss this point completely (I can think of at least one major one :P).

    Identified criteria, codified checks and living checklists are beautiful things. That’s exactly the route I’ve been taking with the product we’re developing over at Impacta. Great post.

    –Kevin
    http://www.impactalabs.com

  4. Jiri Ludvik

    Jun 30, 2008 at 9:25 pm

    JD,

    Like other people, I find the concept of macro / micro elements of the dev process interesting and would be interested to find out more. Any chance you could post the chapter that cover the subject? I did some search and found out that Madden & Alexander are only editors. I would like to see if I could track down some more web resources on the large & small & different process models.

    Many thanks
    Jiri
    http://jludvik.net

  5. JD

    Jul 12, 2008 at 7:41 pm

    Hey Jiri

    You’ll actually want the complete book (Scenarios, Stories, Use Cases Through the Systems Development Life-Cycle) — there’s key concepts throughout the book. The main on macro/micro is Chapter 15 – Project Stories: Combining Life-Cycle Process Models.

    For your analysis, I think it helps to think in terms of activities and techniques, artifacts, time, and communication .. as well as think in terms of meta-process models and then instances of process models.

    Here’s some resources you might find useful:
    * Lean Software Engineering – http://LeanSoftwareEngineering.com
    * Wikipedia on Meta-Process Modeling – http://en.wikipedia.org/wiki/Meta-Process_Modeling
    * Wikipedia on V-Model – V-Model – http://en.wikipedia.org/wiki/V-Modell

Trackbacks

  1. Mission Impossible says:
    Jun 23, 2008 at 1:52 am

    […] 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