CMM Implementation StrategiesES

7/28/2019 CMM Implementation StrategiesES

1/157

26 April 2003 SPIN Bangalore + NASSCOM

CMM Workshop

SPIN Bangalore + NASSCOM
http://www.ibm.com/


2/157


CMM Workshop

Overview of CMM

Strategy for CMM implementationa. Clarity of Organizations objectives for going for CMM

b. Organizational structures

c. Process definition approach

d. Process institutionalization approach

Role of Change Agent(s) in implementing Quality initiatives.

CMM implementationpractices & toolsa. Project Management: PP, PTO, ISM, SCM (25 min)

b. Process Management: OPF, OPD, SQA, (QPM, PCM, TCM) (25 min)

c. Solution engineering: RM, SPE, PR, (SQM, DP) (25 min)

d. Enabling functions: TP, IGC (15 min)

Critical Success Factors for sustainable CMM implementation:

implementing the CMM Common Features Assessment approach

Case Study

Q&A, Discussions

Detailed Agenda


3/157


Module 1:Overview of CMM


4/157


Cobbs 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


5/157


Some Facts

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

31.1 % of all projects were canceled before they are

completed.

52.7% of projects cost 189% of their original estimates

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


6/157


Problems in Projects

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


7/15726 April 2003 SPIN Bangalore + NASSCOM

Origin

CMM or Capability Maturity Model was established

in the mid 1980s by the Software Engineering

Institute, Carnegie Mellon University to reduce the

variations in schedule, effort and also the defects in

the software products that were being delivered to

Government organisations.



History

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

GAO (US Government Accounting Office) study in 1983showed that only 3% of the software being delivered to

the Governmentwas usable on delivery; that 49% wasnever usable; and that 48% needed modification prior touse.

In the early 1980s, the Government created a FederallyFunded Research and Development Center at Carnegie

Mellon University, The Software Engineering Institute. Objective was to reduce the Governments exposure to

software development and maintenance risk.

TQM was in full swing in the manufacturingenvironment.



Evolution of the CMM

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 thencataloged as the Key Practices and grouped into Key

Process Areas (KPAs).



Evolution of the CMM

The organizations had applied their good businesspractices to the development of software.

The KPAs, in aggregate, represent good businesspractices that have been defined in the context of asoftware development environment.

The KPAs were grouped into levels of capability. Thematurity levels were derived from TQM literature andapplied to software.



The KPAs in each level enhance the effectiveness of the previous maturity

level KPAs while strengthening the foundation for further process maturity

growth.

The Capability Maturity Model is

defined in levels of process maturity.

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.

CMM Framework



CMM Model

A Total of 316 Key Practices in CMM V1.1

CMM V1.1

Level2 Level 3 Level 4 Level 5

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

Commitmentto Perform

AbilitytoPerform

ActivitiesPerformed

MeasurementandAnalysis

VerifyingImplementation

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

Key Process Areas are organized by Common Features



Relationships of CMM Elements

Indicate Contain

Achieve Organized By

Address Contain

Describe

Maturity Levels

Key Process

Areas

Common

Features

Key

Practices

Process Capability

Goals

Institutionalization

Activities



Capability Maturity Model

Project

Risk

Productivity and Quality

1 Initial

2 Repeatable

3 Defined

4 Managed

5 Optimizing

Heroes

Project

Management

Engineering

Process

Product and

Process Quality

Change Management

Defect Prevention

Disciplined

Standard,

Consistent

Predictable

Continuously

Improving



Common features

Commitment to Perform

Describes the actions the organization must take to

ensure that the process is established and willendure. Eg.,Policy Issues

Ability to Perform

Describes the preconditions that must exist in the

project or organization to implement the software

process competently Eg.,Resource issue



Activities

Describes the activity we are performing

Measurement and Analysis

Describes the basic measurement practices necessaryto determine status related to process being performed.

Common features



VerifyingImplementation

Describes the steps to ensure that the activities are

performed in compliance with the processes that have

been established.

Common features

P f CMM



Repeatable (2)

Project level

Documented andstable

Estimating,

planning, and

commitment

Problems

recognized and

corrected

Defined (3)

Organizational

Integratedmanagement and

engineering

processes

Problems are

anticipated

, or

Impact of

problem is

minimized

Managed (4)

Processes are

quantitatively

understood andstabilized

Sources of

assignable

problems are

understood and

eliminated

Optimizing (5)

Processes are

continuously and

systematicallyimproved

Common

sources of

problems are

understood and

eliminated

Process Characteristics of CMM

Levels



Success depends

on individuals

Commitments

are understood

at project level

People are

trained

Repeatable (2)

Project groups

work together

Work as

integrated team

Training is

planned and

provided

according to roles

Defined (3)

Strong sense of

teamwork exists

within eachproject with

shared

quantifiable goals

Managed (4)

Strong sense of

teamwork across

the organization

Everyone is

involved in

process

improvement

Optimizing (5)

People Characteristics of CMM Levels

T h l Ch t i ti f CMM



Technology

supports

established, stableactivitieszt

project level

Repeatable (2)

New technologies

are evaluated on a

qualitative basis

Defined (3)

New technologies

are evaluated on a

quantitative basis

Managed (4)

New technologies

are pro-actively

pursued anddeployed

Optimizing (5)

Technology Characteristics of CMM

Levels

M t Ch t i ti f CMM



Planning and

management data

used by

individual

projects

Repeatable (2)

Data are

collected and used

in all defined

processes

Data are

systematically

shared across

projects

Defined (3)

Data definition

and collection are

standardized

across the

organization

Data are used to

understand the

processquantitatively

Managed (4)

Data are used to

evaluate and

select process

improvements

Optimizing (5)

Measurement Characteristics of CMM

Levels


22/157


Better Visibility through Higher Process Maturity


23/157


Better & Consistent Performancethrough Higher Process Maturity


24/157


Module 2:

Strategy for CMMImplementation


25/157


Organizational Objectives

CMM should be an objective of the Head of theorganizationbuy-in, conviction from Qualityimprovement perspective

Avoid duplicate initiativesCMM level3subsumes ISO requirements

Focus on organizational capability improvement;look at assessment as a byproduct

Keep Customer Satisfaction as the end goal; UseCMM as a reference framework

Use the Assessment as a catalyst for change

Organizational Structures and


26/157


Organizational Structures and

Mechanisms There should be one person championing the

initiative.

This person should report to the Head of theorganization

Have a Steering Committee from themanagement side of the project delivery functionfor driving the initiative

Have many dynamic Task teams (working

groups, Subject Matter Expert teams) fordefining and implementing the processes

Define appropriate Management Reviews formonitoring progress on process definition and

process usage in projectskey pivotal point


27/157


Process Definition Approach

Start with a holistic view for defining the

architecture for process: Customer Satisfaction asgoal and process & tools as means to that goal

Establish linkages to business goals

Define the process from user perspective: ISO12207, IEEE 1074 are good references fordefining the life cycle processes; Use CMM as across check to verify that all requirements areaddressed.

Facilitate Practitioners to define the process(Subject Matter Expert teams)buy-in,internalization.

A R t ti f CMM KPA f


28/157


A Representation of CMM KPAs from

process architecture perspective

PCM

PR

S P ERM

S Q A

PP ISM PTO

S C M

SQMProject L evel

Continuous Improvement cycle

Organizational Level

TCM

DP

QPM

The Boat House on a Continuous Improvement journey

Project Start Project End


29/157


L4, L5 KPAs are layers over L2, L3 KPAs

QPM/SQM

DP

TCM

PCM

PT PE PRPP

Continuous

Process

Improvement:

Dynamic

Process

Static

Process

RM

Treat L4, L5 KPAs as extensions of L2 & L3 KPAs

I tit ti li ti


30/157


Institutionalization Management Reviews are the pivotal points:

bring the key initiatives, key metrics and process

usage checks under regular managementmonitoring

At different periodicityweekly, monthly,quarterly

At different levelsproject team level, managementlevel

Use Audits (SQA, cross-project,) to bringconstant visibility and focus on process usage

Leverage Peer Reviews to bring processdeployment within project teams

Automation and Tools

Rewards & Recognitions


31/157


Module 3:

Managing Change:Role of Quality Function &

Management


32/157


The Role

Understanding best in class practices and models

Enabling management to understand GAPs

Ensuring the management commitment andinvolvement

Sponsorship

Reviews

Re-enforcement Enabling to set the improvement goals and

aligning with the business needs


33/157


The Role

Planning for improvements

Long term

Short term

Improving users in process improvement

Active facilitation

Enabling process users

Ensuring Process effectiveness


34/157


The Role

Keeping a tab on customer feedback

Guiding projects to tune the process

Quality Help desk

Support to Sales

Thought leadership


35/157


Organising the Quality Function

Full time

Part time

Ratio [quality folks/total folks]

Role as defined in CMM [different Levels]


36/157


Managing resistance

Creating few Champions

Communication

Setting Improvement targets for Project

people and Appraising for them

Rewarding


37/157


Module 4:

CMM implementationPractices and Tools

CMM Implementation - Practices & Tools


38/157


Major Domains in this section:

Project Management

Process Management

Solution Engineering

Enabling Functions

Practices & Tools



39/157


Optimizing (5)

Process change management

Technology change management

Defect Prevention

Managed (4)

Software Quality management

Quantitative process management

Defined (3)

Peer reviewsInterGroup Coordination

Software product engineering

Integrated Software ManagementTraining program

Organization process definition

Organization process focus

Repeatable (2)

Software Configuration ManagementSoftware Quality assurance

Software subcontract management

Project Tracking and Oversight

Project PlanningRequirements management

Initial (1)

Disciplined Process

Standard, consistent

process

Predictable

process

Continuously Improving

process

Adhock practices

Project Management

Project Planning

Project Tracking & Oversight



40/157


Purpose:

To establish reasonable plans for performing thesoftware engineering and for managing the software

project.

Project Planningj g g

Software Configuration Management

Integrated Software Management

Goal:

1. Software estimates are documented for use in

planning and tracking the software project

2. Software project activities and commitments

are planned and documented .

3. Affected groups and individuals agree to their

commitments related to the software project.

P j t Pl iCMM Implementation - Practices & Tools Project Planning



41/157


Right estimation techniques.

A suitable technique not a complicated one.

Different methods suits different situations.

Consider actuals for estimating the next time.

Build a historical Database right from Day 1.

Track & Trace Commitments to the source.

Mark commitments as part of the schedule.

Independent review of planning documents.

Kick Off meeting with related groups for clarity. Plan Project Specific Processes.

Project Planningj g g



Suggested Practices

P j t Pl iCMM Implementation - Practices & Tools


42/157


Support Groups include: Training : Skill upgrade, skill matching

HR: Recruitment, contractors, trainees.

Quality Assurance: Facilitation, Audits, consultation.

Reviews: Work products, PM, Sr. Mgt.

Technical Services Group: Infrastructure

Administration & Facilities: Infrastructure

Test groups : Pure Testing

Project PlanningCommitments:

P j t Pl iCMM Implementation - Practices & Tools


43/157


Factors to be considered while planning:

Risks.

Constraints.

Assumptions.

Project Complexity.

Project Type (New, similar)

Capabilities. Dependencies.

Resources available.

Management Focus/Priority.

Escalation Mechanisms. Measurements for project!

Project Planning

Use Simple Job aids built out of Excel/Word.

P j t Pl iCMM Implementation - Practices & Tools Project Planning



44/157


Project Planning

Highlights :

Estimation Techniques.

Obtain Commitments.

Planning effectively.



Project Planning





45/157


Purpose:

To provide adequate visibility into actual progressso that management can take effective actions

Project Tracking

Goal:

1. Actual results and performances are trackedagainst the software plans.

2. Corrective actions are taken and managed to

closure when actual results and performance

deviate significantly from the software plans.

3. Changes to software commitments are agreed

to by the affected groups and individuals.



Project TrackingCMM Implementation - Practices & Tools Project Planning




46/157


Track & update issues on time. Report status into management review.

Update Project status correctly.

Use Metrics to Track status from DAY 1 !!!

Escalate on time. Update Development team of status.

Effective not Long meetings.

Split meetings into sub groups in parallel.

No project without Implementation issues exists.

Corrective actions applied on time makes it tick!

Project TrackingSuggested Practices



Project TrackingCMM Implementation - Practices & Tools Project Planning




47/157


Project Tracking

Provide Visibility.

Monitor w.r.t plan consistently.

Take corrective actions on time.

Highlights :



Project Planning





48/157


Purpose:

To establish and maintain the integrity of the

products of the software project throughout the

project's software life cycle

Goal:

1. Software configuration management activities

are planned.

2. Selected software work products are

identified, controlled, and available.

3. Changes to identified software work productsare controlled.

4. Affected groups and individuals are informed

of the status and content of software baselines.



Software Configure Management

CMM Implementation - Practices & ToolsProject Planning




49/157


Nominated Configuration Controller (CC). Review SCM Plan by independent CC.

Estimation to include SCM effort.

Brief in to entire team on CC activities.

Split SCM activities into: SCM Planning.

Audit & Follow up.

SCM Effort on Scope Changes.

Plan SCM related Risks & mitigation.


Suggested Practices







50/157


Maintain Change Control Register (CCR). Periodic independent review of CCR.

Perform Audits as Planned in SCM Plan.

Ensure SQA verifies audit results & action Plan.

Restoring Backup audit is critical and consistent. Track Requirements from Initial stage.

SRS>HLD>DLD>Code>Debug>Deliver>Wrnty.

A Requirements Tracking Document (RTD)

A challenge to decide the level of detail.

Just sufficient detail to trace it back.


Suggested Practices



Software Configure ManagementProject Planning





51/157


Software Configure Management g gIntegrated Software Management

Plan & establish Baselines.

Control Changes.

Maintain Traceability.

Highlights :




52/157


Project Deliverables

Integrated Software ManagementProject Tracking & Oversight



Engineering

ActivitiesLife Cycle Support

ActivitiesEstablished

Processes

Project Specific

Processes

Project PlanningProject Tracking & Oversight




53/157


Purpose:

To integrate the software engineering andmanagement activities into a coherent, definedsoftware process that is tailored from theorganization's standard software process (OSSP)

Goal:

1. The project's defined software process is a

tailored version of the organization's standard

software process .

2. The project is planned and according to the

project's defined software process (PDSP) .

Integrated Software ManagementIntegrated Software Management

Integrated Software ManagementCMM Implementation - Practices & Tools Project Planning




54/157



Build a repository of Organization processes (OPD)Include Best Practices & Learnings.

Use Metrics to understand it in Numbers.

Define Tailoring Guidelines as part of OSSP.

PDSP beyond tailoring are deviations.

Assign process engineer as a role to overlook.

Process audits around PDSP.

Practioners inputs vital for PDSP.

Revisit PDSP end of every Phase, Phase Kick Off.

Project audits based on PDSP

Suggested Practices


Integrated Software ManagementProject PlanningProject Tracking & Oversight




55/157


Integrated Software Management Integrated Software Management

Refer Org. Processes.

Project Defined Specific Processes.Use PDSP.

Highlights :

EstablishedProcesses

S l ti E i iCMM Implementation - Practices & Tools


56/157


Optimizing (5)

Process change management

Technology change management

Defect PreventionManaged (4)

Software Quality ManagementQuantitative process management

Defined (3)

Peer ReviewsIntergroup Coordination

Software Product EngineeringIntegrated Software Management

Training program

Organization process definition

Organization process focus

Repeatable (2)

Software configuration managementSoftware Quality assurance

Software subcontract management

Project Tracking and Oversight

Project Planning

Requirements Management

Initial (1)

Disciplined Process

Standard, consistent

process

Predictable

process

Continuously Improving

process

Adhock practices

Solution Engineering


R i M

Requirements Management Software Product Engineering

Peer Reviews

Software Quality Management


57/157


Purpose:

To establish a common understanding between thecustomer and the software project of the customer's

requirements that will be addressed.

Goal:

1. System requirements allocated to software are

controlled to establish a baseline for software

engineering and management use.

2. Software plans, products, and activities are

kept consistent with the system requirements

allocated to software .

Requirements Management Software Quality Management

Defect Prevention

R i M

CMM Implementation - Practices & Tools Requirements Management Software Product Engineering

Peer Reviews



58/157



Baseline agreements with customer. Track requirement clarifications to closure.

Re - estimate EVERY scope change.

Include ALL parameters affecting the project.

Customer Reviews requirements or vice versa.

Assumed requirement set sent to customer.

Impact analysis for every scope change.

Effort, Schedule, Risks, ...

All stakeholders agree to changes.

Lost Effort due to scope changes.

Suggested Practices


Defect Prevention

R i M


Peer Reviews




59/157


Requirements Management Software Quality Management

Defect Prevention

Baseline Requirements.

Manage Scope Changes (SCM). Re-Planning.

Highlights :

S ft P d t E i i

Requirements ManagementSoftware Product Engineering

Peer Reviews




60/157


Purpose:

To consistently perform a well-defined engineeringprocess that integrates all the software engineeringactivities to produce correct, consistent softwareproducts effectively and efficiently .

Goal:

1. The software engineering tasks are defined,

integrated, and consistently performed to

produce the software.

2. Software work products are kept consistent

with each other.

Software Product Engineering Software Quality Management

Defect Prevention

S ft P d t E i i

CMM Implementation - Practices & ToolsRequirements ManagementSoftware Product Engineering

Peer Reviews



61/157


Software Product Engineering

PDSP for engineering tasks Use simple tools/methods as far as possible.

Practioners inputs in Phase kick off meetings.

Practioners include:

Technology Specialists.

Process specialists.

SQA.

PM.

Measurements are used to fine tune activities.

Set of checklists and guidelines reviewed eachphase.

Weekly Technical meetings across practioners.

Weekly trainings on engineering subjects.

Suggested Practices


Defect Prevention

S ft P d t E i i

CMM Implementation - Practices & ToolsRequirements ManagementSoftware Product Engineering

Peer Reviews



62/157


Software Product Engineering

Engineering Tasks Planned.(ISM) Reviewed periodically.(SQA,PR)

Measured for each activity.(SQM)

Highlights :

Manage :Requirements

Design

BuildTest

Release

Documentation

Q y g

Defect Prevention

P R i


Peer Reviews




63/157


Purpose:

To remove defects from the software work productsearly and efficiently.

Goal:

1. Peer review activities are planned .

2. Defects in the software work products are

identified and removed.

Peer ReviewsQ y g

Defect Prevention


64/157

Peer Re ie s

CMM Implementation - Practices & ToolsRequirements Management Software Product Engineering

Peer Reviews



65/157


Peer Reviews

Monthly Compliance reviews. Self run Process checklists.

Traffic light signal for:

Process Compliance.

Review effectiveness.

Measurements.

Ensure Planned reviews HAPPEN!

SQA Reviews

Defect Prevention


66/157

Peer Reviews


Peer Reviews




67/157


Peer Reviews Defect Prevention

Work product reviews

SQA Reviews. Management Reviews.

Highlights :


68/157


Questions Please?..

Software Quality Assurance


69/157


Software Quality Assurance

Purpose:

To provide management with appropriate visibilityinto the process being used by the projects and ofthe products being built

Goal:

1. SQA Activities are planned2. Adherence of software products and activities to the

applicable standards, procedures and requirementsis verified objectively.

3. Affected groups and individuals are informed of

SQA activities and results

4. Non compliance issues that cannot be resolved witinthe software project are addressed by seniormanagement.

SQA Suggested Practices


70/157


SQA-Suggested Practices

Each SQA member in the project helps to

establish plans,standards and procedures

for the project.

No need of independent SQA, but

objective verification is required

SQA is involved in reviewing the plans,

facilitations and auditing.

Checklists are required to do effective

facilitation and auditing.

SQA Suggested Practices


71/157


SQA-Suggested Practices

Reports to management on periodic basis about

the status of every project and the non-conformities.

Reports the process performance to SEPG

wherever applicable. Does the metrics analysis for the projects and

gives feedback on time.

Conducts periodic training on new artifacts

developed in the organization.

Takes part in process improvement activities.

SQA Metrics Analysis


72/157


SQA-Metrics Analysis

Start with simple metrics like effort

deviation, Schedule slippage and Defects

Use simple statistical techniques like

Pareto Analysis, Histogram, Cause and

Effect diagram,Run chart, etc. This can bedone with MS Excel and MSWord

Prepare the reports and distribute to the

affected groups on time for timelycorrective action.

Organization Process Definition


73/157


Organization Process Definition

Purpose:

To develop and maintain a usable set ofsoftware process assets that improveprocess performance across projects.

Goals:1. A standard software process for the

organization is developed and maintained

2. Information related to the use of OSSPby the software projects is collected,reviewed and made available.


74/157

OPD Suggested Practices


75/157


OPD- Suggested Practices

The organizational processes are defined,reviewed, approved, documented and made

available in the intranet.

All the procedures, guidelines, documents,

checklists and standards are made available in theintranet for the use of entire organization.

Life cycle and tailoring guideline helps to tailor

the process for the new projects.

Flow charts are prepared and kept in many places

for better understanding of each process.

OPD-Software Process Database


76/157


OPD-Software Process Database

Develop a repository for storing the datafrom the past projects. This can bedeveloped using MS Access for smallorganizations.

The project data can be of projectdescriptions, estimations, effort, schedule,defect details, risks,etc.

Whenever a new project starts, past datafrom the similar projects can be retrievedand effectively used for planning.


77/157


78/157


79/157

Training


80/157


Training

Purpose:

To develop the skills and knowledge of individualsso they can perform their roles effectively andefficiently

Goals:

1. Training activities are planned

2. Training for developing the skills andknowledge needed to perform softwaremanagement and technical roles are provided

3. Individuals in the software engg. Group andrelated groups receive the training necessary to

perform their roles


81/157

Training-suggested practices


82/157


Training suggested practices

Training courses can be developed atorganization level, maintained and continuouslyimproved.

Training can be conducted in the evenings or

early morning to avoid project delays. Skill Matrix is continuously updated by getting

feedback from the employees.

Training needs for the individual projects are

identified before starting the project. Continuousmonitoring is done for on the job training andnew programmers work.

Inter Group Coordination


83/157


Inter Group CoordinationPurpose:

To establish a means for the groups to participateactively in the work for satisfying thecustomers needs effectively and efficiently.

Goals:

1. The customer requirements are agreed to by allaffected groups

2. The commitments between the Engg. Groupsare agreed to by the affected groups

3. The Engg. Groups identify,track and resolveinter-group issues


84/157

IGC-Suggested Practices


85/157


IGC Suggested Practices

Interaction between the different project groups

and dependencies of the team need to be wellexplained in the project plan.

Technical issues can be resolved as early aspossible with the help of available experts.

Inter group issues not solvable by the team areescalated to the senior management positively.

Email facility can be effectively used for bettercommunication among the team members.

The minutes of the project meetings should bedocumented and communicated to all the

participants on time.

Recap


86/157


Recap

Read the CMM Guideline clearly

Develop a mapping between CMM

Terminology and terms used in the

organization

Be clear with the Roles and

Responsibilities

Independent Groups like SQA, SCM and

Testing can be shared across projects

Recap (Contd..)


87/157


Recap (Contd..)

Basis documentation of processes is required. Make sure the documentation is simple and easy

to understand.

Use flow charts and diagrams, if required

Procedures, Standards, Checklists should be task

focused

Most of the documents are available in the

internet. No need of re-inventing the wheel.


88/157

Recap (Contd..)


89/157


Recap (Contd..)

Peer Reviews can be conducted easily bytailoring the checklists available in the

internet.

Small improvement projects can beinitiated by a Process focus Manager and

done along with the process users.

Buy in for documented process is verycritical for successful deployment in the

organization.


90/157


Module 5:Critical Success Factors for

sustainable CMM

implementation:

Implementing the CMM

Common Features

Key characteristics of process


91/157


Key characteristics of process

Reasonable

Practiced

Documented

Enforced

Trained

Measured

Able to improve

Institutionalized

Effective

Repeatable

Can endure/last

Institutionalized Processes


92/157


The organizational culture must convey the

process.

Management must nurture the culture

if no one cares, everyone forgets

Culture is conveyed with role models and rewards.

Institutionalized processes endure after the people

who originally defined them have gone.Theorganization outlives those who leave it.

Building Organizational Culture


93/157


Building Organizational Culture

Institutionalizationand Infrastructure

policy

standardsprocedures

training

oversight

reviews

audits

Organizational Culture

Thats the way we do things around here.

ExternalPressures

customer needs

changing technologycompetition

InternalFactors

champions

sponsors

competence

skills

abilities

tools


94/157


Common Features for sustenance

Commitment to perform

Ability to perform

Measurement and analysisVerifying implementation



95/157


Describes the actions the organization must take to ensure

that the process is established and will endure.

RM

SPP

SPTO

SSM

SQA

SCM

OPF

OPD

TP

ISM

SPE

IC PR

QPM

SQM

DP

TCM

PCM

Commitment

Written Organization Policy

Designated Responsibility

Sr. Mgmt Sponsors Activities

Sr. Mgmt Oversees Activities


Implementation guideline:

1. Policy statements in Quality manual or in process documents

2. Assign leaders or sponsors for certain Key Process Areas

Describes the preconditions that must exist in the project or organizationAbility to Perform


96/157


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, andAnalyzing measurements (data)

Data is Available to support analysis

RM

SPP

SPTO

SSM

SQA

SCM

OPF

OPD

TP

ISM

SPE

IC PR

QPM

SQM

DP

TCM

PCM

Implementation Guideline:

1.Document responsibilities in QM or process documents

2.Plan and execute process training and orientation sessions



97/157


Describes the basic measurement practices necessary todetermine status related to process being performed.


Measurement

Measurements Used to Determine StatusMeasurements Used to Determine Quality

Measurements Used to DetermineEffectiveness

RM

SPP

SPTO

SSM

SQA

SCM

OPF

OPD

TP

ISM

SPE

IC PR

QPM

SQM

DP

TCM

PCM

Implementation guidelines:

1. Perform status reviews for all activities.

2. Specific method to measure effectiveness of Training and ISM

activities

Verifying Implementation


98/157


Describes the steps to ensure that the activities areperformed in compliance with the processes that have

been established.Verifying Implementation

Senior Management Reviews

Project Manager Reviews

Quality Assurance ReviewsAnd/or Audits

Independent (Expert) Review

Activities are Reviewed and/orAudited

SCM Audits Software Baselines

RM

SPP

SPTO

SSM

SQA

SCM

OPF

OPD

TP

ISM

SPE

IC PR

QPM

SQM

DP

TCM

PCM

Implementation Guideline:

1. Reviews at project manager and senior management levels (weekly andmonthly)

2. Perform SQA audits (Monthly) and Internal audits (Quarterly or half yearly)


99/157


100/157


101/157


102/157


103/157


104/157


105/157


106/157


107/157


108/157


109/157


110/157


111/157


112/157


113/157


114/157

Onsite Period - Consolidation


115/157


Based on information collected, data

gathering strategy is revised continuously

Adequacy of information collected isevaluated

If adequate, the observations are

corroborated Sets context for freezing data collection


116/157

Onsite PeriodRating and FinalFindings


117/157


Findings

Based on draft findings and feedback

Rating is an optional feature in anassessment

Goal satisfaction profile is arrived at byassessment team through consensus

Presented to sponsor, assessment

participants and organization, at large

Generate further buy-in


118/157


119/157


120/157


121/157

Assessment Results


122/157


How long are my assessment findings valid

?

How does it increase my responsibilities ? How do I leverage my assessment results ?


123/157


124/157

Why Metrics ???


125/157


You cannot control ..

what you cant measure


126/157




Software Product Engineering Peer Reviews


Defect Prevention

Suggested Practices


127/157


Start Collecting Actual Data.

Use simple forms in excel to do that.

Build a repository for benchmark/reference.

Prioritize Expectations.

Customer Aspirations.

Project Capability. Organization Goals.

Justify priority.

Maintain project specific trendline on parameters.

Nominated metrics champ on rotation basis. Plan Frequency of data collection.

Sample checks to ensure collection happens.

Start using the data.

Suggested Practices


128/157






Defect Prevention


129/157


Milestones

Milestone ID BL st BL End Act. St Act. End SV %

Requirements Analysi 9-Jul-02 21-Jul-02 9-Jul-02 21-Jul-02 0.00

HLD 9-Aug-02 21-Aug-02 9-Aug-02 21-Aug-02 0.00

DLD 19-Aug-02 22-Aug-02 19-Aug-02 22-Aug-02 0.00

Utilisation Report 23-Aug-02 29-Aug-02 23-Aug-02 30-Aug-02 16.67

Archives 23-Aug-02 29-Aug-02 23-Aug-02 29-Aug-02 0.00

Define Billable Resou 1-Sep-02 3-Sep-02 1-Sep-02 3-Sep-02 0.00

Resource Sharing 3-Sep-02 9-Sep-02 3-Sep-02 9-Sep-02 0.00

Build 23-Aug-02 12-Sep-02 23-Aug-02 16-Sep-02 20.00

Unit Testing 13-Sep-02 16-Sep-02 16-Sep-02 17-Sep-02 33.33

System Testing 17-Sep-02 18-Sep-02 17-Sep-02 18-Sep-02 0.00

UAT 19-Sep-02 20-Sep-02Implementation 20-Sep-02 23-Sep-02






Defect Prevention


130/157


Defects Status

RE % SRS HLD DLD Code Rev. U.T Int Total Def

SRS 90.70 39 39

HLD 85.71 0 30 30

DLD 100.00 2 5 5 12

Code Review 80.99 2 0 0 115 117Unit Testing 60.47 0 0 0 12 40 52

Sy. Testing 97.06 0 0 0 15 12 6 33

UAT 1 1

Total 43 35 5 142 52 7 284





Defect Prevention



131/157


Plan Data Collection.

Take Measurements & use them.

.. ON TIME!!

Manage corrective actions.

Until you can predict.

Highlights :

Defect Prevention




Defect Prevention



132/157


Learn from Previous Data.

Perform Causal Analysis.

Use 7 QC Tools.

Derive Action Plan.

Implement Them.

Monitor action Plan.

Verify Results.Until you can predict.

Highlights :


133/157


134/157


135/157


136/157

Technology Change Management


137/157


Purpose:

To identify new technologies (tools, methods andprocesses) and track them into the organizationin an orderly manner

Goals:

1. Incorporation of technology changes areplanned

2. New technologies are evaluated to determinetheir effect on quality and productivity

3. Appropriate new technologies are transferredinto normal practice across the organization.


138/157

TCM-Suggested Practices


139/157


Senior management sponsorship is a must. Resources can be part-time contributors.

But, need a strong commitment.

Appropriate data on the software processesand work products should be collected foranalysis.

TrainingOSSP, SPI,Tools, SQC

Post the final results in the intranet

Review with senior management

Process Change Management


140/157


Purpose:

To continually improve the software processes usedwith in intent of improving software quality,increasing productivity and decreasing cycletime.

Goals:1. Continuous process improvement is planned

2. Participation in the organizations SPI activitiesis organization wide

3. The OSSP and PDSP are improvedcontinuously.


141/157

PCM-Suggested Practices

S i M S hi i


142/157


Senior Management Sponsorship is a must

Prepare a Plan Use experienced people

Use tools wherever applicable

Proper training on SPI activities Resources are selected organization wide

Record all the details

Periodic review of SPI activitiesverycritical

Getting Management involved

A


143/157


Agenda

a. Understanding what the Management needsb. Addressing Management concerns

c. Seeking Management Commitment

d. Defining role of management in the CMM context

a. Role vis--vis CMM implementationthe role of themanagement

b. Role relating to evaluating assessment needs and

investments

c. Role as part of a Management Review System

Understanding management

needs


144/157


needs

Management needs in small organizations are

typically no different from any other organization

Bottom line results

Customer satisfaction

Product / Service quality

Employee productivity

System designed needs to address theserequirementsevery measure should be

traceable to these requirements


145/157

CMM Quotes Relevant for SmallBusinesses


146/157


A reasonable interpretation of the CMM

practices must be made in any context inwhich the CMM is applied.

The Capability Maturity Model; page 41

Businesses


147/157

CMM Quotes Relevant for SmallBusinesses (cont.)


148/157


Thegoals of each key process areasummarize its key practices and can be

used in determining whether anorganization or project has effectivelyimplemented the key process area.


usinesses (cont.)


149/157


150/157



151/157


The key practices in the CMM, however,

must be interpreted in light of a projects ororganizations business environment and

specific circumstances.


( )



152/157


If an organizations implementation of a keyprocess area satisfies the goals but differs

significantly from the key practices, therationale for the interpretation should be

documented.


( )


153/157


154/157

Addressing management

concerns (cont )


155/157


concerns (cont.)

CMM requires steep investments to implement

Differentiate between cost of implementation and costof assessment

Countering no immediate pay off Low hanging fruits Ensure that management understands that the real pay offs

are increased quality, higher productivity and better employeemorale

Using phased approach to implementation Start small, use pilots Higher pay off areas

Project planning/tracking, reviews, CM, training

Seeking management

commitment


156/157


commitment

Sell CMM benefits

Increased project predictability

Improved planning and controlReduced rework

Increased product quality

Increased likelihood of project success

.


157/157

Documents

CMM Implementation StrategiesES