Softversko Inženjerstvo Elektronski Fakultet, Ispiti' predlog Informatika. Anton de Kom University
davitko23
davitko23
Questo è un documento Store
messo in vendita da davitko23
e scaricabile solo a pagamento

Softversko Inženjerstvo Elektronski Fakultet, Ispiti' predlog Informatika. Anton de Kom University

PDF (2 MB)
30 str.
248broj poseta
Opis
Materijal sa Predavanja iz Softverskog Inženjerstva na Elektronskom Fakultetu u Nišu
2.99
Cena dokumenta
preuzmi dokument
Questo documento è messo in vendita dall'utente davitko23: potrai scaricarlo in formato digitale subito dopo averlo acquistato! Più dettagli
pregled3 str. / 30
ovo je samo pregled
3 prikazano na 30 str.
preuzmi dokument
ovo je samo pregled
3 prikazano na 30 str.
preuzmi dokument
ovo je samo pregled
3 prikazano na 30 str.
preuzmi dokument
ovo je samo pregled
3 prikazano na 30 str.
preuzmi dokument

1. Uvod u Sofversko !!! SOfTveR - Softver je računarski program, pridružena dokumentacija i konfiguracioni podaci neophodni da bi softver radio korektno. SOfTveRSki SiSTeM Se SaSTOji Od : određenog broja programa; konfiguracionih fajlova, koji se koriste da postave ove programe; sistemske dokumentacije, koja opisuje strukturu sistema; korisničke dokumentacije, koja objašnjava kako se koristi sistem; Web sajtova za korisnike, odakle mogu download-ovati najsvežije informacije o proizvodu. Softversko inženjerstvo se bavi razvojem softverskih proizvoda; softvera koji se može prodati kupcima. TipOvi SOfTveRSkOg pROizvOda - dva osnovna tipa: 1) Generički (Generic) – samostalni sistemi razvijeni da bi se prodavali na slobodnom tržištu svakome ko može da ih kupi. Npr. Word procesori, paketi za crtanje, sistemi za upravljanje bazama podataka,... 2) Ugovorni (bespoke, custom) – razvijeni za jednog korisnika prema njegovim zahtevima. Npr. Sistemi za kontrolu avio saobraćaja, sistemi za upravljanje elektranama, ... Osnovna razlika je ko diktira šta će se raditi (specifikacija)- Generički – organizacija koja razvija sistem; • Ugovorni – naručilac, a razvojni tim radi po toj specifikaciji. ŠTa je SOfTveRSkO inženjeRSTvO - Softversko inženjerstvo je inženjerska disciplina koja se bavi teorijom, metodama i alatima za profesionalni razvoj softvera. Softversko inženjerstvo je inženjerska disciplina koja obuhvata sve aspekte proizvodnje softvera. Softver inženjeri treba da prihvate sistematski i organizovan način u svom radu i da koriste odgovarajuće alate i tehnike zavisno od problema koji rešavaju, ograničenja na koja nailaze u toku razvoja i raspoloživih resursa. Razlike izMeđu SOfTveRSkOg inženjeRSTva i infORMaTike - Nauka o računarstvu ili Informatika (Computer science) se bavi teorijom i osnovama računarstva. Softversko inženjerstvo se bavi praktičnom stranom razvoja i isporuke korisnog softvera. Teorija nauke o računarstvu je trenutno dovoljno razvijena i obezbeđuje solidnu osnovu za softversko inženjerstvo. Razlike izMeđu SOfTveRSkOg i SiSTeMSkOg inženjeRinga - Sistemski inženjering (System engineering) se bavi svim aspektima razvoja sistema zasnovanih na računarima, uključujući hardverski, softverski i procesni inženjering. Softversko inženjerstvo je deo tog procesa . Sistem inženjeri (System engineers) su uključeni u aktivnostima specificiranja sistema, arhitekturnog projektovanja, integracije i isporuke sistema. Sistemski inženjering je starija disciplina od SW Inženjeringa. SOfTveRSki pROceS - Softverski proces je skup aktivnosti i pridruženih rezultata čiji je cilj proizvodnja softvera. Aktivnosti zajedničke za sve softverske procese su: 1) Specifikacija softvera (Sofware Specification) – gde klijenti i softver inženjeri definišu softver koji treba da se proizvede i ograničenja pod kojima će raditi 2)Razvoj softvera (Software Development) – gde se softver projektuje i programira 3) Validacija softvera (Sofware Validation) – gde se proverava da je proizveden softver kakav je naručilac (kupac) zahtevao 4) Evolucija softvera (Software Evolution) – gde se softver modifikuje da bi se prilagodio promenjenim zahtevima naručioca i tržišta. Različiti tipovi sistema zahtevaju različite procese razvoja – kod njih su zajedničke aktivnosti organizovane na različite načine. MOdel SOfTveRSkOg pROceSa - Model softverskog procesa je uprošćena reprezentacija softverskog procesa koja predstavlja jedan pogled na ovaj proces. Modeli procesa uključuju: 1) Aktivnosti procesa 2) Softverske proizvode 3) Uloge ljudi koji učestvuju u softverskom procesu. Primeri tipova modela softverskih procesa: 1) Model radnih tokova (Workflow model) - Prikazuje se sekvenca aktivnosti u procesu zajedno sa ulazima. Izlazima i zavisnostima sekvenca aktivnosti – Akcije u ovom modelu su akcije čoveka. 2) Model toka podataka ili model aktivnosti (Dataflow or activity model) – Predstavlja proces kao skup aktivnosti, pri čemu se svaka aktivnost bavi nekom transformacijom podataka – Ove aktivnosti mogu voditi ili ljudi ili računari. 3) Model uloga/akcija (Role/action model) – Predstavlja uloge ljudi koji učestvuju u SW procesu i aktivnosti za koje su oni odgovorni – Definiše ko šta radi OpšTi MOdeli ili paRadigMe: Mnogi modeli softverskog procesa su zasnovani na jednom od tri opšta modela ili paradigmi razvoja softvera: 1) Vodopad prilaz (Waterfall approach): a) Aktivnosti predstavljaju posebne faze u ovom modelu b) Po završetku svake faze se usvaja dokument i tada se ide na sledeću fazu 2) Iterativni razvoj (Iterative Development): Aktivnosti specifikacija zahteva, razvoj i validacija se prepliću. Inicijalni sistem se vrlo brzo razvija na osnovu vrlo apstraktne specifikacije. Zatim se u saradnji sa kupcem zahtevi detaljišu i sistem u više iteracija razvija do konačnog izgleda. Na komponentama zasnovano softversko inženjerstvo (Component-based software engineering, CBSE). Polazi se od pretpostavke da delovi sistema već postoje. Model se koncentriše na integraciju tih delova u celinu. TROškOvi Sw inženjeRinga - Grubo 60% troškova su razvojni troškovi, 40% troškovi testiranja. Za korisnički softver, troškovi evolucije prelaze često troškove razvoja. Troškovi variraju zavisno od tipa sistema koji se razvija i zahtevanih atributa sistema, kao što su performanse i pouzdanost sistema. Distribucija troškova zavisi od korišćenog modela

razvoja. MeTOde SOfTveRSkOg inženjeRinga - To su strukturni prilazi razvoju softvera koji uključuju opise modela sistema, notacije, pravila, savete za projektovanje i vodič kroz proces. Metode obuhvataju: 1) Opise modela 2) Opisi grafičkih modela koji nastaju u toku razvoja – Pravila 3) Ograničenja primenjena na model sistema – Preporuke 4) Saveti za dobro projektovanje – Vodič kroz proces 5) Kako teku aktivnosti. CASE (Computer-Aided Software Engineering) - CASE je softverski sistem koji je namenjen pružanju automatske podrške aktivnostima softverskog procesa. CASE sistemi se često koriste kao podrška za konkretnu metodu ili grupu metoda. CASE višeg nivoa (Upper-CASE) – Alati koji podržavaju rane aktivnosti procesa, faze inženjeringa zahteva i projektovanja. CASE nižeg nivoa (Lower-CASE) – Alati koji podržavaju kasnije aktivnosti, kao što su programiranje, debagiranje i testiranje. ATRibuTi dObROg SOfTveRa - Softver treba da ima funkcionalnost i performanse saglasno zahtevu korisnika. Takodje, mora biti pogodan za održavanje, da je upotrebljiv i da uliva poverenje. 1) Pogodnost za održavanje (Maintainability) – Treba da je u stanju da se lako menja. 2) Stabilnost (Dependability) – Softver mora ulivati poverenje, što podrazumeva da je softver pouzdan (reliability), bezbedan ( security) i siguran (safety) 3) Efikasnost (Efficiency) – Softver mora ekonomično koristiti resurse sistema (procesorsko vreme, memoriju). 4) Upotrebljivost (Usability) – Softver mora biti ugodan za korišćenje, da ima odgovarajući korisnički interfejs i adekvatnu dokumentaciju. IzazOvi SOfTveRSkOg inženjeRinga - Kako se izboriti sa: postojećim sistemima (legacy systems), sve većom raznovrsnošću, i zahtevima da se skrati vreme izrade softvera. Postojeći sistemi (Legacy systems) - Stare, vredne sisteme treba održavati i ažurirati. Raznovrsnost (Heterogeneity) - Sistemi su distribuirani i uključuju raznovrstan hw i sw. Isporuka (Delivery) – Postoji sve veći pritisak da se softver isporuči što je moguće brže. PROfeSiOnalna i eTička OdgOvORnOST – 1) Softver inženjeri imaju šire odgovornosti od proste primene tehničkih veština 2) Softver inženjeri moraju negovati etičku odgovornost kako bi bili respektovani kao profesionalci 3) Etičko ponašanje je više od prostog pridržavanja zakona. EleMenTi pROfeSiOnalne OdgOvORnOSTi - 1) Poverljivost – Inženjeri bi trebalo da respektuju poverljivost svojih zaposlenih ili klijenata bez obzira na to da li je formalno potpisan neki dokument o tome. 2) Kompetentnost – Inženjeri ne bi trebalo da pogrešno predstavljaju svoju kompetentnost. Ne bi trebalo da prihvataju poslove koji su van njihove kompetencije 3) Prava intelektualne svojine – Inženjeri bi trebalo da su obavešteni o lokalnim zakonima o korišćenju intelektualne svojine kao što su patenti, prava kopiranja, itd. Moraju osigurati zaštitu intelektualnih prava njihovih zaposlenih i klijenata. 4) Zloupotreba računara – SW inženjeri ne bi trebalo da koriste svoje tehničke veštine za zloupotrebu računara drugih ljudi. Zloupotreba može varirati od trivijalne (npr. Korišćenje računara zaposlenih za igrice) do vrlo ozbiljnih (diseminacija virusa). 2. SISTEMSKI INŽENJERING !!! Sistemsko inženjerstvo - Projektovanje, implementacija, isporuka i eksploatacija sistema koji uključuju HW, SW i ljude. Sistem : Kolekcija medjusobno povezanih komponenti koje rade zajedno radi ostvarenja nekog zajedničkog cilja. obuhvata HW, SW i ljude. Sistem obuhvata SW, HW (mehaničke, električne i elektronske komponente) i ljude. Svojstva i ponašanje svake komponente ponaosob utiče na ostale komponente sistema. Primer sistema: Olovka – vrlo prost sistem koji ima 3 ili 4 HW komponente. ATC (Air Traffic Control) sistem im na hiljade SW I HW komponenti plus korisnici koji donose odluke na osnovu informacija iz računarskog sistema. Kategorije sistema: Sistemi koji uključuju SW spadaju u dve kategorije: Tehnički sistemi zasnovani na računaru; Socio- tehnički sistemi Tehnički sistemi zasnovani na računaru - To su sistemi koji uključuju HW i SW komponente ali ne uključuju procedure i procese. Primeri teh. Sis.: televizor, mobilni telefon i PC SW. Pojedinci i organizacije koriste ove sisteme za neke namene ali znanje o tim namenama nije ugrađeno u tehnički sistem. Socio-tehnički sistemi - To su sistemi koji uključuju jedan ili više tehničkih sistema, ali takođe i znanje o tome kako koristiti sistem da bi se postigao cilj. Ovi sistemi definišu radne procese, uključujući operatere kao inherentni deo sistema, koji su prilagođeni poslovnim i drugim procesima organizacije kojoj su namenjeni. Primeri socio-tehničkih sis.: Sistem za publikovanje; Satelitska stanica Problemi sistemskog inženjeringa - Veliki sistemi se obično projektuju da bi rešili “nezgodne” probleme. Sistemski inženjering zahteva koordinaciju velikog broja disciplina. Postoji gotovo beskonačno mnogo alternativa za svaki problem. Postoji uzajamno nerazumevanje medu različitim inženjerskim disciplinama. Softversko i sistemsko inženjerstvo - Udeo SW u sistemu je sve veći. Problemi sistemskog inženjerstva su slični problemima softverskog inženjerstva. SW se nažalost vidi kao problem u

sistemskom inženjerstvu. Mnogi veliki projekti sistema su kasnili zbog problema sa SW Dodatna svojstva sistema: Svojstva sistema kao celine. Dodatna svojstva su posledica veza među komponentama sistema. Mogu se utvrditi i meriti tek nakon integracije komponenti u sistem. Primeri: Ukupna težina sistema (Ovo je primer dodatnog svojstva koje se može izračunati na osnovu svostva pojedinih komponenti), Pouzdanost (Pouzdanost sistema zavisi od pouzdanosti komponenti sistema i veza među komponentama), Upotrebljivost (Ovo je složeno svojstvo koje ne zavisi samo od HW i SW sistema već i od operatera sistema i okruženja gde se sistem koristi. Mere se nakon integracije komponenti u sistem.) Tipovi dodatnih svojstva: Funkcionalna (Javljaju se kada svi delovi sistema rade zajedno da bi ostvarili neki cilj - bicikla) i nefunkcionalna (Odnose se na ponašanje sistema u radnom okruženju. Primeri nefunkcionalnih svojstava su pouzdanost, performanse, sigurnost i bezbednost. Obično su kritični za sistem zasnovan na računaru). Pouzdanost sistema: Pouzdanost HW: Kolika je verovatnoća da HW komponenta bude neispravna i koliko dugo traje reparacija te komponente?; Pouzdanost SW: Koliko je verovatno da će neka SW komponenta proizvesti neispravan izlaz. SW neispravnost se razlikuje od HW po tome što se softver ne može istrošiti (pohabati); Pouzdanost operatera: Kolika je verovatnoća da operater sistema načini grešku? Veze među komponentama pouzdanosti: Sve ove komponente pouzdansoti su vrlo blisko povezane i utiču jedna na drugu. HW neispravnosti mogu generisati signal koji je van opsega ulaza koji očekuje SW. SW greške mogu aktivirati alarm koji može delovati stresno na operatera i koji zbog toga može pogrešiti. Okruženje u kome je sistem instaliran može uticati na njegovu pouzdanost. "Shall-not" svojstva: Svojstva kao što su performanse i pouzdanost se mogu meriti. Međutim, postoje svojstva sistem koja sistem ne može pokazati: Sigurnost; Bezbednost. Merenje ili utvrđivanje ovih svojstava je veoma teško. Sistemi i njihova okruženja: Sistem nije nezavistan, on radi u nekom okruženju: Funkcije sistema mogu menjati okruženje. Takođe, okruženje utiče na funkcionisanje sistema. Na primer, sistem zahteva iz okruženja napajanje. Važno je i organizaciono i fizičko okruženje. Ljudski i organizacioni faktori: Promene procesa – Da li sistem zahteva promene radnih procesa u okruženju?; Promene posla – Dali sistem zahteva od korisnika da menjaju način rada i nova znanja? Organizacione promene – Da li sistem menja organizaciju posla? Modeliranje arhitekture sistema: Arhitekturni model predstavlja apstraktni pogled na podsisteme koji čine sistem. Obično se predstavlja blok dijagramima. Može uključiti glavne tokove podataka među Podsistemima. U modelu se mogu identifikovati različiti tipovi funkcionalnih komponenti Komponente sistema: Komunikacione (mreža), koordinacione (planer), interfejsne (interfejs). Proces sistemskog inženjerstva: Definisanje zahteva, projektovanje sistema, razvoj podsistema, integracija sistema, instalacija sistema, evolucija sistema, rasturanje sistema. Obično se koristi model vodopada buduće da treba paralelno razvijati različite delove sistema. Mali je broj iteracija između faza jer su promene HW komponenti vrlo skupe. SW mora kompenzovati HW probleme. Neizbežno uključivanje inženjera iz različitih disciplina koji moraju raditi zajedno. Veliki prostor za nesporazume i nerazumevanje. Različite discipline koriste različiti rečnik pa je potrebno mnogo dogovaranja. Svaki inženjer mora imati personalno zaduženje. Definisanje zahteva: U ovom koraku se definišu tri vrste zahteva: Apstraktni funkcionalni zahtevi (Funkcije sistema se definišu na apstraktan način), svojstva sistema (def. nefunkcionalni zahtevi za sistem uopšteno) i nepoželjne karakteristike (Specificira se neprihvatljivo ponašanje sistema). Treba definisati i organizacione ciljeve sistema kao celine. Ciljevi sistema: Funkcionalni ciljevi (Da u zgradi obezbedi alarmni sistem protiv požara i provale), organizacioni ciljevi (Da u zgradi osigura normalno funkcionisanje radnog procesa, odnosno da požar i provala ne poremete ozbiljno ovaj proces). Problemi sistemskih zahteva: Menjaju se nakon specificiranja sistema. Moraju se predvideti promene koje donose nove HW i komunikacione tehnologije u toku životnog veka sistema. Teško je definisati nefunkcionalne zahteve bez nekakve prestave o strukturi sistema Projektovanje sistema: podela zahteva, identifikovanje podsistema, vezivanje zahteva za podsisteme, specificiranje funkcionalnosti podsistema i definisanje interfejsa podsistema (kritična aktivnost). Podela zahteva – Organizovati zahteve u grupe srodnih zahteva; Identifikovati podsisteme – Identifikovati skup podsistema koji zajedno mogu ostvariti sistemske zahteve. Vezivanje zahteva za podsisteme – Izaziva partikularne probleme kada se integrišu gotove komponente (COTS). Specificiranje funkcionalnosti podsistema. Definisanje interfejsa podsistema – Kritična aktivnost za paralelni razvoj podsistema.

Problemi projektovanja sistema: Podela zahteva na HW, SW i ljudske komponente zahteva mnogo dogovaranja. Teški projektantski problemi se često SW rešavaju. HW platforme mogu biti neodgovarajuće za SW zahteve tako da softver to mora kompenzovati. Birokratizacija i spori mehanizam za predlaganje promena sistema može dovesti do toga da se planirano vreme razvoja prekorači Razvoj podsistema: HW, SW i komunikacione komponente se paralelno razvijaju, može zahtevati nabavku gotovih komponenti. Problem nedostatak komunikacije unutar tima. Integracija sistema: Objedinjavanje komponenti u jedan sistem. U ovom koraku se otkrivaju problemi u interfejsu među komponentama. Treba ga izvesti inkrementalno, tj. Integrisati jednu po jednu komponentu. Može biti problem u ne koordiniranoj isporuci pojedinih komponenti sistema. Instaliranje sistema: Nekorektne pretpostavke o okruženju mogu biti problem. Otpor ljudi za novi sistem potencijalan, zato on treba jedno vreme da radi sa postojećim. Mogu biti fizički problemi u instalacijama (npr. Problem kabliranja). Treba identifikovati obuku operatera Eksplatacija sistema: Mogu se pojaviti novi zahtevi, može se koristiti sistem na nepredviđen način. Može se javiti problem u interakciji sa drugim sistemima: Fizički problemi nekompatibilnosti; Problemi konverzije podataka; Povećane greške operatera zbog neodgovarajućeg interfejsa. Evolucija sistema: Veliki sistemi imaju dug životni vek. Oni moraju evoluirati da bi zadovoljili nove zahteve. Skupa, promene analizirati sa tehničke i poslovne strane. Mogu se javiti problemi u podsistemima koji interaguju sa sistemom koji se menja. Kada se promene unose narušava se struktura sistema. Postojeći sistemi koji se moraju održavati se zovu legacy systems. Rasturanje sistema: Staviti sistem van upotrebe nakon što se završi njegov životni vek. Potencijalno odlaganje materijala da ne zagađuje okolinu, potencijalna rekonstrukcija ili upotrebljavanje rasturenih delova. Može se zahtevati rekonstrukcija i konverzija podataka na drugi sistem Nabavka sistema: Traženje sistema koji zadovoljava potrebe organizacije. Pre nabavke je neophodno izvesti u nekom obliku specificiranje i arhitekturno projektovanje sistema. Potrebna vam je specifikacija da bi ste ugovorili razvoj sistema. Specifikacija vam može omogućiti kupovinu komercijalnih COTS sistema. Gotovo uvek je to jeftinije nego razvijati sistem. Istraživanje-> (ako ima gotovog sistema) Adaptiranje zahteva, izbor sistema, traženje ponuda, izbor dobavljača. (Ako nema )Objavljivanje tendera, Selekcija tendera, Ugovaranje, Potpisivanje ugovora. Problemi nabavke: Možda je potrebno modifikovati zahteve da bi se prilagodili mogućnostima COTS Komponenti. Specifikacija zahteva može biti deo ugovora za razvoj sistema. Obično postoji period rada na ugovoru da bi se naručilac i izvođač usaglasisli kakav sistem razvijati Zaključak: Sistemsko inženjerstvo je teško! Ne postoji nikada lak odgovor na probleme razvoja složenih sistema. Softversko inženjerstvo ne treba da ima sve odgovore ali je bolje ako se koristi sistemski pogled. U sistemskom inženjerstvu nužna je kooperacija različitih disciplina process. 3. Softverski provesi !!! SOfTveRSki pROceSi - Softverski proces je skup aktivnosti za razvoj softverskog sistema. Aktivnosti zajedničke za sve SW procese: 1) Specifikacija – definiše funkcionalnost sw i ograničenja 2) Projektovanje i implementacija – proizvodi se SW koji zadovoljava specifikaciju. 3) Validacija – provera da li je proizveden SW prema specifikaciji 4) Evolucija – SW evoluira prateći evoluciju zahteva. MOdel SOfTveRSkOg pROceSa - je apstraktna reprezentacija procesa. Predstavlja opis procesa iz određene perspektive. Generički modeli softverskog procesa: a) Model vodopada – Odvojene faze specifikacije i razvoja; b) Evolutivni razvoj – Specifikacija i razvoj se prepliću; c) Formalni razvoj sistema – Matematički model sistema se formalno transformiše u implementaciju. d) Softversko inženjerstvo zasnovano na komponentama – Sistem se sklapa od postojećih komponenti. MOdel vOdOpada - Faze modela vodopada: 1) Analiza i definicija zahteva: a) Servisi, ograničenja i ciljevi sistema se postavljaju u saradnji sa korisnikom b) Zatim se to definiše detaljni i to služi kao specifikacija sistema 2) Projektovanje sistema i softvera: a) Zahtevi se dele na SW i HW b) Postavlja se arhitektura celog sistema c) Projektovanje SW obuhvata identifikovanje komponenti i njihovih veza 3) Implementacija i komponentno testiranje: a) Pišu se i programske komponente b) Testiraju se programi i komponente radi provere da li su saglasni sa specifikacijom 4) Integrisanje i testiranje sistema: a) Programi i programske komponente se integrišu i testira se sistem kao celina radi provere da li je usklađen sa SW zahtevima. B) Nakon toga se sistem isporučuje –5) Eksploatacija i održavanje: a)

Nakon puštanja sistema u eksploataciju nastaje njegova evolucija: a) Nedostaci modela vodopada b) Nefleksibilna podela projekta u faze – Teško je prihvatiti promene zahteva korisnika. Preporuka: Ovaj model je

jedino pogodan kada su zahtevi dobro poznati. EvOluTivni RazvOj - Zasniva se na ideji da se razvije inicijalna implementacija, da se ona pruži na uvid korisniku i da se na osnovu komentara korisnika vrši revizija i da se kroz više verzija dođe do konačnog rešenja. Postoje dva osnovna tipa evolutivnog razvoja: 1) Istraživački razvoj: Cilj je raditi sa klijentima i evolucijom doći do finalnog sistema polazeći od kratke inicijalne specifikacije. Startuje se sa dobro shvaćenim zahtevima. 2) Prototipovanje sa odbacivanjem prototipova: a) Evolutivni razvoj služi da se dobro shvate zahtevi korisnika i da se potom razvije bolja definicija sistemskih zahteva b) Startuje se sa slabo shvaćenim zahtevima. Problemi: Proces nije vidljiv; Sistemi su obično slabo struktuirani; Mogu biti potrebne specijalne veštine (npr. Jezici za brzo prototipovanje), Aplikativnost Za male i srednje (do 500 000 linija koda) interaktivne sisteme. Za delove velikih sistema (npr. za korisnički interfejs). Za sisteme sa kratkim životnim vekom.

FORMalni RazvOj SiSTeMa - Zasniva se na transformaciji matematičke specifikacije kroz različite reprezentacije do izvršnog programa. Transformacije se izvode bez grešaka tako da je lako dokazati da softver zadovoljava specifikaciju. Ugrađen u ‘Cleanroom’ prilaz razvoju softvera. Problemi: Potrebne su specijalne veštine i obuka za primenu ove tehnike. Neke aspekte sistema je teško formalno specificirati (npr. korisnički interfejs). Aplikativnost: Kritični sistemi posebno oni gde se mora osigurati sigurnost i bezbednost pre puštanja sistema u rad.

SW inženjerstvo zasnovano na komponentama, Razvoj orijentisan ka ponovnom korišćenju - Bazira se na sistematskom ponovom korišćenju komponenti ili gotovih sistema, pa se novi sistem razvija tako što se integrišu postojeće komponente ili postojeći sistemi – COTS systems.

ITeRacija pROceSa - Sistemski zahtevi uvek evoluiraju sa napredovanjem projekta tako da je iteracija procesa (ponavljanje ranije izvedenih koraka) prisutna u procesu razvoja svih velikih sistema o Iteracija se može primeniti na bilo kom generičkom modelu softverskog procesa o Poznata su dva prilaza – Inkrementalni razvoj (Incremental development) – Spiralni razvoj (Spiral development) InkReMenTalni RazvOj - Umesto da se sistem isporuči odjedanput, razvoj i isporuka se mogu razdeliti u inkremente pri čemu svaki inkrement obezbeđuje deo tražene funkcionalnosti. Korisnički zahtevi se razvrstavaju po prioritetu i inkrementi se definišu tako da ranije isporučeni inkrementi obuhvate prioritetnije zahteve. Kada startuje razvoj inkrementa zamrzavaju se zahtevi koji su ugrađeni u taj inkrement dok ostali zahtevi mogu dalje evoluirati. Koraci procesa: 1. Definisanje okvirne specifikacije; 2. Dodela zahteva inkrementima; 3. Projektovanje arhitekture sistema 4. Razvoj inkrementa sistema; 5. Validiranje inkrementa; 6. Integrisanje inkrementa; 7. Validiranje sistema; Koraci 4-7 se ponavljaju dok se ne razvije ceo sistem. PRednOSTi inkReMenTalnOg RazvOja - Klijent ranije dobija neke funkcionalnosti sistema čime se stiče njegovo poverenje i on se uključuje u proces prikupljanja zahteva i testiranja sistema. Raniji inkrementi se mogu koristiti kao prototip koji može pomoći u prikupljanju zahteva za kasnije inkremente. Manji je rizik da projekat padne. Servisi sistema najvišeg prioriteta se najbolje Testiraju.

SpiRalni RazvOj - Proces je predstavljen kao spirala za razliku od ostalih modela gde je to sekvenca aktivnosti sa nekim povratnim stazama. Svaka petlja u spirali predstavlja fazu u spiralnom modelu procesa. Nema fiksnih faza kao što su izrada specifikacije ili projekta – petlja u spirali se bira zavisno od toga šta se zahteva. Rizici se eksplicitno utvrđuju i rešavaju kroz ovaj proces. SekTORi SpiRalnOg MOdela: 1) Postavljanje ciljeva – Identifikuju se specifični ciljevi za svaku fazu 2) Utvrđivanje i redukcija rizika – Utvrđuju se rizici i definišu se aktivnosti za redukciju ključnih rizika 3) Razvoj i validacija – Za razvoj se može izabrati bilo koji od generičkih modela 4) Planiranje – Radi se recenzija (pregled) projekta i planira sledeća faza spirale. Specifikacija SOfTveRa ili inženjeRing zahTeva - Proces razumevanja i definisanja servisa koje sistem treba da obezbedi i ograničenja pod kojima će sistem raditi i pod kojima će se razvijati. Proces inženjeringa zahteva obuhvata sledeće aktivnosti: a) Izradu studije izvodljivosti; 2) Prikupljanje i analizu zahteva 3) Izradu specifikacije zahteva 4) Validaciju zahteva. PROceS inženjeRinga zahTeva Projektovanje i implementacija softvera: a) Proces konverzije specifikacije sistema u izvršni sistem b) Projektovanje softvera c) Projektovanje strukture softvera koja realizuje specifikaciju softvera o Implementacija – Prevođenje strukture softvera u izvršni program d) Aktivnosti projektovanja i implementacije su usko povezane i mogu se preplitati. Proces projektovanja softvera: a) Arhitekturno projektovanje; b) Apstraktna specifikacija c) Projektovanje interfejsa d) Projektovanje komponenti e) Projektovanje struktura podataka f) Projektovanje algoritama MeTOde pROjekTOvanja: a) Sistematski prilazi razvoju projekta softvera b) Projekat se obično dokumentuje preko skupa grafičkih modela c) Mogući modeli: a) Model toka podataka b) ER model (Entity-relation-attribute model); c) Strukturalni model d) Objektni modeli. 3) Programiranje i debaging: a) Prevođenje projekta u program i uklanjanje grešaka iz tog programa b) Programiranje je personalna aktivnost – ne postoji generički proces programiranja c) Programeri testiraju svoj program da bi otkrili eventualne neispravnosti i u procesu debaginga. uklanjaju te neispravnosti Proces debaginga - Aktivnosti: a) Lociranje greške b) Projektovanje reparacije greške c) Reparacija greške d) Ponovno testiranje programa. 4) Validacija softvera: Verifikacija i validacija SW ima za cilj da pokaže da je sistem usaglašen sa svojom specifikacijom i da su svi zahtevi klijenta ugrađeni. Uključuje proveru i poregled procesa i testiranje sistema. Testiranje sistema uključuje izvršavanje sistema sa test slučajevima koji su izvedeni iz specifikacije realnih podataka koji treba da se obrađuju na sistemu. Koraci testiranja: a) Komponentno testiranje b) Testiraju se pojedinačne komponente c) Testiranje modula – Testiraju se povezane kolekcije zavisnih komponenti d) Testiranje podsistema – Moduli se integrišu u podsisteme i testiraju. Fokus je na testiranju interfejsa. e) Testiranje sistema – Testiranje sistema u celini; Testiranje bitnih svojstava. f) Prijemno testiranje – Testiranje sa podacima korisnika da bi se proverilo da li je sistem prihvatljiv za korisnika. Faze TeSTiRanja u SW pROceSu Evolucija sistema – Aktivnosti: Definisanje sistemskih zahteva; Procena na postojećem sistemu; Predlog promena sistema; Modifikovanje sistema

4. RUP !!! RUP MeTOdOlOgija - Rational Unified Process (RUP). RUP je primer modernog modela procesa koji je izveden iz rada na UML-u i pratećeg objedinjenog modela razvoja softvera. Dobar primer hibridnog modela: RUP se obično opisuje iz 3 različite perspektive: 1) Dinamička perspektiva – prikazuje faze modela u vremenu 2) Statička perspektive – prikazuje aktivnosti procesa 3) Perspektiva primene – sugeriše dobru praksu koju treba koristiti za vreme procesa. RUP je fazni model koji razlikuje 4 diskretne faze u SW procesu (dinamička perspektiva): Za razliku od modela vodopada gde su faze izjednačene sa aktivnostima procesa, u RUP-u su one bliže vezane sa poslovanjem nego sa tehnikom. RUP MeTOdOlOgija: RUP je metodologija za razvoj SW-a. RUP definiše korake koji dovode do proizvoda i ko je za njih odgovoran. Pomaže da se kontroliše projekat i da se smanji konfuzija. Pomaže rukovodstvu projekta u obezbeđenju resursa, planiranju i merenju napretka. Smanjuje rizik. Čini razvoj softvera predvidivim, ponovljivim i merljivim. Faze u RUP-u (Dinamička perpektiva): Iteracija u RUP-u je podržana na 2 načina: Svaka faza se može izvoditi na iterativan način, a rezultati se mogu isporučivati inkrementalno. Ceo skup faza se takođe može izvoditi inkrementalno. POčeTak: Cilj je definisanje modela poslovanja, kriterijuma uspeha, procena rizika, procena potrebnih resursa i izrada plana po fazama. Treba identifikovati sve eksterne entitete (ljudi i sistemi) koji će interagovati sa sistemom i definisati njihove interakcije. Ove informacije se koriste da se potvrdi da je sistem u funkciji poslovanja. Ako to nije slučaj, projekat se može otkazati. RazRada: Cilj je razumevanje domena problema, uspostavljanje arhitekturnog okvira za sistem, razvoj plana projekta i identifikovanje rizika projekta. Na kraju ove faze ima se model zahteva za sistem opis arhitekture i plan razvoja softvera. Konstrukcija: Odnosi se na projektovanje, programiranje i testiranje. Delovi sistema se razvijaju paralelno i na kraju faze se integrišu. Na kraju ove faze imamo sistem u radnom stanju i njegovu dokumentaciju. Sistem je spreman za isporuku korisniku. TRanzicija: Cilj je prenošenje sistema iz razvojnog u realno okruženje i njegovo puštanje u eksploataciju. Ova faza se po pravilu ispušta iz modela softverskih procesa. Na kraju ove faze imamo sistem koji je dokumentovan i koji radi kod korisnika. STaTički Radni TOkOvi u RUP-u - Statički pogled na RUP se fokusira na aktivnosti koje treba preduzeti u toku procesa razvoja. U RUP-u se nazivaju workflows. Identifikovano je: 6 radnih tokova glavnih procesa (core process workflows) i 3 radna toka glavne podrške (core supporting workflows). RUP je razvijen u sprezi sa UML-om, pa opisi workflows-a su orijentisani oko pridruženih UML modela. 1) Business modelling – modeliraju se poslovni procesi korišćenjem biznis slučajeva korišćenja 2) Requirements – identifikuju se akteri koji interaguju sa sistemom i razvijaju slučajevi korišćenja radi modeliranja zahteva sistema 3) Analysis and design – kreira se i dokumentuje model projekta korišćenjem arhitekturnih modela, modela komponenti, objektnih i sekvencijalnih modela. 4) Implementation – implementiraju se komponente sistema i ugrađuju u podsisteme. Proces ubrzava automatski proces generisanja koda iz projekta: a) Testing – testiranje je iterativan proces koji se izvodi u saradnji sa implementacijom b) Deployment – kreiran je “release” proizvoda, on se didtribuira i instalira kod korisnika c) Configuration and change management – aktivnost koja podržava upravljanje promenama d) Poject management – aktivnost koja podržava upravljanje razvojem sistema e) Environment – ova aktivnopst se odnosi na pribavljanje odgovarajućih alata za razvoj. RUP je skup parcijalno uređenih koraka namenjenih osnovnom cilju - da se efikasno i u predviđenim okvirima korisniku isporuči sistem koji u potpunosti zadovoljava njegove potrebe: a) Inkrementalan i iterativan proces b) Proces proizvodnje softverskog proizvoda je planiran i kontrolosan c) Proces je dokumentovan d) Baziran je na UML RUP – KaRakTeRiSTike - RUP je inkrementalan i iterativan proces. To znači da se do konačne verzije sistema stiže kroz niz iteracija, a da se u svakoj iteraciji inkrementalno povećava funkcionalnost sistema sve dok se ne stigne do konačnog sistema. Na taj način, stalno se dobijaju izvršne verzije sistema sa sve većim brojem realizovanih funkcija, čime se tokom trajanja razvoja sistema, polako smanjuje rizik. Dobra osobina RUP metodologije je što je proces jako dobro dokumentovan (postoji i Web- tutor koji vodi korisnika kroz proces), dobro definisan - tačno je definisano šta se od proizvoda (modeli i dokumenti) u kojoj fazi dobija i u potpunosti podržan softverskim alatima (pre svega kompanija Rational (sada IBM) sa svojim softverskim alatima) i šablonima (templejtima) proizvoda. Sve ovo jako pomaže korisniku da dođe do konačnog cilja - što boljeg softverskog proizvoda. OSnOvni pRObleMi u RazvOju SW-a: Potrebe korisnika ili poslovnog sistema nisu zadovoljene; Promena zahteva; Moduli nisu integrisani; Teškoće u realizaciji; Kasno otkrivanje grešaka; Loš kvalitet ili neiskustvo korisnika; Loše performanse pri opterećenju; Nekoordinisan rad tima. 6 OSnOvnih pRincipa za uSpešan RazvOj SW-a pO RUP-u: 1) Iterativni razvoj SW-a 2) Upravljanje zahtevima 3) Komponentna arhitektura SW-a 3) Vizuelno modeliranje 4) Kontinualna verifikacija kvaliteta 5) Upravljanje promenama.

ITeRaTivni RazvOj Upravljanje zahtevima: a) Upravljanje zahtevima znači prevođenje zahteva korisnika u skup njihovih potreba i funkcija sistema b) Ovaj skup se kasnije pretvara u detaljnu specifikaciju funkcionalnih i nefunkcionalnih zahteva. c) Detaljna specifikacija se prevodi u test procedure, projekat i korisničku dokumentaciju. d) Potrebno je definisati proceduru u slučaju promene zahteva korisnika.

Komponentna arhitektura: a) Zadovoljava i trenutne i buduće zahteve b) Poboljšava proširljivost c) Obezbedjuje višestruko korišćenje d) Enkapsulira zavisnosti Vizuelno modeliranje: Koristi se UML – Objedinjeni jezik za modeliranje

Upravljanje promenama: a) Upravljanje promenama zahteva b) Izveštavanje o statusu proizvoda c) Upravljanje konfiguracijom d) Praćenje promena e) Odlaganje izvornog koda i kontrola verzija. OSnOvni kOncepTi RUP MeTOdOlOgije: Faze, Iteracije (Kada se nešto događa?); Tokovi procesa (Šta se događa?); Aktivnosti, koraci; Proizvodi (Šta se proizvodi?) – modeli, izveštaji, dokumenti; Učesnici (Ko to radi?) - Projektant, programer. RUP faze: 1. Početna faza; 2. Faza razrade; 3. Faza izrade; 4. Faza isporuke. Svaka faza može imati proizvoljan broj iteracija i svaka iteracija (osim, naravno, početne) treba da rezultira izvršnom verzijom koja se može testirati. KOnTROlne Tačke na kRaju faza: Početna faza: a) Analiza problema b) Razumevanje potreba (potencijanih) korisnika c) Generalno definisanje sistema d) Upravljanje kod promena korisničkih zahteva. Rezultat ove faze je dokument Vizija sistema. Vizija sistema: a) Piše se bez mnogo tehničkih detalja tako da bude razumljiva i korisnicima i razvojnom timu. B) Koriste se samo blok dijagrami za šematski prikaz sistema. Vizija sistema Faze: a) Pozicioniranje proizvoda c) Opis korisnika e) Opis proizvoda h) Funkcionalni zahtevi k) Nefunkcionalni zahtevi b) Ograničenja d) Kvalitet. Faza elaboracije: b) Izrada plana projekta d) Organizacija i ekipni rad f) Detaljna definicija zahteva g) Definisanje arhitekture sistema. Rezultati ove faze su: Plan projekta, Use-case specifikacija, Arhitekturni projekat sistema. Plan projekta: 1) Plan faza 2) Plan izrade 3) Rezultati projekta 4) Kontrolne tačke 5) Resursi... Use-case specifikacija: a) Opis slučajeva korišćenja b) Definisanje aktera u sistemu c) Određivanje arhitekturno najznačajnijih slučajeva korišćenja Arhitekturni projekat sistema: a) Definisanje arhitekture sistema b) Definisanje najbitnijih klasa c) Realizacija arhitekturno najznačajnijih slučajeva korišćenja (preko sequence diagram) d) UML dijagrami klasa Faza izrade: a) Realizacija sistema b) Testiranje. Rezultati ove faze su: a) Plan testiranja b) Test specifikacija c) Detaljni projekat sistema d) Softverski proizvod Plan testiranja: a) Zahtevi testiranja b) Strategija testiranja c) Tehnike testiranja d) Alati za testiranje e) Resursi f) Proizvodi h) Kontrolne tačke Detaljni projekat sistema: a) Arhitekturni projekat razvijen u detalje b) Dijagrami klasa c) “4+1” model sistema (na slici desno).

Test specifikacija: Test-case-ovi: Opis; Radnje-ulazi; Očekivani odzivi-izlazi; Završne radnje 4+1 model sistema: Logička arhitektura: a) Logička arhitektura sistema opisuje najvažnije klase u sistemu, njihovu organizaciju u pakete i podsisteme kao i organizaciju paketa i podsistema u nivoe (layers) b) Za predstavljanje logičke arhitekture se koriste dijagrami klasa c) Mogućnost automatskog generisanja koda na osnovu dijagrama klasa Procesna arhitektura: a) Procesna arhitektura sistema opisuje najvažnije procese i niti (threads) u sistemu i njihovu organizaciju. Procesi se izvršavaju u nezavisnim adresnim prostorima računara, dok su niti procesi koji se izvršavaju paralelno sa procesima ili drugim nitima ali u adresnom prostoru nekog od procesa. Za procesne arhitekture se koriste dijagrami klasa. IMpleMenTaciOni MOdel: Za prikaz implementacionog modela se koriste dijagrami komponenti. Fizički MOdel: Fizički model opisuje fizičke čvorove u sistemu i njihov razmeštaj u prostoru. Za prikaz fizičkog modela se koriste dijagrami razmeštaja. Faza isporuke: a) Finalizacija softverskog sistema; b) Alfa (beta) testiranje c) Izrada korisničke dokumentacije (uputstva) d) Obuka korisnika e) Uvođenje sistema kod korisnika. Rezultati ove faze su: a) Test izveštaj b) korisničko uputsvo c) Instalacija sistema Test izveštaj: 1) Pregled rezultata testiranja: a) Generalna procena testiranog SW-a b) Uticaj test okruženja c) Predložena poboljšanja 2) Rezultati izvršenja test-case-ova PRiMena RUP alaTa i TeMplejTa: Primena alata: Za male projekte se ne moraju primenjivati, ali za bilo koji ozbiljniji rad moraju se koristiti alati. RUP je univerzalno rešenje - Svaki projekat ima svoje specifičnosti. RUP pruža okvir za proces razvoja. Neki koraci mogu biti nepotrebni, neki su možda nedovoljno definisani. U zavisnosti od projekta, RUP se može prilagođavati sopstvenim potrebama. RUP templejti: Način da se formalizuje proces. U suštini, sam format templejta je najmanje važan, važniji je sadržaj dokumenata. Da bi se članovima razvojnog tima olakšao posao, kao i da bi se obezbedile sve neophodne informacije za naredne faze moraju se koristiti templejti. Naravno, i oni mogu biti podložni promenama u skladu sa potrebama. 5. Agilne Metode!!! Agilni razvoj softvera - Tradicionalne nasuprot agilnim metodama. Agilno = aktivnost, hitnost, spremnost za pokret. Iterativni i Inkrementalni razvoj. Razlika: Inkrementalne metode 3 - 6 meseci. Agilne metode 1 - 4 nedelje. Agilne metode su razvijene da se koriste u malim programerskim timovima koji rade zajedno u istoj prostoriji i komuniciraju neformalno. Zbog toga se one najviše koriste za razvoj malih i srednjih sistema. Def. agilnog program. - Više vrede: Pojedinci i interakcije nego procesi i alati; Programska podrška koja radi nego dokumentacija. Saradnja s klijentima nego ugovori. Odgovor na promene nego praćenje plana. Agilno prog. Principi: Zadovoljstvo korisnika brzom isporukom korisnog softvera. Mogućnost promene zahteva, čak i u poodmakloj fazi razvoja. Česta isporuka softvera, u razmaku od par nedelja. Ispravan softver je osnovna mera napretka. Razvoj koji je u stanju da održi konstantan tempo. Bliska saradnja između projektanata i poslovnih saradnika. Najbolji tip komunikacije je komunikacija “licem-u- lice”. Projekti se izvode u okruženju u kojem su motivisani pojedinci, u koje se može imati poverenja. Kontinualno usmeravanje pažnje ka tehničkoj veštini i dobrom dizajnu. Jednostavnost. Samo organizovani timovi. Prilagođavanje promenljivim okolnostima. Šta izabrati – je odluka da li izabrati agilnu ili planom vođenu metodu razvoja zavisi od tipa softvera koji se razvija, od sposobnosti tima, i afiniteta kompanije koja razvija sam softver. Praksa nije idilična - Kupac ne može uvek biti umešan u razvoj; Osobine članova tima; Različiti prioriteti; Jednostavnost zahteva dodatni trud; Stare navike kompanija . Agilne metode: Ekstremno programiranje (XP); Industrijsko ekstremno programiranje (IXP); Scrum; Crystal; Cristal Cleer; Adaptivni razvoj softvera (ASD); Razvoj vođen karakteristikama (FDD); Metode dinamičkog razvoja sistema (DSDM); Lean Development (LD); Agilno modelovanje (AM). Extreme Programming (XP) – Verovatno najbolja a i Najpopularnija agilna metoda. Ime je skovao Beck - 1999. god, zato što je gurao prepoznatljivo dobru praksu, kao interativni ravoj na „Extremne“ nivoe; Mali timovi; Proizvodnja dugotrajnog softvera. Sposobnost reagovanja na promene zahteva. Programeri rade u paru i testiraju svaki zadatak pre nego što počnu da pišu kod, i svaki test mora da bude uspešno izvršen kada se novi kod ugrađuje u sistem. Novi prilaz razvoju softvera zasnovan na razvoju i isporuci vrlo malih inkremenata funkcionalnosti. Vezuje se za konstantno poboljšanje koda, za uključivanje korisnika u razvojni tim i za programiranje u paru ( “pairwise programming”). Životni ciklus XP-a: 1. Istraživanje (pisanje priča, upoznavanje tehnologija); 2. Planiranje (utvrđivanje potrebnog vremena, prioriteti, stvaranje); 3. Iteracije (pisanje, procena i dodeljivanje prioriteta novim zadacima, testiranje na kraju svake iteracije); 4. Proizvodnja (testiranje pre isporuke, evidentiranje novih zahteva); 5. Održavanje (dodavanje novih funkcionalnosti, ispravke grešaka); 6. Kraj (zahtevi ispunjeni, završetak projekta). Naručioci su blisko uključeni u specificiranje i davanje prioriteta zahtevima, maltene kupci sistema su deo razvojnog tima i mogu da diskutuju sa

drugim članovima tima. Oni zajedno razvijaju „story card“ koji obuhvata korisnikove potrebe, on je glavni za planiranje procesa u XP ili „planiranje igre“. Naručioc bira koju priču (story) hoće da bude sada implemetirana, i onda će biti gotova za oko 2 nedelje. Naravno u tom vremenskom periodu, ostale ne implementirane priče mogu biti menjane kao i odbačene, a ako treba da budu vršene neke izmene na sistem koji je već dostavljen, nove „story kartice“ moraju biti napravljene i onda opet korisnik bira koja će biti sledeća implemetirana. Vrednosti XP-a: Metodologija se temelji na pet osnovnih vrednosti: Komunikacija; Jednostavnost; Povratna sprega; Hrabrost; Poštovanje. Ponekad u toku igre planiranja jave se neka pitanja na koja nije lako odgovoriti, koja zahtevaju dodatna rasvetljavanja i razmatranja da bi se našla odgovarajuće rešenja, i ona se u Xp-u nazivaju „spike“ i mogu se javiti u dizajnu arhitekrutere ili pravljenja dokumentacije a s obzirom da rokovi nikad ne spavaju ako dođe do problema, konsultuje se sa naručiocem da se ta funkcionalnost izbriše iz planirane verzije za naredni rok. Aktivnosti u XP-u: Da bi se dostigle vrednosti ekstremnog programiranja sprovode se četiri vrste aktivnosti pomoću kojih se te vrednosti implementiraju u ponašanje i rad tima: Kodiranje; Slušanje; Testiranje; Projektovanje. Kada se napravi nova verzija ona se mora automacki testirati i nova verzija je jedni prihvatljiva ako svi testovi uspešno prođu, i ona predstavlja bazu za sledeću iteraciju sistema. Uloge u XP-u: Menadžer - formira tim i upravlja njime; Trener - uči članove tima o XP metodologiji; Tragač - prikuplja korisničke zahteve i prati napredak testova; Programer - piše testove, projektuje i kodira; Tester – pomaže kupcu da piše i razvija testove. Kupac - piše zahteve i testove, i bira zahteve koji će se raditi u određenoj iteraciji. Uslovi u XP-u: Otvorena radna sredina; Oglasna tabla; Normalno radno vreme; Dnevni sastanci; Nedeljni sastanci; Tromesečni sastanci; U praksi, mnogo kompanije koriste adaptirani Xp, one su ga prilagodile svom načinu rada i one prave male release verzije, verzije koje se prve testiraju, i kontinualnu integraciju. Testiranje u Xp-u – Najvažnije prednosti: 1. Testiranje prve verzije 2. Inkrementalno testiranje iz scenarija 3. Uključivanje korisnika u testiranje i proveru 4. Korišćenje automatizovanih okruženja za testiranje. „Test-first development“ je jedna od najvećih inovacija XP-a, i znači da umesto da pišemo kod pa testiramo mi pišemo test pre koda, to znači da mi možemo pokrenuti test kao kod kada bi bio napisan, i pronaći odmah probleme. Programiranje u Paru – Ovo je još jedna inovacija XP-a, a to znači da par programera sede i rade na razvoju istog softvera istovremeno i jedan par ne mora uvek da radi zajedno, već se mogu dinamički menjati. Dobro je što se ima podrška tima, što se u paru pa se lakše i brže nađu i više grešaka, takođe je dobro što se znanje razmenjuje pa tako odlazak nekog člana tima neće mnogo uticati na projekat a i studije su pokazale da kada imamo pair programing i da dva programera rade nezavisno daje slične rezultate kada imamo dva slabije programera, ali kada imamo dve iskusna programera, prednost je na metodi kada se radi nezavisno i odvojeno. Industrijsko ekstremno programiranje (IXP): 1. Припремљеност за приступ; 2. Пројектна заједница; 3. Уговарање пројекта; 4. Менаџмент вођен тестовима; 5. Ретроспектива; 6. Стално учење; 7 Razvoj vođen testovima priče 8. Dizajn vođen domenom; 9. Uparivanje - unapređeno programiranje u paru; 10. Iterativno testiranje korisnosti - unapređeno prisustvo klijenta u timu; 11. Рефакторисање; 12. Игра планирања; 13. Стална интеграција; 14. Заједничко власништво; 15. Стандарди у коду; 16. Одрживи корак; 17. Честе испоруке; 18. Управљање ризиком Континуирано; 19. Развојна Дизајн; 20. Мале приче (корисник захтев); 21. Тест приче; 22. Рад у заједници; 23. Мали тимови SCRUM - Nastao Polovina 90-ih. Scrum je uopštena agilna metoda kojoj je u fokusu upravljanje iterativnim razvojem umesto dostizanja agilnog SW inženjeringa. Scrum ne podržava programiranje u paru i razvoj „prvo-testiranje“. On se više koristi sa XP za rukovođenje okruženja za projekat odnosno Projektni okvir. Agilno upravljanje, ne projektovanje softvera. Propisuje načine upravljanja zahtevima, formiranja iteracija, kontrole implementacije i isporuke klijentu. Uloge u SCRUM-u: 5 do 10 članova tima: Vlasnik projekta; “Scrum Master”; Scrum tim; Zainteresovane strane. Faze u SCRUM-u: Scrum proces se sastoji od 3 faze: Pre igre – nacrtno planiranje faza, projektovanje arhitekture, visok nivo apstrakcije; Igra - razvoj, serija sprint ciklusa gde se u svakoj inkrementalno poboljšava sistem. – iterativni ciklusi, poboljšanja, nove verzije; Posle igre - nema novih zahteva, kompletiranje potrebne dokumentacija kao help, sistem spreman za korišćenje. Inovacija u Scrum je centralna faza, koja se naziva sprint ciklus. Sprint u Scrum-u je jedinica planiranja u kom se bira rad koji treba da se izvrši, biraju se funkcionalnosti koje će se razvijati, i softver se implementira, a na kraju sprinta, kompletna funkcionalnost se dostavlja Zainteresovanim stranama. SCRUM dokumentacija - Tri glavna dokumenta koje generiše Scrum ekipa: zaliha softvera, zaliha trenutne iteracije i dijagram preostalog posla u sprintu SCRUM proces - Sprint (Iteracija ) traje 2 do 4 nedelje (isto kao i razvoj release verzije sistema u XP). Celokupni projekat (jedna igra) traje 3 do 8 sprintova. Faze: Planiranje sprinta (plan za 30 dana). Startuje se sa planiranjem preostalog posla koji treba da bude urađen, korisnik je uključen u proces tako da može izneti nove zahteve i zadatke na početku svakog Sprinta. Sprint sa kratkim dnevnim sastancima uključuje ceo tim da vidi progres i krajnji pregled sprinta. U toko same faze tim je izolovan od korisnika i sva komunikacija ide preko takozvanog „Scrum master“-a, čija

je uloga da štiti tim od spoljašnjeg uznemiravanja. Način na koji će se problem rešiti zavisi od tima i problema, nije kao u XP-u, ovde Scrum ne sugeriše kako pisati zahteve, testove… Ali se Xp može koristi ako tim smatra da je odgovarajući. Na kraju sprinta, rad će biti pregledan i pokazan „StakeHolders“-ima, i onda sledeći Sprint ciklus počinje. Sama ideja Scrum-a je da se ceo tim opunomoći da donosi odluke pa je termin „project manager“ oprezno izbegavan. „Scrum master“ je ovde zadužen da organizuje dnevne sastanke, prati rad, donosi odluke, meri napredak, komunicira sa mušterijama i vrši sva upravljanja izvan tima. Ceo tim učestvuje na dnevnim sastancima koji mogu biti i na nogama, gde se razmenjuju mišljenja, i iznose problemi ako ih ima, svi učestvuju i nema jasnih direktiva od Scrum master-a. Scrum je napravljen da se koristi kada se svi članovi tima okupljao na dnevnim sastancima, mada sad imamo sve više distribuiranih timova lociranih svuda po svetu tako da Scrum sad više ide „ka Scrum za distribuirana razvojna okruženja“. Crystal metodologije: Alistair Cockburn, 1991. god. Metodologije orijentisane na ljude su bolje od metodologija koje su orijentisane na procese. Sedam ključnih principa Crystal metodologije: 1. Učestala isporuka 2. Kontinuirane povratne informacije 3. Stalna komunikacija 4. Sigurnost 5. Fokus 6. Raspoloživost korisnika 7. Automatski testovi i integracija Crystal Clear - Elementi su: 1. Dokumenti: plan puštanja u rad, slučajevi korišćenja, skice dizajna, testovi i korisnički priručnik… 2. Uloge (Tim: 3 - 8 osoba): sponzor projekta (kupac), vodeći programer projektant, programer projektant, korisnik. 3. Proces - Crystal Clear proces: Inkrementalna dostava projekta; Projekat se pušta u rad u manje od 2 do 3 meseca. Testovi su automatizovani. Korisnik je direktno uključen. Dve korisničke recenzije pre puštanja u rad. Prati se napredak na projektu. Adaptivni razvoj softvera. Namenjena je za razvoj kompleksnih rešenja, uz oslonac na Inkrementalni i iterativni razvoj i evolutivne prototipove. “Balansiranje na ivici haosa”, 1. Zahtevi, ciljevi; 2. Trajanje projekta; 3. Broj iteracija i trajanje; 4. Tema svake iteracije; 5. Funkcije svake iteracije ASD karakteristike životnog ciklusa su: Fokusira se na misiju; Zasniva se na funkcionalnostima; Iterativan; Vremenske celine; Vođen je rizikom; Tolerantan na promene FDD - Razvoj vođen karakteristikama - Ne bavi se celokupnim životnim ciklusom, već se koncentriše na faze projektovanja i konstrukcije. Realizacija malih, zaokruženih funkcija koje se ne kreiraju duže od dve nedelje. Faze u FDD-u - Gotovi na početku projekta: Razvoj celokupnog modela, Realizacija liste potrebnih funkcija ažuriraju se; Inkrementalno na 2 nedelje: Planiranje realizacije funkcija; Detaljno projektovanje; Konstrukcija potrebnih funkcija. Uloge u FDD-u: Vođa projekta; Glavni arhitekta; Vođa razvoja; Glavni programer; Vlasnik klase; Stručnjak u određenom domenu; Tim koji razvija određenu funkcionalnost. Metode dinamičkog razvoja sistema (DSDM) - Konzorcijum (od 16 kompanija) čiji je cilj održavanje RAD metoda. DSDM je baziran na sledećim principima: Fokusirati se na potrebe poslovanja; Isporuka na vreme; Kolaboracija; Nikada ne praviti kompromis po pitanju kvaliteta; Inkrementalni i iterativni razvoj; Kontinualna i jasna komunikacija. Demonstracija kontrole. Životni ciklus DSDM projekta - DSDM metod podržava sledeće faze razvoja projekta: Studija o izvodljivosti; Studija poslovnog domena; Iteracija razvoja funkcionalnog modela; Iteracija projektovanja i izgradnje; Implementacija u realnom okruženju (instaliranje kod korisnika). Lean Development (LD) - Metodologija inspirisana sistemom proizvodnje u japanskim fabrikama automobila. Vreme razvoja u Tojoti je duplo kraće, a produktivnost radnika je 4 puta veća, uz znatno manji procenat grešaka nego u fabrikama u SAD-u. LD je skoncentrisan na vrh preduzeća i strategiju upravljanja, ne na detalje razvojnog procesa na niskom nivou. Pošto se LD bavi više filozofijom upravljanja nego konkretnim razvojnim procesom, detalji razvoja nisu precizno definisani, kao ni veličina tima i način njegovog organizovanja. Principi LD-a - Najveći prioritet je zadovoljiti očekivanja korisnika; Potrebno je obezbediti najbolje moguće rešenje za novac korisnika; Uspeh zavisi od aktivnog učešća korisnika; Svaki LD projekat je rezultat timskog rada; Sve se može menjati; Rešenje primenjivo na širi problemski domen, a ne samo za konkretni problem. Realizacija “unikatnog” rešenja je preskupa. Bolje je prilagoditi gotovo rešenje, nego raditi svaki put iz početka. Bolje je imati 80% rešenja danas, nego 100% rešenja u budućnosti. Minimalizam je esencijalan za uspeh projekta. Potreba određuje tehnologiju, ne obrnuto. Agilno modelovanje (AM) - Nije metod koji podržava celokupni životni ciklus softvera, već se bavi isključivo tehnikama za realizaciju modela i dokumentacije u “agilnom” maniru. Može se primenjivati u okviru bilo koje druge metodologije, agilne ili ne. Vrednosti se poklapaju sa vrednostima XP-a: Komunikacija; Jednostavnost; Povratna sprega od strane korisnika; Hrabrost; Skromnost Principi AM-a: Softver koji zadovoljava potrebe korisnika je primarni cilj; Priprema za period koji sledi je drugi po važnosti cilj projekta. Minimalno opterećivati projekat dodatnim artefaktima. Pretpostaviti da je najjednostavnije

rešenje najbolje rešenje. Prihvatiti da su promene neminovne. Razvijati sistem inkrementalno. Modelovati sa svrhom, tj. ne kreirati modele radi njih samih. Raditi kvalitetno. Naručiocu pružiti najbolje za njegov novac. 6. Specifikacija zahTeva UpRavljanje zahTeviMa: Upravljanje zahtevima znači prevođenje zahteva korisnika u skup njihovih potreba i funkcija sistema. Ovaj skup se kasnije pretvara u detaljnu specifikaciju funkcionalnih i nefunkcionalnih zahteva. Detaljna specifikacija se prevodi u test procedure, projekat i korisničku dokumentaciju. Potrebno je definisati proceduru u slučaju promene zahteva korisnika. Svaki od funkcionalnih i nefunkcionalnih zahteva evoluira kroz različite fokuse i perspektive, definišući različite nivoe detalja u zahtevima. Svaka nenamerna praznina u zahtevima povećava RIZIK kraha projekta ili dodavanja drugog defekta. FunkciOnalni zahTevi: KO (Interfejs) koji ljudi organizacije ili sistemi smeju (ne ljudi, organizacije, ili smeju) da pristupe sistemu. ŠTA (Podaci) Informacije potrebne sistemu u smislu zadovoljenja funkcija. GDE (Mreža) Fizička ili Internet lokacija koja mora imati pristup rešenju. KADA (Događaji) Vremensko usaglašavanje poslovnih događaja. ZAŠTO (Businnes rules) Poslovna pravila kojima mora biti prilagođen sistem. KAKO (Proces) Koje zadatke ili procesiranje i funkcije system mora da izvrši. NefunkciOnalni zahTevi: Ograničenja u projektu se moraju takođe definisati. Kategorije ograničenja: Nivo kvaliteta; Nivo cene; Funkcionalnost; Dizajn; Politička; Kulturološka; Pravna Problemi u specifikaciji zahteva: Korisnici u početku: neznaju tačno šta hoće, menjaju svoja očekivanja u toku projekta, uvek misle da se može više uraditi, i nikada nisu zadovoljni. PRObleMi u Specifikaciji zahTeva: Važno je za uspeh projekta da KUPAC uoči razliku između toga ŠTA ŽELI i ŠTA MU TREBA. “Mi imamo više nego 100% onoga što Vama treba. Mi nemamo 100 % onoga što Vi želite". Larry Ellison (Oracle CEO) KORišćenje STandaRda u Specifikaciji zahTeva: Omogućava KUPCU da postavi zahteve na način da ga isporučioc razume. Omogućava ISPORUČIOCU da razume zahteve kupca i analizom zahteva bude siguran da je u mogućnosti da proizvede softverski proizvod odgovarajućeg kvaliteta. Specifikacija zahTeva: Organizacija mora da definiše zahteve kupca koji obuhvataju: zahteve za proizvod koje je kupac definisao, uključujući i zahteve u pogledu dostupnosti, isporuke i podrške proizvodu; zahteve koje kupac nije definisao, ali koji su neophodni za planiranu ili željenu upotrebu; obaveze koje se odnose na proizvod, uključujući propise i zakonske zahteve. UpRavljanje zahTeviMa: Upravljanje zahtevima je više od dokumentovanja istih. Šest preporuka “dobre prakse” za upravljanje zahtevima: 1. Odvojite dovoljno vremena za proces definisanja zahteva. 2. Izaberite pravi pristup za iznošenje zahteva. 3. Prenesite – saopštite zahteve svim interesnim stranama. 4. Razvrstajte zahteve po prioritetu. 5. Zahtevi za ponovno korišćenje – reuse. 6. Pratite zahteve kroz životne cikluse softvera. PodProcesi UpRavljanje zahTeviMa: Proces upravljanja zahtevima sastoji se od međusobno nerazdvojivih podprocesa, koji se ne mogu zasebno i sekvencijalno odvijati: Prikupljanje zahteva; Analiza zahteva; Specifikacija zahteva; Validacija zahteva Zablude pRi pOTpiSivanju Specifikacije zahTeva: Tipski UGOVOR + specifikacija. Potpisnici obično nemaju vremena da do detalja prouče specifikaciju koju su “SAVESNO” pripremili saradnici. I jedni i drugi potpisuju specifikaciju, zaboga, programeri bez toga ne mogu da počnu da programiraju. Značaj Specifikacije zahTeva: Kvalitetan softver je proizvod vrlo dobro realizovanog dizajna zasnovanog na tačnim zahtevima, koji su rezultat efektivne komunikacije i saradnje – partnerstva – između projektanata i kupaca PRikupljanje zahTeva: Tri glavne kategorije učesnika su: Kupac; Korisnik; Developer i NIKO od učesnika u ovoj fazi nema kompletnu sliku o softverskom proizvodu. Glavni problem: neadekvatna komunikacija. Tokom procesa prikupljanja zahteva mora se uspostaviti partnerski odnos među interesnim stranama. Učešće kupca je najkritičniji faktor od kojeg ovisi kvalitet softvera, i najteži problem je deljenje vizije o proizvodu sa kupcem. LiSTa pRava kupca SW-a: 1. Očekuje da analitičar govori njegovim jezikom, 2. Očekuje da analitičar razume njegovo poslovanje i ciljeve, i u tom svetlu mesto i ulogu novog softverskog proizvoda, 3. Očekuje da analitičar informacije koje mu prezentira evidentira, razradi i izradi specifikaciju zahteva za sistem, 4. Da projektanti objasne zahteve za softver na nivou podsistema i nižim nivoima, 5. Očekuje da ga projektanti tretiraju sa respektom i da održavaju klimu saradnje i profesionalnosti, 6. Analitičar prezentira ideje i alternative i za njegove zahteve i za implementaciju, 7. Da se opišu karakteristike koje će obezbediti lako korišćenje proizvoda i da se opišu scenariji upotrebe proizvoda, 8. Budu prikazane mogućnosti da se već postojeće softverske komponente uključe ili prilagode njegovim zahtevima, 9. Mu se ukaže poverenje na njegovu procenu cene i uticaja na softver kada zahteva promenu zahteva za softver, 10. Primi sistem koji zadovoljava zahteve za funkcionalnost i kvalitet, do nivoa koji je utvrđen u komunikaciji sa projektantima, usaglašen i dokumentovan u specifikaciji i dopunama specifikacije. LiSTa OdgOvORnOSTi kupca SW-a - Kupac softvera ima odgovornost da: 1. Upozna analitičara sa svojim poslovanjem i

definiše žargon. 2. Potroši vreme da obezbedi zahteve i pojasni ih u svetlu svojih poslovnih potreba. 3. Bude precizan u vezi sa zahtevima za sistem. 4. Blagovremeno donese odluke u vezi zahteva, kada se to zahteva od njega. 5. Poštuje projektantske ocene u vezi cene i izvodljivosti zahteva. 6. Definiše prioritete za svaki pojedinačni zahtev, osobinu sistema i scenario primene. 7. Izvrši preispitivanje dokumenata (zahteva) i prototipova. 8. Odmah dostavi promene u zahtevima za proizvod. 9. Postupa saglasno dokumentovanom procesu promena zahteva razvojne organizacije. 10. Poštuje proces upravljanja zahtevima koji koristi razvojna organizacija. KaTegORije zahTeva: Funkcije: “šta” sistem mora da bude sposoban da uradi. Osobine: “koliko dobro” će funkcije biti izvršavane. Cena: koliko će koštati (bilo koji ulazni resurs: novac, ljudi, ili vreme) kreiranje i održavanje funkcija i njihovih osobina. Ograničenja: bilo koja restrikcija u slobodi definisanja zahteva ili dizajnu. TipOvi zahTeva: Nije kvantifikovan, ali je testiranjem moguće utvrditi da je realizovan; Kvantifikovan (na mernoj skali); Funkcije se ne mogu kvantifikovati, one ili su ili nisu prisutne. Sve osobine i cena se mogu i moraju kvantifikovati. Ograničenja mogu biti bilo kog tipa. KaRakTeRiSTike zahTeva: 1. Svi zahtevi su testabilni na prisustvo u realnom svetu njihove implementacije. 2. Svi zahtevi reflektuju nečije subjektivne vrednosti i prioritete. 3. Za bilo koji set zahteva, postoji neki drugi set zahteva koji verovatno isto tako dobro ili bolje zadovoljava realne potrebe, vrednosti i prioritete kupca. 4. Svi zahtevi su u prirodnom konfliktu sa svim ostalim u odnosu na resurse. 5. Zahtevi nisu statični, nego se stalno menjaju kako se menja svet menjajući naše potrebe, vrednosti i prioritete. 6. Upravljanje zahtevima je sistematičan proces utvrđivanja kompletnog seta relevantnih vrednosti kojima raspolažu interesne strane, i procesiranja istih sve dok se od njih ne dobije zadovoljavajući nivo “isporuke zahtevanih krajnjih stanja”. To implicira da se mora uključiti dizajn, testiranje, kontrola kvaliteta, upravljanje projektom, specifikacija jezika i sve ostale relevantne discipline da se omogući da projekat uspe. Lažni zahTevi: 1. Zahtevi nisu iskazani na kvantifikovan i merljiv način: “reducirana cena”, “poboljšana kontrola upravljanja”, “visoka upotrebljivost”, “povećano zadovoljstvo kupca”, 2. Ideje o projektovanju umesto stvarnih zahteva, “zahteva se objektno orjentisana baza podataka”, “potrebno je poboljšano uputstvo za rukovanje”, “obezbediti Windows XP interfejs”. ŠTa TReba ubaciTi na kRaju Specifikacije - SPECIFIKACIJA (TekST iSpRed pOTpiSa): “Slažem se da ovaj dokument reprezentuje naše najbolje shvatanje zahteva za softver za ovaj projekat. Naredne izmene osnovne konfiguracije mogu se izvršiti kroz definisan proces upravljanja promenama. Prihvatam da usaglašene izmene mogu zahtevati da pregovaramo o ceni, resursima i rokovima realizacije projekta.” Značaj Specifikacije zahTeva: NIKO ne želi da dobije proizvod koji ne može da koristi. Vaš kupac nije izuzetak. Čak i mala greška u zahtevima može dovesti do velikog problema… RazlOzi uSpeha ili neuSpeha SOfTveRSkih pROjekaTa: Istraživanje čuvene Standish Group kako softverski projekti postižu uspeh, ili preciznije neuspehe. Rezultat studije u kojoj je učestvovalo 365 organizacija, reprezentujući 8.380 aplikacija. 31% softverskih projekata je ugašeno pre nego su uopšte završeni. RazlOzi uSpeha SOfTveRSkih pROjekaTa: 1. Učešće korisnika 15,9%; 2. Podrška izvršnog menadžmenta 13,9%; 3. Jasni zahtevi 13,0%; 4. Odgovarajuće planiranje 9,6%; 5. Realistična očekivanja 8,2%; 6. Manji Smaller Milestones 7,7%; 7. Kompetentno osoblje 7,2%; 8. Vlasništvo (Ownership) 5,3%; 9. Jasna vizija i ciljevi 2,9%; 10. Hard-Working Staff 2,4%; Other 13,9% FakTORi Rizika: 1. Nedostatak ulaza od korisnika 12,8%; 2. Nekompletni zahtevi 12,3%; 3. Promenjivi zahtevi 11,8%; 4. Nedostatak podrške rukovodstva 7,5%; 5. Tehnološka nekompetentnost 7,0%; 6. Nedostatak resursa 6,4%; 7. Nerealna očekvanja 5,9%; 8. Nejasni ciljevi 5,3%; 9. Nerealni vremenski rokovi 4,3%; 10. Nova tehnologija 3,7%; Ostali 23,0% RazlOzi neuSpeha SOfTveRSkih pROjekaTa: 1. Nekompletni zahtevi 13,1%; 2. Nedostatak učešća korisnika 12,4%; 3. Nedostatak resursa 10,6%; 4. Nerealna očekvanja 9,9%; 5. Nedostatak podrške rukovodstva 9,3%; 6. Promenjivi zahtevi 8,7%; 7. Nedostatak planiranja 8,1%; 8. Nije više potreban 7,5%; 9. Nedostatak IT menadžmenta 6,2%; 10. Tehnološka nepismenost 4,3%; Ostali 9,9%

7. Metode inženjeringa zahteva Metode inženjeringa zahteva - Procesi inženjeringa zahteva su obično “vođeni” odgovarajućom metodom. Metode inženjeringa zahteva definišu sistematske načine za dobijanje modela sistema. Karakteristike RE metode - Pogodnost za usaglašavanje sa krajnjim korisnikom. Preciznost definicije i odgovarajuće notacije. Pomoć kod formulisanja zahteva. Fleksibilnost. Podržanost odgovarajućim SW alatima. Najpoznatije RE metode - DFD (Data-Flow-Diagram) dijagrami; Metode koja koriste relacioni model podataka; Objektno-orijentisane metode; Formalne metode; Metode zasnovane na ponašanju sistema: Use-case specifikacija; Viewpoint orijentisane metode.

Formalne metode - Polu-formalne i neformalne metode: Koriste prirodni jezik, dijagrame, tabele i prostu notaciju. Uključuju strukturnu analizu i OO analizu. Formalne metode: Bazirane su na matematički formalnoj sintaksi i semantici. Poznate metode: Z, B, VDM, LOTOS. Obezbeđuju načine za postizanje visoke sigurnosti da će sistem odgovarati specifikaciji zahteva. Ne garantuju apsolutnu korektnost sistema. Komponente jezika formalne specifikacije: Sintaksa - definiše specifičnu notaciju za zapis zahteva. Semantika - definiše objekte i njihovo značenje za opis sistema. Relacije - definišu pravila koja određuju koji objekat zadovoljava specifikaciju na pravi način. Upotreba Formalnih Metoda - Nisu mnogo zaživele među ljudima koji razvijaju SW. Razlozi: Teško razumevanje i učenje notacije. Problemi formalizovanja pojedinih aspekata zahteva. Učinak nije očigledan. Objektno-orijentisane metode - Nasledile su ER model. Bazirane su na sledećim metodama: Shlaer and Mellor (1988); Colbert (1989); Coad and Yourdon (1989); Wirf-Brock (1990); Rumbaugh (1991); Jacobson (1992); Martin- Odell (1992). Notacije su različite za različite metode, ali je semantika slična. Prikupljanje zahteva kod OO m. - U procesu prikupljanja zahteva, osnovni elementi koji se posmatraju su objekti. Objekti se dobijaju analizom domena problema. Objekti uključuju: Udeđaje sa kojima sistem interreaguje; Sisteme koji sarađuju sa sistemom koji se razvija; Organizacione jedinice; Stvari o kojima se moraju čuvati podaci; Fizičke lokacije; Specifične uloge ljudi Koraci OO m. - Većina OO metoda ima sledeće zajedničke korake u modeliranju sistema i prikupljanju zahteva: Identifikacija osnovnih objekata (klasa); Definisanje objektne strukture i veza između klasa; Definisanje atributa i servisa objekata; Definisanje poruka koje objekti razmenjuju. Atributi objekta - Atributi se dobijaju analizom zahteva Servisi objekata - U ovom koraku se vrši identifikacija servisa. Svakako mora da postoje servisi za pristup i izmenu atributa: Get - Set servisi. Jedan način identifikovanja servisa je praćenje poruka koje se razmenjuju između objekata. Use-case metoda - Sistem se posmatra sa stanovišta korisnika sistema. Opisuju se slučajevi korišćenja sistema i scenarija ponašanja. Koristi se UML notacija. Koristi se kod RUP modela razvoja SW-a. Scenarija događaja - Servisi objekata mogu biti otkriveni i modeliranjem scenarija događaja za različite funkcije sistema. Događaji se prate do objekata koji reaguju na njih. Tipičan model scenarija događaja je interakcija između korisnika i sistema. Scenarija - Scenarija su primeri kako će sistem biti korišćen u realnom životu. Oni bi trebalo da uključe: Opis početne situacije; Opis normalnog toka događaja; Opis izuzetaka (ako se izađe iz normalnog toka); Informacije o konkurentnim aktivnostima; Opis stanja gde se scenario završava. Slučajevi korišćenja - predstavljaju tehniku baziranu na scenarijima i zapisanu pomoću UML dijagrama koja identifikuje aktere u sistemu i slučajeve korišćenja sistema. Potpuni skup slučajeva korišćenja opisuje sve moguće interakcije korisnika sa sistemom. UML dijagrami sekvenci mogu biti korišćeni za detaljni opis slučajeva korišćenja. Oni daju sliku o obradi događaja u sistemu za izabrani slučaj korišćenja. RUP - Use-case specifikacija je izlaz iz faze razrade (elaboracije) i sadrži: Opis slučajeva korišćenja; Definisanje aktera u sistemu; Određivanje arhitekturno najznačajnijih slučajeva korišćenja Viewpoint - Osnovna ideja: Sistem se posmatra sa različitih tačaka (aspekata) posmatranja (iz ugla različitih korisnika sistema) i na taj način se pokušava da se sistem sagleda sa svih strana i da se identifikuju svi validni zahtevi, kao i da se razreše kontradiktorni zahtevi. Prednosti viewPoint - Eksplictno otkrivaju sve izvore zahteva za sistem. Obezbeđuju mehanizam organizovanja i struktuiranja svih zahteva. Pružaju osećaj potpunosti (kompletnosti). Tipovi viewPointa – 1) Direktni aspekti posmatranja – Ljudi ili drugi sistemi koji imaju direktnu interakciju sa sistemom. Na primer, kod sistema ATM bankomata, korisnici bankomata i baza bankovnih računa korisnika su

direktni VP-i. 2) Indirektni aspekti posmatranja – Korisnici koji ne koriste sistem direktno, ali imaju uticaja na zahteve sistema. Na primer, kod sistema ATM bankomata, menadžment i radnici obezbeđenja su indirektni VP-i.

3) Domenski aspekti posmatranja – Ograničenja i karakteristike domena koje imaju uticaja na zahteve. Na primer, kod sistema ATM bankomata, standardi za komunikaciju između banaka bi bili domenski VP-i. Identifikacija viewpointa - tražiti među: Pružaocima i korisnika servisa sistema; Sistemima sa kojima novi sistem treba da interreaguje; Propisima i standardima; Izvorima poslovnih i nefunkcionalnih zahteva. Inženjerima koji će razviti i održavati sistem; Marketinškim i ostalim poslovnim VP-ima.

Upravljanje projektima - 1 Upravljanje softverskim projektima - Odnosi se na aktivnosti koje treba da osiguraju da se softver isporuči na vreme i po planu, a saglasno zahtevima organizacije koja razvija SW i organizacije koja nabavlja SW. Upravljanje

projektom je potrebno zbog toga što je razvoj softvera uvek vezan za ograničenja po pitanju budžeta i radnog rasporeda koja postavlja organizacija koja razvija softver. Osobenosti upravljanja softverom - Proizvod je nevidljiv. Proizvod je fleksibilan. Softversko inženjerstvo nema status zdrave inženjerske discipline kao što su mašinstvo, energetika, itd. Proces razvoja softvera nije standardizovan. Mnogi softverski proizvodi su unikatni. Aktivnosti upravljanja - Pisanje predloga projekta. Planiranje i raspoređivanje projekta. Utvrđivanje cene projekta Monitoring i recenzija projekta. Izbor i evaluacija personala. Pisanje i prezentacija izveštaja Upravljanjem projektima i dr. inženjerske discipline - Aktivnosti upravljanja projektima nisu specifične za softverske projekte. Mnoge tehnike upravljanja inženjerskim projektima se mogu primeniti kod upravljanja softverskim projektima. Tehnički složeni inženjerski sistemi pate od istih problema kao i softverski sistemi. Izbor ljudi za rad na projektu - Za rad na projektima nije uvek moguće izabrati idealno osoblje iz više razloga: Budžet projekta ne dopušta angažovanje dobro plaćenog osoblja. Osoblje sa odgovarajućim veštinama nije raspoloživo. Organizacija želi da razvija veštine svojih zaposlenih za rad na SW projektima. Manadžeri mora da rade unutar ovih ograničenja posebno kada (što je trenutno slučaj) postoji internacionalni nedostatak obučenog IT osoblja. Planiranje projekta - Aktivnost upravljanja projektom koja nosi najviše vremena. Kontinualna aktivnost od inicijalnog koncepta do isporuke sistema. Planove treba revidirati kadgod je neka nova informacija raspoloživa. Treba razvijati različite tipove planova da bi se podržao glavni plan softverskog projekta koji se odnosi na raspored zadataka i budžet. Tipovi planova projekta (Tabelica ) - Plan kvaliteta: Opisuje procedure kvaliteta i standarde koji će se koristiti u projektu; Plan validacije: Opisuje prilaz, resurse i raspored koji će se koristiti za validaciju sistema; Plan upravljanja konfiguracijom - Opisuje procedure i strukturu upravljanja konfiguracijom koja će se koristiti; Plan održavanja - Predviđa zahteve za održavanjem sistema, potrebne troškove i napor; Plan razvoja osoblja - Opisuje kako će se razvijati veštine i iskustvo članova projektnog tima. Proces planiranja projekta - 1. Postaviti ograničenja projekta (datum isporuke, raspoloživo osoblje, budžet,..); 2. Odrediti inicijalne parametre projekta (struktura, veličina, distribucija funkcija); 3. Definisati kontrolne tačke i izlazne produkte projekta; 4. Sve dok projekat ne bude završen ili dok ne bude otkazan raditi sledeće: 1. Uraditi raspored projekta; 2. Inicirati aktivnosti prema rasporedu; 3. Čekati; 4. Nadgledati kako projekat napreduje; 5. Revidirati procene parametara projekta; 6. Ažurirati raspored projekta; 7. Ponovo ugovoriti ograničenja i izlazne produkte projekta; 8. Ako problem raste tada inicirati tehničku recenziju i možda reviziju Struktura plana projekta – 1) Uvod – Kratak opis ciljeva projekta i postavljanje ograničenja (budžet, vreme,…) koja

utiču na upravljanje projektom 2) Organizacija projekta – Opisuje način na koji će biti organizovan razvojni tim, ljudi

koji će učestvovati u timu i njihove uloge 3) Analiza rizika – Opisuje moguće rizike projekta, verovatnoću pojavljivanja rizika i strategije koje se predlažu za redukciju rizika. 4) Potrebni hardverski i softverski resursi – Specificira potreban HW i SW za rad na projektu. Ako HW ili SW treba nabaviti, specificira cene i raspored nabavke

5) Prekidi u radu – Deli projekat na aktivnosti i identifikuje kontrolne tačke I izlazne produkte za svaku aktivnost 6)

Raspored projekta – Prikazuje zavisnost među aktivnostima, daje procenu vremena potrebnog da se stigne do

svake kontrolne tačke i prikazuje raspored ljudi na aktivnosti 7) Mehanizmi monitoringa i izveštavanja – Definiše izveštaje koje treba pripremiti, kada će se ovi izveštaji raditi i koji će se mehanizmi koristiti za monitoring projekta. Organizacija aktivnosti - Aktivnosti u projektu treba organizovati tako da daju konkretne izlaze radi provere napredovanja projekta. Kontrolne tačke su krajnje tačke neke aktivnosti. Izlazni produkti su rezultati projekta koji se isporučuju kupcu. Proces vodopada omogućava dobro definisanje kontrolnih tačaka. Kontrolne tačke u inženjeringu zahteva (slika)

Raspored rada na projektu - Razbiti projekat na zadatke i proceniti vreme i resurse potrebne da se kompletira svaki zadatak. Organizovati zadatke konkurentno imajući u vidu optimizaciju radnog procesa. Minimizirati zavisnosti među zadacima kako bi se izbegao uticaj kašnjenja nekog zadatka na ostale. Zavisi od intuicije i iskustva rukovodioca (menadžera) projekta.

Problemi izrade rasporeda rada - Procena je problem i stoga je teško utvrditi troškove razvoja. Produktivnost nije proporcionalna broju ljudi koji rade na nekom zadatku. Dodavanje ljudi kada projekat kasni je loša odluka jer to dovodi do još većeg kašnjenja – problemi u komunikaciji. Ono što ne očekujete uvek će se desiti. Pri planiranju uvek dopustite eventualne događaje. Bar karte i mreže aktivnosti - Koristite grafičke notacije kao ilustraciju rasporeda rada na projektu. Prikažite podelu projekta na zadatke. Zadaci ne treba da budu suviše mali. Treba da traju 1 do 2 nedelje. Karte aktivnosti prikazuju zavisnosti među zadacima i kritični put. Bar karte prikazuju raspored rada na projektu prema kalendaru. Upravljanje rizikom - obuhvata identifikovanje rizika i skiciranje plana minimizacije uticaja rizika na projekat. Rizik je verovatnoća da se neka nepovoljna prilika pojavi. Rizici se razvrstavaju u 3 kategorije: Rizici projekta - utiču na raspored ili resurse; Rizici proizvoda utiču na kvalitet ili performanse SW koji se razvija; Rizici poslovanja - utiču na organizaciju koja razvija ili nabavlja SW. Proces upravljanja rizikom - Identifikacija rizika – Identifikovati projektne, proizvodne i poslovne rizike; Analiza rizika

– Proceniti verovatnoću i posledice identifikovanih rizika; Planiranje rizika – Skicirati planove da se izbegnu ili

minimiziraju uticaji identifikovanih rizika; Monitoring rizika – Nadgledati rizike u toku projekta.

Identifikacija rizika - To je proces pronalaženja mogućih rizika. Ne postoje pravila kako se to radi: Bitna je kritičnost I iskustvo menadžera projekta; Kao vodič menadžeru može poslužiti lista mogućih rizika. Postoje 6 tipova rizika: Tehnološki rizici; Ljudski rizici; Organizacioni rizici; Rizici zahteva; Rizici procene; Analiza rizika - Proceniti verovatnoću i ozbiljnost svakog rizika. Verovatnoća može biti vrlo niska (<10%), niska (10- 25%), srednja(25-50%), visoka (50-75%) i vrlo visoka (>75%). Efekti rizika mogu biti katastrofalni, ozbiljni, tolerišući ili beznačajni. Planiranje rizika - Razmotriti svaki rizik i razviti strategiju upravljanja svakim rizikom. Ne postoji prost proces da se napravi plan upravljanja rizikom. To zavisi od kritičnosti I iskustva menadžera projekta. Na sledećem slajdu prikazane su moguće strategije za ključne rizike. Strategije su podeljene u 3 kategorije: 1) Strategija izbegavanja: Smanjiti verovatnoću pojave rizika; Primenjeno kod defekata u komponentama. 2) Strategija minimizacije: Smanjiti uticaj rizika na projekat ili proizvod; Primenjeno kod bolesti osoblja. 3) Planovi za nepredviđene događaje: Ako se rizik pojavi, ovi planovi definišu kako se radi sa rizikom; Primenjeno kod finansijskih problema organizacije. Monitoring rizika - Proceniti svaki identifikovani rizik da bi videli da li je manje ili više verovatan. Takođe proceniti da li se efekti rizika menjaju. Svaki ključni rizik treba prodiskutovati na sastancima rukovodstva projekta. Faktori rizika – Tehnološki: Kasni isporuka HW ili SW podrška, više izveštaja o tehnoločkim problemima; Ljudi: Slab moral ljudi, slabe veze među članovima tima, raspoloživost poslova; Organizacioni: Glasine u organizaciji, nedostaju akcije starijeg menadžmenta; Alati: Odbijanje članova tima da koristi alate, žalbe na CASE alate, zahtevi za močnijim radnim stanicama; Zahtevi: Nogo zahteva za promenama zahteva, žalbe klijenta; Procena: Nemogućnost da se ostvari radni raspored, nemogućnost da se otklone uočeni defekti.

Arhitekturni modeli - 2 13.Arhitekturni modeli (stilovi) predstavljaju projektne obrasce za arhitekturu SW-a. Oni definišu komponente i konektore koji čine arhitekturu sistema. Na ovaj način, arhitektura sistema se može predstaviti kao graf čiji su čvorovi sledeće komponente: Procedure; Moduli; Procesi; Alati; Baze podataka; Grane (potege) grafa čine konektori koji mogu biti: Pozivi procedura; Prenosi događaja; Upiti baze podataka; Protočne obrade. 14:Repository model: Ovaj model se koristi kod sistema kod kojih je neophodno deljenje velikih količina podataka. Tada se organizuje centralno skladište podataka kome pristupaju podsistemi. Komponente: Centralna baza podataka. Skup SW komponenti koje pristupaju centralnoj bazi. Konektori: Pozivi procedura. Direktan pristup bazi podataka. 15:Repository model - karakteristike: Prednosti: Efikasan način za deljenje velike količine podataka; Podsistemi ne moraju da brinu o nekim aspektima upravljanja podacima kao što su backup, sigurnost,... Model deljenja podataka je prikazan u obliku šeme skladišta podataka. Nedostaci Podsistemi moraju da se slože oko skladišta podataka. Kompromis je neizbežan; Evolucija podataka je skupa; Otežana je distribucija podataka. Primer: Informacioni sistemi; Okruženja za razvoj SW-a; Grafički editori; Baze znanja u VI; Sistemi za reverse engineering

16.Pipe and Filter model: Ovaj model se koristi kod sistema kod kojih je neophodno izvršiti unapred definisane serije nezavisnih obrada nad podacima. Komponente prihvataju tokove podataka na ulazu i generišu tokove podataka na izlazu. Komponente: Komponente se često zovu i filtri koji vrše određene transformacije ulaznih podataka. Konektori: Konektori se često zovu pipe (cevovod) jer povezuju tokove i filtre (izlaz jednog filtra vode na ulaz drugog filtra). 16.1.Pipe and Filter - karakteristike: Prednosti: Lako razumevanje ulazno-izlaznog ponašanja celokupnog sistema kao skupa individualnih ponašanja filtera u sistemu; Lako je ponovno korišćenje filtera (reuse), jer je izme]u dva filtra već definisan format razmene podataka. Laka je izmena ili proširenje sistema (zamenom postoje’ih ili dodavanjem novih filtera). Prirodno je podržano konkurentno izvršenje. Nedostaci: Nije najbolji izbor kod interaktivnih sistema zbog velikog broja transformacija; Povećava kompleksnost sistema i smanjuje efikasnost; ( primeri Unix shell skriptovi Tradicionalni kompajleri (prevodioci)).

17.OO model: Ovaj model se koristi kod sistema kod kojih je neophodno izvršiti zaštitu i enkapsulaciju podataka. Podaci i pridružene operacije su enkapsulirane u apstraktne tipove podataka (klase i objekte). Komponente: Objekti Konektori: Metodi (servisi) objekata. 17.1.OO model karakteristike: Prednosti: Zbog skrivanja informacija od klijenata, moguće je promeniti implementaciju objekata bez uticaja na klijente; Moguće je projektovanje sistema kao skupa autonomnih agenata. Moguće je direktno mapiranje entiteta iz realnog sveta u objekte. Nedostaci: Neophodno je poznavanje indentiteta objekata. Ukoliko se izmeni identitet nekog objekta, moraju se izvršiti izmene i kod svih objekata koji ga pozivaju; Mogućnost pojave “bočnih efekata”;

18.Client-Server Model: Ovaj model se koristi kod distribuiranih sistema. Sastoji se od skupa stand-alone servera koji obezbeđuju specifične servise (štampa, Web, baza podataka,...), skupa klijenata koji pozivaju te servise i mreže koja omogućuje udaljeni pristup. Komponente: Serveri, klijenti. Konektori: Mreža, servisi servera.

18.1.Client-Server karakteristike: Prednosti: Efikasno korišćenje mrežnih sistema; Omogućava korišćenje slabijeg HW-a za klijente, obzirom da server odrađuje većinu posla. Lako dodavanje novih servera i upgrade postojećih. Nedostaci: Neefikasna razmena podataka između klijenata (moraju da idu preko servera); Redundantnost podataka. Ne postoji centralni registar imena servera i servisa; Nije lako otkriti koji serveri i servisi su na raspolaganju. 19.Slojeviti (Layered) Model: Ovaj model se koristi kod modeliranja interfejsa među podsistemima. Sistem se organizuje u skup slojeva (layera) od kojih svaki obezbeđuje jedan skup funkcionalnosti sloju iznad i služi kao klijent sloju ispod. Omogućava inkrementalni razvoj podkomponenti u različitim slojevima. Komponente: Slojevi. Konektori: Interfejsi. 19.1.Layered karakteristike: Prednosti: Promena interfejsa jednog sloja može da utiče na maksimalno još dva sloja; Laka zamena jednog sloja drugim ukoliko su im interfejsi identični. Baziran je na visokom nivou apstrakcije. Nedostaci: Ne mogu svi da se organizuju po ovom modelu.

20.Event driven model: (Implicitno pozivanje) Ovaj model se koristi kod sistema koji su upravljani eksterno generisanim događajima (events). Postoje dve osnovne grupe ovih modela: 1) Broadcast modeli 2) Interrupt-driven modeli. Komponente: Komponente i podsistemi koji generišu ili obrađuju evente. Konektori: Broadcast sistem i event procedure. 20.1.Broadcast modeli: Kod ove grupe modela, generisani događaj (event) se prosleđuje svim komponentama i podsistemima u sistemu. Svaka komponenta koja upravlja generisanim događajem može da obradi događaj. Efikasni su kod integracije podsistema koji se nalaze na različitim računarima u mreži. Podsistemi neznaju da li će i kada eventi biti obrađeni. Podsistemi se registruju za određene događaje i kada se oni generišu, upravljanje se prenosi na podsistem koji upravlja tim događajem.

20.2.Interrupt-driven modeli (modeli upravljani prekidima) Koriste se kod sistema za rad u realnom vremenu gde je osnovna stvar brzi odgovor sistema na neki događaj. Obezbeđuju brzu reakciju sistema na događaje, ali su komplikovani za realizaciju i pogotovo za testiranje i validaciju sistema.

20.3.Event driven karakteristike: Prednosti: Podrška višestrukom korišćenju SW-a (reuse); Laka evolucija sistema. Lako uvođenje nove komponente u sistem (jednostavno se registruje za neki event). Nedostaci: Kada komponenta generiše događaj ona ne može da zna da li će neka komponenta da odgovori na njega i kada će obrada događaja biti završena;

21.Control model: Koristi se kod sistema gde je potrebna centralizovana kontrola. Kontrolni podsistem upravlja tokom informacija između ostalih podsistema. Postoje četiri osnovne grupe ovih modela: Call-return modeli Manager modeli Feed-back modeli Open-loop modeli Komponente: Kontrolni algoritam i podsistemi. Konektori: Relacije između tokova podataka. 21.1.Call-return modeli: Kod ove grupe modela, kontrola kreće od vršnih podsistema i proteže se naniže (top-down pristup). Pogodni su za sekvencijalne sisteme.

21.2.Manager modeli: Ova grupa modela se primenjuje kod konkurentnih sistema. Jedna sistemska komponenta određuje početak, zaustavljanje i koordinaciju rada svih procesa u sistemu. 21.3.Feed-back modeli: Kod ove grupe modela, neke promenljive sistema se kontrolišu i njihove vrednosti se

koriste za podešavanje sistema.

21.4.Open-loop modeli (slika): Kod ove grupe modela, neke promenljive sistema se kontrolišu ali se njihove vrednosti ne koriste za podešavanje sistema.

Verifikacija i Validacija - 3 22.Verifikacija: SW treba da je usaglašen sa svojom specifikacijom - “Da li na pravi način gradimo proizvod” 23.Validacija: SW treba da radi ono što korisnik stvarno traži - “Da li gradimo pravi proizvod” 24.Ciljevi V&V procesa: Otkrivanje defekata u sistemu i Procena da li je sistem upotrebljiv i koristan u realnim uslovima Verifikacija i validacija - treba da utvrdi da softver odgovara nameni: To NE znači da je softver bez defekata; To znači da je softver dovoljno dobar za poslove kojima je namenjen. 25.V & V poverenje: Nivo poverenja zavisi od namene softvera, očekivanja korisnika i marketinškog okruženja. Funkcije softvera - Nivo poverenja zavisi od toga koliko je softver kritičan za organizaciju. Očekivanja korisnika: Korisnici mogu imati mala očekivanja od neke vrste softvera. Marketinško okruženje - Izneti proizvod ranije na tržište može biti važnije od nalaženja defekata u programu. 26.Statička verifikacija: Inspekcija softvera: Odnosi se na analizu statičkih reprezentacija sistema da bi se otkrili problemi (statička verifikacija) Mogu se koristiti alati za analizu koda i alati za pregledavanje dokumentacije koja je predmet inspekcije. Dinamička verifikacija - Testiranje softvera: Odnosi se na izvršenje i posmatranje ponašanja proizvoda (dinamička verifikacija) Sistem se izvršava sa test podacima i posmatra se kako se ponaša u radu.

Testiranje programa - Može otkriti prisustvo grešaka, a NE njihovo odsustvo. Jedina tehnika validacije nefunkcionalnih

zahteva budući da se sw izvršava da bi se videlo kako se ponaša. Može se koristiti zajedno sa statičkom verifikacijom da bi se u potpunosti pokrila V&V. 26.1.Tipovi testiranja: 1) Defektno testiranje: Testovi se projektuju da otkriju defekte u sistemu. Uspešan defekt test je onaj koji otkriva defekte u sistemu. Kako? Videćemo kasnije. 2) Validaciono testiranje: Cilj je pokazati da su ispunjeni zahtevi. Uspešan test je onaj koji pokazuje da su zahtevi implementirani na pravi način 27.Testiranje i debaging: Defektno testiranje i debaging su različiti procesi. Verifikacija i Validacija se bavi utvrđivanjem postojanja defekata u programu. Debaging se bavi lociranjem i reparacijom ovih grešaka. Debaging obuhvata formulisanje hipoteze o ponašanju programa, a zatim se testiranjem ove hipoteze nalaze greške. Proces debuginga (slika)

28.Planiranje verifikacije i validacije: V&V je skup proces, stoga je neophodno planiranje. Pažljivo planiranje zahteva mnogo toga što je van procesa inspekcije i testiranja .Planiranje treba početi u ranim fazama procesa razvoja. Plan treba da identifikuje balans između statičkog i dinamičkog prilaza verifikaciji i validaciji. Planiranje treba da identifikuje standarde i procedure za inspekciju i testiranje, listu grešaka za inspekciju, i da definiše plan testiranja softvera. V-model razvoja softvera (slika) 29.Inspekcija softvera: Cilj je ispitivanje izvorne reprezentacije SW radi otkrivanja anomalija i defekata. Inspekcija ne zahteva izvršenje SW tako da se može izvoditi pre njegove implementacije. Može biti primenjena na bilo koju reprezentaciju. SW (zahtevi, projekat, konfiguracioni podaci, test podaci, itd.). Pokazalo se da je vrlo efektivna tehnika za otkrivanje grešaka u programu. Uspešnost inspekcije - Jednom inspekcijom se može otkriti veliki broj različitih defekata – Kod testiranja jedan defekt može maskirati drugi tako da je potrebno više izvršenja. Pregledavači koriste domensko i programersko znanje tako da je velika verovatnoća otkrivanja grešaka. Fagan[1986]: inspekcijom je moguće detektovati >60% grešaka. Mills i ostali [1987]: prilaz inspekciji zasnovan na korektnosti argumenata može detektovati >90% grešaka. Gilb,Graham [1993]: najefikasnija primena je na slučajeve korišćenja. Inspekcija i testiranje - Inspekcija i testiranje su komplementarne verifikacione tehnike. Obe se koriste u V & V procesu. Inspekcija može proveriti saglasnost sa specifikacijom, a ne sa korisničkim zahtevima. Inspekcija ne može proveriti nefunkcionalne zahteve. 30.Inspekcija programa: Formalizovani prilaz pregledavanju dokumenata. Eksplicitno orijentisan detekciji defekata (ne korekciji). Defekti mogu biti logičke greške, anomalije u kodu ili nesaglasnost sa standardima. 31.Preduslovi za inspekciju: Mora biti na raspolaganju precizna specifikacija. Članovi tima moraju biti upoznati sa standardima organizacije. Mora biti na raspolaganju sintaksno korektan kod ili neka druga reprezentacija sistema. Treba pripremiti listu grešaka prema kojoj će se vršiti inspekcija. Menadžment mora prihvatiti da inspekcija povećava troškove. Menadžment nesme koristiti inspekciju za utvrđivanje ko od osoblja pravi propuste. Proces inspekcije 32.Procedura inspekcije: Kod i prateća dokumenta se unapred distribuiraju inspekcijskom timu. Inspekcijskom timu se prezentira SW. Vrši se inspekcija (program se sistematski analizira) i otkrivene greške se beleže. Nakon reparacije otkrivenih grešaka inspekcija se može ponoviti Inspekcijski tim - Uloge 6-članog tima - Autor ili vlasnik: Programer ili projektant koji je autor programa ili nekog dokumenta. Njegov zadatak je da locira i ukloni greške koje su inspekcijom otkrivene; Inspektor: Pronalazi greške u

programima ili dokumentima; Čitač: Prezentuje kod ili dokument inspekcijskom timu; Zapisničar: Vodi zapisnik u toku sastanka inspekcijskog tima; Moderator: Upravlja procesom inspekcije i obezbeđuje uslove da se inspekcija obavi. Izveštava šefa moderatora o rezultatima inspekcije. Šef moderator. Odgovoran je za poboljšanje procesa inspekcije, ažurira listu grešaka, razvija standarde, itd. Brzina inspekcije - 500 izvornih naredbi/čas može se prezentovati za vreme pregleda; 125 izvornih naredbi/čas može se ispitati za vreme individualne pripreme; 90-125 naredbi/času može se ispitati u toku jednog sastanka inspekcijskog tima; Inspekcija je skup proces; Inspekcija 500 linija košta oko 40 čovek/čas - oko £2800 u UK

Testiranje - 4 51. testiranje: Proces evaluacije sistema ili neke njegove komponente radi verifikacije da zadovoljava specificirane

zahteve ili da se identifikuju razlike između očekivanih i stvarnih rezultata. Proces koji se koristi da bi se

identifikovala korektnost, kompletnost, sigurnost i kvalitet razvijenog softvera – Izvršenje testova radi provere da

sistem ili aplikacija rade ili ne rade prema specifikaciji zahteva. Nakon testiranja program nije bez grešaka.

Testiranje 50% od razvoja SW

52. Test podaci: podaci odabrani za testiranje sistema ili neke njegove komponente

53.Test slučajevi: specifičan skup test podataka i pridruženih procedura razvijen sa određenim ciljem, kao što je da

se izvrši određeni put u programu, da se proveri određeni funkcionalni ili nefunkcionalni zahtev

54.Automatski test generator: – SW alat koji prihvata kao ulaz program koji treba testirati i kriterijume testiranja i

generiše test podatke koji zadovoljavaju zadate kriterijume testiranja i ponekad određuje očekivane rezultate

55. Generator test podataka : SW alat koji prihvata kao ulaz program koji treba testirati i kriterijume testiranja i

generiše test podatke koji zadovoljavaju zadate kriterijume testiranja

56.Generator test slučajeva : SW alat koji prihvata kao ulaz program koji treba testirati i kriterijume testiranja i

generiše test podatke koji zadovoljavaju zadate kriterijume testiranja i očekivane rezultate

57.Test bed: 1. Okolina za testiranje koja obuhvata HW, alate za instrumentiranje, simulatore, i ostalu SW podršku

neophodnu za testiranje sistema ili komponente sistema 2. Repertoar test slučajeva neophodnih za testiranje

sistema ili komponente sistema.

58.Greška (eng. error) je: 1. Razlika između izračunate, dobijene i izmerene vrednosti ili uslova i istinite,

specificirane ili teoretski tačne vrednosti ili uslova. 2. Neispravan korak, proces ili definicija podataka - Na primer,

nekorektna instrukcija u kodu 3. Netačan rezultat; 4. Ljudska aktivnost čiji je rezultat SW koji sadrži neki nedostatak

- Na primer, ispuštanje ili nepravilna interpretacija korisničkih zahteva u specifikaciji softvera, nekorektno

prevođenje ili ispuštanje nekog zahteva u specifikaciji projekta.

59.Pad (eng. failure): Nemogućnost sistema ili komponente da izvrši zahtevanu radnju sa specificiranim zahtevima

performansi

60.Nedostatak : Manifestacija greške -- Ljudska aktivnost čiji je rezultat SW koji sadrži neki nedostatak -- u softveru

61.Propust: Ljudska akcija koja proizvodi netačan rezultat

62. Klase tehnika za detekciju grešaka: Statička analiza: analiza zahteva, projekta, koda ili nekog drugog subjekta

bez

njegovog izvršavanja sa ciljem da se odredi da li su njegove leksičke i sintaksne osobine jednake unapred

predviđenim; Koristi se u svim fazama razvoja softvera; Statička analiza uključuje: inspekciju, proveru, čitanje koda,

analizu algoritama, grafičke tehnike za analizu kontrole toka i podataka, što se često koristi u automatskim alatima

za testiranje. Dinamička analiza i Formalna analiza.

Ciljevi procesa testiranja sw - Da otkrije nedostatke ili defekte u softveru zbog čega je ponašanje softvera

nekorektno,

neočekivano ili nije usklađeno sa svojom specifikacijom. Ovaj cilj se ostvaruje kroz defektno testiranje softvera.

Projektuju se test slučajevi koji treba da otkriju defekte. Defektno testiranje je testiranje programa da bi se otkrilo

prisustvo defekata u programu. Uspešan defekt test je test koji primorava program da se ponaša na abnomalan

način. Defekt testovi - pokazuju prisustvo, a ne odsustvo defekata.

63.Defektno testiranje: je testiranje programa da bi se otkrilo prisustvo defekata u programu.

63.1.Uspešan defekt: test je test koji primorava

program da se ponaša na abnomalan način

63.2.Defekt testovi: pokazuju prisustvo, a ne odsustvo defekata

64.Prilazi testiranju: Postoje dva prilaza testiranju (komplementarna su): Testiranje bez računara (otkriva 38-70%

logičkih grešaka i grešaka kodiranja): Inspekcija koda; Obilazak koda; Kodiranje na papiru; Testiranje pomoću

računara (korišćenjem sredstava za testiranje). Postoje različite strategije, metode i tehnike testiranja

65.Metode testiranja: Metode crne kutije, Metode sive kutije, Metode bele kutije. Kriterijumi za ovu kategorizaciju

metoda su: da li se pri razvoju test slučajeva pristupa izvornom kodu SW koji se testira i; da li se testiranje vrši preko

UI-a (User Interface) ili preko API-a

66.Metode crne kutije: Test inženjer pristupa SW koji testira preko interfejsa koji je namenjen krajnjim korisnicima

Predloženo je više metoda: Podela u particije ekvivalencije; Analiza graničnih vrednosti…

67. Metode bele kutije: Test inženjer pristupa izvornom kodu i može pisati kod koji linkuje sa bibliotekama koje su

linkovane sa SW koji se testira. Obično se koristi kod komponentnog testiranja

68.Metode sive kutije: Test inženjer može postaviti ili manipulisati nekom okolinom za testiranje i može videti

stanje SW posle svake akcije. Koriste ih gotovo isključivo klijent-server test inženjeri ili inženjeri koji koriste bazu

podataka kao repozitorijum informacija. Takođe ih mogu koristiti test inženjeri koji manipulišu XML fajlovima ili

konfiguracionim datotekama ili. Test inženjeri koji poznaju internu strukturu ili algoritam SW koji se testira i mogu

pisati testove specifično za određeni rezultat.

Testiranje metodom crne kutije - Prilaz testiranju gde se program posmatra kao ‘crna kutija’. Test slučajevi

programa se baziraju na specifikaciji sistema ili komponente. Pristup: Sistemu ili komponenti se dostavljaju ulazi i

ispituju se dobijeni izlazi. Ako se dobije izlaz koji se ne očekuje, tada se zaključuje da sistem ili komponenta ima neki

problem, tj. tada je test detektovao neki defekt. Kada se testira neka verzija sistema ili komponente, tada se biraju

test-slučajevi iz skupa Ie koji imaju veliku verovatnoću da će otkriti neki defekt izlaz iz skupa Oe) .

Metod crne kutije (Slika) - 1) Ulazi koji izazivaju anomalije u ponašanju 2) Pri testiranju neke verzije sistema ili

komponente biraju se test-slučajevi iz skupa Ie koji imaju veliku verovatnoću da će otkriti neki defekt (izlaz iz skupa

Oe). 3) izlazi koji otkrivaju prisustvo defekata.

69.Podela u particije ekvivalencije: Ulazni podaci i izlazni rezultati programa se mogu razvrstati u veći broj klasa

koje imaju neke zajedničke karakteristike. Svaka od ovih klasa je jedna particija (ili domen) ekvivalencije gde se

program ponaša na ekvivalentan način za sve članove klase. Jedan sistematski prilaz za projektovanje test slučajeva

je: Identifikovati sve particije ekvivalencije za sistem ili komponentu koja se testira. Projektovati test-slučajeve:

treba izabrati bar po jedan test-slučaj iz svake particije ekvivalencije; Preporuka: Treba izabrati po jedan test-slučaj

na granicama particija i bar jedan iz sredine particije.

Particije ekvivalencije (Slika) - Elipse su particije ekvivalencije. Ulazne particije ekvivalencije su skupovi podataka

koji se obrađuju na isti način. Izlazne particije ekvivalencije su izlazi programa koji imaju zajedničke karakteristike,

tako da se mogu smatrati različitim klasama. Takođe se identifikuju particije sa ulazima koji su van izabrane

particije. Čime se proverava da li program korektno rukuje ulazima koji nisu validni.

70.Ulazne particije ekvivalencije: su skupovi podataka koji se obrađuju na isti način.

Izlazne particije ekvivalencije su izlazi programa koji imaju zajedničke karakteristike, tako da se mogu smatrati

različitim klasama

71.Podela u particije ekvivalencije: Ako je ulaz petocifreni ceo broj iz opsega 10000 i 99999 Izabrati test slučajeve

na granicama ovih particija: 00000, 09999, 10000, 99999, 10001

72.Strukturno testiranje: Ponekad se naziva testiranje po metodi “bele kutije”. Jedan od prilaza za projektovanje

test

slučajeva gde se test slučajevi izvode iz strukture i implementacije programa. Za identifikovanje dodatnih test

slučajeva

koristi se znanje o programu.

73.Kriterijumi strukturnog testiranja

73.1. Pokrivanje naredbi – Svaka naredba programa treba da se izvrši bar jedanput

73.2.Pokrivanje odluka – Svaka odluka u programu treba da se pokrije sa TRUE i FALSE bar jedanput i

da se svaki ulaz pozove bar jedanput; ovaj uslov pokriva prethodni

73.3. Pokrivanje uslova – SvakI uslovu programu treba da se pokrije sa TRUE i FALSE bar jedanput i

da se svaki ulaz pozove bar jedanput

73.4. Pokrinje odluka/uslova – Svaka odluka treba da se testira na sve izlaze i da se svaki uslov pozove bar

Jedanput; Nedostatak je što se uslovi mogu međusobno pokrivati

73.5. Pokrivanje višestrukih uslova – Sve kombinacije uslova u odluci treba da se pokriju sa TRUE i FALSE bar

jedanput i da se svaki ulaz pozove bar jedanput; ovaj uslov pokriva prethodne

73.6. Pokrivanje puteva – Proći svakim putem u CFG-u; Ova

Pokrivanje odluka/uslova (Myers) (slika)

Pokrivanje višestrukih-uslova (slika) - Sve kombinacije uslova u odluci treba da se pokriju sa TRUE i FALSE bar

jedanput i da se svaki ulaz pozove bar jedanput; ovaj uslov pokriva prethodne.

Testiranje puteva - Cilj je obezbediti da skup test slučajeva bude takav da se svaki nezavistan put programa izvrši bar jedanput. Ako se svaki nezavistan put u programu izvrši, tada sve naredbe u programu moraju biti izvršene bar jedanput. Dalje, sve uslovne naredbe u programu treba da se izvrše bar jedanput. U OO razvoju programa testiranje puteva se može koristiti za testiranje metoda. Početna tačka testiranja puteva je graf toka programa (čvorovi predstavljaju odluke, grane tokove upravljanja). Naredbe sa uslovima su čvorovi u grafu toka. Nezavistan put programa je onaj put koji prolazi bar jednom novom granom u grafu toka programa: Izvršenje 1 ili više novih uslova; Moraju se izvršiti obe grane čvora grananja (True i False). Ciklomatična složenost - Broj testova za testiranje svih upravljačkih naredbi jednak je ciklomatičnoj složenosti. Kod strukturnih programa ciklomatična složenost je jednaka broju uslova u programu +1. Korisna ako se pažljivo koristi. Izvršenje svih puteva ne znači izvršenje svih kombinacija puteva. Model procesa testiranja softvera (slika)

Test slučaj - U SWE test slučaj je skup uslova na osnovu kojih tester može utvrditi da li SW delimično ili potpuno ispunjava neki zahtev. Za testiranje SW potreban je veliki broj test slučajeva. RUP preporučuje kreiranje bar po 2 test slučaja za svaki zahtev - jedan bi trebao da izvrši testiranje da je zahtev zadovoljen, a drugi da nije. Test slučaj treba da sadrži opis funkcionalnosti koja se testira i kako treba pripremiti okruženje da bi bili sigurni šta testiramo. Struktura test slučaja - Uvod – sadrži opšte informacije o test slučaju: Identifikator – jedinstvenu oznaku test slučaja – Vlasnik ili kreator test slučaja; Verzija definicije test slučaja; Naziv test slučaja; Identifikator zahteva koji je pokriven ovim test slučajem; Namena – koja se funkcionalnost testira; Zavisnosti. Aktivnost test slučaja: Okruženje/konfiguracija test slučaja- potreban HW i SW koji mora biti obezbeđen da bi se izvršio test slučaj. Inicijalizacija – šta treba da se obezbedi pre izvršenja test slučaja (npr. da se otvori datoteka). Finalizacija – opis akcije koja treba da se uradi nakon izvršenja test slučaja, (npr. ako test slučaj obori bazu treba je oporaviti pre nego što se test slučaj ponovo izvrši). Akcije – šta treba uraditi korak po korak da bi se test kompletirao; Ulazni podaci. Očekivani rezultati – opisuje šta će tester videti posle izvođenja svih koraka Test garnitura je termin za kolekciju test slučajeva. Test garnitura sadrži detaljne instrukcije ili ciljeve svake kolekcije test slučajeva. Sadrži sekcije: identifikator konfiguracije sistema u toku testiranja, preduslove i post uslove za grupu test slučajeva, opise sledećih testova. Kolekcije test slučajeva se ponekad nekorektno nazivaju test plan, test skripta ili test scenario. Test skripta je kratak program koji se piše na nekom programskom jeziku za testiranje neke funkcionalnosti SW sistema: koriste se kod komponentnog, sistemskog ili regresionog testiranja, a pišu ih testeri za mnoge metode bele kutije; mnoge kompanije koje koriste automatsko testiranje koriste termin test skripta za kod koji se koristi u tim alatima. Napisani skup koraka koje treba izvesti ručno može se takođe nazvati test skriptom. Mada je korektnije test slučaj. Svaki test napisan kao kratak program se posmatra kao automatski test. Test skripte se pišu korišćenjem specijalnih test alata ili programskih jezika opšte namene (kao što su C++, Tcl, Expect, Java, Perl, Python, ili od nedavno, Ruby). Test scenario je test zasnovan na hipotetičkoj priči koja se koristi da pomogne proces razmišljanja o kompleksnom problemu ili sistemu; Može biti predstavljen dijagramom ili tekstom; Test slučajevi su koraci scenarija; Test garnitura i scenario se mogu koristiti zajedno za kompletno testiranje sistema. Proces testiranja – 1) Komponentno testiranje: Inženjer razvoja softvera. Testiranje komponenti programa. Testovi se formiraju na osnovu iskustva inženjera razvoja SW. Metode bele kutije. 2) Sistemsko testiranje: Nezavistan tim za testiranje. Testiranje grupe komponenti integrisanih u sistem ili podsistem. Testovi se formiraju na osnovu specifikacije SW. Testiraju se funkcionalni i nefunkcionalni zahtevi. Metode crne, bele ili sive kutije. 3) Prijemno testiranje: Nezavistan tim za testiranje. Testiranje programa u radnom okruženju pomoću podataka Korisnika. Otkrivaju se propusti u definiciji zahteva. Metode crne kutije.

Koraci testiranja - Komponentno testiranje: Testiraju se pojedinačne komponente; Testiranje modula: Testiraju se povezane kolekcije zavisnih komponenti; Testiranje podsistema: Moduli se integrišu u podsisteme i testiraju. Fokus je na testiranju interfejsa. Testiranje sistema: Testiranje sistema u celini; Testiranje bitnih svojstava. Prijemno testiranje

– Testiranje sa podacima korisnika da bi se proverilo da li je sistem prihvatljiv za korisnika. Faze testiranja u SWprocesu (slika)

Prost ciklus testiranja - Analiza zahteva: Testiranje SW počinje u fazi prikupljanja i analize zahteva životnog ciklusa softvera. Analiza projekta: U fazi projektovanja softvera test inženjeri rade zajedno sa projektantima

da bi utvrdili koji se aspekti projekta mogu testirati i kako. Planiranje testiranja – Strategija testiranja, plan

testiranja, kreiranje test bedova. Razvoj testova – Razvijaju se test procedure, test scenarija, test slučajevi i test skriptovi

koji će se koristiti u toku testiranja SW. Izvršenje testova – Test inženjeri izvršavaju SW prema planu testiranja i sa

razvijenim testovima i izveštavaju razvojni tim o nađenim greškama. Izveštavanje o testiranju – Nakon završetka testiranja, test inženjeri generišu metrike i formiraju finalne izveštaje o testiranju i izvode zaključak da li je testirani SW spreman za isporuku. Retestiranje defekata. Integraciono testiranje - Testiraju se kompletni sistemi ili podsistemi sastavljeni od integrisanih komponenti.

Integraciono testiranje je testiranje po metodi crne kutije sa testovima koji su izvedeni iz specifikacije. Prilazi: – Monolitno; Inkrementalno. Glavni problem je lokalizacija grešaka. Inkrementalno integraciono testiranje redukuje ovaj problem. Inkrementalno integraciono testiranje (slika)

Strategije integracionog testiranja - Top-down testiranje – Startuje se sa najvišim nivoom sistema i sistem se

integriše s vrha ka dnu, pri čemu se netestirane komponente zamenjuju stabovima (stub). Bottom-up testiranje – Integrišu se komponente po nivoima s dna ka vrhu sve dok se ne integriše sistem. Za integraciju se koriste drajverski moduli. U praksi se koristi kombinacija ovih strategija. Top-down testiranje (slika)

Bottom-up testiranje (slika)

komentari (0)
nema postavljenih komentara
budi prvi koji ce napisati!
ovo je samo pregled
3 prikazano na 30 str.
preuzmi dokument