Предложение за изпълнение на поръчката


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



страница15/38
Дата17.06.2017
Размер4.56 Mb.
#23756
1   ...   11   12   13   14   15   16   17   18   ...   38

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

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



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

  • Визуализиране на извършените транзакции;

  • Успешни / неуспешни идентификации към ДЕАУ;

  • Осъществен достъп до лични данни от ДЕАУ / служители на ДЕАУ;

  • Действия, извършени в Портала за граждани – използвани тематични ЕАУ;

  • Други специфични събития, действия и операции, регистрирани в ПЖС.






Информацията трябва да се презентира чрез използване на технически методи и средства за минимизиране на обема данни (напр. lazy loading) и възможност за прилагане на филтри:

  • Имплементиране на фасетни филтри на база реквизитите от журналите и таксономиите;

  • Филтриране по вид на събитието;

  • Филтриране по времеви интервал;

  • Филтриране по организация/ЕАУ;

  • Филтриране на база пълнотекстово търсене в историята на транзакциите.






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







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

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



Гражданите трябва да имат възможност за преглед на информацията, съхранявана за тях в първичните регистри. Извличането на тази информация ще става чрез изградените по т. Error: Reference source not found интерфейси.






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







Изисквания за реализиране на служебен потребителски интерфейс (UI) за приложна администрация на ПГ

Изисквания за реализиране на служебен потребителски интерфейс (UI) за приложна администрация на ПГ



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






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






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






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







Изисквания за реализиране на програмен интерфейс (API) на ПГ

Изисквания за реализиране на програмен интерфейс (API) на ПГ



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






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






Програмният интерфейс (API) трябва да отговаря и на общите технически и функционални изисквания за реализиране на програмни интерфейси (APIs), съгласно т. Error: Reference source not found от ТС.







Изисквания за изготвяне на документация за ПГ

Изисквания за изготвяне на документация за ПГ



Трябва да бъде изготвена техническа документация, отговаряща на релевантните изисквания, и с обхват, в съответствие с т. Error: Reference source not found от ТС







Поддръжка за периода до приключване на дейностите по договора за възлагане на обществена поръчка

Поддръжка за периода до приключване на дейностите по договора за възлагане на обществена поръчка



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






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







Гаранционна поддръжка, отстраняване на дефекти и пропуски в сигурността

Гаранционна поддръжка, отстраняване на дефекти и пропуски в сигурността



Изпълнителят трябва да осигури гаранционна поддръжка на ПГ за период от 36 (тридесет и шест) месеца.






Изпълнителят трябва да осигури гаранционна поддръжка за непрекъсната работоспособност на ПГ, без отклонения от изискванията на ТС.






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







Общи изисквания за реализиране на Подсистема за отворени данни (ПОД)

Общи изисквания за реализиране на Подсистема за отворени данни (ПОД)



Трябва да бъде реализирана Подсистема за отворени данни (ПОД), която:

  • Да централизира конфигурациите на програмните интерфейси за отворени данни на отделните системи, подсистеми, модули и др. на националната схема за електронна идентификация, които се публикуват на портала за отворени данни (http://opendata.government.bg) като URL/URI към програмни интерфейси

  • Да осигури прокси-услуги за достъп до интерфейсите за отворени данни, така че публичният достъп до програмния интерфейс на ПОД да не изисква автентикация със сертификати, за да се осигури максимална достъпност за гражданите и бизнеса до отворени данни (Open Data) за повторна употреба, по смисъла на ЗДОИ;

  • Да съхранява / буферира набори от данни, които са подготвени във файлови формати (CSV / XML / JSON)






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

  • Реализация на интерфейс за автоматично регистриране на набори от отворени данни в Портала за отворени данни на Република България - https://opendata.government.bg. Порталът е базиран на отворената системата CKAN - http://ckan.org/ и притежава интеграционен API интерфейс, чрез който организациите могат да публикуват отворените данни и/или да регистрират набор от данни, които предоставят от собствени сървъри.

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






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

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









Минимални изисквания за публикуване

на набори от данни

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




Минималният обхват на информацията, която трябва да бъде публикувана е следния:

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

  • Списъци с ДЕАУ, които са интегрирани към НСЕИ и поддържат идентификация с УЕИ, с информация за работно време и URL-и към уеб-сайтове, данни за контакт (адрес / телефон)

  • Списъци с ЕАУ, които са достъпни с електронна идентификация с УЕИ, с информация дали изискват и електронно подписване, и информация за работно време и URL-и към уеб-сайтове, данни за контакт (адрес / телефон)

  • Статистика за броя на електронните идентификатори – по периоди, по населени места;

  • Статистика за броя на издадените, спрените и прекратените УЕИ – по периоди;

  • Статистики за извършени идентификации - общо за период, по доставчици на ЕАУ и по услуги;

  • Статистики за заявки и отговори за удостоверяване на обстоятелства и предоставяне на данни – по периоди и първични регистри;

  • Статистики за извършени овластявания – по периоди и по услуги;

  • Статистики за предоставени ЕАУ с електронна идентификация (по периоди, доставчици и услуги)

  • Статистики за сигурните връчвания – по периоди и по услуги;

  • Статистки по администратори на електронна идентификация и центрове за електронна идентификация;






Участникът може да предложи и допълнителни набори за отворени данни







Изисквания за реализиране на служебен потребителски интерфейс (UI) за приложна администрация на ПEПП

Изисквания за реализиране на служебен потребителски интерфейс (UI) за приложна администрация на ПEПП



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






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






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






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






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







Изисквания за изготвяне на документация за ПОД

Изисквания за изготвяне на документация за ПОД



Трябва да бъде изготвена техническа документация, отговаряща на релевантните изисквания, и с обхват, в съответствие с т. Error: Reference source not found от ТС







Поддръжка за периода до приключване на дейностите по договора за възлагане на обществена поръчка

Поддръжка за периода до приключване на дейностите по договора за възлагане на обществена поръчка



Изпълнителят трябва да осигури наблюдение на работоспособността и натовареността на ПОД, и при необходимост оптимизации за по-добра производителност и надеждност.






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







Гаранционна поддръжка, отстраняване на дефекти и пропуски в сигурността

Гаранционна поддръжка, отстраняване на дефекти и пропуски в сигурността



Изпълнителят трябва да осигури гаранционна поддръжка на ПОД за период от 36 (тридесет и шест) месеца.






Изпълнителят трябва да осигури гаранционна поддръжка за непрекъсната работоспособност на ПОД, без отклонения от изискванията на ТС.






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




Каталог: rdonlyres
rdonlyres -> Областна дирекция на мвр – р а з г р а д районно управление на мвр – р а з г р а д
rdonlyres -> Република българия министерство на вътрешните работи а н а л и з
rdonlyres -> Стара Загора Дата Време
rdonlyres -> „развитие на човешките ресурси” Ч
rdonlyres -> Дипломна работа за получаване на образователно-квалификационна степен „Магистър" по специалността „Стратегическо ръководство и управление на сигурността и обществения ред"
rdonlyres -> Наредба за условията и реда за функциониране на националната система за ранно предупреждение и оповестяване на органите на изпълнителната власт и населението при бедствия и за оповестяване при въздушна опасност
rdonlyres -> Решение за откриване на процедура за възлагане на обществена поръчка
rdonlyres -> Закон за движението по пътищата в сила от 01. 09. 1999 г. Отразена деноминацията от 05. 07. 1999 г
rdonlyres -> Наредба №8121з-968 от 10 декември 2014 Г. За правилата и нормите за пожарна безопасност при извършване на дейности в земеделските земи


Сподели с приятели:
1   ...   11   12   13   14   15   16   17   18   ...   38




©obuch.info 2024
отнасят до администрацията

    Начална страница