How do CMMI and CMM differ

5 Comparison of CMM, CMMI v1.1 and CMMI v1.2

Transcript

1 D3kjd3Di38lk323nnm 93 5 Comparison of CMM, CMMI v1.1 and CMMI v From SW-CMM to CMMI v1.1 Some of the differences between CMMI and its predecessor model, the CMM, have already been addressed elsewhere when dealing with the respective topic. The most important changes are to be summarized and completed here. The main differences, which have already been dealt with in Chapter 3, are the modular structure, the associated adaptability to different areas of application and the introduction of a continuous representation and the generic goals and practices. A very detailed comparison of CMMI-SE / SW and SW-CMM v1.1 on the level of individual requirements (practices) can be found in [STSC02]. The names of the structural elements have been partially changed. Instead of “Key Process Areas” (KPA) as in CMM, there are “Process Areas” in CMMI, and the previous “key practices” are now called “Practices”, whereby a distinction has been introduced between generic and specific practices. Key process areas and key practices Improved structuring In order to achieve the goal of easy adaptability, the CMMI has been structured much more strongly than the CMM: Common requirements in all process areas have been extracted as generic goals and practices. Each practice belongs to exactly one goal. In practice, this has given the goals a higher priority, as it is now easier to check whether they have been achieved.

2 94 5 Comparison of CMM, CMMI v1.1 and CMMI v1.2 The subdivision of the process areas into four categories (process management, project management, engineering disciplines and support) rather than three categories as in CMM (management, organization, Engineering disciplines; see [CMM94, Chap. 4.6]) Changes in content This stronger structure means that the requirements are clearer and requirements that are obviously meant but not explicitly required hardly occur. There have been such cases in CMM, for example Activity 2 requires a plan from CMM-OPF for the activities for software process development and improvement. However, there is no explicit requirement that this plan be implemented. At least rumor has it that there are organizations that have exploited this loophole in assessments. A comparison of the individual maturity levels results in the following picture: Maturity level 2 Maturity level 3 Many changes in detail, but essentially the requirements have remained the same. The most obvious difference is the new "Measurement and Analysis" process area, in which the requirements for this area, which were previously distributed across all process areas, have been combined (see Chapter). In the “Requirements Management” process area, the requirement for bidirectional traceability (SP 1.4, see page 42) of the requirements in CMMI has been added, the implementation of which causes difficulties for many companies. This level has changed the most compared to the CMM. This becomes apparent at first glance by comparing the process areas of both models. Of the seven process areas of the CMM, maturity level 3, two were roughly retained ("organizational process focus" and "organization-wide process definition"), for two others this applies with restrictions ("training program" and "integrated software management") and the other three became complete restructured and supplemented so that CMMI maturity level 3 has grown to a total of eleven process areas (see Fig. 5 1). 1 Due to this greater breakdown, the project life cycle in the narrower sense has become significantly more important, 1. Only the process areas of the CMMI-SW are taken into account; Two more process areas were added for IPPD and one more process area for SS.

3 5.1 From SW-CMM to CMMI because it is now described in much more detail in three separate process areas (see beginning of chapter 4.2, in particular chapter to chapter). As with maturity level 2, there are many changes in detail, but essentially the requirements have remained the same. Here, too, you can see many changes in detail, but there are no changes in the basic requirements. Maturity level 4 Maturity level 5 Fig. 5 1 Mapping of CMM level 3 to CMMI level 3 Changes to the processes and changes to the technology that were dealt with in the CMM in two separate key process areas, namely in »technology change management« and »process change management«, are in CMMI summarized in the process area "Organization-wide innovation and dissemination" (chapter).

4 96 5 Comparison of CMM, CMMI v1.1 and CMMI v Model scope The scope of the CMMI is significantly larger than that of the CMM or the other predecessor models, with the exception of the IPD-CMM (see Tab. 5 1). The main reason for this is that the CMMI is intended to cover all of the topics covered by the previous models. As a result, however, the effort involved in the introduction and, in particular, the review as part of an assessment (Chapter 8) is significantly greater. This is reinforced by the replacement of the assessment method CBA-IPI by the "standard CMMI Appraisal Method for Process Improvement" SCAMPI, which has higher formal requirements (see Section 8.2). Tab. 5 1 Size comparison of CMMI with the source models (information marked with (*) according to [Phil02]) Model # Process areas # Goals / Topics # Practices (specific + generic) SW-CMM v = 316 SW-CMM v2.0 draft C (*) EIA / IS 731 (*) IPD-CMM v0.98 (*) CMMI-SE / SW v1.1, stepped display CMMI-SE / SW v1.1, continuous display CMMI-SE / SW / IPPD / SS v1.1, stepped display CMMI-SE / SW / IPPD / SS v1.1, continuous display CMMI-DEV v1.2 (continuous and stepped display) CMMI-DEV + IPPD v1.2 (continuous and stepped display) = = GG GP = = GG GP GG GP GG GP The common structure of the process areas In terms of content, the requirements contained in the structure of the process areas (common features) of the CMM have been retained, even if they were divided differently in the CMMI. The common features were used in CMMI v1.1 to differentiate between the generic practices, but had no practical significance and were therefore deleted in CMMI v1.2.

5 5.2 CMMI v1.2 compared to CMMI v CMMI v1.2 compared to CMMI v Overview The most important changes of CMMI version 1.2 compared to the previous version 1.1 are summarized below. Both versions can be downloaded from the SEI website [URL: CMMI] and are available as a book ([ChKS03] or [ChKS06]). Many details have changed with CMMI-DEV v1.2, but the changes to the model itself have little effect on the practical implementation, as long as you limit yourself to the disciplines of software and system development that are most widespread in practice. In most cases, only the previous content is formulated more clearly, sometimes also shifted to other process areas, so that overall one can speak of a real improvement. With CMMI v1.2, two relatively complex distinctions between practices, which had hardly any practical relevance, have been eliminated: On the one hand, there is the division of generic practices into the common structure (common features): Obligations to implement (commitments, CO) skills for Execution (Abilities, AB) Control of the implementation (Directing Implementation, DI) Verifications of the implementation (Verifications, VE). On the other hand, the subdivision into basic practices, which were assigned to skill level 1, and advanced practices, which were assigned to a higher skill level. It looks a little different with the assessment method SCAMPI A, in which a number of contents have also changed. Most of these changes are aimed at increasing the reliability of assessment results and making the framework conditions of the individual assessment more clearly visible. However, this also means that the minimum effort required for an assessment continues to rise, which is a problem especially for small organizations. Hardly any impact on the practical implementation Common features Basic practices and advanced practices Increasing the requirements for assessment methods Variants of the CMMI Instead of the previous CMMI disciplines software development (SW), system development (SE), integrated product and process development

6 98 5 Comparison of CMM, CMMI v1.1 and CMMI v1.2 hardware (IPPD) as well as procurement via suppliers (SS) there is now only one CMMI-DEV for development with an optional addition for IPPD. Two new variants, CMMI-ACQ for acquisition and CMMI-SVC for services, have also been announced. The previous distinction between SE and SW is no longer reflected in different model variants (even if these differ only in the explanations and examples in CMMI v1.1), but »only« in the respective application area of ​​a common model. A new addition is the topic of hardware development, which was only implicitly treated as part of system development in CMMI v1.1 and has now been included as a separate specialization of CMMI-DEV. Since these four CMMI variants for development (CMMI-DEV and CMMI-DEV + IPPD, each in stepped and continuous representation) differ only slightly, they appear in a joint document or book. CMMI v1.1 was originally published in the form of eight different documents with significant overlaps, which were later summarized in a joint book. Maturity level 2 The changes to maturity level 2 have relatively little impact on the practical implementation. The following relevant changes were made: Requirements management REQM SP 1.4: Bidirectional traceability of requirements no longer refers explicitly to planning and work results, but only to work results. Management of SAM supplier agreements The scope of SAM has been changed: In particular, the restriction that SAM only applies to supplies for which there is a formal agreement has been removed. This closes the previous loophole that a company could not conclude any formal agreements for its supplies and could therefore declare SAM as inapplicable. The practice SP 2.1 "Reviewing COTS products" from v1.1 has been removed; the topic is now taken into account in the »technical implementation« TS at maturity level 3 in a sub-practice of SP 1.1. SP 2.1 has always been a

7 5.2 CMMI v1.2 compared to CMMI v Foreign matter at this point and didn't really fit SAM, so this change is a real step forward. In addition, there are the practices SP 2.2 "Monitor selected supplier processes" and SP 2.3 "Evaluate selected work results of the supplier", which were taken over to SAM from the previous process area "Integrated Supplier Management" that was omitted in CMMI v1.2. Generic Practices The generic practice GP 2.6 has been slightly weakened in »place named work results of the process to an appropriate extent under control« (previously: place under »configuration management«) Maturity level 3 At maturity level 3, the following significant changes were made: Integrated project management IPM practice SP 1.1 now explicitly requires the derivation of the project processes from standard processes for the entire life cycle of the project. There is also a new practice SP 1.3 "Set up the project's work environment". This means that the provision of an appropriate working environment, which was also part of the generic practice GP 2.3 "Provision of resources" in version 1.1, is of much greater importance. Analogous to the derivation of the organization-wide processes from the standard processes of the organization, the working environment of the project is also derived from a standardized working environment of the organization, which is defined as part of a new practice at OPD. Part of the IPPD addition to CMMI-DEV is the new target SG 3 "Apply IPPD principles", which replaces the previous process area "Integrated Teaming", IT. Organization-wide process definition OPD In order to support the standardized processes of the organization through a standardized work environment, there is a new practice for the work environment at OPD, namely SP 1.6 "Set up standards for the work environment". The working environment of the project is derived from this as part of the »integrated project management«.

8 100 5 Comparison of CMM, CMMI v1.1 and CMMI v1.2 Another part of the IPPD addition to CMMI-DEV is the new goal SG 2 »Enable IPPD Management«, which covers the previous process area »Organization-wide environment for integration« replaced. Organization-wide process focus OPF target SG 2 now calls for the planning and implementation of process improvements instead of process improvement activities. This change is intended to make it clearer that it is not about the activity, but about the process improvement itself. In practice it hardly makes a difference. A new target SG 3 "Introduce process assets of the organization and incorporate experience" has been added. It contains two practices from the previous SG 2, but also the new practices SP 3.2 "Introduce standard processes" and SP 3.3 "Monitor implementation", which place greater emphasis on the implementation of process improvements in all projects. Requirements development RD Practical SP 3.1 "Creating Operating Concepts and Scenarios" has been expanded and now includes the previous Practical SP 1.2 "Further Developing Operating Concepts and Scenarios" from the "Technical Implementation". Technical implementation TS See »Management of supplier agreements« and »Requirements development« Validation VAL practice SP 2.2 now reads »Analyze validation results« without identifying open points, as in the past. This aspect is covered in SG 2 by »project tracking and control«, unfortunately not so explicitly. In addition, in the introduction to the process area it was now more clearly described that validation is not only necessary at the end of a project, but right from the start. Verification VER Analogous to Validation, SP 3.2 now reads “Analyze verification results” without identifying corrective measures, as in the past. In addition, at maturity level 3, the following three process areas have ceased to exist as separate process areas that were previously in the (also removed)

9 5.2 CMMI v1.2 compared to CMMI v) CMMI disciplines CMMI-IPPD and CMMI-SS were included in addition to those of CMMI-SE / SW: Integrated supplier management ISM The contents of this process area were partially included in "management of supplier agreements" integrated (see the new practices SP 2.2 and SP 2.3 there); further parts are taken over into the new CMMI constellation CMMI-ACQ for acquisition. Integrated IT team building This process area, which was previously part of the CMMI discipline IPPD, has also been removed. The essential contents were migrated to the target SG 3 of the »integrated project management«, which in turn is part of the IPPD supplement of CMMI-DEV. Organization-wide environment for integration OEI This process area, also previously part of the CMMI discipline IPPD, has also been omitted with CMMI v1.2. The essential content was migrated to target SG 2 of the »organization-wide process definition«, which is also part of the IPPD supplement to CMMI-DEV. There were significantly more real changes than with the CMMI model with the associated appraisal method SCAMPI A. These changes are summarized in the chapter When should you change? As described, the differences in content between CMMI v1.1 and v1.2 are relatively minor. You should therefore switch to the current version quickly in order to be able to use its improvements. For all those who want to switch to CMMI v1.2, the SEI offers upgrade training as online training. For members of appraisal teams who want to carry out a SCAMPI appraisal according to CMMI v1.2, this is an offer that cannot be refused, because the training course at a price of 175 $ is mandatory in this case. It consists of a set of slides that you work through and explicitly confirm at the end. Appraisals according to CMMI v1.1 and SCAMPI v1.1 are still possible until August 2007; after that, support for these versions will be completely discontinued, and the corresponding SEI licenses for carrying out appraisals will expire. CMMI v1.2 upgrade training