1. Programų sistemų gyvavimo ciklo modeliai

2. Programų sistemos gyvavimo ciklo modelis
Apibrėžia:
Programinės įrangos kūrimo ir plėtros etapų seką
Perėjimo iš vieno etapo į kitą kriterijus
Atsako į du pagrindinius klausimus:
Ką turime daryti toliau?
Kiek ilgai tai turime daryti?
Proceso modelis nėra programų kūrimo metodas
Pagrindinė gyvavimo ciklo (proceso) modelio paskirtis – apibrėžti programinės įrangos kūrimo ir plėtros etapų seką bei nustatyti kriterijus perėjimui iš vieno etapo į kitą.
Kriterijai apima vieno etapo užbaigimo kriterijus ir kito etapo pradžios kriterijus, tai yra – kas turi būti atlikta (pasiekta), kad etapas galėtų būti laikomas baigtu ir kokių įeičių reikia, kad kitas etapas galėtų prasidėti.
Programų kūrimo metodo fokusas – kaip įvykdyti kiekvieną fazę (nustatant duomenis, valdymo ar „panaudojimo“ hierarchijas; dekomponuojant funkcijas; priskiriant reikalavimus) ir kaip apiforminti kiekvienos fazės darbo produktus (struktūrinėmis diagramomis; būsenų diagramomis ir pan.)

3. Kokius gyvavimo ciklo modelius žinote?
Krioklys
Spiralinis
Inkrementinis
...

4. Istorija 1950 - Code-and-fix model
Stagewise model (Bengington )
Waterfall model (Royce)
Incremental model (Mills)
Prototyping model (Bally and others)
Spiral model (Boehm)

5. Waterfall
Waterfall kaip sąvoka (ir kaip siūlomas IS įgyvendinimo būdas) atsirado iš Winston W. Royce straipsnio
Pats W.W.Royce apie Waterfall sakė, kad jį ne taip suprato, o jo paties nuomonė yra: „I believe in this concept, but the implementation described above is risky and invites failure.“ (iš to paties straipsnio)
O tapo įteisintas dėl žmogiško poreikio turėti lengvai suprantamą (racionalų) sprendimą:
vs.

6. Waterfall „Klasikinis“ modelis
Intuityvus, „sveiku protu pagrįstas“ modelis
Ar tikrai?
Klasikinis – ne tobulumo, kaip graikų klasikinės skulptūros, o įprastumo prasme
Sveiku protu grįstas – greičiau intuityviai sukonstruotas pagal tuo metu įprastą didelės sistemos gyvavimo ciklą
Abejokite ir kvestionuokite ginčykite tai, kas atrodo intuityvu arba „visi taip daro“, arba „visi sako, kad taip reikia daryti“!

7. Krioklio gyvavimo ciklo seka
Fazės darbo rezultatas
„Plaukimas prieš srovę“ – grįžimai
Įprastinė nuostata – fazės nepersidengia, o fazės veiklos pradedamos vykdyti pabaigus ir parašais patvirtinus ankstesnės fazės rezultatus
Laikas

8. Privalumai Lengva suprasti ir pradėti naudoti.
Plačiai naudojamas ir žinomas (teoriškai)
Įtvirtina teisingus įpročius: apibrėžimą prieš projektavimą, projektavimą prieš kodavimą
Nustato pateiktis ir tarpinius taškus
Įtvirtina dokumentavimą visos veiklos metu, egzistuoja dokumentų standartai.
Gerai veikia ir brandiems produktams, ir silpnoms komandoms.

9. Trūkumai Idealizuotas ir neatitinkantis realybės.
Neatspindi iteratyvios tiriančiojo kūrimo (exploratory development) prigimties.
Pagristas nerealistišku tikėjimu apie galutinius reikalavimus projekto pradžioje
Programinė įranga pateikiama gale projekto, taip pavėlinant jos teikiamą naudą (finansinis trūkumas!) ir rimtas klaidas atrandant tik gale.

10. Trūkumai (2) Sudėtinga integruoti rizikų valdymą
Sudėtinga (daug darbo) daryti pakeitimus dokumentuose ir tokiu būdu atlikti „grįžimus prieš srovę“ pagal procesą.
Dideli administraciniai kaštai, per brangūs mažoms komandoms.

11. Code-and-Fix / Hakinimas
Neformali pradinio produkto idėja
Hakinam, kol gauname maždaug tinkamą produktą (arba baigiasi laikas arba pinigai)
Jokio planavimo

12. Privalumai Jokių administravimo kaštų Progresas matomas anksti.
Nereikia modelio žinių ar patirties – bet kas gali taip dirbti!
Naudingas mažiems bandomiesiems (proof of concept) projektams, gali būti naudojamas kaip rizikos valdymo pratimas (architectural spike)

13. Trūkumai Pavojingas! Nėra kontrolės Nėra planavimo Nėra terminų
Klaidas sudėtinga pastebėti ir pataisyti
Netinkamas dideliems projektams dėl komunikacijų ribojimų, chaotiškumu.

14. Spiralinis modelis
Kadangi reikalavimus sudėtinga surinkti, galima būtų kurti programinę įrangą eksperimentavimo keliu:
1. Implementuoti kažkiek kodo (PĮ)
2. Tikrinti, ar tenkina visus reikalavimus
3. Jei ne, kartoti nuo 1, kitaip baigti.

15. Spiralinis modelis
1988 B. Boehm sukūrė spiralinį modelį kaip iteratyvųjį modelį, kuriame įdėta rizikos analizė ir rizikos valdymas
Esminė idėja: kiekvienoje iteracijoje identifikuoti ir išspręsti didžiausio rizikos laipsnio sub-problemas (uždavinius).

16. Spiralinis modelis

17. Spiralinis modelis Kiekviename cikle įvykdomas krioklys:
Nustatyti iteracijos tikslus
Apibrėžti apribojimus
Sugeneruoti alternatyvas
Identifikuoti rizikos veiksnius
Suvaldyti rizikos veiksnius
Implementuoti sekantį produkto lygį
Suplanuoti sekantį ciklą

18. Privalumai
Realistiškumas: modelis tiksliai atspindi iteratyvią programų kūrimo projektų su neaiškiais reikalavimais prigimtį
Inkorporuoja krioklio ir greitojo prototipavimo privalumus
Išsamus modelis leidžia geriau valdyti (mažinti) riziką
Leidžia gerą projekto matomumą.

19. Trūkumai
Reikalauja techninių kompetencijų, kad realiai veiktų rizikos valdymas
Netechniniai vadovai prastai supranta modelį, todėl nėra plačiai naudojamas
Sudėtingas modelis, reikalaujantis kompetentingų profesionalių vadovų. Iš to ir dideli administravimo kaštai.
B. Boehm papildytas modelis: The Incremental Commitment Spiral Model

20. Greitasis prototipavimas
Esminė idėja: Užsakovai yra netechniniai žmonės, kurie dažnai nežino, ko nori ar gali gauti.
Greitasis prototipavimas (Rapid prototyping) fokusuojasi į reikalavimų analizę ir validavimą
Dar sutinkami pavadinimai:
customer oriented development,
evolutionary prototyping

21. Greitasis prototipavimas
Reikalavimų surinkimas
Greitas projektavimas
Kartoti kiek reikia
Prototipo kūrimas
Prototipo peržiūra su užsakovu
Galutinio produkto kūrimas

22. Privalumai
Minimizuoja nekorektiškų reikalavimų tikimybę ir su tuo susijusią riziką
Labai tinkamas, kai reikalavimai kinta ar nėra patvirtinti
Reguliarus matomas progresas padeda valdyti projektą
Padeda anksti pardavinėti (marketinguoti) produktą

23. Trūkumai
Nestabilus ar prastai realizuotas prototipas linkęs virsti galutiniu produktu.
Reikalauja nuolatinio ir intensyvaus užsakovo bendradarbiavimo:
Kainuoja užsakovui pinigus
Reikalauja pasišventusių užsakovų
Sudėtinga pabaigti, jei užsakovas pasitraukia
Gali būti pernelyg specifiškas vienam užsakovui, duoda neuniversalų produktą

24. Trūkumai (2) Sudėtinga numatyti, kiek truks projektas
Lengva degraduoti į hakinimo procesą, jeigu tik neužtikrinami tinkamas reikalavimų analizė, projektavimas, užsakovo grįžtamojo ryšio gavimas.

25. Judrusis programavimas (Agile)
Agile manifesto:
Individuals and interactions over processes and tools
Working software over documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

26. Pagrindiniai principai
Nuolatinis programinės įrangos implementavimas ir pateikimas
Nuolatinis bendradarbiavimas su užsakovu
Nuolatinis reagavimas į pasikeitimus
Bendradarbiavimas svarbu
Kodas rašomas paprastai, kad atitiktų tik specifikaciją, bet nieko daugiau

27. Pranašumai Lengvas metodas, tinkamas mažiems ir vidutiniams projektams
Užtikrina gerą komandos bendradarbiavimą
Orientuotas į galutinį veikiantį produktą
Iteratyvus
Pagrįstas reikalavimų, tinkamų testavimui, rinkimu ir nuolatiniu kokybės užtikrinimu

28. Trūkumai Sudėtinga išplėsti dideliems projektams
Reikalauja kompetencijos, kad nedegraduotų į hakinimą
Programavimas poromis (XP) brangus
Sudėtinga konstruoti automatizuotus testus, reikalingi specifiniai įgūdžiai.

29. COTS COTS = Commercial of the Shelf
Principas: minimaliomis priemonėmis „suklijuoti“ veikiantį sprendimą iš egzistuojančių komercinių (arba ne) programinės įrangos paketų
Duomenų bazės, elektroninės lentelės, teksto procesoriai, web portalai ir turinio valdymo sistemos, ir pan.

30. Privalumai Pigus, greitas sprendimas, leidžiantis nuolatinę evoliuciją
Gali duoti visą reikalingą bazinį funkcionalumą
Gerai apibrėžtas projektas, lengva vykdyti

31. Trūkumai Gaunamas ribotas funkcionalumas
Shareware, freeware, open source, komercinių produktų licencijavimo iššūkiai
Licencijų mokesčiai
Sudėtingas naujinimas ir paketų versijų kėlimas

32. Apibendrinimas Sistemų gyvavimo ciklų tipai pagal struktūrą:
Nuoseklusis
Evoliucinis
Inkrementinis
Chaotiškas (ad-hoc)

33. Modifikacijos ir kombinacijos
Literatūra: Visual Explanation of Models

34. Modifikacijos ir kombinacijos
Literatūra: Visual Explanation of Models

35. Proceso modelių praktinė sėkmė
Tik nuomonė / iliustracija, bet jokiu būdu ne bendru atveju teisingas įvertinimas!

36. How Successful are different software development paradigms?

37. How Successful are different software development paradigms?

38. How Successful are different software development paradigms?

39. How Successful are different software development paradigms?

40. How Successful are different software development paradigms?

41. Inkrementinis vs. iteratyvus
Nukosėta iš story-workshop

42. Incremental Release Strategy Minimal Viable Release
Big Product Idea
Incremental Release Strategy
Minimal Viable Release
Product Backlog built from small stories