Kaskádový model ais. Životní cyklus automatizovaných informačních systémů (LC AIS). Modely životního cyklu AIS. Etapy životního cyklu informačního systému

3.1 Definování modelu životního cyklu AIS

pod modelem životní cyklus vývoj softwarového produktu je chápán jako struktura, která určuje posloupnost provádění a vztah procesů, akcí a úkolů prováděných v průběhu životního cyklu vývoje softwarového produktu. Nejčastěji se používají následující modely životního cyklu vývoje softwarových produktů (tabulka 1. Stručná charakteristika Modely životního cyklu AIS): model vodopádu nebo vodopád (model vodopádu); model ve tvaru v (model ve tvaru V); prototypový model (model prototypu); model rychlého vývoje aplikací nebo model RAD (model rychlého vývoje aplikací RAD), víceprůchodový model (přírůstkový model); spirálový model.

Tabulka 1. Stručná charakteristika každého z uvedených modelů

název	vlastnosti
Kaskádový model	Přímé a snadné použití. Neustálá přísná kontrola postupu prací je nutná. Vyvinutý software není k dispozici pro úpravy
model ve tvaru V	Snadné použití. Důraz je kladen na testování a porovnávání výsledků testovací a návrhové fáze
Prototypování modelu	Před sestavením finálních požadavků vzniká „rychlá“ dílčí implementace systému. Pokud Zpětná vazba mezi uživateli a vývojáři v průběhu projektu. Použité požadavky nejsou úplné
Model rychlého vývoje aplikací	Projektové týmy malé (3 ... 7 osob) a jsou tvořeny vysoce kvalifikovanými odborníky. Zkrácená doba vývojového cyklu (až 3 měsíce) a lepší výkon. Automatizace procesu opětovného použití kódu a vývoje
Víceprůchodový model	Rychle se vytvoří fungující systém. Snižuje možnost provádění změn během procesu vývoje. Migrace z aktuální implementace na novou verzi není možná, dokud se buduje současná dílčí implementace
spirálový model	Pokrývá model vodopádu. Rozděluje fáze na menší části. Umožňuje flexibilní design. Analyzuje a řídí rizika. Uživatelé se se softwarovým produktem seznámí v dřívější fázi díky prototypům

3.2 Kaskádový model

V homogenní informační systémy Během 70. a 80. let 20. století byly produkty aplikačního softwaru jedinou entitou. K vývoji tohoto typu softwarového produktu byl použit kaskádový model neboli „vodopád“.

Kaskádový model softwarového produktu je podobný modelu automatizovaného řídicího systému (viz kapitola 1, obr. 1).

Tento proces je zpravidla iterativní povahy: výsledky další fáze často způsobují změny v rozhodnutích o návrhu vyvinutých v dřívějších fázích. Existuje tedy neustálá potřeba vracet se k předchozím etapám a upřesňovat nebo revidovat dříve přijatá rozhodnutí. V důsledku toho má vlastní vývojový proces jinou podobu (viz kapitola 1, obrázek 2)

Model 3,3 V

Tento model (obr. 5) byl vyvinut jako variace modelu vodopádu, ve kterém Speciální pozornost je věnována ověření a certifikaci softwarového produktu. Model ukazuje, že testování produktu je diskutováno, navrženo a plánováno na začátku životního cyklu vývoje.

Od vodopádového modelu zdědil model ve tvaru V sekvenční strukturu, podle které každá následující fáze začíná až po úspěšném dokončení fáze předchozí.

Tento model je založen na systematickém přístupu k problému, pro který jsou definovány čtyři základní kroky: analýza, návrh, vývoj a revize. Analýza zahrnuje plánování projektu a požadavky. Design se dělí na vysokoúrovňový a detailní (nízkoúrovňový). Vývoj zahrnuje kódování, kontrolu - různé druhy testování.

Model jasně ukazuje vztah mezi analytickými fázemi a fázemi návrhu, které předcházejí kódování a testování. Přerušované šipky ukazují, že tyto fáze by měly být zvažovány paralelně.

Model zahrnuje následující fáze:

Vypracování projektových požadavků a plánování - jsou stanoveny systémové požadavky a provádí se plánování práce;

Příprava požadavků na produkt a jejich analýza - sestaví se kompletní specifikace požadavků na softwarový produkt;

Design na vysoké úrovni - struktura je definována software, vztah mezi jeho hlavními složkami a funkcemi, které implementují;

Detailní návrh - je určen algoritmus činnosti každé součásti;

Kódování - provádí se transformace algoritmů do hotového softwaru;

Testování jednotek – testuje se každá součást nebo modul softwarového produktu;

Integrační testování - provádí se integrace softwarového produktu a jeho testování;

Testování systému - provoz softwarového produktu je kontrolován po jeho umístění do hardwarového prostředí v souladu se specifikací požadavků;

Provoz a údržba - uvedení softwarového produktu do výroby. Během této fáze může být softwarový produkt upraven a upgradován.

Obr.5 Model ve tvaru V. Obr

Výhody modelu ve tvaru V:

1) Velká role je věnována ověřování a certifikaci softwarového produktu, počínaje ranými fázemi jeho vývoje, všechny akce jsou plánovány;

2) Předpokládá se atestace a ověření nejen samotného softwarového produktu, ale i všech přijatých interních a externích dat;

3) Postup práce lze snadno sledovat, protože dokončení každé fáze je milníkem.

Kromě těchto výhod má model také řadu nevýhod:

iterace mezi fázemi se neberou v úvahu; není možné provádět změny v různých fázích životního cyklu; testování požadavků probíhá příliš pozdě, takže provádění změn ovlivní plán.

Tento model je účelné používat při vývoji softwarových produktů, jejichž hlavním požadavkem je vysoká spolehlivost.

Produkt a tvorba pohodlných karet pro vyplnění atributů databáze: jednoduchost vytváření odkazů a jejich modernizace. Kapitola II. Vývoj programu pro automatizaci činností vozového parku taxi 2.1 Analýza požadavků zákazníků Program Automated pracoviště taxi dispečer je vyvíjen podle spirálového modelu životního cyklu automatizovaných informačních systémů. V každé fázi tvorby...

Systémy. Hlavní normativní dokumenty, regulující proces tvorby jakéhokoli IS a IT projektu, jsou GOST a jejich komplexy pro tvorbu a dokumentování informační technologie, automatizované systémy, software, organizace a zpracování dat, jakož i řídící dokumenty Státní technické komise Ruska o vývoji, výrobě a provozu softwaru a ...

Kaskádový přístup se osvědčil při budování IS, u kterých je na samém počátku vývoje možné formulovat všechny požadavky zcela přesně a kompletně tak, aby vývojářům poskytla svobodu je technicky co nejlépe implementovat. Tato kategorie zahrnuje komplexní systémy s velkým množstvím úloh výpočetního charakteru systému reálného času atp.

Model životního cyklu AIS- je struktura, která popisuje procesy, činnosti a úkoly, které jsou prováděny při vývoji, provozu a údržbě v průběhu celého životního cyklu systému.

Volba modelu životního cyklu závisí na specifikách, rozsahu, složitosti projektu a souboru podmínek, ve kterých AIS vzniká a funguje.

Model životního cyklu AIS zahrnuje:

Výsledky práce v každé fázi;

Klíčové události nebo body dokončení a rozhodování.

V souladu se známými modely životního cyklu softwaru se určují modely životního cyklu AIS - kaskáda, iterace, spirála.

I. Kaskádový model popisuje klasický přístup k vývoji systémů v jakékoli předmětové oblasti; byl široce používán v 70. a 80. letech.

Kaskádový model zajišťuje sekvenční organizaci práce a hlavním rysem modelu je rozdělení veškeré práce do etap. K přechodu z předchozí fáze do další dochází až po úplném dokončení všech prací předchozí.

Přidělit Pět stabilní vývojové fáze, prakticky nezávislé na předmětné oblasti

Na První Ve fázi se studuje problémová oblast, formulují se požadavky zákazníka. Výsledkem této fáze je zadání (vývojový úkol), dohodnuté se všemi zainteresovanými stranami.

Během druhý etapě, dle požadavků podmínky zadání, vyvíjejí se určitá konstrukční řešení. Výsledkem je soubor projektové dokumentace.

Třetí etapa - realizace projektu; v podstatě vývoj softwaru (kódování) v souladu s návrhovými rozhodnutími předchozí etapy. Metody implementace nemají zásadní význam. Výsledkem etapy je hotový softwarový produkt.

Na Čtvrtý Ve fázi se kontroluje, zda přijatý software splňuje požadavky uvedené v zadání. Zkušební provoz umožňuje odhalit různé druhy skrytých nedostatků, které se projevují v reálných podmínkách provozu AIS.

Posledním krokem je kapitulace hotový projekt, a zde jde především o to přesvědčit zákazníka, že všechny jeho požadavky jsou v plném rozsahu splněny.

Obr. 1.1 Kaskádový model AIS LC

Fáze práce v rámci vodopádového modelu jsou často označovány jako části projektového cyklu AIS, protože fáze sestávají z mnoha opakujících se postupů pro upřesnění systémových požadavků a možností návrhu. Životní cyklus AIS je mnohem komplikovanější a delší: může zahrnovat libovolný počet cyklů zdokonalování, změn a doplňků již přijatých a realizovaných návrhových rozhodnutí. V těchto cyklech probíhá vývoj AIS a modernizace jeho jednotlivých komponent.

Výhody modelu vodopádu:

1) v každé fázi je vytvořena kompletní sada projektové dokumentace, která splňuje kritéria úplnosti a konzistence. V závěrečných fázích je vypracována uživatelská dokumentace pokrývající všechny typy podpory AIS poskytované standardy (organizační, informační, softwarová, technická atd.);

2) postupné provádění fází práce vám umožňuje naplánovat načasování dokončení a odpovídající náklady.

Kaskádový model byl původně vyvinut pro řešení různých druhů inženýrských problémů a dodnes neztratil svůj význam pro aplikovanou oblast. Vodopádový přístup je navíc pro vývoj AIS ideální, neboť již na samém počátku vývoje lze poměrně přesně formulovat všechny požadavky tak, aby vývojářům poskytla volnost technické implementace. Mezi takové AIS patří zejména komplexní systémy vypořádání a systémy v reálném čase.

Nevýhody vodopádového modelu:

Významné zpoždění při získávání výsledků;

Chyby a nedostatky v kterékoli z fází se zpravidla objevují v následujících fázích práce, což vede k nutnosti vrácení;

Složitost paralelní práce na projektu;

Nadměrné informační přetížení každé z fází;

Složitost projektového řízení;

Vysoká míra rizika a nespolehlivosti investic.

Zpoždění při získávání výsledků Projevuje se tím, že při důsledném přístupu k rozvoji jsou výsledky se zainteresovanými stranami odsouhlaseny až po dokončení další etapy prací. V důsledku toho se může ukázat, že vyvíjený AIS nesplňuje požadavky a k takovým nesrovnalostem může dojít v kterékoli fázi vývoje; kromě toho mohou být chyby neúmyslně zaneseny jak analytiky, tak programátory, protože se od nich nevyžaduje, aby se dobře orientovali v předmětech, pro které je AIS vyvíjen.

Návrat do dřívějších fází. Tato nevýhoda je projevem předchozí: postupná postupná práce na projektu může vést k tomu, že chyby vzniklé v dřívějších fázích jsou odhaleny až v následujících fázích. Díky tomu se projekt vrací do předchozí fáze, je zpracován a teprve poté převeden do následné práce. To může způsobit narušení harmonogramu a zkomplikovat vztahy mezi vývojovými týmy provádějícími jednotlivé etapy.

Nejhorší možností je, když se nedostatky předchozí fáze nenajdou v další fázi, ale později. Například ve fázi zkušebního provozu se mohou objevit chyby v popisu předmětné oblasti. To znamená, že část projektu se musí vrátit do počáteční fáze prací.

Složitost paralelní práce související s potřebou sladit jednotlivé části projektu Čím pevnější je vztah jednotlivých částí projektu, tím častěji a pečlivěji je třeba provádět synchronizaci, tím více jsou na sobě vývojové týmy závislé. V důsledku toho se výhody paralelní práce jednoduše ztratí; nedostatek paralelismu negativně ovlivňuje organizaci práce celého týmu.

Problém informační přetížení vzniká ze silné závislosti mezi různými skupinami vývojářů. Faktem je, že při provádění změn v jedné z částí projektu je nutné upozornit ty vývojáře, kteří ji použili (mohli použít) ve své práci. S velkým množstvím propojených subsystémů se synchronizace interní dokumentace stává samostatným hlavním úkolem: vývojáři se musí neustále seznamovat se změnami a vyhodnocovat, jak tyto změny ovlivní získané výsledky.

Složitost projektového řízení především díky přísnému sledu vývojových fází a přítomnosti složitých vztahů mezi různými částmi projektu. Upravený sled prací vede k tomu, že některé vývojové skupiny musí čekat na výsledky práce jiných týmů, proto je nutný administrativní zásah k odsouhlasení načasování a složení předávané dokumentace.

V případě zjištění chyb v práci je nutný návrat k předchozím etapám; dosavadní práce těch, kteří udělali chybu, je přerušena. Důsledkem toho je obvykle zpoždění v realizaci jak opravených, tak nových projektů.

Snížením počtu vazeb mezi jednotlivými částmi projektu je možné zjednodušit interakci mezi vývojáři a snížit informační přetížení dokumentace, ale ne každý AIS lze rozdělit na volně vázané subsystémy.

Vysoká míra rizika.Čím je projekt složitější, tím déle trvá každá etapa vývoje a tím složitější je vztah mezi jednotlivými částmi projektu, kterých se také zvyšuje. Navíc výsledky vývoje lze skutečně vidět a vyhodnotit až ve fázi testování, tedy po dokončení analýzy, návrhu a vývoje - fáze, jejíž realizace vyžaduje nemalý čas a peníze.

Opožděné vyhodnocení vytváří vážné problémy při identifikaci chyb analýzy a návrhu – je nutný návrat k předchozím fázím a opakování procesu vývoje. Návrat k předchozím etapám však může být spojen nejen s chybami, ale také se změnami, ke kterým došlo v předmětné oblasti nebo v požadavcích zákazníků během vývoje. Zároveň nikdo nezaručuje, že se předmětná oblast do doby, kdy bude připravena další verze projektu, opět nezmění. Ve skutečnosti to znamená, že existuje možnost „cyklu“ procesu vývoje: náklady na projekt se budou neustále zvyšovat a termíny dodání hotového produktu se budou neustále zpožďovat.

II. Iterativní model (Stupňovaný model se středním ovládáním) je řada krátkých cyklů (kroků) plánování, realizace, studie, akce.

Tvorba komplexních AIS zahrnuje koordinaci konstrukčních řešení získaných při realizaci jednotlivých úkolů. Konstrukční přístup „zdola nahoru“ vyžaduje takové iterace návratnosti, kdy se návrhová řešení jednotlivých úloh spojují do společných systémových řešení. V tomto případě je potřeba revidovat dříve vytvořené požadavky.

Výhoda iterativního modelu spočívá v tom, že mezistupňové úpravy poskytují menší pracovní náročnost vývoje ve srovnání s kaskádovým modelem.

Nedostatky iterativní model:

· životnost každé fáze je prodloužena na celou dobu práce;

· vzhledem k velkému počtu iterací dochází k nesrovnalostem v provádění rozhodnutí o návrhu a dokumentaci;

složitosti architektury

Obtíže při používání projektové dokumentace ve fázích implementace a provozu si vyžádají přepracování celého systému.

III. spirálový model, na rozdíl od kaskády, ale podobně jako ta předchozí, zahrnuje iterativní proces vývoje AIS. Zároveň se zvyšuje význam počátečních fází, jako je analýza a návrh, který ověřuje a zdůvodňuje proveditelnost technických řešení tvorbou prototypů.

Každá iterace je úplným vývojovým cyklem vedoucím k vydání interní nebo externí verze produktu (nebo podmnožiny konečného produktu), která se od iterace k iteraci vylepšuje, aby se stala kompletním systémem (obrázek 1.2).

Rýže. 1.2. Spirální model životního cyklu AIS

Každé otočení spirály tedy odpovídá vytvoření fragmentu nebo verze softwarového produktu, specifikuje cíle a charakteristiky projektu, určuje jeho kvalitu a plánuje práci na dalším otočení spirály. Každá iterace slouží k prohloubení a důslednému upřesnění detailů projektu, v důsledku čehož je vybrána rozumná varianta pro finální realizaci.

Použití spirálového modelu vám umožní přejít k další fázi projektu, aniž byste čekali na dokončení té aktuální – nedokončenou práci lze provést v další iteraci. Hlavním úkolem každé iterace je co nejrychleji vytvořit funkční produkt pro předvedení uživatelům. Proces zavádění upřesnění a dodatků do projektu je tedy značně zjednodušen.

Spirální přístup k vývoji softwaru překonává většinu nedostatků vodopádového modelu, navíc poskytuje řadu další funkce aby byl proces vývoje flexibilnější.

Výhody iterativní přístup:

Iterativní vývoj výrazně zjednodušuje zavádění změn do projektu při změně požadavků zákazníka;

Při použití spirálového modelu jsou jednotlivé prvky AIS postupně integrovány do jediného celku. Vzhledem k tomu, že integrace začíná s menším počtem prvků, je při její implementaci mnohem méně problémů;

Snížení úrovně rizik (důsledek předchozí výhody, protože rizika jsou detekována při integraci). Míra rizik je na začátku vývoje projektu maximální, s postupem vývoje klesá;

Iterativní vývoj poskytuje větší flexibilitu při řízení projektů tím, že umožňuje provádět taktické změny ve vyvíjeném produktu. Je tedy možné zkrátit dobu vývoje snížením funkčnosti systému nebo použít produkty třetích stran jako komponenty namísto vašeho vlastního vývoje (relevantní, když tržní hospodářství když je nutné bránit se propagaci produktu konkurence);

Iterativní přístup usnadňuje opětovné použití komponent, protože je mnohem jednodušší identifikovat (identifikovat) společné části projektu, když jsou již částečně vyvinuty, než se je snažit izolovat na samém začátku projektu. Analýza návrhu po několika počátečních iteracích odhalí běžné opakovaně použitelné komponenty, které budou vylepšeny v následujících iteracích;

Spirálový model umožňuje získat spolehlivější a stabilnější systém. Je to proto, že jak se systém vyvíjí, jsou při každé iteraci nalezeny a opraveny chyby a slabiny. Současně se upravují kritické výkonnostní parametry, které jsou v případě vodopádového modelu dostupné pouze před implementací systému;

Iterativní přístup umožňuje zlepšování procesů
vývoj - jako výsledek analýzy na konci každé iterace je provedeno posouzení změn ve vývojové organizaci; při další iteraci se to zlepší.

Hlavní problém spirálového cyklu- obtížnost určení okamžiku přechodu do další fáze. K jeho řešení je nutné zavést časové limity pro každou z fází životního cyklu. V opačném případě se proces vývoje může změnit v nekonečné vylepšování toho, co již bylo provedeno.

Zapojení uživatelů do procesu navrhování a kopírování aplikace vám umožňuje přijímat komentáře a dodatky k požadavkům přímo v procesu navrhování aplikace, což zkracuje dobu vývoje. Zástupci zákazníka dostávají možnost řídit proces tvorby systému a ovlivňovat jeho funkční obsah. Výsledkem je zprovoznění systému, který zohledňuje většinu potřeb zákazníků.

Model životního cyklu a konstrukční technologie

Již dříve jsme řekli, že technologie návrhu nastavuje posloupnost akcí nezbytných k získání IP projektu. Je zřejmé, že provedení každé z těchto akcí znamená přechod informačního systému z jednoho stavu do druhého. Jakákoli konstrukční technologie tedy jednoznačně popisuje nějaký model životního cyklu. Na druhé straně vytvořením modelu životního cyklu informačního systému, tedy definováním:

úkoly, skladba a sled vykonávaných prací;

· výsledky každé provedené akce;

Metody a prostředky nezbytné pro výkon práce;

role a odpovědnosti účastníků;

další informace nezbytné pro plánování, organizaci a řízení kolektivního rozvoje IP,

získáme jednoznačný popis námi zvolené konstrukční technologie. Model životního cyklu je tedy nedílnou a nezbytnou součástí technologie návrhu informačních systémů.

Etapy a fáze projektování

Pojmy „stage“ a „stage“ designu jsou často zaměňovány. Někdy o tom mluví etapy nebo fázeživotní cyklus, kroky design. Nabízí se otázka: jaká je ta správná cesta?

Je třeba připomenout, že v různých mezinárodní standardy použitá terminologie se může lišit. Pokud to bude možné, zaměříme se na terminologii tuzemských GOST. Fáze návrhu budeme nazývat část procesu tvorby IS, ohraničenou nějakým časovým rámcem a končící vydáním konkrétního produktu (model, dokumentace, text programu atd.). Podle shodnosti cílů lze fáze návrhu kombinovat etapy. Například fáze „Technický návrh“, fáze „Realizace“ atd.

Podle zveřejněných údajů vyžaduje každá fáze vývoje AIS určitý čas. Většinu času (45–50 %) stráví kódováním, komplexním a samostatným testováním. Vývoj AIS zabírá v průměru jednu třetinu celého životního cyklu systému.

Rýže. Rozložení času při vývoji AIS

Fáze vytváření AIS (ISO/IEC 15288)

Norma ISO/IEC 12207 definuje rámec životního cyklu, který obsahuje procesy, činnosti a úkoly, které je nutné provést při vytváření informačního systému.

AIS existují zpravidla dlouhou dobu a ve svém vývoji postupně procházejí několika etapami kombinovaného vývoje. životní cyklus(LC) systémy:

1) předprojektový průzkum (nebo analýza) organizace,

2) design AIS,

3) implementace AIS,

4) zavedení AIS,

5) fungování (provoz, použití)

6) eskorta AIS,

7) modernizace projektu AIS.

Životní cyklus je období vzniku a používání informačního systému, pokrývající jeho různé stavy, počínaje okamžikem vzniku potřeby tohoto informačního systému a konče okamžikem jeho úplného vyřazení z provozu.

Je třeba si uvědomit, že AIS je produktem výroby informací, stejně jako je automobil produktem strojírenské výroby, klobása je produktem výroby potravin atd., proto etapy životního cyklu AIS s 1 až 5 jsou podobné fázím životního cyklu jakéhokoli produktu.

Životní cyklus AIS, stejně jako auto, může skončit v důsledku fyzického opotřebení, -li v životním cyklu fáze podpory nevyšla, tedy opravy a údržba např. počítačů a programů, které jsou součástí AIS (bez podpory nebude systém fungovat ani šest měsíců). S kvalifikovaným doprovodem může AIS existovat dlouhou dobu, ale existuje hrozba ukončení životního cyklu AIS z důvodu zastaralosti, zastaralost AIS, pokud neexistuje žádná fáze upgradu AIS (bez modernizace nebude systém fungovat déle než 2 roky).

Fyzická amortizace AIS je neschopnost splnit požadavky organizace na AIS z důvodu poruchy, poruchy nebo selhání systémových komponent.

Zastarávání AIS - ukončení plnění požadavků organizace a jejích zaměstnanců na AIS, v důsledku používání zastaralých automat. informační technologie a nedostatek podpory pro nové požadavky uživatelů.

Pokud vaše organizace přistupovala k automatizaci zodpovědně a komplexně, organizovala podle toho všechny fáze a fáze Životní cyklus AIS omezuje pouze životnost vaší organizace, což znamená, že finanční prostředky vynaložené na AIS nebudou vyhozeny do koše spolu s fyzicky či morálně zastaralým AIS.

Všechny fáze životního cyklu AIS byly uvedeny výše, ale některé z nich běží paralelně, takže se pouze alokují 5 fází životního cyklu AIS(obr. 35):

V první fázi" Předprojektový průzkum» (obr. 33) je obvyklé rozlišovat dvě hlavní dílčí etapy a jednu doplňkovou dílčí etapu:

1.1. dirigování předprojektový průzkum a sběr materiálů pro průzkum;

1.2. analýza materiálů průzkumu a vývoje na základě analýzy studie proveditelnosti (FS) a zadání (TOR);

1.3. výběr a vývoj varianty koncepce systému.

Cíle fáze předprojektového průzkumu jsou následující:

· formulovat potřeby nového AIS, tj. identifikovat všechny nedostatky stávajícího IS;

· zvolit směr a určit ekonomickou proveditelnost návrhu AIS.

Průzkumová práce začíná analýzou primárních požadavků a plánováním práce, která trvá od 2 dnů do 4 týdnů. Dále se provede samotný průzkum podniku (doba trvání průzkumu je 1-2 týdny).

Nejprve je vytvořen popis a je analyzováno fungování daného podniku nebo organizace v souladu s požadavky (cílemi), které se na něj vztahují. Jsou stanoveny organizační a topologické struktury podniku. Identifikují se funkční aktivity každé z divizí podniku a funkční interakce mezi nimi, informační toky v rámci divizí a mezi nimi, objekty vně podniku a externí informační interakce. Stanoví se seznam cílových úkolů (funkcí) podniku a provede se analýza rozdělení funkcí podle oddělení a zaměstnanců.

Je stanoven seznam automatizačních prostředků používaných v podniku.

Dále jsou zpracovány výsledky průzkumu a sestaveny následující dva typy modelů podnikových aktivit (všimněte si, že sestavení každého z požadovaných modelů vyžaduje intenzivní práci 6-7 kvalifikovaných systémových analytiků během 2-4 měsíců).

1. Ve výstavbě "jak je" model který je „snímkem“ stavu věcí v podniku (organizační struktura, interakce mezi odděleními, převzaté technologie, automatizované a neautomatizované obchodní procesy atd.) v době průzkumu a umožňuje vám pochopit, co tento podnik dělá a jak funguje z hlediska systémové analýzy a také na základě automatického ověřování identifikovat řadu chyb a úzkých míst a formulovat řadu návrhů na zlepšení situace.

2. Vytvořeno Model „jak se patří“. integruje perspektivní návrhy managementu a zaměstnanců podniku, odborníků a systémových analytiků a umožňuje vytvořit vizi nových racionálních technologií pro provoz podniku. Ona zastupuje koncepce budoucího AIS.

Tvorba konceptu budoucího systému zahrnuje následující práce:

Detailní studie objektu automatizace;

Požadovaná výzkumná práce (VaV) související s hledáním cest a posouzením možnosti implementace požadavků uživatelů;

Vývoj alternativních variant koncepce vytvářeného AIS a plánů jejich realizace;

Školní známka potřebné zdroje pro jejich realizaci a provoz;

Vyhodnocení výhod a nevýhod každé možnosti;

Porovnání uživatelských požadavků a vlastností navrhovaného systému a výběr nejlepší možnost;

Stanovení postupu posuzování kvality a podmínek pro přejímku systému;

Hodnocení efektů přijatých ze systému;

Vypracování zprávy obsahující popis provedené práce;

Popis a zdůvodnění navržené verze koncepce systému.

Na základě vytvořeného konceptu systému a výsledků průzkumu podniku z hlediska identifikace požadavků na budoucí systém je vytvořen projekt systému (model požadavků), což je první fáze vývoje samotného automatizačního systému (zejména fáze analýzy požadavků na systém), na které se specifikují, formalizují a dokumentují požadavky zákazníka.

Ve skutečnosti je v této fázi dána odpověď na otázku: „Co by měl budoucí systém dělat?“. Zde leží klíč k úspěchu celého projektu automatizace. V praxi tvorby velkých softwarových systémů existuje mnoho příkladů neúspěšné implementace právě z důvodu neúplnosti a nejasné definice systémových požadavků.

V této fázi se stanoví:

§ architektura systému, jeho funkce, vnější podmínky jeho fungování, rozdělení funkcí mezi hardwarovou a softwarovou část;

§ rozhraní a rozdělení funkcí mezi osobou a systémem;

§ požadavky na softwarové a informační komponenty systému, potřebné hardwarové zdroje, požadavky na databáze, fyzické vlastnosti komponent systému, jejich rozhraní;

§ složení osob a pracovních míst souvisejících se systémem;

§ omezení v procesu vývoje (směrné termíny dokončení jednotlivých etap, dostupné zdroje);

§ organizační postupy, které zajišťují ochranu informací.

V rámci návrhu systému se provádí následující:

Stanovení skladby, struktury a charakteristiky funkčních úkolů v rámci činnosti strukturních útvarů;

Určení složení a struktury automatizačního softwaru pro technologii řešení problémů s přihlédnutím k existujícím nástrojům v strukturální dělení;

Stanovení struktury a vlastností informačních podpůrných technologií pro řešení problémů;

Vývoj technických řešení pro výstavbu informační podpory (logické databázové struktury, klasifikátorové struktury);

§ vývoj složení automatizovaných pracovních postupů.

Systémový projekt by měl obsahovat:

kompletní funkční model požadavků na budoucí systém;

Komentáře k funkčnímu modelu (specifikace procesu nižší úrovně v textové podobě);

balík zpráv a dokumentů o funkčním modelu včetně popisu objektu modelování, seznamu subsystémů, požadavků na způsoby a prostředky komunikace pro výměnu informací mezi komponentami, požadavky na vlastnosti propojení systému se sousedními systémy, požadavky pro systémové funkce;

· koncepční model integrované databáze (balíček diagramů);

architektura systému s odkazem na koncepční model;

· návrhy organizační struktury na podporu systému.

Projekt systému tedy obsahuje funkční, informační a případně eventové modely požadavků na budoucí systém. Typy a posloupnost prací při konstrukci těchto modelů požadavků jsou podobné jako u odpovídajících prací na konstrukci modelů činností. Projekt systému navíc obsahuje podmínky pro vytvoření automatizovaného systému.

Je třeba poznamenat následující výhodu projektu systému. Tradiční vývoj je charakterizován prováděním počátečních fází řemeslnými neformalizovanými způsoby. Díky tomu mohou zákazníci a uživatelé poprvé vidět systém poté, co byl již z velké části implementován. Tento systém se přirozeně liší od toho, co očekávali, že uvidí. Proto následuje několik dalších iterací jeho vývoje nebo modifikace, což vyžaduje dodatečné (a značné) náklady na peníze a čas. Klíčem k vyřešení tohoto problému je systémový projekt, který umožňuje:

Popsat, „vidět“ a opravit budoucí systém před jeho fyzickou implementací;

Snížit náklady na vývoj a implementaci systému;

Zhodnotit vývoj z hlediska času a výsledků;

Dosáhnout vzájemného porozumění mezi všemi účastníky práce (zákazníci, uživatelé, vývojáři, programátoři atd.);

Zkvalitnit vyvíjený systém, a to: vytvořit optimální strukturu integrované databáze, provést funkční rozklad typických modulů.

Systémový projekt je zcela nezávislý a oddělitelný od konkrétních vývojářů, nevyžaduje údržbu ze strany jeho tvůrců a lze jej bezbolestně přenést na další osoby. Navíc, pokud podnik z nějakého důvodu není připraven na implementaci systému na základě projektu, může být odložen „na polici“, dokud to nebude potřeba. Kromě toho jej lze použít pro samostatný vývoj nebo opravu softwarových nástrojů již implementovaných na jeho základě programátory oddělení podnikové automatizace.

Účelem zpracování „Studie proveditelnosti“ projektu AIS je posoudit hlavní parametry, které projekt omezují, zdůvodnit volbu a vyhodnotit hlavní konstrukční rozhodnutí pro jednotlivé součásti projektu. Zároveň existují organizační parametry, které charakterizují způsoby organizace procesů transformace informací v systému, informační a ekonomické parametry, které charakterizují náklady na vytvoření a provoz systému, úspory z jeho provozu. Hlavními objekty parametrizace v systému jsou úlohy, komplexy úloh, ekonomické ukazatele, procesy zpracování informací. Poté, co bylo rozhodnuto o další práci, řada organizační opatření musí být například vydány příslušné pracovní příkazy; Měli by být jmenováni odpovědní za oblasti atd.

Bez takové podpory ze strany vedení podniku nemá smysl projekt vůbec zahajovat.

Obrázek 33. Sled prací ve fázi předběžného návrhu životního cyklu AIS.

Dále je vytvořen referenční rámec (TOR) pro projekt, který odráží Specifikace a požadavky na budoucí AIS, stejně jako omezení konstrukčních zdrojů. Pokud projekt vyžaduje vědeckou studii komponent, pak je koncept budoucího AIS vyvinut na základě TOR.

V rámci formování TOR jsou na základě identifikovaných a dohodnutých požadavků vypracovány návrhy na automatizaci, které zahrnují:

Vypracování seznamu automatizovaných pracovišť podniku a způsobů interakce mezi nimi;

Analýza použitelnosti stávajících systémů řízení podniku (především tříd MRP a ERP) pro řešení požadovaných úkolů a tvorba doporučení pro výběr takového systému;

Společné rozhodování s klientem výběr konkrétního systému řízení podniku nebo vývoj vlastního systémy.

Vývoj návrhů technických prostředků;

Vývoj návrhů softwaru;

Vývoj topologie, složení a struktury lokální sítě;

Vypracování návrhů etap a podmínek automatizace.

Pokud bylo rozhodnuto o volbě konkrétního řídicího systému, pak jsou některé kroky přeskočeny.

Druhá fáze" Design» (obr. 34) provede následující dílčí kroky:

1) předběžný návrh: vyjasnění požadavků TOR, provedení a schválení předběžného návrhu;

2) technický návrh: výběr konstrukčních řešení pro všechny aspekty vývoje AIS, popis všech komponent AIS, provedení a schválení technického projektu;

3) detailní návrh: výběr a vývoj matematických metod a algoritmů programů, úprava struktury databází (DB), tvorba dokumentace pro dodávku a vývoj softwarových produktů, výběr sestavy hardwaru AIS, tvorba dokumentace pro dodávka a montáž hardwaru, vypracování pracovního návrhu AIS .

Cíle této fáze jsou:

· vyvinout funkční architekturu AIS, která odráží strukturu a složení funkčních subsystémů, pro automatizovanou podporu některých řídících funkcí organizace;

· vypracovat systémovou architekturu vybrané varianty AIS, tj. skladbu podpůrných subsystémů.

Pro komplexní velké AIS, automatizace velký podnik, držení, těla státní moc atd., v dílčím kroku 1 " Předběžný návrh» jsou formulována předběžná řešení pro budoucí AIS jako celek a jeho součásti, v důsledku čehož předběžný návrh(EP). Vývoj předběžných konstrukčních řešení systému a jeho částí zahrnuje:

Definice funkce AIS;

Definice funkce subsystémů, jejich cílů a účinků;

Stanovení skladby komplexů úkolů a jednotlivých úkolů;

Vymezení pojmu informační základna, její rozšířená struktura;

Definice funkcí systému správy databází;

Stanovení složení počítačového systému;

Definice funkce a parametrů hlavních softwarových nástrojů.

Vypracování dokumentace pro tuto část projektu.

Pokud vyvíjený projekt není příliš složitý, předpokládejme, že je automatizován malý podnik, pak je pracovní krok přeskočen.

V dílčím kroku 2. Inženýrský design » práce na logickém vývoji a výběru nejlepší možnosti návrhová rozhodnutí, v jejichž důsledku vzniká technický projekt (TP). V rámci tvorby technického projektu se provádí:

- transformace systémového projektu na technický projekt(implementační model), který zahrnuje následující akce: upřesnění logického modelu (vývoj podrobné logiky pro každý proces pomocí diagramů datových toků a specifikací procesů), návrh fyzické databáze, sestavení hierarchie funkcí modulu, které mají být naprogramovány, odhad nákladů na realizaci.

Uvedené práce by měli provádět konzultanti analytici spolu se systémovými designéry – zde je hranice oddělující poradenství a vývoj. Přesto je žádoucí, aby ve fázi implementace systému poradce jednal i v zájmu zákazníka, a to: softwarový systém systémové a technické projekty, a podílel se i na pracích na jeho rozšíření a úpravě, tk. rozšíření by měla být plánována na základě modelu požadavků.

- technické projekční práce:

Vývoj obecných řešení pro systém a jeho části,

Vývoj obecných řešení pro funkcionálně-algoritmické struktura systému,

Vývoj společných rozhodnutí o personálních funkcích a organizační struktuře,

Vývoj společných řešení pro strukturu technických prostředků,

Vývoj obecných řešení pro algoritmy řešení problémů a používané jazyky,

Vývoj společných řešení pro organizaci a udržování informační základny,

Vývoj společných řešení pro systém klasifikace a kódování informací,

Vývoj společných softwarových řešení;

Provést vypracování, provedení dokumentace ke všem částem projektu včetně dokladu "Formulace problému",

Vypracování a provedení dokumentace pro dodávku produktů pro pořízení AIS a/nebo technické požadavky(technické specifikace) pro jejich vývoj;

Vypracování návrhových úloh v navazujících částech projektu objektu automatizace.

Dílčí fáze 3." Pracovní design » spojené s fyzickou realizací vybrané varianty projektu a přijetím podrobné projektové dokumentace (DP).

Tato dílčí etapa se provádí:

Vypracování a zpracování pracovní dokumentace obsahující všechny potřebné a dostatečné informace pro zajištění realizace prací na zprovoznění AIS a jeho provozu, jakož i pro udržení úrovně provozních charakteristik (kvality) systému v souladu s přijatými projektová rozhodnutí a koordinaci a schvalování této dokumentace;

Vývoj programů a softwarových nástrojů systému, jakož i výběr, přizpůsobení a/nebo vazba zakoupených softwarových nástrojů,

Vývoj softwarové dokumentace.

Organizace výběrových řízení na dodávky komponent AIS (software a hardware, softwarové a hardwarové systémy, informační produkty).

Obrázek 34. Sled prací ve fázi návrhu životního cyklu AIS.

Za přítomnosti zkušeností s designem a malé složitosti projektu jsou všechny tři dílčí fáze spojeny do jedné, v důsledku čehož je získán jediný technologický projekt (TDP). V tomto případě se projekt důsledně, jak jsou dílčí etapy dokončovány, transformuje z návrhu na detailní návrh.

Třetí etapa Implementace» (Obr. 35) je fyzický návrh systému v následujícím pořadí:

1) příjem a instalace technických prostředků;

2) kódování, testování a vývoj programů;

3) získání a instalace softwaru;

4) tvorba informační podpory včetně naplňování databází;

5) vývoj návodů pro obsluhu softwaru a hardwaru, jakož i popis práce pro personál.

Tyto práce lze prakticky provádět paralelně.

Ve čtvrté fázi životního cyklu AIS " Implementace» jsou následující dílčí kroky:

1) pilotní implementace:

zprovoznění technického zařízení,

zprovoznění softwarových nástrojů, provedení zkušebního provozu všech komponent a systémů jako celku,

· školení a certifikace personálu.

Pilotní implementace spočívá v kontrole provozuschopnosti prvků a modulů projektu, odstraňování chyb na úrovni prvků a vazeb mezi nimi.

V této fázi se pracuje na organizační školení automatizační objekt uvést AIS do provozu, včetně:

Implementace návrhových rozhodnutí o organizační struktuře AIS;

Poskytování útvarů řídicího objektu instruktážními a metodickými materiály;

Zavádění klasifikátorů informací;

Výcvik,

Kontrola jeho schopnosti zajistit fungování AIS.

Ve stejné fázi je AIS doplněn o dodávané produkty (software a technické prostředky, softwarové a hardwarové komplexy, informační produkty), dále konstrukce a instalace, uvedení do provozu, předběžné testy:

Provádět zkoušky AIS na výkon a plnění zadání v souladu s předem připraveným programem a metodikou předběžných zkoušek;

Odstraňování závad a zlepšování (v případě potřeby) softwaru, provádění změn dokumentace AIS včetně provozní dokumentace v souladu se zkušebním protokolem.

Pilotní implementační práce končí dne vypracování zákona o ukončení zkušebního provozu.

2) průmyslová realizace (uvedení do komerčního provozu):

uvedení do provozu,

Podepisování aktů o převzetí a předání díla.

Uvedení do provozu spočívá v organizaci ověřování projektu na úrovni funkcí a sledování plnění jeho požadavků formulovaných ve fázi předprojektového průzkumu, tj.

Provést zkoušku shody se zadáním v souladu s předem připraveným programem a metodikou akceptačních zkoušek;

Analýza výsledků testů AIS a odstranění nedostatků zjištěných při testech.

Dokončovací práce na vypracování zákona o převzetí AIS do trvalého provozu.

V poslední páté fázi životního cyklu AIS, provoz, údržba a modernizace software, hardware a celý projekt.

Doprovod AIS leží v provedení prací v souladu se záručními povinnostmi, provedení prací na odstranění nedostatků zjištěných při provozu AIS ve stanovené záruční době a provedení prací na provedení potřebných změn dokumentace k AIS.

Pozáruční servis se skládá z:

Při provádění prací na analýze fungování systému;

při zjišťování odchylek skutečných provozních charakteristik AIS od návrhových hodnot;

Při zjišťování příčin těchto odchylek;

při odstraňování zjištěných nedostatků a zajišťování stability provozních charakteristik AIS;

Při provádění nezbytných změn v dokumentaci pro AIS.

V závislosti na specifikách vytvářených AIS a podmínkách pro jejich tvorbu je umožněno provádět jednotlivé etapy prací před dokončením předchozích etap, paralelní provádění etap prací v čase, zařazení nových etap prací.

Obrázek 35. Fáze životního cyklu AIS.

Životní cyklus je obvykle iterativní: dokončené etapyŽivotní cykly, počínaje těmi nejranějšími, se cyklicky opakují v souladu s novými požadavky a změnami vnějších podmínek. V každé fázi životního cyklu se tvoří soubor dokumentů a technických řešení, které jsou východiskem pro následná rozhodnutí.

Nejrozšířenější tři modely životního cyklu:

kaskádový model (do 70. let) - sekvenční přechod do další etapy po dokončení předchozí;

· iterativní model (70. - 80. léta) - s iterativními návraty do předchozích fází po dokončení další fáze;

· spirálový model (80-90s) - prototypový model, který předpokládá postupné rozšiřování prototypu AIS.

Pro kaskádový model životního cyklu typická je automatizace samostatných nesouvisejících úkolů, která nevyžaduje informační integraci a kompatibilitu, softwarové, technické a organizační rozhraní. V rámci řešení jednotlivých problémů se kaskádový model osvědčil z hlediska doby vývoje a spolehlivosti. Aplikace tohoto modelu životního cyklu na velké a složité projekty vede z důvodu dlouhého trvání procesu návrhu a variability požadavků během této doby k jejich praktické nerealizovatelnosti.

Iterativní model životního cyklu. Při tvorbě komplexního AIS dochází k propojování konstrukčních řešení získaných při realizaci jednotlivých úkolů. Konstrukční přístup „zdola nahoru“ vyžaduje takové iterativní návraty, kdy se návrhová řešení jednotlivých úloh dotvářejí do obecných systémových řešení a zároveň je potřeba revidovat dříve formulované požadavky. V důsledku velkého počtu iterací zpravidla vznikají nesrovnalosti v dokončených konstrukčních rozhodnutích a dokumentaci. Záměna funkčního a architektura systému vytvořený AIS, obtížnost použití projektové dokumentace způsobuje nutnost přepracování celého systému ve fázích implementace a provozu. Dlouhý životní cyklus vývoje informačního systému končí fází implementace, po níž následuje životní cyklus vytvoření nového AIS.

Spirální model životního cyklu. K organizaci návrhu AIS se používá přístup shora dolů, kdy je nejprve stanovena skladba funkčních subsystémů a poté nastavení jednotlivých úkolů. V souladu s tím jsou nejprve vyvinuty takové celosystémové problémy, jako je organizace integrované databáze, technologie pro shromažďování, přenos a shromažďování informací a poté technologie pro řešení specifických problémů. V rámci komplexů úloh se programuje směrem od hlavních programových modulů k modulům, které plní jednotlivé funkce. Zároveň se do popředí dostávají otázky interakce mezi rozhraními programových modulů mezi sebou a s databází a do pozadí se dostává implementace algoritmů.

Každé otočení spirály odpovídá krok za krokem modelu pro vytvoření fragmentu AIS. Vyjasňuje cíle a charakteristiky projektu, určuje jeho kvalitu a naplánuje práci na další zatáčce spirály. Dochází k důslednému prohlubování a konkretizaci detailů projektu, formuje se jeho podložená verze, která je přivedena k realizaci.

Spirální model životního cyklu je založen na využití prototypové technologie nebo technologie RAD (rychlý vývoj aplikací).

Podle této technologie je AIS vyvíjen rozšiřováním softwarových prototypů, po cestě od specifikace požadavků ke specifikaci programového kódu.

S prototypovou technologií se přirozeně snižuje počet iterací a je méně chyb a nesrovnalostí, které je třeba při dalších iteracích opravovat, samotný návrh probíhá rychlejším tempem a zjednodušuje se tvorba projektové dokumentace. Aby více odpovídala projektové dokumentaci vyvinuté AIS, je stále větší důraz kladen na udržování celosystémového úložiště a automatizaci návrhu, zejména využití technologií CASE (Computers Aids System Engineering).

Při použití spirálového modelu:

· dochází ke shromažďování a opětovnému použití návrhových řešení, návrhových nástrojů, modelů a prototypů AIS a informačních technologií;

· Orientace na vývoj a úpravy systému a technologií v procesu jejich návrhu;

· v procesu návrhu systému se provádí analýza rizik a nákladů.

Rozhraní je párování částí softwaru a hardwaru, dat, technologie pro komunikaci mezi člověkem a počítačem, ve kterém všechny informace, logické, fyzické a elektrické parametry splňují stanovené normy.

Prototyp – minimální verze systému použitá pro generování nebo vývoj plné verze

Úložiště obsahuje informace o objektech navrženého AIS a vztazích mezi nimi, data si s ním vyměňují všechny subsystémy.

Modely životního cyklu AIS - Struktura, která definuje sekvenční implementaci procesů, akcí, úkolů prováděných v průběhu životního cyklu a vztah mezi těmito procesy.

kaskádový model. Přechod do další fáze znamená úplné dokončení práce v předchozí fázi. Požadavky definované ve fázi tvorby požadavků jsou přísně dokumentovány formou zadání a fixovány po celou dobu vývoje projektu. Každá fáze vyvrcholí vydáním kompletní sady dokumentace dostatečné pro pokračování vývoje dalším vývojovým týmem.

Fáze projektu podle vodopádového modelu:

1. Tvorba požadavků;

2. Design;

3. Vývoj;

4. Testování;

5. Úvod;

6. Provoz a údržba.

výhody:

-Úplná a schválená dokumentace v každé fázi;

-Stanovené pořadí pracovní sekvence;

- Umožňuje jasně plánovat načasování a náklady.

nedostatky:

-Významné zpoždění při získávání hotových výsledků;

- Chyby v některé z fází jsou detekovány v dalších fázích, což vede k nutnosti vracení a přeevidování projektové dokumentace;

- Potíže s řízením projektů.

spirálový model. Každá iterace odpovídá vytvoření fragmentu nebo verze softwaru, objasňuje cíle a charakteristiky projektu, hodnotí kvalitu získaných výsledků a plánuje práci na další iteraci.

Každá iterace - dokončené vývojové cykly v podobě 1. verze AIS.

Kroky iterace:

1.Tvorba požadavků

3.Design

4.Vývoj

5.Integrace

Při každé iteraci se hodnotí:

Riziko překročení podmínek a nákladů projektu;

Potřeba provést další iteraci;

Stupeň úplnosti a přesnosti pochopení požadavků na systém;

Vhodnost ukončení projektu.

výhody:

-Zjednodušuje proces provádění změn v projektu;

- Poskytuje větší flexibilitu při řízení projektů;

- Možnost získání spolehlivého a stabilního systému, protože chyby a nekonzistence jsou nalezeny při každé iteraci;

- Vliv zákazníka na práci v procesu kontroly každé iterace.

nedostatky:

-Složitost plánování;

-Intenzivní režim práce pro vývojáře;

-Plánování práce je založeno na zkušenostech a není k dispozici dostatek metrik pro měření kvality každé verze.

Požadavky na technologii návrhu, vývoje a údržby AIS

Designová technologie- definuje kombinaci tří složek:

- postup krok za krokem, která určuje posloupnost technologických konstrukčních operací;

- pravidla pro hodnocení výsledků technologických operací;

- předložení vývoje návrhu ke kontrole a schválení.

Technologické pokyny, které tvoří hlavní náplň technologie, by se měly skládat z popisu sledu technologických operací, podmínek podle toho, která ta či ona operace se provádí, a popisů samotných operací.

Technologie pro navrhování, vývoj a údržbu IS musí splňovat následující Obecné požadavky:

Technologie musí podporovat celý životní cyklus softwaru;

Technologie by měla zajistit garantované dosažení cílů rozvoje IS v dané kvalitě a ve stanoveném čase;

Technologie by měla poskytovat možnost provádění prací na návrhu jednotlivých subsystémů v malých skupinách (3-7 osob). Důvodem jsou principy týmové ovladatelnosti a zvýšení produktivity minimalizací počtu externích odkazů;

Technologie by měla poskytovat možnost správy konfigurace projektu, údržbu verzí projektu a jeho součástí, možnost automatického vydávání projektové dokumentace a synchronizaci jejích verzí s verzemi projektu;

Použití jakékoli technologie pro návrh, vývoj a údržbu IS v konkrétní organizaci a konkrétním projektu je nemožné bez vypracování řady standardů (pravidel, dohod), které musí všichni účastníci projektu dodržovat. K takovým standardy zahrnout následující:

- konstrukční standard;

- norma pro návrh projektové dokumentace;

- standardní uživatelské rozhraní.

Požadavek na vývoj

- Provádění prací na tvorbě softwaru;

Příprava na zavedení AIS;

Kontrola, testování hlavních indikátorů projektu.

Doprovodné požadavky

Dokončení implementace CIS by mělo být doprovázeno zveřejněním systému správních předpisů a náplní práce, které určují fungování organizace. Od okamžiku zprovoznění informačního systému probíhá provoz na základě „Předpisů pro fungování informačního systému“ a řady předpisů. Údržbu systému a jeho nepřetržitý provoz zajišťuje útvar organizace pověřený příslušnou objednávkou. Dolaďování informačního systému po uvedení do provozu probíhá v souladu s jednotlivými projekty a zadáním.

V procesu udržování CIS je úkolem udržet jeho životaschopnost. Životaschopnost CIS je do značné míry dána tím, jak odpovídá skutečným úkolům a potřebám univerzity, které se v průběhu životního cyklu CIS mění.

Úvod

1. Architektura automatizovaných informačních systémů a problémy jejího zdokonalování 13

1.1. Modely architektury a hlavní komponenty AIS 13

1.2. Problémy s vývojem AIS 47

1.3. Platformy pro implementaci nové architektury AIS UP 53

1.4. Kapitola 1 Závěry 57

2. Model architektury AIS UE 58

2.1. Základní požadavky na AIS UP 59

2.2. Architektura AIS UP 66

2.3. AIS UP 89 součástek

2.4. Kapitola 2 Závěry 102

3. Metody praktické implementace AIS UE 104

3.1. Nástroje vývoj AIS UP 104

3.2. Zkušenosti s praktickou implementací modelu AIS UP 111

3.3. Kapitola 3 Závěry 123

4. Závěr 125

5. Terminologie a zkratky 128

6. Literatura

Úvod do práce

Činnost moderních podniků je spojena s pohybem vzájemně závislých a objemových toků materiálových, finančních, pracovních a informačních zdrojů. Řízení procesů výrobního a obchodního cyklu v dynamicky se měnícím politickém a ekonomickém prostředí vyžaduje rychlé rozhodování v krátkém čase. Řešení tohoto problému v moderní podmínky nemožné bez použití automatizovaného zpracování technických ekonomické informace.

Za posledních 40 let byly k řešení problémů účetnictví, plánování a analýzy aktivně využívány automatizované informační technologie (IT). ekonomická aktivita podniky různých forem vlastnictví, odvětvové příslušnosti, Organizační struktura a rozsah činnosti. Za tuto dobu bylo nashromážděno mnoho praktických zkušeností při vytváření automatizovaných informačních systémů pro řízení podniku (AIS UE), byly vyvinuty a všeobecně uznávány metodiky řízení, jejichž aplikace je mimo počítačové prostředí nemožná. S plnou odpovědností lze říci, že AIS UE se stal nedílnou součástí podnikové infrastruktury. Teoretické a praktické problémy automatizace ekonomických procesů jsou hluboce studovány v dílech Glushkova V.M., Volkova S.I., Isakova V.I., Ostrovského O.M., Podolského V.I., Ratmirova Yu.A., Romanova A.N., Hotyashova E.N., Bradyho R., Zachmana J., Cook M., Finkelstein K., Hammer M. a další autoři. Jimi navržené přístupy se staly základem pro využití výpočetní techniky v podnicích při řešení problémů účetnictví, plánování a analýzy finančních a ekonomických činností. nicméně

modely, které navrhovaly, nezohledňovaly realitu ekonomiky informační společnosti a současnou úroveň rozvoje IT.

Rozvoj komunikačních prostředků přispívá ke stále užší interakci mezi výrobci a spotřebiteli, dodavateli a kupujícími, zvyšuje konkurenci na trhu, rozšiřuje hranice lokálních trhů na národní a nadnárodní a zrychluje dobu ekonomických transakcí a finančních transakcí. Implementace globální počítačové sítě v ekonomické procesy vedly ke vzniku nových konceptů: ekonomie informační společnosti, e-business(e-business), elektronický obchod(e-commerce), elektronický obchodní patro(e-tržiště);

Stávající koncepce organizace AIS UE jsou založeny na funkčním přístupu k rozdělení úkolů mezi jejími subsystémy. AIS, budovaný jako komplex subsystémů zaměřených na jednotlivé řídící funkce, však nevyhovuje nejlépe požadavku kontinuity end-to-end podnikových procesů podniku. Proto je v posledních letech stále populárnější přístup, kdy jsou do popředí kladeny podnikové procesy, a nikoli jednotlivé funkce služeb systému řízení, které je provádějí. Potřebuje vývoj nový koncept Architektura AIS UE. Zároveň je zřejmé, že přechod na novou architekturu AIS UE nelze provést najednou, protože v průběhu let podniky a organizace uvedly do provozu velké množství softwarových nástrojů, které implementují řešení důležitých úkolů řízení. , od jehož užívání nelze okamžitě upustit. Bohužel většina z nich je zaměřena na autonomní fungování, což značně komplikuje složitou integraci informačních toků. Řada existujících softwarových produktů, které poskytují podporu pro řešení nových problémů podnikového řízení, které vyvstaly v souvislosti s globalizací ekonomiky, je rovněž vyvíjena bez dostatečného propracování rozhraní pro interakci se softwarovými systémy, které implementují řešení souvisejících problémů. Za těchto podmínek je zvláště důležitý úkol syntetizovat integrované systémy řízení podniku integrací běžně dostupných komponent třetích stran, zákaznických řešení a vlastního vývoje.

V publikacích vědců a praktiků se již dlouho diskutuje o myšlence implementace standardů pro systémovou integraci softwarových nástrojů dodávaných různými výrobci. Pokrok systémových nástrojů vedl ke vzniku objektově orientovaných a komponentních softwarových vývojových technologií, které umožňují budovat rozsáhlé systémy z hotových bloků. Přední dodavatelé hardwaru a systémového softwaru (Intel, Microsoft, Sun, Oracle, IBM atd.), komunikačních nástrojů (Cisco, Nortel, Ericsson, Motorola), aplikovaných řešení (SAP, PeopleSoft, Siebel atd.), autoritativní stát, mezinárodní, obchodní a nezisková organizace a asociace (ISO, IEEE, ASCII, APICS, RosStandard atd.) již vyvinuly a aktivně zavádějí do praxe technologie pro integraci hardwaru a softwaru, které umožňují vytvářet otevřené systémy založené na standardech a protokolech pro výměnu dat a interakci komponent v heterogenní prostředí v režimu reálného času.

Tyto návrhy však poskytují pouze celosystémovou platformu, která vyžaduje značné upřesnění ve vztahu ke konkrétní oblasti. V kontextu praktické implementace AIS UE nejsou dostatečně rozvinuty mechanismy pro navrhování a vývoj informačních systémů (IS) využívajících komponentní vícelinkové architektury založené na standardech a protokolech otevřených systémů.

V tomto ohledu se stává naléhavým problém rozvoje teoretické platformy a vypracování praktických doporučení zaměřených na vybudování AIS UE, který poskytuje komplexní automatizaci všech informačních postupů pro řízení podniků a organizací.

Potřeba vyvinout holistický přístup k řešení problematiky systémové integrace AIS PM a end-to-end automatizace mikroekonomických procesů na bázi moderních IT předurčila volbu tématu a směr této studie.

Cílem studia je vyvinout model architektury AIS UE, který poskytuje komplexní automatizaci a informační podporu pro end-to-end podnikové procesy, a zdůvodnit volbu nástrojů pro jeho systémovou integraci z pohledu moderních informačních technologií.

Na základě zamýšleného cíle byly stanoveny a vyřešeny následující vědecké a praktické úkoly:

Analyzovat a zobecnit existující přístupy k návrhu, vývoji a implementaci softwaru AIS UP;

Klasifikovat typy softwaru používaného v praxi podnikového managementu;

Prozkoumejte stávající technologie a standardy, které poskytují integraci heterogenních softwarových nástrojů;

Identifikovat problémy, které vznikají při integraci softwarových nástrojů používaných v AIS UE;

Zajistit systematizaci požadavků stanovených podniky pro software AIS UE informační podpora prostřednictvím ekonomických procesů;

Vyvinout model architektury AIS UE a zdůraznit její hlavní součásti;

Rozvinout principy interakce a výměny dat komponent AIS UE;

Předmětem výzkumu jsou metody a nástroje pro vývoj ekonomických informačních systémů.

Předmětem studia je IS řízení podniku.

Metodologie výzkumu je založena na konkrétních aplikacích metodologie vědeckého poznání v aplikovaných oblastech informatiky a matematiky.

Cíle a záměry studia byly formulovány v souladu s hlavním směrem práce na dalším rozvoji a zdokonalování matematických metod a výpočetní techniky používaných v ekonomických předmětech.

Spolu s obecným vědeckým přístupem založeným na teorii systémů shrnuje disertační práce zkušenosti s vývojem, implementací a provozováním softwarových nástrojů tuzemských i zahraničních výrobců, metod

implementace mezinárodních otevřených standardů pro informační systémy budov. Na tomto základě je navržen soubor metodických a praktických doporučení, která byla testována v ruských a zahraničních podnicích.

Příspěvek využívá teoretická ustanovení děl domácích i zahraničních autorů z oblasti:

Automatizované zpracování ekonomických informací a modelování ekonomických procesů;

Metodiky plánování a operativního řízení výroby a zásob;

Reengineering a počítačový návrh obchodních procesů;

Moderní standardy v informačních technologiích.

V průběhu studie byl sledován vývoj výzkumných týmů a jednotlivých vědců na Finanční akademii pod vládou Ruské federace, Všeruského korespondenčního institutu financí a ekonomiky v Moskvě. státní univerzita Ekonomika, statistika a informatika, Petrohradská univerzita ekonomie a financí. Voznesenského, Výzkumného finančního ústavu a dalších organizací.

Informační základ studie tvořily softwarové produkty ruských a zahraničních výrobců, publikace v ekonomických a počítačových publikacích, výzkumy mezinárodních výzkumných skupin Gartner Group, Aberdeen, IDC, MetaGroup, DataQuest aj. učební materiály přední tuzemské i mezinárodní poradenské a auditorské společnosti, výsledky výzkumů Asociace softwarových vývojářů v oblasti ekonomiky,

průzkum softwarového trhu v Rusku a zemích SNS TSIES "Business-Programs-Service" .

Vědecká novinka disertační práce spočívá ve vývoji modelu architektury AIS UE zaměřeného na integrovanou automatizaci podnikových procesů typu end-to-end a v návrzích na jeho implementaci prostřednictvím systémové integrace heterogenních softwarových nástrojů v distribuovaném heterogenním síťovém prostředí založeném na objektové a komponentní technologie.

Vědecká novinka obsahuje tyto výsledky získané v dizertační práci:

Definice a klasifikace požadavků na funkčnost Software pro organizační a ekonomické řízení podniků;

Model architektury AIS UE zaměřený na integrovanou automatizaci podnikových procesů typu end-to-end;

Principy integrace softwarových nástrojů pro řešení problémů funkčních služeb podniku se základním softwarem pro řízení obchodních procesů, výměnu dat a správu dokumentů;

Návrhy na uspořádání jednotného informačního prostoru podniku, dostupného zaměstnancům a partnerům podniku prostřednictvím podnikového webového portálu;

Návrhy na implementaci jednotného systému tvorby a klasifikace reportingu s využitím analytických nástrojů;

Principy pro implementaci interakce subsystémů AIS UE založených na objektově orientovaných a komponentových technologiích a interakci softwarových komponent v distribuované síti

prostředí v souladu s průmyslovými standardy a internetovými protokoly;

Mechanismus pro implementaci adaptivních vlastností modelu architektury softwaru AIS UE v souladu s požadavky konkrétního podniku, založený na schopnosti konfigurovat základní subsystémy na existující a projektované pracovní procesy.

Praktický význam disertační práce spočívá v tom, že realizace navržených návrhů umožňuje vytvořit AIS UE, poskytující efektivní podporu informačních postupů pro řízení činnosti podniku v kontextu globalizované ekonomiky a formování informační společnosti.

Navržený model architektury AIS UE a doporučení pro jeho aplikaci mají dostatečnou flexibilitu a všestrannost, která zajišťuje jejich použitelnost při budování řízení IS podniků různých forem vlastnictví, oborových specifik a rozsahu činnosti.

Nezávislá praktická hodnota má:

Návrhy na výběr a aplikaci standardů, protokolů a dalších mechanismů používaných v systémové integraci AIS UE;

Nabídky pro integrovaná automatizace komplexní obchodní procesy a pracovní postupy;

Návrhy na vytvoření jednotného informačního prostoru podniku s využitím mechanismu webových portálů;

Návrhy na přizpůsobení spirálově iterativního přístupu při vývoji a implementaci softwaru AIS UP.

Praktický význam práce byl hodnocen v konkrétních projektech pro implementaci navrženého problémově orientovaného modelu podnikového automatizačního systému:

Integrovaný systém řízení podniku "Flagman" společnosti "Infosoft",

Systémy řízení vztahů se zákazníky eRelationship společnosti Pivotal Software Corporation (Kanada),

Firemní reportingové systémy Monarch ES společnosti DataWatch (USA),

Projekt integrace informačních systémů společností Sovintel a Tele Ross.

Školicí středisko Vest-MetaTechnology využívá materiály připravené autorem na základě přístupu navrženého v průběhu této studie při vedení kurzů o vývoji informačních systémů pro řízení podniku (viz http://www.vest.msk.ru).

Výzkumné materiály disertační práce se používají ve výzkumu a praktické činnosti výkonnými orgány Asociace softwarových vývojářů v ekonomice (AREP) a jejími členy.

Hlavní ustanovení práce byla oznámena a projednána na adrese:

Konference "Řešení IBM v oblasti obchodní integrace pro telekomunikační společnosti", zastoupení IBM ve východní Evropě (Moskva, 18. června 2002);

Symposium "Call Center CRM Solutions 2002/Call Centers and Customer Relationship Management" (Moskva, březen 2002);

Konference vývojářů informačních systémů založených na nástrojích korporace Centura Software Corp. (Berlín, Německo, 17.-19. listopadu 1999);

Konference "InfoCity: praxe a problémy informatizace měst" (Moskva, říjen 1999);

Vědecké a praktické konference společnosti "Infosoft" (Moskva, 1995-1999);

Konference specialistů v oblasti ACS a CIS " Podnikové systémy"(Moskva, duben 1998 a 28.-30. dubna 1997, organizátoři: společnost SoftService a zastoupení Oracle, Informix, Sybase, Borland a Centura);

3. ročník konference "Firemní databáze 98" (Moskva, 31. 3. - 3. 4. 1998 a 26. - 29. 3. 1996, pořádané Centrem informačních technologií za účasti Nakladatelství Open Systems);

Konference "Tekhnikom-97" (Moskva, 24.-26. listopadu 1997, organizátoři: SoftService, Ruská asociace uživatelů Oracle, zastoupení Microsoft, Borland, Computer Associates, Lucent Software).

Problémy vývoje AIS

Zavádění informačních technologií do ekonomiky, pronikání počítačových a komunikačních nástrojů do řízení podniku na všech úrovních, rostoucí zájem o interakci podniků prostřednictvím internetu vyžadují koncepční změny v přístupech k budování AIS UE. To se týká nejen čistě technologických problémů tvorby a provozu IS, ale také přístupů k řízení podniku v ekonomice informační společnosti.

AIS UE by měl splňovat potřeby automatizace a informatizace v celé organizaci, což dává vývojářům softwaru za úkol: vyvinout platformu, která může podporovat práci velkého počtu uživatelů; podpora komunikačních nástrojů a průmyslových standardů pro výměnu dat a protokoly interakce komponent; integrace stávajícího vývoje do jednoho systému.

Integrace heterogenních aplikací v rámci jediného AIS by měla poskytnout podporu pro: end-to-end obchodní procesy; jediné uživatelské rozhraní (portál); společný informační prostor.

Podle našeho názoru není podstata nastolených problémů ani tak v technických aspektech implementace, ale v nutnosti použít zásadně nový model architektury AIS UE.

Shrňme si klady a zápory různých variant architektury IS z hlediska možností vybudování integrovaného řešení.

Centralizace zpracování dat dělá vysoké požadavky na servery. S nárůstem počtu souběžných uživatelů (což je nevyhnutelné při automatizaci procesů v celém podniku) se zátěž stává nadměrnou pro hardwarovou platformu a používaný software. Pomocí různých hardwarových řešení (clustering, multiprocessing a další formy kombinování výpočetních zdrojů), stejně jako distribuovaného zpracování pomocí transakčních monitorů, aplikačních serverů a výkonného průmyslového DBMS, můžete vytvářet skutečně škálovatelná řešení, odlehčující centrální uzly nejen zvýšením výkonu hardwaru, ale také díky vhodné konstrukci softwarových komponent systému.

I když je však centrální databázový server schopen poskytnout požadovaný výkon, při takové konstrukci IS nevyhnutelně vznikají problémy s udržením jednotné struktury společné databáze, pokud jednotlivé softwarové komponenty IS vyvíjejí různé společnosti nebo dokonce vývojové týmy v rámci stejná organizace. Instalace společné databáze s přístupem z programů pro řešení různých aplikovaných problémů umožňuje poskytnout společný informační prostor, výše uvedené technologie umožňují přístup k databázi velkému počtu uživatelů, ale to nezaručuje správnou práci se sdílenými daty. Zůstává problém logické integrity dat. Při používání programů od různých výrobců se stává nevyhnutelné rozdělovat data do subsystémů, případně jejich denormalizací a vytvářením redundantních struktur. Schematická architektura s společná základna znázorněno na následujícím obrázku (Obrázek 1-14). Jak vyplývá z výše uvedeného diagramu, moduly neinteragují, to znamená, že nedochází k volání z jednoho modulu do druhého v reálném čase, neexistuje žádná provozní podpora pro end-to-end proces. Data se ukládají do databáze, ze které jsou dostupná dalším modulům, které v ní potřebují obsahovat funkce sledování změn a relevance dat závisí na frekvenci kontroly aktualizací. Příkladem end-to-end procesu může být fakturace zaměstnancem obchodního oddělení. Pokud k tomu využívá CRM systém, vygenerovaná faktura musí být zpracována souběžně s výpisem v modulu logistiky ERP systému pro rezervaci zboží a hned poté - ve finančním modulu pro navýšení dluhu kupujícího. K tomu musí příslušné moduly zkontrolovat existenci nového účtu. Pokud tak není učiněno včas, může být vystavena faktura na skutečně rezervovanou položku.

Aby různé moduly mohly pracovat se společnou databázovou strukturou, musí být zpočátku vyvinuty s ohledem na konkrétní datovou strukturu nebo použít dohodnutý mechanismus metadat (úložiště).

Při použití jiné architektury, kdy jsou heterogenní databáze udržovány na různých počítačích (a případně v různých sítích) a používány autonomními moduly (obrázek 1-15), je udržování logické integrity dat ještě časově náročnější úkol. . V tomto případě je nutné regulovat a implementovat replikaci dat (synchronizaci), sjednocení adresářů, kódovacích a klasifikačních pravidel, vyvinout či implementovat samotný replikační mechanismus. To vše vyžaduje organizační opatření k synchronizaci databáze. Zůstává problém automatického pokračování procesu (příklad s fakturou).

Platformy pro implementaci nové architektury AIS UE

Na počátku 21. století byla na průmyslové úrovni v IT průmyslu vyvinuta a zvládnuta následující řešení, která zajistila široké zavedení IT do ekonomických procesů:

osobní výpočetní nástroj, spočívající v tom, že u mnoha typů prací zmizela potřeba prostředníků mezi zadáním úkolu a jeho vykonavatelem, to znamená, že zaměstnanci podnikových funkčních služeb jsou schopni provádět informační postupy v rámci své působnosti pomocí počítačů bez zapojení nebo s minimální podporou doprovodného technického personálu;

prostředky automatizované podpory pro koordinované společná práce skupiny („týmy“) pracovníků na jednom projektu, dokumentu, úkolu apod.;

mechanismus elektronické komunikace, který v mnoha případech umožnil eliminovat potřebu přenášet papírové dokumenty, minimalizovat potřebu schůzek, což je zvláště důležité, když účastníci jednoho nebo druhého obchodní proces.

Díky těmto řešením bylo možné automatizovat většinu pracovních procesů probíhajících jak v rámci podniku v jeho finančních, ekonomických, výrobních a obchodních činnostech, tak souvisejících s externími funkcemi. Kombinace softwarových a hardwarových nástrojů, které automatizují různé funkce a pracoviště, umožňuje propojit technologické (založené na vybavení a technických zařízeních) a pracovní procesy (za účasti zaměstnanců všech oddělení podniků) do ucelených podnikových procesů. . Existuje tak zásadní možnost řešení problému izolace míst původu dat od center jejich ukládání a zpracování, oddělení pracovišť od sebe.

Řešení problému integrace modulů AIS a volba centralizovaného nebo decentralizovaného přístupu k organizaci jejich interakce je také možné díky nejnovějšímu vývoji předních výrobců systémového softwaru: operační systémy, webové servery, aplikační servery, DBMS a middlewarové platformy. Integrace aplikací je možná díky použití objektově orientované vývojové technologie a vícevrstvé architektury založené na komponentách. Klíčovým principem je zde koncept programovacích rozhraní a pravidla pro jejich změnu a rozšiřování (IDL).

Pro práci v distribuovaném heterogenním prostředí, jako je internet, se aktivně vyvíjejí specifikace webových služeb, z nichž každá může implementovat jednu nebo více obchodních procedur nebo funkcí (obchodní procedury, funkce). OASIS, BPMI a IBM, Microsoft a BEA zveřejnily specifikace regulace pracovních postupů BPEL4WS (Business Process Execution Language for Web Services), XLANG a WSFL (Web Services Flow Language) a koalici WfML - XPDL (XML Process Definition Language) .

Trendem je kombinovat komponenty s otevřenými rozhraními webových služeb do subsystémů, které provádějí logicky kompletní cykly obchodních procesů. V tomto případě mohou být komponenty umístěny na různých aplikačních serverech distribuovaných po síti a pracovat s jednou nebo více databázemi. Změnou počtu a vztahů komponent, počtu a umístění síťových serverů, možností výměny komponent nebo jejich přesunu po síti bez ztráty kompatibility je možné vybudovat AIS, který zachovává rovnováhu centralizace a decentralizace v podniku. řízení.

Neexistují žádné technické překážky pro implementaci takové architektury. Moderní průmyslové aplikační servery (například MTS / COM + / .Net, ONE nebo J2EE / EJB) vám umožňují budovat vícevrstvé systémy, poskytují společnou platformu pro přístup k různým webovým službám, poskytují transakční integritu operací, vyvažování zátěže s konkurenční přístup desítek tisíc uživatelů v reálném čase, stejně jako záruka odolnosti proti chybám a obnovy po selhání.

Důležitým úspěchem IT průmyslu jsou standardy, které se staly rozšířenými a uznávanými předními výrobci softwaru: protokoly interakce komponent (COM / DCOM, CORBA, Java RMI) a formáty pro výměnu dat (EDI, XML,).

Standard EDI a jeho oborově specifické varianty (EDIFACT, XI2, HIPAA atd.) se ve finančním a průmyslovém sektoru Severní Ameriky a Evropy používají od poloviny 70. let a dnes dominují po celém světě. S rostoucí popularitou XML na internetu bylo EDI přeloženo do XML.

Na základě XML (DTD a XDR) byla vyvíjena, strukturována a formátována data v různých ekonomických oblastech ve formě tzv. předmětových slovníků nebo typů dokumentů, např. WIDL, OFX, FpML, IFX, XBRL, CRML a mnoho dalších na Západě, stejně jako CommerceML.ru a XML Partnership/ARB v Rusku. Americká společnost pro výrobu a řízení zásob APICS, která certifikuje systémy třídy ERP / MRP, zveřejňuje specifikace ekonomické subjekty ve formátu XML, například struktura a formát zákaznických nebo fakturačních údajů. Samodokumentování XML poskytuje jednoznačné pochopení dat jak lidmi, tak programy.

Architektura AIS UE

Abychom vytvořili model architektury AIS UE, budeme uvažovat o podniku jako o souboru pracovních, finančních, materiálních a informačních zdrojů zapojených do obchodních procesů k dosažení obchodních cílů podniku. Pod pojmem obchodní cíle se zde rozumí strategické dlouhodobé cíle stanovené vlastníky a vrcholovými manažery a také aktuální cíle stanovené vrcholovými a středními manažery. Obchodní proces nebo obchodní proces je posloupnost akcí zaměstnanců, operací na pracovištích a také funkcí prováděných softwarem a hardwarem v automatickém režimu. Nazvěme každou akci nebo její sekvenci fází procesu. Synonyma pro akce mohou být také operace, procedury. Pokud fáze vyžaduje jednání zaměstnance (skupiny rolí, zástupce nebo vedoucího oddělení, jakož i osoby zastávající oficiální pozici), nazývá se to také úkol a zaměstnanec se nazývá vykonavatel. Posloupnost akcí v obchodním procesu může být nejednoznačná, to znamená, že popis procesu ve formě orientovaného grafu může zahrnovat větvení s podmínkami pro přechod z jedné fáze do druhé. Typické řetězce fází lze rozdělit na dílčí procesy. Přesun úkolů podle určitých fází procesu se nazývá trasa. Pokud proces nelze popsat kvůli libovolným přechodům mezi fázemi, o kterých rozhoduje performer během provádění úkolu v aktuální fázi, pak se tento případ nazývá volné směrování.

AIS PM by měl umožňovat formální popis podnikových procesů v grafické podobě ve formě orientovaného grafu (digrafu), jehož vrcholy jsou fázemi a hrany jsou přechody mezi fázemi. V konkrétním případě vypadá graf obchodních procesů schéma sítě, kde vrcholy označují úlohy s uvedením jejich trvání a orientované hrany (šipky) ukazují pořadí úloh. V souladu s popisem procesu, nazývaného procesní mapa, musí AIS UE spravovat zdroje (nebo přesněji pomáhat manažerům podniku je spravovat), přidělovat úkoly a jejich vykonavatele a také volat (aktivovat) software a hardware. spustit automatizované postupy.

Parametry rozsahu podniku ovlivňují organizaci řízení v konkrétním podniku, což se odráží v požadavcích na AIS UE. Na druhé straně AIS UE ovlivňuje rozsah podniku, například přispívá k růstu podniku. Změna jednoho z parametrů znamená aktualizaci AIS stejným způsobem, jako může zavedení AIS změnit organizaci řízení.

Smyslem zaměření na business procesy při budování AIS UE je najít společnou platformu, na jejímž základě bude možné AIS adekvátně upravovat bez nutnosti kompletní reorganizace systému. Tato platforma je modelování obchodních procesů pomocí softwaru pro řízení procesů.

Jako jádro AIS PM je nutné vyvinout systém, který kombinuje několik funkcí probíraných v revizi systémů řízení procesů (odstavce "1.1.7 Systémy řízení dokumentů" na straně 31 a "1.1.8 Systémy řízení procesů" na straně 34). Mezi nimi: Workflow - subsystém pro řízení pracovníků a technologických postupů, který poskytuje předdefinované a volné směrování úkolů mezi účinkujícími; Docflow - subsystém pro řízení toku dokumentů a směrování dokumentů se sledováním jejich stavů; Groupware - subsystém pro podporu funkcí operativního přidělování úkolů a volného směrování (ad hoc) úkolů mezi členy skupiny interpretů; Dataflow - směrování dat, datových paketů, zpráv mezi aplikacemi.

Na rozdíl od přijímané praxe autonomního používání systémů tohoto druhu zde předpokládáme přítomnost společné procesní mapy, společného modulu pro zpracování procesních fází, společného mechanismu pro přidělování exekutorů a směrování úloh a dat.

Tak vznikají technologická data technická zařízení, faktické údaje vkládané do IS uživateli na pracovištích (včetně primárních dokumentů), jakož i údaje generované o softwarových aplikací, budou vloženy do AIS UE a budou k dispozici spotřebitelům informací v reálném čase.

Schématicky je životní cyklus zpracování dat v AIS UE znázorněn na následujícím obrázku (Obrázek 2-2). Data zadaná ručně nebo přijatá ze softwarových komponent jsou formalizována jako dokument, který je dále zpracováván modulem workflow v souladu s procesní mapou. Na trase zpracování (pokud to nastavení systému vyžaduje) volá subsystém správy dokumentů moduly funkčních subsystémů pro zpracování finančních, obchodních a jiných typů transakcí. V důsledku toho jsou přihlašovací údaje uloženy ve strukturovaných databázích. Samotné dokumenty jsou zase uloženy v úložišti nebo v nestrukturované databázi. Všechny tyto databáze musí být dostupné pro analytické moduly subsystému výkaznictví, aby mohly generovat potřebné výkazy.

Zkušenosti s praktickou implementací modelu AIS UE

V letech 1995 až 1999 byl pod vedením autora práce vyvíjen systém řízení podniku Flagman společnosti Infosoft, který je v současné době implementován ve více než stovce velkých a středních průmyslových, stavebních, obchodních, zemědělských podniků a rozpočtové organizace Rusko a země SNS. Systém se nadále vyvíjí na základě jádra vyvinutého autorem a do roku 2002 „vlajková loď“ zahrnuje více než deset hlavních subsystémů, jak je znázorněno na následujícím obrázku (obrázek 3-2):

Základem systému "Flagman" je základní modul "Správa dokumentů", který je zodpovědný za zadávání, zpracování, směrování a tisk všech primárních dokumentů. Dalšími základními moduly jsou „Administrace“ a „Nástroje“, společné pro všechny funkční moduly. Umožňují konfigurovat skupiny rolí a přístupová práva, pracovní stanice až po položky nabídky, rozvržení dokumentů a šablony sestav.

Výhodou implementovaného modelu bylo jednotné zadávání prvotních dokladů, generování účtů ve funkčních podsystémech na základě těchto dokladů a sjednocení práce s prvotními doklady.

Rychlý vývoj subsystémů a nedostatečná standardizace jejich interakce vedly k tomu, že integrace probíhala kolem centrální databáze a společných tabulek. Pokud nebereme v úvahu dvouvrstvou architekturu, jejíž výběr byl dán úrovní vývoje vývojových nástrojů v roce 1995, pak se hlavním problémem vývoje systému stala křížová závislost modulů. Jeho první implementace odhalily nedostatečnost funkcí automatizace workflow samotným směrováním dokumentů a vyvolaly otázku nutnosti implementace modulu pro řízení procesů (workflow).

Pokud se zamyslíme nad implementací podrobněji, pak modul správy dokumentů je knihovna objektů obsažená ve všech subsystémech a také zkompilovaná jako samostatný modul. Knihovna obsahuje nástroje pro nastavení typů a variant dokumentů, skladbu polí, vstupní a editační formuláře, seznam stavů, možné kombinace přechodů ze stavu do stavu, seznam operací s odkazem na funkční moduly, šablony a tisk formuláře, jakož i pravidla pro tvorbu rejstříků a deníků dokumentů .

Operace s dokumenty mění jejich stav a také volají funkce aplikačních subsystémů. Seznam funkcí je součástí každého subsystému a je pro něj specifický. Pro doprovodné programátory, kteří se podílejí na nastavování systému, jsou k dispozici parametry funkcí a možnost na ně vázat pole dokumentu pomocí vzorců. To vám umožní automatizovat většinu finančních transakcí, stejně jako logistických funkcí, personální záznamy a mzdy, ale plná implementace stále vyžaduje skriptovací jazyk.

Systém má vestavěný generátor zpráv společný pro všechny podsystémy. Jelikož je systém založen na principu integrace kolem centrální databáze, má generátor přístup ke všem datům bez ohledu na to, zda patří do modulů. Sestavy jsou klasifikovány do hierarchické struktury, každé z rozložení sestav obsahuje šablonu pro náhled a tisk a SQL dotazy pro generování výsledné datové sady. Vygenerované sestavy lze dále zpracovávat jako dokumenty.

Je třeba také poznamenat, že systém Flagship implementuje jednotný vzhled subsystémy. Obecný administrační modul pro prvky uživatelského rozhraní, funkce AWP včetně nabídek a panelů nástrojů umožňuje jednotným způsobem přizpůsobit vzhled.

Na tento moment Vývoj IT vyžaduje aktualizaci platformy systému Flagman. V první řadě je nutné jej převést na třívrstvou architekturu a rozvinout modul správy dokumentů na plně funkční systém řízení procesů. Je také nutné vyvinout mechanismy pro integraci externích aplikací, protože systém má pouze prostředky pro import a export dat.

Nicméně četné příklady úspěšné implementace a komerčního provozu systému Flagman, růst počtu jeho prodejů v letech 2001-2002 svědčí o ekonomická účinnostřešení pro automatizaci podniků různých oborů činnosti, odvětví a rozsahu.

V únoru 1999 byl systém Flagman společnosti Infosoft, vytvořený pod vedením autora, uznán jako nejlepší ruský vývoj založený na sadě nástrojů Centura Team Developer od společnosti Centura Software Corp. (USA) a společnost "Interface" (Rusko). V letech 1999, 2000 a 2001 CIS "Flagman" byl certifikován jako celopodnikový informační systém odborníky poroty soutěže "Business-Soft", pořádané Asociací softwarových vývojářů v oblasti ekonomiky (AREP), TSIES "Business Programs-Service". “, časopis „Účetnictví“ a „Finanční noviny“.