1

Artikkel on pühendatud haldusstruktuuridele rahalise toetuse saamiseks esitatavate investeerimisprojektide analüüsimiseks mõeldud infosüsteemi ülesehitamise küsimustele. Sellise süsteemi struktuur on teabekompleks, mis koosneb välismoodulist ja põhisüsteemist. Välismoodul on mõeldud projekti esmase teabe ettevalmistamiseks ja asub konkursil osaleva ettevõtte juures. Põhisüsteem analüüsib projekte ja asub halduskontrolli organis. Põhisüsteemi ülesehitus on suunatud investeerimisprojektide analüüsi tunnuste rakendamisele. Töös pakutakse välja ka investeerimisprojektide hindamise aluspõhimõtted ja metoodika. Projekti hindamiseks jagatakse paljud algnäitajad rühmadesse, mis iseloomustavad organisatsiooni finantsseisundi teatud aspekte. Siia kuuluvad ka täiendavad näitajad, mis on olulised territooriumi sotsiaalse, kultuurilise ja muu arengu seisukohalt. Sellega seoses võimaldab esitatud metoodika laenude eraldamise otsuse tegemisel järjestada investeerimisprojekte mitte ainult finantsnäitajate järgi, vaid võtta arvesse ka haldusorganisatoorse struktuuri prioriteete, mis ei ole otseselt seotud konkursil osaleva organisatsiooni majanduslik seisukord.

Infosüsteem

struktuur

metoodika

investeerimisprojekt

haldusstruktuuri

1. Brykin I.M., Beklemišev A.V. Investeerimisprojektide hindamine, valik ja analüüs. - M .: LLC "Rahvusvaheline meediagrupp", 2011. - 47 lk.

2. Bailey D.V., Sharp U.F., Alexander G.D. Investeeringud. – M.: INFRA-M, 2012. – 1028 lk.

3. Vilensky P.L., Livshits V.N., Smolyak S.A. Investeerimisprojektide tulemuslikkuse hindamine. Teooria ja praktika: Proc. Kasu. – M.: Delo, 2008. – 888 lk.

4. Kravtšenko T.K., Presnjakov V.F. Ettevõtte juhtimise - M.: Riikliku Ülikooli Majanduskõrgkool, 2003. - 272 lk.

5. Lipsits I.V., Kossov V.V. Investeeringute analüüs. Kinnisvarainvesteeringute ettevalmistamine ja hindamine. – M.: INFRA-M, 2014. – 320 lk.

6. Svetlov N.M., Svetlova G.N. Infotehnoloogiad projektijuhtimiseks - M.: INFRA-M, 2012. - 144 lk.

7. Shuremov E. Arvuti ärianalüüs. // Arvutimaailm. - 1998. - nr 1. - Lk 80–83.

Väikeettevõtluse valdkonna investeeringute pakkumise juhtimisotsuste tegemise tulemuslikkus turutingimustes sõltub suuresti ettevõtete finants- ja majandustegevuse analüüsimiseks kasutatavatest vahenditest. Haldusorganisatsiooni struktuuride analüüsivahendite valik on eriti oluline, kui projektile laenu andmise otsust ei tohiks mõjutada mitte ainult ettevõtte finantstulemused, vaid ka selle kontrolli all oleva haldusüksuse prioriteedid. organisatsiooniline struktuur.

Artiklis käsitletavad probleemid on seotud ettevõtte tegevuse analüüsimise süsteemide väljatöötamisega väliste organisatsioonide ning juhtimis- ja kontrollorganite poolt. Süsteemide eesmärk ei ole mitte ainult hinnata ettevõtte finants- ja majanduslikku olukorda, vaid ka võimalusi ja väljavaateid sellega suhtlemiseks või koostööks. Analüüsi infobaasi moodustavad ühel või teisel viisil standardarvestuse, statistilise aruandluse ja avatud allikatest saadud näitajad.

Olemasolevate finants- ja analüütiliste süsteemide hulgast võib välja tuua selliste ettevõtete arendused nagu Expert Systems, Galaktika, INEK, Alt-Invest, kuid nende tõhus kasutamine ilma haldusorganisatoorsete struktuuride muudatusteta on problemaatiline, kuna need süsteemid ei lahenda hindamisprojekti probleemid seoses parameetritega, mis on haldusstruktuuri jaoks prioriteetsed, kuid mitte rahalist laadi.

Infosüsteemi struktuur

Investeerimisprojektide voo kvalitatiivse analüüsi vajadus ja asjakohasus ning olemasolevad erinevused tavainvestori ja investori huvides haldusorganisatoorse struktuuri vormis muudavad instrumendi valiku probleemi selle arendamise tasandile. Samal ajal on soovitatav väljatöötatud süsteemile määrata järgmised ülesanded:

Ettevõtte finantsseisundi analüüs, sealhulgas dünaamikas;

Projekti äriplaani finantsosa analüüs;

Krediidi mõju analüüs ettevõtte finantsseisundile;

Projektide analüüsi protsessis linna prioriteetide arvestamine;

Mitme ettevõtte projektide võrdlev analüüs;

Ettevõtluse arengu ja laenude tagastamise prognoos.

Lähtudes püstitatud ülesannete omadustest ja olemusest on välja töötatud analüüsisüsteemi plokkskeem, mis on näidatud joonisel.

Süsteemi välismoodul on autonoomne programm, mis on mõeldud kavandatava projekti rahastamiseks laenu eraldamise otsuse tegemiseks vajaliku esialgse teabe ettevalmistamiseks:

Bilanss ja bilansi lisadokumendid;

Projekti äriplaani finantsosa;

Täiendav teave, mis on vajalik haldusorgani prioriteetide arvestamiseks.

Moodul võimaldab nii otsest teabe sisestamist klaviatuuri abil kui ka tööd teistest süsteemidest andmete importimise režiimis. Samal ajal kontrollib välismoodul sisestatud info õigsust, et välistada tahtmatud vead.

Süsteemi põhiosa ülesehitus on suunatud investeerimisprojektide analüüsi tunnuste rakendamisele.

Võtmeroll on “Töökeskkonna ja ekspertsüsteemi seadistamise moodulil”. Selles moodulis koostatakse erinevad analüüsistsenaariumid, määratakse täiendavad reeglid ja kriteeriumid, mis kajastavad linna ja administratsiooni huve ning määratakse finantssuhtarvude kriitilised väärtused.

"Finantsnäitajate arvutamise moodul" arvutab finantssuhtarvud.

Investeerimisprojektide analüüsi infosüsteemi struktuuriskeem

"Projekti analüüsi ja tulemuste visualiseerimise moodul" esitab analüüsi tulemused analüütiliselt, graafiliselt ja tabelina.

"Aruannete genereerimise moodul" on seotud standardtarkvaraga ja on mõeldud aruandlusmaterjalide koostamiseks.

Ekspertsüsteem on loodud abistama saadud tulemuste analüüsimisel.

Investeerimisprojektide analüüsi metoodika

Investeerimisprojektide analüüsi metoodika seisneb ettevõtte finantsseisundi terviklikus analüüsis koos investeerimisprojekti enda hinnanguga ja projekti reitingu määramisega edasiste laenude eraldamise otsuste tegemiseks.

Algnäitajaid on palju, mis on jagatud rühmadesse, mis iseloomustavad organisatsiooni finantsseisundi teatud aspekte. Need näitajate rühmad on koondatud eraldi dokumentidesse, näiteks raamatupidamisaruandesse vms.

Seega on algnäitajate L-rühmad , kus ja suhteliste näitajate L-rühmad , kus , l on rühma number ja kl on rühma näitaja järjekorranumber.

Primaarsete näitajate alusel moodustatakse sekundaarsete näitajate Q-rühmad, kus q = 1, Q, , ja mq on q-nda rühma näitaja järjekorranumber. Nimetame neid näitajaid koefitsientideks.

Näitajate ja nende muutumise dünaamika näitajate alusel moodustatakse tüübi absoluutsetes ja suhtelistes ühikutes.

kus j - iseloomustab indikaatori või koefitsiendi mõõtmiste arvu.

Iga näitaja ja koefitsient on fikseeritud mitmel ajahetkel. Saadud väärtused võimaldavad meil tuvastada näitajate ja koefitsientide muutuste dünaamikat aja jooksul:

Siis I = J + 1.

Koefitsientidele on seatud tingimused. Koefitsientide vastavus tingimustele näitab, et selle koefitsiendiga määratud ettevõtte finantsseisundi üldistatud tunnuste seisund on normaalne.

Ettevõtlusprojekti analüüsimise käigus lahendatakse vähemalt kolm põhiülesannet:

a) hinnang kõnealuse ettevõtte laenu tagasimaksmise võimalusele ja sellest tulenevalt otsus lisada see potentsiaalselt laenu andmiseks sobivate isikute nimekirja;

b) laenu andmise võimaluse hindamine, lähtudes administratsiooni prioriteetidest;

Neid ülesandeid lahendatakse koefitsientide ja näitajate mitmetasandilise analüüsi raames.

Analüüs viiakse läbi koefitsientide arvutamise ja tingimuste hindamisega. Koefitsiendid jagunevad rühmade sees suuremate ja vähemtähtsate alarühmadesse. Analüüsi esimene tase on seotud valitud koefitsientide alarühmade tingimuste täitmise hindamisega ja lahendab peamiselt probleemi

a) Teisel ja järgnevatel tasemetel analüüsitakse teisi koefitsiente ja näitajaid ning nende muutumise dünaamikat.

Analüüsi tulemused vormistatakse eraldi dokumentidena, mis iseloomustavad ettevõtte ja kavandatava projekti erinevaid aspekte.

Järgmises etapis kujundatakse projektile vastavalt esemele hinnang

b) Administratsiooni huvide arvestamiseks võetakse kasutusele täiendav näitajate (fh) ja tingimuste (χh) rühm, kus h = 1,H. Ettevõte saab neid näitajaid arvutada või esitada. Kui ettevõte ei vasta kriteeriumidele, arvatakse ta potentsiaalselt krediteeritavate hulgast välja.

a) kujunevad investeerimisprojektide reitingu määramise võimalused, mis on keskendunud hindamisele teatud valdkonna piires, näiteks toiduainete tootmise valdkonnas jne. Peamised erinevused valikute või nimetagem neid stsenaariumideks on järgmised:

Suhteliste näitajate ja koefitsientide rühmades eristatakse eraldi elemente, mida arvestatakse antud stsenaariumi projekti reitingu määramisel, s.o.

kus ζ on stsenaariumi number;

Valitud näitajate ja koefitsientide jaoks määratakse kaalud, mis iseloomustavad selle näitaja mõju reitingule selles rühmas, s.t. vastavalt

Samuti määratakse osakaalud reitingus osalevatele näitajate ja koefitsientide rühmadele, s.o. , kus d ζ on rühma arv ja D ζ on hindamises osalevate rühmade koguarv;

Kaalud on väiksemad kui 1, iga komplekti kaalude summa kogu valimi kohta on 1.

b) moodustatakse hinnatud projektide rühma jaoks parima ettevõtte versioon. Parima ettevõtte versioon on eelnevalt valitud näitajate kogum, millel on kogu komplekti parimad väärtused, s.o. nende näitajate väärtused võivad kuuluda erinevatele ettevõtetele. See versioon ei ole seotud reaalse objektiga ja seda kasutatakse hindamise eesmärgil. Kõik edasised suhtarvud reitingu hindamiseks on antud ainult koefitsientide kohta. Sarnased valemid konstrueeritakse parameetrite ja fh jaoks.

Seega moodustub näitajate kogum , kus , kui mida kõrgem , seda parem ja muidu. Siin on s loendis oleva ettevõtte number ja s-nda ettevõtte koefitsiendi väärtus.

kus , kui koefitsiendi kasv iseloomustab ettevõtte finantsseisundi paranemist ja

e) mida suurem on R ζ s, seda kõrgem on s-nda ettevõtte reiting ζ-nda hindamisstsenaariumi korral.

Normaliseerides (R ζ s) väärtusega, on võimalik järjestada ettevõtteid nende reitingu järgi kasvavas või kahanevas järjekorras. Hindamist indikaatorite ja fh järgi saab teha eraldi.

Järeldus

Esitatud metoodika võimaldab laenude eraldamise otsuse tegemisel järjestada investeerimisprojekte mitte ainult finantsnäitajate järgi, vaid võtta arvesse ka haldusorganisatoorse struktuuri prioriteete, mis ei ole otseselt seotud ettevõtte finantsseisundiga. konkursil osalev organisatsioon.

Seega on infosüsteem rakendudes võimas tööriist, mis ühendab endas tõhusad investeerimistegevuse valdkonna otsuste toetamise mehhanismid ning on suunatud nii ettevõtete finantsseisundi kui ka konkursile esitatud investeerimisprojektide analüüsi andmisele.

Bibliograafiline link

Klevtsov S.I., Klevtsova A.B. HALDUSSTRUKTUURIDE INVESTEERIMISPROJEKTIDE ANALÜÜSI INFOSÜSTEEMI MUDEL // Fundamentaaluuringud. - 2016. - nr 12-1. - lk 58-61;
URL: http://fundamental-research.ru/ru/article/view?id=41046 (juurdepääsu kuupäev: 26.04.2019). Juhime teie tähelepanu kirjastuse "Looduslooakadeemia" väljaantavatele ajakirjadele

Igal ettevõttel, ettevõttel, organisatsioonil on oma organisatsiooniline struktuur. See struktuur on mitmemõõtmeline ja jaguneb mitmeks omavahel seotud ja üksteisest sõltuvaks alamstruktuuriks, mida võib käsitleda iseseisvate struktuuridena, tootmisjuhtimisstruktuurina, personalistruktuurina, turundus-, finants-, majandus-, infostruktuuridena.

Kõik need on tihedas suhtluses ja just nende kombinatsioon loob ettevõtte organisatsioonilise struktuuri. Üks tähtsamaid kohti selles struktuuris on hõivatud infosüsteemiga. Põhimõtteliselt saab igasugust juhtimissüsteemi kujutada infosüsteemina, kus on erinevad infovood organisatsioonisiseselt suunatud dokumentide, korralduste, päringute näol, väliskeskkonnast väljaminevate või sissetulevatena.

Viimastel aastakümnetel on ühiskonnas üldiselt ja eelkõige ettevõttes kasutatava teabe maht hüppeliselt kasvanud. Selle põhjuseks on teaduse ja tehnoloogia kasvav arengutempo, uute tehnoloogiate esilekerkimine ja nende kiire käive. Tooraine- ja toodeteturgudel on välja kujunenud tingimused, mis nõuavad pidevat turu olukorra, selle muutuste ja arengusuundade jälgimist; Kõik see viib selleni, et tänapäevastes tingimustes peavad ettevõtete juhid tegelema nii suure teabehulgaga, see muutub nii kiiresti, et sageli muutub käsitsi töötlemine lihtsalt võimatuks. Lisaks on suurtes ettevõtetes, kus on suur kaubakäive ja töötajate arv, vajadus arvestada ja kontrollida suurt hulka finants-, tootmis-, personali-, ostu- ja turundusteavet, turundusteavet. Sellega seoses on vaja luua automatiseeritud süsteemid teabe kogumiseks, töötlemiseks ja säilitamiseks. Need peaksid hõlbustama ettevõttes ringleva teabega töötamist.

Arvutitehnoloogia tulek võimaldab selliseid süsteeme luua. Kaasaegsetes ettevõtetes on peaaegu kogu teabega töötamine automatiseeritud, on olemas spetsiaalsed programmid, mis võimaldavad teil arvutis pidada raamatupidamisarvestust, töövoogu, turundusuuringuid, prognoosimist ja strateegilist planeerimist ning palju muud. Kuid lisaks automatiseerimisele jääb aktuaalseks ka infosüsteemi struktuuri kompetentse ülesehitamise, infovoogude optimeerimise, mittevajaliku info väljasõelumise, otsingu lihtsustamise ja vajaliku info hankimise küsimus. Väljakujunenud automatiseeritud infosüsteemi olemasolu ettevõttes lihtsustab oluliselt ettevõtte juhtimist. See võimaldab vajalikku teavet õigeaegselt koguda, sorteerida, töödelda ja teha õige otsuse. Mõnikord võib teabe puudumise või mitteõigeaegse laekumise tõttu valel ajal tehtud otsus viia ettevõtte surmani. Seetõttu tuleb suurt tähelepanu pöörata ettevõtte infosüsteemi tõhusa toimimise loomisele ja säilitamisele.

Infosüsteemide ja automatiseeritud infosüsteemide teoorias kasutatavad põhimõisted on informatsioon, süsteem, infootsingusüsteem, automatiseeritud juhtimissüsteem, automatiseeritud töökoht. Info - alates lat. Informatio täpsustus, inimeste poolt algselt suuliselt, kirjalikult või muul viisil edastatud teabe esitamine alates 20. sajandi keskpaigast, üldteaduslik mõiste, mis hõlmab infovahetust inimeste, inimese ja automaadi, automaati ja automaat. Rühmasüsteem on teatud viisil korrastatud ja omavahel seotud elementide kogum, millel on stabiilne ühtsus, sisemine terviklikkus ja eksisteerimise autonoomia väliskeskkonnas. IPS-i teabeotsingusüsteem on tööriistade komplekt vajaliku teabe salvestamiseks, otsimiseks ja nõudmisel väljastamiseks, teabe otsimine IPS-i paigutamiseks toimub käsitsi või arvuti abil vastavalt teatud reeglitele ja vastavalt aktsepteeritud nõuetele. teabekeel. Automatiseeritud juhtimissüsteem ACS on matemaatiliste meetodite, arvutiriistvara, sidevahendite ja organisatsiooniliste komplekside kogum, mis tagab keeruka protsessiobjekti ratsionaalse juhtimise vastavalt etteantud eesmärgile. Automatiseeritud tööjaam AWS operaatori, dispetšeri, disaineri, tehnoloogi töökoht, mis on varustatud arvutitehnoloogiaga töötlemisprotsessi automatiseerimiseks ja tootmisülesande täitmiseks vajaliku teabe kuvamiseks. Viimasel ajal on ettevõtetes, erinevates organisatsioonides kasutatava teabe osatähtsus suurenenud. Võib öelda, et see on üks ressurssidest, mida ettevõtte tegevuses kasutatakse. Inforessursid erinevad aga oma omaduste poolest traditsioonilise materjali, energia, tehnoloogilise kontseptsiooni ressurssidest.

Erinevad teadlased on välja pakkunud erinevaid viise teabetoetuse klassifitseerimiseks. Seega on organisatsiooni ettevõtte ja keskkonnaga suhtlemise seisukohalt tavaks jagada kogu teave, peamiselt dokumentaalne, sissetulevaks ja väljaminevaks. Sõltuvalt säilitusajast eristatakse konstanti, tinglikult konstantset, mõnikord uuendatavat ja regulaarselt muutuvat muutujat. Info on jagatud ka tehase, tehasesisese, töökoja, kauplusesisese juhtimistasandite järgi. Tegevuse laadi, disaini ja tehnoloogiliselt. raamatupidamine, raamatupidamine ja aruandlus, planeerimine, turundus, personal, tootmine. Automatiseeritud süsteemides jaguneb infotugi masinapõhiseks arvutimälus ja masinaväliseks. Neid klassifikatsioone erinevates kombinatsioonides kasutatakse erinevate kirjade, korralduste, juhiste ja muude ettevõtete ja organisatsioonide praktilises tegevuses kasutatavate dokumentide indekseerimisel. Arengu ajalugu. Automatiseeritud infosüsteemide loomise ajaloos arenesid suhteliselt iseseisvalt kaks suunda: 1. automatiseeritud infosüsteemide AIS arendamine automatiseeritud juhtimissüsteemide automatiseeritud juhtimissüsteemidena 2. teadus- ja tehnikainfo automatiseeritud süsteemide arendamine ASNTI. Nende loomisega alustati peaaegu samaaegselt 60ndatel.

Esimene suund - AIS-i ja ACS-i arendamine - sai alguse teaduse ja tehnika arengust ning sellega seoses tekkinud organisatsioonijuhtimise probleemidest, teabehulga suurenemisest, raskustest selle käsitsi töötlemisel. Välispraktika käis eraldi tarkvaraprotseduuride väljatöötamise teed, näiteks raamatupidamiseks, materiaalsete varade arvestuseks ning põhitöö toimus arvutitehnoloogia võimekuse uurimise ja täiustamise suunas, töötades välja tööriistu, mis tagavad kõige ratsionaalsema korralduse. teabemassiivide, kasutajasõbraliku liidese ja arvuti mälu suurendamise. Meie riigis tõstatati kohe süstemaatiliselt probleem juhtivtöötajate teabega varustamisel. Töötati välja automatiseeritud juhtimissüsteemide klassifikaator, milles esiteks eristati juhtimissüsteemi erinevate tasemete automatiseeritud juhtimissüsteeme - ettevõtete ja organisatsioonide tasemel, valdkondlik, vabariiklik ja piirkondlik ning üleriigiline automatiseeritud süsteem.

Samamoodi ettevõtete ja eriti 70ndatel loodud ettevõtete tasandil. mittetulundusühingute teadus- ja tootmisliitude automaatjuhtimissüsteemide või ühenduste integreeritud automatiseeritud juhtimissüsteemide struktuuris eristati kihitasandid - ühingu automatiseeritud juhtimissüsteemid, ettevõtete ja teadusasutuste organisatsioonide automatiseeritud juhtimissüsteemid, projekteerimisbürood Mittetulundusühingud, tootmise automatiseeritud juhtimissüsteemid, töökodade kompleksid, töökodade ja objektide automatiseeritud juhtimissüsteemid. Töökodade ja sektsioonide tasandil jagunesid automatiseeritud juhtimissüsteemid esmalt tehnoloogiliste protsesside automatiseeritud juhtimissüsteemideks, tootmise tehnilise ja tehnoloogilise ettevalmistamise automatiseeritud juhtimissüsteemideks ning tootmise korraldamise automatiseeritud juhtimissüsteemideks. Töö tsentraliseeritud üleriigilise ACS ja ASNTI loomisel peatati seoses 19.–91. Turumajandusele, õigusriigile üleminekul suureneb aga teise olulise teabeliigi roll - juriidilise ja regulatiivse, metoodilise, ettevõtete tegevust reguleeriva, samas neile suurema iseseisvuse tagamise ning organisatsioonilise ja haldusliku dokumentatsiooni vähendamine. jooksvate tellimuste ja korralduste, auditeerimise käsu ja haldusjuhtimise meetodid. Tulevikus ettevõtete ja nende automatiseeritud juhtimissüsteemide arenedes, eriti seoses tööstuste ja töökodade suurema sõltumatuse tagamisega ning juhtimisfunktsioonide ümberjagamisega ettevõtte administratsiooni ning tootmis- ja töökodade juhtide vahel, muutus mugavamaks ka struktuuri esindamine. automatiseeritud juhtimissüsteemid mitmetasandilise, kihilisena. Automaatjuhtimissüsteemi jaotus funktsionaalseteks ja toetavateks osadeks ning viimaste - infotoeks, tehniliseks, organisatsiooniliseks, tarkvaraliseks ja muuks toeks - võimaldas kaasata nende valdkondade spetsialiste vastavate tugiliikide selgitamiseks. Selline lähenemine automatiseeritud juhtimissüsteemide arendamise korraldamisele aitas toime tulla süsteemi keerukusega ja kiirendada automatiseeritud juhtimissüsteemide väljatöötamist paralleelse töö kaudu teatud tüüpi toetuste struktuuri analüüsil ja valikul. Kui aga arendada eraldi projekte, siis pärast väljatöötamist on üsna keeruline ülesanne nende koordineerimine, seda tüüpi toetusliikide aktsepteeritud struktuuride omavaheline sidumine, nende väljatöötamisel arvessevõetavad kriteeriumid jne. Seetõttu sõnastati automatiseeritud juhtimissüsteemide loomise töö teatud etapis isegi teabetoe, riistvara ja tarkvara kui peamiste tugiliikide ühtsuse põhimõte. Praegu on tohutul hulgal valmis tarkvaratooteid. Seetõttu ei ole ettevõttes automatiseeritud süsteemi loomisel vaja tegeleda iseseisva tarkvaraarendusega. Inforessursside efektiivsuse hindamine. Erinevat tüüpi ja erinevat tüüpi teabeallikate puhul tundub nende hindamise probleem peaaegu lahendamatu.

Tõepoolest, kuidas võrrelda erinevat tüüpi teavet Millist teavet tuleks anda juhtidele, juhtidele, teadlastele, disaineritele, tehnoloogidele ja teistele ettevõtte töötajatele Kuidas teha kindlaks, millise teabe salvestamist ja otsimist on kõige olulisem automatiseerida. inforessursside kasutamise efektiivsust üldiselt.

Tootmismahtude kasv, toote- ja tehnoloogiavaliku uuendamise sagedus, kiiresti arenevate piirkondade, tootmissüsteemide ja mittetööstusliku sektori juhtimise keerukus on kaasa toonud infovoogude suurenemise ja keerukuse. Nendel tingimustel tekkis vajadus hinnata inforessursside kulusid, määrata nende panus tootmis-, haridus- ja muude süsteemide toimimise efektiivsusesse.

Erinevad infoteadused on püüdnud seda mõõta. Teadusliku ja tehnilise teabe teoorias teabevajaduste rahuldamise hindamiseks võetakse kasutusele asjakohasuse ja asjakohasuse mõõdikud. Asjakohasus viitab väljundi vastavusele päringule; asjakohasuse all - väljundi vastavust kasutaja vajadustele. Praktikas kasutatakse automatiseeritud juhtimissüsteemide teabemassiivide olulisuse hindamisel mõnikord ka kaudseid hinnanguid, nagu massiivile juurdepääsu sagedus, selle alusel koostatud dokumentide arv, teenindatavate osakondade arv, massiivide maht, jne kaudsed kvantitatiivsed omadused. Konkreetsete probleemide lahendamiseks annavad kaalutud teabe hindamise meetodid mõnikord üsna rahuldavaid tulemusi. Kogu teaberessursside kogumi hindamisel on aga soovitav võimalus võrrelda erinevat tüüpi teavet, et saada kui mitte üksainus mõõdik, siis vähemalt võrreldavad hinnangud erinevate teaberessursside kasulikkusele. tootmist või muud süsteemi, et infotoetuseks raha ratsionaalsemalt eraldada. Traditsioonilise kulumõõdiku rakendamine teaberessursside tõhususe hindamiseks on praktiliselt ebareaalne. Loomulikult on võimalik hinnata teatud tüüpi teabetoe salvestamise ja hankimise automatiseerimise majanduslikku efektiivsust ja tasuvusaega. Nende hinnangute põhjal ei saa aga hinnata teabe olulisust tootmis- või organisatsiooni juhtimissüsteemide täiustamisel, teabe kasulikkust teadusuuringute jaoks ja disainilahendusi. Lähtudes põhiideest kasutada komplekssete uuringute korraldamisel süsteemiesitusi, saab seada ülesandeks hinnata inforessursside tõhusust, kui ülesandeks hinnata nende mõju määra süsteemiahelate rakendamisele.

Sellise probleemipüstitusega on vaja lahendada kaks probleemi: 1 kujundada süsteemi peamiste arengusuundade eesmärkide struktuur, mis määravad selle tegevuse vastaval eksisteerimisperioodil, 2 valida lähenemine. info mõju määra hindamine eesmärkide saavutamisel. Organisatsiooni ettevõtte tegevuse analüüsi täielikkuse tagamiseks on eesmärkide struktuuri kujundamisel vaja rakendada eesmärkide ja funktsioonide struktureerimise meetodeid, mille valiku määrab eelnevalt välja töötatud selle arendamise kontseptsioon. Eesmärgile vastavuse määra hindamiseks saab kasutada tõenäosuslikku mõõdikut, st hinnata tõenäosust, et antud inforessurssi kasutatakse alaeesmärgi saavutamiseks. Selliseid hinnanguid võib saada hinnangutena suhtelise tähtsuse, inforessursi suhtelise panuse kohta vastava alaeesmärgi elluviimisel, kuid see tekitab probleemi, et sama info võib mõjutada rohkem kui ühte alaeesmärki. Võimalik on kasutada teabemõõtjat ressursi mõju määra kohta alaeesmärkide elluviimisel, mis võimaldab arvestada mitte ainult alaeesmärgi p saavutamise tõenäosusega, vaid ka tõenäosusega q, et seda teavet kasutatakse otsustaja alaeesmärgi elluviimisel. Infopotentsiaali H hindamine on mugavam kui suhtelise tähtsusega hinnangud, neid saab kokku võtta, arvestada saab lisaks p-le ka q-ga, infopotentsiaali mõistet tajuvad paremini juhtivtöötajad. Reaalsetes tingimustes saab kasutada keerukamaid meetodeid.

Miks mitte? See on hea näide. Projekt on projekt kõikjal: pluss-miinus samad etapid, sama juhtimisskeem, dokumendivoog, riskijuhtimine, kvaliteedikontroll jne. Kõikjal on nõuded nii seadmetele, ruumidele kui ka tarkvarale. Küsite, millised võivad olla nõuded ruumidele Infosüsteemis? Väga lihtne: operaatorite, serverite töökohtade asukoht - mõlemad vajavad kliimaseadet. Siin on nõuded ruumidele. Ja vaevalt, et keegi nüüd kahtleb, kas haigla vajab tarkvara. Kes tahab ajaga kaasas käia, seisab ees ülesandeks luua elektroonsete haiguslugudega automatiseeritud raviasutus, kus arstid teevad tablettidega uuringuid ja näiteks õed märgistavad pestud tualeti mitte lehele, vaid peale. telefoni. Sel juhul on palju tarkvaranõudeid. Ja niipea kui tarkvara on vaja, on vaja installida serverid, panna administraator ja operaatorid kuhugi. Kõik on omavahel seotud.

Valisime ehitusprojekti, kuna see on kõige lihtsam viis IC projekteerimise demonstreerimiseks. Infosüsteem on kuskil sees peidus, me ei näe seda, aga seinad on siin ees: kõverad ja viltused, tupikkoridoridega, sest projekt tehti põlve otsas ja isegi tellija muutis oma nõudeid etenduse käigus sada korda.

Programmi kood sees (kuid keegi ei näe seda)

Mis on haiglal sellega pistmist, kui me tarkvara arendame?

Aga ei, kallid arendajad, juhid, analüütikud, testijad.

Sa ei arenda tarkvara... Võtame Androidi, see on tarkvara. Ja kui teie ees on näiteks raamatupidamissüsteem, siis te ei tegele juba lihtsalt tarkvaraga, vaid INFOSÜSTEEMIGA.

Erinevus on ilmne. Kui ostsite telefoni, on kõik lihtne: lülitage see sisse, roheline mehike (Android) käivitub, kasutage seda. Ja kui olete ostnud raamatupidamistarkvaraga kasti, siis on selge, et nüüd on vaja servereid, peate seadistama võrgu, seadistama tööjaamad, koolitama töötajaid, integreerima süsteemi ülejäänud ettevõtte IS-iga ja juhtima süsteemi testrežiimis. Jah, ja raamatupidajaid tuleb ikka kuidagi veenda uuele tarkvarale üle minema, kõik pole uuendusteks valmis. Üldiselt on igas IT-projektis 10-20% IT ja kõik muu on organisatsioonilised ja administratiivsed meetmed ning väga tihe ehtetöö personaliga.

Infosüsteem (kas ainult tarkvara?)

Ja lõpuks tuletagem meelde süsteemi määratlust kaugetest 90ndatest, mida keegi pole tühistanud:

Automatiseeritud süsteem: süsteem, mis koosneb töötajatelt Ja vahendite kogum oma tegevuse automatiseerimiseks, mis rakendab infotehnoloogiat kehtestatud funktsioonide täitmiseks.

GOST 34.003-90. Infotehnoloogia. Automatiseeritud süsteemide standardite kogum. Automatiseeritud süsteemid. Tingimused ja määratlused.

See tähendab, et IP on esiteks inimesed, pluss tehnoloogia, mis aitab nende tegevusi automatiseerida, ja mitte vastupidi.

Kuidas haiglat kujundada

Kujutage ette, et olete ehitusorganisatsioon, teie juurde tuleb klient ja palub ehitada haigla sellisesse ja sellisesse kohta. Kas jooksed kohe telliseid laduma või ...? Kui vaadata, kuidas infosüsteeme sageli luuakse, siis see on tõsi: esinejad hakkavad kohe "betooni segama ja ostma topeltklaasid". Nagu, see ei lähe nii – me ehitame uuesti üles! Me ehitame uuesti üles, kuni saavutame soovitud tulemuse.

Kui oled aga tõsine organisatsioon, siis paku esmalt tellijale ehitusPROJEKT. Kas sa nõustud? Miks mitte Infosüsteemiga? Võib-olla pole asi ehituse ja tarkvaraarenduse erinevustes, vaid selles, et sama haigla puhul mõeldakse kõigepealt palju, planeeritakse ja siis ehitatakse, samal ajal kui esmalt arendatakse tarkvara ja siis mõeldakse? Kas pole sellepärast palju kuulda kõveratest programmeerijatest, aga mitte midagi samadest külalistöölistest ehitusplatsil? Erinevalt arendajatest töötavad ehitajad projekti kallal.

Ilma projektita on see alati selline, isegi kui sa seda ei näe

Vaatleme nüüd disainiprotsessi üksikasjalikumalt. Sellel on mitu etappi. Miks on vaja läbida mitu etappi, miks mitte teha seda korraga? Selguse huvides toon koolinäite ... Mitu aastat on nad koolis korrutamise toimimist uurinud? Ütlete - üks või kaks kuud ja te eksite põhimõtteliselt. Jah, kuidas korrutada 5-ga 6, läbida nädalaga. Teatud aja jooksul õpivad nad korrutustabelit. Ja kui palju nad uurivad murdude korrutamist, astmega arve, logaritme, sulgudes olevaid avaldisi, kompleksarve, astmeni tõstmist? Peaaegu kõik kooliaastad! Selgub, et uurime igal aastal sama korrutamist erinevate nurkade alt.
ami.

Miks seda esimeses klassis ei õpetata?

Seega on iga õppimise ja kujundamise protsess tsükliline. Kõigepealt saime selgeks arvude üldmõisted, seejärel õppisime nendega kõige lihtsamaid toiminguid tegema, seejärel õppisime murdude kohta ja nendega töötamist jne.

Esiteks saime aru, millise probleemi peaksime Infosüsteemi abil lahendama. Seejärel määrasime kindlaks lahendatavate ülesannete ringi, saime aru, MIDA süsteem peaks tegema, milliseid toiminguid personal peaks tegema. Seejärel määrasime kindlaks, KUIDAS peaks süsteem eelnevalt määratletud ülesandeid täitma. Võite need etapid vahele jätta, peate lihtsalt tagasi minema ja kõik uuesti tegema: seitse korda mõõtmine ja ühekordne lõikamine on palju kiirem kui vastupidi ja see võtab vähem materjali.

Võtame teise näite. Olete mäe otsas, vaatate läbi võimsa binokli alla ja proovite koostada üksikasjalikku laskumismarsruuti. Läbi okulaaride on näha iga teerajal olev kivi, iga lomp. Aga kas see tee on õige ja kas see viib tippu, seda binokliga ei näe: üldplaani pole. Mõistlik ronija joonistab esmalt palja silmaga välja laskumisrajad ja seejärel uurib neid tugeva suurendusega. Niipea, kui sukeldute detailidesse, kaotate projekti üldpildi. Võttes kohe teleskoobi, kirjeldate ideaalis 10 funktsiooni, unustades samal ajal umbes 40 muud funktsiooni, jättes need üldse mainimata.

See on hästi nähtav, kuid ainult väike osa

Etapikujunduse keerukus seisneb selles, et protsessi alguses tuleb opereerida abstraktsete mõistetega. Nii et soovite "tunnetada" midagi valmis, mitte rääkida teatud nõuetest, funktsioonidest, ülesannetest, protsessidest. Kohe kasutajaliidese joonistamine on lihtsam, kuid lihtsam on ka vähemalt pooltest nõuetest mööda lasta. Kui koostate esmalt üksikasjaliku loendi toimingutest, mida kasutaja peab konkreetse ekraanivormiga töötades tegema, peab disainer ainult joonistama, mitte fantaseerima, nagu sageli juhtub.

Liigume nüüd lõpuks disainietappide juurde.

1. Üldnõuete koostamine

Oletame, et olete disainer. Teie juurde tuleb klient, kelle "saadetavad" vastutustundlikud ehitajad. Klient palub teil loomulikult haiglaprojekti välja töötada. Jooksid joonestuslaua juurde ja... No see on juba iidne – käivita ArchiCAD ja joonista.

Aga see pole muidugi sinus. Olete professionaal ja hakkate esitama hunnikut "rumalaid" küsimusi. Ja kõige olulisem neist – miks on vaja haiglat ehitada. Mis on hoone otstarve. Kui eesmärk pole selge, siis ei oska vastata küsimusele, kas see peaks olema suur või väike haigla, mis profiil, mis on varustatud. Kahjuks räägivad kliendid sageli palju huvitavat, välja arvatud peamine – mis on nende eesmärk. See on see, mis tuleb sellest kõigepealt "välja tõmmata". Ja sa peaksid selle küsimuse esitama. Klient ise ei ole spetsialist, tal on idee ja ta näeb selles oma rolli täidetuna. Ta ei saa aru, mis teed tuleb oma idee elluviimiseks minna. Reeglina ootab klient vana head imet - tuleb mereranda, heidab võrku (maksab raha), püüab kala ja see täidab tema soovi ... Ja see juhtub nagu naljas. rikas mees, kes palus kuldkala püüdes täita ühe soovi: "Ma tahan kõike saada!" - "Pole probleemi," vastas kala, "teil oli kõik ..."

Projekti eesmärgi mõistmiseks ei piisa, kui teha paar lauset standardse fraasikomplektiga. Projekti eesmärk määratakse tavaliselt vastuseisu põhjal: kirjeldatakse olemasolevat infomudelit (näiteks istuvad inimesed arhiivis ja sorteerivad pabereid), seejärel selle puudujääke (automaatsuse puudumise tõttu on kaasatud 10 inimest arhiivis, mis on selgelt üleliigne, ei saa teised osakonnad seda nädalate kaupa arhiivist kätte vajalikku infot jne) ning pakuvad lahendust (võta kasutusele tarkvara, mis võimaldab teha mitmeid toiminguid automatiseeritud režiimis, toimingud peavad olema loetletud). Kui turule tuuakse täiesti uut tüüpi teenus, siis tuleb olemasolevat turgu uurida ja seal olemasolevaid tööriistu “kriitika teha”, seejärel lahendus välja pakkuda.

Lisaks on selles etapis vaja kindlaks teha, milliste juriidiliste nõuetega tuleb arvestada, kuidas teatud toiminguid juriidiliselt vormistada, kuidas uus teenus rahaks realiseeritakse, kuidas plaanitakse turule siseneda, kuidas välist huvi tekitada. uues süsteemis osalejad.

Teisisõnu peate looma ärimudeli. Ühest küljest pole see justkui arendajate ülesanne, kuid teisest küljest, ilma eesmärgi ja selle rakendamise meetodite selge määratlemiseta, pole selge, milliseid ülesandeid süsteem peaks lahendama. Ja kui klient ise pole veel selgelt sõnastanud, mida ta vajab, ei jää ta tõenäoliselt vähemalt mõne tulemusega rahule.

2. Süsteemi kontseptsiooni valik

Selles etapis on vaja valida üldtehnilised lahendused, millega on võimalik täita eelmises etapis koostatud nõudeid. Kas see on veebirakendus või natiivne, paks klient või õhuke, tsentraliseeritud andmebaas või hajutatud, relatsiooniline DBMS või noSQL, monoliit või mikroteenused, Java või Python. Sageli unustatakse need küsimused õigel ajal arutada ja siis selgub, et üks programmeerijatest valis iseseisvalt teatud tööriista ja lõpuks ei võimalda see otsus eesmärki saavutada.

3. Lähteülesannete väljatöötamine

Tegime haiglale üldnõuded, valisime kontseptsiooni. "Noh," ütleb klient, "nüüd on kõik selge, saate joonistada." Kas see on võimalik? Nõuded on üldised, neid tuleb täpsustada. Näiteks tegite esimese sammuna kindlaks, et peaks olema verelabor. Aga mis aparatuur sinna tuleb, kui palju kulub elektrit, suruõhku (mis siis, kui?), kas on vaja desinfitseerimiseks kvartslampe, laborilaudu, ventilatsiooni? Ilma selleta on seda raske kujundada. See on esimene. Ja teiseks on vaja ette kirjutada plaan haigla ehitamiseks, selle koostamiseks ja kasutuselevõtuks.

Infosüsteemi jaoks on TK () arendamine projekti keskne osa. kirjeldab:

1. MIDA süsteem peaks tegema.
2. Milline peaks olema süsteemi üldine struktuur.
3. Kuidas süsteemi luua.

See tähendab, et TOR sisaldab funktsionaalseid ja mittefunktsionaalseid nõudeid, samuti nõudeid väljatöötamise, vastuvõtmise ja dokumenteerimise etappidele. Samuti peaks TOR lühidalt kirjeldama protsesse, mida me tegelikult automatiseerime.

Süsteemi (ja see on TOR-i keskne osa) funktsioonide kirjeldamisel tuleb mõista, et esitame nõuded MIDA süsteem peaks tegema, mitte KUIDAS. Laius peaks olema teile olulisem kui sügavus. Näiteks tuvastasime esimeses etapis (üldnõuete koostamine) vajaduse funktsiooni kasutaja sisselogimise blokeerimiseks. TOR näitas, et konto blokeeritakse, kui seda ei kasutata 90 päeva või pärast 6 ebaõnnestunud sisselogimiskatset, juurdepääsu saab administraator teatud perioodiks piirata, kui blokeeritud kasutaja proovib sisse logida, tuleb kuvada teade jne. Ja tehnilises projektis (eesjooksvas) joonistame kasutajakaardi paigutuse luku lipu ja avamiskuupäevaga, loome sisselogimisskripti, mis kontrollib luku olemasolu, avab automaatselt lukust määratud aja möödudes ja lukustab ebaõnnestunud sisselogimise korral katsed; Määratleme, mida tehakse kliendi ja mida serveri poolel.

Tahaksin ümber lükata mõned müüdid, mis on seotud .

Esimene müüt: TOR sisaldab nõudeid ainult töövõtjale.

Ei, TOR on see, kuidas süsteemi luua ja lähteülesandes on jaotised, kus saate kirjeldada vastutuse jaotust.

4. Tehnilise projekti väljatöötamine

Nii et lähme edasi. Siin on teie ees (oletasime, et olete projekteerija) haigla ehitamise lähteülesanne koos tohutu nõuete loeteluga. Istud, vaatad kurvalt 100 lehekülge TK-d ja ei tea, kust alustada. Siis hakkab pilt tasapisi selginema. Mõtled: jah, meil on nii palju meetreid vaja palatitesse, nii palju kööki, nii palju puhkealasse, laborisse, hooldusruumidesse jne jne. Siis tuleb palju visandeid, visandeid, variante päevavalgele, teed ümber, vahetad kohad, ühesõnaga otsid optimaalseid suhteid. Seejärel minge detailide juurde - joonised, joonised, joonised: seinad, uksed, aknad, kaabelkanalid, juhtmestik, torud, ventilatsioon, põrandatevahelised laed, seinamaterjalid, viimistlus ... ja nii edasi, ja nii edasi jne. Üldiselt kirjeldage võimalikult üksikasjalikult, kuidas haigla peaks pärast ehituse lõppu välja nägema ja toimima.

Infosüsteemi tehnilise projekti väljatöötamisel on vaja dokumente, mis sisaldavad järgmist: üksikasjalikud stsenaariumid, mis kirjeldavad arendatava süsteemi, kasutajate ja seotud süsteemide toimimist ja koostoimet; üksikasjalikud kasutajaliidese paigutused, mis sisaldavad iga liidese elemendi andmetüübi ja käitumise kirjeldust (vaikeväärtus, tingimused, mille korral saab välja väärtust muuta, nähtavus, süsteemi toimingud elemendi muutumisel jne); seotud süsteemide ja seadmetega integreerimise protokollide kirjeldus, aruannete vormid ja nende genereerimisalgoritmi kirjeldus, serverite ja andmebaaside struktuur, kui neid on mitu.

Tavaliselt on see enam kui piisav, et arendajatele dokumente anda ja mõistlik tulemus saada. Üksikasjalikud paigutused ja skriptid annavad piisavalt teavet süsteemi ja liidese käitumise ning andmestruktuuri kohta. Arendajad asetatakse jäigasse raamistikku, milles saate fantaseerida, kuid siis ei pääse te välja.

Loodan, et järgmistes artiklites vaatleme lähemalt, kuidas teostada kvaliteetset tehnilist projekteerimist, kuidas välja töötada skeeme, stsenaariume, milliseid dokumente on vaja vormistada.

5. Töödokumentatsiooni väljatöötamine

Loogiline küsimus on, milline on haigla töödokumentatsioon? Kas tõesti juhised koridori puhastamiseks ?! Nali naljaks, kas tuletõrjesüsteem vajab hooldust? Vajalik. Ja liftid? Aga arvutivõrgud? Ja torustik? "No see pole haiglaprojektiga seotud!" - sa ütled. Jah, see on osaliselt tõsi. Küll aga antakse haigla rendile kliendile tervikuna ning kõikidel süsteemidel peab olema vastav tegevusdokumentatsioon. Ja selleks, et kohaletoimetamine oleks kiire, edukas, koostate nimekirja nõuetest, mille ees saate kontrollida, kas kõik on korras.

IS-i kasutaja- ja administraatorijuhendite olemasolu on standard, sellega on kõik selge. Kuid süsteemi kliendile üleandmise ja vastuvõtmise protsessile mõeldakse sageli viimasel hetkel. Ja asjata. Selleks on olemas suurepärane dokument "Programm ja katsemeetodid", mis on tavaliselt seotud ka töödokumentidega. See on omamoodi kontrollnimekiri, mis sisaldab kontrolliprotseduuride kirjeldust. Kui see dokument on eelnevalt koostatud (ja stsenaariumi saab laenata tehnilisest projektist), on arendajatel oma töö vastuvõtmiseks selge kriteerium. Sul ei ole vaja oma või allhankega programmeerijaid, et tõestada, et sul on õigus – skript on olemas, see tuleb välja töötada. Ja kliendiga probleeme ei teki - fantaasiat piirab juba dokument.

Kus siin Agile koht on?

Mõned inimesed on kõik Agile'i (või muude "agiilsete" arendusmeetodite) poolt, teised aga on selle vastu. Artikli autoril on oma arvamus: Agile on väga hea, aga kohatu. Ja tavaliselt kasutavad nad seda muudel eesmärkidel.

Öelge mulle, Agile lovers, kas selle tehnoloogia abil on võimalik kindlaks teha arenduse lõpus saadav tulemus, maksumus ja ajastus? Ei? No kui palju lolle kliente leiad, kes ebaselge tulemuse, eelarve ja kestusega töösse kaasa löövad? Kas telliksite Agile meeskonnale korteriremondi? Seega Agile’il on koht, kus olla, aga siseprojektide jaoks. Remonti võid ise teha nii palju kui soovid ja kõik mitu korda üle vaadata. Välisklientide jaoks on see pettus, mida nimetatakse nutika terminiga (te muidugi ei nõustu selle sõnastusega, kuid proovige klienti selles veenda).

Klient mõtleb: ja kui palju nad mind veel ninapidi ringi juhivad?

Teiseks on Agile hea innovatsioonis, kus pole selge, millist tulemust nõutakse või pole selge, kuidas seda saavutada. Seda nimetatakse teadus- ja arendustegevuseks, arendustegevuseks. Või isegi teadus- ja arendustegevus – teadus- ja arendustöö. Igas tehases on eksperimentaalne töökoda, kus failiga, mitu korda ümber töötades, saadakse prototüübid. Kujutage ette, et peate puuteekraani, kõik žestid ja käitumise ümber kujundama. Siin peaksite tõesti proovima ja proovima, te ei saa käitumist ette kirjeldada. Aga kui sageli teil selliseid ülesandeid ette tuleb? Tuleb eristada inseneriarendust ja teadustööd. Põhimõtteliselt oleme infosüsteemide insenerid.

Kolmandaks, suures projektis võib olla etappe, kus OCD on vajalik ja siis aitab Agile. Sprintide kasutamist operatiivplaneerimise tasandil keegi ei sega. Vastupidi, väga mugav tehnoloogia: planeeri nädal või paar ja jälgi pidevalt tulemust. Strateegilisel tasandil - kaskaadplaneerimine, taktikalisel - iteratiivne. Ja ei mingeid vastuolusid!

Kahjuks üritavad arendajad väga sageli Agile'i "jutlustades" varjata oma suutmatust süsteemi disaini välja töötada (või isegi ei tea, et see on võimalik). Nad toimivad neile kõige mugavamal viisil: viimistleme ja viimistleme kliendi raha eest. Niikaua kui keegi kulusid ei kontrolli, saate sellest pääseda. Aga siis võib välisvaatlejal (ülemustel) tekkida tunne, et protsess on olemas, aga lõpp ja serv ning tulemust pole näha. Proovige vaadata mitte ainult oma kellatornist.

Kust ma saan infosüsteemide disaini kohta lisateavet?

Sellel teemal on palju raamatuid. Paks ja mitte nii paks. Aga raamat on alati kellegi teise kogemus. Ja teil on teistsugune iseloom, suurepärane olukord ja projekt. On olemas selline TRIZ-süsteem – leidliku probleemide lahendamise teooria. Selle autor Altshuller püüab selgitada samme, mida millegi leiutamiseks astuda. Selgub? Reeglina ei. Põhimõtted on välja toodud huvitavad, kasulikud, kuid ühest leiutisekohast malli ei tule välja. Iga inimene mõtleb ja loob omamoodi ning seda on võimatu õpetada, saab ainult õppida. Kellegi teise kogemust on vaja kasutada, seda on rumal mitte kasutada, vaid see tuleb endal kogeda (töötleda), kanda üle OMA mõtlemisse. Sa ei saa imet kopeerida.

Sildid: lisa sildid

Infosüsteemide projekteerimine

Osa 1. Projekti arendamise etapid: strateegia ja analüüs

Sissejuhatus "Waterfall" - projekti arendamise skeem strateegia Analüüs ER diagrammid kaared Normaliseerimine Andmevoo diagrammid Mõned põhimõtted teabemudeli kvaliteedi ja täielikkuse kontrollimiseks Üksuse kvaliteet Atribuudi kvaliteet Ühenduse kvaliteet Süsteemi funktsioonid Strateegia täpsustamine

Sissejuhatus

Infosüsteemide projekteerimine algab alati projekti eesmärgi määratlemisest. Iga eduka projekti peamine ülesanne on tagada, et süsteemi käivitamise ajal ja kogu selle tööperioodi jooksul on võimalik pakkuda:

süsteemi nõutav funktsionaalsus ja kohanemisaste selle muutuvate toimimistingimustega;

nõutav süsteemi läbilaskevõime;

süsteemi nõutav reageerimisaeg päringule;

süsteemi tõrgeteta töö vajalikus režiimis ehk teisisõnu süsteemi valmisolek ja kättesaadavus kasutajate päringute töötlemiseks;

süsteemi töö lihtsus ja tugi;

vajalik turvalisus.

Jõudlus on peamine tegur, mis määrab süsteemi tõhususe. Hea disain on suure jõudlusega süsteemi alus.

Infosüsteemide projekteerimine hõlmab kolme põhivaldkonda:

andmebaasis realiseeritavate andmeobjektide kujundamine;

programmide, ekraanivormide, aruannete kujundamine, mis tagavad andmepäringute täitmise;

võttes arvesse konkreetset keskkonda või tehnoloogiat, nimelt: võrgu topoloogia, riistvara konfiguratsioon, kasutatav arhitektuur (failiserver või klient-server), paralleeltöötlus, hajutatud andmetöötlus jne.

Reaalsetes tingimustes on projekteerimine süsteemi funktsionaalsuse nõudeid rahuldava viisi otsimine olemasolevate tehnoloogiate abil, arvestades etteantud piiranguid.

Igale projektile kehtivad mitmed absoluutsed nõuded, näiteks maksimaalne projekti arendusaeg, maksimaalne rahaline investeering projekti jne. Üks projekteerimise raskusi on see, et see ei ole nii struktureeritud kui projekti nõuete analüüs või konkreetse projekteerimislahenduse elluviimine.

Arvatakse, et keerulist süsteemi ei saa põhimõtteliselt kirjeldada. See puudutab eelkõige ettevõtte juhtimissüsteeme. Üheks peamiseks argumendiks on süsteemi toimimise tingimuste muutmine, näiteks teatud infovoogude direktiivne muutus uue juhtkonna poolt. Teine argument on lähteülesande ulatus, mis suure projekti puhul võib olla sadu lehekülgi, samas kui tehniline projekt võib sisaldada vigu. Tekib küsimus: võib-olla on parem mitte üldse küsitlusi läbi viia ja tehnilist projekti mitte teha, vaid kirjutada süsteem "nullist" lootuses, et kliendi soov on mingi imeline kokkulangevus programmeerijate kirjutatuga, ja ka seda, et see kõik stabiilselt toimiks?

Kui vaadata, siis kas tõesti on süsteemi areng nii ettearvamatu ja kas tõesti on võimatu selle kohta infot saada? Tõenäoliselt saab seminaride kaudu aimu süsteemist kui tervikust ja selle arendamiseks kavandatud viisidest (juhtimisest). Seejärel purustage keeruline süsteem lihtsamateks komponentideks, lihtsustage komponentide omavahelisi seoseid, tagage komponentide sõltumatus ja kirjeldage nendevahelisi liideseid (nii et ühe komponendi muutus ei tooks automaatselt kaasa olulist muutust teises komponendis) , samuti süsteemi laiendamise võimalus ja funktsioonide süsteemi ühes või teises versioonis realiseerimata "stubs". Sellistele elementaarsetele kaalutlustele tuginedes ei tundu infosüsteemis rakendatava kirjeldus enam nii ebareaalne. Infosüsteemide arendamiseks saate järgida klassikalisi lähenemisviise, millest üks on "kose" skeem ( riis. 1) on kirjeldatud allpool. Põgusalt vaadeldakse ka mõningaid teisi lähenemisi infosüsteemide arendamiseks, kus on vastuvõetav ka "kose" skeemis kirjeldatud elementide kasutamine. Millist lähenemist allpool kirjeldatutest järgida (ja kas on mõtet oma lähenemist välja mõelda), on mingil määral maitse ja asjaolude küsimus.

Riis. 1. Kose skeem

Tarkvara elutsükkel on selle loomise ja kasutamise mudel. Mudel peegeldab selle erinevaid olekuid, alustades hetkest, mil vajadus selle tarkvara järele tekib ja lõpetades hetkega, mil see on kõikide kasutajate jaoks täielikult kasutusest väljas. Tuntud on järgmised elutsükli mudelid:

kaskaadmudel. Üleminek järgmisele etapile tähendab töö täielikku lõpetamist eelmises etapis.

Lavastatud mudel vahepealse juhtimisega. Tarkvaraarendus toimub iteratsioonidena koos etappidevahelise tagasisideahelaga. Etappidevahelised kohandused võivad vähendada arendusprotsessi keerukust võrreldes kosemudeliga; iga etapi eluiga venitatakse kogu arendusperioodiks.

spiraalne mudel. Erilist tähelepanu pööratakse väljatöötamise algfaasidele - strateegia väljatöötamisele, analüüsile ja kujundamisele, kus kontrollitakse ja põhjendatakse teatud tehniliste lahenduste teostatavust prototüüpide loomise (prototüüpimise) kaudu. Iga spiraali pööre hõlmab toote või selle mistahes komponendi teatud versiooni loomist, kusjuures täpsustatakse projekti omadused ja eesmärgid, määratakse selle kvaliteet ning kavandatakse spiraali järgmise pöörde tööd.

Allpool käsitleme mõningaid projekti arendamise skeeme.

Alguse juurde

"Waterfall" - projekti arendamise skeem

Väga sageli kirjeldatakse disaini kui eraldiseisvat projekti arendamise etappi analüüsi ja arenduse vahel. Tegelikkuses pole aga projekti arendusetappide vahel selget jaotust – projekteerimisel ei ole reeglina selgelt määratletud algust ja lõppu ning see jätkub sageli testimise ja juurutamise etapis. Rääkides testimisetapist, tuleb veel märkida, et nii analüüsietapp kui ka projekteerimisetapis sisaldavad elemente testijate tööst, näiteks et saada eksperimentaalset põhjendust konkreetse lahenduse valimiseks, samuti hinnata kvaliteedikriteeriume. saadud süsteemist. Käitamisetapis on asjakohane rääkida süsteemi hooldusest.

Allpool käsitleme kõiki etappe, käsitledes üksikasjalikumalt projekteerimisetappi.

Alguse juurde

strateegia

Strateegia määratlemine hõlmab süsteemi uurimist. Küsitluse põhiülesanne on hinnata projekti tegelikku ulatust, selle eesmärke ja eesmärke, samuti saada kõrgel tasemel üksuste ja funktsioonide määratlusi.

Selles etapis on kaasatud kõrgelt kvalifitseeritud ärianalüütikud, kellel on pidev juurdepääs ettevõtte juhtkonnale; etapp hõlmab tihedat suhtlemist süsteemi peamiste kasutajate ja äriekspertidega. Interaktsiooni põhiülesanne on hankida süsteemi kohta võimalikult täielik teave (täielik ja ühemõtteline arusaam kliendi nõudmistest) ning edastada see teave formaliseeritud kujul süsteemianalüütikutele järgnevaks analüüsietapiks. Reeglina saab infot süsteemi kohta juhtkonna, ekspertide ja kasutajatega peetud vestluste või seminaride tulemusena. Seega määratakse kindlaks selle ettevõtte olemus, selle arendamise väljavaated ja süsteemile esitatavad nõuded.

Süsteemiuuringu põhietapi lõppedes kujundavad tehnikud tõenäolised tehnilised lähenemisviisid ja hindavad riistvara, ostetud tarkvara ja uue tarkvara väljatöötamise kulusid (mis tegelikult eeldab projekt).

Strateegia määratlemise etapi tulemuseks on dokument, milles on selgelt kirjas, mida klient saab, kui ta nõustub projekti rahastama; millal ta valmistoote kätte saab (töögraafik); kui palju see maksma läheb (suurprojektide puhul tuleks koostada rahastamise ajakava erinevates tööetappides). Dokument peaks kajastama mitte ainult kulusid, vaid ka tulusid, näiteks projekti tasuvusaega, eeldatavat majanduslikku efekti (kui seda on võimalik hinnata).

Dokumendis tuleb kirjeldada:

piirangud, riskid, projekti edukust mõjutavad kriitilised tegurid, näiteks on süsteemi päringule vastamise aeg etteantud piirang, mitte soovitav tegur;

tingimuste kogum, mille alusel ta peaks tulevase süsteemi opereerima: süsteemi arhitektuur, süsteemile antavad riist- ja tarkvararessursid, selle toimimise välistingimused, inimeste koosseis ja töö, mis tagavad süsteemi tõrgeteta toimimise;

üksikute etappide läbimise tähtajad, tööde teostamise vorm, projekti arendamise protsessi kaasatud ressursid, teabe kaitsmise meetmed;

süsteemi poolt täidetavate funktsioonide kirjeldus;

tulevased nõuded süsteemile selle arendamise korral, näiteks kasutaja võimekus töötada süsteemiga Internetti kasutades jne;

süsteemi funktsioonide täitmiseks vajalikud üksused;

liidesed ja funktsioonide jaotus isiku ja süsteemi vahel;

nõuded tarkvarale ja tarkvara infokomponentidele, nõuded DBMS-ile (kui projekt peaks olema rakendatud mitmele DBMS-ile, siis nõuded igaühele neist või üldised nõuded abstraktsele DBMS-ile ja selle projekti jaoks soovitatavate DBMS-ide loetelu, vastama kindlaksmääratud tingimustele);

mida projekti raames ei rakendata.

Selles etapis tehtud töö võimaldab meil vastata küsimusele, kas seda projekti tasub jätkata ja milliseid kliendi nõudeid on võimalik teatud tingimustel täita. Võib selguda, et projekti ei ole mõtet jätkata näiteks seetõttu, et teatud nõudeid ei saa mingitel objektiivsetel põhjustel täita. Kui tehakse otsus projektiga edasi minna, siis on analüüsi järgmiseks etapiks juba ettekujutus projekti mahust ja maksumusest.

Tuleb märkida, et strateegia valimise etapis ja analüüsi etapis ning projekteerimisel, olenemata projekti väljatöötamisel kasutatud meetodist, tuleks süsteemi kavandatavad funktsioonid alati tähtsuse järjekorras klassifitseerida. . Ühe võimaliku vormingu sellise klassifikatsiooni esitamiseks MoSCoW pakkusid välja Clegg, Dai ja Richard Barker, Case Method Fast-track: A RAD Approach, Adison-Wesley, 1994.

See lühend tähistab: Must have – vajalikud funktsioonid; Peaks omama - soovitavaid funktsioone; Võiks olla - võimalikud funktsioonid; Ei ole – puuduvad funktsioonid.

Teise ja kolmanda kategooria funktsioonide elluviimist piirab aja- ja finantsraamistik: arendame välja nii vajaliku kui ka maksimaalse võimaliku arvu teise ja kolmanda kategooria funktsioone prioriteetsuse järjekorras.

Alguse juurde

Analüüs

Analüüsietapp hõlmab äriprotsesside (strateegia valiku etapis määratletud funktsioonid) ja nende rakendamiseks vajaliku teabe (üksused, nende atribuudid ja seosed (suhted)) üksikasjalikku uurimist. Selles etapis luuakse teabemudel ja järgmises projekteerimisetapis luuakse andmemudel.

Kogu strateegia määratlemise etapis kogutud teave süsteemi kohta vormistatakse ja täpsustatakse analüüsi etapis. Erilist tähelepanu tuleks pöörata edastatava teabe täielikkusele, teabe analüüsile vastuolude puudumisel, samuti teabe otsimisel, mida ei kasutata või mida dubleeritakse. Klient ei kujunda reeglina kohe nõudeid süsteemile kui tervikule, vaid sõnastab nõuded selle üksikutele komponentidele. Pöörake tähelepanu nende komponentide järjepidevusele.

Analüütikud koguvad ja salvestavad teavet kahel omavahel seotud kujul:

funktsioonid - teave äritegevuses toimuvate sündmuste ja protsesside kohta;

entiteedid - teave asjade kohta, mis on organisatsiooni jaoks olulised ja mille kohta on midagi teada.

Kaks klassikalist analüüsitulemust on:

funktsioonide hierarhia, mis jaotab töötlemise selle komponentideks (mida tehakse ja millest see koosneb);

olemi-suhte mudel (Entry Relationship model, ER-mudel), mis kirjeldab olemite, nende atribuute ja nendevahelisi seoseid (suhteid).

Need tulemused on vajalikud, kuid mitte piisavad. Piisavate tulemuste hulgas on andmevoo diagrammid ja olemi elutsükli diagrammid. Üsna sageli tekivad analüüsivead, kui püütakse näidata olemi elutsüklit ER diagrammil.

Allpool käsitleme kolme kõige sagedamini kasutatavat struktuurianalüüsi metoodikat:

Entity-Relationship Diagrams (ERD), mille eesmärk on vormistada teavet üksuste ja nende suhete kohta;

andmevoo diagrammid (Data Flow Diagrams, DFD), mille eesmärk on vormistada süsteemi funktsioonide esitus;

oleku ülemineku diagrammid (State Transition Diagrams, STD), mis kajastavad süsteemi käitumist olenevalt ajast; Sellesse diagrammide klassi kuuluvad olemi elutsükli diagrammid.

Alguse juurde

ER diagrammid

ER diagrammid ( riis. 2) kasutatakse andmete kujundamiseks ja on standardne viis andmete ja nendevaheliste suhete määratlemiseks. Seega toimub andmeladude detailiseerimine. ER-diagramm sisaldab teavet süsteemi olemite ja nende koostoime kohta, sisaldab teemavaldkonna jaoks oluliste objektide (olemite) tuvastamist, nende objektide omadusi (atribuute) ja nende seoseid teiste objektidega (lingid). Paljudel juhtudel on teabemudel väga keeruline ja sisaldab palju objekte.

Riis. 2. ER diagrammi näide

Olem kuvatakse ristkülikuna, mille ülaosas on olemi nimi (nt TITLES). Kastis saab loetleda olemi atribuudid; ER-diagrammide atribuudid, mis on trükitud paksus kirjas, on võtmetähtsusega (seega on pealkirja identiteet olemi TITLES võtmeatribuut, muud atribuudid ei ole võtmed).

Seost kujutab joon kahe olemi vahel (joonisel sinised jooned).

Üks rida paremale ( riis. 3) tähendab "üks", "linnujalg", vasakul on "palju" ja seost loetakse mööda rida, näiteks "üks paljudele". Vertikaalne riba tähendab "kohustuslikku", ring tähendab "valikulist", näiteks iga väljaande puhul tuleb jaotises TITLE märkida väljaandja väljaandes PUBLISHERS ja üks väljaandja jaotises PUBLISHERS saab TITLESis avaldada mitu pealkirja. Tuleb märkida, et lingid on alati kommenteeritud (silt linki kujutaval real).

Riis. 3. ER diagrammi element

Toome ka näite ( riis. 4) kujutisi peegeldavast suhtest "töötaja", kus üks töötaja saab juhendada mitut alluvat ja nii edasi ametikohtade hierarhias allapoole.

Riis. 4. Refleksiivse seose ER-diagramm

Pange tähele, et selline seos on alati valikuline, vastasel juhul oleks see lõpmatu hierarhia.

Olemi atribuudid võivad olla võtmetähtsusega – need on paksus kirjas; kohustuslik - neile eelneb märk "*", see tähendab, et nende väärtus on alati teada, valikuline (valikuline) - neile eelneb O, see tähendab, et selle atribuudi väärtused võivad mingil hetkel olla puudub või on määratlemata.

Alguse juurde

kaared

Kui olemil on hulk üksteist välistavaid suhteid teiste üksustega, siis öeldakse, et sellised suhted on kaarekujulised. Näiteks pangakonto saab väljastada kas juriidilisele isikule või eraisikule. Seda tüüpi suhete ER-diagrammi fragment on näidatud riis. 5.

Riis. 5. Kaar

Sel juhul on KONTO olemi atribuudil OWNER selle olemi jaoks eriline tähendus - olem jagatakse kategooriate kaupa tüüpideks: "füüsilise isiku jaoks" ja "juriidilise isiku jaoks". Saadud üksusi nimetatakse alamtüüpideks ja algsest olemist saab supertüüp. Et mõista, kas supertüüpi on vaja või mitte, on vaja kindlaks teha, kui paljudel samadel omadustel on erinevad alatüübid. Tuleb märkida, et ala- ja supertüüpide kuritarvitamine on üsna tavaline viga. Neid on kujutatud joonisel näidatud viisil riis. 6.

Riis. 6. Alamtüübid (paremal) ja supertüübid (vasakul)

Alguse juurde

Normaliseerimine

Andmetöötluse anomaaliate vältimiseks kasutatakse normaliseerimist. Infomudeli objektide normaliseerimise põhimõtted on täpselt samad, mis andmemudelite puhul.

Lubatud lingitüübid. Lähemal uurimisel võib öelda, et üks-ühele suhted ( riis. 7) selgub peaaegu alati, et A ja B on tegelikult sama asja erinevad alamhulgad või erinevad vaatepunktid, millel on lihtsalt erinevad nimed ning erinevalt kirjeldatud seosed ja atribuudid.

Riis. 7. Üks-ühele suhted

Mitmed-ühele suhted on näidatud riis. 8.

Riis. 8. Mitu-ühele suhted

I on piisavalt tugev konstruktsioon, et olemi B kirjet ei saa luua ilma olemi A vähemalt ühte seotud kirjet loomata.

II on kõige levinum suhtlusvorm. See eeldab, et iga olemi A esinemine saab eksisteerida ainult ühe (ja ainult ühe) olemi B esinemise kontekstis. B esinemised võivad omakorda eksisteerida nii seoses A esinemistega kui ka ilma selleta.

III - harva kasutatud. Nii A kui ka B võivad eksisteerida ilma nendevahelise ühenduseta.

Paljud-mitmele suhted on näidatud riis. 9.

Riis. 9. Paljud-mitmele suhted

I - selline konstrueerimine toimub sageli analüüsietapi alguses ja tähendab seost - kas pole täielikult mõistetud ja vajab lisaluba või peegeldab lihtsat kollektiivset suhet - topeltseotud loetelu.

II - harva kasutatud. Selliseid linke tuleb alati täpsustada.

Mõelge nüüd rekursiivsetele linkidele ( riis. 10).

Riis. 10. Rekursiivsed lingid

I - haruldane, kuid esineb. Peegeldab alternatiivset tüüpi linke.

II - kasutatakse üsna sageli suvalise arvu tasemetega hierarhiate kirjeldamiseks.

III - toimub varases staadiumis. Sageli peegeldab "materjalide loendi" struktuuri (komponentide vastastikune pesastumine). Näide: iga KOMPONENT võib koosneda ühest või mitmest (teist) KOMPONENDist ja iga KOMPONENTI võib kasutada ühes või mitmes (teises) KOMPONENDIS.

Kehtetud lingitüübid. Kehtetud suhtetüübid on järgmised: kohustuslik palju-mitmele suhe ( riis. üksteist) ja hulk rekursiivseid linke ( riis. 12).

Riis. 11. Kehtetud palju-mitmele suhted

Riis. 12. Kehtetud rekursiivsed lingid

Kohustuslik mitu-mitmele suhe on põhimõtteliselt võimatu. Selline seos tähendaks, et ükski A esinemine ei saaks eksisteerida ilma B-ta ja vastupidi. Tegelikult osutub iga selline konstruktsioon alati ekslikuks.

Alguse juurde

Andmevoo diagrammid

Loogiline DFD ( riis. 13) näitab süsteemiväliste andmete allikaid ja neeldajaid (sihtkohti), identifitseerib loogilisi funktsioone (protsesse) ja andmeelementide rühmi, mis ühendavad ühte funktsiooni teisega (vood), samuti identifitseerib andmesalvestid (akud), millele juurde pääseb. Andmevoo struktuurid ja nende komponentide määratlused salvestatakse ja sõelutakse andmesõnastikku. Iga loogilist funktsiooni (protsessi) saab üksikasjalikult kirjeldada madalama taseme DFD abil; kui täpsemad üksikasjad ei ole enam kasulikud, liigutakse edasi funktsiooni loogika väljendamisele protsessi spetsifikatsiooni abil (minispetsifikatsioon). Iga poe sisu salvestatakse ka andmesõnastikku ja poe andmemudel eksponeeritakse ER diagrammide abil.

Riis. 13. DFD näide

Eelkõige ei näita DFD protsesse, mis juhivad tegelikku andmevoogu, ega tee vahet kehtivatel ja kehtetud teedel. DFD-d sisaldavad palju kasulikku teavet ja lisaks:

võimaldab teil süsteemi andmetena esitleda;

illustreerida väliseid andmeedastusmehhanisme, mis vajaksid spetsiaalseid liideseid;

võimaldavad kujutada nii süsteemi automatiseeritud kui ka manuaalseid protsesse;

teostada kogu süsteemi andmetele orienteeritud partitsioonid.

Andmevooge kasutatakse teabe (või isegi füüsiliste komponentide) edastamise modelleerimiseks süsteemi ühest osast teise. Vood diagrammidel on kujutatud nimeliste nooltega, nooled näitavad info liikumise suunda. Mõnikord võib teave liikuda ühes suunas, seda töödeldakse ja tagastatakse selle allikale. Sellist olukorda saab modelleerida kas kahe erineva voo või ühe kahesuunalise vooga.

Protsess teisendab sisendvoo väljundvooks vastavalt protsessi nimega määratud toimingule. Igal protsessil peab olema kordumatu number, mis sellele diagrammis viitab. Seda numbrit saab kasutada koos diagrammi numbriga, et pakkuda kogu mudelis ainulaadset protsessiindeksit.

Andmete salvestamine (andmete salvestamine) võimaldab määratleda andmeid mitmes piirkonnas, mida protsesside vahel mällu salvestatakse. Tegelikult kujutab salvestusruum andmevoogude "lõike" ajas. Selles sisalduvat teavet saab kasutada igal ajal pärast selle määratlemist ja andmeid saab valida mis tahes järjekorras. Hoidla nimi peaks tuvastama selle sisu. Juhul, kui andmevoog siseneb (lahkub) hoidlasse (lahkub) ja selle struktuur vastab salvestusruumi struktuurile, peab sellel olema sama nimi, mida ei pea diagrammil kajastama.

Väline olem (terminaator) tähistab süsteemi konteksti välist olemit, mis on süsteemiandmete allikas või vastuvõtja. Selle nimi peab sisaldama nimisõna, näiteks "Klient". Eeldatakse, et selliste sõlmedega esindatud objektid ei tohiks üheski töötlemises osaleda.

Alguse juurde

STD oleku ülemineku diagrammid

Olemi elutsükkel kuulub STD diagrammide klassi ( riis. 14). See diagramm kajastab objekti oleku muutumist aja jooksul. Mõelge näiteks toote seisule laos: toodet saab tellida tarnijalt, tarnida lattu, hoiustada laos, läbida kvaliteedikontrolli, müüa, tagasi lükata, tarnijale tagastada. Diagrammil olevad nooled näitavad lubatud olekumuutusi.

Joonis 14. DFD näide

Selliste diagrammide kuvamiseks on mitu erinevat võimalust, joonisel on neist ainult üks.

Alguse juurde

Mõned põhimõtted teabemudeli kvaliteedi ja täielikkuse kontrollimiseks (allikas – Richard Barker, Case Method: Entity Relationship Modeling, Addison-Wesley, 1990)

Kui soovite luua kvaliteetset mudelit, peate kasutama CASE-tehnoloogiat hästi tundvate analüütikute abi. See aga ei tähenda, et infomudeli konstrueerimisel ja kontrollimisel peaksid osalema ainult analüütikud. Ka kolleegide abist võib palju abi olla. Kaasake nad eesmärgi kontrollimisse ja ehitatud mudeli üksikasjalikku uurimisse nii loogiliselt kui ka ainevaldkonna aspektidega arvestamise mõttes. Enamik inimesi leiab, et kellegi teise töös on vigu lihtsam leida.

Esitage regulaarselt oma teabemudelit või selle üksikuid fragmente, mille osas kahtlete kasutajate heakskiidu osas. Pöörake erilist tähelepanu reeglite ja piirangute eranditele.

Alguse juurde

Üksuse kvaliteet

Olemi kvaliteedi peamiseks tagatiseks on vastus küsimusele, kas objekt on tõesti olem, st oluline objekt või nähtus, mille kohta tuleks informatsioon andmebaasi salvestada.

Üksuse kinnitusküsimuste loend:

Kas olemi nimi peegeldab selle objekti olemust?

Kas seal on ristmik teiste üksustega?

Kas atribuute on vähemalt kaks?

Kas atribuute pole kokku rohkem kui kaheksa?

Kas selle olemi jaoks on sünonüüme/homonüüme?

Kas üksus on täielikult määratletud?

Kas on olemas unikaalne identifikaator?

Kas on vähemalt üks ühendus?

Kas olemi väärtuse loomiseks, otsimiseks, värskendamiseks, kustutamiseks, arhiveerimiseks ja kasutamiseks on olemas vähemalt üks funktsioon?

Kas on toimunud muutuste ajalugu?

Kas järgitakse andmete normaliseerimise põhimõtteid?

Kas sama üksus eksisteerib mõnes teises rakendussüsteemis, võib-olla teise nime all?

Kas olemus on liiga üldine?

Kas selles sisalduv üldistusaste on piisav?

Alamtüübi sõelumisküsimuste loend:

Kas esineb kattumisi teiste alatüüpidega?

Kas alamtüübil on atribuute ja/või seoseid?

Kas neil kõigil on oma kordumatud identifikaatorid või pärivad nad kõik ühe supertüübilt?

Kas on olemas täielik alatüüpide komplekt?

Kas alamtüüp pole mitte olemi esinemise näide?

Kas teate mingeid atribuute, seoseid ja tingimusi, mis eristavad seda alatüüpi teistest?

Alguse juurde

Atribuudi kvaliteet

Tuleb välja selgitada, kas need on tõesti atribuudid, st kas need kirjeldavad seda olemit ühel või teisel viisil.

Atribuudi turvaküsimuste loend:

Kas atribuudi nimi on ainsuse nimisõna, mis peegeldab atribuudiga tähistatava omaduse olemust?

Kas atribuudi nimi ei sisalda olemi nime (ei tohiks)?

Kas atribuudil on korraga ainult üks väärtus?

Kas dubleerivad väärtused (või rühmad) puuduvad?

Kas vorming, pikkus, kehtivad väärtused, tuletusalgoritm jne on kirjeldatud?

Kas see atribuut võib olla välja jäetud olem, mis oleks kasulik mõne muu (olemasoleva või kavandatava) rakendussüsteemi jaoks?

Kas see võib olla ühenduse kaotamine?

Kas on vaja muutuste ajalugu?

Kas selle väärtus sõltub ainult antud olemist?

Kui atribuudi väärtus on nõutav, kas see on alati teada?

Kas selle ja sarnaste atribuutide jaoks on vaja domeeni luua?

Kas selle väärtus sõltub ainult unikaalse identifikaatori mingist osast?

Kas selle väärtus sõltub mõne atribuudi väärtustest, mida unikaalne identifikaator ei sisalda?

Sissejuhatus

Infosüsteemide projekteerimine algab alati projekti eesmärgi määratlemisest. Iga eduka projekti peamine ülesanne on tagada, et süsteemi käivitamise ajal ja kogu selle tööperioodi jooksul on võimalik pakkuda:

• süsteemi nõutav funktsionaalsus ja kohanemisaste selle muutuvate toimimistingimustega;
• nõutav süsteemi läbilaskevõime;
• süsteemi nõutav reageerimisaeg päringule;
• süsteemi tõrgeteta töö vajalikus režiimis ehk teisisõnu süsteemi valmisolek ja kättesaadavus kasutajate päringute töötlemiseks;
• süsteemi töö lihtsus ja tugi;
• vajalik turvalisus.

Jõudlus on peamine tegur, mis määrab süsteemi tõhususe. Hea disain on suure jõudlusega süsteemi alus.

Infosüsteemide projekteerimine hõlmab kolme põhivaldkonda:

• andmebaasis realiseeritavate andmeobjektide kujundamine;
• programmide, ekraanivormide, aruannete kujundamine, mis tagavad andmepäringute täitmise;
• võttes arvesse konkreetset keskkonda või tehnoloogiat, nimelt: võrgu topoloogia, riistvara konfiguratsioon, kasutatav arhitektuur (failiserver või klient-server), paralleeltöötlus, hajutatud andmetöötlus jne.

Reaalsetes tingimustes on projekteerimine süsteemi funktsionaalsuse nõudeid rahuldava viisi otsimine olemasolevate tehnoloogiate abil, arvestades etteantud piiranguid.

Igale projektile kehtivad mitmed absoluutsed nõuded, näiteks maksimaalne projekti arendusaeg, maksimaalne rahaline investeering projekti jne. Üks projekteerimise raskusi on see, et see ei ole nii struktureeritud kui projekti nõuete analüüs või konkreetse projekteerimislahenduse elluviimine.

Arvatakse, et keerulist süsteemi ei saa põhimõtteliselt kirjeldada. See puudutab eelkõige ettevõtte juhtimissüsteeme. Üheks peamiseks argumendiks on süsteemi toimimise tingimuste muutmine, näiteks teatud infovoogude direktiivne muutus uue juhtkonna poolt. Teine argument on lähteülesande ulatus, mis suure projekti puhul võib olla sadu lehekülgi, samas kui tehniline projekt võib sisaldada vigu. Tekib küsimus: võib-olla on parem mitte üldse uuringuid läbi viia ja tehnilist projekti mitte teha, vaid kirjutada süsteem "nullist" lootuses, et kliendi soov on mingi imeline kokkulangevus programmeerijate kirjutatuga ja ka see, et et see kõik stabiilselt toimiks?

Kui vaadata, siis kas tõesti on süsteemi areng nii ettearvamatu ja kas tõesti on võimatu selle kohta infot saada? Tõenäoliselt saab seminaride kaudu aimu süsteemist kui tervikust ja selle arendamiseks kavandatud viisidest (juhtimisest). Seejärel purustage keeruline süsteem lihtsamateks komponentideks, lihtsustage komponentide omavahelisi seoseid, tagage komponentide sõltumatus ja kirjeldage nendevahelisi liideseid (nii et ühe komponendi muutus ei tooks automaatselt kaasa olulist muutust teises komponendis) , samuti süsteemi laiendamise võimalus ja funktsioonide süsteemi ühes või teises versioonis realiseerimata "stubs". Sellistele elementaarsetele kaalutlustele tuginedes ei tundu infosüsteemis rakendatava kirjeldus enam nii ebareaalne. Infosüsteemide arendamiseks saate järgida klassikalisi lähenemisviise, millest ühte - "kose" skeemi (joonis 1) - kirjeldatakse allpool. Lühidalt vaadeldakse ka mõningaid teisi lähenemisi infosüsteemide arendamiseks, mille puhul on aktsepteeritav ka kose skeemis kirjeldatud elementide kasutamine. Millist lähenemist allpool kirjeldatutest järgida (ja kas on mõtet oma lähenemist välja mõelda), on mingil määral maitse ja asjaolude küsimus.

Tarkvara elutsükkel on selle loomise ja kasutamise mudel. Mudel peegeldab selle erinevaid olekuid, alustades hetkest, mil vajadus selle tarkvara järele tekib ja lõpetades hetkega, mil see on kõikide kasutajate jaoks täielikult kasutusest väljas. Tuntud on järgmised elutsükli mudelid:

• kaskaadmudel. Üleminek järgmisele etapile tähendab töö täielikku lõpetamist eelmises etapis.
• Lavastatud mudel vahepealse juhtimisega. Tarkvaraarendus toimub iteratsioonidena koos etappidevahelise tagasisideahelaga. Etappidevahelised kohandused võivad vähendada arendusprotsessi keerukust võrreldes kosemudeliga; iga etapi eluiga venitatakse kogu arendusperioodiks.
• spiraalne mudel. Erilist tähelepanu pööratakse väljatöötamise algfaasidele - strateegia väljatöötamisele, analüüsile ja kujundamisele, kus kontrollitakse ja põhjendatakse teatud tehniliste lahenduste teostatavust prototüüpide loomise (prototüüpimise) kaudu. Iga spiraali pööre hõlmab toote või selle mistahes komponendi teatud versiooni loomist, kusjuures täpsustatakse projekti omadused ja eesmärgid, määratakse selle kvaliteet ning kavandatakse spiraali järgmise pöörde tööd.

Allpool käsitleme mõningaid projekti arendamise skeeme.

"Waterfall" - projekti arendamise skeem

Väga sageli kirjeldatakse disaini kui eraldiseisvat projekti arendamise etappi analüüsi ja arenduse vahel. Tegelikkuses pole aga projekti arendusetappide vahel selget jaotust – projekteerimisel ei ole reeglina selgelt määratletud algust ja lõppu ning see jätkub sageli testimise ja juurutamise etapis. Rääkides testimisetapist, tuleb veel märkida, et nii analüüsietapp kui ka projekteerimisetapis sisaldavad elemente testijate tööst, näiteks et saada eksperimentaalset põhjendust konkreetse lahenduse valimiseks, samuti hinnata kvaliteedikriteeriume. saadud süsteemist. Käitamisetapis on asjakohane rääkida süsteemi hooldusest.

Allpool käsitleme kõiki etappe, käsitledes üksikasjalikumalt projekteerimisetappi.

strateegia

Strateegia määratlemine hõlmab süsteemi uurimist. Küsitluse põhiülesanne on hinnata projekti tegelikku ulatust, selle eesmärke ja eesmärke, samuti saada kõrgel tasemel üksuste ja funktsioonide määratlusi.

Selles etapis on kaasatud kõrgelt kvalifitseeritud ärianalüütikud, kellel on pidev juurdepääs ettevõtte juhtkonnale; etapp hõlmab tihedat suhtlemist süsteemi peamiste kasutajate ja äriekspertidega. Interaktsiooni põhiülesanne on hankida süsteemi kohta võimalikult täielik teave (täielik ja ühemõtteline arusaam kliendi nõudmistest) ning edastada see teave formaliseeritud kujul süsteemianalüütikutele järgnevaks analüüsietapiks. Reeglina saab infot süsteemi kohta juhtkonna, ekspertide ja kasutajatega peetud vestluste või seminaride tulemusena. Seega määratakse kindlaks selle ettevõtte olemus, selle arendamise väljavaated ja süsteemile esitatavad nõuded.

Süsteemiuuringu põhifaasi lõppedes kujundavad tehnikud tõenäolised tehnilised lähenemisviisid ja hindavad riistvara, ostetud tarkvara ja uue tarkvara väljatöötamise kulusid (mille tegelikult eeldab projekt).

Strateegia määratlemise etapi tulemuseks on dokument, milles on selgelt kirjas, mida klient saab, kui ta nõustub projekti rahastama; millal ta valmistoote kätte saab (töögraafik); kui palju see maksma läheb (suurprojektide puhul tuleks koostada rahastamise ajakava erinevates tööetappides). Dokument peaks kajastama mitte ainult kulusid, vaid ka tulusid, näiteks projekti tasuvusaega, eeldatavat majanduslikku efekti (kui seda on võimalik hinnata).

Dokumendis tuleb kirjeldada:

• piirangud, riskid, projekti edukust mõjutavad kriitilised tegurid, näiteks on süsteemi päringule vastamise aeg etteantud piirang, mitte soovitav tegur;
• tingimuste kogum, mille alusel ta peaks tulevase süsteemi opereerima: süsteemi arhitektuur, süsteemile antavad riist- ja tarkvararessursid, selle toimimise välistingimused, inimeste koosseis ja töö, mis tagavad süsteemi tõrgeteta toimimise;
• üksikute etappide läbimise tähtajad, tööde teostamise vorm, projekti arendamise protsessi kaasatud ressursid, teabe kaitsmise meetmed;
• süsteemi poolt täidetavate funktsioonide kirjeldus;
• tulevased nõuded süsteemile selle arendamise korral, näiteks kasutaja võimekus töötada süsteemiga Internetti kasutades jne;
• süsteemi funktsioonide täitmiseks vajalikud üksused;
• liidesed ja funktsioonide jaotus isiku ja süsteemi vahel;
• nõuded tarkvarale ja tarkvara infokomponentidele, nõuded DBMS-ile (kui projekt peaks olema rakendatud mitmele DBMS-ile, siis nõuded igaühele neist või üldised nõuded abstraktsele DBMS-ile ja selle projekti jaoks soovitatavate DBMS-ide loetelu, vastama kindlaksmääratud tingimustele);
• mida projekti raames ei rakendata.

Selles etapis tehtud töö võimaldab meil vastata küsimusele, kas seda projekti tasub jätkata ja milliseid kliendi nõudeid on võimalik teatud tingimustel täita. Võib selguda, et projekti ei ole mõtet jätkata näiteks seetõttu, et teatud nõudeid ei saa mingitel objektiivsetel põhjustel täita. Kui tehakse otsus projektiga edasi minna, siis on analüüsi järgmiseks etapiks juba ettekujutus projekti mahust ja maksumusest.

Tuleb märkida, et strateegia valimise etapis ja analüüsi etapis ning projekteerimisel, olenemata projekti väljatöötamisel kasutatud meetodist, tuleks süsteemi kavandatavad funktsioonid alati tähtsuse järjekorras klassifitseerida. . Ühe võimaliku vormingu sellise klassifikatsiooni esitamiseks MoSCoW pakkusid välja Clegg, Dai ja Richard Barker, Case Method Fast-track: A RAD Approach, Adison-Wesley, 1994.

See lühend tähistab: Must have – vajalikud funktsioonid; Peaks omama - soovitavaid funktsioone; Võiks olla - võimalikud funktsioonid; Ei ole – puuduvad funktsioonid.

Teise ja kolmanda kategooria funktsioonide elluviimist piirab aja- ja finantsraamistik: arendame välja nii vajaliku kui ka maksimaalse võimaliku arvu teise ja kolmanda kategooria funktsioone prioriteetsuse järjekorras.

Analüüs

Analüüsietapp hõlmab äriprotsesside (strateegia valiku etapis määratletud funktsioonid) ja nende rakendamiseks vajaliku teabe (üksused, nende atribuudid ja seosed (suhted)) üksikasjalikku uurimist. Selles etapis luuakse teabemudel ja järgmises projekteerimisetapis luuakse andmemudel.

Kogu strateegia määratlemise etapis kogutud teave süsteemi kohta vormistatakse ja täpsustatakse analüüsi etapis. Erilist tähelepanu tuleks pöörata edastatava teabe täielikkusele, teabe analüüsile vastuolude puudumisel, samuti teabe otsimisel, mida ei kasutata või mida dubleeritakse. Klient ei kujunda reeglina kohe nõudeid süsteemile kui tervikule, vaid sõnastab nõuded selle üksikutele komponentidele. Pöörake tähelepanu nende komponentide järjepidevusele.

Analüütikud koguvad ja salvestavad teavet kahel omavahel seotud kujul:

• funktsioonid - teave äritegevuses toimuvate sündmuste ja protsesside kohta;
• entiteedid - teave asjade kohta, mis on organisatsiooni jaoks olulised ja mille kohta on midagi teada.

Kaks klassikalist analüüsitulemust on:

• funktsioonide hierarhia, mis jaotab töötlemise selle komponentideks (mida tehakse ja millest see koosneb);
• entity-relationship model (Entry Relationship model, ER-mudel), mis kirjeldab olemite, nende atribuute ja nendevahelisi suhteid (relationships).

Need tulemused on vajalikud, kuid mitte piisavad. Piisavate tulemuste hulgas on andmevoo diagrammid ja olemi elutsükli diagrammid. Üsna sageli tekivad analüüsivead, kui püütakse näidata olemi elutsüklit ER diagrammil.

Allpool käsitleme kolme kõige sagedamini kasutatavat struktuurianalüüsi metoodikat:

• Entity-Relationship Diagrams (ERD), mille eesmärk on vormistada teavet üksuste ja nende suhete kohta;
• andmevoo diagrammid (Data Flow Diagrams, DFD), mille eesmärk on vormistada süsteemi funktsioonide esitus;
• oleku ülemineku diagrammid (State Transition Diagrams, STD), mis kajastavad süsteemi käitumist olenevalt ajast; Sellesse diagrammide klassi kuuluvad olemi elutsükli diagrammid.

Normaliseerimine

Andmetöötluse anomaaliate vältimiseks kasutatakse normaliseerimist. Infomudeli objektide normaliseerimise põhimõtted on täpselt samad, mis andmemudelite puhul.

Lubatud lingitüübid. Üks-ühele seost lähemalt uurides (joonis 7) selgub peaaegu alati, et A ja B on tegelikult sama subjekti erinevad alamhulgad või erinevad vaatenurgad, millel on lihtsalt erinevad nimed ja erinevalt kirjeldatud. lingid ja atribuudid.

Mitmed-ühele suhted on näidatud joonisel fig. 8 .

I on piisavalt tugev konstruktsioon, et olemi B kirjet ei saa luua ilma olemi A vähemalt ühte seotud kirjet loomata.

II on kõige levinum suhtlusvorm. See eeldab, et iga olemi A esinemine saab eksisteerida ainult ühe (ja ainult ühe) olemi B esinemise kontekstis. B esinemised võivad omakorda eksisteerida nii seoses A esinemistega kui ka ilma selleta.

III - harva kasutatud. Nii A kui ka B võivad eksisteerida ilma nendevahelise ühenduseta.

Paljud-mitmele suhted on näidatud joonisel fig. 9 .

I - selline konstrueerimine toimub sageli analüüsietapi alguses ja tähendab seost - kas pole täielikult mõistetud ja vajab lisaluba või peegeldab lihtsat kollektiivset suhet - topeltseotud loetelu.

II - harva kasutatud. Selliseid linke tuleb alati täpsustada.

Vaatleme nüüd rekursiivseid linke (joonis 10).

I - haruldane, kuid esineb. Peegeldab alternatiivset tüüpi linke.

II - kasutatakse üsna sageli suvalise arvu tasemetega hierarhiate kirjeldamiseks.

III - toimub varases staadiumis. Sageli peegeldab "materjalide loendi" struktuuri (komponentide vastastikune pesastumine). Näide: iga KOMPONENT võib koosneda ühest või mitmest (teist) KOMPONENDist ja iga KOMPONENTI võib kasutada ühes või mitmes (teises) KOMPONENDIS.

Kehtetud lingitüübid. Kehtetud seosetüübid on järgmised: kohustuslik palju-mitmele seos (joonis 11) ja rekursiivsete seoste kogum (joonis 12).

Kohustuslik mitu-mitmele suhe on põhimõtteliselt võimatu. Selline seos tähendaks, et ükski A esinemine ei saaks eksisteerida ilma B-ta ja vastupidi. Tegelikult osutub iga selline konstruktsioon alati ekslikuks.

Andmevoo diagrammid

Loogiline DFD (joonis 13) näitab süsteemiväliseid andmeallikaid ja -nimme (sihtkohti), identifitseerib loogilisi funktsioone (protsesse) ja andmeelementide rühmi, mis seovad ühe funktsiooni teisega (vood), samuti identifitseerib andmehoidlad (akud), millele juurdepääs tehakse. Andmevoo struktuurid ja nende komponentide määratlused salvestatakse ja sõelutakse andmesõnastikku. Iga loogilist funktsiooni (protsessi) saab üksikasjalikult kirjeldada madalama taseme DFD abil; kui täpsemad üksikasjad ei ole enam kasulikud, liigutakse edasi funktsiooni loogika väljendamisele protsessi spetsifikatsiooni abil (minispetsifikatsioon). Iga poe sisu salvestatakse ka andmesõnastikku ja poe andmemudel eksponeeritakse ER diagrammide abil.

Eelkõige ei näita DFD protsesse, mis juhivad tegelikku andmevoogu, ega tee vahet kehtivatel ja kehtetud teedel. DFD-d sisaldavad palju kasulikku teavet ja lisaks:

• võimaldab teil süsteemi andmetena esitleda;
• illustreerida väliseid andmeedastusmehhanisme, mis vajaksid spetsiaalseid liideseid;
• võimaldavad kujutada nii süsteemi automatiseeritud kui ka manuaalseid protsesse;
• teostada kogu süsteemi andmetele orienteeritud partitsioonid.

Andmevooge kasutatakse teabe (või isegi füüsiliste komponentide) edastamise modelleerimiseks süsteemi ühest osast teise. Vood diagrammidel on kujutatud nimeliste nooltega, nooled näitavad info liikumise suunda. Mõnikord võib teave liikuda ühes suunas, seda töödeldakse ja tagastatakse selle allikale. Sellist olukorda saab modelleerida kas kahe erineva voo või ühe kahesuunalise vooga.

Protsess teisendab sisendvoo väljundvooks vastavalt protsessi nimega määratud toimingule. Igal protsessil peab olema kordumatu number, mis sellele diagrammis viitab. Seda numbrit saab kasutada koos diagrammi numbriga, et pakkuda kogu mudelis ainulaadset protsessiindeksit.

Andmete salvestamine (andmete salvestamine) võimaldab määratleda andmeid mitmes piirkonnas, mida protsesside vahel mällu salvestatakse. Tegelikult kujutab salvestusruumi andmevoogude "lõike" ajas. Selles sisalduvat teavet saab kasutada igal ajal pärast selle määratlemist ja andmeid saab valida mis tahes järjekorras. Hoidla nimi peaks tuvastama selle sisu. Juhul, kui andmevoog siseneb (lahkub) hoidlasse (lahkub) ja selle struktuur vastab salvestusruumi struktuurile, peab sellel olema sama nimi, mida ei pea diagrammil kajastama.

Väline olem (terminaator) tähistab süsteemi konteksti välist olemit, mis on süsteemiandmete allikas või vastuvõtja. Tema nimi peab sisaldama nimisõna, näiteks "Klient". Eeldatakse, et selliste sõlmedega esindatud objektid ei tohiks üheski töötlemises osaleda.

Mõned põhimõtted teabemudeli kvaliteedi ja täielikkuse kontrollimiseks
(allikas – Richard Barker, Case Method: Entity Relationship Modeling, Addison-Wesley, 1990)

Kui soovite luua kvaliteetset mudelit, peate kasutama CASE-tehnoloogiat hästi tundvate analüütikute abi. See aga ei tähenda, et infomudeli konstrueerimisel ja kontrollimisel peaksid osalema ainult analüütikud. Ka kolleegide abist võib palju abi olla. Kaasake nad eesmärgi kontrollimisse ja ehitatud mudeli üksikasjalikku uurimisse nii loogiliselt kui ka ainevaldkonna aspektidega arvestamise mõttes. Enamik inimesi leiab, et kellegi teise töös on vigu lihtsam leida.

Esitage regulaarselt oma teabemudelit või selle üksikuid fragmente, mille osas kahtlete kasutajate heakskiidu osas. Pöörake erilist tähelepanu reeglite ja piirangute eranditele.

Üksuse kvaliteet

Olemi kvaliteedi peamiseks tagatiseks on vastus küsimusele, kas objekt on tõesti olem, st oluline objekt või nähtus, mille kohta tuleks informatsioon andmebaasi salvestada.

Üksuse kinnitusküsimuste loend:

• Kas olemi nimi peegeldab selle objekti olemust?
• Kas seal on ristmik teiste üksustega?
• Kas atribuute on vähemalt kaks?
• Kas atribuute pole kokku rohkem kui kaheksa?
• Kas selle olemi jaoks on sünonüüme/homonüüme?
• Kas üksus on täielikult määratletud?
• Kas on olemas unikaalne identifikaator?
• Kas on vähemalt üks ühendus?
• Kas olemi väärtuse loomiseks, otsimiseks, värskendamiseks, kustutamiseks, arhiveerimiseks ja kasutamiseks on olemas vähemalt üks funktsioon?
• Kas on toimunud muutuste ajalugu?
• Kas järgitakse andmete normaliseerimise põhimõtteid?
• Kas sama üksus eksisteerib mõnes teises rakendussüsteemis, võib-olla teise nime all?
• Kas olemus on liiga üldine?
• Kas selles sisalduv üldistusaste on piisav?

Alamtüübi sõelumisküsimuste loend:

• Kas esineb kattumisi teiste alatüüpidega?
• Kas alamtüübil on atribuute ja/või seoseid?
• Kas neil kõigil on oma kordumatud identifikaatorid või pärivad nad kõik ühe supertüübilt?
• Kas on olemas täielik alatüüpide komplekt?
• Kas alamtüüp pole mitte olemi esinemise näide?
• Kas teate mingeid atribuute, seoseid ja tingimusi, mis eristavad seda alatüüpi teistest?

Atribuudi kvaliteet

Tuleb välja selgitada, kas need on tõesti atribuudid, st kas need kirjeldavad seda olemit ühel või teisel viisil.

Atribuudi turvaküsimuste loend:

• Kas atribuudi nimi on ainsuse nimisõna, mis peegeldab atribuudiga tähistatava omaduse olemust?
• Kas atribuudi nimi ei sisalda olemi nime (ei tohiks)?
• Kas atribuudil on korraga ainult üks väärtus?
• Kas dubleerivad väärtused (või rühmad) puuduvad?
• Kas vorming, pikkus, kehtivad väärtused, tuletusalgoritm jne on kirjeldatud?
• Kas see atribuut võib olla välja jäetud olem, mis oleks kasulik mõne muu (olemasoleva või kavandatava) rakendussüsteemi jaoks?

Peame välja selgitama, kas seosed peegeldavad üksuste vahel täheldatud tõeliselt olulisi suhteid.

Suhtlemise kinnitusküsimuste loend:

• Kas iga asjaosalise kohta on kirjeldus olemas, kas see kajastab täpselt suhte sisu ja kas see sobib aktsepteeritud süntaksiga?
• Kas sellega on seotud ainult kaks osapoolt?

Kas ühendus pole kaasaskantav?

• Kas seotuse määr ja kohustus on igale poolele määratud?
• Kas ühenduse struktuur on lubatud?

Kas ühenduse disain on üks harva kasutatavatest?

• Kas see pole üleliigne?
• Kas see aja jooksul ei muutu?
• Kui ühendus on kohustuslik, kas see peegeldab alati suhet vastaspoolt esindava entiteediga?

Eksklusiivse ühenduse jaoks:

• Kas kõik eksklusiivse kaarega kaetud lingiotsad on sama köitetüübiga?
• Kas need kõik viitavad samale üksusele?
riis. 15) selline lagunemine. Mõelge lihtsaimale probleemile kliendile arve väljastamisel kauba laost väljastamisel eeldusel, et kaupade komplekt, mida klient osta soovib, on juba teada (selles näites me kauba valiku probleemi ei käsitle).

Ilmselgelt saab allahindluste valimise ja arvutamise toimingu jaotada ka väiksemateks toiminguteks, näiteks lojaalsuse allahindluste arvutamine (klient ostab kaupa pikaks ajaks) ja allahindluste arvutamine ostetud kaubakogusele. Aatomifunktsioone kirjeldatakse üksikasjalikult, näiteks DFD ja STD abil. Ilmselgelt ei välista selline funktsioonide kirjeldus täiendavat sõnalist kirjeldamist (näiteks kommentaarid).

Tuleb märkida, et analüüsi etapis tuleks tähelepanu pöörata võimalike vigade ja kõrvalekallete süsteemi eeldatavast standardist analüüsi ja töötlemise funktsioonidele. Tuleks välja selgitada süsteemi toimimiseks kõige kriitilisemad protsessid ja nende jaoks tuleks ette näha eriti range veaanalüüs. DBMS-i veakäsitlus (tagastuskoodid) on reeglina eraldi funktsioonide komplekt või üks funktsioon.

Strateegia täpsustamine

Analüüsi etapis viimistletakse lõplikuks teostuseks valitud riist- ja tarkvara. Selleks saab kaasata testimisrühmi ja tehnilisi spetsialiste. Infosüsteemi kujundamisel on oluline arvestada süsteemi edasiarendamisega, näiteks töödeldavate andmete mahu suurenemisega, päringuvoo intensiivsuse suurenemisega, usaldusväärsuse nõuete muutumisega. infosüsteemist.

Analüüsietapis määratakse ülesannete mudelite komplektid, et saada erinevate DBMS-ide võrdlevad omadused, mida arvestati infosüsteemi juurutamise strateegia kindlaksmääramise etapis. Strateegia määramise etapis saab valida ühe DBMS-i. Süsteemi kohta on juba analüüsifaasis palju rohkem andmeid ja need on üksikasjalikumad. Saadud andmed, aga ka testimisrühmade edastatud karakteristikud võivad näidata, et DBMS-i valik strateegia kindlaksmääramise etapis oli vale ja valitud DBMS ei vasta teatud infosüsteemi nõuetele. Samad andmed on saadaval ka riistvaraplatvormi ja operatsioonisüsteemi valiku kohta. Selliste tulemuste saamine algatab strateegia kindlaksmääramise etapis saadud andmete muutumise, näiteks arvutatakse ümber projekti kuluprognoos.

Analüüsi etapis täpsustatakse ka arendusvahendite valikut. Kuna analüüsifaas annab infosüsteemist terviklikuma pildi kui strateegia määratlemise faasis, saab tööplaani korrigeerida. Kui eelmises etapis valitud arendustööriist ei võimalda üht või teist osa tööst määratud aja jooksul lõpetada, siis otsustatakse tähtaegu muuta (reeglina on tegemist arendusaja pikenemisega) või muuta arendustööriista. Ühe või teise tööriista valimisel tuleks arvestada kõrgelt kvalifitseeritud töötajate olemasoluga, kes omavad valitud arendustööriistu, samuti valitud DBMS-i administraatorite olemasolu. Need soovitused täpsustavad ka strateegia valiku etapi andmeid (tingimuste kogum, mille alusel tulevane süsteem peaks toimima).

Samuti on täpsustatud piirangud, riskid, kriitilised tegurid. Kui strateegia koostamise etapis valitud DBMS-i ja tarkvaratööriistade abil realiseeritavas infosüsteemis mingeid nõudeid ei ole võimalik rahuldada, siis algatab see ka saadud andmete täpsustamise ja muutmise (lõppkokkuvõttes kuluprognooside ja tööplaanide ning võimalusel ka muutmise). klientide nõudmistes süsteemile, näiteks nende nõrgenemine). Täpsemalt kirjeldatakse funktsioone, mida süsteemis ei rakendata.

ComputerPress 9 "2001