Основні поняття життєвого циклу та процесу менеджменту проекту

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Вступ

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

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

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

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

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

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

Мета роботи - охарактеризувати основні поняття життєвого циклу та процесу менеджменту проекту.

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

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

Робота складається з 4-х розділів, вступу, висновків, переліку посилань на використані джерела.

1. Менеджмент проекту

Термін «проект» (від лат. Projectus - кинутий вперед) вперше було застосовано Юлієм Цезарем в Записках про Галльську війну.

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

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

1.1 Основні поняття та задачі

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

Кожний проект має такі особливості:

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

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

- послідовність розробки від задуму та початку розроблення проекту до закінчення та утилізації всіх його компонентів. Таку послідовність називають ЖЦ проекту [2-6] і означає поступове виконання робіт проекту.

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

- тимчасовість, тобто будь-який проект має чіткий початок і чітке завершення, коли досягнуто цілі проекту чи стає зрозумілим, що цілі будуть, або не можуть бути досягнуті. Термін «тимчасовий» не обов'язково означає коротку тривалість проекту, він може викоатися декілька років, але в будь-якому разі його обмежують часом робіт;

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

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

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

З менеджментом проекту пов'язано поняття - масштаб проекту або «зміст і межі проекту». Іншими словами, масштаб проекту (Project Scope) - це сукупність мети проекту та запланованих витрат часу і засобів. Тобто це своєрідний тривимірний простір (мета-час-гроші), у якому живуть учасники та виконавці проекту та і сам проект.

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

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

1.2 Головні цілі менеджменту проекту

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

У процесі керування проектом розв'язуються такі задачі:

- дотримання директивних строків завершення проекту;

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

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

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

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

1. Формування плану його виконання.

2. Контроль (відстеження, спостереження, тренінг) за реалізацією плану та керуванням проектом.

3. Завершення проекту.

Чим якісніше будуть реалізовані ці процеси, тим вище вірогідність успішного виконання проекту.

В інституті керування проектами США накопичений досвід з створення різних технічних проектів систематизовано у вигляді ядра знань - PMBOK (Project Management Body of Knowledge, www.pmi.org/publication/download/2000welcome.

У цьому ядрі малими проектами вважаються ті, що містять у собі 100 робіт і 15 виконавців, середніми - 500 робіт і 50 виконавців і великими - 1000 робіт і 100 виконавців.

У ядрі РМВОК визначені основні задачі розробки проектів:

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

- ефективна організація проектної групи (команди);

- застосування інструментарію менеджера проекту (наприклад, системи Project Management фірми Microsoft та Microsoft Visual Studio Team System 2005).

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

1.3 Процес менеджменту проекту

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

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

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

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

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

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

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

Реалізація. Перетворення проектних рішень щодо реалізовані компонентів системи з визначеним їх складом.

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

Експлуатація та супроводження готової ПС для проекту.

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

На основі випробування в систему додаються нові функції або виконуються необхідні зміни при виявленні помилок або неточного виконання деяких вимог. Взагалі кінцевий програмний код системи будується шляхом системної інтеграції готових програмних компонентів, включаючи системні та мережні компоненти (СКБД, ОС, протоколи тощо), та розроблених, що становить не більше 20% загального обсягу ПС проекту. Таким чином, використовується ітеративній підхід до їх відбору, випробування та прийняття рішень про готові компоненти різного типу. Вирішення цих задач проектування виконується за допомогою методів проектного менеджменту, які розглянемо нижче.

1.4 Модель процесу керування проектом

Процес керування проектом є новим процесом ЖЦ стандарту КО/ІЕС 122072002, який був відсутній в стандарті ДСТУ 3918-99 і внесений також у нову версію ДСТУ КО 15504 (частини 1-9) 2002 року.

Згідно з цим стандартів «призначення процесу керування проектом - це ідентифікація, впровадження, координація та моніторинг дій, задач та ресурсів для вироблення продукту та/або послуг відповідно до вимог [7]. Цей процес містить у собі:

- визначення обсягу робіт за проектом;

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

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

- встановлення інтерфейсів між елементами проекту, а також з організаційними підрозділами;

- розроблення та впровадження планів виконання проекту під наглядом відповідних виконавців;

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

Як результат зазначених дій визначається структурований опис процесу керування проектом у вигляді профілю проекту, який наведено на рис. 1.1.

Наведемо трактування складових цього загального процесу.

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

Метрики процесу - це сукупність методів і шкал для вимірювання розміру і складності об'єктів діяльності, а також вартості, трудомісткості і тривалості процесу.

Міжнародні і вітчизняні стандарти, що стосуються планів процесу, а також методів і засобів виконання - профіль стандартів.

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

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

Головним, центральним поняттям моделі є робота, яка пов'язана з розробленням програмного проекту.

Визначення складу робіт, їхніх зв'язків, планів їх виконання (упорядкування у часі та умов виконання), розподілу ресурсів проекту та контролю виконання з урахуванням вимог та угод замовника - сутність керування проектом.

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

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

1.5 Інфраструктура програмного проекту

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

Складовими ресурсами цієї інфраструктури є такі:

- техніка та комунікації (комп'ютери, файли і сервери; локальні та глобальні мережі; електронна пошта (e-mail); техніка налагодження; офісна техніка тощо).

- загальносистемне ПС та інструменти (клієнт/серверні технології; ОС; системи документообігу; утиліти; засоби захисту інформації, CASE-інструменти, системи програмування, графічні інструменти, СКБД тощо);

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

- стандарти програмної інженерії з ЖЦ, визначення інтерфейсів, між проектної взаємодії, якості, вимірювання тощо;

- кадрові питання відображають усе, що пов'язано з підготовкою персоналу для виконання різнопланових робіт у проекті, а також з вивченням сучасних систем знань (ядро знань SWEBOK, PMBOK, засоби Інтернету тощо) для досягнення необхідного рівня реалізації проекту.

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

- техніко-технологічної підтримки (вивчення ринку, придбання Case, ПС, консультації співробітникам, тощо);

- захисту інформації (забезпечення засобами захисту і перевірки інформації в проекті);

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

- якості (SQA-група), у функції якої входить планування та виконання дій ЖЦ, дотримання дисципліни створення проекту, перевірки робіт у контрольних точках проекту, контроль якості робочих продуктів і документів з ПС тощо;

- верифікації і валідації, які проводять кваліфікаційне тестування компонентів ПС або продукту на правильність,

- координування планів робіт з менеджером проекту з вимог до ПС, перевірку виконання вимог (валідація) та тестового середовища;

- керівника проекту, яка відповідає за фінансові і технічні ресурси проекту, виконання проектних угод замовника та визначеного середовища для розроблення складових проекту;

- менеджера проекту, відповідального за розроблення проекту на основі вимог, проектних рішень і планів робіт на проекті і їхньої реалізації;

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

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

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

- розроблення моделі ЖЦ і погодження її з керівником проекту системи;

- підключення до проекту фахівців розглянутих груп;

- координація всіх груп програмного проекту між собою;

- визначення стратегії дій в різних точках процесу ЖЦ з продовження роботи або її закінчення;

- розроблення основних документів проекту і керування верифікацією функцій на процесах ЖЦ і валідацією продукту на відповідність вимог замовника.

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

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

Менеджер підбирає для вдалої організації ведення проекту підбирає стиль ведення проекту, наприклад, стиль фірми IBM, який склався при розробленні проекту всесвітньо відомої ОС IBM-370. У ньому проектування ОС і розроблення її продукту виконував головний програміст і група програмістів.

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

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

Альтернативна структура ведення проекту описана Вейнбергом (Weinberg), так зване знеособлене програмування, коли всі несуть однакову відповідальність за якість продукту. У проекті не концентруються на персоналіях, критиці піддається програмний продукт, а не члени групи. Така структура підходить для маленьких груп програмістів.

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

Моделювання робіт у проекті. У військових відомствах розроблено загальну структуру команди для створення інтегрованого продукту (Integrated Product Development Team).

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

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

Під час розроблення проекту обов'язки і ролі співробітників постійно змінюються. Це зручно для проекту, у якому часто змінюються плани, для них встановлюються строки в межах тижня або навіть годин. Показником того, якою мірою виконано завдання, є діаграма запланованих і реально виконаних робіт. Часто ця модель обов'язків поєднується з моделлю «з рук у руки» (hand-off). Вона припускає передачу результатів робіт однієї групи для роботи іншій групи.

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

Відповідно до світової статистики не всі реалізовані програмні проекти завершуються успішно, 33% з них є провальними з таких причин:

- вимоги замовника не виконуються,

- проект не вклався у вартість,

- проект не вклався в заданий термін,

- етапи робіт виявилися неузгодженими один з одним,

- менеджер не орієнтує розробників на застосування новітніх методів і засобів програмування, планування й дотримання стандартних угод на застосування моделі ЖЦ.

Основні положення керування проектом, завдання й методи якого відпрацьовувалися на технічних проектах (наприклад, перший проект розробки лайнера для перевезення пасажирів з Європи в Америку), призвели до того, що Генрі Гант уперше запропонував діаграмну схему обліку часу виконання проекту. Сьогодні ці завдання сформульовано в такий спосіб:

- планування проекту й складання графіків робіт виконання проекту,

- керування проектними роботами і командою виконавців,

- керування ризиками,

- оцінювання продукту й використовуваних процесів з метою вдосконалення тощо.

На практиці процес керування проектом містить у собі:

- визначення обсягу робіт в рамках задач проекту з урахуванням наявних ресурсів та обмежень;

- розроблення стратегії реалізації цілей проекту з урахуванням ризиків та сприятливих можливостей;

- вибір та обґрунтування моделі ЖЦ, адекватної розміру, складності та цілям проекту;

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

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

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

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

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

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

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

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

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

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

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

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

Відомими методами керування проектами є метод критичного шляху СРМ (Critical Path Method) та PERT (Program Evaluation and Review Technique). Останній метод відомий у СРСР як ПЕРТ, що був створений у 1958 р. групою керування спеціальними проектами. Розглянемо їх.

2.1 Метод критичного шляху - СРМ

Цей метод було створено при дослідженні можливості ефективного використання обчислювальної машини Univac на фірмі Dupon для планування й складання планів-графіків великих комплексів робіт для модернізації заводів цієї фірми. Як результат було розроблено раціональний і простий метод (Уолкера - Келлі) керування проектом з використанням ЕОМ, що було названо методом критичного шляху CPM.

Критичний шлях - послідовність робіт, з'єднаних початковою і кінцевою роботами, відображаючи найдовший повний шлях у мережі. Наприклад, на (рис. 2.1), критичний шлях це:

Початок робіт, А1, А3, А6, кінець робіт.

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

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

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

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

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

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

2.2 Метод аналізу й оцінки проекту - PERT

Паралельно з розробкою CPM, у військово-морських силах США було створено (фірма «Буз, Аллен & Гамільтон») метод аналізу й оцінки програм PERT для реалізації проекту розробки ракетної системи «Polaris», що поєднує близько 3800 підрядників із числом операцій більш як 60 тис.

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

програмою створення ракетної системи виявилося настільки успішним, що проект було завершено на два роки раніше запланованого строку.

Метод PERT представляється мережевими діаграмами з вершинами-подіями, а робота - у вигляді лінії між двома подіями з наступними призначеннями (рис. 2.2):

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

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

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

- строк - дата, до якої процес повністю або частково завершує своє виконання.

Дузі, що виходить з початкової вершини й входить у кінцеву вершину, відповідає часова позначка 0, а на інших дугах - час виконання.

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

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

Розбіжності між цими розглянутими двома методами мережевого графового подання методами CPM і PERT незначні. Однак метод PERT, на відміну від CPM, ураховує виникаючі невизначеності в часі виконання кожної операції.

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

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

- оптимістичної (ПРО),

- песимістичної (P),

- імовірнісної (B).

Цей час визначають за формулою: (ПРО+4В+Р)/6 із зазначенням його на мережевому графіку.

2.3 Планування і контроль проекту

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

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

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

- керування проектом за методами критичного шляху СРМ, PERT або іншими;

- план-графік робіт з проектування і строків їх виконання за відповідними методами керування і планування;

- розподіл робіт між розробниками відповідно плану;

- план досягнення якості, а також плани верифікації, валідації й тестування для отримання результатів проектування;

- поставки і регулювання технічних, CASE і людських ресурсів на проекті;

- супроводження, змінювання деяких вимог і усунення різних недоліків.

Керування проектом охоплює всі вказані плани і може мати в своєму складі додаткові плани, пов'язані з деякими особливостями або вказівками замовника проекту.

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

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

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

План проекту містить у собі календарний план, перелік документів та плану розроблення програмного продукту. Цей план враховує задану вартість, об'єм та план-графік робіт, відстеження ризиків і застосування затверджених методологій і інструментів розроблення проекту. Графік робіт складається за схемою, наведеною на рис. 2.3.

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

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

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

Планування за методом СРМ або діаграми Ганта, які допомагають:

- структуризації робіт на основні компоненти й підкомпоненти;

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

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

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

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

Крім того, є діаграма Ганта - це горизонтальна лінійна діаграма, на якій завдання проекту представляються строками у вигляді відрізків часу і мають дати початку й закінчення, можливо із затримками й іншими часовими параметрами.

Моніторинг проекту. Моніторинг (облік та контроль) забезпечує відстеження «факту відповідно плану» шляхом перегляду надбань та результатів у ході виконання проекту, і вироблення належних заходів з коригування. Ці заходи можуть вміщати виправлення плану розроблення ПС, щоб відобразити у ньому фактичний стан справ щодо надбань та результатів, перепланувати залишкову роботу та/або передбачити в плані дії з вдосконалення виконання роботи.

Моніторинг проводять для того, щоб фактичні результати було простежено за планами проекту з метою повернення проекту в планові рамки. При моніторингу аналізуються такі дані:

- строки (факт / план);

- витрати (матеріальні, трудові) (факт / план або% плану);

- виконана робота (% запланованої);

- об'єм документів (сторінок);

- об'єм програм за кількістю функцій кожного компонента (факт / план або% плану);

- об'єм тестування компонентів проекту (виконано / заплановано або% плану);

- безвідмовність (кількість збійних тестів/проведених або% проведених);

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

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

2.4 Оцінювання вартості проекту

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

Додаткові витрати - це вартість засобів і інструментів тестування, кодування або інші CASE системи. Основна оцінка в проекті визначає витрати на розроблення проекту, тобто людино-дні робіт виконавців проекту. Вона виконується на початку проекту й складання його плану. Оцінювання здійснюють «знизу» або «вгору». При наявності застарілої системи вартість екстраполюється на нову з деякими корегуваннями або проводиться песимістична, оптимістична і реальна оцінка шляхом опитування всіх членів робочої групи з виведенням найбільш ймовірної.

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

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

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

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

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

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

3. Методи керування ризиками у проекті

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

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

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

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

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

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

Якісна оцінка ризиків, як аналіз ризиків і умов їхнього виникнення з метою визначення їхнього впливу на успіх проекту.

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

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

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

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

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

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

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

Кількісна оцінка ризиків - це визначення ймовірності виникнення ризиків і впливів їх наслідків на проект, а прийняття правильних рішень. Ця оцінка визначає наступне:

- імовірність досягнення кінцевої мети проекту;

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

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

- фактичні витрати й передбачувані строки закінчення робіт в проекті.

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

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

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

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

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

Ціль моніторингу й контролю полягає в з'ясуванні таких ситуацій:

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

- зміна ризиків у порівнянні з попередніми значеннями;

- визначення впливу ризиків і вживання необхідних заходів;

- реакція на ризики відповідно плану.

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

Керування ризиками ґрунтується на двох основних типів ризику: загальний ризик і специфічний.

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

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

Систему керування ризиком можна представити у вигляді відношення:

збиток до мінімізації - збиток після мінімізації / ціна мінімізації ризику.

Мінімізації ризику можна досягти прототипуванням. Боєм ідентифікував 10 найпоширеніших причин ризику в проекті:

- Скорочення штату або набір некваліфікованих співробітників.

- Нереалістичні плани й бюджети в проекті.

- Розроблення функціонально неправильних програмних елементів.

- Розроблення невдалого інтерфейсу користувача.

- Невдала постановка вимог.

- Постійна зміна вимог.

- Недоліки у внутрішній організації робіт.

- Недоліки взаємозв'язку із замовником.

- Невміння працювати в реальному часі.

- Обмежені комп'ютерні ресурси.

На кожному проекті з наведених причин можуть бути присутні деякі, а не усі разом ризики. Але їх треба враховувати менеджерам, що розробляють нові проекти, щоб ризиків було як менше. Тоді проект не буде провальним.

4. Керування конфігурацією системи

ризик менеджмент управління планування

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

Елементами конфігурації є:

- одиниця конфігурації (Configuration Item) - елемент, виділений для цілей керування й обробки на процесорах комп'ютера системи;

- базис конфігурації (Configuration Baseline) - набір формально розглянутої й затвердженої основи системи із складу елементів і документації, що встановлює можливість подальшого розвитку системи;

- програмні компоненти системи.

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

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

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

Згідно з діючим стандартом IEEE Std.610-90 керування конфігурацією містить у собі такі основні завдання:

- Ідентифікація конфігурації (Configuration Identification).

- Контроль конфігурації (Configuration Control).

- Облік статусу конфігурації (Configuration Status Accounting).

...