ТЕМА 10
МЕТОДИ КЕРУВАННЯ ПРОГРАМНИМ ПРОЕКТОМ

 

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

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

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

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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

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

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

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

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

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

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

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

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

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

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

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

В інституті керування проектами США накопичений досвід з створення різних технічних проектів систематизовано у вигляді ядра знань – РMBOK (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).

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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

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

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

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

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

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

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

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

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

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

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

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

 

Рис. 10.1. Профіль процесу керування проектом

 

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

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

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

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

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

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

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

 

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

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

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

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

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

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

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

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

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

До них відносять такі групи:

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

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

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

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

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

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

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

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

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

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

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

У його функції входять:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

Рис. 10.2. Модель відповідальності осіб в проекті

 

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

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

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

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

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

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

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

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

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

– керування ризиками;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

10.2.1. Метод критичного шляху – СРМ

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

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

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

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

 

Рис. 10.3. Граф завдання строків виконання робіт

 

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

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

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

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

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

 

10.2.2. Метод аналізу й оцінки проекту – PERT

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

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

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

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

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

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

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

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

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

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

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

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

 

Рис. 10.4. Вид графа робіт і строків (на дугах) для проекту

 

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

1) Оптимістичної (ПРО).

2) Песимістичної (P).

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

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

Рис. 10.5. Кроки складання графіка робіт на проекті

 

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

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

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

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

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

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

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

 

Рис. 10.6. Операційний граф плану проекту

 

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

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

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

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

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

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

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

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

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

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

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

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

 

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

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

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

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

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

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

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

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

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

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

Наприклад, вартість проекту визначається за формулою: E = (a+bSc) m (X), де S − розмір системи, а, в, с − емпіричні константи, Х − вектор чинників вартості розмірністю n, − регулюючий множник за витратами чинників.

У [10] пропонується модель у вигляді співвідношення, отриманого експериментальним шляхом: E = 5.25S0.91. Ця модель застосовувалася для оцінки проекту, у якому програмні системи мали розмір від 4000 до 467000 рядків коду, 28 різними мовами програмування високого рівня для 66 комп’ютерів, і на які витрачено від 12 до 11758 людино-місяців.

Крім того, пропонується техніка моделювання, що використовується в рівнянні витрат організації-розробника: E = 5.5+0.73S1.16.

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

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

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

На третьому процесі оцінка належить до завершеного проектування, коли розмір системи визначається у термінах готових рядків програми й інших чинниках. Базовою моделлю оцінки слугує таке рівняння: E=bSc m(X), де первинна оцінка b Sc коригується за допомогою вектора вартості m (X). Ця модель розвивається з урахуванням аналізу об’єктів (число старих і нових об’єктів). Параметр с у рівнянні змінюється від 0 до 1.0 для першої стадії й від 1.01 до 1.26 для інших.

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

збиток до мінімізації – збиток після мінімізації

ціна мінімізації ризику

 

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

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

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

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

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

5. Невдала постановка вимог. 6. Постійна зміна вимог.

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

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

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

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

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

 

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

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

 

Рис. 10.7. Схема формування версії ПС

 

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

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

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

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

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

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

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

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

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

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

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

4. Аудит конфігурації (Configuration Audit).

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

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

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

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

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

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

 

Рис. 10.8. Види діяльності керування конфігурацією

 

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

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

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

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

Після внесення змін проводять контроль поточної версії системи з використанням вихідних кодів систем, що у репозиторію, інструментів контролю які є у фірмах Rational’s ClearCase й SourceSafe of Microsoft, а також формується версія системи. Після завершення змін і випробування системи проводять тиражування версії системи з її конфігурацією та документації для передачі замовникові.

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

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

До засобів планування належать:

– система керування кодами компонент, їхнім перекладом й об’єднанням у конфігурацію системи;

– базові бібліотеки й ресурси;

– спеціальні групи контролю системи і її конфігурацій;

– СКБД для ведення проекту й зберігання змін у системі.

Основними завданнями цього планування є:

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

– визначення людино-годин й інструментальних ресурсів, стандартів, витрат для внесення змін та ін.;

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

– визначення послідовності робіт керування конфігурацією.

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

Ідентифікація елементів конфігурації. Її виконують методами структуризації, класифікації й іменування елементів системи і її версій. З ідентифікацією пов’язано:

– визначення стратегії ідентифікації для отримання врахованої версії системи;

– іменування елементів системи і всієї її конфігурації;

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

– ведення версії системи (або її частин) і документування;

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

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

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

– конфігурації продукту і її версій;

– контрольованих одиниць конфігурації і їхніх версій;

– всіх складових конфігураційного базису і їхніх редакцій.

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

 

10.4.1. Формування версій й контроль конфігурації

Версія системи містить у собі елементи конфігурації й варіант версії системи для передачі замовнику [8, 13]. Керування версіями полягає у виконанні дій:

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

– вибору інструментарію побудови версії, оцінки можливостей середовища й засобів автоматизації процесу побудови окремих версій з коректною конфігурацією ПС і даних;

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

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

Яскравим прикладом формування 21 версії на ОС 360 (1965–1980р.) є фірма IBM. В ОС постійно й поетапно додавалися нові функціональні можливості й вносилися зміни до попередньої версії при її експлуатації [9]. Над розвитком додаткових можливостей даної ОС і внесення змін у попередню версію постійно працював колектив фірми. Трудомісткість розробки чергової версії ОС вважалася пропорційною інтервалу часу між реєстраціями чергових версій і приймалася за одиницю виміру складності створення нової версії [8].

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

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

Як результат з’явилося поняття «критичної маси» або критичної складності системи, що модифікується. Якщо при модернізації й випуску чергової версії системи обсяг доробок перевищує «критичний», то зростає ймовірність погіршення характеристик або необхідність введення проміжної версії із внесенням деяких змін. «Критичний» обсяг доробок ОС–360 близько 200 модулів залишався постійним, незважаючи на підвищення кваліфікації колективу, удосконалення технічних і програмних засобів тощо. У перших версіях обсяг доробок становив 20% модулів, а в останніх версіях знизився до 5%.

Контроль конфігурації – це перевірка її правильності і випробування розгортки конфігурації в процесі експлуатації системи. Він містить у собі безперервні коректування, які стосуються вже погодженого й/або затвердженого конфігураційного базису. Це обумовлює такі об’єкти контролю:

– зміни в затвердженому базисі і пов’язані з ними коректування елементів конфігурації;

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

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

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

1. Реєстрація пропозиції /запиту на зміну.

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

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

4. Реалізація затвердженої зміни і її верифікація.

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

– реєстрація інформації про отриманий дефект /відхилення;

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

– прийняття рішення з усунення дефекту/відхилення, реалізація й верифікація цих недоліків.

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

Найзручнішою формою реалізації такого рішення є рада керівників з контролю конфігурації CCB (Configuration Control Board), як родоначальника теорії й практики керування конфігурацією.

 

10.4.2. Облік статусу й аудит конфігурації

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

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

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

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

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

Конфігураційний аудит – це:

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

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

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

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