Materijali za pripremu usmenog ispita Predmet: Procesi razvoja softvera

Materijali za pripremu usmenog ispita Predmet: Procesi razvoja softvera

1. Uvod 1.1. Šta je UML? UML je jedna o najpoznatijih skraćenica u informatičkom svetu. Skraćenica potiče od englskog termina Unified Modeling Language, što u prevodu znači jedinstveni jezik za modelovanje. Najuopštenija definicija UML-a bi mogla biti sledeća. UML predstavlja jedinstveni jezik za vizuelizaciju, specifikaciju, konstrukciju i dokumentaciju softverskih sistema. Jezik za modelovanje može biti bilo koji opis koji pomaže izgradnji sistema. Taj opis, govoreći o softverskim proizvodima, može biti predstavljen pseudo kodom, dijagramima, slikama, tekstualnim opisima, itd. Elementi kojima se vrši modelovanje čine notaciju za modelovanje. Ukoliko se kao elementi koriste grafički simboli jezik za modelovanje je grafičkog tipa, tj. grafički jezik za modelovanje. UML poseduje grafičku notaciju, te se može kategorizovati kao grafički jezik za modelovanje. Grafički jezici poput UML-a koriste se već dugo u softverskoj industriji. Međutim ono što je specifično za sve te grafičke jezike, preteče UML-a, jeste njihova neusaglašenost. Upravo ta neusaglašenost je bila inicijalna kapsula koja je uticala na nastanak UML-a i koja pomaže da se razumeju kvaliteti koje je UML doneo svojim nastankom softverskoj industriji. UML je nastao kao posledica saradnje Grady Booch-a, Jamesa Rumbaugh-a i Ivar Jacobson-a. Svako od njih se bavio razvojem sopstvenih notacija, a njihovim ujedinjenjem, pod okriljem kompanije Rational Software, nastao je UML. Popularan naziv za trojicu idejnih tvoraca UML je tri amigosa. Danas kompanija Rational Software posluje kao deo IBM-a. UML danas predstavlja relativno otvoren standard, kontrolisan od strane Object Management Group (u nastavku OMG), nezavisnog konzorcijuma kompanija koji upravlja standardima u objektno orijentisanom razvoju. Najnovije specifikacije UML je moguće pronaći na sajtu OMG-a, www.omg.org. Istorijski posmatrano UML je nastao ujedinjenjem sledećih pristupa: Object-Oriented Analysis and Design (OOAD), čiji je tvorac Grady Booch, Object-Oriented Software Engineering (OOSE), čiji je tvorac Ivar Jacobson, Object Modeling Technique (OMT), čiji je tvorac James Rumbaugh, Probrane objektno orijentisane tehnike, dodatne tehnike koje su se inicijalno našle u UML-u. Inicijativa za stvaranje UML-a je krenula još 1996. godine, kao pokušaj da se prevaziđe rat objektnih notacija, te da se jedna notacija nametne kao standard. Kao kompanija za realizaciju ovoga projekata nametnula se Rational Software korporacija. To nije bilo jednostavno, te je za ovakav izbor bila potrebna saglasnost velikih softverskih giganata poput IBM-a ili Microsoft-a. Zajednički interes je doneo prevagu, te Rational Software korporacija ujedinjuje Boocha-a, Jacobson-a i Rumbaugh-a, te izbacuje UML kao jedinstveni jezik za modelovanje. U saradnji sa OMG-om UML se 1

1997. godine nameće kao standard, a njegov munjevit razvoj dokazuje opravdanost političkog delovanja na razvoju UML-a. Trenutno aktuelna verzija UML-a je 2.0. 1.2. Kratak pregled UML dijagrama Trenutno aktivna verzija UML-a jeste 2.0. U ovoj verziji postoji 13 vrsta dijagrama (predstavljeni tamnim pravougaonicima na slici br. 1.). U procesu razvoja razne uloge koriste različite tehnike dijagramiranja, za rešavanje različitih problema. To u stvari znači da različiti učesnici u procesu razvoja razgovaraju istim jezikom. Da ne bi došlo do zabune potrebno je napomenuti da se proces razvoja ne može obaviti samo sa UML-om. Međutim, standardizacijom i opšteprihvaćenošću UML-a stvoreni su preduslovi da sve aktivnosti koje se ne realizuju UML-om budu usaglašene sa aktivnostima koje se realizuju pomoću njega. U nastavku je dat kratak opis 13 vrsta UML dijagrama. UML dijagrami Dijagrami ponašanja Dijagrami strukture Dijagrami slučajeva upotrebe Dijagrami aktivnosti Dijagrami mašine stanja Dijagrami interakcije Dijagrami klasa Dijagrami objekata Dijagrami rasporeda Dijagrami sekvenci Dijagrami komunikacije Dijagrami pregleda interakcija Vremenski dijagrami Dijagrami složene strukture Dijagrami komponenti Dijagrami paketa Slika 1.1. Vrste UML dijagrama u verziji 2.0 1.2.1. Dijagrami slučajeva upotrebe Dijagrami slučajeva upotrebe služe da daju grub opis funkcionalnosti posmatranog sistema ili posmatranog dela organizacije. U principu se može konstatovati da postoje dve vrste ovih dijagrama: dijagrami slučajeva upotrebe (Use Case Diagrams) i dijagrami slučajeva upotrebe poslovnog procesa (Business Use Case Diagrams). Dijagrami slučajeva upotrebe treba da daju odgovor na pitanje Šta sistem radi?, dok dijagrami slučajeva upotrebe poslovnog procesa treba da daju odgovor na pitanje Šta organizacija radi?. Pomoću dijagrama slučajeva upotrebe predstavljaju se funkcionalnosti koje će biti automatizovane, a pomoću dijagrama slučajeva upotrebe poslovnog procesa i automatizovane i manuelne. Gradivni elementi ovih dijagrama su akteri, slučajevi upotrebe i relacije. Akter predstavlja nekoga ili nešto što se nalazi izvan sistema ili organizacije (u zavisnosti od vrste dijagrama), a u interakciji je sa njom. Slučajevi upotrebe i slučajevi upotrebe poslovnog procesa služe da bi se pomoću njih prikazale konkretne funkcionalnosti sistema, odnosno organizacije. 2

Ovi dijagrami predstavljaju vodilju za kompletan proces razvoja, pa se često za razvoj zasnovan na UML-u kaže da je usmeravan slučajevima upotrebe. 1.2.2. Dijagrami aktivnosti Dijagrami aktivnosti služe za opisivanje logike procedura, poslovnih postupaka i toka posla. Tok funkcionalnosti predstavljenih dijagramima slučajeva upotrebe se opisuje dijagramima aktivnosti, prikazujući sve aktivnosti koje se odvijaju u okviru posmatrane funkcionalnosti. Pomoću jednog dijagrama aktivnosti moguće je prikazati više potencijalnih scenarija koji se mogu desiti pri izvršavanju neke funkcionalnosti. Ukoliko se na dijagramima slučajeva upotrebe slučaj upotrebe posmatra kao crna kutija, na dijagramima aktivnosti se prikazuje redosled izvršavanja aktivnosti u okviru te crne kutije. 1.2.3. Dijagrami stanja mašine Ovi dijagrami služe za prikazivanje ponašanja dela sistema, odnosno ponašanje objekta kao instance posmatrane klase. Na njima se predstavljaju stanja posmatranog objekta, tranzicije između stanja i događaji koji uzrokuju tranzicije objekta iz jednog u drugo stanje. Crtanje dijagrama stanja mašine se ne preporučuje za sve klase sistema. Najčešće se crtaju za najznačajnije klase sistema ili se uopšte ne crtaju ukoliko razvojni tim informacije koje se dobijaju ovim dijagramima dobije na drugi način. 1.2.4. Dijagrami sekvenci i dijagrami komunikacije Ove dve vrste dijagrama prikazuju iste informacije iz različitih perspektiva. Pomoću njih se predstavljaju objekti koji se pojavljuju u okviru slučaja upotrebe i poruke koje oni razmenjuju. Razlika između ovih dijagrama je u tome što dijagrami sekvenci u prvi plan stavljaju vremensku dimenziju, tj. razmenu poruka sa aspekta vremena, dok dijagrami komunikacije zanemaruju vremensku dimenziju i prikazuju saradnju objekata kroz razmenu poruka. CASE alati pomoću kojih se crtaju ovi dijagrami omogućavaju automatsko generisanje jedne vrste dijagrama, na osnovu nacrtanog dijagrama druge vrste. 1.2.5. Dijagrami pregleda interakcija Ovi dijagrami su jedna od novina verzije 2.0. Predstavljaju kombinaciju dijagrama aktivnosti i dijagrama sekvenci. Mogu se posmatrati kao dijagrami aktivnosti u kojima su aktivnosti zamenjene sa dijagramima sekvenci. 1.2.6. Vremenski dijagrami Vremenski dijagrami su takođe novina u verziji 2.0. Iako se odavno koriste pri rešavanju elektrotehničkih problema, tek su u verziji 2.0 uvršteni u UML. Ova vrsta dijagrama je slična dijagramima stanja mašine, sa tom razlikom što se vreme pojavljuje kao inicijator promene stanja objekta. Pored mogućnosti praćenja promena stanja jednog objekata moguće je pratiti i porediti promenu stanja više objekata. Dakle, ovi dijagrami prikazuju stanja u koja objekti dolaze nakon unapred predefinisanog vremenskog intervala. 3

1.2.7. Dijagrami klasa Dijagrami klasa predstavljaju ključne dijagrame za opisivanje strukture sistema. Klasa predstavlja osnovni pojam u objektnom razvoju, te kao takva predstavlja i osnovnu komponentu objektno razvijanog sistema. Ovi dijagrami opisuju klase sistema i to kroz opis njima pripadajućih atributa, operacija i relacija između klasa. Atributi predstavljaju obeležja koja opisuju svojstva klase. Navode se u okviru klase, a svaki atribut može da poseduje sledeća svojstva: vidljivost, ime, tip, multiplicitet, podrazumevanu vrednost, kao i opis nekih dodatnih svojstava atributa (npr. čitljivost). Operacije opisuju poslove koje će objekat, kao konkretna pojava klase, znati da obavi. Kada se od objekta zahteva da obavi neki posao, to se može zahtevati samo preko operacije koju on poseduje. I operacije, kao i atributi poseduju odgovarajuća svojstva, i to: vidljivost, ime, listu parametara, tip rezultata operacije, itd. Relacije služe da bi se prikazao međusobni odnos klasa. Između klasa mogu da postoje sledeće vrste relacija: asocijacija, agregacija, zavisnost i generalizacija. 1.2.8. Dijagrami objekata Dijagrami objekata su postojali i u ranijim verzijama UML-a, ali kao neformalni dijagrami. Od verzije 2.0 postaju i zvanični UML dijagrami. Služe da prikažu objekte posmatranog dela sistema u posmatranom trenutku. Najsličniji su dijagramima saradnje, ali bez tretiranja poruka koje objekti razmenjuju. Koriste se da bi se dodatno opisala struktura sistema, u situacijama kada dijagrami klasa ne daju dovoljno kvalitetan opis iste. 1.2.9. Dijagrami komponenti Dijagrami komponenti služe da bi se prikazale komponente sistema. Pod komponentama se podrazumevaju takvi delovi sistema koji se mogu samostalno isporučivati krajnjim korisnicima. Naravno da sve ove komponente moraju biti tako međusobno usaglašene da dodavanje nove komponente u sistem ne izazove poremećaje kompletnog sistema. Uobičajeno svaka komponenta se sastoji od jedne ili više klasa i predstavlja nezavisnu celinu, koja je povezana sa ostatkom sistema pomoću interfejsa. Na ovakav način se postiže da promene u jednoj komponenti ne deluju destruktivno na ostatak sistema, jer interfejs i dalje čuva integritet komponente i ostatka sistema. 1.2.10. Dijagrami paketa Paketi predstavlju mehanizme za grupisanje UML elemenata. Iako se najčešće koriste za grupisanje klasa, mogu se koristiti i za grupisanje drugih elemenata, npr. za grupisanje slučajeva upotrebe, za grupisanje entiteta ili za grupisanje komponenti sistema. Predstavljaju se pomoću pravougaonika sa jezičkom u levom gornjem uglu, na kojem je ispisan naziv paketa. Između paketa se povlače relacije zavisnosti, koje govore da se neki od elemenata smeštenih u pakete između kojih postoji zavisnost nalaze u međusobnom odnosu. 4

Ukoliko govorimo o paketima klasa, tada bi do njihovog kreiranja moglo doći, npr. radi grupisanja hijerarhijske strukture klasa ili grupisanja klasa čije su instance u međusobnoj zavisnosti predstavljenoj na dijagramima sekvenci ili dijagramima saradnje. Moguće je takođe praviti pakete na osnovu stereotipova klasa. Dakle, ukoliko se klase nalaze u logičkoj ili fizičkoj povezanosti moguće ih je smestiti u paket klasa i predstaviti više takvih paketa na dijagramu paketa. Ovi su dijagrami, iako ranije nezvanično korišćeni, novina u UML verziji 2.0. 1.2.11. Dijagrami složene strukture Dijagrami složene strukture prikazuju saradnju klasa, interfejsa ili komponenti u cilju opisa strukture zadužene za izvršavanje posmatrane funkcionalnosti. Ovi dijagrami su slični dijagramima klasa. Razlika je u tome što dijagrami klasa prikazuju statičku strukturu sistema, kroz prikaz klasa sa njihovim atributima i operacijama, a dijagrami složene strukture prikazuju izvršnu arhitekturu, relacije između njenih gradivnih elemenata i odnos posmatrane arhitekture sa okruženjem, u cilju prikazivanja informacija koji se ne mogu prikazati pomoću statičkih dijagrama. Dijagrami složene strukture su takođe novina u verziji UML-a 2.0. 1.2.12. Dijagrami raspoređivanja Dijagrami raspoređivanja služe za predstavljaje hardverske arhitekture sistema. Oni prikazuju delove sistema raspoređene po fizičkim lokacijama. Ovi dijagrami se mogu posmatrati i kao prikaz arhitekturalnog rešenja celokupnog sistema. U nastavku su detaljno opisane probrane tehnike dijagramiranja pomoću UML dijagrama. 5

2. Od zahteva do slučajeva upotrebe Decenija za nama, donela je revoluciju u razvoju poslovnih procesa. Velika konkurencija pojačala je borbu za ograničenim profitom. Da bi kompanije uspele da ostvare svoj osnovni cilj, a to je opstanak, prinuđene su da stalno pronalaze nove načine za njegovo ispunjenje. Pored sadržajnih promena koje su poslovni procesi doživeli, došlo je i do razvoja velikog broja sasvim novih poslovnih procesa. Ovako buran poslovni razvoj zahteva adekvatnu informatičku podršku. To ilustruje konstantan porast broja novozapočetih IT projekta. Ispitivanja obavljena 2000. godine od strane Standish grupe, pokazuju da je u Sjedinjenim Američkim Državama u toku 1998. godine, započeto oko 200.000 softverskih razvojnih projekata. Dve godine kasnije taj broj se uvećao za 100.000, te je u toku 2000. godine započeto oko 300.000 softverskih projekata. Međutim, dalja ispitivanja Standish grupe prikazuju da manji procenat IT projekata završi uspešno, a veći neuspešno ili se ne završi. Upravo tako se u pomenutom ispitivanju i dele IT projekti, na usešne, propale i neuspešne. Pod neuspešnim projektima se podrazumevaju projekti koji su završeni, ali je prilikom njihove realizacije premašen budžet, produženo vreme izrade ili rezultat projekta ne poseduje zahtevane karakteristike, delimično ili u potpunosti. Naredni prikaz daje pregled započetih projekata u periodu između 1994. i 2000. godine. 28% 23% 49% 2000 U P N 1998 1996 26% 28% 46% U P N 27% 40% 33% U P N U - Uspešni projekti P - Propali projekti N - Neuspešni projekti 16% 31% 53% 1994 U P N 0% 20% 40% 60% 80% 100% Slika 2.1. Pregled uspešnosti projekata u periodu od 1994. do 2000. godine Tragajući dalje, dolazi se do spoznaje da je u 37% slučajeva, razlog za neuspeh projekata vezan za informacione zahteve. Nedostatak korisničkih zahteva predstavlja razlog neuspeha projekta u 13% slučajeva, nepotpuni zahtevi i specifikacije u 12% slučajeva, a promena zahteva i specifikacija, takođe u 12% slučajeva. Dodajući navedenim podacima činjenicu, da su troškovi otklanjanja grešaka nastalih u 6

oblasti zahteva izuzetno visoki, nameće se zaključak da se zahtevima ne posvećuje dovoljna pažnja, u procesu razvoja informacionih sistema. 2.1. Disciplina zahteva Osnovni cilj discipline zahteva jeste, da opiše šta sistem treba da radi. Taj opis treba da bude prihvaćen, kako od strane korisnika, tako i od strane razvojnih inžinjera. U svrhu postizanja navedenog cilja vrši se pronalaženje, organizovanje i dokumentovanje zahteva. Kao osnovni zadaci discipline zahteva mogu se proklamovati sledeći: Da se utvrdi i održi dogovor sa kupcima i ostalim stejkholderima o tome šta sistem treba da radi i zašto Da se jasno prikažu razvojnom timu zahtevi sistema Da se definišu granice sistema Da se stvori osnova za planiranje tehničkog sadržaja budućih iteracija Da se stvori osnova za utvrđivanje troškova i vremena potrebnog za razvoj sistema Da se definiše korisnički interfejs za sistem sa fokusom na želje i potrebe korisnika Rešavajući ove zadatke, disciplina zahteva opisuje kako definisati viziju sistema u izgradnji, kako tu viziju prevesti u model slučajeva upotrebe i kako definisati detaljne softverske zahteve sistema. Takođe, disciplina zahteva opisuje kako koristiti atribute zahteva da bi se lakše upravljalo sadržajem i promenom zahteva sistema u izgradnji. 2.1.1. Definisanje zahteva Zahtevi se moraju shvatiti kao uslovi ili sposobnosti koje sistem mora ispunti ili posedovati. Robert Grady je, u svojim naporima da utvrdi kriterijume za merenja u svrhu ocenjivanja softverskih sistema, kategorizovao kvalitativne atribute softverskih sistema. To su sledeći atributi: Funkcionalnost (Functionality) Upotrebljivost (Usability) Pouzdanost (Reliability) Performantnost (Performance) Podržanost (Supportability) Gore navedeni atributi čine akronim FURPS koji predstavlja koristan podsetnik za to kakvi su zahtevi potrebni da bi se u potpunosti definisao kvalitetan sistem. Upravo na osnovu akronima FURPS dobija se podela zahteva na funkcionalne i nefunkcionalne zahteve. Funkcionalni zahtevi su uvek okrenuti ka korisniku. Oni čine sistem koji se gradi korisnim za korisnika. Takođe predstavljaju i vodič za razvojne inžinjere, pri kreiranju takvog sistema koji treba da je u stanju da zadovolji potrebe korisnika. Ovi zahtevi se koriste za definisanje ponašanja sistema. Da bi se isporučio sistem željenog kvaliteta do krajnjeg korisnika, u obzir pri njegovoj izgradnji se mora uzeti i širok spektar atrbuta koji se ne mogu opisati kao funkcionalni zahtevi. Ovaj set zahteva se naziva nefunkcionalni zahtevi. 7

Koristeći FURPS kategorizaciju mogu se klasifikovati i nefunkconani zahtevi, na sličan način kao što se klasifikuju i kvalitativni atributi sistema. Upravo po toj klasifikaciji zahtevi mogu biti usmereni ka zadovoljavanju svakog od gore navedenih kvalitativnih atributa sistema. Pored funkcionalnosti zbog kojih se sistem razvija, pa ih mora i posedovati, sistem mora da zadovolji i sledeći set zahteva usmerenih ka podizanju upotrebljivosti sistema: Jednostavnost za učenje Lakoća korišćenja Konzistentnost korisničkog interfejsa Kvalitetana korisnička dokumentacija Kvalitetni materijali za trening Zahtevi usmereni ka pouzdanosti sistema se povezuju za učestalost grešaka, sposobnost da se sistem oporavi nakon greške, opseg grešaka, kao i predvidivost grešaka. Zahtevi vezani za performantnost su nametnuti funkcionanim zahtevima. Da bi se ispunili zahtevi vezani za funkcionalnost sistema potrebno je zadovoljiti i zahteve vezane za performantnost. Svakako da bi teško bilo zadovoljiti tražene funkcionalnosti budućeg sistema ukoliko to nije propraćeno sa adekvatnom brzinom sistema, vremenom odziva, vremenom oporavka, zazetošću memorije pri izvršenju odgovarajućih operacija, stabilnošću i sličnim karakteristikama sistema. Sistem mora da funkcioniše i nakon njegove isporuke korisniku. Upravo zato on mora da zadovolji zahteve korisnika vezane za održavanje sistema. Ovi zahtevi su prouzrokovani promenama u okruženju, novonastalim potrebama korisnika i tehničko tehnološkim napretkom. Svrstavanje zahteva dobijenih od stejkholdera, u neku od gore navedenih kategorija neće stvoriti dodatni kvalitet za sistem u izgradnji. Kvalitet više koji se dobija ovakvom klasifikacijom leži u lakšem i kvalitetnijem kreiranju šablona za obuhvat zahteva. Samim tim se dobijaju i kvalitetnije obuhvaćeni zahtevi, a to značajno doprinosi podizanju kvaliteta sistema u izgradnji. 2.2. Tipovi zahteva Tradicionalno, zahtevi se posmatraju kao detaljne tekstualne specifikacije koje se uklapaju u jednu od već spomenutih kategorija. Međutim, da bi se efikasno upravljalo zahtevima od pomoći je da se razumeju potrebe aktuelnih korisnika i ostalih stejkholdera, koje trebaju da se ispune kada se sistem razvije. Ukoliko se pravilno razumeju navedeni zahtevi, razvojni tim dobija tačne odgovore na pitanja šta i zašto. Poznajući ovo razvojni tim će biti u stanju da bolje izvrši interpretaciju zahteva i da donese kvalitetne odluke vezane za dizajn, koje će optimizirati razvojni proces. U nastavku su opisana tri osnovna tipa zahteva. 2.2.1. Potrebe stejkholdera Na vrhu piramide (slika 2.2.) se nalazi prvi tip zahtev, potrebe stejkholdera. Stejkholder predstavlja bilo koju osobu ili prestavnika organizacije koja je povezana sa ishodom projekta. Najčešće se kao stejkhoderi 8

javljaju krajnji korisnici, međutim ne treba zaboraviti ni ostale važne stejkholdere, kao što su: kupac, ugovarač, razvojni inžinjer, menadžer projekta, ili bilo ko čiji će interesi biti vezani za projekat u izradi. Potrebe Karakteristike Softerski zahtevi Slika 2.2. Piramida tipova zahteva Razvojni tim ime zadatak da prepozna i zadovolji potrebe ključnih stejkholdera sistema. Jako važno pitanje jeste kako prepoznati potrebe stejkholdera, pošto se tokom projekta prikupljaju različiti zahtevi stejkholdera. U ranoj fazi projekta koriste se intervjui, kao i radionice za pikupljanje zahteva. Dalje, kako projekat odmiče prikupljaju se promene zahteva, kao i novonastali zahtevi. Pri ovome se ne sme zaboraviti da su zahtevi stejkholdera često nejasni i dvosmisleni. Obično se prezentuju u formi Ja bih trebao..., kao npr. Ja bih trebao povećati svoju produktivnost. Vrlo je bitno prepoznati u stejkholderovim potrebama zahteve bitne za razvoj sistema. Upravo takvi imputi čine delove puzle koja određuje zašto i šta sistem treba da radi. Sve greške učinjene na ovome nivou su fatalne po konačan ishod projekta. 2.2.2. Karakteristike sistema Interesantno je, da kada se pravi inicijalni intervju sa stejkholderom o njegovim potrebama i zahtevima, često se dešava da stejkholder ne opisuje ni njegove potrebe ni njegove zahteve. Stejkholder je često u stanju da opisuje kombinaciju oboje. Ovakav tip apstrakcije se najčešće naziva karakteristike sistema. Primer kako stejkholder može dati različite apstrakcije prikazano je na slici broj 2.3. Tehnički, o karakteristikama se može razmišljati kao o sistemskom servisu koji direktno zadovoljava kupčeve potrebe. Često ovakve karakteristike nisu dobro definisane, čak su ponekad i u međusobnoj suprotnosti, ali je činjenica koja se ne sme zanemariti da one oslikavaju stvarne funkcionalnosti budućeg sistema. Ovde se pojavljuje jedan kvalitet više, gde su stejkholderi sposobni da transformišu svoje potrebe u ponašanje sistema, tj. oni su u stanju da izvrše transformaciju od šta u kako će se nešto implementirati. Upravo radi kvaliteta više koji nose, karakteristike sistema se tretiraju kao poseban tip zahteva. 9

Želim da Jovan i ja imamo bolju komunikaciju Želim automatsku e-mail notifikaciju Slika broj 2.2. Transformacija od potrebe ka karakteristici sistema 2.2.3. Softverski zahtevi Niti su potrebe stejkholdera, niti karakteristike sistema odgovarajuće za komunikaciju sa razvojnim inžinjerima, da bi im se prikazalo šta da rade. Potreban je novi nivo apstrakcije koji treba da prevede potrebe i karakteristike u specifikacije spremne za dizajniranje, implementaciju i testiranje. Za ovaj nivo specifikacije zahteva, potrebno je tretirati kako funkcionalne, tako i nefunkcionalne zahteve. Na osnovu zahteva korisnika, kreira se set dokumenata uključujući i dokument vizije koji sadrže ključne potrebe korisnika, kao i ključne karakteristike sistema. Da bi se karakteristike sistema uključile u viziju, potrebno je napraviti analizu troškova implementacije željenih karakteristika i analizu povrata investicije. Tek tada postoji opravdanost uvođenja karakteristika sistema u dokument vizije. Pre početka kodiranja karakteristike se prevode u detaljne sotverske zahteve, na osnovu kojih je moguće izvršiti dizajniranje sistema. Prilikom izrade detaljnih sofverskih zahteva moraju se imati na umu originalne potrebe stejkholdera i karakteristike sistema. Različite metodologije koriste različite načine za predstavljanje softverskih zahteva. Ukoliko koristimo UML notaciju, u izabranoj metodologiji razvoja, dijagramiranje slučajevima upotrebe predstavlja tehniku za prikaz softverskih zahteva. Pored dijagramiranja slučajevima upotrebe koriste se i dodatne tehnike, radi detaljnijeg predstavljanja softverskih zahteva. 2.3. Prikupljanje informacionih zahteva Kao što je ranije rečeno, Standish grupa je na osnovu svojih istraživanja, ukazala na oskudicu korisničkih inputa kao najčešći razlog neuspeha IT projekata. Pored čak trinaest procenata neuspešnih projekata, kod kojih ovaj uzrok predstavlja osnovni razlog neuspeha, kod dodatnih dvanaest procenata navode se nekompletni zahevi i specifikacije kao razlog neuspeha projekata. Iz navedenih podataka jasno je da za četvrtinu svih posmatranih projekata, nedostatak razumevanja stvarnih zahteva korisnika i drugih stejkholdera predstavlja ozbiljan problem koji otežava uspeh IT projekata. 10

Očekivanje da će se korisnici širom sveta iznenada probuditi i početi bolje objašnjavati svoje zahteve, može se smatrati nerealnim. Upravo to nameće obavezu razvojnim timovima da preuzmu inicijativu, tj. da razviju neophodne veštine pomoću kojih će kvalitetno vršiti obuhvat zahteva. U ovom poglavlju navode se brojne tehnike koje razvojnim timovima omogućuju bolje razumevanje stvarnih potreba korisnika i ostalih stejkholdera. Tehnike koje se navode u ovome poglavlju, rangiraju se od krajnje jednostavnih, jeftinih i neposrednih, pa do umereno skupljih i tenički zahtevnijih. Kao primer jednostavne tehnike može se navesti intervjuisanje, a kao tehnički najzahtevniju i svakako najskuplju tehniku možemo navesti prototajping. Iako ne postoji generalno najbolja tehnika obuhvata zahteva korisnika, svaka situacija nameće odgovarajuću tehniku kao optimalnu. Upravo radi toga razvojni tim treba da razvija veštine raznih tehnika obuhvata zahteva i sposobnost prepoznavanja idealne tehnike ili idealne kombinacije tehnika za određenu situaciju. Pored usvajanja navedenih veština, iskustva stečena na ranijim projektima donose kvalitet više razvojnom timu. Sve to zajedno predstavlja dobro ukomponovano znanje, koje aktivno doprinosi poboljšanju rezultata. 2.3.1. Izazov prikupljanja zahteva Proces obuhvata informacionih zahteva na prvi pogled izgleda vrlo jednostavno. Sve što je potrebno, je sesti sa korisnicima i ostalim stejkholderima sistema i pitati ih šta sistem treba da radi. Ovakvo razmišljanje često dovodi do sledećih pitanja: Zašto je to tako teško? Zašto je potrebno toliko tehnika? Zašto je potrebna timska veština? Pre detaljnog razmatranja različitih tehnika za obuhvat informacionih zahteva, potrebno je dati odgovore na ove nedoumice. Upravo radi toga u nastavku se navode tri sindroma 1 koja značajno usložnjavaju obuhvat informacionih zahteva. 2.3.1.1. Sindrom da ali Jedno od najviše frustrirajućih i naizgled najtežih problema u celom razvoju aplikacije je ono što se najčešće naziva da ali sindrom, a odnosi se na posmatranja korisničkih reakcija na delove softvera koji je razvijen. Radi pojednostavljenja razmatranja, situacija je plastificirana i predstavljena kroz dve jasne i odvojene reakcije kada korisnici prvi put vide implementaciju nekog dela sistema. Prvi set reakcija se ogleda u sledećim: O, to je odlično! Stvarno možemo ovo da koristimo? Kakav dobar program. Drugi set se ogleda u reakcijama sličnim narednim: 1 Navesti naziv knjige i autora odakle je preuzeta podela 11

Da ali, sada kada ovo vidim šta je sa...? Zar ne bi bilo zgodno kada bi...? Šta se desilo sa...? Koren da ali sindroma leži duboko u prirodi softvera, kao neopipljivog intelektualnog procesa. Razvojni tim često usložnjava problem tako što retko prikazuje bilo šta što je razvijeno, a što bi služilo za interakciju i ocenjivanje od strane korisnika, pre detaljne implementacije. Korisnička reakcija je tipično ljudske prirode i javlja se u varijacijama, zavisno od dana do dana. Korisnik sigurno nikada ranije nije video sistem koji mu se predstavlja, a neretko niti bilo šta slično. Čak šta više, moguće je da korisnik nije tačno usvojio ni sve što mu je predstavljano u ranijim fazama. U ovakvoj postavci problema, kada se korisnik prvi put suoči sa sistemom, vrlo je verovatna negativna reakcija, izražena kroz Da, ali sindrom. Krivicu za ovaj problem je najjednostavnije prebaciti na korisnika, međutim to neće dovesti do rešavanja istog. Upravo radi toga potrebno je prihvatiti Da, ali sindrom kao realnost, koja će pomoći razvojnom timu u budućnosti projekta. Da bi se ovaj sindrom prevazišao, razvojni tim mora imati na umu sledeće stvari: Da, ali sindrom je ljudske prirode i sastavni je deo razvoja aplikacija. Sindrom se drastično umanjuje primenom tehnika koje Da, ali sindrom otkrivaju u ranijim fazama. Rano otkrivanje sindroma, daje razvojnom timu mogućnost da usmeri svoje napore ka razvoju softvera na takav način, koji obezbeđuje siguran prolazak Da, ali testa. 2.3.2. Sindrom neotkrivene ruševine Obuhvat ili pronalaženje informacionih zahteva se može poistovetiti sa potragom za neotkrivenim ruševinama. Koliko god informacionih zahteva razvojni tim pronađe i obuhvati, nepoznato je koliko ih je preostalo. Otkrivanje i obuhvat svih informacionih zahteva je zadatak, koji verovatno nikada neće biti realizovan. To proizvodi negativan osećaj vezan za nedovršen posao, koji dovodi do toga da se razvojni tim nalazi u stalnim naporima da odredi kada je gotovo sa obuhvatom zahteva. Različite tehnike za obuhvat informacionih zahteva koje će biti prikazane u ovom radu, pomažu razvojnom timu da ublaži sindrom neotkrivene ruševine, tj. da pri pronalaženju i obuhvatu informacionih zahteva otkriju dovoljno, kao i da osete trenutak kada su otkrili dovoljno. 2.3.3. Sindrom Korisnici i razvojni inžinjeri Tehnike za obuhvat zahteva nisu nove. Razvojni inžinjeri se bore već desetine godina da ovaj posao obave što kvalitetnije. Međutim, i danas razumevanje korisničkih potreba predstavlja nejveći problem u razvoju softvera. Upravo zato, u ozbiljnim softverskim kućama, se često može susresti trening učesnika u razvoju, na savladavanju neke od tehnika obuhvata zahteva. 12

Sindrom Korisnici i razvojni inžinjeri nastaje radi komunikacionog gapa koji postoji između korisnika i razvojnih inžinjera. Najčešće, korisnici i razvojni inžinjeri su ljudi iz različitih svetova, govore različitim jezicima, imaju različitu pozadinu, motivaciju i različite ciljeve. Tehnike za obuhvat informacionih zahteva, predstavljaju most za premošćavanje gapa između korisnika i razvojnih inžinjera. Laura Scharer 2, još 1981. godine, opisuje ovaj sindrom i predlaže neke načine za prevazilaženje problema. Naredna tabela predstavlja neka od njenih zapažanja, dopunjena sa nekim savremenijim tehnikama. Tabela 2.1. Preporuke za prevazilaženje sindroma Korisnici i razvojni inžinjeri Problem Korisnici ne znaju šta žele Korisnici ne znaju da kažu šta žele. Korinici misle da znaju šta žele jer im razvojni inžinjeri nameću šta da kažu da žele. Analitičari misle da poznaju problem korisnika bolje od njih samih Svi veruju da su svi politički motivisani. Rešenje Prepoznavanje i shvatanje korisnika kao domenskog eksperta. Uvođenje alternativnih načina komuniciranja i tehnika obuhvata zahteva. Uvođenje alternativnih tehnika ranije: igra uloga, prototajping itd. Stavljanje analitičara na korisnikovo mesto. Pokušaj tehnike igra uloga jedan vremenski period. Ovo je deo ljudske prirode i kao takvo neminovnost sa kojom se mora računati. Kao što se vidi iz navedene tabele, različite tehnike obuhvata zahteva mogu da stvore kvalitet više i pomognu u prevazilaženju predstavljenih problema. 2.3.1. Tehnike za prikupljanje informacionih zahteva Radi boljeg razumevanja korisničkih potreba razvojni inžinjeri moraju da premeste oblast sopstvenog interesovanja sa područja bitova i bajtova, na područje gde se osećaju manje udobno, u područje stvarnih ljudi i stvarnih problema. Baš kao što postoji mnoštvo tehnika koje se mogu koristiti za analizu i dizajn softverskih rešenja, tako postoji i mnoštvo tehnika koje se mogu koristiti za obuhvat i razumevanje zahteva korisnika i ostalih stejkholdera sistema. U nastavku će biti nabrojane, a kasnije i detaljno opisane neke od tehnika za obuhvat korisničkih zahteva: Intervju Brainstorming i oblikovanje ideja Radionica (Workshop) zahteva Primena slučajeva upotrebe (opisana kroz dijagrame slučajeva uporebe) Igra uloga Prototajping Razvojni inžinjeri se opredeljuju za neku od nabrojanih tehnika, ili kombinaciju tehnika, zavisno od tipa aplikacije, veštine razvojnog tima, veštine kupca, razmera problema i korišćene tehnologije. U nastavku je detaljno opisana tehnika intervjua. 2.3.1.1. Intervju 2 Navesti izvor u kojem Laura Scharer opisuje sindrom 13

Intervju je tehnika koja se vrlo često koristi pri obuhvatu zahteva. Prilikom ove tehnike razvojni inžinjer diskusuje sa različitim stejkholderima i pokušava da razume njihove zahteve. Tipično postoje dva tipa intervjua 3 : 1. Otvoreni intervju, u kojem ne postoje unapred predefinisani materijali, te se u slobodno usmeravajućem razgovoru dolazi do odgovora na pitanje šta stejkholder želi od sistema. 2. Zatvoreni intervju, u kojem postoji unapred predefinisan set pitanja, te se razgovor obavlja u unapred predefinisanom okviru. Granice između gore navedenih načina nisu čvrste i često se događa da se tokom intervjua prelazi iz jednog tipa u drugi. Preporuka je na tome da se prvo iscrpi predefinisani set pitanja, a potom se po potrebi pređe na otvoreni intervju. Za uspešan intervju potrebno je ispuniti dve ključne pretpostavke: 1. Vršioc intervjua mora biti slobodouman i spreman da sluša stejkholdera. Razvojni inžinjer takođe mora biti spreman na menjanje sopstvenog mišljenja o problemu, radi usklađivanja sa stvarnim potrebama stejkholdera. 2. Stejkholder mora imati polaznu tačku za početak diskusije. To može biti predefinisani set pitanja ili postojeći sistem ili nešto treće. Ljudskoj prirodi je specifično, da mnogo lakše vodi razgovor na unapred zadatu temu. Intervju predstavlja, na prvi pogled, vrlo jednostavnu i direktnu tehniku za obuhvat informacionih zateva. Međutim, zamke koje ova tehnika krije su opasne i često dovode do ozbiljnih problema. Problem koji se najčešće javlja, jeste sindrom "Korisnik i razvojni inžinjer". Svaki razvojni inžinjer koji se pojavljuje kao osoba koja vrši intervju, sa sobom nosi nasleđe nagomilano u njemu samom, tokom njegovog prethodnog informatičkog i neinformatičkog razvoja. Upravo to može stvoriti problem tzv. usmeravanja korisnika, gde se možda i nesvesno, korisnik navodi da kaže ono što razvojni inžinjer želi čuti. Ove probleme uočavaju Gause i Weinberg 4 još 1989. godine, te nude "Context - Free Question" koncept, kao rešenje istih. Oni predlažu set neusmeravajućih pitanja, koja razvojnog inžinjera teraju na slušanje, pre nego što pokuša pronaći ili opisati potencijalno rešenje. Takođe ona predstavljaju polaznu tačku za početak diskusije i zatvorenog tipa intervjua. Primeri za takva pitanja su sledeći: Ko je korisnik? Ko je kupac? Da li su njihove potrebe različite? Gde bi se drugo moglo naći rešenje za ovaj problem? Na ovaj način razvojni inžinjer slušajući stiče razumevaje stejkholderovih problema, kako onih koji su bili uočljivi i pre početka razgovora, tako i onih koji su bili skriveni. Upravo ovi problemi su stvorili 3 Navesti izvor odakle je preuzeta podela 4 Navesti tačan izvor 14

motivisanost stejkholdera za izgradnju informacionog sistema, te oni moraju biti pronađeni pre konačne isporuke rešenja. Pomoću seta neusmeravajućih pitanja se predupređuje i sindrom "Da, ali...". U stalnoj potrazi razvojnih inžinjera za neotkrivenim zahtevima, postoji trenutak kada je prikladno pomeriti pitanja ka domenu pronalaženja rešenja. To je trenutak kada su nesugerišuća pitanja postavljena i kada je dobijen odgovor na njih. Pošto je osnovni zadatak razvojnih inžinjera pronalaženje rešenja, a ne razumevanje problema, stvara se potreba za pomeranjem intervjua ka pronalaženju rešenja za uočene probleme. Da bi se to izvelo, potrebno je usmeriti intervju ka domenu rešenja uvođenjem dodatnog konteksta. Dodatni kontekst ili dodatno objašnjenje može i kod stejkholdera stvoriti novi pogled na postojeće probleme. Naravno, stejkholderi zavise od razvojnih inžinjera, jer bez dodatog konteksta pojavljuje se realna opasnost da oni ispričaju sve što znaju o problemu. Da bi se intervju struktuirao na gore navedeni način potrebno je da razvojni inžinjeri generišu dokument koji će održavati intervju na željenom koloseku. Takav dokument bi se mogao nazvati "Šablon za kontrolisano sugerišući intervju". Naredni prikaz daje primer takvog dokumenta, koji sadrži i neusmeravajuća i usmeravajuća pitanja. Intervju sproveden na ovakav način predstavlja u stvari kombinaciju dva osnovna tipa intervjua, zatvorenog, sa setom predefinisanih pitanja i otvorenog, koji se započinje po iscrpljivaju svih pripremljanih pitanja. Tabela 2.2. Šablon za kontrolisano sugerišući intervju 5 Deo 1. Utvrđivanje profila stejkholdera Ime: Kompanija: Industrija: Zanimanje: Koje su vaše ključne odgovornosti? Koji su osnovni rezultati vašega rada? Za koga? Kako se mere vaši rezultati? Koji problemi ometaju vaš uspeh? Šta Vam otežava rad? Šta Vam olakšava rad? Deo 2. Procenjivanje problema Za koje probleme nemate dobra rešenja? (Savet: Stalno pitati - I još nešto?) Za svaki problem pitati: Zašto ovaj problem postoji? Kako ga trenutno rešavate? Kako biste voleli da ga rešavate? Deo 3. Razumevanje korisničkog okruženja Ko su potencijalni korisnici? Kako su obrazovani? Kakvo im je poznavanje rada na računaru? 5 Navesti izvor 15

Da li korisnici imaju iskustva sa sličnim aplikacijama? Koje platforme su u upotrebi? Koju platformu planirate da koristite u budućnosti? Da li koristite neke od dodatnih aplikacija koje bi mogle imati refleksiju na ovu aplikaciju? Šta su vaša očekivanja vezana za upotrebljivost ovoga proizvoda? Kakva vrsta korisničke pomoći (Npr. papirna verzija, on-line dokumentacija) vam je potrebna? Deo 4. Ponavljanje usvojenog Vi ste rekli sledeće (navesti sve probleme koje je ispitanik rekao sopstvenim rečima): Problem 1. Problem 2. Problem 3. Problem x. Da li ovo adekvatno reprezentuje sve vaše probleme? Da li imate još neke probleme da dodate? Deo 5. Problemi stejkholdera Inputi za analitičara Koji, ukoliko postoje, problemi su u vezi sa gore navedenim? Problem 1. Problem 2. Problem 3. Problem x. (Za svaki problem pitati) Da li je ovo stvarno problem? Šta su razlozi za ovaj problem? Kako trenutno rešavate ovaj poblem? Kako biste želeli da rešavate ovaj problem? Koliko Vam je bitno rešenje ovoga problema u odnosu na ostale probleme koje ste spomenuli? Deo 6. Procenjivanje rešenja (Pokušati sakupiti potencijalna rešenja za navedene probleme po stejkholderovim shvatanjima) Rešenje 1. Rešenje 2. Rešenje 3. Rešenje x. Kako biste rangirali rešenja po važnosti? Deo 7. Procnjivanje upotrebljivosti Ko u Vašoj organizaciji treba ovu aplikaciju? Koliko tipova korisnika bi koristilo ovu aplikaciju? Kako biste vrednovali upešno rešenje? (Važnost : Velika Srednja Mala) Deo 8. Procenjivanje pouzdanosti, performantnosti i podržanosti Koja su Vaša očekivanja što se tiče pouzdanosti? Koja su Vaša očekivanja vezana za perfomantnost? Da li ćete Vi lično da podržite budući proizvod? Da li će ga, po vašem mišljenju, podržati drugi? Da li imate neke specijalne zahteve za podršku? Šta očekujete u vezi održavanja? Koji su Vaši zahtevi vezani za sigurnost? 16

Koji su Vaši zahtevi vezani za instaliranje i konfigurisanje proizvoda? Da li su potrebne neke specijalne dozvole? Deo 9. Ostali zahtevi Da li postoje neke pravne regulative, zahtevi iz okruženja ili neki standardi koji moraju biti zadovoljeni? Možete li setiti bilo kojeg zahteva za koji bi mi trebali znati, a da do sada nije rečen? Deo 10. Sumiranje intervjua Da li postoje još neka pitanja koja bi Vas trebao pitati? Da li ste raspoloženi za eventualna naknadna pitanja, ukoliko se pojavi potreba? Da li ste raspoloženi da učestvujete u pregledu zahteva? Deo 11. Analitičarev zaključak (Dok su još podaci sveži u glavi analitičara potrebno je zavesti tri ključne potrebe ili problma koje je stejkholder naveo) 1. Ključna potreba 1. 2. Ključna potreba 2. 3. Ključna potreba 3. Ovako pripremljen intervju omogućuje da bilo koji član razvojnog tima može, relatvno kvalitetno, obuhvatiti zahteve stejkholdera. Međutim, najprikladnije je da se izbere član, koji ima najviše iskustva na poslovima obuhvat zahteva. Prilikom izbora osobe koja će vršiti obuhvat zahteva, ne smeju se zaboraviti ni lične osobine članova tima. Pogodno bi bilo da se izabere što komunikativnija osoba. Pre intervjua potrebno je sledeće: Pripremiti prikladan kontrolisano usmervajući intervju. Obavezno se podsetiti na pripremljeno, neposredno pre intervjua. Pronaći osnovne informacije o stejkholderima i kompaniji, te na taj način rasteretiti ispitanika pitanja na koja se odgovori mogu pronaći pre intervjua. Tokom intervjua potrebno je pedantno zapisivati odgovore koje stejkholder daje. Takođe, potrebno je s vremena na vreme pogledati u šablon i proveriti tok intervjua. Često se dešava da stejkholder prilikom davanja odgovor uđe u detaljno objašnjavanje nepotrebnih detalja. Prekidanje izlaganja u ovakvom bi bilo pogrešno, jer bi se moglo lako izgubiti poverenje između ispitanika i ispitivača. Potebno je strpljivo sačekati kraj izlaganja, te potom preći na naredno pitanje. Nakon nekoliko intervjua, razvojni inžinjer analitičar, će steći osnovna znanja o problemu. Ubrzo potom, on će biti u stanju da uoči ključne potrebe korisnika. Te potrebe se nalaze na vrhu piramide zahteva i predstavljaju pokretačku snagu za sav posao koji sledi. 2.3.1.2. Brainstorming Mnogi problemi ne mogu se rešiti automatski, prvom generisanom idejom. Ponekad da bi se izabralo najbolje rešenje potrebno je razmotriti više potencijalnih rešenja. Jedna od najkvalitetnijih tehnika koja omogućava da se od mnoštva solucija izabere najbolja jeste Brainstorming. Postoje razne definicije Brainstorminga. Neke od njih su navedene u nastavku: 17

Brainstorming je proces generisanja novih ideja. Brainstorming je konferencijska tehnika kod koje grupa ljudi pokušava da nađe rešenje za određen problem, sakupljanjem ideja svih učesnika u sesiji i biranjem najbolje ideje za dati problem Brainstorming je proces namenjen dobijanju maksimalnog broja ideja koje se odnose na rešavanje nekog specifičnog problema. Brainstorming je proces udruživanja ideja grupe ljudi u cilju dobijanja novih ideja. Brainstorming je tehnika koja maksimizira sposobnost generisanja novih ideja. Brainstorming je put razvoja mnogih kreativnih rešenja visoko kompleksnih problema. Termin brainstorming potiče od reči "brain" što znači mozak i "storming" što znači oluja, što bi u bukvalnom prevodu značilo "moždana oluja". Međutim ako se pogleda ono što ovaj pojam zaista predstavlja, možda bi primereniji naziv mogao biti "borba ideja" ili "borba mišljenja". Brainstorming kao tehnika bazira se na činjenici da su ljudi stimulisani za veliku kreativnost, u međusobnoj saradnji i grupnom istraživanju. Dakle brainstormingom se: Podstiče kreativnost svih učesnika u sesiji. Podstiču učesnici da kroz grupni rad stignu do genijalnih ideja Postoji širina u analizi i stvaranju novih ideja U globalu posmatrano breinstorming obuvata dve velike faze: generisanje ideja i redukcija ideja. Primarni zadatak ove prve faze je obuhvatiti što je moguće više ideja, bez obzira na njihovu širinu. Primarni zadatak druge faze je analiza generisanih ideja, zatim eliminisanje nekih od njih, njihovo organizovanje, razvrstavanje, prerađivanje i rangiranje. Generisanje ideja Brainstorming se može realizovati na različite načine. U debati može učestvovati od nekoliko učesnika do nekoliko desetina učesnika. Međutim, da bi se brainstorming razlikovao od obične debate on mora da se sprovodi po određenim pravilima. Mora postojati osmisljen postupak organizovanja debate. Predlog aktivnosti za sprovođenje sesije dat je u nastavku: Definisaje problemske oblasti. Pre početka je potrebno definisati problemsku oblast za koju se žele kreirati nove ideje, i ukoliko je moguće napraviti skicu problema koji postoje, kao i onoga što se želi u novim idejama postići. Naravno to ne sme biti sugestivno, jer bi se omeo tok brainstorminga. Izbor osoba za obavljanje zadataka vezanih za upravljanje sesijom. Tokom ove aktivnosti se bira lice koje će voditi tok sesije, i koje će na neki način biti lider sesije. Takođe je potrebno odrediti osobu koja će obavljeti poslove zapisničara. Za lidera sesije potebno je izabrati kreativnu osobu, sposobnu za vođenje sesije po definisanim pravilima. Definisanje pravila za tok sesije. Tokom trajanja sesije atmosfera treba da bude prijatna za rad, tj. stimulativna za generisanje smelih ideja. Neophodno je odlučiti koga pozvati na ovu sesiju. Broj učesnika se može kretati od 5 do 40 lica. Što je veći broj lica koja učestvuju u sesiji, to je teži posao lidera, duže traju sesije i potrebno je obezbediti veću prostoriju za održavanje sesija. Ako je u pitanju sesija koja obuhvata manji broj lica predlaže se manja prostorija gde će učesnici 18

sedeti oko jednog stola, sa papirom koji će prekriti ceo sto. Svaki učesnik dobija odgovarajući materijal na kome zapisuje svoju ideju i za potrebe kasnije prezentacije iste. Vođa sesije zadužen je da temeljno opiše problem, za koji se traže ideje. Nakon toga proverava da li je svim učesnicima jasan izložen problem, što je veoma bitno da se ne bi pomerio tok debate u suprotnom pravcu. U cilju uspešnog sprovođenja debate i prikupljanja ideja on može postaviti neka usmeravajuća pitanja: Šta očekujete od novog proizvoda? Kakve bi njegove karakteristike trebale biti? Određivanje vremenskog ograničenja. Kada je temeljno objasnio suštinu problema vođa sesije određuje vremenski period u kome bi svaki od učesnika trebao da iznese svoju ideju. To može biti period od sat vremena, dva sata ili više sati mada se u široj literaturi ipak predlaže sat vremena. Svaki od učesnika u sesiji može predložiti jednu ideju, za koju on smatra da je najbolja. Kada istekne predviđeno vreme, svaki učesnik pojedinačno iznosi svoju viziju rešenju problema, odnosno zapisuje njegovu ideju na tabli koja će biti vidljiva svima. Pokretanje debate. Kada svi učesnici prezentuju svoje ideje, sledi aktivnost u kojoj se jednom debatom pojedine ideje dopunjuju, pojedine kombinuju sa idejama drugih učesnika itd. I ovde važi pravilo ne kritikovanja drugih. Iskustva pokazuju da najkreativnije i najinovativnije ideje nisu samo rezultat genijalnosti pojedinaca, već da su one u velikom broju slučajeva nastajale kao rezultat kombinovanja ideja. Osnovna pravila kojih bi se trebali pridržavati u fazi generisanja ideja su: nema kritikovanja od bilo koga u grupi- ne sme biti negativnih komentara sloboda izražavanja je potpuno dozvoljena što je ideja smelija utoliko je bolja poželjno je prikupiti što veći broj ideja kvantitet ideja nije ograničen kombinacija i improvizacija ideja ohrabruje tuđe ideje mogu se iskoristii za proizvodnju novih vlastitih ideja. Redukcija ideja Kada se završi faza generisanja ideja, naredna faza brainstorminga odnosi se na redukciju ideja. Ova faza realizuje se kroz nekoliko koraka. Odstranjivanje ideja. U ovom koraku uočavaju se neke ideje koje po mišljenju grupe ne zaslužuju pažnju u daljoj analizi, jer se uviđa da poseduju određenje nedostatke. Dakle lider projekta pita učesnike o njihovom mišljenju vezanom za određenu ideju, i ukoliko se svi slože odlučuje se o odstranjivanju ideja za koje se smatra da nisu validne. Ne sme da postoji defanzivan stav učesnika vezan za njegovu ideju, niti bilo koji učesnik polaže autorska prava na ideju. Jednostavno svi su deo tima, i trude se da što bolje realizuju svoj zadatak. Grupisanje ideja. Naredni korak u redukciji ideja odnosi se na grupisanje ideja. Svaki korisnik odlazi do table i ukazuje na ideje koje su po njemu srodne. Srodnim idejama daje se zajednički naziv shodno karakteristikama tih ideja. 19

Definisanje osobina. U ovom koraku lider sedsije se konsultuje sa svakim učesnikom oko ideja koje su preostale. Učesnici daju kratak opis preostalih ideja, posebno ukazujući na njihove dobre strane. Utvrđivanje prioriteta. U određenim situacijama generisanje ideja je ključan zadatak, i nakon toga proces je gotov. Međutim u većini situacija neophodno je i utvrđivanje prioriteta ideja koje su preostale nakon odstranjivanja nekih. Postoje sledeće vrste brainstorminga: tradicionalni brainstorming web bazirani braistorming obrnuti brainstorming Web baziran brainstorming, koristi se u situacijama kada zbog određenih razloga ne može organizovati tradicionalni ili brainstorming "uživo". Tada se pomoću interneta i adekvatnih softverskih paketa može organizovati brainstorming proces. Prednost web-baziranog brainstorminga ogleda se u istrajnosti ideja i komentara koji će cirkulisati duži vremenski period, sa beleženjem i najmanjih sitnica vezanim za ideje. Na taj način ideje mogu vremenom "sazrevati" i samim tim može se doći i do vrlo zanimljivih rešenja. To je ujedno i najveća pednost ove tehnike. Obrnuti brainstorming je grupna tehnika za dobijanje nove ideje fokusirajući njene negativnosti i koristeći se njenim negativnim komentarima. Tako se npr. postavlja pitanje: "Na koliko načina ova ideja može pogrešiti" ili "Koje su sve loše strane ove ideje". Može se koristiti pre drugih ideja da bi stimulirala inovativan razgovor. 2.3.1.3. Radionica zahteva Radionica zahteva je jedna od najefikasnijih tehnika koja se koristi u obuhvatu informacionih zahteva. U bukvalnom prevodu na naš jezik requirements workshop bi označavao radionicu za obuhvat informacionih zahteva. Pravilna primena ove tehnike podrazumeva sledeće koncepte: Saradnja - Što je veća saradnja članova tima, veća je verovatnoća da će se postići uspeh u radu Poštovanje dogovorenog - Sve ono što je dogovoreno između razvojnih inžinjera i vlasnika kapitala mora biti ugrađeno u nov proizvod. Politička nemotivisanost - Članovi projktantskih timova moraju biti izuzeti od bilo kakvih političkih uticaja Radionica zahteva se odnosi na organizovanje sastanka u kome će pažljivo odabrana grupa stejkholdera raditi zajedno na definisanju, kreiranju, usavršavanju i obuhvatu informacionih zahteva. Jedan od učesnika bira se za koordinatora. To mora biti osoba sa najvećim znanjem i iskustvom, sposobna da stvori dobru atmosferu u radu. Pred koordinatorom stoje brojne obaveze. On ima sledeće zadatke: 20

da odredi vreme trajanja sastanka da utvrdi pravilnik i da se rukovodi sastankom u skladu sa njim da upozna sve članove tima sa ciljevima sastanaka da upravlja sastankom i da drži tim na okupu, itd. Učesnici na ovim sastancima mogu biti domenski eksperti, razvojni inžinjeri, menadžeri i budući korisnici. Njihov broj je varijabilan i kreće se u intervalu od 8 do 12. Ove radionice podstiču timski rad i bolje međusobno razumevanje svih članova. Jedan od razloga organizovanja ove radionice je prevazilaženje jaza između razvojnih inžinjera i korisnika u cilju uspostavljanja višeg nivoa komunikacije. Ključni zadatak rada ove grupe odnosi se na obuhvat informacionih zahteva. Ovo je kompleksan posao sa svim opsanostima navedenim u prvom delu rada. Upravo radi smanjnja rizika, učesnici moraju biti visoko kvalifikovani za posao koji obavljaju, kako razvojni inžnjeri, tako i sami korisnici. Tabela 2.3. Razlike između običnog sastanka i radionice zahteva Vodi ih menager Običan sastanak Ne zahteva se priprema učesnika za rešavanje problema Glavni zadatak je razmena informacija Radionica Vodi ih koordinator tima koji ima daleko veću sposobnost rešavanja problema Zahteva se temeljna priprema učesnika Zadaci su razmena informacija, istraživanje, kreativnost, temljan rad na razvoju sistema kroz obuhvat zahteva 2.3.1.4. Igra uloga Ova tehnika omogućuje razvojnim inžinjerima da lično iskuse poslove koji se automatizuju. Na ovakav način razvojni tim upoznaje svet korisnika direktno, igranjem uloge korisnika u njegovom svakodnevnom i radnom okruženju. Posmatranje i postavljanje pitanja pomaže u razumevanju sistema, ali često to nije dovoljno za potpuno zazumevanje svih informacionih zahteva koji će se pojaviti u cilju rešavanja tretiranog problema. Često korisnici nisu u staju da u potpunosti opišu procedure koje svakodnevno obavljaju. Iako na prvi pogled izgleda banalno opisati svakodnevne zadatke, mora se uzeti u obzir da opis tih zadataka ne spada u same zadatke. To znači da osobe koje obavljaju određene zadatke nisu do trenutka ispitivanja imale potrebu da opisuju procedure koje obavljaju. Dalje, radnici često nauče da poslove obavljaju šablonski, ne poznajući celinu problema. U tim situacijama se ne može očekivati ni kvalitetan opis problema. Problem može postojati i sa strane razvojnog tima, u situacijama kada se ne obavi dovoljno kvalitetno ispitivanje te se ne dobiju ni kvalitetne informacije. Usvim nabrojanim situacijama pristupa se tehnici igranje uloga. Najjednostavnija forma igranja uloga je ona u kojoj članovi razvojnog tima zamene uloge zauzmu mesta korisnika u obavljanju svakodnevnih poslova. Iskustvo koje u ovakvoj poziciji steknu razvojni inžinjeri je veliko i nemerljivo. 21