e-gov.bg¢ехническа+спецификация_regix.doc · web viewПриложение...

Приложение № 1

Разширяване на обхвата на средата за Междурегистров обмен на справочна и удостоверителна информация, гарантиране работоспособността на същата, създаване и актуализиране на справки, адаптери, присъединяване на нови регистри и надграждане на средата (RegiX) с нови функционалности

Документация за участие в обществена поръчка с предмет:“Разширяване на обхвата на средата за Междурегистров обмен на справочна и удостоверителна информация, гарантиране работоспособността на същата, създаване и актуализиране на справки, адаптери, присъединяване на нови регистри и надграждане на средата (RegiX) с нови функционалности. Услугата се възлага по проект, който се изпълнява по процедура BG05SFOP001-1.004 чрез директно предоставяне на безвъзмездна финансова помощ с наименование „Надграждане на хоризонталните и централни системи на електронното управление“, финансирана по оперативна програма „Добро управление“ 2014-2020 г.

1

Държавна агенция „Електронно управление“

ТЕХНИЧЕСKA СПЕЦИФИКАЦИЯ

Съдържание

1 РЕЧНИК НА ТЕРМИНИ, ДЕФИНИЦИИ И СЪКРАЩЕНИЯ 6

1.1 Използвани акроними 6

1.2 Технологични дефиниции 7

1.3 Дефиниции за нива на електронизация на услугите 14

2 ВЪВЕДЕНИЕ15

2.1 Цел на документа 16

2.2 Функции и структура на Държавна агенция „Електронно управление“ 16

2.3 За проекта 18

2.4 Нормативна рамка 19

3 Цели, обхват и очаквани резултати от изпълнение на проекта 20

3.1 Общи и специфични цели на проекта 20

3.2 Обхват на проекта 21

3.3 Целеви групи 21

3.4 Очаквани резултати 21

3.5 Период на изпълнение. 22

4 ТЕКУЩО СЪСТОЯНИЕ 23

5 ИЗИСКВАНИЯ КЪМ ИЗПЪЛНЕНИЕ НА ПОРЪЧКАТА 25

5.1 Общи изисквания към изпълнението на обществената поръчка25

5.2 Общи организационни принципи 25

5.3 Управление на проекта 27

Фаза Стартиране 28

Фаза Изпълнение 32

Фаза Приключване 32

5.4 Управление на риска 33

5.5 Изисквания към участниците в изпълнението, предмет на настоящата техническа спецификация 34

5.6 Изисквания към инфраструктурата на Изпълнителя 35

5.7 Възлагане. Заявки 35

5.8 Управление на промените 37

5.9 Управление на инциденти и проблеми 39


2

5.10 Управление на качеството 40

5.11 Изисквания по сигурността 41

5.12 Изисквания по управление на работните процеси42

5.13 Методика и стандарти за разработка на софтуер 42

5.14 Специфични изисквания 46

6 ЕТАПИ НА ИЗПЪЛНЕНИЕ НА ПРОЕКТА 47

6.1 Анализ на данните и изискванията 47

6.1.1. Специфични изисквания към етапите на бизнес анализа и разработка - 47

6.1.2. Специфични изисквания при оптимизиране на процесите по заявяване на електронни административни услуги в зависимост от заявителя – 48

6.1.3. Изисквания за оптимизиране на процесите по подаване на декларации, изискуеми в съответствие с нормативната уредба и вътрешните правила 49

6.1.4. Изисквания към регистрите и предоставянето на административните услуги 49

6.2 Изготвяне на системен проект – 50

6.3 Разработване на софтуерното решение 50

6.4 Тестване 51

6.5 Внедряване 55

6.6 Обучение 55

6.7 Гаранционна поддръжка 57

7 ОБЩИ ИЗИСКВАНИЯ ЗА ИНФОРМАЦИОННИ СИСТЕМИ В ДЪРЖАВНАТА АДМИНИСТРАЦИЯ 59

7.1 Функционални изисквания към информационната система 59

7.1.1. Интеграция с външни информационни системи 61

7.1.2. Интеграционен слой 62

7.1.3. Технически изисквания към интерфейсите 63

7.1.4. Електронна идентификация на потребителите 63

7.1.5. Отворени данни 63

7.1.6. Формиране на изгледи 63

7.1.7. Администриране на системата 63

7.2 Нефункционални изисквания към информационната система 64

7.2.1. Авторски права и изходен код 64

7.2.2. Системна и приложна архитектура65

7.2.3. Бързодействие и мащабируемост 70

7.2.4. Информационна сигурност и интегритет на данните 73


3

7.2.5. Използваемост 75

7.2.6. Системен журнал 79

7.2.7. Дизайн на бази данни и взаимодействие с тях 80

8 ИЗИСКВАНИЯ КЪМ ИЗПЪЛНЕНИЕТО НА ДЕЙНОСТИТЕ ПО ПРОЕКТА 81

8.1 Дейност 1 Създаване на нови и актуализиране на съществуващи адаптери и справки. Присъединяване на нови регистри и бази данни. 81

8.1.1. Описание на дейността 81

8.1.2. Изисквания към изпълнение на дейността82

8.1.3. Очаквани резултати 82

8.2 Дейност 2 Надграждане на системата за междурегистров обмен (RegiX) 82




8.3 Дейност 3 Гарантиране на работоспособността и нормалното функциониране на Системата при удостоверяване на вписани в регистри на централната администрация обстоятелства 95




8.4 Дейност 4 Консултантски услуги 101




9 ДОКУМЕНТАЦИЯ 102

9.1 Изисквания към документацията 102

9.2 Прозрачност и отчетност 103

9.3 Системен проект 103

9.4 Техническа документация 103

9.5 Протоколи 105

9.6 Комуникация и доклади 105

10 РЕЗУЛТАТИ 111

11 Други изисквания 111

11.1 Система за управление 112

11.2 Отчитане на извършената работа 113


4

12 Приложение 1а Протокол за стартиране на дейностите 114

13 Приложение 2а Образец на Заявка за предоставяне на дейности 116

14 Приложение 3а Параметри на качеството на обслужване на Системата (REGIX) 119

14.1 Дефиниции 119

14.2 Определяне на степента на критичност на инцидент 120

14.3 Параметри на качеството при отстраняване на инцидент 122

14.4 Параметри на качеството при отстраняване на проблем 123

14.5 Наличност и достъпност на Компонент на Единния модел 123

15 Приложиние 4 Органи на управлението на договора 124

Организационна структура 124

15.1 Съвет за оперативно управление 124

15.2 Дирекция „Информационни системи и оперативна съвместимост” 125

15.3 Дирекция „Комуникационна и информационна инфраструктура“ 127

15.4 Дирекция „Мрежова и информационна сигурност“ 128

15.5 Ръководители на договора от страна на Възложителя и Изпълнителя 128

15.6 Ръководители на дейности от страна на Изпълнителя 129

15.7 Център за обслужване на потребителите на Единния модел (Help desk) 130

15.8 Контрол на параметрите на качеството 135


5

1 РЕЧНИК НА ТЕРМИНИ, ДЕФИНИЦИИ И СЪКРАЩЕНИЯ1.1 Използвани акроними

Акроним Описание

АИС Административна информационна система

АМС Администрация на Министерския съвет

АОП Агенция по обществени поръчки

АПК Административно процесуален кодекс

БУЛСТАТ Регистър Булстат

ДАЕУ Държавна агенция "Електронно управление"

ДХЧО Държавен хибриден частен облак

Единен модел Единен модел за заявяване, заплащане и предоставяне на електронни административни услуги

ЕИСУЧРДА Единна информационна система за управление на човешките ресурси в държавната администрация

ЕПДЕАУ Единен портал за достъп до електронни административни услуги

ЕУ Е-управление

ЗДОИ Закон за достъп до обществена информация

ЗЕДЕУУ Закон за електронния документ и електронните удостоверителни услуги

ЗЕУ Закон за електронното управление

ИТ Информационни технологии

КАО Комплексно административно обслужване

КТЦЕП Контролно-технически център на електронното правителство

ОПДУ Оперативна програма „Добро управление“

ПАД Първичен администратор на данни по смисъла на чл. 2 (2) от ЗЕУ

ТР Търговски регистър

СОУ Съвет за оперативно управление

ЦАИС Централизирана автоматизирана информационна система


6

Акроним Описание

API Application programming interface/Приложно програмен интерфейс

SDK Software development kit

1.2 Технологични дефиницииТермин Описание

Административна информационна система

Административна информационна система е система, която осигурява поддържането и обработката на данните за оборота на електронни документи и документи на хартиен носител при предоставяне на административни услуги и изпълнение на административни процедури.

Административно обслужване

Административно обслужване е всяка дейност по извършване на административни услуги от структурите на администрацията и от организации, предоставящи обществени услуги.

Бекофис Част от организационната структура на администрацията, ангажирана с изпълнението на вътрешните процеси, които не изискват пряко взаимодействие с клиенти.

Билд Версия на Системата

Бъг Възникнал проблем при използване на: текущите функционалности; новите функционалности; подобренията.

Виртуална комуникационна инфраструктура

Инфраструктура, която на база съществуваща физическа свързаност, предоставена от ДАЕУ, предоставя възможност за изграждане на отделни и защитени виртуални мрежи за всяка една от структурите в сектора, при гарантиране на сигурен и защитен обмен на информация в тях

Вътрешна административна услуга

Вътрешна административна услуга е административна услуга, която един административен орган предоставя на друг при осъществяване на неговите правомощия.

Внедряване на информационна система

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

Вътрешна електронна Вътрешни електронни административни услуги са вътрешни


7

Термин Описание

административна услуга

административни услуги, които могат да се заявяват и/или предоставят от разстояние чрез използването на електронни средства. Вътрешни електронни административни услуги са и услугите, които могат да се заявяват и/или предоставят от разстояние чрез използването на електронни средства, предлагани от лицата, осъществяващи публични функции, и от организациите, предоставящи обществени услуги, едни на други, както и на административните органи. Вътрешни електронни административни услуги могат да се предоставят и от административните органи на лицата, осъществяващи публични функции, и на организациите, предоставящи обществени услуги.

Държавен хибриден частен облак

Централизирана на ниво държава информационна инфраструктура (сървъри, средства за съхранение на информация, комуникационно оборудване, съпътстващо оборудване, разпределени в няколко локации, в помещения отговарящи на критериите за изграждане на защитени центрове за данни), която предоставя физически и виртуални ресурси за ползване и администриране от секторите и структурите, които имат достъп до тях, в зависимост от нуждите им, при гарантиране на високо ниво на сигурност, надеждност, изолация на отделните ползватели и невъзможност от намеса в работоспособността на информационните им системи или неоторизиран достъп до информационните им ресурси. Изолацията на ресурсите и мрежите на отделните секторни ползватели (е-Общини, е-Правосъдие, е-Здравеопазване, е-Полиция) се гарантира с подходящи мерки на логическо ниво (формиране на отделни клъстери, виртуални информационни центрове и мрежи) и на физическо ниво (клетки и шкафове с контрол на достъпа).

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

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

Единен модел за заявяване, заплащане и предоставяне на електронни административни услуги

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

Целта на Единния модел е чрез наличните ресурси на електронното управление да се предостави възможност за централизирано заявяване, заплащане и предоставяне на електронни


8


административни услуги.

Електронна административна услуга

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

Електронно управление (е-управление)

Система на информационно взаимодействие на държавните органи помежду им и с физически и юридически лица въз основа на автоматизация и оптимизиране на държавните функции, а също така и за предоставяне на услуги в електронна форма

Електронна услуга ИТ услуги и електронни административни услуги

Жизнен цикъл на информационна система

Съвкупност от етапи на създаване, реална експлоатация, гарантиране на работоспособността, развитие и прекратяване на експлоатацията на информационната система

Заявител/получател Заявител са физически или юридически лица, които реализират своя законен интерес по заявяване и получаване на резултати от административни услуги пряко или чрез свои представители.

В Закона за електронното управление клиентите са определени като „получатели на електронни административни услуги“.

В настоящия документ като синоним на клиент е използвано понятието заявител/получател или потребител.

ИКТ инфраструктура Съвкупност от обекти на информационната и комуникационната инфраструктура, предназначени да осигурят функционирането на технологичната среда с цел формиране и предоставяне на достъп до електронни информационни ресурси.

Интеграционен слой Съвременен ИТ ресурс на е- управлението, отговорен за оркестрацията между отделните нива на взаимодействие както между ресурсите на електронното управление, така и с външни за него ресурси, средства за контрол на достъпа до съответните ресурси, управление на натоварването и съхранение на информация, свързана с достъпа до ресурси. Интеграционния слой обхваща:

интеграционна шина за обмен на електронни документи; интеграционна шина за обмен на удостоверителна и


9


справочна информация; интеграционна шина за достъп и управление на ИТ

услуги и данни;Предоставя съвременни средства чрез стандартизирани протоколи за взаимодействие.

Интеграционна шина Шина за интеграция на информационни системи като осигурява централизиран и унифициран обмен на съобщения между тях на основата на архитектура ориентирани към услуги

Информационна система

Съвкупност от информационни и комуникационни технологии, персонал по поддръжката и техническа документация, които осъществяват определени технологични действия чрез информационно взаимодействие и са предназначени за решаване на специфични функционални задачи.

В настоящия документ като синоним на информационна система се използва и понятието система.

Информационни и комуникационни технологии

Съвкупност от методи за работа с електронни информационни ресурси и методи за информационно взаимодействие, реализирани с използване на Хардуерно-софтуерни комплекси и телекомуникационна мрежа.

Инцидент Частична или пълна неработоспособност на информационната и комуникационна инфраструктура или нейните отделни обекти, които застрашават тяхното правилно функциониране. Отстраняването на инцидента е насочено към възстановяване на работоспособността.

ИТ услуга Независим компонент, който предоставя конкретна функционалност, може да работи на отдалечено разстояние и е достъпен по електронен път.

Комплексно административно обслужване

Комплексно е административното обслужване, при което административната услуга се предоставя от компетентните административни органи, лицата, осъществяващи публични функции, и организациите, предоставящи обществени услуги, без да е необходимо заявителят да предоставя информация или доказателствени средства, за които са налице данни, събирани или създавани от административни органи, първични администратори на данни, независимо дали тeзи данни се поддържат в електронна форма или на хартиен носител.


10


Компонент на Единния модел

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

В настоящия документ, понятието компонент на Единният модел се асоциира единствено и само със Средата за междурегистров обмен (RegiХ).

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

Метаданни Данни, описващи структурата на информацията, предмет на повторно използване.

Моят egov.bg Работно пространство на потребителя на Единния портал за достъп до електронни услуги, създадено за официално информационно взаимодействие на физически и юридически лица с държавните органи относно предоставянето на услуги в електронен вид и съхранение на специфична за лицето информация.

Отворен формат Означава формат на данни, който не налага употребата на специфична платформа или специфичен софтуер за повторната употреба на съдържанието и е предоставен на обществеността без ограничения, които биха възпрепятствали повторното използване на информация.

Официален отворен стандарт

Стандарт, който е установен в писмена форма и описва спецификациите за изискванията как да се осигури софтуерна оперативна съвместимост.

Пилотен режим на работа на информационна система

Работата на информационната система в ограничен обхват на прилагане, провеждан с цел идентифициране и отстраняване на недостатъците във функционирането на софтуера на информационната система и определяне на нейното съответствие с изискванията на техническата документация

Проблем Еднократно или последователно повтарящи се инциденти. Отстраняването на проблема е насочено към отстраняване на причините довели до инцидент.

Първичен регистър Регистър, който се поддържа от първичен администратор на данни - административен орган, който по силата на закон събира или


11


създава данни за субекти (граждани или организации) или за обекти (движими и недвижими) за първи път и изменя или заличава тези данни. Например Търговският регистър е първичен регистър за юридическите лица със стопанска цел, Имотният регистър е първичен регистър за недвижима собственост.

Развитие на информационна система

Съвкупност от мерки за прилагане на допълнителни функционални изисквания, модернизация на въведена в реална експлоатация информационна система с цел оптимизиране на нейното функциониране и (или) разширяване на функционалността.

В настоящия документ като синоним на развитие на информационна система са използвани понятията надграждане на функционалността или разширяване на обхвата.

При развитието на информационна система, се използва технологичната рамка, с която същата е създадена.

Реална експлоатация на информационна система

Функциониране на информационната система в нормален режим в съответствие с целите, задачите и изискванията, изложени в техническата документация.

Ресурси на електронното управление

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

Система за контрол на версиите

Технология, с която се създава специално място, наречено “хранилище”, където е възможно да се следят и описват промените по дадено съдържание (текст, програмен код, двоични файлове). Една система за контрол на версиите трябва да може:

- Да съхранява пълна история - кой, какво и кога е променил по съдържанието в хранилището, както и защо се прави промяната;

- Да позволява преглеждане разликите между всеки две съхранени версии в хранилището;

- Да позволява при необходимост съдържанието в хранилището да може да се върне към предишна съхранена версия;

- Да позволява наличието на множество копия на хранилището и синхронизация между тях.

Цялата информация, налична в системата за контрол на версиите за


12


главното копие на хранилището, прието за оригинален и централен източник на съдържанието, трябва да може да бъде достъпна публично, онлайн, в реално време.

Софтуер Съвкупност от програми, програмни кодове, както и програмни продукти с техническа документация, необходима за тяхната експлоатация;

Софтуер с отворен код Компютърна програма, която се разпространява при условия, които осигуряват безплатен достъп до програмния код и позволяват:

- Използването на програмата и производните на нея компютърни програми, без ограничения в целта;

- Промени в програмния код и адаптирането на компютърната програма за нуждите на нейните ползватели;

- Разпространението на производните компютърни програми при същите условия.

Списък на стандартни лицензионни споразумения, които предоставят тези възможности, който може да бъде намерен в подзаконовата нормативна уредба към Закона за електронно управление или на: http://opensource.org/license s .

Създаване на информационна система

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

Съпровождане на информационна система

Осигуряване от страна на разработчика на информационната система на съвкупност от мерки за използването на информационната система, пусната в реална експлоатация в съответствие с нейната цел, включително мерки за коригиране, модифициране и премахване на софтуерни дефекти, без да се изменят и/или прилагат допълнителни функционални изисквания и в условията на запазване на целостта на информационната система

Техническа инфраструктура

Съвкупност от технологични технически средства, които осигуряват функционирането на ИКТ инфраструктурата, включително помещения, електрозахранване, климатизация, пожарогасене и пожароизвестяване, контрол на достъпа и др.

Технологична рамка Определя се от ИТ инфраструктурата, върху която оперира системата или група от системи, като включва операционни системи, средства за управление и съхранение на информация,


13

http://opensource.org/licenses

http://opensource.org/licenses


приложни сървъри, развойна среда и езици за програмиране.

Хоризонтална система на електронното управление

Информационна система, която предоставя обща функционалност при предоставянето на всяка ЕАУ, а именно автентикация, оторизация, заплащане, връчване и валидиране и е задължително АИС на участниците да са интегрирани с тях.

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

Споразумение за ниво на обслужване (Service Level Agreement или SLA) е споразумение (договор) между Изпълнителя и Възложителя. В него Възложителят определя нивото на обслужване, което се очаква от Изпълнителя.

1.3 Дефиниции за нива на електронизация на услугитеТермин Описание

Ниво 1 Информация - предоставяне на информация за административни услуги по електронен път, включително за начини и места за заявяване на услугите, срокове и такси.

Ниво 2 Едностранна комуникация - информация съгласно дефиницията за Ниво 1 и осигурен публичен онлайн достъп до шаблони на електронни формуляри.

Ниво 3 Двустранна комуникация - заявяване и получаване на услуги изцяло по електронен път, включително електронно подаване на данни и документи, електронна обработка на формуляри и електронна персонална идентификация на потребителите.

Ниво 4 Извършване на сделки или транзакции по услуги от Ниво 3, включващи онлайн разплащане или доставка.

2 ВЪВЕДЕНИЕКъм настоящия момент в областта на електронното управление няма разработено цялостно общосистемно решение, позволяващо бързо и лесно да се автоматизират процеси и свързаното с тях регистрово производство, необходими за административното обслужване на гражданите и на бизнеса по електронен път.

В програмата за управление на правителството на Република България за периода 2017- 2021 година са поставени цели и мерки, свързани с намаляване на административната тежест пред гражданите и бизнеса, и създаване на по-добри условия за икономическа и инвестиционна дейност и развитие на електронното управление като основа за модернизация на държавната администрация и оптимизиране на процесите по


14

административно обслужване на гражданите и бизнеса. За тази цел в Държавна агенция „Електронно управление“ е разработен и утвърден „Единен модел за заявяване, заплащане и предоставяне на електронни административни услуги“ от гражданите и бизнеса, при гарантиране на достъпността и използваемостта на услугите и запазване на административната самостоятелност на административните органи. Единният моделът описва основния работен процес при заявяване, заплащане и предоставяне електронни административни услуги (ЕАУ). Основната му цел е минимални усилия за реализация и използване на наличните ресурси на електронното управление да се предостави възможност за информиране на гражданите и бизнеса за реализираните чрез Единния модел електронни административни услуги и тяхното централизирано заявяване, заплащане и предоставяне. Другите му цели са да се автоматизира процеса по заявяване, заплащане и предоставяне на ЕАУ на централно ниво; да се разширят функционалностите на съществуващите хоризонтални системи на електронното управление, както и да се създадат нови вътрешни административни услуги и комплексност на процеса по административно обслужване при гарантирана сигурност и достъпност на услугите. Единният модел е публикуван на електронен адрес: https://e-gov.bg/bg/139.

Интеграционната шина за обмен на удостоверителна и справочна информация, която е част от Интеграционния слой на електронното управление, е реализирана чрез Системата за междурегистров обмен (RegiX), наричана за целите на настоящия документ „Системата“. Системата е налична и работеща в момента и се явява структуроопределящ компонент от Единния модел. За реализиране на Единния модел е наложително разширяване на функционалностите и надграждане на Системата, чрез създаване и актуализиране на справки, адаптери, присъединяване на нови регистри, надграждане на ядрото на системата с нови функционалности, изграждане и актуализиране на справки, адаптери, присъединяване на интерфейси, които ще осигурят и гарантират работоспособността на основния и на спомагателните работни процеси, изпълнявани при предоставяне за бизнеса и за гражданите електронни административни услуги, дейности, свързани с осигуряване на работоспособността и развитието на средата за автоматизиран достъп до регистри на първични администратори на данни при обмен на справочна и удостоверителна информация за целите на комплексното административно обслужване.

2.1 Цел на документаЦелта на настоящия документ е да опише софтуерните изисквания към изпълнението на обществена поръчка с предмет: Разширяване на обхвата на средата за Междурегистров обмен на справочна и удостоверителна информация, гарантиране работоспособността на същата, създаване и актуализиране на справки, адаптери, присъединяване на нови регистри и надграждане на средата (RegiX) с нови функционалности.

В настоящата техническа спецификация са описани и изискванията към проектната организация, документацията и отчетността.


15

https://e-gov.bg/bg/139

2.2 Функции и структура на Държавна агенция „Електронно управление“Държавна агенция „Електронно управление“ (ДАЕУ) към Министерския съвет е създадена със Закона за електронното управление (обн. ДВ, бр. 50 от 2016 г.). Агенцията е юридическо лице на бюджетна издръжка със седалище в гр. София. Председателят на ДА „Електронно управление“ е първостепенен разпоредител с бюджет, определя се с Решение на Министерския съвет и се назначава от министър-председателя за срок от 5 години.

ДАЕУ е правоприемник на дирекция „Електронно управление” в Министерството на транспорта, информационните технологии и съобщенията и на Изпълнителната агенция „Електронни съобщителни мрежи и информационни системи” и има функции по издаване, налагане и контрол на политики, правила и добри практики в областта на електронното управление, стратегическо планиране и инициативи, бюджетно програмиране и контрол, координация на секторни политики и секторни и междуведомствени проекти. Също така поддържа централизирани регистри за нуждите на електронното управление, други централизирани регистри, държавен хибриден частен облак и Единната електронна съобщителна мрежа (ЕЕСМ) на държавната администрация и за нуждите на националната сигурност.

Председателят на ДАЕУ провежда държавната политика в следните области:

- Електронно управление;- Електронни удостоверителни услуги;- Електронна идентификация;- Мрежова и информационна сигурност;- Инфраструктура за пространствена информация;- Информация от обществения сектор в машинно-четим отворен формат.

При осъществяването на държавната политика в посочените области председателят на агенцията изпълнява правомощия, възложени му със Закона за електронното управление (ЗЕУ), Закона за електронната идентификация (ЗЕИ), Закона за електронните съобщения (ЗЕС), други закони или с акт на Министерския съвет.

Структурата на Държавната агенция „Електронно управление“ е представена на Фигура 1:


16

Фиг. 1 Структура на Държавна агенция „Електронно управление“

2.3 За проектаОбменът на удостоверителна и справочна информация е реализиран чрез Системата. Основната функция на системата е заявяване от страна на правоимащи лица (консуматори) на удостоверителна и справочна информация от регистри и бази данни на първични администратори на данни (ПАД) и нейното последващо предоставяне. Удостоверяването на консуматорите се извършва чрез генерирани от Системата и предоставени им цифрови сертификати. Заявяването и предоставянето на информация може да се извършва в синхронен или асинхронен режим. Генерираната информация се удостоверява чрез електронен печат от ПАД. Използването и интегрирането със Системата от страна на лицата по чл.1, ал.1 от ЗЕУ е задължително при необходимост от обмен на удостоверителна и справочна информация. Процесът по присъединяване, както и правата и задълженията на


17

консуматорите, са част от утвърдените от председателя на ДАЕУ „Общи условия за достъп до данни от регистри на държавната администрация в средата за междурегистров обмен”( https://e-gov.bg/bg/143).

Системата управлява по централизиран, сигурен, контролиран достъп автоматичното извличане на удостоверителна и справочна информация, съхранявана в поддържани от ПАД регистри и бази данни. Предоставя необходимата функционалност за разработка на комплексни административни услуги и осигурява по ефективен начин еднократното събиране и многократно използване на информация, съгласно принципа на „Служебното начало“.

Консуматори на удостоверителна и справочна информация, съхранявана в регистри и бази данни на ПАД, могат да бъдат всички лица, имащи нормативно основание за заявяване и получаването ѝ. Заявяването и предоставянето на информация е в XML формат. Необходимо е да се осигури предоставяне чрез Системата на електронно подпечатан документ, в един от общо приетите стандарти в съответствие с формат установен от НОИИСРЕАУ, който да има правна стойност. Системата поддържа журнал на събитията, в който се записва информация за заявител, правно основание, момент на заявяване, идентификатор на обекта, за който е заявена информацията (физическо или юридическо лице) и др.. Необходимо е да се реализира по-тясна интеграция на системата с Журнала на събитията на Електронното управление, като се използват функционалностите на интеграционната шина за достъп и управление на ИТ услуги (реализирана чрез Enterprise Service Bus на IBM). Чрез тази функционалност е възможно предоставянето на информация на гражданите за заявена и предоставена информация, свързана с тях и съхранявана от ПАД. Уведомяването чрез Системата трябва да се извършва и в реално време, при заявено желание чрез връзка със системата за електронно връчване (е-Връчване). Необходимо да се гарантира работоспособността и нормалното функциониране на Системата, чрез извършване на наблюдение и управление в реално време на състоянието на адаптерите и Системата като цяло, за да се осигури навременна реакция при частично или пълно отпадане на работоспособност, срив, отпадане на комуникацията, натоварвания и при други извънредни ситуации. Необходимо е Системата да функционира върху инфраструктурата на най-малко два от центровете за данни на Електронното управление, като гарантира достъпа до функционалностите при отпадане на един от Центровете.

Функционалностите ще бъдат разширени и по отношение на удостоверяването от страна на ПАД чрез електронен печат на издаваните справки и удостоверени по електронен път. Ще се разшири функционалността по отношение на визуализирането на издаваните чрез средата удостоверения и справки в поне един от общо приетите стандарти в съответствие с НОИИСРЕАУ, като електронно подпечатани документи. Ще се осигури възможност за интеграция с PKI (Public Key Infrastructure) с цел опериране с цифрови сертификати.

Във връзка с концепцията за регистрова реформа, ще се разработят функционалности и ще се предоставят възможности за асинхронно заявяване и предоставяне на справочна и удостоверителна информация, като ще се реши проблема с невъзможността за удостоверяване по електронен път на вписани на хартиен носител обстоятелства и за целите


18




на редуцирането на необходимите ресурси по присъединяване на ПАД и бази данни, както и автоматизиране на процеса по създаване на шаблони на визуализиращи се документи, свързани със заявяване и предоставяне на ЕАУ. Допълнително, към настоящия момент Правителството на Република България е одобрило пакет от мерки свързани с промяна и подобряване на административното обслужване за гражданите и на бизнеса с приоритет трансформиране на удостоверителни услуги като вътрешни такива, РЕШЕНИЕ на Министерски съвет № 704 от 5 октомври 2018 година. С изпълнението на дейностите по настоящия проект ще се осигури основа за модернизация на държавната администрация и оптимизиране на процесите по административно обслужване на гражданите и на бизнеса, с прилагане на посочените приоритетни мерки, които биха довели до изпълнение на поставените в програмата цели.

Проектът се финансира от бюджета на ДАЕУ и по Оперативна програма „Добро управление“ (ОПДУ), по процедура с код BG05SFOP001-1.004 “Надграждане на хоризонталните и централни системи на електронното управление“ и Наименование на проектно предложение Надграждане на хоризонталните и централни системи на електронното управление във връзка с прилагане на Единния модел за заявяване, заплащане и предоставяне на електронни административни услуги“.

2.4 Нормативна рамкаПроектът се осъществява в съответствие с изискванията, регламентирани със следните нормативни актове, стратегически документи в областта на електронното управление и процедури на Възложителя:

Закон за електронното управление (ЗЕУ);

Закон за електронния документ и електронните удостоверителни услуги (ЗЕДЕУУ);

Закон за администрацията (ЗА);

Наредба за общите изисквания към информационните системи, регистрите и електронните административни услуги (НОИИСРЕАУ);

Наредба за обмена на документи в администрацията (НОДА);

Наредба за общите изисквания за мрежова и информационна сигурност (НОИМИС);

Наредба за Административния регистър;

Наредба за административното обслужване;

Базисен модел на комплексно административно обслужване, приет от Министерския съвет на 19.06.2013 г.;

Стратегия за развитие на електронно управление в Република България 2014 – 2020, приета с Решение №163 на Министерския съвет от 2014 г.;

Единен модел за заявяване, заплащане и предоставяне на електронни административни услуги;


19

Модел за интеграция с хоризонтална система за електронна автентикация.

Посочените нормативни актове и документи в областта на електронното управление и административното обслужване не са изчерпателни. Изпълнението на проекта трябва да е съобразено и с всички произтичащи от законовата уредба и подзаконовите актове за нейното прилагане изисквания, вкл. нови нормативни промени, извън посочените по-горе, имащи отношение към настоящия проект.

3 Цели, обхват и очаквани резултати от изпълнение на проекта3.1 Общи и специфични цели на проекта

С изпълнението на настоящата поръчка се цели да се разшири обхватът на Системата, чрез присъединяване на регистри на първични администратори на данни, разработване на нови или промяна на съществуващи адаптери към регистри, разработка на нови или промяна на съществуващи справки към тези регистри при възникнала необходимост и осигуряване на условия за тяхната работоспособност.

Основната цел е постигане на по-висока степен на автоматизиране на процеса по заявяване, заплащане и предоставяне на ЕАУ, чрез бизнес процеса заложен в Единния модел, в частта взаимодействие между административните органи и интеграция с хоризонталните системи на електронното управление за нуждите на централизирано предоставянето на административни услуги на гражданите и бизнеса, както и предоставяне на възможности за асинхронно заявяване и предоставяне на справочна и удостоверителна информация, което ще реши проблема с невъзможността за удостоверяване по електронен път на вписани на хартиен носител обстоятелства.

Постигането на общата цел ще бъде реализирано чрез следните специфични цели, съответстващи на планираните по проекта дейности:

Разширяване на обхвата на Системата (RegiX), чрез създаване и актуализиране на справки, адаптери и присъединяване на нови регистри;

Надграждане на системата за междурегистров обмен (RegiX);

Гарантиране на работоспособността и нормалното функциониране на Системата при удостоверяване на вписани в регистри на централната администрация обстоятелства;

Повишаване на експертния капацитет на служители от ДАЕУ, чрез оказване на експертна и консултантска помощ по дейности в предмета на настоящата поръчка;

Предоставяне на висококачествени и достъпни електронни административни услуги (ЕАУ).

3.2 Обхват на проектаОписаните в т. 3.1 цели се осъществяват с изпълнението на следните основни дейности, които формират обхвата на проекта:


20

Дейност 1 Създаване на нови и актуализиране на съществуващи адаптери и справки. Присъединяване на нови регистри и бази данни.Дейност 2 Надграждане на системата за междурегистров обмен (RegiX).Дейност 3 Гарантиране на работоспособността и нормалното функциониране на системата за обмен на справочна и удостоверителна информация (RegiX) при удостоверяване на вписани в регистри на централната администрация обстоятелства.Дейност 4 Консултантски услуги

3.3 Целеви групиПроектът е насочен към следните целеви групи:

ДАЕУ в ролята на доставчик на услугите, предоставяни чрез Системата(;

Лица по чл.1 от ЗЕУ, в качеството на ПАД, поддържащи присъединени към Системата регистри;

Лица по чл.1 от ЗЕУ – в качеството на доставчици на ЕАУ;

Физически и юридически лица, в качеството на заявители/получатели на ЕАУ, чрез Единния модел.

3.4 Очаквани резултатиПри изпълнение на поръчката участникът следва да използва съществуващите детайлни технически спецификации на Системата,(които се предоставят от Възложителя през фаза Стартиране, описана в т.5.3 на настоящата техническа спецификация) с цел постигане на следните резултати от изпълнението на поръчката:

Разширяване на набора от присъединени регистри и услуги за достъп до тях;

Реализирани и надградени електронни услуги, удостоверени с електронен печат на доставчика;;

Надградени функционалности за наблюдение на адаптерите за достъп до присъединени регистри и средата като цяло, за да се осигури навременна реакция при сривове, отпадания на комуникацията, натоварвания и извънредни ситуации както и създаване на универсални адаптери;

Обучени служители на ДАЕУ и засегнатите администрации за администриране, наблюдение, обслужване и експлоатация на доставения софтуер;

Изготвена/актуализирана техническа и експлоатационна документация на доставените софтуерни решения;

Надградена система за междурегистров обмен RegiX;

Гарантиране на работоспособността на Системата, съгласно параметрите на качеството на обслужване, посочени в приложението към настоящата техническа спецификация.


21

3.5 Период на изпълнение.Преди стартирането на ефективното предоставяне на дейностите по предмета на договора, се предвижда преходен период (условно наричана фаза Стартиране), през който новият изпълнител се запознава детайлно със съществуващата ИТ инфраструктура на ДАЕУ и гарантира готовност за поемане управлението на Системата с изискваното качество.

През фаза Стартиране се извършва предаването/приемането на дейностите за Системата от Възложителя на Изпълнителя по договора. През фаза Стартиране извършваните дейности от Изпълнителя не се заплащат.

Продължителността на фаза Стартиране е необходимо да залегне в техническото предложение на участника, като същия го включи в Графика за изпълнение на проекта и не може да надвишава 15 (петнадесет) работни дни.

Обхватът на дейностите през фаза Стартиране и тяхната организация се регламентират в т. 5.3 на настоящата техническа спецификация.

Ефективното изпълнение на договора (за дейност от 1 до 4) съвпада с фаза Изпълнение, описана в т. 5.3 на настоящата техническа спецификация, и е с продължителност 36 (тридесет и шест) месеца, считано от датата на приключване на фаза Стартиране и подписване на Протокола за стартиране на дейностите (приложение към настоящата техническа спецификация).

Дейност 1 се изпълнява за 36 (тридесет и шест) месеца от датата на стартиране на фаза Изпълнение. но не по-късно от крайния срок за изпълнение на проект № BG05SFOP001-1.004-0001. Конкретните дейности (доработки) се възлагат чрез писмена заявка от Възложителя. Срокът за изпълнение на всяка доработка, обхвата й и конкретните изисквания към изпълнението й се посочват в писмената заявка за възлагане.

Дейност 2 се изпълнява за 9 (девет) месеца от дата на стартиране на фаза Изпълнение, при последващо предоставяне на гаранционна поддръжка от датата на приемане на надграждането до края на срока на договора.

Дейност 3 се изпълнява за 36 (тридесет и шест) месеца от дата на стартиране на фаза Изпълнение.

Дейност 4 се изпълнява за 36 (тридесет и шест) месеца от датата на стартиране на фаза Изпълнение. Всяка конкретна дейност се възлага чрез писмена заявка от Възложителя. Срокът за изпълнението й, обхвата й и конкретните изисквания към изпълнението й се посочват в писмената заявка за възлагане.

Участниците като част от техническото си предложение трябва да изготвят подробен График за изпъление на проекта (план), в който следва да се конкретизират сроковете за изпълнение на всяка дейност от настоящата поръчка.

4 ТЕКУЩО СЪСТОЯНИЕКъм момента, електронното управление не разполага със средство за предоставяне на вътрешни електронни административни услуги по автоматизиран канал, които да имат


22

правната тежест на удостоверителни услуги. Основният компонент на електронното управление, през който е възможен управляем, сигурен, автоматизиран достъп до регистрите на централната администрация, е Системата (RegiX), оперирана от ДАЕУ. Основната роля на Системата е да дава възможност за заявяване и предоставяне на удостоверителна и справочна информация, за вписани обстоятелства от ПАД в поддържани от тях регистри в режим „система-система“ или чрез потребителски интерфейси, като понастоящем тези задача е решена. Състоянието на държавната администрация и електронното управление към момента обаче не позволява пълноценно разгръщане на обмена на данни в режим „система-система“, като фокусът е изместен към сценария, включващ служител на администрацията, доставчик на заявената услуга в ролята на оператор на клиентско приложение с потребителски интерфейс. В частта справки от регистри този сценарий е покрит в значителна степен, но за да може да бъдат използвани пълноценно в контекста на предоставяне на ЕАУ, ВЕАУ и КАО, е необходимо услугите да имат аналогичната правната тежест на удостоверителните услуги, предоставяни на хартиен носител.

Чрез Системата към настоящия момент са свързани 59 основни регистъра, администрирани от 22 централни администрации - министерства и изпълнителни агенции и са реализирани 152 броя служебни справки към регистрите. Статистическите данни, показват изпълнение на средно над 800 000 заявки на месечна база.

В обхвата на изпълнението на РМС № 496/2017 г. са услуги, които изискват административните органи да предприемат необходимите действия за премахване на изискването за представяне на хартиен носител от гражданите и бизнеса на 11 удостоверителни документа. За издаването на удостоверенията от списъка на услугите, административните органи използват справки от регистри, като съдържащите се в тях данни се извличат автоматизирано по електронен път.

До момента има подадени заявления от 174 администрации, между които и общини, за присъединяване към средата за междурегистров обмен. Очакват се голям брой общини да заявят достъп до регистри, свързани с предоставяне на услугите съгласно РМС 496/2017 год. Необходимостта от допълнение/изменение на справки и адаптери е породено от обстоятелството, че до момента на сформиране на ДАЕУ, Системата се е използвала основно от няколко административни органа, първични администратори на данни от регистри и консуматори на данни от тези регистри, при средно-месечен обем от 100 000 заявки. След като се наложи масовото използване на системата като основно средство за междурегистров обмен на данни за изпълнение на решението на Министерски съвет, се появи необходимостта от реализирането на нови функционалности – добавяне на нови адаптери за нови регистри и разработка на справки към тези регистри.

Актуална информация се публикува на електронен адрес: http://regixaisweb.egov.bg/RegiXInfo/.


23

http://regixaisweb.egov.bg/RegiXInfo/

При изпълнение на Системата е използван следния системен и базов софтуер:

Система Функция Потребители

Съпътстващ софтуер, необходим за

функционирането на системата

RegiX

Предоставя централизирано автоматизиран достъп до първични регистри

Административни органи, физически и юридически лица, които имат регистрация в системата за е-Връчване

Win2012R2StdG2

Ограничения:

Платформа за разработка и експлоатация на адаптерите: Microsoft Windows Server 2008 R2 или по-нов и Microsoft .Net. 4.0/4/5

Формат на обменяните съобщения от/към Системата – XML.

5 ИЗИСКВАНИЯ КЪМ ИЗПЪЛНЕНИЕ НА ПОРЪЧКАТА5.1 Общи изисквания към изпълнението на обществената поръчка

Обществената поръчка е с предмет: „Разширяване на обхвата на средата за Междурегистров обмен на справочна и удостоверителна информация, гарантиране работоспособността на същата, създаване и актуализиране на справки, адаптери, присъединяване на нови регистри и надграждане на средата (RegiX) с нови функционалности и е финансирана от бюджета на ДАЕУ и по проект на ОПДУ „Надграждане на хоризонталните и централни системи на електронното управление във връзка с прилагане на Единния модел за заявяване, заплащане и предоставяне на електронни административни услуги.

5.2 Общи организационни принципи Общите принципи за изпълнение на дейностите, предмет на настоящата поръчка са:

Използване на стандарти, позволяващи отвореност, гъвкавост, сигурност, ефективност и ефикасност при изгражданите и внедрявани електронни услуги при съобразяване с изискванията на действащите нормативни документи в областта на електронното управление;

Изпълнение на основният процес на Единния модел за заявяване, плащане и предоставяне на електронни административни услуги (ЕМЗППЕАУ) и свързаните с него спомагателни процеси по начин, определен в политики, процедури и правила (вкл. за мрежова информационна сигурност, инциденти,


24

архивиране и възстановяване), съобразени с най-добрите европейски, световни практики в областта;

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

Надграждане и развитие на изградените и въведени в експлоатация хоризонтални и централни системи на електронното управление;

Създаване на условия за гарантиране на устойчивост в работоспособността на хоризонталните и централни системи на електронното управление за постигане на висока достъпност и надеждност при заявяване, плащане и предоставяне на електронни административни услуги;

Създаване на условия за навременно и качествено управление на промени в хоризонталните системи, продиктувани от промени в нормативната уредба, вътрешните процедури за работа и технологични актуализации на техническата ИТ инфраструктура;

Подчиненост на дейностите по отношение на нормативната уредба приета в Европейския съюз (ЕС) и в българското законодателство свързана с предметната област на електронното управление.

Задължителност на предложени решения, гарантиращи неприкосновеността на личния живот на потребителите, сигурност, надеждност и защита на използваните данни;

При реализиране на всички дейности използват дефинирани стандарти на ЕС, заложените принципи и стандарти в българското законодателство и подзаконови нормативни актове, както и на най-широко разпространените международни стандарти за предметната област на електронното управление;

Сигурна и надеждна комуникационна среда, използвана в държавната администрация (ДА) с разработена процедура за работа в условия на частично и/или пълно отпадане на комуникациите.

Задължително изискване е да се спазят утвърдените хоризонтални и вертикални принципи на организация на изпълнението на предмета на обществената поръчка за гарантирано постигане на желаните резултати от проекта, така че да се покрие пълният набор от компетенции и ноу-хау, необходими за изпълнение на предмета на поръчката, а също така да се гарантира и достатъчно ниво на ангажираност с изпълнението и проблемите на проекта:

Хоризонталният принцип предполага ангажиране на специалисти от различни звена, така че да се покрие пълният набор от компетенции и ноу-хау по предмета на проекта и същевременно екипът да усвои новите разработки на достатъчно ранен етап, така че да е в състояние пълноценно да ги използва и развива и след приключване на проекта;


25

Вертикалният принцип включва участие на експерти и представители на различните управленски нива, така че управленският екип да покрива както експертните области, необходими за правилното и качествено изпълнение на проекта, така и управленски и организационни умения и възможности за осъществяване на политиката във връзка с изпълнението на проекта. Чрез участие на ръководители на звената – ползватели на резултата от проекта, ще се гарантира достатъчно ниво на ангажираност на институцията с проблемите на проекта.

5.3 Управление на проектаПод „проект“ следва да се разбира предметът на настоящата обществена поръчка.

Участниците трябва да опишат в своите предложения подход за управление на проекта – предложени дейности за управление (методология за управление на проекта), които трябва да включват като минимум управление на реализацията на всички дейности, посочени в настоящото техническо задание, както и разпределението на предложените участници в екипа за управление на поръчката по роли.

Към представеният подход за управление на проекта – предложени дейности за управление (методология за управление на проекта), следва да е направена обосновка за избора му в съответствие с обхвата и целите на обществената поръчка и с какво предложеният подход ще допринесе за качественото постигане на очакваните резултати.

Предложенията на участниците трябва да са съобразени с изискванията на настоящата техническа спецификация и приложенията към нея.

Методологията трябва да включва подробно описание на:

етапите на проекта;

организация на изпълнение:

структура на екипа на Изпълнителя;

начин на взаимодействие между членовете на екипа на Изпълнителя;

връзки за взаимодействие с екипа на Възложителя;

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

разпространяване навреме на необходимата информация до всички участници в проекта.

Участниците трябва да представят график и описание на дейностите за изпълнение на настоящата обществена поръчка. В графика участниците трябва да опишат дейностите и стъпките за тяхното изпълнение максимално детайлно, като покажат логическата връзка между тях. В графика трябва да са посочени датите за предаване на всеки от резултатите, изготвени в изпълнение на обществената поръчка.


26

Участниците трябва да опишат в своите предложения методи за осигуряване на качество на проектните резултати, който трябва да включва осигуряване на качеството и полагане на усилия за непрекъснато подобряване на работата за удовлетворяване на изискванията на Възложителя, съгласно параметрите на качеството на обслужване, посочени в Приложението към настоящата техническа спецификация.

Управлението на Договора, обект на настоящата поръчка, се отнася до следните фази на изпълнението на дейностите по него:

Фаза Стартиране; Фаза Изпълнение; Фаза Приключване.

Фаза Стартиране, включва дейностите по приемо-предаване на наличната документация, запознаване на Изпълнителите с нея, конфигуриране на средите на Възложителя, изготвянето на детайлен план на изпълнението на договора, както и други подготвителни дейности за осигуряване на необходимото ниво на качество на изпълнение на отделните дености. Продължителността на фаза стартиране е необходимо да залегне в техническото предложение на участника , като същия го включи в Графика за изпълнение на проекта и не може да надвишава 15 (петнадесет) работни дни.

Фаза Изпълнение, включва ефективното изпълнение на дейностите по предмета на Договора. Тази фаза започва след приключване на фаза Стартиране и подписване на протокол за стартиране на дейностите. През тази фаза се извършва изпълнение на дейностите по предмета на Договора, контрол на изпълнението му, отчитане и приемане на извършената работа. Тази фаза приключва с края на срока на Договора.

Фаза Приключване, включва дейностите по подготовка на приключването на договора и приемо-предаването на окончателните резултати по договора с Възложителя. Тя започва три месеца преди изтичане на срока на договора и се вписва в Графика за изпълнение на проекта, който е част от техническото предложение на Изпълнителя.

Дейностите по фаза Приключване се извършват паралелно и независимо от дейностите по фаза Изпълнение в същия период.

За извършените дейности във фази Стартиране и Приключване Възложителят не дължи на Изпълнителя никакво допълнително възнаграждение.

Фаза СтартиранеДокументи през фаза Стартиране

Документите, необходими за започване на фаза Стартиране са:

Наличие на подписан договор и всички приложения към него;

ИТ документи и процедури в ДИСОС, имащи отношение към изпълнението на договора;

Координати на оторизираните лица от Възложителя и Изпълнителя, съгласно


27

изискванията на настоящата настоящата техническа спецификация.Документите, свързани с изпълнението и отчитането на фаза Стартиране са:

Изготвен от Изпълнителя и одобрен от Ръководителя на договора от страна на Възложителя план за дейностите, които ще бъдат изпълнявани през фаза Стартиране;

Протоколи за предаване-приемане на наличната документация, правила, процедури, софтуер, свързани с предмета на договора. Ако на Изпълнителя е необходима допълнителна информация или актуализация на предадените документи, то тези дейности се извършват с ресурси на Изпълнителя и за негова сметка;

Протоколи от работни срещи;

Детайлен план за изпълнение на договора, изготвен от Изпълнителя, съгласно изискванията на техническата спецификация и съгласно Графика за изпълнение на проекта , който е визиран в техническото предложение на Изпълнителя;

Процедура за предоставяне на достъп на Изпълнителя по Договора до средите на Възложителя необходими за изпълнение на дейностите по предмета на договора, съгласно изискванията на настоящата техническата спецификация;

Протокол за стартиране на дейностите по договора. С подписването на протокола отговорността по функционирането на Системата, предмет на договора, се поема изцяло от Изпълнителя, съгласно условията на договора и приложенията към него и започва фактическото (ефективното) им предоставяне с договореното качество.

Организация на дейностите през фаза Стартиране

Съвместните дейности между Възложителя и Изпълнителя по Договора се извършват на срещи на оторизираните органи на Възложителя и Изпълнителя.

В срещите могат да бъдат привличани и други специалисти, вкл. представители на досегашния изпълнител в качеството им на консултанти на Възложителя.

Работните срещи се председателстват от Ръководителя на договора от страна на Възложителя или определен от него служител на Възложителя, според темата на срещата.

На тези срещи се разглеждат въпроси, свързани с:

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

Промяна при необходимост на срокове по плана за фаза Стартиране, но без да се променя крайния срок;

Проблеми от организационен и технически характер в фаза Стартиране. Документация за участие в обществена поръчка с предмет:

“Разширяване на обхвата на средата за Междурегистров обмен на справочна и удостоверителна информация, гарантиране работоспособността на същата, създаване и актуализиране на справки, адаптери, присъединяване на нови регистри и надграждане на средата (RegiX) с нови функционалности. Услугата се възлага по проект, който се изпълнява по процедура BG05SFOP001-1.004 чрез директно предоставяне на безвъзмездна финансова помощ с наименование „Надграждане на хоризонталните и централни системи на електронното управление“, финансирана по оперативна програма „Добро управление“ 2014-2020 г.

28

За проведените срещи и взетите на тях решения се съставят протоколи, които се подписват двустранно.

Всички протоколи от проведени срещи през фаза Стартиране се изготвят, съгласно изискванията на настоящата техническа спецификация.

Дейности във фаза Стартиране

Провеждане на първоначална среща, на която:

o Поименно се представят Ръководителите на договора от страна на Възложителя и Изпълнителя, Ръководителите на дейности от страна на Изпълнителя и техните контакти - телефон, е-мейл. Изготвят се контактни списъци, които се разпространяват между двете страни;

o Подписване на протокол/и за приемо-предаване на документация, съгласно настоящата техническаспецификация;

o Уточняват се въпроси, свързани с организацията на дейностите през фаза Стартиране.

Ръководителят на договора от страна на Възложителя одобрява предварително съгласувания между страните план за дейностите през фаза Стартиране.

Изпълнителят подготвя и представя пред Ръководителя на договора от страна на Възложителя за разглеждане и одобрение следните документи:

o Ред и начин на използване на предоставените от Възложителя на Изпълнителя технически средства за съхранение и поддържане на актуална документация;

o Точки за контакт и технически средства за обезпечаването им;

o График за посещенията в офиса на Възложителя в рамките на фаза Стартиране;

o Други документи, необходими за обезпечаване на процеса по предаване и приемане на отговорностите;

o На оперативни срещи се извършва предаване на наличната информация, документация, сорс кодове, политики, правила и процедури на Изпълнителя от Възложителя. При предаването се подписват протоколи, с които се документира факта на предаването и приемането. Ако на Изпълнителя е необходима допълнителна информация или актуализация на предадените документи, то тези дейности се извършват с ресурси на Изпълнителя и за негова сметка;

Екипите на Изпълнителя се запознават с предадените документи и със съществуващите ИТ инфраструктури на Възложителя в обхвата на договора;


29

Разрешаване на проблеми от организационен и технически характер, които са в правомощията на ръководителите на договори от двете страни. При невъзможност за решаването им те се ескалират до съответните ръководни нива за разрешаване;

ДИСОС извършва демонстрация на организирания от Възложителя Център за обслужване на потребители на Единния модел и прави демонстрация на функционирането му. За резултатите от демонстрацията се съставя двустранно подписан протокол;

Изпълнителят изгражда основните работни процеси (управление на: инциденти; промени; конфигурации, сигурност) и последователността от дейности в организацията им, свързани с предоставяне на дейностите в обхвата на предмета на договора;

Изпълнителят идентифицира рискове, които не е идентифицирал в техническото си предложение и представя за разглеждане и приемане от Ръководителя на договора от страна на Възложителя мерки за тяхното смекчаване. Не се оценяват и разглеждат финансови рискове;

Изпълнителят актуализира вътрешните си процедури и правила за отговорностите и взаимодействието на екипите си, с оглед поемане на координацията, управлението и контрола на качеството на функционирането на Системата;

Изпълнителят декларира готовност за поемане управлението на дейностите по предмета на договора с изискваното качество, чрез подписване на протокола за стартиране на дейностите. Протоколът се счита за подписан, след подписването му от страна на Възложителя;

За всички извършени дейности през фаза Стартиране Ръководителите на договора от страна на Възложителя и Изпълнителя подписват протокол, удостоверяващ успешното им изпълнение;

Протоколът за стартиране на дейностите влиза в сила от датата на подписването му от страна на Възложителя, като Изпълнителят поема цялата отговорност за изпълнението на дейностите от 00:00 ч. на деня, следващ подписването му. От този момент отговорността по управлението на дейностите по предмета на договора се поема изцяло от новия Изпълнител и започва фактическото й предоставяне с изискуемото качество;

След подписване на протокола за стартиране на дейностите, директорът на ДИСОС със свой доклад информира Вътрешноведомствения експертен съвет на ДАЕУ за дейностите през фаза Стартиране и за успешното стартиране на дейностите по договора.


30

Приключване на фаза Стартиране

Времетраенето на фаза Стартиране се определя от Участника в Техническото му предложение и не може да е повече от 15 (петнадесет) работни дни.

Фаза Стартиране приключва с подписването на двустранен Протокол за стартиране на дейностите, в който се констатира готовността на Изпълнителя да поеме отговорността за правилното функциониране на съответния компонент на Единния модел;

Ако Изпълнителят не подпише протокола за стартиране на дейностите, в определения за това срок или го подпише без да са изпълнени всички изисквания на договора и приложенията към него, Възложителят може с едностранно изявление да прекрати действието на договора. При прекратяване на договора на посоченото основание, Възложителят не дължи на Изпълнителя каквото и да е обезщетение и/или неустойка. В тридневен срок от прекратяването, Изпълнителят е длъжен да върне цялата документация, сорс кодове и всяка друга информация, предоставена му от Възложителя при или по повод действието на прекратения договор.

Фаза ИзпълнениеФаза Изпълнение, включва ефективното изпълнение на дейностите по предмета

на Договора.

Тази фаза започва след приключване на фаза Стартиране и подписване на протокол за стартиране на дейностите. През тази фаза се извършва изпълнение на дейностите по предмета на Договора, контрол на изпълнението му, отчитане и приемане на извършената работа.

Тази фаза приключва с края на срока на Договора.

Фаза ПриключванеПреди приключване на предоставянето на дейностите по предмета на договора се осъществява фаза Приключване, чиято цел е намаляване на риска от компрометиране на функциониране на Системата преди преминаване на реалното им предоставяне от избран нов Изпълнител.

Стартиране на фаза Приключване

Началото на фаза Приключване се съгласува между страните по време на фаза Стартиране при одобряването на Плана за дейностите по договора като продължителността й е минимум три месеца преди приключването срока на договора. В графика за изпълнение на дейностите по договора, част от техническото предложение на участника, се прави предложение за продължителността на фаза Приключване.

Дейности през фаза Приключване


31

По време на фаза Приключване, Изпълнителят:

Осигурява предаване на пълната актуална документация, информация за конфигурациите, топологиите, архитектурите, техническите устройства, софтуер (собственост на Възложителя), бази данни и др., налични при Изпълнителя в резултат на изпълнени дейности по договора;

Осигурява необходимия брой специалисти със съответните познания, компетентност и реален опит, които да окажат съдействие на Възложителя при:

o детайлното запознаване на новия Изпълнител със спецификата на дейностите, които по съображения за конфиденциалност или по други причини не са могли да му бъдат известни преди и по време на проведената тръжна процедура;

o представяне, идентифициране и инвентаризация на документацията, конфигурациите, настройките, топологиите, архитектурите, техническите устройства и софтуер, провеждането на тестове относно тяхната пълнота и работоспособност. Дейностите се извършват в офиса на Възложителя.

При идентифициране на проблеми относно липси, непълнота, неработоспособност в документацията, конфигурациите, техническите устройства и софтуер, предадени от Изпълнителя на Възложителя в обхвата на съответен договор, Изпълнителят е длъжен да отстрани тези проблеми в рамките на фаза Приключване и за своя сметка.

Приключване на фаза Приключване

Фаза Приключване приключва с изтичане на срока на договора. За дейностите извършени през фаза Приключване се подписва двустранен протокол между Ръководителите на договора на Възложителя и Изпълнителя. За извършените дейности през фаза Приключване не се дължи никакво допълнително възнаграждение от Възложителя на Изпълнителя.

5.4 Управление на рискаВ техническото си предложение участниците трябва да опишат подхода за управление на риска, който ще прилагат при изпълнението на поръчката.

Към момента на изготвяне на техническата спецификация, Възложителят е идентифицирал следния мииимален списък от рискове:

Промяна в нормативната уредба, водеща до промяна на ключови компоненти на решението – предмет на разработка на настоящата обществена поръчка;

Недобра комуникация между екипите на Възложителя и Изпълнителя по време на аналитичните етапи на проекта;

Ненавременно изпълнение на всяко от задълженията от страна на Изпълнителя;


32

Неправилно и неефективно разпределяне на ресурсите и отговорностите при изпълнението на договора;

Забавяне при изпълнение на проектните дейности, опасност от неспазване на срока за изпълнение на настоящата поръчка;

Грешки при разработване на функционалностите на системата; Липса на задълбоченост при изследването и описанието на бизнес процесите и

данните; Не информиране на Възложителя за всички потенциални проблеми, които биха

могли да възникнат в хода на изпълнение на дейностите;

В подхода за управление на риска, Участникът следва да представи за всеки риск от минималния списък на Възложителя оценка на вероятност, въздействие и мерки за реакция и да направи анализ на предложенията си.

През времето за изпълнение на проекта Изпълнителят трябва да следи рисковете, да оценява тяхното влияние, да анализира ситуацията и да идентифицира (евентуално) нови рискове.

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

5.5 Изисквания към участниците в изпълнението, предмет на настоящата техническа спецификация

Изпълнителят следва да осигури за целите на изпълнение на настоящата поръчка минимум следните роли по организацията на управление на проекта, отчитайки следните изисквания:

Ръководител на договор от страна на Изпълнителя;

o Отговорности: Пряко отговаря за организацията, контрола и цялостното управление на договора. Разпределя работата вътре в екипа, отговорен за изпълнението на договора. Подписва документи с изпълнението на възложените заявки или дейности в рамките на договора. Поддържа връзка с екипите на Възложителя или други екипи, имащи отношение към дейностите по договора.

Ръководител на дейност от страна на Изпълнителя

o Отговорности: Пряко отговаря за организацията, контрола и цялостното управление на съответната дейност. Разпределя работата вътре в изпълнителския екип, отговорен за изпълнението на съответната дейност. Подписва документи за изпълнението на възложените заявки или дейности в рамките на дейността. Поддържа връзка с екипите на Възложителя или други екипи, имащи отношение към съответната дейност.

Изпълнителски екипи:Документация за участие в обществена поръчка с предмет:


33

o За всяка дейност Изпълнителят следва да осигури изпълнителски екипи с необходимата квалификация и опит, и осигурено от Изпълнителя необходимо оборудване за безпрепятственото й изпълнение;

o Броят на екипите, тяхното местоположение и включените в тях специалисти се определят от Изпълнителя, с оглед изпълнението на всички изисквания по тази техническа спецификация, включително параметрите на качеството на обслужване, посочени в приложението на настоящата техническа спецификация.;

o Всички разходи по командироването (ако е необходимо) на екипите за изпълнение на дейностите са за сметка на Изпълнителя.

Изпълнителят е длъжен да предостави списък на ангажирани лица със необходимите компетентности, разпределени по дейности и поддейности, както и тяхната ангажираност (роля и време) за целия срок на договора.

5.6 Изисквания към инфраструктурата на Изпълнителя Изпълнителят следва да има подходяща инфраструктура, оборудвана с необходимия хардуер, софтуер, лицензи, комуникационна свързаност, офис техника, мобилни и стационарни телефони, осигуряваща условия за тестване, разработване и компилиране на приложния софтуер в средите на Възложителя. Всички разходи в тази връзка са за сметка на Изпълнителя.

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

Изпълнителят осигурява за своя сметка всички необходими средства за електронна идентификация и доказване на авторство върху електронни документи, необходими му в хода на изпълнение на дейностите по настоящата техническа спецификация.

Изпълнителят в своето Техническо предложение декларира готовността си за изпълнение на изискванията на тази точка.

5.7 Възлагане. ЗаявкиВъзлагане

Дейност 3 се изпълнява постоянно без подаване на заявка. Тя се счита за възложена с подписването на Протокола за стартиране на дейностите (приложение към настоящата техническа спецификация).

Дейност 2 се изпълнява без подаване на заявка. Тя се счита за възложена с подписването на Протокола за стартиране на дейностите (приложение към настоящата техническа спецификация).


34

Конкретните дейности по Дейност 1 и Дейност 4, които се изпълняват с възлагане чрез заявка – стартират само след изричното подаване на заявка (приложение към настоящата техническа спецификация) от страна на Възложителя.

Заявки. Процедура за изготвяне, съгласуване и утвърждаване на заявка

Заявките се изготвят от Ръководителя на договора от страна на Възложителя, на база приложените към настоящата техническа спецификация образци, кoито се подписват, проверяват, съгласуват и утвърждават по начина, посочен в образеца. След уточняване от Възложителят на обхвата и изискванията по заявката, същата се изпраща за оценка на обема от предвидените дейности от Изпълнителя. Изпълнителят, в срок от 3 (три) работни дни от получаването й, връща на Ръководителя на договора от страна на Възложителя мотивирана писмена оценка на обема работа в човекочасове и съответните финансови параметри. В случай на несъгласие на Ръководителят на договора от страна на Възложителя с предложената оценка, същият полага усилия чрез преговори с Изпълнителя да постигнат общо съгласие. В случай, че не бъде постигнато съгласие в рамките на 2 (два) работни дни, Възложителят преценява дали да възложи конкретната заявка. Заявките се изготвят в два еднообразни екземпляра (оригинали) – по един за Възложителя и за Изпълнителя.

Утвърдените заявки се изпращат на Изпълнителя по съответния ред за кореспонденция, съгласно изискванията на договора. След приемането и подписването им от Ръководителя на договора на Изпълнителя, екземплярите се връщат до Възложителя, но не по-късно от 5 (пет) работни дни от датата на изпращането.

Дейностите по изпълнението на заявката започват от датата на подписването й от страна на Изпълнителя или от посочена в заявката дата.

В случай, че Изпълнителят не изпрати подписана заявката или не е възразил писмено на нейното съдържание в указания срок, същата се счита за приета от Изпълнителя и подлежи на изпълнение от Изпълнителя от датата на подписването й от Ръководителя на договора от страна на Възложителя.

В случай, че Изпълнителят е възразил писмено на подписаната от Ръководителя на договора от страна на Възложителя, заявката се внася за разглеждане от комисия на Възложителя, за произнасяне в спора в 10 (десет) дневен срок и неговото решение е задължително за Изпълнителя. При разглеждането на спора, анализира всички представени аргументи на Изпълнителя и се произнася с решение за всеки един от тях.

5.8 Управление на променитеВ техническото си предложение участниците трябва да предложат метод за управление на промените, който ще прилагат при изпълнението на поръчката, съобразявайки се с описаните по-долу изисквания.

Управлението на промените цели да гарантира:

ускорено и устойчиво развитие в условия на намален риск на Единния модел през целия жизнен цикъл на компонентите на модела;


35

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

навременното внедряване само на одобрени промени и с минимални грешки;

оценката на въздействието разкрива адекватно ефекта от промяната върху всички засегнати компоненти на Единния модел;

всички спешни промени са прегледани и одобрени след въвеждането им в експлоатация;

навременно и коректно информиране на ключовите заинтересовани лица относно всички аспекти на промяната.

Процесът включва:

Дефиниране на необходимостта и обхвата на промяната;

Съгласуване на необходимостта и обхвата на промяната със заинтересованите страни;

Оценка на въздействието върху бизнес процеси, системна инфраструктура или приложен софтуер, необходимия финансов ресурс, ползите и рисковете свързани с промяната;

Подаване и регистриране на искане за промяна в Системата за управление на промените на Възложителя;

Приоритизиране на подадени искания за промяна на база изготвена обосновка относно функционалните и техническите изисквания, необходимите ресурси, законовите и/или договорни изисквания, които налагат промяната;

Мотивирано одобрение или отказ за одобрение на промяната;

Планиране, управление и координиране на разработката на промяната. Изготвяне на план за разработка на промяната. В плана, ако е приложимо, се включват и дейности по конвертиране и/или миграция на данни, промени в други компоненти на Единния модел, засегнати услуги или инфраструктура обслужваща Единния модел, промени в архивиращи процедури и/или други промени, гарантиращи успешната реализация на промяната;

Дефиниране, управление и координиране на спешните промени с цел минимизиране на вероятността за последващи инциденти, изработване на оценка на въздействието и одобряване след внедряването на спешната промяна. Създаване на процедура за предоставяне и прекратяване на необходимия достъп до системите и информационните активи за пускане в експлоатация на спешни промени;

Документиране, контрол и отчитане на дейностите по изпълнение на промяната (включително документиране на отхвърлените промени, проследяване на


36

статуса на одобрените промени и приключване на процеса на промяна) с цел гарантиране, че одобрените промени са внедрени, съгласно плана за внедряване на промяната;

Актуализиране на системната документация и документацията на засегнатите работни процеси и процедури;

Приемане на промяната и въвеждане в реална експлоатация, включва:

o Изготвяне на план за въвеждане в експлоатация на промяната. Като в плана се включват при необходимост и дейности, които са извън обхвата на настоящата техническа спецификация, но са предусловие за успешното реализиране на промяната. В този случай тези предусловия се ескалират до Възложителя за предприемане на действия по компетентност;

o Дефиниране на тестови сценарии и критерии за приемане на промяната, подготовка на тестова среда и фактическо тестване на промяната.

o Провеждане на тестове по приемане;

o Подготовка на експлоатационната среда чрез мигриране на всички промени от тестовата среда към експлоатационната (хардуер; мрежови ресурси; операционни системи; приложен софтуер; данни за настройка на системни параметри, номенклатури, вътрешни и/или външни интерфейси; транзакционни данни) и фактическо мигриране;

o Подготовка на участниците (компоненти на Единния модел и потребители) в засегнатите от промяната работни процеси, осигуряване на канали за комуникация и обучение;

o Компилиране на нова версия, инсталиране в реална среда и първоначално съпровождане.

Приключване на промяната;

Отчитане на ползите и реалните ефекти от извършената промяна.Искането за промяна може (допуска се) да се инициират и от двете страни (Възложител и Изпълнител). Упълномощени представители на Възложителя или Изпълнителя могат да инициират искане за промяна. Исканията за промяна се регистрират в Системата за управление на промени на Възложителя.

Регистрираните искания за промени се разглеждат от комисия на Възложителя, където промените се преглеждат и се взема решение за съответното действие по тях.


37

5.9 Управление на инциденти и проблемиВ техническото си предложение участниците трябва да опишат метода за управление на инциденти и проблеми, който ще прилагат при изпълнението на поръчката, съобразявайки се с описаните по-долу изисквания.

Целите на управлението на инцидентите и проблемите са:

осигуряване на работоспособността, както на ключовите хоризонтални системи на електронното управление и постигнатите резултати от тези системи, така и изпълнението на поддържащите процеси, които подпомагат ефективното и ефикасно действие на Единния модел;

създаване и прилагане на процедура по ескалиране на инциденти и проблеми, която гарантира, че същите ще се разрешават навременно и по ефективен начин;

използване на Система за управление на инциденти и проблеми, която гарантира разпознаването им, тяхната проследимост и причините за възникването им;

документиране, комуникиране и одобрение на предоставянето и прекратяването на временен и спешен достъп до ресурсите на електронното управление;

определяне на приоритетите за спешно обслужване.Процесът по управление на инциденти и проблеми се обслужва от Системата за управление на инциденти и проблеми на Възложителя и включва следните дейности относими към ITIL Service Support група:

Разпознаване и регистриране на инцидента, включително информация относно засегнатите потребители и компоненти на Единния модел, описание на инцидента и точно време на възникване;

Адекватно описание и първоначално обслужване на инцидента с цел улесняване идентифицирането на причините за често повтарящи се инциденти и установяване на връзки с известни дефекти в компонентите на Единния модел или интеграционни проблеми;

Ескалиране на неразрешените и критични инциденти към отговорното по-високо ниво и информиране на заинтересованите страни;

Разследване и диагностика на инцидента и установяване на средствата и каналите за разрешаване. Статусът на инцидента се анализира с помощта на база данни за известни дефекти на компонентите на Единния модел, интеграционни проблеми, решения и планирани и/или спешни промени, за да се установят възможностите за разрешаването му;

Разрешаване на инцидента и възстановяване на оперативността на засегнатите Документация за участие в обществена поръчка с предмет:


38

компоненти на Единния модел;

Създаване на база данни за начинът на разрешаване на инцидентите, съдържаща информация както за временните решения (work arounds), така и за искания за промени;

Пълно документиране на разрешените инциденти, включително предприетите стъпки за разрешаването му, точното му класифициране, обратна връзка със засегнатите потребители относно предложеното решение, общо изразходвано време за разрешаване;

Анализ и установяване на първичните причини за често повтарящи се инциденти с цел идентифициране на проблеми свързани с неизвестни дефекти на компонентите на Единния модел;

Регулярен мониторинг на неразрешените инциденти, дефиниране на проблеми и оценка на ефектите върху договорените параметри на качеството за наличност и достъпност на компонент на Единния модел.

Центърът за обслужване на потребителите на Единния модел се създава и управлява, както е детайлно описано в приложението към настоящата техническа спецификация.

Индикатори за измерване на процеса по управление на проблеми и инциденти са:

Общ брой на регистрираните инциденти и проблеми;

Средно време за разрешаване на инцидентите и проблеми;

Съотношение на броя на разрешените инциденти и проблеми на първо ниво спрямо общия брой;

Средна стойност на разходите за разрешаване на инцидент и проблеми;

Съотношение между броя на ръчно и автоматично регистрираните инциденти и проблеми.

5.10 Управление на качествотоВ техническото си предложение участниците трябва да опишат подхода за управление на качеството, който ще прилагат при изпълнението на поръчката, съобразявайки се с описаните по-долу изисквания.

Изпълнителят следва да предложи и създаде организация за управление на качеството при предоставяне на всяка една от дейностите.

Изискванията на Възложителя по отношение на параметрите на качеството на обслужване са детайлно описани в приложението към настоящата техническа спецификация.

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


39

С оглед гарантиране качеството на предоставяните дейности и изискванията на международните стандарти на компонент на Единния модел, Изпълнителят следва да осигури необходимия брой специалисти, които да осъществяват контрол и наблюдение (мониторинг) на предоставянето на дейностите с изискуемите в приложение 3а на техническата спецификация параметри на качеството на обслужване. Параметрите на качеството, които ще бъдат по наблюдение са:

процент на наличност на компонент на Единният модел за календарна година;

сумарно време за отпадане на компонент в минути за денонощие;

брой отпадания на компонент за денонощие.

5.11 Изисквания по сигурносттаВсички действия на Изпълнителя по поддържане нивото на сигурност следва да отговарят на изискванията на законовите и подзаконови нормативните актове, и методическите указания на председателя на ДАЕУ в областта на електронното управление, както и на изискванията на ЕС, свързани със сигурността на информационните системи.

Изпълнителят следва да посочи вътрешната си организация и мерките за контрол по отношение на сигурността, цялостта и защитата на информацията и информационните активи на Възложителя, върху които ще извършва действия при изпълнение на дейностите в обхвата на настоящата спецификация, в т.ч и да осигури необходимите специалисти за управление на сигурността.

При изпълнение на дейностите в обхвата на настоящата техническа спецификация, Изпълнителят, неговите подизпълнители и служители се задължават:

да опазват и да не разгласяват пред трети лица съдържанието на документацията, която е станала известна при изпълнението на дейностите от настоящия документ, без писменото съгласие на Възложителя, с изключение на случаите, когато е задължен по закон за това;

да опазват и да не разгласяват пред трети лица съдържанието информация, която е станала известна при изпълнението на дейностите от настоящия документ;

да опазват и да не разгласяват пред трети лица информация, която е станала известна при изпълнението на дейностите от настоящия документ относно вътрешни правила и процедури, структура, начин на функциониране на, комуникации, мрежи и информационни системи;

да спазват вътрешните правила за достъп и режим на работа в сградата на Възложителя;

да спазват Политиката по информационна сигурност, вътрешните правила и всички процедури и изисквания на Възложителя при работата им в


40

информационната инфраструктура;

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

5.12 Изисквания по управление на работните процесиИзпълнителят следва да организира дейностите си съгласно принципите на основните ИТ работни процеси по ITIL (в актуална версия) и при спазване на приетите в ДАЕУ политики, правила и процедури.

5.13 Методика и стандарти за разработка на софтуерУправлението и изпълнението на дейности свързани с надграждане,

усъвършенстване и разработка на софтуер (дейност 2 от настоящата техническа спецификация) следва да е организирано в етапи, които могат да бъдат разделени на два или повече под-етапа (итерации). Основна цел на под-етапите (итерациите) е да се постигне поетапно извършване на реализацията, тестването и внедряването. Под-етапите по отделните етапи обхващат една или повече дисциплини от цикъла за разработка на софтуерния продукт (бизнес моделиране, специфициране на изисквания, анализ и дизайн, реализация, управление на изпълнението на дейностите, изграждане на среда за изпълнение).

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

А. Индикативно разпределение на изпълнението по етапи.Таблица 1 Етапи на разработката

№ Етап Индикативно процентно съотношение на продължителността на етапите, %

1. Планиране 10

2. Детайлизиране 25

3. Изграждане 45

4. Тестване 10

5. Внедряване 10

Б. Технологична рамкаРазработката трябва да следва технологичната рамка използвана при

разработването до момента на Системата. Спазвайки принципа на приемственост и устойчивост при развитието на Системата, промени в технологичната рамка са принципно недопустими от Изпълнителя. Промени в технологичната рамка могат да бъдат разрешени в


41

случай, че Изпълнителят докаже в писмен анализ, че исканата промяна ще доведе до съществени ползи за подобряване обслужването чрез Единния модел в частност и на електронното управление като цяло и няма да доведе до допълнителни разходи за Възложителя, както във фазата на разработка и внедряване, така и в последващата експлоатация. В отделен раздел в анализа се описва влиянието на исканата промяна върху другите компоненти на Единния модел. Анализът следва да бъде придружен и с проект на детайлен план за реализация на исканата промяна. Промените се допускат само след одобряване от Възложителя и негово решение за въвеждане на промени в технологичната рамка на Системата и планиране на евентуални промени при необходимост в другите компоненти на Единния модел.

В.Етапи на изпълнениеИзпълнението на дейностите следва да бъде разделено на следните 5 (пет) основни

етапи: Планиране; Детайлизиране; Изграждане, Тестване и Внедряване.Изпълняваните дейности са свързани с определени отчетни резултати, които са

представени в изискванията за съответната дейност.5.13.1.1 Етап Планиране (П)

През етап „Планиране” се детайлизира обхвата на изпълнение, включително очертаване на контекста и най-важните изисквания/ограничения. Извършва се оценка на възможните ограничения при проектирането на надграждането на Системата и се изследват областите на висок риск. Изгражда се средата за изпълнение, включително процеси и инструменти. Подготвя се планът за изпълнение. Изграждат се всички среди при изпълнителя, необходими за нормалното функциониране (Project среда, Development среда, Среда за проектиране, Тестова среда и т.н.).

Като резултат от етапа и отчитайки изискванията на дейността Изпълнителят следва да представи:

Таблица 2 Резултати от етап Планиране

Документ Описание

План за управление Планът представлява комплексен, интегриран резултат, в който е съсредоточена цялата информация, необходима за управлението на дейностите. Той включва редица резултати, разработвани по време на етап Планиране, и се поддържа през целия жизнен цикъл.


42

План за управление на качеството

ПУК е резултат, който определя начините, по които ще се управлява качеството на продукта, резултатите и процесите. В Плана за качеството са посочени и редица други резултати, разработвани през етап Планиране. Планът за качеството се поддържа по време на изпълнението.

Списък на рисковете Структуриран списък на известните и реални рискове за изпълнението. Рисковете са подредени в низходящ ред на значимост и към всеки от тях са привързани конкретни мерки за ограничаване на последствията или действия при непредвидени ситуации.

Съставя се Списък на рисковете, в който са отразени предвижданите рискове за успеха на изпълнението. Първите рискове се идентифицират именно през етап Планиране.

Детайлен план за етап Детайлизиране

Включва всички дейности и резултати за конкретния етап, които са дефинирани последователно във времето и са обвързани със съответните ресурси.

Речник В Речника се дефинират всички важни термини и съкращения, използвани в документацията.

5.13.1.2 Етап Детайлизиране (Д)След успешно приключване на етапа на планиране Изпълнителят следва да изготви

Системен проект за реализация на изискванията на Възложителя, документирани в предходния етап, съдържащ като минимум:

Модел и описание на работните процеси; Модел и описание на случаите на употреба; Прототип на потребителския интерфейс; Логически и физически модел на данните; Техническа (софтуерна и инфраструктурна) архитектура; Оразмеряване на системата.

Където е приложимо следва да се използват UML диаграми и/или други графични средства за визуално представяне на моделите.

Много важно е през този етап да се стабилизират в достатъчна степен изискванията и плановете, за да могат върху тях да стъпят основните дейности по дизайн и реализация по време на етап Изграждане.


43

5.13.1.3 Етап Изграждане (И)Основните цели при етап Изграждане са разработката на софтуера и създаването на

използваеми версии (алфа, бета и други тестови версии) в предвидените срокове и с необходимото качество. През този етап трябва да се приключи с дизайна, реализацията и алфа тестовете на цялата заявена функционалност с цел да се получи завършен продукт, годен за предаване на Възложителя.

Одобряването на Системния проект от страна на Възложителя трябва да даде начало на етапа по изграждане, където следва да се реализира надграждането на съответния компонент на Единния модел.

Очакваните като минимум резултати от етап Изграждане са: Предоставен изходен код и инсталационен пакет;

Актуализирани функционална и техническа спецификация. Ако в хода на разработката се открият неточности или нужда от промени в спецификациите те следва да бъдат актуализирани, одобрени от Възложителя.

5.13.1.4 Етап Тестване (Т)Извършват се тестове с цел проверка на функционалната коректност на разработката

и приложимостта й. Етап Тестване протича съгласно изискванията на съответната дейност.Процесът по тестване цели да провери функционалната коректност на разработката

и приложимостта й. Тук Изпълнителят следва: Да разработи, предложи за одобрение на Възложителя набор от тестови

сценарии за проверка на функционалността;

Да разработи, предложи за одобрение на Възложителя набор от тестови сценарии за интеграция;

Да разработи, предложи за одобрение на Възложителя набор от тестови сценарии за проверка производителността при определени натоварвания;

Да обобщи всички тестови сценарии в общ план за тестване и да представи на Възложителя за одобрение;

Да разработи документация за ползване, включваща като минимум:

o ръководство за инсталиране;

o ръководство за администратора;

o ръководство за крайните потребители.

Като резултат от етапа на тестване Изпълнителят трябва да предостави за одобрение на Възложителя минимум:

документ, съдържащ резултатите от тестовете, включително проверка на оразмеряването на системата;


44

ръководство за инсталиране;

ръководство за администратора;

ръководство за крайните потребители;

план за внедряване в продукционната среда, включващ оценка на необходимите ресурси от страна на Възложителя.

5.13.1.5 Етап Внедряване (В)На този етап разработените продукти се инсталират/внедряват в продукционна

среда, като се осъществяват дейности, свързани с: Специфични за фазата на внедряване дейности по инсталиране;

Финни настройки като отстраняване на дефекти, подобряване на производителността и използваемостта на системата и др.;

При внедряването следва да се инсталират/внедрят в продукционната среда надградените части на Системата. През този етап Изпълнителят следва да предложи Процедура за гаранционно обслужване, като част от документа Споразумение за нивото на предоставяните услуги от Изпълнителя по време на гаранционния период. (SLAgp) - процедурата има за цел да опише организацията на поддръжката по време на гаранционния период. Гаранционният период на надградените функционалности на Системата започва да тече от датата на подписване на приемо-предавателния протокол за извършени дейности до края на срока на договора. В рамките на гаранционния период се изпълняват дейностите предвидени по дейност 3, като се отчита съответната специфика.

Отчетните като минимум резултати от етапа по внедряване са: Отчет от внедряването;

План и Отчет от проведените обучения;

Споразумение за нивото на предоставяните услуги от Изпълнителя по време на гаранционния период. (SLAgp).

5.14 Специфични изискванияИзпълнителят е задължен да спазва приетите в системата на Възложителя правила и процедури и други нормативни документи по различните дейности. Основните документи са представени в т. 2.4 на настоящата техническа спецификация. Списък на актуалните документи към момента на стартиране на дейностите ще бъдат предоставени на Изпълнителя в рамките на фаза Стартиране.

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


45

Изпълнителят следва в максимална степен да използва въведените и използвани от Възложителя продукти. Кои продукти ще се използват в рамките на изпълнението на договора ще се определи в рамките на фаза Стартиране.

През фаза Стартиране Възложителят осигурява наличната при него документация съгласно предмета на договора. При необходимост от допълнителна документация Изпълнителят я осигурява за своя сметка без това да влияе на сроковете и качеството на изпълнение.

6 ЕТАПИ НА ИЗПЪЛНЕНИЕ НА ПРОЕКТА6.1 Анализ на данните и изискванията

Дейност 1 Създаване на нови и актуализиране на съществуващи адаптери и справки. Присъединяване на нови регистри и бази данни.

Подходът и условията за изпълнение при анализът на данните и изискванията се описват в заявката за възлагане. Процедурата за изготвяне, съгласуване и утвърждаване на заявката е подробно описана в т.5.7 на настоящата техническа спецификация.

Дейност 2 Надграждане на системата за междурегистров обмен (RegiX)Анализът на данните и изискванията се извършват в етап Планиране и етап Детайлизиране, съгласно подробно описани в т. 5.13 Методика и стандарти за разработване на софтуер и в т.8.2.2 на настоящата техническа спецификация.

Дейност 3 Гарантиране на работоспособността и нормалното функциониране на системата за обмен на справочна и удостоверителна информация (RegiX) при удостоверяване на вписани в регистри на централната администрация обстоятелства

Подходът и условията за изпълнение при анализът на данните и изискванията, ако е приложимо, се изпълняват в рамките на Процедурата за управление на инциденти и проблеми, подробно описана в т.5.9 на настоящата техническа спецификация.

Дейност 4 Консултантски услугиПодходът и условията за изпълнение при анализа на данните и изискванията, ако е приложимо се описват в заявката за възлагане. Процедурата за изготвяне, съгласуване и утвърждаване на заявката е подробно описана в т.5.7 на настоящата техническа спецификация.

6.1.1. Специфични изисквания към етапите на бизнес анализа и разработка - Дейност 1 Създаване на нови и актуализиране на съществуващи адаптери и справки. Присъединяване на нови регистри и бази данни.

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

Дейност 2 Надграждане на системата за междурегистров обмен (RegiX)Специфичните изисквания към етапите на бизнес анализа и разработката са подробно описани в етап Детайлизиране на т. 5.13 Методика и стандарти за разработване на софтуер и в т.8.2.2 на настоящата техническа спецификация..


46


Специфичните изисквания към етапите на бизнес анализа и разработката, ако е приложимо, са описани в рамките на Процедурата за управление на инциденти и проблеми, подробно описана в т.5.9 на настоящата техническа спецификация

Дейност 4 Консултантски услугиСпецифичните изисквания към етапите на бизнес анализа и разработката, ако е приложимо, се описват в заявката за възлагане. Процедурата за изготвяне, съгласуване и утвърждаване на заявката е подробно описана в т.5.7 на настоящата техническа спецификация.

6.1.2. Специфични изисквания при оптимизиране на процесите по заявяване на електронни административни услуги в зависимост от заявителя –


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

Дейност 2 Надграждане на системата за междурегистров обмен (RegiX)Виж т. 8.2.1. на настоящата техническа спецификация.


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

Дейност 4 Консултантски услугиСпецифичните изисквания при оптимизиране на процесите по заявяване на електронни административни услуги в зависимост от заявителя, ако е приложимо, се описват в заявката за възлагане. Процедурата за изготвяне, съгласуване и утвърждаване на заявката е подробно описана в т.5.7 на настоящата техническа спецификация.

6.1.3. Изисквания за оптимизиране на процесите по подаване на декларации, изискуеми в съответствие с нормативната уредба и вътрешните правила


Неприложимо.


47

Дейност 2 Надграждане на системата за междурегистров обмен (RegiX)Неприложимо


Неприложимо

Дейност 4 Консултантски услугиСпецифичните изисквания при оптимизиране на процесите по подаване на декларации, изискуеми в съответствие с нормативната уредба и вътрешните правила, ако е приложимо, се описват в заявката за възлагане. Процедурата за изготвяне, съгласуване и утвърждаване на заявката е подробно описана в т.5.7 на настоящата техническа спецификация

6.1.4. Изисквания към регистрите и предоставянето на административните услугиДейност 1 Създаване на нови и актуализиране на съществуващи адаптери и справки. Присъединяване на нови регистри и бази данни.

Специфичните изисквания към регистрите и предоставянето на административните услуги, ако е прилoжимо, се описват в заявката за възлагане. Процедурата за изготвяне, съгласуване и утвърждаване на заявката е подробно описана в т.5.7 на настоящата техническа спецификация.

Дейност 2 Надграждане на системата за междурегистров обмен (RegiX) Предоставяната удостоверителна и справочна информация, трябва да има правна стойност, чрез удостоверяване с електронен печат на доставчика. Всяка удостоверителна административна услуга в обхвата на системата трябва да бъде достъпна като вътрешно-административна електронна услуга чрез уеб-услуга, като комуникацията се подписва с електронен печат на институцията и с електронен времеви печат по смисъла на Регламент (ЕС) 910/2014;

Всяка услуга, за която се допуска представителна власт, трябва да бъде интегрирана с Регистъра на овластяванията по смисъла на Закона за електронната идентификация;

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



Дейност 4 Консултантски услугиСпецифичните изисквания към регистрите и предоставянето на административните услуги, ако е приложимо, се описват в заявката за възлагане. Процедурата за изготвяне, съгласуване и утвърждаване на заявката е подробно описана в т.5.7 на настоящата техническа спецификация


48

6.2 Изготвяне на системен проект –Дейност 1 Създаване на нови и актуализиране на съществуващи адаптери и справки. Присъединяване на нови регистри и бази данни.

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

Дейност 2 Надграждане на системата за междурегистров обмен (RegiX)Изпълнителят следва да изготви системен проект на база на наличната документация, предоставена от Възложителя и фактическото състояние на Системата.

Описание на изискванията към съдържанието, статусът на изготвянето през етапите на разработка са посочени в т.8.2.2. ( Таблица 4 Отчетни резултати).



Дейност 4 Консултантски услугиСпецифичните изисквания към изготвянето или актуализирането на системен проект, ако е приложимо, се описват в заявката за възлагане. Процедурата за изготвяне, съгласуване и утвърждаване на заявката е подробно описана в т.5.7 на настоящата техническа спецификация

6.3 Разработване на софтуерното решениеДейност 1 Създаване на нови и актуализиране на съществуващи адаптери и справки. Присъединяване на нови регистри и бази данни.

Изпълнителят в своето техническо предложение трябва да разпише метод и методология за разработване на възложените адаптери и справки, съобразявайки се с изискванията на настоящата техническа спецификация.

Дейност 2 Надграждане на системата за междурегистров обмен (RegiX)Разработването на софтуерното решение и специфичните изисквания към него са подробно описани в етап Изграждане на т. 5.13 Методика и стандарти за разработване на софтуер и в т.8.2.2 на настоящата техническа спецификация.



Дейност 4 Консултантски услугиСпецифичните изисквания към разработване на софтуерното решение, ако е приложимо, се описват в заявката за възлагане. Процедурата за изготвяне, съгласуване и утвърждаване на заявката е подробно описана в т.5.7 на настоящата техническа спецификация


49

6.4 Тестване Дейност 1 Създаване на нови и актуализиране на съществуващи адаптери и справки. Присъединяване на нови регистри и бази данни.

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

Дейност 2 Надграждане на системата за междурегистров обмен (RegiX)Целта на провеждането на тестове по приемане е да се установи степента на съответствие на развитието и интеграцията на хоризонталните системи на електронното управление с изискванията (функционални и нефункционални) на Възложителя, както и пълната работоспособност и готовност за използване от всички крайни потребители в продукционна (експлоатационна) среда.

Всяка предавана от Изпълнителя нова версия на Системата, подлежаща на тестване при Възложителя, следва да се съпровожда със минимум следните документи :

План за тестване на новата версия;

Тестов модел (където е приложимо);

Резултати от тестовете при Изпълнителя;

Тестови сценарии за провеждане на приемни изпитания.

Изпълнителя разработва, Възложителя одобрява план за тестване и приемане. В плана се посочват конкретните времеви периоди за провеждане на приемните изпитания и разпределение на дейностите, свързани с провеждането на тестовете.

Приемните изпитания се провеждат съгласно предварително подготвен от Изпълнителя и одобрен от Възложителя тестов модел. В тестовия модел се описват тестови сценарии, които могат да обхващат проверка на функционалност, работоспособност, интеграция на компонентите на Единния модел или интерфейси с други системи, производителност и др. Тестовият модел включва информация за това какво ще бъде тествано (видовете тестове – функционален, за производителност и т.н.) и как ще се тества. Той представлява разрез на моделите на работните процеси, на дизайна и имплементацията, с който са описани самите тестове и тези аспекти на тестваните артефакти, които са от значение за тестовия процес. Тестовият модел включва и набор от тестови случаи, тестови процедури и тестови скриптове, както и описание на очакваните резултати от тестовете и на взаимовръзките помежду им. Трябва да съдържа също таблици на съответствието работен процес – потребителски случаи – компоненти на Единния модел - тестови случаи и тестови сценарии. Таблиците на съответствието се поддържат в актуално състояние през целия период на изпълнение на проекта. Възложителят може да поиска промени и включване на допълнителни тестови сценарии, които Изпълнителят следва да разработи и представи за одобрение от Възложителя.

Инсталирането в ИТ инфраструктурата, тестването и други директни действия се Документация за участие в обществена поръчка с предмет:


50

извършват съвместно с екипи на Възложителя или други изпълнителски екипи, които са отговорни за функционирането на Единния модел (ако съществуват) или самостоятелно от Изпълнителя, като начина и спецификата за изпълнение на конкретните дейности се описват в плана за тестване и приемане.

Възложителят определя екип за тестване, който в присъствието на представител на Изпълнителя извършва приемни изпитания на извършената промяна, като се имат предвид следните условия:

Преди извършване на приемни изпитания при Възложителя, Изпълнителят предоставя за одобрение на Възложителя разработена от него програма с тестови сценарии и примери;

Всички необходими компоненти, свързани с нормалното функциониране на тестваната хардуерна или софтуерна промяна, следва да са инсталирани в среда на Възложителя преди извършването на тестването или приемните изпитания.

Преди провеждането на тестовите изпитания Изпълнителят уведомява Възложителя за готовността за провеждане на тестове и изпраща План и тестов модел за тяхното провеждане, както и цялостна техническа документация. Срокът за уведомлението не може да бъде по-кратък от 20 дни. Заедно с плана и тестовия модел се представят и резултатите от предварителните тестове, извършени в тестовата среда на Изпълнителя;

Всички компоненти, гарантиращи нормалното функциониране на Единния модел и който са били обект на промяната, следва да са инсталирани преди извършването на тестовите изпитания;

Критичността на отделните тестове се указват в Тестовия модел.

За успешно преминаване на тестовете се счита успешното изпълнение на всички тестови сценарии. Сценарият е преминат успешно, ако всяка една от стъпките за изпълнение, включени в него са изпълнени, като са постигнати предварително заложените критерии. В този случай Възложителят подписва протокол.

Подробните изисквания за провеждането на тестовете, както и приемането на цялостната разработка се уточняват в Тестовия модел.

Тестовите изпитания приключват с протокол, който установява дали извършената промяна отговаря напълно на изискванията на Възложителя и действащите нормативни документи или се констатира несъответствие с тях. В протокола следва да се укаже еднозначно дали характера на забелязаните несъответствия позволява приемането на извършена промяна в експлоатация, както и срока, в който те следва да бъдат отстранени;

Продължителността на тестовите изпитания не трябва да надхвърля сроковете съгласно договора и техническото задание.

При констатирани съществени недостатъци, които не позволяват въвеждането в експлоатация, Възложителят представя описание на недостатъците, като приложение към


51

протокола от приемните изпитания (тестването), които трябва да бъдат отстранени преди приемането. В този случай Възложителят има право по свое усмотрение да поиска замяна или поправка на недостатъците в определени срокове или да развали договор в съответната му част поради неизпълнение, както и да поиска връщане на платената до момента цена, ако има такава;

Съществени проблеми, свързани със съвместната работа на всички развити и интегрирани компоненти на Единния модел могат да доведат до не приемане от страна на Възложителя на извършената работа;

Всички тестове по приемане се изпълняват при следните условия:

Всички елементи, гарантиращи нормалното функциониране на Системата, следва да са инсталирани преди извършването на тестовете по приемане;

Тестовете по приемане приключват с протоколи, които установяват съответствието с изискванията, заложени в документите за възлагане, допълнително договорените в хода на изпълнение уточнения и промени, описани в протоколите от работни срещи и действащите нормативни документи или се констатира несъответствие с тях. В протокола следва да се укаже еднозначно дали характера на забелязаните несъответствия позволява приемането на извършените промени, както и срока, в който те следва да бъдат отстранени. Образци на протоколите ще бъдат предоставени на Изпълнителя в рамките на фаза Стартиране;

При успешно приключване на тестовете по приемане (констатирана възможност за начало на реална експлоатация в ИТ инфраструктурата със или без забележки), Възложителят подписва протокол от приемните изпитания;

При констатирани съществени недостатъци, които не позволяват въвеждането в реална експлоатация, Възложителят представя описание на недостатъците, като приложение към протокола от тестовете по приемане, които трябва да бъдат отстранени преди приемането. В този случай Възложителят има право по свое усмотрение да поиска замяна или поправка на недостатъците в определени срокове;

Проблеми, свързани със съвместната работа на всички надградени и интегрирани компоненти на Единния модел и/или работни места могат да доведат до не приемане от страна на Възложителя на извършената работа;

За успешно преминаване на тестовете се счита успешното изпълнение на всички тестови сценарии. Сценарият е преминат успешно, ако всяка една от стъпките за изпълнение, включени в него са изпълнени, като са постигнати предварително заложените критерии. Подробните изисквания за провеждането


52

на тестовете, както и приемането на цялостната разработка се уточняват в Тестовия модел.

По време на тестовете по приемане откритите нередности и проблеми се докладват в Система за управление на дефекти на Възложителя. Достъп до системата ще имат оторизирани потребители на Изпълнителя и служители на Възложителя, с права за регистрация и управление на заявки за проблеми и/или дефекти настъпили в съответния етап на изпълнение. Изпълнителят отстранява регистрираните дефекти в рамките на определен период, като го отразява в системата за управление на дефекти и предава нова версия на Системата за провеждане на нов цикъл функционални тестове по приемане;

За преминаване на тестовете по приемане се счита 100% успешно изпълнение на всички тестови сценарии. Сценарият е преминат успешно, ако всяка една от стъпките за изпълнение, включени в него, са преминати успешно.

След успешно преминати тестове по приемане, проверка за пълнота на предадената документация и пълен Source-code, включително инструкции за компилиране до изпълним код на софтуера (инструкции за build на Source-code), Възложителят приема предадената версия. Възложителя по своя преценка може да изиска допълнително цялостно компилиране на Source-code в своя тестова среда, като осигури за това необходимите софтуер и хардуер.


За всяка публикувана версия- нарочна, свързана с отстраняване на критичен инцидент (от ниво 1 и 2), в предвид на критичността, версията се пуска в реална експлоатация, на база резултати от проведени тестове при разработчика и при гаранции от негова страна, свързани с работоспособността й и невъзможност от влошаване на експлоатационни характеристики на свързани модули и системи. Сервизна версия по отношение на инциденти и проблеми (от ниво 3 и 4) се тества в съответствие с изискванията етап Тестване на т. 5.13 Методика и стандарти за разработване на софтуер.

Дейност 4 Консултантски услугиСпецифичните изисквания към тестването, ако е приложимо, се описват в заявката за възлагане. Процедурата за изготвяне, съгласуване и утвърждаване на заявката е подробно описана в т.5.7 на настоящата техническа спецификация

6.5 ВнедряванеДейност 1 Създаване на нови и актуализиране на съществуващи адаптери и справки. Присъединяване на нови регистри и бази данни.

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


53

Дейност 2 Надграждане на системата за междурегистров обмен (RegiX)Специфичните изисквания към внедряването са подробно описани в етап Внедряване на т. 5.13 Методика и стандарти за разработване на софтуер.


Внедряването се извършва Процедурата за управление на инциденти и проблеми и Процедурата за управление на промени, описани в настоящата техническа спецификация.

Дейност 4 Консултантски услугиСпецифичните изисквания към внедряването, ако е приложимо, се описват в заявката за възлагане. Процедурата за изготвяне, съгласуване и утвърждаване на заявката е подробно описана в т.5.7 на настоящата техническа спецификация.

6.6 ОбучениеДейност 1 Създаване на нови и актуализиране на съществуващи адаптери и справки. Присъединяване на нови регистри и бази данни.

За разработените нови и актуализираните съществуващи адаптери и справки се планира да бъде извършено обучение на администраторите и/или на ползватели или консуматори на информацията на Системата.

Изискванията към обучението, се описват в заявката за възлагане. Процедурата за изготвяне, съгласуване и утвърждаване на заявката е подробно описана в т.5.7 на настоящата техническа спецификация.

Дейност 2 Надграждане на системата за междурегистров обмен (RegiX)Предвижда се обучение на администраторите на системата, Консуматорите и ПАД, по отношение на разработените нови функционалности и възможности на системата като цяло.

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

В рамките на дейността се разработва план за обучение, в който се описва набора от всички дейности по обучение на потребителите на Системата.

Планът за обучение трябва да съдържа минимум следните реквизити:

- списък на всички необходими ресурси за организация и провеждане на обучението;- места за провеждане на обучението;- времеви график.

Обучението трябва да бъде предвидено за два типа потребители на системата:

- крайни потребители (консуматори и ПАД);


54

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

Детайлните изискванията към обучението ще бъдат уточнени през етап Планиране на т. 5.13 Методика и стандарти за разработване на софтуер.


В своето техническо предложение участникът следва да предложи метод и списък материали за обучение, като в него за всяка позиция се включва кратко описание на съдържанието й, за участниците в ниво 1 на Центъра за обслужване на потребителите на Единния модел.

Обучението като минимум трябва да съдържа подробни указания относно първичното събиране на информация за инцидентите, правилната им класификация, работата с база данни „Знание“ (прилагане на вече описани действия за сходни инциденти) и други, необходими на операторите от ниво 1, за да се постигне максимално качество при описание и регистриране на инцидента и се минимизира в максимална степен времето за отстраняването му.

Освен първоначалното обучение, участникът може да предвиди и регулярно (например на три месеца) кратко (в рамките на два или три учебни часа) допълнително обучение на служителите от ниво 1 с цел актуализиране на знанията им.

За администраторите на Системата, Изпълнителят следва да:

- Организира поне веднъж на три месеца сесии за трансфер на знания по предложена от Изпълнителя и съгласувана с Възложителя програма, включваща преглед на промените в Системата;

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

Статусът на Плана за обучение и Материалите за обучение през етапите за разработка са посочени в Таблица № 4 на т. 8.2.2.

Дейност 4 Консултантски услугиНеприложимо


55

6.7 Гаранционна поддръжкаДейност 1 Създаване на нови и актуализиране на съществуващи адаптери и справки. Присъединяване на нови регистри и бази данни.

Гаранционната поддръжка на реализираните доработки се извършва от датата на приемането им от Възложителя до края на срока на договора.

Конкретният срок за всяка доработка се определя във всяка заявка, като се отчита изискването на предходния параграф.

В техническото си предложение, участникът следва да:

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

- разпише ескалационни процедури (заявяване, обслужване, ескалиране на инциденти и др.) и нива на услугите по гаранционната поддръжка

- опише работните процеси по взаимодействие между екипите на Изпълнителя и Възложителя във връзка с организирането, изпълнението и отчитането на дейностите по гаранционната поддръжка

- опише работните процеси по взаимодействие между екипите на Изпълнителя и Доставчиците на технологични средства, използвани при реализацията на системата.

Гаранционната поддръжка се извършва, съгласно изискванията за Дейност 3, като се прилага съответната специфика.

Дейност 2 Надграждане на системата за междурегистров обмен (RegiX)Гаранционната поддръжка на реализираните в рамките на дейността доработки се извършва от датата на приемането им от Възложителя до края на срока на договора.






Гаранционната поддръжка се извършва съгласно изискванията за Дейност 3, като се прилага съответната специфика.


56


Гаранционната поддръжка на реализираните усъвършенствания по т. 8.3.1 „Усъвършенстване на системата в рамките на разработената функционалност: се извършва от датата на приемането им от Възложителя до края на срока на договора.






Гаранционната поддръжка се извършва съгласно изискванията за Дейност 3, като се прилага съответната специфика.

Дейност 4 Консултантски услугиИзискванията към гаранционната поддръжка, ако е приложимо, се описват в заявката за възлагане. Процедурата за изготвяне, съгласуване и утвърждаване на заявката е подробно описана в т.5.7 на настоящата техническа спецификация.

7 ОБЩИ ИЗИСКВАНИЯ ЗА ИНФОРМАЦИОННИ СИСТЕМИ В ДЪРЖАВНАТА АДМИНИСТРАЦИЯ

7.1 Функционални изисквания към информационната системаЗа целите на изпълнението на поръчката Първичните администратори на данни (ПАД) със съдействието на Възложителя трябва да осигурят на Изпълнителя достъп до актуална версия на техническа спецификация на структурата на данните в регистъра, на база спецификацията на информационната система или базата данни на регистъра. Задължително условие за успешно присъединяване на регистър е наличието на програмен достъп до информационната система на регистъра – чрез уеб услуги или чрез рестриктирани изгледи/съхранени процедури в базата данни на регистъра. Ако програмният достъп до данни на регистъра ще става чрез уеб услуга, трябва да бъде предоставена WSDL спецификация на уеб услугата, ако достъпът ще е през базата данни, тогава трябва да се предостави дефиниция на таблици и/ или изгледи в базата данни, както и набор тестови данни, които да се ползват при разработката. Обменът на информация в състава на една


57

служебна електронна услуга за автоматизирано извличане на данни се осъществява на принцип на подаване на съобщение – заявка и получаване в резултат на извършено извличане на данни от регистъра съобщение – отговор. За структурата на данните трябва да се проектира XML схема (във формат XML schema definition или XSD), в която са описани данните в съобщението – заявка и съобщението – отговор. Необходимо е да се спазват специфичните стандарти за дефиниране на XML схемите на заявките и отговорите.

На база на проектираните схеми на структури на заявка и отговор за всеки регистър трябва да се разработи софтуерен компонент адаптер за извличане на данни от регистъра. Адаптерът представлява специфична уеб услуга, която се инсталира в центъра за данни на ПАД на регистъра и която приема като входен параметър съобщението заявка заедно с попълнена матрица за достъп и връща съобщението за отговор с извлечените и филтрирани данни от регистъра, отговарящи на параметъра в заявката и филтрирани на база подадената матрица за достъп, ефективно изключвайки от отговора данни, за които даденият потребител, който извлича данни, няма права да ги получи. Разработката на програмния код на адаптера трябва да стане чрез имплементация на специфичните обектно-ориентирани интерфейси и класове и чрез реализация на програмен код, който на практика да извлича данни през програмния интерфейс на регистъра. На база предоставените спецификации и тестови данни Изпълнителят трябва да подготви тестова установка за разработка и тестване на адаптерите.

Предвидените за разработка и внедряване услуги, за които са необходими разработването на адаптери и справки трябва да бъдат регистрирани предварително в Регистъра на услугите към Административния регистър. Услугите, които ще бъдат надградени, и новоразработените услуги трябва да отговарят на изискванията за електронни услуги, съгласно дефинициите за нивата на електронизация на административните услуги са регламентирани в Наредбата за административния регистър към Закона за администрацията;

В процеса на бизнес анализ да бъдат изследвана съвместимостта на бизнес процесите на Възложителя с вече одобрени оптимизирани референтни модели за предоставяне на услуги и нормативни изисквания на Базисен модел за Комплексно административно обслужване в държавната администрация. При наличие на разработени модели за предоставяне на услуги и справки, да бъдат съобразени нуждите от модификации в референтните модели, за да се постигне подобряване на времето и намаляване на административната тежест при комплексно обслужване, спрямо предоставянето на отделните услуги поединично.

В случай че се касае за административни услуги, те трябва да бъдат разграничени на базата на разлики в бизнес процесите и да не бъдат генерализирани и/или обобщавани на базата на типа на действие (например ако Системата издава няколко различни вида удостоверения, с които се удостоверяват различни обстоятелства, справките трябва да бъдат отделни.

Удостоверителните административни услуги трябва да бъдат регистрирани и като вътрешни административни услуги и да бъде реализирана възможност за предоставянето на тези услуги като електронни вътрешно-административни услуги за нуждите на комплексното административно обслужване чрез служебен онлайн интерфейс. Всяка


58

удостоверителна административна услуга трябва да бъде достъпна като вътрешно-административна електронна услуга чрез уеб-услуга, като комуникацията се подписва с електронен печат на институцията и с електронен времеви печат по смисъла на Регламент (ЕС) 910/2014. Не се допуска съхраняване на данни, на които Възложителят не е първичен администратор, в случай че данните могат да бъдат извличани в реално време от регистър на съответния първичен администратор.

ПАД N

БД Регистър N

...

ПАД1

БД Регистър 1

Адаптор на RegiXФилтриране на

данниАдаптор на RegiX

Филтриране на данни

VPN Server КТЦЕП „Бояна“

VPN

VPN

RegiX Ядро

Портал на администрация

1

Портал на администрация

М

......

КЕАУ 1 КЕАУ К

...КЕАУ 1 КЕАУ L

Управление на заявки (асинхронни опашки)

Управление на комуникацията с адаптори

Управление на метаданни

VPN , Two way SSL

VPN , Two way SSL

RegiX Контрол на достъпаВходна точка за всички администрации –

консуматори на данни

7.1.1. Интеграция с външни информационни системи За постигане на заложените цели трябва да бъдат реализирани следните интеграции:

Системна интеграция с хоризонталната система за електронна автентикация еАвт;

Интеграция на Системата с журнала на събитията за регистриране на изпълнените операции по предоставяне на автоматизирани услуги за достъп до регистрите на централната администрация.

Система за електронно връчване (еВръчване) - управлява изпращането и/или получаването и съхраняването на електронни документи за/от публични органи, физически и юридически лица при еднозначно удостоверяване на момента на изпращане, получаване и връчване, както и гарантиране на авторството и интегритета на същия. В съответствие с Регламент 910/2014, системата реализира услуга електронна препоръчана поща, която е електронен еквивалент на услугата препоръчаната поща с обратна разписка. Услугата за електронна препоръчана поща е вписана в Административния регистър под


59

номер 2805. В контекста на настоящата поръчка, при разработката на електронни удостоверителни услуги трябва да бъде реализирана възможност заявителят на услугата да посочи адрес за електронно връчване на резултата.

Интеграциите с външни информационни системи и регистри трябва да се реализира чрез стандартен интеграционен слой (реализирана чрез Enterprise Service Bus на IBM).

[Системата]

Информационна система 1


Потребители


Информационна система 4Регистър база данни

7.1.2. Интеграционен слой Трябва да се реализира интеграция със интеграционната шина за достъп и

управление на ИТ услуги и данни, реализирана към настоящият момент чрез Enterprice Service Bus на IBM. Чрез нея задължително се осъществява взаимодействието с останалите хоризонтални системи на електронното управление;

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


60

чрез запис в Журнала на събитията;

Трябва да бъде разработен и внедрен служебен онлайн интерфейс за автоматизирано изпращане на документи и нотификации чрез електронна препоръчана поща към подсистемата за сигурно връчване, част от националната система за електронна идентификация, съгласно действащите изисквания за оперативна съвместимост;

7.1.3. Технически изисквания към интерфейситеПриложните програмни интерфейси трябва да отговарят на следните архитектурни, функционални и технологични изисквания:

Служебните онлайн интерфейси трябва да се предоставят като уеб-услуги (web-services) и да осигуряват достатъчна мащабируемост и производителност за обслужване на синхронни заявки (sync pull) в реално време, с максимално време за отговор на заявки под 1 секунда за 95% от заявките, които не включват запитвания до регистри и външни системи. Изпълнителят трябва да обоснове прогнозирано натоварване на Системата и да предложи критерии за оценка на максимално допустимото време за отговор на машинна заявка. Критерият за оценка следва да се основава на анализ на прогнозираното натоварване и на наличния хардуер, който ще се използва. Изпълнителят трябва да представи обосновано предложение за минималното време за отговор на заявка на базата на посочените по-горе критерии и да осигури нужните условия за спазването му;

Да бъде предвидено създаването и поддържането на тестова среда, достъпна за използване и извършване на интеграционни тестове от разработчици на информационни системи, включително такива, изпълняващи дейности за други администрации или за бизнеса, с цел по-лесно и устойчиво интегриране на съществуващите и бъдещи информационни системи.

7.1.4. Електронна идентификация на потребителитеИзискванията в цялата точка са неприложими към обхвата на проекта. „Потребителите“ на Системата са приложения - консуматори, които имплементират унифицирания протокол за извикване на услугите за достъп до регистри на администрацията. Тези консуматори се регистрират и администрират по процедура, утвърдена от председателя на ДАЕУ в която вече е включен хоризонталният модул за е-автентикация, с който трябва да се интегрира Системата.

7.1.5. Отворени данниИзискванията от тази точка са неприложими. В обхвата на проекта не влиза изграждането на регистри, до данните от които да бъде дават достъп, съгласно изискванията на Директива 2013/37/ЕС за повторна употреба на информацията в обществения сектор и на Закона за достъп до обществена информация.


61

7.1.6. Формиране на изглединеприложимо

7.1.7. Администриране на систематаСистемата трябва да осигурява администриране на потребителите и правата за достъп.

7.2 Нефункционални изисквания към информационната система7.2.1. Авторски права и изходен код

Всички компютърни програми, които се надграждат или ще се разработват при необходимост, ще използват изходният код на ядрото на Системата. Същите ще бъдат предоставени от Възложителя. Ядрото на Системата e създадено в среда на затворен код.

Изходният код (Source Code) разработван по проекта, както и цялата техническа документация, трябва да бъде бъдат публично достъпни онлайн от първия ден на разработка, чрез използване на система за контрол на версиите и хранилището по чл. 7в, т.18 от ЗЕУ;Всички авторски и сродни права върху произведения, обект на закрила на Закона за авторското право и сродните му права, включително, но не само, компютърните програми, техният изходен програмен код, структурата и дизайнът на интерфейсите и базите данни, чието разработване е включено в предмета на поръчката, възникват за Възложителя в пълен обем без ограничения в използването, изменението и разпространението им и представляват произведения, създадени по поръчка на Възложителя съгласно чл. 42, ал. 1 от Закона за авторското право и сродните му права.

Разработеният програмен код (source-code), вкл. пакети, процеси, процедури, функции, класове, библиотеки и други файлове и настройки, необходими за компилиране, изпълнимият код, както и всички изготвени документи в хода на изпълнението, остават собственост на ДАЕУ.

Всички документи и данни, като спецификации, модели, планове, бази от данни, софтуер и свързаните с тях документи или материали получени, събрани или изготвени от Изпълнителя в изпълнение на тази група дейности, остават абсолютна собственост на ДАЕУ.

Изпълнителят при завършване на съответната фаза от изпълнението, както и при изтичане на гаранционния период, трябва да предаде всички тези документи и данни на ДАЕУ. След приключване на договора Изпълнителят няма право да задържа копия от такива документи и данни и да ги използва за цели, които не са свързани с договора, без предварителното писмено съгласие на ДАЕУ.

Изпълнителят няма право да публикува статии, свързани с извършените в изпълнение на договора дейности или да реферира към тях, когато предоставя услуги на трети страни, или да разпространява информация, получена от ДАЕУ, без предварителното писмено съгласие на ДАЕУ.

Всякакви резултати и права върху тях, включително авторско право и други права на интелектуална и индустриална собственост, получени в изпълнение на договора, са


62

абсолютна собственост на ДАЕУ. ДАЕУ може да ги използва, публикува или прехвърля, както счете за уместно, без географско или друго ограничение.

При разработката Изпълнителят не трябва да използва програмни средства, върху които ДАЕУ няма предоставено право на ползване или такова, което не може да му бъде предоставено в рамките на договорената стойност за изпълнение.

7.2.2. Системна и приложна архитектура Системата трябва да бъде реализирана като разпределена модулна

информационна система. Системата трябва да бъде реализирана със стандартни технологии и да поддържа общоприети комуникационни стандарти, които ще гарантират съвместимост на системата с бъдещи разработки. Съществуващите модули функционалности трябва да бъдат рефакторирани и/или надградени по начин, който да осигури изпълнението на настоящето изискване;

Бизнес процесите и услугите трябва да бъдат проектирани колкото се може по-независимо с цел по-лесно надграждане, разширяване и обслужване. Системата трябва да е максимално параметризирана и да позволява настройка и промяна на параметрите през служебен (администраторски) потребителски интерфейс;

Трябва да бъде реализирана функционалност за текущ мониторинг, анализ и контрол на изпълнението на бизнес процесите в Системата;

При разработката, тестването и внедряването на Системата Изпълнителят трябва да прилага наложили се архитектурни (SOA, MVC или еквивалентни) модели и дизайн-шаблони, както и принципите на обектно ориентирания подход за разработка на софтуерни приложения;

Системата трябва да бъде реализирана със софтуерна архитектура, ориентирана към услуги - Service Oriented Architecture (SOA);

Взаимодействията между отделните модули в Системата и интеграциите с външни информационни системи трябва да се реализират и опишат под формата на уеб-услуги (Web Services), които да са достъпни за ползване от други системи в държавната администрация, а за определени услуги – и за гражданите и бизнеса; За всеки от отделните модули/функционалности на Системата следва да се реализират и опишат приложни програмни интерфейси – Application Programming Interfaces (API). Приложните програмни интерфейси трябва да са достъпни и за интеграция на нови модули и други вътрешни или външни системи;

Приложните програмни интерфейси и информационните обекти задължително да поддържат атрибут за версия;

Версията на програмните интерфейси, представени чрез уеб-услуги, трябва да Документация за участие в обществена поръчка с предмет:


63

поддържа версията по един или няколко от следните начини:

o Като част от URL-а

o Като GET параметър

o Като HTTP header (Accept или друг)

За всеки отделен приложен програмен интерфейс трябва да бъде разработен софтуерен комплект за интеграция (SDK) на поне две от популярните развойни платформи (.NET, Java, PHP);

Системата трябва да осигурява възможности за разширяване, резервиране и балансиране на натоварването между множество инстанции на сървъри с еднаква роля;

При разработването на Системата трябва да се предвидят възможни промени, продиктувани от непрекъснато променящата се нормативна, бизнес и технологична среда. Основно изискване се явява необходимостта информационната система да бъде разработена като гъвкава и лесно адаптивна, като отчита законодателни, административни, структурни или организационни промени, водещи до промени в работните процеси;

Изпълнителят трябва да осигури механизми за реализиране на бъдещи промени в Системата без промяна на съществуващия програмен код. Когато това не е възможно, времето за промяна, компилиране и пускане в експлоатация трябва да е сведено до минимум. Бъдещото развитие на Системата ще се налага във връзка с промени в правната рамка, промени в модела на работа на потребителите, промени във външни системи, интегрирани със Системата, отстраняване на констатирани проблеми, промени в модела на обслужване и др. Такива промени ще се извършват през целия период на експлоатация на системата, включително и по време на гаранционния период;

Архитектурата на Системата и всички софтуерни компоненти (системни и приложни) трябва да бъдат така подбрани и/или разработени, че да осигуряват работоспособност и отказоустойчивост на системата, както и недискриминационно инсталиране (без различни условия за инсталиране върху физическа и виртуална среда) и опериране в продуктивен режим, върху виртуална инфраструктура, съответно върху Държавния хибриден частен облак (ДХЧО);

Част или всички компоненти на Системата ще бъдат разположени върху Държавния хибриден частен облак като среда за функциониране на информационната система;

Изпълнителят трябва да проектира, подготви, инсталира и конфигурира като минимум следните среди за Системата: тестова, стейджинг, продуктивна;


64

Системата трябва да бъде разгърната върху съответните среди (среда за разработчици, тестова за вътрешни нужди, тестова за външни нужди, стейджинг и продуктивна), предоставени от Възложителя;

Тестовата среда за външни нужди трябва да бъде създадена и поддържана като "Sandbox", така че да е достъпна за използване и извършване на интеграционни тестове от разработчици на информационни системи, включително такива, изпълняващи дейности за други администрации или бизнеса, с цел по-лесно и устойчиво интегриране на съществуващи и бъдещи информационни системи. Тестовата среда за външни нужди трябва да е напълно отделна от останалите среди и нейното използване не трябва да влияе по никакъв начин на нормалната работа на останалите среди или да създава каквито и да било рискове за информационната сигурност и защитата на личните данни;

Мрежата на държавната администрация (ЕЕСМ) ще бъде използвана като основна комуникационна среда и като основен доставчик на защитен Интернет капацитет (Clean Pipe) – изискванията на софтуерните компоненти по отношение на използвани комуникационни протоколи, TCP портове и пр. трябва да бъдат детайлно документирани от Изпълнителя, за да се осигури максимална защита от хакерски атаки и външни прониквания чрез прилагане на подходящи политики за мрежова и информационна сигурност от Възложителя в инфраструктурата на Държавния хибриден частен облак и ЕЕСМ;

В Техническото си предложение участникът трябва да опише добрите практики, които ще прилага по отношение на всеки аспект от системната и приложната архитектура на Системата;

Системата трябва да бъде разработена така, че да позволява използването ѝ от много различни институции (т.нар. multitenancy), като за използване от нова институция не трябва да се изисква нова инсталация;

Трябва да бъде създаден административен интерфейс, чрез който може да бъде извършвана конфигурацията на софтуера;

Всеки обект в системата трябва да има уникален идентификатор;

Записите в регистрите не трябва да подлежат на изтриване или на промяна, а всяко изтриване или промяна трябва да представлява нов запис.

Повторно използване (преизползване) на ресурси и готови разработки

По възможност проектите да имат разработени unit tests с code coverage над 50%, а проектът да използва Continuous Integration (CI) подходи – build bots, unit tests run, регулярно използване на статични/динамични анализатори на кода и др.

Препоръчително е преизползването на проекти, финансирани със средства на Европейския съюз, както и на такива, в които Участникът има активни разработчици. Използването на


65

closed source и на инструменти, библиотеки, продукти и системи с платен лиценз става за сметка на Изпълнителя, като е допустимо в случаите, когато липсва подходяща свободна алтернатива с необходимата функционалност или тя не отговаря на горните условия.

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

7.2.2.1. Подход за работа с външните софтуерни ресурсиЗа реализацията на дадена техническа функционалност обикновено съществуват множество отворени алтернативни проекти, които могат да се използват в настоящата Система. Участникът следва да представи базов списък със свободните компоненти и средства, които възнамерява да използва. Отворените проекти трябва да отговарят на следните критерии:

За разработката им да се използва система за управление на версиите на кода и да е наличен механизъм за съобщаване на несъответствия и приемане на допълнения;

По възможност проектите да са подкрепени от организации с идеална цел, държавни или комерсиални организации;

Когато се налага промяна в изходния код на използван софтуерен компонент, промените трябва да се извършват във fork хранилището на governmentbg в съответствие с изискванията на основния проект. Изпълнителят трябва да извърши необходимите действия за включване на направените промени в основния проект чрез "pull requests" и извършване на необходимите изисквани от разработчиците на основния проект промени до приемането им. Тези дейности трябва да бъдат извършвани по време на целия проект.

При установяване на наличие на нови версии на използваните проекти се извършва анализ на влиянието върху настоящата система. В случаите, при които се оптимизира използвана функционалност, отстраняват се пропуски в сигурността, стабилността или бързодействието, новата версия се извлича и използва след успешното изпълнение на интеграционните тестове.

По възможност проектите да имат разработени unit tests с code coverage над 50%, а проектът да използва Continuous Integration (CI) подходи – build bots, unit tests run, регулярно използване на статични/динамични анализатори на кода и др.

Препоръчително е преизползването на проекти, финансирани със средства на Европейския съюз, както и на такива, в които Участникът има активни разработчици. Използването на closed source и на инструменти, библиотеки, продукти и системи с платен лиценз става за сметка на Изпълнителя, като е допустимо в случаите, когато липсва подходяща свободна алтернатива с необходимата функционалност или тя не отговаря на горните условия.


66

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

Изпълнителят трябва да изгради и да поддържа минимум следните логически разделени среди:

Таблица 3 Среди, поддържани от изпълнителяСреда Описание

Development Чрез Development средата се осигурява работата по разработката, усъвършенстването и развитието на Системата. В тази среда са налични и допълнителните софтуерни системи и инсталации, необходими за управление на разработката – continuous integration средства, системи за автоматизирано тестване и др.

Staging Чрез Staging средата се извършват тестове преди разгръщане на нова версия от Development средата върху Production средата. В нея се извършват всички интеграционни тестове, както и тестовете за натоварване.

Sandbox Testing

Чрез Sandbox средата всички, които трябва да се интегрират към Системата, могат да тестват интеграцията си, без да застрашават работата на продукционната среда.

Production Това е средата, която е публично достъпна за реална експлоатация и интеграция със съответните външни системи и услуги.

Управлението на средите трябва да става чрез автоматизирана система за провизиране и разгръщане на системните компоненти. При необходимост от страна на Възложителя Изпълнителят трябва да съдейства за изграждането на нови системни среди.

Участникът може да предложи изграждането на допълнителни среди според спецификите на предложеното решение.

7.2.2.2. Процес на разработка, тестване и разгръщанеПроцесите, свързани с развитието на Системата, трябва да гарантират висока прозрачност и възможност за обществен контрол над всички разработки по проекта. Изграждането на доверие в гражданите и в бизнеса налага радикално по-висока публичност и прозрачност. По този начин гражданите биха могли да съдействат в процесите по развитие и тестване на разработките през целия им жизнен цикъл.

В случай че върху част от компонентите, нужни за компилация, има авторски права, те могат да бъдат или в отделно хранилище с подходящия за това лиценз или за тях трябва да бъде предоставен заместващ „mock up“ компонент, така че да не се нарушава компилацията на проекта.


67

Трябва да се анализират възможностите за включване на граждани в процесите по разработка, тестване и идентифициране на пропуски на софтуера. Участникът трябва да предложи механизъм и процедури за реализирането на такива процеси.

За всеки един разработван компонент Изпълнителят трябва да покрие следните изисквания за гарантиране на качеството на извършваната разработка и на крайния продукт:

Документиране на Системата в изходния код, минимум на ниво процедура/функция/клас;

Покритие на минимум 50% от изходния код с функционални тестове [в случай на надграждане на съществуваща система – 50% от новата функционалност и 20% от съществуващата];

Използване на continuous integration практики;

Използване на dependency management.

Участникът трябва да опише детайлно подхода си за покриване на изискванията.

Във всеки един компонент на Системата, който се build-ва и подготвя за инсталация (deployment), е необходимо да присъстват следните реквизити:

Дата и час на build;

Място/среда на build;

Потребител извършил/стартирал build процеса;

Идентификатор на ревизията от кодовото хранилище на компонента, срещу която се извършва build-ът.

7.2.3. Бързодействие и мащабируемост7.2.3.1. Контрол на натоварването и защита от DoS/DDoS атаки

Системата трябва да поддържа на приложно ниво "Rate Limiting" и/или "Throttling" на заявки от един и същ клиентски адрес както към страниците с уеб-съдържание, така и по отношение на заявките към приложните програмни интерфейси, достъпни публично или служебно като уеб-услуги (Web Services) и служебни интерфейси.

Системата трябва да позволява конфигуриране от страна на администраторите на лимитите за отделни страници, уеб-услуги и ресурси, които се достъпват с отделен URL/URI.

Системата трябва да поддържа възможност за конфигуриране на различни лимити за конкретни автентикирани потребители (напр. системи на други администрации) и трябва да предоставя възможност за генериране на справки и статистики за броя заявки по ресурси и услуги.


68

7.2.3.2. Кохерентно кеширане на данни и заявки - НеприложимоИзискванията в този раздел са неприложими към обхвата на поръчката. Присъединените регистри са с релационни СУБД, които имат вътрешни механизми за оптимизиране на многократния достъп до едни и същи данни, което обезсмисля поддържането на кохерентен кеш извън тях.

7.2.3.3. БързодействиеПри визуализация на уеб-страници системите трябва да осигуряват висока производителност и минимално време за отговор на заявки - средното време за заявка трябва да бъде по-малко от 1 секунда, с максимум 1 секунда стандартно отклонение за 95% от заявките, без да се включва мрежовото времезакъснение (Network Latency) при транспорт на пакети между клиента и сървъра Трябва да бъдат създадени тестове за натоварване.

7.2.3.4. Използване на HTTP/2С оглед намаляване на служебния трафик, времената за отговор и натоварването на сървърите следва да се използва 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, станат незначителен процент.

7.2.3.5. Подписване на документи При реализацията на електронно подписване с всички видове електронен

подпис трябва да се подписва сигурен хеш-ключ, генериран на базата на образа/съдържанието, а не да се подписва цялото съдържание.

Минимално допустимият алгоритъм за хеширане, който трябва да се използва при електронно подписване, е SHA-256. В случаите, в които не се подписва уеб съдържание (например документи, файлове и др.), е необходимо да се реализира поточно хеширане, като се избягва зареждането на цялото


69

съдържание в оперативната памет.

Системата трябва да поддържа подписване на електронни изявления и електронни документи и с електронни подписи, издадени от Доставчици на доверителни услуги в ЕС, които отговарят на изискванията за унифициран профил на електронните подписи, съгласно подзаконовите правила към Регламент ЕС 910/2014, които влизат в сила и са задължителни от 1 януари 2017 г.;

Трябва да бъдат анализирани техническите възможности за реализиране на подписване на електронни изявления и документи без използване на Java аплет и без да се изисква от потребителите да инсталират Java Runtime, като по този начин се осигури максимална съвместимост на процеса на подписване с всички съвременни браузъри. Такава реализация може да бъде осъществена чрез:

използване на стандартни компоненти с отворен код, отговарящи на горните условия, които са разработени по други проекти на държавната администрация и са достъпни в хранилището, поддържано от Държавна агенция „Електронно управление” – при наличие на такива компоненти в хранилището те трябва да се преизползват и само да бъдат интегрирани в Системата;

използване на плъгин-модули с отворен код, достъпни за най-разпространените браузъри (Browser Plug-ins), които са адаптирани и поддържат унифицираните профили на електронните подписи, издавани от ДДУ в ЕС, и съответните драйвери за крайни устройства за четене на сигурни носители или по стандартизиран в националната нормативна уредба протокол за подписване извън браузъра;

чрез интеграция с услуги за отдалечено подписване, предлагани от доставчици на доверителни услуги в ЕС.

7.2.3.6. Качество и сигурност на програмните продукти и приложенията Да бъде предвидено спазването на добри практики на софтуерната разработка –

покритие на изходния код с тестове – над 60%, документиране на изходния код, използване на среда за непрекъсната интеграция (Continuous Integration), възможност за компилиране и пакетиране на продукта с една команда, възможност за инсталиране на нова версия на сървъра с една команда, система за управление на зависимостите (Dependency Management);

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

7.2.4. Информационна сигурност и интегритет на данните Не се допуска съхранението на пароли на администратори, на вътрешни и


70

външни потребители и на акаунти за достъп на системи (ако такива се използват) в явен вид. Всички пароли трябва да бъдат защитени с подходящи сигурни алгоритми (напр. BCrypt, PBKDF2, scrypt (RFC 7914) за съхранение на пароли и където е възможно, да се използва и прозрачно криптиране на данните в СУБД със сертификати (transparent data-at-rest encryption);

Да бъде предвидена система за ежедневно създаване на резервни копия на данните, които да се съхраняват извън инфраструктурата на системата;

Не се допуска използването на Self-Signed сертификати за публични услуги;

Всички уебстраници (вътрешни и публично достъпни в Интернет) трябва да бъдат достъпни единствено и само през протокол HTTPS. Криптирането трябва да се базира на сигурен сертификат с валидирана идентичност (Verified Identity), позволяващ задължително прилагане на TLS 1.2, който е издаден от удостоверителен орган, разпознаван от най-често използваните браузъри (Microsoft Internet Explorer, Google Chorme, Mozilla Firefox). Ежегодното преиздаване и подновяване на сертификата трябва да бъде включено като разходи и дейности в гаранционната поддръжка за целия срок на поддръжката;

Трябва да бъдат извършени тестове за сигурност на всички уебстраници, като минимум чрез автоматизираните средства на SSL Labs за изпитване на сървърна сигурност (https://www.ssllabs.com/ssltest/). За нуждите на автентикация с КЕП трябва да се предвиди имплементирането на обратен прокси сървър (Reverse Proxy) с балансиране на натоварването, който да препраща клиентските сертификати към вътрешните приложни сървъри с нестандартно поле (дефинирано в процеса на разработка на Системата) в HTTP Header-а. Схемата за проксиране на заявките трябва да бъде защитена от Spoofing;

Като временна мярка за съвместимост настройките на уебсървърите и Reverse Proxy сървърите трябва да бъдат балансирани така, че Системата да позволява използване и на клиентски браузъри, поддържащи по-стария протокол TLS 1.1. Това изключение от общите изисквания за информационна сигурност не се прилага за достъпа на служебни потребители от държавната администрация и доставчици на обществени услуги, които имат служебен достъп до ресурси на Системата;

При разгръщането на всички уебуслуги (Web Services) трябва да се използва единствено протокол HTTPS със задължително прилагане на минимум TLS 1.2;

Бисквитките (cookies) задължително да имат флаг HttpOnly;

Headers на отговорите да не съдържат чувствителна информация;

В отговорите да има HTTP security headers, Content Security Policy (CSP), X-


71

https://www.ssllabs.com/ssltest/

Content-Type-Options, X-Frame-Options (XFO), X-XSS-Protection;

Програмният код трябва да включва методи за автоматична санитизация на въвежданите данни и потребителски действия за защита от злонамерени атаки, като минимум SQL инжекции, XSS атаки и други познати методи за атаки, и да отговаря, където е необходимо, на Наредбата за оперативна съвместимост и информационна сигурност;

При проектирането и разработката на компонентите на Системата и при подготовката и разгръщането на средите трябва да се спазват последните актуални препоръки на OWASP (Open Web Application Security Project);

Трябва да бъде изграден модул за проследимост на действия и събития в Системата. За всяко действие (добавяне, изтриване, модификация, четене) трябва да съдържа следните атрибути:

o Уникален номер;

o Точно време на възникване на събитието;

o Вид (номенклатура от идентификатори за вид събитие);

o Данни за информационна система, където е възникнало събитието;

o Име или идентификатор на компонент в информационната система, регистрирал събитието;

o Приоритет;

o Описание на събитието;

o Данни за събитието.

Астрономическото време за удостоверяване настъпването на факти с правно или техническо значение се отчита с точност до година, дата, час, минута, секунда и при технологична необходимост - милисекунда, изписани в съответствие със стандарта БДС ISO 8601:2006;

Астрономическото време за удостоверяване настъпването на факти с правно значение и на такива, за които се изисква противопоставимост, трябва да бъде удостоверявано с електронен времеви печат по смисъла на Глава III, Раздел 6 от Регламент ЕС 910/2014. Трябва да бъде реализирана функционалност за получаване на точно астрономическо време, отговарящо на горните условия, и от доставчик на доверителни услуги или от държавен орган, осигуряващ такава услуга, отговаряща на изискванията на RFC 3161;

Трябва да бъдат проведени тестове за проникване (penetration tests), с които да се идентифицират и коригират слаби места в сигурността на системата.


72

7.2.5. Използваемост7.2.5.1. Общи изисквания за използваемост и достъпност

При проектирането и разработката на софтуерните компоненти и потребителските интерфейси трябва да се спазват стандартите за достъпност на потребителския интерфейс за хора с увреждания WCAG 2.0, съответстващ на ISO/IEC 40500:2012;

Всички ресурси трябва да са достъпни чрез GET заявка на уникален адрес (URL). Не се допуска използване на POST за достигане до формуляр за подаване не заявление, за генериране на справка и други;

Функционалностите на потребителския интерфейс на Системата трябва да бъдат независими от използваните от потребителите интернет браузъри и устройства, при условие че последните са версии в период на поддръжка от съответните производители. Трябва да бъде осигурена възможност за ползване на публичните модули на приложимите услуги през мобилни устройства – таблети и смарт-телефони, чрез оптимизация на потребителските интерфейси за мобилни устройства (Responsive Design);

Не се допуска използване на капча (Captcha) като механизъм за ограничаване на достъпа до документи и/или услуги. Алтернативно, Системата трябва да поддържа "Rate Limiting" и/или "Throttling" съгласно изискванията в т. 7.2.6.1. от настоящите изисквания. Допуска се използването на Captcha единствено при идентифицирани много последователни опити от предполагаем „бот“;

Трябва да бъде осигурен бърз и лесен достъп до електронните услуги и те да бъдат промотирани с подходящи навигационни елементи на публичната интернет страница – банери, елементи от главното меню и др.;

Публичните уеб страници на Системата трябва да бъдат проектирани и оптимизирани за ефективно и бързо индексиране от търсещи машини с цел популяризиране сред потребителите и по-добра откриваемост при търсене по ключови думи и фрази. При разработката на страниците и при изготвяне на автоматизираните процедури за разгръщане на нова версия на Системата трябва да се използват инструменти за минимизиране и оптимизация на размера на изходния код (HTML, JavaScript и пр.) с оглед намаляване обема на файловете и по-бързо зареждане на страниците;

Не се допуска използването на HTML Frames, за да не се пречи на оптимизациите за търсещи машини;

При разработката на публични уеббазирани страници трябва да се използват и да се реализира поддръжка на:

o Стандартните семантични елементи на HTML5 (HTML Semantic Elements);


73

http://www.w3schools.com/html/html5_semantic_elements.asp

o JSON-LD 1.0 (http://www.w3.org/TR/json-ld/);

o Open Graph Protocol (http://ogp.me) за осигуряване на поддръжка за качествено споделяне на ресурси в социални мрежи и мобилни приложения;

В екранните форми на Системата трябва да се използват потребителски бутони с унифициран размер и лесни за разбиране текстове в еднакъв стил.

Всички текстови елементи от потребителския интерфейс трябва да бъдат визуализирани с шрифтове, които са подходящи за изобразяване на екран и които осигуряват максимална съвместимост и еднакво възпроизвеждане под различни клиентски операционни системи и браузъри. Не се допуска използването на серифни шрифтове (Serif).

Полета, опции от менюта и командни бутони, които не са разрешени конкретно за ролята на влезлия в системата потребител, не трябва да са достъпни за този потребител. Това не отменя необходимостта от ограничаване на достъпа до бизнес логиката на приложението чрез декларативен или програмен подход.

Всяка екранна форма трябва да има наименование, което да се изписва в горната част на екранната форма. Наименованията трябва да подсказват на потребителя какво е предназначението на формата.

Всички търсения трябва да са нечувствителни към малки и главни букви.

Полетата за пароли трябва задължително да различават малки и главни букви.

Полетата за потребителски имена трябва да позволяват използване на имейл адреси като потребителско име, включително да допускат всички символи, регламентирани в RFC 1123, за наименуването на хостове;

Главните и малките букви на въвежданите данни се запазват непроменени, не се допуска Системата да променя капитализацията на данните, въвеждани от потребителите.

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

Наименованията на полетата следва да са достатъчно описателни, като максимално се доближават до характера на съдържащите се в тях данни.

Системата трябва да поддържа прекъсване на потребителски сесии при липса на активност. Времето трябва да може да се променя от администратора на системата без промяна в изходния код. Настройките за време за прекъсване на неактивни сесии трябва да включват и възможността администраторите да дефинират стилизирана страница с информативно съобщение, към която Системата да пренасочва автоматично браузърите на потребителите в случай на


74

http://ogp.me/

http://www.w3.org/TR/json-ld/

прекъсната сесия;

Дългите списъци с резултати трябва да се разделят на номерирани страници с подходящи навигационни елементи за преминаване към предишна, следваща, първа и последна страница, към конкретна страница. Навигационните елементи трябва да са логически обособени и свързани със съответния списък и да се визуализират в началото и в края на HTML контейнера, съдържащ списъка;

За големите йерархически категоризации трябва да се предвиди възможност за навигация по нива или чрез отложено зареждане (lazy load).

7.2.5.2. Интернационализация Системата трябва да може да съхранява и едновременно да визуализира данни

и съдържание, което е въведено/генерирано на различни езици;

Всички софтуерни компоненти на Системата, използваните софтуерни библиотеки и развойни комплекти, приложните сървъри и сървърите за управление на бази данни, елементите от потребителския интерфейс, програмно-приложните интерфейси, уебуслугите и др. трябва да поддържат стандартно и да са конфигурирани изрично за спазване на минимум Unicode 5.2 стандарт при съхранението и обработката на текстови данни, съответно трябва да се използва само UTF-8 кодиране на текстовите данни.

Всички публично достъпни потребителски интерфейси следва да поддържат многоезичност, като минимум български и английски език.

Публичната част на Системата трябва да позволява превключване между работните езици на потребителския интерфейс в реално време от профила на потребителя и от подходящ, видим и лесно достъпен навигационен елемент в горната част на всяка страница, който включва не само текст, но и подходяща интернационална икона за съответния език;

При визуализация на числа трябва да се използва разделител за хиляди (интервал).

При визуализация на дати и точно време в елементи от потребителския интерфейс в генерирани справки или в електронни документи всички формати за дата и час трябва да са съобразени с избрания от потребителя език/локация в настройките на неговия профил:

o За България стандартният формат е „DD.MM.YYYY HH:MM:SS”, като наличието на време към датата е в зависимост от вида на визуализираната информация и бизнес-смисъла от показването на точно време;

o Системата трябва да поддържа и всички формати съгласно ISO БДС 8601:2006.


75

7.2.5.3. Изисквания за използваемост на потребителския интерфейс Електронните форми за подаване на заявления и за обявяване на обстоятелства

трябва да бъдат реализирани с AJAX или с аналогична технология, като по този начин се гарантират следните функционалности:

o Контекстна валидация на въвежданите данни на ниво "поле" от форма и контекстни съобщения за грешка/невалидни данни в реално време;

o Възможност за избор на стойности от номенклатури чрез търсене в списък по част от дума (autocomplete) и визуализиране на записи, отговарящи на въведеното до момента, без да е необходимо пълните номенклатури да са заредени в браузъра на клиента и потребителят да скорлира дълги списъци с повече от 10 стойности;

В електронните форми трябва да бъде реализирана валидация на въвежданите от потребителите данни на ниво "поле" (in-line validation). Валидацията трябва да се извършва в реално време на сървъра, като при успешна валидация данните от съответното поле следва да бъдат запазени от сървъра;

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

Трябва да бъде реализирана възможност за добавяне и редактиране от страна на администраторите на системата, без да са необходими промени в изходния код, на контекстна помощна информация за:

o всяка електронна форма или стъпка от процес, за която има отделен екран/форма;

o всяка група полета за въвеждане на данни (в случаите, в които определени полета от формата са групирани тематично);

o всяко отделно поле за въвеждане на данни;

Трябва да бъде разработена контекстна помощна информация за всички процеси, екрани и електронни форми, включително ясни указания за попълване и разяснения за особеностите при попълване на различните групи полета или на отделни полета;

Контекстната помощна информация, указанията към потребителите и информативните текстове за всяка електронна административна услуга не трябва да съдържат акроними, имена и референции към нормативни документи,


76

които са въведени като обикновен текст (plain-text). Всички акроними, референции към нормативни документи, формуляри, изисквания и др. трябва да бъдат разработени като хипервръзки към съответните актуални версии на нормативни документи и/или към съответния речник/списък с акроними и термини;

Достъпът на потребителя до контекстната помощна информация трябва да бъде реализиран по унифициран и консистентен начин чрез подходящи навигационни елементи, като например чрез подходящо разположени микро-бутони с икони, разположени до/пред/след етикета на съответния елемент, за който се отнася контекстната помощ, или чрез обработка на "Mouse Hover/Mouse Over" събития;

При проектирането и реализацията на потребителския интерфейс трябва да се отчете, че той трябва да бъде еднакво използваем и от мобилни устройства (напр. таблети), които не разполагат с мишка, но имат чувствителни на допир екрани;

Потребителският интерфейс следва да бъде достъпен за хора с увреждания съгласно изискванията на чл. 48, ал. 5 от ЗОП.

7.2.5.4. Изисквания за използваемост в случаи на прекъснати бизнес процесиИзискванията на този раздел са неприложими. Системата не съхранява и не бива да съхранява данни от заявките или резултатите от услугите, а без тези данни не може да бъде възстановено изпълнението на прекъснат процес.

7.2.5.5. Изисквания за проактивно информиране на потребителите- НеприложимоСистемата не поддържа критерии и изисквания за проактивно информиране на потребителите и липсва необходимост от това .

7.2.6. Системен журналИзгражданото решение задължително трябва да осигурява проследимост на действията на всеки потребител (одит), както и версия на предишното състояние на данните, които той е променил в резултат на своите действия (системен журнал).

Атрибутите, които трябва да се запазват при всеки запис, трябва да включват като минимум следните данни:

дата/час на действието;

модул на системата, в който се извършва действието;

действие;

обект, над който е извършено действието;

допълнителна информация;

IP адрес и браузър на потребителя.


77

Размерът на журнала на потребителските действия нараства по време на работа на всяка система, което налага по-различното му третиране от гледна точка на организация на базата данни:

по време на работа на системата потребителският журнал трябва да се записва в специализиран компонент, който поддържа много бързо добавяне на записи; този подход се налага, за да не се забавя излишно работата на Системата;

специална фонова задача трябва да акумулира записаните данни и да ги организира в отделна специално предвидена за целта база данни, отделна от работната база данни на системата;

данните в специализираната база данни трябва да се архивират и изчистват, като в специализираната база данни трябва да бъде достъпна информация за не повече от 2 месеца назад; при необходимост от информация за предишен период администраторът на системата трябва първо да възстанови архивните данни;

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

7.2.7. Дизайн на бази данни и взаимодействие с тяхПри използване на база данни (релационна или нерелационна(NoSQL) следва да бъдат следвани добрите практики за дизайн и взаимоедйствие с базата данни, в т.ч.:

дизайнът на схемата на базата данни (ако има такава) трябва да бъде с максимално ниво на нормализация, освен ако това не би навредило сериозно на производителността;

базата данни трябва да може да оперира в клъстър; в определени случаи следва да бъде използван т.нар. sharding;

имената на таблиците и колоните трябва да следват унифицирана конвенция;

трябва да бъдат създадени индекси по определени колони, така че да се оптимизират най-често използваните заявки; създаването на индекс трябва да е мотивирано и подкрепено със замервания;

връзките между таблици трябва да са дефинирани чрез foreign key;

периодично трябва да бъде правен анализ на заявките, включително чрез EXPLAIN (при SQL бази данни), и да бъдат предприети мерки за оптимизиране на бавните такива;

задължително трябва да се използват транзакции, като нивото на изолация трябва да бъде мотивирано в предадената документация;

при операции върху много записи (batch) следва да се избягват дългопродължаващи транзакции;


78

заявките трябва да бъдат ограничени в броя записи, които връщат;

при използване на ORM или на друг слой на абстракция между приложението и базата данни, трябва да се минимизира броят на излишните заявки (т.нар. n+1 selects проблем);

при използване на нерелационна база данни трябва да се използват по-бързи и компактни протоколи за комуникация, ако такива са достъпни.

8 ИЗИСКВАНИЯ КЪМ ИЗПЪЛНЕНИЕТО НА ДЕЙНОСТИТЕ ПО ПРОЕКТА8.1 Дейност 1 Създаване на нови и актуализиране на съществуващи адаптери и

справки. Присъединяване на нови регистри и бази данни.8.1.1. Описание на дейносттаВ обхвата на Дейност 1 влизат следните поддейности:

Анализ и изготвяне на детайлна техническа спецификация за присъединяване на нов регистър, създаване на нов адаптер към този регистър, нова справка или промяната на съществуващ адаптер или справка от вече присъединен към ядрото на средата регистър;

Разработка на нов адаптер за достъп до регистър, нова справка или промяната на съществуващ адаптер или справка от вече присъединен към ядрото на средата регистър;

Инсталиране и конфигуриране на нов адаптер, нова справка или промяната на съществуващ адаптер или справка от вече присъединен към ядрото на средата регистър;

Одобряване на регистъра и справките от първичния администратор на регистъра/справките/данните;

Разработка/актуализация на шаблони на електронни форми за попълване на заявка и визуализиране на резултата от справките или въвеждане на информация от служител при липса на същата в електронен вид (налична на хартиен носител);

Актуализиране на мултитенант уеб приложението на ДАЕУ за достъп до услуги в Системата;

Актуализиране на публичното уеб приложение на ДАЕУ за достъп на граждани до услуги в Системата;

Провеждане на тестове в тестова среда;

Конфигуриране на ядрото на Системата в тестова и в продукционна среда на ЦД, чрез предоставяне на отдалечен достъп;

Актуализиране на информацията в информационния сайт на Системата с данни за присъединения регистър и неговите справки в Интернет, както и отразяване


79

на промените по съществуващата справка.Дейностите по актуализация/разработка се реализират при спазване на исискванията на стандарта, разработен по Дейност 2

8.1.2. Изисквания към изпълнение на дейносттаВ техническото предложение Изпълнителят следва да опише последователност от действия/стъпки, които ще бъдат извършени по отделните етапи на разработка. Участникът следва да опише начина на интеграция с хоризонталните системи и интеграционни слоеве, който е съотносим с целите на поръчката. Участникът следва да опише и обоснове технологичните средства, които ще използва за всеки от архитектурните слоеве, за да постигне параметрите на качество, описани в приложението на настоящата спецификация, като се съобрази с наличните инфраструктурни и технологични средства, описани в настоящата техническа спецификация.

Конкретните дейности се изпълняват по заявка от Възложителя, приложение към настоящата техническа спецификация, в съответствие с разработеният по Дейност 2 стандарт. Процесът по изготвянето, съгласуването и утвърждаването на заявката е детайлно описан в т. 5.7 от настоящата техническа спецификация.

В заявката се описват детайлно конкретните дейности за изпълнение от Изпълнителя, включително целта, обхватът, обемът, сроковете за изпълнение, необходимите ресурси (кадрови и финансови) и всички конкретни изисквания относно изпълнението на конкретната дейност.

8.1.3. Очаквани резултати Разширен набор от присъединени регистри;

Актуализиран набор с услуги за достъп до присъединени регистри;

Актуализирана техническа и експлоатационна документация на Системата.8.2 Дейност 2 Надграждане на системата за междурегистров обмен (RegiX)8.2.1. Описание на дейността

Дейност 2 включва:

Анализ по отношение на оптимизиране, както на вътрешните за интеграционната шина за обмен на удостоверителна и справочна информация процеси, така и по отношение на интеграцията с ресурсите на електронното управление, чрез използването на Интеграционната шина за достъп и управление на ИТ услуги и данни (реализирана чрез Enterprice Service Bus на IBM), последващо изготвяне на предложения за промени и последващото им прилагане;

Изготвяне на стандарт за разработване на адаптери, включващ конвенция за именуване, структура на адаптери, стандарт за описание на сървисите, чрез които си взаимодействат ядрото на системата с адаптерите и адаптерите с бази


80

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

Привеждане на разработените до момента адаптери към изискванията на разработените по горната точка стандарти;

Разширяване на функционалностите, свързани с взаимодействието с ресурсите на Електронното управление и хоризонталните системи, чрез Интеграционната шина за достъп и управление на ИТуслуги и данни, реализирана чрез Enterprice Service Bus на IBM;

Автоматизиране на процеса по актуализиране на информацията в информационния сайт на Системата с данни за присъединения регистър, справки, както и отразяване на промените по съществуващи адаптери и справки;Редизайн на всички съществуващи адаптери в съответствие със стандарта;

Добавяне на функционалност за полагане на електронен печат на съответния Първичен администратор на данни (ПАД) и електронен времеви печат към адаптерите, чрез които се осъществява достъп до регистрите;

Добавяне на функционалност за интеграция с PKI инфраструктурата на Електронното управление и защитени хранилища на криптографски ключове;

Доработване на всички съществуващи адаптери за достъп до регистрите, с добавяне на възможност за изготвяне на резултатите от услугите в преносим документен формат (pdf или docx) в съответствие със ЗЕДУУ;

Доработване на клиентските приложения за достъп до услугите на Системата, мултитенант и публично приложение за граждани, с добавяне на възможност за изготвяне на резултатите от услугите в преносим документен формат (pdf или docx) в съответствие със ЗЕДУУ;

Интеграция с журнала на събитията на Електронното управление за регистриране на събития, свързани с предоставените през Системата услуги;

Реализиране на асинхронни услуги за достъп до регистрите на ПАД, за предоставяне на услуги, които не могат да бъдат автоматизирани в реално време. Такива могат да бъдат услуги за извличане на данни (включително от хартиен носител), за които е необходима намесата на служител на ПАД, услуги за вписване на обстоятелства в регистър, за които е необходим преглед и валидация на данните, одобрение от упълномощено лице в съответния ПАД и др.;


81

Реализиране на функционалност за въвеждане в ръчен режим, чрез потребителски интерфейс на информация, съхранявана напълно или частично на хартиен носител и/или електронно, включително и в неструктуриран вид. Резултатът следва да бъде предоставен на заявителя като електронен документ;

Развитие на комплексна функционалност за проактивно наблюдение на работоспособността на ядрото, адаптерите и средата като цяло, в реално време, за осигуряване на навременна реакция при срив, отпадане на комуникацията, натоварване и извънредни ситуации, чрез събиране, обработка и анализиране на информация с цел осигуряване на проактивен контрол и вземане на решения за последващи действия, интеграция с наличните в ДАЕУ системи за проактивно наблюдение и контрол;

Реализиране на функционалности за наблюдение и контрол на регистрирани в системата сертификати на консуматори и ПАД, включително и за нотифициране за изтичане валидността им;

Интеграция с ЕПДЕАУ с цел предоставяне на специфична информация от системата за междурегистров обмен за всеки потребител с профил в „Моят egov.bg“.

8.2.2. Изисквания към изпълнение на дейносттаДоработките по дейност 2 трябва да обхванат, както следва:

Ядрото на Системата;

Приложението за администриране на Системата;

Мултитенант приложението за достъп до услуги, оперирано от ДАЕУ;

Публичното уеб-приложение на ДАЕУ за граждани, достъпно към момента през системата за електронно връчване;

Адаптерите и справките за достъп до всички присъединени регистри.Изпълнителят е необходимо при изпълнение на тази дейност да се съобразява със изискванията на т. 5.13 Методика и стандарти за разработване на софтуер.

В техническото предложение Изпълнителят следва да опише последователност от действия/стъпки, които ще бъдат извършени по отделните етапи на разработка. Участникът следва да опише начина на интеграция с хоризонталните системи и интеграционни слоеве, който е съотносим с целите на поръчката. Участникът следва да опише и обоснове технологичните средства, които ще използва за всеки от архитектурните слоеве, за да постигне параметрите на качество, описани в приложението на настоящата спецификация, като се съобрази с наличните инфраструктурни и технологични средства, описани в настоящата техническа спецификация.


82

Изпълнителят трябва да актуализира техническата и експлоатационна документация на Системата, както и информационния сайт на средата, за да отрази надградените функционалности и реализацията на удостоверителните услуги.

Разработката трябва да следва технологичната рамка използвана при разработването до момента на компонентите на Единния модел, спазвайки принципа на приемственост и устойчивост при развитието на компонентите на Единния модел, промени в технологичната рамка са принципно недопустими от Изпълнителя. Промени в технологичната рамка могат да бъдат разрешени в случай, че изпълнителят докаже в писмен анализ, че исканата промяна ще доведе до съществени ползи за подобряване на обслужването чрез Единния модел в частност и на електронното управление като цяло и няма да доведе до допълнителни разходи за Възложителя, както във фазата на разработка и внедряване, така и в последващата експлоатация. В отделен раздел в анализа се описва влиянието на исканата промяна върху другите компоненти на Единния модел. Анализът следва да бъде придружен и с проект на детайлен план за реализация на исканата промяна. Промените се допускат само след писмено одобряване от комисия на Възложителя и негово решение за въвеждане на промени в технологичната рамка на съответния компонент и планиране на евентуални промени в другите компоненти на Единния модел.

Изпълнителят е необходимо да се съобрази с технико-експлоатационна документация, която да предостави за съгласуване на Възложителя за всеки един етап. В долната таблица развитието (статуса) на документите (отчетните резултати) е проследено през дефинираните етапи на надграждане на компонент (интеграционната шина за обмен на удостоверителна и справочна информация, реализирана чрез Системата) на Единния модел, а именно:

Етап Планиране – обозначение (П);

Етап Детайлизиране – обозначение (Д);

Етап Изграждане – обозначение (И);

Етап Тестване – обозначение (Т);

Етап Внедряване – обозначение (В);

Етап Гаранционен период – обозначение (Г).Когато след символа П, Д, И, Т или В е поставена цифра (например Д1), тя означава поредния номер на итерацията от съответния етап.

За обозначаване на статуса на документите (отчетните резултати) през отделните етапи и итерации (ако са приложими) са използвани следните символи:

Обозначение Описание

P Документът се предоставя от Възложителя и Изпълнителят го актуализира (документът се предоставя за актуализация и развитие предвид предмета на договора)

E В процес на разработка (по резултата се работи)


83

S Приет (утвърден, подписан от възложителя)

R Ревизиран (актуализиран след приемане, при необходимост)

C Завършен (окончателен, документа не подлежи на по-нататъшна промяна)

Таблица 4 Отчетни резултатиОтчетен резултат П Д И Т В Г Описание

1. План за управление на проекта

s r r r c Планът представлява комплексен, интегриран резултат, в който е съсредоточена цялата информация, необходима за управлението на проекта. Той включва редица резултати, разработвани по време на етап Планиране, и се поддържа през целия жизнен цикъл на проекта.

В края на етапи Планиране, Детайлизиране, Изграждане и Тестване, при необходимост, се актуализира този план съгласно настъпилите промени.

2. План за управление на качеството

s r r c Това е резултат, който определя начините, по които ще се управлява качеството на продукта, резултатите и процесите. В Плана за качеството са посочени и редица други резултати, разработвани през етап Планиране. Планът за управление на качеството се поддържа през целия жизнен цикъл на проекта.

3. Списък на рисковете

s r r c R Структуриран списък на известните и реални рискове за проекта. Рисковете са подредени в низходящ ред на значимост и към всеки от тях са отнесени конкретни мерки за ограничаване на последствията или действия при непредвидени ситуации.


84

Отчетен резултат П Д И Т В Г Описание

4. Анализ по отношение на оптимизиране, както на вътрешните за интеграционната шина за обмен на удостоверителна и справочна информация процеси, така и по отношение на интеграцията с ресурсите на електронното управление, чрез използването на Интеграционната шина за достъп и управление на ИТ услуги и данни (реализирана чрез Enterprice Service Bus на IBM), последващо изготвяне на предложения за промени и последващото им прилагане

e e s Разработва се съгласно изискванията на Дейност 2


85


5. Стандарт за разработване на адаптери, включващ конвенция за именуване, структура на адаптери, стандарт за описание на сървисите, чрез които си взаимодействат ядрото на системата с адаптерите и адаптерите с бази данни.

e s Стандартът включва описание на оптимизиран процес по присъединяване на адаптер и неговата последваща автоматизирана интеграция с ядрото и публикуване в поддържаният от ядрото и клиентските приложения списък от адаптери, предоставяни чрез тях справки и информация за потребителите

6. Детайлен план за етап (итерация)

c c c c c В края на етапи Планиране, Детайлизиране и Изграждане Изпълнителят представя план с детайлна информация за следващия етап – съответно Детайлизиране, Изграждане, Тестване и Внедряване.

Планът с детайлна информация за всеки етап (итерация) подлежи на утвърждаване от ДАЕУ.

Включва всички дейности и резултати за конкретния етап (итерация), които са дефинирани последователно във времето и са обвързани със съответните ресурси.

В случай на прилагане на итерации планът за итерация N се предава в края на итерация N-1.

7. Речник e r r c R В Речника се дефинират всички важни термини и съкращения, използвани за целите на проекта в отчетните резултати по настоящата таблица.


86


8. Системен проект е s R c R Системен проект за реализация на изискванията на Възложителя: Модел и описание на бизнес процесите; Модел и описание на случаите на употреба; Прототип на потребителския интерфейс; Логически и физически модел на данните; Техническа (софтуерна и инфраструктурна) архитектура

9. Завършена система s C R Програмният продукт, готов за започване на потребителски тестове, в това число и Source code.

10. Тестов модел s r R c R Включва информация за това какво ще бъде тествано (видовете тестове – функционален, за производителност и т.н.) и как ще се тества. Той представлява разрез на моделите на бизнес процесите, на дизайна и имплементацията, с който са описани самите тестове и тези аспекти на тестваните резултати, които са от значение за тестовия процес.

Тестовият модел включва набор от тестови случаи, тестови процедури и тестови скриптове, както и описание на очакваните резултати от тестовете и на взаимовръзките помежду им. Трябва да съдържа също таблици на съответствието бизнес процеси – системни потребителски случаи – компоненти на системата - тестови случаи и тестови сценарии.

Таблиците на съответствието се поддържат в актуално състояние през целия период на изпълнение на проекта.


87


11. План за тестване e s C Документът съдържа времеви график за изпълнение на дейностите, описани в тестовия модел.

12. Резултати от тестовете при Изпълнителя

C Документът съдържа резултатите от всички изискуеми тестове, проведени при Изпълнителя.

13. План за внедряване в продукционна среда

s C Целта на този документ е да определи необходимите ресурси и пълния набор от дейности, които трябва да бъдат извършени, за да бъде инсталиран и пуснат в реална експлоатация съответния компонент на Единния модел. Документът трябва да съдържа и времеви график за изпълнение на тези дейности..

14. Документация за ползване - материали за инсталиране, администриране и поддръжка

e s C R Пакетът включва минимум софтуера и документираните инструкции (и скриптове) за генериране на версии от програмния код, Ръководство за инсталация и конфигурация, Ръководство за администратора, Регистър на конфигурационните единици за компонента на Единния модел. При наличие на конфигурационни параметри в базата данни, същите се вписват в регистъра и др.

Пакетът следва да включва и набор от инструкции за обслужване и осигуряване на работоспособността на системата, предназначени за екипите от 1 и 2-ро ниво на Центъра за обслужване на потребители на Единния модел.


88


15. План за обучение c Планът за обучение описва набора от всички дейности по обучение на всички потребители на Системата.

Планът за обучение трябва да съдържа минимум следните реквизити:

списък на всички необходими ресурси за организация и провеждане на обучението

места за провеждане на обучението

времеви график

Обучението трябва да бъде предвидено за два типа потребители на системата:

- крайни потребители (консуматори и ПАД)

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

16. Материали за обучение

c R Това са материали, които се използват при провеждането на курсове или програми за обучение, предназначени да подпомогнат ДАЕУ и крайните потребители при използването, експлоатацията и/или обслужването на Системата.

Материалите се привеждат в завършен вид така, че да бъдат използвани самостоятелно.


89


17. Споразумение за нивото на предоставяните услуги от Изпълнителя по време на гаранционния период. (SLAgp)

s c R В документа се описва подробно организацията на поддръжката по време на гаранционния период на надградената функционалност на Системата.

18. Споразумение за нивото на предоставяните услуги от страна на ДАЕУ към потребителите на съответния компонент на Единния модел. (SLApm)

s c R В документа се описва нивото на предоставяни услуги от ДАЕУ към потребителите на Системата.

19. Доклад за гаранционна поддръжка

e S Структурата на доклада се приема на етап Внедряване. Такъв доклад се предава на всеки три месеца през периода на гаранционната поддръжка, който отразява моментното състояние на изпълнение на гаранционната поддръжка. В края на гаранционния период се предава и приема от ДАЕУ окончателен доклад за гаранционната поддръжка, като към него се предават документите, описани в настоящата таблица, независимо дали по тях е имало или не промени в рамките на гаранционния период.

При необходимост от допълнителни документи, представянето на които се налага в следствие на техническото предложение на участника (анализи, доклади, проучвания, концепции, визии, план за мигриране на стари данни и т.н.), е допустимо участникът да ги опише в горната таблица и задължително посочва статуса им в отделните етапи (итерации).


90

Отчетните резултати се изготвят на български език. Изпълнителят предава отчетните резултати на Възложителя в края на всеки етап в един екземпляр на хартия и в един екземпляр на електронен носител, включително документи, модели, програмен и изпълним код. Заедно с отчетните резултати се представя опис, съгласно Таблица 5 Опис наотчетните резултати.

Таблица 5 Опис на отчетните резултатиНаименование

на отчетния резултат

Описание Директория Име на файл Брой страници

<В съответствие с настоящата документация >

<Описание с 1 изречение на съдържанието на отчетния резултат>

<Име на папката, в която е/ са файловете/ под-папките за конкретния отчетен резултат>

<Път до име/ имена на файловете>

<Само за разпечатани материали>

Отчетните резултати са придружени с официално писмо на хартия, които се внасят в деловодството на ДАЕУ.

Цялата документация, предадена от Изпълнителя трябва да бъде във файлове, позволяващи тяхната обработка и корекция (напр. doc, xls и др.).

В срок до 5 (пет) работни дни от получаване на отчетните резултати от Изпълнителя в края на етап Планиране, Възложителят трябва да го уведоми за становището си по тях, като поиска промени по тях или като посочи причини в случай, че не ги одобрява. В срок до 5 (пет) работни дни Изпълнителят трябва да отрази становището на Възложителя по отчетните резултати и да предаде нова версия на отчетните резултати.

В срок до 5 (пет) работни дни отчетните резултати се разглеждат от комисия на Възложителя , който може да вземе следните решения: „приема отчетните резултати“ или „не приема отчетните резултати“.

В срок до 10 (десет) работни дни от получаване на отчетните резултати от Изпълнителя в края на етап Детайлизиране, Възложителят трябва да го уведоми за становището си по тях, като поиска промени по тях или като посочи причини, в случай че не ги одобрява. В срок до 5 (пет) работни дни Изпълнителят трябва да отрази становището на Възложителя по отчетните резултати и да предаде нова версия на отчетните резултати.

В срок до 5 (пет) работни дни отчетните продукти се разглеждат от комисия на Възложителя, който може да вземе следните решения: „приема отчетните продукти“ или „не приема отчетните продукти“.


91

В срок до 5 (пет) работни дни от получаване на отчетните резултати от Изпълнителя в края на етап Изграждане, Възложителят трябва да го уведоми за становището си по тях, като поиска промени по тях или като посочи причини, в случай че не ги одобрява. В срок до 5 (пет) работни дни Изпълнителят трябва да отрази становището на Възложителя по отчетните резултати и да предаде нова версия на отчетните резултати.

В срок до 5 (пет) работни дни отчетните резултати се разглеждат от комисия на Възложителя, който може да вземе следните решения: „приема отчетните резултати“ или „не приема отчетните резултати“.

Продължителността на етап Тестване е не по-малка от 45 (четиридесет и пет) календарни дни. След приключване на етап Тестване и предаване на отчетните резулатати от Изпълнителя, в срок до 5 (пет) работни дни, Възложителят трябва да го уведоми за становището си по тях, като поиска промени по тях или като посочи причини, в случай че не ги одобрява. В срок до 5 (пет) работни дни Изпълнителят трябва да отрази становището на Възложителя по отчетните резулатати и да предаде нова версия на отчетните резулатати.

В срок до 5 (пет) работни дни отчетните резулатати се разглеждат от комисия на Възложителя, който може да вземе следните решения: „приема отчетните резултати“ или „не приема отчетните резултати“.

Етап „Внедряване“ не може да започне преди да е завършил и приет от Възложителя етап Тестване.

В срок до 5 (пет) работни дни от получаване на отчетните резултати от Изпълнителя в края на етап Внедряване, Възложителят трябва да го уведоми за становището си по тях, като поиска промени по тях или като посочи причини, в случай че не ги одобрява. В срок до 5 (пет) работни дни Изпълнителят трябва да отрази становището на Възложителя по отчетните резултати и да предаде нова версия на отчетните резултати.

В срок до 5 (пет) работни дни отчетните резултати се разглеждат от комисия на Възложителя, който може да вземе следните решения: „приема отчетните резултати“ или „не приема отчетните резултати“.

При изтичане на гаранционния срок се предава актуализирана версия на Системата и свързаните с нея документи и модели, в които са отразени всички корективни дейности, извършени от Изпълнителя в рамките на гаранционния период.

8.2.3. Очаквани резултати Реализирани електронни удостоверителни услуги с правна стойност на

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

Надградени функционалности за наблюдение на адаптерите за достъп до присъединени регистри и средата като цяло, за да се осигури навременна реакция при сривове, отпадания на комуникацията, натоварвания и извънредни


92

ситуации както и създаване на универсални адаптери;

Обучени служители на ДАЕУ и засегнатите администрации за администриране, наблюдение, обслужване и експлоатация на доставения софтуер;

Изготвена/актуализирана техническа и експлоатационна документация на доставените софтуерни решения.

8.3 Дейност 3 Гарантиране на работоспособността и нормалното функциониране на Системата при удостоверяване на вписани в регистри на централната администрация обстоятелства

8.3.1. Описание на дейносттаДейността включва:

Участие в екипите на второ и трето ниво на Центъра за обслужване на потребители на Единния модел, като в рамките на компетентността си изпълнява:

o Предприема на всички необходими действия, за разрешаване на назначената му заявка;

o Възпроизвежда, анализира и разрешава назначената му заявка, включително създаване на временен процес на работа при невъзможност за отстраняване на инцидента в параметрите на качеството, посочени в приложението към настоящата техническа спецификация;

o При необходимост назначава нови операции към заявка - в случай, че е необходимо извършване на действия и от други екипи от второ ниво, или заявката да бъде ескалирана към трето ниво и проследява прогреса на изпълнението ѝ до намиране на решение;

o Проактивно изследва събития с цел откриване на проблеми – коренната причина за възникването на инцидентите;

o Следи цялостния процес на развитие на заявката до постигане на решението ѝ;

o Наблюдава детайлите на инцидента, включително засегнатите други компоненти на Единния модел;

o При необходимост докладва за установени проблеми в системата за управление на инциденти на Възложителя;

o Прави предложения до Възложителя за промени , свързани с решаването на регистрирани проблеми;

o Допринася за качественото и безпроблемно функциониране на Центъра.

Управление на профили на потребители (създаване, промяна, деактивиране);

Промяна в конфигурационни параметри на системата;Документация за участие в обществена поръчка с предмет:


93

Оказване на съдействие на Възложителя при:

o Инсталация и оптимизация, включващи: Наблюдение на основни параметри. Оптимизация на отделните

елементи; Инсталация на разработени нови под-версии, пачове и други на

системата и на използвани средства за разработка; Поддръжка и настройка на системата при въвеждане на нови версии

или пачове на операционната система, базата от данни и сървъра за работа на приложението или при доставка на ново оборудване (хардуер и системен софтуер);

o Използване на административните модули и други специфични части на системата – интерфейси, електронни услуги, съпоставки между базата данни на информационните системи с данни от други системи, налични при Възложителя.

o Контрол на версиите на приложния софтуер. Контролът на версиите се осъществява чрез специализиран софтуер на Изпълнителя. Използваният софтуер ще бъде уточнен в рамките на етап Планиране.

При възникнала необходимост или при поискване от страна на Възложителя:

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

o изготвяне на доклади с конкретни препоръки по отношение на дизайна, консистентността, натовареността и оптимизацията на базата данни.

Съдействие на екипа на Възложителя при създаването, наблюдението и управлението на системната среда на системата, при:

o Анализ и оптимизация на системната среда;

o Конфигурирането на параметрите на клиентските работни станции с оглед осигуряване на безпроблемен достъп до системата и работа на потребителите с нея;

o Осигуряване на достъп до системата от крайните потребители по защитен канал;

o Управление на сигурността на системата и данните;

o Осигуряване на работа на системата върху и с последните нови версии на софтуер от системната и приложна среда на системата;

o Дейности по ниво 3 на Центъра за обслужване на потребители на Единния модел.

Съдействие на екипа на Възложителя при настройка, поддръжка и Документация за участие в обществена поръчка с предмет:


94

оптимизация на базата данни на системата (ако е приложимо), включващо:

o Наблюдение на производителността и оптимизиране на базата данни, индекси и изпълнявани операции;

o наблюдение и диагностика на сървърите на базата данни и грешките при работа на СУБД и оказване на съдействие на Възложителя при необходимост от решаване на възникнали проблеми;

o създаване и управление (вкл. нормализация) на таблици, процедури на ниво база данни (stored procedures) и изгледи (views) съвместно с Възложителя;

o проверка за нарушаване на консистентността на базата данни и решаване на възникнали проблеми съвместно с Възложителя, изготвяне и актуализиране на политика за създаване и актуализация на статистики на базата данни.

o преглед на дизайна на базата данни и изготвяне на препоръки за нейната оптимизация и модификация;

o наблюдение и почистване на базата данни от невалидни и неизползваеми обекти.

o възстановяване на базата данни след настъпили критични и аварийни ситуации;

o извършване на профилактика на базата данни, чрез тестване на системата на определен период от време не по-дълъг от три месеца при различни параметри и натоварвания;

Анализ на подадените от екипите на Възложителя данни от мониторинга на функционирането на системата и производителността (статистически файлове, грешки в работата на съответния компонент на Единния модел и др.). В резултат от направения анализ, Изпълнителят е длъжен:

o При нарушена производителност в работата на системата, дължаща се на неправилното й функциониране, софтуерни грешки или проблеми с базите данни, да предприеме незабавни действия за нейното нормализиране;

o Съобразно заложените параметри на качеството на обслужване в приложението към настоящата спецификация, да предприеме корективни действия в системата, включително когато анализът на грешките показва проблеми във функционирането й, породени от недостатъчно добра интеграция в инфраструктурата на Възложителя;

o Когато необходимите промени излизат извън задълженията на Изпълнителя по осъществяването на гарантиране на работоспособността, да предостави в писмен вид обосновка и препоръки към Възложителя за предприемане на действия, свързани с подобряване работоспособността на системата,


95

разработване и конфигуриране на инструменти за мониторинг на функционалността и други;

o В случаите, когато данните от мониторинга не са достатъчни за анализ или данните не могат да бъдат предоставени отдалечено по обективни причини, Изпълнителят да предостави дейностите в офиса на Възложителя.

Дейностите по гарантиране на работоспособността включват корективни действия за осигуряване на нормалната работоспособност на системата. Извършват се при възникване на проблем във функционирането на системата или при постъпила заявка от страна на Възложителя и включват:

o Възстановяване на системата при пълна или частична неработоспособност в следствие на инцидент/проблем, съгласно времената заложени в приложение 3а към настоящата спецификация.,;

o Възстановяване и коригиране на информация при неправилна работа със системата или при неправилна работа на същата, включително с директна намеса в сорса и базите данни в случаите, когато с вградените му софтуерните инструменти не може да се извърши възстановяването или корекцията.

o Преинсталиране на системата при необходимост;

o Конфигуриране – промени в конфигурацията на място при Възложителя;

o Предоставяне на Възложителя на пачове, актуализации, специални версии и нови версии веднага, след като са налични. Всеки пач, актуализация, специална и нова версия задължително се придружава с документ, описващ отстранените грешки, извършените промени в софтуера и интерфейсите с други системи (release notes), препоръки за конфигурирането на параметрите на системната среда и персоналните компютри на потребителите като при необходимост се извършва конфигуриране на място. В случай на извършени промени се актуализира ръководството на потребителя, описващо начина на използване на актуализираната функционалност. Изпълнителят следва да гарантира, че всички пачове, актуализации, специални и нови версии са предварително тествани и изчистени от грешки преди въвеждането им в ИТ инфраструктурите на Възложителя;

o Отстраняване на открити грешки в работата на системата;

o Извършване на дейности, свързани с настройки, консистентност и оптимизация на базата данни, съвместно с екипа на Възложителя;

o Изготвяне на справки по искане на Възложителя, свързани с


96

функционирането на системата;

o Актуализиране на функционалната и техническата документация, включително ръководствата за администратора и потребителите и сорс-кодовете на системата с означена нова версия при извършени промени в софтуера и базата данни;

o Трансфер на знания към екипите на Възложителя. При изпълнението на тази група дейности Изпълнителят следва да: Организира поне веднъж на три месеца сесии за трансфер на знания по

предложена от Изпълнителя и съгласувана с Възложителя програма, включваща преглед на промените в системата.

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

o Оказване помощ на потребителите при работа със системата, в т.ч. консултации на място, по телефон, електронна поща (e-mail) или др.;

o Оказване съдействие на Възложителя при изготвяне/актуализиране на организационни правила, процедури и други документи, свързани с използването на системата;

o Провеждане на обучения на място при Възложителя за работа със системата и изготвяне на обучителни материали. Време за изпълнение – според естеството на обучението и броя на обучаваните;

o Участие при въвеждане на промените на системата в тестова и/или продуктивна среда и провеждане на тестовите изпитания.

Усъвършенстване на системата в рамките на разработената функционалност:

o Актуализиране на документи, номенклатури, списъци, чек-листи, справки, декларации, удостоверения, писма, отчети и др. по искане на Възложителя поради настъпили промени в нормативната уредба, в работни процеси, процедури, организационни промени и извършване на всички необходими актуализации в базата данни и функционалностите на Системата, в рамките на съществуващата функционалност Актуализирането се извършва до 5 (пет) дни от поискването им;

o Актуализиране и промени в Системата, базата данни и интерфейсите към други системи във връзка с настъпили нормативни промени, промени в работни процеси, процедури, организационни промени в рамките на съществуващата функционалност. Промените се извършват в срок


97

съгласуван между страните, но не повече от 30 (тридесет) дни;

o Унифициране на етикети на полета, формат на визуализираната информация, наименование на данните/информацията в справочната част и използвана терминология в съответния компонент на Единния модел до 5 (пет) дни от поискването им.

o Развитие на съществуващите процеси, функционалности и валидации в съответния компонент на Единния модел за обработка на информацията и данните в срок съгласуван с Възложителя, но не по дълъг от 30 (тридесет) дни от поискването им.

o Реализация на подобрения или разширения в справочните части или в оперативните модули - в частта им за извеждане (визуализация) на данни и допълнителна информация. Сроковете за Реализация на поисканите подобрения/разширения е до 15 (петнаседет) дни от поискването им, по график, съгласуван с Възложителя.

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

o Развитие на възможността за добавяне и съхраняване на историята на извършените действия от потребителите на Системата в системен журнал, достъпен през потребителски интерфейс.

o Развитие на съществуващи интерфейси на Системата за обмен на информация между Системата и останалите системи на Възложителя и между Системата и външни за Възложителя информационни системи, извън предоставяните чрез адаптерите за връзка с регистри/бази данни на ПАД и ядрото на Системата. Сроковете за развитие на всеки интерфейс е до 15 (петнадесет) дни от заявяването му.

8.3.2. Изисквания към изпълнение на дейносттаГарантирането на работоспособността на Системата се извършва в режим 24х7х365, като изпълнителят следва да предложи адекватна схема на работа на служителите си за покриване на заявки за обслужване на инциденти на второ и трето ниво на Центъра за обслужване на потребителите на Единния модел при спазване на параметрите на качеството на обслужване в приложението към настоящата техническа спецификация.

Ангажиментите на служителите на Изпълнителя по отношение на Центъра за обслужване на потребители на Единния модел са детайлно описани в приложението към настоящата спецификация частта й за ниво 2 и 3 и т. 5.9 Управление на инциденти и проблеми на настоящата техническа спецификация. Служителите на Изпълнителя, участващи в ниво 2 и 3 са функционално подчинени на Ръководителя на ниво 2 и съответно 3 на Центъра за обслужване на потребители на Единния модел. Конкретните процедури на взаимодействие


98

на екипа на Изпълнителя с екипите на Възложителя ще се уточнят в рамките на фаза Стартиране.

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

Изпълнението на дейността трябва да е съобразена с Процедурата за управление на промените т.5.8.

В допълнение към горното и за да се приеме, че изпълнението е с необходимото ниво на качество за тази дейност трябва да са изпълнени (постигнати) комулативно и следните параметри:

съотношение между предадени и внедрени версии на Системата, не по-голямо от 3:2 (предадени:внедрени) версии;

не повече от 5% повторно отворени инциденти;

не повече от 10% прекъснати или грешни по време на инсталирането версии/под-версии.

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

8.4 Дейност 4 Консултантски услуги8.4.1. Описание на дейносттаДейността включва:

Изготвяне на технически становища, анализи и спецификации, инструкции, процедури, указания, помощни материали и др.;

Подпомагане на Възложителя при дефиниране на функционални изисквания към нови или усъвършенствани приложения, включително и дефиниране на интерфейси за връзка между компонентите на системите;

Участие при планирането, проектирането, внедряването и развитието на функционалности и регистри от гледна точка на осигуряване на оперативната им съвместимост и нормалната им работа в обща архитектурна среда или съществуващата експлоатационна среда на Възложителя;

Анализ и обработка на данни в различни файлови формати; Различни форми за обучение на потребителите; Участие в: оценка на проекти, задания, тестване или внедряване на приложни

системи; Услуги, свързани с информационна сигурност и защита на данните:

o Изготвяне на нови и актуализиране на съществуващи документи по сигурността и управлението на риска;


99

o Оценка на текущо ниво на риска, развитие на архитектура за сигурност, изготвяне на предложения за гарантиране на сигурността и прилагане на решения за управление на риска съгласно действащата нормативна уредба и най-добрите практики;

o Наблюдение и оценка на организацията, схемите, процедурите и инструментите по сигурността;

o Поддържане и предоставяне на информация за конкретни количествени и качествени характеристики на нивото на сигурност за всяка една информационна система и/или регистър;

Други.

8.4.2. Изисквания към изпълнение на дейносттаВъзлагането на консултантските услуги става с писмена заявка . В нея се описват: обхватът, обемът, сроковете за изпълнение, необходимите ресурси (кадрови и финансови) и всички изисквания относно предоставянето й.

8.4.3. Очаквани резултатиОсигурени необходимия брой консултантски услуги на Възложителя и необходимата документация.

9 ДОКУМЕНТАЦИЯ9.1 Изисквания към документацията

Цялата документация и всички технически описания, ръководства за работа, администриране и поддръжка на Системата, включително и на нейните съставни части, трябва да бъдат налични и на български език;

Всички документи трябва да бъдат предоставени от Изпълнителя в електронен формат (ODF/ /Office Open XML/MS Word DOC/RTF/PDF/HTML или др.), позволяващ пълнотекстово търсене/търсене по ключови думи и копиране на части от съдържанието от оригиналните документи във външни документи, за вътрешна употреба на възложителя;

Навсякъде, където в документацията има включени диаграми или графики, те трябва да бъдат вградени в документите в оригиналния си векторен формат;

Детайлна техническа документация на програмния приложен интерфейс (API), включително за поддържаните уебуслуги, команди, структури от данни и др. Документацията да бъде придружена и с примерен програмен код и/или библиотеки (SDK) за реализиране на интеграция с външни системи, разработен(и) на Java или .NET. Примерният код трябва да е напълно работоспособен и да демонстрира базови итерации с API-то:

o Регистриране на крайна точка (end-point) за получаване на актуализации от Системата в реално време;

o Заявки за получаване на номенклатурни данни (списъци, таксономии);Документация за участие в обществена поръчка с предмет:


100

o Заявки за актуализиране на номенклатурни данни (списъци, таксономии);

o Регистрация на потребител;

o Идентификация и оторизация на потребител или уебуслуга.

9.2 Прозрачност и отчетностВ обхвата на проекта е включено извършване на дейности по анализ на бизнес процеси и нормативна уредба, проектиране на системна и приложна архитектура, разработване на компютърни програми и други дейности, свързани с предоставяне на специализирани професионални услуги. Изпълнителят и Възложителят трябва да публикуват подробни месечни отчети в машинночетим отворен формат за извършените дейности, включително количеството изработени човекодни по дейности, извършени от консултанти, експерти, специалисти и служители на Изпълнителя и Възложителя.

Документацията, предоставена от Изпълнителя на Възложителя, трябва да бъде:

на български език; на хартия и в електронен формат; копирането и редактирането на предоставените

документи следва да бъде лесно осъществимо; актуализирана в съответствие със съгласувана с Възложителя процедура, която

следва да включва документи, подлежащи на промяна/актуализация, крайни срокове и нужната за случая методология.

9.3 Системен проектИзпълнителят на настоящата поръчка трябва да дефинира в детайли конкретния обхват на реализация на софтуерната разработка и да документира изискванията към софтуера в детайлна техническа спецификация (системен проект), която ще послужи за пряка изходна база за разработка.

При документирането на изискванията, с цел постигане на яснота и стандартизация на документите, е необходимо да се използва утвърдена нотация за описание на бизнес модели. Изготвената детайлна техническа спецификация (системен проект) се представя за одобрение на Възложителя. В случай на забележки, корекции или допълнения от страна на Възложителя Изпълнителят е длъжен да ги отрази в детайлната техническа спецификация (системен проект).

9.4 Техническа документацияПрез фаза Стартиране Възложителят осигурява наличната при него документация по предмета на договора. При необходимост от допълнителна документация Изпълнителят я осигурява за своя сметка без това да влияе на сроковете и качеството на изпълнение.

Всички резултати, които ще се доставят, трябва да са със специфична документация за инсталиране и/или техническа документация, в това число:

Ръководство за администратора, включващо всички необходими процедури и скриптове по инсталиране, конфигуриране, архивиране, възстановяване и други, необходими за администриране на Системата;


101

Документи за крайния ползвател – Изпълнителят трябва да предостави главното Ръководство на ползвателите на софтуера. Документът е предназначен за крайните ползватели. Той трябва да описва цялостната функционалност на приложния софтуер и съответното му използване от крайни ползватели;

Детайлно описание на базата данни; Описание на софтуерните модули; Описание на изходния програмен код.

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

Отчетният резултати може да бъде модел, елемент на модел, документ или софтуер, включително отчетните резултати по етапите на разработка и междинните доклади.

Конкретните изисквания към вида и съдържанието на отчетните резултати (конкретен списък по етапи и под-етапи) се посочи в настоящата техническа спецификация, като в същото се отбелязва кой отчетен резултат в какво ниво на завършеност следва да бъде през етапите на разработка и конкретните изисквания за предоставяне и приемане на отчетните резултати.

При заявена от Възложителя необходимост, при предоставяне на коригираща или нова версия на Системата по време на изпълнение на договора, Изпълнителят се задължава да предостави на Възложителя на технически носител актуални версии на техническата документация, както за реализираната функционалност, така и за интегрираната среда, като минимум съдържащи следното:

Последната актуална версия на пълния изходен програмен код (Source code), задължително включващ коментари, описания и документация на използваните класове, процедури, функции, методи и пр.;

Пакет с новата версия на изпълнимия код. Той следва да бъде предварително тестван и да позволява инсталиране в тестова и експлоатационна среда на Възложителя. Дистрибутивният пакет следва да съдържа скриптове и инструкции за инсталиране и инициализиране.;

Актуализирана документация на системата, в съответствие с извършените промени – функционална и техническа спецификация на приложния софтуер; архитектурата на приложния софтуер; Пълно описание на базите данни, техните обекти и взаимовръзките между тях, конфигурационните файлове на базите данни; Инструкция за инсталиране и конфигуриране, включително инсталационни пакети; Ръководство на потребителя; Ръководство на администратора; Регистър на направените промени; Описание на направените промени (release notes) и др. За всеки един документ по тази точка следва да се поддържа версия и кратко описание на промените, извършени в него спрямо предходните версии.


102

Възложителят може да поиска да му бъдат предадени описаните пакети документи във всеки момент от изпълнението на договора, като Изпълнителят е длъжен да ги предостави в указания от Възложителя срок.

9.5 ПротоколиИзпълнителят трябва да изготвя протоколи от изпълнението на различните етапи на проекта, описани в раздел 6 на настоящия документ, заедно със съпътстващите ги документи – резултати от изпълнението на етапите.

Изпълнителят е длъжен да осигури за своя сметка протоколиране на всички срещи в рамките на договора. Образец на протокол от среща ще бъде предоставен от Възложителя в рамките на фаза Стартиране, включително и образец на присъствен лист на участниците в срещата.

Протоколите от срещи на представители на Възложителя и Изпълнителя се изготвят от представител на Изпълнителя за негова сметка и в указаните в настоящата техническа спецификация срокове.

Протоколът се изготвя до 2 (два) работни дни след срещата и се разпространява до всички участници в срещата, с копие до РД от двете страни и РГД от страна на Изпълнителя.

В срок от 3 (три) работни дни участниците в среща могат да изпратят корекции на протокола от срещата. В случай на коригиране на протокол, той отново се изпраща до всички участници. Ако не се поиска корекция до указания срок, се смята, че всички участници в срещата са съгласни с така изготвения протокол, след което го подписват.

Оригиналите на протоколите се съхраняват в ДИСОС.

9.6 Комуникация и докладиДиректорът на ДИСОС и Ръководителят на договора от страна на Възложителя имат право да поискат подробна справка от Изпълнителя за изпълнените дейности, респективно изразходваните ресурси за дейност.

Ръководителите на дейности от страна на Изпълнителя са длъжни стриктно да управляват разхода на човешкия си ресурс, както и съответния бюджет, така че бързо и лесно да предоставят такава справка при поискване.

За изпълнението на всяка дейност Изпълнителят определя поне един служител, който отговаря за управление на качеството му и контрол на изпълнението на параметрите на качеството, съгласно техническата спецификация.

Кореспонденция между страните в хода на изпълнението

Кореспонденцията между страните се извършва, съгласно посоченото в договора и изискванията на настоящата техническа спецификация.

По оперативни въпроси, свързани с възлагането, изпълнението и отчитането на дейностите в обхвата на договора, кореспонденцията се подписва от Ръководителите на договори от


103

двете страни, с копие до Директора на ДИСОС, освен ако в техническата спецификация за възлагане не е предвидено друго.

За разпространението на информацията между участниците в изпълнението и другите заинтересовани лица ще бъдат използвани следните комуникационни средства:

Електронна поща – e-mail кореспонденцията ще бъде използвана за ежедневна комуникация и разпространение на информация. Този канал за комуникация ще бъде използван за разпространение на оперативни документи. Документи, изискващи одобрение, се изпращат първо по електронна поща за съгласуване с другата страна, след което се разпечатват на хартия и се подписват. Чрез електронна поща се насрочват и срещите по дейности, независимо от техния характер;

Системата за сигурно електронно връчване (еВръчване) – ще се използва за кореспонденция, във връзка с която възникват задължения за страните.

Система за управление на инциденти- ще се използва за кореспонденция, свързана с процеса по управление на инциденти;

Система на управление на промени - ще се използва за кореспонденция, свързана със заявяване, запознаване, одобряване и прилагане на промени ;

Технически носител- за записване на актуална версия на техническата документация, както за реализираната функционалност, така и за интегрираната среда, описани в общите изисквания за документация в настоящата спецификация;

Хартиен носител – на хартиен носител ще бъдат разпечатвани и разпространявани документите, които са резултати от изпълнението на договора и такива, които изискват одобрение: доклади, планове, протоколи, спецификации и др.;

Телефон;

Факс.Работни срещи между представители на Изпълнителя и Възложителя се провеждат при възникнала необходимост.

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

За срещите се съставят протоколи от Изпълнителя в сроковете съгласно настоящата техническа спецификация. Протоколите се подписват от всички участници в срещите (когато е приложимо).

За осигуряване ефикасно изпълнение на Договора, се предвижда провеждането на посочените в Таблица 6 Видове регулярни срещи.


104

Таблица 6 Видове регулярни срещи


105

Тип Участници Срещи Входна информация

Изходен резултат

Отговорности

Среща на СОУ

Председателя и членовете на СОУСпециално поканени участници или заинтересовани лица.

Веднъж месечно

Планове на съответните договори, , свързани с дейности по функционирането на Единния модел за заявяване, заплащане и предоставяне на електронни административни услуги въпроси, ескалирани в рамките на изпълнението на дейностите;

Актуализирани планове, въпроси за ръководството на ДАЕУ;Протокол от среща

Следи напредъка по групи дейности.Идентифицира проблеми и набелязва мерки за разрешаването им.В случай на необходимост координира и синхронизира съвместни дейности с други изпълнителски екипи.Актуализира списъка с рисковете, при необходимост.

Експертни срещи

Експерти с необходимата компетентност по темите от дневния ред;Представители на други изпълнителски екипи;Специално поканени

Според Детайлния план за изпълнение или при необходимост

Материали за срещата в зависимост от дневния ред на срещата.

Протокол от среща и други материали, ако е приложимо

Изпълнение на дейностите от обхвата на съответната га дейност.


106

За успешното изпълнение на проекта участниците в настоящата обществена поръчка трябва да предложат адекватен механизъм за управление на проектната комуникация, който е неразделна част от предлаганата цялостна проектна методология.

Докладите се изпращат до отговорния служител на Възложителя. За тази цел Възложителят ще определи в договора отговорния/отговорните служител/служители. Всички доклади се представят на български език в електронен формат и на хартиен носител. Докладите се одобряват от отговорния/отговорните служител/служители в срок до 5 работни дни.

Всички доклади трябва да се представят на възложителя на български език на хартиен и на електронен носител. Представянето на докладите трябва да се извършва чрез подписване на двустранни предавателно-приемателни протоколи, подписани от представители на Изпълнителя и на Възложителя.

Възложителят разглежда представените доклади и уведомява Изпълнителя за приемането им без забележки или ги връща за преработване, допълване и/или окомплектоване, ако не отговарят на изискванията, като чрез упълномощено в договора лице дава указания и определя срок за отстраняване на констатираните недостатъци и пропуски.

Управлението на комуникацията трябва да включва изготвяне на минимум следните регулярни доклади за статуса и напредъка на изпълнението на поръчката:

Встъпителен доклад

Встъпителният доклад трябва да бъде предоставен в рамките на фаза Стартиране и да съдържа описание минимум на:

Подробен работен план и актуализиран времеви график за периода на проекта; Начини на комуникация; Отговорни лица и екипи.

Встъпителният доклад следва да бъде одобрен от Възложителя.

Междинни доклади

Междинните доклади са нарочни и месечни.

Месечни доклади

Изпълнителят трябва да предоставя на Възложителя месечни доклади в края на всеки календарен месец по време на изпълнение на договора. Месечните доклади трябва да съдържат информация относно изпълнението на дейностите, съгласно плана за изпълнение, включително:

Управленско резюме;

За всяка дейност:

o Описание на извършената работа по дейността. Прилагат се резултати от измерването на метриките за качество;


107

o Постигнати резултати, като се опишат чрез заложените и постигнатите индикатори;

o Възникнали проблеми, включително забавяния или отлагане изпълнението на дейности, причини, поради които са възникнали и какви мерки са предприети за преодоляването им (ако е приложимо);

o Допуснати грешки, включително причини, поради които са възникнали и какви мерки са предприети за отстраняването им (ако е приложимо)

Актуализиран списък на рисковете;

Актуализиран план за изпълнение, ако има промяна в него.Към месечните доклади се прилагат съответните доказателства (включително и електронно) за изпълнената през месеца част от работата по съответните дейности.

Нарочни доклади

Нарочният доклад може да бъде изискан по всяко време на изпълнение на договора от Изпълнителя. Той се изисква от Възложителя при настъпила необходимост от конкретна информация по изпълнението на договора, по конкретна тема свързана с изпълнението или по конкретен повод чрез писмено искане, в което се описва изискваната информация и сроковете за предоставянето й. Изпълнителят не може да откаже представянето на изисканата информация, но може да поиска чрез мотивирано писмено искане удължаване на срока за предоставяне. При постъпване на такова искане Възложителя го разглежда във възможно най-кратък срок и решението му е задължително за изпълнение от Изпълнителя.

Всеки междинен доклад следва да бъде одобрен от Възложителя.

Окончателен доклад

Изпълнителят трябва да изготви окончателен доклад в края на срока за изпълнение договора. Докладът трябва да съдържа:

Управленско резюме;

За всяка група дейност от поръчката:

o Описание на извършената работа по групата дейност. Където е приложимо се прилагат и резултати от измерването на метриките за разработка;

o Постигнати резултати, като се опишат чрез заложените и постигнатите индикатори;

o Възникнали проблеми и допуснати грешки, включително забавяния или отлагане изпълнението на дейности, причини поради, които са възникнали и какви мерки са предприети за преодоляването и отстраняването им (ако е приложимо);

Извлечени добри практики;


108

Препоръки за развитие в след проектния период, включително информация за бъдещата устойчивост.

Трябва да бъде направена и цялостна оценка на резултатите.

В срок от един месец преди изтичане на Договора за изпълнение на поръчката, Изпълнителят предава проект на окончателен доклад за преглед от Възложителя.

Доклад за гаранционния период

Изпълнителят, за дейностите за които е предвиден гаранционен период в рамките на договора трябва да изготви Доклад за гаранционна поддръжка в края на гаранционния период.

Докладът се предава заедно с пълна актуализирана версия на отчетната документация на Системата.

Докладът като минимум трябва да съдържа:

o Описание на извършената работа;

o Възникнали проблеми и предприети мерки за преодоляването им;

o Информация в табличен вид относно извършените актуализации на отчетната документация през гаранционния период;

o Идентифицирани рискове и предприети мерки.Към доклада се предава цялостен (пълен) пакет на отчетната документация за Системата, независимо дали в рамките на гаранционния период, същите са били актуализирани или не.

10 РЕЗУЛТАТИОчакваните резултати от изпълнението на настоящата обществена поръчка са посочени за всяка дейност в т.8

11 Други изискванияИзпълнителят по всяка дейност задължен да спазва приетите в системата на Възложителя правила и процедури и други нормативни документи по различните дейности. Основните документи, действащи в момента на създаване на настоящото задание, са дадени в Приложенията.

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

Изпълнителят за всяка дейност е длъжен да осигури за своя сметка протоколиране на всички срещи, с участие на свои представители, в рамките на договора. Образец на протокол от среща ще бъде предоставен от Възложителя в рамките на фаза Стартиране.


109

Изготвянето, съгласуването, подписването и съхранението на протоколите се извършва съгласно изискванията на настоящата техническа спецификация.

Изпълнителят за всяка дейност в рамките на изпълнението следва в максимална степен да използва въведените и използвани от Възложителя продукти. Кои продукти ще се използват в рамките на изпълнението на договора се ще определи в рамките на фаза Стартиране.

11.1 Система за управлениеУчастникът трябва да прилага система за управление на сигурността на информацията, съответстваща на стандарт БДС ISO/IEC 27001 или еквивалентен, с обхват: разработване, внедряване и поддръжка на софтуерни продукти и информационни системи, което се доказва със сертификат. Сертификатът трябва да е валиден и да е издаден от независими лица, които са акредитирани по съответната серия европейски стандарти от Изпълнителна агенция „Българска служба за акредитация“ или от друг национален орган по акредитация, който е страна по Многостранното споразумение за взаимно признаване на Европейската организация за акредитация, за съответната област или да отговарят на изискванията за признаване съгласно чл. 5а, ал. 2 от Закона за националната акредитация на органи за оценяване на съответствието. Възложителят приема еквивалентни сертификати, издадени от органи, със седалище в други държави членки.

Документ за доказване: заверено „Вярно с оригинала“ копие на сертификат БДС ЕN ISO 27001 или еквивалент.

Участникът трябва да прилага система за управление на ИТ услуги, съответстваща на стандарт БДС EN ISO 20000-1 или еквивалентен, което се доказва със сертификат. Сертификатът трябва да е с обхват: предоставяне на услуги по разработване, внедряване и поддръжка на софтуерни продукти и информационни системи, да е валиден и да е издаден от независими лица, които са акредитирани по съответната серия европейски стандарти от Изпълнителна агенция „Българска служба за акредитация“ или от друг национален орган по акредитация, който е страна по Многостранното споразумение за взаимно признаване на Европейската организация за акредитация, за съответната област или да отговарят на изискванията за признаване съгласно чл. 5а, ал. 2 от Закона за националната акредитация на органи за оценяване на съответствието. Възложителят приема еквивалентни сертификати, издадени от органи, установени в други държави членки.

Документ за доказване: заверено „Вярно с оригинала“ копие на сертификат БДС EN ISO 20000-1 или еквивалент.

Участникът трябва в техническото предложение да представи методология, подход и техническо решение за изпълнение на дейностите в обхвата на настоящата поръчка, както и график с включени етапи, дейности, резултати и ангажираност на членовете от екипа.

11.2 Отчитане на извършената работаОтчитането на извършената работа се извършва с представянето от страна на Изпълнителя на отчетните документи/резултати. Всяка доставка следва да бъде придружена с опис на доставяните резултати.


110

Доставката се осъществява с придружително писмо в деловодството на Възложителя. Времето на доставката се удостоверяват в входящия номер от Възложителя.

Приемането на отчетните резулатати става с Подписването на приемо-предавателните протоколи за извършена дейност по договора и се извършва от Ръководителя на договора от страна на Възложителя, след решение на комисия на Възложителя за приемане на работата.


111

12 Приложение 1а Протокол за стартиране на дейностите

ПРОТОКОЛ

за стартиране на дейностите

(договор №.............201.. г. между ДАЕУ и ……………………………..)

Днес, ………………………, в гр.София, между:

1. Държавна агенция „Електронно управление“, със седалище и адрес на управление: гр.нСофия, ул.н“Гурко” № 6, ЕИК: ………………, представлявано от ………………... – Ръководител на договора, съгласно Заповед № ……………………………. на Председателя на ДАЕУ, наричано по-долу Възложител и

2. ………………, ЕИК …………….., със седалище и адрес на управление: гр…………, ……………………………., представляван от ……………., действащ чрез пълномощника си – …………………, наричан по-долу Изпълнител,

на основание т……. и във връзка с т…… от договор № ……./………..201.. г., сключен между горепосочените страни, се състави и подписа настоящият протокол, с който страните удостоверяват следното:

1. Изпълнителят поема изпълнението на дейностите, предмет на договор № ………../……….201… г. в състоянието, в което те се предоставят към момента на подписване на настоящия протокол и обезпечават нормалното функциониране на средата за междурегистров обмен (RegiX).

2. Изпълнителят стартира фактическото предоставяне на дейностите, предмет на договор № …………..../………...201….. г., считано от 00:00 часа на деня, следващ датата на подписване на настоящия протокол от страна на Възложителя, като от този момент нататък поема изцяло отговорността за качественото, навременно и добросъвестно изпълнение на предмета на договора, приложенията към него и плана за изпълнение на договора.

Този протокол се състави и подписа в два еднообразни екземпляра, по един за всяка от страните и е неразделна част от Договор № ……………………../……...201…. г.

ЗА ВЪЗЛОЖИТЕЛЯ: ЗА ИЗПЪЛНИТЕЛЯ:

Ръководител на договора: Упълномощено лице:


112

....................................... ...........................................

(…………………………….)

Дата:………………………

(.....................................)

Дата:………......................


113

13 Приложение 2а Образец на Заявка за предоставяне на дейности

ДЪРЖАВНА АГЕНЦИЯ „ЕЛЕКТРОННО УПРАВЛЕНИЕ“

УТВЪРЖДАВАМ:

(име, подпис)

Ръководител на договор

Заповед № ……. от ………… на Председателя на ДАЕУ

ЗАЯВКА

за предоставяне на дейности

(по договор №...............201… г. между ДАЕУ и .................)

Наименование на проекта (Попълва се точното наименование на проекта)

Дейност (Наименование на дейността, съгл. настоящата техническата спецификация)

Обем работа в човекодни (Попълва се общата стойност в човекодни)

Стойност в лв. без ДДС (Попълва се общата стойност на проекта в лева)

Период на изпълнение: (Начална дата) (Крайна дата)

Ръководител на договор от Възложителя (Име, длъжност, звено,телефон, е-mail)

Ръководител на договор от Изпълнителя (Име, длъжност, звено,телефон, е-mail)

Настоящата заявка да се изпълни при следните условия:

1. Място на изпълнение:(Адрес на офиса на Възложителя или на локацията определена от него).

2. Обща информация2.1. Въведение


114

(описва се необходимостта породила нуждата от промяна или изпълнение на дейност)

2.2. Съществуващо положение(описва се съществуващото положение и засегнатите компоненти на Единния модел, които са засегнати от промяната или изпълнение на дейност)

2.3. Цели(описват се целите, които ще се постигнат с исканата промяна или изпълнение на дейност)

2.4. Очаквани резултати(описват се очакваните резултати)

3. Засегнати компоненти на Единния модел(ако е приложимо се описват засегнатите от заявените промени

компоненти на Единния модел)

4. Описание на заявката (Описват се основните изисквания на Възложителя за изпълнението на проект–

нови или надграждащи функционалности, работни процеси, интерфейси, засегнати страни и т.н. Специфицират се поддейностите, които ще се изпълняват по тази заявка на база описаните дейности в обхвата на групата дейности, съгласно настоящата техническа спецификация).

5. Изисквания, свързани с изпълнението на заявката:(Дефинират се: етапи на изпълнение, начин на провеждане на приемните изпитания, допълнителни специфични документи, които да бъдат представени, извън описаните в настоящата техническа спецификация, ако има такива и други уточнения, прецизиращи възлагането на проекта. Описва се дали се предвиждат и какви приемни изпитания и обучения ще се провеждат. В случай на дефинирани етапи – тази информация се дефинира за всеки етап. Приемните изпитания се извършват, съгласно изискванията на настоящата техническа спецификация).

6. Изисквания, свързани с организацията на изпълнението(описва се подробния времеви график за изпълнението на проекта. В случай на необходимост се описват и етапи на изпълнение).

7. Гаранционна поддръжка и гаранционни срокове


115

(описват се изискванията към гаранционната поддръжка и продължителността й).

8. Отчитане на изпълнението. Активи, които ще бъдат предадени на Възложителя.(В тази точка се описват всички изисквания към отчитане на изпълнението. Като приложение към заявката се дава формата и изискванията към съдържанието на отчета на дейностите по заявката, включително изискванията за финансов отчет и други документи, необходими за приключването на заявката.

Представя се и списък на активите).

9. Други изисквания(описват се други специфични изисквания към изпълнението на заявката)

10. Приложения: (Описват се приложенията, ако има такива).

Настоящият документ е съставен в два оригинални екземпляра по един за Възложителя и Изпълнителя.

За Възложителя: Ръководител на договор:

(име, длъжност)........................

Дата: Подпис:

За Изпълнителя: Ръководител на договор:

(име, длъжност)......................

Дата: Подпис:


116

14 Приложение 3а Параметри на качеството на обслужване на Системата (REGIX)14.1 Дефиниции

Таблица 7 ДефиницииТермин Дефиниция

РаботоспособностПроцентът на договорените часове, за които Системата е достъпна за определен период от време.

Светла част на денонощието От 08.00 часа до 20.00 часаИзвън светлата част на денонощието

От 20:00 – 08:00 часа всеки работен ден, събота, неделя, национални и официални празници

Работни часове (Работно време) 08:00-20:00 всеки работен ден

Инцидент

Всяко събитие, което причинява или може да предизвика прекъсване и/или намаляване на качеството на услуга предоставяна чрез Единния модел.

Продължителна неработоспособност

Прекъсване на услуга предоставяна чрез Единния модел за повече от четири (4) работни часа

Планирана неработоспособност Планирано прекъсване на работата на Единния модел.

Неработоспособност

Неспособността на Единния модел да осигури нормално обслужване на потребителите, съгласно определените параметри на качеството

Непланирана неработоспособност

Неочаквано прекъсване на една или повече услуги предоставяни чрез Единния модел или значително намаляване на параметрите на качеството на предлаганата услуга.

Осигуряване на нормално обслужване

Постигане на работоспособност на Единния модел, съгласно посочените проценти за наличност и достъпност на месечна база.

Критична функционалност не функционира нормално

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

Услуга, предоставяна чрез Единния модел

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

НаличностПроцент на договорените часове, за които Единния модел е достъпен за определен период от време.

ДостъпностСпособността на Единния модел да осигури нормалното обслужване и работа на крайните потребители с него.

Непланирано прекъсванеВсяко прекъсване, за което Възложителя не е уведомен 7 работни дни предварително

Система за управление на инциденти/проблеми

Софтуерният инструмент, който се използва от Възложителя за регистриране и управление на инциденти/проблеми

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


117

Термин Дефинициявъзникнал инцидент в Системата за управление на инциденти/проблеми.

Процедура за управление на инциденти и проблеми

Процедурата е детайлно описана в настоящата техническа спецификация

Време на реакция

Времето от регистрирането на инцидент/проблем в Системата за управление на инциденти/проблеми до започване на работа от страна на Изпълнителя по отстраняването му

План за решение

Описание на действията на Изпълнителя за отстраняване на инцидент/проблем или предлагане на временно решение, което да възстановява поне частично работоспособността на Единния модел

Специална версия

Версия, създадена за да се реши конкретно възникнал един или няколко инцидента със степен на критичност 1 или 2. Предава се от Изпълнителя в определените от Възложителя срокове от момента на изтичане на времето за реакция. Специалните версии се внедряват след подписване на двустранен протокол, неразделна част от който е декларация от страна на Изпълнителя за отстраняване на инцидента/инцидентите, причина за разработването на версията.

Следваща версияВерсия за отстраняване на инциденти/проблеми съгласно плана за дейностите по договора.

Срок за отстраняване на инцидент

Максималното време за реализиране на плана за решение

НКГ Наличност за календарна годинаМОД Максимално сумарно отпадане на денонощиеМБрО Максимален брой отпадане на денонощие

14.2 Определяне на степента на критичност на инцидент

Степента на критичност на възникнал инцидент се определя съгласно критериите, описани в Таблица 8 Приоритети:

Таблица 8 Приоритети

Приоритет Въздействие върху работните процеси1 Критичен Критично влияние върху работните процеси. Изисква незабавно

действие, като работата продължава до неговото отстраняване. Пълно прекъсване на една или повече ЕАУ, предоставяни чрез

Единния модел;

Недостъпност до предоставяни през функционалността на Единния модел, която пряко и съществено засяга способността на


118

Приоритет Въздействие върху работните процеси

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

Висок риск от финансови загуби и/или засягане на имиджа на ДАЕУ или негови контрагенти;

Създава висок риск за компрометиране на информация в системите на електронното управление;

Нарушена комуникация с други държави членки на ЕС или на аналогични системи на електронното управление;

Риск за съществено прекъсване или излизане от строя на Единния модел;

Критична функционалност не функционира нормално или има критично и негативно отражение върху операциите на потребителите или системната среда във ведомство на Възложителя или в имиджа на същото или е възникнало непланирано преустановяване на достъпността.

2 Висок

Съществено влияние върху работните процеси. Изисква ангажиране на необходимите ресурси за отстраняването на проблема, като работата продължава в нормалните работни часове до неговото отстраняване.(1) Влошаване на качеството на предлагана услуга или достъп до

такава, без пълно прекъсване;

Създаване на сериозен риск от възникване на инцидент с критичен приоритет;

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

3 Среден Несъществено влияние върху работните процеси. Изисква ангажиране на необходимите ресурси за отстраняване на проблема, като работата за неговото отстраняване е не-повече от 7 работни дни. Ограничено въздействие върху работата на Единния модел, което

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

Нормалната производителност на Единния модел или част от него Документация за участие в обществена поръчка с предмет:


119

Приоритет Въздействие върху работните процеси

е влошена, но по-голяма част от функционалната му способност е незасегната.

4 Нисък

Няма пряко влияние върху работните процеси в момента на възникването му. Изисква ангажирането на необходимите ресурси за отстраняване на проблема, като работата за неговото отстраняване е не-повече от 14 работни дни В момента липсва пряко влияние върху функционирането на

Единния модел, но не решаването му в определен срок крие потенциален риск от възникване на инцидент с по-висок приоритет.

Обикновено се свързва с подобряване на функционирането на услуга, предоставяна от Единния модел или развитието й.

Отстраняването се планира съвместно с Възложителя и е обект на средносрочно планиране. Възложителят може да изисква информация или помощ по възможните решения.

14.3 Параметри на качеството при отстраняване на инцидентТаблица 9 Параметри на качеството при отстраняване на инцидент

Приоритет на

инцидента

Време за реакция,

max

План за решение, max Начин на отстраняване

Срок за отстраняв

ане на инцидента,

max1 30 минути 2 ч. В специална версия 6 часа2 1 час 4 ч. В специална версия 12 часа

3 1 работен ден 1 седмица В следваща версия 7 работни

дни

4 1 работен ден

1 седмица В следваща версия 14 работни дни

Забележки:(а) Всички понятия са съгласно Таблица 7 Дефиниции;(b) Приоритетите се определят от Възложителя, съгласно точка „Определяне на степента на критичност на инцидент“;(c) За инциденти от 1 и 2 приоритет, ако за времето на отстраняване на проблема бъде намерено временно решение, с което изцяло се възстановява работоспособността на Единния модел, Възложителят може да снижи приоритета на инцидента без да го закрива.(d) Всички, посочени в таблицата, времена започват да текат от момента на регистриране в Системата за управление на инциденти на Възложителя.(e) При обективна невъзможност да бъдат спазени сроковете в таблицата, Възложителят може да ги промени за конкретен инцидент;


120

14.4 Параметри на качеството при отстраняване на проблемТаблица 10 Параметри на качеството при отстраняване на проблем

Приоритет на

проблема

Време за реакция,

max

План за решение, max

Начин на отстраняване

Срок за отстраняване на проблема,

max1 1 час 4 часа В специална версия 24 часа2 2 часа 24 часа В специална версия 72 часа

3 1 работен ден 1 седмица В следваща версия 7 работни дни

4 1 работен ден

1 седмица В следваща версия 14 работни дни

Забележки:(а) Всички понятия са съгласно Таблица 7 Дефиниции;(b) За инциденти от 1 и 2 приоритет, ако за времето на отстраняване на проблема бъде намерено временно решение, с което изцяло се възстановява работоспособността на Единния модел, Възложителят може да снижи приоритета на инцидента без да го закрива.(c) Всички, посочени в таблицата, времена започват да текат от момента на регистриране в Системата за управление на инциденти на Възложителя.

14.5 Наличност и достъпност на Компонент на Единния моделТаблица 11 Наличност и достъпност на Единния модел

Приложно полеНаличност за

календарна година -НКГ

Максимално сумарно отпадане

на денонощие - МОД

Максимален брой отпадане за денонощие

МБрО1. Компонент на Единен модел за заявяване, плащане и предоставяне на ЕАУ

99,680 % Не повече от 60 минути 4 броя

(а) Всички понятия са съгласно Таблица 7 Дефиниции.


121

15 Приложиние 4 Органи на управлението на договораОрганизационна структураВсяка от страните по Договора определя организационната си структура на две нива

– управленско и оперативно.

На управленско ниво задължителни роли за двете страни са ръководител на договор (РД).

На оперативно ниво задължителна роля за Изпълнителя са ръководителите на дейности.

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

15.1 Съвет за оперативно управлениеСъветът за оперативно управление (СОУ) е постоянен оперативен орган на

Възложителя и страните по договори, свързани с дейности по функционирането на Единния модел за заявяване, заплащане и предоставяне на електронни административни услуги.

СОУ се председателства от Директора на ДИСОС от страна на Възложителя или от определен със Заповед на Председателя на ДАЕУ друг служител и включва в състава си ключови експерти от страна на Възложителя и по един представител на всеки Изпълнител по договор, свързан с дейности по функционирането на Единния модел за заявяване, заплащане и предоставяне на електронни административни услуги.

Членовете на СОУ от страна на Възложителя се определят със заповед на Председателя на ДАЕУ. За членове на СОУ от страна на Възложители се определят представители на дирекция „Информационни системи и оперативна съвместимост“, дирекция „Комуникационна и информационна инфраструктура“, дирекция „Мрежова и информационна сигурност“ и представители на други дирекции в ДАЕУ по преценка на Председателя на ДАЕУ.

Членовете на СОУ от страна на Изпълнителя се определят от неговия ръководител (директор, изпълнителен директор, управител и пр.) съгласно утвърдени в съответната организация документи. Копие от съответния документ се изпраща до Председателя на ДАЕУ с цел включване на определения представител в състава на СОУ.

СОУ ще бъде създаден в рамките на фаза Стартиране.

СОУ има следните функции, като подробно функциите и организацията на работата му ще бъдат описани в “Правила за работа на Съвета за оперативно управление”, които се приемат на неговото първо заседание:


122

Управление на техническите аспекти в процеса на предаване/приемане управлението, изпълнението и отчитането на договори, свързани с дейности по функционирането на Единния модел за заявяване, заплащане и предоставяне на електронни административни услуги;

Управление на техническите аспекти на функционирането на Единния модел или координацията на екипите на Центъра за обслужване на потребителите на Единния модел;

Иницииране и мониторинг на промени в управлението и инфраструктурата;

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

Разрешаване на въпроси, свързани с координацията на екипите, обслужващи функционирането на Единния модел след ескалиране.

15.2 Дирекция „Информационни системи и оперативна съвместимост”Дирекция „Информационни системи и оперативна съвместимост” (ДИСОС) е

звеното на Възложителя, което следи и координира на оперативно ниво изпълнението и управлението на договорите като цяло, свързани с функционирането на Единния модел, като оказва и необходимото съдействие на съответните Изпълнители.

Възложителят може да определи и други изпълнителски екипи (различни от служители на ДИСОС), които съвместно с ДИСОС да изпълняват описаните по-долу функции. Съвместната работа на тези изпълнителски екипи с ДИСОС и тяхното взаимодействие се регламентират в техническо задание за възлагане и/или с отделна процедура, която е утвърдена от Възложителя.

Дирекция „Информационни системи и оперативна съвместимост”:

Организира и координира създаването, управлението и контрола на работа на Център за обслужване на потребители на Единния модел;

Координира и отговаря за взаимодействието с всички изпълнителски екипи, имащи отношение към реализацията и функционирането на Единния модел;.

Участва в развойните фази (планиране, детайлизиране, изграждане, тестване и внедряване) при надграждане на компонентите на Единния модел от гледна точка на интегрирането им и осигуряване на нормалната им работа в обща архитектурна среда;

Развива Единния модел, включително и при планиране на промени в компонентите на техническата инфраструктура на Единния модел;

Създава и поддържа в актуално състояние и анализира модели на Документация за участие в обществена поръчка с предмет:


123

съществуващите или нови работни процеси, информационни модели (аналитичен и дизайн), с цел развитие на Единния модел;

Дефинира функционалните изисквания към нови или надграждане на съществуващи компоненти на Единния модел, включително и дефинира интерфейсите за връзка между компонентите на системите и връзки с аналогични системи, функциониращи в Европейския съюз;

Дефинира нефункционалните изисквания към нови или надграждане на съществуващи компоненти на Единния модел, включително и дефиниране на интерфейси за връзка между компонентите на системите и връзки с аналогични системи, функциониращи в Европейския съюз;

Анализира и оценява необходимостта и степента на интеграция между съществуващите компоненти на Единния модел и/или тези, които са в процес на разработка или усъвършенстване в ЕС;

Оценява риска по отношение на общата среда и идентифицира критични точки във функционирането на Единния модел;

Анализира параметрите на качеството на обслужване, оперативната съвместимост, информационната сигурност, потребителските групи и профили;

Предлага техническо специфициране на включване на контроли, позволяващи наблюдение на работоспособността, производителността, достъпността, натоварването на критични компоненти и други параметри на Единния модел при работата му в условията на обща интеграционна среда;

Анализира въздействието на промените върху компонентите на Единния модел.

Разработва предложения и проекти на планове за обновяване на инфраструктурата, обслужваща Единния модел;

Разработва процедури за интеграционни, регресионни тестове и тестове за натоварване по отношение на Единния модел;

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

Провежда интеграционни, регресионни тестове и тестове за натоварване, по отношение на Единния модел, както и анализ на резултатите от тях;

Разработва процедури с цел изследване на удовлетвореността на потребителите на предоставяните и използвани чрез Единния модел услуги;

Анализира рискове и възникналите проблеми в процеса на Документация за участие в обществена поръчка с предмет:


124

експлоатация и развитие на Единния модел; Събира, обобщава и анализира предложения от страна на

Изпълнителите по договори, свързани с дейностите по функциониране на Единния модел и изготвя предложения за подобряване на удовлетвореността на потребителите, както и предложения, свързани с устойчивостта, надеждността и достъпността на Единния модел;

Организира, управлява и контролира осигуряване на дейностите по гарантиране на работоспособността на компонентите на Единния модел и на Единния модел като цяло;

Отговаря за изготвянето и съгласуването с Изпълнителя по договора на плановете за изпълнението им;

Подпомага работата на СОУ, като администрира подготовката на заседанията им;

Участва в разрешаването на спорни въпроси, възникнали между Изпълнителите на съответните договори, свързани с дейности по функционирането на Единния модел за заявяване, заплащане и предоставяне на електронни административни услуги;

Извършва координацията по съгласуване на всички изготвени от Изпълнителя в хода на изпълнението на Договора отчетни резултати;

Създава и съхранява хартиени и/или електронни досиета на цялата проектна документация (възлагане, изпълнение и отчитане – протоколи, отчети, финансови справки и други документи, според изискванията на настоящата техническа спецификация).

15.3 Дирекция „Комуникационна и информационна инфраструктура“Дирекция „Комуникационна и информационна инфраструктура” (ДКИИ) е

звеното на Възложителя, което следи и координира на оперативно ниво изпълнението и управлението на ИТ инфраструктурата като цяло, като оказва и необходимото съдействие при необходимост.

Дирекция „КИИ”:

Участва при съгласуването с Изпълнителя по договора на плановете за изпълнение ;

Подпомага работата на СОУ, като взема участие в заседанията им при необходимост;



125

Ангажира свои служители при необходимост да участват от страна на Възложителя при изпълнението на дейностите по различните договори, както и при приемане на извършената дейност;

Участва в комисиите на Възложителя по приемане на отчетните резултати в хода на изпълнението на договора.

15.4 Дирекция „Мрежова и информационна сигурност“Дирекция „Мрежова и информационна сигурност” (ДМИС) е звеното на

Възложителя, което следи и координира на оперативно ниво изпълнението и управлението на мрежовата и информационна сигурност като цяло, като оказва и необходимото съдействие при необходимост.

Дирекция „МИС”:

Участва при съгласуването с Изпълнителя по договора на плановете за изпълнение на договора;

Подпомага работата на СОУ, като взема участие в заседанията им при необходимост;


Ангажира свои служители при необходимост да участват от страна на Възложителя при изпълнението на дейностите, както и при приемане на извършената дейност;

Участва в комисиите на Възложителя по приемане на отчетните резултати в хода на изпълнението на договора.

15.5 Ръководители на договора от страна на Възложителя и ИзпълнителяСтраните по договора определят ръководител на договора (РД) и негов заместник.

РД е представител от страна на Възложителя, който на управленско ниво отговаря за:

Изпълнението на задълженията на Възложителя по договор, съгласно залегналите в него и приложенията му изисквания;

Създаването на необходимата организация от страна на Възложителя за изпълнението на приетия план по договора;

Мониторинг на параметрите на качеството на обслужване, съгласно приложението към настоящата спецификация;

Поддържането на пряка връзка с РД на Изпълнителя, както и с трети Документация за участие в обществена поръчка с предмет:


126

страни, имащи отношение към изпълняваните по договора дейности.

РД от страна на Изпълнителя е упълномощен негов служител, който пряко на управленско ниво носи пълната отговорност за организацията, контрола и цялостното управление и изпълнение на дейностите, включени в предмета на договора, поддържа пряка връзка с РД на Възложителя, както и с трети страни, имащи отношение към дейностите по договора.

РД от страна на Изпълнителя е задължен да:

Контролира и взима необходимите мерки за изпълнението на дейностите, съгласно параметрите за качество на обслужването, сроковете и финансовите лимити по съответните дейности;

Участва в други дейности в рамките на договора, които са значими за договора като цяло (например идентифицирането и управлението на рисковете);

Подписва заявките за стартиране изпълнението на дейности по договора;

Изготвя обобщен отчет за цялостното изпълнение на договора и го представя за разглеждане и приемане от страна на Възложителя;

При поискване от страна на Възложителя представя информация за напредъка и текущия статус на изпълнение на дейностите по договора, съгласно изискванията на настоящата спецификация;

Отговорен е за параметрите на качеството на дейностите по договора.

15.6 Ръководители на дейности от страна на ИзпълнителяЗа всяка дейност Изпълнителят определя ръководител (РДейност) титуляр и негов

заместник в случай на отсъствие на титуляра. Той осъществява оперативното управление на изпълняваните дейности по предмета на договора.

РДейност от страна на Изпълнителя отговаря за:

Съгласуване и подписване на изготвената от РД на Възложителя Заявка за възлагане на дейности;

Изготвяне на всички отчетни документи – протоколи, съпътстващи документи и други, съгласно изискванията на настоящата техническа спецификация и договора, както и съгласуването им с РД на Възложителя;

Изпълнението на съответната дейност и плановете по нея; Правилното определяне на обема дейности и разпределението на

изпълнението им; Оценка и управление на рисковете; Управление на параметрите на качеството на обслужване и


127

извършване на коригиращи действия, при необходимост; Определяне на отговорностите и взаимовръзките между различните

екипи в рамките на дейността и контролиране на изпълнението им; Изготвяне на информация относно напредъка и изпълнението на

плановете и предоставянето й на РД от страна на Възложителя; Предоставяне на информация относно изпълнението на плановете; Организиране подписването на отчетните документи и предоставянето

им на Възложителя. Разпределяне на задачи и отговорности в екипа, свързани с

осигуряване на качеството на изпълнение.

15.7 Център за обслужване на потребителите на Единния модел (Help desk)Центърът за обслужване на потребителите на Единния модел се изгражда с цел

осигуряване на висока достъпност при предоставянето на електронни услуги чрез Единния модел и гарантиране на непрекъсната работа на всички компоненти на Единния модел. Центърът обслужва всички участници в електронното управление (крайни потребители, администрации, търговски сектор и др.), които използват Единния модел.

Центърът за обслужване на потребителите на Единния модел включва в себе си три нива, които си взаимодействат по начин определен в настоящата техническа спецификация и се състои от експерти на Възложителя, други изпълнителски екипи (ако има такива) и членове на екипите на Изпълнителите по съответните Договори, свързани с дейности по функционирането на Единния модел за заявяване, заплащане и предоставяне на електронни административни услуги.

Всички инциденти се регистрират и управляват чрез Система за управление на инциденти на Възложителя. Цялостната координация, управление контрол на работата на Центъра се извършва от ДИСОС или определен от Възложителя изпълнителски екип.

В състава, който обслужва Центъра, са включени представители на Възложителя и на изпълнителите по Договорите, , свързани с дейности по функционирането на Единния модел за заявяване, заплащане и предоставяне на електронни административни услуги като се отчита компетентността им по компонентите на Единния модел.

Съставът на всяко ниво се състои от Ръководител и членове.

Ръководителите на трите нива на Центъра са представители на Възложителя или определени от него представители на други изпълнителски екипи.

Центърът за обслужване на потребители на Единния модел работи в режим 365/24/7.

Екипът на първо ниво като минимум се състои от един член на денонощен Документация за участие в обществена поръчка с предмет:


128

режим на работа и 2 (двама) членове, работещи в светлата част на денонощието (от 08 часа до 20 часа). Броя на членовете на екипа в светлата част на денонощието трябва да бъде определен така, че да осигурява приемане на обаждане в рамките на 30 (тридесет) секунди.

В екипите на второ и трето ниво се включват минимум по един представител на Изпълнителите по Договорите, свързани с дейности по функционирането на Единния модел за заявяване, заплащане и предоставяне на електронни административни услуги. Изискванията към редставителите на Изпълнителя са детайлно описани в т. 8.3.1 на настоящата техническа спецификация.

Възложителят ще осигури достъп на екипите на Изпълнителя по Договора до ИТ инфраструктурата за обслужване на Центъра за обслужване на потребители на Единния модел, необходими за изпълнение на дейностите, описани в настоящата техническа спецификация.

Дейността на Центъра за обслужване на потребители на Единния модел следва да се изпълнява до максимално възможна степен чрез наличната при Възложителя Система за управление на инциденти, като включва минимум следните изисквания:

Нормални условия за работа на потребителите на Единния модел; Консултиране и оказване помощ на потребителите при работата им с

Единния модел и/или хоризонталните системи на електронното управление;

Разрешаване на проблеми, свързани с настройките на работните станции и периферия, включително системен, необходими за нормалното функциониране на Единния модел при крайните потребители;

Предоставяне на техническа информация и консултация на потребителите чрез Системата за управление на инциденти, по електронна поща или по телефон;

Регистриране, проследяване, разрешаване и отчитане на възникнали инциденти и проблеми;

Създаване и непрекъснато обогатяване на „База знания“, която да подпомага процеса на разрешаване на инциденти и проблеми;

Обучаване на потребители за работа с Единния модел; Текущо наблюдение на работата на Единния модел и предприемане на

навременни действия при възникване на отклонения в работата на наблюдаваните работни процеси;

Центърът за обслужване на потребители на Единния модел трябва да осигури параметрите на качеството на обслужване, посочени в настоящата техническа


129

спецификация.

Трите нива на Центъра за обслужване на потребителите на Единния модел са:

Ниво 1 на Центъра за обслужване на потребителите на Единния моделОсновното значение на първо ниво е “единна точка за контакт”, където се

осъществява събирането и предоставянето на необходимата първоначална информация за получен инцидент.

Основните функции на ниво 1 са:

Приемане и регистриране на нови инциденти. За всеки постъпил инцидент се регистрира заявка в Системата за управление на инциденти на Възложителя;

Събиране на достатъчно информация за получен инцидент, така че той да бъде правилно категоризиран и приоритизиран;

Проверка дали докладвания инцидент не е регистриран вече от друг потребител, т.е. проверка за дублиране на инциденти;

Вземане на решение за това, дали инцидента е от компетенциите и в обхвата на действие на екипите на Центъра за обслужване на потребителите на Единния модел, а ако не е в състояние да прецени, ескалира инцидента към Ръководителя си за вземане на решение или ескалирането към Директора на ДИСОС;

Назначаване за разрешаване на инциденти на други екипи на Възложителя, в случаите когато инцидента не е в обхвата на действие на изпълнителските екипи по Договорите, свързани с дейности по функционирането на Единния модел за заявяване, заплащане и предоставяне на електронни административни услуги;

Проверка в „База знания” за наличността на решение по подадения инцидент;

Разрешаване на инцидент на първо ниво, а при невъзможност ескалира инцидента, като го назначава на подходящ екип от второ ниво на Център за обслужване на потребителите на Единния модел;


130

Приемане и окомплектоване на цялата изискуема информация, необходима за разрешаване на инцидента, в случаите, когато същата е налична при заявителя на инцидента;

Затваря инцидентите, на които той е собственик; Допринася за качественото и безпроблемно

функциониране на Центъра.

Ниво 2 на Центъра за обслужване на потребителите на Единния моделВторо ниво получава уведомление за назначаването на заявка за разрешаване на

инцидент от първо ниво.

Основните му функции са:

Разпределяне на заявка в зависимост от засегнатия компонент на Единния модел. В случай, че са засегнати повече от един компонент на Единния модел – Ръководителят на ниво 2 създава организация и при необходимост сформира нарочен екип за решаване на инцидента, който задължително включва представители на изпълнителите на Договорите, свързани с дейности по функционирането на Единния модел за заявяване, заплащане и предоставяне на електронни административни услуги, които са отговорни за функционирането на съответните засегнати компоненти на Единния модел;

Предприемане на всички необходими действия, за разрешаване на назначената му заявка;

Възпроизвеждане, анализиране и разрешаване на назначената му заявка, включително създаване на временен процес на работа при невъзможност за отстраняване на инцидента в параметрите на качеството на обслужване, посочени в настоящата техническа спецификация;

При необходимост Ръководителят на ниво 2 назначава нови операции към заявка - в случай, на необходимост от извършване на действия и от други екипи от второ ниво, или заявката да бъде ескалирана към трето ниво и проследява прогреса на изпълнението ѝ до намиране на решение;

Ръководителят на ниво 2 и/или определен от него служител проактивно изследва инциденти с цел откриване на проблеми – коренната причина за възникването на инцидентите;

Ръководителят на ниво 2 или определен от него служител следи цялостния процес на развитие на заявката до постигане на решението ѝ;

Обогатява „База знания“ с информация за разрешени инциденти;Документация за участие в обществена поръчка с предмет:


131

Наблюдава детайлите на инцидента, включително засегнатите компоненти на Единния модел;

При необходимост докладва за установени проблеми в системата за регистриране на инциденти на Възложителя;

Допринася за качественото и безпроблемно функциониране на Центъра.

Ниво 3 на Центъра за обслужване на потребителите на Единния моделТрето ниво получава уведомление за назначаването на заявка за разрешаване на

инцидент от второ ниво.

Основните му функции са:

Сформиране на екип от представителите на изпълнителите на Договорите, свързани с дейности по функционирането на Единния модел за заявяване, заплащане и предоставяне на електронни административни услуги с необходимата квалификация за разрешаване на заявката;

Наблюдаване и анализиране на детайлите на инцидент, включително засегнатите компоненти на Единния модел;

Проактивно изследване на инциденти с цел откриване на проблеми – коренната причина за възникването на инцидентите;

Следене на цялостния процес на развитие на заявката до постигане на решението ѝ;

Оценяване полученото решение на заявката и потвърждава валидността му;

Обогатява „База знания“ с информация за решени проблеми; При необходимост докладва за установени проблеми в системата за

регистриране на инциденти на Възложителя; Прави предложения до Възложителя за промени в компонентите на

Единния модел, свързани с решаването на регистрирани проблеми; Допринася за качественото и безпроблемно функциониране на Центъра.

15.8 Контрол на параметрите на качествотоКонтролът на качеството от страна на Възложителя, се осъществява от

Ръководителя на договора или друго специално упълномощено лице и отговаря за:

Контролиране спазването на параметрите по качество на обслужването, дефинирани в договора и приложенията към него;

Своевременно уведомяване на Директора на ДИСОС за отклонения в договорените параметри на качеството на обслужване;


132

Контролиране на изпълнението на утвърдените политики, процедури и правила на Възложителя и спазването им от страна на Изпълнителя, имащи отношение към изпълнението на договора и набелязване на мерки при констатирани пропуски;

Контролиране на постигането на целите и резултатите в хода на изпълнението и съпоставянето им с договорените параметри на качеството;

Проследяване на изпълнението и набелязване на мерки за подобряване на цялостния процес по управление на качеството.

Контролът на качеството от страна на Изпълнителя се осъществява от определен от него служител, който има необходимата компетентност по управление на качеството и отговаря за:

Прилагането на стандартите за качество на предоставяне на услугите и спазване параметрите на качеството, посочени в договора и приложенията към него;

Проследяване на изпълнението на утвърдените политики, процедури и правила на Възложителя и спазването им от страна на екипите на Изпълнителя и взимане на своевременни мерки при констатирани пропуски;

Осъществяване на непрекъснат контрол на качеството в хода на изпълнението и предприемане на корективни действия при констатирани незадоволителни резултати;

Проследяване на постигането на целите и резултатите в хода на изпълнението и съпоставянето им със заложените параметри на качеството;

Предоставяне на информация на Възложителя в хода на изпълнението относно качеството на извършваните дейности и предприемане на необходимите действия за подобряването му;

Изпълнение на изискванията на Възложителя за подобряване на параметрите на качеството и взимане на мерки при констатирани пропуски;

Подписване на документи, удостоверяващи качеството от страна на Изпълнителя;

Изготвяне на справки по различни критерии по искане на Възложителя.


133

e-gov.bg¢ехническа+спецификация_regix.doc · web viewПриложение...

Documents