Module 1 Introduction - pudn.comread.pudn.com/downloads70/ebook/252502/motorolaCMMTraining.pdf · Module 1 Introduction Target Audie nce ... .Explain and use the structure of the

Module 1 Introduction

Target Audience

The target audience will be individuals with knowledge of software engineering and

management and an awareness of process management concepts who want to understand

fundamental concepts of the Capability Maturity Model (CMM).This includes:

.Software engineering process group members or personnel responsible for an organization's

software process improvement program.

.Software engineers and managers with an interest in the details of the SEI CMM.

.Software engineering educators.

.Those interested in changes to the CMM Model in VerBion1.1.

Course Objectives

By the end of this course, you will be able to:

.Describe the fundamental concepts of the CMM.

.Explain and use the structure of the CMM.

.Discuss the key process areas in the CMM.

.Interpret the CMM and the key practices in different contexts.

.Use the CMM in software process improvement activities.

.Use the CMM in software process improvement activities-

Module I--Introduction

Objectives

Upon completion of Module L Introduction, the participant will be able to:

.Define the Software Engineering Institute (SEI).

.Understand the principles of process management and process change used by the

capability Maturity Model (CMM).

.Identify the characteristics of immature and mature software organizations.

.Describe process relative to the CMM.

1

-Established in 1984

-Federally Funded Research and Development Center (FFDRC)

· Located at Carnegie Mellon University (CMU) Pittsburgh,PA

-Managed by Advanced Research Projects Agency (ARPA) -CMM Version 1.Oreleased in 1991 -CMM Version 1.lreleased in 1993 -CMMI Version 1.Oreleased in 2000

SEI Mission

-Provide leadership in advancing the state of the practice of software engineering.

-Provide an assessment vehicle.

Software Process Management Premise

The quality of a software system is highly influenced by the quality of the process used to

develop and maintain it.η1is implies focus on process as we11as product.

Characteristics of an Immature Process

.Ad hoc; process improvised by practitioners and their management

.Not rigorously followed or enforced

-Highly dependent on current practitioners

.Cost and schedule problems likely

-Product functionality and quality may be compromised to meet schedule

.Use of new technology risky

.Quality difficult to predict

2

Process Maturity

Definition

Process maturity measures the extent to which a specific process is:

.Defined.

.Managed

.Measured

.Controlled.

.Effective.

CMM Technology

-There is more terminology in the CMM that takes on different meanings and

interpretations than in standard English.

· These will be pointed out throughout the class.

.Examples:

-Group

3

-SQA

-Work Product

-Contractor

-???

4

Model-based Improvement(cont.)

Risks

-Models are simplifications of the real world.

-Models are not comprehensive.

.Interpretation and tailoring must be aligned to business objectives.

.Judgment is necessary use models correctly and with insight.

5

Module 2 CMM Overview

Capability Maturity Model

The Capability Maturity Model (CMM)is:

-A commonsense application of process management and quality improvement concepts

to software development and maintenance-

-A community-owned guide-

-A model for organizational improvement.

6

-The underlying structure for reliable and consistent CMM-based appraisal methods.

Capability Maturity Model (cont.)

What the CMM Does Not Cover

The CMM does not address all software process and quality improvement issues. The

issues that are addressed only indirectly, or by implication, in the CMM include:

· Specific tools, methods, and technologies.

· Concurrent engineering and teamwork.

一 Integrated Product Development CMM

· System engineering, marketing, etc.

一 Systems Engineering CMM

· Human resources.

一 People CMM

· Organizational behavior.

The CMM is necessary —

But not sufficient.

Definitions Process capability

The range of expected results that can be achieved by following a process, initially established at the organization level .It is a predictor of future project outcomes. Process performance A measure of the actual results achieved from following a process-Process performance refers to a particular project in the organization.

Process Capability

Performance Data

7

Maturity levels are well--denned evolutionary plateaus on the path to becoming a mature software organization.

Each level is a layer in the foundation for continuous process improvement .There are five maturity levels in the CMM. .Maturity levels are described in terms of key process areas.

The Maturity Levels(cont.)

Optimizing(5) Focus on process and technology improvement

Quantitatively Managed(4) Process measured and controlled

Defined(3)

Process characterized fairly well understood

Initial(1) Unpredictable and poorly controlled

Repeatable(2) Can repeat previously mastered tasks

The Maturity Levels (cont.) Understanding the Initial Maturity Level (Level 1) An organization at the Initial Maturity Level: .Is performance driven by the competence and heroics of the people doing the work. .Promotes high quality and exceptional perfom1ance,which are possible as long as the best people can be hired. .Is unpredictable-for good or ill. .Is characterized by major problems that are managerial ,not technical. The major problems facing the software organization are managerial, not technical.

Software Management is Ad Hoc Level 1

Requirements and other inputs flow in. A software product is(usually)produced by some amorphous process. The product flows out and (it is hoped)works. 8

The Key Process Areas for the Initial Level

Understanding the Repeatable Maturity Level (Level 2) An organization at the Repeatable Maturity Level:

.Has established effective software project management-

.Documents and follows the software project management process- .Uses organizational policies to guide the projects in establishing management process- .Repeats successful practices developed during previous projects.

P

roject Management Process is in Place Level2

Req Design Code Test

The process of building software is a series of black boxes with denned milestones

The Key Process Areas for the Repeatable Level

9

The Maturity Levels (cont.)

Understanding the Defined Maturity Level (Level 3) An organization at the Defined Maturity Level:

.Builds on the software project management foundation of Level2.

.Controls a process by defining, documenting, understanding, training, and measuring- .Builds processes that empower the individuals doing the work.

Managed According to a Defined Process Level 3

Roles and responsibi11ties in the process are understood. The production of the software product is visible throughout the software process Processes are denned to the proper level of detail. Phases (e.g.,Test)are denned in detail so everyone knows and performs tests similarly.

The Key Process Areas for the Denned Level

10

Defined (3)

Peer Reviews Intergroup Coordination Software Product Engineering Integrated Software Management Training Program Organization Process Definition Organization Process Focus

Understanding the Quantitatively Managed Maturity Level (Level 4)

An organization at the Quantitatively Managed Maturity Level applies the principles of

statistical process control to address special causes of process variation.

Control Chart with special Causes Common

Causes Level 4 addresses Special Causes.

Level 5 addresses Common Causes.

Product and Process Are Quantitatively Managed Management has an objective basis for making decisions. Level4

Reactive

Management is able to predict performance within quantified realistic bounds. Management uses data as the basis for decisions, goals, Improvements, etc.

The Key Process Areas for the Managed Level

Software Quality Management Quantitative Process Management Manage

d(4)

Software Quality Management

Quantitative Process Management

11

12

The CMM Structure

Components

.Maturity levels

.key process areas

.Goals

.Common features

.key practices

13

Maturity Levels

Maturity levels are well-denned evolutionary plateaus on the path to becoming a mature

software organization.

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

.There are Eve maturity levels in the CMM.

.Achieving each level establishes a different component of the software process.

Key Process Areas

.Key process areas identify a cluster of related activities that, when performed collectively,

achieve a set of goals considered important for enhancing process capability

.Defined to reside at a single maturity level

.Identify the issues that must be addressed to achieve a maturity level

.There are 18KPAs in the CMM

14

Goals

.summarize the key practices of the key process areas .Are considered important for enhancing process capability for that level of maturity

.Can be used to guide organizations and appraisal teams in assessing alternative ways to

implement key process areas .Each key practice maps to one or more goals .Goal 1 is the institutionalization goal in each KPA. It measures implementation of:

-Commitment to Perform

-Ability to Perform

-Measurement

-Verification

Institutionalization Common Features A repeatable process is a set of activities performed to achieve a given purpose that is institutionalized by: .Adhering to organizational policies. .Following a document plan and process description. .Allocating adequate resources (including funding, people, and tools). .Assigning responsibility and authority. .Training the affected people. .Measuring the process and its work products. .Objectively reviewing the process and its work products. .Reviewing status with appropriate levels of management and taking corrective action. The work products of a repeatable process are appropriately: · Compliant with specified standards and requirements. · Reviewed by those affected. · Placed under version control or configuration management.

Common Features Common features are used to organize the key practices in each key process area. The five common features are: · Commitment to perform. · Ability to perform. · Activities performed. · Measurement and analysis. · Verifying implementation.

Common Features (cont.)

Commitment to Perform Commitment to perform describes the actions the organization must take to ensure that

the process is established and will endure. The commitment typically includes: · Polices. · Senior management sponsorship. Commitment to Perform Examples

· "The project follows a written organizational policy for 〈 X〉 ."

15-"This policy typically specifies that..."


Ability to Perform

Ability to perform describes the preconditions that must exist in the project or

organization to implement the software process competently. The ability to perform

typically includes:

· Resources.

· Organization structure.

· Responsibility/authority.

· Training.

Ability to Perform Examples

· "A group that is responsible for 〈 X〉 exists."

· "Adequate resources and funding are provided for 〈 X〉 ."

· "Tools to support 〈 X〉 activities are made available."


Ability to Perform

Training statements are one of two formats:

· At ML2:" 〈 Roles 〉 are trained to perfom1〈 X〉 ."

· At MLs3-5:"〈 Roles 〉 receive required training to perform 〈 X〉 ."

Activity 1

· Activity 1 describes implementing the institutionalized process, not just a process.


Activities Performed

Activities performed describes the roles and procedures necessary to implement a key

process area.

Activities performed typically include:

· Establishing plans and procedures.

· Performing the work. 16

· Tracking it.

· Taking corrective actions as necessary.

.Collecting data where appropriate.

Activities Performed Examples

· " 〈 Activities for X 〉 are performed according to the plan."

一 "The plan covers ..."

· " 〈 Do X〉 according to a documented procedure."


Measurement and Analysis

Measurement and analysis describes the need to measure the KPA activities and analyze

the measurements. Measurement and analysis typically includes examples of the

measurements that could be taken to determine the status and effectiveness of the

Activities Performed common feature.

Measurement and Analysis Examples

· "Measurements are defined, collected, and analyzed to provide insight into the

performance of the 〈 status, effectiveness, etc . 〉 of 〈 X〉 activities."

一 "Examples of measurements include:…”


Verifying Implementation

verifying implementation describes the steps to ensure that the activities are performed in

compliance with the process that has been established. Verifying implementation

typically includes:

· Verification of activities.

· Verification of work products

· Senior management

· Project management. 17

Verifying Implementation Examples

· "The activities for 〈 X〉 are reviewed with senior management on a periodic

basis."

· "The activities for 〈 X〉 are reviewed with the project manager periodically and

as needed.”

Key Practices

· key practices state the fundamental policies, procedures, needs, and activities for a

key process area.

· Describe "what" is to be done, but they should not be interpreted as mandating

"how."

· Organize key practices by common features.

18

Module II Summary

Upon completion of Module II, CMM Overview, the participant will be able to:

· Recognize the five maturity levels and the key process areas associated with each

level.

· Describe how performance relates to, but is different from, capability.

· Explain how the CMM is structured.

Points to Remember

· The CMM focuses on software management issues.

· Visibility into the process depends on the maturity of the process-

· The CMM is a five--level model and the levels are broken into key process areas.

· Each level builds on the capability of the previous level.

Module 3 CMM Level 2

19

Module III-CMM Level 2

Objectives

Upon completion of Module III,CMM Level2,the participant will be able to:

· Name the key process areas at the Repeatable Level.

· Describe the purpose of each of the key process areas.

· Explain the terminology associated with each of the key process areas.

· Understand the key practices of Level 2.

20

21

22

23

Requirements Management (cont.)

Requirements Must Be Documented

The requirements assigned to software engineering must be documented.

This can be as simple as a memo or as elaborate as multi-volume specifications. If

requirements change, the changes must be documented and all resulting necessary

changes in other documents must be tracked and verified throughout the life cycle.

24

25

26

Software Project Planning (cont.)

Plans Are Based on Estimates

In creating estimates for size, effort, cost, schedule ,and/or computer resources:

.Use historical data, when available.

.Document assumptions and estimates.

Good estimating depends on the skills and judgment of the estimator.

Software Project Planning (cont.)

Meeting Commitments

Commitment is a pact that is freely assumed, visible, and expedited to be kept by all

parties.

.Commitment is necessary to achieve plans.

.Feasible commitments are made when plans are realistic.

.Commitment is a process.

27

Software Project Tracking and Oversight (cont.)

Manage to a Plan

Progress must be tracked against plans and specifications, including:

.Product size.

.Project effort, cost, and schedule.

.Activities.

.Risks.

Mechanisms to track progress against plans include both internal reviews and formal

reviews with the customer.

Software Project Tracking and Oversight (cont.)

Taking Corrective Action

If and when discrepancies between plans and actual progress occur, a judgment must be

28

made about whether to:

.Change the way the work is being done.

or

.Adjust the plans.

This judgment results in corrective action.

Archives of original and adjusted plans should be kept.

Software Subcontract Management

Purpose :

To select qualified software subcontractors and manage them effectively.

Involves:

.Selecting a software subcontractor

.Establishing commitments with the subcontractor

.Tracking and reviewing the subcontractor's performance and results

Goals:

1.The prime contractor selects qualified software subcontractors.

2.The prime contractor and the software subcontractor agree to their commitments to

each other.

3.The prime contractor and the software subcontractor maintain ongoing

communications.

4. .The prime contractor tracks the software subcontractor’s actual results and

performance against its commitments.

29

Software Subcontract Management(cont.)

Selecting Subcontractors

The qualifications of a subcontractor may depend on many factors, such as:

.Process capability.

.Software engineering expertise.

.Application domain knowledge.

.Strategic business alliances.

.company policy or edict.

Software Subcontract Management (cont.)

Managing a Subcontract

The prime contractor must manage the subcontract.

.Ensuring subcontractors follow software development plans, standards, and procedures

.Tracking progress via:

30

一 Periodic technical and formal reviews

一 Monitoring performance against the plan

一 Monitoring Software Quality Assurance by the subcontractor

一 Monitoring Software Configuration Management by the subcontractor

Software Quality Assurance (cont.)

Role of QA

The ro1e of QA is that it provides an independent view of progress-both of process and

Product.

QA serves as the compliance function for management.

Most key process areas contain QA activities in Verifying Implementation.

31

Software Quality Assurance (cont.)

QA Evolves at Higher Maturity Levels

Proactive QA functions as a value-adding member of the project team.

.QA starts early in the project.

.QA helps prepare and review procedures, plans, and standards.

.At higher levels, the CMM provides flexibility for QA to function proactive1y to drive

improvements in the software process and product.

32

Using Baselines

CM relies on baselining software work products.A baseline is a specification or

product that:

.Has been formally reviewed and agreed on.

.Serves as the basis for further work.

.Can be changed only through formal change control procedures (which leads to a new

baseline).

Controlling Change

CM provides a stable working environment.

Uncontrolled change of software work products is a chaotic process.

33

CM provides a "memory" of the status of software work products via baselines.

When many individuals are working on the same product, CM coordinates access to and

change of the software work products.

Baseline versus Developmental Configuration Management

In baseline CM, baselines for identified software work products are established at

predetermined points.

In developmental CM, configuration control is exercised by the developers as they

perform their work.

The CM key process area can be satisfied with baseline configuration management.

34

Managed and Controlled

Some software work products do not need the formality of configuration management,

but do need to be placed under some form of:

.Version control.

.Change control.

This is referred to as "managed and controlled” in the key practices.

Exercise 3.1

Instructions

Each group should prepare a 3-minute presentation.

Option 1

· KPA (one of Level2 KPAs)

· Current status/problems with KPA with respect to your environment

· Improvement goals

· How will you measure progress?

· Action plan 35

Modulle III Summary

Upon completion of Module III,CMM Level2, the participant will be able to:

.Name the key process areas at the Repeatable Level.

.Describe the purpose of each of the key process areas.

.Explain the terminology associated with each of the key process areas.

Points to Remember

.Focus is on projects rather than the organization.

Module 4 CMM Level 3

36

Module IV-CMM Level 3

Objectives

Upon completion of Module IV, CMM Level3,the participant will be able to:

· Name the key process areas at the Defined Level.

· Describe the purpose of each of the key process areas.

· Explain the key practices of CMM Level 3.

37

38

Relation to Organization Process Definition

· Organization Process Focus and Organization Process Definition are tightly coupled.

· Organization process Focus focuses on the who.

· Organization Process Definition focuses on the what.

39

Tailoring Guidelines: How to Use the Organization's Set of Standard

Software Process

Guidelines for tailoring the organization's set of standard software process are available

to individual projects.

.What can be tailored out? What cannot?

.How much can a process element be modified?

40

.What parts of a process element should be considered for tailoring?

41

Organizational Training

Organizational training needs are identified based on the:

.Organization's Set of Standard Software Process (OSSP).

.Project needs.

.Support group needs.

.Individual needs .

42

43

44

45

46

47

48

49

Level 3 Barriers and Accelerators

Barriers

.

Accelerators

50

51

52

53

54

55

56

57

58

59

60

61

62

63

1.Interviews (cont.)

Question examples

-How do you (plan /track/measure /make changes to)X?

-How does X get (audited /reviewed by management /tested)?

-What are the (inputs /outputs/impacts/dependencies)of X ?

-When do you X?

-Who (is responsible for /performs) X?

-What (type of/causes /triggers /is in )X?

-How many /How often?

-Could you please describe X?

-Is there anyone else I should ask about this?

64

-Do you have any questions you would like to ask us?

-Is there any thing we missed?

-Is there anything you feel we did not understand?

-Is there anything we did not let you complete?

65

Final Findings

-Scope of assessment

-Overview of assessment

-Capability maturity model

-Findings

· Overview

· Global finding

· KPA findings

· Non-CMM findings

-Ratings

· Definitions

· KPA profile

-Next steps

66

6.NEXT STEPS

-Final Report (within 6weeks)

· Executive summary

· Organization status overview

· Findings and consequences

· Recommendations

· Next steps

-Diagnosing and Process Improvement

-Action Plan

67