1.3 Класифікація rup

У специфікаціях Rational Unified Process при класифікації вимог використовується модель FURPS+ з посиланням на стандарт IEEE Std 610.12.1990 [2.1].

Акронім FURPS означає наступні категорії вимог :

• Functionality (Функціональність)

• Usability (Застосовність)

• Reliability (Надійність)

• Performance (Продуктивність)

• Supportability (експлуатаційна придатність).

Символ "+" розширює FURPS -модель, додаючи до неї:

• обмеження проекту,

• вимоги виконання,

• вимоги до інтерфейсу,

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

Крім того, в специфікаціях RUP виділяються такі категорії вимог, як

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

• вимоги до ліцензування,

• вимоги до документування.

Правила роботи з вимогами до ПВ і загальнішими системними вимогами (до програмно-апаратної системи), визначаються наступними двома стандартами IEEE :

1. IEEE 830-1998 Recommended Practice for Software Requirements Specifications [7] (рекомендовані методи специфікації вимог до ПО).

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

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

1. Коректність або адекватність (відповідність реальним потребам).

2. Недвозначність (однозначність розуміння).

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

4. Несуперечність (узгодженість між різними елементами).

5. Впорядкованість по важливості і стабільності.

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

7. Модифікується (оформлення в зручних для внесення змін структурі і стилях).

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

2. IEEE 1233-1998, 2002 Guide for Developing System Requirements Specifications (керівництво по розробці специфікацій вимог до систем).

Описує правила побудови вимог для програмно-апаратних систем в цілому. Він виділяє наступні необхідні властивості набору вимог.

1. Одноразова згадка окремих вимог.

2. Відсутність перетинів між вимогами.

3. Явна вказівка зв'язків між вимогами.

4. Повнота.

5. Несуперечність.

6. Визначення обмежень, зони дії і контексту для кожної вимоги.

7. Модифікується.

8. Конфігурується, зручність підтримки.

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

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

10. Абстрактність - формулювання, незалежне від можливих реалізацій.

11. Недвозначність.

12. Прослеживаемость.

13. Проверяемость.

Стандарт наказує визначати наступні атрибути для кожної вимоги:

• Унікальний ідентифікатор.

• Пріоритет, важливість реалізації з точки зору користувачів.

• Критичність для побудови і успішності системи з точки зору аналітиків.

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

• Ризики високої вартості, наслідків використання для довкілля і користувачів, конфліктів із стандартами і законодавством.

• Джерело (тобто хто запропонував цю вимогу).

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

• Вимоги на вхідні дані.

• Вимоги на вихідні дані.

• Надійність (reliability, наприклад, середній час роботи між відмовами).

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

• Зручність супроводу (maintainability, наприклад, зручність заміни компонента).

• Продуктивність (performance, наприклад, середній час очікування відповіді).

• Доступність (accessibility, наприклад, різні способи доступу для новачків і досвідчених користувачів).

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

• Ергономічність (ergonomic, наприклад, використання набору кольорів, що знижують стомлюваність очей).

• Безпека (safety, наприклад, допустимі рівні електромагнітного випромінювання різних частот).

• Захищеність (security, наприклад, обмеження доступу для різних користувачів).

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

• Транспортуємість (transportability, наприклад, обмеження ваги).

• Зручність навчання (наприклад, включення повчальних матеріалів).

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

• Зовнішні інтерфейси (наприклад, підтримка стандартних форматів документів).

• Тестуємість (наприклад, підтримка видаленої діагностики).

• Умови необхідної якості (наприклад, максимально допустима погрішність вироблюваних вимірів).

• Наслідування корпоративних і законодавчих норм (наприклад, законам про охорону праці).

• Сумісність з відомими системами.

• Наслідування стандартів і технологічних норм.

• Конвертація даних (наприклад, із старої версії системи).

• Можливості зростання (наприклад, можливе збільшення числа користувачів).

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

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

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

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

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

4. Нечіткі вимоги, які можуть бути такими, що не перевіряють і суб'єктивними ("мінімізувати рівень погрішності", "зручний для користувачів інтерфейс"), або сформульовані у виді, відкритому для поповнення невизначеними елементами (з вказівкою "і т. д. " чи "включаючи, але не обмежуючись наступним.".).

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

Шаблон варіанту використання RUP

З шаблоном опису варіанту використання RUP і прикладами можна ознайомитися в інтерактивній версії RUP1).

Нижче приведений короткий огляд його розділів.

1. Найменування і короткий опис. У цьому розділі вказується: найменування варіанту використання, актори варіанту використання, короткий (у один абзац) опис варіанту використання.

2. Потік подій

2.1. Основний потік подій

Так само, як в "Основний сценарій".

2.2. Альтернативні потоки подій

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

3. Спеціальні вимоги

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

4. Передумови

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

5. Постумови

Постумова RUP по суті описує те ж, що і мінімальна гарантія у Коберна. Л. Новиков [8.3] акцентує увагу на тому, що коректно сформульована постумова має бути істинною при будь-якому можливому сценарії прецеденту, а не описаному в основному потоці.

6. Точки розширення

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

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

На сьогодні в арсеналі аналітика існують десятки методик, мов, візуальних представлень, що дозволяють моделювати вимоги до системи. При створенні інформаційних систем стандартом де-факто являється універсальна мова моделювання, UML [9.1,9.2].

6 Приклади варіантів використання :

У мові UML варіант використання зображається у вигляді овалу, поміченого ім'ям варіанту, що представляється. Варіанти використання можуть бути пов'язані з дійовими особами (actors), що беруть участь в них, зображуються у вигляді чоловічків і представляють різні ролі користувачів системи або зовнішні системи, що взаємодіють з нею.

Варіанти використання можуть бути пов'язані один з одним трьома видами зв'язків : узагальненням (generalization), розширенням (extend relationship) і включенням (include relationship). Дійові особи також можуть бути пов'язані один з одним за допомогою зв'язків узагальнення (generalization).

Например, для коммерческого летательного аппарата можно выделить двух актеров: пилота и кассира. Сидоров — пользователь, который иногда действует как пилот, а иногда — как кассир. Как изображено на рис. 12.27, в зависимости от роли Сидоров взаимодействует с разными элементами Use Case.

Рис. 1.2. Нарис діаграми варіантів використання для комерційного летательного аппарата

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

Варіант використання A розширює (extends) інший варіант використання B, якщо в ході сценарію роботи A за певних умов потрібно включити повний сценарій роботи B.

Добре описаний варіант використання має наступні атрибути:

1. Ім'я, що ясно говорить про призначення варіанту використання.

2. Опис. Декілька пропозицій, що описують цей варіант використання.

3. Частота. Наскільки часто цей варіант використання виникає.

4. Передумови. Усі умови запуску варіанту використання.

5. Постумови. Усі умови, які мають бути виконані після успішного виконання варіанту використання.

6. Основний сценарій роботи, який використовується в більшості випадків.

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

8. ((Необов'язково) Задіяні дійові особи.

9. ((Необов'язково) Розширювані варіанти використання.

10. ((Варіанти використання, що Необов'язково) Включаються.

11. ((Необов'язково) Статус: "в розробці", "готовий до перевірки", "в процесі перевірки", "підтверджений", "знехтуваний".

12. ((Необов'язково) Допущення про оточення і хід роботи системи, використані при розробці цього варіанту. У повністю готовому варіанті ці допущення або мають бути підтверджені і стати обмеженнями системи, або повинні давати початок різним сценаріям роботи.

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

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

Симулятор повинен:

• Моделювати певні умови польоту і створювати деякі події, до яких відносяться наступні, :

  • Швидкісний і висотний режим польоту, запас пального, їх зміни з часом.

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

  • Погода за бортом і її зміни з часом.

  • Рельєф і інші особливості місцевості у нинішній момент, їх зміни з часом.

  • Початковий і кінцевий пункти польоту, відстань і основні характеристики рельєфу між ними.

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

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

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

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

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

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

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

Рисунок 1.3 - Зразкова архітектура авіасимулятора

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