Dizajn informacionih sistema je višestepeni proces njihovog kreiranja i/ili modernizacije primenom uređenog skupa metodologija i alata. Dizajn (za razliku od modeliranja) uključuje rad sa nepostojećim objektom i ima za cilj stvaranje informacionog sistema u oblasti:
- obrada objekata buduće baze podataka,
- pisanje programa (uključujući formulare za izvještavanje i ekrane) koji osiguravaju izvršavanje upita podataka,
- vođenje računa o funkcionisanju određenog okruženja (tehnologije).
Ako izdvojimo fazu projektovanja informacionih sistema kao posebnu fazu, onda se ona može staviti između faza analize i razvoja. Međutim, u praksi je jasna podjela na faze, po pravilu, teška ili nemoguća, jer dizajn, formalno počevši od definicije ciljevi projekta, često se nastavlja kroz faze testiranja i implementacije.
Cilj dizajna informacionog sistema i povezani koncepti
Savremeni čelnici javnih i privatnih organizacija svjesni su da je brzina obrade informacija, koja se konstantno mijenja i povećava obim, stvar opstanka kompanije na tržištu i konkurentsku prednost. Generalno, ciljevi projekata za kreiranje informacionih sistema svode se na obezbeđivanje uslova koji omogućavaju da se ove informacije primaju, obrađuju i koriste kreiranjem funkcionalnog sistema sa dovoljnim:
- nivo prilagodljivosti promenljivim uslovima,
- propusnost,
- vrijeme odgovora sistema na zahtjev,
- nivo sigurnosti,
- stepen lakoće korišćenja.
Informacioni sistem (IS) je skup informacija sadržanih u bazi podataka i tehnologija (kao i tehničkih alata) koji obezbeđuju obradu informacija. U ovom slučaju, tehnologije takođe uključuju metode za otkrivanje, prikupljanje, obradu, skladištenje, širenje informacija i metode koje omogućavaju implementaciju ovih metoda. upravljanje informacijama svodi se na upotrebu ovih metoda za kontrolu procesa planiranja, projektovanja, rada i analize IS. Tehnologija projektovanja zasniva se na metodologiji odabranoj za određeni zadatak kao skupu principa izraženih u jednom specifičnom konceptu.
Organizacija projektovanja IS
Organizacija dizajna IS-a obično se dijeli na 2 tipa:
- Canonical dizajn odražava tehnološke karakteristike originalnog (pojedinačnog) procesa.
- Tipični dizajn, koji karakterizira standardno dizajnersko rješenje (TPR), je repliciran i pogodan za ponovnu upotrebu.
Canonical dizajn odlikuje se odrazom tehnologije ručnog dizajna, implementacijom na nivou izvođača i upotrebom univerzalnih alata za kompjutersku podršku.
Kanonski dizajn se koristi uglavnom za lokalne i relativno male IC-ove uz minimalnu upotrebu standardnih rješenja. Adaptacija projektnih rješenja odvija se samo kroz reprogramiranje softverskih modula. 
Kanonski dizajn je organiziran korištenjem kaskadnog modela životnog ciklusa. Ovo uključuje podjelu procesa na sljedeće korake i korake:
- Predprojektna faza. Izrađene i sastavljene tehničke specifikacije. Odnosno, formiraju se zahtjevi za IP, razvija se njegov koncept, izrađuje studija izvodljivosti i pišu tehničke specifikacije.
- Faza projekta predviđa izradu nacrta i tehničkih projekata, izradu radne dokumentacije.
- Postprojektna faza podstiče aktivnosti na implementaciji IS-a, obuku osoblja i analizu rezultata testiranja. Dio ove faze je održavanje IS-a i otklanjanje uočenih nedostataka.
Faze se, ako je potrebno, mogu uvećati ili detaljnije - kombinovati uzastopne faze, isključiti "dodatne", započeti sljedeću fazu prije završetka prethodne.
Tipičan metod projektovanja odlikuje se mogućnošću dekomponovanja projektovanog IS-a sa podelom na komponente, koje uključuju programske module, podsisteme, komplekse zadataka itd. Za implementaciju komponenti možete koristiti standardna rješenja koji već postoje na tržištu i prilagođavaju ih potrebama određene organizacije. Istovremeno, tipski dizajn pretpostavlja obaveznu dostupnost dokumentacije koja detaljno opisuje TPR i procedure podešavanja.
Dekompozicija može imati nekoliko nivoa, što omogućava izdvajanje klasa TPR-a:
- elemental - za poseban zadatak (element),
- podsistem - za pojedinačne podsisteme,
- objekt - industrijski standardna dizajnerska rješenja koja sadrže cijeli skup podsistema.
Mogućnost implementacije modularnog pristupa smatra se prednošću elementarnog TPR-a. Međutim, u slučaju nekompatibilnosti različitih elemenata, proces njihovog kombiniranja dovodi do povećanja troškova. Podsistem TPR, pored implementacije modularnog pristupa, omogućava izvođenje parametarskog prilagođavanja objektima različitih nivoa upravljanja. Problemi konsolidacije nastaju kada je uključen proizvod nekoliko različitih proizvođača softvera. Osim toga, prilagodljivost TPR-a sa stanovišta kontinuiranog reinženjeringa procesa smatra se nedovoljnom. Objekt TPR, u odnosu na prethodne klase, ima veliki broj prednosti:
- skalabilnost, što omogućava korištenje IS konfiguracija za različit broj poslova,
- metodološko jedinstvo komponenti,
- kompatibilnost IC komponenti,
- otvorenost arhitekture - mogućnost implementacije dizajnerskih rješenja na platformama različitih tipova,
- konfigurabilnost - mogućnost korištenja željenog podskupa IS komponenti.
Prilikom implementacije standardnog dizajna koriste se parametarski i modelno orijentisani pristupi.
Osnovne metodologije dizajna IC
Specifičnosti procesa projektovanja omogućavaju izdvajanje metodologija na osnovu kojih se zasniva različiti principi. Među glavnim modernim metodologijama dizajna IS-a su sljedeće:
- SADT. Metodologija funkcionalnog modeliranja rada, koja se zasniva na strukturnoj analizi i grafički prikaz organizacija kao sistem funkcija. Ovdje se ističu funkcionalni, informativni i dinamički modeli. Metodologija je trenutno poznata kao IDEF0 notacija (standard). Analizirani proces je grafički predstavljen u obliku četverougla, gdje su gore prikazane regulatorne i kontrolne radnje, dolje kontrolni objekti, lijevo ulazni, a desno izlazni podaci.
- RAD. Metodologija brzog razvoja aplikacija. U RAD-u je brz razvoj aplikacija moguć korišćenjem komponentno orijentisanog dizajna. Metodologija se koristi na projektima sa ograničenim budžetom, nejasnim IP zahtjevima i kratkim rokovima. Koristi se ako se korisnički interfejs može demonstrirati u prototipu, a projekat se može podeliti na funkcionalne elemente.
- RUP. RUP metodologija implementira iterativni i inkrementalni (inkrementalni) pristup. Sistem je izgrađen na bazi arhitekture informacionog sistema, a planiranje i upravljanje projektima zasnovani su na funkcionalnim zahtjevima za IS. Razvoj zajedničkog informacionog sistema odvija se u iteracijama, kao kompleks zasebnih malih projekata sa sopstvenim planovima i zadacima. Iterativni ciklus karakteriše periodična povratna informacija i prilagođavanje IS jezgru.
Postoji nekoliko klasifikacija metodologija: prema upotrebi TPR-a, prema upotrebi alata za automatizaciju itd. Na primjer, prema stepenu prilagodljivosti razlikuju se rekonstrukcije (kada se moduli reprogramiraju), parametrizacije (kada se mijenja parametara podrazumeva generisanje projektnog rešenja), restrukturiranje (kada je promena modela problematične oblasti praćena automatskim generisanjem projektnog rešenja).
Servisni centar - organizacija koja se bavi pružanjem usluga servisne podrške i održavanja mašina, opreme i drugih proizvoda. Djelatnost servisnih centara uključuje pretprodajne, garancijske i postprodajne popravke.
Preduzeće IP Mikhailov A.O. bavi se popravkom i održavanjem kućanskih aparata i elektronike, kao i kompjutere, telefone i tablete koje kupci donose u kancelariju, kao i punjenje kertridža i instaliranje mreža i PBX-a. Ukoliko naručilac nije u mogućnosti da sam isporuči opremu, vrši se obilazak objekta, a po potrebi je isporučuje servisni centar. Kada klijent kontaktira servisni centar, dispečer sastavlja zahtjev za prihvatanje narudžbe. Vrši se analiza objekta, na osnovu čega se donosi zaključak da li će oprema biti popravljena ili ne. Inženjerski odjel sastavlja cjenovnik popravke i održavanja opreme, jer sarađuje sa dobavljačima rezervnih dijelova i uređaja za popravku opreme. Popravke treba izvršiti specijalna oprema pridržavajući se sigurnosnih pravila. Kompanija takođe prodaje periferne uređaje za telefone, tablete i računare. Preduzeće se bavi nabavkom polovne opreme i opreme koja je pokvarena.
Kompanija radi kvalifikovanih specijalista sa dugogodišnjim iskustvom. Direktor nadgleda cjelokupno poslovanje preduzeća.
Adresa kompanije:
Permska teritorija, Kungur, ul. Lenina 66
Način rada:
Pon-pet: 10 - 19 bez ručka
Ned: slobodan dan.
Strukturiranjem liste usluga kompanija može povećati svoju dobit, proširiti granice preduzeća ili otvoriti drugi servisni centar na drugom mjestu, može se povećati i kvalitet pruženih usluga i povećati broj kupaca.
Sprovedena analiza predmetne oblasti daje potpun opis predmetne oblasti preduzeća IP Mikhailov A.O. stvoriti funkcionalan informacioni sistem za ovo preduzeće. Dat je opis rada servisnog centra, koji ukazuje na rad inženjerskog odjela. Izrađena je i organizaciona struktura preduzeća koja pokazuje interakciju direktora i podređenih.
Formiranje osnovnih dokumenata za upravljanje projektom informacionog sistema
Projekat je skup zadataka ili aktivnosti koji se odnose na postizanje planiranog cilja, koji je obično jedinstven i ne ponavlja se.
Upravljanje projektom - korištenje znanja, vještina, metoda, alata i tehnologija u implementaciji projekta u cilju postizanja ili prevazilaženja očekivanja učesnika u projektu.
Za pravilno upravljanje projektom informacionog sistema potrebno je generirati osnovne dokumente za upravljanje projektom. Osnovni dokumenti će biti Povelja i Plan upravljanja projektom.
Povelja projekta
Povelja projekta je instrument koji formalno ovlašćuje projekat i predstavlja vezu koja povezuje nadolazeći projekat trenutni rad organizacije.
Povelja projekta dokumentuje početne zahtjeve za projekat koji zadovoljavaju potrebe i očekivanja zainteresovanih strana.
Postoji povelja projekta.
Ovaj dokument obično odražava situaciju na strani organizacije klijenta, izdaje ga vođa izvan projekta i imenuje menadžera projekta, dajući mu ovlaštenje da koristi resurse organizacije u projektu.
Povelja projekta treba da sadrži sljedeće informacije:
Zahtjevi za projekt i proizvod projekta, u prilično opštem obliku;
Cilj projekta;
Podaci o imenovanom rukovodiocu projekta i stepenu njegovih ovlaštenja;
Raspored kontrolnih događaja;
Odnosi između učesnika u projektu;
Funkcionalne organizacije i njihovo učešće;
Pretpostavke o organizaciji i okruženju, kao i eksterne pretpostavke;
Ograničenja u pogledu organizacije i okruženja, kao i eksterna ograničenja;
Pravi poslovni slučaj koji služi kao opravdanje za projekat sa podacima o povratu investicije;
Budžet projekta.
Povelja projekta povećava vjerovatnoću uspješnog završetka projekta. Dokumentira namjere učesnika projekta na samom početku projekta i može poslužiti kao temeljna tačka za rješavanje sporova između članova projektnog tima i organizacije koja izvodi.
Prilikom izrade povelje projekta izvršena je povelja o pravilima organizacije rada projekta uz pomoć dokumentacije, strategija, ciljeva, projektne metodologije, funkcija uloga i projektnih pravila neophodnih za postizanje poslovnih ciljeva projekta. . Identifikovani su odgovorni za upravljanje i implementaciju.
Izrada povelje oduzima dosta vremena. Prilikom izrade sljedećeg projekta, izrađena povelja se može koristiti kao predložak, tako da izrada povelje traje manje vremena. Povelja projekta pomaže u upravljanju projektom jer su neke informacije potrebne za rad u MS Projectu.
Plan upravljanja projektom
Plan upravljanja projektom – skup odobrenih formalnih dokumenata koji specificiraju kako će se projekat izvršiti i kako će se projekt pratiti i upravljati. Plan može biti sažet ili detaljan i može uključivati jedan ili više pomoćnih planova upravljanja i drugih planskih dokumenata.
Proces izrade plana upravljanja projektom je proces dokumentiranja aktivnosti potrebnih za definiranje, pripremu, integraciju i koordinaciju svih pratećih planova. Dobro napisan plan upravljanja projektom glavni je izvor informacija o tome kako će se projekt planirati, evaluirati, kontrolirati i zatvarati. Plan upravljanja projektom se ažurira i uređuje kao dio integriranog procesa upravljanja promjenama u projektu.
1 Podrška planovima upravljanja projektima, koji uključuju:
Plan upravljanja obimom projekta;
Plan upravljanja rasporedom projekta;
Plan upravljanja troškovima projekta;
Plan upravljanja kvalitetom projekta;
Plan upravljanja osobljem;
Plan upravljanja komunikacijama projekta;
Plan upravljanja projektnim rizikom;
Plan upravljanja konfiguracijom.
2 Osnovna linija projekta, koja se sastoji od:
Osnovni raspored projekta;
Osnovni plan troškova;
Osnovni plan za kvalitet;
Osnovni plan za konfiguraciju;
Registar rizika.
3 Rezultati analize koju je sproveo projektni tim u vezi sa sadržajem, obimom i vremenskim rasporedom projekta.
Za projekat informacionog sistema „Obračun pruženih usluga“ izrađen je plan upravljanja projektom. (Dodatak B)
Prvi paragraf plana upravljanja projektom navodi naziv projekta. Naziv projekta se ne može mijenjati tokom cijelog trajanja projekta.
Drugi paragraf definiše ciljeve i ciljeve projekta. Ciljevi se formiraju na osnovu zahteva kupaca, a to su automatizacija glavnih poslovnih procesa preduzeća. Postavljeni su ciljevi, kao što su privlačenje kupaca i povećanje profita, poboljšanje kvaliteta pruženih usluga.
Treći paragraf definira zahtjeve za projektno rješenje i rezultate projekta. Ovaj dio je element osnovnog sadržaja projekta. Kako bi se osigurala veza između zahtjeva kupaca i rezultata projekta, preporučuje se korištenje funkcije kvalitete.
Četvrta tačka definiše granice projekta. Ovo je osnovni element sadržaja projekta. Opseg projekta opisuje šta je uključeno u projekat kako bi se osiguralo da učesnik u projektu ne smatra greškom proizvod, uslugu ili rezultat kao deo projekta.
Peti stav definiše alate i tehnologije za implementaciju upravljanja projektima.
U šestom paragrafu nalazi se hijerarhijska struktura rada – model koji otkriva nivo po nivo projekta do tog stepena detalja koji je neophodan za efikasno planiranje i kontrolu projekta.
Sedma tačka opisuje potrebu za resursima. Određuje se složenošću posla koji se ogleda u prethodno razvijenom IBS-u.
Osma tačka Plana je uvećana kalendarski plan. Razvijen je na osnovu prekretnica, informacija iz Povelje projekta i informacija iz korištene metodologije upravljanja projektom.
Deveta tačka su kritični faktori uspeha. Opisuje uslove čije obezbeđivanje na projektu može biti ključ uspeha.
Deseti i jedanaesti stav odražavaju pretpostavke i ograničenja izvođača. Kako projekat napreduje, ograničenja se mogu promijeniti.
Dvanaesta tačka su prvobitno formulisani rizici. Naznačeni su već poznati rizici i glavne kategorije potencijalnih rizika.
Upravljanje rizicima su procesi povezani sa identifikacijom, analizom rizika i donošenjem odluka, koji uključuju maksimiziranje pozitivnih i minimiziranje negativnih posljedica nastanka rizičnih događaja.
Planiranje upravljanja rizikom - Proces donošenja odluka za primjenu i planiranje upravljanja rizikom za određeni projekat. Ovaj proces može uključivati odluke o organizaciji, popunjavanju osoblja procedura upravljanja rizikom projekta, odabiru preferirane metodologije, izvorima podataka za identifikaciju rizika, vremenskim okvirima za analizu situacije.
Planiranje upravljanja rizicima - izbor pristupa i planiranje aktivnosti za upravljanje projektnim rizikom.
1 Identifikacija rizika - identifikovanje rizika koji mogu uticati na projekat i dokumentovanje njihovih karakteristika.
2 Kvalitativna procjena rizika - kvalitativna analiza rizika i uslova njihovog nastanka kako bi se utvrdio njihov uticaj na uspjeh projekta.
3 Kvantifikacija - kvantitativna analiza vjerovatnoća nastanka i uticaj posljedica rizika na projekat.
4 Planiranje odgovora na rizik – utvrđivanje procedura i metoda za ublažavanje negativnih posljedica rizičnih događaja i korištenje mogućih koristi.
5 Praćenje i kontrola rizika - praćenje rizika, identifikacija preostalih rizika, implementacija plana upravljanja rizicima projekta i evaluacija efikasnosti akcija za smanjenje rizika.
Predstavljen je plan upravljanja rizicima. (Dodatak B)
Plan upravljanja projektom informacionog sistema „Obračun pruženih usluga“ omogućio je kreiranje dokumenata i opis karakteristika i granica projekta, usluga povezanih s njim, kao i načina prihvatanja i upravljanja sadržajem. Izjava o obimu je omogućila procjenu željenog ishoda i poslužila kao osnova za osnovni plan obima koji će se pratiti za sve projektne aktivnosti.
Izrada osnovne dokumentacije za upravljanje projektima informacionog sistema „Obračun pruženih usluga“ omogućila je opis nekih od dokumenata za kvalitetnu i uspješnu implementaciju upravljanja projektima u MS Project-u. Ključ uspjeha je razumijevanje potrebe za ovim dokumentima u procesu upravljanja projektom. Rezultat ovog rada je izrađena povelja projekta i plan upravljanja projektom, koji će se koristiti u daljem radu.
Rezultat prve sekcije bilo je strukturiranje IS projekta „Računovodstvo pruženih usluga“ za preduzeće IP Mikhailov A.O., takođe je razvijena povelja projekta i plan upravljanja projektom koji su korišćeni u daljem radu na upravljanju projektima. . Proces generisanja osnovnih dokumenata je najvažniji deo upravljanja projektom, jer utiče na kvalitet, trajanje i uspeh projekta.
Uvod
Zaključak
Književnost
Uvod
Razvoj raznim oblastima ljudska aktivnost u sadašnjoj fazi je nemoguće bez široke upotrebe računarska nauka i stvaranje informacionih sistema različitih pravaca. Obrada informacija u takvim sistemima postala je samostalan naučno-tehnički pravac.
Nakon faze izgradnje informacioni model počinje projektovanje sistema. U ovoj fazi, izbor tehnološka rješenja na osnovu kojih će se izgraditi informacioni sistem.
Informacije u savremeni svet je postao jedan od najvažnijih resursa, a informacioni sistemi (IS) su postali osnovni alat u skoro svim oblastima delovanja.
U realnim uslovima, dizajn je potraga za načinom koji zadovoljava zahteve funkcionalnosti sistema pomoću dostupnih tehnologija, uzimajući u obzir data ograničenja.
Raznolikost zadataka koji se rješavaju uz pomoć IS-a dovela je do pojave mnogo različitih tipova sistema koji se razlikuju po principima konstrukcije i pravilima obrade informacija ugrađenim u njih.
cilj kontrolni rad je - razmotriti korak po korak, proces kreiranja informacionih sistema.
Ciljevi ovog rada su otkrivanje glavne svrhe dizajna, kao i svrhe kreiranja informacionih sistema.
1. Dizajn informacionih sistema
Dizajn informacionih sistema uvek počinje sa definisanjem svrhe projekta. Glavni zadatak bilo kojeg uspješan projekat je osigurati da je u trenutku pokretanja sistema i tokom cijelog perioda njegovog rada moguće obezbijediti:
potrebnu funkcionalnost sistema i stepen prilagođavanja promenljivim uslovima njegovog funkcionisanja;
potrebna propusnost sistema;
potrebno vrijeme odgovora sistema na zahtjev;
· nesmetan rad sistema u traženom režimu, odnosno spremnost i raspoloživost sistema za obradu zahteva korisnika;
jednostavnost rada i podrške sistema;
neophodna sigurnost.
Performanse su glavni faktor koji određuje efikasnost sistema. Dobar dizajn je osnova sistema visokih performansi.
Dizajn informacionih sistema pokriva tri glavne oblasti:
projektovanje objekata podataka koji će biti implementirani u bazi podataka;
dizajniranje 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 (file-server ili klijent-server), paralelna obrada, distribuirana obrada podataka itd.
Prema savremenoj metodologiji, proces kreiranja IS je proces izgradnje i sekvencijalne transformacije većeg broja konzistentnih modela u svim fazama životnog ciklusa (LC) IS. U svakoj fazi životnog ciklusa kreiraju se modeli specifični za nju - organizacije, zahtjevi za IP, IP projekta, zahtjevi za aplikacije itd. Modele formiraju radne grupe projektnog tima, čuvaju i akumuliraju u repozitoriju projekta. Kreiranje modela, njihovo upravljanje, transformacija i obezbjeđivanje za kolektivnu upotrebu vrši se pomoću posebnih softverskih alata - CASE-alata.
Proces kreiranja IP-a podijeljen je na više faza (faza), ograničenih određenim vremenskim okvirima i završavajući izdavanjem određenog proizvoda (modeli, softverski proizvodi, dokumentacija itd.).
Obično se razlikuju sljedeće faze kreiranja IS-a: formiranje sistemskih zahtjeva, projektovanje, implementacija, testiranje, puštanje u rad, rad i održavanje.
Početna faza procesa kreiranja IS-a je modeliranje poslovnih procesa koji se odvijaju u organizaciji i realizuju njene ciljeve i zadatke. Model organizacije, opisan u smislu poslovnih procesa i poslovnih funkcija, omogućava nam da formulišemo osnovne zahtjeve za IS. Ova fundamentalna pozicija metodologije obezbeđuje objektivnost u razvoju zahteva za projektovanje sistema. Skup modela za opisivanje zahtjeva za IS se zatim pretvara u sistem modela koji opisuju konceptualni dizajn IS-a. Modeli arhitekture IS, zahtjevi za softverom (SW) i informatička podrška(I O). Zatim se formira softverska i IO arhitektura, identifikuju se korporativne baze podataka i pojedinačne aplikacije, formiraju se modeli zahtjeva aplikacija i vrši njihov razvoj, testiranje i integracija.
Svrha početnih faza kreiranja IS-a, koje se obavljaju u fazi analize aktivnosti organizacije, je formiranje zahtjeva za IS koji ispravno i tačno odražavaju ciljeve i ciljeve organizacije korisnika. Da biste specificirali proces kreiranja IS-a koji zadovoljava potrebe organizacije, morate saznati i jasno artikulirati koje su to potrebe. Da biste to učinili, potrebno je odrediti zahtjeve kupaca za IS i prikazati ih na jeziku modela u zahtjevima za razvoj IS projekta na način da se osigura usklađenost sa ciljevima i zadacima organizacije.
Zadatak formiranja zahtjeva za IP jedan je od najodgovornijih, teško formaliziranih i najskupljih i teško ispravljivih u slučaju greške. Savremeni alati i softverski proizvodi omogućavaju vam da brzo kreirate IS prema gotovim zahtjevima. Ali često ovi sistemi ne zadovoljavaju kupce, zahtijevaju brojna poboljšanja, što dovodi do naglog povećanja stvarnih troškova IS-a. Glavni razlog za ovu situaciju je netačna, netačna ili nepotpuna definicija zahtjeva IP u fazi analize.
U fazi projektovanja, prije svega, formiraju se modeli podataka. Projektanti dobijaju rezultate analize kao početne informacije. Izgradnja logičkih i fizičkih modela podataka je glavni dio dizajna baze podataka. Informacijski model dobiven analizom prvo se pretvara u logički, a zatim u fizički model podataka.
Paralelno sa projektovanjem šeme baze podataka, vrši se i projektovanje procesa u cilju dobijanja specifikacija (opisa) svih IS modula. Oba ova procesa dizajna su usko povezana jer se dio poslovne logike obično implementira u bazi podataka (ograničenja, okidači, pohranjene procedure). Osnovni cilj projektovanja procesa je mapiranje funkcija dobijenih u fazi analize u module informacionog sistema. Prilikom projektovanja modula definišu se programski interfejsi: izgled menija, izgled prozora, prečice i povezani pozivi.
Krajnji proizvodi faze projektovanja su:
šema baze podataka (zasnovana na ER modelu razvijenom u fazi analize);
Skup specifikacija za sistemske module (izgrađeni su na osnovu funkcionalnih modela).
Osim toga, u fazi projektovanja vrši se i razvoj IS arhitekture, uključujući izbor platforme (platforme) i operativnog sistema ( operativni sistemi). U heterogenom IS-u, nekoliko računara može raditi na različitim hardverskim platformama i pod različitim operativnim sistemima. Pored izbora platforme, u fazi projektovanja određuju se i sledeće karakteristike arhitekture:
da li će to biti arhitektura "file-server" ili "client-server";
Hoće li to biti 3-slojna arhitektura sa sljedećim slojevima: server, srednji softver (aplikacijski server), klijentski softver;
Da li će baza podataka biti centralizovana ili distribuirana. Ako je baza podataka distribuirana, koji će se mehanizmi koristiti za održavanje konzistentnosti i relevantnosti podataka;
• da li će baza podataka biti homogena, odnosno da li će svi poslužitelji baze podataka biti istog proizvođača (na primjer, svi Oracle serveri ili svi DB2 UDB serveri samo). Ako baza podataka nije homogena, koji softver će se koristiti za razmjenu podataka između DBMS-a različitih proizvođača (već postojećih ili razvijenih posebno kao dio projekta);
· da li će se paralelni poslužitelji baze podataka (npr. Oracle Parallel Server, DB2 UDB) koristiti za postizanje odgovarajuće izvedbe.
Faza projektovanja završava se izradom tehničkog dizajna IS-a. Tokom faze implementacije, kreiranje softver operativnu dokumentaciju.
Nakon što je razvoj jednog modula sistema završen, vrši se autonomni test koji ima dva glavna cilja:
otkrivanje kvarova modula (teški kvarovi);
Usklađenost modula sa specifikacijom (prisutnost svih potrebnih funkcija, odsustvo nepotrebnih funkcija).
Nakon što autonomni test uspješno prođe, modul se uključuje u razvijeni dio sistema, a grupa generisanih modula prolazi testove veze, koji treba da prate njihov međusobni uticaj.
Zatim se grupa modula testira na pouzdanost, odnosno prolaze, prvo, testove simulacije kvarova sistema, i drugo, testove vremena između kvarova. Prva grupa testova pokazuje koliko se dobro sistem oporavlja od kvarova softvera, hardvera. Druga grupa testova određuje stepen stabilnosti sistema tokom normalnog rada i omogućava vam da procenite vreme neprekidnog rada sistema. Komplet za testiranje stabilnosti bi trebao uključivati testove koji simuliraju vršno opterećenje sistema.
Tada ceo set modula prolazi sistemski test - test internog prihvatanja proizvoda, koji pokazuje nivo njegovog kvaliteta. Ovo uključuje testove funkcionalnosti i testove pouzdanosti sistema.
Posljednji test informacionog sistema je testiranje prihvatanja. Takav test uključuje pokazivanje informacionog sistema kupcu i treba da sadrži grupu testova koji simuliraju stvarne poslovne procese kako bi se pokazalo da implementacija ispunjava zahtjeve korisnika.
1Članak je posvećen pitanjima izgradnje informacionog sistema dizajniranog za analizu investicionih projekata koji se podnose administrativnim strukturama radi dobijanja finansijske podrške. Struktura takvog sistema je informacioni kompleks koji se sastoji od eksternog modula i glavnog sistema. Eksterni modul je dizajniran za pripremu početnih informacija o projektu i nalazi se u preduzeću koje učestvuje u konkursu. Glavni sistem analizira projekte i nalazi se u organu upravne kontrole. Struktura glavnog sistema je usmjerena na implementaciju karakteristika analize investicionih projekata. U radu su predloženi i osnovni principi i metodologija za evaluaciju investicionih projekata. Za evaluaciju projekta, skup početnih indikatora podijeljen je u grupe koje karakteriziraju pojedine strane finansijsko stanje organizacije. Uključeni su i dodatni indikatori koji su važni za društveni, kulturni i drugi razvoj teritorije. S tim u vezi, predstavljena metodologija omogućava da se u procesu donošenja odluke o dodjeli kredita rangiraju investicioni projekti ne samo po finansijski pokazatelji, ali i uzeti u obzir prioritete administrativnih organizacijske strukture nije direktno povezana sa finansijskim stanjem organizacije koja učestvuje u konkursu.
Informacioni sistem
struktura
metodologija
investicioni projekat
administrativna struktura
1. Brykin I.M., Beklemishev A.V. Evaluacija, odabir i analiza investicionih projekata. - M.: DOO "International Media Group", 2011. - 47 str.
2. Bailey D.V., Sharp U.F., Alexander G.D. Investicije. – M.: INFRA-M, 2012. – 1028 str.
3. Vilensky P.L., Livšits V.N., Smolyak S.A. Evaluacija efektivnosti investicionih projekata. Teorija i praksa: Proc. Benefit. – M.: Delo, 2008. – 888 str.
4. Kravčenko T.K., Presnjakov V.F. Infokomunikacione tehnologije upravljanja preduzećima - M.: Visoka ekonomska škola Državnog univerziteta, 2003. - 272 str.
5. Lipsits I.V., Kossov V.V. Investiciona analiza. Priprema i procjena ulaganja u nekretnine. – M.: INFRA-M, 2014. – 320 str.
6. Svetlov N.M., Svetlova G.N. informacione tehnologije upravljanje projektima - M.: INFRA-M, 2012. - 144 str.
7. Šuremov E. Računarska poslovna analiza. // PC svijet. - 1998. - br. 1. - Str. 80–83.
Efikasnost prihvatanja upravljačke odluke za obezbeđivanje investicija u oblasti malog biznisa u tržišnim uslovima u velikoj meri zavisi od alata koji se koriste za analizu finansijskih i ekonomskih aktivnosti preduzeća. Izbor analitičkih alata za administrativne organizacione strukture posebno je važan, kada na odluku o kreditiranju projekta treba da utiču ne samo finansijski rezultati preduzeća, već i prioriteti administrativnog subjekta koji je pod kontrolom ovog preduzeća. organizacijske strukture.
Problemi koji se razmatraju u članku odnose se na razvoj sistema za analizu aktivnosti preduzeća eksterne organizacije i organi upravljanja i kontrole. Svrha sistema nije samo da se proceni finansijsko i ekonomsko stanje preduzeća, već i mogućnosti i izgledi za interakciju ili saradnju sa njim. Informacionu bazu analize čine indikatori dobijeni na ovaj ili onaj način iz standardnog računovodstva, statističko izvještavanje i otvoreni izvori.
Među postojećim finansijskim i analitičkim sistemima može se izdvojiti razvoj firmi kao što su Expert Systems, Galaktika, INEK, Alt-Invest, međutim, njihova efektivna upotreba bez modifikacija od strane administrativnih organizacionih struktura je problematična, jer ovi sistemi ne rešavaju probleme. problemi projekta procjene u odnosu na parametre koji su prioritetni administrativna struktura ali ne finansijske prirode.
Struktura informacionog sistema
Neophodnost i relevantnost kvalitativne analize toka investicionih projekata i postojeće razlike u interesima običnog investitora i investitora u vidu administrativne organizacione strukture prevode problem izbora instrumenta u ravan njegovog razvoja. Istovremeno, preporučljivo je da se razvijenom sistemu dodijele sljedeći zadaci:
Analiza finansijskog stanja preduzeća, uključujući i dinamiku;
Analiza finansijskog dijela poslovnog plana projekta;
Analiza uticaja kredita na finansijsko stanje preduzeća;
Uzimanje u obzir prioriteta grada u procesu analize projekta;
Komparativna analiza projekata više preduzeća;
Prognoza razvoja preduzeća i povraćaja kredita.
Na osnovu karakteristika i prirode postavljenih zadataka, razvijen je blok dijagram sistema analize, prikazan na slici.
Eksterni modul sistema je autonomni program koji je dizajniran da pripremi početne informacije potrebne za donošenje odluke o dodjeli kredita za finansiranje predloženog projekta:
Bilans stanja i dodatna bilansna dokumenta;
Finansijski dio poslovnog plana projekta;
Dodatne informacije potrebne da bi se uzeli u obzir prioriteti organa uprave.
Modul omogućava kako direktan unos informacija pomoću tastature, tako i rad u režimu uvoza podataka iz drugih sistema. Istovremeno, eksterni modul provjerava ispravnost unesenih informacija kako bi se isključile nenamjerne greške.
Struktura glavnog dijela sistema je usmjerena na implementaciju karakteristika analize investicionih projekata.
Ključnu ulogu ima „Modul za postavljanje radnog okruženja i ekspertnog sistema“. Ovaj modul generiše različiti scenariji analiza, definicija dodatna pravila i kriterijume koji odražavaju interese grada i uprave, postavljajući kritične vrednosti finansijskih pokazatelja.
"Modul za izračunavanje finansijskih pokazatelja" izračunava finansijske pokazatelje.
Strukturni dijagram informacionog sistema za analizu investicionih projekata
"Modul analize projekta i vizualizacije rezultata" prikazuje rezultate analize na analitički, grafički i tabelarni način.
"Modul generiranja izvještaja" je povezan sa standardom softverski alati i namijenjen je za pripremu izvještajnog materijala.
Ekspertski sistem je dizajniran da pomogne u analizi dobijenih rezultata.
Metodologija za analizu investicionih projekata
Metodologija analize investicionih projekata sastoji se u sveobuhvatnoj analizi finansijskog stanja preduzeća, zajedno sa ocjenom samog investicionog projekta i određivanjem rejtinga projekta za dalje donošenje odluka o dodjeli kredita.
Postoji mnogo početnih indikatora, koji su podijeljeni u grupe koje karakteriziraju određene aspekte finansijskog stanja organizacije. Ove grupe indikatora koncentrisane su u zasebnim dokumentima, na primjer, računovodstveni izvještaj itd.
Dakle, postoje L-grupe početnih indikatora, gdje i L-grupe relativnih indikatora, gdje je , l broj grupe, a kl redni broj indikatora u grupi.
Na osnovu primarnih indikatora formiraju se Q-grupe sekundarnih indikatora, gdje je q = 1, Q, , a mq je redni broj indikatora u q-toj grupi. Ove indikatore nazivamo koeficijentima.
Na osnovu pokazatelja i pokazatelja dinamike njihove promjene formiraju se u apsolutnim i relativnim jedinicama tipa
gdje j - karakterizira broj mjerenja indikatora ili koeficijenta.
Svaki indikator i koeficijent su fiksirani u određenom broju vremenskih tačaka. Dobivene vrijednosti nam omogućavaju da identificiramo dinamiku promjena pokazatelja i koeficijenata tokom vremena:
Tada je I = J + 1.
Uslovi su postavljeni za koeficijente. Korespondencija koeficijenata sa uslovima pokazuje da je stanje generalizovanih karakteristika finansijskog stanja preduzeća koje je određeno ovim koeficijentom normalno.
U procesu analize poduzetničkog projekta rješavaju se najmanje tri temeljna zadatka:
a) procjenu mogućnosti otplate kredita od strane predmetnog preduzeća i, shodno tome, odluku da se isti uvrsti na listu potencijalno pogodnih za kreditiranje;
b) procjena mogućnosti kreditiranja, na osnovu prioriteta uprave;
Ovi zadaci se rješavaju u okviru višeslojne analize koeficijenata i indikatora.
Analiza se vrši uz izračunavanje koeficijenata i procjenu stanja. Koeficijenti su podijeljeni unutar grupa u podgrupe više i manje važnih. Prvi nivo analize povezan je sa procenom ispunjenosti uslova za odabrane podgrupe koeficijenata i uglavnom rešava problem
a) Na drugom i narednim nivoima analiziraju se ostali koeficijenti i indikatori, kao i dinamika njihove promjene.
Rezultati analize se sastavljaju u obliku zasebnih dokumenata, koji karakterišu različite aspekte preduzeća i predloženog projekta.
U sljedećoj fazi formira se procjena projekta prema stavci
b) Da bi se uzeli u obzir interesi uprave, uvodi se dodatna grupa indikatora (fh) i uslova (χh), gdje je h = 1,H. Ove indikatore preduzeće može izračunati ili predstaviti. Ukoliko preduzeće ne ispunjava kriterijume, isključuje se iz grupe potencijalno kreditiranih.
a) formiraju se opcije za određivanje rejtinga investicionih projekata, fokusirane na ocjenu u bilo kojem smjeru, na primjer, u oblasti proizvodnje prehrambeni proizvodi itd. Glavne razlike između opcija, ili nazovimo ih scenarijima, su sljedeće:
U grupama relativnih pokazatelja i koeficijenata izdvajaju se posebni elementi koji će se uzeti u obzir pri određivanju rejtinga projekta u ovom scenariju, tj.
gdje je ζ broj scenarija;
Za odabrane indikatore i koeficijente postavljaju se ponderi koji karakterišu uticaj ovog indikatora na rejting u ovoj grupi, tj. respektivno
Takođe, utvrđuju se ponderi za grupe indikatora i koeficijenata koji učestvuju u rejtingu, tj. , gdje je d ζ broj grupe, a D ζ ukupan broj grupa koje učestvuju u evaluaciji;
Težine su manje od 1, zbir težina svakog skupa u cijelom uzorku je 1.
b) formira se verzija najboljeg preduzeća za grupu evaluiranih projekata. Verzija najboljeg preduzeća je skup prethodno odabranih indikatora sa najboljim vrijednostima u cijelom skupu, tj. vrijednosti ovih indikatora mogu pripadati različitim preduzećima. Ova verzija nije povezana sa stvarnim objektom i koristi se za ocjenjivanje. Svi dalji omjeri za ocjenu rejtinga dati su samo za koeficijente. Slične formule su konstruirane za parametre i fh .
Tako se formira skup indikatora, gdje je, ako je veći, to bolje, a inače. Ovdje je s broj preduzeća na listi, a vrijednost koeficijenta za s-to preduzeće.
gdje je , ako rast koeficijenta karakteriše poboljšanje finansijskog stanja preduzeća i
e) što je veći R ζ s, to je viši rejting s-tog preduzeća u ζ-tom scenariju procjene.
Normalizacijom (R ζ s) sa , moguće je rasporediti preduzeća u rastućem ili opadajućem redosledu njihovog rejtinga. Ocjenjivanje po indikatorima i fh može se izvršiti zasebno.
Zaključak
Prikazana metodologija omogućava da se u procesu donošenja odluke o dodjeli kredita rangiraju investicioni projekti ne samo po finansijskim pokazateljima, već i da se uzmu u obzir prioriteti administrativne organizacione strukture koji nisu direktno povezani sa finansijskim stanjem organizacija koja učestvuje u takmičenju.
Tako će informacioni sistem, kada se implementira, biti moćno sredstvo koje uključuje efikasne mehanizme podrške odlučivanju u oblasti investicionih aktivnosti i ima za cilj da pruži analizu kako finansijskog stanja preduzeća tako i investicionih projekata prijavljenih na konkurs.
Bibliografska veza
Klevtsov S.I., Klevtsova A.B. MODEL INFORMACIONOG SISTEMA ZA ANALIZU INVESTICIJSKIH PROJEKATA ZA UPRAVNE STRUKTURE // Osnovna istraživanja. - 2016. - br. 12-1. - str. 58-61;URL: http://fundamental-research.ru/ru/article/view?id=41046 (datum pristupa: 26.04.2019.). Predstavljamo Vam časopise koje izdaje izdavačka kuća "Akademija prirodne istorije"
Projektovanje informacionih sistema
Dio 1. Faze razvoja projekta: strategija i analiza
Uvod "Vodopad" - šema razvoja projekta Strategija Analiza ER dijagrami lukovi Normalizacija Dijagrami toka podataka Neki principi za provjeru kvaliteta i potpunosti informacijskog modela Kvalitet entiteta Kvalitet atributa Kvalitet veze Funkcije sistema Rafiniranje strategije
Uvod
Dizajn informacionih sistema uvek počinje sa definisanjem svrhe projekta. Glavni zadatak svakog uspješnog projekta je osigurati da je u trenutku pokretanja sistema i tokom cijelog perioda njegovog rada moguće osigurati:
potrebnu funkcionalnost sistema i stepen prilagođavanja promenljivim uslovima njegovog funkcionisanja;
potrebna propusnost sistema;
potrebno vrijeme odgovora sistema na zahtjev;
nesmetan rad sistema u traženom režimu, odnosno spremnost i raspoloživost sistema za obradu zahteva korisnika;
jednostavnost rada i podrške sistema;
potrebnu sigurnost.
Performanse su glavni faktor koji određuje efikasnost sistema. Dobar dizajn je osnova sistema visokih performansi.
Dizajn informacionih sistema pokriva tri glavne oblasti:
dizajniranje objekata podataka koji se implementiraju u bazu podataka;
dizajniranje 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 (file-server ili klijent-server), paralelna obrada, distribuirana obrada podataka itd.
U realnim uslovima, dizajn je potraga za načinom koji zadovoljava zahteve funkcionalnosti sistema pomoću dostupnih tehnologija, uzimajući u obzir data ograničenja.
Svaki projekat podliježe brojnim apsolutnim zahtjevima, na primjer, maksimalno vrijeme izrade 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 dizajnerskog rješenja.
Smatra se da se složen sistem ne može opisati u principu. Ovo se posebno odnosi na sisteme upravljanja preduzećima. Jedan od glavnih argumenata je promjena uslova za funkcionisanje sistema, na primjer, direktivna promjena određenih tokova informacija od strane novog rukovodstva. Drugi argument je obim projektnog zadatka, koji za veliki projekat može biti stotine stranica, dok tehnički projekat može sadržavati greške. Postavlja se pitanje: možda je bolje uopšte ne provoditi ankete i ne praviti nikakav tehnički projekat, već napisati sistem „od nule“ u nadi da će doći do neke čudesne podudarnosti želje kupca sa onim što su programeri napisali, i takođe da će sve ovo raditi stabilno?
Ako pogledate, da li je razvoj sistema zaista toliko nepredvidiv i da li je zaista nemoguće doći do informacija o njemu? Vjerovatno se kroz seminare može dobiti ideja o sistemu u cjelini io načinima (menadžmentu) predviđenim za njegov razvoj. Nakon toga razbiti složeni sistem na jednostavnije komponente, pojednostaviti veze između komponenti, obezbediti nezavisnost komponenti i opisati interfejse između njih (tako da promena u jednoj komponenti ne povlači automatski značajnu promenu u drugoj komponenti) , kao i mogućnost proširenja sistema i "stubova" za neostvarive u jednoj ili drugoj verziji sistema funkcija. Na osnovu takvih elementarnih razmatranja, opis onoga što bi trebalo da se implementira u informacioni sistem više ne izgleda tako nerealno. Možete pratiti klasične pristupe razvoju informacionih sistema, od kojih je jedan "vodopad" šema ( pirinač. 1) je opisano u nastavku. Ukratko će biti razmotreni i neki drugi pristupi razvoju informacionih sistema, gdje je prihvatljiva i upotreba elemenata opisanih u shemi „vodopada“. Koji pristup od onih opisanih u nastavku slijediti (i da li ima smisla osmisliti vlastiti pristup) je u određenoj mjeri stvar ukusa i okolnosti.
Rice. 1. Šema vodopada
Životni ciklus softvera je model za njegovo kreiranje 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 van upotrebe za sve korisnike. Poznati su sljedeći modeli životnog ciklusa:
kaskadni model. Prelazak u sljedeću fazu znači potpuni završetak radova u prethodnoj fazi.
Stupanjski model sa srednjom kontrolom. Razvoj softvera se odvija u iteracijama sa ciklusima povratne informacije između faza. Međufazna prilagođavanja mogu smanjiti složenost procesa razvoja u poređenju sa modelom vodopada; životni vek svake od faza je protegnut za čitav razvojni period.
spiralni model. Posebna pažnja dat je početnim fazama razvoja – izradi strategije, analizi i dizajnu, gdje se izvodljivost pojedinih tehničkih rješenja provjerava i opravdava kroz izradu prototipova (prototyping). 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 šema razvoja projekta.
Za početak
"Vodopad" - šema razvoja projekta
Vrlo često se dizajn opisuje kao zasebna faza razvoja projekta između analize i razvoja. Međutim, u stvarnosti ne postoji jasna podjela faza razvoja projekta - dizajn, po pravilu, nema jasno definisan 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 projektovanja sadrže elemente rada testera, na primjer, za dobijanje eksperimentalnog opravdanja za odabir određenog rješenja, kao i za procjenu kriterija kvalitete. rezultirajućeg sistema. U fazi rada prikladno je govoriti o održavanju sistema.
U nastavku ćemo razmotriti svaku od faza, detaljnije se osvrnuvši se na fazu projektovanja.
Za početak
Strategija
Definisanje strategije uključuje ispitivanje sistema. Glavni zadatak ankete je procijeniti stvarni obim projekta, njegove ciljeve i zadatke, kao i dobiti definicije subjekata i funkcija na visokom nivou.
U ovoj fazi su uključeni visokokvalifikovani poslovni analitičari, koji imaju stalan pristup menadžmentu kompanije; faza uključuje blisku interakciju sa glavnim korisnicima sistema i poslovnim stručnjacima. Glavni zadatak interakcije je dobiti što potpunije informacije o sistemu (potpuno i nedvosmisleno razumijevanje zahtjeva kupaca) i prenijeti te informacije u formaliziranom obliku analitičarima sistema za kasniju fazu analize. Informacije o sistemu se po pravilu mogu dobiti kao rezultat razgovora ili seminara sa menadžmentom, stručnjacima i korisnicima. Tako se utvrđuje suština ovog posla, izgledi za njegov razvoj i zahtjevi za sistem.
Po završetku glavne faze sistematskog istraživanja, tehničari formiraju verovatne tehničke pristupe i procenjuju troškove hardvera, nabavljenog softvera i razvoja novog softvera (što je, u stvari, i pretpostavlja projekat).
Rezultat faze definisanja strategije je dokument koji jasno navodi šta će kupac dobiti ako pristane da finansira projekat; kada dobije gotov proizvod (radni raspored); koliko će to koštati (za velike projekte treba sastaviti raspored finansiranja 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 faktori koji utiču na uspeh projekta, na primer, vreme odgovora sistema na zahtev je dato ograničenje, a ne poželjan faktor;
skup uslova pod kojima bi trebalo da funkcioniše budući sistem: arhitektura sistema, hardver i softverski resursi obezbjeđenost sistemu, eksterne uslove za njegovo funkcionisanje, sastav ljudi i poslove koji obezbjeđuju nesmetano funkcionisanje sistema;
rokovi za završetak pojedinih faza, oblik isporuke posla, sredstva uključena u proces izrade projekta, mjere zaštite informacija;
opis funkcija koje sistem obavlja;
budući zahtjevi za sistem u slučaju njegovog razvoja, na primjer, sposobnost korisnika da radi sa sistemom korištenjem Interneta i sl.;
subjekti neophodni za obavljanje sistemskih funkcija;
interfejsi i distribucija funkcija između osobe i sistema;
zahtjevi za softverske i informacijske komponente softvera, zahtjevi za DBMS (ako se projekat treba implementirati za više DBMS, onda zahtjevi za svaki od njih, ili Opšti zahtjevi na apstraktni DBMS i listu preporučenih za ovaj projekat DBMS koji zadovoljavaju navedene uslove);
koji se neće realizovati u okviru projekta.
Napravljeno ovoj fazi Rad omogućava odgovor na pitanje isplati li se nastaviti ovaj projekat i koji zahtjevi kupaca mogu biti ispunjeni pod određenim uvjetima. Može se pokazati da projekat nema smisla nastaviti, na primjer, 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 obimu projekta i procjeni troškova već dostupna za sljedeću fazu analize.
Treba napomenuti da u fazi izbora strategije, u fazi analize i tokom projektovanja, bez obzira na metod koji se koristio u izradi projekta, uvek treba klasifikovati planirane funkcije sistema po 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; Mogla bi imati - moguće funkcije; Neće imati - nedostajuće funkcije.
Realizacija funkcija druge i treće kategorije ograničena je vremenskim i finansijskim okvirom: razvijamo ono što je potrebno, kao i maksimalno mogući broj funkcija druge i treće kategorije po prioritetu.
Za početak
Analiza
Faza analize uključuje detaljno proučavanje poslovnih procesa (funkcija definisanih u fazi odabira strategije) i informacija potrebnih za njihovu implementaciju (entiteta, njihovih atributa i odnosa (odnosa)). U ovoj fazi se kreira informacioni model, au sljedećoj fazi dizajna kreira se model podataka.
Sve informacije o sistemu prikupljene u fazi definisanja strategije se formalizuju i dorađuju u fazi analize. Posebnu pažnju treba obratiti na potpunost prenošenih informacija, analizu informacija na odsustvo kontradiktornosti, kao i traženje informacija koje se uopšte ne koriste ili dupliraju. Po pravilu, kupac ne formira odmah zahtjeve za sistem 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 dešavaju 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:
hijerarhiju funkcija koja razlaže obradu na njene sastavne dijelove (šta se radi i od čega se sastoji);
model odnosa entiteta (Entry Relationship model, ER-model), koji opisuje entitete, njihove atribute i veze (relacije) između njih.
Ovi rezultati su neophodni, ali nisu dovoljni. Dovoljni rezultati uključuju dijagrame toka podataka i dijagrame životni ciklusi entiteta. Vrlo često dolazi do grešaka u analizi kada se pokušava prikazati životni ciklus entiteta u ER dijagramu.
U nastavku ćemo pregledati tri najčešće korištene metodologije strukturne analize:
Dijagrami entitet-odnos (ERD), koji služe za formalizaciju informacija o entitetima i njihovim odnosima;
dijagrami toka podataka (Data Flow Diagrams, DFD), koji služe za formalizaciju reprezentacije funkcija sistema;
dijagrami tranzicije stanja (State Transition Diagrams, STD), koji odražavaju ponašanje sistema u zavisnosti od vremena; Dijagrami životnog ciklusa entiteta pripadaju ovoj klasi dijagrama.
Za početak
ER dijagrami
ER dijagrami ( pirinač. 2) se koriste za dizajniranje podataka i standardni su način definiranja podataka i odnosa između njih. Tako se vrši detaljizacija skladišta podataka. ER dijagram sadrži informacije o entitetima sistema i načinu na koji oni međusobno djeluju, uključuje identifikaciju objekata koji su važni za predmetno područje (entitete), svojstva ovih objekata (atribute) i njihove odnose sa drugim objektima (linkovi). U mnogim slučajevima, informacioni model je vrlo složen i sadrži mnogo objekata.
Rice. 2. Primjer ER dijagrama
Entitet se prikazuje kao pravougaonik s imenom entiteta na vrhu (na primjer, NASLOV). Kutija može navesti atribute entiteta; atributi ER-dijagrama, upisani podebljanim slovima, su ključni (tako da je Identitet naslova ključni atribut entiteta TITLES, ostali atributi nisu ključni).
Odnos je predstavljen linijom između dva entiteta (plave linije na slici).
Jedan red desno ( pirinač. 3) znači "jedan", "ptičja noga", lijevo je "mnogo", a relacija se čita duž reda, kao što je "jedan prema mnogo". Vertikalna traka znači "obavezno", krug - "opciono", na primjer, za svaku publikaciju u NASLOVU, izdavač mora biti naveden u IZDAVAČI, a jedan izdavač u IZDAVAČIMA može izdati više naslova u NASLOVIMA. Treba napomenuti da se linkovi uvijek komentarišu (natpis na liniji koja prikazuje vezu).
Rice. 3. Element dijagrama ER
Dajemo i primjer ( pirinač. 4) slike reflektivnog odnosa "zaposleni", gdje jedan zaposlenik može nadzirati nekoliko podređenih i tako niz hijerarhiju pozicija.
Rice. 4. ER dijagram refleksivne relacije
Imajte na umu da je takav odnos uvijek neobavezan, inače bi to bila beskonačna hijerarhija.
Atributi entiteta mogu biti ključni - oni su podebljani; obavezno - prethodi im znak "*", odnosno njihova vrijednost je uvijek poznata, neobavezno (opcionalno) - prethodi im O, odnosno vrijednosti ovog atributa u nekom trenutku mogu biti odsutan ili nedefinisan.
Za početak
lukovi
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 se može izdati ili za pravno lice ili za pojedinac. Prikazan je fragment ER dijagrama za ovu vrstu odnosa pirinač. 5.
Rice. 5. Arc
U ovom slučaju, atribut VLASNIK entiteta RAČUN ima posebno značenje za ovaj entitet - entitet je podijeljen na tipove po kategorijama: "za pojedinca" i "za pravno lice". Rezultirajući entiteti se nazivaju podtipovi, a originalni entitet postaje supertip. Da bismo razumjeli da li je supertip potreban ili ne, potrebno je ustanoviti koliko istih svojstava imaju različiti podtipovi. Treba napomenuti da je zloupotreba podtipovi i supertipovi je prilično česta greška, kao što je prikazano u pirinač. 6.
Rice. 6. Podtipovi (desno) i supertip (lijevo)
Za početak
Normalizacija
Kako bi se spriječile anomalije u obradi podataka, koristi se normalizacija. Principi normalizacije za objekte informacionog modela su potpuno isti kao i za modele podataka.
Dozvoljene vrste veza. Pri bližem razmatranju, odnosi jedan na jedan ( pirinač. 7) gotovo uvijek se ispostavi da su A i B zapravo različiti podskupovi iste stvari ili različitih gledišta na to, samo imaju različita imena i različito opisane odnose i atribute.
Rice. 7. Odnosi jedan na jedan
Odnosi više na jedan su prikazani u pirinač. 8.
Rice. 8. Odnosi više na jedan
I je dovoljno jaka konstrukcija da se unos entiteta B ne može kreirati bez istovremenog kreiranja najmanje 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 sa pojavljivanjem entiteta A i bez njega.
III - retko se koristi. I A i B mogu postojati bez veze između njih.
Odnosi mnogo prema mnogo prikazani su u pirinač. 9.
Rice. 9. Odnosi "mnogo-prema-više".
I - takva konstrukcija se često odvija na početku faze analize i znači vezu - ili nije u potpunosti shvaćena i koja zahtijeva dodatnu dozvolu, ili odražava jednostavan kolektivni odnos - dvostruko povezanu listu.
II - retko se koristi. Takve veze uvijek podliježu dodatnim detaljima.
Razmotrite sada rekurzivne veze ( pirinač. 10).
Rice. 10. Rekurzivne veze
Ja - rijetko, ali se javlja. Odražava veze alternativnog tipa.
II - često se koristi za opisivanje hijerarhija sa bilo kojim brojem nivoa.
III - odvija se u ranim fazama. Često odražava strukturu "liste materijala" (međusobno ugniježđenje komponenti). Primjer: svaka KOMPONENTA se može sastojati od jedne ili više (drugih) KOMPONENTI i svaka KOMPONENTA se može koristiti u jednoj ili više (drugih) KOMPONENTI.
Nevažeći tipovi linkova. Nevažeći tipovi odnosa uključuju sljedeće: Obavezni odnos više-prema-više ( pirinač. jedanaest) i niz rekurzivnih veza ( pirinač. 12).
Rice. 11. Nevažeći odnosi više-prema-više
Rice. 12. Nevažeće rekurzivne veze
Obavezna veza više-prema-više je u osnovi nemoguća. Takav odnos bi značio da nijedna pojava A ne bi mogla postojati bez B, i obrnuto. U stvari, svaka takva konstrukcija uvijek se pokaže pogrešnom.
Za početak
Dijagrami toka podataka
Logic DFD ( pirinač. 13) prikazuje izvore i prijemnike (odredišta) podataka van sistema, identifikuje logičke funkcije (procese) i grupe elemenata podataka koji povezuju jednu funkciju sa drugom (tokovi), a takođe identifikuje skladišta podataka (akumulatore) kojima se pristupa. Strukture toka 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žeg nivoa; kada dalji detalji više nisu korisni, prelazi se na izražavanje logike funkcije pomoću specifikacije procesa (mini-specifikacija). Sadržaj svake trgovine je također pohranjen u rječnik podataka, a model podataka spremišta je izložen korištenjem ER dijagrama.
Rice. 13. Primjer DFD-a
Konkretno, DFD ne prikazuje procese koji kontroliraju stvarni tok podataka i ne pravi razliku između valjanih i nevažećih putanja. DFD sadrže mnogo korisnih informacija, a pored toga:
omogućavaju vam da predstavite sistem u smislu podataka;
ilustruju mehanizme za unos eksternih podataka koji bi zahtevali posebne interfejse;
omogućavaju predstavljanje i automatizovanih i ručnih procesa sistema;
izvršiti particioniranje cijelog sistema usmjereno na podatke.
Tokovi podataka se koriste za modeliranje prijenosa informacija (ili čak fizičkih komponenti) iz jednog dijela sistema u drugi. Tokovi na dijagramima su predstavljeni imenovanim strelicama, strelice pokazuju smjer toka informacija. Ponekad se informacije mogu kretati u jednom smjeru, obraditi i vratiti svom izvoru. Takvu situaciju mogu modelirati ili dva različita toka, ili jedan dvosmjerni.
Proces transformira ulazni tok u izlazni tok u skladu sa radnjom specificiranom imenom procesa. Svaki proces mora imati jedinstveni broj da ga referencira unutar dijagrama. Ovaj broj se može koristiti zajedno sa brojem dijagrama kako bi se obezbijedio jedinstveni indeks procesa u cijelom modelu.
Skladištenje podataka (skladištenje podataka) vam omogućava da definirate podatke u brojnim područjima koja će biti pohranjena u memoriji između procesa. U stvari, skladište predstavlja "odsječke" tokova 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 spremišta treba da identifikuje njegov sadržaj. U slučaju kada tok podataka ulazi (izlazi) u (iz) skladišta i njegova struktura odgovara strukturi skladišta, on mora imati isto ime, što ne mora biti prikazano u dijagramu.
Eksterni entitet (terminator) predstavlja entitet izvan konteksta sistema, koji je izvor ili primalac sistemskih podataka. Njegovo ime mora sadržavati imenicu, kao što je "Klijent". Pretpostavlja se da objekti predstavljeni takvim čvorovima ne bi trebali učestvovati ni u kakvoj obradi.
Za početak
STD dijagrami prijelaza stanja
Životni ciklus entiteta pripada klasi STD dijagrama ( pirinač. 14). Ovaj dijagram odražava promjenu stanja objekta tokom vremena. Na primjer, razmotrite stanje proizvoda u skladištu: proizvod se može naručiti od dobavljača, isporučiti u skladište, uskladištiti u skladištu, podvrgnuti kontroli kvaliteta, prodati, odbiti, vratiti dobavljaču. Strelice na dijagramu pokazuju dozvoljene promjene stanja.
Fig.14. Primjer DFD-a
Postoji nekoliko različitih opcija za prikaz takvih dijagrama, a slika prikazuje samo jednu od njih.
Za početak
Neki principi za provjeru kvaliteta i potpunosti informacijskog modela (izvor - Richard Barker, Case Method: Entity Relationship Modeling, 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 samo analitičari trebaju biti uključeni u izgradnju i kontrolu informacionog modela. Pomoć kolega takođe može biti od velike pomoći. Uključiti ih u provjeru cilja iu detaljnu studiju izgrađenog modela, kako u smislu logike tako i u smislu uzimanja u obzir aspekata predmetne oblasti. Većina ljudi lakše pronalazi nedostatke u tuđem radu.
Redovno predstavljajte svoj informacioni model ili njegove pojedinačne fragmente za koje sumnjate na odobravanje korisnika. Obratite posebnu pažnju na iznimke od pravila i ograničenja.
Za početak
Kvalitet entiteta
Glavna garancija kvaliteta entiteta je odgovor na pitanje da li je objekat zaista entitet, odnosno važan objekat ili pojava, o kojoj informacije treba da se pohranjuju u bazi podataka.
Lista verifikacionih pitanja za entitet:
Da li ime entiteta odražava suštinu ovog objekta?
Postoji li raskrsnica sa drugim entitetima?
Postoje li barem dva atributa?
Zar ukupno nema više od osam atributa?
Postoje li sinonimi/homonimi za ovaj entitet?
Da li je entitet u potpunosti definisan?
Postoji li jedinstveni identifikator?
Postoji li barem jedna veza?
Postoji li barem jedna funkcija za kreiranje, pretraživanje, ažuriranje, brisanje, arhiviranje i korištenje vrijednosti entiteta?
Postoji li istorija promjena?
Da li postoji usklađenost sa principima normalizacije podataka?
Postoji li isti entitet u drugom aplikacijskom sistemu, možda pod drugim imenom?
Da li je suština previše uopštena?
Da li je nivo generalizacije oličen u njemu dovoljan?
Lista skrining pitanja za podtip:
Ima li preklapanja s drugim podtipovima?
Ima li podtip neke atribute i/ili odnose?
Da li svi imaju svoje jedinstvene identifikatore ili svi nasljeđuju jedan od supertipa?
Postoji li iscrpan skup podtipova?
Nije li podtip primjer pojave entiteta?
Da li znate za neke atribute, odnose i uslove koji razlikuju ovaj podtip od drugih?
Za početak
Kvalitet atributa
Potrebno je utvrditi da li su to zaista atributi, odnosno da li na ovaj ili onaj način opisuju ovaj entitet.
Lista sigurnosnih pitanja za atribut:
Da li je naziv atributa imenica u jednini koja odražava suštinu svojstva označenog atributom?
Ne uključuje li ime atributa ime entiteta (ne bi trebalo)?
Ima li atribut samo jednu vrijednost u isto vrijeme?
Nedostaju li duplirane vrijednosti (ili grupe)?
Da li su opisani format, dužina, važeće vrijednosti, algoritam izvođenja, itd.?
Može li ovaj atribut biti izostavljeni entitet koji bi bio koristan za drugi aplikacioni sistem (postojeći ili predloženi)?
Može li biti propuštena veza?
Da li postoji potreba za istorijom promjena?
Da li njegova vrijednost zavisi samo od datog entiteta?
Ako je vrijednost nekog atributa potrebna, da li je uvijek poznata?
Da li postoji potreba za kreiranjem domene za ove i slične atribute?
Da li njegova vrijednost ovisi samo o nekom dijelu jedinstvenog identifikatora?
Da li njegova vrijednost ovisi o vrijednostima nekih atributa koji nisu uključeni u jedinstveni identifikator?
