Въведение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

¾ Лесна употреба на интерфейса;

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

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

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

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

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

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

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

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

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

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

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

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

Горната страна е Control;

Лявата страна е настроена на "Input";

Дясната страна е настроена на Изход;

Недостатъкът е „Механизъм”.

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

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

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

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

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

Третата основна концепция на стандарта 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 "Освобождаване на стоки"

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

Организационната структура на предприятие, продаващо хавлиени продукти, е разгледана на примера на Донецк Мануфактура М, магазин Cleonelly:

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

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

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

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

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

5. Съдържа директория със стоки

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Удостоверяване на изискванията.

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

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

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

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

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

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

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

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

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

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

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

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

1.5 Атестация на изискванията

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

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

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

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

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

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

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

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

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

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

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

Прототипирането е най-видимо за клиента на системата.

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

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

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

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

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

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

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

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

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

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

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

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

ERD (Entity-Relationship Diagrams) диаграми на взаимоотношения на обекти.

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

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

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

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

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

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

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

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

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

¾ фокус върху мисията на организацията;

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

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

¾ способността за адаптация;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ето някои от най-важните бизнес ползи от добрия потребителски интерфейс:

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

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

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

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

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

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

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

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

Основният модул на "AWP 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 има две нива на представяне на модела - логическо и физическо. Логическият слой е абстрактен изглед на данните, върху него данните се представят така, както изглеждат в реалния свят, и могат да бъдат извикани така, както се наричат \u200b\u200bв реалния свят, например „Лоялен клиент“, „Отдел“ или „Фамилия на служителя“. Обектните модели, които са представени на логическо ниво, се наричат \u200b\u200bобекти и атрибути. Логическото ниво на модела на данни е универсално и няма нищо общо с конкретна реализация на СУБД. Има три поднива на логическото ниво на модела на данните, които се различават по дълбочината на представяне на информация за данните:

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

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

Напълно приписан модел (FA).

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

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

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

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

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.

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

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

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

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

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

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

2.5 Проектиране на модули

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

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

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

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

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. Обучение	Потребителите са обучени да работят със системата, разработчикът е убеден в коректността и разбирането на работата на IP от клиентите
5. Прехвърляне на базата от знания по проекта на клиента	Цялата документация по проекта се предава на клиента
6. Затваряне на проекта	Изготвя се доклад за приключване на проекта. Клиентът подписва сертификата за приемане.

За нормалното функциониране на AWP е необходима операционната система Microsoft WindowsXP.

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

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

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

Основният нормативен документ, регулиращ жизнения цикъл на софтуера, е международният стандарт 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 диаграмата на Гант е основният инструмент за визуализация на плана на проекта. Тази диаграма представлява графика с хоризонтална времева линия и вертикален списък със задачи. В този случай дължината на сегментите, обозначаващи задачи, е пропорционална на продължителността на задачите.

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

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

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

Важно свойство на ресурсите е разходите (разходите) за тяхното използване в проекта. В 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) \u003d 38 000 рубли. Допълнителна печалба прогнозираха експертите на компанията.

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

Дисконтов процент (i) \u003d 12%.

Периодът, за който е проектиран проектът (n) \u003d 2 години.

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

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

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

Годишни касови бележки (R 1) \u003d 23 000 рубли.

Годишни касови бележки (R 2) \u003d 28 000 рубли.

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

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

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

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

(4.2)

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

k - броят на годините, за колко време е проектиран проектът.

IC - стартираща инвестиция.

i е процентът на отстъпка.

Според изчисленията по тази формула NPV \u003d 3,460.67 рубли

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

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

(4.3)

Изчислено (ROI) \u003d 108,78%

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

= 1,84

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

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

(4.4)

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

Фигура: 6.2.

(Корпоративна информационна система)

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

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

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

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

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

Смисленото значение на концепцията за модул предполага сравнение на функционални подсистеми, функционални задачи с подход, основан на функционални задачи, с основните модули на съвременния Фигура: 6.2. Сравнение на функционални задачи с основните модули на съвременните информационни системи ICISP на предприятие, ...
(Корпоративна информационна система)

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

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

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

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

Въз основа на целта на разработваната информационна система, ние ще разработим допълнително модулната структура на приложението. За да дефинираме модулната структура, ще използваме диаграмата на компонентите на нотация UML 2.0 (Фигура 3.4).

Фигура: 3.4

Информационната система се състои от три компонента:

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

Дизайн на структурата на базата данни

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

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

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

Тъй като бъдещият IS за тази база данни ще търси, бяха избрани следните като основни атрибути за документа:

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

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

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

Фигура: 3.5

Фигура: 3.6

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

Обектът "Служител", който е независим обект, има следните атрибути:

• · Идентификационен номер на служителя - е основният ключ на този обект;
• · Пълно име на служителя;
• · Област на специализация;
• · Рейтинг;
• · Допълнителна информация.

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

• · Серия и номер на паспорта - е основният ключ на този обект;
• · Идентификационен номер на служителя - е вторичният ключ на този обект;
• · Пълно име на служителя;
• · Област на специализация;
• · Рейтинг;
• · Допълнителна информация.

Обектът „Документ“ е зависим обект от обекта „Клиент“, което означава, че всеки клиент може да съхранява много различни документи в архива. Обектът на документа има атрибути:

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

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

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

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

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

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

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

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

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

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

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

Фиг. 1. Генерализирана функционална блок-схема на IC.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

методи на математическо програмиране, математическа статистика, теория на опашките и др.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Целите на създаването и прилагането на ИС.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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