rest_documentconversion_latest_conversion_thumbnail_32309533_1

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

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

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

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

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

2.1.     Планові терміни початку і закінчення роботи із створення Сервісу. 11 2.2.     Призначення Сервісу. 11 2.3.     Мета і завдання створення ПС АДКП.. 11 2.4.     Задачі та засоби для їх вирішення. 11 2.5.     Вимоги чинного законодавства. 12

1. ВИМОГИ ДО ПОБУДОВИ СЕРВІСУ.. 17

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

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

4.1.     Отримання даних з інформаційно-телекомунікаційної системи «Інформаційно-аналітична звітність для органів влади, громадян та бізнесу» далі ІТС Звітність. 28 4.2.     Отримання відкритих даних з єдиного державного реєстру юридичних осіб, фізичних осіб-підприємців та громадських формувань. 28 4.3.     Формування інформації для керівників структурних підрозділів КМДА про динаміку надання звітності підпорядкованими установами; 28 4.4.     Доступ користувачам до потрібної інформації згідно їх повноважень; 28 4.5.     Інструмент для гнучкого аналізу даних, фільтрації, сортування, групування та підрахунку показників; 28 4.6.     Можливість збереження налаштувань користувача в тому числі створених шаблонів аналітичних довідок в ПС АДКП.. 28 4.7.     Управління правами доступу користувачів Сервісів з розподіленням доступу функцій в межах сервісів. 29 4.8.     Реалізувати ведення журналу дій користувачів. 32

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

5.1.     Концептуальний опис ПС АДКП.. 33 5.2.     Використання OLAP-технологій для оперативного формування аналітичних звітів в потрібних розрізах. 34 5.3.     Архітектура Сервісу. 35 5.4.     Опис інтеграції з Платформою KYIVSMARTCITY у рамках авторизації 42 5.5.     Опис інтеграції з Платформою KYIVSMARTCITY у рамках модулю моніторингу. 43 5.6.     Джерела даних та їх перетворення для сервісу «АДКП». 47 5.7.     Компонент аналітичної вибірки. 64 5.8.     Компонент Особистий профіль. 68 5.9.     Компонент відображення звітних даних. 69 5.10.       Компонент проведення аналітичних розрахунків. 73

1. ПРОГРАМНА ТА АПАРАТНА ІНФРАСТРУКТУРА.. 75

6.1.     Загальний перелік програмного забезпечення. 75 6.2.     Системне та прикладне програмне забезпечення. 75 6.3.     Схема розміщення компонентів на серверному обладнанні 75

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

СПИСОК РИСУНКІВ.. 79 СПИСОК ТАБЛИЦЬ. 80 Регламент оновлення інформації у ПС «АДКП». 82

 

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

• Шифр теми або номер договору:

Договір № 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» для розширеного аналізу діяльності комунальних підприємств та структурних підрозділів КМДА, та для забезпечення оперативності управлінських рішень. Сервіс забезпечуватиме:

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

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

• Конституція України;
• Закону України «Про інформацію»;
• Закону України «Про електронні документи та електронний документообіг»;
• Закону України «Про адміністративні послуги»;
• Закону України «Про доступ до публічної інформації»;
• Закону України «Про захист інформації в інформаційно-телекомунікаційних системах»;
• Закону України «Про захист персональних даних»;
• Постанови Кабінету Міністрів України від 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-р «Про схвалення Концепції розвитку електронного урядування в Україні»;
• НД ТЗІ 1.1-003-99. Термінологія в галузі захисту інформації у комп’ютерних системах від несанкціонованого доступу;
• НД ТЗІ 1.4-001-2000. Типове положення про службу захисту інформації в автоматизованій системі;
• НД ТЗІ 2.5-004-99. Критерії оцінки захищеності інформації у комп’ютерних системах від несанкціонованого доступу;
• НД ТЗІ 2.5-005-99. Класифікація автоматизованих систем і стандартні функціональні профілі захищеності оброблюваної інформації від несанкціонованого доступу (зі Зміною №1, затвердженою наказом

Адміністрації Держспецзв’язку від 15.10.2008 № 172);

• НД ТЗІ 3.6-001-2000. Технічний захист інформації. Комп’ютерні системи. Порядок створення, впровадження, супроводження та модернізації засобів

технічного захисту інформації від несанкціонованого доступу;

• НД ТЗІ 3.7-001-99. Методичні вказівки щодо розробки технічного завдання на створення комплексної системи захисту інформації в автоматизованій системі;
• НД ТЗІ 3.7-003-05. Порядок проведення робіт із створення комплексної системи захисту інформації в інформаційно-телекомунікаційній системі;
• ДСТУ 3396.0-96 «Захист інформації». Технічний захист інформації. Основні положення»;
• ДК 010-98 «Державний класифікатор управлінської документації»;
• ДСТУ 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/IEEE 26515:2018 Інженерія систем і програмних засобів. Розроблення документації користувача в гнучкому середовищі (ISO/IEC/IEEE 26515:2011, IDT); ДСТУ 3396.0-96 Захист інформації. Технічний захист інформації. Основні положення;
• ДСТУ 3396.2-97 Захист інформації. Технічний захист інформації. Терміни та визначення;
• ДСТУ 2873-94 Системи оброблення інформації. Програмування. Терміни та визначення;
• ДСТУ 2941-94 Системи оброблення інформації. Розроблення систем. Терміни та визначення;
• ДСТУ 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);
• ДСТУ 3330-96 (ГОСТ 34.321-96) Інформаційні технології. Система стандартів з баз даних. Еталонна модель керування даними;
• ДСТУ 3008:2015 Інформація та документація. Звіти у сфері науки і техніки. Структура та правила оформлювання;
• ДСТУ 4145-2002 Інформаційні технології. Криптографічний захист інформації. Електронний цифровий підпис, що ґрунтується на еліптичних кривих;
• ГОСТ 34.003-90. Інформаційна технологія. Комплекс стандартів на автоматизовані системи. Автоматизовані системи. Терміни та визначення;
• ГОСТ 34.201-89. Інформаційна технологія. Комплекс стандартів на автоматизовані системи. Види, комплектність і позначення документів при створенні автоматизованих систем;
• ГОСТ 34.601-90. Інформаційна технологія. Комплекс стандартів на автоматизовані системи. Автоматизовані системи. Стадії створення;
• ГОСТ 34.602-89. Інформаційна технологія. Комплекс стандартів на автоматизовані системи. Технічне завдання на створення автоматизованої системи;
• ГОСТ 34.603-92. Інформаційна технологія. Види випробувань автоматизованих систем;
• РД 50-34.698-90. Методичні вказівки. Інформаційна технологія. Комплекс стандартів і керівних документів на автоматизовані системи. Автоматизовані системи. Вимоги до змісту документів;
• РД 50-682-89. Методичні вказівки. Інформаційна технологія. Комплекс стандартів і керівних документів на автоматизовані системи. Загальні положення;
• ДСТУ 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 Інформаційні технології. Криптографічний захист інформації. Цифровий підпис, що ґрунтується на еліптичних кривих. Формування та перевіряння;
• НД ТЗІ 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. Методичні вказівки щодо розробки технічного завдання на створення комплексної системи захисту інформації в автоматизованій системі;
• ДСТУ 3396.0-96 Захист інформації. Технічний захист інформації. Основні положення;
• ДСТУ 3396.1-96 Захист інформації. Технічний захист інформації. Порядок проведення робіт;
• ДСТУ 3396.2-97 Захист інформації. Технічний захист інформації. Терміни та визначення;
• ДСТУ 2226-93 Автоматизовані системи. Терміни та визначення, затверджено наказом Держстандарту України від 09.09.93 № 126;
• Business Process Model and Notation (BPMN), Version 2.0, Object Management Group, 2011;
• Unified Modeling Language (UML), Version 2.5.1, Object Management Group, 2017.

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

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

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

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

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

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

Для забезпечення обчислення значення електронного цифрового підпису від даних буде застосовуватися програмний засіб криптографічного захисту інформації, який вже використовує Сервіс для забезпечення конфіденційності та цілісності даних, що передаються між сервером застосувань та АРМ користувачів, а саме програмний засіб криптографічного захисту інформації – «Крипто Автограф» (експертний висновок № 04/03/01-1258 від 12.04.2017 р.). Розробка та впровадження комплексної системи захисту інформації не є предметом даного договору, її може бути реалізовано в подальшому в межах виконання окремих робіт.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• гаряче резервування, у відповідності до якого дублюючі компоненти знаходяться у режимі «гарячого» резерву. У разі відсутності відклику основного компонента здійснюється перенаправлення трафіку на резервне рішення.

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

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

виконання завдання, яке поставлене перед користувачем;

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

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

• Використовувати кольорову палітру, яка включає відтінки фіолетового, сірого та білого кольорів. Кольори повинні бути контрастними та використовуватися в комбінації з формою та текстом. Колір не повинен бути єдиним візуальним засобом передачі інформації, що вказує на дію або вирізняє елемент серед інших. Не допускається використання схожих та яскравих кольорів. Під час використання світлих відтінків кольорів непрозорість повинна становити 75 та/або 50 відсотків. Веб-сторінки ПС АДКП повинні бути адаптованими для перегляду без прив’язки до кольору.
• Форми введення інформації повинні бути простими та запитувати тільки необхідну інформацію.
• Поля введення інформації повинні бути підписаними, мати короткі, інформативні та однозначні назви, які розташовуються над полем. Поля введення інформації рекомендовано вирівнювати одне під одним, по одному в рядок, ширина поля повинна відповідати вмісту, який вводиться.
• Для вибору точної дати (день, місяць, рік) або проміжку дат необхідно використовувати інтегрований календар.
• Під час введення інформації користувачам необхідно надавати помітні та зрозумілі підписи та/або інструкції.
• У разі підтвердження дії, що призводить до зміни чи припинення прав та/або обов’язків, зміни або стирання користувацьких даних,
• Компоненти веб-сторінок повинні мати зрозумілі назви, навігаційні елементи, які повторюються на багатьох веб-сторінках та однаково розташовуються, а компоненти з однаковою функціональністю – мати однакові назви та однаковий дизайн.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Швидкість буде гарантуватися шляхом побудови оптимальних запитів до бази даних і використанні OLAP технологій, описаний в розділі 5.2 «Використання OLAP-технологій для оперативного формування аналітичних звітів в потрібних розрізах».

      Побудова рішення буде базуватися на використання OLAP-технологій, описаний у розділах 5.4 «Архітектура Сервісу» і 5.2 «Використання OLAP-технологій для оперативного формування аналітичних звітів в потрібних розрізах».

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

Реалізація отримання даних буде відбуватися за рахунок інтеграції. ПС АДКП і ІТС «Звітність». При використанні шаблону звіту, зазначається перелік полів з регламентованої звітності надсилає запит з перерахунком полів до бази даних ІТС «Звітність». При виконанні запиту ІТС «Звітність» надсилає відповідь з наявними даними. У разі відсутності звіту, відсутності частини даних, коли неможливо отримати відповідь на запит у ІТС Звітність, ПС АДКП відображає пусту зведену таблицю.

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

Реалізація вимоги буде побудована за рахунок створення шаблону звітів, звіт з вказанням параметрів «Назва звіту», «Період подання» і «Дата запиту». Створена можливість збереження шаблону звіту для подальшого використання.

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

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

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

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

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

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

Рисунок 1Макет керуючого елементу структури організації Реалізувати можливість створювати нові організації з можливістю додавати до них користувачів, для надання відповідних прав доступу.
Рисунок 2. Макет створення нової організації Реалізувати можливість видалення організації з системи, під час видалення повинно відображатися вікно підтвердження видалення організації.
Рисунок 3. Макет видалення організації зі системи           Реалізувати можливість вибору долучення до організації користувача до організації у відповідності до макету вибору організації. Рисунок 4. Макет долучення користувача до організації Функції управління обліковими записами користувачів. В Інтерфейсі Адміністратора розробити модуль який дозволить керувати користувачами ПС АДКП.
Рисунок 5. Макет керуючого елементу управління створення користувача У ARM Адміністратора передбачається реалізувати можливість керуванням прав доступу до конструктору у користувачів. Реалізація повинна базуватися на макеті: Рисунок 6. Макет керування правами доступу користувачів

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

ПС АДКП – це інтегрований предметно-орієнтований інформаційно-телекомунікаційний сервіс, що будується на основі централізованої програмно-технологічної платформи з уніфікацією програмно-технічних засобів розробки прикладної функціональності з використанням сучасних сервісно-орієнтованих технологій. У межах створення Сервісу використовуватимуться системи: ІТС Звітність та ЄДР з метою аналізу інформації в зручному вигляді на веб-порталі, зменшення часу на пошук та співставлення інформації, зменшення помилок при аналізі, збереження шаблонів типових порівнянь, можливість побудови графіків за вказаними параметрами, можливість фільтрації даних за певними ознаками. Дані з цих систем повинні надходити до сховища даних ПС АДКП, що повинно бути включено в єдине інформаційне середовище (програмну платформу) «Big Data». Основною аудиторією користувачів Сервісу є керівництво і фахівці структурних підрозділів КМДА, державних і комунальних підприємств та організацій, які будуть використовувати Сервіс для забезпечення підтримки прийняття управлінських рішень. При створенні Сервісу будуть використовуватись сучасні загальнопоширені засоби розробки програмних продуктів із дотриманням законодавства з питань правової охорони інтелектуальної власності, зокрема правомірного використання комп’ютерних програм. Сервіс повинен мати вбудовані механізми захисту інформації від несанкціонованого доступу, механізми забезпечення ідентифікації та автентифікації користувачів, механізми збереження цілісності даних, реєстрації дій користувачів, управління доступом користувачів до інформації та окремих функцій. Програмно-технічні засоби, що розробляються, будуть підтримувати приймання-передачу даних за протоколом HTTP over TLS. Фізичний сервер, на якому розміщуються програмні модулі Сервісу, повинен мати постійне підключення до Інтернету за протоколами TCP/IP. Сервіс забезпечуватиме уніфікований для всіх видів автоматизованих робочих місць комфортний, максимально простий та інтуїтивно зрозумілий інтерфейс користувача. Сервіс, що створюється, повинен забезпечити інформаційно-аналітичною звітністю відповідних користувачів в повному обсязі. Рішення щодо побудови програмного Сервісу базуються на:

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

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

При побудові OLAP кубу реалізуватиметься наступна концепція збереження даних:
Рисунок 7.Модель представлення даних з використанням OLAP технології

У відповідності до Технічних вимог, архітектурно Платформа великих даних складається з таких компонентів(див. Рисунок 11):

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

Рисунок 8 Концептуальна структура Платформи великих даних Джерелами даних в ПС АДКП є:

• ІТС “Звітність”. Підключення необхідно зробити через SQL запити до БД Звітність;
• ЄДР. Обмін даними необхідно зробити через структурований файл.

ETL-процес:

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

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

• ІТС «Звітність»;
• Портал «Відкриті дані» отримання даних з Єдиного Реєстру фізичних і юридичних осіб.

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

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

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

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

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

• Microsoft Windows Server 2017;

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

• Сервер БД (Microsoft Windows Server SQL 2017), що являє собою промислову систему управління базами даних як частина ІТС «Звітність»;
• Сервер БД (MySQL 8.0), що являє собою систему безкоштовну систему управляння базами даних, для накопичення та збереження даних з Веб-порталу «Відкритих даних» у відповідності до даних з Порталу «Відкритих даних» у розрізі єдиного державного реєстру юридичних і фізичних осіб.
• Сервер застосувань – продукт, що забезпечує підтримку промислової інфраструктури бізнес-застосувань. Включає в себе низку додатків, що забезпечують:
  • стандартні підходи до організації служб каталогів, централізовані методи організації;
  • розгортання сервісів розробки додаткових застосувань;
  • розгортання сервісів аналізу і звітності.
• Клієнтські місця користувачів, що представляють собою автоматизовані робочі місця у вигляді веб-інтерфейсу в межах тонкого клієнту (Інтернет-оглядачі останніх та передостанніх версій Edge, Google Chrome, Mozilla Firefox та Safari).

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

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

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

• Дані передаються від Портал «Відкриті дані» отримання даних з Єдиного Реєстру фізичних і юридичних осіб до безкоштовної бази даних My SQL;
• Запис даних до OLAP кубу відбувається через сервер бази даних МS SQL, що базується на базі ІТС «Звітність»;
• Збереження конфігурації OLAP кубу відбувається на MS SQL Express (Зберігається технічна інформація);
• Під час запиту Користувач звертається до OLAP кубу для отримання інформації по звітам.

Реалізація взаємодії Платформи Big Data та Модуля авторизації дозволить уніфікувати доступ користувачів до ПС АДКП. Процес авторизації користувача здійснюється відповідно до моделі бізнес-процесу авторизації користувачів (див. Рисунок 8). Рисунок 11. Модель бізнес-процесу авторизації користувачів Користувач обирає відповідну вкладку і натискає на неї. Для подальшого перегляду, відображається інформаційне повідомлення «Для перегляду інформації на сторінці необхідна авторизація через Київ ID» Після натискання на кнопку «Авторизуватись через Kyiv ID» на сторінці Платформи Big Data повинна переадресувати користувача на сторінку входу до «Єдиного облікового запису киянина» (див. Рисунок 9). Рисунок 12. Сторінка «Єдиний обліковий запис киянина» Технічний опис отримання даних від kyiv smart city наступний:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Таблиця 1. Базовий набір статусів відповідей

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

• Процедури оновлення даних з завданою регулярністю підключатимуться до БД для проміжних даних, перевіряють повноту даних, обробляють, перетворюють та завантажують їх на віртуальну машину – сервери баз даних та додатків ПС АДКП.
• Звернення користувачів надходитимуть до серверу застосувань та баз даних за отриманням необхідних даних.

Дані які аналізуються ПС АДКП є основною складовою ІТС «Звітність». Інформаційний обмін з ІТС «Звітність» та Портал «Відкриті дані» отримання даних з Єдиного Реєстру фізичних і юридичних осіб реалізований на основі налаштованих програмних каналів обміну даними через резервний шлюзовий сервер. У відповідності до Технічних вимог, схема інформаційних потоків має наступний вигляд: Рисунок 14. Схема інформаційних потоків Кожне з вище перелічених джерел, повинно надавати дані для формування звітності, що передаються у базу даних ПС АДКП у вигляді аналітичних вибірок (таблиць, що вивантажуються) та на шлюзовий сервер SQL-запитів. Процедури оновлення даних з завданою регулярністю підключатимуться до шлюзового серверу та веб-порталу відкритих даних, перевірятимуть повноту даних, оброблятимуть, перетворюватимуть та завантажуватимуть їх на сервер баз даних (докладніше див. Додаток 1). Дані які містять регламентовані звіти докладніше описані у технічному завдані на розвиток інформаційно-телекомунікаційної системи «Інформаційно-аналітична звітність для органів влади, громадян та бізнесу», 4 черга 40222290.184154.4441.ТЗ у відповідності до Договору № 4441 від 27.08.2018 р. Звіти, що будуть використані ПС АДКП наведені у таблицях 1 - 10:
Таблиця 1. Регламентована звітність в ІТС «Звітність» у розрізі Бюджетна

Таблиця 2. Регламентована звітність в ІТС «Звітність» Госпрозрахункова звітність

Таблиця 3. Регламентована звітність в ІТС «Звітність» у розрізі Імпортованих звітів

 Таблиця 4. Регламентована звітність в ІТС «Звітність» у розрізі звітів про припинення діяльності

Таблиця 5. Регламентована звітність в ІТС «Звітність» у розрізі річної звітності (бюджет)

Дані з ЄДР надходять у базу даних Сервісу з Єдиного державного веб-порталу відкритих даних (далі- Портал) за посиланням https://data.gov.ua/dataset/1c7f3815-3259-45e0-bdf1-64dca07ddc10 , у вигляді текстового файлу формату .XML який містить таблицю, що вивантажується та розархівовується до бази даних ПС «АДКП». Інформація розміщена на Порталі  на підставі Наказу від 28.03.2016 року № 897/5 “Про затвердження Переліку інформації, що підлягає оприлюдненню у формі відкритих даних, розпорядником якої є Міністерство юстиції України”.

При використані шаблону звіту з АРМ Користувача формується запит до ПС АДКП через формування файлу у JSON у відповідності до вказаних даних. Компонент з отриманого файлу JSON формує SQL-запит до бази даних ІТС «Звітність» і подальшої побудови зведеної таблиці по відповідним даним. З ЄДР дані розміщуються на веб-порталі відкритих даних та представлені у вигляді заархівованого текстового файлу формату .XML. Термін передачі запиту і отримання даних від ІТС «Звітність» не повинен перевищувати 3 секунд. Порядок і час оновлення інформації у Додатку 1 «Регламент оновлення інформації у ПС АДКП», бізнес процес отримання даних має наступний вигляд (див Рисунок 15) Рисунок 15. Схема отримання даних зі зовнішніх систем Даний модуль повинен задовольняти вимоги: Поля зі шаблонів регламентованої звітності, розподілити на 5 категорій у представлені користувача а саме:

• Бюджетна звітність (квартал)
• Госпрозрахункова звітність
• Імпортовані звіти
• Припинення
• Річна звітність (бюджет)

Рисунок 16. Макет вибору суб’єкта фінансового аналізу Реалізувати можливість вибору даних з регламентованої звітності яка відображається списком звітів в ПС АДКП у відповідній категорії звітів. А також можливість вибору декількох звітів з обраного списку.
Рисунок 17. Макет вибору регламентованих звітів У користувача ПС АДКП буде можливість вибору періоду подачі регламентованих звітів для подальшого аналізу. Рисунок 18.Макет вибору періоду подачі звітів Реалізувати можливість вибору даних по комунальному підприємстві з ЄДР.
Рисунок 19. Макет вибору даних з ЄДР Передбачити можливість зі шаблонів регламентованої звітності вибирати необхідні поля для подальшого аналізу: Рисунок 20.Макет вибору даних зі звіту Реалізувати можливість вказати ідентифікаційні дані підзвітних підприємств, шляхом зазначення наступних даних:

• Id
• Name
• Subordination
• EDRPOU
• GovernmentId
• GovernmentName
• ActivityId
• ActivityName
• DepId
• DepName
• FinancId
• FinancName
• PropertyId
• PropertyName
• OrgLegalId
• OrgLegalName
• StatusId
• StatusName
• StreetName
• Build
• InsertedCreated
• ReportsId
• ReportsType

Рисунок 21.Ідентифікатори вибору підприємства

Реалізувати можливість в інтерфейсі користувача самостійно:

• Створювати шаблони звітів;
• Редагувати шаблони звітів;
• Копіювати шаблони звітів;
• Видаляти шаблони звітів;
• Здійснювати пошук звіту.

Рисунок 22.Макет вікна опрацювання звіту Передбачається можливість самостійно вказувати назву шаблону через окреме вікно вводу. Рисунок 23. Макет вказання назви шаблону звіту Після збереження шаблону звіту він з’являється у вікні опрацювання звіту. Сортування списку шаблонів звіту здійснюється по назві шаблону.
Користувач може самостійно перейти до Особистого профілю, провести коригування персональних даний і змінити пароль. Рисунок 24. Макет особистого профілю користувача

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

Рисунок 26. Макет формування довільних звітів           У зведеній таблиці повинна реалізована можливість, розгортання або згортання внутрішніх значень, для забезпечення можливості перегляду згрупованих даних при наявності декількох значень у одній ознаці (див Рисунок 27).

Рисунок 27. Макет згортання, розгортання внутрішніх значень звіту           У зведеній таблиці повинна бути реалізована можливість опрацювання фільтрованих даних шляхом вибору даних для найменувань, здійснення пошуку а також сортування значень (див Рисунок 28). Рисунок 28 Макет опрацювання фільтрованих даних Додати можливість фільтрувати значення за допомогою натискання на ім’я ієрархії(див. Рисунок 29).
Рисунок 29. Макет фільтрування ім’я ієрархії           Реалізувати можливість відображати або приховати підсумки та великі підсумки в сітці, для коректного аналізу даних (див. Рисунок 30).
Рисунок 30. Макет відображення підсумків у сітці         Здійснення сортування значень за допомогою елементів керування праворуч від імені кожного члена ієрархії або загальної комірки, шляхом натискання на відовідний стовпчик (див. Рисунок 31).

Рисунок 31. Макет можливості сортування значень         Можливість зміни розміру стовпців та рядків шляхом перетягування меж заголовка(див. Рисунок 32).
Рисунок 32. Макет перетягування меж заголовка           Можливість вибору комірок в сітці, скопіюйте вміст і вставте його безпосередньо, наприклад, в Excel.

          У конструкторі полів створити кнопку “Додати міру” має відобразитись спливаюче вікно для додавання нового значення. Введіть назву поля, якщо потрібно, складіть формулу, натиснувши на операторів та перетягнувши наявні значення до поля “формула”.           Реалізувати чекбокс “Обчислити окремі значення”, щоб обчислити формулу, використовуючи необроблені значення. Створити кнопку ЗАСТОСУВАТИ, для відображення нового значення у списку полів (див. Рисунок 33). Рисунок 33. Макет аналітичного компоненту побудови звіту Даний модуль повинен забезпечити можливість здійснювати певні розрахунки для швидкого аналізу великої кількості даних.

1. ПРОГРАМНА ТА АПАРАТНА ІНФРАСТРУКТУРА

Програмне забезпечення стеку технологій: − FrontEnd:

• HTML 5;
• CSS 3;
• JS 1.8.5.

− BackEnd:

• C# .Net 7.3

− СКБД:

• Microsoft SQL Server 2017 Standart Edition;
• MySQL 8.0

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

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






В рамках ІТС «Звітність» буде використовуватись:

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

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

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

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

Виконавець забезпечує гарантійну (технічну) підтримку створеного в результаті надання послуг програмного забезпечення протягом 12 місяців з дати підписання Акту приймання-передачі наданих послуг за останнім етапом згідно Календарного плану. Під гарантійною підтримкою розуміється зобов’язання Виконавця безоплатно підтримувати розроблене програмне забезпечення, виправляти виявлені помилки.
СПИСОК РИСУНКІВ Рисунок 1Макет керуючого елементу структури організації 29 Рисунок 2. Макет створення нової організації 30 Рисунок 3. Макет видалення організації зі системи. 30 Рисунок 4. Макет долучення користувача до організації 31 Рисунок 5. Макет керуючого елементу управління створення користувача. 31 Рисунок 6. Макет керування правами доступу користувачів. 32 Рисунок 7.Модель представлення даних з використанням OLAP технології 35 Рисунок 8 Концептуальна структура Платформи великих даних. 36 Рисунок 9. Трирівнева архітектура. 39 Рисунок 10. Схема архітектури пропонованого рішення. 41 Рисунок 11. Модель бізнес-процесу авторизації користувачів. 42 Рисунок 12. Сторінка «Єдиний обліковий запис киянина». 43 Рисунок 13 Макет бізнес-процесу передачі інформації до модуля моніторингу. 44 Рисунок 14. Схема інформаційних потоків. 47 Рисунок 15. Схема отримання даних зі зовнішніх систем. 64 Рисунок 16. Макет вибору суб’єкта фінансового аналізу. 65 Рисунок 17. Макет вибору регламентованих звітів. 65 Рисунок 18.Макет вибору періоду подачі звітів. 66 Рисунок 19. Макет вибору даних з ЄДР. 66 Рисунок 20.Макет вибору даних зі звіту. 67 Рисунок 21.Ідентифікатори вибору підприємства. 68 Рисунок 22.Макет вікна опрацювання звіту. 68 Рисунок 23. Макет вказання назви шаблону звіту. 69 Рисунок 24. Макет особистого профілю користувача. 69 Рисунок 25. Макет відображення даних у вигляді зведеної таблиці 70 Рисунок 26. Макет формування довільних звітів. 70 Рисунок 27. Макет згортання, розгортання внутрішніх значень звіту. 71 Рисунок 28 Макет опрацювання фільтрованих даних. 71 Рисунок 29. Макет фільтрування ім’я ієрархії 72 Рисунок 30. Макет відображення підсумків у сітці 72 Рисунок 31. Макет можливості сортування значень. 73 Рисунок 32. Макет перетягування меж заголовка. 73 Рисунок 33. Макет аналітичного компоненту побудови звіту. 74 Рисунок 34. Схема розміщення компонентів на серверному обладнані 76

Таблиця 1. Регламентована звітність в ІТС «Звітність» у розрізі Бюджетна……………39 Таблиця 2. Підказки, що використовуються в Сервісі……………………………………59

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

Додаток 1

Регламент оновлення інформації у ПС «АДКП» Процедури оновлення даних повинні відбуватись в онлайн режимі з оновленням щогодини. За допомогою інтеграції баз даних ПС «АДКП» підключається до шлюзового серверу, перевіряє повноту даних, оброблює, перетворює та завантажує дані на сервер баз даних. Оновлення даних щодо завантажених полів з ІТС «Звітність» в базу даних ПС «АДКП» відбувається з періодичністю кожну годину. SQL-запити в базу даних Oracle (10.14.12.9:1521/DBKMDA) використовують наступні таблиці:

• FORMFLD
• ORG
• CARD
• CARDSTATUS
• CARDVAL
• CARDVAL_VALS
• FORM
• HBACTIVITY
• HBFINANC
• HBMPBRANCH
• HBMPDEP
• HBORGLEGAL
• HBORGSTATUS
• HBPROPERTY
• ORGADR
• ORGADRTEL
• ORGINFO

Дані з цих таблиць обробляються та перетворюються у необхідний формат для відображення в ПС «АДКП». З ЄДР дані розміщуються на веб-порталі відкритих даних та представлені у вигляді заархівованого текстового файлу формату .XML. Оновлюються шляхом завантаження заархівованого файлу з порталу відкритих даних, на локальний сервер ПС «АДКП»,  його розархівування та імпорту до бази даних ПС «АДКП» регулярно з періодичністю щотижня. Отримання даних здійснюється щосереди в 00:01:00.
все ж таки треба запустити сервер застосунків та сервер Бази даних. [ГС1] Я б сюди їх включив би
Перевірте з Ярославом коректність даного тексту