# Запити зацікавлених осіб
# Вступ
Цей розділ містить інформацію для осіб, які зацікавлені в ознайомленні з проєктом Duallo. Тут задокументовано інформацію про цільову аудиторію продукту, визначення, які стосуються розробки якісного ПЗ, характеристику ділових процесів і сформульовано вимоги щодо
# Мета
Аналіз цільової аудиторії продукту, вимог і запитів від різних груп зацікавлених осіб, вимог до функціональності, практичності, надійності, продуктивності, експлуатаційної придатності задля створення сучасного і зручного ПЗ для керування проєктами.
# Контекст
Цей документ описує загальний процес роботи із комерційними та некомерційними проєктами на основі наведених нижче прикладів і розкриває всі переваги нашого інструменту Duallo.
# Основні визначення та скорочення
Зацікавлені сторони (особи) (opens new window) - фізичні та юридичні особи, які мають легітимний інтерес у діяльності організації, тобто певною мірою залежать від неї або можуть впливати на її діяльність.
Бізнес-процеси (opens new window) - визначаються цілями й завданнями діяльності суб'єкта господарювання. Процеси забезпечують реалізацію всіх видів діяльності підприємства, пов'язаних з виробництвом товарів і/або послуг.
ISO 9126 (opens new window) - є міжнародним стандартом для оцінки якості продукту (ПЗ). Він розділений на чотири частини, в яких розглядаються наступні теми:
- Зовнішні показники
- Внутрішні показники
- Модель якості
- Показники якості програмного забезпечення
FURPS (opens new window) - це абревіатура, яка характеризує:
функціональність (Functionality)
практичність (Usability)
надійність (Reliability)
продуктивність (Performance)
експлуатаційну придатність (Supportability)
програмного забезпечення комп’ютерних систем і також використовується для визначення багатьох пов’язаних систем і послуг.
UML (Unified Modeling Language) (opens new window) - невід'ємною частиною уніфікованого процесу розробки програмного забезпечення. UML є мовою широкого профілю, це відкритий стандарт, що використовує графічні позначення для створення абстрактної моделі системи, яка називається UML-моделлю.
Інші визначення знаходяться тут.
# Посилання
- Зацікавлені сторони (особи) (opens new window)
- Бізнес-процеси (opens new window)
- ISO 9126 (opens new window)
- FURPS (opens new window)
- UML (Unified Modeling Language) (opens new window)
# Короткий зміст
# Характеристика ділових процесів
Для ефективного управління проектами критично важливо зрозуміти, як система взаємодіє зі своїм оточенням. Розуміння зовнішніх та внутрішніх факторів і їх взаємодії дозволить створити гнучку модель управління проектами.
Зовнішнім фактором, тобто бізнес-актором є:
- Клієнт (customer) - це особа або організація, яка встановлює вимоги до проекту та очікує його виконання. Він не спілкується з системою управління проектами напряму, але взаємодіє з нею за допомогою бізнес-робітників.
Внутрішніми факторами, тобто бізнес-робітниками є:
- Тімлід - це особа, яка координує роботу команди, розділяючи задачі на підзадачі, ділить їх між розробниками та контролює якість та своєчасність виконання робіт.
- Робітник (розробник) - це користувач системи, задіяний у проекті, який виконує певні завдання або підзадачі. Він фокусується на своїй безпосередній роботі, плануючи її самостійно, і має базові права в системі.
- Адміністратор системи - це спеціаліст, який вирішує технічні проблеми інформаційного забезпечення, відповідає на запити користувачів та контролює дотримання правил користування системою.
Для оптимального співробітництва між бізнес-акторами, бізнес-робітниками та системою складено наступні бізнес-сценарії:
| ID | UserSignIn |
|---|---|
| Назва: | Зареєструвати користувача (Sign In) |
| Учасники: | Користувач (тімлід, або розробник), система |
| Передумови: | - Користувач не має облікового запису в системі |
| Результат: | Створений обліковий запис користувача |
| Виключні ситуації: | Користувач не заповнив усі обов'язкові поля форми для реєстрації NullReferenceException Обліковий запис вже існує у системі UserAlreadyExistsException Користувач увів пароль, який не відповідає всім вимогам "надійного паролю" (A-Z, a-z, 0-9, !-*, мінімум 8 символів) NotStrongPasswordException |
| Основний сценарій: | 1. Користувач натискає кнопку "Створити обліковий запис" 2. Користувач вводить реєстраційні дані 3. Користувач натискає кнопку "Зареєструватися" (можливі NullReferenceException та NotStrongPasswordException) 4. Система перевіряє наявність облікового запису користувача (можливе UserAlreadyExistsException) 5. Система створює новий обліковий запис 6. Користувач переходить у щойностворений обліковий запис |
| ID | UserGitHubSignIn |
|---|---|
| Назва: | Зареєструвати користувача (Sign In) за допомогою GitHubApi |
| Учасники: | Користувач (тімлід, або розробник), система |
| Передумови: | - Користувач не має облікового запису в системі |
| Результат: | Створений обліковий запис користувача (через інформацію, отриману з GitHub профілю користувача) |
| Виключні ситуації: | Користувач не має облікового запису GitHub (У даному випадку помилки обробляються самим GitHubApi) Обліковий запис (створений за допомогою GitHubApi) вже існує в системі UserAlreadyExistsException |
| Основний сценарій: | 1. Користувач натискає кнопку "Створити обліковий запис" 2. Користувач обирає варіант "Зареєструватися за допомогою GitHub" 3. Користувач натискає на свій обліковий запис GitHub (або вводить дані облікового запису в GitHubApi) 4. Система перевіряє наявність облікового запису користувача (можливе UserAlreadyExistsException) 5. Система створює новий обліковий запис 6. Користувач переходить у щойностворений обліковий запис |
| ID | UserLogIn |
|---|---|
| Назва: | Авторизувати користувача (Log In) |
| Учасники: | Користувач (тімлід, або робітник), система |
| Передумови: | - Користувач зареєстрований у системі - Користувач не авторизований у системі |
| Результат: | Новий сеанс роботи користувача |
| Виключні ситуації: | У формі авторизації не заповнені одне, або більше полів NullReferenceException Користувач не зареєстрований у системі NullInstanceException Користувач ввів неправильний пароль WrongPasswordException |
| Основний сценарій: | 1. Користувач вводить дані авторизації 2. Користувач натискає кнопку "Увійти" (можливе NullReferenceException) 3. Система перевіряє наявність облікового запису користувача (можливе NullInstanceException) 4. Система перевіряє отримані дані, введені користувачем (можливе WrongPasswordException) 5. Система авторизує користувача |
| ID | UserGitHubLogIn |
|---|---|
| Назва: | Авторизувати користувача (Log In) за допомогою GitHubApi |
| Учасники: | Користувач (тімлід, або робітник), система |
| Передумови: | - Користувач зареєстрований у системі (за допомогою GitHubApi) - Користувач не авторизований у системі |
| Результат: | Новий сеанс роботи користувача |
| Виключні ситуації: | Користувач не зареєстрований у системі NullInstanceException Облікового запису GitHub не існує (У даному випадку помилки обробляються самим GitHubApi) |
| Основний сценарій: | 1. Користувач натискає на "Увійти за допомогою GitHub" 2. Користувач натискає на свій обліковий запис GitHub (або вводить дані облікового запису в GitHubApi) 3. Система перевіряє наявність облікового запису користувача (можливе NullInstanceException) 4. Система авторизує користувача |
| ID | EditUser |
|---|---|
| Назва: | Редагувати дані користувача |
| Учасники: | Користувач (адміністратор системи, тімлід, або робітник), система |
| Передумови: | - Користувач зареєстрований у системі з даними, введеним при реєстрації (що б змінити дані користувача, який реєструвався за допомогою GitHubApi, йому потрібно змінити ці дані у самому GitHub) - Користувач бажає змінити дані облікового запису - Користувач авторизований у системі |
| Результат: | Користувач має відредагований профіль |
| Виключні ситуації: | Користувач змінив пароль на інший, який не відповідає всім вимогам "надійного паролю" (A-Z, a-z, 0-9, !-*, мінімум 8 символів) NotStrongPasswordException Користувач змінив дані у будь-якому полі на пусті (null) NullReferenceException |
| Основний сценарій: | 1. Користувач натискає на "Редагувати профіль" 2. Користувач обирає потрібне йому поле для зміни (Ім'я, Прізвище, Вік, Стать, Компанія, Місце навчання, Пароль) 3. Користувач змінює дані у будь-якому із цих полів і натискає на "Зберегти зміни" (можливі NotStrongPasswordException та NullReferenceException) 4. Система записує зміни у профіль користувача 5. Користувач переходить до оновленого облікового запису |
| ID | CreateTask |
|---|---|
| Назва: | Створити завдання |
| Учасники: | Користувач (тімлід, або робітник), система |
| Передумови: | - Користувач авторизований - Користувач обрав проект |
| Результат: | Завдання створене |
| Виключні ситуації: | У формі створення завдання не заповнені обов'язкові поля NoEssentialDataException |
| Основний сценарій: | 1. Користувач натискає кнопку "Створити завдання" 2. Користувач вводить назву завдання (обов'язково), опис, статус (todo/in progress/done/in rewiew), кому призначене завдання, дедлайн 3. Користувач натискає кнопку "Створити" 4. Система перевіряє наявність обов'язкових полів (можливе NoEssentialDataException) 5. Система створює і відображає завдання у відповідному розділі проєкту 6. Система повідомляє інформацію про завдання користувачам, яким воно було призначене |
| ID | EditTask |
|---|---|
| Назва: | Редагувати завдання |
| Учасники: | Користувач (тімлід, або робітник), система |
| Передумови: | - Користувач авторизований - Користувач обрав завдання |
| Результат: | Завдання відредаговане |
| Виключні ситуації: | У формі редагування завдання не заповнені обов'язкові поля NoEssentialDataException Під час редагування, завдання було видалено TaskNotExistException |
| Основний сценарій: | 1. Користувач натискає кнопку "Редагувати завдання" 2. Користувач редагує завдання 3. Користувач натискає кнопку "Зберегти" (можливе TaskNotExistException) 4. Система перевіряє наявність обов'язкових полів (можливе NoEssentialDataException) 5. Система зберігає внесені користувачем зміни та відображає відредаговане завдання 6. Система повідомляє інформацію про завдання користувачам, яким воно було призначене |
| ID | DeleteTask |
|---|---|
| Назва: | Видалити завдання |
| Учасники: | Користувач (тімлід, або робітник), система |
| Передумови: | - Користувач авторизований - Користувач обрав завдання |
| Результат: | Завдання видалене |
| Виключні ситуації: | Користувач натиснув кнопку "Скасувати" CancelException Користувач не має прав на видалення цього завдання AccessDeniedException |
| Основний сценарій: | 1. Користувач натискає кнопку "Видалити завдання" 2. Система виводить вікно для підтвердження видалення 3. Користувач натискає кнопку "Підтвердити" (можливе CancelException) 4. Система видаляє завдання (можливе AccessDeniedException) |
| ID | FilterTask |
|---|---|
| Назва: | Відфільтрувати завдання |
| Учасники: | Користувач (тімлід, або робітник), система |
| Передумови: | -Користувач авторизований -Користувач обрав проєкт |
| Результат: | Відфільтровані завдання |
| Виключні ситуації: | У проєкті нема жодних завдань NoTasksException |
| Основний сценарій: | 1. Користувач натискає кнопку "Використати фільтр" (можливе NoTasksException) 2. Користувач обирає параметри для фільтрування 3. Система відображає відфільтровані завдання |
| ID | CommentTask |
|---|---|
| Назва: | Коментувати завдання |
| Учасники: | Користувач (тімлід, або робітник), система |
| Передумови: | -Користувач авторизований -Користувач обрав проект -Користувач обрав завдання |
| Результат: | Коментар до завдання |
| Виключні ситуації: | Під час написання коментарію завдання було видалене TaskNoExistException Користувач скасував операцію CancelCommentException |
| Основний сценарій: | 1. Користувач натискає кнопку "Додати коментар" 2. Користувач пише коментар (можливе CancelCommentException) 3. Користувач натискає кнопку "Надіслати" (можливе TaskNoExistException) 4. Cистема зберігає коментар та повідомляє інших учасників цього завдання про новий коментар |
| ID | CreateProject |
|---|---|
| Назва: | Створити проєкт |
| Учасники: | Користувач (тімлід), система |
| Передумови: | - Користувач авторизований |
| Результат: | Новий проєкт |
| Виключні ситуації: | Проєкт з таким іменем вже створений NotUniqueProjectName |
| Основний сценарій: | 1. Користувач заходить в меню управління проєктами 2. Користувач натискає "Створити новий проєкт" 3. Користувач заповнює поля з інформацією проєкту 4. Користувач натискає "Створити" (можливе NotUniqueProjectName) 5. Система створює проект 6. Система відкриває новостворений проект |
| ID | DeleteProject |
|---|---|
| Назва: | Видалити проєкт |
| Учасники: | Користувач (тімлід), система |
| Передумови: | - Проєкт не був видалений до цього |
| Результат: | Проєкт є видалений |
| Виключні ситуації: | Користувач не проходить перевірку на підтвердження вибору (Captcha) NotConfirmedActionException Користувач натиснув кнопку скасувати CancelException |
| Основний сценарій: | 1. Користувач заходить в меню управління проєктами 2. Користувач обирає меню дій над потрібним проєктом 3. Користувач натискає "Видалити проект" 4. Система відкриває вікно з підтвердженням видалення (можливе NotConfirmedActionException, CancelException) 5. Користувач нажимає кнопку "Видалити" 6. Система видаляє проект |
| ID | AddMember |
|---|---|
| Назва: | Додати робітника до проєкту |
| Учасники: | Користувач (тімлід), система |
| Передумови: | - Користувач авторизований - Користувач обрав проект - Користувач має необхідні права доступу до функціоналу системи |
| Результат: | Користувач стає учасником проєкту |
| Виключні ситуації: | Такого користувача не існує UserNotExistException Користувач вже є партійним діячем UserAlreadyProjectMemberException |
| Основний сценарій: | 1. Користувач заходить в меню управління проєктами 2. Користувач обирає меню дій над потрібним проєктом 3. Користувач натискає "Додати робітника" 4. Система відкриває вікно з інформаційними полями (можливе UserAlreadyProjectMemberException, UserNotExistException) 5. Система відображає користувача у списку учасників проекту |
| ID | DeleteMember |
|---|---|
| Назва: | Видалити робітника з проєкту |
| Учасники: | Користувач (тімлід), система |
| Передумови: | - Користувач авторизований - Користувач має необхідні права доступу до функціоналу системи - Існують інші учасники проекту |
| Результат: | Користувач більше не учасник проєкту |
| Виключні ситуації: | Натиснута кнопка "Скасувати" CancelDeleteMemberException Користувач не є робітником проєкту UserIsNotProjectMemberException |
| Основний сценарій: | 1. Користувач заходить в меню управління проєктами 2. Користувач обирає меню дій над потрібним проєктом 3. Користувач натискає "Видалити робітника" 4. Система відкриває вікно з інформаційними полями (можливе UserIsNotProjectMemberException, CancelDeleteMemberException) 5. Користувач підтверджує видалення учасника 6. Система не відображає користувача у списку учасників проекту |
| ID | CreateSprint |
|---|---|
| Назва: | Створити Sprint (opens new window) (далі - Спрінт) |
| Учасники: | Користувач (тімлід), система |
| Передумови: | - Користувач авторизований - Попередній Спрінт вже закінчився |
| Результат: | Спринт створений |
| Виключні ситуації: | Номер/назва Спрінта не є унікальною NotUniqueSpringNameException Натиснута кнопка "Скасувати" CancelException |
| Основний сценарій: | 1. Користувач заходить в меню управління проєктами 2. Користувач обирає меню дій над потрібним проєктом 3. Користувач натискає "Створити та почати новий Спрінт" 4. Система відкриває вікно з інформаційними полями (можливе NotUniqueSpringNameException, CancelException) 5. Користувач заповнює поля 6. Система повідомляє учасникам спринту інформацію про спринт |
| ID | FinishSprint |
|---|---|
| Назва: | Закінчити Sprint (opens new window) (далі - Спрінт) |
| Учасники: | Користувач (тімлід), система |
| Передумови: | - Користувач авторизований - Поточний Спрінт вже наближається до кінця |
| Результат: | Спрінт закінчений |
| Виключні ситуації: | Користувач не проходить перевірку на підтвердження вибору (Captcha) NotConfirmedActionException Натиснута кнопка "Скасувати" CancelException |
| Основний сценарій: | 1. Користувач заходить в меню управління проєктами 2. Користувач обирає меню дій над потрібним проєктом 3. Користувач натискає "Закінчити Спрінт" 4. Система відкриває вікно з підтвердженням вибору (можливе NotConfirmedActionException, CancelExceptionК 5. Користувач виконує підтвердження 6. Система повідомляє учасників спринта про його завершення |
| ID | BanUser |
|---|---|
| Назва: | Блокувати користувача |
| Учасники: | Користувач (адміністратор системи, тімлід, або робітник), система |
| Передумови: | - Користувач порушив угоди використання програмного забезпечення - Забезпечення безпеки системи |
| Результат: | Блокування користувача |
| Виключні ситуації: | Користувача вже заблоковано UserIsBannedException Користувача з введеними даними не існує NullInstanceException |
| Основний сценарій: | 1. Адміністратор отримав достатню кількість скарг для огляду діяльності користувача 2. Адміністратор робить висновок щодо блокування користувача 3. Адміністратор системи натискає на "Дії з користувачем" 4. Адміністратор заповнює форму для блокування (причина, тривалість) 5. Адміністратор натискає на "Заблокувати користувача" 6. Система блокує користувача (можливі UserIsBannedException та NullInstanceException) та надсилає йому інформацію про блокування 7. Адміністратор оцінює результат блокування |
| ID | UnBanUser |
|---|---|
| Назва: | Розблокувати користувача |
| Учасники: | Користувач (адміністратор системи, тімлід, або робітник), система |
| Передумови: | - Користувач заблокований |
| Результат: | Розблокування профілю користувача |
| Виключні ситуації: | Користувача вже розблоковано UserIsUnBannedException Користувача з введеними даними не існує NullInstanceException |
| Основний сценарій: | 1. Адміністратор знаходить заблокованого користувача 2. Адміністратор визначає причину розблокування 3. Адміністратор системи натискає на "Дії з користувачем" (можливе NullInstanceException) 4. Адміністратор натискає на "Розблокувати користувача" (можливе UserIsUnBannedException) 5. Система розблоковує доступ користувачу та повідомляє йому інформацію про розблокування (надіславши лист на пошту) 6. Адміністратор оцінює результат розблокування |
| ID | UserSupport |
|---|---|
| Назва: | Вирішити проблему користувача |
| Учасники: | Користувач (адміністратор системи, тімлід, або робітник), система |
| Передумови: | - Користувач бажає написати повідомлення до технічної підтримки |
| Результат: | Вирішення проблеми користувача |
| Виключні ситуації: | Користувач не авторизований в системі UserIsNotLoggedInException |
| Основний сценарій: | 1. Користувач натискає на "Користувацька підтримка" 2. Система перекидає користувача на сторінку F.A.Q. 3. Користувач натискає на "Звʼязатися з адміністрацією" (можливе UserIsNotLoggedInException) 4. Користувач пише повідомлення й надсилає його 5. Система надсилає це повідомлення до профілю адміністрації 6. Адміністратор вирішує проблему користувача |
# Короткий огляд продукту
Система управління проєктами (СУП) - це структурований набір процесів, методів, інструментів та ресурсів, які використовуються для планування, виконання, моніторингу та контролю проєктів з метою досягнення їхніх цілей в рамках обмежень, таких як бюджет, час та ресурси.
Duallo - це інструмент управління проектами, який спрощує створення проектів будь-якого розміру за допомогою своїх функцій. Він сприяє легкості розробки проекту, дозволяючи ефективно організувати проектне процесування та його керування.
Основні категорії користувачів системи:
- PM(Project Manager), або тімлід - відповідає за планування, організацію та керування проектом. Він адмініструє СУП та координує роботу всіх учасників проекту.
- Команда розробників проекту - фахівці, які працюють над виконанням конкретних завдань у проекті. Вони використовують СУП для відстеження своїх завдань, внесення звітів та спілкування з іншими учасниками проекту.
- Замовник - особа або організація, яка ініціювала проект і визначає його вимоги та цілі. Вони можуть використовувати СУП для моніторингу прогресу та забезпечення відповідності проекту їхнім потребам.
- Аналітики та керівництво - ці особи можуть використовувати СУП для аналізу продуктивності проекту, прийняття рішень та розробки стратегій.
- Користувачі проекту - особи, що користуються результатами проекту (зацікавлені особи).
# Функціональність
Функціональні вимоги системи представлені через інтерфейси для різних груп користувачів та персоналу, що управляє системою управління проектами. Це дозволяє визначити, які можливості доступні кожній групі, розглянути їх взаємодію та чітко встановити межі системи, забезпечуючи необхідний функціонал для виконання робочих завдань. Також така організація сприяє розподілу учасників бізнесу за конкретними ролями та визначенню обов'язків та прав для кожної особи.
# Інтерфейс розробника (робітника)
Інтерфейс розробника є базовим набором можливостей користувача системи.
- зареєструвати користувача
- авторизувати користувача
- відредагувати профіль користувача у системі
- створити завдання
- редагувати завдання
- видалити завдання
- відфільтрувати завдання
- коментувати завдання
# Інтерфейс тімліда
Інтерфейс тімліда розширяє інтерфейс розробника і наділяється правами керування складом команди.
- додати користувача до проекту
- видалити користувача з проекту
- створити проект
- видалити проект
- створити спринт
- завершити спринт
# Інтерфейс адміністратора системи
Інтерфейс адміністратора передбачає найширші можливості керування системою, розширяючи попередні.
- звблокувати користувача
- розблокувати користувача
- вирішити проблему користувача (support)
# Практичність
- Простий мінімалістичний дизайн інтерфейсу, інтуїтивність
- Підтримка декількох мов
- Зрозуміла та приємна до вивчення документація, яка при цьому покриває всі можливості сервісу
- Кросплатформенність
- Підтримка використання гарячих клавіш
- Можливість бекапів (повернення видалених даних і відновлення доступу до аккаунту)
- Використання графічних методів відображення прогресу роботи користувачів (схеми, графіки, діаграми)
- Можливість відновлення паролю
- Адаптивніть під різні роздільні здатності дисплеїв
# Надійність
- Двохфакторна автентифікація
- Авторизація користувачів
- Чітке розділення можливостей користувачів відповідно до їх ролі в проєкті
- Просунуте шифрування та передавання конфіденційних даних, не допускаючи їх витоків
- Система повідомлення адміністраторів та користувачів про проблеми та несправності
- Регулярне створення резервних копій даних
- Автоматичний блок надмірної та/або незвичної активності
- Стійкість до високого трафіку
# Продуктивність
- Швидкий обмін даними
- Ефективне використання оперативної пам'яті, інтернет трафіку тощо
- Використання облачних сервісів
- Використання багатопоточності
- Гнучке налаштування лімітів використовуваних ресурсів кожного проєкту окремо
- Висока пропускна здатність
# Експлуатаційна придатність
- Постійна технічна підтримка сервісу, швидкий зворотній зв'язок
- Відкритість штабу розробників до пропозицій користувачів
- Можливість користувачів залишати фідбек або репортити баги
- Низький поріг входження для апаратного та програмного забезпечення
- Постійне впровадження оновлень
- Активне тестування
- Готовність до роботи в екстримальних умовах