|
№ по ред
|
ИЗИСКВАНЕ ПО ТЕХНИЧЕСКА СПЕЦИФИКАЦИЯ
|
ПРЕДЛОЖЕНИЕ ЗА ИЗПЪЛНЕНИЕ НА ПОРЪЧКАТА
|
|
|
Изисквания за преизползване на ресурси и готови разработки
|
Изисквания за преизползване на ресурси и готови разработки
|
| -
|
При реализацията на обществената поръчка следва максимално да се преизползват налични публично-достъпни инструменти, библиотеки и платформи с отворен код.
|
|
| -
|
За реализацията на регистрите и приложните подсистеми следва да се използват в максимална степен софтуерни библиотеки и продукти с отворен код.
|
|
|
|
Изисквания за прилагане на критерии за подбор, при избора на ресурси и готови разработки, подходящи за преизползване при реализирането на националната схема за електронна идентификация
|
Изисквания за прилагане на критерии за подбор, при избора на ресурси и готови разработки, подходящи за преизползване при реализирането на националната схема за електронна идентификация
|
| -
|
За реализацията на дадена техническа функционалност обикновено съществуват множество алтернативни проекти с отворен код, които могат да се използват за реализацията на системите, подсистемите, модулите и компонентите на националната схема за електронна идентификация.
Участникът да представи базов списък със компонентите и средства с отворен код, които възнамерява да използва за реализиране на дейностите по договора за възлагане на обществена поръчка.
|
|
| -
|
При подбор на проекти с отворен код, подходящи за преизползване и вграждане, трябва да бъдат следвани следните критерии:
-
За разработката им се използва система за управление на версиите на кода и е наличен механизъм за съобщаване на несъответствия (Issues) и приемане на допълнения (Pull Requests);
-
Да имат разработена техническа документация за актуалната стабилна версия;
-
Имат повече от един активен програмист, работещ по развитието им;
-
Имат възможност за предоставяне на комерсиална поддръжка;
-
Нямат намаляваща от година на година активност;
-
По възможност проектите да са подкрепени от организации с идеална цел, държавни или комерсиални организации;
По възможност проектите да имат разработени Unit Tests с над 50% покритие на изходния код, а проектът използва Continuous Integration (CI) подходи – Build Bots, Unit Tests Run, регулярно използване на статични/динамични анализатори на кода и др.
|
|
| -
|
Критериите за софтуер с отворен код са определени в Закона за електронното управление. При подбора на проекти с отворен код, допустими за преизползване и вграждане, трябва да се прави проверка, дали са публикувани от съответните носители на авторски права, с някой от следните лицензи, отговарящи на критериите за софтуер с отворен код по ЗЕУ:
-
EUPL - European Union Public License (Публичен лиценз на Европейския съюз)
-
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
|
|
| -
|
Препоръчително е преизползването на проекти, финансирани със средства на Европейския съюз, както и такива, в които Участникът има включени активни разработчици. Използването на closed source и такива с платен лиценз инструменти, библиотеки, продукти и системи е допустимо само в случаите, в които липсва подходяща алтернатива с отворен код, предлагаща необходимата функционалност, или тя не отговаря на горните условия. В такива случаи уреждането на правата и таксите за ползване са отговорност и за сметка на Изпълнителя.
|
|
| -
|
Изпълнителят трябва да осигури поддръжка от комерсиална организация, развиваща основните отворени продукти, които ще бъдат използвани като минимум за операционните системи, софтуерните продукти за управление на базите данни и софтуерните продукти за управление на PKI инфраструктурата.
|
|
|
|
Изисквания към подхода за работа с външните софтуерни ресурси
|
Изисквания към подхода за работа с външните софтуерни ресурси
|
| -
|
За При използването на свободни имплементации на софтуерни библиотеки е необходимо да се организира копие (fork) на съответното хранилище в общото хранилище за проекти с отворен код, финансирани с публични средства в България (към момента https://github.com/governmentbg). Използващите свободните библиотеки компоненти задават за upstream repo хранилищата в областта governmentbg, като задължително се реферира използваната версия/commit identificator.
|
|
| -
|
Когато се налага промяна в изходния код на използван софтуерен компонент, промените се извършват във fork хранилището на governmentbg в съответствие с изискванията на основния проект. Изпълнителят трябва да извърши необходимите действия за включване на направените промени в основния проект чрез pull requests и извършване на необходимите изисквани от разработчиците на основния проект промени до приемането им. Тези дейности ще бъдат извършвани по време на целия проект.
|
|
| -
|
При установяване на наличие на нови версии на използваните проекти се извършва анализ на влиянието върху настоящата система. В случаите, при които се оптимизира използвана функционалност, отстраняват се пропуски в сигурността, стабилността или бързодействието, новата версия се извлича и използва след успешното изпълнение на интеграционните тестове.
|
|
|
|
Общи изисквания за реализиране на множество среди
|
Общи изисквания за реализиране на множество среди
|
| -
|
Изпълнителят трябва да изгради и поддържа минимум следните логически разделени среди:
-
Среда за експерименти / външни интеграционни тестове (Sandbox)
-
Среда за разработка (Development)
-
Среда за тестове (Test)
-
Среда за разгръщане (Staging)
-
Среда за продукционна експлоатация (Production)
|
|
| -
|
Управлението на средите трябва да става чрез автоматизирана система за провизиране и разгръщане на системните компоненти. При необходимост от страна на Възложителя, Изпълнителят трябва да съдейства за изграждането на нови системни среди.
|
|
| -
|
Участникът може да предложи изграждането на допълнителни среди според спецификите на предложеното решение.
|
|
|
|
Изисквания за реализиране на среда за експерименти / външни интеграционни тестове (Sandbox)
|
Изисквания за реализиране на среда за експерименти / външни интеграционни тестове (Sandbox)
|
| -
|
Sandbox средата трябва да осигурява единствено и само провеждане на тестове и експерименти за интеграция към програмни интерфейси (API), предоставяни от националната схема за електронна идентификация.
|
|
| -
|
Sandbox средата трябва да бъде публично достъпна за всички лица, които имат интерес или са нормативно задължени, да интегрират свои системи към един или повече програмни интерфейси (API), предоставяни от националната схема за електронна идентификация.
|
|
| -
|
Заинтересованите лица трябва да могат да тестват интеграцията на системите си, без да застрашават или смущават работата на останалите среди и без да има нужда да получават достъп до вътрешните среди за тестове.
|
|
| -
|
Sandbox средата трябва да бъде реализирана на два етапа:
-
Етап 1 – предоставяне на примерни ("mock-up") уеб-услуги, базирани на статични конфигурации и изцяло примерни структури от данни само за приложните интерфейси (APIs) на ИСЦЕИ, съгласно функционалните и технически изисквания, описани в т. Error: Reference source not found от ТС;
-
Етап 2 – предоставяне на реални уеб-услуги, базирани на копия на продуктивните системи, реална инфраструктура за публични ключове и примерни данни, за несъществуващи лица / субекти и поддръжка на всички програмни интерфейси (APIs), предлагани от системите, подсистемите, модулите и компонентите на националната схема за електронна идентификация.
|
|
| -
|
Оразмеряването на отделните системни компоненти в тази среда е на нивото на минималните изисквания на инсталираните софтуерни компоненти.
-
За реализацията на Етап 1 на тази среда трябва да се предвиди използването на минимален набор от виртуални сървъри, като е допустимо ролите и услугите да бъдат максимално съвместени.
-
За реализацията на Етап 2 на тази среда трябва да се предвиди използването на общ HSM с ниска производителност.
|
|
|
|
Изисквания за реализиране на среда за разработка (Development)
|
Изисквания за реализиране на среда за разработка (Development)
|
| -
|
Development средата трябва да осигурява работата по разработката, усъвършенстването и развитието на софтуерните компоненти на националната схема за електронна идентификация. В тази среда трябва да са налични и допълнителните софтуерни системи и инсталации, необходими за управление на разработката – continuous integration средства, системи за автоматизирано тестване и др.
|
|
| -
|
Оразмеряването на отделните системни компоненти в тази среда е на нивото на минималните изисквания на инсталираните софтуерни компоненти. В тази среда се предвижда използването на общ HSM с ниска производителност.
|
|
|
|
Изисквания за реализиране на среда за тестове (Test)
|
Изисквания за реализиране на среда за тестове (Test)
|
| -
|
Test средата трябва да осигурява провеждането на вътрешни тестове и обучения на потребители и администратори, без да се възпрепятстват процесите по разработка, пред-продукционни тестове и разгръщане на нови версии на софтуерни компоненти.
|
|
| -
|
Оразмеряването на отделните системни компоненти в тази среда е на нивото на минималните изисквания на инсталираните софтуерни компоненти. В тази среда се предвижда използването на общ HSM с ниска производителност.
|
|
|
|
Изисквания за реализиране на среда за разгръщане (Staging)
|
Изисквания за реализиране на среда
за разгръщане (Staging)
|
| -
|
Staging средата трябва да осигурява провеждането на пред-продукционни тестове, преди разгръщане на нова версия от Development средата върху Production средата. В нея трябва да се извършват всички интеграционни тестове, както и тестовете за натоварване.
|
|
| -
|
Оразмеряването на отделните системни компоненти в тази среда е на нивото на усреднените изисквания на инсталираните софтуерни компоненти. В тази среда се предвижда използването на общ HSM с висока производителност
|
|
|
|
Изисквания за реализиране на среда за продукционна експлоатация (Production)
|
Изисквания за реализиране на среда за продукционна експлоатация (Production)
|
| -
|
Production средата трябва да осигурява реалната експлоатация на националната схема за електронна идентификация и всички интеграции със съответните външни системи и услуги. Чрез нея трябва да се предоставят всички публични и вътрешни услуги, при гарантиране на максимална производителност, непрекъсваемост и информационна сигурност.
|
|
| -
|
Оразмеряването на отделните системни компоненти в тази среда е на нивото на препоръчаните от Изпълнителя оптимални изисквания на инсталираните софтуерни компоненти. В тази среда се предвижда използването на отделни HSM за всяка специфична функционалност, изискваща сигурно съхранение на криптографския материал.
|
|
|
|
Изисквания към организацията и изпълнението на процесите по разработка, тестване и разгръщане на приложен софтуер
|
Изисквания към организацията и изпълнението на процесите по разработка, тестване и разгръщане на приложен софтуер
|
| -
|
Процесите, свързани с развитието на Националната схема за електронна идентификация трябва да гарантират висока прозрачност и възможност за обществен контрол над всички разработки по обществената поръчка. Изграждането на доверие у гражданите и бизнеса налага радикално по-висока публичност и прозрачност, чрез отворена разработка и публикуването на системите компоненти под отворен лиценз от самото начало на разработката. По този начин гражданите биха могли да съдействат в процесите по развитие и тестване на разработките през целия им жизнен цикъл.
|
|
| -
|
Всички софтуерни приложения, системи, подсистеми, библиотеки и компоненти, които са необходими за реализацията на националната схема за електронна идентификация, трябва да бъдат разработвани като софтуер с отворен код и да бъдат достъпни в публично хранилище. Следва да се използва общото хранилище за проекти с отворен код, финансирани с публични средства в България (към момента https://github.com/governmentbg).
|
|
| -
|
В случай, че върху част от компонентите, нужни за компилация, има авторски права, те могат да бъдат или в отделно хранилище с подходящия за това лиценз, или за тях трябва да бъде предоставен заместващ „mock up“ компонент, така че да не се нарушава компилацията.
|
|
| -
|
Трябва да се анализират възможностите за включване на активни граждани в процесите по разработка, тестване и идентифициране на пропуски на софтуера, включително чрез средствата, достъпни в публичното хранилище за изходен код. Изпълнителят трябва да разработи процеси и процедури за реализирането на такива дейности.
|
|
| -
|
Трябва да се реализират технологични и архитектурни решения, които осигуряват на недискриминационно инсталиране, опериране и поддръжка, както и работоспособност и отказоустойчивост на информационните системи в продуктивен режим във виртуална среда, без налагане на различни изисквания от тези за физическа среда.
|
|
|
|
Изисквания за гарантиране на качеството на извършваните софтуерни разработки и на крайния продукт
|
Изисквания за гарантиране на качеството на извършваните софтуерни разработки и на крайния продукт
|
| -
|
Компонентите в изходния код трябва да бъдат документирани на ниво клас и на ниво процедура/функция.
|
|
| -
|
Трябва да бъде постигнато покритие на минимум 50% от изходния код с функционални / процедурни тестове (Functional / Unit Tests).
|
|
| -
|
Трябва да бъдат използвани подходящи инструменти за разработчици и да бъдат прилагани практики за непрекъсната интеграция (Continuous Integration).
|
|
| -
|
Трябва да бъдат използвани подходящи инструменти за разработчици за управление на зависимостите (Dependency Management).
|
|
| -
|
Във всеки един компонент, който се build-ва и подготвя за инсталация (deployment) е необходимо да присъстват следните реквизити:
-
Дата и час на build;
-
Място/среда на build;
-
Потребител извършил/стартирал build процеса;
-
Идентификатор на ревизията от кодовото хранилище на компонента, срещу която се извършва build-а.
|
|
