„Развитие на административното обслужване по електронен път”

Технически аспекти на разработката

• 
  база данни – участникът задължително трябва да включи в техническото си предложение описание на решение за клъстерна архитектура, което отговаря на следните минимални технически изисквания:
  
  • 
    Да реализира механизъм за изграждане на високонадеждни клъстерни (грид) архитектури на ниво база от данни, съобразен с наличния и доставен хардуер;
    
  • 
    Да позволява разширение на ресурсите (нова хардуерна машина) на високонадеждната среда на базата от данни в онлайн режим без прекъсване на работата на приложенията, работещи с нея;
    
  • 
    Да предоставя автоматично разпределяне на натоварването на приложенията, работещи с база от данни между кеша и процесорите на отделните машини, ползвани от нея във високонадеждната й среда;
    
  • 
    В случай на срив на една и повече машини, ползващата я база от данни трябва да продължи да ползва ресурсите на останалите машини, като автоматично пренасочи сесиите на приложенията към наличния ресурс, напълно прозрачно за самите приложения.
    
• 
  портален сървър – тук следва да се използват вградените механизми на базовата платформа, на която е разгърнат портала, за изграждане на клъстери.
  

За подобряване нивото на защита на лични и други чувствителни данни, намиращи се в СУБД към ЕПДЕАУ, ЕСОЕД и РОС, следва да се дефинират и наложат политики за контрол на достъпа от страна на системни администратори, поддържащ персонал и други привилегировани потребители. Като минимум да се реализира принципът „необходимост да се знае” (need-to-know), чрез който се ограничават правата на привилегировани потребители (администратори, разработчици и др.) до функционалност и данни, нужни единствено и само за извършване на ежедневните им задължения. Това предполага дефиниране и даване различни права на отделните администратори за управление на достъп и политики на достъп, за работа със системни структури, за работа с приложни структури. Всички тези администратори следва да нямат достъп до бизнес данните и информацията, намираща се в СУБД. За целта да се използват наличните софтуерни лицензи, предоставени от Възложителя.

• 
  Всички портални компоненти (портлети) да са разработени съгласно спецификациите JSR-168, JSR-268, WSRP 1.0 и WSRP 2.0;
  
• 
  При публикуване на функционалност на база портлети, предоставяна от приложения, разработени върху Java Server Faces да се използва механизъм, съвместим с JSF Portlet Bridge (JSR-301 и JSR-329) спецификацията;
  
• 
  Свързването (binding) на модела с останалите слоеве при разработка на портлети, базирана на Model-View-Controller принципа, да става декларативно. Механизмът на свързване да е съвместим с JSR-227 спецификацията или еквивалент;
  
• 
  Интеграция с външни портални, уеб базирани приложения и уеб сайтовете да става чрез използването на готов набор от портлети. За статично съдържание интеграция следва да се извършва посредством „изрязване” на сегменти от изходния HTML код, които по време на изпълнение се вграждат в портала;
  
• 
  В случаите на защитени отдалечени ресурси механизма на „изрязване” порталът да предава информацията за автентикация, както и да осъществява връзка по криптиран канал (HTTPs);
  
• 
  За директното извличане и визуализация на данни, намиращи се в XML файлове, CSV файлове и таблици, web services, релационни структури от СУБД, RSS и др. да се използва набор от портлети;
  
• 
  Да предлага механизъм за създаване и използване на портални компоненти от тип Pagelet или еквивалент, съвместими с различни платформи Java, .NET и др.Наличието на компоненти от тип pagelet ще даде възможност за интеграция на ЕПДЕАУ и прилежащите портални приложения да се интегрират с различни уеб сайтове и портали;
  
• 
  За целите на подобрен и усъвършенстван жизнен цикъл на порталните приложения резултатът от разработката трябва да предоставя механизъм за създаване и редакция на страниците и компонентите, комбиниращи информация от различните източници – т.нар. mashups – по време на изпълнение (run time), т.е. без необходимост от намеса на разработчици и преинсталация на приложенията;
  
• 
  Описаната по-горе възможност да е добавена като компонент, декларативно при изграждане на приложенията и следва да предоставя следната функционалност като минимум:
  
  • 
    Управление настройки и параметри на отделните портални страници;
    
  • 
    Добавяне на съдържание/компоненти към порталните страници;
    
  • 
    Управление настройки и параметри на компонентите в порталните страници;
    
  • 
    Свързване на компоненти с параметрите на порталните страници;
    
  • 
    Управление разположението (layout) на компонентите в рамките на порталните страници.
    
• 
  Компонентът за редакция на портални страници по време на изпълнение (run time) трябва да може да се добавя към всеки портален компонент като в изходния код това става чрез библиотека от т.нар. tag-ове. Компонентът трябва да е добавен към основните портални страници;
  
• 
  Основна част от порталните приложения е работата със неструктурирана информация – съдържание. За целите на достъп, публикуване и редакция на съдържание в рамките на порталните приложения резултатът от разработката трябва да поддържа интеграция с широк набор от системи за управление на съдържанието. Като минимум основната част от съдържанието следва да се черпи от хранилището на порталната рамка;
  
• 
  Интеграцията трябва да се извършва декларативно и базирана на стандарта JCR-170. Това ще даде възможност на разработчиците бързо и ефективно да свързват различни области от порталните приложения със системи за управление на съдържание по еднакъв начин и при нужда да променят източниците на съдържание;
  
• 
  Друг важен компонент е средата за търсене на информация. Усъвършенстваната реализация следва да използва унифициран и разширяем компонент за търсене и индексиране на информация, намираща се не само в порталните приложения, но и извън тях – файлови сървъри, ресурси достъпни през HTTP и др.;
  
• 
  Резултатите от заявките за търсене на крайните потребители следва да бъдат съобразени с техните права на достъп върху съответната информация;
  
• 
  За улесняване работата на експертите от страна на Възложителя при поддръжка и нужда от допълнително развитие реализацията следва да предоставя на потребителите достъп до каталог (ресурсен каталог) с всички портални ресурси (компоненти за разположение, портлети, pagelet-и, документи, източници на информация и др.). Достъпът до ресурсите следва да се съобрази с правата на потребители;
  
• 
  Комбинацията от ресурсния каталог и компонента за редакция на портални страници и компоненти да се интегрират в обща визуална среда/средство за поддръжка и развитие на ЕПДЕАУ, достъпна и налична като минимум за експертите от страна на Възложителя;
  

• 
  Налагането/залагането на политики за управление достъпа до портални ресурси да се базира на декларативен подход, съвместим със стандарта JAAS(Java Authentication and Authorization Service), а не на програмен, който предполага кодиране на правилата в изходния код на порталните компоненти;
  
• 
  Реализацията трябва да дефинира на политиките за достъп на ниво портално приложение, йерархия от портални страници, части от йерархии, навигационни компоненти и отделни страници;
  
• 
  При интеграцията на порталните решения с наличните back-end услуги и модули, налични в КТЦЕП (Ел. Поща, системи за управление на съдържанието и др.) разработката трябва да предава (propagation) удостоверенията за идентичност (credentials) на крайните потребители;
  
• 
  В случая на интеграция чрез уеб услуги (web services) предаването (propagation) на удостоверенията за идентичност (credentials) на крайните потребители да е съвместимо със стандарта WS-Security;
  
• 
  ЕПДЕАУ трябва да се интегрира с наличните KTЦЕП директорийни (LDAP) сървъри;
  
• 
  При интеграцията на приложните роли и групи потребители да се извършва свързване с, а не пренасяне на роли и групи потребители от наличните в КТЦЕП директорийни услуги;
  
• 
  За улесняване на интеграцията трябва да се реализира модул с уеб базиран потребителски интерфейс за дефиниране на роли, свързване на ролите с тези, описани в директорийната услуга и управление на потребители;
  
• 
  За улесняване процеса по защита на порталните ресурси трябва да се реализира модул за задаване на политики за достъп на ниво портално приложение, йерархия от портални страници, части от йерархии, навигационни компоненти и отделни страници;
  
• 
  Предвид интеграцията с външни системи и портали чрез портлети и pagelet-и, предлаганото решение трябва да реализира механизъм за Single Sign-On;
  
• 
  В случаите, когато външното приложение поддържа собствено хранилище с потребители и удостоверения за идентичност (credentials) за потребителите, трябва да се предостави потребителски интерфейс за свързване (mapping) на двете удостоверения – тези, с които се автентицира пред портала и тези, с които се автентицира пред външната система, портал и др;
  
• 
  ЕПДЕАУ трябва да отговаря на изискванията за информационна сигурност на информационните системи съгласно Наредбата за общите изисквания за оперативна съвместимост и информационна сигурност.
  

Предвид разширените нужди от споделяне и публикуване на информация от различни потребители към целевите групи на ЕПДЕАУ, съвместната работа на различни експертни групи от страна на Възложителя, предлаганото решение следва да реализира като минимум следните модули:

• 
  Граф на активностите – създава предпоставки за формиране на социални мрежи, относно и/или фокусирани върху проблемите, свързани с ЕП. Като функционалност модулът да събира информация за всички действия на потребителите в портала и след анализ да идентифицира и предлага свързване между потребителите;
  
• 
  Среда за анализ ползваемостта на порталното приложение – предназначена за бизнес потребители, тя следва да предлага широк набор от интуитивни справки и отчети за ползваемостта и достъпа на крайните потребители до порталните компоненти;
  
• 
  Обявления – средство за публикуване на кратки съобщения до потребителите на портала;
  
• 
  Уеб журнал (webBLOG) – среда за публикуване на съдържание от даден потребител, относно дадена тема (blog);
  
• 
  Дискусии – среда за събиране на мнение по определени въпроси и теми от по-широк кръг потребители. Тук комуникацията от тип форум (forum) като всяко изказване на потребител се регистрира в системата към повдигната тема; Информационни връзки – за целите на оптимално индексиране на информацията в портала, предлаганото решение трябва да предоставя механизъм на крайните потребители да реализират логически връзки между порталните компоненти (документи, записи в уеб журнала, дискусии във форум и др.);
  
• 
  Електронна поща – интеграция със сървър за електронна поща, посредством протоколите IMAP, SMTP. Чрез този модул крайните потребители ще могат да четат и изпращат съобщения (с прикачени файлове) директно от порталната среда;
  
• 
  Известяване – за улесняване крайната работа на потребителите трябва да се реализира функционалност, чрез която те да се „абонират” за определен източник на информация. При наличие на ново съдържание модулът следва да извести конкретния потребител;
  
• 
  Анкетни карти – за събиране на информация за обратна връзка ЕПДЕАУ да реализира средство за дефинира и публикуване на анкетни карти. По отношение на управлението порталната среда трябва да предоставя на администраторите подмодул за дефиниране на анкетните карти и преглед на резултатите;
  
• 
  Етикети - за целите на оптимално индексиране на информацията в портала, предлаганото решение трябва да предоставя механизъм на крайните потребители да маркират съдържание, документи, публикации и др. С етикети. На база етикетите, порталът трябва да изгради общ индекс на етикетите, който може да се ползва като алтернативен механизъм за търсене;
  
• 
  Съвместни публикации – официални материали и публикации, свързани с ЕП трябва да се формират от вътрешни експертни групи. ЕПДЕАУ следва да предлага среда за подобен род съвместна работа, където повече от един потребител работят върху документ, статия, наредба, публикация, инструкция и т.н.;
  
• 
  персонални/екипни задачи – среда за дефиниране/задаване на и изпълнение на задачи. В личното виртуално пространство от портала всеки потребител следва да получи достъп до онази част/стъпки от бизнес процесите, които касаят него персонално или ролята му в организацията като цяло. По-важните моменти тук са възможностите за ескалация, делегиране (reassignment), приоритизация и др. Всички задачи, които конкретен потребител трябва да извърши, следва да са достъпни през портала като се предоставя потребителски интерфейс за взаимодействие и участие в задачата/процеса.