- [[32309467:index|(Б-38) Платформа великих даних]] - [[.|(Б-38) Платформа великих даних]] - [[32309467:32309471|Документація]] ====== (Б-38) Платформа великих даних : Технічне завдання ПС АСОП ====== [[download/attachments/32309465/%D0%A2%D0%97_%D0%90%D0%A1%D0%9E%D0%9F.docx?version=1&modificationDate=1584705363516&api=v2|{{rest/documentConversion/latest/conversion/thumbnail/32309534/1?0x250}}]] |**ЗАТВЕРДЖУЮ **\\ \\ КП «Головний інформаційно-обчислювальний центр» |**ЗАТВЕРДЖУЮ**\\ \\ ТОВ «СІВІС» | |Директор |Директор | |%%__%%%%__%%%%__%%%%__%%%%__%%%%__%%%%__%%_В.М. Козубський |%%__%%%%__%%%%__%%%%__%%%%__%%%%__%%%%__%%%%__%%_ О. О. Юношева | |«%%__%%%%__%%%%__%%»%%__%%%%__%%%%__%%%%__%%%%__%%%%__%%%%__%% 2019 р.\\ \\ М. П|«%%__%%%%__%%%%__%%»%%__%%%%__%%%%__%%%%__%%%%__%%%%__%%%%__%%%%__%%%%__%%2019 р.\\ \\ М. П| **Створення програмного сервісу Автоматизована система обліку оплати проїзду в міському пасажирському транспорті міста Києва незалежно від форм власності, що входить до складу єдиної інформаційно-аналітичної платформи консолідації та аналізу великих даних «Big Data» в місті Києві** **Шифр: ПС АСОП** **Технічне завдання** **на створення ПС АСОП** **39194632.184154.4687.ТЗ** **Етап 1 п 1.1** На %%__%%%%__%%_ аркушах \\ |**Від Замовника:** |** **|**Від Виконавця:** | |Начальник департаменту розвитку обліково-фінансових систем, голова комісії|** **|Директор\\ \\ \\ | |%%__%%%%__%%%%__%%%%__%%%%__%%%%__%%%%__%%%%__%% А. П. Гусаревич |** **|%%__%%%%__%%%%__%%%%__%%%%__%%%%__%%_ О. О. Юношева| |\\ |\\ |\\ | ЗМІСТ [[#_Toc29891584|ПЕРЕЛІК ТЕРМІНІВ ТА СКОРОЧЕНЬ.. 6]] - [[#_Toc29891585|ЗАГАЛЬНІ ВІДОМОСТІ 11]] [[#_Toc29891586|1.1 Найменування системи та її умовне позначення. 11]] [[#_Toc29891587|1.2 Шифр теми або номер договору: 11]] [[#_Toc29891588|1.3 Найменування організацій Замовника і Розробника, їх реквізити. 11]] [[#_Toc29891589|1.4 Підстави для розробки (перелік документів, на підставі яких створюється проект, ким і коли затверджені ці документи) 12]] [[#_Toc29891590|1.5 Планові терміни початку і закінчення роботи із створення Сервісу. 12]] [[#_Toc29891591|1.6 Порядок передачі замовнику результатів робіт по розробці Сервісу. 12]] - [[#_Toc29891592|ПРИЗНАЧЕННЯ ТА МЕТА СЕРВІСУ.. 13]] [[#_Toc29891593|2.1 Призначення ПС АСОП.. 13]] [[#_Toc29891594|2.2 Мета і завдання створення ПС АСОП.. 13]] - [[#_Toc29891595|НЕФУНКЦІОНАЛЬНІ ВИМОГИ ДО СЕРВІСУ.. 15]] [[#_Toc29891596|3.1 Вимоги чинного законодавства. 15]] [[#_Toc29891597|3.2 Вимоги до комплексу засобів захисту інформації 17]] [[#_Toc29891598|3.3 Вимоги до інформаційної безпеки. 20]] [[#_Toc29891599|3.4 Вимоги до режимів функціонування Сервісу. 21]] [[#_Toc29891600|3.5 Вимоги до чисельності та кваліфікації персоналу Сервісу та режиму його роботи. 21]] [[#_Toc29891601|3.6 Вимоги до надійності 22]] [[#_Toc29891602|3.7 Вимоги до ергономіки. 22]] [[#_Toc29891603|3.8 Вимоги до патентної чистоти. 24]] [[#_Toc29891604|3.9 Вимоги до стандартизації та уніфікації 24]] [[#_Toc29891605|3.10 Загальні вимоги до видів забезпечення. 25]] [[#_Toc29891606|3.11 Вимоги до інформаційного забезпечення. 25]] [[#_Toc29891607|3.12 Вимоги до лінгвістичного забезпечення. 26]] [[#_Toc29891608|3.13 Вимоги до програмного забезпечення. 26]] [[#_Toc29891609|3.14 Вимоги до технічного забезпечення. 27]] [[#_Toc29891610|3.15 Вимоги до організаційного забезпечення. 27]] [[#_Toc29891611|3.16 Вимоги до методичного забезпечення. 28]] [[#_Toc29891612|3.17 Проведення аналізу даних та формування інтерактивної звітності з використанням OLAP-технологій. 28]] [[#_Toc29891613|3.18 Вимоги до технологічної документації та методичного забезпечення. 29]] [[#_Toc29891614|3.19 Вимоги до апаратного забезпечення системи. 30]] - [[#_Toc29891615|ФУНКЦІОНАЛЬНІ ВИМОГИ.. 31]] [[#_Toc29891616|4.1 Інтеграція та/або обмін даними з системами та/або базами даних щодо отримання інформації про утримувачів муніципальної картки «Картка киянина» (пільговиків та категорії їх пільг) 31]] [[#_Toc29891617|4.2 Інтеграція та/або обмін даними з системами та/або базами даних щодо отримання інформації про здійснення реєстрацій електронного квитка та факти оплати пасажиром транспортної послуги Перевізника. 31]] [[#_Toc29891618|4.3 Здійснення формування звітів. 32]] [[#_Toc29891619|4.4 Формування звітів різного типу по кількості та/або вартості використання транспортних продуктів в розрізі Перевізників, маршрутів, транспортних засобів, категорій пасажирів, пільгових категорій пасажирів тощо. 40]] [[#_Toc29891620|4.5 Формування звітів по агентам, що реалізують транспортні продукти для пасажирів у міському пасажирському транспорті 43]] [[#_Toc29891621|4.6 Формування звітів по перевізникам міста Києва, що відносяться до КП «Київпастранс» (далі – КПТ), КП «Київський метрополітен» (далі – КМ) та інших форм власності 46]] [[#_Toc29891622|4.7 Здійснення налаштування фільтрації для кожного звіту окремо. 48]] - [[#_Toc29891623|ОПИС ПРОПОНОВАНОГО РІШЕННЯ.. 50]] [[#_Toc29891624|5.1 Рольова модель ПС АСОП.. 51]] [[#_Toc29891625|5.2 Джерела даних та їх перетворення в ПС АСОП.. 52]] [[#_Toc29891626|5.4. Опис інтеграції з Платформою KYIVSMARTCITY у рамках модулю моніторингу. 59]] [[#_Toc29891627|5.5 Архітектура Сервісу АСОП.. 61]] [[#_Toc29891628|5.6 Опис компонента консолідації даних різних об’єктів функціонування та даних різних рівнів ієрархії для аналітичного дослідження інформації 68]] [[#_Toc29891629|5.7 Інтерактивні елементи у зручному та зрозумілому представленні із набором відповідних текстових та/або графічних інформаційних підказок. 69]] [[#_Toc29891630|5.8 Компонент управління правами доступу користувачів Сервісів з розподіленням доступу функцій в межах сервісів. 70]] - [[#_Toc29891631|ПРОГРАМНА ТА АПАРАТНА ІНФРАСТРУКТУРА.. 75]] - [[#_Toc29891632|ВИМОГИ ДО СКЛАДУ І ЗМІСТУ ПОСЛУГ З ПІДГОТОВКИ ОБ’ЄКТУ АВТОМАТИЗАЦІЇ ДО ВВОДУ СИСТЕМИ В ДІЮ... 78]] - [[#_Toc29891633|КАЛЕНДАРНИЙ ПЛАН НАДАННЯ ПОСЛУГ. 80]] - [[#_Toc29891634|ГАРАНТІЙНА ТА ПІСЛЯГАРАНТІЙНА ПІДТРИМКА.. 82]] [[#_Toc29891635|Регламент оновлення інформації у ПС АСОП.. 83]] - [[#_Toc29891636|СПИСОК ТАБЛИЦЬ.. 85]] - [[#_Toc29891637|СПИСОК РИСУНКІВ.. 86]] [[#_Toc29891638|ЛИСТ РЕЄСТРАЦІЇ ЗМІН.. 88]] \\ ====== ПЕРЕЛІК ТЕРМІНІВ ТА СКОРОЧЕНЬ ====== ^**Термін** ^**Значення** ^ |.Net Framework |Програмне забезпечення для об'єднання різних компонентів програмного проєкту | |Analysis Services (SSAS) |, призначений для роботи с OLAP та аналізом даних | |API |Application Programming Interface – прикладний програмний інтерфейс. | |ASP.NET WebApi додаток |Додаток який повертає методом дії контролера API, кодуються в форматі JSON і відправляє в\\ \\ клієнт (веб-браузер користувача) | |Big Data |Великі дані (англ. Big data) – позначення структурованих і неструктурованих даних великих обсягів, що ефективно оброблюються горизонтально масштабованими програмними інструментами та альтернативними традиційним системам управління базами даних і рішенням класу Business Intelligence. | |JSON |(JavaScript Object Notation) формат для представлення значень і об'єктів. Його опис задокументовано в стандарті RFC 4627. | |OLAP |Online Analytical Processing (аналітична обробка у реальному часі) – це інтерактивна система що дозволяє переглядати різні підсумки по багатовимірних даних. | |Kyiv |Частина єдиної міської платформи електронної взаємодії, управління даними та сервісами, яка дозволяє здійснювати авторизацію користувачів у муніципальних системах. | |SHA-256, MD5 |хеш-функція, певна формула для перетворення частини цифрових даних. | |SOAP |(Simple Object Access Protocol) протокол обміну структурованими повідомленнями в розподіленої обчислювальної середовищі. | |SPA підхід |(single page application) підхід використовує єдиний HTML-документ як оболонку для всіх веб-сторінок і організуючий взаємодія з користувачем через динамічно підкачуємі HTML, CSS, JavaScript | |Web Services |Ідентифікована унікальнною веб-адресою програмна система зі стандартизованими інтерфейсами. | |XML\\ \\ \\ |(eXtensible Markup Language) розширювана мова розмітки, представлена словником тегів і їх атрибутів, а також набором правил, що визначають які атрибути і елементи можуть входити до складу інших елемент. | |Агент |Суб’єкти господарювання, що мають належну інфраструктуру обслуговування пасажирів, обладнання та відповідні права для здійснення операцій з продажу електронних квитків, поповнення транспортного ресурсу. | |Агрегати даних |Іменована підмножина елементів [[https://uk.wikipedia.org/wiki/%D0%91%D0%B0%D0%B7%D0%B0_%D0%B4%D0%B0%D0%BD%D0%B8%D1%85|даних]] бо інших агрегатів у середині запису. У агрегатах допускається множинний елемент, який містить кілька значень елемента в одному примірнику агрегату. | |Адміністратор |Користувач, якому надано право визначати та призначати рівні доступу та виконувати адміністрування Сервісів. | |АІАС |Автоматизована інформаційно-аналітична система – це комп'ютерна система, яка дозволяє отримувати інформацію, створювати її та здійснювати її обробку та аналіз. | |АІС |Автоматизована інформаційна система – це взаємозв'язана сукупність даних, комп’ютерного обладнання, програмних засобів, персоналу, стандартних процедур, які призначені для збору, обробки, розподілу, зберігання, представлення інформації згідно з вимогами, які випливають з цілей організації. | |АРМ |Автоматизоване робоче місце. | |АСОП |Автоматизована система обліку оплати проїзду в міському пасажирському транспорті міста Києва незалежно від форм власності\\ \\ https://prozorro.gov.ua/tender/UA-2018-08-20-002625-c | |Багатофункціональна електронна картка «Муніципальна картка «Картка киянина»|Багатофункціональний електронний платіжний засіб, в будь-якій формі, на будь-якому носії, який містить персональні дані та дає змогу ідентифікувати утримувача картки, за допомогою якого в тому числі надаються пільги, доплати, допомоги, компенсації, сервіси, послуги та знижки його утримувачам на території міста Києва. Муніципальна картка «Картка киянина». | |БД |База даних – сукупність даних, організованих відповідно до концепції, яка описує характеристику цих даних і взаємозв'язки між їх елементами. | |БД АСОП |База даних АСОП | |БД КК |База даних Картка киянина | |Виконавець |Юридична особа, що уклала договір з Замовником про надання послуг з розвитку Платформи. | |Вітрини даних |\\ | |Замовник |Юридична особа Комунальне підприємство «Головний інформаційно-обчислювальний центр», яка уклала договір з Виконавцем про надання послуг зі створення Платформи. | |Звітність |Інформаційно-телекомунікаційна система «Інформаційно-аналітична звітність для органів влади, громадян та бізнесу»\\ \\ https://prozorro.gov.ua/tender/UA-2018-07-02-001783-a | |ЗІС |Зовнішні інформаційні системи | |Інтерфейс |Сукупність засобів для обробки та відображення інформації. Інтерфейс взаємодії між системою і користувачем. | |ІТС |Інформаційно-телекомунікаційна система – це система, в якій реалізується технологія обробки інформації з використанням технічних і програмних засобів | |ІТС РУ МК КК |Інформаційно-телекомунікаційна система "Реєстр утримувачів багатофункціональної електронної картки "Муніципальна картка "Картка киянина". Скорочено ІТС РУ МК КК, в рамках ПС АСОП, утримувач даних по пільговим категоріям пасажирів. | |КК |Муніципальна «Картка киянина» | |КМ |КП «Київський метрополітен» | |Користувач |Користувачами Платформи та окремих програмних сервісів є посадові (службові) особи та працівники структурних підрозділів виконавчого органу Київської міської ради (Київської міської державної адміністрації), районних в місті Києві державних адміністрацій, підприємств, установ та організацій, що належать до комунальної власності територіальної громади міста Києва, у тому числі медичних закладів (поліклініка, школа, садочки), а також інші фізичні або юридичні особи, які пройшли ідентифікацію, автентифікацію та авторизацію у встановленому порядку та отримали доступ до інформаційних ресурсів та функції Платформи у відповідності до визначених для них ролей.| |КП |Комунальне підприємство | |КПТ |КП «Київпастранс» | |Модуль |Функціональна частина системи, яка виконує певну функцію, має закінчене оформлення та засоби сполучення з іншими частинами. | |Модуль авторизації |Комп’ютерна програма «Urbio Модуль авторизації» (Єдиний модуль обліку, управління користувачами та ЗІС) (далі – Модуль авторизації) https:%%//%%prozorro.gov.ua/tender/UA-2019-06-07-002508-b | |Модуль обліку та моніторингу |Комп’ютерна програма «Urbio Модуль обліку та моніторингу» (Єдиний модуль логування та https://prozorro.gov.ua/tender/UA-2019-07-15-001137-a | |Перевізник |Забезпечує надання послуг з перевезення пасажирів наземним автомобільним та електротранспортом (тролейбус, трамвай, фунікулер та інші), а також підземним (метрополітен). | |ПЗ |Програмне забезпечення. | |Платформа KYIVSMARTCITY |Єдина міська платформа електронної взаємодії, управління даними та сервісами (комп’ютерна програма «Платформа Urbio»)\\ \\ https://www.prozorro.gov.ua/tender/UA-2018-05-05-000852-b. | |ППЗ |Прикладне програмне забезпечення. | |Протокол HTTP over TLS |Hyper Text Transfer Protocol Secure – розширення протоколу HTTP, яке підтримує захист даних при транспортуванні за допомогою шифрування інформації відповідно до стандартів TLS. Такий захист потрібний в комерційних ресурсах, де використовується інформація про конфіденційні або розрахункові дані користувача | |Протоколи TCP/IP |Мережева модель передачі даних, представлених в цифровому вигляді в якій передбачається проходження інформації через чотири рівні, кожен з яких описується правилом (протоколом передачі). | |ПС |Програмний сервіс. | |ПС АСОП |Програмний сервіс для отримання даних з Єдиної міської автоматизованої системи обліку оплати проїзду в міському пасажирському транспорті міста Києва незалежно від форм власності, а також даних про утримувачів багатофункціональної електронної картки «Муніципальна картка «Картка киянина». | |Розріз даних |Сукупність загальних показників параметрів по певному напрямку відповідно до яких потрібно провести всебічну аналітику. | |Розробник |Компанія, що забезпечує технічний супровід системи. | |Стандарт IEEE 754 |Стандарт, що описує формат уявлення чисел з плаваючою точкою. Використовується в програмних (компілятори з різних мов програмування) і апаратних (CPU і FPU) реалізаціях арифметичних дій (математичних операцій). | |ТЗ |Технічне завдання | |ЦБД |Центральна база даних | \\ ====== 1. ЗАГАЛЬНІ ВІДОМОСТІ ====== ===== 1.1 Найменування системи та її умовне позначення ===== Повне найменування системи: Програмний сервіс для отримання даних з автоматизованої системи обліку оплати проїзду в міському пасажирському транспорті міста Києва незалежно від форм власності (далі – АСОП), а також даних про утримувачів муніципальної картки «Картка киянина» (умовне позначення – ПС АСОП). Умовне позначення: ПС АСОП, далі – Сервіс. Дане Технічне Завдання стосується розробки та впровадження ПС АСОП, який дозволить формувати аналітичні та статистичні звіти щодо виду транспортних продуктів, перевізників, , відображати достовірну аналітичну та оперативну інформацію у розрізі пільгові категорії пасажирів, підвищить зручність роботи користувачів ПС АСОП всіх типів із збереженням рівня надійності та зручності рішення. Програмний сервіс АСОП створюється як частина Платформи «Big Data» для відображення достовірної аналітичної та оперативної інформації щодо певних аспектів роботи системи АСОП у розрізі даних про утримувачів муніципальної картки «Картка киянина», в тому числі щодо пільговиків. ===== 1.2 Шифр теми або номер договору: ===== Договір № 4687 від 30.07.2019 р. ===== 1.3 Найменування організацій Замовника і Розробника, їх реквізити ===== **Замовник: ** Комунальне підприємство «Головний інформаційно-обчислювальний центр» Місцезнаходження: вул. Космічна, буд. 12а, м. Київ, 02192, Україна. п/р 35442136091290 ГУ ДКСУ в м. Києві, Код банку 820019, ЄДРПОУ 04013755, Свідоцтво пл. ПДВ №100093243, ІПН 040137526538. **Розробник:** Товариство з обмеженою відповідальністю «СІВІС». Місцезнаходження: вул. Амосова, буд. 4, офіс 8, м. Київ, 03141, Україна. ЄДРПОУ 39194632, п/р 26003052709939 в «Філія Розрах. центр» АТ КБ «ПРИВАТБАНК», Код банку 320649, ІПН 391946326582. ===== 1.4 Підстави для розробки (перелік документів, на підставі яких створюється проект, ким і коли затверджені ці документи) ===== Розробка виконується згідно договору № 4687 від 30.07.2019р. Результат проведення закупівлі: код за ДК 021:2015: 72210000-0 Послуги з розробки пакетів програмного забезпечення (Створення, впровадження та модернізація платформи великих даних). ===== 1.5 Планові терміни початку і закінчення роботи із створення Сервісу ===== Початок робіт: 30.07.2019 р. Закінчення робіт: 26.12.2019 р. ===== 1.6 Порядок передачі замовнику результатів робіт по розробці Сервісу ===== Результати робіт передаються у вигляді функціонуючого програмного забезпечення на базі засобів обчислювальної техніки та іншого необхідного устаткування Замовника у строки, визначені договором. Приймання результатів здійснюється комісією у складі уповноважених осіб Замовника та Виконавця. ====== 2. ПРИЗНАЧЕННЯ ТА МЕТА СЕРВІСУ ====== ===== 2.1 Призначення ПС АСОП ===== ПС АСОП призначено для відображення достовірної аналітичної та оперативної інформації щодо певних аспектів роботи системи АСОП у розрізі даних: * Реалізації і використання транспортних продуктів * Утримувачів муніципальної картки «Картка киянина» і використання пільгового проїзду. ПС АСОП – це інтегрований предметно-орієнтований інформаційно-телекомунікаційний сервіс, що будується на основі централізованої програмно-технологічної платформи з уніфікацією програмно-технічних засобів розробки прикладної функціональності з використанням сучасних сервісно-орієнтованих технологій. У межах створення Сервісу використовуватимуться системи «Картка киянина», «АСОП» з метою аналізу інформації в зручному вигляді на веб-порталі. Дані з цих систем будуть надходити до створюваного сховища даних ПС АСОП, що в свою чергу буде включено в єдине інформаційне середовище (програмну платформу) «Big Data». Основною аудиторією користувачів Сервісу є керівництво і фахівці структурних підрозділів КМДА, державних і комунальних підприємств та організацій, які будуть використовувати Сервіс для забезпечення підтримки прийняття управлінських рішень. ===== 2.2 Мета і завдання створення ПС АСОП ===== Метою створення програмного сервісу АСОП є надання інформаційно-аналітичних інструментів, як основи для подальшого аналітичного дослідження великих даних, конструювання та опрацювання аналітичних та статистичних звітів з метою підтримки прийняття управлінських рішень. Основними завданнями Сервісу виступають: * підвищення оперативності отримання достовірної інформації для проведення поглибленого аналізу з метою подальшого прийняття рішень; * підвищення доступності необхідних даних для формування звітів для кінцевих користувачів; * скорочення термінів підготовки періодичної аналітичної звітності за рахунок використання OLAP-технологій для аналітичної обробки даних. Програмний сервіс АСОП створюється як частина Платформи «Big Data» для відображення достовірної аналітичної та оперативної інформації щодо необхідних аспектів роботи системи АСОП, у розрізі даних про утримувачів муніципальної картки «Картка киянина» та використанню транспортних продуктів для підвищення зручності роботи користувачів всіх типів із збереженням рівня надійності та зручності рішення. Цілями розробки та впровадження ПС АСОП є: * впровадження можливості отримувати інформацію про утримувачів муніципальної картки «Картка киянина» та АСОП задля подальшого формування аналітичної звітності з використанням OLAP-технологій; * створення можливості отримувати оперативну, повну та достовірну інформацію про купівлю і використання транспортних продуктів, з метою проведення поглибленого аналізу і оцінки надання пасажирських перевезень пільговим категоріям громадян міста Києва, роботи міського пасажирського транспорту; * забезпечення адміністрації перевізників, співробітників департамент транспортної інфраструктури можливостями, за допомогою яких вони матимуть змогу самостійно формувати будь які звіти в потрібних розрізах (в рамках існуючих даних), без залучення розробників та інших спеціалістів в межах програмного інтерфейсу ПС АСОП; * створення можливості (згідно рольової моделі) через автоматизовані робочі місця (АРМ) керівникам структурних підрозділів КМДА надавати доступ через веб-інтерфейс з можливістю відображати інформацію (історичні дані за певний проміжок часу) про обслуговування та надання відповідних транспортних послуг громадянам міста Києва в тому числі в розрізі основних типів пільг в межах АСОП; * підвищення якості надання послуг, контроль за цільовим використанням коштів задля забезпечення соціального захисту киян. Сервіс має забезпечити: * створення можливості отримувати дані про утримувачів муніципальної картки «Картка киянина» та АСОП для подальшого формування аналітичної звітності з використанням OLAP-технологій; * створення можливості отримувати повну, оперативну і достовірну інформацію для проведення поглибленого аналізу і оцінки щодо надання пасажирських перевезень пільговим категоріям громадян міста Києва, роботи міського пасажирського транспорту тощо та прийняття рішень керівниками структурних підрозділів КМДА; * забезпечення визначених категорій користувачів інструментами, які дозволять їм самостійно формувати довільні звіти в потрібних розрізах, без залучення розробників та інших спеціалістів в межах програмного інтерфейсу ПС АСОП; * створення можливості (згідно рольової моделі) через автоматизовані робочі місця (АРМ) керівникам структурних підрозділів КМДА надавати доступ через веб-інтерфейс з можливістю відображати інформацію (історичні дані за певний проміжок часу) про обслуговування та надання відповідних транспортних послуг громадянам міста Києва в розрізі основних типів пільг в межах АСОП; * підвищення ефективності контролю за якістю надання послуг та цільовим використанням коштів, передбачених для здійснення соціального захисту мешканців Києва.\\ ====== 3. НЕФУНКЦІОНАЛЬНІ ВИМОГИ ДО СЕРВІСУ ====== ===== 3.1 Вимоги чинного законодавства ===== Розробка Сервісу відбувається на підставі та з урахуванням вимог наступних нормативно-правових документів: * Конституція України; * Закону України «Про інформацію»; * Закону України «Про електронні документи та електронний документообіг»; * Закону України «Про адміністративні послуги»; * Закону України «Про доступ до публічної інформації»; * Закону України «Про захист інформації в інформаційно-телекомунікаційних системах»; * Закону України «Про захист персональних даних»; * Постанови Кабінету Міністрів України від 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. ===== 3.2 Вимоги до комплексу засобів захисту інформації ===== Вимоги із забезпечення захисту інформації реалізовуватимуться за рахунок створення комплексу засобів захисту, який складається із програмних засобів криптографічного захисту інформації, засобів підсистеми «Адміністрування» та засобів захисту операційних систем. У складі комплексу засобів захисту будуть застосовані програмні засоби криптографічного захисту інформації, які мають діючий позитивний експертний висновок Державної служби спеціального зв'язку та захисту інформації України. У Сервісі буде реалізований захищений доступ до системи на рівні логінів/паролів підключення до Сервісу, які шифруватимуться за алгоритмом хешування 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); * всі процеси запускаються від імені непривілейованих користувачів; * доступ до баз даних виконується за допомогою спеціалізованих облікових записів та паролів, які відповідають єдиним завданим політикам безпеки (строк дії пароля, кількість літер, чисел та символів). Розробка та впровадження комплексної системи захисту інформації не є предметом даного договору, її може бути реалізовано в подальшому в межах виконання окремих робіт. ===== 3.3 Вимоги до інформаційної безпеки ===== Доступ до інформаційних ресурсів Сервісу надається з метою виконання функцій та завдань, які визначені в чинному законодавстві України, наказах, положеннях, розпорядженнях чи інших нормативних документах, або інших робіт згідно договору. Доступ до інформації з обмеженим доступом, що знаходиться у Сервісі, після підписання договору про конфіденційність і нерозголошення інформації надається через захищені канали зв’язку з використанням програмних або технічних засобів криптографічного захисту інформації, що мають позитивний експертний висновок ДССЗЗІ. При проектуванні ПС АСОП були реалізовані базові заходи безпеки інформації. При реалізації четвертої черги повинні використовуватися вже започатковані заходи безпеки, а саме: * організаційно-адміністративні; * апаратно-програмні; * інженерно-технічні. Вимоги щодо КСЗІ визначатимуться в окремому Технічному завданні, що буде розроблятись Виконавцем, якого буде визначено за результатами проведення окремої конкурсної процедури. Для забезпечення безпеки передачі даних між робочим місцем Користувача та серверним програмним комплексом у ПС АСОП буде передбачена можливість використання програмних засобів криптографічних перетворень, який має позитивний експертний висновок Державної служби спеціального зв'язку та захисту інформації України. ===== 3.4 Вимоги до режимів функціонування Сервісу ===== Експлуатація Сервісу передбачатиме такі режими: - Основний режим – режим штатного функціонування всіх модулів та компонентів за призначенням. - Нештатний режим – режим нештатного функціонування всіх компонентів Платформи. - Режим адміністрування – режим здійснення централізованого автоматизованого налагоджування та автоматизованого оновлення Сервісу одночасно із роботою решти користувачів в основному режимі. - Режим регламентного обслуговування – режим регламентного технічного обслуговування та відновлення працездатності технічних засобів компонентів Системи. ===== 3.5 Вимоги до чисельності та кваліфікації персоналу Сервісу та режиму його роботи ===== Рішення з чисельності та кваліфікації персоналу повинні забезпечити: * безперервне супроводження Сервісу на всіх стадіях експлуатації та підтримки; * цілодобовий режим роботи Сервісу та його компонентів/модулів/сервісів за призначенням в повному обсязі; * централізований контроль працездатності Сервісу; * усунення відмов роботи Сервісу; * адміністрування (оперативне налагодження під час експлуатації) роботи Сервісу; * своєчасне централізоване застосування оновлень програмного забезпечення. Повинні бути запропоновані рішення щодо чисельності та кваліфікації обслуговуючого персоналу Сервісу. Пропозиція повинна бути обґрунтована та мати оптимізований склад обслуговуючого персоналу. ===== 3.6 Вимоги до надійності ===== Надійність Сервісу АСОП повинна забезпечуватись за наступними напрямками: * забезпечення працездатності компонентів Сервісу; * збереження даних. При відмові одного або декількох компонентів механізми із збереження працездатності повинні забезпечувати надійність роботи за рахунок їх резервування. При цьому відбуватиметься мінімальна концентрація уваги з боку системного адміністратора, щодо реакції на усунення наслідків відмов компонентів. Програмно-апаратними засобами повинно бути забезпечене збереження даних. Збереження даних повинно забезпечувати збереження цілісності даних при програмно-апаратних відмовах, помилках, шляхом використання відповідних програмно-апаратних засобів та рішень, резервного копіювання, транзакційності при змінах даних. Збереження даних буде забезпечено у випадках: * вимкнення живлення; * відмови технічних засобів обробки інформації; * помилки, збоїв або руйнування програмного забезпечення; * тимчасової відмови ліній зв’язку. Надійність функціонування Сервісу АСОП буде забезпечено при: * використанням сучасних технологій розробки (модернізації) прикладного програмного забезпечення та забезпеченням якісного його тестування; * резервуванням основних компонентів; * регламентом організації резервного копіювання та архівного збереження інформації; * оперативністю заміни програмно-технічних засобів, що вийшли з ладу; * сумісністю технічних засобів та програмного забезпечення. Повинна бути реалізована одна з наступних стратегій забезпечення надійності: ===== 3.7 Вимоги до ергономіки ===== Рішення щодо ергономіки веб-інтерфейсу ПС АСОП повинні відповідати вимогам технічної естетики та інженерної психології для забезпечення гармонійного зв'язку між параметрами технічних засобів і психофізичними можливостями людини із урахуванням створення єдиного об’ємно-просторового і кольорового рішення відповідно до ГОСТ 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 не передбачається. Основні вимоги до інформаційно-графічних елементів веб-інтерфейсу: * коректне типізоване відображення (сумісність) інформації в передостанніх версіях найбільш популярних веб-браузерів; * графічний і структурний дизайн повинен бути виконаний з урахуванням плавної зміни розміру вікна веб-браузера. Під час перевищення деякого максимального розміру дизайн повинен передбачати заповнення зайвого місця фоновими матеріалами, які можуть бути збільшені без обмежень, наприклад, фоновою картинкою рівної структури; * усі екранні форми користувацького інтерфейсу повинні бути виконані в єдиному графічному дизайні з однаковим розташуванням основних елементів управління і навігації. * схожі операції повинні виконуватися з використанням ідентичних графічних елементів у повній відповідності до побудови (структури) інформаційної архітектури рішення. ===== 3.8 Вимоги до патентної чистоти ===== Патентна чистота Сервісу буде забезпечена за рахунок використання при розробці ліцензійних апаратних і програмних засобів та обладнання і гарантується Розробником. ===== 3.9 Вимоги до стандартизації та уніфікації ===== Стандартизація та уніфікація функцій Сервісу буде забезпечуватись за рахунок використання сучасних інструментальних програмних засобів які підтримують єдину технологію проектування і розробки функціонального, інформаційного та програмного забезпечень. У процесі розробки Сервісу будуть сформовані вимоги до розробки прикладного програмного забезпечення, які уніфікуватимуть процедуру обробки інформації, ідентифікацію програмних модулів та баз даних, типізуватимуть окремі програмні модулі відповідно до свого призначення. В даному документі описані вимоги до розробки прикладного програмного забезпечення, які уніфікують інтерфейс користувача, процедури обробки інформації, ідентифікацію програмних компонентів та баз даних, типізують окремі програмні модулі відповідно до свого призначення в різних функціональних підсистемах. ===== 3.10 Загальні вимоги до видів забезпечення ===== * Застосування сучасних інформаційних технологій. * Застосування правила централізованого накопичення, зберігання та обробки інформації. * Підтримка актуальності, повноти, несуперечності, цілісності та доступності інформації. * Забезпечення надійного захисту інформації від порушення її цілісності, витоку та блокування згідно з порядком, встановленим нормативно-правовими державними актами і нормативними документами в галузі захисту інформації. * Розподіл рівня доступу до даних Сервісу за різними рівнями та можливість гнучкого налаштування та адміністрування. * Забезпечення надійності, резервування компонентів технічного забезпечення Сервісу; * Забезпечення централізованого управління, безперервного контролю функціонування та централізованого налаштування Сервісу та його компонентів. * Забезпечення можливості реалізації централізованого оновлення рішень за результатами модернізації/доопрацювання та налаштувань Сервісу в автоматизованому режимі. ===== 3.11 Вимоги до інформаційного забезпечення ===== Інформаційне забезпечення розробляється достатнім для найбільш ефективного використання всіх функцій Сервісу. Інформаційне забезпечення відповідатиме наступним вимогам та можливостям: * забезпечення фізичної та логічної цілісності даних; * мінімізація надмірності даних, що зберігаються; * стандартизація представлення даних; * достовірність та актуальність даних. ===== 3.12 Вимоги до лінгвістичного забезпечення ===== Мовні засоби програмування обиратимуться Виконавцем відповідно до рішень з програмного забезпечення Сервісу. ===== 3.13 Вимоги до програмного забезпечення ===== Програмне забезпечення (ПЗ) системи складатиметься з: * загальносистемного програмного забезпечення (ЗПЗ); * прикладного програмного забезпечення (ППЗ). Програмне забезпечення системи відображатиме специфіку автоматизованих функціональних задач користувачів та забезпечуватиме: * підтримку загальноприйнятих сучасних міжнародних стандартів до відкритих систем; * сумісність та інтегрованість; * підтримку функціонування в різнорідному апаратному і програмному середовищах; * вмонтованість механізму захисту від помилок і підтримки цілісності; * мінімальні витрати на їх закупівлю та експлуатацію. До загальносистемного програмного забезпечення відносяться: * операційні системи; * система керування базами даних (СКБД); * офісні застосування; * тощо. До прикладного програмного забезпечення відноситься програмне забезпечення, що розробляється та налаштовується під час створення системи. Розробка прикладного програмного забезпечення буде проводитись за допомогою сучасних інструментальних засобів програмної інженерії проектування і генерації розподілених баз даних (CASE-засобів) з урахуванням можливості подальшого автоматизованого тестування. При розробці ППЗ будуть використовуватися принципи модульності та типовості, які забезпечать послідовне нарощування функціональних можливостей системи за рахунок створення, впровадження та тиражування функціонально завершених програмних модулів. В цілому передбачається сумісність ППЗ: * з операційними системами: Windows, Linux; * з веб-браузерами: Edge, Google Chrome, Mozilla Firefox та Safari (останніх та передостанніх версій). Основні вимоги до інформаційно-графічних елементів веб-інтерфейсу: * Коректне типізоване відображення (сумісність) інформації в наперед останніх версіях на дату початку надання послуг за етапом згідно календарного плану найбільш популярних веб-браузерів: * Chromе; * Opera; * Mozilla Firefox; * Microsoft Edge. * Графічний і структурний дизайни повинні бути виконані з урахуванням плавної зміни розміру вікна веб-браузера. * Всі екранні форми користувальницького інтерфейсу повинні бути виконані в єдиному графічному дизайні з однаковим розташуванням основних елементів управління і навігації. Схожі операції повинні виконуватися з використанням ідентичних графічних елементів у повній відповідності до побудови (структури) інформаційної архітектури рішення. * Для організації можливості подальшого автоматизованого тестування всі візуальні елементи веб-інтерфейсу повинні мати постійні унікальні ідентифікатори. * Екранні форми мають бути налаштовані для відображення у мобільних додатках на планшетних пристроях у альбомному форматі. Відображення у портретному форматі не налаштовується, тому що частина інформації буде відображатись некоректно, що неприйнятно для користувача. Для окремих елементів необхідно більше місця при зміні орієнтації пристрою. ===== 3.14 Вимоги до технічного забезпечення ===== Склад програмних засобів, які будуть використовуватися при побудові сховища даних: * Microsoft Server 2017; * Microsoft SQL Express 2017; * My SQL 8.0 Автоматизовані робочі місця користувачів Сервісу повинні бути розгорнуті на базі сучасних комп’ютерів та планшетів, технічні характеристики яких враховують функціональне використання автоматизованого робочого місця за призначенням в повному обсязі відповідно до вимог щодо якості функціонування Сервісу. Технічне забезпечення надається Замовником. ===== 3.15 Вимоги до організаційного забезпечення ===== Організаційне забезпечення, що впроваджуватиметься в межах Сервісу, включатиме документи, які будуть відображати автоматизований технологічний процес обробки інформації та регламентуватимуть діяльність користувачів. ===== 3.16 Вимоги до методичного забезпечення ===== Рішення щодо методичного забезпечення будуть враховувати оптимізацію ділових (функціональних) процесів підрозділів відповідно до змін, що відображають автоматизацію цих процесів. В ході виконання робіт Виконавець може надати пропозиції щодо змін у нормативні акти (за необхідності), в нормативно-технічну документацію відповідно до прийнятих технічних та організаційних рішень у Сервісі. Вимоги щодо методичного забезпечення можуть бути уточнені в ході роботи над Сервісом. ===== 3.17 Проведення аналізу даних та формування інтерактивної звітності з використанням OLAP-технологій ===== Куби OLAP використовуються для створення та обслуговування сховищ даних. Куб OLAP представляє структуру даних в SQL службам Analysis Services (SSAS), побудований, на основі даних зі сховища ПС АСОП, для подальшого аналізу даних. Рисунок 1.Макет представлення даних в ПС АСОП Необхідно реалізувати можливість консолідації і зберігання даних OLAP кубу. Програмний сервіс має забезпечити: * Час на формування звіту з OLAP кубу не повинен перевищувати 5 секунд. * Можливість зведення даних з різних баз (АСОП, КК) в єдиний простір сховище ПС АСОП. * Можливість проведення подальшого бізнес-аналізу ситуації за принципом «що буде, якщо». * Детальність представлення результатів може змінюватися в залежності від потреби. * Можливість побудови багатовимірних зв'язків для можливості виявлення і визначення прихованих залежностей. * Автоматичне обслуговування куба без втручання адміністратором, включно з виконанням обробки, секціонуванням, перекладом і локалізацією, а також зміни схеми. ===== 3.18 Вимоги до технологічної документації та методичного забезпечення ===== Вся документація оформлюється українською мовою в двох примірниках та затверджується в друкованому вигляді з наданням копій в електронному вигляді. Технічна документація розробляється у відповідності до чинних державних стандартів та з використанням термінології згідно галузевих і корпоративних стандартів. Склад документації на створення набору Сервісів повинен включати наступне: - Звіт з аналізу бізнес-процесів. - Технічне завдання. - Програма та методика попередніх випробувань. - Програма та методика дослідної експлуатації. - Описи Сервісу. - Інструкція. - Програмне забезпечення на цифровому носії із відомістю (із вихідними кодами). - Керівництво Адміністратора. - Керівництво Користувача. - Протокол попередніх випробувань. - Протокол дослідної експлуатації. Склад та зміст технологічної документації може бути розширений Виконавцем за згодою Замовника. Технологічна документація Сервісу оформлюється в обсязі, визначеному діючими стандартами та достатньому (за повнотою і змістом) для використання Сервісу обслуговуючим персоналом та користувачами Сервісу її функціональних можливостей в повному обсязі. У межах супроводження та технічного обслуговування Сервсіса Виконавецьукладає Угоду (не фінансову) про нерозголошення (Non-disclosure agreement) (шаблон документу надається Замовником). ===== 3.19 Вимоги до апаратного забезпечення системи ===== Склад та технічні параметри засобів апаратного забезпечення системи, а саме електронно-обчислювальних машин, мережевої апаратури, допоміжного обладнання тощо, повинні відповідати наступним вимогам: * забезпечення реалізації функціональності системи у повному обсязі; * відповідність наявних технічних засобів у Замовника мінімальній специфікації обладнання системи; * врахування зростання вимог до обладнання у перспективі; * взаємна сумісність різних типів апаратних засобів Замовника; * можливість організації інтеграції з зовнішніми системами, апаратними засобами, тощо; * забезпечення найвищої якості та продуктивності роботи системи. Всі компоненти апаратного забезпечення та інфраструктури, які використовуються для розгортання системи, по винні відповідати вимогам сучасності, максимальної ефективності та швидкодії. Автоматизовані робочі місця (АРМ) користувачів системи розгортаються виключно з використанням сучасного комп'ютерного обладнання, яке забезпечує функціонування системи в оптимальному режимі та у повному обсязі. ====== 4. ФУНКЦІОНАЛЬНІ ВИМОГИ ====== ===== 4.1 Інтеграція та/або обмін даними з системами та/або базами даних щодо отримання інформації про утримувачів муніципальної картки «Картка киянина» (пільговиків та категорії їх пільг) ===== Інтеграція та обмін даними з базами даних повинно бути реалізовано для отримання інформації про утримувачів муніципальної картки «Картка киянина», а також пільговиків та категорії їх пільг з Інформаційно-телекомунікаційної системи «Реєстр утримувачів муніципальної картки «Картка киянина» (далі – ІТС РУ МК КК) (див. Рисунок 2). Рисунок 2. Обмін даними з ІТС РУ МК КК Дані накопичуються в OLAP-кубі шляхом внесення через завантаження файлів на FTP сервері і подальшому записі до бази даних, порядок і формат даних описаний в Додатку 1 Регламент оновлення інформації ПС АСОП. ===== 4.2 Інтеграція та/або обмін даними з системами та/або базами даних щодо отримання інформації про здійснення реєстрацій електронного квитка та факти оплати пасажиром транспортної послуги Перевізника. ===== Інтеграція та обмін даними з базами даних повинно бути реалізовано для отримання інформації про інформації про здійснення реєстрацій електронного квитка з Інформаційно-телекомунікаційної системи Автоматизована система обліку оплати проїзду в міському пасажирському транспорті міста Києва незалежно від форм власності (далі – ІТС АСОП) (див. Рисунок 2). Рисунок 3. Обмін даними з ІТС АСОП Дані накопичуються в OLAP-кубі шляхом внесення через завантаження файлів на FTP сервері і подальшому записі до бази даних, порядок і формат даних описаний в Додатку 1 Регламент оновлення інформації ПС АСОП. ===== 4.3 Здійснення формування звітів ===== Програмний Сервіс дозволить формувати різноманітну звітність у вигляді зведених таблиць. Використовуючи інструменти, що дозволяють відфільтровувати по тим чи іншим параметрам. Рисунок 4. Макет вікна Робоча область повинна мати результат опрацювання запиту. \\ \\ \\ \\ \\ \\ \\ \\ \\ \\ \\ \\ Пункт «Дані» має дозволити відкрити дані які не відносяться до Програмного Сервісу АСОП (віддалене сховище) для можливості подальшого аналізу. Рисунок 5. Макет форми завантаження даних \\ Пункт «Відкрити» має дозволити відобразити дані з Локального файлу на пристрої користувача для можливості подальшого аналізу. Рисунок 6. Макет форми внесення звіту \\ Для вивантаження звіту необхідно натиснути на кнопку «Зберігти», відобразиться вікно підтвердження вивантаження. Рисунок 7. Макет кнопки вивантаження файл. Після натискання на дану кнопку повинно відобразитись вікно «Підтвердження» \\ Рисунок 8. Макет вікна підтвердження вивантаження файлу Сформована зведена таблиця має зберігатись файл у форматі json на пристрої користувача. Для реалізації можливості збереження файлу у форматах : doc, docx, xls, xlsx, pdf, які можливо відкрити за допомогою будь-якого текстового редактора (Microsoft Word, Блокнот тощо) буде використовуватись елемент «Експорт», при наведені буде відображатись доступний перелік форматів. \\ Рисунок 9. Макет реалізації вивантаження звітів \\ Пункт «Графіки» повинен дозволяти змінити відображення даних у зведеній таблиці у графічному вигляду Рисунок 10. Макет вибору пунктів, представлення звіту у графічному вигляді \\ Кнопка «Таблиця» повинна дозволяти повернутися до форми зведеної таблиці Рисунок 11. Макет кнопки «Таблиця» Кнопка «Опції» дасть змогу додатково вказувати параметри відображення даних, для додаткової можливості відображати дані: загальні підсумки, проміжні підсумки, параметри. Рисунок 12\\ . Макет форми зміни параметрів відображення даних При зміні параметрів відображення даних у зведеній таблиці змінюється у відповідності до вибраних параметрів. Кнопка «Поля» дозволить відкрити вікно формування звіту який буде відображений у зведеній таблиці \\ Рисунок 13. Макет кнопки «Поля» Серед усіх наявних параметрів реалізувати можливість обирати за принципом логічних операторів. Кожен з цих вимірів буде можливо перетягнути за допомогою лівої кнопки миші у: фільтри, колонки, рядки, міри. У вікні конструктора, де повинна бути представлена основна частина, яка містить робочі панелі: фільтри, рядки, колонки. Зліва повинна бути можливість фільтрації та пошуків. В залежності від обраних фільтрів можливо сформувати звіт. Для цього необхідно: - Поля вимірів повинні перетягуватися за допомогою миші. - Натиснути на панелі кнопку «Застосувати». Рисунок 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. Обрахування міри ===== 4.4 Формування звітів різного типу по кількості та/або вартості використання транспортних продуктів в розрізі Перевізників, маршрутів, транспортних засобів, категорій пасажирів, пільгових категорій пасажирів тощо. ===== Компонент повинен забезпечувати, формування звітів різного типу по кількості та/або вартості використання транспортних продуктів. Компонент має включати: * Блок даних по перевізникам. * Блок даних по маршрутам. * Блок даних по транспортним засобам. * Блок даних по категоріям видів носіїв електронного квитка. * Аналітичні інструменти для обробки блоків даних і формування довільних звітів. * Модуль формування користувацьких звітів шляхом додавання даних через передбачену в веб-інтерфейсі форму. Звіт формується у вигляді зведеної таблиці і має бути відображений у відповідній веб-формі, числовими значеннями, можливістю фільтрації даних а також інтерпретації даних до графічного відображення (діаграма і гістограма). При використані аналітичних формул вирішити проблему стандарту IEEE 754 реалізувати можливість збереження і відображення чіткої суми (приклад: при використані формули: =1,324-1,319 результат 0, 00500000000000012.). При неможливості відображення звіту в веб-формі з причин технологічного обмеження, реалізувати можливість вивантаження звіту на пристрій користувача з відповідними параметрами які зазначаються користувачем системі. Звіти різного типу по кількості та/або вартості використання транспортних продуктів в розрізі Перевізників, маршрутів, транспортних засобів, категорій пасажирів, пільгових категорій пасажирів тощо, повинен відображати наступну інформацію: Таблиця 1. Характеристика полів для побудови звітів по використанню транспортних продуктів. ^**Звіт про використання транспортних продуктів** ^ ^ ^ |**Назва критерію** |**Тип/формат** |**Приклад** | |**Параметри** | | | |Назва продукту |Текст |Разовий квиток (QR-код)| |Тип транспорту |Текст |Автобус | |№ маршруту |Номер (число) |100 | |Кількість поїздок |Кількість (число) |43 | |Сума коштів |Кількість (число) |32 | |ID картки користувача |Номер (число) |1000000000000000 | |**Фільтри** | | | |Разовий квиток (QR-код) |Кількість (число) |43 | |Разова поїздка з гаманця особової картки |Кількість (число) |41 | |1-9 поїздок (8 грн.) |Кількість (число) |65 | |10-19 поїздок (7,70 грн.) |Кількість (число) |54 | |20-29 поїздок (7,40 грн.) |Кількість (число) |4 | |30-39 поїздок (7,10 грн.) |Кількість (число) |45 | |40-49 поїздок (6,80 грн.) |Кількість (число) |5 | |50 поїздок (6,50 грн.) |Кількість (число) |25 | |Студентський квиток (50 %) |Кількість (число) |36 | |Учнівський квиток |Кількість (число) |38 | |КМДА пільгова картка (100 %) |Кількість (число) |40 | |Службовий КПТ |Кількість (число) |42 | |Службовий Метрополітен |Кількість (число) |44 | |Державна пільгова картка (100 %) |Кількість (число) |46 | |Проїзний на визначений період без обмеження кількості поїздок|Кількість (число) |48 | |Період вибірки даних |дд.мм.рррр / дд.мм.рррр|10.01.2019 / 02.05.2019| Спосіб відображення інформації повинен відповідати шаблону (Рисунок 17). Рисунок 17. Макет вибору фільтру Рисунок 18. Макет сформованого звіту ===== 4.5 Формування звітів по агентам, що реалізують транспортні продукти для пасажирів у міському пасажирському транспорті ===== Компонент повинен забезпечувати, формування звітів по агентам, що реалізують транспортні продукти для пасажирів у міському пасажирському транспорті. Компонент має включати: * Блок даних по агентам. * Блок даних по категоріям пасажирів. * Аналітичні інструментів для обробки блоків даних і формування довільних звітів. * Модуль формування користувацьких звітів шляхом додавання даних через передбачену в веб-інтерфейсі форму. Звіт по агентам, що реалізують транспортні продукти для пасажирів у міському пасажирському транспорті, повинен відображати наступну інформацію: Таблиця 2. Характеристика полів для побудови звітів по реалізації агентами транспортних продуктів ^**Звіт по агентам** ^ ^ ^ |**Назва критерію** |**Тип/формат** |**Приклад** | |**Параметри** | | | |Назва агенту |Текст |ФК "ГЕРЦ" | |Банк |Текст |psp_okkasop1_vu pb | |Назва продукту |Текст |Разовий квиток (QR-код)| |Каса |Текст |Каса №1 | |Кількість поїздок |Кількість (число) |43 | |Сума коштів |Кількість (число) |32 | |**Фільтри** | | | |Разовий квиток (QR-код) |Кількість (число) |43 | |Разова поїздка з гаманця особової картки |Кількість (число) |41 | |1-9 поїздок (8 грн.) |Кількість (число) |65 | |10-19 поїздок (7,70 грн.) |Кількість (число) |54 | |20-29 поїздок (7,40 грн.) |Кількість (число) |4 | |30-39 поїздок (7,10 грн.) |Кількість (число) |45 | |40-49 поїздок (6,80 грн.) |Кількість (число) |5 | |50 поїздок (6,50 грн.) |Кількість (число) |25 | |Студентський квиток (50 %) |Кількість (число) |36 | |Учнівський квиток |Кількість (число) |38 | |КМДА пільгова картка (100 %) |Кількість (число) |40 | |Службовий КПТ |Кількість (число) |42 | |Службовий Метрополітен |Кількість (число) |44 | |Державна пільгова картка (100 %) |Кількість (число) |46 | |Проїзний на визначений період без обмеження кількості поїздок|Кількість (число) |48 | |Період вибірки даних |дд.мм.рррр / дд.мм.рррр|10.01.2019/ 02.05.2019 | |Ідентифікатор районна (для користувачів картки киянина) |Текст |Дарницький | |Метод оплати |Текст |Термінал | |Місце оплати |Текст |ст.м Хрещатик | |Стать користувача |Текст (чол/жін) |Жінка | Звіт формується на підставі зведеної таблиці і має бути відображений у відповідній веб формі, числовими значеннями, можливістю фільтрації даних а також інтерпретації даних до графічного відображення (діаграма і гістограма). Реалізувати можливість приховування дублюючих записів, а також наявність інформаційних підказок про походження інформації. При використані аналітичних формул вирішити проблему стандарту IEEE 754 реалізовати можливість збереження і відображення чіткої суми (Приклад при використані формули: =1,324-1,319 результат 0,00500000000000012). При неможливості відображення звіту в веб-формі з причин технологічного обмеження, реалізувати можливість вивантаження звіту на пристрій користувача з відповідними параметрами які зазначаються користувачем системі, реалізувати можливість вивантаження звіту у форматах визначені пунктом 3.4. ===== 4.6 Формування звітів по перевізникам міста Києва, що відносяться до КП «Київпастранс» (далі – КПТ), КП «Київський метрополітен» (далі – КМ) та інших форм власності ===== Компонент повинен забезпечувати, формування звіти по перевізникам міста Києва, що відносяться до КП КПТ, КМ та інших форм власності. Компонент має включати: * Блок даних по перевізникам. * Блок даних по категоріям пасажирів. * Блок даних по маршрутам. * Блок даних по транспортним засобам. * Аналітичні інструментів для обробки блоків даних і формування довільних звітів. * Модуль формування користувацьких звітів шляхом додавання даних через передбачену в веб-інтерфейсі форму. Звіти по перевізникам міста Києва, що відносяться до КП КПТ, КМ та інших форм власності, повинен відображати наступну інформацію: Таблиця 3. Характеристика полів для побудови звітів по перевізникам ^**Звіти по перевізникам** ^ ^ ^ |**Назва критерію** |**Тип/формат** |**Приклад** | |**Параметри** | | | |Лінія метрополітену / Депо |Текст |Святошинсько-Броварська лінія| |Станція метрополітену |Текст |Почайна | |Тип транспорту |Тип (текст) |Автобус | |№ маршруту |Номер (число) |100 | |**Фільтр** | | | |Разовий квиток (QR-код) |Кількість (число) |43 | |Разова поїздка з гаманця особової картки |Кількість (число) |41 | |1-9 поїздок (8 грн.) |Кількість (число) |65 | |10-19 поїздок (7,70 грн.) |Кількість (число) |54 | |20-29 поїздок (7,40 грн.) |Кількість (число) |4 | |30-39 поїздок (7,10 грн.) |Кількість (число) |45 | |40-49 поїздок (6,80 грн.) |Кількість (число) |5 | |50 поїздок (6,50 грн.) |Кількість (число) |25 | |Студентський квиток (50 %) |Кількість (число) |36 | |Учнівський квиток |Кількість (число) |38 | |КМДА пільгова картка (100 %) |Кількість (число) |40 | |Службовий КПТ |Кількість (число) |42 | |Службовий Метрополітен |Кількість (число) |44 | |Державна пільгова картка (100 %) |Кількість (число) |46 | |Проїзний на визначений період без обмеження кількості поїздок|Кількість (число) |48 | |Період вибірки даних |дд.мм.рррр / дд.мм.рррр |10.01.2019 / 02.05.2019 | Звіт формується на підставі зведеної таблиці і має бути відображений у відповідній веб формі, числовими значеннями, можливістю фільтрації даних а також інтерпретації даних до графічного відображення (діаграма і гістограма). Реалізувати можливість приховування дублюючих записів, а також наявність інформаційних підказок про походження інформації. При використані аналітичних формул вирішити проблему стандарту IEEE 754 реалізувати можливість збереження і відображення чіткої суми (Приклад при використані формули: =1,324-1,319 результат 0,00500000000000012). При неможливості відображення звіту в веб-формі з причин технологічного обмеження, реалізувати можливість вивантаження звіту на пристрій користувача з відповідними параметрами які зазначаються користувачем системі, реалізувати можливість вивантаження звіту у форматах визначені пунктом 3.4. ===== 4.7 Здійснення налаштування фільтрації для кожного звіту окремо. ===== При роботі з даними користувач повинен мати можливість обрати інформацію, наприклад, по декільком видам пільг, продуктам, перевізникам тощо. Так, наприклад у звіті по агентам буде можливість фільтрувати за такими полями: * Назва агенту. * Банк. * Назва продукту. * Каса. * Кількість поїздок. * Сума коштів. * Фільтри. * Разовий квиток (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 %). * Проїзний на визначений період без обмеження кількості поїздок. * Період вибірки даних. ====== 5. ОПИС ПРОПОНОВАНОГО РІШЕННЯ ====== Програмний сервіс АСОП повинен бути створений, як частина Платформи «Big Data» для відображення достовірної аналітичної та оперативної інформації щодо певних аспектів роботи системи АСОП у розрізі даних: * Реалізації і використання транспортних продуктів * Утримувачів муніципальної картки «Картка киянина» і використання пільгового проїзду. * Проводити обрахунки отриманих даних від АСОП * Представляти отримані дані у вигляді графіків / діграм. Оновлення даних в базі даних ПС АСОП відбувається в нічний час, в період найменшого навантаження на бази даних ЗІС. У межах створення Сервісу використовуються джерела даних, для яких будуть налаштовані компоненти, а саме: * технологія OLAP; * сховище зберігання даних; * компонент побудови звітів; * програмні сервіси для обробки запитів та представлення даних. Технологія OLAP є ключовим компонентом організації сховищ даних. Ця технологія заснована на побудові і візуалізації багатовимірних кубів даних з можливістю довільного маніпулювання даними, що містяться в кубі. Це дозволяє представити дані для аналізу в будь-якому розрізі. Куб OLAP представляє структуру даних в SQL службам Analysis Services (SSAS), побудований, за допомогою бази даних «Сховище ПС АСОП», для подальшого представлення та аналізу даних. Сховище зберігання даних – це сховище ПС АСОП для консолідації даних, що надходять з зовнішніх джерел даних (БД КК та БД АСОП). Для побудови сховища даних необхідними є наявність: * Microsoft Windows Server 2017; * Microsoft SQL Express Server 2017; * MySQL 0. Компонент побудови звітів дозволяє на основі даних, що надходять із зовнішніх інформаційних систем (АСОП та «Картка киянина») формувати звіти за допомогою технології OLAP для поглибленого аналізу та оцінки: * Реалізації транспортних продуктів агентами. * Утримувачів муніципальної картки «Картка киянина» і використання пільгового проїзду. * Використання транспортних продуктів пасажирами. * Ефективність роботи перевізників. Компонент побудови звітів складається з модулів: * Сервіс обробки запитів. * Сервіс представлення даних. * Модуль аналітичних обрахунків. Звернення користувачів надходять на центральний рівень до серверу додатків та баз даних за отриманням необхідних даних. ===== 5.1 Рольова модель ПС АСОП ===== У відповідності зі звітом по аналізу бізнес процесу передбачається наступна рольова модель: * Користувач - внутрішній користувач системи Замовника; * Користувач публічної інформації - мешканець м. Києва; * Адміністратор. \\ - **** **Користувач** Мета та завдання діяльності: Основна мета діяльності Користувача – самостійно формувати довільні звіти в потрібних розрізах роботи автоматизованої системи обліку оплати проїзду в міському пасажирському транспорті міста Києва, отримувати дані про утримувачів муніципальної картки «Картка киянина» та АСОПу для подальшого формування аналітичної звітності. - **** **Користувач публічної інформації** Мета та завдання діяльності: Основна мета діяльності Користувача публічної інформації – бачити загальну статистику роботи автоматизованої системи обліку оплати проїзду в міському пасажирському транспорті міста Києва, муніципальної картки «Картка киянина» та АСОПу. - **** **Адміністратор** Мета та завдання діяльності: Адміністратор - посадова особа у складі персоналу, який необхідний для забезпечення адміністрування Системи в межах відповідних підрозділів Замовника. Функціональні обов’язки Адміністратора : * забезпечити роботу системи в цілому і відповідати за достовірність даних, що зберігаються; * здійснювати моніторинг реєстру користувачів системи та регламентувати їх права доступу до Системи; * проводити моніторинг технічного складу сервісу: * завантаженості процесорів; * завантаженості операційної пам’яті; * завантаженості фізичних дисків; * завантаженості мережевих інтерфейсів; * приймати рішення з питань, які стосуються технічного супроводу сервісу; * планувати та проводити резервне копіювання і відновлення інформації. Передбачається, що збереження відбуватиметься шляхом тіньового копіювання сервера, на якому розташовується ПС АСОП. Збереження даних відбувається щоденно; * здійснювати процедури регламентного обслуговування ПС АСОП, що полягає у виконанні * оптимізації на основі використання, яка передбачає, що OLAP куб обчислює і зберігає заздалегідь зібрані агрегати разом з даними. Якщо запит може бути задоволений, то, натиснувши на агрегат, сервер OLAP виконає даний запит і пришвидшить формування звіту; * Запрограмованих і пакетних завдань адміністратора, які дозволяють створювати сценарії для поліпшення використання ПС АСОП. ===== 5.2 Джерела даних та їх перетворення в ПС АСОП ===== В основу інформаційного забезпечення Сервісу повинен бути покладений принцип однократного введення і єдиного місця збереження інформації та багаторазового її використання для рішення задач Сервісу. Аналізуючи дані, схема інформаційних потоків буде мати наступний вигляд: Рисунок 19.Схема інформаційних потоків в ПС АСОП Забезпечення створення шлюзу обміну даними із ЗІС КП ГІОЦ повинно відбуватиметься шляхом: - Вивантаження даних зі ІТС АСОП і ІТС РУ МК КК на FTP сервер, вивантаження даних представлених у Таблиці 1 до сховища даних ПС АСОП; - Передача даних до OLAP кубу і перетворення їх у формат описаний у розділі 5.6; - Запис даних до OLAP кубу; - Багаторівневе кешування OLAP кубу; - Опрацювання запитів отриманих від сервісу обробки запитів, вибір отриманих параметрів; - Передача звіту до сервісу представлення даних. Процедури оновлення даних з завданою регулярністю підключатимуться до БД для проміжних даних, перевіряють повноту даних, обробляють, перетворюють та завантажують їх на віртуальну машину – сервери баз даних та додатків ПС АСОП. Звернення користувачів надходитимуть до серверу застосувань та баз даних за отриманням необхідних даних. Візуально модель структури даних в ПС АСОП має наступний вигляд : Рисунок 20. Модель структури даних в ПС АСОП У відповідності до моделі проведемо опис наявних даних: Таблиця 4. Структура даних довідника «Оплата» ^**№ з/п**^**Назва елементу** ^**Назва поля**^**Тип/формат** ^ |1 |Місце оплати |DisplayName |Назва (текст, до 250 символів) | |2 |ЕДРПОУ підприємства |Edrpou |Числовий (8 симовлів) | |3 |Банк |Bank |Назва (текст, до 250 символів) | |4 |Каса |Kass |Назва (текст, до 250 символів) | |5 |Номер картки |CardId |Назва (текст, до 250 символів) | |6 |Дата |Created |дд.мм.рррр | |7 |Метод оплати |PaymentMethod |Назва (текст, до 250 символів) | |8 |Ідентифікатор продукту|ProductId |Числовий (цифри, , до 250 символів)| |9 |Назва продукту |ProductName |Назва (текст, до 250 символів) | |10 |Сума |Sum |Число | Таблиця 5. Структура даних довідника «Підтвердження валідації» ^**№ з/п**^**Назва елементу** ^**Назва поля** ^**Тип/формат** ^ |1 |Ідентифікатор рядка|ID |Ідентифікатор (Число до 30 символів)| |2 |Дата валідації |BillingDay |дд.мм.рррр гг:хх | |3 |Номер картки |CardId |Текст ( до 250 символів) | |4 |ЄДРПОУ пiдприємства|Edrpou |Числовий ( до 8 символів) | |5 |Назва Депо |DepotName |Назва (текст, до 250 символів) | |6 |Лінія |Line |Назва (текст) , до 250 символів) | |7 |Тип транспорту |LocationTypeName|Назва (текст, до 250 символів) | |8 |Назва продукту |ProductName |Назва (текст, до 250 символів) | Таблиця 6. Структура даних довідника «Пільгова категорія» ^**Назва елементу** ^**Назва поля**^**Тип/формат** ^ |Ідентифікатор рядка|id |Ідентифікатор (число до 30 символів)| |Код категорії |code |Назва (текст, до 250 символів) | |Категорія |name |Назва (текст, до 250 символів) | Таблиця 7. Структура даних довідника «Дані про реєстрацію проживання» ^**Назва елементу** ^**Назва поля**^**Тип/формат** ^ |Ідентифікатор рядка |id |Ідентифікатор (число до 30 символів)| |Ідентифікатор людини|person_id |Ідентифікатор (число до 30 символів)| |Код країни |country_code |Назва (текст, до 250 символів) | |Регіон |region |Назва (текст, до 250 символів) | |Місто |locality |Назва (текст, до 250 символів) | |Ідентифікатор района|DistictID |Ідентифікатор (число до 30 симовлів)| |Назва вулиці |street |Назва (текст, до 250 символів) | |Номер будинку |address_object|Назва (текст, до 250 символів) | Таблиця 8. Структура даних довідника «Стать» |**Назва елементу**|**Назва поля**|**Тип/формат** | |Код статі |code |Літера (один символ) | |Назва статі |name |Назва (текст, до 250 символів)| Таблиця 9. Структура даних довідника «Платіжна картка» ^**Назва елементу** ^**Назва поля**^**Тип/формат** ^ |Идентифікатор рядка |id |Ідентифікатор (число до 30 символів) | |Ідентифікатор людини|person_id |Ідентифікатор (число до 30 символів) | |Номер картки |card_number |Літерні та числові символи (до 250 символів)| |Код банку |bank_code |Літерні та числові символи( до 250 символів)| |Номер рахунку |account |Літерні та числові символи (до 250 символів)| |Статус |status_code |Літерні та числові символи (до 250 символів)|