diff --git a/README.md b/README.md index 6271b269..7807f40b 100644 --- a/README.md +++ b/README.md @@ -1,13 +1,12 @@ -# database_basics_template - -Шаблон репозиторію для виконання лабораторних робіт з курсу "Організація баз даних" - -*Для виконання лабораторних робіт необхідно зробити ```fork``` цього репозіторію, склонувати вже власний репозіторій та розміщувати документацію (результати виконання лабораторних робіт) у відповідних діректоріях. -В цьому файлі необхідно вказати назву проекту (тему лабораторних робіт). Коротку загальну характеристику -проекту, контактні дані виконавців.* - -[Теми проєктів](./guidelines/themes.md) - -[Методичні вказівки](./guidelines/guidelines.md) - -[Звітність](https://docs.google.com/spreadsheets/d/1ePb9OBB7ox0E5-GAh2r6ZU3j--PpAROCUfqzA17kL20/edit?usp=sharing) +# ProjectsLab + +Система управління проектами (СУП). За домогою цієї системи ви зможете зручно керувати своїми проектами та їх розробкою. + +## Розробники +- Дмитро Увін (Telegram - @dmitriyuvin) +- Ілля Писарчук (Gmail - Flimka134@gmail.com) +- Ростислав Накарловіч (Telegram - @Zvesdochyot) +- Павло Скворцов (Telegram - @p_skv) +- Кирило Салун (Gmail - kaeviane@gmail.com) +- Артем Сударєв (Telegram - @sssudarev) +- Сергій Прилепа (Telegram - @seaborg1um) diff --git a/docs/requirements/README.md b/docs/requirements/README.md index 4ce87ba1..236d9b17 100644 --- a/docs/requirements/README.md +++ b/docs/requirements/README.md @@ -1,5 +1,6 @@ -# Аналіз вимог до інформаційної системи +# ProjectsLab. Аналіз вимог до інформаційної системи -В цьому файлі необхідно перелічити всі документи, розроблені в проекті та дати посилання на них. +Документи, які були розроблені для подальшої розробки СУП за поданими замовником та зацікавленими особами вимогами та запитами: -*В рамках проекту розробляються документи "Аналіз предметної області" та "Запити зацікавлених осіб".* + - [Аналіз предметної області](./state-of-the-art.md) + - [Запити зацікавлених осіб](./stakeholders-needs.md) diff --git a/docs/requirements/stakeholders-needs.md b/docs/requirements/stakeholders-needs.md index bbdb2682..911ccf32 100644 --- a/docs/requirements/stakeholders-needs.md +++ b/docs/requirements/stakeholders-needs.md @@ -1,86 +1,114 @@ -# Назва проєкту. Запити зацікавлених осіб +# ProjectsLab. Запити зацікавлених осіб ## Вступ -*[Вступ повинен містити короткий огляд всього документу.]* +У цьому документі описуються запити зацікавленої особи, в якості якої виступає доцент Болдак А. О., по відношенню до розробляємої в рамках лаборатних робіт - системи управління проектами. ### Мета -*[Визначення мети цієї сукупності вимог. Зазвичай такою метою є створення та впровадження - інформаційної системи відповідного призначення.]* +Метою документа є визначення основних вимог до функціональності, продуктивності і експлуатаційної придатності, а також визначення бізнес-правил і технологічних обмежень, що пред'являються до предмету розробки. ### Контекст -*[Короткий опис того, з якими проектами пов'язаний цей документ, на що він впливає.]* +Цей документ пов'язаний з системою управління проектами, описує її особливості, функціонал та інші властивості та відповідає запитам зацікавлених осіб і аналізу предметної області. ### Основні визначення та скорочення -*[Розділ містить визначення всіх термінів та скорочень, необхідних для правильного -тлумачення вимог. Можна зробити посилання на документ, в якому поданий аналіз предметної області.]* - +* СУП - Система Управіння Проектами ### Посилання -*[Розділ містить повний список всіх документів, про які згадується.]* - +- [Джерело 1 (oridu.odessa)](http://www.oridu.odessa.ua/7/7/metoduchni-rek/t/02.pdf) +- [Джерело 2 (ela.kpi)](https://ela.kpi.ua/bitstream/123456789/19481/1/DMM_UP_2017.pdf) +- [Джерело 3 (gihub.com)](https://github.com/ip-85/robin/blob/master/docs/stakeholders.md#4) +- [Джерело 4 (rayradavn.gov.ua)](http://rayradavn.gov.ua/images/metodychna/zayavka.pdf) ## Короткий зміст -*[Розділ містить опис того, про що йдеться в еій частині цього документу, що залишилася. -Також тут описана структура документу.]* +В подальшій частині документа описуються ділові процеси, вимоги замовника, виключні та основні сценарії розробки продукту. ## Характеристика ділових процесів -*[В цьому розділі визначаються зовнішні фактори, що впливають на бізнес (бізнес-актори), -та внутрішні фактори (робітники), дається загальна характеристика діяльності бізнес-акторів -та робітників, яка здійснюється за допомогою бізнесу.* +Type: Business Use Case | Package: #002 | Scenario: #002 | Version: 1.0 | BUC.002.002.v1.0
+ +***НАЗВА:*** Cтворення проекту.
-*Дається опис бізнес-сценаріїв взаємодії бізнес-акторів, робітників і, можливо, інформаційної системи за допомогою наступної -специфікації:* +***УЧАСНИКИ:*** Team Lead, керуючий
- -***ID:*** - -***НАЗВА:*** - -***УЧАСНИКИ:*** +***ПЕРЕДУМОВИ:*** Вимоги замовника
-***ПЕРЕДУМОВИ:*** +***РЕЗУЛЬТАТ:*** Проект, готовий до роботи
-***РЕЗУЛЬТАТ:*** +***ВИКЛЮЧНІ СИТУАЦІЇ:***
-***ВИКЛЮЧНІ СИТУАЦІЇ:*** +- EX.002.001 Недостатньо відомостей замовника
+- EX.002.002 Недостатня кількість розробників
+- EX.002.003 Можливість реалізації
***ОСНОВНИЙ СЦЕНАРІЙ:*** -*Кількість сценаріїв визначається у відповідності до специфіки завдання та необхідного -рівня деталізації (зазвичай, 5-6 сценаріїв).* +1. Team lead та керуючий реєструються на платформі. +2. Інтегрує проект з репозиторію github-а. +3. Задає назву, опис проекту. +4. Запрошує команду, призначає ролі, зони відповідальності.(Можлива EX.002.002) +5. Трансформує вимоги замовника в завдання, призначає на них людей.(Можливі EX.002.001 EX.002.002 EX.002.003) +6. Створює колонки для відстеження прогресу.(Можлива EX.002.003) +7. Налаштовує instant messages. +8. Задає опис кінцевого продукту. ## Короткий огляд продукту -*[Визначається границя системи та категорії її користувачів. Дається загальна характеристика категорій користувачів -системи]* - -*[Нижче йде опис FURPS:]* +ProjectsLab - це сервіс, який допоможе Вам у розробці програмного забезпечення. Сервіс для слідкування та управління проектами, командами, задачами. Користувачі нашої системи зможуть оперувати задачами та проектами у зручному "user-friendly" інтерфейсі, також ми надаємо змогу усім користувачам нашого сервісу спілкуватися між собою у зручному інтерфейсі. Користувачі зможуть створювати команди та зберігати їх для майбутніх проектів. ## Функціональність -*[Functionality (функциональні вимоги)]* +Основні вимоги до функціональності, що пред'являються зацікавленим особами до предмету розробки, відносяться до таких категорій: + +* Інтеграція програмного забезпечення. +* Модифікація функціональності зацікавлено особи. + +- Інтеграція програмного забезпечення: + +Користувачі данної СУП повинні мати можливість інтегрувати її з VCS (Version Control System). Наприклад з GitHub. + +- Зацікавлена особа: + +Зацікавленою особою є фізичне або юридичне лице, яке бажає контролювати процес роботи над проектом. ## Практичність -*[Usability (вимоги до зручності роботи)]* +- Локалізація: + +СУП повинна мати українську, російську та англійську локалізації, а також функцію доповнення програми новимии локалізаціями. + +- Мультиплатформеність: + +СУП повинна бути адаптована для доступу як і звичайних комп’ютерів, так і для мобільних пристроїв, що мають підключення до мережі Інтернет. Також СУП бути адаптованою для кожного браузера. + +- Інтерфейс: + +Інтерфейс СУП має бути максимально простим та інтуїтивно зрозумілим для користувача, без зайвих компонентів. Також має бути доступна детальна інструкція використання даного сервісу та його можливостей. ## Надійність -*[Reliability (вимоги до надійності)]* +- Працездатність: + +Працездатність СУП не повинна порушуватися збоями, затримками, або відсутність з’єднання в мережі Інтернет. При порушенні з’єднання сервіс переходить в автономний режим накопичування вхідних даних до того моменту, поки з’єднання не буде відновлено. + +- Резервне копіювання та відновлення даних: + +СУП повинна мати функцію копіювання та збережених даних на незалежні сервери для можливого їх подальшого відновлення. ## Продуктивність -*[Performance (вимоги до продуктивності)]* +- Швидке реагування на запит. +- Якісна взаємодія усіх учасників проекту. +- Якісна синхронізація матеріалів проекту. ## Експлуатаційна придатність -*[Supportability (вимоги до підтримки)]* +- Зручне використання на мобільних пристроях та комп'ютерах +- Зручне, швидке та зрозуміле редагування проекту +- Швидке та своєчасне оновлення даних по проекту diff --git a/docs/requirements/state-of-the-art.md b/docs/requirements/state-of-the-art.md index 3949b09a..9927bcc9 100644 --- a/docs/requirements/state-of-the-art.md +++ b/docs/requirements/state-of-the-art.md @@ -1,34 +1,143 @@ -# Назва проєкту. Аналіз предметної області +# Система управління проєктами. Аналіз предметної області ## Вступ +В даному документі описується предметна область для майбутньої розробки Системи Управління Проектами (СУП) +### Система управління проєктами *(англ. Project management system)* -*[Вступ повинен містити короткий огляд всього документу.]* +**Управління проєктом [(uk.wikipedia.org)](https://uk.wikipedia.org/wiki/%D0%A3%D0%BF%D1%80%D0%B0%D0%B2%D0%BB%D1%96%D0%BD%D0%BD%D1%8F_%D0%BF%D1%80%D0%BE%D1%94%D0%BA%D1%82%D0%B0%D0%BC%D0%B8)** — це процес керівництва роботою команди для досягнення цілей та успішного виконання поставлених завдань протягом визначеного часу. Основними обмеженнями будь-якого проєкту є складність, час, якість та бюджет. Тому оснвною задачею є оптимізація розподілу необхідних ресурсів та їх застосування для досягнення визначених цілей. +Необхідність управління проєктами, а саме необхідність координації використання людських та матеріальних ресурсів протягом життєвого циклу проєкту за допомогою сучасних методів і техніки управління для досягнення відповідного рівня прибутків учасників проекту, високої якості продукції, пов'язана з масовим ростом масштабів і складності проєктів, зростанням вимог до термінів їх здійснення, якості виконуваних робіт. + +### Компоненти, що входять в поняття управління проєктами: +- визначення і формування вимог до проєкту; +- формування максимально чітких і зрозумілих цілей; +- встановлення і реалізація комунікації між задіяними в проєкті сторонами; +- врегулювання проектних обмежень: зокрема бюджету, ресурсів, ризиків, дедлайнів, якості; +- спілкування з командою, врахування їх потреб/побажань/очікувань і корекція існуючих планів відповідно до отриманих матеріалів. + +--- + +При реалізації кожної з методик управління проектами зазвичай не обійтися без певного комплексу технологічного та організаційного інструментарію. Тобто, без системи управління проєктами. У загальному розумінні це певна сукупність методів, які можуть впливати на об'єкт управління з метою реалізації всіх поставлених завдань. Але найчастіше це поняття використовується в більш вузькому сенсі — як позначення конкретної програми. + +Всі вони переслідують 3 основні цілі: зробити співробітників більш ефективними, зробити сам процес проектного менеджменту продуктивнішим і ефективнішим, зробити управління проєктним профілем компанії зручнішим і прозорим для погляду з боку. ## Основні визначення -*[Розділ містить визначення термінів та скорочень, які використовуються при аналізі предметної області.]* +**Програмне забезпечення _(англ. software)_ [(uk.wikipedia.org)](https://uk.wikipedia.org/wiki/%D0%9F%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BD%D0%B5_%D0%B7%D0%B0%D0%B1%D0%B5%D0%B7%D0%BF%D0%B5%D1%87%D0%B5%D0%BD%D0%BD%D1%8F)** — сукупність програм системи обробки інформації і програмних документів, необхідних для експлуатації цих програм. + +**Документація [(uk.wikipedia.org)](https://uk.wikipedia.org/wiki/%D0%94%D0%BE%D0%BA%D1%83%D0%BC%D0%B5%D0%BD%D1%82%D0%B0%D1%86%D1%96%D1%8F)** — сукупність офіційно визнаних, взаємопов'язаних та складених у визначеній формі документів, які містять передбачувану інформацію про виріб, процес або діяльність даного підприємства. + +**Проєкт [(uk.wikipedia.org)](https://uk.wikipedia.org/wiki/%D0%9F%D1%80%D0%BE%D1%94%D0%BA%D1%82)** — обмежена в часі, ресурсах та вимогах якості унікальна сукупність процесів, направлена на досягнення унікальних цілей та завдань для створення нової цінності (продукту або послуги). + +**Система управління проєктами _(англ. Project management system)_ [(uk.wikipedia.org)](https://uk.wikipedia.org/wiki/%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B0_%D1%83%D0%BF%D1%80%D0%B0%D0%B2%D0%BB%D1%96%D0%BD%D0%BD%D1%8F_%D0%BF%D1%80%D0%BE%D1%94%D0%BA%D1%82%D0%B0%D0%BC%D0%B8)** — комплексне програмне забезпечення, що включає в себе програми для планування завдань, складання розпису, контролю ціни і управління бюджетом, розподілу ресурсів, спільної роботи, спілкування, швидкого управління, документування та адміністрування системи, яке використовуються спільно для управління великими проєктами. + +**Завдання [(wikipedia.org)](https://uk.wikipedia.org/wiki/%D0%97%D0%B0%D0%B2%D0%B4%D0%B0%D0%BD%D0%BD%D1%8F)** - проблемна ситуація з чітко визначеною ідеєю мети, яку необхідно досягти саме через параметризацію граничних умов, обставин; в більш вузькому сенсі задачею називають також цю саму параметризовану мету, що дана в рамках граничних умов проблемної ситуації, тобто те, що необхідно виконати. + +**Система керування версіями _(англ. source code management, SCM)_ [(uk.wikipedia.org)](https://uk.wikipedia.org/wiki/%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B0_%D0%BA%D0%B5%D1%80%D1%83%D0%B2%D0%B0%D0%BD%D0%BD%D1%8F_%D0%B2%D0%B5%D1%80%D1%81%D1%96%D1%8F%D0%BC%D0%B8)** — програмний інструмент для керування версіями одиниці інформації: вихідного коду програми, скрипту, веб-сторінки, веб-сайту, 3D-моделі, текстового документу тощо. \ +Система керування версіями — інструмент, який дозволяє одночасно, не заважаючи один одному, проводити роботу над груповими проектами. + +**Життєвий цикл програмного забезпечення [(uk.wikipedia.org)](https://uk.wikipedia.org/wiki/%D0%96%D0%B8%D1%82%D1%82%D1%94%D0%B2%D0%B8%D0%B9_%D1%86%D0%B8%D0%BA%D0%BB_%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BD%D0%BE%D0%B3%D0%BE_%D0%B7%D0%B0%D0%B1%D0%B5%D0%B7%D0%BF%D0%B5%D1%87%D0%B5%D0%BD%D0%BD%D1%8F)** — сукупність окремих етапів робіт, що проводяться у заданому порядку протягом періоду часу, який починається з вирішення питання про розроблення програмного забезпечення і закінчується припиненням використання програмного забезпечення. + +**Водоспадна модель _(англ. waterfall model)_ життєвого циклу ПЗ [(uk.wikipedia.org)](https://uk.wikipedia.org/wiki/%D0%92%D0%BE%D0%B4%D0%BE%D1%81%D0%BF%D0%B0%D0%B4%D0%BD%D0%B0_%D0%BC%D0%BE%D0%B4%D0%B5%D0%BB%D1%8C)** — послідовний метод розробки програмного забезпечення, названий так через діаграму, схожу на водоспад. Ця модель розробки запозичена з системної інженерії у виробництві та будівництві — областях, в яких зміни на пізніх етапах дуже дорогі або неможливі. В данному випадку проект не розбивається на "спрінти", а виконується за одну довгу ітерацію. В данний час не є ефективною. + +**Agile-менеджмент _(від англ. Agile — «рухливий», «спритний», «еластичний»)_ [(uk.wikipedia.org)](https://uk.wikipedia.org/wiki/Agile-%D0%BC%D0%B5%D0%BD%D0%B5%D0%B4%D0%B6%D0%BC%D0%B5%D0%BD%D1%82)** — ітераційний метод планування та керування проєктами і процесами. Agile-менеджмент виділяє короткі цикли розробки продукту, надаючи додаткові оновлення в залежності від зміни потреб клієнта. Найпопулярніша методологія розробки проектів. Проект декомпозується на підзадачі та формуються "спрінти", найчастіше тижневі або двотижневі, і таким чином ведеться розробка. + +**Спіральна модель _(англ. spiral model)_ [(uk.wikipedia.org)](https://uk.wikipedia.org/wiki/%D0%A1%D0%BF%D1%96%D1%80%D0%B0%D0%BB%D1%8C%D0%BD%D0%B0_%D0%BC%D0%BE%D0%B4%D0%B5%D0%BB%D1%8C)** — генератор моделі процесу керування ризиками для проєктів програмного забезпечення. Спіральна модель скеровує команду на прийняття елементів однієї чи кількох моделей процесів, як-от інкрементного, водоспадного чи еволюційного методів планування проєктів. Проект декомпозується на підзадачі та формуються "спрінти" трохи довші за спрінти в Agile, найчастіше тижневі або двотижневі, і таким чином ведеться розробка. ## Підходи та способи вирішення завдання -*[Розділ містить опис підходів, моделей та способів вирішення завдання.]* +Кожен створений проект складається та характеризується такими ресурсами (артефактами): +- Час +- Робоча сила - Люди (Розробники) +- Роль кожного розробника/учасника п проекті +- Проект, як велика кількісна задача, що потребує детальної декомпозиції на менші частини +- Задачі +- Підзадачі до задач + +Проект, згідно вимог замовника та зацікавлених осіб декомпозується на менші задачі/підзадачі та формуються комплекти задач на кожний "спрінт". Прогрес відстежується за допомогою виконаних задач (Наприклад в колонці - Done). +Також, у кожного учасника проекта є своя роль, наприклад учасник з роллю Teamlead, може створити команду, задачі, та назначити для кожної задачі одного або декількох розробників та відстежувати їх прогрес. Також, для такої системи є життєво необхідное система Instant Messages and Notifcations, щоб кожен учасник був оповіщений про будь-які події вчасно. + +Існує ряд підходів до організації проектної діяльності, зокрема: + +### **_Управління перевагами_** + +Управління перевагами проекту визначається як "ініціювання, планування, організація, виконання, контроль, перехід та підтримка змін в організації та їх наслідків, спричинених механізмами управління проектами для реалізації заздалегідь визначених переваг проекту". + +### **_Метод критичного ланцюга_** + +Метод критичного ланцюга є додатком теорії обмежень для планування та управління проектами, призначений для подолання невизначеностей, властивих управлінню проектами, беручи до уваги обмежену доступність ресурсів (фізичних, людських навичок, а також можливостей управління та підтримки), необхідних для виконання проектів. + +### **_Метод освоєного обсягу_** + +Методика освоєного обсягу передбачає складання повного опису проекту і детального графіка його реалізації ще на початковій стадії. Це дозволяє робити точні оцінки фактичних даних і контролювати проект з початку і до повного завершення робіт. Перевага цього інструменту полягає в тому, що він дозволяє отримувати точні та надійні дані про хід виконання проекту вже на стадії 15%-ного його виконання. + +### **_Ітеративно-інкрементний підхід_** + +Основна ідея полягає в тому, щоб розробити систему шляхом циклів, що повторюються (ітеративний) та в менші проміжки часу (інкрементний), даючи змогу розробнику скористатися перевагами того, що було вивчене під час розробки попередніх порцій або версій системи. + +### **_Бережливе управління проектами_** + +Бережливе управління проектами використовує принципи бережливого виробництва, щоб зосередитись на забезпеченні цінності з меншими витратами та за меншу кількість часу. + +### **_Поетапний(фазовий) підхід_** + +Поетапний підхід розбиває та керує роботою через низку окремих кроків, які потрібно завершити. Зазвичай він складається з п’яти областей процесу: + +- ініціація +- планування та дизайн +- виконання +- контроль +- завершення або закриття. + +![alt text](https://upload.wikimedia.org/wikipedia/commons/a/a0/1_UA_Project_Management_%28phases%29.png "5 етапів розробки проекту") + +### **_Процесне управління_** + +Це підхід управління, який розглядає бізнес як сукупність процесів, яким вдалося досягти бажаного результату. Процеси керуються та вдосконалюються організацією з метою досягнення їх бачення, місії та основної цінності. ## Порівняльна характеристика існуючих засобів вирішення завдання -*[Розділ містить опис існуючих програм, інформаційних систем, сервісів, тощо, призначених для вирішення -завдання. Дається порівняльна характеристика властивостей FURPS:* -- *Functionality (функциональні вимоги)* -- *Usability (вимоги до зручності роботи)* -- *Reliability (вимоги до надійності)* -- *Performance (вимоги до продуктивності)* -- *Supportability (вимоги до підтримки)* +### Найпоширеніші сервіси з планування та керування проєктами + +- **Asana [(asana.com)](https://asana.com/)** — програмне забезпечення для браузерів та мобільних пристроїв, призначене для спільної роботи над проєктами. Основний акцент розробників сервісу робиться на те, що управління проєктами можна здійснювати без використання електронної пошти. Кожна команда може створити для себе зручне робоче оточення (workspace). Кожне таке оточення може включати в себе множину проєктів, а кожен проєкт, в свою чергу, включає в себе множину задач. Asana дає можливість користувачу підписатися на цікаву для нього задачу. У разі змінення або закриття такої задачі всі підписники отримають відповідне сповіщення. + +- **Basecamp [(basecamp.com)](https://basecamp.com/)** — це інструмент для управління проєктами, планування спільної роботи та постановки завдань по проєктам, що поширюється за допомогою хмарної моделі. У кожному новому проєкті можна вести бесіди, вносити текстові або будь-які інші документи, складати списки з пріоритетних завдань і користуватися календарем. Адміністратор має змогу вести моніторинг ступеня підготовки проекту та активності кожного учасника команди. + +- **GitHub Projects [(github.com)](https://github.com/features/project-management/)** — це веб-сервіс, де менеджери проєктів та розробники координують, відстежують та оновлюють результати своєї роботи в одному місці, завдяки чому проєкти залишаються прозорими. Достатньо лише створити задачу, щоб запропонувати нову ідею або повідомити про помилку. Після цього лідер команди організує та доручить завдання своїй команді. Однією з переваг є те, що такі запити підтримують більшість типів зображень і файлів. + +- **Jira Software [(atlassian.com)](https://www.atlassian.com/ru/software/jira)** — система відстеження помилок, призначена для організації спілкування з користувачами і управління проектами. Доступна в двох версіях: хмарній і серверній. На даний момент Jira є однією з найпопулярніших систем управління проблемами. Головними елементами Jira є проблема (issue) і робочий процес (workflow). Проблема описує роботу яка має бути виконана, мусить бути названа і описана. Важливим атрибутом є статус (status), який показує на якому етапі знаходиться робота над проблемою. Статус змінюється згідно робочого процесу, створеного для цієї проблеми. + +- **Microsoft Project [(microsoft.com)](https://www.microsoft.com/ru-ru/microsoft-365/project/project-management-software)** — програмне забезпечення для управління проєктами, створене, щоб допомогти менеджеру проекту в розробці планів, розподілі ресурсів за завданнями, відстеженні прогресу та аналізі обсягів робіт. Створює розклади критичного шляху. Розклади можуть бути складені з урахуванням використовуваних ресурсів. Ланцюжок управління проєктом візуалізується в діаграмі Ганта. + +- **Trello [(trello.com)](https://trello.com/)** — це програмне забезпечення для управління проєктами. Проєкти в Trello представлені у вигляді дошки, що містить відповідні списки завдань. Списки містять картки, які пов’язані з завданнями. У міру реалізації проєктного процесу, картки переміщаються з одного списку в інший. Картки містять інформацію про користувачів / відповідальних за виконання завдання. Користувачі і дошки можуть бути згруповані в проєктні команди. На картках користувачі можуть залишати коментарі, голосувати за них. + +### Таблиця порівнянь існуючих засобів вирішення завдання - *(у вигляді таблиці).]* +| Критерій \ Сервіс | Asana | Basecamp | GitHub Projects | Jira | Microsoft Project | Trello | +|:----------------------:|:-----------------------------:|:-----------------------------:|:-----------------------------:|:-----------------------------:|:-------------------------------:|:-----------------------------:| +| Наявність API | ✔️ | ✔️ | ✔️ | ✔️ | ❌ | ✔️ | +| Ціноутворення | безкоштовно / платна підписка | безкоштовно / платна підписка | безкоштовно / платна підписка | безкоштовно / платна підписка | разова оплата / платна підписка | безкоштовно / платна підписка | +| Наявність FAQ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | +| Багатомовність | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | +| Кросплатформність | ✔️ | ✔️ | ✔️ | ✔️ | ❌ | ✔️ | +| Протокол шифрування | TLS 1.2 | TLS 1.2 | No data | TLS 1.2 | SSL / TLS | SSL | +| Швидкість доступу | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | +| Наявність документації | ✔️ | ✔️ | ✔️ | ✔️ | ❌ | ✔️ | +| Своєчасне оновлення | ✔️ | ✔️ | ✔️ | ✔️ | ❌ | ✔️ | ## Висновки -*[Робляться висновки щодо доцільності розробки нової або модифікації існуючої інформаційної системи, необхідності та способів інтеграції з системами(сервісами) третіх сторін, тощо.]* + У зв'язку зі збільшенням кількості проектів, зростанням їх складності та кількості виконавців, попит на системи управління проектами безперестанно зростає, на відміну від кількості цих систем. Оскільки попит почав з'являтися не так давно, то не було розроблено такої системи, яка влаштовувала б усіх користувачів. Існує достатня кількість аналогів, кожен з яких має свої сильні та слабкі сторони, тож було прийнято рішення про створення власної системи управління проектами, яка об'єднала б у собі переваги попередників і оптимізувала або позбулася недоліків. ## Посилання -*[Розділ містить повний список всіх документів, про які згадується.]* +**[Project management](https://en.wikipedia.org/wiki/Project_management)**\ +**[Process-based management](https://en.wikipedia.org/wiki/Process-based_management)**\ +**[Методика освоєного обсягу в Управлінні Проектами](https://ua-referat.com/%D0%9C%D0%B5%D1%82%D0%BE%D0%B4%D0%B8%D0%BA%D0%B0_%D0%BE%D1%81%D0%B2%D0%BE%D1%94%D0%BD%D0%BE%D0%B3%D0%BE_%D0%BE%D0%B1%D1%81%D1%8F%D0%B3%D1%83_%D0%B2_%D0%A3%D0%BF%D1%80%D0%B0%D0%B2%D0%BB%D1%96%D0%BD%D0%BD%D1%96_%D0%9F%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%B0%D0%BC%D0%B8)**\ +**[Ітеративна та інкрементна розробка](https://uk.wikipedia.org/wiki/%D0%86%D1%82%D0%B5%D1%80%D0%B0%D1%82%D0%B8%D0%B2%D0%BD%D0%B0_%D1%82%D0%B0_%D1%96%D0%BD%D0%BA%D1%80%D0%B5%D0%BC%D0%B5%D0%BD%D1%82%D0%BD%D0%B0_%D1%80%D0%BE%D0%B7%D1%80%D0%BE%D0%B1%D0%BA%D0%B0)**\ +**[Основи роботи з Trello. 1 Вступ](http://prof.nau.edu.ua/help/osnovi-roboti-z-trelo-1-vstup/)**\ +**[Atlassian JIRA](https://uk.wikipedia.org/wiki/Atlassian_JIRA)**\ +**[Microsoft Project](https://uk.wikipedia.org/wiki/Microsoft_Project)**\ +**[Asana](https://uk.wikipedia.org/wiki/Asana)**\ +**[Опис Basecamp](https://startpack.ru/application/basecamp)**\ +**[Basecamp](https://ru.wikipedia.org/wiki/Basecamp)**