Общи изисквания за изготвяне и предоставяне на техническа и друга документация
Общи изисквания за изготвяне и предоставяне на техническа и друга документация
|
| -
|
Цялата документация и всички технически описания, ръководства за работа, администриране, поддръжка и софтуерна разработка, включително и на нейните съставни части, трябва да бъдат налични и на български език
|
|
| -
|
Всички документи трябва да бъдат предоставени на Възложителя в електронен формат (Microsoft Word / RTF / PDF / HTML или др.), позволяващ пълнотекстово търсене (търсене по ключови думи) и копиране на части от съдържанието от оригиналните документи във външни документи.
|
|
| -
|
Навсякъде, където в документацията има включени диаграми или графики, те трябва да бъдат вградени в документите в оригиналния си векторен формат
|
|
|
|
Обхват на документация за потребители
|
Обхват на документация за потребители
|
| -
|
Ръководство на потребителя за работа с потребителския интерфейс (UI) на съответната система, подсистема, модул или функционалност.
|
|
| -
|
В случаите, в които даден потребителски интерфейс (UI) е предназначен за различни типове потребители, които имат различни роли, трябва да бъдат изготвени отделни ръководства за потребители, адаптирани за всяка роля (например за АЕИ, ЦЕИ, ДЕАУ).
|
|
|
|
Обхват на документация за системни / приложни администратори
|
Обхват на документация за системни / приложни администратори
|
| -
|
Ръководство за системни администратори за конфигуриране и администрация на съответната система, подсистема, модул или компонент и за работа със служебния потребителски интерфейс (UI), където е приложимо.
|
|
| -
|
Инструкции и процедури за изпълнение на регулярни дейности по поддръжка и системна администрация
|
|
|
|
Обхват на документация за разработчици на софтуер
|
Обхват на документация за разработчици на софтуер
|
| -
|
Детайлна техническа документация за програмния интерфейс (API) на съответната система, подсистема или модул, включително за поддържаните уеб-услуги, команди, структури от данни, протоколи, методи за автентикация и др., където е приложимо.
|
|
| -
|
Детайлна техническа документация за схемата на базата данни на съответната система, подсистема или модул – структури за данни, индекси, дялове, съхранени процедури, конфигурации за репликация на данни и др., където е приложимо.
|
|
|
|
Обхват на документация за DevOps
|
Обхват на документация за DevOps
|
| -
|
Обща информация, инструкции и процедури за инсталиране, администриране, поддръжка и актуализация на приложни сървъри, върху които са инсталирани системи, подсистеми, модули, компоненти, услуги и др.
|
|
| -
|
Обща информация, инструкции и процедури за администриране, архивиране и възстановяване, и поддръжка на сървъри за управление на бази данни, които обслужват системи, подсистеми и модули.
|
|
| -
|
Обща информация, инструкции и процедури за инсталиране и разгръщане на нови версии на системи, подсистеми и модули.
|
|
|
|
Обхват на документация за техническата инфраструктура
|
Обхват на документация за техническата инфраструктура
|
| -
|
Обща информация, инструкции и екзекутивна документация за конфигурацията на мрежовата и комуникационната инфраструктура.
|
|
| -
|
Обща информация, инструкции и екзекутивна документация за конфигурацията на сървърната инфраструктура и системите за виртуализация, където е приложимо.
|
|
| -
|
Обща информация, инструкции и екзекутивна документация за конфигурацията на инфраструктурата за съхранение на данни и системите за виртуализация, където е приложимо.
|
|
| -
|
Обща информация, инструкции и екзекутивна документация за конфигурацията на инфраструктурата за архивиране на данни, където е приложимо.
|
|
| -
|
Обща информация, инструкции и екзекутивна документация за конфигурацията на инфраструктурата за публични ключове, където е приложимо.
|
|
|
|
Общи изисквания за реализация на потребителски интерфейси (UI)
|
Общи изисквания за реализация на потребителски интерфейси (UI)
|
| -
|
Потребителските интерфейси трябва да бъдат разработени с модерен дизайн, изглед и структура (Adaptive / Responsive Design), които да се адаптират и променят динамично (run-time), в зависимост от:
-
устройството, от което се достъпват от потребителите
-
от разделителната способност на клиентското устройство
|
|
| -
|
При реализацията на потребителските интерфейси не се допуска използването на нестандартни презентационни технологии, които не се поддържат от всички основни браузъри и операционни системи като Addobe Flash и Microsoft Silverlight, както и презентационни технологии, които изискват инсталиране на допълнителни модули или софтуер на клиентското устройство, за да визуализират и управляват елементи или целите потребителски интерфейси.
|
|
| -
|
Всеки модул предоставящ потребителски интерфейс (UI) трябва да предоставя функционалността си чрез клиентска интеграция със съответните програмни интерфейси (APIs) на системата, подсистемата и/или модула, за който е предназначен.
|
|
| -
|
При реализацията на потребителски интерфейси (UI) не се допуска смесване на приложна логика с презентационната част. Допустимо е да бъдат реализирани предварителни валидации от страна на клиента, за оптимизиране на заявките към сървъра.
|
|
| -
|
При реализацията на потребителски интерфейси (UI) трябва да се спазват следните изисквания за имплементиране на валидации на данни / документи и др.:
-
допустимо е да бъдат имплементирана функционалност за предварителна валидация от страна "клиент" (UI), за оптимизиране на заявките към сървъра, които задължително трябва да бъдат изпълнени и на сървъра, като финална валидация в края на всеки многостъпков процес (когато е приложимо).
-
определени валидации трябва да бъдат извършвани задължително преди преминаване към следваща стъпка от процес
-
трябва да бъдат реализирани и специфични валидации, свързани с гарантиране на информационната сигурност, съгласно техническите изисквания описани в т. Error: Reference source not found от ТС.
|
|
|
|
Общи изисквания за реализация на функционалности в потребителски интерфейси (UI)
|
Общи изисквания за реализация на функционалности в потребителски интерфейси (UI)
|
| -
|
Трябва да бъдат спазени изискванията за Responsive/Adaptive Design при най -малко следните елементи:
-
Grid;
-
Images;
-
Media queries.
|
|
| -
|
Потребителските интерфейси на разработваните в рамките на обществената поръчка подсистеми трябва да работят и да са тествани под всички съвременни браузери, като минимум всички версии, за които съответният производител предоставя стандартна или разширена поддръжка.
|
|
| -
|
Всички потребителски интерфейси и компоненти на НСЕИ трябва да бъдат разработени с пълна поддръжка на функционалност за интернационализация и многоезичност (Full Localization / Internationalization).
|
|
| -
|
Всички публични потребителски интерфейси (UI) за граждани трябва да бъдат разработени и да се предоставят с локализационни набори на български и английски език и да бъдат пуснати в експлоатация с поддръжка и за двата езика. Преводите от български на английски език трябва да бъдат извършени от професионални преводачи и редактори, при съобразяване със специфичната терминология, включително и терминологията възприета в официални и/или нормативни документи на ЕС.
|
|
| -
|
Всички полета в потребителските интерфейси, в които се въвеждат стойности, чрез избор от номенклатура / таксономия, трябва да поддържат функции In-Line Autocomplete / Auto-Suggest
|
|
| -
|
Потребителските интерфейси трябва да позволяват търсене/филтриране по всички реквизити (полета) на списъци / таблици, както чрез пълнотекстово търсене (Full Text Search), така и чрез филтриране по структурирани реквизити (Facet Filters)
|
|
| -
|
Системата трябва да съхранява перманентно всеки започнал процес / процедура по подаване на заявление или обявяване на обстоятелства, текущия му статус, всички въведени данни и прикачени документи, дори ако потребителят е прекъснал волно или неволно потребителската си сесия. При вход в системата потребителят трябва да получава прегледна и ясна нотификация, че има започнати, но недовършени / неизпратени / неподписани заявления и да бъде подканен да отвори модула за преглед на историята на транзакциите
|
|
| -
|
Контекстната помощна информация, указанията към потребителите и информативните текстове за всяка електронна административна услуга не трябва да съдържат акроними, имена и референции към нормативни документи, които са въведени като обикновен текст (plain-text). Всички акроними, референции към нормативни документи, формуляри, изисквания и пр. трябва да бъдат разработени като хипер-връзки към съответните актуални версии на нормативни документи и/или съответния речник / списък с акроними и термини. Достъпът на потребителя до контекстната помощна информация трябва да бъде реализиран по унифициран и консистентен начин, чрез подходящи навигационни елементи, като например чрез подходящо разположени микро-бутони с икони разположени до/преди/след етикета на съответния елемент, за който се отнася контекстната помощ или чрез обработка на "Mouse Hover / Mouse Over" събития;
|
|
| -
|
Трябва да бъде реализирана възможност за добавяне и редактиране от страна на администраторите на системата, без да са необходими промени в изходния код, на контекстна помощна информация за:
-
всяка електронна форма или стъпка от процес, за която има отделен екран / форма;
-
всяка група полета за въвеждане на данни (в случаите, в които определени полета от формата са групирани тематично);
-
всяко отделно поле за въвеждане на данни;
|
|
| -
|
В електронните форми трябва да бъде реализирана валидация на въвежданите от потребителите данни на ниво "поле" (in-line validation). Валидацията трябва да се извършва в реално време на сървъра, като при успешна валидация, данните от съответното поле следва да бъдат запазени от сървъра;
|
|
| -
|
За всеки удостоверителен процес (интеграция с външна АИС) следва да се реализира интерфейс за комуникация със съответната АИС. Всеки АИС може да поддържа и уеб-услуги. Проверката на автентикацията на заявителя трябва да бъде отговорност на системата, предоставяща уеб-услугата.
|
|
| -
|
Всички структурни данни за комуникация между АИС, първични регистри и координатор трябва да са представени на http://dev.egov.bg (след изграждането на системата), или на друго, посочено от Възложителя публично хранилище, както и на адреса на всеки АИС, в случай, че вече е изграден и наличен
|
|
| -
|
Форматът на датите и часовете следва да бъде ISO 8601 съгласно подзаконовата нормативна уредба на ЗЕУ
|
|
| -
|
Всяка операция трябва да бъде повторена при неуспех минимум 3 пъти, с т.нар. exponential backoff
|
|
| -
|
Ако и след повторението изпращането на отговор към callbackUrl не е успешно, трябва да се запише, като „изчакващо“ в системата и да бъде изпратено в следващ момент
|
|
| -
|
Рутерите, firewall-ите и други механизми следва да бъдат конфигурирани така, че да позволяват използването на нестандартни HTTP header-и (като Signature)
|
|
| -
|
Всички авторски и сродни права върху компютърните програми и техния изходен програмен код, чиято разработка е предмет на поръчката, възникват за Възложителя в пълен обем, без ограничения в използването, изменението и разпространението му, по смисъла на чл. 42 от ЗАПСП.
|
|
| -
|
Изходният код (Source Code) разработван по обществената поръчка, както и цялата техническа документация, трябва да бъдат публично достъпни онлайн като Софтуер с отворен код от първия ден на разработка, чрез използване на система за контрол на версиите. Цялата информация за главното копие на хранилището, прието за оригинален и централен източник на съдържанието, да бъде достъпна публично, онлайн, в реално време
|
|
| -
|
За всички публични интернет страници трябва да бъде реализирана функционалност за публикуване на всяко периодично обновявано съдържание в стандартен формат (RSS 2.х, Atom или еквивалент), както и поддържането на публично достъпни статистики за посещаемостта на страницата.
|
|
| -
|
Дизайнът на схемата на базите данни трябва да бъде с максимално ниво на нормализация, освен ако това не би навредило сериозно на производителността
|
|
| -
|
Базата данни трябва да може да оперира в клъстер. В определени случаи следва да бъде използван т.нар. Sharding;
|
|
| -
|
Трябва да бъдат създадени индекси по определени колони, така че да се оптимизират най-често използваните заявки. Създаването на индекс трябва да е мотивирано и подкрепено със замервания
|
|
| -
|
Връзките между таблици в СУБД трябва да са дефинирани чрез външни ключове (foreign keys);
|
|
| -
|
Периодично трябва да бъде правен анализ на заявките, вкл. чрез EXPLAIN (при SQL бази данни) и да бъдат предприети мерки за оптимизиране на бавните такива;
|
|
| -
|
Задължително трябва да се използват транзакции, като нивото на изолация трябва да бъде мотивирано в предадената документация;
|
|
| -
|
При операции върху много записи (batch) трябва да се избягват дългопродължаващи транзакции;
|
|
| -
|
При използване на нерелационна база данни, трябва да се използват по-бързи и компактни протоколи за комуникация, ако такива са достъпни
|
|