Sissejuhatus……………………………………………………………………………………..3
1. Infosüsteemide arendamise teoreetilised alused
1.1. Kontseptsioon on automatiseerimise vahend ………………………… .5
1.2. IS teabetugi…………………………………………… 7
1.3. Venemaa ravimite registreerimissüsteemide infosüsteemide turg………………………….12
2. Ravimite registreerimise infosüsteemi projekteerimine ja arendamine farmaatsiaorganisatsioonis
2.1. Transpordiettevõtte raamatupidamisandmebaasi infoloogiline struktuur……………………………………………………………………………………………16
Sissejuhatus
Kursusetöö asjakohasus seisneb selles, et kõik kaasaegsed laoettevõtted nõuavad automatiseeritud infosüsteeme (IS). Automatiseerimise peamiseks eeliseks on salvestatud andmete liiasuse vähendamine ja seega ka kasutatava mälumahu kokkuhoid, mitme toimingu maksumuse vähendamine üleliigsete koopiate värskendamiseks ja ebakõlade välistamine sama objekti kohta teabe erinevatesse kohtadesse salvestamise tõttu. , teabe usaldusväärsuse suurendamine ja teabe töötlemise kiiruse suurendamine; sisemiste vahedokumentide liigne hulk, erinevad ajakirjad, kaustad, rakendused jms, sama info korduv sisestamine erinevatesse vahedokumentidesse. Samuti vähendab oluliselt aega automaatne teabeotsing, mis viiakse läbi spetsiaalsetelt ekraanivormidelt, millel on näidatud objekti otsingu parameetrid.
Uuringu objektiks on transpordiettevõte (kaubavedu).
Õppeaineks on raamatupidamise automatiseerimine transpordiettevõttes.
Töö eesmärgiks on transpordiettevõtte sõidukipargi arvestuse infosüsteemi väljatöötamine.
Töös seatud eesmärgi saavutamiseks on vaja lahendada järgmised ülesanded:
1. Uurida infosüsteemide arendamise teoreetilisi aluseid
2. Kavandada ja arendada transpordiettevõtte raamatupidamisarvestuse infosüsteem.
Kursusetöö teoreetiliseks aluseks olid kodumaiste teadlaste tööd automatiseeritud infotehnoloogiate valdkonnas, perioodika materjalid ja globaalse Interneti teabeallikad.
Töö metodoloogiliseks aluseks on süsteemianalüüsi meetodid: programm-, dialektilised ja leksikaalsed meetodid
Kursusetöö eesmärgid ja eesmärgid määrasid selle struktuuri. Kursusetöö koosneb sissejuhatusest, kahest osast, järeldusest ja kirjanduse loetelust1. Infosüsteemide teoreetilised alused
1.1. IS-i kontseptsioon kui automatiseerimisvahend
Süsteemi all mõistetakse mis tahes objekti, mida vaadeldakse samaaegselt nii ühtse tervikuna kui ka heterogeensete elementide kogumina, mis on ühendatud seatud eesmärkide saavutamise huvides. Süsteemid erinevad üksteisest oluliselt nii koostiselt kui ka põhieesmärkidelt.Arvutiteaduses on “süsteemi” mõiste laialt levinud ja sellel on palju semantilisi tähendusi. Kõige sagedamini kasutatakse seda tehniliste tööriistade ja programmide komplekti puhul. Arvuti riistvara võib nimetada süsteemiks. Süsteemiks võib pidada ka konkreetsete rakendusprobleemide lahendamiseks mõeldud programmide kogumit, mida täiendavad dokumentatsiooni pidamise ja arvutuste haldamise protseduurid.Süsteemi mõistele sõna “informatsioon” lisamine peegeldab selle loomise ja toimimise eesmärki. Infosüsteemid võimaldavad koguda, salvestada, töödelda, hankida ja väljastada mis tahes valdkonna probleemide otsustusprotsessis vajalikku teavet. Need aitavad probleeme analüüsida ja uusi tooteid luua.
Infosüsteem on omavahel seotud vahendite, meetodite ja personali kogum, mida kasutatakse teabe salvestamiseks, töötlemiseks ja väljastamiseks etteantud eesmärgi saavutamiseks.
Kaasaegne arusaam infosüsteemist hõlmab arvuti kasutamist teabe töötlemise peamise tehnilise vahendina. Lisaks ei tee infosüsteemi tehniline teostus iseenesest midagi...
Tänapäeval on infotööstusest saanud uus tehnoloogiaharu, mis toob kasutajatele suurt kasu. Seetõttu peavad kaasaegsetes tingimustes organisatsiooni juhil olema teadmised IP loomise metoodilistest alustest. Infosüsteemide loomise ja kasutamise metoodiliste põhimõtete tundmine on tihedalt seotud juhtimisprotsesside arendamise ja täiustamisega.
Küberneetika (süsteemide ja juhtimismeetodite teadus) rajaja on Norbert Wiener (USA). Tema järgijate teosed said automaatjuhtimise teooria aluseks. See on teadus keerukates juhtimissüsteemides teabe vastuvõtmise, salvestamise, edastamise ja teisendamise üldistest seadustest. Arvutitehnoloogia kasutamine juhtimisprobleemide lahendamisel viis infoteooria, kodeerimise teooria väljatöötamiseni ja iseseisva arvutiteaduse teadusvaldkonna kujunemiseni. Nende uuringute tulemused olid aluseks riist- ja tarkvara kasutamise metoodika väljatöötamisele erinevate praktiliste eesmärkidega probleemide lahendamiseks.
Majandusobjekte hakati nägema keerukate süsteemidena ning nende haldamist samastus infoprotsessiga. Arvutitehnoloogia võimaluste ja rakendusalade intensiivne arendamine on viinud inimese-masina infosüsteemide loomiseni majandusobjektides. IS eesmärk ei olnud mitte ainult tootmis- ja majandusprotsesside infotugi, organisatsioonisiseste funktsionaalsete juhtimisprobleemide lahendamine, vaid ka infosuhtlus erinevate omavahel seotud organisatsioonide vahel tootmis-, majandus- ja infoaspektides.
Ühtsete metoodiliste lähenemiste rajaja IS-i disainis oli akadeemik V.M. Glushkov, kes sõnastas teaduslikud ja metoodilised sätted ning praktilised soovitused automatiseeritud infosüsteemi loomiseks. Ühtsete metoodiliste lähenemisviiside peamised põhimõtted on järgmised:
1. Järjepidevuse põhimõte, mis on IP loomisel, toimimisel ja arendamisel kõige olulisem. Uuritavat majandusobjekti käsitleb ta ühtse tervikuna. Samal ajal kehtestab see organisatsiooni tootmis- ja majandustegevuse suunad ning konkreetsed funktsioonid, mida see rakendab; tuvastab erinevat tüüpi ühendusi oma struktuurielementide vahel, tagades süsteemi terviklikkuse. Süstemaatilisuse põhimõte hõlmab organisatsioonis kahe aspekti analüüsi läbiviimist, nimelt makro- ja mikroanalüüsi. Makroanalüüsis vaadeldakse süsteemi ja (või) selle "elemente kõrgema järgu süsteemi osana. Erilist tähelepanu pööratakse infoseostele: määratakse nende liikumissuunad, need seosed, mis on määratud toimimise ja uurimise eesmärgiga. identifitseeritakse ja analüüsitakse objekte ning seejärel valitakse eelistatuimad, võttes arvesse IS-i kujundamise protsessis. Makroanalüüsis uuritakse organisatsiooni tegevuse kõiki aspekte, analüüsitakse selle struktuurikomponente (sh tegevusi igal töökohal) pidades silmas nende funktsionaalseid omadusi, mis avalduvad seostes teiste elementidega ja väliskeskkonnaga.
Majandusüksuse juhtimise organisatsioonilise struktuuri IS-i kavandamisel on kõige tüüpilisem mitmetasandiline hierarhiline struktuur. Süsteemi iga taseme hierarhiline struktuur võimaldab erinevaid lokaalseid optimaalsuskriteeriume kombineerida globaalse optimaalsuse kriteeriumiga süsteemi kui terviku toimimiseks; tagab juhtimissüsteemi suhtelise paindlikkuse ja võime kohaneda muutuvate tingimustega; suurendab usaldusväärsust tänu võimalusele juurutada elementaarne liiasus ja korrastada infovoogude suundi. Hierarhiliste struktuuride eelised aitasid kaasa nende laialdasele kasutamisele juhtimissüsteemides ning määrasid organisatsioonilise ja funktsionaalse lähenemise infosüsteemide loomisele. Selle protsessi käigus saadud kogemused mõjutasid kaasaegset protsessikäsitlust IS-i projekteerimisel.
Süsteemiprintsiibi rakendamise praktiline tähtsus seisneb selles, et see võimaldab analüüsiks ligipääsetaval kujul mitte ainult tuvastada süsteemi loojate huve, vaid kasutada arvutimodelleerimist, et uurida kavandatava süsteemi käitumist konkreetsetes tingimustes. määratud katsetaja. Seetõttu lähtutakse IS-i loomisel modelleerimismeetodist, mis võimaldab leida kõige vastuvõetavamad ja põhjendatumad projektlahendused, võimalused süsteemi konstrueerimiseks ning seeläbi tagada majandusobjekti toimimise suurim efektiivsus.
2. Arengu põhimõte, milleks on, et IS luuakse arvestades võimalust pidevalt täiendada ja ajakohastada süsteemi funktsioone ja selle toe liike. Selle olemus seisneb selles, et arenevad tootmis- ja juhtimisprotsessid muutuvad keerukamaks ning majandusobjektide organisatsioonilised struktuurid ehitatakse ümber – see eeldab infosüsteemide arvutusvõimsuse suurendamist, nende varustamist uute tehniliste ja tarkvaraliste vahenditega, et pidevalt täiendada ja ajakohastada tööülesandeid. lahendatud, teabefondi laiendamine, loodud kujul andmebaasid ja andmelaod, teadmistebaasid.
3. Infoprintsiip, mis on suunatud info ja juhtimisprotsessidega kaasnevate infoprotsesside üksikasjalikule ja terviklikule uurimisele majandusüksuses. Informatsiooni uuritakse semantilisest (sisu), süntaktilisest (märk) ja pragmaatilisest (kasulik) aspektist. Lisaks on teabe uurimine vajalik automatiseeritud tööjaamade, andmete edastamise, säilitamise ja töötlemise ning teabe kaitsmise süsteemide projekteerimiseks, kus peamised on teadmised teabe mahust, sisust ja kasulikkusest.
Praegu põhineb infokäsitlusel objektorienteeritud meetod infoprotsesside modelleerimiseks ja projekteerimistööde automatiseerimiseks juhtimisprotsesside analüüsimiseks ja elektrooniliste infovoogude kujundamiseks.
4. Ühilduvuse põhimõte, mis seisneb erinevat tüüpi, eesmärgi, taseme infosüsteemide koostoime tagamises majandusobjekti toimimisprotsessis. Seetõttu tuleb projekteerimisprotsessis tagada kõigi kasutatavate infosüsteemide info-, tehnilise ja tarkvaralise ühilduvuse probleemide lahendamisel metoodiliste lähenemiste süsteemne ühtsus. Metoodiliste käsitluste ühtsus kajastub infosüsteemide arendamise, dokumenteerimise, vastuvõtmise ja toimimise protsessi reguleerivates regulatiivdokumentides. Need on rahvusvahelised ja kodumaised standardid (GOST), tööstuse ja osakondade reguleerivad materjalid, eeskirjad, protokollid ja organisatsioonilised standardid.
Laialdaselt kasutatakse standardeid, mis reguleerivad infotöötluse keelevahendeid, kommunikatsioonitehnoloogiaid ja andmetöötlusorganisatsioone, objektidevahelist interaktsiooni jms.
5. Standardiseerimise ja ühtlustamise põhimõte, mis seisneb vajaduses kasutada IS-i toimimise standardseid, ühtseid ja standardiseeritud elemente. Eelkõige puudutab see info-, tehniliste, tarkvara- ja muude IT-tugede alamsüsteemide komponente. See põhimõte võimaldab vähendada IS-i loomise aja-, tööjõu- ja kulukulusid, kasutades maksimaalselt ära kogutud kogemusi projekteerimislahenduste kujundamisel ja projekteerimistööde automatiseerimise juurutamisel ning tagab IS-i mitmekülgse koostoime. ON.
6. Dekompositsiooni põhimõte, mis põhineb süsteemi osadeks jagamisel ja üksikute töökomplektide eraldamisel, loob tingimused juhtimistegevuse olemasoleva seisu tõhusamaks analüüsiks, uurides funktsionaalsete probleemide lahendamise tunnuseid konkreetsete edasiseks modelleerimiseks. juhtimistegevuse aspekte ja nende üleviimist automatiseeritud tehnoloogiale. Põhimõtet kasutatakse nii elementide omaduste ja süsteemi kui terviku omaduste uurimisel kui ka uuel infotehnoloogilisel baasil IS-i loomisel.
7. Efektiivsuse põhimõte, mis seisneb infosüsteemi loomise kulude ja selle toimimise käigus saavutatava eesmärgiefekti vahelise ratsionaalse suhte saavutamises.
Infosüsteemi elutsükli kirjeldamine hõlmab toimimist järgmiste mõistetega:
Protsess - tööde ahel, mis viiakse läbi järjestikku;
Etapid on järjestikused ajaperioodid, mille jooksul tööd tehakse. Lava jooksul saab teha erinevate protsessidega seotud töid. Majandusobjekti haldamiseks automatiseeritud infosüsteemi loomise ja kasutamise tegevus põhineb selle elutsükli (LC) kontseptsioonil. Elutsükkel on majandusobjekti haldamiseks mõeldud automatiseeritud infosüsteemi loomise ja kasutamise mudel, mis kajastab selle erinevaid olekuid, alustades selle tekkimise hetkest ja vajadusest selle järele kuni hetkeni, mil kõik kasutusest täielikult loobuvad. kasutajad ilma eranditeta.
Traditsiooniliselt eristatakse AIS-i elutsükli järgmisi põhietappe:
Nõuete analüüs;
Disain;
Programmeerimine/rakendamine;
Testimine ja silumine;
Kasutamine ja hooldus.
Vaatame lähemalt AIS-i elutsükli peamisi etappe:
1. Nõuete analüüs on AIS-i arendamise esimene etapp, mille käigus selgitatakse, vormistatakse ja dokumenteeritakse kliendi nõuded. Tegelikult antakse selles etapis vastus küsimusele: "Mida peaks tulevane süsteem tegema?" Ja see on kogu projekti edu. Suurte süsteemide loomise praktikas on palju näiteid ebaõnnestunud projekti elluviimisest just süsteeminõuete ebatäielikkuse ja ebaselge definitsiooni tõttu.
AIS-i nõuete loend peaks sisaldama:
1) tingimuste kogum, mille alusel ta peaks tulevase süsteemi opereerima (süsteemile antavad riist- ja tarkvararessursid; selle toimimise välistingimused, töötajate koosseis ja sellega seotud tööd)
2) funktsioonide kirjeldus, mida süsteem täitma peab;
3) piirangud arendusprotsessis (üksikute etappide läbimise suunavad tähtajad, olemasolevad ressursid, organisatsioonilised protseduurid ja meetmed teabekaitse tagamiseks).
Analüüsi eesmärk on muuta üldised hägused teadmised tulevase süsteemi nõuete kohta täpseteks (võimaluse korral) definitsioonideks.
Etapi tulemuseks peaks olema süsteeminõuete mudel (st süsteemi disain), mis tähendab:
1) süsteemi arhitektuur, selle funktsioonid, välistingimused, funktsioonide lahusus riist- ja tarkvaraosade vahel;
2) inimeste ja süsteemi liidesed ja funktsioonide lahusus;
3) nõuded tarkvarale ja tarkvaraosa infokomponentidele: vajalikud riistvararessursid, andmebaasinõuded, tarkvarakomponentide füüsilised omadused, nende liidesed.
Nõuete mudel peaks sisaldama;
1) tulevase süsteemi nõuete täielik funktsionaalne mudel töötlemissügavusega kuni iga ametniku iga toimingu tasemeni;
2) madalama taseme operatsioonide spetsifikatsioonid;
3) funktsionaalse mudeli aruannete ja dokumentide pakett, mis sisaldab modelleerimisobjekti tunnuseid, alamsüsteemide loetelu, nõuded komponentidevahelise teabevahetuse meetodite ja sidevahendite kohta, nõuded süsteemi suhete tunnustele naabersüsteemidega; nõuded süsteemi funktsioonidele;
4) nõuete kontseptuaalne infomudel;
5) infomudeli aruannete ja dokumentide pakett;
6) süsteemi arhitektuur viitega kontseptuaalsele infomudelile;
7) ettepanekud süsteemi toetava struktuuri korraldamiseks.
Seega sisaldab nõuete mudel funktsionaalseid, informatiivseid ja võimalusel ka sündmuste (kui sihtsüsteemiks on reaalajas süsteem) mudeleid. Sellel on traditsioonilise mudeli ees mitmeid eeliseid, nimelt:
1) Traditsioonilist arengut iseloomustab algetappide rakendamine käsitöönduslike, vormistamata meetoditega. Seetõttu saavad kliendid ja kasutajad süsteemi esimest korda näha pärast seda, kui see on juba suures osas juurutatud. Loomulikult erineb see süsteem sellest, mida nad ootasid. Seetõttu nõuavad selle arendamise või muutmise edasised iteratsioonid täiendavaid (ja olulisi) raha- ja ajakulutusi. Selle probleemi lahendamise võtme annab nõuete mudel, mis võimaldab
Kirjeldage, "näha" ja kohandage tulevast süsteemi enne selle füüsilist rakendamist;
Vähendada süsteemi arendamise ja juurutamise kulusid;
Hinda arengut aja ja tulemuste osas;
Saavutage vastastikune mõistmine kõigi töös osalejate (kliendid, kasutajad, arendajad, programmeerijad) vahel
Parandage arendatava toote kvaliteeti, nimelt: teostage selle funktsionaalne lagunemine ja kujundage integreeritud andmebaasi optimaalne struktuur.
2) Nõudemudel on täiesti sõltumatu ja konkreetsetest arendajatest eraldatud, ei vaja selle loojate poolt hooldust ning seda saab valutult teistele üle kanda. Pealegi, kui ettevõte ei ole mingil põhjusel valmis nõuete mudelil põhinevat süsteemi juurutama, võib selle vajaduse tekkimiseni “riiulile” jätta.
3) Nõudemudelit saab kasutada selle alusel juba juurutatud tarkvara iseseisvaks arendamiseks või kohandamiseks ettevõtte automatiseerimise osakonna programmeerijate poolt.
4) Nõudemudelit saab kasutada uute töötajate automatiseeritud ja kiireks koolitamiseks ettevõtte konkreetses tegevusvaldkonnas, kuna mudelis sisaldub selle tehnoloogia.
Nõuete analüüsi etapp on kõigi elutsükli etappide seas kõige olulisem. See mõjutab oluliselt kõiki järgnevaid etappe, jäädes samal ajal kõige vähem uuritud ja arusaadavamaks protsessiks. Selles etapis tuleb esiteks aru saada, mida täpselt teha tuleb, ja teiseks see dokumenteerida, sest kui nõudeid ei fikseerita ja projektis osalejatele kättesaadavaks ei tehta, siis neid justkui ei eksisteerigi. Samas peaks nõuete sõnastamise keel olema üsna lihtne ja kliendile arusaadav.
2. Tehniliste kirjelduste väljatöötamine toimub pärast mudeli ehitamist, see sisaldab nõudeid tulevasele süsteemile. Selle põhjal töötatakse välja tehniline kirjeldus, et luua süsteem, mis sisaldab:
Nõuded automatiseeritud tööjaamadele, nende koostis ja struktuur, samuti nendevahelise teabe interaktsiooni meetodid ja skeemid;
Tehnilistele vahenditele esitatavate nõuete väljatöötamine;
Tarkvaranõuete määramine;
Kohaliku arvutivõrgu topoloogia, koostise ja struktuuri arendamine;
Nõuded tööde etappidele ja ajastusele.
3. Disain. See etapp annab vastuse küsimusele: „Kuidas (mil viisil) süsteem täidab talle esitatavad nõuded? Selle etapi ülesanne
On uurimusi elementide loogiliste seoste süsteemi 1 struktuuri kohta ning konkreetsel platvormil realiseerimisega seotud küsimusi siin ei käsitleta. Disaini nähakse kui iteratiivset protsessi, mille käigus saadakse süsteemi loogiline mudel koos sellele seatud rangelt sõnastatud eesmärkidega, samuti kirjutatakse spetsifikatsioonid neile nõuetele vastavale füüsilisele süsteemile. See etapp jaguneb tavaliselt kaheks alaetapiks:
Süsteemiarhitektuuri projekteerimine, sealhulgas komponentide struktuuri ja liideste arendamine, funktsioonide ja komponentide tehniliste nõuete, projekteerimismeetodite ja standardite koordineerimine;
Detailne disain, mis hõlmab iga komponendi spetsifikatsioonide väljatöötamist, komponentidevahelisi liideseid, testimisnõuete väljatöötamist ja komponentide integreerimise plaani.
Teisisõnu, projekteerimine on olelusringi etapp, kus määratakse kindlaks, kuidas analüüsietapis genereeritud ja registreeritud metsanduse nõudeid rakendada. Sellest tulenevalt tuleks koostada rakendusmudel, mis näitab, kuidas süsteem täidab talle seatud nõudeid (ilma tehniliste üksikasjadeta). Tegelikult on rakendusmudel nõuete mudeli väljatöötamine ja täiustamine, nimelt on disain sild analüüsi ja rakendamise vahel.
4. Rakendamine (programmeerimine / kohandamine). Selles etapis luuakse LES tarkvara ja riistvara kompleksina (alates telekommunikatsiooni infrastruktuuri projekteerimisest ja loomisest ning lõpetades rakenduste arendamise ja installimisega).
5. Testimine ja silumine. AISi korrektsus on selle kõige olulisem omadus ja arendajate peamine mure. Ideaalis tähendab 1C korrektsus vigade puudumist. Seda on aga enamiku keerukate tarkvaratoodete puhul võimatu saavutada (iga programm sisaldab vähemalt ühte viga). Seetõttu mõistetakse “õige” all tavaliselt tarkvaratoodet, mis töötab vastavalt sellele esitatavatele nõuetele, ehk siis toodet, mille puhul pole veel leitud tingimusi, mille korral see ei töötaks.
Korrektsuse kindlakstegemine on vaadeldava elutsükli etapi peamine eesmärk. Tuleb märkida, et testimise ja silumise etapp on IS-i arendamise üks töömahukamaid, tüütumaid ja ettearvamatumaid etappe. Traditsiooniliste meetoditega arendamiseks kulub see etapp keskmiselt 1/2 kuni 1/3 kogu arendusajast. Teisest küljest on testimine ja silumine tõsine probleem: mõnel juhul kulub programmide testimiseks ja silumiseks mitu korda rohkem aega kui programmeerimine ise.
Testimine on protseduuride ja toimingute kogum, mille eesmärk on näidata IS-i õiget toimimist kindlaksmääratud režiimides ja välistingimustes. Testimise eesmärk on tuvastada vigade olemasolu või veenvalt näidata nende puudumist, mis on võimalik ainult teatud triviaalsetel juhtudel. Oluline on teha vahet testimise ja sellega seotud „silumise” kontseptsiooni vahel. Silumine on protseduuride ja toimingute kogum, mis algab vea olemasolu tuvastamisega ja lõpeb vea täpse asukoha, olemuse ja selle kõrvaldamise viiside kindlaksmääramisega.
Kõige olulisem ja praktikas kõige sagedamini kasutatav on deterministlik testimismeetod. Sel juhul kasutatakse testistandarditena spetsiifilisi lähteandmeid, mis koosnevad omavahel ühendatud sisend- ja tulemusväärtustest ning nende töötlemise õigetest järjestustest. Antud algväärtustega testimise käigus on vaja kindlaks teha, et nende töötlemise tulemused vastavad kontrollväärtustele.
Keerulised süsteemid nõuavad suurt hulka teste ning probleem tekib vajaliku arvu hindamisel ja nende vähendamise meetodite kasutamisel. Seetõttu on soovitatav planeerida testimine (nagu mis tahes muud tüüpi tegevused). Katseplaan peaks sisaldama:
1) testimise eesmärkide sõnastamine;
2) testimise kvaliteedi kriteeriumid, mis võimaldavad hinnata selle tulemusi;
3) testimisstrateegia, mis tagab kindlaksmääratud kvaliteedikriteeriumide saavutamise;
4) ressursinõuded etteantud kvaliteedikriteeriumi saavutamiseks vastavalt valitud strateegiale.
On olemas automatiseeritud testimis- ja silumissüsteemid (Satna). Need kujutavad endast keerukat algoritmiliste ja tarkvaratööriistade komplekti, mis on loodud AIS-i analüüsi, testimise, silumise ja selle kvaliteedi hindamise automatiseerimiseks ning võimaldavad hõlbustada AIS-i komponentide muutmist, tagada vigade tuvastamine silumise varases staadiumis. ja suurendage automaatselt tuvastatavate vigade protsenti.
6. Kasutamine ja hooldus. Selle etapi peamised eesmärgid on:
Süsteemi stabiilsuse tagamine ja info salvestamine - administreerimine;
Üksikute elementide õigeaegne moderniseerimine ja remont - tehniline tugi;
Ettevõtte praeguste ärivajadustega opereeritava süsteemi võimaluste kohandamine - süsteemi arendamine.
Need tööd peavad sisalduma ettevõtte informatiseerimise tegevuskavas, mis tuleb koostada kõiki strateegilise plaani tingimusi järgides. Vastasel juhul võivad olemasolevasse süsteemi tekkida killud, mis muudavad süsteemi tõhusa toimimise tulevikus võimatuks. Tänapäeval on välismaal tavapäraseks tavaks anda tehnilise toe ja osaliselt ka administreerimise funktsioonid süsteemitarnijatele või süsteemiintegraatoritele. Seda praktikat nimetatakse allhankeks. Sageli annab allhange kolmandatele osapooltele üle ka selliseid funktsioone nagu looduskatastroofi või muude eritingimuste korral kasutatavate kriitiliste ärirakenduste varukoopiate salvestamise ja täitmiskeskuste loomine ja toetamine.
Käitamise ja hoolduse etapis tuleks erilist tähelepanu pöörata personali koolitusele ja vastavalt sellele protsessi investeeringute planeerimisele.
Elutsükkel kujuneb ülalt-alla projekteerimise põhimõttel ja on tavaliselt iteratiivse iseloomuga: rakendatud etappe korratakse tsükliliselt, alates kõige esimestest, vastavalt nõuete muutumisele ja välistingimustele, piirangute kehtestamisele, jne. Igas elutsükli etapis luuakse teatud komplekt dokumente ja tehnilisi lahendusi. Lisaks on iga etapi lähtepunktiks eelmises etapis saadud dokumendid ja otsused. Iga etapp lõpeb loodud dokumentide ja lahenduste kontrollimisega, et kontrollida nende vastavust väljundile.
Olemasolevad olelusringi mudelid määravad arenduse käigus kindlaks etappide järjekorra, samuti etapilt etapile ülemineku kriteeriumid. Selle kohaselt on järgmised kolm mudelit ZhShch4] kõige levinumad:
1. Kaskaadmudel (70-80ndad) näeb ette ülemineku järgmisse etappi pärast eelmise etapi töö täielikku lõpetamist ning seda iseloomustab andmete ja nende töötlemisprotsesside selge eraldamine (joonis 2.6).
Riis. 2.6. Kaskaadi IP elutsükli mudel
2. Stage-by-stage mudel vahepealse juhtimisega (80-85s) - iteratiivne arendusmudel, millel on etappidevahelised tagasisidetsüklid. Selle mudeli eeliseks on see, et etappidevahelised reguleerimised tagavad kaskaadmudeliga võrreldes väiksema töömahukuse; teisalt ulatub iga etapi eluiga üle kogu arenguperioodi.
3. Spiraalmudel (86 - 90ndad) - keskendub elutsükli algfaasidele: nõuete analüüs, spetsifikatsiooni kavandamine, eelnev ja detailne projekteerimine. Nendel etappidel kontrollitakse tehniliste lahenduste teostatavust ja põhjendatakse prototüüpide loomisega. Iga spiraali pööre vastab etapiviisilisele mudelile süsteemi fragmendi või versiooni loomiseks, mille peal selgitatakse projekti eesmärgid ja omadused, määratakse selle kvaliteet ning järgmise pöörde töö. spiraal on planeeritud. Nii süvendatakse ja järjepidevalt täpsustatakse projekti detaile ning selle tulemusena valitakse välja põhjendatud variant, mis viiakse elluviimiseni (joonis 2.7.).
Riis. 2.7. Spiraalne IP elutsükli mudel
Eksperdid märgivad spiraalmudeli järgmisi eeliseid:
Tarkvara, mudelite ja prototüüpide kogumine ja taaskasutamine;
Keskenduda süsteemi arendamisele ja muutmisele selle projekteerimisel;
Riski- ja kuluanalüüs projekteerimisprotsessis.
Spiraalmudeli kasutamisel akumuleeritakse ja taaskasutatakse projekteerimislahendusi, projekteerimisvahendeid, infosüsteemi ja infotehnoloogia mudeleid ja prototüüpe; keskendutakse süsteemide ja tehnoloogiate väljatöötamisele ja muutmisele nende projekteerimisel; süsteemide ja tehnoloogiate projekteerimise käigus teostatakse riskide ja kulude analüüs.
Infotehnoloogia disaini tunnused. Kaasaegne infotehnoloogia on rakendatud projekteeritud infosüsteemi tingimustes.
Disaini aspektid: tehniline (riistvara- ja sidekompleks), tarkvara ja matemaatika (mudelid ja programmid), metodoloogiline (juhtimisfunktsioonide elluviimise vahendite kogum), organisatsiooniline (dokumentide liikumise kirjeldus ja juhtimisaparaadi tegevuste reeglid), operatiivne (automaatselt rakendatav tehnoloogiliste, loogiliste, aritmeetiliste toimingute kogum).
IS ja IT loomine on keeruline projekteerimisprotsess. Projekteerimise eesmärk on projekteerimisdokumentide koostamine ja inim-masin juhtimissüsteemi juurutamine organisatsioonis. Projekteerimise käigus selgitatakse välja majandusobjekti olulisemad omadused, uuritakse selle väliseid ja sisemisi infovoogusid, luuakse uuritava süsteemi ja selle elementide matemaatilised ja füüsikalised analoogid ning tingimused inimeste ja tehniliste kontrollide koostoimeks. on asutatud.
Arvestades IS-i tehnoloogilisest aspektist, võime esile tõsta juhtimisaparatuuri (AC). Ülejäänud komponendid - infotehnoloogia (IT), funktsionaalsete probleemide lahendamise infosüsteem (ISPS) ja otsuste tugisüsteem (DSS) - on omavahel informatiivselt ja tehnoloogiliselt seotud ning moodustavad IS-i arhitektuuri aluse.
Infotehnoloogia hoolikalt läbimõeldud tehnoloogiline tugi võimaldab mitte ainult edukalt lahendada funktsionaalseid juhtimisprobleeme, vaid ka DSS-i raames juhtidel ja organisatsioonide juhtidel teha interaktiivselt analüütilist ja ennustavat tööd järgnevate juhtimisotsuste tegemiseks.
Infotehnoloogia kavandatava tehnoloogilise toe kohustuslikud elemendid on: informatiivne, keeleline, tehniline, tarkvaraline, matemaatiline, organisatsiooniline, juriidiline, ergonoomiline.
Infotugi (IS) on kujundusotsuste kogum, mis puudutab IS-s ringleva teabe mahtusid, paigutust ja organiseerimise vormi.
Lingvistiline tugi (LS) - ühendab keeletööriistade komplekti loomuliku keele vormistamiseks, teabeüksuste konstrueerimiseks ja kombineerimiseks kasutajate ja arvutitehnoloogia vahelise suhtluse ajal.
Tehniline tugi (TS) on tehniliste vahendite kogum (teabe kogumise, registreerimise, edastamise, töötlemise, kuvamise, taasesitamise tehnilised vahendid, kontoritehnika jne), mis tagavad IT toimimise.
Tarkvara (SW) - sisaldab programmide komplekti, mis rakendavad IS-i funktsioone ja ülesandeid ning tagavad tehniliste vahendite komplekside stabiilse töö.
Matemaatiline tarkvara (MS) on matemaatiliste meetodite, mudelite ja infotöötlusalgoritmide kogum, mida kasutatakse funktsionaalsete ülesannete lahendamisel ja projekteerimistööde automatiseerimise protsessis.
Organisatsioonitugi (OS) on IS-i projekteerimise käigus koostatud dokumentide kogum, mis kinnitatakse ja mida kasutatakse toimimise aluseks.
Õigusabi (LbS) on õigusnormide kogum, mis reguleerib õigussuhteid IP ja IT loomisel ja rakendamisel.
Ergonoomiline tugi (ES) - meetodite ja tööriistade kogumina, mida kasutatakse IS-i ja IT arendamise ja toimimise erinevates etappides, on mõeldud optimaalsete tingimuste loomiseks kvaliteetseks, väga tõhusaks ja vigadeta inimtegevuseks IT-s, selle kiireim areng.
Ärikorralduse all mõistetakse projekteerimistööde komplekti rakendamist ärijuhtimise meetodite ja protseduuride väljatöötamiseks, kui organisatsiooni (ettevõtte, ettevõtte) aktsepteeritud juhtimisstruktuuri muutmata saavutatakse selle finantsseisundi paranemine.
Inseneril on ettevõtte kujundamiseks mitmeid tehnikaid:
kavandatava ettevõtte jaoks samm-sammult protseduuride esiletõstmine;
protseduure kirjeldavate noodisüsteemide kasutuselevõtt;
heuristika ja pragmaatiliste lahenduste kasutamine kavandatava ärivõimaluse vastavuse määra kirjeldamiseks etteantud eesmärkidele.
Äriprotsessi all mõistetakse organisatsiooni (ettevõte, firma, korporatsioon) põhitegevuste terviklikku kirjeldust ja nende projekteerimist organisatsiooni struktuuridele, võttes arvesse osalejatevahelise suhtluse arengut ajas.
Ettevõtte ümberkujundamise projekt sisaldab tavaliselt järgmisi samme:
tulevase organisatsiooni kuvandi kujundamine;
olemasoleva äritegevuse analüüs;
uute ettevõtete arendamine;
uue ettevõtte tutvustamine.
Simulatsioon on kõige edukam lähenemine, mis tagab alternatiivsete lahenduste võrdlemisel nii analüüsi täpsuse kui ka erinevuste selguse. Samuti on oluline, et simulatsioonimodelleerimine oleks edukalt rakendatud personaalarvutis, mis tagab automatiseeritud juhi tööjaama.
Ühtse teaberuumi all mõistetakse metoodiliste, organisatsiooniliste, tarkvaraliste, tehniliste ja telekommunikatsioonivahendite kogumit, mis võimaldavad kiiret juurdepääsu ettevõtte mis tahes teaberessurssidele spetsialistide pädevuse ja juurdepääsuõiguste piires.
Controlling on lahenduste leidmise meetodite kogum - süsteemijuhtimise kontseptsioon ja juhtide mõtteviis, mis lähtub soovist tagada organisatsiooni pikaajaline efektiivne toimimine. Juhtimisülesannete rakendamiseks DSS-i kujundamise protsessis luuakse spetsiaalne teabemudel, mida nimetatakse kontrolleriks.
Kontroller on meetodite ja vahendite kogum strateegiliste ja operatiivjuhtimise ülesannete elluviimiseks juhtimissüsteemis, samuti strateegiliste ja taktikaliste probleemide lahendamiseks juhtimistegevuse valdkondades (turundus, ressursside tagamine, investeeringud jne).
Eeltoodud lähenemiste kohaselt kujundatakse IS-i loomise ja IT-juhtimise aluspõhimõtted:
IS-i toetavate ja funktsionaalsete elementide süsteemne ja loogiline ülesehitus;
majanduslike ja matemaatiliste meetodite ning prognoosimise ja statistilise iseloomuga standardprogrammide laialdane kasutamine. Organisatsiooni tootmis- ja finantstegevuse juhtimise ülesanded on enamasti püstitatud analüütiliste, optimeerimis- või planeerimisülesannetena.
hõlmab süsteemi jaotamist mitmeteks ülesannete kompleksideks (mooduliteks), millest igaüks modelleerib teatud juhtimistegevuse valdkonda.
uute meetodite kasutamine ja vastloodud tarkvaramoodulite kaasamine juhtimise automatiseerimissüsteemi. IC-disain peaks esialgu põhinema modulaarsetel põhimõtetel ja arvutirakendus peaks võimaldama tarkvarastruktuuri täiustamise kaudu laienemist.
see on kõigi elementide ja süsteemi kui terviku kohandamise põhimõte. See peab täielikult läbima IS-i juhtimise ülesehitamise ideoloogiat – alates ülesannete analüüsist, tehnilistest ja majanduslikest näitajatest ning nende moodulitesse rühmitamisest kuni eesmärkide sõnastamiseni.
Iga juhi töö lõpptooteks on otsused ja tegevused. Tema tehtud otsus viib kas ettevõtte eduni või ebaõnnestumiseni. Otsustamine on alati konkreetse tegevussuuna valik mitme võimaliku hulgast. Kuna iga organisatsiooni juhtimisprotsess majanduses toimub eranditult juhtimisotsuste kujundamise ja elluviimise kaudu, keskendume seetõttu otsuste tüüpidele, millel on erinevad omadused ja mis nõuavad erinevaid andmeallikaid.
Operatiivsed otsused on perioodilised: sama probleem tekib perioodiliselt. Selle tulemusena muutub otsustusprotsess suhteliselt rutiinseks ja peaaegu probleemivabaks. Otsuste tegemisel kasutatavad äriprotsesside parameetrid (karakteristikud) on määratletud, nende hinnang on suure täpsusega teada ning parameetrite seos tehtud otsusega on selge. Operatiivsete otsuste tegemine viib täiesti oodatud ja prognoositavate tulemusteni. Operatiivsed lahendused on lühiajalised.
Taktikalisi otsuseid teevad tavaliselt keskastme juhid, kes vastutavad tipptasemel otsustajate seatud eesmärkide ja kavatsuste saavutamiseks vajalike vahendite tagamise eest. Taktikalised otsused ei ole nii rutiinsed ja struktureeritud kui operatiivotsused. Kõik taktikaliste otsuste osaks olevad juhtimisobjekti peamised parameetrid on teadmata; Oluliseks tunnistatud tunnuste hinnangud ei pruugi olla teada ning tunnuste ja otsuste vaheline seos ei pruugi olla selge.
Strateegilised otsused tehakse lähtuvalt ettevõtte eesmärkidest, mis on määratletud selle põhikirjas ja määratletud ettevõtte tippjuhtkonna poolt. Need eesmärgid määratlevad aluse, millel peaks põhinema pikaajaline planeerimine, samuti ettevõtte jaoks kriitiliste tegurite kindlaksmääramise. Need otsused on taktikaliste ja operatiivsete otsuste tegemise aluseks.
Vaatame igas etapis kasutatavaid mudeleid ja meetodeid. Esimeses etapis kasutatakse peamiselt mitteametlikke meetodeid, et:
sõnastada probleem;
tuvastada eesmärk;
sõnastada otsuste tegemise hindamise kriteerium.
Kui probleem tuvastatakse ja tuvastatakse kvantitatiivsete näitajate või kvalitatiivsete tunnuste abil, saab sõnastada eesmärgid. Eesmärk on probleemile vastupidine. Kui probleem on selles, mida otsustaja ei taha, siis eesmärk on see, mida ta tahab.
Otsuse kujundamise teises etapis otsitakse erinevaid võimalusi - alternatiive. Võimalusi võib leida mitmesugustes mõõtmisvormides ja -skaalades. Valikud määratakse reeglina kas loetledes, kui neid pole väga palju, või nende omadusi kirjeldades.
Kolmandas etapis toimub vastavalt teises etapis sõnastatud valikukriteeriumile lahenduse võrdlemine, hindamine ja valik. Kõik valikute hindamise meetodid võib jagada kahte rühma:
kindluse tingimustes kasutatavad meetodid;
riskiolukordades kasutatavad meetodid.
DSS-i kujundamise etapid tarkvarakesta juuresolekul on järgmised:
Ainevaldkonna kirjeldus, süsteemi loomise eesmärgid ja probleemipüstituse rakendamine.
Süsteemisõnastiku koostamine.
Teadmusbaasi ja andmebaasi arendamine.
Süsteemi juurutamine.
1. etapp. Ainevaldkonna kirjeldus, süsteemi loomise eesmärgid ja probleemipüstituse rakendamine. Kirjeldus peaks kajastama ainevaldkonna eripära mitmel kujul. Esimene neist on protsesside, objektide ja nendevaheliste seoste sisu tekstiline esitus. Teine kirjelduse vorm on kasutaja ees seisvate eesmärkide puu või JA-VÕI puu graafiline esitus.
Mis tahes probleemi sõnastamine hõlmab süsteemi toimimise tulemuste, lähteandmete näitamist, samuti protseduuride, valemite ja algoritmide üldist kirjeldust lähteandmete teisendamiseks saadud andmeteks.
2. etapp. Süsteemisõnastiku koostamine. Süsteemisõnastik on sõnade, fraaside, koodide, nimede kogum, mida arendaja kasutab tingimuste, eesmärkide, järelduste ja hüpoteeside tähistamiseks. Tänu sõnastikule mõistab kasutaja süsteemi tulemusi. Sõnastiku koostamine on oluline töö, sest selgelt määratletud tingimused ja vastused tõstavad süsteemi töö efektiivsust hüppeliselt.
3. etapp. Teadmusbaasi ja andmebaasi arendamine. Teadmistebaas koosneb reeglina kahest komponendist: arvutusvalemitega eesmärkide puust ja reeglibaasist (järeldusvõrk). Reeglibaas koostatakse eesmärgigraafiku ja eelnevalt sõnastatud hüpoteeside põhjal. Põhitähelepanu pööratakse siin algtingimuste kindluskoefitsientidele ja nende töötlemise reeglitele.
4. etapp. Rakendamine. Kontrollitakse ja hinnatakse süsteemi korrektset toimimist. Tulemused määratakse, mida seejärel võrreldakse süsteemi käivitamise käigus saadud tulemustega. Vahearvutusi kontrollitakse ka ploki abil, mis vastab küsimustele kuidas ja miks.
Infosüsteemide (IS) projekteerimistehnoloogia all mõistetakse loogilises järjestuses järjestatud metoodiliste tehnikate, tehniliste vahendite ja projekteerimismeetodite kogumit, mille eesmärk on rakendada süsteemi ja selle komponentide loomise või kujunduse lõpetamise üldkontseptsiooni. Juhtsüsteemide väljatöötamisel on suur tähtsus projekteerimisbaasi kvaliteedil ja koostisel.
IS-i disaini tehnoloogilise ahela ja selle põhikomponendi - IT - elementaarne aluskujundus on nn tehnoloogiline operatsioon - eraldiseisev lüli tehnoloogilises protsessis.
See mõiste on määratletud IT arendusprotsessi küberneetilise lähenemise alusel. Selle protsessi automatiseerimine määrab kindlaks vajaduse vormistada tehnoloogilisi toiminguid, ühendada need järjestikku omavahel seotud projekteerimisprotseduuride ja nende esituse tehnoloogiliseks ahelaks.
Ainevaldkonna projektieelne uuring hõlmab objekti kõigi omaduste ja selles toimuvate juhtimistegevuste, sisemiste ja väliste infoühenduste voo, uutes tehnoloogilistes tingimustes töötavate ülesannete ja spetsialistide koosseisu, nende töövõime taseme väljaselgitamist. arvuti- ja erialane koolitus kui süsteemi tulevased kasutajad.
Vaatleme radadest esimest, s.o. Rakenduspakettides sisalduvate standardsete disainilahenduste kasutamise võimalus. Informatiseerimiseks sobivad kõige tõhusamalt järgmised tegevused:
raamatupidamine, sealhulgas juhtimis- ja rahandus;
majandustegevuse teatme- ja teabeteenused;
juhi töökorraldus;
dokumendivoo automatiseerimine;
majandus- ja finantstegevus;
haridust.
Automatiseeritud projekteerimissüsteemid on teine kiiresti arenev viis projekteerimistööde läbiviimiseks.
IS-i ja IT-disaini automatiseerimise vallas on viimase kümnendi jooksul tekkinud uus suund - CASE (Computer-Aided Software/System Engineering). CASE on süsteemianalüütikutele, arendajatele ja programmeerijatele mõeldud tööriistakomplekt, mis võimaldab automatiseerida IS-i kujundamise ja arendamise protsessi, mis on IS ja IT loomise ja hooldamise praktikas kindlalt kinnistunud. CASE-i põhieesmärk on eraldada IS ja IT disain selle kodeerimisest ja järgnevatest arendusetappidest, samuti automatiseerida võimalikult palju süsteemide arendus- ja toimimisprotsesse.
Lisaks struktuursete metoodikate automatiseerimisele ja sellest tulenevalt võimalusele kasutada kaasaegseid süsteemi- ja tarkvaratehnika meetodeid, on CASE-l järgmised peamised eelised:
parandada loodud infosüsteemide (IT) kvaliteeti automaatjuhtimisvahenditega (eelkõige projektijuhtimine);
võimaldavad lühikese ajaga luua tulevase IS-i (IT) prototüübi, mis võimaldab varakult hinnata oodatavat tulemust;
kiirendada süsteemi projekteerimise ja arendamise protsessi;
vabastage arendaja rutiinsest tööst, võimaldades tal keskenduda täielikult disaini loomingulisele osale;
toetada juba toimiva IS (IT) arendamist ja hooldamist;
tugitehnoloogiad arenduskomponentide taaskasutamiseks.
Enamik CASE-i tööriistu põhinevad teaduslikul lähenemisviisil, mida nimetatakse metoodikaks/meetodiks/märkimiseks/tööriistaks. Metoodikas formuleeritakse juhised väljatöötatud IS-i projekti hindamiseks ja valikuks, tööetapid ja nende järjestus ning meetodite rakendamise ja eesmärgi reeglid. Tänaseks on CASE-tehnoloogia võtnud kuju iseseisva teadusmahuka suunana, mis on viinud võimsa CASE-tööstuse kujunemiseni, mis ühendab sadu erineva suunitlusega ettevõtteid ja ettevõtteid.
Õigeaegsus iseloomustab IS-i ja IT ajalisi omadusi ning sellel on kvantitatiivne väljendus kasutajale praegusel ajahetkel reaalsetes otsustustingimustes vajamineva teabe summaarse viiteaja näol. Mida väiksem on teabe saamise ajaline viivitus, seda paremini IS sellele nõudele vastab.
IS usaldusväärsuse üldnäitaja sisaldab mitmeid olulisi omadusi:
tehniliste rikete sagedus;
matemaatiliste mudelite adekvaatsusaste;
programmide puhtuse kontrollimine;
teabe usaldusväärsuse suhteline tase;
integreeritud indikaator ergonoomilise IS-toe usaldusväärsuse kohta.
Süsteemi adaptiivsed omadused peegeldavad selle võimet kohaneda organisatsiooni sisemise juhtimis- ja tootmiskeskkonna ümbritseva välistausta muutustega. Kliendi oluliseks ülesandeks on projekteerimisetapis sõnastada piirid kogu süsteemi toimimise seisukohalt fundamentaalse tähtsusega juhtimis- ja väljundparameetrite väärtuste kõrvalekallete lubamiseks.
Üldiselt koosneb probleemipüstitus neljast põhimõtteliselt olulisest komponendist:
organisatsiooniline ja majanduslik skeem ja selle kirjeldus;
rakendatud matemaatiliste mudelite komplekt;
arvutusalgoritmide kirjeldused;
kontseptsioonid süsteemi infomudeli koostamiseks.
Matemaatiline mudel ja selle alusel välja töötatud algoritmid peavad vastama kolmele nõudele: kindlus (üheselt mõistetavus), invariantsus ülesande erinevate alternatiivsete olukordade suhtes ja efektiivsus (võimekus seda lahendada piiratud arvu sammudega). Algoritmiseerimise tulemuseks on loogiliselt konstrueeritud ja silutud plokkskeem.
Ülesannete formuleerimine ja edasine arvutipõhine teostamine eeldab teoreetiliste aluste ja infotehnoloogiaga seotud põhimõistete valdamist. Need sisaldavad:
majandusinformatsiooni omadused, tunnused ja struktuur;
tingimuslikult püsiv teave, selle roll ja eesmärk;
andmekandjad, masinkandjate paigutus;
teabe formaliseeritud kirjeldamise vahendid;
algoritm, selle omadused ja esitusvormid;
sisend- ja väljundinfo jälgimise eesmärk ja meetodid;
arvutiseadmete koostis ja otstarve;
Infosüsteem (IS) on omavahel seotud tööriistade, meetodite ja personali kogum, mida kasutatakse teabe säilitamiseks, töötlemiseks ja väljastamiseks seatud eesmärgi saavutamise huvides.
Kaasaegsed infotehnoloogiad pakuvad IS-i juurutamiseks laia valikut võimalusi, mille valikul lähtutakse sihtkasutajate nõudmistest, mis arendusprotsessi käigus reeglina muutuvad.
IS-projekti all peame silmas projekteerimist ja insenertehnilist dokumentatsiooni, mis kirjeldab projekteerimislahendusi IS-i loomiseks ja toimimiseks konkreetses tarkvara- ja riistvarakeskkonnas.
IS-i disaini all mõistetakse protsessi, mille käigus teisendatakse objekti sisendteave, meetodid ja sarnase eesmärgiga objektide projekteerimise kogemus vastavalt GOST-ile IS-projektiks. Sellest vaatenurgast taandub IS-i projekteerimine projekteerimisotsuste järjekindlale vormistamisele IS-i elutsükli erinevates etappides: nõuete planeerimine ja analüüs, tehniline ja detailne projekteerimine, IS-i juurutamine ja toimimine.
Arendatavate süsteemide mastaap määrab projekteerimisprotsessis osalejate koosseisu ja arvu. Suure mahu ja kitsaste projekteerimistööde teostamise tähtaegadega võivad süsteemi arenduses osaleda mitmed projekteerimismeeskonnad (arendusorganisatsioonid). Sel juhul määratakse kindlaks vanemorganisatsioon, kes koordineerib kõigi kaastäitvate organisatsioonide tegevust.
IC projekteerimise läbiviimine hõlmab disainerite poolt teatud projekteerimistehnoloogia kasutamist, mis vastab arendatava projekti ulatusele ja omadustele.
Mudel (ladina keeles "modulus" - mõõt) on algobjekti asendusobjekt, mis võimaldab uurida viimase mõningaid omadusi; süsteemi lihtsustatud esitus selle analüüsiks ja prognoosimiseks, samuti õige juhtimisotsuse tegemiseks vajalike kvalitatiivsete ja kvantitatiivsete tulemuste saamine.
Modelleerimine on objekti kujutamine mudeliga, et saada selle kohta teavet selle mudeliga katsete läbiviimisel.
Nad kasutavad IC-de kujundamiseks teabemudelid, mis kujutab objekte ja protsesse piltide, diagrammide, jooniste, tabelite, valemite, tekstide jne kujul.
Infomudel on objekti, protsessi või nähtuse mudel, milles esitatakse modelleeritava objekti, protsessi või nähtuse infoaspektid.
See on IS-mudelite väljatöötamise aluseks.
IP loomise mudelil on neli etappi:
1. Projekti eskiis. P projekti eesmärkide ja eesmärkide üksikasjalik kirjeldus, oodatav kasum, ajaressurss, võimalikud piirangud, olemasolevad ressursid jne. Samuti tasub välja selgitada projekti elluviimise eest vastutav "projektijuht" ja tippjuhtkonnas projektiomanik, kes on ettevõtte põhiisik ja toetab projektijuhti vajadusel ja kõige lõpus. projekti.
2. Projekti hindamine. See on projekti kõige olulisem osa. Seal tehakse kõik olulised otsused – mida süsteemid teevad, kuidas nad töötavad, millist riistvara ja rakendusi kasutatakse ning kuidas neid hooldatakse. Kõige olulisem on see, et analüüsitakse erinevate tegevuste võimalikke kulusid ja tulusid ning tehakse lõplik valik. Üldreegel peaks olema, et süsteem peaks olema võimalikult lihtne. Tohutud süsteemiprojektid võivad kaasa tuua uskumatuid kulusid. Hiljem tehtud muudatused on kallimad.
3. Esmalt koosta süsteemile esitatavate nõuete loetelu – detailne nimekiri sellest, mida süsteem ettevõtte heaks teeb ja kuidas seda hallata. Uuritakse tavakasutajate (ja teiste huvirühmade) vajadusi, sest ainult nemad teavad tegelikult, mida nad vajavad ja kuidas seda olemasolevatesse tegevustesse sobitada.
4. Nimekirjas on sisestatavad andmed, peamised tulemused ja aruanded, kasutajate arv, info suurus, seosed teiste olemasolevate süsteemidega jne. ja see peab olema piisavalt üksikasjalik, et võimaldada päringu saatmist riist- ja tarkvaratarnijatele.
5. Praeguses etapis ei tohiks me lihtsalt olemasolevaid tööviise arvutisse muuta. Infotehnoloogia projekt on hea võimalus uuesti mõelda, kuidas oleks kõige parem infosüsteemi teha.
6. Järgmine etapp on riist- ja tarkvaranõuete vaatamine. Pidage nõu potentsiaalsete tarnijatega, vaadake üle muud äriotsused ja konsulteerige asjatundlike nõustajatega. Mõningaid raskeid otsuseid tuleb hoolikalt hinnata. Vastama tuleks näiteks järgmistele küsimustele: kas kasutada juba valmis rakendusprogrammide paketti või tellida uus tarkvara. Vastused sõltuvad riskitasemest, mida olete nõus võtma, ja sellest, kuidas teie ettevõte erineb teistest tüüpilistest ettevõtetest.
Kulude-tulude analüüs on viimane samm enne lõpliku otsuse tegemist. Rakendusprogrammide ja riistvara kulud on suhteliselt madalad, eriti kui kasutate standardpaketti. Suured kulud on süsteemi paigaldamise aeg ja aeg selle toimimise toetamiseks.
7. Ehitus ja katsetamine.Üks alahinnatumaid samme mis tahes süsteemi installimisel on kõigi andmete sisestamine süsteemi enne selle käivitamist.
8. Töötajad peaksid tagama, et süsteemi on lihtne kasutada. Miski ei tapa uue süsteemi vastu entusiasmi kiiremini kui rida tehnilisi probleeme.
9. Projektijuhtimine ja riskide hindamine. Kui projekt pole täiesti triviaalne, peab olema projektijuht, kellel on piisavalt aega projektiga töötamiseks ja paljude esilekerkivate probleemidega tegelemiseks. Projekt ei ole lõpetatud enne, kui projektijuht suudab tõestada, et süsteem töötab usaldusväärselt ja on kasumlik.
10. Tema rolli oluline osa on olla alati teadlik projektiga kaasnevatest riskidest. Riskidest tuleks avalikult rääkida, hoolimata kiusatusest pea liiva alla matta ja loota, et kõik saab korda. Riski saab planeerida: tehes alternatiivseid otsuseid, valmistudes äärmuslikeks tegudeks jne. Näiteks võib tuua tarkvara valiku, kus erinevad otsused võivad olla erineval määral riskantsed. Edasiseks aruteluks ruumi ei ole, kuid järgmise kontrollnimekirja kasutamine võib aidata mõningaid punkte esile tõsta.
ekraanivormid, aruanded, mis tagavad andmepäringute täitmise;Infosüsteemide projekteerimine algab alati projekti eesmärgi määratlemisest. Üldiselt võib projekti eesmärgiks määratleda mitmete omavahel seotud ülesannete lahendamine, sealhulgas tagada süsteemi käivitamise ajal ja kogu selle tööperioodi jooksul:
- süsteemi nõutav funktsionaalsus ja selle kohanemisvõime muutuvate töötingimustega;
- nõutav süsteemi läbilaskevõime;
- nõutav süsteemi reageerimisaeg päringule;
- süsteemi tõrgeteta töö;
- nõutav turvalisuse tase;
- töö lihtsus ja süsteemi tugi.
Kaasaegse metoodika kohaselt on IS-i loomise protsess protsess, mille käigus konstrueeritakse ja järjestikku muundatakse üleüldse mitmed järjekindlad mudelid. elutsükli etapid(LC) IS. Igas elutsükli etapis luuakse sellele omased mudelid - korraldus, IS nõuded, IS projekt, taotluse nõuded jne. Mudelid koostatakse projektimeeskonna töörühmade poolt, salvestatakse ja kogutakse projektihoidlasse. Mudelite loomine, nende juhtimine, teisendamine ja kollektiivseks kasutamiseks võimaldamine toimub spetsiaalsete tarkvaratööriistade - CASE tööriistade abil.
IP loomise protsess on jagatud seeriateks etapid(etapid [1.1]), mis on piiratud teatud ajaraamiga ja lõppevad konkreetse toote (mudelid, tarkvaratooted, dokumentatsioon jne) väljalaskmisega.
Tavaliselt eristatakse järgmist IP loomise etapid: süsteeminõuete kujundamine, projekteerimine, juurutamine, testimine, kasutuselevõtt, käitamine ja hooldus [1.1] [1.2]. (Kahte viimast etappi pikemalt ei käsitleta, kuna need jäävad kursuse ulatusest välja.)
IS loomise protsessi algetapp on organisatsioonis toimuvate äriprotsesside modelleerimine ning selle eesmärkide ja eesmärkide elluviimine. Äriprotsesside ja ärifunktsioonide lõikes kirjeldatud organisatsioonimudel võimaldab sõnastada IS-i põhinõuded. See metoodika põhipositsioon tagab objektiivsuse süsteemi projekteerimisnõuete väljatöötamisel. Seejärel muudetakse IS-i nõuete kirjeldamise mudelite kogum mudelite süsteemiks, mis kirjeldavad IS-i kontseptuaalset disaini. Moodustatakse IS arhitektuuri mudelid, nõuded tarkvarale (SW) ja infotoele (IS). Seejärel moodustatakse tarkvara- ja infoarhitektuur, identifitseeritakse ettevõtete andmebaasid ja üksikrakendused, kujundatakse rakenduste nõuete mudelid ning teostatakse nende arendamine, testimine ja integreerimine.
Initsiaali eesmärk IP loomise etapid Organisatsiooni tegevuse analüüsimise etapis viiakse läbi infosüsteemidele nõuete kujundamine, mis kajastavad õigesti ja täpselt kliendiorganisatsiooni eesmärke ja eesmärke. Organisatsiooni vajadustele vastava infosüsteemi loomise protsessi täpsustamiseks on vaja välja selgitada ja selgelt sõnastada, mis need vajadused on. Selleks on vaja välja selgitada kliendi nõuded IS-ile ja kaardistada need mudelkeeles IS-projekti arendamise nõuetesse, et tagada vastavus organisatsiooni eesmärkidele ja eesmärkidele.
Infosüsteemidele nõuete kujundamise ülesanne on üks olulisemaid, raskemini vormistatavaid ning vea korral kulukaim ja raskemini parandatav. Kaasaegsed tööriistad ja tarkvaratooted võimaldavad kiiresti luua IP vastavalt valmisnõuetele. Kuid sageli ei rahulda need süsteemid kliente ja nõuavad arvukalt muudatusi, mis toob kaasa kulude järsu tõusu tegelik kulu ON. Sellise olukorra peamiseks põhjuseks on IS-i nõuete vale, ebatäpne või mittetäielik määratlemine analüüsietapis.
Projekteerimisetapis moodustatakse esmalt andmemudelid. Disainerid saavad analüüsitulemused esialgse teabena. Peamine osa on loogiliste ja füüsiliste andmemudelite loomine andmebaasi disain. Analüüsiprotsessi käigus saadud teabemudel teisendatakse esmalt loogiliseks ja seejärel loogiliseks füüsiline andmemudel.
Paralleelselt disainiga andmebaasi skeemid Protsessi kavandamine viiakse läbi kõigi IS moodulite spetsifikatsioonide (kirjelduste) saamiseks. Mõlemad disainiprotsessid on omavahel tihedalt seotud, kuna osa äriloogikast on tavaliselt andmebaasis juurutatud (piirangud, päästikud, salvestatud protseduurid). Protsesside kavandamise põhieesmärk on kaardistada analüüsifaasis saadud funktsioonid infosüsteemi mooduliteks. Moodulite kujundamisel määratakse programmide liidesed: menüü paigutus, akna välimus, kiirklahvid ja nendega seotud kõned.
Projekteerimisetapi lõpptooted on:
- andmebaasi diagramm (analüüsi etapis väljatöötatud ER mudeli alusel);
- komplekt mooduli spetsifikatsioonid süsteemid (need on üles ehitatud funktsioonimudelite alusel).
Lisaks toimub projekteerimisetapis ka IS-i arhitektuuri arendus, sealhulgas platvormi (platvormid) ja operatsioonisüsteemi (operatsioonisüsteemid) valik. Heterogeenses IS-is võivad mitmed arvutid töötada erinevatel riistvaraplatvormidel ja erinevatel operatsioonisüsteemidel. Lisaks platvormi valimisele määratakse projekteerimisetapis kindlaks järgmised arhitektuurilised omadused:
- kas see on failiserver või klient-server arhitektuur;
- kas see on 3-tasandiline arhitektuur järgmiste kihtidega: server, vahevara (rakendusserver), klienttarkvara;
- kas andmebaas on tsentraliseeritud või hajutatud. Kui andmebaas on hajutatud, siis milliseid mehhanisme kasutatakse andmete järjepidevuse ja asjakohasuse säilitamiseks;
- kas andmebaas on homogeenne, st kas kõik andmebaasiserverid on samalt tootjalt (näiteks kõik serverid on ainult Oracle või kõik serverid on ainult DB2 UDB). Kui andmebaas ei ole homogeenne, siis millist tarkvara hakatakse kasutama erinevate tootjate (juba olemasolevate või spetsiaalselt projekti raames välja töötatud) DBMS-ide vahel andmete vahetamiseks;
- kas õige jõudluse saavutamiseks kasutatakse paralleelseid andmebaasiservereid (näiteks Oracle Parallel Server, DB2 UDB jne)?
Disainifaas lõpeb väljatöötamisega tehniline projekt ON.
Rakendusetapis luuakse süsteemitarkvara, installitakse riistvara ja töötatakse välja töödokumentatsioon.
Testimisfaas jaguneb tavaliselt aja peale.
