Vinyl Siding Institute’s installation manual here> Siding Institute’s installation manual here>
1 Introduction to the Software Engineering Institute’s (SEI) Capability Maturity Model (CMM)...
-
Upload
theodora-manning -
Category
Documents
-
view
218 -
download
0
Transcript of 1 Introduction to the Software Engineering Institute’s (SEI) Capability Maturity Model (CMM)...
1
Introduction to the
Software Engineering Institute’s (SEI)
Capability Maturity Model (CMM)
“Improving what you build means
improving how you build”
2
AgendaAgenda
• Some interesting “Facts & Figures”• The Software Engineering Institute (SEI)• What Capability Maturity Model (CMM) for
Software means?• Structure of CMM• The Five Maturity Levels of CMM• Understanding the Five Maturity Levels• How Mahindra Satyam achieved SEI-CMM level 5
3
Cobb’s Paradox
“We know why projects fail, we know how to prevent their failure....so why do they still
fail?”
Martin Cobb
Treasury Board of Canada Secretariat
Ottawa, Canada
4
• For every 100 IT projects started, 94 are “restarted”
• Average IT project cost overrun is 178% in large
companies
• Average IT project time overrun is 230% in large
companies
• 42% of original features proposed of IT projects in large
companies actually get ported in the final product
The Need for Better Planning and ManagingThe Need for Better Planning and Managing
5
The reasons projects succeed:– User Involvement
– Executive Management Support (Active interest)
– Clear Statement of Requirements
– Proper Planning
– Realistic Expectations
– Smaller Project Milestones (Visibility)
– Competent Staff
– Ownership
– Clear Vision and Objectives
– Risk Planning, Identification and Mitigation
Project Success ProfilesProject Success Profiles
6
• 31.1 % of all projects were canceled before they are completed.
• 52.7% of projects cost 189% of their original estimates
• The cost for IT projects in American Companies and in the government that were canceled before implementation in 1995 is estimated at $81 billion dollars.
• The cost of overruns for the same period (in addition to canceled projects) is estimated at $59 billion.
Industry IT Project Facts: 1995Industry IT Project Facts: 1995
7
• Lost opportunities cost is not measurable, but could be in the trillions of dollars. Remember Denver; the cost of not having the baggage system working was costing the City of Denver $1.1 million dollars a day.
• Only 9% of projects in large companies come in on budget and on schedule.
More Industry Project FactsMore Industry Project Facts
8
SUCCESS CRITERIA POINTS
– User Involvement 19– Executive Management Support 16– Clear Statement of Requirements 15– Proper Planning 11– Realistic Expectations 10– Smaller Project Involvement 09– Competent Staff 08– Ownership 06– Clear Vision and Objectives 03– Hard-Working and Focused Staff 03
100
Industry Project Success CriteriaIndustry Project Success Criteria
9
• SEI, formed in 1984, began an examination of organizations that were recognized for producing high quality software products that were delivered on-time and within budget.
• Approximately 87 organizations were identified and examined, some of which were excluded from the study.
• The processes used by the remaining organizations were examined and the most common practices were then cataloged as the Key Practices and grouped into Key Process Areas (KPAs).
• The KPAs were grouped into levels of capability. The maturity levels were derived from TQM literature and applied to software.
Evolution of the CMMEvolution of the CMM
10
A Mature ProcessA Mature Process
• Consistent With The Way Work Actually Gets Done
• Defined, Documented, And Continuously Improving
• Supported Visibly By Management And Others• Well Controlled - Process Fidelity Is Audited And
Enforced• Requires Constructive Use Of Product And
Process Measurement• Means Disciplined Use Of Technology
11
Institutionalized ProcessInstitutionalized Process
“That Is The Way We Do Things Around Here”• The Organization Builds An Infrastructure That
Contains Effective, Usable, And Consistently Applied Processes
• 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
12
Risk
Significant Reductionin Development Risk
CMM Level......1..... .....2..... .....3..... .....4..... .....5.....
Productivity
34% Decrease in Cost to Develop
CMM Level......1..... .....2..... .....3..... .....4..... .....5.....
Quality
52% Decrease in Product Errors
CMM Level......1..... .....2..... .....3..... .....4..... .....5.....
Time to Market
15% Decrease in Time to Deliver
CMM Level......1..... .....2..... .....3..... .....4..... .....5.....
Benefits of Using CMM ModelBenefits of Using CMM Model
13
• Models are simplifications of the real world
• Models are not comprehensive
• Interpretation and tailoring must be aligned to business objectives
• Judgment is necessary to use models correctly and with insight
RisksRisks of Model-Based Improvements? of Model-Based Improvements?
14
ISO• Prescriptive
• Standard - Organizations must comply
• Identifies what “must” be done and by whom
• Looks at process existence, execution not at “goodness”
• Requires process improvement activities
• Focused on Quality Management System
CMM• Descriptive
• Model - Must be tailored to organization’s business environment
• Describes successful software development practices
• Expects processes to “make sense” to organization
• Focused process improvement of business practices
• Requires tailoring of process to project needs
How ISO and the CMM DifferHow ISO and the CMM Differ
15
• The CMM is a model. A reasonable interpretation of the CMM practices and professional judgment in application is necessary.
• The CMM was written to address the process for large, complex software efforts.
• Early efforts in tailoring the CMM indicate that in excess of 90% of key practices are applicable as written when interpreted in the context of the specific applications for both large and small organizations.
Common Sense IssuesCommon Sense Issues
16
Structure of CMMStructure of CMM
Maturity Levels
Key Practices
contain
contain
Key Process Areas
Implementation or
Institutionalization
Goals
Process Capability
describe
achieve
indicate
organized by
Common Features
address
Infrastructure or Activities
17
Maturity LevelsMaturity Levels
• Well-defined Evolutionary Plateaus On The Path To Becoming A Mature Software Organization
• Each Level Is A Layer In The Foundation For Continuous Process Improvement
• Achieving Each Level Establishes A Different Component Of The Software Process
• Maturity Levels Are Described In Terms Of 18 Key Process Areas
18
Maturity Levels Provide Orderly Path Maturity Levels Provide Orderly Path for SPIfor SPI
• Process capability is built in stages – This does not imply a ladder - some processes are ineffective
when others are not stable
• Each level provides a foundation for improvements at the next level– engineering process is easily sacrificed without management
discipline
– detailed measures are inconsistent without a defined process
– effect of process innovation is obscure in a noisy process
19
The Five Maturity LevelsThe Five Maturity Levels
Initial (1)
Repeatable (2)
Defined (3)
Managed (4)
Optimizing (5)
Disciplined process
Standard, consistent process
Predictable process
Continuously improving process
Process unpredictable andpoorly controlled
Projects can repeat previouslymastered tasks
Process characterized,fairly well understood
Process measuredand controlled
Focus on ProcessImprovement
20
GoalsGoals
• Goals Summarize The Key Practices Of The Key Process Areas
• They Are Considered Important For Enhancing Process Capability For That Level Of Maturity
• They Can Be Used To Guide Organizations And Appraisal Teams In Assessing Alternative Ways To Implement Key Process Areas
• Each Key Process Maps To One Or More Goals
21
Goals - an exampleGoals - an example
Software Project Planning
• Software estimates are documented for use in planning and tracking the software project
• Software project activities and commitments are planned and documented
• Affected groups and individuals agree to their commitments related to the software project.
22
Common FeaturesCommon Features
The common features across all the Five Maturity Levels:
• Commitment to Perform• Ability to Perform• Activities to Perform• Measurement and Analysis• Verification of Implementation
............Address Institutionalization and Implementation
23
Commitment to PerformCommitment to Perform
• Describes The Actions The Organization Must Take To Ensure That The Process Is Established And Will Endure
• Typically Include
– Policies– Leadership
24
Commitment to Perform - an exampleCommitment to Perform - an example
Software Project Planning
• A project manager is designated to be responsible for negotiating commitments and developing the project's software development plan.
• The project follows a written organizational policy for planning a software project.
25
Ability to PerformAbility to Perform
• Describes the Preconditions that must Exist in the Project or Organization to Implement the Software Process Competently
• Typically Includes– Function– Resources– Delegation– Training– Orientation
26
Ability to Perform - an exampleAbility to Perform - an example
Software Project Planning
• A documented and approved statement of work exists for the software project
• Responsibilities for developing the software development plan are assigned
• Adequate resources and funding are provided for planning the software project
• The software managers, software engineers, and other individuals involved in the software project planning are trained in the software estimating and planning procedures applicable to their areas of responsibility
27
Activities PerformedActivities Performed
• Describes the Roles and Procedures Necessary to Implement a Key Process Area
• Typically Includes
– Establishing Plans and Procedures– Performing the Work– Tracking It– Taking Corrective Actions as Necessary
28
Activities Performed - an exampleActivities Performed - an example
Software Project Planning (some key practices)
• Software project planning is initiated in the early stages of, and in parallel with, the overall project planning
• The project's software development plan is developed according to a documented procedure
• Estimates for the software project's effort and costs are derived according to a documented procedure
• Software planning data are recorded
29
Measurement And AnalysisMeasurement And Analysis
• Describes the Need to Measure the Process and Analyse the Measurements
• Typically Includes Examples of the Measurements that could be taken to determine the Status and Effectiveness of the Activities Performed Common Feature
30
MeasurementMeasurement and Analysis - an and Analysis - an exampleexample
Software Project Planning
• Measurements are made and used to determine the status of the software planning activities
31
Verifying ImplementationVerifying Implementation
• Describes the Steps to Ensure that the Activities are Performed in Compliance with the Process that has been Established
• Typically Includes Reviews and Audits by
– Senior Management– Project Management– Software Quality Assurance
32
Verifying Implementation - an Verifying Implementation - an exampleexample
Software Project Planning
• The activities for software project planning are reviewed with senior management on a periodic basis
• The activities for software project planning are reviewed with the project manager on both a periodic and event-driven basis
• The software quality assurance group reviews and/or audits the activities and work products for software project planning and reports the results
33
Key PracticesKey Practices
• State the Fundamental Policies, Procedures, and Activities for a Key Process Area
• Describe “What” is to be Done, but they should not be Interpreted as Mandating “How”
34
Understanding the Five Maturity LevelsUnderstanding the Five Maturity Levels
• the concept of that Maturity Level
• how that Maturity Level is an improvement over the earlier Level
• the Key Process Areas of that Level
• the purpose of each Key Process Area at that Level
35
The Five Maturity LevelsThe Five Maturity Levels
• Level 1 - Initial Maturity Level
• Level 2 - Repeatable Maturity Level
• Level 3 - Defined Maturity Level
• Level 4 - Managed Maturity Level
• Level 5 - Optimizing Maturity Level
36
Initial Maturity Level (Level 1)Initial Maturity Level (Level 1)
• Performance driven by competence and heroics of the people doing the work
• High quality and exceptional performance possible so long as the best people can be hired
• During a crisis, projects typically abandon planned procedures and revert to coding and testing
• Unpredictable schedules, budgets, functionality and product quality-for good or ill
• The major problems facing the organization are managerial, not technical
37
Initial Maturity Level (Level 1)Initial Maturity Level (Level 1)
• Requirements flow in
• A software product is (usually) produced by some amorphous process
• The product flows out and (hopefully) works
OutIn
Software Management is a Black Art
38
Key Process Areas for Key Process Areas for Initial Maturity Level (Level 1)Initial Maturity Level (Level 1)
No key process areas for the Maturity Level 1
39
The Five Maturity LevelsThe Five Maturity Levels
• Level 1 - Initial Maturity Level
• Level 2 - Repeatable Maturity Level
• Level 3 - Defined Maturity Level
• Level 4 - Managed Maturity Level
• Level 5 - Optimizing Maturity Level
40
Repeatable Maturity Level (Level 2)Repeatable Maturity Level (Level 2)
• Effective software project management is established and institutionalized
• Software project management processes are documented and followed
• Organizational policies guide the projects in establishing management processes
• Successful practices developed on earlier projects can be repeated
• Projects plan and track costs, schedules, size, effort and functionality
41
Repeatable Maturity Level (Level 2)Repeatable Maturity Level (Level 2)
• Process of building software is a series of black boxes with defined checkpoints (milestones)
In Out
Project Management System is in Place
42
• The predominant need is to establish effective software project management
• Software project management processes are documented and followed
• Organizational policies guide the projects in establishing management processes
• Successful practices developed on earlier projects can be repeated
Repeatable Maturity LevelRepeatable Maturity Level
43
Key Process Areas forKey Process Areas forRepeatable Level (Level 2)Repeatable Level (Level 2)
• Software Configuration Management
• Software Quality Assurance
• Software Subcontract Management
• Software Project Tracking and Oversight
• Software Project Planning
• Requirements Management
44
Requirements ManagementRequirements Management
• Establish a common understanding between the customer and the software project of the customer's requirements
• Involves establishing and maintaining an agreement with the customer on the requirements
45
Software Project PlanningSoftware Project Planning
• Establish reasonable plans for performing the software engineering and for managing the project
• Involves developing estimates for the work, establishing the necessary commitments, and defining the plan
46
• A software development plan specifies many or all of the following:– the project’s chosen software life cycle model– a list of the products to be developed– criteria for peer reviews – estimates for level of effort (number of people (and skills),
cost, schedules, etc.)– facilities, support tools, and hardware– project risks
What is in a Software Development Plan?What is in a Software Development Plan?
47
Software Project Tracking Software Project Tracking and Oversightand Oversight
• To provide adequate visibility into the actual progress
• Involves tracking and reviewing the software accomplishments and results against documented estimates, commitments, and plans, and adjusting these plans based on actuals
48
Software Quality AssuranceSoftware Quality Assurance
• To provide management with appropriate visibility into the process being used by the project
• Involves reviewing and auditing the products and activities to verify that they comply with the applicable procedures and providing the project and other managers with the results of these reviews and audits
49
SQA EvolvesSQA Evolves
• Proactive SQA functions as a value-adding member of the project team– SQA starts early in the project
– SQA helps prepare and review procedures, plans and standards
• At higher levels, the CMM provides flexibility for SQA to function pro-actively to drive improvements in the software process and product
50
Barriers to SQABarriers to SQA
• Disbelief in the value of SQA
• Standards and procedures that don’t add value
• Lack of respect of SQA by the software engineering group
• Unqualified SQA staff members
• Shoot the messenger
51
Software Configuration ManagementSoftware Configuration Management
• Establish and maintain the integrity of the products of the project throughout the life cycle
• Involves -– identifying the configuration of the software at given points in
time,
– systematically controlling changes to the configuration,
– maintaining the integrity and traceability of the configuration throughout the life cycle
52
Improvement of Improvement of Level 2Level 2 Over Over Level 1Level 1
• At Level 1, an Organization gets the Job Done
• At Level 2, a Software Project Management System is in Place
• The Organization Sets Expectations Via Policies
• Level 2 Projects Have Disciplined Process
53
The Five Maturity LevelsThe Five Maturity Levels
• Level 1 - Initial Maturity Level
• Level 2 - Repeatable Maturity Level
• Level 3 - Defined Maturity Level
• Level 4 - Managed Maturity Level
• Level 5 - Optimizing Maturity Level
54
Defined Maturity Level (Level 3)Defined Maturity Level (Level 3)
• Maturity Level 3 builds on the software project management foundation
• A Software Engineering Process Group (SEPG) exists and is responsible for the organization’s software process activities
• An Organization Standard Software Process (OSSP) is established for both software engineering and project management
• Projects tailor the OSSP to architect the Project’s software process
55
Defined Maturity Level (Level 3)Defined Maturity Level (Level 3)
• Roles and responsibilities in the process are understood
• The process followed for the software product is visible throughout the Project
In Out
Managed according to a Well-Defined Process
56
Key Process Areas forKey Process Areas forDefined Level (Level 3)Defined Level (Level 3)
• Organization Process Focus
• Organization Process Definition
• Training Program
• Integrated Software Management
• Software Product Engineering
• Intergroup Coordination
• Peer Reviews
57
Organization Process FocusOrganization Process Focus
• Establish the organizational responsibility for software process activities that improve the organization's overall software process capability
• Involves developing and maintaining an understanding of the organization's and projects' software processes and coordinating the activities to assess, develop, maintain, and improve these processes
58
Organization Process DefinitionOrganization Process Definition
• Develop and maintain a usable set of software process assets that improve process performance across the projects and provide a basis for cumulative, long-term benefits to the organization
• Involves developing and maintaining the organization's standard software process, along with related process assets, such as descriptions of software life cycles, process tailoring guidelines and criteria, the organization's software process database, and a library of software process-related documentation
59
Tailoring GuidelinesTailoring Guidelines(or, How to use the Standard Software Process)(or, How to use the Standard Software Process)
• Guidelines for tailoring the organization's standard software process are available to individual projects.
• What can be tailored out? What cannot?
• How much can a process element be modified?
• What parts of a process element should be considered for tailoring?
60
Relation of OPF to OPDRelation of OPF to OPD
• OPF and OPD are tightly coupled
• Organization Process Focus centers on the “who” controls and manages the process
• Organization Process Definition focuses the “what” aspects of the documented process
61
Training ProgramTraining Program
• Develop the skills and knowledge of individuals
• Involves first identifying the training needed by the organization, projects, and individuals, then developing or procuring training to address the identified needs
62
Integrated Software ManagementIntegrated Software Management
• Integrate the software engineering and management activities into a coherent, defined software process
• Involves developing the project's defined software process and managing the project using this process. The project's defined software process is tailored from the OSSP to address the specific characteristics of the project.
63
Software Product EngineeringSoftware Product Engineering
• Consistently perform a well-defined engineering process that integrates all the software engineering activities to produce correct, consistent software products effectively and efficiently.
• Involves performing the engineering tasks to build and maintain the software using the project's defined software process (which is described in the Integrated Software Management key process area) and appropriate methods and tools
64
Intergroup CoordinationIntergroup Coordination
• Establish a means for the software engineering group to participate actively with the other engineering groups
• Involves the software engineering group's participation with other project engineering groups to address system-level requirements, objectives, and issues.
65
Peer ReviewsPeer Reviews
• Remove defects from the software work products early and efficiently. An important corollary effect is to develop a better understanding of the software work products and of defects that might be prevented
• Involve a methodical examination of software work products by the producers' peers to identify defects and areas where changes are needed
66
Improvement of Improvement of Level 3Level 3 Over Over Level 2Level 2
• At Level 2, the Focus is On Projects
• At Level 3, the Emphasis Shifts to the Organization– Best Practices are gathered across the Organization
– Processes are Tailored as Appropriate
• The Organization Supports the Projects by Establishing – Common Processes
– Common Measurements
– Training
67
The Five Maturity LevelsThe Five Maturity Levels
• Level 1 - Initial Maturity Level
• Level 2 - Repeatable Maturity Level
• Level 3 - Defined Maturity Level
• Level 4 - Managed Maturity Level
• Level 5 - Optimizing Maturity Level
68
Managed Maturity Level (Level 4)Managed Maturity Level (Level 4)
• The process is measured with well defined and consistent measurements across all projects
• The process operates within quantified bounds. The organization applies the principles of statistical process control to address special causes of variation
• These measurements enable projects to set and control quantitative quality goals for both software products and processes
• Software products are of predictably quality
69
Managed Maturity Level (Level 4)Managed Maturity Level (Level 4)
• Management has an objective basis for making decisions
• Management is able to predict performance within quantified bounds
In Out
Product and Process are Quantitatively Managed
70
Key Process Areas forKey Process Areas forManaged Level (Level 4)Managed Level (Level 4)
• Software Quality Management
• Quantitative Process Management
71
Quantitative Process ManagementQuantitative Process Management
• Control the process performance of the software project quantitatively. Software process performance represents the actual results achieved from following a software process
• The focus is on identifying special causes of variation within a measurably stable process and correcting, as appropriate, the circumstances that drove the transient variation to occur
72
Controlling Special Causes of VariationControlling Special Causes of Variation
• An important concern is identifying variations in performance that are not within the normal range of process performance– “extraordinary” events outside the bounds of normal process
capability
Control Chart with Special Causes
73
Software Quality ManagementSoftware Quality Management
• Develop a quantitative understanding of the quality of the project's software products and achieve specific quality goals
• SQM applies a comprehensive measurement program to the software work products described in SPE
74
Satisfactory KnowledgeSatisfactory Knowledge
“When you can measure what you are speaking about, and express it in numbers, you know something about it; but when you cannot measure it, when you cannot express it in numbers, your knowledge is of a meager and unsatisfactory kind.”
Lord Kelvin
75
At the Managed LevelAt the Managed Level
• Data is collected and analyzed throughout the projects in the organization
• Measurable product quality goals are defined and used
• When performance falls outside expected limits, something is done
• The quality focus is on customer satisfaction
76
Improvement of Improvement of Level 4Level 4 Over Over Level 3Level 3
• At Level 3, Measurements have been Defined and Collected Systematically
• At Level 4, Decisions are made Based On Data Collected
• Common Measurement
• Data Analysis
77
The Five Maturity LevelsThe Five Maturity Levels
• Level 1 - Initial Maturity Level
• Level 2 - Repeatable Maturity Level
• Level 3 - Defined Maturity Level
• Level 4 - Managed Maturity Level
• Level 5 - Optimizing Maturity Level
78
Optimizing Maturity Level (Level 5)Optimizing Maturity Level (Level 5)
• Continuously improve the software process
• Identify and eliminate the chronic causes of poor performance
• Prevent the occurrence of defects
• Innovations using new technologies and methods
79
Optimizing Maturity Level (Level 5)Optimizing Maturity Level (Level 5)
At this Level, Disciplined change is a way of life
In Out
Focus on Continuous Process Improvement
80
• 95% of all dieters regain the weight they have lost . . . and more. . . within one year of a diet
• 60% of those who change their lifestyle to eat less and exercise more maintain their weight loss
Process Improvement is a Lifestyle ChangeProcess Improvement is a Lifestyle Change
81
Key Process Areas forKey Process Areas forOptimizing Level (Level 5)Optimizing Level (Level 5)
• Defect Prevention
• Technology Change Management
• Process Change Management
82
Defect PreventionDefect Prevention
• Identify the causes of defects and prevent them from recurring.
• Process changes of general value are transitioned to other software projects, as is described in PCM
83
Technology Change ManagementTechnology Change Management
• Identify beneficial new technologies (i.e., tools,
methods, and processes) and transfer them into the organization in an orderly manner, as is described in PCM
• The focus of TCM is on performing innovation efficiently in an ever-changing world
84
Technology Transfer CurveTechnology Transfer Curve
TechnologyTransition
Pilot Test
InformationTransition Contact
AwarenessUnderstanding
Commitment
Installation
Adoption
Institutionalization
85
Process Change ManagementProcess Change Management
• Continually improve the software processes used in the organization with the intent of improving software quality, increasing productivity, and decreasing the cycle time for product development
• PCM takes the incremental improvements of DP and the innovative improvements of TCM and makes them available to the entire organization
86
Change is a ProcessChange is a Process
• Disciplined change is the key to success
• Improvement includes planning
– evaluating improvement proposals and planning actions
– establishing process improvement teams
– conducting pilot programs for process improvement
– updating procedures, training, etc.
• Improvements are transferred into everyday practice across the organization
87
Improvement of Improvement of Level 5Level 5 Over Over Level 4Level 4
• At Level 4, the Process is Quantitatively Understood
• At Level 5, Continuous Process Improvement is a Way of Life
• In Immature Organizations, No One May Be Responsible for Process Improvement
• Mature Organizations Usually Have 70-80% Participation in Improvement Activities at any given Point In Time
88
Level 5 is not the DestinationLevel 5 is not the Destination
• Level 5 is a foundation for building an ever-improving capability
• Level 5 organizations continuous improvements are:– incremental (Kaizen)– revolutionary (innovation)
• Everyone in a Level 5 organization is involved in improvement
89
Themes in the CMMThemes in the CMM
• Continuous improvement• Defined, documented and used processes• Commitment by senior management• Stable processes• Measured processes• Controlled processes• Processes evolve
90
Continuous ImprovementContinuous Improvement
• Processes must be able to improve if we are to achieve continuous process improvement
• In mature organizations, processes are “living” entities, which are supported and maintained
• Everyone is involved in continuous process improvement
91
Defined, Defined, DocumentedDocumented, and Used, and Used
• Processes are documented
• Processes are practiced as documented
• Only procedures that will be used are written
• “Say what you do; do what you say.” or, for the younger set, “Talk the talk, then walk the talk.”
92
Commitment By Senior Commitment By Senior ManagementManagement
• Policies provide a way of establishing expectations for the behavior of everyone in the organization
• Written organizational policies are in Commitment to Perform
93
Stable ProcessesStable Processes
• Training is a way to establishing normal, consistent ways for performing an activity
• Training helps to ensure that everyone understands the process
• Training and orientation practices are in Ability to Perform
• Organizational training needs are addressed by the Training Program key process area.
94
Measured ProcessesMeasured Processes
• Measurement of both product and process is an integral part of every key process area
• Measures of the processes defined in each key process area are in Measurement and Analysis
• Typically measures are of status and effectiveness of processes
• Measurements necessary to implement the process (such as size estimates in Software Project Planning) are in Activities Performed
95
Controlled ProcessesControlled Processes
• The process must be verified and validated to ensure that it is really practiced
• The CMM emphasizes SQA– Software Quality Assurance key process area
– Verifying Implementation common feature
– The feasibility of alternative ways of verifying and validating the process depends on organizational culture
96
Processes EvolveProcesses Evolve
• Implies that the way people do a job will change (improve) over time
• Frequently includes the use of more powerful tools and methods
• Means that a “cultural shift” is under way because people are changing the way they do things
97
Organizational ContextOrganizational Context
• Each organization must interpret levels of excellence in the context of that organization's business environment
• The CMM works best when practices are interpreted in a way that makes sense for the organization
98
Interpreting the CMM Interpreting the CMM
• The CMM is applicable to different types of organizations
• Key practices have to be interpreted
99
The CMM is a ModelThe CMM is a Model
• A model – is a hypothetical or stylized representation
– is inert
– cannot solve anything
• The management of an organization is responsible for satisfying business objectives. The CMM, as a model, and currently the best software process model in existence, can help an organization improve software processes when it is diligently applied by knowledgeable individuals backed by management commitment
100
ConclusionsConclusions
• Software development and maintenance is difficult even with a disciplined process
• The CMM is one (but not the only) tool for understanding and describing the software process
104
Presentation OverviewPresentation Overview
• CBA - IPI Assessment
• What does Level 5 mean for Satyam
• What Level 5 does not mean
• What made the difference
• What it means to Satyamites
• Improvement opportunities identified
• … To Summarize
105
CBA-IPI AssessmentCBA-IPI Assessment
(CMM Based Assessment - (CMM Based Assessment - Internal Process Improvements)Internal Process Improvements)
106
Assessment TeamAssessment Team
Assessment Team leader: Assessment Team leader: Richard KnudsonRichard Knudson
P K Sinha
Anu Khendry
Kishore Rao
Subrata Guha
Sumeeta Hari
Pravin Chipde
Vivek Muzumdar (SBU2)
Deepak Thussu (SBU5)
Sudhakar M (SBU1)
Narayanan V (SBU6)
107
Assessment ProjectsAssessment Projects
• SI-PL - Maintenance - SBU1
• CT - Maintenance - SBU5
• EDS GM - Maintenance - SBU6
• CSSP - Development - SBU3
• VPS Phase 1 - Development - SBU3
• S&S UOPS - Year2000 - SBU6
108
FAR GroupsFAR Groups
• Project Leaders (6)
• Middle Managers (14)
• Developers / Testers (10 + 11)
• Support– SEPG (3)– SQA (3)– SLC / Quality Training (2)– SCM (2)
109
Assessment DataAssessment Data
• Effort– 858 person hours
• Duration– 7 days
• Depth– Conducted at sub-practice level for all KPAs– Almost 1200 sub-practices!!
110
Assessment DetailsAssessment Details
• For each of the 316 key practices– Process evidence(s)– Implementation evidence(s)– Verbal evidence(s)– Satisfied by a consensus of ALL the ATM
members
112
What does Level 5 mean for Mahindra What does Level 5 mean for Mahindra SatyamSatyam
• Our customer expectations will be elevated
• Our process ranks among the top ten companies of the world
• Our process is quantitatively understood, managed and continuously improving
• We can predict our performance with a reasonable level of accuracy
• We identify and eliminate chronic causes of defects and time / effort overruns
113
What level 5 What level 5 does notdoes not mean mean
• We always deliver on time and within estimated effort
• We have no areas of improvement
• We can continue to claim to be a Level 5 company - we need to maintain the level by reassessment once in 18-24 months, as desired by Satyam
114
What made the differenceWhat made the difference
• Defect Prevention
• Technology Change Management
• Process Change Management
… the 3 KPA’s at level 5
115
Defect PreventionDefect Prevention
• A process in place for Causal Analysis and Defect Prevention
• Organization Level Defect Prevention Team
• Organization Level Defect Prevention Plan and activities, as part of SEPG Plan
• Project Level Defect Prevention plans and activities
116
Technology Change ManagementTechnology Change Management
• A process for Technology Transition Management (TTM)
• Organization Level TTM team
• ICC to focus on TTM activities
• Organization / SEPG Level TTM Plans
• Process Evaluation as an input for TTM
• TTM process followed for tools like CCS, BTS, Vision Compass, etc.
117
Process Change ManagementProcess Change Management
• A process for QMS improvements
• Feedback mechanisms for collecting inputs for process improvements (e.g. ICSM)
• Measuring effectiveness of process change via metrics (e.g. Inspections)
• Process followed for defining and piloting the PACE model
• Process Expertise Database
118
What does Level 5 means to Mahindra What does Level 5 means to Mahindra SatyamSatyam
• They know the performance of their project and Satyam quantitatively
• They set improvement goals for the performance and work towards them
• They take decisions based on data e.g.– Tracking progress of projects– Re-planning– Completion of a review contd ...
119
What does Level 5 means to Mahindra What does Level 5 means to Mahindra SatyamitesSatyamites
• They identify causes of defects and prevent them
• They share their project experiences with others and learn from other projects
• They participate actively in process improvements