Software Process Improvement: SEI Capability Maturity Model COP 4331 and EEL 4884 Processes for OO Software Development © Dr. David A. Workman School of EECS University of Central Florida April 20, 2010
Introduction • Reference: The Capability Maturity Model: Guidelines for Improving the Software Process, by Carnegie Mellon University, SEI, Addison-Wesley, 1994, ISBN=0 -201 -54664 -7 • • Reference: The Capability Maturity Model for Software, by Paulk et al, Text[pp 48 -59] History – Originally the vision of Watts Humphrey and produced by a team of SEI researchers including: Mark Paulk Bill Curtis Mary Beth Chrissis Ed Averill Judy Bamberger Tim Kasse Mike Konrad Jeff Perdue Charlie Weber Cindi Wise Jim Withey – Version 1. 0 was released in August 1991 April 20, 2010
Motivation • • • “Software Crisis” “No Silver Bullet” (technology is only part of the solution) Demand for more and more complex software systems have outstripped our ability to cope with changes required to meet these demands. Organizations began to realize the fundamental problem is the inability to manage the software process! Examples – A review of 17 major DOD contracts found that the average 28 -month schedule was missed by 20 months! – Deployment of the B 1 bomber was delayed by software problems and the $58 billion A 12 aircraft program was canceled partly for the same reason. – GAO concluded a study of more than 20 large software projects with this statement, “The understanding of software as a product and of software development as a process is not keeping pace with the growing complexity and software dependence of existing and emerging missioncritical systems. ” April 20, 2010
Evolution • Humphrey’s Book, “Managing the Software Process” Addison-Wesley, 1989. “Characterizing the Software Process: A Maturity Framework, ” IEEE Software, March 1988. – Method: Software Process Assessment An appraisal by a team of trained software professionals to determine the state of an organization’s current software process, to determine the most important process-related issues, and to obtain organizational support for improvement. – Method: Software Capability Evaluation An appraisal by a team of trained software professionals to identify contractors qualified to perform the software work or to monitor the state of the software process used on an existing software effort. – Maturity Questionaire • SEI Development and Release 1991 -92 • SEI Influenced the ISO 9000 Standard series, specifically 9001. April 20, 2010
Fundamental Concepts The CMM focuses on the capability of software organizations to produce high-quality products consistently and predictably. Software process capability is the inherent ability of a software process to produce planned results. • DEFINITION (Process) A sequence of steps performed for a given purpose. The process integrates people, tools, and procedures. • DEFINTION (Software Process) A set of activities, methods, practices, and transformations that people employ to develop and maintain software and the associated products (documents, etc. ) • DEFINTION (Software Process Capability)decribes the range of expected results that can be achieved by following a software process. April 20, 2010
Fundamental Concepts The CMM focuses on the capability of software organizations to produce high -quality products consistently and predictably. Software process capability is the inherent ability of a software process to produce planned results. • DEFINITION (Software Process Performance) the actual results achieved by following a software process. • DEFINTION (Software Process Maturity) the extent to which a specific process is explicitly defined, managed, measured, controlled, and effective. • As a software organization matures, it needs an infrastructure and culture to support its methods, practices, and procedures so that they endure after those who originally defined them have gone. DEFINTION (Institutionalization) is the building of infrastructure and culture to support methods, practices, and procedures so that they are the ongoing way of doing business. April 20, 2010
Software Process Maturity Framework Five Maturity Levels: • Initial: The software process is characterized by ad hoc, and occasionally even chaotic. Few processes are defined, and success depends on individual effort and heroics. • Repeatable: Basic project management processes are established to track cost, schedule, and functionality. The necessary process discipline is in place to repeat earlier successes on projects with similar applications. • Defined: The software process for both management and engineering activities is documented, standardized, and integrated into a standard software process for the organization. All projects use an approved, tailored version of the organization’s standard software process for developing and maintaining software. April 20, 2010
Software Process Maturity Framework Five Maturity Levels (continued): • Managed: Detailed measures of the software process and product quality are collected. Both the software process and products are quantitatively understood and controlled. • Optimizing: Continuous process improvement is enabled by quantitative feedback from the process and from piloting innovative ideas and technologies. April 20, 2010
The CMM Level Structure Indicate Process Capability Maturity Levels Contains Achieves Key Process Areas Organized by Common Features Goals Address Implementation/ Institutionalization Contain Key Practices Describe Activities or Infrastructure April 20, 2010
Key Process Areas • Definition Except for level 1, each maturity level is decomposed into several key process areas that indicate where an organization should focus to improve its software process. KPAs identify the issues that must be addressed to achieve a desired maturity level. If an organization is at level K+1 then it has addressed all of the KPAs at levels K. Each KPA identifies a cluster of activities that, when performed collectively, achieve a set of goals considered important for enhancing process capability. The KPAs may be considered to be the requirements for achieving a particular maturity level. See Notes! April 20, 2010
KPAs – Level 2 • Focus: project concerns related to establishing basic project management controls. 1. Requirements Management (establish customer & user repoire, involve customer & users in the process) 2. Software Project Planning: (establish project management and engineering procedures) 3. Software Project Tracking and Oversight (make visible to the organization) 4. Software Subcontract Management (qualified subcontractors)(avoid disconnect in management and engineering maturity and capability) 5. Software Quality Assurance (make SQA visible to management) 6. Software Configuration Management (control access and change to engineering work products and project deliverables) April 20, 2010
KPAs – Level 3 • Focus: project and organizational issues leading toward the infrastructure that institutionalizes effective software engineering across all projects. 1. Organization Process focus: coordinate and integrate process across all projects. 2. Organization Process definition: develop a reusable set of process assets (documents, training materials) defining the organization’s standard software process (includes a tool set) 3. Training program: train personnel in the various process procedures and roles 4. Integrated Software Management: 5. Software Product engineering: 6. Inter-group coordination: 7. Peer Reviews: April 20, 2010
KPAs – Level 4 • Focus: establishing a quantitative understanding of both the software process and the software products being built (process and product metrics and measures). 1. Quantitative Process Management: develop the quantitative measures necessary to control process performance of software projects. 2. Software Quality Management: develop quantitative measures necessary to control the quality of software products. – Software Quality Metrics – Metrics Validation Process (IEEE Standard 1061) April 20, 2010
KPAs – Level 5 • Focus: addressing issues concerning organization and projects relating to continuous and measurable software process improvement. 1. Defect Prevention: detect causes of defects and prevent them from recurring. 2. Technology Change Management: identify beneficial new technologies (tools, methods, and processes) and transfer them into the organization in an orderly manner. 3. Process Change Management: continually improve software processes in the organization with the intent of improving software quality, increasing productivity, and decreasing the cycle time for product development. April 20, 2010
Common Features • Definition Attributes that indicate whether the implementation and institutionalization of a KPA is effective, repeatable, and lasting. There are 5: 1. Commitment to perform: actions the organization must take to ensure that the process is established and will endure; establish organizational policies and leadership. 2. Ability to perform: defines the preconditions that must exist in the project or organization to implement the software process competently; resources, organizational entities, and training. 3. Activities to perform: activities, roles, and procedures necessary to implement KPAs; create plans and procedures, tracking progress, taking corrective action when not done. 4. Measurement and analysis: determine process status. 5. Verifying implementation: steps to ensure compliance with process. April 20, 2010
Level 2: Requirements Engineering Practices Goals: – – Requirements Management establishes common understanding (agreement) between customer and vendor of the customer's requirements addressed by the project. It involves allocating system requirements to software modules or components. The "agreement" covers technical and non-technical requirements (e. g. delivery dates) and forms the basis for estimating, planning, performing and tracking project activities. To achieve control, the team reviews initial and revised system requirements allocated to software to resolve issues before they are incorporated in development. Whenever requirements change, the affected plans, work products, and activities are adjusted to remain consistent with the updated requirements. 1. System requirements allocated to software 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. April 20, 2010
CMM Key Practices by Level Dr. David Workman School of EE and CS January 17, 2006
Level 2: Requirements Engineering Practices Requirments Engineering Practices: 1. The team reviews allocated requirements before they are incorporated into development. 2. The team uses allocated requirements as the basis for software plans, work products, and activities. 3. Changes to allocated requirements are reviewed and incorporated into the software project. April 20, 2010
Level 2: Software Planning Practices Goals: 1. Software estimates (size, resources, schedule, risks, commitments) are documented for use in planning and tracking development. 2. Project activities and commitments are planned and documented. 3. Affected stakeholders agree to their commitments related to the project. April 20, 2010
Level 2: Software Planning Practices Software Project Planning Practices: 1. The development team participates on the project proposal. 2. The software project planning is initiated in the early stages of, and in parallel with, the overall project planning. 3. The software team participates with the other stakeholder planning groups throughout the project's life. 4. Project commitments made to individuals and groups external to the organization are reviewed with senior management according to a documented procedure. 5. Software development stages of manageable size are identified or defined. 6. The software development plan is developed according to a documented procedure. 7. The software development plan is documented. April 20, 2010
Level 2: Software Planning Practices Software Project Planning Practices: 8. The software work products that are needed to establish and maintain control of the project are identified. 9. Estimates for the size of software work products (or changes to their sizes) are derived according to a documented procedure. 10. Estimates for the project's critical computing resources are derived according to a documented procedure. 11. The project's schedule is derived according to a documented procedure. 12. The software risks associated with cost, resources, schedule, and technical aspects of the project are identified, assessed, and documented. 13. Plans for the project's software engineering facilities and support tools are prepared. 14. Software planning data are recorded. April 20, 2010
Level 2: Project Tracking & Control Practices Goals: 1. Actual results and performance are tracked against the software development plan; accomplishments and results (size, effort, schedule, cost) are compared with documented estimates. 2. Corrective actions are taken and managed to closure when actual results and performance deviate significantly from the software plans. 3. Changes to software commitments are agreed to by the affected stakeholders. April 20, 2010
Level 2: Project Tracking & Control Practices: 1. A documented software plan is used for tracking the software activities and communicating status. 2. The project's development plan is revised according to a documented procedure. 3. Software project commitments and their changes made by external stakeholders are reviewed by senior management according to a documented procedure. 4. Approved changes to commitments that affect the software project are communicated to the members of the development group and other software-related groups (e. g. tools, training, contracts, 3 rd party vendors) 5. The size of software work products (or the size of changes to) are tracked, and corrective actions are taken as necessary. 6. The project's software effort and costs are tracked, and corrective actions are taken as necessary. 7. The project's critical resources (e. g. funds spent) are tracked, and corrective actions are taken as necessary. April 20, 2010
Level 2: Project Tracking & Control Practices: 8. The project's software schedule is tracked, and corrective actions are taken as necessary. 9. Software engineering technical activities are tracked, and corrective actions are taken as necessary. 10. The software risks associated with cost, resources, schedule, and technical aspects of the project are tracked. 11. Actual measurement data and replanning data for the software project are recorded. 12. The software development team conducts periodic internal reviews to track technical progress, plans, performance, and issues against the software development plan. 13. Formal reviews to address the accomplishments and results of the software project are conducted at selected project milestones according to a documented procedure. April 20, 2010
Level 2: Subcontract Management Practices Goals: 1. 2. 3. 4. The prime contractor selects qualified software subcontractors. The prime contractor and the software subcontractor agree to their commitments to each other. The prime contractor and the software subcontractor maintain on-going communciation with each other. The prime contractor tracks the software subcontractor's actual results and performance against its commitments. The purpose of SSM is to select qualified software subcontractors and manage them effectively. SSM involves selecting a software subcontractor, establishing commitments with the subcontractor, and tracking and reviewing subcontractor’s performance and results. A documented agreement covering the technical and nontechnical requirements is established and is used as the basis for managing the subcontract. The work to be done by the subcontractor and the plans for the work are documented. The standards that are to be followed by the subcontractor are compatible with the prime’s standards. The software planning, tracking, and control activities for the subcontracted work are preformed by the subcontractor. The prime ensures that these planning, tracking and control activities are performed appropriately and that the software products delivered by the subcontractor satisfy their acceptance criteria. April 20, 2010
Level 2: Subcontract Management Practices: 1. The subcontracted work is defined and planned according to a documented procedure. 2. The software subcontractor is selected based on an evaluation of the subcontract bidder's ability to perform the work, according to a documented procedure. 3. The contractual agreement between the prime and subcontractor is used as the basis for managing the subcontract. 4. A documented subcontractor's software development plan is reviewed and approved by the prime. 5. A documented subcontractor's software development plan is used for tracking the software activities and communicating status. 6. Changes to the software subcontractor's statement of work, terms and conditions, and other commitments are resolved according to a documented procedure. 7. The prime's management conducts periodic status/coordination reviews with the subcontractor's management. April 20, 2010
Level 2: Subcontract Management Practices: 8. Periodic technical reviews and interchanges are held with the subcontractor. 9. Formal reviews to address the subcontractor's accomplishments and results are conducted at selected milestones, according to a documented procedure. 10. The prime's software quality assurance group monitors the subcontractor's software quality assurance activities, according to a documented procedure. 11. The prime's software configuration management group monitors the subcontractor's configuration management activities, according to a documented procedure. 12. The prime conducts acceptance testing as part of the delivery of the subcontractor's software products, according to a documented procedure. 13. The subcontractor's performance is evaluated on a periodic basic, and the evaluation is reviewed by the subcontractor. April 20, 2010
Level 2: Software Quality Assurance Practices Goals: 1. Software quality assurrance 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. The purpose of SQA is to provide management with appropriate visibility into the process being used by the project and the products being built. SQA involves reviewing project products and activities to verify they comply with applicable documented procedures and standards. SQA provides the software project and other designate managers the results of reviews and audits. SQA works with the project team during its early stages to establish plans, standards, and procedures that will add value to the project and satisfy the constraints of the project and the organization’s policies. April 20, 2010
Level 2: Software Quality Assurance Practices: 1. A SQA plan is prepared for the software project, according to a documented 2. 3. 4. 5. 6. 7. 8. procedure. The SQA group’s activities are performed in accordance with the SQA plan The SQA group participates in the preparation and review of the project’s software development plan, standards, and procedures. The SQA group reviews software engineering activities to verify compliance. The SQA group audits designated software work products to verify compliance. The SQA group periodically reports the results of its activities to the software team. Deviations identified in the software activities and software work products are documented and handled according to a documented procedure. The SQA group conducts periodic reviews of its activities and findings with the customer’s SQA personnel, as appropriate. April 20, 2010
Level 2: Software Configuration Management Practices Goals: 1. 2. 3. 4. Software configuration management activities are planned. Selected software work products are identified, controlled, and available. Changes to identified software work products are controlled. Affected stakeholders are informed of the status and content of the software baselines. The purpose of SCM is to establish and maintain the integrity of the products of the software project throughout the project’s life cycle. SCM involves identifying the configuration of the software (i. e. , selected software work products and their descriptions) at given points in time, systematically controlling changes to the configuration, and maintaining the integrity and traceability of the configuration throughout the software life cycle. A software baseline library is established containing the software baselines as they are developed. Changes to baselines and release of the software products built from the baseline library are systematically controlled via change control and configuration auditing functions of the SCM. Products placed under CM include customer deliverables and items that are required to create them (e. g. a compiler). April 20, 2010
Level 2: Software Configuration Management Practices: 1. An SCM plan is prepared for each software project according to documented procedure. 2. A documented and approved SCM plan is used as the basis for performing SCM activities. 3. A configuration management library system is established as a repository for the software baselines. 4. The software work products to be placed under configuration management are identified. 5. Change requests and problem reports for all configuration items/units are initiated, recorded, reviewed, approved, and tracked according to documented procedure. 6. Changes to baselines are controlled according to documented procedure. 7. Products from the software baseline library are created and their release is controlled according to documented procedure. 8. The status of configuration items/units is recorded according to documented procedure. 9. Standard reports documenting the SCM activities and the contents of the software baseline are developed and made available to affected stakeholders. 10. Software baseline audits are conducted according to documented procedure. April 20, 2010
Level 3: Key Practices (Organization Process Focus) Purpose: Organization Process Focus – – – To establish the organizational responsibility for software practice activities that improve the organization's overall software process capability. This involves developing and maintaining an understanding of the organization's and project's software processes and coordinating activities to assess, develop, maintain, and improve these processes. This is accomplished by establishing a software process group responsible for the organization's software process activities. It is responsible for developing and maintaining process standards for the organization, and it coordinates the process activities with each project. Goals: Organization Process Focus 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. April 20, 2010
Level 3: Key Practices (Organization Process Focus) Organization Process Focus Practices: 1. The software process is assessed periodically, and action plans are developed to address the assessment findings. 2. The organization develops and maintains a plan for its software process development and improvement activities. 3. The organization's and project's activities for developing and improving their software processes are coordinated at the organizational level. 4. The use of the organization's software process database is coordinated at the organizational level. 5. New processes, methods, and tools in limited use in the organization are monitored, evaluated, and, where appropriate, transferred to other parts of the organization. 6. Training for the organization's and project's software processes is coordinated across the organization. 7. The groups involved in implementing the software processes are informed of the organization's and project's activities for software development and improvement. April 20, 2010
Level 3: Key Practices (Organization Process Definition) Purpose: Organization Process Definition – To 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 organizations standard software process, along with related process assets, such as description of software lifecycles, process tailoring guidelines and criteria, the organization's process database, and a library of process-related documentation. Goals: Organization Process Definition 1. A standard software process is developed and maintained. 2. Information related to the use of the organization's standard process is collected, reviewed, and made available in a persistent form. April 20, 2010
Level 3: Key Practices (Organization Process Definition) Organization Process Definition Practices: 1. The organization's standard software process is developed and maintained according to a documented procedure. 2. The organization's standard software process is documented according to established organization standards. 3. Descriptions of approved software lifecycles available for use by projects are documented and maintained. 4. Guidelines and criteria for projects' tailoring of the organization's standard process are developed and maintained. 5. The organization's software process database is developed and maintained. 6. A library of software process-related documentation is established and maintained. April 20, 2010
Level 3: Key Practices (Training Program) Purpose: Training Program – To develop the skills and knowledge of individuals so they can perform their roles effectively and efficiently. – Involves identifying training needs. – Involves procuring the training agent and delivery system. Goals: Training Program 1. Training activities are planned. 2. Training for developing skills and knowledge needed to perform software management and technical roles are provided. 3. Individuals in the software engineering group and software-related groups receive the training necessary to perform their roles. April 20, 2010
Level 3: Key Practices (Training Program) Training Program Practices: 1. Each software project develops and maintains a training plan that specifies its training needs. 2. The organization's training plan is developed and revised according to a documented procedure. 3. The training for the organization is performed in accordance with the organization's training plan. 4. Training courses prepared at the organization level are developed and maintained according to organization standards. 5. A waiver procedure for required training is established and used to determine whether individuals already posses the knowledge and skills required to perform in their designated roles. 6. Records of training are maintained. April 20, 2010
Level 3: Key Practices (Integrated Software Management) Purpose: Integrated Software Management – To integrate the software engineering and management activities into a coherent, defined software process that is tailored from the organization’s standard software process and related process assets, which are described in the Organization Process Definition. – Involves developing the project’s process defined software process and managing the project using that defined software process; the defined project software process is tailored from the organization’s standard process to address specific project characteristics. Goals: Integrated Software Management 1. The project’s defined software process is a tailored version of the organization’s standard process. 2. The software development plan is based on the project’s defined process. 3. The management of the project’s size, effort, cost, schedule, staffing, and other resources are tied to the project’s defined process. April 20, 2010
Level 3: Key Practices (Integrated Software Management) Integrated Software Management Practices: 1. The project’s defined software process (pdsp) is developed by tailoring the organization’s standard software proces (ossp) according to a documented procedure(adp). 2. Each pdsp is revised adp. 3. The software project’s software development plan, which describes the use of the pdsp, is developed and revised adp. 4. The software project is managed in accordance with the pdsp. 5. The ossp database is used for software planning and estimating. 6. The size of the software work products (or the size of their changes) is managed adp. 7. The project’s software effort and costs are managed adp. 8. The project’s critical computer resources are managed adp. 9. The critical dependencies and critical pats of the project’s schedule are managed adp. 10. The project’s software risks are identified, assessed, documented, and managed adp. 11. Reviews of the software project are periodically performed to determine the actions needed to bring the software project’s performance and results in line with the current and projected needs of the business, customer, end users, as appropriate. April 20, 2010
Level 3: Key Practices (Software Product Engineering) Purpose: Software Product Engineering – To perform consistently 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 and appropriate methods and tools. Goals: Software Product Engineering 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. April 20, 2010
Level 3: Key Practices (Software Product Engineering) Software Product Engineering Practices: 1. Appropriate software engineering methods and tools are integrated into the pdsp. 2. The software requirements are developed, maintained, documented, and verified by systematically analyzing the allocated requirements according to the pdsp. 3. The software design is developed, maintained, documented, and verified according to the pdsp, to accommodate the software requirements and to form the framework for coding. 4. The software code is developed, maintained, documented, and verified according to the pdsp, to implement the software requirements and software design. 5. Software is testing is performed according to the pdsp. 6. Integration testing of the software is planned and performed according to the pdsp. April 20, 2010
Level 3: Key Practices (Software Product Engineering) Software Product Engineering Practices: 7. System and acceptance testing of the software planned and performed to demonstrate that the software satisfies its requirements. 8. The documentation that will be used to operate and maintain the software is developed and maintained according to the psdp. 9. Data on defects identified in peer reviews and testing are collected analyzed according to the pdsp. 10. Consistency is maintained across software work products, including the software plans, process descriptions, allocated requirements, software design, code, test plans, and test procedures. April 20, 2010
Level 3: Key Practices (Intergroup Coordination) Purpose: Intergroup Coordination – 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. – Involves the software engineering group's participation with the other engineering groups to address system-level requirements, objectives, and issues. Goals: Intergroup Coordination 1. The customer's requirements are agreed to by all affected groups. 2. The commitments between engineering groups are agreed to by the affected groups. 3. The engineering groups identify, track, and resolve intergroup issues. April 20, 2010
Level 3: Key Practices (Intergroup Coordination) Intergroup Coordination Practices: 1. The software engineering group and the other engineering groups participate with the customer and end users, as appropriate, to establish the system requirements. 2. Representatives of the project's software engineering group work with representatives of the other engineering groups to monitor and coordinate technical activities and resolve technical issues. 3. A documented plan is used to communicate intergroup commitments and to coordinate and track the work performed. 4. Critical dependencies between engineering groups are identified, negotiated, and tracked according to a documented procedure. 5. Work products produced as input to other engineering groups are reviewed by representatives of the receiving groups to ensure that the work products meet their needs. 6. Intergroup issues not resolvable by the individual representatives of the project engineering groups are handled according to a documented procedure. 7. Representatives of the project engineering groups conduct periodic technical reviews and interchanges. April 20, 2010
Level 3: Key Practices (Peer Reviews) Purpose: Peer Reviews – To remove errors from the software work products early and efficiently. – Involve a methodical examination of software work products by the producer's peers to identify errors and areas where changes are needed. Goals: Peer Reviews 1. Peer review activities are planned. 2. Errors or required changes in software work products are identified and removed. April 20, 2010
Level 3: Key Practices (Peer Reviews) Peer Reviews Practices: 1. Peer reviews are planned and plans are documented. 2. Peer reviews are performed according to a documented procedure. 3. Data on the conduct and results of the peer reviews are recorded. April 20, 2010
Скачать презентацию Software Process Improvement SEI Capability Maturity Model COP
d0a3bd60d6bcfafbb9f0d3402c0da4a3.ppt