rest_documentconversion_latest_conversion_thumbnail_32309534_1

Створення програмного сервісу Автоматизована система обліку оплати проїзду в міському пасажирському транспорті міста Києва незалежно від форм власності, що входить до складу єдиної інформаційно-аналітичної платформи консолідації та аналізу великих даних «Big Data» в місті Києві Шифр: ПС АСОП Технічне завдання на створення ПС АСОП 39194632.184154.4687.ТЗ Етап 1 п 1.1 На _____ аркушах

                                                      ЗМІСТ ПЕРЕЛІК ТЕРМІНІВ ТА СКОРОЧЕНЬ.. 6

1. ЗАГАЛЬНІ ВІДОМОСТІ 11

1.1      Найменування системи та її умовне позначення. 11 1.2      Шифр теми або номер договору: 11 1.3      Найменування організацій Замовника і Розробника, їх реквізити. 11 1.4      Підстави для розробки (перелік документів, на підставі яких створюється проект, ким і коли затверджені ці документи) 12 1.5      Планові терміни початку і закінчення роботи із створення Сервісу. 12 1.6      Порядок передачі замовнику результатів робіт по розробці Сервісу. 12

1. ПРИЗНАЧЕННЯ ТА МЕТА СЕРВІСУ.. 13

2.1      Призначення ПС АСОП.. 13 2.2      Мета і завдання створення ПС АСОП.. 13

1. НЕФУНКЦІОНАЛЬНІ ВИМОГИ ДО СЕРВІСУ.. 15

3.1      Вимоги чинного законодавства. 15 3.2      Вимоги до комплексу засобів захисту інформації 17 3.3      Вимоги до інформаційної безпеки. 20 3.4      Вимоги до режимів функціонування Сервісу. 21 3.5      Вимоги до чисельності та кваліфікації персоналу Сервісу та режиму його роботи. 21 3.6      Вимоги до надійності 22 3.7      Вимоги до ергономіки. 22 3.8      Вимоги до патентної чистоти. 24 3.9      Вимоги до стандартизації та уніфікації 24 3.10    Загальні вимоги до видів забезпечення. 25 3.11    Вимоги до інформаційного забезпечення. 25 3.12    Вимоги до лінгвістичного забезпечення. 26 3.13    Вимоги до програмного забезпечення. 26 3.14    Вимоги до технічного забезпечення. 27 3.15    Вимоги до організаційного забезпечення. 27 3.16    Вимоги до методичного забезпечення. 28 3.17    Проведення аналізу даних та формування інтерактивної звітності з використанням OLAP-технологій. 28 3.18    Вимоги до технологічної документації та методичного забезпечення. 29 3.19    Вимоги до апаратного забезпечення системи. 30

1. ФУНКЦІОНАЛЬНІ ВИМОГИ.. 31

4.1      Інтеграція та/або обмін даними з системами та/або базами даних щодо отримання інформації про утримувачів муніципальної картки «Картка киянина» (пільговиків та категорії їх пільг) 31 4.2      Інтеграція та/або обмін даними з системами та/або базами даних щодо отримання інформації про здійснення реєстрацій електронного квитка та факти оплати пасажиром транспортної послуги Перевізника. 31 4.3      Здійснення формування звітів. 32 4.4      Формування звітів різного типу по кількості та/або вартості використання транспортних продуктів в розрізі Перевізників, маршрутів, транспортних засобів, категорій пасажирів, пільгових категорій пасажирів тощо. 40 4.5      Формування звітів по агентам, що реалізують транспортні продукти для пасажирів у міському пасажирському транспорті 43 4.6      Формування звітів по перевізникам міста Києва, що відносяться до КП «Київпастранс» (далі – КПТ), КП «Київський метрополітен» (далі – КМ) та інших форм власності 46 4.7      Здійснення налаштування фільтрації для кожного звіту окремо. 48

1. ОПИС ПРОПОНОВАНОГО РІШЕННЯ.. 50

5.1      Рольова модель ПС АСОП.. 51 5.2      Джерела даних та їх перетворення в ПС АСОП.. 52 5.4.     Опис інтеграції з Платформою KYIVSMARTCITY у рамках модулю моніторингу. 59 5.5      Архітектура Сервісу АСОП.. 61 5.6      Опис компонента консолідації даних різних об’єктів функціонування та даних різних рівнів ієрархії для аналітичного дослідження інформації 68 5.7      Інтерактивні елементи у зручному та зрозумілому представленні із набором відповідних текстових та/або графічних інформаційних підказок. 69 5.8      Компонент управління правами доступу користувачів Сервісів з розподіленням доступу функцій в межах сервісів. 70

1. ПРОГРАМНА ТА АПАРАТНА ІНФРАСТРУКТУРА.. 75
2. ВИМОГИ ДО СКЛАДУ І ЗМІСТУ ПОСЛУГ З ПІДГОТОВКИ ОБ’ЄКТУ АВТОМАТИЗАЦІЇ ДО ВВОДУ СИСТЕМИ В ДІЮ... 78
3. КАЛЕНДАРНИЙ ПЛАН НАДАННЯ ПОСЛУГ. 80
4. ГАРАНТІЙНА ТА ПІСЛЯГАРАНТІЙНА ПІДТРИМКА.. 82

Регламент оновлення інформації у ПС АСОП.. 83

1. СПИСОК ТАБЛИЦЬ.. 85
2. СПИСОК РИСУНКІВ.. 86

ЛИСТ  РЕЄСТРАЦІЇ  ЗМІН.. 88

Повне найменування системи: Програмний сервіс для отримання даних з автоматизованої системи обліку оплати проїзду в міському пасажирському транспорті міста Києва незалежно від форм власності (далі – АСОП), а також даних про утримувачів муніципальної картки «Картка киянина» (умовне позначення – ПС АСОП). Умовне позначення: ПС АСОП, далі – Сервіс. Дане Технічне Завдання стосується розробки та впровадження ПС АСОП, який дозволить формувати аналітичні та статистичні звіти щодо виду транспортних продуктів, перевізників, , відображати достовірну аналітичну та оперативну інформацію у розрізі пільгові категорії пасажирів, підвищить зручність роботи користувачів ПС АСОП всіх типів із збереженням рівня надійності та зручності рішення. Програмний сервіс АСОП створюється як частина Платформи «Big Data» для відображення достовірної аналітичної та оперативної інформації щодо певних аспектів роботи системи АСОП у розрізі даних про утримувачів муніципальної картки «Картка киянина», в тому числі щодо пільговиків.

Договір № 4687 від 30.07.2019 р.

Замовник: Комунальне підприємство «Головний інформаційно-обчислювальний центр» Місцезнаходження: вул. Космічна, буд. 12а, м. Київ, 02192, Україна. п/р 35442136091290 ГУ ДКСУ в м. Києві, Код банку 820019, ЄДРПОУ 04013755, Свідоцтво пл. ПДВ №100093243, ІПН 040137526538. Розробник: Товариство з обмеженою відповідальністю «СІВІС». Місцезнаходження: вул. Амосова, буд. 4, офіс 8, м. Київ, 03141, Україна. ЄДРПОУ 39194632, п/р 26003052709939 в «Філія Розрах. центр» АТ КБ «ПРИВАТБАНК», Код банку 320649, ІПН 391946326582.

Розробка виконується згідно договору № 4687 від 30.07.2019р. Результат проведення закупівлі: код за ДК 021:2015: 72210000-0 Послуги з розробки пакетів програмного забезпечення (Створення, впровадження та модернізація платформи великих даних).

Початок робіт: 30.07.2019 р. Закінчення робіт: 26.12.2019 р.

Результати робіт передаються у вигляді функціонуючого програмного забезпечення на базі засобів обчислювальної техніки та іншого необхідного устаткування Замовника у строки, визначені договором. Приймання результатів здійснюється комісією у складі уповноважених осіб Замовника та Виконавця.

ПС АСОП призначено для відображення достовірної аналітичної та оперативної інформації щодо певних аспектів роботи системи АСОП у розрізі даних:

• Реалізації і використання транспортних продуктів
• Утримувачів муніципальної картки «Картка киянина» і використання пільгового проїзду.

ПС АСОП – це інтегрований предметно-орієнтований інформаційно-телекомунікаційний сервіс, що будується на основі централізованої програмно-технологічної платформи з уніфікацією програмно-технічних засобів розробки прикладної функціональності з використанням сучасних сервісно-орієнтованих технологій. У межах створення Сервісу використовуватимуться системи «Картка киянина», «АСОП» з метою аналізу інформації в зручному вигляді на веб-порталі. Дані з цих систем будуть надходити до створюваного сховища даних ПС АСОП, що в свою чергу буде включено в єдине інформаційне середовище (програмну платформу) «Big Data». Основною аудиторією користувачів Сервісу є керівництво і фахівці структурних підрозділів КМДА, державних і комунальних підприємств та організацій, які будуть використовувати Сервіс для забезпечення підтримки прийняття управлінських рішень.

Метою створення програмного сервісу АСОП є надання інформаційно-аналітичних інструментів, як основи для подальшого аналітичного дослідження великих даних, конструювання та опрацювання аналітичних та статистичних звітів з метою підтримки прийняття управлінських рішень. Основними завданнями Сервісу виступають:

• підвищення оперативності отримання достовірної інформації для проведення поглибленого аналізу з метою подальшого прийняття рішень;
• підвищення доступності необхідних даних для формування звітів для кінцевих користувачів;
• скорочення термінів підготовки періодичної аналітичної звітності за рахунок використання OLAP-технологій для аналітичної обробки даних.

Програмний сервіс АСОП створюється як частина Платформи «Big Data» для відображення достовірної аналітичної та оперативної інформації щодо необхідних аспектів роботи системи АСОП, у розрізі даних про утримувачів муніципальної картки «Картка киянина» та використанню транспортних продуктів для  підвищення зручності роботи користувачів всіх типів із збереженням рівня надійності та зручності рішення. Цілями розробки та впровадження ПС АСОП є:

• впровадження можливості отримувати інформацію про утримувачів муніципальної картки «Картка киянина» та АСОП задля подальшого формування аналітичної звітності з використанням OLAP-технологій;
• створення можливості отримувати оперативну, повну та достовірну інформацію про купівлю і використання транспортних продуктів, з метою проведення поглибленого аналізу і оцінки надання пасажирських перевезень пільговим категоріям громадян міста Києва, роботи міського пасажирського транспорту;
• забезпечення адміністрації перевізників, співробітників департамент транспортної інфраструктури можливостями, за допомогою яких вони матимуть змогу самостійно формувати будь які звіти в потрібних розрізах (в рамках існуючих даних), без залучення розробників та інших спеціалістів в межах програмного інтерфейсу ПС АСОП;
• створення можливості (згідно рольової моделі) через автоматизовані робочі місця (АРМ) керівникам структурних підрозділів КМДА надавати доступ через веб-інтерфейс з можливістю відображати інформацію (історичні дані за певний проміжок часу) про обслуговування та надання відповідних транспортних послуг громадянам міста Києва в тому числі в розрізі основних типів пільг в межах АСОП;
• підвищення якості надання послуг, контроль за цільовим використанням коштів задля забезпечення соціального захисту киян.

Сервіс має забезпечити:

• створення можливості отримувати дані про утримувачів муніципальної картки «Картка киянина» та АСОП для подальшого формування аналітичної звітності з використанням OLAP-технологій;
• створення можливості отримувати повну, оперативну і достовірну інформацію для проведення поглибленого аналізу і оцінки щодо надання пасажирських перевезень пільговим категоріям громадян міста Києва, роботи міського пасажирського транспорту тощо та прийняття рішень керівниками структурних підрозділів КМДА;
• забезпечення визначених категорій користувачів інструментами, які дозволять їм самостійно формувати довільні звіти в потрібних розрізах, без залучення розробників та інших спеціалістів в межах програмного інтерфейсу ПС АСОП;
• створення можливості (згідно рольової моделі) через автоматизовані робочі місця (АРМ) керівникам структурних підрозділів КМДА надавати доступ через веб-інтерфейс з можливістю відображати інформацію (історичні дані за певний проміжок часу) про обслуговування та надання відповідних транспортних послуг громадянам міста Києва в розрізі основних типів пільг в межах АСОП;
• підвищення ефективності контролю за якістю надання послуг та цільовим використанням коштів, передбачених для здійснення соціального захисту мешканців Києва.
  

Розробка Сервісу відбувається на підставі та з урахуванням вимог наступних нормативно-правових документів:

• Конституція України;
• Закону України «Про інформацію»;
• Закону України «Про електронні документи та електронний документообіг»;
• Закону України «Про адміністративні послуги»;
• Закону України «Про доступ до публічної інформації»;
• Закону України «Про захист інформації в інформаційно-телекомунікаційних системах»;
• Закону України «Про захист персональних даних»;
• Постанови Кабінету Міністрів України від 30.01.2013 р. № 57 «Про затвердження Порядку ведення Реєстру адміністративних послуг»;
• Постанови Кабінету Міністрів України від 04.02.1998 № 121 «Про затвердження переліку обов’язкових етапів робіт під час проектування, впровадження та експлуатації систем і засобів інформатизації»;
• Постанови Кабінету Міністрів України від 12.04.2002 № 522 «Про затвердження Порядку підключення до глобальних мереж передачі даних»;
• Постанови Кабінету Міністрів України від 10.09.2003 № 1433 «Про затвердження Порядку використання комп'ютерних програм в органах виконавчої влади»;
• Постанови Кабінету Міністрів України від 28.10.2004 № 1452 «Про затвердження Порядку використання електронних довірчих послуг в органах державної влади, органах місцевого самоврядування, підприємствах, установах та організаціях державної форми власності;
• Постанови Кабінету Міністрів України від 29.03.2006 № 373 «Про затвердження Правил забезпечення захисту інформації в інформаційних, телекомунікаційних та інформаційно-телекомунікаційних системах»;
• Програма Київської міської ради від 03.03.2016 № 116/116 «Про затвердження міської цільової програми «Турбота. Назустріч киянам» на 2016 - 2018 роки».
• Рішення Київської міської ради від 18 грудня 2018 року № 461/6512 «Про затвердження Комплексної міської цільової програми «Електронна столиця» на 2019-2022 роки;
• Розпорядження виконавчого органу Київської міської ради (Київської міської державної адміністрації) від 03 липня 2018 року № 1135 Про затвердження Положення про забезпечення захисту інформації в інформаційно-телекомунікаційних системах структурних підрозділів виконавчого органу Київської міської ради (Київської міської державної адміністрації), районних в місті Києві державних адміністрацій, підприємств, установ та організацій, що належать до комунальної власності територіальної громади міста Києва або передані до сфери управління виконавчого органу Київської міської ради (Київської міської державної адміністрації);
• Розпорядження Кабінету Міністрів України від 15 травня 2013 року N 386-р «Про схвалення Стратегії розвитку інформаційного суспільства в Україні»;
• Розпорядження Кабінету Міністрів України від 20 вересня 2017 року N 649-р «Про схвалення Концепції розвитку електронного урядування в Україні»;
• ДСТУ ISO/IEC/IEEE 12207:2018. Інженерія систем і програмних засобів. Процеси життєвого циклу програмних засобів;
• ДСТУ ISO/IEC/IEEE 42010:2018 Інженерія систем і програмних засобів. Опис архітектури (ISO/IEC/IEEE 42010:2011, IDT);
• ДСТУ ISO/IEC/IEEE 24765:2018 Інженерія систем і програмних засобів. Словник термінів (ISO/IEC/IEEE 24765:2017, IDT);
• ДСТУ ISO/IEC/IEEE 15288:2016 Інженерія систем і програмного забезпечення. Процеси життєвого циклу систем (ISO/IEC/IEEE 15288:2015, IDT);
• ДСТУ ISO/IEC/IEEE 29119-1:2017 Інженерія систем і програмних засобів. Тестування програмних засобів (ISO/IEC/IEEE 29119-1:2013, IDT);
• ДСТУ ISO/IEC 2382:2017 (ISO/IEC 2382:2015, IDT). Інформаційні технології. Словник термінів;
• ДСТУ ISO/IEC 15910:2012 Інформаційні технології. Документування програм. Документація користувача (ISO/IEC 15910:1999, IDT);
• ДСТУ ISO/IEC 14764:2014. Інженерія програмного забезпечення. Процеси життєвого циклу програмного забезпечення. Технічне обслуговування;
• ДСТУ ISO/IEC 11179-3:2005 Інформаційні технології. Реєстри метаданих (ІSO/ІEC 11179-3:2003, ІDT);
• ДСТУ 4302:2004 Інформаційні технології. Настанови щодо документування комп`ютерних програм (ISO/IEC 6592:2000, MOD);
• ДСТУ 3008:2015 Інформація та документація. Звіти у сфері науки і техніки. Структура та правила оформлювання;
• ДСТУ 2226-93 Автоматизовані системи. Терміни та визначення;
• ГОСТ 34.201-89. Інформаційна технологія. Комплекс стандартів на автоматизовані системи. Види, комплектність і позначення документів при створенні автоматизованих систем;
• ГОСТ 34.601-90. Інформаційна технологія. Комплекс стандартів на автоматизовані системи. Автоматизовані системи. Стадії створення;
• ГОСТ 34.602-89. Інформаційна технологія. Комплекс стандартів на автоматизовані системи. Технічне завдання на створення автоматизованої системи;
• ГОСТ 34.603-92. Інформаційна технологія. Види випробувань автоматизованих систем;
• РД 50-34.698-90. Методичні вказівки. Інформаційна технологія. Комплекс стандартів і керівних документів на автоматизовані системи. Автоматизовані системи. Вимоги до змісту документів;
• ДСТУ ISO/IEC 19790:2015 Інформаційні технології. Методи захисту. Вимоги безпеки до криптографічних модулів (ISO/IEC 19790:2012, IDT);
• ДСТУ 7564:2014 Інформаційні технології. Криптографічний захист інформації. Функція гешування;
• ДСТУ ISO/IEC TR 13335-4:2005 Інформаційні технології. Настанови з керування безпекою інформаційних технологій. (ISO/IEC TR 13335-4:2000, IDТ);
• ДСТУ 4145-2002 Інформаційні технології. Криптографічний захист інформації. Цифровий підпис, що ґрунтується на еліптичних кривих. Формування та перевіряння;
• ДСТУ 3396.0-96 Захист інформації. Технічний захист інформації. Основні положення;
• ДСТУ 3396.2-97 Захист інформації. Технічний захист інформації. Терміни та визначення;
• ДСТУ 2873-94 Системи оброблення інформації. Програмування. Терміни та визначення;
• ДСТУ 2941-94 Системи оброблення інформації. Розроблення систем. Терміни та визначення;
• НД ТЗІ 3.7-003-05. Порядок проведення робіт із створення комплексної системи захисту інформації в інформаційно-телекомунікаційній системі;
• НД ТЗІ 1.4-001-2000. Типове положення про службу захисту інформації в автоматизованій системі;
• НД ТЗІ 3.6-001-2000. Технічний захист інформації. Комп’ютерні системи. Порядок створення, впровадження, супроводження та модернізації засобів технічного захисту інформації від несанкціонованого доступу;
• НД ТЗІ 1.1-003-99. Термінологія в галузі захисту інформації в комп’ютерних системах від несанкціонованого доступу;
• НД ТЗІ 2.5-004-99. Критерії оцінки захищеності інформації в комп’ютерних системах від несанкціонованого доступу;
• НД ТЗІ 2.5-005-99. Класифікація автоматизованих систем і стандартні функціональні профілі захищеності оброблюваної інформації від несанкціонованого доступу;
• НД ТЗІ 3.7-001-99. Методичні вказівки щодо розробки технічного завдання на створення комплексної системи захисту інформації в автоматизованій системі;
• Business Process Model and Notation (BPMN), Version 2.0, Object Management Group, 2011;
• Unified Modeling Language (UML), Version 2.5.1, Object Management Group, 2017.

Вимоги із забезпечення захисту інформації реалізовуватимуться за рахунок створення комплексу засобів захисту, який складається із програмних засобів криптографічного захисту інформації, засобів підсистеми «Адміністрування» та засобів захисту операційних систем. У складі комплексу засобів захисту будуть застосовані програмні засоби криптографічного захисту інформації, які мають діючий позитивний експертний висновок Державної служби спеціального зв'язку та захисту інформації України. У Сервісі буде реалізований захищений доступ до системи на рівні логінів/паролів підключення до Сервісу, які шифруватимуться за алгоритмом хешування SHA-256, MD5. Також буде шифруватися доступ до ядра системи та всіх окремих елементів ( автоматизоване робоче місце (АРМ), підключені мережеві пристрої, пристрої модуляції сигналів тощо). Зв’язок між елементами системи будуватиметься на технології шифрованих тунелів, які разом об’єднуються у загальну внутрішню мережу. Для забезпечення конфіденційності та цілісності даних, що передаються між сервером програмних застосувань та веб-інтерфейс користувача а також двохфакторної ідентифікації (автентифікації) користувачів АРМ, буде використовуватися програмний засіб криптографічного захисту інформації, який відповідає наступним загальним вимогам:

• функціонує як невід’ємна частина Сервісу з визначеним переліком функцій;
• має можливість бути використаним у складі будь-якої інформаційної системи (автоматизованої системи), яка реалізована у якості портального рішення;
• реалізує наступні механізми:
• контроль цілісності програмного забезпечення;
• тестування правильності функціонування та блокування роботи в разі виявлення порушень;
• захист від порушення конфіденційності інформації внаслідок помилкових дій користувача або в разі некоректної роботи складових елементів;
• захист ключових даних на їх носіях від несанкціонованого зчитування;
• захист засобу від здійснення порушником навмисного зовнішнього впливу;
• захист від порушення конфіденційності та цілісності ключових даних в ключових документах;
• реалізує алгоритм шифрування даних відповідно до ДСТУ ГОСТ 28147:2009 у режимі гамування зі зворотним зв’язком;
• реалізує наступні формати, структури, протоколи, алгоритми:
• позначки часу відповідно до вимог RFC 3161 «Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP)» та вимог до протоколу Фіксування часу, що затверджені наказом Мін’юсту, Адміністрації Держспецзв’язку від 20.08.2012 № 1236/5/453 та зареєстровані в Мін’юсті 20.08.2012 за № 1402/21714;
• інтерактивного визначення статусу сертифіката відповідно до вимог RFC 2560 «Internet X.509 Public Key Infrastructure Online Certificate Status Protocol – OCSP» та вимог до протоколу визначення статусу сертифіката, що затверджені наказом Мін’юсту, Адміністрації Держспецзв’язку від 20.08.2012 № 1236/5/453 та зареєстровані в Мін’юсті 20.08.2012 за № 1403/21715;
• списку відкликаних сертифікатів відповідно до вимог RFC 5280 «Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile» та вимог до формату списку відкликаних сертифікатів, що затверджені наказом Мін’юсту, Адміністрації Держспецзв’язку від 20.08.2012 № 1236/5/453 та зареєстровані в Мін’юсті 20.08.2012 за № 1400/21712;
• об’єктні ідентифікатори для криптоалгоритмів, що є державними стандартами відповідно до вимог до структури об’єктних ідентифікаторів для криптоалгоритмів, що є державними стандартами, затверджені наказом Мін’юсту, Адміністрації Держспецзв’язку від 20.08.2012 № 1236/5/453 та зареєстровані в Мін’юсті 20.08.2012 № 1399/21711;
• запиту на формування сертифіката відкритого ключа, що створюються та обробляються об’єктом експертизи, відповідають вимогам (PKCS#10) Certification Request Syntax Specification;
• посиленого сертифіката відкритого ключа, що відповідає вимогам до формату посиленого сертифіката відкритого ключа, що затверджені наказом Мін’юсту та Адміністрації Держспецзв’язку від 20.08.2012 № 1236/5/453 та зареєстровані в Мін’юсті 20.08.2012 за № 1398/21710.

Для забезпечення конфіденційності та цілісності даних при введенні даних з клієнтських АРМ, захищеного збереження інформації про дії користувачів та адміністраторів системи буде застосований програмний засіб криптографічного захисту інформації, що відповідає наступним загальним вимогам:

• призначений для забезпечення конфіденційності та цілісності інформації шляхом здійснення її криптографічного перетворення (виконання функцій шифрування та дешифрування) та здійснює розмежування доступу до такої інформації, що зберігається на носіях інформації (жорсткий диск комп’ютера, переносний жорсткий диск, флеш-накопичувач) відповідно до ключових даних та сертифікатів відкритих ключів та забезпечує:
• створення та використання шифрованих файлових контейнерів (шифрованих віртуальних дисків);
• створення шифрованих контейнерів без файлової системи або з файловою системою NTFS чи FAT;
• можливість створення динамічних шифрованих файлових контейнерів;
• створення шифрованого носія на основі переносного жорсткого диску, флеш-накопичувача;
• можливість шифрування логічних дисків (томів) жорсткого диску комп’ютера, переносного жорсткого диску, флеш-накопичувача;
• реалізований у вигляді набору програмних модулів, готових до використання, та має можливість бути використаним у якості її окремої та незалежної частини (складової) з визначеним переліком функцій;
• реалізує алгоритм шифрування даних відповідно до ДСТУ 28147:2009 у режимі гамування зі зворотнім зв’язком;
• реалізацію криптографічних алгоритмів буде здійснено бібліотекою функцій криптографічних перетворень, що має позитивний експертний висновок Державної служби спеціального зв'язку та захисту інформації України за результатами державної експертизи в сфері криптографічного захисту інформації.

Захист компонентів від несанкціонованого доступу буде виконуватися за рахунок реалізації таких заходів:

• сеанс клієнт-сервер, під час роботи з проектом через Інтернет виконується тільки за HTTPs протоколом (захист за допомогою SSL/TLS сертифікату);
• для розгортання компонентів проекту, а також для доступу користувачів до серверів застосовується SSH протокол з використанням логіну та паролю доступу та RDP протокол з використанням логіну та паролю;
• SSH протокол працює по нестандартному порту (port:2002);
• RDP протокол працює по нестандартному порту (port:2003);
• всі процеси запускаються від імені непривілейованих користувачів;
• доступ до баз даних виконується за допомогою спеціалізованих облікових записів та паролів, які відповідають єдиним завданим політикам безпеки (строк дії пароля, кількість літер, чисел та символів).

Розробка та впровадження комплексної системи захисту інформації не є предметом даного договору, її може бути реалізовано в подальшому в межах виконання окремих робіт.  

Доступ до інформаційних ресурсів Сервісу надається з метою виконання функцій та завдань, які визначені в чинному законодавстві України, наказах, положеннях, розпорядженнях чи інших нормативних документах, або інших робіт згідно договору. Доступ до інформації з обмеженим доступом, що знаходиться у Сервісі, після підписання договору про конфіденційність і нерозголошення інформації надається через захищені канали зв’язку з використанням програмних або технічних засобів криптографічного захисту інформації, що мають позитивний експертний висновок ДССЗЗІ. При проектуванні ПС АСОП були реалізовані базові заходи безпеки інформації. При реалізації четвертої черги повинні використовуватися вже започатковані заходи безпеки, а саме:

• організаційно-адміністративні;
• апаратно-програмні;
• інженерно-технічні.

Вимоги щодо КСЗІ визначатимуться в окремому Технічному завданні, що буде розроблятись Виконавцем, якого буде визначено за результатами проведення окремої конкурсної процедури. Для забезпечення безпеки передачі даних між робочим місцем Користувача та серверним програмним комплексом у ПС АСОП буде передбачена можливість використання програмних засобів криптографічних перетворень, який має позитивний експертний висновок Державної служби спеціального зв'язку та захисту інформації України.

Експлуатація Сервісу передбачатиме такі режими:

1. Основний режим – режим штатного функціонування всіх модулів та компонентів за призначенням.
2. Нештатний режим – режим нештатного функціонування всіх компонентів Платформи.
3. Режим адміністрування – режим здійснення централізованого автоматизованого налагоджування та автоматизованого оновлення Сервісу одночасно із роботою решти користувачів в основному режимі.
4. Режим регламентного обслуговування – режим регламентного технічного обслуговування та відновлення працездатності технічних засобів компонентів Системи.

Рішення з чисельності та кваліфікації персоналу повинні забезпечити:

• безперервне супроводження Сервісу на всіх стадіях експлуатації та підтримки;
• цілодобовий режим роботи Сервісу та його компонентів/модулів/сервісів за призначенням в повному обсязі;
• централізований контроль працездатності Сервісу;
• усунення відмов роботи Сервісу;
• адміністрування (оперативне налагодження під час експлуатації) роботи Сервісу;
• своєчасне централізоване застосування оновлень програмного забезпечення.

Повинні бути запропоновані рішення щодо чисельності та кваліфікації обслуговуючого персоналу Сервісу. Пропозиція повинна бути обґрунтована та мати оптимізований склад обслуговуючого персоналу.

Надійність Сервісу АСОП повинна забезпечуватись за наступними напрямками:

• забезпечення працездатності компонентів Сервісу;
• збереження даних.

При відмові одного або декількох компонентів механізми із збереження працездатності повинні забезпечувати надійність роботи за рахунок їх резервування. При цьому відбуватиметься мінімальна концентрація уваги з боку системного адміністратора, щодо реакції на усунення наслідків відмов компонентів. Програмно-апаратними засобами повинно бути забезпечене збереження даних. Збереження даних повинно забезпечувати збереження цілісності даних при програмно-апаратних відмовах, помилках, шляхом використання відповідних програмно-апаратних засобів та рішень, резервного копіювання, транзакційності при змінах даних. Збереження даних буде забезпечено у випадках:

• вимкнення живлення;
• відмови технічних засобів обробки інформації;
• помилки, збоїв або руйнування програмного забезпечення;
• тимчасової відмови ліній зв’язку.

Надійність функціонування Сервісу АСОП буде забезпечено при:

• використанням сучасних технологій розробки (модернізації) прикладного програмного забезпечення та забезпеченням якісного його тестування;
• резервуванням основних компонентів;
• регламентом організації резервного копіювання та архівного збереження інформації;
• оперативністю заміни програмно-технічних засобів, що вийшли з ладу;
• сумісністю технічних засобів та програмного забезпечення.

Повинна бути реалізована одна з наступних стратегій забезпечення надійності:

Рішення щодо ергономіки веб-інтерфейсу ПС АСОП повинні відповідати вимогам технічної естетики та інженерної психології для забезпечення гармонійного зв'язку між параметрами технічних засобів і психофізичними можливостями людини із урахуванням створення єдиного об’ємно-просторового і кольорового рішення відповідно до ГОСТ 12.2.032–78, ГОСТ 12.2.033–78, ГОСТ 24750–81. Веб-сторінки повинні відповідати таким вимогам:

• Вміст веб-сторінок повинен бути структурованим, логічним, зрозумілим та легким для читання.

Дизайн ПС АСОП повинен відповідати таким вимогам (далі – дизайн-код):

• Компоненти веб-сторінок повинні мати зрозумілі назви, навігаційні елементи, які повторюються на багатьох веб-сторінках та однаково розташовуються, а компоненти з однаковою функціональністю – мати однакові назви та однаковий дизайн.
• Рекомендовано передбачити більше одного способу дістатися необхідної веб-сторінки.

Рішення щодо ергономіки забезпечуватимуть:

• зрозумілу логічну побудову інформаційної архітектури із певним набором відповідних графічних, текстових, функціональних компонентів.
• зрозумілу логічну побудову структуру сторінок та розділів, переходів та посилань між ними відповідно до інформаційної архітектури;
• глибину вкладень (логічних переходів) не більше 5 рівнів;
• зручну та інтуїтивно зрозумілу побудову логічних зв’язків в межах певної функціональності;
• прості інтуїтивно зрозумілі інтерфейси робочих місць, які не потребують тривалого навчання роботі з ними;
• форми відображення інформації користувачам, що функціонально орієнтовані на вирішення конкретних задач;
• мінімальну кількість дій користувача при виконанні завдань, відсутність в екранних формах функціональних можливостей, що не потрібні для виконання завдання, яке поставлене перед користувачем;
• інтерактивні елементи у зручному та зрозумілому представленні із набором відповідних текстових та/або графічних інформаційних підказок;
• не перевантаження інформаційно-графічними матеріалами. Рішення щодо ергономіки модулю відповідатимуть основним вимогам технічної естетики та інженерної психології, що забезпечить гармонійний зв'язок між параметрами технічних засобів та психофізичними можливостями людини.

Користувач повинен мати зручний інтерфейс із обґрунтованим набором необхідних інструментів для виконання певних дій, закладених у межах відповідного бізнес-процесу. У цілому передбачається сумісність:

• з операційними системами: Windows;
• з браузерами, у тому числі мобільними: Microsoft Edge, Opera, Mozilla Firefox, Google Chrome (наперед останніми релізами версій на момент надання послуг за календарним планом договору).

Веб-інтерфейс повинен відповідати таким вимогам щодо використання технологій при його створенні:

• Рішення повинне бути виконане з використанням елементів адаптивних технологій.
• Передбачається використання HTML4 / HTML5, JavaScript.
• Для накладення стильової інформації використовуються таблиці стилів CSS3.
• Використання таких технологій, як Flash, наприклад, у вигляді Flex або SilverLigh не передбачається.

Основні вимоги до інформаційно-графічних елементів веб-інтерфейсу:

• коректне типізоване відображення (сумісність) інформації в передостанніх версіях найбільш популярних веб-браузерів;
• графічний і структурний дизайн повинен бути виконаний з урахуванням плавної зміни розміру вікна веб-браузера. Під час перевищення деякого максимального розміру дизайн повинен передбачати заповнення зайвого місця фоновими матеріалами, які можуть бути збільшені без обмежень, наприклад, фоновою картинкою рівної структури;
• усі екранні форми користувацького інтерфейсу повинні бути виконані в єдиному графічному дизайні з однаковим розташуванням основних елементів управління і навігації.
• схожі операції повинні виконуватися з використанням ідентичних графічних елементів у повній відповідності до побудови (структури) інформаційної архітектури рішення.

Патентна чистота Сервісу буде забезпечена за рахунок використання при розробці ліцензійних апаратних і програмних засобів та обладнання і гарантується Розробником.

Стандартизація та уніфікація функцій Сервісу буде забезпечуватись за рахунок використання сучасних інструментальних програмних засобів які підтримують єдину технологію проектування і розробки функціонального, інформаційного та програмного забезпечень. У процесі розробки Сервісу будуть сформовані вимоги до розробки прикладного програмного забезпечення, які уніфікуватимуть процедуру обробки інформації, ідентифікацію програмних модулів та баз даних, типізуватимуть окремі програмні модулі відповідно до свого призначення. В даному документі описані вимоги до розробки прикладного програмного забезпечення, які уніфікують інтерфейс користувача, процедури обробки інформації, ідентифікацію програмних компонентів та баз даних, типізують окремі програмні модулі відповідно до свого призначення в різних функціональних підсистемах.

• Застосування сучасних інформаційних технологій.
• Застосування правила централізованого накопичення, зберігання та обробки інформації.
• Підтримка актуальності, повноти, несуперечності, цілісності та доступності інформації.
• Забезпечення надійного захисту інформації від порушення її цілісності, витоку та блокування згідно з порядком, встановленим нормативно-правовими державними актами і нормативними документами в галузі захисту інформації.
• Розподіл рівня доступу до даних Сервісу за різними рівнями та можливість гнучкого налаштування та адміністрування.
• Забезпечення надійності, резервування компонентів технічного забезпечення Сервісу;
• Забезпечення централізованого управління, безперервного контролю функціонування та централізованого налаштування Сервісу та його компонентів.
• Забезпечення можливості реалізації централізованого оновлення рішень за результатами модернізації/доопрацювання та налаштувань Сервісу в автоматизованому режимі.

Інформаційне забезпечення розробляється достатнім для найбільш ефективного використання всіх функцій Сервісу. Інформаційне забезпечення відповідатиме наступним вимогам та можливостям:

• забезпечення фізичної та логічної цілісності даних;
• мінімізація надмірності даних, що зберігаються;
• стандартизація представлення даних;
• достовірність та актуальність даних.

Мовні засоби програмування обиратимуться Виконавцем відповідно до рішень з програмного забезпечення Сервісу.

Програмне забезпечення (ПЗ) системи складатиметься з:

• загальносистемного програмного забезпечення (ЗПЗ);
• прикладного програмного забезпечення (ППЗ).

Програмне забезпечення системи відображатиме специфіку автоматизованих функціональних задач користувачів та забезпечуватиме:

• підтримку загальноприйнятих сучасних міжнародних стандартів до відкритих систем;
• сумісність та інтегрованість;
• підтримку функціонування в різнорідному апаратному і програмному середовищах;
• вмонтованість механізму захисту від помилок і підтримки цілісності;
• мінімальні витрати на їх закупівлю та експлуатацію.

До загальносистемного програмного забезпечення відносяться:

• операційні системи;
• система керування базами даних (СКБД);
• офісні застосування;
• тощо.

До прикладного програмного забезпечення відноситься програмне забезпечення, що розробляється та налаштовується під час створення системи. Розробка прикладного програмного забезпечення буде проводитись за допомогою сучасних інструментальних засобів програмної інженерії проектування і генерації розподілених баз даних (CASE-засобів) з урахуванням можливості подальшого автоматизованого тестування. При розробці ППЗ будуть використовуватися принципи модульності та типовості, які забезпечать послідовне нарощування функціональних можливостей системи за рахунок створення, впровадження та тиражування функціонально завершених програмних модулів. В цілому передбачається сумісність ППЗ:

• з операційними системами: Windows, Linux;
• з веб-браузерами: Edge, Google Chrome, Mozilla Firefox та Safari (останніх та передостанніх версій).

Основні вимоги до інформаційно-графічних елементів веб-інтерфейсу:

• Коректне типізоване відображення (сумісність) інформації в наперед останніх версіях на дату початку надання послуг за етапом згідно календарного плану найбільш популярних веб-браузерів:
• Chromе;
• Opera;
• Mozilla Firefox;
• Microsoft Edge.
• Графічний і структурний дизайни повинні бути виконані з урахуванням плавної зміни розміру вікна веб-браузера.
• Всі екранні форми користувальницького інтерфейсу повинні бути виконані в єдиному графічному дизайні з однаковим розташуванням основних елементів управління і навігації. Схожі операції повинні виконуватися з використанням ідентичних графічних елементів у повній відповідності до побудови (структури) інформаційної архітектури рішення.
• Для організації можливості подальшого автоматизованого тестування всі візуальні елементи веб-інтерфейсу повинні мати постійні унікальні ідентифікатори.
• Екранні форми мають бути налаштовані для відображення у мобільних додатках на планшетних пристроях у альбомному форматі. Відображення у портретному форматі не налаштовується, тому що частина інформації буде відображатись некоректно, що неприйнятно для користувача. Для окремих елементів необхідно більше місця при зміні орієнтації пристрою.

Склад програмних засобів, які будуть використовуватися при побудові сховища даних:

• Microsoft Server 2017;
• Microsoft SQL Express 2017;
• My SQL 8.0

Автоматизовані робочі місця користувачів Сервісу повинні бути розгорнуті на базі сучасних комп’ютерів та планшетів, технічні характеристики яких враховують функціональне використання автоматизованого робочого місця за призначенням в повному обсязі відповідно до вимог щодо якості функціонування Сервісу. Технічне забезпечення надається Замовником.

Організаційне забезпечення, що впроваджуватиметься в межах Сервісу, включатиме документи, які будуть відображати автоматизований технологічний процес обробки інформації та регламентуватимуть діяльність користувачів.

Рішення щодо методичного забезпечення будуть враховувати оптимізацію ділових (функціональних) процесів підрозділів відповідно до змін, що відображають автоматизацію цих процесів. В ході виконання робіт Виконавець може надати пропозиції щодо змін у нормативні акти (за необхідності), в нормативно-технічну документацію відповідно до прийнятих технічних та організаційних рішень у Сервісі. Вимоги щодо методичного забезпечення можуть бути уточнені в ході роботи над Сервісом.

Куби OLAP використовуються для створення та обслуговування сховищ даних. Куб OLAP представляє структуру даних в SQL службам Analysis Services (SSAS), побудований, на основі даних зі сховища ПС АСОП, для подальшого аналізу даних. Рисунок 1.Макет представлення даних в ПС АСОП Необхідно реалізувати можливість консолідації і зберігання даних OLAP кубу. Програмний сервіс має забезпечити:

• Час на формування звіту з OLAP кубу не повинен перевищувати 5 секунд.
• Можливість зведення даних з різних баз (АСОП, КК) в єдиний простір сховище ПС АСОП.
• Можливість проведення подальшого бізнес-аналізу ситуації за принципом «що буде, якщо».
• Детальність представлення результатів може змінюватися в залежності від потреби.
• Можливість побудови багатовимірних зв'язків для можливості виявлення і визначення прихованих залежностей.
• Автоматичне обслуговування куба без втручання адміністратором, включно з виконанням обробки, секціонуванням, перекладом і локалізацією, а також зміни схеми.

Вся документація оформлюється українською мовою в двох примірниках та затверджується в друкованому вигляді з наданням копій в електронному вигляді. Технічна документація розробляється у відповідності до чинних державних стандартів та з використанням термінології згідно галузевих і корпоративних стандартів. Склад документації на створення набору Сервісів повинен включати наступне:

1. Звіт з аналізу бізнес-процесів.
2. Технічне завдання.
3. Програма та методика попередніх випробувань.
4. Програма та методика дослідної експлуатації.
5. Описи Сервісу.
6. Інструкція.
7. Програмне забезпечення на цифровому носії із відомістю (із вихідними кодами).
8. Керівництво Адміністратора.
9. Керівництво Користувача.
10. Протокол попередніх випробувань.
11. Протокол дослідної експлуатації.

Склад та зміст технологічної документації може бути розширений Виконавцем за згодою Замовника. Технологічна документація Сервісу оформлюється в обсязі, визначеному діючими стандартами та достатньому (за повнотою і змістом) для використання Сервісу обслуговуючим персоналом та користувачами Сервісу її функціональних можливостей в повному обсязі. У межах супроводження та технічного обслуговування Сервсіса Виконавецьукладає Угоду (не фінансову) про нерозголошення (Non-disclosure agreement) (шаблон документу надається Замовником).

Склад та технічні параметри засобів апаратного забезпечення системи, а саме електронно-обчислювальних машин, мережевої апаратури, допоміжного обладнання тощо, повинні відповідати наступним вимогам:

• забезпечення реалізації функціональності системи у повному обсязі;
• відповідність наявних технічних засобів у Замовника мінімальній специфікації обладнання системи;
• врахування зростання вимог до обладнання у перспективі;
• взаємна сумісність різних типів апаратних засобів Замовника;
• можливість організації інтеграції з зовнішніми системами, апаратними засобами, тощо;
• забезпечення найвищої якості та продуктивності роботи системи.

Всі компоненти апаратного забезпечення та інфраструктури, які використовуються для розгортання системи, по винні відповідати вимогам сучасності, максимальної ефективності та швидкодії. Автоматизовані робочі місця (АРМ) користувачів системи розгортаються виключно з використанням сучасного комп'ютерного обладнання, яке забезпечує функціонування системи в оптимальному режимі та у повному обсязі.

Інтеграція та обмін даними з базами даних повинно бути реалізовано для отримання інформації про утримувачів муніципальної картки «Картка киянина», а також пільговиків та категорії їх пільг з Інформаційно-телекомунікаційної системи «Реєстр утримувачів муніципальної картки «Картка киянина» (далі – ІТС РУ МК КК) (див. Рисунок 2). Рисунок 2. Обмін даними з ІТС РУ МК КК Дані накопичуються в OLAP-кубі шляхом внесення через завантаження файлів на FTP сервері і подальшому записі до бази даних, порядок і формат даних описаний в Додатку 1  Регламент оновлення інформації ПС АСОП.

Інтеграція та обмін даними з базами даних повинно бути реалізовано для отримання інформації про інформації про здійснення реєстрацій електронного квитка з Інформаційно-телекомунікаційної системи Автоматизована система обліку оплати проїзду в міському пасажирському транспорті міста Києва незалежно від форм власності (далі – ІТС АСОП) (див. Рисунок 2). Рисунок 3. Обмін даними з ІТС АСОП Дані накопичуються в OLAP-кубі шляхом внесення через завантаження файлів на FTP сервері і подальшому записі до бази даних, порядок і формат даних описаний в Додатку 1  Регламент оновлення інформації ПС АСОП.

Програмний Сервіс дозволить формувати різноманітну звітність у вигляді зведених таблиць. Використовуючи інструменти, що дозволяють відфільтровувати по тим чи іншим параметрам. Рисунок 4. Макет вікна Робоча область повинна мати результат опрацювання запиту.











Пункт «Дані» має дозволити відкрити дані які не відносяться до Програмного Сервісу АСОП (віддалене сховище) для можливості подальшого аналізу. Рисунок 5. Макет форми завантаження даних
Пункт «Відкрити» має дозволити відобразити дані з Локального файлу на пристрої користувача для можливості подальшого аналізу. Рисунок 6. Макет форми внесення звіту
Для вивантаження звіту необхідно натиснути на кнопку «Зберігти», відобразиться вікно підтвердження вивантаження. Рисунок 7. Макет кнопки вивантаження файл. Після натискання на дану кнопку повинно відобразитись вікно «Підтвердження»
Рисунок 8. Макет вікна підтвердження вивантаження файлу           Сформована зведена таблиця має зберігатись файл у форматі json на пристрої користувача. Для реалізації можливості збереження файлу у форматах : doc, docx, xls, xlsx, pdf, які можливо відкрити за допомогою будь-якого текстового редактора (Microsoft Word, Блокнот тощо) буде використовуватись елемент «Експорт», при наведені буде відображатись доступний перелік форматів.
Рисунок 9. Макет реалізації вивантаження звітів
Пункт «Графіки» повинен дозволяти змінити відображення даних у зведеній таблиці у графічному вигляду Рисунок 10. Макет вибору пунктів, представлення звіту у графічному вигляді  
Кнопка «Таблиця» повинна дозволяти повернутися до форми зведеної таблиці Рисунок 11. Макет кнопки «Таблиця» Кнопка «Опції» дасть змогу додатково вказувати параметри відображення даних, для додаткової можливості відображати дані: загальні підсумки, проміжні підсумки, параметри. Рисунок 12
. Макет форми зміни параметрів відображення даних При зміні параметрів відображення даних у зведеній таблиці змінюється у відповідності до вибраних параметрів. Кнопка «Поля» дозволить відкрити вікно формування звіту який буде відображений у зведеній таблиці
Рисунок 13. Макет кнопки «Поля» Серед усіх наявних параметрів реалізувати можливість обирати за принципом логічних операторів. Кожен з цих вимірів буде можливо перетягнути за допомогою лівої кнопки миші у: фільтри, колонки, рядки, міри. У вікні конструктора, де повинна бути представлена основна частина, яка містить робочі панелі: фільтри, рядки, колонки. Зліва повинна бути можливість фільтрації та пошуків. В залежності від обраних фільтрів можливо сформувати звіт. Для цього необхідно:

1. Поля вимірів повинні перетягуватися за допомогою миші.
2. Натиснути на панелі кнопку «Застосувати».

Рисунок 14. Макет таблиці Вимірів Необхідно відобразити можливість

• Дата купівлі, що містить:
• Дата. День.
• Дата. Місяць.
• Дата. Рік.
• Дата валідації, що містить:
• Дата валідації. День.
• Дата валідації. Місяць.
• Дата валідації. Рік.
• Агентам:
• Місце оплати.
• Назва банку.
• Назва каси.
• Тип картки (картка метрополітену, Kyiv Smart City).
• Іd картки ( картка киянина, картка метрополітену, Kyiv Smart City, разовий квиток, учнівський квиток).
• Дата.
• Метод оплати.
• Назва продукту (купівля катки, QR, поповнення і т.д).
• Сума.
• Перевізникам:
• Вартість валідованого продукту.
• Дата валідації.
• Депо.
• Іd картки ( картка киянина, картка метрополітену, Kyiv Smart City, разовий квиток, учнівський квиток).
• Лінія станцій.
• Назва станції.
• Номер маршруту.
• Тип картки (картка киянина, картка метрополітену, Kyiv Smart City, разовий квиток QR, учнівський квиток)
• Тип транспорту.
• Час/дата валідації.
• Пасажирам:
• Ідентифікатор транспортного продукту.
• Категорія пільговика (перша по якій дійсна пільга на проїзд).
• Район проживання пільговика.
• Стать.
• Іd картки ( картка киянина, картка метрополітену, Kyiv Smart City, разовий квиток, учнівський квиток).
• Назва банку що сплачує за пільговика.
• Статус картки.

У верхній правій частині екрану над робочими панелями потрібно розмістити кнопки для здійснення додаткових операцій над формуванням звіту (див. Рисунок 15):

• «Додати міру»;
• «Застосувати»;
• «Відмінити».

За необхідності буде реалізована можливість відмінити застосовані міри або дії Рисунок 15. Макет розміщення кнопок на конструкторі звіту Кнопка «Додати міру» дозволяє:

• Ввести назву міри для зручного пошуку або скористатися вже сформованим переліком мір.
• Обрахувати індивідуальні значення.
• Відредагувати формулу з використанням математичних операторів (+, -, х, OR тощо).

Рисунок 16. Обрахування міри

Компонент повинен забезпечувати, формування звітів різного типу по кількості та/або вартості використання транспортних продуктів. Компонент має включати:

• Блок даних по перевізникам.
• Блок даних по маршрутам.
• Блок даних по транспортним засобам.
• Блок даних по категоріям видів носіїв електронного квитка.
• Аналітичні інструменти для обробки блоків даних і формування довільних звітів.
• Модуль формування користувацьких звітів шляхом додавання даних через передбачену в веб-інтерфейсі форму.

Звіт формується у вигляді  зведеної таблиці і має бути відображений у відповідній веб-формі, числовими значеннями, можливістю фільтрації даних а також інтерпретації даних до графічного відображення (діаграма і гістограма). При використані аналітичних формул вирішити проблему стандарту IEEE 754  реалізувати можливість збереження і відображення чіткої суми (приклад: при використані формули: =1,324-1,319 результат 0, 00500000000000012.). При неможливості відображення звіту в веб-формі з причин технологічного обмеження, реалізувати можливість вивантаження звіту на пристрій користувача з відповідними параметрами які зазначаються користувачем системі. Звіти різного типу по кількості та/або вартості використання транспортних продуктів в розрізі Перевізників, маршрутів, транспортних засобів, категорій пасажирів, пільгових категорій пасажирів тощо, повинен відображати наступну інформацію: Таблиця 1. Характеристика полів для побудови звітів по використанню транспортних продуктів.

Спосіб відображення інформації повинен відповідати шаблону (Рисунок 17). Рисунок 17. Макет вибору фільтру Рисунок 18. Макет сформованого звіту

Компонент повинен забезпечувати, формування звітів по агентам, що реалізують транспортні продукти для пасажирів у міському пасажирському транспорті. Компонент має включати:

• Блок даних по агентам.
• Блок даних по категоріям пасажирів.
• Аналітичні інструментів для обробки блоків даних і формування довільних звітів.
• Модуль формування користувацьких звітів шляхом додавання даних через передбачену в веб-інтерфейсі форму.

Звіт по агентам, що реалізують транспортні продукти для пасажирів у міському пасажирському транспорті, повинен відображати наступну інформацію: Таблиця 2. Характеристика полів для побудови звітів по реалізації агентами транспортних продуктів

Звіт формується на підставі зведеної таблиці і має бути відображений у відповідній веб формі, числовими значеннями, можливістю фільтрації даних а також інтерпретації даних до графічного відображення (діаграма і гістограма). Реалізувати можливість приховування дублюючих записів, а також наявність інформаційних підказок про походження інформації. При використані аналітичних формул вирішити проблему стандарту IEEE 754  реалізовати можливість збереження і відображення чіткої суми (Приклад при використані формули: =1,324-1,319 результат 0,00500000000000012). При неможливості відображення звіту в веб-формі з причин технологічного обмеження, реалізувати можливість вивантаження звіту на пристрій користувача з відповідними параметрами які зазначаються користувачем системі, реалізувати можливість вивантаження звіту у форматах визначені пунктом 3.4.

Компонент повинен забезпечувати, формування звіти по перевізникам міста Києва, що відносяться до КП КПТ, КМ та інших форм власності. Компонент має включати:

• Блок даних по перевізникам.
• Блок даних по категоріям пасажирів.
• Блок даних по маршрутам.
• Блок даних по транспортним засобам.
• Аналітичні інструментів для обробки блоків даних і формування довільних звітів.
• Модуль формування користувацьких звітів шляхом додавання даних через передбачену в веб-інтерфейсі форму.

Звіти по перевізникам міста Києва, що відносяться до КП КПТ, КМ та інших форм власності, повинен відображати наступну інформацію: Таблиця 3. Характеристика полів для побудови звітів по перевізникам

Звіт формується на підставі зведеної таблиці і має бути відображений у відповідній веб формі, числовими значеннями, можливістю фільтрації даних а також інтерпретації даних до графічного відображення (діаграма і гістограма). Реалізувати можливість приховування дублюючих записів, а також наявність інформаційних підказок про походження інформації. При використані аналітичних формул вирішити проблему стандарту IEEE 754  реалізувати можливість збереження і відображення чіткої суми (Приклад при використані формули: =1,324-1,319 результат 0,00500000000000012). При неможливості відображення звіту в веб-формі з причин технологічного обмеження, реалізувати можливість вивантаження звіту на пристрій користувача з відповідними параметрами які зазначаються користувачем системі, реалізувати можливість вивантаження звіту у форматах визначені пунктом 3.4.

При роботі з даними користувач повинен мати можливість обрати інформацію, наприклад, по декільком видам пільг, продуктам, перевізникам тощо.  Так, наприклад у звіті по агентам буде можливість фільтрувати за такими полями:

• Назва агенту.
• Банк.
• Назва продукту.
• Каса.
• Кількість поїздок.
• Сума коштів.
• Фільтри.
• Разовий квиток (QR-код).
• Разова поїздка з гаманця особової картки.
• 1-9 поїздок (8 грн.).
• 10-19 поїздок (7,70 грн.).
• 20-29 поїздок (7,40 грн.).
• 30-39 поїздок (7,10 грн.).
• 40-49 поїздок (6,80 грн.).
• 50 поїздок (6,50 грн.).
• Студентський квиток (50 %).
• Учнівський квиток.
• КМДА пільгова картка (100 %).
• Службовий КПТ.
• Службовий Метрополітен.
• Державна пільгова картка (100 %).
• Проїзний на визначений період без обмеження кількості поїздок.
• Період вибірки даних.
• Ідентифікатор районна (для користувачів картки киянина).
• Метод оплати.
• Місце оплати.
• Стать користувача.

У звіті по перевізникам:

• Разовий квиток (QR-код).
• Разова поїздка з гаманця особової картки.
• 1-9 поїздок (8 грн.).
• 10-19 поїздок (7,70 грн.).
• 20-29 поїздок (7,40 грн.).
• 30-39 поїздок (7,10 грн.).
• 40-49 поїздок (6,80 грн.).
• 50 поїздок (6,50 грн.).
• Студентський квиток (50 %).
• Учнівський квиток.
• КМДА пільгова картка (100 %).
• Службовий КПТ.
• Службовий Метрополітен.
• Державна пільгова картка (100 %).
• Проїзний на визначений період без обмеження кількості поїздок.
• Період вибірки даних.

Програмний сервіс АСОП повинен бути створений, як частина Платформи «Big Data» для відображення достовірної аналітичної та оперативної інформації щодо певних аспектів роботи системи АСОП у розрізі даних:

• Реалізації і використання транспортних продуктів
• Утримувачів муніципальної картки «Картка киянина» і використання пільгового проїзду.
• Проводити обрахунки отриманих даних від АСОП
• Представляти отримані дані у вигляді графіків / діграм.

Оновлення даних в базі даних ПС АСОП відбувається в нічний час, в період найменшого навантаження на бази даних ЗІС. У межах створення Сервісу використовуються джерела даних, для яких будуть налаштовані компоненти, а саме:

• технологія OLAP;
• сховище зберігання даних;
• компонент побудови звітів;
• програмні сервіси для обробки запитів та представлення даних.

Технологія OLAP є ключовим компонентом організації сховищ даних. Ця технологія заснована на побудові і візуалізації багатовимірних кубів даних з можливістю довільного маніпулювання даними, що містяться в кубі. Це дозволяє представити дані для аналізу в будь-якому розрізі. Куб OLAP представляє структуру даних в SQL службам Analysis Services (SSAS), побудований, за допомогою бази даних «Сховище ПС АСОП», для подальшого представлення та аналізу даних. Сховище зберігання даних – це сховище ПС АСОП для консолідації даних, що надходять з зовнішніх джерел даних (БД КК та БД АСОП). Для побудови сховища даних необхідними є наявність:

• Microsoft Windows Server 2017;
• Microsoft SQL Express Server 2017;
• MySQL 0.

Компонент побудови звітів дозволяє на основі даних, що надходять із зовнішніх інформаційних систем (АСОП та «Картка киянина») формувати звіти за допомогою технології OLAP для поглибленого аналізу та оцінки:

• Реалізації транспортних продуктів агентами.
• Утримувачів муніципальної картки «Картка киянина» і використання пільгового проїзду.
• Використання транспортних продуктів пасажирами.
• Ефективність роботи перевізників.

Компонент побудови звітів складається з модулів:

• Сервіс обробки запитів.
• Сервіс представлення даних.
• Модуль аналітичних обрахунків.

Звернення користувачів надходять на центральний рівень до серверу додатків та баз даних за отриманням необхідних даних.

У відповідності зі звітом по аналізу бізнес процесу передбачається наступна рольова модель:

• Користувач - внутрішній користувач системи Замовника;
• Користувач публічної інформації - мешканець м. Києва;
• Адміністратор.

1. Користувач

Мета та завдання діяльності:  Основна мета діяльності Користувача – самостійно формувати довільні звіти в потрібних розрізах роботи автоматизованої системи обліку оплати проїзду в міському пасажирському транспорті міста Києва, отримувати дані про утримувачів муніципальної картки «Картка киянина» та АСОПу для подальшого формування аналітичної звітності. 

1. Користувач публічної інформації

Мета та завдання діяльності:  Основна мета діяльності Користувача публічної інформації – бачити загальну статистику роботи автоматизованої системи обліку оплати проїзду в міському пасажирському транспорті міста Києва, муніципальної картки «Картка киянина» та АСОПу. 

1. Адміністратор

Мета та завдання діяльності:  Адміністратор - посадова особа у складі персоналу, який необхідний для забезпечення адміністрування Системи в межах відповідних підрозділів Замовника.  Функціональні обов’язки Адміністратора : 

• забезпечити роботу системи в цілому і відповідати за достовірність даних, що зберігаються;
• здійснювати моніторинг реєстру користувачів системи та регламентувати їх права доступу до Системи;
• проводити моніторинг технічного складу сервісу:
• завантаженості процесорів;
• завантаженості операційної пам’яті; 
• завантаженості фізичних дисків; 
• завантаженості мережевих інтерфейсів; 
• приймати рішення з питань, які стосуються технічного супроводу сервісу; 
• планувати та проводити резервне копіювання і відновлення інформації. Передбачається, що збереження відбуватиметься шляхом тіньового копіювання сервера, на якому розташовується ПС АСОП. Збереження даних відбувається щоденно;
• здійснювати процедури регламентного обслуговування ПС АСОП, що полягає у виконанні
• оптимізації на основі використання, яка передбачає, що OLAP куб обчислює і зберігає заздалегідь зібрані агрегати разом з даними. Якщо запит може бути задоволений, то, натиснувши на агрегат, сервер OLAP виконає даний запит і пришвидшить формування звіту;
• Запрограмованих і пакетних завдань адміністратора, які  дозволяють створювати сценарії для поліпшення використання ПС АСОП.

В основу інформаційного забезпечення Сервісу повинен бути покладений принцип однократного введення і єдиного місця збереження інформації та багаторазового її використання для рішення задач Сервісу. Аналізуючи дані, схема інформаційних потоків буде мати наступний вигляд: Рисунок 19.Схема інформаційних потоків в ПС АСОП Забезпечення створення шлюзу обміну даними із ЗІС КП ГІОЦ повинно відбуватиметься шляхом:

1. Вивантаження даних зі ІТС АСОП і ІТС РУ МК КК на FTP сервер, вивантаження даних представлених у Таблиці 1 до сховища даних ПС АСОП;
2. Передача даних до OLAP кубу і перетворення їх у формат описаний у розділі 5.6;
3. Запис даних до OLAP кубу;
4. Багаторівневе кешування OLAP кубу;
5. Опрацювання запитів отриманих від сервісу обробки запитів, вибір отриманих параметрів;
6. Передача звіту до сервісу представлення даних.

Процедури оновлення даних з завданою регулярністю підключатимуться до БД для проміжних даних, перевіряють повноту даних, обробляють, перетворюють та завантажують їх на віртуальну машину – сервери баз даних та додатків ПС АСОП. Звернення користувачів надходитимуть до серверу застосувань та баз даних за отриманням необхідних даних. Візуально модель структури даних в ПС АСОП має наступний вигляд : Рисунок 20. Модель структури даних в ПС АСОП У відповідності до моделі проведемо опис наявних даних: Таблиця 4. Структура даних довідника «Оплата»

Таблиця 5. Структура даних довідника «Підтвердження валідації»

Таблиця 6. Структура даних довідника «Пільгова категорія»

Таблиця 7. Структура даних довідника «Дані про реєстрацію проживання»

Таблиця 8. Структура даних довідника «Стать»

Таблиця 9. Структура даних довідника «Платіжна картка»

<HTML><ol></HTML> <HTML><li></HTML><HTML><ul></HTML> <HTML><li></HTML> Опис інтеграції з Платформою KYIVSMARTCITY у рамках авторизації<HTML></li></HTML><HTML></ul></HTML> <HTML></li></HTML><HTML></ol></HTML> Реалізація взаємодії Платформи Big Data та Модуля авторизації дозволить уніфікувати доступ користувачів до ПС АСОП. Процес авторизації користувача здійснюється відповідно до моделі бізнес-процесу авторизації користувачів. Рисунок 21. Модель бізнес-процесу авторизації користувачів           Користувач обирає відповідну вкладку і натискає на неї. Для подальшого перегляду, відображається інформаційне повідомлення «Для перегляду інформації на сторінці необхідна авторизація через Київ ID» Після натискання на кнопку «Авторизуватись через Kyiv ID» на сторінці Платформи Big Data повинна переадресувати користувача на сторінку входу до «Єдиного облікового запису киянина». Рисунок 22. Сторінка «Єдиний обліковий запис киянина» Технічний опис отримання даних від kyiv smart city наступний:

1. Користувач у на Платформі Big Data тисне на кнопку «Авторизуватись через Kyiv ID».
2. Платформа Big Data виконує арі-запит POST /authorize до модуля авторизації
3. Виконується перехід на форму авторизації модуля.
4. Користувач виконує ідентифікацію себе довільним способом, тисне ОК.
5. Виконується переадресація за посиланням redirect_uri, вказаним у запиті в п.2
6. Отримується авторизаційнний токен з даними ідентифікатору користувача.

Для того, щоб увійти до Сервіс, користувач повинен бути зареєстрований Адміністратором сервісу.

Реалізація взаємодії Платформи Big Data та Модуля моніторингу дозволить проводити моніторинг ресурсів сервісу, консолідувати інформації про роботу різних компонентів сервісу і систем (які взаємодіють з ПС АСОП). Процес моніторингу здійснюється відповідно до моделі бізнес-процесу авторизації користувачів. Рисунок 23 Макет бізнес-процесу передачі інформації до модуля моніторингу У межах реалізації електронної взаємодії Сервісів Платформи Big Data та Модуля обліку та моніторингу Платформи KYIVSMARTCITY повинен бути встановлений агент по збору:

• Логів, який буде забезпечувати збір наступних логів:
• логи доступу;
• логи інтеграцій;
• логи помилок.
• Метрик, який буде забезпечувати збір наступних метрик:
• завантаженість процесорів;
• завантаженість операційної пам’яті;
• завантаженість фізичних дисків;
• завантаженість мережевих інтерфейсів.

Для можливості роботи з Модулем обліку та моніторингу Платформи KYIVSMARTCITY Платформа «Big Data» повинна зареєструватися в якості «клієнта» в Модулі авторизації Платформи KYIVSMARTCITY та отримати від нього такі дані:

• Реєстраційне ім'я (client_id);
• Пароль (client_secret);
• Набір повноважень (scope).

Реалізація електронної взаємодії Платформи Big Data та Модуля обліку та моніторингу дозволить використовувати уніфікований інструмент збору логів і метрик для онлайн-аналізу працездатності. У межах електронної взаємодії з Модулем обліку та моніторингу на сервері Платформи Big Data повинен бути встановлений: Агент зі збору логів, який повинен забезпечувати збір логів, що будуть зберігатися у Модулі обліку та моніторингу: Логи доступу ПС АСОП:

• KyivID користувача;
• Дата та час виконання операції.

Логи інтеграцій:

• Назву системи чи модуля, до якого виконується запит;
• Запит;
• Відповідь системи чи модуля.

Логи помилок (див. Таблиця . Базовий набір статусів відповідей):

• Дата та час виникнення помилки;
• Номер, опис або причину помилки (інформація щодо самої помилки).

Агент зі збору метрик, який повинен забезпечувати збір метрик, що будуть зберігатися у Модулі обліку та моніторингу: Завантаженість процесорів:

• Дані метрику;
• Значення дати та часу отримання значення;
• ID системи, від якої отримано метрику.

Завантаженість операційної пам’яті:

• Дані метрику;
• Значення дати та часу отримання значення;
• ID системи, від якої отримано метрику.

Завантаженість фізичних дисків:

• Дані метрику;
• Значення дати та часу отримання значення;
• ID системи, від якої отримано метрику.

Завантаженість мережевих інтерфейсів:

• Дані метрику;
• Значення дати та часу отримання значення;
• ID системи, від якої отримано метрику.

У відповідності до технічних вимог Платформа «великих даних», складається з таких компонентів:

1. Джерела даних. Система управляє параметрами підключення до джерел даних та повинна підтримувати різні формати вхідних даних:
   • API функції інших систем;
   • SQL запити через підключення безпосередньо до Баз даних інших зовнішніх систем;
   • Структуровані файли (csv, xml, тощо).
2. ETL-процес завантаження, перетворення, очистки за збереження вхідних даних. Система контролює своєчасну поставку дану та коректність даних що поступають на вхід системи;
3. Збереження даних реалізується підсистемою збереження даних. Реалізація підсистеми збереження даних необхідно реалізовувати на базі безкоштовних сервісів баз даних або існуючій інфраструктурі Замовника;
4. Перетворення даних - це автоматичні процедури які виконуються в системі які роблять відповідні розрахунки, агрегації або інші процедури зміни даних, що необхідні для функціонування системи та подальшого аналізу та відображення. Система контролює виконання регулярних дій цих процедур згідно з налаштованим графіком виконання.
5. Аналіз даних виконується на основі OLAP-кубів які є частиною платформи. Система контролює виконання регулярних дій оновлення даних в кубах.
6. Вітрини даних - це фронтенд частина платформи направлена на візуалізацію та відображення даних користувачам. Система виконує функції авторизації користувачів та контроля їх доступу до відповідних наборів даних.

Рисунок 24. Архітектурна схема Платформи великих даних Джерелами даних в ПС АСОП є:

1. АСОП;
2. ІТС РУ МК КК.

Обмін даними з цими системами буде реалізований за допомогою постачання файлів через FTP-папку. ETL-процес:

• Необхідно розробити регламент отримання даних
• Процедури вивантаження та обробки даних
• Забезпечити контроль своєчасної поставки даних та їх коректність.

Збереження даних необхідно реалізувати засобами побудови сховища даних, які є складовими платформи Big Data. Сервіс Платформи великих даних - ПС АСОП передбачає створення трирівневої сервісно-орієнтованої клієнт-серверної архітектури у складі наступних рівнів/шарів: Сховище даних - будуватиметься на основі використання сучасних реляційних систем керування базами даних що передбачають шифрування даних і отримання інформації із двох зовнішніх систем:

1. АСОП;
2. ІТС РУ МК КК.

• Рівень серверів застосувань - буде складатись із наступних взаємопов’язаних компонентів:
  • сервіси загальносистемних засобів та реалізації бізнес-логіки прикладної функціональності;
  • сервіси інформаційної взаємодії з іншими компонентами та інформаційними системами.
• Рівень представлення - буде забезпечувати реалізацію прикладної функціональності клієнтських робочих місць із застосуванням сучасних веб-технологій.

Рівень представлення не буде мати прямих зв’язків з базою даних (за вимогами безпеки), не буде навантажений основною бізнес-логікою (за вимогами масштабованості) і буде зберігати стан програми (за вимогами надійності). На рівень представлення виноситься найпростіша бізнес-логіка: інтерфейс авторизації, алгоритми шифрування, перевірка значень, що вводяться, на допустимість і відповідність формату, нескладні операції з даними (сортування, групування, підрахунок значень) вже завантаженими на термінал і веб інтерфейс. Для реалізації клієнтської частини використовуватиметься SPA (Single-Page Applications: односторінкове веб-застосування) підхід побудови веб-застосувань. На рівні сховища даних буде використовуватись сучасна реляційна СКБД. Сховище даних буде складатися із наступних основних розділів:

• службові дані (нормативно-довідникові дані та класифікатори, користувачі системи, журнали аудиту тощо).
• таблиці даних АСОП (дані записуються після отримання з АСОПу для подальшого використання)
• таблиці даних ІТС РУ МК КК (дані записуються після отримання з ІТС РУ МК КК для подальшого використання).

Компоненти серверу застосувань реалізації бізнес-логіки прикладної функціональності призначені для створення серверних служб доступу до об’єктів та бізнес-логіки прикладної функціональності у відповідності до функціональних задач. Компоненти серверу застосувань сервісів загальносистемних засобів призначені для створення серверних служб реалізації загальносистемних функцій засобів ідентифікації та автентифікації користувачів, перевірки прав доступу, аудиту дій, уніфікованих механізмів формування функціональності клієнтських робочих місць тощо. Схема розміщення компонентів ПС АСОП представлена на (Рисунок 25). Рисунок 25. Схема передачі даних між компонентами ПЗ АСОП Автентифікація користувачів досягається шляхом інформаційної взаємодії з Платформою KYIVSMARTCITY, в якій відбувається централізована обробка набору даних і передача в ПС АСОП. Застосовані рішення з використання компонентів Сервісу забезпечуватимуть можливості:

• автоматизованої адаптації системи при зміні вимог до аналітики;
• інтеграції сервісу, що розробляється, з іншими інформаційними системами та програмними продуктами.

Склад програмних засобів, які будуть використовуватися при побудові сховища даних:

• Microsoft Windows Server 2017;
• Microsoft SQL Express Server 2017;
• My SQL 8.0.

До складу Сервісу, що розробляється, включаються наступні технологічні компоненти:

• Сервер БД, що являє собою промислову систему управління базами даних. На даному сервері зберігаються, область тимчасового і постійного зберігання даних, агрегати даних. Реалізована система розмежувань прав доступу на рівні об'єктів і записів в таблицях. В якості серверів БД будуть використані наступні системи управління базами даних:
• Microsoft SQL Express Server 2017;
• My SQL 8.0.
• Сервер застосувань – продукт, що забезпечує підтримку промислової інфраструктури бізнес-застосувань. Включає в себе низку додатків, що забезпечують:
• стандартні підходи до організації служб каталогів, централізовані методи організації;
• розгортання сервісів розробки додаткових застосувань;
• розгортання сервісів аналізу і звітності.

• OLAP надає зручні швидкодіючі засоби доступу, перегляду та аналізу інформації, основною причиною використання технології є можливість видавати результат за рахунок попередньо агрегованих даних і розрахованих метрикю
• Основним компонентом аналітичних служб є Analysis Server. Цей сервер призначений для створення OLAP-кубів на основі реляційних сховищ даних, а також для надання доступу до них з клієнтських додатків.
• Клієнтські місця користувачів, що представляють собою автоматизовані робочі місця у вигляді веб-інтерфейсу в межах тонкого клієнту (інтернет-оглядачі Edge, Google Chrome, Mozilla Firefox та Safari .

Трирівнева архітектура будується з 3-х частин (див. Рисунок 26):
Рисунок 26. Трирівнева архітектура Клієнтський рівень – це інтерфейсний ( графічний) компонент, який представляє перший рівень, власне, застосунок для кінцевого користувача. Перший рівень не має прямого зв’язку із базою даних (за вимогами безпеки), не навантажений основною бізнес-логікою (за вимогами масштабованості) і зберігає стан програми (за вимогами надійності). На перший рівень виноситься найпростіша бізнес-логіка: інтерфейс авторизації, алгоритми шифрування, перевірка значень, що вводяться, на допустимість і відповідність формату, нескладні операції із даними (сортування, групування, підрахунок значень), що вже завантажені на термінал. Сервер застосунків розташовується на другому рівні. Він складається із наступних взаємопов’язаних компонентів: сервіси загальносистемних засобів та реалізації бізнес-логіки прикладної функціональності та сервіси інформаційної взаємодії з іншими компонентами та інформаційними системами. На другому рівні зосереджена більша частина бізнес-логіки. Поза ним залишаються фрагменти, що експортуються на термінали, а також розміщені в третьому рівні збережені процедури і тригери. Компоненти серверу застосунків сервісів загальносистемних засобів призначені для створення серверних служб реалізації загальносистемних функцій засобів ідентифікації та автентифікації користувачів, перевірки прав доступу, аудиту дій, уніфікованих механізмів формування функціональності клієнтських робочих місць тощо. Сервер застосунків представляє ASP.NET WebApi додаток, побудований на базі .Net Framework 4.6.1 або вище. Це набір сервісів (веб-методів), які віддають інформацію в JSON форматі на клієнт і забезпечують автентифікацію і авторизацію користувачів. Сервер передбачає наявність адміністративної частини для ручного введення і редагування записів та адміністрування користувачів системи. Для обмеження доступу до сайту по IP реалізується відповідний модуль. Списком дозволених IP-адрес можна буде управляти через панель адміністрування. Сервер бази даних забезпечує зберігання даних і виноситься на третій рівень. Таким чином, третій рівень являє собою базу даних разом із збереженими процедурами, тригерами і схемою, яка описує застосунок у термінах реляційної моделі. Сервер БД являє собою у систему управління базами даних: Microsoft SQL Server Express 2017 використовується для збереження конфігурацій. MySQL 8.0 використовується як сховище даних двох систем:

1. АСОП
2. МК КК

Застосовані рішення з побудови програмного Сервісу забезпечуватимуть можливості:

• адаптації Сервісу при зміні вимог до аналітики (додаткових розрізів, кількості елементів у кожному розрізі, деталізації або агрегації періодів аналізу);
• поетапного нарощування як продуктивності, так і функціонального складу Сервісу;
• інтеграції Сервісу, що розробляється, з іншими інформаційними системами та програмними продуктами.

Консолідація даних відбувається шляхом запису їх через сховище ПС АСОП і подальшому записі до OLAP кубу. Рисунок 27. Консолідація даних Процес накопичення інформації складається з наступних етапів:

1. Необхідна інформація з серверів інформаційних систем «Картки киянина» та «АСОП» повинна завантажуватись до сховища ПС АСОП.
2. Отримана інформація зі сховища ПС АСОП, у відповідності до налаштувань SSAS служби передається на сервер OLAP та запису даних до OLAP кубу.
3. Відфільтрована інформація повинна передаватися до компоненту побудови звітів.
4. За допомогою системи побудови звітів, користувач матиме змогу отримати інформацію.

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

Також деякі з вище перерахованих підказок повинні містити випадаючі списки. Таким чином піктограма «Вивантаження даних» міститиме список:

• Скачати дашборд в Excel
• Скачати дашборд PDF
• Скачати обрані елементи Excel
• Скачати обрані елементи PDF.

Піктограма «Профіль» міститиме:

• Мій профіль
• Вийти.

Звідси «Мій профіль» міститиме:

• Ім’я
• Прізвище
• По-батькові
• Номер телефону
• Адреса
• E-mail.

У відповідності до звіту аналізу бізнес процесів ПС АСОП передбачена роль Адміністратора з виконанням наступних функцій:  

• Функції управління обліковими записами організацій; 
• Функції управління обліковими записами користувачів. 

Для виконання даних функцій необхідно реалізувати web-інтерфейс адміністратора. Функції управління обліковими записами організацій   В інтерфейсі Адміністратора розробити елемент який дозволить керувати структурою організації для обмеження прав для певного користувача.  
  Рисунок 28.Макет керуючого елементу структури організації Реалізувати можливість створювати нові організації з можливістю додавати до них користувачів, для надання відповідних прав доступу. 
  Рисунок 29. Макет створення нової організації


Реалізувати можливість видалення організації з системи, під час видалення повинно відображатися вікно підтвердження видалення організації.  Рисунок 30. Макет видалення організації зі системи Реалізувати можливість вибору долучення до організації користувача до організації у відповідності до макету вибору організації. 
Рисунок 31. Макет долучення користувача до організації Функції управління обліковими записами користувачів.   В Інтерфейсі Адміністратора розробити модуль який дозволить керувати користувачами ПС АДКП.  
  Рисунок 32. Макет керуючого елементу управління створення користувача  У ARM Адміністратора передбачається реалізувати можливість керуванням прав  доступу до конструктору у користувачів. Реалізація повинна базуватися на макеті: 
  Рисунок 33. Макет керування правами доступу користувачів Реалізувати ведення журналу дій користувачів, з метою відслідковування дій користувачів. Забезпечення ведення автоматичного журналу подій користувачів при роботі з сервісами з можливістю формування статистики щодо використання функцій користувачами  за  визначені  періоди. При веденні журналу подій повинні фіксуватися критичні несправності в роботі сервісів, спроби несанкціонованого або помилкового отримання доступу, інші події на рівні сервісу. 

FrontEnd:

• Angular 8;
• Highcharts 7.1.2;
• Xamarin Forms 4.0.0.618610.

BackEnd:

• Microsoft Internet Information Services 0.17763;
• .Net Framework 4.6.1;
• Net 3.0;
• Microsoft SQL Server Analysis Services;
• C# 7.3.

СКБД:

• Microsoft SQL Express Server 2017;
• MySQL 8.0.

IDE для налаштування та підтримки  

• Microsoft SQL Management Studio SSMS 18.2.

Розширення функціональних можливостей ПС «АCОП» вимагає додаткового збільшення обчислювальних потужностей  для розгортання MySQL 8.0 необхідний сервер з наступними характеристиками:  

• CPU – 8 ядер;  
• RAM – 32 Gb;  
• HDD – 400 Gb.  

Компоненти які базуватимуться на серверах ІТС «Звітність» збільшення обчислюваний потужностей не потребують :

• Сервер застосунків: IIS 10.0.17763; 
• Програмна платформа: .Net Framework 4.6.1; 
• Microsoft SQL Server 2017 Express Edition:
• Аналітичний компонент Microsoft SQL Server Analysis Services; 
• Система управління базами даних: Microsoft SQL Server 2017 Standart Edition. 

Відповідно до структури рішення, а також враховуючи наявність баз даних та серверів – існуватиме наступне представлення передачі інформації (Рисунок 34).  За допомогою запиту до FTP папки, відбуватиметься процес передачі даних між Сервером MySQL та двома базами даних: БД КК і БД АСОП. Дані будуть накопичуватися в OLAP кубі шляхом SQL запитів до MySQL і накопичення даних на кожній границі Куба у відповідності до пункту 3.17. На сервері БД SQL Server 2017 Express зберігаються системні дані налаштувань роботи системи, використовуються  для підтримки функціонування усіх ПС. Відображення даних в ARM «Користувача» буде здійснено через IIS 10.0.17763 запити надсилаються до БЮ MS SQL Express і OLAP Кубу.   Рисунок 34. Схема розміщення компонентів на серверному обладнані

Склад та зміст послуг зі створення ПС АСОП повинен передбачати такі стадії:

1. Стадія: Розробка Технічного завдання на створення ПС АСОП

• Формування звіту з урахуванням результатів проведення обстеження бізнес-процесів систем/сервісів/рішень на об’єктах Замовника.
• Розробка Технічного завдання на створення ПС АСОП.

1. Стадія: Розробка програмного забезпечення щодо створення ПС АСОП та документації

• Розробка програмного забезпечення
• Розробка документації:
  • Інструкція з розгортання та налаштування ПС АСОП.
  • Інструкція з ведення бази даних.
  • Опис ПС АСОП.
  • Програма та методика попередніх випробувань ПС АСОП.
  • Протокол попередніх випробувань ПС АСОП.
  • Акт приймання в дослідну експлуатацію ПС АСОП.
• Проведення попередніх випробувань.
• Приймання програмного забезпечення ПС АСОП у дослідну експлуатацію.

1. Стадія: Дослідна експлуатація програмного забезпечення ПС АСОП та розробка документації:

• Програма та методика дослідної експлуатації ПС АСОП.
• Керівництво Користувача ПС АСОП.
• Керівництво Адміністратора ПС АСОП.
• Протокол дослідної експлуатації ПС АСОП. Дослідна експлуатація програмного забезпечення ПС АСОП та розробка документації

  В ході реалізації проекту на об’єкті автоматизації вимагається виконати роботи з підготовки до введення Сервісу в дію. З метою забезпечення підготовки об’єкту автоматизації до введення Сервісу в дію потрібно провести:

• погодження з Замовником переліку вхідної та вихідної інформації, яка буде надходити в Сервіс і оброблятися із застосуванням ЕОМ;
• навчання персоналу Замовника, яке проводиться за графіком, що розробляється Виконавцем та погоджується із Замовником;
• роботи із забезпечення обладнання всіх робочих приміщень, де планується встановлення обладнання Сервісу відповідно до вимог технічного завдання;
• забезпечення відповідності комп’ютерного обладнання, на якому має розгортатися Сервіс, технічним вимогам, що гарантують працездатність програмного забезпечення, згідно з технічним завданням;
• заходи щодо розгортання системи захисту інформації в місцях встановлення ПЗ ПС АСОП.

Порядок контролю і приймання Сервісу повинен відповідати етапам, наведеним у таблиці вище.

Виконавець забезпечує гарантійну (технічну) підтримку створеного в результаті надання послуг програмного забезпечення протягом 12 місяців з дати підписання Акту приймання-передачі наданих послуг за останнім етапом згідно Календарного плану. Під гарантійною підтримкою розуміється зобов’язання Виконавця безоплатно підтримувати розроблене програмне забезпечення, виправляти виявлені помилки і адаптувати програмне забезпечення до нових версій СКБД.   Додаток 1

Процедури оновлення даних повинні відбуватись щоденно о 01:00, відбувається шляхом завантаження до баз даних ПС АСОП (MySQL) файлів оновлення з зовнішніх інформаційних систем таких як ІТС АСОП і ІТС МК КК.   Оновлення даних з ІТС АСОП в базу даних ПС «АСОП» повинно відбуватись через збереження нових даних за попередній період з таблиць формату .   які зберігаються на FTP сервері. Дані з цих таблиць будуть оброблятися та перетворюватися у необхідний формат для відображення в ПС «АСОП».   Оновлення даних з

• Номер карти;
• Тип пільги;
• Транспортний номер;
• Пільга;
• Статус.

Які зберігаються на FTP сервері, дані з цих таблиць будуть оброблятися та перетворюватися у необхідний формат для відображення в ПС «АСОП».  
          Візуально значок оновлення щодо інформування про дату останнього успішного оновлення повинен відображатись на верхній панелі екрану (див.Рисунок 35): Рисунок 35. Макет інформаційного значка з даними щодо дати оновлень
У АРМ «Користувача», повинен також відображатись час останнього оновлення  даних, шляхом оновлення кубу за участі FTP серверу  (див.Рисунок 36) Рисунок 36. Макет представлення інформації про останнє оновлення  

Таблиця 1. Характеристика полів для побудови звітів по використанню транспортних продуктів. 41 Таблиця 2. Характеристика полів для побудови звітів по реалізації агентами транспортних продуктів. 44 Таблиця 3. Характеристика полів для побудови звітів по перевізникам. 46 Таблиця 4. Структура даних довідника «Оплата». 53 Таблиця 5. Структура даних довідника «Підтвердження валідації». 54 Таблиця 6. Структура даних довідника «Пільгова категорія». 55 Таблиця 7. Структура даних довідника «Дані про реєстрацію проживання». 55 Таблиця 8. Структура даних довідника «Стать». 56 Таблиця 9. Структура даних довідника «Платіжна картка». 56 Таблиця 10. Підказки, що використовуються в Сервісі 69

Рисунок 1.Макет представлення даних в ПС АСОП.. 28 Рисунок 2. Обмін даними з ІТС РУ МК КК.. 31 Рисунок 3. Обмін даними з ІТС АСОП.. 32 Рисунок 4. Макет вікна. 32 Рисунок 5. Макет форми завантаження даних. 33 Рисунок 6. Макет форми внесення звіту. 33 Рисунок 7. Макет кнопки вивантаження файл. 34 Рисунок 8. Макет вікна підтвердження вивантаження файлу. 34 Рисунок 9. Макет реалізації вивантаження звітів. 35 Рисунок 10. Макет вибору пунктів, представлення звіту у графічному вигляді 35 Рисунок 11. Макет кнопки «Таблиця». 36 Рисунок 12. Макет форми зміни параметрів відображення даних. 36 Рисунок 13. Макет кнопки «Поля». 37 Рисунок 14. Макет таблиці Вимірів. 37 Рисунок 15. Макет розміщення кнопок на конструкторі звіту. 39 Рисунок 16. Обрахування міри. 40 Рисунок 17. Макет вибору фільтру. 43 Рисунок 18. Макет сформованого звіту. 43 Рисунок 19.Схема інформаційних потоків в ПС АСОП.. 52 Рисунок 20. Модель структури даних в ПС АСОП.. 53 Рисунок 21. Модель бізнес-процесу авторизації користувачів. 58 Рисунок 22. Сторінка «Єдиний обліковий запис киянина». 59 Рисунок 23 Макет бізнес-процесу передачі інформації до модуля моніторингу. 59 Рисунок 24. Архітектурна схема Платформи великих даних. 62 Рисунок 25. Схема передачі даних між компонентами ПЗ АСОП.. 64 Рисунок 26. Трирівнева архітектура. 66 Рисунок 27. Консолідація даних. 68 Рисунок 28.Макет керуючого елементу структури організації 70 Рисунок 29. Макет створення нової організації 71 Рисунок 30. Макет видалення організації зі системи. 72 Рисунок 31. Макет долучення користувача до організації 72 Рисунок 32. Макет керуючого елементу управління створення користувача. 73 Рисунок 33. Макет керування правами доступу користувачів. 73 Рисунок 34. Схема розміщення компонентів на серверному обладнані 77 Рисунок 35. Макет інформаційного значка з даними щодо дати оновлень. 83 Рисунок 36. Макет представлення інформації про останнє оновлення. 84
 

 
Додати “призначена для роботи з OLAP та аналізом даних” [ГС1]

ЗІС замінити на “клієнт (веб-браузер користувача)“ [ГС3]

Може це повинно звучати як KyivID - OpenID ніде не використовується і це не частина Київської платформи [ГС5]

Не зовсім коректна розшифровка терміну - варто переписати згідно https://ru.wikipedia.org/wiki/%D0%92%D0%B8%D1%82%D1%80%D0%B8%D0%BD%D0%B0_%D0%B4%D0%B0%D0%BD%D0%BD%D1%8B%D1%85 [ГС7]

текст підгуляв трохи. агенти з продажу - це одне, а пільгові категорії це якось трохи інше. [ГС9]

може контакт-центрів викинути? [ГС11]

Прибиріть “Чиновника” замініть на Користувача. [ГС13]

Поглянь на поточний додаток - він іншого кольору. Треба переробити [ГС15]

Необхідно відірвати OLAP від реалізації та аргументувати чому ми обрали Анализис Сервисес. Типа оно уже було встановлено та налаштовано - повторити шматочок з документу аналіз бізнес-процесів там де ми це робили. [ГС17]


Що це описує ? де воно на рисунку? Це опис меню чи що? Якщо меню / операцій, то варто тоді написати хоча б по 1-2 речення про кожен вид доступних операцій. А то щось перераховано, а що це - не зрозуміло. [ГС20]   Є відчуття що пункти повторюються. Може щось преформулювати ?

Я би так не формлював ТЗ. А краще описав би що необхідно забезпечити можливість фільтрації інформації за такими вимірами. і можна їх перерахувати а ще краще описати. [ГС22]

тут щось повинно бути? [ГС24]

Додати пунктик про ОЛАП, а то забули про нього написати [ГС26]

Забули про ОЛАП [ГС28]

Я би трохи змінив. Ситуація така. Є ІТС Звітність де знаходиться ОЛАП і для нього ПО та сервер додатковий не потрібен (вже є) а от щоб розгортати БД МайСКЛ та додаток сервер потрібен. Треба допрацювати. [ГС30]

МайСКЛ [ГС32]

Де описи структури цих файлів? [ГС34]
не через запит. Я б тут писав про файл. Ми запити не пишемо, ми оброблюємо вхідні файли. Доречно описути структуру цих файлів як джерел даних [ГС35]