Process Improvement Is - tarrani.net · 1. Continuous process improvement is ... • defining...

Software Engineering InstituteCarnegie Mellon University

142

Process Improvement IsContinuous Improvement

We can never reach perfection.

The CMM does not provide all the answers;it too is evolving and improving.

Process management means constructiveand continual improvement.

The focus is on always doing better.

Our reach should always exceed our grasp.


141

Issues for CMM v2Need to address:• change requests and feedback from the

CMM user community• issues identified by ISO's SPICE project

Consider restructuring key process areas tospan maturity levels.

Expand the descriptions of Levels 4 and 5.


140

Public Review Process for CMM

submits

CMM UserWorking Group

Assessment& capabilityevaluation

users

SoftwareEngineering

ProcessGroups

QuestionnaireAdvisoryBoard

SEI SoftwareProcess Program

Comments andchange requests

UpdatedCMM

products

reviews

producesreviews

CMM workshops

participates

submits

Pilottests

conducts


139

Impact of the New CMM"If my organization was assessed at Level X using the originalmodel and preliminary maturity questionnaire, will it beassessed at Level X using the updated CMM and updatedmaturity questionnaire?"

• If an organization based its improvement program on thespirit of the maturity model, there will probably be littleimpact on its assessed level.

• If an organization's improvement program is designed onthe items in the preliminary maturity questionnaire, then theorganization may see some impact.

Maturity level scores have always been based on the findings ofan assessment rather than the answers to the maturityquestionnaire.


138

Releases of the CMM

Version 1.0 of the Capability Maturity Model forSoftware (CMM) released in August 1991

CMM v1.1 released in February 1993

CMM v2 planned for the 1996-1998 time frame


137

Process Improvement Usingthe CMMSoftware process improvement occurs withinthe context of:• the organization's strategic plans• its business objectives• its organizational structure• the technologies in use• its social culture• its management system


136

Process Management and theCMM in Context

ProcessManagement

HumanResources

TechnicalAssets

Customer-Supplier

Relationship


135

CMM and Quality ManagementThe CMM does not address all the issues thatneed to be faced for software process andquality improvement.

Issues that are addressed only indirectly, orby implication, include:• specific tools, methods, and technologies• concurrent engineering and teamwork• system engineering, marketing, etc.• human resources• change management

View the CMM, assessments, and evaluationsin the larger context.


134

CMM and Business ContextThe CMM is an application of Total QualityManagement principles to software engineering.

Emphasis should be on customer satisfaction.

The result should be higher quality softwareproducts produced by more competitivecompanies.


133

Using the CMM in ContextThe key practices in the CMM areexpressed in terms of a large governmentcontracting organization.

When the business environment differsfrom that template, an appropriateinterpretation of the practices should bemade.

The true CMM "requirements" are thegoals for achieving the key process areas.


132

Scope of the CMM: Using "Key"The CMM is not exhaustive.

There are software management andengineering processes and practices that arenot described in the CMM.

KEY indicates a focus on the major leveragepoints.


131

Using Higher Level PracticesProcesses at higher maturity levels may beperformed, although perhaps ineffectively,even by Level 1 organizations.

Peer reviews can help even a Level 1 project.

Building an organizational capability meansinstitutionalizing good practices on a firmfoundation.


130

TopicsIntroduction

The Capability Maturity Model

Understanding the Initial and Repeatable Levels

Understanding the Defined Level

Understanding the Managed and OptimizingLevels

Conclusion and Discussion


129

A Foundation, Not a Destination

The optimizing level is not the destination ofprocess management.

The destination is better products for a betterprice: economic survival.

The optimizing level is a foundation for buildingan ever-improving capability.


128

The Great Productivity Dip

PresentState Transition

State

DesiredState

PRODUCTIVITY


127

Process Improvement Is aLifestyle Change

Silver Bullet = Diet

95% of all dieters regain the weight they havelost ... and more ... within one year of a diet.

Process Improvement = Lifestyle Change

60% of those who change their lifestyle to eat lessand exercise more maintain their weight loss.


126

Make Change a Normal ProcessRecognize that there are no silver bullets.

Relate improvements to overall plans and goals.

Accept that improvement will come in smallincremental steps.

Recognize that reactive changes generally makethings worse.

Believe that crisis prevention is more importantthan crisis recovery.

Accept continuous improvement as a way of life.


125

Goals of PCM1. Continuous process improvement is

planned.

2. Participation in the organization's softwareprocess improvement activities isorganization-wide.

3. The organization's standard softwareprocess and the projects' defined softwareprocesses are improved continuously.


124

Process Change Management(PC, PCM)Purpose is to continually improve the softwareprocesses used in the organization with theintent of improving software quality, increasingproductivity, and decreasing the cycle time forproduct development

Involves:• defining process improvement goals• systematically identifying, evaluating, and

implementing improvements to theorganization's standard software processand the projects' defined softwareprocesses


123

Technology Transfer Curve

Installation

Awareness

Contact

Understanding

Institutionalization

Adoption

InformationTransition

Pilot Test

TechnologyTransition

Commitment


122

Goals of TCM

1. Incorporation of technology changes isplanned.

2. New technologies are evaluated todetermine their effect on quality andproductivity.

3. Appropriate new technologies aretransferred into normal practice across theorganization.


121

Technology Change Management(TM, TCM)Purpose is to identify new technologies (i.e.,tools, methods, and processes) and transferthem into the organization in an orderlymanner

Involves:• identifying, selecting, and evaluating new

technologies• incorporating effective technologies into

the organization


120

Important Concepts in DP

Kickoff meetings confirm a commonunderstanding of the processes to be followed.

Causal analysis functions best in a stableprocess.


119

Goals of DP

1. Defect prevention activities are planned.

2. Common causes of defects are sought outand identified.

3. Common causes of defects are prioritizedand systematically eliminated.


118

Defect Prevention (DP)

Purpose is to identify the cause of defectsand prevent them from recurring

Involves:• analyzing defects that were encountered in

the past• taking specific actions to prevent the

occurrence of these types of defects in thefuture


117

The Key Process Areas forLevel 5

Optimizing (5)

Process change management Technology change managementDefect prevention


116

The Management View of theSoftware Process at Level 5

The software process is continuouslyimproved in a controlled manner.

In Out


115

Understanding the OptimizingMaturity LevelAutomate, pilot new technologies, dotechnology transition.

Identify and eliminate chronic causes of poorperformance.

Continually improve the software process.

Original zone of quality control

New zone of quality control

Chronic waste

QualityImprovement

Control Chart With Common Causes


114

Goals of SQM

1. The project's software quality managementactivities are planned.

2. Measurable goals for software productquality and their priorities are defined.

3. Actual progress toward achieving thequality goals for the software products isquantified and managed.


113

Software Quality Management(QM, SQM)Purpose is to develop a quantitativeunderstanding of the quality of the project'ssoftware products and achieve specific qualitygoals

Involves:• defining quality goals for the software

products• establishing plans to achieve these goals• monitoring and adjusting software plans,

software work products, activities, andquality goals to satisfy the needs and desiresof customer and end-user


112

The Juran Trilogy DiagramQuality Planning Quality Control (during operations)

Sporadic spike

Original zone of quality control

New zone of quality control

Chronic waste

QualityImprovement

Lessons learned

Time

Cos

t of p

oor

qual

ity

J.M. Juran Wilton, CTUsed with the express permission of the Juran Institute, August 1990.


111

Some Quantitative ToolsBasic statistical process control tools include:• control charts• cause-and-effect (fishbone) diagrams• Pareto charts• scatter diagrams

Advanced tools include:• robust design (Taguchi)• quality function deployment (QFD)


110

Measurement Across MaturityLevelsMyth that measurement occurs only at Level 4

Level 5—improvement and cost/benefit data

Level 4—process and product quality data

Level 3—process data

Level 2—planning and tracking data

Level 1—haphazard data


109

Goals of QPM

1. The quantitative process managementactivities are planned.

2. The process performance of the project'sdefined software process is controlledquantitatively.

3. The process capability of theorganization's standard software processis known in quantitative terms.


108

Quantitative Process Management(QP, QPM)Purpose is to control the processperformance of the software projectquantitatively

Involves:• establishing goals for process performance• measuring the performance of the project• analyzing these measurements• making adjustments to maintain process

performance within acceptable limits


107


Software quality management Quantitative process management

Managed (4)


106


The production of the software product isquantitatively understood throughout thesoftware process.

In Out


105

Understanding the ManagedMaturity LevelApplying the principles of statistical processcontrol, address special causes of processvariation.

Explicitly address the customer's needs aspart of a philosophy of quality management.

Control Chart With Special Causes

Fix the problemin the process


104

TopicsIntroduction







103

Implementations of PR

Possible alternative ways of implementingpeer reviews include:• Fagan-style inspections• structured walkthroughs• active reviews


102

Goals of PR1. Peer review activities are planned.

2. Defects in the software work products areidentified and removed.


101

Peer Reviews (PR)Purpose is to remove defects from thesoftware work products early and efficiently

Important corollary is to develop a betterunderstanding of the software work productsand of defects that might be prevented

Involve a methodical examination of workproducts by the producer's peers to identifydefects and areas where changes are needed


100

Important Concepts in ICIntergroup Coordination deals with theinterface to groups beyond the softwareengineering group and possibly beyond thecontrol of the organization doing softwareprocess improvement.

Examples of these groups, the interface towhich must be managed, include:• systems engineering• marketing• training

Intergroup Coordination is a first step on theroad to concurrent engineering.


99

Goals of IC1. The customer's requirements are agreed

to by all affected groups.

2. The commitments between theengineering groups are agreed to by theaffected groups.

3. The engineering groups identify, track,and resolve intergroup issues.


98

Intergroup Coordination (IC)Purpose is to establish a means for thesoftware engineering group to participateactively with the other engineering groups sothe project is better able to satisfy thecustomer's needs effectively and efficiently

Involves the disciplined interaction andcoordination of the project engineering groupswith each other to address system-levelrequirements, objectives, and plans


97

Important Concepts in SPE

Software Product Engineering includes:• software requirements analysis• software design• coding• integration• testing

Software Product Engineering addresses thetotal software engineering environment.


96

Goals of SPE

1. The software engineering tasks are defined,integrated, and consistently performed toproduce the software.

2. Software products are kept consistent witheach other.


95

Software Product Engineering(PE, SPE)Purpose is to consistently perform awell-defined engineering process thatintegrates all the software engineeringactivities to produce correct, consistentsoftware products effectively and efficiently

Involves performing the engineering tasks tobuild and maintain the software usingappropriate tools and methods


94

Goals of ISM

1. The project's defined software process isa tailored version of the organization'sstandard software process.

2. The project is planned and managedaccording to the project's definedsoftware process.


93

Integrated Software Management(IM, ISM)Purpose is to integrate the project's softwareengineering and management activities into acoherent, defined software process tailoredfrom the organization's software processassets

Involves:• developing the project's defined software

process by tailoring the organization'sstandard software process

• managing the software project according tothis defined software process


92

Important Concepts in TPTraining may include informal as well asformal vehicles for transferring skills andknowledge.

At Level 2, the phrase "receive training" isused. Training at Level 2 is not likely to havebeen institutionalized across theorganization.

At Levels 3 and above, the phrase "receiverequired training" is used. Institutionalizationof training is expected.


91

Goals of TP

1. Training activities are planned.

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

3. Individuals in the software engineeringgroup and software-related groupsreceive the training necessary to performtheir roles.


90

Training Program (TP)

Purpose is to develop the skills andknowledge of individuals so they canperform their roles effectively and efficiently

Involves:• identifying the training needs of the

organization, the projects, andindividuals

• developing and/or procuring training toaddress these needs


89

Library of Software Process-Related DocumentationEstablished to:• store process documents that are

potentially useful to other current andfuture projects

• make them available for sharing across theorganization

Contains example documents and documentfragments


88

Organization's Software ProcessDatabaseEstablished to collect and make availabledata on the software processes and resultingsoftware work products

Contains or references both the actualmeasurement data and the relatedinformation needed to understand themeasurement data and assess it forreasonableness and applicability


87

Tailoring Guidelines

Established to guide the software projects in:• selecting a software life cycle from those

approved for use• tailoring and elaborating the organization's

standard software process and theselected software life cycle to fit thespecific characteristics of the project


86

Software Life CyclesA software life cycle is the period of timethat begins when a software product isconceived and ends when the software is nolonger available for use.

One software life cycle may not beappropriate for all situations, given a varietyof contractual and customer relationships.

An organization may identify more than onesoftware life cycle for use by the projects.


85

Organization's StandardSoftware ProcessThe operational definition of the basic processthat guides the establishment of a commonsoftware process across the software projectsin the organization

Describes the fundamental software processelements that each software project isexpected to incorporate into its definedsoftware process

Describes the relationships (e.g., ordering andinterfaces) between these software processelements (software process architecture)


84

Software Process Assets

Software process assets include:• the organization's standard software

process (including the software processarchitecture and software processelements)

• the descriptions of software life cyclesapproved for use

• the guidelines and criteria for tailoring theorganization's standard software process

• the organization's software processdatabase

• the library of software process-relateddocumentation


83

Goals of OPD

1. A standard software process for theorganization is developed and maintained.

2. Information related to the use of theorganization's standard software processby the software projects is collected,reviewed, and made available.


82

Organization Process Definition(PD, OPD)Purpose is to develop and maintain a usableset of software process assets that improveprocess performance and provide a basis forcumulative, long-term benefits

Involves developing and maintaining theorganization's standard software processand related process assets


81

Important Concepts in OPF

The typical mechanism for providing a processfocus for the organization is the SoftwareEngineering Process Group (SEPG).

Other mechanisms are possible:• process review boards• quality circles• process steering committees

These mechanisms may work in conjunctionwith, or in place of, an SEPG, depending on anorganization's implementation of OrganizationProcess Focus.


80

Goals of OPF

1. Software process development andimprovement activities are coordinatedacross the organization.

2. The strengths and weaknesses of thesoftware processes used are identifiedrelative to a process standard.

3. Organization-level process developmentand improvement activities are planned.


79

Organization Process Focus(PF, OPF)Purpose is to establish the organizationalresponsibility for software processactivities that improve the organization'soverall software process capability

Involves:• developing and maintaining an

understanding of organization andproject software processes

• coordinating the activities to assess,develop, maintain, and improve theseprocesses


78


Defined (3)

Peer reviews Intergroup coordination Software product engineering Integrated software management Training program Organization process definitionOrganization process focus


77


Roles and responsibilities in the processare understood.

The production of the software product isvisible throughout the software process.

In Out


76

Understanding the DefinedMaturity LevelTo control a process, it must be wellunderstood.

Identify the inputs, how they will affect theprocess, and their readiness criteria.

Identify the outputs and the completioncriteria for the outputs.

Establish a shared understanding of how theprocess works and the role of eachparticipant.


75

TopicsIntroduction







74

Managed and Controlled

Some software work products do not needthe formality of configuration managementbut do need to be placed under some form of:• version control• change control

This is referred to as "managed andcontrolled" in the key practices.


73

Baseline Versus DevelopmentalConfiguration ManagementBASELINE CONFIGURATION MANAGEMENT –establish baselines for identified softwarework products at predetermined points

DEVELOPMENTAL CONFIGURATIONMANAGEMENT – control of the configurationexercised by the developers as they performtheir work

The SCM key process area can be satisfiedwith baseline configuration management.


72

Goals of SCM1. Software configuration management

activities are planned.

2. Selected software work products areidentified, controlled, and available.

3. Changes to identified software workproducts are controlled.

4. Affected groups and individuals areinformed of the status and content ofsoftware baselines.


71

Software ConfigurationManagement (CM, SCM)

Purpose is to establish and maintain theintegrity of the products of the softwareproject throughout the software life cycle

Involves:• identifying configuration items/units• systematically controlling changes• maintaining integrity and traceability of

the configuration throughout thesoftware life cycle


70

Important Concepts in SQA

INDEPENDENCE – SQA should beindependent of the software producers andproject management

FITNESS FOR USE – SQA should providefeedback on the usability of the standardsand procedures, as well as process fidelity


69

Goals of SQA1. Software quality assurance activities are

planned.

2. Adherence of software products andactivities to the applicable standards,procedures, and requirements is verifiedobjectively.

3. Affected groups and individuals areinformed of software quality assuranceactivities and results.

4. Noncompliance issues that cannot beresolved within the software project areaddressed by senior management.


68

Software Quality Assurance(QA, SQA)Purpose is to provide management withappropriate visibility into the process beingused and the products being built

Involves:• reviewing and auditing the software

products and activities to ensure that theycomply with the applicable proceduresand standards

• providing the software project and otherappropriate managers with the results ofthose reviews and audits


67

Important Concepts in SM

PRIME CONTRACTOR – the organizationresponsible for building a system, thatcontracts out part of the work to anothercontractor, the SUBCONTRACTOR

Qualified does not mean "best technicallyqualified" or "highest process capability"

Factors other than process capability andtechnical ability influence the qualificationsof subcontractors• strategic business alliances


66

Goals of SM

1. The prime contractor selects qualifiedsoftware subcontractors.

2. The prime contractor and the softwaresubcontractor agree to their commitments toeach other.

3. The prime contractor and the softwaresubcontractor maintain ongoingcommunications.

4. The prime contractor tracks the softwaresubcontractor's actual results andperformance against its commitments.


65

Software SubcontractManagement (SM)Purpose is to select qualified softwaresubcontractors and manage them effectively

Involves:• selecting a software subcontractor• establishing commitments with the

subcontractor• tracking and reviewing the

subcontractor's performance and results


64

Goals of PTO

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

2. Corrective actions are taken and managed toclosure when actual results and performancedeviate significantly from the software plans.

3. Changes to software commitments areagreed to by the affected groups andindividuals.


63

Software Project Tracking andOversight (PT, PTO)Purpose is to provide adequate visibilityinto actual progress so that managementcan take effective actions whenperformance deviates significantly from theplan

Involves:• tracking and reviewing software

accomplishments and results againstdocumented estimates, commitments,and plans

• adjusting plans based on actualaccomplishments and results


62

Software PlansSOFTWARE PLANS – the collection of plans,both formal and informal, used to expresshow software development and/ormaintenance activities will be performed.

SOFTWARE DEVELOPMENT PLAN (SDP) –the collection of plans that describe theactivities to be performed for the softwareproject:• governs the management of the activities

performed by the software engineeringgroup for a software project

• is not limited to the scope of anyparticular planning standard, such asDOD-STD-2167A and IEEE-STD-1058,which may use similar terminology


61

Making CommitmentsCOMMITMENT – a pact that is freely assumed,visible, and expected to be kept by all parties

PROJECT MANAGER – the role with totalbusiness responsibility for an entire project

SENIOR MANAGEMENT – management with aprimary focus on the long-term vitality of theorganization, rather than short-term projectand contractual concerns and pressures


60

Process in Planning

PROCESS – a sequence of steps performed fora given purpose; a set of activities that achievea desired result

METHOD – an approach to be followed inexecuting a process

PROCEDURE – a written description of acourse of action to be taken to perform a giventask

SOFTWARE TOOL – software that providesautomated support for a method


59

Goals of SPP1. Software estimates are documented for use

in planning and tracking the softwareproject.

2. Software project activities and commitmentsare planned and documented.

3. Affected groups and individuals agree totheir commitments related to the softwareproject.


58

Software Project Planning (PP, SPP)

Purpose is to establish reasonable plansfor performing the software engineeringand for managing the software project

Involves:• developing estimates for the work to be

performed• establishing the necessary commitments• defining the plan to perform the work

Plan provides the basis for initiating thesoftware effort and managing the work


57

Important Concepts in RMCUSTOMER – may be external or internal

SYSTEM REQUIREMENTS – the customer'sstatement of the requirements

SYSTEM REQUIREMENTS ALLOCATED TOSOFTWARE (referred to in the CMM usually asallocated requirements) – the subset of thesystem requirements allocated to the softwarepart of the system

SOFTWARE REQUIREMENTS – derived fromsoftware requirements analysis of the allocatedrequirements


56

Goals of RM

1. System requirements allocated to softwareare controlled to establish a baseline forsoftware engineering and managementuse.

2. Software plans, products, and activitiesare kept consistent with the systemrequirements allocated to software.


55

Requirements Management (RM)

Purpose is to establish a commonunderstanding between the customer andthe software project of the customer'srequirements that will be addressed by thesoftware project

Involves establishing and maintaining anagreement with the customer on therequirements for the software project

Agreement is the basis for estimating,planning, performing, and tracking theproject's software activities


54


Software configuration management Software quality assurance Software subcontract management Software project tracking and oversight Software project planningRequirements management

Repeatable (2)


53


Requirements and resources flow in.

The production of the software product isvisible at defined points.

Artifacts of the process are controlled.

In Out


52

Understanding the RepeatableMaturity LevelManagement must "walk the talk" to initiate animprovement effort.

Only with management discipline will goodsoftware engineering practices be retained inthe crunch.

Management processes establish role modelsfor process improvement.

Management – and process – disciplineempowers the engineering processes and thetechnical staff.


51


Requirements flow in.

A software product is (usually) producedby some amorphous process.

The product flows out and (hopefully)works.

In Out


50

A Myth: The Problems AreAll Technical

Examined real cases• red teams• assessment and evaluations

Projects generally fail for management reasons• Defense Science Board Task Force on Military

Software report, 1987• "Bugs in the Program" report, 1989

The major problems in software development aremanagerial - not technical.


49

Typical Level 1 Environments"I'd rather have it wrong than have it late."

A senior software manager (industry)

"The bottom line is schedule. My promotionsand raises are based on meeting schedule firstand foremost."

A program manager (government)

"By regularly putting the development processunder extreme time pressure and then acceptingpoor-quality products, the software usercommunity has shown its true quality standard."

DeMarco and Lister (Peopleware, 1987)


48

Understanding the InitialMaturity LevelPerformance driven by the competence andheroics of the people doing the work

Consistency and compliance to standards drivenby management priorities - usually schedule isthe top priority

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

Unpredictability – for good or ill – characterizesthe initial level organization


47

TopicsIntroduction







46

A Well-Defined ProcessA well-defined process can be characterizedin terms of:• readiness criteria• inputs• standards and procedures for performing

the work• verification mechanisms (e.g., peer

reviews)• outputs• completion criteria


45

A Reasonable Process

A reasonable software process is:• practiced• documented• enforced• trained• measured• able to improve


44

An Example of Decomposing theCMM StructureMaturity Level Level 2 – Repeatable

Key Process Area Software ProjectPlanning

Goal 1. Software estimates are documented ...

Common Feature Activities Performed

Key Practice 9. Estimates for thesize of the softwarework products ...


43

An Example Key Practice:Size EstimatingSoftware Project Planning

Activity 9 Estimates for the size of thesoftware work products (orchanges to the size ofsoftware work products) arederived according to adocumented procedure:

This procedure typicallyspecifies that ...


42

Key Practices

The infrastructures and activities thatcontribute most to the effectiveimplementation and institutionalization of akey process area


41

Verifying ImplementationDescribes the steps to ensure that theactivities are performed in compliance withthe process that has been established

Typical subfeatures include reviews andaudits by:• senior management• project management• software quality assurance


40

Measurement and Analysis

Describes the need to measure the processand analyze the measurements

Typically includes examples of themeasurements that could be taken todetermine the status and effectiveness of theActivities Performed


39

Activities Performed

Describes the roles and proceduresnecessary to implement a key process area

Typical subfeatures include:• establishing plans and procedures• performing the work• tracking it• taking corrective actions as necessary


38

Ability to Perform

Describes the preconditions that must exist inthe project or organization to implement thesoftware process competently

Typical subfeatures include:• resources• organization structure• delegation• training• orientation


37

Commitment to PerformDescribes the actions the organization musttake to ensure that the process is establishedand will endure

Typical subfeatures include:• policies• senior management sponsorship• responsibility


36

Institutionalize and ImplementThe organization outlives those who leave it.

The organizational culture must convey theprocess.

Management must nurture the culture.

Culture is conveyed with role models andrewards.


35

Common FeaturesAttributes that indicate whether theimplementation and institutionalization of akey process area is effective, repeatable, andlasting

Used to organize the key practices in eachkey process area

Common features are:• commitment to perform• ability to perform• activities performed• measurement and analysis• verifying implementation


34

An Example of Goals:Software Project Planning1. Software estimates are documented for

use in planning and tracking the softwareproject.

2. Software project activities andcommitments are planned anddocumented.

3. Affected groups and individuals agree totheir commitments related to the softwareproject.


33

Organization ResponsibilitiesThe organization will have primaryresponsibility for acting on:• Software Quality Assurance• Organization Process Focus• Organization Process Definition• Training Program• Technology Change Management• Process Change Management


32

Project ResponsibilitiesThe project will have primary responsibilityfor acting on:• Requirements Management• Software Project Planning• Software Project Tracking and Oversight• Software Subcontractor Management• Software Configuration Management• Integrated Software Management• Software Product Engineering• Intergroup Coordination• Peer Reviews• Quantitative Process Management• Software Quality Management• Defect Prevention


31

Responsibility for ImplementingKey Process Areas

The project is primarily responsible foraddressing many key process areas.

The organization is primarily responsible foraddressing other key process areas.

There are both project and organizationalresponsibilities in all key process areas.


30

Key Process Areas to AchieveLevel 5

Optimizing (5)

Process change management Technology change managementDefect prevention

Productandprocessquality

Continuousprocessimprovement


29


Software quality management Quantitative process management

Managed (4)

Integratedengineeringprocess

Productandprocessquality


28


Defined (3)

Peer reviews Intergroup coordination Software product engineering Integrated software management Training program Organization process definitionOrganization process focus

Projectmanagement

Integratedengineeringprocess


27


Software configuration management Software quality assurance Software subcontract management Software project tracking and oversight Software project planningRequirements management

Repeatable (2)

Projectmanagement

Ad hoc


26

Key Process AreasIdentify a cluster of related activities that,when performed collectively, achieve a set ofgoals considered important for enhancingprocess capability

Defined to reside at a single maturity level

Identify the issues that must be addressed toachieve a maturity level


25

The Five Maturity Levels

Initial(1)

Repeatable(2)

Defined(3)

Managed(4)

Optimizing(5)

Disciplinedprocess

Standard,consistentprocess

Predictableprocess

Continuouslyimprovingprocess


24

Maturity Levels

MATURITY LEVEL – a well-definedevolutionary plateau on the path towardbecoming a mature software organization• each level is a layer in the foundation for

continuous process improvement• there are five maturity levels in the CMM


23

The CMM StructureMaturity Levels

KeyPractices

contain

contain

Key Process Areas

Implementation orInstitutionalization

Goals

Process Capability

describe

achieve

indicate

organized by

CommonFeatures

address

Infrastructure orActivities


22

Components of the CMM

Maturity Levels Process Capability

Key Process Areas Goals

Common Features Implementation orInstitutionalization

Key Practices Infrastructure orActivities


21

Critical Process Maturity ConceptsPROCESS CAPABILITY — the range of expectedresults that can be achieved by following aprocess, a predictor of future project outcomes

PROCESS PERFORMANCE — a measure of theactual results achieved from following a process

PROCESS MATURITY — the extent to which aspecific process is explicitly defined, managed,measured, controlled, and effective• implies a potential for growth in capability• indicates both the richness of an organization's

software process and the consistency withwhich it is applied


20

CMM Supporting RoleThe CMM should support:• setting goals for senior management• identifying priorities for process

improvement• identifying process capability of

organizations• predicting future process performance of

projects• industry-wide comparisons of the state of

the practice


19

CMM DefinitionA description of the stages through whichsoftware organizations evolve as they define,implement, measure, control, and improvetheir software processes

A guide for selecting process improvementstrategies by facilitating:• determination of current process

capabilities• identification of the issues most critical to

software quality and process improvement


18

What Is the CMM?The application of process management andquality improvement concepts to softwaredevelopment and maintenance

A guide for evolving toward a culture ofengineering excellence

A model for organizational improvement

The underlying structure for reliable andconsistent software process assessments andsoftware capability evaluations


17

MaturityFramework:Five Levels

Optimizing (5)Focus on process improvement

Managed (4)Process measured and controlled

Defined (3)Process characterized,fairly well understood

Repeatable (2)Can repeat previously mastered tasks

Initial (1)Unpredictable andpoorly controlled


16

Maturity Model InspirationsProcess management concepts – Crosby, Deming,Juran, ...

Experience• 30 years of similar software problems• commonly known software problems• solutions exist

Application of common-sense engineering


15

Applying TQM to Software

Software

Organization

TQM

CMM

Project CProject A Project B

Project X SystemHardware

Process improvement fits in an overallbusiness context – CMM applies tosoftware.


14

Common Points in theQuality Movement

Enabling quality improvement is amanagement responsibility.

Quality improvement focuses on fixing theprocess, not the people.

Quality improvement must be measured.

Rewards and incentives are necessary toestablish and maintain an improvement effort.

Quality improvement is a continuous process.


13

Total Quality ManagementTotal Quality Management (TQM) is theapplication of quantitative methods andhuman resources to improve:• the material and services supplied to an

organization• all the processes within an organization• the degree to which the needs of the

customer are met, now and in the future

Department of Defense, Total Quality Management Master Plan,August 1988.


12

The Process Management Premise

The quality of a (software) system is largelygoverned by the quality of the process used todevelop and maintain it.

This premise implies focus on process as wellas product.

The value of this premise is visible world-widein the Total Quality Management movements inthe manufacturing and service industries.


11

Process Provides a Framework

A focus on people causes resistance tochange – people naturally desire to dogood work.

A focus on tools that do not fit into theprocess leads to ineffective automation –and shelfware.

A focus on procedures that do not match theprocess leads to unusable procedures – andshelfware.


10

A Definition of Process

Procedures and methodsdefining the relationship

of tasks

Tools andequipment

Peoplewith skills,

training, andmotivation

PROCESS

The means by which people, procedures,methods, equipment, and tools are integrated toproduce a desired end result.

AB

CD


9

TopicsIntroduction







8

Contacts for General SEIInformationSEI Customer Relations (412) 268-5800

SEI FAX number (412) 268-5758

Internet [email protected]

Mailing AddressCustomer RelationsSoftware Engineering InstituteCarnegie Mellon UniversityPittsburgh, PA 15213-3890


7

SEI Mission and Vision

Our mission is to provide leadership inadvancing the state of the practice ofsoftware engineering to improve thequality of systems that depend onsoftware.

Our vision is to bring engineeringdiscipline to the development andmaintenance of software.


6

The Software EngineeringInstituteFederally funded research and developmentcenter (FFRDC)

Affiliated with Carnegie Mellon University

Established in 1984


5

TopicsIntroduction







4

The Agenda - 2

Understanding the Defined Level 90 mins

Break

Understanding the Managed andOptimizing Levels 60 mins

Conclusion and Discussion 30 mins


3

The Agenda - 1Introduction 15 mins

The Capability Maturity Model 75 mins

Break

Understanding the Initial andRepeatable Levels 90 mins

Lunch


2

Setting Expectations

This tutorial provides• an overview of the Capability Maturity

Model (CMM) for managers and technicalstaff

• an awareness of the concepts of the CMM

This tutorial is not a substitute for training orexperience in applying the CMM.

The audience is expected to be knowledgeableabout software engineering and management.


1

The CapabilityMaturity Model:A TutorialApril 1993

Software Engineering InstituteCarnegie Mellon UniversityPittsburgh, PA 15213

Sponsored by the U.S. Department of Defense

Process Improvement Is - tarrani.net · 1. Continuous process improvement is ... • defining...

Documents

Transcript of Process Improvement Is - tarrani.net · 1. Continuous process improvement is ... • defining...