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

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

Київ 2018
ЗМІСТ

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

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

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

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

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

1. ВИМОГИ ДО СИСТЕМИ.. 16

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

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

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

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

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

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

|


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

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

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

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

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

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

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

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


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

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

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

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

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

• Інформаційна панель для ролі «Київський міський голова»;
• «Освіта. ЗДО»;
• «Медицина. Helsi»;
• «Медицина. Швидка допомога Онлайн»;
• «Медицина. Швидка допомога Динаміка»;
• «Національна поліція. Кримінал»;
• «Транспорт. АТП-5»;
• «Комунальні підприємства»;
• «Звіт для Аудиту».

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

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

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

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

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

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

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

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

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

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

• Рішення Київської міської ради від 2 липня 2015 року № 654/1518 “Про затвердження Комплексної міської цільової програми “Електронна столиця” на 2015 - 2018 роки”;
• Рішення Київської міської ради від 28 липня 2016 року N 862/862 “Про внесення змін до Комплексної міської цільової програми “Електронна столиця” на 2015-2018 роки”, затвердженої рішенням Київської міської ради від 02 липня 2015 року № 654/1518;
• Закону України «Про інформацію»;
• Закону України «Про електронні документи та електронний документообіг»;
• Закону України «Про доступ до публічної інформації»;
• Закону України «Про захист інформації в інформаційно-телекомунікаційних системах»;
• Закону України «Про електронний цифровий підпис»;
• Закону України «Про захист персональних даних»;
• Постанови Кабінету Міністрів України від 04.02.1998 № 121 «Про затвердження переліку обов’язкових етапів робіт під час проектування, впровадження та експлуатації систем і засобів автоматизованої обробки та передачі даних;
• Постанови Кабінету Міністрів України від 12.04.2002 №522 «Про затвердження Порядку підключення до глобальних мереж передачі даних»;
• Постанови Кабінету Міністрів України від 10.09.2003 № 1433 «Про затвердження Порядку використання комп'ютерних програм в органах виконавчої влади»;
• Постанови Кабінету Міністрів України від 28.10.2004 № 1452 «Про затвердження Порядку застосування електронного цифрового підпису органами державної влади, органами місцевого самоврядування, підприємствами, установами та організаціями державної форми власності»;
• Постанови Кабінету Міністрів України від 29.03.2006 №373 «Про затвердження Правил забезпечення захисту інформації в інформаційних, телекомунікаційних та інформаційно-телекомунікаційних системах»;
• Рішення Київської міської ради від 2 липня 2015 року № 654/1518 «Про затвердження Комплексної міської цільової програми «Електронна столиця» на 2015 - 2018 роки»;
• НД ТЗІ 1.1-003-99. Термінологія в галузі захисту інформації в комп’ютерних системах від несанкціонованого доступу;
• НД ТЗІ 1.4-001-2000. Типове положення про службу захисту інформації в автоматизованій системі;
• НД ТЗІ 2.5-004-99. Критерії оцінки захищеності інформації в комп’ютерних системах від несанкціонованого доступу;
• НД ТЗІ 2.5-005-99. Класифікація автоматизованих систем і стандартні функціональні профілі захищеності оброблюваної інформації від несанкціонованого доступу;
• НД ТЗІ 3.6-001-2000. Технічний захист інформації. Комп’ютерні системи. Порядок створення, впровадження, супроводження та модернізації засобів технічного захисту інформації від несанкціонованого доступу;
• НД ТЗІ 3.7-001-99. Методичні вказівки щодо розробки технічного завдання на створення комплексної системи захисту інформації в автоматизованій системі;
• НД ТЗІ 3.7-003-05. Порядок проведення робіт із створення комплексної системи захисту інформації в інформаційно-телекомунікаційній системі;
• ДСТУ 3396.0-96 Захист інформації. Технічний захист інформації. Основні положення;
• ДСТУ 3396.2-97 Захист інформації. Технічний захист інформації. Терміни та визначення;
• ДСТУ 2873-94 Системи оброблення інформації. Програмування. Терміни та визначення;
• ДСТУ 2941-94 Системи оброблення інформації. Розроблення систем. Терміни та визначення;
• ДСТУ ISO/IEC 2382-4:2005 Інформаційні технології. Словник термінів. Частина 4. Організація даних;
• ДСТУ ISO/IEC 2382-17:2005 Інформаційні технології. Словник термінів. Частина 17. Бази даних;
• ДСТУ ISO/IEC 2382-9:2005 Інформаційні технології. Словник термінів. Частина 9: Обмін даними;
• ДСТУ 4302:2004 Інформаційні технології. Настанови щодо документування комп`ютерних програм (ISO/IEC 6592:2000, MOD);
• ДСТУ 4145:2002 Інформаційні технології. Криптографічний захист інформації. Електронний цифровий підпис, що ґрунтується на еліптичних кривих;
• ГОСТ 19.001-77. Єдина система програмної документації. Загальні положення;
• ГОСТ 19.101-77 (СТ СЗВ 1626-79). Єдина система програмної документації. Види програм і програмних документів;
• ГОСТ 19.102-77. Єдина система програмної документації. Стадії розробки;
• ГОСТ 19.103-77. Єдина система програмної документації. Позначення програм програмних документів;
• ГОСТ 19.104-78 (СТ СЗВ 2088-80). Єдина система програмної документації. Основні написи;
• ГОСТ 19.105-78 (СТ СЗВ 2088-80). Єдина система програмної документації. Загальні вимоги до текстових програмних документів;
• ГОСТ 19.201-78 (СТ СЗВ 1627-79). Єдина система програмної документації. Технічне завдання. Вимоги до змісту та оформлення;
• ГОСТ 19.202-78 (СТ СЗВ 2090-80). Єдина система програмної документації. Специфікація. Вимоги до змісту та оформлення;
• ГОСТ 19.301-79 (СТ СЗВ 3747-82). Єдина система програмної документації. Програма та методика випробувань. Вимоги до змісту та оформлення;
• ГОСТ 19.507-79 (СТ СЗВ 2091-80). Єдина система програмної документації. Відомість експлуатаційних документів;
• ГОСТ 19.701-90 (ИСО 5807-85). Єдина система програмної документації. Схеми алгоритмів, програм, даних та систем;
• ГОСТ 19781-90 Програмне забезпечення систем обробки інформації. Терміни та визначення;
• ГОСТ 34.003-90. Інформаційна технологія. Комплекс стандартів на автоматизовані системи. Автоматизовані системи. Терміни та визначення;
• ГОСТ 34.201-89. Інформаційна технологія. Комплекс стандартів на автоматизовані системи. Види, комплектність і позначення документів при створенні автоматизованих систем;
• ГОСТ 34.601-90. Інформаційна технологія. Комплекс стандартів на автоматизовані системи. Автоматизовані системи. Стадії створення;
• ГОСТ 34.602-89. Інформаційна технологія. Комплекс стандартів на автоматизовані системи. Технічне завдання на створення автоматизованої системи;
• ГОСТ 34.603-92. Інформаційна технологія. Види випробувань автоматизованих систем;
• РД 50-34.698-90. Методичні вказівки. Інформаційна технологія. Комплекс стандартів і керівних документів на автоматизовані системи. Автоматизовані системи. Вимоги до змісту документів;
• РД 50-682-89. Методичні вказівки. Інформаційна технологія. Комплекс стандартів і керівних документів на автоматизовані системи. Загальні положення.
• ДК 010-98 «Державний класифікатор управлінської документації»;
• ДСТУ ISO/IEC 12207:2016 «Інженерія систем і програмного забезпечення. Процеси життєвого циклу програмного забезпечення».

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

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

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

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

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

• Інформаційна панель для ролі «Київський міський голова»;
• «Освіта. ЗДО»;
• «Медицина. Helsi»;
• «Медицина. Швидка допомога Онлайн»;
• «Медицина. Швидка допомога Динаміка»;
• «Національна поліція. Кримінал»;
• «Транспорт. АТП-5»;
• «Комунальні підприємства»;
• «Звіт для Аудиту».

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

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

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

• дані каталогу облікових об’єктів, прикладні атрибутивні та інші дані;
• службові дані (нормативно-довідникові дані та класифікатори, користувачі системи, журнали аудиту тощо).

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

• автоматизованої адаптації системи при зміні вимог до аналітики;
• інтеграції модулів системи у програмну платформу ІТС «Звітність»;
• інтеграції систем, що розробляються, з іншими інформаційними системами та програмними продуктами.

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

• Microsoft Windows Server 2012 R2;
• Microsoft SQL Server 2016 Standard Edition with Data Tools Business Intelligence для служб Analysis Services, Integration Services и Reporting Services;
• Oracle Express 12g.

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

• HTTP-сервер, зворотний проксі-сервер та TCP проксі-сервер загального призначення з підтримкою SSL/TLS Termination – Nginx для балансування навантаження на Систему.
• ETL-додаток – це комплексне рішення SQL Server Integration Services, за допомогою якого реалізуються процеси вилучення, перевірки, перетворення і завантаження даних з джерел.
• Сервер БД, що являє собою промислову систему управління базами даних. На даному сервері зберігаються НДІ, область тимчасового і постійного зберігання даних, агрегати даних. Реалізована система розмежувань прав доступу на рівні об'єктів і записів в таблицях. В якості серверів БД будуть використані наступні системи управління базами даних: Microsoft SQL Server 2016 та Oracle Express Edition 12g;
• Сервер застосувань – продукт, що забезпечує підтримку промислової інфраструктури бізнес-застосувань. Включає в себе низку додатків, що забезпечують:
• стандартні підходи до організації служб каталогів, централізовані методи організації;
• розгортання сервісів розробки додаткових застосувань;
• розгортання сервісів аналізу і звітності.
• Засоби адміністрування і розробки – Microsoft Management Studio, призначений для адміністрування системи ETL, баз даних, сервера застосувань (Microsoft Internet Information Services Manager) і розробки звітності (Microsoft Analysis and Reporting Services).
• Клієнтські місця користувачів, що представляють собою автоматизовані робочі місця у вигляді веб-інтерфейсу в межах тонкого клієнту (Інтернет-оглядачі останніх та передостанніх версій Edge, Internet Explorer, Google Chrome, Mozilla Firefox та Safari) та у вигляді інтерфейсів мобільних додатків (для останніх та передостанніх версій iOS та Android).

          Трирівнева архітектура будується з 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 дозволяє максимально збільшити доступність користувацьких баз даних. Група доступності підтримує набір первинних баз даних читання і запису і від одного до чотирьох наборів відповідних вторинних баз даних. Крім того, бази даних-одержувачі можна зробити доступними тільки для читання або для деяких операцій резервного копіювання. Застосовані рішення з побудови інформаційної системи забезпечуватимуть можливості:

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

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

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

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

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

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

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

• Імпортування статистичних даних з інформаційних систем «Програмний модуль «Соціальні послуги», «Модуль «Фінансова звітність» ІТС «Звітність», «Електронна медична система Helsi», «Інформаційно-аналітична система «Єдиний медичний простір», «Автоматизована система обліку транспортної роботи» (АСОТР) шляхом відправлення запитів до баз даних вказаних систем, а також використання уніфікованих API (Aapplication Pprogramming iInterface) та мови розмітки XML (Extensible Markup Language) з одночасним забезпеченням цілісності та достовірності даних, що надходять з цих систем.
• Контролювання надходження поточної статистичної звітності. Задача включає формування звітності щодо контролю надходження даних з інформаційних систем, а також функціональні можливості, які дозволяють вчасно інформувати про ці надходження користувачів (нагадування).
• Формування звітності за поточними статистичними даними, які надійшли від інформаційних систем.

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

• забезпечує формування інформаційно-аналітичної звітності за допомогою інтуїтивно зрозумілого користувачеві інтерфейсу;
• підтримує протокол доступу SOAP (Simple Object Access Protocol) за допомогою технології Web Services;
• забезпечує збереження отриманих даних в оперативній пам’яті, а також їх обробку в штатному режимі, що допомагає прискорити доступ до них;
• підтримує роботу з базами даних, заснованих на реляційній моделі даних;
• підтримує роботу з багатопроцесорною архітектурою баз даних;
• реалізує SQL (Structured Query Language), який є сумісним зі стандартом SQL:2003, що доповнений SQL:2008;
• підтримує стандарт Open DataBase Connectivity для баз даних;
• підтримує роботу з базами даних, що мають вбудовані засоби контролю цілісності отриманих даних;
• підтримує роботу з базами даних, що мають вбудовані засоби резервного копіювання отриманих даних;
• забезпечує ефективне функціонування з транзакційними та з аналітичними додатками одночасно;
• будується виключно на основі високопродуктивної системи управління базами даних, яка має високий рівень масштабування для ефективної одночасної роботи великої кількості користувачів з великими об’ємами даних;
• забезпечує захист отриманих даних у процесі їх збереження, а також у процесі передачі інформації;
• підтримує роботу з базою даних, що має вбудовані можливості дворівневого збереження даних та їх розділенням на «гарячі» та «холодні» дані в оперативній пам’яті та на дисковому просторі відповідно;
• надає інтегровані дані, які використовуються для крос-функціонального аналізу;
• виключає наявність надлишкових або несумісних даних і помилок;
• забезпечує швидкий та ефективний доступ до достовірних даних;
• забезпечує надійний та якісний інструмент, за допомогою якого інтегруються дані різних структур;
• забезпечує можливість масштабування;
• відповідає найвищим вимогам до продуктивності.

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

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

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

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

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

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

• має дійсний експертний висновок Державної служби спеціального зв'язку та захисту інформації України щодо відповідності вимогам нормативних документів системи криптографічного захисту інформації;
• реалізує наступні функції:
• захист трафіку на рівні автентифікації/шифрування мережевих пакетів по протоколах IPsec AH та/або IPsec ESP;
• пакетну фільтрацію трафіку з використанням інформації в полях заголовків мережевого і транспортного рівнів;
• контекстну фільтрацію для протоколів TCP і FTP;
• класифікацію та маркування трафіку;
• реалізацію заданого протоколу взаємодії (автентифікацію та/або захист трафіку) для кожного захищеного з'єднання, доступ в заданому захищеному режимі тільки для зареєстрованих партнерів по взаємодії;
• регульовану стійкість захисту трафіку;
• підтримку NAT Traversal Encapsulation;
• маскування топології сегмента мережі, що захищається (тунелювання трафіку);
• підтримку списку відкликаних сертифікатів (CRL – Certificate Revocation List);
• реєстрацію подій;
• надання статистики із використанням протоколів SNMP v.1, v.2c;
• дистанційне та локальне налаштування (за допомогою командної строки або із використанням графічного інтерфейсу);
• підтримку сервісів QoS;
• використовує алгоритм шифрування ДСТУ ГОСТ 28147:2009 у режимі гамування зі зворотнім зв’язком;
• забезпечує пропускну здатність у режимі шифрування для пакетів UDP та ТСР – не менш 1600 Мбіт/сек.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• локальних в межах системи;
• відомчих;
• загальнодержавних;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. Коректне типізоване відображення (сумісність) інформації в наперед останніх версіях на дату початку надання послуг за етапом згідно календарного плану найбільш популярних веб-браузерів:

• Chromе;
• Opera;
• Mozilla Firefox;
• Microsoft Internet Explorer;
• Microsoft Edge.

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

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

• 2 сервери баз даних з мінімальною апаратною конфігурацією сервера:
• 8-ядерний 64-бітний процесор;
• оперативна пам’ять об’ємом 32 Гб;
• жорсткий диск об’ємом 400 Гб;
• 2 сервери застосунків з мінімальною апаратною конфігурацією:
• 4-ядерний 64-бітний процесор;
• оперативна пам’ять об’ємом 32 Гб;
• жорсткий диск об’ємом 400 Гб;
• Сервер обробки автентифікації ЕЦП з мінімальною конфігурацією:
• 4-ядерний 64-бітний процесор;
• Оперативна пам’ять об’ємом 4 Gb;
• жорсткий диск об’ємом 100 Gb;
• Сервер балансування навантаження і web-proxy:
• 2-ядерний 64-бітний процесор;
• оперативна пам’ять об’ємом 2 Gb;
• жорсткий диск об’ємом 10 Gb.

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

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

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

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

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

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

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

• Подача звітності;
• Підприємства;
• Аналітика.

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

• Конструктор звітів на основі даних Департаменту соціальної політики КМДА;
• Конструктор звітів на основі даних Київського міського центру реабілітації дітей з інвалідністю.
• Налаштовані на основі конструктора звіти:
  • Статистика за кількістю прийомів за період;
  • Статистика за кількістю прийомів за певний період в розрізі спеціалізації фахівця, фахівця, кабінету, наявності направлення від Департаменту соціальної політики;
  • Статистика за категорією пацієнтів на реабілітації;
  • Статистика за кількістю послуг (за типами спеціалізацій) за період;
  • Статистика за технічними засобами реабілітації;
  • Статистика за завантаженням кабінетів за певний період в розрізі спеціалізації лікарів;
  • Статистика за анкетами PEDI;
  • Звіт про надані за певний період послуги;
  • Статистика за кількістю та статусами направлень.

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

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

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

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

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

• Основний режим.
• Режим адміністрування.
• Режим регламентного обслуговування.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• укладає Угоду (не фінансову) про нерозголошення (Non-disclosure agreement) (шаблон документу надається Замовником);
• проводить навчання та надає Звіт з навчання користувачів (у межах одного з етапів за попереднім погодженням із Замовником).

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

• Можливість поділу повноважень для доступу до інформації:
  • Рівень 0 («Мер») – рівень формування комплексу показників для керівництва КМДА. Відображаються показники по всьому місту.
  • Рівень 1 («Заступник») – рівень формування комплексу показників на основі інформації департаментів, за які відповідають заступники.
  • Рівень 2 («РДА») – рівень формування комплексу показників для керівників районних служб міста.
  • Рівень 3 («Мешканець») – рівень звітів, до яких відкрито вільний доступ.
• Поділ формування звітності на наступні компоненти:

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

• Подача звітності;
• Підприємства;
• Аналітика.

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

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

1. Інформаційні панелі департаментів КМДА:

• Інформаційна панель для ролі «Київський міський голова»;
• «Освіта. ЗДО»;
• «Медицина. Helsi»;
• «Медицина. Швидка допомога Онлайн»;
• «Медицина. Швидка допомога Динаміка»;
• «Національна поліція. Кримінал»;
• «Транспорт. АТП-5»;
• «Комунальні підприємства»;
• «Звіт для Аудиту».

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• щогодини доповнення новими даними;
• щотижня оновлення усіх даних.

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

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

• щогодини доповнення новими даними;
• щотижня оновлення всіх даних.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Можливість доступу до інформаційної панелі для мешканців міста, керівників департаментів КМДА та РДА для отримання відкритої інформації про установи, підпорядковані КМДА, та про динаміку надання ними обов’язкової фінансової звітності.
• Можливість формування аналітичних звітів на основі даних обов’язкової фінансової звітності.
• Можливість формування звітів за обраними фільтрами.
• Можливість експорту друкованої версії звітів у форматі PDF та XLSX.

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

• Подача звітності;
• Підприємства;
• Аналітика.

Джерела даних: Див. п. 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 блоки:

• загальна інформація;
• керівництво;
• контактна інформація.

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

• ЄДРПОУ;
• повна назва;
• форма фінансування;
• статус установи;
• КОПФГ (Організаційно-правова форма);
• основний вид діяльності за КВЕД;
• підпорядкування (департамент або РДА);
• форма власності;
• дата державної реєстрації;
• орган, що видав свідоцтво державної реєстрації;
• розмір статутного капіталу;
• примітка.

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

• ПІБ керівника;
• посада;
• підстава призначення;
• строк дії керівника;
• телефон керівника;
• ПІБ головного бухгалтера;
• телефон бухгалтера.

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

• юридична адреса;
• фактична адреса;
• телефон;
• електронна адреса.

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

• KM110011 1-м, 2-м. Фінансовий звіт суб'єкта малого підприємництва;
• KM301011 1-ПВ. Звіт з праці (місячна);
• KM210110 Ф №1-Б Звіт про фінансові результати і дебіторську та кредиторську заборгованість;
• KM104008 Ф4. Звіт про власний капітал;
• KM105207 Ф5-ІІ Інформація про наявність і рух основних засобів (в тис грн);
• KM300308 Звіт про виконання фінансового плану підприємства.

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

• KM110011 1-м, 2-м. Фінансовий звіт суб'єкта малого підприємництва;
• KM301011 1-ПВ. Звіт з праці (місячна);
• KM210110 Ф №1-Б Звіт про фінансові результати і дебіторську та кредиторську заборгованість;
• KM104008 Ф4. Звіт про власний капітал;
• KM105007 Ф5. Примітки до річної звітності (заповнений розділ 2 Інформація про наявність і рух основних засобів (в тис грн));
• KM300308 Звіт про виконання фінансового плану підприємства;
• KMP00002 Паспорт підприємства;
• KMRPKP01 Розрахунок премії керівника комунального підприємства, установи, організації територіальної громади міста Києва.

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

• KM100113 Ф1. Баланс;
• KM100213 Ф2. Звіт про фінансові результати (в тисячах);
• KM301011 1-ПВ. Звіт з праці (місячна);
• KM210110 Ф №1-Б Звіт про фінансові результати і дебіторську та кредиторську заборгованість;
• KM104008 Ф4. Звіт про власний капітал;
• KM105207 Ф5-ІІ Інформація про наявність і рух основних засобів (в тис грн);
• KM300308 Звіт про виконання фінансового плану підприємства.

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

• KM100113 Ф1. Баланс;
• KM100213 Ф2. Звіт про фінансові результати (в тисячах);
• KM210110 Ф №1-Б Звіт про фінансові результати і дебіторську та кредиторську заборгованість;
• KM100309 Ф3. Звiт про рух грошових коштiв (за прямим методом);
• KM104008 Ф4. Звіт про власний капітал;
• KM105007 Ф5. Примітки до річної звітності;
• KM300308 Звіт про виконання фінансового плану підприємства;
• KM105207 Ф5-ІІ Інформація про наявність і рух основних засобів (в тис грн);
• KM301011 1-ПВ. Звіт з праці (місячна);
• KMP00002 Паспорт підприємства;
• KMRPKP01 Розрахунок премії керівника комунального підприємства, установи, організації територіальної громади міста Києва.

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

• KMFINB01 Форма №1-дс Баланс;
• KMFINR01 Форма №2-дс Звіт про фінансові результати;
• KM105207 Ф5-ІІ Інформація про наявність і рух основних засобів (в тис грн);  
• Ф5-дс Примітки до річної фінансової звітності (згідно проекту Мінфіну від 06.11.2017 року - за рік 2017;
• KM301011 1-ПВ. Звіт з праці (місячна).

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. Звіт про фінансові результати діяльності державних підприємств.

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

• прибуток підприємства;
• чистий прибуток підприємства;
• витрати підприємства.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• кількість зафіксованих злочинів;
• кількість розкритих злочинів;
• кількість розкритих злочинів за 2018 рік;
• кількість справ, що були розслідувані.

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

• при виборі блоку ЖКГ має відобразитись інформаційна панель «Загальна інформація по місту»;
• при натисканні курсором миші на блок «Швидка» повинна відобразитись інформаційна панель «Швидка. Динаміка»;
• натискання курсором миші на блок «Освіта» повинно визивати відображення інформаційної панелі «ЗДО»;
• при натисканні курсором миші на блок «Транспорт» повинна відобразитись інформаційна панель «КиївПастранс. Головна»

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

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

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

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

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

• 1 - 4 класи;
• 5 - 9 класи;
• 10 - 12 класи.

Окрім того, у звіті має бути представлена інформація про кількість дітей, що відвідують або не відвідують групу продовженого дня (ГПД). Інформація про кількість учнів повинна відображатись при наведенні курсору миші на відповідну частину діаграми. Звіт повинен мати заголовок «Загальна кількість дітей в ЗНЗ». Під назвою має бути відображена загальна кількість дітей, що навчаються в ЗНЗ міста Києва. Звіт має бути представлений у вигляді подвійної кругової діаграми, де внутрішня частина надає інформацію про кількість учнів по класам (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. Звіт про категорії педагогів відповідно до віку.

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

• до 30 років;
• 31 - 41 рік;
• 41 - 50 років;
• 51 - 55 років;
• більше 60 років.

Приклад звіту «Розподіл педагогічних працівників за віком» наведено на Рис. 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 дитсадків за навантаженням При натисканні курсором миші на назву стовпця повинно відбуватися сортування або в алфавітному порядку, або у зворотному. При сортуванні стовпця з цифровими даними інформація повинна бути відображена у порядку зростання або спадання.

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

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. Звіт про час прибуття швидкої допомоги на виклик

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

• до 10 хв;
• 10 -20 хв;
• понад 20 хв.

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

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

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

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

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

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

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

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

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

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

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

• до 10 хв;
• 10 -20 хв;
• понад 20 хв.

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

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

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

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

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

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

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

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

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

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

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

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

• Голосіївський;
• Дарницький;
• Деснянський;
• Дніпровський;
• Оболонський;
• Печерський;
• Подільський;
• Святошинський;
• Солом’янський;
• Шевченківський;
• ЛВ Річпорту (Лінійне відділення Річпорту);
• УО Метрополітену.

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

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

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

• крадіжка;
• крадіжка з квартири;
• шахрайство;
• обіг наркотиків;
• крадіжки з автомобілів;
• пограбування;
• кишенькові крадіжки;
• незаконне заволодіння транспортним засобом;
• розбій;
• навмисні вбивства;
• зґвалтування;
• НТТУ – навмисні тяжкі тілесні ушкодження;
• навмисні тяжкі тілесні ушкодження із смертельними наслідками;
• вимагання;
• позбавлення волі;
• ДТП зі смертельними наслідками;
• хуліганство;
• злочини у сфері службової діяльності;
• незаконне поводження зі зброєю.

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

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

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

• Тип злочину - злочини, кількість яких виросла за обраний період;
• Приріст - відображає різницю між кількістю злочинів за обраний період у порівнянні з попереднім аналогічним періодом;
• % приросту – показує, на скільки відсотків зросла кількість злочинів за обраний період у порівнянні з поперед
• нім.

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

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

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

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

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

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

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

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

• на маршруті;
• обід;
• резерв;
• ремонт;
• списання.

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

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

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

• затори;
• з технічної причини;
• з вини водія;
• інше.

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

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

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

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

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

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

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

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

• Рік – список містить тільки ті роки, за які надавалась звітність хоча б одним підприємством. При відкритті форми фільтр повинен автоматично приймати значення поточного року.
• Період – містить значення: «1 квартал», «2 квартал», «3 квартал» та «Рік». Для обраного року в список потрапляють лише ті періоди, за які надавалась звітність хоча б одним підприємством.
• Підпорядкування – містить значення: «Всі», «Місто», «Район». Якщо користувач обирає «Район», то в звіт повинні потрапити районні органи управління (районні державні адміністрації). При обранні значення «Місто» звіт повинен містити департаменти КМДА. При обранні значення «Всі» в звіт потрапляють всі органи управління. Це значення є значенням за замовчуванням. Користувач може обрати тільки одне значення зі списку.
• Орган управління – містить перелік всіх департаментів КМДА та районних державних адміністрацій з довідника «Органи управління», а також значення «Всі», яке повинно відображатися на початку списку і є значенням за замовчуванням. У цьому фільтрі користувач має можливість обрати декілька значень для відображення в звіті.
• Фінансування – містить значення з довідника «Фінансування», а саме «Всі», «Бюджет», «Госпрозрахунок». Значення «Всі» є значенням за замовчуванням. Користувач може обрати тільки одне значення зі списку.
• Власність – містить значення з довідника «Форми власності», а саме «Всі», «Державна власність», «Загальнодержавна власність», «Комунальна власність».

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

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

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

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

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

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

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

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

• Назва реабілітаційної установи;
• Рік;
• Місяць;
• Тиждень;
• Дата;
• Кількість прийомів.

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

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

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

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

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

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

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

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

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

• назва реабілітаційної установи;
• вікова категорія пацієнта:
• ранній вік (0-2 роки);
• дошкільний вік (2-7років);
• шкільний вік (7-14 років);
• підлітковий вік (14-18 років);
• молодіжний вік (18-35 років);
• дорослий вік (35-60 років);
• пенсійний вік (від 60 років);
• тривалість курсу реабілітації:
• до 1 міс.;
• 1-3 міс;
• 3-6 міс;
• 6-12 міс;
• більше 12 міс;
• діагноз;
• пільгова група;
• район проживання;
• кількість пацієнтів.

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

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

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

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

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

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

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

• назва реабілітаційної установи;
• вид ТЗР;
• назва ТЗР;
• вікова група пацієнта;
• ознака виконання заявки;
• кількість заявок на оренду.

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

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

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

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

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

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

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. Відображення звіту, що був створений у «Конструкторі звітів»

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

• Android – не нижче 8 версії;
• IOS – не нижче 10 версії.

Для налаштування клієнтської частини мобільного додатку повинні використовуватися 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» Залежно від ролі користувача має бути реалізований доступ до наступних звітів:

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

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

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

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

• FrontEnd:
  • Angular 2
  • Bootstrap
  • NodeJS
  • Highcharts
  • Maps
  • Програмний комплекс ІАС МАЙНО
  • C#
  • Xamarin Forms
• BackEnd:
  • Microsoft Internet Information Services 7.5
  • .Net Framework 4.6.1
  • Net
• СКБД:
  • Microsoft SQL Server 2016 Enterprise Edition
• Операційні системи
  • Microsoft Windows Server 2012 R2;
  • IOS від 10.0
  • Android0
• Http та Https проксі сервер
  • Nginx
• IDE для налаштування та підтримки
  • Microsoft Internet Information Services 7.5 Manager
  • Microsoft SQL Server Data Tools
  • Microsoft SQL Management Studio

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

• Сервер додатків:
  • CPU – 4 ядра
  • RAM – 8 Gb
  • HDD – 80 Gb
• Сервер баз даних:
  • CPU – 8 ядер
  • RAM – 32 Gb
  • HDD – 400 Gb
• Ресурс для сервера обробки автентифікації ЕЦП:
  • CPU – 4 ядра
  • RAM – 4 Gb
  • HDD – 100 Gb.

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

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

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

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

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

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

Виконавець забезпечує гарантійну (технічну) підтримку створеного в результаті надання послуг програмного забезпечення протягом 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