Зміст

(Б-8) Інформаційно-аналітична звітність для органів влади, громадян та бізнесу : Технічне завдання 4 черга 2018

{{download/resources/com.atlassian.confluence.plugins.confluence-view-file-macro:view-file-macro-resources/images/placeholder-medium-doc.png?0x250}}Технічне_завдання_Звітність_4_черга.docx

ЗАТВЕРДЖУЮ

КП «Головний інформаційно-обчислювальний центр»
ЗАТВЕРДЖУЮ

ТОВ «Аргун Компані»

 
Директор Директор
__________________  В. М. Козубський _________________  С. В. Боднарчук
 

«_____»  _______________  2018 р.

 
 

«_____»  ________________  2018 р.

Створення інформаційно-телекомунікаційної системи “Інформаційно-аналітична звітність для органів влади, громадян та бізнесу” Шифр: ІТС “Звітність” ТЕХНІЧНЕ ЗАВДАННЯ на розвиток інформаційно-телекомунікаційної системи “Інформаційно-аналітична звітність для органів влади, громадян та бізнесу”, 4 черга 40222290.184154.4441.ТЗ На _____ аркушах діє з «_____» _______________ 2018 року  

Від Замовника:
 Від Виконавця:


Начальник департаменту

впровадження та супроводу

інформаційно-комунікаційних систем

 

Керівник проекту

 
________________О. П. Перевозник




В. о. начальника департаменту

впровадження та технологічного

супроводження обліково-фінансових систем

________________ О. В. Кузьмінова


 

________________А. П. Гусаревич

Провідний інженер відділу впровадження та

розвитку інформаційно-комунікаційних систем

 

________________Т. В. Бортник

 

 

Київ 2018
ЗМІСТ



 
                                                 Стор.

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

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

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

3.1      Загальні вимоги. 16 3.2      Архітектура Системи. 17 3.3      Загальний опис рішення Системи. 23 3.3.1       Розширення підсистеми збереження даних. 25 3.3.2       Розширення підсистеми вітрин даних. 26 3.4      Вимоги до Системи збору та обробки статистичної звітності 28

4.1      Вимоги до комплексу засобів захисту інформації 30 4.2      Вимоги до інформаційної безпеки. 33 4.3      Вимоги до режимів функціонування Системи. 34 4.4      Вимоги до діагностування Системи. 34 4.5      Перспективи розвитку, модернізації Системи. 34 4.6      Вимоги до чисельності та кваліфікації персоналу Системи та режиму його роботи. 35 4.7      Показники призначення. 36 4.8      Вимоги до надійності 36 4.9      Вимоги до ергономіки. 37 4.10    Вимоги до патентної чистоти. 37 4.11    Вимоги до стандартизації та уніфікації 37




                                                 Стор.

4.12    Вимоги до видів забезпечення. 38 4.12.1    Загальні вимоги до Системи. 38 4.12.2    Вимоги до інформаційного забезпечення. 38 4.12.3    Вимоги до лінгвістичного забезпечення. 39 4.12.4    Вимоги до програмного забезпечення. 40 4.12.5    Вимоги до технічного забезпечення. 41 4.12.6    Вимоги до організаційного забезпечення. 42 4.12.7    Вимоги до методичного забезпечення. 42 4.13    Склад та зміст послуг зі створення Системи. 42 4.14    Вимоги до технологічної документації та методичного забезпечення. 46

5.1      Загальні вимоги. 48 5.2      Джерела даних та їх перетворення. 49 5.2.1       Джерела даних для програмного компоненту «Комунальні підприємства». 50 5.2.2       Джерела даних для програмного компоненту «Соціальна політика». 56 5.2.3       Джерела даних для програмного компоненту «Запис до лікаря»  58 5.2.4       Джерела даних для програмного компоненту «Швидка допомога». 59 5.2.5       Джерела даних для програмного компоненту «АТП-5». 60 5.2.6       Перелік звітів за компонентами. 61 5.3      Вимоги до функціонального складу компонентів. 64 5.3.1       Програмний компонент «Комунальні підприємства». 64 5.3.2       Інформаційна панель для ролі «Київський міський голова»  81 5.3.3       Інформаційно-аналітична панель «Освіта». 87 5.3.4       Інформаційно-аналітична панель «Медицина». 103 5.3.5       Інформаційно-аналітична панель «Національна поліція». 117 5.3.6       Інформаційно-аналітична панель «Транспорт. Автотранспортне підприємство 5». 121 5.3.7       Програмний компонент «Звіт для аудиту». 125 5.3.8       Програмний компонент «Соціальна політика». 129 5.3.9       Розробка та впровадження нових компонентів аналізу, групування, відображення та збереження даних. 131 5.3.10    Вимоги до розробки мобільних додатків для роботи з Системою на планшетних пристроях під управлінням операційних систем Android та IOS……... 141

|


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

СПИСОК ТАБЛИЦЬ. 155 СПИСОК РИСУНКІВ.. 156 ЛИСТ РЕЄСТРАЦІЇ ЗМІН.. 158  

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

№ з/п Скорочення Розшифрування
1.              АСОТР Автоматизована система обліку транспортної роботи.
2.              АРМ Автоматизоване робоче місце.
3.              АТП -5 Автотранспортне підприємство №5.
4.              База даних

(умовне скорочення БД)
Сукупність даних, числових та не числових значень, показників, що зберігаються у системі.
5.              БП Бізнес-процес.
6.              Візуалізація Графічне представлення.
7.              Вітрина даних

(англ. Data Mart)
Зріз сховища даних, що представляє собою масив тематичної, вузьконаправленої інформації, орієнтований, наприклад, на користувачів однієї робочої групи або департаменту.
8.              ГВП Гаряче водопостачання.
9.              ГПД Група продовженого дня.
10.            ЗДО Заклад дошкільної освіти.
11.            ЗНЗ Загальний навчальний заклад.
12.            ЗНО Зовнішнє незалежне оцінювання.
13.            ЗОШ Загальноосвітня школа.
14.            ЕОМ Електронно-обчислювальна машина.
15.            ЕЦП Вид електронного підпису, отриманого за результатом криптографічного перетворення набору електронних даних, який додається до цього набору або логічно з ним поєднується і дає змогу підтвердити його цілісність та ідентифікувати підписувача.
16.            ЖЕД Житлово-експлуатаційна дільниця.
17.            ЖКГ Житлово-комунальне господарство.
18.            КМДА Київська міська державна адміністрація
19.            Користувач Суб'єкт, що звертається до Системи, щоб користуватися нею.
20.            Моніторинг Процес систематичного або безперервного збору інформації про параметри складного об'єкту або процесу.
21.            НДІ Нормативно-довідкова інформація.
22.            ОС Операційна система.
23.            ПЗ Програмне забезпечення.
24.            Політики організації Конкретні принципи, основи, угоди, правила, положення, інструкції і практики, вживані організацією в управлінні і регулюванні суб'єктів господарювання.
25.            РДА Районна Держадміністрація.
26.            Реляційна база даних Це засіб для раціонального і ефективного зберігання інформації. Як правило, в ній реалізовані засоби захисту даних від випадкової втрати/псування, економного використання ресурсів, швидкого пошуку інформації.
27.            РО Рухомі об’єкти.
28.            Система Інформаційно-телекомунікаційна система «Інформаційно-аналітична звітність для органів влади, громадян та бізнесу», 4 черга.
29.            СКБД Система керування базами даних.
30.            Сховище даних

(англ. Data warehouse)
Наочно-орієнтована інформаційна корпоративна база даних, розроблена і призначена для підготовки звітів, аналізу ділових процесів з метою підтримки ухвалення рішень в організації.
31.            ХВП Холодне водопостачання.
32.            ЦО Центральне опалення.
33.            Android Операційна система і платформа для мобільних телефонів та планшетних комп'ютерів, створена компанією Google на базі ядра Linux.
34.            CSS Спеціальна мова, що використовується для опису зовнішнього вигляду сторінок, написаних мовами розмітки даних.
35.            GIT Розподілена система керування версіями файлів та спільної роботи.
36.            Helsi Електронна медична система, створена для пацієнтів, лікарів, державних та приватних медичних закладів.
37.            HTML  Стандартна мова розмітки веб-сторінок в Інтернеті.
38.            HTTPs Складова схеми URI, яка вказує, що має використовуватися протокол HTTP, але з іншим портом за замовчуванням (443) і додатковим шаром шифрування/автентифікації (ssl/tls) між HTTP і TCP.
39.            iOS Мобільна операційна система від Apple.
40.            JavaScript Динамічна, об'єктно-орієнтована прототипна мова програмування.
41.            PDF Portable Document Format – відкритий формат файлу для представлення двовимірних документів у незалежному від пристрою виведення та роздільної здатності вигляді.
42.            PEDI Опитувальник оцінки дитячої інвалідності.
43.            REST Підхід до архітектури мережевих протоколів, які забезпечують доступ до інформаційних ресурсів.
44.            SFTP Протокол прикладного рівня, призначений для копіювання та виконання інших операцій з файлами поверх надійного і безпечного з'єднання.
45.            SPA Single Page Application – це веб-додаток, розміщений на одній веб-сторінці, який для забезпечення роботи завантажує весь необхідний код разом із завантаженням самої сторінки.
46.            SQL (Structured Query Language) Діалогова мова програмування (мова структурованих запитів) для маніпулювання даними і внесення змін до бази даних, а також управління базами даних.
47.            TCP/IP Набір протоколів мережі Інтернет
48.            SOAP Simple Object Access Protocol – протокол обміну структурованими повідомленнями в розподілених обчислювальних системах, базується на форматі XML.
49.            URL Уніфікований локатор ресурсів - стандартизована адреса певного ресурсу.


 

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

1.1       Найменування системи та її умовне позначення

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

  Вимоги до побудови наступних черг визначаються додатково.

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

Договір № 4441 від 27.08.2018 р.

1.3       Найменування організацій Замовника і Розробника, їх реквізити

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


Розробник: Товариство з обмеженою відповідальністю «Аргун Компані». Місцезнаходження: вул. Червоноткацька, буд. 87, офіс 15, м. Київ, 02660, Україна. ЄДРПОУ 40222290, п/р 26003052638358 в АТ КБ «ПРИВАТБАНК», Код банку 300711, ІПН 402222926526.

1.4       Підстави для розробки (перелік документів, на підставі яких створюється проект, ким і коли затверджені ці документи)

Розробка виконується згідно договору № 4441 від 27.08.2018 р. Результат проведення закупівлі: код за ДК 021:2015: 72210000-0 Послуги з розробки пакетів програмного забезпечення (Розвиток інформаційно-телекомунікаційної системи «Інформаційно-аналітична звітність для органів влади, громади та бізнесу», 4 черга).

1.5 Планові терміни початку і закінчення роботи із створення Системи

Початок робіт: 27.08.2048 р. Закінчення робіт: 26.12.2018 р.

1.6 Порядок передачі замовнику результатів робіт по розробці Системи

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

2.           ПРИЗНАЧЕННЯ ТА МЕТА СИСТЕМИ

2.1       Призначення даної Системи

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

 

2.2       Мета і завдання створення Системи

У результаті виконання робіт з розвитку інформаційно-телекомунікаційної системи «Інформаційно-аналітична звітність для органів влади, громадян та бізнесу» буде впроваджено в експлуатацію четверту чергу системи ІТС «Звітність» у вигляді модулів:

  Метою виконання робіт по розробці четвертої черги ІТС «Звітність» є створення:


            Впровадження четвертої черги ІТС «Звітність» дозволить якісно покращити управління шляхом надання оперативних даних з динаміки змін основних показників діяльності департаментів комунальної власності, освіти і науки, охорони здоров’я, внутрішнього фінансового контролю та аудиту, соціальної політики, а також управлінь національної поліції міста Києва.

2.3        Задачі та засоби для їх вирішення

Послуги, що направлені на розробку четвертої черги ІТС «Звітність», передбачають розв’язання наступних задач:


Модулі системи, що створюються, будуються за наступними принципами:

2.4        Вимоги чинного законодавства

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

Даний перелік не є вичерпним та може бути уточнений в процесі розробки Системи.
 

3.            ВИМОГИ ДО СИСТЕМИ

3.1       Загальні вимоги

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

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

3.2       Архітектура Системи

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

Також передбачається реалізація засобів інформаційної взаємодії з інформаційними системами, в яких відбувається первинне накопичення та актуалізація певного набору даних. Загальна схема логіки побудови Системи наведена на Рис. 1. Рис. 1. Верхньорівнева загальна схема логіки побудови Системи Четверта черга створюється з урахуванням програмної платформи ІТС «Звітність» та буде реалізовуватись на основі трирівневої сервісно-орієнтованої клієнт-серверної архітектури у складі наступних рівнів/слоїв:

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

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

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


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


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

3.3       Загальний опис рішення Системи

У межах реалізації ІТС «Звітність» створюється програмно-технологічний комплекс (програмна платформа ІТС «Звітність»), яка функціонально збудована як єдине інформаційне середовище, в якому функціонально та інформаційно взаємодіють інформаційні системи та/або комплекси. ІТС «Звітність» будується почергово, за модульним принципом. Четверта черга ІТС «Звітність» розширює можливості Системи та призначена для консолідації інформації та процесів з розрізнених інформаційних систем: компонентів «Інтелектуальний центр реабілітації» та «Матеріальна допомога» Програмного модулю «Соціальні послуги», Модулю «Фінансова звітність» ІТС “Звітність”, Електронної медичної системи Helsi, Інформаційно-аналітичної системи «Єдиний медичний простір», Автоматизованої системи обліку транспортної роботи (АСОТР), для представлення їх в наглядному вигляді для керівників та співробітників департаментів КМДА. Кінцеве рішення четвертої черги ІТС «Звітність» є інструментом моніторингу показників роботи департаментів КМДА та підпорядкованих установ. Загальна схема розширення Системи в рамках четвертої черги представлена на Рис. 3. У межах четвертої черги з’являються нові джерела даних, для яких будуть сформовані та налаштовані нові модулі, а саме: - модулі прийому та обробки даних; - модулі підготовки звітів; - модулі обробки звітів; - програмні інтерфейси для внесення даних та відображення даних.   Рис. 3. Загальна схема розширення Системи у межах четвертої черги

3.3.1      Розширення підсистеми збереження даних

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

Також буде розроблено два мобільні додатки для роботи з ІТС “Звітність” на планшетних пристроях під управлінням операційних систем iOS та Android. Схема розширення підсистеми збереження даних наведена на Рис. 4.   Рис. 4. Розширення підсистеми збереження даних

3.3.2      Розширення підсистеми вітрин даних

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

3.4       Вимоги до Системи збору та обробки статистичної звітності

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

Модуль, що розробляється, задовольнятиме наступним вимогам:

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

4.            УЗАГАЛЬНЕНІ ВИМОГИ ДО СИСТЕМИ

4.1        Вимоги до комплексу засобів захисту інформації

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

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

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

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

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

4.2        Вимоги до інформаційної безпеки

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

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

4.3        Вимоги до режимів функціонування Системи

Система буде підтримувати наступні режими функціонування:

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

4.4        Вимоги до діагностування Системи

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

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

4.5       Перспективи розвитку, модернізації Системи

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

4.6       Вимоги до чисельності та кваліфікації персоналу Системи та режиму його роботи

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

Рішення щодо чисельності та кваліфікації персоналу Системи, запропоновані Виконавцем під час розробки Системи, будуть обґрунтовані необхідними вимогами до її обслуговування та мінімізуються за витратами при впровадженні Системи. При цьому чисельність задіяного для обслуговування Системи персоналу не повинна перевищувати наявну чисельність персоналу, який задіяний у поточних автоматизованих процесах. Технічне обслуговування Системи передбачає роботу персоналу на договірних умовах аутсорсингу. Рішення щодо вибору типу експлуатації на умовах аутсорсингу або штатною чисельністю персоналу буде економічно обґрунтовано та забезпечить мінімальні витрати ресурсів під час експлуатації Системи. Впровадження четвертої черги ІТС «Звітність» не передбачає додаткового збільшення чисельності персоналу для обслуговування Системи. Система повинна забезпечувати одночасну роботу до 1200 користувачів. Персонал, що виконує функції супроводу та обслуговування (адміністратори) Системи повинен працювати в режимі основного робочого графіку відповідних підрозділів, а персонал, який забезпечує технічну підтримку Системи – в режимі 24/7. Персонал, який експлуатує (користувачі) Систему, повинен працювати в режимі основного робочого графіку відповідних підрозділів (передбачається ненормований робочий день). Технічна підтримка програмного забезпечення Системи може здійснюватися спеціалізованими організаціями, підприємствами чи установами на основі окремих договорів.

4.7       Показники призначення

Система забезпечуватиме:

4.8       Вимоги до надійності

Надійність системи буде забезпечена за наступними напрямками:

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

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

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

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

4.9       Вимоги до ергономіки

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

4.10   Вимоги до патентної чистоти

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

4.11   Вимоги до стандартизації та уніфікації

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

4.12   Вимоги до видів забезпечення

4.12.1  Загальні вимоги до Системи

4.12.2  Вимоги до інформаційного забезпечення

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

Інформаційне забезпечення буде відповідати основним вимогам:

Інформаційне забезпечення Системи буде включати:

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

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

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

4.12.3  Вимоги до лінгвістичного забезпечення

Лінгвістичне забезпечення Системи буде включати сучасні мовні засоби програмування для розробки програмного забезпечення та інтерфейсу користувача. Мовні засоби програмування будуть обрані Виконавцем відповідно до рішень з програмного забезпечення Системи на етапі розробки технічного завдання (наведено в  п. 6). Інтерфейс користувача буде розроблений українською мовою та забезпечуватиме:

4.12.4  Вимоги до програмного забезпечення

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

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

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

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

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

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

4.12.5  Вимоги до технічного забезпечення

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

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

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

4.12.6  Вимоги до організаційного забезпечення

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

4.12.7  Вимоги до методичного забезпечення

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

4.13   Склад та зміст послуг зі створення Системи

Створення ІТС «Звітність» четвертої черги передбачає створення та впровадження нових компонентів звітності, а саме:

  1. Програмний компонент «Комунальні підприємства»:
  1. Програмний компонент «Соціальна політика»:
  1. Інформаційні панелі департаментів КМДА:
    • Інформаційна панель для ролі «Київський міський голова»;
    • «Освіта. ЗДО»;
    • «Медицина. Helsi»;
    • «Медицина. Швидка допомога Онлайн»;
    • «Медицина. Швидка допомога Динаміка»;
    • «Національна поліція. Кримінал»;
    • «Транспорт. АТП-5»;
    • «Звіт для Аудиту».
  2. Нові компоненти аналізу, групування, відображення та збереження даних: зведена таблиця, підсистема динамічного аналізу даних, фільтрація даних, підсистема підказок та інформувань, підсистема автоматичної розсилки звітів на електронну пошту, конструктор звітів, експорт даних в форматі PDF, експорт даних в форматі MS XLSX.
  3. Мобільні додатки для роботи з Системою на планшетних пристроях під управлінням операційних систем iOS та Android (п. 3.10).

Перелік послуг з розвитку ІТС «Звітність» четвертої черги включає:

  1. Попередні випробування. Склад, обсяг і методи попередніх випробувань Системи визначаються документом «Програма та методика попередніх випробувань» та розробляються на етапі створення робочої документації.
  2. Дослідна експлуатація. Склад, обсяг і методи дослідної експлуатації Системи визначаються документом «Програма та методика дослідної експлуатації» та розробляються на етапі впровадження Системи в експлуатацію.

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

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

Проведення попередніх випробувань включає:

Після проведення всіх етапів випробувань Виконавець надає оновлену у відповідності з результатами проведення випробувань та рекомендаціями щодо вдосконалення наступну документацію:

У складі послуг з розробки ІТС «Звітність» четвертої черги передбачено наступне:

При цьому загальний час проведення профілактичних робіт не повинний перевищувати 3% від загального часу роботи системи в основному режимі функціонування. Буде передбачена можливість ведення в електронній формі журналів інцидентів, а також графіків і журналів проведення профілактичних робіт. Для всіх технічних компонентів буде забезпечений регулярний і постійний контроль стану Системи і технічне обслуговування без зупинки її функціонування. Технічне обслуговування Системи забезпечуватиме:

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

4.14   Вимоги до технологічної документації та методичного забезпечення

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

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


 

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

5.1       Загальні вимоги

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

  1. Програмний компонент «Комунальні підприємства»:
  1. Програмний компонент «Соціальні послуги»:


  1. Інформаційні панелі департаментів КМДА:
  1. Нові компоненти аналізу, групування, відображення та збереження даних: зведена таблиця, підсистема динамічного аналізу даних, фільтрація даних, підсистема підказок та інформувань, підсистема автоматичної розсилки звітів на електронну пошту, конструктор звітів, експорт даних в форматі PDF, експорт даних в форматі MS XLSX.
  2. Мобільні додатки для роботи з Системою на планшетних пристроях під управлінням операційних систем iOS та Android (п. 3.10).

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

5.2       Джерела даних та їх перетворення

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

Інформаційний обмін з суміжними системами буде реалізований на основі налаштованих програмних каналів обміну даними через резервний шлюзовий сервер (Рис. 79). Шлюз інформаційного обміну передбачатиме:

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

5.2.1      Джерела даних для програмного компоненту «Комунальні підприємства»

Звіти для програмного компоненту «Комунальні підприємства» формуються на основі даних ІТС «Звітність».           Дані для програмного компоненту «Комунальні підприємства» надходять у Систему у вигляді аналітичних вибірок даних (таблиць, що вивантажуються).
Таблиця 1. Структура даних довідника «Реєстр підприємств»

з/пНазва елементу Назва поля Тип/формат
1 Код стрічки CODE 1234
2 Код довідника IDSPR 1234
3 Назва підприємства FIRM Назва (текст)
4 ЄДРПОУ пiдприємства EDRPOU 12345678
5 Коротке найменування підприємства SHORTNAME Назва (текст)
6 Найменування підприємства NAME Назва (текст)
7 Коротке найменування підприємства англійською SHORTLAT Назва (текст)
8 Тип платника JUR Юр./Фіз.
9 Логічне видалення DELETED Число
10 Дата реєстрації REGTAX дд.мм.рррр гг:хх
11 Номер реєстрації в ДПI REGTAXNUM 123456
12 Номер платника ПДВ INDTAXNUM Номер (число)
13 Номер свiдоцтва платника ПДВ CODENDS Номер (число)
14 Код ДПI TAXINSPNUM Код (число)
15 Стара податкова інспекція OLDTAXINSP Назва (текст)
16 Орган держ. реєстрацiї GOVREG Назва (текст)
17 Дата держ. реєстрацiї GOVREG дд.мм.рррр гг:хх
18 Номер держ. реєстрацiї GOVREGNUM Номер (число)
19 Форма власності PROPERTY Форма (текст)
20 Дата закриття установи CLOSEDDATE дд.мм.рррр гг:хх
21 Організаційно-правова форма ORGLEGAL Форма (текст)
22 Основний вид діяльності ACTIVITY Вид (текст)
23 Код підзвітної установи SUBORD Код (число)
24 Фінансування FINANC Тип (текст)
25 Орган управління ADMIN Назва (текст)
26 Статутний фонд STATFUND Число
27 Номер реєстрацiї в пенсійному фондi INSURNUM Номер (число)
28 Номер реєстрації у фонді соц. страхування INSURFNDNUM Номер (число)
29 Код територіального органу ДКЦПФР ISSUES Код (число)
30 Орган реєстр. використання води WATER Назва (число)
31 Номер реєстрації у фонді зайнятості UNEMPNUM Номер (число)
32 Код території (КОАТУУ), зв’язок з довідником «Коди КОАТУУ» (таблиця HBKOATUU) KOATUU Код (число)
33 IПН директора LEADINDTAX 12345678910
34 ПIБ директора LEADFIO ПІБ
35 Робочий телефон директора LEADTELW Число (10 символів)
36 Домашній телефон директора LEADTELH Число (10 символів)
37 Додаткові телефон директора LEADTELADD Число (10 символів)
38 IПН бухгалтера CHIEFACCINDTAX 12345678910
39 ПIБ бухгалтера CHIEFACCFIO ПІБ
40 Робочій телефон бухгалтера CHIEFACCTELW Число (10 символів)
41 Домашній телефон бухгалтера CHIEFACCTELH Число (10 символів)
42 Додаткові телефон. бухгалтера CHIEFACCTELADD Число (10 символів)
43 Номер реєстрації у фонді страхування вiд нещасних випадків INSURFNDACCNUM Номер (число)
44 Ключ KEY Ключ (число)
45 Дата початку рознесення звітності DATEBEG дд.мм.рррр гг:хх
46 Дата закриття підприємства CLOSEDDATE дд.мм.рррр гг:хх
47 Код ОКОНХ OKONX Код (число)
48 Ознака неприбуткового підприємства NOTPR Число
49 Ознака платник “фiз. особа підприємець” PLATPHISPRED Число
50 Ознака платник “фiз. особа сумісник” PLATPHISSOVM Число
51 Ознака платник СП PLATSP Число
52 Ознака платник с\г 1 PLATSG1 Число
53 Ознака платник с\г 2 PLATSG2 Число
54 Ознака неплатник ПДВ NOTPLATNDS Число
55 Ознака платник ПДВ(мiс) MONTHNDS Число
56 Ознака платник ПДВ(кв) KVARTNDS Число
57 Ознака платник “м’ясо-молоко” PLATMM Число
58 Ознака платник “технопарк” PLATT Число
59 Ознака платник єдиного податку PLATEN Число
60 Довільна ознака 1 DEFREKV1 Число
61 Довiльна ознака 2 DEFREKV2 Число
62 Папка (група) установ, до якої відноситься організація. Посилання на таблицю ABFOLDERSIDFOLDER Число
63 Дата оновлення даних по платнику ДатаUPДата дд.мм.рррр гг:хх
64 Дата оновлення даних з АИС РПП ДатаAISRPP дд.мм.рррр гг:хх
65 Код iнспектора по пiдприємству TAXER Код (число)
66 Коментар по платнику NOTES Коментар (текст)
67 Регіон REGION Назва (текст)
68 Номер однотипного документа NUM Номер (число)
69 Код відомчої класифікації KVK Код (число)
70 ДКУД DKUD Текст
71 Найменування посади керівника LEADPOS Найменування (текст)
72 Найменування посади бухгалтера CHIEFACCPOS Найменування (текст)
73 Основний вид діяльності за КВЕД KVED Код (число)
74 Індивідуальний номер IND_N Номер (число)
75 Ознака для каз. підприємств KAZ Текст
76 Відомчий вид діяльності NAUKA Вид (текст)
77 Наказ PRIKAZ Номер (число)
78 Код підтвердження PROW Код (число)
79 Код у реєстрі REG Код (число)
80 Зовнішній номер по міністерству REGN Номер (число)
81 Ознака таємності SECR Текст
82 Державна частка більше 50% SOB1 Текст
83 Ознака стратегічності STRAT Текст
84 Управління UPR Текст
85 Галузь (1-й рівень) MPDEP Текст
86 Підгалузь (2-й рівень) MPDIR Текст
87 Департамент (3-й рівень) MPBRANCH Текст
88 Орган Державного казначейства DKU Текст
89 Статус установи ORGSTATUS Текст
90 Категорія звітності установи ZVITCATEGORY Текст
91 Повна адреса установи FULLADDRES Число
92 Код KMPLCODE Код (число)
93 Філія організації DEPT Текст
94 Тип KNTYPE Число (2,0)
95 Статус STATUTE Текст
96 Дата реєстрації статусу REGДатаSTATUTE дд.мм.рррр гг:хх
97 Код статусу назви файлу FILENAMESTATUTEЧисло
98 Ступінь розпорядника SRK Текст
99 Орган управління в МінФіні FREE Число
100 Код бюджету BUDGETNUM Код (число)
101 Категорія платника CATPLATNUM Число
102 Код пенсійного фонду PFUNUM Код (число)
103 Кількість пiдприємств ENTQTY Код (число)
104 Код розпорядника коштів KRK Код (число)
105 Код відповідального виконавця KVV Код (число)
106 Код головної організації. Для дерева організацій. IDPARENT Код (число)
107 Код філії пенсійного фонду PFUDEPT Код (число)
108 Код установи по Мережі KPOL Код (число)
109 Код системи оподаткування OSONUM Код (число)
110 Код центру зайнятості DCZNUM Код (число)
111 Наявність пільг у страхувальника PFUPILG Число
112 Код ФСС НВВ FSSNUM Код (число)
113 Клас проф. ризику виробництва PROF_RISK Число
114 Тип організації TYPE_PFU Число
115 Код типової відомчої класифікації для місцевих бюджетів KTVK Код (число)
116 Визначає головну організацію. IMPMAIN Текст
117 Встановлює комплектність бланків, які можна імпортувати IMPFILTERKMPL Число
118 Код дирекції FSENUM Код (число)
119 Код фінансової установи BANKFINID Код (число)
120 Тип фінансової установи BANKFINTYPE Код (число)
121 Код користувача, який створив документ CRTUSER Код (число)


Таблиця 2. Структура даних довідника форм власності (HBPROPERTY)

Назва елементу Назва поляТип/формат
Унікальний ідентифікатор CODE Ідентифікатор (число)
Символьний код NUM Код (число)
Найменування форми власностіNAME Найменування(текст)


Таблиця 3. Структура даних довідника КОПФГ (HBOGRLEGAL)

Назва елементу Назва поляТип/формат
Унікальний ідентифікаторCODE Ідентифікатор (число)
Символьний код NUM Код (число)
Найменування NAME Найменування (текст)


Таблиця 4. Структура даних довідника видів діяльності (HBACTIVITY)

Назва елементу Назва поляТип/формат
Унікальний ідентифікатор CODE Ідентифікатор (число)
Символьний код NUM Код (число)
Найменування виду діяльностіNAME Найменування (текст)


Таблиця 5. Структура даних довідника форм фінансування (HBFINANC)

Назва елементу Назва поляТип/формат
Унікальний ідентифікатор CODE Ідентифікатор (число)
Символьний код NUM Код (число)
Найменування форми фінансуванняNAME Найменування (текст)




Таблиця 6. Структура даних довідника «КОАТУ» (HBKOATUU)

Назва елементу Назва поляТип/формат
Унікальний ідентифікаторCODE Ідентифікатор (число)
Символьний код NUM Код (число)
Найменування КОАТУ NAME Найменування (текст)


Таблиця 7. Структура даних довідника «КВЕД» (HBKVED)

Назва елементу Назва поляТип/формат
Унікальний ідентифікаторCODE Ідентифікатор (число)
Символьний код NUM Код (число)
Найменування КВЕД NAME Назва (текст)


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

Назва елементу Назва поляТип/формат
Унікальний ідентифікаторCODE Ідентифікатор (число)
Символьний код NUM Код (число)
Найменування галузі NAME Назва (текст)
Дата початку дії DTBEG дд.мм.рррр гг:хх
Дата припинення дії DTEND дд.мм.рррр гг:хх


Таблиця 9. Структура даних довідника «Підгалузь» (HBMPDIR)

Назва елементу Назва поляТип/формат
Унікальний ідентифікаторCODE Ідентифікатор (число)
Символьний код NUM Код (число)
Назва NAME Назва (текст)


Таблиця 10. Структура даних довідника «Органи управління» (MPBRANCH)

Назва елементу Назва поляТип/формат
Унікальний ідентифікаторCODE Ідентифікатор (число)
Символьний код NUM Код (число)
Назва NAME Назва (текст)
Дата початку дії DTBEG дд.мм.рррр гг:хх
Дата закінчення дії DTEND дд.мм.рррр гг:хх


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


5.2.2      Джерела даних для програмного компоненту «Соціальна політика»

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

Назва елементу Назва поля Тип/формат
Ідентифікатор пацієнта ClientId Ідентифікатор (число)
Дата народження пацієнта ClientBirthday дд.мм.рррр гг:хх
Пільгова категорія ContingentType Категорія (текст)
Статус картки пацієнта ClientCardStatus Статус (текст)
Спеціалізація лікуючого фахівця cli_sp_specialization Спеціалізація (текст)
Прізвище фахівця cli_sp_name Прізвище (текст)
Потрібна повторна диспансеризація NeedsRepeatedDispenserizationТак/Ні
Тип навчального закладу CliEducationOrgType Тип (текст)
Назва навчального закладу EdcOrgUnitName Назва (текст)
Потрібна соціальна допомога NeedsSocialAssistance Так/Ні
Потрібні засоби реабілітації NeedRehabMeans Так/Ні
Потрібна медична консультація NeedMedConsultation Так/Ні
Код курсу реабілітації RehabId Число
Дата початку курсу реабілітації RehabDateFrom дд.мм.рррр гг:хх
Дата закінчення курсу реабілітації RehabDateTo дд.мм.рррр гг:хх
Тривалість курсу реабілітації RehabDuration Інтервал
Тип курсу реабілітації RehabType Тип (текст)
Статус курсу реабілітації RehabCourseCardStatus Текст
Потенціал курсу реабілітації RehabPotential Текст
Стан обмеження LimitationOfLife Текст
Завершеність курсу CourseCompletionDegree Текст
Досягнення цілі реабілітації CourseGoalAchieveDegree Текст
Ідентифікатор послуги CdnServiceId Ідентифікатор (число)
Назва послуги ServiceName Назва (текст)
Тип спеціалізації послуги ServiceGroup Тип (текст)
Тип послуги ServiceCostType Тип (текст)
Ідентифікатор прийому AppointmentId Ідентифікатор (число)
Назва кабінету CabinetName Текст
Номер кабінету CabinetNumber Номер (число)
Тип зустрічі CliAppointmentKindCode Тип (текст)
Дата зустрічі AppointmentDate дд.мм.рррр гг:хх
Статус зустрічі AppointmentStatus Текст
Тривалість зустрічі AppointmentDuration Інтервал
Організація OrgName Текст
Місто OrgLocation Текст
Поштовий індекс OrgPostIndex 12345
Вулиця OrgStreet Текст
Номер будинку OrgBuilding Номер (число)
Тип ТЗР TzrTypeName Текст
Підтип ТЗР TzrSubTypeName Текст
Назва ТЗР TzrName Назва (текст)
Кількість ТЗР TZRQuantity Кількіисло)
Статус заявки на оренду ТЗР ApplnStatus Статус (текст)
Планова дата початку оренди ТЗР TZRDateBeginPlan дд.мм.рррр гг:хх
Планова дата закінчення оренди ТЗР TZRDateEndPlan дд.мм.рррр гг:хх
Фактична дата початку оренди ТЗР TZRDateBeginFact дд.мм.рррр гг:хх
Фактична дата закінчення оренди ТЗРTZRDateEndFact дд.мм.рррр гг:хх

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

5.2.3      Джерела даних для програмного компоненту «Запис до лікаря»

Звіти для програмного компоненту «Запис до лікаря» формуються на основі даних Електронної медичної системи “Helsi”. Дані для програмного компоненту «Запис до лікаря» надходять у Систему у вигляді аналітичних вибірок даних (таблиць, що вивантажуються). Таблиця 12. Структура таблиці “Заповнені декларації відповідно району та віку пацієнтів”

Назва елементу Назва поля Тип/формат
Район міста Area Назва (текст)
Організація Organisation Назва (текст)
Дата заповнення деклараціїDate дд.мм.рррр гг:хх
Вік пацієнта PatientYearsOld 123
Кількість декларацій DeclarationCnКількість (число)лоКількість (число)

  Таблиця 13. Структура таблиці “Кількість лікарів відповідно до району міста”

Назва елементуНазва поляТип/формат
Район міста Area Назва (текст)
Організація Organisation Текст
Кількість лікарів Doctor_cnt Кількість (число)

  Таблиця 14. Структура таблиці “Кількість пацієнтів за віком та статтю”

Назва елементу Назва поляТип/формат
Район міста Area Назва (текст)
Організація Organisation Назва (текст)
Дата запису до лікаряDate дд.мм.рррр гг:хх
Стать Gender Текст (чол/жін)
Вікова група YearsGroup 123
Кількість пацієнтів UniqPatient Кількість (число)

  Таблиця 15. Структура таблиці “Інформація за записами до лікарів відповідно до спеціалізації”

Назва елементу Назва поля Тип/формат
Район міста Area Текст
Організація PlanedToOrganisationТекст
Канал запису CreatedChannel Назва каналу (Сайт, реєстратура, кол-центр тощо)
Дата запису EventDate дд.мм.рррр гг:хх
Спеціалізація лікаряDoctorSpeciality Назва спеціалізації
Вік пацієнта PatientYearsOld 123
Кількість записів PlanedEvent Кількість (число)

Таблиця 16. Структура таблиці “Кількість населення відповідно до району”

Назва елементу Назва поля Тип/формат
Район міста англійськоюDistrictNameENGНазва району
Район міста українськоюDistrictNameUKRНазва району
Кількість населення Coun Кількість (число)

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

5.2.4      Джерела даних для програмного компоненту «Швидка допомога»

Звіти для програмного компоненту Інформаційно-аналітична система «Єдиний медичний простір» формуються на основі даних ІТС «Звітність». Дані для програмного компоненту «Швидка допомога» надходять у Систему у вигляді аналітичних вибірок даних (таблиць, що вивантажуються).   Таблиця 17. Структура таблиці “Заповнені декларації відповідно району та віку пацієнтів”

Назва елементуНазва поляТип/формат
Дата Status_Date дд.мм.рррр гг:хх
Номер бригади BrigadeNumber Номер (число)
Статус Status Статус (текст)
Район міста District Текст

Таблиця 18. Структура таблиці “Заповнені декларації відповідно району та віку пацієнтів”

Назва елементу Назва поля Тип/формат
Район District Текст
Номер бригади BrigadeNumber Номер (число)
Час звернення Request_Time гг:хх
Час приїзду Arrival_Time гг:хх
Привід до виклику Request_Reason Привід (текст)
Вікова категорія IsAdult 123
Статус госпіталізації IsHospitalized так / ні
Час закінчення викликуRequest_End_Timeгг:хх

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

5.2.5      Джерела даних для програмного компоненту «АТП-5»

Звіти для програмного компоненту Автоматизована система обліку транспортної роботи (АСОТР) формуються на основі даних ІТС «Звітність». Дані для програмного компоненту «АТП.5» надходять у Систему у вигляді аналітичних вибірок даних (таблиць, що вивантажуються).   Таблиця 19. Структура таблиці “Дані про відповідність руху транспорту відповідно до маршруту”

Назва елементу Назва поля Тип/формат
Код маршруту Id Номер (число)
Дата Date дд.мм.рррр гг:хх
Тип транспорту TransportTypeIdТип (текст)
Філія (ДЕПО) Filiya Назва (Автопарк № 2 тощо)
Номер маршруту Mar Номер (число)
Планова кількість виїздів Plan Кількість (число)
Фактична кількість виїздів Fact Кількість (число)
Відсоток транспорту, що рухається відповідно плануKVp Коефіцієнт (%)

  Таблиця 20. Структура таблиці “Дані про відповідність руху транспорту відповідно до маршруту”

Назва елементуНазва поляТип/формат
Код маршруту Id Номер (число)
Код причини Code Номер (число)
Назва причини Name Назва  (текст)
Дата оновлення UpdatedAt дд.мм.рррр гг:хх

Таблиця 21. Структура таблиці “Кількість транспорту, що не вийшла на маршрут”

Назва елементу Назва поляТип/формат
Код маршруту Id Номер (число)
Код випуску VypuskId Номер (число)
Код причини невиїздуViolRefId Структура даних в форматі {V1, V2…}
Кількість невиїздів VoilCoun Число
Дата оновлення UpdatedAt дд.мм.рррр гг:хх

  Дані повинні отримуватись щоденно.

5.2.6      Перелік звітів за компонентами

Таблиця 22. Детальний перелік звітів за компонентами

Компонент Перелік звітів
-        Комунальні підприємства -        Реєстр органів управління зі статистикою по наданню звітності підпорядкованими підприємствами;

-        Перелік суб’єктів господарювання територіальної громади м. Києва, що підпорядковані департаментам та районам;

-        Реєстр установ, підпорядкованих КМДА;

-        Картка організації;

-        Показники фінансової діяльності за фінансовою звітністю;

-        Показники фінансової діяльності за фінансовим планом;

-        Перелік збиткових підприємств;

-        Перелік прибуткових підприємств.
-        Соціальні послуги -        Конструктор звітів на основі даних програмного модуля «Соціальні послуги»;

-        Статистика за кількістю прийомів за певний період;

-        Кількість прийомів за період в розрізі;

-        Статистика за категорією пацієнтів на реабілітації;

-        Статистика за кількістю послуг (за типами спеціалізацій);

-        Статистика за заявками на оренду технічних засобів реабілітації (ТЗР) за певний період;

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

-        Статистику про власні надходження та капітальні інвестиції;

-        Статистику про кредиторську та дебіторську заборгованість;

-        Статистику про доходи та витрати;

-        Статистику про збитки об’єктів комунальної власності.                       
Інформаційна панель для ролі «Київський міський голова» -        Звіт про діяльність контакт-центрів 1551 і 1557;

-        Звіт за основними показниками діяльності у сфері здоров’я;

-        Звіт за зведеними показниками діяльності закладів дошкільної освіти;

-        Звіт про фінансові результати діяльності міста;

-        Звіт про роботу транспортних підприємств;

-        Звіт про діяльність Національної поліції міста.
Інформаційно-аналітична панель «Освіта»


-        Звіт про загальну кількість дітей у загальноосвітніх навчальних закладах;

-        Звіт про кількість загальноосвітніх навчальних закладів відповідно до типів;

-        Звіт про результати зовнішнього незалежного оцінювання відповідно до району міста;

-        Звіт за основними показниками діяльності загальноосвітніх навчальних закладів;

-        Звіт про основні показники діяльності ЗНЗ відповідно до району міста;

-        Звіт про кількість новобудов та нових шкіл, що були відкриті у 2018 році, відповідно до району міста;

-        Звіт про категорії педагогів відповідно до віку;

-        Звіт про топ шкіл, які використовують найбільшу частку бюджетного фінансування;

-        Звіт про кількість дітей у закладах дошкільної освіти відповідно до віку;

-        Звіт про кількість вільних місць та чергу до закладів дошкільної освіти відповідно до віку;

-        Звіт про кількість вільних місць та чергу до закладів дошкільної освіти за районами міста;

-        Звіт про кількість груп та середнє навантаження закладів дошкільної освіти відповідно до віку;

-        Звіт за основними показниками діяльності закладів дошкільної освіти;

-        Звіт про кількість дитячих садків (діючих та нових) та середнє навантаження на них за районами міста;

-        Звіт за дитячими садками з найбільшою чергою;

-        Звіт за дитячими садками з найбільшим навантаженням.
Інформаційно-аналітична панель «Медицина»


-        Звіт про  кількість пацієнтів на 1 лікаря та приріст декларацій;

-        Звіт про відсоток декларацій, підписаних населенням за районами міста;

-        Звіт про кількість та структуру пацієнтів;

-        Звіт за даними декларацій, запису до лікаря та кількістю прийомів;

-        Звіт за узагальненими даними записів до лікаря;

-        Звіт про найпопулярніші спеціалізації лікарів;

-        Звіт за каналами запису до лікаря;

-        Звіт про погодинну кількість звернень до швидкої допомоги;

-        Звіт про розподіл бригад швидкої допомоги за районами міста;

-        Звіт про звернення пацієнтів до швидкої допомоги;

-        Звіт про ріст викликів швидкої допомоги за причинами їх виникнення;

-        Звіт про розподіл викликів швидкої допомоги за причиною;

-        Звіт про час прибуття швидкої допомоги на виклик;

-        Звіт про погодинну кількість звернень до швидкої допомоги;

-        Звіт про ріст викликів швидкої допомоги за причинами їх виникнення;

-        Звіт про розподіл викликів швидкої допомоги за причиною;

-        Звіт про час прибуття швидкої допомоги на виклик;

-        Звіт про співвідношення між кількістю виїздів за викликом та зверненнями на лінію швидкої допомоги;

-        Звіт про звернення пацієнтів до швидкої допомоги.
Інформаційно-аналітична панель «Національна поліція»


-        Звіт про динаміку звернень до Національної поліції;

-        Звіт про статистику звернень до Національної поліції за районами;

-        Звіт із статистики за типами злочинів;

-        Звіт про типи злочинів, які мали значний приріст.
Інформаційно-аналітична панель «Транспорт. Автотранспортне підприємство 5»-        Звіт про функціонування рухомих об’єктів погодинно;

-        Звіт про функціонування рухомих об’єктів відповідно до номеру маршруту;

-         Звіт про статуси рухомих об’єктів;

-        Звіт про причини відхилення від розкладу руху курсування рухомих об’єктів;

-        Звіт про основні показники діяльності рухомих об’єктів, та відповідності плановим показникам.

 

5.3       Вимоги до функціонального складу компонентів

5.3.1      Програмний компонент «Комунальні підприємства»

Компонент забезпечить:


Компонент включатиме наступні складові:

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

  1. Реєстр органів управління зі статистикою по наданню звітності підпорядкованими підприємствами.

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

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

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

Може містити значення: «1 квартал», «2 квартал», «3 квартал» та «Рік». Для обраного року в список потрапляють лише ті періоди, за які надавалась звітність хоча б одним підприємством. До тих пір, поки період не обрано, звіт не містить даних.

Містить значення: «Всі», «Місто», «Район». Якщо користувач обирає «Район», то в звіт повинні потрапити районні органи управління (районні державні адміністрації). При обранні значення «Місто» звіт повинен містити департаменти КМДА. При обранні значення «Всі» в звіт потрапляють всі органи управління. Це значення є значенням по замовчуванню. Користувач може обрати тільки одне значення зі списку.

Містить перелік всіх департаментів КМДА та районних державних адміністрацій з довідника «Органи управління», а також значення «Всі», яке відображається на початку списку і є значенням по замовчуванню. Структуру довідника «Органи управління» наведено в Таблиця 10. В цьому фільтрі користувач повинен мати можливість обрати декілька значень для відображення в звіті.

Містить значення з довідника «Форми фінансування», а також значення “Всі”, яке повинно відображатись на початку списку і є значенням по замовчуванню. Користувач може обрати тільки одне значення зі списку. Структуру довідника «Форми фінансування» наведено в Таблиця 5.

Відображаються значення з довідника «Форми власності». На початку списку повинен відображатись елемент «Всі», який є значенням по замовчуванню. Користувач може обрати тільки одне значення зі списку. Структуру довідника «Форми власності» наведено в Таблиця 2.

Містить значення з довідника «Галузь», структуру якого наведено в Таблиця 8. Користувач може обирати декілька значень зі списку. Якщо не обрано жодного значення, фільтр не накладається.

Відображаються значення з довідника «Види діяльності», структуру якого наведено в Таблиця 4. Користувач може обрати декілька значень зі списку. Якщо не обрано жодного значення, фільтр не накладається. При натисканні курсором миші на посилання з назвою органу управління повинен виконуватись перехід на сторінку зі звітом «Перелік суб’єктів господарювання територіальної громади м. Києва, що підпорядковані департаментам та районам». При цьому в перелік підприємств повинні потрапити лише ті підприємства, які підпорядковані обраному органу управління. Аналогічна сторінка повинна відображатись при натисканні курсору миші на значення в стовпці «Кількість організацій». При натисканні курсором миші на ненульове значення в стовпцях «Звітувало організацій», «Не звітувало» та «Не повністю звітувало» повинен відкриватись звіт «Перелік суб’єктів господарювання територіальної громади м. Києва, що підпорядковані департаментам та районам», до якого потрапляють тільки ті підпорядковані органу управління підприємства, які відповідно здали повну звітність, не здали звітність або здали не повну звітність. При натисканні курсором миші на ненульове значення в стовпцях «Кількість організацій в стані реорганізації», «Кількість організацій в стані ліквідації» та «Кількість організацій в стані банкрутства» повинен виконуватись перехід на звіт «Перелік суб’єктів господарювання територіальної громади м. Києва, що підпорядковані департаментам та районам», до якого будуть потрапляти тільки ті підпорядковані органу управління підприємства, які знаходяться у відповідному стані. Користувачеві повинна бути надана можливість завантажити детальний та зведений звіт. Зведений звіт повинен містити наступну інформацію про надання обов’язкової фінансової звітності підприємствами в розрізі органів управління:

Детальний звіт повинен містити перелік всіх підприємств за обраними користувачем фільтрами зі статусом подання звітності по кожному підприємству окремо. По кожному органу управління звіт повинен формуватися в окремому файлі у форматі MS Excel з розширенням .xlsx.  Звіт повинен містити наступні стовпці:

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

  1. Перелік суб’єктів господарювання територіальної громади м. Києва, що підпорядковані департаментам та районам.

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

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

Містить значення: «У стані реорганізації», «У стані ліквідації», «У стані банкрутства», «Інші». Користувач повинен мати можливість обирати декілька значень. При цьому в переліку будуть відображатись організації в залежності від вибору користувача.

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

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

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

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

При натисканні курсором миші на назву стовпця повинно виконуватись сортування таблиці за зростанням даних обраного стовпця, при повторному натисканні – сортування за спаданням даних стовпця. Користувачеві повинна бути надана можливість зберегти сформований звіт в форматі PDF або XLSX. Дані в стовпці «Найменування суб’єкту господарювання» повинні мати вигляд посилання, при натисканні на яке формується звіт «Картка організації» з інформацією по обраній установі.  

  1. Реєстр установ, підпорядкованих КМДА.

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

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

Містить перелік всіх департаментів КМДА та районних державних адміністрацій з довідника «Органи управління», структуру якого наведено в Таблиця 10, а також значення «Всі», яке відображається на початку списку і є значенням по замовчуванню. В цьому фільтрі користувач повинен мати можливість обрати декілька значень для відображення в звіті.

Містить значення з довідника «Форми фінансування», структуру якого наведено в Таблиця 5, а також значення «Всі», яке повинно відображатись на початку списку та є значенням по замовчуванню. Користувач може обрати тільки одне значення зі списку.

Містить значення з довідника «Форми власності», структуру якого наведено в Таблиця 2 та значення “Всі”, яке повинно відображатись на початку списку і є значенням по замовчуванню. Користувач може обрати тільки одне значення зі списку.

Містить значення з довідника «Галузь», структуру якого наведено в Таблиця 8. Користувач може обирати декілька значень зі списку. Якщо не обрано жодного значення, фільтр не накладається.

Відображаються значення з довідника «Види діяльності», структуру якого наведено в Таблиця 4. Користувач може обрати декілька значень зі списку. Якщо не обрано жодного значення, фільтр не накладається.

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

Містить значення: «У стані реорганізації», «У стані ліквідації», «У стані банкрутства», «Інші». Користувач повинен мати можливість обирати декілька значень.  При цьому в переліку будуть відображатись організації в залежності від вибору користувача.

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

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

При натисканні курсором миші на назву стовпця повинно виконуватись сортування таблиці за зростанням даних обраного стовпця, при повторному натисканні – сортування за спаданням даних стовпця. Дані в стовпці «Найменування суб’єкту господарювання» повинні мати вигляд посилання, при натисканні на яке формується звіт «Картка організації» з інформацією по обраній установі.  

  1. Картка організації.

Картка організації має містити загальну інформацію про установу та перелік поданої обов’язкової фінансової звітності. Інформація по підприємству розділяється на 3 блоки:

Блок «Загальна інформація» повинен містити наступні дані:

Блок «Керівництво» повинен містити дані:

Блок «Контактні дані» повинен містити інформацію:

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

Список форм для малих госпрозрахункових підприємств в періоді – рік:

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

Список форм для середніх та великих госпрозрахункових підприємств в періоді – рік:

Список форм для бюджетних установ:

 

  1. Показники фінансової діяльності за фінансовою звітністю.

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

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

Для кожного з вище вказаних показників повинна надаватись інформація про планове та фактичне значення, а також абсолютне відхилення фактичного результату від планового. При натисканні курсором миші на назву організації повинна відобразиться «Картка організації», що містить загальну інформацію про установу та перелік поданої обов’язкової фінансової звітності (див. п. 4). Користувачеві повинна бути надана можливість завантажити звіт в форматі MS Excel. Приклад аналітичного звіту «Показники фінансової діяльності за фінансовою звітністю» наведено на Рис. 6.   Рис. 6. Показники фінансової діяльності за фінансовою звітністю

  1. Показники фінансової діяльності за фінансовим планом.

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

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

Користувачеві повинна бути надана можливість завантажити звіт в форматі MS Excel. Приклад аналітичного звіту «Показники фінансової діяльності за фінансовим планом» наведено на Рис. 7.   Рис. 7. Показники фінансової діяльності за фінансовим планом   При натисканні курсором миші на назву організації повинна відобразитись «Картка організації», що містить загальну інформацію про установу та перелік поданої обов’язкової фінансової звітності.  

  1. Перелік збиткових підприємств.

Аналітичний звіт «Перелік збиткових підприємств, організацій комунальної власності м. Києва, що підпорядковані виконавчому органу КМР (КМДА) та його структурним підрозділам, за результатами фінансово-господарської діяльності за ____ рік» містить перелік установ, що мають від’ємне значення в рядку 2350 форм Ф2 КМ100213 або Ф2м КМ110011. Користувачеві має бути надана можливість обрати рік, за результатами якого виконується аналіз. Звіт повинен містити таблицю з наступною інформацією:

Перед таблицею має відображатись рядок із загальною кількістю об’єктів в звіті. Перший рядок таблиці - підсумковий з загальною сумою чистого збитку за всіма підприємствами. Установи в звіті повинні бути згруповані за галуззю. Назва галузі повинна відображатись перед переліком збиткових підприємств цієї галузи. Для кожної галузі повинна відображатись сума чистого збитку підприємств галузі. Приклад звіту надано на Рис. 8. Рис. 8. Приклад звіту «Перелік збиткових підприємств»

  1. Перелік прибуткових підприємств.

Аналітичний звіт «Перелік прибуткових підприємств, організацій комунальної власності м. Києва, що підпорядковані виконавчому органу КМР (КМДА) та його структурним підрозділам, за результатами фінансово-господарської діяльності за ____ рік» містить перелік установ, що мають позитивне значення в рядку 2350 форм Ф2 КМ100213 або Ф2м КМ110011. Користувачеві має бути надана можливість обрати рік, за результатами якого виконується аналіз. Звіт повинен містити таблицю з наступною інформацією:

  Перед таблицею має відображатись рядок із загальною кількістю об’єктів у звіті. Перший рядок таблиці - підсумковий з загальною сумою чистого прибутку за всіма підприємствами. Установи в звіті повинні бути згруповані за галуззю. Назва галузі повинна відображатись перед переліком прибуткових підприємств цієї галузи. Для кожної галузі повинна відображатись сума чистого прибутку підприємств галузі. Приклад звіту надано на Рис. 9: Рис. 9. Приклад звіту «Перелік прибуткових підприємств».  

  1. Інформаційна панель для Департаменту комунальної власності.

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

  1. Звіт про кількість організацій, що звітували або не звітували за вказаний період.

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

  1. Звіт про стани організацій

Звіт має надавати інформацію про кількість організацій у відповідному стані, а саме:

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

  1. Звіт про фінансову діяльність комунальних підприємств.

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

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

  1. Звіт про фінансові результати діяльності державних підприємств.

Звіт має надавати інформацію про фінансові результати діяльності державних підприємств і надавати дані про:

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

5.3.2      Інформаційна панель для ролі «Київський міський голова»

  1. Звіт про діяльність контакт-центрів 1551 і 1557

Звіт повинен надавати інформацію про кількість звернень на лінію Центральної Диспетчерської Служби з питань ЖКГ 1557 та контактного центру міста Києва 1551. Окрім того. звіт має відображати дані про кількість запитів з простроченим терміном розгляду. Звіт має бути представлений у вигляді інформаційної панелі, що розділена на дві частини: ліва надає інформацію про звернення на лінію з питань ЖКГ, а права - до контактного центру Києва. Верхня частина панелі повинна відображати у числовому вираженні кількості звернень до служби підтримки. нижня – надавати інформацію про прострочені звернення на лінію, на номер 1557 у відсотковому вираженні від кількості звернень, а на номер 1551 – надана інформація про кількість та частку звернень з простроченим терміном розгляду.  Приклад інформаційної панелі наведено на Рис. 12: Рис. 12. Звіт про діяльність контакт-центрів 1551 та 1557  

  1. Звіт за основними показниками діяльності у сфері здоров’я

Звіт повинен надавати інформацію по діяльності закладів з охорони здоров’я, зокрема:

          Окремо має надаватись інформація з роботи швидкої допомоги – дані, що відображають кількість:

Інформація повинна бути представлена графічно у вигляді діаграм, де кожна частина надає інформацію по вищевказаним критеріям. Приклад графічного представлення звіту за основними показниками в сфері здоров’я надано на Рис. 13:
Рис. 13. Звіт за основними показниками в сфері здоров`я.  

  1. Звіт за зведеними показниками діяльності закладів дошкільної освіти.

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

Приклад графічного представлення звіту за зведеними показниками діяльності закладів дошкільної освіти наведено на Рис. 14:   Рис. 14. Звіт за зведеними показниками діяльності закладів дошкільної освіти.  

  1. Звіт про фінансові результати діяльності міста.

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

  1. Звіт про роботу транспортних підприємств

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

Приклад графічного представлення звіту про роботу транспортних підприємств наведено на Рис. 16: Рис. 16. Звіт про роботу транспортних підприємств  

  1. Звіт про діяльність Національної поліції міста.

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

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

5.3.3      Інформаційно-аналітична панель «Освіта»

Компонент надає можливість відслідковувати інформацію щодо основних показників діяльності напрямків освіти у місті.

  1. Компонент «Школи»

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

  1. Звіт про загальну кількість дітей у загальноосвітніх навчальних закладах.

Звіт повинен надавати у графічному вигляді дані про загальну кількість дітей у ЗНЗ та окремо по класам з градацією на:

Окрім того, у звіті має бути представлена інформація про кількість дітей, що відвідують або не відвідують групу продовженого дня (ГПД). Інформація про кількість учнів повинна відображатись при наведенні курсору миші на відповідну частину діаграми. Звіт повинен мати заголовок «Загальна кількість дітей в ЗНЗ». Під назвою має бути відображена загальна кількість дітей, що навчаються в ЗНЗ міста Києва. Звіт має бути представлений у вигляді подвійної кругової діаграми, де внутрішня частина надає інформацію про кількість учнів по класам (1 - 4, 5 - 9 і 10 - 12 класи), а зовнішня відображає дані про частку дітей, які відвідують та не відвідують групу продовженого дня. Приклад звіту «Загальна кількість дітей в ЗНЗ» наведено на Рис. 18.
Рис. 18. Загальна кількість дітей в ЗНЗ   При наведенні курсором миші на певну частину звіту повинна відображатися інформація про кількість дітей у відповідній віковій категорії  

  1. Звіт про кількість загальноосвітніх навчальних закладів відповідно до типів.

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

        Звіт повинен мати заголовок «ЗНЗ за типами» і представляти собою стовпчасту діаграму, де вертикальна вісь надає інформацію про кількість ЗНЗ, а горизонтальна відображає типи загальноосвітніх навчальних закладів. Приклад звіту «ЗНЗ за типами» показано на Рис. 19:
Рис. 19. ЗНЗ за типами  

  1. Звіт про результати зовнішнього незалежного оцінювання відповідно до району міста.

Звіт має надавати інформацію про відсоток шкіл за районами міста з наведенням рівня за результатами ЗНО:

Звіт повинен мати заголовок «Розподіл за балами ЗНО» та бути представлений у вигляді нормованої лінійчатої діаграми з накопиченням, у якої вертикальна вісь відображає інформацію за районами міста, а горизонтальна вісь надає дані за відсотками певного рівня балів. Приклад звіту «Розподіл за балами ЗНО» надано на Рис. 20: Рис. 20. Розподіл за балами ЗНО  

  1. Звіт за основними показниками діяльності загальноосвітніх навчальних закладів.

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

Звіт повинен мати заголовок «Основні показники» та мати вигляд інформаційної панелі з наданими вище кількісними показниками. Приклад інформаційної панелі наведено на Рис. 21: Рис. 21. Основні показники  

  1. Звіт про основні показники діяльності ЗНЗ відповідно до району міста.

Звіт повинен надавати загальні показники функціонування ЗНЗ, зокрема про:

Звіт повинен мати заголовок «Статистична інформація» та бути представлений у вигляді комбінованої діаграми, де кількість нових шкіл та загальна кількість ЗОШ представлена у вигляді стовпчастої діаграми, а сума виділених коштів, середня кількість учнів у класі та кількість дітей у школі подається у вигляді графіка. Права вертикальна вісь повинна надавати інформацію про кількість учнів, а ліва - про суму виділених коштів у тисячах гривень. Горизонтальна вісь повинна містити назви районів міста, за якими представлені дані. Приклад звіту про основні показники діяльності ЗНЗ за районами міста наведено на Рис. 22: Рис. 22. Статистична інформація   Відображення конкретної інформації про кількість шкіл, середню кількість учнів у класі, кількість дітей у черзі та суму виділених коштів повинно виконуватись при наведенні курсору миші на відповідну частину діаграми.  

  1. Звіт про кількість новобудов та нових шкіл, що були відкриті у 2018 році, відповідно до району міста.

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

  1. Звіт про категорії педагогів відповідно до віку.

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

Приклад звіту «Розподіл педагогічних працівників за віком» наведено на Рис. 24: Рис. 24. Розподіл педагогічних працівників за віком При наведенні курсору миші на певну ділянку діаграми повинна відобразитись інформація про кількість педагогів відповідної вікової категорії у певному районі міста.  

  1. Звіт про топ шкіл, які використовують найбільшу частку бюджетного фінансування.

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

Приклад звіту «Топ 5 шкіл за часткою використаних бюджетних коштів» наведено на Рис. 25: Рис. 25. Топ 5 шкіл за часткою використаних бюджетних коштів  

  1. Компонент «Заклади дошкільної освіти»

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

  1. Звіт про кількість дітей у закладах дошкільної освіти відповідно до віку

Звіт повинен надавати інформацію про загальну кількість дітей у дитячих садках у розрізі вікових категорій. Звіт має називатись «Кількість дітей в дитсадках» та бути представлений у вигляді кругової діаграми, де надано інформацію про відсоток дітей відповідної вікової категорії від їх загальної кількості. Кількісна інформація за віковою категорією дітей повинна відображатись при наведенні курсору миші на відповідну частину діаграми. Також звіт повинен відображати загальну кількість дітей в дитсадках м. Києва. На графіку повинні бути представлені наступні вікові категорії:

Приклад звіту «Кількість дітей в дитсадках» наведено на Рис. 26: Рис. 26. Кількість дітей в дитсадках  

  1. Звіт про кількість вільних місць та чергу до закладів дошкільної освіти відповідно до віку дітей

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

  1. Звіт про кількість вільних місць та чергу до закладів дошкільної освіти за районами

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

  1. Звіт про кількість груп та середнє навантаження на заклади дошкільної освіти відповідно до віку дітей

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

  1. Звіт за основними показниками діяльності закладів дошкільної освіти

Звіт повинен надавати узагальнену інформацію щодо діяльності дитячих садків, а саме:

Звіт повинен бути представлений у вигляді інформаційної панелі, що відображає кількісні характеристики за вказаними параметрами. Приклад звіту «Основні показники діяльності закладів дошкільної освіти» наведено на Рис. 30: Рис. 30. Основні показники діяльності закладів дошкільної освіти  

  1. Звіт про кількість дитячих садків (діючих та нових) та середнє навантаження на них за районами міста

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

  1. Звіт за дитячими садками з найбільшою чергою

Звіт повинен надавати інформацію за дитячими садками, до яких найбільша черга з поданих заяв. Звіт повинен мати назву «Топ 5 дитсадків за чергою» та бути представлений у вигляді таблиці, де:

Рис. 32. Топ 5 дитсадків за чергою При натисканні курсором миші на назву стовпця повинно відбуватися сортування в алфавітному порядку або у зворотному порядку. При сортуванні стовпця з цифровими даними інформація буде відображена у порядку зростання або спадання.  

  1. Звіт за дитячими садкам з найбільшим навантаженням

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

Приклад звіту «Топ 5 дитсадків за навантаженням» наведено на Рис. 33: Рис. 33. Топ 5 дитсадків за навантаженням При натисканні курсором миші на назву стовпця повинно відбуватися сортування або в алфавітному порядку, або у зворотному. При сортуванні стовпця з цифровими даними інформація повинна бути відображена у порядку зростання або спадання.

5.3.4      Інформаційно-аналітична панель «Медицина»

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

  1. Інформація про стан роботи сервісу «Запис до лікаря» через систему Helsi

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

  1. Звіт про кількість пацієнтів на 1 лікаря та приріст декларацій

Звіт повинен містити наступну інформацію:

Звіт повинен надавати інформацію з роботи лікаря відповідно до району та забезпечувати можливість аналізу районів міста з найбільшою завантаженістю фахівців. Окрім того, звіт повинен надавати інформацію з кількості декларацій, підписаних населенням. Для формування звіту користувач повинен мати можливість обрати період або окрему дату. Звіт повинен мати назву «Кількість пацієнтів на 1 лікаря та приріст декларацій» та бути представлений у вигляді стовпчастої діаграми з загальною інформацією з кількості пацієнтів на одного лікаря та окремо - з кількості підписаних декларацій за всіма районами міста; При натисканні курсором миші на окремий елемент легенди діаграми повинна відображатись тільки відповідна частина даних. Інформація повинна надаватись у кількісних показниках. Вертикальна вісь ліворуч повинна відображати кількість пацієнтів на одного фахівця, вертикальна вісь праворуч - кількість підписаних декларацій. Горизонтальна вісь представляє розподіл показників за районами міста. Приклад звіту «Кількість пацієнтів на 1 лікаря та приріст декларацій» наведено на Рис. 34: Рис. 34. Кількість пацієнтів на 1 лікаря та приріст декларацій При наведенні курсору миші на відповідну частину діаграми повинна відображатись підказка із зазначенням району міста, типу даних та їх кількісної характеристики.  

  1. Звіт про відсоток декларацій, підписаних населенням, за районами міста

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

  1. Звіт про кількість та структуру пацієнтів

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

  1. Звіт за даними декларацій, записом до лікаря та кількістю прийомів

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

Підсумковий рядок «Всього» має відображати загальний результат за всіма районами Києва:

  Приклад звіту наведено на Рис. 37: Рис. 37. Звіт за даними декларацій, записом до лікаря та кількістю прийомів  

  1. Звіт за узагальненими даними записів до лікаря

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

  Рис. 38. Звіт по узагальненим даним записів до лікаря (частина 1) Рис. 39. Звіт по узагальненим даним записів до лікаря (частина 2) Перехід між інформаційними панелями повинен виконуватись автоматично через певні проміжки часу або при натисканні користувачем іконки перемикання панелей.

  1. Звіт про найпопулярніші спеціалізації лікарів

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

  1. Звіт за каналами запису до лікаря

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

Приклад звіту «Розподіл записів за каналами» наведено на Рис. 41: Рис. 41. Розподіл записів за каналами При наведенні курсору миші на певну частину діаграми повинна бути відображена інформація про кількість записів за обраним каналом.    

  1. Інформація про актуальний стан роботи швидкої допомоги. Статистика ситуації в режимі Онлайн

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

  1. Звіт за погодинною кількістю звернень до швидкої допомоги

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

  1. Звіт про розподіл бригад швидкої допомоги за районами міста

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

Вертикальна вісь має відображати назви районів міста, горизонтальна - дані за відсотковим співвідношенню між різними статусами бригад. Кількість бригад за статусами повинна бути відображена у рядку відповідного району міста. Приклад звіту «Розподіл бригад за статусами» наведено на Рис. 43: Рис. 43. Розподіл бригад за статусами  

  1. Звіт про звернення пацієнтів до швидкої допомоги

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

  Приклад звіту про звернення пацієнтів до швидкої допомоги наведено на Рис. 44: Рис. 44. Звіт про звернення пацієнтів до швидкої допомоги  

  1. Звіт про сплеск викликів швидкої допомоги за причинами їх виникнення

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

  1. Звіт про розподіл викликів швидкої допомоги за причиною

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

  1. Звіт про час прибуття швидкої допомоги на виклик

Звіт призначений для відображення інформації про час прибуття швидкої допомоги на виклик пацієнта. Звіт повинен називатись «Час приїзду на виклик» та мати вигляд кругової діаграми, що відображає інформацію щодо швидкості прибуття карети швидкої допомоги на виклик (у відсотковому вигляді) за градацією:

При наведенні курсору миші на відповідну ділянку даних повинна відображатись інформація в кількісних показниках. Приклад звіту «Час приїзду на виклик» наведено на Рис. 47:
Рис. 47. Час приїзду на виклик

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

  1. Звіт про погодинну кількість звернень до швидкої допомоги

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

  1. Звіт про сплеск викликів швидкої допомоги за причинами їх виникнення у порівнянні з попереднім періодом

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

  1. Звіт про розподіл викликів швидкої допомоги за причиною

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

  1. Звіт про час прибуття швидкої допомоги на виклик

Звіт призначений для відображення інформації про час прибуття швидкої допомоги на виклик пацієнта відповідно до району міста. Звіт повинен мати назву «Розподіл викликів за часом приїзду» та бути відображений у вигляді стовпчастої діаграми з інформацією із часом прибуття бригади швидкої допомоги на виклик (у відсотковому співвідношенні) за градацією:

Вертикальна вісь має відображати райони міста, горизонтальна вісь - відсотки викликів, за якими швидка прибула за вказаний часовий період. На діаграмі кількість викликів, за якими карета прибула у вказаний часовий проміжок, повинна бути відображена у рядку відповідного району міста. Приклад звіту наведено на Рис. 51: Рис. 51. Розподіл викликів за часом приїзду

  1. Звіт про співвідношення між кількістю виїздів за викликом до кількості звернень на лінію швидкої допомоги

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

  1. Звіт про звернення пацієнтів до швидкої допомоги

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

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

5.3.5      Інформаційно-аналітична панель «Національна поліція»

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

  1. Звіт про динаміку звернень до Національної поліції

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

  1. Звіт про статистику звернень до Національної поліції за районами

Звіт призначений для відображення інформації про кількість звернень до Національної поліції за обраний період відповідно до району міста, а також інформації про відсоток розслідуваних та розкритих справ. Звіт може бути корисний при визначенні районів з найбільшою кількістю кримінальних ситуацій, та районів, де було розкрито найбільше справ. Звіт повинен мати назву «Статистика за обраний період за районами» та бути представлений у вигляді стовпчастої діаграми з інформацією із кількості звернень громадян до Національної поліції відповідно до району міста та інформацією з розкритих і розслідуваних справ за обраний період у відсотковому вираженні. Горизонтальна вісь має відображати назви районів міста, за якими надана інформація:

Вертикальна вісь має відображати інформацію про кількість звернень до Національної поліції за обраний період. Приклад звіту наведений на Рис. 55: Рис. 55. Статистика за районами

  1. Звіт зі статистикою за типами злочинів

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

Приклад звіту «Статистика за обраний період за типами злочину» наведений на Рис. 56:
Рис. 56. Статистика за обраний період за типами злочину

  1. Звіт за типами злочинів, які мали значний приріст

Звіт надає інформацію за злочинами, кількість яких виросла в обраному періоді в порівнянні з попереднім. Дані можуть бути корисними для виявлення типів злочинів, які показали значний приріст, і, в подальшому, здійснити заходи для їх попередження. Звіт повинен мати назву «ТОП 5 приростів звернень за обраний період» та бути представлений у вигляді таблиці з наступними даними:

Приклад звіту наведений на Рис. 57: Рис. 57. ТОП 5 приростів звернень за обраний період.  

5.3.6      Інформаційно-аналітична панель «Транспорт. Автотранспортне підприємство 5»

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

  1. Звіт з функціонування рухомих об’єктів погодинно

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

  1. Звіт про функціонування рухомих об’єктів відповідно до номеру маршруту

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

  1. Звіт про статуси рухомих об’єктів

Звіт повинен містити актуальну інформацію за наступними статусами роботи транспорту:

Звіт повинен мати назву «Статуси РО» Та бути представлений у вигляді кругової діаграми, де кожен окремий сегмент має відображати частку рухомих об’єктів в обраному статусі. Приклад звіту наведений на Рис. 60:   Рис. 60. Статуси РО  

  1. Звіт про причини відхилення від розкладу руху курсування рухомих об’єктів

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

Приклад звіту «Причини запізнення» наведений на Рис. 61:   Рис. 61. Причини запізнення  

  1. Звіт з основних показників діяльності рухомих об’єктів та відповідності їх плановим показникам

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

Приклад звіту зі статистики за день наведений на Рис. 62: Рис. 62. Статистика за день  

5.3.7      Програмний компонент «Звіт для аудиту»

Звіт має бути сформований на основі фінансових показників діяльності організацій у вигляді таблиці з наступними стовпцями:

Приклад звіту наведений на Рис. 63 та Рис. 64: Рис. 63 Приклад звіту “Звіт для аудиту” (частина 1) Рис. 64. Приклад звіту “Звіт для аудиту” (частина 2) Користувач повинен мати можливість обмежувати кількість даних, що потрапляє до звіту, за допомогою фільтрів. Мають бути реалізовані наступні фільтри:

Значення «Всі» є значенням за замовчуванням. Користувач може обрати тільки одне значення зі списку.

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

У звіт повинні попадати тільки обрані користувачем організації. Дані в стовпці «Найменування суб’єкту господарювання» повинні мати вигляд посилання, при натисканні на яке формується звіт «Картка організації» з інформацією щодо обраної установи.

5.3.8      Програмний компонент «Соціальна політика»

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

  1. Статистика за кількістю прийомів пацієнтів за певний період

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

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

  1. Кількість прийомів пацієнтів за період в розрізах

Користувач повинен мати можливість сформувати статистику за кількістю прийомів за обраний період часу в різних розрізах, а саме:

Звіт повинен мати вигляд таблиці, що містить наступні дані:

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

  1. Статистика за категоріями пацієнтів на реабілітації

Звіт має бути представлений у вигляді таблиці, яка містить наступні дані:

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

  1. Статистика за кількістю послуг за типами спеціалізацій лікарів

Звіт має бути представлений у вигляді таблиці, яка містить наступні дані:

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

  1. Статистика за заявками на оренду технічних засобів реабілітації (ТЗР) за певний період

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

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

  1. Статистика за завантаженням кабінетів.

Звіт має бути представлений у вигляді таблиці, що містить наступні дані:

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

5.3.9      Розробка та впровадження нових компонентів аналізу, групування, відображення та збереження даних

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

  1. Компонент Зведена таблиця

Для обраної вітрини даних повинна бути розроблена можливість налаштувати групування та агрегацію даних, тим самим ілюструючи різні представлення однієї і тієї ж базової інформації. Компонент повинен надавати можливість для окремої вітрини даних формувати вибірки та зрізи даних для окремої вітрини даних, використовуючи існуючі дані. Користувач повинен мати можливість: - обрати вітрину даних, на основі якої хоче отримати аналітичний звіт; - обрати об’єкти, які буде виведено в стовпцях та рядках звіту; - обрати данні, які будуть відображені в блоці значень; - згрупувати чи розгрупувати блоки даних; - зберегти створений звіт в окремому блоці «Особисті звіти»; - змінити збережений раніше звіт або видалити його.   Приклад налаштування компоненту «Зведена таблиця» наведений на Рис. 65: Рис. 65. Приклад налаштування компоненту Зведена таблиця   Компонент повинен надавати можливість виконувати агрегування даних з використанням функцій «сума» та «кількість». Компонент «Зведена таблиця» повинен працювати з даними об’ємом до 100 тис. записів. При спробі роботи з більшим об’ємом даних треба попередити користувача щодо встановленого ліміту даних та запропонувати обмежити вибірку за одним із критеріїв. Якщо вибірка даних перевищує 1 млн. записів, то у користувача повинна бути можливість припинити виконання запиту. Приклад зупинення виконання запиту наведений на Рис. 66: Рис. 66. Приклад зупинення виконання запиту  

  1. Підсистема динамічного аналізу даних

Підсистема призначена для налаштування відображення даних у динаміці, що дасть можливість користувачеві проводити аналіз змін результатів та надасть можливість виявлення їх причин та наслідків, що може бути використано для покращення значень тих чи інших показників та якості наданих послуг. Вітрини відображення даних повинні мати можливість будуватись за наступними критеріями: «данні на зараз» та «динаміка даних» за умови, що надані дані мають періодичний характер та необхідну деталізацію. Переключення між режимами відображення даних повинно відбуватись за бажанням користувача. Дані не порівнюються за замовчуванням. У системі повинен бути реалізований зручний перехід від інформації, що відображає «дані на зараз», до статистичної інформації «динаміка даних». Дані в динаміці повинні містити актуальні дані на «вчора», якщо це закладено в джерелах даних та в регламенті оновлення. Дані на зараз – мають оновлюватися згідно з регламентом надання даних. На Рис. 67 наведений приклад відображення інформації «на зараз»:   Рис. 67. Приклад відображення інформації «дані на зараз» Користувач повинен мати можливість обрати період для аналізу (день, тиждень, місяць, діапазон дат тощо) у представленні даних у динаміці згідно потреб чи запиту. У звіт виводяться тільки ті дані, що відповідають обраному періоду. Користувач повинен мати можливість обрати період шляхом вибору дати початку та дати закінчення періоду. Якщо користувач не обирає період, то за замовчуванням відображаються дані за останній тиждень або місяць в залежності від джерела даних. При цьому дані, що показують стан і не можуть бути відображенні в динаміці, мають бути показані станом на останню дату вибірки або на останню дату в межах обраного періоду. Вибір певного періоду має бути зручним, інтуїтивно зрозумілим і реалізованим за допомогою компонента «Календар». Рис. 68. Приклад відображення інформації «динаміка даних»        

  1. Фільтрація даних

Необхідно розробити компонент фільтрації даних з наступними можливостями: - вибір одного чи декількох значень із включенням та виключенням елементів. Наприклад, обрати дані з кількості звернень у «1551» за декілька місяців за всіма районами, окрім Голосіївського; - ієрархічна фільтрація. Наприклад, у блоці «ЖКГ» обрати данні з кількості звернень за певним ЖЕДом Подільського району. Система фільтрації налаштовується для кожного звіту окремо. Якщо на вітрині даних налаштовано фільтрацію, то у верхній частині повинна відображатись іконка, при натисканні на яку буде відкрита панель фільтрів. Система має повідомляти користувача про кількість задіяних фільтрів з переліку налаштованих для поточного набору даних. Рис. 69. Приклад відображення іконки фільтру
Панель фільтрів повинна містити усі фільтри, що налаштовані для поточної вітрини даних із зазначенням обраного значення. Також повинна бути  передбачена можливість одночасного скидання усіх фільтрів. Рис. 70. Приклад відображення панелі фільтрів При роботі з даними користувач повинен мати можливість обрати інформацію, наприклад, за декількома районами,  виключити заявки з певними статусами тощо.

  1. Підсистема підказок та інформувань

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

  1. Автоматична розсилка регулярних звітів на електронну пошту

Необхідно реалізувати та впровадити автоматичне надсилання постійних звітів на електронну пошту користувачеві з посиланням для більш детального аналізу. Даний механізм повинен інформувати користувачів про основні показники обраного напрямку звітності, стимулювати користувачів частіше відвідувати Систему та спостерігати за доступною йому інформацією. Відправка звітів передбачається тільки для інформації верхнього рівня. Електронні листи, що автоматично створюються Системою, не підлягають редагуванню. Звіти мають відправлятися з адреси zvit@kyivcity.gov.ua. Звіти мають надходити користувачам системи із заданою періодичністю (один раз на день / тиждень) на електрону пошту. Надіслана інформація має відповідати вже сформованим звітам за блоками, що доступні користувачеві, а також з відкритою для нього інформацією (відповідно до налаштованих прав) і містити актуальну інформацію за минулий день / тиждень. Інформація може надходити в xslx-форматі або може бути включена до тексту електронного листа. Агреговані дані повинні мати посилання, перейшовши за якими користувач буде направлений на відповідний звіт в Системі.  

  1. Конструктор звітів

Компонент «Конструктор звітів» повинен дозволити користувачеві самостійно формувати довільні звіти в потрібних розрізах без залучення розробників та інших спеціалістів. На стартовій сторінці має бути представлений список звітів, які були додані користувачем (Рис. 71. Програмний компонент «Конструктор звітів»). Також мають бути доступними наступні функції:

Користувачеві повинна бути надана можливість створення нового шаблону звіту. Рис. 71. Програмний компонент «Конструктор звітів»
Користувачеві повинна бути надана можливість редагувати будь-який шаблон звіту. В шаблоні повинна бути надана можливість обрати необхідні дані, встановити параметри їх відображення і видимості у звіті. Також повинна бути реалізована функція вибору типу представлених даних, а саме: задати період, накласти за допомогою фільтрів обмеження на будь-яке поле, змінити формат даних. Після того, як користувач обере необхідні параметри, у нього має бути можливість зазначити назву звіту і. в подальшому, зберегти його або відмінити дії (Рис. 72).  Після збереження шаблону звіту він повинен відображатись у списку реєстрів. Після збереження звіт можна буде редагувати, копіювати, видалити або поділитися ним з іншими користувачами. При відкритті збереженого звіту у користувача повинна бути можливість переглянути дані за раніше встановленими параметрами, а також зберегти звіт у форматі Excel (Рис. 73).                         
Рис. 72. Шаблон для створення звіту в «Конструктор звітів»

Рис. 73. Відображення звіту, що був створений у «Конструкторі звітів»

5.3.10   Вимоги до розробки мобільних додатків для роботи з Системою на планшетних пристроях під управлінням операційних систем Android та IOS

Мобільні додатки, що буде розроблено, повинні мати назву «Звітність м. Києва. SmartBI» – пілотна назва. В мобільних додатках повинно бути забезпечено функціонування всіх компонентів системи для наступних версій операційних систем:

Для налаштування клієнтської частини мобільного додатку повинні використовуватися C#, Xamarin Forms для відображення вмісту веб-сайтів на HTML5 із застосуванням СSS3 і забезпечення підтримки JavaScript. Додатки повинні забезпечувати підтримку REST (Restfull) API. Розроблені додатки повинні мати необхідні засоби автоматизованого контролю цілісності даних і несуперечності збереженої інформації, персоніфікації даних, створених різними користувачами, забезпечувати ведення журналу операцій, які виконуються. Екранні форми в мобільних додатках на планшетних пристроях повинні бути відображені у альбомному форматі та забезпечувати принципи зручності користування. До уваги треба прийняти таке: ширина екрану у портретному режимі планшетного пристрою значно менша ніж в альбомному, тому у Користувача не буде можливості переглядати графіки, діаграми та звіти, що мають значний об’єм даних. Це може зіпсувати враження про продукт і знизити його цінність для Користувача. Коректна робота додатку повинна бути забезпечена на планшетних пристроях з роздільною здатністю екрану не менше ніж 1024×768 px (точок). Схема розміщення компонентів Системи для мобільних планшетних додатків наведена на Рис. 74. Сервер Бази даних обмінюється інформацією з сервером Застосунків через протокол TCP/IP. На сервері Застосунків зберігаються основні конфігурації додатку. За допомогою Веб-серверу дані адаптуються для відображення у мобільному додатку. Користувач може переглянути дані на планшетному мобільному пристрої завдяки підключенню до мережі інтернет через протокол HTTPs over TLS. Для забезпечення роботи додатку у користувача має бути стабільне швидкісне підключення до мережі інтернет. Рис. 74. Концептуальна блок-схема розміщення компонентів мобільного додатку для планшетних пристроїв Мобільний додаток, розроблений для роботи під управлінням операційної системи Android повинен бути розміщений в магазині Google Play за посиланням https://play.google.com/store/. Мобільний додаток, розроблений для роботи під управлінням операційної системи iOS повинен бути розміщений в магазині App Store за посиланням https://www.apple.com/ios/app-store/. Користувач повинен мати можливість завантажити додаток на мобільний планшетний пристрій, встановити його та, за необхідністю, видалити. Після встановлення додатку на мобільному планшетному пристрої неавторизованому користувачеві мають бути доступні для перегляду три звіти. Приклад екранної форми для неавторизованого користувача наведено на Рис. 75. Рис. 75. Загальнодоступні звіти додатку «Звітність м. Києва. SmartBI» для неавторизованого користувача Користувач повинен мати можливість авторизуватись, обравши піктограму  у лівому верхньому кутку додатку. Для авторизації необхідно ввести логін та пароль, після чого необхідно натиснути кнопку «Увійти». Приклад екранної форми авторизації користувача наведено на Рис. 76. Рис. 76. Вікно авторизації додатку «Звітність м. Києва SmartBI» Після авторизації повинен бути виконаний перехід до екранної форми головного меню, яка містить всі доступні користувачеві розділи звітності. Приклад екранної форми головного меню наведено на Рис. 77.
Рис. 77. Відображення головного екрану додатку «Звітність м. Києва. Smart BI»
Наповнення та відображення всіх розділів з інформаційними панелями для мобільних додатків повинно бути ідентичним до розділів, описаних для веб додатку, проте інформація має бути представлена відповідно до розміру екрану планшетних пристроїв із збереженням читабельності тексту (Рис. 78). Рис. 78. Приклад відображення звіту в додатку «Звітність м. Києва. SmartBI» Залежно від ролі користувача має бути реалізований доступ до наступних звітів:

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

 

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

6.1.         Загальний перелік програмного забезпечення

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

6.2.         Системне та прикладне програмне забезпечення

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

6.3.                 Схема розміщення компонентів на серверному обладнанні

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

Дані надходять у Систему у вигляді аналітичних вибірок даних (таблиць, що вивантажуються) із зовнішніх ресурсів на шлюзовий сервер або відразу на Сервер баз даних, залежно від способу отримання даних. Процедури оновлення даних з завданою регулярністю підключаються до шлюзового серверу, перевіряють повноту даних, обробляють, перетворюють та завантажують їх на сервер баз даних Системи. Запити із зовнішніх джерел до резервного шлюзового серверу надходять за протоколом SFTP. Від резервного шлюзового серверу передаються запити до Серверу баз даних по протоколу SQL Server Integration Services. Також до Серверу баз даних запити можуть надходити із зовнішніх джерел через API по протоколу TCP/IP. Система забезпечує обмін даними між основним та резервним майданчиком, зокрема данні на Сервері баз даних мають бути ідентичними на обох майданчиках. Звернення користувачів через інтернет надходять на основний майданчик, зокрема на сервер балансування, що відповідно розподіляє навантаження між двома майданчиками і далі направляє на сервер застосувань. Сервер застосувань звертається до баз даних за отриманням необхідних даних. На основному майданчику також знаходиться Сервер моніторингу, підключений до кожного із серверів для перевірки їх доступності. Сервер моніторингу, за необхідності, передає інформацію до серверу балансування, куди можна направити навантаження. Така система забезпечує безперебійний доступ користувачів до застосунку.

7.   ВИМОГИ ДО СКЛАДУ І ЗМІСТУ ПОСЛУГ З ПІДГОТОВКИ ОБ’ЄКТУ АВТОМАТИЗАЦІЇ ДО ВВОДУ СИСТЕМИ В ДІЮ

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



8.               КАЛЕНДАРНИЙ ПЛАН НАДАННЯ ПОСЛУГ



з/п
Назва етапу Термін Результат
1 Формування вимог і розробка технічного завдання:

·       Розробка Технічного завдання на розвиток ІТС «Звітність»
20 робочих днів з дати отримання письмової заявки від Замовника Технічне завдання.





2 Розробка нових програмних компонентів:

·       Розробка нових програмних компонентів ІТС «Звітність»
30 робочих днів з дати виконання     п. 1 та отримання письмової заявки від ЗамовникаПрограмне забезпечення нових програмних компонентів ІТС «Звітність», розгорнуте на площадці Замовника.

Загальний опис рішення (в частині оновлення).

Програма та методика попередніх випробувань.

Протокол попередніх випробувань.

Акт впровадження в дослідну експлуатацію.
3 Дослідна експлуатація, розробка документації:

·       Впровадження нових програмних компонентів ІТС «Звітність» в дослідну експлуатацію;

·       Проведення дослідної експлуатації;

·       Розробка документації;

·       Навчання користувачів замовника.
20 робочих днів з дати виконання     п. 2 та отримання письмової заявки від ЗамовникаІнструкція з формування та ведення бази даних ( в частині оновлення).

Загальна інструкція по налагодженню рішення (в частині оновлення).

Керівництво Користувача (в частині оновлення).

Керівництво адміністратора ( в частині оновлення).

Звіт з навчання.

Програма та методика дослідної експлуатації.

Протокол дослідної експлуатації.


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

9.              ГАРАНТІЙНА ТА ПІСЛЯГАРАНТІЙНА ПІДТРИМКА

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

СПИСОК ТАБЛИЦЬ

Таблиця 1. Структура даних довідника «Реєстр підприємств». 50 Таблиця 2. Структура даних довідника форм власності (HBPROPERTY) 54 Таблиця 3. Структура даних довідника КОПФГ (HBOGRLEGAL) 54 Таблиця 4. Структура даних довідника видів діяльності (HBACTIVITY) 54 Таблиця 5. Структура даних довідника форм фінансування (HBFINANC) 54 Таблиця 6. Структура даних довідника «КОАТУ» (HBKOATUU) 55 Таблиця **7**. Структура даних довідника «КВЕД» (HBKVED) 55 Таблиця 8. Структура даних довідника «Галузь» (HBMPDEP) 55 Таблиця 9. Структура даних довідника «Підгалузь» (HBMPDIR) 55 Таблиця 10. Структура даних довідника «Органи управління» (MPBRANCH) 55 Таблиця 11. Структура вибірки даних, що формується на основі даних компоненту «Інтелектуальний центр реабілітації» програмного модулю «Соціальні послуги». 56 Таблиця 12. Структура таблиці “Заповнені декларації відповідно району та віку пацієнтів”. 58 Таблиця 13. Структура таблиці “Кількість лікарів відповідно до району міста”. 58 Таблиця 14. Структура таблиці “Кількість пацієнтів за віком та статтю”. 58 Таблиця 15. Структура таблиці “Інформація за записами до лікарів відповідно до спеціалізації”. 59 Таблиця 16. Структура таблиці “Кількість населення відповідно до району”. 59 Таблиця 17. Структура таблиці “Заповнені декларації відповідно району та віку пацієнтів”. 59 Таблиця 18. Структура таблиці “Заповнені декларації відповідно району та віку пацієнтів”. 60 Таблиця 19. Структура таблиці “Дані про відповідність руху транспорту відповідно до маршруту”. 60 Таблиця 20. Структура таблиці “Дані про відповідність руху транспорту відповідно до маршруту”. 60 Таблиця 21. Структура таблиці “Кількість транспорту, що не вийшла на маршрут”. 61 Таблиця 22. Детальний перелік звітів за компонентами. 61  

СПИСОК РИСУНКІВ

Рис. 1. Верхньорівнева загальна схема логіки побудови Системи. 18 Рис. 2. Трирівнева архітектура. 21 Рис. 3. Загальна схема розширення Системи у межах четвертої черги. 24 Рис. 4. Розширення підсистеми збереження даних. 26 Рис. 5. Загальна схема розширення підсистеми вітрин даних. 27 Рис. 6. Показники фінансової діяльності за фінансовою звітністю.. 75 Рис. 7. Показники фінансової діяльності за фінансовим планом. 77 Рис. 8. Приклад звіту «Перелік збиткових підприємств». 78 Рис. 9. Приклад звіту **«**Перелік прибуткових підприємств**».** 79 Рис. 10. Приклад звіту «Подання звітів». 80 Рис. 11 Приклад звіту «Стани організацій». 81 Рис. 12. Звіт про діяльність контакт-центрів 1551 та 1557. 82 Рис. 13. Звіт за основними показниками в сфері здоров`я. 83 Рис. 14. Звіт за зведеними показниками діяльності закладів дошкільної освіти. 84 Рис. 15. Звіт про фінансові результати діяльності міста. 85 Рис. 16. Звіт про роботу транспортних підприємств. 86 Рис. 17. Звіт про діяльність Національної поліції. 87 Рис. 18. Загальна кількість дітей в ЗНЗ. 88 Рис. 19. ЗНЗ за типами. 89 Рис. 20. Розподіл за балами ЗНО.. 90 Рис**.** 21. Основні показники. 91 Рис. 22. Статистична інформація. 92 Рис. 23. Кількість новобудов та кількість нових шкіл, відкритих у 2018 році 93 Рис. 24. Розподіл педагогічних працівників за віком. 94 Рис. 25. Топ 5 шкіл за часткою використаних бюджетних коштів. 95 Рис. 26. Кількість дітей в дитсадках. 96 Рис. 27. Черга та кількість вільних місць за віком. 97 Рис. 28. Черга та кількість вільних місць за районами. 98 Рис. 29. Кількість груп та середнє навантаження за віком. 99 Рис. 30. Основні показники діяльності закладів дошкільної освіти. 100 Рис. 31. Кількість дитсадків та навантаження. 101 Рис. 32. Топ 5 дитсадків за чергою.. 102 Рис. 33. Топ 5 дитсадків за навантаженням. 102 Рис. 34. Кількість пацієнтів на 1 лікаря та приріст декларацій. 104 Рис. 35. Відсоток декларацій. 104 Рис. 36. Кількість та структура пацієнтів. 105 Рис. 37. Звіт за даними декларацій, записом до лікаря та кількістю прийомів. 106 Рис. 38. Звіт по узагальненим даним записів до лікаря (частина 1) 107 Рис. 39. Звіт по узагальненим даним записів до лікаря (частина 2) 107 Рис. 40. Топ 5 спеціалізацій. 108 Рис. 41. Розподіл записів за каналами. 108 Рис. 42. Кількість звернень погодинно. 109 Рис. 43. Розподіл бригад за статусами. 110 Рис. 44. Звіт про звернення пацієнтів до швидкої допомоги. 111 Рис. 45. Сплеск викликів. 111 Рис. 46. Розподіл викликів. 112 Рис. 47. Час приїзду на виклик. 113 Рис. 48. Погодинна динаміка активності викликів. 114 Рис. 49. Сплеск викликів у порівнянні з попереднім періодом. 114 Рис. 50. Розподіл викликів. 115 Рис. 51. Розподіл викликів за часом приїзду. 115 Рис. 52. «% виїздів за викликом». 116 Рис. 53. Звернення пацієнтів до швидкої допомоги. 117 Рис. 54. Динаміка по тижням. 118 Рис. 55. Статистика за районами. 119 Рис. 56. Статистика за обраний період за типами злочину. 120 Рис. 57. ТОП 5 приростів звернень за обраний період. 121 Рис. 58. Погодинна динаміка. 122 Рис. 59. Аналіз маршрутів. 122 Рис. 60. Статуси РО.. 123 Рис. 61. Причини запізнення. 124 Рис. 62. Статистика за день. 125 Рис. 63 Приклад звіту "Звіт для аудиту" (частина 1) 126 Рис. 64. Приклад звіту "Звіт для аудиту" (частина 2) 127 Рис. 65. Приклад налаштування компоненту Зведена таблиця. 132 Рис. 66. Приклад зупинення виконання запиту. 133 Рис. 67. Приклад відображення інформації «дані на зараз». 134 Рис. 68. Приклад відображення інформації «динаміка даних». 134 Рис. 69. Приклад відображення іконки фільтру. 135 Рис. 70. Приклад відображення панелі фільтрів. 135 Рис. 71. Програмний компонент «Конструктор звітів». 137 Рис. 72. Шаблон для створення звіту в «Конструктор звітів». 139 Рис. 73. Відображення звіту, що був створений у «Конструкторі звітів». 140 Рис. 74. Концептуальна блок-схема розміщення компонентів мобільного додатку для планшетних пристроїв. 142 Рис. 75. Загальнодоступні звіти додатку «Звітність м. Києва. SmartBI» для неавторизованого користувача. 143 Рис. 76. Вікно авторизації додатку «Звітність м. Києва SmartBI». 144 Рис. 77. Відображення головного екрану додатку «Звітність м. Києва. Smart BI». 145 Рис. 78. Приклад відображення звіту в додатку «Звітність м. Києва. SmartBI». 146 Рис. 79. Схема розміщення компонентів на серверному обладнанні 150    

 

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

ЗмінаНомери аркушів (сторінок) Всього аркушів (сторінок) в документі

документа
Вх. № супровідного документа та датаПідпис і дата
Замінених ВведенихВилучених