Demystifying the SEI CMMI Requirements Management & Requirements Development Process Areas

Demystifying SEI CMMI Project World – Business Analyst
Requirements Management & World - Vancouver - November 2007
Requirements Development PAs

quot;Demystifying the SEI CMMI
Requirements Management &
Requirements Development
Process Areasquot;

Marko Wolf-Pany, P.Eng.
Wolf-

Project World – Business Analyst World
Vancouver 2007

Demystifying SEI CMMI Requirements Project World – Business Analyst World
Wolf-
Vancouver 2007 - 0
Management & Requirements Development
Tuesday, November 6, 2007

Marko Wolf Pany, P.Eng.

 Professional Engineer (P.Eng.), Ontario
 B.Eng. Honours, Electrical Engineering, Carleton University
 Software Engineering Institute (SEI) Software Capability Evaluation (SCE)
Evaluator
 CMMI / ITT Senior Manager, Accenture / Vancouver
 Program / Project / Process Improvement Management Consultant
 Director, Software Engineering Management
 Program Manager -SEI CMM based Software Process Improvement (SPI) Programs
 Member of the company’s Baldrige National Quality Program Steering Council
 Director, Systems Engineering -Technical Authority responsible for all
Information Technology (IT) Projects in Latin America
 Project Manager / Technical Manager, Land (Army) Software Engineering
Centre (LSEC), Department of National Defence (DND)
 Member of the Software Engineering Process Group (SEPG)

Wolf-
Vancouver 2007 - 1

Marko Wolf-Pany, P.Eng. 1


Agenda

 
Typical Problems During the Requirements Management - ReqM
Software Life Cycle (SLC)  Specific Goal and Practices
 Generic Goals and Practices
 The Operational Framework
 Requirements Development – RD
 Specific Goals and Practices
 CMMI® for Development, Version
 Generic Goal and Practices
1.2 - August 2006
 22 Process Areas – Alphabetical
 
Capability Levels vs. Maturity Levels Appendix A - The SEI Capability
 Maturity Models
22 Process Areas – by Category
 22 Process Areas – by Maturity
Level

 Four Categories of CMMI Process
Areas

Wolf-
Vancouver 2007 - 2

Typical Problems During the Software Life Cycle (SLC)

A Simple illustration

Borrowed from:
http://scott.yang.id.au/2003/08/software-development-life-
http://scott.yang.id.au/2003/08/software-development-life-
cycle/

Wolf-
Vancouver 2007 - 3



Typical Problems During
the Software Life Cycle (SLC) - 2/6

 
How the customers explained it How the Project Leader understood
it

Wolf-
Vancouver 2007 - 4


 
How the Analyst designed it How the Programmer wrote it

Wolf-
Vancouver 2007 - 5




 
How the Business Consultant How the project was Documented
described it

Wolf-
Vancouver 2007 - 6


 
What operations installed How the customer was billed

Wolf-
Vancouver 2007 - 7




 
How it was supported What the customer really needed

Wolf-
Vancouver 2007 - 8

The Operational Framework

The operational framework describes the operational elements that
govern organizational software development.

The operational framework is shown in the figure below.

Each component of the operational framework is described below.

Wolf-
Vancouver 2007 - 9



The Operational Framework – 2/3

Wolf-
Vancouver 2007 - 10

The Operational Framework – 3/3

 
Policies Standards
 
Organizational policies dictate the rules that Standards are the operational definitions of final
govern operations. A policy statement usually is or interim organizational work products.
used to enforce the use of organizational Standards constrain organizational processes by
processes. A policy statement, therefore, setting acceptance criteria on the output of those
constrains organizational processes by processes.
identifying required or acceptable processes, or
ways of doing work.

 Processes  Procedures
 A process is what happens in the organization to  Procedures are the step-by-step instructions for
step-by-
build products. Processes are constrained by implementing a process or a portion of a
organizational policies and standards in that they process. Procedural information focuses on how
must specify ways to develop products that to perform a certain task identified in the
conform to organizational standards, in process. Processes are, therefore, implemented
accordance with organizational policies. by specific procedures.

 Training  Tools
 Training addresses the knowledge and skills  Tools are any automated support needed to
required to execute a process or use a implement a procedure. Tools, like training, are
procedure. Training is used to support the use of used to support the use of processes and
processes and procedures. procedures.

Wolf-
Vancouver 2007 - 11



CMMI® for Development, Version 1.2

“Improving processes for better products”

CMU/SEI-2006-TR-008
CMU/SEI-2006-TR-
ESC-TR-2006-008
ESC-TR-2006-

August 2006

http://www.sei.cmu.edu/publications/documents/06.reports/06tr008.html

Wolf-
Vancouver 2007 - 12

22 CMMI Process Areas
Alphabetical Order By Acronym – 1/2

 There are 22 process areas, presented here in alphabetical order by acronym:
 Causal Analysis and Resolution (CAR)
 Configuration Management (CM)
 Decision Analysis and Resolution (DAR)
 Integrated Project Management +IPPD (IPM+IPPD)[1]
(IPM+IPPD)[1]
 Measurement and Analysis (MA)
 Organizational Innovation and Deployment (OID)
 Organizational Process Definition +IPPD (OPD+IPPD)6
 Organizational Process Focus (OPF)
 Organizational Process Performance (OPP)
 Organizational Training (OT)

[1] This process area has quot;+IPPDquot; after its name because it contains a goal and
practices that are specific to IPPD. The material specific to IPPD is called an quot;IPPD
addition.quot; All process areas with IPPD additions have quot;+IPPDquot; after their name.

Wolf-
Vancouver 2007 - 13



22 CMMI Process Areas
Alphabetical Order By Acronym – 2/2

 Product Integration (PI)
 Project Monitoring and Control (PMC)
 Project Planning (PP)
 Process and Product Quality Assurance (PPQA)
 Quantitative Project Management (QPM)
 Requirements Development (RD)
 Requirements Management (REQM)
 Risk Management (RSKM)
 Supplier Agreement Management (SAM)
 Technical Solution (TS)
 Validation (VAL)
 Verification (VER)

Wolf-
Vancouver 2007 - 14

CMMI - Capability Levels vs. Maturity Levels

Continuous Representation Staged Representation
Level
Maturity Levels
Capability Levels
Level 0 Incomplete N/A
Level 1 Performed Initial
Level 2 Managed Managed
Level 3 Defined Defined
Level 4 Quantitatively Managed Quantitatively Managed
Level 5 Optimizing Optimizing
Wolf-
Vancouver 2007 - 15



CMMI Process Areas and
Their Associated Categories and Maturity Levels – 1/2

Process Area Category Maturity Level

Causal Analysis and Resolution Support 5

Configuration Management Support 2

Decision Analysis and Resolution Support 3

Integrated Project Management +IPPD Project Management 3

Measurement and Analysis Support 2

Organizational Innovation and Deployment Process Management 5

Organizational Process Definition +IPPD Process Management 3

Organizational Process Focus Process Management 3

Organizational Process Performance Process Management 4

Organizational Training Process Management 3

Wolf-
Vancouver 2007 - 16

CMMI Process Areas and
Their Associated Categories and Maturity Levels – 2/2

Product Integration Engineering 3
Project Monitoring and Control Project Management 2
Project Planning Project Management 2
Process and Product Quality Assurance Support 2
Quantitative Project Management Project Management 4
Requirements Development Engineering 3
Requirements Management Engineering 2
Risk Management Project Management 3
Supplier Agreement Management Project Management 2
Technical Solution Engineering 3
Validation Engineering 3
Verification Engineering 3

Wolf-
Vancouver 2007 - 17



CMMI Process Areas
Process Management - Project Management


Organizational Process Performance Process Management 4
Organizational Innovation and Deployment Process Management 5

Project Planning Project Management 2
Project Monitoring and Control Project Management 2
Supplier Agreement Management Project Management 2
Quantitative Project Management Project Management 4

Wolf-
Vancouver 2007 - 18

CMMI Process Areas – Engineering - Support




Wolf-
Vancouver 2007 - 19



CMMI Process Areas – Maturity Level 2


Project Planning Project 2
Management
Project Monitoring and Control Project 2
Management
Supplier Agreement Management Project 2
Management
Wolf-
Vancouver 2007 - 20

CMMI Process Areas – Maturity Level 3




Wolf-
Vancouver 2007 - 21



CMMI Process Areas – Maturity Levels 4 & 5


Organizational Process Performance Process 4
Management

Quantitative Project Management Project 4
Management

Organizational Innovation and Process 5
Deployment Management


Wolf-
Vancouver 2007 - 22

Four Categories of CMMI Process Areas

Process areas can be grouped into four categories:
Process Management
Project Management
Engineering
Support

Wolf-
Vancouver 2007 - 23



Process Management Process Areas

 Process Management process areas contain the cross-project activities
cross-
related to defining, planning, deploying, implementing, monitoring,
controlling, appraising, measuring, and improving processes.

 The Process Management process areas of CMMI are as follows:
 Organizational Process Focus
 Organizational Process Definition +IPPD[1]
+IPPD[1]
 Organizational Training
 Organizational Process Performance
 Organizational Innovation and Deployment

[1] Organizational Process Definition (OPD) has one goal that applies only
when using CMMI with the IPPD group of additions.

Wolf-
Vancouver 2007 - 24

Basic Process Management Process Areas
jec ee n ’s
tiv ds
ob n io

es
d ss at

Senior
an roce aniz

management Training for projects and
p rg
O

support groups in standard
OT process and assets

Organization’s
business
Tra
objectives inin
gn
eed
Standard s
process and
other assets

Standard process, work Project Management,
environment standards,
Support, and Engineering
and other assets.
OPF process areas
OPD+IPPD
Resources and
coordination Improvement information
(e.g., lessons learned,
data, and artifacts)

Process-improvement proposals;
participation in defining, assessing,
and deploying processes

OPF = Organizational Process Focus
OT = Organizational Training
OPD+IPPD = Organizational Process Definition (with the IPPD addition)

Wolf-
Vancouver 2007 - 25



Advanced Process Management Process Areas
Improvements
Organization
OID

Co ata ove
Cav
d pr
d
st fro me
sr
iim
m

an m nt
d piill s
be ot
ne ed
Quality and process
-

f
fit
e
performance objectives,
measures, baselines,
and models
Quality and process -
Project Management,
performance objectives,
measures, baselines, Support, and Engineering
and models process areas
Senior OPP
Progress toward
management
achieving business
objectives

Co asur
Process performance

me
om u e
e
and capability data

mo s
m
n
Ability to develop and
deploy standard process Basic
and other assets Process Management
process areas

OID = Organizational Innovation and Deployment
OPP = Organizational Process Performance

Wolf-
Vancouver 2007 - 26

Project Management Process Areas

 Project Management process areas cover the project management
activities related to planning, monitoring, and controlling the project.

 The Project Management process areas of CMMI are as follows:
 Project Planning
 Project Monitoring and Control
 Supplier Agreement Management
 Integrated Project Management +IPPD[1]
+IPPD[1]
 Risk Management
 Quantitative Project Management

[1] Integrated Project Management (IPM) has one goal that applies only
when using CMMI with the IPPD group of additions.

Wolf-
Vancouver 2007 - 27



Basic Project Management Process Areas
Status, issues, and results of process and
Corrective action product evaluations; measures and analyses
PMC
Corrective action

What
to monitor
Replan

What to build
Status, issues,
PP What to do Engineering and Support
and results of
process areas
Commitments
reviews and
monitoring

Plans
Measurement
needs
SAM

Product component requirements,
Supplier technical issues, completed product
agreement components, and acceptance reviews
and tests

Supplier

PMC = Project Monitoring and Control
PP = Project Planning
SAM = Supplier Agreement Management

Wolf-
Vancouver 2007 - 28

Advanced Project Management Process Areas
Statistical management data
selin ce
e s,

QPM
n

Risk exposure due to
rma

unstable processes
Quantitative
obj
to statistically ectives, subprocesses
obje ss perfo
and tives, ba

manage, pro
composed, ject’s
els

and def ined
process
mod
e

Organization’s standard processes,
Proc
c

s
Identified risk
work environment standards, RSKM
and supporting assets
Pro
ject’

IPM+IPPD
s co

and
rules
IPPD ines
mpo

guidel
Process Management Pr
oj
,
an and ned

process areas ec Risk taxonomies and
sed

t’s
Pr
ta
rm g , a r

parameters, risk
da

oj sh
rfo in le

an

ec ar status, risk mitigation
ce
p e la n n o n s

t
d de

ed
Project’s defined per plans, and corrective
p es s

vis
fo
process and work
fine

io
rm action
L

n
environment an
d pr

ce
Coordination, da
oce

ta
commitments, and
Product issues to resolve
ss

architecture
for structuring Integrated teams for performing
teams engineering and support processes
Basic
Project Management
process areas
Engineering and Support
process areas

IPM+IPPD = Integrated Project Management (with the IPPD addition)
QPM = Quantitative Project Management
RSKM = Risk Management

Wolf-
Vancouver 2007 - 29



Engineering Process Areas

 Engineering process areas cover the development and maintenance activities
that are shared across engineering disciplines. The Engineering process areas
were written using general engineering terminology so that any technical
discipline involved in the product development process (e.g., software
engineering or mechanical engineering) can use them for process improvement.

 The Engineering process areas also integrate the processes associated with
different engineering disciplines into a single product development process,
supporting a product-oriented process improvement strategy. Such a strategy
product-
targets essential business objectives rather than specific technical disciplines.
This approach to processes effectively avoids the tendency toward an
organizational “stovepipe” mentality.

 The Engineering process areas apply to the development of any product or
service in the development domain (e.g., software products, hardware products,
services, or processes).

Wolf-
Vancouver 2007 - 30


 The Engineering process areas of CMMI are as follows:
 Requirements Development
 Requirements Management
 Technical Solution
 Product Integration
 Verification
 Validation

Wolf-
Vancouver 2007 - 31




Requirements
REQM

Product and product
component requirements

Product
Alternative solutions Product
components
TS Customer
RD PI
Requirements

Product components, work products,
verification and validation reports

PI = Product Integration
VAL
VER
RD = Requirements Development
REQM = Requirements Management
TS = Technical Solution
VAL = Validation
VER = Verification

Customer needs

Wolf-
Vancouver 2007 - 32

Support Process Areas

 Support process areas cover the activities that support product development
and maintenance.
 The Support process areas address processes that are used in the context of
performing other processes.
 In general, the Support process areas address processes that are targeted
toward the project and may address processes that apply more generally to the
organization.
 For example, Process and Product Quality Assurance can be used with all the
process areas to provide an objective evaluation of the processes and work
products described in all the process areas.

 The Support process areas of CMMI are as follows:
 Configuration Management
 Process and Product Quality Assurance
 Measurement and Analysis
 Decision Analysis and Resolution
 Causal Analysis and Resolution

Wolf-
Vancouver 2007 - 33



Basic Support Process Areas

Quality and
Measurements
noncompliance
and analyses
issues
PPQA
MA All process areas

Information
Processes and
needs
work products,
and standards, and
procedures
Configuration
Baselines and
items and
audit reports
change
requests

CM

MA = Measurement and Analysis
CM = Configuration Management
PPQA = Process and Product Quality Assurance

Wolf-
Vancouver 2007 - 34

Advanced Support Process Areas

CAR
Process improvement
proposals

Defects and
other problems

All process areas

Selected
issues

Formal
evaluations

DAR
CAR = Causal Analysis and Resolution
DAR = Decision Analysis and Resolution

Wolf-
Vancouver 2007 - 35



“If You Don’t Know Where You’re Going,
Any Road Will Do.”

Chinese Proverb

Wolf-
Vancouver 2007 - 36

“If you don’t know where you are,
A map won’t help.”
Watts S. Humphrey
“Father” of the capability maturity model (CMM)
Software Engineering Institute
Carnegie Mellon University

Wolf-
Vancouver 2007 - 37



Requirements Management - ReqM
An Engineering Process Area at Maturity Level 2

Purpose
The purpose of Requirements Management (ReqM) is to
manage the requirements of the project’s products and product
components and to identify inconsistencies between those
requirements and the project’s plans and work products.

Wolf-
Vancouver 2007 - 38

SG 1 - Manage Requirements
Specific Goal and Practices

 SG 1 - Manage Requirements
 SP 1.1 - Obtain an Understanding of Requirements
 SP 1.2 - Obtain Commitment to Requirements
 SP 1.3 - Manage Requirements Changes
 SP 1.4 - Maintain Bidirectional Traceability of Requirements
 SP 1.5 - Identify Inconsistencies Between Project Work and Requirements

Wolf-
Vancouver 2007 - 39




 SG 1 - Manage Requirements
 Requirements are managed and inconsistencies with project plans and work
products are identified.

 The project maintains a current and approved set of requirements over
the life of the project by doing the following:
 Managing all changes to the requirements
 Maintaining the relationships among the requirements, the project plans,
and the work products
 Identifying inconsistencies among the requirements, the project plans, and
the work products
 Taking corrective action

Wolf-
Vancouver 2007 - 40

SP 1.1 - Obtain an Understanding of Requirements

 SP 1.1 - Obtain an Understanding of Requirements
 Develop an understanding with the requirements providers on the meaning of the
requirements.

 Typical Work Products
 1. Lists of criteria for distinguishing appropriate requirements providers
 2. Criteria for evaluation and acceptance of requirements
 3. Results of analyses against criteria
 4. An agreed-to set of requirements
agreed-

 Examples of evaluation and acceptance criteria include the following:
 Clearly and properly stated
 Complete
 Consistent with each other
 Uniquely identified
 Appropriate to implement
 Verifiable (testable)
 Traceable

Wolf-
Vancouver 2007 - 41



SP 1.2 - Obtain Commitment to Requirements

 SP 1.2 - Obtain Commitment to Requirements
 Obtain commitment to the requirements from the project participants.

 1. Requirements impact assessments
 2. Documented commitments to requirements and requirements changes

Wolf-
Vancouver 2007 - 42

SP 1.3 - Manage Requirements Changes

 SP 1.3 - Manage Requirements Changes
 Manage changes to the requirements as they evolve during the project.

 1. Requirements status
 2. Requirements database
 3. Requirements decision database

Wolf-
Vancouver 2007 - 43



SP 1.4 - Maintain Bidirectional Traceability of Requirements

 SP 1.4 - Maintain Bidirectional Traceability of Requirements
 Maintain bidirectional traceability among the requirements and work
products.

 1. Requirements traceability matrix
 2. Requirements tracking system

Wolf-
Vancouver 2007 - 44

SP 1.5 - Identify Inconsistencies Between Project Work and
Requirements
 SP 1.5 - Identify Inconsistencies Between Project Work and
Requirements
 Identify inconsistencies between the project plans and work products and
the requirements.

 1. Documentation of inconsistencies including sources, conditions, and
rationale
 2. Corrective actions

Wolf-
Vancouver 2007 - 45



Requirements Management - ReqM
GG 2 - Institutionalize a Managed Process
GG 3 - Institutionalize a Defined Process
 GG 2 - Institutionalize a Managed Process
 GP 2.1 - Establish an Organizational Policy
 GP 2.2 - Plan the Process
 GP 2.3 - Provide Resources
 GP 2.4 - Assign Responsibility
 GP 2.5 - Train People
 GP 2.6 - Manage Configurations
 GP 2.7 - Identify and Involve Relevant Stakeholders
 GP 2.8 - Monitor and Control the Process
 GP 2.9 - Objectively Evaluate Adherence
 GP 2.10 - Review Status with Higher Level Management

 GG 3 - Institutionalize a Defined Process
 GP 3.1 - Establish a Defined Process
 GP 3.2 - Collect Improvement Information

Wolf-
Vancouver 2007 - 46

Requirements Management – ReqM
GG 2 - Institutionalize a Managed Process – 1/5

 GP 2.1 - Establish an Organizational Policy
 Establish and maintain an organizational policy for planning and performing
the requirements management process.
 This policy establishes organizational expectations for managing
requirements and identifying inconsistencies between the requirements and
the project plans and work products.

 GP 2.2 - Plan the Process
 Establish and maintain the plan for performing the requirements
management process.
 This plan for performing the requirements management process can be part
of (or referenced by) the project plan as described in the Project Planning
process area.

Wolf-
Vancouver 2007 - 47


Demystifying the SEI CMMI Requirements Management & Requirements Development Process Areas

Demystifying the SEI CMMI Requirements Management & Requirements Development Process Areas

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Andere mochten auch

Andere mochten auch (10)

Ähnlich wie Demystifying the SEI CMMI Requirements Management & Requirements Development Process Areas

Ähnlich wie Demystifying the SEI CMMI Requirements Management & Requirements Development Process Areas (20)

Demystifying the SEI CMMI Requirements Management & Requirements Development Process Areas