Programų inžinerijos srityje daugiausia dėmesio skiriama programinės įrangos sukūrimui. Tačiau neretai pamirštama, kad kiekvienos tinkamai ar netinkamai sukurtos programinės įrangos tolimesnis gyvavimas priklauso nuo programinės įrangos priežiūros procesų, jų modelių ir taikymo praktikoje. Nei viena sistema, posistemė, mobilioji aplikacija ar paprasta interneto svetainė, el. parduotuvė neapsieina be tolimesnės priežiūros, kuri gali būti įvairi nuo klaidų taisymo, naujo funkcionalumo taikymo iki integravimo su trečiosiomis šalimis ar sąsajomis – visi šie veiksmai atliekami jau sukurtos programinės įrangos priežiūros metu.
Net ir paprastos sistemos šiais laikais tampa neatsiejama verslo ir įmonių dalimi, todėl jų tęstinumui vis daugiau skiriama dėmesio, laiko, kaštų ir žmogiškųjų išteklių. Žiniasklaidoje ne kartą yra pasakota ir rašyta apie didžiulius nuostolius patiriamus dėl sistemų sutrikimų ar netinkamos jų priežiūros, ypač tai aktualu didesnės rizikos verslams, pavyzdžiui, draudimas, bankai, mokėjimų sistemos, gyvybės palaikymo aparatai ir panašios sistemos.
Šiame straipsnyje aptariami programinės įrangos priežiūros procesai ir modeliai, informacija padės specialistui pasirinkti tinkamą modelį, susipažinti su jais, įvertinti ir pasirinkti tinkamą savo taikymo srityje.
Straipsnyje aptariami ir modelių procesai. Kadangi galima rasti daug pakankamai skirtingų priežiūros modelių, kiekvienas jų turi savo procesus, kurie gali skirtis iš esmės arba tik dalinai, pavyzdžiui, lyginant standartinius krioklio tipo ir inkrementinio tipo modelius, jų procesai yra skirtingi.
Programų inžinerijoje PĮ priežiūra – tai PĮ patobulinimas ir optimizavimas, naujos versijos įdiegimas bei defektų šalinimas.
Programinės įrangos priežiūros dalis dažniausiai būna tik pasibaigus ir jau sukūrus pačią sistemą ar posistemę. Tiek Krioklio tipo modelyje, tiek Spiraliniame modelyje priežiūra užima paskutinę dalį programų inžinerijoje, tačiau šis etapas sudaro kartais net iki 70 % sistemos gyvavimo ciklo apimčių bei sunaudoja daugiau kaštų (laiko ir finansinių) nei kad pats sistemos sukūrimas ir testavimas bei atestavimas.
Programinės įrangos priežiūra apima: klaidų taisymą, sistemos architektūros tobulinimą, modernizavimą (naujoms technologijoms pasirodžius), sąsajas tarp įvairių trečiųjų šalių sistemų ir posistemių, adaptavimą skirtingoms terpėms (mobiliosios ar operacinės sistemos, platformos).
Pati programinės įrangos priežiūra turi užtikrinti ir kontroliuoti programinės įrangos funkcionalumą, naudojamų funkcijų tobulinimą, apsaugojimą nuo darbo trukdžių ar neefektyvaus darbo.
ISO/IEC 14764 programinės įrangos priežiūros standarte priežiūra skirstoma į keturias pagrindines kategorijas:
Procesas – veiksmų seka, skirta tam tikram pakeitimui atlikti (angl. the progress or course taken, methods of operation, a series of actions taken to effect a change). PĮ priežiūros procesas – veiksmų seka skirta atlikti keitimus sistemą prižiūrint.
Priežiūros procesai, kaip ir visos kitos programų inžinerijos sritys, yra standartalizuojami, kad būtų laikomasi vienodos įgyvendinimo praktikos, atrenkami geriausi ir labiausiai pasiteisinę sprendimai bei būtų juos paprasčiau taikyti tiesiog šabloniškai. Čia galima rasti labai daug bendrų sąsajų su programinės įrangos kūrimo procesais, kuriuos kai kuriuos galima taip pat pritaikyti ir priežiūrai.
Pagal ISO/IEC 14764 standartą priežiūros procesas pavaizduotas žemiau esančiame paveikslėlyje:
Programų priežiūros modeliai buvo kuriami kartu ir su programinės įrangos kūrimo modeliai bei evoliucionavo kartu su visa kompiuterijos mokslo evoliucija. Nors programinės įrangos studijų sritis yra naujesnė už projektavimo sritį, vis dėlto proceso gyvavimo ciklo modeliai buvo tobulinami jau žinant pačius projektavimo modelius ir jų įtaka buvo neišvengiama priežiūros modelių kūrimui ir taikymui bei adaptavimui.
Tai yra vadinamas ad hoc (nesuplanuotas) modelis, neformalizuotas ir susideda tik iš 2 etapų: rašyti kodą ir taisyti kodą. Dažniausiai toks principas taikomas tuomet, kai nėra iš anksto apibrėžtų tikslių funkcinių reikalavimų, nes jie atliekami ir peržiūrimi, po kiekvienos „code-and-fix“ iteracijos.
Šis modelis sukuria galimybę labai nekokybiškai kodui sistemoje atsirasti, nes kūrimo ir naujos funkcijos pridėjimo metu nėra galvojama apie tolimesnius žingsnius (nėra funkcinių reikalavimų), kas gali pabranginti sistemos palaikymo kaštus ir pačią sistemą. Modelis nesuteikia laisvės analizuoti ir pritaikyti projektavimo aspektus ar struktūrizuoti kodą.
Modelis dažniausiai taikomas tik ypač mažiems projektams, nes jis praktiškai nepritaikomas (sukelia aibę problemų, neefektyvus, neprotingas) bet kokiam didesniam projektui, kuriame reikia išankstinio apmąstymo ir detalizavimo.
Tačiau šis modelis suteikia galimybę kurti sistemą su mažai žinių (angl. expertise) bei nėra papildomų derinimų ar iš ankstinio aptarimo.
Krioklio modelis paremtas ciklais iš sudedamųjų dalių, kurios yra: reikalavimų surinkimas ir analizė, projektavimas, realizavimas, testavimas ir priežiūra (naudojimas).
Šio modeliu didelis darbas skiriamas analizei bei pačių reikalavimų surinkimui ir specifikacijai, tačiau modelis nuostolingas tuo, kad pagal naujausias kuriamas tendencijas (plintantį Agile metodą projektavime) labai sunku iš anksto įvertinti ir nuspręsti visus funkcinius ir nefunkcinius reikalavimus. Taip pat patys užsakovai ar klientai nemoka ar nesugeba tinkamai suformuoti užduočių ir perduoti jų analitikams ar programuotojams, nors galbūt ir žino, įsivaizduoja, kaip turėtų funkcionalumas veikti.
Tokio modelio naudojimo metu daroma prielaida, kad tam tikras etapas baigsis be klaidų, kas iš esmės realioje praktikoje yra nerealu. Radus klaidą ar netinkamą reikalavimą procesas turi prasidėti iš naujo, o testavimas projekto pabaigoje sukelia daug problemų ypač kai klaidų ir atestavimo metu rastų neatitikimų randama daug.
Didžiausias trūkumas tokio modelio naudojimo šiais laikais yra tas, kad sistema paleidžiama veikti tik tuomet, kai visas produktas yra atliktas ir pabaigtas iki galo. Tai dažnai gali būti per vėlu (rinkos konkurentai), pabranginti kaštus bei atidėti paleidimo laiką (vis atsirandančios klaidos ar papildomi reikalavimai pradeda procesą iš naujo).
Tačiau modelis tinkamas tuomet klientas puikiai žino, ko tikėtis iš sistemos, kaip ji veiks, taip pat suvokia ir mato galutinę kainą ir preliminarius terminus. Klientui šis modelis tinkamas tuo, kad nesudėtinga pakeisti vykdytoja (priežiūros proceso), tinkamas ir puikiai panaudojamas mažesniuose projektuose, kur reikalavimų apimti sąlyginai nedidelė ar žinoma iš anksto bei visas procesas yra dokumentuojamas ir konflikto metu paprasčiau išspręsti problemas.
Lengvai pritaikomas modelis dažnai laimi prieš sudėtingesnius modelius aptariamus toliau.
Spiralinis modelis pavadintas taip dėl jo bruožų panašumo į spiralę ir tai yra modelis paremtas rizikos vertinimu bei konkrečiomis konkretaus projekto ar sistemos rizikomis. Modelis primena inkrementinį modelį, tačiau čia daugiau dėmesio skiriama pačioms rizikomis.
Modelis dažniausiai turi griežtus laiko ribojimus, kas sunkina tinkamą rizikos vertinimą. Rizika gali būti skiriamas laikas testavimui (jei norima greičiau paleisti projektą), numatytos paleidimo datos ir pan.
Kiekviena tolimesnė iteracija yra kuriama ar palaikoma lyginant ją su buvusiomis ir atsispiriant nuo jau atliktos iteracijos.
Tai yra krioklio modelio sujungimas į iteracijas, kur kiekviena veikianti projekto dalis yra iteracija, pavyzdžiui, pirmoji iteracija būtų bazinis produktas atsižvelgiant į pagrindinius reikalavimus, antroji iteracija – bazinio produkto praplėtimas.
Trūkumai ir pranašumai panašūs į Krioklio modelį, tačiau suteikia daugiau galimybių klaidų taisymui, pavyzdžiui, produktas gali būti tikrinamas kiekvieną kartą sukūrus naują iteraciją, paprasčiau valdyti riziką, nes visi rizikos veiksniai identifikuojami kiekvieną kartą kuriant naują iteraciją taip pat leidžia vartotojui įvertinti produktą jo pradinėse stadijose.
Tačiau sunku apibrėžti vykdymo terminus, projekto apimtis gali būti nesuvaldytą projektų vadovo ir keistis, pats projekto terminas ir pabaigimas gali nusikelti dėl kiekvieno vis naujai planuojamo plėtimo ar iteracijos.
Evoliucinis modelis yra daug pranašesnis už Krioklio tipo modelį, nes čia nereikia žinoti ir būti surinkus visų įmanomų funkcinių reikalavimų. Sistema ar projektas pateikiami palaipsniui po tam tikras jų dalis (segmentus, posistemius ir t.t.).
Modelis taikomas tuomet, kai kiti klasikiniai modeliai nepasiteisina ir aiškūs tik produkto branduolys, bet ne papildomas funkcionalumas.
Vienas iš evoliucinių modelių yra priežiūrą įvertinantis (angl. maitainance aware life-cycle).
Pagrindinis modelio aspektas tas, kad dedamos visos pastangos priežiūros poreikių numatymui ankstyvoje programinės įrangos kūrimo stadijoje, kad vėlesnėse būtų sutaupomi kaštai (laikas ir finansai).
Toks modelis leidžia sukurti lengviau palaikomą, kokybiškesnę sistemą
Tai analogiškas modelis jau aptartam „code-and-fix“ modeliui, tik pritaikytas iš esmės priežiūros modeliui. Problema sprendžiama iškart ir kuo greičiau, pataisymai atliekami be ilgalaikio poveikio analizės nenumatant pakeitimų sklaido (angl. ripple effects) ar kitoms posistemėms bendrame projekte.
Modelio metu dokumentacija ruošiama minimali, paprastai naudojama tuomet, kai kūrėjas ir priežiūros atstovas yra tie patys asmenys ar įmonė.
Modelis netinkamas dideliems projektams, kodo kokybė prastėja palaipsniui.
Modelis remiasi 1983 metas ekonominiais modeliais ir principais, kur priežiūros procesas yra uždaras ciklas bei remiamasi tuo, kad tam tikrose vietose vadybos sprendimai turi įtakos proceso veikimui bei juos apsprendžia.
Modelio metu iš anksto numatyti pakeitimai specifiniu procesu, kurie turi mažiausiai įtakos ar daugiausia naudos – bandoma ieškoti ir balanso tarp norimų rezultatų ir reikalingų resursų bei biudžeto.
Dažniausiai sistemos funkcionalumą ekonomiškai galima išskirti į tris dalis: investavimą, atsipirkimą bei mažėjančią grąžą. Boehm‘o modelio metu vadyba turi tinkamai paskirstyti balansą tarp visų trijų ekonominių dalių.
Modelis paremtas realybės supratimu apie priežiūros procesą. Kiti aptariami modeliai bando įsivaizduoti ar sukuria iliuzijas apie idealius rezultatus ar pasisekimą, pavyzdžiui, pilnos dokumentacijos sukūrimą dar prieš pradedant patį projektą ir pan. Osborne modelis orientuojasi į tai, kas yra, o ne tai kas bus.
Osborne modelio teorija teigia, kad didžioji dalis problemų kyla dėl vadybos nesugebėjimo kontroliuoti ir rekomenduoja strategiją, kuri nustato įtraukti priežiūros reikalavimus į pokyčių specifikaciją, sukurti priemones patikrinti ar priežiūros tikslams pasiekti, teikiamos nuolatinis grįžtamasis ryšys vadybininkas bei nustato projekto kokybės užtikrinimo programą, kuri įtraukiama į atestavimo reikalavimus.
Modelis daro prielaidą, kad naujų pakeitimų realizavimas sistemoje yra nuolatinis iteratyvus procesas. Modelis panašus į evoliucinius modelis, nes daro taip pat prielaidą, kad neįmanoma išsiaiškinti visų reikalavimų prieš sistemos diegimą.
Modelis susideda iš trijų pakopų: analizės; siūlomų keitimų specifikavimo; rekonstravimo ir realizavimo. Kiekviena stadija yra aktyviai dokumentuojama, modelis ypač skatina per panaudojamumą, tačiau neišvengia gaisrų gesinimo taktikos.
Modelis parankus tuo, kad integruoja greito taisymo modelio praktiką į labiau struktūrizuotą, tvarkingesnę proceso aplinką, tačiau pagrindiniai trūkumai atsiskleidžia tuomet, jei dokumentacija nėra paruošta pilnai bei gebėjimas palaikymo komandos išanalizuoti visą sistemą iš esmės bei vis atnaujinti ir laikyti dokumentaciją pačią naujausią.
Pakartotinės panaudos modelis grindžiamas principu, kad programinės įrangos priežiūra gali būti procesas įtraukiantis esamos sistemos komponentų per panaudojimą. Basili apibūdintas modelis susideda iš pagrindinių keturių žingsnių:
Šis modelis skiriasi tuo, kad pradinis žingsnis gali būti bet koks, pavyzdžiui, reikalavimų analizė, dizainas, testai ar testiniai duomenys ir pan.
Modelis sukurtas iš informacijos surinktos su JAV Gynybos departamentu bendradarbiavusiomis įmonėmis. Pagrindinis modelio tikslas pagerinti programinės įrangos procesus, tačiau modelis gali būti pritaikytas ir kitiems procesams.
Brandumo modelis gali būti interpretuojamas, kaip struktūrizuotų į 5 lygius taisyklių sąrašą, kuris padeda aprašyti veiksmus, praktikas ir procesus organizacijos patikimiems rezultatams formuoti ir gauti. Modelis skirtas kaip palyginimo būdas ir būdas padėti susivokti.
Pagrindiniai 5 aspektai:
Modelis remiasi ir žiūri, kas vyksta ne idealiu atveju (kaip dažnai būna su tradiciniai modeliais), o realioje praktikoje. Modelis sudarytas iš 5 pakopų. Tam tikri procesai jau gali prasidėti projekto pradiniame (angl. initial) etape, projektui pereinant į evoliucinį procesą (angl. evolution) toliau atliekami priežiūros darbai. Trečioji pakopa – aptarnavimo pakopa, kurios metu atliekami smulkūs pataisymai ir patobulinimai, personalui nebūtina turėti aukšto lygio programų inžinerijos žinias. Šioje pakopoje programinės įrangos dalis priskiriama inžinieriui yra nedidelė, todėl turi būti puikiai suvokiama.
Standartalizuotas procesas skirtas programinės įrangos priežiūrai, tačiau 2010 metais atnaujintas ir pakeistas į naują standartą P14764.
Prasideda po pristatymo etapo ir apima priežiūros planavimą ir vertinimo metrikas.
Straipsnyje apžvelgti tradiciniai, evoliucinis ir priežiūros modeliai. Dauguma tradicinių modelių buvo sukurti senai, todėl neatsižvelgia į vis kintančios ir evoliucionuojančios sistemos prigimtį arba kitaip tariant neatsižvelgia į tai, kad programinė įranga nuolat kinta, neįmanoma apibrėžti jos funkcinių reikalavimų visų iš anksto, tačiau tai nesutrukdo tradicinių modelių taikyti programinės įrangos priežiūrai, o pagrindiniai modeliai yra: gaisro gesinimo modelis, iteracinio pagerinimo modelis, Boehm, pakartotinės naudos modeliai.
Galima daryti išvadą, kad pakartotinės panaudos modelis nustato komponentų atkartojimą sukuriant naujus atkartojimus, o pakopiniai modeliai pateikia naujas pakopas kaip patarnavimą. Visi modeliai turi savo pranašumų ir trūkumų, todėl vieno modelio panaudojimas nėra protingas būdas spręsti problemai – dažniausiai keleto modelių integravimas į vieną procesą yra geriausias sprendimas.
Priežiūros specialistai, kaip ir programinės įrangos kūrėjai ieško alternatyvų ad hoc modeliams ir pereina vis labiau prie daugiau struktūrizuotų, dokumentuotų modelių dėl jų palaikomos kokybės ilguoju periodu, o ne tik gaisrų gesinimui.
IEEE standartų modelis yra išvestinis kitų modelių apibendrinimas.
[1] Václav T. Rajlich, Keith H. Bennett „A Staged Model for the Software Life Cycle,“ [Tinkle]. Available: http://www.cs.wayne.edu/~severe/publications/Rajlich.IC.2000.StagedModel.pdf [Kreiptasi 18 05 2016].
[2] Václav T. Rajlich, Keith H. Bennett „SOFTWARE EVOLUTION AND THE STAGED MODEL OF THE SOFTWARE LIFECYCLE,“ [Tinkle]. Available: http://www.cs.wayne.edu/~severe/publications/Bennett.AdvComp.2002.Software.Evolution.pdf [Kreiptasi 18 05 2016].
[3] http://rti.etf.bg.ac.rs/rti/ms1es/Literatura/Grubb_Takang-Software_Maintenance_Ch5.pdf [Kreiptasi 18 05 2016].
[4] DALIA BAUŽAITĖ „PROGRAMINĖS ĮRANGOS IR INFORMACINIŲ SISTEMŲ PRIEŽIŪRA DIDELĖJE ORGANIZACIJOJE
