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
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.
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
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.)
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
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
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