|
Общи изисквания за разработка на комплекти със софтуерни компоненти за интеграция (SDK)
|
Общи изисквания за разработка на комплекти със софтуерни компоненти за интеграция (SDK)
|
-
|
Всеки от комплектите със софтуерни компоненти (SDK) трябва да бъде с отворен код и да бъде разработен за следните основни популярни платформи за разработка на софтуер и информационни системи:
|
|
-
|
Всеки SDK пакет трябва да включва техническа документация и ръководство за разработчици на софтуер.
|
|
-
|
Всеки SDK пакет трябва да включва и тестово/примерно приложение, чрез което се демонстрират интеграционните функционалности.
|
|
-
|
Всеки SDK пакет, разработен за една от технологичните платформи, трябва да има идентично API и функционалност с аналогичните SDK пакети за другите поддържани платформи.
|
|
-
|
SDK пакетите трябва да се развиват кохерентно – например, при коригиране на функционалност за една технологична платформа, свързана с промени в програмния интерфейс (API) на Националната схема за електронна идентификация или при отстраняване на дефекти и грешки, промените трябва да се пренесат и в останалите версии, разработени за другите поддържани технологични платформи.
|
|
|
SDK за проверка на електронна идентичност и заявки за атомични въпроси
|
SDK за проверка на електронна идентичност и заявки за атомични въпроси
|
-
|
Трябва да бъде разработен софтуерен комплект за клиентска интеграция (Client-Side Integration SDK) със следните програмни интерфейси (APIs) на системи и подсистеми от националната схема за електронна идентификация:
-
Програмен интерфейс (API) на ИСЦЕИ
-
Програмен интерфейс (API) на РО
|
|
-
|
Трябва да бъде реализирана следната минимална функционалност и съответни методи за:
-
Сигурна автентикация и отваряне на сесия към съответните програмни интерфейси (API);
-
Регистриране на callBackURL (Call Back End Point)
-
Проверка на електронна идентичност;
-
Заявки с атомични въпроси за потвърждаване на обстоятелства, вписани в първични регистри;
-
Заявки за извличане на автентични и достоверни данни от първични регистри;
-
Заявки за проверка за представителна власт на граждани, законни представители на юридически лица;
-
Заявки за проверка за представителна власт на длъжностни лица, по силата на вписване в "Базов регистър на субекти, обекти и събития";
-
Заявки за проверка за представителна власт, по силата на електронно овластяване.
|
|
|
SDK за генериране на нотификации
|
SDK за генериране на нотификации
|
-
|
Трябва да бъде разработен софтуерен комплект за клиентска интеграция (Client-Side Integration SDK) със следните програмни интерфейси (APIs) на системи и подсистеми от националната схема за електронна идентификация:
-
Програмен интерфейс (API) на ПАН
|
|
-
|
Трябва да бъде реализирана следната минимална функционалност и съответни методи за:
-
Сигурна автентикация и отваряне на сесия към съответните програмни интерфейси (API);
-
Регистриране на callBackURL (Call Back End Point)
-
Генериране и насочване на нотификации към потребители (по различни допустими идентификатори)
-
Получаване на потвърждение за получена / неполучена нотификация
-
Получаване на потвърждение за прочетена нотификация
|
|
|
SDK за сигурно връчване
|
SDK за сигурно връчване
|
-
|
Трябва да бъде разработен софтуерен комплект за клиентска интеграция (Client-Side Integration SDK) със следните програмни интерфейси (APIs) на системи и подсистеми от националната схема за електронна идентификация:
-
Програмен интерфейс (API) на ПЕПП
|
|
-
|
Трябва да бъде реализирана следната минимална функционалност и съответни методи за:
-
Сигурна автентикация и отваряне на сесия към съответните програмни интерфейси (API);
-
Регистриране на callBackURL (Call Back End Point)
-
Изпращане на електронни документи за сигурно връчване (с общо предназначение)
-
Изпращане на електронни документи за сигурно връчване с покана за плащане (на такса / глоба / услуга), съдържащи референция към уникално-глобален номер на транзакция в ПУП
-
Получаване на потвърждение за успешно получен от адресата документ
-
Получаване на потвърждение за успешно връчен на адресата документ (отворен / прегледан)
|
|
|
SDK за обслужване на плащания
|
SDK за обслужване на плащания
|
-
|
Трябва да бъде разработен софтуерен комплект за клиентска интеграция (Client-Side Integration SDK) със следните програмни интерфейси (APIs) на системи и подсистеми от националната схема за електронна идентификация:
-
Програмен интерфейс (API) на ПУП
|
|
-
|
Трябва да бъде реализирана следната минимална функционалност и съответни методи за:
-
Сигурна автентикация и отваряне на сесия към съответните програмни интерфейси (API);
-
Регистриране на callBackURL (Call Back End Point)
-
Изпращане на разходооправдателни електронни документи (фактура / покана за плащане на такса / глоба / услуга)
-
Получаване на потвърждение за приета заявка и референция към уникално-глобален номер на транзакция в ПУП
-
Получаване на отговор с потвърждение за извършено плащане
-
Получаване на отговор за отказано плащане
-
Извличане на платежна история за период / потребител / доставчик на ЕАУ
|
|
|
Компонент за интеграция на eID с Active Directory и LDAP сървъри
|
Компонент за интеграция на eID с Active Directory и LDAP сървъри
|
-
|
Трябва да бъде разработен компонент за интеграция на еИД с Active Directory / LDAP сървъри.
|
|
-
|
Публичните и частни организации, които имат изградена оторизационна инфраструктура на базата на Active Directory / LDAP, трябва да могат да интегрират и използват разработеният компонент за проверка на електронната идентичност на служителите си за организиране контрола на достъп до вътрешните си информационни ресурси.
|
|
-
|
Разработеният компонент трябва да поддържа еИД като основен метод за оторизация, както и добавянето му като допълнителен фактор в решения за многофакторна оторизация (MFA).
|
|
|
Поддръжка за периода до приключване на дейностите по договора за възлагане на обществена поръчка
|
Поддръжка за периода до приключване на дейностите по договора за възлагане на обществена поръчка
|
-
|
Изпълнителят трябва да осигури изменения в изходния код и реализираните функционалности в SDK пакетите, при промени в спецификациите на съответните програмни интерфейси (APIs), вследствие на реализиране на нови версии на интерфейсите и/или изменения в нормативната уредба, настъпили преди края на договора за обществена поръчка.
|
|
|
Гаранционна поддръжка, отстраняване на дефекти и пропуски в сигурността
|
Гаранционна поддръжка, отстраняване на дефекти и пропуски в сигурността
|
-
|
Изпълнителят трябва да осигури гаранционна поддръжка на SDK пакетите за период от 36 (тридесет и шест) месеца.
|
|
-
|
Изпълнителят трябва да осигури отстраняване на грешки и пропуски в сигурността, допуснати в изходния код на ПГ, както и корекции за отстраняване на отклонения от изискванията на ТС.
|
|
|
Изисквания за реализиране на инсталатор и стандартно приложение за електронна идентификация
|
Изисквания за реализиране на инсталатор и стандартно приложение за електронна идентификация
|
-
|
За целта трябва да бъде разработено софтуерно приложение - унифициран инсталатор, според спецификата за следните операционни системи:
-
Microsoft Windows – .MSI / .EXE инсталатор, поддържащи 32 и 64 bit архитектури. Инсталаторът трябва да поддържа възможност за инсталация и актуализации без потребителска интервенция, чрез Push през групови политики;
-
Linux – изграждане и подписване на DEB (за Debian съвместими дистрибуции) и RPM (за RedHat съвместими дистрибуции) пакети, поддържащи 32 и 64 bit архитектури. Пакетите трябва да се публикуват в специфичните за съответната дистрибуционна система хранилища, заедно с пакети с изходния код (source packages). В допълнение трябва да бъде разработен и ръчен инсталатор, чрез който да се извършва инсталирането и конфигурирането на клиентския софтуер за еИД;
-
Apple MacOS – app инсталационен пакет.
|
|
-
|
Участникът може да предложи и допълнителни модели/пакетни системи за дистрибуция.
|
|
-
|
Инсталаторите трябва да инсталират всички необходими драйвери, удостоверителни вериги и добавки, както и да извършват необходимите конфигурации, необходими за функционирането на електронната идентификация в браузъри.
|
|
-
|
Инсталаторът трябва да инсталира и стандартно приложение (необходимо за работата на Error: Reference source not found), което да бъде използвано за подписване с електронен подпис (квалифициран или усъвършенстван).
|
|
-
|
В случаите, при които е извършена ръчна инсталация на инсталационния пакет (не е използвано външно DEB/RPM хранилище и не е извършена централизирана инсталация чрез групови политики), приложението трябва да проверява за наличие на обновена версия и да предлага на потребителя инсталацията й. За всяка версия е необходимо да има описани release notes, описващи направените промени, отстранените несъответствия и добавената функционалност. Процесът на обновяване трябва да гарантира целостта на новия пакет, както и да го валидира за валиден електронен подпис.
|
|
-
|
Приложението трябва да поддържа автоматично обновяване до последна версия. Последните версии трябва да са достъпни и на Портала за граждани, за ръчно сваляне.
|
|
|
Поддръжка за периода до приключване на дейностите по договора за възлагане на обществена поръчка
|
Поддръжка за периода до приключване на дейностите по договора за възлагане на обществена поръчка
|
-
|
Изпълнителят трябва да осигури изменения в изходния код и реализираните функционалности софтуерните приложения, при промени в спецификациите, вследствие на реализиране на нови версии на интерфейсите, стандартите, протоколите и/или изменения в нормативната уредба, настъпили преди края на договора за обществена поръчка.
|
|
|
Гаранционна поддръжка, отстраняване на дефекти и пропуски в сигурността
|
Гаранционна поддръжка, отстраняване на дефекти и пропуски в сигурността
|
-
|
Изпълнителят трябва да осигури гаранционна поддръжка на софтуерните приложения за период от 36 (тридесет и шест) месеца.
|
|
-
|
Изпълнителят трябва да осигури отстраняване на грешки и пропуски в сигурността, допуснати в изходния код на софтуерните приложения, както и корекции за отстраняване на отклонения от изискванията на ТС или несъвместимост с клиентската платформа (ОС), за която са предназначени софтуерните приложения.
|
|
|
Общи изисквания за реализиране на компоненти за електронно подписване
|
Общи изисквания за реализиране на компоненти за електронно подписване
|
-
|
Компонентът трябва да реализира един или няколко от следните подходи за електронно подписване:
-
Подписване извън браузъра. Изпълнителят следва да разработи протокол, по който уеб-страници да подават към инсталирано приложение документи за подписване. Това може да става по два начина:
-
Чрез свързване на приложението към определен протокол – напр. signature://documents-to-sign.meta, разширен с поддръжка на PKCS#7, XmlSig и PDF подписи. Компонента трябва да поддържа подписване на подаден съдържание и на локални файлове;
-
Чрез реализация на Signature creation service (SCS, https://developer.fineid.fi/scs/), разширен с поддръжка на PKCS#7, XmlSig и PDF подписи. Компонента трябва да поддържа подписване на подаден съдържание и на локални файлове.
-
Подписване в браузъра чрез JavaScript. Това може да стане чрез разработка на разширения за популярните браузъри (Microsoft Internet Explorer, Mozilla Firefox и Google Chrome. В този случай изпълнителят трябва да публикува разширенията в съответните онлайн хранилища (plugin stores)
|
|
-
|
Освен протокол, трябва да бъде разработена и примерна реализация с настолно приложение.
-
чрез предоставяне на стандартни компоненти (javascript-базирани), които доставчиците на услуги да използват наготово – чрез интеграция със софтуерните компоненти, описани в т. Error: Reference source not found;
-
чрез разработване на “подписване като услуга”, като документа, който следва да бъде подписан, се препраща на централизирана система, която изисква подпис от гражданина и връща отговора на оригиналния доставчик на услуги. Подписът на гражданина трябва да може да се реализира чрез стандартното приложение, описано в т. Error: Reference source not found или чрез интегриране на система за remote signatures (ако такава е налична по време на обществената поръчка). Интеграцията с централизираната система трябва да бъде реализирана с използването на уеб услуги. Централизираната система трябва да предоставя достъп до всички компоненти, които гражданинът е подписал, след валидна електронна идентификация. Разработката и поддръжката на централизираната система трябва да се извърши от Изпълнителя в рамките на обществената поръчка.
|
|
-
|
Минималните поддържани формати за създадените електронни подписи са: PKCS#7 (attached и detached)/CAdES, XML базирани електронни подписи/XAdES, и PDF базирани електронни подписи/PAdES).
|
|
-
|
При развитие на Web Cryptography API спецификацията за поддръжка на смарт карти, изпълнителят трябва да извърши необходимите промени за интеграция на поддръжката в рамките на изпълнението на договора за обществената поръчка.
|
|
|
Общи изисквания за реализиране на компоненти за проверка за валидност на УЕИ и други удостоверения
|
Общи изисквания за реализиране на компоненти за проверка за валидност на УЕИ и други удостоверения
|
-
|
Трябва да бъде реализиран комплект със софтуерни компоненти (SDK пакет), чрез който да се извършват базови провери за валидност УЕИ:
-
Валидна удостоверителна верига
-
Валидност на удостоверението във времето
-
Валиден KeyUsage
-
Онлайн проверка в CRL
-
Онлайн проверка по OCSP протокол
-
Верификация на подписаните данни.
|
|
-
|
Всеки от комплектите със софтуерни компоненти (SDK) трябва да бъде с отворен код и да бъде разработен за следните основни популярни платформи за разработка на софтуер и информационни системи:
|
|
-
|
Всеки SDK пакет трябва да включва техническа документация и ръководство за разработчици на софтуер.
|
|
-
|
Всеки SDK пакет трябва да включва и тестово/примерно приложение, чрез което се демонстрират интеграционните функционалности.
|
|
-
|
Всеки SDK пакет, разработен за една от технологичните платформи, трябва да има идентично API и функционалност с аналогичните SDK пакети за другите поддържани платформи.
|
|
-
|
SDK пакетите трябва да се развиват кохерентно – например, при коригиране на функционалност за една технологична платформа, свързана с промени в програмния интерфейс (API) на Националната схема за електронна идентификация или при отстраняване на дефекти и грешки, промените трябва да се пренесат и в останалите версии, разработени за другите поддържани технологични платформи.
|
|
-
|
Пакетите ще бъдат предоставяни безплатно на всички заинтересовани страни, за да се осигури възможност за бързо, лесно и евтино вграждане на функционалността в информационни системи на ДЕАУ или други частно-правни субекти.
|
|
|
Поддръжка за периода до приключване на дейностите по договора за възлагане на обществена поръчка
|
Поддръжка за периода до приключване на дейностите по договора за възлагане на обществена поръчка
|
-
|
Изпълнителят трябва да осигури изменения в изходния код и реализираните функционалности на SDK пакета, при промени в спецификациите, вследствие на реализиране на нови версии на интерфейсите, стандартите, протоколите и/или изменения в нормативната уредба, настъпили преди края на договора за обществена поръчка.
|
|
|
Гаранционна поддръжка, отстраняване на дефекти и пропуски в сигурността
|
Гаранционна поддръжка, отстраняване на дефекти и пропуски в сигурността
|
-
|
Изпълнителят трябва да осигури гаранционна поддръжка на SDK пакетите за период от 36 (тридесет и шест) месеца.
|
|
-
|
Изпълнителят трябва да осигури отстраняване на грешки и пропуски в сигурността, допуснати в изходния код на SDK пакетите, както и корекции за отстраняване на отклонения от изискванията на ТС.
|
|
|
Изисквания за реализиране на мобилно приложение за електронна идентификация
|
Изисквания за реализиране на мобилно приложение за електронна идентификация
|
-
|
Мобилното приложение трябва да подържа платформите Google Android и Apple iOS, като Изпълнителят трябва да осигури включването му в съответните Application Stores. Application Stores дават възможност за обратна връзка и поддръжка на приложенията. Изпълнителят трябва да подпомага експертите на Възложителя при отговори на запитвания, както и да отстранява подадените несъответствия. Изпълнителят трябва да извършва и необходимите корекции, наложени от промени в технологичните платформи и/или application stores.
|
|
-
|
Мобилното приложение трябва да участва в последователност от стъпки за извършена на електронна идентификация, инициирана от браузър, както на самото мобилно устройство, така и на друго устройство. При електронна идентификация, инициирана от друго устройство, лицето посочва номера на мобилното устройство, чрез което ще предостави УЕИ (съгласно чл. 20, ал. 2 от ППЗЕИ)
|
|
-
|
Достъпът до удостоверенията за електронна идентичност трябва да става по следните начини:
-
Чрез използване на NFC безконтактния интерфейс на устройството (ако такъв е наличен) и безконтактния интерфейс на носителя на еИД (ако такъв е наличен). В този случай е необходимо комуникацията между устройствата да бъде криптирана;
-
Чрез използване на съвместим външен контактен четец за смарткарти;
-
Използвайки персонализирано на телефона удостоверение чрез Trusted execution environment;
-
Опционално, чрез използване на MicroSD носител на еИД.
|
|
-
|
МПГ трябва да предоставя следната базова функционалност:
-
Получаване и преглед на нотификации от ПАН - като стандартен сигурен канал за нотифициране;
-
Преглед на удостоверенията за еИД и спиране на избрано удостоверение за електронна идентичност;
-
Потвърждаване на заявки за плащане от ПУП (плащане на такси / услуги / глоби / санкции - в случай, че потребителят е асоциирал средство за електронно разплащане в профила си в Портала за граждани);
-
Преглед на връчени документи от ПЕПП;
-
Овластявания (в ролята на овластител и овластен) – овластяване, оттегляне на овластяване, промяна на овластяване, деклариране на несъгласие за овластяване;
-
Преглед и търсене в история на транзакции за извършени плащания (през ПЖС);
-
Преглед и търсене в история на транзакции за използването на еИД (през ПЖС).
-
Преглед и търсене в история на транзакции за осъществен достъп до лични данни (през ПЖС).
-
Преглед и търсене в история на транзакции за овластявания (през ПЖС), в ролята на овластител и овластен.
|
|
-
|
МПГ трябва да предоставя следната функционалност, свързана с иницииране на действия, в следствие на получена специфична нотификация от ПАН, когато нотификацията съдържа покана за действие:
-
Преглед на детайли от журнал за достъп до лични данни (когато нотификацията за осъществен достъп до лични данни)
-
Преглед на детайли от журнал за еИД (когато нотификацията за осъществен а идентификация с УЕИ)
-
Преглед на връчен документ в ПЕПП (когато нотификацията е за документ, получен в сигурната пощенска кутия в ПЕПП)
-
Потвърждаване на плащане (когато нотификацията съдържа покана за плащане от ДЕАУ)
-
Потвърждаване на оттегляне на овластяване (когато нотификацията съдържа покана за потвърждаване на заявено оттегляне на овластяване)
-
Подписване на електронен документ или иницииране на локално и/или отдалечено подписване (ако има техническа възможност), на електронен документ (когато нотификацията съдържа покана за подписване на електронен документ/заявление)
|
|
|
Изисквания за реализация на функционалност за използване на мобилно устройство за мултифакторна автентикация
|
Изисквания за реализация на функционалност за използване на мобилно устройство за мултифакторна автентикация
|
-
|
Трябва да бъде разработена функционалност за използване на МПГ за мултифакторна автентикация. Трябва да бъде направен анализ на възможните подходи (HOTP, TOTP, получаване на съобщение по криптиран канал) и да бъде избран най-подходящият.
|
|
-
|
ИСЦЕИ трябва да поддържа двуфакторна автентикация, както по искане на Доставчика на услуга (възможност да се конфигурира от Доставчика), така и по желание на гражданина (възможност да се конфигурира в Портала за граждани).
|
|
|
Изисквания за реализация на функционалност за използване на мобилно устройство като четец за носител на УЕИ
|
Изисквания за реализация на функционалност за използване на мобилно устройство като четец за носител на УЕИ
|
-
|
При наличие на безконтактен интерфейс на картата за електронна идентификация, ИСЦЕИ трябва да поддържа възможност за идентификация чрез мобилно устройство, с поддръжка на NFC, чрез мобилното приложение за електронна идентификация.
|
|
-
|
Примерна последователност на стъпките:
-
Потребителят въвежда номера на мобилния си телефон на страница на ИСЦЕИ (която не изисква TLS Mutual authentication);
-
ЦЕИ изпраща SMS или Push съобщение с Challenge до посочения номер;
-
С помощта на разработеното мобилно приложение, потребителят потвърждава идентификацията, като след прочитане на картата и въвеждане на ПИН, подписва изпратения Challenge и го изпраща на ИСЦЕИ - response;
-
ЦЕИ проверява дали така симулираният challenge-response е успешен и препраща браузъра на потребителя към страницата на Доставчика на услугите.
|
|
-
|
Допуска се въвеждане на допълнителен код от браузъра в приложението за смартфон, ако това е необходимо за гарантиране на сигурността.
|
|
-
|
Освен безконтактен интерфейс, мобилното приложение трябва да поддържа и контактен четец за смарткарти, свързан към мобилното устройство.
|
|
-
|
Аналогичен процес следва да се предвиди и за случаите, в които мобилното устройство съхранява частния ключ (напр. чрез Trusted Execution Environment или чрез разпределен ключ между устройството и HSM).
|
|
-
|
Участникът може да предложи алтернативна последователност и/или технология, гарантираща нивото на сигурност на електронната идентификация.
|
|
|
Поддръжка за периода до приключване на дейностите по договора за възлагане на обществена поръчка
|
Поддръжка за периода до приключване на дейностите по договора за възлагане на обществена поръчка
|
-
|
Изпълнителят трябва да осигури изменения в изходния код и реализираните функционалности софтуерните приложения, при промени в спецификациите, вследствие на реализиране на нови версии на интерфейсите, стандартите, протоколите и/или изменения в нормативната уредба, настъпили преди края на договора за обществена поръчка.
|
|
|
Гаранционна поддръжка, отстраняване на дефекти и пропуски в сигурността
|
Гаранционна поддръжка, отстраняване на дефекти и пропуски в сигурността
|
-
|
Изпълнителят трябва да осигури гаранционна поддръжка на софтуерните приложения за период от 36 (тридесет и шест) месеца.
|
|
-
|
Изпълнителят трябва да осигури отстраняване на грешки и пропуски в сигурността, допуснати в изходния код на софтуерните приложения, както и корекции за отстраняване на отклонения от изискванията на ТС или несъвместимост с клиентската платформа (ОС), за която са предназначени софтуерните приложения.
|
|
|
Общи изисквания за реализация на Подсистема за обслужване на потребители и онлайн помощ (ПОПОП)
|
Общи изисквания за реализация на Подсистема за обслужване на потребители и онлайн помощ (ПОПОП)
|
-
|
Възможност за създаване/регистриране, проследяване и запазване на потребителски заявки (тикети) по следните комуникационни методи:
-
Уеб-базиран потребителски интерфейс
-
Електронна поща
-
Телефон
|
|
-
|
Трябва да бъде реализиран потребителски интерфейс (UI), интегриран с Портала за граждани (ПГ).
|
|
-
|
Възможност за предоставяне на функционалност за самообслужване (Self Service Help)
|
|
-
|
Създадените тикети да могат да бъдат категоризирани и приоритизирани според предварително зададени критерии
|
|
-
|
Всеки регистриран тикет да може да бъде назначаван на определен оператор/агент
|
|
-
|
Поддръжка на автоматични нотификации чрез изпащане на електронни съобщения до заявителя на съответният тикет или чрез интеграция с програмния интерфейс (API) на ПАН, ако заявителят се е идентифицирал по реда на ЗЕИ.
|
|
-
|
Поддръжка на различни типове таймери за проследяване и управление на гарантирани нива на обслужване (SLA).
|
|
-
|
Възможност за прилагане на файлове към различните регистрирани тикети
|
|
-
|
Да разполага с модул за управление на знанието и често задавани въпроси (Knowledge Base, FAQ)
|
|
-
|
Трябва да поддържа интеграция с LDAP
|
|
-
|
Поддръжка на потребителски роли и контролиран достъп до системата на база роля
|
|
-
|
Възможност за осигуряване на двуфакторна автентикация
|
|
-
|
Възможност за генериране на различни репорти и статистики за работата по управление и обслужване на потребителски заявки.
|
|
-
|
Неограничено лицензиране за външни потребители, които се възползват от помощното бюро. Допустимо е лицензирането да зависи от броя агенти и супервайзъри, като трябва да бъдат осигурени лицензи за минимум 10 броя агенти за едновременна работа.
|
|
-
|
Възможност за допълнителна доработка на системата чрез скриптове и достъп до софтуерният код
|
|
-
|
Време за реакция при подаване на сервизна заявка във връзка със системата: до 4 часа след подаване на сервизна заявка
|
|
-
|
Време за отстраняване на проблема със системата: до 24 часа от регистрирането на подадена сервизна заявка.
|
|
-
|
Възможност и права за получаване на нови версии на системата (updates and upgrades)
|
|
-
|
Системата трябва да дава възможност за конфигуриране на процеси, съответстващи на стандартни и утвърдени практики/рамки за управление на услуги (например ITIL v.3, ISO 20000 или еквивалентни)
|
|
|
Поддръжка за периода до приключване на дейностите по договора за възлагане на обществена поръчка
|
Поддръжка за периода до приключване на дейностите по договора за възлагане на обществена поръчка
|
-
|
Изпълнителят трябва да осигури наблюдение на работоспособността и натовареността на ПОПОП, и при необходимост оптимизации за по-добра производителност и надеждност.
|
|
-
|
Изпълнителят трябва да осигури изменения в изходния код и реализираните процеси в ПОПОП, вследствие на изменения в нормативната уредба, настъпили преди края на договора за обществена поръчка.
|
|
|
Гаранционна поддръжка, отстраняване на дефекти и пропуски в сигурността
|
Гаранционна поддръжка, отстраняване на дефекти и пропуски в сигурността
|
-
|
Изпълнителят трябва да осигури гаранционна поддръжка на ПОПОП за период от 36 (тридесет и шест) месеца.
|
|
-
|
Изпълнителят трябва да осигури гаранционна поддръжка за непрекъсната работоспособност на ПОПОП, без отклонения от изискванията на ТС.
|
|
-
|
Изпълнителят трябва да осигури отстраняване на грешки и пропуски в сигурността, допуснати в изходния код на ПОПОП, както и корекции за отстраняване на отклонения от изискванията на ТС.
|
|
