Projektiranje informacijskog sustava. Mobiteli direktora
Počnimo s pregledom cjelokupne arhitekture. Za početak, istaknimo karakteristične značajke informacijskih sustava ove vrste koji djeluju na internetu na web stranicama, jer projektni zadatak temelji se na karakteristikama određenog sustava i funkcionalnim zahtjevima. Tako:
- sve informacije i svi izračuni se pohranjuju i izvode na poslužitelju
- svaki klijent ima svoj preglednik
- višekorisnički pristup
- kontrola pristupa
- ograničenja količine prenesenih informacija
- povećani sigurnosni zahtjevi
- povećani zahtjevi za performansama
- prenosivost
Pogledajmo redom ove značajke. U prvom planu su prve dvije točke. Oni predstavljaju najvažniju razliku od informacijskih sustava koji rade u zatvorenim mrežama. Nismo u mogućnosti pohraniti i obraditi bilo kakve informacije na strani klijenta. Sve se mora obaviti na serveru. Prilikom razvoja informacijskog sustava s klijentskim softverom bilo bi moguće pohraniti dio korisničkih informacija i obraditi ih na strani klijenta. Takva prilika bi nam omogućila da rasteretimo poslužiteljski i mrežni promet. Primjerice, u slučaju analize posjetitelja web stranice većinu informacija pohranili bismo kod klijenata, a na poslužitelju samo javno dostupna statistička izvješća, izvatke i usporedne pokazatelje s drugim klijentima. Ali mi nemamo takvu priliku, pa moramo potrošiti mnogo novca na tvrde diskove i računalne snage poslužitelja. Višekorisnički pristup i kontrola pristupa zajednički su zahtjevi za sve informacijske sustave. Važan kriterij je ograničenje količine prenesenih informacija. Poslužitelj može imati kanal s velikom propusnošću, ali ovaj kanal prenosi informacije od mnogih klijenata. Zauzvrat, korisnik ima informacije samo za njega, ali vrlo često korisnici sjede na lošim kanalima, na primjer, na modemskoj vezi, ili jednostavno, zbog udaljenosti i velikog broja pristupnika između klijenta i poslužitelja, informacije brzina prijenosa je vrlo spora. Zbog činjenice da na internetu postoji ogroman broj ljudi među kojima ima i uljeza, potrebno je nametnuti povećane sigurnosne zahtjeve. Ne možete pisati upute korisniku: učini ovo, a ne drugačije, ali ovdje imamo rupu da to zaobiđemo, učini ovo. Ne znate što očekivati od korisnika. S obzirom da se svi izračuni odvijaju na serveru, te da korisnik želi raditi u realnom vremenu i ne namjerava čekati ni 30 sekundi, izvođenje jednog CGI programa trebalo bi biti što brže. I konačno, prenosivost. Naravno, ova značajka nije toliko važna, ali recimo da ste trebali otvoriti zrcalo stranice na drugom kontinentu. Uglavnom, potrebno je riješiti dva problema. Prvo, postavljanje poslužiteljske platforme i vaše softver za rad vašeg informacijskog sustava. Drugo, prijevod sustava na drugi jezik. Na drugom kontinentu možda jednostavno ne postoji platforma koju zahtijeva vaš informacijski sustav, niti stručnjaci koji bi sve to mogli instalirati, konfigurirati i podržati. Na primjer, bit će drugačiji okus Unixa. Sve ove karakteristične značajke, u osnovi, određuju fazu projektiranja.
U procesu projektiranja informacijskog sustava mogu se razlikovati tri glavne faze:
- dizajn korisničkog sučelja;
- dizajn baze podataka;
- projektiranje sustava obvezivanja za CGI programe.
U prvoj fazi projektiranja potrebno je saznati zahtjeve korisnika prema sustavu i na temelju tih zahtjeva izraditi izgled stranice na kojoj su prikazani svi HTML oblici i HTML datoteke izvješća o interakciji s informacijskim sustavom. Poželjno je da HTML obrasci prema zadanim postavkama sadrže neke podatke i poveznice na HTML dokumente za koje se očekuje da budu rezultat zahtjeva prema sustavu. U tom slučaju korisnicima će biti lakše razumjeti što ste dizajnirali.
Dizajn baze podataka je detaljno razmotren u poglavlju Dizajn baze podataka, tako da ga ovdje nećemo ponavljati. Napominjemo samo da je ova faza skrivena od korisnika, te sva odgovornost za izbor ispravna odluka pada na vas kao programera.
U trećoj fazi otkriva se skup CGI programa. Što svaki CGI program radi i odnosi među njima. Želio bih odmah napomenuti jednu vrlo čestu pogrešku početnika web programera koji implementiraju nekoliko funkcija u jednom programu. Primjerice, kod izrade knjige gostiju izrađuje se jedna CGI skripta koja se poziva u svim HTML oblicima: i kod prikaza poruka i kod dodavanja, još je gore ako su tu uključene funkcije administratorskog pristupa, t.j. brisanje i uređivanje poruka. Tri su glavna razloga zašto to ne biste trebali učiniti. Prvo, to je potencijalna sigurnosna rupa. Drugo, učitavanje i izvođenje takvog CGI programa bit će sporije. I treće, takav program je teško modificirati, testirati i otklanjati pogreške, jer on sam po sebi predstavlja složenost zbog volumena početnog teksta.
Najviše ispravna odluka je odnos jedan-na-jedan između funkcionalnog zahtjeva i CGI programa. Jedna funkcija (operacija) - jedan CGI program. U tom će slučaju izvorni kod biti jednostavan i malen, pa je vjerojatnost propuštanja sigurnosne rupe u njemu znatno smanjena. Učitavanje i izvođenje takvog programa bit će puno brže. I što je najvažnije, bit će puno lakše modificirati i održavati takav program.
Osim opisa koji program obavlja koju funkciju, morate uspostaviti odnose među njima. To je tako glupa shema. U jednostavnim sustavima on je jednostavan; u velikim sustavima njegova složenost raste nelinearno. Naravno, možete organizirati veze na mjestu. U jednostavnim sustavima uopće se ništa ne crta, jer i sve je tako očito. Ali u velikim sustavima, pogotovo ako radite u timu od nekoliko ljudi, korisno je imati vizualni prikaz odakle i odakle se poziva CGI skripta, te kamo ćete doći nakon što je izvršite. U osnovi, kao što smo već raspravljali u poglavlju "CGI programiranje", CGI program može ispisati ili tekst, ili preusmjeriti na drugu adresu na Internetu, ili ispisati sliku ili neku drugu datoteku. Ovakvu vrstu ručno nacrtanog dijagrama korisno je imati kako bi se jasno razumjela arhitektura projekta.
Na temelju zahtjeva za projektiranje sučelja informacijskog sustava navedenih u stavku 1.2.5.3., započet je razvoj. Prije svega, bilo je potrebno odlučiti se za vrstu dizajna za cijelu stranicu – neka to bude adaptivni, fluidni ili regularni dizajn s fiksnom širinom. Razlog je bio taj što je sada pri izgledu potrebno voditi računa o rezolucijama ekrana koje se kreću od 320 piksela do 2560 na 27-inčnim monitorima, što znači da bi se uz to trebala mijenjati i veličina stranice. Rješenje je bilo napuštanje responsive dizajna (koji se može prilagoditi veličini zaslona uređaja na kojem se sustav gleda), unatoč njegovoj modernosti, u korist fiksne širine. To je učinjeno zbog činjenice da je jedan od zadataka adaptivnog dizajna olakšati korisniku čitanje teksta s mobilnog telefona, uz smanjenje veličine slike, a budući da je primarni zadatak foto arhive da pokažite fotografije, ovaj pristup ne bi bio posve racionalan. Stoga je odlučeno ostaviti uobičajeni dizajn s fiksnom širinom.
Na temelju zadanih zahtjeva potrebno je razviti dvije vrste stranica:
puna širina;
sa bočnom trakom.
Prvi korak je bio odrediti širinu svih blokova za obje vrste stranica. Unatoč brzom napretku tehnologije, još uvijek postoje monitori sa širinom zaslona od 1024x768, manji, poput 800x600, već su van upotrebe. A budući da je ta razlika prisutna, uzmimo širinu svih blokova i praznine između njih kao 1000 piksela (Sl. 12 a). Sukladno tome, ovo je širina za opciju pune širine, u slučaju bočnog stupca uzet ćemo 760 piksela za blok sa sadržajem, odnosno 200 za bočni stupac (slika 12. b).
a | b |
Slika 12 - Širina blokova na IS stranicama
a- za stranicu pune širine, b– za stranicu sa bočnom trakom
Sljedeća faza u razvoju grafičke komponente završnog kvalifikacijskog rada bila je izrada pozadinske slike i odabir boje ispod ove slike.
Početni zahtjev za pozadinsku sliku bio je “koristite fotografiju/fotografije iz smjena kampa u pozadini. Neka prijeđu iz crno-bijele stare u novu boju. Da bi se ostavio dojam da idu uz vremensku ljestvicu.” Na temelju ovog zahtjeva sastavljena je prva verzija pozadinske slike (slika 13.).
Slika 13 - Početna verzija pozadinske slike
Ova opcija se pokazala ne baš atraktivnom, nakon čega je promijenjena u opciju kada su se susjedne slike malo preklapale, stvarajući dojam “protoka vremena” (slika 14.). Zbog činjenice da je prva opcija dobre kvalitete zauzimala puno prostora -
3 mb (prema standardima weba, ovo je puno. Ne treba više od 300 kb), a u lošem je izgledalo užasno, slika je smanjena u visinu i ponavljana duž Y osi. Ali ova opcija se okrenula neće biti kako se očekivalo.
Slika 14 - Ulomak druge verzije pozadinske slike
Zatim su se slike na pozadini pomiješale jedna s drugom (slika 15). Ali ni ova opcija nije bila prikladna. Odlučeno je promijeniti projektni zadatak i napustiti opciju s fotografijama na pozadini.
Slika 15 - Treća verzija pozadinske slike
Odlučeno je koristiti ručno nacrtane slike kao pozadinu. Takav bi korak značajno smanjio veličinu rezultirajuće slike u dobroj kvaliteti s njezinom nepromijenjenom razlučivosti (2560x1500px) s 3-4 mb na 700 kb. Idealna veličina pozadinske slike ne bi smjela biti veća od 300 kb, pa je kvaliteta pozadinske slike bila malo narušena, što se nije baš primijetilo.
Budući da se kamp nalazi u borovoj šumi, odabrao sam sljedeći koncept: u zaglavlju stranice nalazi se nebo s oblacima, u sredini neutralne boje s mogućnošću povećanja s povećanjem visine stranice , a u podnožju se nalazi zemljište sa stablima jele (sl. 16).
Ova opcija je također odbačena. Trebalo je pokazati da se kamp nalazi na obali Gorkog mora, pa je unesena još jedna promjena u zahtjevima dizajna sučelja, odnosno prisutnost mora u pozadini. Kao rezultat toga, ostala je verzija sa slike 17. Ispostavilo se da je svijetla, primamljiva i ne tako ometajuća, unatoč svojoj svjetlini. Povećanjem visine mjesta iznad širine slike, nastali prostor treba ispuniti bojom pijeska, kako bi slika izgledala kontinuirano.
Slika 16 - Izvorna verzija nacrtane pozadinske slike
Slika 17 - Druga verzija nacrtane pozadinske slike
Sljedeći korak bio je odlučivanje o stilu vremenske skale. Ovdje je također bilo nekoliko opcija, od kojih su mnoge morale biti napuštene u korist ljepše slike. Na sl. 18 pokazuje kako se dizajn vremenske skale promijenio.
a | |
b | |
u |
Slika 18 - Opcije dizajna vremenske trake
a- početni, b– odobreno, c – provedeno u zelenoj boji(slika 21). Na vrhu, u kapu, dodani su logotipi kampa.
Slika 21 - Završni dizajn stranice sa bočnom trakom
2.2 Razvoj arhitekture sustava
Arhitektura sustava u ovom završnom kvalifikacijskom radu nije razvijena jer se koristi standardna arhitektura sustava za upravljanje sadržajem Wordpress.
Razvijena je metoda navigacije sustavom koja se sastoji od podjele dijelova na desetljeća radi lakše navigacije. Ovisno o dekadi odabranoj na "Vremenskoj skali", odgovarajuće godine se učitavaju u bočni stupac. Kada kliknete na godinu, dijelovi smjena i događaja u godini trebali bi se ugasiti. Klikom na karticu smjene učitat će se fotografije koje odgovaraju odabranoj smjeni i godini. Odabrani dio događaja u godini dovest će do učitavanja informacija o događajima koji su se dogodili za danu godinu. Kada kliknete na fotografiju u odjeljku s pomakom, trebala bi se povećati zahvaljujući AJAX prozorima i moći se prebaciti na sljedeću/prethodnu fotografiju, kao i zatvoriti prozor.
2.3 Programiranje i osnovni kodovi
2.3.1 Dizajniranje predložaka za osnovne vrste stranica
Obično se WordPress predlošci izrađuju na sljedeći način:
Izgled običnog html dokumenta i css stilova.
Podjela dokumenta na njegove glavne sastavne dijelove.
Izrada zasebnih php dokumenata za Wordpress predloške.
Ispunjavanje ovih dokumenata dijelovima koda iz izvorne datoteke.
Dodavanje prilagođenih oznaka.
Pročišćavanje koda uređivanjem online ili putem Notepad ++ s naknadnim prijenosom putem FTP-a.
Djelujući na danom tečaju, predložak stranice izvorno je kreiran u html-u:
Ostali kodovi stranica dani su u Dodatku B.
2.3.2 Razvoj i dodavanje vanjskih modula
Za implementaciju sustava korišteni su sljedeći moduli treće strane:
1. Dodatak NextGEN Gallery.
Najpopularniji dodatak za galeriju fotografija za WordPress. NextGEN vam omogućuje stvaranje prekrasnih galerija, ima mnogo značajki: učitavanje velikih slika, grupiranje galerija u albume.
Slika 22 - Početni prikaz izbornika u JavaScript skupu LavaLamp
2. Izmjena izbornika dodataka.
Uz pomoć dodatka moguće je kreirati bilo koji broj posebnih lokacija. Za svako određeno mjesto kreirate vlastiti prilagođeni izbornik.
3. JavaScript LavaLamp set.
Koristi se za stvaranje klizača za vodoravni izbornik vremenske trake. Početni prikaz izbornika može se vidjeti na slici 23.
Slika 23 - Početni prikaz izbornika u JavaScript skupu LavaLamp
4. Postavite JavaScript jQuery Vertical Accordion Menu.
Koristi se za stvaranje klizača za vertikalni navigacijski izbornik.
Pojedinosti o korištenju ovih dodataka opisane su u paragrafu 3.2 – vodič za administratore.
Uvod
Dizajn informacijskih sustava uvijek počinje definiranjem svrhe projekta. Glavni zadatak svakog uspješnog projekta je osigurati da je u trenutku pokretanja sustava i tijekom cijelog razdoblja njegovog rada moguće osigurati:
- potrebna funkcionalnost sustava i stupanj prilagodbe promjenjivim uvjetima njegova funkcioniranja;
- potreban propusnost sustavi;
- potrebno vrijeme odgovora sustava na zahtjev;
- nesmetan rad sustava u potrebnom načinu rada, drugim riječima, spremnost i raspoloživost sustava za obradu zahtjeva korisnika;
- jednostavnost rada i podrška sustava;
- potrebnu sigurnost.
Izvedba je glavni čimbenik koji određuje učinkovitost sustava. Dobar dizajn temelj je sustava visokih performansi.
Dizajn informacijskih sustava pokriva tri glavna područja:
- projektiranje podatkovnih objekata za implementaciju u bazu podataka;
- osmišljavanje programa, ekranskih obrazaca, izvještaja koji će osigurati izvršavanje upita podataka;
- uzimajući u obzir specifično okruženje ili tehnologiju, a to su: topologija mreže, konfiguracija hardvera, korištena arhitektura (datoteka-poslužitelj ili klijent-poslužitelj), paralelna obrada, distribuirana obrada podataka itd.
U stvarnim uvjetima projektiranje je potraga za načinom koji zadovoljava zahtjeve funkcionalnosti sustava pomoću dostupnih tehnologija, uzimajući u obzir zadana ograničenja.
Svaki projekt podliježe brojnim apsolutnim zahtjevima, na primjer, maksimalno vrijeme razvoja projekta, maksimalno financijsko ulaganje u projekt itd. Jedna od poteškoća dizajna je što nije tako strukturiran kao analiza zahtjeva projekta ili implementacija određenog projektantskog rješenja.
Smatra se da se složeni sustav ne može u načelu opisati. To se posebno odnosi na sustave upravljanja poduzećima. Jedan od glavnih argumenata je promjena uvjeta za funkcioniranje sustava, na primjer, direktivna promjena određenih tokova informacija od strane novog vodstva. Drugi argument je opseg projektnog zadatka, koji za veliki projekt može biti stotine stranica, dok tehnički projekt može sadržavati pogreške. Postavlja se pitanje: možda je bolje uopće ne provoditi ankete i ne raditi nikakav tehnički projekt, nego napisati sustav "od nule" u nadi da će doći do neke čudesne podudarnosti želje kupca s onim što su programeri napisali, i također da će sve to raditi stabilno?
Ako pogledate, je li razvoj sustava doista toliko nepredvidiv i je li doista nemoguće doći do informacija o tome? Vjerojatno se kroz seminare može dobiti ideja o sustavu u cjelini io načinima (upravljanju) predviđenim za njegov razvoj. Nakon toga razbiti složeni sustav na jednostavnije komponente, pojednostaviti veze između komponenti, osigurati neovisnost komponenti i opisati sučelja između njih (tako da promjena jedne komponente ne povlači automatski značajna promjena drugu komponentu), kao i mogućnost proširenja sustava i "stubova" za funkcije koje nisu implementirane u jednoj ili drugoj verziji sustava. Na temelju takvih elementarnih razmatranja, opis onoga što bi se trebalo implementirati u informacijski sustav više se ne čini tako nerealnim. Možete pratiti klasične pristupe razvoju informacijskih sustava, od kojih je jedan - shema "vodopada" (slika 1.) - opisan u nastavku. Ukratko će biti razmotreni i neki drugi pristupi razvoju informacijskih sustava, gdje je također prihvatljivo korištenje elemenata opisanih u shemi slapa. Koji pristup od dolje opisanih slijediti (i ima li smisla osmisliti vlastiti pristup) donekle je stvar ukusa i okolnosti.
Životni ciklus softvera je model za njegovo stvaranje i korištenje. Model odražava njegova različita stanja, počevši od trenutka kada se pojavi potreba za ovim softverom pa do trenutka kada je potpuno izvan uporabe za sve korisnike. Poznati su sljedeći modeli životnog ciklusa:
- kaskadni model. Prijelaz u sljedeću fazu znači potpuni završetak posla u prethodnoj fazi.
- Stupanjski model sa srednjom kontrolom. Razvoj softvera provodi se u iteracijama s povratnom spregom između faza. Prilagodbe među fazama mogu smanjiti složenost procesa razvoja u usporedbi s modelom vodopada; životni vijek svake od faza rastegnut je za cijelo razdoblje razvoja.
- spiralni model. Posebna se pažnja posvećuje početnim fazama razvoja - izradi strategije, analizi i dizajnu, gdje je izvedivost određenih tehnička rješenja provjereno i opravdano kroz izradu prototipa (prototipa). Svaki zavoj spirale podrazumijeva izradu određene verzije proizvoda ili bilo koje njegove komponente, pri čemu se specificiraju karakteristike i ciljevi projekta, utvrđuje njegova kvaliteta i planira rad sljedećeg zavoja spirale.
U nastavku ćemo razmotriti neke od shema razvoja projekta.
"Vodopad" - shema razvoja projekta
Dizajn se vrlo često opisuje kao zasebna faza razvoja projekta između analize i razvoja. Međutim, u stvarnosti ne postoji jasna podjela faza razvoja projekta - dizajn u pravilu nema jasno definiran početak i kraj, a često se nastavlja u fazama testiranja i implementacije. Govoreći o fazi testiranja, također treba napomenuti da i faza analize i faza projektiranja sadrže elemente rada ispitivača, na primjer, za dobivanje eksperimentalnog opravdanja za odabir određenog rješenja, kao i za procjenu kriterija kvalitete. rezultirajućeg sustava. U fazi rada prikladno je govoriti o održavanju sustava.
U nastavku ćemo razmotriti svaku od faza, detaljnije se zadržavajući na fazi projektiranja.
Strategija
Definiranje strategije uključuje ispitivanje sustava. Glavni zadatak ankete je procijeniti stvarni opseg projekta, njegove ciljeve i ciljeve, kao i dobiti definicije entiteta i funkcija na visokoj razini.
U ovoj fazi su uključeni visokokvalificirani poslovni analitičari, koji imaju stalan pristup upravljanju tvrtkom; faza uključuje blisku interakciju s glavnim korisnicima sustava i poslovnim stručnjacima. Glavni zadatak interakcije je dobiti najpotpunije informacije o sustavu (potpuno i nedvosmisleno razumijevanje zahtjeva kupaca) i prenijeti te informacije u formaliziranom obliku analitičarima sustava za kasniju fazu analize. Informacije o sustavu u pravilu se mogu dobiti kao rezultat razgovora ili seminara s menadžmentom, stručnjacima i korisnicima. Tako se utvrđuje bit ovog posla, izgledi za njegov razvoj i zahtjevi za sustav.
Po završetku glavne faze istraživanja sustava, tehničari formiraju vjerojatne tehničke pristupe i procjenjuju troškove hardvera, kupljenog softvera i razvoja novog softvera (što se, zapravo, pretpostavlja projektom).
Rezultat faze definiranja strategije je dokument koji jasno navodi što će kupac dobiti ako pristane financirati projekt; kada dobije gotov proizvod (radni raspored); koliko će to koštati (za velike projekte treba sastaviti raspored financiranja u različitim fazama rada). Dokument bi trebao odražavati ne samo troškove, već i koristi, na primjer, vrijeme povrata projekta, očekivani ekonomski učinak (ako se može procijeniti).
Dokument mora opisati:
- ograničenja, rizici, kritični čimbenici koji utječu na uspjeh projekta, na primjer, vrijeme odgovora sustava na zahtjev je zadano ograničenje, a ne poželjni čimbenik;
- skup uvjeta pod kojima bi trebao funkcionirati budući sustav: arhitektura sustava, hardverski i softverski resursi koji se osiguravaju sustavu, vanjski uvjeti za njegovo funkcioniranje, sastav ljudi i rad koji osiguravaju nesmetano funkcioniranje sustava;
- rokovi za završetak pojedinih faza, oblik isporuke radova, sredstva uključena u proces izrade projekta, mjere zaštite informacija;
- opis funkcija koje sustav obavlja;
- budući zahtjevi za sustavom u slučaju njegovog razvoja, na primjer, sposobnost korisnika da radi sa sustavom putem interneta i sl.;
- subjekti potrebni za obavljanje funkcija sustava;
- sučelja i raspodjela funkcija između osobe i sustava;
- zahtjevi za softverske i informacijske komponente softvera, zahtjevi za DBMS (ako se projekt treba implementirati za više DBMS-a, onda zahtjevi za svaki od njih ili opći zahtjevi za apstraktni DBMS i popis DBMS-a preporučenih za ovaj projekt koji zadovoljiti navedene uvjete);
- koji se neće provoditi u okviru projekta.
Radovi koji se obavljaju u ovoj fazi omogućuju nam da odgovorimo na pitanje isplati li se nastaviti ovaj projekt i koje zahtjeve kupaca možemo ispuniti pod određenim uvjetima. Može se pokazati da projekt nema smisla nastaviti, primjerice, jer se određeni zahtjevi ne mogu ispuniti iz nekih objektivnih razloga. Ako se donese odluka da se nastavi s projektom, tada je ideja o opsegu projekta i procjeni troškova već dostupna za sljedeću fazu analize.
Treba napomenuti da u fazi odabira strategije, u fazi analize i tijekom projektiranja, bez obzira na metodu korištenu u izradi projekta, uvijek treba klasificirati planirane funkcije sustava prema važnosti. . Jedan mogući format za predstavljanje takve klasifikacije, MoSCoW, predložen je u Clegg, Dai i Richard Barker, Case Method Fast-track: A RAD Approach, Adison-Wesley, 1994.
Ova skraćenica znači: Mora imati - potrebne funkcije; Trebao bi imati - poželjne funkcije; Mogao imati - moguće funkcije; Neće imati - nedostajuće značajke.
Provedba funkcija druge i treće kategorije ograničena je vremenskim i financijskim okvirom: razvijamo ono što je potrebno, kao i najveći mogući broj funkcija druge i treće kategorije prema prioritetu.
Analiza
Faza analize uključuje detaljno proučavanje poslovnih procesa (funkcija definiranih u fazi odabira strategije) i informacija potrebnih za njihovu provedbu (entiteta, njihovih atributa i odnosa (odnosa)). U ovoj fazi se izrađuje informacijski model, a u sljedećoj fazi projektiranja izrađuje se model podataka.
Sve informacije o sustavu prikupljene u fazi definiranja strategije formaliziraju se i dorađuju u fazi analize. Posebnu pozornost treba posvetiti cjelovitosti prenesenih informacija, analizi informacija na odsutnost proturječnosti, kao i traženju informacija koje se uopće ne koriste ili dupliciraju. Kupac u pravilu ne formira odmah zahtjeve za sustav u cjelini, već formulira zahtjeve za njegove pojedinačne komponente. Obratite pažnju na konzistenciju ovih komponenti.
Analitičari prikupljaju i bilježe informacije u dva međusobno povezana oblika:
- funkcije - informacije o događajima i procesima koji se događaju u poslovanju;
- entiteti – informacije o stvarima koje su važne za organizaciju i o kojima se nešto zna.
Dva klasična rezultata analize su:
- hijerarhija funkcija koja razlaže obradu na sastavne dijelove (što se radi i od čega se sastoji);
- model entitet-odnos (Entry Relationship model, ER-model), koji opisuje entitete, njihove atribute i odnose (relacije) među njima.
Ovi rezultati su neophodni, ali nisu dovoljni. Dovoljni rezultati uključuju dijagrame toka podataka i dijagrame životnog ciklusa entiteta. Vrlo često dolazi do pogrešaka analize kada se pokušava prikazati životni ciklus entiteta u dijagramu ER.
U nastavku ćemo pregledati tri najčešće korištene metodologije strukturne analize:
- Dijagrami entitet-odnos (ERD), koji služe za formaliziranje informacija o entitetima i njihovim odnosima;
- dijagrami toka podataka (Data Flow Diagrams, DFD), koji služe za formaliziranje prikaza funkcija sustava;
- dijagrami prijelaza stanja (State Transition Diagrams, STD), koji odražavaju ponašanje sustava, ovisno o vremenu; Dijagrami životnog ciklusa entiteta pripadaju ovoj klasi dijagrama.
Normalizacija
Kako bi se spriječile anomalije u obradi podataka, koristi se normalizacija. Načela normalizacije za objekte informacijskog modela potpuno su ista kao i za modele podataka.
Dopuštene vrste veza. Pobliže ispitivanje odnosa jedan-na-jedan (slika 7), gotovo uvijek se ispostavi da su A i B zapravo različiti podskupovi istog predmeta ili različitih stajališta o njemu, samo da imaju različita imena i različito su opisani. i atribute.
Odnosi više prema jedan prikazani su na Sl. osam .
I je dovoljno jaka konstrukcija da se unos entiteta B ne može kreirati bez istovremenog stvaranja barem jednog povezanog unosa entiteta A.
II je najčešći oblik komunikacije. Pretpostavlja da svaka pojava entiteta A može postojati samo u kontekstu jedne (i samo jedne) pojave entiteta B. Zauzvrat, pojave B mogu postojati i u vezi s pojavljivanjem entiteta A i bez njega.
III - rijetko se koristi. I A i B mogu postojati bez veze između njih.
Odnosi mnogo-prema-više prikazani su na Sl. 9 .
I - takva se konstrukcija često događa na početku faze analize i znači vezu - ili nije u potpunosti shvaćena i zahtijeva dodatnu dozvolu, ili odražava jednostavan kolektivni odnos - dvostruko povezan popis.
II - rijetko se koristi. Takve veze uvijek su podložne daljnjim detaljima.
Razmotrimo sada rekurzivne veze (slika 10).
Ja - rijetko, ali se javlja. Odražava poveznice alternativnog tipa.
II - često se koristi za opisivanje hijerarhija s bilo kojim brojem razina.
III - odvija se u ranim fazama. Često odražava strukturu "popisa materijala" (međusobno ugniježđenje komponenti). Primjer: svaka KOMPONENTA može se sastojati od jedne ili više (drugih) KOMPONENTI i svaka KOMPONENTA se može koristiti u jednoj ili više (drugih) KOMPONENTI.
Nevažeće vrste veza. Nevažeći tipovi odnosa uključuju sljedeće: obvezni odnos više prema mnogo (slika 11) i skup rekurzivnih odnosa (slika 12).
Obvezni odnos više prema mnogo je u osnovi nemoguć. Takva veza bi značila da nijedna pojava A ne može postojati bez B, i obrnuto. Zapravo, svaka takva konstrukcija uvijek se pokaže pogrešnom.
Dijagrami toka podataka
Logički DFD (slika 13) prikazuje izvore podataka i ponore (odredišta) izvan sustava, identificira logičke funkcije (procese) i grupe elemenata podataka koji povezuju jednu funkciju s drugom (tokovi), a također identificira pohranu podataka (akumulatore), kojima se vrši pristup. Strukture protoka podataka i definicije njihovih komponenti pohranjuju se i raščlanjuju u rječnik podataka. Svaki booleova funkcija(proces) može se izbušiti pomoću DFD niske razine; kada daljnji detalji više nisu korisni, prelazi se na izražavanje logike funkcije pomoću specifikacije procesa (mini-specifikacija). Sadržaj svake trgovine također je pohranjen u rječnik podataka, a model podataka trgovine izložen je pomoću ER dijagrama.
Konkretno, DFD ne prikazuje procese koji kontroliraju stvarni protok podataka i ne pravi razliku između valjanih i nevažećih putova. DFD sadrže mnoge korisna informacija, i pored toga:
- omogućuju vam da prezentirate sustav u smislu podataka;
- ilustrirati vanjske mehanizme za unos podataka koji bi zahtijevali posebna sučelja;
- omogućuju predstavljanje automatiziranih i ručnih procesa sustava;
- izvršiti particioniranje cijelog sustava usmjereno na podatke.
Tokovi podataka koriste se za modeliranje prijenosa informacija (ili čak fizičkih komponenti) s jednog dijela sustava na drugi. Tokovi u dijagramima prikazani su imenovanim strelicama, strelice pokazuju smjer toka informacija. Ponekad se informacija može kretati u jednom smjeru, obraditi se i vratiti svom izvoru. Takva se situacija može modelirati ili s dva različita toka, ili s jednim dvosmjernim.
Proces pretvara ulazni tok u izlazni tok u skladu s radnjom specificiranom imenom procesa. Svaki proces mora imati jedinstveni broj za referencu unutar dijagrama. Ovaj se broj može koristiti zajedno s brojem dijagrama kako bi se osigurao jedinstveni indeks procesa u cijelom modelu.
Pohrana podataka (pohrana podataka) omogućuje definiranje podataka u brojnim područjima koja će biti pohranjena u memoriji između procesa. Zapravo, pohrana predstavlja "kriške" protoka podataka u vremenu. Informacije koje sadrži mogu se koristiti u bilo kojem trenutku nakon što su definirane, a podaci se mogu birati bilo kojim redoslijedom. Ime repozitorija treba identificirati njegov sadržaj. U slučaju kada tok podataka ulazi (napušta) pohranu i njegova struktura odgovara strukturi pohrane, ona mora imati isto ime, što ne mora biti prikazano u dijagramu.
Vanjski entitet (terminator) predstavlja entitet izvan konteksta sustava, koji je izvor ili primatelj podataka sustava. Njezino ime mora sadržavati imenicu, kao što je "Klijent". Pretpostavlja se da objekti predstavljeni takvim čvorovima ne bi trebali sudjelovati ni u kakvoj obradi.
Neki principi za provjeru kvalitete i cjelovitosti informacijskog modela
(izvor - Richard Barker, Metoda slučaja: Modeliranje odnosa entiteta, Addison-Wesley, 1990.)
Ako želite stvoriti visokokvalitetan model, morat ćete pribjeći pomoći analitičara koji su dobro upućeni u CASE tehnologiju. Međutim, to ne znači da bi samo analitičari trebali biti uključeni u izgradnju i kontrolu informacijskog modela. Od velike pomoći može biti i pomoć kolega. Uključite ih u provjeru cilja i u detaljnu studiju izgrađenog modela, kako u smislu logike tako i u smislu uzimanja u obzir aspekata predmetnog područja. Većina ljudi lakše pronalazi nedostatke u tuđem radu.
Redovito prezentirajte svoj informacijski model ili njegove pojedinačne fragmente za koje sumnjate na odobravanje korisnika. Obratite posebnu pozornost na iznimke od pravila i ograničenja.
Kvaliteta entiteta
Glavno jamstvo kvalitete entiteta je odgovor na pitanje je li predmet doista entitet, odnosno važan objekt ili pojava, o kojoj bi se podaci trebali pohraniti u bazi podataka.
Popis pitanja za provjeru za entitet:
- Odražava li naziv entiteta bit ovog objekta?
- Postoji li raskrižje s drugim entitetima?
- Postoje li barem dva atributa?
- Ne postoji li ukupno više od osam atributa?
- Postoje li sinonimi/homonimi za ovaj entitet?
- Je li entitet u potpunosti definiran?
- Postoji li jedinstveni identifikator?
- Postoji li barem jedna veza?
- Postoji li barem jedna funkcija za stvaranje, pretraživanje, ažuriranje, brisanje, arhiviranje i korištenje vrijednosti entiteta?
- Postoji li povijest promjena?
- Postoji li usklađenost s načelima normalizacije podataka?
- Postoji li isti entitet u drugom aplikacijskom sustavu, možda pod drugim imenom?
- Je li suština previše opća?
- Je li razina generalizacije utjelovljena u njemu dovoljna?
Popis probirnih pitanja za podvrstu:
- Ima li preklapanja s drugim podtipovima?
- Ima li podtip neke atribute i/ili odnose?
- Imaju li svi svoje jedinstvene identifikatore ili svi nasljeđuju jedan od supertipa?
- Postoji li iscrpan skup podtipova?
- Nije li podtip primjer pojave entiteta?
- Znate li za neke atribute, odnose i uvjete koji razlikuju ovaj podtip od drugih?
Kvaliteta atributa
Potrebno je utvrditi jesu li to stvarno atributi, odnosno opisuju li na ovaj ili onaj način ovaj entitet.
Popis sigurnosnih pitanja za atribut:
- Je li naziv atributa jednina imenica koja odražava bit svojstva označenog atributom?
- Ne uključuje li naziv atributa naziv entiteta (ne bi trebao)?
- Ima li atribut samo jednu vrijednost odjednom?
- Nedostaju li duplicirane vrijednosti (ili grupe)?
- Jesu li opisani format, duljina, valjane vrijednosti, algoritam izvođenja itd.?
- Može li ovaj atribut biti izostavljeni entitet koji bi bio koristan za drugi aplikacijski sustav (postojeći ili predloženi)?
- Postoji li opis za svaku uključenu stranu, odražava li točno sadržaj odnosa i uklapa li se u prihvaćenu sintaksu?
- Jesu li uključene samo dvije strane?
- Je li za svaku stranu određen stupanj povezanosti i obveze?
- Je li dopuštena struktura veze?
- Nije li suvišno?
- Ne mijenja li se s vremenom?
- Ako je veza obvezna, odražava li uvijek odnos prema entitetu koji predstavlja suprotnu stranu?
- Imaju li svi krajevi veze pokriveni ekskluzivnim lukom isti tip povezivanja?
- Odnose li se svi na isti entitet? riža. 15) takva dekompozicija. Razmotrimo najjednostavniji problem izdavanja računa kupcu kada je roba puštena iz skladišta, pod uvjetom da je skup robe koji kupac želi kupiti već poznat (nećemo razmatrati u ovaj primjer problem odabira proizvoda).
Moramo otkriti odražavaju li odnosi stvarno važne odnose uočene između entiteta.
Popis verifikacijskih pitanja za komunikaciju:
Nije li veza prijenosna?
Je li dizajn veze jedan od rijetko korištenih?
Za ekskluzivno udruženje:
Očito se operacija odabira i obračuna popusta može rastaviti i na manje operacije, kao što je izračun popusta za vjernost (kupac kupuje robu na duže vrijeme) i obračun popusta na količinu kupljene robe. Atomske funkcije su detaljno opisane, na primjer pomoću DFD-a i STD-a. Očito, takav opis funkcija ne isključuje dodatni verbalni opis (na primjer, komentare).
Treba napomenuti da se u fazi analize treba obratiti pozornost na funkcije analize i obrade mogućih pogrešaka i odstupanja od očekivanog standarda sustava. Treba identificirati najkritičnije procese za rad sustava i za njih treba osigurati posebno rigoroznu analizu pogrešaka. Rukovanje pogreškama DBMS-a (povratni kodovi) u pravilu je zaseban skup funkcija ili jedna funkcija.
Rafiniranje strategije
U fazi analize dorađuju se hardver i softver odabrani za konačnu implementaciju. Za to se mogu uključiti ispitne skupine i tehnički stručnjaci. Prilikom projektiranja informacijskog sustava važno je uzeti u obzir daljnji razvoj sustava, na primjer, povećanje volumena obrađenih podataka, povećanje intenziteta protoka zahtjeva, promjene u zahtjevima za pouzdanošću. informacijskog sustava.
U fazi analize određuju se skupovi modela zadataka za dobivanje usporednih karakteristika različitih DBMS-a koje su razmatrane u fazi određivanja strategije implementacije informacijskog sustava. U fazi određivanja strategije može se odabrati jedan DBMS. Već u fazi analize postoji mnogo više podataka o sustavu, a oni su detaljniji. Dobiveni podaci, kao i karakteristike koje su prenijele ispitne grupe, mogu pokazati da je izbor DBMS-a u fazi određivanja strategije bio pogrešan te da odabrani DBMS ne može zadovoljiti određene zahtjeve informacijskog sustava. Isti podaci mogu se dobiti iu pogledu izbora hardverske platforme i operacijski sustav. Dobivanje takvih rezultata pokreće promjenu podataka dobivenih u fazi utvrđivanja strategije, na primjer, procjena troškova za projekt se ponovno izračunava.
Izbor razvojnih alata također se specificira u fazi analize. Budući da faza analize daje potpuniju sliku informacijskog sustava nego u fazi definiranja strategije, plan rada se može prilagoditi. Ako razvojni alat odabran u prethodnoj fazi ne dopušta da se jedan ili drugi dio posla završi u navedenom roku, tada se donosi odluka o promjeni rokova (u pravilu se radi o povećanju vremena razvoja) ili za promjenu razvojnog alata. Prilikom odabira jednog ili drugog alata treba voditi računa o prisutnosti visokokvalificiranog osoblja koje posjeduje odabrane razvojne alate, kao i prisutnost administratora odabranog DBMS-a. Ove preporuke će također precizirati podatke faze odabira strategije (skup uvjeta pod kojima bi budući sustav trebao funkcionirati).
Također su navedena ograničenja, rizici, kritični čimbenici. Ako se u informacijskom sustavu implementiranom korištenjem DBMS-a i softverskih alata odabranih u fazi utvrđivanja strategije ne mogu zadovoljiti bilo koji zahtjevi, tada se također pokreće dorada i promjena dobivenih podataka (u konačnici, procjene troškova i planova rada, a eventualno i promjena u zahtjevima kupaca za sustavom, na primjer, njihovo slabljenje). Detaljnije su opisane značajke koje neće biti implementirane u sustav.
ComputerPres 9 "2001
Trenutno je informacijska industrija postala nova tehnološka industrija, koja korisnicima donosi velike prednosti. Stoga, u modernim uvjetimačelnik organizacije mora imati znanja o metodološkim osnovama stvaranja IS-a. Poznavanje metodoloških osnova za stvaranje i korištenje IS-a usko je povezano s razvojem i unapređenjem procesa upravljanja.
Utemeljitelj kibernetike (sustavne znanosti i metode upravljanja) je Norbert Wiener (SAD). Radovi njegovih sljedbenika postali su temelj teorije automatskog upravljanja. Ovo je znanost o općim zakonima primanja, pohranjivanja, prijenosa i transformacije informacija u složenim sustavima upravljanja. Korištenje računalne tehnologije za rješavanje upravljačkih problema dovelo je do razvoja teorije informacija, teorije kodiranja te se formirao samostalan znanstveni smjer informatike. Rezultati ovih istraživanja bili su temelj za razvoj metodologije za korištenje hardvera i softvera za rješavanje problema različitih praktičnih smjerova.
Gospodarski objekti počeli su se smatrati složenim sustavima, a njihovo upravljanje poistovjećivalo se s informacijskim procesom. Intenzivan razvoj sposobnosti računalne tehnologije i opsega njezine primjene doveo je do stvaranja čovjeko-strojnih IS-a u gospodarskim objektima. Svrha IS-a nije bila samo informacijska podrška proizvodnim i poslovnim procesima, rješavanje funkcionalnih upravljačkih zadataka unutar organizacije, već i informacijska interakcija između različitih srodnih organizacija u proizvodnom, gospodarskom i informacijskom aspektu.
Akademik V.M. Glushkov, koji je formulirao znanstvene i metodološke odredbe i praktične preporuke za stvaranje automatiziranog informacijskog sustava. Glavna načela jedinstvenih metodoloških pristupa su:
1. Načelo dosljednosti koje je najvažnije u stvaranju, djelovanju i razvoju IS-a. Proučavani ekonomski objekt razmatra kao cjelinu. Istodobno, utvrđuje smjerove proizvodnih i gospodarskih aktivnosti organizacije i specifične funkcije koje ona provodi; otkriva različiti tipovi veze između njegovih strukturnih elemenata koje osiguravaju cjelovitost sustava. Načelo dosljednosti uključuje provođenje analize dvaju aspekata u organizaciji, a to su makro i mikroanaliza. U makroanalizi se sustav i (ili) njegovi "elementi" smatraju dijelom sustava višeg reda. Posebna se pozornost pridaje informacijskim vezama: uspostavljaju se njihovi smjerovi kretanja, one veze koje su određene svrhom operacije. i proučavanje objekta identificiraju se i analiziraju, a zatim najpoželjniji, uzeti u obzir u procesu projektiranja IS-a. U makroanalizi se proučavaju svi aspekti aktivnosti organizacije, analiziraju se njezine strukturne komponente (uključujući aktivnosti na svakom radnom mjestu) s pogled na njihove funkcionalne karakteristike koje se očituju kroz odnose s drugim elementima i vanjskim okruženjem.
Kod projektiranja IS-a za organizacijsku strukturu upravljanja gospodarskim objektom najkarakterističnija je višerazinska hijerarhijska struktura. Hijerarhijska struktura za svaku razinu sustava omogućuje različite kombinacije lokalnih kriterija optimalnosti s globalnim kriterijem optimalnosti za funkcioniranje sustava kao cjeline; osigurava relativnu fleksibilnost upravljačkog sustava i sposobnost prilagodbe promjenjivim uvjetima; povećava pouzdanost zbog mogućnosti uvođenja elementarne redundancije, racionalizirajući smjerove protoka informacija. Prednosti hijerarhijskih struktura pridonijele su njihovoj raširenosti u sustavima upravljanja i odredile organizacijski i funkcionalni pristup stvaranju IS-a. Istodobno stečeno iskustvo utjecalo je na suvremeni procesni pristup u projektiranju IS-a.
Praktični značaj primjene principa sustava leži u činjenici da omogućuje, u pristupačnom obliku za analizu, ne samo prepoznavanje interesa kreatora sustava, već i korištenje računalne simulacije za proučavanje ponašanja sustava. projektiran pod posebnim uvjetima koje je odredio eksperimentator. Stoga se izrada IS-a temelji na metodi modeliranja, koja omogućuje pronalaženje najprihvatljivijih i najrazumnijih projektnih rješenja, mogućnosti izgradnje sustava i na taj način osigurava najučinkovitiji rad gospodarskog objekta.
2. Načelo razvoja, koje leži u činjenici da se IS stvara uzimajući u obzir mogućnost stalnog nadopunjavanja i ažuriranja funkcija sustava i vrste njegove podrške. Njegova je suština da razvojni procesi proizvodnje i upravljanja postaju složeniji i restrukturiraju organizacijske strukture gospodarskih objekata - to uzrokuje potrebu za povećanjem računalne snage IS-a, opremajući ih novim hardverom i softverom za stalno dopunjavanje i ažuriranje zadataka rješavaju, proširuju informacijski fond, stvaraju u obliku baze podataka i skladišta podataka, baze znanja.
3. Načelo informiranja, koje je usmjereno na detaljno i sveobuhvatno proučavanje informacija i informacijskih procesa koji prate procese upravljanja u gospodarskom objektu. Informacija se proučava u semantičkom (značenju), sintaktičkom (znak) i pragmatičkom (korisnom) aspektu. Osim toga, proučavanje informacija potrebno je za projektiranje automatiziranih radnih stanica, sustava za prijenos, pohranu i obradu podataka, zaštitu informacija, pri čemu su glavna znanja o obujmu, sadržaju i korisnosti informacija.
Trenutno se objektno orijentirana metoda za modeliranje informacijskih procesa i automatizaciju projektantskog rada temelji na informacijskom pristupu za analizu procesa upravljanja i projektiranje elektroničkih tokova informacija.
4. Načelo kompatibilnosti, koje je osigurati interakciju IS-a razne vrste, imenovanja, razine u procesu funkcioniranja gospodarskog objekta. Stoga u procesu projektiranja treba osigurati sistemsko jedinstvo metodoloških pristupa u rješavanju problema informacijske, tehničke, softverske kompatibilnosti svih korištenih IS-a. Jedinstvo metodoloških pristupa očituje se u pravnim dokumentima koji uređuju proces izrade, dokumentiranja, prihvaćanja i rada IS-a. To su međunarodni i domaći standardi (GOST), industrijski i resorni regulatorni materijali, propisi, protokoli, standardi organizacija.
Široko se koriste standardi koji reguliraju jezične alate za obradu informacija, komunikacijske tehnologije i organizaciju računalstva, međudjelovanja objekata i slično.
5. Načelo standardizacije i unifikacije, koje se sastoji u potrebi korištenja standardnih, unificiranih i standardiziranih elemenata funkcioniranja IS-a. To se prvenstveno odnosi na komponente informacijskih, tehničkih, softverskih i drugih podsustava IT podrške. Ovaj princip omogućuje smanjenje troškova vremena, rada i troškova za stvaranje IS-a uz maksimalno moguće korištenje akumuliranog iskustva u oblikovanju projektantskih rješenja i uvođenje automatizacije projektantskog rada, osigurava interakciju IS-a u više aspekata.
6. Princip dekompozicije, koji se temelji na podjeli sustava na dijelove i dodjeli pojedinačnih radnih paketa, stvara uvjete za učinkovitiju analizu trenutnog stanja upravljačke aktivnosti, proučavanje značajki rješavanja funkcionalnih problema. za daljnje modeliranje specifičnih aspekata upravljačke aktivnosti i njihovo prenošenje na automatiziranu tehnologiju. Princip se koristi kako u proučavanju svojstava elemenata i sustava u cjelini, tako i u stvaranju IS-a na bazi nove informacijske tehnologije.
7. Načelo učinkovitosti, a to je postizanje racionalne ravnoteže između troškova stvaranja IS-a i ciljanog učinka dobivenog tijekom njegova rada.
Opis životnog ciklusa informacijskog sustava uključuje korištenje takvih koncepata:
Proces - lanac radova koji se uzastopno izvode;
Faze su uzastopna vremenska razdoblja tijekom kojih se rad obavlja. Tijekom faze mogu se obavljati poslovi vezani uz različite procese. Koncept njegovog životnog ciklusa (LC) u središtu je stvaranja i korištenja automatiziranog informacijskog sustava za upravljanje gospodarskim objektom. Životni ciklus modela za stvaranje i korištenje automatiziranog sustava upravljanja informacijama za gospodarski objekt, koji odražava njegova različita stanja, počevši od trenutka nastanka i potrebe za njim i završavajući s trenutkom potpunog izlaska iz upotrebe svi korisnici bez iznimke.
Tradicionalno se razlikuju sljedeće glavne faze životnog ciklusa AIS-a:
Analiza zahtjeva;
Oblikovati;
Programiranje / Implementacija;
Testiranje i otklanjanje pogrešaka;
Rad i održavanje.
Razmotrimo detaljnije glavne faze životnog ciklusa AIS-a:
1. Analiza zahtjeva prva je faza razvoja AIS-a, gdje su zahtjevi kupaca specificirani, formalizirani i dokumentirani. Zapravo, u ovoj fazi se daje odgovor na pitanje: "Što bi budući sustav trebao raditi?", i to je uspjeh cijelog projekta. U praksi stvaranja velikih sustava ima mnogo primjera neuspješne implementacije projekta upravo zbog nepotpunosti i nejasnoće definiranja zahtjeva sustava.
Popis zahtjeva za AIS trebao bi uključivati:
1) skup uvjeta pod kojima bi trebao funkcionirati budući sustav (hardverski i softverski resursi osigurani sustavu; vanjski uvjeti za njegovo funkcioniranje, sastav zaposlenika i poslovi u vezi s njim)
2) opis funkcija koje sustav treba obavljati;
3) ograničenja u procesu razvoja (direktivni rokovi za završetak pojedinih faza, raspoloživi resursi, organizacijski postupci i mjere za osiguranje zaštite informacija).
Svrha analize je transformirati opće, nejasno znanje o zahtjevima za budući sustav u točne (ako je moguće) definicije.
Rezultat faze trebao bi biti model zahtjeva sustava (odnosno projekt sustava), što znači:
1) arhitektura sustava, njegove funkcije, vanjski uvjeti, podjela funkcija između hardverskih i softverskih dijelova;
2) sučelja i razdvajanje funkcija između osobe i sustava;
3) zahtjevi za softverske i informacijske komponente programskog dijela: potrebni hardverski resursi, zahtjevi baze podataka, fizičke karakteristike softverska komponenta, njihova sučelja.
Model zahtjeva trebao bi uključivati;
1) cjeloviti funkcionalni model zahtjeva za budući sustav s dubinom obrade do razine svake operacije svakog službenika;
2) specifikacije operacija niže razine;
3) paket izvješća i dokumenata o funkcionalnom modelu, uključujući opis objekta modeliranja, popis podsustava, zahtjeve za metode i sredstva komunikacije za razmjenu informacija između komponenti, zahtjeve za karakteristike međupovezivanja sustava sa susjednim sustavima , zahtjevi za funkcije sustava;
4) konceptualni informacijski model zahtjeva;
5) paket izvješća i dokumenata o informacijskom modelu;
6) arhitektura sustava u odnosu na konceptualni informacijski model;
7) prijedlozi za organiziranje strukture za potporu sustava.
Dakle, model zahtjeva sadrži funkcionalne, informacijske i, eventualno, modele događaja (ako je ciljni sustav sustav u stvarnom vremenu). To pruža niz prednosti u odnosu na tradicionalni model, a to su:
1) Tradicionalni razvoj karakterizira provedba početnih faza na zanatsko neformalizirane načine. Stoga korisnici i korisnici mogu prvi put vidjeti sustav nakon što je već uvelike implementiran. Naravno, ovaj će sustav biti drugačiji od onoga što su očekivali. Stoga, da bi se nastavilo odvijati još nekoliko iteracija njegovog razvoja ili modifikacije, potrebni su dodatni (i značajni) troškovi novca i vremena. Ključ za rješavanje ovog problema je model zahtjeva koji dopušta
Opisati, "vidjeti" i ispraviti budući sustav prije nego što se fizički implementira;
Smanjiti troškove razvoja i implementacije sustava;
Ocijeniti razvoj u smislu vremena i rezultata;
Postizanje međusobnog razumijevanja svih sudionika u radu (kupaca, korisnika, programera, programera)
Poboljšati kvalitetu baze podataka koja se razvija, odnosno: izvršiti njezinu funkcionalnu dekompoziciju i dizajnirati optimalnu strukturu integrirane baze podataka.
2) Model zahtjeva je potpuno neovisan i odvojen od konkretnih programera, ne zahtijeva održavanje od strane njegovih kreatora i može se bezbolno prenijeti na druge. Štoviše, ako poduzeće iz nekog razloga nije spremno implementirati sustav na temelju modela zahtjeva, može se ostaviti "na polici" dok se ne ukaže potreba.
3) Model zahtjeva može se koristiti za samostalan razvoj ili korekciju softverskih alata koje su na njegovoj osnovi već implementirali programeri odjela za automatizaciju poduzeća.
4) Model zahtjeva može se koristiti za automatiziranu i brzu obuku novih zaposlenika u određenom području poduzeća, budući da je njegova tehnologija sadržana u modelu.
Faza analize zahtjeva najvažnija je među svim fazama životnog ciklusa. Značajno utječe na sve naredne faze, dok ostaje najmanje proučavan i shvaćen proces. U ovoj fazi, prvo, morate razumjeti što točno treba učiniti, a drugo, dokumentirati, jer ako zahtjevi nisu fiksni i dostupni sudionicima projekta, onda se čini da ne postoje. Istodobno, jezik na kojem su formulirani zahtjevi trebao bi biti prilično jednostavan i razumljiv kupcu.
2. Razvoj projektni zadatak se izvodi nakon izgradnje modela, sadrži zahtjeve za budući sustav. Na temelju toga se razvija projektni zadatak za stvaranje sustava koji uključuje:
Zahtjevi za automatizirana radna mjesta, njihov sastav i struktura, kao i metode i sheme informacijske interakcije među njima;
Izrada zahtjeva za tehnička sredstva;
Definiranje softverskih zahtjeva;
Razvoj topologije, sastava i strukture lokalne mreže;
Zahtjevi za faze i uvjete rada.
3. Dizajn. Ova faza daje odgovor na pitanje: "Kako (na koji način) će sustav ispuniti zahtjeve za to? Zadatak ove faze
Postoje studije strukture sustava 1 logičkih odnosa elemenata, a pitanja vezana za implementaciju na određenoj platformi ovdje se ne obrađuju. Dizajn se promatra kao iterativni proces dobivanja logičkog modela sustava, zajedno s rigoroznim ciljevima postavljenim za njega, kao i pisanjem specifikacija fizičkog sustava, zadovoljava te zahtjeve. Ova se faza obično dijeli u dvije podfaze:
Dizajn arhitekture sustava, uključujući razvoj strukture i sučelja komponenti, koordinaciju funkcija i tehnički zahtjevi komponentama, metodama i standardima dizajna;
Detaljni dizajn, koji uključuje razvoj specifikacija za svaku komponentu, sučelja između komponenti, razvoj zahtjeva za ispitivanje i razvoj plana integracije komponenti.
Drugim riječima, dizajn je faza životnog ciklusa, koja određuje kako implementirati zahtjeve za LES generirane i fiksirane u fazi analize. Kao rezultat toga, trebao bi se izgraditi model implementacije koji pokazuje kako će sustav zadovoljiti zahtjeve koji su mu predočeni (bez tehničkih detalja). Zapravo, model implementacije je razvoj i usavršavanje modela zahtjeva, naime, dizajn je most između analize i implementacije.
4. Implementacija (programiranje/prilagodba). U ovoj fazi, LES se stvara kao kompleks softvera i hardvera (počevši od projektiranja i izrade telekomunikacijske infrastrukture do razvoja i instalacije aplikacija).
5. Testiranje i otklanjanje pogrešaka. Ispravnost AIS-a njegovo je najvažnije svojstvo i glavna briga programera. U idealnom slučaju, ispravnost 1C znači odsutnost pogrešaka u njemu. Međutim, to nije moguće za većinu složenih softverskih proizvoda (svaki program sadrži barem jednu grešku). Stoga se pod "ispravnim" obično podrazumijeva softverski proizvod koji radi u skladu sa zahtjevima koji mu se postavljaju, odnosno proizvod za koji još nisu pronađeni takvi uvjeti u kojima će biti neispravan.
Utvrđivanje ispravnosti je Glavni cilj razmatraju se faze životnog ciklusa. Treba napomenuti da je faza testiranja i otklanjanja pogrešaka jedna od najzahtjevnijih, najzamornijih i nepredvidivih faza razvoja IS-a. U prosjeku, za razvoj tradicionalnim metodama, ova faza traje od 1/2 do 1/3 cjelokupnog vremena razvoja. S druge strane, testiranje i otklanjanje pogrešaka je ozbiljan problem: u nekim slučajevima testiranje i otklanjanje pogrešaka programa zahtijeva nekoliko puta više vremena od samog programiranja.
Testiranje je skup postupaka i radnji dizajniranih da pokažu ispravan rad IS-a u zadanim načinima rada i vanjskim uvjetima. Svrha testiranja je otkriti prisutnost pogrešaka ili uvjerljivo pokazati njihovu odsutnost, što je moguće samo u nekim trivijalnim slučajevima. Važno je razlikovati testiranje i prateći koncept "debugginga". Otklanjanje pogrešaka skup je postupaka i radnji koje počinju identificiranjem same činjenice pogreške i završavaju određivanjem točne lokacije, prirode te pogreške i načina na koji je ispraviti.
Najvažnija i najčešće korištena u praksi je metoda determinističkog ispitivanja. U ovom slučaju, specifični početni podaci koriste se kao standardi ispitivanja, koji se sastoje od međusobno povezanih ulaznih i rezultirajućih vrijednosti te ispravnih sekvenci njihove obrade. U postupku ispitivanja sa zadanim početnim vrijednostima potrebno je utvrditi korespondenciju rezultata njihove obrade s referentnim vrijednostima.
Složeni sustavi zahtijevaju veliki broj testova, a nastaje problem procjene njihovog potrebnog broja i korištenje metoda za njihovo smanjenje. Stoga je testiranje (kao i svaku drugu vrstu aktivnosti) preporučljivo planirati. Plan testiranja treba sadržavati:
1) formuliranje ciljeva testiranja;
2) ispitivanje kriterija kvalitete za ocjenu njegovih rezultata;
3) strategiju ispitivanja koja osigurava postizanje propisanih kriterija kvalitete;
4) potreba za resursima za postizanje zadanog kriterija kvalitete za odabranu strategiju.
Postoje sustavi za automatizaciju testiranja i otklanjanja pogrešaka (Satna). Oni su složeni skup algoritamskih i softverskih alata dizajniranih da automatiziraju analizu AIS-a, testiranje, otklanjanje pogrešaka i procjenu njegove kvalitete, te omogućuju olakšavanje modifikacije komponenti AIS-a, osiguravaju otkrivanje pogrešaka u ranim fazama otklanjanja pogrešaka, povećati postotak grešaka koje se automatski pronalaze.
6. Rad i održavanje. Glavni zadaci ove faze su:
Osiguravanje stabilnosti sustava i očuvanje informacija – administracija;
Pravovremena modernizacija i popravak pojedinih elemenata - tehnička podrška;
Prilagodba mogućnosti sustava, operiranog trenutnim potrebama poslovanja poduzeća - razvoj sustava.
Ovi radovi moraju biti uključeni u operativni plan informatizacije poduzeća, koji se mora formirati u skladu sa svim uvjetima strateškog plana. U suprotnom se unutar postojećeg sustava mogu pojaviti fragmenti, što će u budućnosti onemogućiti učinkovit rad sustava. Sada je u inozemstvu uobičajena praksa prijenos tehničke podrške i djelomično administrativnih funkcija na dobavljače sustava ili integratore sustava. Ova praksa se zove "outsourcing". Često se funkcije poput stvaranja i održavanja rezervnih skladišta podataka i izvršnih centara za kritične poslovne aplikacije koje se aktiviraju u slučaju prirodne katastrofe ili drugih posebnih uvjeta također prenose na poduzeća treće strane u okviru outsourcinga.
Posebnu pozornost u fazi eksploatacije i održavanja treba posvetiti pitanjima osposobljavanja osoblja i, sukladno tome, planiranju ulaganja u ovaj proces.
Životni ciklus formira se prema principu top-down dizajna i obično ima iterativni karakter: implementirane faze, počevši od prve, ciklički se ponavljaju u skladu s promjenama zahtjeva i vanjskih uvjeta, uvođenjem ograničenja, itd. U svakoj fazi životnog ciklusa generira se određeni skup dokumenata i tehničkih rješenja, au isto vrijeme za svaku fazu su dokumenti i odluke dobiveni u prethodnoj fazi početni. Svaka faza završava provjerom generiranih dokumenata i rješenja kako bi se provjerila njihova usklađenost s izlazom.
Postojeći modeli životnog ciklusa određuju redoslijed kojim se faze izvode tijekom razvoja, kao i kriterije za prelazak iz faze u fazu. U skladu s tim, sljedeća tri modela ZhShch4] se najviše koriste:
1. Kaskadni model (70-80-e) predviđa prijelaz u sljedeću fazu nakon završetka rada u prethodnoj fazi i karakterizira ga jasno razdvajanje podataka i procesa obrade (slika 2.6).
Riža. 2.6. Kaskadni model životnog ciklusa IP-a
2. Stupanjski model sa srednjim upravljanjem (80-85) - iterativni razvojni model s povratnim petljama između faza. Prednost ovog modela je u tome što prilagodbe između faza pružaju manji intenzitet rada u usporedbi s modelom vodopada; s druge strane, životni vijek svake od faza produljuje se tijekom cijelog razvojnog razdoblja.
3. Spiralni model (86 - 90-e) - fokusira se na početne faze životnog ciklusa: analizu zahtjeva, dizajn specifikacije, prethodni i detaljni dizajn. U tim se fazama provjerava i opravdava izvedivost tehničkih rješenja izradom prototipa. Svaki zavoj spirale odgovara modelu korak-po-korak za stvaranje fragmenta ili verzije sustava, na kojem se specificiraju ciljevi i karakteristike projekta, utvrđuje njegova kvaliteta i rad sljedećeg zavoja. spirala je planirana. Tako se detalji projekta produbljuju i dosljedno konkretiziraju, te se kao rezultat odabire razumna opcija koja se dovodi u realizaciju (slika 2.7.).
Riža. 2.7. Spiralni model životnog ciklusa IP-a
Stručnjaci primjećuju sljedeće prednosti spiralnog modela:
Akumulacija i ponovna upotreba softverskih alata, modela i prototipova;
Usmjerenost na razvoj i modificiranje sustava tijekom njegovog projektiranja;
Analiza rizika i troškova u procesu projektiranja.
Pri korištenju spiralnog modela dolazi do akumulacije i ponovne upotrebe projektantskih rješenja, projektantskih alata, modela i prototipova informacijskog sustava i informacijske tehnologije; provodi se usmjerenje na razvoj i modifikaciju sustava i tehnologije u procesu njihova projektiranja; analiza rizika i troškova provodi se u procesu projektiranja sustava i tehnologija.
Značajke projektiranja informacijske tehnologije. Suvremena informacijska tehnologija implementirana je u uvjetima projektiranog informacijskog sustava.
Aspekti dizajna: tehnički (hardverski i komunikacijski kompleks), softversko-matematički (modeli i programi), metodički (skup sredstava za implementaciju upravljačkih funkcija), organizacijski (opis tijeka rada i regulative za djelovanje kontrolnog aparata) , operativni (skup tehnoloških, logičkih, aritmetičkih radnji, implementiranih automatski).
Uvod
Dizajn informacijskih sustava uvijek počinje definiranjem svrhe projekta. Glavni zadatak svakog uspješnog projekta je osigurati da je u trenutku pokretanja sustava i tijekom cijelog razdoblja njegovog rada moguće osigurati:
- potrebna funkcionalnost sustava i stupanj prilagodbe promjenjivim uvjetima njegova funkcioniranja;
- potrebna propusnost sustava;
- potrebno vrijeme odgovora sustava na zahtjev;
- nesmetan rad sustava u potrebnom načinu rada, drugim riječima, spremnost i raspoloživost sustava za obradu zahtjeva korisnika;
- jednostavnost rada i podrška sustava;
- potrebnu sigurnost.
Izvedba je glavni čimbenik koji određuje učinkovitost sustava. Dobar dizajn temelj je sustava visokih performansi.
Dizajn informacijskih sustava pokriva tri glavna područja:
- projektiranje podatkovnih objekata za implementaciju u bazu podataka;
- osmišljavanje programa, ekranskih obrazaca, izvještaja koji će osigurati izvršavanje upita podataka;
- uzimajući u obzir specifično okruženje ili tehnologiju, a to su: topologija mreže, konfiguracija hardvera, korištena arhitektura (datoteka-poslužitelj ili klijent-poslužitelj), paralelna obrada, distribuirana obrada podataka itd.
U stvarnim uvjetima projektiranje je potraga za načinom koji zadovoljava zahtjeve funkcionalnosti sustava pomoću dostupnih tehnologija, uzimajući u obzir zadana ograničenja.
Svaki projekt podliježe brojnim apsolutnim zahtjevima, na primjer, maksimalno vrijeme razvoja projekta, maksimalno financijsko ulaganje u projekt itd. Jedna od poteškoća dizajna je što nije tako strukturiran kao analiza zahtjeva projekta ili implementacija određenog projektantskog rješenja.
Smatra se da se složeni sustav ne može u načelu opisati. To se posebno odnosi na sustave upravljanja poduzećima. Jedan od glavnih argumenata je promjena uvjeta za funkcioniranje sustava, na primjer, direktivna promjena određenih tokova informacija od strane novog vodstva. Drugi argument je opseg projektnog zadatka, koji za veliki projekt može biti stotine stranica, dok tehnički projekt može sadržavati pogreške. Postavlja se pitanje: možda je bolje uopće ne provoditi ankete i ne raditi nikakav tehnički projekt, nego napisati sustav "od nule" u nadi da će doći do neke čudesne podudarnosti želje kupca s onim što su programeri napisali, i također da će sve to raditi stabilno?
Ako pogledate, je li razvoj sustava doista toliko nepredvidiv i je li doista nemoguće doći do informacija o tome? Vjerojatno se kroz seminare može dobiti ideja o sustavu u cjelini io načinima (upravljanju) predviđenim za njegov razvoj. Nakon toga razbiti složeni sustav na jednostavnije komponente, pojednostaviti veze između komponenti, osigurati neovisnost komponenti i opisati međusobna sučelja između njih (tako da promjena jedne komponente ne povlači automatski značajnu promjenu u drugoj komponenti) , kao i mogućnost proširenja sustava i "stubova" za neostvarive u jednoj ili drugoj verziji sustava funkcija. Na temelju takvih elementarnih razmatranja, opis onoga što bi se trebalo implementirati u informacijski sustav više se ne čini tako nerealnim. Možete pratiti klasične pristupe razvoju informacijskih sustava, od kojih je jedan - shema "vodopada" (slika 1.) - opisan u nastavku. Ukratko će biti razmotreni i neki drugi pristupi razvoju informacijskih sustava, gdje je također prihvatljivo korištenje elemenata opisanih u shemi slapa. Koji pristup od dolje opisanih slijediti (i ima li smisla osmisliti vlastiti pristup) donekle je stvar ukusa i okolnosti.
Riža. 1. Shema slapa
Životni ciklus softvera je model za njegovo stvaranje i korištenje. Model odražava njegova različita stanja, počevši od trenutka kada se pojavi potreba za ovim softverom pa do trenutka kada je potpuno izvan uporabe za sve korisnike. Poznati su sljedeći modeli životnog ciklusa:
- kaskadni model. Prijelaz u sljedeću fazu znači potpuni završetak posla u prethodnoj fazi.
- Stupanjski model sa srednjom kontrolom. Razvoj softvera provodi se u iteracijama s povratnom spregom između faza. Prilagodbe među fazama mogu smanjiti složenost procesa razvoja u usporedbi s modelom vodopada; životni vijek svake od faza rastegnut je za cijelo razdoblje razvoja.
- spiralni model. Posebna se pozornost posvećuje početnim fazama razvoja – izradi strategije, analizi i dizajnu, gdje se izvedivost pojedinih tehničkih rješenja provjerava i opravdava kroz izradu prototipa (prototipa). Svaki zavoj spirale podrazumijeva izradu određene verzije proizvoda ili bilo koje njegove komponente, pri čemu se specificiraju karakteristike i ciljevi projekta, utvrđuje njegova kvaliteta i planira rad sljedećeg zavoja spirale.
U nastavku ćemo razmotriti neke od shema razvoja projekta.
"Vodopad" - shema razvoja projekta
Dizajn se vrlo često opisuje kao zasebna faza razvoja projekta između analize i razvoja. Međutim, u stvarnosti ne postoji jasna podjela faza razvoja projekta - dizajn u pravilu nema jasno definiran početak i kraj, a često se nastavlja u fazama testiranja i implementacije. Govoreći o fazi testiranja, također treba napomenuti da i faza analize i faza projektiranja sadrže elemente rada ispitivača, na primjer, za dobivanje eksperimentalnog opravdanja za odabir određenog rješenja, kao i za procjenu kriterija kvalitete. rezultirajućeg sustava. U fazi rada prikladno je govoriti o održavanju sustava.
U nastavku ćemo razmotriti svaku od faza, detaljnije se zadržavajući na fazi projektiranja.
Strategija
Definiranje strategije uključuje ispitivanje sustava. Glavni zadatak ankete je procijeniti stvarni opseg projekta, njegove ciljeve i ciljeve, kao i dobiti definicije entiteta i funkcija na visokoj razini.
U ovoj fazi su uključeni visokokvalificirani poslovni analitičari, koji imaju stalan pristup upravljanju tvrtkom; faza uključuje blisku interakciju s glavnim korisnicima sustava i poslovnim stručnjacima. Glavni zadatak interakcije je dobiti najpotpunije informacije o sustavu (potpuno i nedvosmisleno razumijevanje zahtjeva kupaca) i prenijeti te informacije u formaliziranom obliku analitičarima sustava za kasniju fazu analize. Informacije o sustavu u pravilu se mogu dobiti kao rezultat razgovora ili seminara s menadžmentom, stručnjacima i korisnicima. Tako se utvrđuje bit ovog posla, izgledi za njegov razvoj i zahtjevi za sustav.
Po završetku glavne faze istraživanja sustava, tehničari formiraju vjerojatne tehničke pristupe i procjenjuju troškove hardvera, kupljenog softvera i razvoja novog softvera (što se, zapravo, pretpostavlja projektom).
Rezultat faze definiranja strategije je dokument koji jasno navodi što će kupac dobiti ako pristane financirati projekt; kada dobije gotov proizvod (radni raspored); koliko će to koštati (za velike projekte treba sastaviti raspored financiranja u različitim fazama rada). Dokument bi trebao odražavati ne samo troškove, već i koristi, na primjer, vrijeme povrata projekta, očekivani ekonomski učinak (ako se može procijeniti).
Dokument mora opisati:
- ograničenja, rizici, kritični čimbenici koji utječu na uspjeh projekta, na primjer, vrijeme odgovora sustava na zahtjev je zadano ograničenje, a ne poželjni čimbenik;
- skup uvjeta pod kojima bi trebao funkcionirati budući sustav: arhitektura sustava, hardverski i softverski resursi koji se osiguravaju sustavu, vanjski uvjeti za njegovo funkcioniranje, sastav ljudi i rad koji osiguravaju nesmetano funkcioniranje sustava;
- rokovi za završetak pojedinih faza, oblik isporuke radova, sredstva uključena u proces izrade projekta, mjere zaštite informacija;
- opis funkcija koje sustav obavlja;
- budući zahtjevi za sustavom u slučaju njegovog razvoja, na primjer, sposobnost korisnika da radi sa sustavom putem interneta i sl.;
- subjekti potrebni za obavljanje funkcija sustava;
- sučelja i raspodjela funkcija između osobe i sustava;
- zahtjevi za softverske i informacijske komponente softvera, zahtjevi za DBMS (ako se projekt treba implementirati za više DBMS-a, onda zahtjevi za svaki od njih ili opći zahtjevi za apstraktni DBMS i popis DBMS-a preporučenih za ovaj projekt koji zadovoljiti navedene uvjete);
- koji se neće provoditi u okviru projekta.
Radovi koji se obavljaju u ovoj fazi omogućuju nam da odgovorimo na pitanje isplati li se nastaviti ovaj projekt i koje zahtjeve kupaca možemo ispuniti pod određenim uvjetima. Može se pokazati da projekt nema smisla nastaviti, primjerice, jer se određeni zahtjevi ne mogu zadovoljiti iz nekih objektivnih razloga. Ako se donese odluka da se nastavi s projektom, tada je ideja o opsegu projekta i procjeni troškova već dostupna za sljedeću fazu analize.
Treba napomenuti da u fazi odabira strategije, u fazi analize i tijekom projektiranja, bez obzira na metodu korištenu u izradi projekta, uvijek treba klasificirati planirane funkcije sustava prema važnosti. . Jedan mogući format za predstavljanje takve klasifikacije, MoSCoW, predložen je u Clegg, Dai i Richard Barker, Case Method Fast-track: A RAD Approach, Adison-Wesley, 1994.
Ova kratica znači: Mora imati - potrebne funkcije; Trebao bi imati - poželjne funkcije; Mogao imati - moguće funkcije; Neće imati - nedostajuće značajke.
Provedba funkcija druge i treće kategorije ograničena je vremenskim i financijskim okvirom: razvijamo ono što je potrebno, kao i najveći mogući broj funkcija druge i treće kategorije prema prioritetu.
Analiza
Faza analize uključuje detaljno proučavanje poslovnih procesa (funkcija definiranih u fazi odabira strategije) i informacija potrebnih za njihovu provedbu (entiteta, njihovih atributa i odnosa (odnosa)). U ovoj fazi se izrađuje informacijski model, a u sljedećoj fazi projektiranja izrađuje se model podataka.
Sve informacije o sustavu prikupljene u fazi definiranja strategije formaliziraju se i dorađuju u fazi analize. Posebnu pozornost treba posvetiti cjelovitosti prenesenih informacija, analizi informacija na odsutnost proturječnosti, kao i traženju informacija koje se uopće ne koriste ili dupliciraju. Kupac u pravilu ne formira odmah zahtjeve za sustav u cjelini, već formulira zahtjeve za njegove pojedinačne komponente. Obratite pažnju na konzistenciju ovih komponenti.
Analitičari prikupljaju i bilježe informacije u dva međusobno povezana oblika:
- funkcije - informacije o događajima i procesima koji se događaju u poslovanju;
- entiteti – informacije o stvarima koje su važne za organizaciju i o kojima se nešto zna.
Dva klasična rezultata analize su:
- hijerarhija funkcija koja razlaže obradu na sastavne dijelove (što se radi i od čega se sastoji);
- model entitet-odnos (Entry Relationship model, ER-model), koji opisuje entitete, njihove atribute i odnose (relacije) među njima.
Ovi rezultati su neophodni, ali nisu dovoljni. Dovoljni rezultati uključuju dijagrame toka podataka i dijagrame životnog ciklusa entiteta. Vrlo često dolazi do pogrešaka analize kada se pokušava prikazati životni ciklus entiteta u dijagramu ER.
U nastavku ćemo pregledati tri najčešće korištene metodologije strukturne analize:
- Dijagrami entitet-odnos (ERD), koji služe za formaliziranje informacija o entitetima i njihovim odnosima;
- dijagrami toka podataka (Data Flow Diagrams, DFD), koji služe za formaliziranje prikaza funkcija sustava;
- dijagrami prijelaza stanja (State Transition Diagrams, STD), koji odražavaju ponašanje sustava, ovisno o vremenu; Dijagrami životnog ciklusa entiteta pripadaju ovoj klasi dijagrama.
ER dijagrami
ER dijagrami (slika 2) koriste se za dizajn podataka i standardni su način definiranja podataka i odnosa među njima. Tako se provodi detaljizacija skladišta podataka. ER dijagram sadrži informacije o entitetima sustava i njihovoj interakciji, uključuje identifikaciju objekata koji su važni za predmetno područje (entitete), svojstva tih objekata (atribute) i njihove odnose s drugim objektima (veze). U mnogim je slučajevima informacijski model vrlo složen i sadrži mnogo objekata.
Riža. 2. Primjer ER dijagrama
Entitet se prikazuje kao pravokutnik s nazivom entiteta na vrhu (na primjer, NASLOV). Okvir može navesti atribute entiteta; atributi ER-dijagrama, upisani podebljano1, su ključni (dakle, Identitet naslova je ključni atribut entiteta TITLES, ostali atributi nisu ključni).
Odnos je predstavljen linijom između dva entiteta (plave linije na slici).
Pojedinačni red s desne strane (slika 3) znači "jedan", "ptičja noga" s lijeve strane znači "mnogo", a odnos se čita duž retka, kao što je "jedan prema mnogo". Okomita traka znači "obavezno", krug znači "neobavezno", na primjer, za svaku publikaciju u TITLE, izdavač mora biti naveden u IZDAVAČI, a jedan izdavač u IZDAVAČIMA može izdati nekoliko naslova u NASLOVIMA. Treba napomenuti da se veze uvijek komentiraju (natpis na retku koji prikazuje vezu).
Riža. 3. Element dijagrama ER
Navedimo i primjer (slika 4) slike refleksivnog odnosa "zaposlenik", gdje jedan zaposlenik može upravljati s nekoliko podređenih i tako dalje po hijerarhiji pozicija.
Imajte na umu da je takav odnos uvijek neobavezan, inače bi to bila beskonačna hijerarhija.
Riža. 4. ER dijagram refleksivne relacije
Atributi entiteta mogu biti ključni - oni su podebljani; obvezno - prethodi im znak "*", odnosno njihova vrijednost je uvijek poznata, neobavezno (neobavezno) - prethodi im O, odnosno vrijednosti ovog atributa u nekom trenutku mogu biti odsutan ili nedefiniran.
lukovima
Ako entitet ima skup međusobno isključivih odnosa s drugim entitetima, onda se kaže da su takvi odnosi u luku. Na primjer, bankovni račun može se izdati bilo za pravna osoba, ili za pojedinac. Fragment ER dijagrama za ovu vrstu odnosa prikazan je na sl. 5.
Riža. 5. Luk
U ovom slučaju, atribut VLASNIK entiteta RAČUN ima posebno značenje za ovaj entitet - entitet je podijeljen na vrste po kategorijama: "za pojedinca" i "za pravnu osobu". Rezultirajući entiteti nazivaju se podtipovi, a izvorni entitet postaje supertip. Da bismo razumjeli je li supertip potreban ili ne, potrebno je ustanoviti koliko istih svojstava ima različite podtipove. Treba napomenuti da je zlouporaba podtipova i supertipova prilično česta pogreška. Oni su prikazani kao što je prikazano na sl. 6.
Riža. 6. Podtipovi (desno) i supertip (lijevo)
Normalizacija
Kako bi se spriječile anomalije u obradi podataka, koristi se normalizacija. Načela normalizacije za objekte informacijskog modela potpuno su ista kao i za modele podataka.
Dopuštene vrste veza. Pobliže ispitivanje odnosa jedan-na-jedan (slika 7), gotovo uvijek se ispostavi da su A i B zapravo različiti podskupovi istog predmeta ili različitih stajališta o njemu, samo da imaju različita imena i različito su opisani. i atribute.
Riža. 7. Odnosi jedan na jedan
Odnosi više prema jedan prikazani su na Sl. osam.
Riža. 8. Odnosi više na jedan
I je dovoljno jaka konstrukcija da se unos entiteta B ne može kreirati bez istovremenog stvaranja barem jednog povezanog unosa entiteta A.
II je najčešći oblik komunikacije. Pretpostavlja da svaka pojava entiteta A može postojati samo u kontekstu jedne (i samo jedne) pojave entiteta B. Zauzvrat, pojave B mogu postojati i u vezi s pojavljivanjem entiteta A i bez njega.
III - rijetko se koristi. I A i B mogu postojati bez veze između njih.
Odnosi mnogo-prema-više prikazani su na Sl. 9.
Riža. 9. Odnosi mnogo-na-više
I - takva se konstrukcija često događa na početku faze analize i znači vezu - ili nije u potpunosti shvaćena i zahtijeva dodatnu dozvolu, ili odražava jednostavan kolektivni odnos - dvostruko povezan popis.
II - rijetko se koristi. Takve veze uvijek su podložne daljnjim detaljima.
Razmotrimo sada rekurzivne veze (slika 10).
Riža. 10. Rekurzivne veze
Ja - rijetko, ali se javlja. Odražava poveznice alternativnog tipa.
II - često se koristi za opisivanje hijerarhija s bilo kojim brojem razina.
III - odvija se u ranim fazama. Često odražava strukturu "popisa materijala" (međusobno ugniježđenje komponenti). Primjer: svaka KOMPONENTA može se sastojati od jedne ili više (drugih) KOMPONENTI i svaka KOMPONENTA se može koristiti u jednoj ili više (drugih) KOMPONENTI.
Nevažeće vrste veza. Nevažeći tipovi odnosa uključuju sljedeće: obvezni odnos više prema mnogo (slika 11) i skup rekurzivnih odnosa (slika 12).
Riža. 11. Nevažeći odnosi mnogo-prema-više
Obvezni odnos više prema mnogo je u osnovi nemoguć. Takav odnos bi značio da nijedna pojava A ne bi mogla postojati bez B, i obrnuto. Zapravo, svaka takva konstrukcija uvijek se pokaže pogrešnom.
Riža. 12. Nevažeće rekurzivne veze
Dijagrami toka podataka
Logički DFD (slika 13) prikazuje izvore podataka i ponore (odredišta) izvan sustava, identificira logičke funkcije (procese) i grupe elemenata podataka koji povezuju jednu funkciju s drugom (tokovi), a također identificira pohranu podataka (akumulatore), kojima se vrši pristup. Strukture protoka podataka i definicije njihovih komponenti pohranjuju se i raščlanjuju u rječnik podataka. Svaka logička funkcija (proces) može se detaljizirati korištenjem DFD niže razine; kada daljnji detalji više nisu korisni, prelazi se na izražavanje logike funkcije pomoću specifikacije procesa (mini-specifikacija). Sadržaj svake trgovine također je pohranjen u rječnik podataka, a model podataka trgovine izložen je pomoću ER dijagrama.
Riža. 13. Primjer DFD-a
Konkretno, DFD ne prikazuje procese koji kontroliraju stvarni protok podataka i ne pravi razliku između valjanih i nevažećih putova. DFD sadrže puno korisnih informacija, a osim toga:
- omogućuju vam da prezentirate sustav u smislu podataka;
- ilustrirati vanjske mehanizme za unos podataka koji bi zahtijevali posebna sučelja;
- omogućuju predstavljanje automatiziranih i ručnih procesa sustava;
- izvršiti particioniranje cijelog sustava usmjereno na podatke.
Tokovi podataka koriste se za modeliranje prijenosa informacija (ili čak fizičkih komponenti) s jednog dijela sustava na drugi. Tokovi u dijagramima prikazani su imenovanim strelicama, strelice pokazuju smjer toka informacija. Ponekad se informacija može kretati u jednom smjeru, obraditi se i vratiti svom izvoru. Takva se situacija može modelirati ili s dva različita toka, ili s jednim dvosmjernim.
Proces pretvara ulazni tok u izlazni tok u skladu s radnjom specificiranom imenom procesa. Svaki proces mora imati jedinstveni broj za referencu unutar dijagrama. Ovaj se broj može koristiti zajedno s brojem dijagrama kako bi se osigurao jedinstveni indeks procesa u cijelom modelu.
Pohrana podataka (pohrana podataka) omogućuje definiranje podataka u brojnim područjima koja će biti pohranjena u memoriji između procesa. Zapravo, pohrana predstavlja "kriške" protoka podataka u vremenu. Informacije koje sadrži mogu se koristiti u bilo kojem trenutku nakon što su definirane, a podaci se mogu birati bilo kojim redoslijedom. Ime repozitorija treba identificirati njegov sadržaj. U slučaju kada tok podataka ulazi (napušta) pohranu i njegova struktura odgovara strukturi pohrane, ona mora imati isto ime, što ne mora biti prikazano u dijagramu.
Vanjski entitet (terminator) predstavlja entitet izvan konteksta sustava, koji je izvor ili primatelj podataka sustava. Njezino ime mora sadržavati imenicu, kao što je "Klijent". Pretpostavlja se da objekti predstavljeni takvim čvorovima ne bi trebali sudjelovati ni u kakvoj obradi.
STD dijagrami prijelaza stanja
Životni ciklus entiteta pripada klasi STD dijagrama (slika 14.). Ovaj dijagram odražava promjenu stanja objekta tijekom vremena. Na primjer, razmotrite stanje proizvoda u skladištu: proizvod se može naručiti od dobavljača, isporučiti u skladište, pohraniti u skladište, proći kontrolu kvalitete, prodati, odbiti, vratiti dobavljaču. Strelice na dijagramu pokazuju dopuštene promjene stanja.
Riža. 14. Primjer dijagrama životnog ciklusa
Postoji nekoliko različitih opcija za prikaz takvih dijagrama, a slika prikazuje samo jednu od njih.
Neki principi za provjeru kvalitete i cjelovitosti informacijskog modela
(izvor - Richard Barker, Metoda slučaja: Modeliranje odnosa entiteta, Addison-Wesley, 1990.)
Ako želite stvoriti visokokvalitetan model, morat ćete pribjeći pomoći analitičara koji su dobro upućeni u CASE tehnologiju. Međutim, to ne znači da bi samo analitičari trebali biti uključeni u izgradnju i kontrolu informacijskog modela. Od velike pomoći može biti i pomoć kolega. Uključite ih u provjeru cilja i u detaljnu studiju izgrađenog modela, kako u smislu logike tako i u smislu uzimanja u obzir aspekata predmetnog područja. Većina ljudi lakše pronalazi nedostatke u tuđem radu.
Redovito prezentirajte svoj informacijski model ili njegove pojedinačne fragmente za koje sumnjate na odobravanje korisnika. Obratite posebnu pozornost na iznimke od pravila i ograničenja.
Kvaliteta entiteta
Glavno jamstvo kvalitete entiteta je odgovor na pitanje je li predmet doista entitet, odnosno važan objekt ili pojava, o kojoj bi se podaci trebali pohraniti u bazi podataka.
Popis pitanja za provjeru za entitet:
- Odražava li naziv entiteta bit ovog objekta?
- Postoji li raskrižje s drugim entitetima?
- Postoje li barem dva atributa?
- Ne postoji li ukupno više od osam atributa?
- Postoje li sinonimi/homonimi za ovaj entitet?
- Je li entitet u potpunosti definiran?
- Postoji li jedinstveni identifikator?
- Postoji li barem jedna veza?
- Postoji li barem jedna funkcija za stvaranje, pretraživanje, ažuriranje, brisanje, arhiviranje i korištenje vrijednosti entiteta?
- Postoji li povijest promjena?
- Postoji li usklađenost s načelima normalizacije podataka?
- Postoji li isti entitet u drugom aplikacijskom sustavu, možda pod drugim imenom?
- Je li suština previše opća?
- Je li razina generalizacije utjelovljena u njemu dovoljna?
Popis probirnih pitanja za podvrstu:
- Ima li preklapanja s drugim podtipovima?
- Ima li podtip neke atribute i/ili odnose?
- Imaju li svi svoje jedinstvene identifikatore ili svi nasljeđuju jedan od supertipa?
- Postoji li iscrpan skup podtipova?
- Nije li podtip primjer pojave entiteta?
- Znate li za neke atribute, odnose i uvjete koji razlikuju ovaj podtip od drugih?
Kvaliteta atributa
Potrebno je utvrditi jesu li to stvarno atributi, odnosno opisuju li na ovaj ili onaj način ovaj entitet.
Popis sigurnosnih pitanja za atribut:
- Je li naziv atributa jednina imenica koja odražava bit svojstva označenog atributom?
- Ne uključuje li naziv atributa naziv entiteta (ne bi trebao)?
- Ima li atribut samo jednu vrijednost odjednom?
- Nedostaju li duplicirane vrijednosti (ili grupe)?
- Jesu li opisani format, duljina, valjane vrijednosti, algoritam izvođenja itd.?
- Može li ovaj atribut biti izostavljeni entitet koji bi bio koristan za drugi aplikacijski sustav (postojeći ili predloženi)?
- Može li biti propuštena veza?
- Postoji li negdje referenca na atribut kao "značajku projekta" koja bi trebala nestati kada se prijeđe na sloj aplikacije?
- Postoji li potreba za poviješću promjena?
- Ovisi li njegova vrijednost samo o danom entitetu?
- Ako se traži vrijednost atributa, je li ona uvijek poznata?
- Postoji li potreba za stvaranjem domene za ove i slične atribute?
- Ovisi li njegova vrijednost samo o nekom dijelu jedinstvenog identifikatora?
- Ovisi li njegova vrijednost o vrijednostima nekih atributa koji nisu uključeni u jedinstveni identifikator?
Kvaliteta veze
Moramo otkriti odražavaju li odnosi stvarno važne odnose uočene između entiteta.
Popis verifikacijskih pitanja za komunikaciju:
- Postoji li opis za svaku uključenu stranu, odražava li točno sadržaj odnosa i uklapa li se u prihvaćenu sintaksu?
- Jesu li uključene samo dvije strane?
Nije li veza prijenosna?
- Je li za svaku stranu određen stupanj povezanosti i obveze?
- Je li dopuštena struktura veze?
Je li dizajn veze jedan od rijetko korištenih?
- Nije li suvišno?
- Ne mijenja li se s vremenom?
- Ako je veza obvezna, odražava li uvijek odnos prema entitetu koji predstavlja suprotnu stranu?
Za ekskluzivno udruženje:
- Imaju li svi krajevi veze pokriveni ekskluzivnim lukom isti tip povezivanja?
- Odnose li se svi na isti entitet?
- Obično lukovi križaju grananje krajeva - što možete reći o ovom slučaju?
- Veza može biti pokrivena samo jednim lukom. Je li tako?
- Jesu li svi krajevi veza pokriveni lukom uključeni u jedinstveni identifikator?
Funkcije sustava
Analitičari često moraju opisati prilično složene poslovne procese. U tom se slučaju pribjegava funkcionalnoj dekompoziciji, koja pokazuje podjelu jednog procesa na niz manjih funkcija sve dok se svaka od njih više ne može raščlaniti bez gubitka značenja. Konačni proizvod dekompozicije je hijerarhija funkcija, na čijoj se najnižoj razini nalaze funkcije koje su atomske u smislu semantičkog opterećenja. Navedimo jednostavan primjer (slika 15) takve dekompozicije. Razmotrimo najjednostavniji problem izdavanja računa kupcu pri puštanju robe iz skladišta, pod uvjetom da je skup robe koju kupac želi kupiti već poznat (problem odabira robe u ovom primjeru nećemo razmatrati).
Riža. 15. Primjer razgradnje
Očito se operacija odabira i obračuna popusta može rastaviti i na manje operacije, kao što je izračun popusta za vjernost (kupac kupuje robu na duže vrijeme) i obračun popusta na količinu kupljene robe. Atomske funkcije su detaljno opisane, na primjer pomoću DFD-a i STD-a. Očito, takav opis funkcija ne isključuje dodatni verbalni opis (na primjer, komentare).
Treba napomenuti da se u fazi analize treba obratiti pozornost na funkcije analize i obrade mogućih pogrešaka i odstupanja od očekivanog standarda sustava. Treba identificirati najkritičnije procese za rad sustava i za njih treba osigurati posebno rigoroznu analizu pogrešaka. Rukovanje pogreškama DBMS-a (povratni kodovi) u pravilu je zaseban skup funkcija ili jedna funkcija.
Rafiniranje strategije
U fazi analize dorađuju se hardver i softver odabrani za konačnu implementaciju. Za to se mogu uključiti ispitne skupine i tehnički stručnjaci. Prilikom projektiranja informacijskog sustava važno je uzeti u obzir daljnji razvoj sustava, na primjer, povećanje volumena obrađenih podataka, povećanje intenziteta protoka zahtjeva, promjene u zahtjevima za pouzdanošću. informacijskog sustava.
U fazi analize određuju se skupovi modela zadataka za dobivanje usporednih karakteristika različitih DBMS-a koje su razmatrane u fazi određivanja strategije implementacije informacijskog sustava. U fazi određivanja strategije može se odabrati jedan DBMS. Već u fazi analize postoji mnogo više podataka o sustavu, a oni su detaljniji. Dobiveni podaci, kao i karakteristike koje su prenijele ispitne grupe, mogu pokazati da je izbor DBMS-a u fazi određivanja strategije bio pogrešan te da odabrani DBMS ne može zadovoljiti određene zahtjeve informacijskog sustava. Isti podaci mogu se dobiti iu pogledu izbora hardverske platforme i operativnog sustava. Dobivanje takvih rezultata pokreće promjenu podataka dobivenih u fazi utvrđivanja strategije, na primjer, procjena troškova za projekt se ponovno izračunava.
Izbor razvojnih alata također se specificira u fazi analize. Budući da faza analize daje potpuniju sliku informacijskog sustava nego u fazi definiranja strategije, plan rada se može prilagoditi. Ako razvojni alat odabran u prethodnoj fazi ne dopušta da se jedan ili drugi dio posla završi u navedenom roku, tada se donosi odluka o promjeni rokova (u pravilu se radi o povećanju vremena razvoja) ili za promjenu razvojnog alata. Prilikom odabira jednog ili drugog alata treba voditi računa o prisutnosti visokokvalificiranog osoblja koje posjeduje odabrane razvojne alate, kao i prisutnost administratora odabranog DBMS-a. Ove preporuke će također precizirati podatke faze odabira strategije (skup uvjeta pod kojima bi budući sustav trebao funkcionirati).
Također su navedena ograničenja, rizici, kritični čimbenici. Ako se u informacijskom sustavu implementiranom korištenjem DBMS-a i softverskih alata odabranih u fazi utvrđivanja strategije ne mogu zadovoljiti bilo koji zahtjevi, tada se također pokreće dorada i promjena dobivenih podataka (u konačnici, procjene troškova i planova rada, a eventualno i promjena u zahtjevima kupaca za sustavom, na primjer, njihovo slabljenje). Detaljnije su opisane značajke koje neće biti implementirane u sustav.