INCOSE PresentationSan Francisco Chapter

13 October 2009

Mapping CMMI to Systems Engineering

Adrienne Friedman

Mapping the Capability Maturity Model Integration (CMMI) for Development, V

1.2to

System EngineeringRequirements

Agenda Working definitions

What is the CMMI? What is INCOSE? What is Systems Engineering?

CMMI Process categories CMMI-DEV V1.2 Process Areas Handout INCOSE Process Categories INCOSE Handbook 3.1 SE Overview CMMI Requirements Management (REQM) compared to

INCOSE Requirements Analysis CMMI Requirements Development (RD) compared to

INCOSE Requirements Definition Stakeholder benefits: Requirements Summary

What is the CMMI?

CMMI is a process improvement approach that provides organizations with the essential elements of effective processes that ultimately improve their performance.

CMMI can be used to guide process improvement across a project, a division, or an entire organization. Integrates traditionally separate organizational

functions Sets process improvement goals and priorities Provide guidance for quality processes Provides a point of reference for appraising

current processes.

Purpose of INCOSE

To define the discipline and practice of Systems Engineering (SE) for student and practicing professional alike

To provide an authoritative reference to understand the discipline of SE in terms of content and practice

Definition of Systems Engineering Systems engineering is a discipline that concentrates on

the design and application of the whole (system) as distinct from the parts. It involves looking at a problem in its entirety, taking into account all the facets and all the variables and relating the social to the technical aspect. (Ramo)

Systems engineering is an iterative process of top-down synthesis, development, and operation of a real-world system that satisfies, in a near optimal manner, the full range of requirements for the system. (Eisner)

Systems engineering is an interdisciplinary approach and means to enable the realization of successful systems. (INCOSE)

Systems’ thinking focuses on awareness of wholes and how the parts within those wholes interrelate.

CMMI Process categories

PROCESS MANAGEMENT

(PCM)

ENGINEERING (ENG)

PROJECT MANAGEMENT

(PJM)

SUPPORT (SUP)

CATEGORY Process Area

OPF Organizational Process Focus

OPD Organizational Process Definition

OT Organizational Training

OPP Organizational Process Performance

Process Management

OID Organizational Innovation and Deployment

PP Project Planning

PMC Project Monitoring and Control

SAM Supplier Agreement Management

IPM Integrated Project Management for IPPD

RSKM Risk Management

Project Management

QPM Quantitative Project Management

REQM Requirements Management

RD Requirements Development

TS Technical Solution

PI Product Integration

VER Verification

Engineering

VAL Validation

MA Measurement and Analysis

PPQA Process and Product Quality Assurance

CM Configuration Management

DAR Decision Analysis and Resolution

Support

CAR Causal Analysis and Resolution

CMMI-DEV V1.2 Process Areas by CategoryP

resentation focus area

INCOSE SE Process categories

Enterprise Processes

Technical Processes

PROJECT Processes

Agreement Processes

PROCESS MANAGEMENT

(PCM)

ENGINEERING (ENG)

PROJECT MANAGEMENT

(PJM)

SUPPORT (SUP)

Figure 1-1 System Life Cycle Processes Overview per ISO/IEC 15288

INCOSE Handbook SE OverviewENTERPRISEPROCESSES

Enterprise Environment Management

Investment Management

ResourceManagement

QualityManagement

Acquisition

Supply

AGREEMENTPROCESSES

Enterprise Environment Management

Investment Management

ResourceManagement

QualityManagement

ManagementEnterprise Environment

Management

Investment ManagementInvestment

Management

ResourceManagementResource

Management

QualityManagement

QualityManagement

Risk Management Configuration Management

Information Management

Planning Assessment Control

Decision-making Risk Management Configuration Management

Information Management

Planning Assessment Control

Decision-making Risk Management Risk Management

Configuration Management

Configuration Management

Information Management Information

Management

PlanningPlanning AssessmentAssessment ControlControl

Decision-makingDecision- Making

Disposal

MaintenanceOperation

ValidationTransitionVerification

Requirements Analysis Architectural Design

Stakeholder Requirements

Definition

Implementation Integration

DisposalDisposal

MaintenanceOperation MaintenanceMaintenanceOperationOperation

ValidationTransitionVerification ValidationValidationTransitionTransitionVerificationVerification

Requirements Analysis Architectural Design

Stakeholder Requirements

Definition

Requirements Analysis

Requirements Analysis

Architectural DesignArchitectural Design

Stakeholder Requirements

Definition

Stakeholder Requirements

Definition

Implementation IntegrationImplementationImplementation IntegrationIntegration

TECHNICAL PROCESSES

PROJECT PROCESSES

Acquisition

Supply

System Life Cycle Processes

Management

System Life Cycle Processes

Management

System Life Cycle Processes

Management

Process Guidelines

Presentation Focus Area

Process Areas

CMMI Engineering

ENGINEERING (ENG)

• Requirements Management (REQM)

• Requirements Development (RD)

• Technical Solution (TS)

=>

• Product Integration (PI)• Verification (VER)• Validation (VAL)<=

Presentation Focus Engineering portion of CMMI

Systems Engineering approach to Requirements Management and Requirements Development

CMMI Systems Engineering

PPQA 2

MA 2

CM 2

DAR 3

CAR 5

OPF 3

OPD 3

OT 3

TS 3

PI 3

VER 3

VAL 3

SAM 2

OPP 4

OID 5

REQM 2PP2

PMC 2IPM 3

RSKM 3

QPM 4

RD 3

Process Areas and Specific Goals in

Engineering Requirements Management (REQM)

Requirements Management (REQM)

SG1 Requirements are managed and inconsistencies with project plans and work products are identified.

Requirements Management (REQM)

SG1 Requirements are managed and inconsistencies with project plans and work products are identified.

CMMI Requirements Development (REQM)

CMMI Section Specific GoalDescription

Specific Processes

SG1 Manage Requirements

Requirements are managed and inconsistencies with project plans and work products are identified

SP 1.1 Obtain an understanding of RequirementsSP 1.2 Obtain Commitment to requirementsSP 1.3 Manage requirements creep SP 1.4 Maintain Bi-directional traceability of requirementsSP 1.5 Identify inconsistencies between Project Plans and the work products and requirements

Controlling changes ensures that project members and customers have a clear and shared understanding of the requirements

It is important to identify when requirements volatility occurs so appropriate action can be taken.

High volatility makes it difficult for projects to progress. Plans must be adjusted accordingly

Bi-directional traceability can cover traces to work products & demonstrates where & how each requirement is met

Requirements Analysis Process

14

Figure 4-3 Context Diagram for Requirements Analysis Process

Controls- Natural and societal laws

- Project procedures & processes

- Define functional boundary- Define performance requirements- Identify architectural constraints

- Define non-functional requirements- Maintain traceability and baseline integrity

Activities Outputs- Functional and non- functional Requirements

- Performance Requirements

- Architectural constraints

- Updated RVTM

- Verification strategy and criteria

- Stakeholder requirements- System Solution Constraints- Requirements Verification & Traceability Matrix (RVTM)

Inputs

Enablers- Enterprise Infrastructure

- Enterprise Policies, Processes, & Standards

PPQA 2

MA 2

CM 2

DAR 3

CAR 5

OPF 3

OPD 3

OT 3

TS 3

PI 3

VER 3

VAL 3

SAM 2

OPP 4

OID 5

REQM 2PP2

PMC 2IPM 3

RSKM 3

QPM 4

RD 3

Engineering

Requirements Development (RD)

SG1 Stakeholder needs, expectations, constraints, and interfaces are collected and translated into customer requirements.

SG2 Customer requirements are refined and elaborated to develop product and product-component requirements.

SG3 The requirements are analyzed and validated, and a definition of

required functionality is developed.

Requirements Development (RD)

SG1 Stakeholder needs, expectations, constraints, and interfaces are collected and translated into customer requirements.

SG2 Customer requirements are refined and elaborated to develop product and product-component requirements.

SG3 The requirements are analyzed and validated, and a definition of

required functionality is developed.

Process Areas and Specific Goals in

Engineering Requirements Development (RD)

CMMI Requirements Development (RD)

CMMI Section Specific GoalDescription

Specific Processes

SG1 Develop Customer Requirements

Stakeholder needs, expectations, constraints, and interfaces are collected and translated into customer requirements.

SP 1.1 Elicit NeedsSP 1.2 Develop customer Requirements

SG2 Develop Product Requirements

Customer requirements are refined and elaborated to develop product and product-component requirements.

SP 2.1 Establish Product and Product Component RequirementSP 2.2 Allocate Product Component Requirements SP 2.3 Identify Interface Requirements

SG3 Analyze and Validate Requirements

The requirements are analyzed and validated, and a definition of required functionality is developed.

SP 3.1 Establish Operational Concepts and ScenariosSP 3.2 Establish Definition of Required FunctionalitySP 3.3 Analyze RequirementsSP 3.4 Analyze Requirements to achieve balanceSP 3.5 Validate Requirements

Customer needs are communicated informally in documents, conversations and meetings and must be translated into agreed upon requirements

Product component requirements are developed recursively in parallel with recursive product development

Requirements must be analyzed to ensure they are necessary and sufficient. Resulting products must perform in the users environment

Stakeholder Requirements Definition Process

17

Enablers

- Enterprise Infrastructure- Enterprise Policies, Processes, & Standards

-System solution constraints-Traceability Matrix-Validation criteria-Concept documents

Outputs- System solution constraints- Requirements Verification & Traceability Matrix

- Validation criteria- Concept documents

- Stakeholders’ needs- Project Constraints

Inputs

Activities- Identify legitimate stakeholders

- Elicit requirements- Define constraints

- Build scenarios and concept documents- Resolve requirements problems

- Confirm and record requirements- Establish and maintain traceability

- Agreements - Project procedures & processes

Controls

Figure 4-2 Context Diagram for Stakeholder Requirements Definition Process

Stakeholder benefits: Requirements

REWORK AS A PER CENT OF TOTAL EFFORT

WORK59%

REWORK41%

Dion, DIO1McConnell, MCC1

SOURCES OF ERRORS CAUSING REWORK

OTHER60%

REQ'TS40%

Davis, DAV1,Novorita, NOV1 - 66% to 55%

TYPES OF REQ'TS ERRORSIncorrect fact 49%Omission 31%Inconsistency 13%Ambiguity 5%Misplaced 2% Hooks, HOO3

To fix requirements errors after deployment: 50x to 200x cost factor McConnell, MCC1

55% or more of the ... failures discovered by end users and system testers are caused by problems with requirements. The most probable causes are:

• Ambiguous words and phrases• Incomplete statements• Inconsistent functions• Untestable functions• Untraceable functions• Undesirable design impositions

Robert M. Poston, Generating Test Cases from Use Cases Automatically

In conclusion

CMMI is a process improvement model that maps well to current System Engineering processes

It provides a yardstick to ensure that current best practices for SE and for companies as a whole are implemented

http://www.sei.cmu.edu/cmmi/tools/dev/index.cfm