Introduction To CMM

Introduction To CMM Dated: August 29, 2009 1 Why CMM  Ensures quality delivery on time  Ensures productivity and profitability  Ensures repetition of success stories  Makes the organization acceptable and reliable 2 A Mature Process  Consistent with the way work actually gets done: – Defined, documented and continuously improving – Understood, used, living  Supported visibly by management  Well controlled process, enforced and audited  Disciplined use of technology 3 Institutionalized Process ‘That’s the way we do things around here.’  The organization builds an infrastructure that contains effective, usable and consistently applied processes.  The organization culture must convey the process.  Management must nurture the process.  Institutionalized processes endure after people who originally defined them have gone. 4 Benefits of Model Based Improvement  Establishes a common language  Forges a shared vision  Builds on a set of processes and practices developed with input from a broad selection of the software community  Provides a framework for prioritizing actions  Provides a framework for performing reliable and consistent appraisals  Supports industry-wide comparisons 5 What Is CMM?  A commonsense application of process management and quality improvement concepts to software development and maintenance.  A community developed guide.  A model for organizational improvement.  The underlying structure for reliable and consistent CMM-based appraisal methods. 6 The 5 Levels of CMM  Initial level  Repeated level  Defined level  Managed level  Optimized level 7 Initial Level  Performance driven by the competence and heroics of the people doing the work.  High quality and exceptional performance possible so long as the best people can be hired.  Unpredictable – for good or ill.  The major problems facing the software organization are managerial, not technical. 8 Repeatable Level  The predominant need is to establish effective software project management  Software project management processes are documented and followed  Organizational policies guide the projects in establishing management processes  Successful practices developed on earlier projects can be repeated 9 Defined Level  This level builds on the software project management foundation.  To control a process, it must be defined, documented and understood.  The outputs of one task flow smoothly into the inputs of the next task.  At this level, the organization builds processes that empower the individuals doing the work. 10 Managed Level  Apply the principles of statistical process control – Address the special causes of process variation 11 Optimizing Level  Identify and eliminate chronic causes of poor performance  Continuously improve the software process 12 Key Process Areas  Goals – Key practices. – Should know fundamental policies, procedures and activities for a key process area. – ‘What’ is to be done is more important than ‘how’ it is to be done. – Key practices are organized by common feature. – 316 key practices in CMM. 13 Moving From Level 1 to Level 2  At level 1 the organization gets the job done  At level 2, A software project management system is in place  The organization sets expectations via policies  Level 2 projects have disciplined process 14 15 RM Key Practices  Goal # 1: system requirements allocated to software are controlled to establish a baseline for software engineering and management Requires that  Activity # 1: the software engineering group reviews the allocated requirements before they are incorporated into the software project 16 RM Key Practices  Goal # 2: software plans, work products and activities are kept consistent with the system requirements allocated to software Requires that  Activity # 2: the software engineering group uses the allocated requirements as he basis for software plans, work products and activities  Activity # 3: changes to the allocated requirements are reviewed and incorporated into the software project 17 RM Relationships to Level 2  SPP  SPTO  SCM  SQA 18 Barriers to RM  Inadequate knowledge  Communication barrier 19 Software Project Planning  A software development plan specifies many or all of the following – The project’s chosen software life cycle – A list of work products to be developed – Schedules – Estimates for level of effort (number of people) cost etc – Facilities support tools and hardware – Project risks 20 Developing a Software Plan  There may be separate documents entitled: – Software development plan – Software quality assurance plan – Software configuration management plan – Risk management plan – Software test plan – Project training plan Or these plans may be combined into one document 21 SPP Key Practices  Goal # 1 software estimates are documented for use in planning and tracking the software project Requires that  Activities # following estimates are done according to a documented procedure – Estimates for size (or changes) of work products – Estimates for effort and cost of the software project – Estimates for project’s critical computer resources – Estimates for project’s software schedule And software planning data are recorded 22 SPP Key Practices Goal # 2 software project activities and commitments are planned and documented Requires that Activities # SDLC is identified  SDP prepared according to a documented procedure  The plan for the software project is documented  Software work products are identified  The risks are identified  Plan for the project’s software engineering facilities 23 and support tools are prepared  SPP Key Practices Goal # 3 affected groups and individuals agree to their commitments related to the software project Requires that Activities # SEG participates on the project proposal team SEG participates with other affected groups Commitments are reviewed with senior management according to a documented procedure 24 SPP Relationships  RM provides basis for SDP  SPTO provides basis for reviewing the SPP activities  SCM provides basis for managing and controlling planning data  SQA reviews/audits the activities and SPP work products 25 Software Project Tracking Oversight  If and when discrepancies between plans and actual progress occur, a judgment is to be made about whether to: – Change the way the work is being done – And/or adjust the plans Archives of original and adjusted plans should be kept 26 SPTO Key Practices Goal # 1 actual results and performances and tracked against software plans Requires that Activities # Use of SDP for tracking the software activities and communicating status Size of work products (or changes) are tracked and corrective actions are taken as necessary SEG conducts periodic internal reviews to track technical progress, plans, performances and issues against SDP Formal reviews at selected milestones according to a documented procedure 27 SPTO Key Practices Goal # 2 corrective actions are taken and managed to closure when actual results and performance deviate significantly from software plan Requires that Activities # SDP is revised according to a documented procedure Size of work products (or changes) is tracked and corrective actions are taken as necessary 28 Barriers to SPTO  What are the barriers to SPTO?  Points to ponder: – How do you know if you can meet commitments – – – – without tracking the plan? Can you manage your project without an updated plan? What can happen if commitments are not renegotiated when they are known to be not achievable? What can happen if renegotiated commitments are not communicated to affected parties? What can happen if replanning data are not recorded? 29 Software Quality Assurance (SQA)  The value of SQA is that it provides an independent view of the project’s activities, processes, and products.  SQA servers as the ‘eyes and ears’ of management.  Most key process areas contain SQA practices in verifying implementation. 30 SQA Key Practices  Goal # 1software quality assurance activities are planned Requires that – Activity # 1: a SQA plan is prepared for the software project as per a documented procedure – Activity # 2: the SQA group’s activities are performed in accordance with the SQA plan 31 SQA Key Practices – Goal # 2 adherence of software products and activities to the applicable standards, procedures, and requirements is verified objectively Requires that     Activity # 2: the SQA group’s activities are performed in accordance with the SQA plan Activity # 3: the SQA group participates in the preparation and review of the projects software development plan, standards and procedures Activity # 4: the SQA group reviews the project’s activities to verify compliance Activity # 5: the SQA group audits designated software work products to verify compliance 32 SQA Key Practices – Goal # 3 affected groups and individuals are informed of software quality assurance activities and results Requires that – Activity # 6: the SQA group periodically reports the results of its activities to the software engineering group – Activity # 7: deviations identified in the software activities and work products are documented and handed according to a documented procedure – Activity # 8: the SQA group conducts periodic reviews of its activities and finding with the customer’s SQA personnel, as appropriate 33 SQA Key Practices  Goal # 4 noncompliance issues that cannot be resolved within the software project are addressed by senior management Requires that – Activity # 7: deviations identified in the software activities and work products are documented and handed according to a documented procedure 34 Barriers to SQA  Are there any barriers?  Points to ponder: – How do you objectively know if you are in control of your quality requirements? – Have you ever missed your objectives and not had the time to take corrective action against the problem – How are unresolved noncompliances tracked and kept visible 35 Software Configuration Management (SCM)  To establish and maintain the integrity of the products of the software project throughout the software life cycle Involves: – Identifying configuration items/units – Systematically controlling changes – Maintaining integrity and trace-ability of the configuration throughout the software life cycle 36 SCM  SCM provides a stable working environment  Uncontrolled change of work products is a chaotic process  SCM provides a memory of the status of software work products via baselines  When many individuals are working on the same product SCM coordinates access to and change of the software work products – The SCM key process areas can be satisfied using only baseline configuration management 37 SCM Key Practices  Goal # 1: SCM activities are planned Requires that  Activity # 1: SCM plan is prepared for each software project according to a documented procedure  Activity # 2: documented and approved SCM plan is used as the basis for performing the SCM activities 38 SCM Key Practices – Goal # 2: selected software work products are identified, controlled, and available Requires that     Activity # 2: documented and approved SCM plan is used as the basis for performing the SCM activities Activity # 3: a configuration management library system is established as a repository for the software baselines Activity # 4: the software work products to be placed under configuration management are identified Activity # 7: products from the software baseline library are created and their release is controlled according to a documented procedure 39 SCM Key Practices  Goal # 3: changes to identified software work products are controlled Requires that – Activity # 5: change requests and problem reports for all configuration items/units are initiated, recorded, reviewed, approved and tracked according to a documented procedure – Activity # 6: changes to baselines are controlled according to a procedure 40 SCM Key Practices  Goal # 4: affected groups and individuals are informed of this status and content of software baselines Requires that – Activity # 8: the status of configuration items/units is recorded according to a documented procedure – Activity # 9: standard reports documenting the SCM activities and the contents of the software baseline are developed and made available to affected groups and individuals – Activity # 10: software baseline audits are conducted according to a documented procedure 41 Barriers to SCM  Are their any barriers?  Points to ponder: – How otherwise do you control the various parts of your products and projects? – How do you assure that integration is complete? – Have you ever experienced a lost or down-level part? – How are changes managed and controlled? 42 Level 2 Summary  RM – Control system requirements allocated to software to establish the baseline – Keep software plans, products, and activities consistent with the system requirements allocated to software  SPP – Document estimates – Develop and document plans – Establish commitments 43 Level 2 Summary  SPTO – Manage according to a plan – Take corrective action – Renegotiate commitments and adjust the plan  SQA – Plan SQA activities – Review and/or audit software product and processes – Report results – Escalate noncompliance issues that cannot be resolved 44 Level 2 Summary  SCM – Plan SCM activities – Identify and maintain configuration items – Systematically control changes – Maintain integrity and trace-ability of baseline throughout the software life cycle 45 Moving From Level 2 to Level 3  At level 2 the focus is on projects  At level 3 the focus shifts to the organization – Best practices are gathered across the organization – Processes are tailored as appropriate  The organization supports the projects by establishing – Common process – Common measurements – Training 46 KPAs For The Defined Level  Peer reviews  Intergroup coordination  Software product engineering  Integrated software management  Training program  Organization process definition  Organization process focus 47 Organization Process Focus (OPF)  A dedicated group of people is responsible for the organization’s software process activities (SEPG)  Maintaining the organization’s software process database and providing training about the organization’s software process 48 OPF Key Practices  Goal # 1: software process development and improvement activities are coordinated across the organization Requires  Activity # 3: coordination at organizational level  Activity # 4: use of organization’s process database  Activity # 5: new processes are monitored, evaluated and transferred to other parts of the organization  Activity # 6: training for project’s and organization’s processes is coordinated across 49 organization OPF Key Practices  Goal # 2: the strengths and weaknesses of the software processes used are identified relative to a process standard Requires that  Activity # 1: processes assessed periodically and action plans developed to address the findings 50 OPF Key Practices  Goal # 3: organizational level process development and improvement activities are planned Requires that  Activity # 2: the organization develops and maintains a plan for its software process and development and improvement activities 51 Barriers to OPF  Discuss the barriers.  Points to ponder: – Focused and coordinated process improvement. – Understanding of process capability. – Increased process capability. – Planned improvements. 52 Organization Process Definition (OPD)  Process elements are described in terms of standards, procedures, templates abstractions etc which can be hooked together to form a process  OPD and OPF are tightly coupled  Organization process focus focuses on WHO  Organization process definition focuses on WHAT 53 OPD Key Practices  Goal # 1: a standard software process for the organization is developed Requires that – Activity # 3: the organization’s standard software process is developed and maintained according to a documented procedure – Activity # 4: the organization’s standard software process is documented according to established organization standards 54 OPD key practices  Goal # 2: information related to the use of the organization’s standard processes is collected, reviewed and made available Requires that – Activity # 5: the organization’s software process database is established and maintained – Activity # 6: a library of software process related documentation is established and maintained 55 Barriers to OPD  What are they?  Paybacks stem from: – Process assets and baseline for continuous process – – – – – improvement Process database Tailoring guidelines Reduce defects/costs Improve schedule More easily move personnel between projects enabled for reuse 56 Training Program (TP)  Software training is identified, developed and established by an organization training group  The training group – Begins by reviewing each software project’s training needs and plans – Analyses the skills needed by the organization and how and when need training will occur – Prepares, develops and maintains training courses – Maintains training records 57 Training Program (TP)  At level 2, the phrase receive training is used  Training at level 2 may not be institutionalized across the organization  At level 3 and above the phase receive required training is used  Institutionalization of training is expected 58 TP Key Practices  Goal # 1 training activities are planned Requires that  Activity # 1: each SW project develops and maintains a training plan that specifies its training needs  Activity # 2: the organization’s training plan is developed and revised according to a documented procedure  Activity # 3: the training for the organization performed as per the OTP 59 TP Key Practices  Goal # 2 training for developing skills and knowledge needed to perform software management and technical roles is provided Requires that  Activity # 3: the training for the organization performed as per the OTP  Activity # 4: training course prepared at the organizational level are developed. Plan is developed and maintained as per the organization 60 standards TP Key Practices  Goal # 3 individuals in the SEG and other groups receive the training necessary to perform their roles Requires that  Activity # 5 a waiver procedure for required training is established and used to determine whether individuals already possess the knowledge and skills required to perform in their designated roles 61  Activity # 6: records of training are maintained Barriers to TP  What are they?  Paybacks stem from: – Skilled and knowledgeable personnel – Increased flexibility for assignments 62 At level 3, each project tailors the organization’s standard software process for its particular needs  Includes software life cycles, standards, procedures etc  Uses the lessons learned and data from previous projects  Feeds back appropriate measurement data and documents to the organization for use by other projects  63 Integrated Software Management (ISM) ISM Key Practices  Goal # 1 the project’s defined software process is a tailored version of organization’s standard software process Requires that  Activity # 1: the project’s defined software process is developed by tailoring the organization;S standard software process according to a documented procedure  Activity # 2: each project’s defined software process is revised according to a documented procedure  Activity # 3: the project’s SDP which describes the use of the project’s defined software process, is developed and 64 revised according to a documented procedure ISM Key Practices  Goal # 2 the project is planned and managed according to the project’s defined software process Requires that  Activity # 3: the project’s SDP which describes the use of the project’s defined software process, is developed and revised according to a documented procedure  Activity # 4: the software project is managed in accordance with the project’s defined software 65 process ISM Key Practices  Goal # 2 the project is planned and managed according to the project’s defined software process Requires that  Activity # 5: the organization’s software process database is used for planning and estimation  Activity # 6: the size of software work products is managed according to a documented procedure 66 ISM Key Practices  Goal # 2 the project is planned and managed according to the project’s defined software process Requires that  Activity # 7: the project’s software effort and cost are managed according to a documented procedure  Activity # 8: the project’s critical computer resources are managed according to a documented procedure  Activity # 9: the critical dependencies and critical paths of the project’s software schedule are managed according to a documented procedure 67 Barriers to ISM  What are they?  Paybacks stem from: – Flexible process to meet project’s needs – SDP integrated with higher capability and knowledge – Processes optimized at project level 68 Software Product Engineering (SPE)  Requires – SDLC processes – Documentation – Consistently and traceability 69 SPE Key Practices  Goal # 1 the software engineering tasks are defined, integrated and consistently performed to produce the software Requires that  Activity # 1: appropriate software engineering methods and tools are integrated into projects defined software process  Activity # 2: the software requirements are developed, maintained, documented and verified by systematically analyzing the allocated requirements according to the project’s defined software process  Activity # 3: the software design is developed, maintained, documented and verified according to the project’s defined software process to accommodate the software requirements 70 and form the framework for coding SPE Key Practices  Goal # 2 software work products are kept consistent with each other Requires that  Activity # 10: consistency is maintained across software work products, including the software plans, process descriptions, allocated requirements, software requirements, software design, code, test plans, and test procedures 71 Barriers to SPE  What are they?  Paybacks stem from: – Consistency across work products  Enables reuse  Reduces defect repair  Enables defect prevention – Defect data being used more effective use of tools / methods 72 Intergroup Coordination (IC)  The software engineering group actively interfaces with a variety of groups  Examples of these groups, to whom the interface must be managed include: – – – – – Systems engineering Marketing Training Subcontract management Documentation Intergroup coordination is the first step on the road to Concurrent engineering 73 IC Key Practices  Goal # 1 the customer’s requirements are agreed by all affected groups Requires that  Activity # 1: the software engineering group and other engineering groups participate with the customer and end users, as appropriate, to establish the system requirements 74 IC Key Practices  Goal # 2 the commitments between the engineering groups are agreed by the affected groups Requires that – Activity # 3: a documented plan is used to communicate intergroup commitments and to coordinate and track the work performed – Activity # 4: critical dependencies between engineering groups are identified, negotiated, and track the work performed – Activity # 5: work products produced as input to other engineering groups are reviewed by representatives of the receiving groups to ensure that the work products meet their needs 75 IC Key Practices  Goal # 3: the engineering groups identify, track, and resolve intergroup issues Requires that  Activity # 2: representatives of the project’s software engineering group work with representatives of other engineering groups to monitor and coordinate technical activities and resolve technical issues 76 Barriers to IC  What are they? Alternatives?  Paybacks stem from: – – – – – – Issues do not drag on unresolved and impede progress Dependencies more likely to be met on time Commitment channels commonly understood Ability to reach persons you need Improved team work helps morale Commitments between groups made visible and understood by group members – Cross group knowledge increases – Affected groups are involved with customers to better serve them 77 Peer Reviews (PR)  Performing peer reviews: – Plan and schedule peer reviews – Train leader and participants – Give materials to reviewers in advance – Assign each reviewer a specified role – Specify criteria to begin and reviews – Use pre-planned checklists – Identify action items and track to closure – Collect and analyze data for product and peer review process 78 PR Key Practices  Goal # 1 peer review activities are planned Requires that  Activity # 1: peer reviews are planned, and the plans are documented 79 PR Key Practices  Goal # 2 defects in software work products are identified and removed Requires that  Activity # 2: peer reviews are performed according to a documented procedure  Activity # 3: data on the conduct and results of the peer reviews are recorded 80 Barriers to PR  What are they? Alternatives?  Paybacks stem from: – Defects found earlier – Defects found at a lower cost – Data available to guide test – Data available for use in defect removal models 81 Level 3 Summary  Emphasis shifts to organization  Organization process focus: – Coordinate software process improvement activities – Identify strengths and weaknesses of processes – Plan organization’s software process improvement efforts 82 Level 3 Summary  Organization Process Definition – Develop and maintain an organization’s standard software process (OSSP) – Collect, review, and distribute data and documents related to the OSSP  Training Program – Plan organizational training activities – Provide training for developing skills and knowledge for the organization – Ensure that individuals are trained 83 Level 3 Summary  Integrated Software Management – Develop the project’s defined software process – Manage the project according to a plan which includes the project’s defined software process  Software Product Engineering – Perform software activities in a defined, integrated, and consistently manner – Ensure consistency between products 84 Level 3 Summary  Intergroup Coordination – Involve all affected groups – Ensure commitments are agreed to by all affected parties – Identify, track, and resolve intergroup issues  Peer Reviews – Plan peer review activities – Identify and remove defects 85