Anda di halaman 1dari 6

1 TA JE SOFTVERSKO INENJERSTVO Prilikom reavanja problema, softverski inenjeri koriste poznavanje raunara i raunarstva.

Osnovno je razumeti prirodu problema koji je esto u vezi sa raunarom i raunarskim tehnikama ali i ne mora biti odnosno ne mora biti u potpunosti. U procecu reavanja problema, vidi se da li je neka vrsta raunarskog sistema neophodna ili poeljna. REAVANJE PROBLEMA Istraivanje problema zapoinjemo analizom tj. razlaganjem problema na delove koje moemo da razumemo. Na osnovu toga moemo jedan problem opisati kao skup manjih, medjusobno povezanih problema ili potproblema gde je vano uoiti veze medju njima.. Kada je obavljena analiza problema sledi sastavljanje kompletnog reenja iz delova koji se odnose na razliite aspekte problema tj sinteza kao suprotni proces analizi. Toje sklapanje vee strukture na osnovu manjih gradivnih elemenata. Reavanje problema moe biti potpomognuto razliitim metodama( ili tehnikama), alatima ,procedurama i paradigmama. Metod ili tehnika je formalna procedura za pravljenje neega Alat je instrument ili automatizovani sistem koji pomae da se neto obavi na bolji nain Procedura je kao recept, kombinacija alata i tehnika koji, u medjusobnom skladu, ine proizvod. Paradigma , kao stil rada, predstavlja poseban pristup ili filozofiju gradnje softvera. GDE SE TU UKLAPA SOFTVERSKO INENJERSTVO Treba da razumemo kako se softverski inenjer uklapa u svet raunarske nauke. Moemo da to gledamo kroz raunare i programske jezike, ili da gledamo kroz alate kojise koriste u projektovanju i primeni reenja nekog problema.Softversko inenjerstvo predstavlja ovaj drugi pogled. Umesto da istrauje dizajn hardvera ili dokazuje teoreme iz teorija algoritama, softverski inenjer se usresredjuje na raunar, kao sredstvo za reavanje problema. 2 KOLIKO SMO BILI USPENI Sutina rada softverskog inenjera je u projektovanju i razvoju visoko kvalitetnog softvera. Softver inenjeri prouavaju raunarske mehanizme i teorije da bi ih uinili produktivnijim, efikasnijim.Ali isto tako oniprojektuju raunarske sisteme i piu programe za obavljanje poslova na tim sistemima. 3 TA JE DOBAR SOFTVER Kvalitet softvera posmatramo na najmanje tri naina: Kvalitet proizvoda, kvalitet procesa , kvalitet u kontekstu poslovnog okruenja KVALITET SOFTVERA Kvalitet softvera gleda se u zavisnosti ko ga analizira, pa ako je to korisnik on e verovatno potencirati spoljane karakteristike, nedostatke i broj otkaza, funkcionalnost, laku obuku i sl. Ako softver procenjuju oni koji piu kod, ili projektuju, ili iji je zadatak dalje odravanje programa, oni tee razmatranju internih karakteristika proizvoda, esto pre nego to je i isporuen kupcu. Oni posmatraju broj i tip nedostataka kao dokaz kvaliteta. Programeri mogu daprate broj nedostataka u okviru programskih zahteva i na osnovu toga donesu sud o kvalitetu. Zato se prave modeli koji dovode u vezu spoljanji pogled korisnika i unutranji pogled praktiara na softver. KVALITET PROCESA Mnoge aktivnosti utiu na konani kvalitet softvera i ako neka od njih podje naopako to moe da pogora kvalitet. Zbog toga mnogi softverski inenjeri oseaju da je kvalitet postupka razvoja i odravanja vaan isto kao i kvalitet proizvoda. KVALITET U KONTEKSTU POSLOVNOG OKRUENJA Unapredjenje tehnikih vrednosti se automatski odslikava na unapredjenje poslovne vrednosti i u tom aspektu se moze posmatrati kvalitet proizvoda u okviru neke kompanije. Neko meri kvalitet softvera na osnovu odnosa vremena operativnosti i vremena zastoja, trokova odravanja, trokove izmena i sl. Ako ne postoji jasna poslovna vrednost, projekat se ne pokree. 4 KO SE BAVI SOFTVERSKIM INENJERSTVOM? Najee, uesnici u projektu imaju jednu od tri uloge: kupac, korisnik i projektant. KUPAC je kompanija, organizacija ili pojedinac koji plaa za softverski sistem koji se razvija PROJEKTANT je kompanija, organizacija ili pojedinac koji pravi softverski proizvod za kupca, ukljuujui tu i rukovodioce potrebne za koordinaciju sa programerima i testerima KORISNIK je jedan ili vie pojedinaca koji e stvarno koristirti sistem sedei za terminalom, unosei podatke i itajui rezultate. Iako kod nekih projekata, ista grupa ili pojedinac moe da predstavljea i kupca i projektanta i korisnika, u veini sluajeva se radi o razliitim pojedincima ili grupama. 5 SISTEMSKI PRILAZ AKTIVNOSTI I OBJEKTI Aktivnosti su neka deavanja u sistemu, dogadjaj iniciran nekim okidaem, koji transformie neku stvar dajui joj nove osobine. Kod IS tu su razne promene na podacima, kao premetanje lokacijski, promena vrednosti, komponovanje sa drugim podacima da bi se napravio ulaz za novu aktivnost itd. Elementi ukljueni u aktivnost zovu se objekti, koji mogu da budu grupisani u zapise. Npr. zapis o ueu radnika na poslu moe biti zapisan na ovaj nain: Ime, Srednjeslovo, Prezime, Adresa, Mesto, Potanski broj, Satnica, Dodaci, Sati rada, Sati bolovanja, Slobodni sati Date su osobine kao tip podatka,poetne pozicije i duine polja ( npr. prezime varchar (50) ). ODNOSI I GRANICE SISTEMA Odnosi izmedju entiteta i aktivnosti su jasno definisani. Objekti mogu da se koriste u okviru posmatranog sistema ili ga koriste i drugi sistemi, ili posmatrani sistem koristi objekte iz drugih sistema. Sama ova pojava govori nam da sistem ima svoje granice. Ove granice sistema trebadefinisati. Sada sistem moemo definisati kao: skup objekata(entiteta), skup aktivnosti, opis odnosa izmedju objekata i aktivnosti, definiciju granica sistema. 6 INENJERSKI PRISTUP Dakle razvoj softvera obuhvata sledee aktivnosti(faze): analiza i definisanje zahteva projektovanje sistema projektovanje programa pisanje programa testiranje jedinica integrativno testiranje testiranje sistema isporuka sistema odravanje 7 LANOVI RAZVOJNOG TIMA ULOGE RAZVOJNOG TIMA ANALIZA I DEFINISANJE SISTEMA -Analitiar PRPJEKTOVANJE SISTEMA -Analitiar, Projektant PROJEKTOVANJE PROGRAMA- Projektant, Programer IMPLEMENTACIJA PROGRAMA- Programer TESTIRANJE JEDINICA -Testni inenjer,Programer INTEGRATIVNO TESTIRANJE -Projektant, Programer TESTIRANJE SISTEMA -Analitiar, Projektant, Programer ISPORUKA SISTEMA- Instruktor ODRAVANJE

MODELOVANJE PROCESA I IVOTNOG CIKLUSA 1 ZNAENJE TERMINA PROCES Procesom moemo smatrati niz koraka koji obuhvatajuaktivnosti, ogranienja I resurse, Irezultiraju eljeno ostvarenje. Proces obino ukljuuje skup alata I tehnika. Svaki proces poseduje sledee karakteristike: 1 Proces propisuje sve glavne aktivnosti 2 Proces koristi resurse, koji podleu skupu ogranienja (kao to je raspored), I rezultira medjuproizvodima I finalnim proizvodima 3 Proces moe da se sastoji od medjusobno povezanihpodprocesa. Moe biti definisan kao hijerarhija drugih procesa, organizovanih tako da je svaki podproces zasnovan na vlastitom modelu 4 Svaka aktivnost u sklopu procesa poseduje uslove za pokretanje I terminiranje 5 Aktivnosti su organizovane u sekvence, tako da jejasno kada se jedna aktivnost izvodi u odnosu na druge 6 Svaki process poseduje skup uputstava koja objanjavaju ciljeve svake aktivnosti 7 Ogranienja ili kontrole mogu da se primene na aktivnosti,resurse ili proizvod.(npr. Budet moe da ogranii trajanje pojedine aktivnosti ) Ponekad proces izrade softverskog proizvoda nazivamo ivotni ciklus softvera jer opisuje ivot softverskog proizvoda od formulisanja, izrade, implementacije, operativnog korienja Iodravanja. Procesi su vani zato to omoguavaju stalni skup aktivnosti, posebno je to vano kada posedujemo znanja da neto uradimo dobro, a elimo da I drugi to urade na isti nain.( metodologiju uopte). Proces razvoja softvera moe se opisati fleksibilno tako da pojedinci mogu da koriste alate I resurse koji njima vie odgovaraju, a da se pri tome odri nivo kvaliteta proizvoda. Proces je sloeniji pojam od postupka, on u sebi sadri vie postupaka I moe da sugerie da se razliiti postupci ponavljaju, sve dok se ne postigne unapred zadati cilj. Procesi su takodje vani jer omoguavaju evidentiranje iskustava I njihovo prosledjivanje drugima. Svaki proces moe da se opie na razliite naine pomou teksta, slika ili njihovom kombinacijom. Postoje razliite forme takvih opisa, odnosno organizovani modelikoji sadre kljune odlike procesa. 2 MODELI PROCESA IZRADE SOFTVERA MODEL VODOPADA Model vodopada podrazumeva da jedna faza u razvoju softvera treba da se u potpunosti okona, da bi druga zapoela. Zbog toga, tek kada su svi zahtevi kupaza iskazani, analizirani sa aspekta potpunosti I doslednosti, dokumentovani razvojni tim moe da nastavi sa aktivnostima u vezi sa dizajnom sistema. Posle svake aktivnosti dati su I izvetaji, tako da rukovodioci projekta, na osnovu pojedinih modula mogu damere stepen gotovosti projekta. Model vodopada je koristan zato to se jednostavno moe videti ta jo projektni tim treba da uradi. Mnogi drugi, sloeniji modeli, u stvari predstavljaju ulepani model vodopada, kroz ukljuivanje povratnih sprega I dodatnih aktivnosti. (dijagram vodopada) Analiza zahteva Projektovanje sistema Projektovanje programa Kodiranje Testiranje delova i celine Testiranje sistema Zavrno testiranje Operativni rad i odravanje Najvei problem kod modela vodopada je to on ne odraavastvarni nain na koji se projekat razvija. Osim samo za jednostavne problem, softver se razvija kroz velikibroj iteracija. Analiza zahteva - --Validacija ------------------------------------| Projektovanje sistema ----Verifikacija ----- ---------- | | | Projektovanje programa | | | | | Kodiranje | | | | | Testiranje delova i celine | | | | | Testiranje sistema - -------| | | Zavrno testiranje | | | Operativni rad i odravanje IZRADA PROTOTIPA Modifikovani model vodopada sa izradom prototipa V MODEL V model je modifikovani model vodopada, koji pokazuje odnos testiranja I faza analize I dizajna. Kodiranje je ishodite V modela, dok su na levoj strani analiza I projektovanje a na desnoj testiranje I odravanje. V model sugerie da testiranje delova I testiranje pri integraciji mogu da se koriste za verifikovanje dizajna programa. Slino tome, testiranje sistema treba da verifikuje dizajn sistema. Zavrni test sistema slui validaciji zahteva. Operativni rad i odravanje analiza zahteva <------------------------------------------------------------>zavrno testiranje | | projektovanje sistema<---------------------------------->testiranje sistema | | projektovanje programa---------------testiranje delova i celine | | kodiranje V model PROTOTIPSKI MODEL Izrada prototipa ne mora da bude samo dopuna modelavodopada vesama po sebi moe da bude osnov za efikasno modelovanje procesa. Prototipski model omoguava da se kompletan sistem ili neki njegovi funkcionalni delovi brzo konstruiu I tako omogue bolje razumevanje otvorenih pitanja. FAZNI RAZVOJ: INKREMENTI I ITERACIJE Dananja poslovna okruenja ne toleriu duga ekanja kod izrade softvera. Jedan od naina smanjenja vremena izrade prijekta je tkz. fazni razvoj. Sistem se projektujetako da moe da se isporuuje u delovima, omoguujui korisnicima da raspolau sa nekim funkcijama, dok su druge jo u razvoju. Tako imamo dva sistema, koji uporedo funkcioniu, produkcioni sistem I razvojni sistem. Produkcioni sistem je onaj koji trenutno koriste naruilac I korisnik. Razvojni sistem predstavlja sledeu verziju koja se priprema da zameni ( ili dopuni )postojei produkcioni sistem. Razvojni sistem Izrada verzije 1 Upotreba verzije1 Produkcioni sistem Izrada verzije 2 Upotrebaverzije 2 Izrada verzije 3 Upotrebaverzije 3

Dva najpopularnija pristupa faznom razvoju su inkrementalni razvoj I iterativni razvoj. Kod inkrementalnog razvoja, sistem onako kako je definisan se deli na podsisteme prema funkcijama. Verzije se definiu kao mali funkcionalni sistemi, a zatim se svakoj novoj verziji pridodaju nove funkcije. Kod iterativnog razvoja, isporuuje se odmah pun sistem, a zatim se menjaju funkcije podsistema u svakoj novoj verziji. Neki delovi sistema u prvoj verziji mogu sadrati primitivna reenja, toliko da se sagleda celina, izvri obuka I sl. Prednosti faznog razvoja su: Obuka moe da zapone sa prvom verzijom. Izvrenje nekih funkcija moeda sugerie projektnom timu ta ispraviti u sledeim verzijama. Na trite moe da se izadje vrlo rano, posebno akose radi o funkcionalnostima koje ranije nisu obradjene. este verzije omoguavaju projektnom timu da brzo otkloni nepredvidjeneprobleme Projektni tim moe da se usresredi na razliite oblasti usavravanja sistema

PLANIRANJE PROJEKTA I UPRAVLJANJE NJIM 1 PRAENJE NAPRETKA Prilikom poetne komunikacije, kada je naruilac izneo svoje potrebe Obino naruilac ima nekoliko pitanja na koje treba dati odgovor: Da li razumete moj problem I moje potrebe Da li moete da projektujete sistem koji bi reio moj problem I zadovoljio moje potrebe Koliko vremena e vam biti potrebno da razvijete taj sistem Koliko e kotati razvoj tog sistema U prepoznavanju potreba naruioca (kupca ili korisnika) kako bismo ih shvatili, istovremeno proveravamo da li su oni zadovoljni na koji nain smo prepoznali njihove potrebe, I navodimo sve medjuproizvode tj. stavke koje naruilac oekuje da dobije tokom razvoja projekta. U medjuproizvode spadaju: dokumenti demonstracija funkcija demonstracija podsistema demonstracija tanosti demonstracija pouzdanosti, bezbednosti I performansi Nakon toga utvrdjujemo koje aktivnosti moraju da sesprovedu u cilju realizacije projekta. Paljivim ispitivanjem projekta moemo podeliti razvoj na nizfaza, svaka faza se sastoji od niza koraka a svakikorak moe biti predmet dalje podele. 2 OSOBLJE NA PROJEKTU ULOGE I KARAKTERISTIKE TIMA Nakon donoenja odluke o ulogama lanova projektnog tima, neophodno je doneti i o ljudima koji su za svaku od njih potrebni. Osoblje projekta moe dase razlikuje na vie naina, I nije dovoljno da kaemo da projekat, na primer, zahteva jednog analitiara, dva projektanta I pet programera. Dve osobe koje konkuriu za isto radno mesto mogu da se razlikuju po najmanje jednom od sledeih kriterija: sposobnost izvravanja posla interesovanje za posao iskustvo sa slinim aplikacijama iskustvo sa slinim alatima I jezicima iskustvo sa slinim tehnikama iskustvo sa slinim razvojnim okruenjem obuenost sposobnost komunikacije sa drugima sposobnost podele odgovornosti sa drugima sposobnost rukovodjenja

ORGANIZACIJA PROJEKTA

3 POTREBAN RAD 4 UPRAVLJANJE RIZICIMA 5 PLAN PROJEKTA Plan projekta u pisanom obliku sadri korisnikove potrebe-zahteve I nae namere vezane za zadovoljenjetih potreba-zahteva. Planom iskazujemo predvidjene trokove, rokove, organizaciju, rizike I upravljanje njima I sl. Dobar plan projekta mora da ima sledee elemente: Obim projekta rokove projekta organizaciju projektnog tima tehniki opis predloenog sistema standarde koji se u projektu koriste plan osiguranja kvaliteta plan upravljanja konfiguracijom plan dokumentovanja plan upravljanja podacima plan upravljanja resursima plan testiranja plan obuke plan bezbednosti plan upravljanja rizicima plan odravanja

EVIDENTIRANJE ZAHTEVA 1 PROCES VEZAN ZA ZAHTEVE Zahte vpredstavlja izraz eljenog ponaanja. Zahtev se bavi objektima ili entitetima, stanjima u kojim oni mogu biti, kao I funkcijama koje se izvode radipromene stanja ili osobina objekta. Zahtev ne odredjuje implementaciju sistema, bazu podataka koja e se koristiti, koja arhitektura, koliko memorije na raunaru treba da ima, koji programski jezik I sl. Cilj fazed efinisanja zahteva je razumevanje problema i potreba naruioca. Dakle, zahtevi su okrenuti naruiocu Iproblemu, a ne reenju ili implementaciji. Kaemo da zahtevi oznaavaju kakvo ponaanje naruilac eli, bez izraavanja kako e to ponaanje biti ostvareno. Rasprava o reenju je preuranjena sve dok se problem jasno ne definie. Tokom faze specifikacije zahteva, odluiemo koje zahteve e projektovani softverski sistem da ispuni a koje, suprotno tome, e da odrade hardverski uredjaji posebne namene, drugi softverski sistemi, korisnici ili operateri. Izvrilac posla evidentiranje zahtevaje obino analitiar zahtevaili analitiar sistema. Analitiar zahteva prvo radi sa naruiocima na izvodjenju zahteva: postavlja pitanja, ispituje aktuelno ponaanje ili demonstrira sline sisteme. Zatim se zahtevi evidentiraju u obliku modela ili prototipa. Kada se postigne dobro razumevanje zahteva, posao se nastavlja izradom specifikacije, u kojoj se odluuje koji e delovi zahtevanog ponaanja biti ukljueni u softveru. Tokom validacije, proverava se da li specifikacija odgovara onome to naruilac eli da vidi u finalnom proizvodu. Aktivnosti analize I validacije mogu da otkriju probleme ili propuste u modelu I specifikaciji, to prouzrokuje ponovne posete naruiocu I revidiranje modela I specifikacije. Krajnji ishod ovog procesa je specifikacija softverskih zahteva, koja se koristi za komunikaciju sa drugim lanovima razvojnog tima (npr dizajniranje, testiranje, odravanje), o tome kako konani proizvod treba da se ponaa. Proces evidentiranja zahteva: Prikupljane korisnikih zahteva; Razumevanje I modelovanje eljenog ponaanja; Dokumentovanje ponaanja predloenog softverskog sistema; Provera da li specifikacija odgovara korisnikim zahtevima. 2 IZVODJENJE ZAHTEVA Ko su zainteresovani subjekti: Klienti su oni koji finansiraju projekat Kupci su oni koji kupuje softver nakon to je razvijen Korisnici, poznaju postojei I koristie budui sistem Strunjaci iz konkretne oblasti primene Istraivai trita Advokati ili revizori Softverski inenjeri I drugi tehnolozi Kako projektanti vide korisnike: Korisnici ne znaju ta hoe ne mogu da artikuliu ono to hoe nisu sposobni da obezbede korisnu formulaciju svojih potreba imaju suvie potreba koje su politiki motivisane sve hoe odmah ne mogu da prate rokove ne umeju da dodele prioritete svojim potrebama nisu radi da prave kompromise odbijaju da preuzmu odgovornost za sistem nisu posveeni razvojnim projektima Kako korisnici vide projektante: Projektanti ne razumeju operativne potrebe ne mogu jasno da prevedu navedene potrebe u uspeansistem postavljaju nerealne standarde za defenisanje zahteva stavljaju veliki naglasak na tehnika pitanja uvek kasne ne mogu brzo da odgovore na legitimno izmenjene potrebe uvek premauju budet sve vreme govore ne pokuavaju da nam kau kako da radimo na posao 3 TIPOVI ZAHTEVA Kada se razmilja o zhtevima, razmilja se o traenoj funkcionalnosti tj. koje usluge treba da se obezbede? ta treba da bude reakcija na odredjeni stimulans? Kako se zahtevano ponaanje menja u funkciji vremena? Funkcionalni zahtev opisuje obavezno ponaanje u funkciji neophodnih aktivnosti, kao to su: reakcija na ulaze i stanja svakog entiteta pre pojave i nakon okonanja svake aktivnosti. Funkcionalni zahtev odredjuje granice koje omedjuju prostor reenja naeg problema. Zahtev u pogledu kvaliteta ili nefunkcionalni zahtev opisuje neke karakteristike kvaliteta koje softversko reenje mora da poseduje, kao to je kratko vreme odziva, lako korienje, visoka pouzdanost ili niski trokovi odravanja. Okvirna ema prioriteta mogla bi da klasifikuje zahteve u tri kategorije: sutinski zahtevi koji apsolutno mora da se zadovolje poeljni zahtevi koji su veoma poeljni ali nisu nuni opcioni zahtevi koji se mogu ispuniti ali se mogu I izostaviti DVE VRSTA DOKUMENATA O ZAHTEVIMA Nekada je to jedan dokument ali su najee dva: definicija zahteva namenjena poslovnom auditorijumu, kao to su kupci,naruioci I korisnici I specifikacija zahtevana menjena tehnikom auditorijumu kao to su projektanti, timovi za testiranje I rukovodioci projekta. Definicija zahteva predstavlja kompletan spisak svega to naruilac eli da postigne. Dokument sadri neophodne zahteve, opis entiteta koji pripadaju okruenju u kojem e predloeni sistem biti instaliran, kao I eljena ogranienja u vezi sa entitetima. Svrha predloenog sistema jeste realizacija tih zahteva pa prema tome zahtevi su potpuno iskazani u smislu okruenja i opisuju kako e predloeni sistem uticati na okruenje. Specifikacija zahteva iskazuje zahteve u vidu specifikacije ponaanja predloenog sistema.Specifikacija je takodje iskazana u smislu okruenja, s tom razlikom to se odnosi samo na one entitete, kojima moe da se pristupi posredstvom njegovog interfejsa. 4 KARAKTERISTIKE ZAHTEVA Da bi krajnji proizvod bio uspean, vano je da zahtevi budu visoko kvalitetni. Zbog provere kvaliteta, poeljne osobine zahteva su: Da li su zahtevi ispravni?I analitiar I naruilac zahteva treba da pregledaju zahteve I uvere seda su shvatanja zahteva uskladjena. Da li su zahtevi dosledni?Da li postoje suprotstavljeni zahtevi? Npr. ako jedan zahtev navodi da maksimalno deset korisnika moe istovremeno da napada sistem a drugi zahtev trai da u jednom momentu to moe da ini dvadeset korisnika, onda su zahtevi nedosledni. Da li su zahtevi nedvosmisleni?Zahtevi su vieznani ako vie osoba koje analiziraju dokument sa zahtevima dodje do razliitih ali ispravnih interpretacija. Npr. zahtev kaeda radnik treba da dobije nadoknadu za topli obrok, a nije definisao za koje sate rada to vai. Da li su zahtevi kompletni?Skup zahteva je kompletan ako specifikuje zahtevano ponaanje I izlaz za sve mogue kombinacije ulaza,u svim moguim stanjima I pod svim moguim ogranienjima. Npr. za sistem za obraun zarada treba definisati ta se deava kada radnik uzme neplaeno odsustvo, dobije poviicu ili trai akontaciju. Da li su zahtevi izvodljivi?Da li uopte postoji reenje za zahtev naruioca? Npr. zahtev kae da naruilac eli da glavnom raunaru, koji je udaljen nekoliko hiljada kilometara svi korisnici imaju isto vreme pristupa, a to je iz tehnikih razloga nemogue. Da li je svaki zahtev relevantan?Ponekad zahtevi nepotrebno ograniavaju razvojni tim ili ukljuuju funkcionalnosti koje nisu u direktnoj vezi sa potrebama korisnika. Npr. general trai da novi softverski sistem omogui vojnicima da alju I primaju elektronsku potu. Zainteresovanim subjektima treba da pomognemo da se usresrede na sutinske I poeljne zahteve. Da li je zahteve mogue testirati?Zahtevi se mogu testirati ako je mogue formulisati testove koji jasno definiu da li konani proizvod zadovoljava te zahteve.

Npr. ako zahtevkae da sistem treba da obezbedi odgovor brzo mi ne znamo ta je to, aliako kae da treba da odgovori u roku od 1 sec mi taj zahtev moemo da testiramo. Da li zahtevi mogu da se prate?Da li su zahtevi organizovani I jedinstveno oznaeni da mogu da se uporedjuju definicija I specifikacija zahteva? 5 DIJAGRAMI ODNOSA IZMEDJU ENTITETA (NOTACIJE MODELA) Dijagram odnosa izmedju entiteta ili ER dijagram( Entity-Relationship diagram) je popularna grafika notaciona platforma za predstavljanje konceptualnih modela. ER dijagrami predstavljaju osnovu veine objektno orijentisanih notacija za predstavljanje zahteva i dizajna, gde se ona koristi za modelovanje odnosa izmedju objekata iz domena problema ili za modelovanje strukture softverskog proizvoda. Isto tako ER dijagram moe da se koristi za prikazivanje eme baze podataka. ER dijagrami se zasnivaju na tri osnovna elementa: entitet, atribut i odnos (relacija), koje se kombinuju radi specifikovanja elemenata problema i njihovih veza. Entitet, predstavljen pravougaonikom, je skup, ili ponekad kaemo klasa, objekata iz realnogsveta koji imaju zajednike osobine i ponaanja. Odnos ( ili ralacija) je predstavljen linijom koja spaja dva entiteta, sa rombom na sredini koji definee tip odnosa. Atribut je obeleje entiteta, koji opisuje podatke ili svojstva pridruena entitetu. KONANI AUTOMATI Konani automat je grafiki opis svih komunikacija izmedju sistema I njegovog okruenja. Svaki vor, koji se naziva stanje predstavlja postojan skup uslova koji se odravaju u intervalu izmedju pojave dogadjaja. Svaka grana, koja se naziva prelaz stanja, predstavlja promenu koju je dogadjaj proizveo u ponaanju ili u uslovima. Svaki prelaz iz jednog stanja u drugo obeleen je pobudnim dogadjajem, a ponekad I izlaznim dogadjasjem koji se generie kada se dogodi prelaz. DEFINISANJE ZAHTEVA ZA INFORMACIONIM SISTEMOM Kljune aktivnosti, koje se mogu izdvojiti u definisanjuzahteva za informacionim sistemom, su prikupljanje informacija, prikupljanje podataka i ustanovljavanje injenica. PRIKUPLJANJE INFORMACIJA Jedna od aktivnosti kod definisanja zahteva za IS su intervjui sa kljunim korisnicima i radni sastanci. Ako naruilac zapoljava informatiare, svakako ih treba ukljuiti u analizu. Sueljavanje korisnika i informatiara ubrzava reavanje protivrenih iskaza. Kao zamena za intervjue koriste se upitnici i ankete, koji su pogodni i za prikupljanje informacija o resursima. Analiza dokumentacije podrazumeva prikupljanje cjelokupne dokumentacije znaajne za poslovanje, radi boljeg utvrdivanja pravila, poslovne politike, ciljeva poslovanja i strukture informacija. RADNI SASTANCI Radni sastanci se organizuju da analitiari i korisnici zajedniki provode analizu i oblikovanje. Cilj sastanka je zajedniko pronalaenje najboljeg reenja. Za to je potreban poseban prostor i izolacija, dnevni red i zapisnici . RAZVOJ PROTOTIPA Razvoj prototipa se koristi kada korisnik ne moe tano da definie svoje informatike potrebe pre nego to se izgradi informacioni sistem. Razlog tome moe biti nedostatak postojeeg modela na kojem bi korisnik zasnivao svoje potrebe ili pak teka vizuelizacija budueg sistema. Da bi se olakala vizuelizacija budueg sistema izgraduje se sistem koji zadovoljava neke osnovne, inicijalne potrebe. U radu sa takvim sistemom korisnik otkriva svoje informatike potrebe, te se sistem modifikuje kako bi se zadovoljile te potrebe. Postupak koritenje sistema i modifikovanje istog iterativno se ponavlja, a informatike potrebe korisnika otkrivaju koritenjem sistema. Izrada prototipa pogodna je u onim okruenjima gdjeje teko definisati konkretni model sistema, te u okruenjima gdje se informatike potrebe korisnika menjaju ili razvijaju NAJEI PROBLEMI PRI PRIKUPLJANJU INFORMACIJA Ponaanja korisnika esto moe da uzrokuje niz problema pri definisanju zahtjeva za IS. Informatickim argonom su opisana ponaanja koja semogu oekivati od korisnika. 1. 2. 3. Taktika kuhinjskog sudopera: korisnik navodi (preko)brojne potrebe, gomilu nepotrebnih izvetaja, ekranskih formi, sortiranja, izraunavanja i sl. Ovakav pristup obino je uzrokovan pomanjkanjem iskustva korisnika, koji ne zna ta bi mu stvarno moglo zatrebati, ili nije u stanju izdvojiti ono taje bitno; 2. Taktika dimne zavese: korisnik trai vie mogunosti, a zapravo mu je potrebna samo jedna ili dvije. Dodatni zahtevi slue za postizanje bolje nagodbe sa analitiarom. Ova taktika obicno oslikava korisnika sa dobrim poznavanjem onoga ta eli, a zahteve treba reducirati na one realne I izvodljive; 3. Taktika "Treba mi isto, ali u boljem obliku": korisniku koji koristi ovu taktiku nedostaje volja ili znanje, a ponekad oboje. anse za uspeno definisanje problema su male, jer samo korisnik moe izraziti svoje potrebe i probleme.

Korisnik je sklon da preuti izuzetke, koji su bitni (nuni!) za uspenu realizaciju, a obino izuzeci zahtevaju i najvie napora tokom ugradnje: "To je naa jedina procedura (osim kada )". Ne izjednaavati tako se uvijek radi sa tako treba raditi!

Anda mungkin juga menyukai