Comparison of CMM and CMMI
Walker Royce (unknown source)
This article summarizes some ideas from traditional software management techniques to modern software management technology. I have to recognize the Software Engineering Institute SEI's improvements in its new method CMMI (capability maturity model integration), and promote development company to properly apply this method. Although I have always supported the spirit of the original ability maturity model (CMM), it is actually incorrectly understood and applied. From the world-leading experience of the world-leading software development organization in 200 years, I believe that most of the organization of CMM is also limited to the default waterfall mode ideology. I don't think the wrong model itself, because I know some of the process improvements in the CMM context is based on a modern, superimposed development method. However, I have not been specific to this inspiration. CMM Summary Based on the support of the organization's key process domain, CMM defines five levels of software process maturity. Level 1 (initial grade) describes an organization that is immature, or is an undefined process. Level 2 (Repeatable), Level 3 (Defined Level), Level 4 (Management Level) and Level 5 (Optimization Level) The Software Process Maturity Level is described, respectively. And these levels related KPAs are: Level 2: Demand Management, Software Project Plan, Software Project Tracking and Monitoring, Software Substrumental Management, Software Quality Assurance, Software Configuration Management. Level 3: Organizational Level Process Focus, Organizational Level Process Definition, Training Outline, Integrated Software Management, Software Product Engineering, Group Coordination, Peer Review. Level 4: Quantitative Process Management, Software Quality Management Level 5: Defect Prevention, Technology Update Management, Process Change Management Most Organizational Basic Targets Get Level 3. One of the means of assessing the current maturity level of the organization is the software capability assessment (SCE). The SCE determines whether the organization is consistent by evaluating the software process (generally in the form of a policy) and project practice. The organization's process reflects the "work made by real records", project implementation (specific tailoring and interpretation of the process) should prove that "said". CMMI review software maturity model (CMM V1.0) was first developed by Software Engineering, and specifically proposed software process maturity. In 1990, the model was first released and used in many fields. The CMM of other disciplines has also been developed, such as system engineering, personnel, integrated product development, software procurement, etc. CMMI is seen as an integration of various CMMs into a series of models. The basic source model of CMMI includes: Software CMM 2.0 (Dragon C), EIA-731 System Engineering, and IPD CMM (IPD) 0.98A. CMMI also describes 5 different maturity levels. 1. Level 1 (initial grade) represents process maturity characteristics characterized by unpredictable results. The process includes some special methods, symbols, work and reaction management, and success depends mainly on the team's skills. 2. Level 2 (managed stage) represents process maturity of the characteristics that can be performed with repeatable items. Organization uses basic discipline for demand management, project plan, project supervision and control, supplier agreement management, product and process quality assurance, configuration management, and metrics. For level 2, the main process focus is in project level activities and practices. 3. Level 3 (Strict Definition Level) represents process maturity of performance as feature in organizational improvement projects. Emphasize the key process domain of the level 2, the project level discipline to establish an organization-level activities and practices. Additional organizational grade processes include: demand development: multi-stakeholder needs development.
Technical solutions: Expanded design and quality projects. Product Integration: Continuous Integration, Interface Control, Change Control. Verification: Ensure the correct assessment technology of the product. Confirm: Establish an assessment technology for establishing the correct product. Risk management: detection, priority, related issues, and unexpected solutions. Organizational training: establish a mechanism and cultivate more skilled people. Organizational Level Process Focus: Establish an organization-level framework for the project process. Decision analysis and program: an optional assessment of the system. Organization-Level Process Definition: Apply the process as a long-lasting development of organizations. Integrated Project Management: Unify various groups and stakeholders within the project. 4. Level 4 (Quantitative Management Level) Represents process maturity characteristics characterized by improving organizational performance. The historical results of the Level 3 project can be used alternately, and the results of the competition scale (cost, quality, time) in business performance are predictable. Level 4 Additional process domains include: Organizational Level Procedure: Perform setting specification and reference for the process. Quantitative project management: Implement projects based on the statistical quality control method. 5. Level 5 (optimization level) represents process maturity of organizational performance, and quantitative, continuous process improvement. Additional level 5 Process domains include: causal analysis and solution: Actively avoid errors and intensive best practices. Organizational Level Reform and Implementation: Establish a learning organization that can organically adapt and improve. Is CMM outdated? Some problems with CMM practices are also symptoms of traditional waterfall methods and excessive process management. CMM's activity-based metrics and waterfall processes are in order, and there is very close contact based on the activity management specifications (ie: first demand activity, then design activities, encoding activities, unit test activities, integration activities, and system reception test). This probably explains why many organizations have stayed in the CMM's ideology. In addition, superimposed development technology, software industry best practice, and economic motivation promotion organizations adopt results: development business cases, ideals and prototyping programs; after refining, the baseline structure is included, it can be published, and finally the release of live versions . Although CMMI retains activity-based methods, it independently integrates many modern best practices in the software industry, so it has largely dilutes the links between the waterfall ideas. Analysis of the link between CMM and CMMI and the waterfall model and the superiors, the method is to see if the KPA of each model has inspired the reasonable software management principles for these two different development methods. First, let us define those software management principles. In the past 10 years, I compiled two sets of principles: a set of traditional waterfall methods, another set of modern alarms. It is to recognize that this "Ten Principles" have no scientific foundation, and only the rough description of the successful template that meets their respective management methods. But they really provide a suitable framework for my point: CMM and waterfall ideas, while CMMI and superimposed ideas are tight. 1. Freeze demand before design. This is the essence of the first process of demand: The project team strives to provide an accurate demand definition, then strictly follow the requirements. Demand changes will seriously damage the coding and testing phases, so the project team must fully and clearly designate the demand before investing in major strengths in other design and development activities. 2. Avoid encoding before detailed design review. Coding changes will seriously damage the coding and test phases, before starting the encoding, if there are still many change resistance, the project group must ensure that the entire design is mature and complete. 3. Yes use a higher instruction programming language.
Higher instruction programming language avoids a range of major error roots (through advanced data entry, interface separation, packaging and programming structure), and allows software solutions to program with fewer synthesis codes. 4. End the unit test before integration. Although the design is from the top, the test process is from bottom to: the smallest unit is fully tested before the integration test is delivered. Such order limits are to discover defects at some unit levels prior to integration, otherwise they will cause more problems and rework. 5. Maintain all products trackability. To ensure the integrity and consistency of the project in each stage, it is necessary to track the demand products and design and test products. This provides a complete view of the actual impact of the review and the potential impact of the actual impact of the review. 6. Documentation and maintenance design. No documentation is designed. In the later stage, since the code is a major engineering product, the design product must be updated to ensure consistency, and provide the basis for the change decision. 7. Evaluate quality by an independent team. The project group should designate an independent team to ensure the comprehensive quality consistency of the products and processes to maintain an independent report channel with different analysts, designers and tester. 8. Comprehensive inspection. By checking the detailed design and code to find errors, it is much better than the error through the test. To ensure checking all the needs, design, code, and test products. 9. Perform a comprehensive precise plan in the early stage of the project. For identification critical paths, management risks, and evaluation procedures, a complete, precise, refinement plan is necessary, which should arrange the entire progress of the progress and products. 10. Strictly control the source code baseline. Once the product enters the coding phase, the officially released baseline control of the test process must be managed in a strict configuration management, and the product is converted into the zero defect state suitable for the release. The top ten principles of modern (overlapping) software management 1. First focus on structural processes. This requires a balanced operational demand before the organization's commitment to fully develop sufficient resources, and it is important for design decisions, as well as lifecycle plans. 2. Use the superfined life cycle in early defense risk. A stacked process is needed to better understand the problem, form a valid program and effective plan to ensure balance to treat all stakeholders. The main risks should be proposed early to increase predictability, avoiding the subsequent problem and rework. 3. Emphasize components based on components. In order to reduce the number of artificial synthetic source code and customary development, the project team must transfer from the code line idea within the existing structural framework to component-based ideas. The component is the attachment portion of the existing code line, with a defined interface and behavior, exists in the source code or in executable format. 4. Establish a change management environment. The dynamics of superiors include concurrent workflows because different working groups are working for shared products. This requires objective control baseline for all project members. 5. Use a circular engineering tool to make changes more free. The circular engineering provides various formats (such as: demand instructions, design models, source code, and executable code), auto engineering and synchronous engineering information necessary for environmental support. It is difficult to simplify the overlay cycle into manageable, allowing and encouraging changes to manageable, allowing and encouraging changes. The freedom of product change in the superfine process is required because it clears a major source of the engineering team friction. 6. Use strict, model-based design symbols. Model-based approach (for example: UML) supports the design symbol of the text and text. Relative to the traditional manual review and paper documentation, the visual model of the machine handling language allows for more objective assessments. 7. The means of the objective quality control of the process. The process and the lifecycle assessment of all intermediate products must be tight into the product, and the defined metrics are integrated into all activities and groups. 8. Demo-based evaluation using intermediate products.
Convert the current product status (whether early prototype, baseline structure, or β capability) into related usage cases to promote integrated conversion earlier, more practical understanding of design weighing, and more Early eliminate product defects. 9. Release refinement, expanded plans. In the operation context of the system, the early sustained demonstration of the software management process is critical, that is, its cases. The increase in each item and the demo should reflect the current demand and structure. The case of using the case is an important mechanism for organizational needs, defining superflative content, evaluating implementation, and organization reception testing. 10. Create an upgradeable, configurable process. No process is suitable for all software development projects. Reality said that a process framework must be configurable and suitable for wide range of applications. In order to ensure the return of economic level and investment, organizations must instill a general process "spirit", so all projects can integrate a series of general best practices, especially project management, independent workflow, checkpoint, metrics and The best practice of the product. Various items should also be allowed to cut and specify in order to implement the project-specific context optimization process. The relationship between CMM and two management principles Table 1 identifies which of each of the principles are directly excited by KPA of CMM. These are my judgment, combined with many colleagues of Rational, but there is no scientific basis. Also, remember that these principles are not only cmm, but also based on the observation and organization level of the default practice. Table 1: CMM how to stimulate software management principles Waterfall principles CMM excitation stacking principles CMM excitation color Description: Green: CMM direct stimulating tissue Application These principles Blue: CMM is neutral, ie, no direct excitation, nor hinders Organizational application These principles red: CMM hinders the organization to apply these principles 1. Refrigeration requirements before design 2. Avoid encoding before detailed design 3. Programming language using higher instructions 4. Test 5. Maintain all products Details Traceability 6. Documentation and Maintenance Design 7. Evaluate Quality 8. Comprehensive inspection 9. Comprehensive inspections 9. Comprehensive and accurate plans in early projects. 10. Strictly control the source code baseline. 1. First pay attention to the structural process. 2. Use the superfined life cycle in early defense risk. 3. Emphasize components based on components. 4. Establish a change management environment. 5. Use a circular engineering tool to make changes more free. 6. Use strict, model-based design symbols. 7. The means of the objective quality control of the process. 8. Demo-based evaluation using intermediate products. 9. Release refinement, expanded plans. 10. Create an upgradeable, configurable process. As shown in Table 1, the critical process of CMM directly inspired most of the traditional principles, but there is little impact on modern principles. In my opinion, some modern principles actually conflict with the CMM key process domain. I think this form will trigger a fierce argument in the process improved fanatics, but I believe that most engineers and project managers in the final software development project will agree with my conclusion. CMMI and modern management principles are now, let us look at CMMI. If I do a rough analysis, I will get the results of Table 2. Table 2: How CMMI stresses the principles of superfine software management
Connection of CMMI and superiode 1. First focus on structural processes. 2. Use the superfined life cycle in early defense risk. 3. Emphasize components based on components. 4. Establish a change management environment. 5. Use a circular engineering tool to make changes more free. 6. Use strict, model-based design symbols. 7. The means of the objective quality control of the process. 8. Demo-based evaluation using intermediate products. 9. Release refinement, expanded plans. 10. Create an upgradeable, configurable process. Please note that my analysis is still observing based on the industry's default practices, not the purpose of CMMI. Our links in this and traditional methods and organizational culture will become obstacles to the true purpose of CMMI, so I have a conservative attitude towards me. Obviously, my point of view is that CMMI represents the main improvement.
