PREDMET

IS201 OSNOVI INFORMACIONIH SISTEMA

Predavanje broj 9 IS201-P09

METODOLOGIJE ZA RAZVOJ INFORMACIONIH SISTEMA

Predavanja Nedelja 9 as Jedinice znanja Nastavna jedinica/Nastavne teme

Rezultat znanja ili vetine koje student treba da dobije

1 2 3

Copyright 2010 UNIVERZITET METROPOLITAN, Beograd. Sva prava zadrana. Bez prethodne pismene dozvole od strane Univerziteta METROPOLITAN zabranjena je reprodukcija, transfer, distribucija ili memorisanje nekog dela ili itavih sadraja ovog dokumenta., kopiranjem, snimanjem, elektronskim putem, skeniranjem ili na bilo koji drugi nain. Copyright 2010 BELGRADE METROPOLITAN UNIVERSITY. All rights reserved. No part of this publication may be reproduced, stored in a retrieval system or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, scanning or otherwise, without the prior written permission of Belgrade Metropolitan University.

Oktobar, 2012.

IS201 UVOD U INFORMACIONE SISTEME

Predavanje br. 9

SADRAJ
Uvod ........................................................................................................................................................ 3 ivotni ciklus razvoja informacionih sistema ........................................................................................... 3 Prva faza planiranje........................................................................................................................... 4 Druga faza analiza............................................................................................................................. 5 Trea faza dizajn ............................................................................................................................... 6 etvrta faza implementacija.............................................................................................................. 7 Peta faza odravanje......................................................................................................................... 8 Varijacije ivotnog ciklusa razvoja informacionih sistema....................................................................... 9 Tradicionalni SDLC tipa vodopada........................................................................................................ 9 Prototajping........................................................................................................................................ 10 Joint Application Design (JAD) ........................................................................................................... 10 Brzi razvoj aplikacija (Rapid Application Development RAD) .......................................................... 11 Objektno orijentisan pristup razvoja ...................................................................................................... 12 UML (Unified Modeling Languange) ................................................................................................... 12 RUP (Rational Unifed Process) ........................................................................................................... 14 Faze razvoja RUP-a........................................................................................................................... 16 Discipline RUP-a................................................................................................................................ 18

Naziv predavanja: METODOLOGIJE ZA RAZVOJ INFORMACIONIH SISTEMA

2/20

IS201 UVOD U INFORMACIONE SISTEME

Predavanje br. 9

Predavanje br. 9

METODOLOGIJE ZA RAZVOJ INFORMACIONIH SISTEMA

Uvod
Razvoj informacionih sistema je sloen proces koji tim poslovnih ljudi i analitiara koristi da bi razvio i odravao informacioni sistem. On se zasniva na sagledavanju ciljeva, strukture i procesa organizacije, kao i na znanjima koja se odnose na mogunost korienja informacionih tehnologija u cilju njenog unapreivanja. U postojeem poslovnom okruenju, : trend je da se u nain poslovanja organizacije to vie inkorporira Internet i posebno World Wide Web. Jedan od vanih, znai ne i jedini rezultat razvoja sistema je aplikativni softver, tj. softver dizajniran tako da podri specifine procese i funkcije organizacije, npr. upravljanje zalihama, obraun plata, analiza trita itd. Pored aplikativnog softvera, informacionim sistemom je obuhvaen hardver i sistemski softver na kojima se aplikativni softver izvrava, dokumentacija, materijali za obuku i ljudi koji taj softver koriste kao pomo u obavljanju svojih radnih zadataka. Centralno mesto u ovom procesu su razliite metodologije, tehnike i alati koji su bili razvijeni, testirani i iroko korieni tokom godina kako bi pomogli ljudima koji se bave sistemskom analzom i dizajnom. Metodologija predstavlja esto sloen pristup razvoju sistema koji se odvija u vie koraka i koji usmerava rad sistem analitiara, znaajno utiui na kvalitet finalnog proizvoda informacionog sistema. U mnoge metodologije je inkorporirano nekoliko razvojnih tehnika. Tehnike su posebni procesi koje sistem analitiari prate kako bi bili sigurni da e njihov rad biti dobro shvaen, zavren i razumljiv za druge iz projektantskog tima. One obezbeuju podrku za veliki opseg zadataka ukljuujui voenje intervjua, planiranje i upravljanje aktivnostima za razvoj sistema, dokumentovanje logike sistema i dizajniranje izvetaja koji e sistem generisati. Alati su obino kompjuterski programi koji olakavaju korienje razliitih tehnika i predstavljaju vodi kroz itavu metodologiju razvoja. Tehnike i alati moraju biti konzistentni sa metodologijom razvoja sistema u organizaciji. Ova tri elementa metodologije, tehnike i alati zajedno ine organizovan pristup u analizi i dizajnu sistema. Mada su mnogi ljudi u organizaciji zadueni za razvoj sistema, u mnogim organizacijama primarnu odgovornost za to imaju sistem analitiari. Njihova prvenstvena uloga je da proue probleme i potrebe organizacije kako bi odredili kako se ljudi, metode i informacione tehnologije mogu najbolje kombinovati u cilju napretka organizacije. Sistem analitiar pomae korisnicima sistema i drugim menaderima poslovanja da definiu svoje zahteve za novim ili unapreenim sistemom.

ivotni ciklus razvoja informacionih sistema

Mnoge organizacije smatraju da je u razvoju i podrci informacionih sistema korisno primenjivati standardan skup koraka, koji se naziva metodologija razvoja sistema.

Naziv predavanja: METODOLOGIJE ZA RAZVOJ INFORMACIONIH SISTEMA

3/20

IS201 UVOD U INFORMACIONE SISTEME

Predavanje br. 9

Jedna od metodologija koja je prihvaena u mnogim organizacijama jeste ivotni ciklus razvoja sistema (System development life cycle SDLC); nju karakteriu faze: planiranje, analiza, dizajn, implementacija i odravanje.

Slika 1. ivotni ciklus razvoja sistema

ivotni ciklus razvoja sistema se moe shvatiti kao kruni proces u kojem zavretak jednog ivotnog ciklusa dovodi do poetka drugog projekta kojim e se razviti nova verzija sistema ili zameniti postojei sistem. (slika 1.) U poetku, ivotni ciklus razvoja softvera se tretirao kao skup sekvencijalno ureenih faza, to se ne moe smatrati tanim, jer se u svakoj fazi ivotnog ciklusa projekat moe, ako je potrebno, vratiti na prethodnu fazu. Takoe je mogue neke aktivnosti iz jedne faze paraleno izvravati sa aktivnostima iz druge faze. Ponekad je ivotni ciklus iterativan, jer se faza moe ponavljati dokle god je potrebno da bi se dobio prihvatljiv sistem.

U svakom sluaju, ivotni ciklus razoja softvera je ureeni skup aktivnosti koje se vode i planiraju za svaki razvojni projekat. Svaka velika ili srednja korporacija i svaki proizvoa softvera ima svoj specifini ivotni ciklus ili metodologiju razvoja sistema. Kada sistem analitiar poinje svoj prvi posao, potrebno je da provede nekoliko nedelja ili mesici uei SDLC svoje organizacije, kao i metodologije, tehnike i alate koje ona koristi.

U okviru ovog kursa je predstavljen model generikog ivotnog ciklusa, pa se sva steena znanja mogu primeniti na bilo koji ivotni ciklus. Svaka faza ivotnog ciklusa ima svoje specifine izlaze koji su pothranjeni vanim informacijama za sledeu fazu. Na kraju svake faze, razvojni projekat sistema ima kontrolnu taku (milestone).

Prva faza planiranje

U ovoj fazi se identifikuju potrebe za novim ili unapreenim sistemom, izuavaju se informacione potrebe organizacije kao celine i identifikuje projekat koji moe da ih zadovolji. Potrebe informacionog sistema mogu da proizau iz zahteva: da se prevaziu problemi u postojeim standardnim operativnim procedurama, iz elje da se izvravaju neki dodatni zadaci ili iz saznanja da se korienjem informacionih tehnologija organizacija moe unaprediti.

Ovim potrebama se mogu dodeliti prioriteti i one transformisati u plan IS odeljenja. Dve glavne aktivnosti koje se izvravaju za vreme faze planiranja su: formalno, jo uvek preliminarno ispitivanje problema sistema i predstavljanje razloga zato organizacija treba ili ne treba da razvije sistem.

Naziv predavanja: METODOLOGIJE ZA RAZVOJ INFORMACIONIH SISTEMA

4/20

IS201 UVOD U INFORMACIONE SISTEME

Predavanje br. 9

to je prikazano na slici 2.

Slika 2. Identifikacija, izbor i planiranje informacionog sistema

Kritian korak u ovoj taki je odreivanje podruja koje treba obuhvatiti predloenim sistemom. Voa projekta i inicijalni tim sistem analitiara prave specifian plan projekta koji projektantski tim treba da sledi. Formalna definicija projekta se bazira na verovatnoi da e IS odeljenje biti u stanju da razvije sistem koji e razreiti problem i odredi da li cena sistema koji treba razviti prevazilazi koristi koje se od njega mogu oekivati.

Druga faza analiza

Za vreme ove faze, analitiari prouavaju postojee procedure i informacioni sistem koji se koriste da bi se izvravali definisani zadaci u organizaciji. U okviru faze analize se deava fie aktivnosti to je prikazano na slici 3.

Slika 3. Faza analize To su: 1. Odreivanje zahteva sistema: U ovoj aktivnosti analitiari rade sa korisnicima na odreivanju onoga to korisnici oekuju od predloenog sistema. Procesom odreivanja zahteva je obino obuhvaena paljiva studija svih postojeih sistema, runih ili automatizovanih, koji mogu biti zamenjeni ili unapreeni kao deo projekta. Zahtevi sistema se grafiki prikazuju modelom procesa (primer grafikog prikaza modela procesa prikazan je na slici 4.)

Naziv predavanja: METODOLOGIJE ZA RAZVOJ INFORMACIONIH SISTEMA

5/20

IS201 UVOD U INFORMACIONE SISTEME

Predavanje br. 9

Slika 4. Primer grafikog prikaza modela procesa korienjem dijagrama toka podataka

2. Struktuiranje zahteva sistema: U ovoj fazi analitiari studiraju zahteve i struktuiraju ih (u zavisnosti od njihovih meusobnih veza) eliminiui bilu kakvu redudansu. Izlaz iz faze analize je opis alternativnih reenja koja predlae tim analitiara. Kada rukovodstvo prihvati jedan predlog, analitiari mogu da ponu pravljenje plana za kupovinu hardvera i sistemskog softvera neophodnog za izgradnju i rad predloenog sistema. Struktuiranjem zahteva sistema je obuhvaeno modeliranje podataka i modeliranje logike procesa za ije se prikazivanje takoe koriste odgovarajue tehnike.

Trea faza dizajn

U fazi dizajna analitiari konvertuju opise preporuenih alternativnih solucija u logike, a zatim i fizike specifikacije sistema. Analitiari dizajniraju razliite aspekte sistema od ulaznih do izlaznih formi i izvetaja, baze podataka i procesa obrade. Zatim, u vidu modela ili detaljne dokumentacije kreiraju fizike specifikacije sistema kojima se usmeravaju oni koji rade na izgradnji novog sistema to je prikazano na slici 5.

Deo procesa dizajna koji je nezavisan od bilo koje softverske ili hardverske platforme se naziva logiki dizajn. Teorijski, sistem moe biti implementiran na bilo kojem hardveru i sistemskom softveru. Logiki dizajn se odnosi na poslovni aspekt sistema i orijentisan je na specifikacije visokog nivoa.

Naziv predavanja: METODOLOGIJE ZA RAZVOJ INFORMACIONIH SISTEMA

6/20

IS201 UVOD U INFORMACIONE SISTEME

Predavanje br. 9

Slika 5. Faza dizajna

U procesu koji se naziva fiziki dizajn, analitiari logike specifikacije prevode u fizike. Kao deo fizikog dizajna, analitiari dizajniraju razliite delove sistema koji izvravaju fizike operacije neophodne da olakaju prikupljanje podataka, obradu i generisanje izlaza. To moe biti uinjeno na nekoliko naina, npr.: kreiranjem radnog modela sistema koji e se implementirati ili pisanjem detaljnih specifikacija kojima se opisuju razliiti delovi sistema i nain na koji ih treba izgraditi.

Deo procesa dizajna koji je nezavisan od bilo koje softverske ili hardverske platforme se naziva logiki dizajn. Teorijski, sistem moe biti implementiran na bilo kojem hardveru i sistemskom softveru. Logiki dizajn se odnosi na poslovni aspekt sistema i orijentisan je na specifikacije visokog nivoa. U procesu koji se naziva fiziki dizajn, analitiari logike specifikacije prevode u fizike. Kao deo fizikog dizajna, analitiari dizajniraju razliite delove sistema koji izvravaju fizike operacije neophodne da olakaju prikupljanje podataka, obradu i generisanje izlaza. To moe biti uinjeno na nekoliko naina, npr.: kreiranjem radnog modela sistema koji e se implementirati ili pisanjem detaljnih specifikacija kojima se opisuju razliiti delovi sistema i nain na koji ih treba izgraditi.

Za vreme fizikog dizajna, tim analitiara mora da definie mnoge fizike detalje neophodne za izgradnju finalnog sistema, od programskog jezika u kojem e sistem biti pisan, do sistema baze podataka u kojem e se uvati podaci i hardverske platforme na kojoj e se sistem izvravati. esto izbor jezika, baze podataka i platforme odreuje organizacija ili klijent, pa prilikom fizikog dizajna te informacione tehnologije moraju biti uzete u obzir. Finalni proizvod fizikog dizajna je specifikacija fizikog sistema u formi koja je speremna za programere i druge ljude koji uestvuju u izgradnji sistema.

etvrta faza implementacija

U prvom delu faze implementacije se programerima, u formi detljanog modela ili detaljno pisanih specifikacija, daje specifikacija fizikog sistema. U toku implementacije se iz sistemskih specifikacija dobija radni sistem koji se testira, a zatim puta u operativni rad. Implementacija ukljuuje: kodiranje, testiranje i

Naziv predavanja: METODOLOGIJE ZA RAZVOJ INFORMACIONIH SISTEMA

7/20

IS201 UVOD U INFORMACIONE SISTEME

Predavanje br. 9

instalaciju.

Za vreme kodiranja, programeri piu programe koji sainjavaju sistem. Ponekad se kod generie istim sistemom koji je korien za dobijanje detaljnog modela sistema. U toku testiranja, programeri i analitiari testiraju individualne programe i itav sistem da bi pronali i korigovali greke. U toku instaliranja, ovi sistem postaje deo dnevnih aktivnosti organizacije. Aplikativni softver se instalira na postojeoj ili novoj platformi i korisnici se obuavaju za korienje sistema. Implementacione aktivnosti; takoe ukljuuju inicijalnu podrku korisnicima kao to je finalizacija dokumentacije, programi obuke i pomo korisnicima. Naglasiemo da se dokumentacija i programi obuke za vreme implementacije ne zavravaju; dokumentacija se proizvodi za vreme itavog ivotnog ciklusa razvoja projekta. Aktivnosti koje se deavaju u fazi implementacije su prikazane na slici 6.

Slika 6. Faza implementacije

Peta faza odravanje

Kada sistem radi u nekoj organizaciji, korisnici esto pronalaze probleme vezane za njegov rad i razmiljaju o boljim nainima izvravanja njihovih funkcija. Takoe, tokom vremena se menjaju potrebe organizacije. U fazi odravanja, programeri prave izmene koje trae korisnici da bi modifikovali sistem i podrali promenjene uslove poslovanja. Te promene su neophodne da bi sistem ostao u upotrebi i da bi se koristio. U nekom smislu, odravanje nije posebna faza, ve je to ponavljanje drugih faza ivotnog ciklusa potrebnih da se potrebne promene proue i implementiraju. Koliina vremena i snage koju je potrebno uloiti u odravanje, velikim delom zavisi od performansi prethodnih faza ivotnog ciklusa. Kada jedan informacioni sistem ne radi vie onako kako elimo, vreme je da se pone sa dizajniranjem zamene sistema, ime se petlja SDLC zavrava i inicira nov SDLC. Aktivnosti faze odravanja su prikazane na slici 7.

Naziv predavanja: METODOLOGIJE ZA RAZVOJ INFORMACIONIH SISTEMA

8/20

IS201 UVOD U INFORMACIONE SISTEME

Predavanje br. 9

Slika 7. Faza odravanja

Varijacije ivotnog ciklusa razvoja informacionih sistema

Mada skoro svi projekti za razvoj sistema podravaju neki tip ivotnog ciklusa, tana lokacija aktivnosti i specifina sekvenca koraka mogu da variraju od projekta do projekta. Razliite kombinacije aktivnosti su opisane kroz sledee metode: Tradicionalni SDLC tipa vodopada; Brzi razvoj aplikacija (Rapid Application Development RAD); Izrada prototipa; Joint Application Design JAD.

Tradicionalni SDLC tipa vodopada

ivotni ciklus vodopada je prikazan na slici 8. i karakterie se sledeim osobinama: Sledea faza zapoinje po zavretku prethodne faze, tj. po proveri njene kontrolne take. Nakon iniciranja nove faze, teko je vratiti se unazad.

Bez obzira to se za vreme procesa razvoja i analize uslovi poslovanja menjaju i to korisnici esto ubede analitiare da je promena dizajna neminovna kako bi bili podrani promenjeni uslovi, dizajn se zamrzava u zateenom stanju i prelazi se na sledeu fazu. Polazei od injenice da je za implementaciju specificiranog dizajna neophodna ogromna koliina napora i vremena, proizilazi da je pravljenje izmena u sistemu koji je jedanput razvijen, veoma skupo.

Slika 8. ivotni ciklus vodopada Nedostaci tradicionalnog ivotnog ciklusa vodopada su: Zahtevi ostaju na nivou koji je prvobitno definisan, mada se oni mogu u meuvremenu promeniti.

Naziv predavanja: METODOLOGIJE ZA RAZVOJ INFORMACIONIH SISTEMA

9/20

IS201 UVOD U INFORMACIONE SISTEME

Predavanje br. 9

Zahtevi se zakljuavaju suvie rano (u odreivanju zahteva ili analizi) bez obzira to se uslovi poslovanja menjaju. Uloga korisnika je usko definisana. Nakon zavretka jedne faze, nemogu je ponovni povratak na prethodnu fazu, pa se analiza i dizajn ne mogu korektno odraditi. Dobija se sistem koji ne podrava potrebe kupaca i zahteva ekstenzivno odravanje to znaajno poveava trokove razvoja.

Nalaenje i fiksiranje problema nakon isporuke sistema je 100 puta skuplje od pronalaenja problema za vreme analize i dizajna. Prema nekim tvrdnjama, trokovi odravanja iznose 40-70% cene razvoja sistema, pa imajui u vidu ove probleme, ljudi zadueni za razvoj sistema su poeli da pronalaze bolje naine za voenje analize i dizajna.

Prototajping
U prototajpingu, analitiar radi sa korisnicima kako bi odredio inicijalne ili osnovne zahteve sistema, na bazi kojih brzo izgrauje prototip. Kada je prototip zavren, korisnici ga testiraju, i kao povratnu spegu iznose analitiaru ta im se u uraenom prototipu svia, a ta ne. Analitiar koristi tu povratnu spregu da bi poboljao prethodni prototip i dobio novu verziju koju opet vraa korisnicima. Taj iterativni proces se nastavlja sve dok korisnici ne budu zadovoljni onim to su videli. Dve kljune prednosti tehnike prototipa su: visoki stepen kojim su u procesu analize i dizajna korisnici obuhvaeni prototipom i mogunost da se zahtevi prikupe u konkretnoj, a ne apstraktnoj formi.

Pored toga to se moe koristiti kao samostalni proces, prototaping se moe koristiti i u okviru SDLCa. Npr., veoma rano, u fazi analize se moe razviti prototajp finalnog sistema, kako bi se njime identifikovalo ta korisnici ele. Pored prototipa, kao nain za poboljanje procesa razvoja sistema se moe koristiti computer-aided softwer engeneering - CASE alata. CASE alati su prvobitno bili razvijeni za interno korienje, ali kasnije, nekoliko velikih firmi kao to su Oracle (Designer) i IBM (Rational Rose) su ih i prodavale. CASE alati se baziraju na centralnom repozitorijumu podataka koji sadri opis sistema i specifikacije ukljuujui i informacije o imenima podataka, formatima, korisnicima i lokacijama. CASE alati, takoe ukljuuju alate za crtanje dijagrama, alate za dizaniranje ekrana i izvetaja i druge alate specijalne namene. CASE alati pomau programerima i analitiarima da svoj posao rade efikasnije i efektnije automatizujui rutinske poslove.

Joint Application Design (JAD)

U kasnim 1970-im godinama, IBM je razvio novi proces za sakupljanje informacionih zahteva sistema koji je nazvan Joint Application Design (JAD). JAD je struktuirani proces u kojem korisnici, menaderi i analitiari rade zajedno nekoliko dana kroz seriju intenzivnih sastanaka kako bi specificirali ili pregledali zahteve sistema. Izgled prostorije u kojoj se odravaju JAD sesije je prikazan na slici 9.

Naziv predavanja: METODOLOGIJE ZA RAZVOJ INFORMACIONIH SISTEMA

10/20

IS201 UVOD U INFORMACIONE SISTEME

Predavanje br. 9

Slika 9. Prostorija za odravanje JAD sesija

Brzi razvoj aplikacija (Rapid Application Development RAD)

RAD je pristup razvoja informacionog sistema kojim se dobija bolji i jeftiniji sistem tako to ljudi, koji ga razvijaju zajedno sa krajnjim korisnicima, rade na razvoju sistema u realnom vremenu. RAD je nastao zbog: breg i turbulentnijeg obavljanja posla u kasnim 1980. i ranim 1990. godinama; raspoloivosti snanih, na raunaru baziranih alata, koji podravaju razvoj sistema i lako odravanje.

RAD postaje sve legitimniji nain za za razvoj sistema. Danas se akcenat stavlja na brzi razvoj Web baziranih sistema. IBM je npr. razvio skup alata koji omoguavaju brz, lak razvoj e-business aplikacija. Ti alati ukljuuju VisualAge Generator, VisualAge za Java-u, WebSphere Studio i WebSphere Application Server.

Kao to se vidi sa slike 10. u RAD-u su prisutne iste faze projektovanja koje postoje i u tradicionalnom SDLC-u, ali su faze skraene i meusobno kombinovane. Faza planiranja i dizajna je npr. skraena tako to je naglasak stavljen na funkcije sistema i zahteve koji se odnose na korisniki interfejs.

Slika 9. Faze projektovanja u RAD-u U RAD-u se esto sistem koji se razvija posmatra izolovano od drugih sistema, ime su eliminisane aktivnosti koje vremenski dugo traju, a odnose se na usklaivanje postojeih sistema sa sistemom koji se razvija. U RAD-u je:

Naziv predavanja: METODOLOGIJE ZA RAZVOJ INFORMACIONIH SISTEMA

11/20

IS201 UVOD U INFORMACIONE SISTEME

Predavanje br. 9

Generalno manje naglaena sekvenca i struktura procesa ivotnog ciklusa; Vie zadataka se izvrava paralelno; Ekstenzivno se koristi prototyping; Iteracija mogua samo izmeu dizajna i razvojne faze; Korisnici su obuhvaeni u velikoj meri od poetka razvojnog procesa (kada uestvuju u planiranju aplikacije), kroz definisanje zahteva (kada zajedno sa analitiarima rade na izradi prototipa), do dizajna i implementacije (kada sa ljudima angaovanim na razvoju sistema, rade na validiranju finalnih elemenata sistemskog dizajna).

Objektno orijentisan pristup razvoja

Sa sigurnou se moe rei da objekno-orijentisan pristup razvoja danas postaje sve popularniji. Posle pristupa koji su najpre bili orijentisani ka procesima, a zatim ka podacima, OOAD se esto naziva treim pristupom razvoja sistema. U OO pristupu se procesi i podaci kombinuju u jedinstvene entitete koji se nazivaju objektima. Objekat opisuje pojedinane predmete ili entitete, stvarne ili apstraktne, koji se mogu identifikovati u domenu problema koji se reava aplikacijom. Objekti se karakteriu ne samo svojim osobinama koje se iskazuju preko atributa objekata, ve i svojim ponaanjem. Ponaanje objekta se definie skupom operacija koje se izvravaju nad njim, pri emu taj skup operacija menja stanje objekta. Usko sa pojmom objekta je povezan pojam klase, mada izmeu njih postoji jasna razlika. Klasa predstavlja skup objekata koji imaju iste atribute i operacije, istu semantiku i zajednike veze sa drugim objektima. U tom smislu, objekat se moe posmatrati kao jedno pojavljivanje posmatrane klase. Klase u nekom sistemu ne postoje izolovano, ve meu njima postoji neka interakcija. Veza izmeu klasa moe da oznaava: neku vrstu veza kojom se omoguava da povezane klase dele zajednike osobine, kao to su nasleivanje i agregacija ili neku semantiku vezu kao to je asocijacija.

UML (Unified Modeling Languange)

Za predstavljanje rezultata primene objektno orijentisanog pristupa na projektovanje neke aplikacije se koristi UML (Unified Modeling Languange). UML je vizualni, grafiki jezik koji predstavlja skup konvencija za opisivanje modela aplikacije dobijenog primenom neke objektno orijetisane metode. U UML-u se mogu izdvojiti etiri grupa dijagrama koji omoguavaju prikaz razliitih pogleda na dobijeni model aplikacije: Dijagrami za prikazivanje Use case modela kojima su obuhvaeni: o Use case dijagrami na kojima su prikazani Use case-ovi (sluajevi korienja), relacije koje se mogu uspostaviti izmeu njih (tipa extends, includes i generalizacija), interesenti (stakeholdera) i korisnici (actor-a) sistema, veze izmeu korisnika, kao i veze izmeu korisnika i Use case-ova. Use case-ovi predstavljaju tehniku za modeliranje funkcionalnosti i specifikaciju zahteva sistema. Njima se opisuje ponaanje sistema, odnosno njegove funkcije sa take gledita interesenata i korisnika. Svaki Use case se moe predstaviti kao skup sekvenci akcija koje se izvravaju u okviru sistema, a rezultat njihovog izvravanja su vrednosti znaajne za korisnika. Sekvekca akcija se uvek inicira porukom prosleenom od korisnika. o Use Case opisi predstavljaju formalizovani nain za opisivanje sekvence akcija (interakcije) izmeu korisnika i samog sistema, i to korienjem prirodnog jezika korisnika. Oni sadre tekstualni opise specifinog scenarija u kojem interesenti i korisnici snabdevaju sistem ulazima, a sistem na njih odgovara vidljivim izlazima. Use case opis moe da sadri vie od

Naziv predavanja: METODOLOGIJE ZA RAZVOJ INFORMACIONIH SISTEMA

12/20

IS201 UVOD U INFORMACIONE SISTEME

Predavanje br. 9

jednog scenarija, pri emu je jedan od njih glavni, dok su ostali alternativni. Detaljan opis Use Case-ova moe biti dat i dijagramom aktivnosti ili dijagramom sekvenci.

Kolekcija svih Use Case-ova, Acor-a, Stakeholder-a, Use Case dijagrama i Use case opisa ini Use Case model. Osnovni cilj Use case modela jeste opis funkcionalnih zahteva, odnosno osnovnih funkcija sistema sa take gledita korisnika, koji predstavlja osnovu za dalju analizu i dizajn sistema. Dijagrami za opisivanje statikog modela sistema gde spadaju: o Dijagrami klasa, preko kojih se prikazuje statiki aspekt projektovanog sistema. Na dijagramima klasa se prikazuju klase, njihove strukture i meusobne veze koje mogu biti tipa asocijacije, nasleivanja, agregacije i zavisnosti. Osim klasa, mogu biti predstavljeni i drugi elementi modela kao to su interfejsi i paketi moduli koji se dobijaju dekompozicijom sistema u cilju savladavanja njegove sloenosti. Dijagrami klasa se mogu raditi u nekoliko nivoa. o Dijagrami objekata slue za prikazivanje objekata posmatranih klasa i njihovih meusobnih veza. Mogu se pojaviti u dva oblika, kao statiki i dinamiki. Statiki dijagram objekata predstavlja jednu pojavu dijagrama klasa i saglasan je sa njim. Dinamiki dijagram objekata pored objekata i njihovih veza kojima se opisuje stanje sistema, prikazuju i promene koje se deavaju u nekom intervalu vremena, kao i poruke koje objekti meusobno razmenjuju. Dinamiki dijagrami objekata su zapravo dijagrami stanja.

Dijagrami za opisivanje dinamikog modela sistema kojima se opisuju pojedinana ponaanja objekata u sistemu, kao i ponaanje itavog sistema koji se modelira. Za opis dinamikih karakteristika se koriste koncepti kao to su: objekti, veze meu objektima, poruke koje objekti meusobno prosleuju, kao i operacije koje se izvravaju kao odgovor na primljene poruke, stanja u kojima se objekti mogu nai, odnosno promene tih stanja kao odgovor na primljene poruke. Njima su obuhvaeni: o Dijagrami sekvenci kojima se opisuje nain na koji objekti u sistemu meusobno komuniciraju ostvarujui na taj nain oekivano ponaanje. Na njima se prikazuje sekvenca poruke koje se prosleuju izmeu objekata u cilju izvrenja odreene operacije. Sekvencijalni dijagram se mogu raditi tako da svaki odgovara jednom scenariju iz Use Case-a. Kako se njima prikazuju interakcije meu objektima, pre njihove izrade neophodno je za datu aplikaciju identifikovati osnovni skup klasa, odnosno njihovih objekata. o Kolaboracioni dijagrami kojima se prikazuje komunikacija izmeu objekata kao i njihove veze neophodne za ostvarivanje te komunikacije, ali bez naglaska na vremensku komponentu. Neki Case alati (npr. Rational Rose) omoguavaju automasku konverziju sekvencijalnih dijagrama u kolaboracione, i obrnuto. Dijagrami stanja kojima se opisuju stanja objekta posmatrane klase u kojima se oni mogu nai, njihovo ponaanje u tim stanjima kao dogaaje koji uslovljavaju prelazak iz jednog u drugo stanje. Dijagrami aktivnosti su specijalni tip dijagrama stanja i slue za prikazivanje toka aktivnosti (workflow) koje se izvravaju u okviru jedne operacije. Ovi dijagrami, koji ne koriste direktno objekte i klase sadrane u modelu koji se radi tokom analize, imaju za cilj da iskau dimamiko ponaanje sistema na viem nivou od onog prikazanog sekvencijalnim i kolaboracionim dijagramima. Osim toga, dijagrami aktivnosti se mogu koristiti za modeliranje aktivnosti neke specifine operacije, i u tom sluaju oni imaju ulogu flowchart-a.

Dijagrami za opis fizikog modela odnosno implementacije sistema gde spadaju: o Dijagrami paketa koji se koriste da se pokae logika podela klasa na module, predstavljene paketima, kao i veze koje postoje meu paketima.

Naziv predavanja: METODOLOGIJE ZA RAZVOJ INFORMACIONIH SISTEMA

13/20

IS201 UVOD U INFORMACIONE SISTEME

Predavanje br. 9

Dijagrami komponenti kojima se se prikazuje fiziki razmetaj klasa pri realizaciji, za razliku od dijagrama paketa gde je prikazana njihova logika podela. Uobiajeno je da su dijagrami paketa i dijagrami komponenti u relaciji 1:1. Dijagrami razmetanja koji slue da se opie fizika arhitektura aplikacije, tako da vorovi u dijagramima, obino predstavljaju hardversku platformu

Izmeu razliitih vrsta UML dijagrama se mogu uspostaviti veze. Najee, projektovanje sistema zapoinje od specifikacije zahteva poslovnog sistema (Business Process Requirements BPR) koji se izraavaju preko Use case-ova. Nakon kreiranja Use case-ova kojima se specificira ta gotov sistem treba da radi, sugeriu su UML dijagrami koje treba koristiti u fazi analize, dizajna i razvoja aplikacije. Mnogi projektanti kreiraju najmanje jedan Use case dijagram i nekoliko sekvencijalnih i klasnih dijagrama koji predstavljaju sutinu faze analize i dizajna, dok se drugi dijagrami ree koriste. Svaka vrsta dijagrama UML-a ima specifinu namenu i koristi se u zavisnosti od tipa aplikacije koja se razvija. Meutim, UML-om se ne utvruje obavaza da se moraju primeniti svi ili samo neki od navedenih dijagrama, kao ni redosled u kojem se specifini dijagrami rade. Tako se pri razvoju velikih aplikacija moe generisati na stotine razliitih UML dijagrama, dok je male sisteme mogue opisati samo sa nekoliko klasnih i sekvencijalnih dijagrama.

RUP (Rational Unifed Process)

RUP je metodoloki pristup koji slui da se projektantskom timu koji uestvuje u razvoju softvera, u vidu preporuka daju smernice kada, i koje UML dijagrame treba da koriste. Korienjem ovakvog disciplinovanog pristupa u dodeljivanju zadataka i odgovornosti lanovima tima, moe se dobiti softver viskog kvaliteta, koji u okviru predvienog budeta i plana zadovoljava potrebe interesenata i korisnika. Aktivnosti RUP-a nisu fokusirane na proizvodnju velike koliine papiroloke dokumentacije, ve na razvoj i odravanje modela, semantiki bogate prezentacije softverskog sistema koji se razvija. Kreiranje i odravanje razliitih modela je podrano CASE alatima kojima se automatizuje veliki deo procesa. RUP-om je obuhvaeno nekoliko od najboljih iskustava (best practice) do kojih se dolo u modernom razvoju softvera, tako da je pogodan za irok opseg projekata i organizacija. RUP-om je podran iterativni postupak projektovanja koji je prikazan na slici 11.

Slika 11. Iterativni postupak projektovanja podran RUP-om

Naziv predavanja: METODOLOGIJE ZA RAZVOJ INFORMACIONIH SISTEMA

14/20

IS201 UVOD U INFORMACIONE SISTEME

Predavanje br. 9

On omoguava da se rizik itavog projekta znaajno umanji estim izbacivanjem izvrnih verzija softvera koje testiraju krajnji korisnici, tako da se rezultati testiranja kao povratne veze ukljuuju u sledeu verziju softvera. Poto se svaka iteracija zavrava izvrnom verzijom, razvojni tim je stalno usredsreen na dobijanje rezultata i este provere statusa, to pomae da se projekat odvija po utvrenom planu. Iterativni pristup takoe omoguava lake prilagoavanje taktikim izmenama zahteva ili plana RUP se moe opisati kroz dve dimenzije koje se prikazuju kroz dve ose koordinatnog sistema: a. horizontalnu osu koja predstavlja vreme i prikazuje dinamiki aspekt procesa izraen preko faza, iteracaija i kontrolnih taaka (milestone) b. vertikalnu osu koja predstavlja statiki aspekt procesa izraen preko aktivnosti, dokumentacije, uesnika (worker-a) i disciplina (workflow-a) to je prikazano na slici 12.

Slika 12. Dimenzije RUP-a

RUP-om se jedan razvojni ciklus deli na etiri faze: poetak (Inception), razrada (Elaboration), konstrukcija (Construction) i prelaz (Transition).

Svaka faza se zavrava kontrolnom takom (milestone) u kojoj se daje kritiki osvrt na rezultate zavrene faze u smislu postizanja njenog kljunog cilja. Svaka faza se moe odvijati kroz jednu ili vie iteracija, a svaka iteracija se izvrava kroz est osnovnih disciplina (workflow-a): poslovno modeliranje, specifikacija zahteva, analiza, dizajn, implementacija i testiranje

Naziv predavanja: METODOLOGIJE ZA RAZVOJ INFORMACIONIH SISTEMA

15/20

IS201 UVOD U INFORMACIONE SISTEME

Predavanje br. 9

koje su na slici 12. prikazane na vertikalnoj osi. Mada svaka iteracija moe da sadri svih pet disciplina, u zavisnosti od toga gde se data iteracija pojavljuje u ivotnom ciklusu projekta, naglasak se stavlja samo na jednu od njih (pretstavljeno krivom koja je oznaena kao koliina rada) .

Faze razvoja RUP-a

Poetak (Inception) ima za cilj utvrivanje poslovnih (business) Use case-ova sistema i definisanje njegovog domena. Ostvarivanje ovako postavljenog cilja je mogue identifikovanjem svih eksternih entiteta sa kojima je sistem u interakciji predstavljenih preko actor-a i stakeholder-a, svih Use caseova, kao i opis nekih najznaajnijih. U kontrolnoj taki (milestone) koja sledi po zavretku ove faze se proverava da li su isporukom odgovarajuih dokumenata i modela ispunjeni uslovi dati u tabeli 1.

Tabela 1. Uslovi koji moraju biti zadovoljeni nakon faze Poetak Uslov Stakeholder-i su se sloili sa ciljevima projekta Definisan je domen sistema sa kojim su se sloili Stakeholder-i Sa Stakeholder-ima dogovoreni trokovi i plan projekta Menader projekta identifikovao mogue rizike Potvrda izvodljivosti izradom tehnike studije i/ili prototipa Ispunjenje kroz dokument/model Vision dokument kojim su definisani osnovni zahtevi (requirements), karakteristike i ogranienja sistema Inicijalni Use case model (kompletiran 10-20 % ) Inicijalni plan projekta Dokumenat moguih rizika Jedan ili vie prototipa

Razrada (Elaboration) se radi u cilju da se analizira domen problema, razvije stabilan projektni plan, definiu zahtevi iz kojih su eleminisani svi rizici kako bi se mogli predvideti trokovi i plan zavretka itavog projekta i utvrditi fizika arhitektura sistema koja e se koristiti za njegovu implementaciju. Da bi se ispunili ovi zahtevi, potrebno je imati potpunu sliku sistema: podruje koje pokriva, specifikaciju njegove osnovne funkcionalnosti i definisane nefunkcionalne zahteve. Glavni kriterijumi za zavretak faze su odgovori na pitanja: da li je vizija softverskoh proizvoda i njegova arhitektura dovoljno stabilna (vrsta) i da li su razreeni najriziniji elementi. Uslovi koji moraju biti ispunjeni po zavretku ove faze su dati u tabeli 2. Tabela 2. Uslovi koji moraju biti zadovoljeni nakon faze Razrada Uslov Kreiranje grube, izvrne arhitekture kojom se pokazuje da su znaajni rizici identifikovani i razreeni Ispunjenje kroz dokument/model Gruba arhitektura sistema UML statiki model UML dinamiki model UML Use case model Kreiranje stabilne vizije proizvoda Razreavanje problema koji dovode do pojave rizika Kreiranje plana projekta sa dovoljno detalja da se mogu predvideti vreme, Vision dokument Aurirani dokument rizika Aurirani plan projekta

Naziv predavanja: METODOLOGIJE ZA RAZVOJ INFORMACIONIH SISTEMA

16/20

IS201 UVOD U INFORMACIONE SISTEME

Predavanje br. 9

novac i resursi za sledeu fazu. Stakeholder-i se saglaavaju sa planom projekta Postizanje dogovora sa stakeholder-ima o nastavku projekta Potpisivanje dokumenta

Konstrukcija (Construction) ima za cilj izradu softverskog proizvoda koji je spreman za transfer do korisnika. U njoj se naglasak stavlja na upravljanje resursima i kontrolisanje operacija kako bi se optimizovali trokovi, plan i kvalitet projekta. U tom smislu, ona predstavlja prelaz sa razvoja intelektualnih svojstava identifikovanih u fazi poetka i razrade, na razvoj proizvoda koji se moe staviti u ruke krajnjeg korisnika. Kako faza konstrukcije predstavlja razvoj izvrne arhitekture generisane u fazi razvoja u kompletan finalni sistem, u ovoj fazi se naglasak stavlja na discipline analize, dizajna i implementacije. U fazi konstrukcije se zavrava model analize i model dizajna i zapoinje implementacija i testiranje. Kotrolna taka nakon faze konstrukcije je veoma jednostavna softverski sistem je zavren i spreman za beta testiranje na site -u korisnika. Uslovi koje treba zadovoljiti su dati u tabeli 3. Tabela 3. Uslovi koji moraju biti zadovoljeni nakon faze Konstrukcija Uslov Softverski proizvod je dovoljno stabilan i kvalitetan da se instalira na site korisnika. Ispunjenje kroz dokument/model Softverski proizvod UML model Test Stakeholder-i su se sloili i spremni su za prenos softvera u njihovo okruenje. Korisniko uputstvo Opis datog release-a

Prelaz (Transition) : Fokusiran je na aktivnosti neophodne da se softverski proizvod preda korisnicima. Ova faza ukljuuje: beta testiranje kako bi se nov sistem validirao prema oekivanjima korisnika, paralelni rad sa postojeim sistemom koji se menja, konverziju operativne baze podataka, obuku korisnika i odravanje. Na kraju ove faze treba dati odgovore na pitanja: da li su korisnici zadovoljni i da li je stvarni utroak resursa prema planiranoj potronji jo uvek prihvatljiv. Uslove koje teba zadovoljiti dati su tabeli 4. Tabela 4. Uslovi koji moraju biti zadovoljeni nakon faze Prelaz Uslov Beta testiranje je zavreno; napravljene su neophodne izmene, korisnik se slae da je sistem uspeno implementiran. Korisnici proizvod. aktivno koriste softverski Plan podrke korisnika Korisniko uputstvo Ispunjenje kroz dokument/model Softverski proizvod

Strategije za podrku softverskog proizvoda su dogovorene sa korisnicima i implementirane.

U poreenju sa tradicionalnim procesom vodopada, prednosti ovakvog naina razvoja softvera koji pre svega podrazumeva iterativni pristup su: ranije otkrivanje rizika, bolje upravljanje promenama, vei nivo rejuzibilnosti, bolji ukupan kvalitet.

Naziv predavanja: METODOLOGIJE ZA RAZVOJ INFORMACIONIH SISTEMA

17/20

IS201 UVOD U INFORMACIONE SISTEME

Predavanje br. 9

Discipline RUP-a
Discipline RUP-a kojima se opisuje statika struktura procesa su prikazane na slici 13.

Silka 6. Discipline RUP-a

Poslovno modeliranje ( Business modeling ): Jedan od najveih problema pri razvoju softverskog proizvoda jeste to ljudi, koji su zadueni za inenjering softvera i oni koji poznaju poslovni sistem, ne mogu da uspostave odgovarajuu komunikaciju. To dovodi do toga da se izlaz iz inenjeringa poslovnog sistema ne moe koristiti kao ulaz u razvoj softvera i obrnuto. RUP ovaj problem reava ustanovljavanjem zajednikog jezika i procesa koji se mogu koristiti u oba sluaja, a odnosi se prvenstveno na korienje Use case-ova odnosno Use case modela. Modeliranjem poslovnog sistema su obuhvaene aktivnosti: identifikacija poslovnih procesa, preiavanje definicija poslovnih procesa i dizajniranje realizacije poslovnih procesa, pa se kao izlazi iz ove discipline dobijaju: Poslovni Use case model (Business Use case model) kojim se opisuju poslovni procesi i njihova interakcija sa eksternim uesnicima, kao to su kupci i poslovni partneri. Koristi se kao ulaz u discplinu definisanja zahteva (Requirements) za izradu Use case modela. Model poslovnih objekata (Business Object Model) kojim se opisuje realizacija identifikovanih poslovnih Use case-ova, a koristi se u analizi i dizajnu kao ulaz za identifikaciju klasa Design modela.

Modeliranje poslovnog sistema je opciona disciplina. Zahtevi (Requirements): Cilj ove discipline je da se opie ta softver treba da radi, da se definiu granice softverskog reenja, da se onima koji razvijaju softver omogui da te opise usklade sa korisnicima, da se obezbedi osnova za utvrivanje cene i vremena potrebnog za razvoj softvera. Da bi se to postiglo, otkriva se, organizuje i dokumentuje zahtevana funkcionalnost softvera i to identifikovanjem potreba iteresenata (stakeholder-a), korisnika (actor-a) ili drugih sistema koji su u interakciji sa softverskim sistemom, koja se iskazuje preko Use case-ova. Svaki Use case se detaljno opisuje kroz Use case opis kojim se prikazuje u kakvoj je interakciji softverski sistem sa korisnikom i ta on radi. Takoe se opisuju i nefunkcionalni zahtevi koji se mogu odnositi na upotrebljivost, pouzdanost, performanse i podrivost softverskog reenja.

Sa aspekta objektno orijetisane analize i dizajna su posebno vane aktivnsti: pronalaenje actor-a i Use case-ova, detaljna analiza Use case-ova i struktuiranje Use case modela. Aktivnost koja se

Naziv predavanja: METODOLOGIJE ZA RAZVOJ INFORMACIONIH SISTEMA

18/20

IS201 UVOD U INFORMACIONE SISTEME

Predavanje br. 9

odnosi na postavljanje prioriteta meu identifikovanim Use case-ovima je zaduenje onoga ko definie arhitekturu softvera i radi plan projekta. Analiza i dizajn: Cilj ove discipline je pokazati kako e se sistem realizovati u fazi implementacije. Primarni ulaz za analizu i dizajn je Use case model dobijen kao izlaz iz specifikacije zahteva. Izrada modela analize nije obavezna aktivnost, ve se radi samo u sluaju razvoja velikih sistema, ako se proceni da je to korisno. Odvija se kroz sledee korake: Izrada dopunskih opisa Use Case-ova koji se rade da bi se dobila slika o tome ta se deava unutar sistema kako bi se generisao odgovor na poruke actor-a. Identifikovanje analisys klasa preko kojih se izvrava tok dogaaja iz Use Case-ova, najee korienjem tri razliita pogleda na sistem: granica izmeu sistema i njegovih aktera (actor) (boundary klase), informacija koje sistem koristi za generisanje odgovora actor-u (entity klase) i kontrolne logike sistema (control klase). Distribucija ponaanja Use Case-ova na identifikovane analzsis klase korienjem dijagrama Use Case realizacije (Use Case Realization). Use Case realizacija je organizovan model koji se koristi da bi se grupisali dokumenti koji se odnose na dizajn Use Case-a, kao to su dijagrami klasa i sekvencijalni dijagrami. Definisanje atributa za svaku izdvojenu analysis klasu i uspostavljanje asocijacija izmeu klasa.

Za razliku od modela analize kod kojeg se naglasak stavlja na domen problema (poslovne zahteve), u modelu dizajna (design model) se naglasak stavlja na domen reenja (detaljno razmatranje dizajna). Dizajn model slui kao apstrakcija izvornog koda, odnosno prikazuje kako je izvorni kod struktuiran i napisan. On se sastoji od dizajn klasa koje su struktuirane u dizajn pakete (package) i podsisteme sa dobro definisanim interfejsima, a sadri i opise kojima se predstavlja nain na koji objekti tih klasa meusobno kolaboriraju pri izvravanju Use case-ova. Model dizajna se dobija izdvajanjem odgovarajuih elemenata dizajna iz elemenata dobijenih pri izradi modela analize. Analysis klase mogu evaluirati u razliite vrste design elemenata i to: design klase sa fino definisanim svojstvima i ponaanjem (atributima i operacijama); podsisteme (subsystem) koji predstavljaju skup grubo definisanih odgovornosti i mogu se sastojati od skupa drugih podsistema ili ultimativno skupa klasa; aktivne klase kojima se predstavljaju kontrole unutar sistema; interfejse.

Dizajniranje baze podataka podrazumeva izdvajanje perzistentnih klasa podataka iz modela dizajna, dizajniranje odgovarajue strukture baze podataka, kako bi se te perzistentne klase pamtile i definisanje mehanizma i strategija za njihovo pamenje i pretraivanje, kako bi se zadovoljili kriterijumi postavljeni u pogledu performansi. Najvei deo aktivnosti vezan za izradu analysis modela poinje na kraju faze poetak i najveim delom se preklapa sa specifikacijom zahteva. Disciplina dizajna je primarna aktivnost u poslednjem delu faze poetak i u prvoj polovini faze konstrukcija. Implementacija: Svrha implementacije je da se: definie organizacija koda u obliku informacionih podsistema organizovanih u slojeve (layere); da se objekti i klase implemetiraju kao komponente (izvorni, binarni ili izvrni file-ovi); da se razvijene komponente testiraju kao celina;

Naziv predavanja: METODOLOGIJE ZA RAZVOJ INFORMACIONIH SISTEMA

19/20

IS201 UVOD U INFORMACIONE SISTEME

Predavanje br. 9

da se rezultati nastali individualnim implementacijama integiu u jedan izvrni sistem.

Komponente se struktuiraju u informacione podsisteme koji u file sistemu mogu imati formu direktorijuma ili foldera, u C++ ili Adi podsistema, a u Javi se pojaviti kao paketi (package). Ova disciplina je u vezi sa disciplinama: Specifikacija zahteva kojom se preko Use Case modela opisuju zahtevi koje treba ispuniti u implementaciji; Analiza i dizajn kojom se opisuje model dizajna koji predstavlja primarni ulaz za disciplinu implementacija; Test kojim se opisuje kako testirati dobijeni implementacioni model da bi se verifikovali svi zahtevi.

Testiranje: Svrha testiranja je da se verifikuje: iteracija izmeu objekata, integracija svih softverskih komponenti, korektna implementacija svih zahteva kao i da se identifikuju i odklone greke u softveru pre nego to se on isporui krajnjem korisniku.

RUP-om se predlae iterativni pristup, koji podrazumeva da se testiranje vri tokom razvoja celog projekta. To omoguava da se greke pronau to je mogue ranije, to radikalno smanjuje trokove korigovanja greaka. Kroz testiranje se proveravaju tri dimenzije kvaliteta: pouzdanost, funkcionalnost i performanse softvera. Razmetanje: Svrha ove discipline je uspena proizvodnja verzije aplikacije i isporuka softvera do njegovog krajnjeg korisnika. Ona ukljuuje iroki opseg aktivnosti kao to su: proizvodnja eksternih verzija softvera, pakovanje, distribuiranje i instalacija softvera, pruanje pomoi i asistencije korisnicima,

a u mnogim sluajevima ukljuuje i aktivnosti sprovoenja beta testiranja, migracije postojeeg softvera i podataka, i formalno prihvatanje. Mada su aktivnosti razmetanja uglavnom usmerene na fazu tranzicije, mnoge aktivnosti zahtevaju da budu ukljuene u ranijim fazama kako bi se priprema za razmetanje izvrila na kraju faze razvoja.

Naziv predavanja: METODOLOGIJE ZA RAZVOJ INFORMACIONIH SISTEMA

20/20