Product Development & Management

How to Achieve Higher Levels of the Capability Maturity Model Integration (CMMI): Part 1

By |

CMMIIn part one of this two-part blog series, we provide an overview of our recent whitepaper, “How to Achieve Higher Levels of the Capability Maturity Model Integration (CMMI) with Live Traceability™” Click HERE to read the entire thing.

How to Achieve Higher Levels of the Capability Maturity Model Integration (CMMI): Part 1

The Capability Maturity Model Integration (CMMI), developed at Carnegie Mellon University’s Software Engineering Institute, is a recognized standard for engineering best practices that reduce the risk of defects, delays, cost overruns, and recalls. Organizations that choose to adopt CMMI strive to progress up the five levels in the maturity model by implementing sequentially more advanced best practices spanning the engineering development process.

Jama Software® is honored to be chosen by Carnegie Mellon as the primary tool used to in its Master of Science in Software Engineering to train the next generation of software engineering leaders in best practices for requirements management, reviews, verification, validation, and process performance management.

The CMMI defines its best practices in terms of goals, practices, and artifacts. The CMMI does not address the underlying systems and data architecture required to enable these practices, deliver these artifacts, and achieve these goals. The systems architecture reality for most engineering organizations is highly fragmented with the necessary data to manage the engineering product and process (user needs, system level requirements, approvals, component level requirements, model designs, component requirement decompositions, interface definitions, test cases, test results, risk analysis, validations, traceability analysis, etc.) spread across hundreds of siloed tools, spreadsheets, emails, and chat tools with high degrees of uncertainty that any information reflects the latest version continually updated with all interdependencies.

The main reason for this landscape of siloed tools is that each engineering discipline is empowered to choose a best-of-breed tool to optimize engineer productivity within their team. The breadth of functionality covered in total by all of these tools — spanning all engineering disciplines — precludes the potential for a single software vendor to provide one software tool which could replace all these best-of-breed tools to the satisfaction of every engineer across disciplines. Generally speaking, each engineering field uses their chosen best-in-class technology to accomplish their objectives. That said, the data needed to achieve CMMI goals, practices, and artifacts is unstructured, unrelated, unconnected, and unmeasurable, which poses a serious challenge when it comes to achieving goals, practices, and artifacts that must span multiple disciplines to control, manage, and improve the engineering process. In order to advance along the maturity model, each engineering organization (regardless of size) needs a unified data model architecture and automated synchronization spanning best-of-breed tools. Without these improvements, most engineering organizations struggle to achieve Level 2 (Managed) and can only do so in a highly manual, after-the-fact manner that generally fails to deliver the desired outcome benefits.

Let’s take a look at a few specific examples from CMMI to demonstrate the need for a unifying data model and an overview of how to achieve it. The first one we will examine is a core practice from the Requirements Management section for Level 2 (Managed) that specifies bidirectional traceability from high level requirements through decomposed requirements and work products across engineering disciplines to generate and maintain a traceability matrix.

CMMI Level 2 (Managed) Requirements Management

CMMI Level 2 (Managed) Requirements Management

RELATED: Tracing Your Way to Success: The Crucial Role of Traceability in Modern Product and Systems Development

There are two ways companies can approach achieving this traceability practice: after-the-fact traceability or Live Traceability™.

  • After-the-fact traceability occurs after the product has been developed and is typically a highly manual effort to try and re-create artifacts to demonstrate traceability that should have occurred during the development process but did not. This effort is undertaken solely to comply with industry standards and satisfy auditor requests for demonstration of process maturity.
  • Live Traceability occurs in real time as the product development process progresses to improve overall productivity (by ensuring engineers across disciplines are always working off the most recent and correct versions) and to reduce the risk of negative product outcomes (delays, defects, rework, cost overruns, recalls, etc.) through early detection of issues. The benefits of early detection of issues are significant. Research by INCOSE found that issues not found until verification and validation are 40 to 110 times more costly than if found during design. For this reason, most companies want Live Traceability but are stuck with legacy tools and spreadsheets that do not support it. Since each engineering discipline is allowed to choose its own tooling, the result is a large number of tools with no relationship rules or mechanisms to create Live Traceability across them.

So how do you achieve Live Traceability?

STEP 1: Define a Traceability Model

Live Traceability requires a model of the key process elements and their relationship rules to monitor during the development process. Below you see a sample relationship rule diagram from Jama Connect® that defines a common data model that spans best-of-breed tools which enables engineering organizations to manage traceability in real-time and improve process performance. Relationship rules vary by industry and company-specific requirements. Best practice templates are provided to comply with industry standards and configured to meet client-specific needs. The definition of a traceability model forms the foundation for model-based systems engineering (MBSE) since it defines model elements and their relationship to each other in a consistent manner across the entire system architecture.

 

Step 2: Setup Continuous Sync for Siloed Tools/Spreadsheets

Once the relationship rules are defined, the next step is to set up continuous sync with best-of-breed tools and spreadsheets used by the various engineering disciplines. The traceability diagram below shows a typical example of best-of-breed tools and where they sync in the Jama Connect relationship model to deliver Live Traceability.

CMMI Relationship JIRA chart

Most companies prioritize the areas of the traceability model that are most prone to lead to costly issues in the absence of a continuous sync. Most commonly, these areas are:

  • Software task management – directly linking the decomposition of requirements into user stories enables Live Traceability through the software development process through testing and defect management.
  • Test automation – test cases are managed in Jama Connect to align to requirements and ensure traceability across all engineering disciplines with the test automation results sync’d to the traceability model at the verification step.
  • Risk analysis (DFMEA/FMEA) – is most often conducted in multiple Microsoft Excel spreadsheets and the assumption has been that Live Traceability was not possible with Excel. Jama Connect is the first requirements management solution to enable Live Traceability with Excel functions and spreadsheets. Risk teams can now work in their preferred spreadsheets AND for the first time achieve live traceability to stay in sync with changes made by any engineering team.
  • Model-based systems engineering (MBSE) – the first step in MBSE is to define a relationship model between all product requirements. Once a relationship model is defined, then specifications can be determined through modeling. Jama Connect uniquely provides model-based requirements to sync logically with a SysML modeling tool like Cameo No Magic.

RELATED: Traceability Matrix 101: Why It’s Not the Ultimate Solution for Managing Requirements

Step 3: Monitor for Exceptions

Live Traceability provides the ability, for the first time, to manage by exception the end-to-end product development process across all engineering disciplines. The traceability model defines expected process behavior that can be compared to actual activity to generate exceptions. These exceptions are the early warning indicators of issues that most often lead to delays, cost overruns, rework, defects, and recalls. Below is a sample exception management dashboard in Jama Connect.

traceability exception dashboard in jama connect

 

This has been part one of a two-part blog series overviewing our recent whitepaper, “How to Achieve Higher Levels of the Capability Maturity Model Integration (CMMI) with Live Traceability™” Stay tuned for part two and click HERE to read the entire thing.


Marc Osofsky
Latest posts by Marc Osofsky (see all)