Аналіз предметної області 🔎
📖 Вступ
Цей документ містить основні визначення, які допоможуть детально проаналізувати предметну область проєкту. А також тут розглянуто стадії циклу та методики розробки програмного забезпечення. На основні зібраних даних створено порівняльну характеристику засобів вирішення завдання і таблицю, яка допомагає зорієнтуватися у функціональних якостях розгялнутих сервісів.
📑 Зміст:
- Основні визначення, які дозволять користувачу зрозуміти структуру систем управління проєктами;
- Підходи та способи вирішення завдання в області систем управління проєктами;
- Порівняльна характеристика наявних засобів вирішення завдання, яка містить детальний розбір переваг і недоліків сервісів відповідно до критеріїв FURPS;
- Висновки;
- Посилання.
📝 Основні визначення
Проєкт — сукупність моделей, проєктна конструкторська документація, яка містить проєктні рішення і дає повне уявлення про будову розроблюваного виробу, процесу або організації.
Система управління проектами — Сукупність процесів, інструментів, методів, методологій, ресурсів і процедур з управління проєктом. Система документується в плані управління проєктами, і її зміст може відрізнятися в залежності від галузі застосування, організаційного впливу, складності проєкту і доступності наявних систем.
Життєвий цикл проєкту — набір, зазвичай, послідовних фаз проєкту, кількість і склад яких визначається потребами управління проєктом організації або організаціями, які беруть участь в проєкті. Життєвий цикл можна документувати за допомогою методології.
Програмне забезпечення — сукупність програм, необхідних для виконання всіх основних і додаткових функцій системи (компонента), які зберігаються в пам'яті та/або в програмувальних електронних пристроях, що входять до складу цієї системи (компонента), а також програм на зовнішніх носіях і програмної документації.
Вимоги до програмного забезпечення — сукупність тверджень щодо атрибутів, властивостей, або якостей програмної системи, що підлягає реалізації.
Артефакт — окремий шмат інформації, що використовується чи з'являється в процесі розробки програмного забезпечення. Це може бути файл з кодом, модель, частина документації, чи повідомлення електронної пошти або навіть нотатка, приклеєна до монітора.
Agile Model — ітеративна модель розроблення, у якій програмне забезпечення створюють інкрементально від самого початку проєкту, на відміну від каскадних моделей, де код доставляють наприкінці робочого циклу.
Scrum — це специфічна структура в рамках ширших методів Agile. Це потужний інструмент для керування складними проєктами зі змінними вимогами, що пропонує численні переваги у співпраці, гнучкості та задоволеності клієнтів.
Spiral Model — це ризик-орієнтована модель процесу розробки програмного забезпечення. Спираючись на унікальні моделі ризиків конкретного проекту, спіральна модель спрямовує команду на прийняття елементів однієї або декількох моделей процесу, таких як інкрементне, водоспадне або еволюційне прототипування.
Incremental Model — модель життєвого циклу розробки, в якій проект поділено на серію прирощень, кожна з яких додає частину функціональності у загальних вимогах проекту.
Kanban — це гнучкий метод еволюційного управління змінами в проектах. Це означає, що існуючий процес вдосконалюється невеликими кроками (еволюційно). У підсумку, роблячи багато невеликих змін (а не одне велике), ми зменшуємо ризики для всього проекту в цілому.
Kanban-board — це інструмент управління проєктами, візуалізація завдань, які необхідно виконати різним працівникам/підрозділам вашої компанії.
💡 Підходи та способи вирішення завдання
Розробка програмного забезпечення зазвичай проходить через певні основні етапи. Хоча підходи можуть відрізнятися деталями, загальний принцип залишається незмінним. Основні стадії створення програмного продукту включають:
Аналіз вимог – дослідження ідеї та очікувань замовника, аналіз ринку, конкурентів та потенційної аудиторії. На цьому етапі формується розуміння ключових функцій майбутньої системи.
Проєктування – розробка архітектури, створення прототипів і планування завдань. Формується загальна логіка продукту, визначається його структура та дизайн.
Розробка – програмування та інтеграція всіх компонентів. Дизайнери працюють над інтерфейсом і UX, а розробники перетворюють концепцію в робочий програмний продукт.
Документування – створення технічної документації для розробників і супровідних матеріалів для користувачів, що описують функціонал і принципи роботи програми.
Тестування – перевірка працездатності та надійності системи, усунення можливих помилок і виявлення недоліків перед впровадженням.
Впровадження та підтримка – розгортання готового продукту, забезпечення його подальшої роботи та надання технічної підтримки для користувачів.
Ці етапи є фундаментом у процесі створення програмного забезпечення, забезпечуючи якісний результат та відповідність очікуванням користувачів.
🚰 Методологія Waterfall
Каскадний підхід, відомий як методологія ” Waterfall “, є структурованим методом управління проектами, де процес проходить через чітко визначені фази. Кожна з цих фаз має бути завершена до початку наступної. Класична модель Waterfall складається з наступних етапів: аналіз вимог, проектування системи, реалізація, тестування, розгортання та обслуговування. Така модель роботи дозволяє точно планувати і контролювати хід проекту.
Каскадна модель роботи базується на припущенні, що всі вимоги відомі на початку проекту і не зазнають суттєвих змін під час його виконання. Це дає можливість створювати детальний графік і точно управляти ресурсами. Методологія Waterfall особливо корисна в інженерних, будівельних і виробничих проектах, де зміни під час виконання можуть призвести до високих витрат.[1]
Схема Waterfall
⚡ Методологія Agile
Agile методологія розробки програмного забезпечення - це підхід до управління проектами, що базується на ітеративному та інкрементальному процесі розробки. Цей підхід став дуже популярним серед IT-компаній через свою гнучкість, можливість адаптації до змін і спрощення комунікації в команді. У цій статті ми розглянемо основні принципи та переваги Agile методології.
У межах Agile існує кілька методологій, які допомагають реалізувати ці принципи та цінності, такі як Scrum, Kanban, Extreme Programming (XP) та інші. Кожна з цих методологій має свої особливості та підходи до організації робочих процесів.[2]
Схема Agile
📊 Методологія Kanban
Канбан — це метод для розробки продуктів, який допомагає налагодити поточні процеси і перевантажити команду. Незавершені завдання не простоюють і потоком рухаються ланцюжком створення продукту або його підтримки. В основі kanban — Agile та гнучка розробка.
Kanban — це насамперед візуалізація. Для візуалізації використовують дошку та набір різнокольорових карток. Один колір — один виконавець чи процес. Усі учасники команди будь-коли можуть перевірити стан будь-якого завдання.[3]
Схема Kanban
🍃 Методологія Lean
LEAN – це система управління, філософія, інструментарій, що має на меті максимізувати цінність для споживача та мінімізувати витрати для компанії.[4.1]
Мислення за принципом Lean, або ж ощадливе мислення, фокусується вже не на оптимізації керуючої вертикалі — окремих технологій, активів і вертикальних відділів. Натомість ми вчимося оптимізувати потік продуктів і послуг крізь усі потоки створення цінності, що проходять по горизонталі крізь технології, активи й відділи напряму до клієнтів.[4.2]
Схема Lean
🏉 Методологія Scrum
Фреймворк Scrum забезпечує структуру методології. Вона складається з ролей, подій та артефактів, які забезпечують прозорість, перевірку та адаптацію протягом усього проекту. Основні функції включають Scrum Master, Product Owner і Team Development, а події на кшталт Daily Scrum, Sprint Planning, Sprint Review і Sprint Retrospective тримають проект у руслі.
Модель Scrum керується принципами прозорості, перевірки та адаптації. Прозорість гарантує, що всі зацікавлені сторони мають спільне розуміння розвитку проєкту. Перевірка передбачає регулярне оцінювання продукту та процесів для визначення областей, які слід покращити. Адаптація означає внесення змін на основі результатів перевірки для оптимізації результату проєкту.[5]
Схема Scrum
📈 Методологія Incremental
Інкрементний процес передбачає поетапну розробку програмного забезпечення, коли його компоненти постачаються частинами. Кожен інкремент містить завершений набір функцій, які повністю реалізовані та протестовані.
Наприклад, у разі створення інтернет-магазину на початковому етапі можна реалізувати оплату лише кредитними та дебетовими картками. У наступному оновленні можна додати підтримку оплати через електронні гаманці.[6]
Схема Incremental
🔄 Методологія Iterative
Ітеративний процес передбачає поступове вдосконалення системи через послідовні оновлення. Розробницька команда створює початкову версію продукту, заздалегідь знаючи, що деякі його частини будуть неповними. Далі ці частини покроково допрацьовуються, доки продукт не досягне задовільного рівня. Під час кожної ітерації враховуються відгуки користувачів, а програмне забезпечення покращується завдяки деталізації та розширенню функціональності.
Наприклад, розглянемо пошукову систему на сайті. У першій ітерації може бути реалізовано простий пошук. У наступному оновленні можна додати розширені критерії пошуку.[7]
Схема Iterative
🌀 Методологія Spiral
Спіральна модель є еволюцією традиційних підходів до розробки програмного забезпечення, таких як водоспадна модель. Вона поєднує ітеративність з послідовним аналізом ризиків на кожному етапі проекту. Спіральна модель ділить процес розробки на кілька циклів, кожен з яких складається з чотирьох фаз: визначення цілей, аналіз ризиків, розробка та планування наступного циклу.
Основна ідея спіральної моделі полягає в тому, що кожен новий цикл дозволяє команді вчитися на досвіді попереднього і приймати більш обґрунтовані рішення на наступному етапі. Це забезпечує високу ступінь адаптивності та дозволяє ефективно управляти ризиками проекту.[8]
Схема Spiral
🔺 Методологія V-Model
V-model - це життєвий цикл розроблення програмного забезпечення, який являє собою уточнення класичної водоспадної моделі.Перевагами цієї моделі є якість, відповідність стандартам і фіксовані терміни та бюджет на кожному етапі.
У V-моделі розробка відбувається у формі літери "V", що зустрічається - розробка і тестування продукту відбуваються паралельно, а кожен етап тестування спрямований на перевірку відповідного етапу розробки.[9]
Схема V-Model
🔁 Методологія DevOps
DevOps — це методологія або культурна філософія, набір практик, що поєднує розробку ПЗ (Dev) та ІТ-операції (Ops). Основна мета DevOps — скоротити цикл розробки ПЗ і подбати про безперервне доставлення програмних компонентів на кінцеве програмне середовище.[10.1]
Завдяки цьому підходу суттєво збільшується швидкість розробки, скорочуються проміжки між релізами, підвищується якість, надійність і безпека продуктів, а також забезпечується високе масштабування та організована робота команди.[10.2]
Схема DevOps
🚀 Методологія RAD
Rapid Application Development (RAD) - це гнучка методологія розробки програмного забезпечення, яка акцентує увагу на швидкому створенні прототипів та ітеративному удосконаленні продукту. RAD розроблена для скорочення часу розробки та спрощення процесу впровадження змін, не жертвуючи при цьому якістю кінцевого продукту.
Методологія RAD складається з чотирьох ключових компонентів: вимоги, прототипування, швидка ітерація та співпраця. Команди, які використовують RAD, активно взаємодіють з замовниками та користувачами, щоб точно визначити вимоги, і на їх основі створюють робочі прототипи. Це дозволяє швидко вносити зміни та адаптуватися до нових потреб, роблячи процес розробки більш гнучким та відгуковим.[11]
Схема RAD
🐳 Методологія MVC
MVC (Model-View-Controller) — це архітектурний шаблон для розробки програмного забезпечення, який допомагає розділити програму на три основні частини.
Модель відповідає за обробку даних та бізнес-логіку програми. Вона зберігає інформацію і визначає, як ця інформація обробляється і змінюється. Вигляд відповідає за відображення даних користувачу. Він представляє інформацію з Моделі у зручному для користувача вигляді.Контролер взаємодіє з користувачем і відправляє команди до Моделі та Вигляду. Він контролює потік інформації між Моделлю і Виглядом та реагує на дії користувача.[12]
Схема MVC
🔄 Методологія CI/CD
Безперервна інтеграція (Continuous Integration, CI) і безперервне постачання (Continuous Delivery, CD) є культурою, набором принципів і практик, які дозволяють розробникам частіше і надійніше розгортати зміни програмного забезпечення. Обидва терміни дуже тісно пов’язані з професією DevOps і є основними термінами їх еволюції.
Основними інструментами для реалізації CI/CD можуть бути: GitLab, Docker, Jenkins, Maven, Ansible, Kubernetes і т.д. Безперечно такі методи забезпечуть оперативність виведення нового функціоналу продукту. Як правило, це лічені дні чи тижні. У той же час, при класичному підході до розробки клієнтського ПЗ на це може бути витрачено рік і навіть більше.[13]
Схема CI/CD
⚖️ Порівняльна характеристика наявних засобів вирішення завдання
🌍 Огляд сервісів
GitHub Projects — це платформа для спільної роботи над різними проєктами, особливо при розробці програмного забезпечення. В основі GitHub лежить система, яка називається Git, що дозволяє відстежувати зміни у файлах і координувати роботу багатьох людей.
Asana — це потужне та багатофункціональне програмне забезпечення для управління проектами, організації робочих процесів, відстеження прогресу команди та досягнення кращих результатів
Trello — це онлайн-платформа для управління проєктами та завданнями. Trello підходить для контролю роботи в невеликих компаніях та стартапах. Ця система організована за принципом канбан — популярною методикою управління проєктами.
Miro — платформа для спільної віддаленої роботи за допомогою онлайн-дошки. Дошка підходить для складання проектів, креативу, дизайн-концепцій, брейнстормінгу та освітніх цілей. Спільна робота Miro здійснюється за допомогою текстового, голосового або відеочата, а також спільного наповнення та перегляду дошки в реальному часі.
Jira — це засіб адміністрування проектів agile-команд, розроблений таким чином, щоб розробники могли планувати, виправляти та випускати якісні продукти.
Notion — це універсальний додаток для організації, який поєднує таблиці, списки, бази даних та дошки в одному просторі, що дозволяє легко керувати завданнями та проектами на iPhone і Mac. З його допомогою можна зберігати текстові документи, відео та зображення, а також синхронізувати дані між пристроями для ефективної роботи і планування.
Basecamp — інструмент для управління проєктами, який розповсюджується по публічно-хмарній моделі. Використовується для командної роботи над проєктами та задачами. Все спілкування відбувається у вигляді блогу, завдання ставляться як to-do списки, що зручно тільки в разі якихось загальних описів для розвитку проєкту. Також немає можливості складати звіти.
📊 Порівняльна таблиця
| Сервіс | Основні можливості | Тип управління | Інтеграції | Особливості | Недоліки |
|---|---|---|---|---|---|
| GitHub Projects | Управління задачами, Kanban-дошка, відстеження змін у коді | Kanban, Agile | GitHub, CI/CD, Slack | Глибока інтеграція з GitHub | Не підходить для нетехнічних команд |
| Asana | Управління задачами, проєктами, таймлайн, пріоритети | Agile, Scrum | Slack, Google Drive, Zoom | Гнучкість у керуванні задачами | Висока вартість преміум-функцій |
| Trello | Kanban-дошка, чек-листи, теги, автоматизація | Kanban | Google Drive, Slack, Jira | Простий інтерфейс, гнучкість | Обмежений функціонал у безкоштовній версії |
| Miro | Візуальні дошки, брейнштормінг, діаграми | Гнучке управління | Slack, Zoom, Notion | Інтерактивна колаборація | Важко керувати великими проєктами |
| Jira | Відстеження задач, Agile-борди, спринти | Scrum, Kanban | Bitbucket, Confluence, Slack | Підходить для складних проєктів | Висока складність для початківців |
| Notion | Нотатки, бази даних, Kanban-дошки, управління знаннями | Гнучке управління | Slack, Google Drive, API | Універсальний робочий простір | Не підходить для складних проєктів |
| Basecamp | Управління проєктами, повідомлення, файли | Гнучке управління | Email, календарі | Простий у використанні | Обмежена гнучкість у завданнях |
🎯 Висновки
Проаналізувавши деякі застосунки й веб-сервіси, які пропонують засоби для управління проєктами, можемо підсумувати, що кожна система має переваги й недоліки, відштовхуючись від яких користувач обирає ідеальний варіант для себе. Жодна з розглянутих платформ не пропонує оффлайн-доступ, що значно знижує рівень комфорту використання. Також серед мінусів занадто великий вибір функцій, що часто плутає користувача і ускладнює оптимізацію роботи.
Зважаючи на зібрану інформацію, можемо зробити висновок: важливим є створення такого сервісу, який запропонує необхідіний користувачеві функціонал, при цьому забезпечить ефективне управління робочими задачами і збереже баланс між широтою інструментів і інтуїтивно зрозумілим інтерфейсом.