Presentation is loading. Please wait.

Presentation is loading. Please wait.

Pittsburgh, PA 15213-3890 Copyright 2004, Carnegie Mellon University. All rights reserved. CMMI FOR SMALL BUSINESS PILOT – ASI KICKOFF MEETING SuZ Garcia,

Similar presentations


Presentation on theme: "Pittsburgh, PA 15213-3890 Copyright 2004, Carnegie Mellon University. All rights reserved. CMMI FOR SMALL BUSINESS PILOT – ASI KICKOFF MEETING SuZ Garcia,"— Presentation transcript:

1

2 Pittsburgh, PA Copyright 2004, Carnegie Mellon University. All rights reserved. CMMI FOR SMALL BUSINESS PILOT – ASI KICKOFF MEETING SuZ Garcia, SEI Sandra L. Cepeda, SEI Visiting Scientist/CSSA July, 2003

3 Copyright 2004, Carnegie Mellon University. All rights reserved. 2 Topics Introductions Context CMMI Overview Business Issues Analysis Path Forward

4 Copyright 2004, Carnegie Mellon University. All rights reserved. 3 CMMI OVERVIEW

5 Copyright 2004, Carnegie Mellon University. All rights reserved. 4 TOPICS IN THIS SECTION Purpose of CMM frameworks CMMI Executive Overview How CMMI Meets Its Purpose (basic model structures and terms) CMMI Process Area Contents Overview Overview Summary

6 Copyright 2004, Carnegie Mellon University. All rights reserved. 5 Purpose of CMM Frameworks The overall purpose of capability models is to establish a process improvement road­map upon which a route can be drawn from “where we are today” to “where we want to be.” Capability models define the characteristics of good processes and avoid prescribing how the processes must be enacted. Adapted from paper by Sarah Sheard, “Help! How Do I make my organization comply with yet another new model” Copyright (C) Software Productivity Consortium, NFP,2001 Originally published in International Council on Systems Engineering Symposium Proceedings 2001

7 Copyright 2004, Carnegie Mellon University. All rights reserved. 6 More specifically, CMMs Help You to: Verify process contents. Capability models encapsulate basic industry knowledge for an organization to use to help improve quality, customer satisfaction, productivity, and cycle time Demonstrate progress. Another primary use of capability models is to demonstrate improvement from year to year Benchmark. A model can be used to validate process improvement progress in comparison with competitors Structure new processes. Organizations that have not yet captured their basic engineering practices in documented processes frequently will look at capability models as a list of what needs to be included

8 Copyright 2004, Carnegie Mellon University. All rights reserved. 7 SEI Capability Maturity Model (CMM) Evolution in a Nutshell Software CMM initially developed by the Software Engineering Institute (circa ) Characterizes organizational software process capability in terms of “maturity” as evidenced by the widespread use of desirable practices Widely accepted by Government and industry Used both for external evaluation and self assessment Significant Improvements in quality and productivity reported over a wide variety of business contexts A plethora of discipline-specific CMM’s emerged in the 90’s System Engineering, Integrated Product/Process Dev, Software Acquisition, Security, People and more CMMI v1.0 issued August 2000 followed by v1.1 in 2001

9 Copyright 2004, Carnegie Mellon University. All rights reserved. 8 Why CMMI : It Becomes the Integrating Element Needed to integrate SW and SE disciplines Industry was interested and supportive SE arena had already integrated SE models SW CMM update was being finalized IPD CMM was almost final Solution was to integrate SW-CMM Ver. 2.0c (draft), EIA/IS 731, & IPD CMM v0.98 into a combined framework that could address either Software, Systems Engineering, or both, along with IPPD and supplier management.

10 Copyright 2004, Carnegie Mellon University. All rights reserved. 9 SW CMM SECM IPPD-CMM Core Core Core IPPD SE SW Other CMM’s CMM’s Example Lines of Business Include: IT Consulting Sys Arch, Engin & Delivery Enterprise Integration Data Center Operation IT Infrastructure Management Applications Management SETA Functional Process Outsourcing SEI CMMI Why CMMI : Multiple discipline-specific models have a common core Core Processes IPPD Discipline SE Discipline SW Discipline

11 What do we typically do when problems arise? Ignorance is bliss Denial AIIEEE ! Not a good method for problem solving

12 CMMI Provides a Path to a Better Way “The Purpose of CMM Integration is to provide guidance for improving your organization’s processes and your ability to manage the development, acquisition and maintenance of products and services.” CMMI Version 1.1

13 Copyright 2004, Carnegie Mellon University. All rights reserved. 12 CMMI OVERVIEW PART I: EXECUTIVE OVERVIEW

14 Copyright 2004, Carnegie Mellon University. All rights reserved. 13 What is the CMMI Model? CMMI Is a Process-Improvement Model that provides a set of Best Practices that address productivity, performance, costs, and stakeholder satisfaction. CMMI Is NOT a set of “Bolt-On Processes” that last only as Long as the wheel is squeaking. CMMI provides a consistent, enduring framework that accommodates new initiatives. CMMI focuses on the total-system problem, unlike other predecessor CMMs. CMMI facilitates enterprise-wide process improvement, unlike single-discipline models.

15 Copyright 2004, Carnegie Mellon University. All rights reserved. 14 Multiple Disciplines Engineering Development -Software Engineering -Systems Engineering -Concurrent Engineering -Hardware Engineering -“Assurance” Engineering Program Management -Project Management -Quality Assurance -Configuration and Data Management CMMI Scope & Coverage Total Product Life Cycle Multiple Applications Architecture Design -Systems -Electrical -Mechanical -Software System Integration and Test Logistics Operations Maintenance

16 StagedContinuous CMMI In A Nutshell PA Capability Process PA ML 1 ML2 ML3 ML4 ML5 Organization Maturity Level 5 OID, CAR Maturity Level 4 OPP, QPM Maturity Level 3 RD, TS, PI, VER, VAL, OPF, OPD, OT, IPM, RSKM, DAR, OEI, IT, ISM Maturity Level 2 REQM, PP, PMC, MA, PPQA, CM, SAM Process Areas (SE/SW/IPPD/SS) Requirements Management (REQM) Project Planning (PP) Project Monitoring and Control (PMC) Measurement and Analysis (MA) Process and Product Quality Assurance (PPQA) Configuration Management (CM) Supplier Agreement Management (SAM) Requirements Development (RD) Technical Solution (TS) Product Integration (PI) Verification (VER) Validation (VAL) Organizational Process Focus (OPF) Organizational Process Definition (OPD) Organizational Training (OT) Integrated Project Management (IPM) Risk Management (RSKM) Decision Analysis and Resolution (DAR) Organizational Environment for Integration (OEI) Integrated Teaming (IT) Integrated Supplier Management (ISM) Organizational Process Performance (OPP) Quantitative Project Management (QPM) Organizational Innovation & Deployment (OID) Causal Analysis and Resolution (CAR) Support CM, PPQA, MA, CAR, DAR, OEISupport Engineering REQM, RD, TS, PI, VER, VALEngineering Project Management PP, PMC, SAM, ISM, IPM, RSKM, QPM, IT Project Management PP, PMC, SAM, ISM, IPM, RSKM, QPM, IT Process Management OPF, OPD, OT, OPP, OID Process Management OPF, OPD, OT, OPP, OID  Two Representations Per CMMI Model  One Appraisal Method (SCAMPI)  Two Representations Per CMMI Model  One Appraisal Method (SCAMPI) Copyright 2003, CSSA, Inc. Used with permission.

17 Copyright 2004, Carnegie Mellon University. All rights reserved. 16 Using CMMI Correctly Correct use of CMMI implies: Reflecting on the reality of your business environment Tailoring (interpreting) CMMI to suit your context and needs Allowing for professional judgment Identifying problems as objectively as possible Thinking and analyzing how the CMMI applies Doing and not just thinking! Not forcing foolish decisions! Supporting worker participation and empowerment  Use the Model As a, Not a  Use the Model As a Guide, Not a Dictate  Tie Process Improvement to Business Goals  Use the Model As a, Not a  Use the Model As a Guide, Not a Dictate  Tie Process Improvement to Business Goals

18 Copyright 2004, Carnegie Mellon University. All rights reserved. 17 Value of CMMI (1 of 2) CMMI builds upon SW-CMM legacy: Better, expanded model scope Since many “software problems” are linked to systems issues, capabilities associated with disciplines other than software contribute to causal factors CMMI adds: New emphasis on product as well as process Coverage of services as well as systems Emphasis on process capability and organizational maturity Early emphasis on measurement and analysis Better coverage of engineering management A common, integrated vision of improvement for all elements of your organization Efficient, effective appraisals and improvement across multiple process disciplines Additional Productivity and Quality Gains

19 Copyright 2004, Carnegie Mellon University. All rights reserved. 18 Value of CMMI (2 of 2) CMMI helps organizations… Improve delivery of promised performance, cost, and schedule Integrate stakeholders into project activities Provide competitive world-class products and services Implement an integrated, enterprise, business and engineering perspective Use common, integrated, and improving processes for systems and software Implement proactive program management techniques Enable staff members to move between projects and still use the same processes Create and improve processes that adapt to a changing business environment

20 Pittsburgh, PA Copyright 2004, Carnegie Mellon University. All rights reserved. Business Case for Using CMMI

21 Notional Business Case for CMMI Reduced Development/ Maintenance Costs Improved Productivity Less Rework Increased Revenue/Profitability Improved Customer Satisfaction Reduced Post-Release Defects Measurable Improvements of Reliability and Quality Repeat Business Increased Product Sales Reduced Cycle Time Improved Process Performance Enhanced Time-to-Market Performance Bonuses for Early Delivery Improved Professional Staff Improved Employee Morale Increased Developer and Maintainer Confidence Reduced Employee Turnover and Retraining Costs Improved Competitive Advantage Better Products – Not Just Software – Out Sooner And Cheaper Copyright 2003, CSSA, Inc. Used with permission.

22 Building on the Legacy of SW- CMM Success Improvements From Adopting SW-CMM (SEI, 1994) Savings vs. cost of software process improvement (median) 5:1 Percentage Improvement Annual Medians +35% -19% Time to Market -39% Post-Release Defect Reports Productivity Current ROI Value to Programs (DACS, 1999) Application of SPI to “Example Organization With Example Projects”: Development CostsReduced 73% Rework Costs Reduced 96% Average Schedule Length Reduced 37% Post-Release Defects Reduced 80% Weighted Risk Likelihood Reduced 92% Return On Investment 21:1 Expect Even Higher ROI For CMMI

23 DoD Contractors Have Additional Motivation To Transition To The CMMI The Entire Supply Chain Is or Will Be Involved in CMMI DoDCustomers Associate Contractors Suppliers Competitors May Require Organizational Maturity or Process Capability in RFP, Implicitly or Explicitly May Use Organizational Maturity or Process Capability As a Discriminator Will Use Organizational Maturity or Process Capability to Advise Customers Will Use Organizational Maturity or Process Capability to Competitive Advantage Improve Integration of Products and Services Provide Insight Into Supplier Performance and Quality

24 Copyright 2004, Carnegie Mellon University. All rights reserved. 23 Feedback from Early Adopters CMMI is less burdensome in the implementation phases. CMMI provides detailed integrated acquisition management coverage that was only partially available in SW-CMM CMMI Transition Workshop CMMI is less burdensome in the implementation phases. CMMI provides detailed integrated acquisition management coverage that was only partially available in SW-CMM CMMI Transition Workshop “Involvement with and use of CMMI could have prevented a $21M cost overrun if we had had level 3 capability measurement and analysis process in place” Don Michels, SOF System Program Office, USAF/WR-ALC “Involvement with and use of CMMI could have prevented a $21M cost overrun if we had had level 3 capability measurement and analysis process in place” Don Michels, SOF System Program Office, USAF/WR-ALC “You have many reference systems available to measure how efficient you are and to evaluate the progress you make; the CMMI presents this advantage to be a reference as well as a guide towards good practices.” Thales “You have many reference systems available to measure how efficient you are and to evaluate the progress you make; the CMMI presents this advantage to be a reference as well as a guide towards good practices.” Thales

25 Copyright 2004, Carnegie Mellon University. All rights reserved. 24 CMMI Adoption

26 Copyright 2004, Carnegie Mellon University. All rights reserved. 25 Planned CMMI Adoption Life Cycle

27 Copyright 2004, Carnegie Mellon University. All rights reserved. 26 CMMI Adoption Challenges Understanding CMMI content and scope Interpreting and tailoring model for your organization Defining scope of improvement Selecting model representation Integrating disciplines, functions, and applications Eliminating existing process inconsistencies and reducing duplication Minimizing impact to projects Managing organizational change Analyzing legacy transition mechanisms Optimizing CMMI implementation as it relates to other quality improvement efforts

28 Copyright 2004, Carnegie Mellon University. All rights reserved. 27 CMMI... Re-cap... Supports engineering, management, and infrastructure improvement … Can be expanded to include special interest areas of disciplines not already included... Supports flexible process improvement approaches via 2 reflexive representations... Builds on a solid heritage of both principle and data to support process improvement... Provides the organizational infrastructure to support sustainment of other high-impact software engineering techniques

29 Copyright 2004, Carnegie Mellon University. All rights reserved. 28 The Bottom Line Without constant vigilance, steady pressure, and active visible support, the will melt down

30 Copyright 2004, Carnegie Mellon University. All rights reserved. 29 CMMI Overview Part II – Model Overview Model Representations Model Components and Fundamental Concepts High Level Overview of Process Area Contents and Relationships to Typical Business Issues

31 Model Representations Essentially the Same Content but Organized in a Different Way. Continuous …for a single process area or set of process areas Continuous …for a single process area or set of process areas Staged …for a pre-defined set of process areas across an organization Staged …for a pre-defined set of process areas across an organization CL0 (Incomplete) Process Area Capability PA CL1 (Initial) CL2 CL3 CL4 CL5 x y z Maturity Level 1 Initial: Process Unpredictable, Poorly Controlled, and Reactive Maturity Level 2 REQM, PP, PMC, MA, PPQA, CM, SAM Maturity Level 3 RD, TS, PI, VER, VAL, OPF, OPD, OT, IPM, RSKM, DAR, OEI, IT, ISM Maturity Level 4 OPP, QPM Maturity Level 5 OID, CAR Quantitatively Managed: Process Measured and Controlled Quantitatively Managed: Process Measured and Controlled Optimizing: Focus on Process Improvement Optimizing: Focus on Process Improvement Defined: Process Characterized for the Organization and Is Proactive Defined: Process Characterized for the Organization and Is Proactive Managed: Process Characterized for Projects and Is Often Reactive Managed: Process Characterized for Projects and Is Often Reactive Copyright 2003, CSSA, Inc. Used with permission.

32 CMMI Model Structure Staged Maturity Levels (1-5) Maturity Levels (1-5) Process Area 2 Directing Implementation Directing Implementation Commitment To Perform Commitment To Perform Verification Generic Goals (2-3) Generic Goals (2-3) Process Area 1 Process Area N Common Features Ability To Perform Ability To Perform Continuous Process Area 1 Process Area N Process Area 2 Capability Levels (0-5) Capability Levels (0-5) Specific Goals Generic Practices ( ) Generic Practices ( ) Specific Practices Generic Goals (1-5) Generic Goals (1-5) Specific Goals Generic Practices (1.1, , ) Generic Practices (1.1, , ) Specific Practices

33 Copyright 2004, Carnegie Mellon University. All rights reserved. 32 Process Areas A Process Area (PA) Is a Cluster of Related Practices in an Area That, When Performed Collectively, Satisfy a Set of Goals Considered Important for Making Significant Improvement in That Area Practices Are Actions Expected to Be Performed to Achieve the Goals of a Process Area All CMMI Process Areas Are Common to Both Continuous and Staged Representations A Process Area Is NOT a Process Description

34 CMMI Process Areas Process Areas LEVEL 5 Organizational Innovation & Deployment (OID) Causal Analysis and Resolution (CAR) LEVEL 4 Organizational Process Performance (OPP) Quantitative Project Management (QPM) LEVEL 3 Requirements Development (RD) Technical Solution (TS) Product Integration (PI) Verification (VER) Validation (VAL) Organizational Process Focus (OPF) Organizational Process Definition (OPD) Organizational Training (OT) Integrated Project Management (IPM) Risk Management (RSKM) Decision Analysis and Resolution (DAR) Organizational Environment for Integration (OEI) Integrated Teaming (IT) Integrated Supplier Management (ISM) LEVEL 2 Requirements Management (REQM) Project Planning (PP) Project Monitoring and Control (PMC) Measurement and Analysis (MA) Process and Product Quality Assurance (PPQA) Configuration Management (CM) Supplier Agreement Management (SAM) Staged Process Areas Project Management Quantitative Project Management (QPM) Integrated Project Management (IPM) Risk Management (RSKM) Integrated Teaming (IT) Integrated Supplier Management (ISM) Project Planning (PP) Project Monitoring and Control (PMC) Supplier Agreement Management (SAM)) Process Management Organizational Innovation & Deployment (OID) Organizational Process Performance (OPP) Organizational Process Focus (OPF) Organizational Process Definition (OPD) Organizational Training (OT) Engineering Requirements Management (REQM) Requirements Development (RD) Technical Solution (TS) Product Integration (PI) Verification (VER) Validation (VAL) Support Causal Analysis and Resolution (CAR) Decision Analysis and Resolution (DAR) Organizational Environment for Integration (OEI) Measurement and Analysis (MA) Process and Product Quality Assurance (PPQA) Configuration Management (CM) Continuous

35 CMMI Model Structure Staged Maturity Levels (1-5) Maturity Levels (1-5) Process Area 2 Directing Implementation Directing Implementation Commitment To Perform Commitment To Perform Verification Generic Goals (2-3) Generic Goals (2-3) Process Area 1 Process Area N Common Features Ability To Perform Ability To Perform Continuous Process Area 1 Process Area N Process Area 2 Capability Levels (0-5) Capability Levels (0-5) Specific Goals Generic Practices ( ) Generic Practices ( ) Specific Practices Generic Goals (1-5) Generic Goals (1-5) Specific Goals Generic Practices (1.1, , ) Generic Practices (1.1, , ) Specific Practices

36 Copyright 2004, Carnegie Mellon University. All rights reserved. 35 Specific Goals (SGs) A Specific Goal Applies to a Process Area and Addresses the Unique Characteristics That Describe What Must Be Implemented to Satisfy That Process Area Example From the Project Planning Process Area: SG 2: A Project Plan Is Established And Maintained as the Basis For Managing The Project

37 Copyright 2004, Carnegie Mellon University. All rights reserved. 36 Specific Practices (SPs) A Specific Practice is an activity that is considered important in achieving the associated Specific Goal Practices are the major building blocks in establishing the process maturity of an organization Example from the Project Planning process area : Sp 2.1-1: Establish and maintain the project’s budget and schedule

38 CMMI Model Structure Staged Maturity Levels (1-5) Maturity Levels (1-5) Process Area 2 Directing Implementation Directing Implementation Commitment To Perform Commitment To Perform Verification Generic Goals (2-3) Generic Goals (2-3) Process Area 1 Process Area N Common Features Ability To Perform Ability To Perform Continuous Process Area 1 Process Area N Process Area 2 Capability Levels (0-5) Capability Levels (0-5) Specific Goals Generic Practices ( ) Generic Practices ( ) Specific Practices Generic Goals (1-5) Generic Goals (1-5) Specific Goals Generic Practices (1.1, , ) Generic Practices (1.1, , ) Specific Practices

39 Copyright 2004, Carnegie Mellon University. All rights reserved. 38 What Is Institutionalization? Institutionalization involves implementing practices that Ensure processes can be communicated about (they are defined, documented, understood) Ensure the processes are effective, repeatable and lasting Provide needed infrastructure support Enable organizational learning to improve the process

40 Copyright 2004, Carnegie Mellon University. All rights reserved. 39 Why is Institutionalization Important? Without institutionalization Process improvement may not relate to business goals Processes will not be executed or managed consistently The processes will not survive staff or leadership changes The organization will find itself continuously “reinventing the wheel” Commitment to provide resources or infrastructure to support or improve the processes will be missing or insufficient Historical data will not be useful to support future projects

41 Copyright 2004, Carnegie Mellon University. All rights reserved. 40 Realizing Institutionalization In CMMI Models Continuous representation The basis for institutionalization is established via the Capability Level 2 generic practices This basis is extended in the Capability Level 3, 4 and 5 generic practices Staged representation Institutionalization is the primary focus of the common features -The Common Features correspond to the Capability Level 2 and 3 generic practices

42 Copyright 2004, Carnegie Mellon University. All rights reserved. 41 Generic Goals (GGs) Achievement of a generic goal in a process area signifies improved control in planning and implementing the processes associated with that process area Generic Goals are called “generic” because the same goal statement applies to multiple process areas

43 Copyright 2004, Carnegie Mellon University. All rights reserved. 42 Generic Practices (GPs) Generic Practices are activities that ensure that the processes associated with the process area will be effective, repeatable, and lasting Generic Practices contribute to the achievement of the generic goal when applied to a particular process area

44 CL 1 CL 2 CL3 CL4 CL5 Level Generic Goals And Practices GG2: Institutionalize a Managed Process Generic PracticesGeneric Goals GG3: Institutionalize a Defined Process GP 3.1: Establish a Defined Process GP 3.2: Collect Improvement Information GG4: Institutionalize a Quantitatively Managed Process GP 4.1: Establish Quantitative Objectives for the Process GP 4.2: Stabilize Subprocess Performance GG5: Institutionalize an Optimizing Process GP 5.1: Ensure Continuous Process Improvement GP 5.2: Correct Root Causes of Problems GP 2.1: Establish an Organizational Policy GP 2.2: Plan the Process GP 2.3: Provide Resources GP 2.4: Assign Responsibility GP 2.5: Train People GP 2.6: Manage Configurations GP 2.7: Identify and Involve Relevant Stakeholders GP 2.8: Monitor and Control the Process GP 2.9: Objectively Evaluate Adherence GP 2.10: Review Status with Higher Level Management GG1: Achieve Specific Goals GP 1.1: Perform Base Practices ML 2 ML 3 ML 4 ML 5 Common Features Mapping Commitment to Perform GP 2.1: Establish an Organizational Policy GP 2.2: Plan the Process GP 2.3: Provide Resources GP 2.4: Assign Responsibility GP 2.5: Train People GP 2.6: Manage Configurations GP 2.7: Identify and Involve Relevant Stakeholders GP 2.8: Monitor and Control the Process GP 2.9: Objectively Evaluate Adherence GP 2.10: Review Status with Higher Level Management Ability to Perform Directing Implementation Verifying Implementation GP 3.1: Establish a Defined Process GP 3.2: Collect Improvement Information Copyright 2003, CSSA, Inc. Used with permission.

45 ML4 Quantitatively Managed Improving Maturity Levels (Staged Representation) ML1 Initial ML2 Managed ML3 Defined ML5 Optimizing Process Is Unpredictable Adhere to Policy; Follow Documented Plans and Processes; Apply Adequate Resources; Assign Responsibility and Authority; Train People; Apply CM; Monitor and Control Process; Evaluate Process and Product Quality; Identify and Involve Stakeholders; Review With Management Project’s Process Is Tailored From Organization’s Standard Processes; Understand Process Qualitatively; Process Contributes to the Organization’s Assets Measure Process Performance; Stabilize Process; Control Charts; Deal With Causes of Special Variations GP 2.1- GP 2.10 applied to all process areas in ML 2 All SP’s for the ML 2 Process Areas GP 2.1- GP 3.2 applied to All Process Areas in ML 2, ML 3, ML 4, and ML 5 All SP’s for the ML 2, ML 3, ML 4, and ML 5 Process Areas GP 2.1- GP 3.2 applied to All Process Areas in ML 2, ML 3, and ML 4 All SP’s for the ML 2, ML 3, and ML 4 Process Areas GP 2.1- GP 3.2 applied to All Process Areas in ML 2 and ML 3 All SP’s for the ML 2 and ML 3 Process Areas Defect Prevention; Proactive Improvement; Innovative Technology Insertion and Deployment

46 Improving A Process Area (Continuous Representation) Not Performed, Incomplete No GPs or SPs exist GP1.1 CL1 (base) SPs GP1.1 through GP2.10 CL1 + CL2* SPs GP1.1 through GP3.2 CL1+CL2*+CL3* SPs GP1.1 through GP4.2 CL1+CL2*+CL3* SPs Perform the Work Adhere to Policy; Follow Documented Plans and Processes;Apply Adequate Resources; Assign Responsibility and Authority; Train People; Apply CM; Monitor and Control Process; Evaluate Process and Product Quality; Identify and Involve Stakeholders; Review With Management Project’s Process Is Tailored From Organization’s Standard Processes; Understand Process Qualitatively; Process Contributes to the Organization’s Assets Measure Process Performance; Stabilize Process; Control Charts; Deal With Causes of Special Variations * Advanced practices exist only in the Engineering PAs. CL0 Incomplete CL1 Performed CL2 Managed CL3 Defined CL4 Quantitatively Managed CL5 Optimizing GP1.1 through GP5.2 CL1+CL2*+CL3* SPs Defect Prevention; Proactive Improvement; Innovative Technology Insertion and Deployment

47 Required Components in CMMI Staged Maturity Levels (1-5) Maturity Levels (1-5) Process Area 2 Directing Implementation Directing Implementation Commitment To Perform Commitment To Perform Verification Generic Goals (2-3) Generic Goals (2-3) Process Area 1 Process Area N Common Features Ability To Perform Ability To Perform Continuous Process Area 1 Process Area N Process Area 2 Capability Levels (0-5) Capability Levels (0-5) Specific Goals Generic Practices ( ) Generic Practices ( ) Specific Practices Generic Goals (1-5) Generic Goals (1-5) Specific Goals Generic Practices (1.1, , ) Generic Practices (1.1, , ) Specific Practices These model components  Are essential to achieving process improvement in a given Process Area  Are used in appraisals to determine Process Area Capability These model components  Are essential to achieving process improvement in a given Process Area  Are used in appraisals to determine Process Area Capability

48 Expected Components in CMMI Staged Maturity Levels (1-5) Maturity Levels (1-5) Process Area 2 Directing Implementation Directing Implementation Commitment To Perform Commitment To Perform Verification Generic Goals (2-3) Generic Goals (2-3) Process Area 1 Process Area N Common Features Ability To Perform Ability To Perform Continuous Process Area 1 Process Area N Process Area 2 Capability Levels (0-5) Capability Levels (0-5) Specific Goals Generic Practices ( ) Generic Practices ( ) Specific Practices Generic Goals (1-5) Generic Goals (1-5) Specific Goals Generic Practices (1.1, , ) Generic Practices (1.1, , ) Specific Practices These model components  Explain what will typically be done to cover the scope of the process and its goals  Are meant to guide model users and help appraisers  Allow acceptable alternatives These model components  Explain what will typically be done to cover the scope of the process and its goals  Are meant to guide model users and help appraisers  Allow acceptable alternatives

49 Copyright 2004, Carnegie Mellon University. All rights reserved. 48 Informative Model Components Everything else is informative These model components provide details about the model

50 Pittsburgh, PA Copyright 2004, Carnegie Mellon University. All rights reserved. PROCESS AREA CONTENTS AND RELATED BUSINESS ISSUES

51 Copyright 2004, Carnegie Mellon University. All rights reserved. 50 Estimates of project planning parameters are established and maintained A project plan is established and maintained as the basis for managing the project Commitments to the project plan are established and maintained Project Planning Purpose: Establish and Maintain Plans That Define Project Activities Project Management (ML 2): PP (1 of 4)

52 Copyright 2004, Carnegie Mellon University. All rights reserved. 51 Establish Estimates Obtain Commitment To the Plan Obtain Commitment To the Plan Goals Practices Typical Work Products Project Planning Project Management (ML 2): PP (2 of 4) Develop a Project Plan Develop a Project Plan Estimate the Scope of The Project Establish Estimates of Work Product & Task Attributes Define Project Life Cycle Determine Estimates of Effort & Cost Task Descriptions Work Package Descriptions WBS Technical Approach Size and Complexity of Tasks and Work Products Estimating Models Project Life-Cycle Phases Estimation Rationale Project Effort Estimates Project Cost Estimates

53 Copyright 2004, Carnegie Mellon University. All rights reserved. 52 Establish Estimates Obtain Commitment To the Plan Obtain Commitment To the Plan Goals Practices Typical Work Products Project Planning Project Management (ML 2): PP (3 of 4) Develop a Project Plan Develop a Project Plan Establish the Budget & Schedule Identify Project Risks Plan for Data Management Plan for Project Resources Plan for Needed Knowledge & Skills Plan Stakeholder Involvement Establish the Project Plan Project Schedules Schedule Dependencies Project Budget Identified Risks Risk Impacts and Probability of Occurrence Risk Priorities Data Management Plan Master List of Managed Data Data Content and Format Description WBS Work Packages WBS Task Dictionary Staffing Requirements Based on Project Size & Scope Inventory of Skill Needs Staffing and New Hire Plans Databases (e.g., Skills and Training) Stakeholder Involvement Plan Overall Project Plan

54 Copyright 2004, Carnegie Mellon University. All rights reserved. 53 Establish Estimates Goals Practices Typical Work Products Project Planning Project Management (ML 2): PP (4 of 4) Develop a Project Plan Develop a Project Plan Review Plans That Affect The Project Reconcile Work and Resource Levels Obtain Plan Commitment Record of the Reviews of Plans that Affect the Project Revised Methods and Corresponding Estimating Parameters Renegotiated Budgets Revised Schedules Documented Requests for Commitments Documented Commitments Obtain Commitment To the Plan Obtain Commitment To the Plan

55 Copyright 2004, Carnegie Mellon University. All rights reserved. 54 When Project Planning isn’t done well… Symptoms Poor estimates that lead to cost and schedule overruns Failed projects Unable to discover deviations from undocumented plans Resources aren’t available/applied when needed Unable to meet commitments Why Should You Care? Because…. Customers don’t trust suppliers who waste their resources -- loss of future business No lessons learned for future projects means making the same mistakes on multiple projects Unhappy customers, employees,and stockholders means a short life for the business If you fail to plan then you plan to fail!

56 Copyright 2004, Carnegie Mellon University. All rights reserved. 55 Actual Performance and Progress of the Project are Monitored Against the Project Plan Project Monitoring & Control Corrective Actions are Managed to Closure When the Project’s Performance or Results Deviate Significantly From the Plan Purpose: Provide an Understanding of the Project’s Progress So That Appropriate Corrective Actions Can Be Taken When the Project’s Performance Deviates Significantly From the Plan. Project Management (ML 2): PMC (1 of 3)

57 Copyright 2004, Carnegie Mellon University. All rights reserved. 56 Monitor Project Against Plan Monitor Project Against Plan Project Monitoring & Control Monitor Project Planning Parameters Manage Corrective Action to Closure Manage Corrective Action to Closure Monitor Commitments Monitor Project Risks Conduct Milestone Reviews Conduct Progress Reviews Monitor Stakeholder Involvement Monitor Data Management Goals Practices Typical Work Products Project Management (ML 2): PMC (2 of 3) Records of Project Performance Records of Significant Deviations Records of Commitment Reviews Records of Project Risk Monitoring Records of Data Management Records of Stakeholder Involvement Documented Project Review Results Documented Milestone Review Results

58 Copyright 2004, Carnegie Mellon University. All rights reserved. 57 Monitor Project Against Plan Monitor Project Against Plan Project Monitoring & Control Manage Corrective Action to Closure Manage Corrective Action to Closure Analyze Issues Manage Corrective Action Take Corrective Action Goals Practices Typical Work Products Project Management (ML 2): PMC (3 of 3) List of Issues Needing Corrective Actions Corrective Action Plan Corrective Action Results

59 Copyright 2004, Carnegie Mellon University. All rights reserved. 58 When Project Monitoring and Control isn’t done well…. Symptoms Crisis management High rework levels throughout the project Lots of time spent in meetings trying to “discover” project status rather than reporting on it Data needed for management decisions is unavailable when needed Actions that should have been taken early on aren’t discovered until it’s too late Why Should You Care? Because…. If you don’t know what’s going on, corrective action can’t be taken early when it’s least expensive Lack of management insight/oversight makes project results highly unpredictable, even later in the project If your confidence in the status you give to your customer is low, they probably perceive that!

60 Copyright 2004, Carnegie Mellon University. All rights reserved. 59 Agreements With the Suppliers are Established and Maintained Supplier Agreement Management Agreements With the Suppliers are Satisfied by Both the Project and the Supplier Purpose: Manage the Acquisition of Products From Suppliers for Which There Exists a Formal Agreement. Project Management (ML 2): SAM (1 of 3)

61 Copyright 2004, Carnegie Mellon University. All rights reserved. 60 Establish Supplier Agreements Supplier Agreement Management Determine Acquisition Type Satisfy Supplier Agreements Select Suppliers Establish Supplier Agreements Goals Practices Typical Work Products Project Management (ML 2): SAM (2 of 3) List of the Acquisition Types That Will be Used for All Products and Product Components to be Acquired List of Candidate Suppliers Preferred Supplier List Rationale for Selection of Suppliers Statements of Work Contracts Memoranda of Agreement

62 Copyright 2004, Carnegie Mellon University. All rights reserved. 61 Establish Supplier Agreements Supplier Agreement Management Satisfy Supplier Agreements Review COTS Products Execute the Supplier Agreement Transition Products Accept the Acquired Product Goals Practices Typical Work Products Project Management (ML 2): SAM (3 of 3) Trade Studies Price Lists Evaluation Criteria Supplier Progress Reports and Performance Measures Supplier Review Materials and Reports Action items tracked to Closure Acceptance Test Procedures Acceptance Test Results Discrepancy Reports or Corrective Action Plans Transition Plans Training Reports Support and Maintenance Reports

63 Copyright 2004, Carnegie Mellon University. All rights reserved. 62 When Supplier Agreement Management isn’t done well… Symptoms: Sub-optimal Supplier selection– not based on the right criteria Integration of supplier products into product baseline is problematic Management and technical staff do not have insight into supplier’s activities Supplier issues are not uncovered in a timely manner Supplier products are accepted even when they don’t meet the product requirements Why Should You Care? Because…. A supplier can make or break your project You are ultimately responsible to your customer for supplier performance

64 Copyright 2004, Carnegie Mellon University. All rights reserved. 63 The Project is Conducted Using a Defined Process That is Tailored from the Organization’s Set of Standard Processes Integrated Project Management Coordination and Collaboration of the Project With Relevant Stakeholders is Conducted Purpose: Establish and Manage the Project and the Involvement of the Relevant Stakeholders According to an Integrated and Defined Process That Is Tailored From the Organization's Set of Standard Processes. Project Management (ML 3): IPM (1 of 3)

65 Copyright 2004, Carnegie Mellon University. All rights reserved. 64 Interaction Between OPD and IPM Project A’s Defined Process Project B’s Defined Process Project C’s Defined Process Project A’s Project Plan Project B’s Project Plan Project C’s Project Plan Tailoring Guidelines Life-Cycle Model Descriptions Organization’s Measurement Repository Organization’s Process Asset Library Reviews Organization’s Set of Standard Processes Process Architectures Project Environment Organizational Assets OPD IPM

66 Copyright 2004, Carnegie Mellon University. All rights reserved. 65 Use the Project’s Defined Process Integrated Project Management Establish the Project’s Defined Process Coordinate and Collaborate With Relevant Stakeholders Contribute to the Organizational Process Assets Manage the Project Using the Integrated Plans Integrate Plans Use Organizational Process Assets for Planning Project Activities Goals Practices Typical Work Products Project Management (ML 3): IPM (2 of 3) The Project’s Defined Process Project Estimates Project Plans Integrated Plans Work Products Created by Performing the Project’s Defined Process Collected Measures (“Actuals”) and Progress Records or Reports Revised Requirements, Plans, and Commitments Proposed Improvements to the Organizational Process Assets Actual Process and Product Measures Collected From the Project Documentation (e.g., exemplary process descriptions, plans, training modules, checklists, and lessons learned)

67 Copyright 2004, Carnegie Mellon University. All rights reserved. 66 Use the Project’s Defined Process Integrated Project Management Coordinate and Collaborate With Relevant Stakeholders Manage Stakeholder Involvement Manage Dependencies Resolve Coordination Issues Goals Practices Typical Work Products Project Management (ML 3): IPM (3 of 3) Agendas and Schedules for Collaborative Activities Documented Issues (e.g., issues with customer requirements, product and product-component requirements, product architecture, and product design) Recommendations for Resolving Relevant Stakeholder Issues Defects, Issues, and Action Items Resulting From Reviews With Relevant Stakeholders Critical Dependencies Commitments to Address Critical Dependencies Relevant Stakeholder Coordination Issues Status of Relevant Stakeholder Coordination Issues

68 Copyright 2004, Carnegie Mellon University. All rights reserved. 67 When Integrated Project Management isn’t done well….. Symptoms: Unclear responsibilities across functional area boundaries No integrated master schedule is available to guide the stakeholders of the project Data/artifacts to support future similar projects aren’t available when needed Relationship of project’s process/plans to organizational standards is unclear Why Should You Care? Because….. Managing a “stovepiped” project increases the time/effort needed to assure that all the requirements are being met Different stakeholders stepping on each other’s toes is a huge waste of time/effort/money The customer will see different perspectives, status, etc from different elements of the same project You may be the project manager for the “next” project and will need all the help you can get from past projects You may be using less effective processes than the organization knows about through its standard processes

69 Copyright 2004, Carnegie Mellon University. All rights reserved. 68 Preparation for Risk Management is Conducted Risk Management Risks are Identified and Analyzed to Determine Their Relative Importance Risks are Handled and Mitigated, Where Appropriate, to Reduce Adverse Impacts on Achieving Objectives Purpose: Identify Potential Problems Before They Occur, So That Risk-handling Activities May Be Planned and Invoked As Needed Across the Life of the Product or Project to Mitigate Adverse Impacts on Achieving Objectives. Project Management (ML 3): RSKM (1 of 4)

70 Copyright 2004, Carnegie Mellon University. All rights reserved. 69 Prepare for Risk Management Risk Management Determine Risk Sources and Categories Identify and Analyze Risks Mitigate Risks Define Risk Parameters Establish a Risk Management Strategy Goals Practices Typical Work Products Project Management (ML 3): RSKM (2 of 4) Risk Source Lists (external and internal) Risk Categories List Risk Evaluation, Categorization, and Prioritization Criteria Risk Management Requirements (control and approval levels, reassessment intervals, etc.) Project Risk Management Strategy

71 Copyright 2004, Carnegie Mellon University. All rights reserved. 70 Prepare for Risk Management Risk Management Identify and Analyze Risks Mitigate Risks Identify Risks Evaluate, Categorize, and Prioritize Risks Goals Practices Typical Work Products Project Management (ML 3): RSKM (3 of 4) List of Identified Risks, Including the Context, Conditions, and Consequences of Risk Occurrence List of Risks, With a Priority Assigned to Each Risk

72 Copyright 2004, Carnegie Mellon University. All rights reserved. 71 Prepare for Risk Management Risk Management Identify and Analyze Risks Mitigate Risks Develop Risk Mitigation Plans Implement Risk Mitigation Plans Goals Practices Typical Work Products Project Management (ML 3): RSKM (4 of 4) Documented Handling Options for Each Identified Risk Risk Mitigation Plans Updated Lists of Risk Status Updated Assessment of Risk Likelihood, Consequence, and Thresholds Updated Lists of Risk-Handling Options

73 Copyright 2004, Carnegie Mellon University. All rights reserved. 72 When Risk Management isn’t done well… Symptoms: Idealistic approach that assumes “all is well” even when there is evidence that all is NOT well Issues that are known risks to project staff are a surprise to management Every time a new problem manifests, a new management technique is tried Why Should You Care? Because… The project may escape some of the “bullets”, but not all No lessons learned for future projects means making the same mistakes on multiple projects Repeated project failures due to the realization of unforeseen (but predictable!) risks costs you business, if not the whole company

74 Copyright 2004, Carnegie Mellon University. All rights reserved. 73 Potential Sources of Products That Best Fit the Needs of the Project are Identified, Analyzed, and Selected Integrated Supplier Management Work is Coordinated With Suppliers to Ensure the Supplier Agreement is Executed Appropriately Purpose: Proactively Identify Sources of Products That May Be Used to Satisfy the Project’s Requirements and Manage Selected Suppliers While Maintaining a Cooperative Project-supplier Relationship. Project Management (ML 3): ISM (1 of 3)

75 Copyright 2004, Carnegie Mellon University. All rights reserved. 74 Analyze and Select Sources of Products Integrated Supplier Management Analyze Potential Sources of Products Coordinate Work With Suppliers Evaluate and Determine Sources of Products Goals Practices Typical Work Products Project Management (ML 3): ISM (2 of 3) List of Potential Sources of Products That Might be Acquired Market Studies Trade Studies Analysis and Evaluation Reports Revised List of Product Sources

76 Copyright 2004, Carnegie Mellon University. All rights reserved. 75 Analyze and Select Sources of Products Integrated Supplier Management Coordinate Work With Suppliers Monitor Selected Supplier Processes Revise the Supplier Agreement or Relationship Evaluate Selected Supplier Work Products Goals Practices Typical Work Products Project Management (ML 3): ISM (3 of 3) List of Processes Selected for Monitoring Activity Reports Performance Reports List of Work Products Selected for Monitoring Activity Reports Discrepancy Reports Revisions to the Supplier Agreement Revisions to the Project’s and Supplier’s Processes and Work Products

77 Copyright 2004, Carnegie Mellon University. All rights reserved. 76 Baselines of Identified Work Products are Established Configuration Management Changes to the Work Products Under Configuration Management are Tracked and Controlled Integrity of Baselines is Established and Maintained Purpose: Establish and Maintain the Integrity of Work Products Using Configuration Identification, Configuration Control, Configuration Status Accounting, and Configuration Audits. Support (ML 2): CM (1 of 4)

78 Copyright 2004, Carnegie Mellon University. All rights reserved. 77 Establish Baselines Configuration Management Identify Configuration Items Track and Control Changes Establish Integrity Establish a Configuration Management System Create or Release Baselines Goals Practices Typical Work Products Support (ML 2): CM (2 of 4) Identified Configuration Items Configuration Management System With Controlled Work Products Configuration Management System Access Control Procedures Change Request Database Baselines Description of Baselines

79 Copyright 2004, Carnegie Mellon University. All rights reserved. 78 Establish Baselines Configuration Management Track and Control Changes Establish Integrity Track Change Requests Control Configuration Items Goals Practices Typical Work Products Support (ML 2): CM (3 of 4) Change Requests Revision History of Configuration Items Archives of the Baselines

80 Copyright 2004, Carnegie Mellon University. All rights reserved. 79 Establish Baselines Configuration Management Track and Control Changes Establish Integrity Establish Configuration Management Records Perform Configuration Audits Goals Practices Typical Work Products Support (ML 2): (4 of 4) Revision History of Configuration Items Change Log Copy of the Change Requests Configuration Audit Results Action Items

81 Copyright 2004, Carnegie Mellon University. All rights reserved. 80 When Configuration Management isn’t done well… Symptoms: Baseline system can’t be produced when needed Rework during test because components are not what was expected Complete inventory of system components unavailable when needed -Causes wasted time to find parts and specs and interfaces Uncontrolled changes that lead to uncontrolled rework Why Should You Care? Because… Not knowing what is in the product leads to embarrassing discussions with customers Inability to rebuild/revisit a previous baseline wastes money and resources during maintenance Not being able to verify that the product tested is the product delivered costs you time, effort, and customer confidence If you don’t know what’s in or out of the product, you don’t know what you don’t know!

82 Copyright 2004, Carnegie Mellon University. All rights reserved. 81 Adherence of the Performed Process and Associated Work Products and Services to Applicable Process Descriptions, Standards, and Procedures is Objectively Evaluated Process and Product Quality Assurance Noncompliance Issues are Objectively Tracked and Communicated, and resolution is ensured Purpose: Provide Staff and Management With Objective Insight Into Processes and Associated Work Products. Support (ML 2): PPQA (1 of 3)

83 Copyright 2004, Carnegie Mellon University. All rights reserved. 82 Objectively Evaluate Processes and Work Products Process and Product Quality Assurance Objectively Evaluate Processes Provide Objective Insight Objectively Evaluate Work Products and Services Goals Practices Typical Work Products Support (ML 2): PPQA (2 of 3) Evaluation Reports Noncompliance Reports Corrective Actions

84 Copyright 2004, Carnegie Mellon University. All rights reserved. 83 Objectively Evaluate Processes and Work Products Process and Product Quality Assurance Provide Objective Insight Communicate and Ensure Resolution of Noncompliance Issues Establish Records Goals Practices Typical Work Products Support (ML 2): PPQA (3 of 3) Corrective Action Reports Evaluation Reports Quality Trends Evaluation Logs Quality Assurance Reports Status Reports of Corrective Actions

85 Copyright 2004, Carnegie Mellon University. All rights reserved. 84 When Process and Product Quality Assurance aren’t done well… Symptoms: No assurance is available that quality standards are followed or achieved Poor quality work products being produced Ineffective processes that staff avoid using No accountability for not following process or meeting standards Significant project issues are not escalated for management attention Why Should You Care? Because… Loss of management insight into development process can cause significant issues to be missed Poor quality interim products reduce customer’s confidence that you can provide a high quality delivered product -You’re likely to lose that customer’s business in future

86 Copyright 2004, Carnegie Mellon University. All rights reserved. 85 Measurement Objectives and Activities are Aligned With Identified Information Needs and Objectives Measurement & Analysis Measurement Results That Address Identified Information Needs and Objectives are Provided Purpose: Develop and Sustain a Measurement Capability That Is Used to Support Management Information Needs. Support (ML 2): MA (1 of 3)

87 Copyright 2004, Carnegie Mellon University. All rights reserved. 86 Align Measurement and Analysis Activities Measurement & Analysis Establish Measurement Objectives Provide Measurement Results Specify Measures Specify Data Collection and Storage Procedures Specify Analysis Procedures Goals Practices Typical Work Products Support (ML 2): MA (2 of 3) Measurement Objectives Specifications of Base and Derived Measures Data Collection and Storage Procedures Data Collection Tools Analysis Specification and Procedures Data Analysis Tools

88 Copyright 2004, Carnegie Mellon University. All rights reserved. 87 Align Measurement and Analysis Activities Measurement & Analysis Provide Measurement Results Collect Measurement Data Analyze Measurement Data Store Data and Results Communicate Results Goals Practices Typical Work Products Support (ML 2): MA (3 of 3) Base and Derived Measurement Data Sets Results of Data Integrity Tests Analysis Results and Draft Reports Stored Data Inventory Delivered Reports and Related Analysis Results Contextual Information or Guidance to Aid in the Interpretation of Analysis Results

89 Copyright 2004, Carnegie Mellon University. All rights reserved. 88 When Measurement and Analysis isn’t done well… Symptoms: Measurements unknowingly used inappropriately/ out of context Management by perception/judgment vs. by fact Measurement presentations being used to confuse rather than enlighten Useless measures being collected Why Should You Care? Because… Poor decisions that cannot be justified reduce customer and staff confidence Collected measures don’t allow you to quantify how close you are to meeting your business goals Having no valid basis for prioritizing improvements could lead you to significant wasted overhead time, effort, money High risk for not meeting customer expectations wrt. delivery/quality of product

90 Copyright 2004, Carnegie Mellon University. All rights reserved. 89 Decision Analysis & Resolution Decisions are Based on an Evaluation of Alternatives Using Established Criteria Purpose: Analyze Possible Decisions Using a Formal Evaluation Process That Evaluates Identified Alternatives Against Established Criteria. Support (ML 3): DAR (1 of 2)

91 Copyright 2004, Carnegie Mellon University. All rights reserved. 90 Decision Analysis & Resolution Evaluate Alternatives Establish Guidelines for Decision Analysis Select Solutions Evaluate Alternatives Select Evaluation Methods Identify Alternative Solutions Establish Evaluation Criteria Goals Practices Typical Work Products Support (ML 3): DAR (2 of 2) Guidelines for When to Apply a Formal Evaluation Process Documented Evaluation Criteria Rankings of Criteria Importance Identified Alternatives Selected Evaluation Methods Evaluation Results Recommended Solutions to Address Significant Issues

92 Copyright 2004, Carnegie Mellon University. All rights reserved. 91 When Decision Analysis & Resolution isn’t done well….. Symptoms: Unclear who is authorized to make what decisions Decisions are made on primarily subjective basis Same issue is “decided” over and over and over…… Rationale for earlier decisions is unavailable when needed to understand the decision later in the project Only a few choices considered for major decisions Why Should You Care? Because….. Decisions getting made without all the relevant factors being considered usually costs time or money later on Missing a more optimal solution can cost you time, money, credibility, perhaps even the whole project Revisiting decisions, digging up rationale, undoing decisions reduce customer confidence in your expertise and technical ability to serve their needs

93 Copyright 2004, Carnegie Mellon University. All rights reserved. 92 The Engineering Process Areas RD PI Val Customer TS Ver REQM Requirements Customer needs Product and product component requirements Product components, work products, verification and validation reports Product components Alternative solutions Require- ments Product

94 Copyright 2004, Carnegie Mellon University. All rights reserved. 93 Requirements Management Requirements are Managed and Inconsistencies With Project Plans and Work Products are Identified Purpose: Manage the Requirements of the Project's Products and Product Components and Identify Inconsistencies Between Those Requirements and the Project's Plans and Work Products. Engineering (ML 2): REQM (1 of 2)

95 Copyright 2004, Carnegie Mellon University. All rights reserved. 94 Requirements Management Manage Requirements Obtain an Understanding of Requirements Identify Inconsistencies Between Project Work and Requirements Maintain Bidirectional Traceability of Requirements Manage Requirements Changes Obtain Commitment to Requirements Goals Practices Typical Work Products List of Criteria for Distinguishing Appropriate Requirements Providers Criteria for Evaluation and Acceptance of Requirements Results of Analysis Against Criteria Requirements Impact Assessments Documented Commitments to Requirements and Requirements Changes Requirements Status Requirements Database Requirements Decision Database Requirements Traceability Matrix Requirements Tracking System Documentation of Inconsistencies Including Sources, Conditions, and Rationale Corrective Actions Engineering (ML 2): REQM (2 of 2)

96 Copyright 2004, Carnegie Mellon University. All rights reserved. 95 When Requirements Management isn’t done well…. Symptoms: High levels of re-work throughout the project Requirements accepted by staff from any source they deem to be authoritative “Galloping” requirements creep Inability to “prove” that the product meets the approved requirements Why Should You Care? Because…. Lack of agreement among stakeholders as to what are the “real” requirements increases time and cost to complete the project You’re highly likely to deliver an incorrect or incomplete product Revisiting requirements changes over and over is a waste of resource highly visible to the customer

97 Copyright 2004, Carnegie Mellon University. All rights reserved. 96 Shareholder Needs, Expectations, Constraints, and Interfaces are Collected and Translated Into Customer Requirements Requirements Development Customer Requirements are Refined and Elaborated to Develop Product and Product- Component Requirements The Requirements are Analyzed and Validated, and a Definition of Required Functionality is Developed Purpose: Produce and Analyze Customer, Product, and Product- component Requirements. Engineering (ML 3): RD (1 of 4)

98 Copyright 2004, Carnegie Mellon University. All rights reserved. 97 Develop Customer Requirements Requirements Development Collect Stakeholder Needs Develop Product Requirements Analyze and Validate Requirements Elicit Needs Develop the Customer Requirements Customer Requirements Customer Constraints on the Conduct of Verification Customer Constraints on the Conduct of Validation Engineering (ML 3): RD (2 of 4) Goals Practices Typical Work Products Continuous Representation Only

99 Copyright 2004, Carnegie Mellon University. All rights reserved. 98 Develop Customer Requirements Requirements Development Develop Product Requirements Analyze and Validate Requirements Establish Product and Product-component Requirements Allocate Product-component Requirements Identify Interface Requirements Goals Practices Typical Work Products Derived Requirements Product Requirements Product-Component Requirements Requirement Allocation Sheets Provisional Requirement Allocations Design Constraints Interface Requirements Engineering (ML 3): RD (3 of 4)

100 Copyright 2004, Carnegie Mellon University. All rights reserved. 99 Develop Customer Requirements Develop Product Requirements Analyze and Validate Requirements Establish Operational Concepts and Scenarios Establish a Definition of Required Functionality Analyze Requirements Analyze Requirements to Achieve Balance Validate Requirements Validate Requirements With Comprehensive Methods Operational Concept Product Installation, Operational, Maintenance, and Support Concepts Disposal Concepts Functional Architecture Activity Diagrams and Use Cases Object-Oriented Analysis With Services Identified Requirements Defects Reports Proposed Requirements Changes to Resolve Defects Key Requirements Assessment of Risks Related to Requirements Results of Requirements Validation Record of Analysis Methods and Results Engineering (ML 3): RD (4 of 4) Goals Practices Typical Work Products Continuous Representation Only Requirements Development

101 Copyright 2004, Carnegie Mellon University. All rights reserved. 100 When Requirements Development isn’t done well… Symptoms: Unstated requirements, poorly stated requirements that lead to confusion among staff and customers Design, implementation, and test work products that inconsistently interpret the requirements Inordinately long time to get to agreement on product design Why Should You Care? Because… Unusable products and unhappy customers lead to loss of future business Wasted time and resources building product to requirements that customer may not want threatens your profitability Staff get tired of re-doing work because the requirements have been re-interpreted “yet again” The potential for excessive spending to meet customer expectations increases when you don’t identify requirements well

102 Copyright 2004, Carnegie Mellon University. All rights reserved. 101 Product or Product-Component Solutions are Selected From Alternative Solutions Technical Solution Product or Product-Component Designs are Developed Product Components, and Associated Support Documentation, are Implemented From Their Designs Purpose: Design, Develop, and Implement Solutions to Requirements. Solutions, Designs, and Implementations encompass Products, Product Components, and Product-related Lifecycle Processes Engineering (ML 3): TS (1 of 4)

103 Copyright 2004, Carnegie Mellon University. All rights reserved. 102 Select Product- Component Solutions Technical Solution Develop Alternative Solutions and Selection Criteria Develop the Design Implement the Product Design Select Product-component Solutions Evolve Operational Concepts and Scenarios Develop Detailed Alternative Solutions and Selection Criteria Alternative Solutions Selection Criteria Alternative Solution Screening Criteria Evaluations of New Technologies Alternative Solutions Product-Component Operational Concepts, Scenarios, and Environments for All Product-Related Life-Cycle Processes Timeline Analyses of Product-Component Interactions Use Cases Product-Component Selection Decisions and Rationale Documented Relationships Between Requirements and Product Components Documented Solutions, Evaluations, and Rationale Engineering (ML 3): TS (2 of 4) Goals Practices Typical Work Products Continuous Representation Only

104 Copyright 2004, Carnegie Mellon University. All rights reserved. 103 Select Product- Component Solutions Technical Solution Develop the Design Implement the Product Design Design the Product or Product Component Perform Make, Buy, or Reuse Analyses Design Interfaces Using Criteria Establish Interface Descriptions Establish a Technical Data Package Product Architecture Product-Component Designs Technical Data Package Interface Design Interface Design Documents Interface Design Specifications Interface Control Documents Interface Specification Criteria Criteria for Design and Product-Component Reuse Make-or-Buy Analyses Guidelines for Choosing COTS Product Components Engineering (ML 3): TS (3 of 4) Goals Practices Typical Work Products Continuous Representation Only

105 Copyright 2004, Carnegie Mellon University. All rights reserved. 104 Select Product- Component Solutions Develop the Design Implement the Product Design Implement the Design Develop Product Support Documentation Goals Practices Typical Work Products Implemented Design End-User Training Materials User’s Manual Operator’s Manual Engineering (ML 3): TS (4 of 4) Technical Solution

106 Copyright 2004, Carnegie Mellon University. All rights reserved. 105 When Technical Solution isn’t done well… Symptoms: Less than optimal solution is “settled on” Products that don’t meet technical performance requirements and/or user needs Increased testing/rework to resolve design/architecture issues Customer is surprised at the solution that resulted from their requirements Why Should You Care? Because… Increased cost to test and to address rework Future business is at risk with the customer if performance expectations aren’t met Product may not be able to accommodate technology upgrades and future growth if technical solution isn’t well conceived

107 Copyright 2004, Carnegie Mellon University. All rights reserved. 106 Preparation for Product Integration is Conducted Product Integration The Product-Component Interfaces, Both Internal and External, are Compatible Verified Product components are Assembled and the Integrated, Verified, and Validated Product is Delivered Purpose: Assemble the Product From the Product Components, Ensure That the Product, As Integrated, Functions Properly, and Deliver the Product. Engineering (ML 3): PI (1 of 4)

108 Copyright 2004, Carnegie Mellon University. All rights reserved. 107 Prepare for Product Integration Product Integration Determine Integration Sequence Ensure Interface Compatibility Assemble Product Components and Deliver the Product Establish Product Integration Procedures and Criteria Establish the Product Integration Environment Goals Practices Typical Work Products Product Integration Sequence Rationale for Selecting or Rejecting Integration Sequences Verified Environment for Product Integration Support Documentation for the Product Integration Environment Product Integration Procedures Product Integration Criteria Engineering (ML 3): PI (2 of 4)

109 Copyright 2004, Carnegie Mellon University. All rights reserved. 108 Prepare for Product Integration Product Integration Ensure Interface Compatibility Assemble Product Components and Deliver the Product Review Interface Descriptions for Completeness Manage Interfaces Goals Practices Typical Work Products Categories of Interfaces List of Interfaces Per Category Mapping of the Interfaces to the Product Components and Product Integration Environment Table of Relationships Among the Product Components and the External Environment Table of Relationships Between the Different Product Components List of Agreed-to Interfaces Defined for Each Pair of Product Components, When Applicable Engineering (ML 3): PI (3 of 4)

110 Copyright 2004, Carnegie Mellon University. All rights reserved. 109 Prepare for Product Integration Ensure Interface Compatibility Assemble Product Components and Deliver the Product Confirm Readiness of Product Components for Integration Package and Deliver the Product or Product Component Evaluate Assembled Product Components Assemble Product Components Goals Practices Typical Work Products Acceptance Documents for the Received Product Components Delivery Receipts Checked Packing Lists Assembled Product or Product Components Exception Reports Interface Evaluation Reports Product Integration Summary Reports Packaged Product or Product Components Delivery Documentation Engineering (ML 3): PI (4 of 4) Product Integration

111 Copyright 2004, Carnegie Mellon University. All rights reserved. 110 When Product Integration isn’t done well….. Symptoms: Subsystems don’t operate together Increased integration/test time Building test harnesses/procedures/etc late in the project Integration environment is inadequate to support the integration activities Why Should You Care? Because….. You can’t release the system until it operates as a unit You’ll spend more time in integration/test than you planned/can afford You can’t accurately estimate integration-related costs, reducing your customer’s confidence There’s nothing quite as embarrassing as installing a product that doesn’t integrate with the customer’s system

112 Copyright 2004, Carnegie Mellon University. All rights reserved. 111 Verification Versus Validation Verification Are you building the product right? That is, are you meeting the specified requirements? Validation Are you building the right product? That is, are you meeting the operational need?

113 Copyright 2004, Carnegie Mellon University. All rights reserved. 112 Preparation for Verification is Conducted Verification Peer Reviews are Performed on Selected Work Products Selected Work Products are Verified Against Their Specified Requirements Purpose: Ensure That Selected Work Products Meet Their Specified Requirements. Engineering (ML 3): VER (1 of 4)

114 Copyright 2004, Carnegie Mellon University. All rights reserved. 113 Prepare for Verification Verification Select Work Products for Verification Perform Peer Reviews Verify Selected Work Products Establish Verification Procedures and Criteria Establish the Verification Environment Goals Practices Typical Work Products Engineering (ML 3): VER (2 of 4) List of Work Products Selected for Verification Verification Methods for Each Selected Work Product Verification Environment Verification Procedures Verification Criteria

115 Copyright 2004, Carnegie Mellon University. All rights reserved. 114 Prepare for Verification Verification Perform Peer Reviews Verify Selected Work Products Prepare for Peer Reviews Analyze Peer Review Data Conduct Peer Reviews Goals Practices Typical Work Products Engineering (ML 3): VER (3 of 4) Peer Review Schedule Peer Review Checklist Entry and Exit Criteria for Work Products Peer Review Results Peer Review Issues Peer Review Data Peer Review Data Peer Review Action Items

116 Copyright 2004, Carnegie Mellon University. All rights reserved. 115 Prepare for Verification Verification Perform Peer Reviews Verify Selected Work Products Perform Verification Analyze Verification Results and Identify Corrective Action Goals Practices Typical Work Products Engineering (ML 3): VER (4 of 4) Verification Results Verification Reports Demonstrations Analysis Report (such as statistics on performances, causal analysis of nonconformances, comparison of the behavior between the real product and models, and trends) Trouble Reports Change Requests for the Verification Methods, Criteria, and Environment

117 Copyright 2004, Carnegie Mellon University. All rights reserved. 116 When Verification isn’t done well….. Symptoms: Disagreement among technical staff as to the “done-ness” of different components Product under test doesn’t meet requirements/design expectations Defects that could have been caught early escape into later life cycle phases Increased integration/test time Why Should You Care? Because….. Product reliability suffers if defects aren’t detected/ corrected prior to customer release Product costs more to test if early verification activities are ignored Customers don’t want to pay for defective products -You probably won’t get their business next time

118 Copyright 2004, Carnegie Mellon University. All rights reserved. 117 Preparation for Validation is Conducted Validation The Product or Product Components are Validated to Ensure That They are Suitable for Use in Their Intended Operating Environment Purpose: Demonstrate That a Product or Product Component Fulfills Its Intended Use When Placed in Its Intended Environment. Engineering (ML 3): VAL (1 of 3)

119 Copyright 2004, Carnegie Mellon University. All rights reserved. 118 Prepare for Validation Validation Select Products for Validation Validate Product or Product Components Establish Validation Procedures and Criteria Establish the Validation Environment Goals Practices Typical Work Products Engineering (ML 3): VAL (2 of 3) Lists of Products and Product Components Selected for Validation Validation Methods for Each product or Product Component Requirements for Performing Validation for Each Product or Product Component Validation Environment Validation Procedures Validation Criteria Test and Evaluation Procedures for Maintenance, Training, and Support

120 Copyright 2004, Carnegie Mellon University. All rights reserved. 119 Prepare for Validation Validation Validate Product or Product Components Perform Validation Analyze Validation Results Goals Practices Typical Work Products Engineering (ML 3): VAL (3 of 3) Validation Reports Validation Results Validation Cross-Reference Matrix Validation Deficiency Reports Validation Issues Procedure Change Request

121 Copyright 2004, Carnegie Mellon University. All rights reserved. 120 When Validation isn’t done well….. Symptoms: Lots of user change requests before/soon after the product is released Arguments among the technical staff as to what the user “really” wants Released product doesn’t meet user expectations Why Should You Care? Because….. Customers don’t want to pay for products that don’t meet their needs If an end user refuses to use the product as delivered, their confidence in you is eroded -You’ll spend a lot of money trying to “make it right” or you’ll give up that customer’s future business

122 Copyright 2004, Carnegie Mellon University. All rights reserved. 121 Strengths, Weaknesses, and Improvement Opportunities for the Organization’s Processes are Identified Periodically and as Needed Organizational Process Focus Improvements are Planned and Implemented, Organizational Process Assets are Deployed, and Process- Related Experiences are Incorporated Into the Organizational Process Assets Purpose: Plan and Implement Organizational Process Improvement Based on a Thorough Understanding of the Organizational Process Assets Process Management (ML 3): OPF (1 of 3)

123 Copyright 2004, Carnegie Mellon University. All rights reserved. 122 Organizational Process Focus Establish Organizational Process Needs Appraise the Organization’s Processes Identify the Organization’s Process Improvements Establish Process Action Plans Implement Process Action Plans Deploy Organizational Process Assets “OPD” Organization’s Process Assets Determine Process Improvement Opportunities Plan and implement process improvement

124 Copyright 2004, Carnegie Mellon University. All rights reserved. 123 Determine Process Improvement Opportunities Organizational Process Focus Establish Organizational Process Needs Plan and Implement Process Improvement Activities Appraise the Organization’s Processes Identify the Organization's Process Improvements Goals Practices Typical Work Products Process Management (ML 3): OPF (2 of 3) Organization’s Process Needs and Objectives Plans for the Organization’s Process Appraisals Appraisal Findings That Address Strengths and Weaknesses of the Organization’s Processes Improvement Recommendations for the Organization’s Processes Analysis of Candidate Process Improvements Identification of Improvements for the Organization’s Processes

125 Copyright 2004, Carnegie Mellon University. All rights reserved. 124 Determine Process Improvement Opportunities Organizational Process Focus Plan and Implement Process Improvement Activities Establish Process Action Plans Implement Process Action Plans Deploy Organizational Process Assets Incorporate Process-related Experiences Into the Organizational Process Assets Goals Practices Typical Work Products Process Management (ML 3): OPF (3 of 3) Organization’s Approved Process Action Plans Commitments Among the Various Process Action Teams Status and Results of Implementing Process Action Plans Plans for Pilots Plans for Deploying the Organizational Process Assets and Changes to Organizational Process Assets Training Materials for Deploying the Organizational Process Assets and Changes to Organizational Process Assets Documentation of Changes to the Organizational Process Assets Process Improvement Proposals Process Lessons Learned Measurements on the Organizational Process Assets

126 Copyright 2004, Carnegie Mellon University. All rights reserved. 125 When Organization Process Focus isn’t done well….. Symptoms: Lots of staff changes in the Engineering Process Group or equivalent Lack of visible senior management support for process improvement activities The things that are chosen for improvement are not aligned with business priorities False starts and rocky implementations of improvement efforts Why Should You Care? Because….. Each time the organization visibly fails at improvement, the harder it is to get support the next time Lack of alignment with business priorities means lots of overhead money gets wasted If the organization can’t effectively support improvement, employee pride in their work is eroded when they can’t meet customer expectations Employees will only tolerate so many “improvements” that don’t work before they look for another job

127 Copyright 2004, Carnegie Mellon University. All rights reserved. 126 Organizational Process Definition A Set of Organizational Process Assets is Established and Maintained Purpose: Establish and Maintain a Usable Set of Organizational Process Assets Process Management (ML 3): OPD (1 of 2)

128 Copyright 2004, Carnegie Mellon University. All rights reserved. 127 Organizational Process Definition Establish Organizational Process Assets Establish Standard Processes Establish Life-cycle Model Descriptions Establish Tailoring Criteria and Guidelines Establish the Organization’s Measurement Repository Establish the Organization’s Process Asset Library Goals Practices Typical Work Products Process Management (ML 3): OPD (2 of 2) Organization’s Set of Standard Processes Descriptions of Life-Cycle Models Tailoring Guidelines for the Organization’s Set of Standard Processes Definition of the Common Set of Product and Process Measures for the Organization’s Set of Standard Processes Design of the Organization’s Measurement Repository Organization’s Measurement Repository (i.e., the repository structure and support environment) Design of the Organization’s Process Asset Library Organization’s Process Asset Library Selected Items to be Included in the Organization’s Process Asset Library

129 Copyright 2004, Carnegie Mellon University. All rights reserved. 128 When Organization Process Definition isn’t done well….. Symptoms: Staff resist using the guidance in the standard processes that have been defined “Mother of all process manuals” sits on the real (or virtual!) shelf Lots of time being spent getting process waivers Extreme amount of tailoring requested by each project Why Should You Care? Because….. Since defining processes is an overhead task, defining processes that can’t be used/cause lots of work to “get around” is a direct waste of profit Using processes that are ineffective can cause many of the other symptoms we’ve discussed Staff who lack confidence in the organization’s ability to provide useful guidance will probably look elsewhere for jobs Lots of tailoring leads to less and less reuse of process knowledge and skills, thus reducing your ROI in process definition activities

130 Copyright 2004, Carnegie Mellon University. All rights reserved. 129 A Training Capability That Supports the Organization’s Management and Technical Roles is Established and Maintained Organizational Training Training Necessary for Individuals to Perform Their Roles Effectively is Provided Purpose: Develop the Skills and Knowledge of People So They Can Perform Their Roles Effectively and Efficiently Process Management (ML 3): OT (1 of 3)

131 Copyright 2004, Carnegie Mellon University. All rights reserved. 130 Establish an Organizational Training Capability Organizational Training Establish the Strategic Training Needs Provide Necessary Training Determine Which Training Needs Are the Responsibility of the Organization Establish an Organizational Training Tactical Plan Establish Training Capability Goals Practices Typical Work Products Process Management (ML 3): OT (2 of 3) Training Needs Assessment Analysis Common Project and Support Group Training Needs Training Commitments Organizational Training Tactical Plan Training Materials and Supporting Artifacts

132 Copyright 2004, Carnegie Mellon University. All rights reserved. 131 Establish an Organizational Training Capability Organizational Training Provide Necessary Training Deliver Training Establish Training Records Assess Training Effectiveness Goals Practices Typical Work Products Process Management (ML 3): OT (3 of 3) Delivered Training Course Training Records Training Updates to the Organizational Repository Training-Effectiveness Surveys Training Program Performance Assessments Instructor Evaluation Forms

133 Copyright 2004, Carnegie Mellon University. All rights reserved. 132 When Organizational Training isn’t done well….. Symptoms: Staff attending training courses they don’t need Staff avoiding training that is provided Inappropriately-skilled staff being assigned to tasks, often without knowledge of the deficiency Staff aren’t released to attend training they do need Why Should You Care? Because….. You compromise your competitive edge if staff are not appropriately skilled for the tasks you’re competing for Staff who get frustrated at not getting the training they need may look elsewhere for a job Customer confidence is eroded when they find out that inappropriately-skilled staff are assigned to their project The productivity difference between highly skilled/unskilled staff (at least in software) is documented at 27:1 1 1 Capers Jones, Software Quality & Productivity


Download ppt "Pittsburgh, PA 15213-3890 Copyright 2004, Carnegie Mellon University. All rights reserved. CMMI FOR SMALL BUSINESS PILOT – ASI KICKOFF MEETING SuZ Garcia,"

Similar presentations


Ads by Google