- [[29038795:index|(Б-21) Реєстр територіальних громад Киева]] - [[.|ІС Реєстр Територіальної Громади міста Києва]] - [[29038795:29038782|Загальні відомості про систему]] - [[29038795:29038782:29038812|Документація]] ====== (Б-21) Реєстр територіальних громад Киева : Технічне завдання 2019 ====== [[download/attachments/29038810/%D0%A0%D0%A2%D0%93%D0%9A%202019%20%20%D0%A0%D0%A2%D0%93%D0%9A%20%D0%A2%D0%97_29.05.2019_final.docx?version=1&modificationDate=1559737290921&api=v2|{{rest/documentConversion/latest/conversion/thumbnail/29039379/1?0x250}}]] \\ |**ЗАТВЕРДЖУЮ** |** **|**ЗАТВЕРДЖУЮ** | |КП «Головний інформаційно-обчислювальний центр» |  |ТОВ «ЕФ ДІ АЙ КАМПАНІ» | |Заступник директора |  |Директор | |%%__%%%%__%%%%__%%%%__%%%%__%%%%__%%%%__%%%%__%%О. П. Перевозник |  |%%__%%%%__%%%%__%%%%__%%%%__%%%%__%%%%__%%%%__%%%%__%%%%__%%_ М. В. Козлов | |«%%__%%%%__%%_» %%__%%%%__%%%%__%%%%__%%%%__%%%%__%%%%__%%%%__%%%%__%% 2019 р.|  |«%%__%%%%__%%_» %%__%%%%__%%%%__%%%%__%%%%__%%%%__%%%%__%%%%__%%%%__%% 2019 р.| \\ ** ** **ТЕХНІЧНЕ ЗАВДАННЯ** **ДООПРАЦЮВАННЯ ІНФОРМАЦІЙНОЇ СИСТЕМИ** **«РЕЄСТР ТЕРИТОРІАЛЬНОЇ ГРОМАДИ МІСТА КИЄВА»** **3 черга** 37770359.184154.4363.ТЗ На %%__%%%%__%% аркушах діє з «%%__%%%%__%%_»%%__%%%%__%%%%__%%%%__%%%%__%%%%__%%%%__%%_2019 року     |**ВІД ЗАМОВНИКА:** |** **|** **|**ВІД ВИКОНАВЦЯ:** | |КП «Головний інформаційно-обчислювальний центр» |  |  |ТОВ «ЕФ ДІ АЙ КАМПАНІ» | |Начальник департаменту планування та управління проектами і програмами\\ \\ %%__%%%%__%%%%__%%%%__%%%%__%%%%__%%%%__%%%%__%%_ Я. В. Гринько\\ \\   |  |  |Керівник проекту\\ \\  \\ \\ %%__%%%%__%%%%__%%%%__%%%%__%%%%__%%%%__%%%%__%%С. Л. Маланіч| |Начальник департаменту розвитку обліково-фінансових систем\\ \\ %%__%%%%__%%%%__%%%%__%%%%__%%%%__%%%%__%%%%__%%А. П. Гусаревич\\ \\ Заступник начальника департаменту планування та управління проектами і програмами\\ \\ %%__%%%%__%%%%__%%%%__%%%%__%%%%__%%%%__%%%%__%%_ Т. Ю. Пудова\\ \\  |  |  |  | Київ  2019 **ЗМІСТ** [[#_Toc10045296|ПЕРЕЛІК ТЕРМІНІВ ТА СКОРОЧЕНЬ.. 5]] [[#_Toc10045297|1 ЗАГАЛЬНІ ВІДОМОСТІ 10]] [[#_Toc10045298|1.1 Повне найменування доопрацювань та їх умовне позначення. 10]] [[#_Toc10045299|1.2 Шифр теми або шифр (номер) договору. 10]] [[#_Toc10045300|1.3 Найменування установ Виконавця і Замовника, їх реквізити. 10]] [[#_Toc10045301|1.4 Перелік документів, на підставі яких здійснюються доопрацювання, ким і коли затверджені ці документи. 10]] [[#_Toc10045302|1.5 Планові терміни початку та закінчення виконання робіт з доопрацювання Системи  14]] [[#_Toc10045303|1.6 Відомості про джерела і порядок фінансування послуг. 14]] [[#_Toc10045304|1.7 Порядок оформлення і пред’явлення Замовникові наданих послуг. 15]] [[#_Toc10045305|2 ПРИЗНАЧЕННЯ ТА ЦІЛІ ДООПРАЦЮВАННЯ СИСТЕМИ.. 16]] [[#_Toc10045306|2.1 Призначення доопрацювань. 16]] [[#_Toc10045307|2.2 Мета здійснення доопрацювань. 16]] [[#_Toc10045308|3 ХАРАКТЕРИСТИКИ ОБ’ЄКТІВ АВТОМАТИЗАЦІЇ 17]] [[#_Toc10045309|3.1 Відомості про об’єкт автоматизації 17]] [[#_Toc10045310|3.2 Умови експлуатації і характеристики навколишнього середовища. 17]] [[#_Toc10045311|4 ВИМОГИ ДО ДООПРАЦЮВАНЬ СИСТЕМИ.. 18]] [[#_Toc10045312|4.1 Вимоги до доопрацювань в цілому. 18]] [[#_Toc10045313|4.1.1 Загальні вимоги. 18]] [[#_Toc10045314|4.1.2 Обмеження на побудову доопрацювань Системи. 18]] [[#_Toc10045315|4.1.3 Принципи побудови доопрацювань Системи. 18]] [[#_Toc10045316|4.1.4 Вимоги до структури і функціонування доопрацювань. 20]] [[#_Toc10045317|4.1.5 Вимоги до чисельності, кваліфікації та режиму персоналу. 21]] [[#_Toc10045318|4.1.6 Вимоги до показників призначення. 22]] [[#_Toc10045319|4.1.7 Вимоги до надійності 22]] [[#_Toc10045320|4.1.8 Вимоги з техніки безпеки. 22]] [[#_Toc10045321|4.1.9 Вимоги до ергономіки і технічної естетики. 23]] [[#_Toc10045322|4.1.10 Вимоги до експлуатації і технічного обслуговування, ремонту та зберігання компонентів доопрацювань. 25]] [[#_Toc10045323|4.1.11 Вимоги до захисту інформації від несанкціонованого доступу. 26]] [[#_Toc10045324|4.1.12 Вимоги до збереження інформації при аваріях. 26]] [[#_Toc10045325|4.1.13 Вимоги до патентної чистоти. 26]] [[#_Toc10045326|4.1.14 Вимоги до стандартизації та уніфікації 27]] [[#_Toc10045327|4.2 Вимоги до функцій (задач), які реалізуються в межах доопрацювань. 27]] [[#_Toc10045328|4.2.1 Перелік програмних компонентів, які розробляються/ модернізуються в межах доопрацювань. 27]] [[#_Toc10045329|4.2.2 Архітектура рішення. 28]] [[#_Toc10045330|4.2.3 Опис вимог до програмних компонентів, які розробляються або модернізуються в межах доопрацювань. 29]] [[#_Toc10045331|4.2.3.1 Вимоги до модернізації програмного компонента «ЕКГ». 29]] [[#_Toc10045332|4.2.3.2 Вимоги до модернізації програмного компонента «Заяви». 34]] [[#_Toc10045333|4.2.3.3 Вимоги до створення програмного компонента щодо перенесення місця проживання/перебування громадян до іншого об’єкта адресації 35]] [[#_Toc10045334|4.2.3.4 Вимоги до розробки нового права доступу до рольової моделі для надання знеособленої інформації громадянам по приміщенням щодо реєстрації/зняття з реєстрації місця проживання/перебування громадян. 45]] [[#_Toc10045335|4.2.3.5 Вимоги до доопрацювання робочого місця користувача «Виконавці комунальних послуг». 51]] [[#_Toc10045336|4.2.3.6 Вимоги до доопрацювання прикладного програмного компонента «Статистичний звіт: Кількість зареєстрованих осіб». 55]] [[#_Toc10045337|4.2.3.7 Вимоги до розробки механізму взаємодії ІС РТГК з ОКК у межах послуги «Електронний сервіс запиту громадянином про кількість зареєстрованих у приміщенні» (для е-послуги ОКК «Кількість жителів, зареєстрованих за моєю адресою»). 61]] [[#_Toc10045338|4.2.3.8 Вимоги до інтеграції ІС РТГК з Модулем авторизації Платформи KYIVSMARTCITY, який є частиною Платформи KYIVSMARTCITY.. 64]] [[#_Toc10045339|4.2.3.9 Вимоги до інтеграції ІС РТГК з Модулем нотифікацій Платформи KYIVSMARTCITY з метою розсилки повідомлень організаціям, які приймають участь у процесі надання послуг користувачам.. 68]] [[#_Toc10045340|4.2.3.10 Вимоги до інтеграції ІС РТГК з Модулем обліку та моніторингу, який є частиною Платформи KYIVSMARTCITY.. 77]] [[#_Toc10045341|4.2.3.11 Вимоги до інтеграції ІС РТГК з СНДІ МКА в частині подання заявок на створення нових компонентів адреси. Вимоги до видів забезпечення. 78]] [[#_Toc10045342|4.2.3.12 Вимоги до розробки механізму обміну даними між ІС РТГК та «Вітриною даних»  91]] [[#_Toc10045343|4.3 Вимоги до видів забезпечення. 92]] [[#_Toc10045344|4.3.1 Вимоги до математичного забезпечення. 92]] [[#_Toc10045345|4.3.2 Вимоги до інформаційного забезпечення. 92]] [[#_Toc10045346|4.3.3 Вимоги до лінгвістичного забезпечення. 92]] [[#_Toc10045347|4.3.4 Вимоги до апаратно-програмного забезпечення. 93]] [[#_Toc10045348|4.3.5 Рекомендовані вимоги до апаратно-технічного забезпечення, включаючи вже існуюче апаратно-технічне забезпечення інформаційної системи РТГК.. 94]] [[#_Toc10045349|4.3.6 Вимоги до технічного забезпечення. 95]] [[#_Toc10045350|4.3.7 Вимоги до метрологічного забезпечення. 95]] [[#_Toc10045351|4.3.8 Вимоги до організаційного забезпечення. 95]] [[#_Toc10045352|4.3.9 Вимоги до методичного забезпечення. 96]] [[#_Toc10045353|5 СКЛАД ТА ЗМІСТ ПОСЛУГ ПО ВИКОНАННЮ ДООПРАЦЮВАНЬ СИСТЕМИ.. 97]] [[#_Toc10045354|6 ПОРЯДОК КОНТРОЛЮ ТА ПРИЙМАННЯ ДООПРАЦЮВАНЬ СИСТЕМИ.. 98]] [[#_Toc10045355|7 ВИМОГИ ДО СКЛАДУ ТА ЗМІСТУ РОБІТ З ВВЕДЕННЯ ДООПРАЦЮВАНЬ СИСТЕМИ В ДІЮ.... 99]] [[#_Toc10045356|8 ВИМОГИ ДО ДОКУМЕНТУВАННЯ.. 100]] [[#_Toc10045357|СПИСОК РИСУНКІВ.. 101]] [[#_Toc10045358|СПИСОК ТАБЛИЦЬ.. 103]] [[#_Toc10045359|ЛИСТ РЕЄСТРАЦІЇ ЗМІН.. 104]] \\   ПЕРЕЛІК ТЕРМІНІВ ТА СКОРОЧЕНЬ ^**№ з/п**^**Термін** ^ ^**Значення** ^ |1.       | |API|Набір готових класів, процедур, функцій, структур і констант, що надаються додатком (бібліотекою, сервісом) для використання в зовнішніх програмних продуктах  (англ. Application Programming Interface) http://en.wikipedia.org/wiki/Application_programming_interface | |2.       |BankID | |Унікальний ідентифікатор жителя міста, за допомогою якого буде визначатися його інформаційний профайл. | |3.       |BPEL | |Скорочення від WS-BPEL (англ. Web Services Business Process Execution Language) — стандарт OASIS, мова на основі XML для формального опису бізнес-процесів і протоколів їх взаємодії між собою. BPEL є одним із засобів реалізації сервісно-орієнтованого підходу до створення додатків. | |4.       |BPMN | |Нотація і модель бізнес-процесів – система умовних позначень (нотацій) для моделювання бізнес-процесів (англ. BusinessProcessModelandNotation). | |5.       |CRUD (Create, Read, Update, Delete) | |Скорочене найменування чотирьох базових функцій управління даними: створення, читання, редагування та видалення. | |6.       |ID_RTGK | |Ідентифікатор громадянина у ІС РТГК. | |7.       |JDBC | |[[https://uk.wikipedia.org/wiki/%D0%9F%D1%80%D0%B8%D0%BA%D0%BB%D0%B0%D0%B4%D0%BD%D0%B8%D0%B9_%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BD%D0%B8%D0%B9_%D1%96%D0%BD%D1%82%D0%B5%D1%80%D1%84%D0%B5%D0%B9%D1%81|Прикладний програмний інтерфейс]] [[https://uk.wikipedia.org/wiki/Java|Java]], який визначає методи, з допомогою яких програмне забезпечення на Java здійснює доступ до [[https://uk.wikipedia.org/wiki/%D0%91%D0%B0%D0%B7%D0%B0_%D0%B4%D0%B0%D0%BD%D0%B8%D1%85|бази даних]]. JDBC - це платформо-незалежний промисловий стандарт взаємодії Java-[[https://uk.wikipedia.org/wiki/%D0%97%D0%B0%D1%81%D1%82%D0%BE%D1%81%D1%83%D0%BD%D0%BE%D0%BA|застосунків]] з різноманітними [[https://uk.wikipedia.org/wiki/%D0%A1%D0%A3%D0%91%D0%94|СУБД]], реалізований у вигляді пакета java.sql, що входить до складу (англ. Java Data Base Connectivity).| |8.       |JMS | |Стандарт проміжного ПЗ для розсилання повідомлень, який дозволяє додаткам, що розроблені на платформі J2EE, створювати, посилати, отримувати та читати повідомлення. Повідомлення стає в чергу адресата і може бути прочитаним будь-коли (англ. Java Message Service). | |9.       |JSON | |Текстовий формат обміну даними, заснований на JavaScript. | |10.   |Kyiv ID | |Унікальний ідентифікатор жителя міста, за допомогою якого буде визначатися його інформаційний профайл. | |11.   |OAuth2 | |Протокол авторизації, що дозволяє видати одному сервісу (із застосунками) права на доступ до ресурсів користувача на іншому сервісі. Протокол позбавляє від необхідності довіряти застосунку логін і пароль, а також дозволяє видавати обмежений набір прав, а не всі права одразу. | |12.   |Open ID | |Відкритий протокол автентифікації, який дозволяє отримати третій стороні обмежений доступ до захищених ресурсів користувача без необхідності передавати їй (третій стороні) логін та пароль. | |13.   |PL | |[[https://uk.wikipedia.org/wiki/%D0%9C%D0%BE%D0%B2%D0%B0_%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D1%83%D0%B2%D0%B0%D0%BD%D0%BD%D1%8F|Мова програмування]], яка використовується для доступу до баз даних [[https://uk.wikipedia.org/wiki/Oracle_Database|Oracle]]. | |14.   |Profile ID | |Ідентифікатор майстер-профілю МР сутності «Житель» в ІС МР. Потрібен для об'єднання відповідних профілів МР в одну сутність при запитах ЗІС на отримання даних про конкретну людину. Присвоюється в ІС МР під час створеня профілю МР (першому отримані даних від джерела). | |15.   |REST API | |[[https://uk.wikipedia.org/wiki/%D0%9F%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BD%D0%B8%D0%B9_%D1%96%D0%BD%D1%82%D0%B5%D1%80%D1%84%D0%B5%D0%B9%D1%81|Програмний інтерфейс]] для написання надбудов та інтеграції зі стороннім ПЗ (англ. Representational State Transfer). | |16.   |SID | |Референтна модель даних (англ. Shared Information and Data Model). | |17.   |Автентифікація | |Перевірка належності користувачу ідентифікатора, що він пред’явив; підтвердження автентичності. | |18.   |Автоматизована система | |Будь-яке прикладне рішення, яке автоматизуватиме процес взаємодії користувача та компанії. | |19.   |АРМ | |Автоматизоване робоче місце користувача. | |20.   |БП | |Бізнес-процес. | |21.   |Веб-ресурс/сайт | |Сукупність веб-сторінок, що згруповані за темами, сервісами, функціональними можливостями та призначені для розміщення інформації. Кожний веб-ресурс має власну адресу. | |22.   |Веб-сервіс | |Програмна система, що ідентифікується рядком URI (UniformResourceIdentifier), чиї загальнодоступні інтерфейси визначені на мові XML або JSON. Опис цієї програмної системи може бути знайдено іншими програмними системами, які можуть взаємодіяти з нею згідно з цим описом за допомогою повідомлень, що засновані на XML/JSON та передаються за допомогою інтернет-протоколів. | |23.   |Відвідування | |Період взаємодії між браузером відвідувача та певним сайтом, що закінчується при закритті вікна браузера, завершенні роботи в браузері або не активності користувача на цьому сайті протягом визначеного часу. | |24.   |ЕКГ | |Електронна картка громадянина – електронний еквівалент інформаційної картки в базі даних, яка містить персональну інформацію про громадянина у кількості та якості, необхідної для проведення операцій в Реєстрі. ЕКГ уніфікована і не залежіть від ролі або функції, яку громадянин виконує під час здійснення операцій з РТГК. Паперовим аналогом є Картка реєстрації особи (форма 16). | |25.   |ЕОМ | |Електронна обчислювальна машина. | |26.   |Е-послуга | |Послуга, яка надається громадянину в електронному вигляді через спеціалізований веб-додаток. | |27.   |Житель | |Громадянин, який зареєстрований, мешкає, працює у      м. Києві, гості м. Києва. | |28.   |ЗІС | |Зовнішніми інформаційними системами. | |29.   |ЗПЗ | |Загальносистемне програмне забезпечення. | |30.   |ІС МР | |Інформаційна система «Муніципальний реєстр» – це автоматизована система управління реєстром жителів міста Києва \\ \\ (https://prozorro.gov.ua/tender/UA-2018-07-10-001517-c). | |31.   |ІС РТГК (Система) | |Інформаційна система «Реєстр територіальної громади м. Києва» \\ \\ (https://prozorro.gov.ua/tender/UA-2018-04-19-000476-c). | |32.   |Користувач | |Фізична або юридична особа, яка використовує Систему для рішення завдань, що стоять перед даною особою. | |33.   |КЕП | |Кваліфікований електронний підпис - удосконалений електронний підпис, який створюється з використанням засобу кваліфікованого електронного підпису і базується на кваліфікованому сертифікаті відкритого ключа. | |34.   |Малолітня особа/малолітній громадянин | |Особа, якій ще не виповнилося 14 років. | |35.   |Модуль авторизації  | |Комп’ютерна програма «Urbio Модуль авторизації» (Єдиний модуль обліку та управління користувачами та ЗІС) Платформи KYIVSMARTCITY, яка забезпечує єдину точку входу користувачів та ЗІС до Платформи KYIVSMARTCITY для реєстрації, автентифікації, авторизації та ідентифікації за умови підключення до Платформи KYIVSMARTCITY. | |36.   |Модуль нотифікацій | |Комп’ютерна програма «Urbio Модуль нотифікацій» (Єдиний модуль обліку та управління нотифікаціями) Платформи KYIVSMARTCITY, яка забезпечує відправку повідомлень користувачам ЗІС за умови підключення до Платформи KYIVSMARTCITY. Повідомлення відправляються за відповідними шаблонами з урахуванням підписки. | |37.   |Модуль обліку та моніторингу | |Комп’ютерна програма «Urbio Модуль обліку та моніторингу» (Єдиний модуль логування та моніторингу) Платформи KYIVSMARTCITY, яка забезпечує збір та обробку (пошук, перегляд) логів та метрик усіх ЗІС за умови підключення до Платформи KYIVSMARTCITY. | |38.   |МПП | |Місце проживання/перебування. | |39.   |ОКК | |Інформаційна система «Особистий кабінет киянина» (https://prozorro.gov.ua/tender/UA-2018-10-23-001069-a). | |40.   |ОЖФ | |Об’єкт житлового фонду – кінцеве приміщення, яке може використовуватися як місце для проживання та / або перебування особою. ОЖФ можуть бути різними за типами та відносно них можуть бути в подальшому організовані додаткові процедури та атрибути обліку. ОЖФ - це узагальнена назва для всіх типів житлових приміщень. | |41.   |ОСББ | |Об'єднання співвласників багатоквартирного будинку. | |42.   |Платформа KYIVSMARTCITY | |Єдина міська платформа електронної взаємодії, управління даними та сервісами, https://www.prozorro.gov.ua/tender/\\ \\ UA-2018-05-05-000852-b. | |43.   |ПК | |Персональний комп’ютер. | |44.   |Послуга «Електронний сервіс запиту громадянином кількості зареєстрованих у приміщенні»| |Технічна назва е-послуги, що надається громадянину України засобами ОКК щодо отримання інформації про кількість зареєстрованих громадян у приміщенні, в якому зареєстровано громадянина, який отримує послугу. \\ \\ Назва е-послуги в ОКК визначається вимогами на модернізацію ОКК та може бути іншою, наприклад «Кількість жителів, зареєстрованих за моєю адресою». | |45.   |Пошуковий запит | |Слово/фраза, що використовується для внутрішнього пошуку по сайту. | |46.   |ППЗ | |Прикладне програмне забезпечення. | |47.   |Реєстрація користувача | |Занесення користувача в список користувачів ІС «РТГК» (або Системи), взяття на облік. У процесі реєстрації користувач вказує Системі свій ідентифікатор (логін) та пароль, які Система перевіряє та зберігає. | |48.   |РТГ ВКП | |Робоче місце користувача «Виконавці комунальних послуг» (Реєстр територіальної громади для Виконавців комунальних послуг). | |49.   |РТГК | |Реєстр територіальної громади м. Києва. (https://prozorro.gov.ua/tender/UA-2018-04-19-000476-c).  | |50.   |СВПЗ | |Середовище для виконання пошукових запитів. | |51.   |СНДІ МКА | |Система нормативно-довідникової інформації м. Києва Модуль консолідації адрес. | |52.   |СКБД | |Система керування базами даних. | |53.   |ТГ | |Територіальна громада – жителі, об'єднані постійним проживанням у межах села, селища, міста, що є самостійними адміністративно-територіальними одиницями або добровільне об'єднання жителів кількох сіл, що мають єдиний адміністративний центр. | |54.   |Тег | |Елемент розмітки мови HTML, мітка-ідентифікатор для завдання внутрішньої структури документа. | |55.   |Токен | |Код (Securitycode), який видається під час автентифікації. Надає право доступу до відповідного ресурсу, та діє обмежений час тільки в межах поточної сесії. | |56.   |Фрейм | |Область вікна браузера для подання окремої веб-сторінки, в тому числі сторінки з іншої інформаційної системи. | |57.   |ЦБД | |Центральна база даних. | |58.   |ЦНАП | |Центр надання адміністративних послуг. | | | | | |     ====== 1 ЗАГАЛЬНІ ВІДОМОСТІ ====== ===== 1.1 Повне найменування доопрацювань та їх умовне позначення ===== Найменування: доопрацювання інформаційної системи «Реєстр територіальної громади м. Києва», 3 черга. Скорочена назва: доопрацювання «ІС РТГК». Умовне позначення: ІС РТГК або Система. ===== 1.2 Шифр теми або шифр (номер) договору ===== Договір про надання послуг від 10 квітня 2019 року № 4627. Шифр роботи: ІС РТГК. ===== 1.3 Найменування установ Виконавця і Замовника, їх реквізити ===== Замовником доопрацювань ІС РТГК є комунальне підприємство «Головний інформаційно-обчислювальний центр». Адреса та реквізити Замовника: 02192, м. Київ-192 вул. Космічна, 12а; код ЄДРПОУ 04013755 п/р № 35442136091290 ГУ ДКСУ у м. Києві, МФО 820019 ІПН: 040137526538 Свідоцтво № 100093243 Виконавцем є товариство з обмеженою відповідальністю «ЕФ ДI АЙ КАМПАНI». Адреса та реквізити Виконавця: 01032, м. Київ, бульвар Тараса Шевченка, 62 код ЄДРПОУ  37770359 Реквізити: п/р 2600825709 в ПАТ «ПУМБ» у м. Києві МФО 334851 ІПН 377703526578 Свідоцтво платника ПДВ №200088431 Платник податку на прибуток на загальних підставах Тел: (044) 337-03-91 Email: ===== 1.4 Перелік документів, на підставі яких здійснюються доопрацювання, ким і коли затверджені ці документи ===== Під час розробки доопрацювань необхідно користуватися такими нормативно-правовими актами та національними і міжнародними стандартами, як:Конституція України; * Закон України «Про внесення змін до деяких законодавчих актів України щодо розширення повноважень органів місцевого самоврядування та оптимізації надання адміністративних послуг»; * Закон України «Про Єдиний державний демографічний реєстр та документи, що підтверджують громадянство України, посвідчують особу чи її спеціальний статус»; * Закон України «Про Державний реєстр виборців»; * Закон України «Про адміністративні послуги»; * Закон України «Про інформацію»; * Закон України «Про електронні документи та електронний документообіг»; * Закон України «Про доступ до публічної інформації»; * Закон України «Про захист інформації в інформаційно-телекомунікаційних системах»; * Закон України «Про електронний цифровий підпис»; * Закон України «Про захист персональних даних»; * Закон України «Про свободу пересування та вільний вибір місця проживання в Україні»; * Закон України «Про внесення змін до деяких законодавчих актів України щодо документів, що підтверджують громадянство України, посвідчують особу чи її спеціальний статус, спрямованих на лібералізацію Європейським Союзом візового режиму для України»; * Постанови Кабінету Міністрів України від 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 м. Київ. «Деякі питання цифрового розвитку». ===== 1.5 Планові терміни початку та закінчення виконання робіт з доопрацювання Системи ===== Терміни виконання робіт з доопрацювання системи визначаються Договором про надання послуг від 10.04.2019р. № 4627. ===== 1.6 Відомості про джерела і порядок фінансування послуг ===== Джерело фінансування послуг – бюджетні кошти. ===== 1.7 Порядок оформлення і пред’явлення Замовникові наданих послуг ===== Порядок оформлення і пред’явлення наданих послуг визначається умовами Договору про надання послуг від 10.04.2019 № 4627. Результатом надання послуг є: - Працездатна копія програми (серверна частина) на оптичному диску зі службовою програмою автоматичної установки. - Комплект документації у складі, обумовленому в цьому ТЗ. - Встановлена виконавцем програмна частина доопрацювань ІС РТГК на виділений сервер з боку Замовника. - Продемонстрована та перевірена згідно з процедурою тестування та приймання працездатність та відповідна функціональність доопрацювання ІС РТГК на тестових перевірочних даних. ====== 2 ПРИЗНАЧЕННЯ ТА ЦІЛІ ДООПРАЦЮВАННЯ СИСТЕМИ ====== ===== 2.1 Призначення доопрацювань ===== Доопрацювання ІС РТГК призначено для: * модернізації та розширення функціональності Системи шляхом створення додаткового комплексу програмних засобів та сервісів, які забезпечують автоматизацію, спрощення та прискорення процесів надання адміністративних послуг з реєстрації / зняття з реєстрації місця проживання / перебування громадян; * автоматизації взаємодії з зацікавленими організаціями, які приймають участь у процесі надання послуг громадянам з урахуванням сучасного стану розвитку інформаційних технологій та вимог до архітектури міських інформаційних систем. ===== 2.2 Мета здійснення доопрацювань ===== Метою доопрацювання ІС РТГК є: * удосконалення процедури обслуговування громадян в частині попередження користувачів під час виконання операцій, що стосуються малолітніх осіб та під час обслуговування громадян, в яких закінчився термін дії паспорта; * створення додаткового комплексу програмних засобів та сервісів для можливості перенесення реєстрації місця проживання/перебування громадян за списком; * автоматизація процесів взаємодії з новими організаціями в частині отримання знеособленої інформації щодо реєстрації громадян; * розширення функціональності (модернізація) Системи шляхом інтеграції з іншими інформаційними системами, що є частинами Платформи KYIVSMARTCITY. ====== 3 ХАРАКТЕРИСТИКИ ОБ’ЄКТІВ АВТОМАТИЗАЦІЇ ====== ===== 3.1 Відомості про об’єкт автоматизації ===== Об’єктами автоматизації є процеси, пов’язані з реєстрацією та/або зняттям з реєстрації місць проживання/перебування громадян, які забезпечуються: * підрозділами **Департаменту з питань реєстрації виконавчого органу Київської міської ради (Київської міської державної адміністрації);** * відділами з питань реєстрації місця проживання/перебування фізичних осіб при районних державних адміністраціях в м. Києві; * іншими організаціями, що здійснюють обслуговування громадян та мають право перегляду інформації щодо місця реєстрації проживання громадян. Також до Системи можуть бути підключені зовнішні користувачі (організації) з обмеженими правами, які приймають участь у процесі надання адміністративних послуг. Кількість таких користувачів не регламентовано. Місцем розташування серверної інфраструктури та серверної частини програмного комплексу є серверні потужності на майданчику КП ГІОЦ. Автоматизовані робочі місця співробітників, які мають безпосередній доступ до адміністрування ІС РТГК, розташовані в приміщеннях КП ГІОЦ. В межах одного будинку робочі місця підключені до локальної обчислювальної мережі з централізованим підключенням до інтернету. Всі бази даних повинні бути розташовані на відповідних серверах на вищевказаному майданчику КП ГІОЦ. ===== 3.2 Умови експлуатації і характеристики навколишнього середовища ===== Приміщення, в яких буде розташоване обладнання автоматизованих робочих місць, повинні відповідати вимогам діючих норм та правил. Приміщення кабінетів, де будуть розміщені робочі місця, повинно(ні) мати обмежений доступ сторонніх осіб, природне освітлення та бути забезпечені: * штучним та аварійним освітленням; * природною вентиляцією; * основним та резервним джерелами живлення електрообладнання; * стаціонарним телефонним зв’язком; * захисним заземленням та засобами захисту апаратури від розрядів блискавки; * первинними засобами пожежогасіння та пожежною сигналізацією. Забезпечення у приміщеннях кліматичних та інших умов для експлуатації роботи обладнання не є предметом цієї роботи і покладається на Замовника. У приміщеннях, в яких встановлено серверне та телекомунікаційне обладнання, відповідно до ГОСТ 15150-69 повинні бути штучно створені кліматичні умови з такими параметрами: * температура навколишнього середовища від +10 С до + 35 С; * відносна вологість повітря не більше 80% при температурі +25 С; * атмосферний тиск від 650 мм рт. ст. до 800 мм рт. ст. ====== 4 ВИМОГИ ДО ДООПРАЦЮВАНЬ СИСТЕМИ ====== ===== 4.1 Вимоги до доопрацювань в цілому ===== ==== 4.1.1 Загальні вимоги ==== Доопрацювання повинні будуватись на базі раніше створеної централізованої програмно-технологічної платформи ІС РТГК з уніфікацією програмно-технічних засобів розробки (модернізації) прикладної функціональності з використанням сучасних веб-портальних сервісно-орієнтованих технологій. Функціонально доопрацювання повинні бути інтегровані в існуючу ІС РТГК та уніфіковані з точки зору програмно-апаратної платформи. Базовими компонентами доопрацювань мають бути програмні комплекси сервісів, що забезпечують реалізацію додаткової функціональності ІС РТГК. Доопрацьована ІС РТГК повинна забезпечувати уніфікований та комфортний, максимально простий та інтуїтивно зрозумілий інтерфейс користувача. Технологічна гнучкість, надійність роботи при модифікації та розширенні функціонального складу, скорочення часу та сукупних витрат на розробку та підтримку компонентів доопрацювань ІС РТГК повинні досягатись за рахунок реалізації принципів стандартизації та уніфікації, а саме: * уніфікованих правил структурної побудови та/або модернізації та організації прикладних програмних компонентів, їх взаємодії між собою; * стандартизації вимог до побудови та/або модернізації єдиної централізованої бази даних, формування єдиних вимог до класифікації об’єктів та їх атрибутивного складу; * уніфікації правил побудови та/або модернізації інформаційної взаємодії з іншими інформаційними системами. ==== 4.1.2 Обмеження на побудову доопрацювань Системи ==== При доопрацюванні ІС РТГК необхідно врахувати наявність таких обмежень: * велика кількість установ місцевої та/або державної влади – від 1000 та більше, які можуть підключатися до Системи у якості користувачів з обмеженим доступом по API; * підрозділи, які використовують функціональність Системи і мають територіальну ознаку – місто Київ. ==== 4.1.3 Принципи побудови доопрацювань Системи ==== З урахуванням обмежень доопрацювання ІС РТГК повинні бути побудовані на таких принципах: * Централізація: доопрацювання ІС РТГК повинні вирішувати завдання, пов’язані з забезпеченням доступу до всіх об’єктів обліку (громадяни, об’єкти житлового фонду, записи у Реєстрі територіальної громади м. Києва та інше) та до відповідних довідкових та статистичних систем в межах Київської територіальної громади. Для вирішення цих завдань створюється Центральна база даних (ЦБД). Забезпечується централізоване ведення користувачів та загальносистемних довідників і класифікаторів. * Стандартизація: стандартизація та централізація ведення довідників та класифікаторів. Підтримку довідників та класифікаторів необхідно забезпечити в автоматичному режимі шляхом стандартизованої програмної взаємодії з розпорядником відповідного інформаційного ресурсу. Якщо таке автоматичне оновлення має певні технічні та технологічні обмеження, підтримувати дані в актуальному стані повинен окремо виділений адміністратор даних. * Мінімальна достатність серверних потужностей: доопрацювання ІС РТГК не повинні вимагати обов’язкової установки серверів у будь-яку установу або підрозділ. * Безпека та надійність: у зв’язку з тим, що доопрацювання ІС РТГК мають працювати з персональними даними, Система повинна підтримувати необхідні технології безпеки зберігання, доступу та обробки інформації у відповідності до діючих законів та нормативів (детальніше у відповідних розділах цього ТЗ). * Мінімізація числа операцій: доопрацювання ІС РТГК повинні забезпечувати одноразове внесення інформації в процесі надання адміністративної послуги з реєстрації / зняття з реєстрації без повторного внесення даних в різноманітні документи та форми. * Стандарти відкритих систем, які забезпечують сумісність та інтегрованість між різним програмним забезпеченням та або їх модулями. * Підтримка функціонування в різнорідному апаратному та програмному середовищах (для клієнтської частини). * Вбудованість механізмів захисту від помилок і підтримка цілісності. * Мінімальні витрати на закупівлю і експлуатацію супутнього ПЗ та обладнання. * Орієнтація на користувача: потреби користувачів та суб’єктів звернення мають визначати перелік та способи реалізації функцій та властивостей доопрацювань ІС РТГК. * Дебюрократизація та адміністративне спрощення: розвиток системи реєстрації МПП має на меті спрощення порядків надання та зменшення кількості адміністративних послуг, у тому числі через запровадження міжвідомчої електронної взаємодії. * Збереження електронної інформації: принцип полягає у забезпеченні цілісності та достовірності інформації про дії суб’єктів надання адміністративних послуг з реєстрації МПП, пов’язані з отримання персональних даних про суб’єктів звернення з можливістю доступу суб’єктів звернення до такої інформації. * Ефективність і результативність: запровадження ІС РТГК повинно відбуватись з урахуванням досягнення конкретних показників щодо ефективності та результативності їх надання, у тому числі економії бюджетних коштів та підвищення задоволеності суб’єктів звернення. ==== 4.1.4 Вимоги до структури і функціонування доопрацювань ==== Доопрацювання ІС РТГК повинні функціонувати як додаткова частина у межах діючої Системи з використанням єдиного сховища даних для користувачів всіх рівнів ієрархії, встановивши кожному свій рівень доступу до інформації. Доопрацювання ІС РТГК повинні будуватись на основі реалізації трирівневої сервісно-орієнтованої клієнт-серверної архітектури у складі таких рівнів/слоїв: * сховище даних на базі СКБД PostgreSQL; * рівень серверу застосувань; * рівень представлення веб-серверу. Рівень серверів застосувань повинен складатись із таких взаємопов’язаних компонентів: * сервіси загальносистемних засобів та реалізації бізнес-логіки прикладної функціональності; * сервіси інформаційної взаємодії з іншими компонентами та інформаційними системами. Обмін інформацією між сервером застосувань, клієнтською частиною доопрацювань ІС РТГК та іншими зовнішніми системами повинен реалізовуватись на рівні ХМL-документів із застосуванням технології веб-сервісів на базі JSON API. Компоненти серверу застосувань реалізації серверної бізнес-логіки призначені для: * створення серверних служб доступу до об’єктів та бізнес-логіки прикладної функціональності у відповідності до функціональних задач; * реалізації загальносистемних функцій засобів ідентифікації та автентифікації уповноважених користувачів; * перевірки прав доступу; * аудиту дій; * уніфікованих механізмів формування функціональності клієнтських застосунків. Компоненти серверу застосувань сервісів інформаційної взаємодії призначені для забезпечення ведення регламентів взаємодії та механізмів інформаційного обміну. Рівень представлення повинен забезпечувати реалізацію прикладної функціональності клієнтських робочих місць. Доопрацювання ІС РТГК поділяються на два інформаційні рівні: * центральний рівень; * рівень користувача. Центральний рівень – рівень, який забезпечує роботу бази даних (БД), сервісів авторизації та автентифікації користувачів, сервісів обробки запитів та виконання процедур та інших загальних інформаційних ресурсів доопрацювань ІС РТГК. Рівень користувача – організації з надійними та швидкісними каналами зв’язку, які є споживачами адресної інформації та мають віддалений доступ до ІС РТГК. Користувачі можуть бути авторизованими та мати безпосередній доступ до доопрацювань ІС РТГК з правом читання/запису або неавторизованими, які мають доступ до доопрацювань ІС РТГК через спеціалізовані програмні протоколи доступу. Центральний інформаційний рівень фізично розгортається на серверах майданчика КП ГІОЦ. Інформаційний рівень авторизованих користувачів не потребує особливих дій або умов по розгортанню та обмежується встановленням браузерів для перегляду та використання стандартних веб-сервісів. ==== 4.1.5 Вимоги до чисельності, кваліфікації та режиму персоналу ==== Рішення щодо кількості персоналу Замовник приймає самостійно в залежності від навантаження та операційної необхідності. Вимоги до персоналу Системи: * «Супервізор» – має доступи до всіх функцій та операцій Системи, відповідає за функціонування програмно-технічного комплексу; * «Адміністратор» – відповідає за функціонування програмно-технічного комплексу в цілому; * «Шеф» – відповідає за наповнення, обробку, актуалізацію та видалення даних з довідників Системи; * «Уповноважені» – відповідає за наповнення, обробку та актуалізацію довідників Системи; * Сторонні – співробітники організацій (нотаріуси тощо), що надають послуги громадянам та мають право переглядати/використовувати данні ІС РТГК, але не мають права вносити зміни.                    Вимоги до кваліфікації персоналу, порядку його підготовки та контролю знань та навичок: * «Супервізор» – повинен мати вищу профільну освіту з адмініструванням баз даних; * «Адміністратор» – повинен мати профільну освіту або сертифікати про закінчення курсів, пов’язаних з адмініструванням баз даних, захистом інформації; * «Шеф» – повинен мати вищу профільну освіту; * «Уповноважені» – повинні мати вищу профільну освіту; * Сторонні – повинні володіти навичками роботи з ПК, інші вимоги межами цього ТЗ не визначаються.                    У даному розділі описані вимоги до персоналу. АРМ являтиме собою консолідоване програмне рішення з уніфікованою рольовою моделлю, доступ до функціональності якого надаватиметься за визначеним переліком ролей. ==== 4.1.6 Вимоги до показників призначення ==== Доопрацювання ІС РТГК повинні забезпечувати: * обслуговування одночасної роботи до 5000 користувачів; * час обробки запитів та відображення інформації на сторінці – не більше ніж 5 сек; * первісне завантаження будь-якої веб-сторінки – не більше 4 сек. ==== 4.1.7 Вимоги до надійності ==== Експлуатація доопрацювань ІС РТГК повинна передбачати такі режими функціонування: * Основний режим – режим штатного функціонування всіх компонентів за своїм призначенням. * Режим адміністрування – режим здійснення централізованого автоматизованого налагоджування та автоматизованого оновлення даних одночасно з роботою решти користувачів в основному режимі або в режимі технічного обслуговування. Надійність доопрацювань повинна бути забезпечена за такими напрямками: * забезпечення працездатності компонентів програмно-технічної платформи; * збереження даних. Збереження працездатності повинно забезпечувати надійність роботи під час відмови одного або декількох компонентів за рахунок їх резервування. При цьому повинна вимагатися мінімальна увага з боку адміністратора щодо реакції на усунення наслідків відмов компонентів, а також програмно-апаратними засобами повинно бути забезпечене збереження даних. Збереження даних повинно забезпечувати збереження цілісності даних під час програмно-апаратних збоїв, відмов, помилок шляхом використання відповідних програмно-апаратних засобів та рішень, резервного копіювання, транзакційності при змінах даних. ==== 4.1.8 Вимоги з техніки безпеки ==== Проектні рішення щодо доопрацювань ІС РТГК повинні передбачати заходи та процедури з експлуатації, які узгоджуються з вимогами документа «Про затвердження Правил охорони праці під час експлуатації електронно-обчислювальних машин», затверджених наказом Державного комітету України з промислової безпеки, охорони праці та гірничого нагляду від 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. Під час наладки та експлуатації технічних засобів повинні виконуватись усі вимоги правил техніки безпеки та правил встановлення та експлуатації електрообладнання. ==== 4.1.9 Вимоги до ергономіки і технічної естетики ==== Рішення щодо ергономіки доопрацювань ІС РТГК повинні відповідати вимогам технічної естетики та інженерної психології для забезпечення гармонійного зв'язку між параметрами технічних засобів і психофізичними можливостями людини з урахуванням створення єдиного об’ємно-просторового і кольорового рішення відповідно до ГОСТ 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). Основні вимоги до інформаційно-графічних елементів веб-інтерфейсу: - Коректне типізоване відображення (сумісність) інформації в передостанніх версіях найбільш популярних веб-браузерів: * Chromе; * Mozilla Firefox; - Графічний і структурний дизайни повинні враховувати (підлаштовуватись) плавну зміну розміру вікна веб-браузера. - Всі екранні форми користувальницького інтерфейсу повинні бути виконані в єдиному графічному дизайні з однаковим розташуванням основних елементів управління і навігації. Схожі операції повинні виконуватися з використанням ідентичних графічних елементів у повній відповідності до побудови (структури) інформаційної архітектури рішення. Рішення щодо ергономіки доопрацювань ІС РТГК повинні забезпечувати: * прості інтуїтивно-зрозумілі інтерфейси, які не потребують тривалого навчання роботі з ними; * форми відображення інформації користувачам, що функціонально орієнтовані на вирішення конкретних завдань; * мінімальну кількість дій користувача при виконанні завдань в Системі, відсутність в екранних формах функціональних можливостей, що не потрібні для виконання завдання, яке поставлене перед користувачем; * вбудовані механізми валідації значень, що визначаються для окремих полів, комбінацій полів (контекстно-залежний контроль), контроль значень полів за довідниками/класифікаторами, а також на відповідність вже введеним даним (базі даних); валідація буде проводитися як на фронт-частині програмного комплексу, так і на серверній, що дозволить контролювати цілісність даних на всіх етапах обробки введених даних; * вбудовані механізми допомоги внесення та отримання інформації, контекстні підказки. ==== 4.1.10 Вимоги до експлуатації і технічного обслуговування, ремонту та зберігання компонентів доопрацювань ==== Експлуатація доопрацювань ІС РТГК повинна виконуватися в умовах, що забезпечують її нормальне функціонування згідно з вимогами виробників програмного і технічного забезпечення та діючими нормативними документами. Експлуатація доопрацювань ІС РТГК повинна виконуватися за такими принципами: * технічний супровід та технічна підтримка вузлів доопрацювань ІС РТГК виконуються технічним персоналом Замовника та/або фахівцями Виконавця згідно з вимогами виробників обладнання та програмного забезпечення, які надаються Виконавцем у вигляді інструкцій з експлуатації; * склад та регламент робіт з технічного супроводу та підтримки доопрацювань ІС РТГК, кількість і кваліфікація технічного персоналу повинні відповідати вимогам виробників програмно-технічних засобів і бути узгодженими з Замовником; * проведення робіт з профілактики і ремонту окремих компонентів та блоків доопрацювань ІС РТГК не повинно порушувати роботу всієї Системи; * технічний та фізичний захист і збереженість апаратних компонентів доопрацювань ІС РТГК та носіїв даних, безперебійне електропостачання, резервування ресурсів, поточне обслуговування забезпечується технічними та організаційними засобами, передбаченими в структурі Замовника; * електроживлення технічних засобів доопрацювань ІС РТГК повинно здійснюватися від електромережі змінного струму напругою 220В з частотою 50 Гц; * приміщення, в яких експлуатуватиметься серверне обладнання, повинні відповідати вимогам виробників обладнання щодо розміру площі, необхідної для розміщення апаратури, та наявності системи кондиціювання повітря; * приміщення, де розміщується обладнання доопрацювань ІС РТГК мають бути обладнані індивідуальним контуром заземлення; * нормальними умовами для експлуатації АРМ користувачів повинні бути: * температура навколишнього повітря: +20±5 С°; * атмосферний тиск: 630-800 мм.рт.ст.; * відносна вологість повітря: 60±15 %. ==== 4.1.11 Вимоги до захисту інформації від несанкціонованого доступу ==== Вимоги щодо КСЗІ можуть визначатися в окремих Технічних вимогах в межах окремої конкурсної процедури. При підключенні віддалених користувачів до ІС РТГК повинні використовуватися засоби криптографічного захисту, які мають позитивний експертний висновок Державної служби спеціального зв’язку та захисту інформації України. На всіх робочих станціях користувачів ІС РТГК повинно бути встановлене антивірусне програмне забезпечення. Ідентифікація користувачів в ІС РТГК повинна відбуватися за допомогою електронно-цифрового підпису. Засоби електронно цифрового підпису повинні мати позитивний експертний висновок Державної служби спеціального зв’язку та захисту інформації України за результатами державної експертизи в сфері криптографічного захисту інформації щодо відповідності вимогам нормативних документів системи криптографічного захисту інформації України. Побудова КСЗІ передбачає програмне та технологічне розширення (масштабування) компонентів ІС РТГК. ==== 4.1.12 Вимоги до збереження інформації при аваріях ==== Доопрацювань ІС РТГК повинні включати в себе програмні засоби діагностики та механізми документування аварійних подій або помилок. У разі виникнення аварійних подій або помилок у роботі доопрацювань ІС РТГК помилка повинна реєструватися у відповідному лог-журналі. При цьому має бути реалізована можливість отримання технічної довідкової інформації-допомоги з різним рівнем деталізації, щодо ліквідації аварійних подій, чи виправлення помилки. У лог-журналі повинна бути можливість перегляду такої інформації: * час; * текстова назва аварії; * назва файлу вихідних текстів; * номер рядка в файлі; * причина помилки. Також за можливості повинна передаватись назва функції, яка викликала збій і список відповідних викликів. ==== 4.1.13 Вимоги до патентної чистоти ==== Патентна чистота доопрацювань ІС РТГК повинна бути забезпечена розробником і гарантуватися фірмами виробниками програмних засобів. Ліцензійна чистота доопрацювань ІС РТГК повинна бути забезпечена використанням ліцензійних програмних продуктів та гарантуватися відповідними документами фірм, що їх виробляють. Для розроблюваних компонентів програмного забезпечення ліцензійна чистота має забезпечуватися відповідно до чинного законодавства України. В окремих випадках до складу системного та загальносистемного програмного забезпечення доопрацювань ІС РТГК можуть бути включені вільно розповсюджувані програмні продукти. ==== 4.1.14 Вимоги до стандартизації та уніфікації ==== Стандартизація та уніфікація реалізації функцій доопрацьованих компонентів повинна бути забезпечена за рахунок використання сучасних інструментальних програмних засобів, які підтримують єдину технологію проектування та розробки (модернізацію) функціонального, інформаційного та програмного забезпечень систем. Проектні рішення з технічного та загального програмного забезпечень допрацьованих компонентів повинні передбачати вибір сумісних, найбільш інтегрованих програмних та технічних засобів, які відповідають вимогам сучасних міжнародних стандартів «відкритих систем». ===== 4.2 Вимоги до функцій (задач), які реалізуються в межах доопрацювань ===== ==== 4.2.1 Перелік програмних компонентів, які розробляються/ модернізуються в межах доопрацювань ==== В межах доопрацювань ІС РТГК розробляються такі програмні компоненти: - Модернізація прикладного програмного компонента «ЕКГ». - Модернізація прикладного програмного компонента «Заяви». - Створення прикладного програмного компонента щодо перенесення реєстрації місця проживання/перебування громадян до іншого об’єкта адресації. - Розробка нового права доступу до рольової моделі для надання знеособленої інформації користувачам по приміщеннях щодо реєстрації/зняття з реєстрації місця проживання/перебування громадян. - Доопрацювання робочого місця користувача «Виконавці комунальних послуг». - Доопрацювання прикладного програмного компонента «Статистичний звіт: Кількість зареєстрованих осіб». - Розробка механізму взаємодії ІС РТГК з ОКК у межах послуги «Електронний сервіс запиту громадянином кількості зареєстрованих у приміщенні» (для е-послуги ОКК «Кількість жителів, зареєстрованих за моєю адресою»). - Інтеграція ІС РТГК з Єдиним модулем обліку та управління користувачами та ЗІС, який є частиною Платформи KYIVSMARTCITY. - Інтеграція ІС РТГК з Єдиним модулем та управління нотифікаціями з метою розсилки повідомлень організаціям, які приймають участь у процесі надання послуг громадянам. - Інтеграція ІС РТГК з Єдиним модулем логування та моніторингу, який є частиною Платформи KYIVSMARTCITY. - Інтеграція ІС РТГК з СНДІ МКА в частині подачі заявок на створення нових компонентів адреси. - Розробка механізму обміну даними між ІС РТГК та «Вітриною даних». ==== 4.2.2 Архітектура рішення ==== Загальна блок схема побудови архітектури рішення (див. Рисунок 1. Концептуальна схема логічної архітектури побудови рішення). Рисунок 1. Концептуальна схема логічної архітектури побудови рішення ==== 4.2.3 Опис вимог до програмних компонентів, які розробляються або модернізуються в межах доопрацювань ==== Екранні форми, прототипи яких наведені при описі вимог до доопрацювань ІС РТГК, можуть бути змінені в процесі розробки, але у будь-якому разі кінцеві екранні форми повинні відповідати вимогам, що зазначені у цьому Технічному завданні. === 4.2.3.1 Вимоги до модернізації програмного компонента «ЕКГ» === Модернізація прикладного програмного компонента ЕКГ забезпечує: * Відстеження та повідомлення користувачів про настання подій щодо громадян (див. Таблиця 1. Перелік подій, за якими відбувається повідомлення користувача). Таблиця 1. Перелік подій, за якими відбувається повідомлення користувача ^№^Подія ^Повідомлення ^ |1|Закінчення строку дії паспорта громадянина України зразка 2015 року. |Увага! Закінчився строк дії паспорта громадянина. Необхідно ввести дані актуального документа.| |2|Закінчення строку дії реєстрації місця перебування. |Увага! У громадянина закінчився строк дії реєстрації місця перебування. | |3|Досягнення громадянином віку 25 і 45 років (по громадянах, у яких діючий паспортний документ –паспорт зразка 2015 року та дата видачі документа менша ніж дата народження 25/45 років).|Увага! Громадянину виповнилося 25(45) років. Перевірте діючий документ громадянина. | Повідомлення користувачів про настання подій повинно відбуватися в момент перегляду даних громадянина в окремому вікні або у вигляді підказки, натиснувши на яку користувач може переглянути повідомлення (див. Рисунок 2. Прототип екранної форми ЕГК підказки про настання події та Рисунок 3. Прототип екранної форми ЕГК повідомлення про настання події).   Рисунок 2. Прототип екранної форми ЕГК підказки про настання події Рисунок 3. Прототип екранної форми ЕГК повідомлення про настання події   **//\\ //** * Зміну алгоритму перевірки унікальності номеру Свідоцтва про народження при заведені документа у Систему. Перевірка унікальності повинна виконуватися не тільки за номером документа, а одночасно за номером та датою видачі документа. Перевірка унікальності виконується в момент збереження створення/редагування ЕКГ. Програма перевіряє унікальність номеру Свідоцтва про народження за таким правилом: серія та номер свідоцтва + дата видачі документа повинні бути унікальними у Системі. При цьому при перевірці першого символу серії свідоцтва «І» та «1» повинні вважатися рівнозначними, наприклад: //Свідоцтво «1-БК 235874 від 25.04.2016» = свідоцтву «І-БК 235874 від 25.04.2016».// Якщо при збережені даних Система виявляє порушення вказаного правила унікальності, то дані не зберігаються, а користувачу надається повідомлення про помилку. * Створення у картці ЕКГ додаткового поля для введення ІПН громадянина, яке необов'язкове для заповнення (див. Таблиця 2. Опис поля «ІПН» та Рисунок 4. Прототип екранної форми ЕКГ з новим полем «ІПН»). Поле «ІПН» доступно до заповнення при створенні та редагуванні ЕКГ. Таблиця 2. Опис поля «ІПН» ^Назва^Тип ^Опис ^Обов’язковість^ |ІПН |Текстово-символьний (10)|Ідентифікаційний податковий номер громадянина.\\ \\ Дозволяється введення тільки чисел. Введення літер та інших символів заборонено.\\ \\ При введенні менше ніж 10 символів поле підсвічується червоним.\\ \\ Система забороняє збереження створення нового ЕКГ або збереження змін при редагуванні ЕКГ, якщо в полі ІПН введено менше ніж 10 символів.|Ні |   Рисунок 4. Прототип екранної форми ЕКГ з новим полем «ІПН»   === 4.2.3.2 Вимоги до модернізації програмного компонента «Заяви» === Модернізація повинна забезпечити можливість відстеження та повідомлення користувачів Системи: * Про факт реєстрації малолітньої дитини в ОЖФ Повідомлення повинно відбуватися в момент збереження Заяви на реєстрацію місця проживання малолітньої дитини (громадянин, якому ще не виповнилося 14 років). Система в момент збереження Заяви повинна перевірити, чи зареєстроване у приміщенні місце проживання повнолітнього громадянина, який має родинний зв’язок з дитиною за типом «мати» або «батько», та у разі відсутності реєстрації одного з батьків дитини Система повинна видати користувачеві повідомлення. При наданні повідомлення Система повинна надати користувачеві можливість продовження або скасування збереження Заяви (див. Рисунок 5. Прототип екранної форми з повідомленням про факт реєстрації малолітньої дитини у ОЖФ). Рисунок 5. Прототип екранної форми з повідомленням про факт реєстрації малолітньої дитини у ОЖФ * Про факт зняття з реєстрації повнолітніх громадян у ОЖФ, в якому залишається зареєстрованою малолітня дитина. Повідомлення повинно відбуватися в момент збереження Заяви на зняття з реєстрації місця проживання повнолітнього громадянина. Система в момент збереження Заяви повинна перевірити, чи зареєстрована в обраному ОЖФ малолітня дитина. У разі, коли в обраному ОЖФ залишається малолітня дитина, Система повинна перевірити, чи зареєстровано у приміщенні місце проживання повнолітнього громадянина, який має родинний зв’язок з дитиною за типом «мати» або «батько». У разі відсутності реєстрації одного з батьків дитини Система повинна видати користувачеві повідомлення з попередженням. При наданні повідомлення Система повинна надати користувачеві можливість продовження або скасування збереження Заяви (див. Рисунок 6. Прототип екранної форми з повідомленням про наявність реєстрації неповнолітньої особи). Рисунок 6. Прототип екранної форми з повідомленням про наявність реєстрації неповнолітньої особи === 4.2.3.3 Вимоги до створення програмного компонента щодо перенесення місця проживання/перебування громадян до іншого об’єкта адресації === Створення програмного компонента повинно забезпечити можливість перенесення всієї історії реєстрації/зняття з реєстрації місця проживання/перебування громадян у відповідному ОЖФ: * з одного приміщення до іншого приміщення в межах однієї будівлі; * з однієї будівлі до іншої будівлі за умови, що в будівлі, до якої відбувається перенесення реєстрації громадян, вже існують необхідні приміщення. Операція щодо перенесення історії реєстрації/зняття з реєстрації місця проживання/перебування громадян повинна виконуватися тільки користувачами, які мають роль «Супервізор» з окремої сторінки меню «Перенесення реєстрації» (див. Рисунок 7. Прототип екранної форми розділу меню для виконання операції перенесення історії реєстрації/зняття з реєстрації) та може бути двох типів: * в межах однієї будівлі; * до іншої будівлі. Рисунок 7. Прототип екранної форми розділу меню для виконання операції перенесення історії реєстрації/зняття з реєстрації * Операція перенесення історії реєстрації/зняття з реєстрації місця проживання/перебування громадян в межах однієї будівлі. Для виконання операції перенесення історії реєстрації/зняття з реєстрації місця проживання/перебування громадян з одного приміщення до іншого приміщення в межах однієї будівлі необхідно обрати тип операції «В межах однієї будівлі». Екранна форма для виконання операції повинна дозволяти вибір адреси будівлі, в межах якої необхідно здійснити перенесення історії реєстрації/зняття з реєстрації місця проживання/перебування, обравши вулицю та номер будівлі. Опис полів щодо вибору адреси будівлі (див. Таблиця 3. Опис полів фільтра пошуку адреси при перенесенні в межах однієї будівлі). Таблиця 3. Опис полів фільтра пошуку адреси при перенесенні в межах однієї будівлі ^**Назва поля**^**Тип поля** ^**Опис** ^**Обов’язковість**^ |Вулиця |Текстово-символьний (130)|Назва вулиці. \\ \\ Значення обирається з довідника вулиць міста Києва. |Так | |№ будівлі |Текстово-символьний (40) |Номер будівлі. Значення обирається з номерів будинків, що належать обраній вулиці, з довідника будинків міста Києва. \\ \\ Поле стає доступним для заповнення тільки після вибору вулиці. |Так | Після вказання адреси будівлі на екрані повинен відобразитися перелік усіх приміщень цієї будівлі та список громадян, у яких в історії реєстрації/зняття з реєстрації є обрана будівля (див. Рисунок 8. Прототип екранної форми для виконання операції ). Опис полів списку приміщень та громадян (див. Таблиця 4. Опис полів списку приміщень та громадян при перенесення в межах однієї будівлі).   Рисунок 8. Прототип екранної форми для виконання операції перенесення історії реєстрації/зняття з реєстрації в межах однієї будівлі Таблиця 4. Опис полів списку приміщень та громадян при перенесення в межах однієї будівлі ^**Назва поля** ^**Тип поля** ^**Опис** ^**Обов’язковість** ^ |□ |Чек-бокс |Чек-бокс для вибору приміщень.\\ \\ Можна обрати:\\ \\ ·        усі;\\ \\ ·        одне;\\ \\ ·        декілька.\\ \\ При виборі приміщення автоматично у списку обираються усі громадяни цього приміщення. |Так\\ \\ (хоча б одне значення)| |Приміщення |Текстово-символьний\\ \\ (20) |Номер приміщення, у обраному будинку.\\ \\ Номера приміщень сортуються у порядку зростання. |Так | |□ |Чек-бокс |Чек-бокс для вибору громадян.\\ \\ Можна обрати:\\ \\ ·        одного;\\ \\ ·        декількох. |Так\\ \\ (хоча б одне значення)| |ПІБ |Текстово-символьний\\ \\ (50) |Прізвище, ім’я, по-батькові громадян, які мають будь-які реєстраційні (актуальні та/або історичні) записи в обраному приміщенні (реєстрації/зняття з реєстрації).\\ \\ В межах приміщення список громадян сортується за алфавітом.\\ \\ Якщо за одним громадянином є декілька реєстраційних записів за обраним будинком, то на екран виводиться тільки останній реєстраційний запис у останньому приміщені (ОЖФ).\\ \\ При цьому при виконанні операції перенесення приміщення змінюється за всіма історичними записами, які відповідають ОЖФ у останньому реєстраційному запису в обраному ОЖФ.|Так | |Дата народження|Дата у форматі\\ \\ дд.мм.рррр|Дата народження громадянина. |Так | |Статус |Текстово-символьний\\ \\ (20) |Останній статус реєстрації громадянина за обраним приміщенням. Може приймати три значення:\\ \\ ·            проживає;\\ \\ ·            перебуває;\\ \\ ·            вибув з проживання. |Так | |Актуальність |Текстово-символьний\\ \\ (20) |Актуальність статусу реєстраційного запису. Може приймати значення:\\ \\ ·            Так – якщо реєстраційний запис за вказаним ОЖФ є останнім у історії реєстраційних записах громадянина;\\ \\ ·            Ні – якщо реєстраційний запис за вказаним ОЖФ не останній у історії реєстраційних записах громадянина. |Так | |Перенести |Кнопка зі списком |Поле для вибору приміщення куди переноситься історія реєстрації/зняття з реєстрації громадянина.\\ \\ Значення обирається зі списку приміщень в обраному будинку.\\ \\ Поле доступно для заповнення тільки за тими громадянами, по яким було проставлено позначку у чек-боксі. |Так\\ \\ (хоча б одне значення)|   При виконанні операції перенесення історії реєстрації/зняття з реєстрації в межах однієї будівлі повинна бути можливість: * обрати усі приміщення або одне/декілька, звідки здійснюється перенесення історії реєстрації/зняття з реєстрації; * обрати одного або декілька громадян; * обрати приміщення, в яке здійснюється перенесення історії реєстрації/зняття з реєстрації. Система повинна дозволяти виконання операції тільки у разі, коли були обрані відповідні громадяни, за якими необхідно перенести історію реєстрації/зняття з реєстрації місця проживання/перебування. Якщо при виконанні операції перенесення історії реєстрації/зняття з реєстрації виникла якась помилка, Система повинна повідомляти про це користувача відповідним повідомленням, при цьому перенесення реєстраційних записів за всіма вказаними приміщеннями не здійснюється. * Операція перенесення історії реєстрації/зняття з реєстрації місця проживання/перебування громадян з однієї будівлі до іншої. Для виконання операції перенесення історії реєстрації/зняття з реєстрації місця проживання/перебування громадян з однієї будівлі до іншої необхідно обрати тип операції «До іншої будівлі». Екранна форма для виконання операції повинна дозволяти обирати адресу будівлі, з якої переноситься історія реєстрації/знаття з реєстрації, та адресу будівлі, до якої виконується перенесення (див. Рисунок 9. Прототип екранної форми для виконання операції перенесення історії реєстрації/зняття з реєстрації з однієї будівлі до іншої). Опис полів щодо вибору адрес наведено нижче (див. Таблиця 5. Опис полів фільтра пошуку адреси при перенесенні з однієї будівлі до іншої). Таблиця 5. Опис полів фільтра пошуку адреси при перенесенні з однієї будівлі до іншої ^**Назва поля** ^**Тип поля** ^**Опис** ^**Обов’язковість**^ |Перенести з будівлі | | | | |Вулиця |Текстово-символьний (70)|Назва вулиці, з якої виконується перенесення.\\ \\ Значення обирається з довідника вулиць міста Києва. |Так | |№ будівлі |Текстово-символьний (20)|Номер будівлі, з якого виконується перенесення. Значення обирається з номерів будинків, що належать обраній вулиці, з довідника будинків міста Києва.\\ \\ Поле стає доступним для заповнення тільки після вибору вулиці. |Так | |Перенести до будівлі| | | | |Вулиця |Текстово-символьний (70)|Назва вулиці, до якої виконується перенесення.\\ \\ Значення обирається з довідника вулиць міста Києва. |Так | |№ будівлі |Текстово-символьний (20)|Номер будівлі, до якого виконується перенесення. Значення обирається з номерів будинків, що належать обраній вулиці, з довідника будинків міста Києва.\\ \\ Поле стає доступним для заповнення тільки після вибору вулиці.\\ \\  |Так | Після вказання адреси будівлі, з якої відбувається перенесення історії реєстрації/зняття з реєстрації, на екрані повинен відобразитися перелік усіх приміщень цієї будівлі та список громадян, у яких є обрана будівля в їх реєстраційних записах (див. Рисунок 9. Прототип екранної форми для виконання операції перенесення історії реєстрації/зняття з реєстрації з однієї будівлі до іншої). Опис полів списку приміщень та громадян наведено нижче (див. Таблиця 6. Опис полів списку приміщень та громадян при перенесення з однієї будівлі до іншої).   Рисунок 9. Прототип екранної форми для виконання операції перенесення історії реєстрації/зняття з реєстрації з однієї будівлі до іншої   Таблиця 6. Опис полів списку приміщень та громадян при перенесення з однієї будівлі до іншої ^**Назва поля/зображення**^**Тип поля** ^**Опис** ^**Обов’язковість** ^ |□ |Чек-бокс |Чек-бокс для вибору приміщень.\\ \\ Можна обрати:\\ \\ ·        усі;\\ \\ ·        одне;\\ \\ ·        декілька. |Так\\ \\ (хоча б одне значення)| |Приміщення |Текстово-символьний\\ \\ (20) |Номер приміщення у обраному будинку, з якого виконується переміщення.\\ \\ Номера приміщень сортуються у порядку зростання. |Так | |□ |Чек-бокс |Чек-бокс для вибору громадян. Можна обрати:\\ \\ ·              одного;\\ \\ ·              декількох. |Так\\ \\ (хоча б одне значення)| |ПІБ |Текстово-символьний\\ \\ (50) |Прізвище, ім’я, по-батькові громадян, які мають будь-які реєстраційні (актуальні та/або історичні) записи у обраному будинку (реєстрації/зняття з реєстрації).\\ \\ В межах приміщення список громадян сортується за алфавітом.\\ \\ Якщо за одним громадянином є декілька реєстраційних записів за обраним ОЖФ, то на екран виводиться тільки останній реєстраційний запис.\\ \\ При цьому при виконанні операції перенесення приміщення змінюється за всіма записами.|Так | |Дата народження |Дата у форматі\\ \\ дд.мм.рррр|Дата народження громадянина. |Так | |Статус реєстрації |Текстово-символьний\\ \\ (20) |Останній статус реєстрації громадянина за обраним приміщенням. Може приймати три значення:\\ \\ ·              проживає;\\ \\ ·              перебуває;\\ \\ ·              вибув з проживання. |Так | |Актуальність |Текстово-символьний\\ \\ (20) |Актуальність статусу реєстраційного запису. Може приймати значення:\\ \\ ·            Так – якщо реєстраційний запис за вказаним ОЖФ є останнім в історії реєстраційних записах громадянина.\\ \\ ·            Ні– якщо реєстраційний запис за вказаним ОЖФ не останній в історії реєстраційних записах громадянина. |Так | |Перенести |Кнопка зі списком |Поле для вибору приміщення, куди буде перенесена історія реєстрації/зняття з реєстрації громадянина.\\ \\ Значення обирається зі списку приміщень у обраному будинку для перенесення. |Так\\ \\ (хоча б одне значення)| При виконанні операції перенесення історії реєстрації/зняття з реєстрації з однієї будівлі до іншої повинна бути можливість: * обирати усі приміщення в будинку, з якого відбувається перенесення або одне/декілька приміщень; * обирати одного або декількох громадян; * обирати приміщення для перенесення історії реєстрації/зняття з реєстрації в іншому будинку. * обирати опцію «Заповнити відповідно номерів приміщень» для перенесення у приміщення з номерами, відповідними номерам приміщень будинку, з якого переноситься історія реєстрації/зняття з реєстрації. Опцію можна використовувати тільки у разі, коли в обох будинках є відповідні приміщення. В іншому випадку повинна видаватись помилка «Увага!!! В будівлі, куди переноситься історія реєстрації/зняття з реєстрації громадян, наявні не всі приміщення». Виконання операції перенесення дозволяється тільки після вибору громадян, за якими необхідно перенести історію реєстрації/зняття з реєстрації, та відповідних приміщень, до яких необхідно виконати перенесення. Заборонено виконання операції перенесення у той самий будинок, з якого переносяться історії реєстрації/знаття з реєстрації. Якщо під час виконання операції перенесення історії реєстрації/зняття з реєстрації виникла якась помилка, Система повинна повідомляти про це користувача відповідним повідомленням. При цьому перенесення реєстраційних записів за всіма вказаними приміщеннями не здійснюється. === 4.2.3.4 Вимоги до розробки нового права доступу до рольової моделі для надання знеособленої інформації громадянам по приміщенням щодо реєстрації/зняття з реєстрації місця проживання/перебування громадян === Розробка повинна забезпечити створення нових прав до ролі для можливості: * формування витягу по приміщенню щодо реєстрації/зняття з реєстрації місця проживання/перебування громадян зі знеособленою інформацією щодо громадян; * управління відображенням ПІБ громадянина у інтерфейсі та у сформованому витягу по приміщенню у форматі PDF щодо зареєстрованих/знятих з реєстрації громадян. Нові права до ролі повинні надаватися в інтерфейсі «Робоче місце Адміністратора» (див. Рисунок 10. Прототип екранної форми щодо надання прав до ролі) як до нової, так і до існуючої ролі. За допомогою чек-боксу можна управляти приховуванням/відображенням даних громадянина. При проставленні позначки у чек-боксі дані громадянина повинні скриватися (див. Рисунок 11. Екранна форма з чек-боксом для управління відображенням ПІБ громадян у меню «Витяги»). Колонка «Перегляд ЕКГ» у меню «Витяги» повинна бути доступною тільки користувачам з роллю, яка надає право перегляду/пошуку даних ЕКГ (див. Рисунок 12. Екранна форма з чек-боксом для управління відображенням ПІБ громадян у меню «Витяги» для ролі, яка має права на перегляд ЕГК). В іншому випадку «Перегляд ЕКГ» повинен бути недоступний (див. Рисунок 11. Екранна форма з чек-боксом для управління відображенням ПІБ громадян у меню «Витяги» для ролі, яка не має права на перегляд ЕГК). . Рисунок 10. Прототип екранної форми щодо надання прав до ролі   Рисунок 11. Екранна форма з чек-боксом для управління відображенням ПІБ громадян у меню «Витяги» для ролі, яка не має права на перегляд ЕГК   Рисунок 12. Екранна форма з чек-боксом для управління відображенням ПІБ громадян у меню «Витяги» для ролі, яка має права на перегляд ЕГК   Формування витягу по приміщенню щодо реєстрації/зняття з реєстрації місця проживання/перебування громадян зі знеособленою інформацією по громадянах повинно управлятися комбінацією двох прав: * щодо перегляду/пошуку ЕКГ; * на управління відображенням ПІБ громадянина (див. Таблиця 7. Результат формування «Витягу по будинку за період» в залежності від комбінації прав доступу ролі). Таблиця 7. Результат формування «Витягу по будинку за період» в залежності від комбінації прав доступу ролі ^**Право у меню «Витяги»** ^ ^**Відображення на екрані**^** **\\ \\ **Формування витягу по приміщенню ** ^ |**Щодо перегляду/пошуку ЕКГ**|**На управління відображенням ПІБ громадян **| | | |**+** |**-** |ПІБ |Тільки з повною інформацією щодо громадян. | |**+** |**+** |ПІБ |Можливі два варіанти в залежності від проставлення позначки у чек-боксі:\\ \\ ·        з повною інформацією щодо громадян;\\ \\ ·        зі знеособленою інформацією щодо громадян.| |**-** |**-** |………… |Тільки зі знеособленою інформацією щодо громадян. | |**-** |**+** |ПІБ |Тільки зі знеособленою інформацією щодо громадян.\\ \\   | У сформованому «Витягу» по приміщенню щодо реєстрації/зняття з реєстрації місця проживання/перебування громадян зі знеособленою інформацією по громадянах повинні відображатися тільки дата народження та дата реєстрації/зняття з реєстрації у приміщенні, а замість ПІБ громадян необхідно відображати крапки (див. Рисунок 13. Прототип «Витягу» по приміщенню зі знеособленою інформацією). Формат та інші вимоги до «Витягів» по приміщенню не змінюються. Рисунок 13. Прототип «Витягу» по приміщенню зі знеособленою інформацією === 4.2.3.5 Вимоги до доопрацювання робочого місця користувача «Виконавці комунальних послуг» === У межах модернізації робочого місця «Виконавці комунальних послуг» необхідно: * Реалізувати можливість формування звіту «Статистика за адресами» з можливістю вибору періоду у межах двох місяців, а саме: * реалізувати можливість завдання дати початку та дати закінчення періоду, за який необхідно сформувати звіт (див. Рисунок 14. Прототип екранної форми при формування звіту «Статистика за адресами»). Опис полів див. Таблиця 8. Опис полів періоду формування звіту «Статистика за адресами». При вказанні дат початку та закінчення періоду введені значення повинні зберігатися впродовж всієї робочої сесії при формуванні будь-якої кількості звітів до моменту ручного введення інших значень або до виходу з меню «Статистика за адресами»; * обмежити максимальний період формування звіту двома місяцями; * новий формат вказання періоду поширюється на всі звіти, що формуються з розділу «Статистика за адресами», а саме: * звіт за районом; * звіт за вулицею; * звіт за № будівлі; * об’єднаний звіт; * звіт по ОСББ/ЖБК/ВЖ. Таблиця 8. Опис полів періоду формування звіту «Статистика за адресами» ^**Назва поля**^**Тип поля** ^**Опис** ^**Обов’язковість**^ |Період з |Дата\\ \\ у форматі дд.мм.рррр|Дата початку періоду, за який необхідно сформувати звіт. \\ \\ Обирається з календаря. |Так | |По |Дата\\ \\ у форматі дд.мм.рррр|Дата закінчення періоду, за який необхідно сформувати звіт. \\ \\ Обирається з календаря.|Так | * Внести зміни у заголовок «Витяг з інформаційної системи «Реєстр територіальної громади м. Києва» про зареєстрованих/знятих з реєстрації осіб у житлових приміщеннях». У заголовку «Витяги з інформаційної системи «Реєстр територіальної громади м. Києва» про зареєстрованих/знятих з реєстрації осіб у житлових приміщеннях» (надалі – «Витяг за будинком за період») необхідно вказувати період формування витягу у форматі «за період з дд.мм.рррр по дд.мм.рррр року», де дд.мм.рррр – дата початку/закінчення періоду формування витягу (див. Рисунок 15. Прототип документа «Витяг за будинком за період»). Формат та інші вимоги до «Витягу по будинку за період» залишаються без змін. Заголовок «Витягу за будинком за період» необхідно виводити у новому форматі також при формуванні об’єднаного витягу за будинком та при формування витягу по ОСББ/ЖБК/ВЖ. При цьому формування документа «Витяг з інформаційної системи «Реєстр територіальної громади міста Києва» про зареєстрованих осіб у житлових приміщеннях за адресою» залишається без змін та виводиться на поточну дату формування витягу. Рисунок 14. Прототип екранної форми при формування звіту «Статистика за адресами»   Рисунок 15. Прототип документа «Витяг за будинком за період»   === 4.2.3.6 Вимоги до доопрацювання прикладного програмного компонента «Статистичний звіт: Кількість зареєстрованих осіб» === Доопрацювання прикладного програмного компонента «Статистичний звіт: Кількість зареєстрованих осіб» повинне забезпечити: - Можливість формування звіту «Кількість зареєстрованих осіб» за декількома будинками в межах обраної вулиці. Необхідно у розділі меню «Статистика» у звіті «Кількість зареєстрованих осіб» реалізувати можливість вибору в межах вулиці одного, декількох або усіх будинків (див. Рисунок 16. Прототип екранної форми для вибору декількох будинків при формуванні звіту «Кількість зареєстрованих осіб»). Інформація у звіті повинна виводитися на екран в розрізі кожного обраного будинку та з підсумковими даними за всіма обраними будинками про кількість зареєстрованих осіб, в тому числі віком від 18 років (див. Рисунок 17. Прототип екранної форми виведення звіту «Кількість зареєстрованих осіб» за декількома будинками). Опис полів звіту, які виводяться на екран, наведено на Таблиця 9. Опис полів звіту «Кількість зареєстрованих осіб» за декількома будинками.     Рисунок 16. Прототип екранної форми для вибору декількох будинків при формуванні звіту «Кількість зареєстрованих осіб»   Рисунок 17. Прототип екранної форми виведення звіту «Кількість зареєстрованих осіб» за декількома будинками Таблиця 9. Опис полів звіту «Кількість зареєстрованих осіб» за декількома будинками ^**Назва поля** ^**Тип поля** ^**Опис** ^**Обов’язковість**^ |Будівля |Текстово-символьний (30)|Номер будинку з вказанням типу будинку. |Так | |Зареєстровано |Числовий (30) |Кількість громадян, зареєстрованих у будинку на дату формування звіту. |Так | |В тому числі віком від 18 років|Числовий (30) |Кількість громадян віком від 18 років, зареєстрованих у будинку на дату формування звіту. |Так | |Разом |Числовий (30) |Загальна кількість зареєстрованих громадян в обраних будинках - за кожною колонкою окремо.|Так | * Можливість формування документа «Витяг з Реєстру територіальної громади міста Києва про кількість зареєстрованих громадян» в одному або декількох будинках. Необхідно у розділі меню «Статистика» у звіті «Кількість зареєстрованих осіб» реалізувати можливість формування у форматі PDF документа «Витяг з Реєстру територіальної громади міста Києва про кількість зареєстрованих громадян» (надалі – Витяг за декількома будинками) (див. Рисунок 18. Прототип Витягу за декількома будинками). Опис полів Витягу за декількома будинками (див. Таблиця 10. Опис полів Витягу за декількома будинками). Рисунок 18. Прототип Витягу за декількома будинками Таблиця 10. Опис полів Витягу за декількома будинками ^**Назва поля** ^**Тип поля** ^**Опис** ^**Обов’язковість**^ |Заголовок Витягу | | | | |Витяг з Реєстру територіальної громади міста Києва\\ \\ про зареєстрованих осіб\\ \\ за адресою: м. Київ, топонім та назва вулиці\\ \\ на дд місяць рррр року\\ \\  |Текстово-символьний (150)|Заголовок Витягу, у якому є змінними:\\ \\ 1)        адреса, за якою виводиться Витяг - топонім та назва вулиці;\\ \\ 2)        дата формування Витягу - дд місяць рррр|Так | |Поля Витягу | | | | |Будівля |Текстово-символьний (30) |Номер будинку з вказанням типу будинку. |Так | |Зареєстровано |Числовий (30) |Кількість громадян, зареєстрованих у будинку на дату формування звіту. |Так | |В тому числі віком від 18 років |Числовий (30) |Кількість громадян віком від 18 років, зареєстрованих у будинку на дату формування звіту. |Так | |Разом |Числовий (30) |Загальна кількість зареєстрованих громадян в обраних будинках - за кожною колонкою окремо. |Так | * Можливість надання доступу до «Статистичного звіту: Кількість зареєстрованих осіб» за окремим правом доступу. Нове право до ролі щодо надання доступу до статистичного звіту «Кількість зареєстрованих осіб» повинно надаватися у інтерфейсі «Робоче місце Адміністратора» (див. Рисунок 19. Прототип екранної форми щодо надання прав до ролі на доступ до звіту «Кількість зареєстрованих осіб») як до нової, так і до існуючої ролі, у якої налаштовано право доступу до розділу «Статистика».   Рисунок 19. Прототип екранної форми щодо надання прав до ролі на доступ до звіту «Кількість зареєстрованих осіб»   === 4.2.3.7 Вимоги до розробки механізму взаємодії ІС РТГК з ОКК у межах послуги «Електронний сервіс запиту громадянином про кількість зареєстрованих у приміщенні» (для е-послуги ОКК «Кількість жителів, зареєстрованих за моєю адресою»). === Рішення повинно забезпечити взаємодію ІС РТГК з зовнішніми інформаційними системами (надалі – ЗІС) через механізм використання публічних запитів (АРІ). У межах реалізації механізму взаємодії ІС РТГК з ОКК повинна бути забезпечена можливість онлайн-отримання запиту від ЗІС щодо кількості зареєстрованих громадян у приміщенні за адресою реєстрації користувача, який подав запит та надання відповіді про кількість зареєстрованих осіб. Вхідними даними до ІС РТГК має бути: * у разі наявності в ІС МР даних користувача з ІС РТГК: * ID громадянина у ІС РТГК; та/або * за необхідності передачі даних користувача до ІС МР: * прізвище, ім’я, по-батькові; * дата народження; та/або * серія та номер паспорта. Вихідними даними мають бути: * ID громадянина у ІС РТГК; * адреса реєстрації користувача; * кількість осіб, що зареєстровано за адресою реєстрації користувача на дату запиту, за типом «Проживає»/«Перебуває». Схема взаємодії ІС РТГК з ЗІС (див. Рисунок 20. Бізнес процес замовлення та отримання е-послуги «Кількість зареєстрованих за моєю адресою»). Опис бізнес-процесу замовлення послуги «Електронний сервіс запиту громадянином про кількість зареєстрованих у приміщенні» (е-послуги ОКК «Кількість жителів, зареєстрованих за моєю адресою»): - Послугу може отримати тільки користувач ОКК, який увійшов до ОКК за умови проходження ідентифікації та автентифікації засобами КЕП або BankID та надав згоду на передачу даних з ІС РТГК до ІС МР. - Для замовлення послуги користувачу необхідно обрати її в каталозі електронних послуг ОКК, де є можливість також ознайомитись з інформацією та правилами надання послуги. - За фактом замовлення послуги, ОКК передає дані KyivID користувача до ІС МР. - ІС МР здійснює пошук даних користувача, у своїй базі даних, отриманих з ІС РТГК за даними KyivID та за результатами успішного пошуку повертає до ОКК ідентифікатор громадянина у ІС РТГК (надалі - ID RTGK). У випадку відсутності даних користувача виконується існуючий сценарій отримання даних з ІС РТГК. - У випадку успішного результату пошуку ОКК запитує у ІС РТГК дані про кількість громадян за ID RTGK. - За результатами пошуку по ID RTGK Система повертає до ОКК дані про кількість громадян, зареєстрованих за місцем реєстрації користувача.   Рисунок 20. Бізнес процес замовлення та отримання е-послуги «Кількість зареєстрованих за моєю адресою» === 4.2.3.8 Вимоги до інтеграції ІС РТГК з Модулем авторизації Платформи KYIVSMARTCITY, який є частиною Платформи KYIVSMARTCITY === У межах інтеграції необхідно забезпечити реалізацію доступу до ІС РТГК засобами комп’ютерної програми «Urbio Модуль авторизації» (Єдиний модуль обліку та управління користувачами та ЗІС) Платформи KYIVSMARTCITY (далі – Модуль авторизації) та модифікацію процесу реєстрації нового співробітника. У межах нового процесу авторизація користувача з використанням КЕП повинна здійснюватися через Модуль авторизації (див. Рисунок 21. Схема реєстрації користувачів у ІС РТГК з використанням КЕП). Для отримання доступу до ІС РТГК реєстрація нового співробітника повинна виконуватися у два етапи: 1 етап – реєстрація у ІС РТГК нового співробітника та створення для нього користувача. Етап повинен виконуватися Адміністратором ІС РТГК за існуючою процедурою в інтерфейсі «Робоче місце Адміністратора». Вимоги (обмеження) щодо реєстрації співробітника у Системі за існуючою процедурою залишаються без змін. 2 етап – створення та встановлення відповідності KyivID громадянина до користувача ІС РТГК. Етап повинен здійснюватися у момент першого входу користувача у ІС РТГК після виконаної реєстрації (див. Рисунок 21. Схема реєстрації користувачів у ІС РТГК з використанням КЕП). Після введення користувачем його логіна та пароля на сторінці входу до ІС РТГК (див. Рисунок 22. Інтерфейс сторінки входу до ІС РТГК) Система повинна: * направити користувача до Модуля авторизації на сторінку для введення даних КЕП (див. Рисунок 23. Прототип екранної форми KyivID для входу через КЕП); **// //** Рисунок 21. Схема реєстрації користувачів у ІС РТГК з використанням КЕП \\ Рисунок 22. Інтерфейс сторінки входу до ІС РТГК   Рисунок 23. Прототип екранної форми KyivID для входу через КЕП   * при отриманні KyivID користувача, що було йому надано Модулем авторизації під час реєстрації на підставі даних КЕП, перевірити відповідність отриманих даних користувача за КЕП та даних, введених під час його реєстрації у ІС РТГК; * у разі успішної перевірки даних користувача за КЕП та введених під час його реєстрації у ІС РТГК, зберегти їх у Системі KyivID користувача. При подальшому вході користувача у ІС РТГК Система повинна забезпечити перевірку відповідності надісланого KyivID користувача від Модуля авторизації з тим, що було збережено у Системі. === 4.2.3.9 Вимоги до інтеграції ІС РТГК з Модулем нотифікацій Платформи KYIVSMARTCITY з метою розсилки повідомлень організаціям, які приймають участь у процесі надання послуг користувачам === - Відправка повідомлень Необхідно забезпечити інтеграцію ІС РТГК з комп’ютерною програмою «Urbio Модуль нотифікацій» (Єдиний модуль обліку та управління нотифікаціями) Платформи KYIVSMARTCITY (далі – Модуль нотифікацій) та розробку механізму відправлення повідомлень за шаблонами про порядок сплати за послуги користування Системою та сплату заборгованості нотаріусам, які приймають участь у процесі надання послуг користувачам (див. Рисунок 24. Схема відправлення повідомлення за шаблоном//).// Рішення повинно забезпечити: * Можливість автоматичної розсилки електронних листів користувачам Системи з категорією «Нотаріальні» за одним з трьох шаблонів: * шаблон 1 – «Порядок сплати за послуги РТГК»; * шаблон 2 – «Реквізити для сплати послуг РТГК»; * шаблон 3 – «Повідомлення про заборгованість». * Можливість створення списку отримувачів для відправлення повідомлень двома способами: * завдання списку вручну (див. Рисунок 25. Прототип інтерфейсу відправлення повідомлень користувачам за умови ручного формування списку); * вибір зі списку користувачів (див. Рисунок 26. Прототип інтерфейсу відправлення повідомлень користувачам при виборі зі списку користувачів). Опис полів списку для відправлення наведено у Таблиця 11. Опис полів списку для відправлення повідомлень користувачам. \\ \\ Рисунок 24. Схема відправлення повідомлення за шаблоном   \\ Рисунок 25. Прототип інтерфейсу відправлення повідомлень користувачам за умови ручного формування списку Рисунок 26. Прототип інтерфейсу відправлення повідомлень користувачам при виборі зі списку користувачів Таблиця 11. Опис полів списку для відправлення повідомлень користувачам ^**Назва поля** ^**Тип поля** ^**Опис** ^**Обов’язковість** ^ |Організація |Текстово-символьний (50) |Назва організації, за якою зареєстровано користувача, якому необхідно відправити повідомлення. |Так | |Код ГІОЦ |Число (5) |Особистий код, який вказується під час реєстрації користувача у ІС РТГК. |Так | |Отримувач |Текстово-символьний (50) |ПІБ користувача, якому необхідно відправити повідомлення. |Так | |E-mail |Текстово-символьний (30) |Електронна адреса, що була вказана під час реєстрації нотаріуса у Системі та на яку буде відправлено повідомлення. |Так | |Сума заборгованості|Число (10) у форматі хххххххх.хх|Сума заборгованості нотаріуса. \\ \\ Поле наявне тільки при відправленні повідомлень за шаблоном 3: «Повідомлення про заборгованість». За умови відправлення повідомлень за шаблонами 1 та 2 поле відсутнє.|Так \\ \\ (тільки для Шаблона 3)| * Можливість вказання періоду заборгованості та дати блокування надання послуг РТГК у разі розсилки електронних листів за шаблоном 3 (див. Рисунок 25. Прототип інтерфейсу відправлення повідомлень користувачам за умови ручного формування списку). * Формування списку повинно виконуватися Супервізором з окремого інтерфейсу ІС РТГК та надавати можливість: * при формуванні списку вручну – можливість завдати отримувача за кодом ГІОЦ або за ПІБ користувача (див. Рисунок 25. Прототип інтерфейсу відправлення повідомлень користувачам за умови ручного формування списку); * при виборі отримувачів зі списку користувачів – можливість формування списку користувачів для розсилки повідомлень з вибором категорії організації та/або вибором однієї або декількох організацій, користувачам якої необхідно відправити повідомлення. (див. Рисунок 26. Прототип інтерфейсу відправлення повідомлень користувачам при виборі зі списку користувачів). * Можливість виконання операцій зі списком для відправлення повідомлень нотаріусам: * додавання отримувача; * видалення отримувача зі списку. * Можливість вибору тільки тих користувачів, у яких є електронна адреса. В іншому випадку Система повинна попереджати Супервізора про відсутність електронної адреси. * Ініціювання відправлення повідомлень згідно з обраним шаблоном на електронні адреси, що були вказані під час реєстрації нотаріусів у ІС РТГК. * При ініціюванні відправлення повідомлень ІС РТГК повинна передати до Модуля нотифікацій запит на відправлення електронних листів, вказавши такі данні: * KyivID отримувача (нотаріуса); * ідентифікатор сценарію відправки та ідентифікатор шаблону повідомлення, налаштованого у Модулі нотифікацій; * необхідні теги за шаблоном та електронну адресу отримувача; * токен, що було надано ІС РТГК Модулем авторизації. * Відправлення повідомлень нотаріусам повинно відбуватися в асинхронному режимі. - Перегляд статусів відправок повідомлень Історія відправлення повідомлень повинна зберігатися у Системі та бути доступною до перегляду Супервізором з окремого інтерфейсу ІС РТГК (див. Рисунок 27. Прототип інтерфейсу історії повідомлень користувачів). Опис полів фільтрів для вибору повідомлень зі списку наведено у Таблиця 12. Опис фільтрів для пошуку повідомлень в історії. Опис полів списку для перегляду історії відправлення повідомлень наведено у Таблиця 13. Опис полів списку історії відправлених повідомлень.   \\ **//\\ //**   Рисунок 27. Прототип інтерфейсу історії повідомлень користувачів   Таблиця 12. Опис фільтрів для пошуку повідомлень в історії ^**Назва поля** ^**Тип поля** ^**Опис** ^**Обов’язковість**^ |Дата створення\\ \\ від|Дата у форматі дд.мм.рррр|Поля для наведення дати створення повідомлення. |Ні | |Дата створення\\ \\ до |Дата у форматі дд.мм.рррр| |Ні | |Статус |Текстовий |Статус відправлення повідомлення, вибір з трьох значень:\\ \\ ·        обробка;\\ \\ ·        відправлено;\\ \\ ·        не відправлено.|Ні | |Шаблон |Текстово-символьний (10) |Шаблон, за яким було направлено повідомлення, вибір трьох значень:\\ \\ ·      шаблон 1;\\ \\ ·      шаблон 2;\\ \\ ·      шаблон 3. |Ні | |Організація |Текстово-символьний (50) |Назва організації, обирається зі списку зареєстрованих організації. Є можливість пошуку за контекстом; входження у будь-якому місці. |Ні | |Код ГІОЦ |Число (5) |Особистий код користувача у ІС РТГК. |Ні | |Отримувач |Текстово-символьний (50) |ПІБ користувача, обирається зі списку зареєстрованих користувачів. Є можливість пошуку за контекстом; входження у будь-якому місці. |Ні | Таблиця 13. Опис полів списку історії відправлених повідомлень ^**Назва поля**^**Тип поля** ^**Опис** ^**Обов’язковість** ^ |Дата створення|Дата у форматі дд.мм.рррр|Дата створення повідомлення. |Так | |Статус |Текстовий |Поточний статус відправлення повідомлення. Може приймати три значення:\\ \\ ·        обробка;\\ \\ ·        відправлено;\\ \\ ·        не відправлено.|Так | |Шаблон |Текстово-символьний (10) |Шаблон, за яким було направлено повідомлення. Може приймати три значення:\\ \\ ·      шаблон 1;\\ \\ ·      шаблон 2;\\ \\ ·      шаблон 3. |Так | |Організація |Текстово-символьний (50) |Назва організації, за якою зареєстровано користувача, якому відправлялося повідомлення. |Так | |Код ГІОЦ |Число (5) |Особистий код користувача у ІС РТГК, якому відправлялося повідомлення. |Так | |Отримувач |Текстово-символьний (50) |ПІБ користувача, якому відправлялося повідомлення. |Так | |E-mail |Текстово-символьний (30) |Електронна адреса, на яку відправлялося повідомлення. |  | |Теги |Текстово-символьний (50) |Період заборгованості та сума заборгованості. Виводиться текстом, наприклад:\\ \\ Період: травень 2019, сума: 500. |Так \\ \\ (тільки для шаблона 3)| === 4.2.3.10 Вимоги до інтеграції ІС РТГК з Модулем обліку та моніторингу, який є частиною Платформи KYIVSMARTCITY === Інтеграція ІС РТГК з комп’ютерною програмою «Urbio Модуль обліку та моніторингу» (Єдиний модуль логування та моніторингу) Платформи KYIVSMARTCITY (далі – Модуль обліку та моніторингу) повинна забезпечити збір логів та метрик. У межах інтеграції Системи з Модулем обліку та моніторингу в Системі повинні бути встановлені: * Агент зі збору логів. Він повинен забезпечувати збір таких логів, які будуть зберігатися у Модулі обліку та моніторингу: * Логи доступу Системи. * Логи інтеграцій: * назва системи чи модуля, до якого виконується запит; * запит; * відповідь системи чи модуля. * Логи помилок (див. Таблиця 14. Базовий набір статусів відповідей (повідомлень) Системи): * дата та час виникнення помилки; * номер, опис чи причина помилки (інформація щодо самої помилки). * Агент зі збору метрик. Він повинен забезпечувати збір метрик, які будуть зберігатися у Модулі обліку та моніторингу: * Завантаженість процесорів: * дану метрику; * значення дати та часу отримання значення; * ID системи, від якої отримано метрику. * Завантаженість операційної пам’яті: * дану метрику; * значення дати та часу отримання значення; * ID системи, від якої отримано метрику. * Завантаженість фізичних дисків: * дану метрику; * значення дати та часу отримання значення; * ID системи, від якої отримано метрику. * Завантаженість мережевих інтерфейсів: * дану метрику; * значення дати та часу отримання значення; * ID системи, від якої отримано метрику. Таблиця 14. Базовий набір статусів відповідей (повідомлень) Системи ^**Статус повідомлення**^**Опис коду англійською мовою**^**Опис коду повернення** ^**Умови виникнення** ^ |**200** |Ок |Операція успішна. |Після успішного виконання операції. | |**400** |Bad Request |Некоректний запит. |Сервіс отримав запит. | |**500** |Internal Server Error |Внутрішня помилка сервера.|Запит не виконаний через внутрішню помилку сервера. | |**201** |Created |Успішно створено. |Успішно створено екземпляр об`єкта чи запис. | |**304** |Not Modified |Дані не змінились. |Дані щодо запиту не були змінені. | |**401** |Unauthorized |Не авторизований запит. |Сервіс отримав не авторизований запит. | |**403** |Forbidden |Доступ заборонено. |Права доступу для запиту не дозволяють отримати запитуваний доступ.| |**404** |Not Found |Не знайдено. |Запитувані дані не знайдено. | За необхідності перелік та зміст записів статусів повідомлень може бути змінений на етапі розробки. === 4.2.3.11 Вимоги до інтеграції ІС РТГК з СНДІ МКА в частині подання заявок на створення нових компонентів адреси. Вимоги до видів забезпечення. === У межах інтеграції з СНДІ МКА необхідно забезпечити: - Можливість направлення Заяви на створення нового компонента адреси (у тому числі вулиці та об’єкта адресації). Подання заяви на створення нового компонента адреси здійснюється користувачем з роллю Супервізора через окремі фрейми, які викликаються з інтерфейсу ІС РТГК. Процес подання заяви на новий компонент адреси (див. Рисунок 28. Схема обміну запитами при створенні нового компонента адреси). У межах інтеграції ІС РТГК з СНДІ МКА можна подати Заяви на створення таких компонентів адреси: * населеного пункту в межах України; * вулиці в межах м. Києва; * будинку на відповідній вулиці в межах м. Києва. Виклик фрейму відбувається після вибору типу компонента адреси, який необхідно створити (див. Рисунок 29. Прототип інтерфейсу екрана для виклику фрейму на створення нового компоненту адреси та отримання статусу по Заявам).   \\ Рисунок 28. Схема обміну запитами при створенні нового компонента адреси Рисунок 29. Прототип інтерфейсу екрана для виклику фрейму на створення нового компоненту адреси та отримання статусу по Заявам   Для виклику фрейму на створення відповідного компоненту адреси потрібно обрати необхідний тип компоненту адреси та натиснути кнопку «Створити» (див. Рисунок 29. Прототип інтерфейсу екрана для виклику фрейму на створення нового компоненту адреси та отримання статусу по Заявам), після чого у інтерфейсі Системи повинні відкритися поля вбудованого фрейму Заяви на новий компонент адреси (див. Рисунок 30. Прототип інтерфейсу фрейму Заяви на створення нової вулиці). Поля Заяви на новий компонент адреси залежать від самого компоненту, який необхідно створити. Перелік та опис полів фреймів (див. Таблиця 15. Опис полів фрейму на створення нових компонентів адреси). Таблиця 15. Опис полів фрейму на створення нових компонентів адреси ^**Назва поля** ^**Тип поля** ^**Опис** ^**Обов’язковість**^ |Заява на новий населений пункт | | | | |Країна |Текст (30) |Повна офіційна назва країни українською мовою. Заповнюється автоматично = Україна. |Так | |Область/регіон |Текст (30) |Повна офіційна назва регіону українською мовою. Обирається з довідника областей України. |Ні | |Район |Текст (30) |Повна офіційна назва району українською мовою.\\ \\ Обирається з довідника районів України. |Ні | |Назва населеного пункту |Текст (30) |Повна офіційна назва населеного пункту українською мовою.\\ \\ Вводиться вручну. |Так | |Тип населеного пункту |Текст (30) |Топонім населеного пункту.\\ \\ Значення обирається з довідника «Тип населених пунктів». |Так | |Документ |Посилання на документ |Документ, що є підставою для створення нового компонента адреси.\\ \\ Розмір документа не більше 10 МБ.\\ \\ Може бути створено декілька документів загальним розміром не більше 100 МБ.|Ні | |Коментар |Текстово-символьний (200)|Коментар до заяви. |Ні | |Заява на нову вулицю в м. Києві | | | | |Країна |Текст (30) |Повна офіційна назва країни українською мовою.\\ \\ Заповнюється автоматично = Україна. |Так | |Область/регіон |Текст (30) |Повна офіційна назва регіону українською мовою.\\ \\ Поле залишається порожнім. |Ні | |Район |Текст (30) |Повна офіційна назва району українською мовою.\\ \\ Поле залишається порожнім. |Ні | |Населений пункт |Текст (30) |Повна офіційна назва населеного пункту українською мовою.\\ \\ Заповнюється автоматично = Київ. |Так | |Адмін. район |Текст (30) |Повна офіційна назва адміністративного району населеного пункту українською мовою.\\ \\ Значення обирається з довідника адміністративних районів м. Києва. |Ні | |Назва вулиці |Текстово-символьний (50) |Повна офіційна назва вулиці українською мовою.\\ \\ Вводиться вручну. |Так | |Тип вулиці |Текст (20) |Топонім вулиці.\\ \\ Значення обирається з довідника «Тип вулиць». |Так | |Документ |Посилання на документ |Документ, що є підставою для створення нового компонента адреси.\\ \\ Розмір документа не більше 10 МБ.\\ \\ Може бути створено декілька документів загальним розміром не більше 100 МБ.|Ні | |Коментар |Текстово-символьний (200)|Коментар до заяви. |Ні | |Заява на новий будинок в м. Києві| | | | |Країна |Текст (30) |Повна офіційна назва країни українською мовою. Заповнюється автоматично = Україна. |Так | |Область/регіон |Текст (30) |Повна офіційна назва регіону українською мовою.\\ \\ Поле залишається порожнім. |Ні | |Район |Текст (30) |Повна офіційна назва району  українською мовою.\\ \\ Поле залишається порожнім. |Ні | |Населений пункт |Текст (30) |Повна офіційна назва населеного пункту українською мовою.\\ \\ Заповнюється автоматично = Київ. |Так | |Адмін. район |Текст (30) |Повна офіційна назва адміністративного району населеного пункту українською мовою.\\ \\ Значення обирається з довідника адміністративних районів м. Києва. |Ні | |Вулиця |Текстово-символьний (50) |Повна офіційна назва вулиці українською мовою.\\ \\ Значення обирається з довідника вулиць м. Києва. |Так | |Назва об’єкта адресації |Текстово-символьний (20) |Назва (номер) будинку, корпусу, секції. Значення вводиться вручну.\\ \\   |Так | |Тип об’єкта адресації |Текст (20) |Топонім об'єкта адресації.\\ \\ Значення обирається з довідника «Тип об'єкта адресації». |Так | |Документ |Посилання на документ |Документ, що є підставою для створення нового компонента адреси.\\ \\ Розмір документа не більше 10 МБ.\\ \\ Може бути створено декілька документів загальним розміром не більше 100 МБ.|Ні | |Коментар |Текстово-символьний (200)|Коментар до заяви. |Ні |     Рисунок 30. Прототип інтерфейсу фрейму Заяви на створення нової вулиці - Можливість отримання поточного статусу поданих Заяв щодо створення нового компонента адреси. Отримання поточного статусу поданих заяв здійснюється користувачем з роллю Супервізор через окремий фрейм, який викликається з інтерфейсу ІС РТГК та направляється до СНДІ МКА (див. Рисунок 31. Схема обміну запитами при отримані поточного статусу Заяви). Виклик фрейму відбувається при натисканні кнопки «Перегляд статусу Заяв», після чого у інтерфейсі відкриваються поля вбудованого фрейму для перегляду статусів Заяв на створення нового компонента адреси (див. Рисунок 32 Прототип інтерфейсу для перегляду статусів Заяв на створення нових компонентів адреси). Опис полів фільтрів пошуку та списку перегляду статусів Заяв на створення нових компонентів адрес (див. Таблиця 16. Опис фільтрів пошуку та полів списку перегляду статусу Заяв на нові компоненти адрес). Таблиця 16. Опис фільтрів пошуку та полів списку перегляду статусу Заяв на нові компоненти адрес ^**Назва поля** ^**Тип поля** ^**Опис** ^**Обов’язковість**^ |Фільтри пошуку | | | | |Номер Заяви |Текстово-символьний\\ \\ (15) |Унікальний номер Заяви (ID Заяви), за яким можна її ідентифікувати. |Ні | |Дата подання - від |Дата\\ \\ у форматі дд.мм.рррр|Поля для завдання періоду /дати подання/створення Заяви. |Ні | |Дата подання - до |Дата\\ \\ у форматі дд.мм.рррр| |Ні | |Тип Заяви |Текстово-символьний\\ \\ (5) |Тип Заяви.\\ \\ Обирається зі списку:\\ \\ -       створення вулиці;\\ \\ -       створення об’єкта адресації. |Ні | |Статус Заяви |Текст (15) |Статус Заяви, обирається зі списку:\\ \\ -       нова;\\ \\ -       в роботі;\\ \\ -       виконано;\\ \\ -       відмовлено. |Ні | |Дата виконання - Від|Дата\\ \\ у форматі дд.мм.рррр| \\ \\ Поля для завдання періоду/дати виконання Заяви. |Ні | |Дата виконання - до |Дата\\ \\ у форматі дд.мм.рррр| |Ні | |Поля списку | | | | |Номер Заяви |Текстово-символьний (40) |Унікальний номер Заяви (ID Заяви), за яким можна її ідентифікувати. |Так | |Дата подачі |Дата\\ \\ у форматі дд.мм.рррр|Дата створення Заяви. |Так | |Тип Заяви |Текстово-символьний\\ \\ (15) |У відповідності до компонента, який необхідно створити:\\ \\ ·        вулиця;\\ \\ ·        будинок/корпус\\ \\ /секція. |Так | |Коментар |Текстово-символьний\\ \\ (200)|Коментар, який був введений під час подання Заяви. |Ні | |Виконавець |Текст\\ \\ (15) |ПІБ виконавця, який здійснив останню дію, що призвела до зміни статусу Заяви. |Так | |Дата обробки |Дата\\ \\ у форматі дд.мм.рррр|Дата виконання дії з Заявою, що призвела до зміни статусу. |Так | |Статус Заяви |Текст (15) |Поточний статус Заяви на момент перегляду:\\ \\ 1.       нова;\\ \\ 2.       в роботі;\\ \\ 3.       виконано;\\ \\ 4.       відмовлено.|Так |     \\ Рисунок 31. Схема обміну запитами при отримані поточного статусу Заяви   \\ Рисунок 32 Прототип інтерфейсу для перегляду статусів Заяв на створення нових компонентів адреси   === 4.2.3.12 Вимоги до розробки механізму обміну даними між ІС РТГК та «Вітриною даних» === У межах реалізації послуги для обміну інформацією між ІС РТГК та інформаційно-телекомунікаційною системою «Інформаційно-аналітична звітність для органів влади, громадян та бізнесу» (надалі «Вітрина даних») необхідно забезпечити реалізацію програмного інтерфейсу з двома методами: Метод 1 – для передачі інформації щодо кількості зареєстрованих осіб у місті Києві на поточну дату. Вхідні данні: * Токен. * Дата, за яку необхідні данні. Вихідні данні: * Назва адміністративного району міста Києва. * Кількість зареєстрованих осіб (на дату запиту). * Кількість зареєстрованих осіб віком від 18 років (на дату запиту). Метод 2 – для передачі інформації щодо кількості здійснених операцій. Вхідні данні: * Токен; * Дата, за яку необхідні данні. Вихідні данні: * Назва адміністративного району міста Києва. * Кількість операцій щодо формування документа «Довідка про реєстрацію місця проживання особи», які були здійснені співробітниками організацій з категорією ЦНАП (у розрізі адміністративних районів, прив’язка до адміністративного району у відповідності до реєстрації громадянина, який отримав довідку) на дату запиту. * Кількість операцій («кліків»), які були здійснені користувачами ІС РТГК через СВПЗ (у розрізі адміністративних районів) на дату запиту. Кількість операцій повинна рахуватися аналогічним чином до звіту «Ефективність організацій». Для отримання доступу до API «Вітрина даних» повинна бути зареєстрованою у Модулі авторизації, пройти стандартну процедуру авторизації та автентифікації та надіслати до ІС РТГК наданий токен. ===== 4.3 Вимоги до видів забезпечення ===== ==== 4.3.1 Вимоги до математичного забезпечення ==== Математичне забезпечення повинно складатися з алгоритмів і методів обробки інформації, що використовуються під час доопрацювання ІС РТГК і відомостей про їх застосування. ==== 4.3.2 Вимоги до інформаційного забезпечення ==== Інформаційне забезпечення повинно гарантувати: * багаторазове використання даних у різних ділових процесах; * забезпечення фізичної та логічної цілісності даних; * мінімізацію надмірності даних, що зберігаються; * стандартизацію представлення даних; * розмежування доступу до даних, запобігання несанкціонованого доступу до них. Інформаційне забезпечення повинно відповідати таким основним вимогам: * забезпечувати копіювання і зберігання масивів інформації; * забезпечувати мінімізацію обсягу даних, що вводяться вручну; * забезпечувати можливість розширення масивів інформації з урахуванням перспектив розвитку Системи. Інформаційне забезпечення доопрацювань ІС РТГК повинно включати: * систему класифікації і кодування; * програмні модулі забезпечення інформаційного обміну між компонентами Системи та між внутрішніми і зовнішніми інформаційними системами, з якими повинний бути організований обмін. Система класифікації і кодування повинна підтримувати процес накопичення і заощадження інформації, а також вирішення функціональних задач з мінімальними витратами пам‘яті і максимальною швидкодією за рахунок використання класифікаторів таких рівнів: * локальних в межах доопрацювань ІС РТГК; * відомчих; * загальнодержавних. ==== 4.3.3 Вимоги до лінгвістичного забезпечення ==== Лінгвістичне забезпечення доопрацювань повинно включати розвинуті мовні засоби програмування програмного забезпечення та інтерфейсу користувача.   Інтерфейс користувача повинен бути виконаний українською мовою та забезпечувати: * очевидність кожної дії на робочих місцях користувачів та введення-виведення інформації на професійно-орієнтованій мові, яка використовує поняття конкретної предметної області ділових процесів; * наявність ефективної допомоги під час можливих дій користувача; * максимальне використання довідників можливих значень даних під час введення інформації; * попередження помилкових ситуацій. ==== 4.3.4 Вимоги до апаратно-програмного забезпечення ==== Програмне забезпечення (ПЗ) доопрацювань ІС РТГК повинне складатися з: * загальносистемного програмного забезпечення (ЗПЗ); * прикладного програмного забезпечення (ППЗ). Програмне забезпечення повинно відображати специфіку автоматизованих функціональних задач користувачів та забезпечувати: * підтримку загально прийнятих сучасних міжнародних стандартів до відкритих систем; * сумісність та інтегрованість; * підтримку функціонування в різнорідному апаратному і програмному середовищах; * вбудованість механізму захисту від помилок і підтримки цілісності; * мінімальні витрати на їх закупівлю та експлуатацію. До загальносистемного програмного забезпечення відносяться: * операційні системи; * система керування базами даних (СКБД); * офісні застосування; * тощо. Загальносистемне програмне забезпечення не є предметом даного доопрацювання. Рішення зі складу загальносистемного програмного забезпечення повинні бути технічно та економічно обґрунтовані з точки зору цілісності та обґрунтованої повноти програмного застосування доопрацювання ІС РТГК, його компонентів за призначенням та мінімізації витрат на подальший супровід. До прикладного програмного забезпечення повинно відноситись програмне забезпечення, що розробляється та налаштовується під час створення доопрацювань ІС РТГК. За результатами створення та впровадження доопрацювань ІС РТГК програмний код прикладного програмного забезпечення повинен бути переданий Виконавцем Замовнику в електронному вигляді. Розробка прикладного програмного забезпечення повинна проводитись за допомогою сучасних інструментальних засобів програмної інженерії проектування і генерації розподілених баз даних (CASE-засобів). Під час розробки ППЗ повинні використовуватися принципи модульності та типовості, які забезпечать послідовне нарощування функціональних можливостей доопрацювань ІС РТГК за рахунок створення, впровадження та тиражування функціонально завершених програмних модулів. ==== 4.3.5 Рекомендовані вимоги до апаратно-технічного забезпечення, включаючи вже існуюче апаратно-технічне забезпечення інформаційної системи РТГК ==== - Сервер баз даних у кількості: 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. - Сервер додатків у кількості: 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. - Веб-сервер у кількості: 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. - КЕП-валідатор * процесор – 4 core min 2.0 Gz; * оперативний запам'ятовуючий пристрій – не менше ніж 8 GB; * дискова підсистема – System: 100Gb, Data: 200Gb; * операційна система – Windows Server 2012. - Технічні засоби комунікаційної мережі (включаючи лінії зв’язку). Вказаного апаратно-технічного забезпечення достатньо для роботи кількості користувачів, визначеної у п. 4.1.6. Технічні засоби для роботи працівників комунального підприємства «Головний інформаційно-обчислювальний центр» (базові вимоги): * робочі станції (локалізовані персональні комп’ютери з монітором діагоналлю не менше 19”) із доступом до мережі та предвставновленим веб-браузером (детальні вимоги будуть надані у відповідних інструкціях). * лазерний принтер формату А4. Пристрої записування/читання на CD, DVD, USB. ==== 4.3.6 Вимоги до технічного забезпечення ==== Специфікація обчислювальної техніки та апаратних засобів мережевої взаємодії повинна забезпечити поетапну реалізацію функціональних завдань доопрацювань ІС РТГК і враховувати: * наявність існуючих технічних засобів у Замовника; * тенденції розвитку обчислювальної техніки та апаратних засобів зв’язку; * можливість фізичного поєднання різноманітної техніки у єдиний програмно-технічний комплекс; * необхідність взаємодії з зовнішніми автоматизованими системами; * високу пропускну спроможність, надійність і безпечність передачі даних. Автоматизовані робочі місця користувачів Системи повинні бути розгорнуті на базі сучасних комп’ютерів, технічні характеристики яких враховують функціональне використання автоматизованого робочого місця за призначенням та у повному обсязі відповідно до вимог щодо якості та регламентів функціонування відповідного модуля. ==== 4.3.7 Вимоги до метрологічного забезпечення ==== Вимог до метрологічної сумісності технічних засобів доопрацювань ІС РТГК не пред’являється. Якісні характеристики доопрацювань ІС РТГК перевіряються на випробуваннях згідно з Програмою і методикою випробувань. На вимогу Замовника метрологічна сумісність технічних засобів може бути проведена сторонніми організаціями. ==== 4.3.8 Вимоги до організаційного забезпечення ==== Доопрацювання ІС РТГК повинні розроблятися і функціонувати відповідно до вимог чинного законодавства України. Під час доопрацювання Системи повинні бути розроблені кваліфікаційні вимоги до таких категорій користувачів Системи: * авторизовані користувачі, які використовують інформацію доопрацювань ІС РТГК; * обслуговуючий персонал доопрацювань ІС РТГК, а саме: адміністратор та персонал служби захисту, який забезпечує захист інформаційних ресурсів доопрацювань ІС РТГК. ==== 4.3.9 Вимоги до методичного забезпечення ==== Рішення щодо методичного забезпечення повинні враховувати оптимізацію ділових (функціональних) процесів підрозділів відповідно до змін, що відображають автоматизацію цих процесів. У ході виконання робіт з доопрацювання ІС РТГК Виконавець може надати пропозиції щодо внесення змін у нормативні акти (за необхідності) або в нормативно-технічну документацію відповідно до прийнятих технічних та організаційних рішень. ** ** ====== 5 СКЛАД ТА ЗМІСТ ПОСЛУГ ПО ВИКОНАННЮ ДООПРАЦЮВАНЬ СИСТЕМИ ====== - ** **Доопрацювання програмного забезпечення функціональних компонентів, розробка документації: * розробка/модернізація програмного забезпечення функціональних компонентів; * розробка документації. - ** **Проведення попередніх випробувань. - ** **Дослідна експлуатація, розробка документації: * дослідна експлуатація програмного забезпечення; * збір зауважень та коментарів щодо роботи доопрацювань; * доопрацювання з метою врахування зауважень; * розробка документації. - ** **Проведення приймальних випробувань. - ** **Навчання відповідальних співробітників Замовника. Склад документації на Доопрацювання ІС РТГК наведено у Розділі 8 «ВИМОГИ ДО ДОКУМЕНТУВАННЯ». ** ** ====== 6 ПОРЯДОК КОНТРОЛЮ ТА ПРИЙМАННЯ ДООПРАЦЮВАНЬ СИСТЕМИ ====== Порядок контролю та приймання Доопрацювань ІС РТГК повинні відповідати 3 етапам (див. Таблиця 17. Етапи контролю та приймання доопрацювань ІС РТГК). Таблиця 17. Етапи контролю та приймання доопрацювань ІС РТГК |**№ з/п**|**Назва етапу** |**Термін, днів**|**Результат** | |1 |Створення технічного завдання на розробку |25 днів |Технічне завдання.\\ \\ \\ | |2 |Розробка програмного забезпечення та розробка робочої документації|50 днів |Дослідний зразок програмного забезпечення (на окремому диску з відомістю до нього).\\ \\ Програма та методика попередніх випробувань.\\ \\ Протокол попередніх випробувань.\\ \\ Акт приймання в дослідну експлуатацію. | |3 |Дослідна експлуатація, розробка документації |30 днів |Програма та методика дослідної експлуатації.\\ \\ Опис системи (стосовно доопрацювання).\\ \\ Керівництво користувача (розширене).\\ \\ Керівництво адміністратора (розширене).\\ \\ Інструкція з розгортання та налаштування (в частині доопрацювання).\\ \\ Інструкція з формування та ведення бази даних (в частині доопрацювання).\\ \\ Протокол дослідної експлуатації.| **\\ ** ** ** ====== 7 ВИМОГИ ДО СКЛАДУ ТА ЗМІСТУ РОБІТ З ВВЕДЕННЯ ДООПРАЦЮВАНЬ СИСТЕМИ В ДІЮ ====== З метою забезпечення підготовленості об’єкта автоматизації до введення доопрацювань ІС РТГК в дію необхідно: - Погодити з Замовником перелік вхідної та вихідної інформації, яка буде надходити в ІС РТГК і оброблятися із застосуванням ЕОМ. - Провести навчання відповідальних співробітників Замовника, графік якого буде розроблено Виконавцем та погоджено з Замовником. - Забезпечити відповідність комп’ютерного обладнання, на якому повинні розгортатися доопрацювання ІС РТГК, технічним вимогам, що гарантують працездатність програмного забезпечення згідно з технічним завданням. **\\ ** ** ** ====== 8 ВИМОГИ ДО ДОКУМЕНТУВАННЯ ====== Склад і зміст документів, що розроблюються, визначаються згідно з ДСТУ 3973-2000, ДСТУ 3974-2000, ГОСТ 34.201-89, РД 50-34.698-90 і ДСТУ 3008-95 і складає: - Технічне завдання. - Програма та методика попередніх випробувань. - Протокол попередніх випробувань. - Опис системи (стосовно доопрацювання). - Керівництво користувача (розширене). - Керівництво адміністратора (розширене). - Програма та методика дослідної експлуатації. - Інструкція з розгортання та налаштування (в частині доопрацювання). - Інструкція з формування та ведення бази даних (в частині доопрацювання). - Протокол дослідної експлуатації. Документація надається на паперових та електронних носіях. Конкретний склад та зміст документації може бути розширений Виконавцем за згодою Замовника. Прикладне програмне забезпечення повинно бути документовано в об’ємі, визначеному діючими стандартами та достатньому для його ефективного використання, містити в своєму складі підказки, оперативну допомогу. Документація повинна бути достатньою за повнотою і змістом для використання обслуговуючим персоналом та користувачами Системи функціональних можливостей Доопрацювань ІС РТГК у повному обсязі. ** ** СПИСОК РИСУНКІВ [[#_Toc10045264|Рисунок 1. Концептуальна схема логічної архітектури побудови рішення. 28]] [[#_Toc10045265|Рисунок 2. Прототип екранної форми ЕГК підказки про настання події 30]] [[#_Toc10045266|Рисунок 3. Прототип екранної форми ЕГК повідомлення про настання події 31]] [[#_Toc10045267|Рисунок 4. Прототип екранної форми ЕКГ з новим полем «ІПН». 33]] [[#_Toc10045268|Рисунок 5. Прототип екранної форми з повідомленням про факт реєстрації малолітньої дитини у ОЖФ.. 34]] [[#_Toc10045269|Рисунок 6. Прототип екранної форми з повідомленням про наявність реєстрації неповнолітньої особи. 35]] [[#_Toc10045270|Рисунок 7. Прототип екранної форми розділу меню для виконання операції перенесення історії реєстрації/зняття з реєстрації 36]] [[#_Toc10045271|Рисунок 8. Прототип екранної форми для виконання операції перенесення історії реєстрації/зняття з реєстрації в межах однієї будівлі 37]] [[#_Toc10045272|Рисунок 9. Прототип екранної форми для виконання операції перенесення історії реєстрації/зняття з реєстрації з однієї будівлі до іншої 42]] [[#_Toc10045273|Рисунок 10. Прототип екранної форми щодо надання прав до ролі 46]] [[#_Toc10045274|Рисунок 11. Екранна форма з чек-боксом для управління відображенням ПІБ громадян у меню «Витяги» для ролі, яка не має права на перегляд ЕГК.. 47]] [[#_Toc10045275|Рисунок 12. Екранна форма з чек-боксом для управління відображенням ПІБ громадян у меню «Витяги» для ролі, яка має права на перегляд ЕГК.. 48]] [[#_Toc10045276|Рисунок 13. Прототип «Витягу» по приміщенню зі знеособленою інформацією.. 50]] [[#_Toc10045277|Рисунок 14. Прототип екранної форми при формування звіту «Статистика за адресами». 53]] [[#_Toc10045278|Рисунок 15. Прототип документа «Витяг за будинком за період». 54]] [[#_Toc10045279|Рисунок 16. Прототип екранної форми для вибору декількох будинків при формуванні звіту «Кількість зареєстрованих осіб». 56]] [[#_Toc10045280|Рисунок 17. Прототип екранної форми виведення звіту «Кількість зареєстрованих осіб» за декількома будинками. 57]] [[#_Toc10045281|Рисунок 18. Прототип Витягу за декількома будинками. 58]] [[#_Toc10045282|Рисунок 19. Прототип екранної форми щодо надання прав до ролі на доступ до звіту «Кількість зареєстрованих осіб». 60]] [[#_Toc10045283|Рисунок 20. Бізнес процес замовлення та отримання е-послуги «Кількість зареєстрованих за моєю адресою». 63]] [[#_Toc10045284|Рисунок 21. Схема реєстрації користувачів у ІС РТГК з використанням КЕП.. 65]] [[#_Toc10045285|Рисунок 22. Інтерфейс сторінки входу до ІС РТГК.. 66]] [[#_Toc10045286|Рисунок 23. Прототип екранної форми KyivID для входу через КЕП.. 67]] [[#_Toc10045287|Рисунок 24. Схема відправлення повідомлення за шаблоном.. 69]] [[#_Toc10045288|Рисунок 25. Прототип інтерфейсу відправлення повідомлень користувачам за умови ручного формування списку. 70]] [[#_Toc10045289|Рисунок 26. Прототип інтерфейсу відправлення повідомлень користувачам при виборі зі списку користувачів. 71]] [[#_Toc10045290|Рисунок 27. Прототип інтерфейсу історії повідомлень користувачів. 74]] [[#_Toc10045291|Рисунок 28. Схема обміну запитами при створенні нового компонента адреси. 80]] [[#_Toc10045292|Рисунок 29. Прототип інтерфейсу екрана для виклику фрейму на створення нового компоненту адреси. 81]] [[#_Toc10045293|Рисунок 30. Прототип інтерфейсу фрейму Заяви на створення нової вулиці 86]] [[#_Toc10045294|Рисунок 31. Схема обміну запитами при отримані поточного статусу Заяви. 89]] [[#_Toc10045295|Рисунок 32 Прототип інтерфейсу для перегляду статусів Заяв на створення нових компонентів адреси. 90]] \\ ** ** СПИСОК ТАБЛИЦЬ [[#_Toc10045247|Таблиця 1. Перелік подій, за якими відбувається повідомлення користувача. 29]] [[#_Toc10045248|Таблиця 2. Опис поля «ІПН». 32]] [[#_Toc10045249|Таблиця 3. Опис полів фільтра пошуку адреси при перенесенні в межах однієї будівлі 36]] [[#_Toc10045250|Таблиця 4. Опис полів списку приміщень та громадян при перенесення в межах однієї будівлі 38]] [[#_Toc10045251|Таблиця 5. Опис полів фільтра пошуку адреси при перенесенні з однієї будівлі до іншої 40]] [[#_Toc10045252|Таблиця 6. Опис полів списку приміщень та громадян при перенесення з однієї будівлі до іншої 43]] [[#_Toc10045253|Таблиця 7. Результат формування «Витягу по будинку за період» в залежності від комбінації прав доступу ролі 49]] [[#_Toc10045254|Таблиця 8. Опис полів періоду формування звіту «Статистика за адресами». 51]] [[#_Toc10045255|Таблиця 9. Опис полів звіту «Кількість зареєстрованих осіб» за декількома будинками. 58]] [[#_Toc10045256|Таблиця 10. Опис полів Витягу за декількома будинками. 59]] [[#_Toc10045257|Таблиця 11. Опис полів списку для відправлення повідомлень користувачам.. 72]] [[#_Toc10045258|Таблиця 12. Опис фільтрів для пошуку повідомлень в історії 75]] [[#_Toc10045259|Таблиця 13. Опис полів списку історії відправлених повідомлень. 76]] [[#_Toc10045260|Таблиця 14. Базовий набір статусів відповідей (повідомлень) Системи. 78]] [[#_Toc10045261|Таблиця 15. Опис полів фрейму на створення нових компонентів адреси. 82]] [[#_Toc10045262|Таблиця 16. Опис фільтрів пошуку та полів списку перегляду статусу Заяв на нові компоненти адрес. 87]] [[#_Toc10045263|Таблиця 17. Етапи контролю та приймання доопрацювань ІС РТГК.. 98]]     |**\\ **\\ \\ ЛИСТ РЕЄСТРАЦІЇ ЗМІН| | | | | | | | |Зміна |Номери аркушів (сторінок)| | |Всього аркушів (сторінок) в документі|№\\ \\ документа|Вх. № супровідного документа та дата|Підпис і дата| | |Замінених |Введених|Вилучених| | | | | |\\ |\\ |\\ |\\ |\\ |\\ |\\ |\\ |