Amoco: Introduction to the SEI`s CMM

G

S

T

Manufactures’ Association for

Information Technology (MAIT)

Introduction to the Software Engineering Institute’s (SEI) Capability Maturity Model (CMM)

Global Systems Technology, Inc. © 1997, 1998

1

G

S

T

Global Systems Technology, Inc.

Introduction to the

Software Engineering Institute’s (SEI)

Capability Maturity Model (CMM)

“Improving

what

you build means improving

how

you build”

The SEI is a Federally Funded Research and Development Center Located at

Carnegie Mellon University in Pittsburgh, Pennsylvania



2

G

S

T


Course Overview

 Introduction: An Executive Overview of the CMM (6 Hrs)

 Level 2: Understanding the Repeatable Level KPAs (5 Hrs)

 Level 3: Understanding the Defined Level KPAs (6 Hrs)

 Level 4: Understanding the Managed Level KPAs (2 Hrs)

 Level 5: Understanding the Optimizing Level KPAs (3 Hrs)

 CMM Summary and Test (2 Hrs)



3

G

S

T


Course Guidelines











The Class schedule will be followed.

The Class will start at 9:30 and end at 5:30 promptly.

One break in the morning, one in the afternoon.

Course is fast paced, but questions are welcome.

Exercises and test will be given, and results provided to

SEI CMM site training coordinator.



4

G

S

T


Day

1

Executive

Overview

Course Schedule

Morning Afternoon

Executive

Overview

Executive

Overview

APA

Level 2 Level 3 Level 3 Level 3

Day

2

Level 4 Level 4/5 Level 5

Summary

And Test

Day

3



5

G

S

T


Day One: Executive Overview

















Understand the origins of the CMM and the underlying need

Understand the difference between the CMM and ISO 9000

Recognize the Benefits of CMM based software process improvements

Be able to describe the CMM and how it is organized

Understand management’s commitments in CMM based software process Improvement

Be able to describe the CMM and how it is organized

Understand the elements necessary for successful software process improvement

Results of the Abbreviated Process Assessment



6

G

S

T


Evolution of the CMM

For Software



7

G

S

T


Cobb’s Paradox

“We know why projects fail, we know how to prevent their failure....so why do they still fail?”

Martin Cobb

Treasury Board of Canada Secretariat

Ottawa, Canada



8

G

S

T


The Need for Better Planning and Managing









For every 100 IT projects started, 94 are “restarted”

Average IT project cost overrun is 178% in large companies

Average IT project time overrun is 230% in large companies

42% of original features proposed of IT projects in large companies actually get ported in the final product

This information and the following statistics are the result of an extensive national (United States) survey conducted by the Standish Group.

Respondents were IT Executives.



9

G

S

T


Project Success Profiles

 The reasons projects succeed:

• User Involvement

• Executive Management Support (Active interest)

• Clear Statement of Requirements

• Proper Planning

• Realistic Expectations

• Smaller Project Milestones (Visibility)

• Competent Staff

• Ownership

• Clear Vision and Objectives

• Risk Planning, Identification and Mitigation



10

G

S

T


Project Obstacles Profiles

 The reasons projects are challenged:

• Lack of User Input

• Incomplete Requirements and Specifications

• Changing Requirements and Specifications

• Lack of Executive Support

• Technical Incompetence

• Lack of Resources

• Unrealistic Expectations

• Unclear Objectives

• New Technology

• Team Commitment



11

G

S

T


Project Failure Profiles

The reasons projects are impaired and canceled:

















Incomplete Requirements

Lack of User Involvement

Lack of Resources

Unrealistic Expectations

Lack of Executive Support

Changing Requirements

Lack of Planning

Obsolete before it is complete













Lack of IT Management

Oversight

Technology Illiteracy

Does not solve business problem

Unrealistic schedule requirements

Lack of Program

Management training

Poor Estimating



12

G

S

T


Industry IT Project Facts: 1995

 31.1 % of all projects were canceled before they are completed.

 52.7% of projects cost 189% of their original estimates

 The cost for IT projects in American Companies and in the government that were canceled before implementation in 1995 is estimated at $81 billion dollars.

 The cost of overruns for the same period (in addition to canceled projects) is estimated at $59 billion .



13

G

S

T


More Industry Project Facts

 Lost opportunities cost is not measurable, but could be in the trillions of dollars. Remember Denver; the cost of not having the baggage system working was costing the City of Denver

$1.1 million dollars a day.

 Only 9% of projects in large companies come in on budget and on schedule.



14

G

S

T


Industry Project Success Criteria

SUCCESS CRITERIA POINTS

•

•

•

•

• User Involvement

• Executive Management Support

• Clear Statement of Requirements

• Proper Planning

Realistic Expectations

• Smaller Project Involvement

• Competent Staff

Ownership

Clear Vision and Objectives

Hard-Working and Focused Staff

19

16

15

11

10

09

08

06

03

03

100



15

G

S

T













Conditions described were worse in the 1960s and 1970s.

GAO (US Government Accounting Office) study in 1983 showed that only 3% of the software being delivered to the Government was usable on delivery; that 49% was never usable; and that

48% needed modification prior to use.

In the early 1980s, the Government created a Federally Funded

Research and Development Center at Carnegie Mellon

University, The Software Engineering Institute.

Objective was to reduce the Government’s exposure to software development and maintenance risk.

TQM was in full swing in the manufacturing environment.



16

G

S

T



S/W Engineering Sciences

TQM PRINCIPLES

Maturing 1940s-1980s

DOD Standards Development: Mil-S-482, 483, 1679,

2167, 498 (Also: 52779, 2168)

Commercial Standards: IEEE 498, 12207

ISO Standards: 12207

Commercial Practices of S/W Organizations

ISO 9000 Series (Commercial)

ASQC Tech-notes

DOD Standards (Mil Q 9858A)

SHEWART (1920s)

DEMMING (1950s)

ISHIKAWA (1940s)

JURAN (1960s)

CROSBY(1970s)

ADAPTATION OF

QUALITY

MANAGEMENT

MATURITY GRID

TO SOFTWARE

DOMAIN

DEFINITION OF

THE FIVE LEVELS

OF SOFTWARE

PROCESS

MATURITY IN THE

CMM

FRAMEWORK

SEI/1987-1993

QUALITY

MANAGEMENT

MATURITY GRID

P. CROSBY/1979

W. HUMPHREY

IBM/1985



CMM

For

Software

(Model)

17

G

S

T



 SEI, formed in 1984, began an examination of organizations that were recognized for producing high quality software products that were delivered on-time and within budget.

 Approximately 87 organizations were identified and examined, some of which were excluded from the study.

 The processes used by the remaining organizations were examined and the most common practices were then cataloged as the Key Practices and grouped into Key Process Areas (KPAs).

 The KPAs were grouped into levels of capability. The maturity levels were derived from TQM literature and applied to software.



18

G

S

T



 The organizations had applied their good business practices to the development of software.



The KPAs, in aggregate, represent “good business” practices that have been defined in the context of a software development environment.



19

G

S

T


Definition of Software Process

Procedures and methods defining the relationship of tasks

Process

People with skills, training and motivation

Tools and equipment



20

G

S

T


TQM CMM

Assumes processes are mature

Expects processes to be institutionalized

Expects processes to be immature

Recognizes the benefit of quantitative measures in process management and change

Builds foundation so

TQM can be applied



21

G

S

T


Applying TQM to Software

Organization

TQM

Project A Project B

Project C

Software

Hardware

Project D

The CMM is a model for software process that embodies the principles of TQM

System

CMM

TQM fits in an overall business context - the Capability Maturity

Model (CMM) applies specifically to software.



22

G

S

T


Points in Common with the Quality Movement

 Improvement focuses on fixing the process, not on blaming the people.

 Improvement must be measured and periodically reinforced

 Improvement requires consistency of investment, training and effort to search for new opportunities to improve

 Improvement is a continuous process.

 If level of discomfort is not high enough (i.e., market share, time-to-market, competitive posture, number of fielded defects, etc., are acceptable to the organization) things will not change.



23

G

S

T


How Does Your Customer Benefit?

 Confidence in you, the product/service provider

 On-time delivery of your products and services

 Reduced costs of your software development activities

 Acceleration of your work accomplishments

 Improvement in your product service quality

 Ability to better plan their business activities due to the overall reduced risk in doing business with



24

G

S

T


What’s in it for the Employee

?

 Less overtime required to get the job done

 Improved customer relations and customer satisfaction



Enhanced “team” working environment within the organization, where you can depend on everyone

 Improved personal performance as you have a shorter learning curve, can benefit from others’ experiences

 Enhanced professional skills, defined methods and processes, and availability of training



25

G

S

T


How Does the Organization Benefit?

 Improved customer relations results in additional work, and better communications

 Recognition of products from customers

 Satisfied employees resulting in best efforts and retention

 Better response and less business risk in meeting client needs

 Improved quality and productivity of services and products provided resulting in improved competitiveness, market share increase

Increased Market Share! Increased Efficiency! Improved Profitability!



26

G

S

T


Quality

Benefits of Using CMM Model

Productivity

52% Decrease in

Product Errors

CMM Level

......1..... .....2..... .....3..... .....4..... .....5.....

Time to Market

34% Decrease in

Cost to Develop

CMM Level

......1..... .....2..... .....3..... .....4..... .....5.....

Risk

15% Decrease in

Time to Deliver

Significant Reduction in Development Risk

CMM Level

......1..... .....2..... .....3..... .....4..... .....5.....

CMM Level

......1..... .....2..... .....3..... .....4..... .....5.....



27

G

S

T


Improvement

Category

Improvements Using the CMM

Measurement

Cost

Sc hed ule

O ther

1 .

Defe cts

2 .

Error Rate

3 .

Pro duc t

4 .

Error

5 .

$ Save d

6 .

Cos ts

7 .

Savi ngs

8 .

ng s

9 .

Wi thi n

1 0 .

me De liv ery

1 1 .

Proj e c

1 2 .

Sa v i

50% Aver age

45% Aver age

KSL OC

80% Sa vin gs

50%

+ or – 5% Ave rag e

15% Aver age

1 3 .

Rework

1 4 .

Sa v i



28

G

S

T


Maturity Levels in Review (Predictability)

Level Characteristics Predicted Performance

Optimizing

4

5

Managed

Process Improvement is institutionalized

Product and process are quantitatively controlled

Quality/Schedule/Cost


2

1

Software engineering and management processes defined and integrated

Project management system in place; performance is repeatable

Process is informal and ad hoc; performance is unpredictable






29

4

3

2

G

S

T


Maturity Levels In Review (Visibility)

1



30

G

S

T


Maturity Levels In Review (Visibility)

5



31

G

S

T


What Are the

Risks

of Model-Based

Improvements?

 Models are simplifications of the real world

 Models are not comprehensive

 Interpretation and tailoring must be aligned to business objectives

 Judgment is necessary to use models correctly and with insight



32

G

S

T


What the CMM Does Not Cover

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

Not included:

• User Needs

Analysis

• Requirements

Definition

• System

Requirements

• System Design

• Risk

Management

The CMM focuses on Software

Engineering through:

Software Requirements

Software Design

Code and Unit Test

Integration Test

Software Test

Not included:

• Systems Testing

• Implementation

Support

• Customer

Support

• User Training



33

G

S

T


The CMM Focuses on Software

Development Issues

 Issues addressed only indirectly, or by implication, include:

• specific tools, methods, and technologies

• concurrent engineering, Joint Application Development and teamwork

• system engineering, marketing, testing, delivery

• human resources

• organizational behavior



34

G

S

T

Capability Versus Performance

 Process capability - the range of expected results that can be achieved by following a process, initially established at the organization level. A predictor of future project outcomes.

 Process performance - a measure of the actual results achieved from following a process. Refers to a particular project in the organization



35

G

S

T


But I have ISO, so why do I need the CMM?

“In today’s competitive marketplace, ISO 9000 registration is becoming a requirement for doing business in many industries. To remain competitive, companies need to go beyond that.” Quality Digest

The CMM practices focuses on competitiveness and emphasize the business objectives, bottom line performance, employee satisfaction and development, and supplier and partner performance.



36

G

S

T


How ISO and the CMM Differ

ISO













Prescriptive

Standard - Organizations must comply

Identifies what “must” be done and by whom

Looks at process existence, execution not at

“goodness”

Requires process improvement activities

Focused on Quality

Management System

CMM













Descriptive

Model - Must be tailored to organization’s business environment

Describes successful software development practices

Expects processes to “make sense” to organization

Focused process improvement of business practices

Requires tailoring of process to project needs



37

G

S

T


How ISO and the CMM Differ

RM SPP SPTO SSM SQA SCM OPF OPD TP ISM SPE IC PR QPM SQM DP TCM PCM Coverage

AREAS

10%

AREAS COVERED BY

ISO 9001/9000-3

PARTIALLY

COVERED

20%

30%

40%

50%

60%

70%

80%

AREAS NOT COVERED BY

ISO 9001/9000-3

90%

100%



38

G

S

T


(After ISO)

ISO and the CMM share the same

Organizational constraints,

Both must be adapted to those constraints.

Enterprise

(Before ISO)

ISO, as a standard, requires the

Organization to conform. The

Organization may need to expand activities to cover the ISO requirements.

(After CMM)

CMM for Software

Coverage and

Applicability

CMM , as a model, is used to understand and evolve within the

Organization constraints. Blind compliance without a reasonable interpretation and use of professional judgement may mislead the Organization.

ISO 9000

(9000-3)

Coverage and

Applicability



39

G

S

T


Models are simplified views of the real world

THE REAL WORLD

Integrated Product Teams

Organization Culture

System Engineering

People Issues

Technology

Marketing

Procedures, templates, models, tool usage, and forms, are below the level of detail within the

CMM

The capability maturity model for software



40

G

S

T


So, What is the CMM?

 The CMM is a model that describes software development practices that are recognized as critical to success for software development efforts within state of the practice organizations.



The CMM describes “what” activities are necessary for success.

(It is Descriptive)



The CMM does not describe “how” the activities are to be performed. (It is Not Prescriptive)

 Your organization procedures (QMS) describes how activities are to be performed.



41

G

S

T


Common Sense Issues

 The CMM is a model.

A reasonable interpretation of the CMM practices and professional judgment in application is necessary.

 The CMM was written to address the process for large, complex software efforts.

 Early efforts in tailoring the CMM indicate that in excess of 90% of key practices are applicable as written when interpreted in the context of the specific applications for both large and small organizations.



42

G

S

T


The Model:

SEI’s CMM

Understanding the model structure



43

G

S

T


Maturity Levels Provide an Orderly Path for SPI





Process capability is built in stages

• This does not imply a ladder - some processes are ineffective when others are not stable

Each level provides a foundation for improvements at the next level

• engineering process is easily sacrificed without management discipline

• detailed measures are inconsistent without a defined process

• effect of process innovation is obscure in a noisy process



44

G

S

T


• The Capability Maturity Model is defined in levels of process maturity.

• The levels do not imply a “ladder”.

• Each level consists of a grouping of homogeneous key process areas (KPAs).

• The relationship is such that the most benefit from a

KPA can only be achieved when KPAs from lower levels are in place.

• The KPAs in each level enhance the effectiveness of the previous maturity level KPAs while strengthening the foundation for further process maturity growth.



45

G

S

T


Summary Characteristics of Organizations at Different Levels of

Process Maturity

5

Optimizing (process/product data used for strategic business improvement)

4

Managed (quantitative process and software quality management in place)

3

Defined (same processes used across the organization)

2

Repeatable (repeatable processes documented and used)

1

Ad hoc or chaotic (repeatable processes not documented and not used)



46

1

G

S

T


2

4

5

• Defect Prevention

• Technology Change Management

• Process Change Management

• Quantitative Process Management

• Software Quality Management

3

• Organization Process Focus

• Organization Process Definition

• Training program

• Integrated Software Management

• Software Product Engineering

• Intergroup Coordination

• Peer Reviews

• Requirements Management

• Project Planning

• Project Tracking & Oversight

• Subcontract Management

• Software Quality Assurance

• Configuration Management

• No Key Process Areas



47

G

S

T


CMM Structure

Level 2 Level 3

CMM V1.1

Level 4 Level 5

A Total of 18 Key Process Areas (KPAs) each with established goals

Key Process Areas are organized by Common Features

Commitment to Perform

Ability to Perform

Activities

Performed

Measurement and Analysis

Verifying

Implementation

Each of the KPAs are organized by common features that contain key practices

A Total of 316 Key Practices in CMM V1.1



48

G

S

T


Conceptual Organization CMM

Level 2 Level 3 Level 4 Level 5

Common Features

• Commitment and

• Ability

Organizational Infrastructure and

Management Support

• Activities Work Accomplished

• Measurements and

• Verification

Management Visibility and Oversight

316 Key Practices making up the 18 KPAs



49

G

S

T


Strategic

Business

Plan

Directives

Policy

Allocation of

Resources

Evaluate, Redefine Goals

Defect

Prevention

Organization

Management

Process

Definitions

Training

Procedures

Std.

Practices

Functional

Management

Issue

Resolution

Defect

Prevention

Organization

Management

Reviews

Group

Management

Reviews

Customer Requirements, Regulatory

Environment, Constraints, Customer

Direction, Competition, etc.

Client Management

Adapt/Tailor Procedures to Specific Project Needs;

Project Specific Training

Project

Management

Project Work

Instructions

Defect

Prevention

Issue

Resolution



Project

Management

Reviews

50

G

S

T




Understanding Commitment

Commitment to Perform: describes the actions the organization must take to ensure that the process is established and will endure.

Commitment

Written Organization Policy

Designated Responsibility

Sr. Mgmt Sponsors Activities

Sr. Mgmt Oversees Activities

  





 



Why are there two “written policy Statements” for two KPAs?



51

G

S

T




Understanding Ability to Perform

Ability to Perform: describes the preconditions that must exist in the project or organization to implement the software process competently.

Ability

Responsibility Established-Assigned

         

Documentation of Artifacts-Procedures

  

Adequate Funding, Resources

Trained to Perform Tasks

Orientation for Project Members

Support tools are compatible

Support for collecting, recording, and

Analyzing measurements (data)

                 

           

       



 



Data is Available to support analysis



52

G

S

T




Understanding Measurement and Analysis

Measurement and Analysis: describes the basic measurement practices necessary to determine status related to process being performed.

Measurement

Measurements Used to Determine Status

Measurements Used to Determine Quality

Measurements Used to Determine

Effectiveness

        





       



What is Different with the Quality Measurement ?

Why do two KPAs have a Separate Measurement for Quality?

What is different about the Training KPA?



53

G

S

T




Understanding Verifying Implementation

Verifying Implementation: describes the steps to ensure that the activities are performed in compliance with the processes that have been established.

Verifying Implementation

Senior Management Reviews

               

Project Manager Reviews

Quality Assurance Reviews

And/or Audits

     

   

     

          

Independent (Expert) Review

Activities are Reviewed and/or

Audited

 



SCM Audits Software Baselines



Why does Training not have a Quality Review or Audit called out?



54

G

S

T


Relationships of CMM Elements

Indicate

Maturity

Levels

Process Capability

Contain

Key Process

Areas

Achieve

Goals

Organized By

Common

Features

Address Contain

Institutionalization

Describe

Key

Practices

Activities



55

G

S

T


Indicate

Process Capability

Contain

Relationships of CMM Elements

Quiz

Achieve Organized By

Address Contain

Institutionalization

Describe

Fill in Blanks

Activities



56

G

S

T


Characteristics of Organizations at

Different Levels of Process

Maturity



57

G

S

T


Key Process Areas of each Level

Repeatable (2)

• Requirements

Management

• Project Planning

• Project Tracking and Oversight

• Subcontract

Management

• Software Quality

Assurance

• Configuration

Management

Defined (3)

• Organization

Process Focus

• Organizational

Process Definition

• Training program

• Integrated

Software

Management

• Software Product

Engineering

• Intergroup

Coordination

• Peer Reviews

Managed (4)

• Quantitative

Process

Management

• Software Quality

Management

Optimizing (5)

• Defect Prevention

• Process Change

Management

• Technology

Change

Management



58

G

S

T


Process Characteristics of CMM Levels

Repeatable (2)

•

Project level

•

Documented and stable

•

Estimating, planning, and commitment

• Problems recognized and corrected

Defined (3)

•

Organizational

•

Integrated management and engineering processes

•

Problems are anticipated and prevented, or

•

Impact of problem is minimized

Managed (4)

•

Processes are quantitatively understood and stabilized

•

Sources of individual problems are understood and eliminated



Optimizing (5)

•

Processes are continuously and systematically improved

•

Common sources of problems are understood and eliminated

59

G

S

T


People Characteristics of CMM Levels

Repeatable (2)

•

Success depends on individuals

• Management systems supports

•

Commitments are understood

• People are trained

Defined (3)

•

Project groups work together

•

Work as integrated team

• Training is planned and provided according to roles

Managed (4)

•

Strong sense of teamwork exists within each project

Optimizing (5)

•

Strong sense of teamwork across the organization

• Everyone is involved in process improvement



60

G

S

T


Technology Characteristics of CMM Levels

Repeatable (2)

•

Technology supports established, stable activities

Defined (3)

•

New technologies are evaluated on a qualitative basis

Managed (4)

•

New technologies are evaluated on a quantitative basis

Optimizing (5)

•

New technologies are pro-actively pursued and deployed



61

G

S

T


Measurement Characteristics of CMM Levels

Repeatable (2)

•

Planning and management data used by individual projects

Defined (3)

•

Data are collected and used in all defined processes

•

Data are systematically shared across projects

Managed (4)

•

Data definition and collection are standardized across the organization

•

Data are used to understand the process quantitatively

Optimizing (5)

•

Data are used to evaluate and select process improvements



62

G

S

T


P & P

Projects

P & P

SEPG Analysis

Organization

Policy and

Procedures

P & P

P & P

Best

Practice

P & P

Organizationwide

Implementation

Level 2

P & P

Level 3



63

G

S

T


Level 3 Level 4

Errors/10K Loc.

Planned Actual

Policy and

Procedures

Organization

Implementation

4 0

3 5

3 0

2 5

2 0

1 5

1 0

5

0 A B C D

Products

Change

As

Required

Level 5

Organization

Strategic

Business

Goals

Today

Overrun

Task A

Task B

Task C

1st

Qtr

Planned

2nd

Qtr

Actual

3rd

Qtr

4th

Qtr

Estimate

Change by Prevention, Technology, and Improvement

Quantitative Understanding of

Product and Process Capability



64

G

S

T


WHAT THREE WAYS CAN THE CMM

CAN BE USED?



65

G

S

T


The Three Uses of the CMM







Process Development: Used as a model for determining desired practices for reducing project risk.

Process Improvement: Used as a model to assess current project practices for improvement.

Vendor Selection: Used as a basis for determining risk of potential software contractors.

Caution!

The CMM is only a model. A tool. It is not the solution. It is not a silver bullet.



66

G

S

T


Process Development









List all processes that are thought to be appropriate for the enterprise activities.

Examine the CMM to understand the processes described and to compare to “list” of enterprise processes. Determine the applicability of CMM processes to organization. Adjust list as necessary.

Using the list as a foundation, define processes in the context of how to perform them. Pick a project for implementation.

Review process definitions and tailor to project needs, implement the tailored processes on the project. Measure and analyze results.

Caution!

The CMM is not all inclusive, includes only “Key

Practices” . You are the judge as to “Key” for your organization.



67

G

S

T


Process Improvement (CBAIPI)









Use the CMM as a basis for evaluation of the organizations processes by comparing the organization’s processes to the

CMM key practices.

During the organization evaluation, identify what is done well and what is not done well. Identify the strengths and weaknesses of the practices using the CMM comparison, and taking into account the alternative practices.

Using the comparison, and evaluating alternative methods, determine the satisfaction of the different KPA goals.

This provides you with a clear understanding of process strengths and weaknesses and the consequences as determined by goal satisfaction.

Caution!

The satisfaction of goals is the objective



68

G

S

T


Vendor Selection (SCE)







Use the CMM as a basis for evaluating a subcontractor, or a potential development partner using your team of experts.

Follow the same process that would be used for an internal assessment.

Using a goals satisfaction matrix, and process strengths and weaknesses, establish risk of software development by the organization being evaluated. Risk should be measured relative to the scope of the organization evaluated.

Caution!

The SCE can establish a maturity rating for the scope of the evaluation. The major difference is that the SCE provides no

“lasting knowledge” of the problems.



69

G

S

T




Building the Culture for Improvement

Continuous Software Process Improvement (SPI) requires the consistent oversight of management. Conduct regular review meetings to assess the activities.

 When the improvement plan is finalized and approved by management and the team chosen to accomplish the planned objectives. Management should follow through with the necessary resources. Ensure that adequate hours are allocated and budgeted for the improvement activity.

 Participate (randomly) in the Software Engineering Process Groups meetings. This not only indicates that management is interested, but any problems can be detected early in the improvement cycle. Visible management support for the improvement activity encourages the organization to support the activities.



70

G

S

T


Establishing a Software Process Engineering

Group (SEPG)

 An organization is most successful in achieving software process improvement when there is a “focus” group that has the responsibility, accountability, and authority to cause software process improvement.

• The group that is selected should be comprised of individuals that are perceived very well by their peers.

•

These individuals should be recognized as knowledgeable in their field.

• The group should be comprised of both technicians and project management personnel.

•

The group should have representation of the key disciplines that are used in the organization.

• The group should be chartered by senior management.



71

G

S

T



Group (SEPG) (Cont.)

 Before the group is selected, a charter for the group should be written that clearly defines the groups authority, responsibility, and accountability.

• The charter should define the group members by workgroup representation.

•

The charter should spell out what is expected of the group. This should specifically address their authority to request other members of the organization for support.

• The charter should identify, in broad terms, the schedule and the resources that management has made available.

• Only when the charter is complete should management select their improvement group.



72

G

S

T



Group (SEPG) (Cont.)

 When the charter is written and has management consensus, the team is formed. The charter should be consistent with the organizations overall business goals and objectives.

• The first order of business for the team is to organize into an effective group and develop a plan to accomplish the objectives of the charter.

•

The plan that is produced should support the boundaries established by the charter. If there is differences, this must be resolved with management prior to initiating the plan.

• The team should treat the program like any other project. They have requirements established by the charter. The team’s function is to build the process infrastructure, or improve the structure that is in place in accordance with their requirements.

•

The team should report progress to management on a periodic basis, and should report cost, schedule, and progress for management review.



73

G

S

T


GST Assessment and Evaluation Process

Planning Management

Briefing

Participants

Brief

Final

Report

Schedule

Coordination

APA

Administer

Questionnaire

Document

Review

Action

Plan

CMM

Training

PL, Mid-Mgmt.,

FAR Interviews

Preliminary

Findings

Milestone

Tracking

Team

Training

Pre-Assessment

Final

Findings

Presentation

Exit

Briefing

Implement

Improvement

On-Site Assessment

Post-Assessment



74

G

S

T


GST

Proposal

GST/

Client

Contract

APA

Report

GST

Exclusive

GST Assessment Document Flow

CBAIPI Forms

Completed

Assessment

Evaluation Forms

CMM

Training

Documents

Team

Training

MQ Quest

Final

Report

CBAIPI

Plan

MQ Analysis

Doc Analysis

Project

Analysis

F

O

R

M

S

S

U

P

P

O

R

T

PAIS Document

Interview

GST

Exclusive

CBAIPI

Workbook

Draft Finding

Final

Findings

CBAIPI

Schedule

SEI

Package

GST

Exclusive



75

G

S

T


AN

ORGANIZATIONAL

VIEW OF THE CMM

EMPOWER

ORGANIZATION MANAGEMENT

1. DEFECT PREVENTION

2. TECHNOLOGY CHANGE

MANAGEMENT

3. PROCESS CHANGE MANAGEMENT

IMPROVE

4. ORGANIZATION PROCESS FOCUS

5. ORGANIZATION PROCESS

DEFINITION

6. TRAINING PROGRAM

ANALYZE

PROJECT MANAGEMENT

1. REQUIREMENTS MANAGEMENT

2. PROJECT PLANNING

3. PROJECT TRACKING AND OVERSIGHT

4. SUBCONTRACT MANAGEMENT

5.QUANTITATIVE PROCESS MANAGEMENT

PRODUCT ASSURANCE

1. SOFTWARE QUALITY ASSURANCE

2. SOFTWARE CONFIGURATION

MANAGEMENT

3.SOFTWARE QUALITY MANAGEMENT

ENGINEERING/DEVELOPMENT EVALUATE

EMPLOY 1. SOFTWARE PRODUCT ENGINEERING

2. PEER REVIEWS

3. INTERGROUP COORDINATION

4. INTEGRATED SOFTWARE

MANAGEMENT



76

G

S

T


PROCESS IMPROVEMENT,

EVEN WITH THE CMM,

IS NOT A SIMPLE TASK



77

G

S

T


A Model for the Process of Improvement

Management

Responsibility

MATURITY

GROWTH

MODEL

MEASURE PROCESS

DETERMINE MATURITY

(ASSESS/CBA-IPI)

ESTABLISH GOALS

OF ORGANIZATION

(CHARTER)

MANAGEMENT

IMPROVEMENT

OVERSIGHT

(REVIEW/APA)

MATURITY GROWTH

CYCLE ESTABLISH PLAN

FOR IMPROVEMENTS

(SEPG PLAN)

SEPG

Responsibility

COMPARE RESULTS

TO GOALS; REFINE

(OPTIMIZE)

MAKE CHANGES TO

EXISTING PROCESS

(IMPROVE)

EVALUATE AND

MEASURE CHANGES

(ANALYZE)

SOFTWARE PROCESS

IMPROVEMENT

CYCLE TRAIN EMPLOYEES IN

NEW PROCESS

(INSTITUTIONALIZE)



78

G

S

T


Challenges of Change

“There is nothing more difficult to plan, more doubtful of success, nor more dangerous to manage than the creation of a new order of things.......

Whenever his enemies have occasion to attack the innovator, they do so with the passion of partisans, while others defend him sluggishly so that the innovator and his party alike are vulnerable.”

NICCOLO MACHIAVELLI

The Prince



79

G

S

T


Organizations are Complex Systems

Strategic

Technical

Managerial

Social/

Cultural

Structural



80

G

S

T


Software Organizations Resist Change

Software organizations undergoing process transition activities tend to focus on the technology rather than on the problems they are attempting to resolve.

Technical

Strategic

Social/

Cultural

Managerial

Structural



81

G

S

T


Software organizations tend to overlook systemic organizational issues like planning, training, and the preparation for supporting organizational processes

Organizational Issues are Overlooked

Technical

Strategic

Social/

Cultural

Managerial

Structural

It is this characteristic of software organizations that make higher levels of process maturity so difficult to achieve.



82

G

S

T


The systemic attributes of the organization become dysfunctional when changes are not anticipated, properly planned, and coordinated.

Technical

Systemic Problems

Occur

Strategic Managerial Structural

Social/

Cultural



83

G

S

T


Organizations are Complex Systems

Strategic

Technical

Managerial

Social/

Cultural

Structural



84

G

S

T

PRODUCTIVITY


Managing the SPI Transition

The Ideal: Directed Change

DESIRED STATE

PRESENT

STATE

Rapid

Change

INFRASTRUCTURE

TIME



85

G

S

T


Managing the SPI Transition

The Alternative: Evolving Change

DESIRED STATE

PRESENT

STATE

Evolution: a State of

Transition

Adapting

Implementation

PRODUCTIVITY

Reviewing and

Undoing

Goal Setting and Defining

Training and

Institutionalizing

INFRASTRUCTURE

TIME



86

G

S

T




Early Majority



Pragmatists

Adopters of Change



Late Majority



Relate to Technology



Conservatives



Driven by Practical Sense



Not Comfortable with Change



Proof of Adaptability



Uses Established Technology



Early Adopters



Adapts Slowly to New



Visionaries Technology



Not Technologists



Insight to Match Technology



Needs Support for Use



Laggards



Skeptics to Opportunity



Recognizes Need to Change



Innovators



Technology Enthusiasts



Cannot Stand Change



Avoids New Technology



Quick to Find Fault



First to Adopt New Technology



Understand Problems



87

G

S

T


Innovators Can Tailor a New Technology

CORE

TECHNOLOGY

AND NEW

METHODOLOGY

Individuals least in need of support are the technology enthusiasts. These people

(innovators and early adopters) are used to joining together the bits and pieces of systems and figuring their own way to the objectives intended by the core technology.



88

G

S

T


Sponsorship: Facilitating Change

 The SPONSOR is the person in management that has the authority to commit all resources required to implement the desired change; decides the change will be implemented; and commits the resources.

 The SPONSOR is has the authority, accountability, and responsibility for making the change take place.



















“Owns” the change.

Communicates ownership to everyone who needs change.

Selects and empowers qualified change agents.

Commits the resources required for success.

Keeps the change goals in the consciousness of the organization.

Modifies reward system to encourage organizational change.

Enforces the modified reward system and makes enforcement public.

Models changes in behavior for change adoption.

Communicates change objectives and benefits effectively and often.



89

G

S

T




Agents of Change

The CHANGE AGENTS are the individuals that are selected by the sponsor to be the implementers of new methods and technologies.

Frequently, these are the the individuals first to identify a new or merging technology.

 The CHANGE AGENTS are responsible to the sponsor for change implementation.















Manages the implementation

Identifies the resources that will be needed

Helps sponsor build support.

Assists Users in implementation

Collects and consolidates data. Reports progress to sponsor

Identifies sources of resistance and helps sponsor use resistance effectively

Pinpoints systemic problems and productivity wasters



90

G

S

T


Five Elements of Change

A clear vision of the desired state and an understanding of the current state.

The skill to apply the methodologies and technologies of the desired state.

Clear understanding of the benefits (incentives) that would be achieved with the desired state.

Availability of adequate resources and the willingness to commit the resources.

A well-thought plan of action to implement change.



91

G

S

T


VISION

Effects of Missing Change Elements

SKILLS INCENTIVES RESOURCES

ACTION

PLAN

CHANGE

VISION

VISION

VISION

SKILLS

SKILLS

SKILLS

INCENTIVES RESOURCES

INCENTIVES RESOURCES

INCENTIVES

RESOURCES

ACTION

PLAN

ACTION

PLAN

ACTION

PLAN

ACTION

PLAN

CONFUSION

ANXIETY

SLOW CHANGE

FRUSTRATION

VISION SKILLS INCENTIVES RESOURCES FALSE STARTS

Source: Ambrose, 1987



92

G

S

T


Identifying the Change Makers

SPONSORS CHANGE AGENTS PROCESS OWNERS

VISION

RESOURCES

BENEFITS

SKILLS

ACTION PLAN

BENEFITS

BENEFITS

IMPLEMENTATION

USE

MANAGEMENT

SOFTWARE ENGINEERING

PROCESS GROUP

PRIMARY USERS

ESTABLISH

VISION

DEFINE

GOALS

REALITY

CHECK

MATURITY

GROWTH

CYCLE

EVALUATE

GOALS

ACTION

PLANNING

CHANGES

TRAINING

PROCESS

IMPROVEMENT

CYCLE

REALITY

CHECK

EVALUATE

PLAN

IMPLEMENT

CHANGES

MEASURE

CHANGES

IMPLEMENTATION

AND USE

CYCLE

REALITY

CHECK

EVALUATE

CHANGES

EARLY ADOPTERS INNOVATORS EARLY MAJORITY



93

G

S

T


Resistance To Change

ANGER, RAGE

E

N

E

R

G

Y

STATUS QUO

DENIAL

STUNNED PARALYSIS

BARGAINING

ACCEPTANCE

TESTING

DEPRESSION

T I M E



94

G

S

T


SEI’s Ideal

Model

Initiating

Leveraging

Propose

Future

Actions

Analyze and

Validate Implement

Solution

Refine

Solution

Acting

Stimulus for Change

Set

Context

Build

Sponsorship

Charter &

Infrastructure

Pilot/Test

Solution

Characterize

Current &

Desired

States

Diagnosing

Develop

Recommendations

SM IDEAL is a service mark of

Carnegie Mellon University.

Set

Develop

Priorities

Approach

Plan

Actions

Create

Solution

Establishing



95

Amoco: Introduction to the SEI`s CMM

Introduction to the

Software Engineering Institute’s (SEI)

Capability Maturity Model (CMM)

“Improving

you build means improving

you build”

Course Overview

Course Guidelines

Course Schedule

Day One: Executive Overview

Evolution of the CMM

For Software

Cobb’s Paradox

“We know why projects fail, we know how to prevent their failure....so why do they still fail?”

The Need for Better Planning and Managing

Project Success Profiles

Project Obstacles Profiles

Project Failure Profiles

Industry Project Success Criteria

Evolution of the CMM

Evolution of the CMM

Evolution of the CMM

Evolution of the CMM

Process

How Does Your Customer Benefit?

What’s in it for the Employee

?

How Does the Organization Benefit?

Benefits of Using CMM Model

Risks

But I have ISO, so why do I need the CMM?

The Model:

SEI’s CMM

Understanding the model structure

1

2

4

5

3

CMM Structure

Relationships of CMM Elements

Relationships of CMM Elements

Fill in Blanks

Characteristics of Organizations at

Different Levels of Process

Maturity

Key Process Areas of each Level

Process Characteristics of CMM Levels

People Characteristics of CMM Levels

Technology Characteristics of CMM Levels

Measurement Characteristics of CMM Levels

Level 2

Level 3

WHAT THREE WAYS CAN THE CMM

CAN BE USED?

The Three Uses of the CMM

PROCESS IMPROVEMENT,

EVEN WITH THE CMM,

IS NOT A SIMPLE TASK

Software Organizations Resist Change

Technical

Organizational Issues are Overlooked

Technical

Related documents

Add this document to collection(s)

Add this document to saved

Suggest us how to improve StudyLib