rest_documentconversion_latest_conversion_thumbnail_32309534_1
ЗАТВЕРДЖУЮ КП «Головний інформаційно-обчислювальний центр» | ЗАТВЕРДЖУЮ ТОВ «СІВІС» |
Директор | Директор |
_______________В.М. Козубський | _________________ О. О. Юношева |
«______»______________ 2019 р. М. П | «______»__________________2019 р. М. П |
Створення програмного сервісу Автоматизована система обліку оплати проїзду в міському пасажирському транспорті міста Києва незалежно від форм власності, що входить до складу єдиної інформаційно-аналітичної платформи консолідації та аналізу великих даних «Big Data» в місті Києві
Шифр: ПС АСОП
Технічне завдання
на створення ПС АСОП
39194632.184154.4687.ТЗ
Етап 1 п 1.1
На _____ аркушах
Від Замовника: | Від Виконавця: | |
Начальник департаменту розвитку обліково-фінансових систем, голова комісії | Директор |
|
________________ А. П. Гусаревич | _____________ О. О. Юношева | |
ЗМІСТ ПЕРЕЛІК ТЕРМІНІВ ТА СКОРОЧЕНЬ.. 6
1.1 Найменування системи та її умовне позначення. 11 1.2 Шифр теми або номер договору: 11 1.3 Найменування організацій Замовника і Розробника, їх реквізити. 11 1.4 Підстави для розробки (перелік документів, на підставі яких створюється проект, ким і коли затверджені ці документи) 12 1.5 Планові терміни початку і закінчення роботи із створення Сервісу. 12 1.6 Порядок передачі замовнику результатів робіт по розробці Сервісу. 12
2.1 Призначення ПС АСОП.. 13 2.2 Мета і завдання створення ПС АСОП.. 13
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
4.1 Інтеграція та/або обмін даними з системами та/або базами даних щодо отримання інформації про утримувачів муніципальної картки «Картка киянина» (пільговиків та категорії їх пільг) 31 4.2 Інтеграція та/або обмін даними з системами та/або базами даних щодо отримання інформації про здійснення реєстрацій електронного квитка та факти оплати пасажиром транспортної послуги Перевізника. 31 4.3 Здійснення формування звітів. 32 4.4 Формування звітів різного типу по кількості та/або вартості використання транспортних продуктів в розрізі Перевізників, маршрутів, транспортних засобів, категорій пасажирів, пільгових категорій пасажирів тощо. 40 4.5 Формування звітів по агентам, що реалізують транспортні продукти для пасажирів у міському пасажирському транспорті 43 4.6 Формування звітів по перевізникам міста Києва, що відносяться до КП «Київпастранс» (далі – КПТ), КП «Київський метрополітен» (далі – КМ) та інших форм власності 46 4.7 Здійснення налаштування фільтрації для кожного звіту окремо. 48
5.1 Рольова модель ПС АСОП.. 51 5.2 Джерела даних та їх перетворення в ПС АСОП.. 52 5.4. Опис інтеграції з Платформою KYIVSMARTCITY у рамках модулю моніторингу. 59 5.5 Архітектура Сервісу АСОП.. 61 5.6 Опис компонента консолідації даних різних об’єктів функціонування та даних різних рівнів ієрархії для аналітичного дослідження інформації 68 5.7 Інтерактивні елементи у зручному та зрозумілому представленні із набором відповідних текстових та/або графічних інформаційних підказок. 69 5.8 Компонент управління правами доступу користувачів Сервісів з розподіленням доступу функцій в межах сервісів. 70
Регламент оновлення інформації у ПС АСОП.. 83
Термін | Значення |
---|---|
.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://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) реалізаціях арифметичних дій (математичних операцій). |
ТЗ | Технічне завдання |
ЦБД | Центральна база даних |
Повне найменування системи: Програмний сервіс для отримання даних з автоматизованої системи обліку оплати проїзду в міському пасажирському транспорті міста Києва незалежно від форм власності (далі – АСОП), а також даних про утримувачів муніципальної картки «Картка киянина» (умовне позначення – ПС АСОП). Умовне позначення: ПС АСОП, далі – Сервіс. Дане Технічне Завдання стосується розробки та впровадження ПС АСОП, який дозволить формувати аналітичні та статистичні звіти щодо виду транспортних продуктів, перевізників, , відображати достовірну аналітичну та оперативну інформацію у розрізі пільгові категорії пасажирів, підвищить зручність роботи користувачів ПС АСОП всіх типів із збереженням рівня надійності та зручності рішення. Програмний сервіс АСОП створюється як частина Платформи «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». Основною аудиторією користувачів Сервісу є керівництво і фахівці структурних підрозділів КМДА, державних і комунальних підприємств та організацій, які будуть використовувати Сервіс для забезпечення підтримки прийняття управлінських рішень.
Метою створення програмного сервісу АСОП є надання інформаційно-аналітичних інструментів, як основи для подальшого аналітичного дослідження великих даних, конструювання та опрацювання аналітичних та статистичних звітів з метою підтримки прийняття управлінських рішень. Основними завданнями Сервісу виступають:
Програмний сервіс АСОП створюється як частина Платформи «Big Data» для відображення достовірної аналітичної та оперативної інформації щодо необхідних аспектів роботи системи АСОП, у розрізі даних про утримувачів муніципальної картки «Картка киянина» та використанню транспортних продуктів для підвищення зручності роботи користувачів всіх типів із збереженням рівня надійності та зручності рішення. Цілями розробки та впровадження ПС АСОП є:
Сервіс має забезпечити:
Розробка Сервісу відбувається на підставі та з урахуванням вимог наступних нормативно-правових документів:
Вимоги із забезпечення захисту інформації реалізовуватимуться за рахунок створення комплексу засобів захисту, який складається із програмних засобів криптографічного захисту інформації, засобів підсистеми «Адміністрування» та засобів захисту операційних систем. У складі комплексу засобів захисту будуть застосовані програмні засоби криптографічного захисту інформації, які мають діючий позитивний експертний висновок Державної служби спеціального зв'язку та захисту інформації України. У Сервісі буде реалізований захищений доступ до системи на рівні логінів/паролів підключення до Сервісу, які шифруватимуться за алгоритмом хешування SHA-256, MD5. Також буде шифруватися доступ до ядра системи та всіх окремих елементів ( автоматизоване робоче місце (АРМ), підключені мережеві пристрої, пристрої модуляції сигналів тощо). Зв’язок між елементами системи будуватиметься на технології шифрованих тунелів, які разом об’єднуються у загальну внутрішню мережу. Для забезпечення конфіденційності та цілісності даних, що передаються між сервером програмних застосувань та веб-інтерфейс користувача а також двохфакторної ідентифікації (автентифікації) користувачів АРМ, буде використовуватися програмний засіб криптографічного захисту інформації, який відповідає наступним загальним вимогам:
Для забезпечення конфіденційності та цілісності даних при введенні даних з клієнтських АРМ, захищеного збереження інформації про дії користувачів та адміністраторів системи буде застосований програмний засіб криптографічного захисту інформації, що відповідає наступним загальним вимогам:
Захист компонентів від несанкціонованого доступу буде виконуватися за рахунок реалізації таких заходів:
Розробка та впровадження комплексної системи захисту інформації не є предметом даного договору, її може бути реалізовано в подальшому в межах виконання окремих робіт.
Доступ до інформаційних ресурсів Сервісу надається з метою виконання функцій та завдань, які визначені в чинному законодавстві України, наказах, положеннях, розпорядженнях чи інших нормативних документах, або інших робіт згідно договору. Доступ до інформації з обмеженим доступом, що знаходиться у Сервісі, після підписання договору про конфіденційність і нерозголошення інформації надається через захищені канали зв’язку з використанням програмних або технічних засобів криптографічного захисту інформації, що мають позитивний експертний висновок ДССЗЗІ. При проектуванні ПС АСОП були реалізовані базові заходи безпеки інформації. При реалізації четвертої черги повинні використовуватися вже започатковані заходи безпеки, а саме:
Вимоги щодо КСЗІ визначатимуться в окремому Технічному завданні, що буде розроблятись Виконавцем, якого буде визначено за результатами проведення окремої конкурсної процедури. Для забезпечення безпеки передачі даних між робочим місцем Користувача та серверним програмним комплексом у ПС АСОП буде передбачена можливість використання програмних засобів криптографічних перетворень, який має позитивний експертний висновок Державної служби спеціального зв'язку та захисту інформації України.
Експлуатація Сервісу передбачатиме такі режими:
Рішення з чисельності та кваліфікації персоналу повинні забезпечити:
Повинні бути запропоновані рішення щодо чисельності та кваліфікації обслуговуючого персоналу Сервісу. Пропозиція повинна бути обґрунтована та мати оптимізований склад обслуговуючого персоналу.
Надійність Сервісу АСОП повинна забезпечуватись за наступними напрямками:
При відмові одного або декількох компонентів механізми із збереження працездатності повинні забезпечувати надійність роботи за рахунок їх резервування. При цьому відбуватиметься мінімальна концентрація уваги з боку системного адміністратора, щодо реакції на усунення наслідків відмов компонентів. Програмно-апаратними засобами повинно бути забезпечене збереження даних. Збереження даних повинно забезпечувати збереження цілісності даних при програмно-апаратних відмовах, помилках, шляхом використання відповідних програмно-апаратних засобів та рішень, резервного копіювання, транзакційності при змінах даних. Збереження даних буде забезпечено у випадках:
Надійність функціонування Сервісу АСОП буде забезпечено при:
Повинна бути реалізована одна з наступних стратегій забезпечення надійності:
Рішення щодо ергономіки веб-інтерфейсу ПС АСОП повинні відповідати вимогам технічної естетики та інженерної психології для забезпечення гармонійного зв'язку між параметрами технічних засобів і психофізичними можливостями людини із урахуванням створення єдиного об’ємно-просторового і кольорового рішення відповідно до ГОСТ 12.2.032–78, ГОСТ 12.2.033–78, ГОСТ 24750–81. Веб-сторінки повинні відповідати таким вимогам:
Дизайн ПС АСОП повинен відповідати таким вимогам (далі – дизайн-код):
Рішення щодо ергономіки забезпечуватимуть:
Користувач повинен мати зручний інтерфейс із обґрунтованим набором необхідних інструментів для виконання певних дій, закладених у межах відповідного бізнес-процесу. У цілому передбачається сумісність:
Веб-інтерфейс повинен відповідати таким вимогам щодо використання технологій при його створенні:
Основні вимоги до інформаційно-графічних елементів веб-інтерфейсу:
Патентна чистота Сервісу буде забезпечена за рахунок використання при розробці ліцензійних апаратних і програмних засобів та обладнання і гарантується Розробником.
Стандартизація та уніфікація функцій Сервісу буде забезпечуватись за рахунок використання сучасних інструментальних програмних засобів які підтримують єдину технологію проектування і розробки функціонального, інформаційного та програмного забезпечень. У процесі розробки Сервісу будуть сформовані вимоги до розробки прикладного програмного забезпечення, які уніфікуватимуть процедуру обробки інформації, ідентифікацію програмних модулів та баз даних, типізуватимуть окремі програмні модулі відповідно до свого призначення. В даному документі описані вимоги до розробки прикладного програмного забезпечення, які уніфікують інтерфейс користувача, процедури обробки інформації, ідентифікацію програмних компонентів та баз даних, типізують окремі програмні модулі відповідно до свого призначення в різних функціональних підсистемах.
Інформаційне забезпечення розробляється достатнім для найбільш ефективного використання всіх функцій Сервісу. Інформаційне забезпечення відповідатиме наступним вимогам та можливостям:
Мовні засоби програмування обиратимуться Виконавцем відповідно до рішень з програмного забезпечення Сервісу.
Програмне забезпечення (ПЗ) системи складатиметься з:
Програмне забезпечення системи відображатиме специфіку автоматизованих функціональних задач користувачів та забезпечуватиме:
До загальносистемного програмного забезпечення відносяться:
До прикладного програмного забезпечення відноситься програмне забезпечення, що розробляється та налаштовується під час створення системи. Розробка прикладного програмного забезпечення буде проводитись за допомогою сучасних інструментальних засобів програмної інженерії проектування і генерації розподілених баз даних (CASE-засобів) з урахуванням можливості подальшого автоматизованого тестування. При розробці ППЗ будуть використовуватися принципи модульності та типовості, які забезпечать послідовне нарощування функціональних можливостей системи за рахунок створення, впровадження та тиражування функціонально завершених програмних модулів. В цілому передбачається сумісність ППЗ:
Основні вимоги до інформаційно-графічних елементів веб-інтерфейсу:
Склад програмних засобів, які будуть використовуватися при побудові сховища даних:
Автоматизовані робочі місця користувачів Сервісу повинні бути розгорнуті на базі сучасних комп’ютерів та планшетів, технічні характеристики яких враховують функціональне використання автоматизованого робочого місця за призначенням в повному обсязі відповідно до вимог щодо якості функціонування Сервісу. Технічне забезпечення надається Замовником.
Організаційне забезпечення, що впроваджуватиметься в межах Сервісу, включатиме документи, які будуть відображати автоматизований технологічний процес обробки інформації та регламентуватимуть діяльність користувачів.
Рішення щодо методичного забезпечення будуть враховувати оптимізацію ділових (функціональних) процесів підрозділів відповідно до змін, що відображають автоматизацію цих процесів. В ході виконання робіт Виконавець може надати пропозиції щодо змін у нормативні акти (за необхідності), в нормативно-технічну документацію відповідно до прийнятих технічних та організаційних рішень у Сервісі. Вимоги щодо методичного забезпечення можуть бути уточнені в ході роботи над Сервісом.
Куби OLAP використовуються для створення та обслуговування сховищ даних. Куб OLAP представляє структуру даних в SQL службам Analysis Services (SSAS), побудований, на основі даних зі сховища ПС АСОП, для подальшого аналізу даних. Рисунок 1.Макет представлення даних в ПС АСОП Необхідно реалізувати можливість консолідації і зберігання даних OLAP кубу. Програмний сервіс має забезпечити:
Вся документація оформлюється українською мовою в двох примірниках та затверджується в друкованому вигляді з наданням копій в електронному вигляді. Технічна документація розробляється у відповідності до чинних державних стандартів та з використанням термінології згідно галузевих і корпоративних стандартів. Склад документації на створення набору Сервісів повинен включати наступне:
Склад та зміст технологічної документації може бути розширений Виконавцем за згодою Замовника. Технологічна документація Сервісу оформлюється в обсязі, визначеному діючими стандартами та достатньому (за повнотою і змістом) для використання Сервісу обслуговуючим персоналом та користувачами Сервісу її функціональних можливостей в повному обсязі. У межах супроводження та технічного обслуговування Сервсіса Виконавецьукладає Угоду (не фінансову) про нерозголошення (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. Макет кнопки «Поля»
Серед усіх наявних параметрів реалізувати можливість обирати за принципом логічних операторів. Кожен з цих вимірів буде можливо перетягнути за допомогою лівої кнопки миші у: фільтри, колонки, рядки, міри.
У вікні конструктора, де повинна бути представлена основна частина, яка містить робочі панелі: фільтри, рядки, колонки. Зліва повинна бути можливість фільтрації та пошуків. В залежності від обраних фільтрів можливо сформувати звіт. Для цього необхідно:
Рисунок 14. Макет таблиці Вимірів Необхідно відобразити можливість
У верхній правій частині екрану над робочими панелями потрібно розмістити кнопки для здійснення додаткових операцій над формуванням звіту (див. Рисунок 15):
За необхідності буде реалізована можливість відмінити застосовані міри або дії Рисунок 15. Макет розміщення кнопок на конструкторі звіту Кнопка «Додати міру» дозволяє:
Рисунок 16. Обрахування міри
Компонент повинен забезпечувати, формування звітів різного типу по кількості та/або вартості використання транспортних продуктів. Компонент має включати:
Звіт формується у вигляді зведеної таблиці і має бути відображений у відповідній веб-формі, числовими значеннями, можливістю фільтрації даних а також інтерпретації даних до графічного відображення (діаграма і гістограма). При використані аналітичних формул вирішити проблему стандарту 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. Макет сформованого звіту
Компонент повинен забезпечувати, формування звітів по агентам, що реалізують транспортні продукти для пасажирів у міському пасажирському транспорті. Компонент має включати:
Звіт по агентам, що реалізують транспортні продукти для пасажирів у міському пасажирському транспорті, повинен відображати наступну інформацію: Таблиця 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.
Компонент повинен забезпечувати, формування звіти по перевізникам міста Києва, що відносяться до КП КПТ, КМ та інших форм власності. Компонент має включати:
Звіти по перевізникам міста Києва, що відносяться до КП КПТ, КМ та інших форм власності, повинен відображати наступну інформацію: Таблиця 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.
При роботі з даними користувач повинен мати можливість обрати інформацію, наприклад, по декільком видам пільг, продуктам, перевізникам тощо. Так, наприклад у звіті по агентам буде можливість фільтрувати за такими полями:
У звіті по перевізникам:
Програмний сервіс АСОП повинен бути створений, як частина Платформи «Big Data» для відображення достовірної аналітичної та оперативної інформації щодо певних аспектів роботи системи АСОП у розрізі даних:
Оновлення даних в базі даних ПС АСОП відбувається в нічний час, в період найменшого навантаження на бази даних ЗІС. У межах створення Сервісу використовуються джерела даних, для яких будуть налаштовані компоненти, а саме:
Технологія OLAP є ключовим компонентом організації сховищ даних. Ця технологія заснована на побудові і візуалізації багатовимірних кубів даних з можливістю довільного маніпулювання даними, що містяться в кубі. Це дозволяє представити дані для аналізу в будь-якому розрізі. Куб OLAP представляє структуру даних в SQL службам Analysis Services (SSAS), побудований, за допомогою бази даних «Сховище ПС АСОП», для подальшого представлення та аналізу даних. Сховище зберігання даних – це сховище ПС АСОП для консолідації даних, що надходять з зовнішніх джерел даних (БД КК та БД АСОП). Для побудови сховища даних необхідними є наявність:
Компонент побудови звітів дозволяє на основі даних, що надходять із зовнішніх інформаційних систем (АСОП та «Картка киянина») формувати звіти за допомогою технології OLAP для поглибленого аналізу та оцінки:
Компонент побудови звітів складається з модулів:
Звернення користувачів надходять на центральний рівень до серверу додатків та баз даних за отриманням необхідних даних.
У відповідності зі звітом по аналізу бізнес процесу передбачається наступна рольова модель:
Мета та завдання діяльності: Основна мета діяльності Користувача – самостійно формувати довільні звіти в потрібних розрізах роботи автоматизованої системи обліку оплати проїзду в міському пасажирському транспорті міста Києва, отримувати дані про утримувачів муніципальної картки «Картка киянина» та АСОПу для подальшого формування аналітичної звітності.
Мета та завдання діяльності: Основна мета діяльності Користувача публічної інформації – бачити загальну статистику роботи автоматизованої системи обліку оплати проїзду в міському пасажирському транспорті міста Києва, муніципальної картки «Картка киянина» та АСОПу.
Мета та завдання діяльності: Адміністратор - посадова особа у складі персоналу, який необхідний для забезпечення адміністрування Системи в межах відповідних підрозділів Замовника. Функціональні обов’язки Адміністратора :
В основу інформаційного забезпечення Сервісу повинен бути покладений принцип однократного введення і єдиного місця збереження інформації та багаторазового її використання для рішення задач Сервісу. Аналізуючи дані, схема інформаційних потоків буде мати наступний вигляд: Рисунок 19.Схема інформаційних потоків в ПС АСОП Забезпечення створення шлюзу обміну даними із ЗІС КП ГІОЦ повинно відбуватиметься шляхом:
Процедури оновлення даних з завданою регулярністю підключатимуться до БД для проміжних даних, перевіряють повноту даних, обробляють, перетворюють та завантажують їх на віртуальну машину – сервери баз даних та додатків ПС АСОП. Звернення користувачів надходитимуть до серверу застосувань та баз даних за отриманням необхідних даних. Візуально модель структури даних в ПС АСОП має наступний вигляд : Рисунок 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 символів) |
<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 наступний:
Для того, щоб увійти до Сервіс, користувач повинен бути зареєстрований Адміністратором сервісу.
Реалізація взаємодії Платформи Big Data та Модуля моніторингу дозволить проводити моніторинг ресурсів сервісу, консолідувати інформації про роботу різних компонентів сервісу і систем (які взаємодіють з ПС АСОП). Процес моніторингу здійснюється відповідно до моделі бізнес-процесу авторизації користувачів. Рисунок 23 Макет бізнес-процесу передачі інформації до модуля моніторингу У межах реалізації електронної взаємодії Сервісів Платформи Big Data та Модуля обліку та моніторингу Платформи KYIVSMARTCITY повинен бути встановлений агент по збору:
Для можливості роботи з Модулем обліку та моніторингу Платформи KYIVSMARTCITY Платформа «Big Data» повинна зареєструватися в якості «клієнта» в Модулі авторизації Платформи KYIVSMARTCITY та отримати від нього такі дані:
Реалізація електронної взаємодії Платформи Big Data та Модуля обліку та моніторингу дозволить використовувати уніфікований інструмент збору логів і метрик для онлайн-аналізу працездатності. У межах електронної взаємодії з Модулем обліку та моніторингу на сервері Платформи Big Data повинен бути встановлений: Агент зі збору логів, який повинен забезпечувати збір логів, що будуть зберігатися у Модулі обліку та моніторингу: Логи доступу ПС АСОП:
Логи інтеграцій:
Логи помилок (див. Таблиця . Базовий набір статусів відповідей):
Агент зі збору метрик, який повинен забезпечувати збір метрик, що будуть зберігатися у Модулі обліку та моніторингу: Завантаженість процесорів:
Завантаженість операційної пам’яті:
Завантаженість фізичних дисків:
Завантаженість мережевих інтерфейсів:
У відповідності до технічних вимог Платформа «великих даних», складається з таких компонентів:
Рисунок 24. Архітектурна схема Платформи великих даних
Джерелами даних в ПС АСОП є:
Обмін даними з цими системами буде реалізований за допомогою постачання файлів через FTP-папку. ETL-процес:
Збереження даних необхідно реалізувати засобами побудови сховища даних, які є складовими платформи Big Data. Сервіс Платформи великих даних - ПС АСОП передбачає створення трирівневої сервісно-орієнтованої клієнт-серверної архітектури у складі наступних рівнів/шарів: Сховище даних - будуватиметься на основі використання сучасних реляційних систем керування базами даних що передбачають шифрування даних і отримання інформації із двох зовнішніх систем:
Рівень представлення не буде мати прямих зв’язків з базою даних (за вимогами безпеки), не буде навантажений основною бізнес-логікою (за вимогами масштабованості) і буде зберігати стан програми (за вимогами надійності). На рівень представлення виноситься найпростіша бізнес-логіка: інтерфейс авторизації, алгоритми шифрування, перевірка значень, що вводяться, на допустимість і відповідність формату, нескладні операції з даними (сортування, групування, підрахунок значень) вже завантаженими на термінал і веб інтерфейс. Для реалізації клієнтської частини використовуватиметься SPA (Single-Page Applications: односторінкове веб-застосування) підхід побудови веб-застосувань. На рівні сховища даних буде використовуватись сучасна реляційна СКБД. Сховище даних буде складатися із наступних основних розділів:
Компоненти серверу застосувань реалізації бізнес-логіки прикладної функціональності призначені для створення серверних служб доступу до об’єктів та бізнес-логіки прикладної функціональності у відповідності до функціональних задач. Компоненти серверу застосувань сервісів загальносистемних засобів призначені для створення серверних служб реалізації загальносистемних функцій засобів ідентифікації та автентифікації користувачів, перевірки прав доступу, аудиту дій, уніфікованих механізмів формування функціональності клієнтських робочих місць тощо. Схема розміщення компонентів ПС АСОП представлена на (Рисунок 25). Рисунок 25. Схема передачі даних між компонентами ПЗ АСОП Автентифікація користувачів досягається шляхом інформаційної взаємодії з Платформою KYIVSMARTCITY, в якій відбувається централізована обробка набору даних і передача в ПС АСОП. Застосовані рішення з використання компонентів Сервісу забезпечуватимуть можливості:
Склад програмних засобів, які будуть використовуватися при побудові сховища даних:
До складу Сервісу, що розробляється, включаються наступні технологічні компоненти:
Трирівнева архітектура будується з 3-х частин (див. Рисунок 26):
Рисунок 26. Трирівнева архітектура
Клієнтський рівень – це інтерфейсний ( графічний) компонент, який представляє перший рівень, власне, застосунок для кінцевого користувача. Перший рівень не має прямого зв’язку із базою даних (за вимогами безпеки), не навантажений основною бізнес-логікою (за вимогами масштабованості) і зберігає стан програми (за вимогами надійності). На перший рівень виноситься найпростіша бізнес-логіка: інтерфейс авторизації, алгоритми шифрування, перевірка значень, що вводяться, на допустимість і відповідність формату, нескладні операції із даними (сортування, групування, підрахунок значень), що вже завантажені на термінал.
Сервер застосунків розташовується на другому рівні. Він складається із наступних взаємопов’язаних компонентів: сервіси загальносистемних засобів та реалізації бізнес-логіки прикладної функціональності та сервіси інформаційної взаємодії з іншими компонентами та інформаційними системами. На другому рівні зосереджена більша частина бізнес-логіки. Поза ним залишаються фрагменти, що експортуються на термінали, а також розміщені в третьому рівні збережені процедури і тригери. Компоненти серверу застосунків сервісів загальносистемних засобів призначені для створення серверних служб реалізації загальносистемних функцій засобів ідентифікації та автентифікації користувачів, перевірки прав доступу, аудиту дій, уніфікованих механізмів формування функціональності клієнтських робочих місць тощо.
Сервер застосунків представляє ASP.NET WebApi додаток, побудований на базі .Net Framework 4.6.1 або вище. Це набір сервісів (веб-методів), які віддають інформацію в JSON форматі на клієнт і забезпечують автентифікацію і авторизацію користувачів. Сервер передбачає наявність адміністративної частини для ручного введення і редагування записів та адміністрування користувачів системи. Для обмеження доступу до сайту по IP реалізується відповідний модуль. Списком дозволених IP-адрес можна буде управляти через панель адміністрування.
Сервер бази даних забезпечує зберігання даних і виноситься на третій рівень. Таким чином, третій рівень являє собою базу даних разом із збереженими процедурами, тригерами і схемою, яка описує застосунок у термінах реляційної моделі.
Сервер БД являє собою у систему управління базами даних:
Microsoft SQL Server Express 2017 використовується для збереження конфігурацій.
MySQL 8.0 використовується як сховище даних двох систем:
Застосовані рішення з побудови програмного Сервісу забезпечуватимуть можливості:
Консолідація даних відбувається шляхом запису їх через сховище ПС АСОП і подальшому записі до OLAP кубу. Рисунок 27. Консолідація даних Процес накопичення інформації складається з наступних етапів:
Відповідно до бізнес-логіки реалізувати відображення динамічних підказок для користувача, що додають більшої інформативності Сервісу для більш зручного та зрозумілого використання її можливостей. Дані підказки допоможуть користувачу зрозуміти які дії від нього потребує Сервіс в процесі користування та у разі неможливості певних дій в зв’язку бізнес-логікою Сервісу пояснити що саме відбувається на сайті і чому ці дії неможливі. Таблиця 10. Підказки, що використовуються в Сервісі
Піктограма | Підказка |
---|---|
Відображатиметься підказка «Головна» | |
Відображатиметься підказка «Назад» | |
Відображатиметься підказка «Вперед» | |
Відображатиметься підказка «Перезавантажити» | |
Вивантаження даних | |
Сповіщення | |
Профіль |
Також деякі з вище перерахованих підказок повинні містити випадаючі списки. Таким чином піктограма «Вивантаження даних» міститиме список:
Піктограма «Профіль» міститиме:
Звідси «Мій профіль» міститиме:
У відповідності до звіту аналізу бізнес процесів ПС АСОП передбачена роль Адміністратора з виконанням наступних функцій:
Для виконання даних функцій необхідно реалізувати web-інтерфейс адміністратора. Функції управління обліковими записами організацій
В інтерфейсі Адміністратора розробити елемент який дозволить керувати структурою організації для обмеження прав для певного користувача.
Рисунок 28.Макет керуючого елементу структури організації
Реалізувати можливість створювати нові організації з можливістю додавати до них користувачів, для надання відповідних прав доступу.
Рисунок 29. Макет створення нової організації
Реалізувати можливість видалення організації з системи, під час видалення повинно відображатися вікно підтвердження видалення організації.
Рисунок 30. Макет видалення організації зі системи
Реалізувати можливість вибору долучення до організації користувача до організації у відповідності до макету вибору організації.
Рисунок 31. Макет долучення користувача до організації
Функції управління обліковими записами користувачів.
В Інтерфейсі Адміністратора розробити модуль який дозволить керувати користувачами ПС АДКП.
Рисунок 32. Макет керуючого елементу управління створення користувача
У ARM Адміністратора передбачається реалізувати можливість керуванням прав
доступу до конструктору у користувачів. Реалізація повинна базуватися на макеті:
Рисунок 33. Макет керування правами доступу користувачів
Реалізувати ведення журналу дій користувачів, з метою відслідковування дій користувачів. Забезпечення ведення автоматичного журналу подій користувачів при роботі з сервісами з можливістю формування статистики щодо використання функцій користувачами за визначені періоди. При веденні журналу подій повинні фіксуватися критичні несправності в роботі сервісів, спроби несанкціонованого або помилкового отримання доступу, інші події на рівні сервісу.
FrontEnd:
BackEnd:
СКБД:
IDE для налаштування та підтримки
Розширення функціональних можливостей ПС «АCОП» вимагає додаткового збільшення обчислювальних потужностей для розгортання MySQL 8.0 необхідний сервер з наступними характеристиками:
Компоненти які базуватимуться на серверах ІТС «Звітність» збільшення обчислюваний потужностей не потребують :
Відповідно до структури рішення, а також враховуючи наявність баз даних та серверів – існуватиме наступне представлення передачі інформації (Рисунок 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.1 | Розробка технічного завдання на створення ПС АСОП | 15 робочих днів з дати отримання письмової заявки від Замовника** | Звіт з аналізу бізнес-процесів. Технічне завдання на створення ПС АСОП. |
1.2 | Розробка програмного забезпечення щодо створення ПС АСОП та документації | 40 робочих днів з дати отримання письмової заявки від Замовника | Дослідний зразок програмного забезпечення ПС АСОП на майданчику Замовника. Програмне забезпечення на цифровому носії із відомістю. Інструкція з розгортання та налаштування ПС АСОП. Інструкція з ведення бази даних. Загальний опис ПС АСОП. Програма та методика попередніх випробувань ПС АСОП. Протокол попередніх випробувань ПС АСОП. Акт приймання в дослідну експлуатацію ПС АСОП. |
1.3 | Дослідна експлуатація програмного забезпечення ПС АСОП та розробка документації | 15 робочих днів з дати отримання письмової заявки від Замовника | Програма та методика дослідної експлуатації ПС АСОП. Керівництво Користувача ПС АСОП. Керівництво Адміністратора ПС АСОП. Протокол дослідної експлуатації ПС АСОП. |
Порядок контролю і приймання Сервісу повинен відповідати етапам, наведеним у таблиці вище.
Виконавець забезпечує гарантійну (технічну) підтримку створеного в результаті надання послуг програмного забезпечення протягом 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]