metode projektovanja

SVEUCILITE U ZAGREBU FAKULTET ELEKTROTEHNIKE I RACUNARSTVA

Kreimir Mari c

PRILAGODBA METODE EKSTREMNOG PROGRAMIRANJA ZA PROJEKT RAZVOJA JAVNE ELEKTRONICKE USLUGE

MAGISTARSKI RAD

Zagreb, 2005.

Magistarski rad je izraden u Centru za komunikacijska rjeenja, usluge, logistiku i e-sustave u kompaniji Ericsson Nikola Tesla d.d. u Zagrebu i na Zavodu za telekomunikacije Fakulteta elektrotehnike i ra unarstva c Sveu ilita u Zagrebu. c

Mentor:

Doc.dr.sc. eljka Car, dipl.ing. Fakultet elektrotehnike i ra unarstva, Sveu ilite u Zagrebu c c

Magistarski rad ima: 132 stranice.

Rad br.

i

Povjerenstvo za ocjenu rada u sastavu: 1. Prof.dr.sc. Ignac Lovrek - predsjednik, Fakultet Elektrotehnike i ra unarstva, Sveu ilite u Zagrebu c c 2. Doc.dr.sc. eljka Car - mentor, Fakultet Elektrotehnike i ra unarstva, Sveu ilite u Zagrebu c c 3. Prof.dr.sc. Ivica Crnkovi , c Mlardalen University, Department of Computer Science and Electronics, Vsters, Sweden

Povjerenstvo za obranu rada u sastavu: 1. Prof.dr.sc. Ignac Lovrek - predsjednik, Fakultet Elektrotehnike i ra unarstva, Sveu ilite u Zagrebu c c 2. Doc.dr.sc. eljka Car - mentor, Fakultet Elektrotehnike i ra unarstva, Sveu ilite u Zagrebu c c 3. Prof.dr.sc. Ivica Crnkovi , c Mlardalen University, Department of Computer Science and Electronics, Vsters, Sweden 4. Prof.dr.sc. Marijan Kunti - zamjenik, c Fakultet Elektrotehnike i ra unarstva, Sveu ilite u Zagrebu c c

Datum obrane: 06. travnja 2005.

ii

Zahvaljujem svima koji su mi na bilo koji na in pomogli da ovaj rad c doivi svjetlo dana. Zahvaljujem kompaniji, Ericsson Nikola Tesla d.d., ciji sam stipendist od prolje a 2003. godine, te doc.dr.sc. eljki Car, dipl.ing, voditeljici i c mentorici. Veliko hvala i kolegama s posla s kojima sam sudjelovao na HT Telex over IP i PZZ projektima, s kojima sam radio i od kojih sam puno nau io. Hvala i onima koji su mi izravno pomogli u realizaciji ovog c rada te ih izdvajam abecednim redom: dipl.ing. Tomislav Belobrajdi , c dipl.ing. Dalibor Brnas, dipl.ing. Ivan Crkvenac, doc.dr.sc. Saa Dei , c dipl.ing. Miljenko Kalenik, dipl.ing. Hrvoje Lu i , mr.sc. Karlo mid. cc Zahvaljujem se i svima onima koji su mi pomagali u ivotu i radu. Molim da mi oproste svi oni koje zbog ograni enog prostora ali i vlastite c zaboravljivosti nisam poimence nabrojao i zahvalio im.

Na kraju, posebno zahvaljujem kolegi dr.sc. Hrvoju Serti u, bez kojeg c svega ovoga najvjerojatnije ne bi bilo.

iii

SadrajPopis slika Koritene kratice 1 2 Uvod Pregled metodologija razvoja softvera 2.1 Uvod u metodologije razvoja softvera . . . . . . 2.2 Povijesni aspekti nastanka i razvoja metodologija 2.3 Primjeri metodologija razvoja softvera . . . . . . 2.3.1 Top-down i Bottom-up model . . . . . . . 2.3.2 Vodopadni model . . . . . . . . . . . . . 2.3.3 Spiralni model . . . . . . . . . . . . . . 2.3.4 Model kaosa . . . . . . . . . . . . . . . 2.3.5 Model protipa . . . . . . . . . . . . . . . 2.3.6 Iterativni i inkrementalni razvoj . . . . . 2.3.7 Rational Unied Process . . . . . . . . . Agilne metode (engl. Agile Methods) razvoja softvera 3.1 Povijesni aspekti nastanka agilnih metoda . . . . 3.2 Svojstva agilnih metoda . . . . . . . . . . . . . . 3.2.1 Pregled i denicije . . . . . . . . . . . . 3.2.2 Karakteristike . . . . . . . . . . . . . . . 3.3 Primjeri agilnih metoda . . . . . . . . . . . . . . viii ix 1 4 4 5 6 6 7 9 9 10 11 13 14 14 15 15 17 18 19 19 21 24 24 25 26

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

3

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

4

Razvojna metodologija ekstremnog programiranja 4.1 Uvod u ekstremno programiranje . . . . . . . . . . . . . . . . . . . . . . 4.2 Podru ja primjene metodologije ekstremnog programiranja . . . . . . . . c Postupci metodologije ekstremnog programiranja 5.1 Planiranje razvoja softvera u ekstremnom programiranju . . . . . . . . . 5.1.1 Korisni ke pri e . . . . . . . . . . . . . . . . . . . . . . . . . . c c 5.1.2 Planiranje isporuke . . . . . . . . . . . . . . . . . . . . . . . . .

5

iv

SADRAJ

5.2

5.3

5.4

5.5

5.6

5.1.2.1 Kvanticiranje projekta s cetiri varijable . . . . . . . . 5.1.3 Male isporuke . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1.4 Brzina projekta . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1.5 Iterativni razvoj . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1.6 Planiranje iteracija . . . . . . . . . . . . . . . . . . . . . . . . . 5.1.7 Kretanje ljudi . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1.8 Dnevni stoje i sastanci . . . . . . . . . . . . . . . . . . . . . . . c 5.1.9 Popravak XP-a . . . . . . . . . . . . . . . . . . . . . . . . . . . Dizajn softvera u ekstremnom programiranju . . . . . . . . . . . . . . . 5.2.1 Jednostavnost . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2.2 Metafora sustava . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2.3 CRC karte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2.4 Rjeenje tehnolokih probi . . . . . . . . . . . . . . . . . . . . . 5.2.5 Izbjegavanje dodavanja funkcionalnosti . . . . . . . . . . . . . . 5.2.6 Refaktoriranje . . . . . . . . . . . . . . . . . . . . . . . . . . . Kodiranje softvera u ekstremnom programiranju . . . . . . . . . . . . . . 5.3.1 Stalna prisutnost naru itelja u razvoju . . . . . . . . . . . . . . . c 5.3.2 Standardi pisanja kda . . . . . . . . . . . . . . . . . . . . . . . 5.3.3 Kodiranje testova za jedinice programa prije implementacije funkcionalnosti . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3.4 Programiranje u pru . . . . . . . . . . . . . . . . . . . . . . . . 5.3.5 Kontinuirana integracija kda . . . . . . . . . . . . . . . . . . . 5.3.5.1 Cesta integracija . . . . . . . . . . . . . . . . . . . . . 5.3.6 Zajedni ko vlasnitvo nad kdom . . . . . . . . . . . . . . . . . c 5.3.7 Optimizacija kda na kraju . . . . . . . . . . . . . . . . . . . . . 5.3.8 40-satni radni tjedan . . . . . . . . . . . . . . . . . . . . . . . . Testiranje softvera u ekstremnom programiranju . . . . . . . . . . . . . . 5.4.1 Testiranje jedinice programa . . . . . . . . . . . . . . . . . . . . 5.4.2 Pronalaenje neispravnosti . . . . . . . . . . . . . . . . . . . . . 5.4.3 Cesto izvravanje testova prihva enosti . . . . . . . . . . . . . . c ivotni ciklus XP projekta . . . . . . . . . . . . . . . . . . . . . . . . . 5.5.1 Istraiva ka faza . . . . . . . . . . . . . . . . . . . . . . . . . . c 5.5.2 Faza planiranja . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.5.3 Faza od iteracija do isporuke . . . . . . . . . . . . . . . . . . . . 5.5.4 Faza isporuke . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.5.5 Faza odravanja . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.5.6 Faza zavretka . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.5.7 Rizici u ivotnom ciklusu XP projekta . . . . . . . . . . . . . . . XP projektne uloge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.6.1 Programer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.6.2 Naru itelj . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . c v

27 28 28 29 30 31 32 33 33 34 34 34 35 35 36 37 37 38 39 40 41 41 42 43 43 43 44 45 46 46 47 48 48 48 49 49 49 50 51 51

SADRAJ

5.7 6

5.6.3 Tester . . . . . . . . . . 5.6.4 Traga . . . . . . . . . . c 5.6.5 Trener . . . . . . . . . . 5.6.6 Savjetnik . . . . . . . . 5.6.7 Menader . . . . . . . . Slijed dnevnih aktivnosti u XP-u

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

51 52 52 53 53 53 55 55 59 60 60 61 64 68 68 69 70 70 73 74 76 78 79 79 80 81 82 82 83 84 84 85 86 87 89 89 91

Primjene razvojnih postupaka metode ekstremnog programiranja 6.1 Opis projekta razvoja javne elektroni ke usluge . . . . . . . . . . . . . . c 6.2 Primjene razvojnih postupaka metode ekstremnog programiranja . . . . . 6.2.1 Programiranje u pru . . . . . . . . . . . . . . . . . . . . . . . . 6.2.2 Tehnika refaktoriranja . . . . . . . . . . . . . . . . . . . . . . . 6.2.2.1 Duplicirani kd . . . . . . . . . . . . . . . . . . . . . 6.2.2.2 Duga ka metoda . . . . . . . . . . . . . . . . . . . . . c 6.2.2.3 Golema klasa . . . . . . . . . . . . . . . . . . . . . . 6.2.2.4 Duga ka lista parametara . . . . . . . . . . . . . . . . c 6.2.3 Jedini no testiranje . . . . . . . . . . . . . . . . . . . . . . . . . c 6.2.3.1 Implementacija testova . . . . . . . . . . . . . . . . . 6.2.3.2 JUnit okruje za testiranje . . . . . . . . . . . . . . . . 6.2.3.3 Integracija Rational TestManger-a i JUnit-a . . . . . . 6.2.3.4 csUnit okruje za testiranje . . . . . . . . . . . . . . . 6.2.3.5 Potreba za razvojem novog testnog okruja . . . . . . . 6.2.4 Male i ceste isporuke . . . . . . . . . . . . . . . . . . . . . . . . 6.3 Rezultati primjene postupaka metode ekstremnog programiranja na projekt razvoja javne elektroni ke usluge . . . . . . . . . . . . . . . . . . . c 6.3.1 Period promatranja projekta . . . . . . . . . . . . . . . . . . . . 6.3.2 Struktura tima . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.3.2.1 Voditelj projekta . . . . . . . . . . . . . . . . . . . . . 6.3.2.2 Tehni ki koordinator . . . . . . . . . . . . . . . . . . . c 6.3.2.3 Programer . . . . . . . . . . . . . . . . . . . . . . . . 6.3.2.4 Tester . . . . . . . . . . . . . . . . . . . . . . . . . . 6.3.3 Karakteristika softvera . . . . . . . . . . . . . . . . . . . . . . . 6.3.4 Postupci XP-a . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.3.4.1 Programiranje u pru . . . . . . . . . . . . . . . . . . 6.3.4.2 Tehnika refaktoriranja . . . . . . . . . . . . . . . . . . 6.3.4.3 Jedini no testiranje . . . . . . . . . . . . . . . . . . . c 6.3.4.4 Male i ceste isporuke . . . . . . . . . . . . . . . . . . 6.4 Osvrt na budu i rad iz podru ja ekasne implementacije XP razvojne c c metodologije . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Zaklju ak c

7

vi

SADRAJ

A Izvorni kd A.1 BN.java . . . . . . . . . A.2 TC_BN.java . . . . . . . A.3 TM_BN.java . . . . . . A.4 Telecom_Factory_TC.cs Literatura Indeks

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

94 94 96 107 108 112 119

Saetak 119 Klju ne rije i . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 c c Summary 120 Keywords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120 ivotopis 121

vii

Popis slika2.1 3.1 5.1 5.2 5.3 5.4 5.5 6.1 6.2 6.3 6.4 6.5 6.6 Vodopadni model (engl. Waterfall model) . . . . . . . . . . . . . . . . . Odnos agilnih metoda i ostalih pristupa razvoja softvera . . . . . . . . . . Razvoj projekta u procesu ekstremnog programiranja . . . Iteracija u ekstremnom programiranju . . . . . . . . . . . Zajedni ko vlasnitvo kda . . . . . . . . . . . . . . . . . c Razvoj (engl. Development) u Ekstremnom programiranju ivotni ciklus XP procesa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 16 26 30 32 33 47 56 62 63 64 65 67 68 71 76 77

HalthCare Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Podru je zaustavljanja (engl. PullUpField) . . . . . . . . . . . . . . . . . c Oblik predloka metode (engl. Form Template Method) . . . . . . . . . . Izdvajanje klase (engl. Extract Class) . . . . . . . . . . . . . . . . . . . Uvodenje parametriziranog objekta (engl. Introduce Parameter Object) . Zamjena metode s metodom objekta (engl. Replace Method with Method Object) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.7 Izdvajanje potklase (engl. Extract Subclass) . . . . . . . . . . . . . . . . 6.8 JUnit testno okruje . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.9 csUnit testno okruje . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.10 HCAgentTestTool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

viii

Koritene kraticeACM ANSI ASD API ATM CCW COM CMM CVS DMIM DSDM FDD FSF GPL GUI HC HL7 Association for Computing Machinery Udruenje ra unalne opreme c American National Standards Institute Ameri ki nacionalni institut za standarde c Adaptive Software Development Prilagodljivi razvoj softvera Application Program Interface Aplikacijsko programsko su elje c Asynchronous Transfer Mode Asinkroni mod prijenosa COM Collable Wrapper Component Object Model Komponentni objektni model Capability Maturity Model Starosni model sposobnosti Concurrent Versions System Repozitorij konkurentnih verzija Domain Message Information Model Informacijski model poruka Dynamic Systems Development Method Dinami ka metoda razvoja sustava c Feature Driven Development Karakteristikama usmjeravan razvoj Free Software Foundation Slobodna softverska fundacija General Public License Op a javna licenca c Graphical User Interface Gra ko korisni ko su elje c c c Health Care Zdravstvena njega Health Level Seven Medunarodna organizacija koja se bavi standardiziranjem informatizacije zdravstva International Business Machines Corporation kolokvijalno, Big Blue ix

IBM

KORITENE KRATICE

ICT IDE ISO OO OSI OSS PLEX QA RAD RIM RUP SDK TDD UML XP

Information and Communications Technology Informacijska i komunikacijska tehnologija Integrated Development Environment Integrirano razvojno okruje International Organization for Standardization Medunarodna organizacija za standardizaciju Object - Oriented Objektno - orijentirano Open System Interconnection Otvoreni sustav meduspajanja Open Source Software Development Razvoj softvera otvorenog kda Programming Language for EXchanges Programski jezik za centrale Quality Assurance Osiguravanje kvalitete Rapid Application Development Rapidni razvoj aplikacija Reference Information Model Referentni informacijski model Rational Unied Process Rational unicirani proces Software Development Kit Alat za razvoj softvera Test Driven Development Testiranjem usmjeravan razvoj Unied Modelling Language Unicirani jezik za modeliranje eXtreme Programming Ekstremno programiranje

x

Poglavlje 1

UvodU dananjem informacijskom dobu, u svijetu tehnike, ra unala i komunikacija softver c je jedno od najvanijih dostignu a ljudskog stvaralatva. Softver je svakim danom sve c sloeniji zbog neprestanog razvoja sustava koji ga koriste. Kao posljedica te sloenosti, raste i broj razvojnih timova koji unutar softverskih ku a rade na razvoju softvera. c Kao neizostavna cinjenica name e se problematika razvoja softvera koji ce biti ispoc ru en na vrijeme, sa to manje otkrivenih pogreaka i sa to zadovoljnijim naru iteljima c c i kupcima. Ova problematika name e, kako u prijanjim godinama razvoja sloenog c softvera, a tako i u dananjem dobu, koritenje odgovaraju ih procesa za razvoj softvera, c nasuprot neorganiziranom i nesredenom razvoju. Pod pojmom procesa razvoja softvera podrazumijeva se slijed akcija koje se izvode u postupku razvoja softvera. Proces razvoja softvera je svojevrsna poveznica ljudi koji sudjeluju u razvoju softvera, alata koji se koriste u razvoju te procedura. Prema svome bitku, svi procesi razvoja softvera su op eniti do odredene mjere. Na c razvojnom timu ili kompaniji je da ga prilagodi svojim speci nim potrebama kako bi ga c mogla ekasno koristiti. Pojam procesa se cesto odnosi na standardiziranu i dokumentiranu metodologiju koja je ve prije koritena na sli nim projektima razvoja softvera ili koja se ve koristi unutar c c c neke organizacije ili ku e. c U minulim periodima razvijale su se razli ite metodologije koje su naglaavale c razli ite pristupe u razvoju softvera. Opstale su i danas se koriste one koje su se sa svojim c praksama pokazale dovoljno kvalitetnima i prilagodljivima da mogu odgovoriti na rastu e c probleme u dananjem razvoju softvera. Mogu se izdvojiti tradicionalne, procesnoorijentirane metode tradicionalnih pristupa u razvoju softvera te agilne, nove i manje opsene metode usredoto ene na male jedinice posla i s naglaskom na vrijednostima i c principima umjesto na procesu. Samo jedna metodologija razvoja softvera ne moe djelovati na citavom spektru razli itih projekata. Sve metodologije i nisu primjenjive u svim projektima. Usprkos c tomu, projektni menadment treba identicirati speci nu prirodu projekta te odabrati c najprikladniju razvojnu metodologiju. Zato i postoji potreba i za agilnim metodologijama i za procesno-orijentiranim metodologijama razvoja softvera [1]. Ekstremno programiranje (engl. Extreme Programming, XP) je pristup, odnosno 1

1 Uvod

metoda razvoja softvera koja adresira probleme od najranije faze prikupljanja zahtjeva (engl. requirements) do isporuke (engl. delivery). Ekstremno programiranje je, prije svega, programerska disciplina sa svojom jezgrenom inovacijom implementacije testova prije smog kodiranja programskog sustava (aplikacije) koja tim pristupom iz temelja mijenja postupak razvoja softvera. Zatim, XP je i timska disciplina koja uklju uje prakse koje pomau izgradnju tima visokih performansi i c solidnog znanja. Takoder, XP je i disciplina za rad s kupcima jer sadri speci an proces c planiranja i dnevne aktivnosti u procesu razvoja softvera. Ovaj rad bavi se problematikom uvodenja prikladnih praksi XP metodologije razvoja softvera u teku e projekte velike organizacije (ili odredene organizacijske jedinice) koja c se bavi razvojem softvera. Magistarski rad ima za cilj pokazati glavne prakse i temeljne karakteristike XP metodologije razvoja softvera. Istrauje se primjena odredenih praksi XP-a u projektima s razli itih stajalita osoba uklju enih u realizaciju razvojnog projekta (programera, testera, c c arhitekta sustava i menadera). Istrauje se mogu nost uvodenja nekih praksi XP-a u c pojedinim fazama projekta. Analizirane su prednosti i nedostaci praksi XP i ne-XP metodologije, koritenih resursa u smoj implementaciji i kvaliteta kda, tj. kakvo e c proizvoda, uz uo avanje glavnih prednosti i nedostataka obaju pristupa. c Rad je organiziran u slijede a poglavlja: c Drugo poglavlje opisuje metodologije i procese razvoja softvera. Daje deniciju metodologije i procesa razvoja softvera, opisuje povijesne aspekte nastajanja i razvoja metodologija te daje pregled danas najvanijih i najrairenijih metodologija razvoja softvera, posebno isti u i nove, agilne metode razvoja softvera. c c Tre e poglavlje opisuje glavne karakteristike agilnih metoda kao novijih metoda koje c obiljeava bri razvoj softvera. Kao glavni aspekt naglaava jednostavnost implementacije softvera, brzinu isporuke softvera, dobivanje povratne informacije (engl. feedback) od naru itelja te daljnje usmjeravanje razvoja softvera na dobivenim povratnim informacijama. c Navedeni su glavni predstavnici agilnih metoda. Cetvrto poglavlje predstavlja uvod u metodologiju ekstremnog programiranja razvoja softvera. Opisuje ekstremno programiranje kao glavnog predstavnika agilnih metoda razvoja softvera. Prikazane su osnovne karakteristike ove metodologije. U ovom poglavlju se pokuava dati odgovor na pitanje kada treba koristiti ekstremno programiranje te koje su prednosti takve razvojne metodologije. Peto poglavlje donosi detaljan opis glavnih pravila i praksi, odnosno fundamentalnih karakteristika ekstremnog programiranja, koje su razvrstane u cetiri tipi ne discipline c u razvoju softvera: planiranje razvoja, dizajn softvera, kodiranje (tj. implementacija) softvera te testiranje. Prikazan je i ivotni ciklus idealnog XP projekta te tipi ne projektne c uloge. esto poglavlje donosi prikaz HC Agent razvojnog projekta te problematiku uvodenja nekih praksi metodologije ekstremnog programiranja razvoja softvera u navedeni razvojni projekt. Istrauje se primjena odredenih praksi XP-a u projekt s razli itih stajalita c projektnog tima (programera, testera, arhitekta sustava i menadera). Takoder, istrauje se doprinos temeljnih praksi XP-a na status i napredak HC Agent razvojnog projekta. 2

1 Uvod

Zatim, usporeduje se navedeni projekt koji koristi neke od praksi XP metodologije razvoja softvera sa "klasi nim" (ne XP, niti agilnim) projektnom razvoja softvera. Uo avaju se c c glavne prednosti i nedostaci obaju pristupa. Poglavlje sadri i osvrt na budu i rad na c podru ju ekasne implementacije XP metodologije razvoja softvera. c Sedmo poglavlje sadri zaklju ak magistarskog rada. c

3

Poglavlje 2

Pregled metodologija razvoja softveraPovijesni nastanak metodologija razvoja softvera prati se jo od kasnih 60-ih i ranih 70-ih godina 20. stolje a. Naglim razvojem sklopovlja kontinuirano sve vie raste c sloenost softverskih sustava. Ovo poglavlje u svojoj uvodnoj rije i (odjeljak 2.1) daje osnovne denicije metodoc logija i procesa razvoja softvera. Prikazuju se povijesni aspekti razvoja softvera i nastajanje razli itih softverskih metoc dologija (odjeljak 2.2). Naglaena je problematika s kojom se razvoj softvera susretao sve do dananjih dana. Opisuju se okolnosti koje su dovele do nastanka metodologija razvoja softvera koje su objedinjene pod zajedni kim nazivom agilne metode (engl. Agile c Methods) (poglavlje 3). Opisuju se zna ajne metodologije razvoja softvera i prikazuju se njihove temeljne c karakteristike (odjeljak 2.3).

2.1

Uvod u metodologije razvoja softvera

Proces razvoja softvera (engl. software development process) je koriteni slijed akcija, odnosno postupak koji se koristi kako bi se proizveo ra unalni program (ili programski c sustav), odnosno programski proizvod [2]. U irem smislu, softver je cjelokupan skup programa, procedura i pripadne dokumentacije povezane sa sustavom, a naro ito ra unalnim sustavom. Po svojoj naravi, proces c c razvoja softvera moe biti i ad hoc proces, voden od tima ljudi za jedan speci an c softverski razvojni projekt. c No, pojam se ce e odnosi na standardiziranu i dokumentiranu metodologiju koja je koritena ve prije na sli nim projektima razvoja softvera ili koja sa koristi unutar neke c c organizacije. Iako ima mnogo razli itih denicija metodologija, na kraju se one svode na isto. c Metodologija razvoja softvera je postupak, odnosno kodiciran skup preporu enih praksi c koje pokazuju kako organizacija odabire sustav ljudi i potrebnih resursa kako bi kreirala i odravala softverski proizvod [3]. Metodologija je prilagodavana prema razli itim korisnicima koji ce je koristiti [4]. c Po etnici trae detaljan slijed koraka koje treba pratiti kako bi se garantirao uspjeh. Oni c 4

2.2 Povijesni aspekti nastanka i razvoja metodologija

srednjeg znanja i iskustva trae rang strategija koje ce koristiti u razli itim trenucima u c projektu. Eksperti su primarno zainteresirani na otkrivanje artefakata i kontrolnih to aka c koje metodologija zahtijeva, kako bi se ekasno ostvarili zadani ciljevi i pra enje projekta. c U softverskom inenjerstvu (engl. software engineering), metodologija je popisan skup preporu enih praksi i teorije, ponekad popra en s materijalima za treniranje, c c programima formalne edukacije, dijagramima tka i sli no [5]. c Metodologije u softverskom inenjerstvu premo uju mnoge discipline, uklju uju i c c c upravljanje projektom (engl. project management), analizu, specikaciju, dizajn, kodiranje, testiranje te osiguravanje kvalitete. Sve metodologije su zapravo svojevrsne kolekcija svake od tih disciplina. Metodologije razvoja softvera se mogu op enito podijeliti u dvije glavne skupine [5] c [6]. 1. Teke i opsene metodologije razvoja softvera (engl. heavyweight methodologies) sadre mnogo pravila, na ina postupanja i dokumentacije. Trae vrijeme i disciplinu c za ispravno slijedenje. Nazivaju se i "debelim" metodama (engl. thick methods). 2. Lake i manje opsene metodologije razvoja softvera (engl. lightweight methodologies) obi no sadre tek nekoliko pravila i na ina postupanja koji su lagani za c c slijedenje. Nazivaju se i "tankim" metodama (engl. thin methods). Cilj razvoja softvera je proizvodnja kvalitetnog softvera, u zadanom vremenu, unutar predvidenog budeta i uz zadovoljavanje stvarnih potreba naru itelja [7]. c Uspjeh projekta ovisi o dobrom upravljanju zahtjevima (engl. requirement management). Greke u zahtjevima i nepravilno specicirani zahtjevi su jedni od naj e ih problema c c u razvoju sustava i najskuplji su za ispravljanje. Neke klju ne vjetine mogu zna ajno c c smanjiti greke u odredivanju zahtjeva softvera te poboljati kvalitetu.

2.2

Povijesni aspekti nastanka i razvoja metodologija

U kasnim 60-tim te ranim 70-tim godinama 20. stolje a zajedni ka praksa ra unalnih c c c programera u stvaranju softvera je bilo kreiranje softvera na bilo koji na in, tj. neorganic zirano i nesredeno, na onaj na in koji se trenutno mogao koristiti i koji je vodio cilju. c U to vrijeme se isticao velik broj ra unalnih programera koji su proizvodili softver koji c je bio teak za razumijevanje ikome te jako kompleksan. Tada je naprosto bilo cudo ako se program izvravao bez i jedne evidentirane neispravnosti. Dranje ra unala radno c uspjenim je smatrano golemim naporom te svojevrsnim vrijednim istraivanjem. Softversko inenjerstvo (engl. Software Engineering) je disciplina dizajniranja i proizvodnje softvera te uklju uje sve potrebne akcije da bi se proizveo softver. Utemeljeno c je na konferencijama sponzoriranim od NATO organizacije 1968. godine u GarmischPartenkirchenu i 1970. godine u Rimu. Programiranje je, dakle, samo dio discipline softverskog inenjerstva. 5

2.3 Primjeri metodologija razvoja softvera

U to vrijeme je bilo uvrijeena praksa da ve e i discipliniranije metodologije mogu c pomo i u razvoju softvera dosljedne kvalitete i predvidljive cijene. Time se zaustavila c vladavina "razuzdanih" tzv. cowboy programera. U 80-tim godinama 20. stolje a nastupilo je bolje vrijeme za ra unalne programere. c c U to vrijeme je postojalo nekoliko pravila i praksi za kreiranje softvera koji je bio daleko superiorniji u kvaliteti od onog to je bio desetlje e ranije [8]. c S vremenom se sve vie pove ava broj pravila i na ina postupanja za pokrivanje c c potencijalnih problema u razvoju softvera. Zna ajno se pove ava i kvaliteta softvera kao c c posljedica neprestanog usavravanja metodologij razvoja softvera. Kona no, u 21. stolje u pravila te na ini postupanja i djelovanja cesto postaju jo tei c c c za pra enje, procedure su katkad kompleksne i nerazumljive, a time i kona ni softverski c c produkti. Koli ina dokumentacije u nekim apstraktnim notacijama lagano izmi e kontroli. c c Programeri cesto odbacuju pravila i prakse sloenih metodologija koje koriste (tzv. cowboy programeri); instinktivno se odri u tekih i opsenih metodologija razvoja sofc tvera i vra aju prema ranijim, jednostavnijim, lakim i manje opsenim metodologijama c koje je lake pratiti, gdje je tek nekoliko pravila (engl. rules) dovoljno. Kao suprotnost sloenih i opsenih metodologija, javljaju se lake i manje opsene metodologije. Problematika koja se ovdje javlja je da ra unalni programeri i softverski inenjeri c ne ele potpuno odbaciti pravila i praksu koja je pomagala razvoj kvalitetnog softvera (engl. quality software) kako ne bi nastao kaos. To zna i, dakle, zadravanje odredenih c pravila i praksi koje omogu uju razvoj kvalitetnog softvera. Rjeenje je, dakako, jedino c u pojednostavljenju sloenih (previe kompleksnih) pravila i praksi, u onim situacijama i okolnostima gdje je to mogu e. c Istodobno, ne eli se povratak ranim danima anarhi nog (engl. cowboy) kodiranja koje c je prevladavalo u 70-im godinama 20. stolje a. Umjesto toga, eli se zadrati dovoljno (ali c ne previe) pravila i praksi kako bi se zadrala pouzdanost, kvaliteta i cijena softvera. Rezultat tih napora su nove, lake i manje opsene metodologije razvoja softvera koje su objedinjene pod zajedni kim terminom agilne metode (poglavlje 3). Neke c od metodologija razvoja softvera unutar agilnih metoda su ekstremno programiranje (poglavlje 4), Lean Software Development ("Mravi" razvoj softvera) i druge.

2.3

Primjeri metodologija razvoja softvera

Slijedi opis zna ajnijih metodologija razvoja softvera. Teite je usmjereno na agilnim c metodama (poglavlje 3) i na ekstremnom programiranju (poglavlje 4).

2.3.1

Top-down i Bottom-up model

Top-down [9] i Bottom-up [10] su dva pristupa koritena u razvojnoj metodi ili dvije kategorije razvojnih metodologija. Oba pristupa se mogu promatrati kao nadogradnja na druge, postoje e razvojne metodologije. c 6


U Top-down kategoriji formuliran je pregled sustava bez ulaenja u detalje bilo kojeg njegovog dijela. Svaki pojedini dio sustava se tada dalje razvija dizajniranjem u vie detalja. Svaki novi dio sustava moe biti ponovno poboljan i detaljnije deniran, sve dok cjelokupna specikacija nije dovoljno detaljna kako bi se zapo eo razvoj, tj. c implementacija. U suprotnosti, u Bottom-up modelu individualni dijelovi sustava su detaljno specicirani te mogu mirno biti kodirani, tj. implementirani. Ti individualni kodirani dijelovi se tada spajaju zajedno kako bi tvorili ve e komponente, koje su pak medusobno spajane sve c dok nije spojen kompletan sustav. Top-down pristup isti e planiranje te potpuno razumijevanje sustava. Svojstveno je c da kodiranje ne moe zapo eti dok nije dostignut dovoljan nivo detalja na barem nekim c dijelovima sustava. Pristup je 1970. godine promovirala IBM kompanija. Bottom-up pristup isti e kodiranje koje moe zapo eti ve onda cim je speciciran c c c prvi modul. Dakako, kodiranje u Bottom-up pristupu nosi rizik da moduli, koji su u fazi kodiranja, nemaju cvrstu ideju kako ce se spojiti s ostalim dijelovima sustava te da to spajanje ne e biti lagano kako na prvi pogled obi no izgleda. c c Moderni pristup dizajnu softvera obi no kombinira metode od oba navedena pristupa. c Iako se razumijevanje cijelog sustava obi no smatra nunim za dobar dizajn, veliki broj c softverskih projekata pokuava iskoristiti ve postoje i kd (engl. reuse). Time postoje i c c c moduli daju dizajnu Bottom-up smjer.

2.3.2

Vodopadni model

Vodopadni model (engl. Waterfall model) [5] je model, odnosno metodologija razvoja softvera koju je 1970. godine predloio Winston W. Royce u clanku "Managing Development of Large Scale Software" [11]. Model je baziran na empiri kim opservacijama da cijena promjene raste eksponenc cijalno sa stupnjem promjene. Zaklju ak je da velike odluke potrebno donijeti cim je c mogu e vie ranije jer je kasnija promjena skupa. c U tom modelu, razvoj slijedi linearno kroz faze analize zahtjeva (engl. requirements analysis), dizajna (engl. design), implementacije (kodiranja) (engl. implementation), testiranja (validacije) (engl. testing (validation)), integracije (engl. integration) i odravanja (engl. maintenance). Proces se zove "vodopadni" jer svaka faza, tj. ciklus u modelu logi ki slijedi za c prethodnim ciklusom (tj. fazom). Slika (2.1) prikazuje glavne faze u vodopadnom modelu koje logi ki slijede za c prethodnom fazom: 1. Analiza i denicija zahtjeva (engl. Requirements Analysis and Denition) 2. Dizajn sustava i softvera (engl. System and Software Design)

7

2.3 Primjeri metodologija razvoja softveraAnaliza i definicija zahtjeva Dizajn sustava i softvera Implementacija i jedinino testiranje Integracija i testiranje sustava

Slika 2.1: Vodopadni model (engl. Waterfall model)

3. Implementacija i jedini no testiranje (engl. Implementation and Unit Testing) c 4. Integracija i testiranje sustava (engl. Integration and System Testing). Iz bilo koje faze vodopadnog modela mogu je povratak u bilo koju fazu to je i prikazano c strelicama na slici. U praksi, vodopadni model rijetko slijedi cisto linearni stil ve je cest iterativni c pristup razvoja (odjeljak 2.3.6). Winston W. Royce je u svom originalnom clanku naglasio ponovljivu upotrebu modela u iterativnom na inu. c Iteracija je karakteristika stanovitih algoritama ili ra unalnih programa u kojoj se c sekvenca jednog ili vie algoritamskih koraka obavlja u programskoj petlji. Iteracija se razlikuje se od ponavljaju e tehnike koja se zove rekurzija (engl. recursion). c Mnogi softverski inenjeri su u novije vrijeme diskreditirali vodopadni model u korist agilnih metoda razvoja (poglavlje 3). Glavni razlozi tome su teak i skup povratak u prethodnu fazu te dugo trajanje projekata koji koriste ovu metodologiju. Vodopadni model je prvenstveno orijentiran velikim i tehni ki zahtjevnim projektima. Faza analize i c denicije zahtjeva je kriti na faza za propast projekta. c Vodopadni model je zapravo tradicionalni model razvoja softvera. Iako diskreditiran u korist agilnih metoda, i dalje je cesto koriten u praksi [12]. Glavne prednosti modela su: preglednost, vidljivost i dobra organiziranost. Moraju postojati dobro denirani zahtjevi kako bi se uspjeno provodile slijede e faze. Vodopadni c model je orijentiran prema opsenoj dokumentaciji. Glavni nedostaci modela su: neeksibilno particioniranje projekta u to no odredene c dijelove to ga cini tekim za odgovor na promjene zahtjeva kupca te teak i skup povratak u prethodnu fazu.

8


2.3.3

Spiralni model

Spiralni model [5] je model, odnosno metodologija razvoja softvera koja ima na elo c u kombiniranju elemenata dizajna i stadija (etapa) iz prototipa. Zapravo, to je svojevrsna mjeavina Top-down i Bottom-up koncepata (odjeljak 2.3.1). Spiralni model je denirao Barry Boehm clankom "A Spiral Model of Software Development and Enhancement" 1986. godine [13]. Najve a zna ajka modela je eksplicitno c c prepoznavanje i uklanjanje rizika. Gra ki prikaz modela je u obliku spirale u koordinatnom sustavu. Svaka petlja spirale c predstavlja jednu fazu procesa razvoja softvera. Petlja po inje iz kvadranta problema gdje c se vri pregled izvedivosti. U slijede em kvadrantu se obavlja analiza rizika i odabir c prototipa. Slijedi kvadrant s programskim dijelom (simulacije, modeli i procjena) i sa provjerom (validacija). Zadnji kvadrant predstavlja integraciju i provjeru. No, taj model nije bio prvi model za raspravu o iteracijama ve je bio prvi model c koji je raspravljao o vanosti iterativnog dizajna. Originalno je zamiljeno da je duina iteracija tipi no 6 mjeseci do dvije godine. c Prednosti spiralnog modela su: Eksplicitno prepoznavanje rizika koje omogu uje njegovo ekasno uklanjanje. c Procjene (budet i plan) su realisti nije kako projekt napreduje jer se pove ava broj c c pitanja. Mogu e je uhvatiti se u kotac s (gotovo neizbjenim) promjenama koje razvoj c softvera op enito name e. c c Softverski inenjeri mogu ranije po eti djelovati na projektu. c Glavni nedostatak spiralnog modela je to su procjene koje se ti u budeta i plana c grube na po etku jer neke analize nisu zavrene sve dok te etape nisu prole fazu dizajna. c c Spiralni model kao takav u dananje vrijeme (2005. godina) nije koriten [14] u ve oj mjeri. Dakako, utjecao je na moderne koncepte razvoja softvera dananjice, naro ito na c tzv. agilne metode (poglavlje 3) koje nastoje biti ekstremnije u svojem pristupu nego to je spiralni model.

2.3.4

Model kaosa

U svijetu razvoja softvera, model kaosa (engl. Chaos model) je struktura razvoja softvera koji proiruje spiralni model (odjeljak 2.3.3) i vodopadni model (odjeljak 2.3.2) razvoja softvera. Model kaosa je denirao L.B.S. Raccoon radom "The Chaos Model and the Chaos Life Cycle" [15]. Model kaosa pretpostavlja da su faze ivotnog ciklusa programskog proizvoda primjenjive na sve nivoe projekta, od cjelokupnog projekta do individualnih linija kda.

9


U matematici i zici, teorija kaosa postupa s ponaanjem odredenih nelinearnih dinami kih sustava koji, pod odredenim okolnostima, predo avaju fenomen poznatiji kao c c kaos, izvanredno karakteriziran osje ajno u za po etna stanja. Primjeri takvog sustava c c c uklju uju atmosferu, sun ev sustav, turbulentne uide itd. c c Nelinearni dinami ki sustav op enito moe pokazati slijede e tipove ponaanja: c c c zauvijek u miru zauvijek ekspandira (samo za neomedene, tj. neograni ene sustave) c periodi ka kretanja c kvaziperiodi ka kretanja c kaoti na kretanja c Tip ponaanja moe ovisiti o po etnom (inicijalnom) stanju sustava i vrijednostima c parametara ako oni postoje. Postoji nekoliko doprinosa modela kaosa: Model kaosa moe pomo i dati odgovor na pitanje zato je softver toliko nepredvic div. Model objanjava zato koncepti visokog nivoa kao to je arhitektura ne mogu biti tretirani neovisno od linija kda koje su nieg nivoa. Model omogu uje objanjenje to napraviti slijede e (slijede i korak) sukladno sa c c c strategijom kaosa. Slijede najvanije pretpostavke za ostvarenje modela kaosa: Cijeli projekt treba biti deniran, implementiran te integriran. Sustav koji se razvija mora biti deniran, implementiran te integriran. Moduli sustava moraju biti denirani, implementirani te integrirani. Funkcije modula sustava trebaju biti denirane, implementirane te integrirane. Linije kda trebaju biti denirane, implementirane te integrirane.

2.3.5

Model protipa

Model prototipa (engl. Prototyping model) [16] je proces razvoja softvera koji po inje c s kolekcijom zahtjeva (engl. requirements collection) iza cega slijedi izrada prototipa i evaluacija od strane korisnika (tj. naru itelja). c Cesto, krajnji korisnik nije u mogu nosti pribaviti kompletan skup grade za sustav koji c se implementira, detaljne informacije ili zahtjeve za inicijalni stadij. Nakon korisni ke c 10


evaluacije prototipa, obi no se gradi drugi prototip koji je baziran na povratnoj sprezi c dobivenoj od kupca. Ponovno se dobiva povratna informacija, tj. evaluacija od kupca. Ciklus zapo inje sluanjem kupca (ili naru itelja) iza cega slijedi izgradnja ili revizija c c modela, te kasnije kupac (naru itelj) vri testiranje modela. Ciklus se nakon toga ponavlja. c Razlikuju se dva osnovna tipa prototipa: evolucionarni prototip (prototip se odabire za daljnje koritenje) odbacuju i prototip (prototip se odbacuje). c Pojam "prototip" ne odnosi se isklju ivo na softver. Kompanije mogu proizvesti c prototip produkata kako bi pokazali odredene karakteristike ili kako bi imale model koji radi prije poboljavanja ostalih dijelova iz dizajna. U elektronici, izrada prototipova zna i izradu elektri nog kruga prema teoretskom c c dizajnu za verikaciju valjanosti dizajna, te za pripremu zi ke platforme za otkrivanje c neispravnosti dizajna.

2.3.6

Iterativni i inkrementalni razvoj

Iterativni i inkrementalni razvoj (engl. Iterative and Incremental development) [16] je proces razvoja softvera, te takoder jedna od praksi koja se koristi u metodologiji ekstremnog programiranja (poglavlje 4) kao predstavniku agilnih metoda (poglavlje 3).

Inkrement je deniran kao podsustav sustava. Zavreni inkrement je podsustav za koji vrijedi da su faze analize, dizajna i kodiranja sustava zavrene, revidirane i testirane. Iteracija je denirana kao prolaz preko odredenog skupa aktivnosti. Iterativni proces je revizija i nastavak rada na prijanjem poslu. Osnovna ideja ovog modela je inkrementalan razvoj softverskog sustava koji omogu cuje programerima da iskoriste prednosti od onoga to je bilo nau eno tijekom razvoja c ranijih, inkrementalnih verzija sustava koje su cesto bile i isporu ene kupcu (naru itelju). c c U enje dolazi i iz razvoja i iz koritenja sustava, gdje je to mogu e [17]. c c Klju ni koraci u procesu su zapo eti sa jednostavnom implementacijom podskupa c c softverskih zahtjeva te iterativno pove avati skup softverskih zahtjeva (isporu uju i pri c c c tom verzije) sve dok svi programski zahtjevi nisu realizirani, to zna i da je sustav c implementiran u potpunosti. U svakoj iteraciji cine se modikacije dizajna zajedno sa implementacijom novih funkcionalnosti (sukladno softverskim zahtjevima). Discipline unutar svake iteracije su: prikupljanje zahtjeva, dizajn, implementacija i test. Svaka iteracija je zapravo mini-projekt. Iterativna i inkrementalna metoda razvoja se sastoji od inicijalizacijskog koraka (engl. Initialization step), iteracijskog koraka (engl. Iteration step) i projektne kontrolne liste (engl. Project Control List).

11


Inicijalizacijski korak slui kreiranju osnovne (bazne) verzije sustava. Cilj te inicijalne implementacije je kreiranje proizvoda na kojeg korisnik moe djelovati. Taj korak treba ponuditi primjer klju nih aspekata problema i omogu iti rjeenje koje je c c dovoljno jednostavno za razumijevanje i za implementaciju. Za vodenje iterativnog procesa, kreirana je projektna kontrolna lista koja sadri zapise svih zadataka koji trebaju biti izvreni. Sadri i pojedine stavke kao nove zna ajke koje c treba implementirati te podru ja redizajna postoje e solucije. c c Projektna kontrolna lista je kontinuirano pregledavana i revidirana kao rezultat faze analize. Iteracijski korak povla i za sobom redizajn i implementaciju zadataka iz projektne c kontrolne liste te analizu trenutne verzije sustava. Cilj dizajna i implementacije bilo koje iteracije je da bude cim jednostavnija, izravna i modularna, podravaju i redizajn c u trenutnom stadiju ili na mjestu gdje se zadaci dodaju u projektnu kontrolnu listu. Kd reprezentira glavni izvor dokumentacije sustava. Analiza iteracije je bazirana na korisni koj povratnoj informaciji i mogu nosti analize sustava koji je u implementaciji. c c To obuhva a analizu strukture kda, modularnost, upotrebljivost, pouzdanost, ekasnost c te postignu e ciljeva. Projektna kontrolna lista je modicirana prema rezultatima analize. c Linija vodilja implementacije i analize sadri: Bilo koja poteko a u dizajnu, kodiranju i testiranju treba signalizirati modikaciju c (redizajn ili promjene u kdu). Modikacije trebaju biti prilagodljive postoje im izoliranim modulima. Ako to nije c slu aj, potreban je redizajn. c Modiciranje tablica baze podataka treba biti izvedivo posebno lagano. U slu aju c da su modikacije tablica zahtjevne, potreban je redizajn. Kako iteracije napreduju, modikacije bi trebale biti lake izvedive. Ako to nije slu aj, zna i da postoji osnovni problem kao to je propust u dizajnu ili problem s c c patch-evima. U svijetu ra unala, softverska zakrpa (engl. patch) je softverska nadogradnja (engl. c update) za ispravljanje problema, neispravnosti ili upotrebljivosti prethodne verzije aplikacije. To moe uklju iti bilo koji ra unalni program u rangu od tekstualnih c c editora, ra unalnih igara do operativnih sustava i Web servisa. Termin patch potje e c c od Unix patch komande Larry Wall-a. Preporu ljivo je postojanje patch-eva za samo jednu ili maksimalno dvije iteracije. c Postojanje patch-eva je nuno kako bi se izbjegao redizajn u fazi implementacije. Postoje a implementacija treba biti cesto analizirana kako bi se odredilo udovoljac vanje prema ciljevima projekta. Treba biti koritena mogu nost programske analize kad god je to mogu e, kako bi c c se pomogla analiza djelomi ne implementacije. c Reakcija treba biti traena i analizirana od strane korisnika (kupca ili naru itelja) c za indikaciju nedostataka trenutne implementacije. 12


Iterativni pristup je uspjeno koriten za razvoj familije prevodioca za familiju programskih jezika koji su primjenjivi na mnotvu sklopovskih arhitektura. Koritenje analize i mjerenja kao goni a iterativnog poboljavaju eg procesa je glavna c c razlika izmedu iterativnog procesa i postoje ih agilnih metoda (poglavlje 3). Omogu uje c c podrku za odredivanje djelotvornosti procesa i kvalitete proizvoda. Takoder, omogu uje c prou avanje, poboljavanje i prilagodbu procesa za odredeni okoli. Te aktivnosti mjerec nja i analize mogu biti aktivno dodane postoje im agilnim razvojnim metodama. c Sklop viestrukih iteracija osigurava prednosti koritenja mjerenja. Mjerenja su katkad teka za razumijevanje u potpunosti, ali relativne promjene u mjerenjima preko evolucije sustava mogu biti vrlo informativne jer time osiguravaju osnovu za usporedbu. Na primjer, vektor mjerenja m1 , m2 , ..., mn moe biti deniran da bi karakterizirao razli ite c aspekte proizvoda u nekom vremenskom trenutku; npr. vrijeme, promjene, neispravnosti te logi ke, zi ke i dinami ke atribute. Analizator moe odrediti kako se karakteristike c c c proizvoda, kao to su veli ina, kompleksnost, spajanje i kohezija pove aju i smanjuju u c c vremenu. Mjeriti se mogu i relativne promjene razli itih aspekata produkta ili predvidjeti c granice za mjerenja za signaliziranje potencijalnih problema i anomalija

2.3.7

Rational Unied Process

Rational Unied Process (RUP) su razvili Philippe Kruchten, Ivar Jacobsen i ostali u Rational Corporation kompaniji kako bi upotpunili UML (Unied Modelling Language), koji je industrijski standardizirana metoda modeliranja softvera [18]. RUP je interaktivni i inkrementalni pristup za objektno-orijentirane sustave, strogo prihva a slu ajeve uporabe (engl. Use Cases) kao zahtjeve u modeliranju. Iako implicitno c c ne isklju uje ostale metode, naglaava UML metodu i objektno-orijentirani (OO) razvoj c (Jacobsen, 1994. godine). RUP naglaava razvoj softvera u fazama [19]. Svaka faza se sastoji od jedne ili vie iteracija. RUP opisuje cetiri faze kroz koje prolazi projekt: inspekcija, elaboracija, konstrukcija i tranzicija. Sadraj faze inspekcije je kreiranje vizije, razvoj business case-a, stvaranje softverskog prototipa ili djelomi nog rjeenja. U fazi elaboracije se donose klju ni arhitekturalni c c zaklju ci i eliminiraju rizici. Izvrna arhitektura proizvodi softver na temelju klju nih c c arhitekturalnih zaklju aka. U fazi konstrukcije se vri implementacija funkcionalnosti c koja je identicirana u arhitekturi. U fazi tranzicije je fokus na isporuci softvera kupcu. Faze su podijeljene na iteracije. Iteracije su vremenski odredene te imaju speci ne c ciljeve. Iteracije se dre vremenski to je mogu e kra ima ali dovoljno dugima kako c c bi se implementirali potpuni slu ajevi uporabe ili odredeni scenariji koji predstavljaju c odredenu vrijednost za korisnika. Na kraju svake iteracije se prilagodavaju planovi za budu e iteracije na temelju rezultata trenutne iteracije. c RUP predstavlja kreiranje vizije onoga to se eli, kreiranje okruja (engl. framework) kako bi se to postiglo, te procjene na zadanim to kama da li se nalazi na putu gdje se c namjeravalo biti.

13

Poglavlje 3

Agilne metode (engl. Agile Methods) razvoja softveraAgilno ozna ava spremno na pokret, aktivnost, ustrost, hitrost. Agilne metode c razvoja softvera pokuavaju ponuditi odgovor na elju poslovne zajednice za manje opsenim metodologijama razvoja softvera, koje sa sobom donose bre, ustre procese razvoja softvera [18]. U softverskom inenjerstvu, agilne metode razvoja softvera su manje opsene metode koje prihva aju cinjenicu da je softver teko kontrolirati [18]. One minimiziraju rizik time c to osiguravaju da su inenjeri koji razvijaju softver fokusirani na male jedinice posla. To je naro ito vano sa dananjim rapidnim rastom industrije vezane uz Internet, sa okolinom c vezanom uz mobilne aplikacije te s distribuiranim razvojem op enito. c Na in na koji je agilni razvoj softvera op enito odijeljen od "teih", vie procesnoc c orijentiranih metodologija, npr. vodopadnog modela (odjeljak 2.3.2), predstavlja naglasak na vrijednostima i principima umjesto na procesu. Tipi ni ciklusi su jedan tjedan ili jedan mjesec. Na kraju svakog ciklusa vrednuju se c projektni prioriteti to je karakteristika koju agilne metode dijele s modelom iterativnog razvoja (odjeljak 2.3.6) i modernim teorijama upravljanja projektima.

3.1

Povijesni aspekti nastanka agilnih metoda

U posljednjih 25 godina isproban je velik dio razli itih pristupa u razvoju softvera, od c kojih je samo nekoliko istinski zaivjelo. Agilne metode su se razvijale sredinom 90-ih godina 20. stolje a kao dio reakcije c na tzv. visoko formalne metode (engl. high ceremony methods), kao to su CMM (engl. Capability Maturity Model), Prince i Rational Unied Process. Proces razvoja koji vu e c porijeklo od ovih metoda je u odredenim primjenama viden kao birokratski i spor. Agilni pokret (engl. Agile Movement) u industriji softvera je zapo eo 2001. godine c kada je grupa softverskih prakti ara i konzultanta (Kent Beck, Alstair Cockburn i ostali) c objavila "Agile Software Development Manifesto" [20] [17]. Uvodenje metodologije ekstremnog programiranja (engl. Extreme Programming) 1999 godine, poznatije kao XP, je iroko prihva ena kao startna to ka razli itih pristupa c c c agilnog razvoja softvera. Postoji, takoder, mnotvo drugih metoda koje pripadaju zajed 14

3.2 Svojstva agilnih metoda

ni koj porodici agilnih metoda. Neke od tih metoda, odnosno metodologija su: Crystal c Methods (Cockburn, 2000. godine), Feature-Driven Development (Palmer i Felsing, 2002. godine), Adaptive Software Development (Highsmith, 2000. godine) i druge.

3.2

Svojstva agilnih metoda

Glavni aspekt agilnih metoda je jednostavnost i brzina. U razvojnom radu, tim je koncentriran samo na funkcije koje su potrebne u prvoj ruci i na njihovu implementaciju, zatim na brzu isporuku, dobivanje povratne informacije od naru itelja te reakcije na c primljene informacije. Glavno pitanje je to cini razvojnu metodu agilnom? To je slu aj kada je razvoj c softvera: inkrementalan (malene isporuke, s brzim ciklusima) kooperativan (naru itelj i razvojni tim rade neprestano zajedno u bliskoj komunikac ciji) izravan (metoda je jednostavna za u enje i modiciranje te dostatno dokumentirana) c prilagodljiv (u mogu nosti da se cine promjene u posljednjem trenutku). c Tipi ni ciklus projekta [21] je u trajanju od jednog tjedna ili jednog mjeseca i na kraju c svakog ciklusa se vri ocjena projektnih prioriteta, to je karakteristika i inkrementalnih metodologija razvoja softvera (odjeljak 2.3.6) i modernih teorija projektnog vodenja. Op enito, agilne metode name u koritenje nepotrebnih trokova to je manje moc c gu e, u formi principa, opravdanosti, izvjetavanja i doputenja. c

3.2.1

Pregled i denicije

Glavni principi agilnog pokreta objavljenih u manifestu su [17]: Individualnost i interakcije iznad procesa i alat Agilni pokret naglaava vezu i zajednitvo ra unalnih programera i ljudskih uloga c u suprotnosti s institucionaliziranim procesima i razvojnim alatima. U postoje im c agilnim praksama, to se manifestira u bliskosti projektnog tima i dobrom timskom duhu. Softver koji radi iznad opsene dokumentacije Vitalni zadatak softverskog tima je kontinuirana isporuka testiranog softvera koji radi. Nove verzije se isporu uju u pravilnim razmacima (npr. nekoliko puta c mjese no). Programeri su duni odravati kd jednostavnim i tehni ki doradenim c c cim je vie mogu e. Naglasak nije na koli ini proizvedene dokumentacije. c c Suradnja s kupcem (engl. customer) iznad striktnih ugovora Veza i suradnja izmedu programera i naru itelja je u prednosti nad striktnim c 15


ugovorima, iako vanost dobro sro enih ugovora raste istim tempom kao i veli ina c c softverskih projekata. Iz poslovnog kuta gledanja, agilni razvoj je fokusiran na brzu isporuku, ubrzo nakon to je projekt startan, cime se smanjuju brojni rizici (promjene zahtjeva, testiranost, odustajanje od projekta i drugi). Odgovor na promjene iznad sljedenja plana Razvojna grupa koja sadri i programere i naru itelja trebala bi biti dobro inc formirana, kompetentna i autoritativna kako bi uzela u obzir mogu e prilagodbe c za vrijeme razvojnog puta projekta. To zna i da bi sudionici tima trebali biti c pripremljeni da cine promjene.

Prilagodljiv razvoj softvera Hakeri XP

1111111 0000000

Procesnoorijentirane metode

Strogi ugovorni pristup razvoju

11 00Agilne metode Softverski CMM CMM

11 00

Slika 3.1: Odnos agilnih metoda i ostalih pristupa razvoja softvera Slika (3.1) prikazuje spektar razli itih pristupa razvoju softvera, gdje su ad-hoc c (hackerski pristup) smjeteni na jednom kraju a drugi, klasi ni, procesno-orijentirani c pristup na drugom, suprotnom kraju. Agilne metode su blie ad-hoc pristupu. c Cockburn [4] je denirao jezgru agilnih metodologija razvoja softvera koriste i neopsena ali dovoljna (engl. light-but-sufcient) pravila ponaanja u projektu koritenjem humanih i komunikacijski-orijentiranih pravila. Agilni proces je istovremeno i jednostavan i dovoljan. Predlae se postojanje ovih praksi koje omogu uju prosperitet c projekata: dva covjeka do osmero ljudi u jednoj sobi (komunikacija, dijeljenje znanja) cesto koritenje eksperta (kratke i kontinuirane povratne informacije) kratke inkrementalne verzije (jedan do tri mjeseca, omogu eno je brzo testiranje i popravak greaka) c potpuno automatizirano regresijsko testiranje (jedini no i funkcijsko testiranje stabilizira kd i omogu uje kontinuirana poboljc c anja) iskusni programeri (iskustvo ubrzava vrijeme razvoja i to 2 do 10 puta u usporedbi sa sporijim clanovima tima; obi no rade uz bilo koju metodologiju). c 16


3.2.2

Karakteristike

Miller [22] je prikazao slijede e karakteristike agilnih softverskih procesa iz kuta c gledanja brze isporuke, koje omogu uju skra ivanje ivotnog ciklusa projekata: c c 1. modularnost stupnja razvojnog procesa 2. kratke iteracije koje omogu uju brze verikacije i korekcije c 3. vremenski okvir iteracija je od jednog do est tjedana 4. micanje svih nepotrebnih aktivnosti 5. prilagodljivost s mogu im nenadanim rizicima c 6. inkrementalni pristup procesu koji omogu ava funkcionalnu izgradnju softverskog c produkta u malim koracima 7. konvergentni i inkrementalni pristup minimizira rizike 8. ljudski-orijentirani agilni proces favorizira ljude iznad procesa i tehnologija 9. kolaborativni i komunikativni radni stil. Odabir odgovaraju e procedure nije toliko orijentiran kako bi zaustavio promjene rano c u projektu, ve kako se bolje nositi s neminovnim promjenama tijekom citavog ivotnog c ciklusa projekta. Agilne metode su zapravo dizajnirane kako bi: proizvele prvu isporuku u ranim tjednima projekta, kako bi se postigla "brza pobjeda" i rapidna povratna informacija od kupca osmislile jednostavno rjeenje tako da je manje toga za mijenjati i izrada tih promjena je jednostavnija c kontinuirano unaprijedile kvalitetu dizajna, cine i slijede u iteraciju jeftinijom za c implementaciju potakle kontinuirano testiranje za raniju i time manje skuplju detekciju neispravnosti. Osnovni principi agilnih metoda uklju uju cisto u kda koji radi, efektivnost ljudi koji c c rade zajedno sa dobrom voljom te je fokus zapravo na timskom radu [23]. Skup pristupa koji izviru iz agilnih procesa razvoja softvera su slijede i: c ljudima je stalo da razvojni projekt uspije cim manje dokumentacije (ako je mogu e) c komunikacija o kriti nim stvarima c alati za modeliranje nisu korisni kao to se obi no misli c

17

3.3 Primjeri agilnih metoda

veliki dizajn unaprijed nije poeljan (iako je ovo nepovoljno prilikom razvoja sigurnosnih sustava). Budu nost informacijskog doba je i u agilnim metodologijama [24]. Softverske komc panije koje koriste agilnost imaju kapacitet da pove aju inovativnost i brzinu te kreiraju c promjene kod konkurenata. Sporije i manje inovativne kompanije doivljavaju kaos koji su drugi pokrenuli. Sposobnosti kompanija da dre korak i kreiraju promjene lei u sposobnosti razvoja softvera. U svijetu neprestanih promjena, tradicionalne rigorozne metode razvoja softvera su nedovoljne za uspjeh. Sada je trend ko-opeticije, to za procese zna i kombinaciju tradicionalnih i agilnih c metoda.

3.3

Primjeri agilnih metoda

Kao rezultat agilnog pristupa u razvoju softvera, mogu se izdvojiti slijede e postoje e c c agilne metode koje su denirane na prethodnim na elima (odjeljak 3.2) jednostavnosti i c brzine: Extreme Programming (Beck, 1999. godina) Scrum (Schwaber 1995. godine, Schwaber i Beedle 2002. godine) Crystal porodica metodologija (Cockburn 2002. godine) Feature Driven Development (Palmer i Felsing 2002. godine) Rational Unied Process (Kruchten 1996. godine, Kruchten 2002. godine) Po naravi, RUP nije tipi an predstavnik agilnih metoda. Orijentiran je na stvaranje c i koritenje velike koli ine dokumentacije. c Dynamic System Development Method (Stapleteon 1997. godine) Adaptive Software Development (Highsmith 2000. godine) Open Source Software Development (OReilly 1999. godine).

18

Poglavlje 4

Razvojna metodologija ekstremnog programiranjaEkstremno programiranje (Extreme Programming, XP) je pristup, odnosno metoda razvoja softvera kuju su formulirali Kent Beck, Ward Cunningham i Ron Jeffries [3]. Kent Beck je napisao prvu knjigu na tu temu pod naslovom "Extreme Programming Explained" [25] koja je objavljena 1999. godine. Metoda ekstremnog programiranja je najpopularnija od nekoliko agilnih metoda razvoja softvera (poglavlje 3). XP je predstavnik lakih i manje opsenih metodologija razvoja softvera namijenjen prvenstveno malim timovima koji razvijaju softver, suo eni sa neodredenim zahtjevima c ili sa zahtjevima koji se dinami ki mijenjaju. Predstavnik je agilnih metoda razvoja. c XP je izniknulo iz problema prouzro enog dugim razvojnim ciklusom tradicionalnih c razvojnih modela. Krenulo je jednostavno kao prilika kako bi se zavrio posao s praksama koje su smatrane dovoljno ekasnima u procesu razvoja softvera. Nakon dovoljno velikog broja pokuaja u praksi, XP metodologija je dokumentirana s klju nim principima i c praksama. Individualizirane prakse XP-a nisu same po sebi nove, u XP-u one su sakupljene kako bi zajedno funkcionirale i cinile novu metodologiju razvoja softvera. Pojam ekstremno dolazi od tih zajedni kih praksi koje su dokazane kao dobro primjenjive i koje su c dovedene do svojih ekstremnih granica [25]. U XP-u postoji proces kojeg se slijedi ali je zajedni ko razmiljanje da je taj proces c vie nalik pravilima igre [24].

4.1

Uvod u ekstremno programiranje

Ekstremno programiranje je discipliniran pristup razvoju softvera [8]. Ovaj pristup je star desetak godina (dakle, po eo se koristiti u prvoj polovici devedesetih godina prolog c stolje a) i dokazan je u mnogim kompanijama razli itih veli ina te u industriji u zemljama c c c irom svijeta [24]. Pokreta metodologije je bio Kent Beck koji je razmiljao o boljem na inu razvoja c c softvera. Proveo je neko vrijeme rade i s Ward Cunninghamom i zajedno su iskusili c 19

4.1 Uvod u ekstremno programiranje

pristup razvoju softvera koji svaku stvar cini jednostavnijom i u inkovitijom. Kent Beck c je u tvrtki DaimlerChrysler zapo eo jedan speci an razvojni projekt u prolje e 1996. c c c godine koriste i nove koncepte razvoja softvera. Rezultat je bio metodologija ekstremnog c programiranja razvoja softvera. Dakle, po svojoj starosti, to je jedan od mladih pristupa. Smatra se prvom uspostav c ljenom agilnom metodom (poglavlje 3) nakon nekih zajedni kih popularnih taktika medu ra unalnim programerima. c Jedna od temeljnih vrijednost XP-a je zadovoljstvo naru itelja softvera. Zadovoljstvo c naru itelja je kona ni cilj u ciklusu razvoja softvera jer uklju uje ispunjenje, tj. implec c c mentiranost ulaznih zahtjeva. Ti ulazni zahtjevi su ispunjeni ako je naru itelj softvera zac dovoljan s implementiranom funkcionalno u. Metodologija ekstremnog programiranja c je dizajnirana za isporuku softvera koju naru itelj treba u trenutku kada je ona potrebna c (tj. vri se implementacija to no onoga to je prethodno dogovoreno). XP omogu uje c c programerima odgovor na promjene zahtjeva koje donosi naru itelj softvera, cak i kasno c u procesu razvoja softvera. Ova metodologija naglaava timski rad. Menaderi, naru itelji softvera i programeri c su zajedno dio tima koji je zaduen za isporuku kvalitetnog softvera. XP tim je time proireni razvojni tim jer njega ne cine samo programeri, nego i menaderi i naru itelj. XP c implementira jednostavan ali ekasan na in razvoja softvera koji se temelji na grupama c (parovima) (odjeljak 5.3.4). Fundamentalne, tj. temeljne karakteristike modela ekstremnog programiranja su [26]: 1. Igra planiranja (engl. Planning game) Korisni ka interakcija u programerskom (implementacijskom) timu izmedu prograc mera i naru itelja oko procjena implementacije pojedine funkcionalnosti. c 2. Malene ceste isporuke (engl. Small/short releases) Sustav se brzo i cesto isporu uje, najmanje svaka 2 do 3 mjeseca. Ovaj pristup se c temelji na praksi iterativnog i inkrementalnog razvoja (odjeljak 2.3.6). 3. Organizacija sustava s metaforama (engl. Methaphor) Metafora je pojednostavljena slika sustava u razvoju. 4. Jednostavan dizajn (engl. Simple Design) Naglasak je na dizajnu najjednostavnijeg rjeenja koji je zahtijevan u tom trenutku, bez dodatnog kda i vika funkcionalnosti. 5. Testiranje (engl. Testing) Kontinuirano, cesto ponavljaju e automatizirano jedini no (engl. unit) testiranje i c c regresijsko (engl. regression) testiranje. 6. Koritenje tehnike refaktoriranja (engl. Refactoring) Micanje dvostrukog (redundantnog) kda i odravanje kda jednostavnim. 7. Programiranje u pru (engl. Pair Programming) Ovaj princip zna i da uvijek dva covjeka piu odredeni kd. c 20

4.2 Podru ja primjene metodologije ekstremnog programiranja c

8. Zajedni ko dijeljenje kda (pristup kdu) (engl. Collective Ownership) c Bilo tko iz tima smije mijenjati bilo ciji kd. 9. Kontinuirana integracija (engl. Continuous integration) Novi kd se integrira u sustav cim je spreman (implementiran i testiran). 10. 40 satni radni tjedan (engl. 40-hours week) Maksimum je 40-satni radni tjedan. Nisu poeljni uzastopni prekovremeni tjedni zbog slamanja timskog duha. 11. Povratna informacija od kupca (naru itelja) (engl. On-site customer) c Naru itelj je stalno na raspolaganju programerima. c 12. Standardi kodiranja (engl. Coding Standards) Postoje standardi kodiranja i programeri ih slijede kako bi kd na kojem se trebaju na initi bilo kakve promjene, a napisao ga je netko drugi u timu, bio cim c razumljiviji. Programeri su prvenstveno motivirani eljom kreiranja softvera koji radi i na koji su ponosni koliko je dobar. Motivacija je zapravo bazirana na ponosu i programeri se jednostavno ele istaknuti. To je razlog to ele koristiti XP metodologiju razvoja softvera (pored ostalih agilnih metoda) jer osje aju da agilne metode omogu uju isporuku softvera c c koji radi [4]. XP poboljava softverski projekt u cetiri esencijalna to ke: komunikaciji, jednosc tavnosti, povratnoj informaciji od naru itelja (kupca) te odvanosti ili hrabrosti. XP c programeri komuniciraju sa svojim naru iteljima softvera i svojim kolegama (ra unalnim c c programerima). Svoj dizajn softvera nastoje drati jednostavnim i cistim. Vana to ka u c razvoju softvera je provodenje testiranja (po evi ve s prvim danom), cime se dobiva c c povratna informacija da li se softver ispravno ponaa. Poeljno je softver isporu iti naruc citelju (kupcu) najranije to je mogu e, implementiraju i promjene sukladno dogovorima c c s naru iteljem (kupcem). S tim pristupom, XP programeri su u mogu nosti odgovoriti c c zahtjevima i tehnologiji koji su skloni cestom mijenjanju. Ekstremno programiranje je po svojim temeljnim karakteristikama razli ita metodoloc gija razvoja softvera od drugih, tradicionalnih pristupa razvoju softvera. Dobra usporedba metodologije ekstremnog programiranja je sa pazlama (engl. puzzle). Postoji mnogo malih komadi a koji individualno ne zna e mnogo ali kada se kombiniraju zajedno, moe c c se dobiti potpuna slika.

4.2

Podru ja primjene metodologije ekstremnog prograc miranja

Ekstremno programiranje je kreirano kao odgovor na domenu problema ciji se zahtjevi mijenjaju. Naru itelj softvera (engl. customer) ne treba imati cvrstu i kona nu c c 21


ideju to sustav u kona nici treba raditi. Mogu e je da programeri razvijaju sustav cija c c se funkcionalnost mijenja svakih nekoliko mjeseci. U mnogim softverskim okolinama dinami ko mijenjanje zahtjeva je zapravo konstanta. Ovo je svakako podru je gdje XP c c moe uspjeti dok ostale metodologije razvoja softvera mogu zakazati i cest slu aj u praksi c je da zakazuju. XP takoder doti e i probleme vezane za rizike u projektu. U slu aju da naru itelj c c c softvera treba novi sustav do odredenog datuma, rizik je velik. Ako je taj sustav i novi izazov za grupu programera u timu, rizik je jo i ve i. U slu aju da je sustav c c koji se razvija nov izazov za cjelokupnu softversku industriju, rizik je time jo ve i. c Metodologija ekstremnog programiranja svojim praksama omogu ava da se ublai rizik i c pove a vjerojatnost uspjeha projekata. c Ekstremno programiranje je prvenstveno namijenjeno maloj grupi programera, obi no c izmedu 2 i 12. No, i ve i projekti od 30 i vie programera su zabiljeili uspjeh koriste i c c ovu metodologiju razvoja softvera ili neke njene prakse. Ipak, ekstremno programiranje nije preporu ljivo na velikim projektima iako postoje i pozitivna iskustva [25] [27]. c Dakako, treba naglasiti da na projektima s dinami kim zahtjevima ili visokim rizicima c mala grupica XP programera moe biti (a obi no i je) u inkovitija nego veliki tim c c programera. Metodologija ekstremnog programiranja zahtijeva proireni razvojni tim. Kao to je ve re eno, XP tim uklju uje ne samo programere, nego jo menadere i naru itelje c c c c softvera, tvore i tako proireni razvojni tim. Svi sudionici tima rade zajedno i jedni c su drugima pri ruci. Postavljanje pitanja, podru je pregovaranja te vremenski rokovi c vezani uz razvoj, testiranje i isporuku ne uklju uju samo programere, ve i menadere c c i naru itelje. c Nakon smog razvoja, testabilnost je drugi najvaniji zahtjev u razvoju softvera kod ekstremnog programiranja. Vana je mogu nost kreiranja automatiziranih funkcijskih i c jedini nih testova. Cest je slu aj da su pojedine domene testiranja diskvalicirane zbog c c speci nih zahtjeva. Tada je mogu e promijeniti dizajn sustava kako bi se olakalo c c testiranje. XP metodologija razvoja softvera nije primjenjiva u svim projektima. XP je teko implementirati u slu ajevima kada: c Postoji jak otpor prema XP na inu programiranja. Teko je prihvatiti XP metodoloc giju ako proces koji se koristi funkcionira dobro [3] i nije ga potrebno mijenjati. U nekim projektima postoji zahtjev za generiranjem velike koli ine dokumentacije. c XP je proces razvoja softvera a ne proces razvoja dokumentacije. U nekim okruenjima je prekovremeni rad uobi ajena praksa. XP nije primjenjiv u c takvim okruenjima. Ljudi u timu ponekad ne mogu ili ne ele medusobno komunicirati iz razli itih c razloga (objektivnih ili subjektivnih). XP nije primjenjiv u takvim okruenjima.

22


Veliki timovi nisu prihvatljivi za XP. Najbolje rezultate XP postie s manjim brojem ljudi, obi no od 2 do 12. c Okolina u kojoj se povratne informacije dugo cekaju nije pogodna za primjenu XPa. XP o ekuje povratne informacije vrlo rano u dizajnu i implementaciji kako bi se c imalo vremena djelovati na razvoj sustava. XP nije pogodan za odredene klase produkata: sigurnosne dugog ivota modularne

23

Poglavlje 5

Postupci metodologije ekstremnog programiranjaOvo poglavlje poblie opisuje glavne prakse, odnosno temeljne karakteristike XP metodologije razvoja softvera koje su razvrstane u cetiri tipi ne discipline u razvoju c softvera: 1. planiranje razvoja (odjeljak 5.1) 2. dizajn softvera (odjeljak 5.2) 3. kodiranje softvera (implementacija) (odjeljak 5.3) 4. testiranje softvera (odjeljak 5.4). Takoder, poglavlje opisuje ivotni ciklus XP projekta (odjeljak 5.5), XP projektne uloge (odjeljak 5.6) i slijed dnevnih aktivnosti u XP projektu (odjeljak 5.7).

5.1

Planiranje razvoja softvera u ekstremnom programiranju

Planiranje razvoja softvera uklju uje akcije prikupljanja zahtjeva koji se oblikuju u c korisni ke pri e (engl. User Stories) (odjeljak 5.1.1), planiranje isporuke na nivou citavog c c projekta (odjeljak 5.1.2) te kreiranje plana iteracij za svaku pojedinu iteraciju (odjeljak 5.1.6) u iterativnom razvoju softvera (odjeljak 5.1.5). Ovdje je naglaena i uklju ena vanost cestih i malenih isporuka (odjeljak 5.1.3) te c vanost mjerenja brzine projekta (engl. Project Velocity) na vrenje planiranja (odjeljak 5.1.4). Takoder, isti e se vanost dnevnih stoje ih sastanaka (engl. Daily Stand Up Meeting) c c (odjeljak 5.1.8) te spomenuta praksa kretanja ljudi (engl. Move people around) u projektu kao mehanizam spre avanja gubitka znanja (odjeljak 5.1.7). c

24

5.1 Planiranje razvoja softvera u ekstremnom programiranju

5.1.1

Korisni ke pri e c c

Korisni ke pri e (engl. User Stories) slue istom cilju kao i slu ajevi uporabe (engl. c c c Use Cases), no zapravo nisu isto. Koritene su, u prvom redu, kako bi se kreirale vremenske procjene za planiranje isporuke softvera (engl. Release Planing) (odjeljak 5.1.2). Takoder, njihovo zna enje je i zamjena velikih dokumenata za zahtjevima koje c softver treba zadovoljavati. Slu ajevi uporabe koriste se za modeliranje zahtjeva koje sustav mora ispunjavati. c Zahtjevi koje sustav mora ispunjavati se mogu podijeliti u dvije glavne skupine: funkcijski zahtjevi (engl. functional requirements) i zahtjevi koji se odnose na kvalitetu usluge (engl. quality of service requirements). Slu ajevi uporabe deniraju ponaanje sustava ili c dijela sustava te predstavljaju skup scenarija koji sustav izvodi kako bi postigao neki cilj. Scenarij je skup koraka koji se izvode za vrijeme interakcije izmedu korisnika i sustava. Funkcijski zahtjevi deniraju to ce sustav raditi za korisnika. Kada se deniraju, sustav se obi no predstavlja kao crna kutija (engl. black box) jer se samo gleda ponaanje c sustava izvana. Zahtjevi koji se odnose na kvalitetu usluge deniraju performanse, pouzdanost i sigurnost sustava. Nikad nisu samostalni, ve se odnose na jedan ili vie funkcijskih zahtjeva. c Primjena slu ajeva uporabe ima za cilj modeliranje eljenog ponaanja sustava, bez c potrebe speciciranja na ina implementacije takvog ponaanja. Tipi an proces modelic c ranja nekog sustava po inje detaljnom specikacijom slu aja uporabe, a nakon toga se c c prelazi na realizaciju (deniranje klas od kojih se sastoji te potrebnih interakcijskih dijagrama). Korisni ke pri e pie naru itelj (engl. customer) softvera kao zahtjeve koje sustav c c c (softverski sustav) treba zadovoljiti. Sli ne su korisni kom scenariju, jedino to nisu c c limitirane na opis korisni kog su elja (engl. user interface). Obi no su u formatu od c c c oko tri re enice teksta u terminologiji naru itelja bez tehni ke sintakse. Dakle, po svojim c c c karakteristikama, druga ije su od slu ajeva uporabe. c c Korisni ke pri e vode kreiranju tzv. testa prihva enosti softvera kojeg potvrduje c c c naru itelj (engl. Acceptance Test) (odjeljak 5.4.3) [28]. Potrebno je kreiranje jednog ili c vie automatiziranih testova prihva enosti softvera kako bi se vericirale korisni ke pri e, c c c tj. provjerilo da li su korisni ke pri e ispravno implementirane. c c Slika (5.1) prikazuje sudjelovanje korisni kih pri a u obliku zahtjeva u izradi vrec c menske procjene za isporuku softvera (planiranje isporuke) te testa prihva enosti softvera c kojeg potvrduje naru itelj na temelju razli itih scenarija testiranja. c c Jedno od najve ih nerazumijevanja s korisni kim pri ama je kako se pri e razlikuju c c c c od tradicionalnih specikacija zahtjeva, odnosno slu ajeva uporabe. Najve a razlika c c je u stupnju detalja. Korisni ke pri e trebaju osigurati dovoljno detalja kako bi se c c na inila razumna procjena relativno niskog rizika koja prikazuje koliko dugo ce trajati c implementacija te korisni ke pri e. Kada dode vrijeme za implementaciju pri e, ra unalni c c c c programeri ce do i do naru itelja i primiti detaljan opis zahtjeva. c c Programer procjenjuje koliko dugo (vremenski) ce trajati implementacija pojedine

25

5.1 Planiranje razvoja softvera u ekstremnom programiranjuScenariji testiranja

Korisnike prie Tehnoloka proba

Zahtjevi Metafora sustava Nesigurne procjene

Nova korisnika pria Brzina projekta Plan isporuke Sigurne procjene

Neispravnosti Zadnja verzija

Planiranje isporuka

Iteracija

Test prihvaenosti

Odobrenje naruitelja

Mala izdanja

Slijedea iteracija

Proba

Slika 5.1: Razvoj projekta u procesu ekstremnog programiranja

korisni ke pri e. Svaka korisni ka pri a ce oduzeti jedan, dva ili tri tjedna procjene u c c c c "idealnom vremenu" razvoja. To idealno vrijeme razvoja zapravo zna i koliko dugo treba c za implementaciju korisni ke pri e u kd ukoliko nema nekih prepreka, drugih obveza te c c je to no poznato to i kako treba ciniti. c Razdoblje due od tri tjedna zna i da bi korisni ku pri u trebalo razdvojiti u vie manjih c c c dijelova. Razdoblje kra e od jednog tjedna zna i premalu razinu detalja; treba kombinirati c c nekoliko korisni kih pri a u jednu. Oko 80 korisni kih pri a (plus/minus 20) je idealan c c c c broj za kreiranje plana isporuke softvera (odjeljak 5.1.2). Ta procjena koju donosi programer je zapravo tehni ka procjena. U kreiranju procjena c sudjeluje i naru itelj. c Druga razlika izmedu korisni kih pri a (odjeljak 5.1.1) i dokumenta zahtjeva, odnosno c c slu ajeva uporabe je fokus na potrebe naru itelja. Poeljno je pokuati izbje i detalje c c c speci ne tehnologije, osnove baze podataka te algoritme. Poeljno je pokuati drati c korisni ke pri e fokusirane na potrebama naru itelja kao suprotnost specikaciji izgleda c c c gra kog su elja. c c

5.1.2

Planiranje isporuke

Korisni ke pri e (odjeljak 5.1.1) slue kako bi se kreirao plan isporuke [29] koji c c vrijedi za citav projekt. Plan isporuke se, kada je doneen, koristi za kreiranje plana iteracij za svaku pojedinu iteraciju (odjeljak 5.1.5) (slika 5.1). Planiranje isporuke (engl. Release Planning) softvera sadri skup pravila koje omogu cuju svima uklju enima u projekt da naprave vlastite odluke. Skup pravila denira metodu c oko pregovora vremenskog plana kojeg svatko iz tima moe ispuniti. Bt planiranje isporuke za razvojni tim je idealna procjena trajanja svake korisni ke c pri e u tjednima. Idealno, tjedan je vremensko trajanje implementacije korisni kih pri a c c c ako se apsolutno nita drugo ne cini, jedino uklju uju i implementaciju jedini nih testova. c c c Naru itelj tada odlu uje koje korisni ke pri e su najvanije ili imaju najvii prioritet da c c c c bude zavrene, znaju i koja je vanost pojedine pri e za kupca. c c

26


Korisni ke pri e su obi no napisane na kartama (komadima papira). Zajedno, ra uc c c c nalni programeri i naru itelj kreiraju skupove pri a koje ce biti implementirane u prvoj c c (i slijede im) isporukama. Programer donosi, kao to je ve re eno, tehni ke procjene c c c c o potrebnom vremenu implementacije pojedine korisni ke pri e. Naru itelj odreduje c c c prioritet pri a unutar iteracije (odjeljak 5.1.5). c Krajnji cilj je upotrebljiv, testabilan sustav koji ce biti rano isporu en ( im je c c mogu e ranije). Brzina projekta (odjeljak 5.1.4) je kreirana kako bi se odredilo koliko c korisni kih pri a moe biti implementirano prije danog datuma (roka) ili koliko dugo c c traje implementacija skupa korisni kih pri a (doseg). Kad se vri vremensko planiranje, c c treba pomnoiti broj iteracija s brzinom projekta da bi se odredilo koliko korisni kih pri a c c moe biti zavreno. Kad se vri planiranje po dosegu, potrebno je podijeliti ukupan broj tjedana procijenjenih korisni kih pri a s brzinom projekta kako bi se odredio ukupan broj c c iteracija do kraja. Individualne iteracije su detaljno planirane prije po etka svake iteracije i nikako ne c unaprijed. Kad je kreiran kona ni plan isporuke (engl. Final Release Plan) i prosljeden menadc mentu, cesto se pokuavaju promijeniti procjene korisni kih pri a. Smanjenjivati procjene c c u ovom slu aju nije dobro niti poeljno. Procjene su valjane i smanjivanje trajanja c procjena ce vjerojatno prouzro iti probleme kasnije. Umjesto toga, moe se pregovarati c oko prihvatljivog plana isporuke sve dok se razvijatelji softvera, naru itelji i menaderi c slau oko plana isporuke. Slika (5.1) prikazuje postupak nastajanja planiranja isporuke (odjeljak 5.1.2). Na nastajanje planiranje isporuke utje u zahtjevi te metafora sustava (engl. System Metaphor) c (odjeljak 5.2.2). Nepouzdane i nesigurne procjene (engl. Uncertain Estimates) mogu biti popravljenje odredenim tehnolokim probama (engl. Spike) (odjeljak 5.2.4). Sigurne, tj. pouzdane procjene (engl. Condent Estimates) ponovno utje u na planiranje isporuke. c Planiranje isporuke rezultira planom isporuke (engl. Release Plan) koji vrijedi za citav projekt te se koristi za kreiranje plana iteracij (odjeljak 5.1.6) za svaku pojedinu iteraciju. Kreiranje novih korisni kih pri a (engl. New User Stories) unutar pojedinih iteracija c c ponovno utje e na planiranje isporuke i donoenja novog plana isporuke. c 5.1.2.1 Kvanticiranje projekta s cetiri varijable

Osnovna lozoja planiranja isporuke je da projekt moe biti kvanticiran s cetiri varijable [29]: domet, resursi, vrijeme i kvaliteta. Varijable predstavljaju dimenziju projekta. Domet se odnosi na kvantitetu; tj. koliko toga treba na initi. Resursi su u zna enju c c broja dostupnih ljudi. Vrijeme se odnosi na trenutak kad su projekt ili isporuka gotovi. Kvaliteta je pokazatelj koliko je softver dobar i koliko dobro ce biti testiran. Gledaju i op enito, potrebno je kontrolirati barem dvije od cetiri varijable u bilo c c kojem projektu, kako bi se projekt odvijao pod nadzorom. Menadment moe samo odabrati tri od cetiri projektne varijable kako bi upravljao i

27


planirao, dok razvoj uzima preostalu cetvrtu varijablu. Smanjenje kvalitete manje od izvrsno (engl. excellent) ima nepredvidljivi utjecaj na ostale tri varijable. Zbog toga, u osnovi, postoje samo tri varijable koje se zapravo ele mijenjati, izuze i kvalitetu. c

5.1.3

Male isporuke

Zada a razvojnog tima je cesto isporu iti iterativne verzije sustava naru itelju. Kod c c c planiranja isporuke je potrebno denirati malene jedinice funkcionalnosti koje su pogodne za isporuku i koje mogu biti isporu ene u okruje naru itelja rano u projektu (u ranim c c fazama projekta). Kriti no je dobiti vrijednu i kvalitetnu povratnu informaciju od korisnika kako bi se c na vrijeme imao bolji utjecaj na daljnji razvoj sustava. Cijena promjene softvera je ve a u c kasnijim fazama projekta (implementaciji, testiranju te isporuci) nego u po etnim fazama c projekta kada je malo toga implementirano. to se vie ceka isporuka vanih obiljeja korisnicima, bit ce manje vremena za njihov ispravak. Slika (5.1) prikazuje nastajanje malenih isporuka (engl. Small Releases) nakon to je proao test prihva enosti softvera. c

5.1.4

Brzina projekta

Brzina projekta (engl. Project Velocity) je mjera koliko brzo posao moe biti napravljen na projektu. Faktor radnog u inka (engl. load factor) je koriten kao mjera brzine u c projektima sve do nedavno. No, brzina projekta je jednostavnija mjera za koritenje od faktora radnog u inka. Ako pomae, moe se koristiti faktor radnog u inka kako bi se c c kreirala po etna procjena brzine projekta. Nakon toga se moe koristiti brzina projekta c umjesto faktora radnog u inka. c Za mjerenje brzine projekta, moe se brojiti koliko korisni kih pri a (odjeljak 5.1.1) c c ili koliko programerskih zadataka je zavreno u iteraciji (odjeljak 5.1.5). Za vrijeme kreiranja plana isporuke, brzina projekta u zavrenim korisni kim pri ama c c moe biti koritena kako bi se procijenilo koliko jo korisni kih pri a moe biti dovreno c c do nekog vremena. Za vrijeme kreiranja plana iteracij, dozvoljeno je da programeri potpisuju isti broj procijenjenih dana za obavljanje programerskih zada a koji je jednak c brzini projekta mjerenoj u prethodnoj iteraciji. Brzina projekta se pove ava tako to se doputa programerima da pitaju naru itelja za c c neku drugu korisni ku pri u u slu aju da je njihov posao ranije zavren. c c c Prilikom odredivanja brzine projekta, o ekuju se pove anja i smanjenja brzine c c projekta tijekom trajanja projekta (oscilacije u vrijednostima). Ako se brzina projekta dramati no mijenja od predvidene u vie od jedne iteracije, potrebno je promijeniti c projektni plan isporuke (odjeljak 5.1.2). Tijekom stavljanja sustava u produkciju, takoder se moe o ekivati mijenjanje brzine projekta zbog pove anih zadataka odravanja. c c

28


Dijeljenje brzine projekta s duinom iteracije ili brojem programera nema ba smisla. Taj broj nije dobar pokazatelj pri usporedivanju produktivnosti dvaju projekata jer svaki projektni tm posjeduje razli ite sklonosti za procjenu pri a i zadataka; svaki tm c c procjenjuje razli ito (neki procjenjuju visoko a neki nisko) te svaki tm ima ipak razli it c c radni u inak. Pra enje cjelokupnog opsega posla obavljenog za vrijeme svake iteracije je c c klju za ravnomjerno optere en projekt. c c Problem sa svakim projektom je kreiranje inicijalnih procjena. Sakupljanje mnotva detalja ne cini inicijalnu promjenu nita drugo nego pogadanjem. Briga oko korektne procjene cijelog projekta je iznad kreiranja opsene dokumentacije. Slika (5.1) prikazuje utjecaj brzine projekta na planiranje u projektu. Brzina projekta utje e na odredivanje koliko ce korisni kih pri a biti implementirano u iteraciji. Kreiranje c c c novih korisni kih pri a mijenja planiranje isporuke na nivou citavog projekta i utje e na c c c donoenje novog plana isporuke. Slika (5.2) prikazuje utjecaj brzine projekta iz slijede e iteracije na planiranje iteracije. c U razvoju na brzinu projekta utje u u enje i komunikacija. Kreiranje novih korisni kih c c c pri a u razvoju utje e na brzinu projekta. c c

5.1.5

Iterativni razvoj

Iterativni razvoj (engl. Iterative Development) pove ava brzinu razvoja. Razvoj c softvera kod XP-a se moe podijeliti u raspored u oko desetak iteracija, a iteracija traje u prosjeku od jednog do tri tjedna. Poeljno je drati duinu iteracija konstantnom tijekom citavog projekta jer su iteracije zapravo ila kucavica projekta. XP adresira i paralelni razvoj. Ako je razvojni projekt razmjerno velik, tj. u njemu sudjeluje ve i broj osoba (npr. 30 do 40 programera), poeljno je podijeliti tim u dva c ili vie manjih timova. Svaki manji podtim (grupa) dobiva vlastite korisni ke pri e od c c naru itelja. Budu i da je osnovna ideja podjela korisni kih pri a na manje timove, u c c c c pravilu ne bi trebalo biti ve ih problema u sinkronizaciji medu grupama [3] [29]. c Nije dobro podijeliti programerske zada e (kodiranje) unaprijed. Umjesto toga, c potrebno je na initi plan iteracij i planirati iteracije na po etku svake od njih, kako bi c c se odredilo to ce se ciniti u trenutnoj iteraciji. Planiranje u trenutku (engl. just-in-time planning) je jednostavan na in za pra enje promjena korisni kih zahtjeva u projektu. c c c Takoder, nije preporu eno gledanje unaprijed i implementiranje onoga to nije prec dvideno u trenutnoj iteraciji. Bit ce dosta vremena za implementiranje te funkcionalnosti kada ona postane dio jedne od slijede ih korisni kih pri a u nekoj od slijede ih iteracija. c c c c Vano je da se ozbiljno shvate rokovi predvideni za implementaciju svake iteracije prate i napredak tijekom iteracije. U slu aju da je o ito da se ne mogu zavriti sve zada e, c c c c potrebno je izvriti novo planiranje iteracija, ponoviti procjene i smanjiti broj zadataka koji ulaze u iteracije. Potrebno je koncentrirati napore na zavravanje najvanijih (najprioritetnijih) zada a c koje je odredio naru itelj, umjesto da je slu aj da postoji nekoliko nedovrenih zadataka c c koje su po svom nahodenju izabrali programeri. 29

5.1 Planiranje razvoja softvera u ekstremnom programiranjuNova korisnika pria, Brzina projekta Plan isporukeKorisnike prie Nedovreni zadaci Plan iteracije Uenje i komunikacija Nova funkcionalnost

Slijedea iteracija Neispravnosti

Brzina projekta

Planiranje iteracije

RazvojPopravak neispravnosti Dan za danom

Zadnja verzija

Neuspjeli test prihvaenosti

Slika 5.2: Iteracija u ekstremnom programiranju

Ako se funkcionalnosti dodaju samo onda kada je odredeno da budu implementirane, te ako se prakticira planiranje, tada se i lake uhvatiti u kotac s promjenom korisni kih c zahtjeva. Slika (5.2) prikazuje razvoj iteracija u ekstremnom programiranju. U planiranje iteracija utje u korisni ke pri e koji su odredene u planu isporuke, brzina projekta kao c c c vrijednost koja se mijenja sa slijede im iteracijama, a ovisi o prethodnim iteracijama te c neispravnost testa prihva enosti softvera (engl. Failed Acceptance Test). c Usvojeni plan iteracija vodi u fazu razvoja. Problemi u fazi razvoja koji imaju za posljedicu nedovrene zada e (engl. Unnished Tasks) vode novom planiranju iteracija. c

5.1.6

Planiranje iteracija

Planiranje iteracije (engl. Iteration Planning) se vri na po etku svake iteracije te c ima cilj proizvesti plan izvravanja zada a koje ce se izvravati u toj iteraciji. Obi no je c c c svaka iteracija u duini od jednog do tri tjedna. Korisni ke pri e (odjeljak 5.1.1) naru itelj c c odabire za trenutnu iteraciju sukladno planu isporuke (odjeljak 5.1.2) u poretku kojeg sm vrednuje. Neispravnost testa prihva enosti softvera kojeg potvrduje naru itelj, a koji c c treba biti popravljen, je takoder povezan s planiranjem iteracije [28]. Naru itelj odabire c korisni ke pri e zajedno s procjenama o brzini projekta iz prethodne iteracije. c c Korisni ke pri e i testovi koji nisu proli provjeru ispravnosti se ubacuju kao c c programerske zada e u obliku novih korisni kih pri a. Dok su korisni ke pri e u jeziku c c c c c naru itelja, zadaci su u jeziku programera. Duplicirani zadaci mogu biti maknuti iz c iteracije. Razvijatelji potpisuju zadatke i procjenjuju koliko je potrebno da bi se ti zadaci kompletirali. Vano je za razvijatelje koji prihva aju zadatke da oni budu ti koji ce c procijeniti kraj zadatka. Unutar XP-a ne preporu a se zamjena ljudi koji sudjeluju na c razvoju. Odredena osoba koja ce implementirati zadatak mora procijeniti koliko dugo ce trajati implementacija. Svaka zada a treba biti u trajanju od jednog do tri idealna programerska dana. Idealni c programerski dan zna i koliko dugo je potrebno da bi se zavrio zadatak u slu aju da c c nema nikakvih smetnji (dodatnih zadataka) sa strane. Zadaci koji su kra i od jednog dana c 30


mogu se zajedno grupirati. Zadaci koji su pak dui od tri dana trebaju biti razbijeni u vie manjih zadataka. Brzina projekta (odjeljak 5.1.4) je koritena kako bi se odredilo da li je iteracija preoptere ena i rezervirana ili nije. Cjelokupna vremenska procjena u idealnim programerskim c danima ne bi smjela premaiti brzinu projekta iz prethodne iteracije. Ako iteracija sadri previe korisni kih pri a, naru itelj treba odabrati pri e (na osnovi prioriteta) koji moraju c c c c biti maknute sve do slijede e iteracije. c U slu aju da iteracija sadri premalo korisni kih pri a, tada ih moe biti prihva eno c c c c jo. Brzina izraena u danima potrebnim za implementaciju zadataka je s vremenom vjerniji podatak od brzine izraene u tjednima potrebnim za implementaciju korisni kih c pri a. c Cesto je alarmantno vidjeti korisni ke pri e koje su proptere ene time to su preopc c c irne za implementaciju. Treba imati u vidu vanost jedini nog testiranja i tehnike rec faktoriranja (engl. Refactoring) (odjeljak 5.2.6). Unutar XP-a se naglaava da nedovoljno posve ivanje panje tim podru jima ce uzrokovati usporavanje u projektu. Prema tome, c c poeljno je izbjegavati dodavanje novih funkcionalnosti prije nego su te funkcionalnosti po rasporedu za implementaciju, ina e nastupaju zakanjenja u projektu. c Kao to je ve ranije re eno, nije pametno mijenjati procjene zadataka i korisni kih c c c pri a. Proces planiranja lei na realnosti dosljednih procjena, mijenjanje (smanjivanje) tih c procjena uzrokuje kasnije vie problema. Panju, dakle, treba posvetiti brzini projekta

Documents

metode projektovanja