7 Part 7: V-Modell Reference Mapping to Standards

7.2 Mapping to other Standards

7.2.2 Mapping to CMMI®

Version 1.1 of the Capability Maturity Model Integration® (in the following called briefly CMMI®) was developed by the Software Engineering Institute of the Carnegie Mellon University, Pittsburgh, PA, to be able to carry out interdisciplinary developments, in particular software and system development projects faster and better and to obtain at the same time high quality products. In this process models for software development, system development, integrated product and process development and procurement from suppliers, which previously existed separately, were integrated in a combined model. The history of the original models lead to two layouts with different structures, the stepped layout and the continuous layout. In this »Mapping to Standards only the stepped variant is considered, because it determines the degree of maturity of an organization over all process areas and thus corresponds more closely to the view of the V-Modell. The main structural element of the stepped layout are the process area that are assigned to the maturity levels 2 to 5. In each process area one or more "Specific Goals" exist that have to be achieved in order to comply with the process area. This is done by mastering the "Specific Practices" assigned to the Specific Goals. Beyond that there are also "Generic Goals", one for the maturity level 2 and one for the maturity levels 3 to 5. The "Generic Practices" of those goals have to be complied with for each process area depending on the desired degree of maturity. In principle the essential thing is that for achieving a certain maturity level it is required to achieve the specific and generic goals of all process areas assigned to this and to the lower maturity levels.

At the maturity level 1 the processes mostly do not exist, are "chaotic" or ad hoc. This means that although processes may exist, neither a project-specific nor a company-wide use of these processes is possible. Thus the success of a company depends on the competence or the "heroism" of individual persons. Organizations of the maturity level 1 therefore frequently exceed the budget and schedule of their projects. Successes due to good products are possible, but frequently they cannot be repeated.

In organizations of maturity level 2 the project staff is tasked with the management of requirements and the planning, control, administration and review of processes. The process areas considered at maturity level 2 guarantee that existing procedures are used also during times of stress. At defined points the management is able to reconstruct the progress made in the projects. The operating results are reviewed and monitored and they meet the specified requirements, standards and objectives.

A company of maturity level 3 has a standard process defined across the organization which is continuously improved and adapted by the project staff by »Tailoring. In addition ot process descriptions this standard process includes also tools, a lessons learned database and an organization-wide collection of »Metrics that can be used by the individual projects. The standard process is introduced across the organization and imparted to all employees by way of follow-on training. During utilization it is important to recognize and document the potential for improvement of the processes in the projects and to incorporate it by taking appropriate measures.

An organization of maturity level 4 is required to greatly strengthen the field of measurement and analysis with one focus being the development and maintenance of an organization-wide metric database. It is necessary to collect information that can be analyzed not only qualitatively, but also statistically and quantitatively. For this purpose the performance of important subprocesses that significantly contribute to process performance is measured. Based on the knowledge gained from this information, the processes are improved. In the projects both the processes and the objectives are derived from those of the organization and placed under statistical/quantitative control.

Maturity level 5 organizations continually improve their process performance. Starting with the objectives of the organization and the numbers the processes provide predictable results so that the company can react quickly to chances and changes. Another aspect of the process area is the continuous fault analysis. It is used to identify faults that are caused by regular variations of the processes. On the basis of the results, the causes of the faults have to be determined and eliminated.

Both CMMI® and the V-Modell have the objective to standardize and thus facilitate the interdisciplinary development of systems consisting of software, hardware and externally produced items. The introduction of processes that are standardized across the company improves the development results.

However, the two models use a different approach. The CMMI® process model includes a large number of requirements for processes of an organization that are used to evaluate the processes and to make suggestions for improvement on the basis of the results. By comparison the V-Modell represents a standard process, which can be adapted to the specific project by tailoring. It is also possible to introduce a standard process on the basis of the V-Modell across the organization. The V-Modell offers finished »Templates for documents and includes suggestions for the methods and tools to be used. By comparison the CMMI® process model provides abstracted Best Practices.

Since CMMI® poses requirements on the processes of an organization, the following considerations are based on the assumption that the organization has introduced an organization-wide standard process based on the V-Modell, communicated the resulting expectations of the management and informed all roles about the benefits of the processses. Statements on the fulfilment or non-fulfilment of CMMI® requirements always refer to this standard process. As seen from the perspective of CMMI®, the definition of this standard process and the project-specfic tailoring must ensure that all modules necessary for fulfilling the CMMI® requirements are taken into account. Thus, CMMI® does not regard - for example - the module Measurement and Analysis as mandatory.

Since the V-Modell is based on a complex model with dependencies between the elements, some requirements of the CMMI® are not dirctly covered in the V-Modell by individual products or activities, but by products/activities with multiple applications, automatisms of the model or general regulations mostly described in the introductory chapters, such as:

• Stakeholder Involvement and Commitment is mainly covered by the role model. On top of that, on some points, for example in the project plan, the consent of all stakeholders is explicitly obtained and documented.
• The review, for example of CM activities, is carried out within the framework of the generic activity »Evaluating Process.
• Methods have to be developed when the V-Modell is introduced into the organization or when the project starts. This is supported by the V-Modell with a method pool.
• There is a product state model (see »Quality Assurance and Product State Model ) which guarantees that after the implementation of changes all products directly affected by the change and also all products depending on those products are again subjected to a test.

Another basic difference is that the V-Modell XT makes a distinction between acquirer and supplier projects. The activities of the process area "Requirements Management" are therefore for example distributed among two different projects.

In the CMMI® representation only the process areas of the maturity levels 2 and 3 are examined, because the V-Modell does not cover the maturity levels 4 and 5. The V-Modell achieves the Generic Objectives for all process areas that are relevant in the V-Modell. Therefore, contrary to the usual description, they are removed from the process areas and treated like separate process areas.