Техническо задание

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

За администраторите на ИС модулът трябва да предоставя възможност за:

• 
  Дефиниране на групи потребители;
  
• 
  Дефиниране на потребителски роли;
  
• 
  Изготвяне на матрица на правата на достъп на потребителите – до страници, функции, съобщения, новини, форум, както и детайлизация на правото на достъп – за въвеждане, за редакция и за изтриване;
  
• 
  Блокиране и възстановяване на права за достъп;
  
• 
  Съобразно дефинираните групи, роли и матрица на достъпа да създават акаунти на експерти на ИАНМСП за работа с ИС.
  

• 
  След оторизация чрез своя master account, да регистрират акаунти на физически лица за работа в ИС;
  
• 
  Да присвояват на физическите лица група и роля в системата;
  
• 
  Чрез матрицата на достъпа да дават и променят права на физическите лица за работа в ИС в областта на действия на своя master account;
  
• 
  Да променят служебно получени или компрометирани пароли;
  
• 
  Да възстановяват, чрез система за идентификация на заявката, забравени пароли;
  
• 
  Да отнемат права за достъп до ИС в рамките на действие на своя master account.
  

Модул Профили

Профилната страница следва да има следните елементи, които собственикът на страницата не може да променя и които се попълват от администратор на ИС или автоматично от функциите на ИС:

• Връзки за достъп до свързаните страници;

• Връзки за достъп до останалите модули и функции на ИС;

• Географска локация (страна);

• Име и фамилия на търговския представител/и (служител);

• Снимка на търговския представител/и (служител);

• Адрес на търговското представителство (ИАНМСП).

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

Потребител от основен акаунт в модула следва да може да създаде под-профили от своя тип.

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

Модул Профилна страница на СТИВ

• 
  Географска локация (континент, държава, щат);
  
• 
  Име и фамилия на търговския представител;
  
• 
  Снимка на търговския представител;
  
• 
  Електронна поща;
  
• 
  Телефон, факс;
  
• 
  Предпочитан език за комуникация;
  
• 
  Адрес на търговското представителство;
  
• 
  ZIP;
  
• 
  Уеб страница;
  

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

Модулът трябва да обобщава достъпните функционалности за потребител от тип СТИВ, като добавяне на информация, преглед, връзки до аналитични инструменти, информация за други държави – създаване и/или преглед.

Конкретният обхват на функционалностите в модула ще бъде прецизиран по време на етапа за анализ и верификация на изискванията.

Модул ИАНМСП

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

Конкретният обхват на функционалностите в модула ще бъде прецизиран по време на етапа за анализ и верификация на изискванията.

Модул Аналитични инструменти

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

Модул Информация за държава, локална за конкретен СТИВ, от трети държави

В този модул да се предоставя възможност за обмяна на информация между СТИВ. Служители от СТИВ следва да могат да качват файлове, откъси от статии, снимки, линкове и др., които да имат възможност да обменят помежду си, като част от файловете могат да бъдат достъпни само до конкретни потребители. Всяка такава страница на всеки СТИВ следва да е достъпна за публикуване от всички други потребители от вида СТИВ, а за четене от ИАНМСП. Обособени части от информацията следва да могат да получават статус за публично достъпни.

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

Модул Информационна база ИАНМСП

Този модул е предназначен да осигури връзка със съществуващите информационни източници, поддържани от ИАНМСП:

• 
  Националният експортен портал (НЕП) ИАНМСП;
  
• 
  Електронният регистър (ЕР) на българските малки и средни предприятия.
  

Модулът следва да осигурява възможност за представяне на службите по търговско-икономически въпроси – СТИВ актуална и проверена информация, свързана с фирмите, които ИАНМСП е регистрирала. Връзката следва да бъде осъществена на софтуерно (програмно) ниво и да предоставя възможност за извличане и записване на данни от ЕР посредством програмен интерфейс, поддържащ работата с данни, използвайки техника за конвертиране на данните между системи от различен тип – от една система, към друга, използвайки технологична опция на специализирани програмни езици, предоставящи възможност за създаването на единици, съдържащи атрибути и/или код под формата на процедури. Би било възможно използването на друг посочен от Изпълнителя подход, позволяващ обработка на данните. Посочените данни следва да бъдат най-малко:

Идентификационни данни:

• 
  Търговско наименование на български език и латиница;
  
• 
  Правна форма, ЕИК/Друг идентификатор;
  
• 
  Държава;
  

Контактни данни:

• 
  Адрес на управление; адрес за кореспонденция; производствен адрес, телефон, факс; електронна поща лого, уеб страница;
  
• 
  Лице за контакт и представителни функции;
  

Икономически данни

• 
  Икономически сектор, основна дейност, произвеждани продукти/услуги;
  
• 
  Членство в браншова организация/клъстер;
  
• 
  Сертификати, патенти, награди;
  
• 
  Участия в изложения, търговски мисии, панаири;
  

Други данни

В процеса на изпълнение на поръчката ще бъде уточнена необходимостта от допълнителни данни, налични в регистъра на МСП и/или Националният експортен портал (НЕП) на ИАНМСП.

Модул дефиниране на преводи в системата

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

Изброяването не е изчерпателно, модулът трябва да позволява добавяне на допълнителни езици.

Нефункционални изисквания

ИС СТИВ трябва да отговаря на следните изисквания:

Натоварване

• 
  ИС трябва да позволява едновременна работа на не по-малко от 30 потребители, с възможност за увеличаване на техния брой, при необходимост до 70.
  

Интерфейс

• 
  Системата да предоставя потребителски интерфейс на български език и/или английски, който да е хомогенен и еднотипен, със стандартизирани контроли и визуални елементи, с цел бързо усвояване и лесно използване;
  
• 
  Цветовите решения трябва в ИС да бъдат съобразени с логото на ИАНМСП, но не изцяло подчинени на него;
  
• 
  Да предлага бърза и интуитивна навигация;
  
• 
  Да позволява многоезичност;
  
• 
  Чрез модула за дефиниране на преводи системата да предоставя възможност за промяна и добавяне на текстове и термини от интерфейса на различни езици, като минимум български и английски;
  
• 
  Системата трябва да бъде достъпна и да работи чрез основните видове интернет браузъри. Като минимум тя трябва да поддържа последните версии на Mozilla Firefox, Google Chrome, Internet Explorer, Opera и Safari, както и да бъде разработена чрез модерни способи, позволяващи достъпването на ИС и работата с нея през браузър на мобилно устройство;
  
• 
  Дизайнът на системата трябва да позволява бъдещо разширение и подобрения;
  
• 
  Списъци и друга резултативна информация следва да могат да бъдат подреждани по избрана колона, в низходящ и възходящ ред.
  

Архитектура и технология

• 
  Основата на софтуерните компоненти на ИС следва да бъде базирана на технология, поддържаща езикова интероперативност между поне два различни базови за нейната работа езика, общоезикова изпълняваща среда и виртуална машина на апликацията, която позволява управление на паметта и мениджмънт на изключенията.
  
• 
  Технологичната платформа трябва да използва общодостъпни и публикувани отворени технологични стандарти като например CSV, XML, HTML, CSS, Javascript, JSON, RDF, HTTP и други.
  
• 
  Внедрената ИС трябва да притежава следните характеристики:
  

• 
  Бързодействие при изпълнение;
  
• 
  Сигурност;
  
• 
  Лесна инсталация;
  
• 
  Изработена при спазване принципите на обектно - ориентиран подход за програмиране;
  
• 
  Разработен обектен модел за работа с релационни данни.
  

• 
  Внедрената ИС следва да бъде централизирана, уеб-базирана система с трислойна архитектура с презентационно ниво, приложно ниво и ниво база от данни;
  
• 
  Системата трябва да бъде реализирана на базата на съвременна и перспективна технологична платформа, която да гарантира нейната жизненост, актуалност и отвореност за пълноценно развитие за дълъг период от време.
  
• 
  Системата следва да е създадена при спазване на утвърдени стандарти за достъпност, използваемост и валидация – Accessibility и usability, дефинирани от W3C/WAI;
  
• 
  Модулите да бъдат интегрирани на ниво данни, на ниво функционалност, на ниво интерфейс и да са достъпни 24/7;
  
• 
  Да бъде предоставена възможност за съхранение и движение на документи и файлове в различен формат - .xls/xlsx, .doc/.docx. и сканирани документи във формати .pdf, .jpeg.;
  
• 
  Предлаганата системна архитектура и реализация трябва да съхранява своите данни в стандартна релационна база данни.
  

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

Сигурност на системата

• 
  Базата данни и системата да включват мерки за сигурност на данните.
  
• 
  Всяко създаване на достъп да е проследимо и за него да се регистрират данни автоматично и по начин, не подлежащ на корекция или унищожаване, данни за:
  

• 
  създател на достъпа,
  
• 
  еднозначно идентифициращи служителя данни,
  
• 
  време на създаване на достъп.
  

• 
  ИС трябва да използва утвърдени стандарти за достъп до данните, за изграждане на логиката и потребителския интерфейс, за евентуален обмен на данни с други системи.
  
• 
  Системата не трябва да допуска въвеждането на некоректни данни. Трябва да оповестява потребителя за възникнали грешки и да изисква задължително потвърждаване за извършване на необратими действия.
  
• 
  Системата да използва надеждни технологии за криптиране на пароли и служебна информация.
  
• 
  Системата да поддържа административен интерфейс за управление на системни данни, номенклатури, потребители и права.
  
• 
  Системата да включва мерки за сигурност на данните, които не разрешават пряк, неконтролиран от системата достъп на потребител до тях и последващото им копиране и разрушаването на тяхната цялост.
  
• 
  Системата трябва да бъде подсигурена срещу мрежови атаки, насочени към източване на съхраняваните данни;
  
• 
  Системата трябва да осигурява цялостност на данните при многопотребителски режим на работа и безпроблемно въвеждане или актуализиране на информация от много потребители в един и същ момент.
  

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

Уеб базираната информационна система за обслужване и вътрешна комуникация между българските служби по търговско-икономически въпроси в чужбина /СТИВ/ и ИАНМСП” ще бъде инсталирана от Изпълнителя на предоставена от Възложителя среда. Конкретните параметри на средата ще бъдат уточнени с избрания за изпълнител след стартиране изпълнение на поръчката.

Етапи и Дейности в обхвата на поръчката

Внедряването на ИС трябва да включва следните етапи:

• 
  Етап 1: Анализ и верификация на изискванията
  
• 
  Етап 2: Програмна реализация и тестване
  
• 
  Етап 3: Внедряване на среда при възложителя
  
• 
  Етап 4: Гаранционна поддръжка
  

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

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

Анализ и верификация на изискванията

Този етап включва дейностите по стартиране на проекта и анализиране на изискванията към ИС. Като минимум в този етап Изпълнителят следва:

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

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

• 
  Функционално – техническа спецификация, която да бъде одобрена от Възложителя
  

Изпълнението на етапа се удостоверява с подписване на протокол между Изпълнителя и Възложителя.

Програмна реализация и тестване

В рамките на този етап следва да бъдат извършени следните дейности:

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

Очакваният резултат от изпълнение на този етап е:

• 
  Програмно реализирана и тествана ИС;
  
• 
  Доклад от проведените тестове
  

Изпълнението на етапа се удостоверява с подписване на протокол между Изпълнителя и Възложителя.

Внедряване на среда при възложителя

В рамките на този етап Изпълнителят следва да осигури тестване на разработената ИС. Етапът трябва да съдържа следните дейности

• 
  Изготвяне на Тест план и Тестови сценарии;
  
• 
  Инсталация и конфигурация на ИС на реална среда;
  
• 
  Приемателно тестване с Възложителя;
  
• 
  Разработване на ръководство за употреба от администратори и потребители;
  

Очакваният резултат от изпълнение на този етап е:

• 
  Програмно реализирана и тествана ИС;
  
• 
  Финален доклад за внедряване на ИС
  

Изпълнението на етапа се удостоверява с подписване на протокол между Изпълнителя и Възложителя.

Гаранционна поддръжка

Този етап включва гаранционната поддръжка на ИС след приемането и от Възложителя на реална среда.

Изпълнителят на поръчката следва да осигури постоянна 6 месечна гаранционна поддръжка на внедрения от него софтуер. При стартирането на етапа Изпълнителят следва да предаде на Възложителя План за изпълнение на гаранционната поддръжка. Той се задължава да отстранява в гаранционния срок всички установени от Възложителя дефекти на софтуера и несъответствия с експлоатационната документация. В случай на нужда, Изпълнителят на поръчката трябва да разполага с необходимия ресурс и капацитет, който да му позволява да отстранява своевременно възникналите проблеми със софтуера, така че да не се прекъсва нормалния процес на работа на Възложителя. За периода на гаранционно обслужване, Изпълнителят трябва да осигури време на реакция в рамките на до 4 часа, след получаване на заявка. Гаранционната и техническа поддръжка не включва добавяне или доразвиване на функционалности.

Възможните проблеми на Възложителя с внедрения софтуер се разделят на три групи в зависимост от приоритета им:

• 
  нарушаване на основните функционалности на структуроопределящите компоненти, водещо до пълната системна неработоспособност;
  
• 
  частично нарушаване на функционалностите на структуроопределящите компоненти, водещо до частична системна неработоспособност;
  
• 
  нарушаване на функционалности на неструктуроопределящите компоненти, водещо до частична системна неработоспособност.
  

Приоритетите на проблемите се определят от Възложителя в зависимост от влиянието им върху работата на потребителите. Редът на отстраняване на проблемите се определя в зависимост от техния приоритет. Минималният обхват на поддръжката трябва да включва:

• 
  Извършване на диагностика на рапортуван проблем с цел осигуряване на правилното функциониране на системите;
  
• 
  Отстраняване на дефектите, открити в софтуерните системи, които са внедрени в обхвата на проекта;
  
• 
  Консултация за разрешаване на проблеми по предложената конфигурация на средата (операционна система, база данни, middleware, хардуер и мрежи), използвана от приложението, включително промени в конфигурацията на софтуерната инфраструктура на мястото на инсталация;
  
• 
  Възстановяване на системата и данните при евентуален срив на системата, както и коригирането им в следствие на грешки в системата;
  
• 
  Експертна поддръжка на потребителите на софтуера по телефон и електронна поща в рамките на работното време (от 9:00 до 17:30 часа всеки работен ден от седмицата);
  
• 
  Актуализация на документацията на системата в резултат от извършени действия в рамките на поддръжката и предаването й на Възложителя.
  

За осъществяване на своите гаранционни задължения участникът следва да предложи в техническото си предложение процедура за гаранционно обслужване.

Изпълнителят трябва да има Система за регистриране на проблеми, в която администраторите на системата от страна на Възложителя да регистрират заявка за отстраняване на проблем, действия по заявката и отстраняване.

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

ОРГАНИЗАЦИЯ И МЕТОДОЛОГИЯ за изпълнение на поръчката

Методология за управление на изпълнението на поръчката

Конкретната методология за управление на изпълнението на поръчката е предмет на техническото предложение на участника. Тя трябва да включва подробно описание на:

• 
  Планираните дейности (детайлен план - график за изпълнение), срокове за изпълнение, целите и очакваните резултати, както и обосновка на връзките помежду им;
  
• 
  Методите за изпълнение на планираните дейности, както и подходите, които ще бъдат използвани за постигане на целите и очакваните резултати;
  
• 
  Организационната структура на Изпълнителя и връзки за взаимодействие с Възложителя, описание на ролите и отговорностите на ключовите експерти в екипа на Изпълнителя; дефиниране на задачите и отговорностите на всеки от експертите; представяне на механизъм за взаимодействие и координация между експертите;
  
• 
  Описание на междинните резултати от изпълнението (milestones);
  
• 
  Описание на документите, които Изпълнителят ще изготви и предаде на Възложителя (проектна документация).
  

Могат да се използват методологии за управление на софтуерни проекти като например PMI, MSF, ITIL, Prince2, Agile/Scrum или еквивалентни.

Методология за анализ и извличане на изисквания

Участникът трябва да представи в техническото си предложение подробно описание на средствата и методиката за анализ на бизнес процесите и извличане и документиране на изискванията, които смята да използва по време на изпълнение на проекта. Анализът на процесите и извличането и документирането на изискванията трябва да бъдат изпълнени в пълно съответствие с изискванията на Възложителя.

Участникът по настоящата обществена поръчка трябва да използва утвърдена методика за анализ и извличане на изисквания и да я опише в техническото си предложение.

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

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

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

• 
  Планиране на качеството – идентифициране на стандартите за качество за конкретните дейности от обществената поръчка и начините за спазването им.
  
• 
  Гарантиране на качеството – всички планирани и систематични действия в рамките на системата за качество, които дават увереност, че изпълнението на конкретните дейности предмет на обществената поръчка ще отговаря на съответните стандарти.
  
• 
  Качествен контрол – проследяване на конкретни резултати, за да се определи дали отговарят на зададените стандарти и да се набележат начини за отстраняване на причините за незадоволителните резултати.
  

Участникът по настоящата обществена поръчка трябва да използва утвърдена методика за осигуряване на качеството и да я опише в техническото си предложение. В методиката той трябва да посочи кои подходи, средства и техники ще прилага при гарантиране на качеството на дейностите и как ще изпълни посочените по-горе елементи.

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

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

Участникът трябва да опише в техническото си предложение дейностите по управление на риска, като подробно:

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

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

№	Наименование на риска	Вероятност	Влияние
1.	Недобра комуникация между екипите на Възложителя и Изпълнителя по време на аналитичните дейности на проекта, в резултат на което може да се получи неразбиране на действителните нужди на Възложителя и непостигане на целите на поръчката	Средна	Високо
2.	Недостатъчна яснота по правната рамка и/или променяща се правна рамка по време на изпълнение на поръчката, което може да доведе до концептуални непълноти и разминавания между цели и резултати	Средна	Високо
3.	Недостатъчна ангажираност на персонала по време на извличане на изискванията към системата в резултат на което могат да се получат непълноти и/или забавяне	Ниска	Високо
4.	Неточна дефиниция на случаите на употреба, които ще бъдат реализирани чрез системата	Ниска	Високо
5.	Риск за администрирането на системата след изтичане на периода на гаранционна поддръжка	Ниска	Високо
6.	Невъзможност на Изпълнителя да спази предложените срокове за изпълнение на дейностите	Средна	Високо

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

Каталог: uploads -> 2016
2016 -> Цдг №3 „Пролет Списък на приетите деца
2016 -> Българска федерация по тенис на маса „В”-1” рг мъже – Югоизточна България мъже временно класиране
2016 -> Национален кръг на олимпиадата по физика 05. 04. 2016 г., гр. Ловеч Възрастова група клас
2016 -> Българска федерация по тенис на маса „А” рг мъже – Южна България мъже временно класиране
2016 -> Конкурс за изписване на великденски яйце по традиционната техника съвместно с одк велинград 27 април
2016 -> Министерство на образованието и науката регионален инспекторат по образованието – софия-град

Изтегляне 351.49 Kb.

Сподели с приятели: