Управління проєктом розробки мобільного застосунку "Викладач ЧДТУ"

Цибенко, В'ячеслав Олександрович

Please use this identifier to cite or link to this item: https://er.chdtu.edu.ua/handle/ChSTU/6675

Title:	Управління проєктом розробки мобільного застосунку "Викладач ЧДТУ"
Authors:	Оксамитна, Любов Павлівна Цибенко, В'ячеслав Олександрович
Keywords:	МОБІЛЬНИЙ ЗАСТОСУНОК;ВИКЛАДАЧ;БАЗА ДАНИХ.
Issue Date:	17-Dec-2025
Abstract:	У сучасному світі заклади вищої освіти (ЗВО) активно переходять до цифрових форматів роботи. Збільшується кількість курсів в онлайн режимі, електронних журналів, дистанційних пар і викладачам потрібно швидко керувати навчальним процесом у будь-який момент. Це робить створення мобільного застосунку для викладачів особливо актуальним. Для цифровізації освіти університети впроваджують електронні системи управління навчанням (LMS), але більшість із них орієнтовані на роботу з комп’ютерами. Викладачам часто потрібен зручний мобільний інструмент для оперативних дій. Після пандемії багато процесів залишилися онлайн. Це створює потребу в інструментах, які підтримують оперативний доступ до інформації в реальному часі. Метою кваліфікаційної роботи магістра є розробка та обґрунтування концепції мобільного застосунку «Викладач ЧДТУ», який забезпечує викладачів зручними інструментами для організації навчального процесу, керування академічною діяльністю. Об’єктом дослідження є процес організації та управління навчальною діяльністю викладача закладу вищої освіти в умовах цифровізації освітнього середовища. Предметом дослідження є методи, засоби та програмні рішення для підтримки й автоматизації роботи викладача через мобільний застосунок «Викладач ЧДТУ». Апробація результатів роботи. Основні положення і результати кваліфікаційної роботи магістра доповідалися і були обговорені на конференції «День студентської науки кафедри КНСА», 22 квітня 2025 року, Черкаси, Україна. Публікації. В. О. Цибенко, Л. П. Оксамитна, Г. О. Заспа. Ініціація проєкту створення мобільного застосунку «Викладач ЧДТУ»: Збірник тез доповідей студентської науково-практичної конференції ЧДТУ : 22-23 квітня 2025 / [упорядник Мельник І.В.]; Міністерство освіти і науки України, Черкаський державний технологічний ун-т. Черкаси : ЧДТУ, 2025. С. 25.
URI:	https://er.chdtu.edu.ua/handle/ChSTU/6675
Appears in Collections:	122 Комп’ютерні науки (Управління стартапами і проектами в галузі інформаційних технологій)

Files in This Item:

File	Description	Size	Format
Пояснювальна записка_Цибенко В'ячеслав_МСТП-2402_2025-2026.pdf Restricted Access		3.23 MB	Adobe PDF	View/Open Request a copy

Show full item record

Extracted text

МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ
ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОГІЧНИЙ УНІВЕРСИТЕТ

Факультет інформаційних технологій і систем

Кафедра комп’ютерних наук та системного аналізу

Пояснювальна записка
до кваліфікаційної роботи
магістра
(освітньо-кваліфікаційний рівень)

на тему: «Управління проєктом розробки мобільного застосунку «Викладач
ЧДТУ»»

Виконав: студент 2 курсу, групи МСТП-2402

спеціальності 122  «Комп’ютерні науки»
(шифр і назва спеціальності)

освітня програма «Управління стартапами
(назва освітньої програми)
і проєктами в галузі інформаційних технологій»

Цибенко В’ячеслав Олександрович

Керівник Оксамитна Л.П.
(прізвище та ініціали)

Консультант___________ Заспа Г.О.
(прізвище та ініціали)

Рецензент Мельник В.П.
(прізвище та ініціали)

Черкаси 2025 року

2
Бланк завдання на кваліфікаційну роботу магістра студенту

Черкаський державний технологічний університет
Факультет Інформаційних технологій і систем
Кафедра Комп’ютерних наук та системного аналізу
Освітньо-кваліфікаційний рівень Магістр
Спеціальність 122 – комп’ютерні науки
Освітня програма Управління стартапами і проєктами в галузі інформаційних технологій

ЗАТВЕРДЖУЮ
Завідувач кафедри КНСА
_______________ Юрій ТРИУС
«____» _____________ 2025 р.

ЗАВДАННЯ
на кваліфікаційну роботу магістра студенту
Цибенку В’ячеславу Олександровичу
(прізвище, ім‘я, по батькові)
1. Тема роботи Управління проєктом розробки мобільного застосунку «Викладач ЧДТУ»

Керівник роботи Оксамитна Любов Павлівна, к.т.н., доцент
(прізвище, ім’я, по батькові, науковий ступінь, вчене звання)
затверджені наказом університету від «07» жовтня 2025 р. № 307/03-03.

2. Строк подання студентом роботи «15» грудня 2025 року.
3. Вихідні дані до роботи:
Результати та матеріали з проходження виробничої та переддипломної практики.

4. Зміст пояснювальної записки (перелік питань, що їх належить розробити):
Вступ
4.1. Аналіз та дослідження предметної галузі.
4.2. Розробка концепції проєкту.
4.3. Планування проєкту.
4.4. Практична реалізація продукту проєкту.
Висновки.
5. Перелік додатків (з точним зазначенням назв додатків):
5.1. Додаток А. Специфікація 482. ЧДТУ. 52420-01.
Інструкція користувача
5.2. Додаток Б. Публікація по темі кваліфікаційної роботи магістра.
5.3 Презентація у вигляді 30 слайдів.

3
6. Консультанти розділів роботи
Прізвище, ініціали та Підпис, дата
Розділ посада
завдання видав завдання прийняв
консультанта

7. Дата видачі завдання 02.09.2025 р.

КАЛЕНДАРНИЙ ПЛАН
Строк виконання
№ з/п Назва етапів кваліфікаційної роботи магістра Примітка
етапів роботи
1 Видача завдання на кваліфікаційну роботу до 02.09.2025 Виконано
магістра.
2 Аналіз літературних джерел, об’єкту та до 15.09.2025 Виконано
предмету дослідження.
3 Написання теоретичного розділу до 01.10.2025 Виконано
кваліфікаційної роботи магістра.
4 Написання аналітичного розділу (аналіз об’єкту до 03.11.2025 Виконано
й предмету дослідження).
5 Написання практичних розділів й висновків до 01.12.2025 Виконано
кваліфікаційної роботи магістра.
6 Передзахист кваліфікаційної роботи магістра на до 01.12.2025 Виконано
засіданні випускової кафедри.
7 Подання роботи завідувачу кафедри КНСА. до 15.12.2025 Виконано
8 Захист кваліфікаційної роботи магістра. 18.12.2025 Виконано

Студент _____________________________ В’ячеслав ЦИБЕНКО
(підпис)

Керівник роботи ____________________________ Любов ОКСАМИТНА
(підпис)

4
РЕФЕРАТ
Кваліфікаційна робота магістра містить: 87 с., 27 рис., 10 табл., 28
використаних джерел, 2 додатки.
Актуальність теми. У сучасному світі заклади вищої освіти (ЗВО) активно
переходять до цифрових форматів роботи. Збільшується кількість курсів в онлайн
режимі, електронних журналів, дистанційних пар і викладачам потрібно швидко
керувати навчальним процесом у будь-який момент. Це робить створення
мобільного застосунку для викладачів особливо актуальним.
Для цифровізації освіти університети впроваджують електронні системи
управління навчанням (LMS), але більшість із них орієнтовані на роботу з
комп’ютерами. Викладачам часто потрібен зручний мобільний інструмент для
оперативних дій.
Після пандемії багато процесів залишилися онлайн. Це створює потребу в
інструментах, які підтримують оперативний доступ до інформації в реальному часі.
Мета та задачі дослідження. Метою кваліфікаційної роботи магістра є
розробка та обґрунтування концепції мобільного застосунку «Викладач ЧДТУ»,
який забезпечує викладачів зручними інструментами для організації навчального
процесу, керування академічною діяльністю.
Основні задачі для досягнення поставленої мети:
 проаналізувати та дослідити предметну галузь, якою є освітня діяльність в
університеті;
 визначити постановку та обгрунтування проблеми;
 розробити концепцію проєкту, зокрема описати структуру продукту,
очікувані результати проєкту, життєвий цикл проєкту тощо;
 спланувати виконання проєкту;
 розробити базу даних та програмне забезпечення мобільного застосунку
«Викладач ЧДТУ»;
 впровадити мобільний застосунок «Викладач ЧДТУ».
Даний список задач допомагає створити цілісне усвідомлення процесу
управління проєктом, що сприяє забезпеченню якісної розробки, успішного
5
впровадження та довгострокового розвитку мобільного застосунку «Викладач
ЧДТУ».
Об’єктом дослідження є процес організації та управління навчальною
діяльністю викладача закладу вищої освіти в умовах цифровізації освітнього
середовища.
Дослідження орієнтоване на вивченні етапів створення продукту, визначенні
основних факторів успіху та аналізі підходів управління для забезпечення високої
якості та відповідності очікуванням викладачів.
Предметом дослідження є методи, засоби та програмні рішення для
підтримки й автоматизації роботи викладача через мобільний застосунок «Викладач
ЧДТУ».
Апробація результатів роботи. Основні положення і результати
кваліфікаційної роботи магістра доповідалися і були обговорені на конференції
«День студентської науки кафедри КНСА», 22 квітня 2025 року, Черкаси, Україна.
Публікації. В. О. Цибенко, Л. П. Оксамитна, Г. О. Заспа. Ініціація проєкту
створення мобільного застосунку «Викладач ЧДТУ»: Збірник тез доповідей
студентської науково-практичної конференції ЧДТУ : 22-23 квітня 2025 /
[упорядник Мельник І.В.]; Міністерство освіти і науки України, Черкаський
державний технологічний ун-т. Черкаси : ЧДТУ, 2025. С. 25.
Методи дослідження. У процесі роботи застосовуються такі методи:
теоретичний аналіз для дослідження предметної галузі, аналіз статистичних даних,
STEP-аналіз, SWOT-аналіз, календарне планування, моделювання архітектури
системи та інші інструменти дослідження і проєктного менеджменту.
Перелік ключових слів: МОБІЛЬНИЙ ЗАСТОСУНОК, ВИКЛАДАЧ, БАЗА
ДАНИХ.

6
ABSTRACT
Master's qualifying work includes: 87 p., 27 rites, 10 tabl., 28 sources used, 2
appendice.
Actuality of theme.
In the modern world, higher education institutions are actively moving to digital
formats of work. The number of online courses, electronic journals, distance pairs is
increasing, and teachers need to quickly manage the educational process at any time. This
makes the creation of a mobile application for teachers especially relevant.
To digitize education, universities are implementing electronic learning
management systems (LMS), but most of them are focused on working with computers.
Teachers often need a convenient mobile tool for operational actions.
After the pandemic, many processes remained online. This creates a need for tools
that support operational access to information in real time.
Research goal and objectives. The goal of this project is to develop and
substantiate the concept of the mobile application «Teacher of ChDTU», which provides
teachers with convenient tools for organizing the educational process, managing academic
activities.
The main tasks to achieve the goal:
 analyze and research the subject area, which is educational activities at the
university;
 formulate and justify the problem;
 develop a project concept, in particular, describe the product structure, expected
project results, project life cycle, etc.;
 plan the project implementation;
 develop a database and software for the mobile application «Teacher of ChDTU»;
 implement the mobile application «Teacher of ChDTU».
This list of tasks helps to create a holistic awareness of the project management
process, which contributes to ensuring high-quality development, successful
implementation and long-term development of the mobile application «Teacher of
ChSTU».
7
The object of the study is the process of organizing and managing the educational
activities of a teacher in a higher educational institution in the conditions of digitalization
of the educational environment.
The study is focused on studying the stages of product creation, identifying the main
success factors and analyzing management approaches to ensure high quality and
compliance with teachers' expectations.
The subject of the study is methods, tools and software solutions for supporting
and automating the work of a teacher through the mobile application «Teacher of
ChSTU».
Approbation of the results of the work. The main provisions and results of the
master's qualification work were reported and discussed at the conference «Day of Student
Science of the Department of KNSA», April 22, 2025, Cherkasy, Ukraine.
Publications. V. O. Tsybenko, L. P. Oksamytna, G. O. Zaspa,. Initiation of the
project to create a mobile application «Teacher of ChSTU»: Collection of abstracts of
reports of the student scientific and practical conference of the Cherkasy State Technical
University : April 22-23, 2025 / [compiler Melnyk I.V.]; Ministry of Education and
Science of Ukraine, Cherkasy State Technological University. Cherkasy : Cherkasy State
Technical University, 2025. P. 25.
The following methods are used in the work process: theoretical analysis for
researching the subject area, statistical data analysis, STEP analysis, SWOT analysis,
calendar planning, system architecture modeling, and other research and project
management tools.
List of keywords: MOBILE APPLICATION, TEACHER, DATABASE.

8
ЗМІСТ
ПЕРЕЛІК УМОВНИХ ПОЗНАЧЕНЬ, СИМВОЛІВ, СКОРОЧЕНЬ І
ТЕРМІНІВ.................................................................................................................10
ВСТУП.......................................................................................................................11
1 АНАЛІЗ ТА ДОСЛІДЖЕННЯ ПРЕДМЕТНОЇ ГАЛУЗІ....................................13
1.1 Системний аналіз об’єкту дослідження та предметної області ................13
1.2 Постановка та обгрунтування проблеми......................................................15
1.3 Пошук та опис аналогів.................................................................................22
Висновки до розділу 1..........................................................................................26
2 РОЗРОБКА КОНЦЕПЦІЇ ПРОЄКТУ..................................................................27
2.1 Первинні та вторинні зацікавлені сторони і аналіз їх впливу на проєкт..27
2.2 Цілі та задачі проєкту.....................................................................................29
2.3 Структура продукту проєкту.........................................................................30
2.4 Очікувані результати проєкту.......................................................................35
2.5 Життєвий цикл проєкту.................................................................................36
Висновки до розділу 2.........................................................................................39
3 ПЛАНУВАННЯ ПРОЄКТУ.................................................................................40
3.1 Планування змісту проєкту...........................................................................40
3.2 Планування часу проєкту (діаграма Ганта, сітьовий графік) ...................43
3.3 Планування трудових ресурсів проєкту (OBS, матриця відповідальності,
лист ресурсів) ...........................................................................................................45
3.4 Планування якості проєкту............................................................................48
3.5 Планування ризиків проєкту.........................................................................51
3.6 Планування бюджету проєкту.......................................................................55
3.7 Планування комунікацій у проєкті...............................................................59
Висновки до розділу 3..........................................................................................61
4 ПРАКТИЧНА РЕАЛІЗАЦІЯ ПРОДУКТУ ПРОЄКТУ.....................................62
4.1 Вибір технологій розробки............................................................................62
9
4.2 Організація командної роботи в проєкті......................................................66
4.3 Розробка бази даних та програмного забезпечення....................................70
4.3.1 Інтеграція мобільного застосунку в інформаційну систему
університету..............................................................................................................70
4.3.2 Структура бази даних та програмного забезпечення............................71
4.3.3 Тестування та впровадження мобільного застосунку «Викладач
ЧДТУ»........................................................................................................................74
Висновки до розділу 4..........................................................................................77
ВИСНОВКИ..............................................................................................................78
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ................................................................80
ДОДАТОК А. Специфікація 482. ЧДТУ. 52420-01................................................83
ДОДАТОК Б. Публікація по темі кваліфікаційної роботи магістра....................85

10
ПЕРЕЛІК УМОВНИХ ПОЗНАЧЕНЬ, СИМВОЛІВ, СКОРОЧЕНЬ І ТЕРМІНІВ
ЗВО – заклад вищої освіти;
ІАСПОДУ – Інформаційно-аналітична система підтримки освітньої діяльності
університету;
ЛНУ – Львівський національний університет;
ЧДТУ – Черкаський державний технологічний університет;
ІС – інформаційна система;
ПЗ – програмне забезпечення;
ЖЦ – життєвий цикл;
ТЗ – технічне завдання;
WBS – Work Breakdown Structure.
11
ВСТУП
Актуальність теми. У сучасному світі заклади вищої освіти активно
переходять до цифрових форматів роботи. Збільшується кількість курсів в онлайн
режимі, електронних журналів, дистанційних пар і викладачам потрібно швидко
керувати навчальним процесом у будь-який момент. Для цифровізації освіти
університети впроваджують електронні системи управління навчанням (LMS), але
більшість із них орієнтовані на роботу з комп’ютерами. Викладачам часто потрібен
зручний мобільний інструмент для оперативних дій.
У ЧДТУ використовується ІАСПОДУ (Інформаційно-аналітична система
підтримки освітньої діяльності університету), активними користувачами якої є
працівники деканатів, навчально-методичного відділу, приймальної комісії та
студенти. У системі є багато інформації, яка стосується роботи викладачів, але
немає програми, за допомогою якої викладачі могли б працювати з цією
інформацією. Тому розробка програми для викладачів у вигляді мобільного
застосунку є актуальною задачею.
Мета та задачі дослідження. Метою даної роботи є обґрунтування та
розробка проєкту з побудови мобільного застосунку «Викладач ЧДТУ», який
забезпечує викладачів зручними інструментами для організації навчального
процесу, керування академічною діяльністю.
Основні задачі для досягнення поставленої мети:
 проаналізувати та дослідити предметну галузь, якою є освітня діяльність в
університеті;
 визначити постановку та обгрунтування проблеми;
 розробити концепцію проєкту, зокрема описати структуру продукту,
очікувані результати проєкту, життєвий цикл проєкту тощо;
 спланувати виконання проєкту;
 розробити базу даних та програмне забезпечення мобільного застосунку
«Викладач ЧДТУ»;
12
 впровадити мобільний застосунок «Викладач ЧДТУ».
Даний список задач допомагає створити цілісне усвідомлення процесу
управління проєктом, що сприяє забезпеченню якісної розробки, успішного
впровадження та довгострокового розвитку мобільного застосунку «Викладач
ЧДТУ».
Об’єктом дослідження є процес навчальної діяльності викладача закладу
вищої освіти в умовах цифровізації освітнього середовища.
Предметом дослідження є методи, засоби та інструменти проєктного
менеджменту при побудові ІТ-продуктів у сфері вищої освіти.
Апробація результатів роботи. Основні положення і результати
кваліфікаційної роботи магістра доповідалися і були обговорені на конференції
«День студентської науки кафедри КНСА», 22 квітня 2025 року, Черкаси, Україна.
Публікації. В. О. Цибенко, Л. П. Оксамитна, Г. О. Заспа. Ініціація проєкту
створення мобільного застосунку «Викладач ЧДТУ»: Збірник тез доповідей
студентської науково-практичної конференції ЧДТУ : 22-23 квітня 2025 /
[упорядник Мельник І.В.]; Міністерство освіти і науки України, Черкаський
державний технологічний ун-т. Черкаси : ЧДТУ, 2025. С. 25.
13
1 АНАЛІЗ ТА ДОСЛІДЖЕННЯ ПРЕДМЕТНОЇ ГАЛУЗІ
1.1 Системний аналіз об’єкту дослідження та предметної області
Об’єкт дослідження – освітня діяльність в університеті. Предметна область –
університет.
Сучасний навчальний процес у закладах вищої освіти характеризується
значним обсягом інформації, великою кількістю студентів і навчальних дисциплін,
необхідністю ведення обліку відвідуваності, контролю знань, підготовки навчально-
методичних матеріалів, організації занять та підготовки звітності. Викладачеві
доводиться поєднувати освітню, наукову та адміністративну діяльність, що формує
високий рівень навантаження. У таких умовах виникає потреба в автоматизації
частини функцій, що дозволить зменшити рутинні витрати часу та підвищити
ефективність роботи.
Застосування системного аналізу в даній проблемній області є доцільним,
оскільки він дозволяє комплексно дослідити всі процеси діяльності викладача,
виявити взаємозв’язки між ними, визначити ключові проблемні ділянки та
побудувати узгоджену модель майбутньої інформаційної системи. Системний підхід
також забезпечує врахування зовнішніх обмежень і вимог, таких як навчальні плани,
стандарти Міністерства освіти і науки України, регламенти університету та технічні
ресурси.
Принципи системного аналізу в предметній області:
 цілісність – діяльність викладача розглядається як єдина система, що
включає навчальну, організаційну та комунікаційну складові;
 ієрархічність – виділяються рівні управління: університет → факультет →
кафедра → викладач → студент;
 множинність моделей – для повного опису системи застосовуються
функціональні, інформаційні, процесні та поведінкові моделі;
14
 взаємозв’язок із середовищем – система роботи викладача залежить від
зовнішніх факторів: адміністративних вимог, освітніх стандартів, технічної
інфраструктури;
 адаптивність – майбутня система автоматизації повинна враховувати зміни
у навчальних програмах, формах контролю та звітності тощо.
Тип проблеми. Проблема є складною, оскільки діяльність викладача охоплює
багато різнорідних функцій, частина з яких добре формалізована (наприклад,
виставлення оцінок), а інша – слабоформалізована (наприклад, комунікація зі
студентами чи підготовка навчальних матеріалів). Для її вирішення необхідне
використання системного підходу та різних типів моделей, які дозволяють
врахувати всі аспекти предметної області.
Список моделей, що передбачаються до розгляду:
 функціональні моделі (IDEF0) – для відображення основних процесів
роботи викладача;
 інформаційні моделі (ER-діаграми) – для структурування даних (студенти,
дисципліни, оцінки, навчальні матеріали);
 процесні моделі (BPMN, діаграми потоків) – для опису послідовності
виконання завдань (планування занять, проведення лекцій, перевірка робіт);
 моделі взаємодії (use-case UML) – для представлення ролей (викладач,
студент, адміністрація) та їхніх сценаріїв роботи із системою.
Інтерпретація основних понять системного аналізу в даній предметній галузі:
 система – інформаційна система, яка автоматизує діяльність викладача,
спрямовану на організацію та проведення навчального процесу;
 елементи системи – модулі, що виконують завдання викладача: підготовка
матеріалів, проведення занять, оцінювання, звітність, комунікація зі студентами;
 функції системи – забезпечення якісного навчання, контроль знань,
організація навчального процесу;
 оточення системи – адміністрація університету, студенти, навчальні плани,
вимоги законодавства, технічна інфраструктура (LMS, електронна пошта, бази
даних);
15
 вхідні ресурси – навчальні плани, розклад, методичні матеріали;
 вихідні результати – знання студентів, оцінки, звіти, навчальні продукти
(лекції, методичні посібники).
1.2 Постановка та обгрунтування проблеми
Сучасна система вищої освіти перебуває в умовах активної цифрової
трансформації, що вимагає від закладів вищої освіти впровадження інноваційних
рішень для оптимізації освітнього процесу та управління діяльністю викладачів.
Одним із ключових напрямів є розробка спеціалізованих мобільних застосунків, які
забезпечують інтерактивність, доступність та оперативність роботи в освітньому
середовищі.
Проблема полягає в тому, що існуючі програмні рішення переважно
орієнтовані на студентів або на загальні адміністративні процеси, тоді як
індивідуальні потреби викладачів залишаються недостатньо врахованими.
Відсутність зручного мобільного інструменту для планування занять, ведення
журналів, комунікації зі студентами та отримання актуальної інформації з
навчального процесу ускладнює ефективну організацію викладацької діяльності.
З наукової точки зору розробка такого застосунку дозволить поглибити
дослідження в сфері освітніх інформаційних технологій, цифровізації управлінських
процесів у вищій школі та розробки мобільних застосунків. Практична значущість
полягає в створенні зручного інструменту для викладачів університету, що
сприятиме підвищенню продуктивності їхньої роботи, покращенню якості
навчального процесу та налагодженню ефективної комунікації між учасниками
освітнього середовища.
Таким чином, розробка мобільного застосунку «Викладач університету» є
актуальною науковою та практичною задачею, адже вона поєднує потреби сучасної
освітньої практики з перспективами розвитку інформаційних технологій.
У Черкаському державному технологічному університеті з 2018 року працює
Інформаційно-аналітична система підтримки освітньої діяльності. Впродовж всього
16
часу свого існування дана система розширювалася та вдосконалювалася. На даний
час вона складається з п’яти окремих підсистем: інформаційно-аналітичної системи
деканатів та навчально-методичного відділу, мобільного застосунку «Студент
ЧДТУ+» з адміністративною частиною, інформаційною системою формування
юридичних документів для вступників, модуля отримання інформації студентів за
допомогою сервісів «Дії», модуля інтелектуального порівняння назв предметів.
Всього на даний час в рамках системи працюють та розробляється 9 програмних
проєктів.
Оскільки існуючі програмні рішення переважно орієнтовані на студентів або
на загальні адміністративні процеси, то певним недоліком системи є відсутність
засобів, які б інформатизували роботу викладачів. Цій частині приділялося
недостатньо уваги, в результаті чого, з одного боку викладачі не можуть
скористатися уже існуючою інформацією та існуючими програмними рішеннями, а
з іншого боку інформація, яку генерують викладачі, вводиться в систему непрямим
чином, що призводить до додаткової роботи та виникнення додаткових помилок.
Отже, метою роботи є розширення ІАСПОДУ шляхом побудови системи, яка
б дала можливість інформатизувати роботу викладачів. Частиною цього напрямку є
проєкт розробки мобільного застосунку «Викладач ЧДТУ», призначений для
надання викладачам зручного сервісу для отримання інформації та виконання дій,
які стосуються навчальної та організаційної роботи викладача.
Мобільний застосунок може бути використаний як частина ІАСПОДУ
Черкаського державного технологічного університету. Також його можна
використовувати в інших закладах вищої освіти за умови забезпечення сумісності
його серверної частини з іншими інформаційними підсистемами даного ЗВО.
Очікуваними ефектами від впровадження системи є:
 зменшення витрат часу викладачів на пошук інформації, що стосується
освітньої діяльності;
 зменшення кількості помилок введення інформації до ІАСПОДУ;
 зменшення витрат часу працівників інших підрозділів на введення
інформації;
17
 збільшення оперативності взаємодії викладачів з підрозділами університета.
Розроблення концептуальної моделі системи.
Розроблювана система передбачає інформатизацію декількох бізнес-процесів,
в яких задіяні викладачі університету.
1. Викладачі, предмети яких були обрані як вибіркові, викладають дані
предмети; при цьому викладачеві важливо знати інформацію про тих студентів, які
зареєстровані на його предмет. Схема бізнес-процесу вибору вибіркових дисциплін
показана на рисунку 1.1.

Рисунок 1.1 – Схема бізнес-процесу вибіркових дисциплін
2. Викладачі є керівниками кваліфікаційних робіт бакалаврів та магістрів; при
цьому викладачеві важливо знати інформацію про студентів, у яких викладач є
керівником теми кваліфікаційних робіт. Схема бізнес-процесу призначення
кваліфікаційних робіт показана на рисунку 1.2.
18

Рисунок 1.2 – Схема бізнес-процесу кваліфікаційних робіт
3. Викладачі можуть бути кураторами певних груп студентів; при цьому
викладач повинен мати список студентів для яких він є куратором та інформацію
про цих студентів. Схема бізнес-процесу призначення кураторства, яка показана на
рисунку 1.3.

Рисунок 1.3 – Схема бізнес-процесу кураторства

19
Вхідні дані системи.
Основним джерелом даних для системи є підсистема деканату та навчально-
методичного відділу ІАСПОДУ.
1. Інформація про викладачів:
 ПІБ викладача;
 науковий ступінь;
 вчене звання;
 кафедра.
2. Інформація про групи студентів:
 назва групи;
 спеціальність групи;
 освітня програма групи;
 рік створення групи;
 кількість років та семестрів навчання групи;
 форма навчання групи;
 список студентів групи;
 куратор.
3. Інформація про студентів:
 ПІБ студента;
 дата народження;
 бюджет чи контракт;
 номер заліковки;
 номер телефона;
 домашня адреса;
 назва кваліфікаційної роботи;
 оцінки.
4. Оцінки студента:
 назва предмету;
 семестр;
20
 форма контролю знань;
 викладач;
 кількість балів;
 оцінка за національною шкалою;
 оцінка за шкалою ECTS;
 вчасно чи не вчасно було здано.
Вихідні дані системи.
1. Список груп та студентів цих груп, в яких даний викладач є куратором:
 назва групи;
 спеціальність групи;
 освітня програма групи;
 рік створення групи;
 кількість років та семестрів навчання групи;
 форма навчання групи;
 список студентів групи.
2. Інформація про студентів:
 ПІБ студента;
 дата народження;
 бюджет чи контракт;
 номер заліковки;
 номер телефона;
 домашня адреса;
 назва кваліфікаційної роботи;
 оцінки.
3. Академічні заборгованості студентів, для яких даний викладач є куратором:
 назва групи;
 ПІБ студента;
 список предметів, з яких є заборгованість в даного студента.
4. Вибіркові дисципліни, які викладає даний викладач:
21
 назва дисципліни;
 семестр;
 кількість годин та тип контролю знань;
 тип дисципліни: загальна чи професійна;
 список студентів, які обрали дану дисципліну (ПІБ студента, факультет,
спеціальність, назва групи).
5. Кваліфікаційні роботи, у яких даний викладач є керівником:
 ступінь: бакалавр або магістр;
 тема роботи;
 студент (ПІБ, назва групи).
Опис функцій системи.
Мобільний застосунок матиме такі функції:
1. Авторизація в системі шляхом введення логіну та пароля;
2. Перегляд профілю викладача, в якому відображається інформація про
нього: ПІБ, науковий ступінь, вчене звання, факультет, кафедра;
3. Відображення списків студентів, які навчаються в академічних групах, в
яких даний викладач є куратором;
4. Відображення академічних заборгованостей студентів, які навчаються в
академічних групах, в яких даний викладач є куратором;
5. Виведення оцінок семестрового контролю з предметів, які викладає даний
викладач;
6. Відображення розкладу даного викладача;
7. Відображення тем кваліфікаційних робіт студентів, в яких викладач є
керівником;
8. Відображення списків студентів, які обрали вибіркові дисципліни, які
викладає даний викладач.
Опис структури системи.
Дана система складатиметься з двох частин: серверної (back-end) та
клієнтської (front-end). Клієнтська частина являтиме собою крос-платформний
мобільний застосунок, придатний для використання в операційних системах Android
22
та iOS. Крім того, дана система використовуватиме API підсистеми «Деканат»
ІАСПОДУ показано на рисунку 1.4.

Рисунок 1.4 – API підсистеми «Деканат» ІАСПОДУ
1.3 Пошук та опис аналогів
В Україні існує велика кількість інформаційних систем (ІС), які
автоматизують роботу в університеті, в тому числі роботу викладачів, яка
стосується організацій навчального процесу. В результаті пошуку переважно
знаходяться адміністративні та розкладні системи, наприклад:
 АСУ «Університет» – автоматизована система управління університетом
(розклад, облік навантаження, робочі плани);
 розклад НУБіП, КПІ, ЛНУ тощо – в багатьох ЗВО є власні автоматизовані
системи формування й публікації розкладу;
 ELearning-портали університетів – внутрішні ресурси для розміщення
методичних матеріалів і контролю навчального процесу;
 СумДУ: електронний журнал + індивідуальні плани викладачів + силабуси
курсів + модуль для оцінювання та звітності;
23
 ЛНУ «Політехніка»: інтеграція з Moodle для тестування й електронних
курсів, доступ до робочих програм дисциплін;
 Odoo (ERP-версії для освіти): модулі «Courses», «Students», «Exams»,
«Library», що дозволяють повністю управляти процесом викладання та оцінювання;
 Microsoft 365 Education + Teams: створення класів, завдань, електронних
журналів, проведення онлайн-лекцій, зберігання матеріалів у SharePoint/OneDrive.
Пошук вказує, що існує дуже багато систем, які дають можливість
переглядати розклад, а також працювати з функціями, близькими до розкладу,
наприклад обліковувати відвідування студентами занять або проставляти оцінки,
тощо.
Пошук серед мобільних застосунків показав, що існує велика кількість
застосунків для відображення розкладу, але інші функції, які можуть бути потрібні
викладачам представлені дуже рідко. Пошук застосунків для розкладу в Google Play
дає результат представлений на рисунку 1.5. Він демонструє, що існує багато
застосунків, як для відображення розкладу в комерційних освітніх системах, так і в
системах окремих університетів.

Рисунок 1.5 – Пошук застосунків для розкладу в Google Play
24
Прикладом такого застосунку є «АСУ ВНЗ», який працює з однойменною
інформаційною системою. На рисунку 1.6 показані скріншоти даного застосунку, в
яких відображається розклад.

Рисунок 1.6 – Застосунок «АСУ ВНЗ»
Серед застосунків, які мають більший функціонал, ніж розклад, варто
відзначити в «Мій НУВГП». У його описі в Google Play зазначено, зокрема,
можливість роботи з оцінками студентів, але інші функції не описуються (рис. 1.7).
25
Можемо зробити висновок, що мобільні застосунки для викладачів – це
область, досить слабко покрита в університетах України. Існує багато рішень для
розкладу, але інші функції реалізовані рідко в небагатьох застосунках.

Рисунок 1.7 – Застосунок «Мій НУВГП»
26
Висновки до розділу 1
У даному розділі було проведено системний аналіз об’єкту дослідження та
предметної області.
У якості об’єкту дослідження виділено освітню діяльність в університеті, а в
якості предметної області – університет.
Визначено постановку та обгрунтування проблеми, досліджено бізнес-
процеси, які стосуються проєкту розробки мобільного застосунку, описано очікувані
ефекти від впровадження застосунку.
Досліджено існуючі в даний час системи університету та їх потенційну
взаємодію із розроблюваним застосунком, а також вхідні та вихідні дані засосунку.
Здійснено пошук та проведено аналіз аналогів – знайдено кілька проєктів, які
можна назвати відносно аналогами, але за результатами було зроблено висновок, що
прямих аналогів на даний час не існує.

27
2 РОЗРОБКА КОНЦЕПЦІЇ ПРОЄКТУ
2.1 Первинні та вторинні зацікавлені сторони і аналіз їх впливу на проєкт
Зацікавлені сторони проєкту (учасники) – це окремі особи й організації,
залучені до проєкту, або ті, чиї інтереси можуть позитивно чи негативно вплинути
на результати виконання проєкту або на успішне його завершення [1].
Загалом виділяють такі категорії зацікавлених сторін, як:
 первинні зацікавлені сторони – ті, від кого залежить проєкт або хто може на
нього суттєвим чином вплинути, від кого суттєво залежить його успіх, або навпаки,
ті особи, групи чи організації, які відчують на собі результати успішного чи не
успішного виконання проєкту;
 вторинні зацікавлені сторони – це всі інші особи чи організації, які мають
чи можуть мати непрямий інтерес до проєкту чи певну роль у його проєктуванні чи
реалізації.
Межа між типами зацікавлених сторін не завжди є чіткою, тобто певна особа
чи організація можуть мати як характеристики первинної, так і вторинної
зацікавленої сторони. Важливим кроком на етапі підготовки проєкту є складання
списку всіх зацікавлених у проєктуванні та реалізації проєкту. Важливо
проаналізувати і визначити, хто ті люди, організації чи групи, які можуть
скористатися успішною реалізацією проєкту чи окремих його складових. Потрібно
урахувати думки всіх, кого зачепить реалізація та впровадження проєкту [2].
До первинних зацікавлених сторін за визначенням відносяться замовник
проєкту та команда, яка його реалізує. У цьому випадку замовником є університет, а
командою реалізації проєкту є команда студентів та викладачів. Крім того,
первинною зацікавленою стороною є викладачі університету, які користуватимуться
розробленим програмним забезпеченням.
Первинні зацікавлені сторони зображено в таблиці 2.1

28
Таблиця 2.1 – Первинні зацікавлені сторони
Первинні зацікавлені сторони Роль і вплив на проєкт
Керівник (менеджер) проєкту. Відповідає за всі частини та аспекти
проєкту. Вміння, навички та мотивація
менеджера проєкту безпосередньо
впливає на результат.
Розробники проєкту (студенти та Відповідають за розробку, впровадження
викладачі). та розвиток мобільного застосунку.
Вміння, навички та мотивація
розробників проєкту безпосередньо
впливають на результат.
Користувачі (викладачі Беруть участь у визначенні потрібних
університету). функцій застосунку та інтерфейсу
застосунка. Впливають на набір функцій
та інтерфейс застосунку.
Керівництво університету. Визначає часовий інтервал розробки і
впровадження застосунка. Можуть
впливати на організаційні рішення та
шлях розвитку мобільного застосунку.
Можуть матеріально стимулювати
розробників проєкту.

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

29
Таблиця 2.2 – Вторинні зацікавлені сторони
Вторинні зацікавлені Роль і вплив на проєкт
сторони
Студенти. Можуть отримувати інформацію, введену
через мобільний застосунок та скористатись
меншою кількістю помилок викладача.
Впливу на проєкт не мають.
Міністерство освіти та науки Зацікавлене в поглибленні інформатизації
України. університетів. Впливу на проєкт не мають.
Підрозділи університету, такі, Діляться своєю інформацією з викладачами;
як деканати і навчально- отримують інформацію від викладача.
методичний відділ. Консультують учасників проєкту з
інформаційних та організаційних питань.
2.2 Цілі та задачі проєкту
Діяльність університету концентрується на роботі зі студентами та наукових
дослідженнях. Метою університету в сфері роботи зі студентами є навчання, а також
виховання студентів, їх фізичний, інтелектуальний та творчий розвиток. Дерево
цілей університету зображено на рисунку 2.1, при цьому виділено задачі, які
стосуються сфери мобільного застосунку «Викладач ЧДТУ».

Рисунок 2.1 – Дерево цілей організації
30
Місія проєкту: зробити роботу викладача більш ефективною за рахунок
використання сучасних інформаційних технологій та сприяти цифровій
трансформації освіти.
Цілі проєкту.
Короткострокові цілі:
1. Спростити доступ викладача до деякої інформації, яку він використовує в
своїй діяльності, що стосується навчання;
2. Спростити введення деякої навчальної інформації в інформаційну систему
університету.
Довгострокові цілі:
1. На основі мобільного застосунку розбудувати повноцінну інформаційну
систему підтримки освітньої діяльності викладача університету.
Задачі проєкту:
1. Розробити серверну частину для мобільного застосунку «Викладач ЧДТУ»,
яка інтегрована з іншими інформаційними системами університету;
2. Розробити крос-платформний мобільний застосунок «Викладач ЧДТУ»;
3. Встановити серверну частину на сервері університету; опублікувати
мобільний застосунок в Google Play та App Store;
4. Впровадити мобільний застосунок;
5. Здійснювати підтримку мобільного застосунку і на його основі
розбудовувати новий функціонал для автоматизації освітньої діяльності
викладача.
2.3 Структура продукту проєкту
Продуктом даного проєкту є розроблений мобільний застосунок, який
включає в себе: базу даних, серверну частину та клієнтську частину у вигляді
безпеосередньо крос-платформного мобільного застосунку (рис. 2.2).
31

Рисунок 2.2 – Загальна структура продукту проєкту
Сам безпосередньо мобільний застосунок складається з модулів, які можна
розділити на три частини: функціональні, технічного характеру та загального
користування.
Один функціональний модуль реалізує одну функцію застосунку. У програмі є
наступні функціональні модулі.
1. Модуль перегляду профілю викладача. Його задачею є відображення
інформації про викладача, а саме: ПІБ, науковий ступінь, вчене звання, посада,
факультет, кафедра. Модуль складається з контролера (у вигляді flutter bloc
елементу з класами станів та подій), репозиторію для отримання інформації про
викладача з сервера та віджету для відображення інформації;
2. Модуль відображення списків студентів, які навчаються в академічних
групах, в яких даний викладач є куратором. Його задачею є відображення списка
груп, в яких викладач є куратором та списків студентів, що навчаються в кожній з
цих груп. Модуль складається з контролера (у вигляді flutter bloc елементу з класами
станів та подій), репозиторію для отримання інформації про студентів потрібних
груп з сервера та віджету для відображення інформації;
32
3. Модуль відображення академічних заборгованостей студентів, які
навчаються в академічних групах, в яких даний викладач є куратором. Його задачею
є відображення предметів, семестровий контроль з яких не склали студенти, які
навчаються в академічних групах, в яких даний викладач є куратором. Модуль
складається з контролера (у вигляді flutter bloc елементу з класами станів та подій),
репозиторію для отримання інформації про академічні заборгованості з сервера та
віджету для відображення інформації;
4. Модуль введення оцінок семестрового контролю з предметів, які викладає
даний викладач. Його задачею є відображення форм для предметів, за якими у
даного викладача є семестровий контроль з можливістю введення оцінок з предметів
семестрового контролю для студентів, які проходять даний семестровий контроль.
При цьому оцінки повинні зберігатися в базі даних деканату. Модуль складається з
контролера (у вигляді flutter bloc елементу з класами станів та подій), репозиторію
для отримання інформації про список предметів даного викладача, з яких є
семестровий контроль, з сервера та репозиторію для збереження введених оцінок, а
також віджетів для відображення форми та інформації після збереження оцінок;
5. Модуль відображення розкладу даного викладача. Його задачею є
відображення розкладу в зручному для викладача вигляді: за замовчуванням
повинен відображатися розклад саме даного викладача з поточної дати на місяць
вперед; але є й інші можливості для відображення розкладу. Модуль складається з
контролера (у вигляді flutter bloc елементу з класами станів та подій), репозиторію
для отримання інформації про розклад з сервера та віджету для відображення
інформації;
6. Модуль відображення тем кваліфікаційних робіт, в яких викладач є
керівником. Його задачею є відображення списків тем кваліфікаційних робіт в яких
викладач є керівником. Модуль складається з контролера (у вигляді flutter bloc
елементу з класами станів та подій), репозиторію для отримання інформації про
студентів та теми їх кваліфікаційних робіт з сервера та віджету для відображення
інформації;
33
7. Модуль відображення списків студентів, які обрали вибіркові дисципліни,
які викладає даний викладач. Його задачею є відображення вибіркових дисциплін
та списків студентів, які обрали дані вибіркові дисципліни, які викладає даний
викладач. Модуль складається з контролера (у вигляді flutter bloc елементу з
класами станів та подій), репозиторію для отримання інформації про вибіркові
дисципліни даного викладача та студентів, що обрали ці дисципліни з сервера та
віджету для відображення інформації.
У програмі є наступні технічні модулі (такі, функції яких не складають бізнес-
логіку саме даного застосунку, але потрібні для його функціонування).
1. Модуль авторизації в системі шляхом введення логіну та пароля. Його
задачею є забезпечення можливості користувачеві авторизуватися в системі шляхом
введення логіна та пароля і після цього мати доступ до функцій системи.
Модуль складається з:
 контролера логіна (у вигляді flutter bloc елементу з класами станів та подій),
репозиторію для надсилання інформації про логін та пароль та отримання JWT-
токена з сервера та віджету для відображення інформації;
 контролера аутентифікації (у вигляді flutter bloc елементу з класами станів
та подій) та репозиторію для правильного формування запитів до сервера.
У програмі є наступні модулі загального користування (такі, які можуть
використовуватися в рамках багатьох функціональних модулів).
1. Модуль модальних вікон. Його задачею є забезпечення можливості
використання різноманітних модальних вікон для показу діалогів підтверджень,
повідомлень про помилку, простих повідомлень тощо на різних функціональних
екранах. Модуль складається з класів віджентів, які реалізують потрібний
функціонал;
2. Модуль утиліт. Його задачею є забезпечення інших модулів функціями, які
виконують утилітні задачі. Модуль складається з класу утиліт, в якому є набір static
методів;
3. Модуль візуальних блоків. Його задачею є забезпечення інших модулів
віджетами багаторазового використання, які можуть використовуватися, в тому
34
числі на екранах в різних функціях. Модуль складається з класів віджентів, які
реалізують потрібний функціонал;
4. Модуль ресурсів (assets). Його задачею є забезпечення інших модулів не
програмними ресурсами, наприклад графічними зображеннями. Він складається з
ресурсних файлів, зокрема, графічних зображень, кольорів, рядків, стилів (рис. 2.3).

Рисунок 2.3 – Структура продукту проєкта
Важливою особливістю мобільного застосунку «Викладач ЧДТУ» є його
інтегрованість в Інформаційно-аналітичну систему підтримки освітньої діяльності
університету, зокрема інтегрованість з системою «Деканат». Тому, в рамках роботи
над мобільним застосунком потрібно вносити зміни в систему «Деканат» (дана
система повинна надавати API для виконання функцій, потрібних мобільному
застосунку).
У системі «Деканат» міститься та обробляється інформація про викладачів,
предмети, студентів, тощо, яка якраз потрібна в мобільному застосунку. Деяка
інформація, потрібна в мобільному застосунку, на даний час відсутня, тому її та
модулі роботи з неї потрібно додати в ході роботи над мобільним застосунком.
В ІАСПОДУ є також можливість переглядати розклад, отримуючи дані з
серверної частини мобільного застосунку «Студент ЧДТУ+». Тому, для
35
відображення розкладу потрібно інтегрувати системи мобільного застосунку
«Викладач ЧДТУ» та мобільного застосунку «Студент ЧДТУ+».
2.4 Очікувані результати проєкту
Очікуваним результатом даного проєкту є перевірений робочий застосунок,
викладений в Google Play та App Store і готовий до встановлення користувачами на
свої пристрої та використання.
Артефактами результату проєкту є:
1. Крос-платформний мобільний застосунок, розроблений на основі технології
Flutter, придатний для використання на платформах Google та iOS, що включає всі
вищезазначені функції;
2. Серверна частина, розроблена на основі технологій Node.js та NestJS, що
включає підтримку всіх вищезазначених функцій, яка має REST API, що може
використовуватися мобільним застосунком;
3. База даних, з якою працює серверна частина. База даних на початку роботи
програми повинна бути заповнена коректними довідниковими даними;
4. Зміни до серверної частини інформаційної системи деканатів та навчально-
методичного відділу, які надають необхідний для мобільного застосунку «Викладач
ЧДТУ» сервіси;
5. Зміни до бази даних інформаційної системи деканатів та навчально-
методичного відділу, які надають підтримку необхідним для мобільного застосунку
«Викладач ЧДТУ» сервісам;
6. Репозиторії мобільної та серверної частин на сервері github.com, що
зберігають версії та документацію розробленого програмного забезпечення;
7. Інструкція користувачеві про використання мобільного застосунку «Викладач
ЧДТУ»;
8. Пояснювальна записка, в якій описано проєкт розробки мобільного застосунку
«Викладач ЧДТУ», а саме: аналіз аналогів, системний аналіз предметної галузі,
аналіз організації, аналіз оточення проєкту, розробка концепції проєкту, розробка
36
безпосередньо самого проєкту, включно з моделюванням, плануванням тощо, опис
практичної реалізації проєкту.
2.5 Життєвий цикл проєкту
Життєвий цикл проєкту (ЖЦ) – це період часу від задуму проєкту до його
закінчення, який може характеризуватися часом здійснення перших витрат за
проєктом (поява проєкту) і отриманням останньої вигоди (ліквідація проєкту).
Життєвий цикл проєкту [3] – концепція, відповідно до якої проєкт
розглядається як послідовність фаз, подій та етапів, кожна з яких має свою назву та
часові межі.
Життєвий цикл є важливою концепцією для кожного проєкту. Стандартними
фазами життєвого циклу IT-проєкту є: виникнення ідеї, постановка завдання
(вироблення вимог), планування, проєктування, розробка, тестування, впровадження
та підтримка.
Життєвий цикл даного проєкту описаний в таблиці 2.3.
Таблиця 2.3 – Життєвий цикл проєкту
Фаза життєвого Мета фази Завдання Опис фази
циклу фази
1. Ідея Сформулювати - формулю- Ідея виникає з
ідею з вання ідеї; усвідомлення певної
підтвердженням - валідація проблеми. У ЧДТУ є
її доцільності ідеї; потреба в
- оцінка інформатизації
досяжності навчальної діяльності
ідеї. викладачів. Валідація
проходить через
спілкування з
потенційно
зацікавленими
особами, зокрема
викладачами та
керівництвом
університету.
Досяжність оцінюється
на основі наяввності
команди, що може
37
здійснити реалізацію
проєкту з оцінкою
спроможностей як
кожного члена команди
так і команди вцілому.
2. Планування Розробити - планування Планування
детальний план змісту відбувається з
і графік проєкту проєкту; використанням MS
- планування Project.
часу проєкту
(діаграма
Ганта,
сітьовий
графік);
- планування
трудових
ресурсів
проєкту
(OBS,
матриця
відповідаль-
ності, лист
ресурсів);
- планування
якості
проєкту;
- планування
ризиків
проєкту;
- планування
бюджету
проєкту;
- планування
комунікацій у
проєкті.
3. Проєктування Створити - оцінка Дана система
архітектурний середовища, в працюватиме як
проєкт системи якому частина Інформаційно-
працюватиме аналітичної системи
система; підтримки освітньої
- розробка діяльності
архітектури університету. Вона в
серверної значній мірі залежить
частини; від існуючих систем.
- розробка Архітектура даної
38
архітектури системи залежить з
мобільної одного боку від
частини. технологій реалізацій, а
з іншого боку від
організації взаємодії з
іншими системами.
4. Розробка та Створити - розробка MVP включатиме в
тестування MVP базову версію MVP з себе три функції, а
системи для початковими саме логін,
початкового функціями; відображення профілю
тестування - встановлен- користувача та
ня серверної перегляд списків
частини на студентів груп, в яких
сервері та викладач є куратором.
мобільної Серверна частина
частини в встановлюватиметься
Google Play; на Production-сервері і
- підключен- тестуватиметься на
ня декількох основі реальних даних.
користувачів Для тестування
для використовуватиметься
тестування. версія мобільного
застосунку тільки для
Android.
5. Розробка та Створити повну - розробка Серверна частина
тестування версію системи застосунку з встановлюватиметься
повнофункціонального для всебічного всіма на Production-сервері і
застосунку тестування функціями; тестуватиметься на
- встановлен- основі реальних даних.
ня серверної Потрібно забезпечити
частини на інтеграцію з
сервері та інформаційною
мобільної систетою деканатів.
частини в Для тестування
Google Play та використовуватимуться
App Store; версії мобільного
- підключен- застосунку для Android
ня декількох та iOS. Група
десятків викладачів кількістю
користувачів до 20 осіб братимуть
для участь у тестуванні.
тестування. Для тестування
потрібно підготувати
дані в базі даних.
6. Впровадження та Забезпечити - налаштува- Впровадження вимагає
39
підтримка можливість ти на сервері додавання та
користування серверну упорядкування даних
мобільним частину, не тільки в базі даних
застосунком включно з мобільного застосунка,
всім наповненням а і в базі даних
викладачам бази даних деканату. Якщо раніше
університету. всіма застосунок
потрібними завантажувався в
даними; Google Play в
- завантажити тестовому режимі, то
мобільний тепер він
застосунок в завантажується в
Google Play та Google Play та App
App Store для Store в режимі
широкого використання. Дані для
користування; входу та інструкцію всі
- розіслати викладачі повинні
всім отримати на
викладачам електоронну пошту.
дані для Команда розробників
входу та отримує відгуки від
інструкцію користувачів
користування; електронною поштою,
- збирати через месенджери та
відгуки шляхом
користувачів безпосереднього
та спілкування і
покращувати виправляє помилки та
застосунок. вносить покращення в
наступних версіях.
Висновки до розділу 2
У ході виконання роботи було проведено підготовчі дії до подальшого
планування та реалізації проєкту. Були визначені первинні та вторинні зацікавлені
сторони, проведено аналіз їх впливу на проєкт. Визначені цілі та задачі проєкту,
структура продукту проєкту, очікувані результати проєкту. Описано життєвий цикл
проєкту, який складається із стадій: ідея, планування, проєктування, розробка та
тестування MVP, розробка та тестування повнофункціонального застосунку,
впровадження та підтримка.
40
3 ПЛАНУВАННЯ ПРОЄКТУ
Інструментом, що використовується в даному проєкті для підтримки
планування, є Microsoft Project [4]. Він надає потужні та водночас прості засоби
керування, щоб планувати, контролювати й виконувати роботу над проєктами
різного масштабу [5]. Microsoft Project дає можливість описувати та планувати етапи
проєкту, трудові та матеріальні ресурси, задачі тощо, візуалізуючи потрібні речі у
вигляді діаграм, наприклад діаграми Ганта, графіку ресурсів тощо (рисунок 3.1).

Рисунок 3.1 – Вікно MS Project: планування проєкту розробки мобільного
застосунку «Викладач ЧДТУ»
3.1 Планування змісту проєкту
Планування змісту проєкту – це процес, під час якого визначають, що саме
потрібно зробити в межах проєкту, які будуть його результати, а також що входить,
а що не входить у його рамки [6].
Чітке визначення змісту дуже важливе, тому що:
 допомагає узгодити очікування між замовником і виконавцями;
 дає основу для планування часу, грошей і ресурсів;
41
 запобігає появі зайвих робіт, які не були передбачені (це називають
«повзучим змістом»).
Основні етапи планування змісту [7]:
1. Визначення цілей і завдань – формулюють, що саме потрібно досягти і які
результати очікуються;
2. Визначення меж проєкту – уточнюють, які роботи входять у зміст, а які ні;
3. Розбиття змісту на частини (декомпозиція) – ділять великий обсяг робіт на
менші, щоб ними легше було керувати;
4. Узгодження змісту – обговорюють і погоджують зміст із усіма
зацікавленими сторонами (замовником, командою тощо);
5. Підготовка документа «План змісту проєкту» – описують усі заплановані
результати, межі, припущення й обмеження;
6. Затвердження плану – офіційно підтверджують зміст і передають його
команді для виконання.
Інструменти планування змісту.
WBS (Work Breakdown Structure) – структура розбиття робіт, яка допомагає
розкласти проєкт на дрібніші частини, щоб краще бачити обсяг робіт і керувати
ними.
Заява про зміст проєкту (Project Scope Statement) – документ, у якому описано,
що саме входить до проєкту, які результати очікуються, які припущення й
обмеження існують.
Матриця відповідальності (RACI) – таблиця, де вказано, хто відповідає за
виконання кожного завдання.
Оцінювання робіт – визначення, скільки часу, коштів і ресурсів потрібно для
виконання кожного елемента проєкту.
Зв’язок зі строками, ресурсами та бюджетом. План змісту тісно пов’язаний із
планом строків, ресурсів і бюджету. Якщо зміст проєкту визначено неточно, то
календарний план і бюджет також будуть ненадійними.
42
Після створення структури робіт (WBS) можна оцінити, скільки часу й
ресурсів потрібно для кожного елемента, і таким чином узгодити зміст із загальним
планом і кошторисом.
Межі, припущення та зміни в змісті. У плані змісту обов’язково потрібно
вказати: межі – що не входить у проєкт; припущення – які умови вважаються
правильними без додаткових доказів. Це допомагає уникнути непорозумінь між
учасниками [8].
Якщо в процесі реалізації з’являються нові завдання або зміни, вони мають
бути зареєстровані, оцінені (як це вплине на час, бюджет і якість) та офіційно
затверджені.
Контроль і управління виконанням. Після затвердження план змісту
використовується для контролю проєкту [9]. Перевіряють, чи збігаються фактичні
результати з плановими. Виявляють відхилення – наприклад, роботи, які не були
заплановані. За потреби вносять корективи, якщо зміст проєкту змінився або
розширився без узгодження. WBS схема проєкту розробки мобільного застосунку
зображена на рисунку 3.2.

Рисунок 3.2 – WBS схема проєкту розробки мобільного застосунку
«Викладач ЧДТУ»
43
3.2 Планування часу проєкту (діаграма Ганта, сітьовий графік)
Планування часу – це процес визначення, коли саме потрібно виконати
завдання проєкту, у які терміни завершити етапи та коли закінчиться весь проєкт
[10]. Це важливо, бо дозволяє координувати роботу команди, розподіляти ресурси та
контролювати строки.
Без чіткого плану часу навіть добре продуманий проєкт може затриматися або
перевищити бюджет.
Візуальні інструменти планування.
1. Діаграма Ганта. Це таблиця, де: по вертикалі вказані завдання проєкту, а по
горизонталі – часова шкала.
Кожне завдання позначається смугою, яка показує тривалість роботи, дати
початку й завершення. Між завданнями можуть бути залежності (що треба зробити
спочатку, а що – після).
Цей інструмент допомагає швидко побачити:
 які завдання зараз виконуються;
 що вже завершено;
 де можуть бути затримки.
Недолік – діаграма не завжди добре показує логічні зв’язки між завданнями.
2. Сітьовий графік: показує логіку виконання завдань: що за чим робиться, які
роботи можна виконувати одночасно, а які – послідовно.
Основні поняття: вузли або стрілки – це завдання або зв’язки між ними.
Типи залежностей:
 Finish-to-Start: одне завдання закінчується, і починається інше; Start-to-Start,
Finish-to-Finish тощо;
 запас часу (float): скільки завдання може затриматись без шкоди для всього
проєкту;
 критичний шлях: найважливіша послідовність робіт, що визначає загальний
термін завершення проєкту.
Основні етапи планування часу:
44
 визначення завдань: створення повного списку робіт;
 оцінка тривалості: визначення, скільки часу потрібно на кожне завдання;
 визначення залежностей: які роботи виконуються раніше, а які –
паралельно;
 побудова сітьового графіка: логічна послідовність робіт;
 створення діаграми Ганта: візуальний графік строків;
 визначення контрольних точок і резервів часу;
 затвердження графіка та його постійний контроль.
План часу пов’язаний із ресурсами, бюджетом і змістом проєкту.
Якщо строки визначені неточно – це може призвести до перевитрат ресурсів
або перенавантаження команди.
Наприклад, знаючи, коли виконуються певні завдання, можна точно
розрахувати, коли потрібні ресурси і яка їхня вартість, узгоджуючи графік із
бюджетом.
Можливі труднощі та корекція графіка:
 затримки на критичному шляху – впливають на весь проєкт;
 «повзучі строки» – коли додаються нові завдання без зміни плану;
– оптимізація графіка:
 Crashing – прискорення виконання за рахунок додаткових ресурсів;
 Fast-tracking – виконання завдань паралельно;
 постійний моніторинг – графік потрібно оновлювати за фактичним
станом.
Значення для проєкту. Для проєкту, де ресурси обмежені, а час критичний,
планування часу – життєво важливе.
Діаграма Ганта допомагає бачити загальну картину, а сітьовий графік –
залежності та ризики.
Комбінація цих інструментів дає можливість ефективно розподіляти ресурси,
ставити пріоритети і швидше досягати цілей. Також важливо передбачати резерв
часу для непередбачених змін. OBS схема проєкту розробки мобільного застосунку
зображено на рисунку 3.3.
45

Рисунок 3.3 – OBS схема проєкту розробки мобільного застосунку
«Викладач ЧДТУ»
3.3 Планування трудових ресурсів проєкту (OBS, матриця
відповідальності, лист ресурсів)
Планування трудових ресурсів – це процес визначення, які люди, з якими
навичками, ролями та обсягом зайнятості потрібні для виконання проєкту, як вони
організовані та хто за що відповідає [11]. Це одна з найважливіших частин
управління проєктом, адже саме людський фактор є ключовим для успішного
виконання завдань.
Якщо ресурси не заплановані чітко (ролі, навички, навантаження), виникають
ризики затримок, перевантаження команди, перевищення бюджету чи зниження
якості результатів.
Основні інструменти планування трудових ресурсів.
1. Організаційна структура проєкту OBS – це ієрархічна структура, яка
показує, як організовані люди або підрозділи, що беруть участь у проєкті, і хто кому
підпорядковується.
Вона допомагає:
 чітко бачити відповідальність кожного члена команди;
46
 поєднати завдання з виконавцями;
 поліпшити комунікацію між учасниками.
Для стартапів OBS корисна тим, що навіть у невеликій команді вона
забезпечує прозорість і зрозумілий розподіл обов’язків.
2. Матриця відповідальності (RACI / Responsibility Assignment Matrix).
RACI-матриця – це таблиця, яка показує, хто: Responsible (виконує),
Accountable (відповідає), Consulted (консультується), Informed (поінформований).
Цей інструмент дозволяє уникнути плутанини у ролях, дублювання чи
“провалів” у виконанні завдань.
Для стартапів RACI особливо корисна, коли команда невелика і члени мають
кілька ролей.
3. Лист ресурсів (Resource List). Це документ або таблиця, де зазначено:
 імена або ролі членів команди;
 їхні навички, кваліфікацію;
 рівень зайнятості (повна, часткова);
 тривалість участі;
 орієнтовну вартість роботи.
Такий перелік допомагає менеджеру контролювати доступність людей,
уникати перевантаження і правильно розподіляти бюджет.
Етапи планування трудових ресурсів:
1. Визначення потреб – за планом змісту і графіком визначають, які
спеціалісти потрібні;
2. Розробка OBS – будують структуру підпорядкування та відповідальності;
3. Створення RACI-матриці – розподіляють ролі по завданнях;
4. Формування листа ресурсів – фіксують конкретних людей, навички,
періоди роботи;
5. Узгодження плану – затвердження у керівництва або замовника;
6. Контроль і коригування – постійний моніторинг, оновлення плану за
змінами в команді.
47
Взаємозв’язок з іншими складовими проєкту. План трудових ресурсів тісно
пов’язаний з:
 планом змісту (що треба зробити – хто робить);
 планом часу (коли потрібні ресурси);
 планом бюджету (скільки коштують ресурси).
Без узгодження цих планів виникають перевантаження або затримки.
Основні проблеми і рішення:
1. Перевантаження – вирішується перерозподілом ролей або залученням
додаткових людей;
2. Невизначеність ролей – усувається створенням RACI;
3. Зміни у складі команди – потребують оновлення листа ресурсів;
4. Непередбачені обставини – бажано мати резерв або запасні варіанти;
5. Регулярний перегляд плану дозволяє підтримувати ефективність команди та
стабільність проєкту.
Матриця відповідальностей проєкту розробки мобільного застосунку
«Викладач ЧДТУ» зображена на рисунку 3.4.

Рисунок 3.4 – Матриця відповідальностей проєкту розробки мобільного застосунку
«Викладач ЧДТУ»

48
3.4 Планування якості проєкту
Планування якості за PMBOK (PMBOK Guide – Project Management Body of
Knowledge) – це процес, який визначає стандарти якості, вимоги та методи,
необхідні для того, щоб забезпечити відповідність результатів проєкту очікуванням
замовника та зацікавлених сторін.
Згідно з Посібником до вступу знань з управління проєктами (PMBOK®
Guide), планування якості – це процес, який передбачає ідентифікацію вимог і
стандартів якості для проєкту та його результатів, а також визначення того, як вони
будуть виконуватися. Результатом цього процесу є План управління якістю –
документ, що описує, як політики та процедури організації будуть впроваджуватися
для досягнення цілей щодо якості.
Вхідні дані для планування якості.
Для ефективного планування якості потрібні такі вхідні дані:
 план управління проєктом. Надає загальну інформацію про проєкт, яка
допомагає в розробці плану управління якістю;
 реєстр зацікавлених сторін. Дозволяє зрозуміти очікування та потреби
сторін щодо якості, щоб перетворити їх на конкретні вимоги до продукту;
 базовий план змісту. Містить опис обсягу робіт, ієрархічну структуру робіт
(WBS) та словник WBS, які допомагають у визначенні результатів проєкту та вимог
до якості;
 реєстр ризиків. Надає інформацію про ризики, пов'язані з якістю, які
потрібно врахувати під час планування;
 корпоративні організаційні активи. Сюди входять політики, процедури та
інструкції щодо якості, а також історична інформація з попередніх проєктів;
 фактори середовища підприємства. До них належать урядові або галузеві
стандарти, правила та норми, які можуть впливати на якість проєкту.
Інструменти та методи для планування якості.
PMBOK Guide пропонує такі інструменти та методи для розробки плану
управління якістю:
49
 аналіз витрат і вигод. Порівняння витрат на якість із потенційною вигодою
від досягнення цієї якості;
 вартість якості (Cost of Quality, CoQ). Аналіз усіх витрат, понесених для
запобігання, оцінки та виправлення невідповідностей у проєкті;
 сім основних інструментів якості. Група простих, але ефективних
інструментів, що допомагають аналізувати та контролювати якість;
 діаграми потоків. Візуалізація послідовності кроків, що допомагає виявити
потенційні проблеми з якістю;
 бенчмаркінг. Порівняння практик і продуктивності проєкту з іншими
подібними проєктами, щоб виявити сфери для поліпшення.
Результатом процесу планування якості є План управління якістю, який
включає:
 стандарти якості, які використовуватимуться в проєкті;
 заходи контролю якості та забезпечення якості, заплановані для проєкту;
 ролі та обов'язки, пов'язані з якістю;
 вимірювання якості (метрики), які відстежуватимуться;
 процедури усунення невідповідностей, виявлених під час контролю якості;
 процедури постійного вдосконалення;
 план оновлення плану управління проєктом.
Аналіз вимог до якості з боку різних зацікавлених сторін дає можливість
сформувати відповідності, представлені в таблиці 3.1.
Таблиця 3.1 – Вимоги до якості проєкту з боку зацікавлених сторін
Зацікавлена сторона Вимоги до якості Опис вимог
Керівник (менеджер) Надійність роботи. Менеджер проєкту
проєкту Продуктивність відповідає за всі аспекти
(швидкість) роботи. якості, відповідно, він
Коректна обробка повинен організувати
помилок. процеси забезпечення
Зручність використання, якості.
якісний інтерфейс
користувача.
Якісна підтримка.
Розробники проєкту Надійність роботи. Команда розробників
(студенти та викладачі) Продуктивність відповідає за всі технічні
50
(швидкість) роботи. аспекти. Вона повинна
Коректна обробка забезпечити як
помилок. користувацьку, так і
Зручність використання, внутрішню якість
якісний інтерфейс розробленого програмного
користувача. та інформаційного
Якісна підтримка. забезпечення.
Висока якість коду.
Якісна структура бази
даних.
Користувачі (викладачі Надійність роботи. Користувачі зацікавлені в
університету) Продуктивність надійній, зручній у
(швидкість) роботи. використанні роботі
Коректна обробка застосунку, який
помилок. працюватиме без
Зручність використання, невиправдених затримок.
якісний інтерфейс Задоволеність користувача
користувача. є основним критерієм
Якісна підтримка. якості продукту.
Керівництво Надійність роботи. Керівництво університету
університету Продуктивність зацікавлене в якості
(швидкість) роботи. застосунку – це дасть
Коректна обробка можливість зробити роботу
помилок. викладачів більш
Зручність використання, продуктивною, вирішувати
якісний інтерфейс інформаційні задачі
користувача. швидше та точніше.
Якісна підтримка.
Студенти Надійність роботи. Студенти зацікавлені у
оперативному введенні та
виведенні інформації, що
стосується них.
Міністерство освіти та Надійність роботи. Міністерство освіти та
науки України. науки України зацікавлено
в збільшенні
продуктивності викладачів
університетів, що
позитивно впливає на
ефективність їх роботи.
Підрозділи Надійність роботи. Підрозділи університету
університету, такі, як зацікавлені в оперативному
деканати і навчально- введенні та виведенні
методичний відділ інформації, що стосується
них.

Тестування програмного забезпечення (ПЗ) грає провідну роль в забезпеченні
якості. Тестування проводять:
51
– розробники, які проводять як автоматизоване, так і ручне тестування
розроблюваних функцій; автоматизоване тестування проводиться у вигляді Unit-
тестів та інтеграційних тестів, ручне тестування може проводитись як через
інтерфейс користувача, так і через спеціальні інструменти, наприклад Swagger для
тестування серверного API;
– тестувальник, які проводять як автоматизоване, так і ручне тестування
розроблюваних функцій; автоматизоване тестування проводиться у вигляді
користувацьких автоматизованих тестів, ручне тестування може проводитись через
інтерфейс користувача;
– користувачі в рамках бета-тестування, як остаточно підготовлений
застосунок через інтерфейс.
3.5 Планування ризиків проєкту
Планування ризиків у проєкті – це процес, під час якого визначають, як саме
команда буде працювати з можливими проблемами на всіх етапах проєкту [12]. На
цьому кроці створюють або оновлюють план управління ризиками, який входить до
загального плану проєкту.
Основна мета планування ризиків:
 організувати роботу з ризиками чітко та впорядковано;
 визначити, хто за що відповідає та які методи будуть використовуватися;
 установити правила оцінювання ризиків, форму документів та як часто їх
потрібно оновлювати;
 виробити підхід, як знаходити ризики, оцінювати їх та реагувати на них.
Цілі планування ризиків:
 визначити, як саме команда буде працювати з ризиками. Тобто, обрати
інструменти, правила і підходи, якими користуватимуться;
 призначити людей, які відповідають за ризики. Хто буде їх відстежувати,
аналізувати та діяти у разі появи проблем;
 визначити, скільки ресурсів і грошей потрібно для роботи з ризиками;
52
 поділити ризики на категорії, щоб легше було їх знаходити та аналізувати;
 визначити, як оцінювати ризики: наскільки вони ймовірні, наскільки
сильний їхній вплив і наскільки вони термінові;
 установити формат і регулярність звітів, тобто як і як часто команда буде
звітувати про стан ризиків [13].
Ключові документи, які створюють під час планування.
1. План управління ризиками.
У ньому описують:
 мету й основні правила роботи з ризиками;
 хто за що відповідає;
 категорії ризиків;
 як саме їх оцінюватимуть (за ймовірністю, впливом і терміновістю);
 що робити, якщо ризик виходить за межі допустимого (правила ескалації);
 які бюджети та резерви потрібні;
 як оформлювати журнали та звіти;
 як часто переглядати ризики;
 як цей план пов’язаний з іншими планами проєкту — комунікаціями,
закупівлями, якістю тощо.
2. Реєстр ризиків (Risk Register).
Це основний перелік, де записують усі ризики. У ній міститься:
 короткий опис ризику (причина → подія → можливий наслідок);
 тригери та показники, за якими його можна помітити;
 відповідальна особа (власник ризику);
 оцінка ризику (ймовірність × вплив);
 його пріоритет;
 обрана стратегія реагування;
 план дій;
 резерви на випадок реалізації ризику;
 залишковий або вторинний ризик (що залишається після вжитих дій) [14].
53
Виділяють наступні типи ризиків для даного проєкту [15].
1. Фінансові ризики. Існують ризики невідповідності запланованих витрат та
невчасних виплат. Зокрема, невчасна оплата акаунту розробника Apple може
привести до неможливості розміщення застосунку в App Store;
2. Технічні ризики. Ризики, пов’язані зі збоями в роботі серверів, особливо
зважаючи на перебої у постачанні електроенергії в Україні. Ризики пов’язані з
хакерськими атаками, які є особливо актуальними під час війни. Помилки в
програмному забезпеченні можуть призводити до збою в роботі програми або
невідповідної швидкості її роботи, що може нести ризик небажання користувачів
користуватись застосунком. Оскільки мобільний застосунок «Викладач ЧДТУ»
пов’язаний з іншими сервісами ІАСПОДУ, то проблеми в роботі інших сервісів
можуть спричиняти збої в роботі мобільного застосунку. Ризики в безпеці
інформації при роботі застосунка можуть привести до псування даних, що може
зробити користування застосунком ускладненим або взагалі неможливим;
3. Юридичні ризики. Неврахування ліцензійних вимог використовуваних
зовнішніх бібліотек може привести до штрафних санкцій та миттєвої зупинки
використання цих бібліотек і пов’язаних з ними функцій мобільного застосунку.
Недотримання вимог компаній Google та Apple до програм, які розміщуються в
Google Play та App Store може привести до неможливості користувачами
завантажувати програми на свої пристрої, неможливості оновлювати програми в
Google Play та App Store і навіть до видалення застосунку з даних сервісів;
4. Кадрові ризики. Недостатня кваліфікація розробників може привести до
затримки в розробці функцій та запуску застосунку для використання, а також до
виникнення критичних помилок при використанні застосунку. Хвороби, а також
працевлаштування осіб задіяних в проєкті на повний робочий день може привести
до призупинки, або навіть зупинки роботи проєкту. Недостатньо якісне управління
проєктом може привести до зниження мотивації учасників проєкту, що може мати
наслідком зменшення якості та затримка в термінах реалізації;
54
5. Користувацькі ризики. Недостатньо якісні інструкції, погана підтримка,
численні помилки в роботі застосунку можуть демотивувати викладачів
користуватись ним.
Основні ризики проєкту зображено в таблиці 3.2.
Таблиця 3.2 – Основні ризики проєкту
Тип ризику Характеристика Методи уникнення
Фінансові Невідповідності Мати резервні джерела для
ризики запланованих витрат. покриття витрат.
Невчасні виплати. Намагатись підготувати виплати
заздалегідь, вести календар виплат
для запобігання забуванню про
них.
Технічні Збої в роботі серверів. Розміщувати серверну частину в
ризики Хакерські атаки. хмарних сервісах, що належать
Проблеми кібербезпеки. надійним компаніям.
Збої у пов’язаних сервісах. Встановити на сервері захист від
DDOS-атак, примушувати
користувачів періодично
змінювати паролі, робити резервні
копії критичних даних (наприклад
бази даних) і розміщувати їх поза
межами серверу, вести логи
роботи серверної частини,
встановити обмеження на
мінімальну довжину пароля.
Постійно контактувати з
розробниками інших сервісів, так,
щоб можна було оперативно
усунути недолік, продумати
резервні варіанти роботи
мобільного застосунку.
Юридичні Неврахування ліцензійних Уважно вивчати ліцензійні вимоги
ризики вимог використовуваних використовуваних зовнішніх
зовнішніх бібліотек. бібліотек, залучати дор цього
Недотримання вимог юриста.
компаній Google та Apple до Уважно вивчати вимоги компаній
програм, які розміщуються Google та Apple до програм, які
в Google Play та App Store. розміщуються в Google Play та App
Store, моніторити повідомлення
про зміни, негайно реагувати на
нові вимоги.
Кадрові Недостатня кваліфікація Залучати досвідчених
55
ризики розробників. консультантів, проводити постійне
Хвороби, а також навчання членів команди,
працевлаштування осіб здійснювати постійний контроль
задіяних в проєкті на менш досвідчених членів команди
повний робочий день. більш досвідченими.
Недостатньо якісне Залучати до роботи команди нових
управління проєктом. менш досвідчених членів для
поступової інтеграції в проєкт з
можливістю швидкої заміни
учасників, які вибули.
Зробити якісне планування
проєкту, ретельно дотримуватись
вимог, проводити заходи з
мотивування членів команди.
Користувацькі Недостатньо якісні Розробити якісні матеріали
ризики інструкції. Виділити окремі кадрові та часові
Погана підтримка. ресурси для забезпечення
Численні помилки в роботі підтримки.
застосунку. Ретельно дотримуватись
запланованих заходів забезпечення
якості проєкту.
3.6 Планування бюджету проєкту
Планування бюджету проєкту – це процес, під час якого визначають і
розраховують усі витрати, потрібні для виконання проєкту від початку до кінця. У
стандарті PMBOK це включає два основні кроки: оцінити, скільки що буде
коштувати (Estimate Costs); скласти загальний бюджет (Determine Budget).
Головна мета – створити реальний і керований бюджет, який дозволить
стежити за витратами, ухвалювати правильні рішення та ефективно
використовувати ресурси [12]. Визначення структури витрат допоможе зробити
бюджет зрозумілим і повним, без пропусків для цього розбивають проєкт на всі
роботи та завдання (за допомогою WBS), а потім для кожного з них окремо
визначають, скільки це коштуватиме.
Бюджет створюють наступним чином:
 складають разом вартість усіх робіт у проєкті;
56
 додають резерви на можливі ризики та запас коштів керівництва на
непередбачені ситуації;
 планують, коли і скільки грошей потрібно буде витрачати протягом
виконання проєкту.
Бюджет проєкту має включати [16]:
 оплату роботи людей і час, який вони витратять;
 вартість обладнання та матеріалів;
 витрати на закупівлі, договори та роботу підрядників;
 оплату ліцензій, різних послуг і необхідної інфраструктури;
 витрати на використання ресурсів під час роботи проєкту;
 адміністративні витрати, такі як офіс, комунальні послуги, підтримка тощо.
У підсумку бюджет оформлюють як базову лінію витрат (Cost Baseline) – це
основний орієнтир, за яким потім порівнюють фактичні витрати та контролюють
виконання проєкту.
Принципи якісного бюджетування [17]:
 зв’язок з роботами: кожна витрата має чітко відповідати конкретному
завданню або роботі з WBS;
 обґрунтованість: усі суми мають спиратися на реальні дані та правдиві
розрахунки;
 відкритість: усі припущення й пояснення повинні бути записані;
 гнучкість: бюджет має легко оновлюватися, якщо в проєкті відбуваються
зміни;
 зручність контролю: бюджет повинен дозволяти точно відстежувати
прогрес і витрати за допомогою таких методів, як Earned Value Management
(EVM).
Практично всі члени команди залучені до планування та реалізації бюджету.
Всі витрати в проєкті можна розділити на дві великі частини – витрати на людську
працю та витрати на закупівлю чи оренду матеріальних ресурсів.
Розподіл ролей за відповідальністю та бюджет зображено в таблиці 3.3.
57
Таблиця 3.3 – Розподіл ролей за відповідальністю та бюджет
Роль Основна відповідальність Завдання
Керівник проєкту Планування бюджету, - розробити план бюджету;
остаточне схвалення всіх - проводити остаточне
витрат, контроль за схвалення всіх витрат за
витратами. поданням інших членів
команди;
- контролювати витрати;
- корегувати витрати за
необхідності.
Головний інженер Пошук матеріальних - шукати предмети
проєкту одиниць для закупівлі, закупівлі та постачальників
схвалення матеріальних для придбання
одиниць для закупівлі. запланованих матеріальних
одиниць з урахуванням
обмежень бюджету;
- проводити схвалення
витрат за поданням інших
членів команди.
Системний Підбір сервера з урахуванням - шукати хмарний сервіс
адміністратор в тому числі вартості оренди. для оренди сервера з
урахуванням обмежень
бюджету.
Економіст Допомога керівникові у - допомогати керівникові у
плануванні бюджету та плануванні бюджету та
контролю за витратами. контролю за витратами;
Ведення обліку витрат. - вести облік витрат.
Тестувальник Підбір мобільних телефонів з - шукати мобільні телефони
урахуванням в тому числі їх для закупівлі з урахуванням
вартості. обмежень бюджету.
Розробники Підбір персонального - шукати комп’ютер та
комп’ютера і ноутбука з ноутбук для закупівлі з
урахуванням в тому числі їх урахуванням обмежень
вартості. бюджету.

Оцінка вартості проєкту за фазами зображено в таблиці 3.4.

58
Таблиця 3.4 – Оцінка вартості стартапу за фазами
№ Назва Оцінка вартості, грн
фази
1 Ініціація 3000
2 Планування 7000
3 Розробка програмного забезпечення 78000
4 Завершення 9100
Всього: 97100

Розробка даного застосунку ведеться силами викладачів та студентів
університету, тому для них не виділяється зарплата в класичному розумінні, але
університет виділяє для них приміальні кошти за результатами розробки та
впровадження. При цьому було зображено людські ресурси (табл. 3.5):
Таблиця 3.5 – Людські ресурси
№ Назва ресурса Оцінка
вартості
за годину*
Т1 Керівник проекта (КП) 150 грн.
Т2 Головний інженер проекту (ГІП) 130 грн.
Т3 Системний адміністратор (СА) 100 грн.
Т4 Економіст (Е) 80 грн.
Т5 Маркетолог (М) 80 грн.
Т6 Frontend розробник 1 100 грн.
Т7 Frontend розробник 2 100 грн.
Т8 Backend розробник 1 100 грн.
T9 Backend розробник 2 100 грн.
T10 Тестувальник 90 грн.
При закупівлі матеріальних ресурсів ті члени комнади, які будуть їх
використовувати, безпосередньо залучаються до вибору предметів закупівлі,
59
оскільки вони найкраще знають, що потрібно для виконання їхніх задач. Наприклад
розробники найкраще знають якої конфігурації комп’ютер та ноутбук потрібні для
розробки, яку вони вестимуть [18]. З іншого боку, системний адміністратор
найкраще знає, які повині бути параметри сервера для того, щоб серверна частина
застосунка працювала з достатньою продуктивністю та надійністю. Всі пропозиції
від членів команди однак повинні пройти схвалення головного інженера та
керівника проєкту.
При цьому були виділені матеріальні ресурси (табл. 3.6):
Таблиця 3.6 – Матеріальні ресурси
№ Назва ресурса Оцінка Оцінка
кількості вартості*
M1 Персональный комп’ютер 1 шт. 30000 грн.
М2 Ноутбук 1 шт. 20000 грн.
M3 Мобільні телефони для тестування 5 шт. 8000 грн.
М4 Оренда сервера 1 шт. 3000 грн.
М5 Ліцензія розробника Apple 1 шт. 4100 грн.
3.7 Планування комунікацій у проєкті
Планування комунікацій у проєкті – це процес визначення того, хто, що, коли,
як і яким способом має отримувати або надавати інформацію протягом реалізації
проєкту. Мета – забезпечити ефективний обмін інформацією між усіма учасниками
проєкту, щоб правильна інформація потрапляла до потрібних людей у потрібний час
і в потрібному форматі.
Основні етапи планування комунікацій.
1. Визначення зацікавлених сторін (Stakeholders):
 сторони, що беруть участь у проєкті або впливають на даний проєкт;
 приклади: замовник, керівник проєкту, команда, спонсори, користувачі.
2. Аналіз інформаційних потреб:
60
 яку саме інформацію потребує кожна сторона (звіти, статус, ризики,
результати тощо);
 як часто і в якій формі.
3. Вибір каналів комунікації:
 електронна пошта, месенджери, зустрічі, звіти, інформаційні панелі
(дашборди);
 враховується розмір команди, дистанційність, культура організації.
4. Розроблення плану комунікацій:
– документ, що описує:
 формати обміну інформацією;
 частоту та канали комунікацій;
 відповідальних за передачу та отримання даних.
5. Визначення стандартів і шаблонів:
– єдиний стиль звітів, презентацій, протоколів зустрічей.
6. Контроль і оновлення плану:
– під час реалізації проєкту план може змінюватися, якщо з’являються нові
зацікавлені сторони або змінюється обсяг робіт.
Основні принципи ефективних комунікацій:
– прозорість: інформація доступна всім зацікавленим сторонам;
– своєчасність: обмін даними без затримок;
– доступність: зручні формати й канали;
– зворотний зв’язок: підтвердження отримання й розуміння інформації.
Репозиторієм для зберігання проєктів мобільного застосунку (серверної та
клієнтської частини) є github.com. Він має в собі вбудовані засоби комунікації в
проєкті. Наприклад там можна вести журнал інформаційних повідомлень тривалого
використання. Крім того в ньому описуються задачі. Також github має свою Kanban-
дошку, в якій можна представляти візуальний перебіг виконання задач. План
комунікацій проєкту представлений в таблиці 3.7.

61
Таблиця 3.7 – План комунікацій проєкту
Тип Кому Відповідальний Формат / Частота
інформації передається канал
Завдання Виконавцям Керівник Група проєкту Щодня
команди проєкту в месенджері
Завдання на Розробникам. Керівник Github, Група На початку
розробку проєкту. проєкту в спринта,
Головний месенджері. корекції та
інженер. доповнення
Розробники, щоденно.
Тестувальник.
Звіти перед Замовнику, Керівник Очна У кінці
замовником користувачам. проєкту. презентація. спринта.
Головний
інженер.
Розробники.
Тестувальник.
Зустріч Керівник Керівник Очна зустріч. Один раз на
розробників проєкту. проєкту. тиждень.
Головний Головний
інженер. інженер.
Розробники. Розробники.
Тестувальник. Тестувальник.
Поточні Всім членам Всі члени Група проєкту Щодня.
уточнення команди команди. в месенджері.
План Керівник Керівник Група проєкту У кінці
покращення проєкту. проєкту. в месенджері. спринта.
за Головний
результатами інженер.
ретроспективи Розробники.
Тестувальник.
Висновки до розділу 3
У даному розділі описано планування проєкту згідно міжнародного стандарту
проєктного менеджменту PMBoK [12, 13]. Виконано планування: змісту проєкту,
часу проєкту, трудових ресурсів проєкту, якості проєкту, ризиків проєкту, бюджету
проєкту, закупівель в проєкті, комунікацій в проєкті. Було розроблено діаграму
WBS, діаграму Ганта, сітьовий графік, OBS, матрицю відповідальності, лист
ресурсів. Дане планування дає можливість правильно розподілити фінансові,
матеріальні та людські ресурси для успішної реалізації проєкту, з урахуванням
ризиків, які можуть виникнути в ході роботи над проєктом.
62
4 ПРАКТИЧНА РЕАЛІЗАЦІЯ ПРОДУКТУ ПРОЄКТУ
4.1 Вибір технологій розробки
Мобільний застосунок «Викладач ЧДТУ» складається з двох частин –
серверної (бекенд) та клієнтської (фронтенд). Очевидно, для побудови кожної з них
використовується свій стек технологій. Серверна частина являє собою Web REST
API, побудоване на основі фреймворка Nestjs [19] та використовує мову
програмування TypeScript. Клієнтська частина являє собою крос-платформний
мобліьний застосунок, написаний мовою Dart на основі технології Flutter з
використанням фреймворку bloc.
TypeScript [20] – це мова програмування, яка розширює JavaScript і додає до
нього статичну типізацію. Його розробила компанія Microsoft для того, щоб
спростити створення великих та складних програм.
TypeScript перетворюється у звичайний JavaScript, тому весь написаний код
може виконуватися в браузерах або середовищі Node.js.
Основні можливості TypeScript:
1. Статична типізація. Можна завчасно визначити, які дані очікуються: число,
текст, масив, об’єкт тощо. Це дозволяє знайти помилки ще на етапі
написання коду;
2. Підтримка сучасного JavaScript. TypeScript дозволяє використовувати нові
можливості JavaScript навіть у тих середовищах, які їх ще не підтримують;
3. Інтерфейси та типи. Дає можливість описувати структури даних і
забезпечувати їх однаковість по всьому проєкту;
4. Класи та об’єктно-орієнтоване програмування TypeScript робить ООП більш
зрозумілим і надійним;
5. Покращена робота з IDE. Завдяки типам редактори можуть підказувати,
доповнювати код і попереджати про помилки.
Застосовання TypeScript:
 веб-додатки;
63
 серверні API (з Node.js);
 мобільні застосунки (через React Native);
 великі корпоративні проєкти.
Завдяки структурованості TypeScript часто обирають для командної роботи.
NestJS [21] – це backend-фреймворк, написаний на TypeScript, який
використовує архітектурні принципи із світу Java та .NET. Він організовує
серверний код так, щоб зі збільшенням проєкту він не ставав хаотичним.
Ключові ідеї NestJS:
1. Модульність. Весь проєкт ділиться на модулі (наприклад, модуль
користувачів, модуль авторизації тощо). Це спрощує підтримку та
розширення;
2. Контролери. Обробляють вхідні запити користувача (наприклад: «Отримати
список студентів»);
3. Сервіси. Містять бізнес-логіку: розрахунки, звернення до бази даних,
правила роботи програми;
4. Dependency Injection. Фреймворк самостійно створює та передає об’єкти, які
потрібні сервісам і контролерам;
5. Гнучкість інтеграцій. Може працювати з будь-якою базою даних через ORM
(TypeORM, Prisma, Sequelize та ін.).
Використання NestJS:
 структурованість та передбачуваність;
 можливість швидко масштабувати проєкт;
 підтримка TypeScript;
 чіткі правила побудови API;
 підходить для мікросервісної архітектури.
NestJS – чудове рішення для серверної частини мобільного застосунку.
Dart – це мова програмування, створена Google. Вона призначена для швидкої
розробки інтерфейсів, тому має простий синтаксис, близький до Java, JavaScript і C#.
Особливості Dart:
1. Швидка компіляція:
64
 JIT (Just-In-Time) під час розробки → швидкий запуск і «hot reload»;
 AOT (Ahead-Of-Time) для релізів → максимальна продуктивність.
2. Типізація з можливістю вибору. Можна писати як зі строгими типами, так і
динамічно;
3. Підтримка асинхронності. Має зручний синтаксис async/await, що важливо
для роботи з мережею;
4. Сучасні конструкції. Лямбда-функції, розширені класи, міксини, стріми.
Dart став популярним завдяки Flutter, де є основною мовою.
Flutter [22] – це UI-фреймворк від Google, призначений для створення
застосунків під Android, iOS, веб і настільні платформи з однією кодовою базою.
На відміну від інших мобільних фреймворків, Flutter сам рендерить інтерфейс
через власний графічний рушій, а не використовує нативні елементи.
Головні переваги Flutter:
1. Єдина кодова база – один код працює всюди: мобільні, веб, Windows,
macOS, Linux;
2. Продуктивність, близька до нативної – завдяки власному рендеринг-движку
(Skia) графіка працює плавно;
3. Hot Reload Можна оновлювати інтерфейс без перезапуску застосунку;
4. Велика бібліотека віджетів Всі елементи інтерфейсу – від кнопок до
анімацій – це віджети;
5. Гнучкість дизайну – Інтерфейси створюються точністю до пікселя.
Flutter-архітектура:
 Widgets – основні будівельні блоки UI;
 Stateful / Stateless widgets – з керованим або фіксованим станом;
 State Management – різні підходи до керування станом: BLoC, Provider,
Riverpod, MobX.
BLoC (Business Logic Component) – це архітектурний шаблон, який
відокремлює логіку застосунку від інтерфейсу. Він побудований на принципі
потоків (Streams) у Dart.
65
BLoC став популярним завдяки офіційній підтримці Google і високій
структурованості.
Основні поняття BLoC:
1. Events (події). Те, що «запускає» логіку. Наприклад: LoadSchedule,
ChangePassword, AddNote;
2. States (стани). Те, що інтерфейс відображає. Наприклад: LoadingState,
LoadedState, ErrorState;
3. Bloc. Компонент, який отримує події, обробляє їх та видає нові стани.
Використання BLoC:
 чіткий поділ відповідальності;
 легке тестування бізнес-логіки;
 можливість повторного використання BLoC у різних частинах застосунку;
 зручність у середніх та великих проєктах.
Принцип роботи:
1. Користувач викликає подію (натиснув кнопку);
2. Подія надсилається у Bloc;
3. Bloc обробляє подію (наприклад, робить запит до API);
4. Bloc повертає новий стан;
5. UI оновлюється відповідно до стану.
Таким чином, інтерфейс не містить бізнес-логіки – він тільки реагує на зміни
стану.
Отже, усі п’ять технологій добре поєднуються між собою:
 TypeScript + NestJS → серверна частина застосунку;
 Dart + Flutter + BLoC → клієнтська мобільна частина.
Разом вони дозволяють створити сучасний, масштабований, кросплатформний
продукт зі зрозумілою структурою та високою продуктивністю.

66
4.2 Організація командної роботи в проєкті
Репозиторієм, в якому зберігається код серверної та клієнтської частин
проєкту, є github. Github є одним із багатьох сервісів на основі Git. Для легшого
розуміння можна уявити собі соціальну мережу для розробників, де ті переглядають
коди один одного, допомагають в розробці, залишають коментарі, тощо [23].
Основними функціями Github є:
 хостинг репозиторіїв: зберігання проєктів у вигляді репозиторіїв, де Git
відстежує кожну зміну;
 спільна робота: інструменти для співпраці над кодом, наприклад,
відстеження помилок, управління завданнями та перегляд коду;
 історія змін: можливість відстежувати історію всіх змін, внесених до
проєкту, та повертатися до попередніх версій;
 профіль-портфоліо: профіль на GitHub демонструє навички та досягнення
розробника;
 відкриті та приватні проєкти: можна створювати як публічні (безкоштовно),
так і приватні проєкти для закритого кола розробників (з можливостями платного
доступу).
Github надає цілу низку зручних інструментів командної взаємодії, до яких
можна віднести [24, 25]:
1. Опис задач. У розділі Issues групуються задачі, які описуються у вигляді
User Stories і можуть уточнюватить по ходу виконання (рисунок 4.1).
Задачі можуть бути призначені (рисунок 4.2) для певного розробника, в
певному спринті, можна встановити тип задачі (нова функція, задача в рамках
існуючої функції, виправлення помилки тощо). У ній видно історію змін та
доповнень даної задачі;

67

Рисунок 4.1 – Опис задач серверної частини мобільного застосунку «Викладач
ЧДТУ» в github

Рисунок 4.2 – Опис однієї з задач серверної частини мобільного застосунку
«Викладач ЧДТУ» в github
2. Pull requests (merge requests). Це важливий інструмент командної розробки
(рисунок 4.3), який дає можливість перевірити результат виконання задачі
програмістом (зазвичай, перевіряє більш досвідчений розробник).
68
Pull request в тому числі відображає зміни, внесені в рамках гілки виконання
задачі, в зручному вигляді, значно полегшуючи роботу програміста, який робити
перегляд коду (рисунок 4.4). Зокрема, там відображаються зміни різними
кольорами, що дозволяє чітко побачити, що було зроблено в рамках даної задачі і чи
не було видалено потрібний код;

Рисунок 4.3 – Приклад pull request в серверній частині мобільного застосунку
«Викладач ЧДТУ» в github

Рисунок 4.4 – Приклад порівняння коду в pull request в серверній частині
мобільного застосунку «Викладач ЧДТУ» в github
69
3. Kanban-дошка, яка є досить функціональною та гнучкою. Вона дає
можливість створювати потрібні колонки, перетягувати карточки з метою
відображення прогресу в задачах, також карточки автоматично створюються при
додаванні нових задач (рисунок 4.5). Дошка об’єднує задачі серверної та клієнтської
частини та має колонки для існуючих задач, задачі призначені для виконання в
даному спринті, взяті до роботи, послані на review та завершені. Kanban-дошка
безшовно інтегрується з Github Issues, що дозволяє легко створювати нові завдання і
додавати їх на дошку, без необхідності виходити з Github. Це спрощує роботу з
проблемами та завданнями, надаючи зручний інтерфейс для команд. додавати теги,
використовувати фільтри для швидкого пошуку задач і інтегрувати дошку з іншими
інструментами GitHub, такими як Pull Requests та Actions. Всі учасники проєкту
мають доступ до однієї канбан-дошки, що дозволяє легко координувати роботу і
слідкувати за прогресом [26].

Рисунок 4.5 – Приклад Kanban-дошки мобільного застосунку «Викладач
ЧДТУ» в github

70
4.3 Розробка бази даних та програмного забезпечення
4.3.1 Інтеграція мобільного застосунку в інформаційну систему
університету
Мобільний застосунок «Викладач ЧДТУ» з самого початку був запланований
як невід’ємна частина Інформаційно-аналітичної системи підтримки освітньої
діяльності університету. Він активно взаємодіє з ІАСПОДУ при виконанні своїх
задач [27]. Структура взаємодії показана на рисунку 4.6.

Рисунок 4.6 – Структура взаємодії мобільного застосунку «Викладач ЧДТУ»
в ІАСПОДУ
Система складається з кількох незалежних, але взаємопов’язаних підсистем,
які обмінюються даними через REST API. Центральним елементом цієї взаємодії є
серверна частина мобільного застосунку «Викладач ЧДТУ», що отримує
інформацію з інших систем університету та передає її мобільному клієнту.
Cерверна частина ІС деканату та навчально-методичного відділу є основною
інформаційна система університету, в якій зберігаються такі дані: студентські групи,
71
списки студентів, навчальні дисципліни, результати успішності (оцінки), інформація
про курси, довідники кафедр, спеціальностей тощо. Система надає REST API, через
який дані передаються до серверної частини мобільного застосунку «Викладач
ЧДТУ», такі, як інформацію про студентів, перелік вибіркових дисциплін викладача,
журнали успішності, оцінки та іншу навчальну інформацію [28].
4.3.2 Структура бази даних та програмного забезпечення
Перша версія бази даних мобільного застосунку «Викладач ЧДТУ»
складається з таблиць, які використовуються для аутентифікації користувачів – всі
інші дані для набору початкових функцій застосунка беруться з ІС деканату та
навчально-методичного відділу. Структура бази даних наведена на рисунку 4.7.

Рисунок 4.7 – Структура бази даних мобільного застосунку «Викладач ЧДТУ»

Серверна частина зроблена на основі фреймворку Nestjs, кожна функція
розташовується у власній папці, який являє собою окремий модуль – там
розташовуються як мінімум файли модуля, контролера, сервісу та DTO (рис. 4.8).
72
У папці remote-api розташовуються класи-репозиторії, які використовуються
для взаємодії з іншими бекендами. Приклад такого класу зображено на рисунку 4.9.

Рисунок 4.8 – Структура серверної частини мобільного застосунку «Викладач
ЧДТУ» в середовищі розробки

Рисунок 4.9 – Структура класів-репозиторії для взаємодії з іншими бекендами
73
Всі модулі мають схожу структуру, прикладом якої є структура модуля
відображення інформації про студентів для куратора (рисунок 4.10).

Рисунок 4.10 – Структура класів модуля відображення інформації про
студентів для куратора
Клієнтська частина застосунку є мобільним застосунком, структура якого
визначається платформою Flutter та фрйймворком bloc. Bloc (Business Logic
Component) – це архітектурний патерн для управління станом у Flutter, який
дозволяє розділяти бізнес-логіку від UI. Основна ідея BLoC полягає в тому, що вся
логіка обробки даних реалізується в окремих компонентах, а UI лише реагує на
зміни стану. Програма на основі BLoC складається з потоків (Streams), через які
компоненти взаємодіють між собою, передаючи дані та події. Кожен bloc відповідає
за певну частину логіки і керує своїми потоками даних, гарантуючи, що UI
відображатиме лише актуальний стан програми. Тому, програма розбивається на
74
папки, кожна з яких реалізує одну функцію застосунка і яка містить файли
репозиторію для доступу до даних, а також файли подій, станів, bloc для керування
станами і віджету екрану для відображенння інформації (рисунок 4.11).

Рисунок 4.11 – Структура класів класів мобільного застосунку
4.3.3 Тестування та впровадження мобільного застосунку «Викладач
ЧДТУ»
Тестування програми проводилось шляхом ручного тестування – окремо
тестувався бекенд за допомогою вбудованого в нього swagger та тестувались
фронтенд разом з бекендом як в локальній системі, так і на сервері.
Інтерфейс самого застосунку побудований таким чином, що внизу є меню з 5-
ти елементів, які відкривають екрани з основними функціями і останнім справа є
пункт у вигляді «бургера», який відкриває додаткове меню, в яке можна додавати
пункти і в подальшому (рисунок 4.12).
75

Рисунок 4.12 – Екран застосунку з нижнім меню та додатковим меню

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

Рисунок 4.13 – Перегляд груп, в яких викладач є куратором в мобільному
застосунку

Серверна частина задеплоєна на сервері університету разом з іншими
підсистемами ІАСПОДУ. Доступ до неї здійснюється за спеціально виділеним URL
через сервер nginx, який в тому числі забезпечує роботу за протоколом HTTPS.
Даний Backend комунікує з іншими сервісами ІАСПОДУ, які розташовані на цьому
ж сервері. Мобільний застосунок можна завантажити в Google Play, також
планується розміщення його в App Store. Для використання викладач повинен
увести логін та пароль, вислані на його електронну пошту.
77
Висновки до розділу 4
У рамках реалізації проєкту була сформована команда розробників, яка
реалізувала даний ІТ-проєкт, розробивши програмне забезпечення для мобільного
застосунку (бекенд-частину та безпосередньо сам застосунок на базі крос-
платформної технології Flutter). Програмне забезпечення було протестовано та
встановлено для практичного використання: серверна частина на хмарному сервері
університету, мобільний клієнт – в Google Play.

78
ВИСНОВКИ
У даній роботі було поставлено задачу спланувати та реалізувати IT-проєкт з
розробки мобільного застосунку для викладачів ЧДТУ, який є частиною існуючої в
даний час Інформаційно-аналітичної системи підтримки освітньої діяльності
університету. У ІАСПОДУ є багато інформації, яка стосується роботи викладачів,
але немає програми, за допомогою якої викладачі могли б працювати з цією
інформацією. Тому, метою кваліфікаційної роботи магістра стало обґрунтування та
розробка проєкту з побудови мобільного застосунку «Викладач ЧДТУ», який
забезпечує викладачів зручними інструментами для організації навчального
процесу, керування академічною діяльністю.
У роботі було проведено системний аналіз об’єкту дослідження та предметної
області. В якості об’єкту дослідження було виділено освітню діяльність
університету, а в якості предмету дослідження – IT-проєкт з розробки мобільного
застосунку для університету. Було зроблено постановку та обгрунтування проблеми,
досліджено бізнес-процеси, які стосуються проєкту розробки мобільного
застосунку, описано очікувані ефекти від впровадження застосунку. Досліджено
існуючі в даний час системи університету та їх потенційну взаємодію із
розроблюваним застосунком, а також вхідні та вихідні дані засосунку. Здійснено
пошук та проведено аналіз аналогів – знайдено кілька проєктів, які можна назвати
відносно аналогами, але за результатами було зроблено висновок, що прямих
аналогів на даний час не існує.
Також було проведено підготовчі дії до подальшого планування та реалізації
проєкту. Були визначені первинні та вторинні зацікавлені сторони, проведено аналіз
їх впливу на проєкт. Визначені цілі та задачі проєкту, структура продукту проєкту,
очікувані результати проєкту. Описано життєвий цикл проєкту, який складається з
стадій: ідея, планування, проєктування, розробка та тестування MVP, розробка та
тестування повнофункціонального застосунку, впровадження та підтримка.
Це стало основою для подальшого планування проєкту. Було виконано
планування: змісту проєкту, часу проєкту, трудових ресурсів проєкту, планування
79
якості проєкту, ризиків проєкту, бюджету проєкту, закупівель в проєкті, комунікацій
в проєкті. Було розроблено діаграму WBS, діаграму Ганта, сітьовий графік, OBS,
матрицю відповідальності, лист ресурсів.
У рамках реалізації проєкту була сформована команда розробників, яка
реалізувала даний ІТ-проєкт, розробивши програмне забезпечення для мобільного
застосунку (бекенд-частину та безпосередньо сам застосунок на базі крос-
платформної технології Flutter). Програмне забезпечення було протестовано та
встановлено для практичного використання: серверна частина на хмарному сервері
університету, омбільний клієнт – в Google Play.
80
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ
1. М. І. Рич Цінності зацікавлених сторін в соціальних та комерційних проектах
Збірник наукових праць «Управління розвитком складних систем», Київський
національний університет будівництва і архітектури, №13, 2013 рік, стор. 45-49.
2. Чумаченко І. В. Управління проектами: процеси планування проектних дій:
підручник. / Чумаченко І. В., Морозов В. В., Доценко Н. В., Чередниченко А. М. К. :
КРОК, 2014. 673 с.
3. Життєвий цикл проекту. URL: https://studfile.net/preview/13721236/page:7 (дата
звернення: 22.10.2025).
4. Управління ІТ-проектами в Microsoft Project: Комп’ютерний практикум [Текст]:
навчальний посібник для студентів спеціальності 122 «Комп’ютерні науки» для всіх
спеціалізацій / за ред.: Л. М. Добровська, О. В. Аверьянова. Київ : КПІ ім. Ігоря
Сікорського, 2020. 152 с.
5. Керування проєктами з повним контролем. URL: https://www.microsoft.com/uk-
ua/microsoft-365/project/project-management (дата звернення: 22.10.2025).
6. Конспект лекцій з курсу: «Розроблення та керування проєктами і стартапами».
URL: https://archer.chnu.edu.ua/bitstream/handle/123456789/4731/Розроблення та
керування Лек.pdf?isAllowed=y&sequence=1&utm (дата звернення: 22.10.2025).
8. Управління проєктами : навч. посібник / за ред. О. В Ульянченка, П. Ф. Цигікала.
Xарків : ХНАУ ім. В. В. Докучаєва, 2010. 522 с.
9. Морозов В. В. Формування, управління та розвиток команди проекту / Морозов В.
В., Чередніченко А. М., Шпильова Т.І. Київ : Таксон, 2009. 461с.
10. Time Management. URL: https://www.pmi.org/learning/library/time-management-
9094?utm (дата звернення: 12.11.2025).
11. Project Human Resource Management. URL: https://www.edwell.com/Free-
Resources/Project-Human-Resource-Management (дата звернення: 12.11.2025).
12. A Guide to the Project Management Body of Knowledge (PMBOK® Guide). Sixth
Edition. USA. PMI, 2017. 756 p.
81
13. A Guide to the Project Management Body of Knowledge (PMBOK® Guide) and the
Standard for Project Management. Seventh Edition. USA. PMI, 2021. 274 p.
14. Project Management Body of Knowledge (PMBOK®). URL:
https://www.projectmanagement.com/wikis/234759/project-management-body-of-
knowledge--pmbok-- (дата звернення: 12.11.2025).
15. Рішняк І. В. Моделювання процесу управління ризиками у мультипроектному
середовищі. [Текст] Львів : Вісник Національного університету "Львівська
політехніка" № 783: Інформаційні системи та мережі, 2014. С. 466-473.
16. ISO 10006:2017 – Quality management – Guidelines for quality management in
projects. URL:
https://cdn.standards.iteh.ai/samples/70376/e1b29c136abf4a48b5222ec0ef533ea9/ISO-
10006-2017.pdf (дата звернення: 12.11.2025).
17. PRINCE2 – Theme “Plans” та Theme “Progress”. URL:
https://www.prince2.com/eur/blog/unpacking-the-seven-themes-of-the-prince2-
methodology (дата звернення: 21.11.2025).
18. Морозов В. В. Інформаційні системи і технології в управлінні проектами. Ч.1
Планування проектів у MS Project : навч. посібник / Морозов В. В., Данченко О. Б.,
Шаров О. І. К. : Університет економіки та права “КРОК”, 2011. 167 с.
19. Node.js Foundation. Node.js Documentation. URL: https://nodejs.org/en/docs/ (дата
звернення: 23.11.2025).
20. Microsoft. TypeScript: JavaScript With Syntax for Types. Офіційна документація.
URL: https://www.typescriptlang.org/docs/ (дата звернення: 23.11.2025).
21. NestJS. Introduction to NestJS. URL: https://docs.nestjs.com/first-steps (дата
звернення: 23.11.2025).
22. Google. Flutter Documentation. URL: https://docs.flutter.dev/ (дата звернення:
23.11.2025).
23. QATestLab taining center. URL: https://training.qatestlab.com/blog/technical-
articles/what-is-github-and-how-to-work/ (дата звернення: 23.11.2025).

82
24. GitHub. Deanoffice-teacher-backend. URL: https://github.com/chdtu-fitis/deanoffice-
teacher-backend (дата звернення: 23.11.2025).
25. GitHub. Deanoffice-teacher-mobile. URL: https://github.com/chdtu-fitis/deanoffice-
teacher-mobile (дата звернення: 23.11.2025).
26. GitHub. Projects, views. URL: https://github.com/orgs/chdtu-fitis/projects/4/views/1
(дата звернення: 23.11.2025).
27. В. О. Цибенко, Л. П. Оксамитна, Г. О. Заспа. Ініціація проєкту створення
мобільного застосунку «Викладач ЧДТУ»: Збірник тез доповідей студентської
науково-практичної конференції ЧДТУ : 22-23 квітня 2025 / [упорядник Мельник
І.В.]; Міністерство освіти і науки України, Черкаський державний технологічний ун-
т. Черкаси : ЧДТУ, 2025. С. 25.
28. Методичні рекомендації до підготовки кваліфікаційної роботи магістра
здобувачів освітнього ступеня «магістр» зі спеціальності 122 – комп’ютерні науки,
освітня програма «Управління стартапами і проєктами в галузі інформаційних
технологій» усіх форм навчання [Електронний ресурс] / [упоряд. Данченко О. Б.,
Триус Ю. В., Оксамитна Л.П.]; М-во освіти і науки України, Черкаський держ.
технол. ун-т. Черкаси : ЧДТУ, 2023. 40 с.

83
ДОДАТОК А

Затверджую
Зав. кафедри КНСА,
______________ Юрій ТРИУС
«____»____________2025 р.

УПРАВЛІННЯ ПРОЄКТОМ РОЗРОБКИ МОБІЛЬНОГО ЗАСТОСУНКУ
«ВИКЛАДАЧ ЧДТУ»

Специфікація
482. ЧДТУ. 52420-01

Листів 2

Розробник ____________________ Цибенко В.О.

Керівник ____________________ Оксамитна Л.П.

Черкаси – 2025
84
482. ЧДТУ. 52420-01
Позначення Найменування Примітка

Документація

482. ЧДТУ. 52420-02 90 01 Публікація по темі
кваліфікаційної роботи
магістра

85
ДОДАТОК Б

УПРАВЛІННЯ ПРОЄКТОМ РОЗРОБКИ МОБІЛЬНОГО ЗАСТОСУНКУ
«ВИКЛАДАЧ ЧДТУ»

Публікація по темі кваліфікаційної роботи магістра
482.ЧДТУ. 52420-02 90 01
Листів 3

Розробник _____________ Цибенко В.О.

Черкаси – 2025
86

87

ChSTU repository

ChSTU repository preserves and enables easy and open access to all types of digital content including text, images, moving images, mpegs and data sets