Capability Maturity Model for Software (Модель SEI SW-CMM)

У 1982 році Міністерство оборони США утворило комісію, основним завданням якої стало дослідження проблем, що виникають при розробці програмних продуктів в організаціях міністерства. В результаті діяльності комісії в грудні 1984 року був створений Інститут інженерів-розробників програмного забезпечення (Software Engineering Institute, SEI) на базі Університету Карнеги-меллона в Пітсбурге.

У 1986 році SEI і корпорація Mitre під керівництвом Уоттса Хамфрі (Watts Humphrey) приступили до розробки критеріїв оцінки зрілості технологічних процесів – Capability Maturity Model (CMM).

Далі події розвивалися в наступному порядку.

1987 р. SEI публікує: короткий опис структури CMM; методи оцінки процесів розробки ПО; методи оцінки зрілості процесів виробництва ПО; анкету для виявлення ступеня зрілості процесів (для проведення самостійного, внутрішнього аудиту і зовнішнього аудиту).

1991 р. Випуск версії CMM v1.0.

1992 р. Випуск версії CMM v1.1.

1997 р. Випуск чергової (вдосконаленою) версії CMM.

Методология CMM разрабатывалась и развивалась в США как средство, позволяющее выбирать лучших производителей ПО для выполнения госзаказов. Для этого предполагалось создать критерии оценки зрелости ключевых процессов компании-разработчика и определить набор действий, необходимых для их дальнейшего совершенствования. В итоге методология оказалась чрезвычайно полезной для большинства компаний, стремящихся качественно улучшить существующие процессы проектирования, разработки, тестирования программных средств и свести управление ими к понятным и легко реализуемым алгоритмам и технологиям, описанным в едином стандарте.

СММ де-факто став саме таким стандартом. Його застосування дозволяє поставити розробку ПО на промислову основу, підвищити керованість ключових процесів і виробничу культуру в цілому, гарантувати якісну роботу і виконання проектів точно в строк. Основою для створення СММ стало базове положення про те, що фундаментальна проблема "кризи" процесу розробки якісного ПО полягає не у відсутності нових методів і засобів розробки, а в нездатності компанії організувати технологічні процеси і управляти ними.

Для оцінки ступеня готовності підприємства розробляти якісний програмний продукт СММ вводить ключове поняття зрілість організації (Maturity). Незрілою вважається організація, в якій:

· відсутнє довготривале і проектне планування;

· процес розробки програмного забезпечення і його ключові складові не ідентифіковані, реалізація процесу залежить від поточних умов, конкретних менеджерів і виконавців;

· методи і процедури не стандартизовані і не документовані;

· результат не зумовлений реальними критеріями, витікаючими із запланованих показників, застосування стандартних технологій і розроблених метрик;

· процес вироблення рішення відбувається стихійно, на межі мистецтва.

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

Основні ознаки зрілої організації:

· у компанії є чітко певні і документовані процедури управління вимогами, планування проектної діяльності, управління конфігурацією, створення і тестування програмних продуктів, відпрацьовані механізми управління проектами;

· ці процедури постійно уточнюються і удосконалюються;

· оцінки часу, складнощі і вартості робіт грунтуються на накопиченому досвіді, розроблених метриках і кількісних показниках, що робить їх досить точними;

· актуалізовані зовнішні і створені внутрішні стандарти на ключові процеси і процедури;

· існують обов'язкові для всіх правила оформлення методологічної програмної і призначеної для користувача документації;

· технологии незначительно меняются от проекта к проекту на основании стабильных и проверенных подходов и методик;

· максимально використовуються напрацьовані в попередніх проектах організаційний і виробничий досвід, програмні модулі, бібліотеки програмних засобів;

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

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

Кожен з рівнів, окрім першого, складається з декількох ключових областей процесу (Key Process Area), що містять цілі (Goal), зобов'язання по виконанню (Commitment to Perform), здійсненність виконання (Ability to Perform), виконувані дії (Activity Performed), їх вимірювання і аналіз (Measurement and Analysis) і перевірку впровадження (Verifying Implementation). Таким чином, СММ фактично є комплексом вимог до ключових параметрів ефективного стандартного процесу розробки ПО і способам його постійного поліпшення. Виконання цих вимог, кінець кінцем, збільшує вірогідність досягнення підприємством поставлених цілей в області якості.

Початковий рівень (Initial Level – Level 1).

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

Ключові області процесу цього рівня не зафіксовані.

Повторюваний рівень (Repeatable Level – Level 2).

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

У компанії розроблені деякі внутрішні стандарти і організовані спеціальні групи перевірки якості (QA). Зміни версій кінцевого програмного продукту і створених проміжних програмних засобів відстежуються в системі управління конфігурацією. Є необхідна дисципліна дотримання встановлених правил. Ефективні методики і процеси институционализируются (встановлюються), що забезпечує можливість повторення успіху попередніх проектів в тій же прикладній області.

Ключові області процесу розробки ПО цього рівня:

· Управління вимогами (Requirements management).

· Планування проекту розробки ПО (Software project planning).

· Відстежування ходу проекту і контроль (Software project tracking and oversight).

· Управління субпідрядниками розробки ПО (Software subcontract management).

· Забезпечення упевненості як розробка ПО (Software quality assurance).

· Управління конфігурацією продукту (Software configuration management).

Певний рівень (Defined Level – Level 3).

Рівень характеризується деталізованим методологічним підходом до управління (тобто описані і закріплені в документованій політиці типові дії, необхідні для багатократного повторення: ролі і відповідальність учасників, стандартні процедури і операції, порядок дій, кількісні показники і метрики процесів, формати документів і ін.).

Для створення і підтримки методологій в актуальному поляганні в організації вже підготовлена і постійно функціонує спеціальна група. Компанія регулярно проводить тренінги для підвищення професійного рівня своїх співробітників.

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

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

Ключові області процесу розробки ПО цього рівня:

· Мета впорядковування роботи організації (Organization Process Focus).

· Визначення (стандартного) процесу організації (Organization Process Definition).

· Програма навчання (Training Program).

· Інтегроване управління розробкою ПО (Integrated Software Management).

· Технологія розробки програмних продуктів (Software Product Engineering).

· Міжгрупова координація (Intergroup Coordination).

· Експертні (сумісні) оцінки колег (Peer Reviews).

Керований рівень (Managed Level – Level 4).

Рівень, при якому розроблені і закріплені у відповідних нормативних документах кількісні показники якості. Вищий рівень управління проектами досягається за рахунок зменшення відхилень різних показників проекту від запланованих. При цьому систематичні зміни в продуктивності процесу (тенденції, тренди) можна виділити з випадкових варіацій (шуму) на підставі статистичної обробки результатів вимірювань по процесах, особливо в добре освоєних і достатньо формалізованих процессных областях.

Ключові області процесу розробки ПО цього рівня:

· Кількісне управління процесом (Quantitative Process Management).

· Управління якістю ПО (Software Quality Management).

Оптимізуючий рівень (Optimizing Level – Level 5).

Для цього рівня заходу щодо вдосконалення розраховані не тільки на існуючі процеси, але і на впровадження, використання нових технологій і оцінку їх ефективності. Основним завданням всієї організації на цьому рівні є постійне вдосконалення існуючих процесів, яке в ідеалі направлене на запобігання відомим помилкам або дефектам і попередження можливих. Застосовується механізм повторного використання компонентів від проекту до проекту (шаблони звітів, формати вимог, процедури і стандартні операції, бібліотеки модулів програмних засобів).

Ключові області процесу розробки ПО цього рівня:

· Запобігання дефектам (Defect Prevention).

· Управління зміною технологій (Technology Change Management).

· Управління зміною процесу (Process Change Management).

СММ визначає наступний мінімальний набір вимог: реалізувати 18 ключових областей процесу розробки ПО, що містять 52 мету, 28 зобов'язань компанії, 70 можливостей виконання (гарантій компанії) і 150 ключових практик.

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

До переваг моделі SEI SW-CMM відноситься те, що вона орієнтована на організації, що займаються розробкою програмного забезпечення. У даній моделі вдалося детальніше пропрацювати вимоги, специфічні для процесів, пов'язаних з розробкою ПО. З цієї причини в SEI SW-CMM приведені не тільки вимоги до процесів організації, але і приклади реалізації таких вимог.

Основний же недолік SW-CMM полягає в тому, що модель не авторизована як стандарт ні міжнародними, ні національними органами по стандартизації. Втім, CMM давно вже стала промисловим стандартом де-факто.

До недоліків даної моделі необхідно віднести також великі зовнішні накладні витрати на приведення процесів компанії у відповідність моделі СММ, ніж до моделей ISO 9000. Це пов'язано з меншою поширеністю моделі в світі, меншою кількістю консалтингових органів і експертів і, в результаті, з набагато більшими зовнішніми витратами на консалтинг і на підтвердження відповідності процесів незалежною третьою стороною. Проте, CMM, поза сумнівом, корисно ISO 9000.