Підготовка та планування проекту. (Тема 3) презентация

ДО ПЛАНУВАННЯ ПРОЕКТУ

1. Призначення і зміст планування проекту.
2. Виявлення зацікавлених осіб
3. Збір вимог
4. Створення концепції проекту
5. Визначення ресурсів

Після підписання Статуту починають планування.
Парадигма УП: «Що не можна спланувати, не можна зробити». Цілі планування: - нічого не забути під час виконання проекту - розуміння кожним своїх поточних задач без менеджера; - забезпечення комунікацій ( спілкування). Плани є засобом комунікації. Без них робітник не знає чим зайнятись, замовник незадоволений відсутністю результату, для якого ще не прийшов час і т. ін. План має бути: достовірним, доступним, розумно-докладним.
План – це не «клятва», а «прогноз». Оскільки ІТ- проекти не дозволяють точно прогнозувати тривалість, а часом і склад робіт, планувати треба з «діапазоном». Не давати (і не вимагати) точну оцінку там, де це неможливо. Задача планування не «вкластися до певної дати», а реалістично оцінити дату і можливі відхилення. Точність має бути більшою, ніж на етапі ініціювання (+100 /-40%.) На початку планування прийнятними є значення +25/-10%, усередині 10% і так далі. Ні коли не можна навмисно завищувати оцінки (padding) задля страховки!!! Треба чітко розуміти, що плани будуть змінюватися. На відміну від статуту, вони є дуже «живими» документами. По ходу виконання робіт будуть виявлятися нові нюанси, деталі, форс-мажори. Щоб плани залишалися достовірними їх необхідно коригувати. Але процес коригування треба заздалегідь узгодити і строго виконувати його вимоги.

ПЛАН УПРАВЛІННЯ ПРОЕКТОМ

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

ВИЯВЛЕННЯ ЗАЦІКАВЛЕНИХ ОСІБ

Для опису усіх необхідних робіт треба знати вимоги і очікування замовника,
зрозуміти, що з них можна реально здійснити, і що для цього знадобиться:
• зібрати і фіналізувати вимоги; • сформувати концепцію; • створити ІСР (WBS)
Статут містить лише високорівневі вимоги. Треба конкретизувати хто саме і що
саме хоче отримати. Треба врахувати не лише вимоги спонсора. Успішний
проект має задовольнити замовника; кінцеві користувачі мають користуватися
його результатами. Виявлення зацікавлених осіб і збір вимог є важливою і
виснажливою роботою,
без якої успіх проекту є
неможливим. Основні
персони проекту є у
Статуті. Тепер роблять
“Реєстр зацікавлених
осіб”, до якого мають
увійти десятки (часто
сотні) прізвищ:
• залучені до проекту;
• кінцеві користувачі;
• керівники членів
команди;
• усі, хто має вплив на
проект (сірі кардинали).
Не страшна кількість,
небезпечно когось
забути.

ЗБІР ВИМОГ

Виявленні достатньо загальні очікування «зацікавлених осіб» (щоб зросла
продуктивність, щоб стало зручніше), треба перетворити на вимоги.
Вимога є конкретним, вимірюваним запитом зацікавленої особи. Наприклад:
«Система має забезпечити проходження усіх сценаріїв користувача без «миші»
Необхідно вибрати методи «витягування» з зацікавлених осіб їх очікувань і
вимог, чітко розуміти потреби в інформації і здатності її надання партнером.
Основні методи:
• інтерв'ю,• опитування,• мозкові штурми (в різних варіаціях),• прототипування
Інтерв'ю (безпосереднє спілкування) – висока надійність, особистий контакт.
Але потребує багато часу, можлива недосяжна статусність.
Опитувальники –швидкий збір інформації з великої кількості людей. Але є
«однобокість» зібраної інформації, ймовірність формального підходу до анкет.
Мозковий штурм – умовне «колективним інтерв'ю». Може бути дуже ефективним,
хоча і потребує певних умов і навичок, які слід розвивати у своїй команді.
Прототипування – зрозумілий співрозмовнику образ продукту (картинка, макет,
аналог, …. Зручно поєднувати з іншими техніками (наприклад, інтерв'ю). Але
можна упустити суттєві моменти, не реалізовані в прототипі.
Збір вимог бажано вести спільно з представниками команди, що варто прописати
у Статуті. Чудово підключити фахівців зі збору й опису вимог і левову частку
турбот перекласти на них, оскільки вимоги є найбільш складною і трудомісткою
для опису «межею трикутника».
Кожен день члени команди стикаються з побажаннями зацікавлених осіб, не
врахованими раніше. У всіх співробітників має бути легкий доступ для перегляду і
поповнення знов виявлених вимог.
Важливо не забувати фіксувати вимоги, виробити єдиний для усіх учасників
процесу спосіб їх фіксування. Це можуть бути «організаційні діаграми»,”звіти”,
електронні листи, які можуть бути дуже корисними в подальшому – при виконанні
робіт, при необхідності уточнити завдання.

МАТРИЦЯ ВИМОГ

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

РОБОТА З ВИМОГАМИ

Збір вимог :у рамках початкового планування повинен бути розумно-глибоким і
максимально широким. Але їх список немає стати «фіксованим» до кінця
проекту. Проектне управління базується на роботі з очікуваннями замовника,
накопиченням його згоди, коригуванням планів всього життєвого циклу проекту.
Іноді збір вимог виділяють в окремий проект. Для відбору вимог для виконання
їм надають пріоритети, виділяють найбільш значущі, і відбірають ті з них, які
можна задовольнити у межах проектних обмежень (деякі вимоги бувають взає-
мопов'язаними і включати чи виключати їх з трикутника можна тільки разом).
На першому етапі наявні лише грубі оцінки вартості й строків проекту, точно не
відомі вибрані роботи. У поточних оцінках менеджер проекту покладається на
професійний досвід і відчуття (своє і команди). Тому після оцінки собівартості та
тривалості робіт, треба переглянути відібрані вимоги, можливо і відмовитися від
деяких з них. Але вимоги записані у Статуті є обов’язковими для виконання.
Результати збору і відбору можна затвердити у зацікавлених осіб проекту, але
не варто добре подумати, чи треба отримувати підтвердження, і у якій формі.
Де-факто, матриця вимог і є ТЗ. Але на практиці ТЗ – статичний документ, що є
невід'ємною частиною контрактів. Статичність ТЗ робить його вкрай незручним
для всіх зацікавлених осіб проекту. Правильна організація робіт з вимогами
(урахування сподівань замовника і відсікання нездійсненних вимог) знижує
ризик незадоволення очікувань замовника. ТЗ може мати зворотний ефект. Якщо ТЗ не можна уникнути, треба використати у ньому інформацію з
матриці вимог і ввести докладні описи процедури уточнення вимог. Наприклад:
«Список використовуваних в системі довідників та класифікаторів наведено у
додатку №101. Даний список може бути збільшений або скорочений не більше
ніж на 10 позицій. Про необхідність внесення змін замовник повідомляє
виконавця не пізніше 1.12.16 і надає опис. За результатами поведеного
виконавцем аналізу складається акт на основі шаблону в додатку №102.»

КОНЦЕПЦІЇ (SCOPE) ПРОЕКТУ

При створенні концепції вже відомі очікування замовника і вона має допомогти
з’ясувати як виконати обіцяне. Концепція проекту вкрай важлива для команди,
але не для замовника. «Концепція» має бути доступна власним співробітникам,
зрозуміла і прийнята ними, але залучати до її погодженням замовника не варто
Документ має бути таким, щоб при появі на проекті нового робітника, він міг
допомогти швидко розібратись у суті справ. Контракт тут не дуже допоможе.
Інформація у Статуті достатньо поверхнева. Матриця вимог пояснює що треба
Зробити, але не як працювати.
Саме концепція проекту має містити загальну як інформацію про проект, так і
посилання на різноманітні вимоги та опису продукту, так що новий робітник,
залежно від характеру своїх питань – зможе самостійно знайти максимум
інформації без сторонньої допомоги.
Не менш важливо і те, що «концепція» містить опис «проектного підходу»:
правила спілкування з замовником у проекті; узгоджені з командою
домовленості щодо проведення нарад; де можна подивитися, хто за що
відповідає у проекті; де знайти правила внесення зміни в початкові вимоги або
Як додати нові?
Концепція є наріжним каменем проекту. Сама по собі вона може бути
небагатослівна, але рясніти посиланнями на зовнішні документи (дуже
важливо уникати переписування інформації з документа до документу – це
заощадить сили і багаторазово полегшить підтримку цілісності і несуперечності
інформації).
Отож, концепція має забезпечити будь-якому члену команди (будь то
розробник, тестувальник або найнятий для консультацій експерт) можливість
максимально чітко уявити собі загальну задачу і свою конкретну роль. Важливо
зробити концепцію доступною і проінформувати про неї всіх учасників.

ВИЗНАЧЕННЯ РЕСУРСІВ

Наявність Статуту, вимог і концепції забезпечує планування ресурсів. Ця тема
поверхнево обговорюється зі спонсором при ініціації, і тепер опрацьовується
детально. Чи доступні співробітники з потрібною кваліфікацією? Чи потрібне
специфічне обладнання, особливі ліцензії? Для проведення таких оцінок
потрібний добре спланований зміст проекту і розуміння доступних ресурсів і
можливостей всередині організації. Для цього необхідний діалог з власниками
ресурсів. Головна задача – донести суть виконуваних робіт (тут працюють такі
документи, як концепція, матриця вимог). Треба пояснити власнику ресурсів
Що треба зробити команді в рамках проекту і попросити допомоги у
визначенні з необхідними для такої роботи навичками і/або обладнанням.
Друге важливим питання, крім «хто потрібен?», є питання «хто є наявний?».
Чи є співробітники з необхідною кваліфікацією? Чи потрібні для роботи
спеціальна ліцензії, чи є вона у наявності, і.т.д. Якщо ресурси наявні, треба
з'ясувати, коли і на який термін їх можна задіяти у проекті. Можливо, єдиний
підходящий фахівець вже задіяний на 120% до кінця року? Чи буде потрібний
сервер у вільному розпорядженні проекту, чи доступ до нього буде обмежено?
Це може бути приводом для проведення закупівель чи залучення підрядників.
Залучення сторонніх організації до виконання великих проектів є звичайною
практикою, якщо це не суперечить контракту або політики компанії. Субпідряди
часто знижують ризики проекту. Варто використовувати субпідряди: якщо
відчувається дефіцит власних ресурсів; якщо треба підвищити керованість
проекту; якщо є необхідність використання патентів / сертифікатів і т. п. Іноді
керованість проекту легше зберегти, надав блок робіт сторонньої компанії, ніж
контролювати власних співробітників, якщо ті, час від часу переміщуються на
інші проекти, а на проект приходять ще “не занурені” у нього.\
Після визначення «Хто потрібний?», «Хто є?», «Кого дають?», чи доцільним є
залучення підрядників треба сформувати «список ресурсів».

ТЕМА 4. ПЛАНУВАННЯ РЕСУРСІВ

1. Уточнення змісту і складу робіт.
2. Планування управління змістом
3. Планування організаційної структури
4. Планування управління конфігураціями.
5. Планування управління якістю

Для планування робіт проекту, необхідно, послідовною декомпозицією розбити
основну задачу проекту на підзадачі, аж до рівня тривіальних задач. При цьому
утворюється ієрархічна деревовидна структура, у корені якої знаходиться
проект, а на листках - елементарні завдання або тривіальні роботи, які треба
виконати для завершення проекту в умовах заданих обмежень. Згідно РМВОК
ієрархічна структура робіт (ІСР) (Work/Breakdown Structure, WBS ) є
орієнтованою на результат ієрархічною декомпозицією робіт, виконуваних
командою проекту для досягнення цілей проекту і необхідних результатів. З її
допомогою структурується і визначається весь зміст проекту. Кожен наступний
рівень ієрархії відображає більш детальне визначення елементів проекту .
Основою для розробки ІСР служить концепція проекту, яка визначає продукти
проекту та їх основні характеристики. ІСР забезпечує виявлення всіх робіт,
необхідних для досягнення цілей проекту. Багато проектів провалюються не від
відсутності плану, а від того що в цьому плані забуті важливі роботи (наприклад
тестування і виправлення помилок), і продукти проекту (документація
користувача). Тому, якщо ІСР складена коректно, то будь-яка робота, яка не
увійшла до неї, не може вважатися роботою за проектом. ІСР ділить проект на
підпроекти, пакети робіт, підпакети. Кожен наступний рівень декомпозиції
забезпечує послідовну деталізацію змісту проекту, що дозволяє робити оцінку
термінів та обсягів робіт. ІСР повинна включати всі проміжні та кінцеві продукти.

у такому:
Кожний елемент WBS є такою дискретною часткою проекту, до якої можна
застосувати управління, планування і контроль, з власними постачальниками,
планами, системою контролю й аналізу виконання витрат, ресурсів, графіку.
2. Проект розбивається на кілька рівнів. Найнижчий рівень WBS створюється
найменшими дискретними частинами проекту, які потребують планування і
контролю як інтегрованого цілого. Вони не діляться далі, хоча можуть бути
розподілені на роботи для окремих груп виконавців, як окремі одиниці.
3. Не треба ділити кожний основний елемент проекту на однакову кількість
рівнів. Цей поділ має служити розумним цілям і виконуватися помірковано.
4. Кожний елемент вищого рівня WBS є складовою проекту, яка планується і
контролюється як інтегроване ціле. Це потребує поєднання планування і
контролю елементів нижчого рівня та елементів більш високого рівня.
5. Кожний рівень у структурі потребує збору й аналізу контрольної інформації і
кожний елемент цього рівня має свій аналіз виконання та звіт.
6. Не треба ділити проект на велику кількість рівнів заради самої структури.
Кожний рівень має бути значним, логічним і необхідним для управління,
планування та контролю проекту. Кожний додатковий рівень WBS значно
збільшує обсяг інформації, що збирається, роботи з паперами і потрібними
звітами, але скорочує обсяг діяльності функціональних груп.
7.Для більшості проектів характерною є кількість рівнів від чотирьох до шести. У
простих випадках достатньо двох рівнів.
8. У великих проектах, до виконання залучаються окремі компанії-виконавці,
можуть бути дві групи WBS: одна - для проекту в цілому, інші – для компаній.
9. Робота, спільна для більш ніж одного елементу WBS на будь-якому одному її
рівні, постає як окремий елемент WBS. Проте робота, що є унікальною для
одного елементу, включається у цей елемент як його складова на нижчому рівні

Виконувати декомпозицію робіт проекту можна по-різному. Наприклад, ГОСТ
19.102-77 передбачає каскадний підхід і визначає такі стадії розробки ПЗ:
1.ТЗ 2. Ескізний пр-т 3. Технічний проект 4. Робочий проект 5. Впровадження
Згідно стандарту, на першому рівні ІСР знаходяться саме ці проектні продукти.
Але сучасний процес розробки комерційного ПЗ має бути інкрементальним.
Отож, на верхньому рівні декомпозиції проекту мають знаходитися продукти
проекту, на наступному рівні - компоненти, з яких ці ​​продукти складаються, далі
функції, які мають реалізовувати компоненти.
Компоненти програмної системи
виділяють на фазі планування проекту, не чекаючи опрацювання всіх
функціональних вимог до розроблюваного ПЗ. Компонентами можуть бути як
прикладні підсистеми, так і інфраструктурні або ядерні, наприклад, підсистема
під’єднання (легування), безпеки, бібліотека візуальних компонентів GUI.
Результатом розробки ІСР є визначення груп індивідуальних порцій робіт.
Відповідальність за кожну елементарну роботу доручається одному члену
команди проекту.
Головна задача складання ІСР - розділ проекту на підпроекти до рівня, коли
з'явиться можливість розподілити елементарні роботи. Отже, на самому
нижньому рівні будь-якого проекту повинен бути опис індивідуальної порції
роботи, яка може бути виконаний однією людиною (або групою людей). Ця
людина (або група) дійсно буде виконувати цю роботу, а не керувати її
виконанням. Цей рівень називається рівнем задач (task level) або рівнем
операцій (асtivity level).
Внаслідок розбиття проекту на підпроекти і досягнення рівню пакетів робіт,
насправді вдається визначити близько 90% від загального обсягу робіт, що
необхідно виконати. Після чого з’являється можливість більш точного
визначення решти необхідних робіт.

ТА ІСР

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

ПРИКЛАД ІСР-1

Наприклад, фрагмент ІСР проекту розробки «Автоматизованої системи
продажу документації» може виглядати таким чином:
1. Проект розробки « Автоматизованої системи продажу документації»
1.1. Підготовка технічного завдання на автоматизацію
1.1.1.1. Проведення аналітичного обстеження
1.1.1.2. Розробка функціональних вимог
1.1.1.3. Розробка вимог базового ПЗ
......
1.1.1.5. Узгодження і затвердження ТЗ
1.1.1.6. ТЗ затверджено (контрольна точка проекту)
1.2. Поставка та монтаж обладнання
1.2.1. Розробка специфікації на обладнання
1.2.2. Закупівля і постачання устаткування
……
1.2.5. Монтаж устаткування завершений (контрольна точка)
1.3. Постачання і установка базового ПЗ
1.3.1. Розробка специфікацій на базове ПЗ
1.3.2. Закупівля базового ПО
1.3.3. Розгортання та налаштування базового ПЗ
1.3.4. Базове ПЗ встановлено у замовника (контрольна точка)
1.4. Розробка і тестування прикладного ПЗ
1.4.1. Розробка специфікацій на прикладне ПЗ
1.4.2. Установка і конфігурація робочого середовища
1.4.3 . Проектування і розробка ПЗ
1.4.3.1. Авторизація та аутентифікація користувачів.
1.4.3.2. Розробка підсистеми замовлення документації
1.4.3.2.1. Перегляд каталогу продуктів.

ПРИКЛАД ІСР-2

1.4.3.2.2. Пошук продуктів по каталогу.
…..
1.4.3.2.5. Інформування клієнта про зміну статусу замовлення.
1.4.3.2.6. Підсистема замовлення документації передана в тестову експлуатацію (на серверах розробника) (контрольна точка).
1.4.3.3. Розробка підсистеми обробки замовлень
1.4.3.3.1. Перегляд та обробка замовлень виконавцями служби продажів.
1.4.3.3.2. Перегляд статистики надходження і обробки замовлень.
1.4.3.3.3. Підсистема обробки замовлень передана в тестову експлуатацію на обладнанні Замовника (контрольна точка)
1.4.3.4. Розробка підсистеми супроводу каталогу
1.4.3.4.1. Підготовка та супровід каталогу продукції.
1.4.3.5. Виправлення помилок
1.4.4. Тестування ПЗ
1.4.4.1. Раунд 1
1.4.4.2. Раунд 2
1.4.4.3. Раунд 3
1.4.4.4. Вихідне тестування
1.4.5. Документування прикладного ПЗ
1.5. Навчання користувачів
1.5.1. Підготовка навчальних курсів
…..
1.5.4. Навчання адміністраторів системи
1.6 . Введення в дослідну експлуатацію
1.6.1. Розгортання та налаштування прикладного ПЗ
1.6.2. Проведення приймально-здавальних випробувань
1.6.3. Акт передачі системи в дослідну експлуатацію затверджений
1.7. Супроводження системи в період дослідної експлуатації
1.8. Система передана в промислову експлуатацію

УПРАВЛІННЯ ЗМІСТОМ

Зміст проекту враховуэ дві речі: зміст проекту (project scope) і зміст продукту
(product scope). Зміст продукту охоплює особливості і функцій, які будуть
надані учасникам проекту при його завершенні, зміст проекту - це роботи, які
треба виконати, щоб доставити зміст продукту учасникам проекту.
Перший етап роботи за проектом відзначається ентузіазмом, який провокує
«повзучий фічерізм», коли команда натхненно вигадує кучу нікому в
подальшому непотрібного функціоналу. Це загубило багато проектів
розробки ПЗ.
Проблему „перевантаження” проекту варто вирішувати на загальних зборах
команди і учасників проекту, що проводиться кілька разів для відкидання, за
загальною згодою, потреб, які не мають практичної цінності для проекту.
Результатом такої мінімізації потреб проекту, є список вимог (requirements).
Далі складають список результатів проекту, з яким згодні як учасники, так і
команда проекту. Всі учасники проекту мають офіційно схвалити результати
і остаточно з ними погодитися.
Після погодження ІСР розробляють план управління змістом проекту:
• Визначають джерела запитів на зміну.
• Визначають порядок аналізу, оцінки і затвердження/відхилення зміни змісту
• Визначають порядок документування змін змісту.
• Визначають порядок інформування про зміну змісту .
При аналізі запиту на зміни треба виявити об'єкти змін: вимоги, архітектура,
структури даних, вихідні коди, сценарії тестування, документація користувача
та інше. Далі треба спроектувати і детально описати зміни в усіх виявлених
об'єктах. І нарешті, слід оцінити витрати на внесення змін, тестування змін і
регресійне тестування продукту та їх вплив на терміни проекту.
Ця робота потребує витрат робочого часу від різних фахівців: аналітиків,
проектувальників, розробників, тестувальників, нарешті, менеджера проекту.
Тому ця робота має обов'язково бути врахована в плані.

ОРГАНІЗАЦІЙНОЇ СТРУКТУРИ

Організаційна структура (Organizational Breakdown Structure, OBS) є узгодженим і затвердженим розподілом ролей, обов'язків і цілей діяльності ключових учасників проекту. В OBS компоненти роботи, представлені в ІСР, показані у зв'язку з групами робітників і ресурсами, що забезпечують виконання роботи.
Вона має включати систему взаємодії між робочими групами проекту, систему звітності, оцінки ходу виконання проекту і систему прийняття рішень.. Вона має складатися на стадії планування і повинна змінюватися по ходу проекту.

ПЛАНУВАННЯ УПРАВЛІННЯ КОНФІГУРАЦІЯМИ
План має включати у себе роботи щодо забезпечення єдиного сховища всієї проектної документації та розроблюваного програмного коду, забезпечення збереження і відновлення проектної інформації після збою, налаштування робочих станцій і серверів, використовуваних учасниками проектної команди. Крім цього в плані мають міститися роботи, необхідні для організації складання проміжних випусків системи, а також її кінцевого варіанту.
Ці роботи, як правило, виконує одна людина - інженер з конфігурацій. Якщо проект невеликий, то ця роль може бути додатковою для одного з програмістів. Цю роль може виконувати і менеджер проекту. «Розмазувати» цю роботу на всіх учасників проекту, по-перше, неефективно. Установка і конфігурація середовища розробки, наприклад, баз даних і серверів додатків, вимагає певних компетенцій і знань особливостей конкретних версій продуктів. Якщо ці навички доведеться освоювати всім розробникам, це забере багато робочого часу. «Розмазування» робіт з управління конфігураціями може призвести до колективної безвідповідальності, коли ніхто не знає, чому не збирається проект і як відкотитися до консистентної версії. Управління конфігураціями може значно ускладнитися, якщо проектній команді паралельно з розробкою нової функціональності продукту доводиться підтримувати кілька релізів цього продукту, які були встановлені раніше у різних клієнтів. Всі ці роботи повинні бути враховані в плані проекту .

ПЛАНУВАННЯ УПРАВЛІННЯ ЯКІСТЮ 17

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

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

Крім перерахованих розділів план проекту повинен включати також:
• План управління ризиками
• Оцінку трудомісткості і термінів робіт