Kaskadni model ais. Životni ciklus automatizovanih informacionih sistema (LC AIS). AIS modeli životnog ciklusa. Faze životnog ciklusa informacionog sistema

3.1 Definiranje AIS modela životnog ciklusa

ispod modela životni ciklus Razvoj softverskog proizvoda shvata se kao struktura koja određuje redosled izvođenja i odnos procesa, radnji i zadataka koji se obavljaju tokom životnog ciklusa razvoja softverskog proizvoda. Sljedeći modeli životnog ciklusa razvoja softverskih proizvoda su najčešće korišteni (tabela 1. Kratke karakteristike AIS modeli životnog ciklusa): model vodopada, ili vodopad (model vodopada); model u obliku slova v (model u obliku slova v); model prototipa (model prototipa); model brzog razvoja aplikacija, ili RAD-model (RAD-brzi model razvoja aplikacija);model sa više prolaza (inkrementalni model); spiralni model.

Tabela 1. Kratke karakteristike svakog od navedenih modela

Ime	karakteristike
Kaskadni model	Jednostavan i jednostavan za korištenje. Neophodna je stalna stroga kontrola toka radova. Razvijeni softver nije dostupan za izmjene
model u obliku slova V	Jednostavan za korištenje. Naglasak je stavljen na testiranje i poređenje rezultata faze testiranja i projektovanja
Model za izradu prototipa	Kreira se "brza" djelomična implementacija sistema prije nego što se sastave konačni zahtjevi. Pod uslovom Povratne informacije između korisnika i programera tokom trajanja projekta. Korišteni zahtjevi nisu potpuni
Model brzog razvoja aplikacija	Projektni timovi mali (3 ... 7 ljudi) i sastavljeni su od visoko kvalifikovanih stručnjaka. Smanjeno vrijeme razvojnog ciklusa (do 3 mjeseca) i poboljšane performanse. Ponovna upotreba koda i automatizacija procesa razvoja
Model sa više prolaza	Radni sistem se brzo stvara. Smanjuje mogućnost izmjena tokom procesa razvoja. Migracija sa trenutne implementacije na novu verziju nije moguća dok se gradi trenutna djelomična implementacija
spiralni model	Pokriva model vodopada. Razbija faze na manje dijelove. Omogućava fleksibilan dizajn. Analizira i upravlja rizicima. Korisnici upoznaju softverski proizvod u ranijoj fazi zahvaljujući prototipovima

3.2 Kaskadni model

U homogenom informacioni sistemi Tokom 1970-ih i 1980-ih, aplikativni softverski proizvodi su bili jedinstvena cjelina. Za razvoj ove vrste softverskog proizvoda korišten je kaskadni model ili „vodopad“.

Kaskadni model softverskog proizvoda je sličan modelu automatizovanog sistema upravljanja (vidi Poglavlje 1, sl. 1).

Ovaj proces je po pravilu iterativnog karaktera: rezultati sljedeće faze često uzrokuju promjene u dizajnerskim odlukama razvijenim u ranijim fazama. Stoga postoji stalna potreba za vraćanjem na prethodne faze i ranijim pojašnjavanjem ili revizijom donete odluke. Kao rezultat toga, stvarni razvojni proces poprima drugačiji oblik (vidi Poglavlje 1, Slika 2)

3.3 V-model

Ovaj model (slika 5) razvijen je kao varijanta modela vodopada, u kojem Posebna pažnja daje se verifikaciji i sertifikaciji softverskog proizvoda. Model pokazuje da se o testiranju proizvoda raspravlja, dizajnira i planira rano u životnom ciklusu razvoja.

Od modela vodopada, model u obliku slova V naslijedio je sekvencijalnu strukturu, prema kojoj svaka naredna faza počinje tek nakon uspješnog završetka prethodne faze.

Ovaj model se zasniva na sistematskom pristupu problemu, za koji su definisana četiri osnovna koraka: analiza, dizajn, razvoj i pregled. Analiza uključuje planiranje projekta i zahtjeve. Dizajn se dijeli na visok nivo i detaljan (niski nivo). Razvoj uključuje kodiranje, pregled - različite vrste testiranje.

Model jasno pokazuje odnos između analitičkih faza i faza projektovanja koje prethode kodiranju i testiranju. Isprekidane strelice pokazuju da ove faze treba posmatrati paralelno.

Model uključuje sljedeće faze:

Izrada projektnih zahtjeva i planiranje - utvrđuju se sistemski zahtjevi i vrši se planiranje rada;

Priprema zahteva za proizvod i njihova analiza - sastavlja se kompletna specifikacija zahteva za softverski proizvod;

Dizajn visokog nivoa - struktura je definisana softver, odnos između njegovih glavnih komponenti i funkcija koje implementiraju;

Glavni projekat - utvrđuje se algoritam rada svake komponente;

Kodiranje - vrši se transformacija algoritama u gotov softver;

Jedinično testiranje - testira se svaka komponenta ili modul softverskog proizvoda;

Integraciono testiranje - vrši se integracija softverskog proizvoda i njegovo testiranje;

Testiranje sistema - provjerava se rad softverskog proizvoda nakon što se postavi u hardversko okruženje u skladu sa specifikacijom zahtjeva;

Rad i održavanje - puštanje softverskog proizvoda u proizvodnju. Tokom ove faze, softverski proizvod može biti izmijenjen i nadograđen.

Sl.5 Model u obliku slova V

Prednosti modela u obliku slova V:

1) Velika uloga se daje verifikaciji i sertifikaciji softverskog proizvoda, počevši od ranih faza njegovog razvoja, planiraju se sve radnje;

2) Pretpostavlja se atestiranje i verifikacija ne samo samog softverskog proizvoda, već i svih primljenih internih i eksternih podataka;

3) Napredak rada se može lako pratiti jer je završetak svake faze prekretnica.

Pored ovih prednosti, model ima i niz nedostataka:

iteracije između faza se ne uzimaju u obzir; nemoguće je izvršiti promjene u različitim fazama životnog ciklusa; testiranje zahtjeva se dešava prekasno, tako da unošenje izmjena utiče na raspored.

Ovaj model je svrsishodno koristiti u razvoju softverskih proizvoda, čiji je glavni zahtjev visoka pouzdanost.

Proizvod i izrada praktičnih kartica za popunjavanje atributa baze podataka: jednostavnost kreiranja veza i njihova modernizacija. Poglavlje II. Izrada programa za automatizaciju aktivnosti taksi flote 2.1 Analiza zahtjeva kupaca Program Automatiziran radno mjesto taxi dispečer je razvijen prema spiralnom modelu životnog ciklusa automatizovanih informacionih sistema. U svakoj fazi stvaranja...

Sistemi. Main normativni dokumenti, koji reguliraju proces kreiranja bilo kojeg IS i IT projekta, su GOST-ovi i njihovi kompleksi za kreiranje i dokumentovanje informatička tehnologija, automatizovani sistemi, softvera, organizacije i obrade podataka, kao i upravljačkih dokumenata Državne tehničke komisije Rusije o razvoju, proizvodnji i radu softvera i ...

Kaskadni pristup se dokazao u izgradnji IS-a, za koje je na samom početku razvoja moguće prilično precizno i ​​potpuno formulisati sve zahtjeve kako bi se programerima pružila sloboda da ih tehnički implementiraju što bolje. Ova kategorija uključuje složeni sistemi sa velikim brojem zadataka računske prirode sistema u realnom vremenu itd.

AIS model životnog ciklusa- je struktura koja opisuje procese, aktivnosti i zadatke koji se provode tokom razvoja, rada i održavanja tokom cijelog životnog ciklusa sistema.

Izbor modela životnog ciklusa zavisi od specifičnosti, obima, složenosti projekta i skupa uslova u kojima AIS nastaje i funkcioniše.

AIS model životnog ciklusa uključuje:

Rezultati rada u svakoj fazi;

Ključni događaji ili tačke završetka i donošenje odluka.

U skladu sa poznatim modelima životnog ciklusa softvera, AIS modeli životnog ciklusa se određuju - kaskadni, iterativni, spiralni.

I. Kaskadni model opisuje klasičan pristup razvoju sistema u bilo kojoj predmetnoj oblasti; bio naširoko korišćen 1970-ih i 80-ih godina.

Kaskadni model predviđa sekvencijalnu organizaciju rada, a glavna karakteristika modela je podjela svih radova na faze. Prijelaz iz prethodne faze u sljedeću događa se tek nakon potpunog završetka svih radova prethodne.

Dodijeli pet stabilne faze razvoja, praktično nezavisne od predmetne oblasti

Na prvo U fazi se proučava problematično područje, formuliraju se zahtjevi kupca. Rezultat ove faze je projektni zadatak (razvojni zadatak), usaglašen sa svim zainteresovanim stranama.

Tokom sekunda faza, prema zahtevima projektni zadatak, razvijaju se određena dizajnerska rješenja. Rezultat je skup projektne dokumentacije.

Treće faza - implementacija projekta; u suštini razvoj softvera (kodiranje) u skladu sa dizajnerskim odlukama prethodne faze. Metode implementacije nisu od fundamentalnog značaja. Rezultat faze je gotov softverski proizvod.

Na četvrto U fazi, primljeni softver se provjerava u skladu sa zahtjevima navedenim u projektnom zadatku. Probni rad omogućava otkrivanje raznih vrsta skrivenih nedostataka koji se manifestuju u realnim uslovima rada AIS-a.

Poslednji korak je predaja gotov projekat, a glavna stvar ovdje je uvjeriti kupca da su svi njegovi zahtjevi ispunjeni u potpunosti.

Slika 1.1 AIS LC kaskadni model

Faze rada unutar modela vodopada se često nazivaju dijelovima AIS projektnog ciklusa, budući da se faze sastoje od mnogih iterativnih procedura za preciziranje sistemskih zahtjeva i opcija dizajna. Životni ciklus AIS-a je mnogo složeniji i duži: može uključivati ​​proizvoljan broj ciklusa usavršavanja, izmjena i dopuna već usvojenih i implementiranih projektnih odluka. U ovim ciklusima odvija se razvoj AIS-a i modernizacija njegovih pojedinačnih komponenti.

Prednosti modela vodopada:

1) u svakoj fazi formira se kompletna projektna dokumentacija koja ispunjava kriterijume kompletnosti i konzistentnosti. U završnim fazama izrađuje se korisnička dokumentacija koja pokriva sve tipove AIS podrške predviđene standardima (organizacijske, informativne, softverske, tehničke itd.);

2) uzastopno izvođenje faza rada omogućava vam da planirate vrijeme završetka i odgovarajuće troškove.

Kaskadni model je prvobitno razvijen za rješavanje raznih vrsta inženjerskih problema i do danas nije izgubio svoj značaj za primijenjenu oblast. Uz to, vodopad pristup je idealan za razvoj AIS-a, jer je već na samom početku razvoja moguće prilično precizno formulirati sve zahtjeve kako bi se programerima pružila sloboda tehničke implementacije. Takav AIS, posebno, uključuje složene sisteme poravnanja i sisteme u realnom vremenu.

Nedostaci modela vodopada:

Značajno kašnjenje u dobijanju rezultata;

Greške i nedostaci u bilo kojoj od faza pojavljuju se u pravilu u narednim fazama rada, što dovodi do potrebe za povratom;

Složenost paralelnog rada na projektu;

Preopterećenost informacijama svake od faza;

Složenost upravljanja projektima;

Visok nivo rizika i nepouzdanost ulaganja.

Kašnjenje u dobijanju rezultata Ona se manifestuje u tome da se u doslednom pristupu razvoju, rezultati dogovaraju sa zainteresovanim stranama tek nakon završetka sledeće faze rada. Kao rezultat, može se ispostaviti da razvijeni AIS ne ispunjava zahtjeve, a takve nedosljednosti se mogu pojaviti u bilo kojoj fazi razvoja; osim toga, greške mogu nenamjerno uneti i analitičari i programeri, jer se od njih ne traži da budu dobro upućeni u oblastima za koje se AIS razvija.

Vratite se na ranije faze. Ovaj nedostatak je manifestacija prethodnog: fazni sekvencijalni rad na projektu može dovesti do činjenice da se greške napravljene u ranijim fazama otkrivaju tek u narednim fazama. Kao rezultat toga, projekat se vraća u prethodnu fazu, obrađuje se i tek onda prenosi na kasniji rad. To može uzrokovati poremećaj u rasporedu i zakomplicirati odnos između razvojnih timova koji izvode pojedinačne faze.

Najgora opcija je kada se nedostaci prethodne faze pronađu ne u sljedećoj fazi, već kasnije. Na primjer, u fazi probnog rada mogu se pojaviti greške u opisu predmetne oblasti. To znači da se dio projekta mora vratiti u početnu fazu rada.

Složenost paralelnog rada vezano za potrebu koordinacije različitih dijelova projekta Što je čvršća veza između pojedinih dijelova projekta, to se češće i pažljivije mora vršiti sinhronizacija, timovi za razvoj više zavise jedni od drugih. Kao rezultat toga, prednosti paralelnog rada se jednostavno gube; nedostatak paralelizma negativno utiče na organizaciju rada čitavog tima.

Problem preopterećenost informacijama proizilazi iz snažne zavisnosti između različitih grupa programera. Činjenica je da je prilikom izmjene jednog od dijelova projekta potrebno obavijestiti one programere koji su ga koristili (mogli koristiti) u svom radu. Uz veliki broj međusobno povezanih podsistema, sinhronizacija interne dokumentacije postaje poseban glavni zadatak: programeri moraju stalno da se upoznaju sa promjenama i procjenjuju kako će te promjene uticati na dobijene rezultate.

Složenost upravljanja projektima uglavnom zbog striktnog slijeda razvojnih faza i prisutnosti složenih odnosa između različitih dijelova projekta. Regulisani redoslijed rada dovodi do toga da neke razvojne grupe moraju čekati rezultate rada drugih timova, pa je potrebna administrativna intervencija kako bi se dogovorili rokovi i sastav prenesene dokumentacije.

U slučaju otkrivanja grešaka u radu, neophodan je povratak na prethodne faze; prekinut je dosadašnji rad onih koji su pogriješili. Posljedica toga je obično kašnjenje u realizaciji kako korigovanih tako i novih projekata.

Moguće je pojednostaviti interakciju između programera i smanjiti informacijsko preopterećenje dokumentacije smanjenjem broja veza između pojedinih dijelova projekta, ali se svaki AIS ne može podijeliti na labavo povezane podsisteme.

Visok nivo rizika.Što je projekat složeniji, to duže traje svaka faza razvoja i složeniji je odnos između pojedinih delova projekta, čiji se broj takođe povećava. Štaviše, rezultati razvoja se zapravo mogu vidjeti i ocijeniti tek u fazi testiranja, odnosno nakon završetka analize, dizajna i razvoja – faza, čija implementacija zahtijeva dosta vremena i novca.

Zakašnjela evaluacija stvara ozbiljne probleme u identifikaciji grešaka u analizi i dizajnu – potreban je povratak na prethodne faze i ponavljanje procesa razvoja. Međutim, povratak na prethodne faze može biti povezan ne samo s greškama, već i sa promjenama koje su se dogodile u predmetnoj oblasti ili zahtjevima korisnika tokom razvoja. Istovremeno, niko ne garantuje da se predmetna oblast neće ponovo promeniti do trenutka kada bude spremna sledeća verzija projekta. Zapravo, to znači da postoji mogućnost "ciklusa" razvojnog procesa: troškovi projekta će stalno rasti, a rokovi za isporuku gotovog proizvoda će se stalno odlagati.

II. Iterativni model (Stupanjski model sa srednjom kontrolom) je niz kratkih ciklusa (koraka) planiranja, implementacije, proučavanja, djelovanja.

Izrada kompleksnog AIS-a podrazumeva koordinaciju projektnih rešenja dobijenih tokom realizacije pojedinačnih zadataka. Pristup dizajna odozdo prema gore iziskuje takve iteracije povrata, kada se dizajnerska rješenja za pojedinačne zadatke kombinuju u zajednička sistemska rješenja. U ovom slučaju postoji potreba za revizijom prethodno formiranih zahtjeva.

Prednost iterativnog modela je da međufazna prilagođavanja obezbjeđuju manji radni intenzitet razvoja u odnosu na kaskadni model.

Nedostaci iterativni model:

· vijek trajanja svake faze je razvučen za cijeli period rada;

· zbog velikog broja iteracija dolazi do odstupanja u implementaciji projektnih odluka i dokumentacije;

zamršenosti arhitekture

· Poteškoće u korištenju projektne dokumentacije u fazama implementacije i rada zahtijevaju redizajn cijelog sistema.

III. spiralni model, za razliku od kaskade, ali slično prethodnoj, uključuje iterativni proces razvoja AIS-a. Istovremeno se povećava značaj početnih faza, poput analize i projektovanja, koji provjerava i opravdava izvodljivost tehničkih rješenja izradom prototipova.

Svaka iteracija je kompletan razvojni ciklus koji vodi ka izdavanju interne ili eksterne verzije proizvoda (ili podskupa konačnog proizvoda) koji se poboljšava iz iteracije u iteraciju kako bi postao kompletan sistem (slika 1.2).

Rice. 1.2. Spiralni model životnog ciklusa AIS-a

Dakle, svaki zavoj spirale odgovara kreiranju fragmenta ili verzije softverskog proizvoda, precizira ciljeve i karakteristike projekta, određuje njegovu kvalitetu i planira rad na sljedećem zavoju spirale. Svaka iteracija služi za produbljivanje i dosljedno specificiranje detalja projekta, kao rezultat čega se odabire razumna opcija za konačnu implementaciju.

Korištenje spiralnog modela omogućava vam da pređete na sljedeću fazu projekta bez čekanja da se trenutna završi - nedovršeni posao može se obaviti u sljedećoj iteraciji. Glavni zadatak svake iteracije je stvoriti funkcionalan proizvod za demonstraciju korisnicima što je brže moguće. Time je proces unošenja pojašnjenja i dopuna projekta uvelike pojednostavljen.

Spiralni pristup razvoju softvera prevazilazi većinu nedostataka modela vodopada, osim toga, pruža niz dodatne funkciječineći proces razvoja fleksibilnijim.

Prednosti iterativni pristup:

Iterativni razvoj uvelike pojednostavljuje uvođenje promjena u projekat kada se mijenjaju zahtjevi kupaca;

Kada se koristi spiralni model, pojedinačni elementi AIS-a se postepeno integriraju u jedinstvenu cjelinu. Pošto integracija počinje sa manje elemenata, mnogo je manje problema tokom njene implementacije;

Smanjenje nivoa rizika (posledica prethodne prednosti, jer se rizici otkrivaju tokom integracije). Nivo rizika je maksimalan na početku razvoja projekta, kako razvoj napreduje, on se smanjuje;

Iterativni razvoj pruža veću fleksibilnost u upravljanju projektima omogućavajući taktičke promjene na proizvodu u razvoju. Dakle, moguće je smanjiti vrijeme razvoja smanjenjem funkcionalnosti sistema ili korištenjem proizvoda trećih strana kao komponenti umjesto vlastitog razvoja (relevantno kada tržišnu ekonomiju kada je potrebno oduprijeti se promociji konkurentskog proizvoda);

Iterativni pristup olakšava ponovnu upotrebu komponenti jer je mnogo lakše identificirati (identificirati) zajedničke dijelove projekta kada su već djelomično razvijeni nego pokušati ih izolirati na samom početku projekta. Analiza dizajna nakon nekoliko početnih iteracija otkriva uobičajene komponente za višekratnu upotrebu koje će biti poboljšane u narednim iteracijama;

Spiralni model vam omogućava da dobijete pouzdaniji i stabilniji sistem. To je zato što kako se sistem razvija, greške i slabosti se pronalaze i popravljaju na svakoj iteraciji. Istovremeno se prilagođavaju kritični parametri performansi, što je u slučaju vodopada dostupno samo prije implementacije sistema;

Iterativni pristup omogućava poboljšanje procesa
razvoj - kao rezultat analize na kraju svake iteracije, vrši se procjena promjena u organizaciji razvoja; poboljšava se u sljedećoj iteraciji.

Glavni problem spiralnog ciklusa- poteškoće u određivanju trenutka prelaska u sljedeću fazu. Da bi se to riješilo, potrebno je uvesti vremenska ograničenja za svaku od faza životnog ciklusa. U suprotnom, proces razvoja može se pretvoriti u beskonačno poboljšanje onoga što je već urađeno.

Uključivanje korisnika u proces dizajniranja i kopiranja aplikacije omogućava vam da dobijete komentare i dopune zahtjeva direktno u procesu dizajniranja aplikacije, smanjujući vrijeme razvoja. Predstavnici korisnika dobijaju priliku da kontrolišu proces kreiranja sistema i utiču na njegov funkcionalni sadržaj. Rezultat je puštanje u rad sistema koji uzima u obzir većinu potreba kupaca.

Model životnog ciklusa i tehnologija projektovanja

Ranije smo rekli da tehnologija dizajna postavlja redoslijed radnji potrebnih za dobivanje IP projekta. Očigledno, izvršenje svake od ovih radnji znači prelazak informacionog sistema iz jednog stanja u drugo. Dakle, bilo koja tehnologija dizajna nedvosmisleno opisuje neki model životnog ciklusa. S druge strane, izgradnjom modela životnog ciklusa informacionog sistema, odnosno definisanjem:

zadaci, sastav i redoslijed obavljenog posla;

· rezultate svake izvršene radnje;

Metode i sredstva neophodna za obavljanje poslova;

uloge i odgovornosti učesnika;

druge informacije potrebne za planiranje, organizovanje i upravljanje kolektivnim razvojem intelektualne svojine,

dobićemo nedvosmislen opis tehnologije dizajna koju smo odabrali. Dakle, model životnog ciklusa je sastavni i suštinski deo tehnologije projektovanja informacionih sistema.

Faze i faze projektovanja

Često se brkaju koncepti "faza" i "faza" dizajna. Ponekad pričaju o tome faze ili fazeživotni ciklus, stepenice dizajn. Postavlja se pitanje: koji je pravi put?

Treba imati na umu da u različitim međunarodnim standardima terminologija koja se koristi može varirati. Ako je moguće, fokusirat ćemo se na terminologiju domaćih GOST-ova. Faza projektovanja nazvat ćemo dio procesa kreiranja IS-a, ograničen određenim vremenskim okvirom i koji se završava izdavanjem određenog proizvoda (modela, dokumentacije, teksta programa itd.). Prema zajedništvu ciljeva, faze projektovanja se mogu kombinovati u faze. Na primjer, faza "Tehnički dizajn", faza "Implementacija" itd.

Prema objavljenim podacima, svaka faza razvoja AIS-a zahtijeva određeno vrijeme. Većina vremena (45-50%) se troši na kodiranje, složeno i samostalno testiranje. U prosjeku, razvoj AIS-a zauzima jednu trećinu cjelokupnog životnog ciklusa sistema.

Rice. Raspodjela vremena u razvoju AIS-a

Faze stvaranja AIS-a (ISO/IEC 15288)

Standard ISO/IEC 12207 definiše okvir životnog ciklusa koji sadrži procese, aktivnosti i zadatke koji se moraju izvršiti tokom kreiranja informacionog sistema.

AIS postoje, po pravilu, dugo vremena, sukcesivno prolazeći kroz nekoliko faza kombinovanog razvoja u svom razvoju. životni ciklus(LC) sistemi:

1) pretprojektno istraživanje (ili analiza) organizacije,

2) AIS dizajn,

3) implementacija AIS-a,

4) uvođenje AIS-a,

5) funkcionisanje (rad, upotreba)

6) AIS pratnja,

7) modernizacija projekta AIS.

Životni ciklus - period stvaranja i korišćenja informacionog sistema, koji obuhvata njegova različita stanja, počevši od trenutka kada se pojavi potreba za ovim informacionim sistemom i završava se momentom njegovog potpunog izlaska iz rada.

Treba napomenuti da je AIS proizvod proizvodnje informacija, kao što je automobil proizvod mašinogradnje, kobasica proizvod proizvodnje hrane itd., dakle, faze životnog ciklusa AIS-a sa 1 do 5 slični su fazama životnog ciklusa bilo kojeg proizvoda.

AIS životni ciklus, kao i automobil, može završiti kao rezultat fizičkog habanja, ako u životnom ciklusu faza podrške nije razrađena, odnosno popravku i održavanje, na primjer, računara i programa koji su dio AIS-a (bez podrške sistem neće raditi ni šest mjeseci). Uz kvalifikovanu pratnju, AIS može postojati dugo vremena, ali postoji prijetnja prestanak životnog ciklusa AIS-a zbog zastarjelosti, AIS zastarelost, ako nema faze nadogradnje AIS (bez modernizacije, sistem neće raditi duže od 2 godine).

Fizička amortizacija AIS-a je nemogućnost ispunjavanja zahtjeva organizacije za AIS-om zbog kvara, kvara ili otkaza komponenti sistema.

Zastarelost AIS-a - prestanak ispunjavanja zahteva organizacije i njenih zaposlenih za AIS, kao rezultat upotrebe zastarelih automatizovanih informacione tehnologije i nedostatak podrške za nove zahtjeve korisnika.

Ako je vaša organizacija pristupila automatizaciji odgovorno i sveobuhvatno, organizirala sve faze i faze u skladu s tim, onda AIS životni ciklus ograničava samo životni vijek vaše organizacije, što znači da sredstva potrošena na AIS neće biti bačena u smeće zajedno sa fizički ili moralno zastarjelim AIS-om.

Sve faze životnog ciklusa AIS-a su navedene gore, ali neke od njih rade paralelno, tako da dodeljuju samo 5 faza u životnom ciklusu AIS-a(sl.35):

U prvoj fazi" Anketa prije projekta» (Sl. 33) uobičajeno je razlikovati dvije glavne podfaze i jednu dodatnu podfazu:

1.1. dirigovanje pretprojektno istraživanje i prikupljanje anketnog materijala;

1.2. analiza materijala ankete i razvoj na osnovu analize studije izvodljivosti (FS) i projektnog zadatka (TOR);

1.3. izbor i razvoj varijante koncepta sistema.

Ciljevi faze istraživanja prije projekta su sljedeći:

· formulisati potrebe za novim AIS-om, tj. identifikovati sve nedostatke postojećeg IS;

· izabrati pravac i utvrditi ekonomsku izvodljivost projektovanja AIS-a.

Anketni rad počinje analizom primarnih zahtjeva i planiranjem rada, što traje od 2 dana do 4 sedmice. Zatim se provodi samo istraživanje preduzeća (trajanje ankete je 1-2 sedmice.)

Prvo se kreira opis i analizira funkcionisanje preduzeća ili organizacije u skladu sa zahtjevima (ciljevima) koji se na njega odnose. Određene su organizacione i topološke strukture preduzeća. Identificiraju se funkcionalne aktivnosti svake od divizija poduzeća i funkcionalne interakcije između njih, tokovi informacija unutar odjeljenja i između njih, objekti izvan poduzeća i eksterne informacijske interakcije. Utvrđuje se lista ciljnih zadataka (funkcija) preduzeća i vrši se analiza raspodjele funkcija po odjelima i zaposlenima.

Utvrđuje se lista sredstava za automatizaciju koja se koriste u preduzeću.

Zatim se obrađuju rezultati ankete i grade sljedeća dva tipa modela aktivnosti preduzeća (imajte na umu da izgradnja svakog od potrebnih modela zahtijeva intenzivan rad 6-7 kvalifikovanih sistemskih analitičara u roku od 2-4 mjeseca).

1. U izgradnji "kao što je" model koji je "snimak" stanja u preduzeću (organizacijska struktura, interakcije između odeljenja, usvojene tehnologije, automatizovani i neautomatizovani poslovni procesi, itd.) u vreme anketiranja i omogućava vam da razumete šta je ovo preduzeće da li i kako funkcioniše sa stanovišta sistemske analize, kao i da, na osnovu automatske verifikacije, identifikuje niz grešaka i uskih grla i formuliše niz predloga za poboljšanje situacije.

2. Formirano Model "kako treba". integrišući obećavajuće predloge menadžmenta i zaposlenih u preduzeću, stručnjaka i sistemskih analitičara i omogućavaju formiranje vizije novih racionalnih tehnologija za rad preduzeća. Ona predstavlja koncept budućeg AIS-a.

Kreiranje koncepta budućeg sistema uključuje sljedeće radove:

Detaljna studija objekta automatizacije;

Potreban istraživački rad (R&D) koji se odnosi na pronalaženje načina i procjenu mogućnosti implementacije zahtjeva korisnika;

Izrada alternativnih opcija za koncept kreiranog AIS-a i planova za njihovu implementaciju;

Ocjena neophodna sredstva za njihovu implementaciju i rad;

Procjena prednosti i mana svake opcije;

Poređenje zahtjeva korisnika i karakteristika predloženog sistema i izbor najbolja opcija;

Utvrđivanje postupka ocjenjivanja kvaliteta i uslova za prihvatanje sistema;

Evaluacija efekata dobijenih od sistema;

Izrada izvještaja koji sadrži opis obavljenog posla;

Opis i obrazloženje predložene verzije koncepta sistema.

Na osnovu izgrađenog koncepta sistema i rezultata istraživanja preduzeća u smislu identifikacije zahteva za budući sistem, formira se sistemski projekat. (model zahtjeva), koji je prva faza razvoja samog sistema automatizacije (odnosno faza analize zahtjeva za sistem), na kojoj se specificiraju, formaliziraju i dokumentuju zahtjevi kupca.

Naime, u ovoj fazi se daje odgovor na pitanje: „Šta treba da radi budući sistem?“. Tu leži ključ uspjeha cjelokupnog projekta automatizacije. U praksi kreiranja velikih softverskih sistema ima mnogo primera neuspešne implementacije upravo zbog nepotpunosti i nejasne definicije sistemskih zahteva.

U ovoj fazi se utvrđuje:

§ arhitektura sistema, njegove funkcije, spoljni uslovi njegovog funkcionisanja, raspodela funkcija između hardverskih i softverskih delova;

§ interfejsi i distribucija funkcija između osobe i sistema;

§ zahtjevi za softverske i informacione komponente sistema, potrebni hardverski resursi, zahtjevi za bazom podataka, fizičke karakteristike komponenti sistema, njihovi interfejsi;

§ sastav ljudi i poslova vezanih za sistem;

§ ograničenja u procesu razvoja (direktni rokovi za završetak pojedinih faza, raspoloživi resursi);

§ organizacione procedure koje obezbjeđuju zaštitu informacija.

U okviru projektovanja sistema sprovodi se sledeće:

Utvrđivanje sastava, strukture i karakteristika funkcionalnih zadataka u okviru djelatnosti strukturnih odjeljenja;

Određivanje sastava i strukture softvera za automatizaciju tehnologije rješavanja problema, uzimajući u obzir postojeće alate u strukturne podjele;

Određivanje strukture i karakteristika tehnologije informacione podrške za rješavanje problema;

Razvoj tehničkih rješenja za izgradnju informatičke podrške (logičke strukture baza podataka, strukture klasifikatora);

§ razvoj sastava automatizovanih procedura toka posla.

Projekt sistema treba uključivati:

kompletan funkcionalni model zahtjeva za budući sistem;

Komentari na funkcionalni model (procesne specifikacije nižeg nivoa u tekstualnom obliku);

paket izvještaja i dokumenata o funkcionalnom modelu, uključujući opis objekta modeliranja, listu podsistema, zahtjeve za metode i sredstva komunikacije za razmjenu informacija između komponenti, zahtjeve za karakteristike interkonekcije sistema sa susjednim sistemima, zahtjeve za sistemske funkcije;

· konceptualni model integrisane baze podataka (paket dijagrama);

arhitektura sistema u odnosu na konceptualni model;

· prijedlozi organizacione strukture za podršku sistemu.

Dakle, sistemski projekat sadrži funkcionalne, informativne i eventualno događajne modele zahtjeva za budući sistem. Vrste i redoslijed radova u konstrukciji ovih modela zahtjeva su slični odgovarajućim radovima na konstrukciji modela aktivnosti. Dodatno, sistemski projekat uključuje projektni zadatak za kreiranje automatizovanog sistema.

Potrebno je napomenuti sljedeću prednost sistemskog projekta. Tradicionalni razvoj karakteriše implementacija početnih faza na zanatski neformalizovan način. Kao rezultat toga, korisnici i korisnici mogu prvi put vidjeti sistem nakon što je već u velikoj mjeri implementiran. Naravno, ovaj sistem je drugačiji od onoga što su očekivali da vide. Stoga slijedi još nekoliko iteracija njegovog razvoja ili modifikacije, što zahtijeva dodatne (i značajne) troškove novca i vremena. Ključ za rješavanje ovog problema je sistemski projekat koji omogućava:

Opišite, „vidite“ i ispravite budući sistem prije nego što se fizički implementira;

Smanjiti troškove razvoja i implementacije sistema;

Ocijeniti razvoj u smislu vremena i rezultata;

Ostvariti međusobno razumijevanje svih učesnika u radu (kupaca, korisnika, programera, programera itd.);

Poboljšati kvalitet razvijenog sistema, odnosno: kreirati optimalnu strukturu integrisane baze podataka, izvršiti funkcionalnu dekompoziciju tipičnih modula.

Projekt sistema je potpuno nezavisan i odvojen od konkretnih programera, ne zahtijeva održavanje od strane njegovih kreatora i može se bezbolno prenijeti na druge osobe. Štaviše, ako iz nekog razloga preduzeće nije spremno da implementira sistem zasnovan na projektu, može se staviti "na policu" dok se ne ukaže potreba. Osim toga, može se koristiti za samostalan razvoj ili korekciju softverskih alata koje su na njegovoj osnovi već implementirali programeri odjela za automatizaciju poduzeća.

Svrha izrade „Studije izvodljivosti“ AIS projekta je procijeniti glavne parametre koji ograničavaju projekat, opravdati izbor i ocijeniti glavne dizajnerske odluke za pojedine komponente projekta. Istovremeno, postoje organizacioni parametri koji karakterišu načine organizovanja procesa transformacije informacija u sistemu, informacioni i ekonomski parametri koji karakterišu troškove kreiranja i rada sistema, uštede od njegovog rada. Glavni objekti parametrizacije u sistemu su zadaci, kompleksi zadataka, ekonomski pokazatelji, procesi obrade informacija. Nakon što je donesena odluka o daljem radu, niz organizacione mjere, na primjer, moraju se izdati odgovarajući radni nalozi; Trebalo bi imenovati odgovorne za oblasti itd.

Bez takve podrške menadžmenta preduzeća, besmisleno je uopšte započeti projekat.

Slika 33. Redoslijed radova u fazi predprojektovanja životnog ciklusa AIS-a.

Zatim se kreira projektni zadatak (TOR) za projekat, koji odražava specifikacije i zahtjevi za budući AIS, kao i ograničenja u projektnim resursima. Ako projekat zahtijeva naučno proučavanje komponenti, onda se koncept budućeg AIS-a razvija na osnovu TOR-a.

U okviru formiranja Projektnog zadatka razvijaju se prijedlozi za automatizaciju na osnovu identifikovanih i dogovorenih zahtjeva, koji uključuju:

Izrada liste automatizovanih radnih mesta preduzeća i načina interakcije između njih;

Analiza primenljivosti postojećih sistema upravljanja preduzećem (prvenstveno MRP i ERP klasa) za rešavanje traženih zadataka i formiranje preporuka za izbor takvog sistema;

Zajedničko odlučivanje sa klijentom odabirom određenog sistema upravljanja preduzećem ili razvojem sopstvenog sistemima.

Izrada prijedloga tehničkih sredstava;

Razvoj prijedloga softvera;

Razvoj topologije, sastava i strukture lokalne mreže;

Izrada prijedloga faza i termina automatizacije.

Ako je odlučeno da se izabere određeni kontrolni sistem, neki koraci se preskaču.

druga faza" Dizajn» (Sl. 34) izvodi sljedeće pod-korake:

1) idejni projekat: pojašnjenje uslova zadatka, izvođenje i odobrenje idejnog projekta;

2) tehničko projektovanje: izbor projektnih rešenja za sve aspekte razvoja AIS-a, opis svih komponenti AIS-a, izvođenje i odobravanje tehničkog projekta;

3) Glavni projekat: izbor i razvoj matematičkih metoda i programskih algoritama, prilagođavanje strukture baza podataka (DB), izrada dokumentacije za nabavku i razvoj softverskih proizvoda, izbor kompleta AIS hardvera, izrada dokumentacije za nabavka i ugradnja hardvera, izrada radnog nacrta AIS-a.

Ciljevi ove faze su:

· razviti funkcionalnu arhitekturu AIS-a, koja odražava strukturu i sastav funkcionalnih podsistema, za automatizovanu podršku određenim funkcijama upravljanja organizacijom;

· razviti sistemsku arhitekturu odabrane varijante AIS-a, odnosno sastav pratećih podsistema.

Za složeni veliki AIS, automatizacija veliko preduzeće, držanje, tijela državna vlast itd., u pod-korak 1" Idejni projekat» formulirana su preliminarna rješenja za budući AIS u cjelini i njegove komponente, kao rezultat toga idejni projekat(EP). Izrada idejnih projektnih rješenja za sistem i njegove dijelove uključuje:

Definicija AIS funkcije;

Definisanje funkcije podsistema, njihovih ciljeva i efekata;

Određivanje sastava kompleksa zadataka i pojedinačnih zadataka;

Definisanje koncepta informacione baze, njene proširene strukture;

Definicija funkcija sistema upravljanja bazom podataka;

Određivanje sastava računalnog sistema;

Definicija funkcije i parametara glavnih softverskih alata.

Izrada dokumentacije za ovaj dio projekta.

Ako projekat koji se razvija nije jako složen, pretpostavimo da se malo preduzeće automatizuje, tada se radni korak preskače.

U podkorak 2. Inženjerski dizajn » rad na logičkom razvoju i odabiru najbolje opcije dizajnerske odluke, kao rezultat kojih se kreira tehnički projekat (TP). U sklopu izrade tehničkog projekta provodi se sljedeće:

- transformacija sistemskog projekta u tehnički projekat(implementacijski model), koji uključuje sljedeće radnje: usavršavanje logičkog modela (razvoj detaljne logike za svaki proces korištenjem dijagrama toka podataka i specifikacija procesa), dizajn fizičke baze podataka, izgradnju hijerarhije modulskih funkcija koje treba programirati, procjena troškova implementacije.

Navedeni posao treba da obavljaju konsultanti analitičari zajedno sa projektantima sistema - tu je granica koja razdvaja konsalting i razvoj. Ipak, poželjno je da u fazi implementacije sistema konsultant djeluje i u interesu kupca, i to: softverski sistem sistemski i tehnički projekti, a također je učestvovao u radu na njegovom proširenju i modifikaciji, tk. proširenja treba planirati na osnovu modela zahtjeva.

- tehnički projektantski radovi:

Izrada opštih rešenja za sistem i njegove delove,

Razvoj općih rješenja za funkcionalno-algoritamske strukturu sistema,

Izrada zajedničkih odluka o kadrovskim funkcijama i organizacionoj strukturi,

Izrada zajedničkih rješenja za strukturu tehničkih sredstava,

Razvoj općih rješenja algoritama za rješavanje problema i korištenih jezika,

Razvoj zajedničkih rešenja za organizovanje i održavanje informacione baze,

Razvoj zajedničkih rješenja za sistem klasifikacije i kodiranja informacija,

Razvoj zajedničkih softverskih rješenja;

Vršiti izradu, izvođenje dokumentacije za sve dijelove projekta, uključujući i dokument "Formulacija problema",

Izrada i izrada dokumentacije za nabavku proizvoda za nabavku AIS i/ili tehnički zahtjevi(tehničke specifikacije) za njihov razvoj;

Izrada projektnih zadataka u susjednim dijelovima projekta objekta automatizacije.

Podfaza 3." Radni dizajn » povezana sa fizičkom implementacijom odabrane opcije projekta i prijemom detaljne projektne dokumentacije (DP).

Ova podetapa se provodi:

Izrada i izrada radne dokumentacije koja sadrži sve potrebne i dovoljne informacije kako bi se osiguralo izvođenje radova na puštanju AIS-a u rad i njegov rad, kao i održavanje nivoa operativnih karakteristika (kvaliteta) sistema u skladu sa usvojenim projektne odluke i usaglašavanje i odobravanje ove dokumentacije;

Razvoj programa i softverskih alata sistema, kao i izbor, adaptacija i/ili uvezivanje kupljenih softverskih alata,

Izrada softverske dokumentacije.

Organizacija tendera za nabavku AIS komponenti (softver i hardver, softver i hardverski sistemi, informacioni proizvodi).

Slika 34. Redoslijed radova u fazi projektovanja životnog ciklusa AIS-a.

U prisustvu dizajnerskog iskustva i male složenosti projekta, sve tri podfaze se kombinuju u jednu, čime se dobija jedan tehno-radni projekat (TDP). U ovom slučaju, projekat se dosljedno, kako se podfaze završavaju, pretvara iz nacrta u detaljni projekat.

Treća faza Implementacija» (Sl. 35) je fizički dizajn sistema u sljedećem redoslijedu:

1) prijem i ugradnja tehničkih sredstava;

2) kodiranje, testiranje i razvoj programa;

3) pribavljanje i instaliranje softvera;

4) kreiranje informacione podrške, uključujući i popunjavanje baza podataka;

5) izradu uputstva za rad softvera i hardvera, kao i opisi poslova za osoblje.

Ovi radovi se praktično mogu izvoditi paralelno.

U četvrtoj fazi životnog ciklusa AIS-a" Implementacija» postoje sljedeći pod-koraci:

1) pilot implementacija:

puštanje u rad tehničke opreme,

puštanje u rad softverskih alata, probni rad svih komponenti i sistema u celini,

· obuka i sertifikacija osoblja.

Pilot implementacija sastoji se u provjeri operativnosti elemenata i modula projekta, otklanjanju grešaka na nivou elemenata i veza između njih.

U ovoj fazi se izvode radovi na organizacionu obuku objekt automatizacije za stavljanje AIS-a u rad, uključujući:

Implementacija projektnih odluka o organizacionoj strukturi AIS-a;

Obezbjeđivanje jedinica kontrolnog objekta instruktivnim i metodološkim materijalima;

Uvođenje klasifikatora informacija;

obuka,

Provjera njegove sposobnosti da osigura funkcionisanje AIS-a.

U istoj fazi, AIS se kompletira isporučenim proizvodima (softver i tehnička sredstva, softverski i hardverski kompleksi, informacioni proizvodi), kao i konstrukcija i montaža, puštanje u rad, preliminarna ispitivanja:

Sprovesti testove AIS-a za performanse i usklađenost sa projektnim zadatkom u skladu sa unapred pripremljenim programom i metodologijom preliminarnih ispitivanja;

Rješavanje problema i poboljšanje (po potrebi) softvera, unošenje izmjena u AIS dokumentaciju, uključujući i operativnu dokumentaciju u skladu sa protokolom testiranja.

Radovi na pilot implementaciji se završavaju sastavljanje akta o završetku probnog rada.

2) industrijska implementacija (stavljanje u komercijalni rad):

puštanje u rad,

Potpisivanje akata prijema i predaje radova.

Puštanje u rad sastoji se u organizovanju verifikacije projekta na nivou funkcija i praćenju usklađenosti sa njegovim zahtevima formulisanim u fazi pre-projektne ankete, tj.:

Izvršiti provjeru usklađenosti sa projektnim zadatkom u skladu sa unaprijed pripremljenim programom i metodologijom prijemnih testova;

Analiza rezultata AIS testa i otklanjanje nedostataka uočenih tokom testiranja.

Završni radovi na izrada akta o prijemu AIS-a u stalni rad.

U posljednjoj petoj fazi životnog ciklusa AIS-a, rad, održavanje i modernizaciju softver, hardver i cijeli projekat.

AIS pratnja lezi u obavljanje poslova u skladu sa garantnim obavezama, izvođenje radova na otklanjanju nedostataka uočenih tokom rada AIS-a u utvrđenom garantnom roku i u izvođenju radova izvršiti potrebne izmene u dokumentaciji za AIS.

Postgarantni servis se sastoji od:

U realizaciji poslova na analizi funkcionisanja sistema;

U identifikaciji odstupanja stvarnih operativnih karakteristika AIS-a od projektnih vrijednosti;

U utvrđivanju uzroka ovih odstupanja;

U otklanjanju uočenih nedostataka i obezbjeđivanju stabilnosti operativnih karakteristika AIS-a;

U izradi potrebnih izmjena u dokumentaciji za AIS.

U zavisnosti od specifičnosti kreiranog AIS-a i uslova za njihovo stvaranje, dozvoljeno je izvođenje pojedinih faza rada pre završetka prethodnih faza, paralelno izvođenje faza rada u vremenu, uključivanje novih faza rada.

Slika 35. Faze životnog ciklusa AIS-a.

Životni ciklus je obično iterativan: završene fazeŽivotni ciklusi, počevši od onih najranijih, ciklički se ponavljaju u skladu sa novim zahtjevima i promjenama vanjskih uvjeta. U svakoj fazi životnog ciklusa formira se set dokumenata i tehničkih rješenja koji su polazne tačke za kasnije odluke.

Najrasprostranjeniji tri modela životnog ciklusa:

kaskadni model (do 70-ih) - uzastopni prijelaz u sljedeću fazu nakon završetka prethodne;

· iterativni model (70-80-e) - sa iterativnim vraćanjem na prethodne faze nakon završetka sljedeće faze;

· spiralni model (80-90-e) - model prototipa, koji pretpostavlja postepeno širenje AIS prototipa.

Za kaskadni model životnog ciklusa tipična je automatizacija odvojenih nepovezanih zadataka, koja ne zahtijeva integraciju informacija i kompatibilnost, softver, tehničko i organizacijsko sučelje. U sklopu rješavanja pojedinačnih problema, kaskadni model se opravdao u pogledu vremena razvoja i pouzdanosti. Primena ovog modela životnog ciklusa na velike i složene projekte, zbog dugog trajanja procesa projektovanja i varijabilnosti zahteva tokom tog vremena, dovodi do njihove praktične neostvarljivosti.

Iterativni model životnog ciklusa. Izrada kompleksnog AIS-a podrazumijeva povezivanje projektnih rješenja dobijenih u realizaciji pojedinačnih zadataka. Pristup dizajna odozdo prema gore iziskuje takve iterativne povratke, kada se projektna rješenja za pojedinačne zadatke kompletiraju u opšta sistemska rješenja, a istovremeno postoji potreba za revizijom prethodno formuliranih zahtjeva. U pravilu, zbog velikog broja iteracija, dolazi do odstupanja u gotovim projektnim odlukama i dokumentaciji. Zbrka funkcionalnih i arhitektura sistema kreiran od strane AIS-a, poteškoće u korištenju projektne dokumentacije izazivaju potrebu redizajniranja cjelokupnog sistema u fazama implementacije i rada. Dugi životni ciklus razvoja informacionog sistema završava se fazom implementacije, nakon čega slijedi životni ciklus stvaranja novog AIS-a.

Spiralni model životnog ciklusa. Koristi se pristup odozgo prema dolje organizaciji projektovanja AIS-a, kada se prvo utvrđuje sastav funkcionalnih podsistema, a potom i postavljanje pojedinačnih zadataka. Shodno tome, prvo se razvijaju sistemska pitanja kao što su organizacija integrisane baze podataka, tehnologija za prikupljanje, prenošenje i akumuliranje informacija, a zatim tehnologija za rješavanje konkretnih problema. U okviru kompleksa zadataka programiranje se odvija u pravcu od glavnih programskih modula ka modulima koji obavljaju pojedinačne funkcije. Istovremeno, u prvi plan dolaze pitanja interakcije međusobnih interfejsa programskih modula i sa bazom podataka, a implementacija algoritama dolazi u drugi plan.

Svaki okret spirale odgovara modelu korak po korak za kreiranje AIS fragmenta. Pojašnjava ciljeve i karakteristike projekta, utvrđuje njegovu kvalitetu i planira rad sljedećeg zavoja spirale. Dolazi do dosljednog produbljivanja i konkretizacije detalja projekta, formira se njegova utemeljena verzija koja se dovodi u realizaciju.

Spiralni model životnog ciklusa baziran je na korištenju tehnologije prototipa ili RAD tehnologije (brzi razvoj aplikacija).

Prema ovoj tehnologiji, AIS se razvija proširenjem softverskih prototipova, prateći put od specifikacije zahtjeva do specifikacije programskog koda.

Naravno, uz prototipnu tehnologiju smanjuje se broj iteracija i manje je grešaka i nedosljednosti koje je potrebno ispravljati u narednim iteracijama, a sam dizajn se izvodi bržim tempom, a izrada projektne dokumentacije je pojednostavljena. Da bi se što bolje uskladila sa projektnom dokumentacijom koju je razvio AIS, sve se više i više značaja pridaje održavanju sistemskog repozitorija i automatizaciji dizajna, posebno korišćenju CASE (Computers Aids System Engineering) tehnologija.

Kada koristite spiralni model:

· postoji akumulacija i ponovna upotreba dizajnerskih rješenja, dizajnerskih alata, modela i prototipova AIS-a i informacionih tehnologija;

· Vrši se orijentacija na razvoj i modifikaciju sistema i tehnologija u procesu njihovog projektovanja;

· analiza rizika i troškova se provodi u procesu projektovanja sistema.

Interfejs je uparivanje delova softvera i hardvera, podataka, tehnologije za komunikaciju između osobe i računara, u kojoj sve informacije, logički, fizički i električni parametri zadovoljavaju utvrđene standarde.

Prototip - minimalna verzija sistema koja se koristi za generisanje ili razvoj pune verzije

Repozitorijum sadrži informacije o objektima projektovanog AIS-a i odnosima između njih, svi podsistemi razmenjuju podatke sa njim.

AIS modeli životnog ciklusa - Struktura koja definira sekvencijalnu implementaciju procesa, radnji, zadataka koji se izvode kroz životni ciklus i odnos između ovih procesa.

kaskadni model. Prelazak u sljedeću fazu znači potpuni završetak radova u prethodnoj fazi. Zahtjevi definirani u fazi formiranja zahtjeva strogo su dokumentirani u formi projektnog zadatka i fiksirani za cijelo vrijeme trajanja razvoja projekta. Svaka faza kulminira izdavanjem kompletnog seta dokumentacije dovoljne da razvoj nastavi drugi razvojni tim.

Faze projekta prema modelu vodopada:

1. Formiranje zahtjeva;

2. Dizajn;

3. Razvoj;

4. Testiranje;

5. Uvod;

6. Rad i održavanje.

Prednosti:

- Potpuna i dogovorena dokumentacija u svakoj fazi;

-Utvrđen redosled rada;

- Omogućava vam da jasno planirate vrijeme i troškove.

Nedostaci:

-Značajno kašnjenje u dobijanju gotovih rezultata;

-U narednim fazama se otkrivaju greške u bilo kojoj od faza, što dovodi do potrebe vraćanja i preregistracije projektne dokumentacije;

- Poteškoće u upravljanju projektima.

spiralni model. Svaka iteracija odgovara kreiranju fragmenta ili verzije softvera, pri čemu se specificiraju ciljevi i karakteristike projekta, ocjenjuje se kvalitet dobijenih rezultata i planira rad sljedeće iteracije.

Svaka iteracija - završeni razvojni ciklusi u obliku 1. verzije AIS-a.

Koraci iteracije:

1.Formiranje zahtjeva

3.Dizajn

4.Razvoj

5.Integracija

U svakoj iteraciji, procjenjuje se sljedeće:

Rizik prekoračenja rokova i troškova projekta;

Potreba za izvođenjem još jedne iteracije;

Stepen potpunosti i tačnosti razumijevanja zahtjeva za sistem;

Svrsishodnost okončanja projekta.

Prednosti:

-Pojednostavljuje proces unošenja izmena u projekat;

- Pruža veću fleksibilnost u upravljanju projektima;

- Mogućnost dobijanja pouzdanog i stabilnog sistema, jer greške i nedosljednosti se nalaze na svakoj iteraciji;

- Uticaj naručioca na rad u procesu provjere svake iteracije.

Nedostaci:

-Složenost planiranja;

-Intenzivan način rada za programere;

-Planiranje rada se zasniva na iskustvu i nema dovoljno metrika za mjerenje kvaliteta svake verzije.

Zahtjevi za tehnologiju projektovanja, razvoja i održavanja AIS-a

Tehnologija dizajna- definira kombinaciju tri komponente:

- postupak korak po korak, kojim se utvrđuje redoslijed operacija tehnološkog projektovanja;

- pravila koja se koriste za vrednovanje rezultata tehnoloških operacija;

- dostavljanje izrade projekta na ispitivanje i odobrenje.

Tehnološka uputstva, koji čine glavni sadržaj tehnologije, treba da se sastoji od opisa redosleda tehnoloških operacija, uslova u zavisnosti od toga koja se jedna ili druga operacija izvodi i opisa samih operacija.

Tehnologija dizajniranja, razvoja i održavanja IS-a mora zadovoljiti sljedeće opšti zahtjevi:

Tehnologija mora podržavati puni životni ciklus softvera;

Tehnologija treba da osigura garantovano postizanje ciljeva razvoja IS sa zadatim kvalitetom iu određenom vremenu;

Tehnologija treba da pruži mogućnost izvođenja radova na projektovanju pojedinačnih podsistema u malim grupama (3-7 ljudi). To je zbog principa upravljanja timom i povećanja produktivnosti minimiziranjem broja vanjskih veza;

Tehnologija treba da obezbedi mogućnost upravljanja konfiguracijom projekta, održavanje verzija projekta i njegovih komponenti, mogućnost automatskog izdavanja projektne dokumentacije i sinhronizacije njenih verzija sa verzijama projekta;

Korišćenje bilo koje tehnologije za projektovanje, razvoj i održavanje IS u određenoj organizaciji i konkretnom projektu nemoguće je bez izrade niza standarda (pravila, sporazuma) koje moraju poštovati svi učesnici projekta. Za takve standardima uključiti sljedeće:

- standard dizajna;

- standard za izradu projektne dokumentacije;

- standard korisničkog interfejsa.

Zahtjev za razvoj

- Izvođenje radova na izradi softvera;

Priprema za uvođenje AIS-a;

Kontrola, testiranje glavnih indikatora projekta.

Prateći zahtjevi

Završetak implementacije CIS-a treba da bude praćen objavljivanjem sistema administrativnih propisa i opisa poslova koji određuju funkcionisanje organizacije. Od momenta puštanja u rad informacionog sistema, rad se odvija na osnovu „Pravila za funkcionisanje informacionog sistema“ i niza propisa. Održavanje sistema i njegov nesmetani rad vrši pododjel organizacije ovlašten odgovarajućim nalogom. Završetak informacionog sistema nakon puštanja u rad vrši se u skladu sa pojedinačnim projektima i projektnim zadatkom.

U procesu održavanja CIS-a, zadatak je održati njegovu održivost. Održivost CIS-a je u velikoj mjeri određena time koliko on odgovara stvarnim zadacima i potrebama univerziteta, koji se mijenjaju tokom životnog ciklusa CIS-a.

Uvod

1. Arhitektura automatizovanih informacionih sistema i problemi njenog unapređenja 13

1.1. Modeli arhitekture i glavne komponente AIS 13

1.2. Problemi razvoja AIS-a 47

1.3. Platforme za implementaciju nove arhitekture AIS UP 53

1.4. Poglavlje 1 Zaključci 57

2. Model arhitekture AIS UE 58

2.1. Osnovni zahtjevi za AIS UP 59

2.2. Arhitektura AIS UP 66

2.3. AIS UP 89 komponente

2.4. Poglavlje 2 Zaključci 102

3. Metode za praktičnu implementaciju AIS UE 104

3.1. Alati razvoj AIS UP 104

3.2. Iskustvo u praktičnoj implementaciji modela AIS UP 111

3.3. Poglavlje 3 Zaključci 123

4. Zaključak 125

5. Terminologija i skraćenice 128

6. Književnost

Uvod u rad

Delatnost savremenih preduzeća povezana je sa kretanjem međusobno zavisnih i volumetrijskih tokova materijalnih, finansijskih, radnih i informacionih resursa. Upravljanje procesima proizvodnog i komercijalnog ciklusa u političkom i ekonomskom okruženju koje se dinamično mijenja zahtijeva brzo donošenje odluka u kratkom vremenu. Rješenje ovog problema u savremenim uslovima nemoguće bez upotrebe automatizovane obrade tehničkih ekonomske informacije.

U proteklih 40 godina automatizirane informacione tehnologije (IT) aktivno se koriste za rješavanje problema računovodstva, planiranja i analize. ekonomska aktivnost preduzeća različitih oblika svojine, delatnosti, organizacijske strukture i obim aktivnosti. Za to vrijeme stečeno je mnogo praktičnog iskustva u kreiranju automatiziranih informacionih sistema za upravljanje preduzećima (AIS UE), razvijene su i dobile univerzalno priznanje metodologije upravljanja, čija je primjena nemoguća izvan računarskog okruženja. Sa punom odgovornošću se može reći da je AIS UE postao sastavni dio poslovne infrastrukture. Teorijski i praktični problemi automatizacije ekonomskih procesa su duboko proučavani u radovima Glushkov V.M., Volkov S.I., Isakov V.I., Ostrovsky O.M., Podolsky V.I., Ratmirov Yu.A., Romanov A.N., Hotyashova E.N., Brady R., Zachman J. , Cook M., Finkelstein K., Hammer M. i drugi autori. Pristupi koje su oni predložili postali su osnova za korišćenje računarske tehnologije u preduzećima u rešavanju problema računovodstva, planiranja i analize finansijskih i ekonomskih aktivnosti. kako god

modeli koje su predložili nisu uzeli u obzir realnost ekonomije informacionog društva i trenutni nivo razvoja IT-a.

Razvoj komunikacijskih alata doprinosi sve bližoj interakciji između proizvođača i potrošača, dobavljača i kupaca, povećava konkurenciju na tržištu, proširuje granice lokalnih tržišta na nacionalna i transnacionalna i ubrzava vrijeme za ekonomske transakcije i finansijske transakcije. Implementacija globalnog kompjuterske mreže in ekonomskim procesima dovela je do pojave novih koncepata: ekonomije informacionog društva, e-poslovanje(e-poslovanje), elektronska trgovina(e-trgovina), elektronski trgovački pod(e-tržište) itd. Trendovi u globalizaciji privrede ogledaju se u novoj metodologiji organizacije poslovanja, u kojoj pitanje povećanja fleksibilnosti izgradnje poslovnih procesa i efikasnosti odnosa sa kupcima i dobavljačima dolazi do izražaja.

Postojeći koncepti organizacije AIS UE zasnovani su na funkcionalnom pristupu raspodjeli zadataka između njegovih podsistema. Međutim, AIS, izgrađen kao kompleks podsistema fokusiranih na pojedinačne funkcije upravljanja, ne ispunjava najbolje zahtjeve kontinuiteta end-to-end poslovnih procesa preduzeća. Stoga, u poslednjih godina Sve je popularniji pristup u kojem se u prvi plan stavljaju poslovni procesi, a ne pojedinačne funkcije servisa sistema upravljanja koji ih obavljaju. Potreban je razvoj novi koncept AIS UE arhitektura. Istovremeno, očigledno je da se prelazak na novu AIS UE arhitekturu ne može izvršiti odjednom, budući da su preduzeća i organizacije već dugi niz godina pustili u rad veliki broj softverskih alata koji implementiraju rješavanje važnih upravljačkih zadataka, od čije upotrebe se ne može odmah odustati. Nažalost, većina njih je usmjerena na autonomno funkcioniranje, što značajno otežava složenu integraciju tokova informacija. Mnogi postojeći softverski proizvodi koji pružaju podršku za rješavanje novih problema upravljanja preduzećima koji su nastali u kontekstu globalizacije privrede također su razvijeni bez dovoljno razrađenih interfejsa za interakciju sa softverskim sistemima koji implementiraju rješavanje srodnih problema. U ovim uslovima, zadatak sintetizacije integrisanih sistema upravljanja preduzećem integracijom gotovih komponenti trećih strana, prilagođenih rešenja i internog razvoja je od posebne važnosti.

U publikacijama naučnika i praktičara dugo se raspravlja o ideji implementacije standarda za sistemsku integraciju softverskih alata koje isporučuju različiti proizvođači. Napredak sistemskih alata doveo je do pojave objektno orijentisanih i komponentnih tehnologija razvoja softvera koje vam omogućavaju da izgradite sisteme velikih razmera od gotovih blokova. Vodeći dobavljači hardvera i sistemskog softvera (Intel, Microsoft, Sun, Oracle, IBM itd.), komunikacijskih alata (Cisco, Nortel, Ericsson, Motorola), primijenjenih rješenja (SAP, PeopleSoft, Siebel, itd.), autoritativnog stanja, međunarodne, komercijalne i neprofitne organizacije i udruženja (ISO, IEEE, ASCII, APICS, RosStandard, itd.) su do sada razvili i aktivno implementiraju u praksi tehnologije za integraciju hardvera i softvera koji omogućavaju kreiranje otvorenih sistema zasnovanih na standardima i protokolima za razmjenu podataka i interakciju komponenti u heterogeno okruženje u režimu realnog vremena.

Međutim, ovi prijedlozi pružaju samo sistemsku platformu, koja zahtijeva značajna usavršavanja u odnosu na određenu predmetnu oblast. U kontekstu praktične implementacije AIS UE, nisu dovoljno razvijeni mehanizmi za projektovanje i razvoj informacionih sistema (IS) korišćenjem komponentnih multilink arhitekture zasnovanih na standardima i protokolima otvorenih sistema.

U tom smislu, problem razvoja teorijske platforme i izrade praktičnih preporuka za izgradnju AIS UE, koji omogućava sveobuhvatnu automatizaciju svih informacionih procedura za upravljanje preduzećima i organizacijama, postaje hitan.

Potreba za razvojem holističkog pristupa rješavanju pitanja sistemske integracije AIS PM i end-to-end automatizacije mikroekonomskih procesa baziranih na savremenoj informatici odredila je izbor teme i smjera ove studije.

Cilj studije je da se razvije model AIS UE arhitekture koji obezbeđuje sveobuhvatnu automatizaciju i informatičku podršku za end-to-end poslovne procese, te da se sa stanovišta savremenih informacionih tehnologija obrazloži izbor alata za njegovu sistemsku integraciju.

Na osnovu zacrtanog cilja postavljeni su i riješeni sljedeći naučni i praktični zadaci:

Analizirati i generalizirati postojeće pristupe dizajnu, razvoju i implementaciji AIS UP softvera;

Klasificirati tipove softvera koji se koriste u praksi upravljanja preduzećem;

Istražite postojeće tehnologije i standarde koji omogućavaju integraciju heterogenih softverskih alata;

Da identifikuje probleme koji nastaju tokom integracije softverskih alata koji se koriste u AIS UE;

Da se sistematiziraju zahtjevi koje postavljaju preduzeća za AIS UE softver da se osigura informatička podrška kroz ekonomske procese;

Razviti model AIS UE arhitekture i istaći njegove glavne komponente;

Razviti principe interakcije i razmjene podataka komponenti AIS UE;

Predmet istraživanja su metode i alati za razvoj ekonomskih informacionih sistema.

Predmet istraživanja je IS upravljanja preduzećem.

Metodologija istraživanja zasnovana je na specifičnim primenama metodologije naučnog saznanja u primenjenim oblastima informatike i matematike.

Ciljevi i zadaci studije formulisani su u skladu sa glavnim pravcem rada na daljem razvoju i unapređenju matematičkih metoda i računarske tehnologije koja se koristi u ekonomskim predmetnim oblastima.

Uz opšti naučni pristup zasnovan na teoriji sistema, disertacija sumira iskustva razvoja, implementacije i rada softverskih alata domaćih i stranih proizvođača, metoda

implementacija međunarodnih otvorenih standarda za izgradnju informacionih sistema. Na osnovu toga, predložen je skup metodoloških i praktičnih preporuka koje su testirane u ruskim i stranim preduzećima.

U radu se koriste teorijske odredbe radova domaćih i stranih autora iz oblasti:

Automatska obrada ekonomskih informacija i modeliranje ekonomskih procesa;

Metodologije za planiranje i operativno upravljanje proizvodnjom i zalihama;

Reinženjering i računalni dizajn poslovnih procesa;

Savremeni standardi u informacionoj tehnologiji.

U toku studije, razvoji istraživačkih timova i pojedinačnih naučnika na Finansijskoj akademiji pri Vladi Ruske Federacije, Sveruskom dopisnom institutu za finansije i ekonomiju, Moskovskom državni univerzitet Ekonomija, statistika i informatika, Univerzitet za ekonomiju i finansije Sankt Peterburga. Voznesenskog, Istraživački finansijski institut i druge organizacije.

Informacionu bazu studije činili su softverski proizvodi ruskih i stranih proizvođača, publikacije u ekonomskim i kompjuterskim publikacijama, istraživanja međunarodnih istraživačkih grupa Gartner Group, Aberdeen, IDC, MetaGroup, DataQuest itd. nastavni materijali vodeće domaće i međunarodne konsultantske i revizorske kuće, rezultati istraživanja Udruženja softverskih programera iz oblasti ekonomije,

istraživanje tržišta softvera u Rusiji i zemljama ZND TSIES "Business-Programs-Service" .

Naučna novina disertacije leži u razvoju arhitektonskog modela AIS UE, fokusiranog na integrisanu automatizaciju end-to-end poslovnih procesa, i predlozima za njegovu implementaciju kroz sistemsku integraciju heterogenog softvera u distribuirano heterogeno mrežno okruženje zasnovano na o tehnologijama objekata i komponenti.

Naučna novina sadrži sljedeće rezultate dobijene u disertaciji:

Definicija i klasifikacija zahtjeva za funkcionalnost Softver za organizacijsko i ekonomsko upravljanje poduzećima;

AIS UE model arhitekture fokusiran na integrisanu automatizaciju end-to-end poslovnih procesa;

Principi integracije softverskih alata za rješavanje problema funkcionalnih usluga preduzeća sa osnovnim softverom za upravljanje poslovnim procesima, razmjenu podataka i upravljanje dokumentima;

Predlozi za organizovanje jedinstvenog informacionog prostora preduzeća, dostupnog zaposlenima i partnerima preduzeća putem korporativnog web portala;

Prijedlozi za implementaciju jedinstvenog sistema za formiranje i klasifikaciju izvještavanja korištenjem analitičkih alata;

Principi implementacije interakcije AIS UE podsistema zasnovanih na objektno orijentisanim i komponentnim tehnologijama i interakcija softverskih komponenti u distribuiranoj mreži

okruženje u skladu sa industrijskim standardima i internet protokolima;

Mehanizam za implementaciju adaptivnih svojstava modela arhitekture AIS UE softvera u skladu sa zahtevima određenog preduzeća, zasnovan na mogućnosti konfigurisanja osnovnih podsistema postojećim i projektovanim radnim procesima.

Praktični značaj rada na disertaciji je da implementacija predloženih prijedloga omogućava stvaranje AIS UE, pružajući efikasnu podršku informacijskim procedurama za upravljanje aktivnostima preduzeća u kontekstu ekonomske globalizacije i formiranja informacionog društva.

Predloženi model arhitekture AIS UE i preporuke za njegovu primenu imaju dovoljnu fleksibilnost i svestranost, što obezbeđuje njihovu primenljivost u IS upravljanja zgradama za preduzeća različitih oblika vlasništva, specifičnosti industrije i obima delatnosti.

Nezavisnu praktičnu vrijednost imaju:

Prijedlozi za izbor i primjenu standarda, protokola i drugih mehanizama koji se koriste u sistemskoj integraciji AIS UE;

Ponude za integrisana automatizacija end-to-end poslovni procesi i radni tok;

Prijedlozi za stvaranje jedinstvenog informacionog prostora preduzeća korištenjem mehanizma web portala;

Prijedlozi za prilagođavanje spiralno-iterativnog pristupa u razvoju i implementaciji AIS UP softvera.

Praktični značaj rada je evaluiran u konkretnim projektima za implementaciju predloženog problemski orijentisanog modela sistema automatizacije preduzeća:

Integrisani sistem upravljanja preduzećima "Flagman" kompanije "Infosoft",

eRelationship sistemi upravljanja odnosima s korisnicima Pivotal Software Corporation (Kanada),

Monarch ES sistemi korporativnog izvještavanja kompanije DataWatch (SAD),

Projekat integracije informacionih sistema kompanija Sovintel i Tele Ross.

Centar za obuku Vest-MetaTechnology koristi materijale koje je pripremio autor na osnovu pristupa predloženog u toku ove studije kada vodi kurseve o razvoju informacionih sistema za upravljanje preduzećima (vidi http://www.vest.msk.ru).

Materijali za istraživanje disertacije koriste se u istraživanju i praktične aktivnosti izvršni organi Asocijacije programera u ekonomiji (AREP) i njeni članovi.

Glavne odredbe rada su objavljene i diskutovane na:

Konferencija „IBM rešenja u oblasti poslovne integracije za telekomunikacione kompanije“, predstavništvo IBM-a u Istočnoj Evropi (Moskva, 18. juna 2002.);

Simpozijum "Call Center CRM Solutions 2002/Call Centers and Customer Relationship Management" (Moskva, mart 2002);

Konferencije programera informacionih sistema zasnovanih na alatima korporacije Centura Software Corp. (Berlin, Njemačka, 17-19. novembar 1999.);

Konferencija "InfoCity: praksa i problemi informatizacije gradova" (Moskva, oktobar 1999);

Naučno-praktične konferencije kompanije "Infosoft" (Moskva, 1995-1999);

Konferencija stručnjaka iz oblasti ACS i CIS" Enterprise Systems(Moskva, april 1998 i 28-30 april 1997, organizatori: kompanija SoftService i predstavništva Oracle, Informix, Sybase, Borland i Centura);

3. godišnja konferencija "Korporativne baze podataka 98" (Moskva, 31. mart-3. april 1998. i 26-29. mart 1996. u organizaciji Centra za informacione tehnologije uz učešće Izdavačke kuće Otvoreni sistemi);

Konferencija "Tehnikom-97" (Moskva, 24-26. novembar 1997, organizatori: SoftService, Rusko udruženje korisnika Oraclea, predstavništva Microsoft, Borland, Computer Associates, Lucent Software).

Problemi razvoja AIS-a

Uvođenje informacionih tehnologija u privredu, prodor kompjuterskih i komunikacionih alata u upravljanje preduzećima na svim nivoima, sve veći interes za interakciju kompanija putem interneta zahtevaju konceptualne promene u pristupima izgradnji AIS PM-a. Ovo se ne odnosi samo na čisto tehnološki problemi stvaranje i rad IS, ali i pristupi poslovnom upravljanju u uslovima ekonomije informacionog društva.

AIS UP treba da zadovolji potrebe za automatizacijom i informatizacijom u celoj organizaciji, što pred programere softvera postavlja zadatak da: razvijaju platformu sposobnu da podrži rad velikog broja korisnika; podrška komunikacijskim alatima i industrijskim standardima za razmjenu podataka i protokole interakcije komponenti; integraciju postojećeg razvoja u jedinstven sistem.

Integracija heterogenih aplikacija unutar jednog AIS-a treba da pruži podršku za: end-to-end poslovne procese; jednokorisnički interfejs (portal); zajednički informacioni prostor.

Po našem mišljenju, suština postavljenih problema nije toliko u tehničkim aspektima implementacije, koliko u potrebi korištenja fundamentalno novog modela AIS UE arhitekture.

Hajde da sumiramo prednosti i nedostatke različitih opcija IS arhitekture u smislu mogućnosti izgradnje integrisanog rešenja.

Centralizacija obrade podataka čini visoki zahtjevi na servere. Sa povećanjem broja istovremenih korisnika (što je neizbežno kada se procesi automatizuju u celom preduzeću), opterećenja postaju prevelika za hardversku platformu i softver koji se koristi. Koristeći različita hardverska rješenja (klasterizacija, višeprocesiranje i drugi oblici kombiniranja računarskih resursa), kao i distribuiranu obradu pomoću monitora transakcija, aplikacijskih servera i moćnog industrijskog DBMS-a, možete kreirati istinski skalabilna rješenja, oslobađajući centralne čvorove ne samo povećanjem snage hardvera, ali i zbog odgovarajuće konstrukcije softverskih komponenti sistema.

Međutim, čak i ako je centralni poslužitelj baze podataka sposoban pružiti potrebne performanse, s takvom konstrukcijom IS-a, neizbježno nastaju problemi u održavanju jedinstvene strukture zajedničke baze podataka ako se razvijaju pojedinačne softverske komponente IS-a. različite kompanije ili čak razvojni timovi unutar iste organizacije. Instaliranje zajedničke baze podataka sa pristupom iz programa za rešavanje različitih primenjenih problema omogućava obezbeđivanje zajedničkog informacionog prostora, gore navedene tehnologije omogućavaju pristup bazi podataka velikom broju korisnika, ali to ne garantuje ispravan rad sa zajedničkim podacima. Ostaje problem logičkog integriteta podataka. Kada koristite programe različitih proizvođača, postaje neizbježno razdvajanje podataka u podsisteme, eventualno denormalizacijom i stvaranjem redundantnih struktura. Šematska arhitektura sa zajednička baza prikazano na sljedećoj slici (Slika 1-14). Kao što slijedi iz gornjeg dijagrama, moduli nemaju interakciju, odnosno nema poziva od jednog modula do drugog u realnom vremenu, nema operativne podrške za end-to-end proces. Podaci se pohranjuju u bazu podataka iz koje su dostupni ostalim modulima koji trebaju sadržavati funkcije praćenja promjena u njoj, a relevantnost podataka ovisi o učestalosti provjere ažuriranja. Primjer procesa od kraja do kraja bi bio fakturisanje od strane zaposlenog u odjelu prodaje. Ukoliko za to koristi CRM sistem, generisani račun se mora obraditi paralelno sa izvodom u logističkom modulu ERP sistema radi rezervisanja robe, a odmah nakon toga - u finansijskom modulu za povećanje duga kupca. Da bi to učinili, relevantni moduli moraju provjeriti postojanje novog naloga. Ako se to ne uradi blagovremeno, može se ispostaviti faktura za stvarno rezervisanu stavku.

Da bi različiti moduli radili sa zajedničkom strukturom baze podataka, moraju se inicijalno razviti sa pogledom na određenu strukturu podataka ili koristiti dogovoreni mehanizam metapodataka (repozitorijum).

Kada se koristi drugačija arhitektura, kada se heterogene baze podataka održavaju na različitim računarima (i možda na različitim mrežama) i koriste ih autonomni moduli (slika 1-15), održavanje logičkog integriteta podataka je zadatak koji oduzima više vremena. U ovom slučaju potrebno je regulisati i implementirati replikaciju podataka (sinhronizaciju), objedinjavanje direktorija, pravila kodiranja i klasifikacije, razviti ili implementirati sam mehanizam replikacije. Sve ovo zahtijeva organizacijske mjere za sinhronizaciju baze podataka. Ostaje problem automatskog nastavka procesa (primjer sa fakturom).

Platforme za implementaciju nove AIS UE arhitekture

Do početka 21. stoljeća razvijena su i savladana sljedeća rješenja na industrijskom nivou u IT industriji, što je omogućilo široko uvođenje IT-a u ekonomske procese:

alat za personalno računarstvo, koji se sastoji u činjenici da je u mnogim vrstama posla nestala potreba za posrednicima između formulacije zadatka i njegovog izvršioca, odnosno da su zaposleni u funkcionalnim službama preduzeća u mogućnosti da obavljaju informacione procedure unutar njihovu osposobljenost za korištenje računara bez uključivanja ili uz minimalnu podršku pratećeg tehničkog osoblja;

sredstva automatizovane podrške za koordin zajednički rad grupe ("timovi") radnika na jednom projektu, dokumentu, zadatku itd.;

mehanizam elektronskih komunikacija, koji je u velikom broju slučajeva omogućio da se eliminiše potreba za prenosom papirnih dokumenata, da se minimizira potreba za sastancima, što je posebno važno kada su učesnici jednog ili drugog poslovni proces.

Zahvaljujući ovim rješenjima, postalo je moguće automatizirati većinu radnih procesa koji se odvijaju kako unutar poduzeća u njegovim financijskim, ekonomskim, proizvodnim i komercijalnim aktivnostima, tako i vezanih za eksterne funkcije. Kombinacija softverskih i hardverskih alata koji automatizuju različite funkcije i poslove omogućavaju povezivanje tehnoloških (na bazi opreme i tehničkih uređaja) i radnih procesa (uz učešće zaposlenih iz svih sektora preduzeća) u end-to-end poslovne procese. . Dakle, postoji fundamentalna mogućnost rješavanja problema izolacije mjesta porijekla podataka od centara njihovog skladištenja i obrade, odvajanja radnih mjesta jedno od drugog.

Rješavanje problema integracije AIS modula i odabir centraliziranog ili decentraliziranog pristupa u organizaciji njihove interakcije moguće je i zahvaljujući najnovijim dostignućima vodećih proizvođača sistemskog softvera: operativni sistemi, web serveri, aplikacijski serveri, DBMS i platforme međuopreme. Integracija aplikacija je omogućena korištenjem objektno orijentirane razvojne tehnologije i višeslojne arhitekture zasnovane na komponentama. Ključni princip ovdje je koncept programskih sučelja i pravila za njihovu promjenu i proširenje (IDL).

Za rad u distribuiranom heterogenom okruženju, kao što je Internet, aktivno se razvijaju specifikacije web servisa, od kojih svaka može implementirati jednu ili više poslovnih procedura ili funkcija (poslovnih procedura, funkcija). OASIS, BPMI i IBM, Microsoft i BEA objavili su BPEL4WS (jezik za izvršavanje poslovnih procesa za web usluge), XLANG i WSFL (jezik protoka web usluga) specifikacije za regulaciju toka posla i WfML koaliciju - XPDL (jezik za definiciju procesa XML) .

Trend je kombinovanje komponenti sa otvorenim interfejsima web servisa u podsisteme koji izvršavaju logički kompletne cikluse poslovnih procesa. U ovom slučaju, komponente se mogu nalaziti na različitim serverima aplikacija raspoređenim preko mreže i raditi s jednom ili više baza podataka. Promjenom broja i odnosa komponenti, broja i lokacije mrežnih servera, mogućnosti zamjene komponenti ili njihovog premeštanja po mreži bez gubitka kompatibilnosti, moguće je izgraditi AIS koji održava ravnotežu centralizacije i decentralizacije u poduzeću. menadžment.

Ne postoje tehničke prepreke za implementaciju takve arhitekture. Moderni industrijski aplikacijski serveri (na primjer, MTS / COM + / .Net, ONE ili J2EE / EJB) vam omogućavaju izgradnju višeslojnih sistema, pružaju zajedničku platformu za pristup različitim web servisima, osiguravaju transakcioni integritet operacija, balansiranje opterećenja sa konkurentski pristup desetinama hiljada korisnika u realnom vremenu, kao i garancija tolerancije grešaka i oporavka nakon kvarova.

Važno dostignuće IT industrije su standardi koji su postali široko rasprostranjeni i priznati od strane vodećih proizvođača softvera: protokoli interakcije komponenti (COM/DCOM, CORBA, Java RMI) i formati za razmenu podataka (EDI, XML,).

Standard EDI i njegove varijante specifične za industriju (EDIFACT, XI2, HIPAA, itd.) koriste se u finansijskim i industrijskim sektorima Sjeverne Amerike i Evrope od sredine 1970-ih i danas dominiraju u cijelom svijetu. Sa rastućom popularnošću XML-a na Internetu, EDI je preveden u XML.

Na osnovu XML-a (DTD i XDR) podaci su razvijeni, strukturirani i formatirani u različitim ekonomskim oblastima u obliku tzv. predmetnih rječnika ili tipova dokumenata, na primjer, WIDL, OFX, FpML, IFX, XBRL, CRML i brojni drugi na Zapadu, kao i CommerceML.ru i XML Partnership/ARB u Rusiji. Američko društvo za proizvodnju i upravljanje zalihama APICS, koje certificira sisteme ERP/MRP klase, objavljuje specifikacije privrednih subjekata u XML formatu, na primjer, strukturu i format podataka o kupcu ili fakturi. Samodokumentirajući XML pruža nedvosmisleno razumijevanje podataka od strane ljudi i programa.

AIS UE arhitektura

Da bismo izgradili model AIS UE arhitekture, preduzeće ćemo razmotriti kao skup radnih, finansijskih, materijalnih i informacionih resursa uključenih u poslovne procese za postizanje poslovnih ciljeva preduzeća. Ovdje se pojam poslovnih ciljeva odnosi na strateške dugoročne ciljeve koje postavljaju vlasnici i top menadžeri, kao i na trenutne ciljeve koje postavljaju najviši i srednji menadžeri. Poslovni proces ili poslovni proces je niz radnji zaposlenih, operacija na radnim mestima, kao i funkcija koje softver i hardver obavlja u automatskom režimu. Nazovimo svaku radnju ili njihov niz fazom procesa. Sinonimi za akcije mogu biti i operacije, procedure. Ako faza zahtijeva radnje zaposlenog (grupe uloga, predstavnika ili šefa odjela, kao i osobe na službenoj funkciji), onda se to naziva i zadatkom, a zaposlenik se naziva izvršilac. Redoslijed radnji u poslovnom procesu može biti dvosmislen, odnosno opis procesa u obliku usmjerenog grafa može uključivati ​​grananje sa uslovima za prelazak iz jedne faze u drugu. Tipični lanci faza mogu se podijeliti u podprocese. Kretanje zadataka po određenim fazama procesa naziva se ruta. Ako se proces ne može opisati zbog proizvoljnih prijelaza između faza, o čemu odluku donosi izvođač tokom izvršavanja zadatka u trenutnoj fazi, onda se ovaj slučaj naziva slobodno rutiranje.

AIS PM treba da omogući formalno opisivanje poslovnih procesa u grafičkom obliku u obliku usmjerenog grafa (digrafa), čiji su vrhovi etape, a ivice prijelazi između faza. U konkretnom slučaju, graf poslovnog procesa izgleda ovako mrežni dijagram, gdje vrhovi označavaju poslove sa naznakom njihovog trajanja, a orijentirane ivice (strelice) pokazuju redoslijed poslova. U skladu sa opisom procesa, koji se naziva mapa procesa, AIS UE mora upravljati resursima (ili, tačnije, pomoći menadžerima preduzeća da upravljaju njima), dodijeliti zadatke i njihove izvršioce, te pozvati (aktivirati) softver i hardver za pokretanje automatizovanih procedura.

Parametri obima preduzeća utiču na organizaciju upravljanja u pojedinom preduzeću, što se ogleda u zahtevima za AIS UE. S druge strane, AIS UE utiče na obim preduzeća, na primer, doprinoseći rastu poslovanja. Promjena jednog od parametara podrazumijeva ažuriranje AIS-a na isti način kao što uvođenje AIS-a može promijeniti organizaciju upravljanja.

Svrha fokusiranja na poslovne procese prilikom izgradnje AIS UE je pronalaženje zajedničke platforme na osnovu koje će biti moguće adekvatno modificirati AIS bez potrebe za potpunim reorganizacijom sistema. Ova platforma je modeliranje poslovnih procesa softverom za upravljanje procesima.

Kao srž AIS PM-a, neophodno je razviti sistem koji kombinuje nekoliko funkcija o kojima se govori u pregledu sistema upravljanja procesima (paragrafi "1.1.7 Sistemi upravljanja dokumentima" na strani 31 i "1.1.8 Sistemi za upravljanje procesima" na strani 34). Među njima: Workflow - podsistem za upravljanje radnicima i tehnološkim procesima, koji obezbeđuje unapred definisano i slobodno rutiranje zadataka između izvođača; Docflow - podsistem za upravljanje tokom dokumenata i usmjeravanje dokumenata sa praćenjem njihovog stanja; Groupware - podsistem za podršku funkcijama operativnog dodjeljivanja zadataka i slobodnog rutiranja (ad hoc) zadataka između članova grupe izvođača; Protok podataka - usmjeravanje podataka, paketa podataka, poruka između aplikacija.

Za razliku od prihvaćene prakse autonomnog korišćenja sistema ove vrste, ovde pretpostavljamo postojanje zajedničke mape procesa, zajedničkog modula za obradu faza procesa, zajedničkog mehanizma za dodeljivanje izvršilaca i rutiranja zadataka i podataka.

Dakle, generisani tehnološki podaci tehnički uređaji, činjenične podatke koje u IS unose korisnici na radnim mjestima (uključujući primarne dokumente), kao i podatke koje generira softverske aplikacije, biće uneseni u AIS UE i dostupni potrošačima informacija u realnom vremenu.

Šematski je životni ciklus obrade podataka u AIS UE prikazan na sljedećoj slici (Slika 2-2). Podaci uneseni ručno ili primljeni od softverskih komponenti se formaliziraju kao dokument, koji modul toka posla dalje obrađuje u skladu sa mapom procesa. Na ruti obrade (ako to zahtijeva konfiguracija sistema), podsistem za upravljanje dokumentima poziva module funkcionalnih podsistema za obradu finansijskih, poslovnih i drugih vrsta transakcija. Kao rezultat toga, vjerodajnice se pohranjuju u strukturirane baze podataka. Zauzvrat, sami dokumenti se pohranjuju u skladištu ili nestrukturiranoj bazi podataka. Sve ove baze podataka moraju biti dostupne analitičkim modulima izvještajnog podsistema za generiranje potrebnih izvještaja.

Iskustvo u praktičnoj implementaciji AIS UE modela

Od 1995. do 1999. godine, pod rukovodstvom autora disertacije, razvijen je sistem integrisane automatizacije upravljanja preduzećem „Flagman“ kompanije „Infosoft“, koji je trenutno implementiran u više od stotinu velikih i srednjih industrijskih preduzeća. , građevinska, komercijalna, poljoprivredna preduzeća i budžetske organizacije Rusija i zemlje ZND. Sistem nastavlja da se razvija na osnovu kernela koji je razvio autor, a do 2002. godine "Flagship" uključuje više od deset glavnih podsistema, prikazanih na sledećoj slici (Slika 3-2):

Osnovu sistema "Flagship" čini osnovni modul "Upravljanje dokumentima", koji je odgovoran za unos, obradu, usmjeravanje i štampanje svih primarnih dokumenata. Ostali osnovni moduli su "Administracija" i "Alati", zajednički za sve funkcionalne module. Oni vam omogućavaju da konfigurišete grupe uloga i prava pristupa, radne stanice do stavki menija, izgled dokumenata i šablone izveštaja.

Prednosti implementiranog modela bile su jednostruki unos primarnih dokumenata, generisanje računa u funkcionalnim podsistemima na osnovu ovih dokumenata i objedinjavanje rada sa primarnim dokumentima.

Brzi razvoj podsistema i nedostatak standardizacije njihove interakcije doveli su do toga da se integracija odvijala oko centralne baze podataka i zajedničkih tabela. Ako ne uzmemo u obzir dvoslojnu arhitekturu, čiji je izbor bio određen stepenom razvoja razvojnih alata 1995. godine, tada je unakrsna zavisnost modula postala glavni problem razvoja sistema. Njegove prve implementacije otkrile su nedovoljnost funkcija automatizacije toka posla samo usmjeravanjem dokumenata i postavile su pitanje potrebe za implementacijom modula za upravljanje procesima (workflow).

Ako detaljnije razmotrimo implementaciju, onda je modul za upravljanje dokumentima biblioteka objekata uključenih u sve podsisteme, a takođe je sastavljena kao samostalni modul. Biblioteka uključuje alate za podešavanje tipova i varijanti dokumenata, sastav polja, forme za unos i uređivanje, listu stanja, moguće kombinacije prelaza iz stanja u stanje, listu operacija povezanih sa funkcionalnim modulima, šablone i obrasce za štampanje , kao i pravila za formiranje registara i evidencije dokumenata .

Operacije s dokumentima mijenjaju njihovo stanje i također pozivaju funkcije podsistema aplikacije. Lista funkcija je ugrađena u svaki podsistem i specifična je za njega. Za prateće programere uključene u postavljanje sistema, dostupni su parametri funkcije i mogućnost vezivanja polja dokumenta pomoću formula. Ovo vam omogućava automatizaciju većine finansijskih transakcija, kao i logističkih funkcija, kadrovske evidencije i platni spisak, ali puna implementacija i dalje zahtijeva skriptni jezik.

Sistem ima ugrađeni generator izvještaja zajednički za sve podsisteme. Budući da je sistem zasnovan na principu integracije oko centralne baze podataka, generator ima pristup svim podacima, bez obzira da li pripadaju modulima. Izveštaji su klasifikovani u hijerarhijsku strukturu, svaki od izgleda izveštaja sadrži šablon za preview i ispis, i SQL upite za generiranje rezultirajućeg skupa podataka. Generisani izveštaji se mogu dalje obraditi kao dokumenti.

Takođe treba napomenuti da vodeći sistem implementira objedinjeni izgled podsistemi. Modul opšte administracije za elemente korisničkog interfejsa, AWP funkcije, uključujući menije i trake sa alatkama, omogućava vam da prilagodite izgled na ujednačen način.

Na ovog trenutka IT razvoj zahteva ažuriranje platforme Flagman sistema. Prije svega, potrebno ga je prenijeti na troslojnu arhitekturu i razviti modul za upravljanje dokumentima u potpuno funkcionalan sistem upravljanja procesima. Takođe je potrebno razviti mehanizme za integraciju eksternih aplikacija, jer sistem ima samo sredstva za uvoz i izvoz podataka.

Ipak, brojni primjeri uspješne implementacije i komercijalnog rada Flagman sistema, rast broja njegovih prodaja u periodu 2001-2002. ekonomska efikasnost rješenja za automatizaciju poduzeća različitih djelatnosti, djelatnosti i obima.

U februaru 1999. godine, sistem "Flagman" kompanije "Infosoft", kreiran pod vodstvom autora, prepoznat je kao najbolji ruski razvoj na Centura Team Developer alatki od strane Centura Software Corp. (SAD) i kompanije "Interface" (Rusija). Godine 1999, 2000 i 2001 CIS "Flagman" je certificiran kao informacioni sistem za cijelo preduzeće od strane stručnjaka žirija takmičenja "Business-Soft", održanog od strane Udruženja programera softvera u oblasti ekonomije (AREP), TSIES "Business Programs-Service “, časopisa “Računovodstvo” i “Finansijske novine”.