Projektovanje informacionih sistema Information Systems Design - Uvodna predavanja -

1. Prof. dr Angelina Njeguš Vanredni profesor Univerziteta Singidunum anjegus@singidunum.ac.rs Beograd, 2008/2009. Projektovanje informacionih sistemaInformation Systems Design- Uvodna predavanja -

2. Softverski inženjering • Formalne definicije softverskog inženjeringa: • Inženjerska disciplina koja se bavi svim aspektima proizvodnje softvera • Disciplina koja obuhvata znanje, alate i metode za definisanje zahteva, razvoja softvera, rukovanje i održavanje softvera • Istorija razvoja softverskog inženjerstva : • 1940-te: ručno pisanje mašinskog koda • 1950-te: prvi alati, kao što su makro asembleri i interpreteri; prva generacija kompajlera • 1960-te: druga generacija alata kao što su optimizovani kompajleri; mainframe računari i softveri za velike korporacije • 1970-te: kolaborativni alati kao što su Unix; miniračunari i rast manjih poslovnih softvera • 1980-te: personalni računari (PC) i radne stanice; rast potrošačkih softvera • 1990-te: objektno-orjentisano programiranje i agilni procesi (npr., Extreme Programming); drastičan pad cena kapaciteta memorije računara i hardvera uopšte; WWW i PDA računari omogućavaju široku upotrebu softvera i rast sve kompleksnijih softvera • 2000-te: Upravljani kodovi i platforme kao što su Java, .NET, PHP i dr. čine pisanje softvera lakšim nego ikad. Web servisi, SOC (Service-oriented computing), SOA (servisno-orijentisana arhitektura) i sl.

3. Softverski procesi • Svi softverski procesi koriste procedure u realizaciji procesa, s tim što su neki formalniji, tj. sadrže niz strogo definisanih procesnih koraka, striktne uloge, dokumentaciju i dr. (tzv. teški procesi), dok su drugi procesi adaptivniji, odnosno agilniji (okrenuti ljudskoj dimenziji, efikasnost kolaboracije ljudi koji prave i koriste softver u cilju dobijanja poslovne koristi). • Zajednički principi kod agilnih metoda u razvoju softvera: • Individue i interakcije između njih su važnije od procesa i alata • Softver koji radi je važniji od dokumentacije koja raste • Saradnja sa korisnicima je važnija od procesa ugovaranja • Odziv na promene je važniji od striktnog pridržavanja i praćenja plana • Striktna podela uloga, karakteristična za proceduralno orijentisane metode, se agilnim pristupom zamenjuju zajedničkom podelom znanja i odgovornosti za izvršavanje posla na nivou tima • Agilni – sazrevanje u vremenu; realizacija softvera koji se adaptira promenama okoline i promenama u zahtevima; oslanjanje na povratnu spregu radi analize rezultata svake iteracije od strane korisnika i usmeravanje toka sledeće iteracije

4. Vodopad životni ciklus razvojaWaterfall Development Lifecycle • Vodopad pristup ne može adekvatno da se bori sa sve većom kompleksnošću koja nastaje: • Produženim trajanjem projekta • Sve većom veličinom aplikacije • Velikim ili distribuiranim timovima • Povećanom tehničkom kompleksnošću • Novinama u tehnologijama • Glavni problem ovog pristupa je što ne omogućava identifikovanje i umanjenje rizika u ranim fazama projekta

5. Šta se dešava u praksi

6. Iterativni razvoj Iterative Development • Iterativni razvoj je pristup razvoju softvera u kome se životni ciklus softvera sastoji od nekoliko sekvencijalnih iteracija • Svaka iteracija je poseban mini-projekat koji se sastoji od aktivnosti kao što su analiza zahteva, dizajn, programiranje i testiranje • Iteracije u prvim fazama ukazuju na najveće rizike • Svaka iteracija proizvodi izvršne verzije • Svaka iteracija uključuje integraciju i testiranje • Cilj završetka iteracije je stabilan, integrisan, testiran deo celokupnog softverskog sistema koji se gradi • Razlika između dve sukcesivne iteracije je inkrement. Inkrement predstavlja razliku u ispunjenju funkcionalnih zahteva između posmatrane iteracije i iteracije koja joj neposredno prethodi implementirane u kodu

7. Profil boljeg napretka

8. Proceduralni vs. agilni pristup

9. Proceduralni vs. agilni pristup

10. Objedinjeni proces • Veliki broj proceduralnih procesa se primenjuje u razvoju OO softvera: OMT, Booch, MSF i dr. • Objedinjeni proces (Unified Process) nastaje ujedinjavanjem pristupa projektovanja softverskih sistema koji su formulisani od strane vodećih stručnjaka (Jacobson, Booch, Rumbaugh) • Glavni sponzor razvoja ove metodologije je bila firma Rational (vodeći prodavac CASE alata) otuda naziv Rational Unified Process ili kraće RUP • RUP se može svrstati i u kategoriju lakih procesa tzv. agilni UP, ako bi se iz UP-a izdvojio skup samo neophodnih artifakta za dati projekat. • RUP se oslanja na UML (Unified Modelling Language) koji služi za specifikaciju, vizuelizaciju, konstrukciju i dokumentaciju razvoja softvera • UML je brzo postao standardni jezik za modelovanje poslovnih potreba i softverskih aplikacija • UML je projektovan kao fleksibilni i prilagodljiv jezik i ne mora se samo koristiti za modelovanje objektno orijentisanih aplikacija.

11. RUP je pristup razvoja softvera koji je iterativan, centriran oko arhitekture i vođen slučajevima korišćenja Osnovni koncepti u RUP: Iterativno inkrementalni proces u razvoju softvera je proces koji obezbeđuje da sistem koji se razvija inkrementalno raste u vremenu iz iteracije u iteraciju Milestone (kontrolna/ključna/kritična tačka) Svaka faza u razvoju projekta se završava sa nekim milestone-om koji sumiraju rezultate svih prethodnih iteracija i u njoj se donose značajne odluke za ceo projekat u celini, u zavisnosti od toga da li su svi ciljevi i uslovi koji su bili definisani za tu tačku ispunjeni Role definišu ponašanja i odgovornosti pojedinca ili tima Artifakti: Dokumenta: beleže zahteve sistema, kao i upotrebljivost, pouzdanost, performanse i podršku zahtevima Model: pojednostavljeni pogled sistema koji prikazuje osnovni sistem bez nepotrebnih detalja Elementi modela: pomaže timu da vizuelizuju, konstruišu i dokumentuju strukturu i ponašanja sistema Rational Unified Process – RUP

12. Faze iterativnog razvoja • Životni ciklus softvera prema RUPu je dekomponovan tokom vremena u četiri sekvencijalne faze koje se završavaju glavnim kontrolnim tačkama • U početnoj fazi (inception): razumevanje šta treba graditi • Vizija, zahtevi visokog nivoa, poslovni slučajevi korišćenja • Identifikovanje rizika • Procena troškova, vremena, plana i kvaliteta proizvoda • Inicira se kreiranje poslovne studije opravdanosti ulaženja u projekat • Faza elaboracije (elaboration): razumevanje kako treba graditi • Osnovna arhitektura, većina zahteva je detaljna • Dizajn nije detaljan • Precizna procena resursa i vremena • Konstrukcija (construction): izgradnja proizvoda • Rad na proizvodu, završeno testiranje sistema • Tranzicija (transition): validacija rešenja • Prihvatljivost od strane stejkoldera

13. Iteracije i faze • U okviru svake faze razvija se proces kroz niz iteracija i inkrementa • Na kraju svake iteracije proverava se šta je urađeno i da li se u međuvremenu pojavio ili promenio neki zahtev čime se kontroliše nivo rizika za sledeću iteraciju • Strategija razvoja softvera korišćenjem ove metode je u malim koracima kojim se upravlja, a koji svaki za sebe može predstavljati mini projekat • Cilj je dobiti što kvalitetniji rezultat u posmatranom vremenu, a ne da se iza maske velikog projekta sakrije neefikasnost i loši rezultati • Svaka iteracija kao završetak ima implementiran kod

14. Graf iterativnog životnog ciklusa

15. Pregled RUP koncepata • Discipline prikazuju sve aktivnosti kroz koje se mora proći kako bi se proizveo određeni skup artifakta. Ove discipline se opisuju kroz role, aktivnosti i uključene artifakte • Tokovi posla (workflow) grupiše aktivnosti koje se zajedno odvijaju

16. Početna faza (Inception) – Šta razvijati • Pripremiti dokument vizije i inicijalnih poslovnih slučajeva korišćenja • Uključiti ocenu rizika i procenu resursa • Razviti projektne zahteve visokog nivoa • Inicijalni slučajevi korišćenja i modeli domena (10-20% završeno) • Upravljati domenom projekta • Umanjiti rizike tako što će se identifikovati svi ključni zahtevi • Saznanje da će se zahtevi menjati • Upravljati promenama kroz iterativne procese

17. Ciljevi početne faze • Cilj 1: Razumeti šta se razvija • Složiti se oko vizije • Navesti ključne aktere i slučajeve korišćenja (preliminarni model slučajeva korišćenja) • Identifikovati sve aktere • Pridružiti svakog aktera slučajevima korišćenja • Ukratko objasniti svakog aktera i slučajeve korišćenja sa 1 do 2 rečenice • Napraviti rečnik (definiše opštu terminologiju za sve modele i sadrži tekstualni opis zahtevanog sistema) • Identifikovati najosnovnije i kritične slučajeve korišćenja (<20% slučajeva korišćenja) • Odrediti domen sistema • Navesti detaljne ključne nefunkcionalne zahteve

18. Slučaj Korišćenja Use Case AkterActor Osnovni koncepti u modelu slučajeva korišćenja Akter (učesnik) predstavlja osobu ili drugi sistem koji je u interakciji sa sistemom • Akteri su obično ljudi, hardverski uređaji i dr. sistemi koji su u interakciji sa sistemom Slučaj korišćenja (use case) definiše sekvencu akcija koje sistem izvršava, a predstavlja rezultat od određene vrednosti za aktera. • Use case predstavlja glavni deo neke komplentne funkcionalnosti od početka do kraja • Npr. student mora da izabere kurseve za semestar, da se upiše i uplati izabrane kurseve (use case: registrovanje na kurseve) • Npr. sekretar mora da dodaje, briše i modifikuje kurseve (use case: održavanje nastavnog plana, jer započinje isti akter i radi sa istim entitetima u sistemu)

19. Use case model opisuje funkcionalne zahteve sistema u terminima slučajeva korišćenja Primer UML dijagrama Slučaj korišćenja

20. Ciljevi početne faze (nastavak) • Cilj 2: Identifikovati ključne zahteve • Funkcionalnost je jezgro aplikacije • Iscrtati ključne interfejse • Navesti rizike koji se odnose na performanse, redundnantnost, bezbednost podataka, ... • Cilj 3: Odrediti najmanje jedno potencijalno rešenje • Trebalo bi odgovoriti na pitanja od bitnog uticaja: • Da li možete razviti aplikaciju sa manjim brojem rizika, a pri prihvatljivim troškovima. • Da li ste razvijali slične sisteme? Sa kojom arhitekturom i sa kojim troškovima? Da li će trenutna arhitektura raditi ili će biti potrebno redizajnirati? • Profil osoblja – Da li ste u mogućnosti da angažujete osoblje sa pravim kompetencijama? • Da li se zahtevaju softverske komponente? Da li se mogu nabaviti? Pri prihvatljivim troškovima?

21. Ciljevi početne faze (nastavak) • Cilj 4: Razumevanje troškova, rasporeda i rizika • Poslovni slučajevi • Da li treba da finansiramo projekat • Troškovi • Povratak investicija (ROI) • Plan razvoja softvera • Plan projekta • Potreba za resursima • Cilj 5: Razumevanje koje procese pratiti i koje alate koristiti

22. Faza elaboracije – kako razvijati • Detaljni zahtevi (~80% završiti) • Postaviti izvršnu i stabilnu arhitekturu • Definisati, implementirati i testirati interfejse glavnih komponenti • Identifikovati zavisnost spoljnih komponenti i sistema • Neke ključne komponente će biti parcijalno implementirane • Grubo 10% koda će biti implementirano • Arhitektura sa ključnim slučajevima korišćenja • 20% slučajeva korišćenja nose 80% arhitekture • Projektovati, implementirati i testirati ključna scenarija za slučajeve korišćenja • Verifikovati arhitekturu • Pouzdanost: stres test (proverava ponašanje sistema kada je na izmaku resursa ili kada se za resurse treba boriti, npr. prevazilaženje deadlock stanja) • Skalabilnost i performanse: test punjenja • Kontinualna procena poslovnih slučajeva korišćenja, rizika i plana razvoja

23. Ciljevi faze elaboracije • Cilj 1: Detaljnije razumevanje zahteva • Sa 20% slučajeva korišćenja obuhvatiti 80% zahteva • Izgraditi prototipe grafički orjentisanih slučajeva korišćenja • Proći kroz slučajeve korišćenja sa stejkholderima • Cilj 2: Projektovati, implementirati, vrednovati i postaviti arhitekturu • Doneti kritične odluke: kupiti ili razvijati, paterni, ... • Skicirati osnovnu strukturu vašeg sistema. Dokument arhitekture softvera predstavlja sveobuhvatan pregled arhitekture softverskog sistema. Uključuje: poglede, ciljeve i ograničenja, veličinu i performanse, kvalitet, proširljivost i portabilnost. • Izvršiti inicijalni test performansi

24. Ciljevi faze elaboracije (nastavak) • Cilj 3: Umanjiti osnovne rizike i napraviti precizniji raspored i proceniti troškove • Ključni rizici: • Tehničke rizike - umanjiti implementiranjem i testiranjem arhitekture • Poslovne rizike - implementiranjem i testiranjem ključnih funkcionalnosti sistema • Timske rizike – tim treba da prođe kroz ceo životni ciklus softvera implementirajem realnog koda • Cilj 4: Uvođenje razvojnog okruženja • Zasniva se na prethodnom iskustvu tima • Kastimizacija i poboljšanje okruženja alata ukoliko je potrebno • Obučavati članove tima i uvoditi alate

25. Iteracija 1 Projektovati, implementirati i testirati manji broj kritičnih scenarija Identifikovati, implementirati i testirati manji skup paterna Uraditi preliminarni logički dizajn baze podataka Detaljan tok događaja počevši od najvažnijih slučajeva korišćenja Testirati kako bi se umanjili rizici Iteracija 2 Popraviti sve ono što nije radilo u prethodnoj iteraciji Projektovati, implementirati i testirati ostatak scenarija Uočiti ključne rizike implementiranjem konkurentnosti, procesa, niti i fizičke distribucije Fokusirati se na testove performansi, punjenja i interfejsa Identifikovati, implementirati i testirati paterne Projektovati, implementirati i testirati preliminarnu verziju baze podataka Detaljnije obraditi i ostalih 50% slučajeva korišćenja Testirati arhitekturu u slučaju redizajna Višestruke iteracije kod faze elaboracije

26. Scenario • Svaki use case ima tok događaja koji pokazuje šta sistem radi, ali ne i kako će sistem biti projektovan • Tok događaja use case-a ima jedan normalan, osnovni tok i nekoliko alternativnih tokova • Jedan tok događaja se naziva instanca use case-a ili scenario • Slučajevi korišćenja mogu imati mnogo instanci • Instanca slučaja korišćenja je jednostavan tok događaja u sistemu, obično iniciranih od strane aktera • Slučaj korišćenja opisuje skup povezanih scenarija • Scenario opisuje instancu slučaja korišćenja: određena sekvenca akcija koje opisuju ponašanje sistema

27. Primer: Specifikacija use case-a“Odabiranje kurseva koji će se predavati” 1.0 Use case name Odabiranje kurseva koji će se predavati 1.1 Brief Description Ovaj use case pokreće Profesor. Omogućava da profesor izabere do četiri kursa koja će predavati tokom izabranog semestra 2.0 Flow of Events (tok događaja) 2.1 Osnovni tok (basic flow) Ovaj use case počinje kada se profesor prijavi na sistem za registraciju i unese svoju lozinku. Sistem verifikuje da je lozinka valjana (ukoliko lozinka nije valjana izvršava se alternativni tok 2.2.1) i signalizira da profesor izabere tekući ili budući semestar (ukoliko se unese pogrešan semestar, izvršava se alternativni tok 2.2.2). Profesor unosi željeni semestar. Sistem signalizira da profesor izabere željenu aktivnost: add, delete, review, print ili quit. Ukoliko je izabrana aktivnost Add, sistem prikazuje ekran sa poljem za unos naziva i broja kursa. Ukoliko profesor unese nevažeću kombinaciju ime/broj, izvršava se alternativni tok 2.2.3). Sistem prikazuje nuđene opcije za taj kurs (ako ime kursa ne može da se prikaže izvršava se alternativni tok 2.2.4). Profesor bira neku od ponuda. Sistem povezuje tog profesora sa izabranom ponudom (ukoliko veza ne može da se napravi, izvršava se alternativni tok 2.2.5). Zatim, use case ponovo počinje. Ukoliko je izabrana opcija Delete, sistem prikazuje ekran sa nuđenim opcijama za taj kurs sa poljem za ime opcije i za broj. Profesor unosi ime i broj opcije (ako se unese nevažeća kombinacija ime/broj, izvršava se alternativni tok 2.2.3). Sistem uklanja vezu sa tim profesorom (ako veza ne može da se ukloni, izvršava se alternativni tok 2.2.6). Tada use case ponovo počinje. Ukoliko je izabrana aktivnost Review, sistem poziva (ako informacija o kursu ne može biti pozvana, izvršava se alternativni tok 2.2.7) i prikazuje sledeće informacije o svim opcijama kurseva koje su njemu dodeljene: ime kursa, broj kursa, broj opcije kursa, dane u nedelji, vreme i lokaciju. Kada profesor ukaže da je on ili ona završio pregledanje, use case ponovo počinje. Ukoliko je izabrana aktivnost Print, sitem štampa profesorov raspored (ukoliko raspored ne može da bude odštampan, izvršava se alternativni tok 2.2.8). Use case ponovo počinje. Ukoliko je izabrana aktivnost Quit, use case se završava.

28. Primer: specifikacija use case-a (nastavak) 2.2 Alternativni tokovi 2.2.1 Nevažeća lozinka Unešena je nevažeća lozinka. Korisnik može ponovo da je unese ili da okonča use case. 2.2.2 Nevažeći semestar Sistem obaveštava korisnika da je semestar nevažeći. Korisnik može ili ponovo da unese semestar ili da okonča use case 2.2.3 Nevažeće ime/broj kursa Sistem obaveštava korisnika da je nevažeće ime/broj kursa. Korisnik može ponovo da unese valjanu kombinaviju ili da okonča use case 2.2.4 Opcija kursa ne može da se prikaže Korisnik biva informisan da ta opcija nije trenutno dostupna. Use case ponovo počinje 2.2.5 Ne može da se uspostavi veza između profesora i opcije kursa Ova informacija je zapamćena i sistem će kasnije uspostaviti tu vezu 2.2.6 Veza između profesora i opcije kursa ne može da se ukloni Ova informacija ostaje zapamćena i sistem će kasnije ukloniti tu vezu 2.2.7 Ne može da se dobije informacija o rasporedu Korisnik se obaveštava da ova opcija trenutno nije dostupna 2.2.8 Raspored ne može da se odštampa Korisnik se obaveštava da ova opvija trenutno nije dostupna 3.0 Special Requirements Za ovaj use case ne postoje posebni zahtevi

29. Primer: Specifikacija use case-a (nastavak) 4.0 Preconditions (preduslovi) 4.1 Pre nego što se pokrene ovaj use case mora biti završen podtok Create Course Offerings (Napravi opcije kursa) use case-a Maintain Course Information (Održavaj informacije o kursevima) 5.0 Post Conditions (post uslovi) Ne postoje krajnji uslovi 6.0 Extension Points Ne postoje tačke proširivanja

30. Slojevit pristup (layering approach) • Na slici je prikazan primer arhitekture sa četiri sloja: • Najviši sloj, sloj Aplikacije, sadrži servise koji su specifični za aplikaciju • Sledeći sloj, Biznis sloj (sloj poslovne logike), sadrži komponente specifične za poslovanje koje se koriste u nekoliko aplikacija • Srednji sloj, Middleware sloj, sadrži komponente kao što su GUI bilderi, interfejsi sistema za upravljanje bazama podataka, servisi operativnih sistema nezavisnih od platformi i OLE komponente kao što su spreadsheets i dijagram editori • Donji sloj, sloj sistemskog softvera, sadrži komponente kao što su operativni sistemi, baze podataka, interfejse ka određenim hardverima itd.

31. Arhitektura zasnovana na komponentama (Component-based architecture) • Komponenta je nezavisan i zamenjivi softverski objekat koji enkapsulira implementaciju određene funkcionalnosti ili skupa funkcionalnosti iza jasno definisanog interfejsa i u interakciji je sa drugim komponentama sadržanih u jasno definisanoj arhitekturi • Većina komponenti je nezavisna od platforme • Tipovi komponenata: • Business component – softverska implementacija poslovnog koncepta ili procesa; sadrži određenu poslovnu funkcionalnost, npr. porudžbina, izračunavanje poreza, plaćanje itd. • Technical component – sadrži tehničku funkcionalnost koja se koristi za formiranje infrastrukture aplikacije; npr. komponente bezbednosti, sistemi menija, Java apleti, interakcija sa operativnim okruženjem itd. • Runtime software component – izvršna softverska komponenta koja se kreira tokom izvršavanja programa

32. Primer komponentne arhitekture u e-business aplikaciji • Business components: • Customer relationship – servisi za skladištenje, održavanje i korišćenje korisničkih profila • Product catalogue – servisi koji omogućavaju konzistentan pristup informacijama kataloga proizvoda kao što su cene, specijalne ponude, nivo zaliha i dr. • Shopping cart – servisi koji omogućavaju klijentu prikupljanje i pregledanje skupa izabranih kupovina kao jednu transakciju • Payment – servisi koji omogućavaju proveru kredita i administriranje transakcija plaćanja • Order – servisi koji omogućavaju kreiranje porudžbenice, • Directory - servisi koji omogućavaju otvorenu i digitalnu verziju internog direktorijuma telefona

33. Primer komponentne arhitekture u e-business aplikaciji (nastavak) • Komponentna arhitektura je troslojna gde je korisnički interfejs odvojen od poslovne logike i sloja podataka – omogućava se ponovna upotrebljivost određenih funkcionalnosti: • User interface layer – ovaj sloj podržava sve delove rešenja koji se odnose na korisničke interfejse • Business layer – uključuje: • Process components – obezbeđuje lokalnu poslovnu funkcionalnost • Business domain components – obezbeđuje funkcionalnost kroz različite poslovne procese • Business infrastructure components – kroz nekoliko poslovnih domena • Technical infrastructure layer – ove komponente obezbeđuju tehničke servise poslovnim komponentama

34. Paterni (patterns) • Dizajn paterni i ponovno upotrebljive komponente pomažu u prevazilaženju složenosti koje postoje kod velikih aplikacija • Dizajn paterni (design patterns) - obezbeđuju pristup dokazanim metodologijama za rešavanje opštih problema i sposobnost korišćenja kolektivnog znanja i iskustva IT zajednice radi poboljšanja kvaliteta aplikacije • Paterni pomažu u organizovanju koda na dokazani način u rešavanju dobro definisanih problema • Omogućavaju bolju modularnost; visoko jedinstvo i slabu spregnutost • Ponovo upotrebljive komponente (reusable components) – enkapsuliraju funkcionalnost koja je zajednička kroz mnoge aplikacije i povećava produktivnost

35. Faza konstrukcije – razviti proizvod • Kompletan model zahteva i dizajna • Projektovanje, implementiranje i testiranje svake komponente • Prototipovanje sistema i uključivanje korisnika • Inkrementalno uključivanje izvršne arhitekture radi završavanja sistema • Razvijati dnevno ili nedeljno sa automatizovanim procesom razvoja • Testirati svaki build • Automatsko regresivno testiranje (potvrđuje se da li su ostali delovi sistema ostali stabilni posle završetka iteracije) • Test punjenja i stresa kako bi se osigurao integritet arhitekture • Isporučiti funkcionalni softver (beta verzija) • Uključiti materijale za obuku, korisničku dokumentaciju i dokumentaciju uvođenja rešenja u sistem • Napraviti opis verzije

36. Ciljevi faze konstrukcije • Cilj 1: Minimizirati troškove razvoja i dostići neki stepen paralelnog rada razvojnog tima • Organizovati tim oko arhitekture softvera • Optimizovati resurse i izbeći nepotrebne ostatke • Osigurati kontinuirani progres • Postaviti jasne ciljeve • Organizovati brze svakodnevne sastanke ... • Cilj 2: Iterativno razviti kompletan proizvod koji je spreman za tranziciju u korisničko okruženje • Opisati ostale slučajeve korišćenja i druge zahteve • Projektovati bazu podataka • Integraciono i sistemsko testiranje • Razviti prvu operativnu verziju sistema (beta verzija) • Odrediti da li su softver, sajtovi, korisnici spremni za uvođenje aplikacije

37. Višestruke iteracije

38. Faza tranzicije – uvođenje ka krajnjim korisnicima • Potvrda da realizovani sistem zadovoljava tražene funkcionalnosti i performanse • Uvođenje inkrementalne “bug-fix” verzije • Ažuriranje korisničkih priručnika i dokumentacije uvođenja • Ažuriranje verzije • Vođenje analize projekta u toku perioda zatišja

39. Ciljevi faze tranzicije • Cilj 1: Beta test za vrednovanje očekivanja korisnika • Ispravljanje bagova • Cilj 2: Obučavanje korisnika i održavanje pouzdanosti korisnika u sistem • Cilj 3: Pripremiti uvođenje sistema • Nabavka novog hardvera, migriranje podataka ... • Cilj 4: Pripremiti sistem za puštanje u rad, verziju za distribuciju, obučavati osoblje • Cilj 5: Poboljšati buduće performanse projekta kroz naučene lekcije

40. Ključni principi i najbolje prakse • Razviti samo ono što je neophodno • Agilnost • Fokus na ključne zahteve (prikupiti, dokumentovati, organizovati, sortirati prema prioritetu) • Minimizirati papirne poslove • Biti fleksibilan • Zahtevi će se menjati – proceniti uticaj promena i odlučiti koje zahteve implementirati • Preneti promene svim članovima tima • Plan, ljudi itd. • Učiti iz prethodnih grešaka • Petlje povratne sprege • Poboljšanje procesa • Revizija redovnih rizika • Uspostaviti ciljeve, merljive kriterijume za napredovanje • Automatizovati • Podržati proces sa alatima za razvoj softvera

41. Razvoj vođen slučajevima korišćenja • Slučajevi korišćenja (use-case) opisuju servise koje sistem nudi korisnicima i drugim sistemima • Slučajevi korišćenja vode posao kroz svaku iteraciju: • Planiranje iteracija • Kreiranje i validacija arhitekture • Definisanje slučajeva i procedura testiranja • Dizajniranje korisničkih interfejsa i kreiranje korisničke dokumentacije

42. Uspostaviti izvršnu arhitekturu u ranim fazama • Arhitektura obezbeđuje kostur strukture sistema • Podsistemi, ključne komponente, interfejsi, arhitekturalni mehanizmi (rešenja za opšte probleme, kao što su doslednost, interno-procesna komunikacija ...) • Implementiranje i testiranje arhitekture umanjuje veće tehničke rizike

43. Tradicionalna funkcionalna dekompozicija • Vođena zahtevima • Mnoge zavisnosti kreiraju nefleksibilni sistem

44. Izgraditi sistem sa komponentama • Komponentna arhitektura obezbeđuje fleksibilnost • Komponente omogućavaju: • Jasnu podelu posla između timova developera • Poboljšano održavanje i proširljivost • Ekonomička ponovna upotreba ili kastimizacija postojećih komponenti • Izbor između hiljada raspoloživih ActiveX i Java komponenata • Inkrementalnu evoluciju postojećeg softvera

45. Testiranje svake iteracije • Veoma je važno započeti testiranje u ranim iteracijama • Kako se dodaju novi zahtevi u svakoj iteraciji, generišu se i novi testovi

46. Poređenje metodologija • Agilni procesi

47. DOD standardi (Department of Defense standards)

48. SEI CMM i SEI CMMI

49. Rational Unified Process Framework

50. RUP: integrisan sa alatima • Tool mentors: Web-based assistance for tool use • Extended Help: Process guidance from within any tool