Izrada sustava Izrada sustava Kodiranje, programiranje Ugovor ...

Refaktoriranje (refactoring)Osnovni pojmovi• promjena interne strukture programske podrške da bi ju se bolje razumjelo ilakše održavalo, uz očuvanje vanjskog ponašanja (Fowler 1999)• jedna od osnovnih praksa agilnog programiranja• karakteristika ekstremnog programiranja je agresivno refaktoriranje• proces programiranja sastoji se od niza koraka kodiraj+refaktoriraj Primjena - na sve aspekte programske podrške (dokumentacija,programski kod, modeli, testovi, …)• Teže je refaktorirati programe koji nisu pisani objektno orijentiranim jezikomjer su tokovi podataka i kontrolni tokovi čvrsto povezani• Uzimajući u obzir koncepte objektno orijentiranih jezika kao što sunasljeđivanje i polimorfizam, refaktoriranje programa pisanih objektnoorijentiranim jezikom je također teško• Ukoliko se radi o refaktoriranju UML modela, treba paziti na konzistentnostizmeđu različitih modela, kao i modela i programskog koda, ili dokumentacijeKarakteristike refaktoriranja• Prema Lehman-ovim zakonima evolucije programske podrške• povećanje funkcionalnosti sustava razmjerno je smanjenju kvalitete i povećanjuunutarnje složenosti Prednosti refaktoriranja• sprječava narušavanje strukture programskog koda• ako se nakon svake promjene koda izazvane promjenom zahtjeva obavirefaktoriranje, tada struktura ostaje očuvana, što olakšava buduće promjene• Povećanje razumljivosti i čitljivosti programskog koda• Olakšava otkrivanje bugova• Povećanje produktivnosti• promjene koda brže obaviti ako je kod dobro dizajniran, lak za razumijevanje i bezbugova – ušteda vremena je znatno veća od vremena utrošenog na refaktoriranje• Uslijed jednostavnijeg dizajna smanjuju se troškovi održavanja Nedostaci refaktoriranja• Pretjerana primjena smanjuje produktivnost i svodi se na puko refaktoriranje• Ukoliko nije automatizirano, refaktoriranje može biti dugotrajno i mukotrpno• Postojeći alati nisu dovoljno zreli i pouzdani – nepovjerenje programeraFER \ Fertalj: Razvoj informacijskih sustava13FER \ Fertalj: Razvoj informacijskih sustava14Tehnike refaktoriranjaReprezentativni predlošci refaktoriranja Predlošci (patterns) refaktoriranja – tzv. refactorings Composing methods• Extract method, inline method, inline temp, replace temp with query, introduceexplaining variable, split temporary variable, remove assignments to parameters, ... Moving features between objects• Move method, move field, extract class, inline class, hide delegate, remove middleman, introduce foreign method, introduce local extension Organizing data• Self encapsulate field, replace data value with object, change value to reference,replace array with object, encapsulate field, replace subclass with fields, ... Simplifying conditional expression• Decompose conditional, remove control flag, replace conditional with polymorphism,replace nested conditional with guard, ... Making method calls simpler• Rename method, parameterize method, remove parameter Dealing with generalization• Pull up field, pull up method, push down method, extract subclass, extract interface, ... Rename method• Davanje novog, razumljivijeg imena metodi Extract method• Dio koda se izdvaja u posebnu metodu Replace temp with query• Zamjena varijable koja poprima vrijednost nekog izraza s pozivom metode Move method/field• Metoda/članska varijabla se iz jednog razreda prebacuje u drugi razred Extract class – inline class• Razred koji “radi puno toga” dijeli su više razreda - extract, obrnuto – inlineclass Replace conditional with polymorphism• Zamjena uvjeta (switch) koji ispituje tip objekta s polimorfizmom, tako što seoriginalna metoda učini apstraktnom i u podrazredima se primijeni overriding Replacetypecodewithstate/strategy• Postoji kod koji utječe na ponašanje a ne može se primijeniti subclassingFER \ Fertalj: Razvoj informacijskih sustava15FER \ Fertalj: Razvoj informacijskih sustava16

Prije kraja ... Primjer: Izrada \ Refaktoriranje – R7• slično IzracunajIznosPosudbe, preseljena je i IzracunajFrekvencijuPosudbeReplace Conditional with Polymorphism Preostaje riješiti switch dio• Postoji nekoliko tipova filmova koji na isti upit (izračunaj iznos posudbe,izračunaj frekvenciju posuđivanja i kod cijene) "odgovaraju" na različiti način• Računica se obavlja temeljem atributa cijenaKodFilmClassFieldscijenaKodDJECAnaslovNOVIOBICNIPropertiesCijenaKodNaslovMethodsFilmIzracunajFrekvencijuP…IzracunajIznosPosudbefilmPosudbaClassFieldstrajanjeDanaPropertiesFilmTrajanjeDanaMethodsIzracunajFrekvencijuPosudbeIzracunajIznosPosudbePosudbaposudbeClanClassFieldspunoimePropertiesMethodsPunoImeClanDodajPosudbuIspisiInfoOPosudbamaIspisiInfoOPosudbamaHTMLIzracunajUkupniIznosPosu…Iz ra cunajUkupnuFrekvencij… Problem: što ako se pojavi novi tip filma• Tada bi na svim mjestima gdje se obavlja provjera tipa cijene (u ovomkratkom primjeru to se radi samo na jednom mjestu) trebalo dodati novi caseuvjet. Rješenje: nasljeđivanje i polimorfizam• za vrijeme izvođenja će se odrediti o kojem se tipu filma radi, te pozivatiodgovarajuća metoda specijalizacije• korištenjem postupka Replace Conditional with PolymorphismFER \ Fertalj: Razvoj informacijskih sustava41FER \ Fertalj: Razvoj informacijskih sustava42Model s ugrađenim polimorfizmomSučelje i izvedeni razred Primjer: Izrada \ Refaktoriranje – R7 Primjer: Izrada \ Refaktoriranje – R8, sučelje IFilmObicniFilmClassFieldsnaslovPropertiesNaslovMethodsIzracunajFrekvencijuP…IzracunajIznosPosudbeObicniFilmIFilmInterfacePropertiesNoviFilmClassFieldsNaslovMethodsnaslovPropertiesNaslovMethodsFER \ Fertalj: Razvoj informacijskih sustavaIzracunajFrekvencijuPosudbiIzracunajIznosPosudbeIFilm IFilm IFilmIzracunajFrekvencijuP…IzracunajIznosPosudbeNoviFilmDjecjiFilmClassFieldsnaslovPropertiesNaslovMethodsfilmDjecjiFilmIzracunajFrekven…IzracunajIznosPo…PosudbaClassFieldstrajanjeDanaPropertiesFilmTrajanjeDanaMethodsIzracunajFrekvencijuPosudbeIzracunajIznosPosudbePosudbaposudbeClanClassFieldspunoimePropertiesMethodsPunoIme43interface IFilm{string Naslov {get;}double IzracunajIznosPosudbe(int trajanjeDana);int IzracunajFrekvencijuPosudbi(int trajanjeDana); Primjer: Izrada \ Refaktoriranje – R8, realizacijaclass ObicniFilm : IFilm {...public double IzracunajIznosPosudbe(int trajanjeDana) {double rezultat = 2;if (trajanjeDana > 2)rezultat += (trajanjeDana - 2) * 1.5;...public int IzracunajFrekvencijuPosudbi(int trajanjeDana){return 1;}FER \ Fertalj: Razvoj informacijskih sustava44

Kada primijeniti refaktoriranjeRefaktoriranje – bad code smells• “uvijek” – kad god se naprave neke promjene na programskom kodu koje“kvare” strukturu koda ili kada se promjene očekuju, pa se želimo pripremitikako bi promjene čim lakše proveli• “the rule of three” - kada prvi put nešto radimo, onda to samo napravimo.Kada neki drugi put radimo nešto slično, bojimo se dupliciranja, ali svejednoto napravimo ponovo. U trećoj sličnoj situaciji primijenimo refaktoriranje.• kada se dodaje nova funkcionalnost – prije nego se nova funkcija doda,potrebno je razumjeti dio koda na koji utječe. Ako je kod teško za razumjetitada treba primijeniti refaktoriranje. Ako dodavanje nove funkcije narušavastrukturu koda tada također treba primijeniti refaktoriranje.• kada treba ispraviti neki bug – sama činjenica da bug treba otkriti znači daje kod nerazumljiv i da je potrebno refaktoriranje• kada se obavlja pregled koda – za vrijeme pregleda koda obično se pojavenove, bolje ideje, koje se primjenjuju tako da se obavi refaktoriranje• “bad code smells” –duplicirani kod, duge metode, veliki razredi, metode smnogo parametara, divergent change, shotgun surgery, feature envy,primitive obsession, switch statements, parallel inheritance hierarchies, lazyclass, temporary field, message chains, middle man, ...duplicirani kod• ako se neki kod pojavljuje na više od jednog mjesta tada ga treba izdvojiti i smjestitina jedno mjesto• ako se isti kod pojavljuje na više mjesta u istom razredu tada treba primijeniti extractmethod• ako se isti kod pojavljuje u razredima koji imaju isti nadrazred tada se najprije upodrazredima primijeni extract method, a onda se metode prebaci u nadrazredpomoću pull up method• ako se isti kod pojavljuje u više razreda koji nisu povezani tada se primijeni extractclass ili jedan razred koristi drugi razredduge metode• metode koje su duge teže je razumjeti nego više manjih metoda• dijelove je moguće izdvojiti pomoću extract method ili replace temp with query, a akoovo dvoje ne pomaže tada treba primijeniti replace method with method objectveliki razredi• ako razred obavlja previše posla tada treba primijeniti extract class ili ako ima smislatada treba primijeniti extract subclassFER \ Fertalj: Razvoj informacijskih sustava45FER \ Fertalj: Razvoj informacijskih sustava46Refaktoriranje – bad code smellsRefaktoriranje – bad code smells metode s mnogo paramatara• metode s mnogo parametara je teže razumjeti nego one s malo parametara• moguće rješenje je replace parameter with method pri čemu se izbacuju nekiparametri metode, koje metoda može sama saznati postavljajući upitobjektu koji joj je dostupan• ako postoji više parametara koji nisu logički povezani s nekim objektomkojem bi metoda mogla postaviti upit kako bi saznala vrijednost parametara,tada se (ako ima smisla) primjenjuje introduce parameter object pri čemu separametri grupiraju u objekt i objekt se prosljeđuje kao parametar metode divergent change• pojavljuje se kada različite promjene zahtijevaju različite promjene u istomrazredu, npr. uslijed dodavanja nove BP treba promijeniti 3, a uslijeddodavanja novog tipa poreze druge 2 metode• rješenje je stvaranje više razreda, tako da se razred mijenja samo kaoposljedica točno određenog tipa zahtjeva• kako bi se to postiglo koristi se uzorak extract class shotgun surgery• suprotno od divergent change• pojavljuje se kada neki tip promjene povlači za sobom puno malih promjena urazličitim razredima – kada je promjene potrebno obaviti na puno mjesta povećava semogućnost pogreške• ako postoji razred u koji se mogu prebaciti dijelovi drugih razreda koji zahtijevajupromjene tada se koristi move method i move field ili inline class feature envy• pojavljuje se kada se neka metoda nalazi u nekom razredu, a više bi odgovaralanekom drugom razredu, jer dosta koristi podatke tog drugog razreda• ako samo jedan dio metode puno koristi podatke drugog razreda tada treba primijenitiextract method, a inače treba primijeniti move method data clumps• pojavljuje se kada se iste članske varijable pojavljuju u više razreda ili se isti parametripojavljuju u više metoda• rješenje je korištenje extract class (kako se iste varijable ne bi pojavljivale u višerazreda) ili introduce parameter object (kako metode ne bi imale više istih parametara)FER \ Fertalj: Razvoj informacijskih sustava47FER \ Fertalj: Razvoj informacijskih sustava48

primitive obsessionRefaktoriranje – bad code smells• pojavljuje se kad se neke relativno jednostavne podatke poput telefonskog broja ilipoštanskog broja ne koristi kao objekte• najčešće se u početnoj fazi razvoja programa takvi podaci koriste kao vrijednosni tippodatka, a kako razvoj programa napreduje tako se ti podaci sve više koriste kaoobjekti (pr. za telefonski broj se dodaje posebna metoda za formatirani ispis, metodaza ekstrakciju pozivnog broja) – rješenje problema je replace data value with object switch statements• switch naredba (isto vrijedi i za if-else) postaje problem ako se koristi na više mjesta,jer ako se pojavi potreba za uvođenjem novog uvjeta tada treba naći sve switchnaredbe i promijeniti ih• problem se riješava korištenjem replace type code with State/Strategy ili replaceconditional with polymorphism lazy class• pojavljuje se kada neki razred radi “malo posla” – može biti posljedica refactoringa• ako je neki razred podrazred koji ne zaslužuje da bude posebni razred tada se koristicollapse hierarchy pri čemu se ono malo funkcionalnosti podrazreda dodajenadrazredu, a ako taj razred nije ničiji podrazred tada se koristi inline class tj. razredse dodaje nekom logički bliskom razredu (pr. razred TelBroj se dodaje razreduZaposlenik – primitive obsession?)Refaktoriranje – bad code smells temporary field• pojavljuje se kada razred sadrži neku člansku varijablu koja se koristi samo uodređenim uvjetima, problem je u tome što se očekuje da su razredu potrebne svenjegove varijable• problem se može riješiti korištenjem extract class, pri čemu se sav kod koji se tičetakve varijable odvaja u posebni razred message chains• pojavljuje se kada klijent želi saznati nešto o nekom objektu, ali najprije mora zatražitineki drugi objekt pa onda od njega željeni objekt (pr. ako se želi saznati tko je šefnekoj osobi tada treba najprije za tu osobu saznati odjel, a onda na temelju odjelasaznati tko je šef u odjelu – klijent previše toga vidi, jer ne postoji enkapsulacija)• problem se rješava korištenjem hide delegate (pr. klijent za neku osobu samo zatražinjegovog šefa, a osoba sama na temelju svog odjela zatraži tko je šef odjela) middle man• pojavljuje se kada se previše koristi delegacija – kada većina metoda nekog razredana svaki upit odgovara tako što upit prosljeđuje nekom drugom razredu tada je tajrazred middle man• rješenje je remove middle man kojim nestaje posrednik i komunicira se direktno srazredom koji daje odgovore ili inline method kojim se metode iz posrednika prebacujuu pozivateljaFER \ Fertalj: Razvoj informacijskih sustava49FER \ Fertalj: Razvoj informacijskih sustava50Provjera ispravnostiProvjera ispravnostiTestiranje Testiranje programa, provjeravanje programa, ispitivanje programa• provjera programa izvođenjem, uz uporabu ispitnih podataka te analizomrezultata obrade• cilj testiranja je otkrivanje pogrešaka odnosno nedostataka unutar programa• uspješnost testa razmjerna je broju pronađenih pogrešaka Stupnjevi, stadiji, faze• testiranje jedinica, integracijsko testiranje, test sustava i test prihvatljivosti Verifikacija - ovjera ispravnosti• dokazivanje da je faza dobro provedena ili da je proizvod dobro napravljen,tj. da odgovara specifikaciji zahtjeva (slučajevima korištenja) Validacija - potvrda valjanosti• kojom se utvrđuje da je napravljen pravi proizvod, koji odgovara namjeni teje prihvatljiv korisnikuFER \ Fertalj: Razvoj informacijskih sustava52

Ključni pojmovi Test – provjerava da li je neki aspekt softvera ispravan• pr. test da li radi login, test da utrošak memorije ne premašuje 500Mb Pogreška (error) – propust programera, npr. radi nerazumijevanja• dovodi do jednog ili više kvarova• razlika u odnosu na "pogrešku" koja znači neželjeno stanje Kvar (fault), defekt (defect), neformalno bug - neispravan dio koda• slično kao kad kvar lambda sonde na automobilu ometa normalan rad• npr. pretpostavka da se polje indeksira od 1 umjesto 0 izaziva kvar pristupanepostojećem elementu polja Zastoj u radu (Failure) – stanje izazvano jednim ili više kvarova• npr. prestanak rada sustava zbog "buffer overrun" kvara Ispravak (Fix) – stanje popravkaProblem testiranja objektno orijentiranih sustava Problem: kako provjeriti da sustav zadovoljava potrebe korisnika• rješenje: testiranjem poslovnih procesa• poslovni proces je raspodijeljen u skupu međudjelujućih razreda isadržan u postupcima tih razreda• jedini način da se sazna učinak poslovnog procesa na sustav jezagledavanje u promjene stanja u sustavu• učahurivanje međutim sakriva podatke i obradu iza izloženih sučelja ! Drugi problem: što je osnovna "jedinica" za testiranje• paket, razred ili metoda ?• u tradicionalnim pristupima proces je sadržan u funkciji• u OO sustavima zasebno testiranje pojedinačnih metoda nema puno smisla• uslijed nasljeđivanja i višeobličja postoje različita ponašanja, a bugovinadređenog razreda propagiraju u neposredno i posredno izvedene• pri dinamičkom povezivanju ne zna se unaprijed koja će implementacijarazreda biti izvršenaFER \ Fertalj: Razvoj informacijskih sustava53FER \ Fertalj: Razvoj informacijskih sustava54Plan testiranja Provjera počinje planom testiranja - plan definira niz testova• plan treba napraviti na početku razvoja i stalno ažurirati Primjer: plan jedinične provjere razredaClass Test Plan Page ___ of ___Class Name: ________________ Version Number: _____ CRC Card ID: __________Tester: _________________ Date Designed : ________ Date Conducted : ________Class Objective:Associated Contract IDs:Associated Use Case IDs:Associated Superclass(es):Testing Objectives:Walkthrough Test Requirements:Invariant-Based Test Requirements:State-Based Test Requirements:Contract-Based Test Requirements:Plan testiranja (2) Primjer: plan provjere invarijanti razreda• navodi se izvorna i nova vrijednost atributa, događaj koji izaziva promjenu terezultat tj. posljedica promjene. Evidentira se uspješnost testa (Pass/Fail)Class Invariant Test Specification Page ___ of ___Class Name: ________________ Version Number: _____ CRC Card ID: __________Tester: _________________ Date Designed : ________ Date Conducted : ________Testing Objectives:Test CasesInvariant Original Event New Expected ResultDescription Attribute Attribute Result P/FValue ValueAttribute Name:1) ____________ _________ _______ ________ ________ ____2) ____________ _________ _______ ________ ________ ____3) ____________ _________ _______ ________ ________ ____Attribute Name:1) ____________ _________ _______ ________ ________ ____FER \ Fertalj: Razvoj informacijskih sustava55FER \ Fertalj: Razvoj informacijskih sustava56

Testiranje jedinica Testiranje jedinica (unit testing), pojedinačno testiranje• najmanja jedinica mjere je razred !• testovi primjenjivi na nadređeni razred primjenjivi su na iz njega izvedenerazrede• svaki puta kad se razred koristi u različitom kontekstu treba biti ponovnotestiran» vrste testiranja Funkcionalno (black-box testing)• provjera se što cjelina radi, to jest da li zadovoljava zahtjeve• probni slučajevi izvode se iz specifikacija• provodi osoblje proizvođača ili korisnici• osnovica plana testiranja: CRC kartice, dijagrami razreda, ugovori Strukturalno (white-box, clear box testing)• provjera kako cjelina radi• probni slučajevi izvode se uvidom u programski kôd (inspekcija koda)• provode programeri• osnovica plana testiranja: specifikacije metodaIntegracijsko testiranje Integracijska provjera (integration testing)• ispitivanje komponenti koje integrirane čine cijeli sustav ili neki njegov dio• razine: razredi koji tvore logičku cjelinu, sloj, paket, knjižnica• ispitivanje provodi tim (analitičara i programera) za testiranje» vrste testiranja Testiranje korisničkog sučelja (User Interface Testing)• provjerava se svaka funkcija sučelja• osnovica: dizajn sučelja• testiranje se radi prolaskom kroz svaku stavku izbornika sučelja. Testiranje slučajeva korištenja (Use-Case Testing)• provjerava se svaki slučaj korištenja• osnovica: slučajevi korištenja• testiranje se radi prolaskom kroz svaki slučaj korištenja.• često se kombinira s testom korisničkog sučelja jer UC ne testira sva sučeljaFER \ Fertalj: Razvoj informacijskih sustava57FER \ Fertalj: Razvoj informacijskih sustava58Integracijsko testiranje (nastavak)Testiranje sustava Testiranje interakcije (Interaction Testing)• testiranje svakog procesa korak po korak• osnovica: dijagrami razreda, dijagrami slijeda, dijagrami komunikacije• Cijeli sustav započinje kao skup okrajaka. Razredi se dodaju pojedinačno irezultati razreda uspoređuju se s očekivanim ispravnim rezultatima iz testnihpodataka. Nakon što jedan razred prođe testove, dodaje se sljedeći razred iponavljaju se testovi. To se radi za svaki paket. Jednom kada svi paketiprođu sve testove, proces ponavlja integriranje paketa. Testiranje sučelja sustava (System Interface Testing)• testiranje razmjene podataka s drugim sustavima• osnovica: dijagrami slučajeva korištenja• Budući su prijenosi podataka između sustava često automatizirani, akorisnici ih izravno ne prate, važno je oblikovati testove koji će osigurati dase prijenosi obavljaju ispravno. Provjera sustava (System Testing)• provjera rada sustava kao cjeline, kojom se osigurava da svi nezavisnorazvijeni aplikacijski programi rade ispravno te sukladno specifikacijama» vrste testiranja Testiranje zahtjeva (Requirements Testing)• testiranje jesu li zadovoljeni izvorni poslovni zahtjevi• osnovica: dizajn sustava, testovi komponenti i integracijski testovi• Osigurava da promjene tijekom integracije nisu dovele do novih pogrešaka.• Testeri se pretvaraju da su nekompetentni korisnici i izvode neprikladneradnje da testiraju robustnost (npr. dodavanje praznih ili duplih zapisa). Testiranje uporabivosti (Usability Testing)• testiranje prikladnosti sustava za korištenje• osnovica: dizajn sučelja i slučajevi korištenja• Često ih radi analitičar koji ima iskustva u razumijevanju korisnika kao i udobrom dizajnu sučelja.FER \ Fertalj: Razvoj informacijskih sustava59FER \ Fertalj: Razvoj informacijskih sustava60

Testiranje sustava (nastavak)Test prihvatljivosti Testiranje sigurnosti (Security Testing)• testiranje mogućnosti oporavka i neautoriziranog pristupa• osnovica: dizajn infrastrukture• Testiranje sigurnosti je složen zadatak kojeg obično radi analitičarinfrastrukture. U ekstremnim slučajevima, provodi zasebna tvrtka. Testiranje performansi (Performance Testing)• ispitivanje sposobnosti izvođenja pod velikim opterećenjem• stress testing - velik broj interakcija• load testing – velika količina podataka• osnovica: prijedlog sustava, dizajn infrastrukture• Izaziva se velik broj transakcija, često generatorima probnih podataka. Testiranje dokumentacije (Documentation Testing)• testiranje ispravnosti dokumentacije• osnovica: sustav pomoći, postupci, priručnici• Analitičar provjerava svaku stavku dokumentacije kako bi osigurao da suprimjeri u dokumentaciji i ponašanje sustava usklađeni. Provjera prihvatljivosti (Acceptance Testing)• test sustava kojim se dokazuje da proizvod zadovoljava korisničke zahtjeve i potrebeorganizacije te uvjete pod kojima ga je naručitelj spreman preuzeti• iscrpan i konačan test nad stvarnim podacima Alfa-testiranje (Alpha Testing) - verifikacijsko• probna uporaba koju provode korisnici kod izvođača• simulacija stvarnog okruženja• traženje pogrešaka i propusta Beta-testiranje (Beta Testing) – validacijsko• provode korisnici kod sebe, bez nazočnosti izvođača• provjera u stvarnim uvjetima• performanse sustava• vršna opterećenja• provjera upotrebljivosti i lakoće uporabe• metode i procedure• izrada rezervnih kopija i oporavak sustava Nadzorni test (Audit Test) – provodi se opcionalno• potvrda da je sustav gotov, ispravan i spreman za primjenu• provode nezavisne tvrtke ili odjeli za osiguranje kvaliteteFER \ Fertalj: Razvoj informacijskih sustava61FER \ Fertalj: Razvoj informacijskih sustava62Neki primjeriRazvoj vođen testiranjem Provjera u kojoj sudjeluju poznati korisnici (alfa, beta)• Provjeru obavlja ogledna skupina krajnjih korisnika koja, koristeći napravljena rješenja,nastoji obaviti svoje svakodnevne poslove.• Po želji krajnji korisnik dodatno iznosi svoja zapažanja ili prijedloge.• Primjedbe se prikupljaju dnevno a pogreške uklanjaju po mogućnosti istog dana.• Prikupljeni dodatni zahtjevi se procjenjuju te se izrađuje lista prioriteta ugradnje.• Nerealni i preveliki zahtjevi se odbacuju ili se planira njihova naknadna ugradnja. Plan testiranja• identifikator programa ili dijela obrade (npr. naziv opcije izbornika ili zaslona)• naziv funkcije (npr. unos ili izmjena)• vrstu poduzete akcije (npr. potvrda pohrane ili prekid obrade)• identifikator ili opis podatka koji se želi obraditi• ponašanje programa (npr. neregularni završetak rada, neispravni podaci, pogrešanprikaz podataka), po potrebi očekivani rezultat Primjer: Izrada\ ObrazacZaTest Razvoj vođen testiranjem (Test Driven Development)• Testovi se pišu prije koda, tj. ne kodira se nešto za što ne postoji test• U svakoj iteraciji po obavljanju testa provodi se refaktoriranje Automatizacija testiranja• koriste se alati za automatsko testiranje koji rezultate testiranja uspoređuju sočekivanim rezultatima• xUnit (jUnit, nUnit, csUnit) Regresijsko testiranje (regression testing), retesting• provjera kojom se dokazuje da softver nije nazadovao (regressed)• pokretanje svih testova (starih i nanovo dodanih) pri promjeni softvera Primjeri: Izrada \ VrsteTestova.xls, formulari specifikacija i testovaFER \ Fertalj: Razvoj informacijskih sustava63FER \ Fertalj: Razvoj informacijskih sustava64

PrimjerRazred AutomobilTests – testiranje jedinica Primjer: Izrada \Testiranje – RentACarNajamClassPropertiesMethodsNajamAdresadodajAutomobilNajamsadrziAutomobilautiAutomobilClassPropertiesMethodsadresaKilometriAutomobilizracunajKilome…AdresaClassPropertiesDrzavaPostanskiBrojUlicaMethodsAdresaModelAutomobilModelClassPropertiesBrojModelaCijenaMethodsProizvodacAutaAutomobilModelProizvodacClassKlasaAutaPropertiesNazivMethodsProizvodacKlasaClassPropertiesNazivMethodsKlasa Primjer: Izrada \Testiranje – TestiranjeJedinica• Projekt: classLibrary• Reference: csUnit, projekt koji se testira (RentACar) Kreira se razred kojem se pridružuje atribut [TextFixture]• Označava iz kojih razreda će se pokretati testovi (test cases)• Nema parametara i može se primijeniti samo na razrede Metode koje pokreću testove označavaju se atributom [Test][TestFixture]public class AutomobilTests{[Test]public void testKreiraj(){//Korak 1: Kreiranje objekata//Korak 2: Upravljanje objektima//Korak 3: AssertFER \ Fertalj: Razvoj informacijskih sustava65FER \ Fertalj: Razvoj informacijskih sustava66Primjer postupka za testiranjeTest nakon refaktoriranja Primjer: Izrada \Testiranje – TestiranjeJedinica.AutomobilTest.cs• Tools \ cdUnit \ Tests – označavanje i pokretanje označenih/svih testova[Test]public void testKreiraj(){//Kreiranje objekata i upravljanje objektimaKlasa klasa = new Klasa("Salonac");Proizvodac proizvodac = new Proizvodac("Figuar");string brojModela = "Blur 1.6";int cijena = 30;}AutomobilModel automobilModel = new AutomobilModel(klasa, proizvodac, brojModela, cijena);int kilometri = 234243;Automobil automobil = new Automobil(automobilModel, 33445);//AssertAssert.Equals(automobil.Kilometri, kilometri);FER \ Fertalj: Razvoj informacijskih sustava67 Primjer: Izrada \Testiranje – ... AutomobilTestR.cs• Obje metode testKreiraj i testSetKilometri zahtijevaju kreiranjeobjekta Automobil• Refaktoriranjem je taj zajednički dio koda izdvojen u zasebnu metodu SetUp• Atribut [SetUp] označava metodu koja će se izvesti prije svakog testa• Atribut [TearDown] označava metodu koja će se izvesti nakon svakog testa[TestFixture]public class AutomobilTestsR{[SetUp]public void SetUp(){...}[Test]public void testKreiraj() ...FER \ Fertalj: Razvoj informacijskih sustava68

Primjer regresijskog testiranja (1)Primjer regresijskog testiranja (2) Primjer: Izrada \Testiranje – RentACar.RegresijskoTestiranje• Jedna mogućnost je da se označe testovi u csUnit i pokrene Run Checked• Drugi način je korištenjem ugrađenih mogućnosti okoline Visual Studio• Regresijsko testiranje se simulira opcijom grupiranja jediničnih testova• Namespace Microsoft.VisualStudio.TestTools.UnitTesting• U izborniku odabrati Test \ Windows \ Test List Editor• Jedinični testovi se rade ručno ili automatski (desni klik na klasu/metodu)• Koriste se slični atributi kao i kod csUnit[TestClass()]public class AutomobilTest{ ...[TestInitialize()]public void MyTestInitialize(){[TestMethod()]public void KilometriTest() {...Assert.AreEqual(automobil.Kilometri, novaUdaljenost);FER \ Fertalj: Razvoj informacijskih sustava69 Primjer: Izrada \Testiranje – RentACar.RegresijskoTestiranjeFER \ Fertalj: Razvoj informacijskih sustava70Otklanjanje pogrešaka (debugiranje) Debugiranje (debugging)• Posljedica testiranja, ali je nezavisna aktivnost, tj. nije testiranje• Može biti jedan od najviše iscrpljujućih dijelova razvoja• Otkrivanje pogreške napornije (dugotrajnije!) od ispravljanja• Slično liječenju osobe - vidimo simptome i pokušavamo pronaći uzrok Simptom• može biti povremen• može nestati kada seispravi neki drugi problem Uzrok• može biti pogreška sustavaili prevoditelja• može biti ljudska pogreškasimptomkoju je teško otkriti• mogu biti pretpostavke u koje svi vjeruju Simptomi i uzroci mogu biti prostorno odvojeni Pritisak da se isprave pogreške često dovodi do novih !uzrokTehnike otklanjanja pogrešaka Gruba sila – jaki oslonac na računalo• ispisi memorije• praćenje izvođenja koda Vraćanje unatrag (backtracking) – unatražno praćenje• početi od mjesta gdje se problem javlja i unatraške tražiti uzrok• upotrebljivo za manje programe Eliminacija uzroka• pokušati stvoriti skup ulaznih podataka koji potvrđuju ili opovrgavajuodređenu teoriju• teško, no često jedino što je moguće ! Preporuke za otklanjanje• Alati za debugiranje - mogu pomoći stjecanju boljeg pregleda situacije• Razgovor s kolegama — možda drugi primijete ono što autor ne vidi• Izolacija i usredotočenost – promisliti problem, neka rješenja nađu se kadste udaljeni od računala• Regresijsko testiranje - nakon što je pogreška ispravljena !FER \ Fertalj: Razvoj informacijskih sustava71FER \ Fertalj: Razvoj informacijskih sustava72

Raspodjela broja otkrivenih pogrešakaStatistika pogrešaka: pojava i ispravakzahtjevi projekt ugradnja20 % 38 % 42 %Ugrađenepogreške1 % 2 % 20 % 30 % 40 % 7 %pregledzahtjevapregledprojektapregledkoda+pojedinačnaprovjeraprovjerapodsustavaprovjera primjenasustava iprihvaćanjeUočenepogreškeFER \ Fertalj: Razvoj informacijskih sustavaSlika: A.Dennis, B.H.Wixom, D.Tegarden:Systems Analysis and Design with UML,John Wiley & Sons73FER \ Fertalj: Razvoj informacijskih sustava74Vrijeme razvoja i postotak uklonjenih pogrešaka• Odnos trajanja razvoja i postotka uklonjenih pogrešaka [Jones 1991].Vrijeme razvoja i postotak uklonjenih pogrešaka• U aplikacijama u kojima je otklonjeno 95% pogrešaka, svaki daljnji trud uotklanjanju pogrešaka povlači za sobom velika vremenska ulaganja.• Napor koji je potrebno uložiti za ispravak preostalih pogrešaka smislen jekada se radi o sustavima bitnim za životne funkcije (npr. sustav zaodržavanje života u Space Shuttle-u).• Područje oko točke koja prikazuje 95% otklonjenih pogrešaka predstavljanajkraći razvojni ciklus, najmanji napor u izradi i najveće zadovoljstvokorisnika isporučenom aplikacijom.• U aplikacijama u kojima je nakon isporuke pronađeno više od 5%pogrešaka, razvoj je trajao dulje od optimalnog.• Aplikacije koje su isporučene pod vremenskim pritiskom, imaju do 4 putaviše pogrešaka u odnosu na druge [Jones 1994].• Klasična zabluda je da je testiranje luksuz kada je rok završetka blizu.• Umjesto odbacivanja problematičnih rutina i pisanja čistog programskogmodula ispočetka, programeri pribjegavaju prečicama koje za posljedicuimaju kasnije razbacivanje vremenom radi ispravljanja programa.FER \ Fertalj: Razvoj informacijskih sustava75FER \ Fertalj: Razvoj informacijskih sustava76

Moduli s najvećim postotkom pogrešaka Moduli na koje otpada disproporcionalno velik postotak pogrešaka• Takvi moduli su skuplji i vremenski zahtjevniji u odnosu na module s nižimpostotkom pogrešaka, a obično su veći i lošije strukturirani. Pravilo 80:20• Uobičajeno 20% modula sadrži 80% svih pogrešaka [Boehm 1987b].• IBM je utvrdio da u projektu IMS čak 57% pogrešaka otpada na 7% modula[Jones 1991].Izrada dokumentacije Treba identificirati module u kojima se pojavljuje najveći postotakpogreški, te ih redizajnirati• npr. ako se na svakih 1000 redaka u modulu pojavljuje 10 pogrešakaFER \ Fertalj: Razvoj informacijskih sustava77Sistemska dokumentacijaKorisnička dokumentacija Sistemska dokumentacija• dokumentira razvoj i proizvode pojedinih faza• namijenjena tehničkom osoblju• potrebna za razumijevanje, izradu i održavanje sustava• glavnina (pisane) dokumentacije nastaje tijekom analize i projektiranjasustava• programska dokumentacija dijelom se može generirati Korisnička dokumentacija• pomoć korisnicima pri korištenju aplikacija• mora biti prilagođena korisnicima različitog iskustva• korisnički priručnik, upute za uporabu (user manual)• materijali za poduku, upute za vježbu (training guide, tutorial)• dinamička pomoć (online help) upravljanje projektom i konfiguracijom sustava• plan razvoja, specifikacija zahtjeva i dizajna, ... programska dokumentacija• izvorni kôd, opis baze podataka, probni podaci i rezultati provjere, dnevnikpromjena, programski priručnici upute za rukovanje i održavanje (installation, operations manual)• opis instalacijske procedure• opis procedura za pokretanje/zaustavljanje (startup/shutdown)• opis izrade rezervnih kopija i vraćanja podataka (backup, restore)• opis postupka ponovnog pokretanja i oporavka (restart, recovery) Vrste korisničke dokumentacije s obzirom na strukturu• referentni priručnik (reference document),najčešće sustav pomoći• kad korisnik treba naučiti kako obaviti neku funkciju• obično se čita nakon što je intuitivan pokušaj obrade bio neuspješan,stoga treba biti prikladno/pažljivo napisan• priručnik procedure (procedure manual)• opisuje kako obaviti poslovne zadatke koji se sastoje od više funkcija ilikoraka, npr. ispis mjesečnog izvješća, zaprimanje narudžbe• vodič, lekcija (tutorial)• podučava kako koristiti glavne komponente sustava• elementi dokumentacije dulji i oblikovani tako da se čitaju u slijeduFER \ Fertalj: Razvoj informacijskih sustava79FER \ Fertalj: Razvoj informacijskih sustava80

Planiranje dokumentiranja Dokumentiranje se često ostavlja za kraj izrade – rizično ! Vremenski zahtjevan postupak izrade dokumentacije• dizajn dokumenata, pisanje teksta, uređivanje teksta, testiranje dokumenata• 3h po stranici pisanog teksta• 2h po zaslonu dinamičke pomoći Planiranje izrade dokumentacije• dokumentiranje treba ugraditi u plan projekta• početak izrade okvirno nakon što je definirano korisničko sučelje inapravljene programske specifikacije• kraj izrade planirati za neposredno nakon pojedinačnog testiranja• time se smanjuje volumen izmjena a ostavlja vrijeme za moguće promjenePreporuke za izradu dokumentacije Prilikom izrade treba• izbjegavati ponavljanje i neodređenost• koristiti standardizirane dokumente• prije objavljivanja provjeriti da odgovara namjeni Između ostalog, dobra dokumentacija mora:• biti napisana s gledišta čitatelja, a ne pisca• konzistentnost pojmova, jednostavnost izraza, kratka poglavlja• biti dobro ilustririrana (slikama zaslona i njihovog redoslijeda)• opisivati postupak rada, a ne samo sadržaj zaslona• npr. redoslijed popunjavanja šifrarnika, određivanje lozinki i pravapristupa, radne procedure• bilježiti načela (argumente odluka)• odražavati stvarno stanje opreme u primjeni, tj. biti ažurna• uključivati rječnik korištenih izraza Preporuča se odvojeno pohranjivati odgovarajuću inačicuprogramske opreme (alata) kojom je proizvod napravljen.FER \ Fertalj: Razvoj informacijskih sustava81FER \ Fertalj: Razvoj informacijskih sustava82Primjeri Dokumentacija po IEEE standardu• Plan validacije i verifikacije softvera - Software Validation and Verification Plan(SVVP)• Plan osiguranja kvalitete softvera - Software Quality Assurance Plan (SQAP)• Plan upravljanja konfiguracijom softvera - Software Configuration Management Plan(SCMP)• Plan upravljanja softverskim projektom - Software Project Management Plan (SPMP)• Specifikacija zahtjeva na softver - Software Requirements Specification (SRS)• Specifikacija dizajna softvera – Software Design Document (SDD)• Dokumentacija o provjeri softvera - Software Test Documentation (STD) Primjeri: Predlošci• neki od gore navedenihPrimjena Primjeri: Izrada• *DOC, *HLP Primjer: DOO-UputeFER \ Fertalj: Razvoj informacijskih sustava83

Uvođenje u primjenu Uvođenje u primjenu podrazumijeva promjenu u sustavu Upravljanje promjenama smatra se najtežim zadatkom te uključuje• Odmrzavanje (Unfreezing) – napuštanje starih navika i normi• Prijelaz (Moving) – prijelaz sa starog na novi sustav• Zamrzavanje (Refreezing) – usvajanje i uhodavanje novog načina rada Plan migracije uključuje tehničke ali i organizacijske aspekteSlika: A.Dennis, B.H.Wixom, D.Tegarden:Systems Analysis and Design with UML,John Wiley & Sons Konverzija sustavaTehnička konverzija• tehnički proces u kojem novi sustav zamjenjuje stari sustav Glavni koraci – najčešće slijedni na pojedinoj lokaciji• instalacija hardvera• instalacija softvera• konverzija podataka – najsloženija uslijed promjene strukture podataka• inicijalni unos podataka, npr. novih šifrarnika• prijenos postojećih podataka uz konverziju, najčešće matičnih podataka• prijenos zbirnih stanja poslovna transakcija, za tzv. "prometne" podatke• odgovarajući plan testiranja Konverzija se provodi u 3 "dimenzije"• stil konverzije (conversion style) – način uvođenja• lokacija konverzije (conversion location) - gdje• moduli konverzije (conversion modules) – što, koji dijeloviFER \ Fertalj: Razvoj informacijskih sustava85FER \ Fertalj: Razvoj informacijskih sustava86Način konverzijeLokacija konverzije Izravno uvođenje (direct conversion, abrupt cutover, cold turkey,big bang)• početak rada novog sustava uz istovremeni prestanak rada starog sustava• u poslovnim sustavima provodi se na određeni dan, uobičajeno datumzavršetka poslovnog razdoblja, po mogućnosti na kraju tjedna• mogući problemi: pojava pogrešaka koje nisu bile uočene tijekom testiranja,nepredviđeno preopterećenje opreme u punom pogonu• nedostatak: neposredna izloženost korisnika pogreškama sustava Paralelno uvođenje (parallel conversion)• istovremeni rad starog i novog sustava tako dugo dok se ne pokaže da novisustav ispravno radi i da su se korisnici navikli na novi način rada• bitno manje rizičan postupak u odnosu na izravno uvođenje• nedostatak: potreba za dvostrukom obradom istih podataka, u starom i unovom sustavu → otpor korisnika Primjeri: Foto marketing, D.O.O, Učilište Lokacija konverzije• dijelovi organizacije smješteni na različitim zemljopisnim lokacijama• u nekim slučajevima lokacijom se smatraju različite organizacijske cjeline u istomkompleksu (npr. prodaja, otprema, nabava) Probno uvođenje (pilot conversion)• izravno/paralelno uvođenje sustava na jednoj lokaciji ili u jednoj radnoj cjelini• nakon što sustav uspješno prođe pilot test, uvodi se na ostalim lokacijama• prednost: dodatna razina provjere prije širenja po organizaciji, pa se problemiodražavaju samo na probnu instalaciju• nedostaci: dulje trajanje, razdoblje u kojem različiti dijelovi sustava koriste različiteverzije sustava što otežava razmjenu podataka Postupno uvođenje, fazno uvođenje (phased conversion)• uvođenje slijedno po grupama lokacija• jedna skupina lokacija, pa druga, ...• karakteristike slične probnom, s tim da zahtijeva manje osoba Istovremeno uvođenje (simultaneous conversion)• istovremeno uvođenje na svim lokacijama – najčešće izravno• uklanja heterogenost, ali zahtijeva više ljudi Primjeri: MinistarstvoFER \ Fertalj: Razvoj informacijskih sustava87FER \ Fertalj: Razvoj informacijskih sustava88

Modularnost konverzijeOdabir strategije uvođenja u primjenu Uvođenje cijelog sustava (whole system conversion)• čitav sustav instalira se odjednom – najčešći način• u slučaju velikih sustava (npr. ERP, kao što su SAP ili PeopleSoft), možebiti naporno usvajanje za korisnike Modularno uvođenje (modular conversion, staged conversion)• postupna zamjena starog sustava novim, uvođenjem po dijelovima• izvedivo samo ako je moguć istovremeni rad oba (nekompletna) sustava• problemi: potreba za spojnim programima, tj. premošćivanjem• svaki modul treba moći raditi i sa starim i s novim sustavom, ili• novi sustav mora moći učahuriti funkcionalnost starog• prednost: postupni prijelaz, lakša poduka korisnika• nedostatak: dulje trajanje Primjeri: UčilišteUvođenje Rizik Trošak TrajanjeIzravno visok nizak (ako uspije) kratko (ako uspije)Paralelno nizak visok dugoProbno nizak srednji srednjeFazno srednji srednji dugoIstovremeno srednji srednji kratkoCijeli sustav visok srednji kratkoModularno srednji visok dugoFER \ Fertalj: Razvoj informacijskih sustava89FER \ Fertalj: Razvoj informacijskih sustava90Upravljanje promjenamaPoduka Upravljanje promjenama (Change Management)• podrška procesa prilagodbe korisnika na novi sustav Ključne uloge• sponzor promjena (sponsor of the change) – osoba koja želi promjenu• najčešće poslovnjak koji je pokrenuo zahtjev za novim sustavom ili viširukovoditelj organizacijske cjeline u koju se uvodi sustav• presudno je da bude aktivan jer upravlja onima koji usvajaju sustav• agent promjena (change agent) – osoba/osobe koje vode promjenu• obično netko izvan organizacijske jedinice na koju se promjena odnosi• usvojitelj promjena (adopter) – osoba/osobe na koje se promjena odnosi• ljudi koji će u konačnici koristiti novi sustav Otpor promjenama• što je dobro za organizaciju, ne mora biti dobro za pojedinca• promjena radne procedure ne mijenja iznos plaće• promjena zahtijeva napor prilagodbe Priprema, obuka (training)• usvojitelji će prihvatiti sustav ukoliko ih se osposobi• obuka daje potrebne vještine Sadržaj poduke• kako obaviti svoj posao (a ne kako koristiti sustav) !• što korisnik treba napraviti s pomoću sustava (a ne što sustav može) Poduka krajnjih korisnika može uključivati:• opću informatičku kulturu (npr. uporaba osobnih računala)• funkcije sustava i način uporabe sustava, to jest korištenje aplikacija• poduku iz posebnih znanja potrebnih za obavljanje osnovne djelatnosti (npr.optimizacija proizvodnje, projektiranje primjenom računala, GIS) Poduka tehničkog osoblja može uključivati:• operacijski sustav i uslužne programe• administriranje baze podataka• programske jezike, razvojne alate i alate za projektiranjeFER \ Fertalj: Razvoj informacijskih sustava91FER \ Fertalj: Razvoj informacijskih sustava92

Način poduke Redoslijed poduke• prvo se obavlja poduka tehničkog osoblja koje će održavati sustav i pružati potporukrajnjim korisnicima, da bi se mogla pokrenuti primjena• zatim bi trebalo obrazovati (niže) rukovodstvo, da bi se stekla njegova potpora pripoduci ostalih korisnika te tijekom primjene• slijedi školovanje (krajnjih) korisnika, koje treba prilagoditi funkcijama koje oniobavljaju u svakodnevnom radu Postupci i tehnike poduke• tečajevi• probni rad fazi provjere rada sustava• kvalitetni sustav interaktivne pomoći• prikladna dokumentacija• potpora tijekom primjeneOdržavanje Izvođači poduke mogu biti• unutarnji izvođači - npr. odjel informatike ili grupa za to djelatnika• vanjski izvođači – konzultanti, specijalizirane ustanove ili visokoobrazovne ustanove Primjeri: HŽ, HŠ, IPISVUFER \ Fertalj: Razvoj informacijskih sustava93Sistemska potpora i održavanje sustava Post-implementacija, post-produkcija – razdoblje nakon uvođenja uprimjenu, ključne aktivnosti• sistemska potpora (system support)• održavanje sustava (system maintenance)• ocjena projekta (project assessment) Sistemska potpora• nakon uvođenja sustav preuzima "operativna grupa" – služba informacijskepotpore ili oformljeni centar kompetencija• pomoć korisnicima korištenju sustava (on-demand training)• pomoć korisnicima "kad nešto zapne" (hardver, mreža, virusi, ...)• računalna podrška (online support) – web stranice koje sadržedokumentaciju, odgovore na često postavljana pitanja (FAQ, ...)• odjel pomoći (help desk) Višerazinska organizacijaOdjel pomoći• Prva razina podrške (1st level support) – odgovara na široki raspon zahtjeva• očekuje se da razriješi 80% problema• inače sastavlja zapisnik problema (problem report) i prosljeđuje 2. razini• Druga razina podrške (2nd level support) – složenija stručna pomoć• mogu biti timovi po struci: npr. desktop tim, mrežni tim• Ukoliko se ne pronađe rješenje nego se ispostavi da postoji bug• zapisnik problema postaje zahtjev za promjenom (change request) kojise prosljeđuje odjelu održavanja Sustav za praćenje problema (issue tracking system, trouble ticketsystem, incident ticket system)• sadrži bazu znanja o problemima, rješenjima, korisnicima, ...• omogućuje praćenje problema korisnika• evidentira kartone (ticket) s jedinstvenim brojem (unique reference number)• karton je datoteka s informacijama o problemu i intervencijamaFER \ Fertalj: Razvoj informacijskih sustava95FER \ Fertalj: Razvoj informacijskih sustava96

Održavanje (IEEE, 1993):Održavanje sustava• Modifikacija programskog proizvoda nakon isporuke da bi se ispravilikvarovi, popravile performanse ili druga svojstva ili da bi se proizvodprilagodio promjenama okruženja Održavanje je trajna aktivnost koja započinje odmah po uvođenju• Bez obzira na to koliko je sustav dobar, kvarovi su neizbježni! Zahtjev za promjenom (change request)• manja verzija zahtjeva na sustav (system request) s početka ciklusa• najčešći razlozi (po prioritetu)• prijava kvara• zahtjev za poboljšanje – npr. ugradnja nove funkcije• zahtjevi vanjskih sustava s kojima se očekuje integracija – npr. ISVU-IPISVU• nove inačice sistemskog softvera, npr. baze podataka ili operacijskogsustava• zahtjevi višeg rukovodstva, obično radi promjena strategije organizacije PreventivnoVrste održavanja• podrazumijeva zaštitu od mogućih problema• redovita izrada sigurnosnih kopija (backup)• obavlja se periodički (dnevno, tjedno, mjesečno) Korektivno• podrazumijeva popravak nakon što se problem pojavio• vraćanje podataka iz sigurnosne kopije (restore)• uklanjanje uzroka pogreške (ispravljanje programa) Adaptivno• prilagodba funkcionalnosti (načina posluživanja)• prilagodba strukture (promjene strukture podataka)• poboljšanje performansi (optimizacija programa) Perfektivno• nadgradnja sustava da bi se riješili novi problemi• ugradnja novih mogućnosti (features) Primjeri: Primjena \ MaintInsFER \ Fertalj: Razvoj informacijskih sustava97FER \ Fertalj: Razvoj informacijskih sustava98• http://www.refactoring.com/Materijali• M.M. Lehman, Laws of Software Evolution Revisited, Lecture Notes in ComputerScience , London, 1996.• Izrada \ Lehman-2• Unit Testing and Generating Source Code for Unit Test Frameworks Using VisualStudio 2005 Team System• http://msdn.microsoft.com/en-us/library/ms364064.aspx• Alati za jedinično testiranje• http://www.csunit.org/• http://www.nunit.org/index.php• Team Development with Visual Studio Team Foundation Server• http://www.codeplex.com/TFSGuide• Adaptable Process Model Document Templates• http://www.rspa.com/docs/index.html• Construx Material Types• http://www.construx.com/Page.aspx?hid=571 LiteraturaReference• A.Dennis, B.H.Wixom, D.Tegarden: Systems Analysis and Design with UML,John Wiley & Sons, 2005• M. Fowler. Refactoring: Improving the Design of Existing Code,Addison-Wesley Professional, 1999.• Mike O’Docherty: Object-Oriented Analysis And Design UnderstandingSystem Development With Uml 2.0, John Wiley and Sons, 2005.• McConell: Code Complete: A Practical Handbook of Software Construction,Microsoft Press; 2nd edition, 2004. http://www.cc2e.com/ Standardi• IEEE Std 1008-1987 (R1993), Standard for Software Unit Testing• IEEE Std 829-1998, Standard for Software Test Documentation• IEEE Std 730-2002, Standard for Software Quality Assurance Plans• IEEE Std 1063-2001, Standard for Software User DocumentationFER \ Fertalj: Razvoj informacijskih sustava99FER \ Fertalj: Razvoj informacijskih sustava100

, ??? Metodologije razvoja10/13MetodologijeTaksonomija metodologija Metodologija (methodology) = metoda + idejni pristup• Kolekcija procedura, tehnika, alata i dokumentacijskih pomagala,potkrijepljenih filozofijom, koji potpomažu izgradnju informacijskog sustava[Avison & Fitzgerald, 1995]• Skup načela izrade IS, koji se u određenoj situaciji svodi na metodujedinstveno prikladnu toj situaciji [Checkland]• razrađen "plan bitke" ili "kuharica" za postizanje željenog rezultata Komponente metodologije (Avison & Fitzgerald, 2003)• definirane faze – varijanta životnog ciklusa• procedure, zadatci, pravila, tehnike i upute za pojedine faze• dokumentacija – formati, predlošci i organizacija dokumenata• alati - preporuke (vodič) uporabe tehnika i pomagala• upute o upravljanju i organizaciji projekta – upravljanje, nadzor, podukasudionika, ... Cilj• standardizirani razvojni proces• bolji i kvalitetniji proizvodFER \ Fertalj: Razvoj informacijskih sustava103FER \ Fertalj: Razvoj informacijskih sustava104

Glavne vrste metodologijaPrimjer modela mekog pristupa Čvrste, tvrde (Hard), teške (Heavy)• teške ili tvrde - zbog opsežnosti, složenosti i velike količine dokumentacije• pozadina potječe od tradicionalnog životnog ciklusa• prvotne, strukturirane su zasnovane na funkcionalnoj dekompoziciji• SSADM (Structured Systems Analysis and Design Method), BSP (BusinessSystem Planning), CASE*Method, IEM (Information Engineering Methodology,Martin), SADT, STRADIS, ...• današnje naglašavaju objektno orijentirani pristup• RUP – nastala fuzijom ranijih objektnih (Booch, OMT, Objectory)• derivati – Open UP, Agile UP, dX (neki spadaju u agilne) Meke (Soft), lagane (Light), agilne (Agile)• naglasak na socološkim i ljudskim aspektima• bave se slabo definiranim, neizrazitim (fuzzy edged) stvarnim situacijama• prvotne meke metodologije - SSM, ETHICS• metode za brzi razvoj aplikacija (Rapid Application Development Methods) – DSDM• moderne agilne metode - XP, Crystal, FDD, Scrum Hibridne metodologije (Hybrid methodologies)• kombinacija tvrdih i mekih Primjer: bogata slika(rich picture)• Checkland SSM(Soft SystemsMethodology)FER \ Fertalj: Razvoj informacijskih sustava105FER \ Fertalj: Razvoj informacijskih sustava106Karakteristike metodologijaTradicionalne naspram agilnih metodologija Kuhanje po kuharici (receptu) ne znači da će jelo biti dobro!• Preporučene aktivnosti ne moraju uvijek biti prikladne, primjenjive ili potrebne• Korisnik je nepredvidljiv i "prevrtljiv" - zahtjevi se mogu mijenjati u vremenu• Inzistiranje na propisanim procedurama vodi u zanemarivanje stvarnih problema• Posljedica: formalno dobro napravljen, a neuspješan sustav Nedostaci metodologija (općenito)• Nedostatak standarda – velik broj varijanti postupaka i notacija• (Ne)odmjerenost – (pre)komplicirane ili (pre)jednostavne• Pokrivenost životnog ciklusa – rijetke podupiru sve faze životnog ciklusa• Podržanost alatima – nepotpuna jer proizvođači alata nastoje približno podržati štoveći broj notacija Dodaci ili alternative metodologijama• zdrav razum• najbolje dokazano u praksi - "Best practices"• prečice do rješenja problema temeljene na temelju sličnih iskustava - "Rules of thumb"TradicionalnipristupModerniagilni pristupProces Prakse Struktura projektneekipeNisu definirane. Gradi sepostepeno, a isporučujesamo jednom.„Težak“: plan strogodefiniran na početku– planski usmjeren(eng. plan driven);linearan i predvidiv„Lagan“: nema strogodefiniranog plana,planiranje se odvijakroz cikluse, proces:nelinearan iprilagodljiv,inkrementalanSedam osnovnih:samoorganizirajuće ekipe,česta isporuka, planiranjeučenja snažnakomunikacija, testiranjesvega, mjerenje vrijednostii „čišćenje puta“Distribuirane ilikolocirane,uglavnom velikeekipe sa strogodefiniranim ulogamaManje, kolociraneekipeFER \ Fertalj: Razvoj informacijskih sustava107FER \ Fertalj: Razvoj informacijskih sustava108

Tradicionalne naspram agilnih metodologija (2)TradicionalnipristupModerniagilni pristupDokumentacijaDobro dokumentirane.Najprije dokumentirati, aonda razvijati premadefiniranim dokumentima.Malo ili bezdokumentacije. Usmjerenona taktičko znanje –dijeljenje znanja izmeđučlanova ekipe.Tipovi programskepodrškeBilo koji tip, ali spovećanim rizikom.Inženjerski ili znanstveni.Veliki ili mali projekti.Poslovni sustavi, spromjenjivim zahtjevima.Manji projekti.AlatiRazličiti alati za svakufazu s kasnijomintegracijom.Integrirana razvojnaokruženja.Odabir metodoloigije Ne postoji, univerzalni ili najbolji pristup• Samo jedna metodologija se ne može primijeniti na sve projekte• Treba identificirati posebnosti projekta na kojem će se raditi i tek ondaodabrati najbolju primjenjivu razvojnu metodologiju. Selekcija metodologije• DESMET - metodologija za evaluaciju metodologija i alata Integracija metoda• Prevladava mišljenje da su potrebna oba pristupa (tradicionalni i agilni)• Kombiniranje postupaka i tehnika za pojedine fazeFER \ Fertalj: Razvoj informacijskih sustava109FER \ Fertalj: Razvoj informacijskih sustava110SSADM Structured Systems Analysis and Design Method• najpoznatija i najčešće korištena• podatkovno-vođena ("data-driven") metodologijaStrukturirane metodologije Faze – moduli, dalje razloženi u stadije (stages)• Studija izvodljivosti - izvodljivost• Analiza zahtijeva - analiza postojeće okoline, opcije poslovnog sustava• Specifikacija zahtijeva - definicija zahtijeva• Specifikacije logičkog sustava - alternative tehničkog sustava, logički dizajn(strukturnim kartama)• Fizički dizajn – fizički dizajn Glavne tehnike• logičko oblikovanje podataka - Logical Data Structure (LDS), slično ERD• oblikovanje toka podataka - Data Flow Modelling, DFD dijagrami• oblikovanje događajaj entiteta - Entity Life Histories (ELH)FER \ Fertalj: Razvoj informacijskih sustava112

Životni ciklus prema SSADMModel života entiteta Povijest života entiteta (Entity Life History)• pogled na sustav usmjeren učincima događaja koji uzrokuju promjene stanja• opisuje vremenski zavisno ponašanje (jednog) entiteta• prati promjene ponašanja entiteta koji prolazi kroz sustav• Dijagram podudarnosti učinaka - Effect Correspondence Diagram (ECD)entitet,bloksl ije dnidogađaj(slijed)alternativnidogađaj(selekcija)ponavljanidogađaj(iteracija)moperacijen oFER \ Fertalj: Razvoj informacijskih sustava113FER \ Fertalj: Razvoj informacijskih sustava114Model života entitetaMetodologija informacijskog inženjerstva Primjer, pojednostavnjena rezervacija sobe u hotelu Proljećerezervacijasobe Information Engineering Methodology (IEM) – James Martin Razvojni okvir (“framework”) sa 7 razina unutar 4 strategije• Planiranje• Analiza• Dizajnprivremenarezervacijarezervacija,nenajav.dolazakdolazakgostapotvrdarezervacije3opozi vrezervacijeopozi vrezervacijeili nedolazaknedolazakgostanajavljenidolazak23stvaranjetroškapovećanjetroškapl aćanjeusluga356arhivi ranjerezervacije7• Konstrukcija (izrada) Osnovno načelo• IS treba graditi kao što se gradedrugi “unikatni” proizvodi, npr. ugraditeljstvu ili brodogradnji1 1 23 341. Kreirati rezervac iju2. Zauzeti sobu3. Ažurirati status rezervacije4. Kreirati zaduženje5. Poništiti zaduženje6. Osloboditi sobu7. Obrisati podatke o rezervaci jiFER \ Fertalj: Razvoj informacijskih sustava115FER \ Fertalj: Razvoj informacijskih sustava116

Ključne faze IEŽivotni ciklus IE projekta• Planiranje strategije IS - Information Strategy Planning (ISP)• promatranje poslovanja kao cjeline s ciljem definiranja općeg, sveobuhvatnogplana i arhitekture za slijedni razvoj informacijskih (pod)sustava• izdvajanje poslovnih područja i pridjeljivanje prioriteta– poslovno područje – skup poslovnih procesa koji se protežu organizacijom a moraju bitivisoko integrirani da bi se ostvarila strategija ili misija• Analiza poslovnih područja - Business Area Analysis (BAA)• proučavanje poslovnih područja i definiranje poslovnih zahtjeva za organizirani iintegrirani skup informacijskih (pod)sustava i aplikacija poslovnog područja• definiranje aplikacija– izdvajanje aplikacija i definiranje prioriteta temeljem analize poslovnih područja– aplikacije postaju projekti u kojima se primjenjuju drugi postupci analize i dizajn Podatkovno usmjerena paradigma• Budući da je informacija proizvod podataka, podaci moraju biti planirani prvi!• Modeliranje započinje modelima podataka• Zatim se rade modeli procesa slično onima u strukturiranoj analiziIDEF porodica metoda Knowledge Based Systems, Inc. (KBSI)• www.idef.com• IDEF0 Integration Definition for Function Modeling• IDEF1 Information Modeling• IDEF1x Data modeling Method – za relacijske baze podataka• IDEF3 Process Flow and Object State Description Capture Method• IDEF4 Object-Oriented Design Method• IDEF5 Ontology Description Capture MethodFER \ Fertalj: Razvoj informacijskih sustava117FER \ Fertalj: Razvoj informacijskih sustava118Modeliranje poslovnih procesa i funkcijaOblikovanje aktivnostiBusiness Process Modeling (IDEF0)• tehnika strukturirane analize i dizajna(Structured Analysis and DesignTechnique - SADT®, SofTech, 1960-ih),zamišljena kao inženjerska disciplina zarazvoj složenih sustava koji uključujustrojeve i ljude• metoda za oblikovanje poslovnih funkcija Oblikovanje sustava hijerarhijom ugniježdenih aktivnosti Aktivnost konteksta - vrh hijerarhije, predstavlja čitav sustavUSED AT: AUTHOR:PROJECT: Process OrdersNOT ES: 1 2 3 4 5 6 7 8 9 10DATE: 05.09.1997REV: 05.09.1997WORKINGDRAFTRECOMMENDEDPUBLICATIONREADERDATE CONTEXT:TOPGrafički prikaz procesa i resursa• proces – niz aktivnosti (funkcija)• aktivnost – prikazana ICOM konceptom• ulaz (I=Input): nešto što se troši u procesu- opcionalan• upravljanje (C=Control): ograničenje naobavljanje procesa - obvezno• izlaz (O=Output): rezultat procesa -obvezan• mehanizam (M=Mechanism): koristi se uprocesu, ali se ne troši - opcionalanNew CustomerInformationPayment VerificationOrderPolicyPROCESS ORDERSProductInventoryProductOrderSystemOn-lineProductCatalogCustomerStatus0CustomerCreditRecordsOrder NumberPackingSlipOrderInvoiceCompare this viewpoint with theOrdrProd.bp1 file. T his is anFER \ Fertalj: Razvoj informacijskih sustava119FER \ Fertalj: Razvoj informacijskih sustava120

USED AT: AUTHOR: DATE:PROJECT: Process OrdersREV:NewCustomerInformationPaymentVerificationNOTES: 1 2 3 4 5 6 7 8 9 10TAKE CUSTOMERORDERDekompozicija aktivnosti1ProductRequest(s)CHECKPRODUCTAVAILABILITY205.09.199705.09.1997AvailableProductsOrderPolicyDOCUMENTORDEREDPRODUCTSCurrentPer UnitPricesPOS(OrderModule)WORKINGDRAFTRECOMMENDEDPUBLICATION3ProductsOrderedDETERMINEPAYMENTMETHODPOS(CreditModule)READER DATE CONTEXT:CustomerStatusQuantitiesOrdered4FinalizedOrderInformationA-0Viewpoint: Order ClerkScope: New Customer OrdersOrder NumberPROVIDEORDERPacking SlipVERIFICATION Order Invoice5Modeliranje toka procesa Metoda Process Flow Modeling (IDEF3)• strukturirana metoda za opis poslovne situacije uređenim slijedom događajai objekata koji u njoj sudjeluju• prikazuje slijed, zavisnost i konkurentnost aktivnosti• prikladna za prikupljanje informacija tijekom analize i dizajna• poslovna politika i poslovne procedure• preoblikovanje poslovnih procesa• modeliranje scenarija kojima se odgovara na pitanja "što-ako"On-lineProductCatalogProductInventoryProductOrderSystemCustomerCreditRecordsNODE: TITLE: PROCESS ORDERSNUMBER:A0FER \ Fertalj: Razvoj informacijskih sustavaPOS(OrderModule)121FER \ Fertalj: Razvoj informacijskih sustava122Primjer toka procesaUSED AT: AUTHOR: Bob Saunders DATE: 06.05.1999PR OJ EC T: It's not just ID EF anymore.R EV: 22.10.1999WORKINGDRAFTR EADERD ATE C ON TEXT:RECOMMENDEDNOTES: 1 2 3 4 5 6 7 8 9 10PU BLIC ATIONA42$0.00CutsomerPlaces OrderA422.1.11Customer $0.00Enquiry /Or derIs CustomerCredit Worthy?A422.1.12A422.1.14No$0.00N otify s alesYes$0.00Fulfill fromstock items?A422.1.13No$0.00Sourceelsewhere?A422.1.15YesAccountstatusChange$0.00Is stockavailable?A422.1.17YesNoNoYes$0.00Accept orderA422.1.18$0.00Reject OrderA422.1.16Ujedinjeni razvojni procesRUP i derivatiFER \ Fertalj: Razvoj informacijskih sustava123

Ujedinjeni razvojni proces softveraStruktura procesa – osnovni elementi Unified software development process (UDP)• okruženje za razvoj softvera temeljeno na iterativnom i inkrementalnomprocesu• najpoznatija komercijalna inačica – IBM Rational Unified Process (RUP) RUP definiraju tri komponente• skup filozofija, ključnih praksi (core pratices, best practices) te načela(process essentials) za uspješan razvoj programske podrške• metodološki okvir izgrađen od višekratno iskoristivih metoda i procesnihblokova• jezik za definiranje procesa• process meta-model• elementi za definiranje procesa• (slika na sljedećoj foliji)FER \ Fertalj: Razvoj informacijskih sustava125FER \ Fertalj: Razvoj informacijskih sustava126Glavne karakteristike URP-aNačela (Process essentials) Produktivnost ekipe• baza znanja (u obliku web stranica) s detaljnim uputama o procesima,predlošcima dokumentacije te uputama za korištenje razvojnih alata• osigurava da svi članovi dijele zajednički jezik, proces i pristup razvoju Vizualno modeliranje• naglašava razvoj i održavanje modela umjesto papirnate dokumentacije Oslonac na UML• tzv. industrijski standard Podržanost alatima• izrada i održavanje raznih artefakata (pretežno modela), vizualnomodeliranje, programiranje, testiranje itd.• alati pomažu razvoj ali i procese upravljanja izmjenama i konfiguracijom Iterativan i inkrementalan razvoj Elastičnost i prilagodljivost• prema veličini ekipa ili tipu projekta• RUP sadrži niz "predložaka" razvojnih procesa (roadmaps) za različitemodele razvoja i tipove projekataVizija: Definirati viziju• artefakt Vizije – dokument zahtjeva visoke razine i ograničenja u oblikovanju• Vizija je jedan od ključnih dokumenata za odobrenje pokretanja projekta.Plan: Upravljati prema planu• RUP izrazito naglašava disciplinu upravljanja projektom• dokumentiranje Planom razvoja softvera (Software Development Plan)Rizici: Ublažiti rizike i pratiti probleme• Čim ranija identifikacija i upravljanje rizicima je vrlo važna• Rizici se opisuju u Registru rizika (Risk List) po prioritetima i s planom razrješenjaPoslovni slučaj: Istražiti poslovni slučaj• Poslovni slučaj opravdava ulaganje u projekt i povrat investicije (ROI)• Postavlja se ekonomski okvir i ograničenja projekta te provjerava tijekom projekta.Arhitektura: Oblikovati arhitekturu zasnovanu na komponentama• RUP definira arhitekturu programskog rješenja kao strukturu sistemskih komponentikoje komuniciraju putem sučelja i sastoje se od manjih komponenti i sučelja• Radi se dokument Arhitekture softvera (Software Architecture Document)FER \ Fertalj: Razvoj informacijskih sustava127FER \ Fertalj: Razvoj informacijskih sustava128

Načela (Process essentials) - nastavakŽivotni ciklus RUP projektaPrototip: Inkrementalno graditi i testirati proizvod• Iterativan i inkrementalan pristup radi što ranijeg otkrivanja i razrješavanja problemaEvaluacija: Redovito procjenjivati rezultate• Redovita izvješća o statusu – identifikacija, komuniciranje i razrješenje problema• Procjena iteracije na kraju svake iteracije – ocjena rezultata i prijedlog promjenaZahtjevi za promjenama: Upravljati izmjenama i kontrolirati izmjene• svi zahtjevi za promjenama moraju biti predloženi i obrađeni kroz konzistentan proces• bilježenje odluka te osiguravanje da svi članovi projektnog tima razumiju promjeneKorisnička podrška: Isporučiti iskoristiv proizvod• Cilj procesa je izrada iskoristivog proizvoda• Proizvod je više od programske podrške – korisnička i sistemska dokumentacijaProces: Osigurati proces koji odgovara projektu• Proces razvoja mora odgovarati tipu rješenja koje se izrađuje.• Čak i kad je proces odabran, treba ga shvatiti fleksibilno i stalno prilagođavatiFER \ Fertalj: Razvoj informacijskih sustava129FER \ Fertalj: Razvoj informacijskih sustava130Faze, discipline i kontrolne točkeGlavne faze razvoja - Počinjanje Horizontalna os predstavlja vrijeme i aspekte životnog ciklusa• cikluse, faze, iteracije i kontrolne točke. Vertikalna os predstavlja discipline - logički grupirane aktivnosti• u ranijim fazama naglasak je na poslovnom modeliranju i prikupljanjuzahtjeva, a u kasnijima na implementaciji, uvođenju u primjenu te upravljanjuizmjenama i konfiguracijom• Disciplina upravljanja projektom ujednačenog je intenziteta. Osnovicu životnog ciklusa čine četiri sekvencijalne faze od kojihsvaka završava velikom kontrolnom točkom Faza incepcije (Inception phase) - Počinjanje• Formuliranje opsega projekta.• opis problemskog konteksta te najvažnijih zahtjeva i ograničenja• prikupljanje najvažnijih zahtjeva (10% detaljno)• preporuča se istaknuti i kritične scenarije korištenja (UC scenariji)• Inicijalna procjena ukupnog troška, vremena i rizika.• Planiranje i priprema poslovnog slučaja.• Izrada prijedloga arhitekture.• Cilj je demonstrirati izvedivost projekta putem nekog modela zasimulaciju, inicijalnog prototipa i sl.• Priprema okruženja za projekt.• Procjena projekta i organizacije, odabir alata, razvojnih okruženja iprocesa.FER \ Fertalj: Razvoj informacijskih sustava131FER \ Fertalj: Razvoj informacijskih sustava132

Glavne faze razvoja - ElaboracijaGlavne faze razvoja - Konstrukcija Faza elaboracije (Elaboration phase) - Razrada• Definiranje, validacija i zacrtavanje arhitekture• Osiguranje da su arhitektura, zahtjevi i planovi stabilni, a rizici ublaženi• tako da se može pouzdano odrediti trošak i završetak projekta.• Prikupljanje detaljnih zahtjeva (80%)• Ažuriranje vizije projekta• dobrim razumijevanjem kritičnih slučajeva korištenja koji su ujedno inositelji najvećih rizika.• Izrada plana iteracija za fazu konstrukcije.• Dorada razvojnog procesa i uspostava razvojnog okruženja• uključujući proces, alate i podršku za automatizaciju• Dorada arhitekture i odabir komponenti.• Radi se procjena potencijalnih komponenti kako bi se mogla odrediticijena i trajanje naredne faze. Faza konstrukcije (Construction phase) - Izgradnja• Upravljanje resursima, kontrola projekta i optimizacija procesa.• Paralelni razvoj nekoliko razvojnih timova s ciljem ubrzanja razvoja.• Završetak iterativnog i inkrementalnog razvoja konačnog proizvoda• Provjera prihvatljivosti• podrazumijeva dovršetak analize, dizajna, razvoja i testiranja• Procjena razvijenih isporuka naspram definirane Vizije projekta• Provjera da li su programska podrška, lokacije i korisnici spremni za betaisporuku.FER \ Fertalj: Razvoj informacijskih sustava133FER \ Fertalj: Razvoj informacijskih sustava134Glavne faze razvoja - TranzicijaProcjena napora i trajanja pojedine faze Faza tranzicije (Transition phase) - Prijelaz• Izvršavanje planova uvođenja u primjenu• Dovršavanje korisničke dokumentacije i uputa• Obuka krajnjih korisnika i održavatelja• Testiranje programskog rješenja na lokaciji isporuke• Izrada isporuke (release) konačnog programskog rješenja• Prikupljanje povratne informacije od krajnjih korisnika• Fino podešavanje rješenja (popravak manjih pogrešaka, poboljšanjeperformansi) na temelju povratne informacije• Omogućavanje proizvoda dostupnim svim krajnjim korisnicima Broj i trajanje iteracija, općenito• za projekte do 18 mjeseci, otprilike 3 do 6 iteracijauložen napor(u odnosu na ukupan)trajanje(u odnosu na ukupno)Počinjanje(Inception)Elaboracija(Elaboration)Konstrukcija(Construction)Prijelaz(Transition)5% 20% 65% 10%10% 30% 50% 10%FER \ Fertalj: Razvoj informacijskih sustava135FER \ Fertalj: Razvoj informacijskih sustava136

Strategije iterativne provedbe RUP projekta (1)Strategije iterativne provedbe RUP projekta (2) Inkrementalna strategija Evolucijska strategija• poznata domena problema• vrlo dobro poznati rizici• iskusan projektni tim• nova ili nepoznata domena problema• neiskusan projektni timFER \ Fertalj: Razvoj informacijskih sustava137FER \ Fertalj: Razvoj informacijskih sustava138Strategije iterativne provedbe RUP projekta (3)Strategije iterativne provedbe RUP projekta (4) Strategija inkrementalne isporuke• poznata domena problema• arhitektura i zahtjevi mogu biti stabilizirani rano u razvojnom ciklusu• malo novog i nepoznatog u projektu• iskusan projektni tim Strategija “Velikog oblikovanja” (vodopadni model)• dodaje se mali inkrement dobro definirane funkcionalnosti na vrlo stabilanproizvod• nova funkcionalnost je vrlo dobro definirana i shvaćena• tim posjeduje iskustvo kako u domeni tako i sa postojećim proizvodom• inkrementalne isporuke su vrlo važne i imaju visoku vrijednost za korisnikaFER \ Fertalj: Razvoj informacijskih sustava139FER \ Fertalj: Razvoj informacijskih sustava140

Glavne discipline Poslovno modeliranje (Business Modeling)• Uspostavlja poslovni kontekst sustava te oblik organizacije u kojoj sustavtreba uvesti u primjenu.• Definiraju se ciljevi i okvirna funkcionalnost, poslovna pravila i sl. Requirements (Zahtjevi)• Definira kako saznati i prikupiti želje zainteresiranih strana te ih pretvoriti uskup zahtjeva koji definiraju doseg sustava i potrebnu funkcionalnost. Analiza i dizajn (Analysis & Design)• Definira pretvorbu zahtjeva u dizajn• Analiza usmjerena na logički pogled i funkcionalne zahtjeve• Dizajn usmjeren na fizički pogled i nefunkcionalne zahtjeve Implementacija (Implementation)• Kako razviti, organizirati, testirati i integrirati komponente Provjera (Test)• Kako testirati i procijeniti kvalitetu rješenja Uvođenje u primjenu (Deployment)• Aktivnosti potrebne da sustav bude dostupan svim krajnjim korisnicimaPodupiruće discipline Upravljanje konfiguracijom i promjenama (Configuration & ChangeManagement)• Disciplina koja opisuje kako kontrolirati i sinkronizirati evoluciju skupakomponenti i isporuka koje zajedno čine konačni sustav Upravljanje projektom (Project Management)• Disciplina usredotočena na planiranje projekta, upravljanje rizicima, praćenjenapretka i metriku Okolina (Environment)• Organizira dijelove metodologije koji pružaju okruženje razvojnom timu,uključujući procese i alateFER \ Fertalj: Razvoj informacijskih sustava141FER \ Fertalj: Razvoj informacijskih sustava142Alati (nazivi se često mijenjaju!)RUP kao programski proizvod IBM Rational Requisite Pro• upravljanje zahtjevima (pisanje, dijeljenje, promjena) IBM Rational ClearQuest• automatizacija postupka zahtjeva za promjenom (change request) IBM Rational Rose• vizualno modeliranje poslovnih procesa, analizu zahtjeva i oblikovanje arhitekture IBM Rational SoDA• automatizacija izrade dokumentacije tijekom cijelog razvojnog ciklusa proizvoda IBM Rational Purify• alat za testiranje i provjeru programskog koda, naročito za pogreške u memoriji IBM Rational Visual Quantify• testiranje performansi sustava i njegovih komponenti IBM Rational TeamTest• izrada, održavanje i provedba funkcionalnih testova IBM Rational PerformanceStudio• mjerenje performansi IBM Rational ClearCase• upravljanje konfiguracijom programskog rješenja Za sve faze putem objedinjenog web sučelja dostupne su detaljneupute oko provedbe konstitutivnih aktivnosti koje se sastoje od:• sažetka i svrhe faze, ključnih ciljeva i aktivnosti• grafičkog prikaza procesa i aktivnosti unutar faze u vidu strukturneraščlambe posla (Work Breakdown Structure)• za svaku aktivnost dostupni su koraci izvođenja, uloge koje ju obavljaju,ulazne i izlazne informacije, primjeri i predlošci za vezane isporuke• detaljnu raspodjelu uloga po aktivnostima faze• popis poželjnih isporuka po aktivnostima faze, uključujući detaljne upute osvrsi, sadržaju i obliku svake isporuke Primjer: RUP(R) Configuration for Microsoft(R) .NET DevelopersFER \ Fertalj: Razvoj informacijskih sustava143FER \ Fertalj: Razvoj informacijskih sustava144

Inačice RUP-aFaze procesa• RUP – Rational Unified Process – IBM (Rational) razvojni proces• EUP – Enterprise Unified Process – proširenje RUP na razinu poduzeća• OUM – Oracle Unified Method – Oracle-ov razvojni i implementacijski proces• BUP – Basic Unified Process – pojednostavnjenje, prethodnik OpenUP• OpenUP – Open Unified Process – agilni razvoj otvorenog kôda temeljen naEclipse Process Frameworku, nastao iz BUP donacijom EclipseFoundationu• AUP – Agile Unified Process – pojednostavnjena agilna inačica Scotta W.Amblera (IBM)• EssUP – Essential Unified Process – pojednostavnjena inačica procesaRUP Ivara Jacobsona temeljena na tzv. „praksama“ (practice)Faze RUP EUP OpenUP Agile UPPočetak (Inception) X X X XRazrada (Elaboration) X X X XIzgradnja (Construction) X X X XPrijelaz (Transition) X X X XProdukcija (Production) XUmirovljenje (Retirement) XFER \ Fertalj: Razvoj informacijskih sustava145FER \ Fertalj: Razvoj informacijskih sustava146Discipline procesaDiscipline RUP EUP Open UP Agile UPPoslovno modeliranje X X XZahtjevi X X XAnaliza i dizajn X X XImplementacija X X X XTestiranje X X X XPostavljanje X X XUpravljanje konfiguracijom i promjenama X X XUpravljanje projektom X X X XOkruženje X X XOperacije i podrška XPoslovno modeliranje poduzeća XUpravljanje portfeljem XArhitektura poduzeća XStrateško ponovno korištenje XUpravljanje kadrovima XAdministracija poduzeća XProces poboljšanja softvera XAgilni postupci razvoja• Open UP: Analiza i dizajn zove se Arhitektura, a implementacija RazvojFER \ Fertalj: Razvoj informacijskih sustava147

Proglas agilnosti agilitas (lat.) - svojstvo brzine, okretnosti, hitrosti, lakoće, radinosti Manifest agilnosti (objava, proglas)– Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, WardCunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt,Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, KenSchwaber, Jeff Sutherland, Dave Thomas– skijalište Snowbird, Utah, 2001.• Pojedinci i interakcije se cijene više od procesa i alata• Softver koji radi se cijeni više od sveobuhvatne dokumentacije• Suradnja s naručiteljem/korisnikom se cijeni više od pregovora o ugovoru• Odziv na promjenu se cijeni više od praćenja planaNačela (principi) agilnosti Zadovoljstvo korisnika ranim i kontinuiranim isporukama softvera Promjene zahtjeva se željno prihvaćaju, čak i u kasnoj fazi razvoja Česta i čim ranija isporuka softvera koji radi• od polumjesečnih isporuka do isporuka svakih nekoliko mjeseci Česta (dnevna) suradnja „poslovnjaka“ i razvojnika Motiviranje pojedinaca za rad u projektu• prikladno okruženje i povjerenje Najefikasnija i najefektivnija metoda za prijenos informacija• razvojnom timu i unutar njega je usmena komunikacija Glavna mjera napretka - softver koji radi Agilni procesi promiču održivi razvoj• sponzori, razvojni tim i korisnici trebaju održavati stalni tempo Kontinuirana pažnja na tehničku izvrsnost i dobar dizajn potičuagilnost Jednostavnost je nužna Najbolje arhitekture, zahtjevi i dizajn - iz samo-organiziranih timova Tim spoznaje kako postati efektivniji, a zatim se često prilagođavaFER \ Fertalj: Razvoj informacijskih sustava149FER \ Fertalj: Razvoj informacijskih sustava150Naziv metodeEkstremno programiranje (XP -eXtreme Programming)Scrum (Scrum)Kristalne metode (Crystal methods)Razvoj vođen mogućnostima (FDD -Feature Driven Development)Metoda za dinamički razvoj sustava(DSDM – Dynamic SystemsDevelopment Method)Prilagodljivi razvoj programskepodrške (ASD – Adaptive SoftwareDevelopment)Razvoj programske podrškeotvorenim kodom (OSS – OpenSource Software Development)Agilno modeliranje (AM - AgileModeling)Vižljasti razvoj (LD – LeanDevelopment)FER \ Fertalj: Razvoj informacijskih sustavaAgilne metodeAutorKent BeckKen SchwaberAlistair CockburnJeff De Luca,Stephen PalmerDSDM konzorcijJames A.Highsmith IIIRichard StallmanScott W. AmblerRon Masticelli,Mary PoppendieckKarakteristikatehnički orijentiranaupravljanje procesomorganizacijski orijentirane;zasebna metoda za određenusvrhuorijentirana na oblikovanje iimplementacijuprilagodba funkcionalnosti sustavavremenu i resursimaprilagođavanje u svrhu ostvarenjaciljevadostupan izvorni kod; Na granicitradicionalne i agilnemodeliranje; definiranje zahtijeva;faza analize i dizajnapostizanje ušteda onako po uzoru151na (auto) industrijuEkstremno programiranje (eXtreme Programming) Životni ciklusIstraživanje(Exploration)RedovnenadopunePričePlaniranje(Planning)Priče zaidućuiteracijuPrioritetiProcjenanaporaFER \ Fertalj: Razvoj informacijskih sustavaIteracije do izdanja(Iterations to Release)StalnipregledProgramiranje u paruAnaliza DizajnPovratneinformacijeTestPlantestira.Produkcija(Productionizing)TestiranjeStalnaintegracijaSkupna bazaMaloizdanjeOdobrenjekorisnikaOdržavanje(Maintenance)NadopunjenoizdanjeSmrt(Death)Finalnoizdanje152

IstraživanjeFaze ekstremnog programiranja (1)• Korisnici bilježe svoje priče na kartice• Svaka kartica sadrži jednu mogućnost (feature) programa.• Projektni tim se upoznaje s alatima, tehnologijom i postupcima projekta.• Radi se prototip sustava za testiranje tehnologije i varijanti arhitekture• Faza istraživanja traje nekoliko tjedana do nekoliko mjeseci Planiranje• Postavlja prioritete na korisničke priče (tj. svojstva programskog rješenja)• Planira se doseg prvog malog izdanja i vrijeme za pojedinu karticu• Zatim se određuje cjelokupni vremenski raspored.• Rok za izdavanje prvog malog izdanja obično je unutar dva mjeseca.• Faza planiranja traje nekoliko dana.Faze ekstremnog programiranja (2) Iteracije do izdanja• Uključuje nekoliko iteracija sustava prije prvog izdanja.• Vremenski raspored iz faze planiranja se razlaže u više iteracija• Pojedina iteracija traje jedan do četiri tjedna.• Prva iteracija stvara verziju koja obuhvaća cijelu arhitekturu ciljanog sustava.• Klijent određuje kartice koje će se koristiti pri svakoj narednoj iteraciji.• Testovi prihvatljivosti izvode na kraju svake iteracije.• Na kraju posljednje iteracije, sustav je spreman za produkciju. Produkcija• Dodatno testiranje i provjera performansi sustava prije isporuke klijentu.• Razrješenje primjedbi te odlučivanje da li će se riješiti u tekućem izdanju.• Iteracije trajanja tri do najviše tjedan dana.• Zakašnjele nove ideje i prijedlozi se dokumentiraju a implementacija odgađa.FER \ Fertalj: Razvoj informacijskih sustava153FER \ Fertalj: Razvoj informacijskih sustava154Faze ekstremnog programiranja (3)Temeljne vrijednosti (core values) Održavanje• Nakon što je prvo izdanje pušteno u produkciju,• treba istovremeno održavati softver u primjeni i proizvoditi nove verzije• Zbog toga se brzina implementacije smanjuje• Održavanje može zahtijevati nove članove tima i promjenu strukture tima. Faza smrti je blizu kada klijent nema više novih kartica s pričama• Podrazumijeva se da sustav zadovoljava sve zahtjeve (npr. pouzdanost istabilnost).• Vrijeme u XP projektu da se konačno napiše sva korisnička dokumentacijabudući da više nema promjena na arhitekturi, dizajnu i kodu sustava.• Smrt može nastupiti i kada sustav ne ispunjava sva korisnička očekivanja, iliako postane preskup za daljnji razvoj. Komunikacija (communication)• XP zahtijeva komunikaciju u svim fazama projekta• komunikacija članova razvojnog tima, komunikacija članova s voditeljimaprojekta, komunikacija naručitelja s izvođačima (razvojnicima i voditeljima). Jednostavnost (simplicity)• Dijelovi softvera i cjelokupna arhitektura moraju u svakoj fazi biti jednostavni.• ostvaruje se kontinuiranim refaktoriranjem i minimizacijom dokumentacije Povratne informacije (feedback)• XP nalaže kontinurane povratne informacije od svih sudionika projekta• povratne informacije onemogućavaju nerazumijevanje među sudionicima Hrabrost (courage)• sposobnost provedbe teških odluka (npr. odbacivanja dijelova koda kada jeto nužno ili velikih promjena u kasnoj fazi projekta)• također, podrazumijeva međusobnu iskrenost svih članova projektnog tima Uvažavanje (respect)• razvojnici nikad neće napraviti promjene koje bi onesposobile aktualnuverziju ili vodile neispravnom testiranju ili usporile napredak ostalihFER \ Fertalj: Razvoj informacijskih sustava155FER \ Fertalj: Razvoj informacijskih sustava156

Načela (principles) Poveznica između apstraktnih temeljnih vrijednosti i prakse Ljudskost (Humanity) – kompromis interesa ljudi i organizacije Ekonomičnost (Economics) – dokaz vrijednosti za naručitelja Obostrana korist (Mutual benefit) – zadovoljstvo naručitelja Samo-sličnost (Self-similarity) – višestruko upotrebljiv kod Unaprjeđenje (Improvement) – trajno poboljšanje u iteracijama Raznolikost (Diversity) – komplementarni pojedinci Promišljanje (Reflection) – učenje na vlastitim pogreškama Tijek aktivnosti (Flow) – kontinuirani proces, ne slijed aktivnosti Prilika (Opportunity) – problemi kao mogućnost za napredak Redundancija (Redundancy) – raznolika rješenja jamstvo napretka Neuspjeh (Failure) – bolje pogriješiti nego zastati Kvaliteta (Quality) – jamstvo stabilnosti, ne perfekcija Mali koraci (Baby steps) – stalni, vidljivi napredak Prihvaćena odgovornost (Accepted Responsibility) - osobljaOsnovne XP prakse (Primary practices) Priče (korisničke priče) - Stories (User Stories)• kratki opis funkcionalnosti Tjedni ciklus (Weekly Cycle)• razvoj u tjednim ciklusima, svaki tjedan započinje sastankom izbora priča Kvartalni ciklus (Quarterly Cycle)• grublje, na dulje staze, razvoj se planira kvartalno Rezerva (Slack)• izbjegavanje obećanja koja ne mogu biti ispunjena Smještaj ekipe (Sit Together)• smještaj ekipe na isto mjesto da se poveća komunikacijaFER \ Fertalj: Razvoj informacijskih sustava157FER \ Fertalj: Razvoj informacijskih sustava158Osnovne XP prakse (2)Osnovne XP prakse (3) Cjelovitost i zajedništvo ekipe (Whole Team)• ekipa sastavljena od članova potrebne stručnosti• osjećaj pripadnosti i spremnosti na pomoć ostalim članovima Informativno radno okruženje (Informative Workspace)• pružanje osjećaja pripadnosti i predanosti projektu (posteri itd.) Energičan rad (Energised Work) Inkrementalni dizajn (Incremental Design)• dizajn kao kontinuirani proces koji se u malim koracima odvija tijekomčitavog razvoja• Refaktoriranje – uklanjanje složenosti i zalihosti programskog koda• Jednostavan dizajn – što je moguće jednostavniji (KISS) Test prije programiranja (Test-First Programming)• Testovi trebaju biti napisani prije kodiranja• programeri moraju biti odmoreni (svježi) da bi bili produktivni• smanjenje prekovremenog rada Destminutna gradnja (Ten-Minute Build)• sustav se mora moći kompilirati i testirati unutar 10 minuta Programiranje u paru (Pair Programming)• da bi mogao postići odgovarajuću povratnu informaciju (feedback)• Programeri rade u parovima, tako da jedan piše kôd, a drugi prati pisanje irevidira kôd pazeći da kod bude jasan i razumljiv. Kontinuirana integracija (Continuous Integration)• Sustav treba integrirati svaka 2 sata ili nakon većih promjenaFER \ Fertalj: Razvoj informacijskih sustava159FER \ Fertalj: Razvoj informacijskih sustava160

XP u praksi Najpoznatija, a ujedno i prva opisana upotreba XP-a• Chrysler Comprehensive Compensation System (skraćeno C3)• sustav za obračun plaća za 87.000 djelatnika Cryslera.• Razvoj je počeo u 1995. a planirano je da bude gotov do 1999. godine.• Nakon godinu dana zastoja Kent Beck je postavljen za voditelja projekta.• Prve funkcionalne verzije softvera su se pojavile godinu dana kasnije, alinedugo nakon toga projekt se prestao dalje razvijati.• Nakon kupnje Cryslera od strane tvrtke Daimler Benz projekt je definitivnoodbačen.• Tijekom svog životnog vijeka C3 je obradio samo 10.000 plaća• http://en.wikipedia.org/wiki/Chrysler_Comprehensive_Compensation_System (1.9.2007)Integracija metodaujedno primjer za rezultate faza metoda Uf, kako je početna jednostavnost postala komplicirana !FER \ Fertalj: Razvoj informacijskih sustava161Integracija RUP i XP na srednjim i malim projektima Za dosljednu primjenu• XP premali i labav – softver je preskup da bi bio planiran "ad hoc"• RUP prevelik i općenit – projekti su predinamični i nepredvidljivi Najbolje od najboljeg• XP – naglasak na kodiranju, kratkim projektima (do 1god), malim ekipama(do 10), skraćenoj dokumentaciji, ...• RUP - konfigurabilni, prilagodljivi proces, s elementima uklanjanja rizika idetaljnom dokumentacijomSnimka stanjaAktivnost RUP eXtreme ProgrammingAnaliza zahtjeva Use-Case analiza Priče (Stories)Komunikacija (Communication)Povratne informacije (Feedback)Prisutnost naručitelja (On-site customer)Analiza i dizajnClass dijagramSequence dijagramCollaboration dijagramActivity dijagramJednostavnost dizajna(Simple Design)Skice dizajna sustava (CRC skice)Implementacija Česte integracije izvršnih verzija (SmallReleases)Stalna integracija (Continuous Integration)Kolektivno vlasništvo (Collective Ownership)Prilagodbe koda (Refactoring)Programiranje u paru (Pair programming)TestiranjePlaniranje, dizajn iTestiranje komponenti (Unit Testing)implementacija testovaKontrolapromjenaChange RequestdokumentiUpravljanjeprojektomPlan iteracija(Iteration Plan)Status AssessmentdokumentPlan iteracija (Iteration Plan)FER \ Fertalj: Razvoj informacijskih sustava163FER \ Fertalj: Razvoj informacijskih sustava164

Sistem analiza i sistem dizajnKonstrukcijaAktivnost RUP eXtreme ProgrammingAnaliza zahtjeva Use-Case analiza Priče (Stories)Komunikacija (Communication)Povratne informacije (Feedback)Prisutnost naručitelja (On-site customer)Analiza i dizajnClass dijagramSequence dijagramCollaboration dijagramActivity dijagramJednostavnost dizajna (Simple Design)Skice dizajna sustava (CRC skice)Implementacija Česte integracije izvršnih verzija (Small Releases)Stalna integracija (Continuous Integration)Kolektivno vlasništvo (Collective Ownership)Prilagodbe koda (Refactoring)Programiranje u paru (Pair programming)TestiranjePlaniranje, dizajn iimplementacija testovaTestiranje komponenti(Unit Testing)KontrolapromjenaChange Request dokumentiUpravljanjeprojektomPlan iteracija(Iteration Plan)Status AssessmentPlan iteracija (Iteration Plan)AktivnostAnaliza zahtjevaAnaliza i dizajnImplementacijaTestiranjeKontrolapromjenaRUPUse-Case analizaClass dijagramSequence dijagramCollaborationdijagramActivity dijagramPlaniranje, dizajn iimplementacija testovaChange RequesteXtreme ProgrammingPriče (Stories)Komunikacija (Communication)Povratne informacije (Feedback)Prisutnost naručitelja (On-site customer)Jednostavnost dizajna(Simple Design)Skice dizajna sustava (CRC skice)Integracije izvršnih verzija (Small Releases)Stalna integracija (Continuous Integration)Kolektivno vlasništvo (Collective Ownership)Prilagodbe koda (Refactoring)Programiranje u paru (Pair programming)Testiranje komponenti (Unit Testing)UpravljanjeprojektomStatus AssessmentPlan iteracija (Iteration Plan)FER \ Fertalj: Razvoj informacijskih sustava165FER \ Fertalj: Razvoj informacijskih sustava166TranzicijaMaterijali i internet adreseAktivnostAnaliza zahtjevaAnaliza i dizajnImplementacijaTestiranjeRUPUse-Case analizaClass dijagramSequence dijagramCollaboration dijagramActivity dijagramPlaniranje, dizajn i implementacijatestovaTestovi prihvaćanja (AcceptanceTests)eXtreme ProgrammingPriče (Stories)Komunikacija (Communication)Povratne informacije (Feedback)Prisutnost naručitelja (On-site customer)Jednostavnost dizajna (Simple Design)Skice dizajna (CRC skice)Integracije izvršnih verzija (Small Releases)Stalna integracija (Continuous Integration)Kolektivno vlasništvo (Collective Ownership)Prilagodbe koda (Refactoring)Programiranje u paru (Pair programming)Testiranje komponenti (Unit Testing)Testovi prihvaćanja (Acceptance Tests) Primjeri metoda: Metode \ * Internet adrese• http://www.rspa.com/• http://www.extremeprogramming.org/• http://www.agilemodeling.com/• http://www.agilealliance.com• http://www.realsoftwaredevelopment.com/the-complete-list-of-softwaredevelopment-frameworks-processs-methods-or-philosophies/Uvođenjesustava uprodukciju(Deployment)Plan uvođenja u produkciju(Deployment Plan)Generiranje korisničkedokumentacije (UserDocumentation)Izrada plana održavanja(Support Plan)• http://www.noop.nl/2008/07/the-definitive-list-of-software-developmentmethodologies.htmlKontrolapromjenaChange Request dokumentiUpravljanje Status Assessment dokumentprojektom FER \ Fertalj: Razvoj informacijskih sustavaPlan iteracija (Iteration Plan)167FER \ Fertalj: Razvoj informacijskih sustava168

Reference IBM Rational Unified Process web site,http://www-01.ibm.com/software/awdtools/rup, [2009-01-27] Leslee Probasco, The Ten Essentials of RUP – the Essence of an EffectiveDevelopment Process, Rational Software White Paper, TP177, 9/00,ftp://ftp.software.ibm.com/software/rational/web/whitepapers/2003/TP177.pdf, [2009-01-20] Manifesto for Agile Software Development,http://www.agilemanifesto.org/, [2009-01-20] Don Wells, Extreme Programming: A gentle introduction, 2006,http://www.extremeprogramming.org , [2009-01-16] Michele Marchesi, The New XP, http://www.snip.gob.ni/Xdc/Agile/TheNewXP.pdf,[2009-01-19] OpenUP Wiki,http://epf.eclipse.org/wikis/openup/, [2009-01-27] Scott Ambler, The Agile Unified Process,http://www.ambysoft.com/unifiedprocess/agileUP.html, [2009-01-27] Gary Pollice, Using the Rational Unified Process for Small Projects: ExpandingUpon eXtreme Programming, Rational Software White Paper, TP 183, 3/01,ftp://ftp.software.ibm.com/software/rational/web/whitepapers/2003/tp183.pdf, [2009-01-10] Robert C. Martin, The Process, 1999,http://www.objectmentor.com/resources/articles/RUPvsXP.pdf, [2009-01-13]Literatura• Jacobson, Booch, Rumbaugh: The Unified Software Development Process. AddisonWesley, 1999• Agile software development mehods, review and analysis, Pekka Abrahamsson, OutiSalo & Jussi Ronkainen, 2002• Juhani Iivari, Jari Maansaari: The usage of systems development methods: are westuck to old practices?, Information and Software Technology, 1998, Linnanmaa,Finland, 1998, pp. 501-510• Manifesto for Agile Software Development, available at http://agilemanifesto.org/,Dostupno: 10.06.2008• Jack Vaughan: Agile tools for agile development, available athttp://searchsoftwarequality.techtarget.com/news/article/0,289142,sid92_gci1287345,00.html, Dostupno: 10.06.2008• Jack Vaughan, Agile tools for agile development, 2008http://searchsoftwarequality.techtarget.com/news/article/0,289142,sid92_gci1287345,00.html• Mishkin Berteig: The Seven Core Practices of Agile Work, available athttp://www.agileadvice.com/archives/2006/09/practices_of_ag.html, Dostupno:10.06.2008• Alistair Cockburn: Agile Software Development, Addison Wesley, Boston, USA, 2000• XP123 - Exploring Extreme Programming, available at http://www.xp123.com/,Dostupno: 10.06.2008• Christine M. Sigman, Adapting to Scrum: Challenges and Strategies, Intercom, 2007(http://www.stc.org/intercom/PDFs/2007/20070708_16-19.pdf)FER \ Fertalj: Razvoj informacijskih sustava169FER \ Fertalj: Razvoj informacijskih sustava170CASECASE CASE• eng. Computer Aided Software Engineering• eng. Computer Aided System Engineering CAISE• Computer Aided Information System Engineering Računalom podržano programsko/informacijsko inženjerstvo• programski sustav za pomoć pri izgradnji IS i razvoju programske opreme• uporaba alata koji podupiru neku od faza životnog ciklusa• automatizacija programske opreme (Software Automation)FER \ Fertalj: Razvoj informacijskih sustava172

CASE pomagaloCASE pomagala• programski sustav za pomoć pri izgradnji IS i razvoju programske opreme CASE pomagala podupiru (ne sva i ne uvijek!)• jednu ili više metoda informacijskog/programskog inženjerstva• samo njima svojstvenu ili neku od standardnih metodologija• mogućnost definiranja vlastite metodologije (meta-case) Često se radi o skupu integriranih alata kojim se podupire:• jedna od faza životnog ciklusa (toolkit)• životni ciklus (workbench)• cjelokupni proces (environments), uključujući potporne aktivnosti Osnovne komponente• rječnik podataka (data dictionary), meta-baza (meta-base) ili riznica(repository) za pohranu modela• sučelje za izradu dijagrama i rukovanje meta-podacima• posebni dijelovi koji vode brigu o usklađivanju promjena načinjenih narazličitim razinama raščlambe modela ili u različitim modelima.Vrste CASE pomagala Gornji CASE (Upper CASE, Front-End CASE)• Automatizacija ili podrška ranih faza - planiranje, analiza i oblikovanje• modeliranje zahtjeva• oblikovanje baza podataka, prevođenje modela u 3NF• generiranje sheme BP (SQL naredbe) Donji CASE (Lower CASE, Back-End CASE)• potpora fazama razvoja: detaljni dizajn, konstrukcija, ugradnja, održavanje• generatori programske opreme (application generator, code generator)• održavanje programske potpore (version control) i prepravke (reengineering)• alati za izradu programske dokumentacije (documentation tool)• alati za povratno inženjerstvo (reverse engineering), npr. analizatori izvornogkoda, alati za restrukturiranje koda Integrirana CASE pomagala (ICASE - Integrated CASE)• cjeloviti CASE sustavi koji pokrivaju sve faze razvoja• sadrže i dodatne module za povratno inženjerstvo, nadzor i upravljanjeizvedbom te osiguranje kvaliteteFER \ Fertalj: Razvoj informacijskih sustava173FER \ Fertalj: Razvoj informacijskih sustava174Problem selekcije alata za projektiranjeUMLmodeliranjeModeliranjeprocesaModeliranjepodatakaInženjerstvoizvornog kodaAllFusion PowerDesigner Visual Paradigm Rational Rose XDE Visiostandardni dijagrami da, uz ORM sinkronizacija ERD i Data Modeler i dadijagrama razreda Developer for VSIDEF0, IDEF3, DFD,ostaloDFD, FlowChart UML notacija ne podržavastrukturiranenotacije, nema UMLproširenjaCross FunctionalFlowchart, IDEF0,Data Flow ModelDiagramIDEF1X, IE, DM IE, IDEF1X DBVA: ERD logički i fizički UML Database ModelDiagram, besplatandodatak za ERsamo C++kružno Java, C#,VB.NETkružno, u razvojnojokoliniDeveloper: kružnopovratno inženjerstvoC++, C#Preoblikovanje programske podrškeInženjerstvobaze podatakaGeneriranjedokumentacijeNapredne idodatnemogućnostiIntegriranostalataModeler: kružno,Model Validator:jednosmjernokružnoDBVA:jednosmjernoDeveloper: kružnoRTF, HTML, TXT RTF, HTML ne HTML, Webpublishingvalidacija modela, upravljanječitanje Rational slobodni dijagrami,Data Warehouse, zahtjevima. veza s Rose modela razvoj zasnovan naData Mart, zahtjevi u MS Word,predlošcima,MS Wordmodeliranjepodrška grupnomskladišta podatakaradu, RUPnezavisni alati,zajednička riznica,nepovezanostmodelaneIntegracija srazvojnomokolinomFER \ Fertalj: Razvoj informacijskih sustavaskup alata ili jedanalat, riznica modelaEclipse, VisualStudio:NET, drugiodvojeni alati zaUML i oblikovanjepodatakaVisual Studio.NET,Eclipse, drugipaleta odvojenihalataVisual Studio.NETjednosmjernonedefiniranje vlastitenotacijejedan alatVisual Studio.NET175

Osnovni pojmoviGlavni procesi i aktivnosti Preoblikovanje programske podrške (software reengineering)• skup ispitivanja i postupaka izmjena postojećeg sustava koji rezultirajukonačnim preustrojem sustava u novi oblik• sustav čine svi programi, baze podataka, podaci i razvojna dokumentacija• moguće je mijenjati čitav sustav ili samo jedan njegov manji dio Glavni procesi i aktivnosti• zahtjevi na sustav (definicija problema, ciljeva, ograničenja, poslovnihprocesa)• projektiranje (specifikacija rješenja)• izvođenje (kodiranje, testiranje i isporuka radne verzije sustava)FER \ Fertalj: Razvoj informacijskih sustava177FER \ Fertalj: Razvoj informacijskih sustava178Inženjerstvo prema naprijed i unatragPodručja obrnutog inženjerstva Inženjerstvo prema naprijed (forward engineering)• tradicionalni postupak kod kojeg s viših razina apstrakcije prelazimo na niže slojeveprojektiranja i izvođenja• pojmu inženjerstvo se dodaje oznaka „naprijed“ samo da bismo ga kao tradicionalnipristup razlikovali od, novijeg, inženjerstva unatrag Inženjerstvo unatrag (reverse engineering) - obrnuto, reverzno, povratno• kontekst• izvorni kod je dostupan, ali je dokumentacija nepotpuna, neažurna ili je nema• izvorni kod nije dostupan i cilj je doći do njega• glavne aktivnosti• prepoznavanje dijelova sustava i njihove povezanosti, s ciljem da se identificirajukomponente sustava i dobije potpuna specifikacija• oblikovanja sustava na višim slojevima apstrakcije iz nižih slojeva, npr. izradadijagrama temeljem izvornog koda programa• ne podrazumijeva izmjene u postojećem sustavu, već se svodi na detaljno ispitivanjepostojećeg sustava s ciljem stvaranja boljeg novog sustava• postupci - ispitivanje postojeće implementacije sustava, ponovno otkrivanje dizajnasustava, dešifriranje zahtjeva ugrađenih u sustav Redokumentacija (redocumentation)• naknadno dokumentiranje postojeće programske podrške• generiranje temeljem komentara u izvornom kodu ili rječnika BP Metrička analiza• mjerenje veličine, složenosti i uvezanosti programskog koda• ocjena kvalitete implementacije, pogodnosti za održavanje, utjecaja promjena nekogdijela koda na ostatak sustava, prepoznavanje ponovno uporabljivih dijelova Restrukturiranje (restructuring)• pretvorba sustava iz jednog oblika u drugi na istom sloju apstrakcije uz očuvanoponašanje prema okolini• formatiranje izvornog koda - najjednostavniji oblik (uvlačenje, kapitalizacija, ...)• preusmjeravanje (retargeting) - prevođenje na novu konfiguraciju ili platformu• refaktoring – tehnika OO programiranja Objektifikacija (objectification)• preoblikovanje proceduralnog programa u funkcionalno ekvivalentni OO programpisan u drugom programskom jeziku ili u modernijoj varijanti istog jezika Inženjerstvo višestruke iskoristivosti (reuse engineering)• analiza prikladnih dijelova, izmjena dijelova s ciljem odvajanja, izrada funkcionalnihspecifikacija za izdvojene dijelove• pohrana specifikacija uz naknadno pretraživanje i odabirFER \ Fertalj: Razvoj informacijskih sustava179FER \ Fertalj: Razvoj informacijskih sustava180

Inženjerstvo u krug (round-trip engineering)Reference Kombinacija inženjerstvaunaprijed i unatrag Skraćeni prikaz• http://www.softdevtools.com/• http://www.enterprise-architecture.info/EA_Tools.htm Upravljanje zahtjevima• http://www.jiludwig.com/Requirements_Management_Tools.html Oblikovanje, projektiranje• http://www.idsscheer.com/en/ARIS_ARIS_Business_Performance_Edition/89359.html• http://www-306.ibm.com/software/awdtools/developer/rosexde/• http://www.eclipse.org/• http://www.objecteering.com/• http://staruml.sourceforge.net/en/• http://www.sparxsystems.com.au/• http://www.sybase.com/products/modelingdevelopment/powerdesigner• http://developer.tibco.com/business_studio/• http://www.visual-paradigm.com• http://www.visible.com/FER \ Fertalj: Razvoj informacijskih sustava181FER \ Fertalj: Razvoj informacijskih sustava182 Razvojni alatiReference• http://www.prolifics.com/panther.htm• http://www.magicsoftware.com/ Ekipni razvoj• http://www.codeplex.com/TFSGuide Generatori• http://www.codegeneration.net/• CodeChargehttp://www.yessoftware.com/products/product.php?product_id=1• Iron Speed http://www.ironspeed.com/• LLBLGen http://www.llblgen.com/defaultgeneric.aspx• MyGeneration http://www.mygenerationsoftware.com/portal/default.aspx• Sculpture http://www.codeplex.com/Sculpture• Dollard, K. 2004. Code Generation in Microsoft .NET. Apress, Berkley.• Herrington, J. 2003. Code Generation in Action. Manning, Greenwich.Reference Preoblikovanje, refaktoriranje• DevAdvantagehttp://www.anticipatingminds.com/Content/Products/devAdvantage/devAdvantage.aspx• ReSharper http://www.jetbrains.com/resharper/• dodatak RGreatEx http://www.brothersoft.com/rgreatex-resourcerefactoring-tool-69903.html• CodeIt.Right http://submain.com/download/codeit.right/ Potpora kodiranju, analiza koda, metrika• ANTS Profiler http://www.red-gate.com/products/ants_profiler/index.htm• CodeSmart http://www.axtools.com/• NDepend http://www.ndepend.com/• StyleCop http://code.msdn.microsoft.com/sourceanalysis Testiranje• http://www.csunit.org/• http://www.nunit.org/index.phpFER \ Fertalj: Razvoj informacijskih sustava183FER \ Fertalj: Razvoj informacijskih sustava184

Projekt Projekt• Projekt je vremenski određeno nastojanje da se proizvede jedinstvenproizvod, usluga ili rezultat. [PMBOK, www.pmi.org]Upravljanje projektom11/13 Vremenska određenost• Svaki projekt mora imati jasno određen početak i kraj.• Projekti mogu biti kratki ili trajati godinama, ali će svakako završiti.• Projekt završava u trenutku kada postane jasno da su ciljevi projektadostignuti ili kada se zaključi da ciljevi projekta ne mogu ili neće bitidostignuti. Jedinstvenost• Projekt se odnosi na rad na nečemu što prije nije postojalo i što se razlikujeod rezultata nastalih sličnim projektima.FER \ Fertalj: Razvoj informacijskih sustava186Rezultati projektaUpravljanje projektom Projektom mogu nastati:• Proizvod ili artefakt,• koji se može kvantitativno odrediti, a koji može biti krajnji proizvod ilisastavna komponenta.• Proizvodi su uobičajeno materijal ili roba.• Sposobnost obavljanja usluge,• kao što su poslovne funkcije potpore proizvodnje ili distribucije.• Korisni rad koji ne proizvodi opipljivi proizvod ili rezultat.• Rezultat, u vidu ishoda ili dokumenta.• Na primjer, ishod može biti integrirani sustav, revidirani proces,restrukturirana organizacija ili podučeno osoblje.• Dokumenti mogu biti pravilnici, planovi, studije, definirane procedure,specifikacije, izvješća i drugo. Upravljanje, rukovođenje projektom (Project management)• Upravljanje projektima je primjena znanja, vještina, alata i tehnika u projektnimaktivnostima da bi se ispunili projektni zahtjevi. [PMI] Upravljanje projektom uključuje• Planiranje• Utvrđivanje zahtjeva• Postavljanje jasnih i ostvarivih ciljeva• Uravnoteženje zahtjeva na kvalitetu, doseg, vrijeme i trošak,• Prilagodbu interesima i očekivanjima zainteresiranih strana – dionika(Stakeholders)• Organiziranje• Formiranje projektnog tima• Raspoređivanje obaveza• Tko, što i kada treba napraviti• Usmjeravanje• Nadgledanje, omogućavanje izvršenja• Kontroliranje• Provjera učinka i rezultataFER \ Fertalj: Razvoj informacijskih sustava187FER \ Fertalj: Razvoj informacijskih sustava188

Progresivna razrada Progresivna razrada (Progressive elaboration)• Projekt se početno razvija u osnovne korake a zatim postupno dorađuje.• Progresivna razrada podrazumijeva neprekidno poboljšavanje i detaljiziranjeplana kroz niz ponavljanja u kojima prikupljene informacije postaju svedetaljnije a procjene sve preciznije.• Na primjer, na početku projekta doseg projekta može biti okvirno postavljen,a zatim postaje sve jasniji i detaljnije opisan, sukladno produbljivanjushvaćanja o postavljenim ciljevima i očekivanim rezultatima.Slični pothvati Projekti naspram operacija• Operacije su neprekidne i mogu se ponavljati• Projekti su vremenski ograničeni i jedinstveni.• Namjera projekta je postići zadane ciljeve i završiti.• Svrha operacije je podupiranje i održanje poslovanja, čak i kada se ciljevi promijene. Programi• Program je grupa projekta organiziranih da priskrbe korist koja ne bi bila moguća dase radi o individualnim projektima.• Mnoge tvrtke imaju program menadžere koji su zaduženi za pojedinačnu isporuku(release) proizvoda na tržište ili koordinaciju više isporuka tijekom vremena.• Programi mogu uključivati i grupu akcija koje se ciklički ponavljaju, npr.:• izrada godišnjeg plana proizvodnje• nastavni plan i program• nabavka opreme i uredskog materijala Podprojekti• Projekti se često dijele na podprojekte koji su upravljiviji, npr.:• provedba jedne faze životnog ciklusa, primjerice dizajn Web stranica• izgradnja podsustava, primjerice CRM (custumer relationship manager)• Podprojekti se često dodjeljuju drugoj funkcionalnoj jedinici ili vanjskoj organizaciji.FER \ Fertalj: Razvoj informacijskih sustava189FER \ Fertalj: Razvoj informacijskih sustava190Procesi projektaPodručja upravljanja projektom• Grupa procesa započimanja (Initiating Process Group) – definira i odobrava projekt ili fazuprojekta.• Grupa procesa planiranja (Planning Process Group) – definira i istančava svrhu, planira smjer iakcije za postizanje cilja i dosega.• Grupa izvršnih procesa (Executing Process Group) – koordinira ljudske i druge resurse u svrhuprovedbe plana• Grupa upravljačkih procesa (Monitoring and Controlling Group) – mjeri i prati napredak radiuočavanja odstupanja od plana s ciljem poduzimanja korektivnih akcija• Grupa završnih procesa (Closing Process Group) – formalizira prihvaćanje proizvoda, usluge ilirezultata i dovodi do završetka projekta ili faze projekta.Razina aktivnostiProcesinicjalizacijeProcesplaniranjaProcesizvršavanjaKontrolniprocesZavršni proces• Koordinacija projekta (Project Integration Management)• Upravljanje dosegom projekta (Project Scope Management)• Upravljanje vremenskim rasporedom projekta (Project Time Management)• Upravljanje troškovima projekta (Project Cost Management)• Upravljanje kvalitetom projekta (Project Quality Management)• Upravljanje ljudskim resursima projekta (Project Human Resource Mgt.)• Upravljanje razmjenom informacija u projektu (Project Communications Mgt.)• Upravljanje rizicima projekta (Project Risk Management)• Upravljanje nabavom za potrebe projekta (Project Procurement Management)Početak fazeFER \ Fertalj: Razvoj informacijskih sustavaVrijemeKraj faze191FER \ Fertalj: Razvoj informacijskih sustava192

Koordinacija projektaUpravljanje dosegom projekta Koordinacija projekta (Project Integration Management)• Razvoj povelje projekta (Develop Project Charter) Upravljanje dosegom projekta (Project Scope Management)• Planiranje dosega (Scope Planning)• Razvoj početne izjave o dosegu projekta (Develop Preliminary ProjectScope Statement)• Razvoj plana upravljanja projektom (Develop Project Management Plan)• Usmjeravanje i upravljanje izvršenja projekta (Direct and Manage ProjectExecution)• Praćenje i nadzor rada na projektu (Monitor and Control Project Work)• Koordinirani nadzor nad promjenama (Integrated Change Control)• Definiranje dosega (Scope Definition)• Strukturiranje raspodjele posla (Create Work Breakdown Structure)• Verifikacija dosega (Scope Verification)• Nadzor nad dosegom (Scope Control)• Zatvaranje projekta (Close Project)FER \ Fertalj: Razvoj informacijskih sustava193FER \ Fertalj: Razvoj informacijskih sustava194Upravljanje vremenskim rasporedom projektaUpravljanje troškovima i kvalitetom projekta Upravljanje vremenskim rasporedom projekta (Project TimeManagement)• Definiranje aktivnosti (Activity Definition)• Određivanje poretka aktivnosti (Activity Sequencing)• Procjena resursa aktivnosti (Activity Resource Estimating)• Procjena trajanja aktivnosti (Activity Duration Estimating)• Izrada vremenskog rasporeda (Schedule Development)• Nadzor ispunjenja rokova (Schedule Control) Upravljanje troškovima projekta (Project Cost Management)• Procjena troškova (Cost Estimating)• Upravljanje proračunom (Cost Budeting)• Nadzor nad troškovima (Cost Control) Upravljanje kvalitetom projekta (Project Quality Management)• Planiranje kvalitete (Quality Planning)• Osiguravanje kvalitete (Perform Quality Assurance)• Nadzor nad kvalitetom (Perform Quality Control)FER \ Fertalj: Razvoj informacijskih sustava195FER \ Fertalj: Razvoj informacijskih sustava196

Upravljanje resursima i informacijamaUpravljanje rizicima, upravljanje nabavom Upravljanje ljudskim resursima projekta (Project Human ResourceManagement)• Planiranje ljudskih resursa (Human Resource Planning)• Prikupljanje projektne ekipe (Acquire Project Team)• Razvoj projektne ekipe (Develop Project Team)• Rukovođenje projektnom ekipom (Manage Project Team) Upravljanje razmjenom informacija u projektu (ProjectCommunications Management)• Planiranje komunikacije (Communications Planning)• Distribuiranje informacija (Information Distribution)• Izvješćivanje o provedbi (Performance Reporting)• Koordiniranje zainteresiranih strana (Manage Stakeholders) Upravljanje rizicima projekta (Project Risk Management)• Planiranje upravljanja rizicima (Risk Management Planning)• Prepoznavanje rizika (Risk Identification)• Kvalitativna analiza rizika (Qualitative Risk Analysis)• Kvantitativna analiza rizika (Quantitative Risk Analysis)• Plan ublažavanja rizika (Risk Response Planning)• Praćenje i nadzor rizika (Risk Monitoring and Control) Upravljanje nabavom za potrebe projekta (Project ProcurementManagement)• Planiranje kupovine i nabavke (Plan Purchase and Acquisitions)• Planiranje ugovaranja (Plan Contracting)• Prikupljanje ponuda (Request Seller Responses)• Odabir dobavljača (Select Sellers)• Administriranje ugovora (Contract Administration)• Zatvaranje ugovora (Contract Closure)FER \ Fertalj: Razvoj informacijskih sustava197FER \ Fertalj: Razvoj informacijskih sustava198Generički modeli organizacijeOrganizacija projekta Funkcionalna organizacija• osoblje organizirano po funkcionalnim odgovornostima• pojedina funkcija može podupirati više različitih projekata• prednosti: potpomaže specijalizaciju (povećanje broja specijalista)• nedostatci: smanjuje osjećaj pripadnosti projektu, tj. koheziju projekta Projektna organizacija• osoblje organizirano unutar/oko projekta• prednosti: brže odlučivanje, minimizira potrebno sučelje između članova,potiče identifikaciju osoblja s projektom• nedostatci: prikladna za male projekte, minimalna raspodjela ekspertize Matrična organizacija• hibrid projektne i funkcionalne strukture• u osnovi funkcionalna, osoblje izmiješano u različitim projektima• prednosti:• projektna komponenta pogoduje uspješnosti projekta• funkcionalna komponenta pogoduje povećanju specijalizacije• nedostatak: mogući sukob interesaFER \ Fertalj: Razvoj informacijskih sustava200

Funkcionalna organizacijaProjektna organizacija Klasična funkcionalnaorganizacija je ona u kojojsvaki zaposlenik imaneposredno nadređenog. Funkcionalne organizacijeimaju projekte, ali su dosezinjihovog djelovanja ograničenipodručjem rada funkcionalnecjeline. Na primjer, inženjerski odjel jeneovisan o marketinškomodjelu. Informacije kolaju hijerarhijomorganizacije.Funkcionalni ManagerOsobljeGlavni izvršniFunkcionalni ManagerOsobljeFunkcionalni ManagerOsobljeKoordinacijaprojektom Članovi projektnog tima pripadajuistoj organizacijskoj cjelini. Voditelji projekata imaju relativnoveliku neovisnost.KoordinacijaProjekt ManagerGlavni izvršniProjekt ManagerProjekt ManagerOsobljeOsobljeOsobljeOsobljeOsobljeOsobljetamnije kućice predstavljaju osobe uključene u aktivnosti projektaFER \ Fertalj: Razvoj informacijskih sustava201FER \ Fertalj: Razvoj informacijskih sustava202Varijante matrične organizacijeJaka matrična i kompozitna organizacija Slaba matrična• voditelj više koordinira nego upravlja Balansirana matrična• voditelj upravlja ali nema punuautonomiju nad resursima iproračunom Jaka matrična• postoji stalno zaposleni upraviteljprojekta s punom autonomijom iprateće administrativno osoblje Kompozitna organizacija• U osnovi funkcionalna organizacijaformira posebne ekipe za kritičneprojekteGlavni izvršniGlavni izvršniGlavni izvršniGlavni izvršniFunkcionalni ManagerFunkcionalni ManagerFunkcionalni ManagerFunkcionalni ManagerFunkcionalni ManagerFunkcionalni ManagerFunkcionalni ManagerFunkcionalni ManagerFunkcionalni ManagerManager ProjektnihManageraFunkcionalni ManagerFunkcionalni ManagerFunkcionalni ManagerManager ProjektnihManageraOsobljeOsobljeOsobljeOsobljeOsobljeOsobljeOsobljeOsobljeOsobljeProjekt ManagerOsobljeOsobljeOsobljeProjekt ManagerOsobljeOsobljeOsobljeKoordinacijaprojektomOsobljeOsobljeOsobljeKoordinacijaprojektomOsobljeOsobljeOsobljeProjekt ManagerOsobljeOsobljeOsobljeProjekt ManagerOsobljeOsobljeOsobljeProjekt ManagerOsobljeOsobljeOsobljeProjekt ManagerOsobljeOsobljeOsobljeProjekt managerOsobljeOsobljeFER \ Fertalj: Razvoj informacijskih sustava203FER \ Fertalj: Razvoj informacijskih sustava204

Utjecaj organizacije na projektEkipni radFER \ Fertalj: Razvoj informacijskih sustava205 Ekipni rad (teamwork)Organizacija i ekipni rad• Ekipa je "samoupravljačka" jedinica, koja posluje u duhu suradnje svojihčlanova, njihove koordinacije i njima unaprijed poznatih procedura.• Prednosti:• kvalitetnije donošenje odluka – "ne treba nam soliti pamet"• motivacija članova – "zajedno smo jači"• inovativnost – "dvoje zna više nego jedan, …"• Sinergija• 2+2=5 ?Razvoj ekipe Razvoj ekipe (Forming, Storming, Norming, Performing)• Formiranje – ljubaznost, nesklonost iznošenju stavova, prepuštanje vođenju• "Jurišanje" – nesloga, sukob osobnosti, grupašenje/strančarstvo,pomanjkanje kvalitetne komunikacije, nesposobnost dogovaranja• Normiranje – uviđanje dobrih strana zajedničkog rada, uvažavanje• Predstavljanje, djelovanje – povezivanje u učinkovitu operativnu grupuGroupeffectivenessFormingPerformingStormingNormingGroup effortFER \ Fertalj: Razvoj informacijskih sustava207FER \ Fertalj: Razvoj informacijskih sustava208

Modeli ekipa (1/4) Ekipa s glavnim programerom (Chief Programmer Team) - klasična• glavni programer (chief programmer) utjelovljuje znanje i odlučivanje ekipe• mora istovremeno biti dobar (vrhunski) programer i voditelj• u poboljšanoj (revidiranoj) organizaciji ima ulogu voditelja ekipe• rezervni programer (backup programmer)• služi kao zamjena za nekog od mlađih (junior) programera• u poboljšanoj (revidiranoj) organizaciji ima ulogu pomoćnika voditeljaAdministratorGlavniprogramer(voditelj)Rezervniprogramer(pomoćnik)Modeli ekipa (2/4) Moderna organizacija ekipe (4GL ekipa)• voditelj projekta (project leader) – viši sistem analitičar• suradnja s korisnikom (user liason) – poslovni analitičar• konceptualno i logičko oblikovanje – sistem analitičar• isporuka sustava/aplikacija – poslovni analitičar• nabava i pogon opreme – sistem inženjer za računala• mrežni servisi – sistem inženjer za komunikacije• programsko inženjerstvo – programer-analitičar• izrada dokumentacije – urednik/pisac (editor / technical writer)• potporno osoblje: administrativni koordinator, tehničari, činovnici Neke stvarne organizacije koriste gornju podjelu za opis radnihmjesta.ProgramerFER \ Fertalj: Razvoj informacijskih sustava209FER \ Fertalj: Razvoj informacijskih sustava210Modeli ekipa (3/4)Modeli ekipa (4/4) XP ekipa• Razvojni inženjer• Razvojni inženjeri pišu testove i restrukturiraju programski kod• Klijent, korisnik• Klijent piše korisničke priče i piše testove zadovoljavanja funkcionalnosti• Odlučuje redoslijed i prioritete implementacije• Testeri• Testeri pomažu klijentima pisati testove zadovoljavanja funkcionalnosti.• Redovito izvode te testove, objavljuju rezultate testiranja i održavaju alate zatestiranje.• „Pratilac“ (tracker)• Vraća povratnu informaciju unutar XP projekta.• Prati procjene ekipe (npr. procjena utrošenog vremena) ocjenjuje njihovu točnost• Prati napredak svake iteracije i procjenjuje uspješnost, predlaže promjene• Trener• Trener je osoba zadužena za XP proces u cjelini, koja vodi ekipu kroz proces.• Treba dobro poznavati cjelokupni XP• Savjetnik• Savjetnik je vanjski član koji posjeduje specifično tehničko znanje koje je potrebnoza projekt.• Upravitelj (Veliki šef)• Upravitelj donosi odluke, komunicira s članovima, prepoznaje teškoće, uvodirješenja. Elastični model ekipe• upravitelj ekipe – upravljanje osobljem (plaće, režije)• voditelj ekipe – upravljanje razvojem (organizacija posla)• projektant (analitičar-programer) – analiza, oblikovanje i izvedba• programer (programer aplikacija) – kodiranje, testiranje• administrator baze podataka – administriranje baze podataka• sistem inženjer(i) – održavanje mreže i računala Sastav ekipe odgovara poslovima koje treba obaviti.• Raspodjela uloga konkretnim članovima, kao i broj članova pojedinekategorije ovise o konkretnom projektu i raspoloživosti djelatnika.• Na primjer:• ulogu upravitelja ekipe i voditelja ekipe može imati ista osoba• ekipa može imati više programera• uloga administratora BP i sistem inženjera može se dodijeliti istoj osobi Ovakav model ekipe može se primijeniti bez obzira na mogućerazličitu sistematizaciju radnih mjesta u nekoj organizaciji.FER \ Fertalj: Razvoj informacijskih sustava211FER \ Fertalj: Razvoj informacijskih sustava212

SkunkworksOstali modeli ekipa• Skunkworks projekt okuplja grupu kreativnih osoba i postavlja ih u okolinugdje će biti slobodni od utjecaja birokracije u pripadnoj organizaciji teprepušta toj grupi da po vlastitom nahođenju razvija produkt i/ili inovacije.• Menadžment tretira ekipu kao crnu kutiju – ne želi znati detalje posla, želisamo da se posao obavi• Tim ima slobodu da se organizira onako kako misli da je najbolje za projekt.• Prednosti: sjećaj privrženosti projektu, produktivnost, motivacijski učinci• Nedostatci: nedovoljan uvid u napredak projekta Tim orijentiran na funkcionalnost (feature team)• Osoblje odgovorno za razvoj, kvalitetu, dokumentaciju i marketingorganizirano je hijerarhijski prema funkciji (npr. hijerarhija razvojnika)• Sloj iznad tradicionalne strukture nalaze se timovi koji iz svake od prethodnonavedenih grupa dobivaju jednog ili više članova, a svaki tim imaodgovornost za jednu od funkcionalnosti proizvoda.• Za ovakvu ekipu kaže se da ima balansiranu strukturu Spasilački timOstali modeli ekipa• Spasilački tim usredotočen je na rješenje specifičnog problema kod kojeg jepotrebna hitna intervencija.• Članovi ovakve ekipe su specijalisti za rad sa specifičnim alatima uodređenom okruženju ili na posebnoj platformi.• Primjer: ekipa koja intervenira prilikom pada telefonske centrale. Tim specijalaca (SWAT)• Zasniva se na modelu vojnih ili policijskih specijalnih jedinica• Članovi imaju ogromno iskustvo u radu s određenim alatom ili paradigmomte im se prepušta rješavanje odgovarajućih problema.• Članovi su obično stalni i naviknuti raditi zajedno te svaki ima dobrodefiniranu ulogu.FER \ Fertalj: Razvoj informacijskih sustava213FER \ Fertalj: Razvoj informacijskih sustava214Ostali modeli ekipaVrste projekata i prikladne strukture ekipa Tim profesionalnih atleta (professional athletic team)• Zasniva se na modelu sportskih ekipa• Članovi su jednako važni ako ne i važniji od voditelja• Voditelj postoji da bi uklanjao prepreke i omogućio učinkovit rad• Članovi imaju strogo specijalizirane uloge i od eksperta na jednom područjune može se očekivati da se bavi drugim područjem. Kazališni tim• Glavnu ulogu ima režiser, koji prema viziji projekta dodjeljuje članovimazadatke i odgovornosti za pojedina područja.• Članovi tima mogu oblikovati svoje uloge i svoje dijelove projekta premavlastitom nahođenju, ali se njihove ideje moraju poklapati s vizijom.• Uloge se pridjeljuju na temelju "audicije".• Nakon što su podijeljene ne mogu se mijenjati.DominantnaznačajkaTipičanprimjerNaglasak uprocesuPrilkadnimodeli razvojaKriteriji zaodabir članovaPrikladnimodeli timovaRješavanjeproblemaKreativnostTaktičko izvršavanjePovjerenje Autonomija Jasnoća zadatakaKorektivnoodržavanje naaktivnim sustavimaFokusiranje naproblemeKodiraj i popravi(engl. code-and-fix),spiralaInteligencija,suradnja,razmišljanje,osjetljivost, integritetPoslovni tim, timspecijalaca,spasilački timRazvoj novog produktaIstraživanje novihmogućnosti i alternativaSpirala, evolucijskoprototipiranje,evolucijska isporuka,dizajn po rasporedu,dizajn po alatuKreativnost, neovisnorazmišljanje, snažnamotivacija, ustrajnostPoslovni tim, tim sglavnim programerom,skunkworks tim,kazališni tim, feature timRazvoj nadogradnje produktaDobro fokusirani zadaci sa jasnimulogama, dobro je poznat kriterijuspjeha ili neuspjehaVodopad, modificirani vodopad,spirala, dizajn po rasporedu, dizajn poalatuOdanost, predanost, orjentacija naakcije, osjećaj za hitnost rješavanjaproblemaPoslovni tim, tim s glavnimprogramerom, tim specijalaca, featuretim, tim profesionalnih atletaFER \ Fertalj: Razvoj informacijskih sustava215FER \ Fertalj: Razvoj informacijskih sustava216

Organizacija velikih projekata Upravitelj ili voditelj projekta,(project manager, project leader)• upravlja projektom• posao obavlja više ekipa• nadređen voditeljima / upraviteljimaekipa Ekipa može imati i dva voditelja Upravitelj ekipe (team manager)• planiranje, upravljanje i nadzor,rukovođenje ostalim članovima ekipe Voditelj ekipe (team leader)• tehnički aspekte aktivnosti koje seodnose na izradu i/ili uvođenjeaplikacija/podsustava ISvoditelj projekta(project leader)voditelj ekipe(team leader)upravitelj ekipe(team manager)članoviekipeKarakteristike dobrih ekipa Zajednička, inspirirajuća vizija ili cilj• Cilj koji se postavlja mora biti inspirirajući, a posao izazovan. Snažan identitet tima i osjećaj pripadnosti timu• Uspjeh - samopouzdanje – povećani angažman – produktivnost – elitizam. Struktura orijentirana na povećanje produktivnosti (zarade)• Jasne uloge, dobra komunikacija, odluke na temelju činjenica, objektivansustav nagrađivanja. Kompetentni članovi• Tehničke kompetencije (metodologije, platforme, programski jezici…),angažman i doprinos projektu, komunikacijske sposobnosti. Predanost timu i organizaciji• poticaji: vizija, izazov, identitet tima ili karizmatični vođa• predanost je moguća samo ako je osoba rasterećena problema u radnojokolini (radna atmosfera, financijska stabilnost)FER \ Fertalj: Razvoj informacijskih sustava217FER \ Fertalj: Razvoj informacijskih sustava218Karakteristike dobrih ekipa (nastavak)Karakteristike dobrog voditelja Međusobno povjerenje i međuzavisnost članova tima• iskrenost, otvorenost, dosljednost i uvažavanje Učinkovita komunikacija Osnaživanje (empowerment) - osjećaj autonomije i ovlaštenja• mogućnost poduzimanja akcija koje ekipa smatra potrebnim Mali broj članova• pravilo 7±2 – četiri osobe nisu dovoljne za stvaranje grupnog identiteta,deset i više je teško koordinirati Uživanje u poslu• članovi dobrih timova vole biti produktivni, a ako rade posao koji vole,napravit će još više posla• može se povećati uz (ograničenu) zabavu i humor Voditelj mora zastupati interese organizacije i interese članova tima. Mogućnost nagrađivanja i kažnjavanja članova tima• Može provoditi direktno ili indirektno preko viših razina upravljanja.• Voditelj mora biti podržan u provođenju svojih ovlasti jer inače gubi autoritet. Objektivnost• Dobar voditelj trudi se da dobro procijeni količinu i kvalitetu posla koji obavlja pojediničlan tima i shodno tome se odnosi prema tom članu.• Dobar voditelj ima jednaka mjerila za sve članove tima. Mora imati dovoljno tehničkog znanja da može pratiti razvoj projekta.• Voditelj mora imati dovoljno znanja da može shvatiti tehničke probleme te dobroprocijeniti vrijeme potrebno za dovršenje nekog posla. Preuzimanje odgovornosti.• Voditelj mora imati autoritet i odgovornost da prekine raspravu i donese odluku kojusmatra najboljom, pa makar ponekad ta odluka bila kriva. Brzo i efikasno rješavati problematične situacije, naročito sproblematičnim osobljem.• Toleriranje problematičnog člana ruši motivaciju ostalih članova.• Jedan od načina može biti da prepusti timu da riješi problem problematičnog člana.FER \ Fertalj: Razvoj informacijskih sustava219FER \ Fertalj: Razvoj informacijskih sustava220

Smjernice za izgradnju dobrih ekipa [Larson i LaFasto]Raspodjela uspjeha Voditelj• Izbjegavati kompromitiranje ciljaekipe "političkim" pitanjima• Pokazivati osobnu predanostzajedničkom cilju• Ne smije opterećivati ciljeveprevelikim brojem prioriteta• Biti pošten i objektivan prema svimčlanovima tima• Suočavati se s problemima vezanimuz slabije performanse pojedinihčlanova• Biti otvoren prema novim idejama iinformacijama članova Članovi• Pokazati realistično poznavanjesvoje uloge i odgovornosti• Donositi objektivne odluke natemelju stvarnih činjenica• Surađivati s drugim članovima• Osobni cilj podrediti cilju ekipe• Uložiti u posao onoliko truda koliko jepotrebno da se ostvari cilj• Dijeliti informacije i ideje s ostalimčlanovima.• Pomagati drugim članovima timakada je to potrebno• Podržavati i stajati iza odluka ekipe• Konstruktivno odgovarati nainformaciju drugih članova Kriteriji za procjenu doprinosa članova• uloženi trud (vrijeme)• rezultati rada (korisnost, kvaliteta proizvoda i zadovoljstvo korisnika)• objektivna težina posla (vrsta, uvjeti, intenzitet i trajanje)• pristup radu (zalaganje, samoinicijativa, kooperativnost, odgovornost)• sposobnost (svestranost, samostalnost) Stimuliranje, nagrađivanje i trajno usavršavanje• Pretplata na stručne časopise, kupnja stručnih knjiga.• Sudjelovanje na prezentacijama informatičke opreme i sajmovima, s ciljempraćenja stanja i trendova IT.• Sudjelovanje na stručnim konferencijama, s ciljem praćenja razvoja struke.Može se uvjetovati pisanjem stručnih radova vezanih uz projekte i probleme.• Stimulacija kroz formalnu izobrazbu (dodiplomski, poslijediplomski studij)kao uvjet ostanka u tvrtki u određenom razdoblju.• Pohađanje stručnih tečajeva, radionica ili tečajeva iz engleskog jezika.FER \ Fertalj: Razvoj informacijskih sustava221FER \ Fertalj: Razvoj informacijskih sustava222Neki kriteriji vrednovanja članovaElementi upravljanja projektomFER \ Fertalj: Razvoj informacijskih sustava223

Upravljanje projektom Upravljanje projektom (Project management)• “plan, staff, organize, schedule, direct, control”• Proces organiziranja, planiranja, upravljanja i nadzora razvoja sustava kojimće se postići prava funkcionalnost, na vrijeme i uz minimalne troškove.• Uključuje različite aspekte:• plan – Koje aktivnosti i u kojem vremenskom razdoblju treba obaviti?• sredstva/resursi – Koji su kadrovi (osoblje) i oprema potrebni?• organizacija – Koji je odnos pojedinih resursa?• raspored – Koji je redoslijed aktivnosti?• upravljanje – Kako usmjeriti i motivirati izvođače (ekipu)?• nadzor – Poštuje li se plan?• Elementi plana• Veličina projekta: funkcijske točke, broj programskih redaka• Napor izrade: čovjek-mjeseci• Vrijeme izrade: mjeseci Izgradnja IS je posao koji se, unatoč posebnostima, obavlja kaoneki drugi inženjerski poslovi, u planiranom vremenu i s planiranimresursima.Upravljanje projektom Planiranje projekta (planning)• odrediti doseg, vremenski raspored i financijska sredstva• identificirati pokroviteljstvo (sponsorship) kao jamstvo provedbe• izabrati upravitelja/voditelja projekta• odabrati alate za upravljanje projektom• pokrenuti projekt Planiranje vremena, izrada rasporeda (scheduling)• određivanje aktivnosti• procjena i pridjeljivanje sredstava potrebnih za pojedinu aktivnost• procjena trajanja pojedine aktivnosti• određivanje zavisnosti između aktivnosti• izrada vremenskog rasporeda za projekt Upravljanje, nadzor (controlling)• određivanje postupka izvještavanja o napretku projekta• praćenje napretka redovitim revizijama• preraspodjela sredstava i aktivnosti sukladno događajima• ažuriranje vremenskog rasporedaFER \ Fertalj: Razvoj informacijskih sustava225FER \ Fertalj: Razvoj informacijskih sustava226Planiranje projekataPlaniranje projekta Zašto planirati? Izrada plana• Ako nešto može poći krivo, poći će krivo – u najgore vrijeme i na najgoremmjestu (Murphyjev zakon)• Murphy je bio optimist (Grimmov korolar) Što je plan (a što nije)• plan ne predstavlja izvjesnost ili nešto što će se zacijelo dogoditi• plan je naša najbolja procjena, zasnovana na pretpostavkama i iskustvu• elementi plana: aktivnosti, ključni događaji (milestones), resursi (sredstva),troškovi Programerski paradoks (Brooks, 1982)• Nakon što je odgovarajući broj osoba pridružen nekom zadatku, dodavanjeosoblja usporava razvoj, umjesto da ga ubrza. Složeni projekti zahtijevaju velike ekipe• Najbolja strategija je podijeliti projekt u niz manjih projekata (podprojekata)koji se mogu nezavisno obaviti. Neuspješno planiranje = planiranje neuspjeha.• utvrditi ključne aktivnosti i događaje• odrediti vremenski redoslijed aktivnosti i događaja• utvrditi potrebna sredstva• pripisati/racionalizirati pripadne troškove• povezati pojedine pod-projekte/poslove u glavni projekt• iterativno razraditi plan• revidirati plan sukladno postojećem iskustvu/saznanjima Metode namijenjene upravljanju projektima• PRINCE (PRojects IN Controlled Environments)• strukturirana metoda za upravljanje projektom• definiranje organizacijske strukture projekta• definiranje strukture i sadržaja plana projekta• definira skup provjera i izvješća koji se koriste za nadzor provedbe• COCOMO• SUMFER \ Fertalj: Razvoj informacijskih sustava227FER \ Fertalj: Razvoj informacijskih sustava228

Praćenje napretka (izvršenja)Elementi projektne evidencijeZadatak Upravljanje podrazumijeva stalninadzor (controlling)• postavljanje kontrolnih točki• praćenje napretka - evidencija radnihsati, Tracking Gantt• preraspodjela sredstava i aktivnostisukladno događajima• ažuriranje vremenskog rasporedaIzvršiteljiPlaniranipočetakPlaniranizavršetakPrioritetPlanirano Stvarnotrajanje trajanjeD1 planprojektaaČlanekipeStatus% ispunjenjaP1prilagodbaplanaP2praćenjenapredovanjaevidencijaD2 radnihsatiStvarnizavršetakbVoditeljprojektaKašnjenje KomentarUlogaKratUloga: NOT NULLNazUloga:UlogaOsobeRbrUlogaOsobe:KratProjekt: NOT NULLOsoba: NOT NULLKratUloga: NOT NULLProjektKratProjekt: NOT NULLNazProjekt:KratPartner: NOT NULLSifProjekt:OznVrProjekt:OpisProjekt:KratRacun:URLprojekt:JavnoProjekt: NOT NULLAktivan: NOT NULLPartnerKratPartner: NOT NULLNazPartner:TipPartner: NOT NULLMBR:Email:URL:OpisPartner:PripadnostOsoba: NOT NULLKratPartner: NOT NULLPosaoRbrPosao:Osoba: NOT NULLDatPosao: NOT NULLKratProjekt: NOT NULLKratPosao: NOT NULLSati: NOT NULLOpisPosao:RbrZadatak:CijenaSata: NOT NULLrbr_posao:StatZadatakOznStatZadatak: NOT NULLNazStatZadatak:Aktivan: NOT NULLVrstaZadatkaVrstaZadatak: NOT NULLVrstaPoslaKratPosao: NOT NULLNazPosao:OsobaOsoba: NOT NULLOznStatOsoba:Password:Rodjen:Zanimanje:Zvanje:SifDjelatnika:SifZnanstvenika:ZadatakRbrZadatak:KratProjekt:NazZadatak: NOT NULLVrstaZadatak:Nositelj:DatZadatak:RokZadatak:Prioritet:OznStatZadatak:DatStatZadatak:OpisZadatak:PlanPoc:PlanZav:StvarPoc:StvarZav:PlanTraj:StvarTraj:VrijZadatak:OznValuta:RbrDokument:LogAzur:DatAzur:FER \ Fertalj: Razvoj informacijskih sustava229FER \ Fertalj: Razvoj informacijskih sustava230Nadzor napretkaKolaboracija među članovima Komunikacija• verbalna: brzo slušaj i misli - sporo i jasno govori, bilježi izrečeno• pisana: sadržaj, forma (predlošci), učestalost• elektronička: E-mail, Chat, News• obavješćivanje: pismenim putem, elektroničkom poštom (CC, BCC)• pohrana informacija: mrežno kazalo, FTP kazalo, web poslužitelj• organizacija kazala: Admin, Materijali, Projekt, Backup, Tmp, itd.FER \ Fertalj: Razvoj informacijskih sustava231FER \ Fertalj: Razvoj informacijskih sustava232

Pomagala za podršku grupnom raduPreporuke verbalnu komunikaciju Konzultacije i razmjena informacija• zajedničko dnevno druženje svih članova ekipe• dinamičko rješavanje detalja konkretnih praktičnih problema• dnevno po 5 min., na početku radnog dana ili prije/poslije pauze• po potrebi se mogu sazvati i izvan dogovorenih termina Sastanci• upoznavanje s trenutnim stanjem, realizacijom plana i daljnjim poslovima• razmatranje problema, predlaganje načina i redoslijeda njihovog rješavanja• kratki, jednom tjedno, unaprijed dogovorenog dana, najbolje na početkutjedna• kontrolni, jednom mjesečno ili na kraju faze• po potrebi se mogu sazvati i izvan dogovorenih termina• sastanci moraju biti pripremljeni - mjesto, vrijeme, teme, sudionici• izbjegavati raspravu o općepoznatim ili nevažnim stvarima• treba ih prekinuti u trenutku kada se pretvore u razgovor o temama koje sene odnose na posaoFER \ Fertalj: Razvoj informacijskih sustava233FER \ Fertalj: Razvoj informacijskih sustava234Neke tehnikeUpravljanje vremenom (time management) Tehnike za poboljšanje rada pravilno raspoređivanje poslova:• Brainstorming – iznošenje ideja• točnom procjenom što i kada treba napraviti• Izbjegavanje "jedinih" rješenja – traženje alternativa• podjelom posla u pod-poslove• Bilježenje odluka – zapisivanje da bi se izbjegla pogrešna tumačenja• Konstruktivne povratne informacije – kritiziranje postupaka, a ne osoba• Razumijevanje neuspjeha – analiza i poboljšanje svega što nije dobro• Raspodjela moći i odgovornosti – ravnopravnost, izbjegavanje hijerarhije• izradom izvješća o napredovanju i gotovosti izbjegavanje obavljanja tuđih poslova• "mogu to i sam"• "mogu to brže"• "teže mi je objasniti, nego napraviti" neprimjeren utrošak vremena (razbacivanje vremenom)• druženje – telefonski razgovori, neproduktivna konverzacija• započimanje – problem "prebacivanja" s jednog posla na drugi ili "promjenebrzine" → pokušati s manje poslova i grupirati slične poslove• ugodni poslovi → izbjegavati produljenje rada na poslovima "za gušt"• neugodni poslovi → izbjegavati odugovlačenje neugodnih ili teških poslovaFER \ Fertalj: Razvoj informacijskih sustava235FER \ Fertalj: Razvoj informacijskih sustava236

Planiranje poslovaPreporuke za planiranje poslova• planovi moraju biti ažurni, tj. prilagođeni stvarnom stanju• izbjegavati detaljno planiranje poslova koji slijede u daljoj budućnosti – takveje dovoljno predvidjeti i najaviti, a pažnju usmjeriti na probleme koji setrenutno rješavaju• planovi trebaju što kraći, kako se vrijeme ne bi trošilo na detaljiziranje kojezbog moguće promjene stanja ionako neće biti istinito• konkretno razdoblje za koje se radi plan može varirati u ovisnosti o veličiniprojekta• načelno je dovoljan jedan plan (i pregled realizacije) mjesečno, s tim dauključuje raspored tjednih aktivnosti• poslove i zadatke treba uravnoteženo raspodijeliti• više pažnje treba posvetiti članovima koji zaostaju u izvršenju plana ilirješavaju složeniji problem u odnosu na ostale članove• po potrebi treba prerasporediti postojeće posloveDokumentiranje projekta Povelja projekta (Project Charter)• Dokument kojim pokretač projekta ilisponzor formalno odobravapostojanje projekta i kojim ovlašćujevoditelja za primjenu organizacijskihresursa u provedbi projekta. Plan upravljanja softverskimprojektom (Software ProjectManagement Plan)• IEEE Standard for Software ProjectManagement Plans 1058-1998 Primjeri• ProjectCharter• ProjectPlan1. Introduction1.1 Project Overview1.2 Project Deliverables1.3 Evolution of the Software Project Management Plan1.4 Reference Materials1.5 Definitions and Acronyms2. Project Organization2.1 Process Model2.2 Organizational Structure2.3 Organizational Boundaries and Interfaces2.4 Project Responsibilities3. Managerial Process3.1 Management Objectives and Priorities3.2 Assumptions, Dependencies, and Constraints3.3 Risk Management3.4 Monitoring and Controlling Mechanisms3.5 Staffing Plan4. Technical Process4.1 Methods, Tools, and Techniques4.2 Software Documentation4.3 Project Support Functions5. Work Packages, Schedule, and Budget5.1 Work Packages5.2 Dependencies5.3 Resource Requirements5.4 Budget and Resource Allocation5.5 Schedule6. Additional Components7. Index8. AppendicesFER \ Fertalj: Razvoj informacijskih sustava237FER \ Fertalj: Razvoj informacijskih sustava238Izrada vremenskog rasporedaVremenski raspored projekta MS Project - Sustav za upravljanjeprojektima• klijentski program za mrežnoplaniranje• poslužitelj za upravljanje projektom –evidentiranje planova, rizika tedokumentacije Koraci izrade rasporeda projekta• Izrada liste zadataka• Izrada hijerarhije zadataka (workbreakdown structure)• Procjena trajanja zadataka• Izrada ovisnosti među zadacima• Dodjela resursaFER \ Fertalj: Razvoj informacijskih sustava240

Osnovni pogled na plan projektaIzrada liste zadataka Ganttov dijagram (Gantt Chart)• tablični prikaz zadataka na lijevoj strani i grafički prikaz na desnoj strani• prikaz plana projekta, unos i izmjene zadataka te analiziranje projekta Zadaci – osnovni gradbeni elementi svakog projekta• predstavljaju posao koji se mora obaviti da bi se postigao cilj projekta• opisuju tijek događaja, trajanja i zahtjeva za resursima na projektu• primitivni zadaci• zadaci koji se dekompozicijom ne mogu podijeliti na jednostavnijezadatke• skupni zadaci (summary tasks)• zbrajaju trajanje i troškove primitivnih zadataka• trajanje, datum te izračunate vrijednosti se automatski izvode iz skupaprimitivnih zadataka• prekretnice ili miljokazi (milestones)• ključni događaj ili krajnji rok odnosno cilj koji treba postići• trajanja 0• služe za provjeru stupnja dovršenosti drugih zadataka• pomak ključnog događaja ima za posljedicu vremenski prerasporedFER \ Fertalj: Razvoj informacijskih sustava241FER \ Fertalj: Razvoj informacijskih sustava242Lista i hijerarhija zadatakaIzrada hijerarhije zadataka Faza - grupa povezanih zadataka koji se odnose na fazu projekta• Zbirni zadaci se odnose na faze WBS (work breakdown structure)• hijerarhijska lista faza, zadataka i miljokaza• osnova za pregledni raspored projekta Dva su pristupa razvoju zadataka i faza:• Planiranje s vrha prema dolje (Top-down)• pristup od općeg prema specifičnom• identificira glavne faze i rezultate projekta prije dodavanja zadatakapotrebnih za završetak tih faza• složeni projekti mogu imati nekoliko slojeva faza;• Planiranje s dna prema dolje (Bottom-up)• pristup od specifičnog prema općem• identificira što više zadataka najnižeg sloja prije grupiranja u fazeFER \ Fertalj: Razvoj informacijskih sustava243FER \ Fertalj: Razvoj informacijskih sustava244

Procjena trajanja zadatakaMeđuzavisnost zadataka Trajanje zadatka• očekivana količina vremena za završetak zadataka• Tools/Options/Schedule – odabir željene vremenske jedinice Projekt može zahtijevati da zadacibudu napravljeni u određenomredoslijedu• Niz – iza jednog slijedi drugi zadatak• Zavisnost – sljedbenik (successor)može biti izvršen ako je dovršenprethodnik (predecessor)• Bilo koji zadatak može biti prethodnikjednom ili više sljedbenika Odnosi između zadataka:• Finish-to-start (FS) – završni datumprethodnika jest početni sljedbenika• Start-to-start (SS) - početni datumprethodnika utvrđuje početnisljedbenika• Finish-to-finish (FF) - završni datumprethodnika utvrđuje završnisljedbenika• Start-to-finish (SF) - početni datumprethodnika utvrđuje završnisljedbenikaFER \ Fertalj: Razvoj informacijskih sustava245FER \ Fertalj: Razvoj informacijskih sustava246Definiranje zavisnosti među zadacimaKritični put Kritični put• niz zadataka koji moraju završiti na vrijeme da bi projekt završio na vrijeme• svaki zadatak na kritičnom putu je kritični zadatak• kašnjenje kritičnih zadataka uzrokuje kašnjenje projekta Primjer kritičnog puta (View/Tracking Gantt)FER \ Fertalj: Razvoj informacijskih sustava247FER \ Fertalj: Razvoj informacijskih sustava248

ResursiRaspodjela resursa Resursi - sredstva• ljudi, oprema i materijal potrebni za obavljanje zadataka Vrste resursa:• Resursi rada (work resources)• ljudi (ograničeno vrijeme rada)• oprema (neograničeno vrijeme rada)• Resursi materijala (material resources)• potrošni materijal koji predstavlja projektni utržak• daje informaciju o brzini konzumiranja resursa Dva važna pogleda na resurse: Unos resursa i pratećih podataka (dostupnost, trošak) Maksimalne jedinice (max. units)• prikazuju vrijednosti raspoloživosti resursa u postocima• 100% predstavlja jednog čovjeka punog radnog vremena• 300% tri čovjeka punog radnog vremena• Raspoloživost - u koje vrijeme određeni resurs može raditi na zadatku ikoliko posla može obaviti• Trošak – koliko novca će biti potrošeno na resurseFER \ Fertalj: Razvoj informacijskih sustava249FER \ Fertalj: Razvoj informacijskih sustava250Kalendar i dodjela resursaRaspored resursa Kalendar resursa• osnova po kojoj je resursu dodijeljeno obavljanje posla• MS Project automatski za svaki resurs kreira (standardni) kalendar resursa• za pojedinačnu prilagodbu uvažavaju se radni i neradni dani resursa• Primjer: ako kalendar predstavlja radno vrijeme četvrtka i petka od 13-17sati, 100% raspoloživosti nekog resursa ne znaci 40 satno tjedno radnovrijeme, nego 8 satno tjedno radno vrijeme Dodjelom resursa zadatku, dodjeljuje mu se određeni posao• Posao – količina utroška resursa za završetak zadatka• Posao = Trajanje * Jedinice (Work = Duration * Units) Raspoređivanje temeljem napora (effort-driven scheduling)• metoda planiranja koja se koristi kod dodavanja ili brisanja nekog resursa sazadatka• početni rad zadatka ostaje konstantan bez obzira koliko se dodatnih resursadodijeliFER \ Fertalj: Razvoj informacijskih sustava251FER \ Fertalj: Razvoj informacijskih sustava252

Praćenje napretkaPraćenje napretka Snimanje detalja projekta koje nazivamo trenutne aktivnosti• Prati se napredak izvršavanja zadataka, tako da se zna kada resursizavršavaju rad nad dodijeljenim zadacima Pitanja koja se rješavaju na taj način mogu biti:• Da li zadaci počinju i završavaju planirano? Ako ne, kakav je utjecaj na rokzavršetka?• Da li resursi koriste više ili manje vremena od planiranog za završetakzadataka? Različite razine praćenja detalja uključuju:• Snimanje projektnog plana kada je to planirano• Snimanje postotka završenosti svakog zadatka• Snimanje stvarnog početka, stvarnog završetka, stvarnog posla i aktualnogtrajanja i onog trajanja koje ostaje do završetka svakog zadatka• Praćenje razine zadatka posla kroz period; ovo je najdetaljniji nivo praćenjagdje se snimaju stvarne vrijednosti radaFER \ Fertalj: Razvoj informacijskih sustava254Praćenje napretka - osnovica U početku postoji projektni plan koji je razrađen i koji se smatraosnovicom budućeg projekta Osnovica (baseline):• skup važnih vrijednosti u projektnom planu, kao što je planirani datumpočetka, završni datum i trošak zadatka, resursa• treba je spremiti kad je projektni plan razvijen i kada nije započetounošenje aktualnih vrijednosti poput postotka završetka zadatakaPraćenje napretka – spremanje osnovice Osnovni plan je prikazan sivom bojom i snimljen je u osnovicuplana prijekta• Tools/Tracking/Set Baseline...FER \ Fertalj: Razvoj informacijskih sustava255FER \ Fertalj: Razvoj informacijskih sustava256

Praćenje napretka Dovršenost zadatka mijenja se nakon što je posao započet• Moguće je za svaki zadatak snimiti stvarni početak, završetak i trajanje• MS Project ažurira raspored i računa postotak završetka zadatka Primjena pravila:• Kada se unese stvarni početak zadatka, Project namješta planirani početakda odgovara stvarnom početku• Kad se unese stvarni završetak Project pomiče planirani završetak daodgovara stvarnom završetku• Kad se unese stvarna vrijednost rada Project računa preostali posao• Kad se unese stvarno trajanje zadatka ako je manje od planiranog trajanjaProject oduzima stvarno trajanje od planiranog trajanja da izračunapreostalo trajanje• Kada se upiše stvarno trajanje zadatka, ako je jednako planiranom Projectupisuje 100% završeno• Kada se upiše stvarno trajanje zadatka ako je duže od planiranog trajanjaProject prilagođava planirano trajanje da odgovara stvarnom trajanju iupisuje 100% završenoPraćenje napretka Razlika između osnovice iaktualnog plana projekta• dogodila se promjena u odnosuna osnovicu• sivo – osnovica• crveno – kritični put• plavo – nekritični zadaci i umeđuvremenu ažurirani zadaciFER \ Fertalj: Razvoj informacijskih sustava257FER \ Fertalj: Razvoj informacijskih sustava258Pregled resursa (Resource Sheet)Utrošak resursa (Resource Usage) Prikaz i trajanje dodijeljenih resursa Pregled resursa dodijeljenih zadatku i njihovo trajanjeFER \ Fertalj: Razvoj informacijskih sustava259FER \ Fertalj: Razvoj informacijskih sustava260

Kalendar (Calendar View)Pregled zadataka (Task Usage) Prikaz zadataka po danima Pregled svih aktivnosti za svaki od zadataka i njihovog trajanjaFER \ Fertalj: Razvoj informacijskih sustava261FER \ Fertalj: Razvoj informacijskih sustava262Mrežni dijagram (Network Diagram)Reference Prikaz detalja svakog od zadataka i relacija između njih Upravljanje projektima• www.pmi.org• http://www.pmi-croatia.hr• http://www.ipma.org• http://www.ipma-hr.org Materijali• http://www.ebook3000.com/Software-Project-Management-in-Practice_22125.html• http://office.microsoft.com/en-us/help/HA011361531033.aspx Alati• http://www.smashingmagazine.com/2008/11/13/15-useful-projectmanagement-tools/FER \ Fertalj: Razvoj informacijskih sustava263FER \ Fertalj: Razvoj informacijskih sustava264