Model životného cyklu je štruktúra, ktorá definuje postupnosť vykonávania a vzťahy medzi procesmi, činnosťami a úlohami vykonávanými počas životného cyklu.
Najpoužívanejšie sú dva hlavné modely životného cyklu:
· kaskádový model (70-85);
· špirálový model (86-90).
Kaskádový model
Kaskádová metóda je rozdelenie celého vývoja na etapy a prechod z jednej etapy do ďalšej nastáva až po úplnom ukončení prác na súčasnej (obr. 2).
Pozitívne aspekty použitia kaskádového prístupu:
· v každej fáze sa vytvorí kompletný súbor projektovej dokumentácie spĺňajúce kritériá úplnosti a konzistentnosti;
· etapy prác vykonávané v logickom slede nám umožňujú plánovať čas dokončenia všetkých prác a zodpovedajúce náklady.
Kaskádový prístup sa dobre osvedčil pri konštrukcii informačných systémov, na ktoré sa dajú všetky požiadavky celkom presne a úplne formulovať už na začiatku vývoja. Do tejto kategórie patria komplexné výpočtové systémy, systémy v reálnom čase a iné podobné úlohy.
Obr.2 Schéma kaskádového prístupu
V skutočnosti však v procese vytvárania IP existuje neustála potreba vracať sa k predchádzajúcim fázam, objasňovať alebo revidovať skôr prijaté rozhodnutia. Skutočný proces tvorby informačný systém má nasledujúcu podobu (obr. 3):
Obr.3 Skutočný proces vytvárania IP na základe vodopádového modelu
Jedným z názvov používaných v západnej literatúre pre takúto schému organizácie práce je „vodopádový model“.
Hlavnou nevýhodou kaskádového prístupu je značné oneskorenie pri získavaní výsledkov. Modely (funkčné aj informačné) automatizovaného objektu môžu zastarať súčasne s ich schválením. Ďalšou nevýhodou je, že takýto návrh informačného systému vedie k primitívnej automatizácii (v podstate „mechanizácii“) existujúcich výrobných činností pracovníkov.
Špirálový model životného cyklu (obr. 4) kladie dôraz na počiatočné fázy životného cyklu: analýzu a návrh. Uskutočniteľnosť technických riešení sa testuje vytváraním prototypov.
Obr.
Každé otočenie špirály zodpovedá vytvoreniu nového fragmentu alebo verzie informačného systému, objasnia sa ciele a charakteristiky projektu, určí sa jeho kvalita a naplánuje sa práca na ďalšom otočení špirály. V tomto prípade jedno otočenie špirály predstavuje úplný projektový cyklus podobný kaskádovej schéme. Tento prístup sa nazýval aj „pokračujúci dizajn“. Neskôr projektový cyklus začal dodatočne zahŕňať etapy vývoja a testovania prototypového systému. Nazývalo sa to: „rýchle prototypovanie“, prístup k rýchlemu prototypovaniu alebo „rýchla trať“.
Použitie takýchto metód však spolu s rýchlym efektom znižuje zvládnuteľnosť projektu ako celku a prepojenosť rôznych fragmentov informačného systému. Hlavným problémom špirálového cyklu je určenie momentu prechodu do ďalšej fázy. Prechod prebieha podľa plánu, aj keď nie sú dokončené všetky plánované práce. Plán je zostavený na základe štatistických údajov získaných v predchádzajúcich projektoch a osobná skúsenosť vývojárov.
Modely životného cyklu AIS –Štruktúra, ktorá definuje sekvenčnú implementáciu procesov, akcií, úloh vykonávaných počas celého životného cyklu a vzťahy medzi týmito procesmi.
Kaskádový model. Prechod do ďalšej fázy znamená úplné dokončenie práce v predchádzajúcej fáze. Požiadavky stanovené vo fáze tvorby požiadaviek sú prísne zdokumentované vo forme technických špecifikácií a zaznamenávajú sa počas celého vývoja projektu. Každá fáza vyvrcholí vydaním kompletného súboru dokumentácie, ktorý je dostatočný na to, aby vo vývoji mohol pokračovať ďalší vývojový tím.
Etapy projektu podľa vodopádového modelu:
1. Tvorba požiadaviek;
2. Dizajn;
3. rozvoj;
4. Testovanie;
5. Implementácia;
6. Prevádzka a údržba.
Výhody:
- Kompletná a odsúhlasená dokumentácia v každej fáze;
-určité poradie postupnosti práce;
-Umožňuje jasne plánovať termíny a náklady.
nedostatky:
-Výrazné oneskorenie pri dosahovaní konečných výsledkov;
-Chyby v ktorejkoľvek fáze sú identifikované v ďalších fázach, čo vedie k potrebe vrátenia a opätovnej registrácie projektovej dokumentácie;
-Zložitosť projektového manažmentu.
Špirálový model. Každá iterácia zodpovedá vytvoreniu fragmentu alebo verzie softvéru, pri ktorej sa vyjasnia ciele a charakteristiky projektu, posúdi sa kvalita získaných výsledkov a naplánuje sa práca ďalšej iterácie.
Každá iterácia je ukončený vývojový cyklus v podobe 1. verzie AIS.
Etapy iterácie:
1. Tvorba požiadaviek
3. Dizajn
4.Vývoj
5.Integrácia
Pri každej iterácii sa vyhodnocujú:
Riziko prekročenia termínov projektu a nákladov;
Potreba vykonať ďalšiu iteráciu;
Stupeň úplnosti a presnosti pochopenia systémových požiadaviek;
Možnosť ukončenia projektu.
Výhody:
-Proces vykonávania zmien v projekte je zjednodušený;
- Poskytuje väčšiu flexibilitu pri riadení projektov;
-Schopnosť získať spoľahlivý a stabilný systém, pretože chyby a nezrovnalosti sa zisťujú pri každej iterácii;
-Vplyv zákazníka na prácu počas procesu overovania každej iterácie.
nedostatky:
-Náročnosť plánovania;
-Intenzívny pracovný plán pre vývojárov;
-Plánovanie práce sa vykonáva na základe existujúcich skúseností a nie je dostatok metrík na meranie kvality každej verzie.
Požiadavky na technológiu návrhu, vývoja a podpory AIS
Dizajnová technológia- definuje kombináciu troch komponentov:
- postup krok za krokom, definujúci postupnosť technologické operácie dizajn;
-pravidlá používané na hodnotenie výsledkov technologických operácií;
-výkon dizajnový vývoj na preskúmanie a schválenie.
Technologické pokyny, ktoré tvoria hlavný obsah technológie, musia pozostávať z opisu postupnosti technologických operácií, podmienok v závislosti od toho, ktorá operácia sa vykonáva, a opisov samotných operácií.
Technológia navrhovania, vývoja a údržby IS musí spĺňať nasledovné všeobecné požiadavky:
Technológia musí podporovať celý životný cyklus softvéru;
Technológia musí zabezpečiť garantované dosiahnutie cieľov rozvoja IS v danej kvalite a v predpísanom čase;
Technológia by mala poskytovať možnosť vykonávať práce na návrhu jednotlivých podsystémov v malých skupinách (3-7 osôb). Je to spôsobené princípmi riadenia tímu a zvyšovaním produktivity minimalizáciou počtu vonkajšie vzťahy;
Technológia by mala poskytovať možnosť spravovať konfiguráciu projektu, udržiavať verzie projektu a jeho súčastí, schopnosť automaticky uvoľňovať projektovú dokumentáciu a synchronizovať jej verzie s verziami projektu;
Použitie akejkoľvek technológie na návrh, vývoj a údržbu informačných systémov v konkrétnej organizácii a konkrétnom projekte je nemožné bez vypracovania množstva noriem (pravidiel, dohôd), ktoré musia dodržiavať všetci účastníci projektu. K takýmto štandardy zahŕňajú nasledovné:
-štandard dizajnu;
- norma pre projektovú dokumentáciu;
-štandard používateľského rozhrania.
Požiadavka na rozvoj
- Vykonávanie prác na stvorení softvér;
Príprava na implementáciu AIS;
Monitorovanie a testovanie kľúčových ukazovateľov projektu.
Požiadavky na údržbu
Ukončenie implementácie CIS musí byť sprevádzané zverejnením systému správnych predpisov A popisy práce, definujúci poriadok fungovania organizácie. Od spustenia informačného systému do prevádzky prebieha prevádzka na základe „Predpisov pre fungovanie informačného systému“ a množstva predpisov. Údržbu systému a jeho nepretržitú prevádzku vykonáva útvar organizácie poverený príslušným príkazom. Spresnenie informačného systému po uvedení do prevádzky prebieha v súlade s jednotlivými projektmi a technickými špecifikáciami.
V procese udržiavania CIS je úlohou zachovať jeho životaschopnosť. Životaschopnosť CIS je do značnej miery daná tým, ako dobre zodpovedá skutočným úlohám a potrebám univerzity, ktoré sa v priebehu životného cyklu CIS menia.
Popis prezentácie Etapy tvorby modelov životného cyklu AIS AIS na diapozitívoch
Životný cyklus AIS je súbor etáp, ktorými AIS prechádza vo svojom vývoji od momentu rozhodnutia o vytvorení systému až po moment, keď prestane fungovať.
Fázy životného cyklu 1 Plánovanie a analýza (fáza predbežného návrhu) – určenie toho, čo by mal systém robiť. Príprava štúdie uskutočniteľnosti (TES) a technických špecifikácií (TOR).
2 Návrh (technický a logický návrh) - určenie, ako bude systém fungovať (špecifikácia* subsystémov, funkčných komponentov a spôsobov ich interakcie). Príprava technického projektu. * Špecifikácia - presný, úplný, jasne formulovaný popis požiadaviek na danú úlohu.
3. Implementácia (detailný návrh, programovanie) - Tvorba funkčných komponentov a jednotlivých subsystémov, prepojenie subsystémov do jedného celku. Napĺňanie databázy. Tvorba pokynov pre personál. Registrácia pracovného návrhu
4 Implementácia (testovanie, skúšobná prevádzka) – inštalácia a uvedenie systému do prevádzky, odladenie subsystémov, zaškolenie personálu. Vypracovanie protokolu o akceptačnej skúške.
Poznámky 1. Etapy 2 a 3 je možné spojiť do jedného: technologický dizajn alebo systémová syntéza. 2. V každej fáze životného cyklu sa používa určitý súbor technických riešení a príslušných dokumentov
3. Pre každú fázu sú východiskovými bodmi dokumenty a rozhodnutia prijaté v predchádzajúcej fáze. 4. Modely životného cyklu určujú poradie vykonávania etáp v procese vytvárania systému a kritériá prechodu z fázy do fázy.
Model životného cyklu je modelom tvorby a používania AIS, ktorý odráža rôzne stavy systému od jeho vzniku až po moment jeho úplného zastarania.
Základné modely kaskádového životného cyklu – zahŕňajú prechod do ďalšej fázy po úplnom dokončení práce predchádzajúcej. Tento model sa používa pri konštrukcii automatizovaných informačných systémov, na ktoré sú od začiatku presne a kompletne formulované všetky požiadavky. Nevýhody: rigidná schéma - nemožnosť návratu k predchádzajúcim etapám a použitie pre zložité systémy.
Krok za krokom iteračný model Predpokladá prítomnosť spätná väzba medzi cyklami. Výhodou je, že medzistupňové úpravy poskytujú väčšiu flexibilitu a menšiu námahu. Nevýhodou je, že životnosť každej etapy sa môže pretiahnuť počas celého obdobia tvorby systému Ťažkosti a nevýhody špirálového modelu životného cyklu Hlavným problémom je určenie prechodu do ďalšej etapy: na vyriešenie sú pre každú zavedené časové obmedzenia. etáp. Prechod sa uskutočňuje v súlade s plánom vypracovaným na základe štatistických údajov z predchádzajúcich projektov a skúseností developerov. Nevýhody: Chyby urobené počas fáz analýzy a návrhu môžu viesť k problémom v nasledujúcich fázach a zlyhaniu celého projektu.
Rola užívateľa AIS je vytvorená tak, aby vyhovovala informačným potrebám konkrétneho užívateľa. Je priamo zapojený do jeho práce. .
Užívateľ sa podieľa na formulácii problému a vykonáva skúšobnú prevádzku, počas ktorej môže odhaliť nedostatky vo formulácii, upraviť vstupné a výstupné informácie, formuláre na vydávanie výsledkov, papierovanie.
Účasť používateľov na tvorbe automatizovaných informačných systémov zabezpečuje rýchle a kvalitné riešenia problémov a skracuje čas na zavádzanie nových technológií.
Úvod
1. Architektúra automatizovaných informačných systémov a problémy jej zlepšovania 13
1.1. Modely architektúry a hlavné komponenty AIS 13
1.2. Problémy vývoja AIS 47
1.3. Platformy pre implementáciu novej architektúry AIS UP 53
1.4. Kapitola 1 Závery 57
2. Model architektúry AIS UE 58
2.1. Základné požiadavky na AIS UP 59
2.2. Architektúra AIS UP 66
2.3. Komponenty AIS UP 89
2.4. Kapitola 2 Závery 102
3. Metódy praktickej implementácie AIS UE 104
3.1. Vývojové nástroje AIS UP 104
3.2. Skúsenosti s praktickou implementáciou modelu AIS UP 111
3.3. Kapitola 3 Závery 123
4. Záver 125
5. Terminológia a skratky 128
6. Literatúra
Úvod do práce
Aktivita moderné podniky spojené s pohybom vzájomne závislých a objemných tokov materiálových, finančných, pracovných a informačné zdroje. Riadenie procesov výrobného a obchodného cyklu v dynamicky sa meniacom politickom a ekonomickom prostredí si vyžaduje rýchle rozhodovanie v krátkom čase. Riešením tohto problému je moderné podmienky nemožné bez použitia finančných prostriedkov automatizované spracovanie technické a ekonomické informácie.
Za posledných 40 rokov sa automatizované informačné technológie (IT) aktívne využívajú na riešenie problémov účtovníctva, plánovania a analýzy. ekonomická aktivita podniky rôznych foriem vlastníctva, odvetvová príslušnosť, Organizačná štruktúra a rozsah činnosti. Za tento čas sa nazbierali rozsiahle praktické skúsenosti s vytváraním automatizovaných podnikových manažérskych informačných systémov (AIS EM) a boli vyvinuté a všeobecne uznávané manažérske metodiky, ktorých použitie mimo počítačového prostredia je nemožné. S plnou zodpovednosťou možno konštatovať, že AIS UE sa stali integrálnou súčasťou podnikovej infraštruktúry. Teoretické a praktické problémy automatizácie ekonomických procesov sú hlboko študované v prácach Glushkova V.M., Volkova S.I., Isakova V.I., Ostrovského O.M., Podolského V.I., Ratmirova Yu.A., Romanova A.N., Khotashova E.N., Bradyho R., Zachmana J. , Cook M., Finkelstein K., Hammer M. a ďalší autori. Prístupy, ktoré navrhli, sa stali základom pre využitie výpočtovej techniky v podnikoch pri riešení problémov účtovníctva, plánovania a analýzy finančných a ekonomických činností. Avšak
modely, ktoré navrhli, nezohľadňovali realitu ekonomiky informačnej spoločnosti a súčasná úroveň rozvoja IT.
Rozvoj komunikačných médií podporuje čoraz užšiu interakciu medzi výrobcami a spotrebiteľmi, dodávateľmi a nákupcami, zvyšuje konkurenciu na trhu, rozširuje hranice lokálnych trhov na národné a nadnárodné a zrýchľuje čas ekonomických transakcií a finančných transakcií. Zavedenie globálnych počítačových sietí do ekonomických procesov viedlo k vzniku nových pojmov: ekonomika informačnej spoločnosti, elektronické podnikanie (e-business), elektronický obchod(elektronický obchod), elektronický obchodná platforma(e-trhovisko) a pod. .
Existujúce koncepcie organizácie AIS CP sú založené na funkčnom prístupe k rozdeleniu úloh medzi jeho subsystémy. AIS, budovaný ako komplex subsystémov zameraných na jednotlivé riadiace funkcie, však nevyhovuje najlepšie požiadavke kontinuity end-to-end podnikových procesov podniku. Preto sa v posledných rokoch stáva čoraz populárnejším prístup, v ktorom sú do popredia kladené podnikové procesy a nie jednotlivé funkcie služieb systému manažérstva, ktoré ich vykonávajú. To si vyžaduje vývoj novej koncepcie architektúry AIS UE. Zároveň je zrejmé, že prechod na novú architektúru AIS CP nie je možné uskutočniť zo dňa na deň, keďže podniky a organizácie v priebehu mnohých rokov uviedli do prevádzky veľké množstvo softvérových nástrojov, ktoré implementujú riešenie dôležitých problémov riadenia, napr. od používania ktorých nemožno okamžite upustiť. Žiaľ, väčšina z nich je zameraná na autonómne fungovanie, čo značne komplikuje komplexnú integráciu informačných tokov. Mnohé existujúce softvérové produkty, poskytujúce podporu pri riešení nových problémov podnikového manažmentu, ktoré vznikli v kontexte globalizácie ekonomiky, boli tiež vyvinuté bez dostatočného rozvoja rozhraní pre interakciu s softvérové systémy implementáciu riešenia súvisiacich problémov. Za týchto podmienok naberá úloha syntézy osobitný význam. komplexné systémy riadenie podniku integráciou hotových komponentov od výrobcov tretích strán, zákazníckych riešení a vlastného vývoja.
O myšlienke implementácie noriem už dlho diskutovali vedci a odborníci z praxe integrácia systému softvér dodávaný rôznymi výrobcami. Pokrok systémových nástrojov viedol k vzniku objektovo orientovaných a komponentových technológií vývoja softvéru, ktoré umožňujú budovať rozsiahle systémy z hotových blokov. Poprední dodávatelia hardvéru a systémového softvéru (Intel, Microsoft, Sun, Oracle, IBM, atď.), komunikačných nástrojov (Cisco, Nortel, Ericsson, Motorola), aplikačných riešení (SAP, PeopleSoft, Siebel atď.), renomovaná vláda, medzinárodné, obchodné a neziskové organizácie a asociácie (ISO, IEEE, ASCII, APICS, RosStandard atď.) v súčasnosti vyvinuli a aktívne zavádzajú do praxe technológie na integráciu hardvéru a softvéru, umožňujúce vytváranie otvorených systémov založených na štandardoch a protokoloch na výmenu údajov a interakciu komponentov. v heterogénnom prostredí v reálnom čase.
Tieto návrhy však poskytujú len celosystémovú platformu, ktorá si vyžaduje značné objasnenie vo vzťahu ku konkrétnej tematickej oblasti. V kontexte praktickej implementácie AIS CP boli vyvinuté mechanizmy pre návrh a vývoj informačných systémov (IS) s využitím komponentných viacvrstvových architektúr založených na štandardoch a protokoloch. otvorené systémy nedostatočne vyvinuté.
V tomto ohľade problém rozvoja teoretickej platformy a rozvoja praktické odporúčania, zameraná na vybudovanie automatizovaného systému riadenia informácií, ktorý poskytuje komplexnú automatizáciu všetkých informačných postupov pre riadenie podnikov a organizácií.
Potreba vyvinúť holistický prístup k riešeniu problematiky systémovej integrácie AIS PM a end-to-end automatizácie mikroekonomických procesov na báze moderných IT predurčila výber témy a smerovania tohto výskumu.
Cieľom štúdie je vyvinúť model architektúry AIS CP, ktorý poskytuje komplexnú automatizačnú a informačnú podporu pre komplexné podnikové procesy, a zdôvodniť výber nástrojov pre jeho systémovú integráciu z pohľadu moderných informačných technológií.
Na základe zamýšľaného cieľa boli stanovené a vyriešené nasledovné vedecké a praktické úlohy:
Analyzovať a sumarizovať existujúce prístupy k návrhu, vývoju a implementácii softvéru AIS CP;
Klasifikovať typy softvéru používaného v praxi riadenia podniku;
Výskum existujúcich technológií a noriem, ktoré zabezpečujú integráciu rôznych softvérových nástrojov;
Identifikovať problémy, ktoré vznikajú pri integrácii softvéru používaného v AIS CP;
Systematizovať požiadavky na podnikový softvér AIS na poskytovanie informačnej podpory pre komplexné ekonomické procesy;
Vypracovať model architektúry AIS UE a zdôrazniť jej hlavné komponenty;
Vypracovať zásady interakcie a výmeny údajov komponentov AIS UE;
Predmetom výskumu sú metódy a nástroje rozvoja ekonomických informačných systémov.
Predmetom štúdia sú podnikové manažérske informačné systémy.
Metodológia výskumu je založená na špecifických aplikáciách metodológie vedeckého poznania v aplikovaných oblastiach informatiky a matematiky.
Ciele a zámery štúdie boli formulované v súlade s hlavným smerom práce na ďalší vývoj a zdokonaľovanie matematických metód a výpočtovej techniky používaných v ekonomických predmetoch.
Spolu so všeobecným vedeckým prístupom založeným na teórii systémov sú v dizertačnej práci zhrnuté skúsenosti z vývoja, implementácie a prevádzky softvérových nástrojov domácich a zahraničných výrobcov, metódy
implementácia medzinárodných otvorených štandardov pre budovanie informačných systémov. Na tomto základe sa navrhuje súbor metodických a praktických odporúčaní, ktoré boli testované v ruských a zahraničných podnikoch.
Práca využíva teoretické ustanovenia z diel domácich a zahraničných autorov z oblasti:
Automatizované spracovanie ekonomických informácií a modelovanie ekonomických procesov;
Metodiky plánovania a operatívneho riadenia výroby a zásob;
Reinžiniering a počítačom podporovaný návrh obchodných procesov;
Moderné štandardy v oblasti informačných technológií.
Výskum analyzoval a využíval vývoj výskumných tímov a jednotlivých vedcov na Finančnej akadémii pri vláde Ruskej federácie, Všeruskom korešpondenčnom inštitúte financií a ekonómie, Moskovskej štátnej univerzite ekonómie, štatistiky a informatiky, St. Petrohradská univerzita ekonómie a financií. Voznesensky, Vedecký výskum finančné inštitúcie a ďalšie organizácie.
Informačná báza štúdie zahŕňala softvérové produkty ruských a zahraničných výrobcov, publikácie v ekonomických a počítačových publikáciách, výskumy medzinárodných výskumných skupín Gartner Group, Aberdeen, IDC, MetaGroup, DataQuest atď. učebných materiálov popredné domáce a medzinárodné poradenské a audítorské spoločnosti, výsledky výskumu Asociácie softvérových vývojárov v oblasti ekonomiky,
Prieskum softvérového trhu v Rusku a krajinách SNŠ CIES "Business Programs-Service".
Vedecká novinka dizertačnej práce spočíva vo vývoji modelu architektúry AIS CP zameraného na komplexnú automatizáciu end-to-end podnikových procesov a návrhoch na jeho implementáciu prostredníctvom systémovej integrácie heterogénneho softvéru v distribuovanom heterogénnom sieťovom prostredí na báze objektov a komponentné technológie.
Vedecká novinka je obsiahnutá v nasledujúcich výsledkoch získaných v dizertačnej práci:
Stanovenie a klasifikácia požiadaviek na funkčnosť softvéru pre organizačné a ekonomické riadenie podnikov;
Model architektúry AIS UP, zameraný na komplexnú automatizáciu end-to-end podnikových procesov;
Princípy integrácie softvéru na riešenie problémov funkčné služby podniky so základným softvérom na riadenie obchodných procesov, výmenu údajov a tok dokumentov;
Návrhy na organizáciu jednotného informačného priestoru podniku, prístupného zamestnancom a partnerom podniku prostredníctvom podnikového webového portálu;
Návrhy na implementáciu jednotný systém generovanie a klasifikácia správ pomocou analytických nástrojov;
Princípy implementácie interakcie subsystémov AIS CP založených na objektovo orientovaných a komponentových technológiách a interakcii softvérových komponentov v distribuovanej sieti
prostredie v súlade s priemyselnými štandardmi a internetovými protokolmi;
Mechanizmus implementácie adaptívnych vlastností modelu softvérovej architektúry AIS CP v súlade s požiadavkami konkrétneho podniku, založený na schopnosti konfigurovať základné subsystémy na existujúce a navrhnuté pracovné procesy.
Praktický význam dizertačnej práce spočíva v tom, že realizácia navrhnutých návrhov umožňuje vytvárať automatizované systémy riadenia informácií, ktoré poskytujú efektívnu podporu informačné postupy riadenia činnosti podniku v kontexte ekonomickej globalizácie a formovania informačnej spoločnosti.
Model architektúry AIS CP navrhnutý v práci a odporúčania na jeho použitie majú dostatočnú flexibilitu a všestrannosť, čo zabezpečuje ich použiteľnosť pri výstavbe manažérskych informačných systémov pre podniky rôznych foriem vlastníctva, odvetvových špecifík a škál aktivít.
Nezávislý praktický význam mať:
Návrhy na výber a aplikáciu noriem, protokolov a iných mechanizmov používaných pri systémovej integrácii AIS UE;
Návrhy komplexnej automatizácie end-to-end obchodných procesov a toku dokumentov;
Návrhy na vytvorenie jednotného informačného priestoru pre podnik pomocou mechanizmu webových portálov;
Návrhy na prispôsobenie špirálovo-iteračného prístupu pri vývoji a implementácii softvéru AIS CP.
Praktický význam práce je hodnotený v konkrétnych projektoch pre implementáciu navrhovaného problémovo orientovaného modelu podnikového automatizačného systému:
Integrovaný systém riadenia podniku "Flagman" spoločnosti Infosoft,
Systémy riadenia vzťahov so zákazníkmi „eRelationship“ od spoločnosti Pivotal Software Corporation (Kanada),
Firemné systémy výkazníctva „Monarch ES“ od DataWatch (USA),
Projekt integrácie informačných systémov spoločností Sovintel a Tele Ross.
Školiace stredisko spoločnosti Vest-MetaTechnology používa materiály pripravené autorom na základe prístupu navrhnutého v priebehu tohto výskumu pri realizácii kurzov vývoja informačných systémov riadenia podniku (pozri http://www.vest.msk.ru ).
Výskumné materiály dizertačnej práce sa využívajú vo vedeckom výskume a praktické činnosti výkonné orgány Asociácia vývojárov softvéru v oblasti ekonomiky (AREP) a jej členovia.
Hlavné ustanovenia práce boli oznámené a prediskutované na adrese:
Konferencia "IBM riešenia v oblasti obchodnej integrácie pre telekomunikačné spoločnosti", zastúpenie IBM vo východnej Európe (Moskva, 18. jún 2002);
Sympózium „Call Center CRM Solutions 2002/Call Centers and Customer Relationship Management“ (Moskva, marec 2002);
Konferencia vývojárov informačných systémov na báze nástrojov od Centura Software Corp. (Berlín, Nemecko, 17. - 19. november 1999);
Konferencia „InfoCity: prax a problémy mestskej informatizácie“ (Moskva, október 1999);
Vedecké a praktické konferencie spoločnosti "Infosoft" (Moskva, 1995-1999);
Konferencia odborníkov v oblasti automatizovaných riadiacich systémov a počítačových informačných systémov " Podnikové systémy"(Moskva, apríl 1998 a 28. – 30. apríl 1997, organizátori: spoločnosť SoftService a zastúpenia spoločností Oracle, Informix, Sybase, Borland a Centura);
3. ročník konferencie „Corporate Databases 98“ (Moskva, 31. 3. – 3. 4. 1998 a 26. – 29. 3. 1996, organizovaný Centrom informačných technológií za účasti Open Systems Publishing House);
Konferencia "Tekhnikom-97" (Moskva, 24.-26. novembra 1997, organizátori: spoločnosť SoftService, Russian Oracle Users Association, zastúpenia Microsoft, Borland, Computer Associates, Lucent Software).
Problémy vývoja AIS
Zavádzanie informačných technológií do ekonomiky, prenikanie počítačových a komunikačných nástrojov do riadenia podniku na všetkých úrovniach a rastúci záujem o interakciu podnikov prostredníctvom internetu si vyžadujú koncepčné zmeny v prístupoch k budovaniu automatizovaných manažérskych informačných systémov. Ide nielen o čisto technologické problémy tvorby a prevádzky informačných systémov, ale aj o prístupy k riadeniu podniku v ekonomike informačnej spoločnosti.
AIS UP musí spĺňať požiadavky na automatizáciu a informácie v celej organizácii, čo pre vývojárov softvéru kladie tieto úlohy: vývoj platformy schopnej podporovať prácu veľkého počtu používateľov; podpora komunikačných nástrojov a priemyselných noriem na výmenu údajov a protokolov interakcie komponentov; integrácia existujúceho vývoja do jedného systému.
Integrácia heterogénnych aplikácií v rámci jedného automatizovaného informačného systému by mala poskytnúť podporu pre: end-to-end obchodné procesy; jednotné používateľské rozhranie (portál); spoločný informačný priestor.
Podstata nastolených problémov podľa nášho názoru nespočíva ani tak v technických aspektoch implementácie, ale v potrebe použiť zásadne nový model architektúry AIS CP.
Zhrňme si klady a zápory rôznych možností architektúry IS z pohľadu možností budovania integrovaného riešenia.
Centralizácia spracovania dát kladie vysoké nároky na servery. So zvyšujúcim sa počtom súbežných používateľov (čo je nevyhnutné pri automatizácii procesov v rámci podniku) sa záťaž pre používanú hardvérovú platformu a softvér stáva nadmernou. Pomocou rôznych hardvérových riešení (clustering, multiprocessing a iné formy kombinovania výpočtových zdrojov), ako aj distribuovaného spracovania pomocou transakčných monitorov, aplikačných serverov a výkonných priemyselných DBMS, je možné vytvárať skutočne škálovateľné riešenia odľahčujúce centrálne uzly nielen zvýšením výkonu hardvéru, ale aj vďaka vhodnej konštrukcii softvérových komponentov systému.
Aj keď je centrálny databázový server schopný poskytnúť požadovaný výkon, pri takejto konštrukcii IS nevyhnutne vznikajú problémy s udržaním jednotnej štruktúry spoločnej databázy, ak jednotlivé softvérové komponenty IS vyvíjajú rôzne spoločnosti alebo dokonca vývojové tímy v rámci rovnaká organizácia. Inštalácia spoločnej databázy s prístupom z programov na riešenie rôznych aplikovaných problémov nám umožňuje poskytnúť spoločný informačný priestor, vyššie uvedené technológie umožňujú prístup k databáze veľkému počtu používateľov, čo však neposkytuje záruku správna prevádzka so zdieľanými údajmi. Problém logickej integrity údajov zostáva. Pri používaní programov od rôznych výrobcov sa stáva nevyhnutné rozdeľovať údaje do podsystémov, prípadne ich denormalizáciou a vytváraním nadbytočných štruktúr. Architektúra so spoločnou základňou je schematicky znázornená na nasledujúcom obrázku (obrázok 1-14). Ako vyplýva z vyššie uvedeného diagramu, moduly neinteragujú, to znamená, že neexistuje žiadne volanie z jedného modulu do druhého v reálnom čase, neexistuje žiadna prevádzková podpora pre end-to-end proces. Dáta sa ukladajú do databázy, z ktorej sú dostupné ďalším modulom, ktoré musia obsahovať funkcie na sledovanie zmien v nej a relevantnosť údajov závisí od frekvencie kontroly aktualizácií. Príkladom end-to-end procesu by bolo vystavenie faktúry obchodným zástupcom. Ak na to používa CRM systém, vygenerovanú faktúru súbežne s výpisom je potrebné spracovať v module logistiky ERP systému na rezerváciu tovaru a hneď potom - finančný modul zvýšiť dlh kupujúceho. Na tento účel musia príslušné moduly skontrolovať prítomnosť nového účtu. Ak sa tak nestane včas, môže byť vystavená faktúra za skutočne rezervovanú položku.
Aby rôzne moduly pracovali so spoločnou databázovou štruktúrou, musia byť pôvodne navrhnuté s ohľadom na špecifickú dátovú štruktúru alebo musia používať konzistentný mechanizmus metadát (úložisko).
Pri použití inej architektúry, keď sú heterogénne databázy udržiavané na rôznych počítačoch (a prípadne v rôznych sieťach) a používajú ich autonómne moduly (obrázok 1-15), je zachovanie logickej integrity údajov ešte náročnejšie na prácu. úloha. V tomto prípade je potrebné regulovať a implementovať replikáciu dát (synchronizáciu), zjednotenie adresárov, pravidlá kódovania a klasifikácie a vyvinúť či implementovať samotný mechanizmus replikácie. To všetko si vyžaduje organizačné opatrenia na synchronizáciu databázy. Zostáva problém automatického pokračovania v procese (príklad s vystavením faktúry).
Platformy na implementáciu novej architektúry AIS UE
TO začiatok XXI storočia v IT priemysle boli na priemyselnej úrovni vyvinuté a zvládnuté nasledujúce riešenia, ktoré zaisťujú širokú implementáciu IT v ekonomických procesoch:
nástroj osobnej výpočtovej techniky, ktorý spočíva v tom, že pri mnohých druhoch práce sa vytratila potreba sprostredkovateľov medzi zadaním úlohy a jej vykonávateľom, to znamená, že zamestnanci funkčných služieb podniku sú schopní vykonávať informačné postupy v rámci svojich schopnosť používať počítače bez zapojenia alebo s minimálnou podporou sprievodného technického personálu;
prostriedky automatizovanej podpory koordinovanej spolupráce skupiny („tímu“) pracovníkov na jednom projekte, dokumente, úlohe a pod.;
mechanizmus elektronickej komunikácie, ktorý v mnohých prípadoch umožnil eliminovať potrebu prenosu papierové dokumenty minimalizovať potrebu stretnutí, čo je obzvlášť dôležité, keď sú účastníci konkrétneho obchodného procesu geograficky vzdialení.
Vďaka týmto riešeniam je možné zautomatizovať väčšinu pracovných procesov, ktoré sa vyskytujú v rámci podniku pri jeho finančných, ekonomických, výrobných a obchodných činnostiach, ako aj súvisiacich s podnikaním. vonkajšie funkcie. Kombinácia softvéru a hardvéru, ktorý automatizuje rôzne funkcie a úlohy, umožňuje prepojiť technologické (na základe vybavenia a technických zariadení) a pracovné procesy (za účasti zamestnancov všetkých oddelení podniku) do komplexných podnikových procesov. Existuje tak zásadná možnosť riešenia problému izolácie miest vzniku dát od centier ich ukladania a spracovania a oddelenia pracovísk od seba.
Riešenie problému integrácie modulov AIS a výber centralizovaného alebo decentralizovaného prístupu k organizácii ich interakcie je možné aj vďaka najnovšiemu vývoju popredných výrobcov systémového softvéru: operačné systémy, webové servery, aplikačné servery, DBMS a middleware platformy. Integrácia aplikácií je možná vďaka použitiu objektovo orientovanej vývojovej technológie a viacvrstvovej architektúry založenej na komponentoch. Kľúčovým princípom je tu koncepcia programových rozhraní a pravidlá ich zmeny a rozšírenia (jazyk IDL).
Pre prácu v distribuovanom heterogénnom prostredí, akým je internet, sa aktívne vyvíjajú špecifikácie webových služieb, z ktorých každá môže implementovať jednu alebo viacero obchodných procedúr alebo funkcií. OASIS, BPMI a IBM, Microsoft a BEA zverejnili jazyk vykonávania obchodných procesov pre webové služby (BPEL4WS), XLANG a WSFL (jazyk toku webových služieb) a koalíciu WfML - XPDL (jazyk definície procesov XML).
Trendom je spájať komponenty s otvorenými rozhraniami webových služieb do subsystémov, ktoré vykonávajú logicky kompletné cykly obchodných procesov. V tomto prípade môžu byť komponenty umiestnené na rôznych aplikačných serveroch distribuovaných po sieti a pracovať s jednou alebo viacerými databázami. Zmenou počtu a vzťahov medzi komponentmi, počtom a umiestnením sieťových serverov, schopnosťou nahrádzať komponenty alebo ich presúvať po sieti bez straty kompatibility je možné vybudovať automatizovaný informačný systém, ktorý zachováva rovnováhu medzi centralizáciou a decentralizáciou v riadenie podniku.
Neexistujú žiadne technické prekážky pre implementáciu takejto architektúry. Moderné priemyselné aplikačné servery (napríklad MTS/COM+/.Net, ONE alebo J2EE/EJB) vám umožňujú budovať viacvrstvové systémy, poskytujú spoločnú platformu pre prístup k rôznym webovým službám, zabezpečujú transakčnú integritu operácií, vyrovnávanie záťaže pri konkurenčný prístup desiatky tisíc používateľov v reálnom čase a tiež zaručujú odolnosť voči chybám a obnovu po zlyhaniach.
Dôležitým úspechom IT priemyslu sú štandardy, ktoré sa stali rozšírenými a uznávanými poprednými výrobcami softvéru: protokoly interakcie komponentov (COM/DCOM, CORBA, Java RMI) a formáty výmeny dát (EDI, XML, ).
Štandard EDI a jeho priemyselné varianty (EDIFACT, XI2, HIPAA atď.) sa vo finančnom a priemyselnom sektore Severnej Ameriky a Európy používajú od polovice 70. rokov a dnes dominujú na celom svete. S rastúcou popularitou XML na internete sa EDI prenieslo do XML.
Na základe XML (DTD a XDR) sú dáta vyvíjané, štruktúrované a formátované v rôznych ekonomických sfér vo forme takzvaných predmetových slovníkov alebo typov dokumentov, napríklad WIDL, OFX, FpML, IFX, XBRL, CRML a mnohé ďalšie na Západe, ako aj CommerceML.ru a XML Partnership/ARB v Rusku. Americká spoločnosť pre výrobu a riadenie zásob APICS, ktorá certifikuje systémy triedy ERP/MRP, zverejňuje špecifikácie ekonomické subjekty vo formáte XML, napríklad štruktúra a formát zákazníckych údajov alebo faktúry. Samodokumentačná povaha XML zaisťuje, že dátam môžu jasne rozumieť ľudia aj programy.
Architektúra AIS UP
Na vybudovanie modelu architektúry AIS UE budeme považovať podnik za súbor pracovných, finančných, materiálnych a informačných zdrojov zapojených do obchodných procesov na dosiahnutie obchodných cieľov podniku. Pod pojmom obchodné ciele sa tu rozumejú strategické dlhodobé ciele stanovené vlastníkmi a senior manažérmi, ako aj aktuálne ciele zadané vrcholovými a strednými manažérmi. Obchodný proces alebo obchodný proces je postupnosť činností zamestnancov, operácií na pracoviskách, ako aj funkcií vykonávaných softvérom a technické prostriedky v automatickom režime. Nazvime každú akciu alebo ich postupnosť etapou procesu. Operácie a postupy môžu byť tiež synonymami akcií. Ak si etapa vyžaduje činnosť zamestnanca (skupiny rolí, zástupcu alebo vedúceho oddelenia, ako aj osoby zastávajúcej pozíciu), nazýva sa to aj úloha a zamestnanec sa nazýva výkonný. Postupnosť akcií v obchodnom procese môže byť nejednoznačná, to znamená, že popis procesu vo forme orientovaného grafu môže zahŕňať vetvenie s podmienkami prechodu z jednej fázy do druhej. Typické reťazce fáz možno rozdeliť na podprocesy. Pohyb úloh cez špecifikované fázy procesu sa nazýva trasa. Ak proces nie je možné opísať z dôvodu ľubovoľných prechodov medzi fázami, o ktorých rozhoduje vykonávateľ počas vykonávania úlohy na súčasné štádium, potom sa tento prípad nazýva voľné smerovanie.
AIS CP by mal umožňovať formálne popísať obchodné procesy v grafickej podobe vo forme orientovaného grafu (digrafu), ktorého vrcholy sú etapami a hrany sú prechodmi medzi etapami. V konkrétnom prípade vyzerá graf obchodného procesu sieťový diagram, kde vrcholy označujú úlohy označujúce ich trvanie a orientované hrany (šípky) znázorňujú postupnosť úloh. V súlade s popisom procesu, ktorý sa nazýva procesná mapa, musí automatizovaný informačný systém pre riadenie riadiť zdroje (alebo presnejšie pomáhať manažérom podnikov riadiť ich), prideľovať úlohy a ich vykonávateľov a tiež volať (aktivovať) softvér a hardvér na spustenie automatizovaných postupov.
Parametre podnikového rozsahu ovplyvňujú organizáciu riadenia na konkrétny podnik, čo sa odráža v požiadavkách na AIS UE. Na druhej strane AIS UP ovplyvňuje rozsah podniku, napríklad podporuje rast podnikania. Zmena jedného z parametrov si vyžaduje aktualizáciu AIS, rovnako ako zavedenie AIS môže zmeniť organizáciu riadenia.
Účelom zamerania sa na obchodné procesy pri budovaní AIS CP je nájsť spoločnú platformu, na základe ktorej bude možné adekvátne modifikovať AIS bez potreby kompletnej reorganizácie systému. Táto platforma je modelovanie obchodných procesov softvér riadenie procesov.
Ako jadro AIS PM je potrebné vyvinúť systém, ktorý kombinuje viaceré funkcie diskutované pri revízii systémov riadenia procesov (odseky „1.1.7 Systémy riadenia dokumentov“ na strane 31 a „1.1.8 Systémy riadenia procesov“ na strana 34). Patria sem: Workflow - podsystém pre riadenie pracovníkov a technologických procesov poskytujúce vopred definované a bezplatné smerovanie úloh medzi vykonávateľmi; Docflow - subsystém na riadenie toku dokumentov a smerovanie dokumentov so sledovaním ich stavu; Groupware - subsystém na podporu funkcií rýchleho prideľovania úloh a voľného smerovania (ad hoc) úloh medzi členmi skupiny interpretov; Dataflow - smerovanie dát, dátových paketov, správ medzi aplikáciami.
Na rozdiel od akceptovanej praxe autonómneho používania systémov tohto druhu tu predpokladáme prítomnosť všeobecná mapa proces, všeobecný modul na spracovanie fáz procesu, všeobecný mechanizmus na prideľovanie vykonávateľov a smerovanie úloh a údajov.
Takto vznikajú technologické údaje technické zariadenia, faktické údaje zadávané do IS používateľmi na ich pracoviskách (vrátane primárnych dokumentov), ako aj údaje generované softvérovými aplikáciami, budú vložené do AIS UP a dostupné spotrebiteľom informácií v reálnom čase.
Schematicky je životný cyklus spracovania údajov v AIS UE znázornený na nasledujúcom obrázku (obrázok 2-2). Dáta zadané ručne alebo prijaté zo softvérových komponentov sú naformátované ako dokument, ktorý je ďalej spracovávaný modulom toku dokumentov v súlade s mapou procesov. Na trase spracovania (ak si to konfigurácia systému vyžaduje) subsystém správy dokumentov volá moduly funkčných subsystémov na spracovanie finančných, obchodných a iných typov transakcií. V dôsledku toho sú poverenia uložené v štruktúrovaných databázach. Samotné dokumenty sú zase uložené v úložisku alebo v neštruktúrovanej databáze. Všetky tieto databázy musia byť prístupné pre analytické moduly subsystému podávania správ, aby mohli vytvárať potrebné správy.
Skúsenosti s praktickou implementáciou modelu AIS UE
V rokoch 1995 až 1999 bol pod vedením autora dizertačnej práce vyvinutý integrovaný automatizačný systém pre riadenie podniku „Flagman“ spoločnosti Infosoft, ktorý tento moment realizované vo viac ako stovke veľkých a stredných priemyselných, stavebných, obchodných, poľnohospodárskych podnikov a rozpočtové organizácie Rusko a krajiny SNŠ. Systém sa naďalej vyvíja na základe jadra vyvinutého autorom a do roku 2002 „vlajková loď“ zahŕňa viac ako desať hlavných podsystémov, ktoré sú znázornené na nasledujúcom obrázku (obrázok 3-2):
Základom systému „Flagman“ je základný modul „Document Flow“, ktorý je zodpovedný za zadávanie, spracovanie, smerovanie a tlač všetkých primárnych dokumentov. Ďalšími základnými modulmi sú Administrácia a Nástroje, ktoré sú spoločné pre všetky funkčné moduly. Umožňujú vám konfigurovať skupiny rolí a prístupové práva, pracovné stanice až po položky ponuky, rozloženia dokumentov a šablóny správ.
Výhodou implementovaného modelu bolo jednoduché zadávanie primárnych dokumentov, generovanie účtov vo funkčných podsystémoch na základe týchto dokumentov zjednotenie práce s primárnymi dokumentmi.
Rýchly rozvoj subsystémov a nedostatočná štandardizácia ich interakcie viedli k tomu, že integrácia prebiehala okolo centrálnej databázy a všeobecné tabuľky. Ak neberieme do úvahy dvojvrstvovú architektúru, ktorej výber bol determinovaný úrovňou vývoja vývojových nástrojov v roku 1995, potom sa hlavným problémom vývoja systému stala krížová závislosť modulov. Jeho prvé implementácie odhalili nedostatočnosť funkcií automatizácie pracovného toku dokumentov samotným smerovaním dokumentov a vyvolali otázku potreby implementácie modulu riadenia procesov (workflow).
Ak sa pozrieme na implementáciu podrobnejšie, modul správy dokumentov je knižnica objektov, ktorá je zahrnutá vo všetkých podsystémoch a je zostavená aj ako samostatný modul. Knižnica obsahuje nástroje na nastavenie typov a variantov dokumentov, skladbu polí, vstupné a editačné formuláre, zoznam stavov, možné kombinácie prechodov zo stavu do stavu, zoznam operácií naviazaných na funkčné moduly, šablóny a tlačové formuláre. , ako aj pravidlá tvorby registrov a denníkov dokumentov .
Operácie s dokumentmi menia svoj stav a tiež volajú funkcie aplikačných subsystémov. Zoznam funkcií je zahrnutý v každom podsystéme a je preň špecifický. Pre sprievodných programátorov, ktorí sa podieľajú na nastavovaní systému, sú k dispozícii parametre funkcií a možnosť naviazať na ne polia dokumentu pomocou vzorcov. To vám umožňuje automatizovať väčšinu finančných transakcií, ako aj logistických funkcií, personálne záznamy a výpočty miezd, avšak pre úplnú implementáciu zostáva potreba skriptovacieho jazyka (script).
Systém má zabudovaný generátor správ, spoločný pre všetky podsystémy. Keďže systém je založený na princípe integrácie okolo centrálnej databázy, generátor má prístup ku všetkým údajom bez ohľadu na členstvo v module. Zostavy sú zaradené do hierarchickej štruktúry, každé usporiadanie zostavy obsahuje šablónu na náhľad a tlač a SQL dotazy na generovanie výsledného súboru údajov. Vygenerované zostavy je možné ďalej spracovávať ako dokumenty.
Treba tiež poznamenať, že systém Flagman implementuje jednotný vzhľad subsystémy Spoločný modul pre správu prvkov používateľského rozhrania a funkcií AWS vrátane ponúk a panelov nástrojov umožňuje jednotne prispôsobiť vzhľad.
V súčasnosti si vývoj IT vyžaduje aktualizáciu systémovej platformy Flagman. V prvom rade je potrebné preniesť ho na trojvrstvovú architektúru a rozvinúť modul toku dokumentov do plne funkčného systému riadenia procesov. Je tiež potrebné vyvinúť mechanizmy na integráciu externých aplikácií, keďže systém má len nástroje na import a export dát.
Avšak, početné príklady úspešnej implementácie a priemyselná prevádzka systém "Flagman", naznačuje nárast počtu jeho predaja v rokoch 2001-2002 ekonomická efektívnosť riešenia pre automatizáciu podnikov rôznych odborochčinnosti, odvetvia a rozsah.
Vo februári 1999 bol systém „Flagman“ spoločnosti Infosoft, vytvorený pod vedením autora, uznaný ako najlepší Ruský vývoj na nástrojoch Centura Team Developer od spoločnosti Centura Software Corp. (USA) a spoločnosťou Interface (Rusko). V rokoch 1999, 2000 a 2001 CIS "Flagman" bol certifikovaný ako podnikový informačný systém odborníkmi z poroty súťaže "Business-Soft" organizovanej Asociáciou softvérových vývojárov v oblasti ekonomiky (AREP), CIES "Business Programs-Service", časopis "Účtovníctvo" a "Finančné noviny" "
Kaskádový prístup sa dobre osvedčil pri konštrukcii informačných systémov, na ktoré je už na začiatku vývoja možné celkom presne a úplne formulovať všetky požiadavky tak, aby vývojári mali voľnosť pri ich technickej implementácii čo najlepšie. Do tejto kategórie patria komplexné systémy s veľkým počtom výpočtových úloh, systémy v reálnom čase atď.
Model životného cyklu AIS je štruktúra, ktorá popisuje procesy, činnosti a úlohy, ktoré sa vykonávajú počas vývoja, prevádzky a údržby počas celého životného cyklu systému.
Výber modelu životného cyklu závisí od špecifík, rozsahu, zložitosti projektu a súboru podmienok, v ktorých AIS vzniká a funguje.
Model životného cyklu AIS zahŕňa:
Výsledky práce v každej fáze;
Kľúčové udalosti alebo body ukončenia práce a rozhodovania.
V súlade so známymi modelmi životného cyklu softvér určuje modely životného cyklu AIS - kaskádové, iteračné, špirálové.
I. Kaskádový model opisuje klasický prístup k vývoju systémov v akejkoľvek tematickej oblasti; široko používaný v 70. a 80. rokoch.
Kaskádový model zabezpečuje sekvenčnú organizáciu práce a hlavnou črtou modelu je rozdelenie všetkých prác na etapy. Prechod z predchádzajúcej fázy do ďalšej nastáva až po úplnom dokončení všetkých prác predchádzajúcej.
Zlatý klinec päť etapy trvalo udržateľného rozvoja, prakticky nezávislé od predmetnej oblasti
Zapnuté najprv V tejto fáze sa vykoná štúdia problémovej oblasti a formulujú sa požiadavky zákazníka. Výsledok tejto fáze je technická špecifikácia (vývojová úloha) dohodnutá so všetkými zainteresovanými stranami.
Počas druhý etape sa podľa požiadaviek technických špecifikácií vyvinú určité konštrukčné riešenia. V dôsledku toho sa objaví súbor projektovej dokumentácie.
Po tretie etapa - realizácia projektu; V podstate vývoj softvéru (kódovanie) v súlade s rozhodnutiami o dizajne v predchádzajúcej fáze. Spôsoby implementácie nemajú v tomto prípade zásadný význam. Výsledkom tejto etapy je hotový softvérový produkt.
Zapnuté štvrtý V tejto fáze sa kontroluje, či výsledný softvér spĺňa požiadavky uvedené v technických špecifikáciách. Skúšobná prevádzka umožňuje identifikovať rôzne druhy skrytých nedostatkov, ktoré sa objavujú v reálnych prevádzkových podmienkach AIS.
Poslednou fázou je doručenie hotový projekt, a tu ide hlavne o to presvedčiť zákazníka, že všetky jeho požiadavky sú plne splnené.
Obr. 1.1 Kaskádový model životného cyklu AIS
Fázy práce v rámci modelu vodopádu sa často nazývajú časti projektový cyklus AIS, keďže fázy pozostávajú z mnohých opakovaných postupov na objasnenie systémových požiadaviek a možností návrhu. Životný cyklus AIS je podstatne zložitejší a dlhší: môže zahŕňať ľubovoľný počet cyklov objasňovania, zmien a doplnkov už prijatých a implementovaných konštrukčných riešení. V týchto cykloch sa vyvíja AIS a modernizujú sa jeho jednotlivé komponenty.
Výhody kaskádového modelu:
1) v každej fáze sa vygeneruje kompletný súbor projektovej dokumentácie, ktorá spĺňa kritériá úplnosti a konzistentnosti. V záverečných fázach sa vytvára užívateľská dokumentácia, ktorá pokrýva všetky typy podpory AIS poskytované štandardmi (organizačná, informačná, softvérová, technická atď.);
2) postupná implementácia pracovných etáp umožňuje plánovať termíny dokončenia a zodpovedajúce náklady.
Kaskádový model bol pôvodne vyvinutý na riešenie rôznych druhov inžinierskych problémov a dodnes nestratil svoj význam pre aplikovanú oblasť. Okrem toho je vodopádový prístup ideálny pre vývoj AIS, pretože na samom začiatku vývoja je možné celkom presne a úplne formulovať všetky požiadavky, aby vývojári mali voľnosť pri technickej implementácii. Takéto AIS najmä zahŕňajú komplexné výpočtové systémy a systémy v reálnom čase.
Nevýhody kaskádového modelu:
Výrazné oneskorenie pri získavaní výsledkov;
Chyby a nedostatky v ktorejkoľvek fáze sa spravidla objavujú v nasledujúcich fázach práce, čo vedie k potrebe vrátenia;
Náročnosť paralelnej práce na projekte;
Nadmerné presýtenie informácií v každej fáze;
Zložitosť projektového manažmentu;
Vysoký stupeň riziko a nespoľahlivosť investícií.
Oneskorené prijímanie výsledkov sa prejavuje v tom, že dôsledný prístup k výsledkom rozvoja sa so zainteresovanými stranami dohodne až po ukončení ďalšej etapy prác. V dôsledku toho sa môže ukázať, že vyvíjaný AIS nespĺňa požiadavky a takéto nezrovnalosti môžu vzniknúť v ktorejkoľvek fáze vývoja; Okrem toho môžu dizajnéri-analytici aj programátori neúmyselne zaviesť chyby, pretože sa od nich nevyžaduje, aby dobre rozumeli oblastiam, pre ktoré sa AIS vyvíja.
Vráťte sa do predchádzajúcich fáz. Táto nevýhoda je prejavom predchádzajúcej: postupná práca na projekte môže viesť k tomu, že chyby urobené v skorších fázach sa zistia až v nasledujúcich fázach. Výsledkom je, že projekt sa vráti do predchádzajúcej fázy, prepracuje sa a až potom sa prenesie do ďalšej práce. To môže spôsobiť narušenie harmonogramu a skomplikovať vzťahy medzi vývojovými tímami vykonávajúcimi jednotlivé etapy.
Najhoršou možnosťou je, keď sa nedostatky predchádzajúcej fázy neodhalia v ďalšej fáze, ale neskôr. Napríklad v štádiu skúšobnej prevádzky sa môžu objaviť chyby v popise predmetnej oblasti. To znamená, že časť projektu sa musí vrátiť do počiatočnej fázy prác.
Ťažkosti pri paralelnej práci je spojená s potrebou koordinovať rôzne časti projektu.Čím silnejšie je prepojenie jednotlivých častí projektu, tým častejšie a starostlivejšie sa musí vykonávať synchronizácia, tým sú vývojové tímy na sebe závislejšie. V dôsledku toho sa jednoducho stratia výhody paralelnej práce; Nedostatok paralelizmu negatívne ovplyvňuje aj organizáciu práce celého tímu.
Problém informačná presýtenosť vzniká v dôsledku silných závislostí medzi rôznymi vývojovými skupinami. Faktom je, že keď dôjde k zmenám v jednej z častí projektu, je potrebné upozorniť tých vývojárov, ktorí ju použili (mohli použiť) vo svojej práci. Ak existuje veľké množstvo vzájomne prepojených subsystémov, synchronizácia internej dokumentácie sa oddelí najdôležitejšia úloha: Vývojári si musia neustále uvedomovať zmeny a vyhodnocovať, ako tieto zmeny ovplyvnia ich výsledky.
Zložitosť projektového manažmentu je to spôsobené najmä prísnou postupnosťou fáz vývoja a prítomnosťou zložitých vzťahov medzi rôznymi časťami projektu. Regulovaná postupnosť prác vedie k tomu, že niektoré vývojové skupiny musia čakať na výsledky práce iných tímov, preto je potrebný administratívny zásah na dohodnutie načasovania a zloženia prenášanej dokumentácie.
Ak sa v práci zistia chyby, je potrebné vrátiť sa k predchádzajúcim etapám; aktuálna práca tí, ktorí sa pomýlia, sú prerušení. Dôsledkom toho sú zvyčajne nedodržané termíny pre opravené aj nové projekty.
Zjednodušiť interakciu medzi vývojármi a znížiť informačnú presýtenosť dokumentácie je možné znížením počtu prepojení medzi jednotlivými časťami projektu, nie každý AIS je však možné rozdeliť na voľne nadväzujúce podsystémy.
Vysoká miera rizika. Ako komplexnejší projekt, čím dlhšie trvá každá etapa vývoja a tým zložitejšie sú vzťahy medzi jednotlivými časťami projektu, ktorých počet tiež narastá. Navyše, výsledky vývoja je možné reálne vidieť a posúdiť až vo fáze testovania, t. j. po dokončení analýzy, návrhu a vývoja – fázy, ktorej realizácia si vyžaduje značný čas a peniaze.
Neskoré hodnotenie spôsobuje vážne problémy pri identifikácii chýb analýzy a návrhu – je potrebný návrat k predchádzajúcim fázam a opakovanie procesu vývoja. Návrat k predchádzajúcim etapám však môže byť spojený nielen s chybami, ale aj so zmenami, ktoré nastali v predmetnej oblasti alebo v požiadavkách zákazníkov počas vývoja. Zároveň nikto nezaručuje, že sa predmetná oblasť do prípravy ďalšej verzie projektu opäť nezmení. V skutočnosti to znamená, že existuje možnosť „cyklovania“ procesu vývoja: náklady na projekt sa budú neustále zvyšovať a termín dodania hotového produktu sa bude neustále oneskorovať.
II. Iteračný model (Krokový model so stredným ovládaním) pozostáva zo série krátkych cyklov (krokov) plánovania, implementácie, štúdie, akcie.
Tvorba komplexných automatizovaných informačných systémov zahŕňa schvaľovanie návrhových riešení získaných pri realizácii jednotlivých úloh. Prístup k návrhu „zdola nahor“ si vyžaduje také iterácie návratnosti, keď sa dizajnové riešenia pre jednotlivé úlohy spájajú do všeobecných systémových. Zároveň je potrebné revidovať predtým vytvorené požiadavky.
Výhoda Iteračný model spočíva v tom, že medzistupňové úpravy poskytujú menšiu pracovnú náročnosť vývoja v porovnaní s kaskádovým modelom.
Nedostatky iteračný model:
· životnosť každej etapy sa rozprestiera počas celého obdobia práce;
· v dôsledku veľkého počtu opakovaní vznikajú nezrovnalosti pri realizácii návrhových rozhodnutí a dokumentácie;
· zložitosť architektúry;
· ťažkosti s používaním projektovej dokumentácie v etapách implementácie a prevádzky si vyžadujú redizajn celého systému.
III. Špirálový model, na rozdiel od kaskádového, ale podobne ako v predchádzajúcom, predpokladá iteračný proces vývoja AIS. Zároveň narastá dôležitosť počiatočných fáz, akými sú analýza a návrh, v ktorých sa overuje realizovateľnosť technických riešení a zdôvodňuje sa vytváraním prototypov.
Každá iterácia predstavuje úplný vývojový cyklus, ktorého výsledkom je uvoľnenie internej alebo externej verzie produktu (alebo podmnožiny konečného produktu), ktorá sa od iterácie po iteráciu zlepšuje, aby sa stala kompletným systémom (obrázok 1.2).
Ryža. 1.2. Špirálový model životného cyklu AIS
Každé otočenie špirály teda zodpovedá vytvoreniu fragmentu alebo verzie softvérového produktu, vyjasnia sa ciele a charakteristiky projektu, určí sa jeho kvalita a naplánujú sa práce na ďalšie otočenie špirály. Každá iterácia slúži na prehĺbenie a dôsledné upresnenie detailov projektu, v dôsledku čoho sa vyberie rozumná možnosť pre konečnú realizáciu.
Použitie špirálového modelu vám umožňuje prejsť do ďalšej fázy projektu bez čakania na úplné dokončenie aktuálnej - nedokončenú prácu je možné dokončiť pri ďalšej iterácii. hlavnou úlohou každá iterácia - vytvoriť funkčný produkt, ktorý sa čo najrýchlejšie predvedie používateľom. Proces upresňovania a dopĺňania projektu sa tak výrazne zjednoduší.
Špirálový prístup k vývoju softvéru prekonáva väčšinu nevýhod vodopádového modelu a poskytuje aj množstvo ďalších funkcií, vďaka ktorým je proces vývoja flexibilnejší.
Výhody iteratívny prístup:
Iteračný vývoj výrazne zjednodušuje vykonávanie zmien v projekte pri zmene požiadaviek zákazníka;
Pri použití špirálového modelu sa jednotlivé prvky AIS postupne integrujú do jedného celku. Keďže integrácia začína s menším počtom prvkov, počas integrácie je oveľa menej problémov;
Zníženie úrovne rizík (dôsledok predchádzajúcej výhody, keďže riziká sa objavujú práve pri integrácii). Miera rizika je maximálna na začiatku vývoja projektu a s postupujúcim vývojom klesá;
Iteračný vývoj poskytuje väčšiu flexibilitu pri riadení projektov, čo umožňuje vykonávať taktické zmeny vo vyvíjanom produkte. Môžete teda skrátiť čas vývoja znížením funkčnosti systému alebo použiť produkty tretích strán ako komponenty namiesto vlastného vývoja (relevantné, keď trhové hospodárstvo keď je potrebné brániť sa propagácii produktov konkurencie);
Iteračný prístup uľahčuje opätovné použitie komponentov, pretože je oveľa jednoduchšie identifikovať spoločné časti projektu, keď sú už čiastočne vyvinuté, než sa ich snažiť izolovať na samom začiatku projektu. Analýza návrhu po niekoľkých počiatočných iteráciách odhalí bežné, opakovane použiteľné komponenty, ktoré budú vylepšené v nasledujúcich iteráciách;
Špirálový model umožňuje spoľahlivejší a stabilnejší systém. Je to preto, že ako sa systém vyvíja, chyby a slabé stránky sa zisťujú a opravujú pri každej iterácii. Súčasne sa upravujú kritické parametre účinnosti, ktoré sú v prípade kaskádového modelu dostupné len pred implementáciou systému;
Iteračný prístup umožňuje zlepšovanie procesov
vývoj - ako výsledok analýzy na konci každej iterácie sa hodnotia zmeny v organizácii vývoja; v ďalšej iterácii sa to zlepšuje.
Hlavný problém špirálového cyklu- ťažkosti s určením okamihu prechodu do ďalšej fázy. Na jeho vyriešenie je potrebné zaviesť časové obmedzenia pre každú fázu životného cyklu. V opačnom prípade sa vývojový proces môže zmeniť na nekonečné zlepšovanie toho, čo už bolo urobené.
Zapojenie používateľov do procesu navrhovania a kopírovania aplikácie vám umožňuje dostávať pripomienky a dodatky k požiadavkám priamo počas procesu návrhu aplikácie, čím sa skracuje čas vývoja. Zástupcovia zákazníkov majú možnosť kontrolovať proces tvorby systému a ovplyvňovať jeho funkčný obsah. Výsledkom je uvedenie systému do prevádzky, ktorý zohľadňuje väčšinu potrieb zákazníkov.
Model životného cyklu a konštrukčná technológia
Predtým sme povedali, že dizajnová technológia určuje postupnosť akcií potrebných na získanie IP projektu. Je zrejmé, že realizácia každej z týchto akcií znamená prechod informačného systému z jedného štátu do druhého. Každá dizajnová technológia teda jednoznačne opisuje určitý model životného cyklu. Na druhej strane vybudovaním modelu životného cyklu informačného systému, teda definovaním:
· úlohy, skladba a postupnosť vykonávaných prác;
· výsledky získané z každej vykonanej akcie;
· metódy a prostriedky potrebné na výkon práce;
· úlohy a zodpovednosti účastníkov;
· ďalšie informácie potrebné na plánovanie, organizovanie a riadenie kolektívneho rozvoja IP,
dostaneme jednoznačný popis nami zvolenej konštrukčnej technológie. Model životného cyklu je teda neoddeliteľnou a najdôležitejšou súčasťou technológie návrhu informačných systémov.
Etapy a etapy návrhu
Pojmy „fáza“ a „fáza“ dizajnu sú často zamieňané. Niekedy hovoria o etapy alebo fázyživotný cyklus, kroky dizajn. Vynára sa otázka: aký je správny spôsob?
Treba pripomenúť, že v inom medzinárodné normy Použitá terminológia sa môže líšiť. Vždy, keď to bude možné, sa zameriame na terminológiu domácich GOST. Fáza návrhu budeme nazývať časť procesu tvorby IP, ohraničenú určitým časovým rámcom a končiacu vydaním konkrétneho produktu (model, dokumentácia, text programu a pod.). Na základe spoločných cieľov je možné kombinovať fázy návrhu etapy. Napríklad fáza „Technický návrh“, fáza „Implementácia“ atď.
Podľa zverejnených údajov si každá etapa vývoja AIS vyžaduje určitý čas. Väčšinou (45-50%) času sa strávi kódovaním, komplexným a offline testovaním. Vývoj AIS zaberá v priemere jednu tretinu celého životného cyklu systému.
Ryža. Rozloženie času pri vývoji AIS
Etapy vytvárania AIS (ISO/IEC 15288)
Norma ISO/IEC 12207 definuje štruktúru životného cyklu obsahujúcu procesy, činnosti a úlohy, ktoré je potrebné vykonať pri tvorbe informačného systému.
