• Лекція 6
• Уніфікований процес розробки (RUP). Визначення вимог
  • 6.1 Життєвий цикл ПЗ в RUP
  • 6.2 Ітеративна розробка ПЗ в RUP
  • 6.3 Робочий процес визначення вимог
    • 6.3.1 Процес визначення вимог
    • 6.3.2 Ідентифікація акторів у визначенні вимог
  • 6.4 Приклад 1. Завдання
    • 6.4.1 Ідентифікація акторів
    • 6.4.2 Ідентифікація ВВ
    • 6.4.3 Високорівнева діаграма ВВ
    • 6.4.4 Деталізована діаграма ВВ
  • 6.5 Опис архітектури
    • 6.5.1 Діаграма архітектури із описом підсистем
    • 6.5.2 Документування ВВ (скорочена форма)
    • 6.5.3 Документування ВВ (розширена форма).
    • 6.5.4 Процес
    • 6.5.5 Користувацькі інтерфейси
  • 6.6 Співробітники, задіяні в побудові моделі ВВ
  • 6.7 Робочий процес визначення вимог
    • 6.7.1 Етапи процесу створення UI

Лекція 6

Уніфікований процес розробки (RUP). Визначення вимог

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

Показники ефективності:

• • вартість;

  • якість;

  • витрачений час.

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

6.1        Життєвий цикл ПЗ в RUP

6.2        Ітеративна розробка ПЗ в RUP

Життєвий цикл ПЗ в RUP

Моделі розробляються в ході робочих процесів, кожен із яких характеризується:

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

• Обов'язків;

• Очікуваної поведінки.

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

Артефакт (artifact) – істотна частина інформації, яка створюється, змінюється або використовується співробітником під час розроблення ПП. Артефактом може бути модель, її елемент або документ.

Модель ВВ (use case model)

Модель ВВ (use-case model) – повний набір акторів, ВВ системи та взаємозв'язків між ними, у т.ч. прототип інтерфейсу, опис архітектури ПЗ, сценаріїв ВВ

Модель ВВ доповнюється глосарієм.

Коли розробляється модель ВВ у RUP

6.3        Робочий процес визначення вимог

6.3.1        Процес визначення вимог

• Ідентифікація акторів

• Визначення ВВ

• Ідентифікація опису кожного ВВ

• Опис моделі ВВ

Результат діяльності – артефакт нової версії моделі ВВ з новими або уточненими акторами та ВВ.

6.3.2        Ідентифікація акторів у визначенні вимог

Системний аналітик та замовник послідовно визначають:

• Користувачів.

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

Ідентифікація ВВ у визначенні вимог

Розробка Use Cases (UC) - варіантів використання (ВВ):

• • всі функції визначаються ВВ;

  • нефункціональні вимоги об'єднуються в один ВВ;

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

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

Інші артефакти у визначенні вимог

Опис архітектури – архітектурна форма моделі ВВ:

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

• є основою для визначення пріоритетів та послідовності розробки.

Архітектура – це організаційна структура та відповідна поведінка системи.

Архітектура може бути рекурсивно розкладена на частини, які взаємодіють через інтерфейси, відносини, які з'єднують частини, і обмеження на їх збірку. Частини системи, які взаємодіють через інтерфейси, включають класи, компоненти і підсистеми [UML 1.5].

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

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

6.4        Приклад 1. Завдання

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

Оплачені квитки повинні надсилатись на адресу email, вказану у замовленні. Клієнт може роздрукувати оплачені квитки.

Реєстрація в системі потрібна, якщо клієнт хоче отримувати персоналізовані пропозиції.

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

6.4.1        Ідентифікація акторів

Система онлайн-купівлі квитків на розважальні заходи

Актори:

• Клієнт (Новий та Зареєстрований) - особа, яка використовує веб-сайт для здійснення покупки квитків в Інтернеті

• Платіжна система - автоматизована система виконання он-лайн платежів

6.4.2        Ідентифікація ВВ

Система онлайн-купівлі квитків на розважальні заходи

Варіанти використання:

• Пошук заходів - клієнт шукає квитки за запитом про місто проведення, діапазоном дат та/або типом заходу.

• Придбання квитків - для відібраних у UC "Пошук заходів" клієнт обирає захід та кількість квитків і здійснює покупку, оплачені квитки надсилаються клієнту на вказаний у замовленні email.

• Реєстрація клієнта - новий клієнт реєструється на сайті (дані для реєстрації - логін, пароль, контактні дані: прізвище, ім’я, актуальний email)

• Аутентифікація - перевірка даних зареєстрованого клієнта.

6.4.3        Високорівнева діаграма ВВ

6.4.4        Деталізована діаграма ВВ

6.5        Опис архітектури

• Критичні для функціонування системи ВВ:

UC «Придбання квитків»

UC «Пошук заходів»

• ВВ, що впливають на структуру системи:

UC «Реєстрація клієнта»

UC «Аутентифікація»

6.5.1        Діаграма архітектури із описом підсистем

6.5.2        Документування ВВ (скорочена форма)

Потік подій (flow of events) – опис подій, які повинні відбутися під час реалізації поведінки ВВ.

Документація потоку подій ітеративно розробляється у Фазі Розробки (Elaboration Phase):

• Спочатку – короткий опис кроків, які потрібно пройти для нормального виконання ВВ (записуються функції ВВ);

• Із розвитком аналізу кроки обростають деталями;

• Наприкінці до потоку подій додається опис виключень у поведінці.

Актори, які ініціюють ВВ

X.1 Передумови  

X.2 Процес 

X.3 Субпотоки (виконання однієї функції різними засобами)

X.4 Альтернативні потоки (опис виключень поведінки) 

X.5 Післяумови

Червоний – обов’язкові елементи

Білій – деталізація виконання ВВ

6.5.3        Документування ВВ (розширена форма).

• Назва та короткий опис ВВ (Use Case Name)

• Актори, які взаємодіють із ВВ

• Пріоритетність в проекті (Priority)

• Статус (Status)

• Передумови (Pre-Conditions)

• Процес (Process)

• Розширення (Extension Points)

• Післяумови (Post-Conditions)

• Які ВВ використовуються (“Included” Use Cases)

• Користувацькі інтерфейси (User Interface)

Документування UC «Реєстрація клієнта»

• UC «Реєстрація клієнта» - не зареєстрований клієнт реєструється на сайті.

• Актори, які взаємодіють із ВВ – ініціює Новий клієнт

• Пріоритетність – розробляється після критичних для архітектури ВВ

• Статус – чернетка

• Передумови – новий клієнт у меню навігації натиснув кнопку «Вхід/Реєстрація»

6.5.4        Процес

з’являється вікно авторизації, у якому користувач натискає кнопку «Зареєструватись». Відкривається вікно реєстрації.

новий клієнт вводить логін (повинен містити літери, може включати цифри та знаки «_», «.»), пароль (повинен складатись із 6 символів, може містити літери і цифри), підтвердження паролю (має співпадати із паролем), контактні дані (Прізвище, ім’я, email – виконується перевірка) і натискає кнопку «Зареєструватись».

виконується перевірка унікальності логіну та актуальності адреси email.

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

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

    • якщо введений email не підтверджений, виводиться повідомлення про неможливість реєстрації із введеною адресою email 

Післяумови (Post-Conditions) – дані авторизації клієнта записані в БД сайту, клієнт переходить у групу акторів «Зареєстрований клієнт» і клієнт отримує доступ до системи як актор Зареєстрований клієнт.

6.5.5        Користувацькі інтерфейси

Співробітникові відповідає опис:

• Обов'язків;

• Очікуваної поведінки.

6.6        Співробітники, задіяні в побудові моделі ВВ

• Системний аналітик

• Специфікатор ВВ

• Розробник інтерфейсу користувачів

• Архітектор

Системний аналітик

• гарантує, що модель ВВ повна та узгоджена;

• не відповідає за кожен ВВ.

Специфікатор ВВ

• відповідає за детальний опис одного або кількох ВВ;

• працює із замовником.

Розробник UI (інтерфейсів користувача)

• створює проект інтерфейсу для одного або кількох акторів.

Архітектор

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

• планує ітерації.

6.7        Робочий процес визначення вимог

Модель предметної області – визначає найважливіші об'єкти змісту системи: предмети області та події в системі.

Класи предметної області: бізнес-об'єкти, об'єкти та поняття реального світу, події, що відбулися або будуть відбуватися в системі.

Діяльність:

• • Знаходження акторів та ВВ;

  • Визначення пріоритетності ВВ;

  • Деталізація ВВ;

  • Створення прототипу інтерфейсу;

  • Структурування моделі ВВ.

Робочий процес визначення вимог

Інтерфейс (UI та UX)

Інтерфейс користувача (User interface, UI) – метод виконання задачі за допомогою програмного забезпечення (Дж.Раскін).

Досвід користувача (User experience, UX) – враховуються характеристики користувачів та середовища користування.

Юзабіліті

Юзабіліті (Usability) - ступінь ефективності, затрат праці та задоволення, з якими продукт може бути використаний певними користувачами у певному контексті використання для досягнення визначених цілей (ISO 9241-11:2018 Ergonomics of human-system interaction -- Part 11: Usability: Definitions and concepts)

Для кого важливий проект інтерфейсу?

Користувач – проект гарантує зручність;

Проджект-менеджер – легше узгодити;

Тестувальник – легше перевіряти;

Розробник – зрозумілі вимоги до інтерфейсу пришвидшують розробку та підвищують якість;

Компанія-розробник ПЗ – полегшує підтримку ПЗ.

Підходи до проектування інтерфейсу

Орієнтоване на задачі користувача – виконання окремого завдання;

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

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

Цілеорієнтований дизайн (Goal-oriented design)

Орієнтований на потреби користувача (Goal Centered Design) – для чого користувачеві потрібне ПЗ.

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

Когнітивне тертя - поняття, введене А. Купером і характеризує ставлення людини до складної речі (наприклад, до комп'ютера) як до іншої людини. Таке ставлення виникає у ситуаціях, коли людина не може зрозуміти того, як і чому ця річ працює (або не працює).User-Centered Design

Орієнтований на користувача (User Centered Design) – ергономічність, зрозумілість;

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

6.7.1        Етапи процесу створення UI

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

• Аналіз

• Розроблення ескізу інтерфейсу

• Розробка (Implementation Support)

• Тестування інтерфейсу

Аналіз та розроблення екскізів у процесі проектування UI

Аналіз

• Інтерв'ю із користувачами

• Розроблення профілю користувачів

• Визначення цілей та задач користувачів

Розроблення ескізу інтерфейсу

• Візуальне моделювання (Modeling)

• Визначення пріоритетних показників ергономіки

• Узгодження вимог (Requirements Definition)

• Технічні обмеження (Framework Definition)

• Створення прототипів (Detailed Design)

Ітеративність процесу розроблення UI

CASE-засоби розробки ескізів інтерфейсу

Безкоштовні

• draw.io (https://www.diagrams.net/)

• moqups.com (1 проект)

• uxpin.com (1 прототип)

• realtimeboard.com (5 дошок)

trial-період

• Balzamiq

• Mockplus

• Edraw Max