# Аналіз предметної області
# Вступ
У цьому документі представлено аналіз предметної області продукту, що містить:
- Основні визначення та скорочення
- Підходи, моделі та способи вирішення завдання
- Порівняльна характеристика переваг та недоліків нашого продукту та існуючих систем управління (GitHub Projects, Notion, Trello, Jira, YouTrack, Nifty)
- Висновки
- Посилання на використану інформацію
# Основні визначення
Проект - обмежена в часі, ресурсах та вимогах якості унікальна сукупність процесів, направлена на досягнення унікальних цілей та завдань для створення нової цінності (продукту або послуги). [1]
Система керування проєктами — комплексне програмну забезпечення, що охоплює програми для планування завдань, складання розпису, контролю ціни і керування бюджетом, розподілу ресурсів, спільної роботи, спілкування, швидкого керування , документування та адміністрування системи, яке використовуються спільно для керування великими проєктами. [2]
Управління проектами - планування, організація та управління ресурсами з метою успішного досягнення цілей та завершення завдань проєкту. Іноді ототожнюється з управлінням програмами, але програма — це фактично вищий рівень: група пов'язаних та взаємозалежних проєктів. [3]
Життевий цикл проекту - сукупність окремих етапів робіт, що проводяться у заданому порядку протягом періоду часу, який починається з вирішення питання про розроблення програмного забезпечення і закінчується припиненням використання програмного забезпечення. [4]
UML - уніфікована мова моделювання, використовується у парадигмі об'єктно-орієнтованого програмування. Є невід'ємною частиною уніфікованого процесу розробки програмного забезпечення. UML є мовою широкого профілю, це відкритий стандарт, що використовує графічні позначення для створення абстрактної моделі системи, яка називається UML-моделлю. UML був створений для визначення, візуалізації, проєктування й документування в основному програмних систем. UML не є мовою програмування, але в засобах виконання UML-моделей як інтерпретованого коду можлива кодогенерація. [5]
Артефакт - окремий шмат інформації, що використовується чи з'являється в процесі розробки програмного забезпечення. Це може бути файл з кодом, модель, частина документації, чи повідомлення електронної пошти або навіть нотатка, приклеєна до монітора. [8]
Методологія розробки програмного забезпечення — сукупність методів, застосовуваних на різних стадіях життєвого циклу розробки програмного забезпечення, що мають спільний філософський підхід та, відповідно до цього підходу, дозволяють забезпечити найкращу ефективність процесів розробки. [6]
Agile Modeling - yабір концепцій, принципів і методів (практик), який дозволяє швидко і легко виконувати проектування та документацію для проектів з розробки програмного забезпечення. Не включає в себе докладні інструкції з проектування, містить описи, як побудувати діаграми UML. Основна мета – ефективне моделювання та документація, але не включає в себе програмування і тестування, управління проектом, розгортання та обслуговування системи. [7]
DSDM - Грунтується на концепції швидкої розробки додатків (Rapid Application Development, RAD). Це ітеративний і інкрементний підхід, який підкреслює постійну участь користувача/споживача в проекті. [7]
Scrum - Встановлює правила для процесу управління розробки програмного забезпечення і дозволяє використовувати існуючу практику кодування, регулювати вимоги або приймати тактичні зміни. Використовуючи цю методику можливо виявити і усунути відхилення від бажаного результату на більш ранніх стадіях розробки програмного забезпечення. [7]
Kanban - реалізує принцип «точно в строк» і урівноважує робоче навантаження між усіма членами команди. За допомогою цього методу весь процес розробки зрозумілий для всіх членів команди. Канбан є візуальною моделлю розвитку, яка показує те, що потрібно виробляти, коли і скільки. [7]
Scrumban - структура управління і гібрид Scrum і Kanban. Розробники працюють з історіями користувачів і намагаються зберігати ітерації якомога коротшими. Тут не існує конкретних ролей, як наприклад в Scum. Кожен член команди зберігає свою існуючу роль в проекті. [7]
# Підходи та способи вирішення завдання
Вибір моделі розроблення програмного забезпечення допомагає:
- Зрозуміти, як створити корисний продукт для бізнесу.
- Надати чіткий план дій для команди розробників.
- Створити послідовність процесів і визначити вимоги до продукту.
- Розподілити завдання в команді.
- Мінімізувати помилки та правки під час розробки.
# Каскадна модель
Модель в якій кожен етап розробки, що відповідає стадії життєвого циклу ПЗ, продовжує попередній. [9]
# Плюси каскадної моделі:
- Повне документування кожного етапу;
- Чітке планування термінів і витрат;
- Прозорість процесів для замовника;
# Мінуси каскаднох моделі:
- Необхідність затвердження повного обсягу вимог до системи ще на першому етапі;
- У разі необхідності внесення змін до вимог пізніше – повернення до першої стадії та переробка заново всієї виконаної роботи;
- Збільшення витрат коштів та часу в разі потреби змінити вимоги.
- Незважаючи на те, що каскадна модель все ще використовується, вона вже втратила колишні позиції. Сьогодні їй на зміну приходять більш просунуті моделі та методології розробки програмного забезпечення.
# Коли варто використовувати каскадну модель:
- У проектах з чітко визначеними вимогами, для яких не передбачається зміна цих вимог в процесі розробки;
- Для проектів, які мігрують з однієї платформи на іншу. Тобто, вимоги залишаються ті ж, міняється лише системне оточення та/або мова програмування;
- Коли від компанії-розробника не потрібно проводити тестування – наприклад, його забезпеченням займеться сам замовник або стороння фірма.
# Ітераційна модель
Передбачає розбиття проекту на частини (етапи, ітерації) і проходження етапів життєвого циклу на кожному з них. Кожен етап є закінченим сам по собі, сукупність етапів формує кінцевий результат. [10]
# Плюси:
- Можливість виправлення помилок на різних етапах розробки
- Можливість завершення розробки в кінці будь-якої ітерації
# Мінуси:
- Велика складність управління ітераціями.
# Спіральна модель проектування
Спіральна модель - це ризик-орієнтована модель процесу розробки програмного забезпечення. Спираючись на унікальні моделі ризиків конкретного проекту, спіральна модель спрямовує команду на прийняття елементів однієї або декількох моделей процесу, таких як інкрементне, водоспадне або еволюційне прототипування. [11]
# Плюси:
- покращений аналіз ризиків;
- хороша документація процесу розробки;
- гнучкість – можливість внесення змін і додавання нової функціональності навіть на відносно пізніх етапах;
- раннє створення робочих прототипів.
# Мінуси:
- може бути досить дорога у використанні;
- управління ризиками вимагає залучення висококласних фахівців;
- успіх процесу у великій мірі залежить від стадії аналізу ризиків;
- не підходить для невеликих проектів.
# Agile
Методологія гнучкої розробки, яка першочергово сьогодні популярна в ІТ і дозволяє клієнтам швидше отримувати якісне програмне забезпечення.
# Плюси:
- Здатність швидко адаптуватися до змін у вимогах та середовищі.
- Швидке виправлення помилок та швидший виход на ринок.
# Мінуси:
- Складне управління
- Нестіка до змін у проекті
- Вимагає витрачати багато часу
# Порівняльна характеристика існуючих засобів вирішення завдання
GitHub Projects - це інструмент управління проектами, спеціально розроблений для співпраці в середовищі GitHub. Він представляє собою адаптивну електронну таблицю, яка інтегрується з завданнями (issues) та запитами на злиття (pull requests) на GitHub. Основна мета цього інструмента - оптимізувати процес планування та моніторингу роботи. Використовувачі мають можливість створювати, налаштовувати та візуалізувати завдання та робочі процеси за допомогою фільтрів, сортування, групування та додавання метаданих. Це дозволяє командам ефективно пристосовувати свої робочі процеси до потреб проекту, незалежно від вибраної методології.
Trello - це інструмент управління проектами, який базується на методології Kanban. Він надає командам засоби для візуального планування, координації та моніторингу робочих процесів за допомогою дошок, списків і карток. Кожна картка відображає окреме завдання чи ідею і може переміщатися між колонками відповідно до її статусу в проекті. Trello надає можливості додавання файлів, створення контрольних списків, автоматизації та призначення відповідальних осіб, забезпечуючи ефективну та організовану співпрацю команди.
Nifty - це універсальний інструмент для керування проектами та спільної роботи. Він включає в себе різноманітні функції для команд будь-якого розміру, які працюють над складними завданнями. Nifty дозволяє співпрацювати в реальному часі над документами, обмінюватися файлами, відстежувати завдання та проекти, а також автоматизувати робочі процеси. Використовуючи інтерфейси, такі як канбан-дошки, списки завдань та вбудований календар, користувачі можуть налаштовувати своє робоче середовище для максимальної продуктивності. Із мобільними додатками для Android та iOS, Nifty забезпечує гнучкість для роботи в русі.
Notion - це багатофункціональний інструмент для організації проектів та спільної роботи. Він дозволяє створювати структуровані сторінки, включаючи тексти, таблиці, зображення, задачі та багато іншого. Notion відомий своєю гнучкістю та можливістю адаптуватися до різних потреб команд.
YouTrack - це інструмент від JetBrains для управління проектами та задачами. Він надає широкий спектр функцій для відстеження завдань, управління проектами та аналізу результатів.
Jira - це інструмент для управління проектами, який розроблений компанією Atlassian. Він дозволяє створювати та відстежувати завдання, планувати проекти та співпрацювати в команді для досягнення успішних результатів.
Порівняльна таблиця
| Вимоги | Критерії | Flowly (Наш продукт) | GitHub Projects | Trello | Nifty | Notion | YouTrack | Jira |
|---|---|---|---|---|---|---|---|---|
| Функціональніcть | ||||||||
| Free to use | ✅ | ✅ | ⚠️ | ✅ | ⚠️ | 🚫 | ⚠️ | |
| Кросплатформеність | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | |
| Наявність API | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | |
| Підтримка артекфактів | ✅ | ✅ | 🚫 | 🚫 | ✅ | ✅ | ✅ | |
| Офлайн доступ | ⚠️ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | |
| Система сповіщень | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | |
| Інтеграція з GitHub | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | |
| Інтеграція з 3rd Party | ✅ | 🚫 | 🚫 | 🚫 | 🚫 | 🚫 | 🚫 | |
| Штучний Інтелект | ✅ | 🚫 | 🚫 | 🚫 | 🚫 | 🚫 | 🚫 | |
| Гарячі клавіші | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | |
| Зручність | ||||||||
| User-friendly interface | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | |
| Багатомовність | ⚠️ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | |
| Інтеграція з Github | ✅ | 🚫 | ✅ | 🚫 | ✅ | ✅ | ✅ | |
| Ведення паралельно кількох проєктів | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | |
| Доступ до дошки без реєстрації | 🚫 | ✅ | 🚫 | ✅ | ✅ | ✅ | ✅ | |
| Надійність | ||||||||
| Резервне копіювання | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | |
| Швидкість виправлення багів | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | |
| Приватні проєкти | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | |
| Історія зміни проєктів | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | |
| Багаторівнева автенфікація | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | |
| Продуктивность | ||||||||
| Швидкість інтерфейсу | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | |
| Швидкість виконання запитів | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | |
| Синхронізація | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | |
| Стійкість до збоїв | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | |
| Підтримка | ||||||||
| Онлайн підтримка | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | |
| FAQ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | |
| Частота оновлень | ✅ | ⚠️ | ⚠️ | ⚠️ | ⚠️ | ✅ | ✅ |
# Висновки
На ринку інструментів для управління проектами існують недоліки, такі як відсутність підтримки важливих функцій, і деякі функції доступні лише у платних версіях. Розробка нового інструмента, який враховує ці недоліки і пропонує унікальні можливості такі як інтеграція з 3rd party та наявність штучного інтелекту, може стати важливим рішенням. Він може привернути користувачів і вирішити їх потреби краще, ніж існуючі інструменти.
# Посилання
[1] https://uk.wikipedia.org/project (opens new window)
[2] https://uk.wikipedia.org/projcontrolsys (opens new window)
[3] https://uk.wikipedia.org/projcontrol (opens new window)
[4] https://uk.wikipedia.org/projlifecycle (opens new window)
[5] https://uk.wikipedia.org/wiki/uml (opens new window)
[6] https://uk.wikipedia.org/wiki/softdevmethods (opens new window)
[7] https://agile.yakubovsky.com/softdevmethods (opens new window)
[8] https://uk.wikipedia.org/wiki/uml-artefact (opens new window)
[9] https://qalight.ua/baza-znaniy/kaskadna-model-waterfall-model (opens new window)
[10] https://evergreens.com.ua/ua/articles/software-development-metodologies (opens new window)
[11] https://www.maxzosim.com/boehms-spiral-model (opens new window)