ALL(PDF)

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

Збір вимог: інструменти й методи

Ще один приклад семінару за участю модератора, що допомагає визначити критично важливі характеристики для просування нового продукту - «Розгортання функції якості» (Quality

Function Deployment, QFD).

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

QFD починається зі збору потреб замовника, що також називається «думкою замовника» (Voice of the Customer, VOC). Потім ці потреби об'єктивно сортуються, і між ними розставляються пріоритети, а також установлюються цілі для їхнього досягнення.

Збір вимог: інструменти й методи

4. Групові творчі методи

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

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

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

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

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

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

Збір вимог: інструменти й методи

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

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

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

•Більшість голосів. Підтримка з боку більше 50 % членів групи.

•Відносна більшість голосів. Вибирається рішення самого численного блоку в групі, навіть якщо не набрано більшість голосів.

•Диктатура. Одна людина приймає рішення за всю групу.

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

Збір вимог: інструменти й методи

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

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

Збір вимог: інструменти й методи

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

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

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

Збір вимог: інструменти й методи

8. Прототипи

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

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

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

Збір вимог: виходи

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

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

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

Збір вимог: виходи

Елементи документів по вимогах можуть містити в собі, серед іншого:

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

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

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

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

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

•вимоги до якості;

•критерії приймання;

•бізнес-правила, що описують керівні принципи організації;

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

•вплив на інші органи усередині й за межами виконуючої організації;

•вимоги до технічної підтримки й навчання;

•допущення й обмеження відносно вимог.

Збір вимог: виходи

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

Збір вимог: виходи

Елементи плану управління вимогами можуть містити в собі, серед іншого:

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

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

•процес розміщення пріоритетів вимог;

•використовувані показники продукту й обґрунтування їхнього використання;

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

Збір вимог: виходи

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

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

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

Збір вимог: виходи

Цей процес містить у собі, не обмежуючись тільки відстеженням, такі елементи:

•вимоги до бізнес-потреб, можливостей, задач і цілей;

•вимоги до цілей проекту;

•вимоги до змісту проекту / результатів ІСР;

•вимоги до проектування продукту;

•вимоги до розробки продукту;

•вимоги до стратегії й сценаріїв перевірки;

•деталізацію вимог від високого рівня до більш детальних вимог.

Збір вимог: виходи

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

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

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

2.2. Визначення змісту

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

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

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

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

-проектні архіви з попередніх проектів;

-знання, накопичені в попередніх фазах або проектах.

Визначення змісту: інструменти й методи

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

-інші підрозділи в рамках організації;

-консультантів;

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

-професійні й технічні асоціації;

-промислові групи;

-експерти з окремих питань.

Визначення змісту: інструменти й методи

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

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

4.Семінари за участю модератора Описані раніше.

Визначення змісту: виходи

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

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

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

Визначення змісту: виходи

Детальний опис змісту проекту або безпосередньо, або за допомогою посилань на інші документи містить у собі:

- знання, накопичені в попередніх проектах.

Створення ІСР: інструменти й методи

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

Створення ІСР: інструменти й методи Декомпозиція всієї сукупності робіт із проекту до пакетів робіт звичайно містить у собі такі дії:

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

-структурування й організація ІСР;

-розбивка верхніх рівнів ІСР на деталізовані елементи більш низьких рівнів;

-розробку й присвоєння ідентифікаційних кодів елементам ІСР;

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

Структура ІСР може бути створена в різних формах, наприклад:

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

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

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

Зразок ієрархічної структури робіт Зразок ієрархічної структури робіт, організованої по фазах

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

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

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

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

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

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

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

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

Цей метод іноді називають «плануванням методом хвилі, що набігає».

ІСР представляє всі роботи продукту й проекту, включаючи роботи з управління проектом. Загальний зміст робіт на самих нижніх рівнях повинен скручуватися в більш високі рівні, щоб нічого не було пропущено, і не виконувалася зайва робота. Іноді це називають «правилом 100 %».

Практичний стандарт PMI по ієрархічних структурах робіт (the Practice Standard for Work Breakdown Structures - Second Edition) містить рекомендації зі створення, розробки й застосування ієрархічних

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

Створення ІСР: виходи

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

Створення ІСР: виходи

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

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

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

Створення ІСР: виходи

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

Словник ІСР надає більш детальні описи елементів ІСР, включаючи пакети робіт і контрольні рахунки.

Створення ІСР: виходи

Інформація в словнику ІСР містить у собі, серед іншого:

-ідентифікатор плану рахунків;

-опис робіт;

-відповідальну організацію;

-список контрольних подій розкладу;

-пов'язані заплановані операції;

-необхідні ресурси;

-оцінки вартості;

-вимоги до якості;

-критерії приймання;

-технічні посилання;

-контрактну інформацію.

Створення ІСР: виходи

3. Базовий план по змісту є елементом плану управління проектом. Елементи базового плану по змісту містять у собі:

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

-ІСР - визначає кожний результат і декомпозицію результатів на пакети робіт.

-Словник ІСР - містить докладний опис робіт і технічну документацію по кожному елементу ІСР.

Створення ІСР: виходи

4. Оновлення документів проекту

Документи проекту, які можуть бути оновлені, містять у собі документи по вимогах, але не обмежуються тільки ними. Якщо в результаті процесу створення ІСР з'являються схвалені запити на зміни, може знадобитися коректування документів по вимогах, щоб включити в них схвалені зміни.

2.4. Підтвердження змісту

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

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

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

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

Підтвердження змісту: входи, інструменти й методи, виходи Блок-схема даних при підтвердженні змісту Підтвердження змісту: входи

1. План управління проектом, описаний у темі Управління інтеграцією проекту містить базовий план по змісту.

Елементи базового плану по змісту містять у собі:

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

-ІСР. ІСР визначає кожний результат і декомпозицію результатів на пакети робіт.

-Словник ІСР. Словник ІСР містить докладний опис робіт і технічну документацію по кожному елементу ІСР.

Підтвердження змісту: входи

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

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

4.Підтверджені результати, завершені й перевірені на правильність у процесі контролю якості.

Підтвердження змісту: інструменти й методи

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

Інспекції іноді називаються «перевірками», «перевірками продукту», «аудитами» або «наскрізним контролем».

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

Підтвердження змісту: виходи

1. Прийняті результати

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

Підтвердження змісту: виходи

2. Запити на зміни

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

Підтвердження змісту: виходи

3. Оновлення документів проекту

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

2.5. Управління змістом

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

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

управління інтеграцією проекту).

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

Некеровані зміни часто називають «зрушенням змісту проекту».

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

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

Управління змістом: входи

1. План управління проектом, розглянутий в темі Управління інтеграцією проекту, містить таку інформацію, використовувану для управління змістом:

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

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

-План управління змінами. План управління змінами визначає процес управління змінами проекту.

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

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

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

Управління змістом: входи

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

3.Документи по вимогах (Розглянуто раніше)

4.Матриця відстеження вимог (Розглянуто раніше).

5.Активи процесів організації, які можуть впливати на процес управління змістом, містять у собі,

серед іншого:

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

-використовувані методи моніторингу й звітності.

Управління змістом: інструменти й методи

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

Управління змістом: виходи

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

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

містять у собі, серед іншого:

-причини відхилень;

-обрані коригувальні впливи й причини;

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

Управління змістом: виходи

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

Запити на зміни обробляються з метою проведення перевірки й представлення відповідно до процесу здійснення загального управління змінами (див. тему Управління інтеграцією проекту).

Управління змістом: виходи

4. Оновлення плану управління проектом включає:

-Оновлення базового плану по змісту. Якщо схвалені запити на зміни впливають на зміст проекту, то опис змісту, ІСР і словник ІСР переглядаються й випускаються заново, щоб відбити схвалені зміни.

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

Управління змістом: виходи

5. Оновлення документів проекту

Документи проекту, які можуть бути оновлені, містять у собі, серед іншого:

-документи по вимогах;

-матрицю відстеження вимог.

Дякую за увагу!