11.5 Collection of Issues for Beyond Version 1.1

[ Team LiB ]

11.5 Collection of Issues for Beyond Version 1.1 The public review period for CMMI version 0.2 in 1999 resulted in about 2,500 change requests to the model and the "books" that represent the model. Of these requests, approximately 400 were classified as "minor" and 500 were considered "global" (affecting several process areas or other elements). The remaining change requests were classified as being "local" to the individual model elements. For several of the change requests in the global and local categories, the CMMI Team lacked sufficient time to deal with them properly. Instead, they were placed on a list of potentially good ideas warranting more exploration. The use of version 1.0 resulted in many more change requests to the model components. The CMMI Team used the same process to deal with the large number of changes requested, and as happened prior to version 1.0's release, version 1.1 does not address all of the potentially good ideas from the reviewers. In this section, we discuss a few of the other major open issues�that is, issues deferred for consideration to after version 1.1. 11.5.1 Advanced Practices The implementation of advanced practices remains an issue. Version 1.1 allows advanced practices in the Engineering category but not in the other process area categories. For the future, we would expect that as the model is used, one of two things would occur. First, process improvement in the Engineering process areas might be aided by the presence of advanced practices, prompting users of this model to seek the expansion of this concept across the entire model. Second, the value that advanced practices may have for process improvement might be viewed as insufficient to justify the architectural complexity they introduce, prompting model users to ask for their elimination across the entire model. The decision within the CMMI Team to put them into the initial model releases in a limited way was intended to lay the foundation for feedback either in favor of or opposed to advanced practices, as the team could not reach a consensus view. This disagreement was a part of the debate between proponents of staged versus continuous architectures. 11.5.2 Generic Attributes EIA 731 contains generic attributes, an aspect of process improvement that is not included in any other source model. Generic attributes address the effectiveness of the process and the value of the work products produced by it. Proponents of generic attributes on the CMMI Team generated a proposal for CMMI generic attributes by making changes to improve the objectivity of the generic attributes in EIA 731. In the end, however, that proposal was not adopted. Generic attributes add a significant aspect to process improvement that is not addressed by the capability dimension or the process dimension: How effective are the processes in your environment, and do they produce work products that the stakeholders find valuable? Some organizations have developed the ability to evaluate this process-improvement dimension by adopting the Lean initiative. For CMMI, the question remains: Would the inclusion of generic attributes in a CMMI appraisal be of sufficient value, given the issue of their objectivity? 11.5.3 Relationship to Other Process Areas CMMI version 1.1 includes a section in each process area titled "Related Process Areas," which contains (not surprisingly) references to other process areas. A recommendation was made and accepted by the CMMI Team (but not implemented in version 1.1) to change the title of this section to "Relationships with Other Process Areas," and to make its content more meaningful.[7] [7] An earlier version of CMMI (predating version 1.0) used two levels of reference: the currently used "informative" reference and a stronger reference. The stronger reference invoked another process area, stating "Use the x process areas to achieve y." The application of the "Use" reference was not consistent across the model, confused model users, and raised issues in the area of appraisal. It was not clear exactly what was implied by the stronger relationship between process areas. Given the many calls to reduce the model's complexity and of the time to adequately study the issue, the stronger reference was eliminated in version 1.0. Whether anyone will make the case to revive multiple forms of reference in CMMI remains to be seen. The needs related to this issue are as follows: Model users need to understand the high-level (key) relationships between process areas. Those who develop CMMI training materials need a mechanism to generate a high-level diagram to show relationships between process areas. Model users need to understand the difference between references at different levels (components) of the model. The following guidelines were defined to restrict the use of the initial reference section in each process area to key process area interfaces: Change the title of "Related Process Areas" to "Relationships with Other Process Areas." Use the "Reference" architectural component but change the structure of the reference, in this section only, to an active statement of the relationship with other process areas. Allow one to three sentences for each relationship description. Include only the key relationships (that is, what the user needs to see at a high level). Retain the normal references in the model from other components. Generate a view in the Product Suite Repository that shows these relationships. The CMMI Product Team has recommended such a change for each process area as a part of the next release of CMMI. Example Update to Relationships Section The following example is a proposed update to the Technical Solution process area: Relationship with Other Process Areas The Requirements Development process area provides product-component requirements to this process area so that alternative solutions can be developed. The Requirements Development process area receives technical solutions, selected from the alternatives, to refine the product-component requirements. The Work Product Verification process area verifies that the product components meet their requirements. As verification issues are identified, the design may need to change. This is an iterative process and occurs throughout the development of the product. The Decision Analysis and Resolution process area provides structured decision-making practices that are used in selecting a technical solution from the alternative solutions. The Product Integration process area receives the product components following their implementation. The Product Integration process area provides integration test deficiencies to this process area for corrective action. The Validation process area provides validation deficiencies to this process area for corrective action. The Supplier Agreement Management process area handles the acquisition of all product components once the purchase decision is made in this process area.

[ Team LiB ]