Съдържание table of Contents
Подход за избор на отворени имплементации и продукти
Изтегляне 0.74 Mb.
|
- Навигация на страницата:
- Подход за работа с външните софтуерни ресурси
- Изграждане и поддръжка на множество среди
- Процес на разработка, тестване и разгръщане
- Бързодействие и мащабируемост
- Кохерентно кеширане на данни и заявки
Подход за избор на отворени имплементации и продуктиЗа реализацията на дадена техническа функционалност обикновено съществуват множество отворени алтернативни проекти, които могат да се използват в настоящия сайт. Участникът следва да представи базов списък със свободните компоненти и средства, които възнамерява да използва. Отворените проекти трябва да отговарят на следните критерии: За разработката им да се използва система за управление на версиите на кода и да е наличен механизъм за съобщаване на несъответствия и приемане на допълнения; Да имат разработена техническа документация за актуалната стабилна версия; Да имат повече от един активен програмист, работещ по развитието им; Да имат възможност за предоставяне на комерсиална поддръжка; Да нямат намаляваща от година на година активност; По възможност проектите да са подкрепени от организации с идеална цел, държавни или комерсиални организации; По възможност проектите да имат разработени unit tests с code coverage над 50%, а проектът да използва Continuous Integration (CI) подходи – build bots, unit tests run, регулярно използване на статични/динамични анализатори на кода и др. Препоръчително е преизползването на проекти, финансирани със средства на Европейския съюз, както и на такива, в които Участникът има активни разработчици. Използването на closed source и на инструменти, библиотеки, продукти и системи с платен лиценз става за сметка на изпълнителя, като е допустимо в случаите, когато липсва подходяща свободна алтернатива с необходимата функционалност или тя не отговаря на горните условия. Изпълнителят трябва да осигури поддръжка от комерсиална организация, развиваща основните отворени продукти, които ще бъдат използвани като минимум за операционните системи и софтуерните продукти за управление на базите данни. Подход за работа с външните софтуерни ресурсиПри използването на свободни имплементации на софтуерни библиотеки е необходимо да се организира копие (fork) на съответното хранилище в общото хранилище за проекти с отворен код, финансирани с публични средства в България (към момента https://github.com/governmentbg). Използващите свободните библиотеки компоненти задават за "upstream repo" хранилищата в областта governmentbg, като задължително се реферира използваната версия/commit identificator. Когато се налага промяна в изходния код на използван софтуерен компонент, промените трябва да се извършват във fork хранилището на governmentbg в съответствие с изискванията на основния проект. Изпълнителят трябва да извърши необходимите действия за включване на направените промени в основния проект чрез "pull requests" и извършване на необходимите изисквани от разработчиците на основния проект промени до приемането им. Тези дейности трябва да бъдат извършвани по време на целия проект. При установяване на наличие на нови версии на използваните проекти се извършва анализ на влиянието върху настоящата система. В случаите, при които се оптимизира използвана функционалност, отстраняват се пропуски в сигурността, стабилността или бързодействието, новата версия се извлича и използва след успешното изпълнение на интеграционните тестове. Изграждане и поддръжка на множество средиИзпълнителят трябва да изгради и да поддържа минимум следните логически разделени среди:
Управлението на средите трябва да става чрез автоматизирана система за провизиране и разгръщане на системните компоненти. При необходимост от страна на Възложителя Изпълнителят трябва да съдейства за изграждането на нови системни среди. Участникът може да предложи изграждането на допълнителни среди според спецификите на предложеното решение. Процес на разработка, тестване и разгръщанеПроцесите, свързани с развитието на Системата, трябва да гарантират висока прозрачност и възможност за обществен контрол над всички разработки по проекта. Изграждането на доверие в гражданите и в бизнеса налага радикално по-висока публичност и прозрачност чрез отворена разработка и публикуването на системите компоненти под отворен лиценз от самото начало на разработката. По този начин гражданите биха могли да съдействат в процесите по развитие и тестване на разработките през целия им жизнен цикъл. Всички софтуерни приложения, системи, подсистеми, библиотеки и компоненти, които са необходими за реализацията на сайта, трябва да бъдат разработвани като софтуер с отворен код и да бъдат достъпни в публично хранилище. След края на Председателството може да се използва общото хранилище за проекти с отворен код, финансирани с публични средства в България (към момента https://github.com/governmentbg). В случай че върху част от компонентите, нужни за компилация, има авторски права, те могат да бъдат или в отделно хранилище с подходящия за това лиценз или за тях трябва да бъде предоставен заместващ „mock up“ компонент, така че да не се нарушава компилацията на проекта. Трябва да се анализират възможностите за включване на граждани в процесите по разработка, тестване и идентифициране на пропуски на софтуера. Участникът трябва да предложи механизъм и процедури за реализирането на такива процеси. За всеки един разработван компонент Изпълнителят трябва да покрие следните изисквания за гарантиране на качеството на извършваната разработка и на крайния продукт: Документиране на сайта в изходния код, минимум на ниво процедура/функция/клас; Покритие на минимум 50% от изходния код с функционални тестове; Използване на continuous integration практики; Използване на dependency management. Участникът трябва да опише детайлно подхода си за покриване на изискванията. Във всеки един компонент на сайта, който се build-ва и подготвя за ползване, е необходимо да присъстват следните реквизити: Дата и час на build; Място/среда на build; Потребител извършил/стартирал build процеса; Идентификатор на ревизията от кодовото хранилище на компонента, срещу която се извършва build-ът. Бързодействие и мащабируемостКонтрол на натоварването и защита от DoS/DDoS атакиСайтът трябва да поддържа на приложно ниво "Rate Limiting" и/или "Throttling" на заявки от един и същ клиентски адрес както към страниците с уеб-съдържание, така и по отношение на заявките към приложните програмни интерфейси, достъпни публично или служебно като уеб-услуги (Web Services) и служебни интерфейси. Сайтът трябва да позволява конфигуриране от страна на администраторите на лимитите за отделни страници, уеб-услуги и ресурси, които се достъпват с отделен URL/URI. Сайтът трябва да поддържа възможност за конфигуриране на различни лимити за конкретни автентикирани потребители (напр. на други администрации) и трябва да предоставя възможност за генериране на справки и статистики за броя заявки по ресурси и услуги. Кохерентно кеширане на данни и заявкиОтделните информационни системи, подсистеми и интерфейси трябва да бъдат проектирани и да използват системи за разпределен кохерентен кеш в случаите, в които това би довело до подобряване на производителността и мащабируемостта, чрез спестяване на заявки към СУБД или файловите системи на сървърите. Изпълнителят трябва да опише детайлно подхода и използваните механизми и технологии за реализация на разпределения кохерентен кеш, както и системните компоненти, които ще използват разпределения кеш; Разпределеният кохерентен кеш трябва да поддържа възможност за компресия на подходящите за това данни – например тези от текстов тип; компресирането на данни може да бъде реализирано и на приложно ниво; Използваният алгоритъм за създаване на ключове за съхранение/намиране на данни в кеша не трябва да допуска колизии и трябва оптимално да използва процесорните ресурси за генериране на хешове; Изпълнителят трябва да подбере подходящи софтуерни решения с отворен код за реализиране на буфериране и кеширане на данните в оперативната памет на сървърите. В зависимост от конкретните приложни случаи (Use Cases) е допустимо да се използват и внедрят различни технологии, които покриват по-добре конкретните нужди – например решения като Memcached или Redis в комбинация с Redis GeoAPI могат да осигурят порядъци по-висока мащабируемост и производителност за често достъпвани оперативни данни, номенклатурни данни или документи; Като минимум разпределен кохерентен кеш трябва да се предвиди при: Извличане на информация от номенклатури и атомични данни за статус и актуално състояние на партиди от регистри в информационните системи; Извличане на информация от предефинирани периодични справки; Информация от лога на транзакциите при достъп с електронно-ИД до дадена услуга; Информация за извършените плащания; Други, които са идентифицирани на етап бизнес и системен анализ. От кеша следва да бъдат изключени прикачени файлове и големи по обем резултати от справки. Изтегляне 0.74 Mb. Сподели с приятели:
|