Upload
guest035e0d
View
123
Download
3
Tags:
Embed Size (px)
DESCRIPTION
This is a very good presentation on SEI CMM. (Althopugh the model has been retired but it still forms the basis for many IT organisations)
Citation preview
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.
Software Engineering InstituteCarnegie Mellon University
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.
Software Engineering InstituteCarnegie Mellon University
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
Software Engineering InstituteCarnegie Mellon University
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.
Software Engineering InstituteCarnegie Mellon University
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
Software Engineering InstituteCarnegie Mellon University
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
Software Engineering InstituteCarnegie Mellon University
136
Process Management and theCMM in Context
ProcessManagement
HumanResources
TechnicalAssets
Customer-Supplier
Relationship
Software Engineering InstituteCarnegie Mellon University
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.
Software Engineering InstituteCarnegie Mellon University
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.
Software Engineering InstituteCarnegie Mellon University
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.
Software Engineering InstituteCarnegie Mellon University
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.
Software Engineering InstituteCarnegie Mellon University
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.
Software Engineering InstituteCarnegie Mellon University
130
TopicsIntroduction
The Capability Maturity Model
Understanding the Initial and Repeatable Levels
Understanding the Defined Level
Understanding the Managed and OptimizingLevels
Conclusion and Discussion
Software Engineering InstituteCarnegie Mellon University
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.
Software Engineering InstituteCarnegie Mellon University
128
The Great Productivity Dip
PresentState Transition
State
DesiredState
PRODUCTIVITY
Software Engineering InstituteCarnegie Mellon University
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.
Software Engineering InstituteCarnegie Mellon University
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.
Software Engineering InstituteCarnegie Mellon University
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.
Software Engineering InstituteCarnegie Mellon University
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
Software Engineering InstituteCarnegie Mellon University
123
Technology Transfer Curve
Installation
Awareness
Contact
Understanding
Institutionalization
Adoption
InformationTransition
Pilot Test
TechnologyTransition
Commitment
Software Engineering InstituteCarnegie Mellon University
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.
Software Engineering InstituteCarnegie Mellon University
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
Software Engineering InstituteCarnegie Mellon University
120
Important Concepts in DP
Kickoff meetings confirm a commonunderstanding of the processes to be followed.
Causal analysis functions best in a stableprocess.
Software Engineering InstituteCarnegie Mellon University
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.
Software Engineering InstituteCarnegie Mellon University
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
Software Engineering InstituteCarnegie Mellon University
117
The Key Process Areas forLevel 5
Optimizing (5)
Process change management Technology change managementDefect prevention
Software Engineering InstituteCarnegie Mellon University
116
The Management View of theSoftware Process at Level 5
The software process is continuouslyimproved in a controlled manner.
In Out
Software Engineering InstituteCarnegie Mellon University
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
Software Engineering InstituteCarnegie Mellon University
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.
Software Engineering InstituteCarnegie Mellon University
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
Software Engineering InstituteCarnegie Mellon University
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.
Software Engineering InstituteCarnegie Mellon University
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)
Software Engineering InstituteCarnegie Mellon University
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
Software Engineering InstituteCarnegie Mellon University
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.
Software Engineering InstituteCarnegie Mellon University
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
Software Engineering InstituteCarnegie Mellon University
107
The Key Process Areas forLevel 4
Software quality management Quantitative process management
Managed (4)
Software Engineering InstituteCarnegie Mellon University
106
The Management View of theSoftware Process at Level 4
The production of the software product isquantitatively understood throughout thesoftware process.
In Out
Software Engineering InstituteCarnegie Mellon University
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
Software Engineering InstituteCarnegie Mellon University
104
TopicsIntroduction
The Capability Maturity Model
Understanding the Initial and Repeatable Levels
Understanding the Defined Level
Understanding the Managed and OptimizingLevels
Conclusion and Discussion
Software Engineering InstituteCarnegie Mellon University
103
Implementations of PR
Possible alternative ways of implementingpeer reviews include:• Fagan-style inspections• structured walkthroughs• active reviews
Software Engineering InstituteCarnegie Mellon University
102
Goals of PR1. Peer review activities are planned.
2. Defects in the software work products areidentified and removed.
Software Engineering InstituteCarnegie Mellon University
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
Software Engineering InstituteCarnegie Mellon University
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.
Software Engineering InstituteCarnegie Mellon University
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.
Software Engineering InstituteCarnegie Mellon University
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
Software Engineering InstituteCarnegie Mellon University
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.
Software Engineering InstituteCarnegie Mellon University
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.
Software Engineering InstituteCarnegie Mellon University
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
Software Engineering InstituteCarnegie Mellon University
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.
Software Engineering InstituteCarnegie Mellon University
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
Software Engineering InstituteCarnegie Mellon University
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.
Software Engineering InstituteCarnegie Mellon University
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.
Software Engineering InstituteCarnegie Mellon University
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
Software Engineering InstituteCarnegie Mellon University
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
Software Engineering InstituteCarnegie Mellon University
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
Software Engineering InstituteCarnegie Mellon University
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
Software Engineering InstituteCarnegie Mellon University
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.
Software Engineering InstituteCarnegie Mellon University
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)
Software Engineering InstituteCarnegie Mellon University
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
Software Engineering InstituteCarnegie Mellon University
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.
Software Engineering InstituteCarnegie Mellon University
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
Software Engineering InstituteCarnegie Mellon University
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.
Software Engineering InstituteCarnegie Mellon University
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.
Software Engineering InstituteCarnegie Mellon University
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
Software Engineering InstituteCarnegie Mellon University
78
The Key Process Areas forLevel 3
Defined (3)
Peer reviews Intergroup coordination Software product engineering Integrated software management Training program Organization process definitionOrganization process focus
Software Engineering InstituteCarnegie Mellon University
77
The Management View of theSoftware Process at Level 3
Roles and responsibilities in the processare understood.
The production of the software product isvisible throughout the software process.
In Out
Software Engineering InstituteCarnegie Mellon University
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.
Software Engineering InstituteCarnegie Mellon University
75
TopicsIntroduction
The Capability Maturity Model
Understanding the Initial and Repeatable Levels
Understanding the Defined Level
Understanding the Managed and OptimizingLevels
Conclusion and Discussion
Software Engineering InstituteCarnegie Mellon University
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.
Software Engineering InstituteCarnegie Mellon University
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.
Software Engineering InstituteCarnegie Mellon University
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.
Software Engineering InstituteCarnegie Mellon University
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
Software Engineering InstituteCarnegie Mellon University
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
Software Engineering InstituteCarnegie Mellon University
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.
Software Engineering InstituteCarnegie Mellon University
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
Software Engineering InstituteCarnegie Mellon University
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
Software Engineering InstituteCarnegie Mellon University
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.
Software Engineering InstituteCarnegie Mellon University
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
Software Engineering InstituteCarnegie Mellon University
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.
Software Engineering InstituteCarnegie Mellon University
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
Software Engineering InstituteCarnegie Mellon University
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
Software Engineering InstituteCarnegie Mellon University
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
Software Engineering InstituteCarnegie Mellon University
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
Software Engineering InstituteCarnegie Mellon University
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.
Software Engineering InstituteCarnegie Mellon University
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
Software Engineering InstituteCarnegie Mellon University
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
Software Engineering InstituteCarnegie Mellon University
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.
Software Engineering InstituteCarnegie Mellon University
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
Software Engineering InstituteCarnegie Mellon University
54
The Key Process Areas forLevel 2
Software configuration management Software quality assurance Software subcontract management Software project tracking and oversight Software project planningRequirements management
Repeatable (2)
Software Engineering InstituteCarnegie Mellon University
53
The Management View of theSoftware Process at Level 2
Requirements and resources flow in.
The production of the software product isvisible at defined points.
Artifacts of the process are controlled.
In Out
Software Engineering InstituteCarnegie Mellon University
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.
Software Engineering InstituteCarnegie Mellon University
51
The Management View of theSoftware Process at Level 1
Requirements flow in.
A software product is (usually) producedby some amorphous process.
The product flows out and (hopefully)works.
In Out
Software Engineering InstituteCarnegie Mellon University
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.
Software Engineering InstituteCarnegie Mellon University
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)
Software Engineering InstituteCarnegie Mellon University
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
Software Engineering InstituteCarnegie Mellon University
47
TopicsIntroduction
The Capability Maturity Model
Understanding the Initial and Repeatable Levels
Understanding the Defined Level
Understanding the Managed and OptimizingLevels
Conclusion and Discussion
Software Engineering InstituteCarnegie Mellon University
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
Software Engineering InstituteCarnegie Mellon University
45
A Reasonable Process
A reasonable software process is:• practiced• documented• enforced• trained• measured• able to improve
Software Engineering InstituteCarnegie Mellon University
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 ...
Software Engineering InstituteCarnegie Mellon University
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 ...
Software Engineering InstituteCarnegie Mellon University
42
Key Practices
The infrastructures and activities thatcontribute most to the effectiveimplementation and institutionalization of akey process area
Software Engineering InstituteCarnegie Mellon University
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
Software Engineering InstituteCarnegie Mellon University
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
Software Engineering InstituteCarnegie Mellon University
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
Software Engineering InstituteCarnegie Mellon University
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
Software Engineering InstituteCarnegie Mellon University
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
Software Engineering InstituteCarnegie Mellon University
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.
Software Engineering InstituteCarnegie Mellon University
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
Software Engineering InstituteCarnegie Mellon University
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.
Software Engineering InstituteCarnegie Mellon University
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
Software Engineering InstituteCarnegie Mellon University
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
Software Engineering InstituteCarnegie Mellon University
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.
Software Engineering InstituteCarnegie Mellon University
30
Key Process Areas to AchieveLevel 5
Optimizing (5)
Process change management Technology change managementDefect prevention
Productandprocessquality
Continuousprocessimprovement
Software Engineering InstituteCarnegie Mellon University
29
Key Process Areas to AchieveLevel 4
Software quality management Quantitative process management
Managed (4)
Integratedengineeringprocess
Productandprocessquality
Software Engineering InstituteCarnegie Mellon University
28
Key Process Areas to AchieveLevel 3
Defined (3)
Peer reviews Intergroup coordination Software product engineering Integrated software management Training program Organization process definitionOrganization process focus
Projectmanagement
Integratedengineeringprocess
Software Engineering InstituteCarnegie Mellon University
27
Key Process Areas to AchieveLevel 2
Software configuration management Software quality assurance Software subcontract management Software project tracking and oversight Software project planningRequirements management
Repeatable (2)
Projectmanagement
Ad hoc
Software Engineering InstituteCarnegie Mellon University
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
Software Engineering InstituteCarnegie Mellon University
25
The Five Maturity Levels
Initial(1)
Repeatable(2)
Defined(3)
Managed(4)
Optimizing(5)
Disciplinedprocess
Standard,consistentprocess
Predictableprocess
Continuouslyimprovingprocess
Software Engineering InstituteCarnegie Mellon University
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
Software Engineering InstituteCarnegie Mellon University
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
Software Engineering InstituteCarnegie Mellon University
22
Components of the CMM
Maturity Levels Process Capability
Key Process Areas Goals
Common Features Implementation orInstitutionalization
Key Practices Infrastructure orActivities
Software Engineering InstituteCarnegie Mellon University
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
Software Engineering InstituteCarnegie Mellon University
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
Software Engineering InstituteCarnegie Mellon University
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
Software Engineering InstituteCarnegie Mellon University
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
Software Engineering InstituteCarnegie Mellon University
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
Software Engineering InstituteCarnegie Mellon University
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
Software Engineering InstituteCarnegie Mellon University
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.
Software Engineering InstituteCarnegie Mellon University
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.
Software Engineering InstituteCarnegie Mellon University
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.
Software Engineering InstituteCarnegie Mellon University
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.
Software Engineering InstituteCarnegie Mellon University
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.
Software Engineering InstituteCarnegie Mellon University
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
Software Engineering InstituteCarnegie Mellon University
9
TopicsIntroduction
The Capability Maturity Model
Understanding the Initial and Repeatable Levels
Understanding the Defined Level
Understanding the Managed and OptimizingLevels
Conclusion and Discussion
Software Engineering InstituteCarnegie Mellon University
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
Software Engineering InstituteCarnegie Mellon University
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.
Software Engineering InstituteCarnegie Mellon University
6
The Software EngineeringInstituteFederally funded research and developmentcenter (FFRDC)
Affiliated with Carnegie Mellon University
Established in 1984
Software Engineering InstituteCarnegie Mellon University
5
TopicsIntroduction
The Capability Maturity Model
Understanding the Initial and Repeatable Levels
Understanding the Defined Level
Understanding the Managed and OptimizingLevels
Conclusion and Discussion
Software Engineering InstituteCarnegie Mellon University
4
The Agenda - 2
Understanding the Defined Level 90 mins
Break
Understanding the Managed andOptimizing Levels 60 mins
Conclusion and Discussion 30 mins
Software Engineering InstituteCarnegie Mellon University
3
The Agenda - 1Introduction 15 mins
The Capability Maturity Model 75 mins
Break
Understanding the Initial andRepeatable Levels 90 mins
Lunch
Software Engineering InstituteCarnegie Mellon University
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.
Software Engineering InstituteCarnegie Mellon University
1
The CapabilityMaturity Model:A TutorialApril 1993
Software Engineering InstituteCarnegie Mellon UniversityPittsburgh, PA 15213
Sponsored by the U.S. Department of Defense