VEBA 6

Iterativni

dizajn Analiza zadataka i korisnika USE CASE DIAGRAM SEQENCE DIAGRAM VISIO

ITERATIVNO PROJEKTOVANJE
Dananji

primer najboljeg pristupa dizajnu u softverskom inenjerstvu Proces razvoja korisnikih interfejsa Specijalizacija spiralnog modela Barry Boehm-a Analiza zadataka je proces u kome se otkrivaju karakteristike korisnika i zadataka koje oni treba da urade To je prvi korak u dizajnu korisnikog interfejsa.

 Prua

nacin da se upravlja rizikom u procesu dizajna korisnickog interfejsa Proces razvoja softvera se deli u nekoliko koraka koji se ponavljaju u ciklusima Prvo se projektuje, zamilja kako ce izgledati Zatim se fizicki realizuje, implementira Nakon toga se testira, evaluacija

 Svaka

iteracija je vezana za izdavanje nove verzije korisnikog interfejsa Evaluacija (albe) slui kao povratna sprega novih informacija u sledeu fazu projektovanja Korisnici koji kupuju softver se ne mogu koristiti za ocenu korisnosti jer im se

to nece dopasti nece kupiti sledecu verziju proizvoda

SPIRALNI MODEL
Dimenzija

koja se vezuje za prenik se odnosi na troak iteracije tj. na tanost dizajna. Npr. u ranim fazama implementacije moe se napraviti skica. Ova skica ima loiji kvalitet, i samo lici na ono kako ce izgledati softver. Njena prednost je to je jeftina za napraviti i moe se pokazati korisnicima, kojima se mogu postavljati pitanja vezana za softver.

PROJEKTOVANJE USMERENO NA KORISNIKA (USER-CENTERED DESIGN)

Iterativno

projektovanje Rano usmeravanje na korisnike i zadatke Analiza korisnika: ko su korisnici? Analiza zadataka: ta korisnici treba da urade? Ukljuivanje korisnika u fazu testiranja, za konsultacije, a nekad i kao projektante Konstantno testiranje Korisnici su ukljuceni u svaku iteraciju Svaki prototip se testira na neki nacin

IDENTIFIKOVANJE KARAKTERISTIKA KORISNIKA

Godine,

pol, nacionalnost (zbog jezika i pisma) Fizicke karakteristike Vetine (kucanje? citanje? deca, stariji, nepismeni) Osnovna racunarska pismenost Iskustvo u radu sa aplikacijom Iskustvo u radu sa zadacima Radno okruenje i odnos sa kolegama Veze sa ljudima u okruenju i nacin komunikacije Vecina aplikacija poseduje grupe korisnika Analiza korisnika se radi za svaku grupu korisnika

TEHNIKE ZA ANALIZU KORISNIKA

Upitnici Intervjui Posmatranje Prepreke:

oni koji razvijaju aplikaciju i koji je koriste su odvojeni jedni od drugih Tehnicka podrka je veza izmedu korisnika i programera Marketing odvaja korisnike od programera (suprotan smer) Neki korisnici su previe skupi ili zauzeti (lekari, direktori, clanovi sindikata) Najbolji nacin da se uradi analiza korisnika je naci predstavnike korisnika Ocigledne karakteristike se mogu dobiti iz upitnika Detalji o kontekstu i okruenju se dobijaju inervjuisanjem korisnika ili posmatranjem kako rade

ANALIZA ZADATAKA(TASK ANALYSIS)

Identifikovanje

individualnih zadataka koje program

treba da rei Svaki zadatak ima cilj (ta? ne, kako?) esto se pocne od ukupnog cilja sistema koji se hijerarhijski dekomponuje u zadatke

KLJUNI DEO ANALIZE ZADATAKA

ta treba uraditi? Cilj Goal ta treba uraditi pre nego to se krene sa zadatkom Preduslovi, zadaci od kojih zavisi trenutni zadatak Od kojih koraka je sastavljen zadatak Podzadaci, koji se mogu rekurzivno dekomponovati Gde se zadatak izvrava? Koliko cesto se izvrava? Da li postoje vremenska ogranicenja ili ogranicenja u pogledu resursa? Kako se zadatak uci? ta moe krenuti naopako (izuzeci, greke, hitni slucajevi)? ta je jo ukljuceno u zadatak?

KAKO SE IZVODI ANALIZA ZADATAKA?

Intervjui

sa korisnicima Posmatranje kako korisnici izvravaju zadatak

OPASNOST PRI ANALIZA ZADATAKA

Dupliciranje

loe postojece procedure u softveru Nemogunost uvianja dobrih aspekata postojece procedure

PREPORUKE ZA BOLJE IZVODJENJE ANALIZE

KORISNIKA I ZADATAKA
Pitanja

koja treba pitati Zato ovo radite? (cilj) Kako to radite? (podzadaci) Traiti mane u postojecoj situaciji Neispunjen cilj, utroeno vreme, iritacija korisnika

OSNOVNI POJMOVI
Slucajevi

koricenja (Use cases)

Opisuje sekvencu akcija koje pruaju merljivu vrednost za aktera. Crta se kao horizontalna elipsa

Akteri

(Actors).

Su osobe, organizacija, koji stupaju u jednu ili vie interakcija sa sistemom. Crtaju se kao figurice coveka(cica glia)

 Pod

terminom sluaj koricenjapodrazumeva se jedan specifican nacin koricenja programa Preko slucaja koricenja opisuje se interakcija nekog objekta van sistema sa samim programom. Skup slucajeva koricenja predstavlja sve pretpostavljene nacine koricenja sistema.

PRIMER SLUAJA KORIENJA

 Svaki

sluaj koricenja treba da bude detaljno opisan. Mada je moguce davati i formalan opis sluaja koricenja (dijagrami kolaboracije, dijagram promene stanja) preporuuje se da se u prvoj fazi koristi struktuirani verbalni opis, jer je on neophodan cak i ako se da neki formalni opis. Uobiajeno je, takoe, da se posebno daje opis normalnog toka dogaaja u slucaju koricenja, a posebno moguci izuzeci.

OSNOVNI SCENARIO
Provera kartice: Komitent ubacuje karticu u automat. Automat cita karticu i proverava da li je prihvatljiva. Ako je prihvatljiva, zahteva se od komitenta da unese tajnu ifru. Proveravanje ifre: Komitent unosi tajnu ifru. Ako je ifra korektna zahteva se da korisnik izabere transakciju. Unos tipa transakcije: Komitent bira podizanje novca I automat alje racunaru banke tajnu ifru da bi se dobili brojevi komitentovih racuna. Dobijaju se komitentovi brojevi racuna prikazuju na ekranu automata. Podizanja novca: Komitent bira racun i unosi iznos koji podie.Automat alje racunaru banke zahtev za podizanje datog iznosa sa datog racuna. Priprema se tampanje izvetaja za komitenta. Kraj: Automat vraca karticu karticu komitentu. Izdaje se izvetaj komitentu

ALTERNATIVNI SCENARIO
Kartica

nije prihvatljiva: Kartica se vraca korisniku sazvucnim signalom. Nekorektna tajna ifra: Odgovarajuca poruka se Pri kazuje na ekranu i daje se ansa korisniku da je ponovo unese. Dozvoljava se tri pokuaja, a zatim se vraca kartica korisniku. Prekid: Korisnik moe u svakom trenutku da prekine transakciju. Ponitice se svi dotadanji efekti i vratiti kartica korisniku.

PRIMER U/I
Mada

SK treba, prvenstveno, da bude logicki opis koricenja sistema, treba imati u vidu i buducu arhitekturu sistema, a ponekad se opis daje preciznije ako je prethodno definisan korisnicki interfejs. To ne sme da implicira zavisnost buduce aplikacije od interfejsa

DIJAGRAMI INTERAKCIJE
Dinamiki

opis se daje preko dijagrama interakcija Interakcije se mogu modelovati prikazujui vremenski redosled poruka: DIJAGRAMI SEKVENCI

SISTEMSKI DIJAGRAMI SEKVENCI

Sistemski

dijagram sekvenci predstavlja dogaaje koji eksterni aktori generiu, za pojedini slucaj koricenja Oni predstavljaju vizuelni pregled individualnog slucaja koricenja Sistem se tretira kao crna kutija; i dijagram naglaava dogaaje sa sistemom koje iniciraju akteri Treba ga uraditi za osnovni scenarijo slucaja koricenja Delovi SDS-a
Eksterni akteri Poruke koje alju aktori Povratne poruke (ako postoje) od sistema

Novi

kandidat

Akter:

Operater Svrha: Prijem dokumenata novog kandidata Opis: Sistem zahteva od operater za unos podataka unos potrebnih podataka o novom kandidatu
Normalno

funkcionisanje

IZRADA PROTOTIPOVA
Izmeu

dva suprotna stanja treba da postoji kontrast

Primer: nije dobro da se poruka o uspenom izvravanju ili poruka o greci prikae na isti nacin Primer: dugme OK ne bi trebalo da bude obojeno crvenom bojom (osim ako se interfejs prilagoava color-blind osobama)

Konzistentnost:

Jednostavan

dizajn (simplicity)

Koristiti nekoliko osnovnih boja + nekoliko njihovih nijansi Ovo dozvoljava da se koricenjem neke druge boje skrene panja na neto bitno