# Аналіз предметної області

# Вступ

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

Зміст документу:

Основні визначення
Підходи та способи вирішення завдання
Порівняльна характеристика існуючих засобів вирішення завдання
Висновки
Посилання

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

Проєкт (opens new window) - це унікальна сукупність вхідних даних (цілей, проблем), процесів і ресурсів, направлених на те, щоб у встановлений проміжок часу досягти очікуваних результатів, наприклад, розробити новий застосунок.
Система управління проєктами (opens new window)> - сукупність процесів, інструментів, методів, методологій, ресурсів і процедур з управління проєктом.
Структура проєкту (opens new window) - система, яка об’єднує елементи, необхідні для управління проєктом.
Процес (opens new window) - один з інструментів управління проєктом. Коли кажуть, що процеси вибудовані, це означає, що є розуміння того, хто і за що відповідає, на якому етапі знаходиться та чи інша діяльність.
Артефакт (opens new window) - окремий шмат інформації, що використовується чи з'являється в процесі розробки програмного забезпечення. Це може бути файл з кодом, модель, частина документації, чи повідомлення електронної пошти або навіть нотатка, приклеєна до монітора.
Учасники проєкту – фізичні та \ або юридичні особи, які безпосередньо залучені до реалізації проєкту, або чиї інтереси можуть бути порушені при здійсненні проєкту.
Scrum (opens new window) — це чітка схема для управління проєктами, легкий, ітеративний та поступовий підхід до розробки продукту.
Життєвий цикл (opens new window) - це умовна схема, що включає в себе окремі етапи, які є стадіями розвитку процесу створення ПЗ. При цьому, на кожному етапі виконуються різні дії.
Методологія розробки програмного забезпечення - сукупність методів, застосовуваних на різних стадіях життєвого циклу розробки програмного забезпечення, що мають спільний філософський підхід та, відповідно до цього підходу, дозволяють забезпечити найкращу ефективність процесів розробки.
Agile Model (opens new window) - ітеративна модель розроблення, у якій програмне забезпечення створюють інкрементально від самого початку проєкту, на відміну від каскадних моделей, де код доставляють наприкінці робочого циклу.
Waterfall model (opens new window) - послідовний метод розробки програмного забезпечення, названий так через діаграму, схожу на водоспад.
V-подібна модель (opens new window) - є моделлю розробки інформаційних систем (ІС), спрямованої на спрощення розуміння складнощів, пов'язаних з розробкою систем.
Інкрементна модель (opens new window) - програмне забезпечення розробляється з лінійною послідовністю стадій, але в кілька інкрементів (версій).
Спіральна модель (opens new window) - генератор моделі процесу керування ризиками для проєктів програмного забезпечення.
Гнучка модель (opens new window) - генератор моделі процесу керування ризиками для проєктів програмного забезпечення.
Kanban (opens new window) - це гнучкий метод еволюційного управління змінами в проєктах. Це означає, що існуючий процес вдосконалюється невеликими кроками (еволюційно). У підсумку, роблячи багато невеликих змін (а не одне велике), ми зменшуємо ризики для всього проєкту в цілому.
CRM (opens new window) - «управління взаємовідносинами з клієнтами» і відноситься до всіх стратегій, методів, інструментів і технологій, які використовує бізнес для розвитку, утримання і залучення клієнтів.

# Підходи та способи вирішення завдання

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

Планування.

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

Аналіз та збирання вимог.

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

Проєктування та дизайн.

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

Етап розробки.

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

Завдання розділені між членами команди відповідно до їхньої галузі спеціалізації. Розробники відповідають за створення інтерфейсу та його зв'язок із сервером. Адміністратори бази даних додають необхідні дані до бази. Front-end розробники створюють чуйний інтерфейс майбутнього веб-додатку.

Результатом цього етапу є програмний продукт, що працює.

Тестування.

Створення робочого продукту - це ще кінець життєвого циклу розробки. Після розробки триває етап тестування. На цьому етапі команда порівнює задуманий додаток на етапі аналізу та збору вимог із тим, який створений після етапу розробки. Відповідає на запитання:

Чи всі ці функції та інтеграції працюють правильно?

Чи правильно відпрацьовують усі кнопки?

Чи досягли того кінцевого результату, який було прописано у вимогах?

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

Після виправлення та налагодження продукту, він готовий до наступного етапу.

Вихід на ринок (продакшн).

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

Технічна підтримка.

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

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

# Waterfall model

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

# V-подібна модель

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

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

# Інкрементна модель

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

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

# Спіральна модель

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

# Гнучка модель

Являє собою сукупність різних підходів до розробки ПЗ. Включає серії підходів до розробки програмного забезпечення, орієнтованого на використання ітеративної розробки (в Scrum ітерації називаються спринтами), динамічне формування вимог і забезпечення їхньої реалізації в результаті постійної взаємодії всередині самоорганізованих робочих груп, що складаються з фахівців різного профілю. Окрема ітерація являє собою мініатюрний програмний проєкт. Однією з основних ідей Agile є взаємодія всередині команди і з замовником напряму.

# Скрам

Скрам - це гнучка модель розробки ПЗ, в якій робиться акцент на якісному контролі процесу розробки. Ролі в методології (Scrum Master, Product Owner, Team) дозволяють чітко розподілити обов'язки в процесі розробки. За успіх Scrum в проєкті відповідає Scrum Master і є сполучною ланкою між менеджментом і командою. За розробку продукту відповідає Product Owner, який також ставить завдання і приймає остаточні рішення для команди.

# Порівняльна характеристика існуючих засобів вирішення завдання

Є багато варіантів систем управління проєктами. Отже, розглянемо найпопулярніші та найцікавіші:

Jira (opens new window) - забезпечує надійну підтримку методологій гнучкого управління проєктами, таких як Scrum і Kanban. Він пропонує широкий спектр адаптивних дощок, у тому числі дошки Scrum для планування спринту та дошки Kanban для безперервного потоку, що дозволяє командам візуалізувати свою роботу та ефективно керувати нею. Гнучкі функції Jira включають відображення історій користувача, планування спринтів, керування невиконаними документами та діаграми згоряння, що дозволяє командам забезпечувати ефективність ітеративно та адаптуватися до мінливих вимог.
Worksection (opens new window) - це сервіс управління задачами з простим інтерфейсом і канбан-дошками. Worksection розроблений для того, щоб ви могли впровадити його в компанію будь-якого масштабу і налаштувати під конкретні задачі. Маркетингові агентства, відеопродакшени, державні структури, event-агентства використовують цю систему для досягнення самих різних цілей.
Asana (opens new window) - програмне забезпечення для веб і мобільних пристроїв, призначене для спільної роботи над проєктами без електронної пошти. Було створене співзасновником Facebook Дастіном Московіцем і колишнім інженером Джастіном Розенштейном, які працювали над підвищенням продуктивності співробітників на Facebook.
Trello (opens new window) - це візуальний інструмент, що дає змогу команді керувати різноманітними проєктами й робочими процесами та відстежувати виконання завдань. Додавайте файли, контрольні списки або правила для автоматизації: налаштування Trello допомагають оптимізувати командну роботу.
Clickup (opens new window) - це хмарний сервіс для командної роботи над проєктами і завданнями. Він дозволяє створювати як окремі таски, так і об'ємні to-do списки, а також гнучко управляти і налаштовувати проекти за допомогою ряду інструментів кастомізації. Тут же можна створювати документи, вікі-сторінки і бази знань для проєктів, а потім ділитися ними з іншими учасниками команди або ким завгодно в інтернеті. Ще однією важливою функцією ClickUp є створення таблиць, робити це можна як з нуля, так і імпортувавши їх з інших сервісів: Google Sheets або Airtable.
Basecamp (opens new window) - це одна з найпопулярніших CRM (система управління взаємовідносинами з клієнтами). Вона дозволяє спілкуватися з командою, ділитися документами, створювати to-do списки, призначати відповідальних, додавати коментарі та багато іншого.

Основні категорії:

Functionality (функциональні вимоги)
Usability (вимоги до зручності роботи)
Reliability (вимоги до надійності)
Performance (вимоги до продуктивності)
Supportability (вимоги до підтримки)

Категорія	Критерії	Наша система	Jira	Worksection	Asana	Trello	Clickup	Basecamp
Functionality
	Планування проєкту	🟢	🟢	🟢	🟡	🟡	🟢	🟡
	Створення завдань та дедлайнів	🟢	🟢	🟢	🟢	🟡	🟢	🟡
	Чати та комунікація всередині системи	🟢	🟡	🟢	🟡	🟡	🟢	🟢
	Управління ресурсами	🟢	🟡	🟢	🟡	🟡	🟢	🟡
	Моніторинг прогресу	🟢	🟢	🟢	🟢	🟡	🟢	🟡
	Назначання учасників проєкту	🟢	🟢	🟢	🟢	🟡	🟢	🟡
Usability
	Графічний інтерфейс	🟢	🟢	🟢	🟢	🟢	🟢	🟢
	Адаптивність під мобільні пристрої	🟡	🟢	🟢	🟢	🟢	🟢	🟡
	Використання різних мов	🟡	🟡	🟢	🟢	🔴	🟢	🔴
Reliability
	Захист даних	🟢	🟢	🟡	🟢	🟢	🟢	🟢
	Багаторівнева автентифікація	🟢	🟢	🟡	🟡	🔴	🟢	🟡
	Поділ користувачів за ролями	🟢	🟡	🟡	🟡	🔴	🟡	🔴
Performance
	Швидкість внесення змін	🟢	🟢	🟢	🟢	🟢	🟢	🟢
	Стійкість до збоїв	🟢	🟢	🟢	🟢	🟢	🟢	🟢
Supportability
	Тех. підтримка	🟢	🟢	🟢	🟢	🟡	🟢	🟡
	FAQ і документація	🟢	🟡	🟡	🟢	🔴	🟢	🟢

🟢 - повністю підтримують

🟡 - можливо частково підтримують

🔴 - не підтримують

# Висновки

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

# Посилання

← Вступ Запити зацікавлених осіб →