Brief Presentation on Software Process Improvement using the CMM Framework and How Some Development Corporations See Th

1. Brief Presentation on Software Process Improvement using the CMM Framework and How Some Development Corporations See Themselves… (in Jacksonville) Robert F. Roggio Pratibha Kashyap 31

2. Background / Previous Work This is a presentation emanating from a follow on paper to research conducted and reported on at the Pacific Northwest Software Quality Conference, October, 2000. The paper and this presentation were extracted from Pratibha’s project for her M.S. Survey and resulting statistics came from a survey in a large metropolitan city in the South – two large, two medium, and two small software developers – based on numbers of developers Built questionnaire based primarily on the CMM and its Key Process Areas (KPAs) and Key Practices (key terms in the CMM) Reported results Please note: There are newer and different versions of the CMM. These slides reflect the ‘first’ CMM Framework. Nevertheless, the thrust of the CMM slides presented herein still apply. 31

3. Overview • 1. Introduction to the CMM • Maturity Levels, Key Process Areas, and other terms in the CMM architecture. • 2. Self-Organizational Assessment • 3. Survey Instruments and Process • 4. Factors affecting Software Process Improvement (SPI) 31

4. Capability Maturity Model (CMM) • CMM – a framework/model for undertaking continuous process improvement of an organization’s software process. • Organizations are assessed as to the ‘maturity’ their software process exhibits. • Maturity levels consist of sets of process goals such that when satisfied, stabilize an important component of their software process. • Higher the level implies an increased process capability. • The framework prioritizes improvement actions for increasing software process maturity. • This all implies that an organization’s process must be ‘assessed.’ 31

5. Lot of key words here… Materials taken directly (or almost directly) from The Capability Maturity Model – Guidelines for Improving the Software Process, by several authors most of whom are affiliated with the SEI. 31

6. What do the level names mean? • Level 1: Initial Level: • Software processes ad hoc; sometimes chaotic. Laissez-faire. • Successes dependent upon individual(s) and heroics. • Few processes, if any, are defined. • Repeatable? only if same people assigned • Capability is a characteristic of the individuals and not the organization 31

7. Maturity Levels - CMM • Level 2: Repeatable Level: • Basic projectmanagement processes: • established to track cost, schedule, and functionality. • A necessary process discipline in place. • repeat earlier successes on projects w/similar applications. • Software process capability (Level 2 organizations) Summarized as disciplined • Planning and tracking of project is stable • Earlier successes can be repeated. • Project’s process - under the effective control of a project management system w/realistic plans based on the performance of previous projects. •  Emphasis: Project Management 31

8. Maturity Levels (continued) • Level 3 – Defined Level: • The softwareprocess for both management and engineering activities is documented, standardized, andintegrated into a standard software process for the organization. • All projects use an approved, tailoredversion of the organization’s standard software process for developing and maintaining software. • An organization-wide training program is implemented to ensure that the staff and managers have the knowledge and skills required to fulfill their assigned roles. 31

9. Level 3 – Defined (continued) • Level 3 – Defined (continued) • Projects tailor the organization’s standard software process to develop their own defined software process, for unique characteristics of a project. • This tailored process is referred to in the CMM as the project’s defined software process. • This defined software process contains a coherent, integrated set of well-defined software engineering and management processes. • A well-defined process will include: • readiness criteria, • inputs, • standards and • procedures for performing the work, • verification mechanisms (such as peer reviews), • outputs, and • completion criteria. 31

10. Level 3 – Defined (continued) • Level 3 – Defined (continued) • Because process is welldefined, management has good insight into technical progress on the project. • Characteristics: • The software process is standard and consistent with both software engineering and management activities • Stable and repeatable. • The process capability is based on a common, organization-wide understanding of the activities, roles, and responsibilities in a defined software process. 31

11. Maturity Levels (continued) • Level 4 – Managed: • Organization’s set quantitative quality goals for both software products and processes. • All projects part of an organizational measurement program. • The capability is quantifiable and predictable because the process is measured and operates within quantitative limits. • Because process - both stable and measured - exceptional circumstances can address ‘special causes’ of the variation. • When predefined limits are exceeded, actions are taken to understand and correct the situation. • Software products are of predictably high quality. 31

12. Maturity Levels (continued) • Level 5 – Optimized • Focus: continuous process improvement • At the Optimizing Level, the entire organization is focused on continuous process improvement. • The organization has the means to identify weaknesses and strengthen the process proactively, with the goal of preventing the occurrence of defects. • Innovations that exploit the best software engineering practices are identified and transferred throughout the organization. • These organizations continuously strive to improve the range of their process capability, thereby improving the process performance of their projects. 31

13. Structure of the Model • The CMM is a framework representing a path of improvements recommended for software organizations that want to increase their software process capability. • The model describes essential (key) attributes that would be expected to characterize an organization at a particular maturity level. • A maturity level is a well-defined evolutionary plateau toward achieving a mature software process. • The five maturity levels provide the top-level structure of the CMM. • Each level indicates a level of process capability. 31

14. Structure of the Model Top level… Lots of key terms!! 31

15. Key Process Areas • ‘Maturity levels’ contain several KPAs • Each KPA has a set of goals that must be satisfied to satisfy that KPA. • KPAs address a cluster of related activities (Key Practices - ahead) that, collectively when addressed, achieve a set of goals. • Key Practices are the ‘whats’ (not hows) that must be satisfied to meet the goals of a specific maturity level. 31

16. Optimizing Key Process Areas (KPAs) by Maturity Level Defect Prevention Technology Change Management Process Change Management Managed Quantitative Process Management Software Quality Management Levels and their respective KPAs are shown. Defined Organization process focus Organization process definition Training Program Integrated Software Management Software Product Engineering Intergroup coordination Peer Reviews Notice Level 3 More to do with Process Management (also organizational thrust) Notice Level 2 More to do with Project Management When the Key Practices for each KPA are satisfied, the goals for that KPAs are met. For a given maturity level, all KPAs must be satisfied. Repeatable Requirements Management Software Project Planning Software project tracking and oversight Software subcontract management Software Quality Assurance Software Configuration Management 31 Initial

17. Key Practices for a KPA • Each KPA - described in terms of Key Practices. • Satisfying the Key Practices = essential to meeting the goals of that KPA. • Equivalently, key practices describe the activities and infrastructure that contribute most to the effective implementation and institutionalism of the KPA. • Important to note: Key Practices evolve as organization achieves higher level of maturity. • They do NOT go away. • A level-3 shop satisfies all KPAs of a level-2 shop 31

18. Key Practice – Evolution Example • Many of the project estimating capabilities described in the Software Project Planning KPA at Level 2 must evolve to handle additional project data available at Level 3, described in Integrated Software Management, a level 3 KPA • Key Practices describe WHAT is to do – not how. Again, satisfaction of KP necessary to meet goal of KPA. • Each Key Practice consists of a single sentence often followed by a more detailed description, which may include examples and elaboration. 31

19. 2. Organizational Self-Assessment • Now a bit of Student Research • 65 companies; 55 responses – with pressure! • Ms. Pratibha Kashyap surveyed a number of business in Jax • Size: (Six: two of each ‘size’, where size based on number of developers) • Self-perceptions as to how theymet the maturity levels (hence KPAs and then Key Practices…) • Analysis of their perceptions 31

20. Organization's Position at CMM Level-2 5.0 4.0 3.0 Range (1-Never Thru 5-Always) 2.0 1.0 0.0 1 2 3 4 5 6 Organizations Requirements management Project Planning Project Tracking Software Quality Assurance Configuration Management Key Process Areas for Level 2 31

21. Organization's Position at CMM Level-3 5.0 4.0 3.0 Range (1-Never thru 5-Always) 2.0 1.0 0.0 1 2 3 4 5 6 Organizations Key Process Areas for Level 3 Organization Process Focus Software Process Definition Training program Integrated Software Management Software Product Engineering Inter-group Coordination 31 Peer Reviews Defects are Tracked

22. KPAs: Organization's Position at CMM Level-4 Quantitative 4.0 Process Management 3.0 Measurable 2.0 Range (1-Never thru 5-Always) Quality Goals 1.0 are defined 0.0 Progress 1 2 3 4 5 6 towards these Goals are Organizations tracked 31

23. Organizations' Position at CMM Level-5 4.0 3.5 3.0 Range (1-Never thru 5-Always) 2.5 2.0 1.5 1.0 0.5 0.0 1 2 3 4 5 6 Organizations Defect Prevention activities are planned Common Causes of Defects are Identified Technology Change Management Appropriate New Technologies are transferred in to normal practice Process Change Management to improve continually KPAs: Key Process Areas for Level 5 31

24. 3. Survey Instruments and Process • Instruments divided into components administered to • Project Leaders and to • Developers. • Sometimes both. • Designed to ascertain their perceptions of how well these companies perceived themselves satisfying the KPAs of the individual levels via the Key Practices. 31

25. 31

26. * Are software processes, procedures, and standards defined (what and how), documented, validated for correctness, practiced (used), improved (new technology) etc. Figure 3. Section 2 of Survey (Developers and Management) 31

27. 31

28. 31

29. Graph 7 - Factors Affecting Business Goals 35 30 25 20 Number of Responses 15 10 5 0 Budget Overrun Rework due to Scope changed Missed Schedule Customer satisfaction Poor Productivity due to Poor Quality products due to Affected Areas Poor Estimates Poor Planning Poor requirements Poor Skills Poor Design Poor Coding Poor QA Poor Inspections Poor Reviews 31

30. 4. Factors Affecting • Software Process Improvement (SPI) • Management’s commitment and support • Dedicated group • Projects driven by schedule • Personal involvement in overseeing • Middle management’s involvement • Organizational structure and politics 31

31. Thank You! 31