incose presentation san francisco chapter 13 october 2009 mapping cmmi to systems engineering...
TRANSCRIPT
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