Нова методология за проектиране на IC

Индустрията за разработване на автоматизирани системи за управление на информацията възниква през 50-те и 60-те години на миналия век и до края на века придоби напълно завършени форми.

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

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

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

Самата идея за използване на универсална програма налага значителни ограничения върху способността на разработчиците да формират структура на база данни, екранни форми и да избират алгоритми за изчисление. Твърдата рамка, заложена "отгоре", не позволява гъвкаво адаптиране на системата към спецификата на дейността на конкретно предприятие: да се вземе предвид необходимата дълбочина на аналитичното и производствено-технологичното счетоводство, да се включат необходимите процедури за обработка на данни, да се осигури интерфейс за всяко работно място, като се вземат предвид функциите и технологията на конкретен потребител. Решаването на тези проблеми изисква сериозни модификации на системата. По този начин разходите за материали и време за внедряване на системата и нейното фино настройване към изискванията на клиента обикновено значително надвишават планираните цифри.

Според статистиката, събрана от Standish Group (САЩ), от 8380 проекта, изследвани в САЩ през 1994 г., повече от 30% от проектите са били неуспешни, на обща стойност над 80 милиарда долара. В същото време само 16% от общия брой проекти са завършени навреме, а преразходите възлизат на 189% от планирания бюджет.

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

Поради това имаше спешна необходимост от формиране нанова методологияза изграждане на информационни системи.

Целта на такава методология е да регулира процеса на проектиране на ИС и да осигури управление на този процес, за да се гарантира, че са изпълнени изискванията както за самата ИС, така и за характеристиките на процеса на разработка. ОсновенЗадачите, чието решаване трябва да бъде улеснено от методологията за проектиране на корпоративни ИС, са следните:

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

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

IC Designобхваща три основни области:

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

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

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

Според съвременната методология процесът на създаване на ИС е процес на изграждане и последователно трансформиране на редица последователни модели на всички етапи от жизнения цикъл (ЖЦ) на ИС. На всеки етап от жизнения цикъл се създават специфични за него модели - организации, изисквания за IP, IP на проекта, изисквания към приложения и др. Моделите се формират от работни групи на екипа на проекта, съхраняват се и се натрупват в хранилището на проекта. Създаването на модели, тяхното управление, трансформиране и предоставяне за колективно ползване се извършва с помощта на специални софтуерни средства - CASE-инструменти.

Процесът на създаване на ИС е разделен на няколкоетапа(етапи [1]), ограничени от определени времеви рамки и завършващи с пускането на конкретен продукт (модели, софтуерни продукти, документация и др.).

Обикновено се разграничават следнитеетапи на създаване на ИС:формиране на системните изисквания, проектиране, внедряване, тестване, въвеждане в експлоатация, експлоатация и поддръжка[1] [2]. (Последните две стъпки не се обсъждат допълнително, тъй като са извън обхвата на книгата.)

Началният етап от процеса на създаване на ИС е моделирането на бизнес процесите, които протичат в организацията и изпълняват нейните цели и задачи. Организационният модел, описан от гледна точка на бизнес процеси и бизнес функции, ни позволява да формулираме основните изисквания към ИС. Това принципно положение на методиката осигурява обективност в разработкатаизисквания за проектиране на системата. Наборът от модели за описание на изискванията за IS след това се преобразува в система от модели, които описват концептуалния дизайн на IS. Формират се модели на архитектура на ИС, изисквания към програмното осигуряване (ПО) и информационното осигуряване (ИС). След това се формира софтуерната и IO архитектура, идентифицират се корпоративните бази данни и индивидуалните приложения, формират се модели на изискванията на приложенията и се извършва тяхното разработване, тестване и интегриране.

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

Задачатаза формиране на изисквания за IPе една от най-отговорните, трудни за формализиране и най-скъпите и трудни за коригиране в случай на грешка. Съвременните инструменти и софтуерни продукти ви позволяват бързо да създавате ИС според готови изисквания. Но често тези системи не удовлетворяват клиентите, изискват многобройни подобрения, което води до рязко увеличение на действителната цена на ИС. Основната причина за тази ситуация е неправилното, неточно или непълно определяне на изискванията за ИС на етап анализ.

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

Паралелно спроектирането на схемата на базата даннисе извършвапроектиране на процесиза получаване на спецификации (описания) на всички модули на ИС. И двата процеса на проектиране са тясно свързани, тъй като част от бизнес логиката обикновено се прилага в базата данни (ограничения, тригери, съхранени процедури). Основната цел на проектирането на процеса е да картографира функциите, получени на етапа на анализ, в модулите на информационната система. При проектирането на модули се дефинират програмни интерфейси: оформление на менюто, външен вид на прозореца, горещи клавиши и свързани повиквания.

Крайните продуктиот фазата на проектиранеса:

схема на база данни(базирана на ER модела, разработен по време на фазата на анализ);
набор от спецификациина системни модули (те са изградени на базата на функционални модели).

Освен това на етапа на проектиране се разработва иархитектуратана ИС, включително изборът на платформа (платформи) и операционна система (операционни системи). В разнороден IS няколко компютъра могат да работят на различни хардуерни платформи и да работят с различни операционни системи. В допълнение към избора на платформа, следните характеристики на архитектурата се определят по време на фазата на проектиране:

дали ще бъде архитектура "файл-сървър" или "клиент-сървър";
ще бъде ли 3-степенна архитектура със следните слоеве: сървър, мидълуер (сървър на приложения), клиентски софтуер;
дали базата данни ще бъде централизирана или разпределена. Ако базата данни ще се разпространява, тогава какви механизми за поддръжкаще се използва последователност и уместност на данните;
дали базата данни ще бъде хомогенна, т.е. дали всички сървъри на бази данни ще бъдат от един и същи доставчик (например всички сървъри само за Oracle или всички сървъри само за DB2 UDB). Ако базата данни не е хомогенна, тогава какъв софтуер ще се използва за обмен на данни между СУБД на различни производители (вече съществуващи или разработени специално като част от проекта);
дали ще се използват паралелни сървъри на бази данни (например Oracle Parallel Server, DB2 UDB и т.н.) за постигане на правилна производителност.

Етапът на проектиране завършва с разработване на технически проект на ИС.

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

Фазата на тестванеобикновено се разпределя във времето.

След приключване на разработката на единичен модул от системата се извършва автономен тест, който има две основни цели:

откриване на модулни повреди (твърди повреди);
съответствие на модула със спецификацията (наличие на всички необходими функции, липса на ненужни функции).

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

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

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

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

Необходимостта да се контролира процеса на създаване на ИС, да се гарантира постигането на целите на разработката и спазването на различни ограничения (бюджет, време и т.н.) доведе до широкото използване на методите и инструментите на софтуерното инженерство в тази област: структурен анализ, обектно-ориентирано моделиране, CASE системи.

	следваща лекция ==>
АВТОМАТИ ЗА ПАКЕТИРАНЕ НА ВИСКОЗНИ МЛЕЧНИ ПРОДУКТИ.		ИНФОРМАЦИЯ, СВЪРЗАНА С ДЪРЖАВНА ТАЙНА