Concept: RUP for Systems Engineering
Main Description

Introduction

Motivation

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.

Integration with RUP

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.

Plan levels for the RUP-SE plug in

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.

Summary of changes

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

Discipline  Activity  Task  Artifact Role
Project Management Develop Plans Project Planning Review
 Compile Plans
Plan Phases and Iterations
 Define Monitoring and Control Processes
Define Project Organization and Staffing
Iteration Plan
System Development Plan*
Project Manager
Project Reviewer
Conceive New Project Initiate Project
Manage Iteration Acquire Staff
Initiate Iteration
Assess Iteration
Monitor and Control Project  Monitor Project Status
Schedule and Assign Work
 Handle Exceptions and Problems
Plan for Next Iteration Develop Iteration Plan
Close-Out Phase  Prepare for Phase Close-Out
 Lifecycle Milestone Review
Close-Out Project  Prepare for Project Close-Out
 Project Acceptance Review
Discipline  Activity  Task  Artifact Role
Requirements Manage Changing Requirements Define the System Context* Use Case
Vision
Supplementary Specifications
Use-Case ModelSystem Requirements Specification*
System Analyst
Requirements Specifier
Manage the Scope of the System Prioritize System Use Cases*
Develop Vision
Refine the System Definition Define the System Context*
Detail the System Requirements*
Detail a Use Case
Define the System Find Actors and Use Cases
Define the System Context*
Develop Vision
Discipline  Activity  Task  Artifact Role
Analysis & Design - Systems Engineering Synthesize System Architecture* System Architectural Analysis*
Construct System Architecture Proof-of-Concept*
Assess Viability of System Architecture Proof-of-Concept*

Subsystem Supplementary Requirements*
Subsystem Use-Case Model*
Subsystem Vision*
System Analysis Model*
System Architecture Document*
System Architecture Proof-of-Concept*
System Deployment Model*
System Design Model*
System Use-Case Realization*
Subsystem Operation*
Subsystem Operation Realization*

System Architect*
System Designer*
Define Candidate System Architecture* System Architectural Analysis*
Operation Analysis*
Analyze System Behavior* Operation Design*
Refine System Structure*
Refine System Processes*
Refine System Deployment Model*
Refine System Architecture* System Architectural Analysis*
Refine System Structure*
Refine System Processes*
Refine System Deployment Model*

Other related guidelines and concepts:

Changes to the disciplines

Business Modeling

Rationale

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

Project management

Rationale

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.

Workflow

The Project Manager and Project Reviewer role descriptions are extended in RUP SE to reflect the wider scope of systems engineering.

Requirements

Rationale

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.

Workflow
  • 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:

Analysis and Design

Rationale

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:

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.

Workflow

Implementation

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.

Test

No changes in this release of RUP SE.

Deployment

No changes in this release of RUP SE.

Environment

No changes in this release of RUP SE.

Configuration and Change Management

No changes in this release of RUP SE.