ПОРТФЕЙЛ МРЕЖОВИ УСЛУГИ 4.1Текущ портфейл мрежови услуги

4.2Настояща мрежова среда

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

За редуциране услугите на БТК, през 2001 г. бе инициирано въвеждането на НАМДА (опорна мрежа за държавната администрация). В действителност днес НАМДА не покрива цялата територия на България с посредством междуградски оптични връзки. От април 2007 г. НАМДА има оптична връзка между София, Пазарджик и Пловдив. Маршрутът между Пловдив, Хасково, Стара Загора и Ямбол бе завършен наскоро. Важна стъпка към модернизацията на мрежовата инфраструктура на администрацията бе замяната на ATM технологията за междуградски връзки с DWDM / SDH технология за наскоро изпълнените връзки между София, Пловдив, Хасково, Стара Загора, Сливен и Ямбол (вижте Фигура 6).



Фигура 6 – Настояща НАМДА инфраструктура

Настоящият оптически пробег все още не покрива другите областни центрове на България: Бургас, Варна, Шумен, Търговище, Разград, Русе, Велико Търново, Габрово, Плевен, Ловеч, Враца и Монтана.

Физическата топология е линейна; тя не осигурява допълнителен ресурс в случай на възлова или авария на връзките.

За осигуряване на устойчивост, се използва нает капацитет, но планът и препоръката е да се разшири съществуващата собствена мрежова инфраструктура за осигуряване на двоен достъп до всяка локация чрез използване на топологичният модел на два допираши се кръга модел. (вж. фиг. 7 – Препоръчителна бъдеща инфраструктура на НАМДА).

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

4.3Бъдещи изисквания към мрежата

• 
  Западен кръг – включващ
  

• 
  София
  
• 
  Пазарджик
  
• 
  Пловдив
  
• 
  Хасково
  
• 
  Стара Загора
  
• 
  Габрово
  
• 
  Велико Търново
  
• 
  Ловеч
  
• 
  Плевен
  
• 
  Враца
  
• 
  Монтана
  

• 
  Източен кръг – включващ
  

• 
  Стара Загора
  
• 
  Сливен
  
• 
  Ямбол
  
• 
  Бургас
  
• 
  Варна
  
• 
  Шумен
  
• 
  Търговище
  
• 
  Разград
  
• 
  Русе
  
• 
  Велико Търново
  
• 
  Габрово
  

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

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

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

• 
  Като база за началното оразмеряване на системата и оценка на разходите
  
• 
  За оценка на приложимостта на предлаганата ИТ система
  
• 
  За изготвяне дизайна на операционните (инфраструктурни) модели
  
• 
  Като базови данни за Споразуменията за ниво на обслужване (и други НФИ) за проектирането на компонентите
  

Описаното по-долу представя началния комплект нефункционални изисквания, базирани на резултатите от интервютата на фаза оценка, най-добрите практики и опита на IBM от проекти с подобен характер.

4.4.1Изпълнение

Архитектурата трябва да е гъвкава и с възможност за допълнителна настройка за предоставянето на време за отговор, удовлетворяващо потребителя, съгласно определеното за всяко разработено приложение при различни операционни условия. Архитектурните и изпълнителски решения могат да се основават на условията по специфичния избор на технология, например ненадеждни дистанционни връзки, който не могат да поддържат Гласова услуга чрез IP (VoIP) приложение. Най-общо характеристиките н аизпълнението като време за отговор и време за предаване трябва да се базират на реалните, възможни работни нужди.

4.4.2Универсалност

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

4.4.3Наличие и надеждност

Сега повече от всякога, наличието и изпълнението на важните за мисията приложения в ИТ средата е от съществена важност за бизнес трансакциите, независимо къде са разположени компонентите. Е—правителството може да понесе огромни загуби на производителността, ако клиентите, доставчиците и служителите нямат достъп до ключовите приложения. По тази причина, наличната и пригодна информация за ИТ приложенията и техните ресурси трябва да се осигурява от агенти по управлението за докладване до конзолата за управление, така че да могат да се предприемат необходимите действия. Очакванията за наличност спрямо системата се отнасят до това колко часа на ден, на седмица или седмици в годината електронните работни приложения ше са налични за потребителите и колко бързо могат да бъда т възстановени в случай на повреда (непланирано прекъсване). Много е вероятно работните нужди да наложат изискване приложенията на е-правителството да са налични 24 часа на ден, 7 дни в седмицата, 52 седмици в годината. Архитектурата на е-правителството трябва д апозволи това, както и да се справя с непланирано спиране посредством целева функция, програмирана за измерване наличието на услугите.

«Времето за възстановяване» често е ключовия фактор за измерване и може да бъде изразено в минути, секунди или дори милисекунди за различните нива на мрежава в зависимост от характеристиките на технологията. За приложенията 'в реално време', като Гласова услуга, потребителите няма да толерират повече от няколко секунди загуба на връзката, след което биха прекъснали разговора.

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

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

4.4.4Разширяемост и гъвкавост

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

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

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

4.4.5Сигурност

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

4.4.6Свързаност и взаимодействие

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

4.4.7Управление на системите

Работата на комбинирани и споделени услуги в рамките на е-правителството представлява уникално управление на проблемите и въпросите.

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

4.4.8Удобство за експлоатация

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

Това изискване се отнася до експлоатацията и управлението на бизнес софтуерните и хардуерни системи. То включва дейности като:

• 
  Добавяне и премахване на потребители и системи
  
• 
  Наблюдение и извършване настройка на компютърното и мрежово изпълнение
  
• 
  Поправяне на бъгове и разпространение на новите версии на производителя
  
• 
  Адаптиране на софтуера към новите хардуерни устройства и тестване
  
• 
  Диагностика на хардуера и софтуера или отстраняване на проблеми
  

Каталог: upload -> docs
docs -> Задание за техническа поддръжка на информационни дейности, свързани с държавните зрелостни изпити (дзи) – учебна година 2012/2013
docs -> Наредба №2 от 10. 01. 2003 г за измерване на кораби, плаващи по вътрешните водни пътища
docs -> Наредба №15 от 28 септември 2004 Г. За предаване и приемане на отпадъци резултат от корабоплавателна дейност, и на остатъци от корабни товари
docs -> Общи положения
docs -> І. Административна услуга: Издаване на удостоверение за експлоатационна годност (уег) на пристанище или пристанищен терминал ІІ. Основание
docs -> I. Общи разпоредби Ч
docs -> Закон за изменение и допълнение на Закона за морските пространства, вътрешните водни пътища и пристанищата на Република България
docs -> Закон за предотвратяване и установяване на конфликт на интереси
docs -> Наредба за системите за движение, докладване и управление на трафика и информационно обслужване на корабоплаването в морските пространства на република българия

Изтегляне 1.44 Mb.

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