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/6752| Title: | Управління проєктом розробки інформаційної системи моніторингу цін у Інтернет магазинах |
| Authors: | Андрієнко, Володимир Олександрович Данилюк, Андрій Андрійович |
| Keywords: | ІНФОРМАЦІЙНА СИСТЕМА;РОЗРОБКА ПРОЄКТУ;ПЛАНУВАННЯ ПРОЄКТУ;МОНІТОРИНГ ЦІН. |
| Issue Date: | 29-Jan-2024 |
| Abstract: | Моніторинг цін є важливим інструментом для забезпечення ефективного управління бізнесом, утримання конкурентоспроможності та задоволення потреб споживачів. Все більше і більше бізнесів впроваджує у свою роботу моніторинг цін. У цьому має стати в пригоді інформаційна система моніторингу цін, проєкт якої розроблений в кваліфікаційній роботі магістра. Мета дослідження полягає у розробці інформаційної системи моніторингу цін з використанням технологій управління проєктами в галузі інформаційних технологій. Об’єкт дослідження: процеси управління проєктом розробки інформаційної системи моніторингу цін на різних фазах його реалізації. Предмет дослідження: проєкт розробки інформаційної системи моніторингу цін в Інтернет магазинах. |
| URI: | https://er.chdtu.edu.ua/handle/ChSTU/6752 |
| Appears in Collections: | 122 Комп’ютерні науки (Управління стартапами і проектами в галузі інформаційних технологій) |
Files in This Item:
| File | Description | Size | Format | |
|---|---|---|---|---|
| Пояснювальна записка_Данилюк Андрій_МСТП-2202_2023-2024.pdf Restricted Access | 4.34 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 курсу, групи МСТП-2122
спеціальності 122 – «Комп’ютерні науки»
(шифр і назва спеціальності)
освітня програма «Управління стартапами
(назва освітньої програми)
і проєктами в галузі інформаційних технологій»
Данилюк Андрій Андрійович
Керівник Андрієнко В.О.
(прізвище та ініціали)
Рецензент Антонюк В.С.
(прізвище та ініціали)
Черкаси 2024 року
2
Бланк завдання на кваліфікаційну роботу магістра студенту
Черкаський державний технологічний університет
Факультет Інформаційних технологій і систем
Кафедра Комп’ютерних наук та системного аналізу
Освітньо-кваліфікаційний
рівень М Магістр
Спеціальність 122 – комп’ютерні науки
Освітня програма Управління стартапами і проєктами в галузі інформаційних
технологій
ЗАТВЕРДЖУЮ
Завідувач кафедри КНСА
_______________ Юрій ТРИУС
«____» _____________ 20__ р.
ЗАВДАННЯ
на кваліфікаційну роботу магістра студенту
Данилюку Андрію Андрійовичу
(прізвище, ім‘я, по батькові)
1. Тема роботи «Управління проєктом розробки інформаційної системи моніторингу цін у
Інтернет магазинах»
Керівник роботи Андрієнко Володимир Олександрович, к.т.н., доцент
(прізвище, ім’я, по батькові, науковий ступінь, вчене звання)
затверджені наказом університету від «06» жовтня 2023 р. № 267/04.
2. Строк подання студентом роботи «22» січня 2024 року
3. Вихідні дані до роботи:
Звіт з переддипломної практики
4. Зміст пояснювальної записки (перелік питань, що їх належить розробити):
Вступ
4.1. Аналіз передумов створення ІТ-проєкту.
4.2. Розробка концепції проєкту.
4.3. Планування та управління проєкту.
4.4 Моделювання виконання проєкту.
Висновки.
5. Перелік додатків (з точним зазначенням назв додатків):
Інструкція користувача
5.1. Додаток А. Специфікація 482. ЧДТУ. 42234-01
5.2. Додаток Б. Текст програм в СКМ Matlab та СППР Decisioner для аналізу альтернативної ідеї
розробки проєкту.
3
5.3. Додаток В. Текст програм, повний перелік робіт з діаграмою Ганта та повна мережева схема
в MS Project.
6. Консультанти розділів роботи
Прізвище, ініціали та Підпис, дата
Розділ
посада консультанта завдання видав завдання прийняв
КАЛЕНДАРНИЙ ПЛАН
Строк
№ з/п Назва етапів кваліфікаційної роботи магістра виконання Примітка
етапів роботи
1 Видача завдання на кваліфікаційну роботу до 02.10.2023 Виконано
магістра.
2 Аналіз літературних джерел, об’єкту та предмету до 20.10.2023 Виконано
дослідження.
3 Написання теоретичного розділу кваліфікаційної до 05.11.2023 Виконано
роботи магістра.
4 Написання аналітичного розділу (аналіз об’єкту до 20.11.2023 Виконано
й предмету дослідження).
5 Написання практичних розділів й висновків по до 05.12.2023 Виконано
роботі.
6 Передзахист кваліфікаційної роботи магістра на 15.01.2024 Виконано
засіданні випускової кафедри.
7 Подання роботи завідувачу кафедри. до 22.01.2024 Виконано
8 Захист кваліфікаційної роботи магістра. 29.01.2024 Виконано
Студент _____________________________ Андрій ДАНИЛЮК
(підпис)
Керівник роботи ____________________________ Володимир АНДРІЄНКО
(підпис)
4
РЕФЕРАТ
Кваліфікаційна робота магістра містить: 67 с., 29 рис., 12 табл., 15
використаних джерел, 3 додатки.
Актуальність теми. Моніторинг цін є важливим інструментом для
забезпечення ефективного управління бізнесом, утримання конкурентоспроможності
та задоволення потреб споживачів.
Все більше і більше бізнесів впроваджує у свою роботу моніторинг цін. У цьому
має стати в пригоді інформаційна система моніторингу цін, проєкт якої розроблений
в кваліфікаційній роботі магістра.
Мета роботи і задачі дослідження. Мета дослідження полягає у розробці
інформаційної системи моніторингу цін з використанням технологій управління
проєктами в галузі інформаційних технологій.
Задачі, що вирішуються в роботі:
– проведення дослідження ринку систем моніторингу цін;
– дослідження особливостей методологій управління проєктами в ІТ галузі;
– розробка компонентів управління проєктом розробки інформаційної
системи моніторингу цін;
– виявлення та оцінка можливостей подальшого удосконалення системи з
метою розширення її функціональності.
Об’єкт дослідження: процеси управління проєктом розробки інформаційної
системи моніторингу цін на різних фазах його реалізації.
Предмет дослідження: проєкт розробки інформаційної системи моніторингу
цін в Інтернет магазинах.
Методи дослідження.
У процесі дослідження використовувалися наступні методи:
– експертне оцінювання альтернатив;
– методи прийняття рішень в умовах невизначеності;
– календарне планування;
– метод критичного шляху.
5
Користувачі системи матимуть можливість отримувати аналітичні звіти по
цінам на товари в Інтернет магазинах, отримання вихідної інформації у xml та json
форматах для побудови власної політики ціноутворення.
Перелік ключових слів: ІНФОРМАЦІЙНА СИСТЕМА, РОЗРОБКА
ПРОЄКТУ, ПЛАНУВАННЯ ПРОЄКТУ, МОНІТОРИНГ ЦІН.
ABSTRACT
The master's thesis contains: 67 pages, 29 figures, 12 tables, 15 used sources, 3
appendices.
Actuality of theme. Price monitoring is an important tool for ensuring effective
business management, maintaining competitiveness and meeting consumer needs.
More and more businesses are implementing price monitoring in their work. The price
monitoring information system, the project of which was developed in this qualification
work, should come in handy for this.
The purpose and objectives of the research. The purpose of the study is to develop
an information system for price monitoring using project management technologies in the
field of information technology.
Tasks solved in the work:
− Researching the market of price monitoring systems;
− Study of the peculiarities of project management methodologies in the IT industry;
− Development of project management components for the development of a price
monitoring information system;
− identification and assessment of opportunities for further improvement of the price
monitoring systems in order to expand its functionality.
The object of the research is the project management processes of the development
of a price monitoring system at various phases of its implementation.
The subject of the research is the project of developing a price monitoring system.
The following methods were used in the research process:
− Expert evaluation of alternatives;
6
− Methods of decision-making in conditions of uncertainty;
− Calendar planning;
− the critical path method.
System users will have the opportunity to receive analytical reports on the prices of
goods in online stores, receive source information in xml and json formats to build their own
pricing policy.
List of keywords: INFORMATION SYSTEM, PROJECT DEVELOPMENT,
PROJECT PLANNING, PRICE MONITORING.
7
ЗМІСТ
ПЕРЕЛІК УМОВНИХ ПОЗНАЧЕНЬ, СИМВОЛІВ, СКОРОЧЕНЬ І ТЕРМІНІВ 8
ВСТУП 9
1 АНАЛІЗ ПЕРЕДУМОВ СТВОРЕННЯ ІТ-ПРОЄКТУ 11
1.1 Постановка та обґрунтування проблеми 11
1.2 Опис задуму створеного проєкту 12
1.3 Аналіз аналогів проєкту, що реалізується в роботі 12
1.4 Аналіз альтернативних ідей та вибір найбільш привабливої альтернативи для
реалізації проєкту 16
Висновки до розділу 1 18
2 РОЗРОБКА КОНЦЕПЦІЇ ПРОЄКТУ 19
2.1 Зацікавлені сторони та їх вплив на стартап 19
2.2 Розробка концепції стартапу 22
2.3 Життєвий цикл проєкту 24
Висновки до розділу 2 27
3 ПЛАНУВАННЯ ТА УПРАВЛІІННЯ ПРОЄКТУ 29
3.1 Управління змістом проєкту 29
3.2 Планування часу проєкту 36
3.3 Планування трудових ресурсів проєкту 41
3.4 Призначення ресурсів до робіт проєкту 43
3.5 Планування якості проєкту 48
3.6 Управління ризиками проєкту 50
3.7 Планування бюджету проєкту 55
3.8 Управління комунікаціями в проєкті 57
Висновки до розділу 3 58
4 МОДЕЛЮВАННЯ ВИКОНАННЯ ПРОЄКТУ 60
4.1 Механізм контролю робіт проєкту 60
4.2 Опис засобів програмної реалізації додатку 61
4.3 Опис функцій та можливостей додатку 62
Висновки до розділу 4 65
ВИСНОВКИ 66
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ 68
ДОДАТКИ 69
8
ПЕРЕЛІК УМОВНИХ ПОЗНАЧЕНЬ, СИМВОЛІВ, СКОРОЧЕНЬ І ТЕРМІНІВ
СППР – система підтримки прийняття рішень;
СКМ – система комп’ютерної математики;
СДР – структура декомпозиції робіт;
ІСР – ієрархічна структура робіт;
СУБД – система управління базами даних;
WBS – work breakdown structure;
MS – Microsoft;
OBS – organizational breakdown structure.
9
ВСТУП
Актуальність теми. Моніторинг цін в магазинах є важливою складовою
успішної стратегії бізнесу, як для власників магазинів, так і для споживачів. Ось
декілька причин, чому важливо вести моніторинг цін:
Конкурентоспроможність: спостереження за цінами в інших магазинах
дозволяє підтримувати конкурентоспроможність в ринкових умовах. Якщо ваші ціни
вищі або нижчі, ніж у конкурентів, це може вплинути на кількість клієнтів, які
обирають ваш магазин.
Максимізація прибутковості: аналіз цін дозволяє оптимізувати стратегію
ціноутворення, спрямовуючи зусилля на максимізацію прибутковості. Вірне
установлення цін може позитивно впливати на обсяги продажів і прибуток.
Взаємодія з покупцями: постійний моніторинг дозволяє ефективно реагувати на
зміни у попиті та уподобаннях споживачів. Ви можете швидко адаптувати ціни на
популярні товари та пропонувати знижки або акції, щоб залучити більше покупців.
Управління запасами: моніторинг цін допомагає в управлінні запасами.
Відстеження цінової динаміки дозволяє планувати закупівлі та уникати надмірного
або недостатнього залишку товарів.
Підвищення лояльності споживачів: послідовне утримання
конкурентоспроможних цін сприяє збереженню та залученню клієнтів. Споживачі
часто порівнюють ціни перед покупкою, тому якщо ваші ціни привабливі, це може
позитивно вплинути на їхню лояльність.
Реагування на ринкові тенденції: моніторинг цін дозволяє вчасно реагувати на
зміни в ринкових умовах, такі як зміни в цінах на конкурентних ринках або зміни
витрат на виробництво.
З отриманням даних про поточний стан цін в Інтернет магазинах допоможе
інформаційна система, проєкт якої розроблений в кваліфікаційній роботі магістра.
Мета та задачі дослідження. Мета дослідження полягає у розробці
інформаційної системи моніторингу цін з використанням технологій управління
проєктами в галузі інформаційних технологій.
10
Задачі, що вирішуються в роботі:
– проведення дослідження ринку систем моніторингу цін в Інтернет
магазинах;
– дослідження особливостей методологій управління проєктами в ІТ галузі;
– розробка компонентів управління проєктом розробки інформаційної
системи моніторингу цін і Інтернет магазина;
– виявлення та оцінка можливостей подальшого удосконалення
інформаційної системи моніторингу цін.
Об’єктом дослідження є процеси управління проєктом розробки
інформаційної системи моніторингу цін у Інтернет магазинах на різних фазах його
реалізації.
Предмет дослідження – проєкт розробки інформаційної системи моніторингу
цін у Інтернет магазинах.
У процесі дослідження використовувалися наступні методи:
– експертне оцінювання альтернатив;
– методи прийняття рішень в умовах невизначеності;
– календарне планування;
– метод критичного шляху.
Користувачі матимуть можливість отримати аналітичні звіти по поточному
стану цін у Інтернет магазинах. Дану інформацію користувачі можуть
використовувати у власних процесах ціноутворення що надасть
конкурентоспроможність їх бізнесу.
11
1 АНАЛІЗ ПЕРЕДУМОВ СТВОРЕННЯ ІТ-ПРОЄКТУ
1.1 Постановка та обґрунтування проблеми
Моніторинг цін в магазинах є важливою складовою успішної стратегії бізнесу,
як для власників магазинів, так і для споживачів. Ось декілька причин, чому важливо
вести моніторинг цін:
Конкурентоспроможність: Спостереження за цінами в інших магазинах
дозволяє підтримувати конкурентоспроможність в ринкових умовах. Якщо ваші ціни
вищі або нижчі, ніж у конкурентів, це може вплинути на кількість клієнтів, які
обирають ваш магазин.
Максимізація прибутковості: аналіз цін дозволяє оптимізувати стратегію
ціноутворення, спрямовуючи зусилля на максимізацію прибутковості. Вірне
встановлення цін може позитивно впливати на обсяги продажів і прибуток.
Взаємодія з покупцями: постійний моніторинг дозволяє ефективно реагувати на
зміни у попиті та уподобаннях споживачів. Існує можливість швидкої адаптації ціни
на популярні товари та пропонувати знижки або акції, щоб залучити більше покупців.
Управління запасами: моніторинг цін допомагає в управлінні запасами.
Відстеження цінової динаміки дозволяє планувати закупівлі та уникати надмірного
або недостатнього залишку товарів.
Підвищення лояльності споживачів: послідовне утримання
конкурентоспроможних цін сприяє збереженню та залученню клієнтів. Споживачі
часто порівнюють ціни перед покупкою, тому якщо ціни привабливі, це може
позитивно вплинути на їхню лояльність.
Реагування на ринкові тенденції: моніторинг цін дозволяє вчасно реагувати на
зміни в ринкових умовах, такі як зміни в цінах на конкурентних ринках або зміни
витрат на виробництво. Тож у власників бізнесів виникають питання:
– Скільки коштує такий самий товар в інших магазинах?
– Чи конкурентна у мене ціна по ринку?
– Хто з мережі дистрибʼюторів демпінгує ціни?
12
1.2 Опис задуму створеного проєкту
Основною концепцією проєкту є створення інформаційної системи для ведення
моніторингу цін в Інтернет-магазинах. Система буде надавати змогу кінцевому
користувачеві надавати аналітичну інформацію про ціни на товари у Інтернет
магазинах. За допомогою системи користувачі матимуть можливість вибудовувати
власну стратегію ціноутворення. Також система буде корисна офіційним
дистрибʼюторам так як надасть змогу контролювати виконання домовленостей
інтернет магазинами щодо рекомендованих роздрібних цін. Система має давати змогу
співробітникам співставляти товари клієнта з товарами у магазинах. Інформаційна
система матиме інформативні аналітичні звіти які будуть відповідати на питання:
– ціни в інтернет магазинах;
– наявність товарів в інтернет магазинах;
– слідування рекомендованим роздрібним цінам.
Окрім того планується системі надати можливість віддавати зібрані ціни по API
через json, xml формат. Це надасть можливість зручного обміну даними з
інформаційними системами вже на стороні клієнтів.
Ще однією особливістю системи буде можливість відправляти рекламні
демонстраційні звіти по різним брендам товарів. Це має бути одним з шляхів
залучення нових клієнтів для роботи з системою.
1.3 Аналіз аналогів проєкту, що реалізується в роботі
Оскільки задача моніторингу цін не нова, то вже є декілька систем які
дозволяють моніторити ціни і Інтернет магазинах. Деякі з них вузького призначення,
деякі мають досить широкі функціональні можливості. Для аналізу і порівняння
аналогів до проєкту, що розробляється, було обрано найбільш конкурентоздатні:
– «Competera» [1];
– «Z-PRICE» [2];
– «PriceControl» [3].
13
Найбільш привабливою системою серед цих систем є «Competera».
«Competera» – це система цінової оптимізації та моніторингу цін, яка надає рішення
для роздрібних та онлайн-торгових компаній. Основні особливості та можливості
системи «Competera» включають в себе:
Моніторинг цін. Система автоматично відстежує ціни на товари та послуги
конкурентів. Забезпечує структуровану інформацію про цінові зміни та акції в
реальному часі. Можливість відслідковувати цінові стратегії різних гравців на ринку.
Аналіз конкурентоспроможності. Надає аналітику та порівняльний аналіз цін,
що допомагає підтримувати конкурентоспроможність продуктів чи послуг.
Прогнозування цін. Використовуючи аналітичні методи та алгоритми,
«Competera» може надавати прогнози щодо майбутніх цінових тенденцій на ринку.
Автоматизація цінової стратегії. Дозволяє налаштовувати автоматичні правила
для цінової політики на основі зібраної інформації та аналітики.
Моніторинг асортименту. Включає в себе відстеження змін в асортименті
товарів та послуг конкурентів.
Сповіщення та звіти. Надає можливість налаштовувати систему сповіщень для
оперативної реакції на зміни в цінах або асортименті.
Інтеграція. «Competera» може бути інтегрована з іншими системами управління
електронною комерцією (ЕРП, CRM) та платформами для максимальної
ефективності.
Підтримка прийняття рішень. Надає засоби для прийняття обґрунтованих
рішень у сфері ціноутворення та конкурентоспроможності.
Серед недоліків системи «Competera» можна виділити наступні:
Складність впровадження. Великі системи моніторингу та оптимізації цін
можуть вимагати складного процесу впровадження та налаштування, особливо для
великих компаній з різними категоріями товарів і складними ціновими стратегіями.
Вартість. Вартість використання подібних систем може бути високою,
особливо для менших підприємств або стартапів, що може впливати на їхню
фінансову ефективність.
На рисунку 1.1 представлено інтерфейс ІС «Competera».
14
Рисунок 1.1 – Інтерфейс ІС «Competera»
На рисунку 1.2 представлено Інтерфейс ІС «Z-PRICE».
Рисунок 1.2 – Інтерфейс ІС «Z-PRICE»
Аналізуючи ІС «Z-PRICE» (рис. 1.2), варто відзначити, що якщо з додатком від
Loup. у проєкті, що розробляється, багато спільного, то додаток Nike Inc. має свої
суттєві відмінності. Він представляє собою щось на кшталт онлайн тренера. Тобто,
він також містить програми тренувань для різних цілей та від різних відомих
спортсменів. Проте, користувач не може їх адаптувати під себе, що є серйозним
недоліком додатку. Сутність додатку ж полягає в тому, що користувач запускає його
15
прямо на тренуванні, і виконує всі вправи, що йому пропонуються, в режимі
реального часу, з вказаними інтервалами відпочинку та роботи. Комусь можливо це і
підійде, не потрібно витрачати час на самостійний підбір тренувань, просто
користувач обирає тренування та слідуєте інструкціям. Але такий підхід не дає
можливості враховувати особисті потреби користувача, що в деяких випадках не
дуже зручно.
Інформаційна система PriceControl дещо схожа з ІС «Z-Price» і також забезпечує
моніторинг цін в Інтернет магазинах.
На рисунку 1.3 представлено Інтерфейс додатку «HIIT|Down Dog».
Рисунок 1.3 – Інтерфейс додатку «HIIT|Down Dog»
У таблиці 1.1 здійснено порівняльний аналіз розглянутих інформаційних
систем за певними критеріями.
Як видно з таблиці 1.1, за всіма критеріями система «Competera» є найбільш
конкурентною для системи що створюється у роботі. В неї є багато функціональних
переваг. Отже, саме на неї слід звернути увагу при подальшій роботі над проєктом.
16
Таблиця 1.1 – Порівняльний аналіз додатків-конкурентів
Критерії «Competera» «Z-Price» «PriceControl»
Демо-звіти - - +
Динамічна підписка + - -
Алгоритми ціноутворення + + -
Налаштування розкладу звітів + - -
Сповіщення про демпінг - - +
Дизайн та інтерфейс + + +
Можливість користуватися без - + -
платної підписки
Простота використання + + +
Результати 5 4 4
1.4 Аналіз альтернативних ідей та вибір найбільш привабливої
альтернативи для реалізації проєкту
Для більшого розуміння ринку та на випадок непередбачуваних ризиків,
проаналізуємо альтернативні ідеї для реалізації проєкту та визначимо, яка з них буде
кращою альтернативою основному проєкту.
Для аналізу оберемо 4 альтернативи, а саме:
– cтворення інформаційної системи моніторингу цін “Моніторинг цін”;
– cтворення інформаційної системи прайсів постачальників “Прайс”;
– cтворення інформаційної системи аналізу наявності “Наявність”.
Сутність інформаційної системи моніторингу цін полягає в тому що користувач
може надати свій прайс, визначити магазини які його цікавлять для моніторингу і
отримувати аналітичні звіти по цінам в магазинах. Маючи прайс від клієнта система
також може в аналітичних звітах виділяти ціни що відхилились від рекомендованих
роздрібних цін. Шляхом зміни прайсу клієнт може модифікувати склад товарів що
попадають у моніторинг.
Сутність системи прайсів постачальників полягатиме у акумулюванні даних по
цінам від постачальників і наданню інформації про ціну клієнту. У разі доступності
товару у декількох постачальників система пропонуватиме найкращу ціну. Також за
17
допомогою інформації у прайсі користувачу можна буде видавати рекомендації щодо
правильних найменувань товарів та їх характеристик.
Сутність системи аналізу наявності полягатиме у моніторингу лише наявності
товару. Система не матиме функцію співставлення товарів. Вихідними даними для
моніторингу буде перелік посилань на сторінки товарів за якими система проведе
аналіз доступності товару і видасть результат.
Щоб обрати найпривабливішу альтернативу для проєкту проведемо аналіз із
урахуванням ризиків, зумовлених такими зовнішніми умовами:
– зникнення фінансування проєкту;
– вихід на ринок схожого продукту, з кращими характеристиками;
– раптова втрата великої кількості клієнтів;
– форс-мажорні обставини (війна, шторм, блекаут тощо).
Оскільки вибір альтернативи для проєкту здійснюється в умовах
невизначеності, то й аналіз будемо проводити з використанням відповідних
математичних критеріїв, зокрема: критеріїв Лапласа, Вальда, Севіджа та Гурвіца.
Розв’язання цієї задачі проведемо за допомогою СППР «Dicisioner» [4] та СКМ
«Matlab» [5]. У таблиці 1.2 представлені результати обрахунків за допомогою двох
вище вказаних ресурсів. Повне виконання даного аналізу наведене в додатку А.
Таблиця 1.2 – Результати обрахунків за допомогою СКМ Matlab та СППР Decisioner
СКМ Matlab СППР Decisioner
№ Розрахунок Оптимальна альтернатива Оптимальна альтернатива
1 За критерієм Моніторинг цін Моніторинг цін
Лапласа
2 За критерієм Моніторинг цін, Прайс, Наявність Моніторинг цін
Вальда
3 За критерієм Моніторинг цін Моніторинг цін
Севіджа
4 За критерієм Моніторинг цін Моніторинг цін
Гурвіца
18
Як бачимо, результати для прийняття рішення з використанням обох ресурсів
збігаються, тобто найкращою альтернативою є перша альтернатива, тобто система
«Моніторинг цін».
Отже з цього випливає, що найкращою альтернативною ідеєю є створення
інформаційної системи «Моніторинг цін».
Висновки до розділу 1
У даному розділі була описана проблема, яку вирішує створена у роботі
інформаційна система, а також обґрунтована її актуальність. Чітко описана ідея
розроблюваної системи, її переваги та недоліки. Завдяки цьому були визначені цілі та
обмеження проєкту.
В рамках розділу також був проведений аналіз конкурентів для більш чіткого
розуміння ринку та того, які у подібних системах можуть бути недоліки та як з ними
боротися.
Також на випадок непередбачуваних обставин було обрано альтернативну ідею
для розробки, для цього було проведено аналіз з використанням відповідних
математичних критеріїв прийняття рішень в умовах невизначеності, та використано
відповідні програмні засоби.
За підсумками даного аналізу було обрано оптимальну альтернативу –
інформаційну систему «Моніторинг цін», що буде розроблятися у межах
кваліфікаційної роботи.
Також під час даного аналізу стало зрозуміло, як ті чи інші зовнішні умови
можуть впливати на подібні додатки.
19
2 РОЗРОБКА КОНЦЕПЦІЇ ПРОЄКТУ
2.1 Зацікавлені сторони та їх вплив на стартап
При проведенні аналізу зацікавлених сторін особливо важливо провести
комплексний аналіз усіх учасників, зацікавлених у реалізації проєкту. Для початку
необхідно виділити всі зацікавлені сторони проєкту (рис. 2.1).
Замовник:
ТОВ
Ініціатор: “Прайскоп”
Данилюк Власник:
Андрій ТОВ “Прайскоп”
Менеджер
проєкту:
Інвестор: Данилюк А.А.
ТОВ Конкуренти:
“Прайскоп” Z-price, priceva
Команда
проєкту:
BE програміст
Споживачі: (2),
Клієнти ТОВ FE програміст
“Прайскоп”, (1), Постачальники
QA тестувальник
яким Магазин
(1)
необхідна комп’ютерного
послуга обладнання
моніторингу
цін
Рисунок 2.1 – Зацікавлені сторони проєкту
Тепер розглянемо докладніше всіх осіб, які беруть участь у проєкті:
– Ініціатор/Замовник/Власник/Інвестор – ТОВ “Прайскоп”.
Механізм участі: створення ідеї проєкту, пошук команди для реалізації,
планування, фінансування, контроль виконання проєкту, проведення рекламної
кампанії, прийняття рішень на всіх етапах реалізації проєкту.
Цілі: отримати продукт проєкту, прибуток. Основна ціль – успіх проєкту.
– Менеджер проєкту – Данилюк А.А.
20
Механізм участі: пошук команди для реалізації, планування, контроль
виконання проєкту.
Цілі: отримати продукт проєкту, досвід в управлінні проектами, прибуток.
Основна ціль – успіх проєкту.
– Команда проекту – Back-end програміст (2), front-end програміст (1), QA
тестувальник (1), бізнес аналітик (1), devops (1), customer support (1).
Механізм участі: розробка та реалізація інформаційної системи, створення
дизайну, тестування продукту, маркетингові дослідження.
Цілі: отримати досвід роботи в команді, підвищити кваліфікацію, отримати
прибуток.
– Органи влади – податкова служба.
Механізм участі: надання реєстрації підприємства, оподаткування.
– Конкуренти – інформаційні система «Competera».
Механізм участі: конкуренція, пошук переваг та недоліків.
– Споживачі фінального продукту проекту – Клієнти ТОВ Прайскоп. Інтернет-
магазини та офіційні дистриб'ютори продукції на ринку. Організації яким для
вирішення внутрішніх питань ціноутворення треба знати аналітичну
інформацію по ринку про ціни та їх динаміку.
Механізм участі: придбання підписки на розсилку аналітичних звітів.
Цілі: отримати продукт, який задовольняє вимоги, покращить механізми
ціноутворення.
– Постачальники – магазини компʼютерного обладнання.
Механізм участі: продаж необхідного компʼютерного обладнання для роботи
команди проєкту.
Цілі: отримати прибуток.
Клієнти – кінцеві користувачі інформаційної системи, отже продукт має
відповідати вимогам та очікуванням користувачів.
Постачальники повинні бути партнерами, оскільки умови співпраці є
взаємовигідними. Затримки з боку постачальника призведуть до затримки платежів
21
замовником. Крім того, для постачальників важливо мати постійного клієнта, а
замовник має можливість отримувати знижки.
На органи влади важко вплинути, тому їх слід враховувати у плані реагування
на ризики, а також при плануванні проекту, тобто притримуватися стратегії
реагування та адаптації.
В таблиці 2.1 вказано вплив, який зацікавлені сторони мають на різні аспекти
виконання проєкту, такі як: ресурси, вимоги до проєкту, процеси проєкту та оцінка
виконання.
Таблиця 2.1 – Вплив зацікавлених сторін на проєкт
Проаналізувавши усі фактори, можна зробити висновок, що зацікавлені
сторони позитивно впливають на проєкт, тому що кожен має свою вигоду.
22
2.2 Розробка концепції стартапу
Сьогодні всюди є ціноутворення, у всіх сферах життя присутні торговельні
відносини. Завдяки інформаційним системам та додаткам люди мають можливість
оптимізовувати та організовувати витрати. Набір інформації, який зараз пропонують
інформаційні системи допомагає компаніям планувати закупівлі та продажі, тим
самим сприяючи отриманню прибутку. Існує багато систем, які відповідають
потребам компаній і роблять їх бізнес-процеси більш оптимальними та
ефективнішими. Однією з таких систем може стати система моніторингу цін в
інтернет магазинах.
Мета проєкту: створення продукту, що зможе моніторити ціни в інтернет
магазинах. Система має зберігати ціни з інтернет-магазинів та надавати аналітичну
інформацію замовнику про стан ринку на його бажані товарні позиції.
Цілі проєкту:
– Можливість моніторингу цін у інтернет-магазинах з послідуючою
генерацією аналітичних даних про стан ринку.
– Зменшення часу бордінгу клієнта у систему.
– Можливість налаштування розкладів формування аналітичної інформації.
– Збільшення рівня автоматизації послуг що надаються. Автоматизація має
досягти співвідношення залученності: 1 спеціаліст підтримки на 20 клієнтів.
– Прибуток.
Критерії досягнення цілей проекту відображені в таблиці 2.2.
Таблиця 2.2 – Критерії досягнення цілей
№ Ціль Критерії
1. Можливість моніторингу цін Система безпроблемно має генерувати
звіти на 50 000 позицій
2. Зменшення часу бордінгу клієнта Від отримання прайсу клієнта до
першого збору - 5 робочих днів
23
3. Можливість налаштування Нескінченна кількість розкладів
розкладів формування аналітичної
інформації
4. Збільшення рівня автоматизації 1 спеціаліст підтримки на 20 клієнтів
послуг що надаються
5. Прибуток Прибуток від кожного залученого
клієнта становить від 100$ (в залежності
від обраного тарифного пакету) після
бордінгу його у систему
Продукт проєкту: інформаційна система для моніторингу цін в інтернет
магазинах.
Основний функціонал продукту проєкту:
– зручний та зрозумілий інтерфейс для взаємодії з основними елементами та
функціями системи;
– можливість налаштувати розклад формування звітів;
– можливість збереження співставлення товарів клієнта з товарами в інтернет-
магазинах;
– отримання інформації про ціни у вигляді аналітичних звітів з можливістю
налаштування варіантів звітів;
– наявність актуальних цін та інформації про наявність товарів;
– можливість отримати дані по цінам через API;
– можливість налаштування відправки повідомлень про демпінг.
Критерії успішності проєкту:
– наявність продукту проекту (готова, повністю функціонуюча інформаційна
система);
– клієнти у системі (≥ 20 клієнтів);
– відхилення від плану по проєктам ≤ 10%;
– кількість позитивних оцінок членів команди проєкту ≥ 70%.
24
Обмеження проєкту:
– проєкт має бути реалізовано не більше ніж за 8 місяців;
– бюджет не повинен перевищувати 800 000 грн.
Допущення проєкту:
– часове відхилення від плану реалізації проєкту не більше ніж 2 місяці;
– бюджет може бути перевищено максимум на 100 000 грн.
2.3 Життєвий цикл проєкту
Життєвий цикл проєкту розробки інформаційної системи моніторингу цін в
інтернет магазинах складається з наступних фаз:
– Ініціалізація;
– Планування;
– Реалізація;
– Завершення.
Ключові фази проєкту, їх характеристика та перелік основних робіт виглядають
наступним чином:
Ініціалізація:
– розробка та опрацювання загальної концепції та стратегії проєкту (розробка
стратегії, визначення чітких цілей, завдань, вимог, можливостей, обмежень,
очікуваних результатів проєкту);
– розробка попереднього пакету основної документації по проекту (підготовка
статуту проєкту; попереднє бачення організаційної структури команди;
погодження плану дій на початковий період);
– формування команди;
– розробка бізнес-плану;
– прийняття рішення про реалізацію проєкту.
Планування:
– коригування та затвердження попереднього пакету базової проектної
документації;
25
– розробка та затвердження плану управління проєктом (розробка
календарного плану; розробка плану виконання робіт (WBS); планування
ресурсів);
– встановлення комунікацій (розроблення процедур, регламентів, політик
діяльності та комунікації команди проєкту; розроблення системи контролю
інформації);
– планування бюджету проєкту;
– управління ризиками.
Реалізація:
– управління, контроль та координація ходу виконання проєкту;
– виконання пакетів робіт;
– вирішення конфліктів;
– створення та узгодження ТЗ, створення концептуальної схеми продукту;
– розробка продукту (розробка дизайн-макету додатку; верстка, розробка
основного функціоналу додатку; проведення тестування, виправлення
помилок);
– робота з постачальниками та органами влади (укладання договорів;
реєстрація ФОП).
Завершення:
– формальне завершення всіх етапів проєкту;
– виведення продукту на ринок;
– затвердження закриття проєкту (наказ про закриття проєкту);
– передача продукту замовнику;
– розпуск команди проєкту;
– проведення аналізу результатів (з погляду цілей проєкту, ходу виконання
проєкту, результатів проєкту);
– архівація проєкту.
Результати проєкту за фазами життєвого циклу:
Ініціалізація:
– розроблена загальна концепція та стратегія проєкту;
26
– узгоджений попередній пакет основної документації по проєкту та статут
проєкту;
– сформована команда проєкту.
Планування:
– затверджений план управління проєктом;
– створений і затверджений план проведення рекламної кампанії;
– встановлені комунікації та розроблена система контролю інформації.
Реалізація:
– створені та узгоджені ТЗ та концептуальна схема продукту;
– виконані пакети робіт;
– розроблена та протестована система моніторингу цін.
Завершення:
– наказ про закриття проєкту;
– архівація проєкту;
– розпуск команди;
– закриті контракти.
Тепер можна визначити детальний зміст фаз життєвого циклу проєкту, що
представлено в таблиці 2.3 з тривалістю та ключовими віхами.
Таблиця 2.3 – Зміст фаз життєвого циклу проєкту
Фаза Ініціалізація Планування Реалізація Завершення
Тривалість 33 29 99 38
фази (дні)
Перелік – Формування – Планування – Реєстрація ФОП – Розміщення
основних команди змісту – Розробка додатку в
робіт – Формалізація – Планування концепту магазинах
ідеї трудових ресурсів – Розробка ТЗ – Розпуск
– Аналіз ринку – Планування – Вибір технології команди
– Розробка бюджету – Проектування – Архівація
бізнес-плану – Планування архітектури системи проекту
ризиків – Створення – Аналіз
– Планування структури системи проекту
якості – Розробка дизайну
27
– Планування часу – Створення
– Планування прототипу
комунікацій – Тестування
– Планування – Заключення
закупівель договорів з
постачальниками
– Реалізація
додатку
– Створення
рекламних сторінок
Ключові Прийняте Всі плани проекту Готова система Проект
віхи рішення затверджені моніторингу цін закритий
замовником замовником
Можливі Ідея може Планування може Наявних ресурсів Продукт може
проблеми виявитися бути не дуже може не вистачити виявитися
недоцільною і якісним і точним для успішної недостатньо
неактуальною для через недостатню реалізації продукту якісним,
реалізації кваліфікацію проекту функціональ-
проектного ним,
менеджера конкурентоспро
можним, чи
неактуальним
Отже, тривалість всього життєвого циклу проєкту становить 199 робочих днів
або 6.5 місяців. Обмеження за часом виконання проєкту – 8 місяців, тому запланована
тривалість проєкту відповідає встановленому обмеженню. Фаза ініціалізації триває
33, фаза планування – 29. Найдовша фаза – реалізація, вона триває 99 робочих днів.
Фаза завершення триватиме 38 робочих днів.
Як було зазначено на початку розділу, ефективність проєкту оцінюватиметься
рівнем прибутку та кількістю клієнтів у системі після реалізації продукту.
Висновки до розділу 2
У другому розділі було розроблено концепцію стартапу. В результаті визначені
цілі та завдання проєкту, критерії успішності, обмеження та допущення. Проведено
28
аналіз зацікавлених сторін, в результаті якого визначено механізм участі та цілі
кожного учасника проєкту. Проаналізувавши усі фактори, можна зробити висновок,
що зацікавлені сторони позитивно впливають на проєкт, тому що кожен має свою
вигоду. Логічним завершенням розділу є обґрунтований стратегічний план, на основі
якого сформовано фази життєвого циклу та зроблений прогноз очікуваних
результатів кожної фази проєкту.
29
3 ПЛАНУВАННЯ ТА УПРАВЛІННЯ ПРОЄКТУ
3.1 Управління змістом проєкту
Під час впровадження проєктів передбачається використання знань і методів
управління проєктами в різноманітних областях. Однією з цих областей є управління
змістом проєкту. Без відповідного контролю над змістом неможливо здійснити
ефективне керівництво проєктом.
Управління змістом проєкту передбачає реалізацію процесів, спрямованих на
забезпечення того, щоб у складі проєкту були включені лише ті завдання, які
необхідні для його успішного завершення.
Структура декомпозиції робіт (СДР або WBS, що є скороченням від
англійського терміну Work Breakdown Structure) – це інструмент управління
проєктами, який дозволяє систематизувати і розглядати всі елементи проєкту.
Створення СДР є важливим етапом в плануванні та управлінні проєктами.
Декомпозиція: процес розбиття проєкту на менші, більш управлінсько-
контрольовані частини або роботи. Проєкт декомпозується на підзавдання, які
можуть бути ефективно керовані. Цей розподіл триває до тих пір, поки завдання не
будуть визначені достатньо детально, щоб надати необхідну підтримку для
подальших етапів виконання проєкту.
Перш, ніж створювати СДР, необхідно сформувати структуру продукту та
основні вимоги до нього.
Кінцевим продуктом проєкту є інформаційна система для моніторингу цін в
інтернет магазинах.
На табл. 3.1 представлені високорівневі вимоги до кінцевого результату
проєкту.
Таблиця 3.1 – Високорівневі вимоги до кінцевого результату проєкту
№ Назва вимоги
1 Завантаження цін замовника з зовнішніх джерел (api, xml, google
spreadsheet).
30
2 Можливість налаштувань системи під різні сторінки інтернет магазинів.
3 Можливість налаштування періодичності збору для клієнта в залежності від
обраного ним тарифу.
4 Можливість масштабування потужностей при збільшенні кількості
товарних позицій які перебувають у моніторингу.
5 Можливість інтеграції з ERP-системами клієнта через api.
У процесі створення WBS відбувається послідовна декомпозиція проєкту на
вкладені підпроєкти, різні рівні пакетів робіт і конкретні етапи робіт. Загальний
перелік завдань проєкту фактично представляє собою ієрархічну структуру робіт.
Для створення WBS необхідно оцінити вартість роботи та створити її розклад.
При розробці WBS проєкту необхідно враховувати такі правила:
– кожен елемент WBS повинен забезпечувати досягнення помітного
результату;
– кожен елемент WBS має бути набором усіх підпорядкованих елементів,
перерахованих безпосередньо під ним;
– декомпозиція результатів, від верхнього рівня до нижнього, повинна мати
логічний зв'язок.
Декомпозиція повинна відбуватись з огляду на логічну повʼязаність елементів,
починаючи з першого рівня до останнього. Результативність пакетів робіт повинна
бути унікальною та бути відмінним результатом пакетів робіт того ж самого рівня.
Процес розробки WBS має бути гнучким механізмом, що дозволяє коригувати
систему.
Щоб розробити WBS, треба ітераційно розглядати цілі та результати проєкту,
досягнення функціональності, критеріїв планування і, об’єму робіт, реалізації
технічних вимог. Верхні рівні WBS є загальними областями або фазами проекту, які
служать основою для подальшого детального розгортання. Подальша деталізація
WBS можлива після визначення проєкту та підготовчих особливостей.
Для деталізації кінцевого результату проєкту була створена схема декомпозиції
(рис. 3.1).
31
Рисунок 3.1 – Декомпозиція кінцевого результату проєкту
Під час створення WBS проєкту першим кроком стало визначення кінцевого
результату проєкту – створена та впроваджена інформаційна система моніторингу
цін.
Наступним етапом було визначено основні пакети робіт та відповідні завдання,
які підпорядковуються цим пакетам та є необхідними для отримання кінцевих
результатів або продуктів проєкту.
Детальну та кінцеву структури робіт представлено в табл. 3.2.
32
Таблиця 3.2 – Структура декомпозиції робіт проєкту
№ 1-го № 2-го № 3-го № 4-го Назва задачі Оцінка Ресурси Оцінка
рівня рівня рівня рівня тривалості вартості
1 Розробка ІС “PriceCop”
1.1 Ініціалізація 33 74500
1.1.1 Формування команди 10 PM 15000
1.1.2 Формалізація ідеї 5 PM, BA 15000
1.1.3 Аналіз існуючих 5 PM, BA, 25000
програмних продуктів для BE1
парсинга html-сторінок.
1.1.4 Визначення стейкхолдерів 3 PM 4500
1.1.5 Розробка статуту проекта 10 PM 15000
1.1.6 Прийняте рішення 0 PM
замовником про
доцільність
1.2 Планування 29 58000
1.2.1 Планування змісту 5 PM, BA 15000
1.2.2 Навчання команди 5 PM 7500
1.2.3 Планування бюджету 3 PM 4500
1.2.4 Планування ризиків 3 PM 4500
1.2.5 Планування часу 2 PM 3000
1.2.6 Планування інтеграцій 2 PM, BA, 10000
BE1
1.2.7 Планування людських 2 PM 3000
ресурсів
1.2.8 Планування якості 2 PM 3000
1.2.9 Планування комунікацій 3 PM 4500
1.2.10 Планування 2 PM 3000
стейкхолдерів
1.2.11 Затвердження планів 0 PM
замовником
1.3 Реалізація 99 97000
1.3.1 Заключення договорів з 10 PM 15000
постачальниками
1.3.2. Закупівля обладнання 10 РМ 15000
1.3.3 Проектування ІС 22
1.3.3.1 Розробка архітектури 8 BE1, 32000
системи FE1
1.3.3.2 Розробка use-case діаграм 3 BA, BE1, 16500
FE1
1.3.3.3 Проектування інтеграцій 3 BA, BE1 10500
1.3.3.4 Розробка проектної 4 BA, BE1,
документації FE1
1.3.3.5 Проектування БД 4 BE1 8000
1.3.4 Розробка системи 20 150000
1.3.4.1 Реалізація основного 20 BE1, 150000
функціоналу BE2,
FE1,
QA1
1.3.5 Інтеграції 12 21000
33
1.3.5.1 Завантаження цін з 3 BE1 6000
Google spreadsheet
1.3.5.2 Розробка API для 3 BE2 4500
відправки цін замовнику
1.3.5.3 Інтеграція зі стороннім 3 BE1 6000
ПЗ парсінгу
1.3.5.4 Інтеграція зі стороннім 3 BE2 4500
сервісом відправки листів.
1.3.6 Тестування системи 15 37500
1.3.6.1 Розробка тест планів та 5 QA1, 17500
тест кейсів BA
1.3.6.2 Регресійне тестування 10 QA1 20000
1.3.7 Розробка документації 8 28000
системи (інструкції
користувача)
1.3.7.1 Розробка документації 5 BE1, BA 17500
користувача.
1.3.7.2 Розробка документації 3 BE1, BA 10500
системного
администратора системи
1.3.8 ІС готова до 0 PM
впровадження
1.4 Завершення 38 109500
1.4.1 Впровадження системи 5 PM, DO, 19500
CS1
1.4.2 Здача продукта замовнику 5 PM,CS1 12500
1.4.3 Супроводження ІС 10 CS1 10000
1.4.4 Розформування команди 5 PM 7500
1.4.5 Архівація проекту 3 PM, BE1, 37500
FE1, QA1
1.4.6 Аналіз проекту 5 PM, BA 15000
1.4.7 Закриття (пролонгація) 5 PM 7500
зовнішніх договорів
1.4.8 Фініш проекту 0 PM
Отже, ієрархічна структура робіт є фундаментом для розробки плану проєкту
та одним із ключових методів, застосовуваних у сфері управління проєктами.
Справно створена ІСР визначається як важлива складова для ефективного планування
та успішного управління проєктами.
Організаційна структура проєкту
Команда проєкту – це група індивідів, які співпрацюють для досягнення
конкретних цілей проекту. Команда проекту зазвичай включає фахівців і спеціалістів
із різних областей, які мають різні навички та знання, необхідні для успішного
виконання проєкту. Керівник проєкту відповідає за управління та координацію
діяльності команди.
34
Основні завдання в організаційному аспекті при формуванні проєктної команди
включають створення умов для професійного та стимулюючого оточення, реалізацію
ефективного керівництва, забезпечення наявністю кваліфікованого технічного
персоналу, а також надання підтримки керівництву і забезпечення стабільного та
сприятливого робочого середовища.
Члени команди повинні бачити себе частиною команди проєкту та виробити
спільні цінності та норми, перш ніж вони зможуть працювати разом як команда. Для
побудови та розвитку команди можуть бути використані наступні шляхи:
– аналіз та підбір членів команди, використовуючи підходи оцінки
психологічної сумісності;
– організація семінарів, курсів.
Для оптимального функціонування колективу проєктний менеджер повинен:
– чітко пояснити цілі та завдання;
– розподілити функціональні обов’язки;
– визначити організаційну структуру команди;
– уникати конфліктів та долати перешкоди;
– забезпечити своєчасне планування і розподіл роботи.
Група фахівців, що входить у стартап, складається з професіоналів, які
володіють необхідними знаннями та навичками для успішного виконання завдань
проєкту. Схему оргструктури команди проєкту наведено на рисунку 3.2.
Менеджер
проекту
Бізнес- Головний DevOps Customer
аналітик програміст support
Middle backend Frontend QA інженер
програміст програміст
Рисунок 3.3 – Організаційна структура проєкту
Команда стартапу складається з 8 осіб: проєктного менеджера, бізнес-
аналітика, головного програміста, програміста, frontend програміст, тестувальник,
35
devops, спеціаліст підтримки користувачів. Проєктний менеджер є керівником
проєкту і йому підпорядковуються усі інші учасники команди.
На основі розроблених організаційної структури виконавців проєкту та
структури декомпозиції робіт розподіляється відповідальність учасників проєкту по
основним проєктним роботам. В результаті формується матриця відповідальності
(табл. 3.3), в якій визначаються ролі виконавців у різних роботах і фазах проєкту.
Таблиця 3.3 – Матриця відповідальності
Ресурси
PM BA BE1 BE2 FE1 QA1 DO CS1
З 1.1.1 R E
а
1.1.2
в R E E
д 1.1.3 R E E E
а
н 1.1.4 R E
н
я 1.1.5 R E
1.1.6 R E
1.2.1 R E E
1.2.2 R E E E E E E E E
1.2.3 R E
1.2.4 R E
1.2.5 R E
1.2.6 R E E E
1.2.7 R E
1.2.8 R E
1.2.9 R E
1.2.10 R E
1.2.11 R E
1.3.1 R E
1.3.2 R E
1.3.3.1 R E E
1.3.3.2 R E E E
36
Ресурси
PM BA BE1 BE2 FE1 QA1 DO CS1
1.3.3.3 R E E
1.3.3.4 R E E E
1.3.3.5 R E
1.3.4.1 R E E E E
1.3.5.1 R E
1.3.5.2 R E
1.3.5.3 R E
1.3.5.4 R E
1.3.6.1 E R E
1.3.6.2 R E
1.3.7.1 R E E
1.3.7.2 R E E
1.3.8 R E
1.4.1 R E E E
1.4.2 R E E
1.4.3 R E
1.4.4 R E
1.4.5 R E E E E E
1.4.6 R E E
1.4.7 R E
1.4.8 R E
R – Відповідальний (responsible)
E – Виконавець
3.2 Планування часу проєкту
Розробка календарного плану стартапу.
Наступним важливим етапом є планування часу, або календарне планування.
На цьому етапі складається та коригується розклад робіт, що взаємопов’язані між
собою. При розробці календарного плану важливо справлятися з умовами,
37
встановленими у проєкті, такими як: тривалість робіт, обмеження з ресурсами та
оптимальний розподіл цих ресурсів.
Основними цілями при плануванні календарного плану є:
− Забезпечення вчасного завершення проєкту.
− Забезпечення своєчасного надходження коштів.
− Контроль над виконанням робіт у рамках проєкту.
− Вчасне забезпечення ресурсами, визначення та коригування рівня їх
завантаження.
Ітеративний характер розробки календарного плану проєкту полягає в тому, що
в процесі виконання необхідно постійно повертатися до попередніх етапів для
уточнення та наближення їх до реальності. Це може включати як поступове
наближення попередніх варіантів до оптимальних значень, так і постійне уточнення
та вдосконалення етапів з метою найкращого досягнення цілей проєкту.
Даний календарний план проєкту є першим наближеним прогнозом щодо
реалізації проєкту. Протягом виконання проєкту цей прогноз коригується,
враховуючи як фактичні, так і заплановані показники ефективності. У найкращому
випадку стан проєкту наприкінці повинен відповідати його прогнозу.
Саме при календарному плануванні найкраще проявляють себе комп’ютерні
системи управління проєктами.
Починаючи розробку календарного плану проєкту, потрібно визначити повний
перелік робіт та пакетів робіт. Результати пакетів робіт мають бути унікальними і
відрізнятися від результатів пакетів робіт того ж рівня. Їх необхідно розбити до рівня
деталізації , який забезпечить успішне планування, координацію, а також контроль
робіт.
Календарне планування даного проєкту виконувалося в системі управління
проєктами Microsoft Project.
Project Plan 365 – одна з найбільш поширених систем управління проєктами під
MacOS. Дана програма поєднує в собі простоту використання, дружній інтерфейс і
необхідні інструменти для управління проєктами.
38
Під час розробки календарного планування проєкту була використана
розроблена СДР проєкту.
Для початку потрібно внести повний перелік робіт та пакетів робіт проєкту
(рис. 3.3).
Рисунок 3.3 – Вікно проєкту з введеним переліком робіт
Далі потрібно визначити тривалість робіт. Поле часової діаграми містить лінії
діаграми, які починаються та закінчуються одночасно.
Наступним кроком визначаємо тривалість виконання підлеглих робіт.
Найпростіше зробити це за допомогою календаря, який відкривається в комірці
стовпця Start напроти назви роботи. Перелік робіт після визначення їх тривалості
матиме такий вигляд (рис. 3.4).
39
Рисунок 3.4 – Вікно проєкту з визначеною тривалістю робіт
У завершальному етапі планування робіт проекту проводиться встановлення
взаємозв'язків між завданнями, оскільки тільки з урахуванням послідовності
виконання завдань система може сформувати графік проєкту та відобразити його на
діаграмі.
Для встановлення зв'язків між завданнями використовують два основних
інструменти: вказування попередника (роботу пов'язують із завданням-
попередником, вказуючи номер рядка цього завдання у стовпці "Predecessor"), або
налаштування цього зв'язку безпосередньо на графіку за допомогою піктограми
зв'язування.
При складанні календарного плану даного проєкту використовувався кожен з
цих інструментів.
Існують різні види взаємозв'язків між роботами, такі як початок до початку
(Start to Start), завершення до завершення (Finish to Finish), завершення до початку
40
(Finish to Start) та початок до завершення (Start to Finish) (SS, FF, FS, SF). За
замовчуванням завдання проекту пов'язані між собою зв'язком завершення до
початку, що означає їх послідовне виконання.
При встановленні зв'язків між роботами важливо враховувати обмеження часу,
які можуть бути виражені такими термінами:
– Так пізно, як це можливо - 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).
Необхідно також враховувати конкретні календарні дати в межах обмежень
часу. Для кожного типу обмеження, призначення яких стає зрозумілим після
визначення послідовності виконання робіт, логічним є введення лише пари часових
параметрів. Наприклад, для роботи з обмеженням типу MFO логічним є визначення
дати завершення і тривалості, причому дата старту обчислюється автоматично.
Спочатку при встановленні взаємозв'язків між завданнями всім роботам
проекту були надані обмеження типу ASAP, які потім було налаштовано для окремих
завдань на подальших етапах проекту.
Після виконання зв’язків робіт календарний план проєкту набув наступного
вигляду (рис. 3.5).
41
Рисунок 3.5 – Вікно проєкту з вказаними зв’язками між роботами
Також важливою є мережева схема проєкту. В Project Plan 365 вона будується
автоматично, на основі робіт та їх зв’язків (рис. 3.6).
Рисунок 3.6 – Мережева схема проєкту
3.3 Планування трудових ресурсів проєкту
Наступним не менш важливим етапом є планування трудових ресурсів.
Трудовими ресурсами даного проєкту є його безпосередні учасники, тобто команда
проєкту. Основними організаційними завданнями побудови команди проєкту є:
здійснення грамотного керівництва; створення професійно-стимулюючого оточення;
42
забезпечення підтримки керівництва і стабільно сприятливого навколишнього
середовища; забезпечення кваліфікованим технічним персоналом.
Учасники команди мають бачити себе частиною команди проекту та виробити
спільні цінності та норми, тільки тоді вони будуть в змозі працювати як команда.
Продовжуючи планування проєкту, необхідно вказати ресурси, які
використовуються для виконання кожної роботи, тобто призначити ресурси до робіт
проєкту.
Під ресурсами у проєкті розуміють: робочу силу, обладнання, мтеріали та
гроші, що потрібні для виконання робіт, і є передумовами для реалізації будь-якого
проєкту.
Важливим питанням є складання та оцінка потреб у ресурсах, умов їх
надходження та забезпечення та забезпечення їх повного та ефективного
використання.
Планування ресурсів починається з складання переліку людей і обладнання,
необхідних для виконання проєктних робіт.
Зробити це можна за двома способами:
− визначати ресурси для кожного завдання, тим самим створюючи список
призначених для них ресурсів;
− створити список ресурсів і потім використовувати його для назначення
конкретних ресурсів для виконання робіт.
Всі ресурси даного проєкту відомі, тож легше використовувати другий спосіб.
Скориставшись меню View | Resource Sheet, на екрані з'явиться таблиця
ресурсів. У даній таблиці будуть доступні характеристики:
– назва ресурсу - Resource Name;
– тип (працівник, матеріал) - Type;
– позначення матеріалу - Material Label;
– абревіатура працівника - Initials;
– група - Group;
– максимальна "задіяність" - Max. Units;
– звичайний тариф оплати (протягом робочого часу) - Std. Rate;
43
– тариф оплати за роботу в неробочий час - Ovt. Rate;
– одноразові витрати - Cost/Use;
– форма оплати (аванс, погодинно, по факту) - Accrue At;
– базовий календар ресурсу - Base Calendar;
– код ресурсу - Code.
Якщо ресурс повністю використовується для виконання робіт у проєкті, у
комірці Units потрібно поставити значення (100%), якщо ресурс використовується
частково, то необхідно вказати відсоток його використанняу цьому проєкті.
На рис. 3.8 зображена заповнена таблиця ресурсів.
Рисунок 3.8 – Заповнена таблиця ресурсів проєкту
3.4 Призначення ресурсів до робіт проєкту
Після того, як ресурси визначені, можна призначати їх до робіт. Для цього
необхідно двічі клацнути лівою кнопкою миші, навівши курсор на комірку з назвою
роботи. Після чого з’явиться діалогове вікно Task Information. У ньому знаходимо
вкладку Recource.
У цьому вікні можна вибрати з переліку доступні ресурси та призначити їх на
виконання цієї роботи (рис. 3.9).
44
Рисунок 3.9 – Перелік доступних ресурсів проєкту для призначення
Альтернативно можна призначити ресурс до роботи, натиснувши лівою
кнопкою миші на комірку поруч з датою закінчення роботи в стовпці Resource Names
(рис. 3.10).
Рисунок 3.10 – Присвоєння ресурсу до роботи
Після присвоєння всіх ресурсів до необхідних робіт можна побачити, що їх
назви відображаються на діаграмі Ганта, поруч з лініями робіт (рис. 3.11).
45
Рисунок 3.11 – Відображення призначених роботам ресурсів на часовій
діаграмі
Виявлення та вирішення конфліктів ресурсів.
Після того, як ресурси призначені до робіт, можуть з’явитися перенавантаження
тих чи інших ресурсів.
Наявність перенавантажень можна перевірити в листі ресурсів (Resource Sheet),
перенавантажені ресурси будуть позначені червоним (рис. 3.12).
Рисунок 3.12 – Маркування перевантажених ресурсів
Далі необхідно використати меню View, Resource Graph. У вікні, що
відкриється, зображено графік перенавантаження ресурсів. На рис. 3.13 зображено
графік перенавантаження проєктного менеджера, на рис. 3.14 – перенаванттаження
маркетолога.
46
Рисунок 3.13 – Графік перевантажень ресурсу «Проєктний менеджер»
Рисунок 3.14 – Графік перенавантажень ресурсу «Тестувальник»
У даному проєкті виявились перенавантаженими кілька ресурсів, а саме:
проєктний менеджер та тестувальник (рис. 3.12). Це означає, що на виконання роботи
на яку призначений ресурс, йому знадобиться більше часу ніж він має.
Ця проблема може виникнути за кількох причин:
47
– самою розповсюдженою причиною є призначення ресурсу до паралельних
завдань, тобто тих, що виконуються одночасно;
– іншою причиною може бути збільшення обсягу робіт завдання, через яке
відбувається перевищення допустимого часу виконання та як наслідок,
перенавантаження ресурсу.
Якщо такі конфлікти наявні у проєкті, то їх потрібно виправляти за допомогою
методів «зглажування» або «калібрування».
Метод «калібрування» полягає в тому, що явне навантаження розподіляється
рівномірно протягом усього терміну виконання, що дає зниження пікового
навантаження та дотримання термінів виконання робіт, проте використовуючи цей
метод ресурси працюють понаднормово, що в свою чергу збільшує витрати на проєкт.
Застосовуючи ж метод «зглажування», рівень задіяних ресурсів зводиться до
номінальних 100%%, однак збільшуються терміни виконання проєкту.
Для того, щоб збалансувати дане перенавантаження, можна використати один
чи декілька методів:
– зменшити навантаження на перенавантажені ресурси шляхом скорочення
частини робіт або доручення їх іншим учасникам;
– позбавитися перетинів у роботах, додавши перерви в розкладі завдань або
призначень, чи змінити дати початку та закінчення;
– позначити роботу, яка виконується ресурсом, як понаднормову.
Дані вирівнювання ресурсів можна виконувати, як автоматичними засобами,
так і вручну. Проте, як правило використовують обидва варіанти, тому, що
автоматичне вирівнювання використовує лише другий з наведених вище способів.
Перш за все потрібно запам’ятати тривалість проєкту до змін, аби розуміти, як
коригування змінить тривалість проєкту.
Рисунок 3.15 – Тривалість виконання проєкту до зглажування ресурсів
48
Більшою мірою у проєкті було використано метод «згалажування». Тобто,
навантаження на ресурс зводилося до номінальних 100% шляхом рівномірного
розподілу відсотків навантаження ресурсу між паралельними роботами. Що в свою
чергу призвело до збільшення тривалості проєкту, проте паралельно відбулося
незначне зменшення витрат на проєкт (рис. 3.16).
Рисунок 3.16 – Тривалість виконання проєкту після зглажування ресурсів
Оскільки перенавантаження ресурсів усунуто, то лист ресурсів виглядає
наступним чином:
Рисунок 3.17 – Лист ресурсів із вирішеними конфліктами ресурсів
Як бачимо, після зглажування тривалість проєкту складає 177 днів, замість 171
днів до зглажування. Тобто, тривалість проєкту збільшилася на 6 днів.
3.5 Планування якості проєкту
У проекті використовується така концепція формування якості:
– формування корпоративних рекомендацій з якості (на основі стандартів серії
ISO 9001). Стандарти визначають основні методи забезпечення якості та
структуру документів системи забезпечення якості;
– усі роботи в проєкті мають виконуватись з урахуванням попередньо
узгоджених і затверджених рекомендацій з якості;
– саме впровадження технології управління проектами є складовою частиною
системи управління якістю;
– підвищення кваліфікації членів команди;
– використання обладнання та програмного забезпечення що пройшли
сертифікацію та ліцензування;
49
– відповідальність виконавців за за якість своєї праці;
– контроль якості на всіх етапах проекту.
Визначимо заходи щодо досягнення якості на кожній з фаз проекту:
– Фаза ініціалізації.
Комплексний аналіз ринку та об'єктивне визначення потреб та очікувань
потенційних клієнтів, повнота статуту проекту та техніко-економічного
обґрунтування.
– Фаза планування.
Якість та повнота створених основних нормативних документів та інструкцій,
проектних структур, оцінки ризиків тощо. Розробка процедур командоутворення та
рекомендацій щодо налагодження ефективних комунікацій проекту.
– Фаза реалізації.
Відповідність результатів робіт вимогам корпоративної настанови з якості (ISO
9001), та загальновизнаним стандартам якості. Забезпечення високоякісного
технічного тестування продукту для максимального виявлення помилок і недоліків
до завершення етапу впровадження. Проведення користувацького тестування.
– Фаза завершення.
Складання звітів про результати проекту. Повнота та якість архіву проекту.
Оцінка фактичних термінів виконання проекту, фактичного бюджету і якості
продукту проекту.
Ключові показники якості наведені у таблиці 3.3.
Таблиця 3.3 – Показники якості
Показники Цільове Допустиме Опис Відповідаль Контролюю Робота або
значення значення показників ні за якість чий фаза проекту
якості
Підтримка Мультипла роботу у Версії Програміст Менеджер Фаза
операційних тформен- сучасних браузерів у проекту планування,
систем ність браузерах яких має Фаза
запускатись реалізації
система
Час До 5х До 10ти Час за який має Програміст Менеджер Фаза
завантаження секунд секунд бути проекту планування,
системи завантажена Фаза
система у реалізації
браузері
50
Час До 60ти До 120ти Час за який має Програміст Менеджер Фаза
формування секунд секунд бути проекту планування,
звіту оновлений/відо Фаза
бражений реалізації
аналітичний
звіт у системі
Швидкість До 2хи До 5ти Час за який Програміст Менеджер Фаза
збору однієї секунд секунд система має проекту планування,
товарної завантажити Фаза
позиції ціну однієї реалізації
позиції
інтернет
магазину
Час Виконання Допустиме Виконання Менеджер Замовник На всіх фазах
виконання в термін відхилення робіт в термін проекту
поставлених не більше 2х впливає на
задач тижнів бюджет
зазначеного проекту
терміну
Надійність 100% 100% Відповідність Програміст, Менеджер На фазі
виконаних кінцевих тестуваль- проекту реалізації
робіт результатів ник
поставленим
цілям,
перевірка
кінцевого
результату
згідно до
погоджених
специфікацій
та дизайну
додатку для
кожної
операційної
системи на всіх
етапах робіт
3.6 Управління ризиками проєкту
Оскільки планування та втілення проєкту реалізуються в умовах
невизначеності, це призводить до змін у внутрішньому та зовнішньому середовищі.
У проектному контексті невизначеність вказує на відсутність повної та достовірної
інформації про умови реалізації проекту. Кожен проєкт передбачає виконання нових
завдань в нових умовах, з використанням нових ресурсів та для досягнення нового
результату. Зазвичай складні проєкти на початкових етапах свого розвитку стають ще
більш невизначеними. Новизна або інноваційність проєкту призводять до виникнення
51
ризиків в широкому розумінні. Ризики можна описати як невизначеності, пов'язані із
ситуаціями, що виникають під час проекту та впливають на тривалість, витрати та
якість проєкту.
Управління ризиками означає взаємодію з подіями та змінами ризиків у процесі
виконання проєкту.
Основна стратегія управління ризиками полягає у мінімізації. Управління
ризиками включає в себе планування ризиків, впровадження заходів реагування,
контроль, роботу з новими або залишковими ризиками.
Планування управління ризиками – це процес вибору підходу до планування та
управління ризиками для конкретного проєкту. Цей процес включає в себе прийняття
рішень щодо обмеження реакції на ризики, організації та кадрового забезпечення
процедур управління ризиками проєкту, вибору джерел інформації та періодів для
виявлення ризиків та їх фінансового забезпечення. На даному етапі створюється
система управління ризиками для конкретного проєкту. Планування управління
ризиками повинно бути адекватним за типом та рівнем ризиків, а також важливістю
проєкту для організації.
На рисунку 3.20 зображено загальний проєкт управління ризиками.
Планування
Ідентифіка- Якісний Кількісний Плануван Моніто-
управління
ція ризиків аналіз аналіз ризиків ня ринг
ризиками
контроль
Рисунок 3.20 – Схема процесу управління ризиками
Для проєкту застосовуються такі процеси управління ризиками:
– планування управління ризиками – процес, під час якого відбувається вибір
підходу до планування і управління ризиками для конкретного проєкту;
– ідентифікація ризиків проєкту – це процес, на меті якого є ідентифікація та
документування потенційних небезпек, які можуть впливати на проєкт. Це
включає в себе опис і характеристики ризиків, їхню категорію, умови
виникнення та методи;
52
– якісна і кількісна оцінка ризиків і умов їх виникнення. Дана оцінка має на
меті оцінити ймовірності їх виникнення і вплив на розвиток проєкту. На
даному етапі проводиться якісна та кількісна оцінка ступеня значущості
ризиків, і визначаються пріоритети для різних категорій ризиків;
– планування реагування на виявлені значимі ризики. У результаті
визначаються процедури і методи щодо ослаблення негативного впливу
ризикових подій;
– моніторинг і контроль ризиків. Під час виконання даного процесу
відбувається відстеження поточних, визначення вже існуючих і нових
ризиків, виконання плану управління ризиками проекту й оцінка
ефективності дій щодо управління ними.
Для того, щоб оцінити вплив ризикових подій на процес реалізації проєкту,
було використано наступну шкалу:
– «0» - ризик не має ніякого впливу;
– «0.05» - ризик має мінімальний вплив;
– «0.1» - ризик має невеликий вплив;
– «0.2» - ризик має помірний вплив;
– «0.4» - ризик має великий вплив;
– «0.8» - ризик має надмірно великий вплив.
Тепер розподілимо ймовірності настання ризикової події на такі діапазони (від
0 до 1, де 0 – подія неможлива, 1 – подія, що точно відбудеться):
– 0,0-0,2 – дуже низька ймовірність;
– 0,2-0,4 – низька ймовірність;
– 0,4-0,6 – середня ймовірність;
– 0,6-0,8 – велика ймовірність;
– 0,8-1 – дуже велика ймовірність.
Після цього визначаємо ймовірність настання того чи іншого ризику та його
вплив на проєкт (табл. 3.4).
53
Таблиця 3.4 – Ймовірність настання та вплив на проєкт ризиків
№ Найменування ризику Імовірність Вплив на
виникнення проєкт
(0-1) (0-1)
1 Зміна законодавства у антимонопольній 0,2 0,2
політиці
2 Поломка обладнання 0,1 0,1
3 Недостатня компетентність 0,1 0,3
4 Втрата інформації 0,05 0,2
5 Втрата ключових виконавців 0,1 0,3
6 Хвороби 0,6 0,2
7 Порушення контрактів 0,1 0,2
8 Форс мажор 0,1 0,6
9 Ріст інфляції 0,5 0,5
10 Нестабільне фінансування 0,4 0,6
11 Управлінський ризик 0,2 0,8
Далі, для комплексної оцінки можливих наслідків впливу ризикової події на
проєкт формується матриця аналізу ризиків (табл. 3.5).
Таблиця 3.5 – Аналіз ризиків
Імовірність
0.8 – 1.0
0.6 – 0.8 6
0.4 – 0.6 9 10
0.2 – 0.4 1 11
0.0 – 0.2 2 4,7 3,5 8
54
0.05 0.1 0.2 0.4 0.8
Вплив
З табл. 3.5 видно, що найвпливовішим для проєкту є фінансовий ризик, середній
вплив мають: ризик персоналу, управлінський ризик, форс-мажорний ризик.
Завершальним кроком в управлінні ризиками є створення варіантів реагувань
на ризики, що мають значний вплив на проєкт (табл. 3.6).
Таблиця 3.6 – Заходи щодо запобігання ризикам проєкту
№ Найменування Попередження ризику Усунення наслідків від ризику
ризику Дії Відпові- Дата Дії Відповіда-
дальний льний
1 Зміна моніторинг РМ Фаза реалізація PM
законодавства у антимонопольного планування опционального
антимонопольній законодавства увімкнення
політиці сповіщень про
демпінг
2 Поломка заключення РМ Фаза Заміна обладнання Devops
обладнання договорів з реалізації по гарантії
перевіреними
постачальниками
закуповувати
обладнання з
найбільшим терміном
гарантійного
обслуговування
закуповування
обладнання брендів,
сервісні центри яких
є у місті.
3 Недостатня співбесіда учасників РМ Фаза ідеї Заміна учасника РМ
компетентність потенційних команди
учасників команди
4 Втрата резервне копіювання Devops Фаза Розгортання Devops
інформації файлів проекту реалізації проекту з резервних
файлів
5 Втрата ключових Під час формування РМ Фаза ідеї Пошук іншого РМ
виконавців команди чітко виконавці
розуміти цілі
кожного учасника
команди
6 Хвороби Заохочення членів РМ На протязі Перепланування РМ
команди до занять проекту проекту по строках
спортом, активного
відпочинку.
7 Порушення Чітке формулювання РМ Фаза Звернення до РМ
контрактів договорів з реалізації судових органів за
перевіркою у юристів пунктом
перед підписанням
55
недотримання
вимог договору.
РМ
Переукладання
договору з іншим
постачальником
8 Форс мажор Прописування у РМ Фаза Перепланування РМ
договорах пункту про реалізації проекту
форс мажор призупинення Замовник
проекту
9 Ріст інфляції - постійний PM Раз на день - Перепланування PM
моніторинг бюджету проєкту
економічної ситуації Фаза - Призупинити Замовник
- резервування PM планування проєкт
коштів в бюджеті
проєкту
10 Нестабільне - резервування PM Фаза - фінансування за Замовник
фінансування коштів в бюджеті планування рахунок інших
проєкту проєктів
- Використання PM
резерву
- Призупинити Замовник
проєкт
11 Управлінський - навчання PM Замовник - запрошення Замовник
ризик - сертифікація PM консультанта
- заміна PM Замовник
3.7 Планування бюджету проєкту
Планування бюджету проєкту – це визначення вартості робіт, що виконуються
в рамках проєкту, і процес формування бюджету проєкту на основі розподілу витрат
за видами робіт, часом їх виконання, статтями витрат, центрами витрат та іншими
критеріями.
Бюджетування представляє собою процес планування вартості або розподілу
витрат. Це означає, що бюджет повинен надавати чітке уявлення про те, коли, скільки
і на що буде витрачено гроші. У цьому контексті можна використовувати різні методи
представлення витрат, головне вимога – вони повинні задовольняти конкретні
потреби стейкхолдерів, відповідати стандартам та враховувати питання, що цікавлять
учасників проекту.
Бюджет може бути представлений у наступних варіантах:
– кругові діаграми структури витрат;
– календарні плани-графіки витрат;
– стовпчасті діаграми витрат;
56
– матриці розподілу витрат;
– лінійні діаграми розподілених у часі кумулятивних витрат;
– стовпчасті діаграми кумулятивних (наростаючим підсумком) витрат.
Оскільки в проєкті немає закупівель, його вартість обумовлена лише витратами
на заробітню платню команді проєкту. Для її розрахунку необхідно використання
ресурсів за годину множити на тривалість робіт (рис. 3.21).
Рисунок 3.21 – Ставка кожного виконавця проєкту
В Project Plan 365 витрати обраховуються автоматично, як тільки до робіт
будуть присвоєні доступні ресурси. Для зручності на діаграму Ганта можна вивести
витрати проєкту, додавши відповідний стовпчик (рис. 3.22).
Рисунок 3.22 – Діаграма Ганта з витратами проєкту
57
Ще в Project Plan 365 існує безліч шаблонних звітів, в тому числі і фінансових,
за допомогою яких можна зробити різні звіти, що будуть корисні проєктному
менеджеру на етапі моніторингу та контролю.
3.8 Управління комунікаціями в проєкті
Управління комунікаціями в проєкті слід розглядати як важливий етап,
необхідний для ефективного управління проєктами. Відсутність зв'язку в проєкті
може призвести до його припинення: керівники не мають інформації про виконані
роботи, виконавці не отримують зворотного зв'язку щодо відповідності їхніх
результатів проєктним цілям і планам, а менеджер проєкту втрачає можливість
координувати виконання завдань. Це може призвести до зупинки будь-якої діяльності
в рамках проєкту, поки не буде відновлено ефективний зв'язок.
Комунікацію часто порівнюють із важливим фактором, що сприяє єднанню
різноманітних процесів, необхідних для успішного розвитку проектів. Зазвичай
менеджер проєкту віддає близько 80% свого робочого часу для взаємодії та обміну
інформацією. Таким чином, ефективне керівництво проєктами надто залежить від
якості комунікаційних процесів, їх аналізу, а також вчасного виявлення та розв'язання
потенційних проблем.
У межах проєкту комунікація є процесом, під час якого учасники передають
один одному інформацію, пов'язану з досягненням цілей проєкту. Під час взаємодії
учасники обмінюються інформацією з метою забезпечення чіткого розуміння
відправленого повідомлення зі сторони отримувача. Комунікаційний процес завжди
включає щонайменше дві сторони – тих, хто передає інформацію, і тих, хто отримує
її. Ці сторони можуть бути окремими особами, групами людей (наприклад, командою
проєкту) або навіть цілими організаціями.
Аби проєкт нормально функціонував, учасникам проєкту необхідно ретельно
координувати свої дії та зусилля.
Для проєкту було розроблено наступний план комунікацій (табл. 3.7).
58
Таблиця 3.7 – План комунікацій проєкту
№ Вид комунікації Регулярність Хто відправляє Хто отримує
комунікації інформацію інформацію
1 Тижневий звіт по 1 раз на тиждень (кожну Виконавець Той, хто контролює
задачах п’ятницю)
2 Місячний звіт по 1 раз на місяць Виконавець Той, хто контролює
задачах (останній день місяця)
3 Звіт за місяць по 1 раз на місяць (перший Менеджер проекту Замовник
проекту день місяця)
4 Щотижнева 1 раз на тиждень (кожна Виконавець Менеджер проекту
нарада п’ятниця)
5 Усна комунікація Кожний день Будь-хто з команди Будь-хто з команди
6 Підсумковий звіт При завершенні Менеджер проекту Замовник
по всьому проекту проекту
Висновки до розділу 3
Планування проєкту становить ключову та відповідальну складову процесу.
На етапі планування для даного проєкту ретельно розроблено концепцію
проєкту, включаючи повний перелік завдань, необхідних для успішного завершення
проєкту.
Наступним етапом є розробка календарного плану проєкту, де визначено
тривалість кожного завдання та загальний час виконання проєкту. Крім того, на цьому
етапі встановлюються взаємозв'язки між усіма етапами та завданнями проєкту.
Після спланованого календарного планування відбувається планування
ресурсів. На цьому етапі для проєкту були внесені необхідні для виконання робіт
трудові ресурси, що згодом були призначені для виконання цих самих робіт.
Далі відбувається планування якості проєкту. В цьому етапі були сформовані
та прописані стандарти якості, яким повинен відповідати проєкт.
На етапі управління ризиками визначено, які види ризиків для проєкту більш
небезпечні та розроблено відповідні кроки, щоб запобігти появі даних ризиків та
варіанти вирішення ризикової ситуації, в разі її виникнення.
На етапі планування бюджету була закладена вартість проєкту, його обмеження
та допущення.
59
Останнім етапом фази планування є управління комунікаціями проєкту. В
даному етапі розроблено план комунікацій для проєкту, за допомогою якого учасники
зможуть комфортно обмінюватися необхідною інформацією.
Отже, планування проєкту є важливим, оскільки охоплює всі фундаментальні
етапи створення проєкту. Розробивши даний розділ, стало зрозуміло, що для
успішного завершення проєкту менеджер повинен вкласти в планування всі свої
можливості та знання.
60
4 МОДЕЛЮВАННЯ ВИКОНАННЯ ПРОЄКТУ
4.1 Механізм контролю робіт проєкту
Важливою складовою системи контролю є нагляд за проєктом. Цей механізм
призначений для постійного відстеження найсуттєвіших результатів реалізації
проєкту з метою вчасного виявлення будь-яких відхилень від запланованого графіка
та бюджету.
Моніторинг дозволяє порівнювати плановані та фактичні показники, що
відносяться до планування та реалізації проєкту. Це здійснюється шляхом оцінки
різниці між запланованими та реальними показниками проєкту. Моніторинг може
бути проведений як внутрішньою командою проєкту, так і залученими зовнішніми
організаціями.
Основні завдання моніторингу включають:
– відображення здійснених операцій, витрат і використаних ресурсів;
– своєчасне виявлення проблем;
– поліпшення робіт в рамках проєкту;
– розпізнавання можливих варіантів подальшого поліпшення технологій;
– оцінка якості управління проєктом;
– прискорення появи необхідних результатів проєкту;
– економія витрат;
– забезпечення стейкхолдерів інформацією;
– визначення помилок і аналіз їх причин.
В даному проєкті моніторинг відбувається наступним чином:
– Виконавець має надсилати звіт особі, що його контролює кожної п’ятниці;
– Виконавець має надсилати місячний звіт по задачам особі, що контролює
його роботу першого числа кожного місяця;
– Кожної п’ятниці проводиться нарада, де виконавці відзвітовуються
проєктному менеджеру;
– Усна комунікація між командою проєкту може відбуватися у будь-який час;
61
– Менеджер проєкту надає замовнику підсумковий звіт по всьому проєкту
після завершення проєкту.
Звіти потрібні для ведення контролю за ходом виконання робіт, аналізу
виконаної роботи та постановки завдання на наступний тиждень.
4.2 Опис засобів програмної реалізації додатку
Мова програмування
BAS – це популярна платформа для розробки облікових систем. Платформа має
свою вбудовану мову програмування тим самим надаючи можливість розробляти свої
рішення під платформу. BAS найчастіше використовується для розробки систем
обліку оперативного та бухгалтерського обліку..
Також платформа дає можливість працювати з конфігурацією через web-
сервіси та http-сервіси. Це дає можливість робити інтеграцію BAS з іншими
програмними рішеннями які використовуються у ТОВ “Прайскоп”.
BAS платформа має свою вбудовану мову програмування. Для доступу до
даних може використовуватись вбудована мова запитів яка має сиснтаксис схожий на
SQL.
Зараз доступні різні конфігурації під дану платформу, але ТОВ “Прайскоп”
використовує свою, розроблену під потреби розвʼязку задач моніторингу цін в
інтернет магазинах.
Переваги BAS.
Використання відкритої конфігурації полягає у використанні відкритого
програмного коду для можливості адаптації будь-якої з компонентів BAS під
індивідуальні потреби конкретного підприємства. Фахівець, який має відповідні
навички, може налаштувати програму точно під специфічні вимоги конкретного
бізнесу.
Персональна проєктна розробка дозволяє кожному користувачеві створювати
та налаштовувати проєкти, враховуючи специфіку бізнес-процесів конкретної
організації. Технологічна платформа виступає єдиною для всіх програмних
62
продуктів, забезпечуючи можливість швидкої стандартизації прикладних рішень
згідно з сучасними вимогами та масштабування проєктів за потребою.
Незважаючи на широкий функціонал, BAS не вважається специфічним
програмним забезпеченням, що робить його доступним для вивчення практично для
будь-якого співробітника. Під час проходження курсів та отримання технічної
підтримки, ймовірність людських помилок зводиться до мінімуму.
Універсальність продукту проявляється в його придатності та можливості
адаптації для різних галузей бізнесу.
Недоліки платформи BAS.
Оплата за індивідуальну адаптацію базового продукту передбачає залучення
зовнішнього фахівця для створення конфігурацій, який в подальшому відповідатиме
за підтримку, обслуговування та удосконалення цієї компоненти.
Основні конфігурації, такі як Управління торгівлею, Підприємство, та
Бухгалтерія, не можуть бути використані без додаткової адаптації для сфери послуг,
спеціальних об'єктів або роздрібної торгівлі. Для використання їх у цих галузях
необхідно провести додаткові модифікації спеціалістами.
Вартість оновлень продуктів є платною, і хоча це, можливо, не є повністю
недоліком, але впливає на користувачів. Покупка кожної нової версії обґрунтована
необхідністю забезпечення фінансування для підтримки програмного забезпечення та
розробки нових рішень.
4.3 Опис функцій та можливостей додатку
Для більшого розуміння результату проєкту наведемо концептуальний опис
створюваного продукту та опис його основних функцій.
Після проведення онбординга клієнта клієнт зʼявляється у системі. У системи
можуть бути різні користувачі: адміністратор збору даних, клієнт.
Приклад використання системи адміністратором збору даних
Адміністратор збору даних може спостерігати інтенсивність збору, план-
фактний аналіз кількості зібраних цін.
63
Рисунок 4.1 – dashboard представлення інформації для фахівця зі збору даних
Адміністратор може змінювати розклад формування звітів, ініціювати
позачерговий збір, відміняти вже запущені збори.
Також адміністратор може формувати поточну діаграму збору даних, яка надає
йому більше аналітичної інформації про стан збирання інформації для звітів.
Рисунок 4.2 – Діаграма стану збору даних
Також адміністратор може спостерігати за рівномірністю навантаження
віртуальних машин збору. Він може виконувати коригування розподілу завдань на ці
віртуальні машини.
64
Рисунок 4.3 – Графік інтенсивності надходження даних по цінам
Приклад використання аналітичних звітів клієнтом
Для клієнта система надає повний спектр аналітичних звітів, за допомогою яких
клієнт може відповісти на питання:
– скільки позицій було проаналізовано;
– скільки магазинів прийняло участь у аналізі;
– який період збору даних;
– скільки позицій в демпінгу;
– яка кількість демпінгу у магазині;
– відносне відхилення цін магазину і прайса клієнта;
– яка рекомендована ціна згідно попередньо встановленого алгоритму;
– яка історія зміни цін на товарну позицію.
65
Рисунок 4.3 – Приклад аналітичного звіту
Висновки до розділу 4
У даному розділі детально описані можливості та функції продукту, що
розробляється в кваліфікаційній роботі магістра. Описано перелік ролей у системі.
Приведені приклади роботи різних ролей з системою, перелік найбільш важливих
функцій при роботі.
Створено та запущено систему в роботу. Запущений боардінг клієнтів. Система
відвантажує звіти комерційним клієнтам.
Також у даному розділі вибрано та зроблено короткий опис програмних засобів,
які знадобляться для практичної реалізації додатку.
66
ВИСНОВКИ
Мета кваліфікаційної роботи магістра досягнута.
Задачі, що вирішено в роботі:
– проведено дослідження ринку систем моніторингу цін;
– досліджено особливості методологій управління проєктами в ІТ галузі;
– розроблено компоненти управління проєктом розробки інформаційної
системи моніторингу цін;
– виявлено та оцінено можливості подальшого удосконалення системи з
метою розширення її функціональності.
У роботі представлено управління проєктом з розробки системи моніторингу
цін у Інтернет магазинах. Все більше бізнесів мають необхідність отримувати
аналітичну інформацію про ціни конкурентів. Для правильної політики
ціноутворення дана інформація має важливе значення і бізнеси шукають рішення цієї
проблеми. Створений в роботі проєкт з розробки системи моніторингу цін, є саме
таким рішенням. Ця система може підійти як дистрибʼюторам так самим інтернет
магазинам. Система поєднує у собі безліч функцій, які описані в даній роботі.
Кожен розділ кваліфікаційної роботи є важливою частиною розробки проєкту.
Так, у першому розділі обґрунтовується проблема, яку вирішуватиме система.
На основі розуміння проблеми, що вирішує створюваний додаток,
розробляється концепція проєкту, якій присвячений другий розділ, де також
формується важлива частина проєкту, перше розуміння того, як виглядатиме процес
реалізації додатку.
У третьому розділі відбувається планування розробки за допомогою Project Plan
365. Даний розділ є, напевно, що найважливішим, оскільки містить в собі точне
визначення тривалості, вартості проєкту. В ньому відбувається планування таких
важливих чинників, як ризики, комунікації та бюджет проєкту.
У завершальному розділі розглянуто процес моніторингу та контролю в рамках
проєкту, який має важливе значення для успішної його реалізації. Тут також обрані
програмні інструменти для здійснення цих процесів. В додаток до цього в четвертому
67
розділі надано детальний опис можливостей та функцій, що має кінцевий продукт
проєкту, та розроблено систему моніторингу, включаючи найбільш важливі функції.
У майбутньому планується виконати інші функції системи моніторингу цін. З
метою залучення більшої кількості клієнтів на комерційній основі та отримання
прибутку.
Отже, кожний етап впровадження проєкту має свою важливість. Проєкт
вважатиметься успішним, якщо всі фази, від початкового етапу ініціації до
завершення, ретельно та систематично розроблені, і всі учасники мають достатній
рівень кваліфікації для досягнення поставлених цілей.
68
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ
1. Фітнес-додаток «Centr». URL: https://centr.com/
2. Фітнес-додаток «Nike Training Club». URL: https://www.nike.com/ntc-app
3. Фітнес-додаток «HIIT|Down Dog». URL: https://hiit.downdogapp.com/web
4. СППР Decisioner. URL: http://decision.tg.ck.ua/experiment.php?id=2
5. СКМ Matlab. URL: https://www.mathworks.com/products/matlab.html
6. Поняття життєвого циклу проєкту. URL: https://buklib.net/books/34069/
7. Фази життєвого циклу проєкту. URL: https://buklib.net/books/34070/
8. Структура декомпозиції робіт проєкту. URL:
https://studentbooks.com.ua/content/view/1313/42/1/3/
9. Планування якості проєкту. URL: https://studfile.net/preview/5118274/page:32/
10. Управління ризиками проєкту. URL:
https://pidru4niki.com/87734/menedzhment/upravlinnya_rizikami_proektu
11. Філдінг Пол Дж. Як керувати проєктами / пер. з англ. О. Якименко. Харків :
Вид-во «Ранок» : Фабула, 2020. 240 с.
12. Морозов В.В., Кузнецов Є.Д., Данченко О.Б. та інші. Управління бізнесом,
проєктами, програмами та портфелями проєктів: колективна монографія.
Університет економіки та права "КРОК", 2012. Т.3, 304 с.
13. Данченко О.Б., Дзюба Т.В. Маркетингові дослідження у проєктах: навчальний
посібник. Київ: ВНЗ «Університет економіки та права «КРОК», 2021. 224 с.
14. Управління ІТ-проектами в Microsoft Project: Комп’ютерний практикум
[Електронний ресурс]: навчальний посібник для студентів спец-і 122
“Комп’ютерні науки” для всіх спеціалізацій / Л.М. Добровська, О.В.
Аверьянова; КПІ ім. Ігоря Сікорського. Київ: КПІ ім. Ігоря Сікорського, 2020.
152 с.
15. Ефективне управління економікою: інформаційні технології, маркетинг, бізнес
[текст]: матеріали міжнародної науково-практичної конференції, 19 квітня 2018
р. // Черкаський державний технологічний університет. Черкаси: ФОП
Гордієнко, 2018. 108 с.
69
ДОДАТОК А
Затверджую
Зав. кафедри КНСА,
______________ Юрій ТРИУС
«____»____________2024 р.
УПРАВЛІННЯ ПРОЄКТОМ РОЗРОБКИ ІНФОРМАЦІЙНОЇ СИСТЕМИ
МОНІТОРИНГУ ЦІН У ІНТЕРНЕТ МАГАЗИНАХ
Специфікація
482. ЧДТУ. 42234-01
Листів 2
Розробник ____________________ Данилюк А. А.
Керівник ____________________ Андрієнко В.О.
Черкаси – 2024
70
482. ЧДТУ. 42234-01
Позначення Найменування Примітка
Документація
482. ЧДТУ. 42234-01 12 01 Текст програми
завантаження цін на
платформі BAS
482. ЧДТУ. 42234-01 12 02 Текст програм повний
перелік робіт з
діаграмою Ганта в Project
Plan 365
71
ДОДАТОК Б
Затверджую
Зав. кафедри КНСА,
______________ Юрій ТРИУС
«____»____________2024 р.
УПРАВЛІННЯ ПРОЄКТОМ РОЗРОБКИ ІНФОРМАЦІЙНОЇ СИСТЕМИ
МОНІТОРИНГУ ЦІН У ІНТЕРНЕТ МАГАЗИНАХ
Текст програми завантаження цін на платформі BAS
482. ЧДТУ. 42234-01 12 01
Листів 9
Розробник ____________________ Данилюк А.А.
Черкаси – 2024
72
Текст програми завантаження цін на платформі BAS
&НаСервере
Процедура ПолучитьТаблицуЦенИзИсточника(Источник) Экспорт
APDEX_ОценкаПроизводительностиКлиентСервер.НачатьЗамерВремени("ПолучитьТаблицуЦенИзИсточника")
;
УстановитьПривилегированныйРежим(Истина);
МассивСвойствТП = Новый Массив;
Запрос = Новый Запрос;
Запрос.Текст = "ВЫБРАТЬ
| МАКСИМУМ(Прайскоп_ЗагруженныеДанныеПоЦенам.ИД) КАК ИД
|ИЗ
| РегистрСведений.Прайскоп_ЗагруженныеДанныеПоЦенам КАК
Прайскоп_ЗагруженныеДанныеПоЦенам";
Выборка = Запрос.Выполнить().Выбрать();
Если Выборка.Следующий() Тогда
ИД = ?(Выборка.ИД=Null,0,Выборка.ИД);
Иначе
ИД = 0;
КонецЕсли;
ИД = ИД - 5;
ТаблицаРезультат = Новый ТаблицаЗначений;
СоответствиеКолонок = Новый Соответствие;
СоответствиеКолонок.Вставить("idgoods","ИД");
СоответствиеКолонок.Вставить("price","Цена");
СоответствиеКолонок.Вставить("productID","Артикул");
СоответствиеКолонок.Вставить("oldPrice","Ст_цена");
СоответствиеКолонок.Вставить("averagePrice","Ср_цена");
СоответствиеКолонок.Вставить("lowPrice","Мин_цена");
СоответствиеКолонок.Вставить("highPrice","Макс_цена");
СоответствиеКолонок.Вставить("optPrice","Опт_цена");
СоответствиеКолонок.Вставить("datePublished","ДатаПубликации");
СоединениеССайтом = Прайскоп_Пауки.ПолучитьСоединениеСБазой();
Если СоединениеССайтом = Неопределено Тогда
Возврат;
КонецЕсли;
ПорцияЗагрузкиЦен = Константы.ПорцияЗагрузкиЦен.Получить();
Если ПорцияЗагрузкиЦен = 0 Тогда ПорцияЗагрузкиЦен = 100; КонецЕсли;
ТекстЗапроса = "select * from " + Источник.Таблица;
ТекстЗапроса = ТекстЗапроса + " where idgoods > " + Формат(ИД,"ЧРГ=; ЧН=0; ЧГ=0");
ТекстЗапроса = ТекстЗапроса +" limit "+ Формат(ПорцияЗагрузкиЦен,"ЧРГ=; ЧН=0; ЧГ=0");
Рекордсет = Новый COMОбъект("ADODB.Recordset");
Рекордсет.Open(ТекстЗапроса, СоединениеССайтом, 3, 1);
RegExp = Новый COMОбъект("VBScript.RegExp");
РекордсетПаук = Новый COMОбъект("ADODB.Recordset");
МассивКонтрагентов = Новый Массив;
МассивПрисутствующихТП = Новый Массив;
73
МассивОпределенияТегов = Новый Массив;
МассивЗаписиОчередиКлиентСайт = Новый Массив;
ДобавленоЦен = 0;
ПоследийПериодЦены = Неопределено;
МассивУРЛ = Новый Массив;
ПериодЦены = Неопределено;
Пока НЕ (Рекордсет.EOF) Цикл
Если Рекордсет.fields.Item("url").Value = Null or Рекордсет.fields.Item("url").Value = "" Тогда
Рекордсет.MoveNext();
Продолжить;
КонецЕсли;
Если ПериодЦены = Неопределено Тогда
ПериодЦены =
ПолучитьДатаВремя(Рекордсет.fields.Item("date").Value,Рекордсет.fields.Item("time").Value);
КонецЕсли;
МассивУРЛ.Добавить(Рекордсет.fields.Item("url").Value);
Рекордсет.MoveNext();
КонецЦикла;
Рекордсет.MoveFirst();
СоответствиеПауков = ПолучитьСоответствиеПауков(ПериодЦены,МассивУРЛ,СоединениеССайтом);
Пока НЕ (Рекордсет.EOF) Цикл
Если Рекордсет.fields.Item("url").Value = Null or Рекордсет.fields.Item("url").Value = "" Тогда
Рекордсет.MoveNext();
Продолжить;
КонецЕсли;
СтрокаДомен =
Прайскоп_ОбщегоНазначенияСервер.ВыделитьДоменИзУРЛ(Рекордсет.fields.Item("url").Value,RegExp);
СтрокаНаименование = Рекордсет.fields.Item("name").Value;
СтрокаНаименование = СтрЗаменить(СтрокаНаименование,Символы.ПС," ");
Пока Найти(СтрокаНаименование," ") > 0 Цикл
СтрокаНаименование = СтрЗаменить(СтрокаНаименование," ", " ");
КонецЦикла;
ТЕКУРЛ = Рекордсет.fields.Item("url").Value;
СтруктураТоварнойПозиции = Новый Структура();
СтруктураТоварнойПозиции.Вставить("УРЛ",ТЕКУРЛ);
СтруктураТоварнойПозиции.Вставить("КаноническийУРЛ",Прайскоп_ОбщегоНазначения.ДополнитьУРЛДоме
ном(Рекордсет.fields.Item("canonical").Value,ТЕКУРЛ,RegExp));
СтруктураТоварнойПозиции.Вставить("УРЛКатегории",Прайскоп_ОбщегоНазначения.ДополнитьУРЛДоменом(
Рекордсет.fields.Item("urlCategory").Value,ТЕКУРЛ,RegExp));
СтруктураТоварнойПозиции.Вставить("ХлебныеКрошки","");
СтруктураТоварнойПозиции.Вставить("Наименование",СтрокаНаименование);
СтруктураТоварнойПозиции.Вставить("Код",?(Рекордсет.fields.Item("sku").Value = Null, "",
Рекордсет.fields.Item("sku").Value));
СтруктураТоварнойПозиции.Вставить("Бренд",Рекордсет.fields.Item("brand").Value);
СтруктураТоварнойПозиции.Вставить("Артикул",Рекордсет.fields.Item("productID").Value);
СтруктураТоварнойПозиции.Вставить("Домен",СтрокаДомен);
СтруктураТоварнойПозиции.Вставить("Модель", ?(Рекордсет.fields.Item("model").Value =
Null,"",Рекордсет.fields.Item("model").Value));
74
СтруктураТоварнойПозиции.Вставить("Тег",Рекордсет.fields.Item("tag").Value);
СтруктураТоварнойПозиции.Вставить("Продавец",Рекордсет.fields.Item("seller").Value);
Если СоответствиеТП.Получить(СтруктураТоварнойПозиции.УРЛ) = Неопределено Тогда
ТоварнаяПозиция =
ПолучитьТоварнуюПозицию(СтруктураТоварнойПозиции,Истина,,Перечисления.ТочкиСозданияТП.ЗагрузкаЦен);
Иначе
ТоварнаяПозиция = СоответствиеТП.Получить(СтруктураТоварнойПозиции.УРЛ);
КонецЕсли;
Если ЗначениеЗаполнено(ТоварнаяПозиция) Тогда
Контрагент =
ОбщегоНазначения.ЗначениеРеквизитаОбъекта(ТоварнаяПозиция,"Контрагент");
Если ЗначениеЗаполнено(Контрагент) Тогда
МассивКонтрагентов.Добавить(Контрагент);
КонецЕсли;
КонецЕсли;
Если СтруктураТоварнойПозиции.Свойство("Тег") Тогда
Если ЗначениеЗаполнено(СтруктураТоварнойПозиции.Тег) Тогда
СтруктураОпределенияТега = Новый Структура;
СтруктураОпределенияТега.Вставить("Позиция",ТоварнаяПозиция);
СтруктураОпределенияТега.Вставить("НаименованиеТега",СтруктураТоварнойПозиции.Тег);
СтруктураОпределенияТега.Вставить("Домен",СтруктураТоварнойПозиции.Домен);
МассивОпределенияТегов.Добавить(СтруктураОпределенияТега)
КонецЕсли;
КонецЕсли;
Для ТекСвойство = 1 По 10 Цикл
ЗначениеСвойстваСтрока = Рекордсет.fields.Item("property" + Строка(ТекСвойство)).Value;
Если Не ЗначениеЗаполнено(ЗначениеСвойстваСтрока) Тогда
Продолжить;
КонецЕсли;
СтруктураСвойства = Новый Структура;
СтруктураСвойства.Вставить("ТП",ТоварнаяПозиция);
СтруктураСвойства.Вставить("Свойство",ПланыВидовХарактеристик.СвойстваТоварныхПозиций["Свойство" +
Строка(ТекСвойство)]);
СтруктураСвойства.Вставить("ЗначениеСвойстваСтрока",ЗначениеСвойстваСтрока);
МассивСвойствТП.Добавить(СтруктураСвойства);
КонецЦикла;
МассивПрисутствующихТП.Добавить(ТоварнаяПозиция);
ПериодЦены =
ПолучитьДатаВремя(Рекордсет.fields.Item("date").Value,Рекордсет.fields.Item("time").Value);
ТекСППаук = СоответствиеПауков.Получить(ТЕКУРЛ);
ЗапросПоискИд = Новый Запрос;
ЗапросПоискИд.Текст = "ВЫБРАТЬ
| Прайскоп_ЗагруженныеДанныеПоЦенам.ИД
|ИЗ
| РегистрСведений.Прайскоп_ЗагруженныеДанныеПоЦенам КАК
Прайскоп_ЗагруженныеДанныеПоЦенам
|ГДЕ
| Прайскоп_ЗагруженныеДанныеПоЦенам.ИД = &ИД";
75
ИДПроверка = Рекордсет.fields.Item("idgoods").Value;
ЗапросПоискИд.УстановитьПараметр("ИД", ИДПроверка);
ВыборкаПоискИД = ЗапросПоискИд.Выполнить().Выбрать();
Если ВыборкаПоискИД.Следующий() Тогда
Рекордсет.MoveNext();
Продолжить;
Иначе
Если ИДПроверка < (ИД + 5) Тогда
ЗаписьЖурналаРегистрации("Во время загрузки цены оказалось что ИД был
пропущен: "+ Строка(ИДПроверка),
УровеньЖурналаРегистрации.Информация,,,ПодробноеПредставлениеОшибки(ИнформацияОбОшибке()));
КонецЕсли;
КонецЕсли;
ОшибкаДлиныПоля = "";
Если СтрДлина(СтруктураТоварнойПозиции.УРЛ) > 300 Тогда
ОшибкаДлиныПоля = ОшибкаДлиныПоля + ?(ОшибкаДлиныПоля = "","",Символы.ПС) + "УРЛ
больше 300. " + СтруктураТоварнойПозиции.УРЛ;
КонецЕсли;
Если СтрДлина(СтруктураТоварнойПозиции.КаноническийУРЛ) > 300 Тогда
ОшибкаДлиныПоля = ОшибкаДлиныПоля + ?(ОшибкаДлиныПоля = "","",Символы.ПС) +
"Канонический УРЛ больше 300. " + СтруктураТоварнойПозиции.УРЛ;
КонецЕсли;
Если СтрДлина(СтруктураТоварнойПозиции.УРЛКатегории) > 300 Тогда
ОшибкаДлиныПоля = ОшибкаДлиныПоля + ?(ОшибкаДлиныПоля = "","",Символы.ПС) + "УРЛ
категории больше 300. " + СтруктураТоварнойПозиции.УРЛ;
КонецЕсли;
Если СтрДлина(СтруктураТоварнойПозиции.ХлебныеКрошки) > 300 Тогда
ОшибкаДлиныПоля = ОшибкаДлиныПоля + ?(ОшибкаДлиныПоля = "","",Символы.ПС) + "УРЛ
хлебные больше 300. " + СтруктураТоварнойПозиции.УРЛ;
КонецЕсли;
Если СтрДлина(СтруктураТоварнойПозиции.Наименование) > 300 Тогда
ОшибкаДлиныПоля = ОшибкаДлиныПоля + ?(ОшибкаДлиныПоля = "","",Символы.ПС) +
"Наименование больше 300. " + СтруктураТоварнойПозиции.УРЛ;
КонецЕсли;
Если СтрДлина(СтруктураТоварнойПозиции.Код) > 32 Тогда
ОшибкаДлиныПоля = ОшибкаДлиныПоля + ?(ОшибкаДлиныПоля = "","",Символы.ПС) + "Код
позиции больше 32. " + СтруктураТоварнойПозиции.УРЛ;
КонецЕсли;
Если СтрДлина(СтруктураТоварнойПозиции.Бренд) > 150 Тогда
ОшибкаДлиныПоля = ОшибкаДлиныПоля + ?(ОшибкаДлиныПоля = "","",Символы.ПС) +
"Бренд больше 150. " + СтруктураТоварнойПозиции.УРЛ;
КонецЕсли;
Если СтрДлина(СтруктураТоварнойПозиции.Артикул) > 50 Тогда
ОшибкаДлиныПоля = ОшибкаДлиныПоля + ?(ОшибкаДлиныПоля = "","",Символы.ПС) +
"Артикул больше 50. " + СтруктураТоварнойПозиции.УРЛ;
КонецЕсли;
Если СтрДлина(СтруктураТоварнойПозиции.Домен) > 75 Тогда
76
ОшибкаДлиныПоля = ОшибкаДлиныПоля + ?(ОшибкаДлиныПоля = "","",Символы.ПС) +
"Домен больше 75. " + СтруктураТоварнойПозиции.УРЛ;
КонецЕсли;
Если СтрДлина(СтруктураТоварнойПозиции.Модель) > 150 Тогда
ОшибкаДлиныПоля = ОшибкаДлиныПоля + ?(ОшибкаДлиныПоля = "","",Символы.ПС) +
"Модель больше 150. " + СтруктураТоварнойПозиции.УРЛ;
КонецЕсли;
Если СтрДлина(Рекордсет.fields.Item("typeOfGood").Value) > 150 Тогда
ОшибкаДлиныПоля = ОшибкаДлиныПоля + ?(ОшибкаДлиныПоля = "","",Символы.ПС) + "Тип
больше 150. " + СтруктураТоварнойПозиции.УРЛ;
КонецЕсли;
Если СтрДлина(Рекордсет.fields.Item("typeOfGood_brand").Value) > 150 Тогда
ОшибкаДлиныПоля = ОшибкаДлиныПоля + ?(ОшибкаДлиныПоля = "","",Символы.ПС) + "Тип
бренд больше 150. " + СтруктураТоварнойПозиции.УРЛ;
КонецЕсли;
Если СтрДлина(Рекордсет.fields.Item("brand_model").Value) > 150 Тогда
ОшибкаДлиныПоля = ОшибкаДлиныПоля + ?(ОшибкаДлиныПоля = "","",Символы.ПС) +
"Бренд модель больше 150. " + СтруктураТоварнойПозиции.УРЛ;
КонецЕсли;
Если СтрДлина(Рекордсет.fields.Item("category").Value) > 150 Тогда
ОшибкаДлиныПоля = ОшибкаДлиныПоля + ?(ОшибкаДлиныПоля = "","",Символы.ПС) +
"Категория больше 150. " + СтруктураТоварнойПозиции.УРЛ;
КонецЕсли;
Если СтрДлина(Рекордсет.fields.Item("model").Value) > 150 Тогда
ОшибкаДлиныПоля = ОшибкаДлиныПоля + ?(ОшибкаДлиныПоля = "","",Символы.ПС) +
"Модель больше 150. " + СтруктураТоварнойПозиции.УРЛ;
КонецЕсли;
Если СтрДлина(Рекордсет.fields.Item("addOn").Value) > 150 Тогда
ОшибкаДлиныПоля = ОшибкаДлиныПоля + ?(ОшибкаДлиныПоля = "","",Символы.ПС) +
"Акция больше 150. " + СтруктураТоварнойПозиции.УРЛ;
КонецЕсли;
Если СтрДлина(Рекордсет.fields.Item("isGift").Value) > 150 Тогда
ОшибкаДлиныПоля = ОшибкаДлиныПоля + ?(ОшибкаДлиныПоля = "","",Символы.ПС) +
"Подарок больше 150. " + СтруктураТоварнойПозиции.УРЛ;
КонецЕсли;
Если СтрДлина(Рекордсет.fields.Item("availableDeliveryMethod").Value) > 150 Тогда
ОшибкаДлиныПоля = ОшибкаДлиныПоля + ?(ОшибкаДлиныПоля = "","",Символы.ПС) +
"Доставка больше 150. " + СтруктураТоварнойПозиции.УРЛ;
КонецЕсли;
Если СтрДлина(Рекордсет.fields.Item("seller").Value) > 150 Тогда
ОшибкаДлиныПоля = ОшибкаДлиныПоля + ?(ОшибкаДлиныПоля = "","",Символы.ПС) +
"Продавец больше 150. " + СтруктураТоварнойПозиции.УРЛ;
КонецЕсли;
Если СтрДлина(Рекордсет.fields.Item("offerCount").Value) > 150 Тогда
ОшибкаДлиныПоля = ОшибкаДлиныПоля + ?(ОшибкаДлиныПоля = "","",Символы.ПС) +
"Предложений больше 150. " + СтруктураТоварнойПозиции.УРЛ;
КонецЕсли;
77
Если СтрДлина(Рекордсет.fields.Item("availability").Value) > 150 Тогда
ОшибкаДлиныПоля = ОшибкаДлиныПоля + ?(ОшибкаДлиныПоля = "","",Символы.ПС) +
"Наличие больше 150. " + СтруктураТоварнойПозиции.УРЛ;
КонецЕсли;
Если СтрДлина(Рекордсет.fields.Item("priceCurrency").Value) > 20 Тогда
ОшибкаДлиныПоля = ОшибкаДлиныПоля + ?(ОшибкаДлиныПоля = "","",Символы.ПС) +
"Валюта больше 20. " + СтруктураТоварнойПозиции.УРЛ;
КонецЕсли;
Если СтрДлина(Рекордсет.fields.Item("unitmeasure").Value) > 50 Тогда
ОшибкаДлиныПоля = ОшибкаДлиныПоля + ?(ОшибкаДлиныПоля = "","",Символы.ПС) +
"Единица измерения больше 50. " + СтруктураТоварнойПозиции.УРЛ;
КонецЕсли;
Если ОшибкаДлиныПоля <> "" Тогда
ЗаписьЖурналаРегистрации("Загрузка данных",
УровеньЖурналаРегистрации.Ошибка,,СтруктураТоварнойПозиции.УРЛ, ОшибкаДлиныПоля);
КонецЕсли;
МенеджерЗаписи =
РегистрыСведений.Прайскоп_ЗагруженныеДанныеПоЦенам.СоздатьМенеджерЗаписи();
МенеджерЗаписи.Источник = Перечисления.Прайскоп_ИсточникиЦен.Сайт;
МенеджерЗаписи.ТоварнаяПозиция = ТоварнаяПозиция;
МенеджерЗаписи.Период = ПериодЦены;
МенеджерЗаписи.Паук = ТекСППаук;
Для Каждого ТекКолонка Из СоответствиеКолонок Цикл
ЗначениеКолонки = Рекордсет.fields.Item(ТекКолонка.Ключ).Value;
Если ТекКолонка.Ключ = "price" Тогда
ЗначениеКолонки = СтрЗаменить(ЗначениеКолонки," ","");
ЗначениеКолонки = СтрЗаменить(ЗначениеКолонки,Символы.НПП,"");
КонецЕсли;
МенеджерЗаписи[ТекКолонка.Значение]= ЗначениеКолонки;
КонецЦикла;
ОшибкаОпределенияЦены = Ложь;
Попытка
СтрокаТолькоЦифры =
Прайскоп_ОбщегоНазначения.ТолькоЦиферныеСимволы(МенеджерЗаписи.Цена);
МенеджерЗаписи.ЦенаЧисло = Число(СтрокаТолькоЦифры);
Исключение
ОшибкаОпределенияЦены = Истина;
КонецПопытки;
Попытка
МенеджерЗаписи.Ст_ЦенаЧисло = Число(МенеджерЗаписи.Ст_цена);
Исключение
КонецПопытки;
ЗначениеСтрока = Рекордсет.fields.Item("typeOfGood").Value;
МенеджерЗаписи.ТипСсылка=
Справочники.Прайскоп_Тип.ПолучитьПоНаименованию(ЗначениеСтрока);
ЗначениеСтрока = Рекордсет.fields.Item("typeOfGood_brand").Value;
78
МенеджерЗаписи.Тип_БрендСсылка =
Справочники.Прайскоп_Тип_Бренд.ПолучитьПоНаименованию(ЗначениеСтрока);
ЗначениеСтрока = Рекордсет.fields.Item("brand_model").Value;
МенеджерЗаписи.Бренд_МодельСсылка =
Справочники.Прайскоп_Бренд_Модель.ПолучитьПоНаименованию(ЗначениеСтрока);
ЗначениеСтрока = Рекордсет.fields.Item("category").Value;
МенеджерЗаписи.КатегорияСсылка =
Справочники.Прайскоп_Категория.ПолучитьПоНаименованию(ЗначениеСтрока);
ЗначениеСтрока = Рекордсет.fields.Item("model").Value;
МенеджерЗаписи.МодельСсылка =
Справочники.Прайскоп_Модели.НайтиМодельПоНаименованию(ЗначениеСтрока);
ЗначениеСтрока = Рекордсет.fields.Item("addOn").Value;
МенеджерЗаписи.АкцияСсылка =
Справочники.Прайскоп_Акция.ПолучитьПоНаименованию(ЗначениеСтрока);
ЗначениеСтрока = Рекордсет.fields.Item("isGift").Value;
МенеджерЗаписи.ПодарокСсылка =
Справочники.Прайскоп_Подарок.ПолучитьПоНаименованию(ЗначениеСтрока);
ЗначениеСтрока = Рекордсет.fields.Item("availableDeliveryMethod").Value;
МенеджерЗаписи.ДоставкаСсылка =
Справочники.Прайскоп_Доставка.ПолучитьПоНаименованию(ЗначениеСтрока);
ЗначениеСтрока = Рекордсет.fields.Item("seller").Value;
МенеджерЗаписи.ПродавецСсылка =
Справочники.Прайскоп_Продавец.ПолучитьПоНаименованию(ЗначениеСтрока);
ЗначениеСтрока = Рекордсет.fields.Item("offerCount").Value;
МенеджерЗаписи.ПредложенийСсылка =
Справочники.Прайскоп_Предложений.ПолучитьПоНаименованию(ЗначениеСтрока);
ЗначениеСтрока = Рекордсет.fields.Item("priceCurrency").Value;
МенеджерЗаписи.Валюта =
Справочники.Прайскоп_Валюта.ПолучитьПоНаименованию(ЗначениеСтрока);
ЗначениеСтрока = Рекордсет.fields.Item("unitmeasure").Value;
МенеджерЗаписи.ЕдиницаИзмерения =
Справочники.Прайскоп_ЕдиницаИзмерения.ПолучитьПоНаименованию(ЗначениеСтрока);
НаличиеСтрока = Рекордсет.fields.Item("availability").Value;
Если НаличиеСтрока = "" ИЛИ НаличиеСтрока = Null Тогда
Если МенеджерЗаписи.ЦенаЧисло = 0 Тогда
НаличиеСтрока = "Нет (Автоматически)";
КонецЕсли;
КонецЕсли;
МенеджерЗаписи.Наличие =
Справочники.Прайскоп_Наличие.НайтиНаличиеПоНаименованию(НаличиеСтрока);
МенеджерЗаписи.Записать();
ПоследийПериодЦены = МенеджерЗаписи.Период;
ДобавленоЦен = ДобавленоЦен + 1;
Если Не ОшибкаОпределенияЦены Тогда
СтруктураЗаписи = Новый Структура;
СтруктураЗаписи.Вставить("Позиция",ТоварнаяПозиция);
79
СтруктураЗаписи.Вставить("ЦенаЧисло",МенеджерЗаписи.ЦенаЧисло);
СтруктураЗаписи.Вставить("Период",МенеджерЗаписи.Период);
СтруктураЗаписи.Вставить("Паук", МенеджерЗаписи.Паук);
СтруктураЗаписи.Вставить("ПредставлениеНаличия",МенеджерЗаписи.Наличие.ПредставлениеНаличия);
МассивЗаписиОчередиКлиентСайт.Добавить(СтруктураЗаписи);
КонецЕсли;
Рекордсет.MoveNext();
КонецЦикла;
Рекордсет.Close();
СоединениеССайтом.Close();
Если МассивКонтрагентов.Количество() <> 0 Тогда
Запрос = Новый Запрос;
Запрос.Текст = "ВЫБРАТЬ РАЗЛИЧНЫЕ
| Контрагенты.Ссылка
|ИЗ
| Справочник.Контрагенты КАК Контрагенты
|ГДЕ
| Контрагенты.Ссылка В(&МассивКонтрагентов)
| И Контрагенты.ИсключитьИзСбора =
ЗНАЧЕНИЕ(перечисление.ВариантИсключенияИзСбора.ДоПервогоПоступленияДанных)";
Запрос.УстановитьПараметр("МассивКонтрагентов",МассивКонтрагентов);
Выборка = Запрос.Выполнить().Выбрать();
Пока Выборка.Следующий() Цикл
ТекОбъКонтрагент = Выборка.Ссылка.ПолучитьОбъект();
ТекОбъКонтрагент.ИсключитьИзСбора =
Перечисления.ВариантИсключенияИзСбора.ПустаяСсылка();
ТекОбъКонтрагент.Записать();
КонецЦикла;
КонецЕсли;
МассивУРЛ =
Справочники.Прайскоп_ТоварныеПозиции.МассивУРЛПоМассивуТП(МассивПрисутствующихТП);
РегистрыСведений.Прайскоп_УдаленныеЗаданияПаука.ОчиститьЗаписиПоМассивуУРЛ(МассивУРЛ);
МассивЗапущенныхЗаданий = Новый Массив;
Ключ = Новый УникальныйИдентификатор;
МассивПараметров = Новый Массив;
МассивПараметров.Добавить(МассивПрисутствующихТП);
МассивПараметров.Добавить(Перечисления.ТочкаПодтвержденияСуществованияТоварнойПозиции.Данные);
МассивЗапущенныхЗаданий.Добавить(ФоновыеЗадания.Выполнить("Прайскоп_ОбщегоНазначения.Зафиксир
оватьНаличиеМассиваТП",МассивПараметров, Ключ, "ЗафиксироватьНаличиеМассиваТП"));
Ключ = Новый УникальныйИдентификатор;
МассивПараметров = Новый Массив;
МассивПараметров.Добавить(МассивСвойствТП);
МассивЗапущенныхЗаданий.Добавить(ФоновыеЗадания.Выполнить("Прайскоп_ОбщегоНазначения.Обновить
СвойстваТоварныхПозиций",МассивПараметров, Ключ, "ОбновитьСвойстваТоварныхПозиций"));
Ключ = Новый УникальныйИдентификатор;
МассивПараметров = Новый Массив;
МассивПараметров.Добавить(МассивОпределенияТегов);
МассивЗапущенныхЗаданий.Добавить(ФоновыеЗадания.Выполнить("Прайскоп_ОбщегоНазначения.Заполнит
ьТегКонтрагентаПозиции",МассивПараметров, Ключ, "ЗаполнитьТегКонтрагентаПозиции"));
Ключ = Новый УникальныйИдентификатор;
80
МассивПараметров = Новый Массив;
МассивПараметров.Добавить(МассивЗаписиОчередиКлиентСайт);
МассивЗапущенныхЗаданий.Добавить(ФоновыеЗадания.Выполнить("Прайскоп_ОбщегоНазначения.Записать
ОчередьКлиентСайт",МассивПараметров, Ключ, "ЗаписатьОчередьКлиентСайт"));
Если ПоследийПериодЦены <> Неопределено Тогда
Прайскоп_ОбщегоНазначения.УдалитьЗаписиPctaskdone(ПоследийПериодЦены);
КонецЕсли;
УстановитьПривилегированныйРежим(Ложь);
APDEX_ОценкаПроизводительностиКлиентСервер.ЗакончитьЗамерВремени("ПолучитьТаблицуЦенИзИсточни
ка",,"Добавлено цен: " + Формат(ДобавленоЦен,"ЧГ=0"));
КонецПроцедуры
81
ДОДАТОК В
Затверджую
Зав. кафедри КНСА,
______________ Юрій ТРИУС
«____»____________2024 р.
УПРАВЛІННЯ ПРОЄКТОМ РОЗРОБКИ ІНФОРМАЦІЙНОЇ СИСТЕМИ
МОНІТОРИНГУ ЦІН В ІНТЕРНЕТ МАГАЗИНАХ
Текст програм повний перелік робіт з діаграмою Ганта в Project Plan 365
482. ЧДТУ. 42234-01 12 02
Листів 3
Розробник ____________________ Данилюк А.А.
Черкаси – 2024
82
Рисунок В.1 – Перелік робіт фази ініціації з діаграмою Ганта
Рисунок В.2 – Перелік робіт фази планування з діаграмою Ганта
Рисунок В.3 – Перелік робіт фази реалізації з діаграмою Ганта
Рисунок В.4 – Перелік робіт фази завершення з діаграмою Ганта
Рисунок В.5 – Timeline проєкту
83
Рисунок В.6 – Таблиця використання ресурсів