Programų sistemų gyvavimo ciklo modeliai

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.)

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

Istorija 1950 - Code-and-fix model 1956 - Stagewise model (Bengington ) 1970 - Waterfall model (Royce) 1971 - Incremental model (Mills) 1977 - Prototyping model (Bally and others) 1988 - Spiral model (Boehm)

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.

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“!

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

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.

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.

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.

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

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)

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.

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.

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).

Spiralinis modelis

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ą

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ą.

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 http://greenbay.usc.edu/csci577/fall2012/uploads/readings/ep/What_is_ICSM.pdf

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

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

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ą

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ą

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.

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

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

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

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.

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.

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

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

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

Modifikacijos ir kombinacijos Literatūra: Visual Explanation of Models

Modifikacijos ir kombinacijos Literatūra: Visual Explanation of Models

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

How Successful are different software development paradigms?

How Successful are different software development paradigms?

How Successful are different software development paradigms?

How Successful are different software development paradigms?

How Successful are different software development paradigms?

Inkrementinis vs. iteratyvus Nukosėta iš http://www.slideshare.net/peterantman/user- story-workshop-39391611

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