Модель зрілості можливостей (CMM) & це рівні в інженерії програмного забезпечення

Що таке ШМ?

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

CMM був розроблений в Інституті програмного забезпечення в кінці 80-х. Він був розроблений в результаті дослідження, що фінансується ВПС США, як спосіб оцінки роботи субпідрядників. Пізніше на основі моделі CMM-SW, створеної в 1991 році для оцінки зрілості розробки програмного забезпечення, з CMM-I інтегровано кілька інших моделей.

У цьому підручнику ми дізнаємось,

• Що таке рівні зрілості моделі здатності (ШМ)?
• Що відбувається на різних рівнях ШМ?
• Скільки часу потрібно для впровадження ШМ?
• Внутрішня структура ШМ
• Обмеження моделей ШМ
• Навіщо використовувати ШМ?

Що таке рівні зрілості моделі здатності (ШМ)?

1. Початковий
2. Повторюваний / керований
3. Визначений
4. Кількісно керований
5. Оптимізація

Що відбувається на різних рівнях ШМ?

Рівні	Діяльність	Переваги
Початковий рівень 1	На рівні 1 процес зазвичай є хаотичним та спеціальним Працездатність характеризується на основі окремих людей, а не організації Прогрес не вимірюється Продукти, що розробляються, часто мають графік і вищі за бюджет Широкі варіації розкладу, вартості, функціональності та цільових показників	Жоден. Проект - "Загальний хаос"
Рівень 2 Керований	Управління вимогами Оцініть такі параметри проекту, як вартість, графік та функціональність Виміряйте фактичний прогрес Розробити плани та обробити Визначено стандарти програмного забезпечення Виявляти та контролювати продукти, зміни у звітах про проблеми тощо. Процеси можуть відрізнятися між проектами	Процеси стає легшим для сприйняття Менеджери та члени команди витрачають менше часу на пояснення того, як щось робиться, і більше часу на його виконання Проекти краще оцінюються, краще плануються та є більш гнучкими Якість інтегрована в проекти Спочатку вартість може бути високою, але згодом зменшується Запитайте більше про документи та документацію
Визначено рівень 3	Уточнити вимоги замовника Вирішити вимоги до проектування, розробити процес впровадження Переконується, що виріб відповідає вимогам та призначеному використанню Систематично аналізуйте рішення Виправити та контролювати потенційні проблеми	Поліпшення процесу стає стандартом Рішення переходить від "кодування" до "проектування" Програми якості з’являються впродовж проектних зусиль із участю всієї команди в процесі Ризики пом'якшуються і не застають команду зненацька
Рівень 4 Кількісно керований	Статистично управляє процесами та підпроцесами проекту Зрозумійте ефективність процесу, кількісно керуйте проектом організації	Оптимізує ефективність процесу в організації Сприяє кількісному управлінню проектами в організації.
Оптимізація рівня 5	Рано виявити та усунути причину дефектів Визначте та застосуйте нові інструменти та вдосконалення процесів для задоволення потреб та бізнес-цілей	Сприяє розвитку організаційних інновацій та впровадженню Дає поштовх до причинно-наслідкового аналізу та вирішення

Наступна діаграма дає наочне зображення того, що відбувається на різних рівнях ШМ

Скільки часу потрібно для впровадження ШМ?

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

• Впровадження ШМ не відбувається за одну ніч
• Це просто не просто "оформлення документів".
• Типовий час для впровадження
  • 3-6 місяців -> для підготовки
  • 6-12 місяців -> для впровадження
  • 3 місяці -> для підготовки до оцінки
  • 12 місяців -> для кожного нового рівня

Внутрішня структура ШМ

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

Для різних рівнів ШМ існує набір KPA, наприклад, для моделі ШМ-2, KPA є

• REQM - Управління вимогами
• ПП - Планування проекту
• PMC - моніторинг та контроль проектів
• SAM - Управління угодами з постачальниками
• PPQA-Процес та забезпечення якості
• Керування конфігурацією CM

Так само для інших моделей CMM у вас є конкретні KPA. Щоб дізнатись, чи впровадження КПА є ефективним, тривалим та повторюваним, воно наноситься на наступну основу

1. Зобов'язання виконати
2. Можливість виконання
3. Діяльність виконувати
4. Вимірювання та аналіз
5. Перевірка реалізації

Обмеження моделей ШМ

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

Навіщо використовувати ШМ?

Сьогодні CMM виступає як "печатка схвалення" в галузі програмного забезпечення. Це допомагає різними способами поліпшити якість програмного забезпечення.

• Це спрямовує на повторюваний стандартний процес і, отже, скорочує час на навчання про те, як щось зробити
• Практикувати ШМ означає практикувати стандартний протокол для розробки, що означає, що це не тільки допомагає команді економити час, але також дає чітке уявлення про те, що робити і чого очікувати
• Якісні заходи добре поєднуються з проектом, а не розглядаються як окрема подія
• Він діє як пасажир між проектом та командою
• Зусилля ШМ завжди спрямовані на вдосконалення процесу

Резюме

CMM вперше був представлений наприкінці 80-х років у ВПС США для оцінки роботи субпідрядників. Пізніше, з покращеною версією, він був впроваджений для відстеження якості системи розробки програмного забезпечення.

Весь рівень ШМ ділиться на п'ять рівнів.

• Рівень 1 (початковий): де вимоги до системи, як правило, невизначені, неправильно зрозумілі та неконтрольовані. Процес, як правило, хаотичний і спеціальний.
• Рівень 2 (керований): Оцініть вартість проекту, графік та функціональність. Визначено стандарти програмного забезпечення
• Рівень 3 (визначений): Переконується, що виріб відповідає вимогам та призначеному використанню
• Рівень 4 (кількісно керований): статистично управляє процесами та підпроцесами проекту
• Рівень 5 (зрілість): Визначте та застосуйте нові інструменти та вдосконалення процесів для задоволення потреб та бізнес-цілей