Є різноманітні методики управління проектами У цьому курсі ми дотримуватися методики «>Мягкого впровадження» ведення проекту. Це методики м'якого й жорсткого впровадження.
Впровадження - запровадження у умовах взаємної довіри Замовника і Виконавця, у якому проблеми освіти й помилки Замовника перебирає здебільшого Виконавець.
Жорстке впровадження - запровадження у умовах жорсткого формального управління, зниженого довіри й підвищеної відпо-відальності Замовника і Виконавця. Жорстке впровадження зазвичай є наслідком сильні політичні ризиків
Ця технологія розробки й упровадження має такі перевірені кордону застосовності:
· Його розраховано на взаємний радіус довіри Замовника і Виконавця не більше упродовж як мінімум етапу робіт, мають на увазі, що Замовник чи Виконавець можуть блокувати проект, але з більш ніж рамках етапу.
· Оптимально для проектів терміном до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 місяців, і вкладався в планову оцінку витрат.
Фактично, значний виграш за часом утворився від використання точних математичних методів у управлінні складними комплексами робіт, який став можливим завдяки розвитку обчислювальної техніки.
Нині і в Америці склалися глибокі традицією використання системам управління проектами у багатьох областях життєдіяльності. Застосування системи управління проектами практично може бути ефективним й у дуже невеликих проектів, оскільки, основна частка серед планованих проектів становлять саме невеликі за величиною проекти.
