„Инвентаризация на информационно-комуникационната инфраструктура за нуждите на електронното управление“ по проект BG05SFOP001-1.001-0001 „Инвентаризация на информационно-комуникационната инфраструктура за нуждите на електронното управление“,...
79
Приложение № 1 към чл. 38, ал. 3
|
ТЕХНИЧЕСКО ЗАДАНИЕ |
за обществена поръчка с предмет: |
„Инвентаризация на информационно-комуникационната инфраструктура за нуждите на електронното управление“ по проект BG05SFOP001-1.001-0001 „Инвентаризация на информационно-комуникационната инфраструктура за нуждите на електронното управление“, финансиран по Оперативна програма „Добро управление” 2014-2020 г., съфинансирана от Европейския съюз чрез Европейския социален фонд |
|
СЪДЪРЖАНИЕ
1. РЕЧНИК НА ТЕРМИНИ, ДЕФИНИЦИИ И СЪКРАЩЕНИЯ 4
1.2. Дефиниции за нива на електронизация на услугите 6
2.2. За възложителя – функции и структура 7
3. Цели, обхват и очаквани резултати от изпълнение на проекта 10
3.1. Общи и специфични цели на проекта 10
5. ИЗИСКВАНИЯ КЪМ ИЗПЪЛНЕНИЕ НА ПОРЪЧКАТА 15
5.1. Общи изисквания към изпълнението на обществената поръчка 15
5.2. Общи организационни принципи 16
6. ОБЩИ ИЗИСКВАНИЯ ЗА ИНФОРМАЦИОННИ СИСТЕМИ В ДЪРЖАВНАТА АДМИНИСТРАЦИЯ 27
6.1.1. Интеграция с външни информационни системи 27
6.1.3. Технически изисквания към интерфейсите 28
6.1.4. Електронна идентификация на потребителите 29
6.1.6. Портал за мрежова и информационна сигурност 30
6.1.7. Формиране на изгледи 31
6.1.8. Администриране на системата 31
6.2. Нефункционални изисквания към информационната система 31
6.2.1. Авторски права и изходен код 31
6.2.2. Системна и приложна архитектура 32
1.1.2.1 Надграждане на съществуващата АИС за инвентаризация на ИКИ ресурсите 33
1.1.2.2 Разработка на Уеб приложен модул за визуализация на регистъра на информационните ресурси. 36
1.1.3. Повторно използване (преизползване) на ресурси и готови разработки 38
1.1.4. Изграждане и поддръжка на множество среди 40
6.2.5. Процес на разработка, тестване и разгръщане 41
6.2.6. Бързодействие и мащабируемост 42
6.2.6.1 Контрол на натоварването и защита от DoS/DDoS атаки 42
6.2.6.3 Използване на HTTP/2 42
6.2.6.4 Качество и сигурност на програмните продукти и приложенията 43
6.2.7. Информационна сигурност и интегритет на данните 43
6.2.8.1 Общи изисквания за използваемост и достъпност 46
6.2.8.2 Интернационализация 48
6.2.8.3 Изисквания за използваемост на потребителския интерфейс 50
2. ИЗИСКВАНИЯ КЪМ ИЗПЪЛНЕНИЕТО НА ДЕЙНОСТИТЕ ПО ПРОЕКТА 52
6.3.1. Описание и изисквания на дейността 52
7.1.1.2. Изграждане на Регистър на информационните ресурси 54
6.4.1. Описание и изисквания на дейността 61
6.5. Изисквания към документацията 73
6.6. Прозрачност и отчетност 74
6.8. Техническа документация 75
Акроним |
Описание |
АИС |
Автоматизирана информационна система |
АМС |
Администрация на Министерския съвет |
АОП |
Агенция по обществени поръчки |
АПК |
Административно-процесуален кодекс |
БУЛСТАТ |
Регистър Булстат |
ДАЕУ |
Държавна агенция "Електронно управление" |
ЗДОИ |
Закон за достъп до обществена информация |
ЗЕДЕП |
Закон за електронния документ и електронния подпис |
ЗЕУ |
Закон за електронното управление |
ИКТ |
Информационни и комуникационни технологии |
КАО |
Комплексно административно обслужване |
ИКИ |
Информационно-комуникационна инфраструктура |
ТР |
Търговски регистър |
ДХЧО |
Държавен хибриден частен облак |
SDK |
Software development kit |
API |
Application programming interface/Приложно програмен интерфейс |
ИСПОДСА |
Информационна система за попълване на отчетните доклади за състоянието на администрацията |
ИИСДА |
Интегрирана информационна система на Държавната администрация |
АИС на ИКИ ресурсите |
Автоматизирана информационна система за одит на ресурсите информационно-комуникационната инфраструктура |
РИР |
Регистър на информационните ресурси |
НОИИСРЕАУ |
Наредба за общите изисквания към информационните системи, регистрите и електронните административни услуги |
Технологични дефиниции
Термин |
Описание |
Виртуална комуникационна инфраструктура |
Инфраструктура, която на база съществуваща физическа свързаност, предоставена от ДАЕУ, предоставя възможност за изграждане на отделни и защитени виртуални мрежи за всяка една от структурите в сектора, при гарантиране на сигурен и защитен обмен на информация в тях. |
Държавен хибриден частен облак |
Централизирана на ниво държава информационна инфраструктура (сървъри, средства за съхранение на информация, комуникационно оборудване, съпътстващо оборудване, разпределени в няколко локации, в помещения отговарящи на критериите за изграждане на защитени центрове за данни), която предоставя физически и виртуални ресурси за ползване и администриране от секторите и структурите, които имат достъп до тях, в зависимост от нуждите им, при гарантиране на високо ниво на сигурност, надеждност, изолация на отделните ползватели и невъзможност от намеса в работоспособността на информационните им системи или неоторизиран достъп до информационните им ресурси. Изолацията на ресурсите и мрежите на отделните секторни ползватели (е-Общини, е-Правосъдие, е-Здравеопазване, е-Полиция) се гарантира с подходящи мерки на логическо ниво (формиране на отделни клъстери, виртуални информационни центрове и мрежи) и на физическо ниво (клетки и шкафове с контрол на достъпа). |
Софтуер с отворен код |
Компютърна програма, която се разпространява при условия, които осигуряват безплатен достъп до програмния код и позволяват: Използването на програмата и производните на нея компютърни програми, без ограничения в целта; Промени в програмния код и адаптирането на компютърната програма за нуждите на нейните ползватели; Разпространението на производните компютърни програми при същите условия. Списък на стандартни лицензионни споразумения, които предоставят тези възможности, който може да бъде намерен в подзаконовата нормативна уредба към Закона за електронно управление или на: xxxx://xxxxxxxxxx.xxx/xxxxxxxx. |
Машинночетим формат |
Формат на данни, който е структуриран по начин, по който, без да се преобразува в друг формат позволява софтуерни приложения да идентифицират, разпознават и извличат специфични данни, включително отделни факти и тяхната вътрешна структура. |
Отворен формат
|
Означава формат на данни, който не налага употребата на специфична платформа или специфичен софтуер за повторната употреба на съдържанието и е предоставен на обществеността без ограничения, които биха възпрепятствали повторното използване на информация. |
Xxxxxxxxx
|
Xxxxx, описващи структурата на информацията, предмет на повторно използване. |
Официален отворен стандарт
|
Стандарт, който е установен в писмена форма и описва спецификациите за изискванията как да се осигури софтуерна оперативна съвместимост. |
Система за контрол на версиите
|
Технология, с която се създава специално място, наречено „хранилище”, където е възможно да се следят и описват промените по дадено съдържание (текст, програмен код, двоични файлове). Една система за контрол на версиите трябва да може:
Цялата информация, налична в системата за контрол на версиите за главното копие на хранилището, прието за оригинален и централен източник на съдържанието, трябва да може да бъде достъпна публично, онлайн, в реално време. |
Първичен регистър |
Xxxxxxxx, който се поддържа от първичен администратор на данни - административен орган, който по силата на закон събира или създава данни за субекти (граждани или организации) или за обекти (движими и недвижими) за първи път и изменя или заличава тези данни. Например Търговският регистър е първичен регистър за юридическите лица със стопанска цел, Имотният регистър е първичен регистър за недвижима собственост. |
Дефиниции за нива на електронизация на услугите
ВЪВЕДЕНИЕ
Термин |
Описание |
Ниво 1 |
Информация - предоставяне на информация за административни услуги по електронен път, включително за начини и места за заявяване на услугите, срокове и такси. |
Ниво 2 |
Едностранна комуникация - информация съгласно дефиницията за Ниво 1 и осигурен публичен онлайн достъп до шаблони на електронни формуляри. |
Ниво 3 |
Двустранна комуникация - заявяване и получаване на услуги изцяло по електронен път, включително електронно подаване на данни и документи, електронна обработка на формуляри и електронна персонална идентификация на потребителите. |
Ниво 4 |
Извършване на сделки или транзакции по услуги от Ниво 3, включващи онлайн разплащане или доставка. |
Държавна агенция „Електронно управление“ (ДАЕУ) е конкретен бенефициент по процедура „Структуриране на данни и аналитични дейности в изпълнение на стратегическите документи за развитие на държавната администрация, развитие на електронното управление и въвеждането на електронното управление в сектор „Правосъдие“ по Оперативна програма „Добро управление“.
Целта на настоящия документ е да запознае участниците със същността, целите и дейностите на проекта и да опише изискванията към изпълнението на обществена поръчка с предмет: „Инвентаризация на информационно-комуникационната инфраструктура за нуждите на електронното управление“ по проект BG05SFOP001-1.001-0001, финансиран по Оперативна програма „Добро управление” 2014-2020 г., съфинансирана от Европейския съюз чрез Европейския социален фонд. В настоящото техническо задание са описани и изискванията към проектната организация, документацията и отчетността.
Възложител на настоящата обществена поръчка е Държавна агенция „Електронно управление“.
Структурата на Държавна агенция „Електронно управление“ е представена във Фигура 1:
Фигура 1. Структура на Възложителя
Обществената поръчка се обявява във връзка с проект № BG05SFOP001-1.001-0001 „Инвентаризация на информационно-комуникационната инфраструктура за нуждите на електронното управление“, финансиран по Оперативна програма „Добро управление” 2014-2020 г. с финансовата подкрепа на Европейския съюз чрез Европейския социален фонд.
На 19.01.2016 г. Изпълнителна агенция „Електронни съобщителни мрежи и информационни системи“ (ИА ЕСМИС) сключи договор за безвъзмездна финансова помощ по проект BG05SFOP001-1.001-0001 „Инвентаризация на информационно-комуникационната инфраструктура за нуждите на електронното управление“ по Процедура BG05SFOP001-1.001, по Оперативна програма „Добро управление” 2014-2020 (ОПДУ), Приоритетна ос № 1 „Административно обслужване и е-управление“ (ПО1).
На 01.07.2016 г. бяха обнародвани промени в Закона за електронното управление /ЗЕУ/, като в разпоредбата на чл. 7а от закона е посочено, че към Министерския съвет се създава Държавна агенция „Електронно управление“ в състава на която преминава ИА ЕСМИС. Активите, пасивите, архивът, както и другите права и задължения на закритата Изпълнителна агенция „Електронни съобщителни мрежи и информационни системи” преминават към Държавна агенция „Електронно управление“, която е настоящият бенефициент по проекта.
ОПДУ е стратегически документ за провеждане на европейски политики, съфинансирани от Европейския социален фонд на Европейския съюз и националния бюджет в рамките на програмния период 2014-2020 г.. Бюджетът на програмата за целия период на изпълнението й е 335 919 605,00 евро, 85% от които са от Европейския социален фонд.
Законът за обществените поръчки и Правилникът за неговото прилагане уреждат реда за възлагане и изпълнение на настоящата обществена поръчка.
Законът за управление на средствата от Европейските структурни и инвестиционни фондове определя рамката за управлението на средствата от Европейските структурни и инвестиционни фондове.
Общата цел на проекта е извършване на инвентаризация на информационната и комуникационна инфраструктура (ИКИ) на централните, областните и общинските администрации, без тази на сектор „Правосъдие“, за структуриране на информация и данни в подкрепа на изпълнението на Стратегията за развитие на електронното управление в Република България 2014-2020 г., оптимизиране на разходите и изграждане на средата за електронно управление.
Специфичните цели на проекта са:
Осигуряване на данни за бъдещи стратегически интервенции чрез съставяне на „карта“ на ИКИ на администрацията към настоящия момент за нуждите на електронното управление;
Създаване на предпоставки за налагане на модел за следене и оптимизация на разходите за изграждане и поддържане на интегрирана среда за развитие и функциониране на системата на електронното управление;
Извършване на пълен преглед на състоянието на ИКТ, информационните системи и свързани с тях услуги на администрациите в Република България. Обобщените данни от прегледа ще дадат пълна информация за статуса им и ще послужат за оценка на необходимия капацитет и ресурси за обслужване на наличните процеси, както и за сравнителна оценка относно желаното състояние в контекста на предвижданите реформи. По този начин ще се отговори и на потребността от анализи за осигуряване на допълнителна техника за дигитализация и централизация на информационните масиви с оглед въвеждане изискванията за е-управление и секторните стратегии към него;
Надграждане на съществуващата информационна система за инвентаризация на информационните ресурси на МП и изграждане на електронен регистър на информационните ресурси на администрациите в съответствие с чл.7г от ЗЕУ и интегрирането му към интегрираната информационна система на Държавната администрация (ИИСДА), Портала за мрежова и информационна сигурност (xxxxx://xxxxxxx.xx/), Портала за отворени данни и модула за е-автентификация, разработен за нуждите на електронното управление.
Описаните в т. 3.1 цели се осъществяват с изпълнението на следните основни дейности, които формират обхвата на обществената поръчка:
Дейност 1. Надграждане и внедряване на разработената от Министерство на правосъдието информационна система за одит на ИКИ ресурсите и изграждане на Регистър на информационните ресурси:
Поддейност 1.1. Надграждане и внедряване на разработената от Министерство на правосъдието информационна система за инвентаризация (одит) на ИКИ
В рамките на тази дейност ще бъде надградена и внедрена вече изградената от МП АИС за инвентаризация на ИКИ. Тя трябва да бъде интегрирана за предоставяне на данни чрез автоматизиран интерфейс с Интегрираната информационна система на държавната администрация (наименование и организационна структура, адреси на които оперират и др.), с Портала за мрежова и информационна сигурност (xxxxx://xxxxxxx.xx/) и с Портала за отворени данни. В рамките на тази дейност е необходимо да се извърши интеграция на системата с модул е-автентификация, разработен за нуждите на електронното управление.
Поддейност 1.2. Изграждане на Регистър на информационните ресурси
Изпълнителят ще трябва да изгради уеб базиран електронен регистър. Той ще надгражда АИС за инвентаризация на ИКИ, разработена за нуждите на МП.
Поддейност 1.3. Организиране и провеждане на обучение за работа с информационната система и Регистъра на информационните ресурси и за провеждане на инвентаризация по места с въвеждане и валидиране на данните. В рамките на тази поддейност следва да бъдат обучени 140 лица от ДАЕУ в 3 панела за провеждане на инвентаризацията, работа с информационната система и Регистъра на информационните ресурси.
Дейност 2. Провеждане на инвентаризация по места, въвеждане, валидиране и анализ на данните.
Дейността ще обхване централните, областните и общинските администрации, с изключение на администрациите от сектор „Правосъдие“. Тя ще се изпълнява съвместно от Възложителя и избрания Изпълнител.
Целевите групи, към които е насочен проектът, обхващат:
ДА „Електронно управление“;
Министерства и ведомства;
Областни администрации;
Общински администрации.
По дейност 1:
• Въведена информационна система за одит на ИКИ на централната, областната и общинската администрация.
• Разработен и внедрен регистър на информационните ресурси;
• Проведено едно обучение в 3 панела и обучени 140 служители от ДАЕУ за провеждане на инвентаризацията, работа с информационната система за одит на ИКИ и Регистъра на информационните ресурси.
По дейност 2.
Извършена инвентаризация на ИКИ в 576 администрации в най-малко 2 005 локации, инвентаризирани от Изпълнителя съгласно (Приложение 1) чрез физическо посещение и/или с алтернативни методи;
Въведени, валидирани и верифицирани в АИС данни за инвентаризираните администрации;
Извършени анализи на постъпилите от инвентаризацията данни. На база на въвежданата информация в Регистъра на информационните ресурси изпълнителят следва да представи следните анализи:
Анализ на наличния и използвания капацитет на инфраструктурата;
Анализ на осигуряването с адекватна техническа поддържка на информационните ресурси;
Анализ на експлоатационните разходи за информационните ресурси;
Анализ на рисковете за инфраструктурата и информационните ресурси.
Периодът на изпълнение е не по-късно от 30.06.2018 година. Участниците трябва да изготвят подробен график, в който следва да се конкретизират сроковете за изпълнение на всяка дейност и поддейност от настоящата поръчка. Допустимо е едновременното изпълнение на някои от дейностите и поддейностите при запазване на логическата им последователност и максималната им продължителност, ако има такава, посочена в т. 7.
АИС на ИКИ ресурсите за нуждите на МП притежава следните характеристики:
Същата е изградена като уеб базирана система;
АИС е продукт с отворен код;
Всички авторски и сродни права, изходен програмен код, дизайнът на интерфейсите и базите данни, чиято разработка са били предмет на поръчката на МП, са възникнали за Възложителя в пълен обем, без ограничения в използването, изменението и разпространението им, към момента на внедряване на системата в редовна експлоатация;
АИС предоставя възможност за едновременно използване от повече от една администрация, съгласно действащите изисквания за оперативна съвместимост и информационна сигурност;
АИС осигурява възможност за централизиран достъп до обобщена информацията за ИКИ активите по ведомства на ниво централна администрация;
AИС e разработена и ще бъде инсталирана и внедрена върху инфраструктурата на Възложителя в условията на спазване на изискванията за мрежова и информационна сигурност и оперативна съвместимост. Системата е реализирана по начин, по който позволява едновременното й използване от повече от една администрация. Сигурността на системата е реализирана в два основни аспекта:
Към момента, достъпът до системата се осъществява чрез защитена (https) връзка, управлявана от сървъра, която изисква идентификация и автентификация чрез уникално потребителско име и комплексна парола.
АИС е изградена в условията на спазване всички функционални и нефункционални изисквания. Същата притежава следните възможности:
Въведените активи се виждат от всички потребители с подходящи права в момента на тяхното въвеждане в системата;
Осигурена е възможност за лесно и автоматизирано генериране на справки;
Осигурена е възможност за въвеждане на данни за активи от структурирани файлове с данни по предварително зададени шаблони;
Системата предоставя възможност за автоматизирано периодично архивиране на данни по зададени критерии от Възложителя;
Системата управлява сигурно достъпа до себе си и данните, базирано на роли и права;
Създаден е гъвкав потребителски интерфейс, който позволява възможност за редактиране на електронните форми.
Системата проследява и създава записи за целите на последваща проверка от администратор на данни относно:
Успешно / неуспешно влизане на потребител в АИС (Logon);
Успешно / неуспешно излизане на потребител от АИС (Logoff);
Ръчна въвеждане и актуализация на данни;
Въвеждане (upload) на данни в АИС;
Експорт на данни от системата;
Дефиниране / модифициране на потребител;
Дефиниране / модифициране на права;
Дефиниране / модифициране на роли;
Принудително прекъсване на сесията на даден потребител.
Настоящата поръчка с предмет „Инвентаризация на информационно-комуникационната инфраструктура за нуждите на електронното управление“ се изпълнява в рамките на проект BG05SFOP001-1.001-0001 „Инвентаризация на информационно-комуникационната инфраструктура за нуждите на електронното управление“, финансиран по Оперативна програма „Добро управление” 2014-2020 г., съфинансирана от Европейския съюз чрез Европейския социален фонд“ В изпълнение на проекта ще бъдат реализирани дейности за цялостна инвентаризация на информационната и комуникационна инфраструктура в централните, областните и общинските администрации, с изключение на тези от сектор „Правосъдие“.
Задължително изискване е да се спазят утвърдените хоризонтални и вертикални принципи на организация на изпълнението на предмета на обществената поръчка за гарантирано постигане на желаните резултати от проекта, така че да се покрие пълният набор от компетенции и ноу-хау, необходими за изпълнение на предмета на поръчката, а също така да се гарантира и достатъчно ниво на ангажираност с изпълнението и проблемите на проекта:
Хоризонталният принцип предполага ангажиране на специалисти от различни звена, така че да се покрие пълният набор от компетенции и ноу-хау по предмета на проекта и същевременно екипът да усвои новите разработки на достатъчно ранен етап, така че да е в състояние пълноценно да ги използва и развива и след приключване на проекта;
Вертикалният принцип включва участие на експерти и представители на различните управленски нива, така че управленският екип да покрива както експертните области, необходими за правилното и качествено изпълнение на проекта, така и управленски и организационни умения и възможности за осъществяване на политиката във връзка с изпълнението на проекта. Чрез участие на ръководители на звената – ползватели на резултата от проекта, ще се гарантира достатъчно ниво на ангажираност на институцията с проблемите на проекта.
Управление на проекта1
Участниците трябва да предложат методология за управление на проекта, която смятат да приложат, като се изтъкнат ползите й за успешното изпълнение на проекта. Предложената методология трябва да съответства на най-добрите световни практики и препоръки (например Project Management Body of Knowledge (PMBOK) Guide, PRINCE2, Agile/SCRUM/Kanban, RUP и др. еквивалентни).
5.3.1. Отговорен орган от страна на Възложителя
Отговорният орган за контрол на изпълнението на договора ще бъде упълномощен от Възложителя.
5.3.2. Управление на договора от страна на Изпълнителя
Изпълнителят трябва да опише ясна и подробна методология за управление на договора и да представи проект на План-график за изпълнение на договора.
5.3.3. Начин на приемане на документите и другите материали от изпълнението на договора, офис и оборудване
Етапите на изпълнение на договора се приемат по следния ред:
Предаване на документация
Предаването на докладите, документите и другите материали, изготвени във връзка с изпълнението на договора се осъществява чрез приемо-предавателен протокол между Изпълнителя и Възложителя.
Изискване за спазване на мерките за информация и публичност
Изпълнителят се задължава да извърши всички необходими дейности за информиране и публичност в съответствие с разпоредбите на приложение XII от Регламент (ЕС) № 1303/2013 и Единния наръчник на бенефициента за прилагане на правилата за информация и комуникация 2014-2020 г., публикуван на xxxx://xxx.xxxxxxx.xx
Върху документите и материалите, свързани с изпълнението на договора Изпълнителят се задължава да поставя следните данни:
Наименованието на ЕСФ и флага на ЕС;
Наименованието и логото на ОПДУ 2014-2020;
Наименованието на проекта, който се изпълнява;
Изречението „Проектът се финансира от Европейския социален фонд и от държавния бюджет на Република България”.
За информацията, разпространявана по електронен път (напр. уебсайтове, електронни съобщения и т.н.) или чрез аудиовизуални материали, описаните мерки се прилагат аналогично.
Офис
Поръчката е с обхват - територията на цялата страна.
Оперативната база за изпълнението на проекта ще бъде в София, където Изпълнителят следва да притежава офис за периода на изпълнение на договора. Всички разходи за офиса са за негова сметка.
Оборудване, което ще се осигури от Изпълнителя
Изпълнителят ще покрие всички административни и логистични разходи, както и офис-консумативите и другите необходими за изпълнението на договора материали.
Екип за изпълнение на поръчката
Възложителят изхожда от разбирането, че при обществени поръчки за интелектуални услуги професионалната компетентност на ръководния и експертен екип, предложен от участника, е аспект неразривно свързан с предмета на поръчката, и по-специално с нейното качество. С оглед на това Възложителят изисква участниците да разполагат с екип за изпълнение на поръчката състоящ се минимум от:
Ръководител екип – 1 брой;
Експерт „Системен архитект” - 1 брой;
Експерт „Бизнес анализатор“ – 2 броя;
Експерт „Бази данни” - 2 броя;
Експерт „Обезпечаване на работата на контактния център“ – 6 броя;
Експерт „Консултант „ИКТ“ – 5 броя;
Експерт „Инвентаризация“ - 140 броя.
За членовете на екипа е задължително да притежават минимална образователна и професионална компетентност за изпълнението на поръчката, както следва:
1. Ръководител екип – 1 брой;
Квалификация: висше образование с минимална образователно-квалификационна степен „магистър“ или еквивалент по специалност, в някое от следните професионални направления: математика; информатика и компютърни науки; инженерни науки; електротехника, електроника и автоматика; комуникационна и компютърна техника; информационни системи и технологии или еквивалентни.
Допълнителна квалификация:Притежаване на минимум един сертификат по управление на проекти като PMP (сертификат за управление на проекти от PMI), MSF, PRINCE 2 или еквивалентен и/или сертификат по някоя от методологиите за управление на софтуерна разработка и/или предоставяне на IT услуги ( RUP, SCRUM, ITIL или еквивалентни)
Професионален опит:
- Минимум 5 години професионален опит в сферата на проектиране, разработване, внедряване и поддръжка на информационни системи или изследване/анализ и оценка на комуникационна архитектура или приложна архитектура или техническо състояние на хардуерно и софтуерно оборудване или еквивалент.
- Да притежава опит като ръководител на минимум два ИТ проекта или ръководител на екип за изпълнение на минимум една дейност свързана с проектиране, разработване, внедряване и поддръжка на информационни системи или изследване/анализ и оценка на комуникационна архитектура или приложна архитектура или техническо състояние на хардуерно и софтуерно оборудване или еквивалент.
2. Експерт: „Системен архитект”- 1 брой:
Квалификация:
Висше образование, минимална образователно-квалификационна степен „бакалавър” или еквивалент по специалност, в някое от следните професионални направления: математика; информатика и компютърни науки; машинно инженерство; електротехника, електроника и автоматика; комуникационна и компютърна техника; информационни системи и технологии или еквивалентни.
Професионален опит:
Минимум 3 години професионален опит, включващ проектиране и изграждане на софтуерни модели и/или софтуерни архитектури и в изграждането на разпределени и многослойни информационни решения или еквивалент.Участие в най-малко 1 проект или дейности в областта на информационните технологии, свързани с проектирането на софтуерни архитектури или опит в изграждането на разпределени или многослойни информационни решения или еквивалент.
3. Експерт: Бизнес анализатор – 2 броя:
Квалификация:
Висше образование, минимална образователно-квалификационна степен „бакалавър“ или еквивалент в областта на природни науки, математика и информатика; социални, стопански и правни науки; технически науки или еквивалентни.
Професионален опит за всеки един от тях:
Минимум 3 години професионален опит в разработване на функционални изисквания за информационни системи и в разработката на спецификации за тестване или еквивалент.
Участие като бизнес аналитик в минимум 1 проект или дейност в областта на разработването на информационни системи или проект или дейност в областта на анализа на данни или еквивалент.
4. Експерт: „Бази данни”- 2 броя:
Квалификация:
Висше образование, минимална образователно-квалификационна степен „бакалавър” или еквивалент по специалност, в някое от следните професионални направления: математика; информатика и компютърни науки; инженерни науки; електротехника, електроника и автоматика; комуникационна и компютърна техника; информационни системи и технологии или еквивалентни.
Професионален опит:
Минимум 3 години професионален опит в проектиране, изграждане, оптимизация на комплексни бази данни, поддръжка и администриране на бази данни или еквивалент;
Участие в минимум 1 проект или отделни дейности по проект, свързани с проектиране, изграждане, внедряване и поддържане на бази данни за информационни системи или еквивалент.
5. Експерт „Обезпечаване на работата на контактния център“ – 6 броя:
Квалификация:
Висше образование, минимална образователно-квалификационна степен „бакалавър” или средно техническо образование или еквивалентна по специалност, в някое от следните професионални направления: математика; информатика; компютърни науки; инженерни науки; електроника и автоматика; компютърна и комуникационна техника; информационни системи и технологии или еквивалентни.
Професионален опит:
Минимум 1 година професионален опит в контактен център, help-desk или еквивалентен за подпомагане на потребители на информационни системи, поддръжка на мрежи за пренос на данни, хардуер, софтуер и оборудване.
6. Експерт „Консултант „ИКТ“ – 5 броя;
Квалификация:
Висше образование, минимална образователно-квалификационна степен „магистър” или еквивалент по специалност, в някое от следните професионални направления: математика; информатика и компютърни науки; електроника и автоматика; електротехника, инженерни науки; комуникационна и компютърна техника; информационни системи и технологии или еквивалентни.
Професионален опит:
Минимум 5 години професионален опит в изграждане, инсталиране, пускане в експлоатация и поддръжка на хардуерни решения за информационни системи и/или хардуерно и комуникационно оборудване и/или виртуализация и /или проектиране, разработване, внедряване и поддръжка на информационни системи и/или конфигуриране и преконфигуриране на комуникационно оборудване или диагностициране, локализиране и отстраняване на проблеми в мрежата или изграждане и поддържане на мрежи за пренос на данни или еквивалент.
Участие в минимум 1 проект или дейности по проект за изграждане, инсталиране, пускане в експлоатация и поддръжка на хардуерни решения за информационни системи и/или хардуерно и комуникационно оборудване и/или виртуализация и /или проектиране, разработване, внедряване и поддръжка на информационни системи и/или конфигуриране и преконфигуриране на комуникационно оборудване или диагностициране, локализиране и отстраняване на проблеми в мрежата или изграждане и поддържане на мрежи за пренос на данни или еквивалент.
7. Експерт „Инвентаризация“ - 140 броя:
Квалификация:
Висше или средно техническо образование или еквивалент по специалност в областта на електронна техника, инженерни науки, машиностроене, информационни технологии или еквивалентни.
Професионален опит:
Минимум 1 /една/ година професионален опит в областта на информационните технологии или еквивалент.
В документацията участникът трябва да посочи опита и професионалната квалификация на членовете на екипа по точки от 1 до 6 и само на 20 експерта „Инвентаризация“.
5.3.4. Участникът, избран за изпълнител, следва да притежава валиден сертификат за информационна сигурност EN ISO 27001 в актуална версия или еквивалент, чийто обхват да е относим към предмета на обществената поръчка.
За доказване на посоченото изискване участниците следва да представят към техническата си оферта копие на издаден валиден сертификат за информационна сигурност EN ISO 27001 в актуална версия или еквивалент, чийто обхват да е относим към вида на услугите в настоящата поръчка. Съгласно, чл. 64, ал. 6-7 от ЗОП възложителят приема и други доказателства за еквивалентни мерки за осигуряване на качеството с обхват, отговарящ на предмета на поръчката.
Важно!! В случай, че участникът бъде избран за изпълнител е длъжен в срок не по-късно от датата на сключване на договора да удължи срока на валидност на сертификатa по т. 5.3.4. за целия период на изпълнение.
В техническото си предложение участниците трябва да опишат подхода за управление на риска, който ще прилагат при изпълнението на поръчката. Участниците трябва да представят и списък с идентифицираните от Възложителя рискове с оценка на вероятност, въздействие и мерки за реакция.
През времето за изпълнение на проекта Изпълнителят трябва да следи рисковете, да оценява тяхното влияние, да анализира ситуацията и да идентифицира (евентуално) нови рискове. В хода на изпълнение на поръчката Изпълнителят следва да докладва състоянието на рисковете на месечна база.
При изготвянето на списъка с рискове Участниците следва да вземат предвид следните идентифицирани от Възложителя рискове:
Недобра комуникация между екипите на Възложителя и Участника по време на различните етапи на изпълнение на проекта, в резултат на което може да се получи непостигане на целите на проекта;
Недостатъчна яснота по правната рамка и/или променяща се правна рамка по време на изпълнение на проекта, което може да доведе до концептуални непълноти и разминавания между цели и резултати;
Недостатъчна ангажираност на персонала по време на изпълнение на услугата, в резултат на което могат да се получат непълноти и/или забавяне;
Неправилно и неефективно разпределяне на ресурсите и отговорностите по предоставянето на услугата;
Неточно и некачествено събиране на данни - информацията не е коректно въведена в информационната система, липсват данни;
Недостатъчни, липсващи или неправилно разпределени ресурси (човешки, финансови, технически средства и др.).
Изпълнителят трябва да осигури за своя сметка гаранционна поддръжка за период от минимум 36 (тридесет и шест) месеца след приемане в експлоатация на новоразработените служебни интерфейси (приложения) на системата и приложението с което ще се реализира Регистъра на информационните ресурси.
При необходимост, по време на гаранционния период трябва да бъдат осъществявани дейности по осигуряване на експлоатационната годност на софтуера и ефективното му използване от Възложителя, в случай че настъпят явни отклонения от нормалните експлоатационни характеристики, заложени в системния проект.
Изпълнителят следва да предоставя услугите по гаранционна поддръжка, като предоставя за своя сметка единна точка за достъп за приемане на телефонни и e-mail съобщения (help desk).
Приоритетите на проблемите се определят от Възложителя в зависимост от влиянието им върху работата на администрацията. Редът на отстраняване на проблемите се определя в зависимост от техния приоритет. Минималният обхват на поддръжката трябва да включва:
Извършване на диагностика на докладван проблем с цел осигуряване на правилното функциониране на системите и модулите;
Отстраняване на дефектите, открити в софтуерните модули, които са модифицирани или разработени в обхвата на проекта;
Консултации за разрешаване на проблеми по предложената от Изпълнителя конфигурация на средата (операционна система, база данни, middleware, хардуер и мрежи), използвана от приложението, включително промени в конфигурацията на софтуерната инфраструктура на мястото на инсталация;
Възстановяването на системата и данните при евентуален срив на системата, както и коригирането им в следствие на грешки в системата;
Експертни консултации по телефон и електронна поща за системните администратори на Възложителя за идентифициране на дефекти или грешки в софтуера;
Актуализация и предаване на нова версия на документацията на системата при установени явни несъответствия с фактически реализираните функционалности, както и в случаите, в които са извършени действия по отстраняване на дефекти и грешки, в рамките на гаранционната поддръжка. Времето за отговор е включено във времето за реакция в случай на заявка за поддръжка, изпратена по e-mail при открити проблеми в приложния софтуер е 1 (един) час, а срокът за отстраняване е в зависимост от нивото на критичност (приоритета), както следва:
Ниво на критичност (приоритет) |
Описание |
Време за реакция |
Срок за отстраняване на инциденти или проблеми |
Режим на поддържане |
Непрекъснат режим (24х7) 365 дни в годината |
||
Високо |
Системата не функционира - критична функционалност блокира или не функционира нормално или има критично отражение върху бизнес операциите на потребителите или приложната среда. |
До 1 час |
До 24 часа |
Средно |
Системата не функционира пълноценно - Критична функционалност функционира непълноценно или има силно неблагоприятно отражение върху бизнес операциите вследствие на неприемлива производителност или генериране на грешни данни. |
До 2 часа |
До 2 работни дни |
Ниско |
Нормалната производителност на системата или модул от нея, е влошена, но по-голяма част от функционалната й способност е незасегната. |
До 4 часа |
До 3 работни дни |
Искане за съдействие |
Възложителят изисква информация или помощ по въпросите на възможности на продукт, инсталация или конфигурация. Налице е малко или незначително отражение върху бизнес операциите. |
До 4 часа |
В съгласувано между екипите време в срок не по-късно от следващия работен ден |
Забележка:
Работно време е периодът от 00.00 ч. до 24.00 ч. - всеки ден от седмицата, 365 дни в годината;
Времето за реакция се отчита от момента на съобщаване до момента на потвърждаване регистрирането на повредата от Изпълнителя през определена в договора точка за контакт.
Времето за отстраняване на повредата се отчита от момента на потвърждаването на приемането й до момента на възстановяване на нормалната работоспособност на системата. Изпълнителят трябва да представи схема за работните процеси и отговорностите по поддръжката на приложния софтуер.
За реализиране на функционалности приложението трябва да поддържа интеграция в реално време с информационни системи и приложения, както следва:
Автоматизирано предоставяне на данни в частност (наименование и организационна структура, адреси на които оперират и др.) чрез автоматизиран интерфейс от ИИСДА към АИС за инвентаризация на ИКИ и Регистъра на информационните ресурси;
Интеграция на приложението (регистъра) чрез служебен приложен интерфейс с модул е-автентификация, разработен за нуждите на електронното управление;
Интеграция на системата чрез служебен приложен или програмен интерфейс към Портала за отворени данни;
Интеграция на системата чрез служебен приложен интерфейс с Портала за мрежова и информационна сигурност (https://govcert.bg/).
Приложението трябва да се реализира чрез стандартен интеграционен слой като вътрешна услуга (service).
Приложните програмни интерфейси трябва да отговарят на следните архитектурни, функционални и технологични изисквания:
Служебните онлайн интерфейси трябва да се предоставят като уеб-услуги (web-services) и да осигуряват достатъчна мащабируемост и производителност за обслужване на синхронни заявки (sync pull) в реално време, с максимално време за отговор на заявки под 1 секунда за 95% от заявките, които не включват запитвания до регистри и външни системи. Изпълнителят трябва да обоснове прогнозирано натоварване на Системата и да предложи критерии за оценка на максимално допустимото време за отговор на машинна заявка. Критерият за оценка следва да се основава на анализ на прогнозираното натоварване и на наличния хардуер, който ще се използва. Изпълнителят трябва да представи обосновано предложение за минималното време за отговор на заявка на базата на посочените по-горе критерии и да осигури нужните условия за спазването му;
Всички публични и служебни онлайн интерфейси трябва да бъдат реализирани с поддръжка на режими „push” и „pull”, в асинхронен и синхронен вариант – практическото прилагане на всяка от комбинациите трябва да бъде определено на етап бизнес-анализ и да бъдат съобразени реалните казуси (use cases), които всеки интерфейс обслужва;
Да бъде предвидено създаването и поддържането на тестова среда, достъпна за използване и извършване на интеграционни тестове от разработчици на информационни системи, включително такива, изпълняващи дейности за други администрации или за бизнеса, с цел по-лесно и устойчиво интегриране на съществуващите и бъдещи информационни системи.
Електронната идентификация трябва да се реализира чрез интеграция на разработения за нуждите на електронното управление приложен модул е-автентификация.
Трябва да бъде разработен и внедрен онлайн интерфейс за свободен публичен автоматизиран достъп до документите, информацията и данните в Системата (Регистъра). Интерфейсът трябва да осигурява достъп до данните в машинночетим, отворен формат, съгласно всички изисквания на Директива 2013/37/ЕС за повторна употреба на информацията в обществения сектор и на Закона за достъп до обществена информация.
Да бъде предвидена разработката и внедряването на отворени онлайн интерфейси и практически механизми, които да улеснят търсенето и достъпа до данни, които са на разположение за повторна употреба, като например списъци с основни документи и съответните метаданни, достъпни онлайн и в машинночетим формат, както и интеграция с портала за отворени данни http://opendata.government.bg, който съдържа връзки и метаданни за списъците с материали, съгласно изискванията на ЗДОИ.
Трябва да се разработи и да се поддържа актуално публично описание на всички служебни и отворени интерфейси, отворените формати за данни, заедно с историята на промените в тях, в структуриран машинночетим формат.
Трябва да се разработят процеси по предоставяне на данни в отворен, машинночетим формат заедно със съответните метаданни. Форматите и метаданните следва да съответстват на официалните отворени стандарти.
Да се реализира автоматизиран онлайн обмен на данни между изграждания Регистър на информационните активи и Портала за мрежова и информационна сигурност (https://govcert.bg/) чрез идентификация на информационните активи съгласно National Institute of Standards and Technology (NIST) - Common Platform Enumeration (СРЕ) (https://scap.nist.gov/specifications/cpe/), за обобщени данни за конкретна административна структура (Наименование, Тип, Подтип, ЕИК) описани по-долу:
Обобщени данни за обща софтуерна инсталационна база – операционни системи и приложени софтуери по вид:
• Статус на софтуера;
• Тип/Вид на софтуера.
Обобщени данни за мрежово оборудване:
• Статус на хардуера;
• Тип/Вид на мрежовото оборудване;
• Тип IP address;
• IP address.
Обобщени данни за сървърно оборудване:
• Статус на сървърното оборудване;
• Тип/Вид на софтуера;
• Роля на сървъра;
• Тип/вид на машината (или виртуална);
• Тип IP address;
• IP address.
Обобщени данни за публични мрежови адреси:
• Данни за начален и краен IP адрес от обхвата;
• Указване на повече от един обхват от IP адреси.
Потребителите на приложението трябва да получават разрези на информацията чрез филтриране, сортиране и агрегиране на данните. Резултатът се представя чрез визуализиране във вид на форма или таблица:
с възможност за експорт на данни в един или в няколко от изброените формати – ODF, Excel, PDF, HTML, TXT, XML, CSV и графична визуализация на същите на екран;
с възможност за експорт на данни и разпечатване на хартиен носител.
Приложението трябва да осигурява администриране на потребителските профили и правата за достъп чрез интеграция с разработения модул за е-управление - е-автентификация.
Всички компютърни програми, които се разработват за надграждане на АИС за инвентаризация на ИКИ ресурсите, трябва да отговарят на критериите и изискванията за софтуер с отворен код;
всички авторски и сродни права върху произведения, обект на закрила на Закона за авторското право и сродните му права, включително, но не само, компютърните програми, техният изходен програмен код, структурата и дизайнът на интерфейсите и базите данни, чието разработване е включено в предмета на поръчката, възникват за Възложителя в пълен обем без ограничения в използването, изменението и разпространението им и представляват произведения, създадени по поръчка на Възложителя съгласно чл. 42, ал. 1 от Закона за авторското право и сродните му права;
Приложимите и допустими лицензи за софтуер с отворен код са:
GPL (General Public License) 3.0;
LGPL (Lesser General Public License);
AGPL (Affero General Public License);
Apache License 2.0;
New BSD license;
MIT License;
Mozilla Public License 2.0
Изходният код (Source Code), разработван по проекта, както и цялата техническа документация трябва да бъде бъдат публично достъпни онлайн като софтуер с отворен код от първия ден на разработка чрез използване на система за контрол на версиите и хранилището по чл. 7в, т.18 от ЗЕУ;
Да бъде предвидено използването на Система за контрол на версиите и цялата информация за главното копие на хранилището, прието за оригинален и централен източник на съдържанието, да бъде достъпна публично, онлайн, в реално време.
Изпълнителят е необходимо да надгради съществуващата АИС за инвентаризация на ИКИ ресурсите като реализира приложен интерфейс, който да зарежда автоматично данни за (администрациите и тяхното местоположение) от ИИСДА, т.е. да бъде реализиран като вътрешна Уеб услуга (service). Зареждането на данни следва да се осъществява посредством Web service и SOAP XML протокол. Процесът се състои в изпращане на съобщение от страна на ИИСДА, обработване на същото от АИС на ИКИ ресурсите, запис и връщане на отговор.
Изпълнителят е необходимо да извърши интеграция на съществуващата АИС за инвентаризация на ИКИ ресурсите с приложният модул е- автентификация, който е разработен за нуждите на електронното управление. Същото приложение е реализирано като Уеб услуга и е разработено като система с отворен код. Същият да бъде реализиран като вътрешна Уеб услуга (service).
Изпълнителят е необходимо да реализира връзка чрез Уеб интерфейс, като вътрешна уеб услуга към Портала за отворени данни. Същият трябва да позволява автоматично зареждане (upload) на данни за статуса на ИКИ ресурсите на отделна администрация и/или други обобщени данни, които се генерират от АИС за инвентаризация на ИКИ ресурсите и да се зареждат в Портала за отворени данни. Зареждането на данни следва да се осъществява посредством Web service и SOAP XML протокол.
Изпълнителят е необходимо да реализира автоматизиран онлайн обмен на данни между изграждания Регистър на информационните ресурси и Портала за мрежова и информационна сигурност (https://govcert.bg/) чрез идентификация на информационните активи съгласно National Institute of Standards and Technology (NIST) - Common Platform Enumeration (СРЕ) (https://scap.nist.gov/specifications/cpe/) за обобщени данни подробно уточнени в етапа на анализ, описани в софтуерна спецификация.
Съществуващите модули и функционалности на системата трябва да позволяват да бъдат рефакторирани и/или надградени по начин, който да осигури изпълнението на настоящето изискване.
При надграждането, тестването и внедряването на новите приложения/приложни програмни интерфейси Изпълнителят трябва да прилага наложили се архитектурни (SOA, MVC или еквивалентни) модели и дизайн-шаблони, както и принципите на обектно ориентирания подход за разработка на софтуерни приложения;
Взаимодействията между отделните модули в АИС за инвентаризация на ИКИ ресурсите и интеграциите с външни информационни системи трябва да се реализират и опишат под формата на уеб-услуги (Web Services). За всеки от новите модули/функционалности, които се интегрират чрез АИС за инвентаризация на ИКИ ресурсите следва да се реализират и опишат приложни програмни интерфейси – Application Programming Interfaces (API). Приложните програмни интерфейси трябва да са достъпни и за интеграция на нови модули и други вътрешни или външни системи;
Приложните програмни интерфейси задължително да поддържат атрибут за версия.
Версията на програмните интерфейси, представени чрез уеб-услуги, трябва да поддържа версията по един или няколко от следните начини:
Като част от URL-а;
Като GET параметър;
Като HTTP header (Accept или друг).
За всеки отделен приложен програмен интерфейс трябва да бъде разработен софтуерен комплект за интеграция (SDK) на поне две от популярните развойни платформи (.NET, Java, PHP или други).
Системата трябва да осигурява възможности за разширяване, резервиране и балансиране на натоварването между множество инстанции на сървъри с еднаква роля.
При доразработването на приложението трябва да се предвидят възможни промени, продиктувани от непрекъснато променящата се нормативна, бизнес и технологична среда. Основно изискване се явява необходимостта информационната система и новите приложни интерфейси да бъдат разработени като гъвкави и лесно адаптивни, като се отчита законодателни, административни, структурни или организационни промени, водещи до промени в работните процеси.
Архитектурата на всички софтуерни компоненти (системни и приложни) трябва да бъдат така подбрани и/или разработени, че да осигуряват работоспособност и отказоустойчивост като единно цяло, както и недискриминационно инсталиране (без различни условия за инсталиране върху физическа и виртуална среда) и опериране в продуктивен режим, върху виртуална инфраструктура, съответно върху ДХЧО.
Всички компоненти на АИС за инвентаризация на ИКИ ресурсите и приложните програмни интерфейси, осигуряващи интеграцията, както и приложението, реализиращо РИР, трябва да бъдат разположени върху Държавния хибриден частен облак като среда за функциониране на информационната система.
Изпълнителят трябва да проектира, подготви, инсталира и конфигурира като минимум следните среди за Системата: тестова, стейджинг, продуктивна.
Системата и новоразработените приложения трябва да бъде разгърнати върху съответните среди (тестова за вътрешни нужди, тестова за външни нужди, стейджинг и продуктивна).
Мрежата на държавната администрация (ЕЕСМ) ще бъде използвана като основна комуникационна среда и като основен доставчик на защитен Интернет капацитет (Clean Pipe) – изискванията на софтуерните компоненти по отношение на използвани комуникационни протоколи, TCP портове и пр. трябва да бъдат детайлно документирани от Изпълнителя, за да се осигури максимална защита от хакерски атаки и външни прониквания чрез прилагане на подходящи политики за мрежова и информационна сигурност от Възложителя в инфраструктурата на Държавния хибриден частен облак и ЕЕСМ.
Изпълнителят е необходимо да изгради Уеб приложен интерфейс (приложение), използвайки данните в СУБД на АИС за инвентаризация на ИКИ ресурсите като основа за изграждане и поддържане на Електронния регистър на информационните ресурси.
Електронният регистър на информационните ресурси трябва да поддържа структурирани данни за ИКИ ресурсите на всяка администрация, както следва:
- хардуер, в т.ч. сървъри, настолни и мобилни компютри и устройства;
- мрежово оборудване;
- софтуер;
- софтуерни лицензи.
За всеки хардуерен и мрежови информационен ресурс се поддържат най-малко следните метаданни:
вид;
марка и модел;
продуктов номер;
сериен номер;
производител;
доставчик;
година на производство;
година на закупуване;
срок на гаранционна поддръжка;
история и условията на гаранционната и извънгаранционната поддръжка;
цена на придобиване;
разходи за извънгаранционна поддръжка.
За всеки софтуер се поддържат най-малко следните метаданни:
фирма-разработчик или отдел (вътрешен изпълнител);
изходен код или връзка към хранилището по чл. 58, ал. 2, ако са налични;
година на изграждане;
срок на гаранционна поддръжка;
история и условия на гаранционната и извънгаранционната поддръжка;
версия;
договори за разработка и надграждане;
други свързани със софтуера информационни ресурси;
цена;
разходи за извънгаранционна поддръжка.
За всеки вид лицензиран софтуерен продукт се поддържат най-малко следните данни:
разработчик;
доставчик;
срок;
използвана и максимална възможна версия;
условия за ползване;
брой закупени лицензи;
тип на лицензирането (на процесор, на ядро, на работна станция, на инсталация и др.);
единична цена.
В Уеб приложния модул е необходимо да бъде заложена функционалност, която да генерира форми и справки, които да подпомагат дейността на администрацията при изготвянето на годишен план за обновяване на информационни ресурси на всяка една от тях. В годишния план за всеки ресурс или група ресурси за всяка администрация трябва да се съдържа минимум следната информация:
планираният месец на обновяване;
причина за обновяване;
планиран бюджет.
Уеб приложният модул да дава възможност за предоставяне на агрегирани справки по всички комбинации от вписани обстоятелства, в т.ч. администрации, за които се отнасят.
Да бъде изграден служебен програмен интерфейс, който да реализира функционалност за потребители на всяка една администрация автоматизирано да вписват и заличават данни в регистъра на информационните ресурси в зависимост от техните права и роли. Това да бъде организирано като вътрешна Уеб услуга (пример Регистърът на проектите и дейностите в областта на е-управление).
За търсене трябва да се използват системи за пълнотекстово търсене (например Solr, Elastic Search). Не се допуска използването на индекси за пълнотекстово търсене в СУБД;
Трябва да бъде създаден административен интерфейс, чрез който може да бъде извършвана конфигурацията на софтуера.
Проектът следва максимално да преизползва налични публично достъпни инструменти, библиотеки и платформи с отворен код.
За реализацията на проекта следва да се използват в максимална степен софтуерни библиотеки и продукти с отворен код.
Подход за избор на отворени имплементации и продукти
За реализацията на дадена техническа функционалност обикновено съществуват множество отворени алтернативни проекти, които могат да се използват в настоящата система. Участникът следва да представи базов списък със свободните компоненти и средства, които възнамерява да използва. Отворените проекти трябва да отговарят на следните критерии:
За разработката им да се използва система за управление на версиите на кода и да е наличен механизъм за съобщаване на несъответствия и приемане на допълнения;
Да имат разработена техническа документация за актуалната стабилна версия;
Да имат повече от един активен програмист, работещ по развитието им;
Да имат възможност за предоставяне на комерсиална поддръжка;
Да нямат намаляваща от година на година активност;
По възможност проектите да са подкрепени от организации с идеална цел, държавни или комерсиални организации;
По възможност проектите да имат разработени unit tests с code coverage над 50%, а проектът да използва Continuous Integration (CI) подходи – build bots, unit tests run, регулярно използване на статични/динамични анализатори на кода и др.
Препоръчително е преизползването на проекти, финансирани със средства на Европейския съюз, както и на такива, в които Участникът има активни разработчици. Използването на closed source и на инструменти, библиотеки, продукти и системи с платен лиценз става за сметка на изпълнителя, като е допустимо в случаите, когато липсва подходяща свободна алтернатива с необходимата функционалност или тя не отговаря на горните условия.
Изпълнителят трябва да осигури поддръжка от комерсиална организация, развиваща основните отворени продукти, които ще бъдат използвани като минимум за операционните системи и софтуерните продукти за управление на базите данни.
Подход за работа с външните софтуерни ресурси
До изграждането на хранилището на изходен код в ДА „Електронно управление“, изпълнителите по договори за изграждане и надграждане на софтуер да използват съответното хранилище в общото хранилище за проекти с отворен код, финансирани с публични средства в България (към момента https://github.com/governmentbg). Използващите свободните библиотеки компоненти задават за "upstream repo" хранилищата в областта governmentbg, като задължително се реферира използваната версия/commit identificator.
Изпълнителят трябва да извърши необходимите действия за включване на направените промени в основния проект чрез "pull requests" и извършване на необходимите изисквани от разработчиците на основния проект промени до приемането им. Тези дейности трябва да бъдат извършвани по време на целия проект.
При установяване на наличие на нови версии на използваните проекти се извършва анализ на влиянието върху настоящата система. В случаите, при които се оптимизира използвана функционалност, отстраняват се пропуски в сигурността, стабилността или бързодействието, новата версия се извлича и използва след успешното изпълнение на интеграционните тестове.
Изпълнителят трябва да изгради и да поддържа минимум следните логически разделени среди на собствена инфраструктура:
Среда
|
Описание |
Development |
чрез Development средата се осигурява работата по разработката, усъвършенстването и развитието на Системата. В тази среда са налични и допълнителните софтуерни системи и инсталации, необходими за управление на разработката – continuous integration средства, системи за автоматизирано тестване и др. |
Staging |
чрез Staging средата се извършват тестове преди разгръщане на нова версия от Development средата върху Production средата. В нея се извършват всички интеграционни тестове, както и тестовете за натоварване. |
Production |
това е средата, която е публично достъпна за реална експлоатация и интеграция със съответните външни системи и услуги. |
В случай че върху част от компонентите, нужни за компилация, има авторски права, те могат да бъдат или в отделно хранилище с подходящия за това лиценз или за тях трябва да бъде предоставен заместващ „mock up“ компонент, така че да не се нарушава компилацията на проекта.
Трябва да се анализират възможностите за включване на граждани в процесите по разработка, тестване и идентифициране на пропуски на софтуера. Участникът трябва да предложи механизъм и процедури за реализирането на такива процеси.
За всеки един разработван компонент Изпълнителят трябва да покрие следните изисквания за гарантиране на качеството на извършваната разработка и на крайния продукт:
Документиране на Системата в изходния код, минимум на ниво процедура/функция/клас;
Покритие на минимум 50% от изходния код с функционални тестове [в случай на надграждане на съществуваща система – 50% от новата функционалност и 20% от съществуващата];
Използване на continuous integration практики;
Използване на dependency management.
Участникът трябва да опише детайлно подхода си за покриване на изискванията.
Във всеки един компонент на Системата, който се build-ва и подготвя за инсталация (deployment), е необходимо да присъстват следните реквизити:
Дата и час на build;
Място/среда на build;
Потребител извършил/стартирал build процеса;
Идентификатор на ревизията от кодовото хранилище на компонента, срещу която се извършва build-ът.
Системата трябва да поддържа на приложно ниво "Rate Limiting" и/или "Throttling" на заявки от един и същ клиентски адрес както към страниците с уеб-съдържание, така и по отношение на заявките към приложните програмни интерфейси, достъпни публично или служебно като уеб-услуги (Web Services) и служебни интерфейси;
Системата трябва да позволява конфигуриране от страна на администраторите на лимитите за отделни страници, уеб-услуги и ресурси, които се достъпват с отделен URL/URI;
Системата трябва да поддържа възможност за конфигуриране на различни лимити за конкретни автентикирани потребители (напр. системи на други администрации) и трябва да предоставя възможност за генериране на справки и статистики за броя заявки по ресурси и услуги.
Уеб приложенията трябва да осигуряват висока производителност и минимално време за отговор на заявки - средното време за заявка трябва да бъде по-малко от 1 секунда, с максимум 1 секунда стандартно отклонение за 95% от заявките, без да се включва мрежовото времезакъснение (Network Latency) при транспорт на пакети между клиента и сървъра. Необходимо е да бъдат създадени тестове за натоварване.
С оглед намаляване на служебния трафик, времената за отговор и натоварването на сървърите следва да се използва HTTP/2 протокол при предоставяне на публични потребителски интерфейси с включени като минимум следните възможности:
Включена header compression;
Използване на brotli алгоритъм за компресия;
Включен HTTP pipelining;
HTTP/2 Server push, приоритизиращ специфични компоненти, изграждащи страниците (CSS, JavaScript файлове и др.).
Публичните потребителски интерфейси трябва да поддържат адаптивен избор на TLS cipher suites според вида на процесорната архитектура на клиентското устройство - AES-GCM за x86 работни станции и преносими компютри (с налични AES-NI CPU разширения) и ChaCha20/Poly1305за мобилни устройства (основно базирани на ARM процесори).
Ако клиентският браузър/клиент не поддържа HTTP/2, трябва да бъде предвиден fall-back механизъм към HTTP/1.1. Тази възможност трябва да може лесно да се реконфигурира в бъдеще и да отпадне, когато браузърите/клиентите, неподдържащи HTTP/2, станат незначителен процент.
Да бъде предвидено спазването на добри практики на софтуерната разработка – покритие на изходния код с тестове – над 60%, документиране на изходния код, използване на среда за непрекъсната интеграция (Continuous Integration), възможност за компилиране и пакетиране на продукта с една команда, възможност за инсталиране на нова версия на сървъра с една команда, система за управление на зависимостите (Dependency Management).
Публичните модули, които ще предоставят информация в Интернет, трябва да отговарят на актуалните уебстандарти за визуализиране на съдържание.
Не се допуска съхранението на пароли на администратори, на вътрешни и външни потребители и на акаунти за достъп на системи (ако такива се използват) в явен вид. Всички пароли трябва да бъдат защитени с подходящи сигурни алгоритми (напр. BCrypt, PBKDF2, scrypt (RFC 7914) за съхранение на пароли и където е възможно, да се използва и прозрачно криптиране на данните в СУБД със сертификати (transparent data-at-rest encryption).
Да бъде предвидена система за ежедневно създаване на резервни копия на данните, които да се съхраняват извън инфраструктурата на системата;
Всички уеб страници (вътрешни и публично достъпни в Интернет) трябва да бъдат достъпни единствено и само през протокол HTTPS. Криптирането трябва да се базира на сигурен сертификат с валидирана идентичност (Verified Identity), позволяващ задължително прилагане на TLS 1.2, който е издаден от удостоверителен орган, разпознаван от най-често използваните браузъри (Microsoft Internet Explorer, Google Chorme, Mozilla Firefox). Ежегодното преиздаване и подновяване на сертификата трябва да бъде включено като разходи и дейности в гаранционната поддръжка за целия срок на поддръжката.
Трябва да бъдат извършени тестове за сигурност на всички уеб страници, като минимум чрез автоматизираните средства на SSL Labs за изпитване на сървърна сигурност (https://www.ssllabs.com/ssltest/).
Като временна мярка за съвместимост настройките на уеб сървърите и Reverse Proxy сървърите трябва да бъдат балансирани така, че приложенията да позволяват използване и на клиентски браузъри, поддържащи по-стария протокол TLS 1.1. Това изключение от общите изисквания за информационна сигурност не се прилага за достъпа на служебни потребители от държавната администрация,услуги, които имат служебен достъп до ресурси на приложенията.
При разгръщането на всички уеб услуги (Web Services) трябва да се използва единствено протокол HTTPS със задължително прилагане на минимум TLS 1.2.
Програмният код трябва да включва методи за автоматична санитизация на въвежданите данни и потребителски действия за защита от злонамерени атаки, като минимум SQL инжекции, XSS атаки и други познати методи за атаки, и да отговаря, където е необходимо, на Наредбата за оперативна съвместимост и информационна сигурност.
При проектирането и разработката на уеб приложенията и интерфейсите и при подготовката и разгръщането на средите трябва да се спазват последните актуални препоръки на OWASP (Open Web Application Security Project).
Трябва да бъде изграден модул за проследимост на действия и събития в надградената АИС за инвентаризация на ИКИ ресурсите. За всяко действие (добавяне, изтриване, модификация, четене) трябва да съдържа следните атрибути:
Уникален номер;
Точно време на възникване на събитието;
Вид (номенклатура от идентификатори за вид събитие);
Данни за информационна система, където е възникнало събитието;
Име или идентификатор на компонент в информационната система, регистрирал събитието;
Приоритет;
Описание на събитието;
Данни за събитието.
Астрономическото време за удостоверяване настъпването на факти с правно или техническо значение се отчита с точност до година, дата, час, минута, секунда и при технологична необходимост - милисекунда, изписани в съответствие със стандарта БДС ISO 8601:2006.
Астрономическото време за удостоверяване настъпването на факти с правно значение и на такива, за които се изисква противопоставимост, трябва да бъде удостоверявано с електронен времеви печат по смисъла на Глава III, Раздел 6 от Регламент ЕС 910/2014. Трябва да бъде реализирана функционалност за получаване на точно астрономическо време, отговарящо на горните условия, и от доставчик на доверителни услуги или от държавен орган, осигуряващ такава услуга, отговаряща на изискванията на RFC 3161;
Трябва да бъдат проведени тестове за проникване (penetration tests), с които да се идентифицират и коригират слаби места в сигурността.
При проектирането и разработката на софтуерните компоненти и потребителските интерфейси трябва да се спазват стандартите за достъпност на потребителския интерфейс за хора с увреждания WCAG 2.0, съответстващ на ISO/IEC 40500:2012.
Всички ресурси трябва да са достъпни чрез GET заявка на уникален адрес (URL). Не се допуска използване на POST за достигане при генериране на справка и други.
Функционалностите на потребителския интерфейс на Системата трябва да бъдат независими от използваните от потребителите интернет браузъри и устройства, при условие че последните са версии в период на поддръжка от съответните производители. Трябва да бъде осигурена възможност за ползване на публичните модули на приложимите услуги през мобилни устройства – таблети и смарт-телефони, чрез оптимизация на потребителските интерфейси за мобилни устройства (Responsive Design).
Не се допуска използване на капча (Captcha) като механизъм за ограничаване на достъпа до документи и/или услуги. Допуска се използването на Captcha единствено при идентифицирани много последователни опити от предполагаем „бот“.
Публично достъпната информация, касаеща структурирани данни през уеб портал, трябва да бъдат проектирана и оптимизирана за ефективно и бързо индексиране от търсещи машини с цел популяризиране сред потребителите и по-добра откриваемост при търсене по ключови думи и фрази. При разработката на уеб приложенията и при изготвяне на автоматизираните процедури за разгръщане на нова версия на АИС на инвентаризация на ИКИ ресурсите трябва да се използват инструменти за минимизиране и оптимизация на размера на изходния код (HTML, JavaScript и пр.) с оглед намаляване обема на файловете и по-бързо зареждане на страниците.
Не се допуска използването на HTML Frames, за да не се пречи на оптимизациите за търсещи машини;
При разработката на публични уеб базирани страници трябва да се използват и да се реализира поддръжка на:
Стандартните семантични елементи на HTML5 (HTML Semantic Elements);
JSON-LD 1.0 (http://www.w3.org/TR/json-ld/);
Open Graph Protocol (http://ogp.me) за осигуряване на поддръжка за качествено споделяне на ресурси в социални мрежи и мобилни приложения.
В екранните форми на уеб приложенията трябва да се използват потребителски бутони с унифициран размер и лесни за разбиране текстове в еднакъв стил.
Всички текстови елементи от потребителския интерфейс трябва да бъдат визуализирани с шрифтове, които са подходящи за изобразяване на екран и които осигуряват максимална съвместимост и еднакво възпроизвеждане под различни клиентски операционни системи и браузъри. Не се допуска използването на серифни шрифтове (Serif).
Полета, опции от менюта и командни бутони, които не са разрешени конкретно за ролята на влезлия в приложението потребител, не трябва да са достъпни за този потребител. Това не отменя необходимостта от ограничаване на достъпа до бизнес логиката на приложението чрез декларативен или програмен подход.
Всяка екранна форма трябва да има наименование, което да се изписва в горната част на екранната форма. Наименованията трябва да подсказват на потребителя какво е предназначението на формата.
Всички търсения трябва да са нечувствителни към малки и главни букви;
Полетата за пароли трябва задължително да различават малки и главни букви.
Полетата за потребителски имена трябва да позволяват използване на имейл адреси като потребителско име, включително да допускат всички символи, регламентирани в RFC 1123, за наименуването на хостове.
Главните и малките букви на въвежданите данни се запазват непроменени, не се допуска Приложението да променя капитализацията на данните, въвеждани от потребителите.
Уеб приложението трябва да позволява въвеждане на данни, съдържащи както на български език, така и английски език.
Наименованията на полетата следва да са достатъчно описателни, като максимално се доближават до характера на съдържащите се в тях данни.
Приложението трябва да поддържа прекъсване на потребителски сесии при липса на активност. Времето трябва да може да се променя от администратора на приложението без промяна в изходния код. Настройките за време за прекъсване на неактивни сесии трябва да включват и възможността администраторите да дефинират стилизирана страница с информативно съобщение, към която Приложението да пренасочва автоматично браузърите на потребителите в случай на прекъсната сесия.
Дългите списъци с резултати трябва да се разделят на номерирани страници с подходящи навигационни елементи за преминаване към предишна, следваща, първа и последна страница, към конкретна страница. Навигационните елементи трябва да са логически обособени и свързани със съответния списък и да се визуализират в началото и в края на HTML контейнера, съдържащ списъка.
За големите йерархически категоризации трябва да се предвиди възможност за навигация по нива или чрез отложено зареждане (lazy load).
Приложението трябва да може да съхранява и едновременно да визуализира данни и съдържание, което е въведено/генерирано на различни езици.
Всички софтуерни приложения и използваните софтуерни библиотеки и развойни комплекти, приложните сървъри и сървърите за управление на бази данни, елементите от потребителския интерфейс, програмно-приложните интерфейси, уеб услугите и др. трябва да поддържат стандартно и да са конфигурирани изрично за спазване на минимум Unicode 5.2 стандарт при съхранението и обработката на текстови данни, съответно трябва да се използва само UTF-8 кодиране на текстовите данни;
Всички публично достъпни потребителски интерфейси следва да поддържат многоезичност, като минимум български и английски език;
Публичната част на Приложението трябва да бъде разработена и да включва набори с текстове на минимум два официални езика в ЕС, а именно български и английски език. Преводите на английски език трябва да бъдат осъществени професионално, като не се допуска използването на средства за машинен превод без ръчна проверка и корекции от професионални преводачи.;
Версиите на съдържанието на съответните езици трябва да включват всички текстове, които се визуализират във всички елементи на потребителския интерфейс, справките, генерираните от системата електронни документи, съобщения, нотификации, имейл съобщения, номенклатурите и таксономиите и др. Данните, които се съхраняват в Приложението само на български език, се изписват/визуализират на български език.;
При визуализация на числа трябва да се използва разделител за хиляди (интервал);
При визуализация на дати и точно време в елементи от потребителския интерфейс в генерирани справки или в електронни документи всички формати за дата и час трябва да са съобразени с избрания от потребителя език/локация в настройките на неговия профил:
За България стандартният формат е „DD.MM.YYYY HH:MM:SS”, като наличието на време към датата е в зависимост от вида на визуализираната информация и бизнес-смисъла от показването на точно време;
Приложението трябва да поддържа и всички формати съгласно ISO БДС 8601:2006.
При надграждането на АИС за инвентаризация на ИКИ ресурсите трябва да се гарантира, че въведените, валидираните и запазените от сървъра данни остават достъпни за потребителите дори за процеси, които не са приключили, така че при волно, неволно или автоматично прекъсване на потребителската сесия поради изтичане на периода за допустима липса на активност потребителят да може да продължи съответния процес след повторно влизане в системата, без да загуби въведените до момента данни и прикачените до момента електронни документи.
Трябва да бъде реализирана възможност за добавяне и редактиране от страна на администраторите на Приложението, без да са необходими промени в изходния код, на контекстна помощна информация за:
всяка електронна форма или стъпка от процес, за която има отделен екран/форма;
всяка група полета за въвеждане на данни (в случаите, в които определени полета от формата са групирани тематично);
всяко отделно поле за въвеждане на данни;
Трябва да бъде разработена контекстна помощна информация за всички процеси, екрани и електронни форми, включително ясни указания за попълване и разяснения за особеностите при попълване на различните групи полета или на отделни полета.
Контекстната помощна информация, указанията към потребителите и информативните текстове за всяка електронна административна услуга не трябва да съдържат акроними, имена и референции към нормативни документи, които са въведени като обикновен текст (plain-text). Всички акроними, референции към нормативни документи, формуляри, изисквания и др. трябва да бъдат разработени като хипервръзки към съответните актуални версии на нормативни документи и/или към съответния речник/списък с акроними и термини.
Достъпът на потребителя до контекстната помощна информация трябва да бъде реализиран по унифициран и консистентен начин чрез подходящи навигационни елементи, като например чрез подходящо разположени микро-бутони с икони, разположени до/пред/след етикета на съответния елемент, за който се отнася контекстната помощ, или чрез обработка на "Mouse Hover/Mouse Over" събития;
При проектирането и реализацията на потребителския интерфейс трябва да се отчете, че той трябва да бъде еднакво използваем и от мобилни устройства (напр. таблети), които не разполагат с мишка, но имат чувствителни на допир екрани.
Изгражданото решение за уеб приложението, реализиращо регистъра на информационните ресурси, задължително трябва да осигурява проследимост на действията на всеки потребител (одит), както и версия на предишното състояние на данните, които той е променил в резултат на своите действия (системен журнал).
Атрибутите, които трябва да се запазват при всеки запис, трябва да включват като минимум следните данни:
дата/час на действието;
модул на системата, в който се извършва действието;
действие;
обект, над който е извършено действието;
допълнителна информация;
IP адрес и браузър на потребителя.
Размерът на журнала на потребителските действия нараства по време на работа на всяка система, което налага по-различното му третиране от гледна точка на организация на базата данни:
по време на работа на приложението потребителският журнал трябва да се записва в специализиран компонент, който поддържа много бързо добавяне на записи; този подход се налага, за да не се забавя излишно работата на Приложението;
специална фонова задача трябва да акумулира записаните данни и да ги организира в отделна специално предвидена за целта база данни, отделна от работната база данни на приложението;
данните в специализираната база данни трябва да се архивират и изчистват, като в специализираната база данни трябва да бъде достъпна информация за не повече от 2 месеца назад; при необходимост от информация за предишен период администраторът на приложението трябва първо да възстанови архивните данни.
Дейността се състои от следните поддейности (етапи):
В рамките на тази дейност ще бъде надградена и внедрена вече изградената от МП АИС за инвентаризация на ИКИ ресурсите. Същата трябва да бъде интегрирана с Интегрираната информационна система на държавната администрация (наименование и организационна структура, адреси на които оперират и др.), Портала за мрежова и информационна сигурност (https://govcert.bg/) и Портала за отворени данни за предоставяне на данни чрез автоматизиран интерфейс. В рамките на тази дейност е необходимо да се извърши интеграция на приложението с модул е-автентификация, разработен за нуждите на електронното управление. Срокът за изпълнение на тази поддейност е до 1 месец след сключване на договора.
Изградената система, освен посочените по-долу изисквания, следва да покрива и изискванията на чл. 58а от Закона за електронното управление /ЗЕУ/ и другите относими нормативни актове /законови и подзаконови/.
Основно изискване ще бъде поддръжката на функционалност за съхранението и управлението на всички данни, включени в Методиката за инвентаризация на ИКИ, която ще му бъде предоставена от Възложителя, относно ресурсите на централните и местни администрации и генерирането на справки и отчети с възможни различни разрези на данните. Друго специфично изискване към приложението ще бъде поддържането на версии и дневник на промените.
Не по-късно от 2 месеца след сключване на договора с избрания изпълнител, същият следва да осигури онлайн достъп до приложението (или до функциониращ модул от него), в който да е възможно да бъдат вписвани онлайн резултатите от проведената инвентаризация по места.
Всички права върху продуктите, предмет на допълнителна доработка и надграждане на дадено приложение от съществуващата ИС за нуждите на МП и изходният код, който не е отворен код, преминават като собственост на Възложителя.
Екипът на Изпълнителя следва да предприеме в процеса на изграждане на тестовата среда на АИС на ИКИ ресурсите, инсталирането й върху собствената си инфраструктура и да извърши конфигуриране на всички потребителски профили за всяка една администрация по зададен списък.
Екипът на изпълнителя да уточни по възможност детайлите за формат и версии на виртуализационния софтуер, който ще бъде използван като същия трябва да предложи за използване следната информация:
тип диск (IDE, SCISI);
генерация на виртуалната машина;
версията на хост операционната система;
версия на Hyper-V или друг подобен;
Конфигуриране на hostname и IP, такива каквито ще се ползват за нуждите на тестовата среда;
Конфигуриране на портовете на приложението за да отговарят на рестрикциите на firewall;
Експорт на виртуални машина (формат Hyper-V или друг такъв) за стартиране върху виртуализационен софтуер:
Лиценз за GraphDB;
Инсталиран софтуер;
Заредени конфигурации;
Създадени потребителски акаунти;
Тенант за тестова среда.
Импортиране на виртуалните машини в средата на изпълнителя;
Конфигуриране на мрежовия адаптер за работа в мрежата на Изпълнителя;
Конфигуриране на firewalls;
Тестване на hostname и IP, такива каквито ще се ползват на тестовата среда.
Препоръчително е използването на https, за което е необходим валиден SSL сертификат.
Изпълнителят ще трябва да изгради уеб базиран електронен регистър в срок от 2 месеца след сключване на договора. Той ще надгражда АИС за инвентаризация на ИКИ ресурсите, разработена за нуждите на МП.
Регистърът ще трябва да съдържа информация за:
информационните ресурси, с които разполагат административните органи (хардуер; мрежово оборудване; софтуер, вкл. лицензи; др.), включително придобити по проекти, финансирани от ЕСИФ или от други финансови източници, с изключение на тези, чието предназначение е за работа и съхранение на класифицирана информация;
информационните ресурси на Единната електронна съобщителна мрежа (ЕЕСМ) на държавната администрация и за нуждите на националната сигурност;
годишни планове за обновяване на информационните ресурси на администрациите, индикативните стойности и сроковете, в които да бъдат реализирани.
Вписването и заличаването на данни трябва да се извършва чрез уеб базиран потребителски програмен интерфейс за взаимодействие система-система. Регистърът ще послужи за реализация на механизма за планиране на информационните ресурси, описан в чл. 7ж от ЗЕУ. Данните от него ще се използват за изготвянето на отчета за състоянието и годишния план за развитието и обновяването на информационните ресурси в администрацията и информационните ресурси на ЕЕСМ, който ще се одобрява ежегодно от МС.
Описание на последователността от необходими действия:
Изготвяне на системен проект
Изпълнителят трябва да изготви системен проект, който подлежи на одобрение от Възложителя. В системния проект трябва да са описани всички изисквания за реализирането на Регистъра на информационните ресурси, използвайки като основа разработената АИС за инвентаризация на ИКИ ресурсите за нуждите на МП, всички изисквания за изграждане на програмен интерфейс към ИИСДА, всички изисквания за програмен интерфейс към отворения портал за данни съгласно ЗДОИ и всички изисквания за програмен интерфейс за интеграция на системата с модул е-автентификация. Изготвянето на системния проект включва следните основни задачи:
Определяне на концепция за разработка на Регистъра на информационните ресурси на базата на съществуваща информация в СУБД на АИС на ИКТ ресурсите;
Дизайн на Регистъра на информационните ресурси;
Изготвяне на план за техническа реализация;
Определяне на потребителския интерфейс.
Определяне на концепция за разработка на приложния програмен интерфейс за връзка с ИИСДА;
Определяне на концепция за разработка на приложния програмен интерфейс за интеграция с модул е-автентификация;
Определяне на концепция за разработка на приложния програмен интерфейс за връзка с Портала за отворени данни;
Определяне на концепция за разработка на автоматизиран онлайн обмен на данни между изграждания Регистър на информационни активи и Портала за мрежова и информационна сигурност (https://govcert.bg/) чрез идентификация на информационните активи съгласно National Institute of Standards and Technology (NIST) - Common Platform Enumeration (СРЕ) (https://scap.nist.gov/specifications/cpe/).
Изпълнението на задачите изисква, модели на стандартни справки и анализи, политика за сигурност и защита на данните, технология на взаимодействие, спецификация на номенклатурите, роли в разработката и други. При документирането на изискванията, с цел постигане на яснота и стандартизация на документите, е необходимо да се използва стандартен език за описание на бизнес процеси – BPMN. Системният проект подлежи на одобрение от Възложителя. В случай на забележки, корекции или допълнения от страна на Възложителя, Изпълнителят е длъжен да ги отрази в системния проект в срок не по-късно от 10 работни дни.
Разработване на софтуерното решение
Разработката на софтуерното решение включва изпълнението на следните задачи:
Разработка на приложението за регистъра за информационните ресурси и служебните програмни интерфейси на информационната система за инвентаризация на ИКТ ресурсите на администрацията за връзка с ИИСДА, портала за отворени данни, интеграция на системата с модул е-автентификация съгласно изискванията и модула за онлайн обмен на данни между изграждания Регистър на информационни активи и Портала за мрежова и информационна сигурност (https://govcert.bg/) чрез идентификация на информационните активи съгласно National Institute of Standards and Technology (NIST) - Common Platform Enumeration (СРЕ) (https://scap.nist.gov/specifications/cpe/).;
Провеждане на вътрешни тестове на разработените по-горе приложения и интерфейси (в среда на разработчика).
Представянето на софтуерното приложение и потребителските интерфейси включва описание и документация на изходния код на системата и самия изходен код на технически носител, като се съпровожда от документ за извършено тестване и контрол на качеството за всички компоненти на софтуера по вътрешните правила на Изпълнителя.
За изпълнение на дейностите по разработка на приложенията, надграждащи АИС на ИКТ ресурсите, участниците в настоящата обществена поръчка трябва да опишат в своите технически предложения приложим подход (методология) за софтуерна разработка, която ще използват, както и инструментите за разработка и средата за провеждане на вътрешните тестове. Участниците трябва да опишат как предложеният от тях подход ще бъде адаптиран за успешната реализация на софтуерните приложения.
Тестване
След завършване на разработката на софтуерното решение се извършва тестване от представители на Възложителя на разработената система в необходимия брой итерации (повторения).
Изпълнителят има задължението да извърши инсталация на системата и всички необходими настройки за експлоатацията й в тестова среда.
Тестването се извършва от представители на Възложителя в присъствието на експерти на Изпълнителя, в тестовата среда на Възложителя и по предварително уговорен между Възложителя и Изпълнителя график.
Изпълнителят подготвя Спецификация за тестване и тестови сценарии, обхващащи цялостно общите изисквания към системата и функционалността на системата - логически обособените й части и модули и интеграцията помежду им, включително заредени данни в АИС на ИКИ ресурсите и връзка с ИИСДА и други - така, че с успешното им изпълнение максимално да се гарантира работоспособността на системата. Тестовите сценарии не ограничават експертите на Възложителя за тестване на всеки елемент от функционалността.
Всяка итерация на тестването следва да приключи с протокол, който да съдържа обхвата на теста (тестови сценарии), резултатите от тестването и забележките на Възложителя. Броят итерации на тестването се определя от удовлетвореността на Възложителя от реализацията на системата на база изпълнението на дефинираните изисквания на Възложителя.
Последна итерация е приемателното тестване, при което се отчита изпълнението на дефинираните изисквания на Възложителя, съдържащи се в техническите спецификации, съответствието на реализацията с функционалната и техническата спецификации, както и представянето на приложенията при големи натоварвания.
Участникът, избран за Изпълнител, предоставя на Възложителя надлежно документиран изходен код на служебните програмни интерфейси с ИИСДА, модул е-автентификация и портала за отворени данни, модул за онлайн обмен на данни между изграждания Регистър на информационните активи и Портала за мрежова и информационна сигурност (https://govcert.bg/) чрез идентификация на информационните активи съгласно National Institute of Standards and Technology (NIST) - Common Platform Enumeration (СРЕ) (https://scap.nist.gov/specifications/cpe/), както и приложението за реализиране на функционалността на регистъра на информационните ресурси, актуализиран след последната итерация от тестването, както и други такива, които са разработени в процеса на изпълнение на проекта за постигане на описаните функционалности.
Изпълнителят трябва да внедри софтуерното решение в информационната и комуникационна среда на Възложителя. Това включва инсталиране, конфигуриране и настройка на програмните компоненти на системата в условията на виртуализирана продукционна среда.
За всяка промяна в приложенията екипът на Изпълнителя ще предоставя билд с нова подверсия, пач и т.н. в електронен формат, който ще е придружен от следните документи:
• Описание на направените промени (release notes);
• Документ (release content), съдържащ номерата и кратко описание на проблемите или възложеното актуализиране, които влизат в билда, както и кои модули на приложния слой на ИС са засегнати от промените;
• Инструкция за инсталация, описваща последователността от действия по инсталиране на предоставения билд;
• Преди внедряване на промяна в програмните интерфейси и свързания с него Регистър на информационните ресурси, екипът на Изпълнителя следва да представи пред представители на Възложителя направените промени в софтуерното решение на ниво програмен изходен код и база данни за наличие на неоптимизиран, зловреден или злонамерен код.
За всеки билд (и за тестова и за реална среда) на определен служител от екипа на ДАЕУ се предоставя протокол на хартиен носител в два екземпляра (по един за Изпълнител и Възложителя) придружен от носител на информация - CD/DVD съдържащ промените.
Изпълнителят трябва да разработи процедура за поддържане на информацията в регистъра в актуално състояние от страна на администрациите, чрез създаване на потребителски профили на всеки координатор от всяка администрация.
Същият трябва да разработи онлайн ръководство за работа с регистъра, предназначено за администраторите на профили в регистъра (служителите, определени от всеки административен орган по реда на чл. 7 е), ал. 3 от ЗЕУ, които да подават информацията към регистъра по ред, установен с приложимата подзаконова нормативна уредба.
На този етап следва да бъдат обучени 140 лица, предложени от Възложителя по списък. Обучението да бъде петдневно, разделено в 3 панела, както следва:
Панел „Операционни системи“ - 1 ден;
Панел „Информационни системи“ - 1 ден;
Панел „Работа с АИС за инвентаризация на ИКИ ресурсите и запознаване с Регистъра на информационните ресурси“ - 3 дни.
В интерес на процеса на обучение Изпълнителят трябва да осигури:
програма за обучение;
лектори;
места за обучение с необходимата техника за провеждане на обучението.
Изпълнителят трябва да осигури за обучаемите в гр. София или градове извън София: нощувка в хотел минимум 3*, изхранване за дните на обучението, включващо закуска, обяд, вечеря, кафе-паузи, обучителни материали, техника, транспорт.
Обучението се извършва по план, предложен от Изпълнителя и съгласуван от Възложителя и трябва да приключи в рамките на 1 месец.
По поддейност 7.1.1.1.
Надградена и въведена информационна система за одит на ИКИ ресурсите на централната, областната и общинската администрация, интегрирана към ИИСДА, Портала за отворени данни и Портала за мрежова и информационна сигурност (https://govcert.bg/) и модул е-автентификация, разработен за нуждите на електронното управление;
Разработено онлайн ръководство за работа с АИС;
По поддейност 7.1.1.2.
- Разработено и внедрено приложение, реализиращо регистър на информационните ресурси на основата на данните, обработени в АИС за инвентаризация на ИКИ ресурсите;
- Разработена процедура за пoдържане на регистъра в актуално състояние;
- Разработено онлайн ръководство за работа с регистъра на информационните ресурси;
По поддейност 7.1.1.3
Обучени 140 служители от ДАЕУ в 3 панела за провеждане на инвентаризацията, работа с информационната система и Регистъра на информационните ресурси.
Дейността следва да обхване централните, областните и общинските администрации, с изключение на администрациите от сектор „Правосъдие“, съгласно Приложение 1. Дейността ще се изпълнява съвместно от Възложителя и избрания Изпълнител като срокът й за изпълнение е 6 месеца от сключване на договора.
В процеса на прегледа ще бъде събрана в структуриран вид подробна информация за ИКИ, информационните системи, услуги и свързаните с тях процеси, както следва:
Обхват 1 - Наличните технически помещения, в които са разположени ИКТ активи и тяхната обезпеченост по отношение на физическа сигурност, резервно и аварийно електрозахранване, климатизация, безопасност и пр.:
Общи данни за локация /сграда/:
Адресна и географска информация за локацията - точен адрес, лице за контакт, данни за контакт и други, GPS координати и др.;
Структури, които се помещават в сградата;
Административна структура, стопанисваща сградата;
Параметри на сградата;
Списък с помещенията, в които има ИКТ инфраструктура:
Тип на помещението - обикновена стая или обособено техническо помещение;
Административна структура, стопанисваща помещението;
Местоположение на помещението - етаж, стая, обозначения;
Обща скица на всяко помещение с означаване на разположеното оборудване (случаите, в които има специализирано такова);
Информация за контрол на достъпа - как се контролира достъпа, има ли налична система за автоматизиран контрол на достъпа;
Информация за електрозахранването - захранване от дизел-генератор, UPS-и пр.;
Климатизация - наличие, тип, брой, модел;
Обхват 2 - Наличните ИКТ активи - компютри и периферия, сървъри, системи за съхранение на и архивиране на данни, комуникационно оборудване и пр.:
ИКИ шкафове
Наличие, тип, брой, големина, свободно място;
Скица на разположението вътре в комуникационния шкаф;
Описание на връзките вътре в комуникационния шкаф, ако е възможно;
Начин на захранване на комуникационния шкаф;
Снимков материал - обща снимка на всеки шкаф отпред и отзад;
Цена на придобиване.
Активно мрежово оборудване
Наличие на маршрутизатори, комутатори, защитни стени и други мрежови устройства като за всяко устройство се събира информация за:
Производител и модел;
Продуктов номер;
Сериен номер;
Дата на закупуване;
Цена на придобиване;
Гаранция / дата на изтичане на гаранцията;
Захранване (брой и тип);
Брой инсталирани портове по типове;
Брой активни портове по типове (портове, за които има активен лиценз);
Брой свободни портове по типове;
Снимков материал - за всяко устройство отпред и отзад.
Сървъри
Налични сървъри и персонални компютри, които играят ролята на сървъри, като за всяко устройство се изисква информация за:
Тип /сървър или ПК; реален или виртуален/;
Тип на шаси и размер;
CPU (количество, работна честота);
Оперативна памет (капацитет);
Дисково пространство (капацитет);
Осигурена наличност на средства за съхранение на данни (RAID);
Производител и модел;
Продуктов номер;
Сериен номер;
Дата на закупуване;
Цена на придобиване;
Гаранция / дата на изтичане на гаранцията;
Захранване (брой и тип);
Брой инсталирани портове по типове;
Брой свободни портове по типове;
Брой и вид разширителни слотове (брой заети и свободни, на заетите - вид и модел на инсталираните в тях разширителни карти (платки);
Наличие на визуални и звукови аларми и какви са те;
Наличие на лентови устройства и библиотеки - типове, брой касети и глави;
Хипервайзор, който се използва;
Операционна система;
Приложен софтуер;
ИТ услуги, които се предоставят чрез сървъра;
Други параметри.
Дискови масиви за съхранение на данни
Налични устройства за съхранение на данни и сървъри или работни станции, които играят ролята на устройства за съхранение на данни, като за всяко устройство се изисква информация за:
Тип / Специализирано устройство или сървър или персонален компютър /;
Тип на шаси и размер;
Дисково пространство (raw space);
Брой и параметри на използваните дискове;
Максимален капацитет за дискове;
Използвани RAID групи;
Сформирани пулове от дискове;
Количество контролери;
Производител и модел;
Продуктов номер;
Сериен номер;
Дата на закупуване;
Гаранция / дата на изтичане на гаранцията;
Цена на придобиване;
Захранване (брой и тип);
Брой инсталирани портове по типове;
Брой свободни портове по типове;
Колко и какви карти и платки;
Използване на синхронен и асинхронен обмен на данни - наличност или възможност;
Наличие на визуални и звукови аларми и какви са те;
Наличие на лентови устройства и библиотеки - типове, брой касети и глави;
Други параметри.
Възможности за гарантиране на високо ниво на надеждност и отказоустойчивост на наличните ИТ услуги чрез:
Наличие на огледални центрове;
Наличие на Data Recovery центрове;
Наличие на средства за архивиране;
Наличие на процедури за възстановяване при частична или пълна загуба на ИТ услуга.
Софтуерни лицензи
Опис на закупените / наличните лицензи за системен и приложен софтуер - продуктови номера (различни от активационни, лицензионни или продуктов ID номер) и наименования, количество от вид, договор и цена на придобиване, дата на закупуване, дата до която има валидна поддръжка и права за ползване на нови версии;
Инфраструктура
Описание на Активна директория;
Описание на базови и разширени ИТ услуги;
Описание на средства за обновяване, наблюдение и превантивен контрол;
Описани на вътрешни правила, процедури, политики, конвенции и др.;
Описани на средства за гарантиране на високо ниво на отказоустойчивост;
Описание на средства за виртуализация.
Работни станции
Производител и модел, там, където е приложимо;
Продуктов номер, там, където е приложимо;
Сериен номер, там, където е приложимо;
Дата на закупуване;
Гаранция / дата на изтичане на гаранцията;
Цена на придобиване;
Процесор - вид и тактова честота;
Оперативна памет;
Твърд диск - вид и обем;
Графична карта;
Захранване;
Монитор - вид, размер, разделителна способност;
Операционна система;
Приложен софтуер.
Входни и изходни периферни устройства (принтери, скенери, факсове, уеб камери, IP телефони и др.)
Вид периферно устройство;
Производител и модел;
Продуктов номер;
Сериен номер;
Дата на закупуване;
Гаранция / дата на изтичане на гаранцията;
Цена на придобиване.
Архитектура и производителност на ИКИ
Архитектура на комуникационната инфраструктура;
Капацитет на мрежовите връзки (пропускателна способност).
Топология на мрежата
Описание и диаграма/и на текущото състояние - пасивно и активно оборудване;
Устройствата, които трябва да бъдат включени са пасивно оборудване, рутери, суичове, WiFi точки за достъп, сървъри, защитни стени и други устройства.
WiFi мрежи
Хардуер;
Софтуер за управление;
Идентификация за всяка мрежа;
Сигурност на мрежата (IEEE802.1x);
Контролери за управление;
Топологията на мрежата.
Налична комуникационна инфраструктура
WAN/Internet - устройства, доставчик на интернет, доставчик на WAN свързаността, Firewall и др.;
Рутери;
Суичове;
VPN сървър;
WiFi точки за достъп;
IP телефония;
Структурни кабелни системи.
Налична домейн инфраструктура
Имена на домейн контролери;
Дублираност на домейн контролери;
Видове домейн контролери - Master/Slave.
Обхват 3 - Наличните информационни ресурси - информационни системи, база данни. Като минимум за всеки един информационен масив задължително следва да бъде описана в детайл следната информация:
Вид - база данни, информационна система и др.;
Наименование;
Описание на съдържаната информация;
Нормативно основания за събиране и обработване на данните;
Отговорни служители за вписване/поддържане/администриране на информацията, включително вътрешни правила/документи и др., заповеди за определяне на отговорните служители и др.;
Наличие/липса на метаданни за информацията и описание на метаданните;
Формат на данните;
Структура на данните - структурирани, неструктурирани, полу-структурирани, с конкретното описание;
Локация на данните - външен сървър/хостинг, вътрешноведомствен сървър, локален компютър, диск, хартиен носител и т.н.;
Достъп - служебен, свободен, свободен онлайн достъп до данните - интернет адрес;
Статус на данните - дали се обновяват, ако „да“ - по какъв начин - ръчно, автоматизирано или и по двата начина, на какъв период (автоматично при вписване на обстоятелство, ежедневно, седмично, месечно, тримесечно, годишно, по-рядко), кой отговаря за обновяването, възможност за автоматично обновяване, съдържат ли се лични данни (да, не, частично) и какъв вид, нормативно основание за тяхното събиране и обработка;
Възможност за служебен обмен на данни - автоматизиран достъп до данни чрез административни информационни системи, периодично изпращане на данни по електронна поща, писмена кореспонденция с обмен на хартиени документи, предоставяне на достъп до данни чрез потребителско име и парола, репликиране на данни, служебно събиране на данни чрез писмена кореспонденция с обмен на хартиени документи, и др. включително какъв обем и с каква периодичност се извършва и случаите, в които не се предоставя служебен обмен на данни;
Наличие на техническа възможност за автоматизиран обмен на данните;
Брой на администрациите, на които е осигурен достъп до данните;
Начална дата на поддържане на информационния ресурс;
Данни за контакт - лица за контакт, длъжност, служебен телефон, мобилен телефон, електронна поща;
Права върху информационния ресурс.
Обхват 4 - Наличния квалифициран персонал за опериране, управление и поддръжка на информационните ресурси:
Поименни списъци с длъжности и квалификация на персонала (вкл. граждански договори), зает с поддръжката на техническа инфраструктура, ИКТ активи, информационни системи и пр.;
Налични правила и процедури за ползаване на ИТ ресурси, правила и процедури за информационна сигурност, ниво на оперативна съвместимост на информационните ресурси.
Обхват 5 - Наличните договори за външни услуги за техническа поддръжка, комуникационна свързаност, разработка и/или внедряване на информационни системи и др.
Доставчици на телекомуникационни услуги:
Събиране на обща информация за наличие, брой, оператор, тип на услугата и начин на реализация (оптика, мед, медия конвертор и други пасивни и/или активни компоненти използвани за връзка към оператора);
Договори за доставка на услугата, наличие на SLA с конкретни параметри и др.
Доставчици на външни ИТ услуги като:
Договори и SLA във връзка с решения за IT сигурност - single-sign-on, PKI;
Договори и SLA за поддръжка на ИКИ инфраструктура (mail server, active directory, domain controller);
Договори за разработка/поддръжка на софтуер и/или информационни системи;
Договори за наемане на помещения/ресурси под наем (ко-локация, хостинг, облачни услуги и пр.);
Други договори ако са налични ИТ услуги.
В рамките на дейността ще бъдат инвентаризирани чрез посещение на място от Изпълнителя 576 администрации в не по-малко от 2 004 локации, като от него се очаква и изготвянето на 4 вида анализи на постъпващите от инвентаризацията данни. Бройката от 2 004 локации са тези с уточнено местоположение от общински, областни и централни администрации според справката в Интегрираната информационна система на държавната администрация (ИИСДА). Изпълнителят следва да инвентаризира администрациите и локациите, посочени под формата на списък в Приложение 1 към настоящата документация. Всички оставащи локации, които бъдат идентифицирани в хода на работата по проекта, и които надхвърлят бройката от 2 004 могат да бъдат инвентаризирани или чрез физическо посещение, или чрез алтернативни методи, като например: чрез анкетиране, възможности за самооценка от администрациите и други.
Избраният външен изпълнител следва да:
координира работата на всички екипи от свои експерти;
докладва на четиримата регионални координатори от ДАЕУ, които са в екипа за управление на проекта;
извършва текущ анализ и отправя препоръки на база постъпващите от инвентаризацията данни;
Използвайки възможностите на АИС за инвентаризация на ИКИ ресурсите Изпълнителят трябва да може да извърши дистанционен одит на всички инфраструктурни компоненти от една централна локация (т.е. без инсталация на допълнителен софтуер, или агенти, по инфраструктурните компоненти).
За всички данни събирането ще се осъществява в цитираната среда.
Експерти от Държавна агенция „Електронно управление“ на регионално ниво ще оказват организационно съдействие на избрания изпълнител.
От избрания изпълнител ще бъде изискано създаването на контактен център 24/7 за периода на извършване на инвентаризацията - телефон и общ e-mail адрес, достъпни, както за администрациите, така и за екипите, които ще извършват инвентаризацията. Осигуряване на не по-малко от двама едновременно дежурни служители от 6:00 до 22:00 часа, всеки работен ден, за срока на проекта, които да извършват координация и обслужване на контактния център.
За локации/звена с ограничения в режима на достъп, при възможност, инвентаризацията ще се извършва посредством предоставяне на данни от съответната администрация.
В зависимост от спецификата на конкретни звена/локации, при който се извършва инвентаризация, е възможно част от дейностите да се проведат извън работното време с оглед осигуряването на непрекъсваемост на дейностите и осигуряване на работоспособността на системите.
Въз основа на извършената инвентаризация изпълнителят следва да представи на Възложителя следните анализи:
• Анализ на наличния и използвания капацитет на инфраструктурата;
• Анализ на осигуряването с адекватна техническа поддържка на информационните ресурси;
• Анализ на експлоатационните разходи за информационните ресурси;
• Анализ на рисковете за инфраструктурата и информационните ресурси. За осигуряване изпълнението на дейността Възложителят ще предостави:
1. Списък на локациите на централните, областните и общинските администрации, в които следва да бъде извършена инвентаризацията съгласно приложение 1;
2. Методика за инвентаризация на ИКТ ресурсите в централните, областните и общинските администрации съгласно приложение 2;
3. Инсталационни пакети със source code на носител на Информационна система реализираща инвентаризация на ИКТ ресурсите на разработена за нуждите на МП ;
4. Доклад за състоянието на администрацията за 2015 г. и 2016 г.;
5. Информация за лицата, участващи в попълване/отчитане/събиране на информация в АИС за инвентаризация на ИКИ ресурсите от ДАЕУ;
6. Обща координация и организационно съдействие, включително осъществяване на първоначален контакт и създаване на условия за достъп до необходимите за провеждане на инвентаризацията локации в отделните администрации по места;
7. Осигуряване на лице за контакт (на подходяща позиция) във всяка администрация, по въпроси, свързани с провежданата инвентаризация.
- Извършена инвентаризация на ИКИ ресурси чрез физическо посещение в 576 администрации в най-малко 2 005 локации (съгласно Приложение 1);
- Въведени, валидирани и верифицирани в АИС за инвентаризация на ИКИ ресурсите данни за инвентаризираните администрации;
- Извършени 4 бр. анализи на всички постъпили от инвентаризацията данни.
Цялата документация и всички технически описания, ръководства за работа, администриране и поддръжка на Приложенията, включително и на нейните съставни части, трябва да бъдат налични и на български език;
Всички документи трябва да бъдат предоставени от Изпълнителя в електронен формат (ODF/Office Open XML/MS Word DOC/RTF/PDF/HTML или др.), позволяващ пълнотекстово търсене/търсене по ключови думи и копиране на части от съдържанието от оригиналните документи във външни документи, за вътрешна употреба на възложителя;
Навсякъде, където в документацията има включени диаграми или графики, те трябва да бъдат вградени в документите в оригиналния си векторен формат;
Детайлна техническа документация на програмния приложен интерфейс (API), включително за поддържаните уеб услуги, команди, структури от данни и други. Документацията да бъде придружена и с примерен програмен код и/или библиотеки (SDK) за реализиране на интеграция с външни системи, разработен(и) на Java или .NET. Примерният код трябва да е напълно работоспособен и да демонстрира базови итерации с API-то:
Регистриране на крайна точка (end-point) за получаване на актуализации от Приложението в реално време;
Заявки за получаване на номенклатурни данни (списъци, таксономии);
Заявки за актуализиране на номенклатурни данни (списъци, таксономии);
Регистрация на потребител;
Идентификация и оторизация на потребител или уеб услуга.
Документацията за приложния програмен интерфейс (API) трябва да бъде публично достъпна;
Всеки предоставен REST/SOAP приложно-програмен интерфейс трябва да бъде документиран чрез API Blueprint (https://github.com/apiaryio/api-blueprint), Swagger (http://swagger.io) или чрез аналогична технология. Аналогично представяне трябва да бъде изготвено и за SOAP интерфейсите;
Ръководства на потребителя и администратора за работа и администриране на Приложението;
Обща информация, инструкции и процедури за администриране и поддръжка на приложните сървъри, сървърите за бази данни и др.
В обхвата на проекта е включено извършване на дейности по проектиране на системна и приложна архитектура, разработване на компютърни програми и други дейности.
Документацията, предоставена от изпълнителя на възложителя, трябва да бъде:
на български език;
на хартия и в електронен формат; копирането и редактирането на предоставените документи следва да бъде лесно осъществимо;
актуализирана в съответствие със съгласувана с възложителя процедура, която следва да включва документи, подлежащи на промяна/актуализация, крайни срокове и нужната за случая методология.
Минимално изискуемата документация по проекта включва долуизброените документи.
Изпълнителят на настоящата поръчка трябва да дефинира в детайли конкретния обхват на реализация на софтуерната разработка и да документира изискванията към софтуера в детайлни технически спецификации (системен проект), която ще послужи за пряка изходна база за разработка.
Изготвената детайлна техническа спецификация (системен проект) се представя за одобрение на възложителя. В случай на забележки, корекции или допълнения от страна на възложителя изпълнителят е длъжен да ги отрази в детайлната техническа спецификация (системен проект).
Всички продукти, които ще се доставят, трябва да са със специфична документация за инсталиране и/или техническа документация, в това число:
Ръководство за администратора, включващо всички необходими процедури и скриптове по инсталиране, конфигуриране, архивиране, възстановяване и други, необходими за администриране на приложението;
Документи за крайния ползвател – Изпълнителят трябва да предостави главното Ръководство на ползвателите на софтуера. Документът е предназначен за крайните ползватели. Той трябва да описва цялостната функционалност на приложния софтуер и съответното му използване от крайни ползватели;
Описание на софтуерните модули;
Описание на изходния програмен код.
Изпълнителят трябва да изготвя протоколи от изпълнението на дефинираните дейности / поддейности от проекта, описани в раздел 8 на настоящия документ, заедно със съпътстващите ги документи – резултати от изпълнението на етапите.
Изпълнителят трябва да изготвя протоколи за провежданите срещи по време на различните етапи от изпълнението на дейностите, описани в настоящия документ.
Протоколите са неразделна част от документацията по изпълнението на дейността. Протоколът от срещата ще бъде изпращан в електронен формат до всички присъствали лица в тридневен срок след провеждане на срещата. В едноседмичен срок след изпращането на всеки протокол, присъствалите на срещата лица могат да изпращат коментари и предложения за редакция, които Изпълнителят ще нанесе в протокола. След края на този срок ще се счита, че всички присъствали на срещата са съгласни с вписаните в протоколите решения.
За оперативно управление на работата по договора ще се провеждат срещи между ръководните екипи от страна на Изпълнителя и Възложителя с периодичност минимум веднъж месечно. На срещите ще се разглеждат оперативни въпроси, ще се отчита напредъкът по изпълнение на дейностите, плановете за следващия период на изпълнение на договора и възникналите проблеми, вкл. ще се отчита статусът на всички регистрирани от Възложителя проблеми за периода.
В процеса на изпълнение на дейностите от настоящия документ, представители на Възложителя и Изпълнителя могат да инициират работни срещи за уточняване на неясноти и изисквания за актуализиране, за дискутиране и решаване на възникнали проблеми. За целта иницииращата страна следва да уведомява другата по електронен път (имейл) като предварително се заявява целта на срещата и темата за дискусия, на база на което съответният ръководител – координаторът по договора от страна на Възложителя и ръководителят на екипа от страна на Изпълнителя - ще определят експертите, които трябва да вземат участие.
От срещите ще се изготвя протокол, който ще бъде неразделна част от документацията по изпълнението на дейността. Ангажимент за изготвяне на протокола има Изпълнителят. Протоколът от срещата ще бъде изпращан в електронен формат до всички присъствали лица в 3 дневен срок след провеждане на срещата. В едноседмичен срок след изпращането на всеки протокол, Изпълнителят ще нанесе получените коментари и предложения за редакция. След края на този срок ще се счита, че всички присъствали на срещата са съгласни с вписаните в протоколите решения. Управлението на комуникацията трябва да включва изготвяне на минимум следните регулярни доклади за статуса и напредъка на изпълнението на поръчката:
Встъпителният доклад трябва да бъде предоставен до един месец от подписването на договора и да съдържа описание минимум на:
Подробен работен план и актуализиран времеви график по дейности, поддейности и локации за периода на проекта;
Начини на комуникация;
Отговорни лица и екипи.
Встъпителният доклад се одобрява от възложителя.
Междинни доклади трябва да бъдат представяни в електронен формат и на хартиен носител при приключване на всяка от дейностите/поддейностите и/или при настъпване на събитие.
Възложителят разглежда представените доклади и уведомява Изпълнителя за приемането им без забележки или ги връща за преработване, допълване и/или окомплектоване, ако не отговарят на изискванията, като чрез упълномощено в договора лице дава указания и определя срок за отстраняване на констатираните недостатъци и пропуски.
Междинните доклади трябва да съдържат информация относно изпълнението на дейностите/поддейностите по актуалния времеви график.
Те трябва да бъдат подготвени по следния начин:
Общ прогрес по дейностите през периода;
Постигнати резултати за периода;
Срещнати проблеми, причини и мерки, предприети за преодоляването им;
Рискове за изпълнение на свързани дейности и на проекта като цяло и предприети мерки;
Актуализиран времеви график, ако има необходимост от това.
Всеки междинен доклад се одобрява от възложителя с приложен двустранен приемо-предавателен протокол в срок до 5 работни дни от получаването им.
В края на периода за изпълнение трябва да се представи окончателен доклад на български език в електронен формат и на хартиен носител. Окончателният доклад освен изпълненото от последния междинен доклад трябва да съдържа и описание на изпълнението и резултатите на базата на всички извършени на място проверки, включително инвентаризираните с алтернативни методи локации. Той трябва да представя актуалното състояние на ИКТ ресурсите на администрацията, както и препоръки за бъдещи действия с оглед въвеждането на е-управление.
Докладът се изпраща до отговорния служител на възложителя. Възложителят разглежда представеният доклад и уведомява изпълнителя за приемането му без забележки или го връща за преработване, допълване и/или окомплектоване, ако не отговаря на изискванията, като чрез упълномощено в договора лице дава указания и определя срок за отстраняване на констатираните недостатъци и пропуски. Докладът се одобряват от отговорния/отговорните служител/служители в срок до десет работни дни от получаването му.
1 Под „проект“ следва да се разбира предметът на настоящата обществена поръчка