We think you have liked this presentation. If you wish to download it, please recommend it to your friends in any social system. Share buttons are a little bit lower. Thank you!
Presentation is loading. Please wait.
Published byRyan Coyle
Modified over 3 years ago
© 2010 Carnegie Mellon University Mike Phillips Software Engineering Institute Carnegie Mellon University Excerpted by Pat Wegerson for North Star INCOSE 17 February 2011 ® CMMI is registered in the U.S. Patent and Trademark Office by Carnegie Mellon University. CMMI ® Version 1.3 and Beyond November 2010
2 CMMI V1.3 and Beyond Phillips – November 2010 © 2010 Carnegie Mellon University Organizations Are Complex Systems Strategic Technological Structural Human/ Cultural Managerial Organizational System Input-output flow of materials, energy, information Inputs Human, Financial, Technological, Material, Resources Outputs Products, Services Adapted from Kast and Rosenzweig, 1972.
3 CMMI V1.3 and Beyond Phillips – November 2010 © 2010 Carnegie Mellon University What Is a Process? A process is a set of interrelated activities, which transform inputs into outputs, to achieve a given purpose. Result Process Improvement flows from and extends the general management theories developed over the past ~30 years (Juran, Deming, Crosby, etc.)
4 CMMI V1.3 and Beyond Phillips – November 2010 © 2010 Carnegie Mellon University How Do You Want to Work? Random motion – lots of energy, not much progress No teamwork – individual effort Frequent conflict You never know where youll end up Directed motion – every step brings you closer to the goal Coordinated efforts Cooperation Predictable results Processes can make the difference!
5 CMMI V1.3 and Beyond Phillips – November 2010 © 2010 Carnegie Mellon University Symptoms of Process Failure Quality Problems Too much rework No product documentation Functions that dont work correctly Customer complaints after delivery Delivery of embarrassing products Wide variation in how people perform identical tasks Work with wrong versions of work products No View to the Future No concern for process improvement No feedback on process effectiveness Program cancellation
6 CMMI V1.3 and Beyond Phillips – November 2010 © 2010 Carnegie Mellon University Workforce Challenges Generation Workforce (Millions) % WorkforceWorkforce% WorkforceWorkforce% Workforce Traditionalists (Born before 1946) 11.57.5%45,6256.7%8,3227.4% Baby Boomers (1946 - 1964) 61.542.0%438,97164.5%77,77968.7% Generation X (1965-1976) 43.529.5%132,94819.5%17,58115.5% Generation Y (1977 -1989) 31.521.0%62,6769.2%9,3948.3% Millennium (1990 - present) 51.00%1530%0 National (2005) DoD (2006) Civilian AT&L Workforce (2006) Source: Anderson 2007, NDIA STEM Initiative Strategy Session DoD faces significant challenges related to mitigating the pending departure of its highly experienced and seasoned talent – the critical challenge Frank Anderson, Jr., Director, AT&L Human Capital Initiatives and President, Defense Acquisition University 2007
7 CMMI V1.3 and Beyond Phillips – November 2010 © 2010 Carnegie Mellon University Characteristics of Effective Processes trackable measurable simple Well-defined gates documented trained supported enforced practiced
8 CMMI V1.3 and Beyond Phillips – November 2010 © 2010 Carnegie Mellon University Process Definition Inputs Strategic Plans, Goals, Objectives Policies Process Descriptions, Procedures, Instructions Asset Library Measurement Repository Process Architecture Process Scope Process Needs
9 CMMI V1.3 and Beyond Phillips – November 2010 © 2010 Carnegie Mellon University Signs that Processes Are Insufficient Unmet commitments Late delivery Last minute crunches Spiraling costs Little or no management visibility Youre always being surprised Quality problems Too much rework Functions do not work correctly Customer dissatisfaction post-delivery; continuing high costs Poor morale Frustration Is anyone in charge? Mars Orbiter (Sep 1999) A 125 million dollar orbiter was lost because one team used English units of measure while another used metric units of measure.
10 CMMI V1.3 and Beyond Phillips – November 2010 © 2010 Carnegie Mellon University Process Improvement Whether intentional or not, you already have processes in place. Are they the RIGHT processes? Something is wrong… … if no one uses the processes (except under duress) … if everyone has their own interpretation of the process … if you find you are always tailoring your processes
11 CMMI V1.3 and Beyond Phillips – November 2010 © 2010 Carnegie Mellon University SEIs IDEAL SM Approach
12 CMMI V1.3 and Beyond Phillips – November 2010 © 2010 Carnegie Mellon University Common Misconceptions I dont need process, I have … Really good people Advanced technology An experienced manager Process… Interferes with creativity = bureaucracy + regimentation Is only useful on large projects Hinders agility in fast-moving markets Costs too much
13 CMMI V1.3 and Beyond Phillips – November 2010 © 2010 Carnegie Mellon University Threats to Process Improvement Senior management problems Change or loss of sponsorship Inadequate support and resources Desire for quick fixes Unreasonable expectations Termination before institutionalization Inconsistent reinforcement Middle management resistance If it aint broke dont fix it Flavor of the day This is another management initiative I can outlast Understand resistance before trying to eliminate it. It may be justified! Understand resistance before trying to eliminate it. It may be justified!
14 CMMI V1.3 and Beyond Phillips – November 2010 © 2010 Carnegie Mellon University How Can Process Help? Process supports the goals of the company, enabling Repeatability Insight and oversight Control and tracking Measurement Improvement Training Transformation (via consistency, integration, coordination) Interchangeable parts
15 CMMI V1.3 and Beyond Phillips – November 2010 © 2010 Carnegie Mellon University Error Correction Costs By Phase $$$ Value of Fixing Defects Early Relative Cost to Correct Error Operation Detailed Design Integration Validation Implementation TIME
16 CMMI V1.3 and Beyond Phillips – November 2010 © 2010 Carnegie Mellon University Early Defects Detection Level 5 Level 4 Level 3 Level 2 Level 1 5%20%40%20%10%<5%$800 Require- ments DesignCode Software Test System Test Field Use 3%12%30% 20%5%$1,000 0%2%20%38%32%8%$1,400 0% 3%30%50%17%$2,500 0% 2%15%50%33%$4,000 Relative Cost Source: SEPG Asia Pacific 2009 presented by Ravindra Nath, KUGLER MAAG CIE GmbH
17 CMMI V1.3 and Beyond Phillips – November 2010 © 2010 Carnegie Mellon University Late Discovery of System-Level Problems 5x Software Architectural Design System Design Component Software Design Code Development Unit Test System Test Integration Test Acceptance Test Requirements Engineering 110x Where faults are introduced Where faults are found The estimated nominal cost for fault removal 20.5% 1x 20%, 16% 10%, 50.5% 0%, 9% 40x 70%, 3.5% 16x Sources: NIST Planning report 02-3, The Economic Impacts of Inadequate Infrastructure for Software Testing, May 2002. D. Galin, Software Quality Assurance: From Theory to Implementation, Pearson/Addison-Wesley (2004) B.W. Boehm, Software Engineering Economics, Prentice Hall (1981)
18 CMMI V1.3 and Beyond Phillips – November 2010 © 2010 Carnegie Mellon University An Investment Is Required Desired State Transition State Present State T i m e ProductivityProductivity
19 CMMI V1.3 and Beyond Phillips – November 2010 © 2010 Carnegie Mellon University Commitment to improve must start at the top. First understand the current process. Structured change must become a way of life. Improvement requires investment. When failure occurs, focus on the process, not the people. Institutionalizing improvements requires vigilance and periodic reinforcement. SUCCESS STATUS QUO FAILURE Critical Success Factors for Process Improvement
© 2010 Carnegie Mellon University What Is CMMI?
21 CMMI V1.3 and Beyond Phillips – November 2010 © 2010 Carnegie Mellon University M Is for Model Models are simplified views of the real world. CMMI THE REAL WORLD Process descriptions, models, and instantiations are below the level of detail of the CMMs. Systems Engineering Marketing Integrated product teams Technology Organizational culture People issues Maturity Levels Process Areas Practices Process Descriptions All models are wrong, but some are useful. - George Box
22 CMMI V1.3 and Beyond Phillips – November 2010 © 2010 Carnegie Mellon University CMMI in a Nutshell CMMI is a collection of characteristics of effective processes that provides guidance for improving an organizations processes and ability to manage the development, acquisition, and maintenance of products or services. CMMI places proven approaches into a structure that helps an organization examine the effectiveness of its processes establishes priorities for improvement helps implement these improvements Improving processes for better products
23 CMMI V1.3 and Beyond Phillips – November 2010 © 2010 Carnegie Mellon University CMMI Product Suite CMMI Models o CMMI for Development o CMMI for Acquisition o CMMI for Services SCAMPI SM (Standard CMMI Appraisal Method for Process Improvement) o Class A (results in ratings) o Class B (deployment) o Class C (approach) Training o Introduction to CMMI o Advanced training courses Training Models SCAMPI
24 CMMI V1.3 and Beyond Phillips – November 2010 © 2010 Carnegie Mellon University CMMI Framework Training Understanding CMMI High Maturity Practices CMMI-Based Process Improvement Overview Implementing CMMI for High Performance, an Executive Seminar Introduction to CMMI (for Development) Introduction to CMMI for Services Acquisition Supplement for CMMI Services Supplement for CMMI CMMI Level 2 for Practitioners (DEV only) CMMI Level 3 for Practitioners (DEV only) CMMI Level 2 for Practitioners (ACQ only) CMMI Instructor Training CMMI Upgrade Training Intermediate Concepts of CMMI SCAMPI Lead Appraiser SM Training CMMI Model Foundation Development Acquisition Services Models Appraisals SCAMPI Class A Appraisal Method (Results in Ratings) SCAMPI Class B Appraisal Method SCAMPI Class C Appraisal Method Appraisal Requirements for CMMI
25 CMMI V1.3 and Beyond Phillips – November 2010 © 2010 Carnegie Mellon University Five Reasons to Adopt CMMI CMMI helps your organization to … Improve delivery of performance, cost, and schedule Collaborate with external stakeholders and integrate their expectations into day-to-day 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
26 CMMI V1.3 and Beyond Phillips – November 2010 © 2010 Carnegie Mellon University Evolution of Process Capability Process is informal and unpredictable Project management system is in place; performance is repeatable Software engineering and management processes are defined and integrated Product and process are quantitatively controlled Process improvement is institutionalized LevelProcess Characteristics Time/$/... Predicted Performance 1 2 3 4 5
27 CMMI V1.3 and Beyond Phillips – November 2010 © 2010 Carnegie Mellon University Example Chart from CMMI Level 5 Company: Multi-Performance Results Summary We all do! MeasurePerformance Result CostFirm fixed price upon acceptance of requirements specifications ScheduleNot to exceed 8% of committed schedule Weekly status reporting with ability to detect one-day schedule slip Time in test and agility with rework time significantly less than customer historical average QualityAcceptance test defects significantly lower than customer historical average Company will fix defects found in production use free for life of the product
28 CMMI V1.3 and Beyond Phillips – November 2010 © 2010 Carnegie Mellon University Example Chart from CMMI Level 5 Company: Their Results vs. Industry Average We all do! MeasurePerformance Result (Industry vs. ML5 Company) Schedule deviation >50% <10% Number of defects in delivered product (Size: 100,000 source lines of code) >100 <15 % of design and code inspected<100 100 Time to accept 100,000 SLOC product10 months 5 weeks % of defects removed prior to system test 85% % of development time fixing system test defects>33% <10% Cost of Quality>50% <35% Warranty on products? Lifetime
29 CMMI V1.3 and Beyond Phillips – November 2010 © 2010 Carnegie Mellon University CMMI Models
30 CMMI V1.3 and Beyond Phillips – November 2010 © 2010 Carnegie Mellon University Sequence of Models 41
31 CMMI V1.3 and Beyond Phillips – November 2010 © 2010 Carnegie Mellon University CMMI Models for Three Constellations 16 Core Process Areas, common to all CMMI-DEV CMMI-DEV provides guidance for measuring, monitoring and managing development processes. CMMI-SVC CMMI-SVC provides guidance for those providing services within organizations and to external customers. CMMI-ACQ CMMI-ACQ provides guidance to enable informed and decisive acquisition leadership.
32 CMMI V1.3 and Beyond Phillips – November 2010 © 2010 Carnegie Mellon University CMMI Core PAs CMMI Core PAs CMMI-DEV CMMI-ACQ CMMI-SVC Core PAs are common to all three CMMI models. Core PAs include informative material that interprets the goals and practices for the models area of interest.
33 CMMI V1.3 and Beyond Phillips – November 2010 © 2010 Carnegie Mellon University Process Area Components Related Process Areas Introductory Notes Example Work Products Example Work Products Subpractices Expected Informative Specific Goals (SG) Generic Goals (GG) Required Purpose Statement Specific Practices (SP) Generic Practices (GP) Generic Practice Elaborations Legend Process Area (PA) Subpractices
34 CMMI V1.3 and Beyond Phillips – November 2010 © 2010 Carnegie Mellon University CMMI Model Structure Institutionalization Policies Plans Resources Responsibilities Training Managing Configurations Stakeholder Involvement Monitoring and Control Objective Evaluation Management Visibility Defined Process Improvement Information CMMI Model Foundation (Core Process Areas) Requirements Management Project Planning Project Monitoring & Control Measurement & Analysis Configuration Management Process and Product QA Integrated Project Management Risk Management Decision Analysis & Resolution Organizational Process Focus Organizational Process Definition Organizational Training Causal Analysis & Resolution Org Process Performance Org Performance Management Quantitative Project Mgmt Requirements Development Supplier Agreement Mgmt Technical Solution Product Integration Verification Validation CMMI-DEV Capacity & Availability Management Incident Resolution and Prevention Supplier Agreement Mgmt Service Continuity Service Delivery Service System Development Service System Transition Strategic Service Mgmt CMMI-SVCCMMI-ACQ Agreement Management Acquisition Requirements Development Acquisition Technical Mgt Acquisition Validation Acquisition Verification Solicitation and Supplier Agreement Development Benchmark Ratings Goals Process Areas Maturity Levels Capability Levels Incremental Frameworks for Continuous Process Improvement
35 CMMI V1.3 and Beyond Phillips – November 2010 © 2010 Carnegie Mellon University Critical Distinctions Among Processes performedvs.managed the extent to which the process is planned; performance is managed against the plan; corrective actions are taken when needed managedvs.defined the scope of application of the process descriptions, standards, and procedures (i.e., project vs. organization)
36 CMMI V1.3 and Beyond Phillips – November 2010 © 2010 Carnegie Mellon University Understanding Levels Levels are used in CMMI to describe an evolutionary path for an organization that wants to improve the processes it uses to develop and maintain its products and services. CMMI supports two improvement paths: continuous - enabling an organization to incrementally improve processes corresponding to an individual process area (or set of process areas) selected by the organization staged - enabling the organization to improve a set of related processes by incrementally addressing successive predefined sets of process areas
37 CMMI V1.3 and Beyond Phillips – November 2010 © 2010 Carnegie Mellon University Staged Representation: PAs by Maturity Level 5 Optimizing 4 Quantitatively Managed 3 Defined 2 Managed Continuous Process Improvement Quantitative Management Process Standardization Basic Project Management Risk Rework 1 Initial Level Focus Quality Productivity
38 CMMI V1.3 and Beyond Phillips – November 2010 © 2010 Carnegie Mellon University Achieving Maturity Levels Processes are ad hoc and chaotic Adhere to policy; follow documented plans and processes; apply adequate resources; assign responsibility and authority; train people; apply CM; monitor, control, and evaluate process; identify and involve stakeholders; review with management Tailor the projects process from organizations standard processes; understand processes qualitatively; ensure that projects contribute to organization assets Measure process performance; stabilize process and control charts; deal with causes of special variations Prevent defects; proactively improve; insert and deploy innovative technology ML1 Initial ML1 Initial ML2 Managed ML2 Managed ML3 Defined ML3 Defined ML4 Quantitatively Managed ML4 Quantitatively Managed ML5 Optimizing ML5 Optimizing GG 2 All ML2 PAs GG 2 and GG 3 All ML2 and ML3 PAs GG 2 and GG 3 All ML2, ML3, and ML4 PAs GG 2 and GG 3 All ML2, ML3, ML4, and ML5 PAs
39 CMMI V1.3 and Beyond Phillips – November 2010 © 2010 Carnegie Mellon University Continuous Representation: PAs by Categories (And Potentially Across Constellations) Project/Work Management (Product) Engineering Support Process Management Acquisition Engineering Service Establishment and Delivery
40 CMMI V1.3 and Beyond Phillips – November 2010 © 2010 Carnegie Mellon University Achieving Capability Levels (CLs) for a Process Area CL0 Not performed, incomplete CL1 Performed CL1 Performed Perform the work CL2 Managed CL2 Managed Adhere to policy; follow documented plans and processes, apply adequate resources; assign responsibility and authority; train people, apply CM, monitor, control, and evaluate process; identify and involve stakeholders; review with management CL3 Defined CL3 Defined Projects process is tailored from organizations standard processes; understand process qualitatively; process contributes to the organizations assets A few GPs or SPs may be implemented GG 1 All SPs GG 1 and GG 2 All SPs GG 1, GG 2, and GG 3 All SPs
41 CMMI V1.3 and Beyond Phillips – November 2010 © 2010 Carnegie Mellon University Summary of Generic Goals and Practices Adapted from Cepeda Systems & Software Analysis, Inc. GG2: Institutionalize a Managed Process Generic PracticesGeneric Goals GG3: Institutionalize a Defined Process GP 3.1:Establish a Defined Process GP 3.2:Collect Process Related Experiences 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:Control Work Products 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 Specific Practices
42 CMMI V1.3 and Beyond Phillips – November 2010 © 2010 Carnegie Mellon University CMMI for Development
43 CMMI V1.3 and Beyond Phillips – November 2010 © 2010 Carnegie Mellon University CMMI for Development Model CMMI Core PAs Development- specific PAs Shared PA (SAM) 16 5 5 1 1 22 CMMI-SVC CMMI-ACQ CMMI-DEV Core PAs that are present in all CMMI models.
44 CMMI V1.3 and Beyond Phillips – November 2010 © 2010 Carnegie Mellon University Comparison of Models MeasureCMMI for DevelopmentCMMI for Acquisition CMMI for Services V1.1 Staged V1.1 Cont V1.2V1.3V1.2V1.3V1.2V1.3 Pages715710560468428423531506 Process Areas 25 22 24 Generic Goals 25535353 Generic Practices 1217 1317131713 Specific Goals 55 504946475253 Specific Practices 185189173167161163182181
45 CMMI V1.3 and Beyond Phillips – November 2010 © 2010 Carnegie Mellon University Development-Specific PAs Technical Solution Requirements Development Supplier Agreement Management (Shared with SVC) Supplier Agreement Management (Shared with SVC) Product Integration Validation Verification CMMI Model Framework (CMF) 16 Project, Organizational, and Support Process Areas
46 CMMI V1.3 and Beyond Phillips – November 2010 © 2010 Carnegie Mellon University CMMI-DEV PAs by Maturity Level Maturity LevelProcess Areas 5Optimizing Causal Analysis and Resolution Organizational Performance Management 4Quantitatively Managed Organizational Process Performance Quantitative Project Management 3Defined Decision Analysis and Resolution Integrated Project Management Organizational Process Definition Organizational Training Organizational Process Focus Product Integration Requirements Development Risk Management Technical Solution Validation Verification 2Managed Configuration Management Measurement and Analysis Project Monitoring and Control Project Planning Process and Product Quality Assurance Requirements Management Supplier Agreement Management For the V1.3 release, there were no changes that affected the DEV PAs positioning by maturity level.
47 CMMI V1.3 and Beyond Phillips – November 2010 © 2010 Carnegie Mellon University CMMI-DEV PAs by Category Process Management Organizational Innovation and Deployment (OID) Organizational Process Definition (OPD) Organizational Process Focus (OPF) Organizational Process Performance (OPP) Organizational Training (OT) Support Causal Analysis and Resolution (CAR) Configuration Management (CM) Decision Analysis and Resolution (DAR) Measurement and Analysis (MA) Process and Product Quality Assurance (PPQA) Project Management Integrated Project Management (IPM) Project Monitoring and Control (PMC) Project Planning (PP) Quantitative Project Management (QPM) Requirements Management (REQM) Risk Management (RSKM) (+) Supplier Agreement Management (SAM) Engineering Product Integration (PI) Requirements Development (RD) Technical Solution (TS) Validation (VAL) Verification (VER) For the V1.3 release, REQM was moved from Engineering to Project Management.
48 CMMI V1.3 and Beyond Phillips – November 2010 © 2010 Carnegie Mellon University Product Integration SG 1:Prepare for Product Integration SP 1.1Establish an Integration Strategy SP 1.2Establish the Product Integration Environment SP 1.3Establish Product Integration Procedures and Criteria SG 2: Ensure Interface Compatibility SP 2.1Review Interface Descriptions for Completeness SP 2.2Manage Interfaces SG 3: Assemble Product Components and Deliver the Product SP 3.1Confirm Readiness of Product Components for Integration SP 3.2Assemble Product Components SP 3.3Evaluate Assembled Product Components SP 3.4Package and Deliver the Product or Product Component Revised the purpose statement to ensure proper behavior instead of proper function, thereby more explicitly including quality attributes and required functionality. Changed emphasis on integration sequence to an emphasis on integration strategy. Described an integration strategy and how it relates to an integration sequence.
49 CMMI V1.3 and Beyond Phillips – November 2010 © 2010 Carnegie Mellon University Requirements Development SG 1:Develop Customer Requirements SP 1.1Elicit Needs SP 1.2Transform Stakeholder Needs into Customer Requirements SG 2: Develop Product Requirements SP 2.1Establish Product and Product Component Requirements SP 2.2Allocate Product Component Requirements SP 2.3Identify Interface Requirements SG 3: Analyze and Validate Requirements SP 3.1Establish Operational Concepts and Scenarios SP 3.2Establish a Definition of Required Functionality and Quality Attributes SP 3.3Analyze Requirements SP 3.4Analyze Requirements to Achieve Balance SP 3.5Validate Requirements SP1.2 revised to add that customer requirements should be prioritized based on their criticality to the customer and other stakeholders. Broadened emphasis from operational scenarios to a more balanced scenarios (operational, sustainment, and development). Added a focus on architectural requirements. Broadened emphasis from operational scenarios to a more balanced scenarios (operational, sustainment, and development). Added a focus on architectural requirements. Because Quality attributes needs to be considered in addition to functionality, SG3 and SP 3.2 were revised. Added informative material that requirements can be monitored through development based on their criticality to the customer. Because Quality attributes needs to be considered in addition to functionality, SG3 and SP 3.2 were revised. Added informative material that requirements can be monitored through development based on their criticality to the customer.
50 CMMI V1.3 and Beyond Phillips – November 2010 © 2010 Carnegie Mellon University Technical Solution SG 1:Select Product Component Solutions SP 1.1Develop Alternative Solutions and Selection Criteria SP 1.2Select Product Component Solutions SG 2: Develop the Design SP 2.1Design the Product or Product Component SP 2.2Establish a Technical Data Package SP 2.3Design Interfaces Using Criteria SP 2.4Perform Make, Buy, or Reuse Analyses SG 3: Implement the Product Design SP 3.1Implement the Design SP 3.2Develop Product Support Documentation
51 CMMI V1.3 and Beyond Phillips – November 2010 © 2010 Carnegie Mellon University Validation SG 1: Prepare for Validation SP 1.1Select Products for Validation SP 1.2Establish the Validation Environment SP 1.3Establish Validation Procedures and Criteria SG 2: Validate Product or Product Components SP 2.1Perform Validation SP 2.2Analyze Validation Results
52 CMMI V1.3 and Beyond Phillips – November 2010 © 2010 Carnegie Mellon University Verification SG 1: Prepare for Verification SP 1.1Select Work Products for Verification SP 1.2Establish the Verification Environment SP 1.3Establish Verification Procedures and Criteria SG 2: Perform Peer Reviews SP 2.1Prepare for Peer Reviews SP 2.2Conduct Peer Reviews SP 2.3Analyze Peer Review Data SG 3: Verify Selected Work Products SP 3.1Perform Verification SP 3.2Analyze Verification Results
© 2010 Carnegie Mellon University V1.3 CMMI Model Updates: Core PAs
54 CMMI V1.3 and Beyond Phillips – November 2010 © 2010 Carnegie Mellon University CMMI Product Suite, Version 1.3 Version 1.3 focused on but was not limited to the following: High Maturity Appraisal efficiency Consistency across constellations Simplify the generic practices Version 1.3 was change request (CR) driven.
55 CMMI V1.3 and Beyond Phillips – November 2010 © 2010 Carnegie Mellon University What Is a CMMI Model? A CMMI model is a subset of the CMMI Product Suite that covers a particular area of interest. Currently, there are three models that address the following: The development of products and services The acquisition of products and services The establishment, management, and delivery of services Every CMMI model is a process improvement approach that provides organizations with the essential elements of effective processes, can be used to guide improvement across a team, project, division, or entire organization, and helps to set process improvement goals and priorities, provide guidance for quality processes, and provide a point of reference for appraising current processes.
56 CMMI V1.3 and Beyond Phillips – November 2010 © 2010 Carnegie Mellon University How Similar Are Core PAs? Core process areas appear in all CMMI models; however... These process areas are not identical across all models. Informative material can be different so that users interpret goals and practices for the area of interest addressed by the model. Sometimes practices can be different in one model from another (e.g., Project Planning).
57 CMMI V1.3 and Beyond Phillips – November 2010 © 2010 Carnegie Mellon University V1.3 Model Architecture Changes IPPD/Teaming Removed the IPPD addition from CMMI-DEV and in its place added teaming practices from CMMI-ACQ and CMMI-SVC. These practices are not optional. Amplifications Removed the amplification model component. CMMI-ACQ Renamed the Acquisition process area category to be Acquisition Engineering. Moved AM and SSAD from the Acquisition PA category to the Project Management PA category. CMMI-DEV Moved REQM from the Engineering PA category to the Project Management PA category.
58 CMMI V1.3 and Beyond Phillips – November 2010 © 2010 Carnegie Mellon University V1.3 Changes to GGs, GPs, and GP Elaborations Positioned generic goals, generic practices, and GP elaborations in one central location as the first section of Part 2 in all three models. Simplified GG1 to make it more readable. Renamed GP 2.6 to Control Work Products. Added selected work products to the GP 2.9 statement. Simplified the GP 3.2 statement to replace collect work products, measures, measurement results, and improvement information with collect process related experiences. Eliminated GG4 and GG5.
59 CMMI V1.3 and Beyond Phillips – November 2010 © 2010 Carnegie Mellon University Core PAs by Maturity Level Causal Analysis and Resolution Organizational Performance Management 5 Optimizing 4 Quantitatively Managed 3 Defined 2 Managed Continuous Process Improvement Quantitative Management Process Standardization Basic Project Management Organizational Process Performance Quantitative Project Management Decision Analysis and Resolution Integrated Project Management Organizational Process Definition Organizational Process Focus Organizational Training Risk Management Configuration Management Measurement and Analysis Project Monitoring and Control Project Planning Process and Product Quality Assurance Requirements Management Risk Rework 1 Initial Process AreasLevel Focus Quality Productivity
60 CMMI V1.3 and Beyond Phillips – November 2010 © 2010 Carnegie Mellon University Core PAs by Category Process Management Organizational Process Definition (OPD) Organizational Process Focus (OPF) Organizational Performance Management (OPM) Organizational Process Performance (OPP) Organizational Training (OT) Support Causal Analysis and Resolution (CAR) Configuration Management (CM) Decision Analysis and Resolution (DAR) Measurement and Analysis (MA) Process and Product Quality Assurance (PPQA) Project and Work Management Integrated Project Management (IPM) Project Monitoring and Control (PMC) Project Planning (PP) Quantitative Project Management (QPM) Requirements Management (REQM) Risk Management (RSKM) (+) Supplier Agreement Management (SAM) SAM is a shared PA instead of a core PA. Work is substituted for Project in CMMI-SVC titles.
61 CMMI V1.3 and Beyond Phillips – November 2010 © 2010 Carnegie Mellon University Core PAs: Support Category Configuration Management Establish and maintain the integrity of work products using configuration identification, configuration control, configuration status accounting, and configuration audits Decision Analysis and Resolution Analyze possible decisions using a formal evaluation process that evaluates identified alternatives against established criteria Measurement and Analysis Develop and sustain a measurement capability used to support management information needs Process and Product Quality Assurance Provide staff and management with objective insight into processes and associated work products CM: Clarified that CM can apply to hardware, equipment, and other tangible assets. DAR: Added guidance on defining the scope of the decision and communicating results. MA: More clearly distinguished between information needs and objectives, measurement objectives, and business/project objectives. Included a table of examples (as in ACQ) for DEV and SVC. Clarified that PPQA also applies to organization level activities and work products.
62 CMMI V1.3 and Beyond Phillips – November 2010 © 2010 Carnegie Mellon University Core PAs: Process Management Category Organizational Process Definition Establish and maintain a usable set of organizational process assets, work environment standards, and rules and guidelines for teams Organizational Process Focus Plan, implement, and deploy organizational process improvements based on a thorough understanding of current strengths and weaknesses of the organizations processes and process assets Organizational Training Develop skills and knowledge of people so they can perform their roles effectively and efficiently Expanded applicability to training development and delivery methods such as self study, mentoring, and online training. Converted goal on teaming to a single practice, which is no longer an addition for IPPD only. Simplified SP 3.4 to replace process- related work products, measures, and improvement information with process related experiences.
63 CMMI V1.3 and Beyond Phillips – November 2010 © 2010 Carnegie Mellon University Core PAs: Project and Work Management Category -1 Integrated Project Management Establish and manage the project and the involvement of relevant stakeholders according to an integrated and defined process that is tailored from the organizations set of standard processes Project Monitoring and Control Provide an understanding of the projects progress so that appropriate corrective actions can be taken when the projects performance deviates significantly from the plan Project Planning Establish and maintain plans that define project activities Simplified SP 1.7 to replace work products, measures, and documented experiences with process related experiences. Converted goal on IPPD or Integrated Teaming to a single practice (IPPD no longer an addition). Simplified SP 1.7 to replace work products, measures, and documented experiences with process related experiences. Converted goal on IPPD or Integrated Teaming to a single practice (IPPD no longer an addition). Added guidance for monitoring risks, data management, stakeholder involvement, project progress, and milestone reviews. Added guidance on determining project lifecycle and milestones. Added subpractices on determining data rights and need for configuration control, and determining communication requirements and other continuing resource needs. Added guidance on determining project lifecycle and milestones. Added subpractices on determining data rights and need for configuration control, and determining communication requirements and other continuing resource needs.
64 CMMI V1.3 and Beyond Phillips – November 2010 © 2010 Carnegie Mellon University Core PAs: Project and Work Management Category -2 Requirements Management Manage requirements of the projects products and product components and to ensure alignment between those requirements and the projects plans and work products Risk Management Identify potential problems before they occur so that risk handling activities can be planned and invoked as needed across the life of the product or project to mitigate adverse impacts on achieving objectives Changed the focus of SP 1.5 so that it now reads Ensure that project plans and work products remain aligned with requirements. Included examples related to: architectural risks, use of industry standards to identify risks, FMEA, and consequence monetization. Provided guidance on maintaining risk parameters through life of the project. Included examples related to: architectural risks, use of industry standards to identify risks, FMEA, and consequence monetization. Provided guidance on maintaining risk parameters through life of the project.
65 CMMI V1.3 and Beyond Phillips – November 2010 © 2010 Carnegie Mellon University SAM – the Shared PA SG 1:Establish Supplier Agreements SP 1.1Determine Acquisition Type SP 1.2Select Suppliers SP 1.3Establish Supplier Agreements SG 2: Satisfy Supplier Agreements SP 2.1Execute the Supplier Agreement SP 2.2Accept the Acquired Product SP 2.3Ensure Transition of Products Clarified the applicability of SAM practices. Demoted SP 2.2 and SP 2.3 to subpractices of SP 2.1 and renumbered the remainder of the practices. Revised SP 2.3 to allow its applicability to times when the product or service is delivered directly to the customer or end user from the supplier.
66 CMMI V1.3 and Beyond Phillips – November 2010 © 2010 Carnegie Mellon University New Informative Material Update selected process areas to provide interpretation of practices for organizations with respect to the following topics: Agile methods Quality attributes (i.e., non functional requirements or ilities) Allocation of product capabilities to release increments Product lines System of systems Architecture-centric development practices Technology maturation Customer satisfaction
67 CMMI V1.3 and Beyond Phillips – November 2010 © 2010 Carnegie Mellon University Terminology Used team instead of integrated team in most cases when discussing teaming practices. Simplified phrases such as work products, measures, and improvement information with simpler expressions such as the word experiences. Revised the terminology in engineering-related material from a strong emphasis on functionality to a more balanced behavior (functionality and quality attributes) or simply functionality and quality attributes. Clarified whether the use of lifecycle refers to a project lifecycle, product lifecycle, or both throughout the model. Involved the CMMI Translation Team during model development work to identify and resolve translations issues. Replaced the word project with other terms where needed. (SVC only)
68 CMMI V1.3 and Beyond Phillips – November 2010 © 2010 Carnegie Mellon University Front Matter Clarified that CMMI models are not processes or process descriptions. Removed any biases favoring maturity levels or capability levels. Explained that core process areas appear in all CMMI models and that they can have different expected and informative material. For example, PP can have an SP in ACQ that is absent in DEVs PP. Added information on selecting the right CMMI model for use.
69 CMMI V1.3 and Beyond Phillips – November 2010 © 2010 Carnegie Mellon University Glossary -1 Differentiated between definitions and usage notes for each glossary entry. Removed terms from the glossary, including: adequate, alternative practice, amplifications, appropriate, appraisal team leader, as needed, assessment, assignable cause of process variation, capability evaluation, discipline, evidence, functional configuration audit, goal, integrated product and process development, objective, objective evidence, observation, organizational unit, physical configuration audit, profile, program, rating, reference, root cause, and test procedure. Revised the definitions of quality and corrective action to be more consistent with ISO definitions. Revised the terms process, development, supplier, and team to be more broadly applicable.
70 CMMI V1.3 and Beyond Phillips – November 2010 © 2010 Carnegie Mellon University Glossary -2 Revised the definition of supplier agreement to include agreements within an organization. Revised the following definitions related to high maturity practices: causal analysis, natural bounds, optimizing process, process performance model, quality and process performance objectives, stable process, statistical techniques, and subprocess. Added the following terms related to high maturity: quantitative management, statistical and other quantitative techniques. Deleted the following terms related to high maturity: quantitatively managed process, statistically managed process, and statistical predictability.
71 CMMI V1.3 and Beyond Phillips – November 2010 © 2010 Carnegie Mellon University V1.3 Changes to High Maturity PAs Many of the most significant changes to CMMI models as part of Version 1.3, are the changes to the high maturity process areas (CAR, OPM, OPP, and QPM). These process areas are core process areas, but weve focused on these four over the others because of their significance in this release.
72 CMMI V1.3 and Beyond Phillips – November 2010 © 2010 Carnegie Mellon University High Maturity Changes for V1.3 Terminology Confusion Common Cause (Statistical versus Quantitative Techniques) Process Models and Process Modeling Business Objectives Subprocesses Requirements implied versus explicit/ Explanations not central or consistent Model/ Audit Criteria/ Presentations (Healthy Ingredients)/ UCHMP Perceptions Customers – ML 5 is expensive – no better than 3 Industry – ML 5 is NOT RIGHT for every business High Maturity in ALL constellations Examples are focused on Development
73 CMMI V1.3 and Beyond Phillips – November 2010 © 2010 Carnegie Mellon University High Maturity Restructuring for V1.3 Insufficient link between process improvement, business objectives, and performance Clarify distinction between ML4 and ML5 Eliminate GG4 and GG5 Make CAR more relevant for organizational benefit
74 CMMI V1.3 and Beyond Phillips – November 2010 © 2010 Carnegie Mellon University Combined OID and OPM into One PA Organizational Performance Management Causal Analysis and Resolution Organizational Process Performance Quantitative Project Management Organization Customer Improvement Proposals Measures, baselines and models Organizational quality & process performance objectives Measures, baselines and models Selected outcomes Updated measures, baselines and models (actual performance) Progress toward achieving quality & process performance objectives Improvements Performance issues Root cause solutions Quality & process performance objectives Measures, baselines and models
75 CMMI V1.3 and Beyond Phillips – November 2010 © 2010 Carnegie Mellon University Causal Analysis and Resolution SG 1:Determine Causes of Selected Outcomes SP 1.1Select Outcomes for Analysis SP 1.2Analyze Causes SG 2: Address Causes of Selected Outcomes SP 2.1Implement Action Proposals SP 2.2Evaluate the Effect of Implemented Actions SP 2.3Record Causal Analysis Data Used outcomes instead of defects and problems. Added examples for service organizations and for selecting outcomes for analysis. Added subpractices in SP 1.1 for defining the problem, and in SP 2.2 for following up when expected results did not occur. Added more information about how PPMs can be used. Added emphasis on prevention and reducing recurrence.
76 CMMI V1.3 and Beyond Phillips – November 2010 © 2010 Carnegie Mellon University Organizational Performance Management SG 1:Manage Business Performance SP 1.1Maintain Business Objectives SP 1.2Analyze Process Performance Data SP 1.3Identify Potential Areas for Improvement SG 2: Select Improvements SP 2.1Elicit Suggested Improvements SP 2.2Analyze Suggested Improvements SP 2.3Validate Improvements SP 2.4Select and Implement Improvements for Deployment SG 3: Deploy Improvements SP 3.1Plan the Deployment SP 3.2Manage the Deployment SP 3.3Evaluate Improvement Effects Renamed the PA to be Organizational Performance Management (OPM). Added a new goal about managing business performance using statistical and other quantitative techniques. Provided more information about how improvements can be selected for deployment. More explicitly described and discussed using process performance models. Clarified that not all improvement validations include piloting.
77 CMMI V1.3 and Beyond Phillips – November 2010 © 2010 Carnegie Mellon University Organizational Process Performance SG 1:Establish Performance Baselines and Models SP 1.1Establish Quality and Process Performance Objectives SP 1.2Select Processes SP 1.3Establish Process Performance Measures SP 1.4Analyze Process Performance and Establish Process Performance Baselines SP 1.5Establish Process Performance Models Re-ordered SPs, moving the old SP 1.3 (Establish Quality and Process Performance Objectives) to SP 1.1 Revised SP 1.4 to include process performance analysis and assessment of subprocess stability. Revised SP 1.5 to note that under certain circumstances, projects may need to create their own process performance models. Clarified the relationship of OPP to other high maturity process areas.
78 CMMI V1.3 and Beyond Phillips – November 2010 © 2010 Carnegie Mellon University Quantitative Project Management SG 1:Prepare for Quantitative Management SP 1.1Establish the Projects Objectives SP 1.2Compose the Defined Process SP 1.3Select Subprocesses and Attributes SP 1.4Select Measures and Analytic Techniques SG 2: Quantitatively Manage the Project SP 2.1Monitor the Performance of Selected Subprocesses SP 2.2Manage Project Performance SP 2.3Perform Root Cause Analysis Restructured QPM so that SG1 focuses on preparation and SG2 focuses on managing the project. Added guidance about using process performance baselines and process performance models. Define quantitative management in the glossary to include statistical management and use that definition for use of the terms throughout QPM. Removed the practice about applying statistical methods to understand variation to reduce the over-emphasis on control charts. Added new practices about managing performance and performing root cause analysis.
© 2010 Carnegie Mellon University CMMI Adoption
80 CMMI V1.3 and Beyond Phillips – November 2010 © 2010 Carnegie Mellon University Number of Appraisals Number of Appraisals Reported to the SEI by Continent
81 CMMI V1.3 and Beyond Phillips – November 2010 © 2010 Carnegie Mellon University * Red/Italic country name: New additions with this reporting since March 2010 Countries Where Appraisals Have Been Performed and Reported to the SEI
82 CMMI V1.3 and Beyond Phillips – November 2010 © 2010 Carnegie Mellon University CMMI Adoption Has Been Broad 34 countries with > 10 appraisals (as of Sept 2010): USA 1719 China 1475 India 576 Japan 324 Spain 198 France 183 Korea (ROK) 176 Brazil 167 Taiwan 147 U.K. 118 Mexico 104 Germany 80 Argentina 79 Malaysia 74 Canada 62 Egypt 52 Italy 46 Colombia 43 Chile 43 Thailand 41 And - Australia, Pakistan, Philippines, Singapore, Israel, Hong Kong, Viet Nam, Turkey, Netherlands, Portugal, Sri Lanka, Ireland, Peru and Russia http://www.sei.cmu.edu/cmmi/casestudies/profiles/cmmi.cfm Is the source for these statistical analyses. Estimated 1.2 million people work in organizations that have had at least one SCAMPI A appraisal since April 2002. There were SCAMPI A appraisals reported from 71 countries. Approximately 75% of adopters are commercial organizations. Services; 1/6 Manufacturing Approximately 2/3 of adopters in the US are contractors for military/government or are government. 201 to 2000+ 23.8% 1 to 100 58.2% Manufacturing 16.3% Services 71.1%
83 CMMI V1.3 and Beyond Phillips – November 2010 © 2010 Carnegie Mellon University CMMI Transition Status Reported to the SEI as of 10-31-10 Training Introduction to CMMI V1.2120,838 Intermediate Concepts of CMMI3,238 Understanding CMMI High Maturity Practices636 Introduction to CMMI V1.2 Supplement for ACQ1,325 Introduction to CMMI V1.2 Supplement for SVC2,361 Introduction to CMMI for Services V1.2314 Certifications Introduction to CMMI V1.2 Instructors408 CMMI-ACQ V1.2 Supplement Instructors66 CMMI-SVC V1.2 Supplement Instructors131 Introduction to CMMI for Services V1.2 Instructors23 SCAMPI V1.2 Lead Appraisers466 SCAMPI V1.2 High Maturity Lead Appraisers142 CMMI-ACQ V1.2 Lead Appraisers72 CMMI-SVC V1.2 Lead Appraisers147
84 CMMI V1.3 and Beyond Phillips – November 2010 © 2010 Carnegie Mellon University CMMI V1.2 Foreign Language Translation Status Reported to the SEI as of 10-31-2010 LanguageStatus (for CMMI-DEV V1.2) JapaneseCompleted August 2007. Intro course translated October 2007 Chinese (trad.)Completed December 2007 FrenchCompleted August 2008 GermanCompleted April 2009. Intro course translated October 2009 SpanishCompleted in June 2009 PortugueseCompleted in May 2010 LanguageStatus (for CMMI-ACQ V1.2) Chinese (trad.)Completed April 2009 LanguageStatus (for CMMI-SVC V1.2) Chinese (trad.)Completed in July 2010 ArabicTo start, pending agreement LanguageStatus (for CMMI-DEV V1.3) DutchUnderway
85 CMMI V1.3 and Beyond Phillips – November 2010 © 2010 Carnegie Mellon University Number of Appraisals Conducted by Year Reported as of 10-31-10
86 CMMI V1.3 and Beyond Phillips – November 2010 © 2010 Carnegie Mellon University Continuous Improvement Certification of our process improvement professionals is appropriate and achievable Lead Appraisers first Instructors next CMMI consultants/practitioners in the future Improved architecture allows process improvement model expansion. Extensions of the lifecycle o allows coverage of more of the enterprise or potential partnering organizations o adapts model features to fit non-developmental efforts
87 CMMI V1.3 and Beyond Phillips – November 2010 © 2010 Carnegie Mellon University Transition… We are providing an on-line upgrade course for V1.3 as we did for V1.2. Users make the transition by taking the upgrade course. During a period of one year, organizations may use either V1.2 or V1.3 models for their appraisals. Appraisals using V1.2 models will be valid for the full 3 years.
Copyright © 2003 by Cooliemon TM, LLC 1 Causal Analysis & Resolution (CAR) at Level 1 Presenter: Ralph Williams, President SEI Authorized CBA IPI Lead.
Capability Maturity Model CS3300 Fall The Problem Contractors over budget and late. Need a way to rank how likely a software company is to deliver.
WEEK 2. A Quality Focus Process Methods Tools Process Series of predictable steps-a road map that helps create a timely and high quality entity Software.
Software Project Failure Software Project Failure Night Two, Part One CSCI 521 Software Project Management.
OHT 2.1 Galin, SQA from theory to implementation © Pearson Education Limited 2004 Software Quality assurance (SQA) SWE 333 Dr Khalid Alnafjan
ORGANIZATIONAL DEVELOPMENT CORE GROUP Academy Session 2011, Paris October 30 th and 31 st 2011 EUROPEAN SCOUT REGION 1.
Managing CMMI ® as a Project Intelligence and Information Systems (IIS), Garland, Texas Richard Marks November 20, 2003 CMMI is registered in the U.S.
Pittsburgh, PA CMMI Acquisition Module - Page M5-1 CMMI ® Sponsored by the U.S. Department of Defense © 2005 by Carnegie Mellon University This.
1 15 Making the System Operational Lecture Activities of the Implementation and Support Phases Figure 15-1.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 27 Slide 1 Quality Management.
SE 450 Software Processes & Product Metrics 1 Quality Systems Frameworks.
Software Engineering CSE470: Process 15 Software Engineering Phases Definition: What? Development: How? Maintenance: Managing change Umbrella Activities:
Capability Maturity Model. What is CMM? n CMM: Capability Maturity Model n Developed by the Software Engineering Institute of the Carnegie Mellon University.
N By: Md Rezaul Huda Reza n
Dillon: CSE470: SE, Process1 Software Engineering Phases l Definition: What? l Development: How? l Maintenance: Managing change l Umbrella Activities:
W5HH Principle As applied to Software Projects Compiled by Dr. Peri Sastry.
1 Dr. Ashraf El-Farghly SECC. 2 Level 3 focus on the organization - Best practices are gathered across the organization. - Processes are tailored depending.
Lecture 5: Requirements Engineering Dr Valentina Plekhanova University of Sunderland, UK
SOFTWARE PROCESS IMPROVEMENT “Never Stop Learning”
Copyright © 2003 by Cooliemon TM, LLC 1 Presenter: Ralph Williams, President SEI Authorized CBA IPI Lead Assessor (CMM ® ) SCAMPI Lead Appraiser SM (CMMI.
© 2010 Carnegie Mellon University ® CMMI is registered in the U.S. Patent and Trademark Office by Carnegie Mellon University. V&V Principles Verification.
MethodCMMI Capability Maturity Model Integration.
J. R. Burns, Texas Tech University Capability Maturity Model -- CMM n Developed by the Software Engineering Institute (SEI) in 1989 –SEI is a spinoff.
1 Fraud Risk Assessment Chapter Describe the factors that influence an organization’s vulnerability to fraud. Explain the difference between preventive.
Computer Engineering 203 R Smith Process/Plan Model 7/ Development Process Models Development Process Models are different ways to look at the processes.
1)List and briefly describe the three project quality management processes. Quality Planning: Identify which quality standards are relevant to project.
1 1 The World of the Modern Systems Analyst and as a Project Manager Lecture 1.
S3-1 © 2001 Carnegie Mellon University OCTAVE SM Process 3 Identify Staff Knowledge Software Engineering Institute Carnegie Mellon University Pittsburgh,
Module 12 WSP quality assurance tool 1. Module 12 WSP quality assurance tool Session structure Introduction About the tool Using the tool Supporting materials.
Copyright ProcessVelocity, LLP Slides intended for informational purposes only. CMM and Capability Maturity Model are registered in the U.S. Patent.
14% of the exam 24 questions 1 Carol Pattyn 6/18/13.
Software Life Cycles ECE 417/617: Elements of Software Engineering Stan Birchfield Clemson University.
Slide 1 Testing Workflow Purpose l Purpose Verify the result from implementation by testing each build Plan the tests in each iteration Integration tests.
Role of Information Farrokh Alemi, Ph.D.. Torturing Data Until They Confess I only have one question. What is 1 plus 1? Mathematician: “For sure 2”
Introduction to Software Engineering LECTURE 2 By Umm-e-Laila 1Compiled by: Umm-e-Laila.
Technische Universität München Agile Modeling Emitzá Guzmán.
©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 25 Slide 1 Chapter 25 Process Improvement.
© Copyright 2006 FPT Software 1 © FPT SOFTWARE – TRAINING MATERIAL – Internal use 04e-BM/NS/HDCV/FSOFT v2/3 How to work in Fsoft project Authors: KienNT.
CMMI Overview Quality Frameworks. Slide 2 of 146 Outline Introduction High level overview of CMMI Questions and comments.
Process and Product Quality Assurance (PPQA) Intermediate Concepts of CMMI Presentation Assignment Nicolae Giurescu.
Service management is a set of specialized organizational capabilities for providing value to customers in the form of services.
Introduction to Product Family Engineering. 11 Oct 2002 Ver 2.0 ©Copyright 2002 Vortex System Concepts 2 Product Family Engineering Overview Project Engineering.
Capability Maturity Model Part One - Overview. History Effort started by SEI and MITRE Corporation assess capability of DoD contractors First.
Acceptance testing is a user-run test that demonstrates the application’s ability to meet the original business objectives and system requirements and.
THE MANAGEMENT AND CONTROL OF QUALITY, 5e, © 2002 South-Western/Thomson Learning TM 1 Chapter 7 Process Management.
1 Software Process and Product Metrics CIS 375 Bruce R. Maxim UM-Dearborn.
Software Engineering - Spring 2003 (C) Vasudeva Varma, IIITHClass of 39 CS3600: Software Engineering: Standards in Process Modeling CMM and PSP.
1 Requirements Engineering Processes – 2. 2 Recap of Last Lecture - 1 We introduced the concept of requirements engineering process We discussed inputs.
© 2017 SlidePlayer.com Inc. All rights reserved.