Система управління проєктами

# Запити зацікавлених осіб

# Вступ

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

# Мета

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

# Контекст

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

# Основні визначення та скорочення

ISO 9126 — міжнародний стандарт для оцінки якості програмного забезпечення. Він складається з чотирьох частин, що охоплюють такі аспекти:

  • Зовнішні показники
  • Внутрішні показники
  • Модель якості
  • Показники якості ПЗ

UML (Unified Modeling Language) — мова моделювання, яка є важливою складовою уніфікованого процесу розробки програмного забезпечення. UML є відкритим стандартом, що застосовує графічні елементи для створення абстрактних моделей систем, відомих як UML-моделі.

FURPS — це абревіатура, що визначає такі характеристики програмного забезпечення:

  • Функціональність (Functionality)
  • Зручність використання (Usability)
  • Надійність (Reliability)
  • Продуктивність (Performance)
  • Підтримуваність (Supportability)

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

Бізнес-процеси — це процеси, які визначаються цілями та завданнями діяльності підприємства. Вони забезпечують реалізацію всіх видів діяльності, пов’язаних з виробництвом товарів або наданням послуг.

Модель акторів (opens new window) — математична модель паралельних обчислень, побудована на основі поняття «актора», яке вважається універсальним примітивом паралельного виконання. Актор в даній моделі взаємодіє з іншими акторами шляхом надсилання та отримання повідомлень. Отримавши повідомлення актор може опрацювати його, створити нових акторів, надіслати власні повідомлення, змінити власний стан, в тому числі стратегію опрацювання наступних отриманих повідомлень чи завершити свою роботу. Ця модель виступає як теоретична основа для ряду практичних реалізацій систем паралельних обчислень.

У даному пункті перечисленні не всі визначення, частина з них знаходяться тут.

# Посилання

  1. ISO 9126 (opens new window)
  2. UML (Unified Modeling Language) (opens new window)
  3. FURPS (opens new window)
  4. Зацікавлені сторони (opens new window)
  5. Бізнес-процеси (opens new window)
  6. Модель акторів (opens new window)

# Короткий зміст

# Характеристика ділових процесів

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

Бізнес-актори:

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

Бізнес-робітники:

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

У ході аналізу систем управління проєктами було створено наступні бізнес-сценарії взаємодії бізнес-акторів та бізнес-робітників між собою та системою:

ID CreateUser
Назва Створити користувача
Учасники Користувач, система
Передумови Система не зареєструвала користувача
Результат Система створює обліковий запис користувача
Виключні ситуації
  • Користувач не ввів ім'я користувача (NullUsernameException)
  • Користувач не ввів пошту (NullEmailException)
  • Користувач не ввів пароль (NullPasswordException)
  • Користувач з таким ім'ям вже існує (UserAlreadyExistsException)
  • Користувач вказав неправильний формат пошти (WrongEmailFormatException)
  • Користувач ввів недостатньо сильний пароль (менше 8 символів, не містить букв і цифр) (WeakPasswordException)
Основний сценарій
  1. Користувач натискає на кнопку "Зареєструватись"
  2. Користувач заповнює поля реєстрації (ім'я користувача, пошта, пароль)
  3. Користувач натискає на кнопку "Створити"
  4. Система перевіряє введені поля на валідність
  5. Система створює обліковий запис користувача
  6. Користувач автоматично входить в систему
ID AuthorizeUser
Назва Авторизувати користувача
Учасники Користувач, система
Передумови Система зареєструвала користувача
Результат Система авторизувала користувача
Виключні ситуації
  • Користувач ввів неправильний пароль (InvalidPasswordException)
  • Користувач ввів неправильне ім'я користувача (InvalidUsernameException)
  • Система заблокувала користувача (UserBannedException)
Основний сценарій
  1. Користувач вводить ім'я користувача і пароль.
  2. Система перевіряє введені дані (можливе InvalidPasswordException або InvalidUsernameException)
  3. Система перевіряє статус користувача (можливе UserBannedException)
  4. Користувач успішно входить у систему
ID EditUser
Назва Редагувати користувача
Учасники Користувач, адміністратор, система
Передумови Система авторизувала користувача або адміністратора
Результат Система змінила дані користувача
Виключні ситуації
  • Система не знайшла користувача (UserNotFoundException)
  • Користувач має недостатньо прав для редагування (InsufficientPermissionsException)
  • Користувач ввів дані у неправильному форматі (InvalidDataFormatException)
Основний сценарій
  1. Адміністратор або користувач відкриває профіль користувача.
  2. Користувач або адміністратор змінює потрібні поля.
  3. Система перевіряє права (можливе InsufficientPermissionsException).
  4. Система перевіряє введені дані на правильність (можливе InvalidDataFormatException).
  5. Система зберігає оновлені дані користувача.
ID DeleteUser
Назва Видалити користувача
Учасники Адміністратор, система
Передумови Система авторизувала адміністратора
Результат Система видаляє користувача
Виключні ситуації
  • Система не знайшла користувача (UserNotFoundException)
  • Користувач має недостатньо прав для видалення (InsufficientPermissionsException)
Основний сценарій
  1. Адміністратор вибирає користувача для видалення.
  2. Адміністратор натискає кнопку "Видалити користувача".
  3. Система перевіряє права адміністратора (можливе InsufficientPermissionsException).
  4. Система видаляє користувача (можливе UserNotFoundException).
ID CreateProject
Назва Створити проект
Учасники Користувач, система
Передумови Система авторизувала користувача
Результат Система створює проєкт та надає права керівника проєкту користувачу
Виключні ситуації
  • Користувач не ввів назву проєкту (NullProjectNameException)
  • Користувач ввів назву проєкту у неправильному форматі (InvalidProjectNameException)
Основний сценарій
  1. Користувач натискає кнопку "Створити проект".
  2. Користувач заповнює форму (назва проекту).
  3. Система перевіряє дані на валідність.
  4. Система створює новий проект.
  5. Система надає права керівника проєкту користувачу.
  6. Користувач отримує підтвердження про створення проекту.
ID EditProject
Назва Редагувати проект
Учасники Користувач (керівник проєкту), адміністратор, система
Передумови
  • Система авторизувала користувача
  • Користувач має права на редагування проекту
Результат Система змінює дані проєкту
Виключні ситуації
  • Система не знайшла проєкт (ProjectNotFoundException)
  • Користувач має недостатньо прав для редагування (AccessDeniedException)
Основний сценарій
  1. Користувач відкриває проект.
  2. Користувач натискає кнопку "Редагувати".
  3. Користувач вносить зміни.
  4. Система перевіряє права на редагування.
  5. Система зберігає зміни.
ID DeleteProject
Назва Видалити проект
Учасники Користувач (керівник проєкту), адміністратор, система
Передумови
  • Система авторизувала користувача
  • Користувач має права на видалення проєкту
Результат Система видаляє проєкт
Виключні ситуації
  • Система не знайшла проєкт (ProjectNotFoundException)
  • Користувач має недостатньо прав для видалення (AccessDeniedException)
Основний сценарій
  1. Користувач вибирає проект для видалення.
  2. Користувач натискає кнопку "Видалити".
  3. Система перевіряє права на видалення.
  4. Система видаляє проект.
ID AddMemberToProject
Назва Додати учасника до проекту
Учасники Користувач (керівник проєкту), адміністратор, система
Передумови
  • Система авторизувала користувача
  • Користувач має права на редагування проекту
Результат Система додає учасника до проєкту
Виключні ситуації
  • Система не знайшла користувача (UserNotFoundException)
  • Система не знайшла проєкт (ProjectNotFoundException)
  • Користувач має недостатньо прав для додавання учасника (AccessDeniedException)
Основний сценарій
  1. Користувач відкриває проект.
  2. Користувач натискає кнопку "Додати учасника".
  3. Користувач вводить дані нового учасника.
  4. Система перевіряє права на додавання учасника.
  5. Система додає учасника до проекту.
ID RemoveMemberFromProject
Назва Видалити учасника з проекту
Учасники Користувач (керівник проєкту), адміністратор, система
Передумови
  • Система авторизувала користувача
  • Користувач має права на додавання учасників до проєкту
Результат Система видаляє учасника з проєкту
Виключні ситуації
  • Система не знайшла учасника (MemberNotFoundException)
  • Система не знайшла проєкт (ProjectNotFoundException)
  • Користувач має недостатньо прав для видалення учасника (AccessDeniedException)
Основний сценарій
  1. Користувач відкриває проект.
  2. Користувач вибирає учасника для видалення.
  3. Користувач натискає кнопку "Видалити".
  4. Система перевіряє права на видалення.
  5. Система видаляє учасника з проекту.
ID CreateTask
Назва Створити задачу
Учасники Користувач (керівник проєкту), адміністратор, система
Передумови
  • Система авторизувала користувача
  • Користувач має права на редагування проєкту
Результат Система створює задачу
Виключні ситуації
  • Користувач не ввів назву задачі (NullTaskNameException)
  • Користувач ввів назву задачі у неправильному форматі (InvalidTaskNameException)
  • Користувач має недостатньо прав для створення задачі (AccessDeniedException)
Основний сценарій
  1. Користувач натискає кнопку "Створити задачу".
  2. Користувач заповнює форму (назва задачі, опис).
  3. Система перевіряє дані на валідність.
  4. Система створює нову задачу.
  5. Користувач отримує підтвердження про створення задачі.
ID EditTask
Назва Редагувати задачу
Учасники Користувач (керівник проєкту), адміністратор, система
Передумови
  • Система авторизувала користувача
  • Користувач має права на редагування задачі
Результат Система змінює дані задачі
Виключні ситуації
  • Система не знайшла задачу (TaskNotFoundException)
  • Користувач має недостатньо прав для редагування (AccessDeniedException)
Основний сценарій
  1. Користувач відкриває задачу.
  2. Користувач натискає кнопку "Редагувати".
  3. Користувач вносить зміни.
  4. Система перевіряє права на редагування.
  5. Система зберігає зміни.
ID DeleteTask
Назва Видалити задачу
Учасники Користувач (керівник проєкту), адміністратор, система
Передумови
  • Система авторизувала користувача
  • Користувач має права на видалення задачі
Результат Система видаляє задачу
Виключні ситуації
  • Система не знайшла задачу (TaskNotFoundException)
  • Користувач має недостатньо прав для видалення (AccessDeniedException)
Основний сценарій
  1. Користувач вибирає задачу для видалення.
  2. Користувач натискає кнопку "Видалити".
  3. Система перевіряє права на видалення.
  4. Система видаляє задачу.
ID SortTasks
Назва Відсортувати задачі
Учасники Користувач, система
Передумови
  • Система авторизувала користувача
  • Користувач є учасником проєкту
Результат Система відсортовує список задач
Виключні ситуації
  • Система не знайшла задачі (TasksNotFoundException)
  • Користувач не є учасником проєкту (UserNotProjectMemberException)
Основний сценарій
  1. Користувач вибирає список задач.
  2. Користувач натискає кнопку "Відсортувати".
  3. Користувач обирає спосіб сортування задач (за важливістю, за дедлайном).
  4. Система перевіряє користувача на причасність до проєкту.
  5. Система відсортовує список задач.
ID CreateBoard
Назва Створити дошку
Учасники Користувач (керівник проєкту), адміністратор, система
Передумови
  • Система авторизувала користувача
  • Користувач має права на створення дошки
Результат Система створює дошку
Виключні ситуації
  • Користувач не ввів назву дошки (NullInstanceException)
  • Користувач ввів недопустиму назву дошки (InvalidBoardNameException)
Основний сценарій
  1. Користувач натискає кнопку "Створити дошку".
  2. Користувач вводить назву дошки (можливе NullInstanceException).
  3. Система перевіряє введені дані (можливе InvalidBoardNameException).
  4. Система створює нову дошку.
  5. Користувач отримує доступ до дошки.
ID EditBoard
Назва Редагувати дошку
Учасники Користувач (керівник проєкту), адміністратор, система
Передумови
  • Система авторизувала користувача
  • Користувач має права на редагування дошки
Результат Система оновила дані дошки
Виключні ситуації
  • Система не знайшла дошку (BoardNotFoundException)
  • Користувач має недостатньо прав для редагування (AccessDeniedException)
Основний сценарій
  1. Користувач відкриває дошку.
  2. Користувач натискає кнопку "Редагувати".
  3. Користувач вносить зміни.
  4. Система перевіряє права на редагування (можливе AccessDeniedException).
  5. Система зберігає зміни.
ID DeleteBoard
Назва Видалити дошку (Delete Board)
Учасники Користувач (керівник проєкту), адміністратор, система
Передумови
  • Система авторизувала користувача
  • Користувач має права на видалення дошки
Результат Система видаляє дошку
Виключні ситуації
  • Система не знайшла дошку (BoardNotFoundException)
  • Користувач має недостатньо прав для видалення (AccessDeniedException)
Основний сценарій
  1. Користувач відкриває дошку.
  2. Користувач натискає кнопку "Видалити".
  3. Система перевіряє права на видалення (можливе AccessDeniedException).
  4. Система видаляє дошку.
  5. Користувач отримує підтвердження про успішне видалення.
ID BanUser
Назва Заборонити користувача
Учасники Адміністратор, користувач, система
Передумови
  • Система авторизувала адміністратора
  • Система не заборонила користувача
Результат Система забороняє доступ користувачу
Виключні ситуації
  • Система не знайшла користувача (UserNotFoundException)
  • Адміністратор має недостатньо прав для заборони (InsufficientPermissionsException)
  • Система вже заборонила користувача (UserBannedException)
Основний сценарій
  1. Адміністратор вибирає користувача зі списку.
  2. Адміністратор натискає кнопку "Заборонити користувача".
  3. Система перевіряє права адміністратора (можливе InsufficientPermissionsException).
  4. Система перевіряє користувача на заборону (можливе UserBannedException).
  5. Система забороняє користувача (можливе UserNotFoundException).
  6. Користувач отримує повідомлення про заборону.
ID UnbanUser
Назва Дозволити користувача
Учасники Адміністратор, користувач, система
Передумови
  • Система авторизувала користувача
  • Система заборонила доступ користувачу
Результат Система дозволяє доступ користувачу
Виключні ситуації
  • Система не знайшла користувача (UserNotFoundException)
  • Адміністратор має недостатньо прав для дозволення (InsufficientPermissionsException)
  • Система не заборонила доступ користувачу (UserNotBannedException)
Основний сценарій
  1. Адміністратор вибирає забороненого користувача зі списку.
  2. Адміністратор натискає кнопку "Дозволити користувача".
  3. Система перевіряє права адміністратора (можливе InsufficientPermissionsException).
  4. Система перевіряє користувача на заборону (можливе UserNotBannedException).
  5. Система дозволяє користувача.
  6. Користувач отримує повідомлення про дозвіл.
ID WriteToSupport
Назва Написати в службу підтримки
Учасники Користувач, система
Передумови Система авторизувала користувача
Результат Система відправила повідомлення до служби підтримки
Виключні ситуації Користувач не ввів текст повідомлення (NullInstanceException)
Основний сценарій
  1. Користувач відкриває форму для зв'язку зі службою підтримки.
  2. Користувач вводить текст повідомлення.
  3. Система перевіряє введені дані (можливе NullInstanceException).
  4. Система відправляє повідомлення до служби підтримки.
  5. Користувач отримує підтвердження про відправлення повідомлення.

# Короткий огляд продукту

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

# Основні категорії користувачів системи:

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

SigmaTasking встановлює чіткі межі для управління проєктами, що забезпечує структуровану та злагоджену роботу всіх учасників, сприяючи успішному виконанню проєктів.

# Функціональність

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

  • Створення, редагування та видалення проектів і завдань.
  • Управління ресурсами та учасниками проектів.
  • Відстеження виконання завдань та прогресу проекту.
  • Комунікація між учасниками через коментарі та сповіщення.

# Інтерфейс звичайного користувача

Звичайний користувач має можливість:

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

# Інтерфейс керівника проєкту

Керівник проекту може:

  • Створювати та редагувати проекти і завдання.
  • Призначати завдання учасникам.
  • Відстежувати прогрес виконання завдань та проекту в цілому.
  • Отримувати звіти про виконання завдань.

# Інтерфейс адміністратора

Адміністратор має можливість:

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

# Практичність

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

# Надійність

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

# Продуктивність

  • Висока швидкість передачі даних між компонентами системи.
  • Оптимізоване використання оперативної пам'яті та інтернет-ресурсів.
  • Використання хмарних технологій для збільшення продуктивності.
  • Підтримка багатопотокової обробки даних для підвищення ефективності.
  • Гнучка настройка ресурсів для кожного окремого проекту.
  • Підвищена пропускна здатність системи для обробки великих обсягів даних.

# Експлуатаційна придатність

  • Можливість розширення: Проект легко розширюється завдяки модульній архітектурі та використанню популярних бібліотек, що дозволяє додавати нові функції без значних змін в основному коді.
  • Управління проектом: Проект має чітко визначені цілі та етапи, що спрощує управління і контроль за виконанням завдань.
  • Забезпечення якості: Використовуються практики тестування, такі як юніт-тести та інтеграційні тести, для забезпечення високої якості коду.
  • Використання технологій: Використовуються сучасні технології та фреймворки, які є актуальними на ринку праці, що дозволяє студентам здобути практичні навички.
  • Документація: Документація проекту є повною і зрозумілою, що полегшує розуміння коду та швидкий старт для нових учасників команди.
  • Взаємодія з користувачами: Проект активно залучає користувачів до тестування та отримання зворотного зв’язку, що допомагає покращити продукт.
  • Адаптивність: Проект швидко адаптується до змін у вимогах чи умовах, завдяки використанню гнучких методологій.
Останнє оновлення: 10/12/2024, 11:54:04 PM

← Розроблення вимог до функціональности системи →