drug florida in rehab

........................................................................................................................................................................................................................................................................................................................................................................................ Dr. Ralf Kneuper, 11.03.2005 Capability Maturity Model Integration (CMMI) Introduction and Overview Dr. Ralf Kneuper Beratung für Softwarequalitätsmanagement und Prozessverbesserung 1 Dr. Ralf Kneuper, 11.03.2005 Ralf Kneuper – Dipl.-Mathematiker, Univ. of Bonn – PhD Computing Science, Univ. of Manchester – 1989-1995: Software AG • Quality assurance, quality management, ISO 9000 – 1995-2005: Deutsche Bahn/TLC/DB Systems • Senior consultant, project lead • Quality management, internal CMM(I) consultant, development processes, project management – Since 2003: Independent consultant on CMMI – Speaker of GI SIG on software processes – SEI-Authorized CMM Lead Assessor, CMMI Lead Appraiser – Coordinator of the German CMM(I) Lead Appraiser and Instructor Board (CLIB) • Contact: ralf@kneuper.de 2 Dr. Ralf Kneuper, 11.03.2005 Where do I find out more about CMMI? Original CMMI documentation • Capability Maturity Model Integration (CMMI), CMMI for Systems Engineering and Software Engineering (CMMI-SE/SW, V1.1) Continuous Representation CMU/SEI-2002-TR-001 • Capability Maturity Model Integration (CMMI), CMMI for Systems Engineering and Software Engineering (CMMI-SE/SW, V1.1) Staged Representation CMU/SEI-2002-TR-002 – both available at http://www.sei.cmu.edu/cmmi • Mary Beth Chrissis, Mike Konrad, Sandy Shrum: CMMI. Guidelines for Process Integration and Product Improvement. 663 S., SEI Series in Software Engineering, Addison-Wesley, Boston, 2003 Further reading • Ahern, Clouse, Turner: CMMI Distilled. A Practical Introduction to Integrated Process Improvement. 2nd ed, Addison-Wesley, 2003 • Kneuper: CMMI. Verbesserung von Softwareprozessen mit Capability Maturity Model Integration. 2nd edition, dpunkt.verlag, January 2006 (http://www.dpunkt.de/cmmi/) • see also http://www.kneuper.de/cmmi/cmmi-lit.htm 3 Dr. Ralf Kneuper, 11.03.2005 Underlying Premise of Process Improvement "The quality of a product is largely determined by the quality of the process that is used to develop and maintain it." Based on TQM principles as taught by Shewhart, Juran, Deming and Humphrey. 4 Dr. Ralf Kneuper, 11.03.2005 Why do we want software process improvement (CMM, CMMI, ...)? • What does the customer want? – High-quality results that satisfy the requirements and are completed in time and in budget • What does the management want? – High customer satisfaction – High productivity – Control over projects • What do the developers want? – Do their job in peace Software Process Improvement (SPI) supports achieving these goals! 5 Dr. Ralf Kneuper, 11.03.2005 Versions of CMM(I) Software process maturity framework 1987 Capability Maturity Model Version 1.0 1991 Capability Maturity Model Version 1.1 1993 Draft of Capability Maturity Model Version 2.0 1998 Capability Maturity Model Inte 2000 Capability Maturity Model Inte 6 gration Version 1.0 gration Version 1.1 Withdrawn in order to restructure the model Emphasis in Assessments on Maturity Questionnaire Planned: CMMI 1.2 2002 2006 Dr. Ralf Kneuper, 11.03.2005 Capability Maturity Model Integration (CMMI) Project • Project started in 1997 • CMMI-SE/SW Version 1.0 released in August 2000 • CMMI-SE/SW Version 1.1 released in January 2002 – „staged" and „continuous" representation – one common document covering Systems and Software Engineering – some additional requirements compared to SW-CMM 1.1 – in some cases requirements are stated more explicitly • mainly requirements that were obviously meant but not stated explicitly – SPICE (ISO 15504) - conformant – More structure, higher abstraction level • "Sunset period" until end of 2003 • Revised assessment method („SCAMPI" instead of „CBA-IPI") 7 Dr. Ralf Kneuper, 11.03.2005 The five maturity levels of CMMI continuous process improvement 4. Quant. Managed Process measured and controlled predictable process Managing change standardised consistent process 3. Defined Process documented, well understood Product and process quality 8 1. Initial Unpredictable, little control 2. Managed Can repeat earlier successes Comprehensive development process Controlled process Project management Process improvement 5. Optimizing Increased productivity and quality Reduced risk Dr. Ralf Kneuper, 11.03.2005 Structure of CMMI Staged Representation Maturity Levels Process Area 1 Process Area 2 Process Area n Specific Goals Generic Goals Commitment to Perform Verifying Implementation Directing Implementation Ability to Perform Common Features Specific Practices Generic Practices Common features will be removed in CMMI v1.2 since they are no longer relevant Dr. Ralf Kneuper, 11.03.2005 Variants of CMMI Representation / Application area System engineering (SE) X X Software engineering (SW) X X Integrated product and process development (IPPD) X X Supplier Sourcing (SS) X X CMMI-SE/SW Staged Representation CMMI-SE/SW Continuous Representation 10 Dr. Ralf Kneuper, 11.03.2005 Levels • Maturity Level (Staged representation) – Maturity levels apply to the totality of all process areas – Maturity levels range from 1 (no requirements) to 5 • Capability Level (Continuous representation) – Capability levels apply to one process area – Capability levels range from 0 (no requirements) to 5 11 Dr. Ralf Kneuper, 11.03.2005 CMMI Maturity Levels vs. Capability Levels 1 Initial 2 Managed 3 Defined 4 Quantitatively managed 5 Optimizing Processe are characterized by the project Processes are defined by the organization Processes are measured and controlled Processe are ad-hoc Focus on process improvement Maturity Levels 5 Optimizing 3 Defined 2 Managed 1 Performed) 0 Incomplete 4 Quantitatively managed Capability Levels 12 Dr. Ralf Kneuper, 11.03.2005 Generic Goal Level 1 • Achieve Specific Goals (GG 1) – Perform Base Practices (GP 1.1) 13 Dr. Ralf Kneuper, 11.03.2005 Generic Goal Level 2 Managed Process • Institutionalize a Managed Process (GG 2) – Establish an Organizational Policy (GP 2.1) – Plan the Process (GP 2.2) – Provide Resources (GP 2.3) – Assign Responsibility (GP 2.4) – Train People (GP 2.5) – Manage Configurations (GP 2.6) – Identify and Involve Relevant Stakeholders (GP 2.7) – Monitor and Control the Process (GP 2.8) – Objectively Evaluate Adherence (GP 2.9) – Review Status with Higher Level Management (GP 2.10) Careful: in CMM, „managed" referred to level 4 14 Dr. Ralf Kneuper, 11.03.2005 Generic Goal Level 3 Defined Process • Institutionalize a Defined Process (GG 3) – Establish a Defined Process (GP 3.1) – Collect Improvement Information (GP 3.2) 15 Dr. Ralf Kneuper, 11.03.2005 Generic Goal Level 4 / 5 Quantitatively Managed Process / Optimizing Process • Institutionalize a Quantitatively Managed Process (GG 4) – Establish Quantitative Objectives for the Process (GP 4.1) – Stabilize Subprocess Performance (GP 4.2) • Institutionalize an Optimizing Process (GG 5) – Ensure Continuous Process Improvement (GP 5.1) – Correct Root Causes of Problems (GP 5.2) • GG 4 and GG 5 are only contained in the continuous representation 16 Dr. Ralf Kneuper, 11.03.2005 Agenda • Introduction • History and Motivation • Structure of CMMI • Generic Goals – Overview • Maturity Level 2 and 3 Process Areas • Generic Goals – Revisited • CMMI Appraisals • Introducing CMMI into an Organization • CMMI and ISO 15504 (SPICE) 17 Dr. Ralf Kneuper, 11.03.2005 CMMI (CMMI-SE/SW V. 1.1) Process Areas by Category and Maturity Level Process Mgmt. Project Management Engineering Support 2 3 4 5 Configuration Management (CM) Process & Product Quality Assurance (PPQA) Measurement and Analysis (MA) Decision Analysis and Resolution (DAR) Causal Analysis and Resolution (CAR) Project Planning (PP) Project Monitoring and Control (PMC) Supplier Agreement Management (SAM) Integrated Project Management (IPM) Risk Management (RSKM) Quantitative Project Management (QPM) Requirements Development (RD) Technical Solution (TS) Product Integration (PI) Verification (VER) Validation (VAL) Requirements Management (REQM) Organizational Process Performance (OPP) Organizational Innovation and Deployment (OID) Organizational Process Focus (OPF) Organizational Process Definition (OPD) Organizational Training (OT) 18 Dr. Ralf Kneuper, 11.03.2005 Engineering process areas Requirements Management The purpose of Requirements Management is to manage the requirements of the project's products and product components and to identify inconsistencies between those requirements and the project's plans and work products. 19 Dr. Ralf Kneuper, 11.03.2005 Requirements Management SP 1.1 Obtain an Understanding of Requirements SP 1.2 Obtain Commitment to Requirements SP 1.3 Manage Requirements Changes SG 1 Manage Requirements SP 1.4 Maintain Bidirectional Traceability of Requirements SP 1.5 Identify Inconsistencies between Project Work and Requirements Requirements documentation1 Requirements traceablity matrix 1 Typical tools: • requirements list • requirements database • ... 20 Dr. Ralf Kneuper, 11.03.2005 Project Planning SP 3.1 Review Plans that Affect the Project SP 3.2 Reconcile Work and Resource Levels SP 3.3 Obtain Plan Commitment SG 3 Obtain Commitment to the Plan SP 1.1 Estimate the scope of the project SP 1.2 Establish Estimates of Work Product and Task Attributes SG 1 Establish Estimates SP 1.4 Determine Estimates of Effort and Cost SP 1.3 Define Project Life Cycle Planning data (effort, cost,...) Project plan SP 2.1 Establish the Budget and Schedule SP 2.2 Identify Project Risks SP 2.3 Plan for Data Management SP 2.4 Plan for Project Resources SG 2 Develop a Project Plan SP 2.6 Plan Stakeholder Involvement SP 2.5 Plan for Needed Knowledge and Skills SP 2.7 Establish the Project Plan 21 Dr. Ralf Kneuper, 11.03.2005 Project Monitoring and Control SP 1.1 Monitor Project Planning Parameters SP 1.2 Monitor Commitments SP 1.3 Monitor Project Risks SP 1.4 Monitor Data Management SG 1 Monitor Project Against Plan SP 1.5 Monitor Stakeholder Involvement SP 1.7 Conduct Milestone Reviews SP 1.6 Conduct Progress Reviews Project plan Status report PP SP 2.1 Analyze Issues SP 2.2 Take Corrective Action SG 2 Manage Corrective Action to Closure SP 2.3 Manage Corrective Action Open issues list, corrective measures 22 Dr. Ralf Kneuper, 11.03.2005 Supplier Agreement Management SP 1.1 Determine Acquisition Type SP 1.2 Select Suppliers SP1.3 Establish Supplier Agreements SG 1 Establish Supplier Agreements SP 2.2 Execute Supplier Agreement SP 2.4 Transition Product SP 2.3 Accept the Acquired Product SP 2.1 Review COTS1 Products SG 2 Satisfy Supplier Agreements 1 COTS = commercial off-the-shelf, Supplier Agreement (Contract) Work Product Supplier reqs. (acquisition type, supplier list, selection criteria, etc.) Transition plan Acceptance test (Procedure, result) Evaluation criteria Supplier status (progress, reviews, etc.) 23 Dr. Ralf Kneuper, 11.03.2005 Measurement and Analysis SP 2.1 Collect Measurement Data SP 2.2 Analyze Measurement Data SP 2.3 Store Data and Results SP 2.4 Communicate Results SG 2 Provide Measurement Results SP 1.1 Establish Measurement Objectives SP 1.2 Specify Measures SP1.3 Specify Data Collection and Storage Procedures SG 1 Align Measurement and Analysis Activities SP1.4 Specify Analysis Procedures Measurement Objectives Metric Repository Procedures & Tools (for collection and analysis) Analysis, interpretation of measurement data and reports Relevant stakeholder (data supplier or analyst, etc.) 24 Dr. Ralf Kneuper, 11.03.2005 Process and product quality assurance SP 1.1 Objectively Evaluate Processes SP 1.2 Objectively Evaluate Work Products and Services SG 1 Objectively Evaluate Processes and Work Products SP 2.1 Communicate and Ensure Resolution of Noncompliance Issues SP 2.2 Establish Records SG 2 Provide Objective Insight Review minutes (deviations) QA reporting (trends, etc.) QA review data base Processes & work products 25 Dr. Ralf Kneuper, 11.03.2005 Engineering process areas Requirements Development The purpose of Requirements Development is to produce and analyze customer, product, and product-component requirements. 26 Dr. Ralf Kneuper, 11.03.2005 Engineering process areas Technical Solution The purpose of Technical Solution is to design, develop, and implement solutions Solutions, designs, and implementations encompass products, product components, and product-related lifecycle processes either singly or in combinations as appropriate. to requirements. 27 Dr. Ralf Kneuper, 11.03.2005 Engineering process areas Product integration The purpose of Product Integration is to assemble the product from the product components, ensure that the product, as integrated, functions properly, and deliver the product. 28 Dr. Ralf Kneuper, 11.03.2005 Engineering process areas Verification The purpose of Verification is to ensure that selected work products meet their specified requirements. 29 Dr. Ralf Kneuper, 11.03.2005 Engineering process areas Validation The purpose of Validation is to demonstrate that a product or product component fulfills its intended use when placed in its intended environment. 30 Dr. Ralf Kneuper, 11.03.2005 Verification vs. Validation • Verification – „Do things right" – do what was specified previously • Validation – „Do the right thing" – do what the customer really needs Dr. Ralf Kneuper, 11.03.2005 Process Management Process Areas Organizational Process Focus The purpose of Organizational Process Focus is to plan and implement organizational process improvement based on a thorough understanding of the current strengths and weaknesses of the organization's processes and process assets. Dr. Ralf Kneuper, 11.03.2005 Process Management Process Areas Organizational Process Definition The purpose of Organizational Process Definition is maintain a usable set of organizational process to establish and assets. Dr. Ralf Kneuper, 11.03.2005 Process Management Process Areas Organizational Training The purpose of Organizational Training is to develop the skills and knowledge of people so they can perform their roles effectively and efficiently. Dr. Ralf Kneuper, 11.03.2005 Project management process areas Integrated Project Management • The purpose of Integrated Project Management is to 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. – SG 1 Use the Project's Defined Process • Establish the Project's Defined Process • Use Organizational Process Assets for Planning Project Activities • Integrate Plans • Manage the Project Using the Integrated Plans • Contribute to the Organizational Process Assets – SG 2 Coordinate and Collaborate with Relevant Stakeholders • Manage Stakeholder Involvement • Manage Dependencies • Resolve Coordination Issues 35 Dr. Ralf Kneuper, 11.03.2005 Project management process areas Risk Management • The purpose of Risk Management is to 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. – SG 1 Prepare for Risk Management • Determine Risk Sources and Categories • Define Risk Parameters • Establish a Risk Management Strategy – SG 2 Identify and Analyze Risks • Identify Risks • Evaluate, Categorize, and Prioritize Risks – SG 3 Mitigate Risks • Develop Risk Mitigation Plans • Implement Risk Mitigation Plans 36 Dr. Ralf Kneuper, 11.03.2005 Support process areas Decision Analysis and Resolution • The purpose of Decision Analysis and Resolution is to analyze possible decisions using a formal evaluation process that evaluates identified alternatives against established criteria. – SG 1 Evaluate Alternatives • Establish Guidelines for Decision Analysis • Establish Evaluation Criteria • Identify Alternative Solutions • Select Evaluation Methods • Evaluate Alternatives • Select Solutions 37 Dr. Ralf Kneuper, 11.03.2005 Additional Process Areas for Other Disciplines (all Maturity Level 3) • CMMI-SE/SW/IPPD – Integrated Teaming (IT) – Organizational Environment for Integration (OEI) – Integrated Project Management for IPPD (IPM) • Two additional goals • CMMI-SE/SW/IPPD/SS – Integrated Supplier Management (ISM) 38 Dr. Ralf Kneuper, 11.03.2005 Rough timeline for a SCAMPI Appraisals decision to have assessment, select lead assessor 1 - 2 months create appraisal input Readiness Review prepare appraisal plan 1 - 2 months 1 - 2 months 39 Dr. Ralf Kneuper, 11.03.2005 Rough timeline for a SCAMPI Appraisals decision to have assessment, select lead assessor 1 - 2 months create appraisal input 1 - 2 months Readiness Review prepare appraisal plan Assessment on-site 1 - 2 months 40 Dr. Ralf Kneuper, 11.03.2005 Appraisal process On-site Kickoff presentation Document review (complete) Interviews Consolidation and evaluation Presentation of preliminary results Final presentation of results Complete consolidation, evaluation 41 Dr. Ralf Kneuper, 11.03.2005 Appraisal Requirements for CMMI (ARC) Class A Class B Class C high medium low Effort high (>100 days) medium low Frequency low (< 1/year) medium high Data Sources 3 2 1 Rating yes no no Standard Method SCAMPI Reliability and correctness of results none (SCAMPI B planned) none (SCAMPI C planned) 42

posted by Fitzgerald Randolph at 4:45 PM

0 Comments:

Post a Comment

<< Home