Home » Process

Evolutionary, Incremental, and High-Risk

23 June 2008 3 Comments

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 project is divided into phases and each phase helps constrain risk.  In Scenarios, Stories, Use Cases: Through the Systems Development Life-Cycle, Ian F. Alexander and Neil Maiden write about the Evolutionary, Incremental, and High-Risk software process models for systems engineering ‘in the large.’

Evolutionary Model

According toe Alexander and Maiden, the Evolutionary model for software engineering is structured as follows:

  • Version 1:  User Requirements Definition, System Requirements Definition, System Design/Architecture, Preliminary Design, Detailed Design, Implementation, Test and Integration, Acceptance and Certification.
  • Version 2:  User Requirements Definition, System Requirements Definition, System Design/Architecture, Preliminary Design, Detailed Design, Implementation, Test and Integration, Acceptance and Certification.
  • Version 3:  User Requirements Definition, System Requirements Definition, System Design/Architecture, Preliminary Design, Detailed Design, Implementation, Test and Integration, Acceptance and Certification.

Incremental Model

According to Alexander and Maiden, the Incremental model for software engineering is structured as follows:

  • User Requirements Definition, System Requirements Definition, System Design/Architecture occur only once up front – User Requirements Definition, System Requirements Definition, System Design/Architecture are factored out of the sequence of incremental deliveries and they occur only once.
  • Individual increments: The physical increments are individually designed, tested, and delivered at successive points in time.
  • Increment 1:  Preliminary Design, Detailed Design, Implementation, Test and Integration, Acceptance and Certification
  • Increment 1 and 2:  Preliminary Design, Detailed Design, Implementation, Test and Integration, Acceptance and Certification
  • Increment 1, 2, and 3: Preliminary Design, Detailed Design, Implementation, Test and Integration, Acceptance and Certification

High-Risk Model

According to Alexander and Maiden, the High-Risk model for software engineering is structured as follows:

  • The project is factored into life-cycle stages:  Explore Concept, Proof of Concept, Full Development, and Operations.
  • Explore Concept – The dominant activities during Explore Concept are User Requirements and System Requirements.
  • Proof of Concept – The dominant activities during Proof of Concept are System Design/Architecture and Preliminary Design.
  • Full Development  – The dominant activities during Full Development are Detailed Design, Implementation, Test and Integration, and Acceptance and Certification.

Evolutionary Model Explained

Alexander and Maiden explain the Evolutionary model for systems engineering:

In essence, it consists of a sequence of successive versions of a product evolving over time, with feedback from version (n) into version (n + 1).  Inside each version cycle, we see the ‘in the small’ system engineering activities embedded.

Incremental Model Explained

Alexander and Maiden explain the Incremental model for systems engineering:

The incremental model is subtly different from the evolutionary model.  In the incremental model, the system is specified and designed in broad architectural terms up front, and (in principle) the design always stays unchanged thereafter.  After the system specification and overall design are completed, an initial piece of functionality called Increment 1 is delivered.  Some time later, some more functionality called Increment 2 is delivered, which fits together with Increment 1.  Still later, Increment 3 is added, fitting together with Increments 1 and 2.  And so on.

Evolutionary vs. Incremental

Alexander and Maiden write that the key distinction between Evolutionary and Incremental is that in the Evolutionary model, the complete cycle of activities is repeated while in the Incremental model, the requirements are factored out up front:

In the Evolutionary model, the complete cycle of activities is repeated for each version, whereas in the Incremental model, the User Requirements Definition, System Requirements Definition, and System Design/Architecture activities are factored out of the sequence of incremental deliveries and occur only once, at the outset of the project.  This distinction is important.  It means that the sum of all increments represents the totality of a single system.  It means that the sum of all increments represents the totality of a single system, which must be analyzed and designed once at the start of the project.  Thereafter, the physical increments are individually designed, tested, and delivered at successive points in time.

The aspect of requirements analysis and design once at the start of the project is not present in the evolutionary model in which the coupling between successive versions is much looser.  Indeed, in the evolutionary model, compatibility between successive versions, although desirable, is by no means assured.  In the incremental model, on the other hand, compatibility between successive increments is de rigueur.

High-Risk Model Explained

According to Alexander and Maiden, to reduce risk, in the High-Risk model you divide the project into a number of successive phases.  The phases include:  Explore Concept, Proof of Concept, Full Development, Production, Installation, In-service support, and Disposal.   Project risks (user need requirements, technology and fitness for purpose) are reduced in a controlled, step-wise fashion.

Use the High-Risk Model for High-Risk Projects

Alexander and Maiden clarify that the High-Risk model is for high-risk projects:

The name of this model should not be misconstrued.  It does not mean that the use of this model will result in a high-risk project!  It means the model is to be used with projects are initially considered to be high-risk.  This model is particularly useful when contracting combined with potentially high financial risk is involved.  By contracting for one phase at a time, both customer and supplier can keep contractual risk under control.

How Does the High-Risk Model Compartmentalize Risk

Alexander and Maiden explain how the phases work together to reduce risk:

For example, some element of architecting/design is needed in the Explore Concept phase, otherwise even a rudimentary meaningful cost/benefit case will be impossible to construct.  Nevertheless, requirements-oriented activities will certainly predominate.  Conversely, although it is certain that during Full Development design, implementation and testing activities will be dominant, there will still be requirements-oriented activities taking place to accommodate and assess requirements changes and refine any requirements not sufficiently defined during the earlier phases.

High-Risk Model Example

Alexander and Maiden illustrate the High-Risk model through an example.  Consider the following scenario:

  • Projects of type ‘Explore Concept’ are the province of the Future Studies Group in Marketing and Strategic Planning;
  • Projects of type ‘Proof of Concept’ are done by the Engineering Directorate;
  • Full Developments are done by a Projects Directorate.

Alexander and Maiden write:

Now, even if we allow that the requisite skills exist in type and number within each part of the organization (admittedly a big assumption!), not being allowed (for whatever reason) to use the right skills mix (because they exist only somewhere else in the organization) will harm the project.  If we just use business analysts and requirements specialists during Explore Concept (and it is not unknown for organizations to behave precisely this way), the output from the Explore Concept phase will be decidedly lopsided.  Business cases will not be worth the paper they’re written on.  Think about it: who constructed the cost side of the cost side of the cost/benefit equation?  What assumptions were used?  Do they bear any relationship on engineering reality?

Key Take Aways

Here’s my key take aways:

  • Evolutionary, Incremental, and High-Risk models 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.

My Related Posts

3 Comments »

  • Evolutionary, Incremental, and High-Risk said:

    [...] JD wrote an interesting post today on Evolutionary, Incremental, and High-Risk. Here’s a quick excerpt: [...]

  • Alex said:

    Your blog is interesting!

    Keep up the good work!

  • Vedestara said:

    hobby center for the performing artshospice lancaster pa glucerna barsislandwaygrill