CMMI — the CAPABILITY MATURITY MODEL INTEGRATION, from the Software Engineering Institute at Carnegie Mellon, successor to the original CMM (1991). It is a PROCESS IMPROVEMENT framework: it describes what a capable process looks like, without prescribing how to achieve it. THE UNDERLYING PREMISE: the quality of a software product is largely determined by the quality of the process used to develop it. Improve the process and the product improves — repeatably, rather than by heroics. THE FIVE MATURITY LEVELS (the STAGED representation): LEVEL 1 — INITIAL The process is ad hoc and occasionally chaotic. Few processes are defined and success depends on INDIVIDUAL EFFORT AND HEROICS. Schedules and budgets are typically exceeded. → Every organisation is at Level 1 by default; it is not an achievement but a starting point. Note that Level 1 organisations can and do ship good software — but they cannot do it PREDICTABLY, and cannot say in advance whether the next project will go well. LEVEL 2 — MANAGED (originally "Repeatable") Basic project management processes are established to track cost, schedule and functionality. The necessary process discipline is in place to REPEAT EARLIER SUCCESSES on projects with similar applications. → the key word is PROJECT. Discipline exists per project, and practices may differ between projects. Process areas: requirements management, project planning, project monitoring and control, supplier agreement management, measurement and analysis, process and product quality assurance, configuration management. LEVEL 3 — DEFINED The process for both management and engineering activities is DOCUMENTED, STANDARDISED AND INTEGRATED into an ORGANISATION-WIDE standard software process. All projects use an approved, tailored version of that process. → the shift from Level 2 to Level 3 is from PROJECT-level discipline to ORGANISATION-level. This is the level most commonly targeted, and the biggest single jump in effort. Process areas add: requirements development, technical solution, product integration, verification, validation, organisational process focus and definition, organisational training, integrated project management, risk management, decision analysis and resolution. LEVEL 4 — QUANTITATIVELY MANAGED Detailed measures of the software process and product quality are collected. Both are QUANTITATIVELY UNDERSTOOD AND CONTROLLED using statistical techniques. → the shift is to STATISTICAL control: you know the mean and the variance of your process, so you can predict outcomes with stated confidence rather than hoping. Process areas: organisational process performance, quantitative project management. LEVEL 5 — OPTIMISING CONTINUOUS PROCESS IMPROVEMENT is enabled by quantitative feedback from the process and from piloting innovative ideas and technologies. → the organisation deliberately experiments, measures the result, and adopts what works. Defect causes are systematically analysed and prevented. Process areas: organisational performance management, causal analysis and resolution. THE PROGRESSION IN ONE LINE EACH: 1 unpredictable · 2 disciplined per project · 3 standardised across the organisation · 4 measured and statistically controlled · 5 continuously improving THE LEVELS ARE CUMULATIVE — you cannot be Level 4 without satisfying Levels 2 and 3.

CMMI offers TWO REPRESENTATIONS of the same content, and the distinction is regularly examined: STAGED REPRESENTATION The organisation is assessed and given a single MATURITY LEVEL 1–5. Process areas are grouped into levels, and you must satisfy all process areas at a level (and below) to claim it. ✔ a single, comparable number — which is why procurement likes it ✔ a predefined improvement roadmap: you know what to do next ✘ forces you to improve areas you may not need yet, in order to reach the next level CONTINUOUS REPRESENTATION Each PROCESS AREA is separately rated on a CAPABILITY LEVEL (0 incomplete, 1 performed, 2 managed, 3 defined). An organisation gets a PROFILE across process areas rather than one number. ✔ improve the areas that matter to your business first ✔ finer-grained and more honest ✘ no single number to advertise, and profiles are hard to compare between organisations → this is the representation that matches ISO 15504/SPICE. THE STRUCTURE OF THE MODEL: PROCESS AREAS a cluster of related practices in an area (e.g. Configuration Management, Risk Management). CMMI-DEV defines around 22 of them. SPECIFIC GOALS unique to a process area — what that area must achieve SPECIFIC PRACTICES the activities that achieve a specific goal GENERIC GOALS apply to multiple process areas — concerned with institutionalising the practices GENERIC PRACTICES the activities that achieve generic goals, such as providing resources, assigning responsibility, training people, and monitoring THE GENERIC GOALS ARE THE INTERESTING PART: they are what distinguish "we did this once" from "this is how we work". A practice performed but not resourced, trained, monitored and reviewed is not institutionalised, and CMMI will not credit it. CMMI CONSTELLATIONS — CMMI-DEV (development), CMMI-ACQ (acquisition), CMMI-SVC (services). APPRAISAL is done using SCAMPI (Standard CMMI Appraisal Method for Process Improvement), with classes A, B and C at decreasing rigour and cost. Only a SCAMPI A appraisal produces a published maturity level rating.

THE PUBLISHED EVIDENCE, in the form organisations report it. Typical findings when moving from Level 1 to Level 3 or higher include reduced schedule variance, reduced defect density, and improved productivity — with the largest effects on PREDICTABILITY rather than on raw speed. WORKED — what "predictability" means numerically. Consider two organisations each estimating ten projects at 100 person-months: LEVEL 1: actual outcomes (person-months) 62, 88, 95, 110, 134, 141, 158, 176, 203, 233 mean = 140.0 deviations from the mean: −78, −52, −45, −30, −6, 1, 18, 36, 63, 93 sum of squared deviations = 25,988 variance = 25,988/10 = 2,598.8 standard deviation = √2,598.8 = 50.98 coefficient of variation = 50.98/140.0 = 0.364 LEVEL 4: actual outcomes 104, 108, 112, 115, 118, 121, 124, 127, 131, 140 mean = 120.0 variance = 108.0, standard deviation = 10.39 coefficient of variation = 10.39/120.0 = 0.087 THE MEAN BARELY MOVED — 140 to 120, a 14.3% improvement in average effort. THE VARIABILITY COLLAPSED — a standard deviation of 50.98 down to 10.39, very nearly FIVE TIMES tighter, and the coefficient of variation fell from 0.364 to 0.087, a factor of 4.2. WHY THAT MATTERS MORE THAN THE MEAN: with σ = 51, a commitment to deliver in 150 person-months has a real chance of needing 230 — the worst observed outcome is 1.8σ above the mean. To promise a date safely you must pad enormously, so your quoted price is uncompetitive even though your average cost is fine. With σ = 10.4, a commitment of 150 sits 2.9σ above the Level 4 mean of 120, so essentially nothing exceeds it — the SAME quoted figure that was reckless at Level 1 is now safe. PROCESS MATURITY BUYS THE ABILITY TO MAKE PROMISES — which is exactly what a customer is paying for, and why maturity levels matter commercially. THE COSTS, honestly: · reaching Level 3 is commonly a multi-year programme with a dedicated process group · appraisal itself is expensive, and must be renewed · documentation and measurement overhead falls on engineers, who will resent it if it produces nothing they can use — which is the standards problem from the SQA topic · SMALL ORGANISATIONS may find the overhead disproportionate; CMMI was designed with large defence contractors in mind THE CRITICISMS, which you should be able to state: · IT MEASURES PROCESS, NOT OUTCOME. An organisation can be Level 5 and build a product nobody wants. Maturity is about predictability, not about product judgement. · APPRAISAL GAMING. Where a level is a contractual requirement, the incentive is to obtain the rating rather than the capability — the same failure mode as certification theatre. · IT CAN DISCOURAGE ADAPTABILITY if interpreted as "document everything and never deviate". The model does not require that, but rigid implementations do. · POOR FIT WITH SMALL, FAST-CHANGING PRODUCT WORK, where the cost of process documentation is high relative to team size. CMMI AND AGILE — the reconciliation, since students often assume they conflict. They address different questions: agile methods are a set of PRACTICES, CMMI is a framework for assessing CAPABILITY. An agile team can satisfy CMMI process areas — a definition of done is process and product quality assurance, a retrospective is causal analysis and resolution, a burndown chart is project monitoring and control, and version control with CI is configuration management. The SEI published guidance specifically on this. What CMMI demands is that the practice be INSTITUTIONALISED — resourced, trained, monitored — which is a fair demand of any practice.