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

Є різноманітні методики управління проектами У цьому курсі ми дотримуватися методики «>Мягкого впровадження» ведення проекту. Це методики м'якого й жорсткого впровадження.

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

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

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

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

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

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

· Замовник готовий заплатити більше, але за результат, а чи не за зусилля (час) Виконавця. Купівля проекту, а чи не часу Виконавця дозволяє Замовникові зняти із себе значну частку провиниза проблеми освіти й помилки.

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

· Методика застосовна для невеликих замовних і серійних систем.

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

Основна продукція етапу - документ "Постановка Завдання" (>Product Vision).

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

За підсумками "Постановки Завдання" потрібно скласти документ "Економічне обгрунтування".

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

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

Для оцінки ризиків потрібно розробити принаймні 2 найпростіших прототипу (є підстави виконані одностайно).

">Интерфейсний прототип" - це прототип, що імітував 1-2 найважливіших діалогових вікна програми. Необхідно проаналізувати реакцію користувачів для вивчення ризиків що з модифікацією їх вимог.

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

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

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

У результаті маємо нечітко сформульоване завдання "Постановка Завдання" й оцінку вартістю "Економічній обгрунтуванні". Ризики від нечіткості вимог би мало бути вкриті песимістичною оцінкою. З погляду юридичного договору "Постановка Завдання" може зайняти позиціюТЗ, але із зазначенням у договорі те що, що як пріоритетний документ "Документація користувача" (див. нижче) і системи прийматиметься по ">Приемочним випробувань" (див. також нижча)

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

 

Умова завершення етапу: підписання сторонами "Постановки Завдання" і "Економічного обгрунтування".

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

Водночас у виглядіпошагових сценаріїв (>usecase) пишеться "ДокументаціяПользователя", розкриває пункти "Постановки Завдання". Спочатку створюються сценарії поведінки системи загалом. Потім створюються індивідуально спрямовані сценарії - посадові інструкції користувачам. Забороняється використання у документації слова "повинен", час описи вибирається як невизначене чи справжнє. Такі стилістичні обмеження необхідні здобуття права "Документація користувача" грала як роль специфікації, а й роль документації для користувача, як міститься в назві документа.

Можливі два варіанта взаємодії ">прототип-документация":

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

2) За відсутності ставлення до кращому варіанті реалізації по короткому завданням з урахуванням "Постановки Завдання" спочатку створюється прототип. Після схвалення Замовником документується бажане поведінка системи.

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

Як зазначалося, "Документація" фактично заміняє класичнеТЗ,. в такий спосіб в наявності ряд переваг:

1. Опис програми робиться мовою, зрозумілому користувачеві.

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

3. Не треба правитиТЗ і Документацію одночасно.

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

Ступінь Важности Продукт етапу

 

Опис продукту

1 Прототип всієї системи

Прототип системи - це набір прототипів перевіряючий щонайменше 80% користувальних і архітектурних рішень.

Усі прототипи необхідно прийняти Замовником.

2 Документація (>ТЗ) Мають бути складено і схвалено сценарії щонайменше 80% поведінки кінцевої Системи.

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

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

 

Укладання

Широке застосування методика планування робіт з урахуванням проекту отримало будівництві. Наприклад, керувати проектом споруди гідроелектростанції річці Черчілль в Ньюфаундленді (півострів Лабрадор). Вартість проекту становила 950 млн. доларів.Гидроелектростанция будувалася з 1977 по 1986 р. Проект включав понад 100 будівельних контрактів, причому, вартість декого з тих досягала 76 млн. доларів. У 1984 року хід за проектом робіт випереджав розклад на 18 місяців, і вкладався в планову оцінку витрат.

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

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