Chair of Software Engineering Prof. Dr. Bertrand Meyer March 2007 – June 2007 Lecture 11: CMMI and the software process (based in part on material by Dr. Peter Kolb)
SEI Trademarks and Service Marks SM CMM Integration SCAMPI are service marks of Carnegie Mellon University ® Capability Maturity Model, Capability Maturity Modeling, CMM, and CMMI are registered in the U. S. Patent & Trademark Office 2 Software Engineering, lecture 11: CMMI 2
Get ready for interesting English… The plan for performing the organizational process focus process, which is often called `the process-improvement plan, ' differs from the process action plans described in specific practices in this process area. The plan called for in this generic practice addresses the comprehensive planning for all of the specific practices in this process area, from the establishment of organizational process needs all the way through to the incorporation of processrelated experiences into the organizational process assets. 3 Software Engineering, lecture 11: CMMI 3
Over/Under Percentage Boeing results 140% 0% -140% . . . . . . . . . . . Without Historical Data With Historical Data. Variance between + 20% to - 145% Variance between - 20% to + 20% (Mostly Level 1 & 2) (Level 3) (Based on 120 projects in Boeing Information Systems) Reference: John D. Vu. “Software Process Improvement Journey: From Level 1 to Level 5. ” 7 th SEPG Conference, San Jose, March 1997. 4 Software Engineering, lecture 11: CMMI 4
Improved cycle time Source: Software Engineering Div. , Hill AFB, Published in Crosstalk May 1999 5 Software Engineering, lecture 11: CMMI 5
Increased productivity and quality 6 Software Engineering, lecture 11: CMMI 6
CMMI goals Emphasis on developing processes and changing culture for measurable benefit to organization’s business objectives Framework from which to organize and prioritize engineering, people, and business activities Supports coordination of multi-disciplined activities required to build successful product or application Adds “Engineering Systems Thinking” 7 Software Engineering, lecture 11: CMMI 7
What is a CMM? Capability Maturity Model: A reference model of mature practices in a specified discipline, used to assess a group’s capability to perform that discipline CMMs differ by Ø Discipline (software, systems, acquisition, etc. ) Ø Structure (staged versus continuous) Ø How Maturity is Defined (process improvement path) Ø How Capability is Defined (institutionalization) NOT: Ready-made scheme or template for describing processes Ø Methods for the processes Ø 8 Software Engineering, lecture 11: CMMI 8
Bridging the divide Integrates systems and software disciplines into one process improvement framework. CMMI-SE/SW/IPPD/SS, V 1. 1 Ø Systems Engineering Ø Software Engineering Ø Integrated Product and Process Development Ø Supplier Sourcing Provides a framework for introducing new disciplines as needs arise. 9 Software Engineering, lecture 11: CMMI 9
The CMM Explosion The first CMM (CMM v 1. 0) was developed for software and released in August 1991 Based on this success and the demand from other interests CMMs were developed for other disciplines and functions Ø Systems Engineering Ø People Ø Integrated Product Development Ø Software Acquisition Ø Software Quality Assurance Ø Measurement Ø Others……. 10 Software Engineering, lecture 11: CMMI 10
The world of standards http: //www. software. org/quagmire/ 11 Software Engineering, lecture 11: CMMI 11
ISO 9001: 2000 vs CMMI ISO 9001: 2000 Ø No explicit requirements for § Institutionalization § Creating and maintaining organizational process assets § Organizational Measurement Repository § Database of good and best practices § Misses details for the following process areas § Organizational Training (Lvl 3) § Risk Management (Lvl 3) § Decision Analysis and Resolution (Lvl 3) § Organization Process Performance (Lvl 4) § Quantitative Project Management (Lvl 4) § Organization Innovation and Deployment (Lvl 5) § Causal Analysis (Lvl 5) 12 Software Engineering, lecture 11: CMMI 12
Support of CMMI for ISO 9001: 2000 Organizations at the CMMI Maturity Level 3 will be ready for ISO 9001: 2000 registration with minor adjustments Organizations registered as ISO 9001: 2000 compliant will require additional effort to reach the CMMI Level 2 or 3 The CMMI path leverages the investment an organization may have in ISO 9001 Ø Provides additional benefits especially in institutionalizing the engineering discipline Ø Takes an organization to the quantitative management level of process improvements Ø 13 Software Engineering, lecture 11: CMMI 13
Model Representations ML 2 ML 1. . . for an established set of process areas across an organization 14 5 4 3 ML 3 1 2 ML 4 0 ML 5 Process Area Capability Staged PA PA PA Software Engineering, lecture 11: CMMI 14
Management visibility by maturity level Level Process Characteristics Management Visibility In Out Defined Process is characterized for the organization and is proactive In Out Managed Process is characterized for projects and is often reactive In Out Initial Process is unpredictable, poorly controlled, and reactive In Out Optimizing Quantitatively Managed 15 Focus is on continuous quantitative improvement Process is measured and controlled Software Engineering, lecture 11: CMMI 15
Capability levels are cumulative Because capability levels build upon one another, there can be no gaps. 16 Software Engineering, lecture 11: CMMI 16
Structure of the CMMI Staged Representation Maturity Level Process Area Generic Goals Process Area Specific Goals Common Features Commitment to Perform Ability to Perform Directing Implementation Generic Practices Verification Specific Practices Commitment to Perform: creates policies and secures sponsorship for process improvement Ability to Perform: ensures that project/organization has needed resources for improvement Directing Implementation: collects, measures, and analyzes data related to processes Verification: verifies that activities meet requirements, processes, procedures 17 Software Engineering, lecture 11: CMMI 17
Generic goals Commitment to Perform: creates policies and secures sponsorship for process improvement efforts Ability to Perform: ensures that the project and/or organization has the resources it needs to pursue process improvement Directing Implementation: collects, measures, and analyzes data related to processes Verification: verifies that the projects and/or organization’s activities conform to requirements, processes, and procedures 18 Software Engineering, lecture 11: CMMI 18
CMMI terminology Institutionalization involves implementing practices that Ø Ø Provide needed infrastructure support Ø Ensure processes are defined, documented, understood Ø 19 Ensure the process areas are effective, repeatable and long lasting Enable organizational learning to improve the processes Software Engineering, lecture 11: CMMI 19
CMMI terminology Establish and Maintain Ø This phrase connotes a meaning beyond the component terms; it includes documentation and usage. Work product Ø The term “work product” is used throughout the CMMI Product Suite to mean any artifact produced by a process. These artifacts can include files, documents, parts of the product, services, processes, specifications, and invoices. Planned Process Ø A process that is documented both by a description and a plan. The description and plan should be coordinated, and the plan should include standards, requirements, objectives, resources, assignments, etc. 20 Software Engineering, lecture 11: CMMI 20
CMMI terminology Performed Process (Capability Level 1) Ø A process that accomplishes the needed work to produce identified output work products using identified input work products. The specific goals of the process area are satisfied. Managed Process (Capability Level 2) Ø A “managed process” is a performed process that is planned and executed in accordance with policy; employs skilled people having adequate resources to produce controlled outputs; involves relevant stakeholders; is monitored, controlled, and reviewed; and is evaluated for adherence to its process description. Defined Process (Capability Level 3) Ø A “defined process” is a managed process that is tailored from the organization’s set of standard processes according to the organization’s tailoring guidelines; has a maintained process description; and contributes work products, measures, and other process-improvement information to the organizational process assets 21 Software Engineering, lecture 11: CMMI 21
The maturity levels 5 4 3 2 1 22 Optimizing Focus on process improvement Quantitatively Managed Process measured and controlled Defined Process characterized for the organization and is proactive Process characterized for projects and is often reactive Process unpredictable, poorly controlled and reactive Managed Performed Software Engineering, lecture 11: CMMI 22
Process areas by maturity level Level Focus Process Areas 5 Optimizing Continuous process improvement Organizational Innovation and Deployment Causal Analysis and Resolution 4 Quantitatively Managed Quantitative management Organizational Process Performance Quantitative Project Management 3 Defined Process standardization (SS) (IPPD) 2 Managed Basic project management Requirements Development Technical Solution Product Integration Verification Validation Organizational Process Focus Organizational Process Definition Organizational Training Integrated Project Management Integrated Supplier Management Risk Management Decision Analysis and Resolution Organizational Environment for Integration Integrated Teaming Requirements Management Project Planning Project Monitoring and Control Supplier Agreement Management Measurement and Analysis Process and Product Quality Assurance Configuration Management 1 Performed 23 Software Engineering, lecture 11: CMMI 23
Examples The purpose of Integrated Supplier Management is to proactively identify sources of products that may be used to satisfy the project’s requirements and to manage selected suppliers while maintaining a cooperative projectsupplier relationship 24 Software Engineering, lecture 11: CMMI 24
Examples The purpose of Organizational Process Definition is to establish and maintain a usable set of organizational process assets. (Organizational process asset: “Anything that the organization considers useful in attaining the goals of a process area. “) 25 Software Engineering, lecture 11: CMMI 25
Examples 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. 26 Software Engineering, lecture 11: CMMI 26
Process capability prediction Focus is on continuous quantitative improvement Target N-z Optimizing Predicted Performance Process Characteristics Probability Level Process is measured and controlled Target N-y Quantitatively Managed Probability Time/$/. . . Process is characterized for the organization and is proactive Target N-x Defined Probability Time/$/. . . 27 Process is unpredictable, poorly controlled, and reactive Target N+a. Time/$/. . . Target N Initial Process is characterized for projects and is often reactive Probability Managed Probability Time/$/. . . Software Engineering, lecture 11: CMMI 27
People implications Level Optimizing Quantitatively Managed Defined Managed Initial 28 Process Characteristics People Implications Focus is on continuous quantitative improvement Focus on "fire prevention"; improvement anticipated and desired, and impacts assessed Process is measured and controlled Sense of teamwork and interdependencies Process is characterized for the organization and is proactive Increased reliance on defined process; investment in people and process as corporate assets Process is characterized for projects and is often reactive Overreliance on experience of good people – when they go, the process goes Process is unpredictable, poorly controlled, and reactive Focus on "fire fighting"; effectiveness low – frustration high Software Engineering, lecture 11: CMMI 28
Risk implications Level Optimizing Process Characteristics Focus is on continuous quantitative improvement Process is measured Quantitatively and controlled Managed Defined Process is characterized for the organization and is proactive Managed Initial 29 Process is characterized for projects and is often reactive Process is unpredictable, poorly controlled, and reactive Results P r o d u c t i v i t y Q u a l i t y R i s k C u s t o m e r Software Engineering, lecture 11: CMMI S a t i s f a c t i o n 29
Specific and generic goals and practices Capability Levels PA PA 5 4 3 2 1 Process Areas (PA) 30 Software Engineering, lecture 11: CMMI 30
Generic goals and practices Capability Level Generic Goals Generic Practices 1 Achieve Specific Goals GP 1. 1 Perform Base Practices 2 Institutionalize a Managed Process GP 2. 1 GP 2. 2 GP 2. 3 GP 2. 4 GP 2. 5 GP 2. 6 GP 2. 7 GP 2. 8 GP 2. 9 GP 2. 10 Establish an Organizational Policy Plan the Process Provide Resources Assign Responsibility Train People Manage Configurations Identify and Involve Relevant Stakeholders Monitor and Control the Process Objectively Evaluate Adherence Review Status with Higher Level Mgmt GP 3. 1 GP 3. 2 Establish a Defined Process Collect Improvement Information 3 4 31 Institutionalize a Defined Process Institutionalize a Quantitatively Managed Process Software Engineering, lecture 11: CMMI 31
Generic practices The Generic Practices support institutionalization of critical practices for an organization to have a successful process improvement initiative Ø Ø Processes will survive staff changes Ø Process improvement will be related to business goals Ø The organization will not find itself continuously “reinventing the wheel” Ø There will be the commitment to provide resources or infrastructure to support or improve the processes Ø 32 Processes will be executed and managed consistently There will be historical basis for cost estimation Software Engineering, lecture 11: CMMI 32
For More Information About CMMI Go to CMMI Website § http: //sei. cmu. edu/cmmi § http: //seir. sei. cmu. edu/seir/ § http: //jo. sei. cmu. edu/pub/english. cgi/0/323123 § http: //dtic. mil/ndia (first annual CMMI Conference) § http: //www. faa. gov/aio Ø Assistance for government organizations: § SW-CMM v 1. 1 to CMMI v 1. 1 Mappings § Software Technology Support Center § http: //www. stsc. hill. af. mil Ø 33 Software Engineering, lecture 11: CMMI 33
CMMI Defines goals and practices shown to be useful to the software industry Primarily directed to large organizations Focus on process: explicit, documented, reproducible, measurable, self-improving Essential to outsourcing industry Technology-neutral 34 Software Engineering, lecture 11: CMMI 34
TSP, PSP Transposition to work of individual teams and developers 35 Software Engineering, lecture 11: CMMI 35
Management support The initial TSP objective is to convince management to let the team be self-directed, meaning that it: Ø Ø Establishes its own roles Ø Decides on its development strategy Ø Defines its processes Ø Develops its plans Ø 36 Sets its own goals Measures, manages, and controls its work Software Engineering, lecture 11: CMMI 36
Management support Management will support you as long as you: Strive to meet their needs Ø Provide regular reports on your work Ø Convince them that your plans are sound Ø Do quality work Ø Respond to changing needs Ø Come to them for help when you have problems Ø 37 Software Engineering, lecture 11: CMMI 37
Management support Management will agree to your managing your own work as long as they believe that you are doing a superior job. To convince them of this, you must: Maintain and publish precise, accurate plans Ø Measure and track your work Ø Regularly show that you are doing superior work Ø The PSP helps you do this 38 Software Engineering, lecture 11: CMMI 38
PSP essential practices Ø Measure, Ø Learn track, and analyze your work from your performance variations Ø Incorporate 39 lessons learned into your personal practices Software Engineering, lecture 11: CMMI 39
What does a PSP provide? A stable, mature PSP allows you to Ø Estimate and plan your work Ø Meet your commitments Ø Resist unreasonable commitment pressures You will also Ø Understand your current performance Ø Improve your expertise as a professional 40 Software Engineering, lecture 11: CMMI 40
PSP fundamentals As a personal process, PSP includes: Ø Defined steps Ø Forms Ø Standards Ø A measurement and analysis framework for characterizing and managing your personal work Ø A defined procedure to help improve your personal performance 41 Software Engineering, lecture 11: CMMI 41
The PSP process flow Requirements Planning Design Scripts guide Code Logs Compile Test Postmortem PM Finished product 42 Project summary Project and process data summary report Software Engineering, lecture 11: CMMI 42
A progressive approach PSP is introduced in six upward-compatible steps At each step: Ø Ø Gather and analyze data on your work Ø 43 Write one or more modules Use results to improve your personal performance Software Engineering, lecture 11: CMMI 43
The steps 44 Software Engineering, lecture 11: CMMI 44
Goals at each level PSP 0: Establish a measured performance baseline PSP 1: Make size, resource, and schedule plans PSP 2: Practice defect and yield management 45 Software Engineering, lecture 11: CMMI 45
PSP 0 PSP 2 Code reviews Design reviews PSP 1 Size estimating Test report PSP 0 Current process Time recording Defect type standard 46 PSP 2. 1 Design templates PSP 1. 1 Task planning Schedule planning PSP 0. 1 Coding standard Size measurement Process improvement proposal (PIP) Objective: Ø Demonstrate use of defined process for small programs Ø Incorporate basic measurements in process Ø Minimize changes to your personal practices Software Engineering, lecture 11: CMMI 46
PSP 0 setup PSP 0 is a simple, defined, personal process: Make a plan Ø Use your current design and development methods to produce a small program Ø Gather time and defect data on your work Ø Prepare a summary report Ø 47 Software Engineering, lecture 11: CMMI 47
The six phases of PSP 0 Produce plan for developing program from requirements 1 4 Plan Compile 2 Produce design specification for the Design program. Turn design into executable code (In Eiffel, 2 & 3 are one step) 48 3 Code 5 Test Translate into executable code Verify that code satisfies requirements 6 Summarize & Postmortem analyze project data Software Engineering, lecture 11: CMMI 48
Phase order PSP looks like waterfall but is not Phase order is determined by dependencies: Plan Can’t test code before it’s compiled Ø Can’t compile before it’s written Ø Can’t use design if produced after code is written Ø No reason to make a plan after you’re done Design Ø Code Compile Test Conclusion: start here with a plan 49 Postmortem Software Engineering, lecture 11: CMMI 49
Cyclic process flow Programs that are large programs or not well understood may require an iterative approach In this example, each module is separately coded, compiled, and tested Requirements Plan Design Module A Module B Code Compile The example uses PSP 0 phases and 2 code-compiletest cycles Code Compile Test Program and Project data 50 Postmortem Software Engineering, lecture 11: CMMI 50
Cyclic process flow There can be more than 2 cycles Part size is key factor for determining cycles: Ø Line of code: too small Ø Program: usually too large Requirements Plan Determine what works for you 51 Module B Module C Design Code Compile Typical: one or more classes or features Module A Compile Test Program and Project data Postmortem Software Engineering, lecture 11: CMMI 51
PSP 0. 1 PSP 2 Code reviews Design reviews PSP 1 Size estimating Test report PSP 0 Current process Time recording Defect type standard 52 PSP 2. 1 Design templates PSP 1. 1 Task planning Schedule planning PSP 0. 1 Objective: help you to Ø Measure size of programs that you produce Ø Perform size accounting for these programs Ø Make accurate and precise size measurements Coding standard Size measurement Process improvement proposal (PIP) Software Engineering, lecture 11: CMMI 52
Process measurement To be useful, measurements should be Ø Gathered for a specific purpose Ø Explicitly defined Ø Properly managed Ø Properly used We measure to Ø Understand manage change Ø Predict or plan Ø Compare one product, process, or organization with another Ø Determine adherence to standards Ø Provide a basis for control 53 Software Engineering, lecture 11: CMMI 53
Measurement objectives Measurements only produce numbers To be useful, they must Ø Relate to business objectives Ø Be properly interpreted Ø Lead to appropriate action If the business purposes for the measurements are not understood Ø The wrong data may be gathered Ø Data may not be properly used 54 Software Engineering, lecture 11: CMMI 54
PSP measurements Basic PSP data: Ø Program size Ø Time spent by phase Ø Defects found and injected by phase On every item, gather both actual and estimated data Measures derived from these data: Ø Support planning Ø Characterize process quality 55 Software Engineering, lecture 11: CMMI 55
PSP 1 PSP 2 Code reviews Design reviews PSP 1 Size estimating Test report PSP 0 Current process Time recording Defect type standard PSP 2. 1 Design templates PSP 1. 1 Task planning Schedule planning Objective: Establish orderly & repeatable procedure for size estimation PSP 0. 1 Coding standard Size measurement Process improvement proposal (PIP) New process elements: Ø PROBE size estimating method & template Ø Test report template 56 Software Engineering, lecture 11: CMMI 56
Estimating with PROBE Stands for PROxy Based Estimating Uses proxies to estimate program size and development time A good proxy helps make accurate estimates 57 Software Engineering, lecture 11: CMMI 57
The PROBE estimating method Conceptual design Start Identify and size the proxies Number of items Part Type Relative size Reuse categories Estimate other element sizes Estimate program size Calculate prediction interval Size estimate and range 58 Estimate resources Resource estimate and range Software Engineering, lecture 11: CMMI 58
Conceptual design relates the requirements to the parts needed to produce the program Parts categories: Ø Reused: Can be used as-is Ø Base: Exists, requires modifications Ø Added: needs to be developed
Sizing parts Reused part: Use actual size Added part: define proxy Ø Identify part type, e. g. parsing, GUI, network… Ø Estimate number of items, e. g. routines Ø Estimate relative size, i. e. very small, medium, large, or very large Ø Find size of an item of this part type and relative size in the relative size table Ø Estimated size = item size * number of items Base part: start from actual size; estimate additions, deletions, modifications
PSP 1. 1 PSP 2 Code reviews Design reviews PSP 1 Size estimating Test report PSP 0 Current process Time recording Defect type standard PSP 2. 1 Design templates PSP 1. 1 Task planning Schedule planning PSP 0. 1 Coding standard Size measurement Process improvement proposal (PIP) Objective: introduce & practice methods for Ø Making resource & schedule plans Ø Tracking your performance against them Ø Judging likely project completion dates Two new process elements: Ø Task planning template Ø Schedule planning template Typically used for projects that take several days or weeks 61 Software Engineering, lecture 11: CMMI 61
PSP 2 Code reviews Design reviews PSP 1 Size estimating Test report PSP 0 Current process Time recording Defect type standard PSP 2. 1 Design templates PSP 1. 1 Task planning Schedule planning PSP 0. 1 Coding standard Size measurement Process improvement proposal (PIP) Objective: introduce Ø Design & code reviews Ø Methods for evaluating and improving quality of reviews Two key capabilities added at this level: Ø Design and code reviews Ø Quality planning Two new process elements, separate: Ø Design review checklist Ø Code review checklist 62 Software Engineering, lecture 11: CMMI 62
Quality planning PSP 2 introduces quality planning. This involves estimating: Total number of defects that will be injected Ø Number of defects injected & removed in each process phase Ø Amount of time for design and code reviews Ø & adjusting these parameters to ensure high-quality result 63 Software Engineering, lecture 11: CMMI 63
Arguments for reviews over tests In testing, you must Ø Detect unusual behavior Ø Figure out what the test program was doing Ø Find where the problem is in the program Ø Figure out which defect could cause such behavior This can take a lot of time With reviews you Ø Follow your own logic Ø Know where you are when you find a defect Ø Know what the program should do, but did not Ø Know why this is a defect Ø Are in a better position to devise a correct fix 64 Software Engineering, lecture 11: CMMI 64
PSP review process principles Defined review process: guidelines, checklists, standards. Goal is to find every defect before first compile/test To meet it, you must: Ø Review before compiling or testing Ø Use coding standards Ø Use design completeness criteria Ø Measure and improve your review process Ø Use a customized personal checklist 65 Software Engineering, lecture 11: CMMI 65
Code reviews General principles (not specifically from PSP): Ø Uncoupled from evaluation process Ø Meeting must have chair, secretary Ø Chair is not supervisor Ø Purpose is to identify faults Ø Purpose is not to correct them Ø Purpose is not to evaluate developer; keep focus technical Ø Strict time limit (e. g. 2 hours) Ø Announced sufficiently long in advance Ø Participant number: 5 to 10 Ø Code available in advance, as well as any other documents Ø Meeting must be conducted professionally and speedily; chair keeps it focused 66 Software Engineering, lecture 11: CMMI 66
Code review checklist Reviews are most effective with personal checklist customized to your own defect experience: Ø Use your own data to select the checklist items Ø Gather and analyze data on the reviews Ø Adjust the checklist with experience Do the reviews on a printed listing, not on screen The checklist defines steps and suggests their order: Ø Review for one checklist item at a time Ø Check off each item as you complete it 67 Software Engineering, lecture 11: CMMI 67
Design review principles In addition to reviewing code, you should also review your designs Requires that you Ø Produce designs that can be reviewed Ø Follow an explicit review strategy Ø Review design in stages Ø Verify that logic correctly implements requirements 68 Software Engineering, lecture 11: CMMI 68
PSP 2. 1 PSP 2 Code reviews Design reviews PSP 1 Size estimating Test report PSP 0 Current process Time recording Defect type standard PSP 2. 1 Design templates PSP 1. 1 Task planning Schedule planning PSP 0. 1 Objective: introduce Ø Additional measures for managing process quality Ø Design templates that provide an orderly framework and format for recording designs Coding standard Size measurement Process improvement proposal (PIP) New process elements: Ø Design review script Ø Design review checklist Ø Operational specification template Ø Functional specification template Ø State specification template Ø Logic specification template 69 Software Engineering, lecture 11: CMMI 69
PSP: an assessment Ignore technology assumptions (strict design-code-compiletest cycle) which is not in line with today’s best practices. Retain emphasis on professional engineer’s approach: Ø Plan Ø Record what you do both qualitatively and quantitatively: § Program size § Time spent on parts and activities § Defects ØThink about your personal process Ø Improve your personal process Tool support, integrated in development environment, is essential. 70 Software Engineering, lecture 11: CMMI 70
Скачать презентацию Chair of Software Engineering Prof Dr Bertrand Meyer
e2fb128926228058adfc6ea2e3d09e3e.ppt