Capability Maturity Model

Capability Maturity Model — модель зрілості можливостей (модель повноти потенціалу) створення ПЗ: еволюційна модель розвитку здатності компанії розробляти програмне забезпечення. Термін "зрілість" відноситься до ступеня формалізації та оптимізації процесів, від спеціальної практики, до формально певних кроків, щоб вдалося привести показники до активної оптимізації процесів.

Метою моделі є покращення існуючих програм розвитку процесів, але це може застосовуватися і до інших процесів.

Історія

У листопаді 1986 року американський інститут Software Engineering Institute (SEI) спільно з Mitre Corporation почали розробку огляду зрілості процесів розробки програмного забезпечення, який був призначений для допомоги в покращенні їх внутрішніх процесів.

Розробка такого огляду була викликана запитом американського федерального уряду на надання методу оцінки субпідрядників для розробки ПЗ. Реальна ж проблема полягала в нездатності керувати великими проектами. У багатьох компаніях проекти виконувалися зі значним запізненням і з перевищенням запланованого бюджету. Необхідно було знайти рішення даної проблеми.

У вересні 1987 року SEI випустив короткий огляд процесів розробки ПЗ з описом їх рівнів зрілості, а також опитувальник, що призначався для виявлення сфер компанії, які потребували поліпшення. Однак, більшість компаній розглядали даний опитувальник як готову модель, внаслідок чого через 4 роки опитувальник був перетворений у реальну модель, Capability Maturity Model for Software (CMM). Перша версія СММ (Version 1.0) вийшла в 1991 році. У 1992 році була переглянута учасниками робочої зустрічі, в якій брали участь близько 200 фахівців в області, і членами суспільства розробників.

Типи моделі

Моделі зрілості

Моделі зрілості можна розглядати як сукупність структурованих рівнів, які описують, як і поведінки, практики та процеси організації можуть надійно і стійко виробляти необхідні результати.

Модель зрілості може бути використана як орієнтир для порівняння і як допомога для розуміння, наприклад, для порівняльної оцінки різних організацій, де є щось загальне, що може бути використане як основа для порівняння. У випадку з CMM, наприклад, базою для порівняння будуть організації процеси розробки програмного забезпечення.

Структура

Модель включає в себе п'ять аспектів:

• Рівні зрілості: 5-рівневий континуум - де в самому верхньому (5-му) рівні є умовною ідеальна держава, де процеси систематично контролюються поєднанням процесів оптимізації і постійного вдосконалення процесів.
• Ключові області процесу: основним процесом області визначено комплекс відповідних заходів, які, коли виконуються разом, досягають низки важливих цілей.
• Цілі: метою ключової області процесу є узагальнення положень, які повинні існувати для того, щоб ключова область була включена ефективно. Ступінь, в якій цілі були досягнуті, є показником того, скільки потенціалу організації створило на той рівень зрілості. Цілі окреслюють сферу, межі та мету кожній ключовій області процесу.
• Загальні характеристики: Загальні характеристики включають в себе практики, які впроваджуються та інституціоналізації ключової області.
• Ключові практики: ключові практики описують елементи інфраструктури і практики, які найбільш ефективно сприяють впровадженню та інституціоналізації області.

Рівні

Є п'ять рівнів, визначених за спектром, згідно з SEI: 

1. Початковий (хаотичний) - найпримітивніший статус організації. Організація здатна розробляти ПЗ. Організація не має явно усвідомленого процесу, і якість продукту цілком визначається індивідуальними здібностями розробників. Один проявляє ініціативу, і команда слідує його вказівкам. Успіх одного проекту не гарантує успіх іншого. Під час завершення проекту не фіксуються дані про роботи, розклад і якість.
2. Повторюваний - деякою мірою відстежується процес. Робляться записи про роботу і плани. Функціональність кожного проекту описана в письмовій формі. У середині 1999 року лише 20 % організацій мали 2-й рівень або вище..
3. Встановлений - мають певний, документований і встановлений процес роботи, що не залежить від окремих особистостей. Тобто вводяться узгоджені професійні стандарти, а розробники їх виконують. Такі організації в стані досить надійно передбачати витрати на проекти, аналогічні виконаним раніше.
4. Керований - можуть точно передбачити терміни і вартість робіт. Є база даних накопичених вимірювань. Але немає змін при появі нових технологій і парадигм.
5. Оптимізований процес управління включає в себе цілеспрямований процес оптимізації/поліпшення. Є постійно діюча процедура пошуку і освоєння нових і вдосконалених методів та інструментів.

Критика

Модель спершу була призначена для оцінки спроможності урядових підрядників у виконання проекту з розробки програмного забезпечення. Він був використаний і може бути пристосований до цієї мети, але критики ^[хто?] відзначили, що процес зрілості за CMM був не обов'язковим для успішної розробки програмного забезпечення.

Основи процесу розробки програмного забезпечення

У рамках документованості процесу програмне забезпечення призначається для тих, хто бажає оцінити організацію або узгодженість проекту по ключових областях процесу. Для кожного рівня зрілості, існує п'ять типів:

Тип	Опис
Політика	Описаний зміст політики і цілей KPA рекомендованих ключових областей процесів.
Стандарт	Наведено рекомендації щодо змісту деяких продуктів, описаних в ключових областях.
Процес	Описано процес інформаційного наповнення, рекомендованих ключових областей процесів.
Процедура	Наведено рекомендації щодо змісту документованих процедур, описаних в ключових областях процесу.
Огляд рівня	Дано уявлення про загальний рівень зрілості.

Див. також

• Модель Розвитку Функціональних Можливостей Інтеграції

Зовнішні посилання

• Cmmi Інституту [Архівовано 27 листопада 2017 у Wayback Machine.]
• Capability Maturity Model, каталог посилань Open Directory Project
• Архітектура зрілості моделі [Архівовано 13 травня 2017 у Wayback Machine.] у відкритій групі