Контроль статусу вимог

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

Стан	Визначення
Proposed (запропоновано)	Вимога, що запитана авторизованим джерелом
Approved (схвалено)	Вимога проаналізована, її вплив на проект прораховано, і вона була розміщена в базовій версії визначеної версії. Ключові зацікавлені в проекті особи погодились з цією вимогою, а розробники ПЗ зобов’язались реалізувати її
Implemented (реалізовано)	Код, що реалізує вимогу, розроблений, написаний і протестований. Вимогу відслідковано до відповідних елементів дизайну і коду
Verified (перевірено)	Коректне функціонування реалізованої вимоги підтверджено у відповідному продукті. Вимогу відслідковано до відповідних варіантів тестування. Тепер вимога вважається закінченою.
Deleted (видалено)	Затверджену вимогу видалено із базової версії. Необхідно зазначити причини видалення і назвати того, хто прийняв таке рішення.
Rejected (відхилено)	Вимога запропонована, але не запланована для реалізації ні в одній із майбутніх версій. Необхідно описати причини відхилення вимог і назвати того, хто прийняв таке рішення.

Вимірювання трудовитрат, необхідних для управління вимогами

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

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

- Пропозиція зміни вимог та нових вимог;

- Оцінка запропонованих змін, включаючи оцінку впливу змін;

- Зміна роботи;

- Оновлення документації вимог або бази даних;

- Повідомлення про зміни вимог зацікавленим групам і окремим особам;

- Контроль і звіт про стан вимог;

- Збір інформації про трасуємість вимог.

Управління змінами

Більшість розробників стикалися з простими на перший погляд змінами, які виявлялися більш складними, ніж вони очікували. Розробники іноді не виконують - або не можуть виконати - реалістичні розрахунки витрат та інших наслідків запропонованого зміни ПЗ. І коли розробник, який хоче бути люб'язним, погоджується додати поліпшення, запитуване користувачем, вимоги змінюються через «чорний хід», а не затверджуються зацікавленими особами, які мають на це право. Tакі неконтрольовані зміни - повсюдний джерело хаосу в проекті, порушення графіка і проблем з якістю, особливо якщо робота ведеться на декількох ділянках або проект виконує стороння організація. Організація, серйозно відноситься до управління
своїми проектами з розробки ПЗ, повинна переконатися, що:

· запропоновані зміни вимог ретельно оцінені до їх у введення у справу;

· відповідні особи приймають (беруть) бізнес-рішення, будучи добре інформованими про запитані зміни;

· схвалені зміни доведені до відома всім учасникам проекту;

· зміни вимог, внесені в проект, узгоджені один з іншим.

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

Управління незапланованим ростом об’єму

Незапланований ріст об’єму ставить під загрозу:

- 80% проектів по розробці систем управління інформацією:

- 70% проектів по розробці військових систем ПЗ;

- 45% проектів по створенню ПЗ, що виконуються за контрактом.

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

Вимоги до системи управління інформацією, як правило, збільшуються на 1% на місяць (Jones, 1996b). Темп приросту може складати до 3,5% у місяць для комерційного ПЗ, при цьому темпи зростання інших типів проектів входять у цей показник.

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

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

Інша стратегія – це уміння говорити «Ні». психологія більшості людей побудована таким чином. Що їм важко відмовляти, і в даному випадку може виникнути стан постійного пресингу. К Вігерс пропонує пом’якшити цей підхід, замінивши «Ні» на «Не зараз» (вимога обов’язково буде виконана, але не в поточній версії).

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

2. Процес контролю змін

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

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

Якщо запропонована зміна не настільки важлива, щоб зацікавлена ​​в проекті
особа витратила пару хвилин на передачу її через стандартні, прості канали, то варто замислитися про її цінності взагалі. Процес управління повинен бути ретельно задокументований, максимально простий і, що найважливіше, ефективний.
Після реєстрації запиту на зміну слід прийняти рішення про його подальшу
долі. Рада з управління змінами (change control board, CCB) (іноді її
називають радою з управління конфігурацією) була визначена кращим практичним рішенням при розробці ПЗ.

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

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

Процес контролю змін

Рис. Шаблон опису процесу контролю змін

1. Введення

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

2. Ролі та відповідальності

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

Рис. Можливі ролі учасників проекту при управлінні змінами

3. Стан запиту на зміну

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

4. Вхідний критерій

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

5. Завдання

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

6. Перевірка

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

7. Вихідний критерій

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

- стан запиту: Rejected (Відхилено), Closed (Закрито) або Canceled (Скасовано);

- всі зміни записані у відповідних розділах;

- ініціатор запиту, голова ради з управління змінами, менеджер проекту та інші значущі учасники проекту оповіщені про деталі зміни і поточний стан запиту на зміну;
- матриця зв'язків вимог оновлена.

8. Звіт про стан управління зміни

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

Рада з управління змінами

Рада з управління змінами (change control board, CCB) (іноді її називають радою з управління конфігурацією) була визнана кращим практичним рішенням при розробці ПЗ (McConnell, 1996), Це група людей, незалежно від того, скільки їх-одна людина чи декілька, приймаюча рішення про те, які запропоновані зміни вимог і нові функції прийняти для включення в продукт.
Рада з управління змінами також вирішує, які виявлені помилки варто виправити і коли. Офіційне призначення ради з управління змінами дозволяє визначити його структуру та повноваження, а також призначити робочі процедури.

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

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

Склад ради з управління змінами

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

менеджерів проекту або програми;

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

розробників;

фахівців з тестування або перевірці якості:

маркетологів або представників клієнта;

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

фахівців технічної служби або служби підтримки;

фахівців з управління конфігурацією.

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

Статут ради з управління змінами

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

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

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

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

- чи використовується голосування, консультативний спосіб чи будь-яке інше правило прийняття рішень;

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

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

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

Аналіз впливу зміни

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

Аналізу результатів змін зачіпає три аспекти.

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

2. Визначення всіх файлів, моделей та документів, які, можливо, доведеться змінити, якщо команда включить всі запитані зміни.

3. Визначення задач, необхідних для реалізації зміни, і оцінка зусиль,
необхідних для виконання цих завдань.

24.04.2012 Лекція

1. Поняття та процеси доменної інженерії та доменного аналізу програмного забезпечення.

2. Лінійки та сімейства продуктів.

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

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

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

Доменна інженерія включає в себе три основні компоненти-процеси – Доменний Аналіз (ДА), Доменне Проектування (ДП), Реалізація Домену (РД).

Основна мета кожного із цих компонентів:

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

Доменне Проектування – створення спільної (загальної) архітектури для систем в домені.

Реалізація Домену – реалізація повторно використовуваних ресурсів, наприклад, повторно-використовувані компоненти, доменно-орієнтовані мови, генератори і повторно використовувана інфраструктура.

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

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

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

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

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

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

ДОМЕННИЙ АНАЛІЗ

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

Метою ДА є:

- Вибір і визначення домену.

- Збір важливої (необхідної) інформації про домен і інтеграція її в зв’язану (єдину) модель домену.

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

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

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

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

- Лексикон домену: Доменний лексикон визначає доменний словник.

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

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

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

2) Моделювання домену: розробка доменної моделі

Дата добавления: 2015-09-06