The Capability Maturity Model® Integration (CMMISM), Version 1.1, characterizes
systems engineering and systems engineers thus: "systems engineering covers the development of total systems, which may
or may not include software. Systems engineers focus on transforming customer needs, expectations, and constraints into
product solutions and supporting these product solutions throughout the life of the product." A system, which might
contain hardware (computational and non-computational), software and human workers, delivers some needed operational
capability to its users, and might itself require supporting systems for successful operation. Systems engineering has
to consider not only the specification and creation of a product, but also the in-service support of that product (for
example, its maintenance) to ensure its continued utility. This view of a system extends that of the core RUP, where
system is used to mean software and the computational hardware on which it runs. Additionally, it is likely the
case that most applications of RUP for Systems Engineering will be to large developments, where the subsystems into
which the system is decomposed are themselves complex enough to be regarded as systems, with the implication that RUP
(or even RUP for Systems Engineering) could be reapplied, in total, to their development.
A systems engineering process has, then, to be able to deal with systems that are arbitrarily complex and large, and
which require a multidisciplinary approach in their construction, deployment and support. The whitepaper, the Rational Unified Process® for Systems Engineering (q.v.) describes the motivation
for the "RUP for Systems Engineering" (RUP SE) plug-in, to extend RUP (which, by default, concerns itself with software
engineering) to address the problems of size and complexity (in the user needs and requirements as well as design),
quality of service, and other engineering specialties, faced by the Systems Engineer. The RUP SE plug-in is of interest
to the managers of a systems (as defined previously) project, as well as those concerned with system analysis and
specification, system architecture, implementation and test.
The view here is that systems engineering should not be added as a separate RUP discipline, to underscore the unified
nature of the teams, and the unified nature of the process. Thus, where RUP without the RUP SE plug-in is a
process for software engineering, RUP with the RUP SE plug-in is (or should become over time) a process for
systems engineering (of which software engineering then becomes a subset). The default RUP disciplines, business
modeling, requirements, analysis and design, implementation, test, deployment, and the supporting disciplines,
configuration and change management, project management and environment, are as much part of the fabric of systems
engineering as software engineering. Therefore, having systems engineering as a peer discipline, for example, of
requirements, made less sense than having requirements part of (invoked by) a systems engineering process. So
RUP SE adds new tasks, artifacts and activities and so forth, and modifies some existing ones to provide support
for the wider scope and additional concerns of systems engineering.
With this integration, systems engineering is not obviously delineated in the Web site, and so for those learning the
process and interested primarily in systems engineering, this roadmap is intended to help them find the relevant
assets.
It is also important to understand the way the systems engineering plug-in is articulated with respect to the rest of
RUP: RUP SE expects that systems are composed of subsystems, which in turn might be composed of subsystems, and so on.
The aim is that RUP with the systems engineering extensions be applicable at any level in this hierarchy, including the
lowest level, at which, at least for software, the behavior of a subsystem is realized by collaborations of software
objects (and links). Also, a subsystem development, viewed from the level of its developers, is like the total system
development in its process needs, that is, it needs to have an inception phase, elaboration phase, and so on. So, if
you look at the overall system development plan, you find the RUP sequence of phases, then looking "inside," you find a
number of RUP lifecycles, one for each subsystem. This is illustrated in the diagram below which uses NASA's Next
Generation Space Telescope (NGST) as an example. The top level plan (shown as Level 1) is for the NGST System, and
contains the RUP sequence of phases. In these top level activities, the overall requirements for the NGST are
established and the decomposition, reflected at Level 2, into Observatory, Ground Segment and Launch Segment, is
established. At Level 2, a complete set of lifecycle plans is established for each subsystem.
Levels of Plans.
This does not mean the top-level activities are simply rolled-up from the lower levels. There are requirements, design,
and other activities at each level, and separate logical plans. This permits one to describe the process simply,
but still be able to construct plans of arbitrary complexity by recursive application of the RUP lifecycle. At any
level, you then choose the activities, tasks, and steps within the tasks, appropriate to your purpose. As an example,
consider the Capability Pattern: Analysis & Design - Systems Engineering (workflow
diagram): a late elaboration iteration for a systems development (at, for instance, Level 1 as shown above) appears to
consist only of the Activity: Refine System Architecture and Activity: Analyze System Behavior (looking at the right-hand side of the workflow
diagram). This is correct at the level it describes (Level 1 in this example) - there might be lower-level work taking
place (in a concurrent RUP lifecycle) that contributes to this iteration - and in the example depicted above, there is
lower-level work, at Level 2 on the Launch Segment, for example, and then Level 3 on the Launch Vehicle, and so on.
These concepts, and the relationship of the artifacts produced at one level to levels above and below, are illustrated
in Delivery Process: Systems Engineering Lifecycle.
The new or modified elements are tabulated below. New elements are indicated with an asterisk. Changes that are systems
engineering-specific, in existing elements, have been tagged so that they can be displayed in a different font if
desired (using a cascading style sheet entry in the file rop.css).
Other related guidelines and concepts:
RUP SE makes no changes to Business Modeling in this release. However, note that RUP SE assumes the existence of
at least an initial Vision document, and perhaps the beginnings of a Business Case and Risk List, coming from some precursor enterprise modeling effort that
is either complete or proceeds independently of system development (at the enterprise level, for example). Currently,
the Business Modeling discipline does not produce these artifacts (although it does produce the Supplementary
Specifications, Use-Case Model, and Analysis Model in sketch form at the System level).
The description of project management in RUP SE differs only slightly from standard RUP. Pragmatically, the
actual planning and management tasks are more complex because the project manager (the incumbent, not the RUP role) has
potentially to engage at several levels, and produce and synchronize the lower levels of planning so that they serve
the top-level plan. Looking at the systems engineering sample iteration plans, you see subsystem development shown as a
summary task: this expands into a set of subtasks which have also to be planned, if not directly by the Project
Manager, then with his/her supervision and agreement. In such arrangements, often called programs, the Project Manager
might have significant additional coordination and dependency management responsibilities which are not canvassed in
RUP SE in this release.
-
Activity: Conceive New Project
In this activity, the Task: Initiate Project is changed in RUP SE so that it produces
the first draft of the Work Product: System Development Plan instead of the Software
Development Plan. The description of Initiate Project shows both artifacts. They are alternatives, depending on the
context for invocation of Initiate Project.
-
Activity: Evaluate Project Scope and Risk
There is no change to this activity.
-
Activity: Develop Plans This activity is named Develop Software
Development Plan in standard RUP. It has been renamed to be applicable to system and software development. The
following tasks are changed for RUP SE:
-
Project Planning Review - To show review of the System
Development Plan as an alternative.
-
Compile Plans - This task is named Compile Software
Development Plan in standard RUP. It has been renamed to apply to system or software development and has an
alternate set of steps for RUP SE.
-
Plan Phases and Iterations - In RUP SE, the System
Development Plan is added as an alternative output.
-
Define Monitoring and Control Processes - The System
Development Plan is added as an alternative input/output item and an additional step is added in RUP SE to
define a Technical Performance Measurement Plan (as part of the System Development Plan).
-
Define Project Organization and Staffing - The System
Development Plan has been added as an alternative to the Software Development Plan, and some additional
text added to describe the different staffing needs of systems engineering.
-
Activity: Plan for Next Iteration In Task: Develop Iteration Plan, the System Development Plan and the
Work Product: System Architecture Document are added as
alternative inputs to the formation of the iteration plan. The Work Product: Iteration Plan also has an expanded scope in RUP
SE.
-
Activity: Manage Iteration In this activity, the following
tasks are changed for RUP SE:
-
Acquire Staff - Adds the System Development Plan as an
alternative.
-
Initiate Iteration - Adds the System Development Plan as
an alternative input.
-
Assess Iteration - Adds the System Development Plan as an
alternative input and indicates that change requests might be raised against it, in the systems engineering
context.
-
Activity: Monitor and Control Project In this activity, the
following tasks are changed for RUP SE:
-
Activity: Close-Out Phase In this activity, the following
tasks are changed for RUP SE:
-
Activity: Close-Out Project
In this activity, the following tasks are changed for RUP SE:
The Project Manager and Project Reviewer role descriptions are extended in RUP SE to reflect
the wider scope of systems engineering.
There is much in common between RUP SE and RUP for software development in the requirements discipline. Techniques for
requirements elicitation, the importance of understanding stakeholder needs and the avoidance of unnecessarily
constraining the design, are just as important for systems requirements as software requirements. However, in dealing
with system specification in general, you have a potentially much richer problem space, in dealing with hardware, human
and software elements. There are physical aspects and constraints to consider that are not present with software -
size, weight, thermal, electrical and mechanical, for example. So the non-functional requirements assume a greater
significance than is usually the case with pure software developments.
The specification of the context in which a system operates is also important, as it is for some classes of
software - embedded software, for example. A system will likely have to interface to other systems, and the operations,
interfaces, services offered and expected have to be carefully specified. The entities that flow between systems
also need to be defined, and in the systems case, these can include physical flows, as well as data.
Looking at the systems engineering sample iteration plans, at the activity level, the requirements workflow is not
changed. There are some new and changed artifacts and tasks, and the existing RUP roles System Analyst and Requirements Specifier are modified to accommodate these.
-
Activity: Analyze the Problem There is no change to this
activity.
-
Activity: Understand Stakeholder Needs There is no change to
this activity.
-
Activity: Define the System In this activity, the following tasks are changed
for RUP SE:
-
Find Actors and Use Cases - Text has been added to this
task to specify how it relates to Business Modeling in the systems engineering context. The Use Case, Supplementary Specifications, and Use-Case Model artifacts output from this task are
system-level artifacts and reflect the concern for context and non-functional requirements mentioned above,
and which are elaborated in the changes to this task.
-
Define the System Context - A replacement task in
RUP SE, performed by the System Analyst, in which a logical model of the system in
its environment is created as a top-level collaboration (in the Work Product: System Analysis Model) showing the system
(modeled as a top-level subsystem), its interfaces, and its relationships with its actors, including the
external I/O entities that flow between actor and system.
-
Develop Vision - Modified to reflect the level at which
the Work Product: Vision is set. For systems development, the
Vision fulfills the role of an operational concept description and has additional content describing the
motivation for change, the environment in which the system will function, the features or capabilities and
how well they are to be performed, important system operational scenarios, and the impact of the system on
various stakeholders - interface changes, procedural changes, staff changes (skills, numbers, training
requirements)- as well as the rationale for the proposals.
-
Activity: Manage the Scope of the System
The following tasks are changed for RUP SE:
-
Prioritize System Use Cases - A new task in RUP SE,
performed by the System Architect, to help with the selection of system
use cases for analysis, and possibly design and implementation in the next iteration. The selection is
based on utility and importance to the user, architectural significance, and risk. In the activity, this is
an alternative to Prioritize Use Cases (for software development).
-
Develop Vision - See Activity: Define the System,
above.
-
Activity: Refine the System Definition
The following tasks are changed for RUP SE:
-
Detail the System Requirements - A new task in RUP SE,
performed by the Requirements Specifier, which produces a composite
artifact, the System Requirements Specification, which combines the
specification of required functional capability and required constraints. This is an alternative to Detail
the Software Requirements.
-
Detail a Use Case - Modified to add systems engineering
content, emphasizing the desirability of black-box specification for use cases, the flow down of
non-functional requirements, and the importance of protocol definition for external communications with
other systems or hardware.
-
Define the System Context - See Activity: Define the
System, above.
-
Activity: Manage Changing Requirements
The following tasks are changed for RUP SE:
The default description of Analysis and Design in RUP is software-specific and would be difficult to generalize.
Consequently, RUP SE adds a new set of tasks and is described separately from the standard workflow for Analysis and
Design. The intent is similar to the software workflow:
-
During inception, to produce an architectural proof-of-concept, if the risk profile of the project requires it, in
Synthesize System Architecture
-
During elaboration, to define the logical or physical structure of the system, in Define Candidate System Architecture and, in Analyze System Behavior, to realize the desired behavior in interactions between
subsystems and interactions between localities, then
-
During any phase, as discoveries or changes are made, to adjust the system architecture, in Refine System Architecture
Unlike the software workflow for Analysis and Design, there are no additional lower-level activities in RUP SE
equivalent to Design Components or Design Database: the lowest level outputs of the system-level activities form a
series of specifications for subsystems that derive from the realization of the required system behavior and
characteristics as defined in the System Analysis Model, System Architecture Document, System Architecture Proof-of-Concept, System Deployment Model, System Design Model, and System Use-Case Realization.
These subsystem artifacts, Subsystem Supplementary Requirements, Subsystem Use-Case Model, and Subsystem Vision drive subsystem development by becoming the
system-level artifacts (Supplementary Specifications, Use-Case Model and Vision) for a complete RUP development
lifecycle invocation, as if the subsystem were a system in its own right. From the perspective of an outside
subcontractor, this is close to reality; when all teams are in the same organization, and perhaps even co-located,
there might be no boundaries between systems and subsystems teams, and this differentiation of system and subsystem
artifacts is simply a descriptive convenience.
The System Architect is responsible for the system level artifacts and
for the Subsystem Vision, and the System Designer is responsible for defining in detail how the
subsystems collaborate to yield the required behavior and characteristics, and for the aggregation of the subsystem
interactions into the Subsystem Use-Case Model and Subsystem Supplementary Requirements.
-
Activity: Synthesize System Architecture New tasks in this activity:
-
System Architectural Analysis - In this task, the System Architect makes the initial determination of the
subsystems (logical viewpoint), the top-level processes (process viewpoint), and the Locality Model
(conceptual level of the System Deployment Model), and annotates the Locality
Model with non-functional requirements (later mapped to characteristics). The System Architect identifies
collaborations of subsystems that realize architecturally significant use cases, captures these (in broad
outline) in the System Analysis Model, and creates the Subsystem Vision artifacts. When this task is performed
as part of Activity: Synthesize System Architecture, in inception, the artifacts created are tentative and
are refined in subsequent invocations of this task, particularly during elaboration. The significant
decisions and rationale are captured in the System Architecture Document.
-
Construct System Architecture Proof-of-Concept - In
this task, the System Architect attempts the synthesis of at least one solution, in the Work Product: System Architecture Proof-of-Concept
(which might simply be conceptual), that meets the critical system architectural requirements and
demonstrates significant aspects of the problem space, with the objective of risk-reduction.
-
Assess Viability of System Architecture Proof-of-Concept
- The System Architect evaluates the synthesized System Architecture Proof-of-Concept to determine whether
the critical architectural requirements are feasible and can be met (by this or any other solution).
Depending on the results of this assessment, the project's Vision, Business Case, and Risk List can be
adjusted (or in the extreme, the project could be abandoned).
-
Activity: Define Candidate System Architecture New tasks in this activity:
-
System Architectural Analysis - See Activity: Synthesize
System Architecture, above.
-
Operation Analysis - In this task, the System Designer uses the outlined collaborations created
by the System Architect, and the black-box system use case descriptions, and elaborates black-box text into
subsystem white-box steps, augmenting these with locality and process decisions, and apportioning black-box
step budgeted requirements to white-box steps. The collection of subsystem white-box steps forms the
beginning of the Subsystem Use-Case Model. The System Designer also
creates preliminary Subsystem Supplementary Requirements for each
subsystem.
-
Activity: Analyze System Behavior New tasks in this activity:
-
Operation Design - In this task, the System Designer details the subsystem interactions in System Use-Case Realizations (in the System Design Model) and, for each subsystem, aggregates
similar subsystem white-box steps to form the Subsystem Use-Case Model. The System Designer updates
the Subsystem Supplementary Requirements to reflect any
refactoring decisions
-
Refine System Structure - In this task, the System Architect reviews changes and refactors/augments
subsystems as necessary, capturing the updated logical viewpoint in the System Architecture Document and other system-level
artifacts, and updating subsystem requirements artifacts.
-
Refine System Processes - The System Architect reviews
changes and refactors/augments the process structure (active class structure) as needed, capturing the
updated process viewpoint in the System Architecture Document and other system-level artifacts.
-
Refine System Deployment Model - In this task, the System
Architect refines the Locality Model into a Descriptor-level Model, and then to an Implementation level,
through analysis of the localities, their characteristics and hosted subsystem operations. The results are
recorded in the System Deployment Model and System Architecture Document (physical viewpoint). There
is a possible interface here to genuine hardware component work (not only computing platforms).
Characteristics at lower levels support supplementary requirements (with the Descriptor level inheriting
the Locality requirements through allocation/budgeting).
No changes in this release of RUP SE. Note that at the System level, Implementation is about the integration of
the system elements into an operational whole.
No changes in this release of RUP SE.
No changes in this release of RUP SE.
No changes in this release of RUP SE.
No changes in this release of RUP SE.
|