Каскаден модел ais. Жизнен цикъл на автоматизирани информационни системи (LC AIS). Модели на жизнения цикъл на AIS. Етапи от жизнения цикъл на една информационна система

3.1 Дефиниране на модел на жизнения цикъл на AIS

под модела кръговат на животаРазработката на софтуерен продукт се разбира като структура, която определя последователността на изпълнение и връзката на процесите, действията и задачите, изпълнявани през целия жизнен цикъл на разработката на софтуерния продукт. Следните модели на жизнения цикъл на разработка на софтуерни продукти са най-широко използвани (Таблица 1. Кратка характеристикаМодели на жизнения цикъл на AIS: модел на водопад или водопад (модел на водопад); v-образен модел (v-образен модел); прототипен модел (прототипен модел); бърз модел за разработка на приложения или RAD-модел (RAD-модел за бърза разработка на приложения), многопроходен модел (инкрементален модел); спираловиден модел.

Таблица 1. Кратка характеристика на всеки от изброените модели

Име	характеристики
Каскаден модел	Прост и лесен за използване. Необходим е постоянен строг контрол върху хода на работата. Разработеният софтуер не е достъпен за модификация
V-образен модел	Лесен за използване. Акцентът е поставен върху тестването и сравняването на резултатите от фазите на тестване и проектиране
Модел за прототипиране	Създава се "бързо" частично внедряване на системата преди изготвянето на окончателните изисквания. При условие Обратна връзкамежду потребители и разработчици по време на проекта. Използваните изисквания не са пълни
Модел за бърза разработка на приложения	Проектни екипималки (3 ... 7 души) и се състоят от висококвалифицирани специалисти. Намалено време за цикъл на разработка (до 3 месеца) и подобрена производителност. Повторно използване на код и автоматизация на процеса на разработка
Многопроходен модел	Бързо се създава работеща система. Намалява възможността за извършване на промени по време на процеса на разработка. Миграцията от текущата реализация към нова версия не е възможна, докато текущата частична реализация се изгражда
спираловиден модел	Покрива модела водопад. Разбива фазите на по-малки части. Позволява гъвкав дизайн. Анализира и управлява рисковете. Потребителите се запознават със софтуерния продукт на по-ранен етап благодарение на прототипите

3.2 Каскаден модел

При хомогенни информационни системиПрез 70-те и 80-те години на миналия век приложните софтуерни продукти бяха едно цяло. За разработването на този тип софтуерен продукт е използван каскаден модел или „водопад“.

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

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

3.3 V-модел

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

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

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

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

Моделът включва следните фази:

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

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

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

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

Кодиране - извършва се трансформирането на алгоритми в готов софтуер;

Unit testing – всеки компонент или модул от софтуерния продукт се тества;

Интеграционно тестване - извършва се интегриране на софтуерния продукт и неговото тестване;

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

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

Фиг.5 V-образен модел

Предимства на V-образния модел:

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

2) Предполага се атестиране и проверка не само на самия софтуерен продукт, но и на всички получени вътрешни и външни данни;

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

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

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

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

Продуктът и създаването на удобни карти за попълване на атрибутите на базата данни: простотата на създаване на връзки и тяхното модернизиране. Глава II. Разработване на програма за автоматизиране на дейността на таксиметровия парк 2.1 Анализ на изискванията на клиента Програма Автоматизирана работно мястотакси диспечерът е разработен според спиралния модел на жизнения цикъл на автоматизираните информационни системи. На всеки етап от създаването...

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

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

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

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

Моделът на жизнения цикъл на AIS включва:

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

Ключови събития или точки на завършване и вземане на решения.

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

I. Каскаден моделописва класическия подход за разработване на системи във всякакви предметни области; се използва широко през 70-те и 80-те години.

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

Разпределете петстабилни етапи на развитие, практически независими от предметната област

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

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

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

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

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

Фиг. 1.1 AIS LC каскаден модел

Етапите на работа в рамките на каскадния модел често се наричат ​​части от проектния цикъл на AIS, тъй като етапите се състоят от много итеративни процедури за прецизиране на системните изисквания и опциите за проектиране. Жизненият цикъл на AIS е много по-сложен и по-дълъг: той може да включва произволен брой цикли на усъвършенстване, промени и допълнения към вече приети и реализирани дизайнерски решения. В тези цикли протича развитието на АИС и модернизацията на отделните й компоненти.

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

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

2) последователното изпълнение на етапите на работа ви позволява да планирате времето за завършване и съответните разходи.

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

Недостатъци на модела водопад:

Значително забавяне при получаване на резултати;

Грешките и недостатъците на някой от етапите се появяват, като правило, на следващите етапи на работа, което води до необходимостта от връщане;

Сложността на паралелната работа по проекта;

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

Сложността на управлението на проекти;

Високо ниво на риск и ненадеждност на инвестициите.

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

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

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

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

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

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

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

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

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

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

II. Итеративен модел (Етапен модел с междинен контрол) е поредица от кратки цикли (стъпки) на планиране, изпълнение, проучване, действие.

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

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

недостатъциитеративен модел:

· животът на всеки етап се разтяга за целия период на работа;

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

тънкостите на архитектурата

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

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

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

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

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

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

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

Предимстваитеративен подход:

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

При използването на спиралния модел отделните елементи на АИС се интегрират постепенно в едно цяло. Тъй като интеграцията започва с по-малко елементи, има много по-малко проблеми по време на нейното изпълнение;

Намаляване на нивото на рисковете (последствие от предишното предимство, тъй като рисковете се откриват по време на интеграцията). Нивото на рисковете е максимално в началото на развитието на проекта, с напредване на развитието намалява;

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

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

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

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

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

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

Модел на жизнения цикъл и технология за проектиране

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

задачи, състав и последователност на извършваната работа;

· резултатите от всяко извършено действие;

Методи и средства, необходими за извършване на работата;

ролите и отговорностите на участниците;

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

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

Етапи и етапи на проектиране

Понятията „етап“ и „етап“ на дизайна често се бъркат. Понякога говорят за етапиили фазикръговат на живота, стъпкидизайн. Възниква въпросът: кой е правилният път?

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

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

Ориз. Разпределение на времето при разработване на АИС

Етапи на създаване на AIS (ISO/IEC 15288)

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

AIS съществуват, като правило, за дълъг период от време, последователно преминавайки през няколко етапа на комбинирано развитие в своето развитие. кръговат на живота(LC) системи:

1) предпроектно проучване (или анализ) на организацията,

2) AIS дизайн,

3) внедряване на AIS,

4) въвеждане на AIS,

5) функциониране (работа, използване)

6) AIS ескорт,

7) модернизация на проекта AIS.

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

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

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

Физическата амортизация на AIS е невъзможността да се изпълнят изискванията на организацията за AIS поради повреда, повреда или отказ на системни компоненти.

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

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

Всички етапи от жизнения цикъл на AIS бяха изброени по-горе, но някои от тях работят паралелно, така че разпределят само 5 етапа в жизнения цикъл на AIS(фиг.35):

На първия етап" Предпроектно проучване» (фиг. 33) обичайно е да се разграничават два основни подетапа и един допълнителен подетап:

1.1. провеждане предпроектно проучванеи събиране на анкетни материали;

1.2. анализ на проучвателни материали и разработка въз основа на анализ на предпроектно проучване (FS) и техническо задание (TOR);

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

Целите на етапа на предпроектното проучване са следните:

· да се формулират нуждите от нова АИС, т.е. идентифициране на всички недостатъци на съществуващата ИС;

· избор на посока и определяне на икономическата целесъобразност на проектирането на AIS.

Проучвателната работа започва с анализ на основните изисквания и планиране на работата, което отнема от 2 дни до 4 седмици. След това се извършва самото проучване на предприятието (продължителността на проучването е 1-2 седмици.)

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

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

След това резултатите от проучването се обработват и се изграждат следните два вида модели на дейността на предприятието (имайте предвид, че изграждането на всеки от необходимите модели изисква интензивна работа на 6-7 квалифицирани системни анализатори в рамките на 2-4 месеца).

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

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

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

Детайлно проучване на обекта на автоматизация;

Необходима изследователска работа (R&D), свързана с намиране на начини и оценка на възможността за изпълнение на изискванията на потребителите;

Разработване на алтернативни варианти на концепцията на създадените АИС и планове за тяхното внедряване;

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

Оценка на предимствата и недостатъците на всеки вариант;

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

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

Оценка на ефектите, получени от системата;

Изготвяне на протокол, съдържащ описание на извършената работа;

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

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

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

На този етап се определят:

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

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

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

§ съставът на хората и длъжностите, свързани със системата;

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

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

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

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

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

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

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

§ разработване на състава на автоматизираните работни процеси.

Системен проекттрябва да включва:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Фигура 33. Последователността на работата на етапа на предпроектиране на жизнения цикъл на AIS.

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

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

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

Анализ на приложимостта на съществуващи системи за управление на предприятието (предимно MRP и ERP класове) за решаване на поставените задачи и формиране на препоръки за избор на такава система;

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

Разработване на предложения за технически средства;

Разработване на софтуерни предложения;

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

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

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

Втора фаза" Дизайн» (Фиг. 34) изпълнява следните подстъпки:

1) предварителен проект: изясняване на изискванията на ТЗ, изпълнение и одобряване на предварителния проект;

2) технически проект: избор на проектни решения за всички аспекти на разработването на АИС, описание на всички компоненти на АИС, изпълнение и одобрение на технически проект;

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

Целите на тази фаза са:

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

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

За сложни големи AIS, автоматизиране голямо предприятие, държане, тела държавна власти т.н., в подстъпка 1 " Идеен проект» се формулират предварителни решения за бъдещата АИС като цяло и нейните компоненти, в резултат на което идеен проект(EP). Разработването на предварителни проектни решения за системата и нейните части включва:

Дефиниция на AIS функция;

Дефиниране на функцията на подсистемите, техните цели и ефекти;

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

Дефиниране на понятието информационна база, нейната разширена структура;

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

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

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

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

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

На подстъпка 2. Инжинерен дизайн » работа по логическо развитие и подбор на най-добрите вариантипроектни решения, в резултат на които се създава технически проект (ТП). Като част от създаването на технически проект се извършва следното:

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

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

- работа по технически дизайн:

Разработване на общи решения за системата и нейните части,

Разработване на общи решения за функционално-алгоритм структура на системата,

Разработване на общи решения относно функциите на персонала и организационната структура,

Разработване на общи решения за структурата на техническите средства,

Разработване на общи решения за алгоритми за решаване на проблеми и използвани езици,

Разработване на общи решения за организиране и поддържане на информационна база,

Разработване на общи решения за системата за класификация и кодиране на информацията,

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

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

Разработване и изпълнение на документация за доставка на продукти за придобиване на АИС и/или Технически изисквания(технически спецификации) за разработването им;

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

Подетап 3." Работен проект » свързани с физическото изпълнение на избрания проектен вариант и получаването на работната проектна документация (ПД).

Този подетап се извършва:

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

Разработване на програми и софтуерни инструменти на системата, както и избор, адаптиране и/или обвързване на закупени софтуерни инструменти,

Разработване на софтуерна документация.

Организиране на търгове за доставка на АИС компоненти (софтуер и хардуер, софтуерни и хардуерни системи, информационни продукти).

Фигура 34. Последователността на работата на етапа на проектиране на жизнения цикъл на AIS.

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

Третият етап Внедряване» (фиг. 35) е физическият дизайн на системата в следната последователност:

1) получаване и инсталиране на технически средства;

2) кодиране, тестване и разработване на програми;

3) получаване и инсталиране на софтуер;

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

5) разработване на инструкции за работа на софтуер и хардуер, както и длъжностни характеристикиза персонала.

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

На четвъртия етап от жизнения цикъл на AIS " Внедряване» има следните подстъпки:

1) пилотно внедряване:

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

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

· обучение и сертифициране на персонала.

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

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

Изпълнение на проектни решения по организационната структура на АИС;

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

Въвеждане на информационни класификатори;

обучение,

Проверка на способността му да осигури функционирането на АИС.

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

Извършва тестове на АИС за работоспособност и съответствие с техническото задание в съответствие с предварително изготвена програма и методика за предварителни тестове;

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

Работата по пилотното внедряване приключва на съставяне на акт за завършване на пробна експлоатация.

2) индустриално внедряване (пускане в търговска експлоатация):

въвеждане в експлоатация,

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

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

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

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

Довършителни работи по съставяне на акт за приемане на AIS за постоянна експлоатация.

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

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

Следгаранционното обслужване се състои от:

При изпълнението на работата по анализ на функционирането на системата;

При установяване на отклонения на действителните експлоатационни характеристики на АИС от проектните стойности;

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

При отстраняване на констатираните недостатъци и осигуряване на стабилност на експлоатационните характеристики на АИС;

При извършване на необходимите промени в документацията за АИС.

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

Фигура 35. Етапи на жизнения цикъл на AIS.

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

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

каскаден модел (до 70-те години) - последователен преход към следващия етап след завършване на предишния;

· итеративен модел (70-те – 80-те) – с итеративни връщания към предишните етапи след завършване на следващия етап;

· спираловиден модел (80-90-те) - прототипен модел, който предполага постепенно разширяване на прототипа на AIS.

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

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

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

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

Спираловидният модел на жизнения цикъл се основава на използването на прототипна технология или RAD технология (бързо разработване на приложения).

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

Естествено, с прототипната технология броят на итерациите е намален и има по-малко грешки и несъответствия, които трябва да бъдат коригирани при следващи итерации, а самото проектиране се извършва с по-бързи темпове и създаването на проектна документация е опростено. За по-голямо съответствие с проектната документация, разработена от AIS, все по-голямо значение се придава на поддържането на системно хранилище и автоматизацията на проектирането, по-специално използването на CASE (Computers Aids System Engineering) технологии.

Когато използвате спираловиден модел:

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

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

· в процеса на проектиране на системата се извършва анализ на риска и разходите.

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

Прототип - минималната версия на системата, използвана за генериране или разработване на пълната версия

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

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

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

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

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

2. Дизайн;

3. Развитие;

4. Тестване;

5. Въведение;

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

Предимства:

-Пълна и съгласувана документация на всеки етап;

-Определен ред на последователност на работа;

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

недостатъци:

-Значително забавяне при получаване на готови резултати;

-Грешките на някой от етапите се откриват на следващи етапи, което води до необходимостта от връщане и пререгистриране на проектната документация;

- Трудности при управлението на проекти.

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

Всяка итерация - завършени цикли на разработка под формата на 1-ва версия на AIS.

Стъпки на итерация:

1.Формиране на изисквания

3.Дизайн

4.Развитие

5.Интеграция

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

Рискът от превишаване на сроковете и стойността на проекта;

Необходимостта от извършване на друга итерация;

Степента на пълнота и точност на разбиране на изискванията към системата;

Целесъобразността от прекратяване на проекта.

Предимства:

-Опростява процеса на извършване на промени в проекта;

- Осигурява по-голяма гъвкавост при управление на проекти;

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

- Влияние на клиента върху работата в процеса на проверка на всяка итерация.

недостатъци:

-Сложност на планирането;

-Интензивен режим на работа за разработчиците;

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

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

Дизайнерска технология- дефинира комбинация от три компонента:

- процедура стъпка по стъпка, който определя последователността на операциите по технологично проектиране;

- правила, използвани за оценка на резултатите от технологичните операции;

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

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

Технологията за проектиране, разработване и поддържане на ИС трябва да отговаря на следното Общи изисквания:

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

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

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

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

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

- стандарт за проектиране;

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

- стандартен потребителски интерфейс.

Изискване за развитие

- Извършване на работа по създаване на софтуер;

Подготовка за въвеждане на АИС;

Контрол, тестване на основните показатели на проекта.

Съпътстващи изисквания

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

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

Въведение

1. Архитектура на автоматизирани информационни системи и проблеми на нейното усъвършенстване 13

1.1. Модели на архитектура и основни компоненти на AIS 13

1.2. Проблеми с развитието на АИС 47

1.3. Платформи за внедряване на новата архитектура на AIS UP 53

1.4. Глава 1 Заключения 57

2. Архитектурен модел на AIS UE 58

2.1. Основни изисквания за AIS UP 59

2.2. Архитектура AIS UP 66

2.3. AIS UP 89 компоненти

2.4. Глава 2 Заключения 102

3. Методи за практическо внедряване на АИС ИУ 104

3.1. Инструментиразработка на AIS UP 104

3.2. Опит в практическото внедряване на модела AIS UP 111

3.3. Глава 3 Заключения 123

4. Заключение 125

5. Терминология и съкращения 128

6. Литература

Въведение в работата

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

През последните 40 години автоматизираните информационни технологии (ИТ) се използват активно за решаване на проблемите на счетоводството, планирането и анализа стопанска дейностпредприятия с различни форми на собственост, отраслова принадлежност, организационна структураи мащаб на дейността. През това време е натрупан много практически опит в създаването на автоматизирани информационни системи за управление на предприятието (AIS UE), разработени са и са получили всеобщо признание методологии за управление, чието прилагане е невъзможно извън компютърната среда. С пълна отговорност може да се каже, че АИС ИУ се превърна в неразделна част от бизнес инфраструктурата. Теоретичните и практическите проблеми на автоматизацията на икономическите процеси са задълбочено изследвани в трудовете на Глушков В.М., Волков С.И., Исаков В.И., Островски О.М., Подолски В.И., Ратмиров Ю.А., Романов А.Н., Хотяшова Е.Н., Брейди Р., Захман Дж. , Кук М., Финкелщайн К., Хамър М. и други автори. Предложените от тях подходи станаха основа за използването на компютърни технологии в предприятията при решаване на проблемите на счетоводството, планирането и анализа на финансовите и икономическите дейности. въпреки това

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

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

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

В публикациите на учени и практици отдавна се обсъжда идеята за внедряване на стандарти за системна интеграция на софтуерни инструменти, доставяни от различни производители. Напредъкът на системните инструменти доведе до появата на обектно-ориентирани и компонентни технологии за разработка на софтуер, които ви позволяват да изграждате мащабни системи от готови блокове. Водещи доставчици на хардуер и системен софтуер (Intel, Microsoft, Sun, Oracle, IBM и др.), средства за комуникация (Cisco, Nortel, Ericsson, Motorola), приложни решения (SAP, PeopleSoft, Siebel и др.), авторитетна държава, международни, търговски и Не-правителствени Организациии асоциации (ISO, IEEE, ASCII, APICS, RosStandard и др.) досега са разработили и активно внедряват в практиката технологии за интегриране на хардуер и софтуер, които позволяват създаване на отворени системи, базирани на стандарти и протоколи за обмен на данни и взаимодействие на компоненти в разнородна среда в режим на реално време.

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

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

Необходимостта от разработване на холистичен подход за решаване на проблемите на системната интеграция на AIS PM и автоматизацията от край до край на микроикономически процеси, базирани на съвременни ИТ, определи избора на темата и посоката на това изследване.

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

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

Да анализира и обобщи съществуващите подходи към проектирането, разработването и внедряването на софтуера AIS UP;

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

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

Да идентифицира проблеми, които възникват при интегрирането на софтуерни средства, използвани в AIS UE;

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

Разработете модел на архитектура на AIS UE и подчертайте основните му компоненти;

Разработване на принципите на взаимодействие и обмен на данни на компонентите на AIS UE;

Предмет на изследването са методите и средствата за разработване на икономически информационни системи.

Обект на изследването са ИС за управление на предприятието.

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

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

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

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

Статията използва теоретичните положения на трудовете на местни и чуждестранни автори в областта на:

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

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

Реинженеринг и компютърно проектиране на бизнес процеси;

Съвременни стандарти в информационните технологии.

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

Информационната база на изследването беше съставена от софтуерни продукти на руски и чуждестранни производители, публикации в икономически и компютърни издания, изследвания на международни изследователски групи Gartner Group, Aberdeen, IDC, MetaGroup, DataQuest и др. учебни материаливодещи местни и международни консултантски и одиторски компании, резултати от изследвания на Асоциацията на разработчиците на софтуер в областта на икономиката,

проучване на пазара на софтуер в Русия и страните от ОНД TSIES "Business-Programs-Service" .

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

Научната новост включва следните резултати, получени в дисертацията:

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

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

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

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

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

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

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

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

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

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

Самостоятелна практическа стойност имат:

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

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

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

Предложения за адаптиране на спираловидно-итеративния подход при разработката и внедряването на софтуера AIS UP.

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

Интегрирана система за управление на предприятието "Флагман" на фирма "Инфософт",

Системи за управление на взаимоотношенията с клиенти eRelationship на Pivotal Software Corporation (Канада),

Системи за корпоративна отчетност Monarch ES на компанията DataWatch (САЩ),

Проектът за интеграция на информационни системи на компаниите Sovintel и Tele Ross.

Центърът за обучение Vest-MetaTechnology използва материали, подготвени от автора въз основа на подхода, предложен в хода на това изследване, при провеждане на курсове за разработване на информационни системи за управление на предприятието (вижте http://www.vest.msk.ru).

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

Основните положения на работата бяха докладвани и обсъдени на:

Конференция "Решения на IBM в областта на бизнес интеграцията за телекомуникационни компании", представителство на IBM в Източна Европа (Москва, 18 юни 2002 г.);

Симпозиум "Call Center CRM Solutions 2002/Call Centers and Customer Relationship Management" (Москва, март 2002 г.);

Конференции на разработчици на информационни системи, базирани на инструментите на корпорацията Centura Software Corp. (Берлин, Германия, 17-19 ноември 1999 г.);

Конференция "InfoCity: практика и проблеми на информатизацията на градовете" (Москва, октомври 1999 г.);

Научно-практически конференции на фирма "Инфософт" (Москва, 1995-1999 г.);

Конференция на специалисти в областта на ACS и CIS " Корпоративни системи"(Москва, април 1998 г. и 28-30 април 1997 г., организатори: компания SoftService и представителства на Oracle, Informix, Sybase, Borland и Centura);

3-та годишна конференция "Корпоративни бази данни 98" (Москва, 31 март-3 април 1998 г. и 26-29 март 1996 г., организирана от Центъра за информационни технологии с участието на издателство "Отворени системи");

Конференция "Техником-97" (Москва, 24-26 ноември 1997 г., организатори: SoftService, Руската асоциация на потребителите на Oracle, представителства на Microsoft, Borland, Computer Associates, Lucent Software).

Проблеми с развитието на AIS

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

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

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

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

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

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

Въпреки това, дори ако сървърът на централната база данни е в състояние да осигури необходимата производителност, с такава конструкция на IS неизбежно възникват проблеми при поддържането на единна структура на обща база данни, ако се разработят отделни софтуерни компоненти на IS различни компанииили дори екипи за разработка в рамките на една и съща организация. Инсталирането на обща база данни с достъп от програми за решаване на различни приложни проблеми дава възможност да се осигури общо информационно пространство, изброените по-горе технологии позволяват достъп на голям брой потребители до базата данни, но това не гарантира правилна работа със споделени данни. Остава проблемът с целостта на логическите данни. Когато се използват програми от различни производители, става неизбежно да се разделят данните на подсистеми, вероятно чрез денормализирането им и създаване на излишни структури. Схематична архитектура с обща базапоказано на следващата фигура (Фигура 1-14). Както следва от горната диаграма, модулите не взаимодействат, тоест няма обаждане от един модул към друг в реално време, няма оперативна поддръжка за процес от край до край. Данните се съхраняват в базата данни, от която са достъпни за други модули, които трябва да съдържат функциите за проследяване на промените в нея, а релевантността на данните зависи от честотата на проверка за актуализации. Пример за процес от край до край би било фактуриране от служител на отдел продажби. Ако той използва CRM система за това, генерираната фактура трябва да се обработва паралелно с извлечението в логистичния модул на ERP системата за резервиране на стоката и веднага след това - във финансовия модул за увеличаване на задължението на купувача. За целта съответните модули трябва да проверят за съществуването на нов акаунт. Ако това не бъде направено своевременно, може да бъде издадена фактура за действително запазения артикул.

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

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

Платформи за внедряване на новата AIS UE архитектура

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

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

средства за автоматизирана поддръжка за координирани съвместна работагрупи („екипи“) от работници по един проект, документ, задача и др.;

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

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

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

За работа в разпределена разнородна среда, като Интернет, активно се разработват спецификации на уеб услуги, всяка от които може да реализира една или повече бизнес процедури или функции (бизнес процедури, функции). OASIS, BPMI и IBM, Microsoft и BEA публикуваха спецификациите за регулиране на работния процес BPEL4WS (Език за изпълнение на бизнес процеси за уеб услуги), XLANG и WSFL (Език за поток на уеб услуги) и коалицията WfML - XPDL (Език за дефиниране на XML процеси) .

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

Няма технически пречки за реализирането на такава архитектура. Съвременните индустриални сървъри за приложения (например MTS / COM + / .Net, ONE или J2EE / EJB) ви позволяват да изграждате многослойни системи, предоставят обща платформа за достъп до различни уеб услуги, осигуряват транзакционна цялост на операциите, балансиране на натоварването с конкурентен достъп на десетки хиляди потребители в реално време, както и гаранция за устойчивост на грешки и възстановяване след повреди.

Важно постижение на ИТ индустрията са стандартите, които станаха широко разпространени и признати от водещите производители на софтуер: протоколи за взаимодействие на компоненти (COM / DCOM, CORBA, Java RMI) и формати за обмен на данни (EDI, XML,).

Стандартът EDI и неговите специфични за индустрията варианти (EDIFACT, XI2, HIPAA и др.) се използват във финансовите и индустриални сектори на Северна Америка и Европа от средата на 70-те години на миналия век и доминират днес в целия свят. С нарастващата популярност на XML в Интернет, EDI беше преведен в XML.

На базата на XML (DTD и XDR) данните са разработени, структурирани и форматирани в различни икономически области под формата на така наречените тематични речници или типове документи, например WIDL, OFX, FpML, IFX, XBRL, CRML и много други на Запад, както и CommerceML.ru и XML Partnership/ARB в Русия. Американското дружество за управление на производството и инвентара APICS, което сертифицира системи от клас ERP / MRP, публикува спецификации икономически субектив XML формат, например структурата и формата на данните за клиента или фактурата. Самодокументиращият се XML осигурява недвусмислено разбиране на данните както от хора, така и от програми.

AIS UE архитектура

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

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

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

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

Като ядро ​​на AIS PM е необходимо да се разработи система, която комбинира няколко функции, обсъдени в прегледа на системите за управление на процеси (параграфи "1.1.7 Системи за управление на документи" на страница 31 и "1.1.8 Системи за управление на процеси" на страница 34). Сред тях: Workflow - подсистема за управление на работници и технологични процеси, който осигурява предварително дефинирано и безплатно маршрутизиране на задачите между изпълнителите; Docflow - подсистема за управление на документооборота и маршрутизиране на документи с проследяване на състоянието им; Групов софтуер - подсистема за поддържане на функциите за оперативно възлагане на задачи и свободно маршрутизиране (ad hoc) на задачи между членовете на група изпълнители; Dataflow - маршрутизиране на данни, пакети данни, съобщения между приложения.

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

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

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

Опит в практическото внедряване на модела AIS UE

От 1995 до 1999 г. под ръководството на автора на дисертацията е разработена системата за интегрирана автоматизация на управлението на предприятието "Флагман" на фирма "Инфософт", която в момента е внедрена в повече от сто големи и средни индустриални предприятия. , строителни, търговски, селскостопански предприятия и бюджетни организацииРусия и страните от ОНД. Системата продължава да се развива на базата на ядрото, разработено от автора, и до 2002 г. "Флагманът" включва повече от десет основни подсистеми, показани на следната фигура (Фигура 3-2):

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

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

Бързото развитие на подсистемите и липсата на стандартизация на тяхното взаимодействие доведе до факта, че интеграцията се извършва около централна база данни и общи таблици. Ако не вземем предвид двустепенната архитектура, изборът на която се определя от нивото на развитие на инструментите за разработка през 1995 г., тогава кръстосаната зависимост на модулите се превърна в основния проблем за развитието на системата. Първите му внедрявания разкриха недостатъчността на функциите за автоматизация на работния процес само чрез маршрутизиране на документи и повдигнаха въпроса за необходимостта от внедряване на модул за управление на процеси (workflow).

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

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

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

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

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

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

През февруари 1999 г. системата "Flagman" на компанията "Infosoft", създадена под ръководството на автора, беше призната за най-добрата руска разработка на инструментариума Centura Team Developer от Centura Software Corp. (САЩ) и компанията "Интерфейс" (Русия). През 1999, 2000 и 2001г CIS "Flagman" беше сертифицирана като корпоративна информационна система от експертите на журито на конкурса "Business-Soft", проведен от Асоциацията на разработчиците на софтуер в областта на икономиката (AREP), TSIES "Business Programs-Service “, сп. „Счетоводство” и „Финансов вестник”.