module 1: introduction to cmmi for development version...

© 2010 Carnegie Mellon University

SM CMM Integration, SCAMPI, SCAMPI Lead Appraiser, TSP, and IDEAL are service marks of Carnegie Mellon University.

® CMMI, Capability Maturity Model, Capability Maturity Modeling, CMM, and Carnegie Mellon are registered in the US Patent and Trademark Office by Carnegie Mellon University. For more information on CMU/SEI Trademark use, please visit http://www.sei.cmu.edu/about/legal-trademarks.html

PG V1

Software Engineering Institute Carnegie Mellon University Pittsburgh, PA 15213

Module 1: Introduction to CMMI for Development Version 1.3

Introduction to CMMI-DEV v1.3

© 2010 Carnegie Mellon University 2

2010-11-01

PG V1

© 2010 Carnegie Mellon University This material is distributed by the SEI only to course attendees for their own individual study. Except for the U.S. government purposes described below, this material SHALL NOT be reproduced or used in any other manner without requesting formal permission from the Software Engineering Institute at [email protected]. This material was created in the performance of Federal Government Contract Number FA8721-05-C-0003 with Carnegie Mellon University for the operation of the Software Engineering Institute, a federally funded research and development center. The U.S. Government's rights to use, modify, reproduce, release, perform, display, or disclose this material are restricted by the Rights in Technical Data-Noncommercial Items clauses (DFAR 252-227.7013 and DFAR 252-227.7013 Alternate I) contained in the above identified contract. Any reproduction of this material or portions thereof marked with this legend must also reproduce the disclaimers contained on this slide.

Although the rights granted by contract do not require course attendance to use this material for U.S. Government purposes, the SEI recommends attendance to ensure proper understanding. THE MATERIAL IS PROVIDED ON AN “AS IS” BASIS, AND CARNEGIE MELLON DISCLAIMS ANY AND ALL WARRANTIES, IMPLIED OR OTHERWISE (INCLUDING, BUT NOT LIMITED TO, WARRANTY OF FITNESS FOR A PARTICULAR PURPOSE, RESULTS OBTAINED FROM USE OF THE MATERIAL, MERCHANTABILITY, AND/OR NON-INFRINGEMENT).



2010-11-01

PG V1

This course

•  illustrates benefits of process improvement

•  introduces CMMI model content (the major focus of this course)

Establishing the Foundation



2010-11-01

PG V1

Course Objectives

By the end of this course, you will be able to •  describe the components of CMMI models and their relationships

•  discuss the process areas

•  locate relevant information in the model



2010-11-01

PG V1

The Audience for this Course

Broad audience •  product developers, process implementers, and managers

•  anyone interested in learning about CMMI No process improvement experience or knowledge of process improvement models is assumed.



2010-11-01

PG V1

Introductions and Expectations

Participant introductions •  name

•  position and background

•  experience with process improvement -  how long?

-  experience with other models or standards

•  expectations -  What do you want to get out of this course?



2010-11-01

PG V1

Participant notebook •  copies of slides •  exercises are at the end of the modules

Addison Wesley Book CMMI: Guidelines for Process Integration and Product Improvement, Third Edition ISBN 0-321-xxxxx-0, Spring, 2011

Software Engineering Institute Technical Report CMMI for Development, Version 1.3 CMU/SEI-2010-TR-033

Model Documents

Course Materials



2010-11-01

PG V1

Logistics



2010-11-01

PG V1

Module 1 Introduction

Module 2 Process Improvement Concepts and CMMI

Module 3 Overview of CMMI Model Components

Module 4 Model Representations and Generic Goals and Practices

Module 5 Product Development 1

Module 6 Managing the Project

Module 7 Project and Organizational Support

Module 8 Product Development 2

Module 9 Improvement Infrastructure

Module 10 High Maturity

Module 11 Tying It All Together

Module 12 Summary

Schedule

DAY 1

DAY 2

DAY 3



2010-11-01

PG V1

Course Approach

Lecture

Exercises

Questions and answers

Discussions

Participation by all is a key element of the course



2010-09-24

PG V1

Rules of Engagement

Participate.

One person speaks at any given time.

Keep discussions and questions to the point.

Turn off your cell phones and other communication devices.

Be prompt returning from breaks.



2010-11-01

PG V1

Completion Criteria

Successful completion of this course requires that participants •  actively participate in classroom discussions and exercises all

three days

•  do not miss any classroom time




PG V1


Module 2: Process Improvement Concepts and CMMI



2010-09-24

PG V1

Topics

Process Improvement Concepts

The CMMI Product Suite

Business Benefits of CMMI

Summary

Exercise 1: Important Process Improvement Concepts



2010-11-01

PG V1

Continuous Representation: PAs by Category

Project Management

Process Areas

Category

Product Integration Requirements Development Technical Solution Validation Verification

Engineering

Causal Analysis and Resolution Configuration Management Decision Analysis and Resolution Measurement and Analysis Process and Product Quality Assurance

Support

Integrated Project Management Project Monitoring and Control Project Planning Quantitative Project Management Requirements Management Risk Management Supplier Agreement Management

Organizational Process Definition Organizational Process Focus Organizational Performance Management Organizational Process Performance Organizational Training

Process Management



2010-11-01

PG V1

Staged Representation: PAs by Maturity Level

Causal Analysis and Resolution Organizational Performance Management

5 Optimizing

4 Quantitatively Managed 3 Defined

2 Managed

Quantitative Management Process Standardization

Basic Project Management

Organizational Process Performance Quantitative Project Management Decision Analysis and Resolution Integrated Project Management Organizational Process Definition Organizational Process Focus Organizational Training Product Integration Requirements Development Risk Management Technical Solution Validation Verification Configuration Management Measurement and Analysis Project Monitoring and Control Project Planning Process and Product Quality Assurance Requirements Management Supplier Agreement Management

1 Initial

Process Areas Level Focus Continuous Process Improvement

Risk Rework

Quality Productivity



2010-11-01

PG V1

What is Process?

How do you define process?



2010-11-01

PG V1

General Definitions of Process

Sequence of steps performed for a given purpose.

Logical organization of people, materials, energy, equipment, and procedures into work activities designed to produce a specified end result.

A set of interrelated activities, which transform inputs into outputs, to achieve a given purpose.

Pall, Gabriel A. Quality Process Management. Englewood Cliffs, N.J.: Prentice Hall, 1987.

IEEE

PALL

CMMI GLOSSARY



2010-11-01

PG V1

The Process Management Premise

The quality of a system is highly influenced by the quality of the process used to acquire, develop, and maintain it. This premise implies a focus on processes as well as on products:

•  This is a long-established premise in manufacturing.

•  Belief in this premise is visible worldwide in quality movements in manufacturing and service industries (e.g., ISO standards).

•  This premise is also applicable to development.



2010-11-01

PG V1

Quality Leverage Points While process is often described as a node of the process-people-technology triad, it can also be considered the “glue” that ties the triad together. Everyone realizes the importance of having a motivated, quality work force but even our finest people cannot perform at their best when the process is not understood or operating at its best.

Major determinant

of product cost, schedule and quality.



2010-11-01

PG V1

Evolutionary Improvement Path

INSTITUTIONALIZED

IMPROVED

AD HOC

Improvised by practitioners and their management

Defined, documented, and continuously

improved

“That's the way we do things around here.”



2010-11-01

PG V1

Ad Hoc Processes

Process descriptions are not rigorously followed or enforced.

Performance is highly dependent on current practitioners.

Understanding of the current status of a project is limited.

Immature processes result in fighting fires:

•  There is no time to improve—instead, practitioners are constantly reacting.

•  Firefighters get burned.

•  Embers might rekindle later. INSTITUTIONALIZED

IMPROVED

AD HOC



2010-11-01

PG V1

Improved Processes

Process descriptions are consistent with the way work actually is done.

Processes are supported visibly by management and others.

They are well controlled—process fidelity is evaluated and enforced.

There is constructive use of product and process measurement.

Technology is introduced in a disciplined manner. INSTITUTIONALIZED

IMPROVED

AD HOC



2010-11-01

PG V1

Institutionalized Processes

The organization builds an infrastructure that contains effective, usable, and consistently applied processes.

The organizational culture conveys the process.

Management nurtures the culture.

Culture is conveyed through role models and recognition.

Institutionalized processes endure after the people who originally defined them have gone.

INSTITUTIONALIZED

IMPROVED

AD HOC



2010-09-24

PG V1

Benefits of Improving Processes

Processes enable you to understand what is going on. By defining, measuring, and controlling the process, improvements are more successful and sustained. The likelihood that appropriate technology, techniques, and tools are introduced successfully increases. People develop their potential more fully and are more effective within the organization.



2010-11-01

PG V1

Process Characteristics Predicted Performance

Process is characterized for projects and is often reactive

Process is characterized for the organization and is proactive

Process is measured and controlled

Focus is on continuous quantitative improvement

Process is unpredictable, poorly controlled, and reactive

Benefits in Terms of Predictability



2010-11-01

PG V1

Early Process Improvement

The theories of process management are a synthesis of the concepts of Deming, Crosby, Juran, and others.

Over the past decades, these theories have been used to address problems common to many organizations.

Solutions to some problems have been developed.

Many of these solutions have been used to build process improvement models.



2010-11-01

PG V1

What Is a Process Model?

A process model is a structured collection of practices that describes the characteristics of effective processes. Practices included are those proven by experience to be effective.



2010-11-01

PG V1

How Is a Process Model Used?

A process model is used

•  to help set process improvement objectives and priorities

•  to help ensure stable, capable, and mature processes

•  as a guide for improving project and organizational processes

•  with an appraisal method to diagnose the state of an organization's current practices



2010-11-01

PG V1

Why Is a Process Model Important?

A process model provides

•  a place to start improving

•  the benefit of a community's prior experiences

•  a common language and a shared vision

•  a framework for prioritizing actions

•  a way to define what improvement means for an organization



2010-11-01

PG V1

CMMI for Process Improvement

Use CMMI in process improvement activities as a

•  collection of best practices

•  framework for organizing and prioritizing activities

•  support for the coordination of multi-disciplined activities that might be required to successfully build a product

•  means to emphasize the alignment of the process improvement objectives with organizational business objectives

CMMI incorporates lessons learned from use of the SW-CMM®, EIA-731, and other standards and models.



2010-09-24

PG V1

Topics




Summary




2010-11-01

PG V1

The CMMI Framework

The CMMI Framework is the basic structure that organizes CMMI components, including common elements of the current CMMI models, as well as rules and methods for generating models, appraisal methods, and training materials.

Model

Appraisal Methods

Training

Subset of the CMMI Product Suite relevant to improvement in a particular

area of interest.

Complete set of products developed around the

CMMI concept.

Development

Model

Training

CMMI Product Suite Constellations

Acquisition

Model

Training

Services

Model

Training

Appraisal Methods



2010-11-01

PG V1

Three Complementary Constellations

Shared PA



2010-11-01

PG V1

A CMMI model is not a process. A CMMI model describes the characteristics of effective processes.

Note

“All models are wrong, but some are useful.” — George Box (Quality and Statistics Engineer)



2010-11-01

PG V1

The Appraisal Method

Appraisal Team

CMMI and SCAMPI Method Appraisal Requirements

Organization Projects Lessons Learned/Improvements

Organizational Processes

Findings, Recommendations Actual Practice



2010-11-01

PG V1

Appraisal Method Classes

Requirements Class A Class B Class C Types of Objective Evidence Gathered

Documents and interviews

Documents and interviews

Documents or interviews

Ratings Generated Goal ratings required

Not allowed Not allowed

Organizational Unit Coverage

Required Not required Not required

Minimum Team Size 4 2 1 Appraisal Team Leader Requirements

Lead Appraiser

Person trained and experienced

Person trained and experienced

Extracted from Appraisal Requirements for CMMI, Version 1.2 (ARC)



2010-11-01

PG V1

SCAMPI Appraisals

Appraisal Requirements for CMMI (ARC) Appraisal requirements

Standard CMMI Appraisal Method for Process Improvement (SCAMPI) Defined and documented type of appraisal that satisfies the requirements stated in the ARC

SCAMPI A Method Definition Document (MDD) SCAMPI method for performing Class A appraisals

Handbook for Conducting SCAMPI B and C Appraisals SCAMPI method for performing Class B and C appraisals



2010-11-01

PG V1

* These courses address CMMI-DEV.

The SEI Training for CMMI

Services Supplement for CMMI-DEV, V1.3

Acquisition Supplement for CMMI-DEV, V1.3

CMMI Level 2 for

Practitioners*

CMMI Level 3 for

Practitioners*

Understanding CMMI High

Maturity Practices

Intermediate Concepts of CMMI, V1.3*

SCAMPI Lead Appraiser Training

CMMI, V1.3 Instructor Training*

Introduction to CMMI-DEV, V1.3



2010-09-24

PG V1

Topics




Summary




2010-11-01

PG V1

Benefits Information

Information about CMMI benefits is available in the August 2006 SEI technical report, Performance Results of CMMI-Based Process Improvement (CMU/SEI-2006-TR-004).

•  This report is based on public reports, interviews, supplementary materials, and comprehensive literature review.

•  It is available in the SEI Library at the SEI Web site

•  The following seven slides are adapted from this technical report.

•  For more information on CMMI performance results, visit the SEI Web site and search for “CMMI Performance Results”.



2010-11-01

PG V1

Impacts: Costs and Benefits of CMMI

OUT IN

BENEFITS

•  Investments •  Expenses

•  Cost •  Schedule •  Productivity •  Quality •  Customer

Satisfaction

Process Capability and Organizational

Maturity

Return on Investment and Cost Benefits

COSTS

ROI



2010-11-01

PG V1

Costs May Vary

The cost of CMMI adoption is highly variable depending on many factors, including organizational

•  goals •  size •  culture •  structure •  processes

Regardless of the investment, organizations generally experience a respectable return on their investment.



2010-11-01

PG V1

Performance Measures - CMMI

The performance results in the following table are from 30 different organizations that achieved percentage change in one or more of the six categories of performance measures below.

Performance Category Median Improvement Cost 34% Schedule 50% Productivity 61% Quality 48% Customer Satisfaction 14% Return on Investment 4:1



2010-11-01

PG V1

Example Benefit -1

The organization 3H Technology, with a little over 2 years of CMMI-based process improvement, showed significant improvement in average number of defects found.



2010-11-01

PG V1

Example Benefit -2

Motorola Global Software Group Russia, a maturity level 5 organization, improved the cost of quality while holding the cost of poor quality steady.

© Motorola, Inc. 2006



2010-11-01

PG V1

Example Benefit -3

The Software Maintenance Group at Warner Robins Air Logistics Center, a maturity level 5 organization, significantly reduced schedule variance.



2010-11-01

PG V1

CMMI Can Benefit You

CMMI provides •  guidance for efficient, effective improvement across multiple process

disciplines in an organization

•  improvements to best practices incorporated from the earlier models

•  a common, integrated vision of improvement for all elements of an organization



2010-11-01

PG V1

Process improvement should be done to help the business— not for its own sake.

The Bottom Line -1

“If you can't describe what you are doing as a process, you don't know what you're doing.” — W. Edwards Deming



2010-11-01

PG V1

The Bottom Line -2

Improvement means different things to different organizations. Improvement is a long-term, strategic effort.



2010-09-24

PG V1

Topics




Summary




2010-11-01

PG V1

Summary

CMMI advances the state of process models by being applicable to the many areas of interest that contribute to business success. The product suite consists of •  models •  appraisal methods •  training materials

Many adopters of CMMI have reported measurable benefits. Businesses can improve through the use of CMMI but change is necessary.



2010-09-24

PG V1

Topics




Summary




2010-11-01

PG V1

Exercise 1

Task Follow the directions in the “Important Process Improvement Concepts” exercise.

Expected Outcome Participants have an opportunity to learn which process improvement concepts are most important to the students.




PG V1


Module 3: Overview of CMMI Model Components



2010-09-24

PG V1

Topics

Contents of the CMMI Model Document

Process Area Components

Supporting Informative Components

Required, Expected, and Informative Model Components

Additions

Glossary

Summary



2010-11-01

PG V1

CMMI for Development Model Document Contents

Note 1: Chapter 6 is in the Addison Wesley book. It does not appear in the technical report form of the model.

Generic Goals and Generic Practices, and the Process Areas

Part Two

A.  References B.  Acronyms C.  CMMI V1.3 Project

Participants D.  Glossary

Part Three

The Appendices

Part One

About CMMI for Development Preface 1.  Introduction 2.  Process Area Components 3.  Tying It All Together 4.  Relationships Among

Process Areas 5.  Using CMMI Models 6.  Essays and Case Studies



2010-11-01

PG V1

Process Areas (PAs) -1

The 22 process areas (in alphabetical order by acronym) are

Causal Analysis and Resolution CAR Configuration Management CM Decision Analysis and Resolution DAR Integrated Project Management IPM Measurement and Analysis MA Organizational Process Definition OPD Organizational Process Focus OPF Organizational Performance Management OPM Organizational Process Performance OPP Organizational Training OT



2010-11-01

PG V1

Process Areas (PAs) -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



2010-09-24

PG V1

Topics





Additions

Glossary

Summary



2010-11-01

PG V1

Expected

Informative

Required

Process Area Components We Will Be Discussing

Specific Practices

(SP)

Generic Practice

Elaborations Subpractices Subpractices Example Work

Products

Introductory Notes

Related Process Areas

Purpose Statement

Generic Goals (GG)

Specific Goals (SG)

Generic Practices

(GP)

Process Area (PA)



2010-11-01

PG V1

Process and Process Area

Process – a sequence of steps performed for a given purpose (IEEE) •  It is how you perform your work.

CMMI Definition of a Process – a set of interrelated activities, which transform inputs into outputs, to achieve a given purpose. These activities can be mapped to one or more practices in CMMI process areas to allow a model to be useful for process improvement and process appraisal.



2010-11-01

PG V1

Process Area

A cluster of related practices in an area that, when implemented collectively, satisfies a set of goals considered important for making improvement in that area.

All CMMI process areas are common to both continuous and staged representations.

They are organized by

•  maturity level in the staged representation

•  process area category (i.e., Process Management, Project Management, Support, and Engineering) in the continuous representation.

There are 22 process areas.



2010-11-01

PG V1

Process Area Contents

All process areas contain the following

•  Purpose Statement

•  Introductory Notes

•  Related Process Areas

•  Specific Goal and Practice Summary

•  Specific Practices by Goal

-  Specific Goals and Specific Practices

•  Generic Practices by Goal

-  Generic Goals and Generic Practices

In “Generic Goals and Generic Practices” section in the model.



2010-11-01

PG V1

Expected

Informative

Required

Process Area Components -1

Specific Practices

(SP)

Generic Practice


Products

Introductory Notes


Purpose Statement

Generic Goals (GG)

Specific Goals (SG)

Generic Practices

(GP)

Process Area (PA)



2010-09-24

PG V1

Purpose Statement

Describes the purpose of the process area

Project Planning example

Purpose The purpose of Project Planning (PP) is to establish and maintain plans that define project activities.

DESCRIPTION

EXAMPLE



2010-09-24

PG V1

Introductory Notes

This section describes the major concepts covered in the process area.


Planning includes estimating the attributes of work products and tasks, determining the resources needed, negotiating commitments, producing a schedule, and identifying and analyzing project risks.

DESCRIPTION

EXAMPLE



2010-09-24

PG V1


This section lists references to related process areas and reflects the high-level relationships among the process areas.


Refer to the Risk Management process area for more information about identifying and analyzing risks and mitigating risks.

DESCRIPTION

EXAMPLE



2010-09-24

PG V1

The titles of the specific goals and specific practices for that process area are summarized at the beginning of each process area.


SG 1 Establish Estimates SP 1.1 Estimate the Scope of the Project SP 1.2 Establish Estimates of Work Product and Task Attributes SP 1.3 Define Project Lifecycle Phases SP 1.4 Estimate Effort and Cost

Specific Goal and Practice Summary

DESCRIPTION

EXAMPLE



2010-11-01

PG V1

Expected

Informative

Required

Process Area Components -2

Specific Practices

(SP)

Generic Practice


Products

Introductory Notes


Purpose Statement

Generic Goals (GG)

Specific Goals (SG)

Generic Practices

(GP)

Process Area (PA)



2010-09-24

PG V1

Specific Goals (SGs)

A specific goal is a required model component that describes the unique characteristics that must be present to satisfy the process area.


SG 1: Estimates of project planning parameters are established and maintained.

Specific goals are numbered starting with the prefix SG (e.g., SG 1). The number is only there to uniquely identify the goal.

DESCRIPTION

EXAMPLE

NUMBERING



2010-09-24

PG V1

Specific Practices (SPs)


SP 1.4: Estimate the project's effort and cost for work products and tasks based on estimation rationale.

Specific practices are expected model components that are considered important in achieving the associated specific goal.

Specific practices are of the form SP x.y where x is the same number as the goal to which the specific practice maps. y is the sequence number of the specific practice under the specific goal.

DESCRIPTION

EXAMPLE

NUMBERING



2010-09-24

PG V1

Example Work Products

Example work products are informative model components that provide sample outputs from a specific practice.

For example, project cost estimates might be an example work product for the Project Planning specific practice SP 1.4, “Estimate the project's effort and cost for work products and tasks based on estimation rationale.”

DESCRIPTION

EXAMPLE



2010-09-24

PG V1

Subpractices

Subpractices are informative model components that provide guidance for interpreting and implementing specific or generic practices.

The following is an example of a subpractice from the “Identify and analyze project risks” specific practice (SP 2.2) in the Project Planning process area:

3. Review and obtain agreement with relevant stakeholders on the completeness and correctness of documented risks.

DESCRIPTION

EXAMPLE



2010-11-01

PG V1

Expected

Informative

Required

Process Area Components We Will Be Discussing

Specific Practices

(SP)

Generic Practice


Products

Introductory Notes


Purpose Statement

Generic Goals (GG)

Specific Goals (SG)

Generic Practices

(GP)

Process Area (PA)



2010-09-24

PG V1

Generic Goals (GGs) -1

Generic goals are required model components that describe characteristics that must be present to institutionalize processes that implement a process area.

Achievement of a generic goal in a process area signifies improved control in planning and implementing the processes associated with that process area.

Generic goals are called generic because the same goal statement applies to multiple process areas.

Generic goal example

The process is institutionalized as a defined process.

DESCRIPTION

EXAMPLE



2010-09-24

PG V1

Generic Goals (GGs) -2

Generic goals are numbered starting with the prefix GG (e.g., GG 2). The number corresponds to the capability level of the GG.

Note: We will talk more about generic goals in Module 4.

NUMBERING



2010-09-24

PG V1

Generic Practices (GPs) -1

Generic practices are expected model components that are considered important in achieving the associated generic goal. Generic practices are called generic because the same practice appears in multiple process areas.

Generic practice example

GP 2.5: Train the people performing or supporting the process as needed.

DESCRIPTION

EXAMPLE



2010-09-24

PG V1

Generic Practices (GPs) -2

Generic practices are of the form GP x.y where x corresponds to the number of the generic goal. y corresponds to the sequence number of the generic practice. Note: We will talk more about generic practices in Module 4.

NUMBERING



2010-09-24

PG V1

Generic Practice Elaborations

Generic practice elaborations are informative model components that appear after a generic practice to provide guidance on how the generic practice could be applied uniquely to a process area.

Project Planning process area example

GP 2.8: Monitor and Control the Process Examples of measures and work products used in monitoring and controlling include the following: -  Number of revisions to the plan -  Cost, schedule, and effort variance per plan revision -  Schedule for development and maintenance of

program plans

DESCRIPTION

EXAMPLE



2010-09-24

PG V1

Topics





Additions

Glossary

Summary



2010-11-01

PG V1


There are many places in CMMI models where further information is provided. This further information is provided in the form of the following components:

•  Examples •  References

•  Notes



2010-09-24

PG V1

Examples

An example is a component comprising text and often a list of items, usually in a box, that can accompany nearly any other component and provides one or more examples to clarify a concept or described activity.

Project Planning SP 1.2 example Examples of attributes to estimate include the following: •  Number of functions •  Function points •  Source lines of code •  Number of pages

DESCRIPTION

EXAMPLE



2010-09-24

PG V1

References

A reference is a pointer to additional or more detailed information in related process areas and can accompany nearly any other model component. A reference is an informative model component.

Project Planning SP 2.2 example

Refer to the Risk Management process area for more information about identifying potential problems before they occur so that risk handling activities can be planned and invoked as needed across the life of the product or project to mitigate adverse impacts on achieving objectives.

DESCRIPTION

EXAMPLE



2010-09-24

PG V1

Notes

A note is text that can accompany nearly any other model component. It may provide detail, background, or rationale. A note is an informative model component.

The example below shows a note that accompanies the specific practice 1.3 in the Project Planning process area.

Project Planning SP 1.3 example

The determination of a project's lifecycle phases provides for planned periods of evaluation and decision making. . . .

DESCRIPTION

EXAMPLE



2010-09-24

PG V1

Topics





Additions

Glossary

Summary



2010-09-24

PG V1

Required, Expected, and Informative Model Components Process area components are grouped into three categories. These categories reflect how to interpret the process area components.

Informative

Required

Expected

1

2

3

Three Categories



2010-09-24

PG V1

Required Components

Required components are CMMI components that are essential to achieving process improvement in a given process area. This achievement must be visibly implemented in an organization's processes.

Goal satisfaction is used in appraisals as the basis for deciding whether a process area has been achieved and satisfied.

Specific goals and generic goals are the required components in CMMI models.



2010-09-24

PG V1

Expected Components

Expected Components are CMMI components that describe the activities that are important in achieving a required CMMI component.

Expected components guide those who implement improvements those who perform appraisals

Specific practices and generic practices are the expected components in CMMI models.

Before goals can be considered to be satisfied, either their practices as described, or acceptable alternatives to them, must be present in the planned and implemented processes of the organization.



2010-09-24

PG V1

Informative Components

Informative components are CMMI components that help model users understand the required and expected components of a model.

Examples of informative components include •  subpractices •  example work products •  generic practice elaborations •  goal and practice titles •  notes •  references



2010-11-01

PG V1

Expected

Informative

Required

Reviewing Process Area Components

Specific Practices

(SP)

Generic Practice


Products

Introductory Notes


Purpose Statement

Generic Goals (GG)

Specific Goals (SG)

Generic Practices

(GP)

Process Area (PA)



2010-09-24

PG V1

Topics





Additions

Glossary

Summary



2010-09-24

PG V1

Additions

Additions are clearly marked model components that contain information of interest to particular users.

Additions can be informative material, a specific practice, a specific goal, or an entire process area that extends the scope of a model or emphasizes a particular aspect of its use.

There are no additions in the CMMI-DEV model.

DESCRIPTION



2010-09-24

PG V1

Topics





Additions

Glossary

Summary



2010-09-24

PG V1

Glossary

Glossary term example

Establish and maintain . . . Create, document, use, and revise work products as necessary to ensure they remain useful.

The glossary defines the basic terms used in CMMI models.

It was designed to document the meaning of words and terms that should have the widest use and understanding by users of CMMI products. Definitions of terms were selected based on recognized sources that have a widespread readership (e.g., ISO, IEEE).

DESCRIPTION

EXAMPLE



2010-09-24

PG V1

Topics





Additions

Glossary

Summary



2010-11-01

PG V1

Summary

In this module we discussed the contents of the CMMI model document including

•  process area components

•  specific goals and practices

•  generic goals and practices

•  required, expected, and informative model components

•  additions

•  glossary




PG V1


Module 4: Model Representations and Generic Goals and Practices



2010-09-24

PG V1

Topics

Model Representations

Process Institutionalization

- Generic Goals and Generic Practices

Applying Generic Practices

Summary

Exercise 2: Process Improvement Goals



2010-11-01

PG V1

CMMI Model Representations

There are two representations in CMMI models: •  staged •  continuous

A representation in CMMI is analogous to a view into a data set provided by a database.

Both representations provide ways of implementing process improvement to achieve business objectives.

Both representations provide essentially the same content and use the same model components but are organized in different ways.



2010-11-01

PG V1

Continuous Representation

The continuous representation offers a flexible approach to process improvement.

An organization may choose to improve the performance of a single process-related trouble spot, or it can work on several areas that are closely aligned to its business objectives.

A continuous representation also allows an organization to improve different processes at different rates.

There are some limitations on choices, however, because of the dependencies among some process areas.



2010-11-01

PG V1

Continuous Representation: PAs by Category

Project Management

Process Areas

Category


Engineering


Support



Process Management



2010-11-01

PG V1

Staged Representation

The staged representation offers a systematic, structured way to approach process improvement one step at a time.

Achieving each stage ensures that an adequate improvement has been laid as a foundation for the next stage.

Process areas are organized by maturity levels.

The staged representation prescribes the order of implementing each process area according to maturity levels, which define the improvement path for an organization from the initial level to the optimizing level.



2010-11-01

PG V1



5 Optimizing


2 Managed




1 Initial


Risk Rework




2010-09-24

PG V1

Topics





Summary




2010-11-01

PG V1


The organization builds an infrastructure that contains effective, usable, and consistently applied processes.

The organizational culture conveys the process.

Management nurtures the culture.

Culture is conveyed through role models and recognition.

Institutionalized processes endure after the people who originally defined them have gone.

Institutionalization means the ingrained way of doing business that an organization follows routinely as part of its corporate culture: “That's the way we do things around here.”

DESCRIPTION



2010-09-24

PG V1

Topics





Summary




2010-11-01

PG V1

Generic Goals and Generic Practices: Building Blocks Generic goals and generic practices contribute to process institutionalization.

The generic goals and generic practices are the model components that provide for commitment and consistency throughout an organization's processes and activities.



2010-11-01

PG V1

Generic Goals and Institutionalization

The degree of institutionalization is embodied in the generic goals and expressed in the names of the processes associated with each goal as indicated below.

* This generic goal is only used in the continuous representation.

GG 1

GG 3

GG 2

Generic Goal and Title Progression of Processes

Institutionalize a Defined Process

Institutionalize a Managed Process

Achieve Specific Goals*

Defined Process

Managed Process

Performed Process



2010-11-01

PG V1

Generic Goals Evolve

Each generic goal provides a foundation for the next. Therefore, the following conclusions can be made:

GG 1

GG 3

GG 2

A defined process includes and builds on a managed process

A managed process includes and builds on a performed process

A performed process



2010-11-01

PG V1

GG 1 GG1 Achieve Specific Goals The specific goals of the process area are supported by the process by transforming identifiable input work products into identifiable output work products. •  A performed process accomplishes the work necessary

to produce work products. •  All specific goals of the process area are

satisfied. •  Essential activities are performed and the

work is accomplished. •  The definition, planning, monitoring, and

controlling of the process may be incomplete.

•  The process may be unstable and inconsistently implemented.

GG1: Performed Process



2010-11-01

PG V1

GP 1.1

GG1 Generic Practices

Perform Specific Practices Perform the specific practices of the process area to develop work products and provide services to achieve the specific goals of the process area



2010-11-01

PG V1

GG 2

GG 2: Managed Process

Institutionalize a Managed Process The process is institutionalized as a managed process. •  A managed process is a performed process that is

planned and executed in accordance with policy; employs skilled people having adequate resources to produce controlled outputs; involves relevant stakeholders; is monitored, controlled, and reviewed; and is evaluated for adherence to its process description.

•  Management of the process is concerned with institutionalization and the achievement of specific objectives established for the process, such as cost, schedule, and quality objectives.



2010-11-01

PG V1

GG 2 Generic Practices -1

The generic practices for managed processes are the same for all process areas. Establish an Organizational Policy Establish and maintain an organizational policy for planning and performing the process. Plan the Process Establish and maintain the plan for performing the process.

GP 2.1

GP 2.2



2010-11-01

PG V1


Provide Resources Provide adequate resources for performing the process, developing the work products, and providing the services of the process. Assign Responsibility Assign responsibility and authority for performing the process, developing the work products, and providing the services of the process. Train People Train the people performing or supporting the process as needed.

GP 2.3

GP 2.4

GP 2.5



2010-11-01

PG V1


Control Work Products Place selected work products of the process under appropriate levels of control. Identify and Involve Relevant Stakeholders Identify and involve the relevant stakeholders of the process as planned. Monitor and Control the Process Monitor and control the process against the plan for performing the process and take appropriate corrective action.

GP 2.6

GP 2.7

GP 2.8



2010-11-01

PG V1


Objectively Evaluate Adherence Objectively evaluate adherence of the process and selected work products against the process description, standards, and procedures, and address noncompliance. Review Status with Higher Level Management Review the activities, status, and results of the process with higher level management and resolve issues.

GP 2.9

GP 2.10



2010-11-01

PG V1

GG 3: Defined Process

Institutionalize a Defined Process The process is institutionalized as a defined process. •  A defined process is a managed process that is

tailored from the organization's set of standard processes according to the organization's tailoring guidelines.

•  A defined process has a maintained process description.

•  A defined process contributes process related experiences to the organizational process assets.

•  The organization's set of standard processes is established and improved over time.

GG 3 GG 3



2010-11-01

PG V1

GG 3 Generic Practices

The generic practices for defined processes are the same for all process areas. Establish a Defined Process Establish and maintain the description of a defined process Collect Process Related Experiences Collect process related experiences derived from planning and performing the process to support the future use and improvement of the organization's processes and process assets.

GP 3.1

GP 3.2



2010-11-01

PG V1

Summarizing Generic Goals and Practices

GG 2 Institutionalize a Managed Process

GG 3 Institutionalize a Defined Process

GG 1 Achieve Specific Goals

GP 2.1 GP 2.2 GP 2.3 GP 2.4 GP 2.5 GP 2.6 GP 2.7 GP 2.8 GP 2.9 GP 2.10

Establish an Organizational Policy Plan the Process Provide Resources Assign Responsibility Train People Control Work Products Identify and Involve Relevant Stakeholders Monitor and Control the Process Objectively Evaluate Adherence Review Status with Higher Level Management

GP 1.1 Perform Specific Practices

GP 3.1 GP 3.2

Establish a Defined Process Collect Process Related Experiences

Generic Practices Generic Goals



2010-09-24

PG V1

Topics





Summary




2010-11-01

PG V1


•  All process areas have generic practices that apply to them.

•  Generic practices ensure sustainability of the specific practices in the processes over time.

•  For example, GP 2.2, “Establish and maintain the plan for performing the process,” when applied to Project Planning, ensures that you planned the activities for creating the plan for the project.



2010-09-24

PG V1

Topics





Summary




2010-11-01

PG V1

Summary

There are two representations in CMMI model, staged and continuous.

CMMI supports two improvement paths: •  incrementally improving processes corresponding to individual

process areas

•  improving a set of related processes by incrementally addressing successive predefined sets of process areas

Institutionalized processes are more likely to be retained during times of stress.

Degree of institutionalization is embodied in the generic goals and expressed through the practices associated with each generic goal.



2010-09-24

PG V1

Topics





Summary




2010-11-01

PG V1

Exercise 2

Task Follow the directions in the “Process Improvement Goals” exercise.

Expected Outcome Participants have an opportunity to identify and discuss their process improvement goals.

127!© Copyright 2004-2011 The Process Group. All rights reserved.! PGV1!www.processgroup.com!

THE

GROUPPROCESS

Potential Problem !

•  Process-centric improvement

– SEI CMMI – ISO9001 – Bellcore

•  It can work! – High risk of failure

Processes!

Business!problems!

Business!goals!


THE

GROUPPROCESS

Starting point

Common result: Lost in the trees


THE

GROUPPROCESS

A Solution!

•  Goal-problem-centric improvement

•  Goals and problems can be used to scope and sequence the improvement effort

Business!goals!

Business!problems!

Processes!


THE

GROUPPROCESS

Goal

Starting point

•  Goal actions •  Improvement actions

Problems


THE

GROUPPROCESS

Goal-problem Approach!•  STEP 1

– State your goals for the next 6-18 months

•  STEP 2

– State your current problems (and/or risks)

•  STEP 3

– If you are using a process improvement model or standard, determine which elements help each of the problems/goals listed

•  STEP 4!– Set priorities


THE

GROUPPROCESS

Using the Approach!•  What is your goal?

» Reduce release cycle to 6-9 months for product X

•  What is preventing you from achieving the goal? » Changing requirements » Poor quality of incoming code from other groups » Too many features for 6-9 month development cycle » Inadequate availability of test equipment » Don't always have the resources available to

complete the planned work » Difficult to find defects early


THE

GROUPPROCESS

Mapping to CMMI!

Goal: Reduce release cycle to six to nine months for product X.

Problems PA component that would help this problem

Changing requirements. Level 2: REQM – SP 1.3, 1.4, 1.5; CM – SP 1.2,1.3, 2.1, 2.2.

The poor quality of incoming code fromother groups.

Level 3: IPM – SP 2.2, 2.3; VER – SP 2.2; PI –3.1.

Too many features are required for a six tonine month development cycle.

Level 2: PP – SP 1.1, 2.1, 2.2, 3.2, 3.3.Level 3: RD – SP 3.3, 3.4.

Inadequate availability of test equipment. Level 2: PP – SP 2.2, 2.4.Level 3: VAL – SP 1.2.

Don’t always have the resources availableto complete the planned work.

Level 2: PP – SP 1.1, 2.1, 2.2, 3.2, 3.3.Level 3: IPM – SP 1.2, 1.4; RSKM – SP 3.1.

Difficult to find defects early. Level 3: VER – SP 2.2, 3.1, GP 2.3.


THE

GROUPPROCESS

Improvement Plan - 1!Action Plan Owner: __Jane______________

Primary Goal and Intermediate Goals

(The results you want)

Purpose of Goal (Why do you want to achieve the goal?)

Actions Priority (*=essential)

Reduce product development cycle to six to nine months for product X.

Deliver earlier than competition.

Manage changing requirements (based on problem 1).

Prevent schedule slips resulting from expensive scope changes.

Only allow changes to the application interface, not the kernel routines.

1*

Assign responsibility and authority for performing the REQM process.

2*

Check progress and take corrective action. - Improve the library control system to minimize

version control errors. Investigate requirements management tools.

3

Track change requests for the configuration items. 4 Develop an understanding with the requirements

providers on the meaning of the requirements. 5

Baseline the requirements before design commences. 6

Add placeholder for checking progress and taking corrective action


THE

GROUPPROCESS

Improvement Plan - 2!Action Plan Owner: __Jane______________

Primary Goal and Intermediate Goals

(The results you want)

Purpose of Goal (Why do you want to achieve the goal?)

Actions Priority (*=essential)

Set feature priorities for a six- to nine-month development cycle (based on problem 3).

Ensure commitments are achievable.

Establish a review process with clients to negotiate features for a six- to nine-month development cycle.

1*

Rate each feature based on value to the customer (1-10 points) and cost to develop (1-10 points).

2*

Check progress and take corrective action. - Reconcile the project plan to reflect available and

estimated resources. 3

Identify and analyze project risks. 4 Establish incremental delivery plan to phase in lower

priority features. 5

© Copyright 2004-2011 The Process Group. All rights reserved.! 136 !

THE

GROUPPROCESS

PGV1!www.processgroup.com!

Exercise: Scoping Your Improvement!•  Write down your top 1-2 project deadlines/deliverables

related to your current work (e.g., the delivery of a current product, changes to an existing product, or improvement goal)

– HUT system v1.6, August 23rd, 20YY – Defect level reduced by 20% - December 4th, 20YY

•  Write down your top 3-5 problems (and/or risks) related to each goal

– No resources assigned – No version list of components we depend on – Customers change requirements too fast, too late




PG V1


Module 5: Product Development 1



2010-09-24

PG V1

Topics

The Presentation Order of Process Areas

Product Development 1 Process Areas

- Requirements Management (REQM)

- Requirements Development (RD)

Product Development 1 Summary



2010-11-01

PG V1

The Presentation Order of Process Areas in this Course The CMMI for Development model organizes the process areas in alphabetical order by acronym. There are many process area relationships: •  organized by process area category in the continuous

representation •  organized by maturity level in the staged representation

This course will use a view into process area relationships revolving around doing the work in a business. This view is for instructional purposes.



2010-11-01

PG V1

Understanding the Work

Module 5

RD REQM

Doing the Work of the Organization * Understanding

the Work

Product Development



2010-11-01

PG V1

Organizing and Managing the Work

Module 6

PP PMC

RSKM SAM


Managing the Project

Module 5

RD REQM


the Work

Product Development



2010-11-01

PG V1

Providing Infrastructure

Module 7

CM PPQA

MA DAR

Providing Infrastructure for

Projects and Organizations

Project and Org Support

Module 6

PP PMC

RSKM SAM



Module 5

RD REQM


the Work

Product Development



2010-11-01

PG V1

Module 5

RD REQM


the Work

Product Development

Performing the Work

Module 7

CM PPQA

MA DAR




Module 6

PP PMC

RSKM SAM



Doing the Work of the Organization

* Understanding the Work

* Performing the Work

Product Development

Module 8

TS PI

VER VAL



2010-11-01

PG V1

Enabling Improvement

Module 9

OPF OPD IPM OT

Enabling Improvement of

the Work

Improvement Infrastructure

Module 7

CM PPQA

MA DAR




Module 6

PP PMC

RSKM SAM



Module 5

RD REQM




Product Development

Module 8

TS PI

VER VAL



2010-11-01

PG V1

Adding High Maturity

Module 10

OPP QPM CAR OPM

Enabling Performance

Management of the Work

High Maturity

Module 9

OPF OPD IPM OT


the Work


Module 7

CM PPQA

MA DAR




Module 6

PP PMC

RSKM SAM



Module 5

RD REQM




Product Development

Module 8

TS PI

VER VAL

© Copyright 2008-2011 The Process Group. All rights reserved.!

THE

GROUPPROCESS


Requirements

Requirements Design Implement Test Integrate Release

Architecture Release 1 Rel 2 Rel 3

REQM (requirements and changes)

Prototype Planning ò ò ò

ò ò ò

Process Areas in Context!

REQM REQM REQM PP (plans, estimates)

PMC (progress tracking and corrective action) MA (objectives & measures) CM (baselines & versions) SAM (supplier selection & management) PPQA (process & product check)

Green = Maturity Level 2 PAs



© Copyright 2008-2011 The Process Group. All rights reserved.!

THE

GROUPPROCESS


Requirements (RD) Design (TS) Implement (TS) Test (VER/VAL) Integrate (PI) Release

REQM (requirements and changes)

ò ò ò ò ò ò

REQM REQM REQM PP / IPM (plans, estimates)

IPM (planning w/ assets, data, program-level tracking) RSKM (risk management) OT (planned training program) OPF (process improvement focus) OPD (process asset creation / update) DAR (tradeoffs using criteria) VER (find defects) VAL (prove it works)

PMC (progress tracking and corrective action) MA (objectives & measures) CM (baselines & versions) SAM (supplier selection & management) PPQA (process & product check)

Green = Maturity Level 2 PAs Blue = Maturity Level 3 PAs



Requirements Architecture Release 1 Rel 2 Rel 3

Prototype Planning



2010-11-01

PG V1

Organization of Process Areas

Process Area Sampling of Work Products – graphic showing a sampling of work products in relation to PA specific practices

Process Area Sampling of PA Relationships – graphic showing a sampling of PA relationship to PA specific practices

PA Case Study Example – example application of the PA to the case study

SG 1

SP 1

Select Solutions

DAR SP 1.6

Focus Areas

Purpose describes the purpose of the process area

Relevant Terminology definitions of important terms from the model glossary

When a PA Is Not Done Well… discussion points for when a PA is not done well

Process Area Specific Goals PA specific goal statements

Process Area Specific Practices PA specific practice titles*

Project Plans

* Only PA specific practice titles are presented, not PA specific practice statements which may provide more information. For example, the specific practice statement for PP SP 1.1, “Establish a top-level work breakdown structure (WBS) to estimate the scope of the project.” provides more information than the specific practice title, “Estimate the Scope of the Project”.



2010-11-01

PG V1

Case Study: The Company

•  Premier Advanced Security Systems, Inc. (PASS) provides extremely high-end, high quality home security systems •  Price is never considered, i.e., customers pay to get what they want •  PASS would like to get into low-end home security systems

Typical Clients

Heads of State Famous Celebrities

High-level Executives of Multi-billion Dollar

Organizations



2010-11-01

PG V1

Case Study: The Customer •  SaveAll discount chain is the most popular chain in the country •  SaveAll wants a cheap economical SaveAll-brand home security system •  System will sell for no more than $199 •  Prototype will be delivered in 12 months •  Budget to complete the job is very small •  SaveAll wants PASS because of their reputation for marketing



2010-11-01

PG V1

What SaveAll is Envisioning

•  House has sensors for doors and windows and sensors to detect motion •  Residents enter a password, then press the On button, to turn on the system •  The system beeps while the resident leaves the house •  After the beeping stops, the system monitors the house for any disturbances •  When a disturbance is detected, the sirens turn on



2010-11-01

PG V1

This Module Focuses On

Module 10

OPP QPM CAR OPM



High Maturity

Module 9

OPF OPD IPM OT


the Work


Module 7

CM PPQA

MA DAR




Module 6

PP PMC

RSKM SAM



Module 8

TS PI

VER VAL


the Work

Product Development



Product Development

Module 5

RD REQM



2010-09-24

PG V1

Topics








2010-11-01

PG V1

Product Development 1 Involves

Establishing and maintaining sets of requirements

•  customer requirements

•  product requirements

•  product component requirements

•  managing the requirements as the product evolves



2010-09-24

PG V1

Topics








2010-11-01

PG V1

Requirements Management (REQM)

Purpose Manage requirements of the project's products and product components and to ensure alignment between those requirements and the project's plans and work products.



2010-09-24

PG V1

Relevant Terminology

Requirements Traceability A discernable association between requirements and related requirements, implementations, and verifications. Bidirectional Traceability An association among two or more logical entities that is discernable in either direction (i.e., to and from an entity).



2010-09-24

PG V1

When Requirements Management Is Not Done Well…

Requirements are accepted by staff from any source they deem to be authoritative. The project experiences a high level of requirements changes. There are high levels of rework throughout the project. There is an inability to prove that the product meets the approved requirements. Lack of requirements traceability often results in incomplete or incorrect testing of the product.



2010-11-01

PG V1

Requirements Management Goals

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

SG 1

The process area also has generic goals to support institutionalization.



2010-11-01

PG V1

Requirements Management Specific Practices

SP 1.1 Understand 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 Ensure Alignment Between Project Work and Requirements

Manage Requirements

SG 1



2010-11-01

PG V1

Requirements Traceability Matrix

Obtain Commitment

to Requirements

SP 1.2

Understand Requirements

SP 1.1

Ensure Alignment

Between Project Work and

Requirements

SP 1.5

Maintain Bidirectional

Traceability of Requirements

SP 1.4

Manage Requirements

Changes

SP 1.3

Requirements Management Sampling of Work Products



2010-11-01

PG V1

Ensure Alignment

Between Project Work and

Requirements

SP 1.5 Maintain

Bidirectional Traceability of Requirements

SP 1.4

Manage Requirements

Changes

SP 1.3 Obtain

Commitment to

Requirements

SP 1.2

Understand Requirements

SP 1.1

Analyze Requirements

RD SP 3.3

Establish Product and

Product Component

Requirements

RD SP 2.1

Track Change

Requests

CM SP 2.1

Requirements Management Sampling of PA Relationships



2010-11-01

PG V1

Requirements Management Case Study Example Focus Area

SP 1.1 Understand 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 Ensure Alignment Between Project Work and Requirements

Manage Requirements

SG 1 Focus

Area



2010-11-01

PG V1

Requirements Management Case Study Example

Which of the following examples of requirements traceability are adequate?

1. Customer requirements to system requirements and vice versa, but no other traceability

2. System requirements to software and hardware requirements and vice versa, but no other traceability

3. Software/hardware requirements to design components and test cases and vice versa, but no other traceability


THE

GROUPPROCESS


Example Change Control Process (REQM GP 2.2)

Submitted

Evaluated Rejected

Approved

Change Made

Verified

Closed

Verifier hasconfirmed thechange

Modifier hasinstalled product

verificationfailed

Modifier has madethe change andrequested verification

no verificationrequired; Modifierhas installedproduct

CCB decided to makethe change, allocatedit to a release, andassigned a Modifier

CCB decidednot to makethe change

Evaluator performedimpact analysis

Originator submitteda change request

Canceled

change was canceled

change was canceled

change wascanceled

See change_control_process.doc at:

http://www.processgroup.com/downloads.html



2010-09-24

PG V1

Topics








2010-11-01

PG V1

Requirements Development (RD)

Purpose Elicit, analyze, and establish customer, product, and product component requirements.



2010-09-24

PG V1

Relevant Terminology -1

Allocated Requirement Requirement that results from levying all or part of a higher level requirement on a lower level architectural element or design component. Derived Requirements Requirements that are not explicitly stated in the customer requirements, but are inferred (1) from contextual requirements (e.g., applicable standards, laws, policies, common practices, management decisions), or (2) from requirements needed to specify a product or service component.

Derived requirements can also arise during analysis and design of components of the product or system.



2010-09-24

PG V1


Quality Attribute A property of a product or service by which its quality will be judged by relevant stakeholders. Quality attributes are characterizable by some appropriate measure. Quality attributes are non-functional, such as timeliness, throughput, responsiveness, security, modifiability, reliability, and usability. They have a significant influence on the architecture.



2010-09-24

PG V1

When Requirements Development Is Not Done Well…

Unstated requirements or poorly stated requirements lead to confusion among staff and customers. Design, implementation, and test work products inconsistently interpret the requirements. It takes an inordinately long time to get agreement on product design. There is an increased potential for higher costs to meet customer expectations.



2010-11-01

PG V1

Requirements Development Goals

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

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

SG 1

Develop Product Requirements SG 2


The requirements are analyzed and validated. Analyze and Validate Requirements

SG 3


THE

GROUPPROCESS


Requirements Development & Management Process (SG 1 + SG 2 + GP 3.1)

Start! Identify!Users!

Define !Vision!

& Scope!

Understand!User Needs!

Derive!Functional!

Requirements!

Analyze &!Verify!

Requirements!

Manage !Requirements!

Changes!



2010-11-01

PG V1

Requirements Development Specific Practices -1

Develop Customer Requirements SP 1.1 Elicit Needs SP 1.2 Transform Stakeholder Needs into

Customer Requirements

SG 1

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

SG 2



2010-11-01

PG V1

Requirements Development Specific Practices -2

SP 3.1 Establish Operational Concepts and Scenarios SP 3.2 Establish a Definition of Required Functionality and Quality Attributes SP 3.3 Analyze Requirements SP 3.4 Analyze Requirements to Achieve Balance SP 3.5 Validate Requirements

Analyze and Validate Requirements

SG 3



2010-11-01

PG V1

Customer Requirements

Product, Product Component, and

Interface Requirements


Product Component

Requirements

SP 2.1 Transform

Stakeholder Needs into Customer

Requirements

SP 1.2

Elicit Needs

SP 1.1

Identify Interface

Requirements

SP 2.3

Allocate Product

Component Requirements

SP 2.2


SP 3.3 Establish

Operational Concepts and

Scenarios

SP 3.1

Validate Requirements

SP 3.5 Analyze

Requirements to Achieve Balance

SP 3.4

Stakeholder Needs

Establish a Definition of

Required Functionality and Quality Attributes

SP 3.2

Requirements Development Sampling of Work Products



2010-11-01

PG V1

Establish Operational

Concepts and Scenarios

SP 3.1

Identify Interface

Requirements

SP 2.3


Product Component

Requirements

SP 2.1 Transform

Stakeholder Needs into Customer

Requirements

SP 1.2

Elicit Needs

SP 1.1


SP 3.5


to Achieve Balance

SP 3.4


SP 3.3

Select Product

Component Solutions

TS SP 1.2

Establish a Definition of

Required Functionality and Quality Attributes

SP 3.2

Manage Requirements

Changes

REQM SP 1.3

Requirements Development Sampling of PA Relationships

Allocate Product

Component Requirements

SP 2.2



2010-11-01

PG V1

Applying Process Areas in the Multiple Layers of a Product Engineering process areas are written to support recursion throughout the product architecture.

This means that the specific practices need to be interpreted according to the needs of the product.

Engineering process areas can be applied to a product that has several layers of product components.



2010-11-01

PG V1

Process areas can be applied in more than one instance in a product structure.

Product requirements exist here.

Product component requirements exist here.

One person's product component may be another person's product.

Process Area Applicability in a Product Hierarchy


THE

GROUPPROCESS


Good Requirements Practices: Elicitation (SG 1)

•  Select product champions

•  Establish focus groups

•  Write project vision and scope

– e.g., product/business requirements

•  Identify user classes and characteristics

•  Identify use cases

•  Define quality attributes

•  Examine problem reports Based on In Search of Excellent Requirements, Copyright © 2000 by Karl E. Wiegers. Modifications & additions Copyright © 2002 The Process Group


THE

GROUPPROCESS


Good Requirements Practices: Specification (SG 2)

•  Identify functional requirements •  Identify the source of each requirement •  Uniquely label each requirement •  Record business rules •  Create requirements traceability matrix •  Adopt a product requirements specification

template

Based on In Search of Excellent Requirements, Copyright © 2000 by Karl E. Wiegers. Modifications & additions Copyright © 2002 The Process Group


THE

GROUPPROCESS


Example Requirements Format (SG 2) #1: Business

Requirements

Vision and Scope Document

#2: User Requirements

Use Case Document

#3:Functional Requirements

Requirements Specification

Constraints

Other Nonfunctional Requirements

Business Rules

Quality Attributes

System Requirements




2010-11-01

PG V1

Requirements Development Case Study Example Focus Areas

SP 3.1 Establish Operational Concepts and Scenarios SP 3.2 Establish a Definition of Required Functionality and Quality Attributes SP 3.3 Analyze Requirements SP 3.4 Analyze Requirements to Achieve Balance SP 3.5 Validate Requirements

Analyze and Validate Requirements

SG 3 Focus Areas



2010-11-01

PG V1

Requirements Review

•  Add missing requirement to detect a broken window.

•  SaveAll indicated the * and # keys are not used so requirements are not needed.

•  SaveAll added a requirement for motion sensors to detect the exact locations where the burglar walked in the room so the resident can tell where the burglar went. It also tracks how long the burglar is in each room.

Are the requirements sufficient? Anything missing?

Are the requirements necessary? Delete something?

Are requirements versus constraints balanced? Delete due to cost and schedule constraints?

PASS reviewed the requirements and asked themselves these questions


THE

GROUPPROCESS

PGV1!www.processgroup.com!Based on In Search of Excellent Requirements, Copyright © 2000 by Karl E. Wiegers. Modifications & additions Copyright © 2002 The Process Group

Automated Requirement Measurement (ARM): http://satc.gsfc.nasa.gov/tools/arm

Good Requirements Practices: Analysis (SP 3.3)

•  Draw a context diagram to clarify project scope •  Create user interface prototypes •  Analyze requirements feasibility •  Prioritize the requirements •  Model the requirements

– E.g., event table, dialogue map •  Create a data dictionary •  Use the ARM* tool to highlight potential defects


THE

GROUPPROCESS


Good Requirements Practices: Verification (SP 3.5)

•  Peer review (inspect) requirements documents •  Write test cases from requirements •  Define acceptance criteria •  Evaluate prototypes



THE

GROUPPROCESS


Good Requirements Practices: Management (GP 2.6)

•  Define requirements change control process •  Establish change control board •  Baseline and control versions of requirements

documents •  Perform requirements change impact analysis •  Trace each change to all affected work products •  Maintain history of requirements changes •  Track requirements status •  Measure requirements stability



THE

GROUPPROCESS


Sampling the Generic Practices

•  GP 3.1 – Detailed process, template, tailoring guidelines for

requirements elicitation / writing / analysis activities

•  GP 3.2 – Example metrics: Requirements volatility, requirements

growth, requirements defects – Example requirements documents – Lessons learned



2010-09-24

PG V1

Topics








2010-11-01

PG V1


RD: Requirements Development Emphasizes the establishment of customer, product, and product component requirements

REQM: Requirements Management Adds the management of requirements to provide a well-controlled foundation on which the product is built

Module 5

RD REQM


the Work

Product Development




PG V1


Module 6: Managing the Project



2010-11-01

PG V1


Module 10

OPP QPM CAR OPM



High Maturity

Module 9

OPF OPD IPM OT


the Work


Module 7

CM PPQA

MA DAR




Module 5

RD REQM




Product Development

Module 8

TS PI

VER VAL

Module 6

PP PMC

RSKM SAM





2010-09-24

PG V1

Managing the Project Involves

•  Estimating the scope and work that needs to be performed

•  Developing mechanisms to acquire identified products

•  Developing a project plan

•  Getting commitments to the plan

•  Working with suppliers to acquire identified products

•  Monitoring progress against the plan

•  Identifying and analyzing risks

•  Taking action to address significant deviations from the plan

•  Taking action to appropriately mitigate risks



2010-09-24

PG V1

Topics

Managing the Project Process Areas

Project Planning (PP)

Project Monitoring and Control (PMC)

Risk Management (RSKM)

Supplier Agreement Management (SAM)

Managing the Project Summary



2010-09-24

PG V1


Purpose Establish and maintain plans that define project activities.

Product

Planning



2010-09-24

PG V1


Project •  A managed set of interrelated activities and resources,

including people, that delivers one or more products or services to a customer or end user.

•  A project has an intended beginning (i.e., project startup) and end. Projects typically operate according to a plan. Such a plan is frequently documented and specifies what is to be delivered or implemented, the resources and funds to be used, the work to be done, and a schedule for doing the work. A project can be composed of projects.

•  In some contexts, the term “program” is used to refer to a project.

Work breakdown structure (WBS) •  An arrangement of work elements and their relationship to

each other and to the end product or service.



2010-09-24

PG V1

When Project Planning Is Not Done Well…

Estimates of project attributes are inaccurate. It is difficult to identify deviations from poorly documented plans. Resources are not available/applied when needed. Future projects cannot learn from completed projects because there are no lessons learned.



2010-09-24

PG V1

Project Planning Goals

A project plan is established and maintained as the basis for managing the project.

Establish Estimates Estimates of project planning parameters are established and maintained.

SG 1

Develop a Project Plan SG 2


Commitments to the project plan are established and maintained.

Obtain Commitment to the Plan SG 3



2010-11-01

PG V1

Project Planning Specific Practices -1

SP 1.1 Estimate the Scope of the Project SP 1.2 Establish Estimates of Work Product and Task Attributes SP 1.3 Define Project Lifecycle Phases SP 1.4 Estimate Effort and Cost

Establish Estimates

SG 1



2010-11-01

PG V1

Project Planning Specific Practices -2

SP 2.1 Establish the Budget and Schedule SP 2.2 Identify Project Risks SP 2.3 Plan Data Management SP 2.4 Plan the Project's Resources SP 2.5 Plan Needed Knowledge and Skills SP 2.6 Plan Stakeholder Involvement SP 2.7 Establish the Project Plan

Develop a Project Plan

SG 2

Obtain Commitment to the Plan SP 3.1 Review Plans That Affect the Project SP 3.2 Reconcile Work and Resource Levels SP 3.3 Obtain Plan Commitment

SG 3



2010-11-01

PG V1

Planning Data Project Plans

Define Project

Lifecycle Phases

SP 1.3 Establish

Estimates of Work Product

and Task Attributes

SP 1.2

Estimate the Scope of the

Project

SP 1.1

Obtain Plan Commitment

SP 3.3 Reconcile Work and Resource

Levels

SP 3.2

Review Plans that Affect the

Project

SP 3.1

Determine Estimates of

Effort and Cost

SP 1.4

Relevant Stakeholders

Project Planning Sampling of Work Products -1



2010-11-01

PG V1

Planning Data Project Plans

Plan Data

Management

SP 2.3

Identify Project Risks

SP 2.2

Establish the Budget and Schedule

SP 2.1

Plan Stakeholder Involvement

SP 2.6 Plan for Needed

Knowledge and Skills

SP 2.5

Plan for Project

Resources

SP 2.4

Establish the Project Plan

SP 2.7

Project Planning Sampling of Work Products -2



2010-11-01

PG V1

Estimate Effort and Cost

SP 1.4

Define Project

Lifecycle Phases

SP 1.3 Establish

Estimates of Work Product

and Task Attributes

SP 1.2

Estimate the Scope of the

Project

SP 1.1

Establish the Budget and Schedule

SP 2.1


SP 2.2

Identify Risks

RSKM SP 2.1

Monitor Project Risks

PMC SP 1.3

Plan Data

Management

SP 2.3

Monitor Data

Management

PMC SP 1.4

Monitor Project

Planning Parameters

PMC SP 1.1

Project Planning Sampling of PA Relationships -1



2010-11-01

PG V1

Plan Needed Knowledge and Skills

SP 2.5

Plan the Project's

Resources

SP 2.4

Establish the Project Plan

SP 2.7


SP 2.6

Determine Which Training Needs are the

Responsibility of the Organization

OT SP 1.2

Monitor Stakeholder Involvement

PMC SP 1.5

Manage Stakeholder Involvement

IPM SP 2.1

Obtain Plan Commitment

SP 3.3 Reconcile Work and Resource

Levels

SP 3.2

Review Plans that Affect the

Project

SP 3.1

Project Planning Sampling of PA Relationships -2



2010-11-01

PG V1

Project Planning Case Study Example Focus Area

SP 2.1 Establish the Budget and Schedule SP 2.2 Identify Project Risks SP 2.3 Plan Data Management SP 2.4 Plan the Project's Resources SP 2.5 Plan Needed Knowledge and Skills SP 2.6 Plan Stakeholder Involvement SP 2.7 Establish the Project Plan

Develop a Project Plan

SG 2 Focus

Area



2010-09-24

PG V1

Project Planning Case Study Example

PASS is planning their resources. What project resources should be included?

1. Tools

2. Budget/funding

3. Staff

4. Project plans

5. Facilities


THE

GROUPPROCESS


Example Planning Process

Project plan process & template at: www.processgroup.com/downloads.html


THE

GROUPPROCESS


Example Process for Schedule Creation (PP SP 2.1, GP 3.1)

1. Determine task dependencies. 2. Add task EFFORT estimates. 3. Add resources - people, equipment, resource assumptions. 4. Add resource availability - %allocation, calendar days out.

Deadline

27 person wks (12 weeks)

Task 1 6*40; Jim, Jane

@75% Task 3

24*40; Fred @66% Task 7

18*40; Jane@40% Jim, Pete@80%

Task 2 5*40; Fred @25%

Task 5 12*40; Jane @ 40%, Fred @80%

Task 4 27*40; Jim, Jane, Pete

Each @ 75%

Task 8 24*40; J, J, P

@80%




24 person wks (36 weeks) 15 person wks

(7.5 weeks) 18 person wks

(9 weeks) 24 person wks

(10 weeks)

= Critical Path 66.5 calendar weeks

Task 6 15*40; Jane@40%

Jim, Pete@80%


THE

GROUPPROCESS


Step 1: Project team determines high-level needs (or scope of work), from customer and marketing input

Step 2: Project team develops an initial project plan and estimates to determine what is feasible

Step 3: Project team meets with management, marketing, customers and related groups to determine whether: -  the change or solution is feasible -  there is agreement to the resource, cost and schedule estimates -  the risk is acceptable

Step 4: A commitment is made OR further negotiation is held

Example Process for Managing Commitments (PP SP 3.2)



2010-09-24

PG V1

Topics


- Project Planning (PP)

- Project Monitoring and Control (PMC)

- Risk Management (RSKM)

- Supplier Agreement Management (SAM)




2010-09-24

PG V1


Purpose Provide understanding of the project's progress so that appropriate corrective actions can be taken when the project's performance deviates significantly from the plan.

Plan vs Actual



2010-09-24

PG V1

When Project Monitoring and Control Is Not Done Well…

Too much time is spent trying to determine project status. Data needed for management decisions are not available when needed. Corrective action is not taken early when it is least expensive. Lack of management insight makes project results highly unpredictable. The customer does not have confidence in the project status reporting.



2010-09-24

PG V1

Project Monitoring and Control Goals

Corrective actions are managed to closure when the project's performance or results deviate significantly from the plan.

Monitor the Project Against Plan Actual project progress and performance are monitored against the project plan.

SG 1

Manage Corrective Action to Closure

SG 2




2010-11-01

PG V1

SP 1.1 Monitor Project Planning Parameters SP 1.2 Monitor Commitments SP 1.3 Monitor Project Risks SP 1.4 Monitor Data Management SP 1.5 Monitor Stakeholder Involvement SP 1.6 Conduct Progress Reviews SP 1.7 Conduct Milestone Reviews

Monitor the Project Against Plan

SG 1

Project Monitoring and Control Specific Practices -1

Manage Corrective Action to Closure SP 2.1 Analyze Issues SP 2.2 Take Corrective Action SP 2.3 Manage Corrective Actions

SG 2



2010-11-01

PG V1

Issues and Corrective

Actions


SP 1.3

Monitor Commitments

SP 1.2 Monitor Project

Planning Parameters

SP 1.1


SP 1.5

Monitor Data Management

SP 1.4

Analyze Issues

SP 2.1

Conduct Milestone Reviews

SP 1.7

Conduct Progress Reviews

SP 1.6

Manage Corrective

Actions

SP 2.3

Take Corrective

Action

SP 2.2

Project Monitoring and Control Sampling of Work Products

Project Plans



2010-11-01

PG V1

Conduct Progress Reviews

SP 1.6


SP 1.5

Monitor Data Management

SP 1.4


SP 1.3

Monitor Commitments

SP 1.2 Monitor Project

Planning Parameters

SP 1.1

Manage Corrective

Actions

SP 2.3

Take Corrective

Action

SP 2.2

Analyze Issues

SP 2.1

Plan Data Management

PP SP 2.3

Conduct Milestone Reviews

SP 1.7


IPM SP 2.1


PP SP 2.2

Project Monitoring and Control Sampling of PA Relationships


PP SP 2.6


THE

GROUPPROCESS


Step 1: Project team determines high-level needs (or scope of work), from customer and marketing input

Step 2: Project team develops an initial project plan and estimates to determine what is feasible

Step 3: Project team meets with management, marketing, customers and related groups to determine whether: -  the change or solution is feasible -  there is agreement to the resource, cost and schedule estimates -  the risk is acceptable

Step 4: A commitment is made OR further negotiation is held

Example Process for Managing Commitments (PP SP 3.2)



2010-11-01

PG V1

Project Problems

1)  People are not showing up at peer review meetings

2)  Actual costs continually exceed planned costs

3)  People are delinquent on their action items

4)  Management does not know PASS status

5)  People are not meeting schedules

Project Monitoring and Control Case Study Example

PMC SPs

a)  SP 1.1 Monitor Project Planning Parameters

b)  SP 1.2 Monitor Commitments

c)  SP 1.5 Monitor Stakeholder Involvement

d)  SP 1.6 Conduct Progress Reviews

e)  SP 2.3 Manage Corrective Action

Match PASS problems with PMC SPs



2010-09-24

PG V1

Topics


- Project Planning (PP)

- Project Monitoring and Control (PMC)

- Risk Management (RSKM)

- Supplier Agreement Management (SAM)




2010-09-24

PG V1


Purpose Identify potential problems before they occur so that risk handling activities can be planned and invoked as needed across the life of the product or project to mitigate adverse impacts on achieving objectives.

Risks



2010-09-24

PG V1

When Risk Management Is Not Done Well…

It is easy to ignore risks when they are not being tracked. Risks that are known to project staff are often not known to management. Repeated project failures due to unforeseen (but predictable) risks can cost you business.



2010-09-24

PG V1

Risk Management Goals

Risks are identified and analyzed to determine their relative importance.

Prepare for Risk Management Preparation for risk management is conducted. SG 1

Identify and Analyze Risks SG 2


Risks are handled and mitigated as appropriate to reduce adverse impacts on achieving objectives.

Mitigate Risks SG 3



2010-11-01

PG V1

Risk Management Specific Practices

Prepare for Risk Management SP 1.1 Determine Risk Sources and Categories SP 1.2 Define Risk Parameters SP 1.3 Establish a Risk Management Strategy

SG 1

Identify and Analyze Risks SP 2.1 Identify Risks SP 2.2 Evaluate, Categorize, and Prioritize Risks

SG 2

Mitigate Risks SP 3.1 Develop Risk Mitigation Plans SP 3.2 Implement Risk Mitigation Plans

SG 3



2010-11-01

PG V1

Plans

Establish a Risk

Management Strategy

SP 1.3

Define Risk Parameters

SP 1.2 Determine

Risk Sources and

Categories

SP 1.1

Develop Risk Mitigation

Plans

SP 3.1 Evaluate,

Categorize, and Prioritize

Risks

SP 2.2

Identify Risks

SP 2.1 Implement

Risk Mitigation

Plans

SP 3.2

Risk Repository

Risk Management Sampling of Work Products



2010-11-01

PG V1

Establish a Risk

Management Strategy

SP 1.3

Evaluate, Categorize,

and Prioritize Risks

SP 2.2

Identify Risks

SP 2.1

Define Risk Parameters

SP 1.2 Determine

Risk Sources and

Categories

SP 1.1

Implement Risk

Mitigation Plans

SP 3.2

Develop Risk Mitigation

Plans

SP 3.1


PP SP 2.2


PMC SP 1.3

Risk Management Sampling of PA Relationships



2010-11-01

PG V1

Risk Management Case Study Example Focus Areas

Prepare for Risk Management SP 1.1 Determine Risk Sources and Categories SP 1.2 Define Risk Parameters SP 1.3 Establish a Risk Management Strategy

SG 1

Focus Areas



2010-11-01

PG V1

Risk Management Case Study Example

1)  PASS identified risks associated with their suppliers

2)  Risks were binned by likelihood of occurrence and impact

3)  PASS identified risks associated with innovative technology

4)  Impact can be high, medium, or low

5)  At the risk management meeting, the status of some risks were changed to retired, mitigated, or closed

a)  Risk source

b)  Risk category

c)  Risk parameter

Match the first column with the second column.



2010-09-24

PG V1

Topics









2010-09-24

PG V1


A Project Management Process Area at Maturity Level 2 Purpose The purpose of Supplier Agreement Management (SAM) is to manage the acquisition of products and services from suppliers.

P A S S



2010-09-24

PG V1


Supplier (1)  An entity delivering products or performing services being

acquired. (2)  An individual, partnership, company, corporation, association,

or other entity having an agreement with an acquirer for the design, development, manufacture, maintenance, modification, or supply of items under the terms of an agreement.

Supplier agreement A documented agreement between the acquirer and supplier. Supplier agreements are also known as contracts, licenses, and memoranda of agreement.



2010-09-24

PG V1

When Supplier Agreement Management Is Not Done Well…

Supplier selection is not based on the right criteria. The management and technical staff do not have insight into supplier activities. Supplier products are accepted even when they do not meet the product requirements. Integration of supplier products into a product baseline is problematic.


THE

GROUPPROCESS


SAM Applicability •  The scope of this process area addresses the acquisition of products,

services, and product and service components that can be delivered to the project's customer or included in a product or service system. This process area's practices can also be used for other purposes that benefit the project (e.g., purchasing consumables).

•  This process area does not apply in all contexts in which commercial off- the-shelf (COTS) components are acquired but does apply in cases where there are modifications to COTS components, government off-the-shelf components, or freeware, that are of significant value to the project or that represent significant project risk.

•  Throughout the process areas, where the terms “product” and “product component” are used, their intended meanings also encompass services, service systems, and their components.

Reference - CMMI 1.3 PDF: page 363



2010-09-24

PG V1

Supplier Agreement Management Goals

Agreements with suppliers are satisfied by both the project and the supplier.

Establish Supplier Agreements Agreements with the suppliers are established and maintained.

SG 1

Satisfy Supplier Agreements SG 2




2010-11-01

PG V1

SP 2.1 Execute the Supplier Agreement SP 2.2 Accept the Acquired Product SP 2.3 Ensure Transition of Products

Establish Supplier Agreements SP 1.1 Determine Acquisition Type SP 1.2 Select Suppliers SP 1.3 Establish Supplier Agreements

SG 1

Satisfy Supplier Agreements

SG 2

Supplier Agreement Management Specific Practices



2010-11-01

PG V1

Supplier Requirements

Supplier Agreement

Establish Supplier

Agreements

SP 1.3

Select Suppliers

SP 1.2

Determine Acquisition

Type

SP 1.1

Execute the Supplier

Agreement

SP 2.1

Accept the Acquired Product

SP 2.2

Ensure Transition of

Products

SP 2.3

Product

Supplier Agreement Management Sampling of Work Products



2010-11-01

PG V1

Execute the Supplier

Agreement

SP 2.1

Establish Supplier

Agreements

SP 1.3

Determine Acquisition

Type

SP 1.1

Select Suppliers

SP 1.2

Ensure Transition of

Products

SP 2.3

Accept the Acquired Product

SP 2.2

Perform Make, Buy, or

Reuse Analyses

TS SP 2.4

Assemble Product

Components

PI SP 3.2

Supplier Agreement Management Sampling of PA Relationships



2010-11-01

PG V1

Sample Activities 1)  PASS wrote a contract with

DetectEx 2)  Supplier motion sensors were

provided to integration and test 3)  PASS trade study selected

DetectEx for motion sensors 4)  The motion sensors passed

acceptance criteria 5)  Keypad uses COTS, sensors use

suppliers, controller re-uses PASS in-house software

Supplier Agreement Management Case Study Example

SAM SPs a)  SP 1.1 Determine Acquisition

Type b)  SP 1.2 Select Suppliers c)  SP 1.3 Establish Supplier

Agreements d)  SP 2.2 Accept the Acquired

Product e)  SP 2.3 Ensure Transition of

Products

PASS uses a supplier for motion sensors. Match PASS sample activities to SAM SPs.

Copyright © 2003 by Karl E. Wiegers. Modifications & additions Copyright © 2004 The Process Group. www.processgroup.com PGV1 237

THE

GROUPPROCESS

1. Define Product Requirements

2. Prepare Statement of Work

3. Define Proposal Evaluation Criteria

9. Manage Subcontracted

Project

5. Submit RFP to Suppliers

12. Close Out Project

4. Prepare Request for Proposal

11. Support and Maintain Product

8. Execute Contract

6. Select Supplier

10. Accept Product

7. Develop Subcontract

Management Plan

Example SAM Process (SAM GP 2.2, GP 3.1)

Copyright © 2003 by Karl E. Wiegers. Modifications & additions Copyright © 2004 The Process Group. www.processgroup.com PGV1 238

THE

GROUPPROCESS Example Supplier Selection Criteria

(SAM SP 1.2) Category Weight

Relative Weight Category Supplier A Supplier B Supplier C

40 Technical Requirements30 Development processes 5 6 720 Quality and CM processes 4 8 950 Specific product requirements 5 6 8100 Subtotal 4.8 6.4 7.9

20 Management Requirements30 Previous customer satisfaction 5 8 740 Project management capabilities 5 7 930 Staffing and skills 4 6 8100 Subtotal 4.7 7 8.1

20 Qualifications25 Application domain experience 4 10 450 Technology experience 8 10 525 CMMI maturity level 5 0 10100 Subtotal 6.25 7.5 6

20 Price and Schedule30 Development cost 5 10 310 Maintenance and support costs 4 5 560 Delivery schedule 5 8 4100 Subtotal 4.9 8.3 3.8

100 Overall Score 51 71 67



2010-09-24

PG V1

Topics









2010-09-24

PG V1


PP: Project Planning Aids project managers in planning project activities.

PMC: Project Monitoring and Control Emphasizes managing project performance according to the plan.

RSKM: Risk Management Enables projects to proactively identify and reduce risks that may jeopardize achieving project objectives.

SAM: Supplier Agreement Management Helps when working with suppliers.

Module 6

PP PMC

RSKM SAM






PG V1


Module 7: Project and Organizational Support



2010-11-01

PG V1


Module 10

OPP QPM CAR OPM



High Maturity

Module 9

OPF OPD IPM OT


the Work


Module 6

PP PMC

RSKM SAM



Module 5

RD REQM




Product Development

Module 8

TS PI

VER VAL

Module 7

CM PPQA

MA DAR






2010-11-01

PG V1

Project and Organizational Support Involves

•  Establishing and maintaining the integrity of work products

•  Providing objective visibility into, and feedback on, processes and associated work products throughout the life of the project to support delivering high-quality products and services

•  Establishing a measurement system to address the many information needs of projects and the organization

•  Determining which decisions should use a formal evaluation process and then applying formal evaluation processes to make good decisions



2010-09-24

PG V1

Topics

Project and Org Support Process Areas

- Configuration Management (CM)

- Process and Product Quality Assurance (PPQA)

- Measurement and Analysis (MA)

- Decision Analysis and Resolution (DAR)

Project and Org Support Summary

Exercise 3: Measurement Implications of Your Process Improvement Goals



2010-09-24

PG V1

Configuration Management (CM)

Purpose Establish and maintain the integrity of work products using configuration identification, configuration control, configuration status accounting, and configuration audits.



2010-09-24

PG V1


Baseline •  A set of specifications or work products that has been formally

reviewed and agreed on, which thereafter serves as the basis for further development, and which can be changed only through change control procedures.



2010-09-24

PG V1

When Configuration Management Is Not Done Well…

A product baseline cannot be produced when needed. Rework is performed during testing because components are not what were expected. A complete inventory of system components is unavailable when needed. A previous baseline cannot be rebuilt, and this wastes money and resources during maintenance.



2010-11-01

PG V1

Configuration Management Goals

Changes to the work products under configuration management are tracked and controlled.

Establish Baselines Baselines of identified work products are established.

SG 1

Track and Control Changes SG 2


Integrity of baselines is established and maintained.

Establish Integrity SG 3



2010-11-01

PG V1

Configuration Management Specific Practices

Establish Integrity SP 3.1 Establish Configuration Management Records SP 3.2 Perform Configuration Audits

SG 3

Track and Control Changes SP 2.1 Track Change Requests SP 2.2 Control Configuration Items

SG 2

Establish Baselines SP 1.1 Identify Configuration Items SP 1.2 Establish a Configuration Management System SP 1.3 Create or Release Baselines

SG 1



2010-11-01

PG V1

Change Request Database

Configuration Management

System

Create or Release

Baselines

SP 1.3 Establish a


System

SP 1.2

Identify Configuration

Items

SP 1.1

Establish Configuration Management

Records

SP 3.1

Control Configuration

Items

SP 2.2

Track Change

Requests

SP 2.1

Perform Configuration

Audits

SP 3.2

Reports and Records Audit Results

Configuration Management Sampling of Work Products



2010-11-01

PG V1

Create or Release

Baselines

SP 1.3

Control Configuration

Items

SP 2.2

Track Change

Requests

SP 2.1

Establish a Configuration Management

System

SP 1.2

Identify Configuration

Items

SP 1.1

Perform Configuration

Audits

SP 3.2 Establish


Records

SP 3.1

Configuration Management Sampling of PA Relationships

All Process Areas

Control Work Products

All PAs



2010-11-01

PG V1

Configuration Management Case Study Example

1. SP 1.1 Identify Configuration Items 2. SP 1.2 Establish a Configuration Management System 3. SP 1.3 Create or Release Baselines 4. SP 2.1 Track Change Requests 5. SP 2.2 Control Configuration Items 6. SP 3.1 Establish Configuration Management Records 7. SP 3.2 Perform Configuration Audits

PASS delivered updated software to SaveAll. SaveAll wanted to know what changed, but PASS wasn't sure because Change Request records were incomplete.

Which CM SPs could have prevented the problem?


THE

GROUPPROCESS


Example Change Control Process (Partial CM GP 2.2)

Submitted

Evaluated Rejected

Approved

Change Made

Verified

Closed

Verifier hasconfirmed thechange

Modifier hasinstalled product

verificationfailed

Modifier has madethe change andrequested verification

no verificationrequired; Modifierhas installedproduct

CCB decided to makethe change, allocatedit to a release, andassigned a Modifier

CCB decidednot to makethe change

Evaluator performedimpact analysis

Originator submitteda change request

Canceled

change was canceled

change was canceled

change wascanceled

See change_control_process.doc at:

http://www.processgroup.com/downloads.html



2010-09-24

PG V1

Topics










2010-09-24

PG V1

Process and Product Quality Assurance (PPQA)

Purpose Provide staff and management with objective insight into processes and associated work products.

QA Engineer



2010-09-24

PG V1


Quality Assurance •  A planned and systematic means for assuring management

that defined standards, practices, procedures, and methods of the process are applied.

Objectively Evaluate •  To review activities and work products against criteria that

minimize subjectivity and bias by the reviewer.

•  An example of an objective evaluation is an audit against requirements, standards, or procedures by an independent quality assurance function.



2010-09-24

PG V1

When Process and Product Quality Assurance Is Not Done Well…

No assurance is available that quality standards and processes are followed or achieved. Poor quality work products may be produced. There may be processes that staff avoid. Significant project issues are not escalated for management attention.



2010-11-01

PG V1

Process and Product Quality Assurance Goals

Noncompliance issues are objectively tracked and communicated, and resolution is ensured.

Objectively Evaluate Processes and Work Products Adherence of the performed process and associated work products to applicable process descriptions, standards, and procedures is objectively evaluated.

SG 1

Provide Objective Insight SG 2




2010-11-01

PG V1

Process and Product Quality Assurance Specific Practices

Objectively Evaluate Processes and Work Products SP 1.1 Objectively Evaluate Processes SP 1.2 Objectively Evaluate Work Products

SG 1

Provide Objective Insight SP 2.1 Communicate and Resolve Noncompliance Issues SP 2.2 Establish Records

SG 2



2010-11-01

PG V1

Reports and Records

Objectively Evaluate Work Products and

Services

SP 1.2

Objectively Evaluate

Processes

SP 1.1

Establish Records

SP 2.2 Communicate and Resolve

Noncompliance Issues

SP 2.1

Relevant Stakeholders

Process and Product Quality Assurance Sampling of Work Products



2010-11-01

PG V1

Establish Records

SP 2.2 Communicate and Resolve

Noncompliance Issues

SP 2.1

Objectively Evaluate Work

Products

SP 1.2

Objectively Evaluate

Processes

SP 1.1

Process and Product Quality Assurance Sampling of PA Relationships

All Process Areas

Evaluate Adherence

All PAs



2010-11-01

PG V1

Process and Product Quality Assurance Case Study Example Focus Area

Objectively Evaluate Processes and Work Products SP 1.1 Objectively Evaluate Processes SP 1.2 Objectively Evaluate Work Products

SG 1

Focus Area



2010-11-01

PG V1

Process and Product Quality Assurance Case Study Example

Which are process evaluations? Which are product evaluations?

1. QA attends a peer review and mentions there should be an attendance sheet

2. QA watches the engineers assemble a security system and notices a component was put in the wrong place

3. QA reviews the requirements and notices a missing requirement

4. QA reviews the design and notices some engineering drawings are missing

5. QA notices test group does not always fill out problem reports



2010-09-24

PG V1

Topics










2010-09-24

PG V1

A Support Process Area at Maturity Level 2

Measurement and Analysis (MA)

Purpose Develop and sustain a measurement capability used to support management information needs.

Hardware

Software

System



2010-09-24

PG V1


Base Measure •  Measure defined in terms of an attribute and the method for

quantifying it.

•  A base measure is functionally independent of other measures.

Derived Measures •  Measure that is defined as a function of two or more values of

base measures.



2010-09-24

PG V1

When Measurement and Analysis Is Not Done Well…

Measurements are used inappropriately. Inappropriate measures can cause unintended behavior. Management is based on perception rather than fact. Measurement presentations may confuse rather than enlighten. Useless measures are collected.



2010-11-01

PG V1

Measurement and Analysis Goals

Measurement results, which address identified information needs and objectives, are provided.

Align Measurement and Analysis Activities Measurement objectives and activities are aligned with identified information needs and objectives.

SG 1

Provide Measurement Results SG 2




2010-11-01

PG V1

Measurement & Analysis Specific Practices

SP 1.1 Establish Measurement Objectives SP 1.2 Specify Measures SP 1.3 Specify Data Collection and Storage Procedures SP 1.4 Specify Analysis Procedures

Align Measurement and Analysis Activities

SG 1

SP 2.1 Obtain Measurement Data SP 2.2 Analyze Measurement Data SP 2.3 Store Data and Results SP 2.4 Communicate Results

Provide Measurement Results

SG 2



2010-11-01

PG V1

Measurement Objectives

Measurement Results

Specify Data Collection and

Storage Procedures

SP 1.3

Specify Measures

SP 1.2

Establish Measurement

Objectives

SP 1.1

Specify Analysis

Procedures

SP 1.4

Store Data and Results

SP 2.3

Analyze Measurement

Data

SP 2.2

Obtain Measurement

Data

SP 2.1

Communicate Results

SP 2.4

Measurement Repository

Information Needs

Information Needs

Measurement & Analysis Sampling of Work Products



2010-11-01

PG V1

Obtain Measurement

Data

SP 2.1

Specify Analysis

Procedures

SP 1.4 Specify Data

Collection and Storage

Procedures

SP 1.3

Specify Measures

SP 1.2

Establish Measurement

Objectives

SP 1.1

Store Data and Results

SP 2.3

Analyze Measurement

Data

SP 2.2

Measurement & Analysis Sampling of PA Relationships

Select Measures and

Analytic Techniques

QPM SP 1.4

Communicate Results

SP 2.4


THE

GROUPPROCESS


Example Metrics - 1 Goal Questions Metrics

Meet all our cost and schedulecommitments.

Are we spending the plannednumber of hours on the projectto complete it?Are we hitting our milestones?

Planned versus actual effort foreach project.The number of days eachmilestone is early or late.

Deliver product X bymm/dd/yy.

Are we spending the plannednumber of hours on the projectto complete it?Are we hitting our milestones?

Planned versus actual effort foreach project milestone.The number of days eachmilestone is early or late.

How much time do we spendon rework now?How does this compare withour development time and arewe improving?

Percentage of project timespent on rework.

Reduce rework to less than 20percent of total project effort.

How many defects do we havein the product during designand coding?

Defect density: Number ofdefects found per unit size ofwork product (e.g., number ofpages of design, number oflines of code).

Improve the performance ofour core software product.(Target to be defined.)

What is our currentperformance?

Average screen response timeduring peak system usage.

Achieve customer rating of9/10 on product evaluationform.

How satisfied are they now?Are we improving?

Annual customer satisfactionsurvey.

Keep profits at 15 percent (andcosts at the same as last year).

What is our profit?Is it getting better or worse?

Annual net profit.


THE

GROUPPROCESS


Example Metrics - 2 Goal Questions Metrics

Achieve customer rating of9/10 on product evaluationform.

How satisfied are they now?Are we improving?

Annual customer satisfactionsurvey.

Keep profits at 15 percent (andcosts at the same as last year).

What is our profit?Is it getting better or worse?

Annual net profit.

Data Storage & Collection Analysis Reporting Collected weekly.

Stored in: metrics-mm-dd-yyyy.html.

Look for 10% additional effort expended over 2 weeks or more than 5 days late.

Reported weekly at staff meeting.



2010-11-01

PG V1

Measurement & Analysis Case Study Example Focus Area

SP 2.1 Obtain Measurement Data SP 2.2 Analyze Measurement Data SP 2.3 Store Data and Results SP 2.4 Communicate Results

Provide Measurement Results SG 2

Focus Area



2010-11-01

PG V1

Measurement and Analysis Case Study Example

Which graphs show measurement data are analyzed?

Plan

Actual

Jan Feb

Cos

t in

$K

80

70

60

50

40

30

Plan

Actual

Jan Feb

Cos

t in

$K

80

70

60

50

40

30

Plan

Actual

Jan Feb

Cos

t in

$K

80

70

60

50

40

30

Plan

Actual

Jan Feb

Cos

t in

$K

80

70

60

50

40

30

Actual is increasing

Actuals exceeding threshold

Risk realized, started

contingency plans

1 2

3 4



2010-09-24

PG V1

Topics










2010-09-24

PG V1

Decision Analysis and Resolution (DAR)

Purpose Analyze possible decisions using a formal evaluation process that evaluates identified alternatives against established criteria.



2010-11-01

PG V1

Decision Analysis and Resolution Applicability

•  Documented guidelines should be provided when formal evaluation processes are to be used.

•  Guidelines often suggest using formal evaluation processes when issues are associated with medium to high risks or when issues affect the ability to achieve project objectives.



2010-09-24

PG V1

When Decision Analysis and Resolution Is Not Done Well…

It is unclear who is authorized to make what decisions. Decisions are made subjectively. Rationale is unavailable when needed to understand an earlier decision. Too few choices are considered for major decisions. Missing a more optimal solution costs time, money, credibility, and perhaps even the whole project.



2010-11-01

PG V1

Decision Analysis and Resolution Goals

Evaluate Alternatives Decisions are based on an evaluation of alternatives using established criteria.

SG 1




2010-11-01

PG V1

Decision Analysis and Resolution Specific Practices

SP 1.1 Establish Guidelines for Decision Analysis SP 1.2 Establish Evaluation Criteria SP 1.3 Identify Alternative Solutions SP 1.4 Select Evaluation Methods SP 1.5 Evaluate Alternative Solutions SP 1.6 Select Solutions

Evaluate Alternatives

SG 1



2010-11-01

PG V1

Guidelines Criteria

Identify Alternative Solutions

SP 1.3

Establish Evaluation

Criteria

SP 1.2 Establish

Guidelines for Decision Analysis

SP 1.1

Select Solutions

SP 1.6

Evaluate Alternative Solutions

SP 1.5

Select Evaluation Methods

SP 1.4

Proposed Alternatives Methods

Decision Analysis and Resolution Sampling of Work Products



2010-11-01

PG V1

Select Solutions

SP 1.6

Evaluate Alternative Solutions

SP 1.5

Select Evaluation Methods

SP 1.4

Identify Alternative Solutions

SP 1.3

Establish Evaluation

Criteria

SP 1.2 Establish

Guidelines for Decision Analysis

SP 1.1

Select Product

Component Solutions

TS SP 1.2

Select Suppliers

SAM SP 1.2


Reuse Analyses

TS SP 2.4

Select Outcomes for

Analysis

CAR SP 1.1

Decision Analysis and Resolution Sampling of PA Relationships



2010-11-01

PG V1

Decision Analysis and Resolution Case Study Example Focus Areas

SP 1.1 Establish Guidelines for Decision Analysis SP 1.2 Establish Evaluation Criteria SP 1.3 Identify Alternative Solutions SP 1.4 Select Evaluation Methods SP 1.5 Evaluate Alternative Solutions SP 1.6 Select Solutions

Evaluate Alternatives

SG 1

Focus Area

Focus Area



2010-11-01

PG V1

Decision Analysis and Resolution Case Study Example

Example decisions subject to

DAR

Example criteria for

when to apply DAR

Example evaluation methods

Use DAR for selecting make-buy-reuse, suppliers, architectural or design alternatives, and engineering tools. Use the following criteria to determine when to apply DAR. •  The cost of the decision is greater than $10,000 •  The schedule is affected by more than 1 month •  The decision can introduce significant risk to the project

Use one of the following evaluation methods: •  Trade Study – Compare similar alternatives against weighted evaluation criteria (e.g., cost, reliability, features, etc.) to objectively determine the best solution •  Consensus or Voting - Use consensus or voting to make the final decision. Only use this method if all relevant stakeholders are present. •  Survey or Interviews – Gather enough information from experts until a trend/pattern is observed to make the best decision.

Project plans should address SP 1.1 and SP 1.4



2010-09-24

PG V1

Topics










2010-11-01

PG V1

Project and Organizational Support Summary

CM: Configuration Management Emphasizes configuration management processes for selected work products. PPQA: Process and Product Quality Assurance Evaluates the quality of processes and work products. MA: Measurement and Analysis Addresses the information needs of the organization and projects with a measurement system. DAR: Decision Analysis and Resolution Supports making major decisions using a formal decision process.

Module 7

CM PPQA

MA DAR






2010-09-24

PG V1

Topics










2010-11-01

PG V1

Exercise 3

Task Follow the directions in the “Measurement Implications of Your Process Improvement Goals” exercise.

Expected Outcome Participants will gain insight into the connection of measurement concepts to process improvement goals.




PG V1


Module 8: Product Development 2



2010-11-01

PG V1


Module 10

OPP QPM CAR OPM



High Maturity

Module 9

OPF OPD IPM OT


the Work


Module 7

CM PPQA

MA DAR




Module 6

PP PMC

RSKM SAM



Module 5

RD REQM


the Work

Product Development




Product Development

Module 8

TS PI

VER VAL



2010-11-01

PG V1

Product Development 2 Involves

Designing the product and its components

Managing the interfaces among the components and between the product and other products

Building the components

Integrating the components to form the product

Ensuring the requirements are satisfied

Ensuring the product will perform as intended

Delivering the product



2010-09-24

PG V1

Topics


- Technical Solution (TS)

- Product Integration (PI)

- Verification (VER)

- Validation (VAL)


Exercise 4: Impact of an Engineering Change



2010-09-24

PG V1

Technical Solution (TS)

Purpose Select, design, and implement solutions to requirements. Solutions, designs, and implementations encompass products, product components, and product related lifecycle processes either singly or in combinations as appropriate.

Design Implementation



2010-09-24

PG V1


Product Related Lifecycle Processes •  Processes associated with a product or service throughout

one or more phases of its life (e.g., from conception through disposal), such as manufacturing and support processes.

Sustainment •  The processes used to ensure that a product or service

remains operational.



2010-09-24

PG V1

When Technical Solution Is Not Done Well…

An ineffective solution is chosen. Products may not meet technical performance requirements or user needs. Increased testing and rework is required to resolve design issues. The product may not be able to accommodate technology upgrades and future growth if the technical solution is not well conceived.



2010-11-01

PG V1

Technical Solution Goals

Product or product component designs are developed.

Select Product Component Solutions Product or product component solutions are selected from alternative solutions.

SG 1

Develop the Design SG 2


Product components, and associated support documentation, are implemented from their designs.

Implement the Product Design SG 3



2010-11-01

PG V1

Technical Solution Specific Practices

SP 2.1 Design the Product or Product Component SP 2.2 Establish a Technical Data Package SP 2.3 Design Interfaces Using Criteria SP 2.4 Perform Make, Buy, or Reuse Analyses

Select Product Component Solutions SP 1.1 Develop Alternative Solutions and Selection Criteria SP 1.2 Select Product Component Solutions

SG 1

Develop the Design

SG 2

Implement the Product Design SP 3.1 Implement the Design SP 3.2 Develop Product Support Documentation

SG 3



2010-11-01

PG V1

Designs Implemented Designs and

Documentation

Design the Product or

Product Component

SP 2.1

Select Product

Component Solutions

SP 1.2 Develop

Alternative Solutions and

Selection Criteria

SP 1.1

Establish a Technical

Data Package

SP 2.2

Implement the Design

SP 3.1


Reuse Analyses

SP 2.4

Design Interfaces

Using Criteria

SP 2.3 Develop Product Support

Documentation

SP 3.2

Technical Solution Sampling of Work Products



2010-11-01

PG V1

Design Interfaces

Using Criteria

SP 2.3

Establish a Technical

Data Package

SP 2.2

Design the Product or

Product Component

SP 2.1

Select Product

Component Solutions

SP 1.2

Develop Alternative

Solutions and Selection Criteria

SP 1.1

Develop Product Support

Documentation

SP 3.2

Implement the Design

SP 3.1


Reuse Analyses

SP 2.4

Select Solutions

DAR SP 1.6


Product Component

Requirements

RD SP 2.1

Select Suppliers

SAM SP 1.2

Identify Interface

Requirements

RD SP 2.3

Assemble Product

Components

PI SP 3.2

Technical Solution Sampling of PA Relationships



2010-11-01

PG V1

Technical Solution Case Study Example Focus Area

Select Product Component Solutions SP 1.1 Develop Alternative Solutions and Selection Criteria SP 1.2 Select Product Component Solutions

SG 1

Focus Area



2010-11-01

PG V1

Beeper Speaker

SW

Window Sensors

SW Controller SW

On/Off Button

SW Keypad

SW

Door Sensors

SW

Motion Sensors

SW Sirens

SW Display

SW

1 2 3 5 6

7 8 9 0 * #

4

Keypad

Door Sensors

Window Sensors

On Off

Beeper Speaker On/Off

Button

Door 1: Low Battery Window 2 : No Response

Display

Design Alternative 1 3 Types of Sensors

Sirens Motion Sensors



2010-11-01

PG V1

Beeper Speaker

SW Controller SW

On/Off Button

SW Keypad

SW

Sirens SW

Display SW

1 2 3 5 6

7 8 9 0 * #

4

Keypad

On Off

Beeper Speaker On/Off

Button

Door 1: Low Battery Window 2 : No Response

Display

Design Alternative 2 All Sensors in One Component

Sirens

Sensors SW

Sensors


THE

GROUPPROCESS




Technical Solution activities

•  GP 3.2 – Number of defects caused / found by / leaked from, the

design phase – Example design documents – Lessons learned



2010-09-24

PG V1

Topics










2010-09-24

PG V1

Product Integration (PI)

Purpose Assemble the product from the product components, ensure that the product, as integrated, behaves properly (i.e., possesses the required functionality and quality attributes), and deliver the product. Integrators



2010-09-24

PG V1

When Product Integration Is Not Done Well…

Subsystems do not operate together. There is increased integration test time. The integration environment is inadequate to support the integration activities. A product is released without all the component integration fully tested.



2010-11-01

PG V1

Product Integration Goals

The product component interfaces, both internal and external, are compatible.

Prepare for Product Integration Preparation for product integration is conducted. SG 1

Ensure Interface Compatibility SG 2


Verified product components are assembled and the integrated, verified, and validated product is delivered.

Assemble Product Components and Deliver the Product

SG 3



2010-11-01

PG V1

Product Integration Specific Practices -1

Prepare for Product Integration SP 1.1 Establish an Integration Strategy SP 1.2 Establish the Product Integration Environment SP 1.3 Establish Product Integration Procedures and Criteria

SG 1

Ensure Interface Compatibility SP 2.1 Review Interface Descriptions for Completeness SP 2.2 Manage Interfaces

SG 2



2010-11-01

PG V1

Product Integration Specific Practices -2

SP 3.1 Confirm Readiness of Product Components for Integration SP 3.2 Assemble Product Components SP 3.3 Evaluate Assembled Product Components SP 3.4 Package and Deliver the Product or Product Component


SG 3



2010-11-01

PG V1

Integration Strategy, Procedures, Criteria,

and Environment Assemblies

Establish the Product

Integration Environment

SP 1.2

Establish an Integration Strategy

SP 1.1 Review

Interface Descriptions

for Completeness

SP 2.1 Establish Product

Integration Procedures and Criteria

SP 1.3

Assemble Product

Components

SP 3.2 Confirm

Readiness of Product

Components for Integration

SP 3.1

Manage Interfaces

SP 2.2

Package and Deliver the Product or

Product Component

SP 3.4 Evaluate

Assembled Product

Components

SP 3.3

Product Integration Sampling of Work Products



2010-11-01

PG V1

Confirm Readiness of

Product Components for Integration

SP 3.1

Manage Interfaces

SP 2.2

Review Interface

Descriptions for

Completeness

SP 2.1 Establish Product

Integration Procedures and Criteria

SP 1.3

Establish an Integration Strategy

SP 1.1 Establish the

Product Integration

Environment

SP 1.2

Package and Deliver the Product or

Product Component

SP 3.4 Evaluate

Assembled Product

Components

SP 3.3

Assemble Product

Components

SP 3.2

Perform Verification

VER SP 3.1

Design Interfaces

Using Criteria

TS SP 2.3

Perform Validation

VAL SP 2.1

Product Integration Sampling of PA Relationships



2010-11-01

PG V1

Product Integration Case Study Example Focus Area

SP 3.1 Confirm Readiness of Product Components for Integration SP 3.2 Assemble Product Components SP 3.3 Evaluate Assembled Product Components SP 3.4 Package and Deliver the Product or Product Component


SG 3

Focus Area



2010-11-01

PG V1

•  Rejected door sensor software. No peer review proof.

•  Rejected keypad software. COTS not under CM control.

•  Rejected controller software. No proof of unit/component test.

•  Rejected siren hardware. No proof of QA assembly inspection.

Rejected Components from Engineering

Integrator confirms that components are ready for integration


THE

GROUPPROCESS




integration activities

•  GP 3.2 – Planned vs. actual effort, quality measure of

components entering integration (e.g., #defects, #missing parts, documentation complete Y/N)

– Example PI plans and procedures – Lessons learned, process changes



2010-09-24

PG V1

Topics










2010-09-24

PG V1

Verification (VER)

Purpose Ensure that selected work products meet their specified requirements.

Testers



2010-09-24

PG V1


Verification •  Confirmation that work products properly reflect the

requirements specified for them. •  In other words, verification ensures that “you built it right.”.

Validation •  Confirmation that the product or service, as provided (or as it

will be provided), will fulfill its intended use.

•  In other words, validation ensures that “you built the right thing.”.

•  Both are applicable throughout the product development

lifecycle.



2010-09-24

PG V1

When Verification Is Not Done Well…

There is disagreement among technical staff as to whether the different components meet the requirements. The product being tested does not meet design requirements. Product reliability suffers because defects are not detected or corrected prior to customer release. Added rework occurs because defects that could have been caught early escape into later lifecycle phases.



2010-11-01

PG V1

Verification Goals

Peer reviews are performed on selected work products.

Prepare for Verification Preparation for verification is conducted. SG 1

Perform Peer Reviews SG 2


Selected work products are verified against their specified requirements.

Verify Selected Work Products SG 3



2010-11-01

PG V1

Verification Specific Practices

Prepare for Verification SP 1.1 Select Work Products for Verification SP 1.2 Establish the Verification Environment SP 1.3 Establish Verification Procedures and Criteria

SG 1

Perform Peer Reviews SP 2.1 Prepare for Peer Reviews SP 2.2 Conduct Peer Reviews SP 2.3 Analyze Peer Review Data

SG 2

Verify Selected Work Products SP 3.1 Perform Verification SP 3.2 Analyze Verification Results

SG 3



2010-11-01

PG V1

Verification Plans

Verification Results

Establish Verification Procedures and Criteria

SP 1.3

Establish the Verification

Environment

SP 1.2

Select Work Products for Verification

SP 1.1

Analyze Verification

Results

SP 3.2

Analyze Peer Review

Data

SP 2.3

Conduct Peer Reviews

SP 2.2

Prepare for Peer Reviews

SP 2.1


SP 3.1

Verification Sampling of Work Products



2010-11-01

PG V1

Conduct Peer Reviews

SP 2.2

Prepare for Peer Reviews

SP 2.1

Establish Verification Procedures and Criteria

SP 1.3


Environment

SP 1.2

Select Work Products for Verification

SP 1.1

Analyze Peer Review

Data

SP 2.3

Analyze Verification

Results

SP 3.2


SP 3.1

Analyze Measurement

Data

MA SP 2.2

Verification Sampling of PA Relationships


THE

GROUPPROCESS


Example Peer Review Process (SP 1.3)

Planning!

High-level !Document!

Task Std.!Common !Errors!Checklist!

Exit !Criteria!!

Kickoff!Meeting!5-45 mins!

Preparation! 15-120 mins!

Defect !Logging!Meeting!<=2 hrs!

Causal !Analysis!Meeting!30-90 mins!

Rework!

Invitation to !Inspection!

Inspection !Statistics!Summary!

Defect Log!

Action Item !Log!

Final !Statistics !in Database!

Low-level !Document!

Follow-up!

Entry !Criteria!

Inputs!Outputs!

[Based on T. Gilb]

“Criteria”

Optional


THE

GROUPPROCESS


Example Peer Review Metrics (SP 2.3 + GP 2.8 / 3.2)

•  Defect Density –  Total Defects / Page (or K lines of code)

•  Defect Find Rate or Close Rate –  Total Defects / Effort-hour


THE

GROUPPROCESS


Example Defect Density (SP 2.3 + GP 2.8 / 3.2)

Code Inspection Defect Density

0.0

1.0

2.0

3.0

4.0

5.0

6.0

1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35 37

Module#

De

fec

ts/1

00

Ph

ys

ica

l L

OC

Defects/100 Physical LOC

Mean

•  Manufacturing control system

•  OO/C++ •  167KLOC •  13 defects/KLOC

in code •  1.38 defects/

KLOC in test


THE

GROUPPROCESS



•  GP 2.1 Policy – Conditions when VER is performed (e.g., 100%, critical,

changed, high-risk components/files/code)

•  GP 2.2 Plan – Specific milestones, time and resources for performing

all verification activities



2010-11-01

PG V1

Verification Case Study Example Focus Area

Prepare for Verification SP 1.1 Select Work Products for Verification SP 1.2 Establish the Verification Environment SP 1.3 Establish Verification Procedures and Criteria

SG 1 Focus Area



2010-11-01

PG V1

Verification Case Study Example

Which of the following are adequate for verification procedures and criteria?

1. Peer review criteria that says, “Ensure products are complete, consistent, and correct.”

2. Checklists for peer reviews.

3. A test procedure that lists test steps and how to judge whether each test step passed or failed

4. A procedure on how to do the verification process.

5. A procedure on how to do peer reviews.



2010-09-24

PG V1

Topics










2010-09-24

PG V1

Validation (VAL)

Purpose Demonstrate that a product or product component fulfills its intended use when placed in its intended environment.

Breaking into an Actual Home



2010-09-24

PG V1

There are arguments among the technical staff as to what the user really wants. The released product does not meet user expectations. Customers do not pay for products that do not meet their needs. End users refuse to use the product as delivered.

When Validation Is Not Done Well…



2010-11-01

PG V1

Validation Goals

The product or product components are validated to ensure they are suitable for use in their intended operating environment.

Prepare for Validation Preparation for validation is conducted. SG 1

Validate Product or Product Components

SG 2




2010-11-01

PG V1

Validation Specific Practices

Prepare for Validation SP 1.1 Select Products for Validation SP 1.2 Establish the Validation Environment SP 1.3 Establish Validation Procedures and Criteria

SG 1

Validate Product or Product Components SP 2.1 Perform Validation SP 2.2 Analyze Validation Results

SG 2



2010-11-01

PG V1

Validation Plans

Validation Results

Establish the Validation

Environment

SP 1.2

Select Products for Validation

SP 1.1 Establish Validation

Procedures and Criteria

SP 1.3

Analyze Validation Results

SP 2.2

Perform Validation

SP 2.1

Validation Sampling of Work Products



2010-11-01

PG V1

Establish Validation

Procedures and Criteria

SP 1.3

Analyze Validation Results

SP 2.2

Perform Validation

SP 2.1


Environment

SP 1.2

Select Products for Validation

SP 1.1


RD SP 3.5

Validation Sampling of PA Relationships


THE

GROUPPROCESS


Example VAL Analysis (SP 2.2) Goal

SSAT: •  < 0.5 defects /

KSLOC

•  No CAT 1 / CAT 2 / CAT 3 defects

Final Test (FLAT): •  0 defects

Published with permission of client



2010-11-01

PG V1

Validation Case Study Example

Which are verification vs. validation?

1. PASS conducts a formal design review with SaveAll

2. PASS has a peer review with the systems engineers, software engineers, and QA

3. PASS demonstrates a prototype to SaveAll to get their feedback

4. PASS formally tests the product prior to delivery with SaveAll and QA witnesses the test

5. PASS integrates the components and tests the system



2010-09-24

PG V1

Topics










2010-11-01

PG V1


TS: Technical Solution Focuses on designing and building the solutions.

PI: Product Integration Addresses integrating the solutions and delivering the products.

VER: Verification Emphasizes ensuring the solutions satisfy the requirements.

VAL: Validation Emphasizes ensuring the solutions satisfy the need.


the Work

Product Development




Product Development

Module 8

TS PI

VER VAL



2010-09-24

PG V1

Topics










2010-11-01

PG V1

Exercise 4

Task Follow the directions in the “Impact of an Engineering Change” exercise.

Expected Outcome Participants will be able to articulate plausible connections between the scenario and the CMMI model.




PG V1


Module 9: Improvement Infrastructure



2010-11-01

PG V1


Module 10

OPP QPM CAR OPM

Adding High Maturity to the Work

High Maturity Module 7

CM PPQA

MA DAR




Module 6

PP PMC

RSKM SAM



Module 5

RD REQM




Product Development

Module 8

TS PI

VER VAL

Module 9

OPF OPD IPM OT


the Work




2010-11-01

PG V1

Improvement Infrastructure Involves

Establishing the infrastructure for continuous process improvement Establishing organizational assets and guidelines for using the assets

Establishing ways for projects to take advantage of the advances of others

Training people to help them perform



2010-09-24

PG V1


Managed Process •  A performed process that is planned and executed in

accordance with policy; employs skilled people having adequate resources to produce controlled outputs; involves relevant stakeholders; is monitored, controlled, and reviewed; and is evaluated for adherence to its process description.

Defined Process •  A managed process that is tailored from the organization's set

of standard processes according to the organization's tailoring guidelines: •  has a maintained process description •  contributes process related experiences to the

organizational process assets



2010-11-01

PG V1

The Improvement Infrastructure

Organization's Measurement

Repository

Organization's Set of Standard

Processes

Training of People

Tailoring Guidelines

Organization's Process Asset

Library

The Organization

A Project

Project's Defined Process

Project Plans

Process Improvement



2010-09-24

PG V1

Topics

Improvement Infrastructure Process Areas

- Organizational Process Focus (OPF)

- Organizational Process Definition (OPD)

Exercise 5: Process Asset Library “Match Game”

-  Integrated Project Management (IPM)

- Organizational Training (OT)

Improvement Infrastructure Summary

Exercise 6: Scenario Evaluation



2010-09-24

PG V1

A Process Management Process Area at Maturity Level 3

Organizational Process Focus (OPF)

Purpose Plan, implement, and deploy organizational process improvements based on a thorough understanding of current strengths and weaknesses of the organization's processes and process assets.

Improvements Standard Process



2010-09-24

PG V1


Organizational Process Assets •  Artifacts that relate to describing, implementing, and improving

processes. •  Examples of these artifacts include policies, measurement

descriptions, process descriptions, process implementation support tools.

•  The term “process assets” is used to indicate that these artifacts are developed or acquired to meet the business objectives of the organization and that they represent investments by the organization that are expected to provide current and future business value.

Project Startup •  When a set of interrelated resources for a project are directed

to develop or deliver one or more products or services for a customer or end user.



2010-09-24

PG V1

When Organizational Process Focus Is Not Done Well…

There is high staff turnover in the engineering process group. There is little visible senior management support for process improvement. Improvement activities are not aligned with business priorities. Improvement efforts often result in false starts and difficult implementations.



2010-11-01

PG V1

Organizational Process Focus Goals

Process actions that address improvements to the organization's processes and process assets are planned and implemented.

Determine Process Improvement Opportunities Strengths, weaknesses, and improvement opportunities for the organization's processes are identified periodically and as needed.

SG 1

Plan and Implement Process Actions SG 2


Organizational process assets are deployed across the organization and process-related experiences are incorporated into organizational process assets.

SG 3 Deploy Organizational Process Assets and Incorporate Experiences



2010-11-01

PG V1

Determine Process Improvement Opportunities SP 1.1 Establish Organizational Process Needs SP 1.2 Appraise the Organization's Processes SP 1.3 Identify the Organization's Process Improvements

SG 1

Plan and Implement Process Actions SP 2.1 Establish Process Action Plans SP 2.2 Implement Process Action Plans

SG 2

Organizational Process Focus Specific Practices -1



2010-11-01

PG V1

SP 3.1 Deploy Organizational Process Assets SP 3.2 Deploy Standard Processes SP 3.3 Monitor the Implementation SP 3.4 Incorporate Experiences into Organizational Process Assets

Deploy Organizational Process Assets and Incorporate Experiences

SG 3

Organizational Process Focus Specific Practices -2



2010-11-01

PG V1

Organizational Process Assets Improvements

Appraise the Organization's

Processes

SP 1.2 Establish

Organizational Process Needs

SP 1.1

Establish Process

Action Plans

SP 2.1 Identify the

Organization's Process

Improvements

SP 1.3

Monitor the Implementation

SP 3.3

Deploy Standard

Processes

SP 3.2 Deploy

Organizational Process Assets

SP 3.1

Implement Process

Action Plans

SP 2.2

Incorporate Experiences into Organizational Process Assets

SP 3.4

Organizational Process Focus Sampling of Work Products



2010-11-01

PG V1

Deploy Organizational

Process Assets

SP 3.1

Implement Process

Action Plans

SP 2.2

Establish Process

Action Plans

SP 2.1

Identify the Organization's

Process Improvements

SP 1.3

Appraise the Organization's

Processes

SP 1.2 Establish

Organizational Process Needs

SP 1.1

Incorporate Experiences into Organizational Process Assets

SP 3.4


SP 3.3

Deploy Standard

Processes

SP 3.2

Establish Standard

Processes

OPD SP 1.1

Organizational Process Focus Sampling of PA Relationships

Contribute to Organizational

Process Assets

IPM SP 1.7

Organizational Performance Management

OPM All SPs


THE

GROUPPROCESS


Trend diagram tracking goal and intermediate goal completion!

2 4 6 8 10 12 14 16

Planned

Actual

Month

12

10

8

6

4

2

Total numberof goals andintermediategoalscompleted inaction plan

Today

Eleven goals and intermediate goals to complete

Originaldeadline

18 20 22 24

Newdeadline

Monitoring Progress - 1 (GP 2.8, GP3.2)


THE

GROUPPROCESS


Monitoring Progress - 2 (GP 2.8, GP 3.2)

JanYr 1

SeptYr 1

JanYr 2

MayYr 2

25%

50%

75%

100%

%Totalcriteriaadopted.

Time

Improvement Goal

Organization A

MayYr 1

SeptYr 2

JanYr 3

MayYr 3

Process adoption over time!


THE

GROUPPROCESS


Institutionalize a Defined Process for OPF (GP 3.1)

•  1. Developing a Plan –  Scope the Improvement – Develop an Action Plan – Determine Risks and Plan to Mitigate

•  2. Implementing the Plan –  Sell Solutions Based on Needs – Work with the Willing and Needy First –  Keep Focused on the Goals and Problems –  Align the Behaviors of Managers and Practitioners

•  3. Checking Progress –  Are We Making Progress on the Goals? –  Are We Making Progress on Our Improvement Plan? –  Are We Making Progress on the Improvement Framework? – What Lessons Have We Learned So Far?


THE

GROUPPROCESS


The process-centric approach was very difficult to sell. Corrective Action (CA) = adopt the goal-problem approach.

Planning

Using the same communication technique as everyone else allows the message to be lost. CA = use bright pink 8.5 x 11-inch cards & pizza lunches.

Implementing

Allowing private data to become public sets perilous expectations. CA = brief management on new metrics policy.

Planning

Be careful of what information you ask for! [Process Assets Library] CA = stop measuring the % of projects that submit to the PAL. Clean out the PAL.

Planning

Using a scoring system for process adoption can encourage inappropriate behavior. CA = stop measuring #inspections/year. Re-look at all metrics that can be optimized but lead to little benefit.

Checking

Collect Improvement Information (GP 3.2)



2010-11-01

PG V1

SP 3.1 Deploy Organizational Process Assets SP 3.2 Deploy Standard Processes SP 3.3 Monitor the Implementation SP 3.4 Incorporate Experiences into Organizational Process Assets

Deploy Organizational Process Assets and Incorporate Experiences

SG 3

Organizational Process Focus Case Study Example Focus Area

Focus Area



2010-11-01

PG V1

Organizational Process Focus Case Study Example

1)  PASS Process Group (PG) has monthly meetings with projects to get feedback

2)  PASS PG notices a process step was poorly written and corrects it

3)  PASS PG looks at how projects are using the templates and updates the templates

4)  PASS PG analyzes appraisal metrics to determine which processes need to be improved

5)  PASS PG updates a process because of information found on the internet

Which show incorporating experiences?



2010-09-24

PG V1

Topics











2010-09-24

PG V1

A Process Management Process Area at Maturity Level 3

Organizational Process Definition (OPD)

Purpose Establish and maintain a usable set of organizational process assets, work environment standards, and rules and guidelines for teams.


Project A

Project B Project C



2010-09-24

PG V1


Standard Process •  An operational definition of the basic process that guides the

establishment of a common process in an organization •  A standard process describes the fundamental process

elements that are expected to be incorporated into any defined process. It also describes relationships (e.g., ordering, interfaces) among these process elements.

Process Architecture •  (1) The ordering, interfaces, interdependencies, and other

relationships among the process elements in a standard process, or (2) the interfaces, interdependencies, and other relationships between process elements and external processes



2010-09-24

PG V1

When Organizational Process Definition Is Not Done Well…

Staff members resist using the guidance in the standard processes. There are too many requests for process waivers. An extreme amount of tailoring is performed by projects. Project managers and staff do not use information collected from previous projects to improve their project.



2010-11-01

PG V1

Organizational Process Definition Goals

Establish Organizational Process Assets A set of organizational process assets is established and maintained.

SG 1




2010-11-01

PG V1

Organizational Process Definition Specific Practices -1

SP 1.1 Establish Standard Processes SP 1.2 Establish Lifecycle Model Descriptions SP 1.3 Establish Tailoring Criteria and Guidelines SP 1.4 Establish the Organization's Measurement Repository SP 1.5 Establish the Organization's Process Asset Library SP 1.6 Establish Work Environment Standards SP 1.7 Establish Rules and Guidelines for Teams

Establish Organizational Process Assets

SG 1



2010-11-01

PG V1

Repositories Organizational

Process Assets

Establish Tailoring

Criteria and Guidelines

SP 1.3 Establish Lifecycle

Model Descriptions

SP 1.2

Establish Standard

Processes

SP 1.1

Establish Work

Environment Standards

SP 1.6

Establish the Organization's Process Asset

Library



Repository

SP 1.4

Establish Rules and

Guidelines for Teams

SP 1.7

Organizational Process Definition Sampling of Work Products



2010-11-01

PG V1

Establish Work

Environment Standards

SP 1.6


Library



Repository

SP 1.4

Establish Tailoring


SP 1.3 Establish Lifecycle

Model Descriptions

SP 1.2

Establish Standard

Processes

SP 1.1 Use


for Planning Project Activities

IPM SP 1.2

Deploy Standard

Processes

OPF SP 3.2

Establish the Project's Work Environment

IPM SP 1.3

Establish the Project's Defined Process

IPM SP 1.1

Establish Rules and


SP 1.7

Organizational Process Definition Sampling of PA Relationships


THE

GROUPPROCESS


Process for Creating a Process (SP 1.1 + GP 2.2 + Simple GP 3.1)

•  Establish need (problem to solve) and pilot project – E.g., Requirements are incomplete and vague on project X

•  Define desired outcome when process is used – E.g., Requirements are clear, complete and testable

•  Write draft process using standard format (version “draft”)

•  Inspect process •  Baseline process (version xx.yy) •  Pilot process •  Revise process (baseline #2) •  Obtain approval for promotion into Process Assets

Library


THE

GROUPPROCESS


Example Life Cycle Choice - 1 (SP 1.2)

Requirements

Requirements Design Build Test Integrate? Release?

Architecture Build 1 Build 2 Build 3

Requirements changes are processed here (ò)

Requirements Design Build Test Integrate Release?

Requirements Design Build Test Integrate Release

Prototype Planning

Prototype high-risk areas

Iron out the problems with the life cycle on Build 1

ò ò ò ò ò ò


THE

GROUPPROCESS


Example Life Cycle Choice - 2 (SP 1.2)

System Tested

Programs

Deliverables TimelineFunctional Development ProjectsFunctional Development Projects

Initiation Analysis Technical Design Construction Implementation

InstalledPrograms

Conversion

$$$Final Cost

User Acceptance Test Plan

Technical DocumentationEducation

Implementation Plan

System Technical

Design Program Specs Unit Test Plans

Environmental Test Plan System Test Plan Integration Test Plan

Post Implementation Plan

$$$ Final Estimate

ProjectRequest

FunctionalSpecs

$$$

$$$

ConceptualSpecs$$$

Initial Analysis & Estimate

BusinessReqmnts

Integration Tested

Systems

Environ-mentally Tested

Components

BuildTest

Environmʼt Coded/Unit Tested

Programs

User Tested

Programs

PostImplementation

Review

System Approved by Applications Testing


THE

GROUPPROCESS


Process Tailoring Guidelines (SP 1.3)

• OPD: Organization Process Definition •  IPM: Integrated Project Management

Tailoring guidelines

and criteria (OPD) ~~~~~~~~ ~~~~~~~~ ~~~~~~~~

Thinking

Project process ~~~~~~~~ ~~~~~~~~ ~~~~~~~~ ~~~~~~~~ ~~~~~~~~

Thinking and planning

Project plan

~~~~~~~~ ~~~~~~~~ ~~~~~~~~ ~~~~~~~~ ~~~~~~~~

PA: OPD+IPM PA: IPM

Typical tailoring areas: •  Management processes •  Engineering processes •  Standards •  Metrics


THE

GROUPPROCESS


Tailoring guidelines ~~~~~~~~ ~~~~~~~~ ~~~~~~~~ ~~~~~~~~ ~~~~~~~~

Estimation Process Step 3: Use the historical database to verify the estimate for each task

Purpose: To search the organization's historical data to see if a similar task (or group of tasks) exists so that previous experience can be used.

Tailoring guideline: This step should be performed whenever applicable data exists. It can be discarded when a new language or technology is being used.

Risk if omitted: Failure to use the database could result in significant oversight about schedule estimates, and could lead to a loss in revenue.

Minimum requirement: Data that exists, but is not considered applicable for the current estimate, must be reviewed with one other manager to verify non-applicability.

Example Process Tailoring Guideline (SP 1.3)


THE

GROUPPROCESS


Process Tailoring Example (SP 1.3)

# Process Step Risk if Process Step is Omitted Process Tailoring

Decision (by project team)

1.

Unit/module black-box (functional) testing.

The component may not work. Difficult to locate module-level problems during system test.

Test all modules.

2. Unit/module white-box testing (all paths through the module).

All scenarios of code execution are not tested.

Omit. Too expensive for release 1.0.

3. Module interface testing.

Data may not get passed correctly between modules. Difficult to locate module-level problems during system test.

Perform all interface tests.

4. Coverage testing: X% of the code.

(100-X)% of the code may not be verified to execute correctly. Later conditions may cause untested code to be executed.

Perform 60% coverage (include all critical code and most-used code).

5. Load testing (extreme volume of data).

Product may fail during heavy customer usage and with large databases.

Perform load testing to 88GB.


THE

GROUPPROCESS


Measurement Database / Repository (SP 1.4)

•  Can be a consolidated spread sheet or simple database containing items such as:

– estimates of size, effort, and cost – actual data on size, effort, and cost – productivity data – quality measurements – peer review coverage and efficiency – test coverage and efficiency – number and severity of defects found in the

requirements, design and code/construction


Repository


THE

GROUPPROCESS


Documentation Context •  The problems related to the Process Areas have been

solved and the solutions have been captured in the processes

•  Project and process documents are used to run the project and the business

– The practices within the CMMI have been institutionalized. The process “lives.”

– No “extra paperwork”. •  Process documentation is:

– Only a small part of process improvement – A method of capturing and sharing engineering and

management practices



2010-11-01

PG V1

Organizational Process Definition Case Study Example

OPD SPs

a) SP 1.1 Establish Standard Processes

b) SP 1.2 Establish Lifecycle Model Descriptions

c) SP 1.3 Establish Tailoring Criteria and Guidelines

d) SP 1.5 Establish the Organization's Process Assets Library

e) SP 1.6 Establish Work Environment Standards

Sample Artifacts

1)  Instructions for when a process step can be deleted or modified

2)  Web site for tools, templates, project examples, etc.

3)  Standard software that comes with all company computers

4)  Spiral lifecycle description

5)  Requirements process

Match sample artifacts with OPD SPs



2010-09-24

PG V1

Topics











2010-11-01

PG V1

Exercise 5

Task Follow the directions in the “Process Asset Library (PAL) 'Match Game'” exercise.

Expected Outcome Participants will have a better understanding of the purpose of different artifacts that are likely to be included in a Process Asset Library.



2010-09-24

PG V1

Topics











2010-09-24

PG V1

Integrated Project Management (IPM)

Purpose Establish and manage the project and the involvement of relevant stakeholders according to an integrated and defined process that is tailored from the organization's set of standard processes.



Project A

Project B Project C



2010-09-24

PG V1

When Integrated Project Management Is Not Done Well…

Projects do not take advantage of standard processes. Facilities and tools are not available when needed. Information to support future similar projects is not made available. No integrated master schedule is available to guide the stakeholders of the project. There are unclear responsibilities across groups.



2010-11-01

PG V1

Integrated Project Management Goals

Coordination and collaboration between the project and relevant stakeholders are conducted.

Use the Project's Defined Process The project is conducted using a defined process tailored from the organization's set of standard processes.

SG 1

Coordinate and Collaborate with Relevant Stakeholders

SG 2




2010-11-01

PG V1

Integrated Project Management Specific Practices -1

SP 1.1 Establish the Project's Defined Process SP 1.2 Use Organizational Process Assets for Planning Project Activities SP 1.3 Establish the Project's Work Environment SP 1.4 Integrate Plans SP 1.5 Manage the Project Using Integrated Plans SP 1.6 Establish Teams SP 1.7 Contribute to Organizational Process Assets

Use the Project's Defined Process

SG 1



2010-11-01

PG V1

Integrated Project Management Specific Practices -2

Coordinate and Collaborate with Relevant Stakeholders SP 2.1 Manage Stakeholder Involvement SP 2.2 Manage Dependencies SP 2.3 Resolve Coordination Issues

SG 2



2010-11-01

PG V1


Coordination Plans and

Issues Integrated

Project Plans

Use Organizational Process Assets



Project's Defined Process

SP 1.1

Integrate Plans


Project's Work

Environment

SP 1.3


SP 2.1 Contribute to


SP 1.7

Manage the Project Using

Integrated Plans

SP 1.5

Resolve Coordination

Issues

SP 2.3

Manage Dependencies

SP 2.2

Integrated Project Management Sampling of Work Products

Establish Teams

SP 1.6



2010-11-01

PG V1

Manage the Project Using

Integrated Plans

SP 1.5

Integrate Plans

SP 1.4

Use Organizational Process Assets


SP 1.2


SP 1.1

Establish Standard

Processes

OPD SP 1.1

Establish Tailoring


OPD SP 1.3


Library

OPD SP 1.5

Integrated Project Management Sampling of PA Relationships -1

Establish the Project's

Work Environment

SP 1.3 Establish

Work Environment Standards

OPD SP 1.6


Environment

VER SP 1.2


Environment

VAL SP 1.2

Establish the Product

Integration Environment

PI SP 1.2



2010-11-01

PG V1

Resolve Coordination

Issues

SP 2.3

Manage Dependencies

SP 2.2


SP 2.1


PP SP 2.6

Monitor Commitments

PMC SP 1.2

Integrated Project Management Sampling of PA Relationships -2

Contribute to Organizational

Process Assets



Repository

OPD SP 1.4

Establish Teams

SP 1.6 Establish Rules and


OPD SP 1.7


Library

OPD SP 1.5



2010-11-01

PG V1

Interaction Between OPD and IPM


Repository Team Rules

and Guidelines

Organization's Set of Standard

Processes

Lifecycle Model

Descriptions

Tailoring Guidelines

Organization's Process Asset

Library

Project A's Defined Process

The Organization (OPD)

Projects (IPM)

Project A's Plans

Project B's Defined Process

Project B's Plans

Project C's Defined Process

Project C's Plans

Work Environment

Standards


THE

GROUPPROCESS


Process Tailoring Guidelines (SG 1)

•  OPD: Organization Process Definition •  IPM: Integrated Project Management

Tailoring guidelines

and criteria (OPD) ~~~~~~~~ ~~~~~~~~ ~~~~~~~~

Thinking

Project process ~~~~~~~~ ~~~~~~~~ ~~~~~~~~ ~~~~~~~~ ~~~~~~~~

Thinking and planning

Project plan

~~~~~~~~ ~~~~~~~~ ~~~~~~~~ ~~~~~~~~ ~~~~~~~~

PA: OPD+IPM PA: IPM

Typical tailoring areas: •  Management processes •  Engineering processes •  Standards •  Metrics


Repository

Feedback


THE

GROUPPROCESS


Manage the Project Using the Integrated Plans (SP 1.5)

Example robustness includes:

•  Using the defined entry and exit criteria to authorize the initiation and determine the completion of the tasks

•  Monitoring the activities that could significantly affect the actual values of the project's planning parameters

•  Tracking the project's planning parameters using measurable thresholds that will trigger investigation and appropriate actions

•  Monitoring product and project interface risks •  Managing external and internal commitments based on the

plans for the tasks and work products of implementing the project's defined process

Reference - CMMI 1.2: CMU/SEI-2006-TR-008 (page 157)


THE

GROUPPROCESS


Example Size Tracking Chart (SP 1.5)

[CMU/SEI-92-TR-25]"1  ! 2 !3 !4 !5 !6 !7 !8 !9

!! Months!

Require-!ments!

60!!50!!40!!30!!20!!10!!

Now!Total!

Cumulative!changes!

TBDs!

PDR! CDR!SSR!

PSR = Product Specification Review!PDR = Preliminary Design Review!CDR = Critical Design Review!

Current Number of Requirements, Cumulative Changes,and Number of TBDs Against Time!

Threshold!


THE

GROUPPROCESS


0

5

10

15

20

25

30

35

0 1 2 3 4 5 6 7 8 9 10

TotalPlanEarned$ Spent

Example Earned Value Management (SP 1.5)

© Copyright 1995-2004, Dennis J. Frailey, All Rights Reserved!

Total

Spent

Plan

Earned



2010-11-01

PG V1

Integrated Project Management Case Study Example Focus Area

SP 1.1 Establish the Project's Defined Process SP 1.2 Use Organizational Process Assets for Planning Project Activities SP 1.3 Establish the Project's Work Environment SP 1.4 Integrate Plans SP 1.5 Manage the Project Using Integrated Plans SP 1.6 Establish Teams SP 1.7 Contribute to Organizational Process Assets

Use the Project's Defined Process

SG 1

Focus Area



2010-11-01

PG V1

Integrated Project Management Case Study Example

Which PASS scenarios are correct? 1. All PASS projects follow the standard process exactly as is

2. Projects can use their own processes and trace them to the PASS standard process

3. PASS provides a standard process and rules for tailoring

4. Once projects tailor the PASS standard process, it is called the projects' standard process

5. If the customer says eliminate QA, but the standard process requires QA with no tailoring, it's okay for PASS projects to tailor out QA to satisfy the customer



2010-09-24

PG V1

Topics











2010-09-24

PG V1

Organizational Training (OT)

Purpose Develop skills and knowledge of people so they can perform their roles effectively and efficiently.



2010-09-24

PG V1

When Organizational Training Is Not Done Well…

Staff members attend training courses they do not need. Staff members avoid training that is provided. Staff members are not released to attend training they need. Staff members are not appropriately skilled for tasks required to maintain a competitive edge.



2010-11-01

PG V1

Organizational Training Goals

Training for individuals to perform their roles effectively is provided.

Establish an Organizational Training Capability A training capability, which supports the roles in the organization, is established and maintained.

SG 1

Provide Training SG 2




2010-11-01

PG V1

Organizational Training Specific Practices

Provide Training SP 2.1 Deliver Training SP 2.2 Establish Training Records SP 2.3 Assess Training Effectiveness

SG 2

SP 1.1 Establish Strategic Training Needs SP 1.2 Determine Which Training Needs Are the Responsibility of the Organization SP 1.3 Establish an Organizational Training Tactical Plan SP 1.4 Establish a Training Capability

Establish an Organizational Training Capability

SG 1



2010-11-01

PG V1

Training Repository

Establish an Organizational

Training Tactical Plan

SP 1.3 Determine

Which Training Needs are the


SP 1.2 Establish Strategic Training Needs

SP 1.1

Assess Training

Effectiveness

SP 2.3

Establish Training Records

SP 2.2

Deliver Training

SP 2.1

Establish a Training

Capability

SP 1.4

Training Plan

Organizational Training Sampling of Work Products



2010-11-01

PG V1

Assess Training

Effectiveness

SP 2.3

Establish a Training

Capability

SP 1.4 Establish an

Organizational Training

Tactical Plan

SP 1.3

Determine Which Training Needs are the


SP 1.2 Establish Strategic Training Needs

SP 1.1

Establish Training Records

SP 2.2

Deliver Training

SP 2.1

Plan Needed Knowledge and Skills

PP SP 2.5

Organizational Training Sampling of PA Relationships



2010-11-01

PG V1

Organizational Training Case Study Example

OT SPs

a)  SP 1.1 Establish Strategic Training Needs

b)  SP 1.2 Determine Which Training Needs are the Responsibility of the Organization

c)  SP 1.3 Establish an Organizational Training Tactical Plan

d)  SP 1.4 Establish a Training Capability

e)  SP 2.3 Assess Training Effectiveness

Sample Artifacts

1)  Training classrooms

2)  Plan for 3-5 years in the future

3)  Analysis of course evaluations

4)  Plan states PASS, not projects, will provide risk tool training

5)  Plan for the next year

Match sample artifacts with OT SPs



2010-09-24

PG V1

Topics











2010-11-01

PG V1

OPF: Organizational Process Focus Helps the organization set up a process improvement process

OPD: Organizational Process Definition Identifies key elements of the standard process suite.

IPM: Integrated Project Management Emphasizes integration of elements within the project as well as integration of the project with the organization.

OT: Organizational Training Helps ensure proper training of personnel.

Improvement Infrastructure Summary Module

9 OPF OPD IPM OT


the Work




2010-09-24

PG V1

Topics











2010-11-01

PG V1

Exercise 6

Task Follow the directions in the “Scenario Evaluation” exercise.

Expected Outcome Participants will be able to articulate plausible connections between different scenarios and CMMI model components.




PG V1


Module 10: High Maturity



2010-11-01

PG V1


Module 9

OPF OPD IPM OT


the Work


Module 7

CM PPQA

MA DAR




Module 6

PP PMC

RSKM SAM



Module 5

RD REQM




Product Development

Module 8

TS PI

VER VAL

Module 10

OPP QPM CAR OPM

Enabling Performance Management of the Work

High Maturity



2010-09-24

PG V1

Topics

High Maturity Concepts

High Maturity Process Areas

- Organizational Process Performance (OPP)

- Quantitative Project Management (QPM)

- Causal Analysis and Resolution (CAR)

- Organizational Performance Management (OPM)

High Maturity Summary



2010-11-01

PG V1

Management by Rear-View Mirror

Many uses of measurement are purely retrospective: •  Do you know where you are (actual

vs. plan)? •  Do you know what corrective action to

take?

It is difficult to use these types of measurement results to answer the following questions: •  Will you be successful? •  What is the impact if you were to do

something different?



2010-11-01

PG V1

Management with a Navigation System

Measurement is used routinely by those who are proactive: •  Are you confident you know where you

are, where you are going, and your performance outcomes (quantitative understanding)?

•  Do you understand variation? Use measurement results to answer the following questions: •  Will you be successful? •  Are customer expectations and your

capabilities aligned? •  What if you were to do something

different?



2010-11-01

PG V1

Why is Understanding Variation Important?

Probably Not Probably Should

Customer wants the product in 10 weeks Historical range is 9-11 weeks Should the job be accepted?

9.5 10 10.5 11 9 9.5 10 10.5



2010-09-24

PG V1


Quantitative Management •  Managing a project or work group using statistical and other

quantitative techniques to build an understanding of the performance or predicted performance of processes in comparison to the project's or work group's quality and process performance objectives, and identifying corrective action that may need to be taken.

•  Statistical techniques used in quantitative management include analysis, creation, or use of process performance models, analysis, creation, or use of process performance baselines, use of control charts, analysis of variance, regression analysis; and use of confidence intervals or prediction intervals, sensitivity analysis, simulations, and tests of hypotheses.



2010-11-01

PG V1

Establishing a Foundation for High Maturity

•  Tailored from organizational processes for project characteristics to achieve organizational consistency

•  Provide an understanding of relationships between processes and project results

•  Provide a quantitative understanding that does not yet provide insight into variation

•  Defined in sufficient detail to enable consistent collection by the projects and aggregation by the organization

•  Aligned to organizational processes

•  Collected with an understanding of the tailoring in place

Foundation for High Maturity

Measures Processes



2010-09-24

PG V1

Topics










2010-11-01

PG V1

Organizational Process Performance (OPP)

Purpose Establish and maintain a quantitative understanding of the performance of selected processes in the organization's set of standard processes in support of achieving quality and process performance objectives, and to provide process performance data, baselines, and models to quantitatively manage the organization's projects.



2010-09-24

PG V1


Process Performance •  A measure of results achieved by following a process. Process

performance is characterized by both process measures (e.g., effort, cycle time, defect removal efficiency) and product or service measures (e.g., reliability, defect density, response time).

Process Performance Baseline •  A documented characterization of process performance, which

can include central tendency and variation.

•  A process performance baseline can be used as a benchmark for comparing actual process performance against expected process performance.



2010-09-24

PG V1

Relevant Terminology -2 Process Performance Model •  A description of relationships among the measurable attributes

of one or more processes or work products that is developed from historical process performance data and is used to predict future performance.

•  One or more of the measureable attributes represent

controllable inputs tied to a subprocess to enable performance of “what-if” analyses for planning, dynamic re-planning, and problem resolution. Process performance models include statistical, probabilistic and simulation based models that predict interim or final results by connecting past performance with future outcomes. They model the variation of the factors, and provide insight into the expected range and variation of predicted results. A process performance model can be a collection of models that (when combined) meet the criteria of a process performance model.



2010-09-24

PG V1


Quality and Process Performance Objectives •  Quantitative objectives and requirements for product quality,

service quality, and process performance.

•  Quantitative process performance objectives include quality; however, to emphasize the importance of quality in the CMMI Product Suite, the phrase “quality and process performance objectives” is used. “Process performance objectives” are referenced in maturity level 3; the term “quality and process performance objectives” implies the use of quantitative data and is only used in maturity levels 4 and 5.



2010-09-24

PG V1


Statistical and Other Quantitative Techniques

•  Analytic techniques that enable accomplishing an activity by quantifying parameters of the task (e.g., inputs, size, effort, and performance).

•  This term is used in the high maturity process areas where the use of statistical and other quantitative techniques to improve understanding of project, work, and organizational processes is described.

•  Examples of non-statistical quantitative techniques include trend analysis, run charts, Pareto analysis, bar charts, radar charts, and data averaging.

•  The reason for using the compound term “statistical and other quantitative techniques” in CMMI is to acknowledge that while statistical techniques are expected, other quantitative techniques can also be used effectively.



2010-09-24

PG V1

When Organizational Process Performance Is Not Done Well…

The projects may set objectives that are not achievable. Risk mitigations are too expensive or not needed. The organization may fail to accept a project that was really doable.



2010-11-01

PG V1

Organizational Process Performance Goals

Establish Performance Baselines and Models Baselines and models, which characterize the expected process performance of the organization's set of standard processes, are established and maintained.

SG 1



2010-11-01

PG V1

Establish Performance Baselines and Models SP 1.1 Establish Quality and Process Performance Objectives SP 1.2 Select Processes SP 1.3 Establish Process Performance Measures SP 1.4 Analyze Process Performance and Establish Process Performance Baselines SP 1.5 Establish Process Performance Models

SG 1

Organizational Process Performance Specific Practices -1



2010-11-01

PG V1

Baselines and Models

Quality and Process

Performance Objectives

Establish Quality and

Process Performance Objectives

SP 1.1

Establish Process

Performance Measures

SP 1.3 Analyze Process Performance and Establish Process

Performance Baselines

SP 1.4

Select Processes

SP 1.2 Establish Process

Performance Models

SP 1.5

Organizational Process Performance Sampling of Work Products



2010-11-01

PG V1

Establish Process

Performance Models



SP 1.4 Establish Process

Performance Measures

SP 1.3

Select Processes

SP 1.2 Establish

Quality and Process


SP 1.1

Specify Measures

MA SP 1.2

Organizational Process Performance Sampling of PA Relationships

Maintain Business

Objectives

OPM SP 1.1


Objectives

QPM SP 1.1

Multiple Specific

Practices

QPM

Multiple Specific

Practices

CAR

Multiple Specific

Practices

OPM

Select Subprocesses and Attributes

QPM SP 1.3



2010-11-01

PG V1

Organizational Process Performance Case Study Example – PASS Peer Review Baseline

PASS understands the performance of their peer reviews, i.e., they understand their central tendency and variation for defect density (defects per 1,000 lines of code (LOC)).

• STM XXX.X, Rev 00, 10-01-06

1 to 800 LOCs Reviewed > 800 LOCs Reviewed

10 11 12 13 14 15 16 3 4 5 6 7 8 9 10



2010-11-01

PG V1

Organizational Process Performance Case Study Example – PASS Peer Review Model

Size Choose how much to peer review, e.g., choose to peer review 20 pages.

Meeting Hours Choose the duration of the meeting, e.g., choose a 1.5 hour meeting.

Attendees Choose how many people to invite to the peer review, e.g., choose to invite 3 people.

Pre-Review Hours Choose the hours to review prior to the meeting, e.g., choose to review 1 hour prior to the meeting.

Defects Predicts the number of defects.

INPUTS OUTPUTS

PASS Peer

Review Model



2010-09-24

PG V1

Topics










2010-11-01

PG V1

Quantitative Project Management (QPM)

Purpose Quantitatively manage the project to achieve the project's established quality and process performance objectives.



2010-09-24

PG V1

When Quantitative Project Management Is Not Done Well…

Quality and process performance objectives for the project do not reflect the areas that are essential for project success. Projects cannot differentiate between outcomes that are a normal result of using the process and ones that are exceptions and should be addressed. The project's objectives for quality and process performance are not monitored and corrective action is not taken as needed.



2010-11-01

PG V1

Quantitative Project Management Goals

The project is quantitatively managed.

Prepare for Quantitative Management Preparation for quantitative management is conducted.

SG 1

Quantitatively Manage the Project SG 2



2010-11-01

PG V1

Quantitative Project Management Specific Practices -1

Prepare for Quantitative Management SP 1.1 Establish the Project's Objectives SP 1.2 Compose the Defined Process SP 1.3 Select Subprocesses and Attributes SP 1.4 Select Measures and Analytic Techniques

SG 1

Quantitatively Manage the Project SP 2.1 Monitor the Performance of Selected Subprocesses SP 2.2 Manage Project Performance SP 2.3 Perform Root Cause Analysis

SG 2



2010-11-01

PG V1

Measures Project Plans


SP 1.3

Compose the Defined

Process

SP 1.2


Objectives

SP 1.1

Monitor the Performance of Selected

Subprocesses

SP 2.1

Perform Root Cause

Analysis

SP 2.3

Select Measures and

Analytic Techniques

SP 1.4

Manage Project

Performance

SP 2.2

Quantitative Project Management Sampling of Work Products



2010-11-01

PG V1


SP 1.3

Compose the Defined

Process

SP 1.2


Objectives

SP 1.1

Select Measures and

Analytic Techniques



OPP SP 1.4

Establish Process

Performance Models

OPP SP 1.5


IPM SP 1.1 Establish

Quality and Process


OPP SP 1.1

Quantitative Project Management Sampling of PA Relationships -1

Specify Measures

MA SP 1.2

Specify Analysis

Procedures

MA SP 1.4



2010-11-01

PG V1

Monitor the Performance of Selected

Subprocesses

SP 2.1

Perform Root Cause

Analysis

SP 2.3

Manage Project

Performance

SP 2.2

Quantitative Project Management Sampling of PA Relationships -2

Determine and Address Causes of Outcomes

CAR



2010-11-01

PG V1

•  To reduce costs, the SaveAll project reduced the number of reviewers and meeting hours

•  The SaveAll project completed a peer review

•  The SaveAll project entered actual results in the organization's PASS peer review model (OPP)

•  The SaveAll project found fewer defects than the organization's PASS peer review model indicated they should have found

•  Reducing the number of reviewers and meeting hours resulted in much poorer quality

•  Management decided to do a root cause analysis to figure out how to correct the problem (CAR-like)

Quantitative Project Management Case Study Example



2010-09-24

PG V1

Topics










2010-09-24

PG V1

Causal Analysis and Resolution (CAR)

Purpose Identify causes of selected outcomes and take action to improve process performance.



2010-09-24

PG V1

When Causal Analysis and Resolution Is Not Done Well…

Root causes of success are not identified and shared across the organization. The same problem occurs again and again. Symptoms of problems are addressed rather than the root cause.



2010-11-01

PG V1

Causal Analysis and Resolution Goals

Root causes of selected outcomes are systematically addressed.

Determine Causes of Selected Outcomes Root causes of selected outcomes are systematically determined.

SG 1

Address Causes of Selected Outcomes SG 2



2010-11-01

PG V1

Causal Analysis and Resolution Specific Practices

Address Causes of Selected Outcomes SP 2.1 Implement Action Proposals SP 2.2 Evaluate the Effect of Implemented Actions SP 2.3 Record Causal Analysis Data

SG 2

Determine Causes of Selected Outcomes SP 1.1 Select Outcomes for Analysis SP 1.2 Analyze Causes

SG 1



2010-11-01

PG V1

Outcomes Measures

Analyze Causes

SP 1.2

Select Outcomes for

Analysis

SP 1.1

Evaluate the Effect of

Implemented Actions

SP 2.2

Implement Action

Proposals

SP 2.1

Record Causal

Analysis Data

SP 2.3

Causal Analysis and Resolution Sampling of Work Products

Action Proposals



2010-11-01

PG V1

Record Causal

Analysis Data

SP 2.3 Evaluate the

Effect of Implemented

Actions

SP 2.2

Implement Action

Proposals

SP 2.1

Elicit Suggested

Improvements

OPM SP 2.1

Causal Analysis and Resolution Sampling of PA Relationships

Analyze Causes

SP 1.2

Select Outcomes for

Analysis

SP 1.1

Perform Root Cause

Analysis

QPM SP 2.3



2010-11-01

PG V1

•  Root cause analysis uncovered reviewers used the organization's PASS standard process, which assumes many reviewers and long meetings.

•  The SaveAll project re-composed their defined process (QPM) to use their own low-end product process, collected data, developed a new process performance baseline and model to correct the problem

•  Continual improvement means measurably improving process capability in a controlled fashion

Causal Analysis and Resolution Case Study Example

0

2

4

6

8

10

1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35 37 39 41

Peer

Rev

iew

Cos

t New low-end product process released



2010-09-24

PG V1

Topics










2010-09-24

PG V1

Organizational Performance Management (OPM)

Purpose Proactively manage the organization's performance to meet its business objectives.



2010-09-24

PG V1

When Organizational Performance Management Is Not Done Well…

Process improvements are not aligned with business objectives. Business objectives do not align with process capabilities. An improvement is deployed throughout the organization without validating it. The deployment of an improvement is not planned or managed effectively.



2010-11-01

PG V1

Organizational Performance Management Goals

Improvements are proactively identified, evaluated using statistical and other quantitative techniques, and selected for deployment based on their contribution to meeting quality and process performance objectives.

Manage Business Performance The organization's business performance is managed using statistical and other quantitative techniques to understand process performance shortfalls, and to identify areas for process improvement.

SG 1

Select Improvements

SG 2

Measurable improvements to the organization's processes and technologies are deployed and evaluated using statistical and other quantitative techniques.

Deploy Improvements

SG 3



2010-11-01

PG V1

Organizational Performance Management Specific Practices -1

SP 2.1 Elicit Suggested Improvements SP 2.2 Analyze Suggested Improvements SP 2.3 Validate Improvements SP 2.4 Select and Implement Improvements for Deployment

Manage Business Performance SP 1.1 Maintain Business Objectives SP 1.2 Analyze Process Performance Data SP 1.3 Identify Potential Areas for Improvement

SG 1

Select Improvements

SG 2



2010-11-01

PG V1

Organizational Performance Management Specific Practices -2

Deploy Improvements SP 3.1 Plan the Deployment SP 3.2 Manage the Deployment SP 3.3 Evaluate Improvement Effects

SG 3



2010-11-01

PG V1

Measures*

Identify Potential Areas for

Improvement

SP 1.3 Analyze Process

Performance Data

SP 1.2

Maintain Business

Objectives

SP 1.1

Evaluate Improvement

Effects

SP 3.3

Manage the Deployment

SP 3.2

Plan the Deployment

SP 3.1

Elicit Suggested

Improvements

SP 2.1

Improvements

Organizational Performance Management Sampling of Work Products

Select and Implement

Improvements for

Deployment

SP 2.4

Validate Improvements

SP 2.3

Analyze Suggested

Improvements

SP 2.2

Deployment Plan

* Measures are used throughout all specific practices.



2010-11-01

PG V1

Organizational Performance Management Sampling of PA Relationships

Analyze Suggested

Improvements

SP 2.2

Plan the Deployment

SP 3.1

Elicit Suggested

Improvements

SP 2.1

Identify Potential Areas for

Improvement

SP 1.3 Analyze Process

Performance Data

SP 1.2

Manage Business

Objectives

SP 1.1

Select and Implement

Improvements for

Deployment

SP 2.4

Evaluate Improvement

Effects

SP 3.3

Manage the Deployment

SP 3.2

Validate Improvements

SP 2.3

Identify the Organization's

Process Improvements

OPF SP 1.3


OPF SP 3.3 Deploy


OPF SP 3.1

Obtain Measurement

Data

MA SP 2.1

Establish Quality and

Process Performance Objectives

OPP SP 1.1



2010-11-01

PG V1

Organizational Process Management Case Study Example

•  PASS gathered improvements from the SaveAll project (QPM) and deployed an updated peer review process for low-end systems

•  6 months later, PASS evaluated peer reviews from 3 new low-end systems

•  Statistical analysis showed costs were significantly reduced without sacrificing quality

•  PASS re-released the peer review model (OPP) with an additional selection for low-end systems

System Type Choose high-end system or low-end system. Size Choose how much to peer review, e.g., choose to peer review 20 pages.

Meeting Hours Choose the duration of the meeting, e.g., choose a 1.5 hour meeting.

Attendees Choose how many people to invite to the peer review, e.g., choose to invite 3 people.

Pre-Review Hours Choose the hours to review prior to the meeting, e.g., choose to review 1 hour prior to the meeting.

INPUTS



2010-09-24

PG V1

Topics










2010-11-01

PG V1 • STM XXX.X, Rev 00, 10-01-06

Case Study Example Summary

OPP

PASS understands their peer review performance through OPP baselines and models

1 During QPM, the SaveAll project used OPP models to monitor their peer review performance

2

The SaveAll project observed their peer review performance worsen so they initiated a CAR

CAR found the root cause was PASS processes for high-end security systems were expensive and ineffective so they developed their own processes and validated it

For the OPM improvement, PASS used SaveAll project's processes to build PASS low-end processes

PASS gathered low-end peer review performance data and created new OPP baselines and models for future projects

QPM

CAR

OPM 3

4

5 For IPM, the SaveAll project provided their low-end security system processes to PASS

6

During OPM, PASS validated then deployed the new PASS low-end processes

7

8

The PASS Story



2010-11-01

PG V1

Case Study Example for Requirements -1

•  In the past, PASS accepted all requirements changes from their high-end customers who had no cost or schedule constraints

•  The SaveAll project experienced high requirements volatility which impacted cost and schedule

•  They decided they needed to improve requirements management



2010-11-01

PG V1 • STM XXX.X, Rev 00, 10-01-06

Case Study Example for Requirements -2

OPP

For OPP, the SaveAll project created a model that predicts requirements volatility

1 During QPM, the SaveAll project used the OPP model to monitor requirements volatility

2

The SaveAll project observed requirements volatility worsen, resulting in cost and schedule problems, so they initiated a CAR

CAR found the root cause was SaveAll, the customer, is a large company and is not involved in requirements development, so the SaveAll project updated their processes to be more proactive at involving the customer

Other new low-end projects were experiencing similar problems. For the OPM improvement, PASS used the SaveAll project's lessons learned to update PASS requirements processes

PASS gathered requirements volatility data and created OPP baselines and models at the org level for future low-end projects

QPM

CAR

OPM 3

4

5 For IPM, the SaveAll project provided their requirements volatility lessons learned to PASS

6

During OPM, PASS validated then deployed the updated PASS requirements processes

7

8

The PASS Story



2010-11-01

PG V1

A View of High Maturity


Causal Analysis and Resolution

Organizational Process

Performance

Quantitative Project

Management

Organization

Customer

Improvement Proposals

Measures, baselines

and models

Organizational

quality & process

performance

objectives

Selected

outcomes

Updated measures, baselines and models (actual performance)

Progress toward achieving quality & process performance objectives

Improvements

Performance issues

Root cause solutions

Quality & process performance objectives

Quality & process performance objectives

Measures, baselines and models

*This slide is discussed in more detail in the Understanding CMMI High Maturity Practices course.



2010-11-01

PG V1


OPP: Organizational Process Performance Establishes baselines and models so projects and the organization can have a quantitative understanding of their ability to achieve objectives QPM: Quantitative Project Management Manages project performance quantitatively to achieve quality and process performance objectives. CAR: Causal Analysis and Resolution Covers analyzing outcomes (successes or deficiencies) from projects or the organization and taking appropriate action OPM: Organizational Performance Management Uses quantitative date to focus improvement activities on areas that are critical to the business and add business value

Module 10

OPP QPM CAR OPM

Enabling Performance Management of the Work

High Maturity




PG V1


Module 11: Tying It All Together



2010-09-24

PG V1

Topics

Process Area to Process Area Relationships

Exercise 7: Project Planning

Understanding Levels

- Capability Levels

- Maturity Levels

Working with the Representations

Summary

Exercise 8: Generic Practices



2010-11-01

PG V1

Relationships Among Process Areas

We will now discuss interactions of groups of PAs so as to show you a larger view of model-based process improvement.

Basic process areas should be implemented before the advanced process areas to ensure that the prerequisites are met to successfully implement the advanced process areas.



2010-11-01

PG V1

We will be discussing the interactions of PAs in the following groupings:

Basic and Advanced Groupings



2010-11-01

PG V1

Basic Process Management PAs

Resources and coordination

Standard process and other assets

Training for projects and support groups in standard process and assets

Organ

izatio

n’s

proc

ess n

eeds

and o

bjecti

ves

Standard process, work, environment standards, and other assets

Organization’s business objectives

Project Management, Support, and Engineering

process areas

Training needs

Improvement information (e.g., lessons learned, data, and artifacts

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

OPF = Organizational Process FocusOT = Organizational Training

OPD = Organizational Process Definition

OPD

OT

OPF

Senior management



2010-11-01

PG V1

Advanced Process Management PAs

OPM = Organizational Performance ManagementOPP = Organizational Process Performance

Basic Process Management

process areas

Project Management,Support, and Engineering

process areas

OPM

Quality and process objectives

Ability to develop anddeploy standard process and other assets

Improvements

Quality and processmeasures, baselines,Performance objectives, and models

Performance capability data

Cost and benefit

data from piloted

improvements

Comm

on

measures

Organization

Senior management

Performance

capability

Business objectives OPP



2010-11-01

PG V1

Basic Project Management PAs

What to buildWhat to do

SAM

What to monitor

Replan

Plans

Status, issues, and results of reviews and monitoring

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

Engineering and Support process areas

Measurement needs

Supplier agreement

Corrective action

Commitments

Corrective action

Status, issues, and results of process and product evaluations; measures and analyses

REQM

PMC

Supplier

PMC = Project Monitoring and ControlPP = Project Planning

SAM = Supplier Agreement ManagementREQM = Requirements Management

PP

Product and

product component

requirements

Product and product component requirements



2010-11-01

PG V1

Advanced Project Management PAs

Statistical management data

Risk taxonomies and parameters, risk status, risk mitigation plans, and corrective action

Risk exposure due to unstable processes

Product architecture for structuring teams Teams for performing engineering

and support processes

Organization’s standard processes, work environment standards, and supporting assets

Project’s defined process and work environment

Identified

risks

Coordination, commitments, and issues to resolve

Project’s shared vision

Project performance data

Less

ons l

earne

d,

plann

ing, a

nd

perfo

rman

ce da

ta

QPM

Process Management process areas

RSKM

IPM

Basic Project Managementprocess areas

Engineering and Supportprocess areas

QPM = Quantitative Project ManagementIPM= Integrated Project Management

RSKM = Risk Management

Teaming rules

and guidelines

Project’s composed and defined processes

Quantitative objectives, subprocesses to statistically manage, project’s composed, and defined process

Proc

ess

perfo

rman

ce o

bjec

tives

,

base

lines

, and

mod

els



2010-11-01

PG V1

The Engineering Process Areas

RD PI

VAL

TS

VER

Requirements

Customer needs

Product and product component requirements

Requirements, Product components, work products, verification and validation reports

Product components

Alternative solutions Product

Customer

PI = Product IntegrationRD = Requirements DevelopmentTS = Technical SolutionVAL = ValidationVER = Verification

Project Management process areas

Requirements



2010-11-01

PG V1

Basic Support PAs

All process areas

Measurements and analyses

Information needs

Controlled configuration items, baselines, and audit reports

Processes and work products, standards, and procedures

Quality and noncompliance issues

Configuration items and change requests

PPQAMA

CM

MA = Measurement and AnalysisCM = Configuration Management

PPQA = Process and Product Quality Assurance



2010-11-01

PG V1

Advanced Support PAs

All process areas

CAR = Causal Analysis and ResolutionDAR = Decision Analysis and Resolution

CAR

DAR

Formal evaluations

Selected issues

Defects, other problems,and successes

Process improvement proposals



2010-09-24

PG V1

Topics





- Maturity Levels


Summary




2010-11-01

PG V1

Exercise 7

Task Follow the directions in the “Project Planning” exercise.

Expected Outcome Participants will gain some insight and understanding into how many process areas are involved in project planning, not just the Project Planning process area. The Project Planning process area does not address all project planning activities.



2010-09-24

PG V1

Topics





- Maturity Levels


Summary




2010-11-01

PG V1

Understanding Levels -1

Levels are used in CMMI to describe an evolutionary path recommended for an organization that wants to improve the processes it uses to develop and maintain its products and services.

CMMI supports two improvement paths:

•  continuous - enabling an organization to incrementally improve processes corresponding to an individual process area (or group of process areas) selected by the organization

•  staged - enabling the organization to improve a set of related processes by incrementally addressing successive predefined sets of process areas



2010-11-01

PG V1

Understanding Levels -2

These two improvement paths are associated with two types of levels that correspond to the two representations, staged and continuous.

For the continuous representation, we use the term capability level or process area capability.

For the staged representation, we use the term maturity level or organizational maturity.



2010-11-01

PG V1

CMMI Model Structure



2010-11-01

PG V1

Levels Are Similar

Regardless of the representation you select, the concept of levels is the same.

To reach a particular level, an organization must satisfy all of the appropriate goals of the process area or set of process areas that are targeted for improvement, regardless of whether the level is a maturity or a capability level.



2010-09-24

PG V1

Topics





- Maturity Levels


Summary




2010-11-01

PG V1

Capability Levels -1

Capability levels provide a scale for measuring your processes against each process area in a CMMI model.

A capability level for a process area is achieved when all of the generic goals are satisfied up to that level.

There are four capability levels (0-3).

Each level is a layer in the foundation for continuous process improvement.

Capability levels are cumulative (i.e., a higher capability level includes the practices of the lower levels).



2010-11-01

PG V1

Capability Levels -2

Defined

CL 1

CL 3

CL 2

CL 0

Managed

Performed

Incomplete



2010-11-01

PG V1

Representing Process Area Capability

The process area capability of an implemented process can be represented by a bar.

Cap

abili

ty L

evel

This point represents a higher level of capability

Process Area n

CL 1

CL 3

CL 2

CL 0

3

2

1

0

this point in a specific process area

than



2010-11-01

PG V1

CL 2 CL 2

Because capability levels build upon one another, there can be no gaps.

CL 1

CL 3

CL 1

CL 3

CL 2

CL 1

CL 3

CL 1

CL 3

CL 2

Capability Levels Are Cumulative

CL 0 CL 0 CL 0 CL 0



2010-11-01

PG V1

Capability Levels and GGs/GPs

Do zero or more SPs, but not all

Do ALL SGs & SPs, satisfying GP 1.1

Do CL 1 and add GP 2.Xs

Do CL2 and add GP 3.Xs

Specific Goals and Practices Generic Goals and Practices

CL 1

CL 3

CL 2

CL 0

GG 3 GG 2 GG 1 SG x SG 1

SP 2.3

SP 1.2

GP 1.1

SP x.y

SP 1.2

SP 1.1

GP 2.1

GP 1.1

GP 2.10

SP x.y

SP 1.2

SP 1.1

GP 2.1

GP 1.1

GP 3.1

GP 3.2

GP 2.10

SP x.y

SP 1.2

SP 1.1

SP . . .

SP . . .

SP . . .

SP . . .

GP . . .

GP . . .



2010-11-01

PG V1

Not performed, incomplete A few GPs or SPs may be implemented

GG 1 All SPs Perform the work

GG 1 and GG 2 All SPs

Adhere to policy; follow documented plans and processes, apply adequate resources; assign responsibility and authority; train people, apply configuration management, monitor, control, and evaluate process; identify and involve stakeholders; review with management

GG 1, GG 2, and GG 3 All SPs

Project's process is tailored from organization's standard processes; understand process qualitatively; process contributes to the organizations assets

Achieving Capability Levels (CLs) for a Process Area

CL 1

CL 3

CL 2

CL 0



2010-11-01

PG V1

A project decided PP, PMC, RSKM, and VER are important and conducted a 4 PA appraisal with a target profile of CL3 for all 4 PAs, but achieved lower CLs than the target profile.

Capability Levels and Process Areas -1

SG 2

GG 1 GG 2

GG 3 GG 3

GG 1 GG 2

SG 1

SG 3

SG 1

GG 1

GG 3

GG 2

SG 1

SG 2 SG 2

GG 2 GG 1

GG 3

SG 1

SG 2

PP PMC RSKM RD TS CAR VER

SG 3 SG 3

CL 2 CL 0 CL 3 CL 1 N/A N/A N/A



2010-09-24

PG V1

Topics





- Maturity Levels


Summary




2010-11-01

PG V1

Maturity Levels -1

ML 1

ML 5

ML 4

ML 3

ML 2

Optimizing

Quantitatively Managed

Defined

Managed

Initial



2010-11-01

PG V1

Maturity Levels -2

ML 1

ML 5

ML 4

ML 3

ML 2

Process unpredictable, poorly controlled, and reactive

Process characterized for projects and is often reactive

Process measured and controlled

Focus on continuous process improvement


Initial

Managed

Optimizing

Defined Process characterized for the organization and is proactive



2010-11-01

PG V1

Achieving Maturity Levels

To achieve a maturity level •  All process areas at that level and all levels below it must be

satisfied or determined to be not applicable.

And to achieve a maturity level 3 or higher •  The generic goal 3 for each applicable maturity level 2 PA must also

be rated satisfied for maturity level 3 or higher.

Note: A process area is satisfied if and only if all of the process area's relevant specific and generic goals are rated as satisfied.



2010-11-01

PG V1

Achieving Maturity Levels (ML)

Processes are ad hoc and chaotic

GG 2 All ML2 PAs

Adhere to policy; follow documented plans and processes; apply adequate resources; assign responsibility and authority; train people; apply CM; monitor, control, and evaluate process; identify and involve stakeholders; review with management

GG 2 and GG 3 All ML2 and ML3 PAs

Tailor the project's process from organization's standard processes; understand processes qualitatively; ensure that projects contribute to organization assets

GG 2 and GG 3 All ML2, ML3, and ML4 PAs

Establish quality and process performance objectives; use statistical and other quantitative techniques to understand process capability and manage projects

GG 2 and GG 3 All ML2, ML3, ML4, and ML5 PAs

Analyze process performance data compared to business objectives and identify improvements to address gaps; use causal analysis to prevent recurrence of problems or to leverage positive outcomes

ML 1

ML 3

ML 2

ML 4

ML 5



2010-11-01

PG V1

ML 3

Maturity Levels Should Not Be Skipped

Each maturity level provides a necessary foundation for effective implementation of processes at the next level:

•  Higher level processes have a greater chance of success with the discipline provided by lower levels.

•  The effect of higher maturity innovations are more easily measurable.

Higher maturity level processes may be performed by organizations at lower maturity levels with the risk of not being consistently applied in a crisis. ML 1

ML 5

ML 4

ML 2



2010-09-24

PG V1

Topics





- Maturity Levels


Summary




2010-11-01

PG V1

Comparing Capability and Maturity Levels

CL 1

CL 3

CL 2

CL 0

ML 1

ML 5

ML 4

ML 3

ML 2

Continuous Representation Staged Representation

Defined

Managed

Performed

Incomplete

Defined

Managed

Initial

Optimizing




2010-11-01

PG V1

Adapted from Cepeda Systems & Software Analysis, Inc.

Summarizing Maturity Levels and Capability Levels in Relation to GGs and GPs

CL3

CL2

Staged Representation Maturity Levels

GG 2 Institutionalize a Managed Process

GG 3 Institutionalize a Defined Process

GG 1 Achieve Specific Goals

GP 1.1

GP 2.1 GP 2.2 GP 2.3 GP 2.4 GP 2.5 GP 2.6 GP 2.7 GP 2.8 GP 2.9 GP 2.10

GP 3.1 GP 3.2


Capability Levels

Establish an Organizational Policy Plan the Process Provide Resources Assign Responsibility Train People Control Work Products Identify and Involve Relevant Stakeholders Monitor and Control the Process Objectively Evaluate Adherence Review Status with Higher Level Management

Perform Specific Practices

Establish a Defined Process Collect Process Related Experiences

ML5

ML4

ML3

ML2

CL1

Generic Goals Generic Practices



2010-09-24

PG V1


Some benefits of choosing the continuous representation are It allows you to select the order of improvement that best meets your

organization's business objectives and mitigates your organization's areas of risk.

It enables comparisons across and among organizations on a process area by process area basis.

Proc

ess A

rea C

apab

ility



2010-09-24

PG V1

Staged Representation

Some benefits of choosing the staged representation are It provides a proven sequence of improvements, each serving as a

foundation for the next.

It permits comparisons across and among organizations by the use of maturity levels.

It provides a single rating that summarizes appraisal results and allows comparisons among organizations.



2010-11-01

PG V1

Continuous Can Support Staged The continuous representation can be useful to an initiative with a staged representation focus • as a guide for detailed planning for improvement within

each process area • as a way to track and report intermediate progress short

of achieving a full maturity level Staged Can Support Continuous The staged representation can be useful to an initiative with a continuous representative focus • as a guide to understanding how process areas support

each other • as a guide for big picture, organization-based planning • as a means for benchmarking success

Representations Can Support Each Other



2010-11-01

PG V1

•  The content is common to both representations. •  Both representations are designed to offer essentially

equivalent results. •  In defining an improvement plan that focuses on your

unique business needs, you may use the principles of both the staged and continuous representations.

•  You may choose the continuous representation for guiding internal process improvement and choose the staged representation to conduct appraisals.

Continuous and Staged Can Be Used Together



2010-11-01

PG V1

Equivalent Staging

Equivalent staging enables an organization using the continuous representation to convert a capability level profile to the associate maturity level rating. Equivalent staging defines what combination of PAs and CLs corresponds to each ML: •  To achieve ML 2, you must achieve CL 2 or higher in all

ML2 PAs. •  To achieve ML 3, you must achieve CL 3 in all ML 2 and

ML 3 PAs. •  To achieve ML 4, you must achieve CL 3 in all PAs up

through ML 4 PAs. •  To achieve ML 5, you must achieve CL 3 in all PAs.

.



2010-11-01

PG V1

Target Profiles and Equivalent Staging Name Abbr. ML CL1 CL2 CL3 Configuration Management CM 2

Measurement and Analysis MA 2 Project Monitoring and Control PMC 2 Target Project Planning PP 2 Profile 2 Process and Product Quality Assurance PPQA 2 Requirements Management REQM 2 Supplier Agreement Management SAM 2 Decision Analysis and Resolution DAR 3 Integrated Project Management IPM 3 Target

Profile 3 Organizational Process Definition OPD 3 Organizational Process Focus OPF 3 Organizational Training OT 3 Product Integration PI 3 Requirements Development RD 3 Risk Management RSKM 3 Technical Solution TS 3 Validation VAL 3 Verification VER 3 Organizational Process Performance OPP 4 Target

Profile 4 Quantitative Project Management QPM 4 Causal Analysis and Resolution CAR 5 Target

Profile 5 Organizational Performance Management OPM 5



2010-09-24

PG V1

Topics





- Maturity Levels


Summary




2010-09-24

PG V1

Summary

Both staged and continuous representations of the CMMI models provide the same essential content for successful process improvement. The organization's business objectives should be the driver of process improvement and direct when to use the staged or continuous representation. In practice, organizations use elements of both representations in their process improvement efforts.



2010-09-24

PG V1

Topics





- Maturity Levels


Summary




2010-09-24

PG V1

Exercise 8

Task Follow the directions in the “Generic Practices” exercise.

Expected Outcome Participants will gain some insight and understanding into typical issues encountered in the real-life world when addressing Generic Practices.




PG V1


Module 12: Summary



2010-09-24

PG V1

Topics

What We Hope You Walk Away With

Next Steps

Where to Find More Information and Help

Exercise 9: Map Statements to Process Areas

Revisiting Course Expectations

Evaluating the Course



2010-09-24

PG V1

Course Objectives

By now, you should be able to describe the components of CMMI models and their relationships discuss the process areas in CMMI models locate relevant information in the model



2010-11-01

PG V1

Reviewing Process Area Components

Expected

Informative

Required

Specific Practices

(SP)

Generic Practice


Products

Introductory Notes


Purpose Statement

Generic Goals (GG)

Specific Goals (SG)

Generic Practices

(GP)

Process Area (PA)



2010-11-01

PG V1

The Capability Levels

Defined

CL 1

CL 3

CL 2

CL 0

Managed

Performed

Incomplete



2010-11-01

PG V1

The Maturity Levels

ML 1

ML 5

ML 4

ML 3

ML 2 Process unpredictable, poorly controlled, and reactive

Process characterized for projects and is often reactive

Process measured and controlled

Focus on continuous process improvement


Initial

Managed

Optimizing

Defined Process characterized for the organization and is proactive



2010-11-01

PG V1

Continuous Representation: PAs by Category Process Areas Category

Project Management

Process Areas

Category


Engineering


Support



Process Management



2010-11-01

PG V1



5 Optimizing


2 Managed




1 Initial


Risk Rework




2010-11-01

PG V1

CMMI-DEV PAs: Organization by Maturity Level and Category

ML5

ML4

ML3

ML2

Requirements Development Technical Solution Product Integration Verification Validation

Engineering

Configuration Management Process and Product Quality Assurance Measurement and Analysis

Support

Project Planning Project Monitoring and Control Requirements Management Supplier Agreement Management

Organizational Process Focus Organizational Process Definition Organizational Training

Process Management

Organizational Process Performance


Integrated Project Management Risk Management

Quantitative Project Management

Decision Analysis and Resolution

Causal Analysis and Resolution

Project Management



2010-11-01

PG V1

Remember “M” is for Model, Not Process

Model scope

Process descriptions are below the coverage level of the model



2010-09-24

PG V1

Topics


Next Steps







2010-11-01

PG V1

Next Steps

There are many other aspects of process improvement that must be addressed to construct and implement an effective process improvement program.

The SEI is the official steward for CMMI and as such has the responsibility to collect and make available information about CMMI. Some of that information is referenced in this module.



2010-11-01

PG V1

An effective change program requires an understanding of current status. Watts Humphrey proverb If you don't know where you are, a map won't help.

Knowledge of the Current Process



2010-11-01

PG V1

http://www.sei.cmu.edu/library/abstracts/reports/96hb001.cfm

The IDEAL Model



2010-11-01

PG V1

CMMI-DEV Roadmap for Professionals

Observation

CMMI-DEV Practitioner Track

CMMI-DEV Instructor

Observation SCAMPI

Lead Appraiser

Introduction To CMMI-DEV

Intermediate Concepts of CMMI-DEV

Examination

Intermediate Concepts of CMMI-DEV

CMMI-DEV Level 2 for

Practitioners

CMMI-DEV Level 3 for

Practitioners

Understanding CMMI-DEV

High Maturity Practices

CMMI-DEV Instructor

Training Entry Examination

CMMI-DEV Instructor

Qualification Steps

CMMI-DEV Instructor Training

SCAMPI Lead Appraiser

Qualification Steps

SCAMPI Lead Appraiser Training

SCAMPI Lead Appraiser

Certification Examination

SCAMPI High Maturity Lead

Appraiser Qualification

Steps

SCAMPI High Maturity Lead

Appraiser Certification Examination

CMMI-DEV Instructor Track

SCAMPI Lead Appraiser Track

SCAMPI High

Maturity Lead

Appraiser

CMMI-DEV Practitioner



2010-09-24

PG V1

Topics


Next Steps







2010-11-01

PG V1

Where to go for more information…

The point is that knowing something about the model is not the end but the beginning of your CMMI-based process improvement journey.

The SEI website provides a wealth of information to assist organizations in their process improvement efforts •  Technical Reports •  Publications and Presentations •  Pages on Topics of Interest, e.g., CMMI Adoption •  Webinars •  Public Course Offerings, e.g., Process Improvement Visit: www.sei.cmu.edu to see a complete list of information available



2010-09-24

PG V1

Reference Guide

You have been provided with a reference guide for locating information relative to •  Learning more about the CMMI product suite •  Using the CMMI for establishing initiatives, appraising your

organization and as a reference guide •  Forums that exist within the CMMI community for sharing process

improvement best practices and lessons learned •  Mappings to other industry standards



2010-09-24

PG V1

Topics


Next Steps







2010-11-01

PG V1

Exercise 9

Task Follow the directions in the “Map Statements to Process Areas” exercise.

Expected Outcome Participants will gain more familiarity with process area content and its relationship with real world situations.



2010-09-24

PG V1

Topics


Next Steps







2010-11-01

PG V1

Revisit Course Expectations

Discussion: Were your expectations met?



2010-09-24

PG V1

Topics


Next Steps







2010-11-01

PG V1

Please fill out a course evaluation form and return it. Thank you for your participation.

Course Evaluation