що діє на підставі , з другої сторони, надалі Замовник і Виконавець також іменуються Сторона, а спільно Сторони, враховуючи результат проведення закупівлі: Розвиток інформаційної системи «Муніципальний Реєстр», 2 черга за кодом ДК 021:2015 (CPV)...

Додаток 5

до тендерної документації

ПРОЕКТ ДОГОВОРУ

ДОГОВІР №

про надання послуг

м. Київ             2018 р.

Комунальне підприємство «Головний інформаційно-обчислювальний центр» (надалі –

«Замовник»), в особі_             , який діє на підставі              , з

однієї сторони, та   (надалі – «Виконавець»), в особі

             , що діє на підставі              , з другої сторони, надалі Замовник і Виконавець також іменуються Сторона, а спільно Сторони, враховуючи результат проведення закупівлі: Розвиток інформаційної системи «Муніципальний Реєстр», 2 черга за кодом ДК 021:2015 (CPV) «Єдиний закупівельний словник» – 72210000-0 Послуги з розробки пакетів програмного забезпечення, керуючись Цивільним кодексом України, Господарським кодексом України, Законом України «Про публічні закупівлі» та іншими нормативно-правовими актами України, уклали цей Договір про нижченаведене.

1. ПРЕДМЕТ ДОГОВОРУ

1.1. Виконавець зобов’язується в порядку та на умовах визначених цим Договором надати Замовникові послуги, зазначені в п. 1.2 Договору, а Xxxxxxxx - прийняти і оплатити такі послуги.

1.2. Найменування послуги: Розвиток інформаційної системи «Муніципальний Реєстр», 2 черга за кодом ДК 021:2015 (CPV) «Єдиний закупівельний словник» – 72210000-0 Послуги з розробки пакетів програмного забезпечення.

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

1.4. Перелік та зміст послуги, що є предметом Договору, строки їх надання та вартість визначаються Календарним планом (Додаток 1 до Договору), який є невід’ємною частиною Договору.

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

2. ЯКІСТЬ ПОСЛУГИ ТА ГАРАНТІЙНІ ЗОБОВ’ЯЗАННЯ

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

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

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

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

3. ЦІНА ДОГОВОРУ ТА ПОРЯДОК РОЗРАХУНКІВ

3.1. Ціна даного Договору становить:           (           ) без ПДВ.

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

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

3.4. У випадку відсутності фінансування або його затримки, розрахунки за надані послуги затримуються до моменту надходження фінансування для оплати таких послуг.

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

4. ПОРЯДОК ТА СТРОКИ ПОСТАВКИ ПОСЛУГИ

4.1. Місце надання послуги: м. Київ, вул. Xxxxxxxx, 00 X, 00000.

4.2. Строк надання послуги: з дати отримання письмової заявки від Замовника та до 26 грудня 2018 року.

4.3. Виконавець приступає до надання послуг за цим Договором з дати отримання письмової заявки від Замовника.

4.4. Надання послуг за цим Договором здійснюється поетапно, згідно з Календарним планом.

4.5. Виконавець приступає до надання послуг за кожним етапом Календарного плану згідно з письмовою заявкою Замовника. У разі дострокового виконання поточного (чергового) етапу, Виконавець, за письмовою згодою Xxxxxxxxx, приступає до виконання наступного етапу Договору.

4.6. Перелік документації та результати послуг, що підлягають оформленню та здачі Виконавцем Xxxxxxxxx під час та по закінченні дії Договору, визначаються Календарним планом.

4.7. Вартість послуг, перелік послуг та документації за кожним етапом визначених Календарним планом може уточнюватись Замовником за письмовим погодженням з Виконавцем.

4.8. Приймання результатів наданих послуг здійснюється з урахуванням їх відповідності вимогам даного Договору, Календарному плану та Технічному завданню.

4.9. По завершенню кожного з етапів Договору Виконавець подає Замовнику протягом 5 (п’яти) днів Акт приймання-передачі наданих послуг за відповідним етапом з доданням результату відповідного етапу послуг згідно з Календарним планом.

4.10. Приймання та оцінка наданих послуг за етапом здійснюється впродовж 5 (п’яти) робочих днів з дня отримання Акту приймання-передачі наданих послуг комісією Замовника за участю Виконавця відповідно до Календарного плану та Технічного завдання. Робота комісії завершується складанням Протоколу з висновком про відповідність (невідповідність) наданих послуг Технічному завданню та Календарному плану, а також, у разі виявлення комісією невідповідностей вимогам Технічного завдання та Календарного плану, зазначенням переліку необхідних доопрацювань і строками їх виконання.

4.11. Замовник протягом 10 (десяти) робочих днів з дня отримання Акта приймання- передачі наданих послуг за відповідним етапом, зобов’язаний надіслати Виконавцю

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

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

4.13. Виконавець зобов’язаний, без додаткової оплати, протягом 10 (десяти) робочих днів або в інший узгоджений із Замовником строк відповідно до Акту з переліком необхідних доопрацювань вжити всіх заходів та усунути недоліки.

5. ПРАВА ТА ОБОВ'ЯЗКИ СТОРІН

5.1. Замовник зобов’язаний:

5.1.1. Своєчасно та в повному обсязі сплачувати вартість належним чином наданих послуг, з урахуванням п. 3.3.-3.5. Договору;

5.1.2. Приймати надані за етапами послуги згідно з Актами приймання-передачі наданих послуг;

5.1.3. На вимогу Xxxxxxxxx надавати йому інформацію, необхідну для надання послуг за цим Договором;

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

5.1.5. При встановлені недоліків та дефектів, виявлених під час використання результатів наданих послуг, невідкладно інформувати про це Виконавця.

5.2. Замовник має право:

5.2.2. Вимагати від Виконавця надання послуг у строки, встановлені цим Договором;

5.2.3. Контролювати якість та строки надання послуг за цим Договором;

5.2.4. Зменшувати в односторонньому порядку обсяг закупівлі послуг та, відповідно ціну цього Договору, залежно від реального фінансування видатків та потреб;

5.2.5. Повернути Виконавцю Акти приймання-передачі наданих послуг без здійснення оплати, в разі неналежного оформлення документів, зазначених у п. 4.6. Договору;

5.2.6. Вимагати від Виконавця надання послуг, якість яких відповідає умовам, встановленим цим Договором;

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

5.2.8. Вимагати від Виконавця безоплатного виправлення недоліків та дефектів, що виникли внаслідок допущених Виконавцем порушень, у т. ч. протягом гарантійного строку, зазначеного у п. 2.2., x. 2.3 даного Договору;

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

5.2.10. Вимагати від Виконавця відшкодування збитків, якщо вони виникли внаслідок невиконання або неналежного виконання Виконавцем взятих на себе зобов’язань за цим Договором.

5.3. Виконавець зобов’язаний:

5.3.1. Надати послуги у строки, встановлені Календарним планом;

5.3.2. Забезпечити надання послуг, якість та комплектність яких відповідає умовам, встановленим цим Договором, Технічному завданню та Календарному плану;

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

5.3.4. Оформлювати первинні бухгалтерські документи відповідно до вимог ст. 9 Закону України «Про бухгалтерський облік та фінансову звітність в Україні»;

.

5.4. Виконавець має право:

5.4.1. Своєчасно та в повному обсязі отримувати плату за надані послуги в порядку, визначеному цим Договором;

5.4.2. На дострокове надання послуг за письмовим погодженням Замовника;

5.4.3. Призупинити надання послуг по Договору у випадку порушення Замовником строків оплати наданих послуг по етапу згідно з Календарним планом, крім з причин визначених п.

3.3. - п. 3.5. Договору.

6. ПРАВА НА ОБ’ЄКТИ ІНТЕЛЕКТУАЛЬНОЇ ВЛАСНОСТІ

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

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

6.3. Передача Замовнику виключних майнових прав інтелектуальної власності на об’єкти права інтелектуальної власності (надалі – Твір) включає передачу (відчуження) Виконавцем Замовнику:

– виключного права на використання Твору;

– виключного права дозволяти використання Твору іншими особами;

– виключного права перешкоджати неправомірному використанню Твору, в тому числі забороняти таке використання, іншими особами;

– інших майнових прав інтелектуальної власності, встановлені законодавством України.

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

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

6.6. Строк дії майнових прав інтелектуальної власності Замовника на Твір дорівнює максимальному строку дії таких прав відповідно до чинного законодавства України.

6.7. Сторони домовилися, що оплата за передачу Замовнику майнових прав інтелектуальної власності на Твір (програмне забезпечення) та всі його компоненти (що розробляються на умовах даного Договору), включена до вартості послуг Виконавця згідно з цим Договором.

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

7. ВІДПОВІДАЛЬНІСТЬ СТОРІН

7.1. У разі невиконання або неналежного виконання своїх зобов’язань за Договором, Xxxxxxx несуть відповідальність, передбачену чинним законодавством України та цим Договором.

7.2. За порушення строків виконання зобов’язань за Договором більше, ніж на 10 (десять) робочих днів Виконавець сплачує Замовнику штраф у розмірі 1 % від вартості послуг, з яких допущено прострочення виконання.

7.3. У разі невиконання або неналежного виконання Виконавцем зобов’язань щодо якості наданих послуг та/або надання послуг, що не відповідають Технічному завданню, Замовник має право відмови від оплати за неякісно надані та/або надані з порушенням Технічного завдання послуги із звільненням Замовника від будь-якої відповідальності за такі дії.

8. ОБСТАВИНИ НЕПЕРЕБОРНОЇ СИЛИ

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

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

8.3. Доказом виникнення обставин непереборної сили та строку їх дії є відповідні документи, які видаються Торгово-промисловою палатою України або іншим компетентним органом.

8.4. У разі коли строк дії обставин непереборної сили продовжується більше ніж 30 днів, кожна із Сторін в установленому порядку має право розірвати цей Договір.

9. ВИРІШЕННЯ СПОРІВ

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

9.2. У разі недосягнення Сторонами згоди, спори (розбіжності) вирішуються у судовому порядку, згідно правил підвідомчості і підсудності, встановлених чинним законодавством України.

10. СТРОК ДІЇ ДОГОВОРУ

10.1. Договір набирає чинності з дати його підписання та скріплення печатками Xxxxxx (за їх наявності та у випадку використання печатки учасником в своїй господарської діяльності та при оформленні документів) і діє до 26 грудня 2018 року, а в частині розрахунків та гарантійних зобов’язань за даним Договором до повного виконання їх Сторонами.

10.2. Закінчення строку дії Договору не звільняє Xxxxxxx від відповідальності за його порушення, що мало місце під час дії Договору.

11. ІНШІ УМОВИ

11.1. Істотні умови Договору не можуть змінюватися після його підписання до виконання зобов’язань Cторонами в повному обсязі, крім випадків, передбачених статтею 36 Закону України «Про публічні закупівлі».

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

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

11.4. Жодна із Сторін не має права передавати свої права та обов’язки за Договором третім особам без письмової згоди на те іншої Сторони.

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

11.6. Сторони добровільно надають свою безумовну згоду на обробку будь-яких персональних даних, які стали відомими в результаті виконання цього договору. Обробка

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

11.7. Цей Договір складений при повному розумінні Сторонами його умов та термінології, українською мовою у двох автентичних примірниках, які мають однакову юридичну силу – по одному для кожної із Сторін.

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

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

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

11.11. Правовідносини сторін, не врегульовані положеннями цього Договору, регулюються нормами чинного в Україні законодавства.

11.12. Виконавець є платником податку                _.

11.13. Замовник є платником податку на прибуток на загальних підставах та платником ПДВ.

12. ДОДАТКИ ДО ДОГОВОРУ

12.1. Календарний план надання послуг.

12.2. Інформація про необхідні технічні, якісні, кількісні та інші характеристики предмета закупівлі (Технічні вимоги).

13. МІСЦЕЗНАХОДЖЕННЯ ТА РЕКВІЗИТИ СТОРІН

ЗАМОВНИК ВИКОНАВЕЦЬ

Додаток 1 до Договору №       від       

Календарний план надання послуг*

№ п/п	Назва послуги за етапом	Термін**	Результат	Вартість послуги без ПДВ, грн.
1	Розробка технічного завдання
	Розробка технічного	20 робочих днів з дати отримання письмової заявки від Замовника	Технічне завдання на модернізацію ІС «МР»
1.1	завдання на
	модернізацію
	ІС «МР»
	Розробка технічного	20 робочих днів з дати отримання письмової заявки від Замовника	Технічне завдання на створення ПМ «РД»
1.2	завдання на
	створення ПМ
	«РД»
2	Розробка програмного забезпечення
	Розробка	35 робочих	Дослідний зразок
	програмного	днів з дати	модернізованого
	забезпечення	отримання	програмного забезпечення
	щодо	письмової	ІС «МР» на площадці
	модернізації	заявки від	Замовника
	ІС «МР»	Замовника	Загальний опис системи
			(стосовно доопрацювань)
			Керівництво Системного
			адміністратора
2.1			(розширене)
			Програма та методика
			попередніх випробувань
			Протокол попередніх
			випробувань
			Акт прийняття в дослідну
			експлуатацію
			модернізованого
			програмного забезпечення
			ІС «МР»
	Розробка	35 робочих	Дослідний зразок
	програмного	днів з дати	програмного забезпечення
	забезпечення	отримання	ПМ «РД» на площадці
	ПМ «РД»	письмової	Замовника
		заявки від	Загальний опис ПМ «РД»
2.2		Замовника	Керівництво Системного
			адміністратора
			Інструкція з розгортання
			та налаштування
			(стосовно доопрацювань)
			Програма та методика

№ п/п	Назва послуги за етапом	Термін**	Результат	Вартість послуги без ПДВ, грн.
			попередніх випробувань Протокол попередніх випробувань Акт прийняття в дослідну експлуатацію програмного забезпечення ПМ «РД»
3	Дослідна експлуатація, розробка документації
3.1	Дослідна експлуатація модернізовано го програмного забезпечення ІС «МР», розробка документації	20 робочих днів з дати отримання письмової заявки від Замовника	Програма та методика дослідної експлуатації Інструкція з формування та ведення бази даних (стосовно доопрацювань) Керівництво Користувача (розширене) Керівництво Адміністратора (розширене) Протокол дослідної експлуатації
3.2	Дослідна експлуатація програмного забезпечення ПМ «РД», розробка документації	20 робочих днів з дати отримання письмової заявки від Замовника	Програма та методика дослідної експлуатації Інструкція з розгортання та налаштування Інструкція з формування та ведення бази даних Керівництво Користувача Керівництво Адміністратора Протокол дослідної експлуатації

* Учасник конкурсних торгів може надавати власний варіант календарного плану.

** Строк розробки та порядок надання ТЗ може бути змінено.

*** За рішенням Виконавця реалізація етапів може проводитися як послідовно один за одним так й одночасно.

ЗАМОВНИК ВИКОНАВЕЦЬ

Додаток 2 до Договору №       від       

ТЕХНІЧНІ ВИМОГИ

ІНФОРМАЦІЯ ПРО НЕОБХІДНІ ТЕХНІЧНІ, ЯКІСНІ ТА КІЛЬКІСНІ ХАРАКТЕРИСТИКИ ПРЕДМЕТУ ЗАКУПІВЛІ

Розвиток інформаційної системи «Муніципальний Реєстр», 2 черга за кодом ДК 021:2015 (CPV) «Єдиний закупівельний словник» – 72210000-0 Послуги з розробки пакетів програмного забезпечення

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

1.16 Напрямів діяльності та заходів Комплексної міської цільової програми «Електронна столиця» на 2015-2018 роки, затвердженої Рішенням Київської міської ради №654/1518 від 02 липня 2015 року та пункту 2 Переліку заходів з подальшого впровадження інформаційно- комунікаційних технологій у сфері життєдіяльності міста Києва на 2018 рік, затвердженому розпорядженням виконавчого органу Київської міської ради (Київської міської державної адміністрації) № 614 від 11 квітня 2018 року.

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

1.1. Загальні положення

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

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

1.2. Мета розвитку ІС «МР»

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

Метою модернізації ІС «МР» є розширення функціональності Системи, а саме:

1) інтеграція з зовнішніми інформаційними системами (далі – ЗІС):

− Інформаційною системою «Реєстр територіальної громади міста Києва» (далі РТГК);

− Інформаційними системами, які надають соціальні сервіси для жителів міста Києва (далі – ІС «НСС»);

− Електронного запису дітей до дошкільних навчальних закладів комунальної власності територіальної громади міста Києва, запровадженого згідно з розпорядженням виконавчого органу Київської міської ради (Київської міської державної адміністрації) від 23 травня 2013 року № 760 «Про запровадження електронного запису дітей до дошкільних навчальних закладів комунальної власності територіальної громади міста Києва» (далі – Електронна черга).

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

2) розробка програмного модулю «Реєстр дітей» (далі – ПМ «РД» або Модуль) для реалізації інформаційної технології обліку:

− дітей шкільного віку та учнів, що ведеться з метою забезпечення здобуття ними загальної середньої освіти у відповідності до Постанови Кабінету Міністрів України від 13 вересня 2017 року №684 і дітей дошкільного віку;

− дітей, які потребують здобуття дошкільної освіти у дошкільних навчальних закладах територіальної громади міста Києва (далі – ДНЗ).

1.3. Призначення модернізації ІС «МР»

ІС “МР” – це автоматизована система управління Реєстром громадян міста Києва, а також реєстром операцій їх активності в інформаційних системах міста Києва.

Призначення ІС “МР” – збір та зберігання даних для створення реєстру громадян м. Києва (Муніципального реєстру) а також створення єдиної централізованої бази операцій їх активності в інформаційних системах м. Києва.

Призначення розробки ПМ «РД» ІС “МР” – збір та зберігання даних для створення реєстру дітей дошкільного, шкільного віку та учнів з урахуванням їх місця реєстрації та обміну даними про них в інтересах функціонування електронних сервісів міста.

1.4. Склад Послуг, що надаються

Нижче надано перелік послуг з модернізації ІС «МР».

1.4.1 Склад послуг з модернізації ІС «МР»

В межах надання послуг з модернізації ІС «МР» повинні бути здійснені наступні заходи:

− розробка програмних компонентів для забезпечення отримання даних з РТГК до МР;

− розробка програмних компонентів для забезпечення отримання даних з ІС «НСС» до МР;

− розробка програмних компонентів для забезпечення сервісу обміну даних МР з Електронною чергою;

− модернізація сервісу обміну даними про мешканців міста МР з ЗІС;

− модернізація бази даних МР та розширення профайлу жителя за рахунок даних з РТГК, даних з ІС «НСС», даних з Електронної черги.

1.4.2 Склад послуг з розробки ПМ «РД» ІС «МР»

В межах розробки ПМ «РД» повинні бути створені наступні компоненти:

− компонент «Загальноосвітній навчальний заклад» (далі – ЗНЗ), що складається з програмних підсистем:

o Паспорт ЗНЗ;

o Співробітник ЗНЗ;

o Учень ЗНЗ;

− компонент «Дошкільний навчальний заклад (» (далі – ДНЗ), що складається з програмної підсистеми:

o Вихованець ДНЗ;

− компонент «Районне управління» (далі – РУ), що забезпечує облік ЗНЗ та ДНЗ на районному рівні;

− компонент «Департамент освіти і науки, молоді та спорту» (далі – ДОНМС), що забезпечує облік ЗНЗ та ДНЗ на міському рівні;

− забезпечення можливості використання веб-рішення «Крипто Автограф» для механізму ідентифікації через ЕЦП;

− програмна підсистема обміну даними з РТГК;

− програмна підсистема обміну даними з Електронною чергою;

− підсистема адміністрування.

1.5. Цілі

1.5.1. Цілі інтеграції МР із зовнішніми системами

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

− Можливість он-лайн отримання з РТГК та зберігання в МР даних про дітей шкільного віку та учнів, які зареєстровані в місті Києві.

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

− Взаємодію МР з ІС «НСС», що дозволить надавати доступ до даних про пільги жителів, з можливістю подальшого їх використання зовнішніми інформаційними системам міста, якщо житель міста Києва надав відповідну згоду на поширення персональних даних під час:

o використання Сервісу авторизації ОКК, коли користувався електронним муніципальним сервісом;

o відкриття соціальної картки в банківських структурах.

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

− Взаємодію ІС «МР» з Електронною чергою що сприятиме обміну даними Електронної черги з МР, якщо житель міста Києва надав відповідну згоду на поширення персональних даних під час використання Сервісу авторизації ОКК, коли користувався електронним муніципальним сервісом.

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

1.5.2 Цілі створення ПМ «РД»

В рамках розробки будуть розроблені сервіси:

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

o можливість обліку, управління та надання достовірних даних стосовно ЗНЗ територіальної громади міста Києва;

o можливість обліку та управління даними про співробітників ЗНЗ міста Києва;

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

− Компонент ДНЗ забезпечить:

o можливість обліку та управління даними про дітей, які потребують дошкільної освіти та навчаються у ДНЗ територіальної громади міста Києва;

o надання оперативних і достовірних відомостей щодо дітей дошкільного віку, які навчаються у ДНЗ територіальної громади міста Києва.

− Xxxxxxxxx XX забезпечить:

o можливість обліку, управління, надання оперативних та достовірних даними про дітей, які навчаються у ДНЗ територіальної громади міста Києва на районному рівні;

o можливість обліку, управління, надання оперативних та достовірних даних стосовно ЗНЗ на районному рівні;

o можливість обліку, управління, надання оперативних та достовірних даних про співробітників ЗНЗ на районному рівні;

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

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

o можливість обліку та управління даними про дітей, які навчаються у ДНЗ територіальної громади міста Києва на міському рівні;

o можливість обліку, управління та надання достовірних даних стосовно ЗНЗ на міському рівні;

o можливість обліку та управління даними про співробітників ЗНЗ на міському рівні;

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

− Програмна підсистема обміну даними з РТГК забезпечить обмін даними ПМ

«РД» з РТГК;

− Програмна підсистема обміну даними з Електронною чергою забезпечить обмін даними ПМ «РД» з Електронною чергою;

− Підсистема адміністрування забезпечить можливостями налаштування довідників та налаштування рольової моделі користувачів.

1.6. Терміни, визначення та скорочення

Терміни	Визначення
Access token	Ключ, що формується в результаті авторизації. Містить інформацію з безпеки сеансу та ідентифікує користувача, зовнішню систему та призначені для них привілеї.
API	Прикладний програмний інтерфейс (Application Programming Interface, API) – набір запитів відповідної структури до сторонніх систем та сайтів.
BankID	Спосіб електронної ідентифікації користувачів через українські банки для надання адміністративних та інших послуг через Інтернет.
ID карта	Нова форма паспорта громадянина України з безконтактним електронним носієм. У паспорт у формі картки вноситься наступна інформація: назва держави, назва документа, ім'я (з латинською транслітерацією, яку можна узгодити відповідно до інших документів, наприклад, посвідчення водія), стать, DATA народження, унікальний номер запису в Єдиному державному демографічному реєстрі, номер самого документа, DATA його видачі і закінчення терміну його дії, код уповноваженого суб'єкта, який видав паспорт, місце народження, оцифроване зображення обличчя та підпис власника картки.
KyivID	Унікальний ідентифікатор, який присвоюється користувачу, що є одержувачем (зокрема потенційним одержувачем) послуг, заходів соціальної підтримки, та служить персональним електронним ключем.
OAuth 2.0	OAuth (англ. Open Authorization) – протокол авторизації, який дозволяє користувачам надавати доступ до своїх даних, що зберігаються на одному веб-ресурсі, іншому веб-ресурсу, без

Терміни	Визначення
	необхідності вводу імені та паролю користувача.
Автентифікація	Електронна процедура, яка дає можливість підтвердити електронну ідентифікацію фізичної особи та/або походження і цілісність електронних даних.
Авторизація	Процес надання особі/процесу прав на виконання певних дій або доступу до ресурсів, а також процес перевірки (підтвердження) прав при спробі виконання цих дій.
Адміністративний район	Адміністративно-територіальний устрій Києва, який поділяється на десять адміністративних міських районів, утворених за радіальним принципом і назв за географічним принципом (окрім Шевченківського району, названого на честь Xxxxxx Xxxxxxxx).
Адреса	Структурований опис сукупності реквізитів місця розташування об’єкта нерухомості жилого фонду на місцевості, що однозначно визначає даний об’єкт. Повна адреса складається з назви країни, індексу поштового відділення, назви обласного центру, назви районного центру, назви вулиці, номера будівлі, споруди, майнового комплексу. Номер об'єкта нерухомості позначається відповідною арабською цифрою. Наприклад: Повна адреса: Xxxxxxx, 00000, Xxxxxxxxxxxx xxxxxxx, Xxxxxxxxxx xxxxx, xxxxx Xxxxx, вулиця Xxxxx Xxxxx, будинок 27. Скорочена адреса: Україна, 16600, Чернігівська обл., Ніжинський р- н, м. Ніжин вул. І. Пулюя, буд. 27.
Адреса реєстрації	Адреса реєстрації місця проживання / місця перебування жителя по відповідному адресу об’єкта нерухомості жилого фонду м. Києва, тобто створений обліковий запис в РТГК.
Банк емітент	Банк, який здійснив випуск Соціальної карти.
Будинок	Номер будинку – це складова частина адреси.
Вулиця	Назва вулиці – це складова частина адреси.
Вчитель, співробітник	Спеціаліст, який проводить навчальну та виховну роботу з учнями в загальноосвітніх школах.
Вихованець	Дитина, у віці 2-7 років, яка перебуває в дошкільних навчальних закладах.
Громадянин x. Києва	Xxxxxxxxxx, який зареєстрований, мешкає, працює у м. Києві, гості м. Києва.
Громадянство	Громадянство – це постійний політико-правовий зв'язок особи з державою, який зумовлює наявність у них взаємних прав, свобод, законних інтересів та обов'язків, як на території країни, так і за її межами.
DATA народження	День, місяць та рік народження жителя.
DATA реєстрації	День, місяць та рік реєстрації місця проживання / місця перебування жителя по відповідному адресу об’єкта нерухомості жилого фонду

Терміни	Визначення
	м. Києва, тобто створення облікового запису в РТГК.
ДНЗ, дошкільний навчальний заклад	Навчальний заклад, що забезпечує реалізацію права дитини на здобуття дошкільної освіти, її фізичний, розумовий і духовний розвиток, соціальну адаптацію та готовність продовжувати освіту.
Документ	Довідник який містить наступні офіційні документи: - Паспорт; - Свідоцтво про народження; - ID карта.
ІАА	Ідентифікації → Автентифікації → Авторизації
Ідентифікація	Процедура розпізнавання користувача в системі, як правило, за допомогою наперед визначеного імені (ідентифікатора), або іншої апріорної інформації про нього, яка сприймається системою. Залежно від ситуації, це може бути ім’я, адреса електронної пошти, номер облікового запису і т.д.
Ім’я	Ім’я – це особиста назва людини, що дається їй після народження. Ім’я – це частина повного імені жителя.
ІПН	ІПН – це цифровий код, необхідний кожному платнику податків для обліку в фіскальних органах. Протягом усього життя, РНОКПП (Реєстраційний номер облікової картки платника податків або ІПН) не змінюється (крім випадків пов'язаних з релігійними переконаннями).
ІС «НСС»	Інформаційна система надання соціальних сервісів.
ЕКГ	Електронна картка громадянина. Картка для обліку місця реєстрації жителя в системі РТГК.
Електронна черга	Інформаційно-телекомунікаційної система електронного запису до закладів дошкільної освіти.
Житель	Громадянин, який має реєстрацію місця проживання / місця перебування по відповідному адресу об’єкта нерухомості житлового фонду м. Києва, тобто створений обліковий запис в РТГК.
Загальний стаж	Xxxxxxx тривалість роботи робітником або службовцем, або в іншій суспільно-корисній діяльності, якщо їх включення в трудовий стаж передбачено чинним законодавством.
ЗНЗ, загально освітній навчальний заклад	Навчальний заклад, що забезпечує реалізацію права громадян на загальну середню освіту.
Зовнішня інформаційна система, ЗІС	Система або модуль, що інтегрований з МР.
Кваліфікація	Довідник який включає наступні види кваліфікації: - Кваліфікований робітник; - Молодший спеціаліст (молодший бакалавр); - Бакалавр; - Магістр.

Терміни	Визначення
Кваліфікаційна категорія	Довідник який включає наступні види кваліфікаційних категорій: - Спеціаліст; - Спеціаліст другої категорії; - Спеціаліст першої категорії; - Спеціаліст вищої категорії.
Квартира	Квартира – ізольоване помешкання в жилому будинку, призначене для проживання фізичних осіб. Номер квартири – це складова частина адресу.
КМДА	Київська міська державна адміністрація.
КОАТУУ	Класифікатор об'єктів адміністративно-територіального устрою України.
Країна	Країна – це політичне, національне, соціальне, культурне, господарське співтовариство, організоване державою на певній території. Визначена територія, що становить єдність з погляду історії, природних умов, населення (спільноти людей, що проживають на цій території), що в політико-географічному відношенні мусить мати державний суверенітет. Назва країни – це складова частина адреси.
Літера будинку	Xxxxxx будинку – це складова частина адресу. Якщо на відповідній вулиці збудовано нові об'єкти та їм, виходячи з уже наявної нумерації об'єктів нерухомого майна по вулиці, на якій вони фактично знаходяться, неможливо надати номер, який є цілим INTм, такий об'єкт нерухомого майна при наданні поштової адреси позначається номером найближчого об'єкта нерухомого майна по відповідному боку вулиці в бік зменшення (можливо, і збільшення) з відповідною заголовною літерою через дефіс. Наприклад: Повна поштова адреса: xxxxxx Xxxxx Xxxxx, xxxxxxx 00-x, Скорочена поштова адреса: вул. І. Пулюя, буд. 25-а.
Місце народження	Місце, де був народжений суб'єкт, тобто житель.
МР	Інформаційна система «Муніципальний реєстр» – це автоматизована система управління реєстром громадян міста Києва, а також реєстром операцій їх активності в інформаційних системах міста Києва.
МР ID (МР ID.ОС)	Універсальна освітня складова, що міститиме інформацію про освітню активність киянина.
МР ID (МР ID.СС)	Універсальна соціальна складова, що міститиме інформацію про права киянина на соціальну допомогу, отриману від спеціалізованих систем, функціонуючих в рамках чинного законодавства.
Модель даних	Інструмент представлення концептуальної моделі предметної області і динаміки її розвитку у вигляді бази даних.
Модуль	Функціональна частина системи, яка виконує певну функцію, має закінчене оформлення та засоби сполучення з іншими частинами.

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

Терміни	Визначення
	- Викладач-методист - Учитель-методист - Вихователь-методист - Педагог-організатор — методист - Практичний психолог — методист - Керівник гуртка — методист - Старший вожатий — методист - Старший викладач - Старший учитель - Старший вихователь - Майстер виробничого навчання I категорії - Майстер виробничого навчання II категорії
Педагогічний стаж	Сумарна тривалість трудової діяльності працівників в освітніх закладах на посадах, пов’язаних з навчальним процесом.
Пенсійний стан	Довідник, який включає наступні види пенсійного стану: - Не пенсіонер; - Пенсіонер; - Передпенсійний.
Платформа	Єдина міська платформа електронної взаємодії, управління даними та сервісами.
По батькові	Xx’x по батькові – це вид антропоніма (патронім), утворений від офіційного імені батька за допомогою суфіксів -ич(-іч), -ович (для чоловіків) та -івна (для жінок). Ім’я по батькові – це частина повного імені жителя.
Постановка на обліку	Довідник який містить наступні види постановки на облік: - на обліку не стоїть; - на обліку в службі у справах неповнолітніх; - на обліку в Кримінальній поліції.
Посада	Визначена структурою і штатним розписом первинна структурна одиниця державного або муніципального органу та його апарату, на яку покладено встановлене нормативними актами коло службових повноважень. Визначається згідно Типових штатних нормативів закладів загальної середньої освіти.
Прізвище	Прізвище – це найменування особи, набуте при народженні або вступі в шлюб, що передається від покоління до покоління і вказує на спорідненість. Прізвище – це частина повного імені жителя.
Профайл	Набір даних про жителя.
Профіль навчання	Довідник який містить наступні профілі навчання: - фізико-математичний; - математичний; - фізичний; - екологічний; - біолого-хімічний; - біолого-фізичний (в тому числі медичний);

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

Терміни	Визначення
	видалення профілю Користувача ОКК.
Соціальна карта	Іменна багатофункціональна електронна пластикова картка, яка видається мешканцю міста, що є одержувачем (зокрема потенційним одержувачем) заходів соціальної підтримки, та служить персональним електронним ключем до інформації про наявні заходи соціальної підтримки утримувача карти і дозволяє використовувати різні додатки, пов'язані з наданням і обліком заходів соціальної підтримки.
Соціальний статус дитини	Довідник який містить наступні соціальні статуси дитини: - Дитина-сирота; - Дитина, позбавлена батьківського піклування; - прийомна сім’я; - Дитячий будинок сімейного типу; - Дитина, батьки якої загинули при виконанні службових обов’язків; - Дитина-інвалід; - Дитина з обмеженими можливостями; - Дитина, яка постраждала від наслідків аварії на ЧАЕС; - Багатодітна сім’я; - Неповна сім’я; - Малозабезпечена сім’я; - Сім’ї трудових мігрантів; - Сім’ї, які опинилися у складних життєвих обставинах; - Переселенець; - Біженець.
Спеціальність	Комплекс набутих людиною знань і практичних навичок, що дає їй можливість займатися певним родом занять у якійсь галузі діяльності.
Стать	Біологічно (генетично) зумовлений поділ осіб на чоловіків, жінок та невизначено.
Табельний номер	Порядковий номер учня в шкільному класному журналі.
УНЗР	Унікальний номер запису в Єдиному державному демографічному реєстрі, який містить тринадцять цифр, який представлений двома послідовностями з восьми та п'яти цифр, розділених текстовим символом "-".
Учень	Особа, у віці 6-18 років, яка здобуває загальну середню освіту у загальноосвітньому навчальному закладі.
Характер зарахування	Довідник який визначає характер зарахування вчителя на посаду: - основний; - сумісний; - пенсіонер; - молодий спеціаліст.
Хронічні захворювання	Довідник, що відповідає класифікатору міжнародної статистичної класифікації хвороб та споріднених проблем охорони здоров'я МКХ- 10 (ICD-10).
Форма навчання учня	Довідник який містить наступні форми навчання учня:

Терміни	Визначення
	- в учбовому закладі; - індивідуальне.
Школа	Загальноосвітній навчальний заклад.

2. ВИМОГИ ДО ЧИННОГО ЗАКОНОДАВСТВА

Модернізація ІС «МР» повинна відповідати вимогам чинних нормативно-правових документів, а саме:

• Конституції України;

• Закону України «Про внесення змін до деяких законодавчих актів України щодо розширення повноважень органів місцевого самоврядування та оптимізації надання адміністративних послуг»;

• Закону України «Про Єдиний державний демографічний реєстр та документи, що підтверджують громадянство України, посвідчують особу чи її спеціальний статус»;

• Закону України «Про адміністративні послуги»;

• Закону України «Про інформацію»;

• Закону України «Про електронні документи та електронний документообіг»;

• Закону України «Про доступ до публічної інформації»;

• Закону України «Про захист інформації в інформаційно-телекомунікаційних системах»;

• Закону України «Про електронний цифровий підпис»;

• Закону України «Про захист персональних даних»;

• Закону України «Про свободу пересування та вільний вибір місця проживання в Україні»;

• Закону України «Про внесення змін до деяких законодавчих актів України щодо документів, що підтверджують громадянство України, посвідчують особу чи її спеціальний статус, спрямованих на лібералізацію Європейським Союзом візового режиму для України»;

• Постанови Кабінету Міністрів України від 28.10.2004 № 1452 «Про затвердження Порядку застосування електронного цифрового підпису органами державної влади, органами місцевого самоврядування, підприємствами, установами та організаціями державної форми власності»;

• Постанови Кабінету Міністрів України від 29.03.2006 № 373 «Про затвердження Правил забезпечення захисту інформації в інформаційних, телекомунікаційних та інформаційно-телекомунікаційних системах»;

• Наказу Державного комітету інформаційної політики, телебачення і радіомовлення України, Державного комітету зв'язку та інформатизації України 25.11.2002 № 327/225. «Порядок функціонування веб-сайтів органів виконавчої влади» Із змінами, внесеними згідно з Наказом Державного комітету телебачення і радіомовлення № 24/26 від 16.02.2015;

• Постанови Кабінету Міністрів України від 12.04.2002 № 522 «Про затвердження Порядку підключення до глобальних мереж передачі даних»;

• Постанови Кабінету Міністрів України від 10.09.2003 № 1433 «Про затвердження Порядку використання комп'ютерних програм в органах виконавчої влади»;

• ДСТУ 2394-94 «Інформація та документація. Комплектування фонду, бібліографічний опис, аналіз документів. Терміни та визначення»;

• НД ТЗІ 1.1-003-99. Термінологія в галузі захисту інформації у комп’ютерних системах від несанкціонованого доступу;

• НД ТЗІ 1.4-001-2000. Типове положення про службу захисту інформації в автоматизованій системі;

• НД ТЗІ 2.5-004-99. Критерії оцінки захищеності інформації у комп’ютерних системах від несанкціонованого доступу;

• НД ТЗІ 2.5-005-99. Класифікація автоматизованих систем і стандартні функціональні профілі захищеності оброблюваної інформації від несанкціонованого доступу (зі

Зміною №1, затвердженою наказом Адміністрації Держспецзв’язку від 15.10.2008 № 172);

• НД ТЗІ 3.6-001-2000. Технічний захист інформації. Комп’ютерні системи. Порядок створення, впровадження, супроводження та модернізації засобів технічного захисту інформації від несанкціонованого доступу;

• НД ТЗІ 3.7-001-99. Методичні вказівки щодо розробки технічного завдання на створення комплексної системи захисту інформації в автоматизованій системі;

• НД ТЗІ 3.7-003-05. Порядок проведення робіт із створення комплексної системи захисту інформації в інформаційно-телекомунікаційній системі;

• ДСТУ 3396.0-96 «Захист інформації». Технічний захист інформації. Основні положення»;

• ДК 010-98 «Державний класифікатор управлінської документації»;

• ДСТУ ISO/IEC 12207:2014 “Інженерія систем і програмного забезпечення. Процеси життєвого циклу програмного забезпечення”;

• ДСТУ 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. Методичні вказівки. Інформаційна технологія. Комплекс стандартів і керівних документів на автоматизовані системи. Автоматизовані системи. Вимоги до змісту документів;

• РД 00-000-00. Методичні вказівки. Інформаційна технологія. Комплекс стандартів і керівних документів на автоматизовані системи. Загальні положення.

Даний список нормативно-правових документів не є вичерпним. Вимоги Законодавства України, нормативних та керівних документів, що стосуються мети та призначення розвитку ІС «МР» повинні бути уточнені при розробці Технічного завдання.

3. ФУНКЦІОНАЛЬНІ ВИМОГИ ЩОДО МОДЕРНІЗАЦІЇ СИСТЕМИ

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

Модернізація ІС «МР» повинно базуватись на використанні підходів та методів модернізації з використанням сучасних веб-портальних та сервісно-орієнтованих технологій.

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

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

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

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

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

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

• РТГК;

• ІС «НСС»;

• Електронна черга.

3.2. Вимоги до функціонального рішення інтеграції МР та РТГК

3.2.1. Опис функціонального рішення

Функціональне рішення виконується за рахунок реалізації налагодженого механізму взаємодії РТГК з МР.

РТГК містить структуровані дані про жителів, а саме:

• особисті дані жителів;

• дані документів;

• дані по реєстрації;

• місце народження.

Кожен з цих параметрів має свою внутрішню структуру (перелік атрибутів). Всі разом вони утворюють структуру «Житель. РТГК».

Муніципальний Реєстр в рамках модернізації 2-ї черги повинен забезпечувати:

• Сервіс управління обміном даними з РТГК;

• Сервіс управління зберіганням даних;

• Сервіс управління обміном даними з ЗІС.

Механізм управління доступний за рахунок реалізації API для отримання даних про жителя міста з РТГК до МР. ІАА між РТГК та МР реалізується на основі протоколу OAuth

2.0. Отримання даних з РТГК завершується їх записом до МР у відповідний розділ профайлу жителя.

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

3.2.2. Схема інтеграції МР з РТГК

Функціональне рішення щодо інтеграції МР з РТГК та надання даних про жителів зовнішнім системам представлено на Рисунок 1.

РТГК

Особисті дані Дані документів

Місце народження Xxxx по реєстрації

Запит даних

про жителів

Дані про жителів

Оновлення даних

Запит даних про жителів

Дані про жителів

МР

Управління обмІном даними з РТГК Управління зберіганням даних в МР

Управління обміном даними з ЗІС

Зовнішня система

Рисунок 1. Схема отримання даних про жителів з РТГК. Модель даних, отриманих з РТГК

Модель даних це група параметрів, що безпосередньо стосується сутності «Житель. РТГК» і утворюють логічну структуру. Структура моделі даних сутності «Житель. РТГК» представлена на Рисунок 2.

ЗІС в якій надана згода

Посилання на текст згоди

Час згоди

Дата дії

Дата згоди

Населений пункт

Xxx xxxxxxx

Район

Дата видачі

Згода на обробку даних

Область

Номер

Дата реєстрації

Країна

Серія

Квартира

Місце народження

Тип документу

Літера будинку

Дані документів

Будинок

Вулиця

Місце народження

Громадянство

Адміністративний район

Згода на обробку даних

Дата народження

Населений пункт

УНЗР

Стать

Район

Дані по реєстрації

По-батькові

Область

Дані документів

Ім'я

Країна

Особисті дані

Прізвище

Дані по реєстрації

Житель. РТГК

Особисті дані

Рисунок 2. Структура моделі сутності «Житель. РТГК»

Атрибути сутності Житель в системі РТГК представлені в Таблиця 1.

Таблиця 1 - Атрибути сутності Житель. РТГК

Назва атрибуту	Тип даних	Обов’язковий / Необов’язковий*	Коментарі
Особисті дані
Прізвище	XXXXXXX	Xxxxxx’xxxxxxx	Якщо громадянство не України, то Прізвище необов’язкове
Ім’я	VARCHAR	Необов’язковий	Якщо Громадянство не Україна, то Ім’я необов’язкове
По-батькові	VARCHAR	Xxxxxx’xxxxxxx
DATA народження	DATA	Необов’язковий	Формат дд/ММ/рррр
Стать	XXXXXXX	Xxxxxx’xxxxxxx
Громадянство	VARCHAR	Необов’язковий
Дані документів
Тип документу	VARCHAR	Необов’язковий	Паспорт, Свідоцтво про народження, військовий квиток інше
Серія	VARCHAR	Необов’язковий	Якщо Тип документу = ID карта (пластиковий паспорт), то Серія не заповнюється
Номер документу	VARCHAR	Необов’язковий
DATA видачі	DATA	Необов’язковий
Ким виданий	VARCHAR	Необов’язковий	Якщо Тип документу = ID

Назва атрибуту	Тип даних	Обов’язковий / Необов’язковий*	Коментарі
			карта (пластиковий паспорт), то Ким виданий заповнюється ХХХХ цифрами
DATA дії	VARCHAR	Необов’язковий	Дата закінчення дії. Якщо Тип документу = ID карта (пластиковий паспорт), то DATA дії заповнюється: DATA видачі + 10 років.
УНЗР	INT (13)	Необов’язковий	13 цифр
Дані по реєстрації
Країна	VARCHAR	Обов’язковий
Область	VARCHAR	Обов’язковий
Район	VARCHAR	Необов’язковий
Населений пункт	VARCHAR	Обов’язковий
Адміністративний район	VARCHAR	Необов’язковий
Вулиця	XXXXXXX	Xxxx’xxxxxxx
Будинок	INT	Обов’язковий
Літера будинку	XXXXXXX	Xxxxxx’xxxxxxx
Квартира	INT	Xxxxxx’xxxxxxx
DATA реєстрації	DATA	Обов’язковий
Місце народження
Країна	VARCHAR	Необов’язковий
Область	VARCHAR	Необов’язковий
Район	VARCHAR	Необов’язковий
Населений пункт	VARCHAR	Необов’язковий
Згоду на обробку персональних даних
DATA надання згоди	VARCHAR	Обов’язковий
Час надання згоди	VARCHAR	Обов’язковий
Посилання на текст згоди	XXXXXXX	Xxxx’xxxxxxx
ЗІС в якій користувач надав згоду	VARCHAR	Необов’язковий

*Необов’язковий – мається на увазі, при реєстрації може бути заповнений пізніше.

3.2.3 Розробка програмних компонентів для забезпечення отримання даних з РТГК до МР

Механізм програмного інтерфейсу повинен забезпечувати можливість отримання даних про жителів міста з РТГК до МР.

Коректна робота програмного інтерфейсу повинна забезпечувати функціональність:

• Отримання оновлених даних від РТГК по жителям міста, які надали згоду на передачу даних з РТГК, або надання яких відповідає чинному законодавству. В рамках оновлення МР отримує від РТГК наступні дані:

- особисті дані;

- дані документів;

- дані по реєстрації;

- місце народження;

• Надсилання запиту даних від МР до РТГК про жителів які дозволили передачу в МР своїх персональних даних. В рамках запиту МР дає наступні дані:

- номер запит;

- підтвердження наявності згоди на обробку даних

- УНЗР;

- ПІБ + серія та номер документу;

• Надсилання відповіді від РТГК до МР. В рамках відповіді РТГК дає наступні дані:

- номер запиту

- особисті дані;

- дані документів;

- дані по реєстрації;

- місце народження.

Повний перелік можливих даних описує модель даних сутності «Житель. РТГК» в системі РТГК.

Результатом успішного завершення процесу є отримання та запис даних у відповідний розділ профайлу.

Детальні вимоги повинні бути викладені в Технічному завданні.

3.2.3.1 Вимоги до отримання даних з РТГК до МР по факту їх оновлення

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

На стороні РТГК після отримання токену формуються та надсилаються змінені дані (особисті дані, дані документів, дані реєстрації та/ або дані про місце народження) до МР.

В МР проводиться розшифровка access token. Якщо розшифровка не успішна, процес завершується остаточно. По факту позитивного результату розшифровки здійснюється пошук жителя в МР по даним РТГК (УНЗР/ ПІБ+документ/ ПІБ+DATA народження).

Для випадків коли жителя не знайдено (по запитуваним даним УНЗР/ ПІБ+документ/ ПІБ+DATA народження) в Системі, створюється профайл жителя та заповнення даними

«Житель. РТГК» і процес завершується остаточно.

Для випадків коли жителя знайдено в Системі, відбувається наповнення профайлу жителя в частині даних «Житель. РТГК» і процес завершується остаточно.

3.2.3.2 Вимоги до отримання даних з РТГК до МР при наданні особистої згоди жителем міста

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

Негативний результат перевірки призводить до остаточного завершення процесу. По факту позитивного результату перевірки генерується та відправляється access token.

В Системі по факту отримання access token надсилається запит та access token до РТГК. В РТГК здійснюється розшифровка токену і, в разі якщо розшифровка не успішна, процес завершується остаточно. По факту позитивного результату розшифровки здійснюється пошук жителя в РТГК. Для здійснення пошуку залучаються наступні дані:

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

3.2.4. Модернізація бази даних МР

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

• особисті дані жителя;

• дані документа;

• місце реєстрації жителя;

• місце народження жителя;

• згода на надання даних.

Повний перелік можливих даних описує модель даних сутності Житель в системі РТГК. Дані можуть бути уточнені в Технічному завданні.

3.2.5 Модернізація сервісу обміну даними про жителів міста МР з ЗІС

В рамках модернізації Системи повинен бути модернізований API МР для можливості надання ЗІС наступних даних про жителів міста:

• особисті дані;

• дані про документи;

• дані по реєстрації;

• дані про місце народження.

• згода на надання даних.

Повний перелік даних, які можуть бути надані ЗІС, описаний у моделі даних сутності

«Житель. РТГК». Надання ЗІС даних з РТГК повинно відбуватися виключно у відповідності з чинним законодавством.

Дані можуть бути уточнені в Технічному завданні.

3.3 Вимоги до функціонального рішення взаємодії МР з ІС «НСС»

3.3.1 Опис функціонального рішення

Функціональне рішення виконується за рахунок реалізації налагодженого механізму взаємодії ІС «НСС» з МР.

Соціальна картка (далі – СК) ІС «НСС» містить структуровані дані про жителів, а

саме:

• ідентифікатор мешканця;

• особисті дані;

• дані документів;

• ІПН;

• дані по реєстрації;

• контактні дані;

• дані по соціальній карті.

Кожен з цих параметрів, в свою чергу, має свою внутрішню структуру (перелік

атрибутів). Всі разом вони утворюють структуру «Житель. СК».

Муніципальний Реєстр в рамках доопрацювання 2-ї черги повинен забезпечувати:

• Сервіс управління обміном даними;

• Сервіс управління зберіганням даних;

• Сервіс управління обміном даними з ЗІС.

3.3.2 Схема інтеграції МР з ІС «НСС»

Отримання даних з ІС «НСС» до МР та надання цих даних зовнішнім інформаційним системам міста описана на Рисунок 3.

Дані про

жителів

Запит даних про жителів

Дані про жителів

МР

Управління обмІном даними з ІС «НСС»

Управління зберіганням

даними в МР

Управління обміном даними з ЗІС

ІС «НСС»

Особисті дані жителя Дані документів

Дані по реєстрації Контактні дані Дані про пільги

Дані по соціальній карті

Зовнішня інфор-

маційна система

Рисунок 3. Схема отримання даних з ІС «НСС» та надання їх зовнішнім інформаційним системам міста

3.3.3 Модель даних, отриманих з ІС «НСС»

Модель даних це група параметрів, що безпосередньо стосується сутності «Житель. СК» і утворюють логічну структуру. Структура моделі даних сутності «Житель. СК» в ІС

«НСС» представлена на Рисунок 4.

Коди категорій пільговика

Адреса електронної пошти

Номер рахунку банку

Xxx xxxxxxx

Номер мобільного телефона

Назва банка-емітента

Дата видачі

Номер карткового рахунку

Контактні дані

Номер

Кінцева дата дії карти

Серія

Номер карти

Поштовий індекс

Тип документу

Дані по соціальній карті

Квартира

Паспортні дані

Літера будинку

Дані по соціальній картці

Будинок

Контактні дані

Вулиця

Дані по реєстрації

Дата народження

КОАТУУ адміністративного

району

ІПН

Стать

Адміністративний район

Дані документів

По-батькові

КОАТУУ населенного пункта

Особисті дані

Ім'я

Населений пункт

Ідентифікатор мешканця

Прізвище

Дані по реєстрації

Житель. СК

Особисті дані

Рисунок 4. Структура моделі даних сутності «Житель. СК» в ІС «НСС»

Атрибути сутності «Житель. СК» представлені в Таблиця 2.

Таблиця 2 - Атрибути сутності «Житель. СК»

Назва атрибуту	Тип даних	Обов’язковий / Необов’язковий*	Коментарі
Особисті дані
Прізвище	XXXXXXX	Xxxx’xxxxxxx
Ім’я	VARCHAR	Обов’язковий
По-батькові	XXXXXXX	Xxxx’xxxxxxx
DATA народження	DATA	Обов’язковий	Формат дд/ММ/рррр
Стать	INT(1)	Обов’язковий	Цифрове (1 цифра). «1» –чол., «2» – жін.
Дані документів
Тип документу	Довідник	Обов’язковий	Паспорт, свідоцтво про народження, ID-картка
Серія	VARCHAR	Обов’язковий	Серія паспорту складається з двох великих літер українського алфавіту - Серія свідоцтва має формат «N-YY», де «N» – римське INT «YY» – дві великих літери українського або англійського алфавіту. Серія ID-картки відсутня.

Назва атрибуту	Тип даних	Обов’язковий / Необов’язковий*	Коментарі
Номер	INT (9)	Обов’язковий	Номер паспорту і свідоцтва 6 цифр. Номер ID картки 9 цифр.
DATA видачі	DATA	Обов’язковий
Ким виданий	VARCHAR	Обов’язковий
Дані по реєстрації
Населений пункт	VARCHAR	Обов’язковий
КОАТУУ населеного пункту	INT (10)	Обов’язковий	10 цифр
Адміністративний район	VARCHAR	Обов’язковий
КОАТУУ району	INT (10)	Обов’язковий	10 цифр
Вулиця	XXXXXXX	Xxxx’xxxxxxx
Будинок	INT	Обов’язковий
Літера будинку	XXXXXXX	Xxxxxx’xxxxxxx
Квартира	INT	Xxxxxx’xxxxxxx
Поштовий індекс	INT	Необов’язковий
Контактні дані
Номер мобільного телефона	INT	Необов’язковий
Електронна пошта	VARCHAR	Необов’язковий
Дані по соціальній карті
Номер карти	INT (16)	Обов’язковий	16 цифр
Кінцева DATA дії карти	DATA	Обов’язковий	DATA, до якої діє карта
Номер карткового рахунку	INT	Обов’язковий
Назва банка емітенту	Довідник	Обов’язковий
Номер рахунку банку	INT	Обов’язковий
Код соціальної категорії	Довідник	Необов’язковий

*Необов’язковий – мається на увазі, при реєстрації може бути заповнений пізніше.

3.3.4 Вимоги до функціональності Системи при взаємодії з ІС «НСС»

3.3.4.1 Розробка програмних компонентів для забезпечення отримання даних з ІС

«НСС» до МР

Механізм програмного забезпечення повинен забезпечувати отримання даних про жителів СК та збереження їх до МР та формування універсальної соціальної складової МР ID (МР ID.СС). Для забезпечення отримання даних повинен бути розроблений API.

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

• особисті дані;

• дані документів;

• дані по реєстрації;

• контактні дані;

• дані по соціальній карті.

Повний перелік можливих даних описує модель даних сутності «Житель. СК» в ІС

«НСС».

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

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

3.3.4.2 Вимоги до отримання оновлених даних з ІС «НСС» до МР

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

За умови пошуку жителя в МР по даним, що є складовими структури бази даних ІС

«НСС», по ІПН або по «ПІБ+документ» повинна здійснюватися перевірка наявності відповідного жителя в МР. По факту негативного результату перевірки ініціюється створення профайлу жителя в частині даних «Житель. СК», після чого процес завершується остаточно. По факту позитивного результату перевірки ініціюється наповнення профайлу жителя в частині даних «Житель. СК», після чого процес завершується остаточно.

3.3.5 Модернізація бази даних МР

В рамках доопрацювання МР необхідно здійснити розширення структури МР шляхом внесення змін в існуючу структуру профайла жителя. Доповнення структури існуючої бази даними з ІС «НСС» потрібно здійснити за наступними параметрами:

• особистими даними;

• даними документів;

• даними по реєстрації;

• контактними даними;

• даними по соціальній карті.

Повний перелік можливих даних описує модель даних сутності «Житель. СК». Дані можуть бути уточнені в Технічному завданні.

3.3.6 Модернізація сервісу обміну даними з ЗІС

В рамках модернізації МР повинен бути модернізований сервіс обміну даними з ЗІС для можливості надання ЗІС наступних даних про жителів міста:

• особистих даних;

• даних документів;

• даних по реєстрації;

• контактних даних;

• даних по соціальній карті;

Повний перелік даних, які можуть бути надані ЗІС, описаний у моделі даних сутності

«Житель. СК». Дані можуть бути уточнені в процесі розробки Технічного завдання та викладені в Технічному завданні.

3.4 Вимоги до функціонального рішення взаємодії МР з Електронною чергою

3.4.1 Опис функціонального рішення

Функціональне рішення виконується за рахунок реалізації налагодженого механізму взаємодії Електронної черги та МР з метою отримання підтверджених даних про реєстрацію дитини у місті Києві.

В рамках модернізації МР повинен бути розроблений API для взаємодії МР з Електронною чергою.

Муніципальний Реєстр в рамках доопрацювання 2-ї черги повинен забезпечувати:

• Сервіс обміну даними.

3.4.2 Схема інтеграції МР з Електронною чергою

Отримання даних з Електронної черги до МР та надання цих даних програмним рішенням міста описана на Рисунок 5.

Електронна черга

Дані про дітей

Статус реєстрації дітей

Дані про дітей

Дані про реєстрацію дітей

Дані про дітей

МР

• Управління обміном даними з Електронною чергою

РТГК

Дані по реєстрації

Рисунок 5 - Загальна схема отримання даних з «Електронна черга» та надання їх програмним рішенням міста

3.4.3 Модель даних отриманих з Електронної черги

Модель даних сутності «Житель. Електронна черга» - це група параметрів, що безпосередньо стосується сутності «Житель. Електронна черга» і утворюють логічну структуру. Структура моделі даних сутності «Житель. Електронна черга» представлена на Рисунок 6.

Додаткові введені дані заяви

Дані користувача кабінету

Е-мейл

Населений пункт реєстрації

Е-мейл

Телефон

Дані видачі свідоцтва

Телефон

Стать

Населений пункт реєстрації

Серія та номер свідоцтва про народження

Дата народження

Родинні стосунки

Країна видачі свідоцтва

По батькові

ІПН

Дата народження

Ім'я

Ім'я

Ім'я дитини

Прізвище

Додаткові введені дані заяви

Житель. Електронна черга

Дані користувача кабінету

Рисунок 6 - Структура моделі даних сутності «Житель. Електронна черга»

Атрибути сутності «Житель. Електронна черга» в системі представлені в Таблиця 3.

Таблиця 3 - Атрибути сутності «Житель. Електронна черга»

Назва атрибуту	Тип даних	Обов’язковий / Необов’язковий*	Коментарі
Ім’я	VARCHAR	Обов’язковий
DATA народження	DATA	Обов’язковий	Формат дд/ММ/рррр
Країна видачі свідоцтва	Довідник	Обов’язковий
Серія свідоцтва	VARCHAR	Обов’язковий
Номер свідоцтва	INT	Обов’язковий
DATA видачі свідоцтва	DATA	Обов’язковий	Формат дд/ММ/рррр
Населений пункт реєстрації дитини	VARCHAR	Необов’язковий
Дані користувача кабінету
Прізвище	XXXXXXX	Xxxx’xxxxxxx
Ім’я	VARCHAR	Обов’язковий
По-батькові	VARCHAR	Xxxxxx’xxxxxxx
DATA народження	DATA	Обов’язковий	Формат дд/ММ/рррр
Стать	Довідник	Обов’язковий
Телефон	INT	Обов’язковий
Е-мейл	VARCHAR	Обов’язковий
Додаткові введені дані заяви (батьків)
Ім’я	VARCHAR	Необов’язковий
ІПН	INT	Необов’язковий
Родинні стосунки	Довідник	Обов’язковий
Населений пункт реєстрації	VARCHAR	Необов’язковий
Телефон	INT	Необов’язковий
Е-мейл	VARCHAR	Необов’язковий

*Необов’язковий – мається на увазі, при реєстрації може бути заповнений пізніше.

3.4.4 Вимоги до функціональності Системи при взаємодії з Електронною чергою

3.4.4.1 Розробка програмних компонентів для забезпечення сервісу обміну даних МР з Електронною чергою

Механізм програмного забезпечення повинен забезпечувати обмін даних з Електронної черги до МР. Для обміну даними повинен бути розроблений API.

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

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

• Отримання запиту даних про дітей від Електронної черги до МР, якщо є згода батьків на передачу їх персональних даних. В рамках запиту Електронна черга дає наступні дані:

- номер запиту;

- Свідоцтво про народження дитини;

• Надсилання відповіді від МР до Електронної черги. В рамках відповіді МР дає наступні дані:

- номер запиту;

- статус реєстрації дитини в Києві;

• Статуси реєстрації:

- Зареєстрований;

- не зареєстрований;

- дані не знайдені.

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

Перелік даних, якими обмінюються МР та Електронна черга, та інші вимоги можуть бути уточнені та викладені в Технічному завданні.

3.4.4.2 Вимоги до обміну даним між МР та Електронною чергою

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

На стороні МР проходить перевірка наявності профайлу Житель.РТГК. Подальші дії будуть залежати від результату перевірки.

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

По факту позитивного результату перевірки відбувається надання даних Житель.РТГК до МР та запис профайлу «Житель.РТГК». Після запису профайлу здійснюється надання статусу реєстрації дитини та завершення роботи з заявою в рамках регламенту Електронної черги. Процес завершується остаточно.

Увага!

Бізнес-процес обміну даними між МР та Електронною чергою може бути уточнений в Технічному завданні.

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

4. ФУНКЦІОНАЛЬНІ ВИМОГИ ДО РОЗРОБКИ ПМ «РД»

4.1 Вимоги до реалізації компоненту ЗНЗ

4.1.1 Вимоги до реалізації блоку Паспорт ЗНЗ

Структура моделі даних сутності «Паспорт ЗНЗ» представлена на Рисунок 7.

Комп’ютерне та програмне забезпечення

Загальна кількість комп’ютерів

Кількість комп’ютерів

підключених до мережі Інтернет

Основні дані

Повна назва ЗНЗ Скорочена назва ЗНЗ Район

Адресні дані

Населений пункт Вулиця

Будинок

Навчальні підрозділи (класи)

Назва класу

Керівник (співробіники) Основна мова навчання

Кількість комп’ютерів, що не

працюють

Кількість комп’ютерів, термін придбання яких понад 5 років

Тип ЗНЗ Профіль

Юридична адреса

Літера будинку Квартира

Спеціалізація Профільне навчання

Кількість учнів

Кількість комп’ютерів, що використовуються в

управлінсько-господарській

діяльності

Кількість комп’ютерів, що використовуються для ведення бібліотечного фонду

Наявність локальної мережі

закладу

Підключення до Інтернет Провайдер

Балансова (залишкова) вартість всього комп’ютерного обладнання

Сайт Е-mail

Тип власності ПІБ директор Телефон Фото ЗНЗ

Узагальнені дані

Загальна чисельність учнів

ЗНЗ

Адресні дані Основні дані

Навчальні підрозділи (класи)

Групи продовженого дня

Комп’ютерне та програмне

забезпечення

Будівельно-технічні

характеристики

Статистика

Групи продовженого дня

Назва класу

Кількість учнів

Оплата за кошти батьків

Будівельно-технічні характеристики

Всього співробітників

Всього педагогічних

співробітників

Використання шкільних приміщень

Оснащення ЗНЗ

Назва будівлі

Стан будівлі

Рік введення в експлуатацію Тип побудови

Проектна потужність кімнат Проектна потужність місць Площа

Кількість поверхів Матеріал стін Матеріал покрівлі Вікна

Кількість ігрових майданчиків

Кількість класів з іноземною мовою навчання

Кількість учнів в класах з

іноземною мовою навчання

Кількість класів з профільним навчанням

Кількість учнів в класах з профільним навчанням

Кількість груп продовженого дня

Кількість груп продовженого дня за кошти батьків

Кількість учнів забезпечених

пільговим гарячим харчуванням

Кількість дітей потерпілих внаслідок аварії на ЧАЕС

Кількість дітей-інвалідів

Оснащення ЗНЗ

Опалення

Теплолічильник Водолічильник Газолічильник Водопровід Басейн Спортивний зал

Спортивний майданчик Актовий зал

Медичний кабінет

Використання шкільних приміщень

Будівля

Номер кабінету Тип кімнати Призначення

Кількість місць з ПЕОМ

Тип майстерні Площа кв м Дані орендаря

Рік останнього капремонту

Кількість дітей-переселенців

Бібліотека

Балансова вартість

Кількість дітей, що навчаються

індивідуально

Поточне утримання 1-ї дитини за

рік

Читальний зал Їдальня

Рисунок 7 - Структура моделі даних сутності «Паспорт ЗНЗ»

Атрибути сутності «Паспорт ЗНЗ» представлені в Таблиця 4.

Таблиця 4 - Атрибути сутності «Паспорт ЗНЗ»

Назва атрибуту	Тип даних	Обов’язковий / Необов’язковий*	Коментарі
Основні дані
Район міста	Довідник	Обов’язковий
Повна назва закладу	VARCHAR	Обов’язковий
Коротка назва закладу	VARCHAR	Обов’язковий
Тип ЗНЗ	Довідник	Обов’язковий
Профіль навчання	Довідник	Обов’язковий
Електронна пошта	VARCHAR	Необов’язковий
Сайт Інтернет	VARCHAR	Необов’язковий
Телефон	INT	Обов’язковий
ПІБ директора	INT	Обов’язковий	Співробітник
Тип власності	Довідник	Обов’язковий
Фото навчального закладу	Файл	Необов’язковий
Адресні дані
Населений пункт	VARCHAR	Обов’язковий
Вулиця	XXXXXXX	Xxxx’xxxxxxx
Будинок	INT	Обов’язковий
Літера будинку	XXXXXXX	Xxxxxx’xxxxxxx
Квартира	INT	Xxxxxx’xxxxxxx
Навчальні підрозділи (класи)
Назва класу	VARCHAR	Обов’язковий	Складається з літери та цифри. Приклад 1А
Керівник	XXXXXXX	Xxxx’xxxxxxx	Співробітник
Основна мова навчання	Довідник	Необов’язковий
Кількість учнів	INT	Xxxxxx’xxxxxxx
Групи продовженого дня
Назва групи	VARCHAR	Необов’язковий
Кількість дітей	INT	Обов’язковий
Оплата за кошти батьків	Логічний	Необов’язковий	Так/Ні
Узагальнені дані
Загальна чисельність учнів	INT	Xxxxxx’xxxxxxx
Всього співробітників	INT	Необов’язковий
Всього педагогічних співробітників	INT	Необов’язковий
Кількість класів з іноземною мовою навчання	INT	Необов’язковий
Кількість учнів в класах з іноземною мовою навчання	INT	Необов’язковий
Кількість класів з профільним навчанням	INT	Необов’язковий
Кількість учнів в класах з профільним навчанням	INT	Необов’язковий
Кількість груп продовженого дня	INT	Необов’язковий
Кількість груп продовженого дня за кошти батьків	INT	Xxxxxx’xxxxxxx

Назва атрибуту	Тип даних	Обов’язковий / Необов’язковий*	Коментарі
Кількість учнів забезпечених пільговим гарячим харчуванням	INT	Необов’язковий
Кількість дітей потерпілих внаслідок аварії на ЧАЕС	INT	Необов’язковий
Кількість дітей-інвалідів	INT	Необов’язковий
Кількість дітей-переселенців	INT	Необов’язковий
Кількість дітей, що навчаються індивідуально	INT	Необов’язковий
Поточне утримання 1-ї дитини за рік	INT	Необов’язковий
Будівельно-технічні характеристики
Назва будівлі	VARCHAR	Обов’язковий
Стан будівлі	Довідник	Необов’язковий
Рік введення в експлуатацію	INT	Необов’язковий
Тип побудови	Довідник	Необов’язковий
Проектна потужність класів	INT	Необов’язковий
Проектна потужність місць	INT	Необов’язковий
Площа будівлі	INT	Необов’язковий
Кількість поверхів	INT	Кількість поверхів
Матеріал стін	Довідник	Необов’язковий	Довідник будівельні матеріали
Матеріали покрівлі	Довідник	Необов’язковий
Вікна	Довідник	Xxxxxx’xxxxxxx
Кількість ігрових майданчиків	INT	Необов’язковий
Рік останнього капремонту	INT	Необов’язковий
Балансова вартість	INT	Необов’язковий
Комп’ютерне та програмне забезпечення
Загальна кількість комп’ютерів	INT	Необов’язковий
Кількість комп’ютерів підключених до мережі Інтернет	INT	Необов’язковий
Кількість комп’ютерів, що не працюють	INT	Необов’язковий
Кількість комп’ютерів, термін придбання яких понад 5 років	INT	Необов’язковий
Кількість комп’ютерів, що використовуються в управлінсько-господарській діяльності	INT	Необов’язковий
Кількість комп’ютерів, що використовуються для ведення бібліотечного фонду	INT	Необов’язковий
Наявність локальної мережі закладу	Логічний	Необов’язковий	Так/Ні
Підключення до Інтернет (так/ні)	Логічний	Необов’язковий	Так/Ні
Провайдер	VARCHAR	Необов’язковий
Балансова вартість всього	INT	Необов’язковий

Назва атрибуту	Тип даних	Обов’язковий / Необов’язковий*	Коментарі
комп’ютерного обладнання
Оснащення ЗНЗ
Опалення	Довідник	Xxxxxx’xxxxxxx
Теплолічильник	Логічний	Необов’язковий	Так/Ні
Водолічильник	Логічний	Необов’язковий	Так/Ні
Газолічильник	Логічний	Необов’язковий	Так/Ні
Водопровід	Логічний	Необов’язковий	Так/Ні
Басейн	Логічний	Необов’язковий	Так/Ні
Спортивний зал	INT	Необов’язковий
Спортивний майданчик	Логічний	Необов’язковий	Так/Ні
Актовий зал	INT	Необов’язковий
Медичний кабінет	INT	Необов’язковий
Бібліотека	INT	Необов’язковий
Читальний зал	INT	Необов’язковий
Кількість місць в їдальні	INT	Необов’язковий
Використання шкільних приміщень
Назва будівлі	VARCHAR	Необов’язковий
Номер приміщення	VARCHAR	Необов’язковий
Тип приміщення	Довідник	Необов’язковий
Призначення кабінету	Довідник	Xxxxxx’xxxxxxx
Кількість місць з ПЕОМ	INT	Необов’язковий
Тип майстерні	Довідник	Необов’язковий	Поле доступно та обов’язкове до заповнення, при значенні поля Тип приміщення (Майстерня)
Площа приміщення	INT	Необов’язковий
Дані орендаря	VARCHAR	Необов’язковий	Поле доступно та обов’язкове до заповнення, при значенні поля Тип приміщення (здано в оренду)

*Необов’язковий – мається на увазі, при реєстрації може бути заповнений пізніше.

В підсистемі повинно бути забезпечено:

• Пошук паспортів ЗНЗ за різними параметрами (тільки для міського та районного рівнів);

• Створення паспорту ЗНЗ;

• Перегляд паспорту ЗНЗ;

• Редагування паспорту ЗНЗ;

• Друк Паспорту ЗНЗ з фото;

• Видалення Паспорту ЗНЗ.

Необхідно передбачити друк Паспорта ЗНЗ на всіх рівнях управління (школа, район, місто). При друкуванні паспорту повинна бути передбачена можливість прив’язки фотографії закладу. Передбачити можливість експорту у документи формату .doc/.docx,

.xls/.xlsx, .pdf.

Даними Технічними вимогами не передбачені роботи щодо формування звітів, так як передбачається що узагальнені дані, визначені у паспорті ЗНЗ, повинні розраховуватися засобами зовнішнього спеціалізованого програмного забезпечення щодо аналітичної обробки

та побудови звітів. Вимоги до формування звітів повинні бути визначені в окремих Технічних вимогах.

4.1.2 Вимоги до реалізації блоку співробітник ЗНЗ

Структура моделі даних сутності «Співробітник ЗНЗ» представлена на Рисунок 8.

Дата видачі

Номер та серія диплому

Науковий ступінь

Рік підвищення кваліфікації

Кваліфікація

Рік останньої атестації

Спеціальність

Педагогічні звання

Дата видачі

Освітньо-кваліфікаційни рівень

Кваліфікаційна категорія

Назва нагороди

Форма навчання закладу

Працює за спеціальністю

Учасник АТО

Навчальний заклад

Педагогічний стаж

Місце перебування на обліку

Дані про освіту

Загальний стаж

Xxx xxxxxxx

Навчальний предмет

Xxx xxxxxxx

Дата видачі

Мови викладання

Дата видачі

Номер військового квитка

Характер зарахування

Номер

Військовий облік

Посада

Серія

Дата зарахування

Тип документу

Номер школи

Дані документів

Квартира

Дані про роботу

Літера будинку

Пенсійний стан

Дані про роботу

Забезпеченість житлом

Вулиця

Будинок

Дані про освіту

Громадянство

Адміністративний район

Військовий облік

Дата народження

Населений пункт

Дані по реєстрації

Стать

Район

ІПН

По-батькові

Область

Дані документів

Ім'я

Країна

Особисті дані

Прізвище

Дані по реєстрації

Співробітник

Особисті дані

Рисунок 8 - Структура моделі даних сутності «Співробітник ЗНЗ»

Атрибути сутності «Співробітник ЗНЗ» представлено в Таблиця 5.

Таблиця 5 - Атрибути сутності «Співробітник ЗНЗ»

Назва атрибуту	Тип даних	Обов’язковий / Необов’язковий*	Коментарі
Особисті дані
Прізвище	XXXXXXX	Xxxx’xxxxxxx
Ім’я	VARCHAR	Обов’язковий
По-батькові	VARCHAR	Xxxxxx’xxxxxxx

Назва атрибуту	Тип даних	Обов’язковий / Необов’язковий*	Коментарі
DATA народження	DATA	Обов’язковий
Стать	Довідник	Обов’язковий
Громадянство	Довідник	Необов’язковий
Забезпеченість житлом	Логічний	Необов’язковий	Так/Ні
Пенсійний стан	Довідник	Необов’язковий
Дані документів
Тип документу	Довідник	Обов’язковий
Серія	VARCHAR	Обов’язковий
Номер	INT	Обов’язковий
DATA видачі	DATA	Обов’язковий
Ким виданий	VARCHAR	Обов’язковий
Дані по реєстрації
Країна	VARCHAR	Обов’язковий
Область	VARCHAR	Обов’язковий
Район	VARCHAR	Необов’язковий
Населений пункт	VARCHAR	Обов’язковий
Адміністративний район	VARCHAR	Необов’язковий
Вулиця	XXXXXXX	Xxxx’xxxxxxx
Будинок	INT	Обов’язковий
Літера будинку	XXXXXXX	Xxxxxx’xxxxxxx
Квартира	INT	Xxxxxx’xxxxxxx
Військовий облік
Номер військового квитка	VARCHAR	Необов’язковий
DATA видачі	DATA	Необов’язковий
Xxx xxxxxxx	XXXXXXX	Xxxxxx’xxxxxxx
Місце перебування на обліку	VARCHAR	Необов’язковий
Учасник АТО	Логічний	Необов’язковий	Так/Ні
Назва нагороди	Довідник	Xxxxxx’xxxxxxx
DATA отримання нагороди	DATA	Необов’язковий
Дані про освіту
Навчальний заклад	Довідник	Xxxxxx’xxxxxxx	Назва навчального закладу
Форма навчання закладу	Довідник	Необов’язковий
Освітньо-кваліфікаційний рівень	Довідник	Необов’язковий
Спеціальність	VARCHAR	Необов’язковий
Кваліфікація	Довідник	Необов’язковий
Науковий ступінь	Довідник	Необов’язковий
Номер та серія диплому	Довідник	Необов’язковий
DATA видачі диплому	DATA	Необов’язковий
Дані про роботу
Номер школи	Довідник	Обов’язковий	Поточна школа
DATA зарахування	DATA	Обов’язковий
Посада	Довідник	Обов’язковий
Характер зарахування	Довідник	Обов’язковий
Мови викладання	Довідник	Обов’язковий
Навчальний предмет	Довідник	Xxxxxx’xxxxxxx

Назва атрибуту	Тип даних	Обов’язковий / Необов’язковий*	Коментарі
Загальний стаж	Текст	Обов’язковий	Роки/місяці
Педагогічний стаж	Текст	Обов’язковий	Роки/місяці
Працює за спеціальністю	Логічний	Обов’язковий	Так/Ні
Кваліфікаційна категорія	Довідник	Обов’язковий
Педагогічне звання	Довідник	Необов’язковий
Рік останньої атестації	DATA	Необов’язковий
Рік підвищення кваліфікації	DATA	Необов’язковий

*Необов’язковий – мається на увазі, при реєстрації може бути заповнений пізніше.

В підсистемі повинно бути забезпечено:

• Пошук картки співробітника;

• Створення картки співробітника;

• Перегляд картки співробітника;

• Редагування картки співробітника;

• Видалення картки співробітника (під видалення розуміється логічне видалення);

• Друк картки співробітника.

4.1.3 Вимоги до реалізації блоку Учень ЗНЗ

Структура сутності «Учень ЗНЗ» представлено на Рисунок 9.

Контактний е-мейл

Контактний телефон

Місце роботи

Дані документів

Стоїть на обліку

Адреса реєстрації

Поглиблене вивчення предметів

Дата народження

Профіль навчання

По батькові

Іноземні мови

Xxx xxxxxxx

Ім'я

Табельний номер

Дата видачі

Прізвище

Клас в якому навчається

Номер

Родинний статус

Форма навчання учня

Серія

Рік зарахування до школи

Дані батьків

Тип документу

Рік зарахування в 1й клас

Дата реєстрації

Дані документів

Номер школи

Квартира

Літера будинку

Дані про навчання

Хронічні захворювання

Будинок

Соціальний статус

Вулиця

Національність

Адміністративний район

Дані про навчання

Дата народження

Населений пункт

Дані батьків

Стать

Район

Дані по реєстрації

По-батькові

Область

Дані документів

Ім'я

Країна

Особисті дані

Прізвище

Дані по реєстрації

Учень

Особисті дані

Рисунок 9 - Структура сутності «Учень ЗНЗ»

Атрибути сутності «Учень ЗНЗ» представлено в Таблиця 6.

Таблиця 6 - Атрибути сутності «Учень ЗНЗ»

Назва атрибуту	Тип даних	Обов’язковий / Необов’язковий*	Коментарі
МР ID (МР ID.ОС)		Обов’язковий	Формується автоматично засобами БД. Унікальний ідентифікатор запису
Особисті дані
Прізвище	XXXXXXX	Xxxx’xxxxxxx
Ім’я	VARCHAR	Обов’язковий
По-батькові	VARCHAR	Xxxxxx’xxxxxxx
DATA народження	DATA	Обов’язковий
Стать	Довідник	Обов’язковий
Національність	Довідник	Необов’язковий
Соціальний статус дитини	Довідник	Необов’язковий
Хронічні захворювання	Довідник	Необов’язковий
Дані документів
Тип документу	Довідник	Обов’язковий
Серія	VARCHAR	Обов’язковий
Номер	INT	Обов’язковий
DATA видачі	DATA	Обов’язковий
Ким виданий	VARCHAR	Обов’язковий
Дані по реєстрації
Країна	VARCHAR	Обов’язковий
Область	VARCHAR	Обов’язковий
Район	VARCHAR	Необов’язковий
Населений пункт	VARCHAR	Обов’язковий
Адміністративний район	VARCHAR	Необов’язковий
Вулиця	XXXXXXX	Xxxx’xxxxxxx
Будинок	INT	Обов’язковий
Літера будинку	XXXXXXX	Xxxxxx’xxxxxxx
Квартира	INT	Xxxxxx’xxxxxxx
DATA реєстрації	DATA	Обов’язковий
Дані про батьків
Родинний статус	Довідник	Необов’язковий	Батько, мати, опікун
Прізвище	XXXXXXX	Xxxxxx’xxxxxxx
Ім’я	VARCHAR	Необов’язковий
По-батькові	VARCHAR	Xxxxxx’xxxxxxx
DATA народження	DATA	Xxxxxx’xxxxxxx
Документ	Аналогічно як по дитині
Адреса реєстрації	Аналогічно як по дитині
Місце роботи	VARCHAR	Необов’язковий
Контактний телефон	INT	Необов’язковий
Контактний е-мейл	VARCHAR	Необов’язковий
Дані про навчання

Назва атрибуту	Тип даних	Обов’язковий / Необов’язковий*	Коментарі
Номер школи	Довідник	Обов’язковий	Довідник ЗНЗ
Рік зарахування в 1 клас	DATA	Необов’язковий
Рік зарахування до школи	DATA	Обов’язковий	Поточна школа навчання
Форма навчання учня	Довідник	Обов’язковий
Клас в якому навчається	Довідник	Обов’язковий	Поточний клас навчання
Табельний номер (за алфавітом)	VARCHAR	Обов’язковий
Іноземні мови	Довідник	Необов’язковий	Довідник мови
Профіль навчання	Довідник	Обов’язковий
Поглиблене вивчення предметів	Довідник	Xxxxxx’xxxxxxx
Постановка на обліку	Довідник	Обов’язковий	Облік в поліції

* Необов’язковий – мається на увазі, при реєстрації може бути заповнений пізніше. В підсистемі повинно бути забезпечено:

• Пошук картки учня;

• Створення картки учня;

• Перегляд картки учня;

• Редагування картки учня;

• Видалення картки учня (під видалення розуміється логічне видалення);

• Друк картки учня.

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

.doc/.docx, .xls/.xlsx, .pdf.

4.2 Вимоги до реалізації компоненту ДНЗ

4.2.1 Вимоги до реалізації блоку Вихованець ДНЗ

Структура сутності «Вихованець ДНЗ» представлено на Рисунок 10.

Особисті дані

Дані документів

Дані батьків

Прізвище			Тип документу				Родинний статус
Ім'я			Xxxxx				XXX
По-батькові			Xxxxx				XXX
Стать			Дата видачі				Контактний телефон
Дата народження							Контактний е-мейл

Населений пункт реєстрації

Вихованець

Дані про пільгу

Назва ДНЗ

ДНЗ

Особисті дані

Дані документів Дані батьків

Назва пільги

Документ

Номер ДНЗ Спеціалізація Тип власності Вид закладу ПІБ керівника Спортзал Музичний зал Адреса

Район

Контактний телефон Контактний е-мейл Час роботи

Загальний опис

Дані про пільгу Дані про ДНЗ

Дані про навчання

Дані про навчання

ДНЗ

Група

Дата зарахування до ДНЗ Табельний номер

Дата направлення з РУО з Дата направлення з РУО по Медичний протокол

Дата медичного протоколу

Група

Назва групи Номер групи

Назва типу групи Вид групи

Спеціалізація ПІБ вихователя Харчування

Батьківська плата за харчування

Кількість спальних місць

Кількість місць довготривалого перебування

Кількість місць інклюзивного

перебування

Спеціалізація для інклюзивного перебування

Час роботи початок Час роботи кінець

Рисунок 10 - Структура сутності «Вихованець ДНЗ»

Атрибути сутності «Вихованець ДНЗ» представлено в Таблиця 7.

Таблиця 7 - Атрибути сутності «Вихованець ДНЗ»

Назва атрибуту	Тип даних	Обов’язковий / Необов’язковий*	Коментарі
МР ID (МР ID.ОС)		Обов’язковий	Формується автоматично засобами БД. Унікальний ідентифікатор запису
Особисті дані

Назва атрибуту	Тип даних	Обов’язковий / Необов’язковий*	Коментарі
Прізвище	XXXXXXX	Xxxx’xxxxxxx
Ім’я	VARCHAR	Обов’язковий
По-батькові	VARCHAR	Xxxxxx’xxxxxxx
DATA народження	DATA	Обов’язковий
Стать	Довідник	Обов’язковий
Громадянство	Довідник	Необов’язковий
Населений пункт реєстрації	VARCHAR	Необов’язковий
Дані документів
Тип документу	Довідник	Обов’язковий
Серія	VARCHAR	Обов’язковий
Номер	INT	Обов’язковий
DATA видачі	DATA	Обов’язковий
Дані про батьків
Родинний статус	Довідник	Обов’язковий	Батько, мати
ПІБ	VARCHAR	Обов’язковий
ІПН	INT	Обов’язковий
Контактний e-mail	VARCHAR	Необов’язковий
Контактний телефон	INT	Необов’язковий
Дані про пільгу
Назва пільги	Довідник	Необов’язковий
Тип документу	VARCHAR	Необов’язковий
Серія	VARCHAR	Необов’язковий
Номер	VARCHAR	Необов’язковий
DATA видачі	VARCHAR	Необов’язковий
Дані про навчання
DATA зарахування	DATA	Обов’язковий
Табельний номер	INT	Обов’язковий
DATA направлення з РУО з	DATA	Необов’язковий
DATA направлення з РУО по	DATA	Необов’язковий
Медичний протокол	VARCHAR	Необов’язковий
DATA медичного протоколу	DATA	Необов’язковий
ДНЗ
Назва ДНЗ	VARCHAR	Обов’язковий
Номер ДНЗ	INT	Обов’язковий
Спеціалізація	Довідник	Обов’язковий
Тип власності	Довідник	Обов’язковий
ПІБ Керівника	XXXXXXX	Xxxx’xxxxxxx
Район	Довідник	Обов’язковий
Xxxxxx	XXXXXXX	Xxxx’xxxxxxx
Спортзал	Логічний	Обов’язковий	Так/Ні
Музичний зал	Логічний	Обов’язковий	Так/Ні
Контактний e-mail	VARCHAR	Необов’язковий
Контактний телефон	DATA	Обов’язковий
Сайт	VARCHAR	Необов’язковий
Час роботи	XXXXXXX	Xxxx’xxxxxxx

Назва атрибуту	Тип даних	Обов’язковий / Необов’язковий*	Коментарі
Загальний опис	VARCHAR	Обов’язковий
Група
Назва групи	VARCHAR	Обов’язковий
Номер групи	INT	Обов’язковий
Назва типу групи	Довідник	Обов’язковий
Вид групи	Довідник	Обов’язковий
Спеціалізація	Довідник	Обов’язковий
ПІБ вихователя	VARCHAR	Обов’язковий
Xxxxxxxxxx	Xxxxxxxx	Обов’язковий
Батьківська плата за харчування	INT	Необов’язковий
Кількість спальних місць	INT	Обов’язковий
Кількість місць довготривалого перебування	INT	Обов’язковий
Кількість місць інклюзивного перебування	INT	Обов’язковий
Спеціалізація для інклюзивного перебування	Довідник	Обов’язковий
Час роботи початок	VARCHAR	Обов’язковий
Час роботи закінчення	VARCHAR	Обов’язковий

* Необов’язковий – мається на увазі, при реєстрації може бути заповнений пізніше.

В підсистемі повинна бути забезпечено:

• Пошук картки вихованця;

• Створення картки вихованця;

• Перегляд картки вихованця;

• Редагування картки вихованця;

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

• Друк картки вихованця.

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

4.3 Вимоги до реалізації компоненту РУ

4.3.1 Облік ЗНЗ на районному рівні

4.3.1.1 Вимоги до блока паспорт ЗНЗ

Аналогічно вимогам до блока паспорт ЗНЗ, але по всіх ЗНЗ району та тільки в режимі перегляду.

4.3.1.2 Вимоги до блока співробітник ЗНЗ

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

4.3.1.3 Вимоги до блока учень ЗНЗ

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

4.3.2 Облік ДНЗ на районному рівні

4.3.2.1 Вимоги до блока вихованець ДНЗ

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

4.4 Вимоги до реалізації компоненту ДОНМС

4.4.1 Облік ЗНЗ на міському рівні

4.4.1.1 Вимоги до блоку паспорт ЗНЗ

Аналогічно вимогам до блока паспорт ЗНЗ, але по всіх навчальним закладам міста та тільки в режимі перегляду.

4.4.1.2 Вимоги до блока співробітник ЗНЗ

Аналогічно вимогам до блока співробітник ЗНЗ, але по всіх навчальних закладах міста та тільки в режимі перегляду.

4.4.1.3 Вимоги до блока учень ЗНЗ

Аналогічно вимогам до блока учень ЗНЗ, але по всіх навчальних закладах міста та тільки в режимі перегляду.

4.4.2 Облік ДНЗ на міському рівні

4.4.2 1 Вимоги до блока вихованець ДНЗ

Аналогічно вимогам до блока вихованець ДНЗ, але по ДНЗ міста та тільки в режимі перегляду.

4.5 Вимоги до реалізації програмної підсистеми обміну даними з РТГК

Основним завдання підсистеми являється забезпечення обмін даними ПМ «РД» з РТГК. З РТГК дозволені для передачі дані по учням.

Повний склад та перелік даних повинен бути визначений у Технічному завданні.

4.5.1 Функції сервісу

Функціями сервісу являються:

• Отримання оновлених даних від РТГК по учням. В рамках оновлення ПМ «РД» отримує від РТГК наступні дані про учнів:

- особисті дані;

- дані про документи;

- дані про реєстрацію;

- місце народження;

4.6 Вимоги до реалізації програмної підсистеми обміну даними з Електронною чергою

Основним завдання підсистеми являється забезпечення обміну даними ПМ «РД» з Електронною чергою.

Повний склад та перелік даних повинен бути визначений у Технічному завданні.

4.6.1 Функції сервісу

Функціями сервісу являються:

• Отримання оновлених даних від Електронної черги по вихованцям ДНЗ. В рамках оновлення ПМ «РД» отримує від Електронної черги наступні дані:

- особисті дані;

- дані про батьків;

- дані про пільгу;

- дані про навчання;

- дані про групу;

- дані про ДНЗ.

При вдалому отриманні даних з Електронної черги відбувається їх запис до ПМ «РД» та формування універсальної освітньої складової МР ID (МР ID.ОС).

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

4.6.2 Вимоги до отримання даних з Електронної черги до ПМ «РД»

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

Відбувається формування та надсилання змінених даних вихованця ДНЗ:

• особисті дані;

• дані про батьків;

• дані про пільгу;

• дані про навчання;

• дані про групу;

• дані про ДНЗ.

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

4.7 Вимоги до реалізації підсистеми адміністрування

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

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

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

• формування списків об’єктів ПМ «РД», довідників та класифікаторів, які користувач коригував протягом дня (як поточного, так і минулих) або за період;

• ведення рольової моделі користувачів з обов’язковою реалізацією таких ролей:

o Керівник;

o Фахівець;

o Адміністратор;

o Системний адміністратор.

• автентифікації користувачів:

o за допомогою логіну та паролю;

o з використанням веб-рішення «Крипто Автограф» для механізму ідентифікації через ЕЦП».

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

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

• створення групи (Департамент освіти; Управління освіти району; Школа, Садок);

• створення ролей, які обов’язково належать групі;

• визначення загальних повноважень для кожної ролі в групі;

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

Можливості ролей за належністю до відповідної організаційної структури та групи (див. Таблиця 8).

Таблиця 8. Можливості ролей у відповідності до організаційної структури та групи

Можливість

Системний адміністратор

Департамент освіти і науки, молоді та спорту (ДОНМС)

Районні управління освіти (РУО)

Загальноосвіт ні навчальні заклади (ЗНЗ)

Заклади дошкільної освіти (ЗДО)

Керівник

Фахівець відділу ЗНЗ

Фахівець відділу ЗДО

Адміністратор

Керівник

Фахівець відділу ЗНЗ

Фахівець відділу ЗДО

Адміністратор

Керівник

Фахівець

Адміністратор

Керівник

Фахівець

Адміністратор

Паспорт ЗНЗ / Паспорт, Співробітник ЗНЗ, Учень ЗНЗ, Вихованець ДНЗ

Пошук/перегляд даних по всіх ЗНЗ та ЗДО м. Києва, які підпорядковані Департаменту освіти і науки, молоді та спорту

+

Пошук/перегляд даних по всіх ЗНЗ м. Києва, які підпорядковані Департаменту освіти і науки, молоді та спорту

+

Пошук/перегляд даних по всіх ЗДО м. Києва, які підпорядковані Департаменту освіти і науки, молоді та спорту

+

Пошук/перегляд даних по всіх ЗНЗ та ЗДО м. Києва, які підпорядковані Районним управлінням освіти

+

Можливість

Системний адміністратор

Департамент освіти і науки, молоді та спорту (ДОНМС)

Районні управління освіти (РУО)

Загальноосвіт ні навчальні заклади (ЗНЗ)

Заклади дошкільної освіти (ЗДО)

Керівник

Фахівець відділу ЗНЗ

Фахівець відділу ЗДО

Адміністратор

Керівник

Фахівець відділу ЗНЗ

Фахівець відділу ЗДО

Адміністратор

Керівник

Фахівець

Адміністратор

Керівник

Фахівець

Адміністратор

Пошук/перегляд даних по всіх ЗНЗ м. Києва, які підпорядковані Районним управлінням освіти

+

Пошук/перегляд даних по всіх ЗДО м. Києва, які підпорядковані Районним управлінням освіти

+

Введення, коригування, пошук та друк інформації по своєму ЗНЗ

+

Пошук/перегляд інформації по своєму ЗНЗ

+

Введення, коригування, пошук, перегляд та друк інформації по своєму ЗДО

+

Пошук/перегляд інформації по своєму ЗДО

+

Адміністрування користувачів ЗНЗ

Інсталяція системи/компонентів/модулів

+

Можливість

Системний адміністратор

Департамент освіти і науки, молоді та спорту (ДОНМС)

Районні управління освіти (РУО)

Загальноосвіт ні навчальні заклади (ЗНЗ)

Заклади дошкільної освіти (ЗДО)

Керівник

Фахівець відділу ЗНЗ

Фахівець відділу ЗДО

Адміністратор

Керівник

Фахівець відділу ЗНЗ

Фахівець відділу ЗДО

Адміністратор

Керівник

Фахівець

Адміністратор

Керівник

Фахівець

Адміністратор

Створення резервних копій та їх зберігання/розгортання

+

Підтримка роботи БД

+

Створення груп

+

Створення ролей, які обов’язково належать групі

+

Визначення загальних повноважень для кожної ролі в групі

+

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

+

Адміністрування користувачів Адміністраторів БП

+

Можливість

Системний адміністратор

Департамент освіти і науки, молоді та спорту (ДОНМС)

Районні управління освіти (РУО)

Загальноосвіт ні навчальні заклади (ЗНЗ)

Заклади дошкільної освіти (ЗДО)

Керівник

Фахівець відділу ЗНЗ

Фахівець відділу ЗДО

Адміністратор

Керівник

Фахівець відділу ЗНЗ

Фахівець відділу ЗДО

Адміністратор

Керівник

Фахівець

Адміністратор

Керівник

Фахівець

Адміністратор

Адміністратор

Наповнення відповідних довідників в межах доступу

+

+

+

Адміністрування користувачів ДОНМС

+

Адміністрування користувачів РУО

+

+

Адміністрування користувачів ЗНЗ

+

+

+

Адміністрування користувачів ЗДО

+

+

+

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

Деталізовані вимоги щодо рольової моделі можуть бути уточнені в Технічному завдані.

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

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

Система повинна модернізуватися з використанням безкоштовних програмних засобів з відкритими кодами, такими як PostgreSQL, MYSQL або аналогів та використовує найсучасніші та перспективні формати інформаційного обміну даними між клієнтом і сервером на основі протоколу HTTPS (XML, JSON) за специфікаціями консорціуму "OGC". Взаємодія між сервером додатків та клієнтом для кінцевого користувача повинно виконуватися за протоколом https.

Модернізація ІС “МР” повинна виконуватись із використанням принципів концепції Free and Open Source Software (FOSS), розширених парадигмою гуманітарної відповідальності (Humanitarian-FOSS) і включає такі вимоги:

− Націленість на рішення критично важливих завдань для підвищення швидкості:

o надання Послуг на Порталі послуг, ЗІС (ОКК), ЗІС, в яких реалізовані on- line послуги;

o роботи ПМ «РД».

− Висока орієнтація на якість, надійність і стабільність роботи ІС «МР», виключення втрати і дублювання даних.

− Мінімальні вимоги до кваліфікації користувачів і необхідності їх навчання.

− Прозорі інтеграційні можливості.

− Інформаційна та технічна безпека ІС “МР”.

− Гнучка рольова модель із можливістю її модифікації.

− Забезпечення необхідного рівня конфіденційності персональних даних громадян згідно із Законодавством України.

− Забезпечення прозорості доступу до інформації.

− Забезпечення історії збереження записів.

− Забезпечення резервування програмних модулів, компонентів ІС “МР”.

− Всі програмні модулі, компоненти, що впроваджуватимуться та поставлятимуться в рамках цієї закупівлі, мають бути надані на умовах ліцензування GPL (xxxx://xxx.xxx.xxx/xxxxxxxx/xxx.xxxx) і забезпечувати відкритість, прозорість та доступність вихідних кодів продукту за ідеологією OpenSource (ліцензія на вільне програмне забезпечення).

− Якісна супроводжувальна робоча та експлуатаційна документація.

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

Запропоновані рішення модернізації ІС “МР” будуть вимагати не менш ніж 3-х фахівців з певною роллю та відповідним рівнем підготовки, які повинні забезпечувати:

− безперервне супроводження ІС “МР” на всіх стадіях його експлуатації та підтримки;

− цілодобовий режим роботи ІС “МР” та його модулів за призначенням в повному обсязі;

− централізований контроль працездатності ІС “МР”;

− усунення відмов роботи ІС “МР” та його компонентів;

− адміністрування (оперативне налагодження під час експлуатації) роботи ІС “МР”;

− своєчасне централізоване застосування оновлень програмного забезпечення.

5.3 Вимоги до показників навантаження

ІС “МР” повинна забезпечувати:

− швидкість обробки запитів із наданням релевантних відповідей – 1-3 секунди;

− можливість зберігання історичних даних протягом усього часу використання ІС “МР”;

− здатність забезпечити можливість нарощування кількості користувачів та об’ємів баз даних без потреби будь-яких додаткових доробок.

Швидкість роботи ІС “МР” не повинна погіршуватися при:

− пікових навантаженнях із одночасною роботою 10000 користувачів (одночасних запитів в 1 секунду);

− порядковому зростанні кількості користувачів;

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

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

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

Надійність ІС “МР” повинна бути забезпечена за наступними напрямками:

− забезпечення працездатності ІС “МР”;

− збереження даних ІС “МР”.

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

− використання сучасних технологій розробки ІС “МР” та забезпеченням якісного тестування;

− резервуванням компонентів та їх елементів;

− режиму автоматичного аналізу поточного стану (в реальному стані) та відновлення працездатності у відповідності до регламенту відновлювальних робіт;

− організації систематичного резервного копіювання та архівного збереження інформації в ІС “МР”;

− апаратно-програмним захистом роботи від стороннього несанкціонованого програмно-апаратного втручання;

− архівним збереженням інформації;

− оперативністю заміни програмно-технічних засобів, що вийшли з ладу;

− сумісністю технічних засобів та програмного забезпечення.

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

На початковому рівні створення ІС “МР” будуть реалізовуватися базові заходи із забезпечення захисту інформації та технологічної інформації про систему. Повинні бути реалізовані наступні заходи захисту початкового рівня, а саме:

− організаційно-адміністративні;

− апаратно-програмні;

− інженерно-технічні.

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

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

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

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

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

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

Всі інтерактивні елементи повинні бути виконані у зручному та зрозумілому представленні із набором відповідних текстових та/або графічних інформаційних підказок.

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

5.6.1 Веб-інтерфейс повинен відповідати таким вимогам щодо використання технологій при його створенні:

− Рішення повинно бути виконано з використанням елементів адаптивних технологій.

− Передбачається використання HTML4 / HTML5, Ajax, JavaScript.

− Для накладення стильової інформації використовується таблиці стилів CSS3.

− Можливе використання різних rich-media технологій як компоненту HTML сторінок.

− Використання таких технологій, як Flash, наприклад, у вигляді Flex або SilverLigh не передбачається.

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

− з операційними системами: Windows, Linux;

− з браузерами, у тому числі мобільними: Microsoft Edge, Opera, Mozilla Firefox, Google Chrome, (наперед останніми релізами версій).

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

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

− Opera;

− Microsoft Edge;

− Chromе.

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

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

5.7 Вимоги до експлуатації і технічного обслуговування, ремонту та зберігання компонентів ІС “МР”

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

Експлуатація ІС “МР” повинно виконуватися за наступними принципами:

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

− Технічне обслуговування та ремонт виконується персоналом Виконавця відповідно до вимог виробників.

Технічне супроводження програмного забезпечення ІС “МР” повинно виконуватися системними адміністраторами, технічне супроводження обладнання ІС “МР” виконується технічними спеціалістами Замовника чи Виконавця.

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

5.8 Вимоги до режимів функціонування

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

Експлуатація ІС “МР” повинна передбачати такі режими:

− Основний режим – режим штатного функціонування всіх компонентів ІС “МР” за своїм призначенням.

− Нештатний режим – режим нештатного функціонування всіх компонентів ІС “МР”, наприклад, недоступність даних серверу.

− Режим адміністрування – режим здійснення централізованого автоматизованого налагоджування та автоматизованого оновлення компонентів ІС “МР” одночасно з роботою решти користувачів в ІС “МР” в основному режимі або в режимі Технічного обслуговування.

− Режим регламентного обслуговування – режим регламентного технічного обслуговування та відновлення працездатності технічних засобів компонентів ІС “МР”.

5.9 Вимоги до збереження інформації при аваріях

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

До складу повідомлення щодо події аварійного типу повинні входити:

− час;

− текстова назва аварії;

− назва файлу вихідних текстів;

− номер рядка в файлі;

− причина помилки.

Користувачі ОКК / Користувачі ПМ «РДК», в разі виникнення помилок, повинні бачити лише скорочені інформаційні повідомлення зрозумілого характеру без технічної деталізації.

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

− відмова обладнання сервера;

− вимкнення живлення на робочому місці та/або на сервері баз даних;

− відмова обладнання робочої станції;

− відмова ліній зв’язку.

З метою забезпечення зберігання інформації повинно використовуватися:

− резервне копіювання;

− відновлення даних при збоях в роботі мережевого, програмного і апаратного забезпечення.

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

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

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

Патентна чистота ІС “МР” повинна бути забезпечена розробником і повинна гарантуватися фірмами виробниками програмних засобів.

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

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

Рішення з технічного та загального програмного забезпечень ІС “МР” повинні передбачати вибір сумісних, найбільш інтегрованих програмних та технічних засобів, які відповідають вимогам сучасних міжнародних стандартів відкритих систем та програмних засобів.

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

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

Інформаційне забезпечення ІС “МР” повинно відповідати таким вимогам та можливостям:

− багаторазове використання даних у різних ділових процесах;

− забезпечення фізичної та логічної цілісності даних;

− мінімізація надмірності даних, що зберігаються;

− стандартизація представлення даних;

− достовірність та актуальність даних. Побудова ІС “МР” повинна забезпечувати:

− розмежування доступу до даних, запобігання несанкціонованого доступу до них;

− копіювання і зберігання масивів інформації;

− мінімізацію обсягу даних, що вводяться вручну;

− можливість розширення масивів інформації з урахуванням перспектив розвитку. Інформаційне забезпечення ІС “МР” повинна включати:

− компонент класифікації і кодування;

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

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

− локальних в межах системи;

− відомчих;

− загальнодержавних.

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

− використання загальносистемних класифікаторів;

− централізоване ведення системних класифікаторів;

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

− забезпечення мінімальних витрат пам’яті у процесі накопичення та зберігання інформації;

− забезпечення максимальної швидкодії при вирішенні функціональних задач.

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

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

Шлюз інформаційного обміну повинен передбачати:

− можливість підключення та безпечність доступу локальних ресурсів ІС “МР” до зовнішніх інформаційних систем та ресурсів;

− можливість централізованого адміністрування та керування доступністю локальних ресурсів ІС “МР”.

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

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

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

Мовні засоби програмування будуть обираються Виконавцем відповідно до рішень з програмного забезпечення ІС “МР”.

5.12.3 Вимоги до апаратно-програмного забезпечення

Програмне забезпечення (далі – ПЗ) ІС “МР” повинно складатися із:

− загальносистемного програмного забезпечення (далі – ЗПЗ);

− прикладного програмного забезпечення (далі – ППЗ).

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

− підтримку загально прийнятих сучасних міжнародних стандартів до відкритих систем;

− сумісність та інтегрованість;

− підтримку функціонування в різнорідному апаратному і програмному середовищах;

− вмонтованість механізму захисту від помилок і підтримки цілісності.

Розробник повинен надати рекомендації щодо складу загальносистемного програмного забезпечення:

− операційні системи;

− система управління базами даних;

− програмна платформа;

− система забезпечення версійності та інтеграції проекту;

− система моніторингу;

− система відслідковування помилок;

− сервери додатків.

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

Рішення зі складу загальносистемного програмного забезпечення повинно технічно та економічно обґрунтовано з точку зору цілісності та обґрунтованої повноти програмного застосування ІС “МР” та його компонентів за призначенням та мінімізації витрат на подальший супровід.

До прикладного програмного забезпечення повинна відноситись програмне забезпечення, що розробляється та налаштовується під час модернізації ІС “МР”.

За результатами створення та впровадження ІС “МР” програмний код прикладного програмного забезпечення повинен бути переданий Виконавцем Замовнику в електронному вигляді.

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

При розробці ППЗ повинні використовуватися принципи модульності та типовості, які забезпечать послідовне нарощування функціональних можливостей ІС “МР” за рахунок створення, впровадження та тиражування функціонально завершених програмних модулів.

Показники навантаження при яких ІС “МР” повинна зберігати час відклику компонентів системи не більше 3х секунд:

Кількість записів користувачів (не менше)	2 млн.
Пікова кількість одночасно працюючих користувачів	10 000
Середня кількість заявок на послугу по всій системі за день	6 000
Пікова кількість заявок на послугу по всій системі за день	16 000
Об’єм (кількість) сканкопій документів	200 000

Щодо прогнозованого навантаження на систему Виконавець повинен надати рекомендації щодо прогнозних характеристик апаратного забезпечення:

− Сxxxxx XX;

− Сервер APP;

− Сервер FileStorage;

− Сервер БД резервний;

− Сервер APP резервний;

− Сервер FileStorage резервний;

− Сервер БД та APP тестовий;

− Сервер моніторингу;

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

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

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

Вимоги до модернізації ІС “МР” в цілому:

− ІС “МР” повинна мати архітектуру, побудовану на сучасних промислових технологіях зберігання, обробки, аналізу даних та доступу до них, забезпечувати одночасну роботу користувачів.

− ІС “МР” повинна мати централізовану базу даних, яка підтримує шифрування певного набору даних, та можливість організації взаємодії (інтерфейси взаємодії) із суміжними інформаційними системами.

− Для захисту певних інформаційних об’єктів у ІС “МР” може використовуватися програмний засіб криптографічних перетворень, який має позитивний експертний висновок Державної служби спеціального зв'язку та захисту інформації України.

− ІС “МР” повинна представляти собою комплекс інформаційних, програмних, технічних, організаційно-методичних та інших необхідних засобів, що забезпечують збір, обробку, зберігання, передачу даних.

− ІС “МР” повинна мати засоби діагностики цілісності як БД в цілому, так і окремих таблиць/об’єктів, а також засоби шифрування.

− Архітектура ІС “МР” повинна передбачати максимальну незалежність програмно- технічних модулів від розробника таким чином, щоб їх подальшим розвитком могли займатися підрядні організації із відповідним рівнем кваліфікації.

− Інформаційна архітектура ІС “МР” повинна відповідати сучасним вимогам щодо побудови інтерфейсів користувачів.

− ІС “МР” повинна мати механізми щодо кластерізації рішення. Рішення щодо побудови ІС “МР” повинно базуватися на:

− застосуванні сучасних інформаційних технологій;

− реалізації концепції створення єдиного інформаційного простору в м. Києві;

− застосуванні правила централізованого накопичення, зберігання та обробки інформації;

− підтримці актуальності, повноти, несуперечності, цілісності та доступності інформації;

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

− забезпеченні надійності, резервування компонентів технічного забезпечення ІС “МР”;

− забезпеченні централізованого управління, безперервного контролю функціонування та централізованого налаштування ІС “МР” (модулів та компонентів);

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

ІС “МР” повинно мати наступні характеристики та функціональність:

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

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

− забезпечувати механізми для адміністрування користувачів та їх повноважень, а також забезпечувати захист персональних даних відповідно до чинного законодавства України;

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

− обов’язкове документування АPI у відповідності до міжнародних типів специфікацій та екосистем таких як Swagger, RAML, API Blueprint для використання внутрішніми/сторонніми сервісами. Перевага надається засобу, яке передбачає найкращу підтримку на момент розробки компонентів та модулів з точки зору бібліотек, фреймворків, націлених на використання в різних мовах програмування, їх зрілості;

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

− підтримка URL-адресації для будь-яких інформаційних об'єктів (користувач повинна мати можливість отримувати/відправляти прямі URL-посилання на об'єкти системи);

− використання форматів інформаційного обміну даними на основі таких протоколів та стандартів: HTTPS, WMS, WFS, XML, JSON, REST (Restfull).

5.12.5 Вимоги до метрологічного забезпечення

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

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

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

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

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

6. СКЛАД ТА ЗМІСТ НАДАННЯ ПОСЛУГ

6.1. Склад та зміст надання послуг

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

1й Етап

6.1.1 Розробка Технічного завдання

6.1.1.1 Розробка Технічного завдання на модернізацію ІС «МР» з урахуванням:

• розробка Технічного завдання на модернізацію ІС «МР».

6.1.1.2 Розробка Технічного завдання на створення ПМ «РД» з урахуванням:

• розробка Технічного завдання на створення ПМ «РД».

2й Етап

6.1.2 Розробка програмного забезпечення

6.1.2.1 Розробка програмного забезпечення щодо модернізації ІС «МР»

• розробка програмного забезпечення;

• розробка документації:

o Опис системи (стосовно доопрацювань);

o Керівництво Системного адміністратора (розширене);

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

• проведення попередніх випробувань;

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

6.1.2.2 Розробка програмного забезпечення ПМ «РД»

• розробка програмного забезпечення;

• розробка документації:

o Опис ПМ «РД»;

o Керівництво Системного адміністратора;

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

• проведення попередніх випробувань;

• приймання програмного забезпечення ПМ «РД» в дослідну експлуатацію.

3й Етап

6.1.3 Дослідна експлуатація, розробка документації

6.1.3.1 Дослідна експлуатація модернізованого програмного забезпечення ІС

«МР», розробка документації

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

• Інструкція з розгортання та налаштування (стосовно доопрацювань);

• Інструкція з формування та ведення бази даних (стосовно доопрацювань);

• Керівництво Користувача (розширене);

• Керівництво Адміністратора (розширене);

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

6.1.3.2 Дослідна експлуатація програмного забезпечення ПМ «РД», розробка документації

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

• Інструкція з розгортання та налаштування;

• Інструкція з формування та ведення бази даних;

• Керівництво Користувача;

• Керівництво Адміністратора;

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

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

Склад документації з доопрацювання системи МР та зі створення ПМ «РД»:

• Технічне завдання;

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

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

• Опис системи (стосовно доопрацювань) та Опис модулю;

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

• Інструкція з розгортання та налаштування стосовно доопрацювань та модулю;

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

• Керівництво Адміністратора з новою функціональністю з урахуванням модуля;

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

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

Вимоги щодо методичного забезпечення можуть бути уточнені в Технічному завданні.

ЗАМОВНИК ВИКОНАВЕЦЬ