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

Додаток 6

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

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

ДОГОВІР №

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

м. Київ 2018 р.

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

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

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

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

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

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

1.2. Найменування послуги: Розвиток веб-порталу надання електронних послуг, в тому числі адміністративних, 3 черга за кодом ДК 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. Місце надання послуги: м. Київ, вул. Космічна, 12 А, 02192.

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

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

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

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

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

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. На вимогу Виконавця надавати йому інформацію, необхідну для надання послуг за цим Договором;

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

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

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

5.2.1. Достроково розірвати цей Договір, повідомивши про це Виконавця письмово у строк за 20 (двадцять) календарних днів до дати розірвання Договору, узгодивши з Виконавцем усі умови розірвання Договору;

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., п. 2.3 даного Договору;

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

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

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

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

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

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

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

5.3.5. Зареєструвати податкові накладні в Єдиному реєстрі податкових накладних згідно п. 201.1 ст. 201 Податкового кодексу України. Якщо Виконавець порушує зобов’язання по реєстрації податкових накладних в Єдиному реєстрі податкових накладних, він зобов’язаний відшкодувати Замовнику збитки. (Даний пункт Договору є чинним лише за умови, що

Виконавець є платником ПДВ та/або послуги за цим Договором є об’єктом оподаткування ПДВ).

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

6.9. У разі якщо до Замовника та/або Виконавця будуть пред’явлені претензії, позови тощо третіх осіб щодо порушення авторських, патентних прав, комерційних таємниць та інших прав таких третіх осіб щодо послуг, що надаються Виконавцем Замовнику в рамках даного Договору, то Виконавець зобов'язується власними силами та за власний рахунок вирішувати усі претензії та позови таких третіх осіб та відшкодувати Замовнику всі понесені ним витрати в результаті таких претензій, позовів тощо.

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

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

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

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

7.4. У разі відмови Виконавця надати податкову накладну та/або розрахунок коригування кількісних та вартісних показників до податкових накладних та/або порядку їх заповнення, реєстрації в Єдиному реєстрі податкових накладних за цим Договором, Виконавець сплачує Замовнику штраф у розмірі суми ПДВ, включеної до такої податкової накладної та/або розрахунку коригування кількісних та вартісних показників до податкових накладних, але не менше 5000,00 (п’ять тисяч) грн. за кожну податкову накладну та/або розрахунок коригування кількісних та вартісних показників до податкових накладних протягом 30 календарних днів з дати отримання відповідної вимоги Замовника. (Даний пункт Договору є чинним лише за умови, що Виконавець є платником ПДВ та/або послуги за цим Договором є об’єктом оподаткування ПДВ).

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

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

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

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

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

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

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

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

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

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

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

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

11. ІНШІ УМОВИ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

КАЛЕНДАРНИЙ ПЛАН НАДАННЯ ПОСЛУГ*

Календарний план виконання послуг Розвиток веб-порталу надання електронних послуг, в тому числі адміністративних, 3 черга

№ з/п	Найменування етапів послуг	Термін надання послуг	Результат	Вартість послуг без ПДВ, грн.	ПДВ, грн.***	Вартість послуг з ПДВ, грн.
1	Розробка технічного завдання	15 робочих дня з дати отримання письмової заявки від Замовника **	Технічне завдання.
2	Розробка та модернізація програмного забезпечення Системи, розробка документації	40 робочих днів з дати виконання п. 1 та отримання письмової заявки від Замовника	Дослідний зразок програмного забезпечення Веб- порталу, 3 черга, ОКК на площадці Замовника. Опис Системи. Керівництво системного адміністратора. Програма та методика попередніх випробувань. Протокол попередніх випробувань. Акт прийняття в дослідну експлуатацію.
3	Дослідна експлуатація програмного забезпечення Системи, розробка документації	15 робочих днів з дати виконання п. 2 та отримання письмової заявки від Замовника	Програма та методика дослідної експлуатації. Протокол з навчання. Протокол дослідної експлуатації. Керівництво користувача. Керівництво адміністратора.
Загальна вартість пропозиції: разом без ПДВ**, грн.: (зазначається учасником цифрами та прописом); розмір ПДВ**, грн.: (зазначається учасником цифрами та прописом); всього з ПДВ**, грн.: (зазначається учасником цифрами та прописом)

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

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

*** Якщо Учасник є платником ПДВ. У разі, якщо Учасник не є платником податку на додану вартість (предмет закупівлі не є об’єктом оподаткування, звільнений від оподаткування, до предмета закупівлі застосовується нульова ставка ПДВ вказана колонка не заповнюється).

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

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

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

ТЕХНІЧНІ ВИМОГИ (СПЕЦИФІКАЦІЯ)

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

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

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

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

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

В цьому документі наведені технічні та якісні характеристики, перелік та терміни надання послуг з розвитку веб-порталу надання електронних послуг, в тому числі адміністративних, 3 черга (далі – Веб-портал як Презентаційний рівень або Система).

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

Мета розвитку Системи

Метою розвитку Системи є:

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

 удосконалення моделі надання електронних послуг;

 підвищення зручності та конверсії в цілому для кінцевого користувача.

Призначення Системи

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

Веб-портал – це єдина система, де мешканцям та представникам бізнесу міста Києва повинні бути доступні всі міські електронні сервіси.

Цілі розвитку Системи

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

Склад послуг з розвитку Системи

В межах виконання робіт з розвитку Системи повинні бути здійснені наступні заходи:

 Конвергентність у вигляді злиття на презентаційному рівні Веб-порталу та ОКК з логічним поділом сутностей, які можуть бути притаманні Веб-порталу та ОКК або тільки Веб-порталу чи ОКК, що надасть можливість гнучкого використання на логічному рівні Веб-

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

 Часткова модернізація презентаційного рівня (інформаційної архітектури та елементів дизайну) з метою покращення якості користування Веб-порталом, ОКК із здійсненням наступних заходів:

1. Реалізація можливості отримування даних про «мою реєстрацію в РТГК», а саме: розробка електронної послуги «Отримати дані про мою реєстрацію».

2. Реалізація можливості отримування даних про користувачів, які переглядали або змінювали «мої дані», а саме: розробка електронної послуги «Хто переглядав або змінював мої дані».

3. Реалізація можливості покупати єдиний квиток, який діє в муніципальному транспорті міста Києва, а саме: розробка електронної послуги «Електронний квиток».

4. Реалізація можливості замовлення відео-контенту з комплексної системи відеоспостереження міста Києва, а саме: розробка електронної послуги

«Замовлення відео-контенту».

5. Реалізація можливості он-лайн трансляції відео-контенту з закладів дошкільної освіти для батьків (опікунів), а саме: розробка електронної послуги «Он-лайн доступ до відеокамер дитячих садків».

6. Реалізація можливості он-лайн запису на відвідування відкритого пленарного засідання сесії КМР, а саме: розробка електронної послуги «Подати заявку на відвідування відкритого пленарного засідання сесії КМР».

7. Реалізація можливості он-лайн бронювання Колонної зали або Лекторію КМР, а саме: розробка електронної послуги «Подати заявку на проведення заходу в Колонній залі або Лекторію КМР».

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

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

Перелік умовних скорочень

Терміни	Визначення
Access token	Ключ, що формується в результаті авторизації. Містить інформацію з безпеки сеансу та ідентифікує користувача, зовнішню систему та призначені для них привілеї
API	Application Programming Interface, див. xxxxx://xx.xxxxxxxxx.xxx/xxxx/ Xxxxxxxxxx_xxxxxxxxxx_xxxxxxxxx.
Back-end	Бекенд (англ. back-end) – програмно-апаратна частина сервісу. Back-end - розробники будують та підтримують технології, що керують всіма компонентами архітектури програмного забезпечення.
BankID	Спосіб електронної ідентифікації користувачів через українські банки для надання адміністративних та інших послуг через Інтернет.
Data	Тип даних. Служить для представлення дати.
Database, База даних, БД	Сукупність даних, організованих відповідно до концепції, яка описує характеристику цих даних і взаємозв'язки між їх елементами; ця сукупність підтримує щонайменше одну з областей застосування.
INT	Цілочисельний тип даних ( англ. Integer) Служить для представлення цілих чисел. Набір чисел цього типу являє собою кінцеву підмножину нескінченної кількості цілих чисел, обмежених максимальним і мінімальним значеннями.
ISIC, NACE	Міжнародна стандартна галузева класифікація всіх видів економічної діяльності.
JSON	Текстовий формат обміну даними, заснований на JavaScript.

Терміни	Визначення
KyivID	Унікальний ідентифікатор, який присвоюється користувачу, що є одержувачем (зокрема потенційним одержувачем) послуг, заходів соціальної підтримки та служить персональним електронним ключем.
Scope	Набір повноважень та перелік даних, які отримує користувач або ЗІС при роботі з модулями платформи.
UI	Інтерфейс користувача (англ. User Interface).
VARCHAR(n)	Строковий тип змінної довжини. Аргумент (n) визначає довжину рядка та може приймати значення від 1 до 8000
Автентифікація	Електронна процедура, яка дає можливість підтвердити електронну ідентифікацію фізичної особи та/або походження і цілісність електронних даних.
Авторизація	Процедура надання особі/процесу прав на виконання певних дій або доступу до ресурсів, а також процес перевірки (підтвердження) прав при спробі виконання цих дій.
Адміністратор	Користувач, якому надано право визначати та призначати рівні доступу, ролі, вносити логіни та паролі.
Будинок	Житловий об’єкт нерухомості, що є невід’ємною частиною адреси.
Валідація	Процес підтвердження відповідності, затвердження, легалізації.
Веб-портал	Веб-портал електронних послуг, в тому числі адміністративних. Веб-портал – це єдина система, де жителям / гостям / представникам бізнесу міста Києва будуть доступні всі міські електронні сервіси, в тому числі адміністративні.
Відео-контент	Записане та надане КП ГІОЦ відео зображення з відеокамер, які обслуговує КП Інформатика.
Вулиця	Лінійно-протяжний планувальний елемент, що забезпечує рух транспорту і пішоходів та є невід’ємною частиною адреси.
ДРФО	Державний реєстр фізичних осіб – платників податків.
ЄДР	Єдиний державний реєстр підприємств та організацій України.
ЕЦП, Електронний цифровий підпис	Вид електронного підпису, отриманого за результатом криптографічного перетворення набору електронних даних, який додається до цього набору або логічно з ним поєднується і дає змогу підтвердити його цілісність та ідентифікувати підписанта. Електронний цифровий підпис накладається за допомогою особистого ключа та перевіряється за допомогою відкритого ключа.
Електронна послуга	Електронна послуга – це послуга, яка реалізує технологію віддаленого / дистанційного обслуговування населення, бізнесу міста Києва через ОКК.
Житель, фізична особа	Громадянин, який зареєстрований, мешкає, працює у м. Києві, гості м. Києва.
ЗАТ	Закрите Акціонерне товариство
ЗПЗ	Загальносистемне програмне забезпечення.
Ідентифікація	Процедура присвоєння ідентифікатора об’єкту або встановлення відповідності між об’єктом і його ідентифікатором; впізнання об’єкта системою.
Ім’я	Особиста назва людини, що дається їй після народження. Ім’я – це частина повного імені жителя.
ІПН	Індивідуальний податковий номер.
Квартира	Квартира – ізольоване помешкання в жилому будинку, призначене для проживання фізичних осіб. Номер квартири – це складова частина адреси.
КВЕД	Класифікатор видів економічної діяльності.
КМДА	Київська міська державна адміністрація.
КМР	Київська міська рада.

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

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

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. ФУНКЦІОНАЛЬНІ ВИМОГИ ЩОДО РОЗВИТКУ СИСТЕМИ Загальні вимоги

Зв'язок 1-ї, 2-ї, 3-ї черги розвитку Системи див. на рисунку 1.

Рисунок 1. Зв'язок 1-ї, 2-ї, 3-ї черги розвитку Системи

На Рисунку (Див. Рисунок 1 - Зв'язок 1-ї, 2-ї, 3-ї черги розвитку Системи) показано ключові сутності – Веб-порталу та ОКК, де:

ОКК – це Особистий Кабінет Киянина.

Веб-портал – це Веб-портал надання електронних послуг, у тому числі адміністративних.

ПМ АК – це Програмний Модуль «Активний киянин».

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

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

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

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

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

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

Передбачається, що Система взаємодіятиме (інтегруватиметься) у вигляді обміну певними наборами даних з такими рішеннями *:

 платформа надання електронних послуг;

 РТГК;

 МР;

 Система Електронний квиток;

 стрім-сервер відеоконтенту;

 внутрішній корпоративний портал КМДА;

* Примітка!

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

Вимоги до електронної послуги «Отримати дані про мою реєстрацію» Вимоги до функціональних можливостей

Електронна послуга «Отримати дані про мою реєстрацію» доступна тільки фізичним

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

Жителю міста Києва необхідно на презентаційному рівні ОКК обрати відповідну електронну послугу, де він буде мати можливість ознайомитись з інформацією та правилами надання даної електронної послуги. Далі житель міста Києва повинен замовити дану електронну послугу, тобто заповнити і направити запит до МР на отримання інформації щодо його місця реєстрації проживання/перебування, якщо він виконав ідентифікацію через ЕЦП або BankID. В іншому випадку під час замовлення даної електронної послуги Користувачу ОКК виводиться відповідна нотифікація.

Схема функціонального рішення електронної послуги «Отримати дані про мою реєстрацію» наведено на Рисунку 2.

Сервіс авторизації

1. УНЗР

2. ПІБ +дата

ОКК народження

2. ПІБ + паспорт

житель міста

Києва (фізична особа)

МР

Жителі Користувачі

Місце реєстрації /

перебування

KyivID

KyivID

Місце реєстрації /

перебування

Замовлення

Електронної послуги

Статуси

Електронної послуги

Презентаційний

рівень ОКК

Електронні послуги

Бек-енд ОКК

 Сервіс обміну даними з МР

РТГК

Жителі

Реєстрація

ЕЦП

BankID

Рисунок 2. Схема функціонального рішення електронної послуги «Отримати дані про мою реєстрацію»

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

На стороні МР після отримання запиту з вхідними даними (номер замовлення та KyivID) повинен здійснюватися пошук даних жителя по KyivID. В залежності від результату пошуку можливі два сценарії подальшого розвитку:

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

 по факту позитивного результату пошуку даних жителя по KyivID відбувається надсилання даних до ОКК.

Користувач ОКК (виконана успішно ідентифікація жителя за допомогою методу ЕЦП або BankID) в «Журналі операцій» повинен мати можливість переглядати результат отримання послуги, коли статус замовленої послуги зміниться на «Завершено». Для цього потрібно натиснути відповідний рядок відповідної послуги в «Журналі Операцій», після чого відкриється форма, на якій буде відображена інформація про місце реєстрації користувача:

 ПІБ користувача ОКК;

 адреса останнього місця реєстрації користувача ОКК;

 дата останнього місця реєстрації користувача ОКК.

У випадку отримання від МР повідомлення про відсутність даних, повинно відбуватися відображення інформації про відсутність даних реєстрації.

Після відображення відповіді процес завершується остаточно.

Склад послуг

Для реалізації електронної послуги «Отримати дані про мою реєстрацію» необхідно реалізувати таке:

 Розробити презентаційний рівень електронної послуги «Отримати дані про мою реєстрацію».

 Розробити сервіс обміну даними з МР для електронної послуги «Отримати дані про мою реєстрацію».

Вимоги до презентаційного рівня ОКК

На презентаційному рівні ОКК користувачу повинні бути доступними наступні можливості за умови виконання ідентифікації через ЕЦП або BankID:

 заповнення та відправка до МР заявки на отримання електронної послуги

«Отримати дані про мою реєстрацію»;

 відображення, в якому статусі знаходиться заявка Користувача ОКК;

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

Необхідно на презентаційному рівні ОКК, в розділі «Каталог послуг» – «Реєстрація місця проживання / перебування» додати електронну послугу «Отримати дані про мою реєстрацію».

Рисунок 3. Прототип форми можливості вибору електронної послуги «Отримати дані про мою реєстрацію»

Відповідно повинні бути сформовані і заповнені додаткові сторінки з інформацією про «Опис» електронної послуги згідно прикладу, наведеному на Рисунку 4:

Рисунок 4. Прототип форми Опису електронної послуги

Для отримання послуги жителю потрібно виконати ідентифікацію за допомогою методу ЕЦП або Bank ID та надати дозвіл щодо використання/передачі його персональних даних.

Користувачу ОКК потрібно натиснути кнопку «Замовити послугу», після чого повинна бути відображена форма підтвердження замовлення (див. Рисунок 5. Прототип форми підтвердження замовлення).

Рисунок 5. Прототип форми підтвердження замовлення

При натисканні кнопки «Ні» відбувається повернення до сторінки замовлення послуги.

Кнопка «Так» стає доступною при виборі одного з методів ІАА жителя – ЕЦП або BankID, шляхом встановлення відмітки відповідного методу.

При виборі методу ЕЦП та натисканні кнопки «Так», користувач повинен переходити на екран вибору типу центру сертифікації ключів (ЦСК), введення особистого ключа та паролю захисту ключа.

При виборі методу BankID та натисканні кнопки «Так», користувач повинен переходити на екран вибору Банку та введення логіну і паролю.

У випадку успішної авторизації методом ЕЦП або BankID, користувач ОКК в

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

 ПІБ користувача ОКК;

 адреса останнього місця реєстрації користувача ОКК;

 дата останнього місця реєстрації користувача ОКК.

Модель даних сутності Житель. РТГК

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

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

Структуру сутності наведено на Рисунку 6.

Особисті дані			Житель. РТГК			Дані по реєстрації
	Прізвище	Особисті дані		Країна
Ім'я			Дані документів		Область
	По батькові	Дані по реєстрації		Район
Стать			УНЗР		Населений пункт
Дата народження	Згода на обробку даних	Адміністративний район
			Громадянство	Місце народження	Вулиця
Дані документів				Будинок
					Місце народження		Літера будинку
			Тип документу
Квартира
			Серія	Країна
Дата реєстрації
			Номер	Область
Згода на обробку даних
			Дата видачі	Район
					Ким виданий	Населений пункт	Дата згоди
Дата дії								Час згоди
						Посилання на текст згоди
						ЗІС в якій надана згода

Рисунок 6. Структура сутності Житель. РТГК

Деталізацію інформації щодо атрибутивного складу сутності Житель (що підтримується в РТГК) буде надано Замовником Виконавцю після підписання NDA.

Вимоги до сервісу обміну даними з МР

Для можливості обміну даних між ОКК та МР необхідно створити сервіс обміну даними з МР.

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

 можливість ОКК надавати запит до МР щодо даних реєстрації користувача ОКК;

 можливість ОКК отримувати дані від МР щодо даних реєстрації користувача ОКК.

Опис сервісу обміну даними з МР:

 вхідні дані:

o номер замовлення;

o KyivID користувача ОКК;

 отримання відповіді по замовленню від МР:

o номер замовлення;

o адреса останнього місця реєстрації користувача ОКК;

o дата останнього місця реєстрації користувача ОКК.

Вимоги щодо надання електронної послуги «Отримати дані про мою реєстрацію» повинні бути уточнені в Технічному завданні.

Вимоги до електронної послуги «Хто переглядав або змінював мої дані» Вимоги до функціональних можливостей

Електронна послуга «Хто переглядав або змінював мої дані» доступна тільки для

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

даними Користувача ОКК.

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

Схема функціонального рішення електронної послуги «Хто переглядав або змінював мої дані» наведено на Рисунку 7.

ЕЦП

BankID

	Бек-енд ОКК  Сервіс обміну даними з МР  Сервіс обміну даними з РТГК
Статуси Електронної послуги
1. УНЗР 2. ПІБ+дата народження		Перелік організацій, які переглядали дані Користувача ОКК

Сервіс

авторизації

ОКК

1. УНЗР

2. ПІБ+дата

народження

3. ПІБ+паспорт

житель міста

Києва (фізична особа)

МР

Жителі

Користувачі

Місце реєстрації /

перебування

РТГК

Жителі

Реєстрація

KyivID

KyivID

Місце реєстрації /

перебування

Замовлення

Електронної послуги

3. ПІБ+паспорт

РТГК

Жителі

Реєстрація

Презентаційний

рівень ОКК

Електронні

послуги

Рисунок 7. Схема функціонального рішення електронної послуги

«Хто переглядав або змінював мої дані»

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

На стороні МР після отримання запиту з вхідними даними (номер замовлення та KyivID) повинен здійснюватися пошук даних жителя по KyivID. За результатами запиту МР часткового або повністю повертає наступні дані:

 УНЗР

 ПІБ+дата народження

 ПІБ+серія та номер паспорту.

У випадку отримання від МР повідомлення про відсутність даних, повинно відбуватися відображення інформації про відсутність даних реєстрації.

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

Користувач ОКК (виконана успішно ідентифікація жителя за допомогою методу ЕЦП

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

 номер замовлення;

 тип операції з даними;

 дата операції;

 хто виконував операцію (підприємство, організація або установа, яка виконувала операції з даними).

У випадку отримання від МР повідомлення про відсутність даних, повинно відбуватися відображення інформації про відсутність даних реєстрації.

Після відображення відповіді процес завершується остаточно.

Склад послуг

Для реалізації електронної послуги «Хто переглядав або змінював мої дані» необхідно реалізувати функціональні можливості:

 Розробити сервіс обміну даними з МР для електронної послуги «Хто переглядав або змінював мої дані».

 Розробити сервіс обміну даними з РТГК для електронної послуги «Хто переглядав або змінював мої дані»;

 Розробити презентаційний рівень електронної послуги «Хто переглядав або змінював мої дані».

Вимоги до презентаційного рівня ОКК

Опис вимог аналогічний, як описано в п. 3.2.3.

Модель даних, структура сутності Житель. РТГК

Модель даних сутності Житель. РТГК описана в розділі 3.2.4. Структура сутності Житель. РТГК описана в розділі 3.2.5.

Вимоги до сервісу обміну даними з МР Опис вимог аналогічний, як описано в п. 3.2.6. Вимоги до сервісу обміну даними з РТГК

Для можливості обміну даних між ОКК та РТГК необхідно створити сервіс обміну даними з РТГК.

В рамках реалізації сервісу обміну даними з РТГК повинно бути доступно:

 можливість ОКК надавати запит до РТКГ щодо перегляду та змін даних користувача ОКК;

 можливість ОКК отримувати дані про підприємства, організації та установи КМДА, співробітники яких переглядали або змінювали дані жителів міста Києва.

Опис сервісу обміну даними з РТГК:

 вхідні дані:

o номер замовлення;

o УНЗР;

o ПІБ + дата народження;

o ПІБ + паспорт (інший документ). Отримання відповіді по замовленню від РТКГ:

o номер замовлення;

o тип операції з персональними даними (перегляд, змінена);

o дата операції;

o підприємство, організація або установа, яка виконувала операції з даними. Вимоги щодо надання електронної послуги «Хто переглядав або змінював мої дані»

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

Вимоги до електронної послуги «Електронний Квиток» Вимоги до функціональних можливостей

Електронна послуга «Електронний Квиток» доступна тільки для фізичних осіб міста

Києва для замовлення електронної транспортної послуги.

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

Схема функціонального рішення електронної послуги «Електронний Квиток» наведена на Рисунку 8.

ЕЦП

BankID

житель міста

Сервіс авторизації

ОКК

1. УНЗР

РТГК

Жителі

Реєстрація

Києва (фізична особа)

Презентаційний

рівень ОКК

Електронні послуги

KyivID

Замовлення Е-послуги Статуси Е-послуги

Замовлення квитків

Електронний

квиток

Історія використання квитків

2. ПІБ+дата

народження

3. ПІБ+паспорт

МР

Жителі Користувачі

Бек-енд ОКК

 Сервіс обміну даними з системою Електронного квитка

 Сервіс обміну даними з МР

Інформація щодо наявної пільги

KyivID

Місце реєстрації / перебування

Рисунок 8. Схема функціонального рішення електронної послуги «Електронний Квиток»

Можливі варіанти виконання електронної послуги «Електронний квиток».

1. В основу замовлення електронної послуги Електронний квиток з урахуванням наявності пільг / без наявності пільг у користувача ОКК покладено взаємодію ОКК, МР та системи Електронного квитка, якщо житель міста Києва виконав ідентифікацію через ЕЦП або BankID.

На стороні МР після отримання запиту з вхідними даними (номер замовлення та KyivID) повинен здійснюватися пошук даних жителя по KyivID. В залежності від результату пошуку можливі два сценарії подальшого розвитку:

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

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

ОКК повинен відправити запит до системи Електронний квиток на доступність транспортних продуктів з врахуванням наявності пільг. По результату відпрацювання запиту на презентаційному рівні ОКК повинна бути доступна можливість придбати електронний квиток.

2. В основу замовлення електронної послуги Електронний квиток жителем міста Києва покладено взаємодію ОКК та системи Електронного квитка, якщо житель міста Києва не виконав ІАА або використовував ІАА через довільний власний акаунт (номер мобільного телефону, e-mail, Facebook, Google, LinkedIn)

ОКК повинен відправити запит до системи Електронний квиток на доступність транспортних продуктів з врахуванням наявності пільг. По результату відпрацювання запиту на презентаційному рівні ОКК повинна бути доступна можливість придбати електронний квиток.

Склад послуг

Для реалізації електронної послуги «Електронний квиток» необхідно виконати таке:

 Розробити сервіс обміну даними з МР для електронної послуги «Електронний квиток».

 Розробити презентаційний рівень електронної послуги «Електронний квиток».

 Розробити сервіс обміну даними з системою Електронний квиток;

 На презентаційному рівні ОКК реалізувати можливості:

o додавання транспортної картки;

o поповнення електронного гаманця;

o придбання проїзного;

o придбання QR-квитка;

o придбання одноразових квитків;

o отримання інформації щодо історії платежів;

o отримання інформації щодо історії поїздок;

o отримання інформації щодо квитків Користувача ОКК;

o заміна втраченої транспортної картки на іншу зі збереженням наявних Транспортних продуктів.

Модель даних сутності Е-Квиток

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

Структура сутності Е-Квиток

Структуру сутності Е-Квиток наведено на Рисунку 8.

Маршрут

Тип транспортного засобу

Вартість

Час використання

Дата купівлі

Дата використання

Використання продукту

Тип продукту

Строк дії

Статус пільги

Використання продукту

Назва продукту

Сума оплати

Транспортний продукт

Транспортний продукт

Дата оплати

Картка

Строк дії картки

Пільги

Користувач

Дата активації

Користувач в АСОП

Е-Квиток

ID Транспортної картки

KyivID

Картка

Користувач

Рисунок 8. Структура сутності Е-Квиток

Деталізацію інформації щодо атрибутивного складу сутності Е-Квиток буде надано Замовником Виконавцю після підписання NDA.

Вимоги до сервісу обміну даними з системою Електронного квитка

Для можливості обміну даних між ОКК та системою Електронного квитка необхідно створити сервіс обміну даними з системою Електронного квитка.

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

 можливість ОКК надавати інформацію до системи Електронного квитка щодо даних про наявність пільг у користувача ОКК;

 можливість ОКК отримувати дані від системи Електронного квитка щодо даних про доступність транспортних продуктів користувачу ОКК / жителю міста Києва;

 можливість ОКК надавати інформацію до системи Електронного квитка щодо даних про вибір транспортного продукту;

 можливість ОКК отримувати дані від системи Електронного квитка щодо придбаного транспортного продукту.

Вимоги до сервісу обміну даними з МР

Для можливості обміну даними між ОКК та МР необхідно створити сервіс обміну даними з МР.

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

 можливість ОКК надавати запит до МР щодо даних про наявність пільг у користувача ОКК;

 можливість ОКК отримувати дані від МР щодо даних про наявність пільг користувача ОКК.

Опис сервісу обміну даними з МР:

 вхідні дані:

o номер замовлення;

o KyivID користувача ОКК;

 отримання відповіді по замовленню від МР:

o номер замовлення;

o пільги користувача ОКК.

Вимоги щодо надання електронної послуги «Електронний квиток» повинні бути уточнені в Технічному завданні.

Вимоги до електронної послуги «Замовлення відео-контенту з комплексної системи відеоспостереження міста»

Вимоги до функціональних можливостей

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

Жителю міста Києва необхідно на презентаційному рівні ОКК вибрати відповідну електронну послугу, де він буде мати можливість ознайомитись з інформацією та правилами надання даної електронної послуги. Далі житель міста Києва повинен замовити дану електронну послугу, тобто заповнити і направити заявку на Платформу надання електронних послуг для опрацювання заявки «КП Інформатика» для надання відео-контенту користувачу ОКК, якщо він виконав ідентифікацію через ЕЦП або BankID. В іншому випадку під час замовлення даної електронної послуги Користувачу ОКК виводиться відповідна нотифікація.

Схема функціонального рішення електронної послуги «Замовлення відео-контенту з комплексної системи відеоспостереження міста» наведено на Рисунку 9.

ЕЦП

BankID

Сервіс авторизації

ОКК

житель міста

Києва (фізична особа)

KyivID

1. Дані камери

1. Пошук камери 2. Статус

2. Замовлення відео замовлення

Камери

Відео контент

Презентаційний

рівень ОКК

Електронні послуги

Бек-енд ОКК

 Сервіс обміну даними з Платформою надання електронних послуг ПМ

«Системою замовлення відео»

Платформа надання

електронних послуг

ПМ «Система

замовлення відео»

 Камери

 Замовлення

Рисунок 9. Схема функціонального рішення електронної послуги

«Замовлення відео-контенту з комплексної системи відеоспостереження міста»

В основу замовлення електронної послуги «Замовлення відео-контенту з комплексної системи відеоспостереження міста» покладено взаємодію ОКК, Платформою надання електронних послуг ПМ Системою замовлення відео (далі – СЗВ).

По факту початку замовлення даної електронної послуги ОКК повинен відправляти запит до СЗВ на отримання доступних відеокамер, кутом огляду.

На презентаційному рівні ОКК повинен надавати можливість вибирати локацію розміщення камери, перегляд кута огляду камери та заповнювати дату та час «з – по» необхідного відео-контенту, оплатити та відправити заявку на Платформу надання електронних послуг для опрацювання заявки «КП Інформатика» для надання відео-контенту користувачу ОКК, якщо він виконав ідентифікацію через ЕЦП або BankID.

У випадку успішної авторизації методом ЕЦП або BankID, користувач ОКК в

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

на якій буде відображена інформація про замовлений відео-контент.

Склад послуг

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

 Розробити сервіс обміну даними з СЗВ для електронної послуги «Замовлення відео-контенту з комплексної системи відеоспостереження міста»;

 Розробити презентаційний рівень електронної послуги «Замовлення відео- контенту з комплексної системи відеоспостереження міста».

Вимоги до сервісу обміну даними з СЗВ

Для можливості обміну даних між ОКК та СЗВ необхідно створити сервіс обміну даними з СЗВ.

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

 можливість ОКК надавати запит до СЗВ щодо даних локації / локацій камер;

 можливість ОКК отримувати дані від СЗВ щодо даних про доступні камери, про камери, кут огляду.

 можливість ОКК відправляти заявку до СЗВ;

 можливість ОКК отримувати замовлений відео контент від СЗВ.

Опис сервісу обміну даними з СЗВ для отримання даних щодо даних по камерам:

 вхідні дані:

o номер замовлення;

o KyivID користувача ОКК;

 отримання відповіді по замовленню від СЗВ:

o номер замовлення;

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

o дані про камери з врахуванням куту огляду.

Опис сервісу обміну даними з СЗВ для можливості роботи з заявкою:

 вхідні дані:

o номер замовлення;

o KyivID користувача ОКК;

o ID камери;

o Дата та час (з – по)

 отримання відповіді по замовленню від СЗВ:

o номер замовлення;

o відео контент.

Вимоги щодо надання електронної послуги «Замовлення відео-контенту з комплексної системи відеоспостереження міста» повинні бути уточнені в Технічному завданні.

Вимоги до електронної послуги «Он-лайн доступ до відеокамер дитячих садків» Вимоги до функціональних можливостей

Електронна послуга «Он-лайн доступ до відеокамер дитячих садків» доступна тільки фізичним особамміста Києва для можливості перегляду стріму відео-контенту з дитячих садків.

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

ЕЦП або BankID. В іншому випадку під час замовлення даної електронної послуги Користувачу ОКК виводиться відповідна нотифікація.

Схема функціонального рішення електронної послуги «Он-лайн доступ до камер дитячих садків» наведено на Рисунку 10.

житель міста

Презентаційний

рівень ОКК

Електронні послуги

Києва (фізична особа)

Сервіс авторизації ОКК

ЕЦП

BankID

KyivID

Камери

Відео стрім

1. Доступні локації

2. Вибрана камера

Користувач

Стрім Сервер

 Камери

 Локації

1. Камери з локації

2. Відео стрім з

Бек-енд ОКК

 Сервіс обміну даними з Стрім Сервером

 Сервіс обміну даними з МР

камери

Доступні локації

МР

 Батьки

 Локації

Рисунок 20. Схема функціонального рішення електронної послуги

«Он-лайн доступ до камер дитячих садків»

В основу замовлення електронної послуги «Он-лайн доступ до відеокамер дитячих садків» покладено взаємодію ОКК, стрім серверу та МР.

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

ОКК по факту отримання від МР інформації щодо локації / локацій дитячих садків повинен мати можливість відправляти запит до стрім серверу на отримання даних по стрім камерам.

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

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

Склад послуг

Для реалізації електронної послуги «Он-лайн доступ до відеокамер дитячих садків» необхідно реалізувати функціональні можливості:

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

 Розробити сервіс обміну даними з МР для електронної послуги «Онлайн доступ до відеокамер дитячих садків»;

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

Модель даних Стрім

Модель Стрім – це група параметрів, що безпосередньо стосується сутності Стрім і утворюють логічну структуру.

Структура сутності Стрім

Структуру сутності Стрім наведено на Рисунку 11.

Зображення з камери

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

Термін збереження відео

Будинок

Дата встановлення

Вулиця

Тип камери

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

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

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

ІПН

Камера

Адреса дитячого садка

По батькові

Камера

Посилання на відео стрім

Ім'я

Прізвище

Адреса дитячого садка

Локація

Ідентифікатор дитячого садка

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

KyivID

Локація

Стрім

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

Рисунок 31. Структура сутності Стрім

Деталізацію інформації щодо атрибутивного складу сутності Стрім буде надано Замовником Виконавцю після підписання NDA.

Вимоги до сервісу обміну даними з стрім сервером

Для можливості обміну даних між ОКК та стрім сервером необхідно створити сервіс обміну даними зі стрім сервером.

В межах реалізації сервісу обміну даними зі стрім сервером повинно бути доступно:

 можливість ОКК надавати запит до стрім серверу щодо даних про доступні відеокамери;

 можливість ОКК отримувати дані від стрім серверу щодо даних про камери, кут огляду.

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

 вхідні дані:

o номер замовлення;

o KyivID користувача ОКК;

 отримання відповіді по замовленню від МР:

o номер замовлення;

o дані про камери з врахуванням куту огляду.

Вимоги до сервісу обміну даними з МР

Для можливості обміну даними між ОКК та МР необхідно створити сервіс обміну даними з МР.

В межах реалізації сервісу обміну даними зі стрім сервером повинно бути доступно:

 можливість ОКК надавати запит до МР на перевірку, що в користувача ОКК дитина ходить до дитячого садку, локацію дитячого садка;

 можливість ОКК отримувати дані від МР щодо даних про локацію дитячого садка.

Опис сервісу обміну даними з МР:

 вхідні дані:

o номер замовлення;

o KyivID користувача ОКК;

 отримання відповіді по замовленню від МР:

o номер замовлення;

o локація / локації дитячих садків.

Вимоги щодо надання електронної послуги «Он-лайн доступ до відеокамер дитячих садків» повинні бути уточнені в Технічному завданні.

Вимоги до електронної послуги «Заява на відвідування відкритого пленарного засідання сесії КМР»

Вимоги до функціональних можливостей

Електронна послуга «Заявка на відвідування відкритого пленарного засідання сесії КМР» доступна для використання фізичними особами міста Києва для можливості відвідати відкриті пленарні засідання сесії КМР без потреби подавати Заявку в паперовому вигляді.

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

ЕЦП

BankID

Схема функціонального рішення електронної послуги «Заявка на відвідування відкритого пленарного засідання сесії КМР» наведено на Рисунку 12.

Сервіс авторизації

ОКК

житель міста

Києва

(фізична особа)

KyivID

Заявка

Інформація щодо

можливості відвідування

пленарного засідання

Замовлення

Електронної послуги

Статуси Електронної послуги

Презентаційний

рівень ОКК

Електронні послуги

Бек-енд ОКК

 Сервіс обміну даними з Внутрішнім корпоративним порталом КМДА

Внутрішній

корпоративний

портал КМДА

Рисунок 12. Схема функціонального рішення електронної послуги

«Заявка на відвідування відкритого пленарного засідання сесії КМР»

В основу реалізації електронної послуги «Заявка на відвідування відкритого пленарного засідання сесії КМР» покладено взаємодію ОКК, Внутрішнього корпоративного інформаційного порталу, Сайту КМР.

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

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

Користувач ОКК повинен мати можливість перегляду Заявки та її статусу на презентаційному рівні ОКК у розділі «Журнал операцій».

Користувач може переглянути на сайті КМР Відкритий перелік відвідувачів відповідного пленарного засідання з даними про отримання ними перепусток.

Склад послуг

Для реалізації електронної послуги «Заявка на відвідування відкритого пленарного засідання сесії КМР» необхідно:

 Розробити презентаційний рівень електронної послуги «Заявка на відвідування відкритого пленарного засідання сесії КМР».

 Розробити сервіс обміну даними з Внутрішнім корпоративним інформаційним порталом КМДА для електронної послуги «Заявка на відвідування відкритого пленарного засідання сесії КМР»:

o можливість ОКК надавати запит до Внутрішнього корпоративного інформаційного порталу та отримувати дані щодо переліку відкритих пленарних засідань сесій КМР з зазначенням для кожного засідання: дата, час; місце проведення; порядок денний;

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

Вимоги до презентаційного рівня ОКК

В межах модернізації Веб-порталу, ОКК та впровадження електронної послуги «Заява на відвідування відкритого пленарного засідання сесії КМР» у відповідності до «Порядку доступу до пленарних засідань сесій КМР» (далі – Порядок), повинні бути враховані наступні вимоги:

 На Веб-порталі електронних послуг в розділі Каталогу послуг «Електронна демократія» необхідно додати електронну послугу «Заява на відвідування відкритого пленарного засідання сесії КМР»;

 Обрання послуги;

 Виконання ІАА жителя міста Києва з застосуванням Сервісу авторизації ОКК засобами ЕЦП або Bank ID;Перегляд переліку відкритих пленарних засідань сесій КМР доступних для відвідування;

 Вибір відповідного пленарного засідання;

 Заповнення форми Заяви встановленого зразка:

o ПІБ (автоматично);

o Місце проживання;

o Номер телефону;

o Електронна пошта;

o Питання порядку денного;

 Отримання підтвердження про реєстрацію Заяви;

 Перегляд відкритого переліку відвідувачів, опублікованого на сайті КМР.

Вимоги щодо надання електронної послуги «Заява на відвідування відкритого пленарного засідання сесії КМР» повинні бути уточнені в Технічному завданні.

Вимоги до електронної послуги «Заявка на проведення заходу в Колонній залі та/або Лекторії КМР»

Вимоги до функціональних можливостей

Електронна послуга «Заявка на проведення заходу в Колонній залі та/або Лекторії КМР» доступна для використання юридичними особами міста Києва для можливості проведення заходу в Колонній залі та/або Лекторії КМР без потреби подавати Заявку в паперовому вигляді.

Юридичній особі міста Києва необхідно на презентаційному рівні ОКК обрати відповідну електронну послугу, де він буде мати можливість ознайомитись з інформацією та правилами надання даної електронної послуги. Далі юридична особа міста Києва повинна замовити дану електронну послугу, тобто заповнити і направити запит до Внутрішнього корпоративного порталу КМДА для опрацювання заявки співробітниками КМР для можливості проведення заходу в Колонній залі та/або Лекторії КМР, якщо він виконав ідентифікацію через ЕЦП або BankID. В іншому випадку під час замовлення даної електронної послуги Користувачу ОКК виводиться відповідна нотифікація.

ЕЦП

BankID

Схема функціонального рішення електронної послуги «Заявка на проведення заходу в Колонній залі та/або Лекторії КМР» наведено на Рисунку 13.

Сервіс авторизації

ОКК

юридична особа

міста Києва

KyivID

Заявка

Інформація щодо

можливості на проведення заходу в Колонній залі та/або Лекторію КМР

Замовлення

Електронної послуги

Статуси

Електронної послуги

Презентаційний

рівень ОКК

Електронні

послуги

Бек-енд ОКК

 Сервіс обміну даними з Внутрішнім корпоративним порталом КМДА

Внутрішній

корпоративний

портал КМДА

Рисунок 13. Схема функціонального рішення електронної послуги

«Заявка на проведення заходу в Колонній залі та/або Лекторію КМР»

В основу реалізації електронної послуги «Заявка на проведення заходу в Колонній залі та/або Лекторії КМР» покладено взаємодію ОКК, Внутрішнього корпоративного інформаційного порталу.

Для отримання електронної послуги «Заявка на проведення заходу в Колонній залі та/або Лекторії КМР» представнику юридичної особи (далі- користувачу ОКК) потрібно підтвердити свої данні через ЕЦП або Bank ID та надати дозвіл щодо використання/передачі його персональних даних. Після успішного виконання ІАА одним з зазначених засобів, Система надає можливість користувачу ОКК заповнити електронну форму Заявки з доступом для обрання дати та часу заходу до «Календарю заходів», в якому відмічені вільні дати для проведення заходів та дати, які мають позначку «Подана Заявка» (доступні до вибору), «Підтверджено попереднє бронювання дати» (недоступні для вибору) та «Дата заходу остаточно підтверджена» (недоступні для вибору).

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

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

Система (Внутрішній корпоративний інформаційний портал) реєструє Заявку та направляє її на модерацію.

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

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

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

Якщо користувач підтвердив проведення заходу, цільова Система змінює статус дати, часу заходу з «Подана Заява» на «Підтверджено попереднє бронювання дати, часу» та надсилає відповідне повідомлення в ОКК разом з інструкцією щодо остаточного підтвердження дати проведення заходу. Для остаточного підтвердження дати проведення

заходу заявник протягом 5 днів з дати отримання повідомлення повинен особисто подати необхідні документи до КМР та пройти відповідний інструктаж.

Модератор приймає документи, проводить інструктаж та вносить у Систему позначку про остаточне підтвердження дати проведення заходу.

Система змінює статус дати, часу заходу на «Остаточно підтверджена дата, час проведення заходу», відправляє відповідне повідомлення заявнику, та відображає ці зміни у

«Календарю заходів».

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

Система знімає в «Календарі заходів» з відповідної дати заходу позначки «Подана Заява» та надсилає Користувачу ОКК повідомлення про відмову в проведенні заходу.

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

Склад послуг

Для реалізації електронної послуги «Заява на проведення заходу в Колонній залі та/або Лекторії КМР» необхідно реалізувати наступні функціональні можливості:

 Розробити презентаційний рівень електронної послуги «Заява на проведення заходу в Колонній залі та/або Лекторії КМР».

 Розробити сервіс обміну даними з Внутрішнім корпоративним інформаційним порталом для електронної послуги «Заява на проведення заходу в Колонній залі та/або Лекторії КМР»;

o можливість Веб-порталу електронних послуг, ОКК надавати запит та отримувати дані щодо «Календарю заходів»;

o можливість Веб-порталу електронних послуг, ОКК передавати дані Заявки користувача та отримувати підтвердження про її реєстрацію та інші статуси її опрацювання Модератором.

Вимоги до презентаційного рівня ОКК

В рамках модернізації Веб-порталу, ОКК та впровадження електронної послуги

«Заява на проведення заходу в Колонній залі та/або Лекторії КМР» у відповідності до

«Порядку використання Київською міською радою Колонної зали та Лекторію для проведення заходів» (далі – Порядок) повинні бути враховані наступні вимоги:

 На Веб-порталі в розділі Каталогу послуг «Електронна демократія» необхідно додати електронну послугу «Заява на проведення заходу в Колонній залі та/або Лекторії КМР»;

 Обрання послуги;Заповнення форми Заяви встановленого зразка;

 Надання для обрання дати та часу заходу «Календарю заходів» з відміткою вільних дат для проведення заходів та дат, які мають позначку «Подана Заявка» (доступні до вибору), «Підтверджено попереднє бронювання дати» (недоступні для вибору) та «Дата заходу остаточно підтверджена» (недоступні для вибору);

 Обрання дати та часу проведення заходу (поля «з», «до») з тих, що доступні для вибору;

 Отримання нотифікації про реєстрацію Заяви з фіксацією дати та часу заходу у

«Календарі заходів» як «Подана Заява» та інші статуси стосовно опрацювання Заяви;

 Перегляд статусів Заяви, отриманої протягом її опрацювання.

Вимоги щодо надання електронної послуги «Заява на проведення заходу в Колонній залі та/або Лекторії КМР» повинні бути уточнені в Технічному завданні.

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

В основу створення профілю покладено взаємодію ОКК та МР. Реєстрація ЮО

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

В МР здійснюється перевірка наявності сформованої раніше ЮО:

 по факту позитивного результату перевірки відбувається надсилання повідомлення до Єдиного модулю управління користувачами та ЗІС, що дана ЮО існує;

 по факту негативного результату перевірки відбувається створення сутності ЮО та заповнення даними з ЕЦП. Далі прикріплення ЮО до Користувача посадової особи та надсилання даних ЮО. В ОКК здійснюється створення профілю ЮО

після чого Користувачу відображаються профіль та дані ЮО.

1.1.1 Склад послуг

 Конвергентність у вигляді злиття на презентаційному рівні Веб-порталу та ОКК з логічним поділом сутностей, які можуть бути притаманні Веб-порталу та ОКК або тільки Веб-порталу чи ОКК;

 Реалізація модернізації веб-інтерфейсу ОКК;

 Реалізація модернізації бази даних МР;

 Реалізація можливості відображення сторінки для людей з вадами зору.

1.1.2 Вимоги до модернізації веб-інтерфейсу ОКК

В межах модернізації ОКК повинна бути забезпечена можливість посадовій особі ЮО виконання наступних операцій:

 створення профілю ЮО;

 замовлення електронної послуги «Заява на проведення заходу в Колонній залі та/або Лекторії КМР»;

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

1.1.3 Створення профілю юридичної особи ОКК

Профіль юридичної особи (далі – ЮО) може бути створений виключно користувачем, який має ЕЦП посадової особи.

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

З ЕЦП посадової особи повинні бути отримані наступні дані:

 назва юридичної особи;

 КОПФГ;

 код ЄДРПОУ юридичної особи;

 ПІБ посадової особи;

 посада посадової особи;

 код ДРФО посадової особи.

1.1.4 Перегляд профілю юридичної особи ОКК

Користувач-посадова особа при переході на профіль ЮО в ОКК повинен мати можливість переглядати наступні дані ЮО:

 назва юридичної особи;

 код КОПФГ;

 код ЄДРПОУ;

 дата державної реєстрації;

 місце реєстрації;

 види економічної діяльності;

 посадові особи.

Детальний перелік даних описаний у моделі даних Юридична особа.

1.1.5 Модернізація бази МР для обліку та управління сутністю ЮО

Модернізація повинна забезпечити облік та управління сутністю ЮО в МР.

В межах модернізації МР повинна бути створена сутність ЮО. Сутність ЮО передбачає наступну структуру:

 назва юридичної особи;

 код КОПФГ;

 код ЄДРПОУ;

 дата державної реєстрації;

 місце реєстрації;

 види економічної діяльності;

 посадові особи

Детальний перелік даних описаний у моделі даних сутності Юридична особа.

Сутність ЮО існує тільки в прив’язці до користувача, який є посадовою особою даної ЮО та має KyivID.

В межах модернізації МР повинні бути реалізовані наступні операції з сутністю ЮО:

 створення;

 перегляд;

 редагування;

 видалення.

1.1.6 Модель даних, структура, атрибути сутності Юридична особа Модель даних сутності Юридична особа

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

Структура сутності Юридична особа

Структура сутності Юридична особа представлена на Рисунку 14.

Квартира

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

Будинок

Посадові особи

Вулиця

Місце реєстрації ЮО

Дата початку посади

Дата закінчення посади

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

Дата державної реєстрації

Посада

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

Код ЄДРПОУ

Код ДРФО

Район

Код КОПФГ

По батькові

Область

Назва юридичної особи

Ім'я

Країна

Прізвище

Юридична особа

Місце реєстрації ЮО

Посадові особи

Рисунок 14. Структура сутності Юридична особа

Деталізацію інформації щодо атрибутивного складу сутності Юридична особа буде надано Замовником Виконавцю після підписання NDA.

4. ЕФУНКЦІОНАЛЬНІ ВИМОГИ ЩОДО РОЗВИТКУ СИСТЕМИ Загальні вимоги

Розвиток Системи повинен виконуватись з використанням безкоштовних програмних засобів з відкритими кодами, такими як PostgreSQL, MYSQL або аналогів та використовувати найсучасніші та перспективні формати інформаційного обміну даними між клієнтом і сервером на основі протоколу HTTP Over TLS за специфікаціями консорціуму "OGC". Взаємодія між сервером додатків та клієнтом для кінцевого користувача повинна виконуватися за протоколом http over tls (криптографічного протоколу).

Розвиток Системи повинен виконуватись з використанням принципів концепції Free and Open Source Software (FOSS), розширених парадигмою гуманітарної відповідальності (Humanitarian-FOSS) і включати такі вимоги:

 Націленість на рішення критично важливих завдань для підвищення швидкості:

o надання електронних послуг на презентаційному рівні ОКК;

o роботи презентаційного рівня ОКК.

 Висока орієнтація на якість, надійність і стабільність роботи Веб-порталу, ОКК, виключення втрати і дублювання даних.

 Мінімальні вимоги до кваліфікації користувачів і необхідності їх навчання.

 Прозорі інтеграційні можливості.

 Інформаційна та технічна безпека Веб-порталу, ОКК.

 Гнучка рольова модель із можливістю її модифікації.

 Забезпечення необхідного рівня конфіденційності персональних даних громадян згідно із Законодавством України.

 Забезпечення прозорості доступу до інформації.

 Забезпечення історії збереження записів.

 Забезпечення резервування програмних модулів, компонентів Веб-порталу, ОКК.

 Всі програмні модулі, компоненти, що впроваджуватимуться та поставлятимуться в межах цієї закупівлі, мають бути надані на умовах ліцензування GPL (xxxx://xxx.xxx.xxx/xxxxxxxx/xxx.xxxx) і забезпечувати відкритість, прозорість та доступність вихідних кодів продукту за ідеологією OpenSource (ліцензія на вільне програмне забезпечення).

 Якісна супроводжувальна робоча та експлуатаційна документація.

Вимоги до чисельності, кваліфікації та режиму роботи персоналу

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

 безперервне супроводження Веб-порталу, ОКК на всіх стадіях його експлуатації та підтримки;

 цілодобовий режим роботи Веб-порталу, ОКК та його модулів за призначенням в повному обсязі;

 централізований контроль працездатності Веб-порталу, ОКК;

 усунення відмов роботи Веб-порталу, ОКК та його компонентів;

 адміністрування (оперативне налагодження під час експлуатації) роботи Веб- порталу, ОКК;

 своєчасне централізоване застосування оновлень програмного забезпечення.

Вимоги до показників навантаження

Веб-портал, ОКК повинні забезпечувати:

 час обробки запитів із наданням релевантних відповідей – 1-3 секунди;

 середній час реагування компонентів Системи за умови 100 запитів в секунду – не більш ніж 0.5 сек;

 можливість зберігання історичних даних протягом усього часу використання Системи, ОКК;

 здатність забезпечити можливість нарощування кількості користувачів та об’ємів баз даних без потреби будь-яких додаткових доробок.

Швидкість роботи Веб-порталу, ОКК не повинні погіршуватися при:

 пікових навантаженнях із одночасною роботою 1000 користувачів (одночасних запитів в 1 секунду);

 порядковому зростанні кількості користувачів;

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

Вимоги до надійності

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

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

 забезпечення працездатності Системи, ОКК;

 збереження даних Системи, ОКК. Надійність повинна забезпечуватись за рахунок:

 використання сучасних технологій розвитку Системи, ОКК та забезпеченням якісного тестування;

 резервуванням компонентів та їх елементів;

 режиму автоматичного аналізу поточного стану (в реальному стані) та відновлення працездатності у відповідності до регламенту відновлювальних робіт;

 організації систематичного резервного копіювання та архівного збереження інформації в Системі, ОКК;

 апаратно-програмним захистом роботи від стороннього несанкціонованого програмно-апаратного втручання;

 архівним збереженням інформації;

 можливість оновлення будь-яких компонентів Системи, ОКК без зупинки сервісу;

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

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

 RTO (Recovery time objective, максимальний час відновлення працездатності всіх компонентів Системи за умови наявності серверної інфраструктури) – не більше ніж 2 год;

 забезпечення доступності Системи не менше, ніж 99.9% без урахування часу планових відключень та недоступності основних та резервних серверних потужностей та засобів зв'язку;

 оперативністю заміни програмно-технічних засобів, що вийшли з ладу;

 сумісності технічних засобів та програмного забезпечення.

Вимоги до інформаційної безпеки

На початковому рівні розвитку Системи, ОКК будуть реалізовуватися базові заходи із забезпечення захисту інформації (КСЗІ) та технологічної інформації про систему. Повинні бути реалізовані наступні заходи захисту початкового рівня:

 організаційно-адміністративні;

 апаратно-програмні;

 інженерно-технічні.

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

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

Вимоги до ергономіки

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

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

Всі інтерактивні елементи повинні бути виконані у зручному та зрозумілому представленні із набором відповідних текстових та/або графічних інформаційних підказок.

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

Веб-інтерфейс повинен відповідати таким вимогам щодо використання технологій при його створенні:

 Рішення повинно бути виконано з використанням елементів адаптивних технологій.

 Передбачається використання HTML4 / HTML5, Ajax, JavaScript.

 Для накладення стильової інформації використовується таблиці стилів CSS3.

 Можливе використання різних rich-media технологій як компоненту HTML сторінок.

 Використання таких технологій, як Flash, наприклад, у вигляді Flex або SilverLigh не передбачається.

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

 з операційними системами: Windows, Linux;

 з браузерами, у тому числі мобільними: Microsoft Edge, Mozilla Firefox, Google Chrome (наперед останніми версіями браузерів на дату початку надання послуг за етапом згідно календарного плану).

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

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

 Mozilla Firefox ;

 Microsoft Edge;

 Google Chromе.

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

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

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

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

Експлуатація Веб-порталу, ОКК повинно виконуватися за наступними принципами:

 технічний супровід виконується обслуговуючим персоналом Замовника або згідно з вимогами виробника програмного та технічного забезпечення, які надаються Виконавцем у вигляді інструкцій з експлуатації;

 технічне обслуговування та ремонт виконується персоналом Замовника відповідно до вимог виробників.

Технічний супровід програмного забезпечення Веб-порталу, ОКК повинен виконуватися системними адміністраторами, технічний супровід обладнання Веб-порталу, ОКК - технічними спеціалістами Замовника.

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

Вимоги до режимів функціонування

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

Експлуатація Веб-порталу, ОКК повинна передбачати такі режими:

 Основний режим – режим штатного функціонування всіх компонентів Веб-порталу, ОКК за своїм призначенням.

 Нештатний режим – режим нештатного функціонування всіх компонентів Веб- порталу, ОКК, наприклад, недоступність даних серверу.

 Режим адміністрування – режим здійснення централізованого автоматизованого налагоджування та автоматизованого оновлення компонентів Веб-порталу, ОКК одночасно з роботою решти користувачів в Веб-порталі, ОКК в основному режимі або в режимі Технічного обслуговування.

 Режим регламентного обслуговування – режим регламентного технічного обслуговування та відновлення працездатності технічних засобів компонентів Веб- порталу, ОКК.

Вимоги до збереження інформації при аваріях

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

До складу повідомлення щодо події аварійного типу повинні входити:

 час;

 текстова назва аварії;

 назва файлу вихідних текстів;

 номер рядка в файлі;

 причина помилки.

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

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

 відмова обладнання сервера;

 вимкнення живлення на робочому місці та/або на сервері баз даних;

 відмова обладнання робочої станції;

 відмова ліній зв’язку.

З метою забезпечення зберігання інформації повинно використовуватися:

 резервне копіювання;

 відновлення даних при збоях в роботі мережевого, програмного і апаратного забезпечення.

Якщо в процесі перевірки виявляються помилки, система повинна зробити спробу її виправлення. У випадку виявлення помилок система повинна занести інформацію про помилки до системних журналів відповідної БД.

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

Вимоги до патентної чистоти

Патентна чистота Веб-порталу, ОКК повинна бути забезпечена розробником і повинна гарантуватися фірмами - виробниками програмних засобів.

Вимоги до стандартизації і уніфікації

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

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

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

Вимоги до видів забезпечення

Інформаційне забезпечення Веб-порталу, ОКК повинно відповідати таким вимогам та можливостям:

 багаторазове використання даних у різних ділових процесах;

 забезпечення фізичної та логічної цілісності даних;

 мінімізація надмірності даних, що зберігаються;

 стандартизація представлення даних;

 достовірність та актуальність даних.

Побудова Веб-порталу, ОКК повинна забезпечувати:

 розмежування доступу до даних, запобігання несанкціонованого доступу до них;

 копіювання і зберігання масивів інформації;

 мінімізацію обсягу даних, що вводяться вручну;

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

 компонент класифікації і кодування;

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

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

 локальних в межах системи;

 відомчих;

 загальнодержавних.

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

 використання загальносистемних класифікаторів;

 централізоване ведення системних класифікаторів;

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

 забезпечення мінімальних витрат пам’яті у процесі накопичення та зберігання інформації;

 забезпечення максимальної швидкодії при вирішенні функціональних задач.

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

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

Шлюз інформаційного обміну повинен передбачати:

 можливість підключення та безпечність доступу локальних ресурсів Веб-порталу, ОКК до зовнішніх інформаційних систем та ресурсів;

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

Вимоги до математичного забезпечення

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

Вимоги до лінгвістичного забезпечення

Мовні засоби програмування будуть обираються Виконавцем відповідно до рішень з програмного забезпечення Веб-порталу, ОКК.

Вимоги до апаратно-програмного забезпечення

Програмне забезпечення (далі – ПЗ) Веб-порталу, ОКК повинно складатися із:

 загальносистемного програмного забезпечення (далі – ЗПЗ);

 прикладного програмного забезпечення (далі – ППЗ).

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

 підтримку загально прийнятих сучасних міжнародних стандартів до відкритих систем;

 сумісність та інтегрованість;

 підтримку функціонування в різнорідному апаратному і програмному середовищах;

 вмонтованість механізму захисту від помилок і підтримки цілісності.

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

 операційні системи;

 система управління базами даних;

 програмна платформа;

 система забезпечення версійності та інтеграції проекту;

 система моніторингу;

 система відслідковування помилок;

 сервери додатків.

Загальне програмне забезпечення не є предметом закупівлі або розробки.

Рішення зі складу загальносистемного програмного забезпечення повинно технічно та економічно обґрунтовано з точку зору цілісності та обґрунтованої повноти програмного застосування ІС “МР” та його компонентів за призначенням та мінімізації витрат на подальший супровід.

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

За результатами створення /розвитку та впровадження Веб-порталу, ОКК програмний код прикладного програмного забезпечення повинен бути переданий Виконавцем Замовнику в електронному вигляді.

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

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

Показники навантаження при яких Веб-портал, ОКК повинні зберігати час відклику компонентів системи не більше 3х секунд:

Кількість записів користувачів (не менше)	2 млн.
Пікова кількість одночасно працюючих користувачів	1 000
Середня кількість заявок на послугу по всій системі за день	6 000
Пікова кількість заявок на послугу по всій системі за день	16 000
Об’єм (кількість) сканкопій документів	200 000

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

 Сервер БД;

 Сервер APP;

 Сервер FileStorage;

 Сервер БД резервний;

 Сервер APP резервний;

 Сервер FileStorage резервний;

 Сервер БД та APP тестовий;

 Сервер моніторингу;

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

У разі збільшення кількості користувачів на 25% / навантаження пікової кількості одночасно працюючих користувачів на 25% / (кількості) сканкопій документів на 25%,

Розробник повинен надати рекомендації щодо прогнозних характеристик апаратного забезпечення.

Вимоги до технічного забезпечення

Вимоги до розвитку Веб-порталу, ОКК в цілому:

 Веб-портал, ОКК повинні мати архітектуру, побудовану на сучасних промислових технологіях зберігання, обробки, аналізу даних та доступу до них, забезпечувати одночасну роботу користувачів.

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

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

 Веб-портал, ОКК повинні мати засоби діагностики цілісності як БД в цілому, так і окремих таблиць/об’єктів, а також засоби шифрування.

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

 Інформаційна архітектура Веб-порталу, ОКК повинна відповідати сучасним вимогам щодо побудови інтерфейсів користувачів.

 ІС “МР” повинна мати механізми щодо кластерізації рішення. Рішення щодо побудови Веб-порталу, ОКК повинно базуватися на:

 застосуванні сучасних інформаційних технологій;

 реалізації концепції створення єдиного інформаційного простору в м. Києві;

 застосуванні правила централізованого накопичення, зберігання та обробки інформації;

 підтримці актуальності, повноти, несуперечності, цілісності та доступності інформації;

 забезпеченні надійності, резервування компонентів технічного забезпечення Веб- порталу, ОКК;

 забезпеченні централізованого управління, безперервного контролю функціонування та централізованого налаштування Веб-порталу, ОКК (модулів та компонентів);

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

Веб-портал, ОКК повинні мати наступні характеристики та функціональність:

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

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

 забезпечувати механізми для адміністрування користувачів та їх повноважень, а також забезпечувати захист персональних даних відповідно до чинного законодавства України;

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

 обов’язкове документування АPI у відповідності до міжнародних типів специфікацій та екосистем таких як Swagger, RAML, API Blueprint для використання внутрішніми/сторонніми сервісами. Перевага надається засобу, яке

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

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

 підтримка URL-адресації для будь-яких інформаційних об'єктів (користувач повинна мати можливість отримувати/відправляти прямі URL-посилання на об'єкти системи);

 використання форматів інформаційного обміну даними на основі таких протоколів та стандартів: HTTP over tls, WMS, WFS, XML, JSON, REST (Restfull).

Вимоги до метрологічного забезпечення

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

Вимоги до організаційного забезпечення

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

Вимоги до методичного забезпечення

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

5. СКЛАД ТА ЗМІСТ ПОСЛУГ Склад та зміст послуг з розвитку Веб-порталу

Склад та зміст робіт з розвитку Веб-порталу передбачає наступні етапи:

1й етап

Розробка технічного завдання

 Розробка Технічного завдання.

2й етап

Розробка та модернізація програмного забезпечення, розробка документації

 Розробка програмного забезпечення;

 Розробка документації;

o Опис системи в частині оновлення;

o Керівництво Системного адміністратора;

o Програма та методика попередніх випробувань;

o Протокол попередніх випробувань;

o Акт прийняття в дослідну експлуатацію.

3й етап

Дослідна експлуатація програмного забезпечення Веб-порталу, розробка документації

 Програма та методика дослідної експлуатації;

 Керівництво Користувача;

 Навчання;

 Керівництво Адміністратора;

 Протокол дослідної експлуатації.

Вимоги до документації та методичного забезпечення

Склад документації на розвиток Веб-порталу включає наступне:

 Технічне завдання;

 Програма та методика попередніх випробувань;

 Програма та методика дослідної експлуатації;

 Опис Cистеми в частині оновлення: документ повинен включати в себе: опис Бази даних;

 Керівництво Системного адміністратора. Документ повинен включати в себе:

o інструкцію з розгортання та налаштування;

o перелік інформаційних ресурсів Веб-порталу, ОКК із рекомендаціями щодо резервного копіювання;

o рекомендації щодо моніторингу працездатності Веб-порталу, ОКК за певним набором ключових показників інформаційного характеру.

 Керівництво Користувача;

 Керівництво Адміністратора (документ повинен включати в себе інструкцію з формування та ведення бази даних);

 Протокол з навчання;

 Протокол випробувань;

 Протокол дослідної експлуатації.

Вимоги щодо методичного забезпечення можуть бути уточнені в Технічному завданні.

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