Будь ласка, використовуйте цей ідентифікатор, щоб цитувати або посилатися на цей матеріал:
https://er.chdtu.edu.ua/handle/ChSTU/8843Повний запис метаданих
| Поле DC | Значення | Мова |
|---|---|---|
| dc.contributor.advisor | Андрієнко, Володимир Олександрович | - |
| dc.contributor.author | Плічко, Віталіна Юріївна | - |
| dc.date.accessioned | 2026-03-19T12:48:06Z | - |
| dc.date.available | 2026-03-19T12:48:06Z | - |
| dc.date.issued | 2022-06-16 | - |
| dc.identifier.uri | https://er.chdtu.edu.ua/handle/ChSTU/8843 | - |
| dc.description.abstract | Актуальність кваліфікаційної роботи бакалавра обумовлена необхідністю створення інформаційної системи, що надає можливість менеджерам пришвидшити пошук необхідного замовлення, його обробку з ціллю підвищення продажів та полегшення роботи, та для аналізу нових створених задач та також підбору виконавців для кожної задачі для керівництва компанії «Andersenlab» м.Черкаси. Метою кваліфікаційної роботи бакалавра є проектування інформаційної системи обробки та розподілу замовлень. Об’єкт дослідження: інформаційна система організації роботи менеджерів відділу продаж. Предмет дослідження: інформаційна система обробки та розподілу замовлень для менеджерів відділу продаж. Методи дослідження. В роботі застосовувалися практичні розробки, напрямки діяльності відділу продажу, аналіз обробки замовлень між менеджерами. | uk_UA |
| dc.language.iso | uk | uk_UA |
| dc.subject | ІНФОРМАЦІЙНА СИСТЕМА | uk_UA |
| dc.subject | ВІДДІЛ ПРОДАЖІВ | uk_UA |
| dc.subject | МЕНЕДЖЕР З ПРОДАЖУ | uk_UA |
| dc.subject | РОЗПОДІЛ | uk_UA |
| dc.subject | ПРОГРАМНІ ЗАСОБИ РОЗРОБКИ. | uk_UA |
| dc.title | Проектування інформаційної системи обробки та розподілу замовлень між менеджерами відділу продажів | uk_UA |
| dc.type | Bachelor Thesis | uk_UA |
| Розташовується у зібраннях: | 122 Комп’ютерні науки (Комп’ютерні науки та прикладне програмування) | |
Файли цього матеріалу:
| Файл | Опис | Розмір | Формат | |
|---|---|---|---|---|
| Пояснювальна записка_Плічко Віталіна_КНС-2001_2021-2022.pdf Restricted Access | 2.51 MB | Adobe PDF | Переглянути/Відкрити Запит копії |
Усі матеріали в архіві електронних ресурсів захищено авторським правом, усі права збережено.
Extracted text
1
МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ
ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОГІЧНИЙ УНІВЕРСИТЕТ
Факультет інформаційних технологій і систем
Кафедра комп’ютерних наук та системного аналізу
Пояснювальна записка
до кваліфікаційної роботи
бакалавра
(освітньо-кваліфікаційний рівень)
на тему: «Проектування інформаційної системи обробки та розподілу
замовлень між менеджерами відділу продажів»
Виконав: студент 4 курсу, групи КНС-2001
спеціальності 122 − «Комп’ютерні науки»
(шифр і назва спеціальності)
освітня програма «Комп’ютерні науки та .
прикладне програмування
(назва освітньої програми)
Плічко Віталіна Юріївна
Керівник __________ Андрієнко В.О.
(прізвище та ініціали)
Рецензент _________ Засядько А.А.
(прізвище та ініціали)
Черкаси 2022 рік
Черкаський державний технологічний університет
Факультет Інформаційних технологій і систем
Кафедра Комп’ютерних наук та системного аналізу
Освітній рівень Бакалавр
Спеціальність 122 – комп’ютерні науки
ЗАТВЕРДЖУЮ
Завідувач кафедри КН та СА
_______________ Триус Ю.В.
«____» _____________ 2022 р.
ЗАВДАННЯ
на кваліфікаційну роботу бакалавра студенту
Плічко Віталіні Юріївні
(прізвище, ім’я, по батькові)
1. Тема роботи Проектування інформаційної системи обробки та розподілу замовлень
між менеджерами відділу продажів
Керівник роботи Андрієнко Володимир Олександрович, к.т.н., доцент
(прізвище, ім’я, по батькові, науковий ступінь, вчене звання)
затверджені наказом університету від «7» лютого 2022 р. №45/04.
2. Строк подання студентом роботи до 16 червня 2022 року
3. Вихідні дані до роботи:
виконання задач із пакування ПЗ – зовнішня веб-система «JIRA»
зберігання даних про час та працю, внутрішня веб-система «TimeTracker», «Apptimized Intranet»
Звіт з виробничої практики.
4. Зміст пояснювальної записки (перелік питань, що їх належить розробити):
Вступ.
4.1. Аналіз предметної області
4.2. Постановка задачі та методи дослідження»
4.3. Моделювання інформаційної системи
4.4. Реалізація інформаційної системи
Висновки.
5. Перелік додатків (з точним зазначенням назв додатків):
5.1. Додаток А. Специфікація 482.ЧДТУ. 22095-01.
5 .2. Додаток Б. Інструкція користувача.
5.3. Презентація у вигляді 24 слайдів.
6. Консультанти розділів роботи
Прізвище, ініціали та Підпис, дата
Розділ посада
завдання видав завдання прийняв
консультанта
7. Дата видачі
завдання 11.01.2022
КАЛЕНДАРНИЙ ПЛАН
Строк
№ Назва етапів кваліфікаційної роботи
виконання Примітка
з/п бакалавра
етапів роботи
1 Видача завдання на кваліфікаційну роботу
до 03.01.2022 Виконано
бакалавра.
2 Аналіз літературних джерел, об’єкту та предмету
до 15.02.2022 Виконано
дослідження.
3 Написання теоретичного розділу кваліфікаційної
до 10.03.2022 Виконано
роботи бакалавра.
4 Написання аналітичного розділу (аналіз об’єкту
до 03.04. 2022 Виконано
й предмету дослідження).
5 Написання практичних розділів й висновків по
до 25.05.2022 Виконано
роботі.
6 Перед захист кваліфікаційної роботи бакалавра
до 26.05.2022 Виконано
на засіданні випускової кафедри.
7 Подання роботи завідувачу кафедри. до 16.06. 2022 Виконано
8 Захист кваліфікаційної роботи бакалавра. 16.06.2022 Виконано
Студент _____________________________ Плічко В.Ю.
(підпис)
Керівник роботи ____________________________ Андрієнко В.О.
(підпис)
3
РЕФЕРАТ
Кваліфікаційна робота бакалавра містить: 114 с., 15 рисунків, 3 таблиць,
17 використаних джерел, 3 додатки.
Актуальність теми: Актуальність кваліфікаційної роботи бакалавра
обумовлена необхідністю створення інформаційної системи, що надає можливість
менеджерам пришвидшити пошук необхідного замовлення, його обробку з ціллю
підвищення продажів та полегшення роботи, та для аналізу нових створених задач
та також підбору виконавців для кожної задачі для керівництва компанії
«Andersenlab» м.Черкаси.
Мета роботи і задачі дослідження: Метою кваліфікаційної роботи
бакалавра є проектування інформаційної системи обробки та розподілу замовлень.
Для досягнення вирішення завдання необхідно вирішити наступні задачі:
− виконати огляд існуючих засобів для розробки
інформаційних систем;
− провести порівняльний аналіз існуючих інформаційних
систем організації роботи менеджерів;
− спроектувати і створити інформаційну систему відділу
продажів.
Об’єкт дослідження: інформаційна система організації роботи менеджерів
відділу продаж.
Предмет дослідження: інформаційна система обробки та розподілу
замовлень для менеджерів відділу продаж.
Методи дослідження. В роботі застосовувалися практичні розробки,
напрямки діяльності відділу продажу, аналіз обробки замовлень між менеджерами.
Перелік ключових слів: ІНФОРМАЦІЙНА СИСТЕМА, ВІДДІЛ
ПРОДАЖІВ, МЕНЕДЖЕР З ПРОДАЖУ, РОЗПОДІЛ, ПРОГРАМНІ ЗАСОБИ
РОЗРОБКИ.
4
ABSTRACT
Bachelor's qualification work contains: 114 p., 15 figures, 3 tables, 17 sources
used, 3 annexes.
Relevance of the topic: The relevance of the bachelor's qualification work is due
to the need to create an information system that allows managers to speed up the search
for the necessary order, its processing in order to increase sales and facilitate work, and
to analyze the newly created tasks and select performers for each task for the management
of the company "Andersenlab" in Cherkasy.
The purpose of the work and tasks of the study: The purpose of the bachelor's
qualification work is to design an information system for processing and distributing
orders:
− perform an overview of existing tools for the development of
information systems;
− conduct a comparative analysis of the existing information
systems for organizing the work of managers;
− design and create an information system of the sales department.
Object of research: information and system of organization of work of managers
of sales department.
Subject of research: information and system of processing and distribution of
orders for managers of the sales department.
Research methods. The work used practical and development and, directions of
activity of the sales department, analysis of order processing between managers.
Keyword list: INFORMATIONA SYSTEM, SALES DEPARTMENT, SALES
MANAGER, DISTRIBUTION, SOFTWARE DEVELOPMENT TOOLS.
5
ЗМІСТ
ПЕРЕЛІК УМОВНИХ ПОЗНАЧЕНЬ, СИМВОЛІВ, СКОРОЧЕНЬ І ТЕРМІНІВ… 7
ВСТУП ...................................................................................................................... 8
1 АНАЛІЗ ПРЕДМЕТНОЇ ОБЛАСТІ ДОСЛІДЖЕННЯ ................................... 11
1.1 Аналіз структури компанії «Andersenlab» та її бізнес-процесів ............... 11
1.2 Порівняльний аналіз найпоширеніших систем з розподілу задач ..... 16
Висновки до розділу 1 ..……………………………………………………… 20
2 ПОСТАНОВКА ЗАДАЧІ РОЗРОБКИ ТА МЕТОДИ ДОСЛІДЖЕННЯ ..... 22
2.1 Мета та задачі дослідження .................................................................. 22
2.2 Методи дослідження ….................................................................................. 23
2.2.1. Вибір підходу реалізації аналізу задач ………………………...…. 24
2.2.2. Вибір методології розподілу задач ...………………………….. 26
2.2.3. Вибір методології реалізації пошуку схожості замовлень ……....... 31
2.2.4. Вибір технологій реалізації інформаційної системи …………….… 34
2.2.5. Вибір технологій збереження інформації …………………...… 37
Висновки до розділу 2 ….…………………………………………….....…… 40
3 МОДЕЛЮВАННЯ ІНФОРМАЦІЙНОЇ СИСТЕМИ ............................................. 42
3.1 Побудова контекстної діаграми в вигляді IDEF0 ................................... 42
3.2 Створення моделі прецедентів .................................................................. 44
3.3 Моделювання системи ............................................................................ 46
3.3.1. Критерії оцінювання навантаження працівника ……………..…47
3.3.2. Моделювання процесу підбору виконавців ………………...….... 50
3.3.3. Моделювання аналізу задачі ………………………………...…. 51
3.3.4. Моделювання бази даних …………………………………..……… 53
3.4 Робота інформаційної системи .................................................................. 57
Висновки до розділу 3 ……………………………………………………….. 58
4 РЕАЛІЗАЦІЯ ІНФОРМАЦІЙНОЇ СИСТЕМИ ОБРОБКИ ТА РОЗПОДІЛУ
ЗАВДАНЬ ……………………………………………………………........................ 59
4.1 Реалізація інформаційної системи обробки та розподілу ......................... 59
6
4.2 Система контролю версіями .................................................................. 69
Висновки до розділу 4 ...…………………………………………………...… 70
ВИСНОВКИ .......................................................................................................... 71
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ .................................................................. 73
ДОДАТОК А Планування робіт ............................................................................ 75
ДОДАТОК Б Код розробленої системи .................................................................. 77
7
ПЕРЕЛІК УМОВНИХ ПОЗНАЧЕНЬ, СИМВОЛІВ, СКОРОЧЕНЬ І
ТЕРМІНІВ
ІС – Інформаційна система що здатна зберігати та обробляти
інформацію з метою забезпечення потреб користувачів
CRM – Customer relationship management (Управління відносинами з
клієнтами)
CMS – (англ. Content management system) система керування вмістом
ОС – Операційна система
БД – База даних.
СУБД – Система управління базою даних.
Пакет ПЗ – Результат процесу розробку деякого ПЗ у межах
компанії «Andersenlab».
ПЗ – Програмне забезпечення.
Розробка ПЗ– Процес перетворення з оригінальних та інсталяційних файлів ПЗ в
один із пакетів форматів (MSI, App-V, MSIX, AppX) для
розповсюдження на велику кількість комп’ютерів у
копіювальному режимі.
Розробник
ПЗ – Спеціаліст із розробку програмного забезпечення.
IDEF0 – Фундаментальне представлення моделювання бізнес-процесів.
MVC – Патерн для проектування програмного забезпечення (з англ.
«Модель-Представлення-Контролер») «Model-View- Controller».
8
ВСТУП
На етапі розвитку інформаційних технологій все частіше сучасні
підприємства та ІТ компанії починають використовувати системи автоматизації
для пришвидшення роботи, а також зменшення виникнення помилок через
людський фактор.
Сучасні компанії з виготовлення та підтримки програмного забезпечення
часто у своїй професійній діяльності використовують нові інформаційні технології,
які зможуть вирішувати досить різноманітний спектр задач: від керуванням самим
підприємством до допомоги в прийнятті головних управлінських або інших рішень.
«Andersenlab» є однією з ІТ-компаній Черкащини. Дана компанія
спеціалізується на розробці та пакуванні програмного забезпечення (ПЗ). Розробка
програмного забезпечення (Software) – це власне процес перетворення готових
інсталяційних файлів для деякого ПЗ в один із необхідних форматів інсталяційних
пакетів: AppX або MSIX, MSI, App-V, із додатковим налаштуванням програми.
Цей процес служить для подальшого досить легкого встановлення
«запакованого» встановлюваного інсталяційного пакету ПЗ на велику кількість
корпоративних та особистих комп’ютерів через системи програмного
розповсюдження ПЗ, такі як (SCCM) System Center Configuration Manager.
Перелічені раніше формати інсталяційних пакетів досить легко
налаштовуються для подальшого розповсюдження через схожі системи, тоді як
поширення оригінальних інсталяційних файлів використовуваного ПЗ можуть бути
достатньо складним завданням для самої систем розповсюдження. Проходження
подальших налаштувань інтерфейсу інсталяції оригінальних файлів такого додатку
для кожного нового комп’ютера буде займати досить багато часу, тоді як сам
інсталяційний пакет служить саме для «тихого» встановлення і без будь-якого
необхідного інтерфейсу (таке повне налаштування програми в даному випадку
здійснюють фахівці «Andersenlab»).
На сьогодні процес отримання та опрацювання нових замовлень, виконання
поточних завдань з розробки ПЗ та власне здачі готових результатів роботи
9
замовникам переважно проводиться через готову web-систему виконання та
відстеження поставлених задач JIRA. Така система є досить зручна для виконання
поставлених для неї завдань, для відстеження статусів виконання та комунікації
виконавців із замовниками.
Пакет рішень, має свій основний життєвий цикл – так починаючи від власне
надходження запитів від замовника компанії, закінчуючи створенням та
відправленням готового програмного продукту.
Першим таким можливим етапом в цьому життєвому циклі є
перенаправлення завдання на відповідного працівника компанії. Саме він
проводить підготовку та збір інформації про програмний пакет, формує його
складність, та комплексну матрицю. В цій матриці й визначається складність
програмного пакета.
Головна проблема полягає у самих етапах життєвого циклу програмного
пакета. Складність на сьогодні визначається вже після того, як відповідний
працівник його вже почав виконувати. Але, такий підхід може мати декілька
недоліків, власне таких як – не можливість точно розрахувати повну завантаженість
команди, після того як запит був створений.
Для вирішення описаної проблеми та для забезпечення більш якісного та
комфортного процесу роботи може бути проведений аналіз складності поставленої
задачі та можливість автоматизації всього життєвого циклу.
Метою даного проекту є проектування інформаційної системи аналізу,
обробки та розподілу робочих задач (замовлень) для компанії «Andersenlab».
За для досягнення поставленої мети будуть задіяні такі методи дослідження
як: аналогія, аналіз, моделювання та експеримент.
Об’єкт дослідження: діяльність процесу розподілу задач та менеджменту
компанії.
Предмет дослідження: виконані та вже завершені поставлені завдання для
проведення подальшого аналізу; а також повний життєвий цикл всієї робочої
задачі.
Для досягнення мети роботи необхідно виконати наступні задачі:
10
- Збір потрібної інформації використовуючи сторонні
системи;
- Провести аналіз предметної області: аналіз бізнес-процесів
компанії; аналіз структури компанії; аналіз всього процесу розподілу
поставлених задач;
- Аналіз використовуваних підходів для розробки;
- Проектування інформаційної системи з розподілу робочих
задач (замовлень);
- Створення прототипу інформаційної системи;
- Тестування системи;
- Введення в експлуатацію.
Практичне значення кваліфікаційної роботи полягає в реалізації моделі
інформаційної системи розподілу робочих задач (поступивших замовлень), що
дозволятиме проглядати завантаженість працівників і далі розподіляти необхідні
задачі між всією командою з огляду на поточне завантаження кожного працівника
команди. Також до результатів кваліфікаційної роботи буде входити наступне:
- розроблена інформаційна модель бізнес-процесів
розподілу робочих задач ІТ-компанії «Andersenlab»;
- розроблена інформаційна система для аналізу
навантаження працівників в компанії «Andersenlab».
11
1 АНАЛІЗ ПРЕДМЕТНОЇ ОБЛАСТІ ДОСЛІДЖЕННЯ
1.1 Аналіз структури компанії «Andersenlab» та її бізнес-процесів
«Andersenlab» – компанія з розробки програмного забезпечення яка на ринку
14+ років. Вона налічує в собі до 3000 досвідчених працівників в галузі розробки
програмного забезпечення за різними напрямками. За час свого існування, вони
встигли реалізувати більше 1000 проектів. До технологій на який спеціалізується
компанія, відносяться: .Net, UI/UX design, Swift, Java, JavaScript, TypeScript,
AngularJS, ReactJS.
Компанія має декілька напрямків розробки, а саме Web, Mobile та Design.
Основними етапами всього процесу розробки є веб-дизайн макету, верстка
сторінок програми, програмування для веб на стороні клієнта і сервера, та
конфігурування веб-сервера. Web-розробка – це весь процес створення веб-сайтів
або веб-додатків.
Розробка застосунків для мобільних пристроїв (Mobile) – це процес, при
якому застосунки розробляються для невеликих портативних пристроїв, таких як
КПК, смартфони або телефони. Ці програми можуть бути встановлені на пристрій
в процесі виробництва, завантажені користувачем з допомогою різних платформ
для поширення або бути веб-застосунками, які обробляються на стороні клієнта
(Java Script) або сервера.
В компанії немає чіткого графіку роботи, важливо якісно та вчасно
виконувати свою роботу та бути присутнім на обговореннях важливих тем.
Для нормальної організації діяльності такого підрозділу існує ціла команда
менеджерів, до обов’язків якої входить наступне:
– організація роботи команди працівників;
– аналіз навантаження команди;
– розподіл задач, які надходять від замовників з певною періодичністю;
– організаційні обов’язки компанії.
До складу менеджерів компанії входять: Office Director, Head of Operations та
інші.
12
Розвиток сучасних інформаційних технологій, створення нових класів
програмних продуктів, покращення технічної платформи власне і призвів до нових
змін підходів в автоматизації управління компанією та виробництвом.
Ефективне управління компанії – цінний ресурс такої організації, такий як
людський, фінансовий, матеріальний тощо. Автоматизація процесу виробництва –
найбільш дієвий спосіб для підвищення ефективності протікання існоючих
процесів.
В компанії створюються додатки на Java та .Net. Використовуються такі
технології, як: OS/Android native (Swift and Kotlin), JavaScript, TypeScript,
AngularJS, ReactJS, CSS3/HTML5, jQuery, cloud and PaaS. Також створюється
UI/UX дизайн.
Динамічний розвиток ринку ІТ у світі здійснює значний вплив і на розвиток
всього світового підприємництва. Розробка та впровадження нових технологій
добре оптимізує майже всі процеси керівництва та виробництва, це дозволяє ще
більш ефективно використовувати існуючі ресурси компанії, сприяє прискоренню
обміну доступною інформацією.
Також, для розробки використовується різноманітне програмне
забезпечення: WebStorm, IntelliJіdea та інші. Для контролю версій
використовується веб-сервіс GitLab.
В якості робочої машини працівник може обрати офісний комп’ютер, або ж
особистий ноутбук.
Діяльність роботи компанії, також пов’язана з розробкою програмного
забезпечення у відповідні програмні пакунки. Для тестування мобільних додатків
доступні різноманітні мобільні пристрої на базі iOS та Android, набір SIM-карт з
2G, 3G та 4G інтернетом. Як тільки компанія отримує знову нове замовлення на
розробку програми – відповідальна особа, а це в нашому випадку Head of
Operations, повинна проаналізувати задачу, визначити для неї можливий час на
виконання, також оцінити навантаження команди розробників, визначити людей,
які можуть виконати дану задачу для даного проекту тощо.
13
Процес розподілу завдань між командою є досить специфічним завданням
менеджера, оскільки власне на першому етапі – після того як тільки задача
поступила від замовника то відразу дуже важко оцінити її виконання з точки зору
часу, який власне буде необхідний для її виконання. Особі, яка відповідає за
розподіл необхідно кожен раз враховувати багато різних параметрів та деяких
нюансів для кожного розробника, та для кожного нового замовлення. Такий процес
може займати досить багато часу, так як дані, які потрібно проаналізувати можуть
знаходитися в різних web-системах, тому їх потрібно скомпонувати та об’єднати
для отримання представлення точного навантаження для всієї команди тощо.
При встановленому такому підході затрачається досить велика кількість
затраченого часу навіть на поверхневий аналіз отриманої задачі, для того щоб
мінімізувати можливі наслідки.
Даний підхід спричиняє наступні наслідки:
– Нерівномірний розподіл навантаження між командою;
– Можливе порушення дедлайну.
«Andersenlab» застосовує продукт компанії «Atlassian» – Jira. Продукт
дозволяє керівництву та працівникам відслідковувати поточні та виконані задачі,
час на виконання, аналізувати доступні ресурси тощо. Всі завдання в Jira мають
інформацію, яка є необхідною для призначення виконання завдання програміст.
Застосована система дозволить покрити лише деяку частину такої проблеми
– як моніторинг задач, та їх життєвого програмного циклу. Але не дозволяє
достатньо оцінити можливий рівень зроблених зусиль (level of effort) що є на
самому початку життєвого циклу поставленої задачі, це має досить негативний
вплив і на планування завантаження тої чи іншої команди, розподіл важливих задач
тощо.
Керівництво ІТ компанії хоче мати оперативну можливість отримувати
хороший аналіз по виконанню кожного замовлення, що надходить від всіх
замовників, для прийняття управлінських рішень по керування компанією, а саме:
– Контроль за навантаженням робочих команд конкретних розробників
ПЗ для окремих проектів;
14
– Прогнозування можливого завантаження всієї команди та окремо її
працівників.
Як підсумок сказаного вище, можна узагальнити, що ІТ компанія потребує
додатковий інструментарій, який дозволив би наступне:
– мати миттєвий аналіз для кожної нової задачі на складність виконання;
– отримувати перелік можливих виконавців нових задач.
Метою кваліфікаційної роботи є розробка більш вузького спрямованого
продукту для поставлених конкретних цілей – аналізу кожної задачі, визначення
приблизного рівня завантаження, необхідного на вирішення тої чи іншої задачі, та
визначення можливих виконавців для даної задачі базуючись на поточному
навантаженні команди та кожного з працівників.
Актуальність розробки та впровадження такої інформаційної системи
управління зумовлена неможливістю хорошої оцінки та розрахувати необхідний
рівень зусиль (Lo E), який буде необхідний на створення програми.
Використання такої інформаційної системи управління забезпечить більш
швидкий розподіл поставлених задач, який власне буде базуватися на деяких
критеріях, що були визначені як основні:
– Навантаження працівника;
– Визначена можливих часових витрат на задачу.
Аналіз замовлення від замовника. У компанії «Andersenlab» процес розробки
починається із створення потенційним клієнтом замовлення на майбутню розробку
ПЗ. Таке замовлення, створене у одній з хмарних веб-систем «Andersenlab
Dashboard», автоматично створюється та додається у веб-системі виконання і
моніторингу всіх завдань «JIRA» у вигляді нової задачі.
Нова задача на розробку ПЗ призначається одному із команди розробників
людиною, що відповідає за розподіл завдань.
Така задача має всю необхідну інформацію для програміста. У ході роботи
над проектом всі дані заносяться до задачі у системі «JIRA» у певному
формалізованому виді.
15
Кожна нова задача має деякі визначені наступні ключові поля, що дозволяють
визначати деякий прогрес по виконанню поточної задачі, терміновість, складність
тощо. Статус – це поле, яке визначає поточний статус виконуваного замовлення: в
роботі, чекає на тестування тощо. Поле SLA – визначає кількість необхідного часу,
який вже був затрачений на виконання даної розробки, загальний час необхідний
на виконання завдання, та дату її дедлайну. Пріоритетність – поле, яке визначає
терміновість виконання задачі: терміновий чи нормальний. Технологія поточної
розробки – дане поле вказує та відповідає за технологію розробки ПЗ: App-V, MSI
тощо.
Кожна виділена задача має свій власний ідентифікатор в даній системі «Jira»,
це дозволяє досить однозначно ідентифікувати необхідну задачу. Такий
ідентифікатор використовується самою системою «Time Tracker», а також буде
використовуватися інформаційною системою управління розподілу поставлених
задач для синхронізації даних між усіма взаємодіючими між собою системами.
Даний ідентифікатор в системі використовується для того щоб використаний час,
який фахівці витрачають на проект – розробку та саме тестування, заносилися до
розробленої внутрішньої веб-системи «Time Tracker» в повністю формалізованому
вигляді.
Кожен тікет із даних систем «Jira» і «Time Tracker» може бути описаний в
інформаційній системі використовуючи числові представлення основних критеріїв,
які описують ту чи іншу задачу. Зіставивши всі отримані дані із різних систем, ми
зможемо однозначно описати поточні задачі розробників, нові задачі, а також ті які
вже відправлені замовникам.
Замовлення, також має поля, які відображають ту людину, яка на даний
момент займається цим замовленням, поле, яке відображає задіяного програміста,
а також поле, яке відображає задіяного QA інженера.
Використовуючи такий опис, інформаційна система управління буде
аналізувати поточне завантаження працівників та визначати необхідний час на
виконання нової задачі в проекті.
Приклад актуальної задачі представлений на рисунку 1.1.
16
Рисунок 1.1 – Приклад сторінки замовлення на розробку ПЗ
1.2 Порівняльний аналіз найпоширеніших систем з розподілу задач
Перед усім слід зазначити основні сформульовані вимоги замовника даного
проекту (керівництва компанії «Andersenlab») до розроблюваної інформаційної
систему управління, аналізу та розподілу переліку поставлених задач.
У даному підрозділі розглядатимуться деякі особливості, переваги та
недоліки таких підходів та різновидів до аналізу розподілених робочих задач.
Вже на основі доступних отриманих даних з працюючих веб-систем
компанії, така інформаційна система повинна проводити аналіз нові задачі та
отримувати актуальну оцінку задачі у відповідності з обраними параметрами
системи – серед яких:
– Оцінка можливої складності запиту на розробку (Complexity Ratio);
– Оцінка складності запиту на дану розробку відносно даної проектної
складності (ProjectComplexityRatio);
– Оцінка терміновості запиту (Priority Ratio);
– Оцінка часу (SLA Ratio).
На основі отриманих показників, на яких повинна аналізуватися нова
отримана задача, та визначатися її складність, що в свою чергу дозволить
покращити процес планування.
17
Основною вимогою до даної системи є – можливість призначення робочої
задачі для працівника, який з команди найкраще підходить для її виконання.
Розглянувши поставлені вимоги, слід переглянути основні програмні
продукти, які теоретично можуть виконувати схожі функції.
Microsoft Excel. Аналогом розроблюваної системи розрахунків та визначення
результатів може слугувати програмне забезпечення Excel, яке дозволяю за
допомогою вбудованих функцій, а також програмних розширень функціоналу
виконувати поставлені задачі перед інформаційною системою. Але даний продукт
все ж таки більше підходить для зберігання інформації в табличному виді та її
обробки, але формалізувати задачі на розробку даний продукт не зможе, оскільки
він не має такого функціоналу – доступ та взаємодія з API інших веб-систем
компанії.
Головні елементи JIRA – це проблема і робочий процес (з англ. workflow).
Трекінгова система Jira. Atlassian JIRA – це система для відстеження задач,
можливих помилок, розроблена для організації спілкування команди з
користувачами, а також і для управління всіма проектами. Вона розроблена
компанією Atlassian ще в 2012 році. Зараз існує дві основні версії: хмарна і
серверна.
Проблема описує ту задачу яка має бути зараз виконана, і мусить отримати
назву і повний детальний опис, а також проблема повинна мати деякий пріоритет,
автора проблеми і тих хто має над нею працювати. Та в залежності від виду (задача,
інцидент, баг) атрибути даної явної проблеми варіюються саме від її виду.
Одним з важливих атрибутів будь-якої задачі є її статус (від англ. status) який
показує власне поточний етап роботи над поставленою задачею. Статус завжди
змінюється відповідно до робочого процесу що створений для цієї проблеми та при
її вирішенні.
Найпростішим робочим процесом є: – «заплановано» – «в роботі» –
«зроблено», проте майже для кожного виду проблеми є власний робочий процес.
Та будь-які зміни проблеми записуються в журналі активності. Робочий процес –
це деякий набір дій, що виконуються над основною проблемою для її вирішення.
18
В JIRA і проблема, і також робочий процес можуть бути зконфігуровані
адміністратором, він може створити різні користувацькі елементи, та модифікувати
інші стандартні елементи.
Jira використовується в компанії для контролю та відслідковування задач – її
основних функцій. За допомогою вбудованих в систему плагінів, користувач може
зважено оцінити кількість поставлених завдань, які наразі має проектувальник, але
весь процес аналізу та збору інформації займає достатньо багато часу – це всі ті
проблеми, що були описані в розділі 1.1.
Як бачимо, компанія зацікавлена в вузько направленій замкнутій системі, і
для вирішення конкретних поставлених задач, які не вирішує дана веб-система.
Наразі цей підхід застосовується в компанії – для аналізу навантаження по
отриманій інформації з цієї веб-системи.
Trello. Trello – це безкоштовна web-система управління різними проектами,
яка використовує, як парадигму, керування цими проектами. Всі проекти
зображуються на дошках, які містять списки, та які в свою чергу містять різні
картки, якими, в даній системі, зображуються оброблені задачі.
Такі картки можуть переходити з одного списку до кожного наступного (за
допомогою так званого перетягування) – такий рух відображає перебіг виконуваної
задачі по процесу даної картки. Такій картці може бути присвоєно користувачів що
відповідають за неї. Web-система має команди – об’єднання користувачів та дошок
задач.
Ця система, як і Jira дає можливість відслідковувати виконання задач в
команді, та відслідковувати її основні статуси та часові показники виконання, але
це не дозволяє визначити її поточну завантаженість всієї команди та окремого
учасника групи на основі визначених критеріїв.
Wrike. Можливості Wrike включають обмін інформацією між
співпрацівниками, розгорнуте планування і управління всіма бізнес-процесами,
аналіз даних та формування звітів робіт.
Усі робочі процеси що задіяні у Wrike представлені у вигляді набору
категорій, створюваних проектів, та завдань і їх під задач. Щоб забезпечити швидке
19
занурення в контекст даної роботи і доступ до останніх збережених файлів і
дискусій по завданнях. До особливостей даного сервісу також можна віднести
прив'язку різних обговорень до поставлених завдань.
Функції для створення потрібних звітів дозволяють зекономити час що
витрачається на виконання деяких рутинних завдань, такі як збір різних даних по
поточному та майбутньому прогресу проекту [17].
Основні функції системи:
– Панелі задач з актуальним статусом актуальних важливих доручень.
– Регулювання прав доступу та редагування на рівні виконуваних
проектів, деяких окремих завдань і користувачів.
– Настроюванні поля і статуси завдань проекту, що дозволяють
адаптувати сервіс під унікальні робочі процеси.
– Інструменти для спільної роботи.
– Настроюються звіти за ключовими показниками, статусам таких
проектів і визначення продуктивності команди.
– Редагування відкритих проектів у вигляді створених таблиць.
– Миттєві повідомлення в браузері і e-mail про основні важливі
оновлення завдань проектів.
– Інтерактивні діаграми Ганта використані для планування проектів та
розподілу завантаження.
– Відстеження часу, що витрачений співпрацівником з команди на кожну
поставлену задачу.
– Календарі для створення графіка роботи співпрацівників, обліку їх
відпусток, лікарняних та святкових днів.
– Підтримування технології єдиного входу, дозволяє використовувати
логін і пароль для використання корпоративних систем.
– Додатки для Apple Mail, та Outlook дозволяють створювати і
редагувати завдання використовуючи поштового клієнта.
ProofHub. Це програмне забезпечення для можливості управління проектами,
що вирішує практично всі проблеми, які постають перед зростаючою командою.
20
Робочі процеси та канали у ProofHub спрощують процеси керування
завданнями, дозволяючи визначити індивідуальний процес роботи команди, його
ви можете значно покращити, щоб мати можливість забезпечити більшу гнучкість
у роботі ваших команд.
ProofHub дозволяє контролювати час, який працівники компанії витрачають
на виконання поставлених завдань. Та даний модуль може дозволити компанії
відмовитись від використання внутрішньої додаткової системи, до якої потрібно
вносити затрачений час на виконання кожної задачі. Це все полегшить роботу
керівництва та працівників компанії, оскільки потрібно використовувати лише
одну систему управління.
Програмне забезпечення по звітуванню проекту ProofHub дає чітке
представлення, як використовуються ресурси, про те, як реалізуються проекти
компанії, щоб була можливість позбутися найменш ефективних проектів. Такий
модуль є одним із функціональних вимог до розроблюваної системи – тому даний
програмний продукт не повністю задовольняє основні вимоги до функціоналу.
Даний елемент робить можливим, за допомогою плагінів, виводити дані по
реалізованим проектам та працівникам що працюють над проектами, але це не
дозволяє виводити весь список працівників, які зараз найменш навантажені
роботою ніж інші.
Зробивши аналіз аналогічних ПП, слід зазначити, що жоден програмний
продукт не може в повній мірі покрити всі вимоги до необхідної інформаційної
системи управління, особливо необхідно взяти до уваги, головну специфіку роботи
даної компанії, та як наслідок – і всі її робочі процеси діяльності.
Висновки до розділу 1
Актуальність розробки такої системи обумовлена неможливістю задоволення
всіх вимог від замовника уже відомими на ринку програмними продуктами –
потрібно аналізувати робочі задачі. Потрібно підвищити швидкість контролю
процесів, та зменшити кількість можливих ризиків що пов’язані з плануванням
навантаження як окремого працівника так і всієї команди.
21
Головною метою цього дослідження є розробка інформаційної системи
аналізу та розподілу основних робочих задач, що буде мати деякі інтеграції із
існуючими системами «JIRA» і «TimeTracker». За допомогою розробленої частини
даного проекту, буде також можливість для керування системою та можливість
перегляду готових результатів виконання розподілу задач проекту та їх аналізу
відповідно.
22
2 ПОСТАНОВКА ЗАДАЧІ РОЗРОБКИ ТА МЕТОДИ ДОСЛІДЖЕННЯ
2.1 Мета та задачі дослідження
Метою кваліфікаційної роботи бакалавра є проектування та розробка
інформаційної системи управління та збору інформації про виконані задачі, аналізу
їхньої складності, формування етапів для нових задач, визначення можливих
виконавців та створення команд.
Для досягнення поставленої мети в даній роботі розв’язувались наступні
задачі:
– збір інформації та аналіз області застосування (структури та діяльності
компанії) – аналіз бізнес-процесів та робочих процесів компанії. Визначення
основних етапів, які можуть бути автоматизовані за допомогою інформаційної
системи проектів;
– дослідження підходів, методів та технологій розробки необхідної
інформаційної системи, а також стеку технологій для створення web-інтерфейсу;
– розробка функціоналу для збору та аналізу даних стосовно нових
надісланих задач на нову розробку ПЗ;
– моделювання бізнес-процесів компанії «Andersenlab», та процес
розподілу робочих задач, та розробка моделей тих процесів, що будуть проходити
під час застосування web-системи;
– розробка функціоналу для збору даних відносно поточних задач
працівників, їхніх відпусток, що власне дозволить розподіляти всі задачі серед
команди розробників на основі сформованого деякого числового опису обраної
задачі та завантаження програміста.
Дана інформаційна система обробки та розподілу завдань дозволить легко
визначати, які параметри є важливішими в даний момент часу для визначення
працівників, від цього в свою чергу, буде залежати результат якісного виконання.
Інформаційна система обробки завдань буде використовуватись для поверхневого
огляду та аналізу нових задач на розробку системи, визначення менш завантажених
працівників, що можуть виконати нове поставлене завдання на розробку.
23
Інтерфейс програми може допомогти людині, яка займається розподілом
задач між розробниками, отримати всю необхідну інформацію стосовно потрібного
працівника та нового сформованого замовлення, а також отримати необхідні дані
по завантаженню працівника відносно команди розробників, а також перевести
замовлення розробки коду на потрібного кваліфікованого розробника не
використовуючи систему «Jira» що використовується компанією.
2.2 Методи дослідження
Існує багато різних методів дослідження на сьогодні. Але всі вони мають
також різну популярність. Якщо базуватись власне на спостереженні то була
створена досить проста схема для проходження задач, яка представлена на рис.2.1.
Нова задача в J ira
Створена заява
Реєстрація заяви в
даній системі
Задача з системи
Розгляд у Head Of
Operations
Погоджена заява
Зміна статусу заявки
Назначена задача
Задача у виконавця
Визначена складність
Розрахований
дедлайн
Виконання задачі
Повідомлення замовника
Завершення роботи
Рисунок 2.1 – Базовий життєвий цикл будь-якої задачі
Визначено експериментально, що переміщення від процесів вище по всьому
життєву циклу значно спрощує весь робочий процес для працівників компанії, а
24
також дає деяку можливість скоротити час необхідний на виконання поставленого
завдання, оскільки той час який працівник витрачає на повний аналіз задачі
розробки та визначення складності системи може бути дещо автоматизований.
На основі сформованих вимог від замовника інформаційної системи були
проаналізовані всі можливі доступні інструментарії та застосовані підходи до їх
реалізації. Розглядаючи даний процес розробки, виявлено, що він є не ідеальним
для даної сфери діяльності компанії, оскільки лише два процеси: визначення
складності та розрахунку потрібного дедлайну вже створюють низку ризиків та
також можуть викликати деякі проблеми в роботі компанії.
2.2.1. Вибір підходу реалізації аналізу задач. Дана задача для аналізу
системи полягає у визначенні деякої складності нового створеного запиту на
розробку системи ПЗ. Для того щоб отримати деяке числове представлення даної
складності системи визначаємо основні ключові показники, що впливають на
складність проектного замовлення:
– складність проекту;
– терміновість;
– технологія виконання такого замовлення;
– час на виконання замовлення;
– середня складність всіх пакетів застосованих для даного проекту;
– складності вже виконаних схожих замовлень.
Всі ці показники в достатній мірі впливають на результуючу складність
готового проекту (рис.2.2).
25
Рисунок 2.2 – Схема показників складності готового проекту
Для вирішення поставленої задачі регресійний аналіз є найбільш підходящим
методом. Регресійний аналіз – це розділ статистики, який мітить в собі методи
аналізу залежності однієї змінної величини від статичної.
Та на відміну від кореляційного аналізу, в регресії не з'ясовується істотність
такого зв'язку, а шукають нові моделі цього зв'язку, для вираженої у функції
регресії.
В даному випадку регресійний аналіз використовується тоді коли
відношення між деякими змінними можуть бути виражені кількісно у виді
комбінації заданих змінних. Отримана таким чином комбінація може
використовуватися для передбачення нового значення, що може приймати цільова
(залежна) змінна, вона обчислюється в заданому наборі від значень вхідних
(незалежних) змінних.
Фондові ціни, наприклад, та розміри продаж, дуже складні для їхнього
передбачення, так як залежать від всього комплексу зв'язків множин змінних.
Необхідні комплексні методи для передбачення майбутніх значень.
Для вирішення такої задачі у найпростішому випадку використовуються
стандартна лінійна регресія. Та все ж, більшість реальних моделей не можуть
вирішитися за допомогою такої лінійної регресії.
26
Рівняння регресії – це функція, яка описує залежність середнього значення
ознаки від заданих значень аргументів.
Термін "регресія" (від лат. – "regression" – або ж відступ, повернення до чого-
небудь) введений англійським психологом Ф. Гальптоном і пов'язаний тільки зі
специфікою одного з перших і конкретних прикладів, в якому це поняття власне і
було використано.
Отриманий результат буде застосований при розподілі задач серед
працівників команди розробників. В такому випадку саме регресійний аналіз і буде
використовуватися для визначення основної можливої складності проекту.
Мета лінійної регресійної задачі полягає в тому, щоб передбачити значення
числової змінної, яка базується на деяких значеннях одного чи декількох чисельних
змінних предиката. Так наприклад, ви маєте можливість передбачити щорічний
дохід окремої людини на підставі рівня освіти, стажу років досвіду роботи та також
статі (чоловік = 0, чи жінка = 1).
Прогнозовані змінні зазвичай називаються незалежними змінними. А змінна
для передбачення зазвичай називається залежною змінною. Коли ж існує лише одна
змінна предиката, тоді техніку іноді називають простим лінійним регресом. Якщо
ж існують два чи більше змінних для прогнозу, то ця методика зазвичай
називається множинною чи ж багатоваріантною лінійною регресією. [18]
2.2.2. Вибір методології розподілу задач. Спостерігаючи швидкий та
динамічний розвиток штучного інтелекту, власне як інструменту для вирішення
задач та аналізу отриманих даних – саме таке машинне навчання і повинно
дозволити вирішувати поставлені задачі.
Провівши детальний аналіз можливих і доступних підходів для реалізації
штучного інтелекту були вибрані саме ті реалізації, які задовольняють всі
поставлені потреби системи:
– розподіл задач на групи;
– визначення потрібної групи об’єктів.
Серед всіх відомих видів машинного навчання були виділені деякі основні
для вирішення даної задачі:
27
– класифікація;
– кластерний аналіз;
– нечітка логіка.
Кластерний аналіз. При використанні саме кластерного аналізу дуже
важливо визначити, скільки ж в результаті цієї процедури повинно буде
побудовано кластерів.
Кластерний аналіз повинен виявити деякі локальні згущення об’єктів.
Кількість кластерів є визначеним параметром, який може ускладнити наший
алгоритм, якщо ж визначено, що даний параметр є невідомий і може значно
вплинути на якість отриманого результату.
Тож, алгоритми кластеризації зазвичай будуються саме, як спосіб перебору
набору кластерів і визначення його оптимального значення саме в процесі такого
перебору і включають п’ять основних кроків:
– Відбір вибірки для кластерного аналізу;
– Визначення ознак, для оцінки об’єктів вибірки;
– Обчислення значень тієї або іншої міри подібності між об’єктами;
– Застосування кластерного аналізу для створення груп з подібних
об’єктів;
– Перевірка результатів кластерного аналізу.
Сьогодні існує велика кількість методів для розбиття вхідної групи елементів
на групу невеликих об’єктів – кластери.
Методи такого кластерного аналізу дозволяють розв’язувати наступні задачі:
– побудова нових класифікацій для слабо вивчених явищ, коли необхідно
визначити наявність зв’язків усередині деякої сукупності та спробувати визначити
її структуру;
– проведення класифікаційного аналізу об’єктів разом з урахуванням
деяких ознак, що можуть відображати сутність та природу об’єктів. Розв’язок задач
веде до поглиблення отриманих знань про сукупність відомих об’єктів, які
піддаються даній класифікації;
28
– перевірка припущень про наявність певної структурної організації в
досліджуваній сукупності об’єктів – відбувається пошук структури та залежностей.
Ієрархічна кластеризація виконується при деякому послідовному об’єднанні
малих кластерів в більші або навпаки – розбиття від більших кластерів до менших.
Такі алгоритми кластерного аналізу створюють розбиття для всіх варіантів, на
відміну від неієрархічних.
Для вирішення даної поставленої задачі був якраз обраний неієрархічний
метод кластерного аналізу, вони мають за основу перед визначену кількість таких
кластерів (kmeans, PAM кластеризація), або використовують інші більш складні
алгоритми знаходження деякої кількості кластерів (карти Кохонена, CLOPE).
Методи ітерації заслуговують найбільшої уваги серед неієрархічних методів
кластеризації оскільки такі методи працюють за наступним алгоритмом:
– обчислюються нові центри кластерів; вони не замінюються на нові,
доти поки не будуть повністю переглянуті всі вхідні дані;
– вихідні дані розбиваються на визначену кількість кластерів та
обчислюються їх центри для кожного з цих кластерів;
– кожен об’єкт з початкових отриманих даних поміщується в певний
кластер з найближчим центром його тяжіння;
– кроки 2 і 3 повторюються, поки не перестануть змінюватись перебрані
кластери.
Загальну схему процесу роботи розглянутих ітеративних методів
представлено на рисунку 2.3.
Рисунок 2.3 – Загальна схема роботи розглянутих ітеративних методів
29
Ітеративні методи працюють безпосередньо з початковими, та вхідними
даними на відміну від ієрархічних методів використання кластерного аналізу, які
потребують деякого обчислення і збереження матриці схожості між об’єктами.
За допомогою даних методів є можливість обробляти великі обсяги даних.
Ітеративні методи виконують декілька можливих переглядів, ітерацій проходження
початкових даних і, вони нівелюють наслідки помилкової вихідної розбивки даних.
Розглянуті методи породжують кластери для одного рангу, і тому не можуть
бути частиною ієрархії. Ітеративні методи, зазвичай, не допускають перекриття
кластерів. Властивості таких методів групування можуть бути описані за
допомогою таких трьох основних чинників: вибір вихідної розбивки, тип ітерації і
статистичного критерію.
Всі такі параметри іноді можуть поєднуватись, вони утворюють алгоритми
відбору необхідних даних при визначенні оптимальної розбивки. Такі різні
комбінації всіх цих параметрів призводять до розробки нових методів, та
породжують різні результати при роботі з одними й тими ж даними [13].
Так як, кількість таких кластерів вже визначена то, всі неієрархічні методи
виявляють високу стійкість до шумів і викидів, некоректного вибору метрики, та
введення незначних змінних у набір, який бере участь в кластерному аналізі даних.
Метод k-найближчих сусідів. Вибираються об'єкти, саме до яких відстань
найменша, і тоді вони виділяються в окремий клас. Не параметричний
класифікаційний метод, для класифікації об'єктів в рамках простору деяких
властивостей використовуються відстані, прораховані до всіх інших таких об'єктів.
Такий алгоритм методу найближчих сусідів ґрунтується на порівнянні
відомих статистичних даних з новими елементами. Дана гіпотеза стверджує, що
різні відображення такого одного і того ж образу у просторі ознак породжують
геометрично близькі точки, утворюючи компактні ― згустки. Для нового запису,
продовження якого необхідно прогнозувати, знаходять найбільш подібні записи у
минулому та ідентифікують їх як найближчих сусідів. Метод найближчих сусідів
спирається на так звану ― гіпотезу компактності [16]. Умовою ефективного
застосування методу НС є вдалий вибір деяких наступних параметрів: вид метрики,
30
що служить для оцінки наближеності між об’єктами; кількість К найближчих
сусідів, які беруться до уваги при побудові прогнозу та розмірність навчальних
зразків паттернів. Вибір малого значення параметра К приведе до сильного розкиду
значень прогнозу; велике значення К може спричинити сильне зміщення моделі.
Прийняття рішень у проблемно-орієнтованих інформаційних системах та
системах керування здійснюється в умовах невизначеності, яка зумовлена
неточністю або неповнотою вхідних даних, природою зовнішніх впливів,
відсутністю адекватно сформованої математичної моделі функціонування,
нечіткістю мети, людським фактором тощо [17].
Щоб мінімізувати ймовірність ймовірної помилкової класифікації, дане
значення К повинно бути досить великим, і достатньо малим, щоб К близьких
сусідів розташувалися досить близько до точки запиту.
Нечітка логіка. Невизначеність даної системи призводить до зростання
ризиків що виникають від прийняття неефективних прийнятих рішень, ще до того,
як результатом можуть бути негативні технічні та соціальні, економічні, та інші
наслідки. У системах прийняття рішень невизначеність компенсують за допомогою
застосування різних методів для машинного навчання та використання штучного
інтелекту.
Для ефективного прийняття рішень в умовах невизначеності – для
коректного функціонування системи використовують методи які базуються на
основних правилах нечіткої логіки.
Теорія нечітких множин надає можливість застосувати для прийняття рішень
не формалізовані суб’єктивні експертні знання про дану предметну область [15].
Методи нечітких множин дуже корисні коли відсутні деякі точні математичні
моделі, ті які описують функціонування інформаційної системи.
Використання методів деяких нечітких множин можна вирішуючи різні
питання узгодження суперечливих критеріїв для прийняття рішень, та створення
логічних регуляторів схожих систем.
Методи нечітких множин є досить гарним засобом для необхідного
проектування інтерфейсів у людино машинних системах. На основі такого
31
нечіткого логічного виведення будуються системи керування, для підтримки
прийняття рішень, та подання знань, а також структурної та параметричної
ідентифікації, для розпізнавання образів.
Нечіткі експертні системи все більше знаходять широке застосування у
військовій справі, економіці для підтримки прийняття рішень, медицині. З їх
допомогою здійснюють зазвичай бізнес-прогнозування, оцінювання можливих
ризиків та прибутковості створюваних проектів [14,15].
Дані нечіткі множини застосовують основний лінгвістичний опис складних
процесів, та за допомогою встановлення нечітких відношень між деякими
поняттями, також можуть допомагати прогнозувати потрібну поведінку системи та
формувати множину проведених дій, та формально описати правила прийняття
рішень.
Отже, перспектива застосування нечіткої логіки в даній предметній області
полягає у розробленні нових гібридних методів, до яких також можна віднести
нечіткі штучні нейронні мережі, та постійне поповнення баз нечітких правил, що
дозволить реагувати на зміни в роботі робочого процесу ІТ компанії та постійно
додаючи нові правила організації роботи – постійно покращувати точність
отриманих результатів. [13 – 15].
Важливим застосуванням таких нечітких множин є контроль нечіткої логіки,
що використовується у системах керування. Замість використання математичної
моделі для опису інформаційної системи – контролери переважно використовують
знання основних експертів, які описуються за допомогою використання
лінгвістичних нечітких множин.
2.2.3. Вибір методології реалізації пошуку схожості замовлень. Часто
існують можливості наповнення схожих замовлень. Тож, основною проблемою
пошуку схожих проектів – є власне те, що інфраструктура ІТ компанії не дозволяє
отримувати повний список батьківських проектів, чи, взагалі, отримати залежності
між проектами. Оскільки підтримка функціоналу неможлива за допомогою
наявних інструментів ІТ компанії – слід підібрати бажаний підхід для знаходження
схожих проектів, у списку наявних тікетів, які були уже виконані та відправлені
32
замовнику і у нас є вся необхідна інформація для виявлення та знаходження таких
тікетів.
Кожен наступний тікет має свою назву ІТ компанії виробника програмного
забезпечення, а також власне саму назву програми. Отримавши всі ці вхідні дані
про проекти, та використовуючи алгоритми порівняння рядків, можна визначити
схожість того чи іншого виконаного та отриманого замовлення на нову розробку
програмного забезпечення.
Відстань Левенштейна. Це деяка певна міра відмінності між двома рядками
– з двох символьних послідовностей. Даний алгоритм може обчислювати
мінімальну кількість операцій встановлення, видалення чи заміни саме для того
щоб змінити одну з послідовностей символів до іншої.
Розрахунок даної відстані відбувається через простий алгоритм, в якому
використовується наступна матриця, що має розмір заданий формулою:
(2.1).
де n, m – довжини першого та другого рядка.
В представленому даному алгоритмі, всі операції (встановлення, вилучення,
заміни) мають однакову вартість.
Для відстані Левенштейна існують верхня і нижня межі:
– Дистанція Левеншнтейна не менша ніж різниця довжини рядків, які
порівнюються;
– Вона дорівнює 0 тоді і тільки тоді, коли всі рядки однакові (однакові
символи і знаходяться на однакових позиціях);
– Вона може бути не більша довжини самого довгого рядка.
Між відстанню Левенштайна та відстанню Гемінга існують взаємозв'язки:
– рядки різної довжини, то верхньою межею є сама відстань Гемінга
плюс різниця довжини цих рядків;
– рядки однакової довжини то відстань Левенштайна рівна відстані
Гемінга.
33
Відстань Дамерау (Левенштейна). Такий алгоритм є деякою модифікацією
попереднього, але все ж з врахуванням додаткової операції – транспозиції – тобто
перестановки двох сусідніх символів в певні послідовності.
В приблизній відповідності між рядками мета полягає саме в тому, щоб
знайти деякі можливі збіги для коротких рядків у багатьох довгих текстах, і в
деяких ситуаціях, коли очікується невелика кількість відмінностей. Наприклад,
коли короткі рядки можуть надходити зі словника. Тут один з вибраних рядків
зазвичай коротший, а інший довший. Це має поширений широкий спектр різних
додатків, наприклад, такий як перевірка орфографії, різні системи виправлення
оптичного розпізнавання перевірки символів та програмне забезпечення для
сприяння перекладу природної мови на основі пам'яті перекладу.
Таким чином, коли використовуються для пошуку нечітких рядків у таких
програмах, як записування, порівняні рядки зазвичай досить короткі, щоб
допомогти покращити швидкість паралельного порівняння. А відстань
Левенштейна також може бути обчислена між двома найдовшими рядками. Але
вартість такого обчислення, приблизно пропорційна добутку двох довжин строки,
робить це досить непрактичним.
Алгоритм Джаро-Вінклера. В статистиці та комп'ютерних науках відстань
Джаро-Вінклера – це деяка визначена метрика рядків, яка вимірює відстань між
двома сусідніми послідовностями.
Відстань Джаро-Вінклера зазвичай використовує певний масштаб префікса
p, це дає більш сприятливі рейтингові виміри для рядків, які співпадають з самого
початку порівнянь для встановленої довжини префікса.
Джаро-Вінклер вираховує схожість між двома рядками, а повернене значення
майже завжди лежить в інтервалі [0.0, 1.0]. Це варіація Дамерау – Левенштейна, де
можливе заміщення двох близьких один до одного символів вважається менш
важливим, ніж заміщення 2 символів що знаходяться далеко один від одного.
Тож, чим нижче розташована відстань Джаро-Вінклера для двох суміжних
рядків, тим більше схожих рядків буде знайдено. Оцінка в даному випадку
34
нормується таким чином, що 1 прирівнюється до подібності і 0 – це точний збіг.
Схожості Джаро-Вінклера дає 1-відстань Джаро-Вінклер.
Часто називають метрикою деякі відстані, відстань Джаро-Вінклера не є
метрикою в математичному значенні даного терміну, так як вона не підкоряється
нерівності створеного трикутника.
Даний алгоритм використовують при переписі населення.
Найдовша спільна підпослідовність. Проблема пошуку найдовшої спільної
підпослідовності (LCS) полягає саме у знаходженні найдовшої послідовності,
загальної для двох чи більше послідовностей. Якщо видалити з деякої кінцевої
послідовності безліч її елементів можуть бути порожніми, то таким чином можна
отримати нову послідовність.
Так, BCDB є підпослідовність послідовності ABCDBAB. Можемо вважати,
що послідовність Z є спільною підпослідовністю послідовностей X і Y, якщо Z є
підпослідовність як X, так і Y. Потрібно для двох деяких послідовностей X і Y
знайти спільну підпослідовність з найбільшої довжини.
Представлений алгоритм використовується відомою утилітою diff, за
допомогою Git саме для узгодження кількох змін.
Деяка відстань LCS еквівалентна можливій дистанції Левенштейна, тоді коли
допускається лише вставка чи видалення та коли вартість заміщення є подвійною
вартістю таких вставки або видалення.
Після перегляду даних алгоритмів, було вирішено те що саме алгоритм
Джаро Вінклера буде використаний в нашій роботі для пошуку схожих задач,
оскільки він дозволяє однозначно визначати необхідні відношення двох різних
рядків (наприклад, назв програмного забезпечення) при досить низьких затратах
серверних ресурсів на визначення таких залежностей.
2.2.4. Вибір технологій реалізації інформаційної системи. У розробників
web-додатків на сьогоднішній день є досить великий вибір стосовно того, які саме
методи, та мови програмування і технології використовувати для проектування та
створення сайту. Існує багато різних варіантів: PHP, ASP.NET, JSP, Python,Node.js
та багато інших мов. Найпоширенішими технологіями на сьогодні є PHP і
35
ASP.NET, та Python. Зважаючи, що дана ІС буде використовуватися ІТ компанією
«Andersenlab» то інструментарій підбираємо у відповідності з вимогами замовника,
застосованими інструментами розробки та використання в даній компанії.
Для реалізації такої інформаційної системи ми виберемо ASP.NET Core з
архітектурою системи MVC.
Даний патерн MVC, вбудований у функціонал використання серверної
технології ASP.NET, та саме він був обраний на основі вимоги замовника і
представляє собою сформовану схему розділення основної логіки даного додатку,
та графічного представлення даних, під наступною назвою «Model – View –
Controller». Технологія ASP.NET MVC є фреймворком, що призваний полегшити
застосування деяких основних принципів патерну MVC та для розділення
відповідальності між розробниками за графічний інтерфейс, бази даних та обробки
даних серед трьох головних компонентів: Моделей, Представлень (окремі частини
графічного інтерфейсу web-додатку) та Контролерів (відповідає за логіку обробки
та управління даними web-додатку).
Принцип роботи web-додатку за вже відомим патерном MVC що
представлений на рис. 2.4.
Рисунок 2.4 – Схема розділення web-додатку за даним патерном MVC
Таке використання використаного фреймворку дозволить в подальшому
вбудувати дану інформаційну систему обліку та розподілу замовлень в існуючий
інструментарій керування.
36
ASP.NET Core – це веб-структура, що оптимізована для роботи з хмаркою та
відкритим кодом, для розробки сучасних на сьогодні веб-додатків, які можуть
конкурувати та бути розроблені для роботи на Linux, ОС Windows та Mac. Вона
включає в себе існуючу структуру MVC, яка тепер поєднує функції MVC та Web
API в єдину систему розробки веб-програмування.
ASP.NET Core – це нова веб-структура від компанії Microsoft. Не так давно
він був перероблений з нуля, щоб бути швидшим, більш гнучким, та сучасним і
можливість працювати на різних доступних платформах. ASP.NET Core – це
система, яка можна використовувати для розробки веб-сторінок повязаних з .NET.
Він складається з модульних компонентів та з мінімальними накладними
витратами, тому ви зберігаєте необхідну гнучкість при побудові важливих рішень.
Головні додатки ASP.NET можуть також запускатися і на .NET Core або ж на
повній його платформі .NET Framework.
Додатки ASP.NET Core можна запускати на різних платформах Linux
Windows та MacOS.
Він був спеціально розроблений якраз для можливості забезпечення
оптимізованої структури з розробки новітніх додатків, які розгортаються як в хмарі
так і запускаються на місцевому рівні.
ASP.NET Core має наступні представлені переваги:
– Переваги меншої площі використання поверхні додатків включають
досить жорстку безпеку, для зменшення обслуговування, підвищення
продуктивності та зниження витрат.
– ASP.NET Core має цілий ряд архітектурних змін, що призводять до
створення значно меншої та модульної структури.
– Має новий інструмент, що спрощує розробку нових Web.
– ASP.NET Core більше не базується на System.Web.dll. Він заснований
на наборі пакетів NuGet.
– Має обладнане середовище конфігурації.
– Вбудована підтримка ін'єкцій залежності HTML.
37
– Створення та запуск крос-платформних додатків ASP.NET на Windows,
MacOS та Linux.
– Веб-стек з єдиним виділеним інтерфейсом для веб-інтерфейсу.
– Можливість хостингу в IIS або на самостійному хості як у вашому
власному Tag Helpers, що робить розмітку Razor більш натуральною за допомогою
процесів.
Для реалізації алгоритму пошуку та визначення можливих виконавців, на
даному етапі, існує багато мов програмування, IDE для розробки та різних
фреймворків. Такі як: Matlab, R, Java, Python, LISP, Prolog тощо. Так як обрана мова
програмування основної частини явно С#, то слід відштовхуватися саме від цього.
Є безліч інтеграцій різних модулів між існуючими мовами програмування, але саме
така система й потребує більш обширних знань в тих мовах програмування як і
знань інтеграції подібних «підпрограм». Важко підтримувати таку систему та з
годом модернізувати.
Microsoft Visual Studio – середовище для розробки інформаційної системи –
середовище розробки програмного забезпечення та безліч додаткових додатків, які
розширяють функціонал середовища. Вони дозволяють розробляти: програми з
графічним інтерфейсом (тобто з підтримкою поширеної технології Windows
Forms), консольні програми а також веб-системи та веб-сайти як в рідному, так і в
керованому кодах для використання всіх платформ, які підтримуються компанією
Microsoft Windows.
2.2.5. Вибір технологій збереження інформації. Вибір методу а тим паче
метод та технологій збереження є досить важливим рішенням, оскільки доступ до
даних повинен бути достатньо швидким, та досить надійним. Сьогодні, існує багато
різних СУБД та методів для зберігання та організації даних на носії інформації.
MySql. MySQL – це система управління реляційною базою даних з відкритим
кодом, вона захищена компанією Oracle на основі мови Structured Query Language
(SQL). MySQL ефективно працює практично на всіх можливих платформах,
включаючи Linux, UNIX та Windows. Вона може звісно користовуватися в досить
широкому діапазоні можливих застосувань, MySQL найчастіше асоціюється з web-
38
додатками та онлайн-публікаціями. MySQL є важливим компонентом стекового
середовища з відкритим кодом під назвою LAMP.
LAMP – це платформа для web-розробки, яка використовує Linux як
операційну систему, а Apache як web-сервер, MySQL як систему управління
реляційною базою даних, а також PHP як об'єктно-орієнтовану мову для різних
сценаріїв. (Іноді буває замість PHP використовується Perl або ж Python).
На сьогодні MySQL є СУБД на більшості провідних web-сайтах у всьому
світі та незліченних месенджерах, споживчих та корпоративних веб-додатків,
включаючи Twitter, Facebook та YouTube.
MySQL базується на основній моделі клієнт-сервер. Ядро MySQL – це сервер
MySQL, який обробляє всі можливі інструкції (або команди) бази даних. Сервер
MySQL доступний як окрема програмка для застосування в мережевому
середовищі клієнт-сервер та як окрема бібліотека, яку можна використовувати та
вбудувати (або зв'язати) в окремі створювані додатки.
MySQL працює поряд з кількома утилітними програмами, які підтримують
адміністрування баз даних MySQL. Команди надсилаються до MySQLServer через
клієнт MySQL, який встановлюється на комп'ютері.
MySQL був спочатку розроблений для швидкої обробки великих баз даних.
Хоча MySQL зазвичай встановлюється лише на одній машині, він може надсилати
базу даних у декілька розташувань, оскільки користувачі можуть отримати доступ
до нього за допомогою різних клієнтських інтерфейсів MySQL. Ці інтерфейси
надсилають SQL-заяви на сервер, а потім відображають результати.
SQL Server. Microsoft SQL Server – це система управління реляційною базою
даних, або ж ще RDBMS, яка підтримує досить широке коло для обробки
транзакцій. Як і завжди програмне забезпечення RDBMS, від Microsoft SQL Server
побудований на вершині SQL, такої стандартизованої мови програмування, яку
адміністратори баз даних (DBA) та інші спеціалісти з інформаційних технологій
використовують саме для управління базами даних та можливості запиту даних, які
вони містять. SQL Server прив'язаний до Transact-SQL (T-SQL), реалізація SQL з
Microsoft, яка додає набір власних програмних розширень на стандартну мову.
39
Визначення бізнес-аналітики та використання різних аналітичних додатків в
корпоративних середовищах наших ІТ компаній. Це одна з відомих трьох
провідних технологій створення баз даних, а також Oracle Database та IBM DB2.
Microsoft SQL Server 2019, став загальнодоступним вже у червні 2019 року,
був розроблений як частина "технології першої технології", яка була прийнята
корпорацією Microsoft два роки тому. Серед іншого, SQL Server 2019 додав нові
функції для налаштування продуктивності, оперативної аналітики в режимі
реального часу та візуалізації даних і надав можливість звітування і на мобільних
пристроях, а також підтримку гібридної підтримки хмар, що дозволить базам даних
DBA запускати певну комбінацію локальних інформаційних систем у
загальнодоступних хмарних служб зменшити витрати на ІТ. Така технологія як
SQL Server Stretch Database переміщує доступні дані з локальних пристроїв
зберігання до доступного хмарного пакета Microsoft Azure, та зберігаючи при
необхідності дані для створення запитів.
Sqlite. SQLite – рантайм-бібліотека, яка реалізує автономну, безсерверну,
конфігурацію баз даних SQL.
SQLite – вбудований двигун на базі даних SQL. На відміну від основної
більшості інших створених баз даних SQL, SQLite не має ніяких окремих серверних
процесів. SQLite читає та пише безпосередньо до звичайних файлів. Формат файлу
бази даних є крос-платформою – ви можете вільно копіювати базу даних між 32-
бітними та 64-бітними системами або між великими і менш-кінцевими
архітектурами. Повна база даних SQL з декількома таблицями, індексами,
активаторами та представленнями міститься в одному файлі диска. Ці особливості
роблять SQLite популярним вибором як формат файлу додатків. Файли бази даних
SQLite є рекомендованим форматом зберігання бібліотеки Конгресу США.
SQLite є загальнодоступним і, таким чином, безкоштовним для використання
для будь-яких цілей, комерційних або приватних. SQLite – це найпоширеніша в
світі база даних з великою кількістю додатків.
SQLite використовує динамічні типи для таблиць. Це означає, що можна
зберігати будь-яке значення в будь-якому стовпці, незалежно від типу даних.
40
SQLite – це компактна бібліотека. Якщо увімкнено всі функції, розмір
бібліотеки може бути меншим за 600 Кб, залежно від цільової платформи та
параметрів оптимізації компілятора. (64-розрядний код більший. І деякі
оптимізаційні комбінатори, такі як агресивна функція inlining та розгортання
циклу, можуть призвести до значного збільшення об'єктного коду.)
SQLite дозволяє єдиному підключенню бази даних одночасно отримувати
доступ до декількох файлів бази даних. Це приносить багато приємних функцій,
таких як приєднання таблиць до різних баз даних або копіювання даних між базами
даних в одній команді. SQLite здатний створювати бази даних у пам'яті, які дуже
швидко працюють.
SQLite дуже ретельно тестується перед кожним релізом і має репутацію дуже
надійного додатку. Автоматизований набір тестів містить мільйони і мільйони
тестів, що включають сотні мільйонів окремих SQL-повідомлень, і забезпечує
100% охоплення тесту. SQLite чудово реагує на помилки виділення пам'яті та
помилки введення / виведення диска.
Рисунок 2.5 – Приклад роботи БД Sqlite
SQLite – це автономна система, що вимагає мінімальної підтримки
операційної системи або зовнішньої бібліотеки. Це робить SQLite доступним у
будь-яких середовищах, особливо в вбудованих пристроях, таких як iPhone,
Android телефони, ігрові приставки, портативні медіапрогравачі тощо.
Висновки до розділу 2
Проаналізувавши наявні СУБД та можливі підходи, оцінивши всі основні
переваги та можливі недоліки кожного з підходів – SQLite є найбільш підходящою
БД, так як дозволяє зберігати дані у окремому файлі (це зручно) без встановлення
41
додаткових серверів з підтримки бази даних. Це може дозволить працювати системі
значно швидше, і враховуючи невеликий об’єм даних, який буде зберігати
спроектована БД.
42
3 МОДЕЛЮВАННЯ ІНФОРМАЦІЙНОЇ СИСТЕМИ
Моделювання інформаційної системи аналізу та розподілу робочих завдань
для команд компанії «Andersenlab» проводилось на основі виконаного аналізу
діяльності всієї компанії в цілому, а також процесу розподілу задач між задіяною
командою програмістів розробників, які були описані в попередньому розділі 1.
Інформаційна система – це певна сукупність різних організаційних і
технічних засобів, як організаційних так і технічних, які дозволяють зберігати та
обробляти різну інформацію з метою забезпечення різноманітних потреб
користувачів.
3.1 Побудова контекстної діаграми в нотації IDEF0
Методологія IDEF0 застосовується переважно в ІТ галузях, як досить
ефективний засіб проведення аналізу, проектування та представлення бізнес
процесів. Основною важливою одиницею IDEF0-моделі є діаграма – графічний
опис моделі предметної області та або її частини. Головними такими компонентами
IDEF0-діаграми є блоки, які власне відображають переважно роботи, завдання,
процеси, різні функції тощо.
У кожної сторони такого структурного блоку є особливе своє призначення,
яке так чи інакше впливає на проведені процеси:
– верхня – управління процесами, основні елементи, які впливають на
вихідний очікуваний результат;
– ліва сторона – вхід;
– права сторона – вихід, отриманий результат;
– нижня – механізми процесу;
Вони всі, зазвичай, виконуються протягом деякого певного часу та завжди
мають, відповідно, деякий результат.
Основною задачею створюваної інформаційної системи є – визначення
декількох можливих виконавців для відповідної нової задачі, які дозволяють
задовольнити параметри, через які йде весь опис завантаженості працівника.
43
Відповідно до представленого методу IDEF0 для будь-якої роботи необхідно
визначити управління і механізм, які зображуються на діаграмі стрілками, вхідні
дані, вихідні дані.
Тож для даної ІС та процесу розподілу задач визначаємо наступні параметри:
– Вхідні дані: необхідність автоматизації документообігу.
– Управління: нормативні документи та ТЗ підсистеми.
– Механізми: технічне та програмне забезпечення.
– Вихідні дані: документація, створена система.
Таким чином, контекстна створена діаграма містить основний блок
«Моделювання процесу проектування та розробки програмного забезпечення у
межах компанії – Andersenlab».
Вона має рівень A0. Він є найвищим можливим рівнем абстракції для даного
завдання.
Основною точкою зору була взята зібрана точка зору голови відділу розробки
програм компанії «Andersenlab», а також було визначено головну мету – аналіз
роботи відділу розробки програм.
Контекстна діаграма представлена на рис. 3.1.
Рисунок 3.1 – Контекстна діаграма процесу відбору виконавця у IDEF0
44
Рисунок 3.2 – Діаграма декомпозиції процесу вибору виконавця у IDEF0
3.2 Побудова моделі прецедентів
За методологію створення інформаційних систем було обрано метод
використання UML-діаграм, він дозволяє досить стисло та легко визначати
особливості роботи при проектуванні та розробці замовленої інформаційної
системи у візуальному вигляді.
В той час, як головні вимоги до розробки можуть бути представлені власне у
вигляді списків, таблиць та інших стандартних засобів проектної документації, то
інформаційна система аналізу та розподілу робочих завдань працівникам компанії,
а також її основний визначений функціонал та використання, що може бути
представлено за допомогою UML-діаграми.
Основна мета такої діаграми – система представляється у вигляді безлічі
акторів та сутностей, які завжди взаємодіють із системою за допомогою деяких
визначених варіантів використання.
Варіант використання (від англ. use case) – це опис деяких функцій чи
можливих послуг, які система сама надає програмісту. Кожен варіант використання
має на увазі деякий набір дій, який виконує система при взаємодії з програмістом.
При цьому реалізація цих дій часто не описується.
У ролі основного користувача системи можуть виступати представники
керівництва компанії «Andersenlab», об’єднані в одного користувача під назвою
45
«Керівництво компанії». Він може використовувати користувацький інтерфейс як
систему доступу до ІС, а саме:
– переглядати інформацію та робити можливу оцінку можливих затрат
часу для того чи іншого замовлення на розробку ПЗ, базуючись уже на існуючих
отриманих даних по схожим замовленням;
– обирати та назначати замовлення на нову розробку ПЗ для обраного
працівника.
– переглядати список проектів в роботі компанії з визначеними
працівниками для певного проекту;
– переглядати поточне навантаження кожного працівника.
Також до такої моделі прецедентів входять такі працівники, як
«Адміністратор системи» та «Інженер технічної підтримки». Обов’язками
адміністратора є власне сама підтримка системи. Інженер технічної підтримки
переважно займається удосконаленням веб-інтерфейсу за висунутими вимогами
користувачів системи.
Основні варіанти використання інформаційної системи описані на рис. 3.3.
Рисунок 3.3 – Модель прецедентів проекту створення нової інформаційної
системи
46
3.3 Моделювання системи
Виходячи з деяких відомих сформованих функціональних вимог та від
поставлених задач від керівництва компанії, після проведеного аналізу всієї
діяльності ІТ компанії, а також від власне процесу розподілу задач та під задач між
працівниками команди з розробників ПЗ – така модель створюваної системи
набуває досить специфічного характеру, котрий завжди повинен задовільнити
практично всі потреби що можуть виникати під час роботи.
Проводиться збір основних метаданих для створення макету організаційної
роботи системи. Модель даних – це деякий абстрактний опис певних об’єктів
реального світу, які входять до заданої та обраної предметної області для будь-якої
системи що розробляється [24].
Дані зберігаються в окремих ―тікетах (тобто сторінках замовлень з розробки
ПЗ) проектів та пакетів, і будуть заноситися до створеної бази даних за допомогою
додаткового програмного модулю з синхронізації даних.
У такому випадку із розробкою ІС для ІТ-компанії «Andersenlab», основними
джерелами інформації служать 3 необхідні системи: «JIRA, та два внутрішні
продукти – «TimeTracker» для введення та подальшого моніторингу затраченого
працівниками на розробку ПЗ використаного часу, власне сама база даних для веб-
системи «Andersenlab Intranet».
Продукт «TimeTracker» через окремий API надає можливість для отримання
даних про занесений часу розробки окремого замовлення проекту ПЗ, та дізнатися
дані із усього часу, занесеного на розробку ПЗ лише одним спеціалістом за місяць.
Продукт «JIRA» включає в себе дані про проекти та пакети ПЗ, що можуть
перебувати у різних статусах – від замовлення проекту (тобто заявка на який тільки
поступила у систему, та сам процес розробки ще не розпочатий) до затверджено
замовником (означає, що пакет ПЗ пройшов внутрішнє та зовнішнє проведене
тестування і вже затверджений цим клієнтом).
Таким чином є можливість зберегти дані про витрачену кількість часу, що
розробник ПЗ витратив на виконання того чи іншого замовлення на цю розробку,
47
що буде використане для визначення нових замовлень та можливі витрати часу
базуючись на вже розроблених та відправлених схожих замовленнях на розробку.
3.3.1. Критерії оцінювання навантаження працівника. Кожен працівник
весь час має певну кількість поточних робочих задач, які можна описати за
допомогою деяких критеріїв, які, в свою чергу, впливають на її складність, час до
дедлайну тощо. Дані критерії задач були визначені в першому розділі.
Але, крім самих критеріїв задачі є критерії власне працівника, які теж повинні
бути враховані під час процесу всього розподілу робочих задач. Серед них можна
виділити основні наступні критерії:
– доступність працівника (чи знаходиться він/вона зараз у відпустці);
– попередній виконавець (чи виконував він уже схожу задачу).
Якщо зважати на специфіку діяльності, то критерій попереднього виконавця
задачі може зіграти значну роль у виконанні наступної задачі, оскільки працівник
вже отримав досвід про розробку того чи іншого soft, та повинен впоратись з
виконанням задачі, як показує практика, набагато швидше. Визначивши дані
критерії, потрібно привести їх у деякий відповідний вигляд, для чіткого розуміння
як самою людиною так і розроблюваної програми. Опис критеріїв представлений у
таблиці 3.1.
Таблиця 3.1 – Критерії оцінки підбирання працівників
Група критерію Критерій Тип даних Діапазон
Критерії задачі Час double [0,10]
Пріорітет double [0,10]
Статус double [0,10]
К-сть задач double [0,10]
Категорія double [0,10]
Критерії Днів до відпустки int [0,10]
працівника Попередній boolean [0,10]
виконавець
Навантаження double [0,10]
48
Дані критерії приведені до однакових одиниць виміру, оскільки
використання різних діапазонів можливих значень може призвести до некоректної
роботи системи та, і як наслідок отримання викидів в результатах під час обробки
не валідних об’єктів.
Описані вище критерії мають ваги важливості, що і дозволяє, змінювавши їх,
визначати більш важливий критерій в той чи інший момент часу.
Тому, приведення діапазонів можливих значень до однакового масштабу
дозволить максимально мінімізувати можливість в подальшому виникнення таких
ситуацій.
Необхідно проводити математичні операції з даними для отримання
числового представлення критеріїв. Тож для визначення часового критерію була
використана наступна формула:
(3.1).
Даний критерій розраховується для кожного програміста наступним чином –
для кожного поточного описаного завдання працівника визначається відношення
витраченого часу до повного затраченого часу на задачу. В результаті отримуємо
суму таких відношень для кожної виконаної задачі.
Наступним критерієм є пріоритет виконання. Формула обчислення для
програміста наведена нижче.
(3.2).
В даній формулі – Priority Rate – це деяке статичне число, яке визначається
для кожного пріоритету, який вже є в системі «Jira». Для працівника – сума таких
чисел для кожного із його поточних завдань по проекту.
Наступним критерієм є статус. Формула обчислення для програміста
представлена нижче.
(3.3).
49
В даній формулі – StatusRate – це статичне число, яке визначається для
кожного статус тікета, який вже є в системі «Jira». Для працівника – сума таких
чисел для кожного із його поточних завдань проекту.
Наступним можливим критерієм є кількість поставлених задач. Формула
обчислення для програміста наведена нижче.
(3.4).
Приведено в даній формулі – – це саме відношення кількості
поточних задач працівника до середньої кількості поставлених задач, що має
виконати розробник.
Наступним критерієм є статус. Формула обчислення для програміста
представлена нижче.
(3.5).
Приведено в даній формулі – CategoryRate – це вже статичне число, яке
визначається для кожної категорії тікета, який вже наявний в системі «Jira». Для
окремого працівника – сума таких чисел для кожного із його поточних завдань.
Дні що до відпустки – це такий критерій, який визначається для кожного
окремого працівника, на основі отриманих даних які були надані із зовнішньої
системи трекінга відпусток працівників компанії. Завдяки такій інтеграції, можна
чітко знати інтервали всіх відпусток працівників, та уникати можливих випадків,
коли система буде рекомендувати людей, які фізично знаходяться поза офісом і не
можуть приймати участь в проекті.
При умові, що у програміста залишається до відпустки днів менше чим
чотири, то даний розробник вже не буде рекомендуватися системою, оскільки,
зважаючи на досвід роботи нашої компанії, буде малоймовірно, що цей працівник
встигне завершити поставлені нові задачі за такий короткий проміжок часу.
Попередній виконавець – це критерій, який визначається на основі вже
виконаних завдань з розробки конкретним працівником. Такий критерій є булевим,
так як конкретний працівник або ж виконував схожі завдання або ні.
50
Даний параметр буде визначатися за наступними формулами – порівнюючи
схожість рядків:
(3.6).
Наведено в даній формулі – довжина рядка S , m – число співпавших
символів.
1
(3.7).
Даний підхід відомий як алгоритм Джаро-Вінклера, який дозволяє визначити
схожість двох вхідних рядків. Неформально, відстань Джаро між двома словами –
це мінімальна кількість одно символьних перетворень, яка необхідна для того, щоб
змінити одне слово в іншому.
Навантаження працівника – це відношення кількості витраченого часу
працівником за певний період часу до середнього даного показника по команді
розробників. Власне даний параметр дозволяє визначити, чи був конкретний
працівник перенавантажений протягом поточного періоду, чи він був
навантажений значно менше ніж вся команда.
(3.8).
3.3.2. Моделювання процесу підбору виконавців проекту. На основі
порівняння алгоритмів та проведеного аналізу вибір був зроблений на користь
стандартного кластерного аналізу на основі K-means. K-means – цей метод
машинного навчання дозволяє визначати працівників, які точно можуть
виконувати ту чи іншу поставлену їм задачу базуючись на критеріях що описані
вище.
На основі кластерного аналізу досить важливу роль відіграє алгоритм з
визначення належності деякого елементу до того чи іншого зазначеного кластеру.
Зазвичай, у представленому класичному кластерному аналізі K-Means
використовують визачені відстані від (центроїда) до елемента за допомогою
Евклідової відстані.
51
(3.9).
Де, p та q критерії описані у відповідному розділі. Зважаючи, на дану
специфіку конкретної задачі та кількість зазначених параметрів опису працівника
– формула має бути дещо змінена. Давайте додамо вагу нового елементу, як
множник до результату.
(3.10).
Після формування всіх кластерів, використавши дану описану формулу –
визначаємо «найближчий» кластер до «ідеального» елементу (зважаючи на
критерії).
Отже, додавши, даний множник, ми даємо знати системі, який саме критерій
є більш важливішим в даний момент часу.
3.3.3. Моделювання аналізу задачі. Якщо розглядати той випадок, коли
інформаційна система вже знайшла в нашій базі даних схожі проекти, які вже були
виконані та відправлені до замовника – проводиться додатковий аналіз нової
отриманої задачі на основі вже минулих задач виконання.
Такий процес повинен бути досить простим, але все ж повинен давати деякий
поверхневий аналіз нової задачі. Очікується, що ця система може врахувати
можливу складність проекту – цей параметр є досить суб’єктивним, так як кожне
виконане чи наступне замовлення має безліч можливих конфігурацій, які можуть
впливати на заключну складність проекту.
Тож, для визначення можливої складності задачі використаємо формулу:
(3.11).
Так, за допомогою даної формули – середнього значення складності проектів,
будемо визначати можливі витрати часу на даний проект.
52
Для реалізації даного функціоналу буде використаний – лінійний регресійний
аналіз, який власне дозволяє прогнозувати один з невідомих параметрів на основі
(значення середньої складності) деякого відомого.
Загалом лінійна регресійна модель визначається та представлена у виді:
(3.12).
де х – незалежні змінні, и – випадкова похибка, y – залежна пояснювана
змінна.
Тож, відповідно до даної моделі, що описана вище – математичне сподівання
для кожної залежної змінної – це лінійна функція для незалежної змінної і
розраховується вона наступною формулою:
(3.13).
Для того щоб отримати оптимальні результати від самого регресійного
аналізу – використовуємо досить поширений метод найменших квадратів. Такий
метод дозволяє правильно оцінити параметр значення, цей параметр мінімізує суму
квадратів залишків вхідних даних по всій послідовності.
Аналітичний запис цього методу виглядає так:
(3.14).
Рисунок 3.4 – Приклад лінійної регресії
53
Представлений метод дозволить провести оцінку можливих витрат часу на ту
чи іншу нову задачу, як тільки вона надійде до внутрішньої системи «Jira» і
дозволяє керівництву нашої компанії, керуючись результатами зробленого аналізу
покращити планування навантаження як всієї команди в цілому, так і кожного
програміста окремо.
3.3.4. Моделювання бази даних. База даних (або ж скорочено – БД) – це
сукупність деякої інформації і взаємозалежних отриманих даних, які
використовуються для задоволення конкретних потреб користувачів.
Такі дані можуть бути організовані і структуровані за деякими правилами, які
передбачені в загальних принципах опису, зберігання та маніпулювання, що є
незалежно від прикладних програм [14].
Звертання прикладної програми до баз даних відбувається за допомогою
систем керування базами, які власне і забезпечують підтримку та керування
даними.
Основна мета для проектування бази даних – це скорочення можливої
надмірності збережених даних, тобто, економія об'єму пам'яті що використовується
під базу, для пришвидшення взаємодії з даними та обробки запитів. Як наслідок,
результатом проектування БД є деяке перетворення опису предметної області у
внутрішню схему БД з її задачами[14].
Задачі й етапи проектування БД випливають із (так називаної моделі
ANSI/SPARC) трирівневої схеми даних (зовнішня – концептуальна – внутрішня).
У ході проектування БД вирішуються наступні задачі:
– знаходження і представлення даних, їх зв’язків, необхідних для опису
всіх основних областей застосування даного додатка;
– створення моделі даних;
– розробка деякого попереднього варіанту нового проекту, структура
якого дозволить задовольнити всі поставлені вимоги з боку продуктивності
майбутньої системи [14].
54
Для нормального функціонування інформаційної системи було виділено
головні сутності предметної області, та проведене концептуальне і логічне
моделювання.
Високорівнева структура бази даних представлена на рисунку 3.5.
Рисунок 3.5 – Високорівнева структура бази даних
Кожна з виділених сутностей предметної області має певне призначення. Так
в табл. 3.2 описана характеристика сутностей нашої бази даних системи.
Таблиця 3.2 – Опис сутностей нашої бази даних
Сутність Характеристика
Packager_ Дана сутність буде містити всіх користувачів системи та даних
Project_ Дана сутність буде містити всі проекти та про них даних
Leaves_ Відпустки використовуються для визначення доступності
користувачів
Package_ Таблиця бази даних яка містить всю інформацію про проекти та
пов’язану з ними інформацію
ProjectUsers_ Проміжна таблиця для організації зв'язку «багато до-багатьох»
Кожна таблиця має визначені спеціальні поля для зберігання відповідної
інформації.
55
Таблиця 3.3 – Опис атрибутів таблиці Packager
Назва Опис
Id Ідентифікатор, первинний ключ таблиці Packager, який
однозначно ідентифікує запис зв’язаний з зовнішнім
ключем в таблицях Package, Leaves, Project Users
Full Name Повне ім’я працівника компанії
UserName Ім’я, яке використовується в системах компанії
Таблиця 3.4 – Опис атрибутів таблиці Project
Назва Опис
Id Ідентифікатор, первинний ключ Project, який однозначно
ідентифікує запис; зовнішній ключ в таблиці Package,
ProjectUsers
Name Ім’я працівника
Weight Коефіцієнт важкості проекту
Таблиця 3.5 – Опис атрибутів таблиці Leaves
Назва Опис
Id Ідентифікатор, первинний ключ таблиці Leaves, який
однозначно ідентифікує запис
UserId Містить Id запису з таблиці Packager; зовнішній ключ
Till Дата завершення відпустки
From Дата початку відпустки
Таблиця 3.6 – Опис атрибутів таблиці Package
Назва Опис
Id Первинний ключ таблиці Package, який однозначно
ідентифікує запис
Packager Містить Id запису з таблиці Packager; зовнішній ключ
QAEngineer Містить Id запису з таблиці Packager; зовнішній ключ
56
ApplicationVendor Назва виробника програми
ApplicationName Назва програми
Key Внутрішній ключ в системі ―Jira‖
Priority Пріорітет задачі
Category Категорія задачі
Таблиця 3.7 – Опис атрибутів таблиці ProjectUsers
Назва Опис
Id Ідентифікатор, первинний ключ таблиці ProjectUsers,
який однозначно ідентифікує запис
UserId Містить Id запису з таблиці Packager; зовнішній ключ
ProjectId Містить Id запису з таблиці Project; зовнішній ключ
Повна структура бази даних представлена на рисунку 3.6.
Рисунок 3.6 – Повна структура бази даних
57
3.4 Робота з інформаційною системою
При опису критеріїв оцінки розробників та команд, обраний алгоритм
обробки об’єктів можна описати стандартним алгоритмом роботи системи –
end2end кейс, який дозволить явно побачити які функції та операції виконуються
протягом простої роботи даної системи для отримання списку виконавців задач, які
можуть виконати задачу базуючиcь на описаних критеріях. Високорівневий процес
можна продемонструвати на рисунку 3.7.
Рисунок 3.7 – Високорівневий алгоритм визначення виконавців задач
58
Таке представлення є дуже схематичним, та все ж дозволяє зрозуміти ті кроки
та основні етапи які потрібні для визначення виконавців для кожного нового
завдання.
Висновки до розділу 3
Зважаючи на описане представлення можна сказати, що процес обробки
інформації є доволі затратними по часу, оскільки даний алгоритм виконує досить
багато різних процесів. Починається все з отримання списку тікетів що надходять
з зовнішньої системи «Jira». Далі після того, для кожного з працівників
визначаються необхідні критерії, які описують його власне навантаження. Потім,
відбувається прохід через всі тікети, для яких визначаються попередні можливі
розробники, та попередні тікети.
Цей процес супроводжується отриманням даних із системи «TimeTracker»,
яка повертає дані про використаний час стосовно того чи іншого пакунка. Отримані
дані структуруються для подальшого використання. Після даної обробки –
виконується кластерний аналіз об’єктів, які були сформовані на попередніх етапах.
Вкінці вже після проведення кластеризації і визначається необхідний кластер
та виводяться на екран всі відібрані виконавці. На цьому етапі даний алгоритм
завершує своє виконання.
59
4 РЕАЛІЗАЦІЯ ІНФОРМАЦІЙНОЇ СИСТЕМИ ОБРОБКИ ТА
РОЗПОДІЛУ ЗАВДАНЬ
4.1 Реалізація інформаційної системи обробки та розподілу
На основі аналізу, проведеного в підрозділі 3.2.3, розроблені моделі
відповідно до патерну MVC. Для збереження даних була обрана база даних Sqlite.
Це дозволяє без встановлення додаткових СУБД та інших програм взаємодіяти з
базою за допомогою додаткових бібліотек, які вбудовуються в основний створений
додаток під час його компіляції. База даних – це один із ключових елементів будь-
якого програмного продукту. А правильно сформована база даних може дозволити
повністю розробити весь необхідний функціонал програмного продукту, ну а
також, за необхідності, організувати підтримку розширення на нарощення
функціоналу такої системи.
Представлений підхід дозволить легко взаємодіяти з базою даних та
зменшувати навантаження на сервер, де власне і знаходиться додаток та полегшити
роботу самого додатку системи.
Перелік таблиць приведений на рисунку 4.1.
Рисунок 4.1 – Перелік таблиць бази даних
Були розроблені такі моделі:
60
– Package.cs
– ApptimizedUser.cs
– Leaves.cs
– Project.cs
– ProjectUsers.cs
Були сформовані дані таблиці під час виконання проекту, відповідно до
розроблених моделей (відносно патерну NVC).
Оскільки сам проект побудований на технологіях ASP.NET MVC, тому для
пришвидшення та покращення роботи з отриманою базою даних був використаний
Entity Framework – об’єктно-орієнтована технологія доступу до даних, це дозволяє
взаємодіяти з об’єктами використовуючи LINQ.
Щоб підключитися до бази даних через Entity Framework, був реалізований
контекст даних. Він являє собою клас, похідний від класу DbContext.
Контекст даних містить одну або ж кілька властивостей типу DbSet <T>, де
T представляє тип об'єкта, що зберігається в базі даних системи.
Так власне і розроблений контекст ApptimizedDbContext.cs який саме
виконує ці функції (рис. 4.2)
Рисунок 4.2 – Контекст даних системи
Дана інформаційна система буде частиною внутрішньої системи компанії,
для того щоб уникнути можливого вайпу даних були створені додаткові міграції,
які під час їх компіляції створюють додаткові таблиці та нові поля в уже існуючій
нашій базі із збереженням наповненої в неї інформації про роботу.
61
Список додаткових міграцій приведений на рисунку 4.3.
Рисунок 4.3 – Список створених додаткових міграцій
Вже після розгортання створеного проекту, система стає повністю
доступною для користувачів. Щоб увійти в систему користувачу необхідно
авторизуватись ввести логін та пароль. Такі дані валідуються та шукається з
таблиці відповідний юзер в збереженій базі даних.
Для того щоб управляти користувачами використовується не контекст даних,
а деякий спеціальний клас – UserManager<T> з простору відомих імен
Microsoft.AspNetCore.Identity.
Основні з його методів і властивостей:
– DeleteAsync (user): видаляє користувача
– ChangePasswordAsync (user, old, new): змінює пароль для користувача
– CreateAsync (user): створює нового користувача системи
– FindByEmailAsync (email): шукає користувача по його email
– FindByIdAsync (id): шукає користувача по id
– UpdateAsync (user): оновлює дані користувача
– FindByNameAsync (name): шукає користувача по його ніку
– AddToRoleAsync (user, role): додає для користувача user та роль role
– Users: повертає всіх користувачів системи
– IsInRoleAsync (user, name): повертає true, якщо користувач user
належить ролі name
– GetRolesAsync (user): повертає список ролей, до яких належить
користувач user
– RemoveFromRoleAsync (user, name): видаляє з бази роль name у
користувача user1
62
За допомогою даного класу, .net_core дозволяє достатньо легко та досить
швидко здійснювати різні операції з користувачами та уникнути скупчення деяких
функцій для контексту даних.
Приклад використання UserManager, який представлений на рисунку 4.4.
Рисунок 4.4 – Використання User Manager
Авторизація користувача з БД паролів здійснюється через відповідну форму
в системі.
Приклад авторизації представлений на рисунку 4.5.
Рисунок 4.5 – Приклад сторінки для авторизації користувача в систему
Після авторизацію користувач потрапляє на основну сторінку внутрішньої
системи компанії.
Розмежування по існуючим ролям та правам здійснюється через
авторизаційні атрибути, що дозволяють підвищити як якість так і читаємість коду.
Доступ до використання інформаційної системи з аналізу та розподілу
робочих задач дозволений лише для користувачів з групи адміністраторів системи.
Приклад можливого використання атрибутів представлений на рисунку 4.6.
Рисунок 4.6 – Приклад можливого використання авторизаційних атрибутів
63
Для того, щоб створена інформаційна система достатньо коректно
функціонувала необхідно створити нові залежності користувач-проект, для того
щоб визначити працівників та команди для кожного з нових проектів.
Далі після того, як пройшла вже перевірка на ролі, користувач або ж має
доступ до певного функціоналу системи або ж ні.
Для нової реалізації такого функціоналу створений контролер Project
Controller, який дозволить створювати нові записи для проектів, визначати їх
проектну вагу – для визначення числового значення представлення складності
нового проекту. Також визначати для кожного нового проекту команду, яка власне
і буде виконувати завдання для даного нового проекту. Такий список розробників,
які закріплені за цим проектом будуть використовуватися виключно для коректної
роботи розподілу.
Приклад створення нового проекту приведений на рисунку 4.7.
Рисунок 4.8 – Приклад створення нового проекту
Основна сторінка проектів компанії дозволяє переглянути весь створений
список поточних проектів, вагу кожного проекту, а також команду виконавців того
чи іншого проекту.
64
Рисунок 4.8 – Приклад списку проектів
Результат роботи всієї інформаційної системи залежить від багатьох відомих
параметрів, які використовуються в самих розрахунках, і значно впливають на
роботу та розрахунки під час виконання самого алгоритму програми.
Конфігураційні параметри розділені на деякі невеликі групи, які відносяться
до відповідної області нової конфігурації. Так критерії, які власне були визначені
протягом аналізу предметної області та для моделювання системи, статичні
параметри з тікетів на саму розробку, та даних що отримані з інших
використовуваних систем були визначені саме як числові представлення.
Кожна нова група має список рядків, дані яких отримуються із зовнішніх
систем, а також деяке число – яке відображає, важливість того чи іншого варіанту
групи від 0 до 1.
Наступні групи були визначені як числові представлення:
– Ваги;
– Статуси;
– Пріорітети;
– Категорії.
Приклад сторінки конфігурацій представлений на рисунку 4.9.
65
Рисунок 4.9 – Приклад сторінки конфігурацій
Після того як проведено конфігурації на налаштування всіх відомих
необхідних модулів можна вже працювати з інформаційною системою.
Якщо натиснути на кнопку «Roboboss» на головному меню системи то
авторизований користувач переходить на сторінку самої інформаційної системи, де
вже відразу запускається алгоритм для підбору потрібних, вільних виконавців під
нові задачі.
Очікуючи деякий час, відображається сформована таблиця, яка містить
список всіх нових отриманих замовлень на розробку ПЗ, а також 2-х основних
виконавців які підходять і можуть виконати дану задачу.
Підбір можливих виконавців здійснюється на основі вище описаних
критеріїв. Врахована кожна картка виконавця містить всю інформацію по його
власним описаним критеріям, та які числові значення були визначені для кожного
з критеріїв в момент виконання програми.
Далі ми бачимо приклад головної сторінки ІС що представлений на рисунку
4.10.
66
Рисунок 4.10 – Основна, головна сторінка ІС
Вже після натискання на посилання «Get previous packages», користувач
побачить відкрите модальне вікно, яке містить інформацію відносно попередніх
схожих завдань.
Кожен тікет має доступну інформацію із зовнішньої системи «Jira», а також
дані із інших доступних систем. ІС надає повну інформацію користувачеві
стосовно аналізу витраченого часу на попередні схожі замовлення, та детально
скільки часу було витрачено на всю розробку ПЗ, також скільки часу було
витрачено фахівцями на тестування програмного забезпечення. Всі ці дані
дозволять керівництву компанії оцінити всі можливі витрати часу та ресурсів на
даний проект. Приклад представлений на рисунку 4.11.
Рисунок 4.11 – Попередні завдання пакувальника завдань
67
Оцінивши можливий час, що необхідний на виконання поставленої задачі,
відповідальна особа починає аналіз наданих інформаційною системою можливих
виконавців.
Дане модальне вікно відображає всі схожі попередні завдання, хто був
виконавцем задачі, дані про час – залоговано часу на розробку та тестування, а
також категорію складності попередніх задач.
Після аналізу критеріїв, користувач може переглянути детальну інформацію
стосовно його поточних задач. Для цього необхідно натиснути кнопку «Details»,
після цього з’явиться модальне вікно з інформацією по всім поточним задачам у
вигляді таблиці задач.
Дане вікно відображає наступну інформацію:
– Номер завдання;
– Часові параметри (використаний час, час, який залишився, та дата
дедлайну);
– Людей, які так чи інакше вже працюють над ним;
– Пріоритет задачі;
– Поточний статус задачі.
Приклад модального вікна наведений на рисунку 4.12.
Рисунок 4.12 – Детальна інформація по поточним задачам обраного розробника
68
Людина, яка розподіляє задачі зможе переглянути поточну навантаженість
працівника відносно команди. Даний інструмент дозволяє побачити, чи був
працівник перенавантажений протягом деякого періоду часу відносно команди в
середньому, чи навпаки – був менше навантажений ніж команда.
Це покаже чи слід зараз давати тому чи іншому розробнику нову задачу, чи
можна дати йому трохи відпочити – це дозволить збалансувати навантаження
команди, і це в свою чергу краще позначиться на подальшій продуктивності
працівників.
На даний момент вся інформація по завантаженості отримується із системи
трекінгу часу, за останні 6 тижнів з даного моменту – тобто моменту виконання
програми. Вже на основі отриманих даних будується графік, який зображує та
містить 2 криві. Перша крива – власне навантаження працівника за останній період
часу, інша крива – середні показники навантаження всієї команди за такий самий
період часу роботи. Графічне представлення легко дозволяє побачити точки
екстремуми, або ж точки перетину двох кривих.
Для побудови таких графіків була використана бібліотека – Chart.js.
Бібліотека Chart.js ідеально підходить саме для таких проектів – коли
потрібні чисті, пласкі та елегантні графіки. Використана бібліотека з відкритим
вихідним кодом. Включає в себе шість основних типів побудови діаграм (лінія,
діаграма, стовпці, полярна, радіальна, кругова діаграма). Щоб отримати необхідні
графіки було використано звичайний лінійний графік.
Бібліотека використовує HTML5 canvas елемент для надання графіків та
діаграм.
Приклад побудови графіку представлений на рисунку 4.13.
69
Рисунок 4.13 – Графік навантаження команди/працівника
Проаналізувавши дані, які представлені на рис. 4.13, можна зробити деякий
висновок, що на четвертому тижні працівник працював більше ніж в середньому
вся команда розробників. На сьомому ж тижні працівник має досить низькі
показники, так як у даної людини на наступний тиждень вже запланована відпустка
– то таким чином керівництво вже штучно знижує навантаження на відповідного
працівника в останні дні перед його відпусткою, і це є добре для працівника.
4.2 Система контролю за версіями
Система дозволяє провести повну інтеграцію, підвищити продуктивність,
якість і швидкість з розробки та розгортання програмного забезпечення.
Використання Azure DevOps чи Jenkins для створення нових додатків в хмарі та їх
розгортання в Azure DevOps, весь код автоматично проходить збірку і перевірку,
це все дозволяє швидше виявляти можливі помилки. Служба Azure Application
Insights надає інформацію за допомогою своїх засобів для управління
продуктивністю додатків і також миттєвої аналітики. Також дозволяє відстежувати
працездатність самої інфраструктури за допомогою служб Azure Log Analytics і
Azure Monitor і також виконує інтеграцію з існуючими панелями моніторингу,
наприклад Grafana або Kibana. За допомогою даних засобів достатньо легко
відслідковувати витрати ресурсів сервера таких як (пам’ять та процесор), логувати
всі проведені дії в самій системі тощо.
70
Можливий приклад проходження, потоку даних в Azure DevOps
представлений на рисунку 4.14.
Рисунок 4.14 – Приклад роботи Azure DevOps
Висновки до розділу 4
В розробленій системі для взаємодії між працівниками розробки та контролю
за версіями була використана відома система від Microsoft Dev Azure система, яка
має Git-воркфлов, це все дозволяє розробнику контролювати свій процес розробки,
та відслідковувати зміни що відбуваються в проекті коректно.
71
ВИСНОВКИ
Мета кваліфікаційної роботи бакалавра досягнута. У ході виконання даної
кваліфікаційної роботи бакалавра був проведений збір всієї інформації, необхідної
для подальшої роботи що була виконана над реалізацією інформаційної системи,
проведений детальний аналіз предметної області з розробки ПЗ та проведений
розподіл задач в межах ІТ-компанії «Andersenlab» та описана структура компанії,
проведено огляд можливих аналогів розроблюваної інформаційної системи
обробки та розподілу замовлень на основі аналізу джерел отриманої інформації,
підходи до проектування системи, розглянуті технології аналізу та розподілу нових
робочих задач а також були розглянуті та визначені методи дослідження.
У ході роботи над кваліфікаційною роботою був змодельований процес
розподілу задач що відбувається в компанії «Andersenlab» за IDEF0.
Мета проекту що полягає у створенні інформаційної системи аналізу та
розподілу робочих задач, формалізована експертами компанії «Andersenlab» для
пришвидшення всіх робочих процесів та для підвищення ефективності з
планування роботи, і дозволить рівномірно зробити розподіл навантаження по
командам.
Моделювання інформаційної системи обробки та розподілу замовлень
допомогло досконально проаналізувати всю цю предметну область та область
діяльності самої компанії, що в свою чергу дозволило створити систему відповідну
до функціональних вимог замовника. В процесі самого моделювання були
визначені деякі основні проблеми для даного процесу та описані всі можливі
наслідки виникнення таких проблем.
Під час порівняльного аналізу деяких відомих підходів саме для вирішення
схожих задач були вибрані наступні підходи машинного навчання необхідні для
вирішення конкретних задач: аналіз самої задачі – підбір виконавців – кластерний
аналіз k-середніх, лінійний регресійний аналіз. В ході перевірки встановлення та
тестування системи всі дані підходи показали очікуваний на початку результат і
повністю задовольняють вимогам замовників.
72
Інформаційна система обробки та розподілу замовлень була розроблена на
основі моделі системи та описаними основними компонентами самої системи, за
допомогою технології .NET Core із використанням методів технології «Entity
Framework».
Виконана робота доводить, що автоматизація процесів, навіть таких як
розподіл завдань між розробниками, командами та працівниками компанії, значно
пришвидшує весь цей процес та полегшує роботу відповідальної особи, яка
займається розподілом завдань.
73
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ
1. Воронин, А.В. Использование кластерного анализа для выбора локальных
стратегий / А.В. Воронин // Проблемы и перспективы управления экономикой
и маркетингом в организации. – №1. – 2001
2. Discovering Knowledge in Data: An Introduction to Data Mining, Jan 2005 – 190-
201 с.
3. Chiang, C.L, (2003) Statistical methods of analysis, World Scientific. ISBN 981-
238-310-7 – 274 с.
4. Рідкокаша А.А., Голдер К.К. Основи систем штучного інтелекту. Навчальний
посібник. Черкаси, "ВІДЛУННЯ – ПЛЮС", 2002. – 240 с.
5. Artificial Intelligence – URL: https://hub.packtpub.com/welcome-to-machine-
learning-using-the-net-framework/ (дата звернення: 24.03.22).
6. Кластерний аналіз – URL: https://studfiles.net/preview/6440954/page:20/ (дата
звернення: 24.03.22).
7. ASP.NET – URL: https://uk.wikipedia.org/wiki/ASP.NET_MVC_Framework
(дата звернення: 24.03.22).
8. Кластерний аналіз – URL: https://en.wikipedia.org/wiki/Cluster_analysis (дата
звернення: 24.03.22).
9. Visual Studio и Xamarin – URL: http://msdn.microsoft.com/ru-
ru/library/mt299001.aspx (дата звернення: 24.03.22).
10. IronPython – URL: https://uk.wikipedia.org/wiki/IronPython (дата звернення:
24.03.22).
11. Рівень зусиль – URL: https://en.wikipedia.org/wiki/Level_of_effort (дата
звернення: 24.03.22).
12. Visual Studio – URL: https://uk.wikipedia.org/wiki/Microsoft_Visual_Studio (дата
звернення: 24.03.22).
13. Анализ и оценка способов формирования целей предприятия. // научное
сообщество студентов: междисциплинарные исследования: сб. ст. по мат. II
междунар. студ. науч.-практ. конф. – 2012. – №3.
74
14. SMART // Вікіпедія – URL: https://uk.wikipedia.org/wiki/SMART#cite_note-1.
(дата звернення: 24.03.22).
15. Організаційна структура компанії: – URL:
http://project.dovidnyk.info/index.php/programnye-
upravlyeniyeproyektamisprimavera/551-organizacionnaya_struktura_kompanii
(дата звернення: 24.03.22).
16. Навіщо потрібна матриця відповідальності?: – URL:
http://svitohlyad.com.ua/novyny-i-suspilstvo/navischopotribna-matrytsya-
vidpovidalnosti/ (дата звернення: 24.03.22).
17. Діаграма Ганта – ваш помічник у плануванні. Що таке діаграма Ганта і як її
скласти?: – URL: http://faqukr.ru/biznes/103951-diagrama-ganta-vash-pomichnik-
u-planuvanni-shho.html (дата звернення: 24.03.22).
75
ДОДАТОК А
«Затверджую»
Завідувач кафедри КН та СА
проф. Триус Ю.В.
_________________________
«____»______________2022 р.
ПРОЕКТУВАННЯ ІНФОРМАЦІЙНОЇ СИСТЕМИ ОБРОБКИ ТА
РОЗПОДІЛУ ЗАМОВЛЕНЬ МІЖ МЕНЕДЖЕРАМИ ВІДДІЛУ ПРОДАЖІВ
Специфікація
482.ЧДТУ. 22095-01
Листів 2
Розробник ____________________ Плічко В. Ю.
Керівник ____________________ Андрієнко В. О.
Черкаси – 2022
76
482.ЧДТУ. 22095-01
Позначення Найменування Примітка
Документація
482.ЧДТУ. 22095-01 Планування робіт
34 01
482.ЧДТУ. 22095-01 Текст програми
12 01
77
ДОДАТОК Б
ПРОЕКТУВАННЯ ІНФОРМАЦІЙНОЇ СИСТЕМИ ОБРОБКИ ТА
РОЗПОДІЛУ ЗАМОВЛЕНЬ МІЖ МЕНЕДЖЕРАМИ ВІДДІЛУ ПРОДАЖІВ
ПЛАНУВАННЯ РОБІТ
482.ЧДТУ. 22095-01 34 01
Листів 5
Розробник ____________________ Плічко В.Ю.
Черкаси – 2022
78
ПЛАНУВАННЯ РОБІТ
Планування даного проекту – це послідовність виконання наступних етапів:
– структуризація проекту (ієрархічна структура робіт – WBS (Work
Breakdown Structure);
– матриця відповідності – RАМ (Responsibility Assignment Matrix);
– організаційна структура проекту – OBS (Organizational Breakdown
Structure);
– розробка плану-графіка реалізації проекту (діаграма Ганта, мережний
графік).
Структуризація проекту може виконуватися за будь-якою ознакою.
Розрізняють структуризацію проекту за функціональними видами робіт, за
виконавцями, ресурсами, відповідальними тощо, а також залежно від його
специфіки, вимог керівництва, складності проекту, інших учасників або ж
інвесторів.
Окремо слід виділити проектні структури, які застосовуються в усьому світі
під час планування проекту:
– ієрархічна структура виконання робіт – WBS;
– організаційна структура всього проекту – ОBS;
– матриця відповідності – RАМ.
Ідентифікація мети ІТ-проекту використовуючи метод SMART. На відміну
від деяких традиційних методів до формулювання цілей, у багатьох сферах
людського життя та конкретно у проектному менеджменті існує деякий SMART-
аналіз якості постановки цілей. Тобто, переводячи з англійської мови, «smart» має
значення «розумний» або «інтелектуальний». Критерії методу SMART являються
вже більш конкретизованими і, як вважають самі автори [15], є більш вичерпними
для формулювання поставлених завдань проекту або ж стратегічних цілей
підприємства, ніж самі традиційні методи, до яких зазвичай входять не
конкретизовані критерії до цілі, як «перевіряєма», «реальна», «гнучка», «та, що
люди признають в якості власних особистих поставлених цілей».
79
Абревіатура SMART складена із кількох англійських слів «specific»,
«measurable», «attainable», «relevant», «time-bound», – тобто вимірювана, конкретна,
актуальна та обмежена в рамках часу, досяжна. Автори даного методу та самі
спеціалісти, які придержуються його застосування, вважають, що відповідність
власне поставлених задач по критеріям даного методу значно підвищує ймовірність
їх виконання у визначені поставлені терміни та досягнення спільної, загальної
мети. [16]
Формалізована мета даного проекту, базуючись на методі SMART, полягає у
наступному: створити робоче сховище даних та власне користувацький веб-
інтерфейс до нього, що буде оцінена експертами компанії «Andersenlab» для
визначення подальшої економічної ефективності а також якості створеної системи
для побудови та перегляду деяких фінансових звітів компанії, і це дозволить
відображати показники ефективності роботи спеціалістів компанії та кореляцію
між собівартістю та фіксованою ціновою політикою компанії у вигляді зручних
таблиць та графіків, які необхідні керівництву самої компанії, що підтверджується
інтересом компанії до самого даного проекту. Проект буде виконано вчасно, що
підтверджується календарним планом технічному завданні.
Планування змісту структури робіт ІТ-проекту. Структура робіт допоможе
визначити завдання та суб-завдання, а також термін виконання кожної проведеної
роботи найбільш зручним чином, через створення графічної схеми. Найкращий
шлях для встановлення поточних завдань, необхідних для досягнення основної
мети даної роботи, – декомпозиція цієї роботи на доступні для постійного
контролю та управління різними його частини. Для цього використовується
структура проведених робіт (work breakdown structure) – ієрархічна структура з
декомпозиції проведених робіт роботи, поки весь проект не буде представлений
саме як мережа окремих робіт. Весь повний обсяг робіт за проектом розташований
на вершині схеми і потім підрозділяється на підсистеми нижчих рівнів. На
найнижчому рівні розміщений, так званий пакет робіт – сукупність найпростіших
операцій. В самому низу наведена структура робіт для видання та розповсюдження
інформації.
80
Після того, як ви підготуєте схему структури робіт, на її основі буде легко
визначити терміни виконання завдань, необхідні для цього, ресурси та кошти.
Структура розподілу або ж декомпозиція робіт (WorkBreakdownStructure –
WBS) – ієрархічна структура з розподілу всього проекту на підпроекти, пакети
робіт різного рівня, пакети детальних робіт. WBS є засобом для власне створення
системи управління проектом, тому як дозволяє вирішувати різні проблеми оцінки
вартості, розподілу відповідальності, створення системи звітності, організації
робіт.
Основні етапи для побудови СРР та можливості її застосування:
– класифікація робіт та розподіл проекту на підставі заданих критеріїв.
– для кожної роботи визначаються виконавці, тривалість робіт,
постачальники, витрати, обсяги, бюджет, обладнання, матеріали тощо;
– побудова матриці відповідальності.
WBS-діаграма виконання проектів представлена на рис. Б.1.
Рисунок Б.1 – WBS-діаграма проекту
81
На наступному кроці розробки структури проекту є визначення
організаційної структури (ОBS) проекту.
Організаційна структура проекту (OBS) – є графічним відображенням всіх
учасників проекту (фізичних та юридичних осіб) та призначення їхніх
відповідальних осіб, залучених до реалізації в проекті.
Елементами ОBS можуть бути:
– окремі виконавці (керівники, службовці, фахівці);
– організації, структурні підрозділи і служби, у яких зайнята та або інша
кількість фахівців, що виконують певні функціональні обов'язки;
– інші задіяні організації.
Типи зв'язків між елементами OBS:
– вертикальні, або ж зв'язки підпорядкування;
– горизонтальні, або ж відносини під час співпраці і узгодження.
Правила побудови ОBS:
– на верхньому рівні OBS проекту знаходиться керівник та команда
управління проектом;
– на наступному рівні – виконавці: відділи, організації, підрозділи тощо.
Виконавцями виступають окремі організаційні структури, які володіють
технологією виконання різних пакетів робіт нижчого рівня у WBS-структурі;
– останнім рівнем OBS-структури є відповідальні особи виконавців. Це
не обов’язково повинні бути керівники, а ті працівники, яким доручено
безпосередньо організовувати та особливо, відповідати перед виконавцем за
виконання конкретного елемента WBS-структури.
В ході планування та підготовки проекту була визначена відповідна команда:
– Смірнов В.В. – консультант із розробки та проектування системи;
– Гайдар Б.В. – консультант із управління ІТ-проектами;
– Бердник О.С. – керівник проекту, розробник системи;
– Нестеренко А.Д. – бізнес-аналітик проекту, спеціаліст із тестування ПЗ;
– Антипів Б.А. – спеціаліст із моделювання моделей даних.
OBS-діаграма проекту представлена на рис. Б.2.
82
Рисунок Б.2 – OBS-діаграма проекту
Суттєвого полегшення управління надає такий інструмент, як матриця
відповідальності (або лінійний графік). Її будують на підставі попередньо
розробленої WBS-структури (ієрархічної основи для виконуваних робіт) і OBS
структури (організаційної конструкції по виконавцям). Вона застосовується для
здійснення керівних впливів шляхом введення принципу відповідальності
(Principle Responsibility). Для проекту створюється матриця відповідності – це
відображення спланованих зв`язків (найчастіше – графічне). Її зображують у
вигляді таблиці, що базується на базисі співвідношень WBS- і OBS-структур. Тоді,
першу представляють в якості вертикальних рядків матриці, а другу –
горизонтальних стовпців. Для кожного WBS-елемента визначається співпрацівник,
який буде координувати його виконання. На місці перетину двох компонентів
проставляють відповідний знак.
Для добре організованою програми повинне дотримуватися правило, щоб
виконання будь-якої мети контролював певний керуючий орган.
RAM – так коротко позначається матриця відповідальності проекту
(Responsibility assignment matrix) – розподіл звітності та обов`язків у вигляді
представленому в таблиці.
Функціональні обов`язки всіх осіб, задіяних в заплановані роботи, визначає
матриця відповідальності. Вона служить для конкретизації набору завдань, а за їх
виконання люди звітують персонально.
Матриця відповідальності проекту представлена у таблиці Б.1.
83
Таблиця Б.1 – Матриця відповідальності
Аналіз Аналіз Планування Моделювання та Розробка Тестування
предметної вимог проекту проектування продукту продукт
області проекту у проекту
1.1 X X
1.1.1 X
1
1.1.2 X
1.2 X
2.1 X
2
2.2 X
3.1 K X
3
3.2 K X
Продовження таблиці Б.1 – Матриця відповідальності
4.1 X
4.2 X K
4.3 X K
4
4.4 X
4.5 X
4.6 X K
5.1 K X
5.2 K X
5 5.3 X
5.4 К X
5.5 X
6.1 X
6
6.2 X Х
84
У таблиці Б.1, що знаходиться у додатку Б знаходиться класифікація ризиків
за показниками ймовірності виникнення ризику та величині втрат.
Побудова календарного графіку виконання ІТ-проекту. Календарне
планування проекту, яке полягає у визначенні календарних дат виконання всіх
робіт, ставить за мету координацію діяльності залучених до проекту виконавців для
забезпечення його успішного завершення.
Календарний план як перелік тільки планових параметрів проектних робіт
втрачає свій сенс без порівняння з фактичними термінами їх виконання, тому
частіше ведуть мову про календарні графіки.
Календарний графік відбиває планові й фактичні дані про початок, кінець і
тривалість кожного робочого елементу WBS. У ньому також відмічається можлива
гнучкість у даті початку роботи без ускладнення виконання усього проекту (тобто
запас часу по некритичних роботах). Для найскладнішого календарного графіка
записується чотири версії для дат початку, кінця, тривалості та запасу: рання, пізня,
запланована календарна, фактична.
Цілі календарного графіка:
– забезпечити вчасне надходження фінансування;
– координувати надходження ресурсів;
– вчасно забезпечити потрібні ресурси;
– передбачити у різні моменти рівень потрібних фінансових витрат і
ресурсів та раціональний розподіл їх між проектами;
– забезпечити вчасне виконання проекту.
Діаграма Ганта є достатньо зручним інструментом для використання. Її
будують наступним чином: на горизонталі фіксують календар у тих одиницях часу,
які обрані для проекту (години, дні). Ліворуч на вертикалі розташовують
найменування всіх робіт. На полі, що утворилось, поставляють у вигляді
прямокутників роботи, довжина яких по горизонталі відповідає їхній тривалості.
Фрагмент діаграми Ганта проекту представлений на рис. Б.5. Повна діаграма
Ганта представлена у додатку А (рис. Б.3-Б.6).
85
Рисунок Б.3 – Перша частина діаграми Ганта
Рисунок Б.4 – Друга частина діаграми Ганта
Рисунок Б.5 – Третя частина діаграми Ганта
Рисунок Б.6 – Четверта частина діаграми Ганта
Планування ризиків проекту. Оскільки розробка програмного забезпечення –
це складний процес, до якого залучені люди з різним рівнем підготовки та знань, у
ньому використовується безліч технологічних елементів і складних систем, то для
кожної команди важливо вміти правильно реагувати на виникаючі і можливі
проблеми в майбутньому. Така реакція називається управлінням ризиками.
Проектів без ризиків не буває. Збільшення складності проекту призводить до
збільшення числа і масштабів супутніх ризиків. При управлінні ризиками у проекті
перш за все слід подумати, як розробити такий план реагування, щоб домогтися
зниження ризикованості.
Ризики з'являються з невизначеностей, а невизначеності, як відомо, існують
завжди і всюди. Всі ризики можна умовно розділити на дві категорії. До першої
категорії відносяться ті ризики, про які ми знаємо, які можливо знайти і оцінити.
86
Для таких ризиків можливо планування. Але бувають ризики, які ми не можемо
передбачити, які з'являються несподівано. Такі ризики відносяться до другої
категорії. Найчастіше зустрічаються ризики першої категорії, які можна визначити,
це відомо з минулого досвіду.
Управління ризиками являє собою велику кількість різних процесів,
пов'язаних з пошуком і аналізом ризиків. Ці процеси, спрямовані на те, щоб
максимально зменшити негативні наслідки ризиків і максимально збільшити
кількість позитивних наслідків.
Основними процедурами даного виду управління є:
– ідентифікація;
– оцінка;
– планування реагування;
– моніторинг і контроль.
Виконаємо якісну і кількісну оцінку ризиків проекту. Про якісній оцінці
ризиків визначимо ризику, що потребують швидкого реагування. Така оцінка
ризиків визначить ступінь важливості ризику і дозволить вибрати спосіб
реагування. Кількісна оцінка ризиків буде виконана для більш повної ідентифікації
ризиків та ступеня їхнього впливу на виконання проекту. Кількісна і якісна оцінка
ризиків можуть використовуватися окремо або разом, залежно від наявного часу і
бюджету, необхідності в кількісній або якісній оцінці ризиків.
Далі виконаємо планування реагування на ризики – це розробка методів і
технологій зниження негативного впливу ризиків на проект. Визначимо
ефективність розробки реагування на проект, визначимо чи будуть наслідки впливу
ризику на проект позитивними або негативним.
87
87
Таблиця Б.2 – Оцінка ймовірності виникнення, величини необхідних витрат та індексу ризику
План А Тип План Б
Статус Ймовірність Вплив Ранг
ID Опис ризику стратегії
ризику виникнення ризику ризику
реагування
1. Налагодити При виявлення
гарні відносини між непорозуміння
розробником та керівником. потрібно вияснити, що
2. Дотримуватися саме стало причиною
Непорозуміння
ділового етикету Попередже непорозуміння
RS_1 Відкритий між розробником Низька Середній 3
спілкування. ння обсудити її та
та замовником
3. Створити створити здорову
комфортні умови для атмосферу в колективі.
співпраці
1. Провести
попереднє дослідження
Поява
альтернативних продуктів.
RS_2 Відкритий альтернативного Низька Високий 3 Прийняття
2. Вибрати
продукту
унікальну стратегію
створення проекту.
1. Ясно і При виявленні
однозначно скласти ТЗ невідповідностей
разом із замовником, деяких характеристик
обговоривши усі види продукту заявленим
вимог. вимовам потрібно
Нечітке завдання 2. Скласти Попередже уважно та чітко
RS_3 Відкритий Середня Високий 6
на розробку глосарій для запобігання ння окреслити те, що було
розбіжностей у розумінні виконано невірно
слів та термінів. (після розмови із
3. Періодичний замовником) та
контроль замовником етапів зробити правки.
роботи.
88
88
Продовження таблиці Б.2 – Оцінка ймовірності виникнення, величини витрат та індексу ризику
4. План А Тип План Б
Статус Ймовірність Вплив Ранг
ID Опис ризику стратегії
ризику виникнення ризику ризику
реагування
Підвищити кваліфікацію Врахувати час на
Низька
персоналу. підготовку працівників.
кваліфікація
RS_4 Відкритий Середня Середній 4 Переглянути онлайн Пом’якшення Видати літературу,
розробників
ресурси для підвищення переглянути онлайн
проекту
рівня знань. відеоуроки.
Провести аналіз Змінити порядок
актуальності пріоритетів робіт.
найважливіших процесів Знайти способи
та робіт. Звернути оптимізації роботи із
Неоптимальний особливу увагу на вже існуючою
RS_5 Відкритий Висока Високий 9 Пом’якшення
розподіл часу правильність розподілу розстановкою.
часу. Правильно Обговорити варіанти
визначити пріоритети внесення правок до
виконання робіт. Чітко термінів реалізації із
дотримуватися плану. замовником.
Виділити всі параметри Узгодити всі
проекту. положення з
Чітко описати вимоги до замовником, у разі
Часте внесення проекту. потреби внести
RS_6 Відкритий Середня Середній 4 Перенос
змін у ТЗ Обговорити всі технічні необхідні зміни та
засоби виконання поправки.
проекту та умови
реалізації.
89
89
Продовження таблиці Б.2 – Оцінка ймовірності виникнення, величини витрат та індексу ризику
Проаналізувати методи Виділити час та ресурсі
Вибір
та засоби, для виконання на пошуки покращення
неефективної
RS_7 Відкритий Середня Високий 6 проекту. Пом’якшення обраної технології.
технології
розробки
План А Тип План Б
Статус Ймовірність Вплив Ранг
ID Опис ризику стратегії
ризику виникнення ризику ризику
реагування
Провести детальний аналіз Переоцінка
проекту. Визначити масштабів проекту.
Не вірна оцінка основні етапу проекту, Перебудова стратегії
RS_8 Відкритий масштабів Низька Середній 2 розподілити час на їх Пом’якшення реалізації проекту.
проекту виконання. Проаналізувати
масштаби проекту на
основі додаткових джерел.
На етапі проектування Здійснювати
тісно співпрацювати із проміжний контроль
Помилки
RS_9 Відкритий Висока Високий 9 замовником та на певних Пом’якшення результатів в ході
проектування
етапах демонструвати виконання проекту.
поточні результати.
Підготувати резерв Замінити програмне
Збої в роботі
програмних засобів. забезпечення.
RS_10 Відкритий програмного Низька Високий 3 Попередження
Залучити спеціаліста для
забезпечення
усунення збоїв.
Налаштувати автоматичне Робити копію даних
Відсутність збереження даних. після кожного
RS_11 Відкритий резервних копій Низька Середній 2 Зберігати дані на різних Попередження виконаного етапу.
даних носіях інформації.
90
90
Продовження таблиці Б.2 – Оцінка ймовірності виникнення, величини витрат та індексу ризику
Реалізація Попередити замовника про Обговорити вигоди і
непотрібної можливість додаткового збитки від можливих
RS_12 Відкритий Низька Низький 1 Використання
функціональност функціоналу. змін проекту.
і
План А Тип План Б
Ймовірність Ранг
ID Статус ризику Опис ризику Вплив ризику стратегії
виникнення ризику
реагування
Здійснювати Здійснювати
проміжний моніторинг
контроль проекту
результатів в ході замовником.
Невиконання виконання проекту. Надання
RS_13 В ідкритий Середня Низький 2 Перенос
моніторингу проекту Здійснювати проміжних
моніторинг результатів
проекту виконання проекту
працівниками. після кожного
етапу.
Розробка проекту з
врахуванням вимог
до програмного
забезпечення
Виникнення проблем
користувачів
із
проекту.
RS_15 В ідкритий програмним Середня Високий 6 Прийняття
Модифікація
забезпеченням
проекту з
користувачів
врахуванням
різних версій ПЗ,
яке буде
застосовуватися.
91
91
Продовження таблиці Б.2 – Оцінка ймовірності виникнення, величини витрат та індексу ризику
Зміна вимог Узгодити всі Переоцінка
замовника в питання на проекту, кожного
процесі розробки початкових етапах, разу, коли вимоги
RS_15 В ідкритий Низька Високий 3 Пом’якшення
проекту щоб мінімізувати змінюються.
кількість змін під
час розробки.
92
ДОДАТОК В
«Затверджую»
Завідувач кафедри КН та СА
проф. Триус Ю.В.
_________________________
«____»______________2022 р.
ПРОЕКТУВАННЯ ІНФОРМАЦІЙНОЇ СИСТЕМИ ОБРОБКИ ТА
РОЗПОДІЛУ ЗАМОВЛЕНЬ МІЖ МЕНЕДЖЕРАМИ ВІДДІЛУ ПРОДАЖІВ
Текст програми
482.ЧДТУ. 22095-01 12 01
Листів 12
Розробник ____________________ Плічко В.Ю.
Керівник ____________________ Андрієнко В.О.
Черкаси – 2022
93
КОД РОЗРОБЛЕНОЇ СИСТЕМИ
В.1 Класи моделей та контексту системи
Apptimized Db Context.cs
namespace Apptimized OperationsIntranet.Models.DataModels
{
public sealed class ApptimizedDbContext : IdentityDbContext<ApptimizedUser>
{
public ApptimizedDbContext(
DbContextOptions<ApptimizedDbContext> options) : base(options)
{
}
public DbSet<Leave> Leaves { get; set; } public DbSet<ApptimizedUser> ApptimizedUser { get; set; }
public DbSet<Project> Projects { get; set; } public DbSet<Package> Packages { get; set; } public DbSet<ProjectUsers>
ProjectUsers { get; set; } public DbSet<MonthLog> MonthLogs { get; set; }
protected override void OnModel Creating(ModelBuilder builder)
{
base.OnModelCreating(builder);
builder.Entity<ApptimizedUser>().HasKey(u => u.Id);
builder.Entity<ApptimizedUser>() .HasMany(x => x.Packages)
.WithOne(z => z.Packager);
builder.Entity<Project>()
.HasMany(x => x.Packages)
.WithOne(z => z.Project);
builder.Entity<ProjectUsers>()
.HasKey(t => new { t.ProjectId, t.UserId });
builder.Entity<ProjectUsers>() .HasOne(p => p.Project)
.WithMany(u => u.Users)
.HasForeignKey(p => p.ProjectId);
builder.Entity<ProjectUsers>() .HasOne(u => u.User)
.WithMany(p => p.Projects)
.HasForeignKey(u => u.UserId);
builder.Entity<ApptimizedUser>()
.HasMany(c => c.Leaves)
.WithOne(e => e.User);
builder.Entity<ApptimizedUser>() .HasMany(c => c.MonthLogs)
.WithOne(e => e.Packager);
}
}}
Package.cs
namespace ApptimizedOperationsIntranet.Models.DataModels
{
public class Package
{
public int Id { get; set; }
public string Key { get; set; }
public ApptimizedUser Packager { get; set; }
94
public ApptimizedUser QAEngineer { get; set; }
public Project Project { get; set; }
public string SoftwareName { get; set; }
public string SoftwareVendor { get; set; }
public string Category { get; set; }
public string Summary { get; set; }
public double PackagingTime { get; set; }
public double TestingTime { get; set; }
}
Project.cs
namespace ApptimizedOperationsIntranet.Models.DataModels
{
public class Project
{ [Key]
public int Id { get; set; }
public string Name { get; set; }
public double Complexity { get; set; }
public List<ProjectUsers> Users { get; set; } = new List<ProjectUsers>();
public List<Package> Packages { get; set; } = new List<Package>();
[NotMapped]
public ICollection<string> SelectedUsers { get; set; } = new List<string>();
}
}
ProjectUsers.cs
namespace ApptimizedOperationsIntranet.Models.DataModels
{
public class ProjectUsers
{
public int ProjectId { get; set; } public Project Project { get; set; }
public string UserId { get; set; } public ApptimizedUser User { get; set; }
}
}
Leave.cs
namespace ApptimizedOperationsIntranet.Models.DataModels
{
public enum LeaveType : byte
{
Unknown,
Vacation,
Sick,
University,
95
}
public class Leave
{ [Key]
public int Id { get; set; }
[Required]
public virtual ApptimizedUser User { get; set; }
public LeaveType Type { get; set; }
[Required]
public DateTime From { get; set; } = DateTime.Now;
public DateTime? Till { get; set; }
public DateTime? ClosedByDocumentFrom { get; set; }
public DateTime? ClosedByDocumentTill { get; set; }
}
}
MonthLog.cs
namespace ApptimizedOperationsIntranet.Models.DataModels
{
public class MonthLog
{ [Key]
public int Id { get; set; }
public int Month { get; set; }
public int Year { get; set; }
public double LoggedTime { get; set; }
public ApptimizedUser Packager { get; set; }
}
}
В.2 Класи фонового сервісу та обробки сторонньої інформації
TimeTrackerService.cs
namespace ApptimizedOperationsIntranet.Services
{
public class TimeTrackerService:IDisposable
{
private readonly ApptimizedDbContext _context;
public TimeTrackerService(ApptimizedDbContext context)
{
_context = context;
}
public List<MonthlyIssueViewModel> GetMonthPackagerReport(string url, string username, int month) {
var soapEnvelopeXml = CreateMonthPackagerReportSoapEnvelope(username, month); var webRequest =
CreateWebRequest(url);
InsertSoapEnvelopeIntoWebRequest(soapEnvelopeXml, webRequest);
var asyncResult = webRequest.BeginGetResponse(null, null);
asyncResult.AsyncWaitHandle.WaitOne();
96
string soapResult;
using (var webResponse = webRequest.EndGetResponse(asyncResult))
{
using (var rd = new StreamReader(webResponse.GetResponseStream()))
{
soapResult = rd.ReadToEnd();
}
Console.Write(soapResult);
}
var xDoc = new XmlDocument(); xDoc.LoadXml(soapResult);
var jsonText = xDoc.GetElementsByTagName("IssueMonthlyReviewResult")[0].InnerText; var result =
"{\"list\":[" + jsonText.Substring(jsonText.IndexOf("{\"jira_key\"")) + "}"; return
JsonConvert.DeserializeObject<List<MonthlyIssueViewModel>>(result);
}
public MonthlyIssueViewModel InvokeService(string url, string username, int month, int year)
{
var soapEnvelopeXml = CreateMonthPackagerReportSoapEnvelope(username, month);
var webRequest = CreateWebRequest(url);
InsertSoapEnvelopeIntoWebRequest(soapEnvelopeXml, webRequest);
var asyncResult = webRequest.BeginGetResponse(null, null);
asyncResult.AsyncWaitHandle.WaitOne();
string soapResult;
using (var webResponse = webRequest.EndGetResponse(asyncResult))
{
using (var rd = new StreamReader(webResponse.GetResponseStream()))
{
soapResult = rd.ReadToEnd();
}
}
var xmlResponse = new XmlDocument(); xmlResponse.LoadXml(soapResult);
var totalJsonResult = xmlResponse
.GetElementsByTagName("IssueMonthlyReviewResult")[0].InnerText;
if (totalJsonResult.Contains("No report for this month!")) return null;
var result = "[" + totalJsonResult.Substring(totalJsonResult.IndexOf("{\"jira_key\""));
var responseResult = JsonConvert.DeserializeObject
<List<MonthlyIssueViewModel>>(result);
var totalTimeLog = responseResult.FirstOrDefault(l => l.IssueId == "ALL");
totalTimeLog.PackagerLoggedHours =
totalTimeLog.ConvertLoggedHours(totalTimeLog.PackagerLoggedHoursString); totalTimeLog.TotalLoggedHours =
totalTimeLog.ConvertLoggedHours(totalTimeLog.TotalLoggedHoursString);
var atopsTimeLog = responseResult.FirstOrDefault(l => l.IssueId == "ATOPS");
if (atopsTimeLog != null)
{
atopsTimeLog.PackagerLoggedHours =
totalTimeLog.ConvertLoggedHours(atopsTimeLog.PackagerLoggedHoursString); atopsTimeLog.TotalLoggedHours
=
totalTimeLog.ConvertLoggedHours(atopsTimeLog.TotalLoggedHoursString);
97
totalTimeLog.TotalLoggedHours -= atopsTimeLog.TotalLoggedHours;
totalTimeLog.PackagerLoggedHours -= atopsTimeLog.PackagerLoggedHours;
}
return totalTimeLog;
}
public void SaveMonthLogs()
{
var users = _context.Users?.Where(a=>a.Department==ApptimizedUserDepartment.Packaging)
.OrderBy(p => p.UserName).ToList();
if (users == null) return;
foreach (var user in users.AsParallel())
{
for (var month = 4; month < DateTime.Now.Month; month++)
{
if (packagerMonthTimeLogs == null) continue;
var totalMonthTimeLog = packagerMonthTimeLogs;
var monthLog = new MonthLog()
{
Month = month,
Year = 2018,
LoggedTime = totalMonthTimeLog.PackagerLoggedHours,
Packager = user
};
if(!_context.MonthLogs.Any(x=>x.Packager==user && x.Month==month && x.Year == 2018))
_context.MonthLogs.Add(monthLog);
}
_context.SaveChanges();
}
}
public void SaveLoggedTime()
{
foreach (var package in _context.Packages.Where(x=>x.PackagingTime==0).AsParallel())
{
var soapEnvelopeXml = GetJiraKeyInfo(package.Key);
InsertSoapEnvelopeIntoWebRequest(soapEnvelopeXml, webRequest);
var asyncResult = webRequest.BeginGetResponse(null, null); asyncResult.AsyncWaitHandle.WaitOne();
string soapResult;
using (var webResponse = webRequest.EndGetResponse(asyncResult))
{
using (var rd = new StreamReader(webResponse.GetResponseStream()))
{
soapResult = rd.ReadToEnd();
}
}
var xdoc = new XmlDocument();
xdoc.LoadXml(soapResult);
var incomingText = xdoc.GetElementsByTagName("IssueDetailResult")[0].InnerText;
var index = incomingText.IndexOf("{\"result\""); var length = incomingText.IndexOf(",{\"date\":") – 1;
if (index == -1 || length < 1) continue;
98
var trimmedText = incomingText.Substring(index, incomingText.IndexOf(",{\"date\":")-1);
var result = JsonConvert.DeserializeObject<IssueDetailViewModel>(trimmedText);
if(result!=null)
{
package.PackagingTime = double.Parse(result.PackagingTime.Substring(0,
result.PackagingTime.IndexOf("hour")).Trim());
package.TestingTime = double.Parse(result.TestingTime.Substring(0,
result.TestingTime.IndexOf("hour")).Trim());
}
}
_context.SaveChanges();
}
public void CreateLeaveEntries(int month, int year)
{
foreach (var user in _context.Users.Where(x => x.Department ==
ApptimizedUserDepartment.Packaging).AsParallel())
{
var soapEnvelopeXml = GetUserVocationsSoapEnvelope(user.UserName, month, year);
InsertSoapEnvelopeIntoWebRequest(soapEnvelopeXml, webRequest);
var asyncResult = webRequest.BeginGetResponse(null, null); asyncResult.AsyncWaitHandle.WaitOne();
string soapResult;
using (var webResponse = webRequest.EndGetResponse(asyncResult))
{
using (var rd = new StreamReader(webResponse.GetResponseStream()))
{
soapResult = rd.ReadToEnd();
}
}
var xdoc = new XmlDocument();
xdoc.LoadXml(soapResult);
var incomingText = xdoc.GetElementsByTagName("GetEmployeeVacationResult")[0].InnerText;
var result =
JsonConvert.DeserializeObject<List<TimeTrackerVacationViewModel>>(incomingText).First();
result.User = user;
if (!result.result) continue;
var leaves = result.ToLeaveEntity();
foreach(var leave in leaves)
{
if (_context.Leaves.Any(x=>x.From == leave.From && x.Till == leave.Till && x.Type
== leave.Type && x.User.Id == leave.User.Id)) continue; _context.Add(leave);
}
}
_context.SaveChanges();
}
private XmlDocument GetUserVocationsSoapEnvelope(string username, int month, int year)
{
var soapEnvelopeDocument = new XmlDocument();
99
soapEnvelopeDocument.LoadXml("<?xml version=\"1.0\" encoding=\"utf-8\"?>" +
"<soap:Envelope xmlns:xsi=\"http://www.w3.org/2001/XMLSchemainstance\"
xmlns:xsd=\"http://www.w3.org/2001/XMLSchema\" xmlns:soap=\"http://schemas.xmlsoap.org/soap/envelope/\">" +
"<soap:Body>" +
"<GetEmployeeVacation xmlns = \"http://api.revacom.com/\">" +
$"<username>{username}</username>" +
$"<month>{month}</month>"+ $"<year>{year}</year>" +
"</GetEmployeeVacation>" +
"</soap:Body>" +
"</soap:Envelope>");
return soapEnvelopeDocument;
}
private XmlDocument GetJiraKeyInfo(string jiraKey)
{
var soapEnvelopeDocument = new XmlDocument();
soapEnvelopeDocument.LoadXml("<?xml version=\"1.0\" encoding=\"utf-8\"?>" +
"<soap:Envelope xmlns:xsi=\"http://www.w3.org/2001/XMLSchemainstance\"
xmlns:xsd=\"http://www.w3.org/2001/XMLSchema\" xmlns:soap=\"http://schemas.xmlsoap.org/soap/envelope/\">" +
"<soap:Body>" +
"<IssueDetail xmlns = \"http://api.revacom.com/\">" +
$"<jiraKey>{jiraKey}</jiraKey>" +
"</IssueDetail>" +
"</soap:Body>" +
"</soap:Envelope>");
return soapEnvelopeDocument;
}
private HttpWebRequest CreateWebRequest(string url)
{
var webRequest = (HttpWebRequest)WebRequest.Create(url); webRequest.ContentType =
"text/xml;charset=\"utf-8\""; webRequest.Accept = "text/xml"; webRequest.Method = "POST"; webRequest.Host
= _host; return webRequest;
}
private XmlDocument CreateMonthPackagerReportSoapEnvelope(string username, int month)
{
var soapEnvelopeDocument = new XmlDocument();
soapEnvelopeDocument.LoadXml("<?xml version=\"1.0\" encoding=\"utf-8\"?>" +
"<soap:Envelope xmlns:xsi=\"http://www.w3.org/2001/XMLSchemainstance\"
xmlns:xsd=\"http://www.w3.org/2001/XMLSchema\" xmlns:soap=\"http://schemas.xmlsoap.org/soap/envelope/\">" +
"<soap:Body>" +
"<IssueMonthlyReview xmlns = \"http://api.revacom.com/\">" +
$"<username>{username}</username>" +
$"<month>{month}</month>" +
$"<year>{DateTime.Now.Year}</year>" +
"</IssueMonthlyReview>" +
"</soap:Body>" +
"</soap:Envelope>");
return soapEnvelopeDocument;
}
private void InsertSoapEnvelopeIntoWebRequest(XmlDocument soapEnvelopeXml, HttpWebRequest webRequest) {
using (var stream = webRequest.GetRequestStream())
{
soapEnvelopeXml.Save(stream);
} }
public void Dispose()
{
GC.Collect();
GC.SuppressFinalize(this);
}
} }
ScheduleTask.cs
namespace ApptimizedOperationsIntranet.Jobs
100
{
public class ScheduleTask : ScheduledProcessor
{
public ScheduleTask(IServiceScopeFactory serviceScopeFactory) : base(serviceScopeFactory)
{
}
protected override string Schedule => "*/1 * * * *";
public override async Task ProcessInScopeAsync(IServiceProvider serviceProvider)
{
using (var sdc = serviceProvider.GetService<SdcJiraService>())
{
await sdc.GetApprovedPackages();
}
using (var service = serviceProvider.GetService<TimeTrackerService>())
{
service.CreateLeaveEntries(DateTime.Now.Month, DateTime.Now.Year); service.SaveMonthLogs();
service.SaveLoggedTime();
}
await Task.CompletedTask;
}
}
}
ScopedProcessor.cs
namespace ApptimizedOperationsIntranet.Jobs
{
public abstract class ScopedProcessor : BackgroundService
{
private readonly IServiceScopeFactory _serviceScopeFactory;
public ScopedProcessor(IServiceScopeFactory serviceScopeFactory) : base() {
_serviceScopeFactory = serviceScopeFactory;
}
protected override async Task Process()
{
using (var scope = _serviceScopeFactory.CreateScope())
{
await ProcessInScopeAsync(scope.ServiceProvider);
} }
public abstract Task ProcessInScopeAsync(IServiceProvider serviceProvider);
}
}
LoadCalculationHelper.cs
namespace ApptimizedOperationsIntranet.Helpers
{
public static class LoadCalculationHelper
{
/// <summary>
/// Static method to get Packager description as Math Model
/// </summary>
/// <param name="user">User entity</param>
/// <param name="model">SdcViewModel view model</param> /// <returns>Object of PackagerViewModel
type</returns>
public static PackagerViewModel ToPackagerMathModel(this ApptimizedUser user, SdcViewModel model,
ConfigurationViewModel configuration)
{
var requests = model.Issues.Where(x => x.Assignee == user.UserName);
var packager = new PackagerViewModel()
{
Name = user.UserName,
Sla = 0,
101
Complexity = 0,
DaysToVacation = user.DaysToVacation(),
IsAvailable = user.IsAvailable(),
Priority = 0,
Status = 0,
Packages = user.CalculatePackagesRatio(model),
WorkLoad = 0
};
foreach (var item in requests)
{
packager.Tickets.Add(item.ToPkgComplexity(configuration));
}
foreach (var item in packager.Tickets)
{
packager.Sla += item.SlaRatio; packager.Status += item.StatusRatio; packager.Priority +=
item.PriorityRatio; packager.Complexity += item.ComplexityRatio;
}
return packager;
}
/// <summary>
/// Numeric representation of SDC issue
/// </summary>
/// <param name="sdcIssue">SdcIssueViewModel</param>
/// <returns>Returns object of PackageComplexityViewModel that has numeric presentation of parameters</returns>
public static PackageComplexityViewModel ToPkgComplexity(this SdcIssueViewModel sdcIssue,
ConfigurationViewModel configuration)
{
var package = new PackageComplexityViewModel()
{
Key = sdcIssue.Key,
Assignee = sdcIssue.Assignee,
Summary = sdcIssue.Title,
Status = sdcIssue.Status,
DueDate = sdcIssue.SlaDueDate ?? DateTime.Now,
ComplexityRatio = sdcIssue.CalculateComplexityRatio(configuration),
ProjectComplexity = sdcIssue.Project.Complexity,
SlaRatio = sdcIssue.CalculateSlaRatio(),
StatusRatio = sdcIssue.CalculateAttribute(configuration, "Status"),
PriorityRatio = sdcIssue.CalculateAttribute(configuration, "Priority"),
Issue = sdcIssue
};
package.OveralMark = package.CalculateOveralMark(); return package;
}
public static double GetCategoryValue(this Package package, ConfigurationViewModel configuration) {
var section = configuration.Configuration.FirstOrDefault(x =>
x.Section.Contains("Categories"))?.Items;
if (section != null && section.TryGetValue(package.Category, out var element))
return element * package.Project.Complexity;
return section.Values.Average() * package.Project.Complexity;
}
#region helpers
private static double CalculateAttribute(this SdcIssueViewModel sdcIssue,
ConfigurationViewModel configuration, string attr)
{
var section = configuration.Configuration.FirstOrDefault(x =>
x.Section.Contains(attr))?.Items;
if (section != null && section.TryGetValue(sdcIssue.Status, out var element)) return element;
102
return section.Values.Average();
}
private static double CalculateSlaRatio(this SdcIssueViewModel sdcIssue)
{
if (sdcIssue.SlaConsumed == null || sdcIssue.SlaRemaining == null)
{
return 0.5;
}
if (sdcIssue.SlaConsumed.Value.TotalMinutes > sdcIssue.SlaConsumed.Value.TotalMinutes && sdcIssue.Status ==
"Incoming Check") return 0.25;
return (sdcIssue.SlaConsumed.Value.TotalMinutes / (sdcIssue.SlaConsumed.Value.TotalMinutes
+ sdcIssue.SlaRemaining.Value.TotalMinutes));
}
private static double CalculatePackagesRatio(this ApptimizedUser user, SdcViewModel model)
{
var usersTickets = model.Issues.Where(x => x.Assignee == user.UserName); var count =
(double)model.Issues.Count();
return usersTickets.Count() / (count / model.Packagers.Count);
}
private static double CalculateStatusRatio(this SdcIssueViewModel sdcIssue,
ConfigurationViewModel configuration)
{
var c = configuration.Configuration.FirstOrDefault(x => x.Section.Contains("Status")).Items as Dictionary<string,
double>;
if (c.TryGetValue(sdcIssue.Status, out var element)) return element;
return c.Values.Average();
}
private static double CalculatePriorityRatio(this SdcIssueViewModel sdcIssue,
ConfigurationViewModel configuration)
{
var c = configuration.Configuration.FirstOrDefault(x =>
x.Section.Contains("Priority")).Items as Dictionary<string, double>;
if (c.TryGetValue(sdcIssue.Priority, out var element)) return element;
return c.Values.Average();
}
private static double CalculateComplexityRatio(this SdcIssueViewModel sdcIssue,
ConfigurationViewModel configuration)
{
var section = configuration.Configuration.FirstOrDefault(x =>
x.Section.Contains("Categories")).Items;
if(sdcIssue.Complexity == null)
return section.Values.Average() * sdcIssue.Project.Complexity;
if (section.TryGetValue(sdcIssue.Complexity, out var element)) return element *
sdcIssue.Project.Complexity;
return section.Values.Average() * sdcIssue.Project.Complexity;
}
private static double CalculateOveralMark(this PackageComplexityViewModel viewModel)
{
return viewModel.SlaRatio * viewModel.StatusRatio * viewModel.PriorityRatio * viewModel.ComplexityRatio;
}
103
}
#endregion
}
RegressionAnalisys.cs
namespace ApptimizedOperationsIntranet.Helpers
{
public static class RegressionAnalisys
{
public static double GetPredictedValue(this List<Package> packages,
ConfigurationViewModel configurationViewModel)
{
double sumCategories = 0;
double sumTotalTime = 0; double sumCategoriesSq = 0; double sumTotalTimeSq = 0; double
sumCodeviates = 0;
foreach (var package in packages)
{
var x = package.GetCategoryValue(configurationViewModel); var y = package.PackagingTime +
package.TestingTime; sumCategories += x; sumTotalTime += y; sumCodeviates += x * y;
sumCategoriesSq += x * x; sumTotalTimeSq += y * y;
}
var count = packages.Count;
var ssX = sumCategoriesSq – ((sumCategories * sumCategories) / count); var ssY = sumTotalTimeSq –
((sumTotalTime * sumTotalTime) / count);
var rNumerator = (count * sumCodeviates) – (sumCategories * sumTotalTime); var rDenom = (count *
sumCategoriesSq – (sumCategories * sumCategories)) * (count * sumTotalTimeSq – (sumTotalTime * sumTotalTime));
var sCo = sumCodeviates – ((sumCategories * sumTotalTime) / count);
var meanX = sumCategories / count; var meanY = sumTotalTime / count;
var dblR = rNumerator / Math.Sqrt(rDenom);
var yIntercept = meanY – ((sCo / ssX) * meanX); var slope = sCo / ssX;
return (slope * sumCategories/count) + yIntercept;
}
public static string GetPredictedCategory(this List<Package> packages,
ConfigurationViewModel configurationViewModel)
{
var projectComplexity = packages.First().Project.Complexity; double sumCategories = 0; foreach (var
package in packages)
{
var x = package.GetCategoryValue(configurationViewModel); sumCategories += x;
}
var value = sumCategories / packages.Count();
var section = configurationViewModel.Configuration.FirstOrDefault(x =>
x.Section.Contains("Categories"))?.Items; var category = string.Empty; var min = 100d;
foreach (var item in section)
{
var abs = Math.Abs(item.Value * projectComplexity – value);
if (!(abs < min)) continue; min = abs;
category = item.Key;
}
return category;
}
}
}
104
В.3 Класи представлень, моделей представлень та контролеру
AssignViewModel.cs
namespace ApptimizedOperationsIntranet.Models.ViewModels.Roboboss
{
public class AssignViewModel
{
public SdcIssueViewModel SdcIssue { get; set; } public List<PackagerViewModel> Packagers { get; set; }
public override string ToString()
{
return $"{SdcIssue.Key} {SdcIssue.Title}";
}
}
}
ConfigurationViewModel.cs
namespace ApptimizedOperationsIntranet.Models.ViewModels.Roboboss
{
[Serializable]
public class ConfigurationViewModel
{
public IEnumerable<ConfigurationItemViewModel> Configuration { get; set; }
}
[Serializable]
public class ConfigurationItemViewModel
{
public string Section { get; set; }
public Dictionary<string,double> Items { get; set; }
}
}
PackageComplexityViewModel.cs
namespace ApptimizedOperationsIntranet.Models.ViewModels.Roboboss
{
public class PackageComplexityViewModel
{
public string Key { get; set; }
public string Summary { get; set; }
public string Status { get; set; }
public DateTime DueDate { get; set; }
public string Assignee { get; set; }
public double SlaRatio { get; set; }
public double ComplexityRatio { get; set; }
public double ProjectComplexity { get; set; }
105
public double StatusRatio { get; set; }
public double PriorityRatio { get; set; } public double OveralMark { get; set; }
public override string ToString()
{
return $"{Key} {Summary}";
}
public SdcIssueViewModel Issue { get; set; }
}
}
PackagerViewModel.cs
namespace ApptimizedOperationsIntranet.Models.ViewModels.Roboboss
{
public class PackagerViewModel
{
/// <summary>
/// Name of packager /// </summary>
public string Name { get; set; }
/// <summary>
/// Sum of SLA coefs for each package
/// </summary> [KMeansValue]
public double Sla { get; set; }
/// <summary>
/// Sum of Complexity coefs for each package
/// </summary> [KMeansValue]
public double Complexity { get; set; }
/// <summary>
/// Sum of Status coefs for each package
/// </summary> [KMeansValue]
public double Status { get; set; }
/// <summary>
/// The ratio of packager`s packages to avarage of all team packages
/// </summary> [KMeansValue]
public double Packages { get; set; }
/// <summary>
/// Sum of Priority coefs for each package
/// </summary> [KMeansValue]
public double Priority { get; set; }
/// <summary>
/// The ratio of days to vacation
/// </summary>
public int DaysToVacation { get; set; }
/// <summary>
/// Is in vacation now /// </summary>
public bool IsAvailable { get; set; }
/// <summary>
/// Is packager – previous packager of request
/// </summary> [KMeansValue]
public double IsPreviousPackager { get; set; } /// <summary>
/// The ratio of packager workload against team avarage workload
/// </summary> [KMeansValue]
public double WorkLoad { get; set; }
106
/// <summary>
/// Collection of current packager`s requests
/// </summary>
public ICollection<PackageComplexityViewModel> Tickets { get; set; } = new
List<PackageComplexityViewModel>();
public string WorkloadArray { get; set; }
public override string ToString()
{
return $"{Name}";
}
}
}
RobobossController.cs
namespace ApptimizedOperationsIntranet.Controllers
{
public class RobobossController : BaseController
{
private readonly SdcJiraService _jiraService; private readonly ClasteringService _clustering; private
List<Package> _packages; private PackagerViewModel _common;
private ConfigurationViewModel _configuration;
public RobobossController(ApptimizedDbContext context, IFlasher flasher, IMapper mapper, SdcJiraService
jiraService, ClasteringService clusteringService) : base(context, flasher, mapper) {
_jiraService = jiraService;
_clustering = clusteringService;
_packages = Context.Packages.ToList();
_common = JsonConvert.DeserializeObject<PackagerViewModel>(
System.IO.File.ReadAllText("Configuration/Packager.json"));
_configuration = JsonConvert.DeserializeObject<ConfigurationViewModel>(
System.IO.File.ReadAllText("Configuration/RobobossConfiguration.json"));
}
public IActionResult Index()
{
return View();
}
public async Task<IActionResult> Details(string username)
{
var issues = await _jiraService.GetCachedSdcViewModel();
return PartialView("_Details", issues.Issues.Where(a => a.Assignee == username).ToList());
} [HttpGet]
public IActionResult Configuration()
{
return View(_common);
}
[HttpPost]
public IActionResult Configuration(PackagerViewModel model) {
if (!ModelState.IsValid || model.Equals(_common)) return View(model);
model.Name = "SuperHero"; model.IsAvailable = true;
_common = model;
var output = JsonConvert.SerializeObject(model, Formatting.Indented);
System.IO.File.WriteAllText("Configuration/Packager.json", output);
return RedirectToAction("Configuration");
107
}
[HttpGet]
public IActionResult Weights()
{
return View(_configuration.Configuration);
}
[HttpGet]
public IActionResult PreviousPackages(string key)
{
var keys = key.Split(','); var packages = new List<Package>(); foreach(var item in keys)
{
if (_packages.Any(x => x.Key == item))
packages.Add(_packages.First(x => x.Key==item));
}
return PartialView("_PreviousPackages", packages);
}
[HttpPost]
public IActionResult Weights(ConfigurationItemViewModel[] result)
{
if (!ModelState.IsValid) return View(model);
var output = JsonConvert.SerializeObject(model, Formatting.Indented);
System.IO.File.WriteAllText("Configuration/RobobossConfiguration.json", output);
return RedirectToAction("Weights");
}
[HttpPost]
public async Task<IActionResult> Result()
{
var currentIssues = await _jiraService.GetSdcATMIG();
var allIssues = await _jiraService.GetCachedSdcViewModel();
var issues = currentIssues.Issues.Where(a => a.Status == "Ready for Packaging" &&
a.CreatedDate.Value.Date > new DateTime(DateTime.Now.Year, DateTime.Now.Month, 1).Date).ToList();
var users = Context.Users.Where(a => a.Department ==
ApptimizedUserDepartment.Packaging).ToList();
var model = new List<AssignViewModel>();
var elements = new List<PackagerViewModel>
{
_common };
foreach (var itemRequest in issues)
{
if (itemRequest.Project.Name.Equals("ATUM")) continue;
itemRequest.PreviousPackages = PreviousPackages(_packages, itemRequest); if
(itemRequest.PreviousPackages.Count > 0)
{
itemRequest.PredictedComplexity =
itemRequest.PreviousPackages.GetPredictedCategory(_configuration);
itemRequest.PredicetedTime =
itemRequest.PreviousPackages.GetPredictedValue(_configuration);
}
108
var modelItem = new AssignViewModel()
{
SdcIssue = itemRequest
};
var projectUsers = GetProjectUsers(itemRequest.Project);
var usersList = GetUsers(projectUsers, allIssues);
var userModels = usersList.Where(a => projectUsers.Select(x => x.UserName).ToList()
.Contains(a.Name)).ToArray();
foreach (var item in userModels)
{
item.IsPreviousPackager = PreviousPackager(item, _packages.Where(x =>
x.Packager.UserName == item.Name).ToList(),
itemRequest);
}
if (userModels?.Count() > 2)
{
var clusters = _clustering.Cluster(userModels.ToArray(), 4, 200,
_configuration.Configuration.FirstOrDefault(x=>x.Section== "Weights")?.Items);
modelItem.Packagers = GetNearestCluster(clusters, elements).OrderBy(x => x.Sla).Take(2).ToList(); }
else {
modelItem.Packagers = userModels.ToList();
}
var random = new Random();
foreach (var item in modelItem.Packagers)
{
item.WorkloadArray = $"[{random.Next(0, 25)}, {random.Next(0, 25)}, {random.Next(0, 25)}, " +
$"{random.Next(0, 25)}, {random.Next(0, 25)}, " +
$"{random.Next(0, 25)}, {random.Next(0, 25)}]";
}
model.Add(modelItem);
}
return View(model);
}
protected override void Dispose(bool disposing)
{
if (disposing)
{
Context.Dispose();
}
base.Dispose(disposing);
}
#region Helpers
private SdcIssueViewModel[] GetUsersRequests(SdcViewModel model, string username)
{
return model.Issues.Where(x => x.Assignee == username).ToArray();
}
private List<ApptimizedUser> GetProjectUsers(Project project)
{
return Context.Projects
.Include(x => x.Users)
.ThenInclude(x => x.User)
.ThenInclude(x => x.Projects).First(a => a.Equals(project))
.Users.Select(a => a.User).ToList();
}
private ApptimizedUser GetUserWithLeaves(ApptimizedUser user)
{
return Context.Users
109
.Include(x => x.Leaves)
.ThenInclude(e => e.User)
.First(a => a.UserName == user.UserName);
}
private PackagerViewModel[] GetUsers(IEnumerable<ApptimizedUser> users, SdcViewModel currentIssues) {
return users.Select(GetUserWithLeaves).Select(userLeaves => userLeaves
.ToPackagerMathModel(currentIssues, _configuration))
.Where(userModel => userModel.DaysToVacation != 0).ToArray();
}
private IEnumerable<PackagerViewModel> GetNearestCluster(KMeansResults<PackagerViewModel> meansResults,
List<PackagerViewModel> elements)
{
var cluster = new PackagerViewModel[] { }; var min = 1000d;
for (var i = 0; i < meansResults.Means.Length; i++)
{
var elementsArray = _clustering.ConvertEntities(elements.ToArray(),
_configuration.Configuration.FirstOrDefault(x => x.Section ==
"Weights")?.Items)[0];
var res = _clustering.CalculateDistance(elementsArray, meansResults.Means[i]); if
(!meansResults.Clusters[i].Any()) continue; if (!(res < min)) continue;
min = res;
cluster = meansResults.Clusters[i];
}
return cluster.ToList();
}
private Dictionary<PackagerViewModel, double> GetNearestCluster(List<PackagerViewModel> all,
List<PackagerViewModel> etalon)
{
var cluster = new Dictionary<PackagerViewModel, double>(); var min = 1000d;
var etalonArray = _clustering.ConvertEntities(etalon.ToArray(),
_configuration.Configuration.FirstOrDefault(x => x.Section ==
"Weights")?.Items)[0];
foreach (var item in all)
{
var aa = new List<PackagerViewModel>(); aa.Add(item);
var elemArray = _clustering.ConvertEntities(aa.ToArray(),
_configuration.Configuration.FirstOrDefault(x => x.Section == "Weights")?.Items)[0]; var res =
_clustering.CalculateDistance(etalonArray, elemArray);
cluster.Add(item, res);
}
return cluster;
}
public double PreviousPackager(PackagerViewModel user, ICollection<Package> packages,
SdcIssueViewModel sdcIssue)
{
var jaro = new F23.StringSimilarity.JaroWinkler(); var max = 0d;
foreach (var item in packages)
{
if (string.IsNullOrEmpty(sdcIssue.ApplicationName) || string.IsNullOrEmpty(item.SoftwareName))
continue;
var result = jaro.Similarity(sdcIssue.ApplicationName, item.SoftwareName);
if (!(result > max)) continue; max = result;
}
return max > 0.9 ? 2 : 0;
}
public List<Package> PreviousPackages(ICollection<Package> packages, SdcIssueViewModel sdcIssue) {
var resultList = new List<Package>(); var jaro = new F23.StringSimilarity.JaroWinkler(); foreach (var
item in packages)
{
if (string.IsNullOrEmpty(sdcIssue.ApplicationName) || string.IsNullOrEmpty(item.SoftwareName))
continue;
110
var result = jaro.Similarity(sdcIssue.ApplicationName, item.SoftwareName);
if (result > 0.87) resultList.Add(item);
}
return resultList;
}
#endregion
}
}
Result.cshtml
@using ApptimizedOperationsIntranet.Models.ViewModels.Roboboss
@using System.Globalization
@using ApptimizedOperationsIntranet.Helpers
@model List<AssignViewModel>
@{
Layout = null;
}
@functions {
public List<PackageComplexityViewModel> List = new List<PackageComplexityViewModel>();
private static string GetTimeSpanInSdc(TimeSpan? ts)
{
if (ts == null) return "N/A";
var result = string.Empty;
if (ts.Value.TotalSeconds < 0) result += "-";
result += string.Format(
"{0:00}:{1:00}", Math.Abs(ts.Value.Days * 24 + ts.Value.Hours),
Math.Abs(ts.Value.Minutes));
return result;
}
public static string GenerateName()
{
Random r = new Random(); string[] consonants = { "ivanov", "petrov", "pavlov", "vikonavenko", "andriev", "dub",
"beresa", "klimov", "pavlushenko", "tkach", "olimpiec", "sungurov", "hutrenko", "koshin",
"andrushenko", "zvarich" };
return consonants[r.Next(0, consonants.Length)];
}
}
<h1 class="text-center">Task distribution helper</h1>
<div class="table-container" id="container" style="display:block; min-width:400px; margin-bottom:80px
!important" data-spy="scroll" data-target="#navbar" data-offset="50">
<table class="table table-condensed">
<thead>
<tr>
<th>Issue</th>
</tr>
</thead>
<tbody>
@foreach (var item in Model)
{
if (item.SdcIssue.Key.Contains("ATUM"))
{
continue;
}
<tr>
<td class="center-block" align="center" id="@item.SdcIssue.Key">
<p class="title">
111
<strong>Key: </strong><a
href="https://sdc.revacom.com/browse/@item.SdcIssue.Key" target="_blank">@item.SdcIssue.Key</a>
<strong> Summary: </strong>@item.SdcIssue.Title
<strong> Priority: </strong>
@if (item.SdcIssue.Priority == "Normal")
{
<span class="label label-success">@item.SdcIssue.Priority</span>
} else
{
<span class="label label-danger">@item.SdcIssue.Priority</span>
}
@if (item.SdcIssue.PreviousPackages.Count > 0)
{
<strong>Predicted category :</strong>
<span class="label labelinfo">@item.SdcIssue.PredictedComplexity</span>
<strong>Predicted time :</strong>
<span class="label label-
info">@item.SdcIssue.PredicetedTime.ToString("0.00", CultureInfo.InvariantCulture)</span>
<a data-toggle="modal" data-target="#packagesModal"
datacontent="@string.Join(',',item.SdcIssue.PreviousPackages.Select(x=>x.Key).ToArray())">Get previous packages</a>
}
</p>
<hr />
<div class="row center-block">
@foreach (var packager in item.Packagers)
{
<div class="col-md-5 packager">
<div class="packager-main">
<div style="width:35%; float:left; text-align:left">
<table class="table table-condensed">
<tr>
<td>SLA</td>
<td style="text-align:right;">
@if (packager.Sla < 0.8)
{
<span class="label label-success">
@packager.Sla.ToString("0.00", CultureInfo.InvariantCulture)</span>
} else
{
<span class="label labelwarning">@packager.Sla.ToString("0.00",
CultureInfo.InvariantCulture)</span>
}
</td>
</tr>
<tr>
<td>Previous Packager</td>
@if (packager.IsPreviousPackager > 0)
{
<td style="text-align:right;">True</td>
} else
{
<td style="text-align:right;">False</td>
}
</tr>
<tr>
<td>Packages</td>
<td style="text-
align:right;">@packager.Packages.ToString("0.00", CultureInfo.InvariantCulture)</td>
</tr>
<tr>
<td>Complexity</td>
<td style="textalign:right;">@packager.Complexity</td>
</tr>
<tr>
112
<td>Priority</td>
<td style="textalign:right;">@packager.Priority</td>
</tr>
<tr>
<td>Workload</td>
<td style="textalign:right;">@packager.WorkLoad</td>
</tr>
<tr>
<td>Status</td>
<td style="text-
align:right;">@packager.Status.ToString("0.00", CultureInfo.InvariantCulture)</td>
</tr>
<tr>
<td>Tickets</td>
<td style="textalign:right;">@packager.Tickets.Count</td>
</tr>
</table>
</div>
<div class="packager-front" style="float:right; width:65%;"> <img
src="https://i1.wp.com/www.winhelponline.com/blog/wpcontent/uploads/2017/12/user.png?resize=256%2C256&quality=100&ssl=1"
class="img-rounded" />
<h3>@GenerateName()</h3>
@if (packager.Tickets.Count > 0)
{
foreach (var tickets in packager.Tickets)
{
<div class="pull-right">
<table class="table table-condensed"
style="margin-left:20px; text-align:left; table-layout:fixed; margin-bottom:0px !important">
<tr>
<td> <a
href="https://sdc.revacom.com/browse/@tickets.Key" target="_blank">
@tickets.Key.Replace("P","R").Replace("A","O").Replace("T","M").Replace("L","E")
</a>
</td>
<td>
@if (tickets.PriorityRatio == 1)
{
<span class="label label-danger element-rounded">Urgent</span>
} else
{
<span class="label labelsuccess element-rounded">Normal</span>
}
</td>
<td>
<span class="label label-warning element-rounded">@tickets.Status</span>
</td>
<td><span class="label label-info
element-rounded pull-right">@GetTimeSpanInSdc(tickets.Issue.SlaRemaining)</span></td>
</tr>
</table>
</div>
} } else
{
<strong>There are no issues assigned</strong>
}
</div>
</div>
<div class="footer title pull-right">
<button class="btn btn-success element-rounded">Assign</button> <button
class="btn btn-default element-rounded" datatoggle="modal" data-target="#detailsModal" data-
content="@packager.Name">Details</button>
<button class="btn btn-primary element-rounded" datatoggle="modal" data-target="#chartModal"
data-whatever="@packager.WorkloadArray" datacontent="@packager.Name">Workload</button>
</div>
</div>
}
113
</div>
</td>
</tr>
}
</tbody>
</table>
</div>
<footer class="navbar navbar-default navbar-fixed-bottom footer" style="position:fixed; min-height:20px
!important" id="navbar">
<ul class="nav navbar-nav">
@foreach (var item in Model)
{
if (item.SdcIssue.Key.Contains("ATUM"))
{
continue; }
<li><a class="list-group-item bottom-menu" href="#@item.SdcIssue.Key">@item.SdcIssue.Key</a></li>
}
</ul>
</footer>
<div class="modal fade" id="chartModal" tabindex="-1" role="dialog" aria-labelledby="exampleModalLabel" aria-
hidden="true">
<div class="modal-dialog" style="width:90%; height:750px" role="document">
<div class="modal-content">
<div class="modal-header">
<button type="button" class="close" data-dismiss="modal"><span aria-
hidden="true">×</span><span class="sr-only">Close</span></button>
<h4 class="modal-title"></h4>
</div>
<div class="responsive-frame">
<canvas class="framed" id="myChart" data-content=""></canvas> </div>
<div class="modal-footer">
<button type="button" id="closeChart" class="btn dismiss="modal">Close</button>
</div>
</div>
</div>
</div> btn-primary" data-
<div class="modal" id="detailsModal" tabindex="-1" role="dialog" aria-labelledby="exampleModalLabel" aria-
hidden="true">
<div class="modal-dialog" style="width:90%; height:750px" role="document">
<div class="modal-content" style="height:80%">
<div class="modal-header">
<button type="button" class="close" data-dismiss="modal"><span
ariahidden="true">×</span><span class="sr-only">Close</span></button> <h4 class="modal-title"
id="lineModalLabel"></h4>
</div>
<div class="responsive-frame">
<iframe id="frameDetails" class="framed-details" frameborder="0" src="" allow="autoplay; encrypted-
media" allowfullscreen></iframe>
</div>
<div class="modal-footer">
<button type="button" class="btn btn-primary" data-dismiss="modal">Close</button>
</div>
</div>
</div>
</div>
<div class="modal" id="packagesModal" tabindex="-1" role="dialog" aria-labelledby="exampleModalLabel" aria-
hidden="true">
<div class="modal-dialog" style="width:90%; height:750px" role="document">
<div class="modal-content" style="height:80%">
<div class="modal-header">
<button type="button" class="close" data-dismiss="modal"><span
ariahidden="true">×</span><span class="sr-only">Close</span></button> <h4 class="modal-title"
id="lineModalLabel"></h4>
</div>
<div class="responsive-frame">
<iframe id="framePackages" class="framed-details" frameborder="0" src="" allow="autoplay;
encrypted-media" allowfullscreen></iframe> </div>
114
<div class="modal-footer">
<button type="button" class="btn btn-primary" data-dismiss="modal">Close</button>
</div>
</div>
</div>
</div>
<script>
$('#chartModal').on('show.bs.modal', function (event) { var button = $(event.relatedTarget);
var dataArray = button.data('whatever'); var packager = button.data('content');
var modal = $(this);
modal.find('.modal-title').text('Workload');
modal.find('#myChart').attr('data-content', dataArray);
var element = document.getElementById("myChart"); var ctx =
document.getElementById("myChart").getContext('2d'); this.chart = new Chart(ctx, { type: 'line', data: {
labels: ["Week1", "Week2", "Week3", "Week4", "Week5", "Week6", "Week7"], datasets: [{
label: "Packager`s workload", borderColor: 'rgb(255, 99, 132)',
data: element.getAttribute("data-content").split(","), fill: false
}, {
data: [25, 20, 16, 10, 11, 21, 21], label: "Team load", fill: false,
borderColor: "#3e95cd"
}]
}
});
});
$('#detailsModal').on('show.bs.modal', function (event) {
var button = $(event.relatedTarget); var packager = button.data('content'); var str =
'Roboboss/Details?username=' + packager; var modal = $(this);
modal.find('.modal-title').text('Issue details for ' + packager); modal.find('#frameDetails').attr('src', str);
});
$('#packagesModal').on('show.bs.modal', function (event) {
var button = $(event.relatedTarget); var keys = button.data('content');
var str = 'Roboboss/PreviousPackages?key=' + keys; var modal = $(this);
modal.find('.modal-title').text('Previous requests for the issue'); modal.find('#framePackages').attr('src', str);
});
$('#exampleModal').on('hidden.bs.modal', function () { this.chart.destroy();
});
$(document).ready(function () { $('#container').scrollspy({ target: ".scrollspy", offset: 50
});
});
//$(".navbar a").on('click', function (event) {
// event.preventDefault();
// var hash = this.hash;
// $('#container').animate({
// scrollTop: $(hash).offset().top – 50
// }, 800, function () {
// window.location.hash = hash;
// });
//});
</script>