The guide to CMMI 2.0 in the Automotive sector

What is CMMI 2.0?

CMMI (Capability Maturity Model Integration) is a framework to improve the quality of software and development efficiency. It provides a set of best practices and guidelines for process improvement in a project, division or the whole organisation. CMMI 2.0 is the current version of the framework, released in 2018.

It’s also used as a model for assessing the process maturity level within an organisation. The organisation is appraised at a specific maturity level based on how well it implements certain practices applicable to a specific maturity level.

CMMI 2.0 category areas, capability areas and practice areas

The requirements of CMMI 2.0 are organised into category areas, capability areas and practice areas.

Each practice area is a collection of practices that define the key activities to achieve specific intent and value. Practice areas are grouped into capability areas, which are divided into four category areas: doing, managing, enabling and improving.

Practice areas in CMMI 2.0

Before CMMI 2.0. process areas were known as defined requirements and grouped into four general categories: process management, project management, engineering, and support. With changes in the new version, process areas become practice areas.

There are 25 practice areas in total. They describe the requirements and critical operations that define the intent of the practice. Each practice is assigned to a specific capability area but addresses them differently depending on their maturity level.

Below is a list of the practice areas in each capability area. In this article, you can read about them in more detail: Process areas in CMMI 2.0 model.

Ensuring quality (ENQ)

• Requirements development and management (RDM)
• Process quality assurance (PQA)
• Verification and validation (VV)
• Peer reviews (PR)

Engineering the developing products (EDP) 

• Technical solution (TS)
• Product integration (PI)

Delivering and managing services  

• Service delivery management (SDM)
• Strategic service management (STSM)

Selecting and managing suppliers

• Supplier source selection (SSS)
• Supplier agreement management (SAM)

Planning and managing work

• Estimating (EST)
• Planning (PLAN)
• Monitor and control (MC)

Managing business resilience

• Risk and opportunity management (RSK)
• Incident resolution and prevention (IRP)
• Continuity (CONT)

Managing the workforce  

• Organisational training (OT)

Supporting implementation  

• Causal analysis and resolution (CAR)
• Decision analysis and resolution (DAR)
• Configuration management (CM)

Sustaining habit and persistence  

• Governance (GOV)
• Implementation infrastructure (II)

Improving performance  

• Process management (PCM)
• Process asset development (PAD)
• Managing performance and measurement (MPM)

CMMI 2.0 maturity levels

As mentioned above, the maturity levels are used to assess the process maturity in an organisation. There are six maturity levels that range from 0 (the lowest) to 5 (the highest).

Maturity level 0 – incomplete

Processes are unknown or ad-hoc – they may not be followed or exist at all, therefore the work may or may not be completed.

Maturity level 1 – initial

Processes are still unpredictable, and the practices are not fully implemented. The work may not always be completed within budget and schedule.

Maturity level 2 – managed

Processes are planned, performed, measured and controlled within a project but not across the whole company yet.

Find out what practice areas must be implemented and rated at CMMI maturity level 2.

Maturity level 3 – defined

Practices are followed across the whole company. The areas for improvement are identified, and there’s a plan to address them.

Find out what practice areas must be included at CMMI maturity level 3

Maturity level 4 – quantitatively managed

At maturity level 4, there’s a data-driven approach to process improvement across the organisation. Processes are predictable and respond to the stakeholder’s needs. Organisations have more insights into process deficiencies, so the risk level is lower.

Level 4 is considered high maturity, though few companies reach it in practice. In the Automotive industry, CMMI maturity level 4 is perceived as an aspiration rather than an achievable target.

Find out what practice areas must be used and rated at CMMI maturity level 4.

Maturity level 5 – optimising

Organisations at maturity level 5, strive for continuous improvement, which leads to innovation. However, similarly to level 4, level 5 is regarded as an aspiration.

Find out what practice areas must be implemented at CMMI maturity level 5.

CMMI 2.0 appraisal

CMMI 2.0 appraisal is used to evaluate an organisation’s processes and find out their strength and weaknesses based on CMMI best practices. As a result of the appraisal, an organisation is rated at an appropriate maturity level.

CMMI 2.0 appraisal is not mandatory, but is commonly required by the U.S. Government software development contracts and thus can be a significant competitive advantage in America.

There are four appraisal methods.

Benchmark appraisal

Through the benchmark appraisal, organisations can identify opportunities for process and business performance improvement. It results in a maturity level valid for three years.

Action plan reappraisal

If an organisation narrowly misses their target maturity level at the previous appraisal, they can carry out an action plan reappraisal.

Sustainment appraisal

Sustainment appraisal is done every two years following the benchmark appraisal to confirm and extend its maturity level.

Evaluation appraisal

It’s a form of a mock benchmark appraisal. It’s used to identify gaps and areas for improvement before the official appraisal and doesn’t result in a maturity level rating.

What are the benefits of CMMI 2.0 in the Automotive sector?

• CMMI 2.0 allows organisations to identify areas for improvement based on how their processes compare to CMMI best practices.
• Organisations with high maturity level (3-4) are perceived as reliable and stable partners for cooperation.
• CMMI is especially beneficial for organisations with short time requirements as it instructs to first map the timings and then plan the modules of the software development phase.

How to use CMMI for systems engineering in the Automotive industry?

Systems engineering is one of the four areas supported in the Capability Maturity Model Integration (CMMI).

The following six process areas are used for engineering, including systems engineering:

Requirements management

At this stage, any possible inconsistencies between the product requirements, both technical and non-technical, and the project workflow and roadmap can be reassessed and settled.

As the requirements may change throughout the product development process, it’s recommended to regularly check how they interact with other elements of the project and adjust them accordingly.

Find out what the specific and generic goals for the requirements management stage are.

Requirements development

At this point, the requirements collected in the previous stage are analysed and developed. There are three groups of practices focused on these activities.

The first one is used as a foundation for product design and includes the collection and coordination of stakeholder needs, the establishment of requirements, analysis of customer needs and expectations.

The second group consists of a customer requirement analysis, the development of an operational concept, the definition of the required functionality and the development of the manufacturing and support concepts to address cost and affordability.

The third group is strongly connected to the previous one. It presents the results of the analysis as a list of constraints of various types, technological limitations, cost and cost drivers, time constraints, possible risks and more.

Read more about the specific and generic goals for the requirements development stage.

Technical solution

The next stage of the process is all about designing, developing and implementing solutions to the requirements established in the two previous phases. It’s important to highlight that the design, development and implementation are connected, and they may impact each other in a direct or indirect way. Also, the requirements may change over time, so further iterations of the already implemented solutions may be needed, maintaining the necessary traceability.

Find out more about the specific and generic goals for the technical solution stage.

Product integration

When the designs and solutions are ready, the next step is to assemble the product from the existing components and fill any gaps that have not been covered by the requirements and solutions. Also, at this stage, the product is tested and assessed as integrated and fully functional. When it’s completed, the product can be delivered to customers and other stakeholders.

In the case of system engineering, the final product will be a system with all its elements included, tested and released. Your responsibility will be to ensure the consistency of all designs.

Also, please note that the product integration stage can be completed iteratively and is not – in any case – a one-off process. Work with prototypes and make sure that they get more advanced as you approach the release.

Find out about the specific and generic goals for the product integration stage.

Verification

Once the product or system is deployed, you need to move to the verification stage. The purpose of this phase is to ensure that the final result meets the specified requirements from both the project and customer sides. You may also need to take any corrective actions if the verification turns out to be unsatisfactory.

While on the surface, verification and validation (see the next stage) may seem similar, there are – in fact – two different activities. Verifying the product assesses whether it’s viable and complete from the requirements point of view. Validating it is all about ensuring that the product will fulfil its function and is, in fact, what was necessary for a particular task.

See the list of specific and general goals for the verification stage.

Validation

The validation process focuses on whether the product can address its intended use. The full functionality needs to be achieved in the intended environment.

As it is with the verification, the validation also follows through on I.a. testing, analysis and simulation, so these two processes may be using the same environment or even be conducted in parallel, at the same time. Any issues that will be discovered at this stage need to be addressed accordingly, with corrective actions taken immediately.

Here’s a list of specific and generic goals for the validation stage.

Using the CMMI model for systems engineering in the Automotive sector

Traditionally, the systems engineering domain is heavily based on the V-model, with certain processes grouped into three categories:

• Primary life cycle processes (acquisition process group, supply process group, system engineering process group, software engineering process group, cybersecurity engineering process group).
• Organisational life cycle processes (management process group, reuse process group, process improvement process group).
• Supporting life cycle processes (supporting process group).

While this model of work is still viable when using CMMI, the workflow itself is managed differently and on an organisational rather than a process level. Where the V-model includes elements such as ‘system architecture’, ‘system requirements’, ‘structure architecture’ and ‘structure requirements’, in the CMMI there’s ‘high-level design’ and ‘low-level design’.

This will be especially important if you need to combine the CMMI with any other processes and models that your organisation may already be using, including the V-model mentioned above and ASPICE.

Read more about it: Cybersecurity as a plugin into ASPICE and V-model.

We’ll help you implement CMMI 2.0 in your company

If you need any support when introducing the CMMI framework to your organisation, contact our Automotive team for more information using the form below.