Ориз. 6.2.

(Информационна система на предприятието)

Аутсорсинг на корпоративни информационни системи

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

Модели на интеграция на корпоративни информационни системи

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

ФУНКЦИОНАЛНИ ЗАДАЧИ НА ИНФОРМАЦИОННАТА СИСТЕМА НА ПРЕДПРИЯТИЕТО И ОСНОВНИТЕ МОДУЛИ НА СЪВРЕМЕННИТЕ ИНФОРМАЦИОННИ СИСТЕМИ НА ПРЕДПРИЯТИЕТО. ИНТЕГРАЦИЯ НА МОДУЛИ

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

КОНЦЕПЦИЯ, ИСТОРИЯ НА РАЗВИТИЕТО И КЛАСИФИКАЦИЯ НА ПРЕДПРИЯТИТЕЛНИТЕ ИНФОРМАЦИОННИ СИСТЕМИ. ИНТЕГРИРАНИ КОРПОРАТИВНИ ИНФОРМАЦИОННИ СИСТЕМИ НА ПРЕДПРИЯТИЕТО

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

ХАРАКТЕРИСТИКИ НА СЪВРЕМЕННИТЕ ИНФОРМАЦИОННИ ТЕХНОЛОГИИ В ИНФОРМАЦИОННИТЕ СИСТЕМИ НА ПРЕДПРИЯТИЕТО

СЪВРЕМЕННИ ТЕХНОЛОГИИ ЗА ОРГАНИЗИРАНЕ НА ВЪВЕЖДАНЕ НА ДАННИ В КОРПОРАТИВНИ ИНФОРМАЦИОННИ СИСТЕМИИнформацията за бизнес транзакциите трябва да бъде своевременно въведена в оперативната база данни от всички източници на нейното възникване. Това ще ви позволи ефективно да организирате по-нататъшна обработка на данни в информация...
(Информационна система на предприятието)

Въведение

Разглежданата дисертация е написана на базата на Донецка OJSC Донецка фабрика за магазин Cleonelly.

Една от водещите дейности на OJSC Donetsk Manufactory произвежда широка гама от облекла, главно халати, чаршафи и кърпи. Освен това фирмата произвежда и багрени памучни прежди за тъкачно и плетачно производство.

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

Предприятията, занимаващи се с проектиране и разработване на устройства за различни цели, в момента широко използват различни средства както за компютърно проектиране - CAD (CAD), така и за наблюдение на производствените процеси - автоматизирани системи за управление на процеси (SCADA / DCS). Въпреки това, за устройства по ваш собствен дизайн е необходимо да се разработи собствени средстванаблюдение на тяхното представяне и анализ на качеството на продукта.

Технологичният процес на отчитане на продуктите в склад в магазин Cleanelly включва етапа на водене на отчет за продадените продукти.

Целта на този дипломен проект е внедряването на автоматизирана работна станция (АРМ), позволяваща отчитане на продуктите в склад на магазин.

За постигане на горната цел е необходимо да се решат следните задачи:

¾ извършване на анализ на бизнес процесите на магазина;

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

¾ разработва концептуални и логически модели на данни;

¾ се развиват софтуерза автоматизирана работна станция за продуктово отчитане

¾ оценява икономическата ефективност на информационната система.

1 Разработване на софтуерни изисквания

1.1 Анализ на съществуващите решения

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

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

Софтуерната система 1C:Enterprise е предназначена за решаване на широк спектър от проблеми на автоматизацията на счетоводството и управлението, пред които са изправени динамично развиващите се съвременни предприятия. Решаване на текущи счетоводни и управленски проблеми Съставът на програмите на системата 1C:Enterprise е фокусиран върху текущите нужди на предприятията. Компанията 1C произвежда масово произвеждани софтуерни решения, предназначени да автоматизират типични счетоводни и управленски задачи в предприятията. Отличителна черта на циркулационните решения на компанията 1C е внимателното проучване на функционалността, включена в стандартните решения. Компанията 1C анализира опита на потребителите, използващи програми от системата 1C:Enterprise, и следи промените в техните нужди.

Основните предимства на моята система Wholesale Base включват относително ниската цена на внедряване на тази система иИма и редица други предимства:

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

¾ Лесно използване на интерфейса;

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

1.2 Анализ на домейна

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

CASE е предназначен за анализ и реорганизация на бизнес процеси – означава Най-високо ниво All Fusion Process Modeler (BPwin), поддържащ IDEF0 (функционален модел), DFD (Диаграма на потока от данни) и IDEF3 (Диаграма на работния поток) методологии. BPwin е мощен софтуерен продукт за създаване на модели, които ви позволяват да анализирате, документирате и планирате промени в сложни бизнес процеси. BPwin предлага инструмент за събиране на цялата необходима информация за работата на едно предприятие и графично представяне на тази информация под формата на холистичен и последователен модел.

От гледна точка на функционалността на системата. В рамките на методологията IDEF0 (Интеграционна дефиниция за функционално моделиране) бизнес процесът е представен като набор от работни елементи, които взаимодействат помежду си, като също така са показани информационните, човешките и производствените ресурси, изразходвани от всяка работа. Функционалният модел има за цел да опише съществуващите бизнес процеси в едно предприятие (т.нар. AS-IS модел) и идеалното състояние на нещата – към какво да се стремим (TO-BE модел). Методологията IDEF0 предписва изграждането на йерархична система от диаграми, т.е. единични описания на системни фрагменти. Първо се извършва описание на системата като цяло и нейното взаимодействие с външния свят (контекстна диаграма), след което се извършва функционална декомпозиция – системата е разделена на подсистеми и всяка система е описана отделно (декомпозиционни диаграми). След това всяка подсистема се разбива на по-малки и така нататък, за да се постигне желаното ниво на детайлност.

Ако по време на процеса на моделиране трябва да подчертаете специфични аспекти на корпоративната технология, BPwin ви позволява да превключите към DFD или IDEF3 нотация на всеки клон на модела. Диаграмите DFD (Data Flow Diagramming) могат да допълнят това, което вече е отразено в модела IDEF3, тъй като те описват потоците от данни, което ви позволява да проследите как се обменя информация между бизнес функциите в системата. В същото време DFD диаграмите игнорират взаимодействията между бизнес функциите.

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

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

Модел IDEF0. За да проучим бизнес процесите „Формиране на поръчка на доставчик“, „Получаване на стоки“, „Издаване на стоки“, нека разгледаме диаграмите, които са представени под формата на диаграма IDEF0. Системата IDEF0 е представена като набор от взаимодействащи дейности или функции.

Методологията IDEF0 се основава на четири основни концепции.

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

Всяка от четирите страни на функционалния блок има свое специфично значение (роля) и:

Горната страна е настроена на „Контрол“;

Лявата страна е настроена на „Вход“;

Правилната странаима стойност „Изход“;

Долната страна има значението „Механизъм“.

Вторият стълб на методологията IDEF0 е концепцията за интерфейсна дъга (стрелка). Графичното представяне на интерфейсна дъга е еднопосочна стрелка. Всяка интерфейсна дъга трябва да има собствено име (Етикет със стрелка). С помощта на интерфейсни дъги се показват различни обекти, които в една или друга степен определят процесите, протичащи в системата. В този случай стрелките, в зависимост от кое лице на работния правоъгълник влизат или от кое лице излизат, се разделят на:

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

Контролни стрелки (включени в горния край на функционалния блок) - изобразяват правилата и ограниченията, поради които се извършва работата;

Стрелки за изход (излизащи от дясната страна на функционалния блок) - изобразяват данни или обекти, които се появяват в резултат на изпълнение на работа;

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

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

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

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

Нека разгледаме диаграмите на бизнес процесите, протичащи в склада на OJSC DMM, магазин "Cleonelly":

За обща видимост на системата е необходимо да се изгради контекстът „Дейности на корпоративния склад“ (виж Фигура 1.1).

Фигура 1.1 – Диаграма „Дейности на склада на предприятието“

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

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

Фигура 1.2 – Диаграми на разлагане на първо ниво

Фигура 1.3 – Диаграма „Дизайн на продукта“

Фигура 1.4 – Диаграма „Освобождаване на стоки“

Фигура 1.5 – Диаграма „Получаване на стоки“

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

Основните компоненти на диаграмата на потока от данни са:

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

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

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

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

Разгледайте диаграмата на потока от данни (DFD) „Издаване на стоки“, Фигура 1.6. Тази диаграма показва движението на документи, когато организацията получи „заявка за стоки“.

Фигура 1.6 – DFD диаграма „Издаване на стоки“

Разгледайте следната диаграма на потока от данни „Разрешение на продукта“ (вижте Фигура 1.7). Той показва процеса на извършване на работа и движението на документи по време на „освобождаване на стоки“.

Фигура 1.7 – DFD диаграма „Регистриране на продукт“

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

Организационната структура на предприятие, занимаващо се с продажба на хавлиени продукти, се разглежда на примера на компанията OJSC „Donetsk Manufactory M“ на магазина Cleonelly:

В посока на разработване на системи за контрол и отчитане на материалите могат успешно да се решат следните проблеми:

1. Това е контрол върху стоките, доставяни и съхранявани в склада.

2. Информация за доставчици и потребители

3. Също така съдържа информация и операции на продукта

4. Съдържа дневник на отчета за освободени стоки

5. Съдържа продуктова директория

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

7. Регистриране и съхранение на фактури за закупени и продадени стоки и услуги, както и издаване на фактури за предплащане, разсрочено плащане и доставка на стоки

8. Създаване на фактури и осчетоводяване на издадени стоки

9. Извършване на инвентаризация на складове със създаване на съвпадащ лист, декларация за липси и излишъци

10. Създаване на продуктови пакети

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

1.3 Изисквания за събиране

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

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

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

¾ документиране на резултатите.

¾ Информационната система трябва да бъде реализирана като програма, базирана на интегрирана среда Visual Fox Pro.

Програмата работи под операционна система Windows 2000/NT/XP.

Има четири основни етапа в процеса на разработване на изискванията (Фигура 1.8):

Анализ на техническата възможност за създаване на система;

Формиране и анализ на изискванията;

Уточняване на изискванията и създаване на съответната документация;

Изисквания за сертифициране.

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

1.4 Спецификация на изискванията

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

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

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

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

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

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

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

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

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

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

1.5 Валидиране на изискванията

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

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

1. Проверка на коректността на изискванията.

2. Проверка за последователност.

3. Проверете за пълнота.

4. Проверка за осъществимост.

Има редица методи за сертифициране на изискванията, които могат да се използват заедно или поотделно:

1. Преглед на изискванията.

2. Прототипиране.

3. Генериране на тестови сценарии.

4. Автоматизиран анализ на консистенцията.

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

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

Следващата стъпка в валидирането на изискванията е действителното създаване на прототипи.

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

Прототип на главното меню на този модулпредставени на фигура 1.9.

1.6 Избор на методология за проектиране на информационна система

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

Всички най-разпространени методологии на структурен подход се основават на редица основни принципи. Следните принципи се използват като два основни принципа:

Принципът на „разделяй и владей“ е принципът за решаване на сложни проблеми чрез разделянето им на много по-малки независими проблеми, които са лесни за разбиране и разрешаване;

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

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

SADT (Structured Analysis and Design Technique) модели и съответните функционални диаграми;

DFD (Data Flow Diagrams) диаграми на потока от данни;

ERD (Entity-Relationship Diagrams) диаграми на същност-връзка.

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

Изброените модели заедно дават Пълно описание IP независимо дали е съществуващ или новоразработен. Съставът на диаграмите във всеки конкретен случай зависи от необходимата пълнота на описанието на системата.

2 ПРОЕКТИРАНЕ НА ИНФОРМАЦИОННА СИСТЕМА

2.1 Архитектурен дизайн

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

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

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

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

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

¾ съсредоточаване върху мисията на организацията;

¾ съсредоточаване върху изискванията;

¾ фокус върху развитието;

¾ способност за адаптиране;

¾ необходимостта от гъвкавост.

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

Основен софтуерни архитектури, изпълнявани в момента са:

¾ файлов сървър;

¾ клиент-сървър;

¾ многостепенни.

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

Клиентски сървър. Тази концепция се основава на идеята, че в допълнение към съхраняването на файловете на базата данни, централен сървър трябва да извършва по-голямата част от обработката на данни. Потребителите имат достъп до централния сървър, използвайки специален език структурирани заявки(SQL, Structured Query Language), който описва списъка от задачи, изпълнявани от сървъра. Потребителските заявки се приемат от сървъра и генерират процеси за обработка на данни в него. В отговор потребителят получава вече обработен набор от данни. Не целият набор от данни се прехвърля между клиента и сървъра, както се случва във файлово-сървърната технология, а само данните, от които клиентът се нуждае. Потребителска заявка, която е дълга само няколко реда, може да генерира обработка на данни, която обхваща множество таблици и милиони редове. В отговор клиентът може да получи само няколко номера. Технологията клиент-сървър ви позволява да избегнете предаването на огромни количества информация по мрежата, като прехвърлите цялата обработка на данни към централен сървър. В допълнение, разглежданият подход ни позволява да избегнем конфликти между промените на едни и същи данни от множество потребители, които са типични за файловата сървърна технология. Технологията клиент-сървър прилага координирана модификация на данни от множество клиенти, като гарантира автоматично съответствие с целостта на данните. Тези и някои други предимства направиха технологията клиент-сървър много популярна. Недостатъците на тази технология включват високи изисквания за производителност на централния сървър. Колкото повече клиенти имат достъп до сървъра и колкото по-голям е обемът на обработваните данни, толкова по-мощен трябва да бъде централният сървър.

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

2.2 Проектиране на интерфейса на информационната система

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

набор от потребителски задачи, които той решава с помощта на системата;

системни контроли;

навигация между системните блокове;

визуален дизайн на програмни екрани.

Нека подчертаем някои от най-значимите предимства на добрия потребителски интерфейс от бизнес гледна точка:

намаляване на броя на потребителските грешки;

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

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

подобряване на морала на персонала;

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

наличие на функционалност на системата за максимален брой потребители.

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

2.2.1 Потребителски интерфейс на управляващата програма

Основният модул на „Workstation Wholesale Base“ е модулът Luck.exe, който осигурява изпълнението на основната функционалност на диаграмата на случаите на използване, представена на фигура 1.9 от раздел 1.4.

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

Програмен интерфейс, административна част:

1. начална форма на програмата. Тази форма се стартира при стартиране на софтуерния продукт, като по този начин се формира началото на диалог между потребителя и системата (Фигура 2.3);

2. форма на администратор. В тази форма се извършва пълен контролинформационна система, т.е. добавяне, изтриване, промяна на данни в базата данни, както и, ако е необходимо, преглед и отпечатване на отчети (Фигура 2.4);

3. Форма “Клиенти”, благодарение на тази форма можете да видите пълна информацияза клиентите на предприятието (Фигура 2.7);

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

Потребителска част на програмния интерфейс:

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

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

В меню баланси се отчитат наименованията на продуктите, съхранявани в склада.

В меню Каса тук се съхранява информация за входящи и изходящи касови ордери (екранни снимки)

2.2.2 Потребителски интерфейси на контролните компоненти

Фиг. 2.0 Главно меню на програмата

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

Фигура 2.1 Прозорец на менюто за пристигане или складова разписка.

Фигура 2.2 Прозорец на менюто на потока

Фигура 2.2 Прозорец на менюто, регулиращ правата за достъп до програмата.

Фигура 2.3 Прозорец на менюто с оставащ елемент.

Фигура 2.4 Прозорец на менюто на касата.

Фигура 2.4 Прозорец на менюто за преоценка.

2.3 Дизайн на база данни

ERwin 4.0 от Computer Associates Int беше използван за проектиране на базата данни.

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

ERwin - не само най-добрият инструментза проектиране на бази данни, но и инструмент за тях бързо създаване. ERwin оптимизира модела според физическите характеристики на целевата база данни. За разлика от други инструменти, ERwin автоматично поддържа съгласуваност между логически и физически дизайн и превежда логически конструкции, като например връзки много към много, в тяхната физическа реализация. Улеснява дизайна на бази данни. За да направите това, достатъчно е да създадете графичен E-Rмодел (обектна връзка), който отговаря на всички изисквания за данни и въведете бизнес правила, за да създадете логически модел, който показва всички елементи, атрибути, връзки и групи. Erwin има две нива на моделно представяне - логическо и физическо. Логическото ниво е абстрактен изглед на данните, където данните се представят така, както изглеждат в реалния свят и могат да бъдат наречени така, както се наричат ​​в реалния свят, например „Редовен клиент“, „Отдел“ или „Служител“ Фамилия". Обектите на модела, представени на логическо ниво, се наричат ​​обекти и атрибути. Логическото ниво на модела на данните е универсално и по никакъв начин не е свързано с конкретна реализация на СУБД. Има три поднива на логическото ниво на модела на данни, които се различават по дълбочината на представяне на информацията за данните:

Диаграма на връзките между обекти (ERD);

Модел на данни, базиран на ключове (Key Based model (KB));

Модел с пълно приписване (FA)

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

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

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

Физическият модел на данни е представен в Приложение B.

2.4 Обосновка за избор на платформа за създаване на информационна система

Visual FoxPro е визуална среда за разработка на системи за управление на релационни бази данни, произвеждани в момента от Microsoft. Последна версияе 9.0. Използва езика за програмиране FoxPro. Версия на системата 7.0 може да работи на операционни системи с ядро ​​на Windows 9x и NT, версии 8.0 и 9.0 - само на Windows XP, 2000, 2003.

FoxPro (Fox-pro?) е един от диалектите на езика за програмиране xBase. Използва се главно за разработването на релационни СУБД, въпреки че може да се използва за разработването на други класове програми.Както беше отбелязано по-горе, езикът VFP е силно допълнен и разширен xBase език. Във Visual FoxPro езикът за програмиране, тоест основната конструкция на езика, е концепцията за клас. Оригиналната версия на xBase е чист структурен език с основна концепция за процедури и функции. По този начин модерният език за програмиране Visual FoxPro ви позволява да комбинирате както програмирането по „старомодния начин“, като описвате маса от процедури, така и в OOP стил, създавайки сложна йерархия от класове.

Избрах този език за програмиране, защото съдържа редица от следните предимства:

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

Модерна организация релационни бази данниданни, което ви позволява да съхранявате информация за таблиците на базата данни, техните свойства, индекси и връзки и да задавате условия за съответствие референтна цялост, създаване на локални и отдалечени изгледи (Views), връзки със сървъри, запомнени процедури, изпълнявани при настъпване на повече от 50 различни вида събития (VFP 7.0-9.0).

Висока скоростработа с големи бази данни.

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

Висока скорост на разработка на приложения с помощта на Wizards, Designers, Builders, режим на подсказка IntelliSense при писане на програмен текст, отстраняване на грешки и системи за тестване.

Възможност за разработване на приложения, използващи технология клиент-сървър с данни, хоствани на сървъри за бази данни на Oracle и Microsoft SQL сървъри с други Microsoft приложения Windows, използващ ODBC и OLE

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

2.5 Дизайн на модула

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

Като пример ще разгледам дизайна на модул, който прилага случая на използване „Попълва заявление за прием“.

Първо, нека опишем потока от събития, които се случват в този случай на употреба.

Предпоставка за use case е получаването на заявка от клиента.

5. Случаят на използване започва, когато клиентът изпрати заявка.

6. Мениджърът отваря формуляра Разписка.

7. Управителят определя датата на заявлението.

8. Мениджърът поставя името на продукта.

9. Мениджърът въвежда количеството на входящата стока.

10. Мениджърът въвежда сумата на заявката.

11. Мениджърът затваря формата.

12. Случаят на използване приключва.

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

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

3 Внедряване и сертифициране на информационната система

3.1 Реализация на приложението

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

В този случай приложението е реализирано в Microsoft Visual FoxPro.

Основните функции на системата ще бъдат описани по-долу:

1. Стартова форма на системата. Тази форма е форма на бутон и съответно всеки бутон изпълнява своя функция. Бутонът за регистрация на администратор е показан на Фигура 3.1 Този бутон ще изпълнява функция, която отваря администраторския панел, ако потребителят има такива права за тази система

2. Бутон на менюто за пристигане. Този бутон ви позволява да следите входящите стоки в склада на магазина (фиг. 3.2).

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

4. В бутона на менюто за достъп се регулират правата за използване на тази програма (фиг. 3.4).

5. Бутонът на менюто „остатъци“ съхранява информация за материалите, съхранявани в склада на магазина (фиг. 3.5).

6. Бутонът на менюто на касата съхранява информация за входящи касови ордери и изходящи касови ордери (фиг. 3.6).

7. В бутона на менюто за преоценка цената се променя на новата цена на продукта (фиг. 3.7).

Фигура 3.1 – Стартова форма на системата

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

Фигура 3.3– Формуляр за отчитане на продадените стоки.

Фигура 3.4 – Формуляр, регулиращ правата за достъп до програмата.

Фигура 3.5 – Форма на оставащите стоки в склада.

Фигура 3.5–Формуляр за входящи касови ордери и изходящи касови ордери.

Фигура 3.6—Форма на транзакции за стоки.

Тестване на приложения

Тестването е процес на изпълнение на програма с цел откриване на грешки. Тестването осигурява:

Откриване на грешки;

Демонстриране на съответствието на функциите на програмата с нейното предназначение;

Демонстрация на изпълнение на изискванията за изпълнение на програмата;

Показване на надеждността като индикатор за качество на програмата.

Фигура 3.2 показва информационните потоци на процеса на тестване.

Има три потока на входа на процеса на тестване:

Програмен текст;

Изходни данни за стартиране на програмата;

Очаквани резултати.

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

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

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

Има 2 принципа на тестване на програмата:

Функционално тестване (черна кутия тестване);

Структурно тестване (тестване на бяла кутия).

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

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

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

Тестването на черна кутия търси следните категории грешки:

Неправилни или липсващи функции;

Грешки в интерфейса;

Грешки във външни структури от данни или при достъп до външна база данни;

Характерни грешки (необходим капацитет на паметта и др.);

Грешки при инициализация и прекратяване.

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

На етапа на тестване се решават две основни задачи:

Тестване на решението - тестовите планове, създадени по време на етапа на планиране и разширени и тествани по време на етапа на разработка, се изпълняват;

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

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

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

На този етап от развитието на информационната система е необходимо да се проведат следните видове тестове:

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

Тестването за използваемост е тестване на високо ниво, извършвано от тестера и бъдещите потребители на продукта. Използва се методът "черна кутия".

Алфа и бета тестване – В условията на MSF, алфа кодът е основно целият изходен код, произведен по време на фазата на разработка на модела на процеса на MSF, а бета кодът е кодът, който е тестван по време на фазата на тестване. Следователно по време на фазата на разработка на модела на процес MSF се тества алфа кодът, а по време на фазата на тестване се тества бета кодът.

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

Тестването на производителността е насочено към проверка дали приложението отговаря на изискванията за производителност и ниво на комфорт на скоростта.

Тестване на документация и помощна система– всички разработени съпътстващи документи и помощни системи са тествани.

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

Планът на процеса на пилотна експлоатация на разработваната информационна система е показан в таблица 3.2.

Таблица 3.2 – План за пилотна експлоатация

Действие		Описание
1. Избор на критерии за успех		Разработчикът и участниците в пилотното тестване определят критериите за успех и се съгласяват с тях
2. Избор на потребители и място за инсталиране		Формира се екип от участници в пилотно тестване от потребители и разработчици. Определя се местоположението на пилотния процес.
3. Подготовка на потребителите и място за монтаж		Извършва се обучение на потребители - участници в теста. Подготвя се мястото за монтаж.
4. Внедряване на прототипната версия		Пробната версия е инсталирана и пусната в експлоатация.
5. Поддръжка и наблюдение на пробната версия		Наблюдение на работата на потребителите и системата, оказване на помощ при работа, събиране на информация за работата на системата
6. Обратна връзка от потребителите и оценка на резултатите		Потребителите изразяват мнението си за работата на системата, посочват недостатъци и грешки.
7. Изменения и допълнения	Откритите грешки се коригират и се правят промени в дизайна или процеса. Коригираните резултати се предоставят на потребителите за работа и оценка.
8. Решения за разполагане	Ако резултатите от пилотното тестване удовлетворяват потребителите, се взема решение за внедряване на системата.

3.2 Методология за внедряване на приложение

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

Цели на фазата на внедряване:

¾  прехвърляне на решението в индустриална среда;

¾  признаване от клиента на завършването на проекта.

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

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

За внедряване на разработваната система е изготвен план за действие, който е показан в таблица 3.1.

Таблица 3.1 – План за внедряване на приложението

Действие	Описание на действието
1. Архивиране	Произведено архивиранепотребителски данни с негово участие и одобрение чрез прехвърляне на информация на преносим носител (CD, DVD)
2. Инсталиране на основните компоненти на решението	Прилагане на технологии за осигуряване на работата на решението. В този случай инсталирането на компонента Visual FoxPro
3. Инсталиране на клиентското приложение	Прехвърляне към компютъра на потребителя и инсталиране на окончателната версия на разработената ИС и база данни
4. Обучение	Потребителите са обучени да работят със системата, разработчикът се грижи клиентите да разбират правилно работата на ИС и
5. Трансфер на базата от знания на проекта към клиента	Цялата проектна документация се прехвърля на клиента
6. Затваряне на проекта	Изготвя се доклад за приключване на проекта. Клиентът подписва сертификата за приемане.

За нормалното функциониране на автоматизираното работно място е необходимо операционна система Microsoft Windows XP.

4 Управление информационен проект

4.1 Избор на жизнен цикъл на разработка

Една от основните концепции на методологията за проектиране на ИС е концепцията за жизнения цикъл на софтуера (SW life cycle). Жизненият цикъл на софтуера е непрекъснат процес, който започва от момента на вземане на решение за необходимостта от неговото създаване и завършва в момента на пълното му изтегляне от експлоатация.

Основен нормативен документ, регламентиращ жизнения цикъл на софтуера е международният стандарт ISO/IEC 12207 (ISO – Международна организация по стандартизация, IEC – Международна електротехническа комисия). Той определя структурата на жизнения цикъл, съдържаща процесите, дейностите и задачите, които трябва да бъдат изпълнени по време на създаването на софтуера.

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

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

Спирален модел (виж Фигура 4.1);

Итеративен модел.

Фигура 4.1 – Спирален модел на жизнения цикъл на софтуера

Да се ​​създаде информационна система, т.е. „Автоматизирано работно мястоскладов служител депо на едро”, беше избран итеративният. Отличителна черта на итеративния модел е, че той е формален метод, състои се от независими фази, извършвани последователно, и подлежи на често преразглеждане (Фигура 4.2). Итеративният подход се е доказал добре при изграждането на информационни системи, за които в самото начало на разработката всички изисквания могат да бъдат формулирани доста точно и напълно, за да се даде свободата на разработчиците да ги прилагат възможно най-добре от техническа гледна точка на гледка.

Предимства на итеративния модел:

Моделът е добре познат на потребители и крайни потребители, които не са разработчици на софтуер.

Удобство и лекота на използване, т.к цялата работа се извършва на етапи (според фазите на модела);

Стабилност на изискванията;

Моделът е лесен за разбиране;

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

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

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

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

Фигура 4.2 – Итеративен модел на жизнения цикъл на софтуера

Фази на модела:

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

На етапа на проектиране системните процеси се разглеждат по-подробно. Функционалният модел се анализира и при необходимост се коригира. Изграждат се прототипи на системи;

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

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

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

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

Анализ на отличителните категории на проекта, поставени в таблиците.

Отговорете на въпросите, зададени за всяка категория, като подчертаете думите „да“ и „не“.

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

Екип за развитие. Въз основа на възможностите, подборът на персонал за екипа за разработка се извършва дори преди да бъде избран моделът на жизнения цикъл на разработката на софтуер. Характеристиките на такъв екип (вижте Приложение G, Таблица G.1) играят важна роля в процеса на избор на модел на жизнения цикъл, това означава, че екипът може да предостави значителна помощ при избора на модел на жизнения цикъл на софтуерен продукт, тъй като отговаря за успешното внедряване на разработения модел на жизнения цикъл.

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

4.2 Определяне на целта и обхвата на софтуерен проект

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

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

За да се определи обхватът на даден софтуерен продукт, по-долу ще бъде описано какво трябва или не трябва да бъде софтуерният проект.

Софтуерният проект трябва да бъде:

За вътрешна употреба в организацията;

Проект за многопотребителски достъп;

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

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

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

Проект, който ще генерира външно отчитане.

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

За да създадете уникален продукт или услуга (резултат от проекта), трябва да извършите определена последователност от работа. Задачата на планирането на проекта е да се изчисли точно времето и цената на тези работи. Колкото по-точна е оценката, толкова по-високо е качеството на плана на проекта. За да дадете точна оценка, трябва да разбирате добре обхвата на работата по проекта, тоест да знаете точно каква работа трябва да бъде извършена, за да получите резултата. Само след като списъкът е съставен проектантска работа, като се определя продължителността на всеки от тях и се разпределят необходимите ресурси за изпълнението им. И едва след това можете да оцените разходите и времето за всяка задача и, в резултат на добавянето, общата цена и продължителност на проекта. Ето защо определянето на обхвата на работата е първата стъпка в планирането на проекта. Определянето на обхвата на проектантската работа започва с определяне на етапите (или фазите) на проекта. Например в проект за създаване на система „Отчитане на стоките в склад“ могат да се разграничат следните фази:

Разработване на софтуерни изисквания;

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

Внедряване и сертифициране на информационната система;

Внедряване на системата.

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

Оперативният списък от работи (Фигура 4.3) е проектиран с помощта на софтуерен продукт като MS Project 2003.

Фигура 4.3 – Оперативен списък на работите

4.4 Оценка на продължителността и разходите за разработка на софтуер

Оценка на продължителността.Определя се след изграждането на оперативен списък от работи (Фигура 4.3, параграф 4.3). Тази оценка на продължителността може да се види с помощта на диаграмата на Гант (Приложение К).

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

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

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

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

Оценка на разходите

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

Важно свойство на ресурсите е цената (Cost) на тяхното използване в проекта. В MS Project има два вида разходи за ресурси: времева ставка и цена за използване.

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

В този случай е използвана времева норма (Фигура 4.4) Общите разходи за използване на ресурси могат да се видят на Фигура 4.5.

Фигура 4.4 – Времева норма за използване на ресурсите

На тази фигура можете да видите, че разработчикът на системата получава 50 рубли на час при завършване на проект; бизнес анализатор получава 45 рубли на час, тестер 38 рубли на час. Ставките за извънреден труд не се вземат предвид.

Фигура 4.5 – Общи разходи за използване на ресурсите на проекта

4.5 Разпределение на ресурсите на проекта

Фрагмент от разпределението на ресурсите за системата „Счетоводство на стоки в склад“ може да се види на Фигура 4.6

Фигура 4.6 – Фрагмент от разпределението на ресурсите на проекта

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

4.6 Оценка на икономическата ефективност на проекта

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

Входни данни.

Допълнителна печалба от проекта (DP) = 38 000 рубли. Допълнителна печалба прогнозираха експертите на компанията.

Първоначална инвестиция (IC) = 39 396,47 рубли. Началните инвестиции съответстват на общите разходи за използване на ресурсите на проекта (Фигура 4.5, параграф 4.6)

Сконтов процент (i) = 12%.

Продължителност, за която е проектиран проектът (n) = 2 години.

Допълнителна печалба от проекта (DP) = 38 000 рубли.

Годишни разходи за изпълнение на проекта (Z 1) = 15 000 рубли.

Годишни разходи за изпълнение на проекта (Z 2) = 10 000 рубли.

Годишни парични постъпления (R 1) = 23 000 рубли.

Годишни парични постъпления (R 2) = 28 000 рубли.

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

Централен показател в разглеждания метод е показателят NPV (net present value) – текущата стойност на паричните потоци. Това е обобщеният краен резултат от инвестиционната дейност в абсолютно изражение.

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

Нетната настояща стойност (NPV) се изчислява по формула 4.2

(4.2)

R k – годишни парични постъпления за n години.

k – броят години, за които е проектиран проектът.

IC – първоначална инвестиция.

i – сконтов процент.

Според изчисленията на тази формула NPV = 3460,67 рубли

Индикаторът NPV е абсолютно увеличение, тъй като оценява доколко настоящият доход покрива настоящите разходи. Тъй като NPV > 0, проектът трябва да бъде приет.

Възвръщаемостта на инвестициите (ROI) се изчислява по формула 4.3

(4.3)

Според изчисленията (ROI) = 108,78%

Таблица 4.1  Помощна таблица за изчисляване на периода на изплащане на проекта

= 1,84

Период на изплащане n ok = 1,84 години (1 година и 11 месеца)

Тъй като ROI = > 100% (а именно = 108,78%), проектът се счита за печеливш.

(4.4)

По този начин индексът на рентабилност е равен на (PI) =1,2

Взаимовръзка на информационните подсистеми на предприятието

Как са свързани? Информационни системив рамките на предприятието? Обичайният начин за Руска компаниясреден - започва внедряване на информационни технологии с автоматизация на счетоводния отдел, отдел човешки ресурси и документооборот. Данните на тези системи са най-формализирани, процесите се автоматизират лесно. Широко разпространените пакети „1C: Счетоводство“, „Шеф: Служител по персонала“, „LanDocs“, „LanStaff“, „Заплата“ и др. Ви позволяват да се разширите с всякакви приложения и по този начин да ги интегрирате в цялостната информационна система на предприятие. Ориз. Фигура 7.1 показва как модулите на информационната система на една компания са свързани помежду си. TPS модулът обслужва основните производствени и поддържащи процеси и обикновено е основният източник за други информационни модули. ESS е основният получател на данни и вътрешни системи от външната среда.

Ориз. 7.1.

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

Връзки между DSS и TPS, KWS,

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

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

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

Компанията се разраства бързо през 2006 г., когато е придобита част от стария завод и започва развитието на втората територия. Естествено възникна задачата двете територии да бъдат обединени в едно информационно поле. Започнахме със създаването на VPN мрежа, но когато броят на потребителите се увеличи, честотна лентаканалът не беше достатъчен. Тогава между двете територии беше прекаран оптичен кабел.

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

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

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

От счетоводството до производството

Първата стъпка към автоматизацията беше придобиването през 2002 г. на продукта 1C: Accounting 6.0 и системата Compass CAD от Ascon. Следващата стъпка беше автоматизацията на производствените дейности. Компанията Rarus NN, по искане на предприятието, започна адаптирането на ERP системата „1C: Manufacturing Enterprise Management 8“ („1C: UPP 8“) към нуждите и характеристиките на предприятието. Целта на проекта беше изграждане на единна база данни и управление на всички бизнес процеси на базата на единна информационна система. Решаващ фактор за успеха на неговото изпълнение беше пряката подкрепа на висшето ръководство на предприятието - генералния директор, който инициира и подкрепя проекта на всичките му етапи.

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

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

Служителите на ИТ отдела разработиха модул за „1C: UPP 8“ за импортиране на „дървото“ на продукта от системата „Компас“, която се използва от дизайнерите на компанията. Алгоритъмът на работа е следният: проектантското бюро с помощта на Compass разработва чертеж и създава 3D модел на обекта, след което структурата на продукта се импортира в ERP системата с помощта на разработения модул, след което се изгражда продуктова спецификация въз основа на импортираните данни. Ако дизайнерите направят промени в който и да е възел, тези промени автоматично се отразяват във всички системи.

Първоначално, както призна Ганин, той и неговите специалисти искаха сами да създадат система за управление на инженерни данни, но скоро разбраха, че групата компании Appius, партньор на 1C, разработва собствено репликируемо PDM решение (то се нарича „ 1C: PDM управление на инженерни данни ").

Обратна връзка

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

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

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

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

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

„Това е универсално решение и не изисква работници компютърна грамотност, отбелязва Ганин. „Автомобилът е основният и най-скъп компонент от нашето производство; намаляването на времето за престой ни позволи драстично да ускорим изпълнението на поръчките.“ Предприятието вече разполага с удобен и прост инструмент за анализ на загубите: системата автоматично генерира работни диаграми за всяко превозно средство, което ви позволява да проследите кога е започнала работата по тази колакога е свършила, колко дълго е стояла колата в очакване на следващата операция. Ако допустимото време е превишено, започваме да откриваме причините и да търсим виновниците за толкова дълъг престой. В резултат на това се увеличи личната отговорност на изпълнителите.

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

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

Важно е да се подчертае, че компанията е поела по пътя на експанзия

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

За да управлява архива на проектната документация, предприятието внедри системата за управление на инженерни данни 1C: PDM (разработена от Appius Group) и я интегрира с 1C: UPP 8. В допълнение към работата по създаването на нови продукти, системата за управление на инженерни данни се планира да се използва за по-точно изчисляване на себестойността на продуктите.

Многото лица на интеграцията

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

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

„Също така планираме да внедрим решение, базирано на „1C: UPP 8“ за взаимодействие с КАТ, подготовка и отпечатване на PTS, транзитни номера“, отбелязва Ганин. - Всички данни ще бъдат групирани на едно място за съхранение на информация - карта на автомобила, където ще се въвеждат всички негови идентификационни номера, цвят, номер на каросерията и др., след което тези данни ще се използват в техническите спецификации, при печат на PTS, номера справка фактури" Такава интеграция ще даде възможност на клиентите на компанията да получават готови PTS и транзитни номера заедно с автомобила, което ще позволи бързото регистриране на автомобили в КАТ.

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

В съответствие с дефиницията функционалните елементи на ИС са следните групи (блокове) от процеси:

въвеждане на информация от външни или вътрешни източници;

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

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

Обратната връзка е информация, обработвана от хора от дадена организация, за да се коригира въведената информация.

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

Отделни части (системни блокове) се наричат ​​подсистеми.

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

Структурата на ИС може да се представи и като комплекс от поддържащи подсистеми (фиг. 2).

Фиг. 1. Обобщена функционална блокова схема на ИС.

Въпреки това, за AIS, които се различават по естеството и видовете обработка на информацията, функционалната диаграма се различава в набора от подсистеми за обработка. Например AIPS (библиотека, музей, правна справка и др.) въвеждат, систематизират, съхраняват, търсят и издават информация по заявка на потребителя без сложни трансформации на данни. Информационни системи за вземане на решения: ASOD, ACS, DSS - обработват информацията от базата данни по определен алгоритъм, но те също се различават по състава на подсистемите за обработка на информация. CAD, специализиран в автоматизацията на проектирането, има специални подсистеми в своята структура: техническа документация, генериране на задачи, симулационно моделиране, изчисление, а в някои може да има експертна система (вижте блоковата схема на фиг. 2).

Фиг.2. CAD блокова схема

Нека разгледаме друг вид структура на ИС: като комплекс от поддържащи подсистеми (фиг. 3).

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

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

Фиг.3. Структура на ИС по видове поддържащи подсистеми.

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

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

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

към единни системи за документация;

към унифицирани форми на документи на различни нива на управление;

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

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

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

изключително голям обем документи за ръчна обработка;

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

работи с голяма сумадокументите отвличат вниманието на специалистите от решаването на непосредствени проблеми;

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

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

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

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

изключване на дублирана и неизползвана информация;

класификация и рационално представяне на информацията.

Методология за изграждане на база даннисе основава на теоретичните основи на тяхното проектиране.

Основни понятия на методиката:

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

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

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

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

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

създаване на информационни масиви на компютърни носители, което изисква съвременна техническа поддръжка.

Практически тази концепция се реализира на два етапа.

Етап 1 – проверка на всички функционални подразделения на компанията с цел:

разбира спецификата и структурата на своята дейност;

изградете диаграма на информационните потоци;

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

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

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

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

Комплексът от технически средства се състои от:

компютри от всякакви модели;

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

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

офис оборудване и устройства за автоматично извличане на информация;

експлоатационни материали и др.

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

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

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

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

Към днешна дата са се появили две основни форми на организиране на техническа поддръжка (форми на използване на технически средства): централизирана и частично или напълно децентрализирана.

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

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

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

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

Към средствата софтуеротнасям се:

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

типични управленски задачи;

методи на математическо програмиране, математическа статистика, теория на масовото обслужване и др.

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

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

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

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

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

Организационната поддръжка изпълнява следните функции:

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

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

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

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

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

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

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

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

състояние на информационната система;

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

процедура за създаване и използване на информация и др.

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

Цели на създаване и внедряване на IP.

Какво можете да очаквате от внедряването на информационни системи?

Въвеждането на информационни системи може да допринесе за:

1. освобождаване на работниците от рутинната работа и ускоряването й чрез автоматизация;

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

3. подобряване на структурата на информационните потоци и системата за документооборот във фирмата поради системния ефект: еднократно въвеждане на данни - многократно и многоцелево използване”;

4. получаване на по-рационални възможности за решаване на управленски проблеми (чрез въвеждане на математически методи и интелигентни системи и др.):

намиране на нови пазарни ниши;

оптимизиране на разходите за производство на продукти и/или услуги;

оптимизиране на взаимоотношенията с клиенти и доставчици.

Етапи на развитие на информационните системи

Историята на развитието на IP е разделена на етапи (Таблица 2), съответстващи приблизително на приетото номериране на целите - подходът към използването на IP се променя.

Таблица 2. Етапи на развитие на ИС.

Период от време	Концепция за използване на информация	Тип информационни системи	Предназначение
1950 – 1960 г	Хартиенопоток на сетълмент документи	Информационни системи за обработка на сетълмент документи на електромеханични счетоводни машини	Увеличаване скоростта на обработка на документи Опростяване на обработката на фактури и заплати
1960 – 1970 г	Основна помощ при изготвяне на справки	Управленски информационни системи за производствена информация	Ускоряване на процеса на докладване
1970 – 1980 г	Управленски контрол на продажбите (продажби)	Системи за подпомагане на вземането на решения Системи за висш мениджмънт	Вземане на проби от най-рационалното решение
1980 – 2000 г	Информацията е стратегически ресурс, който осигурява конкурентно предимство	Стратегически информационни системи Автоматизирани офиси	Оцеляване и просперитет на компанията

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

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

През 70-те - началото на 80-те години. Информационните системи започват да се използват широко като средство за управленски контрол, подпомагащо и ускоряващо процеса на вземане на решения.

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

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