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
Learn More
Please use this identifier to cite or link to this item:
https://er.chdtu.edu.ua/handle/ChSTU/6050| Title: | Управління стартапом створення десктопної системи генерації сайтів |
| Authors: | Данченко, Олена Борисівна Ткачук, Сергій Вікторович |
| Keywords: | УПРАВЛІННЯ,;МОНІТОРИНГ,;ЗАДАЧІ,;РИЗИК-МЕНЕДЖМЕНТ,;КАЛЕНДАРНЕ ПЛАНУВАННЯ,;МОДЕЛЮВАННЯ,;СИСТЕМА ГЕНЕРАЦІЇ САЙТІВ,;SGS. |
| Issue Date: | 11-Dec-2024 |
| Abstract: | Актуальність теми. У всі часи люди намагалися спростити роботу і витрати заради отримання максимальної вигоди. Ручна праця замінювалася спочатку ручними машинами, потім паровими двигунами, а з віком електрики та технологій багато професій замінили машини. Тому лише питання часу, коли у сфері ІТ автоматизація дійде до нового рівня, коли прості сайти та програми будуть створювати по натисканню кількох кнопок без поглибленого вивчення програмування. Саме програмування стане більш комплексним та глибоким. На даний момент повноцінної технології генерації сайтів немає як такої, є лише спроби, які прискорюють саму розробку IT-продукту. Ідея автогенерації все частіше спливає в новинах. Її активно починають використовувати великі компанія та дрібні стартапи для вирішення різноманітних питань, починаючи від дизайну та закінчуючи наповненням самого сайту та юридичних документів. Лише питання часу, коли автоматична система замінить роботу верстальників, дизайнерів та розробників. Мета даної магістерської роботи полягає у закріпленні та удосконаленні теоретичних та практичних знань, набутих під час навчання, шляхом створення додатка для генерації сайтів. У роботі розглядається проєкт розробки програми, яка допоможе компаніям та простим користувачам створювати сайти для свого користування з отриманням коду. Об’єкт дослідження: процеси управління стартапом розробки застосунку (ресурси, час, контроль витрат, визначення змісту, здійснення комунікацій та інші ключові аспекти управління стартапом). Предмет дослідження: стартап розробки проєкту системи генерації сайтів. Апробація результатів роботи. Основні положення і результати кваліфікаційної роботи магістра доповідалися і були обговорені на студентській науково-практичній конференції на кафедрі комп’ютерних наук та системного аналізу 23 – 24 квітня 2024 року, ЧДТУ, Черкаси. Публікації. Ткачук С.В., Данченко О.Б. МАРКЕТИНГ IT-ПРОДУКТІВ. // Студентська науково-практична конференція кафедри комп’ютерних наук та системного аналізу, 23 – 24 квітня 2024 року, ЧДТУ, Черкаси. |
| URI: | https://er.chdtu.edu.ua/handle/ChSTU/6050 |
| Appears in Collections: | 122 Комп’ютерні науки (Управління стартапами і проектами в галузі інформаційних технологій) |
Files in This Item:
| File | Description | Size | Format | |
|---|---|---|---|---|
| Пояснювальна записка_Кваліфікаційна робота магістра_Ткачук Сергій_МСТП-2302_2024.pdf Restricted Access | 2.72 MB | Adobe PDF | View/Open Request a copy |
Items in DSpace are protected by copyright, with all rights reserved, unless otherwise indicated.
Extracted text
МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ
ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОГІЧНИЙ УНІВЕРСИТЕТ
Факультет інформаційних технологій і систем
Кафедра комп’ютерних наук та системного аналізу
Пояснювальна записка
до кваліфікаційної роботи
магістра
(освітньо-кваліфікаційний рівень)
на тему: «Управління стартапом створення десктопної системи генерації
сайтів»
Виконав: студент 2 курсу, групи МСТП-2302
спеціальності 122 «Комп’ютерні науки»
(шифр і назва спеціальності)
освітня програма «Управління стартапами
(назва освітньої програми)
і проєктами в галузі інформаційних технологій»
Ткачук Сергій Вікторович
Керівник Данченко О.Б.
(прізвище та ініціали)
Рецензент Бедрій Д.І.
(прізвище та ініціали)
2
Черкаси 2024 рокуЧеркаський державний технологічний університет
Факультет Інформаційних технологій і систем
Кафедра Комп’ютерних наук та системного аналізу
Освітньо-кваліфікаційний рівень Магістр
Спеціальність 122 – комп’ютерні науки
Освітня програма Управління стартапами і проєктами в галузі інформаційних технологій
ЗАТВЕРДЖУЮ
Завідувач кафедри КНСА
_______________ Юрій Триус
«____» _____________ 2024 р.
ЗАВДАННЯ
на кваліфікаційну роботу магістра студенту
Ткачук Сергій Вікторович
(прізвище, ім‘я, по батькові)
1. Тема роботи «Управління стартапом створення десктопної
системи генерації сайтів»
Керівник роботи Данченко Олена Борисівна, д.т.н., професор
(прізвище, ім’я, по батькові, науковий ступінь, вчене звання)
затверджені наказом університету від «07» жовтня 2024 р. № 299/04
2. Строк подання студентом роботи «28» листопада 2024 року.
3. Вихідні дані до роботи:
Результати та матеріали з проходження виробничої та переддипломної практики
4. Зміст пояснювальної записки (перелік питань, що їх належить розробити):
Вступ.
4.1. Аналіз обʼєкта дослідження
4.2. Розробка концепції стартапу
4.3. Планування та управління стартапом
4.4. Моделювання виконання стартапу та його результати
Висновки.
3
6. Консультанти розділів роботи
Прізвище, ініціали та Підпис, дата
Розділ посада
завдання видав завдання прийняв
консультанта
7. Дата видачі завдання
КАЛЕНДАРНИЙ ПЛАН
Строк виконання
№ з/п Назва етапів кваліфікаційної роботи магістра Примітка
етапів роботи
1 Видача завдання на кваліфікаційну роботу
6.10.2024
магістра.
2 Аналіз літературних джерел, об’єкту та 7.10.2024 -
предмету дослідження. 20.10.2024
3 Написання теоретичного розділу кваліфікаційної 21.10.2024 -
роботи магістра. 5.11.2024
4 Написання аналітичного розділу (аналіз об’єкту 6.11.2024 -
й предмету дослідження). 14.11.2024
5 Написання практичних розділів й висновків 14.11.2024 -
кваліфікаційної роботи магістра. 27.11.2024
6 Передзахист кваліфікаційної роботи магістра на
28.11.2024
засіданні випускової кафедри.
7 Подання роботи завідувачу кафедри КНСА. 29.11.2024
8 Захист кваліфікаційної роботи магістра. 11.12.2024
Студент _____________________________ / Ткачук С.В./
(підпис) ПІБ
Керівник роботи ____________________________ /Данченко О.Б./
(підпис) ПІБ
4
РЕФЕРАТ
Кваліфікаційна робота магістра містить: 107 с., 16 рис., 30 табл., 103
використаних джерел.
Актуальність теми. У всі часи люди намагалися спростити роботу і витрати
заради отримання максимальної вигоди. Ручна праця замінювалася спочатку
ручними машинами, потім паровими двигунами, а з віком електрики та технологій
багато професій замінили машини. Тому лише питання часу, коли у сфері ІТ
автоматизація дійде до нового рівня, коли прості сайти та програми будуть
створювати по натисканню кількох кнопок без поглибленого вивчення
програмування. Саме програмування стане більш комплексним та глибоким. На
даний момент повноцінної технології генерації сайтів немає як такої, є лише спроби,
які прискорюють саму розробку IT-продукту.
Ідея автогенерації все частіше спливає в новинах. Її активно починають
використовувати великі компанія та дрібні стартапи для вирішення різноманітних
питань, починаючи від дизайну та закінчуючи наповненням самого сайту та
юридичних документів. Лише питання часу, коли автоматична система замінить
роботу верстальників, дизайнерів та розробників.
Мета роботи і задачі дослідження. Мета даної магістерської роботи полягає у
закріпленні та удосконаленні теоретичних та практичних знань, набутих під час
навчання, шляхом створення додатка для генерації сайтів. У роботі розглядається
проєкт розробки програми, яка допоможе компаніям та простим користувачам
створювати сайти для свого користування з отриманням коду.
Дана робота має на меті вирішення наступних завдань:
проведення дослідження ринку автоматичних систем;
дослідження особливостей методології управління стартапами в галузі IT;
аналіз оточення стартапу та формування стратегії;
обґрунтування доцільності стартапу;
проведення структурного планування;
5
розробка компонентів управління стартапом;
виявлення та оцінки можливостей подальшого удосконалення продукту з
метою розширення його функціональності.
Об’єкт дослідження: процеси управління стартапом розробки застосунку
(ресурси, час, контроль витрат, визначення змісту, здійснення комунікацій та інші
ключові аспекти управління стартапом).
Предмет дослідження: стартап розробки проєкту системи генерації сайтів.
Методи дослідження. У ході виконання магістерської роботи було
використано різноманітні методи та інструменти для проведення дослідження.
Серед них можна виділити такі: SWOT-аналіз (який застосовувався для оцінки
внутрішніх та зовнішніх аспектів стартапу). методи управління ризиками,
календарне планування, SWOT-аналіз, STEP-аналіз, аналіз зовнішнього та
внутрішнього середовища, інвестеційні дослідження.
Для планування та розробки окремих компонентів стартапу були використані
програмні продукти, такі як LibreOffice, ProjectLibre та BP Win.
Апробація результатів роботи. Основні положення і результати
кваліфікаційної роботи магістра доповідалися і були обговорені на студентській
науково-практичній конференції на кафедрі комп’ютерних наук та системного
аналізу 23 – 24 квітня 2024 року, ЧДТУ, Черкаси.
Публікації. Ткачук С.В., Данченко О.Б. МАРКЕТИНГ IT-ПРОДУКТІВ. //
Студентська науково-практична конференція кафедри комп’ютерних наук та
системного аналізу, 23 – 24 квітня 2024 року, ЧДТУ, Черкаси.
Перелік ключових слів: УПРАВЛІННЯ, МОНІТОРИНГ, ЗАДАЧІ, РИЗИК-
МЕНЕДЖМЕНТ, КАЛЕНДАРНЕ ПЛАНУВАННЯ, МОДЕЛЮВАННЯ, АНАЛІЗ,
РИЗИК, ДЕСКТОПНА СИСТЕМА, СИСТЕМА ГЕНЕРАЦІЇ САЙТІВ, SGS.
6
ABSTRACT
Master's qualifying work includes: 107 p., 16 figures, 30 tables, 103 used sources.
Relevance of the topic. At all times, people have tried to simplify work and costs
for the sake of obtaining maximum benefits. Manual labor was replaced first by hand
machines, then by steam engines, and with the age of electricity and technology, many
occupations were replaced by machines. Therefore, it is only a matter of time when
automation in the field of IT will reach a new level, when simple sites and applications
will be created by pressing a few buttons without in-depth study of programming. The
programming itself will become more complex and deep. At the moment, there is no full-
fledged site generation technology as such, there are only attempts that accelerate the
development of the IT product itself.
The idea of self-generation is increasingly appearing in the news. It is actively being
used by large companies and small startups to solve various issues, starting from design
and ending with the filling of the site itself and legal documents. It is only a matter of time
before an automated system replaces the work of typewriters, designers and developers.
The purpose of the work and research tasks. The purpose of this master's thesis is
to consolidate and improve the theoretical and practical knowledge acquired during
training by creating an application for generating sites. The work considers the project of
developing a program that will help companies and ordinary users to create sites for their
own use with receiving the code.
This work aims to solve the following tasks:
conducting market research of automatic systems;
study of the peculiarities of project management methodology in the field of IT;
analysis of the project environment and strategy formation;
justification of the feasibility of the project;
carrying out structural planning;
development of project management components;
7
identification and evaluation of the possibilities of further improvement of the
product in order to expand its functionality.
The subject of the study: a startup for the development of a site generation
system project.
Research object: application development project management processes
(resources, time, cost control, content definition, communication and other key aspects of
project management).
The subject of the study: a startup for the development of a site generation
system project.
Research methods. Various research methods and tools were used in the course of
the master's work. Among them, the following can be distinguished: SWOT analysis
(which was used to evaluate the internal and external aspects of the project). risk
management methods, calendar planning, SWOT analysis, STEP analysis, analysis of the
external and internal environment, investment studies. Software products such as
LibreOffice, ProjectLibre and BP Win were used for planning and development of
individual project components.
Approbation of the results of the work. The main provisions and results of the
master's qualification work were reported and discussed at the student scientific and
practical conference at the Department of Computer Science and Systems Analysis on
April 23–24, 2024, Cherkasy State Technical University, Cherkasy.
Publications. Tkachuk S.V., Danchenko O.B. MARKETING OF IT PRODUCTS. //
Student scientific and practical conference of the Department of Computer Science and
Systems Analysis, April 23–24, 2024, Cherkasy State Technical University, Cherkasy.
List of keywords: MANAGEMENT, MONITORING, TASKS, RISK MANAGEMENT,
CALENDAR PLANNING, MODELING, ANALYSIS, RISK, DESKTOP SYSTEM, SITE
GENERATION SYSTEM, SGS.
8
ЗМІСТ
ЗМІСТ ........................................................................................................................... 8
ВСТУП ........................................................................................................................ 10
1 АНАЛІЗ ОБʼЄКТА ДОСЛІДЖЕННЯ ................................................................... 12
1.1 Постановка задачі та обґрунтування проблеми ......................................... 12
1.2 Опис ідеї стартапу ......................................................................................... 21
1.3 Маркетингові дослідження та аналіз оточення стартапу .......................... 22
1.4 Альтернативні ідеї реалізації стартапу та аналіз аналогів ........................ 24
Висновки до розділу 1 ............................................................................................... 25
2 РОЗРОБКА КОНЦЕПЦІЇ СТАРТАПУ ................................................................. 27
2.1 Дерево цілей ................................................................................................... 27
2.2 Зацікавлені сторони та їх вплив на стартап ................................................ 30
2.3 Визначення мети, цілей стартапу та критеріїв їх досягнення .................. 31
2.4 Опис продукту стартапу ............................................................................... 33
2.5 Життєвий цикл стартапу ............................................................................... 34
Висновки до розділу 2 ............................................................................................... 38
3 ПЛАНУВАННЯ ТА УПРАВЛІННЯ СТАРТАПОМ ............................................ 39
3.1 Планування змісту та обмеження стартапу ................................................ 39
3.2 Організаційна структура стартапу ............................................................... 44
3.3 Розробка календарного плану стартапу ...................................................... 47
3.4 Планування трудових та матеріальних ресурсів стартапу ........................ 51
3.5 Планування якості стартапу ......................................................................... 52
3.6 Планування бюджету та управління закупівлями ...................................... 54
3.7 Управління ризиками .................................................................................... 58
3.8 Управління комунікаціями стартапу ........................................................... 64
Висновки до розділу 3 ............................................................................................... 66
4 МОДЕЛЮВАННЯ ВИКОНАННЯ СТАРТАПУ ТА ЙОГО РЕЗУЛЬТАТИ ....... 68
4.1 Моделювання продукту стартапу ................................................................ 68
9
4.2 Проектування архітектури застосунку ........................................................ 69
4.3 Опис процесу практичної реалізації стартапу ........................................... 71
4.4 Технології ....................................................................................................... 77
4.5 Технічний борг та майбутні плани розробки ............................................. 94
Висновки до розділу 4 ............................................................................................... 95
ВИСНОВКИ ............................................................................................................... 96
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ ................................................................. 98
10
ВСТУП
Актуальність теми. У всі часи люди намагалися спростити роботу і витрати
заради отримання максимальної вигоди. Ручна праця замінювалася спочатку
ручними машинами, потім паровими двигунами, а з віком електрики та технологій
багато професій замінили машини. Тому лише питання часу, коли у сфері ІТ
автоматизація дійде до нового рівня, коли прості сайти та програми будуть
створювати по натисканню кількох кнопок без поглибленого вивчення
програмування. Саме програмування стане більш комплексним та глибоким. На
даний момент повноцінної технології генерації сайтів немає як такої, є лише спроби,
які прискорюють саму розробку IT-продукту.
Ідея автогенерація все частіше спливає в новинах. Її активно починають
використовувати великі компанія та дрібні стартапи для вирішення різноманітних
питань, починаючи від дизайну та закінчуючи наповненням самого сайту та
юридичних документів. Лише питання часу, коли автоматична система замінить
роботу верстальників, дизайнерів та розробників.
Мета роботи і задачі дослідження. Мета даної магістерської роботи полягає
у закріпленні та удосконаленні теоретичних та практичних знань, набутих під час
навчання, шляхом створення додатка для генерації сайтів. У роботі розглядається
проєкт розробки програми, яка допоможе компаніям та простим користувачам
створювати сайти для свого користування з отриманням коду.
Дана робота має на меті вирішення наступних завдань:
Проведення дослідження ринку автоматичних систем.
Дослідження особливостей методології управління проєктами в галузі IT.
Аналіз оточення проєкту та формування стратегії.
Обґрунтування доцільності проєкту.
Проведення структурного планування.
Розробка компонентів управління проєктом.
11
Виявлення та оцінки можливостей подальшого удосконалення продукту з
метою розширення його функціональності.
Об’єкт дослідження: процеси управління проєктом розробки застосунку
(ресурси, час, контроль витрат, визначення змісту, здійснення комунікацій та інші
ключові аспекти управління проєктом).
Предмет дослідження: стартап розробки проєкту системи генерації сайтів.
Апробація результатів роботи. Основні положення і результати
кваліфікаційної роботи магістра доповідалися і були обговорені на студентській
науково-практичній конференції на кафедрі комп’ютерних наук та системного
аналізу 23–24 квітня 2024 року, ЧДТУ, Черкаси.
Публікації. Ткачук С.В., Данченко О.Б. МАРКЕТИНГ IT-ПРОДУКТІВ. //
Студентська науково-практична конференція кафедри комп’ютерних наук та
системного аналізу, 23–24 квітня 2024 року, ЧДТУ, Черкаси.
12
1 АНАЛІЗ ОБʼЄКТА ДОСЛІДЖЕННЯ
1.1 Постановка задачі та обґрунтування проблеми
Існує багато додатків, які допомагають розробникам та дизайнерам і роблять
життя комфортнішим, легшим та ефективнішим. Одним із таких додатків може стати
десктопна програма система генерації сайтів.
Сам процес створення сайтів має багато етапів та особливостей, які мають
значний вплив на терміни створення, а також вартість самого продукту. І досить
часто утворюється ситуація, коли замовникам доводиться відмовлятися від певних
частин свого додатка/сайту, щоб просто вкласти в саму роботу. Також є додатковий
аспект людей, які мають талант, але не мають жорстоких знань та/або умінь для
створення оптимізованого та якісного сайту.
Розглянемо вартість створення якогось IT-продукту. Визначимо мінімальний
склад команди для розробки сайту з нуля:
– бізнес-аналітик – це людина, яка допомагає визначити бізнес-вимоги,
затвердити технічне завдання, сформувати CJM та написати User Stories.
Мета цього етапу – сформувати документацію та надати прототипи
майбутнього сайту з функціоналом, який буде закладено у першу ітерацію*.
*На етапі пресейлу ми формуємо попередню комерційну пропозицію на
основі базових функціональних вимог, які виходять із нашого досвіду
розробки подібних проєктів. Тобто, ми можемо заздалегідь оцінити обсяг
робіт і показати клієнту попередню вартість, яка незначно змінюватиметься
у більшу чи меншу сторону в процесі погодження. Для зручності ми
укладаємо рамковий договір, а до нього 2 замовлення: на бізнес-аналітику
та на розробку;
– проєктний менеджер - Це серце розробки, він відповідає за комунікацію
між членами команди та клієнтом, ставить завдання, визначає ризики,
формує терміни та стежить за всіма таймлайнами. Менеджер відповідає за
хід проєкту на кожному етапі;
13
– дизайн: арт-директор, дизайнер - Арт-директор визначає візуальну
концепцію та відповідає за підсумковий продакшн. Він аналізує ринок та
продукт клієнта, формує єдину візуальну концепцію. UI-дизайнер малює
інтерфейс на базі прототипів, які були створені на етапі аналітики, формує
макети в Figma (UI-Kit, мобільна версія та набір компонентів, які потім
використовуватимуться в тому числі при масштабуванні сайту) і оформляє
в красиву презентацію;
– розробка: тімлід, 2 розробники (Frontend і Backend) - Тімлід на основі
проведеної аналітики вибирає технології, які будуть використані при
розробці, декомпозує та ставить завдання, відповідає за всю систему
оточення та за кінцевий продакшн коду. Frontend-розробник верстає та
пише логіку клієнтської частини, Backend-розробник пише серверну логіку,
займається конфігурацією CMS (якщо розробляємо на ній);
– qa: ручний тестувальник - Ця людина тестує CJM, функціональність
кожного елемента сайту (форма зворотного зв'язку, платіжні форми і всі
сценарії користувача), перевіряє блоки на відповідність макетам, знаходить
баги;
– продакшн: контент-менеджер – Як правило, інтернет-магазини просять
вивантажити товар на готовий сайт зі своїх систем, наприклад, 1С.
Зазвичай це базова номенклатура з кількістю залишків, цінами та якимось
описом, але у 90% випадків цей контент не підходить для вітрини сайту.
Контент-менеджер завантажує фотографії потрібного розміру, розподіляє
характеристики товару та підганяє клієнтські дані під затверджений дизайн.
Замовник може надати свого контент-менеджера, але простіше взяти
людину від агентства хоча б на старті, тому що знаючи специфіку системи
та дизайн-концепцію, він зробить цю роботу швидше та якісніше;
– адміністративний цех і непрямі витрати - Багато хто забуває включати до
кошторису адміністративну частину виробничого цеху, але це важливий
пункт, який забезпечує працездатність усієї системи. Це бухгалтер (людина,
14
яка займається документообігом та фінансовими операціями), керівник
проєкту (у невеликих компаніях цю роль може виконувати СEO), офісні
витрати (оренда та забезпечення), пресейл (первинні дзвінки, брифінг,
формування комерційної пропозиції).
А тепер візьмемо стандартний кошторис проєкту сайту інтернет-магазину [38 -
46]. І подивимося погодинні витрати на проєкт з урахуванням податків, ні інших
витрат у таблиці 1.1. (Якщо розробник отримує 2000 $ на місяць, то він коштує
компанії приблизно 3560 $, а продавати його потрібно по 4500 $)
Таблиця 1.1 – Середня погодинна оплата
Тип роботи Середня погодинна оплата $
Арт-директор/дизайнер 20
DevOps 20
Team Lead 18
Backend Developer 16
Frontend Developer 16
BA 12
QA 11
UI/UX Designer 11
Content manager 9
А тепер розподілимо їх по всій необхідній роботі та порахуємо вартість [24 -
26] кожного кроку:
Аналітика (таблиця 1.2):
Збір та підготовка даних з різних джерел;
Створення масштабних візуалізацій та звітів;
Виявлення закономірностей, взаємозв'язків і тенденцій даних;
Побудова аналітичних моделей;
Формулювання аналітичних рекомендацій та висновків;
15
Таблиця 1.2 – Аналітика
Найменування Виконавці Час Вартість Коментарі
роботи
Збір даних та BA 40 480 Написати ТЗ — описати межі
формування ТЗ системи та основні вимоги до
функціоналу сайту
Розробка дизайну (таблиця 1.3). Перш ніж приступати до створення програми,
необхідно перш за все створити дизайн, на підставі якого будуть висунуті
припущення про витрати часу на кожну сторінку.
Таблиця 1.3 – Розробка дизайну
Найменування Виконавці Час Вартість Коментарі
роботи
Арт-дирекшн Арт- 16 320 Аналіз конкурентів, цільової
візуальні директор аудиторії
концепції веб-
сайту, ресерчінг,
дослідження
Статика UI/UX 16 176 Шапка, футер, модалки, сповіщення
Designer та інше
Головна UI/UX 40 440 5 стандартних блоків: слайдер-
Designer оффер, нові та популярні товари,
блок колекцій, 2 слова про бренд,
іміджевий блок
Каталог UI/UX 40 440 Хлібні крихти, шапка, фільтр,
Designer сортування, сітка товарів та сам
товар, пагінація
Картка товару UI/UX 40 440 Галерея зображень, опис товару,
Designer додавання до кошика, вибір
16
атрибутів, стану, схожі товари
Кошик UI/UX 32 352 Стандартний кошик, промокод
Designer
Оформлення UI/UX 32 352 Поля доставки, особисті дані, вибір
замовлення Designer доставки, оплати, підсумок за
кошиком
Сторінка Дякую UI/UX 24 264 Сторінка оповіщення щодо статусу
Designer оплати та підтвердження замовлення
Особистий UI/UX 32 352 Особисті дані, доставка, останні
кабінет Designer замовлення
Інформаційна UI/UX 16 176 Будь-яка інформаційна сторінка з
сторінка Designer картинками та текстом
Мобільна версія UI/UX 32 352 Мобільна адаптивність
Designer
Ui Kit UI/UX 24 264 UI Kit та основний посібник до
Designer верстки
Backend-розробка (таблиця 1.4) - створення бази, каркасу та необхідних
запитів для повного функціонування IT-продукції.
Таблиця 1.4 – Backend-розробка
Найменування Виконавці Час Вартість Коментарі
роботи
Налаштування Team Lead 24 432 Структура, плагіни, вимоги
адмін-панелі, до розробки
каскад та
архітектура
Бекенд статики Backend 16 256
Developer
Головна Backend 32 512
17
Developer
Каталог Backend 56 896
Developer
Картка товару Backend 40 640
Developer
Кошик Backend 56 896
Developer
Оформлення Backend 56 896
замовлення Developer
Сторінка Дякую Backend 8 128
Developer
Особистий Backend 8 128
кабінет Developer
Інтеграція Backend 8 128 Встановлення та
системи оплати Developer налаштування плагіна оплати
Інтеграція Backend 8 128 Встановлення та
системи доставки Developer налаштування плагіна
доставки
Інформаційна Backend 8 128
сторінка Developer
Frontend-розробка (таблиця 1.5) — створення інтерфейсу, з яким користувач
постійно взаємодіятиме.
Таблиця 1.5 – Frontend-розробка
Найменування Виконавці Час Вартість Коментарі
роботи
Ініціалізація Team Lead 24 432 Структура, плагіни, вимоги до
архітектури розробки
програми
18
Головна Frontend 80 1280
Developer
Каталог Frontend 40 640
Developer
Картка товару Frontend 56 896
Developer
Кошик Frontend 46 736
Developer
Оформлення Frontend 40 640
замовлення Developer
Сторінка Дякую Frontend 24 384
Developer
Особистий кабінет Frontend 24 384
Developer
Інформаційна Frontend 16 256
сторінка Developer
Верстка статики Frontend 24 384
Developer
Тестування (таблиця 1.6) — найважливіша частина після розробки. Якісне
тестування – запорука успіху. Є кілька прикладів історії, коли дійсно класна IT-
продукція була неприйнята користувача через велику кількість помилок. Наявність
тестувальника може виправити цю ситуацію.
Таблиця 1.6 – Тестування
Найменування Виконавці Час Вартість Коментарі
роботи
Тестування QA 32 352 Тестування функціональності
функціональності - інтеграція, форми, оплата,
системи доставка
19
Тестування QA 24 264 Тестування інтерфейсу на
верстки різних браузерах та пристроях
Передпродакшн (таблиця 1.7) — наповнення самого сайту та його перевірка на
відповідність товар та реальності.
Таблиця 1.7 – Передпродакшн
Найменування Виконавці Час Вартість Коментарі
роботи
Наповнення сайту Content manager 40 320 Фото, текст, картки та інше
актуальними
даними або
коригування
вхідних даних
Публікація сайту (таблиця 1.8) – фінальна частина, реліз.
Таблиця 1.8 – Публікація
Найменування Виконавці Час Вартість Коментарі
роботи
Публікація сайту DevOps 16 360 Гіт, деплой, тестове
в мережі, середовище.
налаштування
тестового та
продакш
оточення
Підсумкова вартість (таблиця 1.9):
Таблиця 1.9 – Підсумкова вартість
Підсумкова вартість 16904 $
Термін виконання 4-5 місяців
20
Нині ж можемо скоротити певні частини розробки. Наприклад взяти вже
готовий функціонал оплати та доставки, який потрібно підключити, а також
стандартний функціонал бекенда. Також було б непогано отримати можливість і
дизайнерам і розробникам виконувати свою роботу відразу або навіть дати
дизайнеру роботу розробника використовуючи конструктор для створення сайту. Ми
можемо отримати скорочення бюджету від 24 до 57%, що буде вкрай вигідно для
будь-якого користувача. Крім того, немає більше потреби у такій великій команді.
Крім іншого, істотно скорочується час розробки та тестування, оскільки
система віщує автоматичну перевірку на декількох браузерах і пристроях.
Отже, головна проблема, яку потрібно вирішити вартість та час розробки, а
також можливість отримання коду створеного продукту з подальшою можливістю
коригування.
Метою створення стартапу є спроба вирішити поставлену проблему, тому
основна задача – розробка продукту, що допоможе користувачам економити час та
гроші. Продуктом є стартап десктопної системи для генерації сайтів, на підставі
шаблонів, а також пошуку необхідних компонентів та можливість їх інтеграції у
додаток.
Цільовою аудиторією майбутнього додатку є, в першу чергу, розробники,
дизайнери та компанії.
Щоб ефективно вирішити проблеми клієнтів, додаток повинен мати широкий
функціонал. Він повинен мати поле створення, перегляду макетів, можливість
вивантаження коду та перевірки функціональності, а також доступ до магазину, в
якому кожен може запропонувати зовнішній вигляд макета і після оплати отримати
вже готовий сайт.
Особливістю додатку буде змога користувачів оформити підписку, створити
особистий кабінет та отримувати ексклюзивні акційні пропозиції.
21
1.2 Опис ідеї стартапу
Метою створення стартапу є проба вирішити поставлену проблему, а саме
створення продукту, що допоможе користувачам економити час та гроші та отримати
можливість вивантажувати код створеного проєкту.
Ідеєю для створення стартап десктопної системи для генерації сайтів.
Для початку роботи з додатком після завантаження на комп'ютер,
користувачеві необхідно буде зареєструватися, тобто створити власний кабінет та
авторизуватися. Кабінет користувача потрібний для того, щоб визначити яку версію
додатку він отримає (безкоштовну чи повну), та наявність підписки. В особистому
кабінеті користувач матиме можливість додати та редагувати особисті дані, такі як
номер телефону, ім'я, адресу електронної пошти, а також змінити пароль. У кабінеті
можна переглянути та редагувати список обраних товарів, додати та змінити дані
банківської картки, керувати підпискою (підключити чи відмовитися), додати чи
змінити адресу доставки замовлень, переглянути історію замовлень, а також
отримати особисті промокоди на знижку. Також у кабінеті будуть доступні
налаштування додатку, можливість звернутися до служби підтримки, якщо
виникнуть проблеми чи запитання, та інформація про додаток (версія, розробники).
На головній сторінці додатку будуть відображатись поточні проєкти [74 - 75], а
також заготівлі.
Ще одним розділом додатку буде магазин, в якому можна подивитись роботи
інших і придбати макети з можливістю вивантаження коду. А також аукціон, якщо
один товар матиме кілька покупців.
Додаток буде розроблено для комп'ютерів на базі операційних систем Windows
та Linux. Розповсюджуватиметься за схемою безкоштовного завантаження з
внутрішньою підпискою. Користувачі зможуть завантажити додаток абсолютно
безкоштовно, але щоб отримати доступ до всіх функцій, необхідно придбати
підписку. Підписка коштуватиме 15$ на місяць, проте будуть й інші варіанти оплати,
крім щомісячного. Оформивши передплату на 6 місяців, рік або 2 роки, користувач
отримає знижку 5%, 10% або 15% відповідно. При реєстрації у додатку буде
22
мoжливість oтримати безкoштoвний прoбний період передплати нa 14 днів. Він буде
наданий користувачеві після введення даних банківської картки для оплати. Після
завершення пробного періоду термін дії підписки буде припинено, а користувачеві
випаде повідомлення про припинення підписки та можливість оформити її.
Користувач матиме можливість відмовитися від продовження підписки в будь-який
момент, натиснувши відповідну кнопку в особистому кабінеті.
Безкоштовна версія додатку буде містити обмежений набір функцій. Буде
надано доступ до всіх можливостей для створення мінімального функціоналу.
Платна версія надасть трохи розширений функціонал для створення сайту,
зокрема автоматичну підтримку, консультацію, а також деякі анімації та шаблони.
Також з кожної покупки в магазині додатка буде відніматися комісія 3%.
Отже, продукт – стартап десктопної системи для генерації сайтів. Назва
стартапу - "SGS" - Система Генерації Сайтів.
Перерахуємо основний функціонал додатку:
зручний та зрозумілий інтерфейс для взаємодії з основними елементами та
функціями додатку;
наявність ексклюзивних акційних пропозицій для користувачів;
інструментарій для створення шаблонів та додаток;
можливості придбати шаблон або взяти участь в аукціоні;
можливість вивантаження коду;
Додаток можна використовувати безкоштовно, але лише невелику частину
функціоналу. Весь функціонал буде доступний лише після придбання підписки за
ціною 15 USD/міс.
Запланована підтримка програми протягом, як мінімум 5 років після дати
випуску, оновлення раз на місяць.
1.3 Маркетингові дослідження та аналіз оточення стартапу
Для визначення слабких та сильних сторін продукту, загроз та можливостей
було проведено SWOT-аналіз. SWOT інтерпретується таким чином: S - сильні
23
сторони, переваги продукту, W - слабкі сторони, O - можливості, T - загрози.
Результати аналізу представлені на рисунку 1.1.
Рисунок 1.1 – SWOT - аналіз стартапу
Після визначення слабких та сильних сторін, загроз та можливостей було
сформовано шляхи регулювання стартапної ситуації для подальшої розробки.
Як скористатися можливостями? Наприклад:
розробити продукт;
вивести продукт на ринок;
провести якісну рекламну кампанію;
займатися регулярними оновленнями та підтримкою продукту.
Що може завадити скористатися можливостями? Наприклад:
недостатній рівень кваліфікації команди стартапу;
неякісне виконання своїх обов’язків працівниками;
24
вихід на ринок нових конкурентів.
За рахунок чого можна знизити загрози? Наприклад:
проведення якісного аналізу ринку;
планування та управління ризиками;
відбір кваліфікованих спеціалістів в команду стартапу.
Отже, дослідивши маркетингове середовище стартапу, можна стверджувати,
що він є перспективним, але потрібен більш детальний розрахунок його реалізації
для оцінки прибутковості та окупності стартапу.
1.4 Альтернативні ідеї реалізації стартапу та аналіз аналогів
З огляду на результат SWOT - аналізу (див. рис. 1.2) було проведено аналіз
альтернативних варіантів додатків для реалізації ідеї стартапу:
Додаток-Конструктор для створення сайтів.
Переваги: економія часу необхідного для створення сайтів; менша складність
розробки, значне зниження вартості розробки.
Недоліки: невелика функціональність; не вирішує поставлену проблему в
повному обсязі; відсутність формату підписки; немає можливості вивантажити код.
Додаток для доповнення коду.
Переваги: є деякі готові рішення для функціональності; невеликі витрати
коштів та години на розробку.
Недоліки: не вирішує поставлену проблему в повному обсязі; невелика
функціональність; відсутність формату підписки; користувачеві необхідні знання
розробки певною мовою без можливості вивантажити код.
Усі ці альтернативи вирішують поставлену проблему лише частково (або
економія коштів, або економія часу користувача), тому для реалізації проєкту був
обраний варіант додатку описаний в роботі.
В даний момент, на ринку дуже мало подібних розробок і вони мають більше
недоліків ніж переваг. Продукти конкурентів знаходяться у вищому ціновому
сегменті та пропонують менший функціонал.
25
Після дослідження ринку [16 - 23] було виявлено наступні аналоги та
конкуренти (табл. 1.10):
Таблиця 1.10 – Аналіз конкурентів
Назва Переваги Недоліки
Додаток «Wix» - зручний інтерфейс; - невелика
- швидке створення сайту. функціональність;
- немає можливості
вивантажити код.
Додаток «Squarespace » - швидке створення сайту. - має лише ознайомчий
характер;
- незручний інтерфейс;
- невелика
функціональність;
- немає можливості
вивантажити код.
Додаток «Shopify » - великий вибір анімацій; - має лише ознайомчий
- зручний інтерфейс; характер;
- швидке створення сайту. - невелика
функціональність;
- немає можливості
вивантажити код.
Отже, як видно з таблиці 1.10, основним конкурентом продукту даного
стартапу є додаток «Shopify». Проте він має більше недоліків ніж переваг над
розроблюваним в стартапі додатком. Всі інші аналоги мають обмежений функціонал
в порівнянні з продуктом даного стартапу та носять інформаційний характер.
Висновки до розділу 1
У розділі проаналізовано мету створення стартапу, визначено проблему, яку
необхідно вирішити. На основі проведених досліджень було сформовано декілька
26
ідей реалізації продукту стартапу, що повинні розв’язати поставлену проблему та
обрано серед них найкращу. Для обраної ідеї додатку був детально описаний
необхідний функціонал.
Проведено маркетингові дослідження, SWOT — аналіз. Аналіз ринку додатків
показав, що ринку дуже мало подібних розробок і вони мають більше недоліків ніж
переваг - продукти конкурентів знаходяться у вищому ціновому сегменті та
пропонують менший функціонал. Це свідчить про те, що обрана ідея продукту
стартапу є конкурентоспроможною та перспективною.
27
2 РОЗРОБКА КОНЦЕПЦІЇ СТАРТАПУ
2.1 Дерево цілей стартапу
Дерево цілей (Goal Tree) - це інструмент стратегічного управління, який
використовується для структурування і візуалізації головних цілей та підцілей
організації чи стартапу. Основні риси дерева цілей включають:
структурованість - дерево цілей надає структурований погляд на всі цілі
та підцілі, що допомагає в уникненні хаосу та неузгодженості в управлінні
стартапом;
логічна послідовність - воно визначає логічну послідовність досягнення
цілей та допомагає вирішити, які завдання потрібно виконувати спочатку, а
які можна відкласти на пізніше;
зв'язки між цілями - дерево цілей дозволяє визначити зв'язки та залежності
між різними цілями, що допомагає в плануванні та керуванні ресурсами та
часом;
оцінка прогресу - за допомогою дерева цілей легко відстежувати прогрес
досягнення цілей та визначати, наскільки близько ви до досягнення
основних мет;
вирішення пріоритетів - дерево цілей допомагає визначити, які цілі є
найважливішими та найбільш пріоритетними для стартапу;
звітність та комунікація - цей інструмент полегшує комунікацію між
учасниками стартапу, бо всі можуть бути впевнені, що розуміють
загальний маршрут досягнення цілей;
підвищення ефективності - дерево цілей допомагає уникнути розсіяння
уваги та зосередитися на досягненні ключових результатів;
аналіз та оптимізація - по завершенні стартапу дерево цілей може
використовуватися для аналізу результатів та ідентифікації можливостей
для покращення в майбутніх стартапах.
28
Загалом, дерево цілей є потужним інструментом управління стартапами, який
допомагає досягати успіху, уникати зайвих ризиків та забезпечує структурований та
систематичний підхід до досягнення цілей стартапу. Логіко-структурна схема
стартапу в табл. 2.1
Таблиця 2.1 – Логіко-структурна схема стартапу
Конкретні цілі Показники Індикатори
стартапу досягнення досягнення цілі
Порівняння конкурентів та
Проведення аналізу
формулювання цілей, етапів
конкуренції та розробка ТЗ
розробки та склад команди
Розробка основної технічної Планування архітектури
Розробка концепції
документації продукту
стартапу
Планування змісту,
Планування різних аспектів структуру, часу, бюджету,
стартапу ризиків, комунікації та
якості
Створення бази додатку, на
Розробка каркасу підставі якого буде
будуватись інші частини
Розробка алгоритму
автогенерації, який на
Реалізація системи
Розробка стартапу підставі певних даних
автогенерації
будуватиме основні шаблони
та деталі
Створення основних частин
Розробка та додавання всіх
продукту та розбудова
частин на каркас
зв'язків у єдину систему
Зменшення кількості
Виявлення і усунення
програмних помилок до
програмних помилок
мінімуму
Тестування і
Проведення регулярних
оптимізація Тестування основного
тестів основного
стартапу функціоналу
функціоналу
Оптимізація продуктивності Підвищення продуктивності
і швидкодії додатку та швидкодії додатку
29
Підготовка стартапу до Завершення всіх технічних і
Випуск стартапу
випуску виробничих процесів
Після проведення аналізу отриманих досліджень, можна створити дерево
цілей для стартапу. Цей інструмент є важливим для планування та управління
стартапом, оскільки допомагає чітко декомпозувати основні цілі стартапу.
Дерево цілей стартапу відображає структуровану ієрархію цілей,
розпочинаючи з загальних цілей та розгалужуючись до більш конкретних та
вимірюваних цілей. Дерево цілей стартапу забезпечує ясність та узгодженість між
цілями стартапу та діями, необхідними для їх досягнення. Це допомагає команді
стартапу розуміти, які конкретні результати повинні бути досягнуті та як вони
пов'язані між собою. Крім того, дерево цілей створює основу для подальшого
планування стартапу, розподілу ресурсів та контролю за досягненням цілей.
Будування дерева цілей сприяє систематизації цілей стартапу та забезпечує їх
належну організацію та структуру. Це важливий етап у розробці та управлінні
стартапом, який сприяє досягненню поставлених завдань для стартапу системи
генерації сайтів (рисунок 2.1).
Рисунок 2.1 – Дерево цілей стартапу
30
2.2 Зацікавлені сторони та їх вплив на стартап
Зацікавлені сторони стартапу (Stakeholders) – це особи, групи чи організації,
які мають інтерес, вплив чи важливість щодо конкретного стартапу. Ці особи або
групи можуть бути прямо або опосередковано задіяні в стартапі, а їхні інтереси та
очікування можуть впливати на результати та успіх стартапу.
За своєю суттю управління зацікавленими сторонами полягає в розумінні та
вирішенні потреб, занепокоєнь і очікувань тих, хто зацікавлений у результатах
вашого проекту. Це можуть бути як члени команди та клієнти, так і спонсори та
постачальники. Кожна зацікавлена сторона має власний унікальний набір очікувань і
впливу, що робить завдання управління ними ключовим аспектом успіху проекту.
Управління взаємодією з зацікавленими сторонами є важливою частиною управління
стартапом для досягнення підтримки, впливу та співпраці всіх сторін в процесі його
реалізації [50 - 53].
Розглянемо первинні та вторинні зацікавлені сторони та проаналізуємо їх
впливу на стартап впровадження інформаційної системи ризик-менеджменту в банку
(таблиця 2.2).
Таблиця 2.2 – Зацікавлені сторони та їх вплив
Зацікавлені сторони Інтереси Вплив
Інвестори Прибуток Визначення стратегічних
цілей та підтримка
інвестицій у стартап.
Фахівці з інформаційних Забезпечення Розробка, впровадження
технологій ефективності, безпеки та та підтримка технічної
надійності системи інфраструктури.
генерації.
Клієнти (Розробники, Забезпечення безпеки та Основні користувачі
дизайнери, зацікавлені конфіденційності їх даних забезпечують успіх
Первинні
31
компанії) самого стартапу, його
окупність та
популярність.
Аналіз впливу:
– інвестори - забезпечити ресурси та стратегічну підтримку стартапу;
– фахівці з IT - визначати технічні аспекти та розроблять різні аспекти
програми;
– клієнти - забезпечують успіх самого стартапу, його окупність та
популярність.
Ефективне врахування інтересів цих сторін підвищить шанси на успіх
стартапу створення десктопної системи генерації сайтів.
2.3 Визначення мети, цілей стартапу та критеріїв їх досягнення
Розглянемо дерево цілей стартапу стартапу створення десктопної системи
генерації сайтів:
Основна мета: Впровадження стартапу десктопної системи генерації
сайтів для скорочення часу та вартості розробки сайтів.
Основні цілі:
cтворення системи генерації сайтів - розробка та впровадження системи
для постійного моніторингу та аналізу ризиків у всіх аспектах діяльності
банку;
оптимізація процесів розробки сайтів - зменшення часу та зусиль,
необхідних для розробки IT-продукції;
зменшення витрат на розробку сайтів - забезпечення правильної роботи
програми зможе суттєво скоротити витрати на розробку IT-продукції;
вивантаження коду - унікальна можливість отримання готового коду для
подальшого вдосконалення поза системою;
32
надання максимальних різноманітних можливостей для створення IT-
продукції - різноманітний інструментарій забезпечить великі можливості
для створення авторського стартапу;
автогенерація - створення IT-продукції за допомогою завдань певних
параметрів без безпосереднього втручання людини. Це дерево цілей
стартапу відображає ієрархічну структуру цілей та вказує на взаємозв'язки
між ними, спрямовані на успішне впровадження стартапу десктопної
системи генерації сайтів.
Розглянемо критерії досягнення наведених цілей стартапу (таблиця 2.3).
Таблиця 2.3 – Критерій досягнення цілей стартапу
Ціль Критерій
Зменшення вартості розробки Значне зниження витрат на розробку
порівняно з використанням
стандартної команди
Зменшення часу розробки IT-продукції Значне зниження часу на розробку
порівняно з використанням
стандартної команди
Можливість вивантаження коду Унікальна можливість після
програми створення/придбання IT-продукції
вивантажити код для подальшої
експлуатації
Створення магазину для Можливість продавати готову
купівлі/продажу готової продукції продукцію для інших користувачів
Збільшення можливостей порівняно з Більший інструментарій збільшить
конкурентами інтерес
Автогенерація Можливість створення IT-продукції за
допомогою автогенеруючої системи
33
2.4 Опис продукту стартапу
Метою створення стартапу є проба вирішити поставлену проблему, а саме
створення продукту, що допоможе користувачам економити час та гроші та отримати
можливість вивантажувати код створеного стартапу.
В описі продукту стартапу "Управління стартапом створення десктопної
системи генерації сайтів " надамо детальний огляд самого застосунку. Він
складається із кількох основних частин.
користувач: логін, реєстрація, відновлення пароля та профіль, де можна
змінити свої дані;
основна частина: головна сторінка з переходом на поточні проєкти та
сторінки інформації про стартап;
генерація: основна сторінка редактора, де і створюються певні частини
програми та додатковий сторінці перегляду та завантаження коду;
блок магазину: стандартний набір сторінки товарів, конкретного товару,
оплати та аукціону, де виставлять унікальні роботи;
автогенерація: додатковий блок алгоритмів для отримання даних за
ключовими словами та завантаження їх у шаблон із формуванням готового
сайту з певної тематики.
Ці компоненти взаємодіють між собою, створюючи впізнаваний гармонійний
механізм, який забезпечує належне функціонування та взаємодію всіх аспектів
стартапу системи генерації сайтів.
Опис продукту також розкриває, на яких платформах буде доступним
продуктом. Ми розробляємо версії для комп'ютерів на операційних системах Unix i
Windows , щоб максимально охопити аудиторію користувачів. Це дасть користувачам
можливість користуватись нашим продуктом на більшості основних платформ і
забезпечить широкий доступ до нашого продукту
34
2.5 Життєвий цикл стартапу
Життєвий цикл стартапу розробки мобільного додатку для моніторингу цін на
продукти в супермаркетах складається з наступних фаз:
– ініціалізація;
– планування;
– реалізація;
– завершення.
Ключові фази стартапу, їх характеристика та перелік основних робіт
виглядають наступним чином (таблиця 2.4):
Таблиця 2.4 – Критерій досягнення цілей стартапу
Фаза Завдання
Ініціалізація розробка та опрацювання загальної концепції та стратегії
стартапу (розробка стратегії, визначення чітких цілей,
завдань, вимог, можливостей, обмежень, очікуваних
результатів стартапу);
розробка попереднього пакету основної документації по
стартапу (підготовка статуту стартапу; попереднє бачення
організаційної структури команди; погодження плану дій на
початковий період;);
формування команди;
розробка бізнес-плану;
прийняття рішення про реалізацію стартапу.
Планування коригування та затвердження попереднього пакету
базової стартапу документації;
розробка та затвердження плану управління стартапом
(розробка календарного плану; розробка плану виконання
робіт (WBS); планування ресурсів);
розробка основної документації стартапу (створення
схеми структури програми; створення схеми бази даних;
35
створення завдань та розподіл по спринтах; створення
технічної документації ризиків та дій)
встановлення комунікацій (розроблення процедур,
регламентів, політик діяльності та комунікації команди
стартапу; розроблення системи контролю інформації);
планування бюджету стартапу;
управління ризиками.
Реалізація управління, контроль та координація ходу виконання
стартапу;
виконання пакетів робіт;
вирішення конфліктів;
створення та узгодження ТЗ, створення концептуальної
схеми продукту;
розробка продукту (розробка дизайн-макету додатку;
верстка, розробка основного функціоналу додатку; проведення
тестування, виправлення помилок);
робота з постачальниками та органами влади (укладання
договорів; реєстрація ФОП);
розробка кампанії по просуванню продукту.
Завершення формальне завершення всіх етапів стартапу;
виведення продукту на ринок;
затвердження закриття стартапу (наказ про закриття
стартапу);
передача продукту замовнику;
розпуск команди стартапу;
проведення аналізу результатів (з погляду цілей стартапу,
ходу виконання стартапу, результатів стартапу);
архівація стартапу.
Результати стартапу за фазами життєвого циклу:
36
Фаза ініціалізація:
– розроблена загальна концепція та стратегія стартапу;
– узгоджений пакет основної документації по стартапу та статут стартапу;
– сформована команда стартапу.
Фаза планування:
– затверджений план управління стартапом;
– затверджений і створений план проведення рекламної кампанії;
– розроблена система контролю інформації та встановлені комунікації.
Фаза реалізація:
– узгоджені та створені ТЗ та концептуальна схема продукту;
– виконані пакети робіт;
– протестований, розроблений десктопний додаток;
– запущена рекламна кампанія та створені рекламні сторінки.
Фаза завершення:
– наказ про закриття стартапу;
– архівація стартапу;
– розпуск команди;
– закриті контракти.
Тепер можна визначити детальний зміст фаз життєвого циклу стартапу (табл.
2.5) з тривалістю та ключовими віхами.
Таблиця 2.5 – Зміст фаз життєвого циклу стартапу
Фаза Ініціалізація Планування Реалізація Завершення
Тривалість 30 50 250 20
фази (дні)
Перелік - Формування - Планування - Реєстрація - Розміщення
основних команди змісту ФОП додатку в
робіт - Формалізація - Планування - Вибір магазинах
ідеї трудових технології - Розпуск команди
- Аналіз ринку ресурсів
- Проектування - Архівація
- Розробка - Планування архітектури стартапу
бізнес-плану бюджету додатку
- Аналіз стартапу
37
- Планування - Створення
ризиків структури
- Планування додатку
якості - Розробка
- Планування дизайну
часу - Створення
- Планування прототипу
комунікацій - Тестування
- Планування - Заключення
закупівель договорів з
- Розробка постачальника
концепту ми
- Розробка ТЗ - Реалізація
додатку
- Створення
рекламних
сторінок
- Запуск
реклами
Ключові Прийняте Всі плани Готовий Стартап у релізі
віхи рішення стартапу десктопний
затверджені додаток
Можливі Ідея може Планування Наявних Продукт може
проблеми виявитися може бути не ресурсів може виявитися
недоцільною і дуже якісним не вистачити недостатньо
неактуальною і точним для успішної якісним,
для реалізації через реалізації функціональним,
недостатню продукту конкурентоспромо
кваліфікацію стартапу жним, чи
неактуальним
Отже, тривалість всього життєвого циклу стартапу становить 350 робочих
днів або 17 місяців. Обмеження за часом виконання стартапу – 18 місяців, тому
запланована тривалість стартапу відповідає встановленому обмеженню. Фаза
ініціалізації триває 30 робочих дні, фаза планування - 50. Найдовша фаза –
реалізація, вона триває 150 робочих днів, найкоротша – завершення, тривалість якої
становить 20 робочих днів.
38
Як було зазначено на початку розділу, ефективність стартапу
оцінюватиметься рівнем прибутку та кількістю нових клієнтів після реалізації
продукту.
Висновки до розділу 2
У розділі розроблено концепцію стартапу, а саме визначені цілі та завдання
стартапу, критерії успішності, обмеження та допущення. Проведено аналіз
зацікавлених сторін, в результаті якого визначено механізм участі та цілі кожного
учасника стартапу. Проаналізувавши усі фактори, можна зробити висновок, що
зацікавлені сторони позитивно впливають на стартап, тому що кожен має свою
вигоду. Логічним завершенням розділу є обґрунтований стратегічний план, на
основі якого сформовано фази життєвого циклу та зроблений прогноз очікуваних
результатів кожної фази стартапу.
39
3 ПЛАНУВАННЯ ТА УПРАВЛІННЯ СТАРТАПОМ
3.1 Планування змісту та обмеження стартапу
Планування змісту стартапу починається з визначення кінцевого результату –
продукту стартапу. В даному стартапі продуктом стартапу є десктопна система
генерації сайтів.
Наступним кроком були визначені високорівневі вимоги до кінцевого
результату стартапу і занесені до таблиці 3.1.
Таблиця 3.1 – Високорівневі вимоги до кінцевого результату стартапу
Назва вимоги
1 Наявність ексклюзивних акційних пропозицій для користувачів
2 Можливість додати необхідні товари в список «Обраних» та відслідковувати
актуальні ціни в різних супермаркетах одночасно
3 Усі супермаркети відображаються на карті відповідно до геолокації
користувача
4 Наявність актуальних цін і інформації про наявність товарів
5 Можливість замовити доставку
6 Можливість обрати необхідний товар та відстежити його наявність в
найближчих супермаркетах
Декомпозиція застосовується у всіх предметних галузях. Це базовий
інструмент планування та управління проектами. Він допомагає організувати бізнес-
процеси у будь-якій сфері діяльності: від розробки IT-продуктів до будівництва
промислових об'єктів. Якщо розбити складне завдання на прості складові та
деталізувати їх, це допоможе скласти план дій. З допомогою декомпозиції можна
оцінити можливості команди, як взяти новий проект. Слід представити його як
послідовність кроків та оцінити, скільки часу та ресурсів знадобиться для кожного
40
етапу. Чи стане зрозуміло, чи зможе команда виконати роботу вчасно. Для деталізації
кінцевого результату стартапу була створена схема декомпозиції (Рисунок 3.1).
Рисунок 3.1 – Декомпозиція кінцевого результату стартапу
Управління змістом стартапу включає в себе процес забезпечення того, щоб у
стартап входили лише ті роботи, які необхідні для успішної реалізації стартапу.
Процес управління змістом стартапу включає планування змісту, визначення змісту,
побудова WBS, підтвердження змісту та управління змістом [29]. Основними
роботами по стартапу що розробляється є:
розробка проєктної документації та узгодження стартапу.
формування стратегії стартапу.
створення ТЗ.
створення концептуальної схеми продукту.
розробка дизайну продукту.
розробка основного функціоналу продукту.
тестування системи.
підписання документації про передачу продукту замовнику.
запуск продукту у комерційну експлуатацію.
41
розробка та проведення рекламної кампанії по просуванню продукту
стартапу.
На основі наведеного переліку створено структуру декомпозиції робіт (WBS)
стартапу.
WBS визначає роботи, що необхідні для досягнення цілей стартапу.
З’ясовуються терміни виконання орієнтованих на результат та ієрархічно
взаємопов’язаних елементів (пакетів робіт – комплексів робіт, згрупованих за
заданими критеріями).
Кожен рівень декомпозиції забезпечує послідовну деталізацію змісту стартапу,
дозволяючи оцінити об’єм виконаних робіт, засвоєний бюджет і виконання у
відповідності до встановлених термінів.
Пакетам робіт нижчого рівня повинні відповідати менші за об’ємами роботи.
Це значно спрощує оцінку відсотка виконання та дозволяє більш чітко визначити дії
для досягнення цілей стартапу.
Структура декомпозиції робіт містить наступні характеристики:
описує зміст робіт в стартапі;
визначає весь об’єм робіт стартапу;
сформована у вигляді ієрархічної структури;
має вимірювальний або об’єктивний результат, який розглядається як
сукупність результатів робіт та результат роботи по пакету.
При розробці WBS стартапу потрібно дотримуватися наступних правил:
кожен елемент WBS повинен забезпечувати досягнення помітного
результату;
кожен елемент WBS має бути набором усіх підпорядкованих елементів,
перерахованих безпосередньо під ним;
декомпозиція результатів, від верхнього рівня до нижнього, повинна мати
логічний зв'язок;
42
результати пакетів робіт мають бути унікальними і відрізнятися від
результатів пакетів робіт того самого рівня. Вони мають бути розбиті до
рівня деталізації, який забезпечує успішне координацію, контроль та
планування робіт, пов’язаних з досягненням поставлених цілей;
процес розробки WBS повинен бути гнучким механізмом, який дозволяє
коригувати WBS, особливо враховуючи, що обсяг робіт стартапу може
змінюватися. Коли зміст стартапу змінюється, WBS необхідно переглянути;
кожен елемент WBS, який представляє обсяг робіт повинен бути
узгоджений безпосередньо з відповідними елементами підрядника;
усі пакети робіт повинні відповідати організаційній структурі та структурі
витрат;
з WBS має бути виключене дублювання робіт.
WBS розробляється шляхом ітераційного розгляду результатів і цілей стартапу,
досягнення функціональності, обсягу робіт і реалізації технічних вимог. Верхні рівні
WBS можуть бути розроблені на ранніх концептуальних стадіях стартапу. Після
визначення стартапу та підготовки специфікацій WBS може бути додатково
деталізована.
Структуру розподілу робіт (WBS) можна розробити «з нуля» або
використовуючи компоненти вже створеної WBS з раніше реалізованого подібного
стартапу.
Під час розробки WBS стартапу першим кроком є визначення кінцевого
результату стартапу — створений та впроваджений додаток для смартфонів.
Другим кроком є визначення основних пакетів робіт і підпорядкованих їм
завдань, які необхідні для отримання кінцевого результату (продукту) стартапу.
Далі необхідно визначити тривалість робіт та зв’язки між ними. Деякі роботи
можуть виконуватися одночасно, інші ж тільки після завершення попередніх.
Кінцева WBS стартапу відображена в таблиці 3.2.
Таблиця 3.2 – WBS стартапу
43
№ 1-го № 2-го № 3-го Назва роботи Оцінка тривалості
рівня рівня рівня
1 Розробка додатку "SGS" 350 днів
1.1 Ініціація 30 дні
1.1.1 Формування команди 5 днів
1.1.2 Формалізація ідеї 7 днів
1.1.3 Аналіз ринку 12 днів
1.1.4 Розробка бізнес-плану 5 днів
1.1.5 Прийняте рішення замовником 0 днів
1.2 Планування 50 днів
1.2.1 Планування якості 4 днів
1.2.2 Планування змісту 5 днів
1.2.3 Планування трудових ресурсів 3 днів
1.2.4 Планування бюджету 3 днів
1.2.5 Планування часу 5 днів
1.2.6 Планування ризиків 7 днів
1.2.7 Планування комунікацій 5 днів
1.2.8 Планування закупівель 6 днів
1.2.9 Розробка ТЗ 5 днів
1.2.10 Вибір технології 5 днів
1.2.11 Проектування архітектури 8 днів
додатку
1.2.12 Всі плани стартапу затверджені 0 днів
замовником
1.3 Реалізація 150 днів
1.3.1 Реєстрація ФОП 5 днів
1.3.2 Розробка концепту 10 днів
1.3.6 Створення структури додатку 20 днів
1.3.7 Розробка дизайну 30 днів
1.3.8 Створення прототипу 10 днів
1.3.9 Тестування 10 днів
1.3.10 Заключення договорів з 5 днів
постачальниками
44
1.3.11 Реалізація додатку 50 днів
1.3.12 Створення рекламних сторінок 5 днів
1.3.13 Запуск реклами 5 днів
1.3.14 Готовий додаток 0 днів
1.4 Завершення 20 днів
1.4.1 Розміщення додатку в магазинах 5 днів
1.4.2 Розпуск команди 5 днів
1.4.3 Архівація стартапу 3 дні
1.4.4 Аналіз стартапу 3 дні
1.4.5 Стартап закритий 0 днів
Тривалість робіт є приблизною на даному етапі, тому що не врахований об’єм
ресурсів на виконання кожної задачі.
Обмеження стартапу загалом виходить 350 днів.
Припущення стартапу - вимушена затримка допустима близько 6 місяців,
тобто близько 530 днів.
Загальна затримка по задачам склала 30 днів, отже загальний час виконання
стартапу збільшився до 560 робочих днів. Відхилення по часу не є критичними, тому
що не перевищують заплановані допущення стартапу.
3.2 Організаційна структура стартапу
Команда стартапу – це певна група людей, які разом працюють над
досягненням спільної мети, реалізацією стартапу та підпорядковані керівнику
(менеджеру) стартапу [29].
Основні організаційні завдання побудови [70 - 73] стартапної команди:
– забезпечення підтримки керівництва і стабільно сприятливого
навколишнього середовища.
– створення професійно-стимулюючого оточення;
– забезпечення кваліфікованим технічним персоналом;
– здійснення грамотного керівництва;
45
Члени команди повинні бачити себе частиною команди стартапу та виробити
спільні цінності та норми, перш ніж вони зможуть працювати разом як команда.
Для розвитку команди можуть бути використані наступні шляхи:
аналіз та підбір членів команди з точки зору психологічної сумісності;
проведення семінарів, організація курсі.
Для ефективної діяльності команди менеджер стартапу повинен:
забезпечити своєчасне розподіл і планування роботи;
розподілити функціональні обов’язки;
чітко пояснити завдання та цілі, уникати конфліктів та долати перешкоди;
визначити організаційну структуру команди.
Команда стартапу була сформована із спеціалістів, що володіють знаннями і
навичками, необхідними для ефективного досягнення цілей стартапу [47 - 49].
Схему оргструктури команди стартапу наведено на рисунку 3.2.
Рисунок 3.2 – Організаційна структура стартапу
Команда стартапу складається з 7 осіб: проєктного менеджера, головного
програміста, програміста, дизайнера, маркетолога, тестувальника та юриста.
Проєктний менеджер є керівником стартапу і йому підпорядковуються усі інші
учасники команди [54 - 59]. Це спеціаліст, який піклується про чітке та своєчасне
виконання замовлення. Він спілкується з клієнтом, фіксує його вимоги, підбирає
команду та стежить за тим, щоб співробітники виконали свою частину роботи якісно
та вчасно. Фахівець із проектів повинен добре розуміти, який результат потрібен
клієнту і що потрібно для того, щоб його досягти: кого потрібно буде включити до
команди, які витрати запланувати та скільки часу займе робота. Роль проектного
46
менеджера може змінюватись у різних організаціях. Деякі компанії можуть мати
спеціалізованих проектних менеджерів, які працюють лише у певних галузях,
наприклад, в IT чи будівництві. Інші наймають проектних менеджерів загального
профілю, які працюють з різними типами проектів.
Схему оргструктури команди стартапу наведено на рисунку 3.3.
Рисунок 3.3 – Учасники стартапу
На основі розроблених організаційної структури виконавців проєкту та
структури декомпозиції робіт розподіляється відповідальність учасників проєкту по
основним проєктним роботам. В результаті формується матриця відповідальності
(табл. 3.3), в якій визначаються ролі виконавців у різних роботах і фазах проєкту.
Таблиця 3.3 – Матриця відповідальності
Ресурси
Проєктний
менеджер
Маркетолог
Дизайнер
Програміст
Тестувальник
Юрист
47
1.1.1 Формування команди RP
1.1.2 Формалізація ідеї RP
1.1.3 Аналіз ринку RP
1.1.4 Розробка бізнес-плану RP
1.2.1 Планування якості RP
1.2.2 Планування змісту RP P
1.2.3 Планування трудових RP
ресурсів
1.2.4 Планування бюджету RP
1.2.5 Планування часу RP
1.2.6 Планування ризиків RP
1.2.7 Планування комунікацій RP
1.2.8 Планування закупівель RP
1.2.3 Розробка ТЗ P RP
1.3.4 Вибір технології RP
1.3.5 Проектування RP
архітектури додатку
1.3.1 Реєстрація ФОП RP P
1.3.2 Розробка концепту RP P P
1.3.6 Створення структури RP
додатку
1.3.7 Розробка дизайну RP
1.3.8 Створення прототипу P RP
1.3.9 Тестування RP
1.3.10 Заключення договорів з R P
постачальниками
1.3.11 Реалізація додатку P RP
1.3.12 Створення рекламних RP
сторінок
1.3.13 Запуск реклами RP
1.4.1 Розміщення додатку в RP P P
магазинах
1.4.2 Розпуск команди RP
1.4.3 Архівація стартапу RP
1.4.4 Аналіз стартапу RP
R – Відповідальний P – Виконавець
3.3 Розробка календарного плану стартапу
Загальною функцією календарного планування є визначення та фіксування
календарних дат виконання усіх робіт з метою координації діяльності виконавців,
залучених до стартапу, та забезпечення його успішного завершення.
Основні цілі календарного планування:
контроль ходу виконання стартапу;
забезпечення своєчасного надходження фінансування;
Задачі
48
своєчасне забезпечення ресурсами, визначення ступеню завантаження
ресурсів, коригування;
забезпечення своєчасного виконання стартапу.
Розробка календарного плану стартапу завжди носить ітеративний характер,
оскільки в ході роботи необхідно неодноразово повертатися до попередніх етапів,
щоб уточнити і наблизити їх до реальності, або поступово наблизити попередні
варіанти до найкращих досяжних значень [16].
Розроблений на даному етапі календарний план стартапу є першим
наближенням прогнозу до його реалізації. У процесі реалізації стартапу цей прогноз
уточнюється з урахуванням як фактичного, так і планового виконання показників
ефективності стартапу. В ідеалі фактичний стан стартапу має відповідати його
прогнозу наприкінці стартапу.
Переваги комп'ютерних систем управління проєктами найкраще проявляються
в процесі створення календарного плану стартапу та можливості швидкого
прогнозування ходу його реалізації.
Приступаючи до календарного планування, необхідно визначити повний
перелік робіт та пакетів робіт [27 - 31].
При розробці календарного плану стартапу було використано розроблену
структуру декомпозиції робіт стартапу.
Спочатку необхідно ввести повний перелік пакетів робіт та робіт стартапу (рис.
49
3.3).
Рисунок 3.3 – Вікно стартапу з введеним переліком робіт
Після складання переліку робіт стартапу необхідно визначити їх тривалість.
Поле часової діаграми містить лінії діаграми, які закінчуються та починаються
одночасно.
Наступним кроком буде:
– визначення тривалості виконання (дата початку і дата закінчення або
тривалість роботи) підлеглих робіт;
– визначити дату початку роботи найпростіше за допомогою календаря, який
відкривається в комірці стовпця Start навпроти назви роботи;
– встановлення взаємозв’язку між роботами, оскільки лише враховуючи
послідовність робіт, система може розрахувати часовий графік проєкту та
представити його на діаграмі.
Існує чотири типи зв’язків між роботами: старт до старту, фініш до фінішу,
фініш до старту та старт до фінішу (Start to Start (SS), Finish to Finish (FF), Finish to
Start (FS), Start to Finish (SF)) [32]. За замовчуванням зв’язок між роботами проєкту є
зв'язком фініш до старту, тобто, послідовним.
При встановленні зв'язку між роботами необхідно враховувати часові межі
роботи, які можуть бути наступних типів [36]:
As Late As Possible (ALAP) - так пізно, як це можливо;
As Soon As Possible (ASAP) - так швидко, як це можливо;
Finish No Earlier Than (FNET) - фініш не раніше, ніж;
Finish No Later Than (FNLT) - фініш не пізніше, ніж;
Must Finish On (MFO) - фініш на визначену дату;
Must Start On (MSO) - старт визначеної дати;
Start No Earlier Than (SNET) - старт не раніше, ніж;
Start No Later Than (SNLT) - старт не пізніше, ніж.
50
Також необхідно враховувати конкретні дати для часових обмежень. Для
кожного типу обмеження, суть і призначення якого стає зрозумілим після введення
послідовності виконання робіт, логічно ввести лише кілька часових параметрів.
На початку визначення зв'язків між роботами проєкту було встановлено
обмеження типу ASAP для всіх робіт, які пізніше були скориговані для окремих робіт.
Після виконання зв’язків робіт календарний план стартапу мав наступний
вигляд (рис. 3.4):
Рисунок 3.4 – Вікно стартапу з вказаними зв’язками між роботами
51
3.4 Планування трудових та матеріальних ресурсів стартапу
Для продовження планування проєкту, потрібно вказати, які ресурси будуть
використовуватися для виконання кожної роботи – призначити ресурси до робіт
проєкту.
Під ресурсами у проєкті розуміють робочу силу, обладнання, матеріали та
гроші, що необхідні для виконання робіт, і є передумовами для реалізації будь-якого
проєкту.
Дуже важливим питанням є складання та оцінка потреб у ресурсах, умов їх
надходження та забезпечення їх повного та ефективного використання.
Планування ресурсів починається з визначення того, що є ресурсами, тобто
складання переліку людей і обладнання, необхідних для виконання проєктних робіт.
Це можна зробити двома способами:
– cкласти перелік ресурсів, а потім за допомогою нього призначати ресурси
до робіт;
– призначати ресурси для кожної роботи, таким чином формуючи їх перелік.
Оскільки відомі всі ресурси проєкту, простіше використати другий спосіб з
наведених вище.
Використовуючи меню View, Resource Sheet, на екрані з'явиться таблиця
ресурсів усіма доступними характеристиками, а саме:
Resource Name - назва ресурсу;
Type - тип (працівник, матеріал);
Material Label - позначення матеріалу;
Initials - абревіатура працівника;
Group - група;
Max. Units - максимальна "задіяність";
Std. Rate - звичайний тариф оплати (протягом робочого часу);
Ovt. Rate - тариф оплати за роботу в неробочий час;
Cost/Use - одноразові витрати;
52
Accrue At - форма оплати (аванс, погодинно, по факту);
Base Calendar - базовий календар ресурсу;
Code - код ресурсу.
3.5 Планування якості стартапу
У стартапі використовується така концепція формування якості:
формування корпоративних рекомендацій з якості (на основі стандартів
серії ISO 9001), що визначають основні методи забезпечення якості та
структуру документів системи забезпечення якості;
виконання усіх робіт в стартапі з урахуванням попередньо узгоджених і
затверджених рекомендацій з якості;.
впровадження технології управління стартапами як складової частини
системи управління якістю.
забезпечення підвищення кваліфікації членів команди.
обов’язково сертифікаційне обладнання, ліцензійне програмне
забезпечення.
кожен виконавець несе відповідальність за якість своєї праці.
контроль якості на всіх етапах стартапу.
Визначимо заходи щодо досягнення якості на кожній з фаз стартапу:
фаза ініціалізації - комплексний аналіз ринку та об'єктивне визначення
потреб та очікувань потенційних клієнтів, повнота статуту стартапу та
техніко-економічного обґрунтування;
фаза планування - якість та повнота створених основних нормативних
документів та інструкцій, проєктних структур, оцінки ризиків тощо,
розробка процедур командоутворення та рекомендацій щодо налагодження
ефективних комунікацій стартапу;
фаза реалізації. - відповідність результатів робіт вимогам корпоративної
настанови з якості (ISO 9001), та загальновизнаним стандартам якості,
53
забезпечення високоякісного технічного тестування продукту для
максимального виявлення помилок і недоліків до завершення етапу
впровадження, проведення користувацького тестування;
фаза завершення - складання звітів про результати стартапу, повнота та
якість архіву стартапу, оцінка фактичних термінів виконання стартапу,
фактичного бюджету і якості продукту стартапу.
Ключові показники якості наведені у таблиці 3.4.
Таблиця 3.4 – Показники якості
Показни Цільове Допустиме Опис Відповідал Контролю Робота або
ки значення значення показників ьні за ючий фаза проєкту
якості якість
Підтрим мультипл Window Версії Програміст Менедже Фаза
ка атформен 10+ операційних р проєкту планування,
операцій ність Unix систем на яких Фаза
них (Linux, має працювати реалізації
систем Debian) додаток
Час До 3х До 5ти Час за який має Програміст Менедже Фаза
заванта секунд секунд бути р проєкту планування,
ження завантажений Фаза
додатку додаток на реалізації
смартфоні
Час До 2х До 5ти Час за який має Програміст Менедже Фаза
оновлен секунд секунд бути р проєкту планування,
ня оновлений/відо Фаза
контент бражений реалізації
у контент на
екрані
смартфона при
користуванні
додатком
Швидкіс До 10ти До 15ти Час за який Програміст Менедже Фаза
ть секунд секунд додаток має р проєкту планування,
визначе визначити Фаза
ння геолокацію реалізації
геолокац користувача та
ії відобразити
користу найближчі
вача супермаркети
на карті
Час Виконанн Допустиме Виконання Менеджер Замовник На всіх
виконан я в термін відхилення робіт в термін проєкту фазах
ня не більше впливає на
поставле 2х тижнів бюджет
них зазначеног проєкту
54
задач о терміну
Надійніс 100% 100% Відповідність Програміст Менедже На фазі
ть кінцевих , р проєкту реалізації
виконан результатів тестувальн
их робіт поставленим ик,
цілям, дизайнер
перевірка
кінцевого
результату
згідно до
погоджених
специфікацій
та дизайну
додатку для
кожної
операційної
системи на всіх
етапах робіт
3.6 Планування бюджету та управління закупівлями
Наведемо орієнтовну структуру бюджету та оцінку основних витрат, які
потрібно врахувати [60 - 66]:
зарплата команди - це найбільша частина витрат стартапу. Включає в себе
зарплату розробників, дизайнерів, тестувальників та інших фахівців, які
беруть участь у стартапу.
обладнання та програмне забезпечення - витрати на комп'ютери, сервери,
ліцензії на розробницьке ПЗ, інструменти розробки та тестування.
витрати на тестування - включають в себе витрати на найм тестувальників,
придбання тестового обладнання та програмного забезпечення для
тестування, а також витрати на виправлення виявлених помилок.
витрати на дизайн та графіку - оплата дизайнерів та ілюстраторів,
придбання необхідного програмного забезпечення та ресурсів для
створення графічного контенту.
витрати на маркетинг і рекламу - реклама і просування гри, включаючи
розробку веб-сайту, соціальних медіа-кампаній та інших маркетингових
заходів.
55
витрати на адміністрування та управління стартапу - включають в себе
витрати на оренду офісу, оплату послуг, що необхідні для функціонування
команди та стартапу, а також оплату проєктного менеджмента.
резервний бюджет - додаткові кошти для непередбачених витрат і
непередбачуваних ризиків.
Варто враховувати, що це лише загальний перелік витрат, і визначення
конкретного бюджету потребує більш докладного аналізу. Точна оцінка витрат буде
залежати від умов стартапу та обраної стратегії розробки. Також важливо
враховувати можливі зміни в ході стартапу та резервний бюджет для їх нейтралізації.
Для орієнтовного визначення бюджету стартапу розглянемо більш детально
витрати які передбачені в межах даного стартапу (табл. 3.5 – 3.10).
Таблиця 3.5 – Витрати на адміністратвно-господарські послуги
№ Найменування витрат Тариф Період Сума (грн.)
(грн/міс) (міс)
1 Оплата провайдеру за 200 18 36 000
інтернет
Сума витрат: 36 000
Таблиця 3.6 – Витрати на обладнання стартапу
№ Найменування Число, Ціна, Сума,
(шт) (грн за шт) (грн)
1 Серверне обладнання 2 40 000 80 000
2 Ноутбук 6 45 000 270 000
Сума витрат: 350 000
Таблиця 3.7 – Резервний бюджет стартапу
№ Найменування Сума, грн
1 Несправність технічних засобів 150 000
56
2 Сфера послуг 60 000
3 Організаційно-економічні втрати 100 000
Сума витрат 310 000
Таблиці 3.8 – Витрати на зарплату команди стартапу
№ Посада Кількість Ставка в Період Сумарна
осіб місяць,(г роботи, вартість
рн) (міс) робіт (грн)
1 Менеджер стартапу/ 1 120 000 18 2 160 000
Головний розробник
2 Розробник 1 80 000 18 1 440 000
3 Юрист (приватна 1 90 000 1 90 000
консульстація)
4 Маркетолог 1 60 000 3 180 000
5 UX/UI Дизайнер 1 70 000 5 350 000
Сума витрат: 4 220 000
Таблиця 3.9 – Витрати на рекламу та маркетинг
Бюджет, Сумарна вартісь
Назва ресурсу Ads Період
(грн/міс) витрат, (грн)
Google 1 міс. – 6 міс. 15 000 75 000
Facebook 1 міс. – 6 міс. 15 000 90 000
Instagram 1 міс. – 6 міс. 15 000 75 000
Сума витрат: 240 000
57
Таблиця 3.10 – Загальна таблиця витрат
№ Найменування Сумарна
вартість,
грн
1 Сумарна вартість витрат на зарплату стартапу 4 220 000
2 Сумарна вартість витрат на обладнання 350 000
3 Сумарна вартість адміністративно-господарських витрати 36 000
4 Резервний бюджет 310 000
5 Сумарна вартість витрат на маркетинг та рекламу 240 000
Сума витрат: 5 156 000
Планування та контроль витрат є необхідними для ефективного управління
стартапом, забезпечуючи фінансову стабільність, досягнення цілей стартапу та
ефективне використання ресурсів.
Управління закупівлями – це комплекс стратегічних та оперативних дій,
спрямованих на ефективне та ефективне придбання товарів, послуг чи робіт,
необхідних для функціонування організації або реалізації стартапу. Цей процес
охоплює весь цикл закупівлі, починаючи від визначення потреб, вибору
постачальників та укладання угоди, і завершуючи контролем за виконанням угоди та
оцінкою результатів.
Основні аспекти управління закупівлями включають:
– аналіз потреб - визначення, які товари, послуги або роботи необхідні
організації для досягнення своїх цілей.
– вибір постачальників - оцінка та вибір постачальників, з якими будуть
укладені угоди. Це може включати оцінку їхньої надійності, якості та
цінової конкурентоспроможності.
– укладання угод - формалізація взаємовідносин з постачальниками через
укладення контрактів або угод.
– замовлення та поставки - оформлення замовлень та контроль за доставкою
товарів чи наданням послуг.
58
– контроль та оцінка - моніторинг виконання угоди, якість товарів або послуг
та витрати, а також оцінка ефективності постачальників.
– ризик-менеджмент - ідентифікація та управління ризиками, пов'язаними із
закупівлями, такими як зміни в цінах, забезпеченість поставками та інші.
Ефективне управління закупівлями допомагає організаціям зменшити витрати,
підвищити якість отримуваних товарів та послуг, забезпечити надійність
постачальників та знизити ризики
У стартапі здійснюється закупівля навчальних курсів та літератури. Всі ці
покупки повинні відповідати плануванню бюджету та встановленим критеріям
якості. Оформлення договорів на проведення навчання передбачається у письмовій
формі, а оплата буде проводитися безготівковим способом. Закупівля літератури
передбачає оплату готівкою з видачею чека для обліку.
Процес закупівлі навчальних курсів починається з розробки докладних вимог
до курсу, визначення критеріїв якості навчання та оцінки набутих навичок. Пошук
лекторів спочатку проводився серед наявних фахівців, а потім на зовнішньому ринку
навчальних курсів.
Закупівля навчальних курсів реалізується через такі процедури:
конкурс;
тендер;
покупка від ліцензованого навчального центру або провідного учасника
цільового ринку.
При виборі постачальників навчальних курсів на зовнішньому ринку основні
критерії включають в себе вартість, післянавчальну підтримку, репутацію та
швидкість поставки.
3.7 Управління ризиками
Метою управління ризиками є зниження ймовірності настання ризикових
подій, що негативно впливають на процес реалізації стартапу, та підвищення
59
ймовірності настання подій, що позитивно впливають на процес реалізації стартапу
[24]. Загальний процес управління ризиками наведено на рисунку 3.5.
Планування
Ідентифікація Якісний Кількісний Планування Моніторинг та
управління
ризиків аналіз ризиків аналіз ризиків реагування контроль
ризикам
Рисунок 3.5 – Схема процесу управління ризиками
У стартапі, що розробляється, застосовуються такі процеси управління
ризиками [57]:
планування управління ризиками – процес визначення підходів та
планування операцій по управлінню ризиками стартапу;
ідентифікація ризиків – це ітеративний процес, який передбачає
визначення та документування характеристик ризиків, які можуть
вплинути на стартап;
якісний аналіз ризиків включає встановлення пріоритетів ризиків,
результати якого використовуються пізніше (у процесі кількісного аналізу
ризиків або при плануванні реагування на ризики);
кількісний аналіз ризиків проводиться щодо тих ризиків, які визначені в
процесі якісного аналізу як ті, що потенційно або суттєво впливають на
конкурентоспроможну якість продукту. У процесі кількісного аналізу
ризиків оцінюється вплив ризикових подій і присвоюється числова оцінка;
планування реагування на ризики – процес розробки шляхів та визначення
дій для збільшення можливостей і зменшення загроз для цілей стартапу;
моніторинг та управління ризиками – процес виявлення, аналізу та
планування повторних ризиків, відстеження виявлених і перерахованих
ризиків для постійного моніторингу, перегляду та впровадження заходів
реагування на ризики та оцінки їх ефективності.
Щоб оцінити вплив ризикових подій на процес реалізації стартапу, було
використано наступну шкалу:
«0» - ризик не має ніякого впливу;
60
«0.05» - ризик має мінімальний вплив;
«0.1» - ризик має невеликий вплив;
«0.2» - ризик має помірний вплив;
«0.4» - ризик має великий вплив;
«0.8» - ризик має надмірно великий вплив.
Розподілимо ймовірність настання ризикової події на такі діапазони (від 0 до 1,
де 0 – подія неможлива, 1 – подія що точно відбудеться):
< 0.2 – дуже низька;
0.2 - 0.4 – низька;
0.4 - 0.6 – середня;
0.6 - 0.8 – велика;
0.8 - 1.0 – дуже велика.
Було сформовано таблицю ризиків стартапу (табл. 3.11), яка містить наступні
дані:
Таблиця 3.11 – Ризики стартапу
Вид Ризикова Умова Наслідки
подія виникнення
Управлінс Помилки у людський зрив календарного плану,
ький плануванні фактор додаткові витрати на
позапланові ресурси
Ризик Невиконання халатність затримки у стартапі пов’язані із
персоналу умов постачальникі пошуком нових постачальників
контрактів в, або переглядом умов
постачальник невизначеності контрактів та угод
ам в умовах
Контрактів та
угод
Фінансови Збільшення зростання цін призупинення стартапу аж до
61
й бюджету на товари та його закриття
стартапу послуги
Фінансови Припинення відсутність призупинення стартапу на
й фінансування грошей, криза невизначений термін
стартапу
Ризик Низька бажання низька якість виконаних робіт,
персоналу кваліфікація економити на додаткові втрати часу на
членів виконавцях виправлення помилок
команди
Ризик Низька слабке затримки у виконанні робіт,
персоналу мотивація фінансування, низька якість робіт
команди високі
навантаження
Технічний Збій у роботі вихід з ладу втрата часу на ремонт або
обладнання певних блоків постачання нового обладнання,
обладнання додаткові витрати
Ринковий Інфляція природне зростання цін на товари та
явище послуги поза бюджетом
Ринковий Коливання економічна зростання цін на товари та
курсу криза послуги поза бюджетом
Маркетин Вихід на збільшення втрата актуальності продукту
говий ринок нових популярності стартапу
конкурентів ринку
Маркетин Малоефектив невірно невиконання планів продажів,
говий не складена втрата частки ринку
просування маркетингова
продукту на компанія,
ринку недостатнє
фінансування
62
реклами
Форс- Пандемія ситуація у світі затримки в стартапі, проблеми
мажорний з фінансуванням, призупинення
стартапу
Форс- Відсутність перебої в затримки в стартапі, додаткові
мажорний електропоста електропостач витрати
чання анні
Визначимо ймовірність настання того чи іншого ризику та його вплив на
стартап (табл. 3.12):
Таблиця 3.12 – Ймовірність настання ризиків стартапу
№ Назва ризику Ймовірніс Вплив на
ть стартап
виникнен
ня
1 Технічні ризики 0,1 0,4
2 Фінансові ризики 0,2 0,8
3 Ризики персоналу 0,4 0,4
4 Маркетингові ризики 0,1 0,4
5 Управлінські ризики 0,3 0,6
6 Форс-мажорні ризики 0,5 0,8
7 Ринкові ризики 0,1 0,4
Для комплексної оцінки можливих наслідків впливу ризикової події на стартап
формується матриця аналізу ризиків (табл. 3.13).
Таблиця 3.13 – Аналіз ризиків стартапу
Ймовірність
0.8 – 1.0
0.6 – 0.8
63
0.4 – 0.6 3 6
0.2 – 0.4 2, 5
0.0 – 0.2 1, 4, 7
0.05 0.1 0.2 0.4 0.8
Вплив
Згідно таблиці 3.13 було виявлено найбільш впливові ризикові події (2, 3, 5, 6).
Визначивши, які ризики матимуть найбільший вплив на стартап, було
розроблено план по попередженню або усуненню ризиків стартапу (табл. 3.14).
Таблиця 3.14 – Управління ризиками стартапу
№ Назва Попередження ризику Усунення ризику
ризику Дії Відповід Дії Відповідаль
альний ний
2 Фінансовий - резервування Менедже - Менеджер
ризик бюджету р перепланування стартапу
- дослідити стартапу бюджету
можливості - кредитування
кредитування стартапу
- пошук
додаткових
джерел
фінансування
3 Ризик - проведення Менедже - пошук нових Менеджер
персоналу досконалого та р учасників стартапу
детального стартапу - підвищення
відбору команди кваліфікації
стартапу - навчання
- стимулювання персоналу
та заохочення
64
учасників
стартапу
6 Управлінськи - підвищення Менедже - Менеджер
й ризик кваліфікації р перепланування стартапу
- консультації зі стартапу стартапу
спеціалістами в - прийняття
управлінні інших, більш
- прийняття професійних,
правильних рішень
рішень - пошук більш
кваліфікованого
менеджера
7 Форс- - резервування Менедже - Менеджер
мажорний бюджету р перепланування стартапу
ризик - резервування стартапу стартапу
часу
3.8 Управління комунікаціями стартапу
Управління комунікаціями стартапу включає процеси, необхідні для компіляції,
збору, розповсюдження, зберігання, отримання та своєчасного використання
інформації про стартап. Забезпечує підтримку взаємодії [67] та системи зв’язку [68 -
69] між учасниками стартапу z, передачу управлінської та звітної інформації, що
спрямована на забезпечення досягнення цілей стартапу.
Планування комунікацій здійснюється на ранніх стадіях стартапу, але
результати цього процесу планування регулярно переглядаються протягом усього
стартапу та коригуються за потреби, для збереження актуальності.
План комунікацій – це документ, що описує: вимоги та очікування щодо
комунікацій стартапу; як і в якій формі буде здійснюватися обмін інформацією; коли
65
і де відбуватимуться комунікації; і хто відповідає за забезпечення кожного типу
комунікації.
Комунікаційні потреби мають на увазі загальні інформаційні потреби
учасників стартапу. Існує чотири основних види таких вимог у членів команди
стартапу.
По-перше, потрібна інформація про розподіл обов'язків. Кожен член команди
повинен точно знати, за яку частину стартапу він відповідає, які його повноваження
та обов’язки. Основою для цієї інформації є організаційна структура стартапу.
По-друге, потрібна координація. Члени команди залежать один від одного,
виконуючи проєктні роботи. Координація інформації забезпечує ефективну спільну
роботу членів команди стартапу. Категорія координуючої інформації включає
інформацію про будь-які зміни, внесені в стартап.
По-третє, існує потреба в інформації про процес реалізації стартапу та
досягнутий прогрес. Члени команди повинні володіти інформацією про поточний
стан стартапу, щоб своєчасно виявляти проблеми та вживати заходів щодо їх
вирішення. Така інформація включає звіти про витрачені кошти на певний момент
часу, дотримання календарних планів і графіків проєктів. Також важливою є
інформація про поточний стан ризиків і проблем, що виникають.
По-четверте, членам команди потрібна інформація про прийняті рішення.
Вони повинні розуміти рішення, прийняті керівництвом, спонсорами стартапу та
клієнтами, якщо ці рішення стосуються самого стартапу або його економічного
середовища. Прикладами такого типу інформації є статути проєктів, посадові
інструкції, робочі графіки та бюджети стартапів.
Природно, потреби людей у комунікаціях виходять за рамки чотирьох
перерахованих пунктів. Але в рамках управління комунікаціями стартапу слід
розглядати лише «необхідні та достатні» для успіху стартапу. Забагато або замало
інформації може мати негативний вплив на виконання стартапу.
Під час планування комунікацій визначається інформація та взаємодії,
необхідні учасникам стартапу. Наприклад, кому яка інформація потрібна, коли, хто
66
має її надати і як. Хоча всі стартапу потребують передачі інформації про стартап,
інформаційні потреби та методи розповсюдження інформації можуть значно
відрізнятися. Важливим фактором успіху стартапу є визначення інформаційних
потреб учасників стартапу та визначення відповідних методів задоволення цих
потреб.
Для стартапу було розроблено наступний план комунікацій (табл. 3.15):
Таблиця 3.15 – План комунікацій
№ Вид Регулярність Хто відправляє Хто отримує
комунікації комунікації інформацію інформацію
1 Тижневий звіт 1 раз на тиждень Виконавець Той, хто
по задачах (кожен понеділок) контролює
2 Місячний звіт 1 раз на місяць Виконавець Той, хто
по задачах (останній день контролює
місяця)
3 Звіт за місяць 1 раз на місяць Менеджер Замовник
по стартапу (останній день проєкту
місяця)
4 Щотижнева 1 раз на тиждень Виконавець Менеджер
нарада (кожна середа) проєкту
5 Усна Кожні 3 дні Будь-хто з Будь-хто з
комунікація команди команди
6 Підсумковий При завершенні Менеджер Замовник
звіт по всьому стартапу проєкту
стартапу
Висновки до розділу 3
Розділ включає в себе структурне планування та розробку компонентів
управління стартапами. Цей розділ є проєктною суттю роботи, оскільки базується на
таких елементах як організаційна структура стартапу, ієрархічна структура робіт
67
стартапу, матриця відповідальності, календарний план стартапу та ін. Для
уникнення ризиків фінансових втрат та перевантаження персоналу, було приділено
увагу плануванню ресурсів, управлінню якістю, ризиками, комунікаціями.
Результатом є готовий календарний план робіт стартапу, з назначеними ресурсами
до кожної задачі, визначеною тривалістю та бюджетною вартістю робіт. Для
реалізації стартапу за планом потрібно 530 робочих днів, або 18 місяців.
Проведено комп’ютерне моделювання управління стартапом з відхиленням по
строкам стартапу. Реалізація стартапу досягла 41% і знаходиться на етапі створення
прототипу десктопного додатку. Прототип має весь запланований функціонал та
попередній варіант дизайну. Загальна затримка по задачам склала 30 днів, отже
загальний час виконання стартапу збільшився до 560 робочих днів. Відхилення по
часу не є критичними, тому що не перевищують заплановані допущення стартапу.
68
4 МОДЕЛЮВАННЯ ВИКОНАННЯ СТАРТАПУ ТА ЙОГО РЕЗУЛЬТАТИ
4.1 Моделювання продукту стартапу
Моделювання додатку на початкових етапах розробки є важливим кроком у
створенні якісного продукту. Цей процес допомагає визначити, на яких платформах
працюватиме майбутній продукт, визначити вимоги до інтерфейсу та дізнатися, які
інструменти будуть використовуватися під час розробки для досягнення
запланованих результатів [32 - 36].
Щоб краще зрозуміти функціональність додатку, потрібно визначити, як
користувач буде використовувати продукт стартапу. Визначення варіантів
використання додатку допомагає представити:
– як додаток взаємодіє з користувачами;
– роль і важливість кожного окремого процесу в додатку;
– обсяг розробки додатку.
Щоб зрозуміти що саме необхідно майбутнім користувачам, для початку
необхідно виділити основні функціональні розділи, а саме:
– взаємодія з користувачем;
– головна частина;
– редактор;
– сторінки результату;
– магазин.
Далі визначаємо, які основні дії користувач буде робити в кожному з розділів.
Після цього можна визначити, які необхідно розробити функції, щоб задовольнити
очікування користувачів. Визначивши основні функції, можна сформулювати
додаткові. Вони не є критично важливими для роботи додатку та виконання
основних дій в ньому користувачами, але ці функції необхідні для більш
комфортного використання, та є привабливими для майбутніх користувачів.
69
Також було визначено механізм моніторингу та контролю виконання робіт
стартапу. Створено систему заходів контролю робіт, що забезпечить успішну
реалізацію стартапу.
4.2 Проектування архітектури застосунку
Проектування архітектури застосунку є критичним етапом розробки будь-
якого програмного продукту. Хороша архітектура допомагає створити ефективний,
легко підтримуваний та розширюваний продукт. Ось кілька кроків, які слід виконати
при проєктуванні архітектури:
Аналіз вимог: ретельний розгляд всіх вимог до вашого продукту. Визначити,
які функціональність, характеристики та можливості повинні бути включені в гру.
Визначення компонентів: Розбити продукт на окремі компоненти, які
взаємодіють один з одним. До цих компонентів можуть входити графічний движок,
ігрова логіка, база даних, користувацький інтерфейс тощо.
Вибір архітектурного підходу: Вибрати підхід до структури застосунку. Це
може бути монолітна архітектура, мікросервіси, Model-View-Controller (MVC) або
інший підхід, який підходить для вашого стартапу.
Розробка бази даних: Визначаємо, як будуть зберігатися дані гри. Розробляємо
схему бази даних та вибераємо відповідну систему управління базами даних
(наприклад, PostgreSQL або MongoDB).
Вибір технологічного стеку: Обераєамо технології та інструменти для
реалізації кожного компонента. Це включає в себе вибір мов програмування,
бібліотек, фреймворків і інших технологій.
Забезпечення безпеки: Розробляємо стратегію забезпечення безпеки вашого
застосунку, включаючи захист від злому та захист конфіденційної інформації.
Інтеграція сторонніх сервісів: Якщо застосунок має взаємодіяти з іншими
сервісами, розгляньте, як це буде реалізовано та як будуть передаватися дані.
Тестування архітектури: Перевіряємо архітектуру на відповідність вимогам та
проводимо тестування, щоб впевнитися в її ефективності та стійкості.
70
Документація: Проводимо документацію архітектури для забезпечення
розуміння команди та майбутніми розробниками.
Постійна оптимізація: Архітектура повинна бути готовою до змін і розширень
в майбутньому. Завжди прагнемо до покращення та оптимізації.
Завершення цих кроків допоможе створити міцну та добре розроблену
архітектуру для нашого застосунку.
Проектування архітектури застосунку є надзвичайно важливим етапом в
розробці будь-якого програмного продукту. Від правильної архітектури залежать
якість, продуктивність та майбутні можливості розробленого застосунку. Ось головні
аспекти, які підкреслюють важливість Проектування архітектури:
Ефективність та продуктивність: правильна архітектура дозволяє оптимізувати
роботу застосунку, забезпечуючи ефективне використання ресурсів та зменшення
часу відгуку.
Легкість розширення: гнучка архітектура допомагає додавати новий
функціонал та компоненти, не порушуючи вже існуючий код.
Стійкість та надійність: добре спроєктована архітектура допомагає
попереджати та виправляти помилки, забезпечуючи надійну роботу застосунку.
Легкість тестування та налагодження: чітка архітектура дозволяє легко
проводити тестування та виправляти помилки.
Керованість стартапом: архітектура допомагає керівникам проєкту та
розробникам зрозуміти, як компоненти взаємодіють та діють, що полегшує
управління стартапом.
Забезпечення безпеки та захисту даних: архітектура може врахувати питання
безпеки та визначити заходи для захисту даних.
Покращення якості продукту: правильна архітектура сприяє створенню
якісного та надійного продукту.
Загалом, Проектування архітектури є фундаментальним кроком, який визначає
майбутній успіх програмного продукту. Воно впливає на всі аспекти розробки,
від якості до продуктивності, і варто приділити йому належну увагу та час.
71
4.3 Опис процесу практичної реалізації стартапу
Реалізація стартапу досягла 41% і знаходиться на етапі створення прототипу
десктопної системи генерації сайтів. Прототип має весь запланований функціонал та
попередній варіант дизайну. [13 - 15] Розглянемо результат виконання проєкту більш
детальніше.
Для початку роботи з додатком після завантаження на комп'ютер, користувачу
необхідно буде зареєструватися, тобто створити власний кабінет, та авторизуватися.
Реєстрація — це спосіб повідомити сайту дані про себе та в обмін отримати доступ
до додаткових можливостей (наприклад, додавання чогось до вибраного) або
ресурсів (наприклад, файлів) на сайті, які недоступні гостям. Реєстрація нероздільна
без авторизації. Фактично, реєстрація - це спосіб отримати можливість увійти на
сайт. Нерідко реєстрацію роблять обов'язковою для доступу до сайту. Часто це
відбувається у соціальних мережах, де можливості гостей обмежені за визначенням.
Кабінет користувача необхідний для того, щоб визначити яку версію додатку
він отримає (безкоштовну чи повну), та наявність підписки. Особистий кабінет – це
набір пов'язаних сторінок сайту, які доступні користувачам певної групи – покупці,
партнери, оператори, модератори. Але особистий кабінет на сайті потрібен не лише
клієнту, бізнес також отримує зиск. Аналітики можуть зібрати дані про користувачів
та детально вивчити свою цільову аудиторію. І, звичайно, переконати користувача
купувати більше за допомогою індивідуальних рекомендацій та можливості
створити добірки. Іноді особистий кабінет виглядає як кабіна старовинного трамвая:
там є лише кілька важелів-опцій, що дозволяють зробити прості дії.
В особистому кабінеті наголошується на зручності, зрозумілості та
функціональності, а не естетиці дизайну. Користувач заходить у особистий кабінет із
конкретною метою – переглянути роботи, завантажити існуючу або доопрацювати
попереднє.
Головна сторінка додатку, одразу після завантаження на комп'ютер – сторінка
реєстрації, зображена на рисунку 4.1.
72
Рисунок 4.1 – Реєстрація
Реєстрація – це частина функціоналу в модулі користувача. Він також включає
інші сторінки: Логін на рисунку 4.2.
73
Рисунок 4.2 – Логін
Новий пароль/згадати пароль на рисунку 4.3 і 4.4
Рисунок 4.3 – Згадати пароль
Профіль на рисунку 4.4.
74
Рисунок 4.4 – Новий пароль
Рисунок 4.5 – Профіль
75
Після проходження реєстрації ми переходимо на головну сторінку (рисунок
4.5), де можемо побачити всі роботи, над якими раніше працювали, а також маємо
можливість створити новий прототип.
Рисунок 4.6 – Головна сторінка
Після цього ми переходимо на сторінку редактора (рисунок 4.6), який дозволяє
нам власне створювати сам сайт за прикладом конструкторів [76] з можливістю
Рисунок 4.7 – Редактор
76
зміни внутрішнього функціоналу. Ця секція буде суттєво перероблена надалі.
Далі сторінка попереднього перегляду (рисунок 4.7) у вигляді пдф файлу [78 -
80], щоб убезпечити можливість злому даних.
Рисунок 4.8 – Сторінка попереднього перегляду
Сторінка оплата має бути максимально простою та зрозумілою одночасно. Як
варіант можна надавати додаткову інформацію щодо кожного поля введення
інформації, щоб користувач не думав зайвий раз, що він зробив щось не так. У той
же час, сторінка не повинна бути надмірно перевантажена анімаціями, діями або
додатковими полями. Кожна зайва дія або інформація лякатиме користувача так, як
він знаходиться в процесі розлучення зі своїми грошима і сприйматиме зайву
інформацію як сигнал, що можливо не варто брати товар. Сторінка сплати (рисунок
77
4.9), після якої можна отримати свій продукт. Сторінка сплати (рисунок 4.9), після
якої можна отримати свій продукт.
Рисунок 4.9 – Сторінка сплати
Сторінка вивантаження коду (рисунок 4.10) для його подальшого
використання.
Сам продукт лише на стадії розробки, а тому його можливості поки що
обмежені.
Рисунок 4.10 – Сторінка вивантаження коду
78
4.4 Технології
Angular — це фреймворк від компанії Google для створення просунутих
безшовних (односторінкових) веб-додатків — SPA (Single Page Applications) —
мовами програмування TypeScript, JavaScript, Dart [1].
У фреймворку відкритий вихідний код. Продукт розповсюджується
безкоштовно. Знайти вихідні файли та додаткову інформацію можна в офіційному
репозиторії фреймворку на GitHub. Фреймворк назвали на честь кутових дужок,
якими обрамляють HTML-теги.
Angular - спадкоємець AngularJS, написаного на JavaScript. Незважаючи на
схожі назви, це різні фреймворки. AngularJS ще називають версією 1.x. Фреймворк
існує із 2009 року. Нині він перебуває у режимі long time support. Це означає, що
його продовжують підтримувати, але нових можливостей у фреймворк вже не
додають. На AngularJS написано багато legacy-коду.
Нова версія - Angular, він же Angular 2.x і далі. Фреймворк написано на
TypeScript і несумісний з AngularJS. Його випустили у 2016 році і з того часу
розвивають. Angular має іншу архітектуру, а писати на ньому можна і з TypeScript, і з
JavaScript.
Пристрій фреймворку Angular:
компоненти — це великі частини програми, які не залежать один від
одного. Наприклад, один компонент – це стрічка новин, інший – шапка
сайту;
модулі - це також складові програми, але інші. Вони керують
компонентами. Якщо компонент — це область програми, модуль відповідає
за керування;
форми. Більшість програм на Angular — form-based, тобто засновані на
формах. Форма - це структура, в яку користувач вводить якісь дані, а потім
відправляє їх на сервер;
79
сервіси. Вони схожі на компоненти, але більш вузькоспеціалізовані. Вони
можуть визначатися як на рівні модуля, так і на рівні компонента або
програми. У сервісах реалізується спеціальна логіка;
директиви - це складові програми, які змінюють структуру або поведінку
сторінки. Компоненти також відносяться до директив. Але крім них
існують ще два види: структурні директиви та директиви, що змінюють
зовнішній вигляд чи поведінку елементів. Вони потрібні, щоб застосувати
одну дію до всіх екземплярів одного компонента, наприклад, зміна валюти
у всіх картках товару.
Переваги Angular:
велика кількість можливостей - Angular допомагає прив'язувати
компоненти програми один до одного, передавати дані, анімувати
інтерфейси та ін. Для простих проєктів його функціональність може бути
надмірною, але для складних SPA-додатків вона незамінна;
універсальне застосування - Фреймворк дозволяє створювати не лише
веб-застосунки;
детальний style guide - Особливість Angular - докладна документація.
Вона містить рекомендації до побудови та розробки додатків, style guide –
гайд за стилем програмування на Angular. Це зручно для розробників, які
вперше зіштовхнулися із фреймворком.
Недоліки Angular:
складність у вивченні - Angular вважається одним із найскладніших
фронтенд-фреймворків. Його можливо нелегко вивчити з нуля самостійно.
Крім того, для початку роботи потрібно знати не тільки "чистий"
JavaScript, але і TypeScript, який на ньому заснований;
відсутність сумісності між старою та новою версіями - Незважаючи на
схожі назви, AngularJS та Angular несумісні та принципово різні. Тому
розробникам, які стикаються з legacy-кодом на AngularJS, потрібно
80
вивчити основи роботи із застарілим фреймворком. Концепції та правила
нового Angular не підійдуть.
Typescript — мова програмування, представлена Microsoft в 2012 року і
позиціонується як засіб розробки веб-додатків, що розширює можливості JavaScript.
Розробником мови TypeScript є Андерс Хейлсберг, який створив раніше Turbo
Pascal, Delphi і C# [2].
Специфікації мови відкриті та опубліковані в рамках угоди Open Web
Foundation Specification Agreement (OWFa 1.0).TypeScript є сумісним з JavaScript і
компілюється в останній.
TypeScript відрізняється від JavaScript
можливістю явного статичного призначення типів, підтримкою використання
повноцінних класів (як у традиційних об'єктно-орієнтованих мовах), а також
підтримкою підключення модулів [99 - 103], що покликане підвищити швидкість
розробки, полегшити читання, полегшити пошук, здійснювати рефакторинг і
повторне використання етапі розробки та компіляції, і, можливо, прискорити
виконання програм.
На момент релізу представлені файли для сприйняття розширеного синтаксису
TypeScript для Vim і Emacs, а також плагін для Microsoft Visual Studio. Одночасно з
виходом специфікації розробники підготували файли з деклараціями статичних
типів для деяких популярних JavaScript-бібліотек, серед яких jQuery.
RxJS — це бібліотека для роботи з потоками даних у JavaScript, яка базується
на концепції реактивного програмування [3]. Один із головних принципів
реактивного програмування полягає в тому, що потік даних вважається поточною
послідовністю подій, яка може змінюватися з часом.
Оператори в RxJS - це функції, які дозволяють здійснювати різноманітні
операції з потоками даних, такі як фільтрування, перетворення, злиття та багато
інших. Використання операторів дозволяє зменшити кількість коду та упростити
роботу з потоками даних.
Ось кілька причин, для чого варто використовувати оператори в RxJS:
81
зручне та ефективне управління потоками даних;
найкраща читабельність коду;
висока можливість перевикористання;
підтримка асинхронного програмування;
розширення функціональності. Оператори в RxJS можуть розширити
функціональність вашого коду та дозволити зробити складні операції
більш простими;
оператори RxJS можуть також допомогти зробити ваш код більш
безпечним та масштабним.
Одним зі способів досить легко почути оператори в RxJS є порівняння їх з
методами масивів у нативному JavaScript. Багато операторів у RxJS мають схожі
функції з методами масивів, які зазвичай використовують для маніпулювання
масивами даних.
HTML5 (англ. HyperText Markup Language, version 5) - мова для
структурування і подання вмісту всесвітньої павутини [7]. Це п'ята версія HTML.
Хоча стандарт був завершений (рекомендована версія до використання) тільки в
2014 році (попередня, четверта, версія опублікована в 1999 році), вже з 2013 року
браузерами оперативно здійснювалася підтримка, а розробниками використання
робочого стандарту (англ. HTML Living). Мета розробки HTML5 — поліпшення
рівня підтримки мультимедіа-технологій з одночасним збереженням зворотної
сумісності, зручності читання коду для людини і простоти аналізу для парсерів.
У 2005 році з'явився YouTube - основний відеохостинг Інтернету аж до
теперішнього часу (2021). Його плеєр був написаний на Adobe Flash - поширеній
системі інтернет-додатків. На момент появи YouTube це було нормально, оскільки
перегляд сторінок відбувався в основному з комп'ютерів та ноутбуків, а порти Flash
були під усі великі ОС. У 2007 році з'явився iPhone. Телефони до нього або
використовували чисто мобільні технології типу WAP, або покладалися на серверний
рендеринг (Opera Mini). iPhone же мав повноцінний браузер — а YouTube, що
покладався на Flash, був реалізований окремою програмою. Однією із завдань
82
HTML5 стало знизити потребу у Flash — за допомогою HTML5 video, SVG і холстів.
iPhone поставив новий стандарт смартфону — прилад із сенсорним екраном на всю
передню панель. Екранна клавіатура звичайно мініатюрна, і тому для різних типів
введення — чисел, дат, адрес електронної пошти — потрібні різні клавіатури.
HTML5 додав і інші нововведення для мобільних пристроїв - геолокацію,
управління кешем для офлайн-роботи і т.д. Як у HTML5, так і в CSS3 додані
механізми переверстки сайтів під мобільні пристрої та сторінкові медіа (електронна
книга, друкований документ). Все більше поширюються AJAX і односторінкові
сайти, і додався API для управління історією в них.
З'ясувалося, що вебмайстри не надають актуальної та достовірної інформації
в DOCTYPE. Підтримка хибних документів уніфікована і в інших місцях.
WHATWG розпочав роботу над новим стандартом у 2004 році [9], коли World
Wide Web Consortium (W3C) зосередився на майбутніх розробках XHTML 2.0, а
HTML 4.01 не змінювався з 2000 року. У 2009 році W3C визнав, що термін роботи у
робочої групи XHTML 2.0 минув, і вирішив не відновлювати його. Згодом W3C та
WHATWG спільно розробляли HTML5. Навіть незважаючи на те, що HTML5 був
добре відомий серед веб-розробників протягом кількох років, він став основною
темою ЗМІ лише у квітні 2010 року. Після цього глава компанії Apple Inc.Стів Джобс
написав публічний лист, заголовок якого говорив: «думки з приводу Flash», де він
зробив висновок, що з розробкою HTML5 немає більше необхідності дивитися
відеоролики або використовувати інші види програм за допомогою Adobe Flash. З
цього приводу спалахували дебати в колі веб-розробників, причому деякі натякали,
що хоча HTML5 і забезпечує розширену функціональність, розробники повинні
брати до уваги відмінності браузерів і необхідність підтримки різних частин
стандартів, так само як і функціональні відмінності між HTML5 і Flash.
WHATWG розпочав роботу над специфікацією у червні 2004 року під назвою
Web Applications 1.0. З січня 2011 року специфікація у Draft Standard
(Стандартизація проєкту) затверджується у WHATWG, Working Draft (робочий
83
проєкт) затверджується у W3C.Ян Хіксон з компанії Google є редактором
специфікації HTML5.
Специфікація HTML5 була прийнята як точка початку роботи над новим
HTML [77] робочою групою W3C у 2007 році. Ця робоча група опублікувала
специфікацію як перший громадський робочий проєкт (working draft) 22 січня 2008
року. Робочий проєкт - це поточна робота, вона залишалася на кілька років, її
частини HTML5 були закінчені і реалізовані в браузерах до того моменту, коли вся
специфікація досягла фінального статусу «Рекомендовано». Ян Хіксон чекав
досягнення Candidate Recommendation протягом 2012 року. Щоб специфікація
набула статусу W3C Рекомендації, необхідні дві закінчені на 100% і повністю
взаємодіючі реалізації.
У грудні 2009 року WHATWG переключився на універсальну модель розробки
для специфікації HTML5. W3C продовжувала публікувати знімки зі специфікацією
HTML5.
14 лютого 2011 року W3C збільшив термін роботи для робочої групи HTML із
проміжними знімками для HTML5. Робоча група передбачала просунути HTML5 у
Last Call, запрошуючи співтовариства до співпраці з W3C, щоб підтвердити технічну
відсутність дефектів у специфікації у травні 2011 року. Потім група перейшла на
тестування своєї реалізації. W3C також розробляла всебічну перевірку, щоб досягти
широкої функціональної сумісності для фінальної специфікації 2014 року -
очікуваної дати для Рекомендації.
З 28 жовтня 2014 року W3C офіційно рекомендує використовувати HTML5 - це
означає, що стандарт остаточно фіналізований і готовий до широкого використання
CSS – це мова опису зовнішнього вигляду документа, тобто вона відповідає за
те, як виглядають веб-сторінки: колір фону та декоративних елементів, розмір та
стиль шрифтів. Термін розшифровується як Cascading Style Sheets (каскадні таблиці
стилів). CSS взаємодіє з іншою мовою розмітки - HTML, яка відповідає за
розміщення елементів на сторінці.
Допустимо, за допомогою HTML текст вже розташований у верхній частині
84
документа. Задати для нього колір, тип шрифту та його кегль, зробити текст жирним
або виділити курсивом можна без використання CSS. Для цього у вихідний код
потрібно додати тег, який визначає зображення тексту. Наприклад, у цьому тексті за
допомогою тега <b> фрагмент виділений жирним шрифтом:
Перша частина тексту набрано звичайним шрифтом. А ось ця частина буде
виділена жирним.
<!DOCTYPE html>
<html>
<head>
<title>Жирний текст за допомогою тега b</title>
</head>
<body>
<p>Перша частина тексту набрано звичайним шрифтом. <b>А ось ця
частина буде виділена жирним.</b></p>
</body>
</html>
Використання тегів для форматування тексту в HTML захаращує вихідний код,
ускладнює його, а значить, ймовірність припуститися в ньому помилки стає вищою.
Для того, щоб цього уникнути, створили окрему мову для стильової розмітки CSS.
Крім розміру та кольору шрифтів, ця мова розмітки регулює поділ заголовків,
підзаголовків та основного тексту, розмір полів та відступів, окремі колірні кадри
для виділення тексту, колір основного фону, шапки та підвалу.
CSS, як і будь-яку мова, має синтаксис. У ньому є правила - значення, що
визначають зовнішній вигляд елементів [8]. CSS-правило складається з селектора,
CSS-властивостей та їх значень:
селектори — це позначки, які допомагають браузеру зрозуміти, до якої
частини HTML-коду потрібно застосувати задані параметри;
властивості CSS — це певні параметри оформлення, наприклад колір
елемента або тексту (color) або колір фону (background);
85
значення — це просто значення, воно виражається текстом або числом,
наприклад чорний (black).
селектор {
властивість: значення;
}
p {
color: black
}
CSS-правила в коді полягають у фігурних дужках {…}. Перед відкриттям
дужки обов'язково потрібно вказати селектор, якого належить це правило. У
прикладі селектор є <p>, і він вибирає всі теги з ім'ям <p>, color — це CSS-
властивість а black — значення CSS-властивості. Зв'язка "властивість: значення"
називається блоком оголошення стилів. Всередині нього властивість
відокремлюється від значення двокрапкою, а один блок від іншого відокремлює
крапка з комою. Таблиці називаються каскадними, тому що працюють за принципом
каскаду — тобто правило, прописане нижче, вважається пріоритетним. Наприклад,
якщо в прикладі під значенням фонового кольору ми пропишемо ще одне значення
color: red, то колір тексту буде червоним, а не чорним.
p {
color: black
background: #eeeeee
color: red
}
Методологія CSS – це стандарт написання CSS таким чином, щоб його можна
було підтримувати та читати іншим членам команди або стороннім розробникам.
Іншими словами, це правила, які будуть зрозумілі людині з боку, щоб вона могла
розібратися в коді без автора та внести правки. Рекомендації щодо написання та
називаються методологіями CSS.
86
Універсальної методології на сьогоднішній день немає. Деякі з них застаріли,
деякі використовуються активніше за інших, а найближчим часом можуть з'явитися
нові, досконаліші методології. Найпопулярнішими є дві. Atomic CSS.У цій
методології створюється набір класів – інструментів, що уніфікують правила. Класи
комбінуються безпосередньо у блоці HTML, тобто стилі елементів задаються над
CSS. Таким чином полегшується завдання верстальника, тому що йому не потрібно
перемикатися між контекстами.
Наприклад, у будь-якому проєкті є значення:
padding – внутрішні відступи з усіх боків елемента;
margin — зовнішні відступи з усіх боків елемента.
Однакові значення { padding: 5px; } і { margin: 5px; } можна уніфікувати
$space-1: 5px, а значення { padding: 10px; } і { margin: 10px; } перетворити на
універсальне значення $space-2: 10px:
Така методологія корисна великих проєктів, оскільки можна створити не
одиничний інтерфейс, а цілу дизайн-систему, яку можна використовувати повторно.
CSS-in-JS. Ця методологія пропонує замість підключення CSS-файлів
підключити до HTML один JS-модуль, в якому можна використовувати переваги
мови JavaScript. Перевага такого підходу — це потужніший CSS, оскільки можна
використовувати всі його функції без обмежень. Наприклад, вибрані кольори з
дизайн-проєкту можна освітлювати або затемнювати за допомогою коду JS:
import color from ‘color’
const red = Color ('red')
const styles = {
color: red.lighten(10).toHex()
}
Ще одна перевага CSS-in-JS – це скорочення обсягу коду та числа файлів.
Наприклад, у цій методології точно не доведеться створювати окремий файл CSS
для одного маленького компонента, в якому прописано 2-3 правила. На інших
методологіях таких файлів буває багато.
87
Методологія CSS-in-JS в першу чергу створена для зручності розробників та
підвищення якості DX (Developer Experience), який, у свою чергу, вплине на
зручність користувачів - UX (User Experience). А ці явища справді пов'язані
безпосередньо, оскільки чим комфортніше працювати розробнику — без багів і
милиць, — тим якіснішим виходить функціонал інтерфейсу.
Bootstrap почала розроблятися як внутрішня бібліотека компанії Twitter під
назвою Twitter Blueprint. Після кількох місяців розробки він був відкритий під
назвою Bootstrap 19 серпня 2011 року [9]. Основними нововведеннями другої версії,
що з'явилася 31 січня 2012 року, стали 12-колонова сітка та підтримка адаптивності.
Тобто з цієї миті фреймворк дозволяє створювати сторінки, які підлаштовуються під
ширину екрана. Третя версія була випущена 19 серпня 2013 року. У ній адаптивність
набула подальшого розвитку, було здійснено перехід до концепції mobile first,
оптимізації насамперед під мобільні пристрої. Роботу над четвертою версією
розпочато 29 жовтня 2014 року. Альфа-версія вийшла 19 серпня 2015 року.
Перша бета-версія випущена 10 серпня 2017 року. Друга бета-версія випущена 19
жовтня 2017 року. 18 січня 2018 року випущена перша стабільна версія Bootstrap 4. 5
травня 2021 року побачив світло Bootstrap 5
Особливості Bootstrap:
зниження часу на розробку - фреймворк дає готові рішення, які дозволяють
створювати макети сайтів швидше. Для швидкого запуску проєктів є безліч
прикладів. Для верстки будь-яких прототипів (альбомів, слайдерів, панелі
входу тощо) потрібні файли index.html, які знаходяться в кожній папці з
прикладами, та відповідний CSS-файл. Наприклад, carousel.css або
cover.css. Змінювати код можна на власний розсуд, вносячи правки в
текстовому редакторі. Bootstrap дозволяє скопіювати код з прикладу та
вставити його у свій проєкт, до якого підключено фреймворк;
адаптивність та кросбраузерність - сайт коректно відображатиметься в
сучасних браузерах та на екранах пристроїв різних розмірів, незалежно від
діагоналі;
88
легкість у використанні та відкритість – bootstrap дуже простий для
освоєння та роботи. Крім того, до фреймворку є безліч уроків та інструкцій.
Відкритий вихідний код дозволяє адаптувати Bootstrap під свої потреби;
зрозумілий код - за допомогою Bootstrap можна писати простий та якісний
код, який буде зрозумілий іншим розробникам. Це полегшує роботу у
команді;
єдність стилів - елементи фреймворку гармонійно поєднуються один з
одним, що дозволяє створювати сайти та сторінки в єдиному стилі;
шаблонність – сайти, створені за допомогою Bootstrap, мають однакову
навігацію, структуру, кнопки. Щоб вирішити проблему, можна змінювати
шаблон в залежності від ідей дизайнерів та побажань замовника;
відсутність підтримки застарілих версій браузерів - оскільки Bootstrap
постійно оновлюється, сайти Bootstrap можуть некоректно відображатися у
старих браузерах.
Node.js (Node) — це платформа з відкритим вихідним кодом для роботи з
мовою JavaScript, побудована на движку Chrome V8. Вона дозволяє писати
серверний код для веб-застосунків і динамічних веб-сторінок, а також програм
командного рядка [11].
Платформу розробив Райан Дал, програміст з Америки у 2009. Node.js працює
на движку V8, що транслює JavaScript в машинний код [37]. Простими словами,
Node.js – це додаток на C++, який отримує на вході код JavaScript та виконує його.
Щоб взаємодіяти з пристроями введення-виведення на комп'ютері, платформа має
власний інтерфейс на C++. Таким чином, платформа перетворює спеціалізовану
скриптову мову JavaScript на мову загального призначення, тому на Node.js можна
писати будь-які комп'ютерні програми. Платформа дозволяє користуватися єдиною
мовою JavaScript для написання коду на стороні клієнта (Frontend), і на сервері
(Backend). Ці можливості Node.js є важливими для розробки програм реального часу,
які базуються на подіях.
89
Платформу використовують fronted-розробники, backend-розробники та інші
[81]. Вона дозволяє написати програму для різних ОС: Linux, OS X і Windows, може
використовуватися для створення API. Також Node.js застосовується для розробки
крос-платформних програм: наприклад, списку завдань, який повинен працювати на
різних платформах, синхронізувати дані в реальному часі та відправляти на
мобільний пристрій.
Node.js є основою Internet of Things, чи навіть IoT. Платформа допомагає
керувати приладами та створювати сервери, здатні одночасно обробляти велику
кількість запитів. Багато великих компаній використовують Node.js. Наприклад,
eBay і веб-версія PayPal у процесі переходу, а LinkedIn, які повністю відмовилися від
Ruby on Rails на користь Node.js ще в 2012 році, заявили про 20-кратне прискорення
27 серверів. Серед інших відомих компаній - Yahoo, Netflix, Uber, Walmart, Google та
багато інших.
Особливості:
висока швидкість. JavaScript-код, який виконується в середовищі Node.js,
може бути в кілька разів швидше, ніж написаний мовами, наприклад Ruby
або Python. У Node.js використовується модель асинхронного
програмування.Модель дозволяє продовжити обробку інших завдань, не
чекаючи завершення передачі. Коли потрібно виконати операцію
введення-виведення на кшталт доступу до файлової системи або бази
даних, Node.js не блокує головний потік очікуванням результатів.
Платформа ініціює її виконання та продовжує виконувати інші завдання,
доки результати попередньої операції не будуть отримані;
універсальність та гнучкість. У Node.js виконується код написаний на
JavaScript;
велика кількість модулів і бібліотек;
робота на движку Chrome V8.Node.js працює на JavaScript-движку V8 від
Google. V8 - движок JavaScript з відкритим вихідним кодом, що
розповсюджується за ліцензією BSD. Він застосовується у браузерах на
90
основі Chromium. Це означає, що в Node.js використано напрацювання
тисяч інженерів. Двигун написаний C++, має відкритий вихідний код і
просунуті бібліотеки.
Python. Гвідо Ван Россум опублікував першу версію коду Python (версія 0.9.0)
у 1991 році. Він уже включав ряд корисних можливостей. Наприклад, різні типи
даних та функції для обробки помилок. У версії Python 1.0, випущеної в 1994 році,
було реалізовано нові функції для простої обробки списку даних: зіставлення,
фільтрація та скорочення [5].
Python 2.0 був випущений 16 жовтня 2000 з новими корисними функціями для
програмістів, такими як підтримка символів Unicode і спрощений спосіб циклічного
перегляду списку. 3 грудня 2008 вийшов Python 3.0 [6]. Ця версія включала функцію
друку та додаткову підтримку розподілу чисел та обробки помилок.
Мова Python має такі переваги:
легко читати та розуміти;
використовуючи менше рядків коду, ніж іншими мовами;
має велику стандартну бібліотеку, що містить багаторазові коди практично
для будь-якого завдання;
активна спільнота Python складається з мільйонів розробників з усього
світу. У разі виникнення проблем співтовариство допоможе в їх вирішенні;
крім того, в Інтернеті є безліч корисних ресурсів для вивчення Python.
Наприклад, ви можете легко знайти відеоролики, навчальні посібники,
документацію та посібники для розробників;
python можна переносити на різні операційні системи: Windows, MacOS,
Linux і Unix.
Electron JS [10] — це фреймворк з відкритим вихідним кодом, який дозволяє
розробникам створювати кросплатформні настільні програми за допомогою
JavaScript, HTML та CSS, які на сьогоднішній день є трьома основними веб-
технологіями. Він розроблений та підтримується GitHub. На своєму веб-сайті
91
Electron обіцяє, що будь-хто, хто може створити веб-сайт, може використовувати
його для створення настільної програми.
Чому? Оскільки всі складні частини, такі як автоматичні оновлення, власні
меню та повідомлення, звіти про збої та налагодження, виконуються механізмом
рендерингу Chromium (частина браузера Chrome з відкритим вихідним кодом) та
Node.js (середовище JavaScript). побудований на движку Chrome V8 JavaScript).
Природно, Electron приваблює веб-розробників, які можуть використовувати його
для розробки потужних кросплатформових настільних програм без попереднього
вивчення безлічі нових навичок. Будь-який написаний вами веб-додаток може
працювати на Electron.js. Так само будь-яка програма Node.JS, яку ви пишете, може
використовувати цю технологію. Electron JS використовує веб-технології, такі як
простий HTML, CSS та JavaScript. Це не вимагає скіл сеньйора, якщо, звичайно, вам
не потрібно щось просунуте. Фреймворк може бути розроблений для одного
браузера. Його файлова система належить API-інтерфейсам Node.js та працює в
Linux, Mac OS X, Windows. Electron JS використовує модуль NPM, який широко
використовується для JavaScript. Він складається з власного меню для діалогів та
повідомлень. Інсталятори Windows не потребують налаштування.
Він також має можливість автоматичного оновлення та створення звітів про
збої в Windows та Mac за допомогою Squirrel. Звіти про збої відправляються на
віддалений сервер для подальшого аналізу. За діями щодо відстеження контенту,
такими як налагодження та профільування, слідкує Chromium.
Тепер давайте проллємо світло на те, на що схожа архітектура Electron.js.
Якщо ви кажете, що Electron.js – це піца, а Node.JS – це основа, то Chrome – це сир, а
V8 JavaScript Engine – начинка:
libchromiumcontent — це веб-браузер з відкритим вихідним кодом,
створений Google, який надає віконний менеджер із вкладками або
оболонку для Інтернету. Він має мінімалістичний інтерфейс користувача і
використовує V8 як движок JavaScript і blink як движок компонування.
92
Libchromiumcontent — це бібліотека рендерингу Chromium, яка є основою
з відкритим кодом для браузера Google Chrome;
node.js — це середовище виконання JavaScript з відкритим вихідним кодом,
в якому використовується двигун JavaScript V8. Він дозволяє запускати
JavaScript поза браузером, а також надає інтерактивну оболонку, в якій ви
можете виконувати необроблений JavaScript;
javascript-движок v8 - V8 JavaScript Engine також є движком JavaScript з
відкритим вихідним кодом, розробленим Google, написаним на C + + і
JavaScript.
Складні та стомлюючі частини створення настільного додатка – це спрощення
упаковки, встановлення, оновлення, забезпечення підтримки власних меню,
повідомлень, діалогових вікон та, нарешті, оптимізація звітів про збої програми.
Electron JS значною мірою подбає про всі ці важливі кроки, щоб користувач міг
зосередитися на ядрі своєї програми. Коли ми пишемо програму для веб-браузера,
ми переважно пишемо код, який буде виконуватися на чужому комп'ютері. Ми не
знаємо, які браузери будуть використовувати наші цільові користувачі. Це може бути
остання версія Chrome або застаріла версія Internet Explorer. Отже, не залишається
великого вибору, окрім як бути консервативними у технологіях, які ми вибираємо
для реалізації, та у типі коду, який потрібно накидати. Коли ви створюєте свої
програми за допомогою Electron, ви пакуєте певну версію Chromium і Node.JS, тому
ви можете покладатися на будь-які функції, доступні в цих версіях.
Навіть у розробників, які не спеціалізуються на фронтенді, є багато вагомих
причин використовувати Electron, у тому числі:
безпека,
велика спільнота розробників та користувачів,
кросплатформна підтримка.
Розробка на Electron має найбільший сенс при створенні багатоплатформних
настільних додатків, яким не потрібно дотримуватися суворих вимог щодо
використання пам'яті та підкреслювати дизайн UX та UI.
93
З Electron можна написати програму лише один раз і поширювати її всюди без
дублювання зусиль з розробки. Мультиплатформний характер Electron може значно
скоротити процес розробки та призвести до суттєвої економії коштів. Більше того,
оскільки програми Electron створюються з використанням трьох основних веб-
технологій – JavaScript, HTML та CSS, – розробники можуть використовувати єдину
кодову базу як для веб-додатків, так і для настільних додатків.
Це інструменти, необхідні Electron.js для створення програми.
Electron — установка готових двійкових файлів Electron для використання
в командному рядку за допомогою npm.
Електронна компіляція — використовує ES2015, CoffeeScript, LESS, SCSS
у програмі без етапу попередньої компіляції.
Electron-packager — упаковує файли та розповсюджує їх у вашому додатку.
Devtron – це офіційне розширення DevTools.
Spectron — тестує програми Electron за допомогою ChromeDriver.
Оскільки за допомогою Electron ви можете створити настільну програму за
допомогою веб-технологій, швидше за все, ваша поточна команда розробників
впорається з цим завданням. Ви можете добре використовувати наявні таланти. Це
також прискорює вихід на ринок, тому що вам не потрібно налаштовувати свій код
для різних систем та їх версій. У більшості випадків Electron буде добрим вибором з
погляду бізнесу. І технічні рішення завжди мають ухвалюватися з урахуванням
перспективи бізнесу. Використання бізнес-контексту для прийняття технологічних
рішень – це перший крок до руйнування кордонів між IT та бізнесом та просто до
створення більш якісних продуктів.
Оскільки програми Electron, по суті, є вікнами браузера з сервером Node.js, що
працює у фоновому режимі, вони, як правило, споживають значний обсяг пам'яті.
Через це немає особливого сенсу використовувати Electron для простих утиліт.
Програми Electron також можуть бути дуже великими в порівнянні з їхніми рідними
аналогами. Різниця в розмірі може бути особливо помітна, коли йдеться про
програми, які не містять занадто багато функцій. Однак у міру того, як пам'ять та
94
дисковий простір з кожним роком дешевшають, аргументи проти використання
Electron для створення простих утиліт поступово втрачають свою актуальність.
Наприклад, Etcher - це простий у використанні додаток для запису образів,
здатний записувати образи ОС на SD-карти та USB-накопичувачі та перевіряти їх
функціональність. На відміну від більшості інших подібних утиліт, Etcher має
гарний інтерфейс користувача, який є практично у всіх додатків Electron.
4.5 Технічний борг та майбутні плани розробки
Технічний борг (також відомий як борг кодингу) [89] — це метафора
програмної інженерії, що позначає накопичені в архітектурі або програмному коді
проблеми, пов'язані з нехтуванням якості при розробці програмного забезпечення та
викликають додаткові витрати праці в майбутньому. Технічний борг зазвичай
непомітний для кінцевих користувачів продукту, а пов'язаний з недоліками в
супровідності, тестованості, зрозумілості, модифікованості, переносимості. За
аналогією з фінансовим боргом, технічний борг може обростати «відсотками» —
ускладненням (або навіть неможливістю) продовження розробки, додатковим часом,
який розробники витратять на зміну програмного продукту, виправлення помилок,
супровід тощо. Хоча збільшення технічного боргу зазвичай негативне впливає на
майбутнє проєкту, воно може бути свідомим, компромісним рішенням,
продиктованим обставинами, що склалися.
Сам собою поганий код який завжди є технічним боргом, оскільки збитки
(«відсотки за боргом») виникають через необхідність зміни коду з часом. Термін
"технічний борг" використовується в першу чергу по відношенню до розробки
програмного забезпечення, але він також може бути застосований і до інших сфер
Проектування. Іноді термін використовується неправильно, позначаючи код, що не
підтримується (англ. legacy code), який є неякісним і написаний кимось іншим.
Технічний борг поточного стартапу містить:
зміна дизайну програми;
коректування функціоналу редактора;
95
оптимізація [82 - 98].
Плани щодо майбутньої зміни функціоналу:
додати нові елементи;
розширення можливостей редактор;
автогенерація за допомогою збору більшої кількості;
додавання нових мов та фрейворків для вивантаження коду;
вбудований магазин;
аукціон.
Висновки до розділу 4
В четвертому розділі розглядається моделювання виконання стартапу та опис
практичної реалізації стартапу: вибір технологічного стеку для розробки,
Проектування архітектури застосунку, інфраструктури застосунку та діаграма
інформаційного потоку.
Визначені основні функціональні вимоги до додатку, пріоритети розробки
яких визначено на першому етапі, а також визначені додаткові функції, які
покращують зручність та привабливість продукту для користувачів.
96
ВИСНОВКИ
Отже, лише питання часу, коли автоматизовані системи займуть своє місце у
сфері ІТ, щоб суттєво прискорити та полегшити процес створення ІТ продукції.
Також це дозволить суттєво знизити ціну самої продукції. У соверменном світі та
компанія, яка зможе найшвидше створити багатофункціональну систему генерації
сайтів, зможе забезпечити на тривалий період великий прибуток.
У кваліфікаційній роботі розглянуті наступні питання:
1. Проаналізовано мету створення стартапу, визначено проблему, яку
необхідно вирішити. На основі проведених досліджень було сформовано
декілька ідей реалізації продукту стартапу, що повинні розв’язати
поставлену проблему та обрано серед них найкращу. Для обраної ідеї
додатку був детально описаний необхідний функціонал. Проведено
маркетингові дослідження, SWOT – аналіз стартапу. Продукти конкурентів
знаходяться у вищому ціновому сегменті та пропонують менший
функціонал, а також дуже обмежені у можливостях. Це свідчить про те, що
обрана ідея продукту стартапу є конкурентоспроможною та перспективною.
2. Розроблено концепцію стартапу, а саме визначені цілі та завдання
стартапу, критерії успішності, обмеження та допущення. Проведено аналіз
зацікавлених сторін, в результаті якого визначено механізм участі та цілі
кожного учасника стартапу. Проаналізувавши усі фактори, можна зробити
висновок, що зацікавлені сторони позитивно впливають на стартап, тому
що кожен має свою вигоду. Логічним завершенням розділу є
обґрунтований стратегічний план, на основі якого сформовано фази
життєвого циклу та зроблений прогноз очікуваних результатів кожної фази
стартапу.
3. Базується на таких елементах як організаційна структура стартапу,
ієрархічна структура робіт стартапу, матриця відповідальності,
календарний план стартапу та ін. Для уникнення ризиків фінансових втрат
97
та перевантаження персоналу, було приділено увагу плануванню ресурсів,
управлінню якістю, ризиками, комунікаціями. Результатом є готовий
календарний план робіт стартапу, з назначеними ресурсами до кожної
задачі, визначеною тривалістю та бюджетною вартістю робіт. Для
реалізації стартапу за планом потрібно 560 робочих днів, або 18 місяців, та
5 156 000 грн. Проведено комп’ютерне моделювання управління стартапом
з відхиленням по строкам стартапу. Реалізація стартапу досягла 41% і
знаходиться на етапі створення прототипу мобільного додатку. Прототип
має весь запланований функціонал та попередній варіант дизайну.
4. Моделювання продукту стартапу є важливим кроком на початкових
етапах розробки додатків. Визначено основні функції додатку, розробка
яких має відбуватися першочергово, та додаткові, що роблять продукт
зручнішим та привабливішим для користувачів. Створено дизайн основних
розділів додатку – головної сторінки, реєстрації користувача, особистого
кабінету, сторінок редактора, перегляду, оплати та вивантаження коду.
Також було визначено механізм моніторингу та контролю виконання робіт
проєкту. Створено систему заходів контролю робіт, що забезпечить
успішну реалізацію стартапу.
Продукт стартапу має практично весь описаний в роботі функціонал.
Користувач може створити продукцію та після оплати отримати свій код..
Розроблений додаток значно зменшує час та ціну розробки ІТ продукції.
Таким чином, у кваліфікаційній роботі всі вимоги технічного завдання
виконані в повному обсязі. Мета роботи досягнута.
98
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ
1. Angular. URL: https://angular.dev/overview (дата звернення: 24.10.2024) .
2. TypeScript. URL: https://www.typescriptlang.org/ (дата звернення:
24.10.2024).
3. RxJs. URL: https://rxjs.dev/ (дата звернення: 24.10.2024).
4. Observable. URL: https://observablehq.com/ (дата звернення: 24.10.2024).
5. Python. URL: https://www.python.org/ (дата звернення: 05.10.2024).
6. Python Technology. URL: https://www.britannica.com/technology/Python-
computer-language (дата звернення: 05.10.2024).
7. HTML5. URL: https://en.wikipedia.org/wiki/HTML5 (дата звернення:
24.10.2024).
8. CSS/CSS3. URL: https://devdoc.net/web/developer.mozilla.org/en-
US/docs/CSS/CSS3.html (дата звернення: 24.10.2024).
9. Botstrap docs. URL: https://getbootstrap.com/docs/5.3/getting-
started/introduction/ (дата звернення: 24.10.2024).
10. Electron. URL: https://www.electronjs.org/blog/10-years-of-electron (дата
звернення: 05.10.2024).
11. A history of Node.js. URL: https://builtinnode.com/2019/05/04/a-history-of-
node-js/ (дата звернення: 04.11.2024) .
12. Node.js Releases. URL: https://nodejs.org/en/about/previous-releases (дата
звернення: 04.11.2024).
13. Atomic Design for Developers: Better Component Composition and
Organization. URL: https://benjaminwfox.com/blog/tech/atomic-design-for-developers
(дата звернення: 07.10.2024).
14. Web Application Architecture: The Latest Guide 2024. URL:
https://peiko.space/blog/article/web-application-architecture (дата звернення: 07.10.2024).
15. What Is Web Application Architecture? Breaking Down a Web App. URL:
https://kinsta.com/blog/web-application-architecture/ (дата звернення: 07.10.2024).
99
16. Wappler. URL: https://wappler.io/ (дата звернення: 21.11.2024).
17. Free Web App Builder. URL: https://www.jotform.com/web-app-builder/
(дата звернення: 21.11.2024).
18. Quarkly. URL: https://quarkly.io/lp/no-code-web-app-builder/ (дата
звернення: 21.11.2024).
19. The full-stack, no-code app builder. URL: https://bubble.io/ (дата звернення:
21.11.2024).
20. Wix. URL: https://uk.wix.com/ (дата звернення: 21.11.2024).
21. Squarespace. URL: https://www.squarespace.com/ (дата звернення:
21.11.2024).
22. Shopify. URL: https://www.shopify.com/ (дата звернення: 21.11.2024).
23. Softr. URL: https://www.softr.io/ (дата звернення: 21.11.2024).
24. Software Developers on Upwork. URL:
https://www.upwork.com/hire/software-developers/cost/ (дата звернення: 21.11.2024).
25. Freelance Developer Rate Explorer. URL: https://arc.dev/freelance-developer-
rates (дата звернення: 21.11.2024).
26. Thumbtack. URL: https://www.thumbtack.com/p/website-development-prices
(дата звернення: 21.11.2024).
27. Development planning: from the concepts to the technique. URL:
https://www.researchgate.net/publication/321765574_Development_planning_from_the_c
oncepts_to_the_technique (дата звернення: 21.11.2024).
28. Evidence-based tools for social policy and programme development. URL:
https://www.developmentanalytics.org/ (дата звернення: 21.11.2024).
29. Understanding Development Communication: Concepts and Goals. URL:
https://journalism.university/development-journalism-for-social-change/development-
communication-concepts-goals/ (дата звернення: 21.11.2024).
30. Time management techniques and strategies for improving personal
productivity and work-life balance. URL: https://www.jetir.org/papers/JETIR2305C29.pdf
(дата звернення: 21.11.2024).
100
31. Fundamentals of Time and Task Management. URL:
https://hwpi.harvard.edu/files/complit/files/fundamentals_of_time_and_task_management.
pdf (дата звернення: 21.11.2024).
32. Design and Build Apps Blazing Fast. URL: https://www.appbuilder.dev/
(дата звернення: 21.11.2024).
33. A Definitive Guide to Front-end Clean Architecture. URL: https://eduardo-
ottaviani.medium.com/a-definitive-guide-to-front-end-clean-architecture-3a62418becb4
(дата звернення: 21.11.2024).
34. Creating A Complete Web App In Foundation For Apps. URL:
https://www.smashingmagazine.com/2015/04/creating-web-app-in-foundation-for-apps/
(дата звернення: 21.11.2024).
35. Building a Solid Foundation in JavaScript. URL:
https://dev.to/imrancodes/building-a-solid-foundation-in-javascript-some-basics-
completed-2o74 (дата звернення: 21.11.2024).
36. Building a Scalable and Maintainable Frontend Architecture. URL:
https://philemono.medium.com/building-a-scalable-and-maintainable-frontend-
architecture-1787248389bc (дата звернення: 21.11.2024).
37. Node.js Architecture. URL: https://radixweb.com/nodejs-architecture (дата
звернення: 04.11.2024).
38. What is an application architecture? URL:
https://www.redhat.com/en/topics/cloud-native-apps/what-is-an-application-architecture
(дата звернення: 21.11.2024).
39. Understanding cloud-native applications. URL:
https://www.redhat.com/en/topics/cloud-native-apps (дата звернення: 21.11.2024).
40. How to Make a Desktop Application? URL:
https://softwaremind.com/blog/how-to-make-a-desktop-application/ (дата звернення:
21.11.2024).
101
41. Building a desktop application with event-driven design. URL:
https://medium.com/@sergeistralenia/building-a-desktop-application-with-event-driven-
architecture-c405c67993f5 (дата звернення: 21.11.2024).
42. Web Application Architecture: A Comprehensive Exploration for 2024. URL:
https://www-netguru-com.translate.goog/blog/web-application-
architecture?_x_tr_sl=en&_x_tr_tl=ru&_x_tr_hl=ru&_x_tr_pto=sc (дата звернення:
21.11.2024).
43. Understanding Web Application Architectures: A Comprehensive Overview of
Infrastructure Models and Components. URL: https://medium.com/@gwenilorac/layout-
of-web-applications-795b3e8e4c1b (дата звернення: 21.11.2024).
44. Web Application Architecture. URL:
https://www.moontechnolabs.com/blog/web-application-architecture/ (дата звернення:
21.11.2024).
45. An Ultimate Guide to Web Application Architecture. URL:
https://www.simform.com/blog/web-application-architecture/ (дата звернення:
21.11.2024).
46. Web Application Architecture. URL: https://www.softkraft.co/web-
application-architecture/ (дата звернення: 21.11.2024).
47. Defining and Justifying IT Policies and Procedures in the Workplace. URL:
https://document360.com/blog/it-policies-and-procedures/ (дата звернення: 22.11.2024).
48. IT Company Rules and Regulations for Employees. URL:
https://www.slajobs.com/it-company-rules-and-regulations-for-employees/ (дата
звернення: 22.11.2024).
49. Critical IT policies every organization should have in place. URL:
https://www.csoonline.com/article/556309/critical-it-policies-you-should-have-in-
place.html (дата звернення: 22.11.2024).
50. Company Policies: 17 Policies to Consider for Your Business. URL:
https://www.indeed.com/hire/c/info/company-policies (дата звернення: 17.11.2024).
102
51. Company rules and regulations. URL: https://fynk.com/en/clauses/company-
rules-and-regulations/ (дата звернення: 17.11.2024).
52. Company contract. URL: https://enty.io/create-
contract?utm_source=google&utm_medium=cpc&utm_campaign=EU-CONTRACTS-
TOS-EEA-
ENG&utm_term=create%20terms%20and%20conditions&gad_source=1&gclid=CjwKC
AiAxea5BhBeEiwAh4t5K-Qg7KTuDAUcSfhXb2GSeJ1OCgHQfXQA_iK-
AWPNya96WNiduV3OqhoCe8IQAvD_BwE (дата звернення: 17.11.2024).
53. Terms & Conditions. URL: https://www.termsfeed.com/blog/sample-terms-
and-conditions-template/ (дата звернення: 17.11.2024).
54. The Essential Small Business Terms and Conditions Template: What You
Need to Know. URL: https://www.iubenda.com/en/help/148380-the-essential-small-
business-terms-and-conditions-template-what-you-need-to-know (дата звернення:
22.11.2024).
55. Design and Build Apps Blazing Fast From Idea to Industry: The Legal
Foundations Every Startup Needs to Know. URL: https://holonlaw.com/from-idea-to-
industry-the-legal-foundations-every-startup-needs-to-know/ (дата звернення:
22.11.2024).
56. Establishment of a company and startup. URL: https://b-plannow.com/en/our-
services/establishment-of-a-company-and-startup/ (дата звернення: 22.11.2024).
57. FAQ STARTUP - CHOICE OF THE CORPORATE STRUCTURE. URL:
https://portolano.it/en/pages/faq-startup-choice-of-the-corporate-structure (дата звернення:
22.11.2024).
58. Best Practices For Startup Legal Structuring. URL:
https://legalnodes.com/article/startup-legal-structuring (дата звернення: 22.11.2024).
59. Legal and Regulatory Compliance. URL:
https://www.bookbaker.com/bn/v/The-Startup-Playbook-A-Venture-Capitalists-Guide-to-
Building-a-Tech-Startup-Legal-and-Regulatory-Compliance/8acc7088-a9f5-49bd-9741-
32100259bd28/18 (дата звернення: 22.11.2024).
103
60. How Much Does Startup Software Development Cost? URL:
https://www.planeks.net/startup-development-costs/ (дата звернення: 14.11.2024).
61. How to create a healthy startup budget. URL:
https://www.brex.com/journal/startup-budget (дата звернення: 14.11.2024).
62. How To Create a Budget for a Startup. URL: https://www.indeed.com/career-
advice/career-development/budget-for-startup (дата звернення: 14.11.2024).
63. How much does it cost to start a startup. URL: https://b-
plannow.com/en/how-much-does-it-cost-to-start-a-startup/ (дата звернення: 14.11.2024).
64. How to create a business budget for your startup: A guide. URL:
https://stripe.com/resources/more/how-to-create-a-business-budget-for-your-startup-a-
guide (дата звернення: 14.11.2024).
65. Startup Budget. URL: https://www.purrweb.com/blog/startup-budget/ (дата
звернення: 14.11.2024).
66. Essential Startup Costs For An It Project Management Business. URL:
https://finmodelslab.com/blogs/startup-costs/it-project-management-startup-costs (дата
звернення: 14.11.2024).
67. Tips for Successful Startup Project Communications. URL: https://pm-
alliance.com/startup-project-communications/ (дата звернення: 14.11.2024).
68. Tips for a successful IT project startup. URL:
https://www.apptension.com/blog-posts/8-tips-for-a-successful-it-project-startup-founders-
should-follow (дата звернення: 14.11.2024).
69. Communication services for startups. URL:
https://vertexcomunicacio.com/en/communication-for-startups/ (дата звернення:
14.11.2024).
70. MODEL OF IT-STARTUPS MANAGEMENT. URL:
https://www.researchgate.net/publication/319997866_MODEL_OF_IT-
STARTUPS_MANAGEMENT (дата звернення: 12.11.2024).
104
71. The Start-up Handbook. URL:
https://otm.illinois.edu/sites/default/files/Start-Up%20Handbook%20for%20web.pdf
(дата звернення: 12.11.2024).
72. From Idea to Startup Business Development Manual Enterpreneurs. URL:
https://www.giz.de/en/downloads_els/2020GIZFrom%20Idea%20to%20StartupBusiness%
20Development%20Manual%20EnterpreneursEN-compressed.pdf (дата звернення:
1.11.2024).
73. Software Development in Startup Companies: A Systematic Mapping Study.
URL: https://arxiv.org/pdf/2307.13104 (дата звернення: 12.11.2024)
74. Desktop Support Engineer PDF. URL:
https://ru.scribd.com/document/360408580/DESKTOP-SUPPORT-ENGINEER-pdf (дата
звернення: 14.10.2024).
75. PDF.js. URL: https://mozilla.github.io/pdf.js/ (дата звернення: 14.10.2024)
76. Editor Manual. URL:
https://cdn.floorplanner.com/static/brochures/FloorplannerManualEN.pdf (дата звернення:
14.10.2024).
77. HTML5 and JavaScript Projects: Build on your Basic Knowledge of HTML5
and JavaScript to Create Substantial HTML5 Applications. URL:
https://www.academia.edu/107824784/HTML5_and_JavaScript_Projects_Build_on_your_
Basic_Knowledge_of_HTML5_and_JavaScript_to_Create_Substantial_HTML5_Applicat
ions (дата звернення: 14.10.2024).
78. Complete guide to PDF.js: The leading JavaScript library for PDF rendering.
URL: https://www.nutrient.io/blog/complete-guide-to-pdfjs/ (дата звернення:
17.10.2024).
79. PDFKit. URL: https://pdfkit.org/ (дата звернення: 17.10.2024).
80. JavaScript PDF. URL: viewer https://www.nutrient.io/blog/how-to-build-a-
javascript-pdf-viewer-with-pdfjs/ (дата звернення: 17.10.2024).
81. Build a JavaScript and Node.js project. URL: https://docs.travis-
ci.com/user/languages/javascript-with-nodejs/ (дата звернення: 20.11.2024).
105
82. JavaScript Optimization Tips To Improve Performance. URL:
https://www.upwork.com/resources/javascript-optimization-tips (дата звернення:
20.11.2024).
83. Efficient code, maximum speed https://alokai.com/blog/optimizing-javascript-
performance (дата звернення: 20.11.2024).
84. Optimize Node.js Application Performance Effortlessly. URL:
https://medium.com/@romulo.gatto/optimize-node-js-application-performance-
effortlessly-d8ebbcfc41fb (дата звернення: 20.11.2024).
85. ptimizing Your Node.js Project: Best Practices for Performance and
Efficiency . URL: https://dev.to/victor1890/optimizing-your-nodejs-project-best-practices-
for-performance-and-efficiency-1ah0 (дата звернення: 20.11.2024).
86. JavaScript Performance Optimization: Techniques for Blazing Fast
Applications. URL: https://certificates.dev/blog/javascript-performance-optimization-
techniques-for-blazing-fast-applications (дата звернення: 20.11.2024)
87. Optimizing Electron.js Apps: Best Practices in Architecture. URL:
https://clouwood.com/optimizing-electron-js-apps-best-practices-in-architecture/ (дата
звернення: 20.11.2024).
88. Electron App Performance - How to Optimize It. URL:
https://brainhub.eu/library/electron-app-performance (дата звернення: 20.11.2024).
89. Node.js High Performance. URL:
http://projanco.com/Library/Node.js%20High%20Performance.pdf (дата звернення:
20.11.2024).
90. Performance Issues and Optimizations in JavaScript: An Empirical Study.
URL: https://software-lab.org/publications/icse2016-perf.pdf (дата звернення:
20.11.2024).
91. Best Practices for Operationalizing Node.js. URL:
https://assets.ctfassets.net/hspc7zpa5cvq/5EKMf9hFPpoKbk96F1xriv/ac10c4d25fd7caef5
56283da088b1db6/operationalizing-node-js.pdf (дата звернення: 20.11.2024).
106
92. CanvasRenderingContext2D. URL: https://developer.mozilla.org/en-
US/docs/Web/API/CanvasRenderingContext2D/globalCompositeOperation (дата
звернення: 20.11.2024).
93. JavaScript - Making canvas a global variable. URL:
https://stackoverflow.com/questions/10270439/javascript-making-canvas-a-global-variable
(дата звернення: 20.11.2024)
94. Advanced Guide to JavaScript Canvas. URL:
https://habtesoft.medium.com/advanced-guide-to-javascript-canvas-8b22774d4ea8 (дата
звернення: 18.11.2024).
95. Fabric.js. URL: https://fabricjs.com/ (дата звернення: 20.11.2024).
96. Optimization in Python. URL:
https://www.halvorsen.blog/documents/programming/python/resources/powerpoints/Opti
mization%20in%20Python.pdf (дата звернення: 20.11.2024)
97. Optimization in Python. URL:
https://kevintcarlberg.net/files/opt_class_icme/4_optimization-in-python.pdf (дата
звернення: 20.11.2024).
98. Pyomo. URL: Optimization Modeling in Python
https://f.openpdfs.org/E315vrGE5Yy.pdf (дата звернення: 20.11.2024).
99. Design Patterns Giacomo Gabrielli, Manuel Comparetti. URL:
http://docenti.ing.unipi.it/~a009435/issw/esercitazioni/1213/design_ptns/Design%20Patter
ns_2009.pdf (дата звернення: 19.10.2024).
100. Design Patterns. URL: https://refactoring.guru/design-patterns/typescript
(дата звернення: 19.10.2024).
101. Design Patterns in TypeScript. URL:
https://github.com/torokmark/design_patterns_in_typescript (дата звернення:
19.10.2024).
102. Design Patterns in TypeScript. URL:
https://medium.com/@ennkay161/design-patterns-in-typescript-260108159ea9 (дата
звернення: 19.10.2024).
107
103. Design Patterns Elements of Reusable Object-Oriented Software. URL:
https://www.javier8a.com/itc/bd1/articulo.pdf (дата звернення: 19.10.2024).