1 / 54

ASQ Las Vegas July 19 th Meeting

ASQ Las Vegas July 19 th Meeting. Capability Maturity Model (CMM) Capability Maturity Model Integration (CMMi) Dileep Dandge IGT. Common Process Problems Settling for Less

wilkinson
Télécharger la présentation

ASQ Las Vegas July 19 th Meeting

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. ASQ Las VegasJuly 19th Meeting • Capability Maturity Model (CMM) • Capability Maturity Model Integration (CMMi) Dileep Dandge IGT

  2. Common Process Problems Settling for Less Do these statements sound familiar? If they do, your organization may be settling for less than it is capable of and may be a good candidate for process improvement. “I'd rather have it wrong than have it late. We can always fix it later.” “The bottom line is schedule. My promotions and raises are based on meeting schedule first and foremost.”

  3. Common Process Problems (Cont.) Symptoms of Process Failure Commitments consistently missed • Late delivery • Last minute crunches • Spiraling costs No management visibility into progress • You’re always being surprised. Quality problems • Too much rework • Functions do not work correctly. • Customer complaints after delivery Poor morale • People frustrated • Is anyone in charge?

  4. Common Process Problems (Cont.) Software-Intensive Systems Software is becoming a larger part of many products and services. Systems and software disciplines traditionally have not been well integrated. The importance of software in systems has increased dramatically

  5. Process Improvement Basics The Process Management Premise The quality of a system is highly influenced by the quality of the process used to acquire, develop, and maintain it. This premise implies a focus on processes as well as on products. • This is a long-established premise in manufacturing (and is based on TQM principles as taught by Shewhart, Juran, Deming, and Humphrey). • Belief in this premise is visible worldwide in quality movements in manufacturing and service industries (e.g., ISO standards).

  6. Process Improvement Basics (Cont.) The Role of Process Everyone realizes the importance of having a motivated, quality work force and the latest technology, but even the finest people can’t perform at their best when the process is not understood or operating at its best. PEOPLE PROCESS TECHNOLOGY

  7. Process Improvement Basics (Cont.) Common Misconceptions I don’t need process, I have • really good people • advanced technology • an experienced manager Process • interferes with creativity • equals bureaucracy + regimentation • isn’t needed when building prototypes • is only useful on large projects • hinders agility in fast-moving markets • costs too much

  8. Capability Maturity Model® Integration (CMMI®)Capability Maturity Modeling, CMM, and CMMI are registered in the U.S. Patent andTrademark Office by Carnegie Mellon University.

  9. Software Development Models • Waterfall or V • Progressive or Phased • Iterative • XP - Extreme Programming

  10. Sequential Phasesin WaterfallorSteps that need to happen • Requirements Analysis • Architectural Design • Detailed Design • Coding and Unit Testing • Software Integration • System Integration • Product Testing/Quality Assurance • Customer Acceptance Testing

  11. What Is a CMM? A Capability Maturity Model (CMM) is a reference model of mature practices in a specified discipline, used to improve and appraise a group’s capability to perform that discipline. CMMs differ by • discipline (e.g., software engineering, systems engineering) • structure (e.g., staged, continuous) • definition of maturity (i.e., process improvement path)

  12. Multiple Process Models • Software CMM • Systems Security Engr CMM • Systems Engr CMM • People CMM • IPD CMM • Software Acq CMM • EEIIAA 773311 • ISO 15504

  13. Success of the Software CMM® caused development of other CMMs, but they: • had different structures, formats, terms, ways of measuring maturity • caused confusion, especially when more than one was used together • were difficult to integrate into a combined improvement program • were difficult to use in supplier selection and sub-contracting

  14. Understanding CMMI Representations There are two types of representations in the CMMI models: • staged • continuous A representation allows an organization to pursue different improvement paths. The organization and presentation of the data are different in each representation. However, the content is the same.

  15. Capability Levels A capability level is a well-defined evolutionary plateau describing the organization’s capability relative to a particular process area. There are six capability levels. Each level is a layer in the foundation for continuous process improvement. Thus, capability levels are cumulative (i.e., a higher capability level includes the attributes of the lower levels).

  16. The CMM Maturity Levels High 5 Process Performance Process Capability 4 Process Maturity 3 Low 2 1

  17. The Five Levels of Software Process Maturity Continuously Improving Process 5.Optimizing Focus on process improvement 4. Managed Predictable Process Managing Change Process measured and controlled Standard, Consistent Process 3. Defined Product and Process Quality Process characterized, fairly well understood 2. Repeatable Disciplined Process Integrated Engineering Process Can repeat previously mastered tasks 1. Initial Project Management Unpredictable and poorly controlled

  18. Level 1 -- Initial Activities Performed by the Organization Activities Performed by the Projects Resulting Process Capability Organization lacks sound management practices Good software engineering practices are undermined by ineffective planning and reaction-driven commitment systems During a crisis, projects abandon planned procedures Even a strong software engineering process cannot overcome the instability created by the absence of sound management practices Software Process Capability is unpredictable because the process is constantly changed or modified as the work progresses (i.e., the process is ad hoc) Few stable processes in evidence

  19. Level 2 -- Repeatable Activities Performed by the Organization Activities Performed by the Projects Resulting Process Capability Establishes software project management policies and procedures Institutionalizes effective project management processes which allow new projects to repeat successful practices developed on earlier projects, although the specific project’s processes may differ Software Process Capability is disciplined because project planning and tracking is stable and earlier successes can be repeated Project process is under the effective control of a project management system, following realistic plans Make realistic project commitments based on previous project results and current project requirements Track software costs, schedules, and functionality to identify problems meeting commitments Control requirements and work products and assure project standards are followed

  20. Level 3 -- Defined Activities Performed by the Organization Activities Performed by the Projects Resulting Process Capability Software Process Capability is standard and consistent because both software engineering and management activities are stable and repeatable Cost, schedule and functionality are under control, and software quality is tracked Documents the organization’s standard process for developing and maintaining software Integrates project management and software engineering processes; exploits effective software engineering practices Provides process support (SEPG) and training program to ensure skills development Projects tailor the organization’s standard software process to develop their own defined software process for the project Because the software process is well defined, management has good insight into technical progress on all projects

  21. Level 4 -- Managed Activities Performed by the Organization Activities Performed by the Projects Resulting Process Capability Software Process Capability is predictable because the process is measured and operates within measurable limits Allows for predictive trends in process and quality within quantitative bounds and allows for corrective action when limits are exceeded Sets quantitative quality goals for both software products and processes Measures productivity and quality for important software process activities across all projects as part of an organizational measurement program Provides a foundation for quantitative evaluation Projects achieve control over their products and processes by narrowing the variation in their process performance to fall within acceptable quantitative boundaries The risks involved in moving up the learning curve of a new application domain are known and carefully managed

  22. Level 5 -- Optimizing Activities Performed by the Organization Activities Performed by the Projects Resulting Process Capability Entire organization is focused on continuous process improvement with the goal of defect prevention Data is used for cost-benefit analysis of new technology and new process changes Innovations in software engineering practices are transferred to the entire organization Project teams analyze defects and determine their causes Project teams evaluate processes to prevent known types of defects from recurring Software Process Capability is continuously improving because the organization continuously improves the range of capability and process performance of projects Improvement occurs both by incremental advancement of existing process and by innovations using new technologies and methods

  23. A Foundation, Not a Destination The optimizing level (Level 5) is not the destination of process management. The destination is better products for a better price: economic survival The optimizing level is a foundation for building an ever-improving capability.

  24. CMM Level 2 Key Process Areas Software Quality Assurance Requirements Management SoftwareProjectPlanning Software Configuration Management SoftwareProject Tracking and Oversight Software Subcontract Management

  25. Level 2 Key Process Area:Requirements Management Purpose Goals 1. System requirements allocated to software are controlled to establish a baseline for software engineering and management use 2. Software plans, products, and activities are kept consistent with the system requirements allocated to software To establish a common understanding between the customer and the software project of the customer’s requirements that will be addressed by the software project Scope Involves establishing and maintaining an agreement with the customer on the requirements for the software project Agreement is the basis for estimating, planning, performing, and tracking the project’s software activities

  26. Example Assessment Findings:Requirements Management • FINDING • Requirements are not sufficiently managed to ensure • Adequate definition • Thorough analysis • Effective change control • Usable input for subsequent development steps • CONSEQUENCES • Low level of confidence that customer needs are met • Design team understanding of requirements is at risk • Definition of product content is hard to determine • Design and code quality cannot be assured

  27. Brainstorm Exercise for:Requirements Management What do we do currently that meets the goals for REQUIREMENTS MANAGEMENT? What issues remain for us to meet the goals and to institutionalize the activities for this KPA?

  28. Level 2 Key Process Area:Software Project Planning Purpose Goals 1. Software estimates are documented for use in planning and tracking the software project. 2. Software project activities and commitments are planned and documented. 3. Affected groups and individuals agree to their commitments related to the software project. To establish reasonable plans for performing the software engineering and for managing the software project Scope Involves: o developing estimates for the work to be performed o establishing the necessary commitments o defining the plan to perform the work Plan provides the basis for initiating the software effort and managing the work

  29. Example Assessment Findings:Estimation, Planning, and Commitment Control • FINDINGS • Little evidence of formal procedures for estimating project size, cost, and schedule • Project plans are not comprehensive • Inadequate management review before commitment • First-line managers do not have formal approval of schedules • Frequently, commitments are not renegotiated when changes occur • CONSEQUENCES • Important process tasks are missing from project plans • Schedules are unreliable • Testing suffers when development schedules slip • Resources are over-committed

  30. Brainstorm Exercise for:Software Project Planning What do we do currently that meets the goals for PROJECT PLANNING? What issues remain for us to meet the goals and to institutionalize the activities for this KPA?

  31. Level 2 Key Process Area:Software Project Tracking and Oversight Purpose Goals 1. Actual results and performances are tracked against the software plans. 2. Corrective actions are taken and managed to closure when actual results deviate significantly from the software plans. 3. Changes to software commitments are agreed to by the affected groups and individuals. To provide adequate visibility into actual progress so that management can take effective actions when performance deviates significantly from the plan Scope Involves: o tracking and reviewing software accomplishments and results against documented estimates, commitments, and plans o adjusting plans based on actual accomplishments and results

  32. Example Assessment Findings:Tracking and Oversight • FINDING • Project activities are not adequately tracked • Product and project interdependencies are insufficiently monitored • Inconsistent use of project review procedures • Many project plans are not regularly reviewed and updated • CONSEQUENCES • Project plans are frequently out-of-date • Schedules are often at risk • Product content and quality cannot be predicted

  33. Brainstorm Exercise for:Software Project Tracking and Oversight What do we do currently that meets the goals for PROJECT TRACKING AND OVERSIGHT? What issues remain for us to meet the goals and to institutionalize the activities for this KPA?

  34. Level 2 Key Process Area:Software Quality Assurance Purpose Goals 1. Software quality assurance activities are planned. 2. Adherence of software products and activities to the applicable standards, procedures, and requirements is verified objectively. 3. Affected groups and individuals are informed of software quality assurance activities and results. 4. Noncompliance issues that cannot be resolved within the software project are addressed by senior management. To provide management with appropriate visibility into the process being used and the products being built Scope Involves: o reviewing and auditing the software products and activities to ensure that they comply with the applicable procedures and standards o providing the software project and other appropriate managers with the results of those reviews and audits

  35. Example Assessment Findings:Software Quality Assurance • FINDING • There is minimal product and process assurance • Process effectiveness is seldom evaluated • Process metrics are often nonexistent or used ineffectively • CONSEQUENCES • Data is suspect • Confidence in process compliance is limited • Process improvement cannot be quantified • Product quality is uncertain • Management is unable to make informed decisions

  36. Level 2 Key Process Area:Software Configuration Management Purpose Goals 1. Software configuration management activities are planned. 2. Selected software work products are identified, controlled, and available. 3. Changes to identified software work products are controlled. 4. Affected groups and individuals are informed of the status and content of software baselines. To establish and maintain the integrity of the products of the software project throughout the software life cycle Scope Involves: o identifying configuration items/units o systematically controlling changeso maintaining integrity and traceability of the configuration throughout the software life cycle

  37. Level 2 Key Process Area:Software Subcontract Management Purpose Goals 1. The prime contractor selects qualified software subcontractors. 2. The prime contractor and the software subcontractor agree to their commitments to each other. 3. The prime contractor and the software subcontractor maintain ongoing communications. 4. The prime contractor tracks the software subcontractor’s actual results and performances against its commitments. To select qualified software subcontractors and manage them effectively Scope Involves: o selecting a software subcontractor o establishing commitments with the subcontractoro tracking and reviewing the subcontractor’s performance and results

  38. Brainstorm Exercise for:Software Quality Assurance What do we do currently that meets the goals for SOFTWARE QUALITY ASSURANCE? What issues remain for us to meet the goals and to institutionalize the activities for this KPA?

  39. Brainstorm Exercise for:Software Configuration Management What do we do currently that meets the goals for CONFIGURATION MANAGEMENT? What issues remain for us to meet the goals and to institutionalize the activities for this KPA?

  40. Brainstorm Exercise for:Software Subcontract Management What do we do currently that meets the goals for SUBCONTRACT MANAGEMENT? What issues remain for us to meet the goals and to institutionalize the activities for this KPA?

  41. CMM Level 3 Key Process Areas Organization Process Focus Organization Process Definition Training Program Inter-group Coordination PeerReviews Integrated Software Management Software Product Engineering

  42. Level 3 Key Process Area:Organization Process Focus Purpose Goals 1. Software process development and improvement activities are coordinated across the organization. 2. The strengths and weaknesses of the software processes used are identified relative to a process standard. 3. Organization-level process development and improvement activities are planned. To establish the organizational responsibility for software process activities that improve the organization’s overall software process capability Scope Involves: o developing and maintaining an understanding of organization and project software processes o coordinating the activities to assess, develop, maintain, and improve these processes

  43. Level 3 Key Process Area:Organization Process Definition Purpose Goals 1. A standard software process for the organization is developed and maintained. 2. Information related to the use of the organization’s standard software process by the software projects is collected, reviewed, and made available. To develop and maintain a usable set of software process assets that improve process performance and provide a basis for cumulative, long-term benefits Scope Involves developing and maintaining the organization’s standard software process and related process assets The organization’s standard software process describes the fundamental elements that each project incorporates and tailors to fit the project

  44. Level 3 Key Process Area:Integrated Software Management Purpose Goals 1. The project’s defined software process is a tailored version of the organization’s standard software process. 2. The project is planned and managed according to the project’s defined software process. To integrate the project’s software engineering and management activities into a coherent, defined software process tailored from the organization’s software process assets Scope Involves: o developing the project’s defined software process by tailoring the organization’s standard software process o managing the software project according to this defined software process

  45. Level 3 Key Process Area:Software Product Engineering Purpose Goals 1. The software engineering tasks are defined, integrated, and consistently performed to produce the software. 2. Software work products are kept consistent with one another. To consistently perform a well-defined engineering process that integrates all the software engineering activities to produce correct, consistent software products effectively and efficiently Scope Involves performing the engineering tasks to build and maintain the software using appropriate tools and methods Includes requirements analysis, design, coding, integration, and testing

  46. Level 3 Key Process Area:Inter-group Coordination Purpose Goals 1. The customer’s requirements are agreed to by all affected groups. 2. The commitments between the engineering groups are agreed to by the affected groups. 3. The engineering groups identify, track, and resolve inter-group issues. To establish a means for the software engineering group to participate actively with the other engineering groups so the project is better able to satisfy the customer’s needs effectively and efficiently Scope Involves the disciplined interaction and coordination of the project engineering groups with each other to address system-level requirements, objectives, and plans

  47. Level 3 Key Process Area:Training Program Purpose Goals 1. Training activities are planned. 2. Training for developing the skills and knowledge needed to perform software management and technical roles is provided. 3. Individuals in the software engineering group and software-related groups receive the training necessary to perform their roles. To develop the skills and knowledge of individuals so they can perform their roles effectively and efficiently Scope Involves: o identifying the training needs of the organization, the projects, and individuals o developing and/or procuring training to address these needs

More Related