9. Аналіз проблем і коригувальні дії
Ціль етапу аналізу проблем - зібрати й проаналізувати проблеми й визначити, які коригувальні дії варто почати для їхнього вирішення.
Проблеми й питання, що вимагають вирішення, звичайно виявляються в ході аналізу й при виконанні процесів. Необхідно фіксувати: проблеми й невідповідності, виявлені в процесі валідації й верифікації; значні відхилення параметрів планування проекту від їхніх оцінок; невиконані зобов'язання (як внутрішні, так і зовнішні); значні зміни в статусі ризиків; проблеми доступу до даних, збору даних, конфіденційності й безпеки даних; проблеми, пов'язані із залученням зацікавлених осіб.
Проблеми можуть мати різний характер. У тих випадках коли проблема, залишена без вирішення, може бути на перешкоді до досягнення поставлених у проекті цілей, потрібні коригувальні дії. Тому аналіз проблем включає визначення тих питань, по яких потрібні коригувальні дії.
Рекомендовані робочі продукти - результати етапу аналізу проблем: перелік проблем, що вимагають прийняття коригувальних дій.
Коригувальні дії — це дії по усуненню виявленої невідповідності або дії, виконання яких сприяє вирішенню або усуненню проблеми. До їхнього числа відносяться: модифікація або коректування завдання на роботу; модифікація або коректування вимог; перегляд оцінок і планів; уточнення й нове узгодження ролей і обов'язків учасників проекту; введення додаткових ресурсів; зміна процесів; ревізія проектних ризиків.
Коригувальні дії, як і будь-які зміни зобов'язань, варто обговорити й погодити із зацікавленими сторонами.
Рекомендовані робочі продукти - результати даного етапу: план коригувальних дій.
10. Моніторинг коригувальних дій проводиться аж до їхнього остаточного завершення. По завершенні коригувальної дії необхідно проаналізувати отримані результати й оцінити ефективність вжитих заходів. Якщо спостерігаються відхилення від очікуваних або планованих результатів, варто визначити й документувати дії, спрямовані на усунення цих відхилень.
Рекомендовані робочі продукти - результати даного етапу: результати коригувальних дій.
Література
CMMI-SE/SW Version 1.1,Staged Representation, Technical Report CMU/ 2002-TR-012, SEI.
CMMI-SE/SW Version 1.1, Continuous Representation, Technical Report CMU/ 2002-TR-012, SEI.
Boris Mutafelija, Harvey Stromberg, Systematic Process Improvement Using ISO 9001:2000 and CMMI. SEI, 2003.
Interpreting Capability Maturity Model Integration (CMMI) for Service Organizations. Technical Note CMU/ 2003-TN-005, 2003.
CMMI Interpretive Guidance Project. Special Report CMU/ 2003-SR-007.
Bruce Allgood, Mile Phillips, CMMI v.1.1 Tutorial. SEI, 2002.
Тема: Моделі зрілості по управлінню проектами інформатизації (cmmi)
1. Варіанти і основні компоненти CMMI
В ІТ-індустрії відзначається різке зростання інтересу до моделі якості СММ/CMMI, прийнятої сьогодні в усьому світі.
СММ (Capability Maturity Model) - це система оцінки й перевірки можливостей компанії, зрілість якої відповідає одному з п'яти рівнів.
Рисунок 1 – Рівні зрілості організації
Рівень 1: початковий (initial). Чітка організація процесів відсутня, процеси непередбачені, немає визначених правил і процедур розробки, успіх програмних проектів звичайно є заслугою окремих осіб.
Рівень 2: керований (managed). Процеси визначаються й документуються, але вони сфокусовані на організації конкретного проекту, тобто не стандартизовані й можуть різнитися в різних проектах.
Рівень 3: визначений (defined). У всіх проектах процеси відповідають заданому корпоративному стандарту, так званому стандартному процесу організації.
Рівень 4: керований на базі кількісних показників (quantitatively managed). Процеси стають передбачуваними й з'являється можливість управляти такими параметрами проекту, як кількість помилок, трудомісткість, обсяг переробок і т.д.
Рівень 5: оптимізований (optimizing). Процеси перебувають у стані постійного вдосконалювання, компанія може впроваджувати істотні інновації в процеси на основі аналізу кількісних показників, ідентифікувати кореневі причини проблем проектів і запобігати їхню появу.
Модель СММ Capability Maturity Model була розроблена в 1991 році Інститутом програмної інженерії Університету Карнегі-Меллона (Software Engineering Institute, SEI) для розробки програмних продуктів. Із часом було випущено ціле сімейство моделей: SW-CMM - для програмних продуктів, SE-CMM - для системної інженерії, Acquisition CMM - для закупівель, People CMM - для управління людськими ресурсами, ICMM - для інтеграції продуктів.
Різноманітні моделі виявилися досить складними для розуміння й упровадження. Оскільки вони були створені різними групами фахівців, зміст цих моделей не завжди був узгодженим один з одним, а також з вимогами міжнародних стандартів. Тому в 2002 році SEI опублікував нову модель CMMI (Capability Maturity Model Integration), що поєднує раніше випущені моделі й ураховує вимоги міжнародних стандартів.