Comparison between CMM and cmme

Author: wokel rosyes (general manager, vice president of strategic service, Rational Software Company)

This article summarizes some ideas on the transition from traditional software management technology to modern software management technology. In particular, I would like to acknowledge the improvements made by the Software Engineering Institute sei in its new approach cmme (Capability Maturity Model Integration) and promote development companies to correctly apply this approach. Although I have always supported the spirit of the original Capability Maturity Model (CMM), it is often incorrectly understood and applied. From my 25 years of cooperation experience with many of the world's leading software development organizations for process improvement, I believe that most organizations that use CMM are limited to the default Waterfall Model concept. I don't think it's wrong with the pattern itself, because I know that some process improvements in the CMM context are based on a modern, stacked development method. However, my understanding of adequacy is not a standard.

CMM Overview
Based on the organization's support for key process domains, CMM defines five levels of software process maturity. Level 1 (initial level) describes the organization of immature or undefined processes. Level 2 (repeatable), Level 3 (defined level), Level 4 (Managed Level), and level 5 (optimized level) Describe the organizations with increasing software process maturity levels. KPA related to these levels are:
Level 2: requirement management, software project plan, software project tracking and monitoring, software sub-contract management, software quality assurance, and software configuration management.
Level 3: Organization-level process focus, organization-level process definition, training syllabus, integrated software management, software product engineering, inter-group coordination, and peer review.
Level 4: Quantitative Process Management and software quality management
Level 5: Defect Prevention, technical update management, and process change management
The basic goal of most organizations is to reach maturity level 3. One of the ways to assess the current maturity level of an organization is the Software Capability Evaluation (SCE ). SCE evaluates the software process (generally in the form of a policy statement) and project practice to determine whether the organization is consistent in words and deeds. The organizational process shows "recording the work done truthfully", and the project implementation (specific tailoring and interpretation of the Process) should prove "to be done ".

Overview
The software Maturity Model (CMM V1.0) was first developed by the Software Engineering Institute, and the software process maturity was proposed in particular. This model was first released in 1990 and has been successfully adopted and used in many fields. CMM has also been developed in other disciplines, such as system engineering, personnel, integrated product development, and software procurement.
Cmme is considered to integrate various CMM into a series of models. The basic source model for cmme includes: Software CMM version 2.0 (Draft C), EIA-731 system engineering, and ipd cmm version 0.98a. Cmme also describes five different maturity levels.
1.Level 1 (initial level)It represents the process maturity characterized by unpredictable results. The process includes some special methods, symbols, work and response management. Success mainly depends on the skills of the team.
2.Level 2 (Managed Level)It represents the process maturity characterized by repeated project execution. Organize the use of basic discipline for demand management, project planning, project supervision and control, supplier agreement management, product and process quality assurance, configuration management, and measurement and analysis. Level 2 focuses on project-level activities and practices.
3.Level 3 (strictly defined level)It represents the process maturity characterized by improving project execution within the Organization.
Emphasize the consistency of project-level discipline in key process domains of level 2 to establish activities and practices at the organizational level. Additional organization-level process domains include:
Demand development: demand development for multiple stakeholders.
Technical solution: Design and Quality Engineering.
Product integration: continuous integration, interface control, and change control.
Verification: ensures that the evaluation technology is correctly established for the product.
Validation: ensure the establishment of correct product evaluation techniques.
Risk management: detection, priority, related problems and unexpected solutions.
Organization-level training: Establish a mechanism to train more skilled personnel.
Organization-level process focus: establishes an organization-level framework for the project process definition.
Decision Analysis and Solution: Optional evaluation of the system.
Organization-level process definition: processes are considered as persistent development assets of an organization.
Integrated Project Management: unify various groups and stakeholders within the project.
4.Level 4 (quantitative management level)It represents the process maturity that improves the organizational performance. The historical results of Level 3 projects can be used in turn, and the results are predictable in terms of the competitive Scale (cost, quality, time) of business performance. Level 4 additional process domains include:
Organizational Process Execution: sets standards and benchmarks for process execution.
Quantitative Project Management: projects are implemented based on statistical quality control methods.
5.Level 5 (optimization level)It represents the organizational performance that can be quickly reconfigured, and the process maturity that features quantitative and continuous process improvement. Additional Level 5 process domains include:
Cause and effect analysis and solutions: proactively avoid errors and strengthen best practices.
Organizational reform and implementation: Establish a learning organization that can adapt and improve organically.

Is CMM outdated?
Some problems with CMM practice are also the symptoms of traditional waterfall methods and excessive process-based management. The activity-based measurement method of CMM is closely related to the orderly and activity-based management norms of the waterfall process (that is, the requirement activities, the design activities, and the coding activities, unit test activity, integration activity, and System Acceptance Test ). This probably explains why many organizations have a deep understanding of CMM in waterfall thinking.
In addition, the stacked development technology, software industry best practices, and economic motives promote organizations to adopt a result-based approach: developing business cases, ideas and prototype solutions; after refinement, the baseline structure and available release will be included, and the release will be finalized as the release of the on-site version. Although cmme retains its activity-based approach, it does integrate many of the best practices in the software industry in modern times, so it largely fades out the connection with waterfall ideas.
Analyzes the relationship between CMM and cmme, waterfall model, and stacked development, one way is to check whether the KPA of each model inspires reasonable software management principles for these two different development methods. First, let's define the software management principles. In the past 10 years, I have compiled two sets of principles: one for the traditional waterfall method and the other for the modern stacked method. It must be admitted that these "Top Ten Principles" have no scientific foundation and only provide a rough description of successful templates that match their respective management methods. However, they do provide a suitable framework for my point of view: CMM is associated with waterfall ideas, while cmme is more closely associated with stacked ideas.
1. freeze requirements before design. This is the essence of the first requirement process: the project team strives to provide an accurate requirement definition, and then strictly follows the requirements. Demand changes seriously damage the coding and testing phase. Therefore, before the project team invests major efforts in other design and development activities, it is necessary to specify the requirements completely and clearly.
2. Avoid coding before detailed design review. The code change will seriously damage the coding and testing phase. If there is still a lot of resistance to the change before the Code starts, the project team must ensure that the entire design is mature and complete.
3. Use a higher instruction programming language. Higher instruction programming languages avoid a series of major error sources (through advanced data input, interface separation, and packaging and programming structures ), and allows software solutions to be programmed with less human synthetic code.
4. Complete the unit test before integration. Although the design is from top to bottom, the test process is from bottom to top: Before the integration test is delivered, the smallest unit is fully tested first. Such order restrictions aim to discover more defects at the unit level before integration, otherwise they will cause more problems and rework.
5. Maintain the trackability of all products. To ensure project integrity and consistency at each stage, we need to track demand products and design and test products. When a change is proposed or the development frontline staff identifies the change, this provides a complete view of the actual impact and potential impact of the change on the review.
6. Document and maintain the design. No documented design is not a design. In the future, as code becomes the main engineering product, the design product must be updated to ensure consistency and provide the foundation for decision-making.
7. An independent team should evaluate the quality. The project team should designate an independent team to ensure full quality consistency of products and processes, so as to maintain an independent reporting channel different from analysts, designers and testers.
8. Comprehensive check. It is much better to identify errors by checking the detailed design and code. Make sure that the check covers all requirements, designs, code, and testing products.
9. complete and precise planning at the early stage of the project. For identifying key paths, managing risks, and evaluating program changes, a complete, precise, and refined plan is necessary. It should arrange detailed activities and products of the entire progress.
10. Strictly control source code baselines. Once the product enters the coding stage, it must use strict configuration management to maintain the baseline control for the formal release of the test process, and convert the product to a zero-Defect State suitable for release.

Ten Principles of Modern (stacked generation) software management
1. Pay attention to the structure process first. This requires balancing operational needs, design decisions that are important to the structure, and life cycle plans before the Organization promises to fully develop sufficient resources.
2. Use stacks to defend against risks in the early stages. A stacking process is needed to better understand the problem and form an effective solution and an effective plan to ensure a balanced treatment of all stakeholder goals. Primary risks should be raised in the early stages to improve predictability and avoid high costs for subsequent problems and rework.
3. Emphasize component-based development. In order to reduce the number of artificial source code synthesis and habitual development, the project team must transfer the idea of code lines from the existing structure framework to the idea of component-based. A component is an attachment to an existing code line. It has defined interfaces and behaviors in source code or executable format.
4. Establish a change management environment. The dynamics of stack-based development include concurrent workflows because different working groups work for shared products. This requires objective baselines for reference by all project members.
5. Use cyclic engineering tools to make changes more free. Cyclic engineering provides environment support required for automatic engineering and synchronization of engineering information in various formats (such as requirement statement, design model, source code, and executable code. Without actual automatic operations, it is difficult to simplify the stack generation cycle into manageable time frames that allow and encourage changes. The freedom to change products is required during the stacking process because it removes a major source of engineering group friction.
6. Use strict model-based design symbols. Model-based methods (such as UML) Support semantic-rich graphical and text design symbols. Compared with traditional manual reviews and inspection of specific design performance of paper documents, visual models with strict symbols and formal and machine processing languages allow for more objective evaluations.
7. Provide objective quality control measures for the process. The process and the Life Cycle Evaluation of all intermediate products must be closely integrated into the product, and the defined measurements obtained directly from the expanded engineering products should be integrated into all activities and groups.
8. Demo-based evaluation using intermediate products. Converts current product status products (whether early prototypes, baseline structures, or beta capabilities) into executable demos of related use cases to facilitate integration conversion to occur earlier, A more effective understanding of design trade-offs and early elimination of product defects.
9. Release a detailed and expanded plan. In the operating context of the system, the early continuous demonstration of the software management process is crucial, that is, its use cases. The increase and demonstration of each project should reflect the detailed level of current requirements and structure. Use Cases are important mechanisms for organizing requirements, defining stacked content, evaluating implementation, and organizing acceptance tests.
10. Create an upgradeable and configurable process. No process is suitable for all software development projects. In reality, a process framework must be configurable and suitable for a wide range of applications. To ensure the economic level and return on investment, the Organization must instill a general process "Spirit" so that all projects can integrate a series of common best practices, especially the best practices for project management, workflow, checkpoint, measurement, and product independent of context. Various projects should also be allowed to be tailored and designated for implementation of the project-specific context optimization process.
The relationship between CMM and the two management principles Table 1 identifies which of the two principles are directly stimulated by the KPA of CMM. These are my judgments. They are combined with the opinions of many rational colleagues, but there is no scientific basis. In addition, remember that these principles are based not only on CMM, but also on observation of default practices and organizational inertia.
Table 1: How CMM inspires software management principles

CMM stimulation of waterfall principles	CMM stimulation of stacking principle
Color Description: Green: CMM directly inspires organizations to apply these principles Blue: CMM is neutral, that is, it does not provide direct stimulation or hinder the Organization from applying these principles. RED: CMM hinders organizations from applying these principles
1. freeze requirements before Design 2. Avoid coding before detailed design review 3. Programming Languages with higher commands 4. Complete unit test before integration 5. maintain detailed traceability for all products 6. Document and maintain the design 7. A measurement team should evaluate the quality. 8. Comprehensive inspection 9. complete and precise planning at the early stage of the project. 10. Strictly control source code baselines.	1. Pay attention to the structure process first. 2. Use stacks to defend against risks in the early stages. 3. Emphasize component-based development. 4. Establish a change management environment. 5. Use cyclic engineering tools to make changes more free. 6. Use strict model-based design symbols. 7. Provide objective quality control measures for the process. 8. Demo-based evaluation using intermediate products. 9. Release a detailed and expanded plan. 10. Create an upgradeable and configurable process.

As shown in table 1, the key process fields of CMM directly inspire most traditional principles, but they have almost no influence on modern principles. In my opinion, some modern principles are actually in conflict with the key process domain of CMM. I think this form will cause a heated debate among the enthusiastic supporters of process improvement, but I believe that most engineers and project managers at the front-line of the final software development project will agree with my conclusion. The connection between CMMs and modern management principles
Now let's take a look at cmme. If I make a rough analysis, I will get the result of table 2.
Note: The color description of table 2 is the same as that of table 1.
Table 2: How the cmme motivates iterative software management principles
Table 2: how to motivate the management principles of software stacks in CMMs

Connection between CMMs and stacked generation principles

1. Pay attention to the structure process first. 2. Use stacks to defend against risks in the early stages. 3. Emphasize component-based development. 4. Establish a change management environment. 5. Use cyclic engineering tools to make changes more free. 6. Use strict model-based design symbols. 7. Provide objective quality control measures for the process. 8. Demo-based evaluation using intermediate products. 9. Release a detailed and expanded plan. 10. Create an upgradeable and configurable process.

Please note that my analysis is still based on the industry's default practice, rather than the purpose of cmme. Our connection with traditional methods and organizational culture will become an obstacle to achieving the true purpose of CMMs. Therefore, I am conservative in my opinion. Obviously, my point is that cmme represents the major improvement.