- [[29037073:index|(Б-24) Програмний модуль «Реєстр дітей»]] - [[.|Програмний модуль Реєстр Дітей]] ====== (Б-24) Програмний модуль «Реєстр дітей» : Відомості про систему ====== |**ЗАТВЕРДЖУЮ**\\ \\ КП «Головний інформаційно-обчислювальний центр» |**ЗАТВЕРДЖУЮ**\\ \\ ТОВ «ЕФ ДІ АЙ КАМПАНІ»\\ \\ \\ | |Директор |Директор | |%%__%%%%__%%%%__%%%%__%%%%__%%%%__%%%%__%%%%__%%%%__%% В. М. Козубський |%%__%%%%__%%%%__%%%%__%%%%__%%%%__%%%%__%%%%__%%%%__%% М. В. Козлов | |\\ \\ \\ «%%__%%%%__%%_»  %%__%%%%__%%%%__%%%%__%%%%__%%%%__%%%%__%%_ 2018 р.\\ \\ \\ |\\ \\ \\ «%%__%%%%__%%_»  %%__%%%%__%%%%__%%%%__%%%%__%%%%__%%%%__%%%%__%% 2018 р.| **Створення інформаційної системи** **«Муніципальний Реєстр міста Києва»** **та його розвиток** **2** **черга** ** ** **ТЕХНІЧНЕ ЗАВДАННЯ** **на створення програмного модуля «Реєстр дітей»**\\ ** Шифр: ПМ РД** **37770359.184154.4458.ТЗ.2** На %%__%%%%__%%_ аркушах \\ діє з  «%%__%%%%__%%_»%%__%%%%__%%%%__%%%%__%%%%__%%%%__%%_2018 року \\ |**Від  Замовника:** |** **|**Від Виконавця:** | |Начальник департаменту\\ \\ впровадження та супроводу\\ \\ інформаційно-комунікаційних систем |\\ |Керівник проекту | |%%__%%%%__%%%%__%%%%__%%%%__%%%%__%%%%__%%_О. П. Перевозник |\\ |%%__%%%%__%%%%__%%%%__%%%%__%%%%__%%%%__%%_ Є. В. Чернов| |\\ \\ \\ В.о. начальника департаменту\\ \\ впровадження та технологічного супроводження обліково-фінансових систем|\\ |\\ | |%%__%%%%__%%%%__%%%%__%%%%__%%%%__%%%%__%%%%__%%_А. П. Гусаревич |\\ |\\ | |Провідний інженер відділу впровадження та розвитку інформаційно-комунікаційних систем |\\ |\\ | |%%__%%%%__%%%%__%%%%__%%%%__%%%%__%%%%__%%%%__%%_К. П. Плєвако\\ \\ \\ |\\ |\\ | Київ  2018 **ЗМІСТ** 1.. ЗАГАЛЬНІ ВІДОМОСТІ. 16 1.1 Повне найменування системи та її умовне позначення. 16 1.2 Шифр теми або шифр (номер) Договору. 16 1.3 Найменування установ розробника і замовника, банківські реквізити. 16 1.4 Планові терміни початку та закінчення надання послуг. 16 1.5 Перелік документів, на підставі яких надаються послуги. 17 1.6 Відомості про джерела і порядок фінансування робіт. 20 1.7 Порядок оформлення і пред’явлення замовнику результатів наданих послуг. 21 2.. ПРИЗНАЧЕННЯ ТА ЦІЛІ СТВОРЕННЯ СИСТЕМИ.. 22 2.1 Призначення. 22 2.2 Мета розвитку. 22 2.3 Ціль. 22 3.. ХАРАКТЕРИСТИКА ОБ’ЕКТУ АВТОМАТИЗАЦІЇ. 24 3.1 Відомості про об’єкт автоматизації 24 3.2 Відомості про умови експлуатації об’єкта автоматизації і характеристиках навколишнього середовища. 24 4.. ФУНКЦІОНАЛЬНІ ВИМОГИ ЩОДО РОЗВИТКУ ІС МР. 26 4.1 Загальні вимоги. 26 4.2 Загальна логічна схема рішення. 26 4.3 Вимоги до реалізації компонента ЗО.. 29 4.3.1       Вимоги до реалізації Паспорт ЗО.. 29 4.3.2       Вимоги до реалізації блоку Учень. 35 4.3.3       Вимоги до реалізації блоку Співробітник ЗО.. 37 4.4 Вимоги до реалізації компонента ЗДО.. 40 4.4.1       Вимоги до реалізації блоку Вихованець ЗДО.. 41 4.5 Вимоги до реалізації компонента «Районне управління освіти». 45 4.5.1       Вимоги до блоку паспорт ЗО.. 45 4.5.2       Вимоги до блока співробітник ЗО.. 45 4.5.3       Вимоги до блока учень ЗО.. 45 4.5.4       Вимоги до блока вихованець ЗДО.. 45 4.5.5       Вимоги до реалізації компонента ДОН.. 45 4.5.6       Вимоги до блоку паспорт ЗО.. 45 4.5.7       Вимоги до блока співробітник ЗО.. 45 4.5.8       Вимоги до блока учень ЗО.. 45 4.5.9       Вимоги до блока вихованець ЗДО.. 45 4.6 Вимоги до реалізації програмної підсистеми обміну даними з Електронною чергою.. 45 4.7 Вимоги до реалізації підсистеми адміністрування. 46 4.7.1       Вимоги до рольової моделі 47 4.7.2       Вимоги до функції «Перегляд нових Користувачів». 52 4.7.3       Вимоги до функції «Надання повноважень та активація Користувача». 54 4.8 Вимоги до АРМ «Заклад дошкільної освіти». 54 4.8.1       Вимоги до реєстрації користувачів. 54 4.8.2       Вимоги до авторизації та автентифікації користувачів. 57 4.8.3       Вимоги до функції «Пошук картки вихованця». 57 4.8.4       Вимоги до програмного компонента «Перегляд картки вихованця». 58 4.8.5       Вимоги до функції «Друк картки вихованця». 59 4.9 Вимоги до АРМ «Заклад освіти». 59 4.9.1       Вимоги до реєстрації користувачів. 59 4.9.2       Вимоги до авторизації та автентифікації користувачів. 59 4.9.3       Вимоги до функції «Створення паспорту ЗО». 59 4.9.4       Вимоги до функції «Перегляд паспорта ЗО». 60 4.9.5       Вимоги до функції «Друк паспорта ЗО». 60 4.9.6       Вимоги до функції «Логічне видалення паспорта ЗО». 61 4.9.7       Вимоги до функції «Додання фото ЗО у паспорт». 61 4.9.8       Вимоги до функції «Редагування ЗО». 61 4.9.9       Вимоги до функції «Експорт даних». 61 4.9.10           Вимоги до функції «Пошук картки учня». 62 4.9.11           Вимоги до функції «Перегляд картки Учня». 63 4.9.12           Вимоги до функції «Друк картки Учня». 63 4.9.13           Вимоги до функції «Створення картки Учня». 63 4.9.14           Вимоги до функції «Редагування картки Учня». 64 4.9.15           Вимоги до функції «Логічне видалення та активація статусу навчання Учня»  65 4.9.16           Вимоги до функції «Створення картки співробітника». 65 4.9.17           Вимоги до функції «Редагування картки співробітника». 66 4.9.18           Вимоги до функції «Пошук картки співробітника». 67 4.9.19           Вимоги до функції «Перегляд картки співробітника». 68 4.9.20           Вимоги до функції «Друк  картки співробітника». 68 4.9.21           Вимоги до функції «Деактивація та активація картки співробітника». 68 4.10 Вимоги до АРМ «Адміністратора». 69 4.10.1           Вимоги до реєстрації користувачів. 69 4.10.2           Вимоги до авторизації та автентифікації користувачів. 69 4.10.3           Вимоги до функції «Створення ролі». 69 4.10.4           Вимоги до функції «Редагування ролі». 71 4.10.5           Вимоги до функції «Перегляд ролі». 71 4.10.6           Вимоги до функції «Перегляд списку ролей». 72 4.10.7           Вимоги до функції «Деактивація ролі». 73 4.10.8           Вимоги до функції «Перегляд списку користувачів». 73 4.10.9           Вимоги до функції «Пошук Користувача». 75 4.10.10        Вимоги до функції «Перегляд інформації по Користувачу». 75 4.10.11        Вимоги до функції «Деактивація Користувача». 76 4.10.12        Вимоги до функції «Редагування Користувача». 76 4.10.13        Вимоги до функції «Перегляд списку довідників». 77 4.10.14        Вимоги до функції «Перегляд Довідника». 83 4.10.15        Вимоги до функції у «Створення запису довідника». 83 4.10.16        Вимоги до функції «Деактивація запису довідника». 84 4.10.17        Вимоги до функції «Редагування запису довідника». 84 4.11 Вимоги до АРМ «Адміністратора». 84 4.11.1           Вимоги до реєстрації користувачів. 84 4.11.2           Вимоги до авторизації та автентифікації користувачів. 84 4.11.3           Вимоги до функції «Пошук по списку паспортів Закладів освіти». 84 5.. НЕФУНКЦІОНАЛЬНІ ВИМОГИ ДО СИСТЕМИ.. 86 5.1 Загальні вимоги. 86 5.1            Вимоги до чисельності, кваліфікації та режиму роботи персоналу. 86 5.2            Вимоги до показників навантаження. 87 5.3            Вимоги до надійності 87 5.4            Вимоги до інформаційної безпеки. 87 5.5            Вимоги до ергономіки. 88 5.5.1       Веб-інтерфейс повинен відповідати таким вимогам щодо використання технологій при його створенні: 88 5.5.2       В цілому передбачається сумісність: 88 5.5.3       Основні вимоги до інформаційно-графічних елементів веб-інтерфейсу. 89 5.6            Вимоги до експлуатації і технічного обслуговування, ремонту та зберігання компонентів ПМ РД ІС МР. 89 5.7            Вимоги до режимів функціонування. 89 5.8            Вимоги до збереження інформації при аваріях. 90 5.9            Вимоги до патентної чистоти. 90 5.10         Вимоги до стандартизації і уніфікації 91 5.11         Вимоги до видів забезпечення. 91 5.11.1           Вимоги до математичного забезпечення. 92 5.11.2           Вимоги до лінгвістичного забезпечення. 92 5.11.3           Вимоги до апаратно-програмного забезпечення. 92 5.11.4           Вимоги до технічного забезпечення. 95 5.11.5           Вимоги до метрологічного забезпечення. 96 5.11.6           Вимоги до організаційного забезпечення. 96 5.11.7           Вимоги до методичного забезпечення. 97 6.. СКЛАД ТА ЗМІСТ ЗАВДАНЬ ЗІ СТВОРЕННЯ ПМ РД.. 98 7.. ПОРЯДОК КОНТРОЛЮ ВИКОНАННЯ ТА ПРИЙМАННЯ.. 99 8.. ВИМОГИ ДО СКЛАДУ ТА ЗМІСТУ ПОСЛУГ З ПІДГОТОВКИ ОБ’ЄКТА АВТОМАТИЗАЦІЇ ДО ВВЕДЕННЯ В ДІЮ... 100 9.. ВИМОГИ ДО ДОКУМЕНТУВАННЯ.. 101 10.      ДЖЕРЕЛА РОЗРОБКИ.. 102 СПИСОК РИСУНКІВ.. 103 СПИСОК ТАБЛИЦЬ. 104 ЛИСТ РЕЄСТРАЦІЇ ЗМІН.. 105 ** ** \\ ПЕРЕЛІК УМОВНИХ СКОРОЧЕНЬ ^Термін ^Значення ^ |API |Прикладний програмний інтерфейс ([[https://uk.wikipedia.org/wiki/%D0%90%D0%BD%D0%B3%D0%BB%D1%96%D0%B9%D1%81%D1%8C%D0%BA%D0%B0_%D0%BC%D0%BE%D0%B2%D0%B0|англ.]] //Application Programming Interface//, API) – набір запитів відповідної структури до сторонніх систем та сайтів. | |BankID |Єдина національна система електронної дистанційної ідентифікації фізичних і юридичних осіб BankID, який регламентується постановою Правління Національного банку України №378 від 30 серпня 2016 року "Про затвердження Положення про Єдину національну систему електронної дистанційної ідентифікації фізичних і юридичних осіб BankID Національного банку України".\\ \\ Згідно Рішення №3 від 10.06.2016. Зареєстровано в Міністерстві юстиції України 15 липня 2016 р. за № 959/29089 «Про функціонування Єдиного державного реєстру декларацій осіб, уповноважених на виконання функцій держави або місцевого самоврядування».\\ \\ BankID – це спосіб електронної ідентифікації жителів через українські банки для надання адміністративних та інших послуг через Інтернет. В даному документі розглядається:\\ \\ * PrivatBank BankID. Cпосіб електронної ідентифікації жителів через сервіси авторизації Приват Банку для надання адміністративних та інших послуг через Інтернет.\\ * ID KyivCard – це соціальний ID (Соціальна карта), який повинен ідентифікувати жителя м. Києва. В даному випадку Ощадбанк надає послугу видачі Соціальної карти і виступає агентом BankID.| |Character |Тип даних, який застосовується, якщо потрібно використовувати літери, цифри, пробіли, символи і знаки пунктуації. В поля і змінні типу character заноситься текстова інформація, яка не використовується в математичних обчисленнях. | |VARCHAR, character varying |Тип даних, який застосовується для позначення рядку обмеженого змінною довжини. | |Data |Тип даних. Служить для представлення дати. | |Database, База даних, БД\\ \\ \\ |Сукупність даних, організованих відповідно до концепції, яка описує характеристику цих даних і взаємозв'язки між їх елементами; ця сукупність підтримує щонайменше одну з областей застосування. | |ExternalID |Ідентифікатор профілю жителя в джерелі даних згідно ТЗ. | |Enum |Тип даних, який містить перелік з набору допустимих значень, що задано заздалегіть. | |File Storage |Модель хмарного сховища для зберігання комп'ютерних даних, в якій цифрові дані зберігаються в логічних пулах. Фізична пам'ять охоплює кілька серверів, а фізичне середовище, як правило, належить і керується хостинговою компанією. | |FLOAT |Тип приблизних числових даних, використовується для числових даних з «плаваючою комою» | |FOSS |Вільне програмне забезпечення з загальнодоступними (відкритими) вихідними кодами (англ. Free and Open Source Software) – категорія програмного забезпечення, яка включає в себе як вільне, так і відкрите програмне забезпечення. | |HTTP/HTTPs |Протокол передачі даних, що використовується в [[https://uk.wikipedia.org/wiki/%D0%9A%D0%BE%D0%BC%D0%BF%27%D1%8E%D1%82%D0%B5%D1%80|комп'ютерних]] мережах (англ. //Hyper Text Transfer Protocol//).\\ \\ HTTPs протокол з додатковим шаром шифрування/ автентифікації між HTTP і [[https://uk.wikipedia.org/wiki/TCP|TCP]] з метою забезпечення безпеки комунікацій. | |ID Картка |Нова форма паспорта громадянина України з безконтактним електронним носієм. У паспорт у формі картки вноситься наступна інформація: назва держави, назва документа, ім'я (з латинською транслітерацією, яку можна узгодити відповідно до інших документів, наприклад, посвідчення водія), стать, дата народження, унікальний номер запису в Єдиному державному демографічному реєстрі, номер самого документа, дата його видачі і закінчення терміну його дії, код уповноваженого суб'єкта, який видав паспорт, місце народження, оцифроване зображення обличчя та підпис власника картки. | |INT, Integer |Цілочисельний тип даних ([[https://ru.wikipedia.org/wiki/%D0%90%D0%BD%D0%B3%D0%BB%D0%B8%D0%B9%D1%81%D0%BA%D0%B8%D0%B9_%D1%8F%D0%B7%D1%8B%D0%BA|англ.]] //Integer//). Служить для представлення цілих чисел. Набір чисел цього типу являє собою кінцеву підмножину нескінченної кількості цілих чисел, обмежених максимальним і мінімальним значеннями. | |JSON |Текстовий формат обміну даними, заснований на JavaScript. | |KyivID |Унікальний ідентифікатор, який присвоюється користувачу, що є одержувачем (зокрема потенційним одержувачем) послуг, заходів соціальної підтримки та служить персональним електронним ключем. | |Long |Тип даних число яке  має розмір 8 байт (64 біт). | |OAuth 2.0 |Протокол авторизації, що дозволяє видати одному сервісу (із застосунками) права на доступ до ресурсів користувача на іншому сервісі. Протокол позбавляє від необхідності довіряти застосунку логін і пароль, а також дозволяє видавати обмежений набір прав, а не всі права одразу. | |OpenID Connect 1.0 |Відкритий протокол автентифікації, який дозволяє отримати третій стороні обмежений доступ до захищених ресурсів користувача без необхідності передавати їй (третій стороні) логін та пароль. | |Open Shift |Засіб для розробників створювати, розгортати та масштабувати програми для контейнерів ([[http://www.openshift.com|www.openshift.com]]). | |ProfileID |Ідентифікатор майстер-профілю сутності "Житель" в ІС МР. Потрібен для об'єднання відповідних Профілів МР в одну сутність при запитах ЗІС на отримання даних про конкретну людину. Присвоюється в ІС МР при створені Профілю МР (першому отримані даних від джерела). | |REST (Restfull) |Representational State Transfer або  «передача репрезентативного стану», див. [[http://uk.wikipedia.org/wiki/REST|uk.wikipedia.org/wiki/REST]]. | |Scope |Набір повноважень та перелік даних, які отримує користувач або ЗІС при роботі з програмами (системами, модулями) | |TCP |Протокол, що призначений для управління передачею даних у мережах (англ. //Transmission Control Protocol).// Забезпечує надійне доправляння даних від відправника до отримувача (працює зі встановленням з’єднання). | |text |Тип даних, що означає рядок необмеженої змінної довжини. | |URL |Uniform Resource Locator, див. [[http://uk.wikipedia.org/wiki/Уніфікований_локатор_ресурсів|uk.wikipedia.org/wiki/Уніфікований_локатор_ресурсів]]. | |UUID |Тип даних, який представляє собою  16-байтний (128-бітний) номер. | |WFS |Web Map Service, див. [[http://uk.wikipedia.org/wiki/Web_Map_Service|uk.wikipedia.org/wiki/Web_Map_Service]]. | |WMS |[[https://uk.wikipedia.org/wiki/Warehouse_Management_System|Warehouse Management System]]. | |XML |Стандарт побудови структурованих [[https://uk.wikipedia.org/wiki/%D0%94%D0%B0%D0%BD%D1%96|даних]] для обміну між різними [[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%86%D0%BD%D1%82%D0%B5%D1%80%D0%BD%D0%B5%D1%82|Інтернет]] (англ. //Extensible Markup Language).// | |Автентифікація |Електронна процедура, яка дає можливість підтвердити електронну ідентифікацію фізичної особи та/або походження і цілісність електронних даних. | |Авторизація |Процес надання особі/процесу прав на виконання певних дій або доступу до ресурсів, а також процес перевірки (підтвердження) прав при спробі виконання цих дій. | |Адміністратор |Спеціально навчений співробітник організації, який супроводить роботу ІС МР. Функцією Адміністратора є створення, налаштування та забезпечення працездатності всіх складових програми. | |Адміністративний район, район, район міста|Адміністративно-територіальний устрій, підпорядкований місту. Місто Київ поділяється на десять адміністративних міських районів, утворених за радіальним принципом і назв за географічним принципом. | |Адреса |Структурований опис сукупності реквізитів місця розташування об’єкта нерухомості жилого фонду на місцевості, що однозначно визначає даний об’єкт.\\ \\ Повна адреса складається з назви країни, індексу поштового відділення, назви обласного центру, назви районного центру, назви вулиці, номера будівлі, споруди, майнового комплексу. Номер об'єкта нерухомості позначається відповідною арабською цифрою.\\ \\ Наприклад:\\ \\ Повна адреса: Україна, 16600, Чернігівська область, Ніжинський район, місто Ніжин, вулиця Івана Пулюя, будинок 27.\\ \\ Скорочена адреса: Україна, 16600, Чернігівська обл., Ніжинський р-н, м. Ніжин вул. І. Пулюя, буд. 27. | |Адреса реєстрації |Адреса офіційного місця проживання жителя за відповідною адресою об’єкта нерухомості жилого фонду\\ м. Києва, тобто створений обліковий запис в РТГК. | |Адреса проживання |Адреса фактичного проживання на території міста Києва. | |АРМ |Індивідуальний комплекс технічних і програмних засобів, що призначений для автоматизації професійної праці фахівця і забезпечує підготовку, редагування, пошук і видачу на екран і друк необхідних йому документів і даних. | |АЦКС |Акредитований центр сертифікації ключів. | |Будинок |Номер будинку – це складова частина адреси. | |БД |База даних. | |Веб-сервіс, сервіс |Програмна система, що ідентифікується рядком URI (англ. //Uniform Resource Identifier//), чиї загальнодоступні інтерфейси визначені на мові XML або JSON. Опис цієї програмної системи може бути знайдено іншими програмними системами, які можуть взаємодіяти з нею згідно з цим описом за допомогою повідомлень, що засновані на XML, JSON та передаються за допомогою інтернет протоколів. | |Відкриті системи |Системи, в яких реалізований вичерпний і узгоджений набір міжнародних стандартів інформаційних технологій і профілів функціональних стандартів, які специфікують інтерфейси, сервіси та підтримувані формати даних, щоб забезпечити інтероперабельність і мобільність додатків, даних і персоналу. | |Вихованець |Дитина, у віці до 7 років, яка здобуває освіту в дошкільних навчальних закладах. | |Вулиця |Назва вулиці – це складова частина адреси. | |ГУДКСУ |Головне управління Державної казначейської служби України. | |Громадянство |Громадянство – це постійний політико-правовий зв'язок особи з державою, який зумовлює наявність у них взаємних прав, свобод, законних інтересів та обов'язків, як на території країни, так і за її межами. | |Дата народження |День, місяць та рік народження жителя. | |Дата реєстрації |День, місяць та рік реєстрації місця проживання жителя по відповідному адресу об’єкта нерухомості жилого фонду м. Києва, тобто створення облікового запису в РТГК. | |ДОН |Департамент освіти і науки КМДА, Департамент освіти і науки КМДА.  Назва до розділу – Департамент освіти і науки, молоді та спорту КМДА. | |Документ |Дані довідника Типи документів. | |ДРФО |Державний реєстр фізичних осіб платників податків | |ДСТУ |С[[https://uk.wikipedia.org/wiki/%D0%A1%D1%82%D0%B0%D0%BD%D0%B4%D0%B0%D1%80%D1%82|тандарти]], розроблені відповідно до чинного законодавства України, що встановлюють для загального і багаторазового застосування правила, загальні принципи або характеристики, які стосуються діяльності чи її результатів, з метою досягнення оптимального ступеня впорядкованості, розроблені на основі [[https://uk.wikipedia.org/wiki/%D0%9A%D0%BE%D0%BD%D1%81%D0%B5%D0%BD%D1%81%D1%83%D1%81|консенсусу]] та затверджені уповноваженим органом. | |Ім’я |Ім’я – це особиста назва людини, що дається їй після народження.\\ \\ Ім’я – це частина повного імені жителя. | |ЕЦП, Електронний цифровий підпис |Вид електронного підпису, отриманого за результатом криптографічного перетворення набору електронних даних, який додається до цього набору або логічно з ним поєднується і дає змогу підтвердити його цілісність та ідентифікувати підписанта. Електронний цифровий підпис накладається за допомогою особистого ключа та перевіряється за допомогою відкритого ключа. | |ЄДРПОУ |[[https://uk.wikipedia.org/wiki/%D0%A1%D1%82%D0%B0%D1%82%D0%B8%D1%81%D1%82%D0%B8%D1%87%D0%BD%D0%B8%D0%B9_%D1%80%D0%B5%D1%94%D1%81%D1%82%D1%80_%D0%BF%D1%96%D0%B4%D0%BF%D1%80%D0%B8%D1%94%D0%BC%D1%81%D1%82%D0%B2|Статистичний реєстр підприємств]] в Україні, автоматизована система збирання, накопичення та обробки даних про підприємства та організації усіх форм власності, а також їх відокремлені підрозділи – філії, відділення, представництва тощо. | |Житель |Людина, яка зареєстрована на території міста та обліковується за допомогою систем міста Києва. | |Загальний стаж |Сумарна тривалість роботи робітником або службовцем, або в іншій суспільно-корисній діяльності, якщо їх включення в трудовий стаж передбачено чинним законодавством. | |ЗДО, дитячий садок |Навчальний заклад дошкільної освіти, що забезпечує реалізацію права дитини на здобуття дошкільної освіти, її фізичний, розумовий і духовний розвиток, соціальну адаптацію та готовність продовжувати освіту. Стара назва – ДНЗ. | |ЗІС |Зовнішня інформаційна система. | |ЗО, заклад освіти |Організація, що забезпечують здобуття загальної середньої освіти на різних її рівнях на постійній і безперервній основі. Та здійснює освітній процес з метою навчання, виховання, розвитку і самовдосконалення особистості. | |ЗЗСО, школа |Загальний заклад середньої освіти, що забезпечує реалізацію права громадян на здобуття загальної середньої освіти. Стара назва – ЗНЗ. | |ІАА |Ідентифікація → Автентифікація → Авторизація. | |Ідентифікатор користувача |Унікальний ідентифікатор, який присвоюється користувачу, що є одержувачем (зокрема потенційним одержувачем) послуг, заходів соціальної підтримки, та служить персональним електронним ключем в системах Києва. | |Ідентифікація |Процедура розпізнавання користувача в системі, як правило, за допомогою наперед визначеного імені (ідентифікатора), або іншої апріорної інформації про нього, яка сприймається системою. Залежно від ситуації, це може бути ім’я, адреса електронної пошти, номер облікового запису і т.д. | |Інтероперабельність |Здатність продукту або системи, інтерфейси яких повністю відкриті, взаємодіяти і функціонувати з іншими продуктами або системами без будь-яких обмежень доступу і реалізації. | |ІС МР |Інформаційна система «Муніципальний реєстр» – це автоматизована система управління реєстром жителів міста Києва, а також реєстром операцій їх активності в інформаційних системах міста Києва. | |Квартира |Квартира – ізольоване помешкання в жилому будинку, призначене для проживання фізичних осіб.\\ \\ Номер квартири – це складова частина адреси. | |Класифікатор |Систематизований перелік об'єктів, кожному з яких присвоєний власний певний шифр, код. | |КМДА |Київська міська державна адміністрація. | |Компонент |Під компонентом розуміється АРМ або сервіс ПМ РД. | |Користувач МР |Технічний користувач, під яким виконуються всі дії в системі. | |Користувач |Чиновник, який в рамках посадових повноважень використовує АРМ ПМ РД. | |Країна |Країна – це політичне, національне, соціальне, культурне, господарське співтовариство, організоване державою на певній території\\ \\ Визначена територія, що становить єдність з погляду історії, природних умов, населення (спільноти людей, що проживають на цій території), що в політико-географічному відношенні мусить мати державний суверенітет.\\ \\ Назва Країни – це складова частина адресу. | |КСЗІ |Комплексна система захисту інформації. | |Літера будинку |Літера будинку – це складова частина адреси.\\ \\ Якщо на відповідній вулиці збудовано нові об'єкти і їм, виходячи з уже наявної нумерації об'єктів нерухомого майна по вулиці, на якій вони фактично знаходяться, неможливо надати номер, який є цілим числом, такий об'єкт нерухомого майна при наданні поштової адреси позначається номером найближчого об'єкта нерухомого майна по відповідному боку вулиці в бік зменшення (можливо, і збільшення) з відповідною заголовною літерою через дефіс.\\ \\ Наприклад:\\ \\ Повна поштова адреса: вулиця Івана Пулюя, будинок 25-а, Скорочена поштова адреса: вул. І. Пулюя, буд. 25-а. | |Матчинг |Пошук та перевірка на співпадання однакових атрибутів даних з різних профілів Жителя від ЗІС. | |Мікросервіс |Це підхід, при якому додаток будується як набір невеликих сервісів, кожен з яких працює у власному процесі та комунікує з іншими. Ці сервіси будуються навколо бізнес-потреб. | |Місце народження |Місце, де був народжений суб'єкт, тобто житель. | |МР |Муніципальний реєстр ІС МР. | |МР ID (МР ID.ОС) |Універсальна освітня складова, що міститиме інформацію про освітню активність киянина. | |Модуль |Функціональна частина системи, яка виконує певну функцію, має закінчене оформлення та засоби сполучення з іншими частинами. | |МФО |Реквізит [[https://uk.wikipedia.org/wiki/%D0%91%D0%B0%D0%BD%D0%BA|банку]], визначений і включений до довідника банківських установ України згідно з нормативно-правовими актами [[https://uk.wikipedia.org/wiki/%D0%9D%D0%B0%D1%86%D1%96%D0%BE%D0%BD%D0%B0%D0%BB%D1%8C%D0%BD%D0%B8%D0%B9_%D0%B1%D0%B0%D0%BD%D0%BA_%D0%A3%D0%BA%D1%80%D0%B0%D1%97%D0%BD%D0%B8|Національного банку]], що регулюють питання міжбанківських розрахунків в Україні. | |Навчальний предмет |Педагогічно адаптована сукупність знань, умінь і навичок з окремої наукової галузі та змісту відповідної діяльності із засвоєння та використання цих знань, умінь і навичок у процесі навчання. | |Населений пункт |Населений пункт (село, селище, поселення, місто) – це первинний рівень за адміністративно-територіальним устроєм України, виділений у самостійну адміністративно-територіальну одиницю.\\ \\ Населений пункт – це частина комплексно заселеної території України, яка склалася внаслідок господарської та іншої суспільної діяльності, має сталий склад населення, власну назву та зареєстрована в порядку, передбаченому законом.\\ \\ Населений пункт – це складова частина адреси. | |Нозологія |Довідник, що відповідає класифікатору міжнародної статистичної класифікації хвороб та споріднених проблем охорони здоров'я МКХ-10 (ICD-10). | |Область |Основна складова частина території України, яка історично склалася і характеризується певним організаційним відособленням, цілісністю, економічною та соціальною самодостатністю, місцевими особливостями і традиціями.\\ \\ Область – це складова частина адреси. | |Обліковий запис |Запис, що призначений для ведення обліку, за допомогою якого постачальник послуг ідентифікує жителя, що звертається до його послуг. В обліковому записі міститься інформація, яку житель повідомляє про себе системі. | |ОКК |Інформаційна автоматизована система «Особистий Кабінет Киянина». | |Паспорт |Паспорт громадянина України – це основний документ, що посвідчує особу та підтверджує громадянство України. Видається кожному громадянинові України центральним органом виконавчої влади, що реалізує державну політику у сфері громадянства. | |Педагогічний стаж |Сумарна тривалість трудової діяльності працівників в освітніх закладах на посадах, пов’язаних з навчальним процесом. | |Персональна складова ID МР |Персональна складова частина профілю Користувача ОКК в ІС МР – це універсальна персональна складова профілю Користувача ОКК, яка автоматично формується після успішного виконання ІАА його в ЗІС (ОКК) за допомогою акредитованих засобів реєстрації (PrivatBank BankID, KyivCard, ЕЦП). | |ПІБ |Прізвище, Ім’я, По батькові. | |По батькові |Ім’я по батькові – це вид антропоніма (патронім), утворений від офіційного імені батька за допомогою суфіксів -ич(-іч), -ович (для чоловіків) та -івна (для жінок).\\ \\ Ім’я по батькові – це частина повного імені жителя. | |Посада |Визначена структурою і штатним розписом первинна структурна одиниця державного або муніципального органу та його апарату, на яку покладено встановлене нормативними актами коло службових повноважень. Визначається згідно типових штатних нормативів закладів загальної середньої освіти. | |Прізвище |Прізвище – це найменування особи, набуте при народженні або вступі в шлюб, що передається від покоління до покоління і вказує на спорідненість.\\ \\ Прізвище – це частина повного імені жителя. | |Провайдер |Системи постачальники даних до МР (РТКГ, ІС НСС, ОКК тощо). | |Профайл (Інформаційний профайл) |Набір профілів даних жителя в МР. | |Профіль |Колекція (набір) даних про жителя, які отримані від відповідної ЗІС (РТГК, ІС НСС тощо) та записані до МР. | |ПП |Приватне підприємство | |РІАА |Реєстрація →Ідентифікація →Автентифікація →Авторизація  | |Реєстрація |Спосіб Користувача повідомити сайту (системі) дані про себе і в обмін отримати доступ до додаткових можливостей (наприклад, додати що небудь в обране) або ресурсів (наприклад, файлів) на сайті, які недоступні незареєстрованим користувачам (Гостям). Реєстрація нероздільна з авторизацією. Фактично, реєстрація – це спосіб отримати можливість увійти на сайт (в систему) з певною метою та вигодою. | |Роль |Клас користувачів системи, що володіють певним набором прав доступу. | |Рольова модель |Правила розподілу повноважень користувачів в системі. | |РНОКПП (раніше ІПН) |Реєстраційний номер облікової картки платника податків. | |РУО |Районне управління освіти. | |ІС НСС |\\ | |СА |Сервіс авторизації. | |Свідоцтво про народження, Свідоцтво |Офіційний стандартний документ, який засвідчує факт народження нової людини. Видається протягом місяця після народження дитини. У свідоцтві про народження дитини обов’язково повинні міститися відомості про батьків. | |Сервіс |Функціональна частина системи, яка виконує певну задачу що повторюється. | |Сервіс профілю МР |Веб-сервіс, який представляє собою набір програмних інтерфейсів та забезпечує управління записами профілів Користувачів в Муніципальному реєстрі. | |Система |Апаратно програмний комплекс, метою якого є обробка, збереження, ввід-вивід інформації. | |СКБД |Система керування базою даних. | |Спеціальність |Комплекс набутих людиною знань і практичних навичок, що дає їй можливість займатися певним родом занять у якійсь галузі діяльності. | |Стать |Біологічно (генетично) зумовлений поділ осіб на чоловіків та жінок із потенційною можливістю додавання невизначеної статі. | |Учень |Особа, яка здобуває повну загальну середню освіту у загальноосвітньому навчальному закладі. | ====== 1.      ЗАГАЛЬНІ ВІДОМОСТІ ====== ===== 1.1 Повне найменування системи та її умовне позначення ===== **Повна назва:** Інформаційна система «Муніципальний Реєстр», 2 черга. Програмний модуль «Реєстр Дітей». **Скорочена назва:** ПМ РД ===== 1.2 Шифр теми або шифр (номер) Договору ===== Договір про надання послуг від 10 вересня 2018 року № 4458. Найменування послуги: код за ДК 021:2015:72210000-0 Послуги з розробки пакетів програмного забезпечення (Розвиток інформаційної системи «Муніципальний Реєстр», 2 черга. .Створення програмного модулю «Реєстр Дітей»). Шифр теми: ПМ РД ===== 1.3 Найменування установ розробника і замовника, банківські реквізити ===== |**ЗАМОВНИК** |**ВИКОНАВЕЦЬ** | |**Комунальне підприємство**\\ **«Головний інформаційно-обчислювальний центр»**\\ \\ ** ** |**Товариство з обмеженою відповідальністю «ЕФ ДI АЙ КАМПАНI»** | |Місцезнаходження:\\ \\ 02192, м. Київ, вул. Космічна, 12 А\\ \\ Код ЄДРПОУ 04013755\\ \\ п/р № 35449173091290\\ ГУДКСУ в м. Києві\\ МФО 820019\\ \\ Тел.: (044) 238-80-05\\ \\ ** **|Місцезнаходження:\\ \\ 01032, м. Київ, бульвар Тараса Шевченка, 62\\ \\ Код ЄДРПОУ 37770359\\ \\ п/р № 2600825709\\ \\ в ПАТ «ПУМБ» в м. Києві\\ \\ МФО 334851\\ \\ Тел.: (044) 337-03-91\\ \\ ** **| |Директор КП ГІОЦ\\ \\ В. М. Козубський |Директор ТОВ «ЕФ ДІ АЙ КАМПАНІ»\\ \\ М. В. Козлов | ===== 1.4 Планові терміни початку та закінчення надання послуг   ===== Терміни виконання робіт у 2018 році визначені Договором про надання послуг від 10 вересня 2018 року № 4458 Послуги з розробки пакетів програмного забезпечення (Розвиток інформаційної системи «Муніципальний Реєстр», 2 черга. Створення програмного модулю «Реєстр Дітей») та Календарним планом надання послуг, що є Додатком №1 до Договору від 10 вересня 2018 року № 4458. ===== 1.5 Перелік документів, на підставі яких надаються послуги ===== Перелік документів, що є підставою для створення ПМ РД: -         Договір про надання послуг від 10 вересня 2018 року № 4458 Послуги з розробки пакетів програмного забезпечення (Розвиток інформаційної системи «Муніципальний Реєстр», 2 черга. Створення програмного модулю «Реєстр Дітей»). -         Календарний план надання послуг, що є Додатком №1 до Договору від 10 вересня 2018 року № 4458. -         Закон України «Про місцеве самоврядування в Україні» (п.22 ч.1 ст. 26); -         Закон України «Про Основні засади розвитку інформаційного суспільства в Україні на 2007 - 2015 роки»; -         Закон України «Про захист інформації в інформаційно-телекомунікаційних системах»; -         Указ Президента України від 27 вересня 1999 року N 1229/99 «Про Положення про технічний захист інформації в Україні»; -         Розпорядження Кабінету Міністрів України та від 15 травня 2013 року N 386-р «Про схвалення Стратегії розвитку інформаційного суспільства в Україні»; -         Розпорядження Кабінету Міністрів України від 20 вересня 2017 року № 649-р «Про схвалення Концепції розвитку електронного урядування в Україні»; -         Рішення Київської міської ради від 29 жовтня 2009 року N 520/2589 «Про порядок розроблення, затвердження та виконання міських цільових програм у місті Києві». -         Рішенням Київської міської ради №654/1518 від 02 липня 2015 року Комплексна міська цільова програма «Електронна столиця» на 2015-2018 роки (зі змінами та доповненнями). -         Розпорядження виконавчого органу Київської міської ради (Київської міської державної адміністрації) від 11 квітня 2018 року № 614 Перелік заходів з подальшого впровадження  інформаційно-комунікаційних технологій у сфері життєдіяльності міста Києва на 2018 рік (зі змінами та доповненнями). -         Розпорядження виконавчого органу Київської міської ради (Київської міської державної адміністрації) від 03 липня 2018 року № 1135 Про затвердження Положення про забезпечення захисту інформації в інформаційно-телекомунікаційних системах структурних підрозділів виконавчого органу Київської міської ради (Київської міської державної адміністрації), районних в місті Києві державних адміністрацій, підприємств, установ та організацій, що належать до комунальної власності територіальної громади міста Києва або передані до сфери управління виконавчого органу Київської міської ради (Київської міської державної адміністрації). -         Наказ КП ГІОЦ від 11 вересня 2018 року № 93 Інструкція з надання доступу до  інформаційних ресурсів інформаційно-телекомунікаційних систем комунального підприємства «Головний інформаційно-обчислювальний центр». Створення ПМ РД повинно відповідати вимогам чинних нормативно-правових документів, а саме: -         Закону України «Про інформацію»; -         Закону України «Про електронні документи та електронний документообіг»; -         Закону України «Про адміністративні послуги»; -         Постанови Кабінету Міністрів України від 30.01.2013р. № 57 «Про затвердження Порядку ведення Реєстру адміністративних послуг»; -         Закону України «Про звернення громадян»; -         Закону України «Про доступ до публічної інформації»; -         Закону України «Про захист інформації в інформаційно-телекомунікаційних системах»; -         Закону України «Про електронний цифровий підпис»; -         Закону України «Про захист персональних даних» від 2010, № 34, ст. 481; -         Постанови Кабінету Міністрів України від 04.02.1998 № 121 «Про затвердження переліку обов'язкових етапів робіт під час проектування, впровадження та експлуатації засобів інформатизації»; -         Постанови Кабінету Міністрів України від 10.09.2003 № 1433 «Про затвердження Порядку використання комп'ютерних програм в органах виконавчої влади»; -         Постанови Кабінету Міністрів України від 28.10.2004 № 1452 «Про затвердження Порядку застосування електронного цифрового підпису органами державної влади, органами місцевого самоврядування, підприємствами, установами та організаціями державної форми власності»; -         Постанови Кабінету Міністрів України від 29.03.2006 № 373 «Про затвердження Правил забезпечення захисту інформації в інформаційних, телекомунікаційних та інформаційно-телекомунікаційних системах»; -         Постанови Кабінету Міністрів України від 13.09.2017 № 684 «Про затвердження Порядку ведення обліку дітей шкільного віку та учнів»; -         НД ТЗІ 1.4-001-2000. Типове положення про службу захисту інформації в автоматизованій системі; -         НД ТЗІ 2.5-004-99. Критерії оцінки захищеності інформації у комп’ютерних системах від несанкціонованого доступу; -         НД ТЗІ 2.5-005-99. Класифікація автоматизованих систем і стандартні функціональні профілі захищеності оброблюваної інформації від несанкціонованого доступу (зі Зміною №1, затвердженою наказом Адміністрації Держспецзв’язку від 15.10.2008 № 172); -         НД ТЗІ 3.7-001-99. Методичні вказівки щодо розробки технічного завдання на створення комплексної системи захисту інформації в автоматизованій системі; -         ДК 010-98 «Державний класифікатор управлінської документації»; -         ДСТУ ISO/IEC 12207:2016 «Інженерія систем і програмного забезпечення. Процеси життєвого циклу програмного забезпечення»; -         ДСТУ 3396.0-96 Захист інформації. Технічний захист інформації. Основні положення; -         ДСТУ 3396.2-97 Захист інформації. Технічний захист інформації. Терміни та визначення; -         ДСТУ 2873-94 Системи оброблення інформації. Програмування. Терміни та визначення; -         ДСТУ 2941-94 Системи оброблення інформації. Розроблення систем. Терміни та визначення; -         ДСТУ ISO/IEC 2382-4:2005 Інформаційні технології. Словник термінів. Частина 4. Організація даних; -         ДСТУ ISO/IEC 2382-17:2005 Інформаційні технології. Словник термінів. Частина 17. Бази даних; -         ДСТУ ISO/IEC 2382-9:2005 Інформаційні технології. Словник термінів. Частина 9: Обмін даними; -         ДСТУ 4302:2004 Інформаційні технології. Настанови щодо документування комп`ютерних програм (ISO/IEC 6592:2000, MOD); -         ДСТУ 4145:2002 Інформаційні технології. Криптографічний захист інформації. Електронний цифровий підпис, що ґрунтується на еліптичних кривих; -         ГОСТ 19.001-77. Єдина система програмної документації. Загальні положення; -         ГОСТ 19.101-77 (СТ СЗВ 1626-79). Єдина система програмної документації. Види програм і програмних документів; -         ГОСТ 19.102-77. Єдина система програмної документації. Стадії розробки; -         ГОСТ 19.103-77. Єдина система програмної документації. Позначення програм програмних документів; -         ГОСТ 19.104-78 (СТ СЗВ 2088-80). Єдина система програмної документації. Основні написи; -         ГОСТ 19.105-78 (СТ СЗВ 2088-80). Єдина система програмної документації. Загальні вимоги до текстових програмних документів; -         ГОСТ 19.201-78 (СТ СЗВ 1627-79). Єдина система програмної документації. Технічне завдання. Вимоги до змісту та оформлення; -         ГОСТ 19.202-78 (СТ СЗВ 2090-80). Єдина система програмної документації. Специфікація. Вимоги до змісту та оформлення; -         ГОСТ 19.301-79 (СТ СЗВ 3747-82). Єдина система програмної документації. Програма та методика випробувань. Вимоги до змісту та оформлення; -         ГОСТ 19.507-79 (СТ СЗВ 2091-80). Єдина система програмної документації. Відомість експлуатаційних документів; -         ГОСТ 19.701-90 (ИСО 5807-85). Єдина система програмної документації. Схеми алгоритмів, програм, даних та систем; -         ГОСТ 19781-90 Програмне забезпечення систем обробки інформації. Терміни та визначення; -         ГОСТ 34.003-90. Інформаційна технологія. Комплекс стандартів на автоматизовані системи. Автоматизовані системи. Терміни та визначення; -         ГОСТ 34.201-89. Інформаційна технологія. Комплекс стандартів на автоматизовані системи. Види, комплектність і позначення документів при створенні автоматизованих систем; -         ГОСТ 34.601-90. Інформаційна технологія. Комплекс стандартів на автоматизовані системи. Автоматизовані системи. Стадії створення; -         ГОСТ 34.602-89. Інформаційна технологія. Комплекс стандартів на автоматизовані системи. Технічне завдання на створення автоматизованої системи; -         ГОСТ 34.603-92. Інформаційна технологія. Види випробувань автоматизованих систем; -         РД 50-34.698-90. Методичні вказівки. Інформаційна технологія. Комплекс стандартів і керівних документів на автоматизовані системи. Автоматизовані системи. Вимоги до змісту документів; -         РД 50-682-89. Методичні вказівки. Інформаційна технологія. Комплекс стандартів і керівних документів на автоматизовані системи. Загальні положення. ===== 1.6 Відомості про джерела і порядок фінансування робіт ===== Робота фінансується за рахунок коштів бюджету міста Києва, які виділяються в рамках заходу 1.16 Напрямів діяльності та заходів Комплексної міської цільової програми “Електронна столиця” на 2015-2018 роки, затвердженої Рішенням Київської міської ради №654/1518 від 02 липня 2015 року (зі змінами і доповненнями), та пункту 2 Переліку заходів з подальшого впровадження  інформаційно-комунікаційних технологій у сфери життєдіяльності міста Києва на 2018 рік, затвердженому Розпорядженням виконавчого органу Київської міської ради (Київської міської державної адміністрації) № 614 від 11 квітня 2018 року (зі змінами і доповненнями). ===== 1.7 Порядок оформлення і пред’явлення замовнику результатів наданих послуг ===== Порядок оформлення та приймання послуг з розвитку ІС МР другої черги здійснюється згідно з відповідними положеннями Договору про надання послуг від\\ 10 вересня 2018 року № 4458 Послуги з розробки пакетів програмного забезпечення (Розвиток інформаційної системи «Муніципальний Реєстр», 2 черга. Створення програмного модуля «Реєстр дітей»). ====== 2.      ПРИЗНАЧЕННЯ ТА ЦІЛІ СТВОРЕННЯ СИСТЕМИ ====== **2** ** ** ===== 2.1 Призначення ===== Інформаційна система «Муніципальний реєстр» (далі – ІС МР або Система) – це автоматизована система управління Реєстром громадян міста Києва, а також реєстром операцій їх активності в інформаційних системах міста Києва. Призначення ІС МР – збір та зберігання даних для створення реєстру громадян м. Києва (Муніципального реєстру). Призначення розробки програмного модулю «Реєстру дітей» інформаційної системи «Муніципальний реєстр» (далі – ПМ РД) – збір та зберігання даних для створення реєстру дітей, охоплених навчанням в закладах освіти міста Києва з урахуванням їх місця реєстрації та обміну даними про них з метою якісного  функціонування електронних сервісів міста. ===== 2.2 Мета розвитку ===== Метою модернізації ІС МР є розширення функціональності Системи, а саме: розробка ПМ РД для реалізації інформаційної технології обліку: -       дітей шкільного віку та учнів, що ведеться з метою забезпечення здобуття ними загальної середньої освіти у закладах освіти (далі – ЗО) відповідно до Постанови Кабінету Міністрів України від 13 вересня 2017 року № 684; -       дітей, які здобувають освіту у закладах  дошкільної освіти територіальної громади міста Києва (далі – ЗДО). ===== 2.3 Ціль ===== В рамках розробки будуть створені сервіси: -        Компонент ЗО, який забезпечить: 1)       облік, управління та надання достовірних даних стосовно ЗО територіальної громади міста Києва; 2)       облік та управління даними про співробітників ЗО міста Києва; 3)       облік та управління даними про дітей шкільного віку та учнів, які навчаються у ЗО територіальної громади міста Києва. -        Компонент ЗДО, який забезпечить: 1)     облік та управління даними про дітей, які навчаються у ЗДО територіальної громади міста Києва; 2)     надання оперативних і достовірних відомостей щодо дітей дошкільного віку, які навчаються у ЗДО територіальної громади міста Києва. -        Компонент РУО, який забезпечить: 1)     облік, управління, надання оперативних та достовірних даних про дітей, які навчаються у ЗДО територіальної громади міста Києва на районному рівні; 2)     облік, управління, надання оперативних та достовірних даних стосовно ЗО на районному рівні; 3)     облік, управління, надання оперативних та достовірних даних про співробітників ЗО на районному рівні; 4)     облік, управління, надання оперативних та достовірних даних про дітей шкільного віку та учнів, які навчаються у ЗО на районному рівні; -        Компонент ДОН, який забезпечить: 1)     облік та управління даними про дітей, які навчаються у ЗДО територіальної громади міста Києва на міському рівні; 2)     облік, управління та надання достовірних даних стосовно ЗО на міському рівні; 3)     облік та управління даними про співробітників ЗО на міському рівні; 4)     облік та управління даними про дітей шкільного віку та учнів, які навчаються у ЗО на міському рівні; -        Програмна підсистема обміну даними з РТГК забезпечить обмін даними ПМ РД з РТГК (описана в ТЗ на доопрацювання ІС МР); -       Програмна підсистема обміну даними з Електронною чергою забезпечить обмін даними ПМ РД з Електронною чергою з метою отримання даних про дітей, які здобувають освіту у закладах  дошкільної освіти територіальної громади міста Києва;   -       Підсистема адміністрування забезпечить можливостями налаштування довідників та налаштування рольової моделі користувачів. \\ ====== 3.      ХАРАКТЕРИСТИКА ОБ’ЕКТУ АВТОМАТИЗАЦІЇ ====== **3** ** ** ===== 3.1 Відомості про об’єкт автоматизації ===== Об’єктами автоматизації ІС МР є розвиток / модернізація бізнес-процесів єдиного, унікального та достовірного реєстру жителів міста Києва (Муніципального реєстру, далі – МР), а саме: -        Створення в МР облікового запису «Житель ОС» шляхом реалізації електронної взаємодії ПМ РД та МР та формування універсальної освітньої складової МР ID (МР ID ОС). -        Створення ПМ РД забезпечить автоматизацію робочих процесів закладів освіти міста Києва. ===== 3.2 Відомості про умови експлуатації об’єкта автоматизації і характеристиках навколишнього середовища ===== Приміщення для розташування обладнання ПМ РД ІС МР повинно(ні) мати обмежений доступ сторонніх осіб, природне освітлення та забезпечуватися: -       штучним та аварійним освітленням; -       природною вентиляцією; -       основним та резервним джерелами живлення електрообладнання; -       стаціонарним телефонним зв’язком; -       захисним заземленням та засобами захисту апаратури від розрядів блискавки; -       первинними засобами пожежогасіння та пожежною сигналізацією. Забезпечення у приміщеннях виконання кліматичних та інших умов для експлуатації роботи обладнання не є предметом цієї роботи і покладається на Замовника. У приміщеннях, в яких встановлено серверне та телекомунікаційне обладнання, відповідно до ГОСТ 15150-69 повинні бути штучно створені кліматичні умови з параметрами: -        температура навколишнього повітря: +20±5 С°; -        відносна вологість повітря: 60±15 %; -        атмосферний тиск: 630-800 мм. рт. ст. Підготовка до експлуатації ПМ РД повинна передбачати заходи та процедури по експлуатації, які узгоджуються з вимогами документа «Про затвердження Вимог щодо безпеки та захисту здоров’я працівників під час роботи з екранними пристроями», затверджених наказом Міністерства соціальної політики України від 14.02.2018 № 207. Експлуатація ПМ РД повинна виконуватися за наступними принципами: -       технічне супроводження виконується обслуговуючим персоналом Замовника згідно з вимогами виробника програмного та технічного забезпечення, які надаються Виконавцем у вигляді інструкцій з експлуатації; -       технічне обслуговування виконується персоналом Замовника відповідно до вимог, які надаються Виконавцем у вигляді відповідних інструкцій, якщо інше не передбачено умовами договору. Забезпечення у приміщеннях виконання кліматичних умов для експлуатації роботи обладнання не є предметом цієї роботи і покладається на Замовника. ====== 4.      ФУНКЦІОНАЛЬНІ ВИМОГИ ЩОДО РОЗВИТКУ ІС МР ====== **4** ** ** ===== 4.1 Загальні вимоги ===== Розвиток ІС МР повинен базуватись на використанні підходів та методів модернізації з використанням сучасних сервісно-орієнтованих технологій. При доопрацюванні будь-яких базових компонентів або створенні нових будуть застосовані сучасні методи та технології, що забезпечуватимуть якісну реалізацію функціональності програмних модулів, компонентів ІС МР. Технологічна гнучкість, надійність роботи, скорочення часу та сукупних витрат на розробку та підтримку будуть досягатись за рахунок реалізації принципів стандартизації та уніфікації, а саме: -       уніфікованих правил структурної побудови та/або модернізації та організації прикладних програмних компонент, їх взаємодії між собою; -       стандартизації вимог до побудови та/або модернізації бази даних, формування єдиних вимог до класифікації об’єктів та їх атрибутивного складу; -       уніфікації правил побудови та/або модернізації інформаційної взаємодії з іншими інформаційними системами. В межах надання послуг з розвитку ІС МР будуть здійснені наступні заходи*: -       створення ПМ РД; -       розробка електронної взаємодії ПМ РД та МР; -       розробка електронної взаємодії ПМ РД та Електронної черги. *Примітка! Взаємодія з вищеназваними системами передбачається за умов технічної готовності, про що Замовник в робочому порядку надає відповідну інформацію Виконавцю. ===== 4.2 Загальна логічна схема рішення ===== У межах розробки ПМ РД повинні бути створені наступні компоненти: -       компонент ЗО, що складається з програмних підсистем: 1)     Паспорт ЗО; 2)     Співробітник ЗО; 3)     Учень ЗО; -       компонент ЗДО, що складається з програмної підсистеми: 1)     Вихованець ЗДО; -       компонент РУО, що забезпечує облік ЗО та ЗДО на районному рівні; -       компонент ДОН, що забезпечує облік ЗО та ЗДО на міському рівні; -       програмна підсистема обміну даними з Електронної черги; -       підсистема адміністрування. \\ \\ Рисунок 1. Загальна логічна схема рішення **__АРМ  Дитячого садка__** – веб-інтерфейс презентаційного рівня для роботи з блоком вихованців ЗДО. Функціонування забезпечується Компонентом Заклад дошкільної освіти. **__АРМ Закладу освіти__** – веб-інтерфейс презентаційного рівня для роботи з блоком закладів, співробітників та учнів ЗО. Функціонування забезпечується Компонентом Заклад освіти. **__АРМ Районного управління__** – веб-інтерфейс презентаційного рівня для роботи з блоком співробітників РУО. Функціонування забезпечується Компонентом Районне управління освіти. **__АРМ Департаменту освіти та науки__** – веб-інтерфейс презентаційного рівня для роботи з блоком співробітників ДОН. Функціонування забезпечується Компонентом Департамент освіти та науки. **__АРМ Адміністратора__** – веб-інтерфейс адміністраторів ПМ РД. Функціонування забезпечується Підсистемою адміністрування. **__Електронна черга__** – електронний запис дітей до дошкільних навчальних закладів комунальної власності територіальної громади міста Києва, запровадженого згідно з розпорядженням виконавчого органу Київської міської ради (Київської міської державної адміністрації) від 23 травня 2013 року № 760 «Про запровадження електронного запису дітей до дошкільних навчальних закладів комунальної власності територіальної громади міста Києва». Взаємодія забезпечується Програмним компонентом обміну даними з Електронною чергою. **__Компонент Заклад освіти__** – забезпечує функціонування ПМ у рамках операцій пошуку, створення, перегляду, редагування, видалення та збереження даних про заклади освіти всіх типів, учнів, співробітників. Забезпечує функціонування АРМ Заклад освіти. **__Компонент Дошкільний навчальний заклад__**  – забезпечує функціонування ПМ в рамках операцій пошуку, створення, перегляду, редагування та збереження даних про вихованців дошкільних навчальних закладів. Забезпечує функціонування АРМ Дитячого садка. Компонент отримує дані по вихованцям ЗДО засобами Програмної підсистеми обміну даними з Електронною чергою. **__Компонент Районне управління освіти__** – забезпечує функціонування ПМ в рамках операцій пошуку та перегляду даних про заклади освіти, учнів, співробітників, вихованців, ЗДО на рівні району. Забезпечує функціонування АРМ Районного управлінню освіти. **__Компонент Департаменту освіти та науки__** – забезпечує функціонування ПМ  в рамках операцій пошуку та перегляду даних про заклади освіти всіх форм власності, учнів, співробітників, вихованців на рівні міста. Забезпечує функціонування АРМ Департаменту освіти та науки. **__Програмний компонент обміну даними з Електронною чергою__** – це веб-сервіс, який представляє собою набір програмних інтерфейсів та забезпечує отримання даних по вихованцям ЗДО з Електронної черги. Взаємодіє з Компонентом Дошкільний навчальний заклад. **__Підсистема адміністрування__** – забезпечує управління користувачами та довідниками системи. Забезпечую функціонування АРМ Адміністратора. **__Сервіс профілю МР__** – це веб-сервіс, який представляє собою набір програмних інтерфейсів та забезпечує управління записами профілів Користувачів в Муніципальному реєстрі. \\ Рисунок 2. Схема відношень між сутностями Муніципального реєстру «Користувач ОКК», «Житель СК», «Житель РТГК», «Житель ОС» ===== 4.3 Вимоги до реалізації компонента ЗО ===== Схему відношень між сутностями компонента показано на Рисунок 3. Схема відношень між сутностями компонента ЗО. \\ Рисунок 3. Схема відношень між сутностями компонента ЗО **4.1       ** ** ** **4.2       ** ** ** **4.3       ** ** ** ===== 4.3.1        Вимоги до реалізації Паспорт ЗО ===== Паспорт ЗО – це основна інформація про заклад освіти, що забезпечує  реалізацію права громадян на здобуття загальної середньої освіти на різних її рівнях. Кожному закладу відповідає тільки один паспорт. Якщо заклад не працює, то паспорт ЗО повинен бути в неактивному стані. Структуру сутності Паспорт ЗО наведено на Рисунок 4. При необхідності в модель даних «Паспорт ЗО» можуть бути внесені уточнення на етапі розробки. \\ Рисунок 4. Структура сутності Паспорт ЗО \\ Атрибути моделі даних Паспорт ЗО наведені в **Таблиця 1. Атрибути моделі даних Паспорт ЗО**. Таблиця 1. Атрибути моделі даних Паспорт ЗО ^**Назва атрибуту** ^**Тип даних**^**Обов’язковий /**\\ \\ **необов’язковий**^**Коментарі** ^ |**Основні дані** | | | | |Повна назва закладу |Текстовий |Обов’язковий |\\ | |Коротка назва закладу |Текстовий |Обов’язковий |\\ | |Номер закладу освіти |Число |Необов’язковий |\\ | |Код ЄДРПОУ |Текст |Обов’язковий |\\ | |Тип закладу |Довідник |Обов’язковий |\\ | |Профіль навчання |Довідник |Обов’язковий |\\ | |Електронна пошта |Текстовий |Обов’язковий |\\ | |Сайт Інтернет |Текстовий |Необов’язковий |\\ | |Телефон |Числовий |Обов’язковий |\\ | |ПІБ директора |Текст |Обов’язковий |\\ | |Форма власності |Довідник |Обов’язковий |\\ | |Фото навчального закладу |Файл |Необов’язковий |\\ | |**Адресні дані** | | | | |Населений пункт |Текстовий |Обов’язковий |\\ | |Район |Текстовий |Обов’язковий |\\ | |Мікрорайон |Текстовий |Необов’язковий |\\ | |Вулиця |Текстовий |Обов’язковий |\\ | |Будинок |Текстовий |Обов’язковий |\\ | |Літера будинку |Текстовий |Необов’язковий |\\ | |Квартира |Текстовий |Необов’язковий |\\ | |**Навчальні підрозділи (класи)** | | | | |Назва класу |Текстовий |Обов’язковий |Складається з літери та цифри. Приклад 1А| |Тип класу |Довідник |Обов’язковий |\\ | |Навчальний рік |Довідник |Обов’язковий |\\ | |Паралель |Довідник |Обов’язковий |\\ | |Керівник |Текстовий |Обов’язковий |Співробітник | |Мова навчання |Довідник |Обов’язковий |Довідник Мови | |Нормативна кількість учнів |Число |Обов’язковий |\\ | |**Групи** | | | | |Тип групи |Довідник |Обов’язковий |\\ | |Назва групи |Текстовий |Обов’язковий |\\ | |Навчальний рік |Довідник |Обов’язковий |\\ | |Нормативна кількість дітей |Число |Обов’язковий |\\ | |Оплата за кошти батьків |Логічний |Обов’язковий |Так/Ні | |**Ліцензування та аудит** | | | | |Дата державної реєстрації закладу освіти |Дата |Обов’язковий |\\ | |Дата затвердження статуту |Дата |Обов’язковий |\\ | |Засновники закладу освіти |Текст |Обов’язковий |\\ | |Проектна потужність закладу освіти |Число |Обов’язковий |\\ | |Дата проведення останнього інституційного аудиту |Дата |Обов’язковий |\\ | |Дата проведення останньої громадської акредитації |Дата |Обов’язковий |\\ | |Дата проведення Державною службою якості освіти останнього позапланового заходу державного нагляду (контролю) (якщо був)|Дата |Обов’язковий |\\ | |Дата затвердження чинної освітньої програми (крім типової) |Дата |Обов’язковий |\\ | |Чисельність педагогічних працівників, які мають чинний сертифікат про успішне проходження процедури сертифікації |Число |Обов’язковий |\\ | |**Комп’ютерне та програмне забезпечення** | | | | |Загальна кількість комп’ютерів |Число |Обов’язковий |\\ | |Кількість комп’ютерів підключених до Інтернету |Число |Обов’язковий |\\ | |Кількість комп’ютерів, що не працюють |Число |Обов’язковий |\\ | |Кількість комп’ютерів, термін придбання яких понад 5 років |Число |Обов’язковий |\\ | |Кількість комп’ютерів, що використовуються в управлінсько-господарській діяльності |Число |Обов’язковий |\\ | |Кількість комп’ютерів, що використовуються для ведення бібліотечного фонду |Число |Обов’язковий |\\ | |Наявність локальної мережі закладу |Логічний |Обов’язковий |Так/Ні | |Підключення до Інтернету |Логічний |Обов’язковий |Так/Ні | |Провайдер Інтернет |Текстовий |Обов’язковий |\\ | |Швидкість Інтернету Wireless |Довідник |Обов’язковий |\\ | |Швидкість Інтернету Cable |Довідник |Обов’язковий |\\ | |Балансова вартість всього комп’ютерного обладнання |Число |Обов’язковий |\\ | |**Оснащення ЗО** | | | | |Теплолічильник |Логічний |Обов’язковий |Так/Ні | |Водолічильник |Логічний |Обов’язковий |Так/Ні | |Газолічильник |Логічний |Обов’язковий |Так/Ні | |Водопровід |Логічний |Обов’язковий |Так/Ні | |Басейн |Логічний |Обов’язковий |Так/Ні | |Спортивний зал |Логічний |Обов’язковий |Так/Ні | |Спортивний майданчик |Логічний |Обов’язковий |Так/Ні | |Актовий зал |Логічний |Обов’язковий |Так/Ні | |Медичний кабінет |Логічний |Обов’язковий |Так/Ні | |Бібліотека |Логічний |Обов’язковий |Так/Ні | |Читальний зал  |Логічний |Обов’язковий |Так/Ні | |Кількість місць в їдальні |Число |Обов’язковий |\\ | |Кількість навчальних кабінетів |Число |Обов’язковий |\\ | |Кількість місць в їдальні |Число |Обов’язковий |\\ | |Кількість  джерел питної води |Число |Обов’язковий |\\ | |Кількість туалетів |Число |Обов’язковий |\\ | |Кількість туалетів для дітей з інвалідністю |Число |Обов’язковий |\\ | |Кількість корекційних кабінетів |Число |Обов’язковий |\\ | |Кількість пандусів |Число |Обов’язковий |\\ | |Кількість ліфтів |Число |Обов’язковий |\\ | |Загальна площа всіх приміщень |Число |Обов’язковий |\\ | |Загальна площа приміщень зданих в оренду |Число |Обов’язковий |\\ | |Загальна площа орендованих приміщень |Число |Обов’язковий |\\ | \\ Формат введення даних \\ \\ \\ \\                                                                                                                                                                                                         \\ ===== 4.3.2    Вимоги до реалізації блоку Учень ===== Структура моделі даних Учень наведено на Рисунок 5. Структура моделі даних Учень. \\ Рисунок 5. Структура моделі даних Учень Атрибути моделі даних Учень наведені в **Таблиця 2. Атрибути моделі даних Учень**. \\ Таблиця 2. Атрибути моделі даних Учень ^**Назва атрибуту** ^**Тип даних** ^**Обов’язковий /**\\ \\ **необов’язковий**^**Коментарі** ^ |ID |** ** |Обов’язковий |ID = МР ID (ID.ОС) (див. Рисунок 2. Схема відношень між сутностями Муніципального реєстру «Користувач ОКК», «Житель СК», «Житель РТГК», «Житель ОС»\\ \\ Формується автоматично засобами БД. Унікальний ідентифікатор запису. | |** Особисті дані профіля Учня** | | | | |УНЗР |Текстовий |Необов’язковий |\\ | |Прізвище |Текстовий |Обов’язковий |\\ | |Ім’я |Текстовий |Обов’язковий |\\ | |По батькові |Текстовий |Необов’язковий |\\ | |Дата народження |Дата |Обов’язковий |\\ | |Стать |Довідник |Обов’язковий |\\ | |Громадянство |Довідник |Необов’язковий |\\ | |Соціальна категорія |Довідник |Необов’язковий |\\ | |Нозологія |Довідник |Необов’язковий |\\ | |Постановка на облік |Довідник |Необов’язковий |\\ | |**Дані документів** | | | | |Тип документа |Довідник |Обов’язковий |\\ | |Серія |Текстовий |Необов’язковий |\\ | |Номер |Текстовий |Обов’язковий |\\ | |Дата видачі |Дата |Обов’язковий |\\ | |Ким виданий |Текстовий |Обов’язковий |\\ | |**Адресні дані профіля Учня** | | | | |Країна |Текстовий |Обов’язковий |\\ | |Область |Текстовий |Необов’язковий |\\ | |Район |Текстовий |Необов’язковий |\\ | |Населений пункт |Текстовий |Необов’язковий |\\ | |Адміністративний район |Текстовий |Необов’язковий |\\ | |Вулиця |Текстовий |Необов’язковий |\\ | |Будинок |Текстовий |Необов’язковий |\\ | |Літера будинку |Текстовий |Необов’язковий |\\ | |Квартира |Текстовий |Необов’язковий |\\ | |Дата реєстрації |Дата |Обов’язковий |\\ | |**Дані про батьків** | | | | |Родинний статус |Довідник |Обов’язковий |Батько, мати, опікун | |РНОКПП |Текстовий |Обов’язковий |\\ | |Прізвище |Текстовий |Обов’язковий |\\ | |Ім’я |Текстовий |Обов’язковий |\\ | |По батькові |Текстовий |Необов’язковий |\\ | |Дата народження |Дата |Необов’язковий |\\ | |Стать |Довідник |Обов’язковий |\\ | |Документ |Аналогічно як по дитині| | | |Адресні дані |Аналогічно як по дитині| | | |Місце роботи |Текстовий |Необов’язковий |\\ | |Контактний телефон |Числовий |Необов’язковий |\\ | |Контактний е-мейл |Текстовий |Необов’язковий |\\ | |**Дані про навчання профіля Учня**| | | | |Клас навчання |Сутність Клас |Обов’язковий |клас ЗО | |Табельний номер |Текстовий |Необов’язковий |за алфавітом | |Форма навчання |Довідник |Обов’язковий |\\ | |Мови вивчення |Довідник |Обов’язковий |Іноземні мови\\ за наявністю | |Поглиблене вивчення предметів |Довідник |Необов’язковий |за наявністю | |Дата зарахування до 1 класу |Дата |Обов’язковий |\\ | |Дата зарахування до класу |Дата |Обов’язковий |Поточний заклад освіти навчання | |Дата вибуття з класу |Дата |Необов’язковий |Поточний заклад  освіти | ===== 4.3.3    Вимоги до реалізації блоку Співробітник ЗО ===== Структура Моделі даних Співробітник наведено на Рисунок 6. Структура моделі даних Співробітник. \\ Рисунок 6. Структура моделі даних Співробітник За виникнення необхідності, в модель даних «Співробітник» можуть бути внесені уточнення на етапі розробки. Атрибути моделі даних «Співробітник» наведено в Таблиця 3. Атрибути моделі даних Співробітник. Таблиця 3. Атрибути моделі даних Співробітник ^**Назва атрибуту** ^**Тип даних**^**Обов’язковий /**\\ \\ **необов’язковий**^**Коментарі** ^ |**Особисті дані** **профіля Співробітника** | | | | |Код УНЗР |Текстовий |Необов’язковий |\\ | |РНОКПП |Текстовий |Обов’язковий |\\ | |Прізвище |Текстовий |Обов’язковий |\\ | |Ім’я |Текстовий |Обов’язковий |\\ | |По батькові |Текстовий |Необов’язковий |\\ | |Дата народження |Дата |Обов’язковий |\\ | |Стать |Довідник |Обов’язковий |\\ | |Громадянство |Довідник |Необов’язковий |\\ | |Пенсійний стан |Довідник |Обов’язковий |\\ | |**Дані документів** | | | | |Тип документа |Довідник |Обов’язковий |\\ | |Серія |Текстовий |Необов’язковий |\\ | |Номер |Числовий |Обов’язковий |\\ | |Дата видачі |Дата |Обов’язковий |\\ | |Ким виданий |Текстовий |Обов’язковий |\\ | |**Дані по реєстрації** **профіля Співробітника** | | | | |Країна |Текстовий |Обов’язковий |\\ | |Область |Текстовий |Необов’язковий |\\ | |Район |Текстовий |Необов’язковий |\\ | |Населений пункт |Текстовий |Необов’язковий |\\ | |Адміністративний район |Текстовий |Необов’язковий |\\ | |Вулиця |Текстовий |Обов’язковий |\\ | |Будинок |Текстовий |Обов’язковий |\\ | |Літера будинку |Текстовий |Необов’язковий |\\ | |Квартира |Текстовий |Необов’язковий |\\ | |**Військовий облік** | | | | |Номер військового квитка |Текстовий |Необов’язковий |\\ | |Дата видачі |Дата |Необов’язковий |\\ | |Ким виданий |Текстовий |Необов’язковий |\\ | |Місце перебування на обліку |Текстовий |Необов’язковий |\\ | |Учасник АТО |Логічний |Обов’язковий |Так/Ні | |Назва нагороди |Текстовий |Необов’язковий |\\ | |Дата отримання нагороди |Дата |Необов’язковий |\\ | |**Дані про освіту** | | | | |Навчальний заклад |Текстовий |Необов’язковий |Назва навчального закладу | |Форма навчання |Довідник |Необов’язковий |\\ | |Освітньо-кваліфікаційний рівень |Довідник |Необов’язковий |\\ | |Спеціальність |Текстовий |Необов’язковий |\\ | |Номер та серія диплому |Текстовий |Необов’язковий |\\ | |Дата видачі диплому |Дата |Необов’язковий |\\ | |Тип освіти |Довідник |Необов’язковий |\\ | |**Дані про роботу** **профіля Співробітника** | | | | |Поточний заклад |Сутність ЗО |Обов’язковий |** ** | |Дата працевлаштування |Дата |Обов’язковий |\\ | |Дата звільнення |Дата |Необов’язковий |\\ | |Посада |Довідник |Обов’язковий |\\ | |Характер працевлаштування |Довідник |Обов’язковий |\\ | |Мови викладання |Довідник |Обов’язковий |Довідник Мови | |Навчальний предмет |Довідник |Необов’язковий |обов’язковий\\ за наявністю | |Кількість годин навантаження по навчальному предмету|Число |Необов’язковий |обов’язковий\\ за наявністю\\ Навчального предмета| |Загальний стаж |Число |Обов’язковий |Роки, місяці | |Педагогічний стаж |Число |Обов’язковий |Роки, місяці | |Працює за спеціальністю |Логічний |Обов’язковий |Так/Ні | |Кваліфікаційна категорія |Довідник |Обов’язковий |\\ | |Педагогічне звання |Довідник |Необов’язковий |\\ | |Дата останньої атестації |Дата |Необов’язковий |\\ | |Дата підвищення кваліфікації |Дата |Необов’язковий |\\ | |Працює у спеціальних/інклюзивних класах |Логічний |Обов’язковий |\\ | ===== 4.4 Вимоги до реалізації компонента ЗДО ===== Схему відношень між сутностями компонента показано на Рисунок 7. Схема відношень між сутностями компонента ЗДО. \\ Рисунок 7. Схема відношень між сутностями компонента ЗДО **4.4       ** ** ** ===== 4.4.1        Вимоги до реалізації блоку Вихованець ЗДО ===== Модель даних Вихованець – це група параметрів, що безпосередньо стосується сутності Вихованець і утворюють логічну структуру. Структура моделі даних Вихованець наведено на  Рисунок 8. Структура моделі даних Вихованець . \\ Рисунок 8. Структура моделі даних Вихованець За виникнення необхідності, в модель даних Вихованець можуть бути внесені уточнення на етапі розробки. Атрибути моделі даних Вихованець наведено в Таблиця 4. Атрибути моделі даних Вихованець. Таблиця 4. Атрибути моделі даних Вихованець ^**Назва атрибуту** ^**Тип даних**^**Обов’язковий /**\\ \\ **необов’язковий**^**Коментарі** ^ |ID |** ** |Обов’язковий |ID = МР ID (ID.ОС) (див. Рисунок 2. Схема відношень між сутностями Муніципального реєстру «Користувач ОКК», «Житель СК», «Житель РТГК», «Житель ОС».\\ \\ Формується автоматично засобами БД. Унікальний ідентифікатор запису. | |**Особисті дані** **профіля** **Вихованця** | | | | |Код УНЗР |Текстовий |Необов’язковий |\\ | |Прізвище |Текстовий |Обов’язковий |\\ | |Ім’я |Текстовий |Обов’язковий |\\ | |По батькові |Текстовий |Необов’язковий |\\ | |Дата народження |Дата |Обов’язковий |\\ | |Стать |Довідник |Обов’язковий |\\ | |Громадянство |Довідник |Необов’язковий |\\ | |Адресні дані |Текстовий |Необов’язковий |\\ | |**Дані документів** | | | | |Тип документа |Довідник |Обов’язковий |\\ | |Серія |Текстовий |Необов’язковий |\\ | |Номер |Числовий |Обов’язковий |\\ | |Дата видачі |Дата |Обов’язковий |\\ | |**Дані про батьків** | | | | |Родинний статус |Довідник |Обов’язковий |Батько, мати | |ПІБ |Текстовий |Обов’язковий |\\ | |РНОКПП |Текстовий |Обов’язковий |\\ | |Контактний e-mail |Текстовий |Обов’язковий |\\ | |Контактний телефон |Текстовий |Обов’язковий |\\ | |**Дані про пільгу** | | | | |Назва пільги |Довідник |Необов’язковий |\\ | |Тип документа |Текстовий |Необов’язковий |\\ | |Серія |Текстовий |Необов’язковий |\\ | |Номер |Текстовий |Необов’язковий |\\ | |Дата видачі |Текстовий |Необов’язковий |\\ | |**Дані про навчання** | | | | |Дата зарахування |Дата |Обов’язковий |\\ | |Табельний номер |Числовий |Обов’язковий |\\ | |Дата направлення з РУО з |Дата |Необов’язковий |\\ | |Дата направлення з РУО по |Дата |Необов’язковий |\\ | |Медичний протокол |Текстовий |Необов’язковий |\\ | |Дата медичного протоколу |Дата |Необов’язковий |\\ | |Нозологія |Довідник |Необов’язковий |\\ | |**ЗДО** | | | | |Назва ЗДО |Текстовий |Обов’язковий |\\ | |Номер ЗДО |Числовий |Обов’язковий |\\ | |Спеціалізація |Довідник |Обов’язковий |\\ | |Тип власності |Довідник |Обов’язковий |\\ | |ПІБ Керівника |Текстовий |Обов’язковий |\\ | |Район |Довідник |Обов’язковий |\\ | |Адреса |Текстовий |Обов’язковий |\\ | |Контактний e-mail |Текстовий |Необов’язковий |\\ | |Контактний телефон |Дата |Обов’язковий |\\ | |Час роботи початок |Текстовий |Обов’язковий |\\ | |Час роботи кінець |Текстовий |Обов’язковий |\\ | |Загальний опис |Текстовий |Обов’язковий |\\ | |**Група** | | | | |Назва групи |Текстовий |Обов’язковий |\\ | |Номер групи |Числовий |Обов’язковий |\\ | |Тип групи |Довідник |Обов’язковий |\\ | |Нозологія |Довідник |Обов’язковий |\\ | |ПІБ вихователя |Текстовий |Обов’язковий |\\ | |Батьківська плата за харчування |Числовий |Обов’язковий |\\ | |Кількість спальних місць (проектна потужність)|Числовий |Обов’язковий |\\ | |Кількість місць повного дня |Числовий |Необов’язковий |\\ | |Кількість місць короткоривалого перебування |Числовий |Необов’язковий |\\ | |Кількість місць інклюзивного перебування |Числовий |Необов’язковий |\\ | ===== 4.5 Вимоги до реалізації компонента «Районне управління освіти» ===== Облік ЗО та ЗДО на районному рівні. **4.5       ** ** ** ===== 4.5.1        Вимоги до блоку паспорт ЗО ===== Аналогічно вимогам до блока паспорт ЗО, але по всіх  ЗО району та тільки в режимі перегляду.  ===== 4.5.2     Вимоги до блока співробітник ЗО ===== Аналогічно вимогам до блока співробітник ЗО, але по всіх навчальних закладах району та тільки в режимі перегляду. ===== 4.5.3    Вимоги до блока учень ЗО ===== Аналогічно вимогам до блока учень ЗО, але по всіх навчальних закладах району та тільки в режимі перегляду.  ===== 4.5.4     Вимоги до блока вихованець ЗДО ===== Аналогічно вимогам до блока вихованець ЗДО, але по всіх навчальних закладах району та тільки в режимі перегляду. ===== 4.5.5    Вимоги до реалізації компонента ДОН ===== Облік ЗО та ЗДО на міському рівні.  ===== 4.5.6     Вимоги до блоку паспорт ЗО ===== Аналогічно вимогам до блока паспорт ЗО, але по всіх навчальним закладам міста в розрізі районів та тільки в режимі перегляду. ===== 4.5.7    Вимоги до блока співробітник ЗО ===== Аналогічно вимогам до блока співробітник ЗО, але по всіх навчальних закладах міста в розрізі районів та тільки в режимі перегляду.  ===== 4.5.8     Вимоги до блока учень ЗО ===== Аналогічно вимогам до блока учень ЗО, але по всіх навчальних закладах міста в розрізі районів та тільки в режимі перегляду. ===== 4.5.9    Вимоги до блока вихованець ЗДО ===== Аналогічно вимогам до блока вихованець ЗДО, але по ЗДО міста в розрізі районів та тільки в режимі перегляду.  ===== 4.6 Вимоги до реалізації програмної підсистеми обміну даними з Електронною чергою ===== Підставою до отримання даних з Електронної черги є зарахування вихованця до ЗДО або внесення змін в анкеті вихованця. Відбувається формування та надсилання в ПМ РД наступних даних вихованця ЗДО: -       особисті дані; -       адресні дані; -       дані про батьків; -       дані про пільгу; -       дані про навчання; -       дані про групу; -       дані про ЗДО. Отримання даних про місце реєстрації вихованців закладів дошкільної освіти  міста Києва реалізовано в Системі електронного запису до ЗДО і відбувається через програмний запит до РТГК та обробку наданої відповіді. З метою отримання вичерпних даних про вихованців ЗДО, реалізація електронної взаємодії ПМ РД з Електронною чергою передбачає забезпечення обміну даними між системами, включаючи отримання підтвердження місця реєстрації вихованця. \\ Рисунок 9. Бізнес-процес отримання даних з Електронної черги ===== 4.7 Вимоги до реалізації підсистеми адміністрування ===== Підсистема адміністрування повинна забезпечувати можливість: -     ведення рольової моделі для надати відповідних прав користувачам; -     організувати список користувачів з ієрархією прав доступу до реєстру з урахуванням рівня конфіденційності та забезпеченням регламенту доступу згідно цих прав до кожного функціонального блоку/компоненту програмного продукту; -     можливість закріплення кожного користувача за конкретним розрізом даних (в діапазоні або в ієрархічній групі кодів територій, видів діяльності, навчальних класів, навчальних років, тощо); -     формування списків об’єктів ПМ РД, довідників та класифікаторів, які користувач коригував протягом дня (як поточного, так і минулих) або за період. Реалізація рольової моделі повинна бути спрямована на спрощення процедури надання доступу користувачам до інформаційних ресурсів та функцій ПМ РД, за рахунок створення механізму групового надання повноважень користувачам, в залежності від організаційної структури та групи, до яких вони належать за своєю діяльністю. Механізм групового надання повноважень повинен надавати можливість користувачу з роллю Системний адміністратор здійснювати: -     створення групи (Департамент освіти, Районне управління освіти, Заклад освіти, Заклад дошкільної освіти); -     створення ролей, які обов’язково належать групі; -     визначення загальних повноважень для кожної ролі в групі; -     визначення переліку інформаційних ресурсів та функцій, що доступні для кожної ролі. **4.6       ** ** ** **4.7       ** ** ** ===== 4.7.1        Вимоги до рольової моделі ===== Роль – це набір прав, які має користувач ПМ РД. Роль визначає можливості користувача. Таблиця 5. Атрибути сутності Роль. ^**Назва атрибуту **^**Тип даних** ^**Опис атрибуту ** ^**Обов'язковий / не обов'язковий**^ |Назва ролі |Текстовий |Назва ролі унікальна для групи, якій належить. Кожна роль повинна бути додана до групи.  |Обов'язковий | |Статус ролі  |Текстовий |Можливі значення статусу: \\ \\ -     Активна\\ \\ -     Деактивована (всі користувачі даної ролі не мають доступу у систему). |Обов'язковий | |Група ролі  |Довідник |Рекомендовані значення атрибуту:\\ \\ -     Департамент освіти і науки, молоді та спорту\\ \\ -     Районні управління освіти\\ \\ -     Заклад загальної освіти\\ \\ -     Заклади дошкільної освіти|Обов'язковий | |Набір прав на дію |Список значень|Список можливих значень прав показано нижче.  |Обов'язковий | |Набір прав на ЗО |Список значень|Список можливих значень:\\ \\ -       всі\\ \\ -       не надано\\ \\ -       список\\ \\ На всі ЗО додатково можна накласти обмеження по районам міста. |Обов'язковий | |Набір прав на ЗДО |Список значень|Список можливих значень:\\ \\ -       всі\\ \\ -       не надано\\ \\ -       список\\ \\ На всі ЗДО додатково можна накласти обмеження по районам міста. |Обов'язковий | **Права користувача різних рівнів на виконання дій в ПМ РД.** Після того, як обліковий запис Користувача стає активним, він отримує доступ до відповідної компоненти ПМ РД з зазначенням переліку прав на керування, що зазначено при наданні ролі. З компонентами ПМ РД можна взаємодіяти наступним чином: __ЗДО:__ -       Перегляд та пошук ЗДО -       Друк паспорта ЗДО -       Експорт паспорта ЗДО __ЗО:__ -       Перегляд та пошук ЗО -       Створення ЗО -       Редагування ЗО -       Активація та деактивація ЗО -       Друк паспорту ЗО -       Експорт паспорту ЗО __Вихованці:__ -       Перегляд та пошук картки вихованця -       Активація та деактивація картки вихованця -       Друк  картки вихованця __Учні:__ -       Перегляд та пошук картки учня -       Створення картки учня -       Редагування картки учня -       Активація та деактивація картки учня -       Друк картки учня __Співробітники:__ -       Перегляд та пошук картки співробітника -       Створення картки співробітника -       Редагування картки співробітника -       Активація та деактивація картки співробітника -       Друк картки співробітника __Користувачі:__ -       Перегляд та пошук картки користувача -       Редагування картки користувача -       Активація та деактивація картки користувача __Ролі:__ -       Перегляд та пошук картки ролі -       Створення картки ролі -       Редагування картки ролі -       Активація та деактивація картки ролі __Довідники:__ -        Перегляд довідника -        Додання запису у довідник -        Редагування запису у довіднику -        Активація та деактивація запису довідника.   **Система повинна мати можливість створити ролі та надавати відповідним користувачам права з наступними повноваженнями:** -       Системний адміністратор  -       Керівник відділу ЗЗСО (ДОН) -       Керівник відділу ЗДО (ДОН)  -       Адміністратор ДОН           -       Керівник РУО                 -       Керівник відділу ЗО (РУО)   -       Керівник відділу ЗДО (РУО)  -       Адміністратор РУО           -       Керівник ЗО                 -       Фахівець ЗО                 -       Адміністратор ЗО            -       Керівник ЗДО                -       Фахівець ЗДО                -       Адміністратор ЗДО. \\ Нижче на Рисунку 10 наведено у графічному вигляді рольову модель ПМ РД. \\ Рисунок 10. Рольова модель системи ===== 4.7.2    Вимоги до функції «Перегляд нових Користувачів» ===== Передбачається, що після активації форми «Заявки на реєстрацію користувачів», ПМ РД (Адміністрування), повинен відображати всіх користувачів із статусом «Новий». Також передбачається, що по кожному Користувачу буде відображатись наступна інформація: -     Ім'я -     Прізвище -     По батькові -     Роль -     Територія дії -     Права на ЗО -     Права на ЗДО. При роботі з картками користувачів, необхідно передбачити можливість виконання стандартних дій: -      Редагування -      Перегляд. \\ \\ \\ \\ Атрибути Користувача вказані в **Таблиця 6. Атрибути Користувача** Таблиця 6. Атрибути Користувача ^**Назва атрибуту**^**Тип даних** ^**Обов’язковий / необов’язковий**^**Опис** ^ |ID користувача |Числовий |Обов’язковий | | |Прізвище |Текстовий |Обов’язковий |Прізвище Користувача. Отримується з Модуля авторизації при реєстрації Користувача. | |Ім’я |Текстовий |Обов’язковий |Ім'я Користувача. Отримується з Модуля авторизації при реєстрації користувача. | |По батькові |Текстовий |Обов’язковий |По батьковій Користувача. Отримується з Модуля авторизації при реєстрації Користувача. | |Роль |Довідник |Обов’язковий | | |Статус |Логічний |Обов’язковий |Новий, Активний, Деактивований. | |Коментар |Текстовий |Обов’язковий |Вводиться користувачем при реєстрації. | |Телефон |Текстовий |Обов’язковий |Вводиться користувачем при реєстрації. | |Е-mail |Текстовий |Обов’язковий |Вводиться користувачем при реєстрації. | |Права на ЗДО |Список значень|Необов’язковий |Задається адміністратором обов’язково при редагуванні користувача, тільки якщо в ролі користувача для ЗДО вибрано список. | |Права на ЗО |Список значень|Необов’язковий |Задається адміністратором обов’язково при редагуванні користувача, тільки якщо в ролі користувача для ЗО вибрано список. | |Права на райони |Список значень|Необов’язковий |Задається адміністратором обов’язково при редагуванні користувача, тільки якщо в ролі користувача для райони вибрано список.| \\ ===== 4.7.3    Вимоги до функції «Надання повноважень та активація Користувача» ===== Передбачається, що в залежності від ролі Користувача, ПМ РД буде визначати відповідні повноваження Користувача. Для активації Користувача повинні бути задані атрибути: «Роль» та необхідні «Райони», «Права на ЗДО», «Права на ЗО». Після того, як обліковий запис Користувача стає активний, він отримує доступ до ПМ РД відповідно до наданої ролі та наданих прав.   Передача даних про всіх користувачів з ПМ РД до МР відбувається якщо отримана відповідна згода. ===== 4.8 Вимоги до АРМ «Заклад дошкільної освіти» ===== **4.8            ** ** ** ===== 4.8.1             Вимоги до реєстрації користувачів. =====  Передбачається, що при виконанні дії «Реєстрація», ПМ РД повинен переводити Користувача в Модуль авторизації, в якому повинна бути передбачена можливість автентифікації тільки через ЕЦП. **__Сценарій Реєстрація користувача через ЕЦП__** |**Назва** |**Реєстрація користувача через ЕЦП**| |**Виконавець** |**Користувач** | |Сценарій:\\ \\ 1. Користувач обрав спосіб реєстрації.\\ \\ 2. Користувач вводить необхідні дані (ЕЦП) та ініціює реєстрацію.\\ \\ 3. Модуль авторизації виконує пошук облікових записів по ЕЦП.\\ \\ 4. Якщо обліковий запис НЕ знайдено – перехід до наступного кроку 5.\\ \\ Якщо обліковий запис знайдено – Модуль авторизації повідомляє Користувача, що обліковий запис з таким ЕЦП вже існує та робота Модулю авторизації завершена.\\ \\ 5. Модуль авторизації виконує пошук облікової записи Користувача.\\ \\ 6. Якщо НЕ знайдено облікові записи по даним Користувача – перехід до наступного кроку 7.\\ \\ Якщо знайдено облікові записи по ІПН Користувача/паспортним даним – Модуль авторизації повідомляє користувача, що обліковий запис з таким даними вже існує та робота Модулю авторизації завершена.\\ \\ 7. Модуль авторизації створює обліковий запис, записує в основні дані облікового запису значення ЕЦП з відміткою, що дані перевірені.| | Після створення облікового запису, Модуль Авторизації повинен перенаправити Користувача в ПМ РД та передати в ПМ РД за наявністю такі дані по Користувачу: -       Ідентифікатор користувача; -       Ім'я; -       Прізвище; -       По батькові; -       Телефон; -       Еmail; -       РНОКПП (Індивідуальний податковий номер); -       Дата народження; -       Стать -       Адреса. В ПМ РД здійснюється перевірка унікальності ідентифікатора  Користувача. Якщо значення ідентифікатора користувача унікальне, то передбачається створення нового Користувача (статус «Новий»), а також відбувається перехід на сторінку підтвердження заявки на реєстрацію. На сторінці підтвердження реєстрації Користувач повинен ввести телефон, адресу електронної пошти та коментар, в якому вказує організацію де працює, посаду і для чого потрібен доступ. Якщо всі поля заповнені, то система  попереджає щодо очікування повідомлення про надання доступу//.// Якщо значення ідентифікатора Користувача не пройшло перевірку унікальності, то ПМ РД не створює Користувача. \\ \\ \\ Рисунок 11. Бізнес-процес реєстрації користувача //\\ // ===== 4.8.2    Вимоги до авторизації та автентифікації користувачів ===== Для можливості входу в ПМ РД передбачається процедура автентифікації та авторизації Користувача. Користувач (Реєстратор Суб’єкту, Адміністратор, Користувач) у веб-браузері повинен перейти по відповідному посиланню (URL) на сторінку ПМ РД та активувати вхід. В результаті цієї дії ПМ РД відправляє Користувача в Модуль авторизації, де Користувач має виконати ідентифікацію через використання ЕЦП. Передбачається, що після проходження автентифікації Модуль авторизації повинен перевести Користувача на цільову внутрішню сторінку ПМ РД. ПМ РД повинен здійснити перевірку статусу Користувача та повноважень Користувача. Якщо статус Користувача «Активний», то ПМ РД повинен авторизувати Користувача та відображати інформацію відповідно до повноважень Користувача. У випадку якщо авторизація не пройдена, Модуль авторизації інформує Користувача про помилку. \\ Рисунок 12. Бізнес-процес авторизації та автентифікації користувача ===== 4.8.3    Вимоги до функції «Пошук картки вихованця» ===== Система повинна надати можливість користувачу здійснювати динамічний контекстний пошук картки вихованця за наступними атрибутами: Прізвище, Ім’я, По батькові. Пошук повинен забезпечити можливість відображення кожного поточного атрибуту вихованця, по якому ведеться пошук. Тобто, якщо пошук ведеться на рівні атрибуту Прізвище, то система повинна відображати існуючі варіанти прізвищ, які відповідають введеним даним. Результат пошуку буде відображений в формі, яка містить наступні атрибути: -       Прізвище -       Ім’я -       Дата народження -       Номер свідоцтва про народження. Форма результатів пошуку картки вихованця, також повинна забезпечувати виконання наступних операцій: -       Перегляд картки вихованця -       Редагування картки вихованця. \\ Рисунок 13. Бізнес-процес пошуку картки вихованця ===== 4.8.4    Вимоги до програмного компонента «Перегляд картки вихованця» =====   Користувач повинен мати можливість переглянути наступні дані по вихованцю: -       Особисті дані -       Дані про документи -       Дані про батьків -       Дані про пільги -       Дані про ЗДО -       Дані про групу. Детальний перелік даних описаний вище в моделі даних сутності Вихованець.   За результатом перегляду користувач має можливість роздрукувати картку вихованця. ===== 4.8.5    Вимоги до функції «Друк картки вихованця» ===== Користувач повинен мати можливість роздрукувати картку. Форма друку визначена и незмінна.   ===== 4.9 Вимоги до АРМ «Заклад освіти» ===== **4.9       ** ** ** ===== 4.9.1        Вимоги до реєстрації користувачів ===== Аналогічно вимогам реєстрації користувачів у АРМ «Заклад дошкільної освіти». ===== 4.9.2     Вимоги до авторизації та автентифікації користувачів ===== Аналогічно вимогам до авторизації та автентифікації користувачів у АРМ «Заклад дошкільної освіти». ===== 4.9.3    Вимоги до функції «Створення паспорту ЗО» ===== У випадку відсутності паспорту ЗО, користувач повинен мати можливість його створити. В рамках створення паспорту ЗО, користувач заповнює наступні дані по ЗО: -       Основні дані; -       адресні дані; -       навчальні підрозділи (класи); -       групи продовженого дня; -       комп’ютерне та програмне забезпечення; -       оснащення ЗО. Детальний перелік даних, типи даних, а також обов’язковий статус полів описаний вище у моделі даних ЗО. \\ Рисунок 14. Бізнес-процес створення паспорта ЗО ===== 4.9.4    Вимоги до функції «Перегляд паспорта ЗО» ===== Користувач, має можливість переглянути наступні дані по ЗО: -        основні дані; -        адресні дані; -        навчальні підрозділи (класи); -        групи продовженого дня; -        комп’ютерне та програмне забезпечення; -        оснащення ЗО. Детальний перелік даних описаний вище у моделі даних паспорт ЗО. За результатом перегляду, користувач має можливість: -        редагувати паспорт ЗО; -        друкувати паспорт ЗО; -        видалити паспорт ЗО; -        додати фото ЗО. ===== 4.9.5     Вимоги до функції «Друк паспорта ЗО» ===== За результатом перегляду паспорту ЗО, користувач має можливість роздрукувати паспорт ЗО. Система повинна дозволяти друк за допомогою стандартних засобів. ===== 4.9.6     Вимоги до функції «Логічне видалення паспорта ЗО» ===== Логічне видалення паспорту ЗО можливе тільки якщо у нього не має ні одного активного учня. Після виконання логічного видалення паспорт ЗО переходить в неактивний стан. Не можливо додати учня або співробітника до неактивного паспорту ЗО. ===== 4.9.7    Вимоги до функції «Додання фото ЗО у паспорт» ===== Користувач повинен мати можливість додати фото до паспорту ЗО. Розмір фото не повинен перевищувати 5 Mb. Тип фото може бути тільки: .pdf, .png, .jpg, .bpm, .tiff, .gif. ===== 4.9.8    Вимоги до функції «Редагування ЗО» ===== Користувач, має можливість редагувати наступні дані по ЗО: -        основні дані; -        адресні дані; -        навчальні підрозділи (класи); -        групи продовженого дня; -        комп’ютерне та програмне забезпечення; -        оснащення ЗО. Детальний перелік даних описаний вище у моделі даних ЗО Рисунок 15. Бізнес-процес редагування ЗО ===== 4.9.9    Вимоги до функції «Експорт даних» ===== Передбачається можливість формування та збереження ПМ РД файлу export.xlsx. Наповнення файлу повинно відповідати заданим параметрам фільтрів по паспортам ЗО. Для рівня РУО та ДОН передбачається можливість формування та збереження ПМ РД файлу (з розширенням .csv) з інформацією про учнів, щоб виявити випадки, коли вони залишили заклад освіти і після того не були зафіксовані в жодному, з існуючих в системі, закладі освіти. Наповнення файлу має відповідати заданим параметрам фільтрів пошуку: дата вибуття, дата зарахування, навчальний заклад, район; та містити всю інформацію з відповідного профілю учня. ===== 4.9.10    Вимоги до функції «Пошук картки учня» ===== Система повинна надати можливість користувачу здійснювати динамічний контекстний пошук картки учня за наступними атрибутами: -        Прізвище; -        Ім’я; -        По батькові. Пошук повинен забезпечити відображення кожного поточного атрибуту профілю учня, зазначеного в пошуковому запиті. Тобто, якщо пошук ведеться на рівні атрибуту Прізвище, то система повинна відображати існуючі варіанти прізвищ, які відповідають введеним даним. \\ Рисунок 16. Прототип екранної форми пошуку картки учня Результат пошуку буде відображений в формі, яка обов’язково містить наступні атрибути: -        Прізвище; -        Ім’я; -        По батькові; -        Дата народження. Форма результатів пошуку картки учня також повинна забезпечувати виконання наступних операцій: -        перегляд картки учня; -        редагування картки учня. \\ Рисунок 17. Бізнес-процес пошуку картки учня ===== 4.9.11    Вимоги до функції «Перегляд картки Учня» ===== Користувач має можливість переглянути наступні дані по учню: -        особисті дані; -        дані документів; -        дані по реєстрації; -        дані про батьків; -        дані про навчання. Детальний перелік даних описаний вище у моделі даних Учень. За результатом перегляду Користувач має можливість Редагувати картку учня ===== 4.9.12    Вимоги до функції «Друк картки Учня» ===== Користувач повинен мати можливість роздрукувати картку учня. Система повинна дозволяти друк за допомогою стандартних засобів. ===== 4.9.13    Вимоги до функції «Створення картки Учня» ===== У випадку відсутності картки учня за результатом пошуку, система дозволяє створити нову картку учня. При створенні картки учня, система здійснює пошук. Пошуковий запит може здійснюються за наступними параметрами учнів та їх батьків: -        прізвище; -        ім’я; -        по батькові; -        дата народження. За результатами пошукового запиту, ПМ РД повертає наступні дані: -        особисті дані; -        дані про документ; -        дані по реєстрації; -        контактні дані. Користувач має можливість ввести та зберегти в ПМ РД наступні дані учня: -        дані про батьків; -        дані про навчання. У випадку коли житель міста не знайдено, користувач має можливість ввести та зберегти наступні дані: -        особисті дані; -        дані документів; -        дані по реєстрації; -        дані про батьків; -        дані про навчання.  \\ Рисунок 18. Бізнес-процес створення картки учня ===== 4.9.14    Вимоги до функції «Редагування картки Учня» ===== Користувач має можливість редагувати наступні дані по учню: -        особисті дані; -        дані документів; -        дані по реєстрації; -        дані про батьків; -        дані про навчання. Детальний перелік даних описаний вище у моделі даних Учень. \\ Рисунок 19. Бізнес-процес редагування картки учня ===== 4.9.15    Вимоги до функції «Логічне видалення та активація статусу навчання Учня» ===== Якщо учень переїжджає в інше місто чи переходить на домашнє навчання, то статус навчання Учня переводиться в неактивний стан та вибуває зі списку класу. Якщо статус навчання Учня є не активним, то користувач, який має відповідні повноваження, має можливість активувати статус навчання Учня. ===== 4.9.16    Вимоги до функції «Створення картки співробітника» ===== У випадку відсутності картки співробітників за результатом пошуку, система дозволяє створити нову картку співробітника. При створенні картки співробітника, система здійснює пошук. Пошуковий запит може здійснюються за наступними параметрами співробітника: -        Прізвище; -        Ім’я; -        По батькові; -        Дата народження; -        Документ. За результатами пошукового запиту, ПМ РД повертає наявну в нього інформацію: -        Особисті дані; -        Дані про документ; -        Дані по реєстрації; -        Контактні дані. Користувач має можливість ввести та зберегти в ПМ РД наступні дані співробітника: -        військовий облік; -        дані про освіту; -        дані про місце роботи. У випадку коли жителя міста не знайдено, користувач має можливість ввести та зберегти наступні дані: -        особисті дані; -        дані документів; -        адресні дані; -        військовий облік; -        дані про освіту; -        дані про місце роботи. \\ Рисунок 20. Бізнес-процес створення картки співробітника ===== 4.9.17    Вимоги до функції «Редагування картки співробітника» ===== Користувач, повинен мати можливість редагувати наступні дані по співробітникам: -        особисті дані; -        дані документів; -        адресні дані; -        військовий облік; -        дані про освіту; -        дані про місце роботи. Детальний перелік даних описаний вище у моделі даних Співробітник. \\ Рисунок 21. Бізнес-процес редагування картки співробітника ===== 4.9.18    Вимоги до функції «Пошук картки співробітника» ===== Система повинна надати можливість Користувачу здійснювати динамічний контекстний пошук картки співробітника за наступними атрибутами: -        прізвище; -        ім’я; -        по батькові. Пошук повинен забезпечити відображення кожного поточного атрибуту співробітника, зазначеного в пошуковому запиті. Тобто, якщо пошук ведеться на рівні атрибуту Прізвище, то система повинна відображати існуючі варіанти прізвищ, які відповідають введеним даним. Результат пошуку буде відображений в формі, яка містить наступні атрибути: -        прізвище; -        ім’я; -        по батькові; -        дата народження. Форма результатів пошуку картки співробітника, також повинна забезпечувати виконання наступних операцій: -        перегляд картки співробітника; -        редагування картки співробітника. \\ Рисунок 22. Бізнес-процес пошуку картки співробітника ===== 4.9.19    Вимоги до функції «Перегляд картки співробітника» ===== Користувач повинен мати можливість переглянути наступні дані по співробітнику: -        особисті дані; -        дані документів; -        адресні дані; -        військовий облік; -        дані про освіту; -        дані про місце роботи. Детальний перелік даних описаний вище у моделі даних Співробітник. За результатом перегляду Користувач повинен мати можливість: -       редагувати картку співробітника; -       роздрукувати картку співробітника. ===== 4.9.20    Вимоги до функції «Друк  картки співробітника» ===== За результатом перегляду картки співробітника, користувач повинен мати можливість її роздрукувати. Система повинна дозволяти друк за допомогою стандартних засобів. ===== 4.9.21     Вимоги до функції «Деактивація та активація картки співробітника» ===== Користувач повинен мати можливість перевести картку Співробітника в неактивний стан, якщо користувач був активний і перестав виконувати обов’язки співробітника.   Після переводу в неактивний стан, Співробітник більше не фіксується в закладі освіти.  Користувач повинен мати можливість перевести картку Співробітника в активний стан, якщо користувач не активний зараз, але знову виконує  обов’язки співробітника.  ===== 4.10 Вимоги до АРМ «Адміністратора»    ===== **4.10   ** ** ** ===== 4.10.1    Вимоги до реєстрації користувачів ===== Аналогічно вимогам реєстрації користувачів у АРМ «Закладу дошкільної освіти». ===== 4.10.2    Вимоги до авторизації та автентифікації користувачів ===== Аналогічно вимогам до авторизації та автентифікації користувачів у АРМ «Закладу дошкільної освіти». ===== 4.10.3    Вимоги до функції «Створення ролі» ===== Передбачається, що після виконання дії «Створити роль», АРМ  активує форму створення ролі. Для створення ролі повинні бути заповненні наступні параметри: -        В полі «Назва ролі» вказується назва ролі, що створюється; -        Заповнюються чек-бокси прав на дію, які надаються для даної ролі; -        Вибирається група ролі; -        Вибирається «Права на ЗДО», «Права на ЗО» та «Права на Райони». Створення ролі повинно відбуватися після активації кнопки «Створити» та виконанні таких умов: -        заповнене обов’язкове поле «Назва ролі»; -        в групі прав на дії заповнений, як мінімум один чек-бокс; -        заповнені обидва поля: «Права на ЗДО» та «Права на ЗО»; -        вказана назва ролі є унікальною в Групі; -        набір прав на дії та види послуг є унікальним. Після створення ролі виконується перехід на перегляд ролі. \\ \\ Рисунок 23. Прототип екранної форми створення ролі ===== 4.10.4    Вимоги до функції «Редагування ролі» ===== Функціональність ПМ РД передбачає можливість редагування раніше створеної ролі і повинна передбачати: -        зміну назви ролі; -        надання нових прав ролі (заповнюється відповідний чек-бокс); -        обмеження прав для ролі («скидається» відповідний чек-бокс); -        зміна групи ролі. Збереження нових параметрів ролі повинно відбуватися після активації кнопки «Зберегти» та при виконанні наступних умов: -        заповнено обов’язкове поле «Назва ролі»; -        в групі прав на дії заповнений, як мінімум один чек-бокс; -        вказана назва ролі є унікальною для обраної групи ролі; -        наявність змін в значеннях прав. Після збереження параметрів редагування ролі виконується перехід на перегляд ролі. Якщо поле «Назва ролі» не заповнено, то необхідно повідомити про потребу введення назви ролі. При цьому роль не створюється. //Якщо назва ролі не унікальна для обраної групи, то біля поля «Назва ролі» необхідно повідомити, що роль з такою назвою в даній групі вже існує, та запропонувати  ввести іншу назву.// При цьому роль не створюється. Якщо в поточні налаштування ролі не були внесені зміни, то //необхідно повідомити, що відсутні зміни до поточної ролі, та запропонувати натиснути кнопку "Відмінити", якщо зміни не потрібні//. //Якщо активована кнопка «Відмінити», то повинен здійснюватися перехід в форму перегляду інформації по ролі користувача.// ===== 4.10.5    Вимоги до функції «Перегляд ролі» ===== Перегляд ролі користувача повинен відбуватись у відповідній формі після активації іконки «Перегляд» ( ). Передбачається, що для перегляду будуть доступні наступні параметри: -     Назва ролі; -     Всі права, надані ролі; -     Група користувача; -     Територія дії; -     Права на ЗО; -     Права на ЗДО. Якщо активований елемент управління «Редагувати», то ПМ РД (Адміністрування) повинен здійснювати перехід в форму редагування ролі Користувача. Якщо активований елемент управління «Створити нову роль», то ПМ РД (Адміністрування) повинен здійснювати перехід в форму створення ролі Користувача. Якщо натиснута кнопка «Деактивувати», то ПМ РД (Адміністрування) повинен здійснювати перехід до форми деактивації ролі Користувача. ===== 4.10.6    Вимоги до функції «Перегляд списку ролей» ===== При перегляді списку ролей в формі «Ролі», ПМ РД повинен відображати такі дані: -        Всі ролі в алфавітному порядку – спочатку по назві групи, потім по назві ролі; -        Назву кожної ролі та групу кожної ролі. Якщо активована іконка «Перегляд» ( ), то повинен відбуватись перехід в форму перегляду ролі. Якщо активована іконка «Редагувати» ( ), то повинен відбуватись перехід в форму редагування ролі. \\ Рисунок 24. Прототип екранної форми перегляду списку ролей. ===== 4.10.7    Вимоги до функції «Деактивація ролі» ===== Передбачається, що після натискання на іконку «Деактивувати», відбуватиметься перехід до форми деактивації з повідомленням відносно //того, що п//ісля деактивації всі користувачі даної ролі не зможуть зайти в систему.//// Після активації у спливаючому вікні кнопки «Зберегти» статус ролі повинен змінитись на «Неактивна». При наступній перевірці прав користувача з даною роллю, ПМ РД повинен виконувати наступне: -        Переводити користувача на сторінку входу із завершенням сеансу. -        Повідомити, якщо це не заперечує поточним обставинам, що роль деактивована, та запропонувати //звернутись за деталями до Адміністратора.// Якщо деактивація ролі не підтверджується – у спливаючому вікні активована кнопка «Відмінити», то відбувається перехід в форму перегляду інформації по ролі. ===== 4.10.8    Вимоги до функції «Перегляд списку користувачів» ===== Передбачається, що після того, як в меню Адміністратора буде обраний пункт «Користувачі», ПМ РД активує форму перегляду всіх користувачів В даній формі повинні відображатись всі користувачі в алфавітному порядку (сортування здійснюється за ПІБ). Інформація по кожному користувачу повинна відображатись у вигляді окремої картки. Передбачається, якщо кількість карток користувачів буде більше 10, то ПМ РД повинен здійснювати розбивку карток на сторінки, відображаючи на одній сторінці по 10 карток користувачів із відповідною пагінацією сторінок. \\ Рисунок 25. Прототип екранної форми перегляду списку користувачів По кожному користувачу в картці повинна відображуватись наступна інформація: -        Прізвище; -        Ім’я; -        По батькові; -        Роль; -        Статус. Передбачається, що перегляд наступних 10 карток користувачів на іншій сторінці, відбуватиметься після активації елементу управління «Показати наступні 10». Якщо активована іконка «Переглянути», то ПМ РД повинен виконувати перехід в форму перегляду інформації по Користувачу. Якщо натиснута іконку «Деактивувати», то ПМ РД повинен виконувати перехід в форму деактивації Користувача. Якщо активована іконку «Редагувати», то ПМ РД повинен виконувати перехід в форму редагування інформації по Користувачу. ===== 4.10.9    Вимоги до функції «Пошук Користувача» ===== Функціональність ПМ РД передбачає пошук необхідного користувача за заданими параметрами.  Буде реалізовано наступний механізм пошуку: - В блоці задання параметрів пошуку Користувача в полі «Прізвище» задається значення, по якому буде виконуватись пошук. ПМ РД  повинен відображати тільки картки користувачів, в прізвищі яких міститься відповідне значення, що вказане в полі «Прізвище». - В полі «Ім’я» задається значення, по якому буде виконуватись пошук. ПМ РД  повинен відображати тільки картки користувачів у яких: -     Ім’я Користувача містить значення, яке вказане в полі «Ім'я»; -     Прізвище Користувача містить значення, яке вказане в полі «Прізвище». - В полі «По батькові» задається значення по якому буде виконуватись пошук. ПМ РД повинен відображати тільки картки користувачів у яких: -     Ім’я Користувача містить значення, яке вказане в полі «Ім'я»; -     Прізвище Користувача містить значення, яке вказане в полі «Прізвище»; -     По–батькові Користувача містить значення, яке вказане в полі «По батькові». З//а запитом користувачів може бути нічого не знайдено, тому користувач має спробуйте змінити умови пошуку.// Якщо активовано іконку «Переглянути», то ПМ РД повинен переводити Адміністратора в форму перегляду інформації по Користувачу. Якщо активовано елемент управління «Показати наступні 10», то ПМ РД  повинен відображати наступні 10 карток Користувачів. Елемент управління «Показати наступні» ховається, коли користувач отримав всі наявні в базі дані. ===== 4.10.10 Вимоги до функції «Перегляд інформації по Користувачу» ===== Передбачається, що функціональність ПМ РД, надаватиме можливість переглянути таку інформацію по Користувачу: -     Прізвище -     Ім’я -     По батькові -     Роль -     Телефон -     Е-mail -     Статус -     Права на ЗДО -     Права на ЗО -     Територія дії -     Коментар. \\     Рисунок 26. Прототип екранної форми перегляду інформації по користувачу ===== 4.10.11          Вимоги до функції «Деактивація Користувача» ===== Передбачається, що після натискання на іконку «Деактивувати» ПМ РД, виконуватиме перехід в форму деактивації Користувача. Після активації в спливаючому вікні кнопки «Видалити», ПМ РД  повинен виконувати наступні дії: -        переводити Користувача в неактивний стан; -        переводити Адміністратора в форму перегляду інформації по Користувачу; -        завершувати сесію деактивованого Користувача та переводити Користувача на головну зовнішню сторінку ПМ РД. ===== 4.10.12          Вимоги до функції «Редагування Користувача» ===== Передбачається, що при редагуванні параметрів Користувача ПМ РД, відображатиме наступну інформацію по Користувачу: «Прізвище»; «Ім’я»; «По батькові»; «Телефон»; «Е-mail»; «Статус». Також повинна надаватись можливість редагування параметрів поля: -        «Роль»; -        «Права на ЗДО» (можливість задання залежить від обраної ролі та значення цього параметру в ролі); -        «Права на ЗО» (можливість задання залежить від обраної ролі та значення цього параметру в ролі); -        «Територія дії».  Якщо активовано кнопку «Відмінити», то ПМ РД не зберігає дані та переводить Адміністратора в форму перегляду інформації по Користувачу. \\ \\ Рисунок 27. Прототип екранної форми редагування інформації по користувачу ===== 4.10.13          Вимоги до функції «Перегляд списку довідників» ===== Передбачається, що функціональність модулю надаватиме можливість Адміністратору перегляду інформації по всім існуючим довідникам. \\ Рисунок 28. Прототип екранної форми перегляду списку довідників В формі перегляду довідників всі існуючі довідники повинні відображатись в алфавітному порядку по назві довідника. Атрибути довідників вказані в Таблиця 7 **** Атрибути довідників. Якщо активована іконка «Перегляд записів», то ПМ РД (Адміністрування) повинен переводити Адміністратора в форму перегляду інформації по довіднику. Таблиця 7 Атрибути довідників ^**Назва довідника** ^**Список значень довідника** ^ |**Громадянство** |-       України\\ \\ -       Росії\\ \\ -       Білорусі | |**Додаткове навантаження** |-       ГПД\\ \\ -       Гурток | |**Кваліфікаційна категорія** |-       Спеціаліст\\ \\ -       Спеціаліст другої категорії\\ \\ -       Спеціаліст першої категорії\\ \\ -       Спеціаліст вищої категорії | |**Мови** |-       українська\\ \\ -       англійська\\ \\ -       російська\\ \\ -       болгарська\\ \\ -       іврит\\ \\ -       іспанська\\ \\ -       китайська\\ \\ -       латинська\\ \\ -       німецька\\ \\ -       новогрецька\\ \\ -       польська\\ \\ -       турецька\\ \\ -       французька\\ \\ -       японська | |**Навчальний рік** |-       2015-2016\\ \\ -       2016-2017\\ \\ -       2017-2018\\ \\ -       2018-2019\\ \\ -       2019-2020\\ \\ -       … | |**Нозологія** |-       з інтелектуальними порушеннями\\ \\ -       сліпих\\ \\ -       зі зниженим зором\\ \\ -       глухих\\ \\ -       зі зниженим слухом\\ \\ -       з порушенням опорно-рухового апарату\\ \\ -       з тяжкими порушеннями мовлення\\ \\ -       із затримкою психічного розвитку\\ \\ -       зі складними порушеннями розвитку\\ \\ -       з розладами аутистичного спектра\\ \\ -       із синдромом Дауна | |**Освітньо-кваліфікаційний рівень**|-       Кваліфікований робітник\\ \\ -       Молодший спеціаліст (молодший бакалавр)\\ \\ -       Бакалавр\\ \\ -       Магістр\\ \\ -       Спеціаліст\\ \\ -       Доктор філософії/доктор мистецтва\\ \\ -       Доктор наук | |**Паралель** |-       1\\ \\ -       2\\ \\ -       3\\ \\ -       4\\ \\ -       5\\ \\ -       6\\ \\ -       7\\ \\ -       8\\ \\ -       9\\ \\ -       10\\ \\ -       11\\ \\ -       12 | |**Педагогічні звання** |-       учитель-методист\\ \\ -       старший учитель\\ \\ -       вихователь-методист\\ \\ -       керівник гуртка-методист\\ \\ -       педагог-організатор-методист | |**Пенсійний вік** |-       Не пенсіонер\\ \\ -       Пенсіонер\\ \\ -       Перед-пенсійний стан | |**Посади** |-       вчитель\\ \\ -       вихователь\\ \\ -       учитель музичного мистецтва\\ \\ -       учитель образотворчого мистецтва\\ \\ -       учитель фізкультури\\ \\ -       учитель захисту Вітчизни\\ \\ -       учитель трудового навчання\\ \\ -       директор\\ \\ -       заступник директора\\ \\ -       практичний психолог\\ \\ -       соціальний педагог\\ \\ -       асистент  в інклюзивних класах\\ \\ -       вихователь ГПД\\ \\ -       педагог-організатор\\ \\ -       технічний працівник | |**Постановка на облік** |-       Служба у справах неповнолітніх\\ \\ -       Національна поліція | |**Предмети** |-       Математика\\ \\ -       Фізика\\ \\ -       Історія\\ \\ -       Правознавство\\ \\ -       Географія\\ \\ -       Українська мова та література\\ \\ -       Іноземна мова\\ \\ -       Інформатика | |**Профіль навчання** |-       Філологічний напрям\\ \\ -       Технологічний напрям\\ \\ -       Суспільно-гуманітарний\\ \\ -       Природничо-математичний\\ \\ -       З поглибленим вивченням математики\\ \\ -       З поглибленим вивченням фізики\\ \\ -       З поглибленим вивченням хімії\\ \\ -       З поглибленим вивченням біології\\ \\ -       З поглибленим вивченням історії\\ \\ -       З поглибленим вивченням права\\ \\ -       З поглибленим вивченням економіки\\ \\ -       З поглибленим вивченням інформатики\\ \\ -       З поглибленим вивченням географії\\ \\ -       З поглибленим вивченням української мови та літератури\\ \\ -       З поглибленим вивченням іноземної мови| |**Родинний статус** |-       Мати\\ \\ -       Батько\\ \\ -       Опікун | |**Соціальна категорія** |-       дитина-сирота\\ \\ -       з малозабезпеченої сім'ї\\ \\ -       з інвалідністю\\ \\ -       позбавлена батьківського піклування\\ \\ -       діти з числа внутрішньо переміщених осіб з Луганської області\\ \\ -       діти постраждалі у наслідок ЧАЕС\\ \\ -       дитина-напівсирота\\ \\ -       дитина з багатодітної сім'ї\\ \\ -       діти з числа внутрішньо переміщених осіб з Донецької області\\ \\ -       діти з числа внутрішньо переміщених осіб з АР Крим\\ \\ -       дитина військовослужбовця\\ \\ -       дитина учасника АТО | |**Стать** |-       Жіноча\\ \\ -       Чоловіча | |**Тип групи**//  (гуртки ЗО)// |-       науково-технічний\\ \\ -       еколого-натуралістичний\\ \\ -       туристсько-краєзнавчий\\ \\ -       фізкультурно-спортивний\\ \\ -       художньо-естетичний\\ \\ -       дослідницько-експериментальний\\ \\ -       бібліотечно-бібліографічний\\ \\ -       військово-патріотичний\\ \\ -       оздоровчий | |**Тип документа** |-       Свідоцтво про народження\\ \\ -       Учнівський квиток\\ \\ -       Студентський квиток\\ \\ -       Картка учня\\ \\ -       Паспорт\\ \\ -       Договір оренди | |**Тип класу** |-       Загального типу\\ \\ -       Інклюзивний\\ \\ -       Спеціальний | |**Тип освіти** |-       Вища педагогічна\\ \\ -       Незакінчена вища педагогічна\\ \\ -       Вища технічна\\ \\ -       Незакінчена вища технічна\\ \\ -       Середня спеціальна педагогічна\\ \\ -       Середня спеціальна\\ \\ -       Середня загальна\\ \\ -       Вища військова\\ \\ -       Вища музична\\ \\ -       Вища | |**Типи закладів освіти** |-       заклад освіти I ступеня\\ \\ -       заклад освіти I-II ступенів\\ \\ -       заклад освіти I-III ступенів\\ \\ -       заклад освіти II-III ступенів\\ \\ -       гімназія\\ \\ -       ліцей\\ \\ -       з посиленою військово-фізичною підготовкою\\ \\ -       спеціальна школа\\ \\ -       навчально-реабілітаційний центр\\ \\ -       санаторна школа\\ \\ -       навчально-виховний комплекс\\ \\ -       школа-дитячий садок\\ \\ -       заклад професійно-технічної освіти\\ \\ -       заклад вищої освіти\\ \\ -       заклад дошкільної освіти | |**Форма власності** |-       Комунальна\\ \\ -       Приватна\\ \\ -       Відомча\\ \\ -       Державна | |**Форма навчання** |-       Денна\\ \\ -       Вечірня\\ \\ -       Екстернатна\\ \\ -       Індивідуальна\\ \\ -       Дистанційна\\ \\ -       Заочна | |**Характер зарахування** |-       трудовий договір\\ \\ -       контракт\\ \\ -       ставка\\ \\ -       0,75 ставки\\ \\ -       0,5 ставки\\ \\ -       0,25 ставки | |**Швидкість інтернету** |-       До 10 Мбіт/с\\ \\ -       10-30 Мбіт/с\\ \\ -       30-100 Мбіт/с\\ \\ -       Більше 100 Мбіт/с | ===== 4.10.14     Вимоги до функції «Перегляд Довідника» ===== Функціональність ПМ РД повинна надавати можливість перегляду інформації по довіднику. Передбачається, що в формі перегляду інформації по довіднику ПМ РД, відображатиме назву довідника та розміщатиме записи довідника в алфавітному порядку. Крім цього, повинні відображатись такі параметри: код довідника; дата створення довідника, автор, який створив даний довідник, дата змін та автор змін по кожному запису у довіднику. Якщо активований елемент управління «Додати запис», то повинен відбуватись перехід в форму створення нового запису. Якщо активована іконка «Видалити запис», то повинен відбуватись перехід в форму деактивації запису довідника. Якщо активована іконка «Редагувати запис», то повинен відбуватись перехід в форму редагування запису довідника. ===== 4.10.15     Вимоги до функції у «Створення запису довідника» ===== Передбачається, що створення запису довідника буде однаковим для всіх типів довідників. Можливість створення запису у довідниках повинно відбуватись після активації кнопки «Додати запис» та відкриття форми створення нового запису у довіднику. У відповідних полях активної форми, заповнюється код та назва довідника. Збереження нового запису довідника повинно відбуватись при умові заповнення всіх полів. Якщо не всі поля заповнено, ПМ РД повинен відображати повідомлення відповідно до такого поля: 1) Незаповнене поле «Код: //«Введіть код запису».// 2) Незаповнене поле «Назва запису: //«Введіть назву запису».// Якщо активований елемент управління «Відмінити», запис у довіднику не зберігається та повинен відбуватись перехід на перегляд довідника. ===== 4.10.16     Вимоги до функції «Деактивація запису довідника» ===== Передбачається, що після натискання кнопки «Видалити запис», ПМ РД виконає перехід в форму видалення запису довідника. В активній формі повинно відображатись повідомлення: «//Підтвердження видалення запису! Ви впевнені, що бажаєте видалити даний запис? Після видалення відновити його неможливо».// Після активації у спливаючому вікні кнопки «Видалити запис», ПМ РД повинен перевести запис у неактивний стан, а також запис повинен стати не можливим для вибору. Якщо в спливаючому вікні активовано елемент управління «Відмінити видалення», то ПМ РД повинен перевести Адміністратора на перегляд інформації по довіднику. ===== 4.10.17     Вимоги до функції «Редагування запису довідника» ===== Передбачається, що редагування поточних параметрів довідника, відбуватиметься в формі редагування запису довідника після активації іконки «Редагувати запис». В активній формі ПМ РД повинен відображати поточні атрибути запису довідника: код, назву запису довідника, час створення, час редагування та автора редагування. Крім цього, ПМ РД повинен відображати поля для задання нових значень коду та назви запису довідника та надавати можливість внесення нових атрибутів в полях «Код» і «Назва запису». Збереження нових атрибутів запису довідника повинно відбуватись при виконанні таких умов: -     заповнено всі обов’язкові поля; -     комбінація даних запису код з назвою у довіднику унікальні. Якщо не всі обов’язкові поля заповнено, ПМ РД повинен повідомити, що відповідне поле  необхідно заповнити//.// Якщо атрибути поля «Код» та «Назва запису» не унікальні, то ПМ РД повинен повідомити, що ця //комбінація// «Код» та «Назва запису» //не унікальні.// Якщо активовано елемент управління «Відмінити», то ПМ РД повинен переводити Адміністратора на перегляд довідника та не зберігає змін атрибутів запису довідника. ===== 4.11 Вимоги до АРМ «Адміністратора»    ===== **4.11   ** ** ** ===== 4.11.1    Вимоги до реєстрації користувачів ===== Аналогічно вимогам реєстрації користувачів у АРМ «Закладу дошкільної освіти». ===== 4.11.2         Вимоги до авторизації та автентифікації користувачів ===== Аналогічно вимогам до авторизації та автентифікації користувачів у АРМ «Закладу дошкільної освіти». ===== 4.11.3         Вимоги до функції «Пошук по списку паспортів Закладів освіти» ===== ПМ РД має надати можливість користувачу здійснювати динамічний контекстний пошук паспорту ЗО по всім ЗО району за наступними атрибутами: -        Назва ЗО -        Тип закладу -        Тип власності. Пошук повинен забезпечити відображення кожного поточного атрибуту паспорта ЗО, зазначеного в пошуковому запиті. Тобто, якщо пошук ведеться на рівні атрибуту Тип закладу, то система повинна відображати існуючі варіанти закладів освіти відповідного типу, що зафіксовані у цьому районі. Результат пошуку буде відображений в формі, яка містить наступні атрибути: -        Назва ЗО -        Тип закладу -        Тип власності. Форма результатів пошуку паспорту закладу освіти, також повинна забезпечувати виконання наступних операцій: -        Перегляд паспорту закладу освіти -        Друк паспорту закладу освіти із відповідним форматуванням сторінки для друку. \\ \\ ====== 5.      НЕФУНКЦІОНАЛЬНІ ВИМОГИ ДО СИСТЕМИ ====== **5** ** ** ===== 5.1 Загальні вимоги ===== Система повинна модернізовуватися з використанням безкоштовних програмних засобів з відкритими кодами, такими як PostgreSQL, MYSQL або аналогів та використовувати найсучасніші та перспективні формати інформаційного обміну даними між клієнтом і сервером на основі протоколу HTTPs за специфікаціями консорціуму "OGC". Взаємодія між сервером додатків та клієнтом для кінцевого користувача повинно виконуватися за протоколом HTTPs із використанням TLS. Модернізація ІС МР повинна виконуватись із використанням принципів концепції Free and Open Source Software (FOSS), розширених парадигмою гуманітарної відповідальності (Humanitarian-FOSS) і включає такі вимоги: -       Націленість на рішення критично важливих завдань для підвищення швидкості: * надання Послуг на Порталі послуг, ЗІС (ОКК), ЗІС, в яких реалізовані on-line послуги; * роботи ПМ «РД». -       Висока орієнтація на якість, надійність і стабільність роботи ПМ РД, виключення втрати і дублювання даних. -       Мінімальні вимоги до кваліфікації користувачів і необхідності їх навчання. -       Прозорі інтеграційні можливості. -       Інформаційна та технічна безпека ПМ РД. -       Гнучка рольова модель із можливістю її модифікації. -       Забезпечення необхідного рівня конфіденційності персональних даних громадян згідно із Законодавством України. -       Забезпечення прозорості доступу до інформації. -       Забезпечення історії збереження записів. -       Забезпечення резервування програмних модулів, компонентів ІС МР. -       Всі програмні модулі, компоненти, що впроваджуватимуться та поставлятимуться в рамках цієї закупівлі, мають бути надані на умовах ліцензування GPL   (http://www.gnu.org/licenses/gpl.html) і забезпечувати відкритість, прозорість та доступність вихідних кодів продукту за ідеологією OpenSource (ліцензія на вільне програмне забезпечення). -       Якісна супроводжувальна робоча та експлуатаційна документація. ===== 5.1   Вимоги до чисельності, кваліфікації та режиму роботи персоналу ===== Запропоновані рішення модернізації ПМ РД в частині створення ПМ РД будуть вимагати не менш ніж 3-х фахівців з певною роллю та відповідним рівнем підготовки, які повинні забезпечувати: -       безперервне супроводження ПМ РД на всіх стадіях його експлуатації та підтримки; -       цілодобовий режим роботи ПМ РД та його модулів за призначенням в повному обсязі; -       централізований контроль працездатності ПМ РД; -       усунення відмов роботи ПМ РД та його компонентів; -       адміністрування (оперативне налагодження під час експлуатації) роботи ПМ РД; -       своєчасне централізоване застосування оновлень програмного забезпечення. ===== 5.2   Вимоги до показників навантаження ===== ІС МР повинна забезпечувати: -       час обробки запитів із наданням релевантних відповідей – 1-3 секунди; -       можливість зберігання історичних даних протягом усього часу використання ПМ РД; -       здатність забезпечити можливість нарощування кількості користувачів та об’ємів баз даних без потреби будь-яких додаткових доробок. Швидкість роботи ПМ РД не повинна погіршуватися при: -       пікових навантаженнях із одночасною роботою 10000 користувачів (одночасних запитів в 1 секунду); -       порядковому зростанні кількості користувачів; -       зростанні об’єму бази даних в декілька разів від початкового значення на момент дослідної експлуатації. ===== 5.3   Вимоги до надійності ===== Збереження працездатності повинно забезпечуватись надійністю роботи при відмові одного або декількох компонентів за рахунок їх резервування. При цьому повинна вимагатися мінімальна увага з боку адміністратора щодо реакції на усунення наслідків відмов компонентів. Збереження даних повинно забезпечуватись програмно-апаратними засобами та механізмами обміну інформації. Надійність ПМ РД повинна бути забезпечена за  наступними напрямками: -       забезпечення працездатності ПМ РД; -       збереження даних  ПМ РД Надійність повинна забезпечуватись за рахунок: -       використання сучасних технологій розробки ПМ РД та забезпеченням якісного тестування; -       резервуванням  компонентів та їх елементів; -       режиму автоматичного аналізу поточного стану (в реальному стані) та відновлення працездатності у відповідності до регламенту відновлювальних робіт; -       організації систематичного резервного копіювання та архівного збереження інформації в ПМ РД; -       апаратно-програмним захистом роботи від стороннього несанкціонованого програмно-апаратного втручання; -       архівним збереженням інформації; -       оперативністю заміни програмно-технічних засобів, що вийшли з ладу; -       сумісністю технічних засобів та програмного забезпечення. ===== 5.4   Вимоги до інформаційної безпеки ===== На початковому рівні створення ПМ РД будуть реалізовуватися базові заходи із забезпечення захисту інформації та технологічної інформації про систему. Повинні бути реалізовані наступні заходи захисту початкового рівня, а саме: -       організаційно-адміністративні; -       апаратно-програмні; -       інженерно-технічні. Побудова КСЗІ здійснюється виключно після визначення вищого грифа інформації, що циркулює у ІС МР. Вимоги щодо КСЗІ визначатимуться в окремому Технічному завданні, яке буде розроблятись Виконавцем, якого буде визначено за результатами проведення окремої конкурсної процедури. Доступ до інформації з обмеженим доступом, що знаходиться в інформаційно-телекомунікаційних систем/підсистем та апаратних платформ (далі – ІТС) КП ГІОЦ, після підписання угоди (договору) про конфіденційність, надається через захищені канали зв’язку з використанням програмних або технічних засобів криптографічного захисту інформації, що мають позитивний експертний висновок ДССЗЗІ. ===== 5.5   Вимоги до ергономіки ===== Рішення щодо ергономіки веб-інтерфейсу повинно надавати у використання користувачу зрозумілу логічну побудову інформаційної архітектури із певним набором відповідних графічних, текстових, функціональних компонентів. Загальна побудова  веб-інтерфейсу повинна передбачати зрозумілу логічну модель структури сторінок та переходів між ними. Сторінки не повинні бути перевантажені інформаційно-графічними матеріалами. Глибина вкладення (логічних переходів) не повинна бути більше 5 рівнів. Побудова логічних зв’язків в межах певної функціональності повинна бути зручною та інтуїтивно зрозумілою. Всі інтерактивні елементи повинні бути виконані у зручному та зрозумілому представленні із набором відповідних текстових та/або графічних інформаційних підказок. Користувач повинен мати зручний інтерфейс із обгрунтованим набором необхідних інструментів для виконання певних дій, закладених у межах відповідного бізнес-процесу. ===== 5.5.1   Веб-інтерфейс повинен відповідати таким вимогам щодо використання технологій при його створенні: ===== -       Рішення повинно бути виконано з використанням елементів адаптивних технологій. -       Передбачається використання HTML4 / HTML5, Ajax, JavaScript. -       Для накладення стильової інформації використовується таблиці стилів CSS3. -       Можливе використання різних rich-media технологій як компоненту HTML сторінок. -       Використання таких технологій, як Flash, наприклад, у вигляді Flex або SilverLigh не передбачається. ===== 5.5.2   В цілому передбачається сумісність: ===== -       з операційними системами: Windows, Linux; -       з браузерами, у тому числі мобільними: Microsoft Edge, Opera, Mozilla Firefox, Google Chrome (передостанні версії згідно до етапу 2.2 календарного плану). ===== 5.5.3   Основні вимоги до інформаційно-графічних елементів веб-інтерфейсу ===== Коректне типізоване відображення (сумісність) інформації в передостанніх версіях найбільш популярних веб-браузерів: -       Opera; -       Microsoft Edge; -       Chromе. Графічний і структурний дизайни повинні бути виконані з урахуванням плавної зміни розміру вікна веб-браузера. При перевищенні  максимального розміру вікна браузера, дизайн повинен передбачати заповнення зайвого місця фоновими матеріалами, які можуть бути збільшені без обмежень – наприклад, фонова картинка рівної структури. Всі екранні форми інтерфейсу користувача повинні бути виконані в єдиному графічному дизайні з однаковим розташуванням основних елементів управління і навігації. Схожі операції повинні виконуватися з використанням ідентичних графічних елементів у повній відповідності до побудови (структури) інформаційної архітектури рішення. ===== 5.6   Вимоги до експлуатації і технічного обслуговування, ремонту та зберігання компонентів ПМ РД ІС МР ===== Експлуатація ПМ РД повинно виконуватися в умовах, що забезпечують їх нормальне функціонування, згідно з вимогами виробника програмного та технічного забезпечення. Експлуатація ПМ РД повинно виконуватися за наступними принципами: -       технічне супроводження виконується обслуговуючим персоналом Замовника або Виконавця згідно з вимогами виробника програмного та технічного забезпечення, які надаються Виконавцем у вигляді інструкцій з експлуатації; -       Технічне обслуговування та ремонт виконується персоналом Виконавця відповідно до вимог виробників. Технічне супроводження програмного забезпечення ПМ РД повинно виконуватися системними адміністраторами, технічне супроводження обладнання ПМ РД виконується технічними спеціалістами Замовника чи Виконавця. Регламент обслуговування обладнання, кількість і кваліфікація обслуговуючого персоналу конкретного робочого місця повинно відповідати вимогам виробника програмно-технічних засобів і бути узгодженим із Замовником. ===== 5.7   Вимоги до режимів функціонування ===== Безперервне повноцінне функціонування відповідно до заявленої функціональності. Серверні програмно-технічні засоби повинно функціонувати у цілодобовому режимі із заздалегідь визначеними періодами регламентного обслуговування. Експлуатація ПМ РД повинна передбачати такі режими: -       Основний режим – режим штатного функціонування всіх компонентів ПМ РД за своїм призначенням. -       Нештатний режим – режим нештатного функціонування всіх компонентів ПМ РД, наприклад, недоступність даних серверу. -       Режим адміністрування – режим здійснення централізованого автоматизованого налагоджування та автоматизованого оновлення компонентів ПМ РД одночасно з роботою решти користувачів в ПМ РД    в основному режимі або в режимі Технічного обслуговування. -       Режим регламентного обслуговування – режим регламентного технічного обслуговування та відновлення працездатності технічних засобів компонентів ПМ РД. ===== 5.8   Вимоги до збереження інформації при аваріях ===== ІС МР повинна включати програмні засоби моніторингу та механізми документування аварійних подій чи помилок. В разі виникнення аварійних подій чи помилок в роботі ПМ РД, помилка повинна реєструватися у відповідному електронному журналі, а адміністратор має отримати відповідне повідомлення із зазначенням типу помилки. При цьому повинна бути реалізована можливість отримання технічної довідкової інформації-допомоги з різним рівнем деталізації щодо ліквідації аварійних  подій чи  виправлення помилки. До складу повідомлення щодо події аварійного типу повинні входити: -       час; -       текстова назва аварії; -       назва файлу вихідних текстів; -       номер рядка в файлі; -       причина помилки. Користувачі ОКК / Користувачі ПМ РД, в разі виникнення помилок, повинні бачити лише скорочені інформаційні повідомлення зрозумілого характеру без технічної деталізації. Збереженість інформації повинна бути забезпечена у разі виникнення наступних подій (аварій, відмов тощо): -       відмова обладнання сервера; -       вимкнення живлення на робочому місці та/або на сервері баз даних; -       відмова обладнання робочої станції; -       відмова ліній зв’язку. З метою забезпечення зберігання інформації повинно використовуватися: -       резервне копіювання; -       відновлення даних при збоях в роботі мережевого, програмного і апаратного забезпечення. Якщо в процесі перевірки виявляються помилки, то система повинна зробити спробу виправлення знайденої помилки. У випадку виявлення помилок система повинна занести інформацію про помилки до системних журналів відповідної БД. Контроль за функціонуванням ПМ РД, проведення планових і позапланових регламентних робіт, усунення відмов і збоїв повинно здійснюватися технічним персоналом підрозділів інформаційних технологій Замовника. ===== 5.9   Вимоги до патентної чистоти ===== Патентна чистота ПМ РД повинна бути забезпечена розробником і повинна гарантуватися фірмами- розробниками програмних засобів. ===== 5.10         Вимоги до стандартизації і уніфікації ===== Стандартизація та уніфікація функцій ПМ РД ІС МР повинна бути забезпечена за рахунок використання сучасних інструментальних програмних засобів які підтримують єдину технологію проектування та розробки функціонального, інформаційного та програмного забезпечень. Рішення з технічного та загального програмного забезпечення ПМ РД  ІС МР повинні передбачати вибір сумісних, найбільш інтегрованих програмних та технічних засобів, які відповідають вимогам сучасних міжнародних стандартів відкритих систем та програмних засобів. У процесі розробки ПМ  РД  будуть сформовані вимоги до розробки прикладного програмного забезпечення, які опишуть процедуру обробки інформації, ідентифікацію програмних модулів та баз даних, типізують окремі програмні модулі відповідно до свого призначення. ===== 5.11         Вимоги до видів забезпечення ===== Інформаційне забезпечення ПМ РД повинно відповідати таким вимогам та можливостям: -       багаторазове використання даних у різних ділових процесах; -       забезпечення  фізичної та логічної цілісності даних; -       мінімізація надмірності даних, що зберігаються; -       стандартизація представлення даних; -       достовірність та актуальність даних. Побудова ПМ РД  повинна забезпечувати: -       розмежування доступу до даних, запобігання несанкціонованого доступу до них; -       копіювання і зберігання масивів інформації; -       мінімізацію обсягу даних, що вводяться вручну; -       можливість розширення масивів інформації з урахуванням перспектив розвитку. Інформаційне забезпечення  ПМ РД  повинна включати: -       компонент класифікації і кодування; -       програмні модулі забезпечення інформаційного обміну між компонентами системи та між внутрішніми та зовнішніми інформаційними системами, з якими повинний бути організований обмін. Компонент класифікації і кодування повинен підтримувати процес накопичення і зберігання інформації, а також вирішення функціональних задач з мінімальними витратами пам’яті і максимальною швидкодією за рахунок використання класифікаторів таких рівнів: -       локальних в межах системи; -       відомчих; -       загальнодержавних. Рішення по системі класифікації і кодування системи повинно передбачати: -       використання загальносистемних класифікаторів; -       централізоване ведення системних класифікаторів; -       забезпечення можливості аналізу інформації, формування статистичних звітів по усьому спектру класифікованих даних; -       забезпечення мінімальних витрат пам’яті у процесі накопичення та зберігання інформації; -       забезпечення максимальної швидкодії при вирішенні функціональних задач. Програмні модулі інформаційного обміну повинні забезпечити автоматизований обмін інформацією між компонентами ПМ РД та між суміжними інформаційними системами для забезпечення виконання завдань та функцій ділових процесів, що підлягають автоматизації. Інформаційний обмін з суміжними системами повинен бути реалізований за рахунок розробки чи використання програмного шлюзу інформаційного обміну та застосуванням сучасних протоколів обміну даними. Шлюз інформаційного обміну повинен передбачати: -       можливість підключення та безпечність доступу локальних ресурсів ПМ РД ІС МР до зовнішніх інформаційних систем та ресурсів; -       можливість централізованого адміністрування та керування доступністю локальних ресурсів ПМ РД  ІС МР. ===== 5.11.1     Вимоги до математичного забезпечення ===== Вимоги до математичного забезпечення не висуваються. ===== 5.11.2     Вимоги до лінгвістичного забезпечення ===== Мовні засоби програмування будуть обираються Виконавцем відповідно до рішень з програмного забезпечення  ПМ РД. ===== 5.11.3     Вимоги до апаратно-програмного забезпечення ===== Програмне забезпечення (далі – ПЗ) ПМ РД повинно складатися із: -       загальносистемного програмного забезпечення (далі – ЗПЗ); -       прикладного програмного забезпечення (далі – ППЗ). Програмне забезпечення ПМ РД повинно відображати специфіку функціональних задач користувачів та забезпечувати: -       підтримку загально прийнятих сучасних міжнародних стандартів до відкритих систем; -       сумісність та інтегрованість; -       підтримку функціонування в різнорідному апаратному і програмному середовищах; -       вмонтованість механізму захисту від помилок і підтримки цілісності. Розробник повинен надати рекомендації щодо складу загальносистемного програмного забезпечення: -       операційні системи; -       система керування базами даних; -       програмна платформа; -       система забезпечення версійності та інтеграції проекту; -       система моніторингу; -       система відслідковування помилок; -       сервери додатків. Загальне програмне забезпечення не є предметом закупівлі або розробки. Рішення зі складу загальносистемного програмного забезпечення повинно технічно та економічно обґрунтовано з точку зору цілісності та обґрунтованої повноти програмного застосування ПМ РД та його компонентів за призначенням та мінімізації витрат на подальший супровід. До прикладного програмного забезпечення повинна відноситись програмне забезпечення, що розробляється  та налаштовується під час модернізації ІС МР. За результатами створення та впровадження  ПМ РД програмний код прикладного програмного забезпечення повинен бути переданий Виконавцем Замовнику в електронному вигляді. Розробка прикладного програмного забезпечення повинна проводитись за допомогою сучасних інструментальних засобів програмної інженерії проектування і генерації розподілених баз даних (CASE-засобів). При розробці ППЗ повинні використовуватися принципи модульності та типовості, які забезпечать послідовне нарощування функціональних можливостей ПМ РД за рахунок створення, впровадження та тиражування функціонально завершених програмних модулів. Згідно даних, наданих Замовником, щодо прогнозованого навантаження на систему, ПМ РД забезпечує безперебійну роботу при нижче вказаних показниках, при яких ПМ РД повинна зберігати час відклику компонентів системи не більше 3х секунд. Таблиця 8 Параметри навантаження ^**Параметри навантаження** ^**Показники**^ |Кількість користувачів (всього) |1 млн. | |Пікова кількість одночасно працюючих користувачів |1 000* | |Середня кількість заявок на послугу по всій системі за день|6 000 | |Пікова кількість заявок на послугу по всій системі за день |16 000 | |Об’єм (кількість) сканкопій документів |200 000 | *За результатами попереднього аналізу достатня кількість для промислового функціонування систем. Розробник рекомендує такі характеристики віртуальних серверів: -       Віртуальний сервер БД: CPU 12, Memory 16GB, HDD 750GB; -       Віртуальний сервер APP: CPU 12, Memory 16GB, HDD 500GB; -       Віртуальний сервер FileStorage: CPU 12, Memory 16GB, HDD 2TB; -       Віртуальний сервер БД резервний: CPU 12, Memory 16GB, HDD 750GB; -       Віртуальний сервер APP резервний: CPU 12, Memory 16GB, HDD 250GB; -       Віртуальний сервер FileStorage резервний: CPU 12, Memory 16GB, HDD 2TB; -       Віртуальний сервер БД та APP тестовий: CPU 12, Memory 16GB, HDD 500GB; -       Віртуальний сервер моніторингу: CPU 1, Memory 8GB, HDD 100GB; -       Віртуальний ервер забезпечення версійності, інтеграції та відслідковування помилок. Очікувана верхньорівнева архітектурна схема побудови рішення представлено на Рисунку 29. \\ Рисунок 29. Очікувана верхньорівнева архітектурна схема\\ побудови рішення **__Апаратне забезпечення__** **** – зберігання даних для управління інформаційними інфраструктурами. **__Платформа__** **__OpenShift__** **____** **__(версія 3.9)__** – це відкрита і розширювана платформа додатків-контейнерів, яка дозволяє за допомогою спеціальних об'єктів і механізмів швидко розробляти програми, легко розгортати і масштабувати рішення, обслуговувати життєвий цикл команд і додатків в довгостроковій перспективі. **__Контейнер ЗІС__** **** – **** низькорівневий програмний компонент  із своїм API, який забезпечує координацію і веб-інтерфейси для розгортання та управління Зовнішньою Інформаційною Системою. **__ПМ Реєстр Дітей__** – Програмний модуль «Реєстр дітей» інформаційної системи «Муніципальний реєстр». **__Сервіс Автентифікації користувача__** **** – зовнішній технологічний сервіс інформаційної системи ГІОЦ. **__ЗІС__** **__Електронна Черга__** **** – зовнішній програмний модуль, який забезпечує ведення черги у ЗДО та акумулювання даних про мережу закладів дошкільної освіти. **__Сервер додатків, база даних, мови розробки__** – компоненти технологічного стеку розробки. За виникнення необхідності архітектура інфраструктури рішення із рекомендаціями щодо апаратно-програмного забезпечення може бути змінена та буде описана на етапі розробки.  У разі збільшення кількості користувачів на 25% і більше, Розробник рекомендує переглянути вимоги до Серверу БД та Серверу APP. У разі збільшення навантаження пікової кількості одночасно працюючих користувачів на 25% і більше, Розробник рекомендує переглянути вимоги до Серверу БД та Серверу APP. У разі збільшення (кількості) сканкопій документів на 25% і більше, Розробник рекомендує переглянути вимоги до File Storage. ===== 5.11.4     Вимоги до технічного забезпечення ===== Вимоги до розробки ПМ РД  в цілому: -       ПМ РД повинен мати архітектуру, побудовану на сучасних промислових технологіях зберігання, обробки, аналізу даних та доступу до них, забезпечувати одночасну роботу користувачів. -       ПМ РД повинен мати централізовану базу даних, яка підтримує шифрування певного набору даних, та можливість організації взаємодії (інтерфейси взаємодії) із суміжними інформаційними системами. -       Для захисту певних інформаційних об’єктів у ПМ РД може використовуватися програмний засіб криптографічних перетворень, який має позитивний експертний висновок Державної служби спеціального зв'язку та захисту інформації України. -       ПМ РД повинен представляти собою комплекс інформаційних, програмних, технічних, організаційно-методичних та інших необхідних засобів, що забезпечують збір, обробку, зберігання, передачу даних. -       ПМ РД повинен мати засоби діагностики цілісності як БД в цілому, так і окремих таблиць/об’єктів, а також засоби шифрування. -       Архітектура ПМ РД повинна передбачати максимальну незалежність програмно-технічних модулів від розробника таким чином, щоб їх подальшим розвитком могли займатися підрядні організації із відповідним рівнем кваліфікації. -       Інформаційна архітектура  ПМ РД повинна відповідати сучасним вимогам щодо побудови інтерфейсів користувачів. -       ПМ РД повинен мати механізми щодо кластеризації рішення. Рішення щодо побудови ПМ РД повинно базуватися на: -       застосуванні сучасних інформаційних технологій; -       реалізації концепції створення єдиного інформаційного простору в\\ м. Києві; -       застосуванні правила централізованого накопичення, зберігання та обробки інформації; -       підтримці актуальності, повноти, несуперечності, цілісності та доступності інформації; -       забезпеченні надійного захисту інформації від порушення її цілісності, витоку (за допомогою механізмів шифрування і хешування) та блокування згідно з порядком, встановленим нормативно-правовими державними актами і нормативними документами в галузі захисту інформації; -       забезпеченні надійності, резервування компонентів технічного забезпечення ПМ РД; -       забезпеченні централізованого управління, безперервного контролю функціонування та централізованого налаштування ПМ РД (модулів та компонентів); -       використанні сучасних засобів програмної інженерії при розробці програмного прикладного забезпечення.   ПМ РД ІС МР повинна мати наступні характеристики та функціональність: -       клієнт-серверну архітектуру (сервер застосувань, сервер баз даних), яка забезпечує побудову будь-яких централізованих програмних комплексів з єдиною центральною базою даних та центральним електронним сховищем інформації; підтримувати використання об’єктно-реляційної СКБД відкритого типу (програмне забезпечення з відкритим вихідним кодом); -       повинні бути передбачені необхідні засоби автоматизованого контролю цілісності даних і несуперечності збереженої інформації, персоніфікації даних, створених різними користувачами, ведення журналу операцій, які виконуються; -       забезпечувати механізми для адміністрування користувачів та їх повноважень, а також забезпечувати захист персональних даних відповідно до чинного законодавства України; -       у разі додавання апаратних ресурсів на рівні серверу додатків, система повинна забезпечувати близький до лінійного приріст продуктивності; -       обов’язкове документування АPI у відповідності до міжнародних типів специфікацій та екосистем таких як Swagger, RAML, API Blueprint для використання внутрішніми/сторонніми сервісами. Перевага надається засобу, яке передбачає найкращу підтримку на момент розробки компонентів та модулів з точки зору бібліотек, фреймворків, націлених на використання в різних мовах програмування, їх зрілості; -       передбачати використання засобів для забезпечення виконання міграцій схеми бази даних; -       підтримка URL-адресації для будь-яких інформаційних об'єктів (користувач повинна мати можливість отримувати/відправляти прямі URL-посилання на об'єкти системи); -       використання форматів інформаційного обміну даними на основі таких протоколів та стандартів: HTTPS, WMS, WFS, XML, JSON, REST (Restfull). ===== 5.11.5     Вимоги до метрологічного забезпечення ===== Вимог до метрологічної сумісності технічних засобів ПМ РД не пред’являється. Якісні характеристики ПМ РД перевіряються на випробуваннях згідно з Програмою і методикою попередніх випробувань. На вимогу Замовника метрологічна сумісність технічних засобів може бути проведена сторонніми організаціями. ===== 5.11.6     Вимоги до організаційного забезпечення ===== Організаційне забезпечення, що впроваджуватиметься в межах створення ПМ РД, повинно включати документи, які відображатимуть автоматизований технологічний процес обробки інформації та регламентуватимуть діяльність користувачів. ===== 5.11.7     Вимоги до методичного забезпечення ===== Рішення щодо методичного забезпечення повинно враховувати оптимізацію ділових (функціональних) процесів, що відображують автоматизацію цих процесів. \\ ====== 6.      СКЛАД ТА ЗМІСТ ЗАВДАНЬ ЗІ СТВОРЕННЯ ПМ РД ======      Склад та зміст робіт зі створення ПМ РД передбачає: **//Етап 1 календарного плану.//** **Розробка Технічного завдання на створення ПМ РД** **//Етап 2  календарного плану.//** **Розробка програмного забезпечення ПМ РД** Дослідний зразок програмного забезпечення ПМ РД. Розробка документації: 1)     Загальний опис ПМ РД. 2)     Керівництво Системного адміністратора. 3)     Інструкція з розгортання та налаштування. 4)     Програма та методика попередніх випробувань. 5)     Протокол попередніх випробувань. 6)     Акт приймання в дослідну експлуатацію програмного забезпечення\\ ПМ РД. **//Етап 3 календарного плану.//** **Дослідна експлуатація програмного забезпечення ПМ РД, розробка    документації** -  Програма та методика дослідної експлуатації. -  Інструкція  з розгортання та налаштування бази даних. -  Керівництво Користувача. -  Керівництво Адміністратора. -  Протокол дослідної експлуатації. ====== 7.      ПОРЯДОК КОНТРОЛЮ ВИКОНАННЯ ТА ПРИЙМАННЯ ====== Календарний план надання послуг вказано в Таблиця 9. Календарний план надання послуг. Таблиця 9. Календарний план надання послуг ^**№ з/п**^**Назва послуги за етапом** ^**Термін%%**%%** ^**Результат** ^**Вартість послуги без ПДВ, грн.**^ |**1** |**Розробка технічного завдання на створення ПМ РД** |20 робочих днів з дати отримання письмової заявки від Замовника|Технічне завдання на створення ПМ РД |** ** | |**2** |**Розробка програмного забезпечення ПМ РД** |35 робочих днів з дати отримання письмової заявки від Замовника|Дослідний зразок програмного забезпечення ПМ РД на майданчику Замовника\\ \\ Загальний опис ПМ РД\\ \\ Керівництво Системного адміністратора\\ \\ Інструкція з розгортання та налаштування\\ \\ Програма та методика попередніх випробувань\\ \\ Протокол попередніх випробувань\\ \\ Акт приймання в дослідну експлуатацію програмного забезпечення ПМ РД|** ** | |**3** |**Дослідна експлуатація програмного забезпечення ПМ РД, розробка документації**|20 робочих днів з дати отримання письмової заявки від Замовника|Програма та методика дослідної експлуатації\\ \\ Інструкція з формування та ведення бази даних\\ \\ Керівництво Користувача\\ \\ Керівництво Адміністратора\\ \\ Протокол дослідної експлуатації |** ** | ====== 8.      ВИМОГИ ДО СКЛАДУ ТА ЗМІСТУ ПОСЛУГ З ПІДГОТОВКИ ОБ’ЄКТА АВТОМАТИЗАЦІЇ ДО ВВЕДЕННЯ В ДІЮ ====== З метою забезпечення підготовленості  об’єкта автоматизації до введення ПМ РД  в дію потрібно провести: - Погодження з Замовником переліку вхідної та вихідної інформації, яка буде надходити до Системи і оброблятися із застосуванням персональних комп’ютерів. - Навчання персоналу Замовника, яке проводиться за графіком, що розробляється Виконавцем та погоджується Замовником. - Роботи з забезпечення обладнання всіх робочих приміщень, де планується встановлення обладнання ПМ РД відповідно до вимог технічного завдання. Замовник повинен виконати наступні дії: - Визначити відповідальних осіб за проведення приймальних випробувань ПМ РД з урахуванням потреб та завдань розробки другої черги. - Разом з Виконавцем провести попередні випробування та дослідну експлуатацію модернізованого програмного забезпечення ПМ РД. ====== 9.      ВИМОГИ ДО ДОКУМЕНТУВАННЯ ====== Виконавець повинен надати Замовнику документи щодо наданих послуг. Обов’язковими елементами документів є інформація про технічні характеристики, опис функцій, інформація, яка необхідна для обслуговування. Документація розробляється згідно з ДСТУ 3973-2000, ДСТУ 3974-2000, ГОСТ 34.201-89, РД 50-34.698-90,  ДСТУ 3008-2015 і Розпорядження виконавчого органу Київської міської ради (Київської міської державної адміністрації) від 03 липня 2018 року № 1135 Про затвердження Положення про забезпечення захисту інформації в інформаційно-телекомунікаційних системах структурних підрозділів виконавчого органу Київської міської ради (Київської міської державної адміністрації), районних в місті Києві державних адміністрацій, підприємств, установ та організацій, що належать до комунальної власності територіальної громади міста Києва або передані до сфери управління виконавчого органу Київської міської ради (Київської міської державної адміністрації) та включає: - Технічне завдання. - Загальний опис ПМ РД. - Програма та методика попередніх випробувань. - Протокол попередніх випробувань. - Керівництво адміністратора та  Системного адміністратора. Також документ повинен включати в себе: -       перелік інформаційних ресурсів ПМ РД, які потребуватимуть резервного копіювання із рекомендаціями щодо резервного копіювання. - Загальна інструкція з розгортання та налаштування ПМ РД. - Керівництво Користувача ПМ РД. - Інструкція з формування та ведення бази даних. - Програма та методика дослідної експлуатації. - Протокол дослідної експлуатації. - Акт приймання системи в дослідну експлуатацію. Документація надається українською мовою на електронному та паперовому носіях. ====== 10. ДЖЕРЕЛА РОЗРОБКИ ====== Дане Технічне завдання розроблено на основі наступних документів та інформаційних матеріалів: - Договір про надання послуг від 10 вересня 2018 року № 4458 Послуги з розробки пакетів програмного забезпечення (Розвиток Інформаційної системи «Муніципальний Реєстр», друга черга). - Матеріали інтерв’ю з представниками Замовника. ====== СПИСОК РИСУНКІВ ====== Рисунок 1. Загальна логічна схема рішення. 27 Рисунок 2. Схема відношень між сутностями Муніципального реєстру «Користувач ОКК», «Житель СК», «Житель РТГК», «Житель ОС». 28 Рисунок 3. Схема відношень між сутностями компонента ЗО.. 29 Рисунок 4. Структура сутності Паспорт ЗО.. 30 Рисунок 5. Структура моделі даних Учень. 35 Рисунок 6. Структура моделі даних Співробітник. 38 Рисунок 7. Схема відношень між сутностями компонента ЗДО.. 41 Рисунок 8. Структура моделі даних Вихованець. 42 Рисунок 9. Бізнес-процес отримання даних з Електронної черги. 46 Рисунок 10. Рольова модель системи. 51 Рисунок 11. Бізнес-процес реєстрації користувача. 56 Рисунок 12. Бізнес-процес авторизації та автентифікації користувача. 57 Рисунок 13. Бізнес-процес пошуку картки вихованця. 58 Рисунок 14. Бізнес-процес створення паспорта ЗО.. 60 Рисунок 15. Бізнес-процес редагування ЗО.. 61 Рисунок 16. Прототип екранної форми пошуку картки учня. 62 Рисунок 17. Бізнес-процес пошуку картки учня. 63 Рисунок 18. Бізнес-процес створення картки учня. 64 Рисунок 19. Бізнес-процес редагування картки учня. 65 Рисунок 20. Бізнес-процес створення картки співробітника. 66 Рисунок 21. Бізнес-процес редагування картки співробітника. 67 Рисунок 22. Бізнес-процес пошуку картки співробітника. 68 Рисунок 23. Прототип екранної форми створення ролі 70 Рисунок 24. Прототип екранної форми перегляду списку ролей. 72 Рисунок 25. Прототип екранної форми перегляду списку користувачів. 74 Рисунок 26. Прототип екранної форми перегляду інформації по користувачу. 76 Рисунок 27. Прототип екранної форми редагування інформації по користувачу. 77 Рисунок 28. Прототип екранної форми перегляду списку довідників. 78 Рисунок 29. Очікувана верхньорівнева архітектурна схема побудови рішення. 94 \\ ====== СПИСОК ТАБЛИЦЬ ====== Таблиця 1. Атрибути моделі даних Паспорт ЗО.. 31 Таблиця 2. Атрибути моделі даних Учень. 36 Таблиця 3. Атрибути моделі даних Співробітник. 39 Таблиця 4. Атрибути моделі даних Вихованець. 43 Таблиця 5. Атрибути сутності Роль. 47 Таблиця 6. Атрибути Користувача. 53 Таблиця 7 Атрибути довідників. 79 Таблиця 8 Параметри навантаження. 93 Таблиця 9. Календарний план надання послуг. 99 \\ \\ |====== ЛИСТ РЕЄСТРАЦІЇ ЗМІН ======| | | | | | | | |Зміна |Номери аркушів (сторінок)| | |Всього аркушів (сторінок) в документі|№\\ \\ документа|Вх. № супровідного документа та дата|Підпис і дата| | |Замінених |Введених|Вилучених| | | | | |\\ |\\ |\\ |\\ |\\ |\\ |\\ |\\ | \\ \\