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

# Вступ

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

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

Методологія управління проєктами (opens new window) – це практика або техніка, яка допоможе вам успішно керувати проєктом і виконувати його. Вона описує, як взятися за проєкт і як виконати покрокові інструкції щодо його завершення. Крім того, вона обмежує життєвий цикл проєкту правильно структурованими етапами.

Моделі розробки програмного забезпечення (opens new window) — це формальні методи організації та управління процесом створення програмного забезпечення. Велика їх частина - це і є методології управління проєктами.

Життєвий цикл розробки програмного забезпечення (opens new window) (SDLC - Software Development Life Cycle) — це послідовність кроків розробки, необхідних для створення проекту, від його первинної ідеї до виходу продукту на ринок і подальшої його підтримки.

Lean (opens new window) — з англ. "ощадливий", це методологія управління проектами, зосереджена на ефективності, тобто на досягненні більшого з меншими витратами.

MVP, мінімально життєздатний продукт (opens new window) (англ. Minimum viable product — MVP) — продукт з мінімальним функціоналом, який можна дати користувачам для використання.

Scrum (opens new window) (англ. "штовханина; сутичка") — підхід управління проєктами для гнучкої розробки програмного забезпечення, де робиться акцент на якісному контролі процесу розробки.Підхід вперше описали Гіротака Такеучі та Ікуджіро Нонака в статті The New New Product Development Game (Гарвардський Діловий Огляд, січ-лют 1986). Вони відзначили, що проєкти, над якими працюють невеликі, крос-функціональні команди, зазвичай систематично продукують кращі результати, і пояснили це, як «підхід регбі». У регбі scrum - сутичка, в якій м'яч вкидається між двома групами із восьми гравців, і ті намагаються вибороти його, відштовхуючи групу супротивника.

Спринт (opens new window) (англ. sprint - ривок; кидок; біг на коротку дистанцію) — у scrum-методології 15-30 денний період (тривалість визначається командою), протягом якого працівники створюють функціональний ріст програмного забезпечення.

Product backlog (opens new window) — це документ, який має список вимог до функціональності, які упорядковані згідно зі ступенем важливості. Product backlog представляє список того, що повинно бути реалізовано.

Предметна сфера (opens new window) — це сукупність продуктів і послуг, виробництво яких повинно бути забезпечене в рамках здійснюваного проекту.

Тайм-менеджмент, керування часом (opens new window) (англ. Time-management) — сукупність методик оптимальної організації часу для виконання поточних задач, проектів та календарних подій. Типовими підходами в керуванні часом є постановка пріоритетів, розбиття великих завдань та проектів на окремі дії та делегування іншим людям.

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

RUP (opens new window) (англ. Rational Unified Process - RUP) — процес розробки програмного забезпечення створений Rational Software - підрозділом американської корпорації-виробника комп’ютерів - IBM.

Інкремент (opens new window) (лат. Incrementum - зростання) — операція збільшення значення змінної, найчастіше на 1.

Ітерація (opens new window) (лат. Iteratio - повторювання) — повторне застосування математичної операції для вирішення задачі; повторний виклик функції в програмному коді тощо.

Система керування версіями (opens new window) — це система, що записує зміни у файл або набір файлів протягом деякого часу, щоб користувач мав змогу повертатися до певних раніших версій свого проєкту.

Репозиторій (opens new window) (англ. repository - сховище) — спеціальний сервер, на якому зберігається програмне забезпечення і документи разом з історією їх зміни та іншою службовою інформацією. Найчастіше дані в репозиторії зберігаються у вигляді файлів, доступних для завантаження і подальшого розповсюдження по мережі.

Гнучка́ розро́бка програ́много забезпе́чення (opens new window) (англ. Agile software development, agile-методи) — клас методологій розробки програмного забезпечення, що базується на ітеративній розробці, в якій вимоги та розв'язки еволюціонують через співпрацю між багатофункціональними командами здатними до самоорганізації; засіб для підвищення продуктивності розробників програмного забезпечення.

TLS (opens new window) (англ. Transport Layer Security — захист на транспортному рівні), як і його попередник SSL — криптографічний протокол, що надає можливості безпечної передачі даних в інтернеті для навігації, отримання пошти, спілкування, обміну файлами, тощо.

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

API (opens new window) (англ. Application Programming Interface - прикладний програмний інтерфейс) — набір визначень підпрограм, протоколів взаємодії та засобів для створення програмного забезпечення; набір чітко визначених методів для взаємодії різних компонентів. Використовується для веб-базованих систем, операційних систем, баз даних, апаратного забезпечення, програмних бібліотек.

Артефакт (opens new window) (англ. artifact) — в UML окремий шматок інформації, що використовується чи з'являється в процесі розробки програмного забезпечення, наприклад файл з кодом, модель, частина документації, чи повідомлення електронної пошти тощо. На відміну від компонентів і класів, артефакти — це фізичні сутності, які розміщуються у фізичних вузлах (девайсах або середовищах розробки).

Кросплатформність, багатоплатформність (opens new window) — властивість програмного забезпечення працювати більш ніж на одній програмній/операційній системі або апаратній платформі; технології, що дозволяють досягти такої властивості.

FAQ (opens new window) (англ. Frequently Asked Questions) — підбірка часто задаваних питань на певну тему та відповідей на них, яка створюється для вільного доступу до інформації користувачами та економії часу розробників системи.

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

# Опис моделей та методологій розроблення ПЗ

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

Планування;
Аналіз вимог;
Проектування;
Розробка;
Тестування і налагодження;
Технічна підтримка.

Проте для полегшення організації роботи над проектом, існують різні методології, які чітко визначають процес розробки ПЗ.[1] (opens new window)

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

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

# Приклади моделей розроблення ПЗ

# Каскадна або водоспадна модель (waterfall model)[2] (opens new window)

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

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

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

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

Для замовників дана модель виглядає лінійно і з боку досить просто: за завершеним етапом проектування слідує програмування, а потім тестування - і так крок за кроком поки не буде досягнута фінальна точка і мета, заради якої ведеться розробка.

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

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

Цикл розробки ПЗ

# Інкрементна модель (incremental model)[3] (opens new window)

Інкрементна модель розробки програмного забезпечення підходить у тому випадку, якщо є чіткий план дій, але продукт потрібно запустити досить швидко, а зміни можна буде вносити потім. Її суть полягає в тому, що спочатку розробляється план дій та сегментується на невеликі завдання. Далі кожен блок розробляється за традиційною каскадною моделлю. Спочатку робиться «базовий» продукт з мінімальними, але важливими функціями. Поступово він доповнюється завдяки розробці інших компонентів, які називаються інкрементами. Процес зациклюється, доки не буде повністю зібраної єдиної системи.

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

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

# Ітеративна або ітераційна модель (iterative model)[3] (opens new window)

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

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

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

# Спіральна модель (spiral model)[3] (opens new window)

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

# Гнучка модель (agile model)[2] (opens new window)

Основні ідеї Agile:

Люди і взаємодія важливіші за процеси та інструменти;
Працюючий продукт важливіший за вичерпну документацію;
Співпраця з замовником важливіше узгодження умов контракту;
Готовність до змін важливіше проходження попереднім планом.

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

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

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

У внутрішньому плануванні та у продуктовій розробці без цього принципу й елементів Agile не обійтися.

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

# Lean[2] (opens new window)

Ідея підходу Lean полягає в тому, що ми ощадливо ставимося до ресурсів (у тому числі часу) і вирішуємо завдання найпростішим способом.

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

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

# SCRUM[4] (opens new window)

Scrum — одна з найпопулярніших гнучких методологій розробки програмного забезпечення з сімейства Agile.

Особливості Scrum

Scrum методологія ґрунтується на понятті спринту (sprint), протягом якого виконується робота над продуктом. Перед початком кожного спринту проводиться планування (Sprint Planning), на якому проводиться оцінка вмісту списку завдань із розвитку продукту (Product Backlog) і формування беклога на спринт (Sprint Backlog), у рамках яких і діє команда. Для спринту завжди існують обмеження по часу, зазвичай від тижня до місяця. Життя продукту таким чином розбита на рівні по тривалості спринти.

Робота над проектом розбивається на невеликі підзадачі. Команда з 5-7 осіб виконує кожну з них у фіксований термін (1-4 тижні).Протягом роботи над одним підзавданням проводиться 5 типів нарад.Отриманий результат роботи над кожним підзавданням має цінність для замовника.

Особливості

Плюси

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

2.Видимі результати. Підсумок кожного спринту — щось реальне. Нова функція або виправлення помилки не так важливо, як можливість бачити, що робота йде, і йде успішно.

Мінуси

1.Мотивація. Хотіти дотримуватися принципів Agile і робити це насправді — дві великі різниці.Тільки від скрам-майстра залежить, чи працюватиме Scrum для команди. Зробити так, щоб співробітники якщо не дружили, то поважали один одного, та розуміли важливість спільної роботи, може бути дуже складно.

2.Невідповідність мети та інструменту. Scrum безумовно хороший для багатьох завдань, навіть не пов'язаних із розробкою. Але, при цьому, всі методології сімейства Agile об'єднує не просто терпимість, а любов до змін. Якщо вашому проекту заявлена гнучкість ні до чого, та ви впевнені, що точно знаєте, як має виглядати проект від початку й до кінця, краще вибрати класичне проектне управління, що буде значно ефективнішим.

# RUP[2] (opens new window)

RUP(Rational Unified Process) - розробка продукту за даним методом складається з чотирьох фаз (початкова стадія, уточнення, побудова, впровадження), кожна з яких включає в себе одну або декілька ітерацій. RUP величезна методологія, котру важко описати одним абзацом тексту, але методи, рекомендовані RUP засновані на статистиці комерційно успішних проектів.

RUP використовує ітеративну модель розробки. В кінці кожної ітерації (в ідеалі що триває від 2 до 6 тижнів) проектна команда повинна досягти запланованих на дану ітерацію цілей, створити або допрацювати проектні артефакти і отримати проміжну, але функціональну версію кінцевого продукту. Ітеративний підхід розробки дозволяє швидко реагувати на зміни вимог, виявляти і усувати ризики на ранніх стадіях проекту, а також ефективно контролювати якість створюваного продукту.

# V-подібна модель (V-model)[5] (opens new window)

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

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

Плюси

строга етапність;
планування тестування і верифікація системи виробляються на ранніх етапах;
покращений, в порівнянні з каскадної моделлю, тайм-менеджмент;
проміжне тестування

Мінуси

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

V-model

# Kanban[6] (opens new window)

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

Kanban має два основні принципи:

візуалізації роботи;
обмеження кількості завдань “у процесі”.

Переваги Kanban

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

Недоліки Kanban

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

Kanban

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

Github projects (opens new window) - ця таблиця інтегрується з проблемами та запитами на злиття (pull requests) на платформі Github, щоб допомогти ефективно планувати та відстежувати роботу. Вона має можливість створювати кілька варіантів відображення, де ви можете фільтрувати, сортувати та групувати проблеми та запити(pull requests), додавати поля для відстеження метаданих, специфічних для кожної команди, і візулізувати роботу за допомогою діаграм.

Jira (opens new window) - один з найвідоміших та найпопулярніших таск-менеджерів. У всьому світі його використовують майже 20% команд. Jira – це хмарний сервіс для управління проектами, який містить величезну кількість інструментів. Він складається з трьох основних розділів: проекти (задачі, баги та запити), проблеми (списки помилок) та робочий процес (послідовність кроків). Jira добре вписується в Agile-методологію управління проектами.

Worksection (opens new window) - український онлайн-сервіс управління проектами. Його легко інтегрувати із сервісами Google, будь-якою CRM-системою, Slack та Telegram. На сьогоднішній день понад 1000 компаній використовують Worksection для керування своїми проектами. Сервіс Worksection підходить для різних типів бізнесу: діджитал-агентств, веб-студій, компаній відео-продакшену та ін.

Asana (opens new window) - це популярний таск-менеджер, який має як веб-версію так і мобільний додаток, і включає безліч функцій для ефективного контролю робочого процесу. Asana можна використовувати для Agile-методологій або керувати робочими проектами як своїми особистими задачами.

Trello (opens new window) - це простий у використанні хмарний сервіс для спільної роботи над проектами, який підійде для невеликих проектів та команд. Як і Jira, належить Atlassian. Trello дозволяє організувати вашу роботу на Канбан-дошках, які є його основними складовими. На сьогоднішній день у світі налічується понад 50 мільйонів користувачів Trello.

Monday.com (opens new window) - це хмарний сервіс управління проектами, що дозволяє командам ефективно контролювати робочий процес. Іноді користувачі називають його чудовою альтернативою Microsoft Project Manager. Monday.com підходить для Agile-методологій, для різних команд та проектів.

# Порівняльна таблиця

Вимоги	Критерії	Github Projects	Jira	Worksection	Asana	Trello	Monday.com	Just Chill (наш проект)
Функціональні (Functional)	Безкоштовна версія	➕	➕	➕	14d (10$/m)➖	30d (11$/m)➖	30d (8$/m)➖	➕
	Scrum/Kanban boards	➕	➕	➕	➕	➕	➕	➕
	Наявність API	➕	➕	➕	➕	➕	➕	➕
	Кросплатформеність (Crossplatform)	➕➖	➕	➕	➕	➕	➕	➕
	Управління ресурсами (Resource management)	➕➖	➕➖	➕	➕➖	➕➖	➕	➕
	Візуалізація прогресу (графіки, діаграми)	➕➖	➕➖	➕	➕	➖	➕➖	➕➖
	Можливості комунікації між учасниками проекту	➕➖	➕➖	➕	➕➖	➕	➕	➕
Зручність (Convenience)	Багатомовність	➕	➕	➕	➕	➕	➕	➕
	Mobile App	➕➖	➕	➕	➕	➕	➕➖	➕➖
	Інтеграція з Github, Slack	➕	➕	➕	➕	➕	➕	➕
	User-friendly interface	➕	➖	➕	➕➖	➕	➕	➕
	Hot keys	➕	➕	➖	➕	➕	➕	➕
Надійність (Reliability)	Резервне копіювання	➕	➕	➕	➕➖	➕	➕	➕
Надійність (Reliability)	Протокол шифрування	SSL	TLS	SSL	TLS	TLS	SSL	SSL
Продуктивність (Productivity)	Час відповіді сервера (Server Response Time)	➕	➕	➕	➕	➕	➕	➕
	Синхронізація в реальному часі	➕	➕	➕	➕	➕	➕	➕
	Стійкість до збоїв	➕	➕	➕	➕	➕	➕	➕
Підтримка (Support)	FAQ	➕	➕	➕	➕	➕	➕	➕
	Онлайн служба підтримки	➕	➕	➕	➕	➕	➕	➖
	Частота впроваджень нових функцій	➕	➕	➕	➕	➕	➕	➖

# Висновки

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

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

# Посилання

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