rest_documentconversion_latest_conversion_thumbnail_29039379_1

  ТЕХНІЧНЕ ЗАВДАННЯ ДООПРАЦЮВАННЯ ІНФОРМАЦІЙНОЇ СИСТЕМИ «РЕЄСТР ТЕРИТОРІАЛЬНОЇ ГРОМАДИ МІСТА КИЄВА» 3 черга 37770359.184154.4363.ТЗ На ____ аркушах діє з «_____»_______________2019 року    

Київ  2019 ЗМІСТ ПЕРЕЛІК ТЕРМІНІВ ТА СКОРОЧЕНЬ.. 5 1 ЗАГАЛЬНІ ВІДОМОСТІ 10 1.1 Повне найменування доопрацювань та їх умовне позначення. 10 1.2 Шифр теми або шифр (номер) договору. 10 1.3 Найменування установ Виконавця і Замовника, їх реквізити. 10 1.4 Перелік документів, на підставі яких здійснюються доопрацювання, ким і коли затверджені ці документи. 10 1.5 Планові терміни початку та закінчення виконання робіт з доопрацювання Системи  14 1.6 Відомості про джерела і порядок фінансування послуг. 14 1.7 Порядок оформлення і пред’явлення Замовникові наданих послуг. 15 2 ПРИЗНАЧЕННЯ ТА ЦІЛІ ДООПРАЦЮВАННЯ СИСТЕМИ.. 16 2.1 Призначення доопрацювань. 16 2.2 Мета здійснення доопрацювань. 16 3 ХАРАКТЕРИСТИКИ ОБ’ЄКТІВ АВТОМАТИЗАЦІЇ 17 3.1 Відомості про об’єкт автоматизації 17 3.2 Умови експлуатації і характеристики навколишнього середовища. 17 4 ВИМОГИ ДО ДООПРАЦЮВАНЬ СИСТЕМИ.. 18 4.1 Вимоги до доопрацювань в цілому. 18 4.1.1 Загальні вимоги. 18 4.1.2 Обмеження на побудову доопрацювань Системи. 18 4.1.3 Принципи побудови доопрацювань Системи. 18 4.1.4 Вимоги до структури і функціонування доопрацювань. 20 4.1.5 Вимоги до чисельності, кваліфікації та режиму персоналу. 21 4.1.6 Вимоги до показників призначення. 22 4.1.7 Вимоги до надійності 22 4.1.8 Вимоги з техніки безпеки. 22 4.1.9 Вимоги до ергономіки і технічної естетики. 23 4.1.10 Вимоги до експлуатації і технічного обслуговування, ремонту та зберігання компонентів доопрацювань. 25 4.1.11 Вимоги до захисту інформації від несанкціонованого доступу. 26 4.1.12 Вимоги до збереження інформації при аваріях. 26 4.1.13 Вимоги до патентної чистоти. 26 4.1.14 Вимоги до стандартизації та уніфікації 27 4.2 Вимоги до функцій (задач), які реалізуються в межах доопрацювань. 27 4.2.1 Перелік програмних компонентів, які розробляються/ модернізуються в межах доопрацювань. 27 4.2.2 Архітектура рішення. 28 4.2.3 Опис вимог до програмних компонентів, які розробляються або модернізуються в межах доопрацювань. 29 4.2.3.1 Вимоги до модернізації програмного компонента «ЕКГ». 29 4.2.3.2 Вимоги до модернізації програмного компонента «Заяви». 34 4.2.3.3 Вимоги до створення програмного компонента щодо перенесення місця проживання/перебування громадян до іншого об’єкта адресації 35 4.2.3.4 Вимоги до розробки нового права доступу до рольової моделі для надання знеособленої інформації громадянам по приміщенням щодо реєстрації/зняття з реєстрації місця проживання/перебування громадян. 45 4.2.3.5 Вимоги до доопрацювання робочого місця користувача «Виконавці комунальних послуг». 51 4.2.3.6 Вимоги до доопрацювання прикладного програмного компонента «Статистичний звіт: Кількість зареєстрованих осіб». 55 4.2.3.7 Вимоги до розробки механізму взаємодії ІС РТГК з ОКК у межах послуги «Електронний сервіс запиту громадянином про кількість зареєстрованих у приміщенні» (для е-послуги ОКК «Кількість жителів, зареєстрованих за моєю адресою»). 61 4.2.3.8 Вимоги до інтеграції ІС РТГК з Модулем авторизації Платформи KYIVSMARTCITY, який є частиною Платформи KYIVSMARTCITY.. 64 4.2.3.9 Вимоги до інтеграції ІС РТГК з Модулем нотифікацій Платформи KYIVSMARTCITY з метою розсилки повідомлень організаціям, які приймають участь у процесі надання послуг користувачам.. 68 4.2.3.10 Вимоги до інтеграції ІС РТГК з Модулем обліку та моніторингу, який є частиною Платформи KYIVSMARTCITY.. 77 4.2.3.11 Вимоги до інтеграції ІС РТГК з СНДІ МКА в частині подання заявок на створення нових компонентів адреси. Вимоги до видів забезпечення. 78 4.2.3.12 Вимоги до розробки механізму обміну даними між ІС РТГК та «Вітриною даних»  91 4.3 Вимоги до видів забезпечення. 92 4.3.1 Вимоги до математичного забезпечення. 92 4.3.2 Вимоги до інформаційного забезпечення. 92 4.3.3 Вимоги до лінгвістичного забезпечення. 92 4.3.4 Вимоги до апаратно-програмного забезпечення. 93 4.3.5 Рекомендовані вимоги до апаратно-технічного забезпечення, включаючи вже існуюче апаратно-технічне забезпечення інформаційної системи РТГК.. 94 4.3.6 Вимоги до технічного забезпечення. 95 4.3.7 Вимоги до метрологічного забезпечення. 95 4.3.8 Вимоги до організаційного забезпечення. 95 4.3.9 Вимоги до методичного забезпечення. 96 5 СКЛАД ТА ЗМІСТ ПОСЛУГ ПО ВИКОНАННЮ ДООПРАЦЮВАНЬ СИСТЕМИ.. 97 6 ПОРЯДОК КОНТРОЛЮ ТА ПРИЙМАННЯ ДООПРАЦЮВАНЬ СИСТЕМИ.. 98 7 ВИМОГИ ДО СКЛАДУ ТА ЗМІСТУ РОБІТ З ВВЕДЕННЯ ДООПРАЦЮВАНЬ СИСТЕМИ В ДІЮ.... 99 8 ВИМОГИ ДО ДОКУМЕНТУВАННЯ.. 100 СПИСОК РИСУНКІВ.. 101 СПИСОК ТАБЛИЦЬ.. 103 ЛИСТ РЕЄСТРАЦІЇ ЗМІН.. 104
  ПЕРЕЛІК ТЕРМІНІВ ТА СКОРОЧЕНЬ

Найменування: доопрацювання інформаційної системи «Реєстр територіальної громади м. Києва», 3 черга. Скорочена назва: доопрацювання «ІС РТГК». Умовне позначення: ІС РТГК або Система.

Договір про надання послуг від 10 квітня 2019 року № 4627. Шифр роботи: ІС РТГК.

Замовником доопрацювань ІС РТГК є комунальне підприємство «Головний інформаційно-обчислювальний центр». Адреса та реквізити Замовника: 02192, м. Київ-192 вул. Космічна, 12а; код ЄДРПОУ 04013755 п/р № 35442136091290 ГУ ДКСУ у м. Києві, МФО 820019 ІПН: 040137526538 Свідоцтво № 100093243 Виконавцем є товариство з обмеженою відповідальністю «ЕФ ДI АЙ КАМПАНI». Адреса та реквізити Виконавця: 01032, м. Київ, бульвар Тараса Шевченка, 62 код ЄДРПОУ  37770359 Реквізити: п/р 2600825709 в ПАТ «ПУМБ» у м. Києві МФО 334851 ІПН 377703526578 Свідоцтво платника ПДВ №200088431 Платник податку на прибуток на загальних підставах Тел: (044) 337-03-91 Email: info@fdi.net.ua

Під час розробки доопрацювань необхідно користуватися такими нормативно-правовими актами та національними і міжнародними стандартами, як:Конституція України;

• Закон України «Про внесення змін до деяких законодавчих актів України щодо розширення повноважень органів місцевого самоврядування та оптимізації надання адміністративних послуг»;
• Закон України «Про Єдиний державний демографічний реєстр та документи, що підтверджують громадянство України, посвідчують особу чи її спеціальний статус»;
• Закон України «Про Державний реєстр виборців»;
• Закон України «Про адміністративні послуги»;
• Закон України «Про інформацію»;
• Закон України «Про електронні документи та електронний документообіг»;
• Закон України «Про доступ до публічної інформації»;
• Закон України «Про захист інформації в інформаційно-телекомунікаційних системах»;
• Закон України «Про електронний цифровий підпис»;
• Закон України «Про захист персональних даних»;
• Закон України «Про свободу пересування та вільний вибір місця проживання в Україні»;
• Закон України «Про внесення змін до деяких законодавчих актів України щодо документів, що підтверджують громадянство України, посвідчують особу чи її спеціальний статус, спрямованих на лібералізацію Європейським Союзом візового режиму для України»;
• Постанови Кабінету Міністрів України від 02.03.2016 №207 «Про затвердження Правил реєстрації місця проживання та Порядку передачі органами реєстрації інформації до Єдиного державного демографічного реєстру»;
• Постанови Кабінету Міністрів України від 28.10.2004 № 1452 «Про затвердження Порядку застосування електронного цифрового підпису органами державної влади, органами місцевого самоврядування, підприємствами, установами та організаціями державної форми власності»;
• Постанови Кабінету Міністрів України від 29.03.2006 № 373 «Про затвердження Правил забезпечення захисту інформації в інформаційних, телекомунікаційних та інформаційно-телекомунікаційних системах»;
• ДСТУ ISO/IEC/IEEE 12207:2018. Інженерія систем і програмних засобів. Процеси життєвого циклу програмних засобів;
• ДСТУ ISO/IEC/IEEE 42010:2018 Інженерія систем і програмних засобів. Опис архітектури (ISO/IEC/IEEE 42010:2011, IDT);
• ДСТУ ISO/IEC/IEEE 24765:2018 Інженерія систем і програмних засобів. Словник термінів (ISO/IEC/IEEE 24765:2017, IDT);
• ДСТУ ISO/IEC/IEEE 15288:2016 Інженерія систем і програмного забезпечення. Процеси життєвого циклу систем (ISO/IEC/IEEE 15288:2015, IDT);
• ДСТУ ISO/IEC/IEEE 29119-1:2017 Інженерія систем і програмних засобів. Тестування програмних засобів (ISO/IEC/IEEE 29119-1:2013, IDT);
• ДСТУ ISO/IEC 2382:2017 (ISO/IEC 2382:2015, IDT). Інформаційні технології. Словник термінів;
• ДСТУ ISO/IEC 15910:2012 Інформаційні технології. Документування програм. Документація користувача (ISO/IEC 15910:1999, IDT);
• ДСТУ ISO/IEC 14764:2014. Інженерія програмного забезпечення. Процеси життєвого циклу програмного забезпечення. Технічне обслуговування;
• ДСТУ ISO/IEC 11179-3:2005 Інформаційні технології. Реєстри метаданих (ІSO/ІEC 11179-3:2003, ІDT);
• ДСТУ 4302:2004 Інформаційні технології. Настанови щодо документування комп`ютерних програм (ISO/IEC 6592:2000, MOD);
• ДСТУ 3330-96 (ГОСТ 34.321-96) Інформаційні технології. Система стандартів з баз даних. Еталонна модель керування даними;
• ДСТУ 2941-94 Системи оброблення інформації. Розроблення систем. Терміни та визначення;
• ГОСТ 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. Методичні вказівки. Інформаційна технологія. Комплекс стандартів і керівних документів на автоматизовані системи. Загальні положення;
• ДСТУ ISO/IEC 19790:2015 Інформаційні технології. Методи захисту. Вимоги безпеки до криптографічних модулів (ISO/IEC 19790:2012, IDT);
• ДСТУ 7564:2014 Інформаційні технології. Криптографічний захист інформації. Функція гешування;
• ДСТУ ISO/IEC TR 13335-4:2005 Інформаційні технології. Настанови з керування безпекою інформаційних технологій. (ISO/IEC TR 13335-4:2000, IDТ);
• ДСТУ 4145-2002 Інформаційні технології. Криптографічний захист інформації. Цифровий підпис, що ґрунтується на еліптичних кривих. Формування та перевіряння;
• НД ТЗІ 3.7-003-05. Порядок проведення робіт із створення комплексної системи захисту інформації в інформаційно-телекомунікаційній системі;
• НД ТЗІ 1.4-001-2000. Типове положення про службу захисту інформації в автоматизованій системі;
• НД ТЗІ 3.6-001-2000. Технічний захист інформації. Комп’ютерні системи. Порядок створення, впровадження, супроводження та модернізації засобів технічного захисту інформації від несанкціонованого доступу;
• НД ТЗІ 1.1-003-99. Термінологія в галузі захисту інформації в комп’ютерних системах від несанкціонованого доступу;
• НД ТЗІ 2.5-004-99. Критерії оцінки захищеності інформації в комп’ютерних системах від несанкціонованого доступу;
• НД ТЗІ 2.5-005-99. Класифікація автоматизованих систем і стандартні функціональні профілі захищеності оброблюваної інформації від несанкціонованого доступу;
• НД ТЗІ 3.7-001-99. Методичні вказівки щодо розробки технічного завдання на створення комплексної системи захисту інформації в автоматизованій системі;
• ДСТУ 3396.0-96 Захист інформації. Технічний захист інформації. Основні положення;
• ДСТУ 3396.1-96 Захист інформації. Технічний захист інформації. Порядок проведення робіт;
• ДСТУ 3396.2-97 Захист інформації. Технічний захист інформації. Терміни та визначення;
• ДСТУ 2226-93 Автоматизовані системи. Терміни та визначення, затверджено наказом Держстандарту України від 09.09.93 № 126;
• Business Process Model and Notation (BPMN), Version 2.0, Object Management Group, 2011;
• Unified Modeling Language (UML), Version 2.5.1, Object Management Group, 2017;
• ПКМУ від 30 січня 2019 р. N 56 м. Київ. «Деякі питання цифрового розвитку».

Терміни виконання робіт з доопрацювання системи визначаються Договором про надання послуг від 10.04.2019р. № 4627.

Джерело фінансування послуг – бюджетні кошти.

Порядок оформлення і пред’явлення наданих послуг визначається умовами Договору про надання послуг від 10.04.2019 № 4627. Результатом надання послуг є:

1. Працездатна копія програми (серверна частина) на оптичному диску зі службовою програмою автоматичної установки.
2. Комплект документації у складі, обумовленому в цьому ТЗ.
3. Встановлена виконавцем програмна частина доопрацювань ІС РТГК на виділений сервер з боку Замовника.
4. Продемонстрована та перевірена згідно з процедурою тестування та приймання працездатність та відповідна функціональність доопрацювання ІС РТГК на тестових перевірочних даних.

Доопрацювання ІС РТГК призначено для:

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

Метою доопрацювання ІС РТГК є:

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

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

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

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

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

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

Забезпечення у приміщеннях кліматичних та інших умов для експлуатації роботи обладнання не є предметом цієї роботи і покладається на Замовника. У приміщеннях, в яких встановлено серверне та телекомунікаційне обладнання, відповідно до ГОСТ 15150-69 повинні бути штучно створені кліматичні умови з такими параметрами:

• температура навколишнього середовища від +10 С до + 35 С;
• відносна вологість повітря не більше 80% при температурі +25 С;
• атмосферний тиск від 650 мм рт. ст. до 800 мм рт. ст.

Доопрацювання повинні будуватись на базі раніше створеної централізованої програмно-технологічної платформи ІС РТГК з уніфікацією програмно-технічних засобів розробки (модернізації) прикладної функціональності з використанням сучасних веб-портальних сервісно-орієнтованих технологій. Функціонально доопрацювання повинні бути інтегровані в існуючу ІС РТГК та уніфіковані з точки зору програмно-апаратної платформи. Базовими компонентами доопрацювань мають бути програмні комплекси сервісів, що забезпечують реалізацію додаткової функціональності ІС РТГК. Доопрацьована ІС РТГК повинна забезпечувати уніфікований та комфортний, максимально простий та інтуїтивно зрозумілий інтерфейс користувача. Технологічна гнучкість, надійність роботи при модифікації та розширенні функціонального складу, скорочення часу та сукупних витрат на розробку та підтримку компонентів доопрацювань ІС РТГК повинні досягатись за рахунок реалізації принципів стандартизації та уніфікації, а саме:

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

При доопрацюванні ІС РТГК необхідно врахувати наявність таких обмежень:

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

З урахуванням обмежень доопрацювання ІС РТГК повинні бути побудовані на таких принципах:

• Централізація: доопрацювання ІС РТГК повинні вирішувати завдання, пов’язані з забезпеченням доступу до всіх об’єктів обліку (громадяни, об’єкти житлового фонду, записи у Реєстрі територіальної громади м. Києва та інше) та до відповідних довідкових та статистичних систем в межах Київської територіальної громади. Для вирішення цих завдань створюється Центральна база даних (ЦБД). Забезпечується централізоване ведення користувачів та загальносистемних довідників і класифікаторів.
• Стандартизація: стандартизація та централізація ведення довідників та класифікаторів. Підтримку довідників та класифікаторів необхідно забезпечити в автоматичному режимі шляхом стандартизованої програмної взаємодії з розпорядником відповідного інформаційного ресурсу. Якщо таке автоматичне оновлення має певні технічні та технологічні обмеження, підтримувати дані в актуальному стані повинен окремо виділений адміністратор даних.
• Мінімальна достатність серверних потужностей: доопрацювання ІС РТГК не повинні вимагати обов’язкової установки серверів у будь-яку установу або підрозділ.
• Безпека та надійність: у зв’язку з тим, що доопрацювання ІС РТГК мають працювати з персональними даними, Система повинна підтримувати необхідні технології безпеки зберігання, доступу та обробки інформації у відповідності до діючих законів та нормативів (детальніше у відповідних розділах цього ТЗ).
• Мінімізація числа операцій: доопрацювання ІС РТГК повинні забезпечувати одноразове внесення інформації в процесі надання адміністративної послуги з реєстрації / зняття з реєстрації без повторного внесення даних в різноманітні документи та форми.
• Стандарти відкритих систем, які забезпечують сумісність та інтегрованість між різним програмним забезпеченням та або їх модулями.
• Підтримка функціонування в різнорідному апаратному та програмному середовищах (для клієнтської частини).
• Вбудованість механізмів захисту від помилок і підтримка цілісності.
• Мінімальні витрати на закупівлю і експлуатацію супутнього ПЗ та обладнання.
• Орієнтація на користувача: потреби користувачів та суб’єктів звернення мають визначати перелік та способи реалізації функцій та властивостей доопрацювань ІС РТГК.
• Дебюрократизація та адміністративне спрощення: розвиток системи реєстрації МПП має на меті спрощення порядків надання та зменшення кількості адміністративних послуг, у тому числі через запровадження міжвідомчої електронної взаємодії.
• Збереження електронної інформації: принцип полягає у забезпеченні цілісності та достовірності інформації про дії суб’єктів надання адміністративних послуг з реєстрації МПП, пов’язані з отримання персональних даних про суб’єктів звернення з можливістю доступу суб’єктів звернення до такої інформації.
• Ефективність і результативність: запровадження ІС РТГК повинно відбуватись з урахуванням досягнення конкретних показників щодо ефективності та результативності їх надання, у тому числі економії бюджетних коштів та підвищення задоволеності суб’єктів звернення.

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

• сховище даних на базі СКБД PostgreSQL;
• рівень серверу застосувань;
• рівень представлення веб-серверу.

Рівень серверів застосувань повинен складатись із таких взаємопов’язаних компонентів:

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

Обмін інформацією між сервером застосувань, клієнтською частиною доопрацювань ІС РТГК та іншими зовнішніми системами повинен реалізовуватись на рівні ХМL-документів із застосуванням технології веб-сервісів на базі JSON API. Компоненти серверу застосувань реалізації серверної бізнес-логіки призначені для:

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

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

• центральний рівень;
• рівень користувача.

Центральний рівень – рівень, який забезпечує роботу бази даних (БД), сервісів авторизації та автентифікації користувачів, сервісів обробки запитів та виконання процедур та інших загальних інформаційних ресурсів доопрацювань ІС РТГК. Рівень користувача – організації з надійними та швидкісними каналами зв’язку, які є споживачами адресної інформації та мають віддалений доступ до ІС РТГК. Користувачі можуть бути авторизованими та мати безпосередній доступ до доопрацювань ІС РТГК з правом читання/запису або неавторизованими, які мають доступ до доопрацювань ІС РТГК через спеціалізовані програмні протоколи доступу. Центральний інформаційний рівень фізично розгортається на серверах майданчика КП ГІОЦ. Інформаційний рівень авторизованих користувачів не потребує особливих дій або умов по розгортанню та обмежується встановленням браузерів для перегляду та використання стандартних веб-сервісів.

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

• «Супервізор» – має доступи до всіх функцій та операцій Системи, відповідає за функціонування програмно-технічного комплексу;
• «Адміністратор» – відповідає за функціонування програмно-технічного комплексу в цілому;
• «Шеф» – відповідає за наповнення, обробку, актуалізацію та видалення даних з довідників Системи;
• «Уповноважені» – відповідає за наповнення, обробку та актуалізацію довідників Системи;
• Сторонні – співробітники організацій (нотаріуси тощо), що надають послуги громадянам та мають право переглядати/використовувати данні ІС РТГК, але не мають права вносити зміни.

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

• «Супервізор» – повинен мати вищу профільну освіту з адмініструванням баз даних;
• «Адміністратор» – повинен мати профільну освіту або сертифікати про закінчення курсів, пов’язаних з адмініструванням баз даних, захистом інформації;
• «Шеф» – повинен мати вищу профільну освіту;
• «Уповноважені» – повинні мати вищу профільну освіту;
• Сторонні – повинні володіти навичками роботи з ПК, інші вимоги межами цього ТЗ не визначаються.

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

Доопрацювання ІС РТГК повинні забезпечувати:

• обслуговування одночасної роботи до 5000 користувачів;
• час обробки запитів та відображення інформації на сторінці – не більше ніж 5 сек;
• первісне завантаження будь-якої веб-сторінки – не більше 4 сек.

Експлуатація доопрацювань ІС РТГК повинна передбачати такі режими функціонування:

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

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

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

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

Проектні рішення щодо доопрацювань ІС РТГК повинні передбачати заходи та процедури з експлуатації, які узгоджуються з вимогами документа «Про затвердження Правил охорони праці під час експлуатації електронно-обчислювальних машин», затверджених наказом Державного комітету України з промислової безпеки, охорони праці та гірничого нагляду від 26.03.2010 №65. Вимоги з техніки безпеки повинні забезпечувати безпеку під час налагодження та експлуатації технічних засобів комп’ютерних програм. Технічні засоби не повинні створювати шуми та вібрації, електромагнітні поля надвисоких частот, жорсткі та іонізуючі випромінювання, рівні яких перевищують допустимі норми, що встановлені в ГОСТ 12.1.003-83. Граничні рівні шуму у приміщеннях, де працює персонал структурних підрозділів служб, повинні відповідати ГОСТ 27818-88 «Машини обчислювальні та системи оброблення даних. Допустимі рівні шуму на робочих місцях і методи їх визначення». Монітори для роботи з АРМ повинні мати рівень електромагнітного випромінювання відповідно до існуючих санітарних норм. Приміщення, у яких розміщуються технічні засоби, повинні бути обладнані протипожежною сигналізацією, дозволеного до використання в органах державної влади. Загальні вимоги електричної і механічної безпеки повинні бути забезпечені відповідно до ГОСТ 12.2.007.0-75 і ГОСТ 25861-83. Засоби захисту людини від ураження електричним струмом повинні відповідати вимогам ГОСТ 12.1.019-75 і ГОСТ 25861-83. Елементи технічних комплексів щодо засобів захисту людини від поразки електричним струмом повинні відповідати вимогам ГОСТ 12.2.007.0-75 і ГОСТ 25861-83. Заземлення технічних засобів повинно бути виконано відповідно до вимог ГОСТ 12.2.007.0-75 і ГОСТ 25861-83. Під час наладки та експлуатації технічних засобів повинні виконуватись усі вимоги правил техніки безпеки та правил встановлення та експлуатації електрообладнання.

Рішення щодо ергономіки доопрацювань ІС РТГК повинні відповідати вимогам технічної естетики та інженерної психології для забезпечення гармонійного зв'язку між параметрами технічних засобів і психофізичними можливостями людини з урахуванням створення єдиного об’ємно-просторового і кольорового рішення відповідно до ГОСТ 12.2.032 – 78, ГОСТ 12.2.033 – 78, ГОСТ 24750 – 81. Рішення щодо ергономіки веб-інтерфейсу повинно надавати у використання користувачу зрозумілу логічну побудову інформаційної архітектури із певним набором відповідних графічних, текстових, функціональних компонентів. Загальна побудова веб-інтерфейсу повинна передбачати зрозумілу логічну модель структури сторінок та переходів між ними. Сторінки не повинні бути перевантажені інформаційно-графічними матеріалами. Глибина вкладення (логічних переходів) не повинна бути більше 5 рівнів. Побудова логічних зав’язків у межах певної функціональності повинна бути зручною та інтуїтивно зрозумілою. Користувач повинен мати зручний інтерфейс із обґрунтованим набором необхідних інструментів для виконання певних дій, закладених у межах відповідного бізнес-процесу. Веб-інтерфейс повинен відповідати таким вимогам щодо використання технологій при його створенні:

• Передбачається використання HTML4 / HTML5, Ajax, JavaScript.
• Для накладення стильової інформації використовується таблиці стилів CSS3.
• Можливе використання різних rich-media технологій як компонента HTML сторінок.
• Використання таких технологій, як Flash, наприклад, у вигляді Flex або SilverLigh не передбачається.

В цілому передбачається сумісність:

• з операційними системами: Windows (не нижче версії 7), Linux;
• з браузерами: MozillaFirefox (не нижче версії 52), GoogleChrome (не нижче версії 50), Opera (не нижче версії 36).

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

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

• Chromе;
• Mozilla Firefox;

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

Рішення щодо ергономіки доопрацювань ІС РТГК повинні забезпечувати:

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

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

• технічний супровід та технічна підтримка вузлів доопрацювань ІС РТГК виконуються технічним персоналом Замовника та/або фахівцями Виконавця згідно з вимогами виробників обладнання та програмного забезпечення, які надаються Виконавцем у вигляді інструкцій з експлуатації;
• склад та регламент робіт з технічного супроводу та підтримки доопрацювань ІС РТГК, кількість і кваліфікація технічного персоналу повинні відповідати вимогам виробників програмно-технічних засобів і бути узгодженими з Замовником;
• проведення робіт з профілактики і ремонту окремих компонентів та блоків доопрацювань ІС РТГК не повинно порушувати роботу всієї Системи;
• технічний та фізичний захист і збереженість апаратних компонентів доопрацювань ІС РТГК та носіїв даних, безперебійне електропостачання, резервування ресурсів, поточне обслуговування забезпечується технічними та організаційними засобами, передбаченими в структурі Замовника;
• електроживлення технічних засобів доопрацювань ІС РТГК повинно здійснюватися від електромережі змінного струму напругою 220В з частотою 50 Гц;
• приміщення, в яких експлуатуватиметься серверне обладнання, повинні відповідати вимогам виробників обладнання щодо розміру площі, необхідної для розміщення апаратури, та наявності системи кондиціювання повітря;
• приміщення, де розміщується обладнання доопрацювань ІС РТГК мають бути обладнані індивідуальним контуром заземлення;
• нормальними умовами для експлуатації АРМ користувачів повинні бути:
• температура навколишнього повітря: +20±5 С°;
• атмосферний тиск: 630-800 мм.рт.ст.;
• відносна вологість повітря: 60±15 %.

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

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

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

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

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

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

В межах доопрацювань ІС РТГК розробляються такі програмні компоненти:

1. Модернізація прикладного програмного компонента «ЕКГ».
2. Модернізація прикладного програмного компонента «Заяви».
3. Створення прикладного програмного компонента щодо перенесення реєстрації місця проживання/перебування громадян до іншого об’єкта адресації.
4. Розробка нового права доступу до рольової моделі для надання знеособленої інформації користувачам по приміщеннях щодо реєстрації/зняття з реєстрації місця проживання/перебування громадян.
5. Доопрацювання робочого місця користувача «Виконавці комунальних послуг».
6. Доопрацювання прикладного програмного компонента «Статистичний звіт: Кількість зареєстрованих осіб».
7. Розробка механізму взаємодії ІС РТГК з ОКК у межах послуги «Електронний сервіс запиту громадянином кількості зареєстрованих у приміщенні» (для е-послуги ОКК «Кількість жителів, зареєстрованих за моєю адресою»).
8. Інтеграція ІС РТГК з Єдиним модулем обліку та управління користувачами та ЗІС, який є частиною Платформи KYIVSMARTCITY.
9. Інтеграція ІС РТГК з Єдиним модулем та управління нотифікаціями з метою розсилки повідомлень організаціям, які приймають участь у процесі надання послуг громадянам.
10. Інтеграція ІС РТГК з Єдиним модулем логування та моніторингу, який є частиною Платформи KYIVSMARTCITY.
11. Інтеграція ІС РТГК з СНДІ МКА в частині подачі заявок на створення нових компонентів адреси.
12. Розробка механізму обміну даними між ІС РТГК та «Вітриною даних».

Загальна блок схема побудови архітектури рішення (див. Рисунок 1. Концептуальна схема логічної архітектури побудови рішення). Рисунок 1. Концептуальна схема логічної архітектури побудови рішення

Екранні форми, прототипи яких наведені при описі вимог до доопрацювань ІС РТГК, можуть бути змінені в процесі розробки, але у будь-якому разі кінцеві екранні форми повинні відповідати вимогам, що зазначені у цьому Технічному завданні.

Модернізація прикладного програмного компонента ЕКГ забезпечує:

• Відстеження та повідомлення користувачів про настання подій щодо громадян (див. Таблиця 1. Перелік подій, за якими відбувається повідомлення користувача).

Таблиця 1. Перелік подій, за якими відбувається повідомлення користувача

Повідомлення користувачів про настання подій повинно відбуватися в момент перегляду даних громадянина в окремому вікні або у вигляді підказки, натиснувши на яку користувач може переглянути повідомлення (див. Рисунок 2. Прототип екранної форми ЕГК підказки про настання події та Рисунок 3. Прототип екранної форми ЕГК повідомлення про настання події).   Рисунок 2. Прототип екранної форми ЕГК підказки про настання події Рисунок 3. Прототип екранної форми ЕГК повідомлення про настання події  

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

Перевірка унікальності повинна виконуватися не тільки за номером документа, а одночасно за номером та датою видачі документа. Перевірка унікальності виконується в момент збереження створення/редагування ЕКГ. Програма перевіряє унікальність номеру Свідоцтва про народження за таким правилом: серія та номер свідоцтва + дата видачі документа повинні бути унікальними у Системі. При цьому при перевірці першого символу серії свідоцтва «І» та «1» повинні вважатися рівнозначними, наприклад: Свідоцтво «1-БК 235874 від 25.04.2016» = свідоцтву «І-БК 235874 від 25.04.2016». Якщо при збережені даних Система виявляє порушення вказаного правила унікальності, то дані не зберігаються, а користувачу надається повідомлення про помилку.

• Створення у картці ЕКГ додаткового поля для введення ІПН громадянина, яке необов'язкове для заповнення (див. Таблиця 2. Опис поля «ІПН» та Рисунок 4. Прототип екранної форми ЕКГ з новим полем «ІПН»).

Поле «ІПН» доступно до заповнення при створенні та редагуванні ЕКГ. Таблиця 2. Опис поля «ІПН»

  Рисунок 4. Прототип екранної форми ЕКГ з новим полем «ІПН»  

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

• Про факт реєстрації малолітньої дитини в ОЖФ

Повідомлення повинно відбуватися в момент збереження Заяви на реєстрацію місця проживання малолітньої дитини (громадянин, якому ще не виповнилося 14 років). Система в момент збереження Заяви повинна перевірити, чи зареєстроване у приміщенні місце проживання повнолітнього громадянина, який має родинний зв’язок з дитиною за типом «мати» або «батько», та у разі відсутності реєстрації одного з батьків дитини Система повинна видати користувачеві повідомлення. При наданні повідомлення Система повинна надати користувачеві можливість продовження або скасування збереження Заяви (див. Рисунок 5. Прототип екранної форми з повідомленням про факт реєстрації малолітньої дитини у ОЖФ). Рисунок 5. Прототип екранної форми з повідомленням про факт реєстрації малолітньої дитини у ОЖФ

• Про факт зняття з реєстрації повнолітніх громадян у ОЖФ, в якому залишається зареєстрованою малолітня дитина.

Повідомлення повинно відбуватися в момент збереження Заяви на зняття з реєстрації місця проживання повнолітнього громадянина. Система в момент збереження Заяви повинна перевірити, чи зареєстрована в обраному ОЖФ малолітня дитина. У разі, коли в обраному ОЖФ залишається малолітня дитина, Система повинна перевірити, чи зареєстровано у приміщенні місце проживання повнолітнього громадянина, який має родинний зв’язок з дитиною за типом «мати» або «батько». У разі відсутності реєстрації одного з батьків дитини Система повинна видати користувачеві повідомлення з попередженням. При наданні повідомлення Система повинна надати користувачеві можливість продовження або скасування збереження Заяви (див. Рисунок 6. Прототип екранної форми з повідомленням про наявність реєстрації неповнолітньої особи). Рисунок 6. Прототип екранної форми з повідомленням про наявність реєстрації неповнолітньої особи

Створення програмного компонента повинно забезпечити можливість перенесення всієї історії реєстрації/зняття з реєстрації місця проживання/перебування громадян у відповідному ОЖФ:

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

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

• в межах однієї будівлі;
• до іншої будівлі.

Рисунок 7. Прототип екранної форми розділу меню для виконання операції перенесення історії реєстрації/зняття з реєстрації

• Операція перенесення історії реєстрації/зняття з реєстрації місця проживання/перебування громадян в межах однієї будівлі.

Для виконання операції перенесення історії реєстрації/зняття з реєстрації місця проживання/перебування громадян з одного приміщення до іншого приміщення в межах однієї будівлі необхідно обрати тип операції «В межах однієї будівлі». Екранна форма для виконання операції повинна дозволяти вибір адреси будівлі, в межах якої необхідно здійснити перенесення історії реєстрації/зняття з реєстрації місця проживання/перебування, обравши вулицю та номер будівлі. Опис полів щодо вибору адреси будівлі (див. Таблиця 3. Опис полів фільтра пошуку адреси при перенесенні в межах однієї будівлі). Таблиця 3. Опис полів фільтра пошуку адреси при перенесенні в межах однієї будівлі

Після вказання адреси будівлі на екрані повинен відобразитися перелік усіх приміщень цієї будівлі та список громадян, у яких в історії реєстрації/зняття з реєстрації є обрана будівля (див. Рисунок 8. Прототип екранної форми для виконання операції ). Опис полів списку приміщень та громадян (див. Таблиця 4. Опис полів списку приміщень та громадян при перенесення в межах однієї будівлі).   Рисунок 8. Прототип екранної форми для виконання операції перенесення історії реєстрації/зняття з реєстрації в межах однієї будівлі Таблиця 4. Опис полів списку приміщень та громадян при перенесення в межах однієї будівлі

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

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

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

• Операція перенесення історії реєстрації/зняття з реєстрації місця проживання/перебування громадян з однієї будівлі до іншої.

Для виконання операції перенесення історії реєстрації/зняття з реєстрації місця проживання/перебування громадян з однієї будівлі до іншої необхідно обрати тип операції «До іншої будівлі». Екранна форма для виконання операції повинна дозволяти обирати адресу будівлі, з якої переноситься історія реєстрації/знаття з реєстрації, та адресу будівлі, до якої виконується перенесення (див. Рисунок 9. Прототип екранної форми для виконання операції перенесення історії реєстрації/зняття з реєстрації з однієї будівлі до іншої). Опис полів щодо вибору адрес наведено нижче (див. Таблиця 5. Опис полів фільтра пошуку адреси при перенесенні з однієї будівлі до іншої). Таблиця 5. Опис полів фільтра пошуку адреси при перенесенні з однієї будівлі до іншої

Після вказання адреси будівлі, з якої відбувається перенесення історії реєстрації/зняття з реєстрації, на екрані повинен відобразитися перелік усіх приміщень цієї будівлі та список громадян, у яких є обрана будівля в їх реєстраційних записах (див. Рисунок 9. Прототип екранної форми для виконання операції перенесення історії реєстрації/зняття з реєстрації з однієї будівлі до іншої). Опис полів списку приміщень та громадян наведено нижче (див. Таблиця 6. Опис полів списку приміщень та громадян при перенесення з однієї будівлі до іншої).   Рисунок 9. Прототип екранної форми для виконання операції перенесення історії реєстрації/зняття з реєстрації з однієї будівлі до іншої   Таблиця 6. Опис полів списку приміщень та громадян при перенесення з однієї будівлі до іншої

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

• обирати усі приміщення в будинку, з якого відбувається перенесення або одне/декілька приміщень;
• обирати одного або декількох громадян;
• обирати приміщення для перенесення історії реєстрації/зняття з реєстрації в іншому будинку.
• обирати опцію «Заповнити відповідно номерів приміщень» для перенесення у приміщення з номерами, відповідними номерам приміщень будинку, з якого переноситься історія реєстрації/зняття з реєстрації. Опцію можна використовувати тільки у разі, коли в обох будинках є відповідні приміщення. В іншому випадку повинна видаватись помилка «Увага!!! В будівлі, куди переноситься історія реєстрації/зняття з реєстрації громадян, наявні не всі приміщення».

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

Розробка повинна забезпечити створення нових прав до ролі для можливості:

• формування витягу по приміщенню щодо реєстрації/зняття з реєстрації місця проживання/перебування громадян зі знеособленою інформацією щодо громадян;
• управління відображенням ПІБ громадянина у інтерфейсі та у сформованому витягу по приміщенню у форматі PDF щодо зареєстрованих/знятих з реєстрації громадян.

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

• щодо перегляду/пошуку ЕКГ;
• на управління відображенням ПІБ громадянина

(див. Таблиця 7. Результат формування «Витягу по будинку за період» в залежності від комбінації прав доступу ролі). Таблиця 7. Результат формування «Витягу по будинку за період» в залежності від комбінації прав доступу ролі

У сформованому «Витягу» по приміщенню щодо реєстрації/зняття з реєстрації місця проживання/перебування громадян зі знеособленою інформацією по громадянах повинні відображатися тільки дата народження та дата реєстрації/зняття з реєстрації у приміщенні, а замість ПІБ громадян необхідно відображати крапки (див. Рисунок 13. Прототип «Витягу» по приміщенню зі знеособленою інформацією). Формат та інші вимоги до «Витягів» по приміщенню не змінюються. Рисунок 13. Прототип «Витягу» по приміщенню зі знеособленою інформацією

У межах модернізації робочого місця «Виконавці комунальних послуг» необхідно:

• Реалізувати можливість формування звіту «Статистика за адресами» з можливістю вибору періоду у межах двох місяців, а саме:
• реалізувати можливість завдання дати початку та дати закінчення періоду, за який необхідно сформувати звіт (див. Рисунок 14. Прототип екранної форми при формування звіту «Статистика за адресами»). Опис полів див. Таблиця 8. Опис полів періоду формування звіту «Статистика за адресами». При вказанні дат початку та закінчення періоду введені значення повинні зберігатися впродовж всієї робочої сесії при формуванні будь-якої кількості звітів до моменту ручного введення інших значень або до виходу з меню «Статистика за адресами»;
• обмежити максимальний період формування звіту двома місяцями;
• новий формат вказання періоду поширюється на всі звіти, що формуються з розділу «Статистика за адресами», а саме:
• звіт за районом;
• звіт за вулицею;
• звіт за № будівлі;
• об’єднаний звіт;
• звіт по ОСББ/ЖБК/ВЖ.

Таблиця 8. Опис полів періоду формування звіту «Статистика за адресами»

* Внести зміни у заголовок «Витяг з інформаційної системи «Реєстр територіальної громади м. Києва» про зареєстрованих/знятих з реєстрації осіб у житлових приміщеннях». У заголовку «Витяги з інформаційної системи «Реєстр територіальної громади м. Києва» про зареєстрованих/знятих з реєстрації осіб у житлових приміщеннях» (надалі – «Витяг за будинком за період») необхідно вказувати період формування витягу у форматі «за період з дд.мм.рррр по дд.мм.рррр року», де дд.мм.рррр – дата початку/закінчення періоду формування витягу (див. Рисунок 15. Прототип документа «Витяг за будинком за період»). Формат та інші вимоги до «Витягу по будинку за період» залишаються без змін. Заголовок «Витягу за будинком за період» необхідно виводити у новому форматі також при формуванні об’єднаного витягу за будинком та при формування витягу по ОСББ/ЖБК/ВЖ. При цьому формування документа «Витяг з інформаційної системи «Реєстр територіальної громади міста Києва» про зареєстрованих осіб у житлових приміщеннях за адресою» залишається без змін та виводиться на поточну дату формування витягу. Рисунок 14. Прототип екранної форми при формування звіту «Статистика за адресами»   Рисунок 15. Прототип документа «Витяг за будинком за період»  

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

1. Можливість формування звіту «Кількість зареєстрованих осіб» за декількома будинками в межах обраної вулиці.

Необхідно у розділі меню «Статистика» у звіті «Кількість зареєстрованих осіб» реалізувати можливість вибору в межах вулиці одного, декількох або усіх будинків (див. Рисунок 16. Прототип екранної форми для вибору декількох будинків при формуванні звіту «Кількість зареєстрованих осіб»). Інформація у звіті повинна виводитися на екран в розрізі кожного обраного будинку та з підсумковими даними за всіма обраними будинками про кількість зареєстрованих осіб, в тому числі віком від 18 років (див. Рисунок 17. Прототип екранної форми виведення звіту «Кількість зареєстрованих осіб» за декількома будинками). Опис полів звіту, які виводяться на екран, наведено на Таблиця 9. Опис полів звіту «Кількість зареєстрованих осіб» за декількома будинками.     Рисунок 16. Прототип екранної форми для вибору декількох будинків при формуванні звіту «Кількість зареєстрованих осіб»   Рисунок 17. Прототип екранної форми виведення звіту «Кількість зареєстрованих осіб» за декількома будинками Таблиця 9. Опис полів звіту «Кількість зареєстрованих осіб» за декількома будинками

* Можливість формування документа «Витяг з Реєстру територіальної громади міста Києва про кількість зареєстрованих громадян» в одному або декількох будинках. Необхідно у розділі меню «Статистика» у звіті «Кількість зареєстрованих осіб» реалізувати можливість формування у форматі PDF документа «Витяг з Реєстру територіальної громади міста Києва про кількість зареєстрованих громадян» (надалі – Витяг за декількома будинками) (див. Рисунок 18. Прототип Витягу за декількома будинками). Опис полів Витягу за декількома будинками (див. Таблиця 10. Опис полів Витягу за декількома будинками). Рисунок 18. Прототип Витягу за декількома будинками Таблиця 10. Опис полів Витягу за декількома будинками

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

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

• у разі наявності в ІС МР даних користувача з ІС РТГК:
• ID громадянина у ІС РТГК;

та/або

• за необхідності передачі даних користувача до ІС МР:
• прізвище, ім’я, по-батькові;
• дата народження;

та/або

• серія та номер паспорта.

Вихідними даними мають бути:

• ID громадянина у ІС РТГК;
• адреса реєстрації користувача;
• кількість осіб, що зареєстровано за адресою реєстрації користувача на дату запиту, за типом «Проживає»/«Перебуває».

Схема взаємодії ІС РТГК з ЗІС (див. Рисунок 20. Бізнес процес замовлення та отримання е-послуги «Кількість зареєстрованих за моєю адресою»). Опис бізнес-процесу замовлення послуги «Електронний сервіс запиту громадянином про кількість зареєстрованих у приміщенні» (е-послуги ОКК «Кількість жителів, зареєстрованих за моєю адресою»):

1. Послугу може отримати тільки користувач ОКК, який увійшов до ОКК за умови проходження ідентифікації та автентифікації засобами КЕП або BankID та надав згоду на передачу даних з ІС РТГК до ІС МР.
2. Для замовлення послуги користувачу необхідно обрати її в каталозі електронних послуг ОКК, де є можливість також ознайомитись з інформацією та правилами надання послуги.
3. За фактом замовлення послуги, ОКК передає дані KyivID користувача до ІС МР.
4. ІС МР здійснює пошук даних користувача, у своїй базі даних, отриманих з ІС РТГК за даними KyivID та за результатами успішного пошуку повертає до ОКК ідентифікатор громадянина у ІС РТГК (надалі - ID RTGK). У випадку відсутності даних користувача виконується існуючий сценарій отримання даних з ІС РТГК.
5. У випадку успішного результату пошуку ОКК запитує у ІС РТГК дані про кількість громадян за ID RTGK.
6. За результатами пошуку по ID RTGK Система повертає до ОКК дані про кількість громадян, зареєстрованих за місцем реєстрації користувача.

  Рисунок 20. Бізнес процес замовлення та отримання е-послуги «Кількість зареєстрованих за моєю адресою»

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

• направити користувача до Модуля авторизації на сторінку для введення даних КЕП (див. Рисунок 23. Прототип екранної форми KyivID для входу через КЕП);

  Рисунок 21. Схема реєстрації користувачів у ІС РТГК з використанням КЕП
Рисунок 22. Інтерфейс сторінки входу до ІС РТГК   Рисунок 23. Прототип екранної форми KyivID для входу через КЕП  

• при отриманні KyivID користувача, що було йому надано Модулем авторизації під час реєстрації на підставі даних КЕП, перевірити відповідність отриманих даних користувача за КЕП та даних, введених під час його реєстрації у ІС РТГК;
• у разі успішної перевірки даних користувача за КЕП та введених під час його реєстрації у ІС РТГК, зберегти їх у Системі KyivID користувача.

При подальшому вході користувача у ІС РТГК Система повинна забезпечити перевірку відповідності надісланого KyivID користувача від Модуля авторизації з тим, що було збережено у Системі.

1. Відправка повідомлень

Необхідно забезпечити інтеграцію ІС РТГК з комп’ютерною програмою «Urbio Модуль нотифікацій» (Єдиний модуль обліку та управління нотифікаціями) Платформи KYIVSMARTCITY (далі – Модуль нотифікацій) та розробку механізму відправлення повідомлень за шаблонами про порядок сплати за послуги користування Системою та сплату заборгованості нотаріусам, які приймають участь у процесі надання послуг користувачам (див. Рисунок 24. Схема відправлення повідомлення за шаблоном). Рішення повинно забезпечити:

• Можливість автоматичної розсилки електронних листів користувачам Системи з категорією «Нотаріальні» за одним з трьох шаблонів:
• шаблон 1 – «Порядок сплати за послуги РТГК»;
• шаблон 2 – «Реквізити для сплати послуг РТГК»;
• шаблон 3 – «Повідомлення про заборгованість».
• Можливість створення списку отримувачів для відправлення повідомлень двома способами:
• завдання списку вручну (див. Рисунок 25. Прототип інтерфейсу відправлення повідомлень користувачам за умови ручного формування списку);
• вибір зі списку користувачів (див. Рисунок 26. Прототип інтерфейсу відправлення повідомлень користувачам при виборі зі списку користувачів).

Опис полів списку для відправлення наведено у Таблиця 11. Опис полів списку для відправлення повідомлень користувачам.

Рисунок 24. Схема відправлення повідомлення за шаблоном  
Рисунок 25. Прототип інтерфейсу відправлення повідомлень користувачам за умови ручного формування списку Рисунок 26. Прототип інтерфейсу відправлення повідомлень користувачам при виборі зі списку користувачів Таблиця 11. Опис полів списку для відправлення повідомлень користувачам

* Можливість вказання періоду заборгованості та дати блокування надання послуг РТГК у разі розсилки електронних листів за шаблоном 3 (див. Рисунок 25. Прототип інтерфейсу відправлення повідомлень користувачам за умови ручного формування списку).

• Формування списку повинно виконуватися Супервізором з окремого інтерфейсу ІС РТГК та надавати можливість:
• при формуванні списку вручну – можливість завдати отримувача за кодом ГІОЦ або за ПІБ користувача (див. Рисунок 25. Прототип інтерфейсу відправлення повідомлень користувачам за умови ручного формування списку);
• при виборі отримувачів зі списку користувачів – можливість формування списку користувачів для розсилки повідомлень з вибором категорії організації та/або вибором однієї або декількох організацій, користувачам якої необхідно відправити повідомлення. (див. Рисунок 26. Прототип інтерфейсу відправлення повідомлень користувачам при виборі зі списку користувачів).
• Можливість виконання операцій зі списком для відправлення повідомлень нотаріусам:
• додавання отримувача;
• видалення отримувача зі списку.
• Можливість вибору тільки тих користувачів, у яких є електронна адреса. В іншому випадку Система повинна попереджати Супервізора про відсутність електронної адреси.
• Ініціювання відправлення повідомлень згідно з обраним шаблоном на електронні адреси, що були вказані під час реєстрації нотаріусів у ІС РТГК.
• При ініціюванні відправлення повідомлень ІС РТГК повинна передати до Модуля нотифікацій запит на відправлення електронних листів, вказавши такі данні:
• KyivID отримувача (нотаріуса);
• ідентифікатор сценарію відправки та ідентифікатор шаблону повідомлення, налаштованого у Модулі нотифікацій;
• необхідні теги за шаблоном та електронну адресу отримувача;
• токен, що було надано ІС РТГК Модулем авторизації.
• Відправлення повідомлень нотаріусам повинно відбуватися в асинхронному режимі.

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

Історія відправлення повідомлень повинна зберігатися у Системі та бути доступною до перегляду Супервізором з окремого інтерфейсу ІС РТГК (див. Рисунок 27. Прототип інтерфейсу історії повідомлень користувачів). Опис полів фільтрів для вибору повідомлень зі списку наведено у Таблиця 12. Опис фільтрів для пошуку повідомлень в історії. Опис полів списку для перегляду історії відправлення повідомлень наведено у Таблиця 13. Опис полів списку історії відправлених повідомлень.  

  Рисунок 27. Прототип інтерфейсу історії повідомлень користувачів   Таблиця 12. Опис фільтрів для пошуку повідомлень в історії

Таблиця 13. Опис полів списку історії відправлених повідомлень

Інтеграція ІС РТГК з комп’ютерною програмою «Urbio Модуль обліку та моніторингу» (Єдиний модуль логування та моніторингу) Платформи KYIVSMARTCITY (далі – Модуль обліку та моніторингу) повинна забезпечити збір логів та метрик. У межах інтеграції Системи з Модулем обліку та моніторингу в Системі повинні бути встановлені:

• Агент зі збору логів.

Він повинен забезпечувати збір таких логів, які будуть зберігатися у Модулі обліку та моніторингу:

• Логи доступу Системи.
• Логи інтеграцій:
• назва системи чи модуля, до якого виконується запит;
• запит;
• відповідь системи чи модуля.
• Логи помилок (див. Таблиця 14. Базовий набір статусів відповідей (повідомлень) Системи):
• дата та час виникнення помилки;
• номер, опис чи причина помилки (інформація щодо самої помилки).
• Агент зі збору метрик.

Він повинен забезпечувати збір метрик, які будуть зберігатися у Модулі обліку та моніторингу:

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

Таблиця 14. Базовий набір статусів відповідей (повідомлень) Системи

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

У межах інтеграції з СНДІ МКА необхідно забезпечити:

1. Можливість направлення Заяви на створення нового компонента адреси (у тому числі вулиці та об’єкта адресації).

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

• населеного пункту в межах України;
• вулиці в межах м. Києва;
• будинку на відповідній вулиці в межах м. Києва.

Виклик фрейму відбувається після вибору типу компонента адреси, який необхідно створити (див. Рисунок 29. Прототип інтерфейсу екрана для виклику фрейму на створення нового компоненту адреси та отримання статусу по Заявам).  
Рисунок 28. Схема обміну запитами при створенні нового компонента адреси Рисунок 29. Прототип інтерфейсу екрана для виклику фрейму на створення нового компоненту адреси та отримання статусу по Заявам   Для виклику фрейму на створення відповідного компоненту адреси потрібно обрати необхідний тип компоненту адреси та натиснути кнопку «Створити» (див. Рисунок 29. Прототип інтерфейсу екрана для виклику фрейму на створення нового компоненту адреси та отримання статусу по Заявам), після чого у інтерфейсі Системи повинні відкритися поля вбудованого фрейму Заяви на новий компонент адреси (див. Рисунок 30. Прототип інтерфейсу фрейму Заяви на створення нової вулиці). Поля Заяви на новий компонент адреси залежать від самого компоненту, який необхідно створити. Перелік та опис полів фреймів (див. Таблиця 15. Опис полів фрейму на створення нових компонентів адреси). Таблиця 15. Опис полів фрейму на створення нових компонентів адреси

    Рисунок 30. Прототип інтерфейсу фрейму Заяви на створення нової вулиці

1. Можливість отримання поточного статусу поданих Заяв щодо створення нового компонента адреси.

Отримання поточного статусу поданих заяв здійснюється користувачем з роллю Супервізор через окремий фрейм, який викликається з інтерфейсу ІС РТГК та направляється до СНДІ МКА (див. Рисунок 31. Схема обміну запитами при отримані поточного статусу Заяви). Виклик фрейму відбувається при натисканні кнопки «Перегляд статусу Заяв», після чого у інтерфейсі відкриваються поля вбудованого фрейму для перегляду статусів Заяв на створення нового компонента адреси (див. Рисунок 32 Прототип інтерфейсу для перегляду статусів Заяв на створення нових компонентів адреси). Опис полів фільтрів пошуку та списку перегляду статусів Заяв на створення нових компонентів адрес (див. Таблиця 16. Опис фільтрів пошуку та полів списку перегляду статусу Заяв на нові компоненти адрес). Таблиця 16. Опис фільтрів пошуку та полів списку перегляду статусу Заяв на нові компоненти адрес

   
Рисунок 31. Схема обміну запитами при отримані поточного статусу Заяви  
Рисунок 32 Прототип інтерфейсу для перегляду статусів Заяв на створення нових компонентів адреси  

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

• Токен.
• Дата, за яку необхідні данні.

Вихідні данні:

• Назва адміністративного району міста Києва.
• Кількість зареєстрованих осіб (на дату запиту).
• Кількість зареєстрованих осіб віком від 18 років (на дату запиту).

Метод 2 – для передачі інформації щодо кількості здійснених операцій. Вхідні данні:

• Токен;
• Дата, за яку необхідні данні.

Вихідні данні:

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

Для отримання доступу до API «Вітрина даних» повинна бути зареєстрованою у Модулі авторизації, пройти стандартну процедуру авторизації та автентифікації та надіслати до ІС РТГК наданий токен.

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

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

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

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

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

Інформаційне забезпечення доопрацювань ІС РТГК повинно включати:

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

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

• локальних в межах доопрацювань ІС РТГК;
• відомчих;
• загальнодержавних.

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

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

Програмне забезпечення (ПЗ) доопрацювань ІС РТГК повинне складатися з:

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

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

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

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

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

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

1. Сервер баз даних у кількості: 4

• процесор – 8 core min 2.0 Gz;
• оперативний запам'ятовуючий пристрій – не менше ніж 16 GB;
• дискова підсистема – System: 100Gb, Swap 16Gb, Data: 200Gb;
• операційна система – CentOS 7 64-bit чи Ubuntu 16.0.4 LTS 64-bit;
• тип платформи бази даних – PostgreSQL.

1. Сервер додатків у кількості: 7

• процесор – 8 core min 2.0 Gz;
• оперативний запам'ятовуючий пристрій – не менше ніж 16 GB;
• дискова підсистема – System: 100Gb, Swap 16Gb, Data: 200Gb;
• операційна система – CentOS 7 64-bit чи Ubuntu 16.0.4 LTS 64-bit.

1. Веб-сервер у кількості: 5

• процесор – 8 core min 2.0 Gz;
• оперативний запам'ятовуючий пристрій – не менше ніж 8 GB;
• дискова підсистема – System: 100Gb, Swap 16Gb, Data: 200Gb;
• операційна система – CentOS 7 64-bit чи Ubuntu 16.0.4 LTS 64-bit.

1. КЕП-валідатор

• процесор – 4 core min 2.0 Gz;
• оперативний запам'ятовуючий пристрій – не менше ніж 8 GB;
• дискова підсистема – System: 100Gb, Data: 200Gb;
• операційна система – Windows Server 2012.

1. Технічні засоби комунікаційної мережі (включаючи лінії зв’язку).

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

• робочі станції (локалізовані персональні комп’ютери з монітором діагоналлю не менше 19”) із доступом до мережі та предвставновленим веб-браузером (детальні вимоги будуть надані у відповідних інструкціях).
• лазерний принтер формату А4.

Пристрої записування/читання на CD, DVD, USB.

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

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

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

Вимог до метрологічної сумісності технічних засобів доопрацювань ІС РТГК не пред’являється. Якісні характеристики доопрацювань ІС РТГК перевіряються на випробуваннях згідно з Програмою і методикою випробувань. На вимогу Замовника метрологічна сумісність технічних засобів може бути проведена сторонніми організаціями.

Доопрацювання ІС РТГК повинні розроблятися і функціонувати відповідно до вимог чинного законодавства України. Під час доопрацювання Системи повинні бути розроблені кваліфікаційні вимоги до таких категорій користувачів Системи:

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

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

1. Доопрацювання програмного забезпечення функціональних компонентів, розробка документації:
   • розробка/модернізація програмного забезпечення функціональних компонентів;
   • розробка документації.
2. Проведення попередніх випробувань.
3. Дослідна експлуатація, розробка документації:
   • дослідна експлуатація програмного забезпечення;
   • збір зауважень та коментарів щодо роботи доопрацювань;
   • доопрацювання з метою врахування зауважень;
   • розробка документації.
4. Проведення приймальних випробувань.
5. Навчання відповідальних співробітників Замовника.

Склад документації на Доопрацювання ІС РТГК наведено у Розділі 8 «ВИМОГИ ДО ДОКУМЕНТУВАННЯ».  

Порядок контролю та приймання Доопрацювань ІС РТГК повинні відповідати 3 етапам (див. Таблиця 17. Етапи контролю та приймання доопрацювань ІС РТГК). Таблиця 17. Етапи контролю та приймання доопрацювань ІС РТГК

З метою забезпечення підготовленості об’єкта автоматизації до введення доопрацювань ІС РТГК в дію необхідно:

1. Погодити з Замовником перелік вхідної та вихідної інформації, яка буде надходити в ІС РТГК і оброблятися із застосуванням ЕОМ.
2. Провести навчання відповідальних співробітників Замовника, графік якого буде розроблено Виконавцем та погоджено з Замовником.
3. Забезпечити відповідність комп’ютерного обладнання, на якому повинні розгортатися доопрацювання ІС РТГК, технічним вимогам, що гарантують працездатність програмного забезпечення згідно з технічним завданням.

Склад і зміст документів, що розроблюються, визначаються згідно з ДСТУ 3973-2000, ДСТУ 3974-2000, ГОСТ 34.201-89, РД 50-34.698-90 і ДСТУ 3008-95 і складає:

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

Документація надається на паперових та електронних носіях. Конкретний склад та зміст документації може бути розширений Виконавцем за згодою Замовника. Прикладне програмне забезпечення повинно бути документовано в об’ємі, визначеному діючими стандартами та достатньому для його ефективного використання, містити в своєму складі підказки, оперативну допомогу. Документація повинна бути достатньою за повнотою і змістом для використання обслуговуючим персоналом та користувачами Системи функціональних можливостей Доопрацювань ІС РТГК у повному обсязі.   СПИСОК РИСУНКІВ Рисунок 1. Концептуальна схема логічної архітектури побудови рішення. 28 Рисунок 2. Прототип екранної форми ЕГК підказки про настання події 30 Рисунок 3. Прототип екранної форми ЕГК повідомлення про настання події 31 Рисунок 4. Прототип екранної форми ЕКГ з новим полем «ІПН». 33 Рисунок 5. Прототип екранної форми з повідомленням про факт реєстрації малолітньої дитини у ОЖФ.. 34 Рисунок 6. Прототип екранної форми з повідомленням про наявність реєстрації неповнолітньої особи. 35 Рисунок 7. Прототип екранної форми розділу меню для виконання операції перенесення історії реєстрації/зняття з реєстрації 36 Рисунок 8. Прототип екранної форми для виконання операції перенесення історії реєстрації/зняття з реєстрації в межах однієї будівлі 37 Рисунок 9. Прототип екранної форми для виконання операції перенесення історії реєстрації/зняття з реєстрації з однієї будівлі до іншої 42 Рисунок 10. Прототип екранної форми щодо надання прав до ролі 46 Рисунок 11. Екранна форма з чек-боксом для управління відображенням ПІБ громадян у меню «Витяги» для ролі, яка не має права на перегляд ЕГК.. 47 Рисунок 12. Екранна форма з чек-боксом для управління відображенням ПІБ громадян у меню «Витяги» для ролі, яка має права на перегляд ЕГК.. 48 Рисунок 13. Прототип «Витягу» по приміщенню зі знеособленою інформацією.. 50 Рисунок 14. Прототип екранної форми при формування звіту «Статистика за адресами». 53 Рисунок 15. Прототип документа «Витяг за будинком за період». 54 Рисунок 16. Прототип екранної форми для вибору декількох будинків при формуванні звіту «Кількість зареєстрованих осіб». 56 Рисунок 17. Прототип екранної форми виведення звіту «Кількість зареєстрованих осіб» за декількома будинками. 57 Рисунок 18. Прототип Витягу за декількома будинками. 58 Рисунок 19. Прототип екранної форми щодо надання прав до ролі на доступ до звіту «Кількість зареєстрованих осіб». 60 Рисунок 20. Бізнес процес замовлення та отримання е-послуги «Кількість зареєстрованих за моєю адресою». 63 Рисунок 21. Схема реєстрації користувачів у ІС РТГК з використанням КЕП.. 65 Рисунок 22. Інтерфейс сторінки входу до ІС РТГК.. 66 Рисунок 23. Прототип екранної форми KyivID для входу через КЕП.. 67 Рисунок 24. Схема відправлення повідомлення за шаблоном.. 69 Рисунок 25. Прототип інтерфейсу відправлення повідомлень користувачам за умови ручного формування списку. 70 Рисунок 26. Прототип інтерфейсу відправлення повідомлень користувачам при виборі зі списку користувачів. 71 Рисунок 27. Прототип інтерфейсу історії повідомлень користувачів. 74 Рисунок 28. Схема обміну запитами при створенні нового компонента адреси. 80 Рисунок 29. Прототип інтерфейсу екрана для виклику фрейму на створення нового компоненту адреси. 81 Рисунок 30. Прототип інтерфейсу фрейму Заяви на створення нової вулиці 86 Рисунок 31. Схема обміну запитами при отримані поточного статусу Заяви. 89 Рисунок 32 Прототип інтерфейсу для перегляду статусів Заяв на створення нових компонентів адреси. 90
  СПИСОК ТАБЛИЦЬ Таблиця 1. Перелік подій, за якими відбувається повідомлення користувача. 29 Таблиця 2. Опис поля «ІПН». 32 Таблиця 3. Опис полів фільтра пошуку адреси при перенесенні в межах однієї будівлі 36 Таблиця 4. Опис полів списку приміщень та громадян при перенесення в межах однієї будівлі 38 Таблиця 5. Опис полів фільтра пошуку адреси при перенесенні з однієї будівлі до іншої 40 Таблиця 6. Опис полів списку приміщень та громадян при перенесення з однієї будівлі до іншої 43 Таблиця 7. Результат формування «Витягу по будинку за період» в залежності від комбінації прав доступу ролі 49 Таблиця 8. Опис полів періоду формування звіту «Статистика за адресами». 51 Таблиця 9. Опис полів звіту «Кількість зареєстрованих осіб» за декількома будинками. 58 Таблиця 10. Опис полів Витягу за декількома будинками. 59 Таблиця 11. Опис полів списку для відправлення повідомлень користувачам.. 72 Таблиця 12. Опис фільтрів для пошуку повідомлень в історії 75 Таблиця 13. Опис полів списку історії відправлених повідомлень. 76 Таблиця 14. Базовий набір статусів відповідей (повідомлень) Системи. 78 Таблиця 15. Опис полів фрейму на створення нових компонентів адреси. 82 Таблиця 16. Опис фільтрів пошуку та полів списку перегляду статусу Заяв на нові компоненти адрес. 87 Таблиця 17. Етапи контролю та приймання доопрацювань ІС РТГК.. 98