Читайте также:
|
Введення нових або зміна існуючих вимог впливає на проект наступним чином:
- відкладається реалізація вимог нижчих рівнів;
- запрошуються нові фахівці;
- на короткий період часу вводиться режим понаднормової роботи, по можливості оплачуваної;
- у відповідності з новою функціональністю змінюється графік;
- страждає якість, так як необхідно вкластися в графік (дуже часто ця реакція за замовчуванням).
Базова версія (baseline) – це набір функціональних і нефункціональних вимог, які розробники зобов’язалися реалізувати у визначеній версії (ітерації).
Визначення базової версії дозволяє зацікавленим у проекті особам виробити спільне розуміння можливостей і властивостей, які вони хочуть бачити у цій версії. Прийнята базова версія вимог - як правило, версія стає базовою після офіційних експертизи та затвердження - віддається для управління конфігурацією (Конфигурация - это особенности конструкции, включая архитектуру, состав и характеристики основных составных частей и вспомогательных (периферийных) средств, а также организацию связей между ними). Наступні зміни дозволяється вносити в неї тільки через визначений у проекті процес управління змінами. До прийняття базової версії вимоги все ще змінюються, тому не має сенсу обмежувати модифікацію якимись процедурами. Однак варто почати контролювати версії, унікальним чином ідентифікуючи різні версії кожного документа вимог, відразу після того, як буде зроблений попередній начерк цього документа.
Процедури управління вимогами базуються на:
- Інструментах, прийомах і погодженнях по управлінню версіями різноманітних документів вимог і окремих вимог;
- Правилах складання базової версії вимог;
- Статусах вимог, які будуть використовуватись, і категоріях осіб, які мають право змінювати їх;
- Процедурах контролю за статусом вимог;
- Способах, за допомогою яких нові вимоги і зміни існуючих вимог пропонуються, оброблюються, обговорюються і передаються усім зацікавленим особам.
- Методах аналізу впливу запропонованої зміни;
- Відслідковуванні зв’язків планів і обов’язків проекту зі змінами вимог.
Хтось повинен виконувати дії при управлінні вимогами, тому в описах процесу також слід визначити ролі учасників, відповідальних за виконання кожного завдання. Проектний аналітик вимог, як правило, несе основну відповідальність за управління вимогами. Він вибирає механізм збереження вимог (наприклад, засіб керування вимогами), визначає атрибути вимог, координує оновлення даних про стан і трасуємість вимог і генерує звіти про зміну дій.
Контроль версій - це важливий аспект управління специфікаціями вимог та іншими проектними документами. Кожній версії слід присвоїти унікальний ідентифікатор. У кожного члена команди повинен бути доступ до поточної
версії вимог, а зміни необхідно ясно документувати і передавати всім зацікавленим сторонам. Щоб мінімізувати плутанину, конфлікти і нерозуміння, потрібно призначити право поновлення вимог строго певним особам і переконатися, що ідентифікатор версії змінюється при кожній зміні вимоги.
Кожна версія документу повинна містити історію переробки, де вказуються внесені зміни, дата кожної з них, особу, що внесла зміни, а також причина.
Найпростіший механізм управління версіями - іменувати вручну кожну версію специфікації вимог до ПЗ згідно з угодою.
Найбільш надійний метод контролю версій полягає в зберіганні вимог у базі даних комерційного засоби управління вимогами. Ці засоби відстежують повну історію змін вимог, що особливо важливо, якщо потрібно
повернутися до більш ранньої версії вимоги. Такий засіб дозволяє вносити коментарі, де можна розумно обґрунтувати рішення про додавання, зміну або видалення вимоги; ці коментарі можуть виявитися корисними при необхідності обговорення вимоги у майбутньому.
Кожна функціональна вимога повинна мати кілька підтримуємих їх фрагментів інформації, або атрибутів (attributes), пов'язаних з ним, Ці атрибути представляють вміст кожної вимоги, вони розташовуються за описом передбачуваної функціональності. Атрибути можна зберегти в таблиці, бази даних або, що найбільш ефективно, в засобі керування вимогами. Останні надають декілька згенерованих системою атрибутів, а також надають можливість визначити інші атрибути. Ці засоби дозволяють фільтрувати, сортувати вибрані підмножини вимог на підставі значень їх атрибутів і запитувати базу даних для іх перегляду.
Контроль змін зручніше здійснювати за допомогою атрибутів вимог. Набір атрибутів підбирається для кожного проекту індивідуально, виходячи із максимальної результативності для команди проекту. При першому впровадженні засобів управління змінами рекомендується використовувати не більше п’яти атрибутів. Ця кількість може буди розширена в подальшому, коли команда «розсмакує» процес управління змінами.
В якості шаблону опису атрибутів вимог К. Вігерс пропонує наступний набір:
- Дата створення вимоги;
- Номер поточної версії;
- Автор вимоги;
- Особа, що відповідає за задоволення вимоги;
- Відповідальний за вимогу або список зацікавлених осіб (щоб прийняти рішення про запропоновані зміни);
- Стан вимоги;
- Походження або джерело вимоги;
- Логічне обґрунтування вимоги;
- Підсистема (або підсистеми), для яких призначена вимога;
- Номер версії продукту, для якого призначена вимога;
- Метод перевірки, що використовується або критерії тестування прийнятності;
- Пріоритет реалізації;
- Стабільність вимоги.
В автоматизованих засобах управління проектами (наприклад,MS Project), для контролю ступеню виконання тієї чи іншої роботи використовується поняття степені виконання (progress), що виражається у відсотках. Даний спосіб слабо застосовується в розробках програмістів, де, в силу їх слабої формалізованості, важко оцінити роботу у відсотках. При управлінні вимогами рекомендується оперувати не відсотком, а статусом. К Вігерс пропонує наступний шаблон для визначення статусу вимоги:
| Proposed (запропоновано) -Вимога, що запитана авторизованим джерелом Approved (схвалено) - Вимога проаналізована, її вплив на проект прораховано, і вона була розміщена в базовій версії визначеної версії. Ключові зацікавлені в проекті особи погодились з цією вимогою, а розробники ПЗ зобов’язались реалізувати її. |
| Implemented (реалізовано) -Код, що реалізує вимогу, розроблений, написаний і протестований. Вимогу відслідковано до відповідних елементів дизайну і коду |
| Verified (перевірено) -Коректне функціонування реалізованої вимоги підтверджено у відповідному продукті. Вимогу відслідковано до відповідних варіантів тестування. Тепер вимога вважається закінченою. |
| Deleted (видалено) -Затверджену вимогу видалено із базової версії. Необхідно зазначити причини видалення і назвати того, хто прийняв таке рішення. |
| Rejected (відхилено) -Вимога запропонована, але не запланована для реалізації ні в одній із майбутніх версій. Необхідно описати причини відхилення вимог і назвати того, хто прийняв таке рішення. |
Більшість розробників стикалися з простими на перший погляд змінами, які виявлялися більш складними, ніж вони очікували. Розробники іноді не виконують - або не можуть виконати - реалістичні розрахунки витрат та інших наслідків запропонованого зміни ПЗ. І коли розробник, який хоче бути люб'язним, погоджується додати поліпшення, запитуване користувачем, вимоги змінюються через «чорний хід», а не затверджуються зацікавленими особами, які мають на це право. Tакі неконтрольовані зміни - повсюдний джерело хаосу в проекті, порушення графіка і проблем з якістю, особливо якщо робота ведеться на декількох ділянках або проект виконує стороння організація. Організація, серйозно відноситься до управління
своїми проектами з розробки ПЗ, повинна переконатися, що:
Обов'язок аналітика вимог - включити затверджені зміни в проектну документацію вимог, Принцип все той же: документація вимог повинна точно описувати поставляємий продукт. Якщо не буде оновлено специфікацію вимог щодо ходу розробки продукту, його цінність буде знижуватися, і команді доведеться працювати таким чином, як ніби-то в неї взагалі немає ніякої специфікації.
Процес контролю змін дозволяє керівнику проекту приймати
інформоване бізнес-рішення, яке задовольняє клієнта і має комерційну
цінність, при цьому контролюються витрати на життєвий цикл продукту. Можна відслідковувати статус усіх запропонованих змін і переконатися, що запропоновані вимоги не були втрачені або втрачені. Після затвердження базової версії набору вимог потрібно дотримуватись цього порядку для внесення всіх пропонованих змін до неї.
Клієнти та інші зацікавлені особи часто ухиляються від нового процесу, проте
процес контролю змін - не перешкода для модифікації. Це механізм
підсумовування та фільтрації, що дає впевненість, що в проект включені найбільш цінні зміни.
Якщо запропонована зміна не настільки важлива, щоб зацікавлена в проекті
особа витратила пару хвилин на передачу її через стандартні, прості канали, то варто замислитися про її цінності взагалі. Процес управління повинен бути ретельно задокументований, максимально простий і, що найважливіше, ефективний.
Після реєстрації запиту на зміну слід прийняти рішення про його подальшу
долі.
Рада з управління змінами (change control board, CCB) (іноді її називають радою з управління конфігурацією) була визнана кращим практичним рішенням при розробці ПЗ (McConnell, 1996), Це група людей, незалежно від того, скільки їх-одна людина чи декілька, приймаюча рішення про те, які запропоновані зміни вимог і нові функції прийняти для включення в продукт.
Рада з управління змінами також вирішує, які виявлені помилки варто виправити і коли. Офіційне призначення ради з управління змінами дозволяє визначити його структуру та повноваження, а також призначити робочі процедури.
Рада з управління змінами переглядає і затверджує зміни базових версій будь-якої документації проекту, наприклад специфікації вимог. Деякі ради мають повноваження для прийняття рішень і просто інформують менеджерів про внесення цих змін, тоді як інші можуть тільки давати рекомендації менеджерам для прийняття рішень. У невеликому проекті має сенс делегувати прийняття рішень одному або двом співробітникам. У великих проектах та програмах може бути кілька рівнів рад контролю змін: одні відповідають за прийняття бізнес-рішень, наприклад про зміну вимог, а інші за рішення технічного характеру. Рада з управління змінами більш високого рівня затверджує зміни, що дуже сильно впливають на проект. Наприклад, при розробці великої програми, що об'єднує кілька проектів, слід створити раду, що приймає рішення на рівні програми, і окремі поради для кожного проекту. Останні вирішують проблеми і розглядають зміни, що впливають тільки на конкретний проект. Питання, що стосуються інших проектів, і зміни, в результаті яких можливе перевищення витрат або порушення графіка, передаються до ради рівня програми.
Для деяких людей термін «рада з управління змінами» означає неекономічні бюрократичні накладні витрати. Однак це цінна структура, яка допомагає керувати навіть невеликим проектом. Вона не повинна забирати багато часу або бути громіздкою - вона повинна працювати ефективно. Це означає, що Рада з управління змінами розглядає всі запропоновані зміни швидко і приймає своєчасні рішення на підставі аналізу можливого впливу і переваг кожної пропозиції. Ця структура повинна бути не більше і не офіційніше, ніж необхідно для того, щоб упевнитися, що відповідні особи приймають правильні бізнес-рішення по кожній запитуваній зміні.
У статуті описуються завдання, область повноважень, членство, виробничі процедури та процес прийняття рішень ради з управління змінами.
В уставі має бути вказана регулярність запланованих нарад і умови скликання спеціальних зустрічей.
Область повноважень вказує, які рішення рада може приймати, а які слід передати раді вищого рівня або менеджера.
Прийняття рішень. Як і всі структури, що приймають рішення, кожна рада з управління змінами повинна визначити відповідні правила та процес прийняття рішення. В описі процесу прийняття рішення слід зазначити таке:
- скільки членів ради з управління змінами або осіб, що виконують ключові ролі, складають кворум для прийняття рішень;
- чи використовується голосування, консультативний спосіб чи будь-яке інше правило прийняття рішень;
- чи може голова ради з управління змінами відхилити колективне рішення ради;
- чи повинна рада з управління змінами більш високого рівня або хто-небудь ще ратифікувати рішення.
Рада з управління змінами зважує передбачувані переваги і передбачуване вплив прийняття запропонованої зміни. До переваг належать: економія коштів, збільшення доходу, більше задоволення покупців і конкурентні
переваги. Вплив від зміни враховує негативний ефект, яке зміна може зробити на продукти або проект. До них відносяться: збільшення витрат на розробку і підтримку, затримка постачання, зниження якості продукту, зменшення функціональності невдоволення клієнтів. Якщо прорахований вплив на витрати або графік перевищує допустимий поріг повноважень для даної ради, передаються зміни для розгляду менеджменту або раді з управління змінами більш високого рівня. В іншому випадку; процес прийняття рішень ради з управління змінами допоможе затвердити або відхилити запропоновану зміну,
Повідомлення про стан
Після того як рада з управління змінами приймає рішення, уповноважений співробітник оновлює стан запиту в базі даних змін. Деякі засоби автоматично генерують повідомлення електронної пошти, щоб інформувати про новий стан ініціатора запиту і всіх, кого зачіпає це зміна Якщо повідомлення електронної пошти не генерується автоматично проінформуйте зацікавлених фахівців особисто для того, щоб вони змогли правильно прийняти цю зміну.
Члени ради з управління змінами повинні представляти всі групи, яким необхідно приймати участь у прийнятті рішень у межах повноважень ради. Учасники представників наступних областей:
менеджерів проекту або програми;
менеджерів продукту або аналітики вимог;
розробників;
фахівців з тестування або перевірці якості:
маркетологів або представників клієнта;
фахівців, відповідальних за інформацію користувача, документацію;
фахівців технічної служби або служби підтримки;
фахівців з управління конфігурацією.
Тільки деякі з них будуть приймати рішення, проте всіх їх слід проінформувати про рішення, що впливають на їх роботу.
Аналіз впливу забезпечує точне розуміння підтексту запропонованої зміни,
що допомагає команді приймати інформовані бізнес-рішення про те, яку
зміну схвалити. Аналіз дозволяє виявити компоненти, які можуть
знадобитися створити, змінити або відхилити, і оцінити витрати, пов'язані з реалізацією зміни. До того, як розробник відповість: «Звичайно, без проблем», він
повинен витратити час на аналіз результату зміни.
Голова ради з управління змінами зазвичай просить досвідченого розробника
виконати аналіз визначеного результату.
Аналізу результатів змін зачіпає три аспекти.
1. Визначення можливих наслідків зміни. Часто вони викликають значний
хвильовий ефект. Включення безлічі функцій в продукт може знизити його
продуктивність до неприйнятного рівня, наприклад, коли системі, яка завантажується щодня, знадобиться 24 години для завершення одного запуску.
2. Визначення всіх файлів, моделей та документів, які, можливо, доведеться змінити, якщо команда включить всі запитані зміни.
3. Визначення задач, необхідних для реалізації зміни, і оцінка зусиль,
необхідних для виконання цих завдань.
Доменна інженерія – діяльність по збору, систематизації і збереження минулого досвіду побудови систем або частин систем в конкретному домені в формі повторно використовуваних ресурсів (активів, засобів), а також по забезпеченню належних засобів (методів) для повторного використання цих ресурсів (тобто, пошук, розповсюдження, адаптація, збірка і т.д.) при створенні нових систем.
Доменна інженерія включає в себе три основні компоненти-процеси – Доменний Аналіз (ДА), Доменне Проектування (ДП), Реалізація Домену (РД).
Основна мета кожного із цих компонентів:
Доменний Аналіз – визначення набору повторно використовуваних вимог для систем в домені.
Доменне Проектування – створення спільної (загальної) архітектури для систем в домені.
Реалізація Домену – реалізація повторно використовуваних ресурсів, наприклад, повторно-використовувані компоненти, доменно-орієнтовані мови, генератори і повторно використовувана інфраструктура.
Доменний аналіз (аналіз предметної області) використовується для визначення домену, збору інформації про домен і вироблення доменної моделі.
Метою ДА є:
- Вибір і визначення домену.
- Збір важливої (необхідної) інформації про домен і інтеграція її в зв’язану (єдину) модель домену.
Джерелами доменної інформації є існуючі системи в домені, експерти домену, система довідників, книжок, створення прототипів, експерименти, вже відомі вимоги до майбутньої системи.
ДА не тільки включає записи існуючих знань домену. Систематична організація існуючих знань дозволяє і заохочує розширювати їх в творчих цілях. Таким чином ДА є креативною діяльністю.
Доменна модель є явним представленням спільних і відмінних властивостей систем в домені і залежностей між відмінними властивостями. В загалі модель домену складається із наступних компонентів:
- Визначення домену. «Визначення домену» визначає область домену і характеризує його вміст за допомогою прикладів систем в домені, контр прикладів (тобто, систем за межами домену) і загальні правила включення або виключення (наприклад, «будь-яка система, що має можливість (здатність) Х належить домену»).
- Лексикон домену: Доменний лексикон визначає доменний словник.
- Концептуальні моделі: Концептуальні моделі описують поняття в домені виражених (відображених) в деяких відповідних формалізмах моделювання (наприклад, діаграми взаємодії і переходу стану або сутність-зв'язок, діаграми потоку даних).
- Моделі характеристик (можливостей). Визначають набір повторно використовуваних і конфігуруємих вимог до специфікованих систем домену. ДА зазвичай включає наступні процеси (діяльності):
1) Планування домену, ідентифікація, і обмеження: планування ресурсів для виконання ДА, ідентифікація інтересів домену, визначення границь домену.
2) Моделювання домену: розробка доменної моделі
Характеристика домену і планування – цей крок аналізує здійсненність ДА з комерційної та технічної точки зору. Якщо ДА можна здійснити, дані про домен визначаються і планується ДА. Крок складається з п’яти під кроків. Ці під кроки не є суворо послідовними; інформація від одного підкроку може вимагати перегляду більш ранніх під кроків.
Збір даних – це діяльність по збору необроблених даних, які доменний аналітик може пізніше відфільтрувати, уточнити, абстрагувати, організувати.
2.1. Відновлення абстракцій – доменний аналітик отримує (відшукує) докладну інформацію про існуючі додатки відносно відповідних компонент (наприклад, інтерфейс користувача, архітектури), поведінку та оригінальний дизайн системи і обґрунтування. Аналітик може використовувати реверсивну інженерію у відновленні абстракцій.
2.2. Огляд літератури
2.3. Отримання знань від експертів – експерти можуть визначати основні принципи, обґрунтування проекту і пастки системи. Вони можуть також перевіряти інформацію від інших джерел.
2.4. Розробка сценаріїв – сценарії пояснюють як зазвичай використовують системи користувачі та інші системи
3. Аналіз даних – в цій діяльності, доменний аналітик перевіряє дані на коректність, несуперечність і повноту.
3.1. Визначення сутностей, подій, операцій і взаємозв’язку – доменний аналітик описує домен з точки зору основних блоків даних, функцій, що виконуються над ними, зовнішніх події, які їх стосуються і зв'язок між ними і в середині них.
3.2. Моделювання інформації – доменний аналітик моделює інформацію функціональною декомпозицією і декомпозицією даних чи об’єктно-орієнтованим аналізом, розробляє і записує проекти рішень.
3.3. Аналіз подібності – аналітик визначає схожість для того, щоб дозволити консолідацію подібних додатків.
3.4. Аналіз відмінності – аналіз пропонує перераховувати, параметризувати чи інкапсулювати відмінності.
3.5. Аналіз комбінацій – комбінації пропонують структурні чи поведінкові схеми і/або архітектури.
3.6. Аналіз компромісів – компроміси пропонують декомпозувати архітектури різними способами, що відповідають несумісним наборам вимог.
4. Класифікація – класифікація є основною моделюючою діяльністю в ДА. Вона збирає і детально формулює структуру інформації для класів додатків.
4.1. Описи груп – інформаційний пошук групуючих алгоритмів, інколи використовується для групування описів.
4.2. Абстрактні описи – формуються узагальнення усіх описів в межах кожної групи, виділяючи найбільш важливі загальні властивості.
4.3. Класифікація описів – коли нові описи доступні, вони назначаються в групу або групи реорганізовуються, для включення нового опису.
4.4. Узагальнення описів – створюються ієрархії з метою зв’язування абстрактних описів разом.
4.5. Створення словника – словник домену, чи мова, додатково створюються важливі доменні жаргони і формалізуються, щоб допомагати в процесі класифікації.
5. Перевірка доменної моделі – критерії перевірки не включені в окремі методи і відповідно, не являються частиною загального процесу ДА, виділеного Arango.
Хоча існує велика кількість методів ДА, але ніхто і ніколи не намагався їх класифікувати. Лише в 1992 році Arango і Wartik здійснили порівняння методів за різними критеріями.
Ferre X. і Vegas S.в своїй роботі запропонували класифікувати методи ДА в залежності від типу елементу, що буде повторно використовуватись:
1. Методи для повторного використання програмних компонентів (Draco, Mc Cain, Prieto-Diaz);
2. Методи для повторного використання активів (HP, ODM);
3. Методи для повторного використання архітектури / проектів ПЗ (FODA, IDeA, STARS, DADO);
4. Методи для повторного використання вимог до ПЗ (Synthesis, JODA).
Найбільш розповсюдженими підходами до ДА є підходи Synthesis, IDeA, KAPTUR, Prieto-Diaz, FODA.
Метод KAPTUR
KAPTUR (Knowledge Acquisition for Preservation of Tradeoffs and Underlying Rationales) є як інструментальним середовищем так і процесом доменного аналізу. Він розглядає повторне використання доменних активів з точки зору їх властивостей (можливостей), які представляють собою компоненти системи, об’єкти, функції в домені. Термін «можливість» використовується в іншому значенні чим методи FODA, Synthesis, де «можливості» відносяться тільки до функціональних характеристик системи. Підхід KAPTUR надає допомогу виробникам в 1) отриманні інформації із архітектурних видів і 2) у введенні і класифікації текстової інформації на всіх рівнях абстракції. Переваги метода KAPTUR є перевірка доменної моделі і збір обґрунтувань домену.
Дата добавления: 2015-07-11; просмотров: 307 | Нарушение авторских прав