Understanding & Using S/W CMM For Process Improvement

TCS Confidential PresentationApril 21, 2023 Page : 1

Understanding & Using S/W CMM

For

Process Improvement


Overview

Objective of the tutorial Overview of s/w CMM– Why CMM

– What is CMM

– Implications and benefit of CMM

Proposed roadmap for higher maturity level SPI methodology Managing change in an organization Exercise on process improvement


Objective

To help participants understand

SW CMM as a model benefits of SW CMM the roadmap for higher maturity level the approach for software process

improvement the process of managing change in an

organization

Page : 4

Why CMM


The software problem (1 of 2)The software problem (1 of 2)

The average software program has 40 design flaws that impair employees' ability to use it. The resulting cost of lost productivity can be up to 720%. (Landauer, 1995)

80% of software lifecycle costs occur during the maintenance phase. (Pressman, 1992)

According to a 1995 study by The Standish Group:

• Only 9% - 16% of software development projects are completed on time and on budget.

• A mind boggling 31% of software development projects are cancelled before completion.

• About 52% of projects eventually do get completed, but end up costing

189% average cost overrun

222% average time overrun

39% of the average functionality was not implemented


The software problem (2 of 2)The software problem (2 of 2) No Silver Bullet (Fred Brooks 1986)

– No single software development support tool would produce a true

order-of-magnitude improvement in programming productivity

So is Software Development a Mission Impossible? Why is it so prone to failure?

“Let’s add more people” seems to be the commonest mistake which

project managers make when schedule slips

– “It takes nine months to bear a child, no matter how many women are

assigned” (Fred Brooks)

• Even in the best of projects where the customer is happy and the system is running LIVE without any major issues, there was a rework effort of about 34% of the overall effort!! (TCS confidential data - early 90s)


Lack of project management

Ambiguous and constantly changing requirements

Use of new technologies

Lack of user involvement

Trying to chase unrealistic targets

Lack of appropriate resources and tools

Obsolete before completion

Lack of training

Why projects fail or have extensive overruns?

Why projects fail or have extensive overruns?


Improving efficiency at workImproving efficiency at workPeople

Process Technology

AB

CD

Sdfkfaso iahsf sdfkas askf asfsdfdsk fs asd;fkjas;dkf askfas sdjfkn kjasdf jasdf jsf wdfi w[0din as;dhfiasf; anf[I sadifh ai asidn f af as09 dahdp uhdf phadf uihdf hdh hf hdf dslasd hasdf uhdf sfs uhasfpuas usfsmfd ask as asjas s jasf mm s apdkas ns n knsf nfas asdfj ifa[if99hj piasd ijsdf jsdfij asdfijs ijsij isad[j ia

Businesscapability


What is a process?

– What you do• e.g Getting

dressed in the morning

What is a software process?

– A set of activities, methods, practices, and transformations that people use to develop and maintain software and the associated products (CMM). e.g.

• process to do analysis

• process to do plan and track the projects

• process to conduct reviews

TCS Confidential PresentationApril 21, 2023 Page :

10

An Immature ProcessAn Immature Process

Improvised by practitioners and managers

Not rigorously followed or enforced

Highly dependent on managers and customers

Low visibility into progress

Product functionality and quality may be

compromised to meet schedule

Quality difficult to predict


11

An effective software processAn effective software process

Characteristics– Defined– Owned– Trained– Supported– Followed– Monitored– Improved

Infrastructure mechanism– Process documentation– Process group– Process training– Process tools– Process enforcement– Feedback activities– Process improvement

Software process maturity is the extent to which a specific process is explicitly defined, managed, measured, controlled, and effective.


12

Software Process Improvement Software Process Improvement

Advantages:

– Fewer product defects found by customers

– Earlier identification and correction of defects

– Fewer defects introduced during the process

– Faster time to market

– Better predictability of project schedules and

resources

Page : 13

What Is CMM


14

Life history– conceived by Watts Humphrey in response to a request for

assessing the capability of software contractors – SEI maturity questionnaire - 1987– “Managing the Software Process” - 1989– Capability Maturity Model, v.1.0 - 1991, v. 1.1 - 1993

Maturity framework integrates– software engineering best practices– quality methods of Crosby and Deming (TQM)– organizational change

Extensive industrial input– CMM Workshops, Advisory Board– 500+ reviewers

Evolution of SW CMMEvolution of SW CMM


15

What is CMM?What is CMM?

A common-sense application of process

management and quality improvement concepts

to software development and maintenance

A community-developed guide

A model for organizational improvement

The underlying structure for reliable and

consistent CMM-based appraisal methods

CMM is applying TQM to software


16

The Five Levels of Software Process MaturityThe Five Levels of Software Process Maturity

Continuously Improving Process

Focus on process improvement

5.Optimizing

1. InitialUnpredictable and poorly controlled

Project Management

2. RepeatableDisciplined Process Can repeat previously

mastered tasks

Integrated Engineering Process

3. DefinedStandard, Consistent Process Process characterized,

fairly well understood

Product and Process Quality

4. ManagedPredictable Process Process measured

and controlled

Managing Change


17

THE CMM STRUCTURE

Level KPA Goals Practices

Level 2 6 22 121

Level 3 7 17 108

Level 4 2 9 40

Level 5 3 6 47

Total 18 54 316


18

THE CMM STRUCTURE

The Common Features Include ... Commitment to perform

– The actions the organization must take to ensure that the process is established and will endure

Ability to perform

– The preconditions that must exist in the project or organization to implement the software process competently

Activities performed

– The roles and procedures necessary to implement a key process area


19

THE CMM STRUCTURE

The Common Features include ... Measurement and analysis

– The need to measure the process and analyze the measurements

Verifying implementation

– The steps to ensure that the activities are performed in compliance with the established process


20

Software Management is a Black Art

In Out

Requirements flow in; product flows out Performance driven by competence and heroics of the people doing the work

INITIAL LEVEL


21

NO KEY PROCESS AREAS

Initial (Lvl 1)

THE KEY PROCESS AREAS - LVL 1


22

Understanding the Initial Maturity levelUnderstanding the Initial Maturity level

Performance driven by the competence and heroics of the people doing the work

High quality and exceptional performance possible so long as the best people can be hired

Unpredictable - for good or ill The major problems facing the

software organization are managerial, not technical


23

Project Management System is in Place

Process of building software is a series of black boxes with defined checkpoints (milestones) Software project management processes are documented and followed. They are guided by organizational policies

REPEATABLE LEVEL

OutIn


24

Software Configuration ManagementSoftware Quality AssuranceSoftware Subcontract Management*Software Project Tracking & OversightSoftware Project PlanningRequirements Management

Repeatable (Lvl 2)


* OPTIONAL


25

Understanding the Repeatable Maturity Level

Understanding the Repeatable Maturity Level

The Predominant need is to establish

effective software project management.

Software project management processes are

documented and followed.

Organizational policies guide the projects in

establishing management processes.

Successful practices developed on earlier

projects can be repeated.


26

Managed according to a well - Defined Process

Builds on Project Management Foundation Roles and Responsibilities in the process are understood Outputs of one task flow smoothly into the inputs of the next task

DEFINED LEVEL

OutIn


27

Peer ReviewsIntergroup CoordinationSoftware Product EngineeringIntegrated Software ManagementTraining ProgramOrganization Process DefinitionOrganization Process Focus

Defined (Lvl 3)



28

Understanding the Defined Maturity Level

Understanding the Defined Maturity Level

This level builds on the software project

management foundation.

To control a process, it must be defined,

documented, and understood.

At this level, the organization builds

processes that empower the individuals

doing the work.


29

Product & Processes are Quantitatively Managed

OutIn

Management has an objective basis for making decisions using statistical process control Management is able to predict performance within quantified bounds

MANAGED LEVEL


30


Software Quality ManagementQuantitative Process Management

Managed (Lvl 4)


31

Understanding the Managed Maturity Level

Understanding the Managed Maturity Level

Quantitative goals set by the organization for products and processes

Organizational measurement program

Software processes are instrumented with well defined and consistent measurements

Process capability quantifiable and predictable


32

Focus - Continuous Process Improvement

OutIn

Disciplined change is a way of life

OPTIMIZING LEVEL


33


Process Change ManagementTechnology Change ManagementDefect Prevention

Optimizing (Lvl 5)


34

Understanding the Optimizing Maturity Level

Understanding the Optimizing Maturity Level

Focus on continuous process improvement

Strengthen the process proactively with the goal

of preventing occurrence of defects


35

Maturity Levels cannot be skippedMaturity Levels cannot be skipped

Processes at higher maturity levels may be performed,

although perhaps ineffectively, even by organizations at

the Initial Level.

Process capability is built in stages, since some processes

are ineffective when others are not stable.

Each level provides a necessary foundation for

improvements undertaken at the next level.

Page : 36

Implications & Benefits of CMM


37

CMM Architecture Level Focus Key Process Area

Optimising ContinuousProcessImprovement

Defect PreventionTechnology Change ManagementProcess Change Management

Managed Product andProcess Quality

Quantitative Process ManagementSoftware Quality Management

Defined DefinedEngineeringProcess

Organisational Process FocusOrganisational Process DefinitionIntegrated Software ManagementTraining ProgramSoftware Product EngineeringIntergroup CoordinationPeer Reviews

Repeatable ProjectManagement andCommitmentProcess

Requirement ManagementSoftware Project PlanningSoftware Project Tracking and OversightSoftware Configuration ManagementSoftware Subcontract ManagementSoftware Quality Assurance

Initial Adhoc


38

Implications with benefits of CMM Level 2

– Project level documentation; stable estimating, planning and monitoring processes

– Problems are recognized and corrected as they occur– Commitments are understood and managed

Level 3– Organisation wide integrated management and

engineering processes– problems are anticipated and prevented, or impacts are

minimized– project groups work together– training is planned and provided according to roles


39

Implications and Benefits at Level 2

Level 2– A basic Quality Management System is established– A Software Quality Assurance Group is put in place– Estimation, Planning and tracking practices are

established in projects– Configuration management and Sub-contract

management is in place

Independent view of qualityObjective subcontractor data and information

Tracking and re-planning data are treated as an assetRisks are tracked and kept visible

Product activities are based on approved and understood requirementsActivities for managing the requirements is kept visible


40

Level 3– Software Engineering Process Group is put in place– Processes are defined, documented and used– “Say what you do; do what you say.”– Inter-group coordination between projects and

supporting groups is formalized with Service Level commitments for various activities

– Inspection methods are formalized and used– Training and orientation practices are in place– Product Engineering practices (including thresholds) are

defined and implemented

Defect found earlier at lower cost; Data available for use in defect removal modelsIssues do not drag on unresolved issues and impede progress

Cross group knowledge increasesConsistency across work products

Flexible processes to meet project needsSkilled and knowledgeable personnel

Implications and Benefits at Level 3


41

Level 4– processes are quantitatively understood and stabilized– management has an objective basis for making decisions– management is able to predict performance within

quantified bounds Level 5

– Disciplined change is a way of life– processes are continuously and systematically improved– common sources of problems are understood and

eliminated– Everyone is involved in process improvement

Implications with benefits at level 4 & 5

Page : 42

Proposed Roadmap


43

Proposed Roadmap for achieving higher maturity levels

Identify where you are – ‘If you don’t know where you are, a map won’t help’-

Humphrey Identify where you want to go

– ‘If you don’t know where you are going any road will do’ - Chinese proverb

Set up an SPI Action Plan Assign resources and responsibilities Track progress Conduct Assessments Continuously improve

Commitment from Senior management•Policies•Rewards•Ensure middle management commitment•Overseeing implementation of various KPAs


44

Proposed Roadmap for achieving higher maturity levels (contd)

Level 2– A basic Quality Management System is established– A Software Quality Assurance Group is put in place– Estimation, Planning and tracking practices are

established in projects– Configuration management and Sub-contract

management is in place

Independent view of qualityObjective subcontractor data and information

Tracking and re-planning data are treated as an assetRisks are tracked and kept visible

Product activities are based on approved and understood requirementsActivities for managing the requirements is kept visible


45


Level 3– Software Engineering Process Group is put in place– Processes are defined, documented and used– “Say what you do; do what you say.”– Inter-group coordination between projects and

supporting groups is formalized with Service Level commitments for various activities

– Inspection methods are formalized and used– Training and orientation practices are in place– Product Engineering practices (including thresholds) are

defined and implemented

Defect found earlier at lower cost; Data available for use in defect removal modelsIssues do not drag on unresolved issues and impede progress

Cross group knowledge increasesConsistency across work products

Flexible processes to meet project needsSkilled and knowledgeable personnel


46

Moving from level 2 to Level 3

Requirements

Selection of life cycle model

Organization’s StandardSoftware Process

(OSSP)

Tailoring Guidelines

Project’s Operational Process

Project Plan

Process Assets and

Process DB

Planning, tracking,

estimating data


47


Level 4– An organization wide metrics program is in place– Statistical Process Control (SPC) used for better insight

of the processes– Training and orientation in SPC is planned and

implemented– Product and process quality managed by comparing

actual measures to expected values of mean and variance (based on past performance)

– Corrective and Preventive actions are planned and implemented to eliminate the special causes

Process Capability is understoodCapability baselines can be used to set goals

Project processes are improvedQuality goals are based on data

Goals are managed


48

Examples of management by data

Defect Density Vs %Review Effort

0

0.2

0.4

0.6

0.8

1

1.2

1.4

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

% Review EffortD

efec

t D

ensi

ty

UCL

LCL

Time

Hou

rs p

er c

all

2

4

3

SEI CMU Pittsburgh (Introduction to CMM)


49

Optimizing at Level 5

Prev UCL

Prev LCL

Time

Hou

rs p

er c

all

2

4

3New UCL

New LCL

Improvement in average

turn-around time

SEI CMU Pittsburgh (Introduction to CMM)


50


Level 5– Focus on defect prevention rather than defect detection

by analysing common errors– Tools for conducting causal analysis are identified and

people are trained on these– Setting up of Technology and Process Change

Management groups aligned with business goals– Cost benefit analysis of proposed process and

technology changes is a continuous process– Involving everyone in continuous process improvement– Focus on use of more powerful tools and methods

Defect types are preventedProcesses revised based on data and analysis

Continuous focus on managed technology changeProcess improvement is everyone’s job

Process improvement is continuous

Page : 51

Software Process Improvement


52

Gap Analysis

Planning, Dev & Dep

Assessment

Gap Analysis Report

Dashboard

SPI : Stages

Improvement


53

Gap Analysis

SPI Planning

Gap Analysis

Training

SPI : Methodology

•Study organization profile, business objectives,

current software development environment and

practices

•Identify Goals and define “To Be” State

•Perform Gap Analysis w.r.t. “To Be” State

•Identify opportunities for Improvement

•Prepare high level Action Plan

Gap Analysis


54

Planning

Milestones

Gap Analysis

Detail Plan

Benefits to the customer:

– Understanding the road-map for desired process maturity– Realization of the roles and responsibilities of different functional

entities

SPIPlan Resource


55

Dev & Dep

Benefits to the customer :

– A systematic approach to plan and track the SPI – Effective handling of change management– Action plan is available to perform the subsequent activities– Periodic tracking reports are available (Score card)

Deploy

ReviewRefine

Check Status

Pilot

ReviewRefine

Detail Plan

Define Process

Scorecard

Duration

Effort

Resource

Difficulties

Issues

ROI

Pilot Results

Page : 56

Managing Change In The Organisation


57

Managing the SPI TransitionThe Ideal: Directed Change

PRODUCTIVITY

PRESENT

STATE

DESIRED STATE

TIME

Rapid

Change


58

Managing the SPI TransitionThe Alternative: Evolving Change

PRODUCTIVITY

PRESENT

STATE

TIME

Evolution:

a State of

Transition

DESIRED STATE

Reviewing and

UndoingGoal Setting

and Defining

Training and

Institutionalizing

Implementation

Adapting


59

Typical Reaction To Change

T I M E

E

N

E

R

G

Y

STATUS QUO

STUNNED PARALYSIS

DENIAL

ANGER, RAGE

BARGAINING

DEPRESSION

TESTING

ACCEPTANCE


60

Five Elements of Change

VISION :- A clear vision of the desired state and an understanding of the current state

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

BENEFITS :- Clear understanding of the benefits (incentives) that would be achieved with the desired state

RESOURCES :- Availability of adequate resources and the willingness to commit the resources

PLAN :- A well-thought plan of action to implement change

If any of the above element is missing, the change process is impaired.


61

Effects of Missing Change Elements

VISION SKILLS INCENTIVES RESOURCES ACTION PLAN CHANGE

SKILLS INCENTIVES RESOURCES ACTION PLAN CONFUSION

VISION INCENTIVES RESOURCES ACTION PLAN ANXIETY

VISION SKILLS RESOURCES ACTION PLAN SLOW CHANGE

VISION SKILLS INCENTIVES ACTION PLAN FRUSTRATION

VISION SKILLS INCENTIVES RESOURCES FALSE STARTS

Source: Ambrose, 1987


62

Adopters of ChangeEarly Majority

PragmatistsRelate to TechnologyDriven by Practical SenseProof of Adaptability

LaggardsSkepticsCannot Stand ChangeAvoids New TechnologyQuick to Find Fault

Late MajorityConservativesNot Comfortable with ChangeUses Established TechnologyAdapts Slowly to New

TechnologyNeeds Support for Use

Early AdoptersVisionariesNot TechnologistsInsight to Match Technology

to OpportunityRecognizes Need to Change

InnovatorsTechnology EnthusiastsFirst to Adopt New TechnologyUnderstand Problems


63

Managing Change in an organisation

Organisations on their path to process maturity need extra efforts to implement change– resistance to change is an expected state

How to manage the change program?– Participation - Involve all affected– Involve practitioners in reviews and audits– Effectively communicate Approach, Deployment and

Results– Train– Pilot major process changes– Empower all affected to give suggestions


64

Management Sponsorship

Formation of Groups for Process Improvement

Allocating budget for Process Improvement initiative

Recognizing and rewarding the efforts in SPI


65

Management Responsibility

Encourage the organization to change Provide committed resources As the SPI sponsors, actively manage

the change process Involved in planning and scheduling Motivate by providing visibility and

recognition Regularly conduct SPI planning and

review meetings with the group


66

Empowering Individuals

Each and every individual in the Organization contributes to SPI

Mandatory for all Staff to participate in SPI program by giving at least one suggestion per year, which is beneficial to the organization and can be taken up for process improvement

Improvement transferred into everyday practice across the organization


67

Exercise 1

Process improvement


68

Exercise 2

Causal Analysis & Defect Prevention


69

THANK YOU

Understanding & Using S/W CMM For Process Improvement

Documents