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

СПРАВКА за отразяване на становищата от общественото обсъждане на Проект на Постановление на Министерския съвет за изменение и допълнение на Наредбата за общите изисквания към информационните системи, регистрите и електронните административни услуги № подател предложение приема/не приема мотиви 1 asirekov В чл. 50 ал. 1 след "дължностни лица" да се добави "от звената си по бюджет и финанси" В чл. 52 ал. 2 след "длъжностни лица" да се добави "от звената си за управление на проекти" Мотиви: изпълнението на дейности в областта на електронно управление, независимо от предмета на тези дейности, по подразбиране се насочват към служители, ангажирани с ИКТ. В конкретния случай дейностите по вписване са свързани с бюджетния и проектния процеси, които са извън експертизата по ИКТ и това може да бъде предпоставка за публикуване на некоректна информация. В чл. да се добави ал. 7 със следния текст "Министърът на електронното управление Не се приема Не се приема Не се приема Могат да определят лица по своя преценка и в зависимост от структурата си Зависи от структурата на ведомството и наличните служители И сега министърът консултира и подпомага администрациите при работа със системата отговаря за осигуряване на адекватно обучение и консултации за работа със системата на длъжностните лица по ал. 4." Мотиви: Системата (РИР) е пусната в експлоатация през 2016 г.; липсват или не са достъпни обучителни материали и ръководства за работа; текущите персонални промени администрациите. 2 lslilova 1. Съгласно чл. 2, ал. 4 от ЗЕУ, Централен администратор на данни е лице или организация по чл. 1, ал. 1 или 2, което по силата на закон централизирано съхранява данни, предоставяни от първични администратори на данни. Централният администратор на данни предоставя достъп на гражданите и организациите до цялата информация, събрана за тях. Централен администратор на данни се смята за първичен администратор на данни по отношение на задълженията по чл. 3 за предоставяне и изпращане на данни. А доколкото в чл. 3, ал. 3 от ЗЕУ е посочено, че изискванията за идентификация на длъжностни лица и информационни системи за нуждите на предоставяне и изпращане на данните по ал. 1 и 2 се определят с Не се приема Липсва законова делегация в ЗЕУ относно уредбата на работата на централния администратор в наредбата наредбата по чл. 12, ал. 4, не е ли редно в проекта на ПМС да се конкретизира прилагането и на разпоредбите (в изпълнение на чл. 7, ал. 2 от Закона за нормативните актове) за централния администратор на данни, каквито липсват. Считам, че би било редно да се има публичност дали данните се предоставят от първичен или централен администратор. Централните администратори ще се вписват ли по някакъв начин регистъра на регистрите по чл. 2 от Наредбата или в някакъв друг регистър за идентифицирането им, защото този регистър не е част от разпоредбите на различни закони, с които се определят администратори централизирано съхраняващи данни на първичен администратор. Чл. 8, чл. 9, ал. 3, чл. 11, ал. 4 и чл. 63, ал. 4 от Наредбата изцяло ли се прилагат и от централния администратор. 2. В Чл. 15б. е посочено . (1) След изграждане на регистъра по чл. 15а на заявителя или на оправомощени от него лица, се предоставят необходимите права за достъп до Информационната Не се приема Детайлите в отношенията между министерстовто и заявителя на регистъра ще се уреждат между тях със споразумение, не е необходимо на нормативно ниво. система за централизирано изграждане и поддържане на регистри, позволяващи вписване, заличаване и промяна на данни в регистър, както и всички други операции, предвидени в нормативен акт. (2) Миграцията на данните към изградения регистър се извършва от заявителя. Чл. 15б. ал. 2 от проекта на ПМС е посочено, че миграцията на данните към изградения регистър се извършва от заявителя, без да фигурират разпоредби задължаващи. Не съществуват задължения за МЕУ за мерки за обучение и/или издаване на указания/ръководства и за консултации за запознаване на заявителя със задълженията му за работа със информационната система. 3. В чл. 62а, ал. 2 на проекта на ПМС е посочено, заявлението за използване на споделените ресурси на електронното управление се подава по реда на чл. 32 от Наредбата, но в този член не съществуват реално пълностни съответстващи разпоредби. 4. В чл. 62б, т. 5 считам, че наличието или не второ изречение би трябвало технически да се обработи. Не се приема Приема се Предвиден е образец на заявление, който ще се подава по всички възможни начини за комуникация 5. Не съществува яснота изготвянето на справките за себестойността на услугите по чл. 62в от проекта на ПМС за какви цели ще се извършват, публични ли ще са, на заявителите ли ще се предоставят, защото ако е за вътрешно ползване от МЕУ наличието на нормативни разпоредби не е необходимо. Допълнително, предвид разпоредбите на чл. 10а от Закона за електронното управление и това, че таксите за електронните административни услуги не са стимулиращи, а се изчисляват по методиката по чл. 7а на Закона за ограничаване на административното регулиране и административния контрол върху стопанската дейност, това предполага задължително включването на тази себестойност и в размера на разходите за административните услуги, в т. ч. основно за ЕАУ. Предвид това, че по методиката в цената на административните услуги трябва да се включат и разходите за закупуване на специфичен софтуер, база данни, техника, и др., присъщи за услугата, то намаляване на цените за ЕАУ могат да се извършат само по субективен начин, което се Не се приема Макар да е за вътрешни цели справката за потреблението ще дава информация и на консуматорите, включително, че макар и безплатна за администрациите, услугата има себестойност. подразбира ако се извършат реални изчисления. 6. Приложение № 1 към чл. 38, ал. 3 от проекта на ПМС (Техническа спецификация) 6.1. В речник на термини, дефиниции и съкращения - В използвани акроними е посочен ЗЕДЕП (Закон за електронния документ и електронния подпис). Това означава ли, че Техническата спецификация към момента използва нормативни разпоредби от закон, чието наименование е променено от 2017 г., предвид и използването му на други места в текста. - В Дефиниции за нива на електронизация на услугите, които предполагам, че са нивата за предоставяне на услуги съгласно определението в Наредбата за Административния регистър, за нива 3 и 4 това са нивата преди нормативните изменения от 2019 г. - Предвид използването като акроним на ЦАИС (Централизирана автоматизирана информационна система) и липсата на такова определение в нормативната уредба на ЗЕУ, считам за редно такова определение да Приема се Приема се Приема се бъде въведено в Технологичните дефиниции на Техническата спецификация. 6.2. Доколко структурата на възложителя, представена във Фигура 1 предвид изискването да не се изтрива съдържание с наличието на главен секретар, финансов контрольор напълно съответства на структурите на всички възложители. 6.3. По т. 6.1.2 моля да се направят допълнителни проверки доколко към момента цитирания „Модул „Самооценка на административното обслужване“ в Интегрираната информационна система на държавната администрация (ИИСДА)“ все още съществува в Годишния отчет в ИИСДА, аз считам, че от няколко години е премахнат. 6.4. По т. 6.7.1 Съкращението „ИР“ как е образувано. 6.5. По т. 6.7.4 Съкращението „АО“ как е образувано при „потребителите на АО (SLApm)“ 6.6. По т. 6.7.5 критичното влияние върху работните процеси, при Приоритет 1 Приема се Приема се Приема се Приема се Приема се Критичен, само пълното прекъсване на една или повече ЕАУ и недостъпността на ЕАУ ли са критични приоритети. Към някои от останалите информационни системи и софтуерните компоненти в администрацията прекъсването няма ли да е критично, като регистри, интернет страници, вътрешни информационни системи, потребителски интерфейси към съществуващи системи, системи за електронен документооборот. 6.6. По т. 6.7.6 къде и с каква цел се въвежда Съвета за оперативно управление - кои го съставят и какви са му функциите. 6.7. Може би в т. 7.1.1 за яснота би трябвало да се поясни каква по същество е разликата между „предоставят електронни административни услуги“ и „предоставят електронно административни услуги“ след като чрез или се въвеждат и двете. 6.8 Портала за електронно управление в т. 6.1.4 и в 7.1.2 Портала на електронното управление по ЗЕУ ли е? 6.9 Какво означава съкращението ДДУ в израза „унифицираните профили на електронните подписи, Приема се Приема се приема се Приема се издавани от ДДУ в ЕС, в т. 7.2.6.5. 6.10 Каква е причината в т. 7.2.8 в NF69 Спецификацията да отговаря на изискванията за достъпността на Интернет страници и мобилни приложения, съгласно хармонизирания стандарт EN 301 549 V2.1.2 (2018-08), а не на EN 301 549 v3.2.1 (2021-03) или предвид промените да се използва общия израз „последната обнародвана версия“ както в предишни абзац. Приема се 3 m_genov Предложения за промени в §1 до §29 От чл. 21 да отпадне ал. 5, която съдържа изискване, което е частен случай (съдържа се) в ал. 6. Текстът от новата ал. 8 на чл. 24 да се прецизира, така, че да стане ясно, че административните органи предоставят възможност на гражданите за заплащане на такси на електронни административни услуги и други задължения чрез Централен виртуален ПОС терминал, поддържан от министъра на електронното управление. Предложения за промени в Приложение 1 и Приложение 2 1. Предвид, че обхвата на ЗЕУ по чл. 1, ал. 2 се прилага и по отношение на дейността Не се приема Приема се Не се приема Отнася се за уеб базирани потребителски интерфейси, практиката не е показала проблем с прилагане на алинеята. Не е в обхвата на ЗЕУ и посочените лица нямат задължение по чл. 58а от на лицата, осъществяващи публични функции и на организациите, предоставящи обществени услуги, в изискванията на Приложение 1 трябва да се прилагат не само за електронно административни услуги, но и за всички електронни услуги със съответно ниво на електронизация и определено ниво на осигуреност на средствата за идентификация на заявителя. 2. Няма поставени специфични изисквания при внедряване системите за документооборот, както и изискванията за аргументация на целесъобразността при внедряване на готови програмни продукти. 3. Липсва изискване за спазване на формализираните описания на данни, които подлежат на задължително унифициране, както и вписването им в специален регистър на информационните обекти. 4. В Приложение 1 има пропусната номерация на изискванията в таблиците. 5. Да се отразят всички предложени промени от §1 до §29 в НОИИСРЕАУ в Приложение 1 и Приложение 2; Приема се Приема се Приема се Приема се ЗЕУ да съгласуват с министъра подобни технически спецификации 6. Да се уеднаквят изискванията и формата на Приложение 1 и Приложение 2. Приема се 4 kris0640 Необходимо е да се даде възможност на АО да използват готови софтуерни решения със затворен код и да се допълни приложение със следните предложения: 1. Допуска се АО да планират изграждането на информационни системи (BI, ERP, деловодни), които са комерсиален софтуер с лицензи на право на ползване, ако финансовата обосновка за тяхното придобиване е икономически по-изгодна от разработката на софтуерно решение с отворен код. 2. В случай, че се въвежда от АО ИС със затворен код след къстамизация на част от софтуерното решение се прилагат изискванията за интеграция на този софтуер с хоризонталните системи на електронното управление Приема се Не се приема Изискването е включено в т. 7.1.1 Интеграция с външни информационни системи 5. НСОРБ, писмо с вх. №МЕУ-7846 от 29.04.2024 г. I. Принципни бележки: Във връзка с горецитирания проект за изменение и допълнение на НОИИСРЕАУ бихме искали да поставим на вниманието Ви няколко проблема, свързани с практическото Не се приема. По бележката относно проблеми с практическото прилагане на законодателството в областта на електронното управление: Съгласно чл. 7г, ал. 2 от Закона за електронното прилагане на законодателството в областта на електронното управление. 1. Закона за електронното управление (ЗЕУ) и НОИИСРЕАУ не са относими към Закона за публичните финанси (ЗПФ) и Закона за местното самоуправление и местната администрация (ЗМСМА), което поражда редица проблеми, свързани с тяхното практическо прилагане. Съгласно чл. 21 ал. 1 т. 6 от ЗМСМА общинският съвет приема и изменя годишния бюджет на общината, включително и показателите по чл. 45, ал. 1, т. 2 от Закона за публичните финанси (ЗПФ), осъществява контрол и приема отчета за изпълнението му. Едновременно с това ЗПФ определя ясно и категорично общинския съвет като единствен орган по приемане на общинския бюджет, както и регламентира съставянето, изпълнението и отчитането му (чл. 10, ал.1, т. 1, чл. 13, ал. 2, чл. 22, ал. 3, чл. 82, ал. 1, чл. 124, ал. 5, чл. 133, чл. 137 от ЗПФ). Видно от гореизложеното ЗПФ е специален закон, който урежда бюджетната рамка, общото устройство и структурата на публичните финанси, както и регулира съставянето, приемането, промяната, изпълнението и отчитането на бюджетите на общините и не съдържа регламент, изискващ управление (ЗЕУ) „В рамките на бюджетния процес всички административни органи са длъжни предварително да съгласуват с министъра на електронното управление разходите в областта на електронното управление и за използваните от тях информационни и комуникационни технологии. Съгласно определението в Административнопроцес уалния кодекс, към което препраща ЗЕУ (§ 1, т. 1 от ДР), административен орган е органът, който принадлежи към системата на изпълнителната власт, както и всеки носител на административни правомощия, овластен въз основа на закон, включително лицата, осъществяващи публични функции, и организациите, предоставящи обществени услуги. В чл. 19, ал. 3, т. 2 от Закона за администрацията изрично е уточнено, че кметовете на общини, на райони и на кметства и кметските наместници са териториални органи на изпълнителната власт. Няма законови основания общините да бъдат изключени от обхвата на ЗЕУ, респ. от НОИИСРЕАУ. предварително съгласуване на бюджетите от МЕУ. 2. Посочените регламенти в чл. 7г от ЗЕУ и в Раздел I Информационна система за предварителен, текущ и последващ контрол по целесъобразност, Раздел II Регистър на проекти и дейности, Раздел III Регистър на информационните ресурси от Глава шеста Регистри и системи на Министерство на електронното управление от НОИИСРЕАУ са в противоречие на чл. 144 от Конституцията на Р България, съгласно който централните държавни органи и техните представители по места осъществяват контрол само за законосъобразност върху актовете на органите на местното управление, само когато това е предвидено със закон. Съгласно чл. 45, ал. 5 от ЗМСМА, кметът на общината може да върне за ново обсъждане незаконосъобразните или нецелесъобразните актове на общинския съвет или да оспорва незаконосъобразните актове пред съответния административен съд и да иска спиране на изпълнението на общите административни актове и действието на подзаконовите нормативни актове. Законът дава правото на кмета на общината да прецени дали приетите решения от общинските съвети са съобразени с обществените интереси и целите на общината. На база на изложеното, предлагаме да се търси практическо решение чрез въвеждане на нови технологични възможности, включително чрез осъществяване на електронен обмен между системите на МЕУ със системите на ИСУН и МФ, така че общините да бъдат изключени от обхвата на чл. 7г и чл. 7д от ЗЕУ и свързаните с тях текстове в Наредбата за общите изисквания към информационните системи регистрите и електронните административни услуги. II. Конкретни предложения: 1. Предлагаме да се създаде нов параграф на систематичното му място, като думата „дейности“ отпадне от текстовете в Раздел II Регистър на проекти и дейности, от Глава шеста Регистри и системи на Министерство на електронното управление. Мотиви: § 1 от Допълнителните разпоредби към ЗЕУ не дава определение за „дейност“. Това води до нееднозначно тълкуване и затрудняване на администрациите при практическото прилагане на разпоредбите. В контекста на НОИИСРЕАУ може да се тълкува като част от проект, но не и като действия, свързани с ежедневната Не се приема. Предложението за отпадането на думата „дейности“ не може да се реализира без изменение в ЗЕУ, тъй като съгласно чл. 7в, ал. 2, т. 10 от ЗЕУ министърът на електронното управление „утвърждава проектни предложения и дейности, както и изменения на проекти и дейности, координира и контролира изпълнението на проектите за електронно управление, информационни и комуникационни технологии на административните органи, финансирани със средства от държавния бюджет, от структурните експлоатация на системите. Точно такива дейности са посочени в чл. 4 от Методическите указания за определянето на предмета в областта на информационните и комуникационни технологии и електронното управление при изпращане за утвърждаване на проектни предложения и дейности и за удостоверяване на съответствие на технически спецификации на МЕУ от януари 2024 г. В НОИИСРЕАУ следва да отпадне терминът „дейност“, освен ако не е част от проект и не се третира като действия, свързани с текуща поддръжка. 2. По § 24 2.1. Предлагаме в чл. 52, ал. 1, т. 1, буква в) да отпадне текста „информационните и комуникационните технологии в администрациите“. Мотиви: ИКТ са отговорност на съответния административен орган, което е определено както в чл. 43 ал. 3 т. 1 от ЗМСМА, така и в чл. 3 ал. 1 от Наредбата за минималните изисквания за мрежова и информационна сигурност по отношение на МИС. Едновременно с това в т. 14, Раздел II от Приложение № 1 към чл. 25 от Закона за защита на класифицираната информация се определя категория информация, подлежаща на класификация „сведения за Не се приема и инвестиционните фондове на Европейския съюз и от други източници, с прогнозна стойност, по-голяма или равна на стойността на прага по чл. 20, ал. 4, т. 2 от Закона за обществените поръчки;“. По чл. 52, ал. 1, т. 1, буква в) да отпадне текстът „информационните и комуникационните технологии в администрациите“: Предложението за отпаднето на текста „информационните и комуникационните технологии в администрациите“ не може да се реализира без изменение в ЗЕУ. Съгласно чл. 7д от ЗЕУ „Министърът на електронното управление създава и поддържа публичен електронен регистър на проектите в областта на електронното управление, информационните и комуникационните технологии на административните организационно- техническата и програмната защита на комуникационните и информационните системи на органите на държавна власт и местно самоуправление и техните администрации, както и на други техни системи за обработване на информация“. 2.2. Предлагаме в чл. 52, ал. 1, т. 1 да отпаднат букви: б), г), д), е), както и т. 3 Мотиви: Регламентите поставят изисквания, които са неизпълними при въвеждане в регистъра на дейности, свързани с ежедневната експлоатация на системите като поддръжка, доставка на интернет, обновяване на хардуер. 3. По § 25 Предлагаме т. 1 да отпадне Не се приема Не се приема органи с прогнозна стойност по-голяма или равна на стойността на прага по чл. 20, ал. 4, т. 2 от Закона за обществените поръчки, …“. Данните, които е необходимо да се вписват, съгласно чл. 52, ал. 1, т. 1, б. г) и е) и т. 3 са изисквания на чл. 7д, ал. 1, т. 2 и 5 от ЗЕУ и не може да отпаднат. Що се отнася до буква букви б) и д), това е информация, необходима за обективната оценка на представеното проектно предложение във връзка със съответствието му с приетите стратегически документи и държавната политика в областта на електронното управление. Целта на изискването на такива данни е да се гарантира обществения интерес, че дейностите за електронно управление и ИКТ, осъществявани от административните органи, са част от една обща рамка за развитие и дигитализация на държавата, а не се правят „на парче“. Текстът на § 25 регламентира критериите, по които се прави проверката за утвърждаване на Мотиви: Виж мотивите по т. 2.2. проектни предложения и дейности. Този текст улеснява административните органи, тъй като осигурява предвидимост на резултатите от направената проверка и съдържа указания относно информацията, която би трябвало да се съдържа в представените за проверка проектни предложения и дейности. 6 Божидар Божанов, народен представите л, писмо вх. №МЕУ-8290 от 08.05.24 г. 1. § 6, относно чл. 15а следва да се посочи, че заявлението се подава чрез самата система, и подлежи на обработка в нея, а не по общия ред (напр. през ССЕВ или по имейл). Следва да се предвиди и ред за т.нар. self- service, който би трябвало да е приложим за по-прости регистри, т.е. административните органи сами да изграждат регистрите си 2. § 6 относно чл. 15б, ал. 1, предоставянето на заявителя на достъп до системата следва да стане преди изграждането, за да може той да бъде включен в процеса, вкл. с оглед на одобрение на описаните процеси, полета и др. 3. § 6 относно чл. 15б, ал. 2, миграцията на данните не може да бъде задължение само на заявителя. Миграцията на данните е неразделна част от Не се приема Не се приема Приема се След изграждане на системата такава функционалност ще бъде налична и процедурата по заявяване ще бъде разписана в Общи условия или правила. По т. 2 С цел гарантиране сигурността и качеството на структурата на изгражданите регистри такава функционалност не е предвидена, включително и облекчаване на АО с липса на достатъчен капацитет в тази област. Миграцията на данните към изградените регистри се извършва от заявителя със изграждането на регистъра, тъй като някои решения за неговата структура следва да бъдат взети с оглед наличния формат на данните и възможностите за техните трансформации. 4. В § 11 не следва да се отменят действащите разпоредби, тъй като те предвиждат задължения за случаите, в които плащането не се извършва чрез централния виртуален пос- терминал на МЕУ 5. В § 17 в т.3 предлагам след думите “информационна система” да се добавят “и данните в нея” 6. С § 19 не следва да се отменят действащите разпоредби на чл. 45; липсват и мотиви за отпадане на необходимостта от тези разпоредби 7. В § 20 е използвана недобра нормативна техника с изреждане на примерни домейни. Примерите могат да бъдат част от мотивите. 8. В § 20 вместо “като поддомейни” следва да се използва “на поддомейни”. 9. В § 21 изразът „административните органи (централни и местни)” следва да се замени с думите “административните органи на централната и местната власт” 10. В § 26 не е препоръчително да се посочват конкретни интернет адреси. Думата “git” е наименование на конкретна технология за управление на версиите, Приема се Приема се Не се приема Приема се Приема се Приема се Не се приема съдействието на МЕУ/ИАИЕУ. Правилата на чл. 45 се съдържат в Закона за киберсигурност и Наредбата за минималните изисквания за мрежова и информационна сигурност (НМИМИС), към които е предвидено препращане в нормата, като чл. 45, ал. 1 от Наредбата се съдържа в чл. 24 от НМИМИС. По отношение на думата “git” тя е посочена в конкретни интернет адреси, както е било в до сега действащата редакция. поради което е добре да не бъде включвана в нормативен акт. 11. Предлагам с преходни и заключителни разпоредби да се създаде нова точка в чл. 28, ал. 1 от Наредбата за обмена на документи в администрацията със следния текст: “5. Данни за квалифициран електронен времеви печат на регистрирания документ” 12. § 28 се предвижда административен ред за заявяване на ресурси, който е ограничаващ спрямо концепцията за облачна инфраструктура - облачната инфраструктура е “еластична” и не следва да има одобрение на искания за предоставяне на ресурси. Одобрението за използване следва да бъде еднократно и без оглед на ресурсите, като всек ползвател следва да може да определи (без намеса от страна на МЕУ или ИА ИЕУ) на необходимите виртуални ресурси. Моля да разгледате долните предложения за текстове и структура на главата, в които е залегнала концепцията за заделяне на ресурси по преценка на ползвателя до определен лимит и преоразмеряването им след преглед на реалното използване: Раздел I Държавен хибриден частен облак Не се приема Не се приема Предложението не е мотивирано и не съответства на чл. 28, ал. 1 от Наредбата за обмена на документи в администрацията. Не сме съгласни с твърдението, че предвиденият в § 28 административен ред за заявяване на ресурси е ограничаващ. Капацитетът, с който разполага МЕУ за споделени ИР не е неограничен и следва внимателно да се планира и управлява предоставянето му за ползване от АО. От друга страна, всеки АО преди да заяви съответния ресурс следва внимателно да направи калкулация на капацитета и параметрите на ресурсите, които ще заяви, включително и нарастването им за бъдещ период от време – по отношение на процесори, оперативна памет, дисково пространство и пр. Заявяване на ресурси в държавния хибриден частен облак Чл. 62а. (1) Административните органи заявяват еднократно достъп до Държавния хибриден частен облак с писмено заявление до министъра на електронното управление. (2) Оправомощени длъжностни лица в административните органи заявяват чрез потребителски интерфейс необходимите изчислителни ресурси за инсталирането и оперирането на информационните си системи. (3) Заявените ресурси не могат да надвишават предварително определени ограничения от министъра на електронното управление, освен след негово одобрение по писмено искане на съответния административен орган (4) Публичноправни организации, които не са административни органи, могат да заявяват изчислителен ресурс в Държавния хибриден частен облак чрез договор, сключен в хипотезата на на чл. 13, ал. 1, т. 14 от Закона за обществените поръчки, като за целта заплащат ежемесечно сумата, предвидена в чл. 62д. Министърът на електронното управление не е длъжен да одобри включването на Липсват мотиви за предложените редакции, като част от предложенията са дадени само като структура на разпоредбите, без съдържание. организациите по предходното изречение. Присъединяване на ресурси към държавния хибриден частен облак Чл. 62б. (1) Административните органи могат да заявят присъединяване на информационни ресурси, които са тяхна собственост, към Държавния хибриден частен облак. (2) При присъединяване на информационни ресурси по ал. 1, собствеността върху тях се прехвърля към Изпълнителна агенция “Инфраструктура на електронното управление”. (3) Присъединяването се ръководи от оправомощено от министъра на електронното управление длъжностно лице. Мониторинг и преглед на използването на заявени ресурси Чл. 62в. (1) Изпълнителна агенция “Инфраструктура на електронното управление” осигурява наблюдение на използваните изчислителни ресурси в Държавния хибриден частен облак. (2) Изпълнителна агенция “Инфраструктура на електронното управление” оказва методическа помощ на административните органи при определянето на необходимите изчислителни ресурси. (3) Изпълнителният директор на Изпълнителна Не подкрепя предложеното в чл. 62б и счита, че „присъединяване“ на оборудване в този вид е лоша практика, която не е в унисон с ефективното управление на споделени инфраструктурни ресурси. Заедно с това предлага усилията да са насочат към възможностите за резервиране в ДХЧО на информационни ресурси които са on premise (при административния орган). По чл. 62в, ал. 2: Определянето на необходимите изчислителни ресурси се извършва на етап проектиране. В процеса на изграждането и тестването, необходимите ресурси може да се коригират. В този смисъл определянето на необходимия ресурс се извършва от Разработчика. Предлага задължението по предварително агенция “Инфраструктура на електронното управление” веднъж месечно публикува доклад за използваните изчислителни ресурси в Държавния хибриден частен облак, в т.ч.: 1. средномесечно използване на наличните процесори 2. средномесечно използване на наличната оперативна памет 3. Средномесечно използване на дисково пространство (4) Изпълнителният директор на Изпълнителна агенция “Инфраструктура на електронното управление” представя на министъра на електронното управление доклад с данните по ал. 3 за всеки ползвател - административен орган или друга публичноправна организация. (5) Веднъж месечно изпълнителният директор на Изпълнителна агенция “Инфраструктура на електронното управление” уведомява ползвателите на Държавния хибриден частен облак, в случай, че заявените от тях ресурси значително надвишават използваните. (6) Един месец след изпратено уведомление по ал. 5, оправомощени от Изпълнителния директор на Изпълнителна агенция “Инфраструктура на електронното управление” намаляват заявените изчислителни ресурси за съответните административни органи, определяне на необходимите изчислителни ресурси да се вмени на съответния административен орган, в чиито интерес те се предоставят. По чл. 62в, ал. 3: Публикуване на тази информация в нейната цялост е свързана с конкретни стойности и параметри на самия ДХЧО и до голяма степен е чувствителна. Тези данни са неразделна част от месечните доклади на ИА ИЕУ до министъра на електронното управление. Публичната информация по-скоро трябва да отразява степента на използване на различните услуги от държавните ведомства, което е и предложението на ИА ИЕУ. По чл. 62в, ал. 5: Такова уведомление не е необходимо, тъй като всяка организация- потребител чрез потребителски интерфейс (Чл. 62а, ал. 3 от предложенията) има достъп до пълна статистика за предоставения и използвания ресурс. По чл. 62в, ал. 6: становище на ИАИЕУ: Текстът противоречи на предложеното в чл. 62а, ал. 3, според който които не са предприели действия за намаляване на заявения изчислителен ресурс. Надграждане на Държавния хибриден частен облак Чл. 62г. (1) Изпълнителният директор на Изпълнителна агенция “Инфраструктура на електронното управление”, съгласувано с министъра на електронното управление, осигурява надграждането на Държавния хибриден частен облак. (2) Надграждането по ал. 1 се извършва по реда на Закона за обществените поръчки при достигане на нива на средномесечно и пиково потребление на изчислителните ресурси, което би застрашило функционирането на информационните системи, разположени в Държавния хибриден частен облак. (3) Надграждането се осъществява при съобразяване на планираните информационни системи по реда на чл. 7д от ЗЕУ. Остойностяване на използваните ресурси Чл. 62д. (1) Министерският съвет, по предложение на министъра на електронното управление приема методика за остойностяване на използваните изчислителни ресурси в Държавния хибриден частен облак. (2) Изпълнителният директор на Изпълнителна агенция “Инфраструктура на заявените ресурси могат да надвишават предварително определените след одобрение от министъра на електронното управление по писмено искане на съответния административен орган Информационните системи и данните в тях са собственост на съответните държавни институции и отговорността за тях са определени в нормативни актове. Очевидно в предложението под информационни ресурси се визират хардуерни средства. Присъединяването в този вид ще доведе до значителни трудности, а много вероятно и до невъзможност за интегрирането на разнороден хардуер в инфраструктурата на ДХЧО. Със сигурност това ще доведе и до значителни затруднения в гаранционната и извънгаранционната му поддръжка впоследствие. Процесът е регламентиран добре и са определени задачите и отговорностите на заинтересованите структури – както на ползвателите така и на предоставящите услугата. Единствената корекция, която може да се направи електронното управление” веднъж месечно изпраща детайлен отчет за финансовата стойност на използваните изчислителни ресурси на: 1. министъра на електронното управление 2. министъра на финансите 3. административните органи за използвания от тях изчислителен ресурс Раздел II Единна електронна съобщителна мрежа Присъединяване към единната електронна съобщителна мрежа Чл… Качество на услугата на ЕЕСМ Чл… Регистър на мрежите в ЕЕСМ Чл… Раздел III Защитен интернет възел Присъединяване към защитения интернет възел Чл… (1) Административните органи са длъжни да използват Защитения интернет възел. (2) Определени от министъра на електронното управление длъжностни лица управляват: … по предоставения за обществено обсъждане Проект е по отношение на ал. 2 на чл. 62г. Информацията, съдържаща се в алинеята на практика ще бъде включена в цитирания в ал. 1 на същия член “Каталог на услугите“, като се предвижда тя да бъде по-пълна и да се обновява динамично при промяна на типа на оборудването или конкретните стандарти (което заложено в нормативен документ като Наредбата е възможно едва на една- две години).

Проект! ДО МИНИСТЕРСКИЯ СЪВЕТ НА РЕПУБЛИКА БЪЛГАРИЯ ДОКЛАД От Александър Йоловски – министър на електронното управление ОТНОСНО: Проект на Постановление на Министерския съвет за приемане на проект на Наредба за изменение и допълнение на Наредбата за общите изисквания към информационните системи регистрите и електронните административни услуги. УВАЖАЕМИ ГОСПОДИН МИНИСТЪР-ПРЕДСЕДАТЕЛ, УВАЖАЕМИ ГОСПОЖИ И ГОСПОДА МИНИСТРИ, На основание чл. 31, ал. 2 от Устройствения правилник на Министерския съвет и на неговата администрация, внасям за разглеждане от Министерския съвет на проект на Постановление на Министерския съвет за приемане на проект на Наредба за изменение и допълнение на Наредбата за общите изисквания към информационните системи регистрите и електронните административни услуги (НОИИСРЕАУ). Целта на изготвения проект е привеждане на подзаконовата нормативна уредба, регламентираща общите изисквания към информационните системи, регистрите и електронните административни услуги в съответствие с измененията и допълненията в Закона за електронното управление (ЗЕУ, обнародвани с ДВ, бр. 80 от 19.09.2023 г.). Законът предвижда структурата и функционалностите на електронните регистри на административните органи, одита на системата за сигурно електронно връчване, реда за заявяване и използване на регистър чрез системата за централизирано изграждане на регистри, както и други съществени изменения, да бъдат уредени в Наредбата за общите изисквания към информационните системи, регистрите и електронните административни услуги (Наредбата). Със Закона за изменение и допълнение на Закона за държавния бюджет (обн. ДВ, брой 66 от 01.08.2023 г.) са направени допълнения в чл. 17 от Закона за електронното управление (ЗЕУ). Съгласно новата ал. 4 административните органи използват споделените ресурси на електронното управление съгласно стандарти и по ред, определени в Наредбата. Новите текстове ще спомогнат за реализацията на целите на регистровата реформа, по отношение на оптимизиране на организацията на регистрите в държавната администрация, поддръжката им с възможно най-малко разходи, служебният обмен на информация и данни за предоставяне на качествени услуги, възможността за предоставяне на услуги, базирани на регистрите, водени от други административни органи, качеството, пълнотата и всеобхватността на данните, осигуряването на възможности за използване и повторно използване на вече налични данни в публичния сектор от всички заинтересовани страни. Във връзка с гореизложеното възниква необходимостта от изменения и допълнения на Наредбата за общите изискван към информационните системи, регистрите и електронните административни услуги (НОИИСРЕАУ). Основните предложения за изменения и допълнения касаят: Определяне на ред за използване на споделените ресурси на електронното управление. Споделените ресурси на електронното управление са техническата инфраструктура, единната електронна съобщителна мрежа, информационните центрове, държавния хибриден частен облак и защитеното споделено информационно пространство, които се създават и развиват от Министерство на електронното управление и се използват споделено от всички държавни органи. Към момента няма нормативно въведен ред за тяхното използване. С допълненията в чл. 17 от ЗЕУ се въвежда изискването за определянето на този ред в НОИИСРЕАУ. За целта се създава нова глава шеста „а“ „Използване на споделените ресурси на електронното управление“ . 2. Въвеждане на реда за заявяване използването на регистър чрез Информационна система за централизирано изграждане и поддържане на регистри. Съгласно чл. 52а от ЗЕУ министърът на електронното управление създава и поддържа информационна система за централизирано изграждане и поддържане на регистри. Редът за заявяване и използване на регистър чрез системата по ал. 1 се урежда с наредбата по чл. 12, ал. 4 от ЗЕУ. 3. Въвеждане на изисквания към структурата, функционалностите и удостоверяването на данни от регистрите в електронен вид на административните органи. С чл. 4а, ал. 2 от ЗЕУ е въведено задължението административните органи да водят регистрите си в електронен вид, в сила от 31.03.2024 г. Последиците от липсата на електронни регистри са няколко: създаване на административна тежест за гражданите, бизнеса и администрацията за доказване на обстоятелства в рамките на процеса по административно обслужване, рискове за загуба на данни, рискове за целостта на данните, в т. ч. неоторизирана подмяна на данни, липса на проследимост и история на промените и липса на прозрачност за данните във водените регистри и невъзможност за администрациите да изпълнят задълженията си по Закона за достъп до обществена информация. С чл. 52б от ЗЕУ се въвеждат общи правила за воденето на регистри, като общите изисквания към регистрите, включително за тяхното структуриране, функционалности и удостоверяване на данни, се определят с Наредбата. 4. Създаване на допълнителни стимули за използване на административни услуги по електронен път и устойчиво регламентиране на института на посредника при предоставяне на административни услуги. За заявяване на електронните административни услуги към настоящия момент се дължи такса, равна на тази за заявяване на гише, освен ако в специален закон изрично не е уредено друго. Това не дава възможност на административните органи да стимулират използването на електронни административни услуги чрез финансовия им параметър. В допълнение, въведеният през 2016 г. институт на посредника при заявяване на административни услуги не функционира отчасти заради липса на устойчив бизнес модел свързан с таксите. В чл. 24а от ЗЕУ е регламентирана фигурата на посредника, като изискванията към дейността на посредниците, към доставчиците на електронни административни услуги във връзка с посредничеството и правилата за извършване на плащания към доставчиците на услугите се уреждат с Наредбата. Чрез предложения проект за изменение и допълнение на НОИИСРЕАУ: - ще се регламентира реда за използване на споделените ресурси на електронното управление от административните органи; - ще се въведе механизъм за контрол върху създаването и функционирането на регистри в администрацията както на централно, така и на местно ниво; - ще се осигури яснота относно заявяването и използването на административни услуги, предоставяни по електронен път. - ще се постигне сериозен напредък в осигуряване на оперативната съвместимост на регистрите на лицата по чл. 1, ал. 2 от ЗЕУ. Предложеният проект на постановление не води до въздействие върху държавния бюджет, като е изготвена финансова обосновка по приложение № 2.2 към чл. 35, ал. 1, т. 4, буква „б“ от УПМСНА, одобрена от министъра на финансите. Настоящият доклад и проект са съгласувани съгласно чл. 32 и чл. 33 от Устройствения правилник на Министерския съвет и на неговата администрация. На основание чл. 26, ал. 2 от Закона за нормативните актове по проекта на Постановлението е проведена обществена консултация. Резултатите от нея са отразени в приложената справка-таблица. УВАЖАЕМИ ГОСПОДИН МИНИСТЪР-ПРЕДСЕДАТЕЛ, УВАЖАЕМИ ГОСПОЖИ И ГОСПОДА МИНИСТРИ, Предвид гореизложеното и на основание чл. 8, ал. 4, т. 1 от Устройствения правилник на Министерския съвет и на неговата администрация предлагам Министерският съвет да разгледа и приеме проекта на Постановление на Министерския съвет за приемане на проект на Наредба за изменение и допълнение на Наредбата за общите изисквания към информационните системи регистрите и електронните административни услуги. С уважение, АЛЕКСАНДЪР ЙОЛОВСКИ Министър на електронното управление

Образецът на частична предварителна оценка на въздействието влиза в сила от 01 януари 2021 г. Частична предварителна оценка на въздействието Институция: Министерство на електронното управление Нормативен акт: Проект на Постановление на МС за изменение на Наредбата за общите изисквания към информационните системи, регистрите и електронните административни услуги. ……………………………………………… Лице за контакт: Стоян Цонев директор на дирекция „Политики за електронно управление“. Телефон и ел. поща: 02/ 949 24 17 s.tsonev@egov.government.bg. 1. Проблем/проблеми за решаване: Проблем „Липса на нормативен ред за прилагане на измененията на Закона за електронно управление, обнародван с ДВ бр. 80 от 19.09.2023 г.“ В заложената в Плана за възстановяване и устойчивост на Република България Реформа 6 - „Регистрова реформа за разгръщане потенциала на електронното управление за подобряване на бизнес средата“ от компонент 10 „Бизнес среда“, е предвидено изменение и допълнение на Закона за електронното управление, свързано с въвеждане на правила за създаване на регистри от административните органи и изискванията към тях; въвеждане на определения за „регистър“, „информационна система“, „централен администратор на данни“; въвеждане на дефиниция за защитеното споделено информационно пространство на електронното правителство. Възникнала е необходимост от привеждане на подзаконовата нормативна уредба, регламентираща общите изисквания към информационните системи, регистрите и електронните административни услуги в съответствие със Закона за електронното управление (ЗЕУ), чиито последни изменения и допълнения са обнародвани с ДВ бр. 80 от 19.09.2023 г. В ЗЕУ са заложени редица реформи, които имат съществен принос към развитие на електронното управление и осигурят и цифрова трансформация на страната. Те са в изпълнение на Актуализираната стратегия за за развитие на електронното управление в Република България (2019 – 2025) и актуализираната Концепция за регистрова реформа (Приложение 2 към Актуализираната стратегия). Технологичните и административни процеси, които стоят зад тези реформи, следва да намерят своето място в подзаконовата нормативна уредба. Законът предвижда редът и начинът за прилагане на новите норми по отношение на регистрите на административните органи, споделените ресурси на електронното управление, електронните административни услуги, както и други съществени изменения, да бъдат уредени чрез Наредбата за общите изисквания към информационните системи, регистрите и електронните административни услуги (Наредбата). В тази връзка предлаганите изменения на Наредбата следват логическите промени в закона и са в следните направления: 1. Определяне на стандартите и реда за използване от административните органи на споделените ресурси на електронното управление – по чл. 17, ал. 4 ЗЕУ; 2. Въвеждане на правилата за провеждане на одит на системата за сигурно електронно връчване, поддържана от Министерството на електронното управление – по чл. 26а, ал. 2 ЗЕУ 3. Редът за заявяване и използване на регистър чрез информационната система за централизирано изграждане и поддържане на регистри – по чл. 52а, ал. 4 ЗЕУ; 4. Допълване на изискванията към дейността на посредниците на електронни административни услуги – по чл. 24а от ЗЕУ; 5. Хармонизация на контрола в рамките на бюджетния процес със сроковете и указанията по бюджетните прогнози и процедури, утвърдени от Министерство на финансите, както и създаване на опростена техническа спецификация за утвърждаване по чл. 58а от ЗЕУ във връзка със задължението на администрациите за адаптиране на информационните им системи за работа с евро по Националния план за въвеждане на еврото в Република България, Приет с Решение на МС № 797 от 13 ноември 2023 г. – по чл. 7г от ЗЕУ. 1.1. Кратко опишете проблема/проблемите и причините за неговото/тяхното възникване. По възможност посочете числови стойности. 1.3. Посочете защо действащата нормативна рамка не позволява решаване на проблема/проблемите. Споделените ресурси на електронното управление са техническата инфраструктура, единната електронна съобщителна мрежа, информационните центрове и държавния хибриден частен облак, които се създават и развиват от Министерство на електронното управление и се използват споделено от всички държавни органи. Към момента няма нормативно въведен ред за тяхното използване. С допълненията в чл. 17 от ЗЕУ се въвежда изискването за определянето на този ред в НОИИСРЕАУ. За целта се създава нова глава шеста „а“ „Използване на споделените ресурси на електронното управление“, което ще уеднакви стандартите при предоставяне на електронни административни услуги посредством портала на електронното управление. Съгласно чл. 52а от ЗЕУ министърът на електронното управление създава и поддържа информационна система за централизирано изграждане и поддържане на регистри. Редът за заявяване и използване на регистър чрез системата по ал. 1 се урежда с наредбата по чл. 12, ал. 4. С чл. 52б от ЗИД на ЗЕУ се въвеждат общи правила за воденето на регистри, като общите изисквания към регистрите, включително за тяхното структуриране, функционалности и удостоверяване на данни, които се определят с НОИИСРЕАУ, във връзка с новото изискване на чл. 4а от ЗЕУ административните органи да водят всички регистри и бази данни в електронна форма. Последиците от липсата на регламентиран ред за водене и поддържане на регистрите на административните органи изцяло електронно са няколко: създаване на административна тежест за гражданите, бизнеса и администрацията за доказване на обстоятелства в рамките на процеса по административно обслужване; рискове за загуба на данни; рискове за целостта на данните, в т. ч. неоторизирана подмяна на данни; липса на проследимост и история на промените; липса на прозрачност за данните във водените регистри и невъзможност за администрациите да изпълнят задълженията си по Закона за достъп до обществена информация. В чл. 24а от ЗЕУ е регламентирана фигурата на посредникa при заявяване на електронни административни услуги, като изискванията към дейността на посредниците, към доставчиците на електронни административни услуги във връзка с посредничеството и правилата за извършване на плащания към доставчиците на услугите се уреждат с наредбата по чл. 12, ал. 4, но с по-разширена законова делегация. Посочените изменения в Наредбата директно произтичат от измененията в Закона за електронно управление, обнародвани с ДВ бр. 80 от 19.09.2023 г. и § 13 от ПЗР на Закона за държавния бюджет на Република България за 2023 г., обн. с ДВ, бр. 66 от 01.08.2023 г. 1.4. Посочете задължителните действия, произтичащи от нормативни актове от по-висока степен или актове от правото на ЕС. 1.5. Посочете дали са извършени последващи оценки на нормативния акт или анализи за изпълнението на политиката и какви са резултатите от тях? Не е извършена последваща оценка на нормативния акт. 2. Цели: Цел 1 „Определяне на реда и изискванията за прилагане на ключовите изменения в ЗЕУ“ Регламентирането на реда и изискванията към воденето и поддържането на електронните регистри на административните органи ще спомогне за реализацията на целите на регистровата реформа, по отношение на: оптимизиране на организацията на регистрите в държавната администрация; поддръжката им с възможно най-малко разходи; служебният обмен на информация и данни за предоставяне на качествени услуги; възможността за предоставяне на услуги, базирани на регистрите, водени от други административни органи; качеството, пълнотата и всеобхватност на данните; осигуряване на възможности за използване и повторно използване на вече налични данни в публичния сектор от всички заинтересовани страни. В изпълнение на визията за развитие на електронното управление в Република България е заложена трансформация на модела на предоставяне на електронни административни услуги, ориентирани към потребителя, чрез промяна на технологичните и административни процеси, които стоят зад тях, с резултат намаляване на административната тежест за гражданите и за бизнеса. Чрез създаването на ясен ред за използване на споделените ресурси от административните органи за електронното управление ще се подобри качеството на предоставяните електронни административни услуги и ще се намали административната тежест за гражданите и бизнеса. Чрез посочените промени ще се осигури техническата и процедурната приложимост на нормативните разпоредби на ЗЕУ, както и създаване на технологични възможности за още по-добро функциониране на института на посредника при заявяване на електронни административни услуги в отдалечените селски райони, където администрацията няма присъствие, от граждани, които не притежават компютърна грамотност и за по-бързо, по-качествено и ефективно административно обслужване. Чрез планираните процедури за одитиране на системата за сигурно електронно връчване (ССЕВ) ще бъде повишена сигурността на ССЕВ и съответно повишено доверието в системата. Системата е ключов канал за комуникация и физическите лица ще могат лесно и сигурно да използват електронни административни услуги и ще могат да получават по електронен път актове за установяване на административни нарушения, фишове и наказателни постановления. Планираните изменения по отношение на контрол в рамките на бюджетния процес целят да се минимизират грешките от страна на администрациите, както и публично и прозрачно планиране и разходване на бюджетните средства. Посочете определените цели за решаване на проблема/проблемите, по възможно най-конкретен и измерим начин, включително индикативен график за тяхното постигане. Целите е необходимо да са насочени към решаването на проблема/проблемите и да съответстват на действащите стратегически документи. 3. Заинтересовани страни: Административни органи - 598, включително 265 общини Всички административни органи, както и всички 265 общини, са засегнати и следва да прилагат промените в Наредбата. Всички ще могат да се възползват от възможностите за обмен на данните, използване на споделените ресурси на електронното управление, които следва да предоставят на гражданите и бизнеса в изпълнение на техни законови правомощия. Физически лица - по данни от Националния статистически институт за 2022 г. Всички физически лица ще могат лесно и сигурно да използват електронни административни услуги. Административната тежест ще бъде намалена, тъй като задължението за предоставяне на различни видове удостоверения, издадени от един административен орган пред друг, се изисква да се извършва по служебен път, включително чрез служебни справки от съответните регистри чрез централен компонент, поддържан от МЕУ, уреден в НОИИСРЕАУ. Именно това е една от основните цели на политиката за развитие на електронното управление от 2017 г. насам. Юридически лица Всички юридически лица ще могат да използват сигурни електронни административни услуги Административната тежест ще бъде намалена, както и времето за предоставяне на различни видове удостоверения, издадени от административен орган директно или пред друг административен орган. Организации, предоставящи обществени услуги и лица, осъществяващи публични функции Енергоразпределителните дружества, ВиК дружествата, телекомуникационните оператори, банките, застрахователните дружества, нотариусите, частните съдебни изпълнители, публичните възложители по чл. 5 от ЗОП, доставчици на удостоверителни услуги, доставчици на пощенски услуги, здравни заведения, образователни учреждения, поддържащи данни, които предоставят административни услуги на гражданите, ще се наложи да изградят или надградят регистрите си, когато са първични администратори на данни. Посочете всички потенциални заинтересовани страни/групи заинтересовани страни (в рамките на процеса по извършване на частичната предварителна частична оценка на въздействието и/или при обществените консултации по чл. 26 от Закона за нормативните актове), върху които предложенията ще окажат пряко или косвено въздействие (бизнес в дадена област/всички предприемачи, неправителствени организации, граждани/техни представители, държавни органи/общини и др.). 4. Варианти на действие. Анализ на въздействията: 4.1. По проблем 1: Вариант 1 „Без действие“: Описание: При Вариант „Без действие” не се предвижда предприемането на измененията на Наредбата за общите изисквания към информационните системи, регистрите и електронните административни услуги , което ще доведе до неизпълнение на чл. 17, ал. 4, чл. 26а, ал. 2, чл. 52а, ал. 4, чл. 24а и чл. 7г от ЗЕУ. Положителни (икономически/социални/екологични) въздействия: При вариант „Без действие“ върху посочените в т. 3 заинтересовани страни не се отчита положително в икономически, социален и екологичен аспект въздействие. (върху всяка заинтересована страна/група заинтересовани страни) Отрицателни (икономически/социални/екологични) въздействия: Вариант „Без действие“ води до практическа невъзможност за приложение на измененията в Закона за електронното управление и създава правна празнота в нормативната уредба. Върху посочените в т. 3 заинтересовани страни в икономически, социален и екологичен аспект се отчита повишаване на риска от: занижено качество на административните услуги и невъзможност в някои случаи за служебно събиране на факти и обстоятелства, налични в регистър; занижено качество и нереализиране на вътрешни електронни административни услуги; понижаване на организационната и бюджетна ефективност; по-ниска ефективност на взаимодействието между всички участници в процеса по административно обслужване; липса на благоприятно въздействие върху околната среда чрез премахване на значителен обем от хартиен документооборот; допълнителна административна тежест при достъпността на административни услуги за гражданите в отдалечени населени места и в чужбина; липса на ресурси за осъществяване на други административни функции; по-ниско ниво на сигурност при електронното връчване на актове и документи; по-ниско доверие в институциите. (върху всяка заинтересована страна/група заинтересовани страни) Специфични въздействия: Въздействия върху малките и средните предприятия Малките и средни предприятия като потребители на административни услуги са силно уязвими към посочените отрицателни въздействия, свързани с утежненото административно обслужване Административна тежест: При този вариант на действие административната тежест върху потребителите на административни услуги ще остане висока. За потребителите в отдалечени точки поради съпътстващи разходи при заявяване на административни услуги има риск да станат недостъпни. Запазването на високи нива на административната тежест за гражданите и бизнеса, и като цяло за ползвателите на административни и/или обществени услуги би довело до административни нарушения и намаляване на събираемостта на данъци и такси. 1.1. Опишете качествено (при възможност – и количествено) всички значителни потенциални икономически, социални и екологични въздействия, включително върху всяка заинтересована страна/група заинтересовани страни. Пояснете кои въздействия се очаква да бъдат значителни и кои второстепенни. 1.2. Опишете специфичните въздействия с акцент върху малките и средните предприятия и административната тежест (задължения за информиране, такси, регулаторни режими, административни услуги и др.) Вариант 2 „Хармонизиране на нормите на Наредбата за общите изисквания към информационните системи, регистрите и електронните административни услуги в съответствие с измененията на Закона за електронно управление, обнародван с ДВ бр. 80 от 19.09.2023 г.“: Описание: При този вариант се предвижда предприемането на действия за адаптиране на подзаконовата нормативна уредба в областта на електронното управление към Закона за електронното управление, включително, но не само относно реда и изискванията за водене на електронни регистри, а именно изисквания за структурирането, функционалностите и удостоверяването на данни от регистрите; реда и стандартите за ползване на споделените ресурси, като ще се разпише общ ред за всички споделени ресурси; на системата за сигурно електронно връчване, като се предвижда уреждане на правилата за одит на системата от външен изпълнител най-малко на всеки две години. Предложените нормативни изменения предвиждат и повишаване на сигурността на системата за сигурно електронно връчване и обезпечаване на възможността за електронна комуникация и електронно връчване на актове в процеса по административно наказване. Предвижда се в НОИИСРЕАУ организациите, предоставящи обществени услуги и лицата, осъществяващи публични функции да могат да използват безплатно информационната система за централизирано изграждане на регистри за изграждане и използване на електронните им регистри. Предвижда се ясно регламентиране на сроковете за подаване на информация до МЕУ от страна на административните органи в изпълнение на техни задължения във връзка с бюджетния и проектния контрол относно разходите им в областта на електронното управление и ИКТ. Ще бъдат преодолени идентифицираните проблеми, свързани със заниженото качество на електронното административно обслужване и неефективността на процесите по осъществяването му. Наличието на гаранции за сигурността на ССЕВ съществено улеснява работните процеси, намалява разходите както за гражданите и бизнеса, така и за администрацията и лицата по чл. 1, ал. 2 от ЗЕУ и подобрява организационната ефективност. Положителни (икономически/социални/екологични) въздействия: Върху посочените в т. 3 заинтересовани страни ще има положително в икономически, социален и екологичен аспект въздействие, изразяващо се в: - по-високо качество на административните услуги; - по-добро качество и реализиране на изцяло електронни административни услуги и вътрешни електронни административни услуги; - повишаване на организационната и бюджетна ефективност; - по-висока ефективност на взаимодействието между всички участници в процеса по административно обслужване; - наличие на значително благоприятно въздействие върху околната среда чрез премахване на съществен обем от хартиен документооборот; - освобождаване на ресурси за осъществяване на други административни функции; - Постигане на основни цели на регистровата реформа; - по-високо ниво на сигурност за управление на данните и ресурсите; - оперативна съвместимост и надеждност на регистрите; - по-високо доверие в институциите. (върху всяка заинтересована страна/група заинтересовани страни) Отрицателни (икономически/социални/екологични) въздействия: Върху посочените в т. 3 заинтересовани страни не се идентифицира отрицателно въздействие в икономически, социален и екологичен аспект. (върху всяка заинтересована страна/група заинтересовани страни) Специфични въздействия: Въздействия върху малките и средните предприятия: Предложените нормативни промени ще доведе до повишаване на качеството на електронното административно обслужване, намаляване на времето за предоставяне на административни услуги и намаляване на разходите за най-голямата категория представители на бизнеса - МСП. Това ще насърчи използването на електронни административни услуги от страна на бизнеса. Административна тежест: Повишаването на качеството на електронното административно обслужване, повишаване на сигурността на електронните услуги неминуемо ще доведе до намаляване на административната тежест за гражданите и бизнеса, като цяло намаляване на разходите за всички страни участващи в процеса на предоставяне и ползване на административни услуги. …………………………………………………………. ………………………………………………………………………………………….. (въздействията върху малките и средните предприятия; административна тежест) 1.1. Опишете качествено (при възможност – и количествено) всички значителни потенциални икономически, социални и екологични въздействия, включително върху всяка заинтересована страна/група заинтересовани страни. Пояснете кои въздействия се очаква да бъдат значителни и кои второстепенни. 1.2. Опишете специфичните въздействия с акцент върху малките и средните предприятия и административната тежест (задължения за информиране, такси, регулаторни режими, административни услуги и др.) 5. Сравняване на вариантите: Степени на изпълнение по критерии: 1) висока; 2) средна; 3) ниска. 5.1. По проблем 1: Вариант „Без действие“ Вариант 1 Ефективност Цел 1: „Определяне на реда и изискванията за прилагане на ключовите изменения в ЗЕУ“ 3 1 Ефикасност Цел 1: „Определяне на реда и изискванията за прилагане на ключовите изменения в ЗЕУ“ 3 1 Съгласуваност Цел 1: „Определяне на реда и изискванията за прилагане на ключовите изменения в ЗЕУ“ 3 1 1.1. Сравнете вариантите чрез сравняване на ключовите им положителни и отрицателни въздействия. 1.2. Посочете степента, в която вариантите ще изпълнят определените цели, съгласно основните критерии за сравняване на вариантите: ефективност, чрез която се измерва степента, до която вариантите постигат целите на предложението; ефикасност, която отразява степента, до която целите могат да бъдат постигнати при определено ниво на ресурсите или при най-малко разходи; съгласуваност, която показва степента, до която вариантите съответстват на действащите стратегически документи. 6. Избор на препоръчителен вариант: По проблем 1: Вариант 2 „Хармонизиране на нормите на Наредбата за общите изисквания към информационните системи, регистрите и електронните административни услуги в съответствие с измененията на Закона за електронно управление, обнародван с ДВ бр. 80 от 19.09.2023 г. “ …………………………………………………………………..……………………… …………………………………………………………………………………………. Посочете препоръчителните варианти за решаване на поставения проблем/проблеми. 6.1. Промяна в административната тежест за физическите и юридическите лица от прилагането на препоръчителния вариант (включително по отделните проблеми): Повишаването на качеството на електронното административно обслужване, повишаване на сигурността на електронните услуги неминуемо ще доведе до намаляване на административната тежест за гражданите и бизнеса, като цяло намаляване на разходите за всички страни участващи в процеса на предоставяне и ползване на административни услуги. 1.1. Изборът следва да е съотносим с посочените специфични въздействия на препоръчителния вариант за решаване на всеки проблем. 1.2. Ако се предвижда въвеждането на такса, представете образуването на нейния размер съгласно Методиката по чл. 7а от Закона за ограничаване на административното регулиране и административния контрол върху стопанската дейност. 6.2. Създават ли се нови/засягат ли се съществуващи регулаторни режими и услуги от прилагането на препоръчителния вариант (включително по отделните проблеми)? …………………………………………………………………..……………………… …………………………………………………………………………………………. 1.1. Изборът следва да е съотносим с посочените специфични въздействия на избрания вариант. 1.2. В случай че се предвижда създаване нов регулаторен режим, посочете неговия вид (за стопанска дейност: лицензионен, регистрационен; за отделна стелка или действие: разрешителен, уведомителен; удостоверителен и по какъв начин това съответства с постигането на целите). 1.3. Мотивирайте създаването на новия регулаторен режим съгласно изискванията на чл. 3, ал. 4 от Закона за ограничаване на административното регулиране и административния контрол върху стопанската дейност. 1.4. Посочете предложените нови регулаторни режими отговарят ли на изискванията на чл. 10 – 12 от Закона за дейностите по предоставяне на услуги. 1.5. Посочете изпълнено ли е изискването на § 2 от Допълнителните разпоредби на Закона за дейностите по предоставяне на услуги. 1.6. В случай че се изменят регулаторни режими или административни услуги, посочете промяната. 6.3. Създават ли се нови регистри от прилагането на препоръчителния вариант (включително по отделните проблеми)? …………………………………………………………………..……………………… …………………………………………………………………………………………. Нови регистри не се създават, но се създава информационна система за централизирано изграждане на регистри, която ще позволи на администрациите да изпълнят изискването на чл. 4а от Закона за електронното управление. Системата ще отговаря на всички изисквания на закона и подзаконовите актове с оглед защита на данните, проследимост, отказоустойчивост и др. Системата е планирано да бъде внедрена в началото на 2024 г. Когато отговорът е „Да“, посочете регистрите, които се създават и по какъв начин те ще бъдат интегрирани в общата регистрова инфраструктура. 6.4. По какъв начин препоръчителният вариант въздейства върху микро-, малките и средните предприятия (МСП) (включително по отделните проблеми)? Предложените нормативни промени ще доведат до повишаване на качеството на електронното административно обслужване, намаляване на времето за предоставяне на административни услуги и намаляване на разходите за най-голямата категория представители на бизнеса - МСП. Това ще насърчи използването на електронни административни услуги от страна на бизнеса. Изборът следва да е съотносим с посочените специфични въздействия на препоръчителния вариант. 6.5. Потенциални рискове от прилагането на препоръчителния вариант (включително по отделните проблеми): Не са идентифицирани рискове за заинтересованите страни от прилагането на избрания препоръчителен вариант. Посочете възможните рискове от прилагането на препоръчителния вариант, различни от отрицателните въздействия, напр. възникване на съдебни спорове и др. 7. Консултации: ……………………………………………………………..……………………………… …………………………………………………………………………………………….. …………………………………………………………………………………………….. Посочете основните заинтересовани страни, с които са проведени консултации. Посочете резултатите от консултациите, включително на ниво ЕС: спорни въпроси, многократно поставяни въпроси и др. ……………………………………………………………..……………………………… …………………………………………………………………………………………….. …………………………………………………………………………………………….. Обобщете най-важните въпроси за обществени консултации. Посочете индикативен график за тяхното провеждане и видовете консултационни процедури. 8. Приемането на нормативния акт произтича ли от правото на Европейския съюз? …………………………………………………………………..……………………… …………………………………………………………………………………………. 1.1. Посочете изискванията на правото на Европейския съюз, включително информацията по т. 6.2 и 6.3, дали е извършена оценка на въздействието на ниво Европейски съюз, и я приложете (или посочете връзка към източник). 1.2. Изборът трябва да съответства на посоченото в раздел 1, съгласно неговата т. 1.5. 9. Изисква ли се извършване на цялостна предварителна оценка на въздействието поради очаквани значителни последици? (преценка съгласно чл. 20, ал. 3, т. 2 от Закона за нормативните актове) 10. Приложения: …………………………………………………………………..……………………… …………………………………………………………………………………………. Приложете необходимата допълнителна информация и документи. 11. Информационни източници: Закон за електронното управление; Актуализирана Стратегия за развитие на електронното управление 2019-2025 и Концепция за регистрова реформа - https://egov.government.bg/wps/portal/ministry-meu/strategies-policies/strategic-documents; Интегрирана информационна система на държавната администрация – Административен регистър - https://iisda.government.bg/; Статистика на Националния статистически институт - https://nsi.bg/bg; Национален план за възстановяване и устойчивост - https://nextgeneration.bg/14. Посочете изчерпателен списък на информационните източници, които са послужили за оценка на въздействията на отделните варианти и при избора на вариант за действие: регистри, бази данни, аналитични материали и др. 12. Име, длъжност, дата и подпис на директора на дирекцията, отговорна за извършването на частичната предварителна оценка на въздействието: Име и длъжност: Стоян Цонев – директор на дирекция „Политики за електронно управление“ Дата: Подпис:

Становище на администрацията на Министерския съвет Съгласуването се извършва на основание чл. 21, ал. 5 от Закона за нормативните актове Проект на акт: Вид оценка: Проект на Постановление на Министерския съвет за изменение и допълнение на Наредбата за общите изисквания към информационните системи, регистрите и електронните административни услуги Становище по ред: Номер и дата: В отговор на №: 04-2-2/15.01.2024 г. Институция: Министерство на електронното управление Диспозитив: Основание: от Устройствения правилник на Министерския съвет и на неговата администрация Общ коментар: С цел постигане на съответствие на частичната предварителна оценка на въздействието, смятаме за необходимо използваното наименование „Единния портал“ да се коригира и да бъде отразено наименованието „Портала на електронното управление“, използвано в Закона за електронното управление. В допълнение, тази препоръка следва да бъде отразена и в проекта на нормативният акт. Относно раздел 2 „Цели“: Като добра практика на извършване на оценка на въздействието е възприето определянето на три групи цели: общи, конкретни и оперативни. Общите цели са тези, които се основават на общата стратегическа рамка на държавата, на програмата на правителството и на принципите и основните начала на действащото право. Чрез тях се установява връзка с генералните ефекти, очаквани от оценяваната политика, в случая е Решение на Министерския съвет № 298 от 2021 г. актуализирана Концепция за регистрова реформа (Приложение 2 към Актуализираната Стратегия за развитие на електронното управление в Република България (2019 – 2025). Конкретните цели вземат под внимание спецификите на оценяваната политика и особеностите на областта, в която тя би попаднала. Чрез тях се определя какво по същество се преследва да бъде постигнато чрез политиката. Те са свързани с очакваните резултати от нейното въвеждане. В тази връзка, предлагаме към формулираната цел да се определят конкретни цели, съответстващи на предлаганите нормативни промени, описани в Раздел 1 или да се посочи допълнителна информация за всяка от тях. При формулиране на целите също могат да се използват насоките от Ръководството за извършване на предварителна оценка на въздействието. Относно раздел 3 „Заинтересовани страни“: Заинтересованите, засегнатите страни и структурите с ангажименти и участие в административните процеси трябва да се идентифицират и да се посочи брой (в групите/подгрупите), където това е възможно. Неидентифицираното на заинтересованите страни не дава възможност да се оцени мащаба на въздействието на предлаганите варианти на действие, както и на самия нормативен акт. Информацията, представена за група „доставчици на обществени услуги и лица, осъществяващи публични функции“ следва да бъде по-изчерпателна относно кои са другите съсловни организации, поддържащи данни, които участват в административното обслужване на граждани. Останалата информация, представена за тях в този раздел е необходимо да бъде преместена в Раздел 4, където е релевантното й място. Относно раздел 4 „Варианти на действие“: При представяне и оценяване на вариантите е необходимо да се използват насоките от Ръководството за извършване на предварителна оценка на въздействието. Във връзка с това предлагаме представянето на Вариант 2 освен общото описание на предлаганите мерки, кореспондиращи с актуализираната концепция за регистрова реформа, да се допълни с описание на предвидените конкретни нормативни промени, както и действия/мерки, които съдържа вариантът. Относно раздел 5 „Сравняване на вариантите“: По отношение на представената таблица в този раздел е необходимо броят на колоните с вариантите да съответства на броя на вариантите, а излишните полета да се премахнат. Относно раздел 6.3. „Създават ли се нови регистри от прилагането на препоръчителния вариант (включително по отделните проблеми)?“: Съгласно § 42 от Заключителни разпоредби към Закона за изменение и допълнение на Закона за електронното управление (ДВ, бр. 80 от 2023 г., в сила от 19.09.2023 г.), „законът влиза в сила от деня на обнародването му в "Държавен вестник" с изключение на § 4, § 5 относно чл. 4а, ал. 2, § 17 относно чл. 26а, ал. 5 и 6, § 21, 27, 29 и § 34, т. 1, буква "в", които влизат в сила от 31 март 2024 г.“. В тази връзка препоръчваме периодът, който е посочен в този раздел да бъде коригиран в съответствие с горепосочената норма. Относно раздел 7 „Консултации“: Напомняме, че предстоящата обществена консултация следва да се проведе в обичайния срок по чл. 26 от Закона за нормативните актове, а именно не по-кратък от 30 дни. Срокът за провеждане на консултацията следва да бъде посочен в образеца на предварителната оценка на въздействието. Относно раздел 11 „Информационни източници“: Източниците на информация, които са използвани за извършване на оценката, предлагаме да се допълнят, а за тези от тях, които са налични в интернет, предлагаме да се посочат съответните хиперлинкове, като например https://egov.bg/wps/portal/egov/nachalo. *   Съгласно чл. 17 от Наредбата за обхвата и методологията за извършване на оценка на въздействието, изводите и относимата информация от извършената частична предварителна оценка на въздействието се включват във финансовата обосновка по чл. 35, ал. 1, т. 4 от Устройствения правилник на Министерския съвет и на неговата администрация. **   При съгласуването по чл. 32 от Устройствения правилник на Министерския съвет и на неговата администрация кръгът от въпроси, проблеми и решения, разгледани в оценката на въздействието се съпоставя с кръга от въпроси, засегнати в проекта на нормативен акт. ***   На основание чл. 30б, ал. 4 от Устройствения правилник на Министерския съвет и на неговата администрация е необходимо окончателната оценка на въздействието да бъде съобразена с препоръките от становището. ****   На основание чл. 85, ал. 1 от Устройствения правилник на Министерския съвет и на неговата администрация е необходимо това становище да бъде публикувано заедно с преработената оценка на въздействието и проекта на акт при обществените консултации, провеждани в изпълнение на Закона за нормативните актове. ДИРЕКТОР НА ДИРЕКЦИЯ „МОДЕРНИЗАЦИЯ НА АДМИНИСТРАЦИЯТА“: ИСКРЕН ИВАНОВ

Р Е П У Б Л И К А Б Ъ Л Г А Р И Я М И Н И С Т Е Р С К И С Ъ В Е Т Проект! ПОСТАНОВЛЕНИЕ ( … от .......... 2024 година за изменение и допълнение на Наредбата за общите изисквания към информационните системи, регистрите и електронните административни услуги, приета с Постановление № 3 от 09.01.2017 г. на Министерския съвет (обн., ДВ, бр. 5 от 17 януари 2017 г.,изм. ДВ., бр.66 от 10 август 2018г., изм. и доп. ДВ. бр. 4 от 14 януари 2020г., изм., бр. 47 от 24.06.2022 г., в сила от 24.06.2022 г.) М И Н И С Т Е Р С К И Я Т С Ъ В Е Т П О С Т А Н О В И: § 1. В чл. 1, ал. 1: Създава се нова т. 1: „1. изискванията за идентификация на длъжностни лица и информационни системи за нуждите на служебното предоставяне и изпращане на данните от първичните администратори на данни – по чл. 3, ал. 3 ЗЕУ;“ 2. Създава се нова т. 1а: „1а. други средства за електронна идентификация – по чл. 5, ал. 2, т. 4 ЗЕУ;“ 3. Досегашната т. 1 става т. 1б; 4. Създава се нова т. 7а: „7а. стандартите и редът за използване от административните органи на споделените ресурси на електронното управление – по чл. 17, ал. 4 ЗЕУ;“ 5. Създава се нова т. 12а: „12а. правилата за провеждане на одит на информационна система за сигурно електронно връчване, поддържана от Министерство на електронното управление – по чл. 26а, ал. 2 ЗЕУ;“ 6. Създава се нова т. 12б: „12б. форматът на електронните адреси в системата за сигурно електронно връчване, поддържана от Министерството на електронното управление – по чл. 26а, ал. 4 ЗЕУ;“ 7. Създава се нова т. 19а: „19a. редът за заявяване и използване на регистър чрез информационната система за централизирано изграждане и поддържане на регистри – по чл. 52а, ал. 4 ЗЕУ;“ 8. Създава се нова т. 19б: „19б. стандартът, съгласно който се генерира уникален идентификатор на всеки запис в регистър – по чл. 52б, ал. 1, т. 3 ЗЕУ;“ 9. Създава се нова т. 19в: „19в. общите изисквания към регистрите, включително за тяхното структуриране, функционалности и удостоверяване на данни – по чл. 52б, ал. 2 ЗЕУ;“ 10. Създава се нова т. 19г: „19г. изискванията за информационна сигурност на регистрите, водени от административните органи и лицата по чл. 1, ал. 2 – по чл. 52б, ал. 3 ЗЕУ;“ § 2. В чл. 5 се правят следните изменения: 1. Ал. 1 се изменя така: „(1) Изискванията в този раздел се отнасят за техническата реализация на регистрите и базите данни, водени от административните органи, когато това им е възложено със закон.“ Ал. 2 се отменя. § 3. В чл. 7, ал. 5 накрая се добавят думите:„както и за лицата, предоставящи услуга за електронна идентификация, посочена в чл. 5, ал. 2, т. 3 от Закона за електронното управление.“ § 4. В чл. 10, ал. 2 след думите „както и при“, както и след думите „извличането, както и“ се добавят думите „предоставяне и изпращане“. § 5. В чл. 12, ал. 7, изречение първо се изменя така: „(7) Данните по ал. 1 – 2 и 4 са достъпни за лицата, за които се отнасят, включително по електронен път, когато са се идентифицирали със средствата за електронна идентификация с високо ниво на осигуреност, определени в Закона за електронното управление доколкото от закон не следва друго.“ § 6. Създава се Раздел IIa с чл. 15а – 15б: „Раздел IIa Ред за заявяване и използване на регистър чрез Информационната система за централизирано изграждане и поддържане на регистри Ред за заявяване и изграждане на регистър Чл. 15а. (1) За изграждане на регистър в Информационната система за централизирано изграждане и поддържане на регистри се подава заявление по образец, одобрен от министъра на електронното управление. (2) В случай на констатирани недостатъци в заявлението, същото се връща на заявителя с указания за отстраняването им. (3) Когато не са констатирани недостатъци и са налице основанията за изграждане на регистър в системата по ал. 1, министърът на електронното управление или упълномощено от него лице, издава заповед за изграждане на заявения регистър. (4) В случай че към момента на разглеждане на заявлението се констатира недостатъчност на наличните технологични ресурси, в заповедта за изграждане на регистър се определя отлагателен срок, за което заявителят се уведомява. (5) Заповедта по ал. 3 съдържа параметрите на регистъра, който ще се изгражда и срокът за изграждането му. Използване на регистър Чл. 15б. (1) След изграждане на регистъра по чл. 15а на заявителя или на оправомощени от него лица, се предоставят необходимите права за достъп до Информационната система за централизирано изграждане и поддържане на регистри, позволяващи вписване, заличаване и промяна на данни в регистър, както и всички други операции, предвидени в нормативен акт. (2) Миграцията на данните към изградения регистър се извършва от заявителя. § 7. В чл. 19, ал. 3, накрая думите „Единния портал за достъп до електронни административни услуги“ се заменят с думите „Портала на електронното управление.“ § 8. В чл. 20: 1. ал. 4 се изменя така: „(4) Всеки административен орган оповестява чрез официалната си интернет страница и чрез Портала на електронното управление електронните адреси, на които могат да му бъдат изпращани електронни документи.“; 2. В ал. 5 се добавя второ изречение: „Времето на получаване се отчита по реда на чл. 46.“ § 9. Чл. 21, ал. 5 се изменя така: „Интегритетът на предаваните електронни изявления през интернет чрез уеббазирани потребителски интерфейси се осигурява чрез използване на протокол HTTPS, като за установяване на криптирана връзка с потребителя на услугата се използва протокол TLS (Transport Layer Security – Сигурност на транспортния слой), версия 1.2 или по-висока, дефиниран в Препоръка RFC 5246, приета от IETF (The Internet Engineering Task Force – Целева група за Интернет инженеринг) през август 2008 г.“ § 10. В чл. 23 се правят следните изменения и допълнения: 1. В ал. 1 думите „Единен портал за достъп до електронни административни услуги“ се заменят с думите „Портала на електронното управление“.; 2. В ал. 2 думите „Единният портал за достъп до електронни административни услуги“ се заменят с думите „Порталът на електронното управление“; 3. В ал. 3 думите „Единният портал за достъп до електронни административни услуги“ се заменят с думите „Порталът на електронното управление“, а думата „образците“ се заменя с думите „електронните образци“. § 11. В чл. 24 се правят следните изменения и допълнения: 1. В ал. 1, накрая се добавят думите „и Единната входна точка за електронни плащания в централната и местната администрация, поддържана от министъра на електронното управление.“; 2. Алинеи 3, 4, 5 и 6 се отменят. 3. Създава се нова алинея 8: „(8)(Нова)Доставчиците на електронни административни услуги предоставят възможност за плащане на електронните административни услуги чрез Централен виртуален ПОС терминал, поддържан от министъра на електронното управление. При плащане чрез Централния ВПОС терминал не се дължат преводни такси и комисиони.“ § 12. В чл. 27 се правят следните изменения и допълнения: 1. В ал 2 думата „ЕПДЕАУ“ се заменя с думите „Портала на електронното управление“. 2. В ал. 5, т. 3, накрая, думите „по реда на Закона за електронната идентификация“ се заличават и се добавят думите „със средствата за електронна идентификация, определени в ЗЕУ.“ 3. Създава се нова ал.6: „(6) Най-малко веднъж на две години министърът на електронното управление възлага на външен изпълнител одит на информационната система за сигурно електронно връчване.“ 4. Създава се нова ал. 7: „(7) Одитната работа в рамките на проверката на системата за сигурно електронно връчване (ССЕВ) се извършва по следните направления: 1. оценка на приложимите общи контроли и контроли на ниво приложения, осигуряващи надеждността на данните в ССЕВ; 2. предоставяне на увереност относно съответствието на процесите в ССЕВ със законодателството, политиките и стандартите, приложими за одитирания обект; 3. предоставяне на увереност, че ИТ ресурсите обезпечават постигането на целите на организацията ефикасно и ефективно, както и че приложимите общи контроли и контроли на ниво приложения не допускат, установяват и коригират случаите на нецелесъобразно или неефективно използване и управление на ССЕВ.“ 4. Създава се нова ал. 8: „(8) Одитът следва да се извърши чрез подходяща комбинация от следните техники: събеседване, въпросници, наблюдение, проследяване, графики на процесите, извличане и анализ на данни, потвърждение, повторно изчисление, повторна обработка и потвърждение от трети страни. Обхватът на оценката на ИТ контролите може да включи проверка дали в ССЕВ са въведени: 1. структура за управление на ССЕВ, която функционира добре; 2. правила за периодична инвентаризация на активите от ССЕВ и дали са установени нужди от разширяване; 3. процеси за споделяне на инфраструктура и общи услуги за ССЕВ с други организации от публичния сектор; 4. процес за разработване, придобиване и поддържане на ССЕВ (вкл. управление на промяната) и дали персоналът за администриране е запознат с него; 5. процеси за ИТ операциите (вътрешно изпълнение, възлагане на подизпълнител, споразумения за обслужване), които са доведени до знанието на съответните длъжностни лица; 6. мерки за гарантиране на физическата сигурност и адекватна физическа работна среда, както и за гарантиране на интегритета на съхраняваните данни; 7. мерки за обучение и запознаване на персонала с въпросите, свързани с конфиденциалността, ненарушимостта и наличността на информацията, както и дали са въведени изисквания за спазване на политиката и структурата за управление на ССЕВ; 8. мерки за гарантиране конфиденциалността, целостта и наличността при различните начини и канали за комуникация; 9. мерки за управление на информационната сигурност; 10. мерки, гарантиращи спазване на законодателството; 11. мерки за гарантиране непрекъсваемост на дейността и възстановяване след срив; 12. подходящи и надеждни контроли на ниво приложение за ССЕВ. При тази оценка може да се идентифицират съществените елементи от приложенията, критичните за ССЕВ приложения, да се направи преглед на наличната документация, събеседване с персонала за администриране, запознаване с контролните рискове на ниво приложения и тяхното въздействие за ССЕВ, както и да се разработят проверки за адекватността и надеждността на контролите на ниво приложение.“ § 13. В чл. 28 се правят следните изменения и допълнения: 1. Ал. 1 се заличава. 2. В ал. 2 думите „и/или получаване на резултата от“ се заличават и се добавя думата „на“ пред думите „съответната услуга“. § 14. В чл. 29 се правят следните изменения и допълнения: В ал. 1 думата „едно“ се заличава; В ал. 2: а) в т. 4 накрая се добавят думите „по електронен път“; б) добавя се нова т. 7: „7. информира за дължимите такси за електронната административна услуга, ако такива са определени от доставчика на услугата, като същите са за сметка на получателя на услугата;“ в) добавя се нова т. 8: „8. информира получателите на електронни административни услуги относно дължимото възнаграждение за посредничество по ясен и разбираем начин.“ 3. Добавя се нова ал. 4: „(4) Посредникът трябва да разполага с технически средства, необходими за заявяването на електронната административна услуга.“ 4. Добавя се нова ал. 5: „(5) Посредникът извършва плащането към доставчика за заявената услуга, в съответствие с чл. 24.“ 5. Досегашната алинея 4 става алинея 6. § 15. В чл. 30 се правят следните изменения и допълнения: 1. В ал. 1 пред думата „договор“ се добавя думата „писмен“. 2. Създава се нова ал. 4: „(4) Министърът на електронното управление води публичен списък на посредниците при заявяване на електронни административни услуги.“; 3. Създава се нова ал. 5: „(5) За включване и изключване от списъка по ал. 4 посредникът подава заявление до министъра на електронното управление.“ § 16. Член 38 се изменя така: „Общи положения Чл. 38. (1) Всички информационни системи и софтуерните компоненти в администрацията, в т. ч. регистри, интернет страници, вътрешни информационни системи, потребителски интерфейси към съществуващи системи, системи за предоставяне на електронни административни услуги и за електронен документооборот, трябва да отговарят на изискванията на тази глава. (2) Общите и специфичните изисквания към системите според тази наредба се включват в техническата спецификация при изграждане и надграждане на системи. (3) При изготвяне на спецификации за провеждане на обществени поръчки, чийто обхват включва изграждане и надграждане на софтуерни компоненти и софтуерната част на информационни системи, възложителите изготвят техническите си задания и спецификации на базата на образец съгласно приложение № 1. (4) (нова) При изготвяне на спецификации за провеждане на обществени поръчки, чийто обхват включва само дейности по адаптиране на информационни системи, регистри или бази данни във връзка с въвеждане на еврото в Република България, възложителите може да изготвят техническите си спецификации на базата на образец съгласно приложение № 2. В случаите, когато в спецификациите са включени и други дейности, се прилага ал. 3. (5) Образецът по ал. 3 се използва независимо дали в рамките на поръчката са включени и дейности, свързани с хардуер, мрежова инфраструктура и др. (6) Образците по ал. 3 и ал. 4 могат да се изменят и допълват съобразно дейностите и услугите в обхвата на обществената поръчка и конкретните изисквания на възложителите. (7) Министърът на електронното управление публикува образците по ал. 3 и 4 в електронна форма на интернет страницата на министерството. (8) При вътрешно изграждане и надграждане на информационни системи и софтуерни компоненти администрациите спазват изискванията, включени в образците по ал. 3 и 4.“ § 17. Създава се нов член 38а: „Ред за извеждане на информационни системи от експлоатация Чл. 38а. Информационни системи се извеждат от експлоатация при спазване на следния ред: 1. административният орган издава заповед за извеждане от експлоатация на информационните системи, за които не са предвидени средства за поддържането им; 2. прекратява се достъпът до данните и функционалностите на информационната система; 3. информационната система се архивира към момента на извеждането й от експлоатация.“ § 18. Чл. 39, ал. 2 се изменя така: „(2) Съдържанието на интернет страниците и мобилните приложения на административните органи, на доставчиците на обществени услуги и на лицата, осъществяващи публични функции, трябва да отговаря на последната обнародвана в Официалния вестник на Европейския съюз версия на хармонизирания стандарт EN 301 549, освен в случаите по чл. 58в, ал. 2 или 3 от ЗЕУ.“ § 19. Член 45 се изменя така: „Информационна сигурност Чл. 45. (1) Всички доставчици на електронни административни услуги са длъжни да спазват изискванията на Закона за киберсигурност и Наредбата за минималните изисквания за мрежова и информационна сигурност. (2) Лицата, поддържащи регистри по смисъла на чл. 52а от ЗЕУ, веднъж годишно провеждат тест за външно проникване в сигурността, извършен от независима организация.“ § 20. В чл. 47 се правят следните допълнения: Създава се нова ал. 9: “(9) Държавният хибриден частен облак (ДХЧО) предоставя услугите си в домейн egov.bg“; 2. създава се нова ал. 10: “(10) Хоризонталните системи на електронното управление се публикуват като поддомейни на egov.bg. със следната конвенция: [име на хоризонтална система].egov.bg. Например: pay.egov.bg, edelivery.egov.bg, eauth.egov.bg и др.“ 3. Създава се нова ал.11: “(11) Администрациите, които използват ресурси от ДХЧО могат да публикуват в egov.bg системи за общ достъп като поддомейни. със следната конвенция: [име на система].egov.bg. Например: iara-iss.egov.bg, strategy.egov.bg и др.“ § 21. В чл. 48 се правят следните допълнения: 1. Досегашният текст става ал. 1, като след думите „административните органи“ се добавят думите „(централни и местни)“; 2. Създава се нова ал. 2: „(2) Министърът на електронното управление утвърждава правила за предварително съгласуване на разходите на административните органи в областта на електронното управление и за използваните от тях информационни и комуникационни технологии в рамките на бюджетния процес.“ § 22. Чл. 49 се изменя така: „Подлежащи на вписване обстоятелства Чл. 49. За нуждите на информационната система по чл. 48 на вписване подлежи предоставяната от административните органи информация за: 1. тригодишните бюджетни прогнози; 2. проектобюджетите за следващата година: 3. утвърдените годишни бюджети; 4. промени по утвърдените бюджети: 5. текущите отчети 6. годишен отчет.“ § 23. Член 50 се изменя така: „Вписване и съгласуване Чл. 50. (1) Първостепенните разпоредители с бюджет определят длъжностни лица, които вписват информацията по чл. 49 в системата по чл. 48. (2) Лицата по ал. 1 за централната администрация, вписват информацията по чл. 49 в срокове, както следва: 1. по т. 1 – тригодишните бюджетни прогнози - в десетдневен срок от датата на утвърждаване на указанията на министъра на финансите за подготовката и предоставянето на бюджетните прогнози на първостепенните разпоредители с бюджет; 2. по т. 2 – проектобюджетите за следващата година и актуализираните им бюджетни прогнози - в десетдневен срок от датата на указанията на министъра на финансите за подготовката и представянето на проектобюджетите на първостепенните разпоредители с бюджет и актуализираните им бюджетни прогнози; 3. по т. 3 – утвърдените бюджети – в едномесечен срок от обнародването на постановлението за изпълнението на Закона за държавния бюджет на Република България за съответната година; 4. по т. 4 извършване на промени по утвърдените бюджети – в петнадесетдневен срок преди извършването на промените по бюджетите по реда на Закона за публичните финанси; 5. по т. 5 текущите отчети - в седемдневен срок от представянето на тримесечните отчети за касовото изпълнение чрез Информационната система за Управление на държавното съкровище на Министерството на финансите; 6. по т. 6 годишен отчет - в петнадесетдневен срок от получаването на окончателния одитен доклад и одитното становище на Сметната палата (3) Лицата по ал. 1 за общинската администрация, вписват информацията по чл. 49 в срокове, както следва: 1. по т. 1 тригодишните бюджетни прогнози - преди внасянето на прогнозите в общинските съвети за приемане; 2. по т. 2 проектобюджетите за следващата година и актуализираните им бюджетни прогнози - преди внасянето на проектобюджетите на първостепенните разпоредители с бюджет и актуализираните им бюджетни прогнози в общинските съвети за приемане; 3. по т. 3 утвърдените бюджети - в едномесечен срок от приемането на общинския бюджет; 4. по т. 4 извършване на промени по утвърдените бюджети преди внасянето им в общинските съвети за приемане; 5. по т. 5 текущите отчети – в седемдневен срок от представянето на отчета за всяко шестмесечие за касово изпълнение чрез Информационната система за общините на Министерството на финансите; 6. по т. 6 годишен отчет - в петнадесетдневен срок от приемането им от общинските съвети. (4) Министърът на електронното управление или определени от него длъжностни лица съгласуват вписаните данни по ал. 2 и ал. 3 в срок до две седмици от вписването им. (5) В случай на връщане към административния орган на коментари относно подадената от него информация по чл. 49, съответният първостепенен разпоредител с бюджет отразява бележките на министъра на електронното управление и вписва променените данни в системата по чл. 48. При частично или пълно неприемане на коментарите, съответната администрация изготвя мотивирано становище и го изпраща до министъра на електронното управление чрез системата по чл. 48. (6) В случай на мотивиран отказ за съгласуване по целесъобразност, съответният първостепенен разпоредител с бюджет може да обжалва решението за отказ или да впише наново преработена съгласно забележките информация. § 24. Член 52 се изменя така: „Вписване Чл. 52.(1) В регистъра по чл. 51 се вписват данни и информация съгласно чл. 7д, ал. 1 и 2 от Закона за електронното управление, включително необходимите за извършване на проверка на проектни предложения и дейности, включени в правилата по чл. 53, ал. 2, на следните етапи като минимум: 1. проектни предложения и дейности: а) общите и специфичните цели; б) съответствие със стратегически и програмни документи в областта на електронното управление; в) пълно описание на дейностите в областта на електронното управление, информационните и комуникационните технологии в администрациите; г) очакваните резултати и измеримите индикатори за резултат, включително по отношение на гражданите и бизнеса; д) необходими изменения на нормативната рамка за осигуряване на съответствие със законодателството за електронното управление; е) план-график и индикативен бюджет. 2. техническите спецификации за обществени поръчки по чл. 58а; 3. оценка на качеството на изпълнение на проекта, постигнатите резултати и финансов ефект. (2) Ръководителите на администрациите определят длъжностни лица, които извършват вписването в регистъра по чл. 51. (3) Лицата по ал. 2 вписват данните по ал. 1, т. 1 и т. 2: а) преди публикуването на обществената поръчка в Регистъра на обществените поръчки, или б) преди изпращането на заявка по действащо рамково споразумение. (4) В случаите, когато проектното предложение или дейността се финансира със средства от Европейския съюз и от други международни програми и договори, лицата по ал. 2 вписват данните по ал. 1, т. 1 преди изпращането на проектното предложение (дейността) за оценка към финансиращата организация. (5) Лицата по ал. 2 вписват данните по ал. 1, т. 3 в срок от 30 дни от приемане от възложителя на резултатите от проекта/дейността.“ § 25. В чл. 53 се правят следните изменения и допълнения: Алинея 3 се изменя така: „(3) В правилата по ал. 2 се урежда при проверка на проектно предложение да се установява най-малко: 1. за проектните предложения или дейности : а) дали отговаря на мярка в стратегически документ; б) дали посочените цели могат да бъдат постигнати чрез проекта или дейността; в) дали начинът на изпълнение е подходящо избран;“ 2. Алинея 8 се изменя така: „(8) Регистърът поддържа списък на всички утвърдени проекти и дейности, както и проектни предложения и дейности с постановен отказ за утвърждаване.“ § 26. В чл. 59 се правят следните изменения и допълнения: Създава се нова ал. 1: „(1) Министърът на електронното управление изгражда и поддържа хранилището за изходен код на интернет адрес: git.egov.bg.“ 2. Досегашната алинея 1 става алинея 2; 3. Досегашната алинея 2 става ал. 3; Досегашната ал. 3 става ал. 4; Досегашната ал. 4 става ал. 5; Досегашната алинея 5 става ал. 6; 7. Досегашната алинея 6 става ал. 7 и думата „GitHub” се заменя с думите HYPERLINK "https://github.com/governmentbg." https://github.com/governmentbg. § 27. Член 60 се изменя така: „Работа с проектно хранилище Чл. 60. (1) Изпълнителите по договори за изграждане и надграждане на софтуер използват проектни хранилища за ежедневна работа. (2) Лица извън администрацията и изпълнителите могат да предлагат подобрения в изходния код на софтуера в проектното хранилище. (3) Предложените по ал. 2 подобрения се преглеждат от възложителя по конкретния договор в 30-дневен срок, след което ги приема или отказва мотивирано. (4) В хранилището, приетите по ал. 3 предложения, се добавят чрез функционалност за обединяване на промени на системата за контрол на версиите.“ § 28. Създава се Глава шеста „а“ „ИЗПОЛЗВАНЕ НА СПОДЕЛЕНИТЕ РЕСУРСИ НА ЕЛЕКТРОННОТО УПРАВЛЕНИЕ“ с чл. 62а-62г: „Глава шеста „а“ ИЗПОЛЗВАНЕ НА СПОДЕЛЕНИТЕ РЕСУРСИ НА ЕЛЕКТРОННОТО УПРАВЛЕНИЕ Заявление Чл. 62а. (1) Използването на споделените ресурси на електронното управление за нуждите на административните органи се одобрява от министъра на електронното управление или оправомощено от него лице въз основа на заявление. Образецът на заявлението се утвърждава от министъра на електронното управление или упълномощено от него лице, публикуван на официалната интернет страница на МЕУ. (2) Заявлението по ал. 1 се подава при условията и реда на чл. 32. (3) Срокът за произнасяне по заявлението по ал. 1 е 15 дни. Ред за заявяване на използването на споделените ресурси Чл. 62б. Редът за заявяване на използването на споделените ресурси на електронното управление включва: 1.заявяване на необходимия ресурс; 2. проверка за допустимост и основателност на заявлението: а) заявлението подадено ли е от административен орган, или чрез оправомощено от него лице; б) заявени ли са всички изискуеми обстоятелства; 3. при наличие на несъответствия се изпраща уведомление на заявителя с указания за отстраняването им в 5-дневен срок. 4. преглед и оценка на техническата възможност за осигуряване на споделените ресурси. При наличие на съответния ресурс и техническа възможност за предоставянето му, министърът на електронното управление, или оправомощено от него лице, издава заповед за предоставяне на ресурса и уведомява заявителя; 5. ако в резултат на оценяването на възможността за предоставяне на ресурси се установи, че няма техническа възможност за предоставянето им, министърът на електронното управление, или оправомощено от него лице, писмено уведомява заявителя за ресурсите, които може да предостави и дава срок за приемане на предложението. предлага редуциране на искания обем ресурси съгласно наличността/възможностите; 6. прекратяване използването на предоставените ресурси, се извършва след писмено разпореждане на министъра на електронното управление, или оправомощено от него лице, по искане на ползвателя за отпаднала необходимост; 7. министърът на електронното управление, или оправомощено от него лице, има право да разпореди прекратяване на ползването, когато административния орган - ползвател, на който са предоставени ресурсите, със свои действия или бездействия поставя под риск целостта и интегритета на споделените ресурси; 8. с цел осигуряване на целесъобразно използване на споделения ресурс в случай че се установи, че предоставен ресурс или части от него не се използват за повече от три месеца, министърът на електронното управление, или оправомощено от него лице има право служебно да редуцира капацитета на предоставяните ресурси, за което уведомява ползвателя. Справки Чл. 62в. На всяко тримесечие се изготвят справки за себестойността на услугите, свързани с предоставяне на споделените ресурси, както и справка за използването на предоставените ресурси Стандарти и ниво на качество на услугите Чл. 62г. (1) Стандартите и нивото на качество на услугите, предоставяни от споделените ресурси, се описват в Каталог на услугите, публикуван на официалната интернет страница на Министерството на електронното управление. (2) За използването на Единната електронна съобщителна мрежа, като част от споделените ресурси на електронното управление следва да се спазват следните стандарти: а) 10/100/1000 Mbps меден порт; б) 1 Gbps оптичен или меден порт (SFP модул); в) 10 Gbps оптичен порт.“ § 29. §1, т. 21. от Допълнителната разпоредба се изменя така: „т. 21 "Уникален идентификатор" е единният граждански номер на българските граждани, личният номер на чужденците, единният идентификационен код за търговците и клоновете на чуждестранните търговци и кодът по БУЛСТАТ за лицата, подлежащи на вписване в регистър БУЛСТАТ.“ Приложение № 1 към чл. 38, ал. 3 [Възложител] ТЕХНИЧЕСКА СПЕЦИФИКАЦИЯ за [Име на проект] СЪДЪРЖАНИЕ TOC \o "1-3" \h \z \u HYPERLINK \l "_Toc107479999" СЪДЪРЖАНИЕ PAGEREF _Toc107479999 \h 2 HYPERLINK \l "_Toc107480000" 1. РЕЧНИК НА ТЕРМИНИ, ДЕФИНИЦИИ И СЪКРАЩЕНИЯ PAGEREF _Toc107480000 \h 6 HYPERLINK \l "_Toc107480001" 1.1. Използвани акроними PAGEREF _Toc107480001 \h 6 HYPERLINK \l "_Toc107480002" 1.2. Технологични дефиниции PAGEREF _Toc107480002 \h 6 HYPERLINK \l "_Toc107480003" 1.3. Дефиниции за нива на електронизация на услугите PAGEREF _Toc107480003 \h 8 HYPERLINK \l "_Toc107480004" 2. ВЪВЕДЕНИЕ PAGEREF _Toc107480004 \h 9 HYPERLINK \l "_Toc107480005" 2.1. Цел на документа PAGEREF _Toc107480005 \h 9 HYPERLINK \l "_Toc107480006" 2.2. За възложителя – функции и структура PAGEREF _Toc107480006 \h 9 HYPERLINK \l "_Toc107480007" 2.3. За проекта PAGEREF _Toc107480007 \h 10 HYPERLINK \l "_Toc107480008" 2.4. Нормативна рамка PAGEREF _Toc107480008 \h 10 HYPERLINK \l "_Toc107480009" 3. Цели, обхват и очаквани резултати от изпълнение на проекта PAGEREF _Toc107480009 \h 11 HYPERLINK \l "_Toc107480010" 3.1. Общи и специфични цели на проекта PAGEREF _Toc107480010 \h 11 HYPERLINK \l "_Toc107480011" 3.2. Обхват на проекта PAGEREF _Toc107480011 \h 11 HYPERLINK \l "_Toc107480012" 3.3. Целеви групи PAGEREF _Toc107480012 \h 12 HYPERLINK \l "_Toc107480013" 3.4. Очаквани резултати PAGEREF _Toc107480013 \h 12 HYPERLINK \l "_Toc107480014" 3.5. Период на изпълнение PAGEREF _Toc107480014 \h 13 HYPERLINK \l "_Toc107480015" 4. ТЕКУЩО СЪСТОЯНИЕ PAGEREF _Toc107480015 \h 13 HYPERLINK \l "_Toc107480016" 5. ИЗИСКВАНИЯ КЪМ ИЗПЪЛНЕНИЕ НА ПОРЪЧКАТА PAGEREF _Toc107480016 \h 13 HYPERLINK \l "_Toc107480017" 5.1. Общи изисквания към изпълнението на обществената поръчка PAGEREF _Toc107480017 \h 13 HYPERLINK \l "_Toc107480018" 5.2. Общи организационни принципи PAGEREF _Toc107480018 \h 13 HYPERLINK \l "_Toc107480019" 5.3. Управление на проекта PAGEREF _Toc107480019 \h 14 HYPERLINK \l "_Toc107480020" 5.4. Управление на риска PAGEREF _Toc107480020 \h 16 HYPERLINK \l "_Toc107480021" 6. ЕТАПИ НА ИЗПЪЛНЕНИЕ НА ПРОЕКТА PAGEREF _Toc107480021 \h 17 HYPERLINK \l "_Toc107480022" 6.1. Анализ на данните и изискванията PAGEREF _Toc107480022 \h 17 HYPERLINK \l "_Toc107480023" 6.1.1. Специфични изисквания към етапите на бизнес анализа и разработка PAGEREF _Toc107480023 \h 18 HYPERLINK \l "_Toc107480024" 6.1.2. Специфични изисквания при оптимизиране на процесите по заявяване на електронни административни услуги в зависимост от заявителя PAGEREF _Toc107480024 \h 20 HYPERLINK \l "_Toc107480025" 6.1.3. Изисквания за оптимизиране на процесите по подаване на декларации, изискуеми в съответствие с нормативната уредба и вътрешните правила PAGEREF _Toc107480025 \h 23 HYPERLINK \l "_Toc107480026" 6.1.4. Изисквания към регистрите и предоставянето на административните услуги PAGEREF _Toc107480026 \h 23 HYPERLINK \l "_Toc107480027" 6.2. Изготвяне на системен проект PAGEREF _Toc107480027 \h 24 HYPERLINK \l "_Toc107480028" 6.3. Разработване на софтуерното решение PAGEREF _Toc107480028 \h 25 HYPERLINK \l "_Toc107480029" 6.4. Тестване PAGEREF _Toc107480029 \h 25 HYPERLINK \l "_Toc107480030" 6.5. Внедряване PAGEREF _Toc107480030 \h 26 HYPERLINK \l "_Toc107480031" 6.6. Обучение PAGEREF _Toc107480031 \h 26 HYPERLINK \l "_Toc107480032" 6.7. Гаранционна поддръжка PAGEREF _Toc107480032 \h 26 HYPERLINK \l "_Toc107480033" 6.7.1. Актуализиране на документацията PAGEREF _Toc107480033 \h 27 HYPERLINK \l "_Toc107480034" 6.7.2. Нива на ескалация на проблемите PAGEREF _Toc107480034 \h 27 HYPERLINK \l "_Toc107480035" 6.7.3. Минимални изисквания към параметрите на качеството PAGEREF _Toc107480035 \h 27 HYPERLINK \l "_Toc107480036" 7. ОБЩИ ИЗИСКВАНИЯ ЗА ИНФОРМАЦИОННИ СИСТЕМИ В ДЪРЖАВНАТА АДМИНИСТРАЦИЯ PAGEREF _Toc107480036 \h 32 HYPERLINK \l "_Toc107480037" 7.1. Функционални изисквания към информационната система PAGEREF _Toc107480037 \h 33 HYPERLINK \l "_Toc107480038" 7.1.1. Интеграция с външни информационни системи PAGEREF _Toc107480038 \h 33 HYPERLINK \l "_Toc107480039" 7.1.2. Интеграционен слой PAGEREF _Toc107480039 \h 35 HYPERLINK \l "_Toc107480040" 7.1.3. Технически изисквания към интерфейсите PAGEREF _Toc107480040 \h 36 HYPERLINK \l "_Toc107480041" 7.1.4. Електронна идентификация на потребителите PAGEREF _Toc107480041 \h 37 HYPERLINK \l "_Toc107480042" 7.1.5. Отворени данни PAGEREF _Toc107480042 \h 38 HYPERLINK \l "_Toc107480043" 7.1.6. Формиране на изгледи PAGEREF _Toc107480043 \h 39 HYPERLINK \l "_Toc107480044" 7.1.7. Администриране на системата PAGEREF _Toc107480044 \h 39 HYPERLINK \l "_Toc107480045" 7.2. Нефункционални изисквания към информационната система PAGEREF _Toc107480045 \h 40 HYPERLINK \l "_Toc107480046" 7.2.1. Авторски права и изходен код PAGEREF _Toc107480046 \h 40 HYPERLINK \l "_Toc107480047" 7.2.2. Системна и приложна архитектура PAGEREF _Toc107480047 \h 41 HYPERLINK \l "_Toc107480048" 7.2.3. Повторно използване (преизползване) на ресурси и готови разработки PAGEREF _Toc107480048 \h 44 HYPERLINK \l "_Toc107480049" 7.2.4. Изграждане и поддръжка на множество среди PAGEREF _Toc107480049 \h 45 HYPERLINK \l "_Toc107480050" 7.2.5. Процес на разработка, тестване и разгръщане PAGEREF _Toc107480050 \h 46 HYPERLINK \l "_Toc107480051" 7.2.6. Бързодействие и мащабируемост PAGEREF _Toc107480051 \h 47 HYPERLINK \l "_Toc107480052" 7.2.7. Информационна сигурност и интегритет на данните PAGEREF _Toc107480052 \h 50 HYPERLINK \l "_Toc107480053" 7.2.8. Използваемост PAGEREF _Toc107480053 \h 54 HYPERLINK \l "_Toc107480054" 7.2.9. Системен журнал PAGEREF _Toc107480054 \h 61 HYPERLINK \l "_Toc107480055" 7.2.10. Дизайн на бази данни и взаимодействие с тях PAGEREF _Toc107480055 \h 61 HYPERLINK \l "_Toc107480078" 8. ИЗИСКВАНИЯ КЪМ ИЗПЪЛНЕНИЕТО НА ДЕЙНОСТИТЕ ПО ПРОЕКТА PAGEREF _Toc107480078 \h 62 HYPERLINK \l "_Toc107480079" 8.1. Дейност 1 [Наименование на дейността] PAGEREF _Toc107480079 \h 62 HYPERLINK \l "_Toc107480080" 8.1.1. Описание на дейността PAGEREF _Toc107480080 \h 62 HYPERLINK \l "_Toc107480081" 8.1.2. Изисквания към изпълнение на дейността PAGEREF _Toc107480081 \h 63 HYPERLINK \l "_Toc107480082" 8.1.3. Очаквани резултати PAGEREF _Toc107480082 \h 63 HYPERLINK \l "_Toc107480083" 8.2. Дейност 2 [Наименование на дейността] PAGEREF _Toc107480083 \h 63 HYPERLINK \l "_Toc107480084" 8.2.1. Описание на дейността PAGEREF _Toc107480084 \h 63 HYPERLINK \l "_Toc107480085" 8.2.2. Изисквания към изпълнение на дейността PAGEREF _Toc107480085 \h 63 HYPERLINK \l "_Toc107480086" 8.2.3. Очаквани резултати PAGEREF _Toc107480086 \h 63 HYPERLINK \l "_Toc107480087" 8.3. Дейност 3 [Наименование на дейността] PAGEREF _Toc107480087 \h 63 HYPERLINK \l "_Toc107480088" 8.3.1. Описание на дейността PAGEREF _Toc107480088 \h 63 HYPERLINK \l "_Toc107480089" 8.3.2. Изисквания към изпълнение на дейността PAGEREF _Toc107480089 \h 63 HYPERLINK \l "_Toc107480090" 8.3.3. Очаквани резултати PAGEREF _Toc107480090 \h 63 HYPERLINK \l "_Toc107480091" 8.4. Дейност 4 [Наименование на дейността] PAGEREF _Toc107480091 \h 63 HYPERLINK \l "_Toc107480092" 8.4.1. Описание на дейността PAGEREF _Toc107480092 \h 63 HYPERLINK \l "_Toc107480093" 8.4.2. Изисквания към изпълнение на дейността PAGEREF _Toc107480093 \h 63 HYPERLINK \l "_Toc107480094" 8.4.3. Очаквани резултати PAGEREF _Toc107480094 \h 63 HYPERLINK \l "_Toc107480095" 8.5. Дейност 5 [Наименование на дейността] PAGEREF _Toc107480095 \h 63 HYPERLINK \l "_Toc107480096" 8.5.1. Описание на дейността PAGEREF _Toc107480096 \h 63 HYPERLINK \l "_Toc107480097" 8.5.2. Изисквания към изпълнение на дейността PAGEREF _Toc107480097 \h 63 HYPERLINK \l "_Toc107480098" 8.5.3. Очаквани резултати PAGEREF _Toc107480098 \h 63 HYPERLINK \l "_Toc107480099" 9. ДОКУМЕНТАЦИЯ PAGEREF _Toc107480099 \h 63 HYPERLINK \l "_Toc107480100" 9.1. Изисквания към документацията PAGEREF _Toc107480100 \h 63 HYPERLINK \l "_Toc107480101" 9.2. Прозрачност и отчетност PAGEREF _Toc107480101 \h 65 HYPERLINK \l "_Toc107480102" 9.3. Системен проект PAGEREF _Toc107480102 \h 65 HYPERLINK \l "_Toc107480103" 9.4. Техническа документация PAGEREF _Toc107480103 \h 66 HYPERLINK \l "_Toc107480104" 9.5. Протоколи PAGEREF _Toc107480104 \h 66 HYPERLINK \l "_Toc107480105" 9.6. Комуникация и доклади PAGEREF _Toc107480105 \h 66 HYPERLINK \l "_Toc107480106" 9.6.1. Встъпителен доклад PAGEREF _Toc107480106 \h 66 HYPERLINK \l "_Toc107480107" 9.6.2. Междинни доклади PAGEREF _Toc107480107 \h 67 HYPERLINK \l "_Toc107480108" 9.6.3. Окончателен доклад PAGEREF _Toc107480108 \h 67 HYPERLINK \l "_Toc107480109" 10. РЕЗУЛТАТИ PAGEREF _Toc107480109 \h 68 РЕЧНИК НА ТЕРМИНИ, ДЕФИНИЦИИ И СЪКРАЩЕНИЯ Използвани акроними Акроним Описание АИС Автоматизирана информационна система АМС Администрация на Министерския съвет АОП Агенция по обществени поръчки АПК Административнопроцесуален кодекс БУЛСТАТ Регистър Булстат МЕУ Министерство на електронното управление ЗДОИ Закон за достъп до обществена информация ЗЕДЕП Закон за електронния документ и електронния подпис ЗЕУ Закон за електронното управление ИТ Информационни технологии КАО Комплексно административно обслужване ТР Търговски регистър ДХЧО Държавен хибриден частен облак ЦАИС Централизирана автоматизирана информационна система SDK Software development kit API Application programming interface/Приложно програмен интерфейс Технологични дефиниции Термин Описание Виртуална комуникационна инфраструктура Инфраструктура, която на база съществуваща физическа свързаност, предоставена от МЕУ, предоставя възможност за изграждане на отделни и защитени виртуални мрежи за всяка една от структурите в сектора, при гарантиране на сигурен и защитен обмен на информация в тях. Държавен хибриден частен облак Централизирана на ниво държава информационна инфраструктура (сървъри, средства за съхранение на информация, комуникационно оборудване, съпътстващо оборудване, разпределени в няколко локации, в помещения отговарящи на критериите за изграждане на защитени центрове за данни), която предоставя физически и виртуални ресурси за ползване и администриране от секторите и структурите, които имат достъп до тях, в зависимост от нуждите им, при гарантиране на високо ниво на сигурност, надеждност, изолация на отделните ползватели и невъзможност от намеса в работоспособността на информационните им системи или неоторизиран достъп до информационните им ресурси. Изолацията на ресурсите и мрежите на отделните секторни ползватели (е-Общини, е-Правосъдие, е-Здравеопазване, е-Полиция) се гарантира с подходящи мерки на логическо ниво (формиране на отделни клъстери, виртуални информационни центрове и мрежи) и на физическо ниво (клетки и шкафове с контрол на достъпа). Софтуер с отворен код Компютърна програма, която се разпространява при условия, които осигуряват безплатен достъп до програмния код и позволяват: Използването на програмата и производните на нея компютърни програми, без ограничения в целта; Промени в програмния код и адаптирането на компютърната програма за нуждите на нейните ползватели; Разпространението на производните компютърни програми при същите условия. Списък на стандартни лицензионни споразумения, които предоставят тези възможности, който може да бъде намерен в подзаконовата нормативна уредба към Закона за електронно управление или на: HYPERLINK "http://opensource.org/licenses" \hhttp://opensource.org/licenseHYPERLINK "http://opensource.org/licenses" \hs. Машинночетим формат Формат на данни, който е структуриран по начин, по който, без да се преобразува в друг формат позволява софтуерни приложения да идентифицират, разпознават и извличат специфични данни, включително отделни факти и тяхната вътрешна структура. Отворен формат Означава формат на данни, който не налага употребата на специфична платформа или специфичен софтуер за повторната употреба на съдържанието и е предоставен на обществеността без ограничения, които биха възпрепятствали повторното използване на информация. Метаданни Данни, описващи структурата на информацията, предмет на повторно използване. Официален отворен стандарт Стандарт, който е установен в писмена форма и описва спецификациите за изискванията как да се осигури софтуерна оперативна съвместимост. Система за контрол на версиите Технология, с която се създава специално място, наречено “хранилище”, където е възможно да се следят и описват промените по дадено съдържание (текст, програмен код, двоични файлове). Една система за контрол на версиите трябва да може: Да съхранява пълна история - кой, какво и кога е променил по съдържанието в хранилището, както и защо се прави промяната; Да позволява преглеждане разликите между всеки две съхранени версии в хранилището; Да позволява при необходимост съдържанието в хранилището да може да се върне към предишна съхранена версия; Да позволява наличието на множество копия на хранилището и синхронизация между тях. Цялата информация, налична в системата за контрол на версиите за главното копие на хранилището, прието за оригинален и централен източник на съдържанието, трябва да може да бъде достъпна публично, онлайн, в реално време. Първичен регистър Регистър, който се поддържа от първичен администратор на данни - административен орган, който по силата на закон събира или създава данни за субекти (граждани или организации) или за обекти (движими и недвижими) за първи път и изменя или заличава тези данни. Например Търговският регистър е първичен регистър за юридическите лица със стопанска цел, Имотният регистър е първичен регистър за недвижима собственост. Наличност на Системата в проценти Процентът на договорените часове, за които компонент или услуга е достъпна за определен период от време. Работни дни От Понеделник до Петък без националните и официални празници. Работни часове (Работно време) 08:00-20:00 всеки работен ден Инцидент Инцидент е всяко намаляване на качеството или недостъпност на предоставяна услуга и/или непланираното ѝ прекъсване, както и неизправност на елемент от инфраструктурната конфигурация Продължително прекъсване Прекъсване на услугата за повече от четири (4) работни часа Планирана недостъпност Планирано прекъсване на една или повече услуги. Недостъпност Неспособността на услуга или част от услуга да осигури нормалното обслужване Непланирана недостъпност Неочаквано прекъсване на една или повече услуги или значителна деградация на качеството на предлаганата услуга. Проблем Проблем е съвкупност от повтарящи се идентични събития или инциденти, които водят до периодично влошаване на дадена услуга, липсата ѝ или неточност в дадена процедура или функционално звено Дефиниции за нива на електронизация на услугите Термин Описание Ниво 1 Информация - предоставяне на информация за административни услуги по електронен път, включително за начини и места за заявяване на услугите, срокове и такси. Ниво 2 Едностранна комуникация - информация съгласно дефиницията за Ниво 1 и осигурен публичен онлайн достъп до шаблони на електронни формуляри. Ниво 3 Двустранна комуникация - заявяване и получаване на услуги изцяло по електронен път, включително електронно подаване на данни и документи, електронна обработка на формуляри и електронна персонална идентификация на потребителите. Ниво 4 Извършване на сделки или транзакции по услуги от Ниво 3, включващи онлайн разплащане или доставка. ВЪВЕДЕНИЕ Цел на документа Целта на настоящия документ е да опише софтуерните изисквания към изпълнението на обществена поръчка с предмет: [опишете предмета на поръчката]. В настоящата техническа спецификация са описани и изискванията към проектната организация, документацията и отчетността. Съдържанието на настоящата техническа спецификация е задължително за прилагане от всички лица по чл.1, ал.1 и ал. 2 от ЗЕУ, публичните и секторните възложители по Закона за обществените поръчки, които са публични предприятия по смисъла на Закона за публичните предприятия като в същото може да бъде добавян текст, в зависимост от специфичните нужди на разработваната информационна система, но не може да бъде изтривано настоящото съдържание. За възложителя – функции и структура Структурата на [възложителя] е представена във Фигура 1: Фигура 1. Структура на [възложителя] За проекта Нормативна рамка Проектът се осъществява в съответствие с изискванията, регламентирани със следните нормативни актове и стратегически документи: Закон за електронното управление; Закон за киберсигурност; Закон за електронната идентификация; Наредба за общите изисквания към информационните системи, регистри и електронни административни услуги; Наредба за минималните изисквания за мрежова и информационна сигурност; Актуализирана стратегия за електронното управление; Архитектура на електронното управление [Документ 2] Цели, обхват и очаквани резултати от изпълнение на проекта Общи и специфични цели на проекта Проектът е насочен към [подробно описание на общата цел на проекта]. Постигането на общата цел ще бъде реализирано чрез следните специфични цели, съответстващи на планираните по проекта дейности: [Специфична цел 1] [Специфична цел 2] [Специфична цел 3] [Специфична цел 4] [Специфична цел 5] Обхват на проекта Описаните в т. 3.1 цели се осъществяват с изпълнението на следните основни дейности, които формират обхвата на проекта: Дейност 1 [Наименование на дейността] Дейност 2 [Наименование на дейността] Дейност 3 [Наименование на дейността] Дейност 4 [Наименование на дейността] Дейност 5 [Наименование на дейността] Подробна информация за конкретните дейности по проекта е публично достъпна на адрес …………….. Целеви групи Целевите групи, към които е насочен проектът, обхващат: [Целева група 1]; [Целева група 2]; [Целева група 3]. Вашата администрация задължително присъства в списъка с целеви групи. Други целеви групи могат да бъдат други организации, например държавни администрации, крайни потребители на административни услуги – гражданите и бизнесът, както и други лица, осъществяващи публични функции. Изтрийте тази текстова кутия при финализиране на документа. Очаквани резултати Очакваните резултати от изпълнението на настоящата поръчка са: [Резултат 1]; [Резултат 2]; [Резултат 3]. Период на изпълнение Периодът на изпълнение е [Х] месеца, но не по късно от [ДД.ММ.ГГГГ] г. Участниците трябва да изготвят подробен график, в който следва да се конкретизират сроковете за изпълнение на всяка дейност и поддейност от настоящата поръчка. Графикът за изпълнение трябва да бъде съобразен с продължителността на дейността и не може да надвишава [Х] месеца от дата на сключване на договора. ТЕКУЩО СЪСТОЯНИЕ ИЗИСКВАНИЯ КЪМ ИЗПЪЛНЕНИЕ НА ПОРЪЧКАТА Общи изисквания към изпълнението на обществената поръчка Обществената поръчка се изпълнява в рамките на [Наименование на проекта/дейността], финансиран по [Източник на финансиране]. Изпълнителят следва да спазва всички нормативни изисквания по отношение на дейността на [бенефициента] и електронното управление в Република България. Общи организационни принципи Задължително изискване е да се спазят утвърдените хоризонтални и вертикални принципи на организация на изпълнението на предмета на обществената поръчка за гарантирано постигане на желаните резултати от проекта, така че да се покрие пълният набор от компетенции и ноу-хау, необходими за изпълнение на предмета на поръчката, а също така да се гарантира и достатъчно ниво на ангажираност с изпълнението и проблемите на проекта: Хоризонталният принцип предполага ангажиране на специалисти от различни звена, така че да се покрие пълният набор от компетенции и ноу-хау по предмета на проекта и същевременно екипът да усвои новите разработки на достатъчно ранен етап, така че да е в състояние пълноценно да ги използва и развива и след приключване на проекта; Вертикалният принцип включва участие на експерти и представители на различните управленски нива, така че управленският екип да покрива както експертните области, необходими за правилното и качествено изпълнение на проекта, така и управленски и организационни умения и възможности за осъществяване на политиката във връзка с изпълнението на проекта. Чрез участие на ръководители на звената – ползватели на резултата от проекта, ще се гарантира достатъчно ниво на ангажираност на институцията с проблемите на проекта. Управление на проекта [Моля, изтрийте ненужното!] Участниците трябва да предложат методология за управление на проекта, която смятат да приложат, като се изтъкнат ползите й за успешното изпълнение на проекта. Предложената методология трябва да съответства на най-добрите световни практики и препоръки (например Project Management Body of Knowledge (PMBOK) Guide, PRINCE2, Agile/ SCRUM/ Kanban, RUP и др. еквивалентни). Участникът следва да организира изпълнението на дейностите си, съгласно принципите на избрана от него Методология за управление на ИТ проекти и да предложи план-график за изпълнение на проекта за всяка дейност и поддейност. [Моля, изтрийте ненужното!] Възложителят изисква методология за управление на проекта, която участниците трябва да приложат и която съответства на най-добрите практики и препоръки, а именно ….. [Моля, довършете изречението!]. Дейностите по управление на проекта трябва да включват като минимум управление на реализацията на всички дейности, посочени в настоящата обществена поръчка, и постигане на очакваните резултати, както и разпределението на предложените участници в екипа за управление на поръчката по роли, график и дейности при изпълнение на настоящата обществена поръчка. Доброто управление на проекта трябва да осигури: координиране на усилията на експертите от страна на Изпълнителя и Възложителя и осигуряване на висока степен на взаимодействие между членовете на проектния екип; оптимално използване на ресурсите; текущ контрол по изпълнението на проектните дейности; разпространяване навреме на необходимата информация до всички участници в проекта; идентифициране на промени и осигуряване на техните анализ и координация; осигуряване на качеството и полагане на усилия за непрекъснато подобряване на работата за удовлетворяване на изискванията на участниците в проекта. Методологията трябва да включва подробно описание на: фазите на проекта; организация на изпълнение: структура на екипа на Изпълнителя; начин на взаимодействие между членовете на екипа на Изпълнителя; връзки за взаимодействие с екипа на Възложителя; проектна документация: видове доклади; техническа и експлоатационна документация; време на предаване; съдържание на документите; управление на версиите; управление на качеството; график за изпълнение на проекта. В графика участниците трябва да опишат дейностите и стъпките за тяхното изпълнение максимално детайлно, като покажат логическата връзка между тях. В графика трябва да са посочени датите за предаване на всеки от документите, изготвени в изпълнение на обществената поръчка. Управление на риска В техническото си предложение участниците трябва да опишат подхода за управление на риска, който ще прилагат при изпълнението на поръчката. Участниците трябва да представят и списък с идентифицираните от Възложителя рискове с оценка на вероятност, въздействие и мерки за реакция. През времето за изпълнение на проекта Изпълнителят трябва да следи рисковете, да оценява тяхното влияние, да анализира ситуацията и да идентифицира (евентуално) нови рискове. В хода на изпълнение на поръчката Изпълнителят следва да поддържа актуален списък с рисковете и да докладва състоянието на рисковете най-малко с месечните отчети за напредъка. При изготвянето на списъка с рискове Участниците следва да вземат предвид следните идентифицирани от Възложителя рискове: Промяна в нормативната уредба, водеща до промяна на ключови компоненти на решението – предмет на разработка на настоящата обществена поръчка; Недобра комуникация между екипите на Възложителя и Изпълнителя по време на аналитичните етапи на проекта; Ненавременно изпълнение на всяко от задълженията от страна на Изпълнителя; Неправилно и неефективно разпределяне на ресурсите и отговорностите при изпълнението на договора; Забавяне при изпълнение на проектните дейности, опасност от неспазване на срока за изпълнение на настоящата поръчка; Грешки при разработване на функционалностите на системата; Недостатъчна яснота по правната рамка и/или променяща се правна рамка по време на изпълнение на проекта; Липса на задълбоченост при изследването и описанието на бизнес процесите и данните; Неинформиране на Възложителя за всички потенциални проблеми, които биха могли да възникнат в хода на изпълнение на дейностите; Риск за администриране на системата след изтичане на периода на гаранционна поддръжка. ЕТАПИ НА ИЗПЪЛНЕНИЕ НА ПРОЕКТА В техническото си предложение участниците трябва да предложат подход за изпълнение на проекта, като включат минимум следните етапи: Анализ на данните и изискванията Функционален обхват на проекта [Моля, изтрийте ненужното!] Надграждане на съществуващи публични електронни административни услуги; [Моля, изтрийте ненужното!] Надграждане на съществуващи вътрешноадминистративни услуги; [Моля, изтрийте ненужното!] Разработка и внедряване на нови публични електронни административни услуги; [Моля, изтрийте ненужното!] Разработка и внедряване на нови вътрешноадминистративни услуги. В процеса на бизнес анализ да бъдат изследвана съвместимостта на бизнес процесите на Възложителя с вече одобрени оптимизирани референтни модели за предоставяне на услуги и нормативни изисквания HYPERLINK "http://www.strategy.bg/Publications/View.aspx?lang=bg-BG&Id=155"на Базисен модел за Комплексно административно обслужване в държавната администрация. При наличие на разработени модели за предоставяне на услуги по „Епизоди от живота“ и „Събития от бизнеса“, които включват услуги, предоставяни от Възложителя, да бъдат съобразени нуждите от модификации в референтните модели, за да се постигне подобряване на времето и намаляване на административната тежест при комплексно обслужване, спрямо предоставянето на отделните услуги поединично; В случай, че се касае за административни услуги, те трябва да бъдат разграничени на базата на разлики в бизнес процесите и да не бъдат генерализирани и/или обобщавани на базата на типа на действие (например, ако Системата издава няколко различни вида удостоверения, с които се удостоверяват различни обстоятелства, административните услуги трябва да бъдат регистрирани отделно); Удостоверителните административни услуги трябва да бъдат регистрирани и като вътрешни административни услуги и да бъде реализирана възможност за предоставянето на тези услуги като вътрешни електронно административни услуги за нуждите на комплексното административно обслужване чрез служебен онлайн интерфейс. Специфични изисквания към етапите на бизнес анализа при разработка и надграждане на информационна система Изпълнителят трябва да следва HYPERLINK "http://www.strategy.bg/Publications/View.aspx?lang=bg-BG&categoryId=&Id=165&y=&m="Методологията за усъвършенстване на работните процеси за предоставяне на административни услуги и Наръчника за прилагане на методологията, приета с Решение № 578 на Министерския съвет от 30 септември 2013 г.; Трябва да бъде предвидена фаза на проучване, по време, на която да се дефинират потребителските нужди, да се проведат предварителни тестове с потребители и да се изработи план, по който да се адресират идентифицираните нужди; Необходимо е да бъде направен анализ на текущото състояние на данните, които ще се обработват, по отношение на тяхната изчерпателност, пълнота и качество, да се направи оценка на възможността за въвеждане на данни и обстоятелства в регистри, съгласно изискванията на нормативната уредба. Да се предложи модел на данните, съдържащ описание на основните таблици и схематично представяне на връзките между тях; В процеса на анализа трябва да се разгледа възможността обменът на данни да се основава на общи стандарти, т.е. условия за използване, формат на данните, машинна четимост, метаданни, споделени речници/таксономии, честота, детайлност и задължителни атрибути. Задължителното прилагане би гарантирало изпълнението на изискванията за повторни потребители и доставчици на данни. Трябва да бъде направен анализ, оценка и описание на работните процеси, заложени в нормативната уредба, да бъде предложена организационна архитектура на базата, на която да бъдат разработени и оптимизирани основните функционалности на Системата. Трябва да бъдат предвидени периодични продуктови тествания по време на разработката и внедряването на Системата, с извадка (фокус-група) от бъдещите потребители на Системата, чрез които да се изпита и оцени използваемостта на услугите и потребителските интерфейси, както и за да бъдат отстранени затруднения и несъответствия със спецификацията; Трябва да се спазват нормативните изисквания за еднократно събиране и повторна употреба на данни в държавната администрация (съгласно АПК и ЗЕУ) и в разработените бизнес процеси да не се изискват данни за заявителя и/или за получателя на услугата, които могат да се извлекат автоматично в процеса на електронна идентификация чрез Центъра за електронна идентификация или на база на ЕГН от КЕП. При необходимост изпълнителят трябва да предложи на Възложителя адекватни промени в нормативната уредба, които да хармонизират съответните секторни нормативни изисквания с общите разпоредби на Административнопроцесуалния кодекс, Закона за електронно управление, Закона за електронния документ и електронния подпис и приложимите подзаконови актове, ако действащата нормативна уредба изисква: изрично попълване на типов структуриран електронен формуляр, върху който потребителите трябва да се подпишат собственоръчно и/или който да приложат като изискуем документ при заявяването на електронна административна услуга; изрично деклариране или обявяване на обстоятелства или данни, които се администрират и/или удостоверяват от други държавни органи и могат да бъдат получени по служебен път, включително и автоматизирано през съответни интеграционни интерфейси; други нормативни изисквания, които водят до неоптимални или ненужно бюрократични процеси, които биха могли да бъдат оптимизирани при заявяване и предоставяне на електронни административни услуги; 6.1.2 Специфични изисквания при оптимизиране на процесите по заявяване на електронни услуги и електронни административни услуги в зависимост от заявителя Предвидените за разработка и внедряване електронни административни услуги трябва да бъдат регистрирани предварително в Регистъра на услугите към Административния регистър (съгласно чл. 61 от Закона за администрацията) и да бъдат въведени и валидирани данни за броя на транзакциите по предоставяне на тези услуги в Модула „Самооценка на административното обслужване“ в Интегрираната информационна система на държавната администрация (ИИСДА). Услугите, които ще бъдат надградени, и новоразработените услуги трябва да отговарят на изискванията за електронни услуги с минимално Ниво 4, където е приложимо (т.е. услугата изисква заплащане на такса), или Ниво 3, в случаите, в които за предоставяне на услугата не се изисква заплащане на такса; Дефинициите за нивата на електронизация на административните услуги са регламентирани в Наредбата за административния регистър към Закона за администрацията; При разработката на информационна система да се предвиди изцяло автоматизирано предоставяне на ЕАУ, като се определят изискванията за задължителното минимално ниво на електронизация на ЕАУ, съгласно 1.3 от техническата спецификация, както и нивото на осигуреност на средствата за електронна идентификация при заявяване на ЕАУ и получаване на резултата от нея. При анализа трябва да се има предвид, ако АО предоставя ЕАУ от ниво 4, тя е с намалена такса спрямо таксата за присъствено заявяване и предоставяне, ако при прилагането на методиката за определяне на разходоориентиран размер на таксите по чл. 7а на Закона за ограничаване на административното регулиране и административния контрол върху стопанската дейност се установи различен размер на разходите, съгласно чл.10а, ал 2 от ЗЕУ. Трябва да се разработят информативни текстове за всяка услуга, които включват като минимум: Условия за предоставяне на услугата; Срокове за предоставяне на услугата; Такси за заявяване и съответно предоставяне на услугата; Начини за получаване на услугата; Резултат от предоставяне на услугата; Отказ от предоставяне на услугата; Информативните текстове за всяка услуга трябва да бъдат достъпни за потребителите още като първа стъпка от заявяването на услуга; Тарифирането на услугите трябва да бъде реализирано така, че Системата да съхранява всички версии на тарифите за услуги (от дата до дата) и да прилага съответната тарифа, в зависимост от момента, в който е заявена дадена услуга; Трябва да бъде оптимизиран потребителският път от влизане на сайта до заявяване и получаване на услуга и пътят от регистрация на нов потребител до заявяване и получаване на услуга; При оптимизацията на потребителския път трябва да се отчита всяко действие от страна на потребителя (натискане на бутон, въвеждане на данни, прочитане на текст и пр.), което може да се спести. Съгласно действащата нормативна уредба допустимите заявители на електронни административни услуги могат да бъдат разделени в няколко групи, като процесите по заявяване на ЕАУ и необходимите процеси по установяване на допустимостта на заявлението зависят от множество фактори. Трябва да бъде обърнато специално внимание на спецификите в процесите в зависимост от качеството, в което действа заявителят, за да се постигне максимална оптимизация на процеса, като същевременно се защити сигурността на търговския и гражданския оборот. Предоставянето на ЕАУ от административните органи на гражданите и бизнеса да се извършва през Портала на електронното управление, като се използва Единния модел за заявяване, заплащане и предоставяне на ЕАУ. В приложената диаграма са показани възможни разлики в бизнес процесите в зависимост от качеството, в което действа заявител на ЕАУ: EMBED Visio.Drawing.15 В приложената таблица са представени спецификите и разликите в бизнес процесите в зависимост от качеството, в което действа заявител на ЕАУ, които трябва да бъдат отразени при реализацията на Системата: Вид заявител Особености Специфични процеси Физическо лице за собствени нужди Заявява ЕАУ за лични нужди от свое име. Това е най-простият за реализиране случай Услугата може да бъде предоставена, след като са изпълнени нуждите за идентификация, ако има такива -електронна идентификация по смисъла на ЗЕИ или ЕГН, извлечено от КЕП в преходния период, както и три имена или анонимно. Законен представител на юридическо лице Заявява ЕАУ, за да обслужи нужди на юридическо лице, на което е законен представител (т.е. заявителят е вписан като представляващ юридическото лице в съответен регистър) Услугата може да бъде предоставена, след като са изпълнени нуждите за идентификация - електронна идентификация по смисъла на ЗЕИ или ЕГН, извлечено от КЕП в преходния период, както и автоматична проверка за представителна власт в ТР/ БУЛСТАТ/ ЦРЮЛНЦ. Пълномощник на ФЛ или ЮЛ Заявява ЕАУ, за да обслужи нужди на физическо или юридическо лице, което го е упълномощило (т.е. заявителят трябва да разполага с пълномощно, което му дава необходимия обем и обхват на представителна власт, за заявяване и/или получаване на съответната услуга) Услугата може да бъде предоставена само след проверка на представителната власт в Регистъра с пълномощни на Нотариалната камара, чрез проверка в Регистъра на овластяванията по смисъла на ЗЕИ или при създадена възможност за регистриране на пълномощни към профила на потребителя или за заявяване на услугата. Пълномощник може да бъде и посредник за предоставяне на ЕАУ по реда на ЗЕУ, в т.ч. Центрове за комплексно административно обслужване. Длъжностно лице (ЧСИ / ДСИ) Заявява ЕАУ, за да изпълни определени свои задължения като длъжностно лице спрямо друго физическо или юридическо лице, за което следва да има съответен правен интерес. Услугата може да бъде предоставена само след проверка на длъжностното лице в съответния регистър (ЧСИ/ ДСИ) и на правния интерес чрез изискване за декларирането му чрез изрична декларация, подписана с КЕП, и прилагане на копие от решение по изпълнително дело. Изисквания за оптимизиране на процесите по подаване на декларации, изискуеми в съответствие с нормативната уредба и вътрешните правила Системата трябва да поддържа номенклатура с редактируеми шаблони на декларации, които да бъдат достъпни за актуализация за администраторите на Системата; Трябва да се поддържа история на версиите на шаблоните и да няма възможност за перманентно премахване/изтриване на шаблони, а само смяна на статуса им и публикуване на нова версия; Ако даден бизнес процес изисква подаване на декларация от страна на заявител на услуга, при достигане на съответната стъпка от процеса Системата трябва: да попълва автоматично всички персонални данни на заявителя в електронна форма, генерирана на база на съответния шаблон на декларация; да дава възможност на потребителя за избор на съответните обстоятелства, които може да декларира (ако шаблонът на декларацията предвижда възможност за деклариране на опционален набор от предефинирани обстоятелства); да изисква потвърждение на обстоятелствата от страна на потребителя; в случай че декларацията трябва да се попълни от лице, различно от заявителя, тя да може да се прикачи като електронно подписан документ или по електронен път да бъде отправяна покана към декларатора за електронно подписване. Всяка попълнена електронна декларация трябва да се прикачи автоматично от Системата към заявлението и да бъде подписана заедно с него от потребителя с електронен подпис, освен в случаите, когато заявителят и деклараторът са различни лица и декларацията е подписана отделно от декларатора. 6.1.4 Изисквания към регистрите и предоставянето на административните услуги Всяка удостоверителна административна услуга в обхвата на системата трябва да бъде достъпна като вътрешноадминистративна електронна услуга чрез уеб-услуга, като комуникацията се подписва с електронен печат на институцията и с електронен времеви печат по смисъла на Регламент (ЕС) 910/2014; Всяка услуга, за която се допуска представителна власт, трябва да бъде интегрирана с Регистъра на овластяванията по смисъла на Закона за електронната идентификация; Системата не трябва да съхранява данни, на които възложителят не е първичен администратор, в случай че данните могат да бъдат извличани в реално време от регистър на съответния първичен администратор при възможност чрез интеграционната шина за обмен на справочна и удостоверителна информация. Всички електронни административни услуги, предоставяни от административните органи на гражданите и бизнеса трябва да се заявяват през Портал за електронно управление. При предоставянето на ЕАУ е необходимо Изпълнителят да осъществи интеграция с хоризонталните системи на електронното управление. Изготвяне на системен проект Изпълнителят трябва да изготви системен проект, който подлежи на одобрение от Възложителя. В системния проект трябва да са описани всички изисквания за реализирането на системата. Изготвянето на системния проект включва следните основни задачи: Определяне на концепция на информационната система на базата на техническата спецификация; Дефиниране на детайлни изисквания и бизнес процеси, които трябва да се реализират в системата; Дизайн на информационната система, хардуерната и комуникационната инфраструктура; Изготвяне на план за техническа реализация; Определяне на потребителския интерфейс. Изпълнението на задачите изисква дефиниране на модели на бизнес процеси, модели на стандартни справки и анализи, модели на печатни бланки, политика за сигурност и защита на данните, основни изграждащи блокове, транзакции, технология на взаимодействие, мониторинг на системата, спецификация на номенклатурите, роли в системата и други. При документирането на изискванията, с цел постигане на яснота и стандартизация на документите, е необходимо да се използва стандартен език за описание на бизнес процеси – BPMN. Системният проект подлежи на одобрение от Възложителя. В случай на забележки, корекции или допълнения от страна на Възложителя Изпълнителят е длъжен да ги отрази в системния проект в срок не по-късно от [Х] работни дни. Разработване на софтуерното решение Етапът на разработка включва изпълнението на следните задачи: [ако е приложимо] Разработка на прототип, който трябва да бъде одобрен от Възложителя и въз основа на който трябва да се разработи цялата система; Разработка на модулите на информационната система съгласно изискванията на настоящата техническа спецификация и системния проект; Провеждане на вътрешни тестове на системата (в среда на разработчика); Изготвяне на детайлни сценарии за провеждане на приемателните тестове за етапи „Тестване“ и „Внедряване“ на проекта. За изпълнение на дейностите по разработка на системата участниците в настоящата обществена поръчка трябва да опишат в своите технически предложения приложим подход (методология) за софтуерна разработка, която ще използват, както и инструментите за разработка и средата за провеждане на вътрешните тестове. Участниците трябва да опишат как предложеният от тях подход ще бъде адаптиран за успешната реализация на системата. Тестване Изпълнителят трябва да проведе тестване на софтуерното решение в създадена за целта тестова среда, за да демонстрира, че изискванията са изпълнени. Изпълнителят трябва да предложи и опише методология за тестване, която ще използва в план за тестване с описание на обхвата на тестването, вид и спецификация на тестовете, управление на дефектите, регресионна политика, инструменти, логистично осигуряване и други параметри на процеса. Внедряване Изпълнителят трябва да внедри софтуерното решение в информационната и комуникационна среда на [бенефициента]. Това включва инсталиране, конфигуриране и настройка на програмните компоненти на системата в условията на експлоатационната среда на [бенефициента]. Обучение Изпълнителят трябва да организира и да проведе обучения за следните групи и ползватели на софтуерното решение: [Потребителска група 1]; [Потребителска група 2]; [Потребителска група 3]. За провеждането на обученията Изпълнителят е длъжен да осигури за своя сметка [включват се само тези точки, за които Възложителят няма възможност да осигури изброените ресурси]: Необходимия хардуер; Необходимия софтуер; Зала/Зали за провеждане на обученията; Учебни материали; Лектори. Гаранционна поддръжка Изпълнителят трябва да осигури за своя сметка гаранционна поддръжка за период от минимум 24 месеца след въвеждане в експлоатация на Системата. При необходимост, по време на гаранционния период трябва да бъдат осъществявани дейности по осигуряване на експлоатационната годност на софтуера и ефективното му използване от Възложителя, в случай че настъпят явни отклонения от нормалните експлоатационни характеристики, заложени в системния проект. Приоритетите на инцидентите и проблемите се определят от Възложителя в зависимост от влиянието им върху работата на администрацията. Редът на отстраняването им се определя в зависимост от техния приоритет. 6.7.1 Обхват на дейностите по гаранционна поддръжка Изпълнителят следва да предоставя услугите по гаранционна поддръжка, като предоставя за своя сметка единна точка за достъп за приемане на телефонни и e-mail съобщения Дейностите по гаранционна поддръжка трябва да включват следния минимален обхват: Извършване на диагностика на ИР с цел осигуряване на правилното им и безпроблемно функциониране; Регистриране на инцидент в Система за управление на инциденти и проблеми; Отстраняване на дефектите, открити в софтуерните и/или хардуерните модули; Възстановяването на работоспособността на ИР (включително информационната система и данните) при евентуален срив, както и коригирането им в следствие на грешки; Предоставяне на консултации за идентифициране на проблеми в конфигурацията на ИТ средата (операционна система, база данни, middleware, хардуер и мрежи); Регулярен мониторинг на неразрешените инциденти, дефиниране на проблеми и оценка на ефектите върху договорените параметри на качеството за наличност и достъпност на ИС. Пълно документиране на разрешените инциденти, включително предприетите стъпки за разрешаването му, точното му класифициране, обратна връзка със засегнатите потребители относно предложеното решение, общо изразходвано време за разрешаване Актуализация на документацията при установени явни несъответствия с фактически реализираните функционалности, както и в случаите, в които са извършени действия по отстраняване на дефекти и грешки, в рамките на гаранционната поддръжка. За целите на дейността е необходимо да бъдат изготвени от Изпълнителя и одобрени и подписани от Възложителя: споразумение за нивото на предоставяните услуги към потребителите на информационни ресурси на АО (SLApm), в които са определени приоритетите за спешно обслужване; параметрите на качество на обслужване на Системата, съобразени с минималните изисквания към параметрите на качеството от т. 6.7.5; комуникационни, анализаторски и документационни средства, с които функционалните звена идентифицират, анализират, проследяват и документират възникването и отстраняването на неработоспособността на информационната система. 6.7.2 Управление на инциденти (incident management) С цел осигуряване на работоспособността на Системата и повишаване на качеството на обслужване на потребителите ѝ в етапа на нейната експлоатация Изпълнителят трябва да разработи процедури за бързо и ефективно регистриране на възникнали инциденти и безпроблемно им отстраняване. Чрез процедурата за управление на инциденти се подпомага и координира работата на въвлечените в тази дейност функционални звена, които изпълняват следните задачи: I-во ниво на поддръжка – за изпълнение на тези дейности се сформира се екип от експерти на Възложителя или дейността се поема от екип на Изпълнителя. Задачите на екипа са да извършва дейности по наблюдение на Системата, регистриране, описание и обслужване на инциденти с цел улесняване идентифицирането на причините за възникване, първоначален анализ и класифициране на инциденти, ескалиране на заявки към 2-ро ниво поддръжка, документиране на дейностите и изготвяне на доклади. II-ро ниво на поддръжка – екипът се сформира от експерти на Изпълнителя или от експерти на Възложителя и Изпълнителя, които разглеждат, анализират и отстраняват всички възникнали инциденти при спазване на процедурата. Екипът изпълнява следните задачи: обслужване на ескалираните от 1-во ниво на поддръжка инциденти, анализиране и класифициране на инциденти, разследване и диагностика на инцидента и установяване на средствата и каналите за разрешаване, разрешаване на инцидента и възстановяване на оперативността на всички засегнати компоненти, създаване на база данни за начинът на разрешаване на инцидентите, съдържаща информация както за временните решения (work arounds), така и за искания за промени; III-то ниво на поддръжка – екипът се сформира от експерти на Изпълнителя, които разрешават инцидент, ескалиран от екипа на II-ро ниво на поддръжка, осигуряват безпроблемното функциониране на Системата, проактивно изследват инцидент с цел откриване на конкретната причина за възникването му, правят предложения за промени в компонентите, свързани с решаването на регистрирани проблеми, предоставят информация за процеса по управление на проблемите (Problem Management) относно взимане на мерки за предотвратяване повторяемостта на инцидентите. Процесът на управление на инциденти се осъществява чрез използване на Система за управление на заявки (Service/ Help Desk), собственост на Възложителя или Изпълнителя, която гарантира разпознаването им, тяхната проследимост и причините за възникването им, позволява документиране, комуникиране и одобрение по идентификация, разследване и отстраняване на причини за възникване на инциденти и проблеми. 6.7.3 Управление на проблеми (УП) (problem management) В етапа на гаранционна поддръжка се включва процеса по управление на проблеми, целта на който е да минимизира и/или елиминира влиянието на инцидентите, причинени от грешки възникнали в компонентите на системите, платформите, функционалните звена и/или процесите, имащи пряко или косвено отношение към влошаване или невъзможност за предоставяне на услугите към крайните потребители. При УП, екипът от експерти на Изпълнителя трябва: да се фокусира върху идентифицирането на причините за възникване на инциденти (root-cause analysis), повторяемостта на идентичните събития и инциденти които водят до появата и съществуването на грешки. да извършва всички необходими дейности за диагностициране и анализиране на причините за възникване на инцидентите и определя начините и методите за разрешаване на проблемите, да дефинира, прилага и да носи пряка отговорност за прилагането на подходящи контролни процедури (Change Management/ Release Management) с цел безпроблемно и качествено имплементиране на одобреното постоянно или временно (workaround) решение. да подържа база данни инструмент за работа с нея, в която се вписват всички проблеми и съответните им решения ( Knowledge Management and Known Error Data Base). да обхване двата основни процеса – реактивно и проактивно управление на проблемите, който е част от процеса на непрекъснато подобряване на услугите (Continuous Service Improvement). 6.7.4 Управление на качеството при отстраняване на инциденти и проблеми. Параметри на качеството. Чрез гаранционната поддръжка Изпълнителят трябва да осигури гарантиране на работоспособността, на мрежовата и информационната сигурност, да поддържа непрекъснатост на работата на софтуер, хардуер и комуникационна свързаност, с което се обезпечава неприкосновеността и сигурността на обработваната информация. Параметрите на качеството на услугите, които Изпълнителят предлага в етапа на гаранционна поддръжка се изпълняват съгласно споразумение за нивото на предоставяните услуги към потребителите на АО (SLApm). 6.7.5 Минимални изисквания към параметрите на качеството Системата трябва да работи в режим 7/24/365. Конкретните параметри, свързани с достигането на необходимото ниво на работоспособност през гаранционния период, са дадени в Таблици от 1 до 5. Таблица 1 Наличност на Системата в проценти и часове на годишна база Система В рамките на работните часове Максимално сумарно отпадане на Системата в работно време за една година Извън рамките на работните часове Максимално сумарно отпадане на Системата в извън работно време за една година 99,50% <15 часа 98,00% <116 часа Таблица 2 Планиране на прекъсвания (планирана недостъпност) на Системата Продължителност на планирана недостъпност < 1 час от 1 до 6 часа от 6 до 11 часа о всяко време Извън работните часове В почивни дни или по време на официални празници Забележка: (a) Ако планираното прекъсване може да надхвърли 11 часа трябва да се раздели на две (или повече прекъсвания ), които не превишават 11 часа. (b) Работните часове са съгласно Таблица „Дефиниции”. (с) Цитираните в таблицата данни и системи са актуални към датата на изготвяне на настоящия документ. При настъпили промени, системите ще бъдат актуализирани. Важно: Обявяването на планирано прекъсване става посредством уведомяване на Възложителя минимум 7 работни дни предварително. Уведомяването трябва да съдържа: засегната/и система/и; начална дата и час; крайна дата и час; причина; Таблица 3 Приоритети Приоритет Въздействие върху работните процеси 1 Критичен Критично влияние върху работните процеси. Изисква незабавно действие, като работата продължава до неговото отстраняване. Пълно прекъсване на една или повече ЕАУ, предоставяни от администрацията; Недостъпност до предоставяни през функционалността на Системата ЕАУ, които пряко и съществено засягат ключови или голям брой клиенти; Висок риск от финансови загуби и/или засягане на имиджа на администрацията или негови контрагенти; Създава висок риск за компрометиране на информация в Системата; Нарушена комуникация с други държави членки на ЕС или на аналогични системи; Риск за съществено прекъсване или излизане от строя на Системата; Критична функционалност не функционира нормално или има критично и негативно отражение върху операциите на потребителите или системната среда във ведомство на Възложителя или в имиджа на същото или е възникнало непланирано преустановяване на достъпността. 2 Висок Съществено влияние върху работните процеси. Изисква ангажиране на необходимите ресурси за отстраняването на проблема, като работата продължава в нормалните работни часове до неговото отстраняване. Влошаване на качеството на предлагана услуга или достъп до такава, без пълно прекъсване; Създаване на сериозен риск от възникване на инцидент с критичен приоритет; Критична функционалност функционира непълноценно или има силно неблагоприятно отражение върху работните процеси вследствие на неприемлива производителност или генериране на грешни данни. 3 Среден Несъществено влияние върху работните процеси. Изисква ангажиране на необходимите ресурси за отстраняване на проблема, като работата за неговото отстраняване е не-повече от 7 работни дни. Ограничено въздействие върху работата на Системата, което засяга или създава неудобство за изпълнение на отделни функции, без да има цялостно отражение върху функциите ѝ. Забавяне на отстраняването му може да доведе до възникване на инцидент от по-високо ниво. Нормалната производителност на Системата или част от него е влошена, но по-голяма част от функционалната му способност е незасегната. 4 Нисък Няма пряко влияние върху работните процеси в момента на възникването му. Изисква ангажирането на необходимите ресурси за отстраняване на проблема, като работата за неговото отстраняване е не-повече от 14 работни дни В момента липсва пряко влияние върху функционирането на Системата, но не решаването му в определен срок крие потенциален риск от възникване на инцидент с по-висок приоритет. Обикновено се свързва с подобряване на функционирането на услуга, предоставяна от Системата или развитието й. Отстраняването се планира съвместно с Възложителя и е обект на средносрочно планиране. Възложителят може да изисква информация или помощ по възможните решения. Таблица 4 Параметри на качеството при отстраняване на инцидент Приоритет на инцидента Време за реакция, max План за решение, max Начин на отстраняване Срок за отстраняване на инцидента, max 1 30 минути 2 ч. В специална версия 6 часа 2 1 час 4 ч. В специална версия 12 часа 3 1 работен ден 1 седмица В следваща версия 7 работни дни 4 1 работен ден 1 седмица В следваща версия 14 работни дни Забележки: (а) Всички понятия са съгласно REF _Ref1719091 \h \* MERGEFORMAT Error! Reference source not found.; (b) Приоритетите се определят от Възложителя, съгласно точка „Определяне на степента на критичност на инцидент“; (c) За инциденти от 1 и 2 приоритет, ако за времето на отстраняване на проблема бъде намерено временно решение, с което изцяло се възстановява работоспособността на Системата, Възложителят може да снижи приоритета на инцидента без да го закрива. (d) Всички, посочени в таблицата, времена започват да текат от момента на регистриране в Системата за управление на инциденти на Възложителя. (e) При обективна невъзможност да бъдат спазени сроковете в таблицата, Възложителят може да ги промени за конкретен инцидент; Таблица 5 Параметри на качеството при отстраняване на проблем Приоритет на проблема Време за реакция, max План за решение, max Начин на отстраняване Срок за отстраняване на проблема, max 1 1 час 4 часа В специална версия 24 часа 2 2 часа 24 часа В специална версия 72 часа 3 1 работен ден 1 седмица В следваща версия 7 работни дни 4 1 работен ден 1 седмица В следваща версия 14 работни дни Забележки: (а) Всички понятия са съгласно REF _Ref1719091 \h \* MERGEFORMAT Error! Reference source not found.; (b) За инциденти от 1 и 2 приоритет, ако за времето на отстраняване на проблема бъде намерено временно решение, с което изцяло се възстановява работоспособността на Системата, Възложителят може да снижи приоритета на инцидента без да го закрива. (c) Всички, посочени в таблицата, времена започват да текат от момента на регистриране в Системата за управление на инциденти на Възложителя. 6.7.6 Управлението на промените (Change management) В техническото си предложение участниците трябва да предложат метод за управление на промените, който ще прилагат при изпълнението на поръчката, съобразявайки се с описаните по-долу изисквания. Управлението на промените цели да гарантира че е осигурено: ускорено и устойчиво развитие в условия на намален риск на работа на Системата; минимизиране на неблагоприятното въздействие върху потребителите при нормалната експлоатация на електронните услуги; навременното внедряване само на одобрени промени и с минимални грешки; ефект от промяната върху всички засегнати компоненти на Системата; всички спешни (критични) промени да са прегледани и одобрени; навременно и коректно информиране на ключовите заинтересовани лица относно всички аспекти на промяната. Процесът включва: Дефиниране на необходимостта и обхвата на промяната; Съгласуване на необходимостта и обхвата на промяната със заинтересованите страни; Оценка на въздействието върху бизнес процеси, системна инфраструктура или приложен софтуер, необходимия финансов ресурс, ползите и рисковете свързани с промяната; Подаване и регистриране на искане за промяна в Системата за управление на промените на Възложителя; Приоритизиране на подадени искания за промяна на база изготвена обосновка относно функционалните и техническите изисквания, необходимите ресурси, законовите и/или договорни изисквания, които налагат промяната; Мотивирано одобрение или отказ за одобрение на промяната; Планиране, управление и координиране на разработката на промяната. Изготвяне на план за разработка на промяната. В плана, ако е приложимо, се включват и дейности по конвертиране и/или миграция на данни, промени в други компоненти на Системата, засегнати услуги или инфраструктура обслужваща Системата, промени в архивиращи процедури и/или други промени, гарантиращи успешната реализация на промяната; Дефиниране, управление и координиране на спешните промени с цел минимизиране на вероятността за последващи инциденти, изработване на оценка на въздействието и одобряване след внедряването на спешната промяна. Създаване на процедура за предоставяне и прекратяване на необходимия достъп до системите и информационните активи за пускане в експлоатация на спешни промени; Документиране, контрол и отчитане на дейностите по изпълнение на промяната (включително документиране на отхвърлените промени, проследяване на статуса на одобрените промени и приключване на процеса на промяна) с цел гарантиране, че одобрените промени са внедрени, съгласно плана за внедряване на промяната. Актуализиране на системната документация и документацията на засегнатите работни процеси и процедури. Приемане на промяната и въвеждане в реална експлоатация, включва: Изготвяне на план за въвеждане в експлоатация на промяната. Като в плана се включват при необходимост и дейности, които са извън обхвата на дейностите по настоящата техническа спецификация, но са предусловие за успешното реализиране на промяната. В този случай тези предусловия се ескалират до Възложителя за предприемане на действия по компетентност. Дефиниране на тестови сценарии и критерии за приемане на промяната, подготовка на тестова среда и фактическо тестване на промяната. Провеждане на тестове по приемане. Подготовка на експлоатационната среда чрез мигриране на всички промени от тестовата среда към експлоатационната (хардуер; мрежови ресурси; операционни системи; приложен софтуер; данни за настройка на системни параметри, номенклатури, вътрешни и/или външни интерфейси; транзакционни данни) и фактическо мигриране; Подготовка на участниците (компоненти на Системата и потребители) в засегнатите от промяната работни процеси, осигуряване на канали за комуникация и обучение; Компилиране на нова версия, инсталиране в реална среда и първоначално съпровождане. Приключване на промяната; Отчитане на ползите и реалните ефекти от извършената промяна. Искането за промяна може (допуска се) да се инициират и от двете страни (Възложител и Изпълнител). Упълномощени представители на Възложителя или Изпълнителя могат да инициират искане за промяна. Исканията за промяна се регистрират в Системата за управление на промени на Възложителя. Регистрираните искания за промени се разглеждат от Съвета за оперативно управление, където промените се преглеждат и се взема решение за съответното действие по тях. ОБЩИ ИЗИСКВАНИЯ ЗА ИНФОРМАЦИОННИ СИСТЕМИ В ДЪРЖАВНАТА АДМИНИСТРАЦИЯ Всички информационни системи и софтуерните компоненти в администрацията, в т.ч. регистри, интернет страници, вътрешни информационни системи, потребителски интерфейси към съществуващи системи, системи за предоставяне на електронни административни услуги и за електронен документооборот, трябва да отговарят на изискванията на Закона за електронното управление, Закона за киберсигурност, Закона за достъп до обществена информация и Закона за достъп до пространствени данни и подзаконовата нормативна база към тях. Неизпълнението на тези изисквания от страна на изпълнителите по договори за разработка и/или надграждане на информационни системи /регистри/ЕАУ е  основание за неприемане на разработеното софтуерно решение от страна на Възложителя. Функционални изисквания към информационната система Интеграция с външни информационни системи За реализиране на основни бизнес процеси Системата трябва да поддържа интеграция в реално време с хоризонталните и централните информационни системи на електронното управление, както следва: Интеграция с хоризонталните системи на ЕУ Интеграцията на Системата с хоризонталните системи за електронно управление се осъществява чрез разработване и внедряване на служебен интерфейс за обмен на данни, както следва: Код Описание Приложимост Забележка* F1 Информационна система за електронна автентикация версия 2.0 Задължително до влизане в сила на Националната схема за електронна идентификация по ЗЕИ. F2 Информационна система за сигурно електронно връчване Задължително F3 Информационна система за електронно плащане(ако е приложимо) Задължително само за ЕАУ от ниво на електронизация на услугата 4 F4 Информационна система за електронни форми Задължително* F5 Информационна система за е-валидация Задължително* F6 Информационна система за е-оторизация Задължително* *Интеграцията с хоризонталните системи на ЕУ, освен информационната система за електронна автентикация v2.0, е задължителна, ако чрез Системата се предоставят електронни или електронно административни услуги чрез Портала на електронното управление. [Информационна система 1] - [кратко описание]; [Информационна система 2] - [кратко описание]; [Информационна система 3] - [кратко описание]. Интегрираната информационна система на държавната администрация (ИИСДА), в частност Регистъра на услугите, в който се вписват допустимите заявители и получатели на административни услуги - например: проверка на достъпа до съответните обстоятелства; посочване на идентификатор на конкретна административна услуга, за която е нужно извличането на съответните обстоятелства от регистрите; Интеграциите с външни информационни системи и регистри трябва да се реализира чрез стандартен интеграционен слой. EMBED Visio.Drawing.15 Интеграционен слой Интеграция на Системата чрез използване на интеграционния слой на ЕУ, включващ: Код Описание Приложимост Забележка* F7 Интеграционна шина за обмен на справочна и удостоверителна информация В случай, че Системата се явява се първичен регистър на данни, с цел присъединяване към интеграционната шина и в последствие използването на първичните данни от други АО, е необходимо да се предвиди разработката на адаптер, който да се реализира съгласно стандарта, публикуван на Портала за електронно управление, в раздел „Разработчици“. При условие, че Системата използва данни от ПАД, трябва да бъде предвидена интеграция с първични регистри чрез стандартен междинен слой или чрез националната схема за електронна идентификация – конкретната реализация трябва да бъде одобрена от Възложителя след приключване на етапа на бизнес-анализ; Трябва да бъде разработен и внедрен служебен онлайн интерфейс за машинен обмен на данни и предоставяне на вътрешноадминистративни електронни услуги към информационни системи и регистри на други администрации, публични институции и доставчици на обществени услуги, съгласно действащите изисквания за оперативна съвместимост. Задължително F8 Интеграционна шина за обмен на електронни документи Задължително, когато се обменят електронни документи чрез документооборотни системи. F9 Интеграционна шина за достъп и управление на ИТ услуги и данни на МЕУ Препоръчително F10 Информационна система за централизирано поддържане на регистри Задължително, когато се изграждат регистри, които са били водени на хартия и са включени в Решение на Министерски съвет Забележка: Интеграциите с външни информационни системи и регистри трябва да се реализира чрез стандартен интеграционен слой, съгласно действащите изисквания за оперативна съвместимост. Трябва да бъде разработен и внедрен служебен онлайн интерфейс за автоматизирано машинно поискване и предаване на история на изпълнените транзакции по машинен обмен на данни, предоставените електронни услуги и начислени такси, към информационни системи на други публични институции и доставчици на обществени услуги, с оглед предоставяне на КАО, съгласно действащите изисквания за оперативна съвместимост; Технически изисквания към интерфейсите Код Описание Приложимост Забележка* F11 Служебните онлайн интерфейси трябва да се предоставят като уеб-услуги (web-services) и да осигуряват достатъчна мащабируемост и производителност за обслужване на синхронни заявки (sync pull) в реално време, с максимално време за отговор на заявки под 1 секунда за 95% от заявките, които не включват запитвания до регистри и външни системи. Задължително F12 Необходимо е да бъде разработен и внедрен служебен онлайн интерфейс за автоматизирано изпращане на транзакционна история към системата за електронна идентификация, съгласно действащите изисквания за оперативна съвместимост. Препоръчително F13 Трябва да бъде разработен и внедрен служебен онлайн интерфейс за електронни разплащания и интеграция с виртуални POS терминали, позволяващ директно плащане с дебитна или кредитна карта без необходимост от регистрация на отделен потребителски акаунт в система на платежен оператор. Задължително за информационни системи предоставящи услуги с ниво на електронизация 4 F14 Всички публични и служебни онлайн интерфейси трябва да бъдат реализирани с поддръжка на режими “push” и „pull”, в асинхронен и синхронен вариант – практическото прилагане на всяка от комбинациите трябва да бъде определено на етап бизнес-анализ и да бъдат съобразени реалните казуси (use cases), които всеки интерфейс обслужва. Препоръчително F15 Трябва да се реализира интегриране на модул за разпределен кохерентен кеш (Distributed Caching) на „горещите данни“, които Системата получава и/или които се обменят през служебните онлайн интерфейси, като логиката на Системата трябва гарантира кохерентност (Cache Coherency) между кешираните данни и данните, съхранявани в базите данни. Задължително F16 Да бъде предвидено създаването и поддържането на тестова среда, достъпна за използване и извършване на интеграционни тестове от разработчици на информационни системи, включително такива, изпълняващи дейности за други администрации или за бизнеса, с цел по-лесно и устойчиво интегриране на съществуващите и бъдещи информационни системи. Задължително Електронна идентификация на потребителите Код Описание Приложимост Забележка* F17 До До влизане в сила на националната схема за електронна идентификация по ЗЕИ трябва да бъде осъществена интеграция с хоризонталната система на електронното управление – е-автентикация v2.0. За целта трябва да се поддържа интеграция с външен доставчик на идентичност - в случая с центъра за електронна идентификация към Министерството на електронното управление. Реализацията на интеграцията трябва да бъде осъществена по стандартни протоколи SAML 2.0 и/или OpenID Connect. Задължително F18 Системата трябва да поддържа и стандартен подход за регистрация на потребители с потребителско име и парола - за потребители, които нямат издадени удостоверения за електронна идентичност, и за потребители, които желаят да продължат да използват електронни административни услуги с КЕП. Препоръчително Процес по регистрация на потребители F19 Да се предостави възможност за визуализиране на информация относно стъпките по регистрация и информация във връзка с процеса за потвърждаване на регистрацията и активиране на потребителския профил. Съвети към потребителите за проверка на настройките на имейл клиентите, свързани с блокиране на спам, и съвети за включване на домейна на Възложителя в "бял списък“; Задължително F 20 Да има възможност за избор на потребителско име с контекстна валидация на полетата (in-line validation), включително и за избраното потребителско име и и визуализиране на сложността на паролата като "слаба", "нормална" и "силна"; Препоръчително F21 Да се реализира функционалност за потвърждение и активиране на регистрацията чрез изпращане на съобщение до регистрирания имейл адрес на потребителя, с еднократно генериран токън с ограничена времева валидност за потвърждение на регистрацията; Задължително F22 При реализиране на вход в Системата с удостоверение за електронна идентичност, по националната схема за електронна идентификация по ЗЕИ, Системата трябва да използва потребителския профил, създаден в системата за електронна идентификация, чрез интерфейси и по протоколи съгласно подзаконовата нормативна уредба към Закона за електронната идентификация. Задължително F23 В случай, че даден потребител има регистриран потребителски профил в Системата, който е създаден преди въвеждането на националната схема за електронна идентификация по ЗЕИ, Системата трябва да предлага на потребителя възможност за "сливане" на профилите и асоцииране на локалния профил с този от националната система за електронна идентификация по ЗЕИ. Допустимо е Системата да поддържа и допълнителни данни и метаданни за потребителите, но само такива, които не са включени като реквизити в централизирания профил на потребителя в системата за електронна идентификация. Задължително Отворени данни Код Описание Приложимост Забележка* F24 Трябва да бъде разработен и внедрен автоматизиран интерфейс за осигуряване на свободен публичен автоматизиран достъп до документите, информацията и данните в Системата (наричани заедно „данните”). Интерфейсът трябва да осигурява достъп до данните в машинночетим, отворен формат, съгласно всички изисквания на Директива 2013/37/ЕС за повторна употреба на информацията в обществения сектор и на Закона за достъп до обществена информация. Задължително за системи, които предоставят данни по ЗДОИ F25 Трябва да бъде разработен и внедрен онлайн интерфейс за предоставяне на пространствени данни, в машинночетим, отворен формат и интеграция с Националния портал за достъп до пространствени данни, съгласно всички изисквания на Директива 2007/2/ЕО и Закона за достъп до пространствени данни. Трябва да се поддържат всички набори от данни, които са изискуеми по Директива 2007/2/ЕО и за които Възложителят се явява първичен администратор на данните. Задължително за ИС, които обработват геопространствена информация F26 Да бъде предвидена разработката и внедряването на отворени онлайн интерфейси и практически механизми, които да улеснят търсенето и достъпа до данни, които са на разположение за повторна употреба, като например списъци с основни документи и съответните метаданни, достъпни онлайн и в машинночетим формат, както и интеграция с портала за отворени данни HYPERLINK "https://data.egov.bg/" https://data.egov.bg/, който съдържа връзки и метаданни за списъците с материали, съгласно изискванията на Закона за достъп до обществена информация (ЗДОИ). Задължително за системи, които предоставят данни по ЗДОИ F27 Трябва да се разработи и да се поддържа актуално публично описание на всички служебни и отворени интерфейси, отворените формати за данни, заедно с историята на промените в тях, в структуриран машинночетим формат. Задължително F28 Трябва да се разработят процеси по предоставяне на данни в отворен, машинночетим формат заедно със съответните метаданни. Форматите и метаданните следва да съответстват на официалните отворени стандарти. Задължително Формиране на изгледи Код Описание Приложимост Забележка* F29 Потребителите на Системата трябва да получават разрези на информацията чрез филтриране, пренареждане и агрегиране на данните. Резултатът се представя чрез: Визуализиране на таблици; Графична визуализация на екран; Експорт на данни в един или в няколко от изброените формати – ODF, Excel, PDF, HTML, TXT, XML, CSV и запис върху електронен носител. Задължително Администриране на системата Код Описание Приложимост Забележка* F30 Системата трябва да осигурява администриране на потребителите и правата за достъп чрез административен панел, с който администраторите на системата да създават профили, управляват, назначават, отнемат роли и права на потребителите. Задължително Нефункционални изисквания към информационната система Авторски права и изходен код Код Описание Приложимост Забележка* NF1 Всички компютърни програми, които се разработват за реализиране на Системата, трябва да отговарят на критериите и изискванията за софтуер с отворен код. Задължително NF2 всички авторски и сродни права върху произведения, обект на закрила на Закона за авторското право и сродните му права, включително, но не само, компютърните програми, техният изходен програмен код, структурата и дизайнът на интерфейсите и базите данни, чието разработване е включено в предмета на поръчката, възникват за Възложителя в пълен обем без ограничения в използването, изменението и разпространението им и представляват произведения, създадени по поръчка на Възложителя съгласно чл. 42, ал. 1 от Закона за авторското право и сродните му права. Задължително NF3 Приложимите и допустими лицензи за софтуер с отворен код са: GPL (General Public License) 3.0; LGPL (Lesser General Public License); AGPL (Affero General Public License); Apache License 2.0; New BSD license; MIT License; Mozilla Public License 2.0; EUPL (European Union PublicLicense). Задължително NF4 Изходният код (Source Code), разработван по проекта, както и цялата техническа документация трябва да бъде бъдат публично достъпни онлайн като софтуер с отворен код от първия ден на разработка чрез използване на система за контрол на версиите и хранилището по глава шеста, раздел ІV „Хранилище за изходен код“ от НОИИСРЕАУ. Задължително NF5 Да се изследва възможността резултатният продукт (Системата) да се изгради частично (библиотеки, пакети, модули) или изцяло на базата на съществуващи софтуерни решения, които са софтуер с отворен код. Когато е финансово оправдано, да се предпочита този подход пред изграждането на собствено софтуерно решение в цялост, от нулата. Избраният подход трябва да бъде детайлно описан в техническото предложение на участниците. Препоръчително NF6 Да бъде предвидено използването на Система за контрол на версиите и цялата информация за главното копие на хранилището, прието за оригинален и централен източник на съдържанието, да бъде достъпна публично, онлайн, в реално време. Задължително 7.2.2 Системна и приложна архитектура Код Описание Приложимост Забележка* NF7 Системата трябва да бъде реализирана като разпределена модулна информационна система. Системата трябва да бъде реализирана със стандартни технологии и да поддържа общоприети комуникационни стандарти, които ще гарантират съвместимост на Системата с бъдещи разработки. Съществуващите модули функционалности трябва да бъдат рефакторирани и/или надградени по начин, който да осигури изпълнението на настоящето изискване. Задължително NF8 Трябва да бъде реализирана функционалност за текущ мониторинг, анализ и контрол на изпълнението на бизнес процесите в Системата. Препоръчително NF9 При разработката, тестването и внедряването на Системата Изпълнителят трябва да прилага наложили се архитектурни (SOA, MVC или еквивалентни) модели и дизайн-шаблони, както и принципите на обектно ориентирания подход за разработка на софтуерни приложения. Системата трябва да бъде реализирана със софтуерна архитектура, ориентирана към услуги - Service Oriented Architecture (SOA). Задължително NF10 Взаимодействията между отделните модули в Системата и интеграциите с външни информационни системи трябва да се реализират и опишат под формата на уеб-услуги (Web Services), които да са достъпни за ползване от други системи в държавната администрация, а за определени услуги – и за гражданите и бизнеса. За всеки от отделните модули/функционалности на Системата следва да се реализират и опишат приложни програмни интерфейси – Application Programming Interfaces (API). Приложните програмни интерфейси трябва да са достъпни и за интеграция на нови модули и други вътрешни или външни системи. Задължително NF11 Приложните програмни интерфейси и информационните обекти задължително да поддържат атрибут за версия. Задължително NF12 Задължително наличие и използване на програмни интерфейси, изискуемите метаданни и атрибути за версия, достъпност за стари версии - минимум 24 месеца след публикуване на нова версия, съгласно изискването по чл. 14 и чл. 41 от НОИИСРЕАУ. Задължително NF13 Версията на програмните интерфейси, представени чрез уеб-услуги, трябва да поддържа версията по един или няколко от следните начини: Като част от URL-а; Като GET параметър; Като HTTP header (Accept или друг). NF14 За всеки отделен приложен програмен интерфейс трябва да бъде разработен софтуерен комплект за интеграция (SDK) на поне две от популярните развойни платформи (.NET, Java, PHP). Задължително NF15 Системата трябва да осигурява възможности за разширяване, резервиране и балансиране на натоварването между множество инстанции на сървъри с еднаква роля. Задължително NF16 При разработването на Системата трябва да се предвидят възможни промени, продиктувани от непрекъснато променящата се нормативна, бизнес и технологична среда. Основно изискване се явява необходимостта информационната система да бъде разработена като гъвкава и лесно адаптивна, като отчита законодателни, административни, структурни или организационни промени, водещи до промени в работните процеси. Задължително NF17 Изпълнителят трябва да осигури механизми за реализиране на бъдещи промени в Системата без промяна на съществуващия програмен код. Когато това не е възможно, времето за промяна, компилиране и пускане в експлоатация трябва да е сведено до минимум. Бъдещото развитие на Системата ще се налага във връзка с промени в правната рамка, промени в модела на работа на потребителите, промени във външни системи, интегрирани със Системата, отстраняване на констатирани проблеми, промени в модела на обслужване и др. Такива промени ще се извършват през целия период на експлоатация на системата, включително и по време на гаранционния период. Задължително NF18 Архитектурата на Системата и всички софтуерни компоненти (системни и приложни) трябва да бъдат така подбрани и/или разработени, че да осигуряват работоспособност и отказоустойчивост на системата, както и недискриминационно инсталиране (без различни условия за инсталиране върху физическа и виртуална среда) и опериране в продуктивен режим, върху виртуална инфраструктура, съответно върху Държавния хибриден частен облак (ДХЧО). Задължително NF19 Изпълнителят трябва да проектира, подготви, инсталира и конфигурира като минимум следните среди за Системата: тестова, стейджинг, продуктивна. Системата трябва да бъде разгърната върху съответните среди (тестова за вътрешни нужди, тестова за външни нужди, стейджинг и продуктивна). Тестовата среда за външни нужди трябва да бъде създадена и поддържана като "Sandbox", така че да е достъпна за използване и извършване на интеграционни тестове от разработчици на информационни системи, включително такива, изпълняващи дейности за други администрации или бизнеса, с цел по-лесно и устойчиво интегриране на съществуващи и бъдещи информационни системи. Тестовата среда за външни нужди трябва да е напълно отделна от останалите среди и нейното използване не трябва да влияе по никакъв начин на нормалната работа на останалите среди или да създава каквито и да било рискове за информационната сигурност и защитата на личните данни. Задължително NF20 Мрежата на държавната администрация (ЕЕСМ) ще бъде използвана като основна комуникационна среда и като основен доставчик на защитен Интернет капацитет (Clean Pipe) – изискванията на софтуерните компоненти по отношение на използвани комуникационни протоколи, TCP портове и пр. трябва да бъдат детайлно документирани от Изпълнителя, за да се осигури максимална защита от хакерски атаки и външни прониквания чрез прилагане на подходящи политики за мрежова и информационна сигурност от Възложителя в инфраструктурата на Държавния хибриден частен облак и ЕЕСМ. Задължително NF21 В Техническото си предложение участникът трябва да опише добрите практики, които ще прилага по отношение на всеки аспект от системната и приложната архитектура на Системата. За търсене трябва да се използват системи за пълнотекстово търсене (например Solr, Elastic Search). Не се допуска използването на индекси за пълнотекстово търсене в СУБД. Задължително NF22 Системата трябва да бъде разработена така, че да позволява използването ѝ от много различни институции (т.нар. multitenancy), като за използване от нова институция не трябва да се изисква нова инсталация. Задължително NF23 Трябва да бъде създаден административен интерфейс, чрез който може да бъде извършвана конфигурацията на софтуера.Всеки обект в системата трябва да има уникален идентификатор. Записите в регистрите не трябва да подлежат на изтриване или на промяна, а всяко изтриване или промяна трябва да представлява нов запис. Задължително Повторно използване (преизползване) на ресурси и готови разработки Код Описание Приложимост Забележка* NF24 Проектът следва максимално да преизползва налични публично достъпни инструменти, библиотеки и платформи с отворен код. За реализацията на системата следва да се използват в максимална степен софтуерни библиотеки и продукти с отворен код. Препоръчително NF25 Участникът следва да представи базов списък със свободните компоненти и средства, които възнамерява да използва. Отворените проекти трябва да отговарят на следните критерии: За разработката им да се използва система за управление на версиите на кода и да е наличен механизъм за съобщаване на несъответствия и приемане на допълнения; Да имат разработена техническа документация за актуалната стабилна версия; Да имат повече от един активен програмист, работещ по развитието им; Да имат възможност за предоставяне на комерсиална поддръжка; Да нямат намаляваща от година на година активност; По възможност проектите да са подкрепени от организации с идеална цел, държавни или комерсиални организации; По възможност проектите да имат разработени unit tests с code coverage над 50%, а проектът да използва Continuous Integration (CI) подходи – build bots, unit tests run, регулярно използване на статични/динамични анализатори на кода и др. Задължително NF26 Използването на closed source и на инструменти, библиотеки, продукти и системи с платен лиценз става за сметка на изпълнителя, като е допустимо в случаите, когато липсва подходяща свободна алтернатива с необходимата функционалност или тя не отговаря на горните условия. Задължително NF27 Изпълнителят трябва да осигури поддръжка от комерсиална организация, развиваща основните отворени продукти, които ще бъдат използвани като минимум за операционните системи и софтуерните продукти за управление на базите данни. Препоръчително NF28 При използването на свободни имплементации на софтуерни библиотеки е необходимо да се организира копие (fork) на съответното хранилище в общото хранилище за проекти с отворен код, финансирани с публични средства в България( https://git.egov.bg/explore/projects). Използващите свободните библиотеки компоненти задават за "upstream repo" хранилищата в областта governmentbg, като задължително се реферира използваната версия/ commit identificator. Задължително NF29 Когато се налага промяна в изходния код на използван софтуерен компонент, промените трябва да се извършват във fork хранилището на governmentbg в съответствие с изискванията на основния проект. Изпълнителят трябва да извърши необходимите действия за включване на направените промени в основния проект чрез "pull requests" и извършване на необходимите изисквани от разработчиците на основния проект промени до приемането им. Тези дейности трябва да бъдат извършвани по време на целия проект. При установяване на наличие на нови версии на използваните проекти се извършва анализ на влиянието върху настоящата система. В случаите, при които се оптимизира използвана функционалност, отстраняват се пропуски в сигурността, стабилността или бързодействието, новата версия се извлича и използва след успешното изпълнение на интеграционните тестове. Задължително Изграждане и поддръжка на множество среди Изпълнителят трябва да изгради и да поддържа минимум следните логически разделени среди: Среда Описаниe Development чрез Development средата се осигурява работата по разработката, усъвършенстването и развитието на Системата. В тази среда са налични и допълнителните софтуерни системи и инсталации, необходими за управление на разработката – continuous integration средства, системи за автоматизирано тестване и др. Staging чрез Staging средата се извършват тестове преди разгръщане на нова версия от Development средата върху Production средата. В нея се извършват всички интеграционни тестове, както и тестовете за натоварване. Sandbox Testing чрез Sandbox средата всички, които трябва да се интегрират към Системата, могат да тестват интеграцията си, без да застрашават работата на продукционната среда. Production това е средата, която е публично достъпна за реална експлоатация и интеграция със съответните външни системи и услуги. Управлението на средите трябва да става чрез автоматизирана система за провизиране и разгръщане на системните компоненти. При необходимост от страна на Възложителя Изпълнителят трябва да съдейства за изграждането на нови системни среди. Участникът може да предложи изграждането на допълнителни среди според спецификите на предложеното решение. 7.2.5 Процес на разработка, тестване и разгръщане Код Описание Приложимост Забележка* NF30 Процесите, свързани с развитието на Системата, трябва да гарантират висока прозрачност и възможност за обществен контрол над всички разработки по проекта. Изграждането на доверие в гражданите и в бизнеса налага радикално по-висока публичност и прозрачност чрез отворена разработка и публикуването на системите компоненти под отворен лиценз от самото начало на разработката. По този начин гражданите биха могли да съдействат в процесите по развитие и тестване на разработките през целия им жизнен цикъл. Препоръчително NF31 Всички софтуерни приложения, системи, подсистеми, библиотеки и компоненти, които са необходими за реализацията на Системата, трябва да бъдат разработвани като софтуер с отворен код и да бъдат достъпни в публично хранилище. Към настоящия момент следва да се използва общото хранилище за проекти с отворен код, финансирани с публични средства в България( HYPERLINK "https://git.egov.bg/explore/projects" https://git.egov.bg/explore/projects). В случай че върху част от компонентите, нужни за компилация, има авторски права, те могат да бъдат или в отделно хранилище с подходящия за това лиценз или за тях трябва да бъде предоставен заместващ „mock up“ компонент, така че да не се нарушава компилацията на проекта. Задължително NF32 За всеки един разработван компонент Изпълнителят трябва да покрие следните изисквания за гарантиране на качеството на извършваната разработка и на крайния продукт: Документиране на Системата в изходния код, минимум на ниво процедура/функция/клас; Покритие на минимум 50% от изходния код с функционални тестове [в случай на надграждане на съществуваща система – 50% от новата функционалност и 20% от съществуващата]; Използване на continuous integration практики; Използване на dependency management. Участникът трябва да опише детайлно подхода си за покриване на изискванията. Задължително NF33 Във всеки един компонент на Системата, който се build-ва и подготвя за инсталация (deployment), е необходимо да присъстват следните реквизити: Дата и час на build; Място/среда на build; Потребител извършил/стартирал build процеса. Идентификатор на ревизията от кодовото хранилище на компонента, срещу която се извършва build-ът. Задължително Бързодействие и мащабируемост Контрол на натоварването и защита от DoS/DDoS атаки Код Описание Приложимост Забележка* NF34 Системата трябва да поддържа на приложно ниво "Rate Limiting" и/или "Throttling" на заявки от един и същ клиентски адрес както към страниците с уеб-съдържание, така и по отношение на заявките към приложните програмни интерфейси, достъпни публично или служебно като уеб-услуги (Web Services) и служебни интерфейси. Задължително NF35 Системата трябва да позволява конфигуриране от страна на администраторите на лимитите за отделни страници, уеб-услуги и ресурси, които се достъпват с отделен URL/URI. Задължително NF36 Системата трябва да поддържа възможност за конфигуриране на различни лимити за конкретни автентикирани потребители (напр. системи на други администрации) и трябва да предоставя възможност за генериране на справки и статистики за броя заявки по ресурси и услуги. Задължително Кохерентно кеширане на данни и заявки Код Описание Приложимост Забележка* NF37 Отделните информационни системи, подсистеми и интерфейси трябва да бъдат проектирани и да използват системи за разпределен кохерентен кеш в случаите, в които това би довело до подобряване на производителността и мащабируемостта, чрез спестяване на заявки към СУБД или файловите системи на сървърите. Задължително NF38 Изпълнителят трябва да опише детайлно подхода и използваните механизми и технологии за реализация на разпределения кохерентен кеш, както и системните компоненти, които ще използват разпределения кеш. Задължително NF39 Разпределеният кохерентен кеш трябва да поддържа възможност за компресия на подходящите за това данни – например тези от текстов тип; компресирането на данни може да бъде реализирано и на приложно ниво. Задължително NF40 Използваният алгоритъм за създаване на ключове за съхранение/намиране на данни в кеша не трябва да допуска колизии и трябва оптимално да използва процесорните ресурси за генериране на хешове. Задължително NF41 Изпълнителят трябва да подбере подходящи софтуерни решения с отворен код за реализиране на буфериране и кеширане на данните в оперативната памет на сървърите. В зависимост от конкретните приложни случаи (Use Cases) е допустимо да се използват и внедрят различни технологии, които покриват по-добре конкретните нужди – например решения като Memcached или Redis в комбинация с Redis GeoAPI могат да осигурят порядъци по-висока мащабируемост и производителност за често достъпвани оперативни данни, номенклатурни данни или документи. Задължително NF42 Като минимум разпределен кохерентен кеш трябва да се предвиди при: Извличане на информация от номенклатури и атомични данни за статус и актуално състояние на партиди от регистри в информационните системи; Извличане на информация от предефинирани периодични справки; Информация от лога на транзакциите при достъп с електронно-ИД до дадена услуга; Информация за извършените плащания; Други, които са идентифицирани на етап бизнес и системен анализ. От кеша следва да бъдат изключени прикачени файлове и големи по обем резултати от справки. Задължително Бързодействие Код Описание Приложимост Забележка* NF43 При визуализация на уеб-страници системите трябва да осигуряват висока производителност и минимално време за отговор на заявки - средното време за заявка трябва да бъде по-малко от 1 секунда, с максимум 1 секунда стандартно отклонение за 95% от заявките, без да се включва мрежовото времезакъснение (Network Latency) при транспорт на пакети между клиента и сървъра [В случай че функционалните изисквания предвиждат визуализация на справки или сложни електронни документи, изискването се адаптира, като се съобразява спецификата на функционалността]. Трябва да бъдат създадени тестове за натоварване. Задължително Използване на HTTP/2 Код Описание Приложимост Забележка* NF44 С оглед намаляване на служебния трафик, времената за отговор и натоварването на сървърите следва да се използва HTTP/2 протокол при предоставяне на публични потребителски интерфейси с включени като минимум следните възможности: Включена header compression; Използване на brotli алгоритъм за компресия; Включен HTTP pipelining; HTTP/2 Server push, приоритизиращ специфични компоненти, изграждащи страниците (CSS, JavaScript файлове и др.). Задължително NF45 Публичните потребителски интерфейси трябва да поддържат адаптивен избор на TLS cipher suites според вида на процесорната архитектура на клиентското устройство - AES-GCM за x86 работни станции и преносими компютри (с налични AES-NI CPU разширения), и ChaCha20/Poly1305 за мобилни устройства (основно базирани на ARM процесори). Задължително NF46 Ако клиентският браузър/клиент не поддържа HTTP/2, трябва да бъде предвиден fall-back механизъм към HTTP/1.1. Тази възможност трябва да може лесно да се реконфигурира в бъдеще и да отпадне, когато браузърите/клиентите, неподдържащи HTTP/2, станат незначителен процент. Задължително Подписване на документи Код Описание Приложимост Забележка* NF47 При реализацията на електронно подписване с всички видове електронен подпис трябва да се подписва сигурен хеш-ключ, генериран на базата на образа/съдържанието, а не да се подписва цялото съдържание. Задължително NF48 Минимално допустимият алгоритъм за хеширане, който трябва да се използва при електронно подписване, е SHA-256. В случаите, в които не се подписва уеб съдържание (например документи, файлове и др.), е необходимо да се реализира поточно хеширане, като се избягва зареждането на цялото съдържание в оперативната памет. Задължително NF49 Системата трябва да поддържа подписване на електронни изявления и електронни документи и с електронни подписи, издадени от Доставчици на доверителни услуги в ЕС, които отговарят на изискванията за унифициран профил на електронните подписи, съгласно подзаконовите правила към Регламент ЕС 910/2014, които влизат в сила и са задължителни от 1 януари 2017 г. Задължително NF50 Трябва да бъдат анализирани техническите възможности за реализиране на подписване на електронни изявления и документи без използване на Java аплет и без да се изисква от потребителите да инсталират Java Runtime, като по този начин се осигури максимална съвместимост на процеса на подписване с всички съвременни браузъри. Такава реализация може да бъде осъществена чрез: използване на стандартни компоненти с отворен код, отговарящи на горните условия, които са разработени по други проекти на държавната администрация и са достъпни в хранилището, поддържано от Министерство на електронното управление – при наличие на такива компоненти в хранилището те трябва да се преизползват и само да бъдат интегрирани в Системата; използване на плъгин-модули с отворен код, достъпни за най-разпространените браузъри (Browser Plug-ins), които са адаптирани и поддържат унифицираните профили на електронните подписи, издавани от ДДУ в ЕС, и съответните драйвери за крайни устройства за четене на сигурни носители или по стандартизиран в националната нормативна уредба протокол за подписване извън браузъра; чрез интеграция с услуги за отдалечено подписване, предлагани от доставчици на доверителни услуги в ЕС. Задължително Качество и сигурност на програмните продукти и приложенията Код Описание Приложимост Забележка* NF51 Да бъде предвидено спазването на добри практики на софтуерната разработка – покритие на изходния код с тестове – над 60%, документиране на изходния код, използване на среда за непрекъсната интеграция (Continuous Integration), възможност за компилиране и пакетиране на продукта с една команда, възможност за инсталиране на нова версия на сървъра с една команда, система за управление на зависимостите (Dependency Management); Задължително NF52 Публичните модули, които ще предоставят информация и електронни услуги в Интернет, трябва да отговарят на актуалните уебстандарти за визуализиране на съдържание. Задължително 7.2.7 Информационна сигурност и интегритет на данните Код Описание Приложимост Забележка* NF53 Не се допуска съхранението на пароли на администратори, на вътрешни и външни потребители и на акаунти за достъп на системи (ако такива се използват) в явен вид. Всички пароли трябва да бъдат защитени с подходящи сигурни алгоритми (напр. BCrypt, PBKDF2, scrypt (RFC 7914) за съхранение на пароли и където е възможно, да се използва и прозрачно криптиране на данните в СУБД със сертификати (transparent data-at-rest encryption). Задължително NF54 Да бъде предвидена система за ежедневно създаване на резервни копия на данните, които да се съхраняват извън инфраструктурата на системата. Задължително NF55 Не се допуска използването на Self-Signed сертификати за публични услуги. Задължително NF56 Всички уебстраници (вътрешни и публично достъпни в Интернет) трябва да бъдат достъпни единствено и само през протокол HTTPS. Криптирането трябва да се базира на сигурен сертификат с валидирана идентичност (Verified Identity), позволяващ задължително прилагане на TLS 1.2, който е издаден от удостоверителен орган, разпознаван от най-често използваните браузъри (Microsoft Internet Explorer, Google Chorme, Mozilla Firefox). Ежегодното преиздаване и подновяване на сертификата трябва да бъде включено като разходи и дейности в гаранционната поддръжка за целия срок на поддръжката. Задължително NF57 Трябва да бъдат извършени тестове за сигурност на всички уебстраници, като минимум чрез автоматизираните средства на SSL Labs за изпитване на сървърна сигурност (HYPERLINK "https://www.ssllabs.com/ssltest/"https://www.ssllabs.com/ssltest/). За нуждите на автентикация с КЕП трябва да се предвиди имплементирането на обратен прокси сървър (Reverse Proxy) с балансиране на натоварването, който да препраща клиентските сертификати към вътрешните приложни сървъри с нестандартно поле (дефинирано в процеса на разработка на Системата) в HTTP Header-а. Схемата за проксиране на заявките трябва да бъде защитена от Spoofing. Задължително NF58 Като временна мярка за съвместимост настройките на уебсървърите и Reverse Proxy сървърите трябва да бъдат балансирани така, че Системата да позволява използване и на клиентски браузъри, поддържащи по-стария протокол TLS 1.1. Това изключение от общите изисквания за информационна сигурност не се прилага за достъпа на служебни потребители от държавната администрация и доставчици на обществени услуги, които имат служебен достъп до ресурси на Системата. Задължително NF59 При разгръщането на всички уебуслуги (Web Services) трябва да се използва единствено протокол HTTPS със задължително прилагане на минимум TLS 1.2. Задължително NF60 Програмният код трябва да включва методи за автоматична санитизация на въвежданите данни и потребителски действия за защита от злонамерени атаки, като минимум SQL инжекции, XSS атаки и други познати методи за атаки, и да отговаря, където е необходимо, на Наредбата за минималните изисквания за мрежова и информационна сигурност. Задължително NF61 При проектирането и разработката на компонентите на Системата и при подготовката и разгръщането на средите трябва да се спазват последните актуални препоръки на OWASP (Open Web Application Security Project). Задължително NF62 Трябва да бъде изграден модул за проследимост на действия и събития в Системата. За всяко действие (добавяне, изтриване, модификация, четене) трябва да съдържа следните атрибути: Уникален номер; Точно време на възникване на събитието; Вид (номенклатура от идентификатори за вид събитие); Данни за информационна система, където е възникнало събитието; Име или идентификатор на компонент в информационната система, регистрирал събитието; Приоритет; Описание на събитието; Данни за събитието. Задължително NF63 Астрономическото време за удостоверяване настъпването на факти с правно или техническо значение се отчита с точност до година, дата, час, минута, секунда и при технологична необходимост - милисекунда, изписани в съответствие със стандарта БДС ISO 8601:2006. Задължително NF64 Астрономическото време за удостоверяване настъпването на факти с правно значение и на такива, за които се изисква противопоставимост, трябва да бъде удостоверявано с електронен времеви печат по смисъла на Глава III, Раздел 6 от Регламент ЕС 910/2014. Трябва да бъде реализирана функционалност за получаване на точно астрономическо време, отговарящо на горните условия, и от доставчик на доверителни услуги или от държавен орган, осигуряващ такава услуга, отговаряща на изискванията на RFC 3161. Задължително NF65 Трябва да бъдат проведени тестове за проникване (penetration tests), с които да се идентифицират и коригират слаби места в сигурността на системата. Задължително NF66 При идентификация на регистри и бази данни да се използва електронно удостоверение във формат X.509, издаден за съответния регистър. Идентификацията се осъществява двустранно по протокол TLS (Transport Layer Security - Сигурност на транспортния слой), версия 1.2 или по-висока, дефиниран в Препоръка RFC 5246, приета от IETF Задължително NF67 Информационните системи на административните органи да се идентифицират пред регистрите чрез цифров сертификат, двустранно по протокол TLS (Transport Layer Security - Сигурност на транспортния слой), версия 1.2 или по-висока. Задължително 7.2.8 Използваемост Общи изисквания за използваемост и достъпност Код Описание Приложимост NF68 При проектирането и разработката на интернет страници и мобилни приложение трябва да се спазват изискванията на хармонизирания стандарт EN 301 549, последната обнародвана версия в Официалния вестник на Европейския съюз. Задължително NF69 Спецификацията да отговаря на изискванията за достъпността на Интернет страници и мобилни приложения, съгласно хармонизирания стандарт EN 301 549 V2.1.2 (2018-08) - касаещ достъпността на продукти и услуги в сферата на ИКТ, освен в случаите по чл. 58в, ал. 2 или 3 от ЗЕУ. Задължително NF70 Всички ресурси трябва да са достъпни чрез GET заявка на уникален адрес (URL). Не се допуска използване на POST за достигане до формуляр за подаване не заявление, за генериране на справка и други. Задължително NF71 Функционалностите на потребителския интерфейс на Системата трябва да бъдат независими от използваните от потребителите интернет браузъри и устройства, при условие че последните са версии в период на поддръжка от съответните производители. Трябва да бъде осигурена възможност за ползване на публичните модули на приложимите услуги през мобилни устройства – таблети и смарт-телефони, чрез оптимизация на потребителските интерфейси за мобилни устройства (Responsive Design). При използване на Captcha, се осигуряват алтернативни форми с използване на изходи за различни видове сетивни възприятия, съобразени с различните увреждания. Задължително NF72 Не се допуска използване на капча (Captcha) като механизъм за ограничаване на достъпа до документи и/или услуги. Алтернативно, Системата трябва да поддържа "Rate Limiting" и/или "Throttling" съгласно изискванията в т. 7.1.1. от настоящите изисквания. Допуска се използването на Captcha единствено при иденетифицирани много последователни опити от предполагаем „бот“. Задължително NF73 Трябва да бъде осигурен бърз и лесен достъп до електронните услуги и те да бъдат промотирани с подходящи навигационни елементи на публичната интернет страница – банери, елементи от главното меню и др. Задължително NF74 Публичните уеб страници на Системата трябва да бъдат проектирани и оптимизирани за ефективно и бързо индексиране от търсещи машини с цел популяризиране сред потребителите и по-добра откриваемост при търсене по ключови думи и фрази. При разработката на страниците и при изготвяне на автоматизираните процедури за разгръщане на нова версия на Системата трябва да се използват инструменти за минимизиране и оптимизация на размера на изходния код (HTML, JavaScript и пр.) с оглед намаляване обема на файловете и по-бързо зареждане на страниците. Задължително NF75 Не се допуска използването на HTML Frames, за да не се пречи на оптимизациите за търсещи машини. Задължително NF76 При разработката на публични уеббазирани страници трябва да се използват и да се реализира поддръжка на: Стандартните семантични елементи на HTML5 (HYPERLINK "http://www.w3schools.com/html/html5_semantic_elements.asp"HTML Semantic Elements); JSON-LD 1.0 (HYPERLINK "http://www.w3.org/TR/json-ld/"http://www.w3.org/TR/json-ld/); Open Graph Protocol (HYPERLINK "http://ogp.me"http://ogp.me) за осигуряване на поддръжка за качествено споделяне на ресурси в социални мрежи и мобилни приложения. Задължително NF77 В екранните форми на Системата трябва да се използват потребителски бутони с унифициран размер и лесни за разбиране текстове в еднакъв стил. Задължително NF78 Всички текстови елементи от потребителския интерфейс трябва да бъдат визуализирани с шрифтове, които са подходящи за изобразяване на екран и които осигуряват максимална съвместимост и еднакво възпроизвеждане под различни клиентски операционни системи и браузъри. Не се допуска използването на серифни шрифтове (Serif). Задължително NF79 Полета, опции от менюта и командни бутони, които не са разрешени конкретно за ролята на влезлия в системата потребител, не трябва да са достъпни за този потребител. Това не отменя необходимостта от ограничаване на достъпа до бизнес логиката на приложението чрез декларативен или програмен подход. Задължително NF80 Всяка екранна форма трябва да има наименование, което да се изписва в горната част на екранната форма. Наименованията трябва да подсказват на потребителя какво е предназначението на формата. Задължително NF81 Всички търсения трябва да са нечувствителни към малки и главни букви. Задължително NF82 Полетата за пароли трябва задължително да различават малки и главни букви. Задължително NF83 Полетата за потребителски имена трябва да позволяват използване на имейл адреси като потребителско име, включително да допускат всички символи, регламентирани в RFC 1123, за наименуването на хостове. Задължително NF84 Главните и малките букви на въвежданите данни се запазват непроменени, не се допуска Системата да променя капитализацията на данните, въвеждани от потребителите. Задължително NF85 Системата трябва да позволява въвеждане на данни, съдържащи както български, така и символи на официалните езици на ЕС. Задължително NF86 Наименованията на полетата следва да са достатъчно описателни, като максимално се доближават до характера на съдържащите се в тях данни. Задължително NF87 Системата трябва да поддържа прекъсване на потребителски сесии при липса на активност. Времето трябва да може да се променя от администратора на системата без промяна в изходния код. Настройките за време за прекъсване на неактивни сесии трябва да включват и възможността администраторите да дефинират стилизирана страница с информативно съобщение, към която Системата да пренасочва автоматично браузърите на потребителите в случай на прекъсната сесия. Задължително NF88 Дългите списъци с резултати трябва да се разделят на номерирани страници с подходящи навигационни елементи за преминаване към предишна, следваща, първа и последна страница, към конкретна страница. Навигационните елементи трябва да са логически обособени и свързани със съответния списък и да се визуализират в началото и в края на HTML контейнера, съдържащ списъка. Задължително NF89 За големите йерархически категоризации трябва да се предвиди възможност за навигация по нива или чрез отложено зареждане (lazy load). Задължително Интернет страниците на администрациите трябва отговарят на правилата за институционална идентичност, определени от министъра на електронното управление. Наименованията на домейните и поддомейните, използвани от административните органи за официалните им интернет страници и портали трябва да отговарят на изискванията на чл. 47 от НОИИСРЕАУ. Задължително Интернационализация Код Описание Приложимост Забележка NF90 Системата трябва да може да съхранява и едновременно да визуализира данни и съдържание, което е въведено/генерирано на различни езици. Задължително NF91 Всички софтуерни компоненти на Системата, използваните софтуерни библиотеки и развойни комплекти, приложните сървъри и сървърите за управление на бази данни, елементите от потребителския интерфейс, програмно-приложните интерфейси, уебуслугите и др. трябва да поддържат стандартно и да са конфигурирани изрично за спазване на минимум Unicode 5.2 стандарт при съхранението и обработката на текстови данни, съответно трябва да се използва само UTF-8 кодиране на текстовите данни. Задължително NF92 Всички публично достъпни потребителски интерфейси следва да поддържат многоезичност, като минимум български и английски език. Задължително NF93 Публичната част на Системата трябва да бъде разработена и да включва набори с текстове на минимум два официални езика в ЕС, а именно български и английски език. Преводите на английски език трябва да бъдат осъществени професионално, като не се допуска използването на средства за машинен превод без ръчна проверка и корекции от професионални преводачи. Задължително NF94 Версиите на съдържанието на съответните езици трябва да включват всички текстове, които се визуализират във всички елементи на потребителския интерфейс, справките, генерираните от системата електронни документи, съобщения, нотификации, имейл съобщения, номенклатурите и таксономиите и др. Данните, които се съхраняват в системата само на български език, се изписват/визуализират на български език. Задължително NF95 Системата трябва да позволява превод на всички многоезични текстове с подходящ потребителски интерфейс, достъпен за администратори на Системата, без промени в изходния код. Модулът за превод на текстове, използвани в Системата, трябва да поддържа и контекстни референции, които да позволяват на администраторите да тестват и да проверяват бързо и лесно направените преводи и тяхната съгласуваност в реалните екрани, страници и документи. Задължително NF96 Публичната част на Системата трябва да позволява превключване между работните езици на потребителския интерфейс в реално време от профила на потребителя и от подходящ, видим и лесно достъпен навигационен елемент в горната част на всяка страница, който включва не само текст, но и подходяща интернационална икона за съответния език. Задължително NF97 При визуализация на числа трябва да се използва разделител за хиляди (интервал). Задължително NF98 При визуализация на дати и точно време в елементи от потребителския интерфейс в генерирани справки или в електронни документи всички формати за дата и час трябва да са съобразени с избрания от потребителя език/локация в настройките на неговия профил: За България стандартният формат е „DD.MM.YYYY HH:MM:SS”, като наличието на време към датата е в зависимост от вида на визуализираната информация и бизнес-смисъла от показването на точно време; Системата трябва да поддържа и всички формати съгласно ISO БДС 8601:2006; Задължително Изисквания за използваемост на потребителския интерфейс Код Описание Приложимост Забележка NF99 Електронните форми за подаване на заявления и за обявяване на обстоятелства трябва да бъдат реализирани с AJAX или с аналогична технология, като по този начин се гарантират следните функционалности: Контекстна валидация на въвежданите данни на ниво "поле" от форма и контекстни съобщения за грешка/невалидни данни в реално време; Възможност за избор на стойности от номенклатури чрез търсене в списък по част от дума (autocomplete) и визуализиране на записи, отговарящи на въведеното до момента, без да е необходимо пълните номенклатури да са заредени в браузъра на клиента и потребителят да скорлира дълги списъци с повече от 10 стойности; Задължително NF100 В електронните форми трябва да бъде реализирана валидация на въвежданите от потребителите данни на ниво "поле" (in-line validation). Валидацията трябва да се извършва в реално време на сървъра, като при успешна валидация данните от съответното поле следва да бъдат запазени от сървъра. Задължително NF101 Системата трябва да гарантира, че въведените, валидираните и запазените от сървъра данни остават достъпни за потребителите дори за процеси, които не са приключили, така че при волно, неволно или автоматично прекъсване на потребителската сесия поради изтичане на периода за допустима липса на активност потребителят да може да продължи съответния процес след повторно влизане в системата, без да загуби въведените до момента данни и прикачените до момента електронни документи. Задължително NF102 Трябва да бъде реализирана възможност за добавяне и редактиране от страна на администраторите на системата, без да са необходими промени в изходния код, на контекстна помощна информация за: всяка електронна форма или стъпка от процес, за която има отделен екран/форма; всяка група полета за въвеждане на данни (в случаите, в които определени полета от формата са групирани тематично); всяко отделно поле за въвеждане на данни. Задължително NF103 Трябва да бъде разработена контекстна помощна информация за всички процеси, екрани и електронни форми, включително ясни указания за попълване и разяснения за особеностите при попълване на различните групи полета или на отделни полета. Задължително NF104 Контекстната помощна информация, указанията към потребителите и информативните текстове за всяка електронна административна услуга не трябва да съдържат акроними, имена и референции към нормативни документи, които са въведени като обикновен текст (plain-text). Всички акроними, референции към нормативни документи, формуляри, изисквания и др. трябва да бъдат разработени като хипервръзки към съответните актуални версии на нормативни документи и/или към съответния речник/списък с акроними и термини. Задължително NF105 Достъпът на потребителя до контекстната помощна информация трябва да бъде реализиран по унифициран и консистентен начин чрез подходящи навигационни елементи, като например чрез подходящо разположени микро-бутони с икони, разположени до/пред/след етикета на съответния елемент, за който се отнася контекстната помощ, или чрез обработка на "Mouse Hover/Mouse Over" събития. Задължително NF106 При проектирането и реализацията на потребителския интерфейс трябва да се отчете, че той трябва да бъде еднакво използваем и от мобилни устройства (напр. таблети), които не разполагат с мишка, но имат чувствителни на допир екрани. Задължително NF107 Потребителският интерфейс следва да бъде достъпен за хора с увреждания съгласно изискванията на чл. 48, ал. 5 от ЗОП. Задължително Изисквания за използваемост в случаи на прекъснати бизнес процеси Код Описание Приложимост Забележка NF108 Системата трябва да съхранява перманентно всеки започнал процес/процедура по подаване на заявление или обявяване на обстоятелства, текущия му статус и всички въведени данни и прикачени документи дори ако потребителят е прекъснал волно или неволно потребителската си сесия. Задължително NF109 При вход в системата потребителят трябва да получава прегледна и ясна нотификация, че има започнати, но недовършени/ неизпратени/ неподписани заявления, и да бъде подканен да отвори модула за преглед на историята на транзакциите. Задължително NF110 Модулът за преглед на историята на транзакциите трябва да поддържа следните функционалности: Да визуализира списък с историята на подадените заявления, като минимум със следните колони – дата, входящ номер, код на тупа формуляр, подател (име на потребител и имена на физическото лице - подател), статус на заявлението; Да предлага видни и лесни за използване от потребителите контроли/инструменти: за филтриране на списъка (от дата до дата, за предефинирани периоди, като "последния един месец", "последната една година"; сортиране на списъка по всяка от колоните, без това да премахва текущия филтър; свободно търсене по ключови думи по всички колони в списъка и метаданните на прикачените/свързаните документи със заявленията, което да води до динамично филтриране на списъка. Задължително Изисквания за проактивно информиране на потребителите Код Описание Приложимост Забележка NF111 За всички публични интернет страници трябва да бъде реализирана функционалност за публикуване на всяко периодично обновявано съдържание (новини, обявления, обществени поръчки, отворени работни позиции, нормативни документи, отговори по ЗДОИ и др.) в стандартен формат (RSS 2.х, Atom или еквивалент), както и поддържането на публично достъпни статистики за посещаемостта на страницата. Задължително NF112 Системата трябва да поддържа възможност за автоматично генериране на електронни бюлетини, които да се разпращат периодично или при настъпване на събития по електронна поща до регистрираните в Системата потребители, които са заявили или са се съгласили да получават такива бюлетини; Потребителите трябва да имат възможност да настройват предпочитанията през потребителския си профил в Системата. Задължително 7.2.9 Системен журнал Код Описание Приложимост Забележка NF113 Атрибутите, които трябва да се запазват при всеки запис, трябва да включват като минимум следните данни: дата/час на действието; модул на системата, в който се извършва действието; действие; обект, над който е извършено действието; допълнителна информация; IP адрес и браузър на потребителя. Задължително NF114 По време на работа на системата потребителският журнал трябва да се записва в специализиран компонент, който поддържа много бързо добавяне на записи; този подход се налага, за да не се забавя излишно работата на Системата. Задължително NF115 Специална фонова задача трябва да акумулира записаните данни и да ги организира в отделна специално предвидена за целта база данни, отделна от работната база данни на системата. Задължително NF116 Данните в специализираната база данни трябва да се архивират и изчистват, като в специализираната база данни трябва да бъде достъпна информация за не повече от 2 месеца назад; при необходимост от информация за предишен период администраторът на системата трябва първо да възстанови архивните данни. Задължително NF117 Трябва да бъде предоставен достъп до системния журнал на органите на реда чрез потребителски или програмен интерфейс; за достъпа трябва да се изисква електронна идентификация. Задължително 7.2.10 Дизайн на бази данни и взаимодействие с тях Код Описание Приложимост Забележка NF118 Дизайнът на схемата на базата данни (ако има такава) трябва да бъде с максимално ниво на нормализация, освен ако това не би навредило сериозно на производителността. Задължително NF119 Базата данни трябва да може да оперира в клъстър; в определени случаи следва да бъде използван т.нар. sharding. Задължително NF120 Имената на таблиците и колоните трябва да следват унифицирана конвенция. Задължително NF121 Трябва да бъдат създадени индекси по определени колони, така че да се оптимизират най-често използваните заявки; създаването на индекс трябва да е мотивирано и подкрепено със замервания. Задължително NF122 Връзките между таблици трябва да са дефинирани чрез foreign key. Задължително NF123 Периодично трябва да бъде правен анализ на заявките, включително чрез EXPLAIN (при SQL бази данни), и да бъдат предприети мерки за оптимизиране на бавните такива. Задължително NF124 Задължително трябва да се използват транзакции, като нивото на изолация трябва да бъде мотивирано в предадената документация. Задължително NF125 При операции върху много записи (batch) следва да се избягват дългопродължаващи транзакции. Задължително NF126 Заявките трябва да бъдат ограничени в броя записи, които връщат. Задължително NF127 При използване на ORM или на друг слой на абстракция между приложението и базата данни, трябва да се минимизира броят на излишните заявки (т.нар. n+1 selects проблем). Задължително NF128 При използване на нерелационна база данни трябва да се използват по-бързи и компактни протоколи за комуникация, ако такива са достъпни. Задължително 7.2.11 Изисквания по отношение на киберсигурност в съответствие с чл. 12, ал. 1 от НМИМИС С цел достигане на изискваното ниво на сигурност на информацията, в мрежите и информационните системи следва да се предвидят следните изисквания: Код Описание Приложимост Забележка NF129 Да бъдат включени адекватни и комплексни изисквания за мрежова и информационна сигурност, основани на анализ и оценка на риска, с цел да се гарантира, че изискваното ниво на сигурност на информацията, мрежите и информационните системи е заложено още в етапа на разработка и внедряване Задължително NF130 Да се представят анализ и оценка на риска, които да послужат като основа за включването на адекватни и комплексни изисквания за мрежова и информационна сигурност. Задължително NF131 Ненужните портове по протоколи TCP и User Datagram Protocol (UDP) да бъдат забранени чрез адекватно конфигуриране на използваните софтуерни решения, хардуерни устройства и оборудване за защита и контрол на трафика. Задължително NF132 Да се използва отделна, изолирана от другите информационни и комуникационни системи и от интернет, подходящо защитена среда (мрежа, система, софтуер и др.) за целите на администриране на информационните и комуникационните системи и техните компоненти. Тази среда трябва да не се използва за други цели. Задължително NF133 Да се валидират всички входни данни, постъпващи от клиента, включително съдържанието, предоставено от потребителя и съдържанието на браузъра, като headеrs на препращащия и потребителски агент Задължително NF134 Всички данни да бъдат кодирани с HTML, изпращани от клиента и показвани в уеб страница. Задължително NF135 Да се ограничават заявките и по-специално по максимална дължина на съдържанието, максимална дължина на заявката и максимална дължина на заявката по URL. Задължително Да се конфигурира типът и размерът на headers, които уеб сървърът ще приеме. NF136 Да се ограничава времетраенето на връзката (connection Timeout) - времето, за което сървърът изчаква всички headers на заявката, преди да я прекъсне, както и минималният брой байтове в секунда при изпращане на отговор на заявка. Задължително NF137 Да се въведе ограничение на броя неуспешни опити за влизане в системата Задължително NF138 Да не се допуска извеждането на списък на уеб директориите. Задължително NF139 Бисквитките (cookies) задължително да имат: флаг за защита (security flag), който инструктира браузъра, че „бисквитката“ може да бъде достъпна само чрез защитени SSL канали; флаг HTTP only, който инструктира браузъра, че „бисквитката“ може да бъде достъпна само от сървъра, а не от скриптовете, от страна на клиента. Задължително NF140 Да се предвидят и предприемат мерки за защита на DNS, като задължително се прилага DNSSEC (Domain Name System Security Extensions); - не е приложимо – това е вътрешна система, а не публична. Задължително NF141 По отношение на системните записи (Logs) да бъдат предвидени следните възможности: в сървъри за приложения, които поддържат критични дейности, сървъри от системната инфраструктура, сървъри от мрежовата инфраструктура, охранителни съоръжения, станции за инженеринг и поддръжка на индустриални системи, мрежово оборудване и работни места на администратори се регистрират автоматично всички събития, които са свързани най-малко с автентикация на потребителите, управление на профилите, правата на достъп, промени в правилата за сигурност и функциониране на информационните и комуникационните системи; за всяко от тези събития в записите се отбелязва с астрономическото време, когато е настъпило събитието; да бъде предвидена възможност за синхронизиране на часовниците на компоненти на информационните и комуникационните системи, като се използва протокол NTP V4 (Network Time Protocol, версия 4.0 и следващи), основан на RFC 5905 на IETF от 2010 г., като се осигурява хронометрична детерминация с времевата скала на UTC (Coordinated Universal Time), или аналогичен; да се предвиди как информацията ще бъде архивирана за срок не по-кратък от дванадесет месеца Задължително ИЗИСКВАНИЯ КЪМ ИЗПЪЛНЕНИЕТО НА ДЕЙНОСТИТЕ ПО ПРОЕКТА Дейност 1 [Наименование на дейността] Описание на дейността Изисквания към изпълнение на дейността Очаквани резултати Дейност 2 [Наименование на дейността] Описание на дейността Изисквания към изпълнение на дейността Очаквани резултати Дейност 3 [Наименование на дейността] Описание на дейността Изисквания към изпълнение на дейността Очаквани резултати Дейност 4 [Наименование на дейността] Описание на дейността Изисквания към изпълнение на дейността Очаквани резултати Дейност 5 [Наименование на дейността] Описание на дейността Изисквания към изпълнение на дейността Очаквани резултати ДОКУМЕНТАЦИЯ Изисквания към документацията Цялата документация и всички технически описания, ръководства за работа, администриране и поддръжка на Системата, включително и на нейните съставни части, трябва да бъдат налични и на български език; Всички документи трябва да бъдат предоставени от Изпълнителя в електронен формат (ODF/ /Office Open XML/MS Word DOC/RTF/PDF/HTML или др.), позволяващ пълнотекстово търсене/търсене по ключови думи и копиране на части от съдържанието от оригиналните документи във външни документи, за вътрешна употреба на възложителя; Навсякъде, където в документацията има включени диаграми или графики, те трябва да бъдат вградени в документите в оригиналния си векторен формат; Детайлна техническа документация на програмния приложен интерфейс (API), включително за поддържаните уебуслуги, команди, структури от данни и др. Документацията да бъде придружена и с примерен програмен код и/или библиотеки (SDK) за реализиране на интеграция с външни системи, разработен(и) на Java или .NET. Примерният код трябва да е напълно работоспособен и да демонстрира базови итерации с API-то: Регистриране на крайна точка (end-point) за получаване на актуализации от Системата в реално време; Заявки за получаване на номенклатурни данни (списъци, таксономии); Заявки за актуализиране на номенклатурни данни (списъци, таксономии); Регистрация на потребител; Идентификация и оторизация на потребител или уебуслуга; Документацията за приложния програмен интерфейс (API) трябва да бъде публично достъпна; Всеки предоставен REST приложно-програмен интерфейс трябва да бъде документиран чрез API Blueprint (HYPERLINK "https://github.com/apiaryio/api-blueprint"https://github.com/apiaryio/api-blueprint), Swagger (HYPERLINK "http://swagger.io"http://swagger.io) или чрез аналогична технология. Аналогично представяне трябва да бъде изготвено и за SOAP интерфейсите; Детайлна техническа документация за схемата на базата данни – структури за данни, индекси, дялове, съхранени процедури, конфигурации за репликация на данни и др. Ръководства на потребителя и администратора за работа и администриране на Системата Обща информация, инструкции и процедури за администриране и поддръжка на приложните сървъри, сървърите за бази данни и др. Обща информация, инструкции и процедури за администриране, архивиране и възстановяване, и поддръжка на сървъра за управление на бази данни. Прозрачност и отчетност В обхвата на проекта е включено извършване на дейности по анализ на бизнес процеси и нормативна уредба, проектиране на системна и приложна архитектура, разработване на компютърни програми и други дейности, свързани с предоставяне на специализирани професионални услуги. Изпълнителят и възложителят трябва да публикуват подробни месечни отчети в машинночетим отворен формат за извършените дейности, включително количеството изработени човекодни по дейности, извършени от консултанти, експерти, специалисти и служители на изпълнителя и възложителя. Документацията, предоставена от изпълнителя на възложителя, трябва да бъде: на български език; само в електронен формат, като копирането и редактирането на предоставените документи следва да бъде лесно осъществимо; актуализирана в съответствие със съгласувана с възложителя процедура, която следва да включва документи, подлежащи на промяна/актуализация, крайни срокове и нужната за случая методология. Минимално изискуемата документация по проекта включва долуизброените документи. Системен проект Изпълнителят на настоящата поръчка трябва да дефинира в детайли конкретния обхват на реализация на софтуерната разработка и да документира изискванията към софтуера в детайлна техническа спецификация (системен проект), която ще послужи за пряка изходна база за разработка. При документирането на изискванията, с цел постигане на яснота и стандартизация на документите, е необходимо да се използва утвърдена нотация за описание на бизнес модели. Изготвената детайлна техническа спецификация (системен проект) се представя за одобрение на възложителя. В случай на забележки, корекции или допълнения от страна на възложителя изпълнителят е длъжен да ги отрази в детайлната техническа спецификация (системен проект). Техническа документация Всички продукти, които ще се доставят, трябва да са със специфична документация за инсталиране и/или техническа документация, в това число: Ръководство за администратора, включващо всички необходими процедури и скриптове по инсталиране, конфигуриране, архивиране, възстановяване и други, необходими за администриране на системата; Документи за крайния ползвател – Изпълнителят трябва да предостави главното Ръководство на ползвателите на софтуера. Документът е предназначен за крайните ползватели. Той трябва да описва цялостната функционалност на приложния софтуер и съответното му използване от крайни ползватели; Детайлно описание на базата данни; Описание на софтуерните модули; Описание на изходния програмен код. Протоколи Изпълнителят трябва да изготвя протоколи от изпълнението на различните етапи на проекта, описани в раздел 8 на настоящия документ, заедно със съпътстващите ги документи – резултати от изпълнението на етапите. Комуникация и доклади За успешното изпълнение на проекта участниците в настоящата обществена поръчка трябва да предложат адекватен механизъм за управление на проектната комуникация, който е неразделна част от предлаганата цялостна проектна методология. Управлението на комуникацията трябва да включва изготвяне на минимум следните регулярни доклади за статуса и напредъка на изпълнението на поръчката: Встъпителен доклад Встъпителният доклад трябва да бъде предоставен до един месец от подписването на договора и да съдържа описание минимум на: Подробен работен план и актуализиран времеви график за периода на проекта; Начини на комуникация; Отговорни лица и екипи. Встъпителният доклад следва да бъде одобрен от възложителя. Междинни доклади Междинните доклади трябва да бъдат представяни и да се предават при приключване на всяка от дейностите и поддейностите и/или при настъпване на събитие. Междинните доклади трябва да съдържат информация относно изпълнението на дейностите и поддейностите по предварително изготвения проектен план. Докладът за междинния напредък трябва да бъде подготвен по следния начин: Общ прогрес по дейностите през периода; Постигнати проектни резултати за периода; Срещнати проблеми, причини и мерки, предприети за преодоляването им; Рискове за изпълнение на свързани дейности и на проекта като цяло и предприети мерки; Актуализиран план за изпълнение, ако има такъв. Всеки междинен доклад следва да бъде одобрен от възложителя. Окончателен доклад В края на периода за изпълнение трябва да се представи окончателен доклад. Окончателният доклад трябва да съдържа описание на изпълнението и резултати. Докладите се изпращат до отговорния служител на възложителя. За тази цел възложителят ще определи в договора отговорния/отговорните служител/служители. Всички доклади се представят на български език в електронен формат и изпращат от Изпълнителя по договора чрез системата за сигурно електронно връчване или на официалния е-мейл на Възложителя. . Докладите се одобряват от отговорния/отговорните служител/служители в срок до 5 работни дни.Възложителят задължително входира в своята деловодна система преписката по договора. Всички доклади трябва да се представят на възложителя на български език на електронен носител. Представянето на докладите трябва да се извършва чрез подписване на двустранни предавателно-приемателни протоколи, подписани от представители на изпълнителя и на възложителя. Възложителят разглежда представените доклади и уведомява изпълнителя за приемането им без забележки или ги връща за преработване, допълване и/или окомплектоване, ако не отговарят на изискванията, като чрез упълномощено в договора лице дава указания и определя срок за отстраняване на констатираните недостатъци и пропуски. РЕЗУЛТАТИ Очакваните резултати от изпълнението на настоящата обществена поръчка са следните: (Описват се конкретните резултати съобразно одобреното проектно предложение) Приложение № 2 към чл. 38, ал. 4 Приложим само за дейности по адаптиране на информационните системи, регистри или бази данни във връзка с въвеждане на еврото в Република България! [Възложител] ТЕХНИЧЕСКА СПЕЦИФИКАЦИЯ за [ Име на проект] СЪДЪРЖАНИЕ TOC \o "1-3" \h \z \u HYPERLINK \l "_Toc146093914" СЪДЪРЖАНИЕ PAGEREF _Toc146093914 \h 2 HYPERLINK \l "_Toc146093915" 1. РЕЧНИК НА ТЕРМИНИ, ДЕФИНИЦИИ И СЪКРАЩЕНИЯ PAGEREF _Toc146093915 \h 4 HYPERLINK \l "_Toc146093916" 1.1. Използвани акроними PAGEREF _Toc146093916 \h 4 HYPERLINK \l "_Toc146093917" 1.2. Технологични дефиниции PAGEREF _Toc146093917 \h 4 HYPERLINK \l "_Toc146093918" 1.3. Дефиниции за нива на електронизация на услугите PAGEREF _Toc146093918 \h 6 HYPERLINK \l "_Toc146093919" 2. ВЪВЕДЕНИЕ PAGEREF _Toc146093919 \h 6 HYPERLINK \l "_Toc146093920" 2.1. Цел на документа PAGEREF _Toc146093920 \h 7 HYPERLINK \l "_Toc146093921" 2.2. За възложителя – функции и структура PAGEREF _Toc146093921 \h 7 HYPERLINK \l "_Toc146093922" 2.3. За проекта PAGEREF _Toc146093922 \h 8 HYPERLINK \l "_Toc146093923" 2.4. Нормативна рамка PAGEREF _Toc146093923 \h 8 HYPERLINK \l "_Toc146093924" 3. ЦЕЛИ, ОБХВАТ И ОЧАКВАНИ РЕЗУЛТАТИ ОТ ИЗПЪЛНЕНИЕ НА ПРОЕКТА PAGEREF _Toc146093924 \h 9 HYPERLINK \l "_Toc146093925" 3.1. Общи и специфични цели на проекта PAGEREF _Toc146093925 \h 9 HYPERLINK \l "_Toc146093926" 3.2. Обхват на проекта PAGEREF _Toc146093926 \h 9 HYPERLINK \l "_Toc146093927" 3.3. Целеви групи PAGEREF _Toc146093927 \h 9 HYPERLINK \l "_Toc146093928" 3.4. Очаквани резултати PAGEREF _Toc146093928 \h 9 HYPERLINK \l "_Toc146093929" 3.5. Период на изпълнение PAGEREF _Toc146093929 \h 10 HYPERLINK \l "_Toc146093930" 4. ТЕКУЩО СЪСТОЯНИЕ PAGEREF _Toc146093930 \h 10 HYPERLINK \l "_Toc146093931" 5. ИЗИСКВАНИЯ КЪМ ИЗПЪЛНЕНИЕ НА ПОРЪЧКАТА PAGEREF _Toc146093931 \h 10 HYPERLINK \l "_Toc146093932" 5.1. Общи изисквания към изпълнението на обществената поръчка PAGEREF _Toc146093932 \h 10 HYPERLINK \l "_Toc146093933" 5.2. Управление на проекта PAGEREF _Toc146093933 \h 11 HYPERLINK \l "_Toc146093934" 5.3. Управление на риска PAGEREF _Toc146093934 \h 12 HYPERLINK \l "_Toc146093935" 6. ЕТАПИ НА ИЗПЪЛНЕНИЕ НА ПРОЕКТА PAGEREF _Toc146093935 \h 13 HYPERLINK \l "_Toc146093936" 6.1 Анализ на данните и изискванията PAGEREF _Toc146093936 \h 13 HYPERLINK \l "_Toc146093937" 6.2 Изготвяне на системен проект PAGEREF _Toc146093937 \h 13 HYPERLINK \l "_Toc146093938" 6.3 Разработване на софтуерното решение PAGEREF _Toc146093938 \h 14 HYPERLINK \l "_Toc146093939" 6.4 Тестване PAGEREF _Toc146093939 \h 14 HYPERLINK \l "_Toc146093940" 6.5 Внедряване PAGEREF _Toc146093940 \h 14 HYPERLINK \l "_Toc146093941" 6.6 Обучение PAGEREF _Toc146093941 \h 14 HYPERLINK \l "_Toc146093942" 6.7 Гаранционна поддръжка PAGEREF _Toc146093942 \h 15 HYPERLINK \l "_Toc146093943" 7. ОБЩИ ИЗИСКВАНИЯ ЗА ИНФОРМАЦИОННИ СИСТЕМИ В ДЪРЖАВНАТА АДМИНИСТРАЦИЯ PAGEREF _Toc146093943 \h 16 HYPERLINK \l "_Toc146093944" 7.1 Интеграция с външни информационни системи PAGEREF _Toc146093944 \h 16 HYPERLINK \l "_Toc146093945" 7.2 Авторски права и изходен код PAGEREF _Toc146093945 \h 16 HYPERLINK \l "_Toc146093946" 7.3 Системна и приложна архитектура PAGEREF _Toc146093946 \h 17 HYPERLINK \l "_Toc146093947" 7.4 Качество и сигурност на програмните продукти и приложенията PAGEREF _Toc146093947 \h 18 HYPERLINK \l "_Toc146093948" 7.5 Информационна сигурност и интегритет на данните PAGEREF _Toc146093948 \h 18 HYPERLINK \l "_Toc146093949" 7.6 Системен журнал PAGEREF _Toc146093949 \h 21 HYPERLINK \l "_Toc146093950" 7.7 Дизайн на бази данни и взаимодействие с тях PAGEREF _Toc146093950 \h 21 HYPERLINK \l "_Toc146093951" 7.8 Специфични изисквания при адаптиране на ИС за работа с евро PAGEREF _Toc146093951 \h 21 HYPERLINK \l "_Toc146093952" 8. ИЗИСКВАНИЯ КЪМ ИЗПЪЛНЕНИЕТО НА ДЕЙНОСТИТЕ ПО ПРОЕКТА PAGEREF _Toc146093952 \h 24 HYPERLINK \l "_Toc146093953" 8.1. Дейност 1 [Наименование на дейността] PAGEREF _Toc146093953 \h 24 HYPERLINK \l "_Toc146093954" 8.1.1. Описание на дейността PAGEREF _Toc146093954 \h 24 HYPERLINK \l "_Toc146093955" 8.1.2. Изисквания към изпълнение на дейността PAGEREF _Toc146093955 \h 24 HYPERLINK \l "_Toc146093956" 8.1.3. Очаквани резултати PAGEREF _Toc146093956 \h 24 HYPERLINK \l "_Toc146093957" 8.2. Дейност … [Наименование на дейността] PAGEREF _Toc146093957 \h 24 HYPERLINK \l "_Toc146093958" 8.2.1. Описание на дейността PAGEREF _Toc146093958 \h 24 HYPERLINK \l "_Toc146093959" 8.2.2. Изисквания към изпълнение на дейността PAGEREF _Toc146093959 \h 24 HYPERLINK \l "_Toc146093960" 8.2.3. Очаквани резултати PAGEREF _Toc146093960 \h 24 HYPERLINK \l "_Toc146093961" 9. ДОКУМЕНТАЦИЯ PAGEREF _Toc146093961 \h 25 HYPERLINK \l "_Toc146093962" 9.1. Изисквания към документацията PAGEREF _Toc146093962 \h 25 HYPERLINK \l "_Toc146093963" 9.2. Прозрачност и отчетност PAGEREF _Toc146093963 \h 26 HYPERLINK \l "_Toc146093964" 9.3. Системен проект PAGEREF _Toc146093964 \h 26 HYPERLINK \l "_Toc146093965" 9.4. Техническа документация PAGEREF _Toc146093965 \h 26 HYPERLINK \l "_Toc146093966" 9.5. Протоколи PAGEREF _Toc146093966 \h 27 HYPERLINK \l "_Toc146093967" 9.6. Комуникация и доклади PAGEREF _Toc146093967 \h 27 HYPERLINK \l "_Toc146093968" 9.6.1. Встъпителен доклад PAGEREF _Toc146093968 \h 27 HYPERLINK \l "_Toc146093969" 9.6.2. Междинни доклади PAGEREF _Toc146093969 \h 27 HYPERLINK \l "_Toc146093970" 9.6.3. Окончателен доклад PAGEREF _Toc146093970 \h 28 HYPERLINK \l "_Toc146093971" 10. РЕЗУЛТАТИ PAGEREF _Toc146093971 \h 28 РЕЧНИК НА ТЕРМИНИ, ДЕФИНИЦИИ И СЪКРАЩЕНИЯ Използвани акроними Акроним Описание АИС Автоматизирана информационна система АМС Администрация на Министерския съвет АО Административен орган АОП Агенция по обществени поръчки АПК Административнопроцесуален кодекс БУЛСТАТ Регистър Булстат МЕУ Министерство на електронното управление ЗВЕРБ Закон за въвеждане на еврото в Република България ЗДОИ Закон за достъп до обществена информация ЗЕДЕП Закон за електронния документ и електронния подпис ЗЕУ Закон за електронното управление ЗКИ Закон за кредитните институции ИС Информационна система ИТ Информационни технологии КАО Комплексно административно обслужване ТР Търговски регистър ДХЧО Държавен хибриден частен облак ЦАИС Централизирана автоматизирана информационна система SDK Software development kit API Application programming interface/Приложно програмен интерфейс Технологични дефиниции Термин Описание Виртуална комуникационна инфраструктура Инфраструктура, която на база съществуваща физическа свързаност, предоставена от МЕУ, предоставя възможност за изграждане на отделни и защитени виртуални мрежи за всяка една от структурите в сектора, при гарантиране на сигурен и защитен обмен на информация в тях. Държавен хибриден частен облак Централизирана на ниво държава информационна инфраструктура (сървъри, средства за съхранение на информация, комуникационно оборудване, съпътстващо оборудване, разпределени в няколко локации, в помещения отговарящи на критериите за изграждане на защитени центрове за данни), която предоставя физически и виртуални ресурси за ползване и администриране от секторите и структурите, които имат достъп до тях, в зависимост от нуждите им, при гарантиране на високо ниво на сигурност, надеждност, изолация на отделните ползватели и невъзможност от намеса в работоспособността на информационните им системи или неоторизиран достъп до информационните им ресурси. Изолацията на ресурсите и мрежите на отделните секторни ползватели (е-Общини, е-Правосъдие, е-Здравеопазване, е-Полиция) се гарантира с подходящи мерки на логическо ниво (формиране на отделни клъстери, виртуални информационни центрове и мрежи) и на физическо ниво (клетки и шкафове с контрол на достъпа). Софтуер с отворен код Компютърна програма, която се разпространява при условия, които осигуряват безплатен достъп до програмния код и позволяват: Използването на програмата и производните на нея компютърни програми, без ограничения в целта; Промени в програмния код и адаптирането на компютърната програма за нуждите на нейните ползватели; Разпространението на производните компютърни програми при същите условия. Списък на стандартни лицензионни споразумения, които предоставят тези възможности, който може да бъде намерен в подзаконовата нормативна уредба към Закона за електронно управление или на: HYPERLINK "http://opensource.org/licenses" \hhttp://opensource.org/licenseHYPERLINK "http://opensource.org/licenses" \hs. Машинночетим формат Формат на данни, който е структуриран по начин, по който, без да се преобразува в друг формат позволява софтуерни приложения да идентифицират, разпознават и извличат специфични данни, включително отделни факти и тяхната вътрешна структура. Отворен формат Означава формат на данни, който не налага употребата на специфична платформа или специфичен софтуер за повторната употреба на съдържанието и е предоставен на обществеността без ограничения, които биха възпрепятствали повторното използване на информация. Метаданни Данни, описващи структурата на информацията, предмет на повторно използване. Официален отворен стандарт Стандарт, който е установен в писмена форма и описва спецификациите за изискванията как да се осигури софтуерна оперативна съвместимост. Система за контрол на версиите Технология, с която се създава специално място, наречено “хранилище”, където е възможно да се следят и описват промените по дадено съдържание (текст, програмен код, двоични файлове). Една система за контрол на версиите трябва да може: Да съхранява пълна история - кой, какво и кога е променил по съдържанието в хранилището, както и защо се прави промяната; Да позволява преглеждане разликите между всеки две съхранени версии в хранилището; Да позволява при необходимост съдържанието в хранилището да може да се върне към предишна съхранена версия; Да позволява наличието на множество копия на хранилището и синхронизация между тях. Цялата информация, налична в системата за контрол на версиите за главното копие на хранилището, прието за оригинален и централен източник на съдържанието, трябва да може да бъде достъпна публично, онлайн, в реално време. Първичен регистър Регистър, който се поддържа от първичен администратор на данни - административен орган, който по силата на закон събира или създава данни за субекти (граждани или организации) или за обекти (движими и недвижими) за първи път и изменя или заличава тези данни. Например Търговският регистър е първичен регистър за юридическите лица със стопанска цел, Имотният регистър е първичен регистър за недвижима собственост. Дефиниции за нива на електронизация на услугите Термин Описание Ниво 1 Информация - предоставяне на информация за административни услуги по електронен път, включително за начини и места за заявяване на услугите, срокове и такси. Ниво 2 Едностранна комуникация - информация съгласно дефиницията за Ниво 1 и осигурен публичен онлайн достъп до шаблони на електронни формуляри. Ниво 3 Двустранна комуникация - заявяване и получаване на услуги изцяло по електронен път, включително електронно подаване на данни и документи, електронна обработка на формуляри и електронна персонална идентификация на потребителите. Ниво 4 Извършване на сделки или транзакции по услуги от Ниво 3, включващи онлайн разплащане или доставка. ВЪВЕДЕНИЕ Цел на документа Целта на настоящия документ е да опише софтуерните изисквания към изпълнението на обществена поръчка с предмет: [опишете предмета на поръчката] за адаптирането на [наименование на информационната система] във връзка с присъединяването на Република България към Еврозоната. В настоящата техническа спецификация са описани и изискванията към проектната организация, документацията и отчетността. За възложителя – функции и структура Структурата на [Възложителя] е представена във Фигура 1: SHAPE \* MERGEFORMAT Фигура 1. Структура на [Възложителя] За проекта Нормативна рамка Проектът се осъществява в съответствие с изискванията, регламентирани със следните нормативни актове и стратегически документи: Закон за електронното управление (ЗЕУ); Наредба за общите изисквания към информационните системи, регистрите и електронните административни услуги; Закон за електронния документ и електронните удостоверителни услуги; Закон за киберсигурност; Наредба за минималните изисквания за мрежова и информационна сигурност. Актуализиран Национален план за въвеждане на еврото в Република България, приет с решение на МС № 797 от 13 ноември 2023 г. (Националния план) и Методически указания към административните органи относно адаптирането на информационните системи във връзка с въвеждането на еврото в Република България (Методическите указания), приложение към Националния план; Закон за въвеждане на еврото в Р. България (ЗВЕРБ) - проект; [Документ 1] [Документ …] ЦЕЛИ, ОБХВАТ И ОЧАКВАНИ РЕЗУЛТАТИ ОТ ИЗПЪЛНЕНИЕ