Baze podataka Visoka poslovna kola strukovnih studija VIPOS

Baze podataka Visoka poslovna škola strukovnih studija VIPOS, Valjevo METODE PROJEKTOVANJA INFORMACIONIH SISTEMA dr Stanišević Ilja, dipl. ing.

Metode projektovanja IS klasične agilne • code-fix • kaskadni model • spiralni model • • extremno programiranje scrum razvoj na bazi osobina FDD. . .

Kodiraj pa ispravljaj (Code-Fix) Specifikacija sistema kodiranje Äneefikasno Äteška modifikacija Änepouzdano ispravljanje grešaka Konačna verzija

Kaskadni model Waterfall model - 1970 Royce analiza zahteva projektovanje sistema Änefleksibilan Änepostojanje povratne sprege Äkorisnik isključen iz procesa Äobimna dokumentacija projektovanje programa kodiranje testiranje delova testiranje sistema završno testiranje operativni rad i održavanje

Brzi razvoj aplikacija -RAD (Rapid Application Development) inicijalni koncept dizajn i implementacija prototipa Äzasnovana na prototipu Äkomunikacija sa korisnikom Äteško se identifikuju entiteti i zavisnosti Älako "sklizne" u Code-Fix podešavanje prototipa do prihvatanja kompletiranje i isporuka prototipa

RAD metode prednosti i nedostaci Fleksibilnost Brzina realizacije PrednostiČeste iteracije olakšavaju komunikaciju Dobra prilagođenost korisnikovim potrebama Problemi integrisanja prototipova u jedinstven sistem Loša kontrola celog procesa Visoki tehnološki i kadrovski zahtevi Rizik kod korišćenja novih tehnologija Nedostaci Pogodna za manje projekte kraćeg trajanja, i za manje timove. Neprikladna za velike projekte široke primene i velike razvojne timove.

Bemov spiralni model m o ik z i r n a t) j l av pmen r p elo u j dev o zv iven a R k dr (ris Radijalna dimenzija kumulativni troškovi Angularna dimenzija napredak razvoja projekta Prototipski razvoj

Bemov spiralni model Ä Evaluacija alternativa i određivanje rizika: identifikacija ciljeva, identifikacija alternativnih sredstava implementacije, identifikacija ograničenja nametnutih alternativama Ä Razvoj i verifikacija proizvoda naredne iteracije: evaluacija alternativa, definicija izvora rizika za ceo projekat; definicija ciljeva narednog prototipa; Ä Plan sledeće iteracije: planiranje i dizajn narednog prototipa, definisanje strategija za eliminisanje izvora rizika Ä Konstrukcija i testiranje novog prototipa: završni korak iteracije, procenjuje se preostali rizik za odvijanje projekta, definišu se ciljevi naredne iteracije ative !!! na r e t l a a r i ab d o m u j i r rite k – A K I RIZ A J I C A Z MINIMI Ne postoje markeri odvijanja projekta !?

Bemov spiralni model Najopštiji slučaj, konceptualno obuhvata sve ostale. Svaki projekat je specifičan, i m u j ri e t i teško je generalizovati. r k i n s ja. u j a t k s e j Nedo etka pro š Dobra kontrola procesa, ali zavr iterativnost obezbeđuje fleksibilnost. Pogodan za projekte visokog rizika, gde se zahteva tačnost i gde implementacija ima prioritet nad funkcionalnošću.

Rational ujedinjeni proces (Rational Unified Process - RUP) zahtevi analiza i dizajn poslovno modeliranje implementacija planiranje iteracija N test ugradnja inicijalno planiranje revizija procene rizika Äniz iteracija Ägrafički modeli kao dokumentacija Ävezanost za IBM i njegove CASE alate

Microsoft okvir za rešenja (Microsoft Solution Framework - MSF) faza uvođenja Uvođenje završeno faza planiranja faza stabilizacije marker faza predviđanja Odobrena vizija /oblast djelovanja Odobrena spremnost za izdavanje Oblast delovanja završena faza razvojna faza Odobreni projektni planovi Uvode se markeri koji označavaju izvršenje jedne i početak naredne faze.

Uloge u MSF-u upravljanje proizvodom –odgovorni za komunikaciju sa upravljanje programom – odgovorni za razvojni proces i Dodatni članovi tima isporuku rešenja unutar ograničenja projekta; razvoj – odgovorni za razvoj tehnologije; testiranje – odgovorni za kvalitet proizvoda i odobravanje izdavanja rješenja; upravljanje izdavanjem – odgovorni za uvođenje rešenja; utisak korisnika – odgovorni za analizu performansi i korisničku podršku. Obavezne uloge kupcima; sponzor projekta kupac (sponzor posla) krajnji korisnik operativa

Faza predviđanja Ä Kupac i tim definišu zahteve i ciljeve projekta na najvišem nivou; Ä Usvaja se zajednička vizija projekta; Ä Definiše se poslovni problem i cilj projekta.

Faza predviđanja Generišu se dokumenta: • dokument vizije/oblasti djelovanja • dokument stukture projekta • dokument procene rizika Opciona dokumenta: • lista karakteristika koje se mogu testirati, • inicijalni slučajevi korišćenja, • uvodna arhitektura, • nacrt korisničkog interfejsa. • katalog učesnika, • katalog poslovnih pravila • rečnik termina Izlaz je marker „vizija/oblast delovanja odobreni“

Faza planiranja U pl ku a n pn ov o a 20 !! ! plan izvodljivosti (eng. Availability Plan); plan arhiviranja i oporavka od grešaka (eng. Backup and Recovery Plan); plan finansiranja (eng. Budget Plan); plan kapaciteta (eng. Capacity. Plan); plan komunikacije (eng. Communications Plan); plan puštanja u rad (eng. Deployment Plan); plan razvoja (eng. Development Plan); plan podrške krajnjem korisniku (eng. End-User Support Plan); plan glavnog projekta (eng. Master Project Plan 0. 2); plan podrške Microsofta (eng. Microsoft Support Plan); plan migracije (eng. Migration Plan); plan nadgledanja (eng. Monitoring. Plan); operativni plan (eng. Operations Plan); plan performansi (eng. Performance. Plan); plan prototipa (eng. Pilot Plan); plan nabavki i opreme (eng. Purchasing and Facilities Plan); bezbednosni plan (eng. Security. Plan); plan podrške (eng. Support Plan); plan testiranja (eng. Test Plan); plan treninga (eng. Training Plan); Planovi

Ukupno 9 specifikacija !!! Faza planiranja Ä poslovni zahtevi (eng. Business Requirements); Ä konceptualni dizajn (eng. Conceptual Design); Ä funkcionalna specifikacija (eng. Functional Specification); Ä logički dizajn (eng. Logical Design); Ä operativni zahtevi (eng. Operations Requirements); Ä fizički dizajn (eng. Physical Design); Ä zahtevi sistema (eng. System Requirements); Ä scenarija korišćenja (eng. Usage Scenarios); Ä korisnički zahtevi (eng. User Requirements). Specifikacije

Razvojna faza Generišu se dokumenta: • izveštaji o testiranju i greškama (eng. Testing and Bug Reporting) • inspekcija praćenja (eng. Traceability Audit) Razvoj i proces generisanja koda se tretira kao automatizam prevođenja planova u izvršnu verziju, bez udubljivanja u specifičnosti ove faze razvoja !!! Izlaz je marker „oblast delovanja završena“

Faza stabilizacije Generišu se dokumenta: • • • specifikacija testova (eng. Test Specification) pregled verzije (eng. Pilot Review) obrazac izdavanja verzije (eng. Release Signoff Form) Obrazac izdavanja verzije - skup potpisa svih odgovornih uloga u razvoju projekta kojim oni garantuju korektno izvršenje aktivnosti (menadžer proizvoda, menadžer programa, menadžer verzije, menadžer razvoja, menadžer testiranja, pravno lice i lice zaduženo za kontakte sa korisnikom). Izlaz je marker „odobrena spremnost za izdavanje“

Faza uvođenja Generišu se dokumenta: • post-projektna analiza (eng. Post Project Analysis) • izvještaj o okončanju projekta (eng. Project Close-out Report) Osnovna zamerka metodi je da softverski sistem tretira kao industrijski proizvod, a ne kao kreativan inženjerski čin. Puno prostora je poklonjeno planovima i specifikacijama, dok se njihova realizacija implicitno podrazumeva i nigde preciznije ne tretira.

MSF prednosti i nedostaci faze i markeri; dobra kontrola odvijanja projekta; definisana odgovornost; visok kvalitet sistema. puno uloga; za velike timove; obimna dokumentacija; visoki troškovi; nedovoljna fleksibilnost. Metoda je pogodna za velike projekte koje realizuju veliki timovi i gde je zahtevan visok kvalitet i striktna kontrola procesa.

The Standish Group International, Inc. * * Boston, MA, USA Prikuplja podatke o IT projektima širom sveta Da li je sve baš kao u teoriji? Koliko smo uspešni u pravljenju informacionih sistema?

Standish Group report Projekti su podeljeni u 3 tipa: Tip I - uspeli projekti, završeni na vreme, u okviru budžeta i sa svim predviđenim funkcionalnostima; Tip II - projekat završen ali je prekoračio budžet, ili je završen kasnije, ili ima manje funkcionalnosti od planiranog; Tip III - od projekta se odustalo, nije nikad završen.

Rezultati Samo 16, 2% projekata uspešno ! 16. 2 31. 1 tip III 52. 7 CHAOS REPORT !!!

AGILNI MANIFEST (Agile Manifesto) Äpojedinci i interakcije su važniji od procesa i alata; Äsoftver koji radi je važniji od sveobuhvatne dokumentacije; Äsaradnja sa korisnikom je važnija od pregovaranja i ugovaranja; Äodgovor na promene je važniji od praćenja plana Kent Beck, Alistair Cockburn, Ken Schwaber, Martin Fowler. . . 2001 godina

Ekstremno programiranje (Extreme Programming - XP) k c e istraživanje višestruke iteracije B t n e K planiranje iteracije uvođenje fino podešavanje plana istraživanje zahtevi korisnika na najvišem nivou, tehnički prototip planiranje definisanje prioriteta, podela na isporuke iteracije testiranje i razvoj, korisnici uključeni, detaljan plan iteracije, dnevne isporuke uvođenje ugradnja sistema u radno okruženje kupca održavanje stalno “krpljenje” i proširivanje sistema održavanje

12 faktora XPa Igra planiranja: naručioci opisuju scenarije; Male verzije: česte isporuke, inkrementalni pristup; Metafora: zajednička vizija dizajna sistema; Jednostavnost dizajna: (YAGNI = You ain’t gonna need it – To Vam neće trebati) Testovi pre kodiranja: scenariji testova; Prerađivanje koda (refraktorisanje): promene nisu neželjena anomalija, već sastavni deo same metode; Programiranje u paru;

12 faktora XPa Kolektivna svojina: svaki član tima može promeniti bilo koji deo sistema dok je on u fazi razvoja; Neprekidna integracija: Isporuka brza, naglasak na sitnim poboljšanjima; Održiv korak: 40 -časovna radna nedjelja; Raspoloživost naručioca; Standardi kodiranja: Kod treba da izgleda kao da ga je pisala jedna osoba.

Uloge u XPu Trener (Coach): nadzire, usmerava, osigurava da projekat ostane na ispravnom kursu, pruža pomoć svim ostalim članovima tima; Kupac (Customer): piše korisničke priče, daje specifikaciju funkcionalnih testova, objašnjava priče, postavlja prioritete, donosi odluke po pitanju korisničkih priča; Programer (Programmer): procenjuje priče, definiše zadatke, implementira priče i definiše jedinične testove; Tragač (Tracker): prati progres programera, pomaže kod zastoja i problema, zakazuje sastanke sa kupcem, obezbeđuje pomoć trenera ili drugog programera; Tester (Tester): implementira i izvršava funkcionalne testove, evidentira rezultate, obaveštava druge kada rezultati testova pokazuju tendenciju opadanja. „leadership“, a ne „management“ !

SKRAM (SCRUM) r e b a hw en Sc K ü naglasak na organizaciji razvojnog tima i upravljanje procesom ü kratke, intenzivne iteracije ü komunikacija se odvija na kratkim sastancima ü timski napor da se stigne do željenog cilja, gola ü unapred su poznati samo zahtevi najvišeg nivoa, dok se detalji kristališu tokom razvoja sistema

SKRAM (SCRUM) r e b a hw en Sc K Osnovni pojmovi metode su: § § § zalihe proizvoda; zalihe za sprint; dnevni sastanci – skramovi; demo.

Zalihe proizvoda Zaliha proizvoda - dokument najvišeg nivoa za projekat. Lista zahteva kupca- naručioca IS koja definiše proizvod na najopštijem nivou i izvodi se iz specifikacije proizvoda. Sadrži spisak traženih funkcionalnosti, spisak poželjnih ali neophodnih osobina, poslovne vrednosti i njihove prioritete. Promenljiva je tokom rada na projektu. Data je i procena napora za implementaciju osobina. Prvo se realizuju osobine (tj. funkcionalnosti) koje imaju najviši prioritet od strane korisnika i zahtevaju najmanju napor za realizaciju po oceni razvojnog tima.

Zalihe za sprint Zaliha za sprint - lista zahteva za realizaciju u toku sprinta. Prioriteti i sadržaj liste se dinamički menjaju pre početka svakog sprinta, ali su fiksirani za tekući sprint u toku njegovog odvijanja. Funkcionalnosti za realizaciju se dekomponuju u radne zadatke koji se po preporuci mogu realizovati za 4 -6 sati rada. Zadaci su precizno i jasno definisani tako da svaki član tima razume i može realizovati svaki zadatak. Članovi tima se samostalno prijavljuju za zadatatke u skladu sa uspostavljenim prioritetima i tehničkom osposobljenošću članova tima.

SPRINT Sprint - vremenski period (do 30 dana) kad se kreiraju demo verzije sistema koje realizuju zahteve definisane u zalihama za sprint. Broj sprintova u toku projekta nije limitiran, ali on određuje trajanje projekta. Broj sprintova se može na početku projekta samo grubo proceniti. Sprint se može otkazati u toku izvršavanja. Razmatraju se razlozi za otkazivanje i nakon toga se definiše novi sprint.

Skramovi (dnevni sastanci) na početku sprinta - sastanak planiranja sprinta (eng. Sprint Planning Meeting): Älimitirani na 8 sati Ädefinišu se zahtevi za sledeći sprint Ävrši se procena potrebnog vremena Äprocenjuje se potrebno opterećenje Sa (p sta na rolo nci ist ng se om ira od m nja ržav es n a tu isu ju. do u t zv ačn ol o je v na re ), me uv ek Ä15 -minutni dnevni sastanci - scrumovi: urađeno od poslednjeg scruma koji su problemi u radu šta će se uraditi do sledećeg na kraju sprinta - pregled sprinta (eng. Sprint Review Meeting) Älimitiran na 4 sata; Äpregled ostvarenog u sprintu; ÄPrezentira su urađeno deoničarima.

DEMO Äde mo = ra dna (a n e pr verz ezen ija p taci ja il rogr i do ama kum enta cija ) Demo - radna i potpuno funkcionalna verzija softvera koja se demonstrira kupcu na kraju svakog skrama. Kada su realizovani i prihvaćeni svi zahtevi iz liste zaliha proizvoda, skup svih od korisnika prihvaćenih demo programa daje nam završeni i kompletni softverski sistem.

SKRAM – životni ciklus zalihe za proizvod zahtevi kupca Äsprint - iteracije od 30 dana Ä15 -minutni dnevni scrumovi: urađeno od poslednjeg scruma koji su problemi u radu šta će se uraditi do sledećeg Ädemo = radna verzija programa zalihe za sprint (a ne prezentacija ili dokumentacija) korekcija i dodatni zahtevi zadaci sprint demo softver dnevni sastanci isporuka završni proizvod

Uloge u skramu Ä vlasnik projekta (eng. Project Owner): - predstavnik deoničara, korisničke strane unutar razvojnog tima. Vodi računa o opisu korisničkih zahteva, određuje prioritete i definiše zalihu proizvoda; Ä skram master (eng. Scrum Master): prati i kontroliše odvijanje procesa. Odgovara ulozi projekt menadžera kod klasičnih projekata. On preuzima na sebe komunikaciju tima sa eksternim svetom, osigurava da se projekat odvija po prihvaćenim pravilima, te olakšava timu da ostane skoncentrisan isključivo na zadatke koji su u toku ispunjavanja; Ä član tima (eng. Team): grupa od maksimalno 7 -8 članova. Osposobljeni su za različite zadatke i obavljaju konkretne poslove analize, dizajna, projektovanja, programiranja, testiranja. . . Ä deoničari (eng. Stakeholders): osobe za koje se sistem realizuje (korisnici, naručioci. . . ) i za koje sistem treba da ostvari novu vrednost; Ä uprava (eng. Management): osobe koje uspostavljaju okruženje za realizaciju projekta.

Uloge u skramu SVINJE PILIĆI (Pig Roles) (Chicken Roles) Vlasnik proizvoda (Product Owner) Vođa skrama (Scrum Master) Članovi tima Krajnji korisnici operateri deoničari, dobavljači, distributeri Menadžeri

Evaluacija skrama Raširenost Organizaciona prednosti fleksibilnost Dinamički odgovor na promene Neorganizacioni aspekti su zanemareni Načini realizacije nisu ni spomenuti, prepušteni su timu Scrum se pokazao pogodnim za širok spektar različitih tipova projekata, gde god se traži fleksibilnost u vođenju projekta. nedostaci

Razvoj na bazi karakteristika - FDD (Feature Driven Development) Kreiranje liste karakteristika Kreiranje plana na bazi liste karakteristika Dizajn na bazi karakteristika Rad na bazi karakteristika

Poređenje klasičnih i agilnih metoda visoka XP code-fix fleksiblnost iterativni RAD RUP i MSF kaskadni mala nizak kvalitet visok

Poređenje klasičnih i agilnih metoda Klasične metode • Pogodne za velike timove, struktuirane problema, striktno kontrolisane procese, gde je potrebno utvrditi odgovornost i gde se zahteva pouzdanost Agilne metode • Pogodne za nestandardne i teško predvidive projekte, manje timove, gde je potrebna kreativnost i fleksibilnost, gde je u fokusu proizvod, a ne proces realizacije projekta

Koliko smo napredovali ? ? ?