arhivadlwms

DokumentPredavanja Ivan Boban

MPP - P5 - Metode razvoja softvera - 2026/2027

Tekst dokumenta251 redova
  1. Ivan Boban, dr.sc.
  2. Tradicionalne i agilne metode
  3. razvoja softvera
  4. Sadržaj
  5. Životni ciklus razvoja softvera
  6. Tradicionalne metode
  7. ▪Agilne metode
  8. Životni ciklus razvoja softvera
  9. ▪Životni ciklus razvoja softvera (SDLC – System Development Life Cycle) opisuje „životni
  10. vijek“ od nastanka potrebe za softverom, preko implementacije, održavanja, pa sve
  11. dok se ne prestane koristiti.
  12. ▪Model procesa razvoja softvera definira redoslijed razvojnih faza.
  13. ▪Postoji više varijanti SDLC-a, a to su:
  14. ✓Tradicionalni linearni (sekvencijalni) “vodopadni” (eng. “waterfall”)
  15. ✓Paralelni model,
  16. ✓Iterativni model ili evolucijski model,
  17. ✓Spiralni model,
  18. ✓Agilne metode itd.
  19. Vodopadni model
  20. ▪Model vodopada poznat je i kao model životnog ciklusa razvoja softvera.
  21. ▪Bio je to prvi procesni model uveden kao linearno-sekvencijalni model životnog
  22. ciklusa.
  23. ▪Model vodopada jednostavno govori fenomenu da se jedna faza u potpunosti završi
  24. prije započinjanja nove faze razvoja, tako da ne postoji preklapanje faza.
  25. Faktori vodopadnog modela
  26. ✓U prijavi nema dvosmislenih zahtjeva.
  27. ✓Stabilnost definicije proizvoda
  28. ✓Nije dinamičan
  29. ✓Na raspolaganju su veliki resursi s odgovarajućom stručnošću kako bi podržali
  30. proizvod
  31. ✓Projekt kratke duljine
  32. ✓Dobar dokument, jasni i fiksni zahtjevi.
  33. Faktori vodopadnog modela
  34. ▪Pri korištenju sekvencijalnih metodologija razvoja analitičar sistema i članovi
  35. razvojnog tima napreduju sekvencijalno od jedne do druge faze projekta. Svaka faza
  36. se u cijelosti završi i potom se prelazi na sljedeću fazu. Nije uobičajeno vraćati se na
  37. prethodnu fazu.
  38. ▪Prednosti:
  39. • Unaprijed identifikovani zahtjevi (prije početka razvoja)
  40. • Promjene u zahtjevima su minimalne
  41. ▪Nedostaci:
  42. • Dizajn mora biti u potpunosti završen prije početka implementacije
  43. • Vrijeme provedeno na svakoj od faza
  44. Paralelni pristup
  45. ▪Metodologija paralelnog razvoja nastoji smanjiti vrijeme između faze analize i
  46. isporuke softverskog proizvoda. Prvo se napravi dizajn cjelokupnog proizvoda, a zatim
  47. se projekt dijeli na više podprojekata. Svi podprojekti, ukoliko ne postoji međusobna
  48. ovisnost među njima, se realiziraju paralelno. Rezultati svakog od podprojekata potom
  49. se integriraju u jednu cjelinu, projekt.
  50. ▪Prednosti:
  51. • Znatno se smanjuje vrijeme razvoja
  52. • Manje su šanse za prepravke
  53. ▪Nedostaci:
  54. • Potrebno više resursa
  55. • Ponekad je teško integrirati podprojekte
  56. Iterativni pristup
  57. ▪Iterativni ili evolucijski model je model u kojem korištenje softverskog proizvoda
  58. mijenja perspektivu korisnika u odnosu na softverski proizvod. Svaka promjena
  59. perspektive može rezultirati generiranjem novih korisničkih zahtjeva. Na taj način
  60. softverski proizvod raste zajedno sa organizacijom u kojoj se koristi. Ovakav pristup
  61. razvoja podrazumijeva brzo prototipiranje, odnosno, gradnju dijelova softverskog
  62. proizvoda u inkrementima.
  63. ▪Prednosti:
  64. • Softver se proizvodi u ranim fazama životnog ciklusa
  65. • Korisnici u ranim fazama probaju rezultate
  66. • Pojednostavljeno testiranje
  67. ▪Nedostaci:
  68. • Izmjene zahtjeva
  69. • Duže vrijeme razvoja
  70. Spiralni model
  71. ▪Na početku svake faze radi se analiza rizika i nastoje se utvrditi mogući rizici. Cilj
  72. analize rizika je eliminirati rizike ili barem ih svesti na najmanju moguću mjeru. Ako je
  73. rizik nastavka projekta prevelik, tada se projekat prekida.
  74. ▪Faze spiralnog modela su:
  75. • Analiza rizika i procjena alternativa
  76. • Razvoj i verifikacija sljedećeg "proizvoda„
  77. • Planiranje sljedeće faze
  78. • Pregled - Određivanje ciljeva, alternativa i ograničenja.
  79. ▪Prednosti
  80. • Visok stepen analize rizika
  81. • Softver se proizvodi u ranim fazama životnog ciklusa
  82. Spiralni model
  83. ▪Nedostaci
  84. • Može biti veoma skup model
  85. • Zahtjeva visok stepen ekspertize u analizi rizika
  86. • Nije dobar za male projekte
  87. Inkrementalni model
  88. ▪Model inkrementalnog procesa također je poznat kao model sukcesivne verzije.
  89. ▪Najprije se izgradi jednostavan radni sustav koji implementira samo nekoliko osnovnih
  90. značajki, a zatim se isporučuje kupcu. Zatim se nakon toga mnoge uzastopne
  91. iteracije/verzije implementiraju i isporučuju kupcu dok se željeni sustav ne pusti u
  92. promet.
  93. AGILNE METODE
  94. ▪Scrum
  95. ▪Kanban
  96. ▪Extreme Programming (“XP”)
  97. ▪Lean Development
  98. ▪Crystal
  99. Scrum
  100. ▪Scrum je najčešće korišteni od mnogih okvira koji podupiru Agile metodologiju.
  101. ▪Scrum karakteriziraju ciklusi ili faze razvoja, poznati kao sprintovi i maksimiziranje
  102. vremena razvoja za softverski proizvod.
  103. ▪Obično se koristi u upravljanju razvojem softverskih proizvoda, ali se može uspješno
  104. koristiti u poslovnom kontekstu.
  105. ▪Svaki dan počinje malim 15-minutnim sastankom, dnevnim Scrumom, koji preuzima
  106. ulogu sinkronizacije aktivnosti i pronalaženja najboljeg načina za planiranje radnog
  107. dana.
  108. Scrum
  109. PREDNOSTI
  110. ▪Motivacija tima je dobra jer programeri žele ispuniti rok za svaki sprint;
  111. ▪Transparentnost omogućuje da projekt prate svi članovi u timu ili čak u cijeloj
  112. organizaciji;
  113. ▪Za provjeru valjanosti zahtjeva koristi se jednostavna "definicija gotovog";
  114. ▪Usredotočenost na kvalitetu je konstanta kod scrum metode, što rezultira s manje
  115. pogrešaka;
  116. ▪Dinamika ove metode omogućuje programerima da reorganiziraju prioritete,
  117. osiguravajući da sprintovi koji još nisu dovršeni dobiju više pažnje;
  118. ▪Dobro planiranje sprinta ima prioritet;
  119. Scrum
  120. NEDOSTACI
  121. ▪Segmentacija projekta i potraga za agilnošću razvoja ponekad može dovesti do toga da
  122. tim izgubi pojam o projektu kao cjelini, fokusirajući se na jedan dio;
  123. ▪Svaka uloga razvojnog programera možda nije dobro definirana, što može dovesti do
  124. zabune među članovima tima.
  125. Kanban
  126. U praksi, Kanban metoda organizirana je na ploči ili tablici (Kanban ploča), podijeljenoj u
  127. stupce, prikazujući svaki tijek unutar projekta proizvodnje softvera. Kako se razvoj
  128. razvija, informacije sadržane u tablici se mijenjaju, a svaki put kada novi zadatak dođe u
  129. igru, stvara se nova "kartica".
  130. Ova metodologija također je korisna u pojedinačnim poslovnim odjelima, kao što su HR,
  131. marketing itd., donoseći željenu vidljivost nad svim zadacima tima.
  132. Kanban metoda zahtijeva komunikaciju i transparentnost tako da svi članovi bilo kojeg
  133. tima znaju točno u kojoj je fazi razvoja i mogu vidjeti status projekta u bilo kojem
  134. trenutku. Prvenstveno je usmjeren na kapacitet tima i najbolji je za procese koji prolaze
  135. kroz male promjene.
  136. Kanban
  137. PREDNOSTI
  138. ▪Mogućnost pregleda svih zadataka u okviru jednog projekta;
  139. ▪Možete ograničiti broj pokrenutih zadataka
  140. ▪Fokusira se na trajanje ciklusa;
  141. ▪Omogućuje kontinuirane isporuke;
  142. ▪Vjerojatno jedna od najjednostavnijih metodologija za implementaciju izvan “IT
  143. svijeta”.
  144. Kanban
  145. NEDOSTACI
  146. ▪Moguće je da članovi tima pogrešno protumače informacije prikazane na Kanban
  147. ploči, posebno kada su prikazane kao zastarjele;
  148. ▪Budući da u Kanbanu nema vremenskih okvira, možete se suočiti s problemima
  149. povezanim s vremenom, poput kašnjenja, u svakoj fazi.
  150. Ekstremno programiranje (XP)
  151. ▪Metodologija ekstremnog programiranja (“XP”) temelji se na ideji otkrivanja
  152. “najjednostavnije stvari koja će raditi” bez stavljanja prevelike težine na dugoročni
  153. pogled na proizvod.
  154. ▪To je metodologija koja naglašava vrijednosti kao što su komunikacija, jednostavnost,
  155. povratne informacije, hrabrost i poštovanje te daje prednost zadovoljstvu korisnika
  156. nad svim ostalim. Ova metodologija potiče povjerenje motivirajući programere da
  157. prihvate promjene u zahtjevima korisnika, čak i ako one stignu tijekom kasnijih faza
  158. razvojnog ciklusa.
  159. Ekstremno programiranje (XP)
  160. ▪Timski rad iznimno je važan u XP-u, budući da, kada postoji problem, rješava ga cijeli
  161. tim menadžera, programera ili kupaca, okupljajući ih kako bi promovirali razgovor i
  162. angažman i razbili prepreke u komunikaciji. Svi oni postaju ključni dijelovi iste
  163. slagalice, stvarajući plodno okruženje za visoku produktivnost i učinkovitost unutar
  164. timova.
  165. ▪Softver se testira od prvog dana, prikupljajući povratne informacije za poboljšanje
  166. razvoja. XP promiče aktivnosti kao što je programiranje u paru, a uz jaku komponentu
  167. testiranja izvrsna je inženjerska metodologija.
  168. Ekstremno programiranje (XP)
  169. PREDNOSTI
  170. • Jednostavnost pisanog koda je prednost jer omogućuje poboljšanje u bilo kojem
  171. trenutku;
  172. • Cijeli proces i razvojni ciklus XP-a je vidljiv, stvarajući ciljeve za programere uz
  173. relativno brze rezultate;
  174. • Razvoj softvera je agilniji nego kod korištenja drugih metodologija, zbog stalnog
  175. testiranja;
  176. • Promiče visoki tempo rada;
  177. • XP također doprinosi podizanju i održavanju timskog talenta.
  178. Ekstremno programiranje (XP)
  179. NEDOSTACI
  180. • Ekstremna usredotočenost na kod može dovesti do toga da se manje važnosti pridaje
  181. dizajnu, što znači da mu se kasnije mora posvetiti dodatna pozornost;
  182. • Ovaj okvir možda neće raditi najbolje ako se svi članovi tima ne nalaze na istom
  183. geografskom području;
  184. • U XP projektima, registar mogućih grešaka se ne održava uvijek, a ovaj nedostatak
  185. praćenja može dovesti do sličnih grešaka u budućnosti.
  186. Lean metoda
  187. Lean razvoj tjera tim da ukloni sve aktivnosti koje ne donose konačnu vrijednost
  188. proizvodu.
  189. Postoji sedam osnovnih načela:
  190. ✓brisanje stvari koje nisu bitne (sve što ne donosi učinkovitu vrijednost projektu kupca);
  191. ✓razvoj kvalitete (stvaranje kvalitete u razvoju zahtijeva disciplinu i kontrolu broja
  192. stvorenih ostataka);
  193. ✓stvaranje znanja (tim je motiviran dokumentirati cijelu infrastrukturu kako bi kasnije
  194. zadržao tu vrijednost);
  195. ✓različite obveze (ova točka potiče tim da se ne fokusira previše na planiranje i
  196. predviđanje ideja bez potpunog prethodnog razumijevanja zahtjeva poslovanja);
  197. Lean metoda
  198. ✓brza isporuka (dobiti vrijednost kupcu što je prije moguće);
  199. ✓poštivanje tima (komunikacija i upravljanje sukobima dvije su bitne točke);
  200. ✓optimizirati cjelinu (slijed razvoja mora biti dovoljno usavršen da se mogu brisati
  201. greške u kodu,
  202. Crystal
  203. ▪Crystal je jedan od najfleksibilnijih okvira koji daje ogromnu slobodu timu da razvija
  204. vlastite procese. Više se usredotočuje na pojedince i način na koji oni međusobno
  205. djeluju, a ne na proces ili alate – stoga je komunikacija ključni aspekt.
  206. ▪Crystal ima varijante kao što su Crystal Clear (do 8 članova tima), Crystal Yellow (do 10
  207. do 20 članova tima), Crystal Orange (do 20 do 50 članova tima) i Crystal Red (za velike
  208. timovi od 50 do 1000 ljudi).
  209. ▪Crystal se fokusira na principe kao što su ljudi, interakcije, zajednica, vještine, talent i
  210. komunikacija, s ciljem pružanja najboljeg mogućeg procesa razvoja softvera. Srž ovog
  211. razvojnog procesa je interakcija i simbioza, koji moraju postojati između ljudi koji su
  212. dodijeljeni projektima i procesima kako bi projekt bio učinkovit.
  213. Crystal
  214. ▪Svaki projekt je jedinstven i prolazi kroz česte promjene, tako da tim mora pronaći
  215. vlastite načine da ga dovede do kraja koristeći najbolje odluke.
  216. ▪To je lagana metodologija u smislu dokumentacije, gdje timovi mogu pronaći vlastite
  217. načine umjesto preferiranih modaliteta rada.
  218. Hvala na pažnji!
na vrh