Шаблон специфікації вимог до пз

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

Складові специфікації вимог:

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

1. Призначення (визначається продукт або застосування, для якого розробляється дана спека; редакція або номер випуску)

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

3. Передбачувана аудиторія і рекомендації з читання (зазначити користувачів, для яких розрахована дана спека, описати зміст документу і його структуру)

4. Границі проекту (описується ПЗ і його призначення, коротко. Тут потрібно показати, як продукт пов'язаний із бізнес цілями і стратегіями даного підприємства)

5. Посилання (перерахувати всі документи, на які посилається спека (контракти, стандарти та інші).

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

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

   2. Особливості продукту (перелік основних особливостей продукту або його головних функцій, детальніше функції будуть розписані в п.3; варто проілюструвати основні групи вимог і їх взаємовідношення (діаграму потоків даних і варіантів використання))

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

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

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

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

   7. Припущення і залежності

2. Функції системи

   1. Функція системи Х

      1. Опис і пріоритети

      2. Послідовності «вплив-реакція»

      3. Функціональні вимоги

3. Требования к внешним интерфейсам

   1. Интерфейсы пользователя (UX)

   2. Программные интерфейсы

   3. Интерфейсы оборудования

   4. Интерфейсы связи и коммуникации

4. Нефункциональные требования

   1. Требования к производительности

   2. Требования к сохранности (данных)

   3. Критерии качества программного обеспечения

   4. Требования к безопасности системы

5. Прочие требования

• Приложение А: Глоссарий

• Приложение Б: Модели процессов и предметной области и другие диаграммы

• Приложение В: Список ключевых задач

13. Характеристики правильно складеної SRS

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

SRS можуть бути складені одним або декількома представниками постачальника, одним або декількома представниками клієнта, або обома.

Характеристика правильно складеної SRS :

• Коректність

• Однозначність

• Повнота

• Несуперечливість

• Упорядкованість за значністю

• Перевіряємість

• Модифікуємість

• Відслідковуваність

14. Проблемні ситуації процесу формування і оцінки вимог

Проблемні ситуації:

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

2. «Золочення» продукту – такі ситуації, коли розробники додають функції, яких немає в специфікації, але їм здається, що це сподобається користувачам. Але замовнику може це не сподобатись.

3. Мінімальна специфікація – представлення вимог на 2-3 сторінках (у невеликих проектах). Мінімальне спека доречна, якщо має місце наявність одночасно трьох обставин:

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

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

   3. Між замовником та розробником існують конструктивні відносини і обидві сторони розуміють і приймають ризики міні-специфікації.

15. Методи і засоби перевірки вимог

Методи і засоби перевірки вимог розрізняють за параметрами:

1. За широтою аналізу – перегляд (вибіркова перевірка)

2. За ступенем формалізації – неофіційні процедури, процедури, що проводяться за формальними правилами (інспекції, експертизи).

3. За складом групи перевірки – з (без) участю автора, з (без) участі менеджера проекту, з (без) участю представників зовнішніх організацій.

4. За використовуваними засобами – тексти вимог, тестові сценарії, критерії прийнятності, прототип.

Неофіційні перегляди вимог:

1. Перегляди «за столом» (коли перевірку робить колега по роботі)

2. Колективна перевірка (коли запрошується декілька колег для паралельної перевірки продукту)

3. Критичний аналіз (автор описує створюваний продукт і просить його прокоментувати).

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

Офіційна перевірка вимог:

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

Головний результат – сукупність усіх знайдених дефектів і піднятих питань.

Експертиза як метод перевірки вимог (інспекція):

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

Учасники:

1. Автор продукту і можливо колеги автора (аналітик, що склав документацію вимог)

2. Автор будь-якого попереднього продукту для елемента, який варто перевірити.

3. Люди, що виконують роботу, що базуються на перевіряємому елементі.

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

16. Неофіційні перегляди вимог. Інспекції

Неофіційні перегляди вимог:

4. Перегляди «за столом» (коли перевірку робить колега по роботі)

5. Колективна перевірка (коли запрошується декілька колег для паралельної перевірки продукту)

6. Критичний аналіз (автор описує створюваний продукт і просить його прокоментувати).

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

Експертиза як метод перевірки вимог (інспекція):

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

Учасники:

5. Автор продукту і можливо колеги автора (аналітик, що склав документацію вимог)

6. Автор будь-якого попереднього продукту для елемента, який варто перевірити.

7. Люди, що виконують роботу, що базуються на перевіряємому елементі.

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

Проблеми перевірки:

1. Великий об’єм документації

2. Велика команда експертів (бажано не більше шести)

3. Географічній роздій інспекторів (доводиться зв’язуватись по відео або пошті)

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

Ролі експертів:

1. Автор. Створює та підтримує продукт, що перевіряється. Тобто аналітик, що розробляв спеку.

2. Координатор – керівник перевірки, планує експертизу сумісно з автором, погоджує особливості і організовує нараду.

3. Читач. Один із перевіряючих виступає в ролі читача. На нараді він перефразовує положення спеки – по одній вимозі за раз.

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

Рішення про завершення експертизи приймається відповідно до одного (будь-якого) з трьох критеріїв:

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

2. Прийняття з перевіркою перероблених фрагментів.

3. Необхідність повторної експертизи.

17. Визначення критеріїв прийнятності

18. Принципи і прийоми управління вимогами

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

До дій по управлінню вимогами відносять:

• Визначення основної версії вимог (моментальний зріз вимог для конкретної версії продукту);

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

• Включення схвалених змін вимог в проект встановленим способом;

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

• Обговорення нових обов’язків, що базуються на оцінюванні впливу зміни вимог;

• Відслідковування окремих вимог до проектування, вихідного коду і варіантів тестування;

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

Принципи і прийоми управління вимогами

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

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

• у відповідності з новою функціональністю змінюється графік;

• страждає якість, так як необхідно вкластися в графік (дуже часто ця реакція за замовчуванням).

19. Базова версія вимог

Базова версія (baseline) – це набір функціональних і нефункціональних вимог, які розробники зобов’язалися реалізувати у визначеній версії (ітерації).

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

20. Процедури управління вимогами

Процедури управління вимогами базуються на:

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

• Правилах складання базової версії вимог;

• Статусах вимог, які будуть використовуватись, і категоріях осіб, які мають право змінювати їх;

• Процедурах контролю за статусом вимог;

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

• Методах аналізу впливу запропонованої зміни;

• Відслідковуванні зв’язків планів і обов’язків проекту зі змінами вимог.

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

21. Контроль версій

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

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

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

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

22. Атрибути вимог

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

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

23. Шаблон опису атрибутів вимог за К. Вігерсом

В якості шаблону опису атрибутів вимог К. Вігерс пропонує наступний набір:

• Дата створення вимоги;

• Номер поточної версії;

• Автор вимоги;

• Особа, що відповідає за задоволення вимоги;

• Відповідальний за вимогу або список зацікавлених осіб (щоб прийняти рішення про запропоновані зміни);

• Стан вимоги;

• Походження або джерело вимоги;

• Логічне обґрунтування вимоги;

• Підсистема (або підсистеми), для яких призначена вимога;

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

• Метод перевірки, що використовується або критерії тестування прийнятності;

• Пріоритет реалізації;

• Стабільність вимоги.

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

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

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

Implemented (реалізовано) - Код, що реалізує вимогу, розроблений, написаний і протестований. Вимогу відслідковано до відповідних елементів дизайну і коду

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

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

Rejected (відхилено) - Вимога запропонована, але не запланована для реалізації ні в одній із майбутніх версій. Необхідно описати причини відхилення вимог і назвати того, хто прийняв таке рішення.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

31. Поняття «Доменна інженерія»

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

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

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

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

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

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

32. Доменний аналіз

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

Метою ДА є:

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

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

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

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

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

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

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

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

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

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

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

33. Зміст процесів доменного аналізу

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

1. Виділення домену – традиційний бізнес і методи аналізу ризику визначають здійсненність ДА. Організації використовують ці методи для вирішення чи є проект доцільним для компанії в даний час, чи правильно виділений домен, чи є обґрунтованим повернення інвестицій і чи домен достатньо зрілий для аналізу.

2. Опис домену – ця діяльність визначає область дії і зміст домену, і встановлює межі на роботу ДА.

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

4. Створення переліку даних - складання опису (переліку) даних є необов’язковою діяльністю, яка готує безпосередньо до подальшого збору даних.

5. Планування проекту.

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

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.

34. Класифікація методів ДА

Хоча існує велика кількість методів ДА, але ніхто і ніколи не намагався їх класифікувати. Лише в 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 є перевірка доменної моделі і збір обґрунтувань домену.

Метод IDeA

Метод IDeA (Intelligent Design Aid) розроблений Lubars в 1991 році. IDeA представляє собою середовище проектування, що допомагає при проектуванні ПЗ і підтримує повторне використання абстрактних конструкцій, представлених у вигляді напівформальних схем проекту. Lubars використовує доменний аналіз для заповнення повторно використовуваних бібліотек.

Метод FODA

Метод FODA (Feature-oriented domain analysis) розроблений Інститутом програмної інженерії для знаходження спільних рис (можливостей/властивостей) у відповідних програмних системах, що можуть бути представлені в зручному форматі з картами в особливих випадках цих можливостей. Базуючись на надійних технологіях моделювання взятих із області програмної інженерії подібно ієрархічній декомпозиції і моделям сутність-зв'язок, метод FODA ближче до існуючих об’єднань інших методів. Переваги – по-перше, документація складається з детальних прикладів методів FODA; по друге, містить унікальну особливість: наявність декількох кроків перевірки; по третє, метод чітко визначає цілі, входи, виходи і внутрішні кроки кожної діяльності в процесі; і на кінець, метод FODA розкладає поняття «можливість» на функціональні, експлуатаційні. Можливості/властивості об’єднуються в ієрархії використовуючи відношення «consist is».

Метод Synthesis

Проект Synthesis в Software Productivity Consortium (SPC) призначений забезпечити членів своєї компанії методологією, яка інтегрується в підмандатний стандарт 2167А Міністерства оборони США. Методологія використовує доменний аналіз протягом фаз визначення системних і програмних вимог, побудови набору повторно використовуваних компонент, звертаючись до великого сімейства подібних систем. Подібно до метода FODA, він має відмінну документацію і опирається на результати декількох аналізів. Synthesis використовує репозитарій для зберігання всіх знань домену, які в свою чергу являються основою для процесу моделювання домену. SPC використовує об’єктно-орієнтований аналіз для формалізації вимог домену.

35. Доменне Проектування. Реалізація Домену

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

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

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

36. Лінійка програних продуктів.

Лінійка програних продуктів (Product Line Practice) – це вид виробництва продуктів по технологічній лінії із готових ресурсів (повторно використовуваних компонент, програми, застосувань, БД і т.д.) з метою задоволення потреб ринку

Технологія лінійки включає:

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

• зразки і каркаси, що використані на лінії;

• виробничі обмеження, стратегії і методи;

• набір засобів і інструментів розробки продукту на лінії

• контроль плану робіт і вияв ризиків;

• прогнозування вартісних і технічних ресурсів проекту;

• технологія управління конфігурацією;

• вимірювання та оцінка показників якості продукту.

37. Діаграми потоків даних.

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

Головна мета такого представлення – продемонструвати, як кожен процес перетворює свої вхідні дані у вихідні, а також виявити відношення між цими процесами.

Для побудови DFD традиційно використовуються 2 нотації, що відповідають методам Йордана і Гейн-Сарсона. Ці нотації дещо відрізняються одна від одної графічним зображенням символів.

Основні компоненти DFD:

• Зовнішні сутності;

• Процеси;

• Накопичувачі даних;

• Потоки даних.