05.Gyv_ciklas

P. Kasparaitis. Žmogaus-kompiuterio sąveika. Programinės įrangos gyvavimo ciklas 2011 01 15

1

Programinės įrangos gyvavimo ciklas1 Įvadas

Kompiuterių moksle jau susiformavo stambi sritis – programų sistemų inžinerija, o viena iš jos esminių sąvokų – gyvavimo ciklas, aprašantis veiklas nuo idėjos apie programinę įrangą atsiradimo iki jos išmetimo į šiukšlių dėžę. Svarbu tai, kad su ŽKS susijusios veiklos išsitęsia per visą gyvavimo ciklą ir įtakoja visas kitas gyvavimo ciklo veiklas. Tai nėra vienas atskiras modulis, kurį galima pridėti prie kitų ciklo veiklų.

Gyvavimo ciklo veiklos

Gyvavimo ciklą sudarančios veiklos pavaizduotos 1 pav. Šis grafinis pavaizdavimas vadinamas kriokliu (kaskadu) (angl. waterfall).

1 pav. Programinės įrangos gyvavimo ciklo veiklos.

Reikalavimų specifikavimas

Šiame etape projektuotojas kartu su užsakovu bando sukurti aprašą, ką sistema turėtų daryti. Kaip sistema tai darys, bus nagrinėjama kituose etapuose. Reikalavimų specifikavimas apima ir informacijos apie būsimos sistemos darbo aplinką surinkimą, kokius vartotojus tai palies, kaip bendraus su kitomis programomis, kokias programas pakeis ir pan.

1 Šis skyrius parengtas pagal [Dix ir kt., 2003; 226-258].


2

Reikalavimai formuluojami iš užsakovo perspektyvos, paprastai iš pradžių jie formuluojami natūralia kalba užsakovui suprantamomis sąvokomis. Vienas iš uždavinių – perkelti reikalavimus iš natūralios kalbos į labiau formalizuotą kalbą.

Architektūros projektavimas

Šiame etape jau sprendžiama ne ką sistema turi daryti, o kaip sistema teiks paslaugas, kurių iš jos tikimasi. Pirmoji veikla – išskaidyti sistemą į stambius komponentus, kurie arba bus kuriami atskirai, arba bus panaudoti jau esamos programinės įrangos moduliai. Sistemą skaidant į modulius reikia ne tik nusakyti, kokias paslaugas kiekvienas modulis teiks, bet ir kokie ryšiai bus tarp modulių, kokiais resursais jie dalinsis.

Yra aibė technologijų sistemos funkciniams reikalavimams aprašyti (CORE, MASCOT [ 4 ], HOOD [ 5 ]), tačiau reikia nepamiršti, kad sistema gali turėti ir aibę nefunkcinių reikalavimų: patikimumas, greitis, saugumas ir pan. Reikalavimai vartotojo sąsajai (išmokstamumas, įsimenamumas ir pan.) taip pat didžia dalimi yra nefunkciniai reikalavimai.

Išsamus projektavimas

Šiame etape projektuotojas turi detalizuoti kiekvieno ankstesniame etape išskirto modulio aprašą, t. y. sukurti pakankamai išsamų aprašą, kurį jau galima realizuoti programavimo kalba. Anksčiau aprašytas modulių elgesys turi būti išsaugotas.

Paprastai yra ne vienas galimas detalizavimo būdas, tenkinantis modulio elgsenos apribojimus (funkcinius reikalavimus). Paprastai pasirenkamas tas išsamaus projekto variantas, kuris geriausiai tenkina nefunkcinius reikalavimus. Pasirinktus projektavimo sprendimus ir jų pasirinkimo priežastis svarbu dokumentuoti.

Kodavimas ir modulių testavimas

Pagal išsamų modulio aprašą rašomas programos kodas, kuris po to testuojamas pagal ankstesnės veiklos metu apibrėžtus kriterijus. Atlikta daug tyrimų, kaip pagal išsamų aprašą būtų galima automatiškai generuoti programos kodą, kadangi tiek išsamus aprašas, tiek programos kodas yra pakankamai formalizuoti matematiniai pavaizdavimai. Kita tyrimų kryptis – kaip iš išsamaus aprašo ir kitų ankstesnių etapų rezultatų automatiškai generuoti testus, su kuriais galima būtų patikrinti užprogramuoto modulio darbo korektiškumą.

Integravimas ir testavimas

Programiškai realizavus pakankamai komponentų, jie apjungiami, kaip aprašyta sistemos architektūros apraše, ir atliekamas testavimas, ar apjungti moduliai elgiasi tinkamai, ar tinkamai dalinasi resursais. Šiame etape jau galima atlikti ir tam tikrus priimtinumo testus su vartotojais (užsakovais). Tik atlikus testavimą su integruota sistema, ją galima perduoti užsakovui.

Šiame etape gali reikėti atlikti ir kokius nors standartais ar įstatymais nustatytus testus.


3

Naudojimas ir palaikymas

Visa veikla po sistemos perdavimo vadinama palaikymu, kol neiškyla poreikis sistemą perprojektuoti iš naujo. Tai ilgiausiai trunkanti veikla. Jos metu taisomos klaidos, pastebėtos po sistemos perdavimo, peržiūrimos sistemos teikiamos paslaugos, ar jos tenkina reikalavimus. Palaikymo metu gaunamas grįžtamasis ryšys visoms gyvavimo ciklo veikloms.

Interaktyvios sistemos ir gyvavimo ciklas

1978 m. atliktas tyrimas, kuris parodė, kad 50% projektuotojo darbo laiko užima vartotojo sąsajos projektavimas. Analogiški rezultatai buvo gauti ir 1990 m. Šiame skyrelyje bus nagrinėjama, kokius pokyčius į gyvavimo ciklą įneša sistemos interaktyvumas.

Vienas iš skirtumų, kad iš karto nebūna suformuluoti visi reikalavimai. Sukuriama sistema, stebimas ir įvertinamas vartotojų elgesys, tada sprendžiama, kaip ją padaryti draugiškesnę vartotojui. Taip yra todėl, kad dabartiniai psichologiniai ir sociologiniai žmogaus modeliai neleidžia pakankamai tiksliai prognozuoti, kaip sukurti pačią tinkamiausią vartotojui sistemą. Šie modeliai arba yra pernelyg detalizuoti (pvz., skirti klavišų sekoms) ir todėl netinka projektavimo pradžioje, arba yra orientuoti į tikslo pasiekimą ir todėl netinka labai interaktyvioms sistemoms.

Bandymams su vartotojais turi būti naudojama tokia sistema, kuri jau funkcionuoja panašiai, kaip ir galutinė sistema. Neverta leisti vartotojams eksperimentuoti su daug primityvesne sistema, nes rezultatai gali gautis labai skirtingi nuo tų, kurie bus gauti su galutine sistema. Dažnai apie tai, ar vartotojui patiks atlikti tam tikrus veiksmus tam tikru būdu, galima sužinoti tik po to, kai vartotojas pabandys juos atlikti su šia sistema, t. y. anksčiau vartotojas neturėjo galimybės tokių veiksmų atlikti. Pvz., kol nebuvo sukurtas pirmasis tekstų procesorius, vartotojai neįsivaizdavo, kad galima jau surinktam tekstui keisti atstumus tarp eilučių. Taigi panašu į vištos/kiaušinio problemą.

Be to, vartotojas gali atlikti tokius veiksmus, t. y. panaudoti sistemą tokiems uždaviniams spręsti, kokių nenumatė sistemos projektuotojas.

Galiausiai tradiciniame gyvavimo cikle nėra pakankamai išvystytų žymėjimo sistemų ir technologijų, skirtų sistemai aprašyti iš vartotojo perspektyvos. Pvz., kaip pagal abstraktų projektą apskaičiuoti, kiek ir kokios informacijos vartotojui reikės atsiminti, per kiek laiko vartotojas sugebės atlikti tam tikrus veiksmus.

Vartotojui tinkamesnių interaktyvių sistemų kūrimas paprastai nagrinėjamas po antrašte „Vartotojui palankus projektavimas“ (angl. user-centered design), kurio pagrindinė idėja – įtraukti vartotoją į visus sistemos kūrimo etapus.

Panaudojamumo inžinerija

Kaip užtikrinti, kad sukurta sistema bus vartotojui tinkama naudoti? Vienas iš būdų – įtraukti tam tikrą aibę panaudojamumo kriterijų į reikalavimų specifikaciją jau pačiame pradiniame etape. Kiekvienam kriterijui reikia nurodyti, kaip jis bus matuojamas, kokį lygį pasiekus bus laikomas priimtinu ir pan. Kai jau sistema bus tinkama testavimui su vartotojais, atlikti testavimą, iteraciškai taisyti ir vėl testuoti sistemą, kol kriterijai bus tenkinami. Toks metodas vadinamas panaudojamumo inžinerija (angl. usability engineering) [Faulkner, 2003, 129-133].


4

Tarkime, kad nusprendėme sistemą vertinti pagal tokius kriterijus: 1) išmokstamumas, 2) naudojimo paprastumas ir efektyvumas po apmokymo (angl. throughput), 3) vartotojo pasitenkinimas.

Išmokstamumą galima būtų vertinti tokiais kriterijais: 1) laikas, reikalingas išmokti dirbti su sistema; 2) klaidų pranešimų dažnis; 3) konkrečios klaidos pranešimų dažnis; 4) žinyno naudojimo dažnis ir pan. Net vartotojų pasitenkinimą galima išmatuoti paprašius jų įvertinti sistemą

balais nuo 1 (labai blogai) iki 5 (labai gerai). Taigi norint kurti sistemą panaudojamumo inžinerijos metodu, reikia sudaryti

panaudojamumo specifikaciją (pavyzdį žr. 1 lentelėje), ir pagal ją testuoti. 1 lentelė. Panaudojamumo specifikacija.

Atributas (matuojamas kriterijus): Sistemos naudojimo paprastumas ir efektyvumas po apmokymo

Metrika: Klaidų skaičius Vartotojų aibė: Visi vartotojai Išankstinės sąlygos: Matuoti praėjus 1 savaitei nuo naudojimo

pradžios Blogiausias atvejis: Daugiau klaidų, nei dabar Žemiausias priimtinas lygis: Tiek pat klaidų, kiek dabar Planuojamas lygis: Dvi klaidos per valandą Geriausias atvejis: Darbas be klaidų Dabartinis lygis: Šešios klaidos per valandą

Sistemos panaudojamumui matuoti gali būti naudingi tokie kriterijai: 1) laikas, reikalingas darbui atlikti; 2) užbaigtų darbų dalis procentais; 3) laikas, skirtas klaidų taisymui; 4) žinyno ar dokumentacijos naudojimo dažnis; 5) laikas, praleistas skaitant žinyną ar dokumentaciją; 6) palankių/nepalankių vartotojo atsiliepimų santykis; 7) neįvykdytų ar pakartotinai vykdomų komandų skaičius; 8) panaudotų skirtingų komandų skaičius; 9) nenaudojamų komandų skaičius; 10) grįžimo komandos vykdymų skaičius; 11) skaičius, kiek kartų vartotojas prarado sistemos kontrolę ir t. t. Viena iš problemų, kad sistemos projektavimo pradiniuose etapuose sunku

apibrėžti tinkamus panaudojamumo kriterijus, priimtinumo lygius ir pan. Be to, taip užtikrinamas tik panaudojamumo kriterijų tenkinimas, bet nebūtinai panaudojamumas.

Projektavimas iteracijomis ir prototipų kūrimas

Yra trys pagrindiniai prototipų naudojimo būdai: 1) Išmetami prototipai. Prototipas sukuriamas ir testuojamas. Gaunamos

reikalingos projektavimo žinios, kurios panaudojamos galutiniame produkte, tačiau pats prototipas išmetamas. Tokia prototipo panaudojimo procedūra pavaizduota 2 pav.


5

2 pav. Reikalavimų specifikavimas naudojant išmetamus prototipus. 2) Pažingsninis didinimas. Galutinis produktas kuriamas iš atskirų komponentų,

pridedant po vieną kiekvienoje iteracijoje. Tai pavaizduota 3 pav.

3 pav. Pažingsninis didinimas gyvavimo cikle. 3) Evoliucija. Šiuo atveju prototipas neišmetamas, o tarnauja kaip kitos

projektavimo iteracijos pagrindas. Tai pavaizduota 4 pav. Šis būdas gerai tinka modifikacijoms, kurių prireikia naudojimo ir palaikymo metu, atlikti.

Prototipų naudojimas kelia ir tam tikras problemas visam projektui. Pvz.: Prototipų kūrimas reikalauja laiko, todėl tai turi vykti sparčiai. Daugelis projektų vadovų neturi patirties, kaip susiplanuoti projekto, kuriame kuriami prototipai, eigą. Iš anksto žinoma, kad kai kurios prototipo savybės (pvz., reakcijos laikas) neatitiks galutinės sistemos elgesio.


6

4 pav. Prototipo evoliucija gyvavimo cikle. Sistemos kūrimas iteracijomis turi ne tik pliusų, tačiau ir minusų. Visų pirma:

projektavimo pradžioje priimtas blogas sprendimas turi savybę išlikti labai ilgai, jo sunku atsisakyti, nors teoriškai kiekvienoje iteracijoje galima atlikti ženklius pakeitimus. Kita problema, kad diagnozavus potencialią naudojamumo problemą svarbu suprasti jos priežastį, o ne tik pastebėti simptomus. Pvz., jei vartotojas nesugeba nustatyti laikrodžio, priežastis gali būti ta, kad sistemoje naudojamas 12 (o ne 24) valandų laikrodis, o ne blogi laiko nustatymo mygtukai ar pan.

Prototipų kūrimo technologijos

Kadruotės

Kadruotė (angl. storyboard) – tai organizuota seka išdėstyti grafiniai vaizdai (eskizai, iliustracijos, fotografijos), kurie nepalaiko jokio būsimos sistemos funkcionalumo. Paprastai tam naudojamos šiuolaikiniai grafiniai piešimo paketai, tačiau gali būti piešiami ir ranka. Vaizdų keitimui galima panaudoti animacijos priemones.

Riboto funkcionalumo simuliacijos

Kadruotės negali adekvačiai pavaizduoti interaktyvių sistemos aspektų. Reikalingos programinės priemonės, leidžiančios greitai sukuti grafinius ar tekstinius sąsajos objektus, kurie imituotų sistemos funkcionalumą. Tokių priemonių pavyzdžiai: Macromedia Flash ir Director.

Šiuo būdu sukurti prototipai panaudojus dažniausiai išmetami, nes jie būna neefektyviai realizuoti ir netinka naudoti kaip pagrindas visai sistemai. Tačiau vis dažniau šio tipo simuliacijos įtraukiamos į galutines sistemas kaip evoliucinio tipo prototipai. Pvz., lėktuvo kabinos prototipą galima panaudoti kaip mokomąjį skrydžio simuliatorių.

Dar viena simuliacijų kūrimo technologija, vadinama Ozo burtininku (angl. Wizard of Oz). Jos esmė, kad sistemos funkcionavimą imituoja kitas žmogus, kuris sėdi kitame kambaryje, priima vartotojo įvestas komandas ir formuoja sistemos atsakus. Taip vartotojui sudaromas įspūdis, kad prototipas jau yra gana funkcionalus.


7

Aukšto lygio programinis palaikymas

Yra specialios paskirties aukšto lygio programavimo kalbos, kurios leidžia projektuotojui lengvai suprogramuoti tam tikras interaktyvios sistemos savybes, pvz., mygtuko paspaudimą pele. Šios programavimo kalbos leidžia atsiriboti nuo aparatūrinės įrangos niuansų.

Jei vartotojo sąsajos kūrimui naudojamos vartotojo sąsajos valdymo sistemos (angl. user interface management systems) (dar žr. skyrių „Programinė realizacija“), tai galima atskirti sistemos funkcionalumą nuo sąsajos. Tuomet galima iš pradžių sukurti sistemos funkcijas, o vėliau sukurti ir išbandyti daug skirtingų sąsajų.

Projektavimo sprendimai

Projektavimo sprendimai (angl. design rationale) – tai informacija, kuri paaiškina, kodėl sistema atrodo taip, o ne kitaip, įskaitant struktūros, architektūrinius, funkcionavimo sprendimus. Sprendimų priėmimas ir dokumentavimas tęsiasi per visą sistemos kūrimą, tai nėra atskira gyvavimo ciklo veikla. Sprendimų dokumentavimas svarbus, nes:

1) Leidžia kitiems projektuotojų komandos nariams suprasti, kokios alternatyvos buvo nagrinėtos, kodėl vienos geresnės už kitas;

2) Gali būti pakartotinai panaudota kuriant kitas sistemas, jei panašūs poreikiai; 3) Poreikis dokumentuoti skatina projektuotojus atsakingiau rinktis sprendimus; 4) Gali būti kelios vienodai geros alternatyvos ir pasirinkimą lemia tai, kuris

kriterijus pasirinktas kaip svarbiausias; 5) Alternatyvų gali būti labai daug ir svarbu žinoti, ar visos alternatyvos buvo

nagrinėtos, gal pati geriausia alternatyva net nebuvo nagrinėta; 6) Sistemos naudojamumas gali labai priklausyti nuo naudojimo sąlygų, pvz.,

sudėtinga grafinė sąsaja gali būti netinkama, jei vartotojas neturi kokybiško displėjaus, todėl gali tekti rinktis kitą alternatyvą.

Sprendimų dokumentavimą galima klasifikuoti keliais būdais: 1) Chronologiškai. 2) Struktūriškai. 3) Pagal atliekamas užduotis.

Literatūra

1. Dix, A., J. Finlay, G. D. Abowd, R. Beale. Human-Computer Interaction, Third Edition, Pearson Prentice Hall, 2003.

2. Faulkner, Ch., The Essence of Human-Computer Interaction, Pearson Prentice Hall, 2003.

3. http://lt.wikipedia.org/wiki/Storyboard. 4. http://en.wikipedia.org/wiki/Modular_Approach_to_Software_Construction

_Operation_and_Test 5. http://www.esa.int/TEC/Software_engineering_and_standardisation/TECKL

AUXBQE_0.html

Documents

05.Gyv_ciklas