Capability Maturity Model Integration (CMMI) Level 5 VS European Standard for Safety-Related Software, the Railway (EN 50128)

Capability Maturity Model Integration (CMMI)

CMMI being a process model providing a clear definition of what an organization should do to promote behaviors that lead to improved performance can be classified into 6 levels:

Level	Continuous Representation Capability Levels	Staged Representation Maturity Levels
0	Incomplete	-
1	Performed	Initial
2	Managed	Managed
3	Defined	Defined
4	-	Qualitatively Managed
5	-	Optimizing

Continuous Representation Capability Levels:

Focuses on selecting a particular process area improving the desired capability level for that particular process

Staged Representation Maturity Levels:

In staged representation the focus is on the selection of multiple process areas to improve within a maturity level

While there is no maturity level 0 in CMMI standard, there also exists no levels 4 and 5 of capability levels in CMMI standard.

CMMI LEVEL#5:

This level of the standard is concerned with the maturity level 5 focusing on the optimization of the project development processes. There are 2 conditions to achieve this level based on the representation of the project:

Achieving this level is based on the implementation of “defined goals”:

1. Establishment of the defined processes
2. Collecting process related experiences from planning and performing the process supporting the future use and improvement of the organization’s processes and process assets i.e. lessons learned, measures, work products (checklists etc.), measurement results and suggestions.

The defined goals listed for the successful implementation of capability level 3 and maturity level 5 are clearly stated in any of the following artifacts:

• Purpose
• Input
• Entry criteria
• Activities
• Roles
• Measures
• Verification steps
• Outputs
• Exit criteria

Any safety critical software developed by an organization must be certified at CMMI level 5. The CMMI standard allows the selection of processes and standards altering its original set of processes and standards in order to incorporate the standards designed for the safety critical systems through the implementation of defined goal # 3 associated with the implementation of high capability (level 3) and maturity levels (level 4-5).

En 50128 - Standard for Railway

The standard is also known as the “resource standard”. The main focus of this standard is to identify the methods to be used in order to provide software meeting the demands of safety and integrity. Following are the reasons for adopting this standard in railway industry:

1. To define a process for specifying and demonstrating dependability requirements
2. To promote the approach and a common understanding the management of the dependability
3. To allow the railway authorities and supporting industries with a process enabling the implementation of a consistent approach to the management of RAMS (reliability, availability, maintainability and safety).

Difference between CMMI Level 5 and En 50128

The CMMI standard provides a process improvement framework through which the safety and security activities can take place. Yet some specific safety and security practices were not necessarily addressed by the CMMI standard and nor does it specify the sufficient guidelines for interpreting the CMMI model’s practices in a safety and security context. Following are the differences between the aspects covered by the CMMI standard’s maturity level 5 and the railway standard En 50128:

CMMI Level 5 Standard	EN 50128 Standard
Continuous Representation Capability Levels requires the implementation of capability level 3 focusing on the selection and analysis of the process more closely to the business objectives	Staged Representation Maturity Levels focuses on the safety objectives associated with the safety critical system under development
Focuses on the type of artifacts to collect that can help communicate within team member	Focuses on how and what to collect that should be documented as an artifact
The standard is not explicitly concerned with the development of a safety critical system and thus can be applied to the development of mission critical or even to the development of a security critical system	The standard is focused on the development of software systems related to time management, safety management and certification etc.
The standard does not necessarily cover the supporting activities such as the configuration management or other management processes such as the integrated project management covering all appropriate process
The standard does not attend RAMS (reliability, availability, safety and maintainability) aspects	The standard provides the railway authorities with the process enabling the implementation of a consistent approach to the management of RAMS and thus introduces software integrity levels (SILs). Each level is associated with the degree of risk using the software system: SIL Level Risk 0 Non-Safety Related 1 Low 2 Medium 3 High 4 Very High
The standard does not only provide itself with an evaluation system but also guides to its implementation
The standard studies the risk resulting from the errors due to the process executed for the development of the software while suggesting the kinds of actions to be taken such as the casual analysis and resolution (CAR) that is applicable to every kind of software to be developed
	The standard guides to evaluate the software in accordance to the standard’s SIL levels
	Following are the specific tasks the standard requires to be performed during the product life cycle of a safety critical system: 1. Hazard & Risk Analysis 2. Safety Requirement Allocation 3. Overall Safety Validation 4. Decommissioning
The standard suggests to conduct a statistical analysis of the quantitative data extracted from the artifacts developed using scatterplots, histograms, box and whiskers plots, run charts and ishikawa diagrams.
The standard involves a practice that is project focused and uses multiple inputs in order to predict if the project’s quality and performance objectives will be satisfied	The standard predicts the possible dangers in the software along with the intensity and the probability of the risk to occur based on SIL levels

Commonalities in CMMI Level 5 and En 50128

• Both of the standards emphasize on traceability back to the objectives (in case of CMMI level 5, the any documented work should trace back to the project’s business objectives whereas in En 50128, the documented artifacts should trace back to the project’s safety objectives).
• Both of the standards require checklists, planning documents and their associated report documents which are further used for evaluation purposes.
• Both of the standards emphasize on conducting reviews on the artifacts to obtain learned lessons.
• Both the standards focus on monitoring the variations and stability in order to avoid propagation of faults in various components of the software.

References

1. A. Softwaretechnik and R. Traussnig, “Safety-Critical Systems : Processes , Standards and Certification Table of Content,” no. January, 2004.
2. The EASIS Consortium, “D0.1.2: State of the art,” Easis, 2004.
3. M. Itea, “Project Deliverable D3.4.4 – Part A (Stéphane Paul, TRT) Task 3.4 – Advanced concepts in safety and security co-engineering (Laurent RIOUX, TRT) WP3 – Advanced multi-concerns engineering concepts (Sam MICHIELS, KUL),” 2016.
4. Software Engineering Institute, “CMMI for Development, Version 1.3,” Carnegie Mellon Univ., no. November, p. 482, 2010.
5. A. Arcuri and G. Fraser, “Parameter tuning or default values? An empirical investigation in search-based software engineering,” Empir. Softw. Eng., vol. 18, no. 3, pp. 594–623, 2013.