що діє на підставі , з другої сторони, надалі Замовник і Виконавець також іменуються Сторона, а спільно Сторони, враховуючи результат проведення закупівлі: Розвиток платформи надання електронних послуг, в тому числі адміністративних, 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 робочих днів з дати отримання письмової заявки від Замовника | Дослідний зразок програмного забезпечення Системи, 3 черга, на майданчику Замовника. Опис Системи ПМ РСНП. Опис Системи ПМ СЗВ. Керівництво системного адміністратора ПМ РСНП. Керівництво системного адміністратора ПМ СЗВ. Програма та методика попередніх випробувань ПМ РСНП. Програма та методика попередніх випробувань ПМ СЗВ. Протокол попередніх випробувань ПМ РСНП. Протокол попередніх випробувань ПМ СЗВ. Акт приймання в дослідну експлуатацію ПМ РСНП. Акт приймання в дослідну експлуатацію ПМ СЗВ. |
3 | Дослідна експлуатація програмного забезпечення Системи, розробка документації | 15 робочих днів з дати отримання письмової заявки від Замовника | Програма та методика дослідної експлуатації ПМ РСНП. Програма та методика дослідної експлуатації ПМ СЗВ. Протокол дослідної експлуатації ПМ РСНП. Протокол дослідної експлуатації ПМ СЗВ. Керівництво користувача ПМ РСНП. Керівництво користувача ПМ СЗВ. Керівництво адміністратора ПМ РСНП. Керівництво адміністратора ПМ СЗВ. | |||
Загальна вартість пропозиції: разом без ПДВ**, грн.: (зазначається учасником цифрами та прописом); розмір ПДВ**, грн.: (зазначається учасником цифрами та прописом); всього з ПДВ**, грн.: (зазначається учасником цифрами та прописом) |
* Учасник конкурсних торгів може надавати власний варіант календарного плану в частині зменшення строків/термінів надання послуг за кожним етапом.
** Строк розробки та порядок надання ТЗ може бути змінено.
*** Якщо Учасник є платником ПДВ. У разі, якщо Учасник не є платником податку на додану вартість (предмет закупівлі не є об’єктом оподаткування, звільнений від оподаткування, до предмета закупівлі застосовується нульова ставка ПДВ вказана колонка не заповнюється).
**** За рішенням Виконавця реалізація етапів може проводитися як послідовно один за одним, так і одночасно.
ЗАМОВНИК | ВИКОНАВЕЦЬ |
Додаток 2 до Договору № від
ТЕХНІЧНІ ВИМОГИ (СПЕЦИФІКАЦІЯ)
ІНФОРМАЦІЯ ПРО НЕОБХІДНІ ТЕХНІЧНІ, ЯКІСНІ, КІЛЬКІСНІ ТА ІНШІ ХАРАКТЕРИСТИКИ ПРЕДМЕТА ЗАКУПІВЛІ
Розвиток платформи надання електронних послуг, в тому числі адміністративних, 3 черга,
за кодом ДК 021:2015 (CPV) «Єдиний закупівельний словник» – 72210000-0 Послуги з розробки пакетів програмного забезпечення
Розвиток платформи надання електронних послуг, в тому числі адміністративних, 3 черга, в межах створення програмної платформи для надання електронних послуг, у тому числі адміністративних, яке виконується згідно пункту 1.2 Напрямів діяльності та заходів Комплексної міської цільової програми «Електронна столиця» на 2015-2018 роки (зі змінами і доповненнями), затвердженої Рішенням Київської міської ради № 654/1518 від 02 липня 2015 року та пункту 2 Переліку заходів з подальшого впровадження інформаційно- комунікаційних технологій у сфері життєдіяльності міста Києва на 2018 рік, затвердженому Розпорядженням виконавчого органу Київської міської ради (Київської міської державної адміністрації) № 614 від 11 квітня 2018 року.
На підтвердження відповідності пропозиції технічним, якісним та кількісним характеристикам предмета закупівлі у складі своєї пропозиції Учасник повинен надати інформацію про можливість надання послуг Замовнику з урахуванням наведених нижче вимог.
ЗАГАЛЬНІ ВІДОМОСТІ
Загальні положення
В цьому документі наведені технічні та якісні характеристики, перелік та терміни надання послуг з розвитку платформи надання електронних послуг, в тому числі адміністративних (ІАС «Е-Послуга»), 3 черга (далі – Платформа електронних послуг або Система).
Обсяги відповідних послуг з розвитку Платформи електронних послуг визначаються цими Технічними вимогами та уточняються в Технічному завданні.
Мета розвитку Системи
Мета розвитку Платформи електронних послуг є забезпечення:
- відкритості органів місцевого самоврядування, спрощення доступу до послуг, що надаються структурними підрозділами виконавчого органу Київської міської ради (Київської міської державної адміністрації), районними в місті Києві державними адміністраціями, підприємствами, установами та організаціями, що належать до комунальної власності територіальної громади міста Києва;
- підвищення якості надання послуг шляхом автоматизації процесів та впровадження сучасних інформаційних технології;
- організація цілеспрямованої діяльності для формування ефективної системи надання електронних послуг місцевій громаді міста Києва.
Призначення Системи
Платформа електронних послуг призначена для забезпечення надання електронних послуг, у тому числі адміністративних фізичним та юридичним особам.
Платформа електронних послуг – це сукупність програмних компонентів, які призначені для вирішення задач автоматизації процесів надання електронних послуг шляхом впровадження сучасних інформаційних технологій в діяльність структурних підрозділів виконавчого органу Київської міської ради (Київської міської державної адміністрації), районних в місті Києві державних адміністрацій, підприємств, установ та організацій, що належать до комунальної власності територіальної громади міста Києва.
Цілі розвитку Системи
Ціль розвитку Системи – розробити та впровадити нові електронні сервіси шляхом автоматизації певних бізнес-процесів на базі сучасних інформаційних технологій, а саме:
- Програмний модуль «Реєстру суб’єктів, що надають послуги» (далі – РСНП). Це дозволить надавати фізичним та юридичним особам міста Києва цільовий набір даних стосовно того, де і які послуги можна отримати у місті;
- Програмний модуль «Системи замовлення відео-контенту» (далі – СЗВ). Це надасть можливість віддаленого / дистанційного обслуговування фізичних осіб через ОКК для замовлення електронної послуги «Замовлення відео контенту з міських камер» для вирішення особистих інформаційних потреб в рамках чинного законодавства.
Склад послуг з розвитку Системи
В межах виконання робіт з розвитку Системи повинні бути здійснені наступні заходи:
- Розробка РСНП.
- Розробка СЗВ.
Перелік не остаточний та може бути уточнений в Технічному завданні.
Терміни та визначення
Терміни | Визначення |
Access token | Ключ, що формується в результаті авторизації. Містить інформацію з безпеки сеансу та ідентифікує користувача, зовнішню систему та призначені для них привілеї |
API | Application Programming Interface, див. xxxxx://xx.xxxxxxxxx.xxx/xxxx/ Прикладний_програмний_інтерфейс. |
Back-end | Бекенд (англ. back-end) – програмно-апаратна частина сервісу. Back-end – розробники будують та підтримують технології, що керують всіма компонентами архітектури програмного забезпечення. |
BankID | Спосіб електронної ідентифікації користувачів через українські банки для надання адміністративних та інших послуг через Інтернет. |
Data | Тип даних. Служить для представлення формату дати. |
Database, База даних, БД | Сукупність даних, організованих відповідно до концепції, яка описує характеристику цих даних і взаємозв'язки між їх елементами. |
ID карта | Нова форма паспорта громадянина України з безконтактним електронним носієм. У паспорт у формі картки вноситься наступна |
Терміни | Визначення | |
інформація: назва держави, назва документа, ім'я (з латинською транслітерацією, яку можна узгодити відповідно до інших документів, наприклад, посвідчення водія), стать, дата народження, унікальний номер запису в Єдиному державному демографічному реєстрі, номер самого документа, дата його видачі і закінчення терміну його дії, код уповноваженого суб'єкта, який видав паспорт, місце народження, оцифроване зображення обличчя та підпис власника картки. | ||
INT | Числовий тип даних (цілі числа) (англ. Integer). Служить для представлення цілих чисел. Набір чисел цього типу являє собою кінцеву підмножину нескінченної кількості цілих чисел, обмежених максимальним і мінімальним значеннями. | |
ISIC, NACE | Міжнародна стандартна галузева класифікація всіх видів економічної діяльності. | |
JSON | Текстовий формат обміну даними, заснований на JavaScript. | |
KyivID | Унікальний ідентифікатор, який присвоюється користувачу, що є одержувачем (зокрема потенційним одержувачем) послуг, заходів соціальної підтримки та служить персональним електронним ключем. | |
Scope | Набір повноважень та перелік даних, які отримує користувач або ЗІС при роботі з модулями платформи. | |
UI | Інтерфейс користувача (англ. User Interface). | |
VARCHAR(n) | Строковий тип змінної довжини. Аргумент (n) визначає довжину рядка та може приймати значення від 1 до 8000. | |
Автентифікація | Електронна процедура, яка дає можливість підтвердити електронну ідентифікацію фізичної особи та/або її походження і цілісність електронних даних. | |
Авторизація | Процедура надання особі/процесу прав на виконання певних дій або доступу до ресурсів, а також процес перевірки (підтвердження) прав при спробі виконання цих дій. | |
Адміністратор | Користувач, якому надано право визначати та призначати рівні доступу. | |
Будинок | Житловий об’єкт нерухомості, що є невід’ємною частиною адреси. | |
Валідація | Процес підтвердження відповідності, затвердження, легалізації. | |
Веб-портал електронних послуг | Веб-портал електронних послуг, в тому числі адміністративних. Веб-портал – це єдина система, де жителям / гостям / представникам бізнесу міста Києва будуть доступні всі міські електронні сервіси, в тому числі адміністративні. | |
Відео-контент | Записане та надане КП ГІОЦ відео зображення з відеокамер, які обслуговує КП Інформатика. | |
Вулиця | Лінійно-протяжний планувальний елемент, що забезпечує рух транспорту і пішоходів та є невід’ємною частиною адреси. | |
ДРФО | Державний реєстр фізичних осіб – платників податків. | |
ЄДР | Єдиний державний реєстр підприємств та організацій України. |
Терміни | Визначення |
ЄДРПОУ | Унікальний ідентифікаційний номер юридичної особи в Єдиному державному реєстрі підприємств та організацій України. |
ЕЦП, Електронний цифровий підпис | Вид електронного підпису, отриманого за результатом криптографічного перетворення набору електронних даних, який додається до цього набору або логічно з ним поєднується і дає змогу підтвердити його цілісність та ідентифікувати підписанта. Електронний цифровий підпис накладається за допомогою особистого ключа та перевіряється за допомогою відкритого ключа. |
Електронна послуга | Електронна послуга – це послуга, яка реалізує технологію віддаленого / дистанційного обслуговування населення, бізнесу міста Києва через ОКК. |
Житель, фізична особа | Громадянин, який зареєстрований, мешкає, працює у м. Києві, гості м. Києва. |
ЗПЗ | Загальносистемне програмне забезпечення. |
ІАС «Е-Послуга» | Інформаційно-аналітична Автоматизована Система «Е-Послуга», що призначена для надання електронних адміністративних послуг фізичним та юридичним особам. |
ІАС “Майно” | Інформаційно-аналітична система, яка призначена для інтегрування існуючих міських інформаційних систем в єдиний інформаційний простір шляхом запровадження єдиної архітектури програмно-технічної платформи з геоінформаційною (ГІС) складовою. |
Ідентифікація | Процедура присвоєння ідентифікатора об’єкту або встановлення відповідності між об’єктом і його ідентифікатором; впізнання об’єкта системою. |
Ім’я | Особиста назва людини, що дається їй після народження. Ім’я – це частина повного імені жителя. |
ІПН | Індивідуальний номер платника податків. |
Квартира | Квартира – ізольоване помешкання в жилому будинку, призначене для проживання фізичних осіб. Номер квартири – це складова частина адреси. |
КВЕД | Класифікатор видів економічної діяльності. |
КМДА | Київська міська державна адміністрація. |
Камера, відеокамера | Пристрій для отримання оптичних образів об'єктів та пристосований для запису або передавання зображення у русі. |
Код послуги | Номер згідно Державного класифікатору продукції та послуг ДК 016:2010. |
Код ДРФО | За даним кодом здійснюється облік фізичних осіб платників податків. |
Код ЄДРПОУ | Унікальний ідентифікаційний номер юридичної особи в Єдиному державному реєстрі підприємств та організацій України. |
Код КВЕД | За даним кодом визначаються основні та неосновні напрямки діяльності юридичної особи. |
Код КОПФГ | За даним кодом визначають форми господарювання юридичних осіб. |
Терміни | Визначення |
Користувач ОКК | Житель або юридична особа, які зареєстровані та мають обліковий запис в ОКК. |
КОПФГ | Класифікатор організаційно-правових форм господарювання. |
Країна | Країна – це політичне, національне, соціальне, культурне, господарське співтовариство, організоване державою на певній території; визначена територія, що становить єдність з погляду історії, природних умов, населення (спільноти людей, що проживають на цій території), що в політико-географічному відношенні мусить мати державний суверенітет. Назва Країни – це складова частина адреси. |
КСВС | Комплексна система відеоспостереження міста Києва, яка забезпечує відеоспостереження у місті Києві в інтересах безпеки громадян, охорони порядку та збереження майна, керування транспортним рухом, контролю за прибиранням сміття, ремонтом доріг, прибиранням території і безпосередньо в інтересах жителів міста (Адміністратором Системи є Комунальне підприємство «Інформатика»). |
Компонент | Під компонентом розуміється АРМ або сервіс Системи. |
КП | Комунальне підприємство. |
Модель даних | Інструмент представлення концептуальної моделі предметної області і динаміки її розвитку у вигляді бази даних. |
Модератор | Людина, яка відповідає за дотримання встановлених норм та правил. В рамках даного документу Модератор це людина, яка несе відповідальність за погодження дат календарю та Регламенту проведення заходів Колонної зали та Лекторії. |
МР, Муніципальний реєстр | Це автоматизована система управління реєстром Громадян міста Києва за допомогою Сервісу профілю. Сервіс профілю – це веб-сервіс, який представляє собою набір програмних інтерфейсів та забезпечує управління записами профілів Користувачів ОКК в Муніципальному Реєстрі. |
Назва юридичної особи | Назва, під якою підприємство займається економічною діяльністю. Згідно із законом про найменуваннях підприємств, якщо підприємство функціонує не під ім'ям його власника, на будівлі, в якому воно розміщується, повинні бути вказані його назва, рід діяльності та ім'я власника. Всі підприємства повинні мати таблички із зазначенням назви фірми та імені його власників. Назва підприємства фіксується Реєстратором компаній. |
Населений пункт | Населений пункт (село, селище, поселення, місто) – це первинний рівень за адміністративно-територіальним устроєм Україна та виділені у самостійні адміністративно-територіальні одиниці. Це частина комплексно заселеної території України, яка склалася внаслідок господарської та іншої суспільної діяльності, має сталий склад населення, власну назву та зареєстрована в порядку, передбаченому законом. Населений пункт – це складова частина адреси. |
Область | Основна складова частина території України, яка історично склалася і характеризується певним організаційним відособленням, цілісністю, економічною та соціальною самодостатністю, місцевими |
Терміни | Визначення |
особливостями і традиціями. Область – це третій рівень за адміністративно-територіальним устроєм України. Область – це складова частина адреси. | |
ОКК | Особистий Кабінет Киянина. |
Оператор | Співробітник КМДА, який в рамках посадових повноважень використовує Систему. |
Операції | Етапи та проміжні статуси отримання е-послуги. |
Отримувачі послуги | Жителі міста, які мають право на отримання послуги згідно чинного законодавства. |
ПІБ | Прізвище, Ім’я, По батькові. |
ПМ | Програмний модуль. |
По батькові | Вид антропоніма (патронім), утворений від офіційного імені батька за допомогою суфіксів -ич(-іч), -ович (для чоловіків) та -івна (для жінок). Ім’я по батькові – це частина повного імені жителя. |
Посада | Службове становище, пов’язане з виконанням певних обов'язків в установі, на підприємстві тощо. |
Посадова особа | Службовець, наділений владними повноваженнями з метою здійснення організаційно-розпорядчих функцій і забезпечення узгодженості в діяльності інших учасників службових відносин. |
ППЗ | Прикладне програмне забезпечення. |
Прізвище | Найменування особи, набуте при народженні або вступі у шлюб, що передається від покоління до покоління і вказує на спорідненість. Прізвище – це частина повного імені жителя. |
Профіль | Набір даних про ЮО. |
Район | Частина території області, невеликий регіон з агропромисловим характером економіки, транспортною, інформаційною та іншою соціальною інфраструктурою, спрямованою на забезпечення зв’язку між сільськими та міськими населеними пунктами, які входять до його складу як самостійні адміністративно-територіальні одиниці. Район – це вторинний рівень за адміністративно-територіальним устроєм України. Район – це складова частина адреси. |
Реєстратор суб’єкта | Користувач з наділеними правами на створення, редагування та видалення карточки послуги та/або карточки суб’єкта. |
Реєстрація | Спосіб Користувача повідомити сайту (системі) дані про себе і в обмін отримати доступ до додаткових можливостей (наприклад, додати що не будь в обране) або ресурсів (наприклад, файлів) на сайті, які недоступні незареєстрованим користувачам (Гостям). Реєстрація нероздільна з авторизацією. Фактично, реєстрація – це спосіб отримати можливість увійти на сайт (в систему) з певною метою та вигодою. |
Складні життєві обставини | Обставини, спричинені інвалідністю, віком, станом здоров’я, соціальним становищем, життєвими звичками і способом життя, внаслідок яких особа частково або повністю не має (не набула або втратила) здатності чи можливості самостійно піклуватися про особисте |
Терміни | Визначення |
(сімейне) життя та брати участь у суспільному житті. | |
Соціальні послуги | Комплекс заходів з надання допомоги особам, окремим соціальним групам, які перебувають у складних життєвих обставинах і не можуть самостійно їх подолати, з метою розв’язання їхніх життєвих проблем. |
Стаж | Сумарна тривалість роботи робітником в певній сфері діяльності. |
Суб’єкти, що надають послуги | Підприємства, установи, організації та заклади незалежно від форми власності та господарювання, фізичні особи – підприємці, а також фізичні особи, які відповідають критеріям надання послуг. |
ТОВ | Товариство з обмеженою відповідальністю. |
ФОП | Фізична особа-підприємець. |
ФО, Фізична особа | Використовується для позначення людини (громадянина, особи без громадянства) як учасника правових відносин. Фізична особа підпорядковується певним нормам та правилам поведінки. |
ЮО, Юридична особа | Організація, суб'єкт права, здатний від свого імені набувати майнових і особистих немайнових прав і нести обов'язки та самостійно брати участь у правовідносинах, бути позивачем та відповідачем у суді. |
ВИМОГИ ЧИННОГО ЗАКОНОДАВСТВА
Розвиток Системи повинен відповідати вимогам чинних нормативно-правових документів, а саме:
Конституції України;
Закону України «Про внесення змін до деяких законодавчих актів України щодо розширення повноважень органів місцевого самоврядування та оптимізації надання адміністративних послуг»;
Закону України «Про Єдиний державний демографічний реєстр та документи, що підтверджують громадянство України, посвідчують особу чи її спеціальний статус»;
Закону України «Про адміністративні послуги»;
Закону України «Про інформацію»;
Закону України «Про електронні документи та електронний документообіг»;
Закону України «Про доступ до публічної інформації»;
Закону України «Про захист інформації в інформаційно-телекомунікаційних системах»;
Закону України «Про електронний цифровий підпис»;
Закону України «Про захист персональних даних»;
Закону України «Про свободу пересування та вільний вибір місця проживання в Україні»;
Закону України «Про внесення змін до деяких законодавчих актів України щодо документів, що підтверджують громадянство України, посвідчують особу чи її спеціальний статус, спрямованих на лібералізацію Європейським Союзом візового режиму для України»;
Постанови Кабінету Міністрів України від 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 «Про затвердження Порядку використання комп'ютерних програм в органах виконавчої влади»;
НД ТЗІ 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:2018 “Інженерія систем і програмного забезпечення. Процеси життєвого циклу програмного забезпечення”;
ДСТУ 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. Методичні вказівки. Інформаційна технологія. Комплекс стандартів і керівних документів на автоматизовані системи. Загальні положення.
Даний перелік не є вичерпним. Вимоги Законодавства України, нормативних та керівних документів, що стосуються мети, призначення та цілей розвитку Системи, повинні бути уточнені при розробці Технічного завдання.
ФУНКЦІОНАЛЬНІ ВИМОГИ ЩОДО РОЗВИТКУ СИСТЕМИ
Загальні вимоги
Зв'язок 1-ї, 2-ї, 3-ї черги розвитку Системи див. на рисунку 1.
Рисунок 2. Зв'язок 1-ї, 2-ї та 3-ї черги розвитку Системи
На Рисунку (Див. Рисунок 3 - Зв'язок 1-ї, 2-ї, 3-ї черги розвитку Системи) показано ключові сутності – Платформи електронних послуг, де:
Веб-портал електронних послуг – це Веб-портал надання електронних послуг, у тому числі адміністративних.
ОКК – Особистий кабінет киянина.
ПМ СП – Програмний модуль «Соціальні послуги».
ПМ РСНП – Програмний модуль «Реєстр суб’єктів, що надають послуги».
ПМ СЗВ – Програмний модуль «Система замовлення відео контенту».
Розвиток Системи повинен базуватись на використанні підходів та методів модернізації з використанням сучасних веб-портальних та сервісно-орієнтованих технологій.
При доопрацюванні будь-яких базових компонентів або створенні нових повинні бути застосовані сучасні методи та технології, що забезпечуватимуть якісну реалізацію функціональності компонентів Системи.
Технологічна гнучкість, надійність роботи, скорочення часу та сукупних витрат на розробку та підтримку Системи повинні досягатись за рахунок реалізації принципів стандартизації та уніфікації, а саме:
уніфікованих правил структурної побудови та/або модернізації та організації прикладних програмних компонентів, їх взаємодії між собою;
стандартизації вимог до побудови та/або модернізації бази даних, формування єдиних вимог до класифікації об’єктів та їх атрибутивного складу;
уніфікації правил побудови та/або модернізації інформаційної взаємодії з іншими інформаційними системами.
Передбачається, що Система взаємодіятиме (інтегруватиметься) у вигляді обміну певними наборами даних з такими рішеннями:
веб-порталом електронних послуг, ОКК;
Комплексною системою відеоспостереження міста*;
ІАС «Майно».
* Примітка!
Взаємодія з вищеназваною системою передбачається за умов технічної готовності, про що Замовник в робочому порядку надає відповідну інформацію Виконавцю.
Вимоги до РСНП
Вимоги до функціональних можливостей
Створення РСНП забезпечить автоматизацію процесу обліку інформації про послуги та суб’єктів, що їх надають.
Схему функціонального рішення наведено на Рисунок 2.
https
АРМ
Користувача
РСНП
Послуги:
Пошук
Перегляд
Друк
Суб єкти:
Пошук
Перегляд
Друк
Спеціалісти Департаментів КМДА
ІАС Майно
Дані про Суб’єктів, що надають послуги
Дані про користувачів
Бек-енд Системи
Сервіс обліку та управління суб’єктами та послугами
Сервіс адміністрування
Сервіс обміну даними з ІАС «Майно»
Дані про Суб’єктів, що
надають послуги
АРМ
Адміністратора РСНП
Облік та управління користувачами
Облік та управління
довідниками
АРМ Реєстратора Суб єкта
Суб єкти та Послуги:
Створення
Перегляд
Редагування
Пошук
Видалення
https https
Адміністратор
КМДА
Реєстратори Суб’єкта Департаментів КМДА
Рисунок 2. Схема функціонального рішення РСНП
Опис РСНП надано у Табл. 1.
Таблиця 1. Опис РСНП
Назва АРМу / Сервісу | Опис |
Інтерфейс користувача | |
АРМ Користувача РСНП | Загальна функціональність: |
Назва АРМу / Сервісу | Опис |
Авторизація та автентифікація Робота з файлами Основний інтерфейс користувача: Пошук послуги або суб’єкта Перегляд картки послуги Друк картки послуги Перегляд картки суб’єкта Друк картки суб’єкта | |
АРМ Реєстратора | Загальна функціональність: Авторизація та автентифікація Робота с файлами Основний інтерфейс адміністратора: Пошук послуги або суб’єкта Перегляд картки послуги Створення картки послуги Редагування картки послуги Логічне видалення картки послуги Перегляд картки суб’єкта Створення картки суб’єкта Редагування картки суб’єкта Логічне видалення картки суб’єкта |
АРМ Адміністратора РСНП | Загальна функціональність: авторизація та автентифікація; налаштування рольової моделі; робота с файлами. Облік та управління користувачами: пошук; створення; перегляд; редагування; логічне видалення. Облік та управління довідниками. Повинно бути передбачено використання наступних довідників: Види послуг; Типи послуги; |
Назва АРМу / Сервісу | Опис |
Код послуги; Вид суб’єкта; Організаційно правова форма; Форма власності; КВЕД; Тип адреси; Тип контактної особи; Посада; Освіта; Тип документу; Організації. | |
Бек-енд Системи | |
Сервіс управління суб’єктами та послугами | Функціональність сервісу: Пошук даних картки послуги в БД Читання даних картки послуги з БД Запис даних картки послуги до БД Формування для друку картки послуги Пошук даних картки суб’єкта в БД Читання даних картки суб’єкта з БД Запис даних картки суб’єкта до БД Формування для друку картки суб’єкта Вимоги до взаємодії з іншими компонентами: АРМ Користувача РСНП. В рамках виконання операцій над послугами та суб’єктами. АРМ Реєстратора суб’єкта. В рамках виконання операцій над послугами та суб’єктами. Сервісом адміністрування для отримання даних про довідники в рамках виконання операцій над послугами та суб’єктами. Сервісом обміну даними з ІАС «Майно» в рамках формування та передачі даних про послуги та суб’єктів. |
Сервіс адміністрування | Функціональність сервісу при роботі з користувачами: Пошук даних користувачів в БД Читання даних користувачів з БД Запис даних користувача до БД Функціональність сервісу при роботі з довідниками: Читання даних довідників з БД |
Назва АРМу / Сервісу | Опис |
Запис даних довідників до БД Вимоги до взаємодії з іншими компонентами: АРМ Користувача РСНП. Сервіс забезпечує авторизацію користувачів в рамках доступу. АРМ Реєстратора суб’єкта. Сервіс забезпечує авторизацію користувачів в рамках доступу. АРМ Адміністратора РСНП. Сервіс забезпечує авторизацію користувачів в рамках доступу. | |
Сервіс обміну даними з ІАС «Майно» | Сервіс забезпечує можливість он-лайн передачі системою наступних даних до ІАС Майно: Послуги Суб’єкти, що надають дані послуги Вимоги до взаємодії з іншими компонентами: Сервіс управління послугами та суб’єктами. Сервіс формує для Сервісу обміну даними з ІАС «Майно» зміни даних про послуги або суб’єктів. |
Склад послуг
Для створення РСНМ необхідно реалізувати:
рольову модель РСНП (АРМ Користувача РСНП, АРМ Реєстратора суб’єкта, АРМ Адміністратора РСНП);
сервіс управління суб’єктами та послугами;
сервіс адміністрування;
сервіс обміну даними з ІАС «Майно».
Модель даних сутності Послуга
Модель даних сутності Послуга – це група параметрів, що безпосередньо стосується сутності Послуга, і утворює логічну структуру.
Структура сутності Послуга
Структуру сутності Послуга наведено на рисунку 3.
Параметри послуги | Послуга | Зміст послуги | ||||
Види послуг | Параметри послуги | Отримувачі послуги | ||||
Типи послуг | Зміст послуги | Умови надання послуги | ||||
Код послуги | Суб’єкти які надають послугу | Порядок надання послуги | ||||
Назва послуги | Оплата послуги | |||||
Короткий опис послуги | Суб’єкти,що надають послугу | Вартість послуги | ||||
Повний опис послуги | Суб'єкт 1 | Державний стандарт послуги | ||||
URL послуги | Суб'єкт n | |||||
Рисунок 3. Структура сутності Послуга
Деталізацію інформації щодо атрибутивного складу сутності Послуга буде надано Замовником Виконавцю після підписання NDA.
Модель даних сутності Суб’єкт
Модель даних сутності Суб’єкт – це група параметрів, що безпосередньо стосується сутності Суб’єкт і утворюють логічну структуру.
Структура сутності Суб’єкт
Структуру сутності Суб’єкт наведено на рисунку 4.
Реєстраційні дані суб'єкта
Стаж
Послуги
Посилання на скан-копію
Освіта
Послуги
Тип документу
Вік
Послуги
Документи
Чисельність
Статус суб'єкта
Код ДРФО
Посада
Матеріально технічна база
По батькові
Кваліфікація персоналу
Кваліфікація персоналу
Ім'я
Веб-сайт суб'єкта
Документи
Прізвище
Квартира
Конктактна особа
Тип контактної особи
Літера будинку
Контактна особа
Адреса
Будинок
Форма власності
Вулиця
Види економічної
діяльності
Місце державної реєстрації
Адміністративний район
Дата державної реєстрації
Населений пункт
Вид суб'єкта
Код ЄДРПОУ
Район
Суб'єкт
Область
Статус КВЕД
Організаційно правова форма
Країна
Назва КВЕД
Скорочена назва
Тип адреси
Повна назва
КВЕД
Адреса
Види економічної діяльності
Реєстраційні дані суб'єкта
Посада
Рисунок 4. Структура сутності Суб’єкт
Деталізацію інформації щодо атрибутивного складу сутності Суб’єкт буде надано Замовником Виконавцю після підписання NDA.
Рольова модель
Облік користувачів та управління користувачами виконується на основні рольової моделі РСНП. Перелік ролей РСНП та права користувачів приведено у табл. 2.
Таблиця 2. Рольова модель Реєстру
Назва ролі | Права |
Користувач РСНП | 1. Пошук, перегляд, друк картки послуги* 2. Пошук перегляд, друк картки суб’єкта* *з можливим врахуванням виду послуг організації, де працює Користувач. |
Реєстратор суб’єкта | 1. Створення, редагування та логічне видалення картки послуги. 2. Створення, редагування та логічне видалення картки суб’єкта. |
Адміністратор РСНП | 1. Читання, створення, редагування, видалення користувачів та налаштування їх прав та ролей. 2. Створення, редагування, видалення довідників системи. |
Назва ролі | Права |
3. Створення, редагування та логічне видалення картки послуги. 4. Створення, редагування та логічне видалення картки суб’єкта. |
Вимоги до сервісу обміну даними з ІАС «Майно»
Сервіс повинен забезпечувати передачу даних про послуги та суб’єкти, що їх надають до ГІС-системи ІАС «Майно» з метою подальшого їх відображення на карті міста у вигляді окремого шару.
Передача даних до ІАС «Майно» повинна здійснюватися по факту їх оновлення в
РСНП.
З метою забезпечення виконання поставлених завдань, сервіс повинен задовольняти
наступним вимогам:
1. Надання оновлених даних від системи по послугам та суб’єктам, що їх надають. Сервіс обміну даними надає до ІАС «Майно» наступні дані:
- вид послуги;
- назва послуги;
- умови надання;
- назва суб’єкта;
- кваліфікація персоналу;
- адреса місця надання послуги.
2. Формування та передача до Сервісу обміну даними з ІАС «Майно» пакету змінених даних, якщо дані про послуги або суб’єктів були змінені, на стороні Сервісу управління суб’єктами та послугами.
На стороні ІАС «Майно», по факту отриманого пакету змінених даних, повинен здійснюватися запис отриманих даних до БД та відображення даних на карті міста.
Вимоги до РСНП повинні бути уточнені в Технічному завданні.
Вимоги до СЗВ
Вимоги до функціональних можливостей
Створення СЗВ надасть можливість отримання від Комплексної системи відеоспостереження міста (КП Інформатика) відео-контенту фізичною особою в м. Києві, якщо така особа замовила відповідну електронну послугу на Веб-порталі електронних послуг, ОКК.
Схему функціонального рішення СЗВ наведено на рисунку 5.
АРМ Оператора
Https
Оператор
КП Інформатика
Https
Https
Користувач ОКК
Обмін даними,
щодо відеоконтенту
Https
Відображення камер на шарі мапи
Дані про користувачів
Дані довідників
Користувачі
Платформа
Оператори
Довідники
Адміністратор Платформи
Https
АРМ Адміністратора СЗВ
ОКК
Камери
Замовлення
Блок-схема побудови рішення із замовлення відеоконтенту
Сервіс обліку та управління камерами
Сервіс обліку та управління заявками
Сервіс адміністрування
Сервіс обміну даними з ІАС «Майно»
Сервіс обміну даними з Платформою
Сервіс обміну даними з КП Інформатика
Сервіс обміну даними з ОКК
Бек-енд рішення
ІАС Майно
КП
Інформатика
Рисунок 5. Схема функціонального рішення СЗВ
Опис СЗВ надано у табл. 3.
Таблиця 3. Опис СЗВ
Назва АРМу / Сервісу | Можливості |
Інтерфейс користувача | |
АРМ Оператора | Загальна функціональність: Авторизація та автентифікація Основний інтерфейс користувача по роботі з даними камери: Пошук камери Перегляд картки камери Редагування картки камери Основний інтерфейс користувача по роботі із замовленнями: Пошук замовлення Перегляд картки замовлення Створення картки замовлення Зміна статусу замовлення. Можливі статуси: o «відмова» - Оператор присвоює замовленню статус «Відмова» у випадках, коли замовлення не може бути виконано в рамках регламенту надання даної послуги. Оператор змінює статус замовлення на «Відмова» та вказує причину відмови в наданні |
Назва АРМу / Сервісу | Можливості |
послуги. Після цього в СЗВ статус замовлення змінюється на «Відмова» та відбувається інформування Користувача в ОКК про відмову в наданні послуги з зазначенням причин відмови. o «у роботі» - Оператор присвоює замовленню статус «У роботі» у випадках коли послуга може бути надана. При цьому Користувач повинен бути проінформований в ОКК про початок надання послуги. Пошук та вибір необхідного відео контенту відбувається поза функціоналом Сервісу та здійснюється з застосуванням даних з КСВС. o «виконано» - Оператор присвоює замовленню статус «Виконано» за результатом знайденого та відібраного відео контенту. При цьому у формі виконання замовлення має бути реалізована можливість запису посилання на зовнішній файл з відео контентом. Разом з тим повинна бути реалізована можливість інформування Користувача в ОКК про виконання замовлення, а також надання Користувачу відео контенту. | |
АРМ Адміністратора СЗВ | Загальна функціональність: авторизація та автентифікація; налаштування рольової моделі. Облік та управління користувачами (операторами): пошук Оператора; створення Оператора; перегляд Оператора; редагування Оператора; логічне видалення Оператора. Облік та управління довідниками: створення довідників; перегляд довідників; редагування довідників; логічне видалення довідників. Повинно бути передбачено використання наступних довідників: типи камер; типи статусів. |
Бек-енд системи | |
Сервіс обліку та управління камерами | Функціональність сервісу: Пошук даних камери в БД |
Назва АРМу / Сервісу | Можливості |
Читання даних камери з БД Запис даних камери до БД Вимоги до взаємодії з іншими компонентами: Сервісом адміністрування АРМ Оператора. В рамках виконання наступних операцій: o пошук картки камери; o перегляд картки камери; o отримання даних довідників в рамках операцій: а. перегляд картки камери. Сервісом обміну даними з ІАС «Майно» в рамках формування та передачі даних про камери. Сервісом обміну даними з КСВС для отримання даних про камери. Сервісом обміну даними з ОКК для: o отримання пошукового запиту по камерах; o надання відповіді на пошуковий запит по камерам. | |
Сервіс обліку та управління замовленнями | Функціональність сервісу: Пошук даних замовлення в БД: пошук, перегляд. Читання даних замовлення з БД. Запис даних замовлення до БД: створення картки замовлення, зміна статусу картки замовлення, логічне видалення картки замовлення. Вимоги до взаємодії з іншими компонентами: Сервісом адміністрування АРМ Оператора. В рамках виконання наступних операцій: o пошук картки замовлення; o перегляд картки замовлення; o створення картки замовлення; o зміна статусу замовлення; o логічне видалення картки замовлення. Сервісом обміну даними з ОКК: o отримання замовлення з ОКК; o надання статусу замовлення в ОКК. |
Сервіс адміністрування | Функціональність сервісу при роботі з користувачами: Пошук даних користувачів в БД Читання даних користувачів з БД Запис даних користувача до БД: запис, редагування, логічне |
Назва АРМу / Сервісу | Можливості |
видалення. Функціональність сервісу при роботі з довідниками: Пошук даних довідників з БД; Читання даних довідників з БД; Запис даних довідників до БД: запис, редагування, логічне видалення. Логічне видалення довідника. Вимоги до взаємодії з іншими компонентами: АРМ Оператора. Сервіс забезпечує авторизацію операторів в рамках доступу. АРМ Адміністратора СЗВ. Сервіс забезпечує авторизацію операторів в рамках доступу. Сервіс обліку та управління камерами. Сервіс забезпечує надання даних з довідників. Сервіс обліку та управління замовленнями. Сервіс забезпечує надання даних з довідників. | |
Сервіс обміну даними з ІАС «Майно» | Функціональність сервісу: Сервіс забезпечує передачу даних про камери до ГІС- системи ІАС «Майно». Вимоги до взаємодії з іншими компонентами: Сервіс обліку та управління камерами. Сервіс забезпечує надання оновлених даних по камерам. |
Сервіс обміну даними з КП «Інформатика» Комплексною системою відеоспостереження міста Києва (далі – КСВС) | Функціональність сервісу: Сервіс забезпечує отримання даних про камери від КСВС; Сервіс забезпечує передачу даних про камери до Сервісу обліку та управління камерами. Вимоги до взаємодії з іншими компонентами: Сервіс обліку та управління камерами. Сервіс забезпечує отримання нових/оновлених даних по камерам. |
Сервіс обміну даними з ОКК | Функціональність сервісу: Сервіс забезпечує отримання пошукового запиту даних по камерам від ОКК; Сервіс забезпечує надання відповіді на пошуковий запит даних по камерам до ОКК; Сервіс забезпечує отримання замовлення відео контенту від ОКК; Сервіс забезпечує надання статусу замовлення до ОКК. |
Назва АРМу / Сервісу | Можливості |
Вимоги до взаємодії з іншими компонентами: Сервіс обліку та управління камерами: в рамках отримання пошукового запиту по камерах з ОКК та надання відповіді на пошуковий запит по камерам до ОКК. Сервіс обліку та управління замовленнями: в рамках отримання замовлення з ОКК та надання статусу замовлення до ОКК. |
Склад послуг
Для реалізації СЗВ необхідно реалізувати функціональні можливості:
- рольова модель СЗВ (АРМ Оператора, АРМ Адміністратора СЗВ);
- тсервіс обліку та управління камерами;
- сервіс обліку та управління замовленнями;
- сервіс адміністрування;
- сервіс обміну даними з ІАС «Майно»;
- сервіс обміну даними з КСВС;
- сервіс обміну даними з ОКК.
Вимоги до сервісу обліку та управління камерами
Сервіс обліку та управління камерами повинен забезпечувати виконання операцій з даними картки камери.
Вимоги до сервісу обліку та управління замовленнями
Сервіс обліку та управління замовленнями повинен забезпечувати виконання операцій з даними картки замовлення.
Вимоги до сервісу адміністрування
Сервіс адміністрування повинен забезпечувати управління довідниками та налаштуваннями рольової моделі.
Вимоги до сервісу обміну даних з ІАС «Майно»
Сервіс обміну даними з ІАС «Майно» повинен забезпечувати передачу даних про камери до ГІС-системи ІАС «Майно» з метою подальшого відображення на карті міста у вигляді окремого шару.
В межах реалізації сервісу обміну даними з ІАС «Майно» повинна бути можливість надавати дані про камери;
адреса;
технічні дані.
Передача даних до ІАС «Майно» повинна здійснюватися по факту їх оновлення, а саме: на стороні Сервісу обліку та управління камерами дані про камери створено, змінено.
Вимоги до сервісу обміну даними з КСВС
Сервіс обміну даними з КСВС повинен забезпечувати:
отримання інформації, що дані по камерам були змінені від системи КСВС;
передачу даних про камеру до Сервісу обліку та управління камерами та до Сервісу замовлення відео контенту.
Тобто, по факту надходження команди до сервісу обміну даних з КСВС, що дані по
камерам були змінені, повинно відбуватися формування та надсилання змінених даних до Сервісу обліку та управління камерами. Потім необхідно здійснювати пошук камери за допомогою Сервісу замовлення відео контенту, та якщо дані про камеру:
не знайдено, то необхідно створити картку камери та завершити процес.
знайдено, то необхідно виконати зміну даних картки камери та завершити процес.
Вимоги до сервісу обміну даними з ОКК
Сервіс обміну даними з ОКК повинен забезпечувати:
отримання пошукового запиту даних по камерам від ОКК;
надання відповіді на пошуковий запит даних по камерам до ОКК;
отримання замовлення відео-контенту від ОКК;
надання статусу замовлення до ОКК.
Рольова модель
Облік користувачів та управління користувачами виконується на основні рольової моделі СЗВ. Перелік ролей СЗВ та права користувачів приведено у табл. 2.
Таблиця 3. Рольова модель СЗВ
Назва ролі | Права |
Оператор | 1. Пошук, перегляд, редагування картки камери 2. Пошук перегляд, створення, зміна статусу картки замовлення |
Адміністратор СЗВ | 1. Читання, створення, редагування, видалення користувачів та налаштування їх прав та ролей. 2. Створення, редагування, видалення довідників системи. 3. Створення, редагування та логічне видалення картки послуги. 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).
Вимоги до метрологічного забезпечення
Вимог до метрологічної сумісності технічних засобів не пред’являється. Якісні характеристики Системи перевіряються на випробуваннях згідно з Програмою і методикою випробувань. На вимогу Замовника метрологічна сумісність технічних засобів може бути проведена сторонніми організаціями.
Вимоги до організаційного забезпечення
Організаційне забезпечення, що впроваджуватиметься в межах створення / розвитку Системи, повинно включати документи, які відображатимуть автоматизований технологічний процес обробки інформації та регламентуватимуть діяльність користувачів.
Вимоги до методичного забезпечення
Рішення щодо методичного забезпечення повинно враховувати оптимізацію ділових (функціональних) процесів, що відображують автоматизацію цих процесів.
СКЛАД ТА ЗМІСТ ПОСЛУГ
Склад та зміст послуг з розвитку Системи
Склад та зміст робіт з розвитку Системи передбачає наступні етапи:
1й етап
Розробка технічного завдання
Розробка Технічного завдання на створення ПМ РСНП.
Розробка Технічного завдання на створення ПМ СЗВ.
2й етап
Розробка та модернізація програмного забезпечення, розробка документації
Розробка програмного забезпечення;
Розробка документації;
o Опис системи ПМ РСНП;
o Опис системи ПМ СЗВ;
o Керівництво Системного адміністратора ПМ РСНП;
o Керівництво Системного адміністратора ПМ СЗВ;
o Програма та методика попередніх випробувань ПМ РСНП;
o Програма та методика попередніх випробувань ПМ СЗВ;
o Протокол попередніх випробувань ПМ РСНП;
o Протокол попередніх випробувань ПМ СЗВ;
o Акт приймання в дослідну експлуатацію ПМ РСНП;
o Акт приймання в дослідну експлуатацію ПМ СЗВ.
3й етап
Дослідна експлуатація програмного забезпечення Системи, розробка документації
Програма та методика дослідної експлуатації ПМ РСНП;
Програма та методика дослідної експлуатації ПМ СЗВ;
Керівництво Користувача РСНП;
Керівництво Користувача СЗВ;
Керівництво Адміністратора РСНП;
Керівництво Адміністратора СЗВ;
Протокол дослідної експлуатації ПМ РСНП;
Протокол дослідної експлуатації ПМ СЗВ.
Вимоги до документації та методичного забезпечення
Склад документації на розвиток Системи включає наступне:
Технічне завдання;
Програма та методика попередніх випробувань;
Програма та методика дослідної експлуатації;
Опис Cистеми в частині оновлення (документ також повинен включати в себе опис Бази даних);
Керівництво Системного адміністратора. Документ повинен включати в себе:
o інструкцію з розгортання та налаштування;
o перелік інформаційних ресурсів Системи із рекомендаціями щодо резервного копіювання;
o рекомендації щодо моніторингу працездатності Системи за певним набором ключових показників інформаційного характеру.
Керівництво Користувача;
Керівництво Адміністратора (документ повинен включати в себе інструкцію з формування та ведення бази даних);
Протокол попередніх випробувань;
Протокол дослідної експлуатації.
Вимоги щодо методичного забезпечення можуть бути уточнені в Технічному завданні.
ЗАМОВНИК | ВИКОНАВЕЦЬ |