Capability Maturity Model for Software (Version 1.1) resources.sei.cmu.edu

Archiving…

When trying to understand a construct I find it best to go back to its earliest citation and watch how the model evolves, or daresay matures, with time.

That brought me back to the idea born in 1986 but more fully operationalized in this 1993 paper.

Not too shocked that SEI chose to use a model for CMMC originally developed by SEI, but it has other signs of street cred to combat any self serving vibes. “Capability Maturity Model” has 42K hits in Google Scholar.

This paper is cited 3,000 times, and the book by the lead author with same title over 2,000 times. Basic sniff test past. Let’s dig in.

SEI technical reports are also available via Internet. To use anonymous ftp from a Unix system on Internet:

Awesome. Probably defunct…True fact I ftp’d the pdf to my server.

In many organizations, projects are often excessively late and double the planned budget.

Okay this predates agile development…and I am almost all done with that method…will bring it up at the next stand up to see if I can get the discussion going in the next sprint.

In the absence of an organization-wide software process, repeating results depends entirely on having the same individuals available for the next project.

What happens when the software grows before the organization. Lot of technical debt piles on just out of bespoke necessity of early days (explained ltr).

In an immature software organization, software processes are generally improvised by practitioners and their management during the course of the project.

In an immature organization, there is no objective basis for judging product quality or for solving product or process problems. Therefore, product quality is difficult to predict

Kinda disagree here. Revenue and low churn is a great indicator of quality for immature software…You get MRR rolling in, prolly doing something right. But it was 1993 when you actually bought and owned software rather than renting a monthly license….good ole days

On the other hand, a mature software organization possesses an organization-wide ability for managing software development and maintenance processes.

….and be way slow…and have department heads battling and designers cursing engineers and other designers suddenly being front end engineers.

but mature means reliable. Old trees grow slowly maybe not bad.

In a mature organization, managers monitor the quality of the software products and customer satisfaction.

Ahh that sounds so nice. No program engineers invent features so they can have KPIs to report.

The IEEE defines a process as “a sequence of steps performed for a given purpose” [IEEE-STD-610]. A software process can be defined as a set of activities, methods, practices, and transformations that people use to develop and maintain software and the associated products

Okay here we go. This has to be the ontological beginnings of how process, which gets used in the CMMC was originally defined.

Software process capability describes the range of expected results that can be achieved by following a software process.

Interesting here the word capability is reached by following processes but in the CMMC capabilities are only related to the practices and not the processes.

Software process maturity is the extent to which a specific process is explicitly defined, managed, measured, controlled, and effective.

You see this in the cmmc levels where they are only defined in level and there is not a requirement for systems to document practices until ML 3.

To achieve lasting results from process improvement efforts, it is necessary to design an evolutionary path that increases an organization’s software process maturity in stages.

Again here process is very related to capability. I wonder where the switch in the model happened historically that disconnected process from capability.

The Capability Maturity Model for Software provides software organizations with guidance on how to gain control of their processes for developing and maintaining software and how to evolve toward a culture of software engineering and management excellence.

In the 1930s, Walter Shewart, promulgated the principles of statistical quality control. His principles were further developed and successfully demonstrated in the work of W. Edwards Deming [Deming86] and Joseph Juran [Juran88, Juran89]

Thought I found the root kernel….guess I gotta dig a little deeper.

The maturity framework into which these quality principles have been adapted was first inspired by Philip Crosby of in his book Quality is Free [Crosby79].

Guess I start ^^

Crosby’s quality management maturity grid describes five evolutionary stages in adopting quality practices.

Five maturity levels in CMMC. Accident?

A preliminary maturity questionnaire [Humphrey87b] was released in 1987 as a tool to provide organizations with a way to characterize the maturity of their software processes.

And self assessment of maturity models began.

A maturity level is a well-defined evolutionary plateau toward achieving a mature software process. Each maturity level provides a layer in the foundation for continuous process improvement.

(insert fig 1)

Okay pretty much the same maturity models used.

The CMM is a descriptive model in the sense that it describes essential (or key) attributes that would be expected to characterize an organization at a particular maturity level.

The CMM is not prescriptive; it does not tell an organization how to improve. The CMM describes an organization at each maturity level without prescribing the specific means for getting there.

First, as maturity increases, the difference between targeted results and actual results decreases across projects.

Skipping levels is counterproductive because each level forms a necessary foundation from which to achieve the next level.

This is what makes me worry about CMMC. Only cert exams for CertP, ML1, ML3, and ML5. That which is assessed gets measured. That which doesn’t gets skipped (just ask a science or social studies teacher).

Interesting in the OG model key practices were a subset of key processes but the CMMC disaggregate process and practice and only has practices as supporting capabilities.

Except for Level 1, each maturity level is decomposed into several key process areas that indicate the areas an organization should focus on to improve its software process

This is the cognitive dissonance issue…process used to many times to define the word process capabilities….stick to the rule of never use the same word to define that word….here we have process as sometimes a modifier, sometimes a noun.

When the goals of a key process area are accomplished on a continuing basis across projects, the organization can be said to have institutionalized the process capability characterized by the key process area.

This institutionalized thing is big all over the CMMC. think first time reading (pg 30) but I am skimming.

Each key process area is described in terms of the key practices that contribute to satisfying its goals. The key practices describe the infrastructure and activities that contribute most to the effective implementation and institutionalization of the key process area.

processes are built through practices…again wonder why they were split in the CMMC theoretical model

The key practices describe “what” is to be done, but they should not be interpreted as mandating “how” the goals should be achieved.

Wonder if same holds for the 171 practices across the 17 capability domains in CMMC.