Разработване на интерфейс и проектиране на информационна система. Проектиране на информационна система

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

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

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

В процеса на проектиране на информационна система могат да се разграничат три основни етапа:

1. дизайн на потребителски интерфейс;
2. проектиране на база данни;
3. проектиране на система за свързване на CGI програми.

На първия етап от проектирането е необходимо да се установят изискванията на потребителите към системата и въз основа на тези изисквания да се направи оформление на уебсайт, показващо всички HTML форми и HTML файлове с отчети за взаимодействие с информационната система. Желателно е HTML формулярите да съдържат някои данни по подразбиране и връзка към HTML документи, които се очаква да бъдат резултат от заявка към системата. В този случай ще бъде по-лесно за потребителите да разберат какво сте проектирали.
Дизайнът на база данни е разгледан подробно в главата „Проектиране бази данни", така че няма да го повтаряме тук. Нека само да отбележим, че този етап е скрит от потребителите и цялата отговорност за избора на правилното решение пада върху вас като разработчик.
На третия етап се идентифицира набор от CGI програми. Какво прави всяка CGI програма и връзките между тях. Веднага бих искал да посоча една много често срещана грешка, допускана от начинаещи уеб разработчици, които внедряват няколко функции в една програма. Например, когато се разработва книга за гости, се създава един CGI скрипт, който се извиква във всички HTML форми: както при показване на съобщения, така и при добавяне.Още по-лошо е, ако там са включени и функции за административен достъп, т.е. изтриване и редактиране на съобщения. Има три важни причини, поради които не трябва да правите това. Първо, това е потенциална дупка в сигурността. Второ, зареждането и изпълнението на такава CGI програма ще бъде по-бавно. И трето, такава програма е трудна за модифициране, тестване и отстраняване на грешки, т.к самата тя е трудна поради обема на изходния текст.
Най-правилното решение е недвусмислена връзка между функционалното изискване и CGI програмата. Една функция (операция) - една CGI програма. В този случай изходният код ще бъде прост и малък и следователно вероятността да пропуснете дупка в сигурността в него е значително намалена. Зареждането и изпълнението на такава програма ще бъде много по-бързо. И най-важното, ще бъде много по-лесно да модифицирате и поддържате такава програма.
В допълнение към описанието коя програма каква функция изпълнява, трябва да установите връзките между тях. Това е такава уеб схема. IN прости системитой е прост, но при големите сложността му нараства нелинейно. Разбира се, можете да организирате връзки на място. В простите системи изобщо нищо не се рисува, защото... и всичко е толкова очевидно. Но в големи системи, особено ако работите в екип от няколко души, е полезно да имате визуална представа за това къде и от какъв CGI скрипт се извиква и къде ще бъдете отведени след неговото изпълнение. По същество, както вече обсъдихме в главата „Програмиране на CGI“, CGI програма може да изведе или текст, или да пренасочи към друг интернет адрес, или да изведе картина или някакъв друг файл. Този вид ръчно начертана диаграма е полезно да имате, за да разберете ясно архитектурата на проекта.

Въведение

Заключение

Литература

Въведение

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

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

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

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

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

Целта на теста е да разгледа стъпка по стъпка процеса на създаване на информационни системи.

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

1. Проектиране на информационни системи

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

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

изисква се пропускателна способностсистеми;

· необходимо време за реакция на системата при заявка;

· безпроблемна работа на системата в необходимия режим, с други думи, готовността и готовността на системата да обработва потребителски заявки;

· лекота на работа и поддръжка на системата;

· необходима сигурност.

Производителността е основният фактор, който определя ефективността на една система. Добрият дизайн е в основата на една високопроизводителна система.

Проектирането на информационни системи обхваща три основни области:

· проектиране на обекти от данни, които ще бъдат внедрени в базата данни;

· проектиране на програми, екранни форми, отчети, които ще осигурят изпълнението на заявки за данни;

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

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

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

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

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

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

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

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

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

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

· диаграма на база данни (базирана на ER модела, разработен на етап анализ);

· набор от спецификации на системни модули (те са изградени на базата на функционални модели).

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

· дали ще бъде архитектура „файл-сървър” или „клиент-сървър”;

· ще бъде ли 3-степенна архитектура със следните слоеве: сървър, мидълуер (сървър на приложения), клиентски софтуер;

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

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

· дали ще се използват паралелни сървъри на бази данни (например Oracle Parallel Server, DB2 UDB) за постигане на правилна производителност.

Фазата на проектиране завършва с разработването технически проектЕ. На етапа на внедряване се създава софтуер за оперативна документация.

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

· откриване на повреди на модули (твърди повреди);

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

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

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

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

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

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

За нетърпеливите или тези, които нямат време: резюме и интересни връзки в края на текста.

Да започнем с очевидното.
Очевидност #1:Хората се нуждаят от информация, за да вземат решения.
Очевидност #2:Информацията може да бъде:

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

Може би това е основната причина, която ме подтикна да напиша статията, която предлагам на вашето внимание. Тя е разделена на няколко глави, в които предлагам да разгледаме следните въпроси:

• Какво представлява информационната архитектура като феномен, нейното място в цялостния процес на проектиране на взаимодействието;
• Какви са спецификите на работата по информационна архитектура за електронна търговия;
• Как вземаме решения. Малко психология;
• Как да проектираме информационна архитектура на практика.

Е, да започваме.

Защо да работим върху информационната архитектура?

Какво се случи с Иван Владимирович

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

Изборът му се спря на магазина Eliteboose.com, за който чу, че е най-много най-добрият изборалкохол. От пръв поглед Иван Владимирович е впечатлен от стилния и изпипан дизайн на сайта.

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

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

Вече наистина исках да спя, но Иван Владимирович направи още един опит, като отиде на друг елемент от менюто - „За приятели“. Сред многобройните бири, водки и ликьори той най-накрая забеляза самотен ром, който се криеше в края на списъка. Бутилката Demo Anejo може би беше добър избор, но той беше объркан от липсата на избор. И можеше ли шефът му - ръководител на отдел на една от водещите банки в страната - да оцени подаръка на цена от само 13 щатски долара.

Иван Владимирович излезе на балкона да изпуши. След това се върна, седна на лаптопа и направи трети и последен опит: избра елемента от менюто „За празник“. И тогава се случи дългоочакваното чудо: той видя впечатляващ списък от голямо разнообразие от роми във всяка ценова категория. След като обмисли списъка няколко минути, той добави петнадесетгодишния Gran Demo Blender Rum в количката си и премина през процеса на поръчка с лекота. Иван Владимирович беше доволен от себе си, но предчувствието за огромна липса на сън значително отрови настроението му.

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

А сега и в цифри

В горната история има проблем с IA, макар и преувеличен. В Eliteboose.com виждаме неясно дефинирани и наименувани категории и неочевидна класификация на продуктите в категории.

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

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

Нека адаптираме подхода Джаред Спул, който той използва, за да изчисли цената на разочарованието на пътниците от проблеми с използваемостта за транспортната компания Amtrak:

1. Ние изчисляваме идеален потенциал за доходи– Iideal=a*b, Където АИ b– среден чек и брой потенциални купувачи (лийдове) на ден
2. Получаваме общ пропуснат доход– Iforgone= Iideal -(Iideal *x/100), Където х– процент на отказаните покупки като цяло
3. Нека разберем цена на грешка в IA – IAcost= Ifforgone *y/100, $3500*20/100, Където г– делът на отказите по вина на ИА.

1. Средна сметка за поръчка – $100 ;
2. брой потенциални купувачи (потенциални клиенти) на ден – 50 ;
3. процент на отказаните покупки – 70% ;
4. от които по вина на ИА - 20% .

• Идеален доход - $100*50=$5000 на ден
• Общ пропуснат доход – $5000-($5000*70/100)=$3500 на ден
• Цената на грешка в IA е $3500*20/100 = $700 на ден

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

Но преди да преминем към решаването на проблема, основателно възниква следният въпрос:
„Какво имаме предвид под информационна архитектура?“

Какво е информационна архитектура?

• „Така ли се организира информацията? Къде и какво е?”;
• „Нещо от използваемостта, за лесно използване на сайта?“;
• „Точно така, карта на сайта! Да, разбира се, че е полезно... не го използвам наистина”;
• „Навигация, като... Е, как да се движите из сайта“;

Ричард Сол Вурман

Бащата на информационната архитектура, Ричард Сол Вурман, дава следните дефиниции на информационната архитектура:

• „Намиране и организиране на модели, присъщи на данните. За да направим сложното просто”;
• „Създаване на структура или карта на информация, която да позволи на потребителите да намерят своя личен път към знанието“;
• „Нова професия в 21-ви век, която се фокусира върху яснотата, човешкото разбиране и науката за организиране на информация.“

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

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

Предлагам следното (което не противоречи на горните подходи за разбиране на IA):
„IA е схема за организиране на информация за уебсайт“

Лаконичен и много абстрактен. Измерваните показатели за качеството на информационната агенция трябва да бъдат доста конкретни:

1. Скорост на намиране на информация(KPI: брой стъпки за намиране на информация или изразходвано време);
2. Качество на намерената информация(KPI: качествен индикатор за съответствие на информацията с очакванията на потребителите, от 1 до 10).

Оттук и въпрос номер две:
Ако е толкова важно, как мога да интегрирам работата по IA в цялостния процес на проектиране на взаимодействие?

Как да работим върху информационната архитектура?

А. Ориентиран към потребителя

Идея:Потребителят знае по-добре

Фокус:Цели и нужди на потребителя

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

Къде се използва:големи продуктови компании, стартиращи фирми и дигитални агенции.

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

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

Подпроцес за създаване на IA


Забележка: изследователският метод „Сортиране на карти“ далеч не е единственият. Страхотен сравнителен прегледОписани са методите за изследване на ИА Джим Рос .

Б. Съсредоточена върху дейността

Идея:Започваме от задачите на потребителя.

Фокус:Потребителска активност.

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

Къде се използва:Както стартиращи компании, така и аутсорсинг компании.

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

IA място:Можете също така да разработите AI във взаимодействие с потребителите без много загуба на време и бюджет. Но трябва да започнете от задачите на потребителя и каква информация трябва да помогне на потребителя да реши всеки конкретен проблем в хода на дейността си. Едва след това ще има смисъл да преминете на по-високо ниво. По този начин проектирането на ОВ ще продължи отдолу нагоре.

Подпроцес за създаване на IA

C. Проектиране на системи

Идея:Потребителят е част от системата около него.

Фокус:Потребителска среда.

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

Къде се използва:Дигитални агенции, големи продуктови компании.

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

IA място:директното изследване и проектиране на IA тук е заменено от работа върху архитектурата на системата с различни инструменти и подходи.

Г. „Гениален“ дизайн

Идея:Дизайнерът е главата на всичко.

Фокус:Собствено разбиране на дизайна, евристика на дизайна (примери могат да бъдат намерени на

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

Основател на кибернетиката (наука за системите и методите за управление) е Норберт Винер (САЩ). Трудовете на неговите последователи станаха основата на теорията автоматично управление. Това е науката за общите закони за получаване, съхраняване, предаване и преобразуване на информация в сложни системи за управление. Приложение компютърно оборудванеза решаване на управленски проблеми доведе до развитието на теорията на информацията, теорията на кодирането и формирането на независима научна област на компютърните науки. Резултатите от тези изследвания са в основата на разработването на методология за прилагане на технически и софтуерза решаване на проблеми с различна практическа насоченост.

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

Основател на единни методологични подходи в проектирането на ИС е академик В.М. Глушков, който формулира научни и методически принципи и практически препоръкиза създаване на автоматизирана информационна система. Основните принципи на единните методически подходи са:

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

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

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

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

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

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

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

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

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

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

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

Описанието на жизнения цикъл на една информационна система включва работа със следните концепции:

Процес - верига от работи, които се извършват последователно;

Етапите са последователни периоди от време, през които се извършва работа. По време на етапа може да се извършва работа, свързана с различни процеси. Дейността по създаване и използване на автоматизирана информационна система за управление на икономически обект се основава на концепцията за неговия жизнен цикъл (LC). Жизненият цикъл е модел на създаване и използване на автоматизирана информационна система за управление на икономически обект, отразяващ различните му състояния, започвайки от момента на възникването и необходимостта от него и завършвайки с момента на пълното изтегляне от употреба от всички потребители без изключение.

Традиционно се разграничават следните основни етапи от жизнения цикъл на AIS:

Анализ на изискванията;

Дизайн;

Програмиране/внедряване;

Тестване и отстраняване на грешки;

Експлоатация и поддръжка.

Нека разгледаме по-подробно основните етапи от жизнения цикъл на AIS:

1. Анализът на изискванията е първата фаза от разработването на AIS, при която изискванията на клиента се изясняват, формализират и документират. Всъщност на този етап се дава отговорът на въпроса: „Какво трябва да прави бъдещата система?“ И това е успехът на целия проект. В практиката на създаване на големи системи има много примери за неуспешно изпълнение на проекти именно поради непълнотата и неясното дефиниране на системните изисквания.

Списъкът с изисквания за AIS трябва да включва:

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

2) описание на функциите, които системата трябва да изпълнява;

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

Целта на анализа е да трансформира общо, размито знание за изискванията към бъдещата система в точни (ако е възможно) дефиниции.

Резултатът от етапа трябва да бъде модел на системни изисквания (т.е. системен дизайн), което означава:

1) архитектурата на системата, нейните функции, външни условия, разделяне на функциите между хардуерната и софтуерната част;

2) интерфейси и разделяне на функциите между хората и системата;

3) изисквания към софтуера и информационните компоненти на софтуерната част: необходими хардуерни ресурси, изисквания към базата данни, физически характеристики на софтуерните компоненти, техните интерфейси.

Моделът на изискванията трябва да включва;

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

2) спецификации на операции от по-ниско ниво;

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

4) концептуален информационен моделизисквания;

5) пакет от отчети и документи по информационния модел;

6) архитектура на системата по отношение на концептуалния информационен модел;

7) предложения за организиране на структура за поддръжка на системата.

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

1) Традиционното развитие се характеризира с прилагането на началните етапи с помощта на занаятчийски, неформализирани методи. Следователно клиентите и потребителите могат да видят системата за първи път, след като тя вече е до голяма степен внедрена. Естествено, тази система ще бъде различна от тази, която очакваха. Следователно по-нататъшните повторения на неговото развитие или модификация изискват допълнителни (и значителни) разходи на пари и време. Ключът към решаването на този проблем се предоставя от модела на изискванията, който позволява

Опишете, „вижте” и коригирайте бъдещата система, преди тя да бъде физически внедрена;

Намалете разходите за разработка и внедряване на системата;

Оценявайте развитието по отношение на времето и резултатите;

Постигане на взаимно разбирателство между всички участници в работата (клиенти, потребители, разработчици, програмисти)

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

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

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

4) Моделът на изискванията може да се използва за автоматизирано и бързо обучение на нови служители в конкретна област от дейността на предприятието, тъй като неговата технология се съдържа в модела.

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

2. Разработването на техническата спецификация се извършва след изграждането на модела, тя съдържа изисквания към бъдещата система. На негова основа се разработва техническо задание за създаване на система, която включва:

Изисквания към автоматизираните работни места, техния състав и структура, както и методи и схеми на информационно взаимодействие между тях;

Разработване на изисквания към техническите средства;

Определяне на софтуерни изисквания;

Разработване на топология, състав и структура на локална компютърна мрежа;

Изисквания за етапите и времето на работа.

3. Дизайн. Този етап дава отговор на въпроса: „Как (по какъв начин) системата ще удовлетвори изискванията към нея?“ Задачата на този етап

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

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

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

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

4. Внедряване (програмиране/адаптиране). На този етап LES се създава като комплекс от софтуер и хардуер (започвайки с проектирането и създаването на телекомуникационна инфраструктура и завършвайки с разработването и инсталирането на приложения).

5. Тестване и отстраняване на грешки. Коректността на AIS е най-важното му свойство и основна грижа на разработчиците. В идеалния случай коректността на 1C означава липсата на грешки в него. Това обаче е невъзможно да се постигне за повечето сложни софтуерни продукти (всяка програма съдържа поне един бъг). Следователно под „правилно“ обикновено имаме предвид софтуер, работещ в съответствие с предявените му изисквания, тоест продукт, за който все още не са открити такива условия, при които той би бил неработещ.

Установяването на коректност е основната цел на разглеждания етап от жизнения цикъл. Трябва да се отбележи, че етапът на тестване и отстраняване на грешки е един от най-трудоемките, досадни и непредвидими етапи от разработването на ИС. Средно, за разработка по традиционни методи, този етап отнема от 1/2 до 1/3 от общото време за разработка. От друга страна, тестването и отстраняването на грешки създават сериозен проблем: в някои случаи тестването и отстраняването на грешки на програмите изисква няколко пъти повече време от самото програмиране.

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

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

Сложните системи изискват голям брой тестове и възниква проблемът с оценката на необходимия брой и използването на методи за тяхното намаляване. Затова е препоръчително да планирате тестване (както всеки друг вид дейност). Планът за изпитване трябва да съдържа:

1) формулиране на целите на тестването;

2) критерии за качество на тестването, позволяващи да се оценят резултатите от него;

3) стратегия за изпитване, която гарантира постигането на определени критерии за качество;

4) потребности от ресурси за постигане на даден критерий за качество според избраната стратегия.

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

6. Експлоатация и поддръжка. Основните цели на този етап са:

Осигуряване на стабилност на системата и запазване на информация - администриране;

Навременна модернизация и ремонт отделни елементи- техническа поддръжка;

Адаптиране на възможностите на системата, оперирани с текущите бизнес нужди на предприятието – развитие на системата.

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

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

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

Съществуващите модели на жизнения цикъл определят реда на етапите по време на разработката, както и критериите за преминаване от етап на етап. В съответствие с това най-разпространени са следните три модела ZhShch4]:

1. Каскадният модел (70-80-те години) осигурява преход към следващия етап след пълно завършване на работата на предишния етап и се характеризира с ясно разделяне на данните и процесите на тяхната обработка (фиг. 2.6).

Ориз. 2.6. Каскаден IP модел на жизнения цикъл

2. Поетапен модел с междинен контрол (80 - 85 години) - итеративен модел на развитие с цикли обратна връзкамежду етапите. Предимството на този модел е, че междустепенните настройки осигуряват по-малка интензивност на труда в сравнение с каскадния модел; от друга страна, животът на всеки етап се простира през целия период на развитие.

3. Спирален модел (86 - 90-те години) - фокусира се върху началните етапи от жизнения цикъл: анализ на изискванията, проектиране на спецификация, предишен и детайлен дизайн. На тези етапи се проверява и обосновава осъществимостта на техническите решения чрез създаване на прототипи. Всеки завой на спиралата съответства на поетапен модел за създаване на фрагмент или версия на системата; върху него се изясняват целите и характеристиките на проекта, определя се неговото качество и работата на следващия завой на планира се спирала. По този начин се задълбочават и последователно уточняват детайлите на проекта, като в резултат се избира обоснован вариант, който се довежда до изпълнение (фиг. 2.7.).

Ориз. 2.7. Спирален IP модел на жизнения цикъл

Експертите отбелязват следните предимства на спиралния модел:

Натрупване и повторно използване на софтуер, модели и прототипи;

Фокус върху развитието и модификацията на системата по време на нейното проектиране;

Анализ на риска и разходите в процеса на проектиране.

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

Характеристики на дизайна на информационните технологии. Модерен информационни технологииреализирани в условията на проектираната информационна система.

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

Въведение

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

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

Производителността е основният фактор, който определя ефективността на една система. Добрият дизайн е в основата на една високопроизводителна система.

Проектирането на информационни системи обхваща три основни области:

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

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

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

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

Ако се вгледате в него, наистина ли развитието на системата е толкова непредсказуемо и наистина ли е невъзможно да се получи информация за нея? Вероятно чрез семинари може да се получи представа за системата като цяло и предложените (от ръководството) начини за нейното развитие. След това разбийте сложната система на по-прости компоненти, опростете връзките между компонентите, осигурете независимостта на компонентите и опишете интерфейсите между тях (така че промяната в един компонент да не води автоматично до значителна промяна в друг компонент) , както и възможността за разширяване на системата и „пънове“ за нереализируеми в една или друга версия на функционалната система. Въз основа на такива елементарни съображения описанието на това, което трябва да се внедри в информационната система, вече не изглежда толкова нереалистично. Можете да се придържате към класически подходи към разработването на информационни системи, една от които - схемата „водопад“ (фиг. 1) - е описана по-долу. Ще бъдат разгледани накратко и някои други подходи за разработване на информационни системи, където използването на елементите, описани в диаграмата „водопад“, също е приемливо. Кой от описаните по-долу подходи да следвате (и дали има смисъл да измислите собствен подход) е до известна степен въпрос на вкус и обстоятелства.

Ориз. 1. Диаграма на водопада

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

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

По-долу ще разгледаме някои схеми за развитие на проекти.

„Водопад“ - диаграма за развитие на проекта

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

По-долу ще разгледаме всеки от етапите, като се фокусираме по-подробно върху етапа на проектиране.

Стратегия

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

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

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

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

Документът трябва да описва:

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

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

Трябва да се отбележи, че както на етапа на избор на стратегия, така и на етапа на анализ и по време на проектирането, независимо от метода, използван при разработването на проекта, планираните функции на системата винаги трябва да се класифицират по степен на важност. Един възможен формат за представяне на такава класификация, MoSCoW, е предложен в Clegg, Dai и Richard Barker, Case Method Fast-track: A RAD Approach, Adison-Wesley, 1994.

Това съкращение означава: Must have - необходими функции; Трябва да има - желани функции; Може да има - възможни функции; Няма да има - липсващи функции.

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

Анализ

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

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

Анализаторите събират и записват информация в две взаимосвързани форми:

• функции - информация за събития и процеси, които се случват в бизнеса;
• entities – информация за неща, които са важни за организацията и за които нещо се знае.

Два класически резултата от анализа са:

• йерархия от функции, която разделя процеса на обработка на съставните му части (какво се прави и от какво се състои);
• Entry Relationship model (ER модел), който описва обекти, техните атрибути и връзки (отношения) между тях.

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

По-долу разглеждаме трите най-често използвани методологии за структурен анализ:

• Entity-Relationship Diagrams (ERD), които служат за формализиране на информация за обекти и техните взаимоотношения;
• Диаграми на потока от данни (DFD), които служат за формализиране на представянето на системните функции;
• Диаграми на прехода на състоянието (STD), които отразяват зависимото от времето поведение на системата; Диаграмите на жизнения цикъл на обекта принадлежат към този клас диаграми.

ER диаграми

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

Ориз. 2. Пример за ER диаграма

Обектът се изобразява като правоъгълник с името на обекта в горната част (например ЗАГЛАВИЯ). Правоъгълникът може да изброява атрибутите на обект; Атрибутите на ER-диаграмата, въведени с удебелен шрифт1, са ключови (например Идентичността на заглавието е ключов атрибут на обекта TITLES, другите атрибути не са ключови).

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

Единичният ред отдясно (Фигура 3) означава „едно“, „птичият крак“ отляво означава „много“, а връзката се чете по линията, като например „едно към много“. Вертикална лента означава „задължително“, кръг означава „незадължително“, например за всяка публикация в TITLE трябва да бъде посочен издателят в PUBLISHERS и един издател в PUBLISHERS може да публикува няколко заглавия на публикации в TITLES. Трябва да се отбележи, че връзките винаги се коментират (надписът на линията, изобразяващ връзката).

Ориз. 3. ER диаграмен елемент

Нека дадем пример (фиг. 4) за образ на рефлексивната връзка „служител“, където един служител може да управлява няколко подчинени и така нататък в йерархията на позициите.

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

Ориз. 4. ER диаграма на рефлексивното отношение

Атрибутите на обекта могат да бъдат ключови - те са подчертани с удебелен шрифт; задължителни - те се предшестват от знак „*“, т.е. тяхната стойност винаги е известна, незадължителни (незадължителни) - те се предшестват от O, т.е. стойностите на този атрибут може да отсъстват или да са несигурни в някои моменти.

дъги

Ако даден обект има набор от взаимно изключващи се взаимоотношения с други обекти, тогава се казва, че такива взаимоотношения са в дъга. Например, банкова сметка може да бъде създадена или за юридическо лице, или за индивидуален. Фрагмент от ER диаграма за този тип връзка е показан на фиг. 5.

Ориз. 5. Арк

В този случай атрибутът OWNER на обекта ACCOUNT има специално значение за този обект - обектът е разделен на типове по категории: „за физическо лице“ и „за юридическо лице“. Получените обекти се наричат ​​подтипове, а оригиналният обект става супертип. За да разберете дали е необходим супертип или не, трябва да установите колко идентични свойства имат различните подтипове. Трябва да се отбележи, че злоупотребата с подтипове и супертипове е доста често срещана грешка. Те са изобразени, както е показано на фиг. 6.

Ориз. 6. Подтипове (вдясно) и супертип (вляво)

Нормализация

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

Допустими видове връзки. По-внимателен поглед към връзката едно към едно (Фигура 7) почти винаги разкрива, че A и B всъщност са различни подмножества на едно и също нещо или различни гледни точки за него, просто имат различни имена и са описани по различен начин, връзки и атрибути.

Ориз. 7. Връзки едно към едно

Отношенията много към едно са показани на фиг. 8.

Ориз. 8. Връзки много към едно

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

II е най-често срещаната форма на комуникация. Предполага се, че всяко появяване на обект A може да съществува само в контекста на едно (и само едно) появяване на обект B. От своя страна, появяванията на B могат да съществуват със или без появявания на A.

III - използва се рядко. И А, и Б могат да съществуват без никаква връзка между тях.

Отношенията много към много са показани на фиг. 9.

Ориз. 9. Връзки много към много

I - тази конструкция често се среща в началото на етапа на анализ и означава връзка - или неразбрана напълно и изискваща допълнително разрешаване, или отразяваща проста колективна връзка - двупосочен списък.

II - рядко се използва. Такива връзки винаги подлежат на допълнителни подробности.

Нека сега разгледаме рекурсивните връзки (фиг. 10).

Ориз. 10. Рекурсивни връзки

I - рядко, но се среща. Отразява връзки от алтернативен тип.

II - доста често се използва за описание на йерархии с произволен брой нива.

III - възниква в ранните етапи. Често отразява структурата на „списъка на материалите“ (взаимно влагане на компоненти). Пример: Всеки КОМПОНЕНТ може да се състои от един или повече (други) КОМПОНЕНТИ и всеки КОМПОНЕНТ може да се използва в един или повече (други) КОМПОНЕНТИ.

Невалидни типове връзки. Невалидните типове релации включват следното: задължителни релации много към много (фиг. 11) и редица рекурсивни релации (фиг. 12).

Ориз. 11. Невалидни релации много към много

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

Ориз. 12. Невалидни рекурсивни връзки

Диаграми на потока от данни

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

Ориз. 13. Пример за DFD

По-специално, DFD не показва процесите, които контролират действителния поток от данни и не прави разлика между валидни и невалидни пътища. DFD съдържат много полезна информация, и в допълнение:

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

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

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

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

Външен обект (терминатор) представлява обект извън системния контекст, който е източник или приемник на системни данни. Нейното име трябва да съдържа съществително име, като например „Клиент“. Обектите, представени от такива възли, не се очаква да участват в никаква обработка.

STD диаграми за преход на състоянието

Жизненият цикъл на един обект принадлежи към класа STD диаграми (фиг. 14). Тази диаграма показва промяната в състоянието на даден обект във времето. Например, помислете за състоянието на продукт в склад: продукт може да бъде поръчан от доставчик, получен в склада, съхраняван в склад, подложен на контрол на качеството, продаден, отхвърлен или върнат на доставчика. Стрелките на диаграмата показват приемливи промени в състоянието.

Ориз. 14. Пример за диаграма на жизнения цикъл

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

Някои принципи за проверка на качеството и пълнотата на информационен модел
(източник - Richard Barker, Case Method: Entity Relationship Modeling, Addison-Wesley, 1990)

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

Редовно изпращайте вашия информационен модел или части от него, относно които имате притеснения, за одобрение от потребителя. Обърнете специално внимание на изключенията и ограниченията.

Качество на субекта

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

Списък с въпроси за проверка за юридическото лице:

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

Списък с скрининг въпроси за подтипа:

• Има ли припокриване с други подтипове?
• Подтипът има ли някакви атрибути и/или връзки?
• Всички ли имат свои собствени уникални идентификатори или наследяват един за всички от супертипа?
• Има ли изчерпателен набор от подтипове?
• Подтипът не е ли пример за възникване на обект?
• Знаете ли някакви атрибути, връзки или условия, които отличават този подтип от другите?

Качество на атрибута

Необходимо е да се установи дали това наистина са атрибути, тоест дали те описват тази същност по един или друг начин.

Списък с въпроси за проверка на атрибути:

• Дали името на атрибута е съществително в единствено число, което отразява същността на свойството, обозначено с атрибута?
• Името на атрибута не включва ли името на обекта (не трябва)?
• Един атрибут има ли само една стойност в даден момент?
• Има ли дублирани стойности (или групи)?
• Описани ли са форматът, дължината, приемливите стойности, алгоритъмът за придобиване и т.н.?
• Може ли този атрибут да е липсващ обект, който би бил полезен за друга приложна система (съществуваща или предложена)?
• Възможно ли е той да е пропусната връзка?
• Има ли някъде препратка към атрибут като „функция на дизайна“, която трябва да изчезне при преминаване към ниво приложение?
• Има ли нужда от хронология на промените?
• Значението му само от тази същност ли зависи?
• Ако стойността на атрибута е задължителна, винаги ли е известна?
• Има ли нужда от създаване на домейн за този и подобни атрибути?
• Стойността му зависи ли само от част от уникалния идентификатор?
• Стойността му зависи ли от стойностите на някои атрибути, които не са включени в уникалния идентификатор?

Качество на връзката

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

Списък с контролни въпроси за комуникация:

• Има ли описание за всяка участваща страна, отразява ли то точно съдържанието на комуникацията и отговаря ли на приетия синтаксис?
• Само две страни ли са замесени?

Връзката не е ли преносима?

• Посочена ли е степента на връзка и ангажираност за всяка страна?
• Приемлив ли е дизайнът на връзката?

Дизайнът на връзката един от рядко използваните ли е?

• Не е ли излишно?
• Не се ли променя с времето?
• Ако връзката е задължителна, тя винаги ли отразява връзката с обекта, представляващ противоположната страна?

За изключителна връзка:

• Всички краища на връзките, обхванати от дъгата за изключване, имат ли един и същи тип ангажимент?
• Всички ли се отнасят за едно и също образувание?
• Обикновено дъгите пресичат разклонени краища - какво можете да кажете за този случай?
• Една връзка може да бъде покрита само от една дъга. Така е?
• Всички краища на връзките, обхванати от дъгата, включени ли са в уникалния идентификатор?

Системни функции

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

Ориз. 15. Пример за разлагане

Очевидно операцията по избор и изчисляване на отстъпки може също да бъде разделена на по-малки операции, например изчисляване на отстъпки за ангажимент (клиентът купува стоки с течение на времето) и изчисляване на отстъпки за количеството закупени стоки. Атомните функции са описани подробно, например с помощта на DFD и STD. Очевидно такова описание на функциите не изключва допълнителни вербални описания (например коментари).

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

Изясняване на стратегията

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

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

Изборът на средства за разработка също се изяснява на етап анализ. Поради факта, че етапът на анализ дава по-пълна картина на информационната система, отколкото беше на етапа на определяне на стратегията, работният план може да бъде коригиран. Ако инструментът за разработка, избран на предишния етап, не позволява една или друга част от работата да бъде завършена в дадения срок, тогава се взема решение за промяна на крайните срокове (обикновено увеличаване на периода на разработка) или за промяна на инструмент за разработка. При избора на определени инструменти трябва да вземете предвид наличието на висококвалифициран персонал, който владее избраните инструменти за разработка, както и наличието на администратори на избраната СУБД. Тези препоръки също ще изяснят данните на етапа на избор на стратегия (наборът от условия, при които се очаква да работи бъдещата система).

Ограниченията, рисковете и критичните фактори също са посочени. Ако някакви изисквания не могат да бъдат удовлетворени в информационната система, внедрена с помощта на СУБД и софтуер, избрани на етапа на дефиниране на стратегията, това също инициира изясняване и промени в получените данни (в крайна сметка прогнози за разходите и работни планове и евентуални промени в изискванията на клиента за система, например тяхното отслабване). Функциите, които няма да бъдат внедрени в системата, са описани по-подробно.