Systems Engineering Lifecycle Processes
Unit 1 Lifecycle & Process Models
Systems Engineering Lifecycle and Process Models
1
2
Basic Lifecycle and Process Models........................................................................................ 2
1.1
Process Models ................................................................................................................ 2
1.2
Process Ordering .............................................................................................................. 3
1.3
Process Relationships....................................................................................................... 5
Advanced Lifecycle and Process Models ................................................................................ 9
2.1
3
4
5
6
Systems Engineering Model (Martin) .............................................................................. 9
Systems Engineering Lifecycle Processes ............................................................................. 12
3.1
Generic Lifecycle ........................................................................................................... 12
3.2
Systems Engineering Technical Processes .................................................................... 15
3.3
Systems Engineering Through Life Decisions .............................................................. 17
Project and Program ............................................................................................................... 19
4.1
Definitions...................................................................................................................... 19
4.2
Real Lifecycle Application ............................................................................................ 20
Systems Engineering Lifecycle Tailoring .............................................................................. 24
5.1
Tailoring Process ........................................................................................................... 24
5.2
Systems Engineering Lifecycle Model Framework ....................................................... 25
Conclusions ............................................................................................................................ 27
Page 1 of 28
 Cranfield University, 2006. All rights reserved.
No part of this publication may be reproduced
without the written permission of the copyright holder
Systems Engineering Lifecycle Processes
Lifecycle & Process Models
Supporting Notes Issue 4
1 Basic Lifecycle and Process Models
1.1
Process Models
Traditional approaches to Systems Engineering process definition produced models such as those
shown below. These models describe the processes required to analyse, design, build and test a
system (product). These models have been particularly applied to software intensive products,
where the “Build” process represents coding and debugging of software modules.
Waterfall Models
Problem
Requirements
Problem
Requirements
System
Requirements
System
Requirements
Preliminary
Design
Preliminary
Design
Detailed
Design
Detailed
Design
Simple Model
With Feedback
Build
Integration
and Testing
Build
Integration
and Testing
Operations and
Maintenance
Operations and
Maintenance
The most important contribution of the waterfall model is that it identifies a minimum set of
Systems Engineering processes required to create a system product.
The overlap between processes shows concurrency. For example, preliminary design start before
detailed design, but cannot be completed until detailed design has reach a define point. Detailed
design will continue beyond the end of the preliminary design, overlapping the start of Build or
Coding.
The lines drawn between the processes could be interpreted in two ways:

A sequence or ordering of those processes, relating to a simple problem solving approach.

Important dependencies between related processes, which must be considered during any
implementation.
The following discussion takes each of these in turn.
Page 2 of 28
 Cranfield University, 2006. All rights reserved.
No part of this publication may be reproduced
without the written permission of the copyright holder
Systems Engineering Lifecycle Processes
Lifecycle & Process Models
1.2
Supporting Notes Issue 4
Process Ordering
The following examples were discussed in a previous unit on ISSE.
The process ordering in these models implies a simple lifecycle for the main system of interest.
However, experience has shown that for complex systems, attempts to organise a project around
this lifecycle do not work.
Some of the problems that occur are:

Lack of “thinking ahead” in early stages ….

…. and inability to go back to early information later in the process;

linked to this, not enough involvement of all stakeholders throughout the project.

This is made worse when completion of stages is linked to payment milestones.
The waterfall models shown previously contained an element of feedback or iteration between
phases. When the waterfall is used as a lifecycle this feedback is generally seen as a last resort to
deal with problems that occur in later stages, e.g. to correct omissions made in the requirements
phase. These iterations are not viewed as a natural or even important part of the lifecycle.
Page 3 of 28
 Cranfield University, 2006. All rights reserved.
No part of this publication may be reproduced
without the written permission of the copyright holder
Systems Engineering Lifecycle Processes
Lifecycle & Process Models
Supporting Notes Issue 4
Even if we can apply such a simple model to the system of interest, other aspects of the whole
system view must be considered in parallel. This type of process model cannot easily support
this.
Whole System Model
DELIVERED SYSTEMS
• Operational System
•
CONTAINING SYSTEM
& ENVIRONMENT
•
SUPPORT
OPERATIONAL
The System which goes into service
• Support System
The System which supports the Operational
System in service.
• Production System
•
DEVELOPMENT
PRODUCTION
The System which manufactures relevant parts
of the Operational and Support Systems.
• Development System
•
The System which develops the Operational,
Support and Production Systems.
• Containing System
DELIVERING SYSTEMS
These systems need to be developed to meet their
individual requirements but are strongly linked
•
•
The Related Systems and the Environment with
which the above Systems interact.
The Acquisition System
This view of the lifecycle models generally defines process as follows
Components of a process
review, audit etc.
Control
work
products,
resources
etc.
Inputs
Outputs
Transformation
Activities
work
products,
measures
This view treats process as a transformation of inputs to outputs. A process is triggered when the
output is required. The assumption being that the input will be available and complete. Control
activities are applied to the process to ensure the output is correct and compete. At this point, the
process is finished.
Page 4 of 28
 Cranfield University, 2006. All rights reserved.
No part of this publication may be reproduced
without the written permission of the copyright holder
Systems Engineering Lifecycle Processes
Lifecycle & Process Models
1.3
Supporting Notes Issue 4
Process Relationships
The “Vee” model of Systems Engineering process is an evolution of the waterfall which
recognises the important relationships between the processes as an essential element of a Systems
Engineering lifecycle.
“Vee” Model
Stakeholder Requirements
System Concept
System Demonstration
and Validation
System Architecture
System Specification
n
itio
pos
om d
Dec annition
i
Def
Sub-Sys. Architecture
Sub-Sys. Specification
Sub-Sys. Integration
and Verification
Sub-System
Test
Sub-System
Design
Int
eg
Qu anrdation
alif
icat
ion
System Integration
and Verification
Production
Time
The model shown contains the same basic processes as a waterfall, but is more obviously focused
upon an integrated system product. This model relates well to the system problem solving
approach discussed in the ISSE module, it describes a process containing:

Customer or Stakeholder needs

System Architecture, identify system functions and structure.

Sub-System Architecture, allocate functions to sub-systems and make technology
choices.

Sub-System Design, production and testing.

Sub-system/system Verification and integration, create the system and test against
requirements

System Demonstration and Validation prove system against customer needs.
As with a waterfall, the overlap between processes shows concurrency. The lines connecting
processes on either side of the “Vee” show a dependency between levels of analysis, design,
Page 5 of 28
 Cranfield University, 2006. All rights reserved.
No part of this publication may be reproduced
without the written permission of the copyright holder
Systems Engineering Lifecycle Processes
Lifecycle & Process Models
Supporting Notes Issue 4
integration and testing. System Verification must be considered as part of the System
specification process, but cannot be completed until an integrated system has been created.
This model gives a more realistic view of a Systems Engineering approach. However, it does not
so easily translate into a lifecycle model that can be used to drive a project. It also fails to deal
with the issues of whole system thinking.
The iterative nature of the
Systems Engineering Process
The spiral model is an attempt to describe both sequence and dependency relationships for
software intensive projects.
Recognize
Need or
Opportunity
Identi
Quan fy and
tify G
oals
Identify and
Quantify Goals
(Boehm’s Spiral
Development Model)
Selec
t
Desig
n
Implementation of
Decisions
Selec
t
Desig
n
e
ad
Tr ies
o
d
D tu
S
te
Crea ts
ep
Conc
Create
Concepts
In
Re cre
so ase
lu
ti o
n
Identify and
Quantify Goals
te
Crea ts
ep
Conc
se n
ea tio
cr lu
In eso
R
se n
ea tio
cr lu
In eso
R
Principle of Successive
Refinement
e
ad
Tr ies
Do tud
S
e
ad
Tr ies
o
d
D tu
S
Selec
t
Desig
n
The exact number of iterations can be tailored for different problems. In the spiral model, the
initial iterations develop early versions of the system to support the design and specification
process. Only the final iteration produces a deliverable product.
The spiral model is good for unclear or fuzzy problems. It allows the developers to explore and
refine their understanding of user needs.
Page 6 of 28
 Cranfield University, 2006. All rights reserved.
No part of this publication may be reproduced
without the written permission of the copyright holder
Systems Engineering Lifecycle Processes
Lifecycle & Process Models
Supporting Notes Issue 4
Spiral to Circle
The spiral to circle lifecycle model, is an extension of the spiral model.
Intermediate Form 1
Intermediate Form 2
Final Form
E Rechtin The Synthesis
of Complex Systems.
IEE Spectrum 1997
In this lifecycle some of the earlier versions of the system can be delivered and used in the real
world. This model works well when the objective is clearer, but the development process is
difficult, expensive or time consuming. In particular, this model is used in domains with rapidly
changing implementation technology such as communication technology.
Both of the above models are attempts to formalise the structure of the lifecycle model for
specific domains. While some tailoring of these lifecycles is allowed, this is only within
proscribed limits. For complex Systems Engineering projects this level of flexibility may not be
sufficient.
One of the issues with process tailoring is the tension between management and control and
technical completeness. Many of the early process models were created to allow easier
management and resourcing of projects. This requires a Predictable process, with a welldefined roadmap. Systems Engineering projects must create and evolve their own lifecycle
model, to fit the needs of the problem being tackled. Tailoring is driven by the type of problem
to be solved, available resources & constraints. Such projects will be harder to manage. For
such projects we must look for a Repeatable process, when roadmap not possible, make sure we
leave an audit trail.
From this discussion, we can see that many of the publish models are caught between three
needs:

The need to manage, organise and resource system development projects.

The need to manage, organise and resource the evolution of whole system capability.
Page 7 of 28
 Cranfield University, 2006. All rights reserved.
No part of this publication may be reproduced
without the written permission of the copyright holder
Systems Engineering Lifecycle Processes
Lifecycle & Process Models

Supporting Notes Issue 4
The need to capture the essential relationships, which will ensure a complete application
of system problem solving.
In the ISSE module we developed a number of Systems Engineering principles. The first set of
these concepts is repeated below:
1. Systems Engineering covers aspects of both Management and Engineering.
2. It must be based upon the principles of Systemic thinking, e.g. boundary, holism,
emergence, viability, hierarchy, completeness, etc.
3. Systems Engineering is a design-based discipline, and must allow for creativity.
4. Systems Engineering also needs a strong process element, ensuring a complete
application of systems problem solving.
Thus we must look for a way of defining Systems Engineering lifecycle and process which
satisfies these principles.
Page 8 of 28
 Cranfield University, 2006. All rights reserved.
No part of this publication may be reproduced
without the written permission of the copyright holder
Systems Engineering Lifecycle Processes
Lifecycle & Process Models
Supporting Notes Issue 4
2 Advanced Lifecycle and Process Models
2.1
Systems Engineering Model (Martin)
Martin (Systems Engineering Guidebook) attempts to solve this problem by defining separate
models for process ordering and relationships.
SE Management
Team
Requirement & Architecture
Definition Team
Development
Teams
SI&V Team
Originating Requirements
SE
Management
Plans,
e.g. SEMP
Arch.
Req.
Req. & Arch. Definition
SE Analysis & Optimisation
SE
Planning
SE
Control &
Integration
Req.
Analysis
Functional
Anal/Alloc
SI&V
Planning
Synthesis
Design,
Prod.
Req. & Arch
Documentation
Program
System
Integration &
Verification
Management &
Reporting
T&E
Plans
Product
SI&V
Development
SI&V
Execution
Product Char.
Systems Engineering Guidebook (James Martin, 1997)
Product
The above model applies to any system of interest. It describes a template for the application of
Systems Engineering processes to create system elements, in response to originating
requirements. The processes have been further expanded to define the top-level activities
contained in each.
In Martins model at any level in the architecture, a component can be passed to a development
team for design and production of that component. The component development team may use
the Systems Engineering process if the nature of that component warrants.
Page 9 of 28
 Cranfield University, 2006. All rights reserved.
No part of this publication may be reproduced
without the written permission of the copyright holder
Systems Engineering Lifecycle Processes
Lifecycle & Process Models
Supporting Notes Issue 4
Martin suggests that Systems Engineering processes should be applied to a component if:

The component is complex

The component is not available off-the-shelf

The component requires special materials, services, techniques, or equipment for
development, production, deployment, test, training, support or disposal.

The component cannot be designed entirely within one engineering discipline.
Martin uses a simple lifecycle model describes the ordering of a project. Each stage of the
lifecycle describes the objectives of the project at a moment in time, centred on the development
of the system of interest.
Lifecycle Phases
(Martin)
time
Development Production Deployment
Support
Operation
Disposition (prior to operations)
e.g. disposal of waste, scrap,
obsolete equipment, etc.
Page 10 of 28
 Cranfield University, 2006. All rights reserved.
No part of this publication may be reproduced
without the written permission of the copyright holder
Disposition
e.g. disposal of waste,
consumables, energy devices,
failed components, etc.
and disposal of system at end of
life
Systems Engineering Lifecycle Processes
Lifecycle & Process Models
Supporting Notes Issue 4
Process Activities &
Acquisition Phases (Martin)
Finally, Martin attempts to show how the processes map onto the lifecycle stages, for the system
of interest. If nothing else, this shows the difficulty of describing this relationship in a generic
way!
Concept
Feasibility
Development
Production/ Operation
& Support
Systems Engineering Management
Req Analysis
SI&V
System Design
Current Engineering
& field Support
SI&V
Product Design
SI&V
Process Design
In this model, the lifecycle stages describe the focus of Systems Engineering effort as we
progress through a project. During the first part of the project Systems Engineering architecture,
requirements and evaluation activities are repeated to address a series of questions:

What is the problem?

What is the “System Solution”?
o Described as a collection of existing systems and proposed new systems,
o this should consider whole system relationships

How do we design one or more Products to implement the solution

How will we create the products?
The second part of the project is concerned with the creation of products, and their integration
into the system solution. This includes a number of levels of Verification or Validation as
appropriate.
Finally, the lifecycle considers the operation and support of the new system; again as an instance
of the core Systems Engineering “design” processes. Martins’ model also includes a Systems
Engineering Management process, which coordinates effort across the lifecycle as needed.
Page 11 of 28
 Cranfield University, 2006. All rights reserved.
No part of this publication may be reproduced
without the written permission of the copyright holder
Systems Engineering Lifecycle Processes
Lifecycle & Process Models
Supporting Notes Issue 4
3 Systems Engineering Lifecycle Processes
3.1
Generic Lifecycle
Lifecycle is a concept used to help organise and manage the changing Systems Engineering
activities related to a particular system over its life. Lifecycle is strongly related to the problem
being considered. We can consider two extremes of problem type with which a Systems
Engineering Lifecycle might be faced.
Tame Problems:
•
A well-defined problem is a problem that has a clear and precise definition.
•
The solution is clearly specifiable and is clearly recognizable as a solution
•
Well-defined problems often have generally known solutions. They are solved using
standard methods, methods of similar problems e.g.: puzzles, lower level mathematics,
science, and hard engineering.
•
Tame problems are not necessarily “easy” and may be quite complex and rely on
significant expert knowledge to solve (e.g. chemistry, mechanical engineering), but they
lend themselves to analysis and solution by known techniques.
•
A traditional linear process is sufficient to produce a workable solution to a really tame
problem in an acceptable period of time, and it is clear when a solution has been reached.
•
This relates to clear, well bounded requirements, a well understood & precedented
architecture, obvious (limited) options/choices and corresponding flow down of
requirements etc
Ill-defined problems:
•
If it is not clear from the beginning what the problem is and, thus, what a solution is, then
the problem is an ill-defined problem
•
Finding a solution requires in addition, finding out what the real problem is.
•
Specifying the problem and the solution develop in parallel and drive each other.
•
We need much more iteration and exploration to establish a consistent problem and
solution definition (i.e. useful, acceptable and achievable)
•
The solutions found are often such that they still could be improved and it is up to the
principal stakeholders to decide when enough is enough.
•
Unexplored (new) problem and/or solution domains often contain ill-defined problem
issues
•
“Foggy problems” … “Wicked problems”
The effects of such ill-defined problems on the decision making process in engineering projects
has been considered by a number of researches. For example Horst and Webber (1984) define
Wicked Problems as follows:
Page 12 of 28
 Cranfield University, 2006. All rights reserved.
No part of this publication may be reproduced
without the written permission of the copyright holder
Systems Engineering Lifecycle Processes
Lifecycle & Process Models
Supporting Notes Issue 4
•
There is no definitive formulation of a wicked problem.
Formulating the problem and the solution are part of the same thing. Each attempt at
creating a solution changes the understanding of the problem.
•
Solutions to wicked problems are not true-or-false but good-or-bad.
Since there are no unambiguous criteria for deciding if the problem is resolved, getting all
stakeholders to agree that a resolution is ‘good enough’ can be a challenge.
•
There is no immediate and no ultimate test of a solution to a wicked problem.
Solutions to wicked problems generate waves of consequences, and it is impossible to
know how all of the consequences will eventually play out.
•
Wicked problems do not have a well-described set of potential solutions.
Various stakeholders will have differing views of acceptable solutions. It is a matter of
judgment as to when enough potential solutions have emerged and which should be
pursued.
•
The causes of a wicked problem can be explained in numerous ways.
There are many stakeholders who will have various and changing ideas about what might
be a problem, what might be causing it, and how to resolve it.
•
The designer has to produce a good solution.
A scientist is expected to formulate hypothesis, which may or may not be supportable by
evidence. A designer doesn’t have such a luxury, they are expected to get things right.
Wicked problems arise when an organization must deal with something new, with change, and
when multiple stakeholders have different ideas about how the change should take place.
How might you identify a wicked problem?

If requirements are volatile, constraints keep changing,

Stakeholders can’t agree and the target is constantly moving.
The most fundamental rule for handling wicked problems is that they must not be treated like
tame problems. For wicked problems one cannot understand the problem without knowing about
the relevant issues of a solution concept. The appropriate way to tackle wicked problems is to
explore them. Consensus emerges through the process of laying out alternative understandings of
the problem, solution and interactions, competing interests, priorities and constraints. The
application of more formal analysis tools is not helpful before the problem can be articulated in a
concise, agreed upon, well-bounded manner.
Investigation of the problem and discussion of alternative will only take us so far. A point is
reached when rightly or wrongly we have identified a bounded problem and proposed a solution.
At this stage it is necessary to focus the energy of the lifecycle on the creation of a complete and
viable solution. System investigation must concentrate on the complete understanding of the
chosen solution and the design of one or more products and services. Any changes to the
problem statement should be avoided at this stage, unless they are significant enough to stop the
creation of a solution and return to problem investigation. This stage of the lifecycle is often
associated with a contractual relationship between acquirer and supplier. We should consider
success at this stage of a systems lifecycle in terms of the cost and time effective delivery of the
Page 13 of 28
 Cranfield University, 2006. All rights reserved.
No part of this publication may be reproduced
without the written permission of the copyright holder
Systems Engineering Lifecycle Processes
Lifecycle & Process Models
Supporting Notes Issue 4
agreed solution. Questions of whether the solution acquired was really needed and can be used
to create the needed capability are parts of a wider lifecycle consideration.
Once a system product or service has been created its lifecycle will focus on supporting its use.
Part of the design stage should be to consider enabling system issues such as support, training,
etc. For the lifecycle of a specific system, we must ensure that all identified system relationships
are fulfilled during its use. It is also necessary to understand the impact of disposing of the
system at the end of its life.
From this discussion we can describe a generic Systems Engineering Lifecycle, consisting of
three Phases of life.
Generic Lifecycle
Problem
Proposed
Solution
Identified
The “Fuzzy Front End”
(Smith and Reinertsen)
•Multidisciplinary teams
•Overall system focus
•Through life Planning
Transition
into service
Implement a
confident,
successful project
Operate and
Sustain a useful
Capability
•Project Organisation
•Product/Service focus
•Workflow Planning
•User Organisation
•Operational focus
•Sustainment Planning
Time
Note, this lifecycle describes the Systems Engineering needed to propose, create and use a
system of interest. The application of these ideas to all aspects of a complex enterprise such as
defence is discussed later.
Page 14 of 28
 Cranfield University, 2006. All rights reserved.
No part of this publication may be reproduced
without the written permission of the copyright holder
Systems Engineering Lifecycle Processes
Lifecycle & Process Models
3.2
Supporting Notes Issue 4
Systems Engineering Technical Processes
The Systems Engineering Lifecycle describes the changing objectives of a project over time.
The lifecycle can be used to identify who should be involved in the project at a particular time. It
can also be used as the basis for project planning, resourcing and control.
Within each lifecycle stage, more detailed Systems Engineering processes and activities are
performed to help achieve the objectives of the stage. We can view the technical Systems
Engineering processes as a simple problem solving approach, applied successively to Systems
Engineering decisions. One such simple model is as follows:
0. Understand the Problem Context

Who is asking the question and why?

What are the issues and constraints which will shape solution choices?
1. Bound & Understand the Problem
•
Capture stakeholder needs and constraints, identify inconsistencies and conflicts,
resolve conflicts
•
Identify a clear set of criteria against which to evaluate solutions
2. Generate potential solution options
•
•
Generate potential solution(s)
•
Changes to the “wider system” which contains the problem
•
Identify new or modified system elements
Evaluate the alternatives and select the best solution
•
Compliance with the Requirements
•
Viability of solution
3. Implement the chosen solution
•
Build/Modify/Buy new system elements
•
Some of these may themselves become System Problems
•
Integrate elements to create solution
•
Prove that solution works as expected
4. Review the success of the solution
•
Install the solution into the “real world”
•
Prove that the problem has been solved
The following simple model describes the main Systems Engineering processes that can be
considered within a lifecycle stage to achieve the problem solving approach describe above.
Page 15 of 28
 Cranfield University, 2006. All rights reserved.
No part of this publication may be reproduced
without the written permission of the copyright holder
Systems Engineering Lifecycle Processes
Lifecycle & Process Models
Supporting Notes Issue 4
Systems Engineering Lifecycle Process ‘V’ Model
(See ISO 15288 Systems Engineering Lifecycle Processes)
Validation &
Transition
S takeholder
Requirements
Requirements
Analysis
Verification
Architectural
Design
Integration
Sub-S ystem
Design
Implementation
Sub-S ystem
verification
Build & Test
The V model shows the basic Systems Engineering processes and their dependencies. The dotted
lines across the V indicate the strong link between front-end analysis and design processes and
their equivalent integration and testing processes. Thus System Requirements analysis must
consider how requirements will be verified, and plan for the verification process; Verification
can only be completed when an integrated system has been acquired and the verification system
is in place.
The implementation processes are highlighted. In the simplest case a single level of system
design will lead us to a set of sub-systems that can be designed, built and tested and then taken as
the input to system integration. In complex system projects, a number of levels of Systems
Engineering will be needed before we get to this stage. Thus implementation for one level of
system of interest will require an application of Systems Engineering to a more constrained
system problem.
As has already been stated, Systems Engineering is about more than just technical processes.
The application of Systems Engineering to a single level of system is described by James Martins
(Systems Engineering Guide Book, 2001). For a given system level, originating requirements
are used as the basis for analysis and design of a system solution. Related to this will be
associated Verification and Integration activities. The design and production activity for each
system element may be another instance of the above process. At some lower level, this may
lead to the build of purchase of components. These can then form the input to the lowest level of
sub-system build and integration, completing the recursive application of Systems Engineering
processes.
All of the above activities must be planned, monitored, controlled and integrated at each level of
application.
Page 16 of 28
 Cranfield University, 2006. All rights reserved.
No part of this publication may be reproduced
without the written permission of the copyright holder
Systems Engineering Lifecycle Processes
Lifecycle & Process Models
3.3
Supporting Notes Issue 4
Systems Engineering Through Life Decisions
This view gives a baseline description of the essential elements of a Systems Engineering
approach, but does not include any trade-off or decision-making. The following diagram shows
three critical trade-off and decision levels that must be delivered across a project lifecycle.
Critical Systems Engineering Decisions
Stakeholder Understand the context and describe Problem Validation &
Transition
Requirements
Requirements
Verification
Select between alternative “System Solutions” (all
LoD)
Analysis
Architectural
Integration
Design
Select
between alternative Viable System Products
Sub-System
Design
Implementation
Sub-System
verification
Build & Test
1. We must decide on the specific problem to solve, from a range of potential stakeholder
concerns.
2. We must decide upon a complete system solution, taking account of all Lines of
Development.
3. For any new or modified products or services, we must upon the design options to
produce a viable design with acceptable cost/time and risk.
Page 17 of 28
 Cranfield University, 2006. All rights reserved.
No part of this publication may be reproduced
without the written permission of the copyright holder
Systems Engineering Lifecycle Processes
Lifecycle & Process Models
Supporting Notes Issue 4
In the following diagram we have mapped this description of key Systems Engineering decisions
onto the generic lifecycle model.
As we can see, the Systems Engineering V covers the central portion of the lifecycle. It overlaps
with the fuzzy front end, and with operate and sustain; but does not fully cover them. In this
simple model, we have identified two additional processes needed to complete the lifecycle:

Identify Capability need looks at the range of potential problems facing an enterprise or
domain, and identifies specific problem areas for further concern. In a commercial
application this might be done by a marketing or commercial function. In an organisation
such as MOD we can take an enterprise wide strategic view of our own future needs; this
includes an overall allocation of resources and top-level ownership of any subsequent
work.

Install, Operate and Sustain takes developed system products or services form all lines of
development, and turns them into a useable and supported capability improvement. In the
commercial world this might include customer support or training activities. In defence
we have a more integrate, top down, approach to capability use; one of the functions of
which is to provide feedback into the identification of future needs.
We could view these two processes as complex system problems requiring an element of system
thinking, if not the formal application of a Systems Engineering process. This is particularly true
for the complex environments of 4th and 5th age Systems Engineering. A further discussion of
these aspects of the acquisition lifecycle, and the extent to which we can apply Systems
Engineering to it, is covered later in the course.
Page 18 of 28
 Cranfield University, 2006. All rights reserved.
No part of this publication may be reproduced
without the written permission of the copyright holder
Systems Engineering Lifecycle Processes
Lifecycle & Process Models
Supporting Notes Issue 4
4
Project and Program
4.1
Definitions
These definitions support the application of Systems Engineering to real world commercial
problems.

Project: A technical and commercial undertaking with defined timescales and objectives.
A project is responsible for an identified System of Interest, for an agreed part of its
lifecycle

Programme: A collection of related projects associated with the sustainment and
evolution of a System of Systems

Lifecycle Model: A framework of processes and activities concerned with the lifecycle
of a Project. A framework of Projects and Deliverables concerned with the lifecycle of a
Programme
Levels of System
The following diagram, taken from ISO 15288, attempts to show the relationship between levels
of system and projects.
Hierarchical view
of System Structure
Terms associated with
Hierarchical System View
System
System
Is
composed of
System
1:many
System Element
1:many
1:many
Project Hierarchy
associated with
System Structure
Is
responsible
for
Is
responsible
for
Project
1:many
Project
1:many
The hierarchical view of systems described in System Sciences allows for multiple levels of
system, each containing a number of elements which may themselves be considered as systems.
The decision to identify a project with responsibility for part of the lifecycle of a particular
system element is driven mostly by practical issues of resource, technical expertise and
commercial relationships.
Page 19 of 28
 Cranfield University, 2006. All rights reserved.
No part of this publication may be reproduced
without the written permission of the copyright holder
Systems Engineering Lifecycle Processes
Lifecycle & Process Models
Supporting Notes Issue 4
To fully explore the aircraft problem, this project would need to consider all possible
dependencies, needs and constraints within the air transport capability. This project would not
require a separate project for each system element. They might choose to acquire the propulsion
system from an external supplier. In which case, this would create a new project.
At a higher level, an organisation planning to acquire and operate an air transport capability will
need to develop relationships with the aircraft project. They may also need to consider projects
for new infrastructure, airport improvements of crew training.
4.2
Real Lifecycle Application
Generic Systems Engineering Lifecycle describes the Systems Engineering needed to propose,
create and use a system of interest.
Generic Lifecycle
Problem
Proposed
Solution
Identified
The “Fuzzy Front End”
(Smith and Reinertsen)
•Multidisciplinary teams
•Overall system focus
•Through life Planning
Transition
into service
Implement a
confident,
successful project
Operate and
Sustain a useful
Capability
•Project Organisation
•Product/Service focus
•Workflow Planning
•User Organisation
•Operational focus
•Sustainment Planning
Time
How does the lifecycle of this system relate to other lifecycles?

The lifecycle of its related systems or of systems which change the environment.

The lifecycle of enabling systems, such as production, support, training.

The lifecycle of alternative solutions, if the system is being created as part of an
evolutionary approach to a complex problem.

The lifecycle of the capabilities within which the system is used, or of the enterprise for
which the capability has been created.
The simple answer to this is that the above model represents the simplest building block of
lifecycle thinking; the lifecycle of a single system entity. In general, Systems Engineering is
performed at three levels:
Page 20 of 28
 Cranfield University, 2006. All rights reserved.
No part of this publication may be reproduced
without the written permission of the copyright holder
Systems Engineering Lifecycle Processes
Lifecycle & Process Models
Supporting Notes Issue 4
1. System Project, a bounded commercial undertaking to create one or more closely
related products and services.
2. System Program, a collection of projects which work together towards a larger goal,
e.g. the sustainment and evolution of a Capability.
3. Enterprise Management, the strategic organisation or group of organisations which
benefits from the use of one or more capabilities within a specific environment.
The following diagram describes the high level relationships between these three levels of
lifecycle thinking.
Acquisition Lifecycles
Enterprise
Lifecycle
New Capability
Operate/Sustain Capabilities
Gap?
Gap?
LoD Integration
Capability
Options
Business
Capability
Lifecycle
In-Service Acceptance
Contract to Supply
System Product
or Service
Lifecycle
Contract Acceptance
Development
System/Technology
Options
The lifecycle of an enterprise is interested in the operation and support of capabilities to achieve
its mission in its environment. This lifecycle must be continuous and evolving at an appropriate
rate to meet the current and future challenges of the environment. To deal with this an enterprise
must assess potential gaps in its current and future capabilities, and make strategic business
decisions about which of these to invest in. While we can discuss this as a kind of system
lifecycle, it is more correctly a systems approach to strategic management.
The identified capability gaps will require investment in new or updated system products and
services, or a revised use of existing systems. The capability lifecycle begins with the
assessment of alternative options to change the capability. If a selected options requires the
acquisition of a new or modified system this will trigger a system project, and usually a supply
contract. Once an updated system has been created, it must be integrated into the existing
capability. In defence we identify a number of Lines of Development, to describe those
responsible for this integration.
Page 21 of 28
 Cranfield University, 2006. All rights reserved.
No part of this publication may be reproduced
without the written permission of the copyright holder
Systems Engineering Lifecycle Processes
Lifecycle & Process Models
Supporting Notes Issue 4
Defence Lines of Development (LODs), and responsible organisations:

Training
DCDS(C)

Equipment
DCDS(EC)

Personnel
DCDS (Pers) and Personnel Director

Information
DCDS(C)

Doctrine & Concepts
Policy Director

Organisation
Finance and Planning Director

Infrastructure
Chief Executive Defence Estates

Logistics
CDL
Thus, a program lifecycle is made up of a number of generic project lifecycles.
Program Lifecycle
Research Project
Related Project
System 1A
System 3
System 1B
Acquisition Project
System 2
2.1
Training
2.2
Training
Infrastructure & Support
The early stage of a project might form part of a capability investigation, with the system as an
alternative solution in one or more options. During the development stage of a systems life, it
must be synchronised with the lifecycles of enabling or related systems which affect it. For
example to agree interfaces, or to ensure that LoD issues have been fully considered. The
operation and support stages of life will play a role in one or more capabilities. This might be as
part of a research program, as a system to support the creation of use of other systems, or as a
direct operational system.
Page 22 of 28
 Cranfield University, 2006. All rights reserved.
No part of this publication may be reproduced
without the written permission of the copyright holder
Systems Engineering Lifecycle Processes
Lifecycle & Process Models
Supporting Notes Issue 4
Thus, our simple lifecycle model of a given system of interest forms the basis for a complex
lifecycle view at the enterprise and capability levels. These lifecycle decisions provide the
context for the lifecycle of a specific product or service, across all of the LoD.
We might consider the running of a complex enterprise, such as the UK MoD, as a portfolio of
capability programs, with associated funded projects covering all aspects of the LoD.
Enterprise Lifecycle
Research
Infrastructure
Recruitment
& Training
Acquisition
Operation
(from Research)
The ISO international standard for Systems Engineering (ISO 15288) defines a lifecycle model
as the specific set of lifecycle stages employed on a program or project, based upon a set of
generic lifecycle stages. The choice of lifecycle model should depend upon the problem being
solved. At a capability level this will depend upon the pace of change in the environment and the
type of capability. At a project level it might be driven more by commercial supply chain issues
or technology constraints.
Page 23 of 28
 Cranfield University, 2006. All rights reserved.
No part of this publication may be reproduced
without the written permission of the copyright holder
Systems Engineering Lifecycle Processes
Lifecycle & Process Models
Supporting Notes Issue 4
5 Systems Engineering Lifecycle Tailoring
5.1
Tailoring Process
The purpose of a Lifecycle model is to help Systems Engineers to select appropriate stages and
processes for a particular application. Lifecycle models are generally defined as a set of specific
stages, with defined objectives. The model may also include an indication of the information
baselines; criteria for risk gates; and advice on how to organise or tailor the gates to specific
problems.
Systems Engineering Lifecycle models attempt to expand the traditional process model to deal
with

Mapping to a wider set of Lifecycle stages.

Application of Systems Engineering processes to successive levels of system.

Inclusions of a wider range of through life processes.
In general, they avoid defining process sequence, relying instead on tailoring of processes within
identified constraints or rules of precedence describing

all of the Systems Engineering processes required for successful completion of a
Lifecycle Phase.

all aspects of a fundamental Systems Engineering problem solving approach

the dependencies and precedence between activities, to ensure the application of a
complete problem approach.
The model can thus be viewed as a generic or template project plan, requiring only (!) estimation,
resource planning and milestone setting.
Within each stage, Lifecycle processes will be tailored to achieve the objectives of the stage.
The tailoring process must consider the needs of all systems in the whole system view, but
related to the need to progress the system of interest in the current stage. This will include the
selection of appropriate Activities.
Through Life (or Project) processes will be required to support engineering activities in each
phase.
A general approach to lifecycle tailoring is described below:
1. Identify the features of the problem, which will drive the lifecycle approach.
2. Produce a flexible lifecycle model tailored to deal with those issues.
Page 24 of 28
 Cranfield University, 2006. All rights reserved.
No part of this publication may be reproduced
without the written permission of the copyright holder
Systems Engineering Lifecycle Processes
Lifecycle & Process Models
Supporting Notes Issue 4
3. Produce a Programme plan which:
a. Identifies a set of related Projects
b. Describes the commercial and contract relationships between these projects
c. Identifies the relationship and interfaces between the projects
d. Assigns the necessary resources to each project
4. Within the structure of this plan, for each project, identify processes and activities which:
a. Are appropriate to the lifecycle approach
b. Fit the objectives of the current stage
c. Satisfy practical project real world constraints
d. Satisfy the requirements of a rigorous Systems Engineering approach. This will
often involve the use of standards.
5. Communicate the lifecycle model, and detailed processes & activities to all those
involved in the project.
6. Iterate and evolve the lifecycle as required.
5.2
Systems Engineering Lifecycle Model Framework
To apply Systems Engineering to a project we need to tailor the Systems Engineering lifecycle
and processes to the specific problem. For complex real world acquisition problems, we will
need to define and manage groups of projects as Systems Engineering programs. This approach
will help us to:

Deal with Whole System lifecycle issues between the System of Interest and its Enabling
Systems.

Deliver groups of related Projects to provide an Incremental delivery of Capability.

Take an Evolutionary approach to exploring complex system problems.

Manage complex System of Systems Acquisition issues.
Page 25 of 28
 Cranfield University, 2006. All rights reserved.
No part of this publication may be reproduced
without the written permission of the copyright holder
Systems Engineering Lifecycle Processes
Lifecycle & Process Models
Supporting Notes Issue 4
To help in the identification of the problem type, and associated lifecycle approach, the following
model can be used.
Lifecycle Models
Three extremes of Lifecycle approach
“ Optimised”
Real projects
“ Evolutionary”
“Increment al”
This model describes three extremes of lifecycle approach, related to extremes of problem type.
An optimised approach is focused on solving a well-bounded problem as efficiently as possible.
This approach applies when:

Specify system needs and performance measures are known and predictable; with clear
understanding of required behaviour, function and constraints.

Architectural design can be optimised to maximise specific performance.
An incremental approach is appropriate for problems in which the solution itself is understood,
but the development and production of that solution is complex or highly constrained by cost or
time. This approach applies when:

Specify system needs and effectiveness measures are fairly well understood.

Some doubt exists about the full range of behaviour and constraints.

Time, cost and other commercial or operational constraints apply.
An evolutionary approach is appropriate for problems for which the solution is unclear, and
further exploration of the problem domain is needed.. This approach applies when:

Specify system needs and effectiveness measures are not well understood

There are doubts about exact nature of problem scenarios.

A range of potential solution concepts exist.
This framework is explored later in the module.
Page 26 of 28
 Cranfield University, 2006. All rights reserved.
No part of this publication may be reproduced
without the written permission of the copyright holder
Systems Engineering Lifecycle Processes
Lifecycle & Process Models
6
Supporting Notes Issue 4
Conclusions
Systems Engineering Lifecycle and process descriptions must deal with two views:

The ordering of Systems Engineering processes to deal with the problem.

The dependencies between Systems Engineering processes essential for a complete
problem solving approach.
Many models have mixed up these two concepts, leading to problems in project application.
More advanced Systems Engineering descriptions (such as Martin) clearly separate a generic
Systems Engineering process model from its application via a lifecycle model.
To ensure that we can deal with a full range of problems, including problems which are:

Hard to understand or formulate

Hard to create, integrate or prove

Hard to operate or sustain
The lifecycle of any system has three generic parts:

The exploration of capability and identification of gaps and opportunities (“fuzzy front
end”)

The development of one or more new products or services

The operation and sustainment of a resulting capability
The application of Systems Engineering to a single lifecycle can be split simply into:

Understand problem; plan for and assess solution

Propose and Select viable system solutions

Design, Implement, Integrate and Test system products
At each stage critical decisions and design choices are made, these may require trade-off and
evaluation of alternatives. Other problems are posed, together with information needed to reach
a decision in the future. The balance of effort between the above varies across the lifecycle with
the type of application. All of these activities are supported by a process of through Life
Management and Control.
Page 27 of 28
 Cranfield University, 2006. All rights reserved.
No part of this publication may be reproduced
without the written permission of the copyright holder
Systems Engineering Lifecycle Processes
Lifecycle & Process Models
Supporting Notes Issue 4
Systems Engineering lifecycle and process thinking can be applied:
• To the Creation and Use of Products, delivered by Projects.
• To the Delivery and Sustainment of Capability, evolved via Programs
• To the Planning and Management of Enterprises, through strategic management of a
portfolio of Programmes.
A Program is responsible for the complete identification of a Capability Problem; the acquisition
of new or modified Product and Services solution; and the integration of these into existing
environment, Operational Use & Support.
A Systems Engineering Projects in Defence starts from an identified Capability Gap (single
customer focus). The project must consider alternative Products and Services across all LoD to
close the gap. If a feasible and cost effective solution exists this will generally require the
development of new or modifies existing system, to Cost/Time/Performance. Once a in use,
these products may need continuing project support in some form.
Through Life systems management starts at the program level with the allocation of resources to
program blocks. It continues across the program, ensuring consideration of cross project
relationships and trade-offs. This requires each project to consider its own system and resource
issues, and to participate in the solution of problems across the program when needed.
Page 28 of 28
 Cranfield University, 2006. All rights reserved.
No part of this publication may be reproduced
without the written permission of the copyright holder