MSA Orientation v203a 1 Whats RIGHT with the CMMI?!? Pat OToole

MSA Orientation – v203a1

What’s RIGHT with the CMMI?!?

Pat O’Toole ([email protected])


Agenda Quick Look at a Process Area What’s RIGHT – Part 1

–Staged vs. Continuous Representation What’s RIGHT – Part 2

–Generic Goals and Practices What’s RIGHT – Part 3

–Base and Advanced Practices–Mapping Practices to Goals–Required/Expected/Informative–Process Area Categories


Purpose

REQUIREMENTS MANAGEMENT Engineering

Purpose

The purpose of Requirements Management 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. [PA146]


Introductory Notes

Introductory Notes

Requirements management processes manage all requirements received or generated by the project, including both technical and nontechnical requirements as well as those requirements levied on the project by the organization. In particular, if the Requirements Development process area is implemented, its processes will generate product and product-component requirements that will also be managed by the requirements management processes. When the Requirements Management, Requirements Development, and Technical Solution process areas are all implemented, their associated processes may be closely tied and be performed concurrently. [PA146.N101]


Related Process Areas

Related Process Areas

Refer to the Requirements Development process area for more information regarding transforming stakeholder needs into product requirements and deciding how to allocate or distribute requirements among the product components. [PA146.R101]

Refer to the Technical Solution process area for more information about transforming requirements into technical solutions. [PA146.R102]

Refer to the Project Planning process area for more information about how project plans reflect requirements and need to be revised as requirements change. [PA146.R103]


Specific Goals

Specific Goals

SG 1 Manage Requirements [PA146.IG101]

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


Generic GoalsGeneric Goals

GG 1 Achieve Specific Goals [CL102.GL101]

The process supports and enables achievement of the specific goals of the process area by transforming identifiable input work products to produce identifiable output work products.

GG 2 Institutionalize a Managed Process [CL103.GL101]

The process is institutionalized as a managed process.

GG 3 Institutionalize a Defined Process [CL104.GL101]

The process is institutionalized as a defined process.

GG 4 Institutionalize a Quantitatively Managed Process [CL105.GL101]

The process is institutionalized as a quantitatively managed process.

GG 5 Institutionalize an Optimizing Process [CL106.GL101]

The process is institutionalized as an optimizing process.


Practice-to-Goal Relationship Table


SG 1 Manage Requirements [PA146.IG101] SP 1.1-1 Obtain an Understanding of Requirements SP 1.2-2 Obtain Commitment to Requirements SP 1.3-1 Manage Requirements Changes SP 1.4-2 Maintain Bidirectional Traceability of Requirements SP 1.5-1 Identify Inconsistencies between Project Work and Requirements


Specific Practices by Goal

Specific Practices by Goal

SG 1 Manage Requirements

Requirements are managed and inconsistencies with project plans and work products are identified. [PA146.IG101]

The project maintains a current and approved set of requirements over the life of the project by doing the following: [PA146.IG101.N101] Managing all changes to the requirements Maintaining the relationships between the requirements, the

project plans, and the work products Identifying inconsistencies between the requirements, the

project plans, and the work products Taking corrective action


Specific Practices

SP 1.1-1 Obtain an Understanding of Requirements Develop an understanding with the requirements providers on the meaning of the requirements. [PA146.IG101.SP101]

As the project matures and requirements are derived, all activities or disciplines will receive requirements. To avoid requirements creep, criteria are established to designate appropriate channels, or official sources, from which to receive requirements. The receiving activities conduct analyses of the requirements with the requirements provider to ensure that a compatible, shared understanding is reached on the meaning of the requirements. The result of this analysis and dialog is an agreed-to set of requirements. [PA146.IG101.SP101.N101]


Specific Practice – Work Products

Typical Work Products

1. Lists of criteria for distinguishing appropriate requirements providers [PA146.IG101.SP101.W101]

2. Criteria for evaluation and acceptance of requirements

[PA146.IG101.SP101.W102]

3. Results of analyses against criteria [PA146.IG101.SP101.W103]

4. An agreed-to set of requirements [PA146.IG101.SP101.W104]


Specific Practice – Subpractices

Subpractices

1. Establish criteria for distinguishing appropriate requirements providers. [PA146.IG101.SP101.SubP101]

2. Establish objective criteria for the acceptance of requirements.

[PA146.IG101.SP101.SubP102]

Lack of acceptance criteria often results in inadequate verification, costly rework, or customer rejection. [PA146.IG101.SP101.SubP102.N102]

Examples of acceptance criteria include the following: [PA146.IG101.SP101.SubP102.N101]

Clearly and properly stated Complete Consistent with each other Uniquely identified Appropriate to implement Verifiable (testable) Traceable


Generic Practices

GP 2.4 Assign Responsibility Assign responsibility and authority for performing the process, developing the work products, and providing the services of the requirements management process. [GP106]

GP 2.5 Train People Train the people performing or supporting the requirements management process as needed. [GP107]


Generic Practices Elaborations

GP 2.7 Identify and Involve Relevant Stakeholders Identify and involve the relevant stakeholders of the requirements management process as planned. [GP124]

Elaboration:

Select relevant stakeholders from customers, end users, developers, producers, testers, suppliers, marketers, maintainers, disposal personnel, and others who may be affected by, or may affect, the product as well as the process. [PA146.EL115]

Examples of activities for stakeholder involvement include: [PA146.EL116]

Resolving issues on the understanding of the requirements Assessing the impact of requirements changes Communicating the bidirectional traceability Identifying inconsistencies among project plans, work products, and

requirements


One Model, Two Representations Staged Representation

–Same as CMM for Software–Prescriptive ordering of improvement areas–Organizational Change Model–“Maturity Levels” – group of process areas

Continuous Representation–Same as System Engineering CMM–Basic vs. advanced process areas–“Capability Levels” – each process area individually


Capability Levels Ability to perform, control, and improve

performance within a Process Area Six capability levels

–0: Incomplete–1: Performed–2: Managed–3: Defined–4: Quantitatively Managed–5: Optimizing


Equivalent Staging – ML2

Name Abbr ML CL1 CL2 CL3 CL4 CL5

Requirements Management REQM 2

Measurement and Analysis MA 2

Project Monitoring and Control PMC 2

Project Planning PP 2

Process and Product Quality Assurance

PPQA 2

Supplier Agreement Management SAM 2

Configuration Management CM 2

Target Profile

2


Equivalent Staging – ML3Name Abbr ML CL1 CL2 CL3 CL4 CL5

Requirements Management REQM 2

Measurement and Analysis MA 2

Project Monitoring and Control PMC 2

Project Planning PP 2

Process and Product Quality Assurance

PPQA 2

Supplier Agreement Management SAM 2

Configuration Management CM 2

Target Profile

2

Decision Analysis and Resolution DAR 3

Product Integration PI 3

Requirements Development RD 3

Technical Solution TS 3

Validation VAL 3

Verification VER 3

Organizational Process Definition OPD 3

Organizational Process Focus OPF 3

Integrated Project Management (IPPD)

IPM 3

Risk Management RSKM 3

Integrated Supplier Management ISM 3

Organizational Training OT 3

Integrated Teaming IT 3

Organizational Environment for Integration

OEI 3

Target Profile 3


Staged Equivalence - 1

Process Mgt:

Staged at ML:

Assessed at Capability

Level: Engineering:Staged at ML:


Level:OPF 3 4 RM 2 5OPD 3 2 RD 3 3OT 3 2 TS 3 3

PI 3 2Project Mgt: Ver 3 1PP 2 3 Val 3 0PMC 2 4SAM 2 2 Support:IPM 3 0 CM 2 3RskM 3 1 PPQA 2 4IT 3 2 MA 2 2ISM 3 4 DAR 3 1

OEI 3 0



Process Mgt:

Staged at ML:






OEI 3 0



Process Mgt:

Staged at ML:






OEI 3 3



Process Mgt:

Staged at ML:






OEI 3 0


Exploiting the Best of Both Staged Representation

–Management and customers love it: 1 simple number–Organizational Change Model

Continuous Representation–Different organizations have different needs/pain–There are 14 process areas at maturity level 3!–Finer level of planning and tracking improvements

Hybrid Approach–Use Staged to establish long range goal–Used Continuous to plan, execute, and track


Maturity Level 2 Example

Staged at 1/1/03Maturity MSA

Level ActProject Mgt:PP 2 2PMC 2 1SAM 2 0Engineering:RM 2 1Support:CM 2 2PPQA 2 2MA 2 0

1Q03Plan

211

2

220

Plan Act

221

2

221

2Q03 3Q03Plan

222

2

221

Plan Act

222

2

222

4Q03Plan Act

222

2

222

4Q03


Maturity Level 3 ExampleStaged at 1/1/03Maturity MSA

Level ActProcess Mgt:OPF 3 1OPD 3 0OT 3 1Project Mgt:PP 2 2PMC 2 1SAM 2 0IPM 3 0RskM 3 1ISM 3 0Engineering:RM 2 1RD 3 1TS 3 1PI 3 1Ver 3 1Val 3 0Support:CM 2 2PPQA 2 2MA 2 0DAR 3 0

1Q03Plan

111

211010

221110

2200

Plan Act

211

221010

221111

2210

2Q03 3Q03Plan

211

322010

221111

2311

Plan Act

222

322111

221111

2321

4Q03 1Q04Plan

222

332111

321222

3321

Plan Act

322

333122

332222

3322

2Q04 3Q04Plan

333

333222

332233

3332

Plan Act

333

333333

333333

3333

4Q04Plan Act

333

333333

333333

3333

4Q04


Structural Overview

Generic Practices

Generic Goals

Process Area 2Process Area 1 Process Area n

Specific Goals

Specific Practices Capability LevelsGeneric Practices

Generic Goals

Process Area 2Process Area 1 Process Area n

Specific Goals

Specific Practices Capability Levels


Generic GoalsGeneric Goals

GG 1 Achieve Specific Goals [CL102.GL101]

The process supports and enables achievement of the specific goals of the process area by transforming identifiable input work products to produce identifiable output work products.

GG 2 Institutionalize a Managed Process [CL103.GL101]

The process is institutionalized as a managed process.

GG 3 Institutionalize a Defined Process [CL104.GL101]

The process is institutionalized as a defined process.

GG 4 Institutionalize a Quantitatively Managed Process [CL105.GL101]

The process is institutionalized as a quantitatively managed process.

GG 5 Institutionalize an Optimizing Process [CL106.GL101]

The process is institutionalized as an optimizing process.


Generic Practices: Capability Level 2 Very Familiar

– Establish an Organizational Policy– Provide Resources– Train People– Objectively Evaluate Adherence– Review Status with Higher Level Mgt

Somewhat Familiar– Assign Responsibility– Plan the Process– Monitor and Control the Process

“New and Improved”– Manage Configurations– Identify and Involve Relevant Stakeholders


And There’s More… CL3 Defined Process

–Establish a Defined Process–Collect Improvement Information

CL4 Quantitatively Managed Process–Establish Quantitative Objectives for the Process–Stabilize Subprocess Performance

CL5 Optimizing Process–Ensure Continuous Process Improvement–Correct Root Causes of Problems


Base/Advanced Practices Base practices: associated with CL1 Advanced practices: associated with CL2+ Some advanced practices build on base

practices, others do not


Base/Advanced PracticesSP 1.1-1 Collect Stakeholder Needs

Identify and collect stakeholder needs, expectations, constraints, and interfaces for all phases of the product life cycle.

The basic activity addresses the receipt of requirements that a customer provides to define what is needed or desired. These requirements may or may not be stated in technical terms.

SP 1.1-2 Elicit Needs Elicit stakeholder needs, expectations, constraints, and interfaces for all phases of the product life cycle.

Eliciting goes beyond collecting requirements by proactively identifying additional requirements not explicitly provided by customers. Additional requirements should address the various product life-cycle activities and their impact on the product.


Mapping Practices to Goals - CMM

SOFTWARE PROJECT TRACKING AND OVERSIGHT

Goal Commitment Ability Activity Measurement Verification

1 1, 2 1, 2, 3, 4, 5 1, 5, 6, 7, 8, 9, 10, 11, 12, 13 1 1, 2, 3

2 1, 2 1, 2, 3, 4, 5 2, 5, 6, 7, 8, 9, 11 1 1, 2, 3

3 1, 2 1, 2, 3, 4, 5 3, 4 1 1, 2, 3

SOFTWARE PROJECT PLANNING

Goal Commitment Ability Activity Measurement Verification

1 1, 2 1, 2, 3 9, 10, 11, 12, 15 1 1, 2, 3

2 1, 2 1, 2, 3, 4 2, 5, 6, 7, 8, 13, 14 1 1, 2, 3

3 1, 2 1, 3, 4 1, 3, 4 1 1, 2, 3


Mapping Practices to Goals - CMMI


SG 1 Develop Customer Requirements [PA157.IG101] SP 1.1-1 Collect Stakeholder Needs SP 1.1-2 Elicit Needs SP 1.2-1 Develop the Customer Requirements

SG 2 Develop Product Requirements [PA157.IG103] SP 2.1-1 Establish Product and Product-Component Requirements SP 2.2-1 Allocate Product-Component Requirements SP 2.3-1 Identify Interface Requirements

SG 3 Analyze and Validate Requirements [PA157.IG102] SP 3.1-1 Establish Operational Concepts and Scenarios SP 3.2-1 Establish a Definition of Required Functionality SP 3.3-1 Analyze Requirements SP 3.4-3 Analyze Requirements to Achieve Balance SP 3.5-1 Validate Requirements SP 3.5-2 Validate Requirements with Comprehensive Methods


Required/Expected/Informative Required components

–Specific and generic goals–Achieved by planned and implemented processes

Expected components–Specific and generic practices–Typical implementation to achieve a goal–Practices as described or acceptable alternatives

Informative components–Everything else


Required/Expected/Informative Informative Components

–Typical Work Products Provide example outputs from a practice

–Subpractices Detailed descriptions that provide guidance for interpreting

the practices–Generic Practice Elaborations

Provide guidance on how the generic practices should uniquely be applied to the Process Area


Process Area Categories Project Management Engineering Support Process Management


Project Management PAs Basic Project Management PAs

–Project Planning–Project Monitoring and Control–Supplier Agreement Management

Advanced Project Management PAs–Integrated Project Management–Risk Management–Integrated Supplier Management–Integrated Teaming–Quantitative Project Management


Engineering PAs Engineering Process Areas

–Requirements Management–Requirements Development–Technical Solution–Product Integration–Verification–Validation


Support PAs Basic Support PAs

–Configuration Management–Process and Product Quality Assurance–Measurement and Analysis

Advanced Support PAs–Decision Analysis and Resolution–Organizational Environment for Integration–Causal Analysis and Resolution


Process Management PAs Basic Process Management PAs

–Organizational Process Focus–Organizational Process Definition–Organizational Training

Advanced Process Management PAs–Organizational Process Performance–Organizational Innovation and Deployment


Verifying the Requirements This presentation will provide [1] a high-level

overview of the new model, primarily focusing on what’s RIGHT with the CMMI. Participants will learn about [2] the model’s dual representation – staged and continuous – and will [3] understand how they can use the benefits of both to their best advantage. They will learn about [4] specific vs. generic practices, [5] base vs. advanced practices, and will [6] become world-class experts in the concept of “equivalent staging.”


Questions?

Pat O’[email protected]

MSA Orientation v203a 1 Whats RIGHT with the CMMI?!? Pat OToole

Documents

Transcript of MSA Orientation v203a 1 Whats RIGHT with the CMMI?!? Pat OToole