Dizajn je kreativni proces pretvaranja problema u reenje, opis reenja se takoe zove dizajn. KONCEPTUALNI I TEHNIKI DIZAJN -dizajn je interativni proces iz dva dela. 1. konceptualni dizajn ili dizajn koji opisuje klijentu tano ta e sistem raditi. Poto ga klijent odobri konceptualni dizajn se prevodi u mnogo detaljniji dokument -tehn. dizajn 2. Tehniki dizajn omoguava graditeljima sistema da utvrde koji e hardver i softver biti potrebni za reenje klijentovog problema. Konceptualni dizajn usresreen na funkcije sistema i tehniki dizajn koji opisuje oblik sistema. Kako se sistem definie svojim granicama, entitetima, atributima i odnosima(relacijama), konceptualni dizajn opisuje svaki od tih aspekata sistema u vidu odgovora na pitanja kao to su: Odakle e podaci dolaziti? ta e se u sitemu dogaati sa podacima? Kako e sistem izgledati korisnicima? ta e korisnici moi da biraju? Kakav je vremenski raspored dogaaja? Kako e izgledati izvetaji i ekrani? Sistem se u konceptualnom dizajnu opisuje jezikom koji klijen razume, a ne raunarskim argonom i tehnikim terminima. Dobar konceptualni dizajn bi morao da ima sledee karakteristike: da bude pisan jezikom klijenta da ne sadri tehnii argon da opisuje funkcije sistema da ne zavisi od implementacije da bude povezan sa dokumentima specifikacije zahteva drugim reima, konceptualni dizajn omoguava klijentu da shvati ta e sistem raditi tako to objanjava spoljanje karakteristike sistema. Tehniki dizajn opisuje konfiguraciju hardvera, softverske potrebe, komunikacione intefejse, ulaze u sistem i izlaze iz njega, mrenu arhitekturu i sve ostalo ime se zahtevi prevode u reenje klijentovog problema, Znai opis u tehnikom dizajnu je tehnika slika specifikacije sistema. Tehniki dizajn najmanje to sadri je : opis glavnih hardverskih komponenti i njihove funkcije hijerarhiju i funkcije softverskih komponenti strukture i tokove podataka RASLANJAVANJE I MODULARNOST Projektovati sistem znai utvrditi skup komponenti i interfejsa meu komponentama koji zadovoljavaju konkretan skup zahteva. Dizajn se moe realizovati na jedan od naina: Modularno ralanjivanje: Ova konstrukcija se zasniva na tome da se komponentama dodele funkcije. Dizajner poinje sa optim opisom funkcija koje treba implementirati i gradi detaljna objanjenja o organizaciji savake komponente i njenim relacijama sa ostalim komponentama. Ralanjivanje na osnovu podataka: Ovaj dizajn se zasniva na spoljanjim strukturama podataka. Opti opis prikazuje globalnu strukturu podataka, a detaljani opisi navode koji e elementi podataka biti obuhvaeni i kakve su njihove meusobne veze. Ralanjaavanje na osnovu dogaaja: Ovaj dizajn zasniva se na dogaajima koje sistem mora da obradi i koristi informacije o tome kako dogaaji menjaju stanje sistema. Opti opis sadri spisak razliitih stanja, detaljan opis govori kako dolazi do transformacije stanja. Dizajniranje spolja ka unutra: Ovaj pristup crne kutije zasniva se na onome to korisnik unosi u sistem. Znai opti opis navodi ta sve korisnik moe da unese, a detaljni opisi opisuju ta e sistem sistem uraditi sa svakim od unetih elemenata, kao i dobijene podatke. Objektno orjentisan dizajn: Ovaj dizajn definie klase objekata i njihove meusobne veze. Na najoptijem nivou opisuje tipove objekata. Na detaljnijim nivoima se opisuju atributi objekta akcije, dizajn objanjava meusobne veze veze objekata. Bez obzira na pristup dizajnu, svaka vrsta ralanjavanja razdvaja dizajn na sastavne delove koje nazivamo modulima ili komponentama. Za sistem kaemo da je modularan kada svaku aktivnost sistema vri samo jedna komponenta sa dobro definisanim ulazima i izlazima. U svakom sluaju komponenta dizajna je entitet sa dobro definisanim ulazom, izlazom i karakteristikama. Kaemo da je komponenta dobro definisana ako su svi njeni ulazi bitni za njenu funkciju, a sve izlaze proizvodi jedna od njenih akcija. To znai da ako nedostaje jedan ulaz, komponenta nije u stanju da obavi svoju funkciju u celosti. Osim toga ne postoje nepotrebni ulazi tj. Svi ulazi se koriste za definisanje izlaza.

1 TA JE OBJEKTNA ORJENTACIJA Objektna orijentacija predstavlja pristup razvoju softvera u kojem se problem i njegovo reenje organizuju kaokup direktnih objekata pri emu ta predstava obuhvata i strukturu podataka i ponaanje. Objektno orjentisana reprezentacija se moe prepoznati na osnovu svojih sedam karakteristika: identitet, apstrakcija, klasifikacija, enkapsulacija, nasleivanje, polimorfizam i perzistencija(trajanje). Identitet postoji zbog injenice da su podaci organizovani u diskretne, jedinstveno prepoznatljive celine, koje zovemo objekti. Objekat ima svojstvena stanja i ponaanja. Svaki objekat u OO sistemu obino poseduje ime i obezbeuje meusobno razlikovanje objekata. Apstrakcije u OO sistemu pomau da se predstave razliiti aspekti sadrani u sistemu koji je predmet projektovanja. Klasifikacija se u OO sistemu koristi za grupisanje objekata sa zajednikim svojstvima i ponaanjem. Enkapsuliranje, kao tehnika OO je tehnika pakovanja informacija na takav nain da se sakriju informacije koje treba da budu sakrivene a vide one koje treba da budu viene. Nasleivanje Da bi smo izgradili hijerarhiju, poinjemo od sveobuhvatne klase a zatim je delimo u specijalizovane podklase. Podklasa moe da nasleuje kako strukturu, tako i ponaanje i atribute nadreene klase. Polimorfizam Ponaanje je akcija ili transformacija koju vri objekat ili koja se nad njim vri. Ponaanje objekta se pokree prijemom neke poruke ili ulaskom u neko stanje. Ponekad se isto ponaanje razliito manifestuje kod razliitih klasa ili potklasa, i ta osobina je poznata kao polimorfizam. Perzistentnost(trajnost) sposobnost da ime, stanje i ponaanje objekta opstanu u vremenu i prostoru. Drugim reima, ime, stanje i ponaanje objekta se uvaju prilikom njegove transformacije. OO DIZAJN SISTEMA Koristimo UML dijagrame klasa. Ti dijagrami opisuju tipove objekata i njihove statike relacije. Konkretno elimo da prikaemo povezanost objekata, i relacije tip-podtip. elimo da dijagram ilustruje atribute svakog objekta, pojedinana ponaanja i ogranienja za svaku klasu ili objekat. Proces projektovanja poinje iskazivanjem zahteva. Zatim pokuavamo da izdvojimo imenice, i na osnovu tih konkretnih elemenata formuliemo polazni skup klasa. Traimo: strukture spoljne sisteme ureaje uloge radne postupke mesta organizacije stvari sa kojima projektovani sistem funkcionie Sledea pitanja mogu da poslue kao uputstvo za pronalaenje kandidata za klase: ta je to to treba na neki nain da se obradi? Koje stavke poseduju vie atributa? Kada postoji vie objekata u jednoj klasi? ta potie od samih zahteva, a nije izvedeno iz naeg tumaenja zahteva? Koji atributi i operacije se mogu uvek primeniti na neku klasu ili objekat? Razmatramo ponaanja koja moraju da se opiu u naem dizajnu. Iz specifikacije zahteva izdvajamo glagole. Ponovo traino konkretne elemente koji opisuju ponaanja: zapovedne glagole pasivne glagole akcije stvari ili podsetnike uloge radne postupke usluge koje prua neka organizacija Relacije meu klasama obino pripadaju jednom od etiri tipa, a to su generalizacija, asocijacija, agregacija i kompozicija. Kada imamo relaciju nasleivanja, nadklasa generalizuje podklasu. Dve klase su u asocijaciji ako se javljaju zajedno i ako ta veza mora se odri tokom odreenog vremena. Primer agregacije je kada je jedna klasa deo druge klase.

1 STANDARDI I PROCEDURE PROGRAMIRANJA Osim pisanja koda esto smo u situaciji da naknadno analiziramo svoj ili itamo tui kod zbog potrebe za promenom, kompletnom zamenom ili upotrebom koda u sklopu druge aplikacije. Samo pisanje koda najee podrazumeva uee veeg broja ljudi. Zbog toga je vano da i drugi mogu da shvate ta ste i zato napisali i kako se to uklapa u njihov deo posla. Standardi za vas: Standardi za druge: Uparivanje dizajna sa implementacijom: 2 SMERNICE ZA PROGRAMIRANJE Bez obzira na programski jezik, svak programska komponenta ukljuuje najmanje tri aspekta: kontrolne strukture, algoritme i strukture podataka. Kontrolne strukture: Vano je da struktura programa odraava kontrolne strukture definisane u sklopu dizajna. Standardi zahtevaju da se kod pie tako da komponenta moe lako da se proita, odozgo nadole. Naravno da nije uvek mogue da tok ide strogo odozgo nadole. Ali je korisno, gde god je to mogue, da zahtevana akcija bude neposredno nakon odluke koja je uslovljava. Modularnost koda je karakteristika dobrog programa. Ako je program sastavljen od modularnih blokova, sistem postaje razumljiviji za itanje i odravanje. Programsku komponentu moemo modularno posmatrati, a zatim koristiti makroe, procedure, potprograme,metode, nasleivanje kao sredstvo za skrivanje detalja uz poveanje stepena razumljivosti. to je komponenta koda modularnija, lake e se odravati i ponovo upotrebiti u drugim aplikacijama.Izmene se ograniavaju na konkretan modul. Kada se pie kod, treba izbegavati da on bude specijalizovan vie nego to je potrebno. Algoritmi: Dizajn programa esto definie klasu algoritama koju treba upotrebiti prilikom kodiranja komponente. Ali, postoji visok stepen slobode prilikom konvertovanja algoritma u kod, zavisno od ogranienja implementacionog programa i hardvera. Strukture podataka: Kada se piu programi, podatke bi trebalo formirati I uvati na takav nain da se njima jednostavno upravlja i manipulie. Postoji nekoliko tehnika u kojima se organizacija programa prilagoava strukturi podataka. Ouvanje jednostavnosti programa. Ponekad su u dizajnu programa definisane strukture podataka koje treba koristiti prilikom implementacije programa. Tako npr. struktuiranje podataka moe da uprosti izraunavanja uprogramu. Opte smernice Lokalizovanje ulaza i izlaza. Delovi programa koji uitavaju ulaz ili formiraju izlaz veoma su specijalizovani i moraju da odraavaju karakteristike osnovnog hardvera i softvera. Zbog te zavisnosti, ponekad je teko testirati delove programa koji obavljaju ulazne i izlazne funkcije. To su delovi koji e se verovatno menjati promenom hardvera i softvera. Prema tome, poeljno je da u komponentama ti delovi budu odvojeni od ostatka koda. Prednost lokalizacije je to u specijalizovanu komponentu mogu da se ukljue neke funkcije koje treba obaviti nad ulaznim podacima, tako da se ostale komponente rastereuju i izbegavaju ponavljanja. Ukljuivanje pseudokoda. Dizajn nije strogo vezan za programski jezik I ostavlja slobodu izbora jezikih sklopopva, naina njihove upotrebe, naina predstavljanja podataka I sl.Kako dizajn postavlja konture onog ta programska komponenta treba da uradi, korisno je da se od dizajna ka kodu ide u fazama, a ne da se dizajn odmah prevodi u kod. Za prilagoavanje dizajna izabranom programskom jeziku moe se upotrebiti pseudokod. Revidirati I ponovo pisati,ne krpiti. Kada se pie kod, najee se prvo napravi gruba skica, zatim se revidira I ponovo pie dok se ne postigne dobar rezultat. Ako se ini da je tok kontrole zamren ili da je postupak odluivanja teko razumeti, ili je teko ukloniti bezuslovna grananja, treba se vratiti na dizajn, pogledati ga ponovo I videti da li je problem posledica dizajna ili prevoenja u kod, pogledati kakva je struktura podataka, kakvi su algoritmi I razlaganja. Viekratna upotrebljivost. Postoje dve vrste viekratne upotrebljivosti: na strani proizvoaa, kada pravimo komponente koje su planirane za upotrebu u kasnijim aplikacijama; I na strani potroaa, kada koristimo komponente koje su prvobitno razvijene za druge projekte. Potroa, pre nego to upotrebi postojeu komponentu,treba da proveri etiri kljune karakteristike: Da li komponenta izvrava funkciju ili obezbeuje podatke koji su potrebni Ako je potrebna nekaizmena, da li je manje potrebno za promenu ili izgradnju nove komponente Da li je komponenta dobro dokumentovana tako da se moe potpuno razumeti bez potrebe da se verifikuje celokupna implementacija Postoji li potpuna evidencija o testiranju I revizijama komponente tako da moemo biti sigurni da u njoj nema greaka Takoe, mora se proceniti koliko koda treba napisati da bi sistem mogao da sarauje sa viekratno upotrebljivim komponentama. Proizvoai viekratno upotrebljivih komponenti treba da vode rauna o nekoliko stvari: neka komponente budu opte, neka koriste parametre I pretpostavljaju uslove sline onima u kojima ih sistempoziva razdvojiti delove koji su podloni promenama, od onih koji e verovatno ostati nepromenjeni neka interfejs komponente bude uopten I dobro definisan ukljuiti informacije o pronaenim I ispravljenim grekama koristiti jasne standarde za imenovanje dokumentovati strukture podataka I algoritme

3 DOKUMENTACIJA Programskom dokumentacijom smatra se skup opisa u pisanoj formi koji objenjavaju ta programi rade I kako to postiu. Unutranja dokumentacija podrazumeva opise koji se direktno upisuju u kod a sva ostala dokumentacija je spoljanja dokumentacija. Unutranja dokumentacija -Unutranja dokumentacija sadri informacije namenjene nekome ko e itati izvorni kod programa. Zaglavlje bloka komentara -daje kratak pregled za identifikaciju programa i opis njegovih struktura podataka. Ovaj deo sadri sledee informacije: 1 naziv komponente: 2 autor komponente 3 mesto komponente u celokupnom dizajnu sistema 4 kada je komponenta napisana odnosno revidirana 5 zato ta komponenta postoji 6 kako komponenta koristi svoju strukturu podataka, algoritme i tokove kontrole Ime komponente mora da bude uoljivo u dokumentaciji. Treba navesti autora, broj telefona, e-potu zbog eventualne komunikacije sa drugim lanovima tima. Tokom ivotnog ciklusa, komponente se mogu revidirati, bilo zbog ispravljanja greaka, bilo zbog proirenja zahteva. U programskoj dokumentaciji je potrebno da postoji evidencija izvrenih promena kao i imena autora promena. Kako je komponenta deo veeg sistema, dokumentacija bi trebala da ukae na mesto komponente u hijerarhiji komponenti. Zaglavlje bi trebalo da ukae na to kako se komponenta poziva. Za objanjenje kako komponenta izvrava svoj cilj, potrebne su detaljnije informacije. Trebalo bi navesti ime, tip i svrhu svake vee strukture podataka i promenljive kratak opis logikog toka, algoritama i obrade greaka oekovani ulaz i mogui izlaz pomona sredstva za testiranje i kako ih treba koristiti oekivana proirivanja i ili revizije Standardi firme obino definiu redosled i sadraj zaglavlja bloka komentara. Ostali komentari u programu. Dodatni komentari pomau itaocu koda da shvati kako su u kodu implementirane namere koje su opisane u zaglavlju. Ako su naredbe jasno formatirane, ako su oznake, imena promenljivih i imena podataka opisana i asocijativna, broj dodatnih komentara e biti mali. Komentari treba da prue dodatne informacije a ne da opisuju ono to je oigledno. Dokumentovanje podataka. Unutranja dokumentacija bi trebala da sadri opise strukture podataka i kako se podaci koristi. Spoljna dokumentacija je namenjena svum uesnicima, omoguava da se stvari opirnije objasne nego to je to mogue komentarima u programu. Spoljna dokumentacija komponenti ini deo sveobuhvatne dokumentacije sistema. Delovi dokumentacije komponenti su: Opis problema. U prvom odeljku dokumentacije koda treba objasniti problem koji komponenta raava. Opisuju se razlozi zbog kojih je izabrano konkretno reenje, a ne neka druga koja su bili u opciji. Opis problema nije ponavljanje dokumentacije zahteva, ve opti opis okvira sa objanjenjem kada se komponenta poziva i zato je ona potrebna. Opis algoritama. Poto je razjanjeno zato komponenta postoji, treba obrazloiti izbor algoritama. Zatim objasniti svaki algoritam koji se koristi u komponenti, ukljuujui formule, ogranienja i posebne uslove. Opis podataka. U spoljnoj dolumentaciji mora se videti tok podataka na nivou komponente.

ISPORUIVANJE SISTEMA OBUKA Sistem koristi dve vrste ljudi: korisnici I operateri. Vrste obuke Obuka korisnika Obuka operateta Specijalna obuka DOKUMENTACIJA Vrsta dokumentacije Korisniki prirunik Prirunici za operatere Opti vodi kroz sistem

TESTIRANJE PROGRAMA Sr testiranja je otkrivanje greaka I obezbedjenje da se kupcu isporui kvalitetan softver. 1 GREKE I SOFTVERSKI OTKAZI Otkazom softvera se smatra situacija kada softver ne radi ono to je opisano u zahtevima. Npr. podatak moe da vidi korisnik koji nije ovlaen za to. Uzroci nastanka otkaza mogu biti: Specifikacija pogrena ili u njoj nedostaje neki zahtev U specifikaciji postoji zahtev koji ne moe da se implementira sa propisanim hardverom ili softverom Postoji greka u dizajnu sistema Postoji greka u programskom kodu VRSTE GREAKA Algoritamska greka se javlja kada algoritam komponente, ili njegova logika, ne proizvode ispravan rezultat za dati ulaz, zato to neto nije u redu sa postupkom obrade. Te greke se ponekad lako otkrivaju itanjem programa ili pravljenjem ulaznih podataka iz svih razliitih klasa podataka za koje se oekuje da se mogu pojaviti pri normalnom radu programa. Uobiajene algoritamske greke mogu biti: grananje pre vremena prekasno grananje ispitivanje pogrenog uslova poetnoj vrednosti njije dodeljena vrednost podeavanje uslova petlje propust pri ispitivanju konkretnog uslova(deljenje nulom) operacije sa promenljivim razliitog tipa sintaksna greka Greke izraunavanja I greke preciznostinastupaju kada se formula pogreno implementira ili kada ne izraunava rezultat sa zahtevanom preciznou. Kada se kombinuju izraunavanja u kojima uestvuju celobrojne vrednosti I vrednosti sa pokretnim zarezom moe doi do neoekivanih rezultata. Greka dokumentacije nastaje kada dokumentacija ne odgovara onome to program zaista radi. Greke preoptereenja nastaju kada se broj korisnika u sistemu poveava preko navedenog kapaciteta. Greke kapaciteta nastaju kada vrednost premauje kapacitet polja u strukturi podataka. Greke vremenskog rasporeda ili greke koordinacije nastaju kada se vie procesa odvija istovremeno ili po strogo uredjenom redosledu, a kod koji vri koordinaciju tih procesa nije odgovarajui. Greke propusnosti ili performansi nastaju kada sistem ne omoguava performanse I brzinu specifikovanu u zahtevu. Greke oporavka mogu da nastanu kada nastupi greka a sistem ne reaguje kako je predvidjeno zahtevom, npr.da vrati datoteke na stanje pre otkaza. Hardverske greke I greke sistemskog softvera nastaju kada isporueni hardver ili sistemski softver ne funkcioniu u skladu sa dokumentovanim operativnim uslovima I procedurama 2 PITANJA TESTIRANJE ORGANIZACIJA TESTIRANJA Kada se razvija veliki sistem, testiranje obino zahteva vie faza. Prvo se zasebno testira svaka programska komponenta, nezavisno od ostalih delova sistema. Takvim testiranjem, koje se naziva testiranje modula ili jedinino testiranje, proverava se da li pojedinane komponente ispravno funkcioniu sa svim oekivanim tipovima ulaza, u skladu sa dizajnom komponente.Nastoji se da se jedinino testiranje vri u kontrolisanom okruenju, tako da tim za testiranje moe komponenti koja se testira da predaje unapred definisan skup podataka, I da posmatra izlazne rezultate. osim toga, tim za testiranje proverava unutranju strukturu podataka, logoku I granine uslove za ulazne I izlazne podatke. Kada se zavri jedinino testiranje skupa komponenti, sledei korak je proveravanje da li su interfejsi izmedju komponenti pravilno definisani I realizovani. Intgraciono testiranje je postupak proveravanja da li sistemske komponente saradjuju kao to je opisano u specifikacijama dizajna sistema I programa. Poto se utvrdi da se izmedju komponenti informacije prenose u skladu sa dizajnom, testira se sistem da bi se proverilo ima li on eljenu funkcionalnost. Funkcionalnim testiranjem se proverava da li integralni sistem zaista izvrava funkcije opisane u specifikaciji zahteva. Kao rezultat dobija se sistem koji funkcionie. 3 JEDININO TESTIRANJE Prvo se ita programski kod I trae greke u algoritmu, podacima I sintaksi. Moe se uporediti kod sa specifikacijom I dizajnom da se vidi da li su uzeti svi relevantni sluajevi. Zatim se prevodi kod I otklanjaju preostale greke sintakse. Na kraju se prave sluajevi za testiranje da li se ulaz pravilno konvertuje u eljeni izlaz. 4 INTEGRACIONO TESTIRANJE Poto je zavreno jedinino testiranje, prelazi se na integraciono testiranje. Sistem se posmatra kao hijerarhija komponenti, gde svaka komponenta pripada nekom sloju dizajna. Tokom testiranja mogue je ii od vrha prema dole, mogue je ii odozdo nagore ili kombinovati oba pristupa. Kada se koristi metod testiranje odozdo nagore, prvo se jedinino testira svaka komponenta na najniem nivou hijerarhije sistema. Zatim se testiraju komponente koje pozivaju prethodno testirane komponente. Taj postupak se ponavlja sve dok testiranjem ne budu obuhvaene sve komponente sistema. Ovaj metod je koristan kada veina komponenti na najniem nivou predstavlja pomone rutine opte namene koje se pozivaju iz drugih komponenti, kod objektno orijentisanog dizajna ilikada sistem integrie vei broj nezavisnih ponovi iskoristivih komponenti.

5 PLANIRANJE TESTA Sledei koraciu procesu testiranja treba da budu isplanirani: 1 utvrdjivanje ciljeva testiranja 2 dizajn sluajeva 3 pisanje sluajeva 4 testiranje sluajeva 5 izvravanje testova 6 ocenjivanje rezultata testiranja TESTIRANJE SISTEMA Proces testiranja sistema se sastoji od nekoliko koraka: Funkcionalno testiranje Testiranje performanse Testiranje prihvatanja Instalaciono testiranje FUNKCIONALNI TEST Testiranje sistema poinje od funkcionalnog testa, zanemaruje se struktura sistema I usrsredjuje se na funkcionalnost. Funkcionalni test se zasniva na funkcionalnim zahtevima sistema. Svakoj funkciji se mogu pridruiti one komponente koje je izvravaju. Za neke funkcije to moe obuhvatiti I ceo sistem. Skup aktivnosti pridruen jednoj funkciji se naziva nit, pa se funkcionalno testiranje ponekad naziva testiranje niti. U efikasnom funkcionalnom testiranju verovatnoa otkrivanja greaka je visoka. Smernice za funkcionalno testiranje su: visoka verovatnoa otkrivanja greaka tim za testiranje nezavisan od projektanata I programera poznate oekivane akcije I izlaz testiranje ispravnih I neispravnih ulaza sistem se nikad ne menja da bi se testiranje olakalo definisani kriterijumi zavretka U funkcionalnom testiranju se sistem poredi sa zahtevima, zato se sluajevi za funkcionalno testiranje prave na osnovu specifikacije zahteva. VRSTE TESTOVA PERFORMANSE Vrste testova performanse se odredjuju prema vrstama nefunkcionalnih zahteva. Testovi optereenja ocenjuju sistem kada se on optereti do svojih granica u kratkom vremenskom periodu. Ako u zahtevima stoji da sistem treba da najvie odredjen broj korisnika ili uredjaja, test optereenja ocenjuje performanse sistema kada su istovremeno aktivni svi ti uredjaji I korisnici. Ovaj test je posebno znaajan za sisteme koji najee funkcioniu ispod svog maksimumalnog optereenja ali su u nekim vrnim situacijama estoko optereeni. Testovi kapaciteta posmatraju obradu velike koliine podataka u sistemu. Npr. gleda se da li su strukture podataka definisane dovoljno iroko da mogu da prihvate sve podatke, proveravaju se polja i datoteke da li e moi da prime sve oekivane rezultate. Proverava se da li sistem reaguje pravilno kada skupovi podataka dosegnu svoj maksimum. Testovi konfiguracije analiziraju razliite softverske I hardverske konfiguracije navedene u zahtevima. Test konfiguracije ocenjuje sve mogue konfiguracije I proverava da li svaka od njih zadovoljava zahteve. Testovi kompatibilnosti su potrebni kada sistem ima interfejsove prema drugim sistemima. Ispituje se da li se funkcije interfejsa izvravaju u skladu sa zahtevima. Testovi bezbednosti proveravaju da li su zadovoljeni bezbednosni zahtevi, testira se dostupnost, integritet I poverljivost podataka. Testovi oporavka ispituju reagovanje sistema na prisustvo greaka ili na gubitak podataka, napajanja, uredjaja ili usluga. Sistem se izlae gubitku sistemskih resursa, a zatim posmatra da li se on pravilno oporavlja. Testovi ljudskih faktora istrauju zahteve koji se tiu interakcije korisnika sa sistemom. Ispituje se izgled ekrana, poruke, formati izvetaja I druge karakteristike koje mugu da utiu na lakou korienja. TESTIRANJE PRIHVATLJIVOSTI Kada se zavri funkcionalno testiranje I testiranje performansi, zna se da sistem zadovoljava sve zahteve definisane u pietnoj fazi razvoja softvera. Sledei korak je pitati kupca I korisnike da li se oni sa tim slau. Sada kupac vodi testiranje I definie sluajeve koji e se testirati. Svrha testa prihvatljivosti jest da se kupcima I korisnicima omogui da utvrde da li sistem koji je napravljen zadovoljava njihove zahteve I oekivanja. Nakon testiranja prihvatljivosti, kupac izvetava koji zahtevi nisu ispunjeni , a koje treba izbrisati, revidirati ili dodati zbog promenjenih uslova. Osoblje koje upravlja konfiguracijom identifikuje ove promene I evidentira potrebne modifikacije dizajna, implementacije I testiranja. INSTALACIONI TEST Sam kraj testiranja predstavlja instaliranje sistema na lokaciji korisnika. Ako je test prihvatljivosti izveden na lokaciji korisnika, instalacioni test moda nije ni potreban. Medjutim, ako uslovi testiranja prihvatljivosti nisu bili identini uslovima kod korisnika, potrebno je dodatno testiranje. Za poetak instalacionog testa konfigurie se sistem prema korisnikom okruenju, povezuje se odgovarajui uredjaji sa glavnim procesorom I uspostavlja komunikacija sa drugim sistemima. Alociraju se datoteke I dodeljuje pristup odgovarajuim funkcijama I podacima. Test sluajevi uveravaju kupca da je sistem potpun I da su prisutne sve datoteke I uredjaji. Testovi su usresredjeni na dve stvari: da li je instalirani sistem potpun I da li uslovi na lokaciji utiu na neke funkcionalne ili nefunkcionalne karakteristike. Kada kupac bude zadovoljan rezultatima, testiranje se zavrava I sistem se formalno isporuuje.