ALL(PDF)

•підготовку аналізу,

•забезпечення участі всіх зацікавлених сторін,

•засідання,

•визначення, документування й простежування необхідних дій,

•підготовку й передачу учасникам звіту про результати аналізу.

5.Виконання угоди (продовження)

б) Технічні наради мають на меті вирішення таких питань:

•ознайомлення постачальника з потребами й очікуваннями клієнта;

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

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

•одержання технічної інформації про продукти постачальника;

•надання постачальникові необхідної технічної інформації й підтримки.

5. Виконання угоди (продовження)

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

Управлінський аналіз може бути сполучений із технічними нарадами.

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

5. Виконання угоди (закінчення)

Рекомендовані робочі продукти - результати даного етапу:

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

•матеріали й звіти про спільні з постачальником аналізи,

•розпочаті коригувальні дії,

•документування результатів поставки продуктів і документації.

6.Приймання продукту й передача продуктів у проект

Перед прийманням продукту повинні бути завершені приймальні перевірки й тести.

6.Приймання придбаного продукту включає цілий ряд дій:

•розробка процедур приймання;

Тема. СММІ: Моніторинг і контроль проекту Контроль і моніторинг необхідні для розуміння того, у якому

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

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

Ця група процесів містить у собі:

1.моніторинг параметрів планування;

2.моніторинг зобов'язань учасників;

3.моніторинг проектних ризиків;

4.моніторинг управління даними;

5.моніторинг залучення зацікавлених сторін;

6.проведення аналізу ходу виконання проекту;

7.проведення аналізу виконання етапів проекту;

8.аналіз проблем;

9.прийняття коригувальних дій;

10.виконання коригувальних дій.

Загальна схема моніторингу й контролю проекту показана на рис. 1.

Рис. 1. Схема моніторингу й контролю проекту

Моніторинг 1.Параметри планування проекту звичайно є найбільш типовими показниками прогресу у виконанні

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

Суть моніторингу параметрів полягає в наступному:

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

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

Наприклад, моніторинг вартості й трудовитрат включає: періодичні вимірювання фактичних трудовитрат, вартості й людських ресурсів; порівняння фактичних трудовитрат, вартості, використаних

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

Всі значні відхилення від параметрів планування повинні документуватися.

2.Моніторинг зобов'язань учасників і інших зацікавлених сторін включає: регулярний аналіз зобов'язань учасників - як внутрішніх, так і зовнішніх; виявлення зобов'язань, які не були виконані або котрі перебувають під загрозою невиконання; документування результатів аналізу.

3.Моніторинг проектних ризиків включає: періодичний аналіз і документування проектних ризиків

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

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

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

Рекомендовані робочі продукти - результати даного етапу: записи про результати моніторингу.

6. Аналіз виконання Ціль проведення аналізу ходу виконання проекту - надати зацікавленим сторонам інформацію.

Такого роду аналіз може мати неформальний характер і може бути встановлений у явному виді в плані проекту.

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

Аналіз ходу виконання проекту включає:

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

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

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

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

документування результатів аналізу;

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

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

Аналіз виконання етапів проекту включає:

зобов'язання учасників, актуальність плану, стан робіт, проектні ризики;

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

документування результатів аналізу, запропонованих дій і ухвалених рішень;

простежування запропонованих дій до їхнього завершення.

Рекомендовані робочі продукти - результати аналізу ходу виконання проекту й аналізу виконання етапів проекту: документовані результати аналізу.

9. Аналіз проблем і коригувальні дії Ціль етапу аналізу проблем - зібрати й проаналізувати проблеми й визначити, які коригувальні дії

варто почати для їхнього вирішення.

Проблеми й питання, що вимагають вирішення, звичайно виявляються в ході аналізу й при виконанні процесів. Необхідно фіксувати: проблеми й невідповідності, виявлені в процесі валідації й верифікації; значні відхилення параметрів планування проекту від їхніх оцінок; невиконані зобов'язання (як внутрішні, так і зовнішні); значні зміни в статусі ризиків; проблеми доступу до даних, збору даних, конфіденційності й безпеки даних; проблеми, пов'язані із залученням зацікавлених осіб.

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

Рекомендовані робочі продукти - результати етапу аналізу проблем: перелік проблем, що вимагають прийняття коригувальних дій.

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

Коригувальні дії, як і будь-які зміни зобов'язань, варто обговорити й погодити із зацікавленими сторонами.

Рекомендовані робочі продукти - результати даного етапу: план коригувальних дій.

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

Рекомендовані робочі продукти - результати даного етапу: результати коригувальних дій.

Література

1.CMMI-SE/SW Version 1.1,Staged Representation, Technical Report CMU/ 2002-TR-012, SEI.

2.CMMI-SE/SW Version 1.1, Continuous Representation, Technical Report CMU/ 2002-TR-012, SEI.

3.Boris Mutafelija, Harvey Stromberg, Systematic Process Improvement Using ISO 9001:2000 and CMMI. SEI, 2003.

4.Interpreting Capability Maturity Model Integration (CMMI) for Service Organizations. Technical Note CMU/ 2003-TN-005, 2003.

5.CMMI Interpretive Guidance Project. Special Report CMU/ 2003-SR-007.

6.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), що поєднує раніше випущені моделі й ураховує вимоги міжнародних стандартів.

В основі CMM/CMMI лежить поняття процесу.

Модель CMMI випущена у двох варіантах - безперервне подання й стадійне подання. Безперервне подання CMMI розглядає чотири категорії процесів:

-управління проектами,

-підтримка,

-інженерія,

-управління процесами.

Таблиця 1 - Групи процесів по категоріях процесів безперервного подання CMMI

В основі безперервного подання лежить концепція можливостей процесів у певній області (6 рівнів). Організація може зосередитися на тій групі процесів, що є для неї найбільш критичною. У цьому випадку можна говорити про рівень потенційних можливостей для обраної групи процесів. Це означає, наприклад, що організація може досягти 5-го рівня потенційної можливості по управлінню проектами й залишатися нижче 2-го рівня потенційної можливості по управлінню процесами.

обставин, що супроводжують впровадження моделі.

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

2. Модель CMMI у плануванні проекту

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

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

CMMI включає в управління проектами такі групи процесів:

планування проекту;

контроль і моніторинг проекту;

управління постачальниками;

інтегроване управління проектом;

управління ризиками;

кількісне управління проектом.

До другого рівня зрілості відносяться такі групи процесів: планування проекту, контроль і моніторинг та управління постачальниками.

До третього рівня зрілості відноситься управління ризиками й інтегроване управління проектом, і, нарешті, кількісне управління проектом - до четвертого рівня.

Завдання групи процесів «Планування проекту» - установити й підтримувати плани, у яких визначені всі необхідні для виконання проекту дії. Загальна схема процесу «Планування проекту наведене на рис. 4.

Проектні

згоду

виконавців

Моніторинг і контроль

Рисунок 4. Загальна схема планування проекту

В CMMI широко використовується термін план проекту.

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

Тому в дане поняття включаються: план управління проектом, план управління ризиками, план вимірювань, план навчання й т.д.

Для встановлення ефективного процесу планування CMMI рекомендує:

1.оцінити обсяг проекту;

2.установити оцінки робочих продуктів і характеристик виконуваних завдань;

3.визначити життєвий цикл проекту;

4.оцінити трудовитрати й вартість;

5.установити бюджет і графік проекту;

6.визначити проектні ризики;

7.планувати управління проектними даними;

8.планувати ресурси (скласти ресурсний план),

9.планувати необхідні знання й навички (скласти план навчання);

10.планувати залучення зацікавлених осіб;

11.установити план проекту;

12.проаналізувати плани;

13.погодити рівні робіт і ресурсів;

14.дістати зобов'язання учасників по виконанню плану.

Оцінка обсягу проекту

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

проектні вимоги (вимоги до продукту, вимоги, що накладаються організацією, вимоги, що накладаються клієнтом тощо);

обсяг проекту;

встановлені завдання й робочі продукти;

технічний підхід;

обрана модель життєвого циклу проекту (наприклад, водоспад, ітеративна, спіральна);

атрибути робочих продуктів і завдань (наприклад, розмір або складність);

графік;

методологія (моделі, дані, алгоритми) визначення необхідних матеріалів, знань, робочого часу і вартості.

Загальна схема процесу оцінок представлена на рис. 5.