# B.1 Süsteemiarenduse protsess ja meetodid

Selle teema materjale läbi töötades saad teadmised tarkvarasüsteemide tüüpidest, tööst, arendusest, testimisest ja haldamisest.

# B.1.1 Tarkvara andmetöötlussüsteemides

Selle alateema materjale läbi töötades saad teadmised tarkvarasüsteemide tüüpidest, kasutusvaldkondadest ja eripäradest.

# B.1.1.1 Andmetöötlussüsteem

Andmetöötlus data processing on andmete manipuleerimine arvuti abil. See tegevus sisaldab toorandmete teisendamist masin-loetavale kujule, nende liikumist läbi protsessori (CPU) ja mälu väljundseadmetesse ning väljundi vormindamist ja teisendamist sobivale kujule. Üldisemalt nimetatakse andmetöötluseks alati arvutil toimuvat protsessi, kui see sisaldab nimetatud tegevusi. Andmetöötlust võib käsitleda ka kitsamalt kui mõnele organisatsiooni või äri tegevuseks vajalike andmete töötlemist (nt statistiline andmetöötlus).

Andmetöötlussüsteem data processing system koosneb üldisemalt riistvarast, tarkvarast ja inimestest. Andmetöötlussüsteem on süsteem, mis teeb sisendandmetega mitmesuguseid matemaatilisi operatsioone, eesmärgiga muuta need informatsiooniks, kasutajale vajalikule väljundandmete kujule. Viimane võib olla nii heli, video, graafika, arvude kui ka teksti kujul.

Riistvara hardware on üldisem mõiste tähistamaks igasuguseid tehnoloogilisi seadmeid (tooteid). Antud kontekstis peetakse silmas ennekõike arvuti riistvara. Viimase moodustavad kõik arvuti füüsilised komponendid: kuvar, protsessor, mälu, kettaseadmed, modem, printer, klaviatuur, hiir jms (vt moodul C). Arvutiriistvara on vajalik nii andmete sisestamisel, töötlemisel, salvestamisel kui ka töötlemise tulemuste esitamisel.

Andmetöötlussüsteemi tarkvara omakorda sisaldab järgmist liiki osi:

Püsivara firmware - talitluslikult põhimälust sõltumatul viisil püsimällu (ROM) salvestatud käsu- ja andmekogum (programm ja vastav andmestik). Püsivara on reeglina seotud mõne riistvara komponendiga ning tihti ei ole teda võimalik muuta riistvara komponenti asendamata või vähemalt ei saa seda muuta iga seadme kasutaja. BIOS (basic input/output system) on üks püsivara näiteid. BIOS on kirjutatud arvuti ROM-i ja sisaldab instruktsioone klaviatuuri sisendi ja ekraaniväljundi tarbeks.

Operatsioonisüsteem operating system software on tähtsaim süsteemitarkvara hulka kuuluv programm, mis juhib arvuti tööd, haldab riistvararessursse, suhtleb perifeerseadmetega ja tagab rakendusprogrammide töötamise. Kasutajatel on võimalik suhelda vahetult operatsioonisüsteemiga, kasutades selleks käsukeelt või graafilist kasutajaliidest. Operatsioonisüsteemi ülesannete hulka kuulub ressursside jaotamine erinevate rakenduste vahel, mälu ühiskasutuse juhtimine, sisend- ja väljundseadmetega suhtlemine, kasutajate haldus jne.

Tuntumad personaalarvutite operatsioonisüsteemid jagunevad kolme suurde gruppi: Windows'i erinevad versioonid, Mac OS ja UNIX'i-laadsed operatsioonisüsteemid

Rakendustarkvara application software on otseselt kasutaja eesmärkide täitmiseks loodud ja installeeritud tarkvara. Kõige olulisema erinevusena tulekski pidada meeles, et erinevalt süsteemitarkvarast on rakendustarkvara otseselt suunatud just kasutaja eesmärkide täitmisele.

Süsteemi konfiguratsioonifailid system configuration data sisaldavad erinevaid andmeid, mis on vajalikud arvutisüsteemi enda toimimiseks. Sellised andmed on nii operatsioonisüsteemil kui ka rakendustarkvaral.

Kasutaja andmed user-defined data on spetsiifilised rakendusele, mida kasutaja jaoks arvutisüsteemi salvestatakse.

# B.1.1.2 Süsteemitarkvara ja rakendustarkvara

Tarkvara liigitatakse kahte suurde gruppi:

• süsteemitarkvara system software
• rakendustarkvara application software

Süsteemitarkvara alla kuuluvad programmid, millised toetavad rakenduste tööd, olemata ühegi rakenduse spetsiifiline. Kujutades piltlikult ette arvuti ehitust kihtidest või tasemetest koosnevana, paiknevad süsteemitarkvara alla liigituvad programmid "alumistes" kihtides, lähemal füüsilisele kihile – riistvarale, mis jooksutab programme. Süsteemitarkvara toetab kogu arvutisüsteemi käitamist.

Toome näiteid süsteemitarkvara funktsioonidest:

• riistvaraga suhtluse juhtimine
• protsesside ajastamine
• mälu haldus
• kasutajaliidese üldfunktsioonid ja kasutajaliidese töö, kui ükski rakendus ei ole aktiivne.

Eelnevad näited seonduvad ennekõike operatsioonisüsteemi talitusega ja võibki väita, et operatsioonisüsteem on üks tüüpilisemaid süsteemitarkvara näiteid. Lisaks on süsteemitarkvara arvuti BIOS ja seadmete püsivara ning erinevad utiliidid, mis aitavad arvutit hallata.. Lisaks võib lugeda süsteemitarkvaraks ka nt erinevate seadmete draivereid, andmebaasimootoreid, tarkvara loomise abivahendeid, nagu interpretaatoreid-kompilaatoreid, silujad jms. Kuid seda arvamust ei tasu pidada ainuõigeks.

Rakendustarkvara paigutub kihilise mudeli järgi "kõrgemale" kihile – "eemale" riistvarast ja lähemale arvutiga suhtlevale kasutajale. Rakendustarkvara ülesandeks on kasutaja soovide täitmine, "kasutaja toetamine" tema eesmärkide saavutamisel. Rakendustarkvara toetub süsteemitarkvarale. Rakendustarkvara võib olla avalikustatud eraldiseisvalt, kuid võib kaasa tulla ka operatsioonisüsteemiga. Igal juhul on kõige olulisem tema suunatus kasutaja abistamisele.

Analoogiana võib ette kujutada elektrivalgust kui kasutajale vajalikku funktsiooni, ning elektrijaamu, ülekandeliine jm kui funktsiooni toetavad mehhanisme.

Süsteemitarkvara ja rakendustarkvara erisus ei ole absoluutne ja kindlapiiriline – nt kohtuasjas Microsoft ja Ameerika Ühendriikide vahel oli üheks põhiküsimuseks, kas veebilehitsejat MS Explorer lugeda operatsioonisüsteemi alla kuuluvaks (seega süsteemitarkvaraks) või iseseisvaks rakenduseks (seega – rakendustarkvaraks). Ja teisalt võime küsida ka teisiti: kas kogu tarkvara, mis installeeritakse koos operatsioonisüsteemiga on süsteemitarkvara või leiame sealt ka mõne rakendustarkvara? Lähtudes rakendustarkvara definitsioonist, et seda saab kasutada mingite eesmärkide saavutamiseks, on rakendustarkvarad lisaks IE-le ka Notepad, Paint, Calculator, Wordpad, Solitaire, Minesweeper jne.

# B.1.1.3 Näited tarkvaradest

Toome näiteid mõlemast tarkvara alaliigist

1. süsteemitarkvara:

• operatsioonisüsteemid, nt Linux, Windows Vista, Symbian OS – mobiilsetes seadmetes kasutatav operatsioonisüsteem, Unix
• draiverid, nt printeri draiver
• failihaldusprogrammid

2. rakendustarkvara nn kontoritööpaketid:

• tekstitöötlusprogrammid
• tabelarvutusprogrammid
• esitlusprogrammid
• jmt

2. arendusvahendid:

• assemblerid
• kompilaatorid
• interpretaatorid
• versioonihaldusprogrammid
• jmt

3. infohaldusrakendused :

• ettevõtte ressursiplaneerimispaketid (ERP)
• raamatupidamispaketid
• kliendihalduspaketid (CRM)
• otsustusi toetavad süsteemid (DSS)
• projektihalduspaketid
• jmt

4. inseneri töövahendid:

• CAD-programmid
• statistilise analüüsi programmid
• geoinfosüsteemid
• jmt

5. kirjastamine ja multimeedia:

• trükiste kujundusprogrammid
• videotöötlusprogrammid
• õppematerjalide ettevalmistus- ja levitusprogrammid
• jmt

6. vabaajaveetmisel kasutatav tarkvara:

• mängud
• heli- ja video esitamise programmid
• jmt

7. suhtlustarkvara:

• e-maili kliendiprogrammid
• veebipäevikute (blog) haldusprogrammid
• wiki haldusprogrammid.

Ülaltoodud tarkvara klassifikatsioon ei ole kindlasti ammendav – toodud on enamlevinud programmide tüübid.

# B.1.1 Kordamisküsimused

# B.1.2 Süsteemiarenduse elutsükkel

Selle alateema materjale läbi töötades saad teadmised süsteemiarenduse elutsüklist.

Süsteemiarenduse elutsükkel Systems Development Lifecycle (ka tarkvaraarenduse elutsükkel) on protsess, mille käigus luuakse uus või muudetakse vana tarkvarasüsteemi, samuti mudelid ja meetodid, mida inimesed kasutavad süsteemide arendamiseks.

Tarkvara kui toode on süsteemiarenduse väljund.

Süsteemiarenduse protsess koosneb nii toote projekteerimisest (disainist) kui toote valmistamisest. Süsteemiarenduse eesmärk on valmistada kõrgekvaliteetne toode ehk tarkvara, mis vastab kasutajate vajadustele ja ootustele, saab valmis kokkulepitud tähtajaks ja maksumuse piires, töötab efektiivselt ja tõhusalt praeguses ja planeeritavas IT infrastruktuuris ning ei ole kulukas hooldada ega laiendada.

# B.1.2.1 Elutsükli faasid

Käsitledes tarkvara justkui iga teist toodet, võib tarkvara elutsükli (arendusprotsessi) jagada faasidesse. Faaside nimed ja täpsem jaotus varieerub sõltuvalt autorist. Kuid see ei tähenda, et oluliste arendustegevuste loetelu kuidagi erineks. Tüüpilisteks elutsükli osadeks võib lugeda: analüüsi analysis, projekteerimise / kavandamise design, teostuse implementation ja hoolduse maintenance.

Järgnevalt sellest, milliseid tegevusi nimetatud arendusfaasid sisaldavad.

# Analüüsi etapil

Analüüsi etapil ja kogu arenduse käigus on tarkvarale esitatavate nõuete väljaselgitamine üks olulisemaid. Ilma selleta ei ole võimalik järgmisi samme astuda. Oma olulisuse tõttu käsitletakse tööd nõuetega tihti ka eraldi faasina. Nõuded annavad ettekujutuse sellest, mida kasutaja tarkvara abil teha tahab, milliseid eesmärke tal vaja saavutada. Teisisõnu on tegemist tarkvara funktsionaalsuse ( funktsionaalsed nõuded ) väljaselgitamisega. Lisaks on olulised ka mittefunktsionaalsed nõuded. Need on tihti piirangud või lisatingimused, millega süsteemi töötamisel arvestada tuleb.

Näide funktsionaalsete nõuete kohta: tavapärases õpiinfosüsteemis (ÕIS) tahab õpilane vaadata oma hindeid. Õpetajal on vaja näha, lisada, muuta ja kustutada kõigi õpetatavate õpilaste hindeid (muidugi oma aines). See ei ole ammendav loetelu ÕIS-i nõuetest. Küll aga tuleb siit välja veel oluline fakt, et tavaliselt on nõuded seotud rollidega - erinevatel süsteemi kasutajatel on erinevad soovid ja erinevad õigused. Mittefunktsionaalsed nõuded võivad näiteks sisaldada tingimust, et süsteem peab töötama pidevalt ning maksimaalne lubatud katkestuse pikkus on pool tundi.

# Projekteerimine (kavandamine)

Projekteerimine on vastavalt IEEE definitsioonile "süsteemi või komponentide arhitektuuri, osade, liideste ja teiste omaduste määramine" Inglisekeelne sõna design tähendab nii tegevust kui ka selle tegevuse produkti, eesti keeles võib tulemust nimetada kavand või projekt. Kavandamine on arendusprotsessi osa, kus analüüsitakse nõudeid, et luua tarkvara sisemine struktuur. Loodud kirjeldus on omakorda realisatsiooni aluseks. Tarkvara projekt peab kirjeldama süsteemi arhitektuuri, st kuidas süsteem on jaotatud osadeks (komponentideks) ning millised on nende liidesed (seostamisvõimalused teiste komponentidega). Komponendid peavad olema kirjeldatud sellise täpsusega, mis lubaks hakata neid realiseerima.

Klassikalises tarkvara elutsüklis vastavalt standardile ISO/IEC 12207 Software life cycle processes, on kavandamise osa jaotatud kahte etappi:

• arhitektuuri kavandamine, millega määratakse kindlaks nö kõrgema taseme komponendid, seosed suuremate ja üldisemate tarkvara osade vahel;
• detailsem kavandamine, millega täpsustatakse komponentide ülesehitus (protseduurid, objektid, algoritmid jms).

# Realisatsioon

Realisatsiooni (teostuse) faasis programmeeritakse tarkvara valmis lähtudes kavandamisetapil loodud tarkvaraprojektist. Komponentideks jagamine loob eeldused tööjaotuseks, st vähegi suurema süsteemi kodeerimiseks rakendatakse tööle programmeerijate meeskond. Realisatsiooni faasis toimub ka programmeeritud osade testimine ehk vigade otsimine. Esialgu komponentide kaupa loogika jms vigade leidmiseks.

Tegelikkuses ei toimu arendus nii sirgjooneliselt, et enne tehakse põhjalik projekt kogu süsteemi tarbeks ning seejärel asutakse programmeerima. Pigem põimuvad need faasid ning peale projekti tekkimist süsteemi osa kohta asutakse seda osa ka teostama. Samal ajal jätkub aga ülejäänud süsteemi projekteerimine.

Realisatsiooni faasi viimaseks osaks on süsteemi valideerimine. See on samuti sisuliselt testimine, kuid põhieesmärgiks on teada saada, kas tekkinud süsteem vastab kasutaja nõuetele ehk lihtsamalt öeldes - kas süsteem teeb seda, mida kasutaja tahab.

# Hooldamine

Tarkvara hooldamiseks nimetatakse tarkvara muutmist peale kliendile üleandmist, et parandada vigu, tõsta jõudlust või parandada muid omadusi. Hoolduse eesmärkideks on süsteemi kohandamine vastavalt muutunud keskkonnale ning muutunud kasutaja soovidele ja tarkvarasüsteemi töös hoidmine nii kaua kui võimalik. Hooldamise juures on oluliseks aspektiks teiste programmeerijate poolt kirjutatud tarkvaraga töötamine (parandamine, täiendamine, muutmine) ja sellest tulenevad omakorda seosed eelmistes faasides tehtud töö kvaliteediga. Hästi kavandatud, kodeeritud ja dokumenteeritud tarkvara on kergem, kiirem ja seega ka odavam hooldada.

Tarkvara tootmine lõppeb kliendile tarkvara üleandmisega. Valminud tarkvara peab olema selline, mida klient tahtis. Kuid tarkvara peab edasi arenema. Töötamise käigus leitakse anomaaliaid, muutub töö keskkond, tekivad uued nõuded. Muudatuste vajadused logitakse, määratakse muudatuste mõju, kood muudetakse, tehakse testid, antakse välja tarkvara uus versioon ja vajadusel korraldatakse ka koolitus.

Võrdluseks Ian Sommerville oma raamatus "Software Engineering" toob välja järgmised tegevused tarkvaraprotsessis. Järele mõeldes kattub nende sisu eespool toodud faaside kirjeldustega.

1. Tarkvara kirjeldamine , mille käigus kliendid ja tarkvarainsenerid määratlevad koostöös loodava tarkvara funktsionaalsuse ja piirangud tema töötamisel.
2. Tarkvara arendamine , mille käigus tarkvara projekteeritakse ja programmeeritakse
3. Tarkvara valideerimine , mille käigus kontrollitakse tarkvara veendumaks, et see on selline, nagu klient tahtis.
4. Tarkvara edasiarendus , mille käigus tarkvara muudetakse, et see vastaks jätkuvalt kliendi muutuvatele nõuetele ja turu ning äri muutuvatele tingimustele.

Süsteemiarenduse elutsüklisse peavad kuuluma kõik eelpool kirjeldatud tegevused, kuid need faasid ei pea tingimata olema kirjeldatud viisil lineaarselt ritta seatud.

# B.1.2.2 Elutsükli üldised mudelid

Süsteemiarenduse elutsükli mudel on arendusprotsessi üldistatud (abstraktne) kirjeldus. See on protsessi kirjeldus teatud vaatenurgast lähtudes. Protsessimudelite kirjeldustes räägitakse tavaliselt tegevustest nagu andmemudeli kavandamine, kasutajaliidese disain jne, kuid nad võivad sisaldada ka dokumentatsiooni ja rollide kirjeldusi.

Protsessimudelites võib kohata kahte põhimõttelist lähenemist.

Tugev planeerimine. See vanem lähenemine seisneb tegevuste ja tarkvara põhjalikus planeerimises ja järgnevas kindlalt plaani järgivas arenduses. Arendustegevuse progressi mõõdetakse sama plaani abil.

Agiilne ehk paindlik arendus, kus planeerimine toimub osade kaupa (inkrementaalselt) ning tänu millele on võimalik protsessi käiku muuta, tulles vastu kasutajate muutuvatele nõuetele. Paindliku protsessi kasutuselevõtt tulenes klientide vajaduste kiirest muutumisest. Protsess peab olema paindlik ja suutma reageerida toote muutmise, täiendamise ja kohandamise soovidele.

Kui vahepeal toimus süsteemi üldiste arendusmudelite jaotamine rangelt ühte või teise kategooriasse, siis praegu leiab Ian Sommerville, et üldiselte sel tasemel ei ole range jaotus otstarbekas ja nii mõnegi mudeli järgi on võimalik panna käima nii agiilne kui planeeritud arendusmeetod.

Läbi ajaloo on pakutud mitmeid üldisi süsteemiarenduse mudeleid ja olulisemad neist on:

1. koskmudel waterfall model
2. spiraalmudel spiral model
3. inkrementaalmudel incremental model
4. prototüüpimine prototyping

Järgnevalt käsitleme eelpoolnimetatud süsteemiarenduse mudeleid lähemealt.

# Koskmudel

Koskmudel (ka klassikaline mudel) on esimene kirjeldatud tarkvarasüsteemi elutsükli mudel, mis lähtus tavalistest tootmisprotsessidest ehituses, mehhaanikas vms. Mudeli kirjeldas Winston W. Royce 1970. aastal. Koskmudel on kõige vanem ja kõige rohkem kritiseeritud protsessimudel

Põhiidee kohaselt jagatakse tegevused nii, et iga tegevus toimub jadamisi eraldi etapina. Royce jagas protsessi järgmisteks põhietappideks (tasub tähele panna, et etappide nimekiri varieerub erinevate autorite esituses):

1. Nõuete määratlemine. See etapp võib olla ka jaotatud kaheks – süsteemi analüüs (kõik see, mis konkreetset tarkvara ümbritseb) ja nõuete analüüs. Dokumenteeritakse süsteemi käitumine, jõudlus, liides jne.
2. Süsteemi ja tarkvara kavandamine. Keskendub põhilistele programmi omadustele nagu andmestruktuurid, tarkvara arhitektuur, liideste omadused ja protseduurilised ning algoritmilised Projekti kvaliteeti on võimalik hinnata. Tulemus dokumenteeritakse.
3. Teostus ja moodulite testimine. Projektis kirjeldatud süsteem programmeeritakse moodulite ja programmide kogumina ja need testitakse eraldi. Mida detailsem on projekt, seda lihtsam ja mehhaanilisem saab olla teostuse etapp.
4. Integratsioon ja süsteemi testimine. Programmid ja moodulid integreeritakse ning testitakse kogu süsteemi, peale testimist antakse toode kliendile. Testimisel keskendutakse nii loogilistele detailidele kui ka sellele, kas süsteem oma funktsionaalsuse osas nõudeid täidab (valideerimine).
5. Kasutamine ja hooldus - on tavaliselt kõige pikem faas. Süsteemi muudetakse, kui kasutajad avastavad vigu, ümbrus ja töökeskkond muutuvad või klient vajab uut funktsionaalsust. Faas kordab kõiki eelnevaid faase olemasoleva süsteemi muutmise raames.

Iga faasi tulemiks on üks või mitu dokumenti, mis kinnitatakse. Järgmine faas ei tohiks alata enne, kui eelmine on lõpetatud. Faasidel on teatav ülekate ja info edastamine ühest teise. Vt ka joonist 1-1.

Joonis 1-1. Koskmudel

Kommentaariks joonis 1-1 juurde - tihti joonistatakse koskmudeli loogikat nii, et on vaid ülalt allapoole (eelmisest faasist järgmisesse) suunduvad nooled. Eelnevate sammude juurde tagasi ei pöörduta, samuti nagu majaehitusel ei pöörduta tagasi vundamendi juurde peale katuse paigaldamist. Sel juhul oleks mudeli kohaselt üldse võimatu midagi süsteemis hiljem muuta. Sellist varianti pidas ka Royce oma artiklis võimatuks. Royce lisas tegelikult juba alguses iga etapi kohta tagasisidet kujutava noole. Siiski ei ole tagasipöördumine igast etapist eelmisesse võimalik. .Kui testimise käigus avastatakse viga, mille juured on arhitektuuris, siis koskmudeli kohaselt saab pöörduda tagasi arhitektuuri muutmise juurde alles siis, kui tarkvara on kasutusse läinud (vt noolte suundi joonisel).

Kokkuvõte:

• Otsused süsteemi kohta tehakse varajases faasis ja süsteem ei pruugi lõpuks teha seda, mida kasutaja tahab (nõuded on varakult külmutatud). Samas ei tea ka klient alguses, mida ta tahab ja tema ebakindlus on täiesti loomulik.
• Projekti range jaotus faasideks ei luba kliendi muutunud nõuetele kergelt vastu tulla. Seega on mudel kasutatav siis, kui nõuded on selged ja nad muutuvad vähe.
• Koskmudel on sobilik suurtele süsteemidele, mida arendatakse mitmes erinevas kohas korraga. Sel juhul lubab eelnev korralik planeerimine töid paremini koordineerida

# Inkrementaalne arendusmudel

Tarkvaraarenduse üks võtmeküsimusi on - kuidas tulla toime muudatustega, sest suurte tarkvaraprojektide puhul on muutused vältimatud. Äritegevus muutub ja see toob endaga kaasa muutunud nõuded, tekivad uued tehnoloogiad, mida oleks otstarbekas tarkvarasüsteemides nende täiustamiseks rakendada ning muutuvad platvormid, millele süsteem on rajatud. Nimetatud muutused nõuavad ümbertegemist ning maksab nii nõuete korduv analüüsimine koos teostusega kui ka uute funktsionaalsuste realiseerimine. Muudatuste maksumust tuleb hoida nii väiksena kui võimalik. Seega tuleb arendusprotsessi tuua sisse tegevused, mis aitavad muudatusi ette näha enne kui nende sisseviimine olulist tööd nõuab. Näiteks prototüüpimise abil saab kliendile näidata varakult süsteemi olulisi omadusi. Muudatusi on parem teha siis, kui nende sisseviimine on võimalikult odav. Sellest tulenevalt on mõistlik toote järk-järguline (inkrementaalne) arendus ja üleandmine. Nii saab muudatusi teha ka nendes osades, mida pole veel arendama asutud.

Mõistelist segadust tekitavad iteratiivne ja inkrementaalne arendus. Alistair Cockburni järgi on tegemist kahe erineva arendusmudeliga:

• Inkrementaalne arendus on etapiviisiline ja ajagraafikut järgiv strateegia, kus süsteemi erinevaid osi arendatakse erinevatel aegadel ja erineva kiirusega ning kui üks osa valmis saab, integreeritakse see juba valmis süsteemiga.
  Alternatiivne strateegia oleks kodeerida kõik süsteemi osad ja siis kogu kood integreerida ühekorraga.

• Iteratiivne arendus on nö muutmisstrateegia, kus nähakse ette olemasolevate süsteemi osade ümbertegemine ja parandamine.
  Alternatiivne strateegia oleks planeerida tegevused selliselt, et kõik tehtaks õigesti esimesel katsel

Ian Sommerville järgi on iteratiivne arendusmudel pigem üldine nimetus mitmele nn hübriidmudelile (sh inkrementaal- ja spiraalmudel). Sõna "iteratiivne" rõhutab seda, et tegevused selles mudelis korduvad.

Sõltumata tähendusest, mis pannakse iteratiivse arenduse taha, on inkrementaalne arendus erinevates allikates üsna üheselt kirjeldatud.

Inkrementaalne arendus võib olla nii plaanipärane kui ka paindlik. Mudel näeb ette ehitada valmis algul väike osa süsteemist ning seda järgnevalt mitmes etapis laiendada. Inkrementaalne lähenemine võimaldab arendajatel ja ka tulevastel süsteemi kasutajatel varajastest iteratsioonidest õppida, saada tagasisidet veel siis kui on võimalik teha muudatusi nt süsteemi arhitektuuri kirjutamata kogu koodi ümber.

# Inkrementaalne arendus

Tarkvara spetsifikatsioon, projekt ja teostus jaotatakse osadeks (increment), mida asutakse ükshaaval arendama. Sel viisil väheneb ümbertegemist vajavate süsteemi osade hulk ja kliendid saavad võimaluse oma soove pikema aja vältel ringi mõelda. Tüüpiliseks tuleks pidada veel seda, et valminud süsteemi osad on kasutatavad ning see aitab kliendil oma edasistes soovides paremat selgust saada.

Tegevuste käik on järgmine: kõigepealt määratakse nõuded üldisemal kujul ning nad jaotatakse tähtsamateks ja vähemtähtsateks. Järgnevalt määratakse tarneosad – mitme tarnena ja millest koosnevana klient oma tarkvara saama hakkab. Tarne all mõeldakse süsteemi osa ehk inkrementi. Iga tarne peab lisama süsteemile kindla funktsionaalsuse. Sealjuures tootmist alustatakse kõrgema prioriteediga osadest. Kui süsteemi osad on määratud, võetakse ette 1. osa ja hakatakse seda detailiseerima, kasutades selleks sobivaimat protsessi (ja miks ka mitte koskmudelit). Samaaegselt saab täpsustada teiste osade nõudeid, kuid töös oleva osa nõuded on külmutatud. Kui väga vaja, pöördutakse selle osa juurde tagasi hiljem. Kui osa saab valmis, tarnitakse see kliendile, kes saab selle töösse rakendada (või vähemalt seda tõsiselt katsetada). See aitab kliendil täpsustada nõudeid järgmiste osade jaoks (või sama osa hilisemate versioonide tarvis). Seejärel võetakse käsile järgmine osa. Uued osad liidestatakse olemasoleva süsteemiga. Kõiki osi ei pea arendama sama protsessi kasutades.

Inkrementaalse arenduse eelised:

1. Kulutused, mida tehakse kasutaja nõuete muutumise tõttu, vähenevad, uuesti tehtava analüüsi ja dokumentatsiooni hulk väheneb oluliselt võrreldes koskmudeliga.
2. Kergem on saada kliendi tagasisidet juba tehtud arendustööle - kliendid saavad anda kommentaare valminud osadele ja ka näevad, kui palju on tehtud. Sel viisil on esimesed süsteemi osad nagu prototüübid kogu süsteemile.
3. Kliendile on võimalik kiiremini tarnida ja evitada loodavat tarkvara - kliendid võivad saada süsteemist reaalset kasu varem, kui see oleks võimalik koskmudeliga.

Inkrementaalse arendused probleemid:

1. Progress ei ole hästi jälgitav - haldurid vajavad pidevalt materjale progressi mõõtmiseks. Kiire arenduse korral ei ole tasuv tekitada dokumente iga pisikese versioonimuudatuse jaoks.
2. Süsteemi struktuur kipub halvenema uute osade lisandumisel - pidev muutmine rikub süsteemi struktuuri. Selle vältimiseks ja tarkvara kvaliteedi parandamiseks on vaja kulutada lisaks aega ja raha refaktoreerimisele. Halb struktuur muudab tarkvara hilisema muutmise keerulisemaks ja kulukamaks.

# Agiilsed arendusmeetodid

Agiilsete arendusmeetodite jaoks sobib kasutada inkrementaaset mudelit. Agiilse tarkvaraarenduse levimise algus läheb 2001 aastasse, kui senise üliplaanipärase arenduse vastased kirjutasid alla "The Agile Manifesto"-le, mille kõige olulisemates punktides rõhutakse inimesele ja inimeste vahelisele suhtlemisele:

• Inimesed ja suhtlemine on tähtsamad kui protsessid ja tööriistad.
• Töötav tarkvara on tähtsam kui dokumentatsioon.
• Koostöö kliendiga on tähtsam kui läbirääkimised lepingu üle.
• Muudatussoovidele vastutulek on tähtsam kui plaani järgmine.

Enam arvestatakse tagasiside (koormustestimine, kasutajate arvamus jm) käigus saadud infoga kui loodetakse hoolika etteplaneerimise tehnikale. Põhitähelepanu on inimestel, sh kasutajatel, ja pideval testimisel. Öeldakse, et agiilmeetoditega saavutatakse parem tulemus sama raha eest, aga agiilmeetoditega on raskem ette planeerida, millal tarkvara mingi funktsioon valmis saab – "Agile process will provide the most bang for the buck, but won't say exactly when that bang will be".

Tuntumad ja levinumad agiilsed arendusmeetodid on ekstreemprogrammeerimine (XP), Scrum, Feature Driven Development (FDD), Open Unified Process (OpenUP) jt

Ekstreemprogrammeerimine ehk XP on tuntumaid agiilmeetoodeid. XP-s viiakse sammud läbi äärmuslikult (ekstreemselt – siit meetodi nimetus) lühikestena, võrreldes klassikaliste arendusmudelitega – esimene sammude läbimistsükkel võib olla päevad või nädal pikk, samas kui klassikalistes mudelites kestab see kuid ja aastaid. Enne kodeerimist kirjutatakse automatiseeritud testid, mida tarkvara peab läbima, seejärel programmeeritakse paarides (so kaks programmeerijat ühe arvuti taga kodeerivad ühte programmilõiku - nn "paarisprogrammeerimine"). Kui valminud kood läbib testid, on programmeerimise samm antud iteratsioonis lõpetatud.

# Spiraalmudel

Spiraalmudel on samuti üks iteratiivseid arendusmudeleid.

Spiraalmudelit kirjeldas esimest korda Barry Boehm oma 1986 a. artiklis. Protsessi kulgemist kujutab spiraal. Esimene kordus võib olla näiteks seotud süsteemi teostatavuse uurimisega, teine nõudmiste kirjeldamisega, järgmine kavandamisega jne. Mitu kordust on enamasti seotud tarkvara realiseerimisega, kus tema ehitamine toimub inkrementaalselt. Kuid kindlasti ei tohiks spiraali korduseid võrdsustada tavapäraste arendusprotsessi faasidega. Iga kordus on jaotatud 3 kuni 6 sektorisse (erinevad autorid jagavad erinevalt). Iga kordus algab lähema eesmärgi kavandamise ja riskide hindamisega ning lõppeb nö kliendiga - ehk eesmärk peab saama täidetud ja kontrollitud. Sektorite töömahukus ei pruugi olla ühesugune. Boehm';i järgi on sektoreid neli (vt ka joonis 3):

Joonis 1-3. Spiraalmudel (Boehm 1988) (Allikas: I. Sommerville "Software Engineering" slaidid)

1. Eesmärkide seadmine (Objective setting) – määratakse selle faasi ehk korduse eesmärgid, piirangud protsessis, tulemused, juhtimisplaan, võimalikud riskid ning alternatiivsed strateegiad lähtudes riskidest.
2. Riskide hindamine ja maandamine (Risk assessment and reduction) – iga leitud riski jaoks tehakse analüüs, võetakse midagi ette riskide maandamiseks (nt risk, et nõudmised pole adekvaatsed: tehakse prototüüp)
3. Arendus ja valideerimine (Development and validation) – valitakse arendusmudel, mis lähtub hinnatud riskidest (mudel peab olema selline, mis riske vähendada aitab). Nt kui kasutajaliides on suurim risk, siis võib aidata prototüüpide tegemine.
4. Planeerimine (Planning) – projekt vaadatakse üle ja tehakse otsus, kas jätkata järgmisel kordusel, kui otsustatakse jätkata, tehakse järgmise faasi jaoks plaan.

Joonisel 3 on kujutatud üks näide spiraalmudelist. Tegelik arendusprotsess võib varieeruda nii iteratsioonide arvu kui ka tegevuste paigutuse osas.

Selle mudeli kõige olulisem erinevus teistest on riskidega arvestamine. Risk – so võimalus, et midagi saab untsu minna. Riskide realiseerumise tõttu ületatakse tähtajad ja maksumus, seepärast peab riskidega arvestama ning võtma midagi ette nende maandamiseks.

Sommerville';i järgi täpselt sellist mudelit kasutatakse harva, kuid ta on aidanud mõista iteratiivse arenduse olemust ja juhtinud tähelepanu riskidega tegelemise vajalikkusele.

# Prototüüpimine

Prototüüp on süsteemi algne versioon, mida kasutatakse disaini võimaluste katsetamiseks ning ideede demonstreerimiseks. Prototüüpe saab kasutada erinevates arenduse faasides. Näiteks nõuete analüüsi etapil nende leidmiseks ja valideerimiseks; disaini etapil valikuvõimaluste uurimiseks ning kasutajaliidese kavandamiseks

Kasu prototüüpimisest on: parem süsteemi kasutusmugavus, täpsem ühildumine kasutaja tegelike vajadustega; parem kvaliteet ja hooldatavus ning väiksem vaev arendamisel.

Joonis 1-4 Prototüübi loomise protsess

Prototüüpimise etapid on järgmised:

• Nõuete kogumine – seda tehakse üldisemal tasemel ja samas ka fikseeritakse, mida on kindlasti vaja edaspidi täpsustama hakata.
• Kiire kavandamine - keskendub nähtavale osale (sisend, väljund, vormid jms) ja selle tulemuseks on prototüüp. Klient hindab prototüüpi ja oskab selle alusel ka oma soove täpsustada.
• Järgneb iteratsioon prototüübi parandamiseks, kuni see rahuldab kasutajat. Samal ajal saab arendaja uusi teadmisi kliendi soovide kohta.

Prototüübi arendamisel on oluline, et see saaks loodud kiiresti, kasutades selleks abivahendeid (kiire prototüüpimise keeled ja tööriistad). Prototüüp ei pea sisaldama kogu funktsionaalsust - ta peab keskenduma sellele, millest ei ole hästi aru saadud; prototüübis ei pea olema vigade kontrolli ning prototüüp on suunatud funktsionaalsetele nõuetele (mitte näiteks turvalisuse probleemidele)

Prototüüpimist võib teha erineval põhimõttel - näiteks ühekordne prototüüpimine (Throwaway prototyping), evolutsiooniline prototüüpimine (Evolutionary prototyping), lisanduv prototüüpimine (Incremental prototyping).

Ühekordse prototüüpimise põhimõtted on järgmised:

Sellised prototüübid tuleb peale loomist likvideerida, sest nad ei ole heaks baasiks tegelikule süsteemile - näiteks ei pruugi nende alusel täita mittefunktsionaalseid nõudeid, prototüübi struktuur ei sobi edasiseks arenduseks ega vasta ka muudele kvaliteedi nõuetele.

Kokkuvõtvalt, erinevalt koskmudelist ei koostata iteratiivsete arendusmudelite järgi esmalt kõikehõlmavat analüüsidokumenti, milline sisaldab muutumatuid kasutajate vajadusi ning "kirjutatakse verega alla" süsteemi tellija ja realiseerija vahel – iteratiivsed mudelid võimaldavad lihtsamalt viia sisse muudatusi süsteemi, saada kasutajatelt varajast tagasisidet, testida arendusprojekti varajases faasis süsteemi arhitektuurilise lahenduse sobivust jmt.

Ei ole ühte, parimat süsteemiarenduse mudelit. Otsus, millist mudelit valida, tuleb langetada lähtuvalt konkreetsest tarkvaraprojektist: tulemist, meeskonna oskustest ja teadmistest, ajagraafikust, kliendi vajaduste selgusest ja stabiilsusest.

# B.1.2.4 Dokumentatsioon

Lisaks eelnevalt vaadeldud tegevustele, vaatleme nüüd tegevuste tulemeid ja tegevuste sooritajaid.

Süsteemi nõuete dokument on nõuete kogumise ja analüüsi tegevuse väljundiks, ning sisaldab kasutajate ning huvipoolte vajadustest lähtuvat süsteemi omaduste ja piirangute kogumit. Toome näiteid nõuetest: funktsionaalne nõue on, et kasutaja saab süsteemi abil hallata klientide andmeid ja arveid, turvanõude näide on, et süsteemist peab saama andmeid kätte ainult selleks volitatud isik. Tehnoloogiline piirang on, et kasutaja peab saama süsteemiga suhelda veebilehitseja abil.

Süsteemi nõuete dokument peaks katma järgmised teemad:

• sissejuhatus: dokumendi eesmärk, projekti ulatus, kasutatavate terminite ja lühendite seletused (nn süsteemi sõnastik), viited teistele dokumentidele, dokumendi struktuuri kirjeldus;
• toote kirjeldus;
• kasutajate ja huvipoolte profiilid, eesmärgid, vajadused, kogemused. Kasutajate kirjeldamine aitab paremini mõista kasutajate vajadusi ning oskusi loodava tootega ümber käia;
• piirangud: kasutajatest või ümbritsevast keskkonnast lähtuvad piirangud, nt olemasolevate süsteemidega seostamine, arendusvahendid, õigusaktid;
• eeldused ja sõltuvused: toote loomine võib eeldada teatud tingimuste täitmist, nt et peatselt jõustatakse õigusakt; kolmas osapool loob liidestatava süsteemi;
• käitluskeskkond – kirjeldab platvormid, millel toode peab töötama, sh operatsioonisüsteemid, riistvaraplatvormid, andmebaasimootorid, veebiserverid, rakendusserverid, monitooringuliidesed jms;
• kõikide funktsionaalsete ja tehniliste (turva-, kasutatavus- jm) nõuete detailne kirjeldus, sh kasutuslood ja UML kasutuslooskeemid.

Nõuete dokumendi koostab analüütik koostöös tulevaste kasutajatega.

Arhitektuurse disaini dokument kirjeldab süsteemi ülesehitust, süsteemi komponente ning mooduleid, liideseid komponentide vahel ja liideseid teiste süsteemidega. Kirjeldatakse ka füüsiline arhitektuur – riistvara ja näidatakse, milline tarkvara komponent millisele riistvarale paigutatakse.

Arhitektuurse disaini dokument peaks katma järgmised teemad:

• sissejuhatus: dokumendi eesmärk, viited teistele dokumentidele, dokumendi struktuuri kirjeldus;
• arendusvahendite valiku ja häälestuse, arenduskeskkond;
• kodeerimise, sh kommenteerimise ja nimetamise standardid;
• liidesed teiste süsteemidega, andmevahetusformaadid ja meetodid;
• toote sisemise struktuuri, ülesehituse: süsteemi jaotuse komponentideks, komponentide kohustused ja rollid, komponentide andmevahetus;
• arhitektuuriotsuste tausta, alternatiivid, valikukriteeriumid;
• jõudlusnõuded. Väljendatakse viisil, mida on võimalik testimise käigus kontrollida;
• suhtlusviisid kasutajatega, vigade kuvamise viisid;
• ressursinõuded, st kui palju toode nõuab mälu, arvutusvõimsust jms;
• turvalisuse tagamise meetmed;
• porditavus, so võimalus käitada tarkvara erinevatel platvormidel.

Süsteemi nõuded ja arhitektuursed otsused peavad olema omavahel ristviidatud, st vajadusel on võimalik mingi nõude muutmisel muuta temaga seotud arhitektuurilisi lahendusi, ning vastupidi – mingi arhitektuuriotsuse muutmisel nt rahalistel põhjustel leida, milliseid nõudeid selline muutmisotsus puudutab.

Arhitektuurse disaini dokumendi koostab arhitekt lähtudes nõuete dokumendis toodud nõuetest.

Kasutajajuhend on dokument, milline käsitleb kasutaja vaadet süsteemile – milleks toodet saab kasutada, kuidas toodet kasutada, millised on võimalikud veasituatsioonid ning nende lahendamine. Kasutajajuhend ei vaatle süsteemi "sisemust" vaid seda, mis on kasutajale nähtav.

Projektidokumentatsioon käsitleb projektijuhtimisega seotud materjale.

Haldusjuhend käsitleb toote installeerimist, andmesiiret, toote hooldust ja administreerimist, konfigureerimist, muudatuste sisseviimise korda.

# B.1.2 Kordamisküsimused

# B.1.3 Süsteemiarenduse vahendid

Selle alateema materjale läbi töötades saad teadmised tarkvara loomise analüüsimisest ning teostusega seotud vahenditest.

# B.1.3.1 CASE-vahendite kasutuseesmärgid ja klassifikatsioon

# B.1.3.2 CASE-vahendid elutsükli erinevatel etappidel

Tarkvara arendusprotsessi etapid nõuavad erinevat tuge süsteemiarenduse vahenditelt:

• projektijuhtimine:
  • projektiplaani koostamine ja jälgimine
  • ressursside haldus
• nõuete kogumine ja analüüs:
  • info kogumine: küsitluslehtede analüüs
  • talitlusprotsesside (äriprotsesside) modelleerimine
  • prototüüpimine, so piiratud funktsionaalsusega lahenduse loomine ja kasutajatelt selle põhjal tagasiside saamine
  • nõuete haldus: nõuete dokumenteerimine, viitamine, nõuete varustamine atribuutidega (nõude selgus, nõude allikad, jm), nõuete prioritiseerimine, nõuete versioonihaldus (seotuna muudatuse taotleja ja muutuse põhjendusega) jne
  • nõuete kogumist ja analüüsi toetav töövahend peaks võimaldama meeskonnatööd, sh võimaldama mitmel kasutajal samaaegset nõuete muutmist, võimaldama määrata erinevatele kasutajarollidele (projektijuht, analüütik, arhitekt, kasutaja) erinevaid õigusi
  • andmemudeli ja sõnastiku koostamine, vältides nii mitmetimõistetavusi ja andmete kvaliteediprobleeme (sh dubleerimist)
  • olemasolevast, dokumenteerimata koodist, automaatselt dokumentatsiooni genereerimine
• arhitektuurse disaini väljatöötamine:
  • võimaldama visualiseerida arhitektuurset lahendust, toetama valitud metoodikat ja ülesmärkimisviisi, st skeemide koostamise "keelt", nt UMLi?
  • kirjeldada tarkvara komponente ja nendevahelisi seoseid, liideseid
  • versioonihaldust, arhitektuuriotsuste seostamist nõuetega ja muudatustaotlustega
• programmikoodi loomine, testimine:
  • koodi, sh ekraanivormide, raportite, automaatne genereerimine arhitektuurse disaini alusel
  • silur (debugger) koodi samm-sammuliseks käivitamiseks ja testimiseks
  • testide läbiviimine, sh testide kirjeldamine, käivitamine, tulemuste analüüs ja dokumenteerimine
  • koodi kommenteerimine ja dokumenteerimine
  • koodi versioonihaldus
• toote konfiguratsioonihaldus:
  • koodi versioonihaldus.

# B.1.3.3 CASE-vahendite probleemid

# B.1.3 Kordamisküsimused

# B.1.4 Süsteemi testimine ja juurutamine

Selle alateema materjale läbi töötades saad teadmised testimise tüüpidest, samuti muudest tarkvara kasutusse võtmise ja töökindluse tagamise juures vajalikest etappidest.

# B.1.4.1 Testimise mõiste

Toote kvaliteet sõltub eelkõige toote valmistamise protsessi (tarkvara korral seega tarkvara arendusprotsessi) kvaliteedist ning toote arendajate-valmistajate (analüütikute, arhitektide, programmeerijate, projektijuhtide jt) teadmistest, oskustest ning motivatsioonist. Seega tarkvara kvaliteedi tõstmise viisideks on protsesside parendamine, inimeste koolitamine jms. Tarkvara on vaja ka kontrollida vigade suhtes ehk testida.

Testimine on kasutusel mitmetes inimtegevuse valdkondades: teaduses testitakse vaatluste ja eksperimentidega hüpoteese ning teooriaid, õppe läbiviimisel testitakse tudengeid, tootmises testitakse toodangut.

Testimise eesmärgiks on näidata, et tarkvara teeb seda, mis vaja ja avastada programmis vigu enne, kui see kasutusse antakse. Testimiseks tavaliselt käivitatakse tarkvara kasutades testandmeid. Edasi kontrollitakse testi tulemusi vigade ja anomaaliate leidmiseks või ka mittefunktsionaalsete omaduste kontrollimiseks. Testimise abil saab leida vigu, kuid mitte tõestada nende puudumist. Testimine on üks osa suuremast valideerimise ja verifitseerimise protsessist.

Tüüpilist testimisprotsessi kujutab järgmine joonis:

Joonis 1-6. Testimise protsess

Testjuhtumitele vastavalt valitakse testandmed (sisend) ja lisaks fikseeritakse, milline peab selliste andmete korral olema süsteemi käitumine või väljund. Süsteem käivitatakse valitud testandmetega ja tulemust võrreldakse oodatava tulemuse/käitumisega. Kui süsteem käitus oodatult, loetakse test läbituks. Kui mitte, siis on avastatud viga. Testi tulemuse registreerimiseks koostatakse aruanne. Milles viga täpsemalt seisneb, peavad välja selgitama arendajad ja selle siis parandama.

Tarkvara ja süsteemi ehk toote testimine on otseselt seotud toote kvaliteediga. Toode on kvaliteetne, kui ta rahuldab oma tööga vajadusi, millised motiveerisid toodet looma. Seega on vajalik vastavate testide läbiviimine tegemaks kindlaks, kas toode vastab täielikult kliendi nõuetele. Siiski, absoluutse kindluse, et toode ei sisalda vigu, saavutamine ei ole reaalsuses võimalik.

# Testimise eesmärgid

Eelnevat kokkuvõttes võib öelda, et testimisel on kaks suuremat eesmärki:

1. Näidata arendajale ja kliendile, et tarkvara vastab talle püstitatud nõuetele. Kliendi seisukohast tähendab see, et iga tema poolt soovitud ja nõuete dokumendis kirjas oleva funktsionaalsuse jaoks on läbi viidud vähemalt üks test (reeglina muidugi rohkem). Üldkasutatava tarkvara puhul aga seda, et testitud on kõiki tarkvaras ettenähtud põhiomadusi. Sellele eesmärgile vastavat testimist nimetatakse valideerimiseks. Edukas valideerimistest näitab, et süsteem töötab nii nagu vaja.
2. Leida olukordi, kus tarkvara käitub vigaselt, ebasoovitavalt või ei vasta spetsifikatsioonile. Vigade otsimine on seega mõeldud selleks, et likvideerida süsteemist mittesoovitud käitumine, nagu näiteks kokku kukkumised, mittesoovitud interaktsioonid teiste süsteemidega, vigased arvutused või rikutud andmed. Seda eesmärki täitvat testimist nimetatakse vigade testimiseks (defect testing). Siin on edukas test selline, mis näitab süsteemi vigast funktsioneerimist ehk teisisõnu leiab süsteemist vea (mida siis edasi parandama asutakse).

# Testimise tüübid

Pragmaatiliselt oodatakse tarkvaratootelt usaldusväärsust, st et tarkvara funktsioneerib soovitud viisil etteantud tingimustel. Funktsioneerimise viis ja opereerimise tingimused on vaja püstitada toote arenduse esimestel etappidel ning täpsustada kogu arendustsükli käigus. Praktikas on võimatu testida kõikvõimalike sisendparameetrite kombinatsioonidega ning võrrelda tarkvara väljundit oodatava väljundiga. Seega on väga oluline valida efektiivne komplekt testandmeid kombineerituna testimise tüüpidega. Tänapäeval on kasutusel ka automaattestid. Kõiki teste, näiteks kasutuskõlblikkuse teste, ei ole võimalik automatiseerida.

Testimise olemuseks on kontrolltegevused, et näidata kõikide tarkvarale esitatud nõuete täidetust. Samuti peab testimisel veenduma, et kõik parandamiseks esitatud defektid ka parandatud saavad ning parandused ei põhjustaks omakorda uusi vigu.

Kuna tarkvaratoote kvaliteet oleneb suures osas läbiviidavate testide tüübist, tuleb neid hoolikalt valida ja toote tellijaga kokku leppida. Osa testimist teeb programmeerija, osa testimist testijad ning lõpuks rakendatakse ka kliente-tellijaid. Järgnevalt lühike ülevaade erinevatest testimise tüüpidest.

• Moodultestimise korral testitakse konkreetset tarkvaramoodulit – ühte alamsüsteemi kogu süsteemist. Testimist viib üldjuhul läbi moodulit realiseeriv arendaja. Moodulit tuleb kindlasti testida enne, kui moodul integreeritakse ülejäänud süsteemi. Mooduli testimisel tuleb jälgida, et moodul vastaks analüüsis püstitatud nõuetele. Mooduli testimise eesmärgiks on siiski vigade leidmine, mitte kasutajanõuetele vastavuse tõestamine. Näiteks kas moodulisse lisatud funktsioonid töötavad korrektselt ning tagastavad õigeid vastuseid. Mooduleid testitakse andmetepõhiselt: õigete, puudulike ja vigaste andmetega. Tüüpiliselt on siin tegemist nn "valge kast" testimisega, st testija tunneb testitava tarkvara sisemist ülesehitust ja tööloogikat.
• Integratsioontestimise korral testitakse moodulitevahelist koostööd - kontrollitakse, kas kokku pandud moodulid töötavad omavahel ja kas iseseisvalt vigadeta töötanud moodulid koos vigasid ei genereeri. Testijana kasutatakse üldjuhul sõltumatut testijat, st testijat, kes ise ei arendanud testitavaid mooduleid. Näide integratsioonitestist on igaöine kompileerimine, et kontrollida arendatava toote käivitatavust.
• Süsteemtestimise korral testitakse süsteemi kui terviku töötamist. Süsteemi testimisel musta kasti meetodil vaadeldakse süsteemi kasutajale nähtavaid osi (kasutajaliidest), süvenemata koodi (siit nimetus "must kast"). Testjuhtumid koostab testija (peamiselt kasutuslugude põhjal), kes testid ka läbi viib. Testijaid peab olema nii tellija kui täitja poolel. Seda laadi testimist nimetatakse ka funktsionaalsuse testimiseks.
• Regressioontestimine on igat tüüpi tarkvara testimine, mida kasutatakse peale koodi/süsteemi viidud muudatusi. Näiteks uue funktsionaalsuse lisamisel, konfiguratsiooni muutmisel, paikamisel. Regressioontestimise eesmärk on veenduda, et muudatused ja veaparandused pole tekitanud süsteemi uusi vigu. Testitakse muudetud mooduleid (moodultestimine) ja nendega seotud mooduleid ning kogu süsteemi funktsionaalsust (funktsionaalsuse testimine). Peamiseks meetodiks on juba kasutatud testide taaskäivitamine veendumaks, et süsteem toimib, vanad vead ei avaldu uuesti ja ei ole tekkinud uusi. Regressioontestimist on kasulik automatiseerida üldise töökoormuse vähendamiseks.
• Jõudlus- ja koormustestid on ette nähtud süsteemi tehniliste nõuetele vastavuse läbiproovimiseks. Jõudlustesti on võimalik läbi viia mitmel moel – iga komponendi jõudlust eraldi mõõtes või suure hulga testandmetega süsteemi tavakasutamist katsetades. Jõudlustesti eesmärk on tuvastada kriitilisemad kohad, kus võib tekkida ülekoormus ja kulutada aeg nende kohtade optimeerimiseks. Kui tavaliselt mõeldakse testandmed korralikult läbi ning valitakse sisendid eesmärgist lähtudes, siis selle testimisel puhul on võimalik testida ka juhusliku, arvuti poolt genereeritud suure andmehulgaga.
• Valideerimise eesmärk on kinnitada, et tarkvara töö tulemid väljatöötatud kujul sobivad määratud kasutamiseks. "Kas me teeme õiget tarkvarasüsteemi?"
• Verifitseerimise eesmärk on kinnitada, et protsessi või projekti iga tulem vastab spetsifitseeritud nõuetele. "Kas me teeme tarkvarasüsteemi õigesti?"
• Kasutatavuse testid hindavad süsteemi kasutusmugavust kasutaja vaatenurgast: Kasutatavuse testi eesmärk on avastada vigu ja kohti, mida paremaks võiks teha, selleks jälgitakse inimesi toodet kasutamas. Kindlasti ei saa kasutatavuse testimiseks pidada seda, kui kliendile näidatakse tulevase toote prototüüpi / pilti ja küsitakse, kas on arusaadav. Testimiseks peab inimene täitma konkreetseid ülesandeid ja sel teel selguvad tarkvarasüsteemis või ka veebilehel halvasti arusaadavad kohad. Kasutatavuse testimiseks sobivad nö "inimesed tänavalt", kes süsteemi esimest korda näevad. Aga ka eksperdid, kes oskavad kogemustest ja teooriatest lähtuvalt leida kasutusmugavuses nõrku kohti.
• Vastuvõtutest ehk aktsepteerimistest on kliendi poolt läbiviidav test valminud toote hindamiseks ja vastuvõtmiseks. Vastuvõtutesti testijuhtumid kirjeldavad üheselt projekti üleandmise ja vastuvõtmise kriteeriumid ning testijuhtumid peavad olema konkreetsed ja mõõdetavad ning nendes lepivad tellija ja teostaja projekti realiseerimise eel kokku;
• Koodi läbivaatus – erinevalt eelnevalt käsitletud testi tüüpidest, koodi läbivaatuse puhul koodi ei käivitata vaid koodi inspekteeritakse testija poolt. Läbivaatus eeldab küsimustiku olemasolu, mille alusel koodi hinnata ning sealt vigu otsida, mis tavatingimustes testides ei pruugi avalduda. Läbivaatajad peavad olema väga kompetentsed ka näiteks kasutatava keele osas. Mida otsitakse? Näiteks algväärtustamata muutujaid, ebasobivalt valitud andmetüüpe, muutujate või massiiviindeksite väljumist lubatud piiridest, tehete järjekorda, erinevate muutujatüüpide kokkusobivust jne.

Eelnimetatud tehnikaid tuleb kombineerida. Testitavaid omadusi on terve hulk, silmas tuleb pidada seda, et testimiseks on vaja, et toote nõuete püstitamise etapis vastava omaduse kohta ka nõuded püstitati ning püstitati viisil, mis võimaldab toote nõuetele vastavust kontrollida ehk mõõta. Loetleme allpoolt olulisemad nõuded tarkvara omadustele :

• funktsionaalsus – toote omadus väljendamaks tema sobivust seatud ülesannete täitmiseks, st tarkvaraga saab teha seda, mida klient vajab;
• turvalisus – toote omadus piirata äriloogikale/andmetele ligipääsu autoriseerimata isikute poolt;
• tõrkekindlus – toote omadus väljendamaks võimet tagada teatud jõudluse ja funktsionaalsuse tase veaolukorra tekke või liidese väärkasutamise puhul;
• taastuvus – toote omadus väljendamaks võimet taastada normaalne töörežiim ja jõudlus peale veaolukorra tekkimist;
• taastatavus – toote omadus väljendamaks keerukust ja vajaminevat töö hulka ning aega süsteemi põhifunktsionaalsuse taastamiseks avariiolukorra puhul;
• efektiivsus , jõudlus – toote omadus väljendamaks reageerimisele ja andmete töötlemisele kuluvat aega koormuse all;
• kasutatavus
  • mõistetavus – toote omadus väljendamaks vajaminevat aja hulka, mille jooksul kasutajad mõistavad süsteemi loogilist kontseptsiooni ja rakendatavust;
  • õpitavus – toote omadus väljendamaks vajaminevat aja hulka, mille jooksul kasutajad suudavad süsteemi kasutama õppida (näiteks andmete sisestamine/väljastamine jne);
  • kohaldatavus – toote omadus väljendamaks süsteemi paindlikust ja lõppkasutaja poolt enda jaoks sobivaks muutmise keerukust;
  • atraktiivsus – toote omadus väljendamaks lõppkasutajate rahulolu toote poolt pakutavate teenuste, esitluse ja käitumisega;
• stabiilsus – toote omadus väljendamaks muudatustejärgsete ootamatute nähtuste tekkimise riski suurust;
• taaskasutatavus – toote omadus väljendamaks toote osade taaskasutamise võimalusi teistes tarkvaraprojektides;
• porditavus – toote omadus väljendamaks aja- ja töökulu toote kohaldamisel teistesse keskkondadesse, platvormidele.

Erinevate testi tüüpide ja arendusetappide vastavust illustreerib alljärgnev joonis. Pidevad nooled näitavad tarkvaratoote arendusprotsessi sammude ajalist kulgu, punktiirjooned seoseid testi tüüpide ja arendusetappide vahel: nt moodultest kontrollib valminud mooduli vastavust mooduli spetsifikatsiooniga, milline sünnib detailse projekteerimise sammus; süsteemitest vastab tarkvara nõuete püstitamise sammule ning vastab küsimusele, kas valminud süsteem tervikuna täidab püstitatud nõudeid. Vastuvõtutest vastab küsimusele, kas tarkvaratoode vastab kliendi vajadustele, ehk kas toode on küps kasutuselevõtuks ja/või müüki paiskamiseks.

Joonis 1-7. Tarkvaratoote testimise V-mudel. Mudel on osaliselt inspireeritud koskmudelist

Testimise käigus leitud vead tuleb dokumenteerida. Dokumenteerimine ei tähenda tingimata paberdokumendi vormistamist, pigem kasutatakse spetsiaalseid CASE-vahendeid, nt Mantis ja Bugzilla, mis abiks ka vearaportite edastamisel programmeerijatele.

Toote kvaliteediga on – lisaks testimisele – seotud ka ülevaatused. Ülevaatus on tegevus, milline viiakse tavaliselt läbi rühmatööna. Ülevaatuste käigus arutatakse ja hinnatakse tarkvaratoote projekti staatust, riske, tehakse otsustusi ressursside juhtimise ning toote nõuete-lahenduste vallast. Otsused peaks protokollima, määrates isikud, kes vastutavad otsuste tähtajalise elluviimise eest.

Ülevaatuste eriliigid on:

• tehnilised koosolekud, millistel osalevad toote arhitektid, analüütikud, projektid, kliendid. Analüüsitakse ja tehakse toote ülesehitust puudutavaid otsuseid;
• koodi läbivaatused;
• auditid, mida üldjuhul viivad läbi sõltumatud, välise organisatsiooni esindajad. Hinnatakse muuhulgas toote ja/või arendusprotsessi vastavust nõuetele, standarditele, formaalsetele protseduuridele, lepingutele jm. Maailmas tuntuim IT-audiitorite organisatsioon on ISACA (http://www.isaca.org), kelle poolt sertifitseeritud audiitorid kannavad CISA-tiitlit (Certified Information System Auditor – sertifitseeritud infosüsteemide audiitor).

# B.1.4.2 Tarkvarasüsteemi juurutamine

Testitud tarkvaratoode tuleb võtta kasutusele. Süsteemi kasutusele võtt hõlmab kogu tarkvaraprotsessist juurutuse deployment, andmeülekande vanast süsteemist, kasutajate ja süsteemi administraatorite koolituse, toe süsteemi kasutajatele ja paranduste sisseviimise juurutusjärgselt ilmnenud vigade parandamiseks.

Tarkvaratoote kasutusele võtt sisaldab mitmeid erinevaid samme. Puudub täpne protsess, sest situatsioon, kus tarkvara juurutatakse, varieerub erinevate klientide juures oluliselt. Siiski järgmised tegevused on reeglina vajalikud:

• tarkvaratoote levitamine , st installeerimine riistvarale. Keerukamate, hajutatud süsteemide on abiks UML levitusskeemid millised kirjeldavad tarkvara paiknemist erinevatel riistvara sõlmedes, sealhulgas:

• Avalikustamine (release). Avalikustamine järgneb arendusprotsessile. See sisaldab kõiki tegevusi, et süsteem ette valmistada assembleerimiseks (masinkoodi viimiseks) ning kliendi juurde üleviimiseks. Selle tegevuse käigus määratakse ka ressursid, mis on vajalikud töötamiseks kliendi poolel.

• Tarkvara installeerimine ja aktiveerimine - käivituvad komponendid paigutatakse arvutitele-serveritele, kus nad edasipidi töötama peavad. Keerulisemad süsteemid vajavad lisaks ka muu toetava tarkvara installeerimist (nt andmebaasimootori uus versioon jms). Tihti installeeritakse suurem süsteem mitmesse keskkonda - näiteks lisaks ka testserverile, mida saab hiljem kasutajakoolituseks ja muudeks katsetusteks kasutada.

• Kohandamine ja uuendamine - uuendamise käigus installeeritakse uus versiooni süsteemist, kohandamine on samuti süsteemi muutmine, kuid põhjuseks on peamiselt muudatuse kliendipoolses keskkonnas.

• andmeülekanne vanast süsteemist - varem kasutatud süsteemis on reeglina andmed, mida tuleb ka edaspidi kasutada. Soovitav on automaatülekandevahendi loomine, milline käivitatakse ühekordselt andmete ülekandeks vanast süsteemist uude. Ülekandemehhanism võib olla päris keerukas, eriti kui vana süsteemi ja uue süsteemi andmestruktuurid on oluliselt erinevad. Kui andmete kogus on väike ja/või automaatteisenduse algoritmi väljatöötamine liigselt keerukas, on võimalik andmeid ka käsitsi üle kanda. Sellisel juhul võib olla vajalik luua raportid vanast süsteemist andmete väljavõtmiseks ja sisestusvormid vm vahendid andmete käsitsi sisestamiseks kasutuselevõetavasse süsteemi;

• muudatuste tegemine teistesse rakendustesse , millised peavad töötama koos ja/või kasutatakse koos arendatava tarkvaratootega;

• koolituse ettevalmistamine ja läbiviimine tarkvaratootega kokkupuutuvatele inimestele, sh järgmistele rollidele:

  • igapäevased kasutajad
  • administraatorid
  • kasutajatoe pakkujad.

  Koolitus peab hõlmama nii teoreetilist kui praktilist osa. Praktilise osa on soovitav läbi viia testimiseks ja/või koolituseks loodud keskkonnas (nii tarkvara kui andmed), seda eelkõige ennetamaks riske reaalsete andmete konfidentsiaalsuse, käideldavuse või tervikluse huvides;

• valmisoleku loomist kriisiolukorra juhtimiseks ja kriisiolukorras käitumiseks. Võimalikud kriisid tarkvaratoote kasutusele võtul on:

  • programmi mittetoimimine töökeskkonnas
  • vigade avastamine programmis
  • andmete kadu.

Viga tarkvaratootes võib tuua kaasa äriprotsesside katkemise ja suure majandusliku ning renomee kahju äriettevõttele või avaliku sektori asutusele. Kriisiolukorraks ettevalmistamise käigus lepitakse kokku rollid, protsessid ja juhtimise, kuidas kriisiolukorras käituda, kuidas suhelda kasutajate ja kriisireguleerijatega, kas ja kuidas teavitada avalikkust, kuidas vajadusel ja võimalusel võtta vana tarkvaratoode kasutusele jms.

Tarkvara kasutuselvõtu riskiks on ka inimesed. Eriti võib see avalduda tarkvara esmakordsel juurutamisel, kus võib tekkida suur vastuseis. Osa sellest riskist saab maandada eelpool mainitud koolituste abil. Lisaks on vajalik läbi mõelda igapäevased protseduurid. Kas seni kasutusel olnud protseduurid saavad samal viisil toimida nüüd, kui kasutusel tarkvarasüsteem? Tihtipeale ei saa. See võib põhjustada suurt inimlikku segadust ning lisada vastasseisu uuendustele. Seega lisaks tehnilistele õpetustele tarkvarasüsteemi kasutamise osas tuleb õpetada töötajaid läbimõeldult nö uut moodi asju ajama.

Näiteks kuidas peaks peale digitaalse dokumendihaldussüsteemi kasutuselevõttu käituma arvega, et see raamatupidaja poolt ülekantud saaks? Või kuidas saab õpilane peale uue õppeinfosüsteemi kasutuselevõttu teada järeleksamitest, mida enam seinale ei riputata?. Üldisemalt öeldes võib olla tarkvara kasutuselevõtmisel vajalik äriprotsesside ümberkujundamine, millel on kaks poolt - äriprotsesside kohandamine, mis esindab organisatsioonilist vaadet ning vastuvõtt ja heakskiitmine, mis esindab üksikisiku vaadet.

Juurutuetapi läbimiseks pakub Capers Jones oma raamatus Software Engineering Best Practices välja järgmised head tavad (best practices):

• Ühine sama rakenduse kasutajate võrgustikuga (kui selline on olemas)
• Küsi praegustelt tarkvarakasutajatelt nõu ja soovitusi tarkvara juurutamiseks.
• Leia konsultandid, kellel on juurutamiskogemus.
• Muretse tarkvara sobilike erikursuste loomiseks ning leia sobivad kursused
• Kohanda tarkvara kohalikeks vajadusteks.
• Tekita liides arendatava uue tarkvara ja väljavahetatava tarkvara vahele.
• Registreeri ja teavita vigadest ning defektidest, mis juurutamise jooksul ilmnevad.
• Installeeri tarkvaratootja paigad ja uuendused.
• Hinda uue rakenduse edukust.

Sama autori järgi võib juurutusetapp olla väga pikk isegi 12 kuud, nõuda mitmekümne inimese tööd ning ca 1 miljon $ raha. Tarkvara, mis ei ole otse antud firmale loodud, võib vajada ka päris pikka ja põhjalikku kohandamist, et seda saaks üldse kasutada.

Eelnevalt kirjeldatud tarkvaratoote juurutamine on pigem ühekordne tegevus. Vastavalt tarkvaraelutsükli mudelitele järgneb hoolduse faas , mis sisuliselt kestab seni, kuni tarkvara kasutuses püsib.

Seoses muudatustega ärikeskkonnas, seadusandluses, äri toimimises on vajadus tarkvaratoodet kaasajastada, samuti nõuavad tarkvaratootes avastatud vead parandamist. Tarkvaratoote muudatuste halduse aitab läbi viia kokkulepitud kord ja ka spetsiaalsed CASE-vahendid, millised võimaldavad teavitada vigadest tootest või muudatusvajadustest; muudatusnõudeid prioritiseerida olulisuse, kriitilisuse jm alustel, muudatuste realiseerimist täitmiseks suunata, hallata tarkvaraversioone jm.

Ka suuremate muudatuste sisseviimisega tarkvarasse (nt uute funktsionaalsuste lisamisega) kaasnevad vähemalt osaliselt eespool kirjeldatud juurutusetapid.

# B.1.4.3 Juurutusmeetodite tugevad ja nõrgad küljed

# B.1.4.4 Kasutusjuhend ja tehnilised juhendid

# Kasutusjuhend

Kasutusjuhend user guide on tehniline dokument, mis peab pakkuma tuge konkreetse süsteemi kasutajatele. Mõistena kasutatakse ka sõna manuaal manual. Ka parimast tarkvarast ei ole kasu, kui kasutaja ei oska teda kasutada. Kogu kasutaja dokumentatsiooni kuuluvad lisaks kasutusjuhendile hooldusjuhised, töös hoidmise juhend, õppematerjal ja teised materjalid-juhendid süsteemi spetsiifikast lähtudes.

Kasutusjuhendi peab süsteemile kaasa andma arendaja. Hea on, kui juhendi kirjutab tehniline kirjutaja technical writer, kellel on sellise materjali kirjutamise kogemus, mitte aga programmeerija. Väikesemas firmas tavaliselt eraldi kirjutaja puudub ning seda tööd peab tegema haldur või mõni teine tehnilise personali liige.

Tavaliselt lisatakse kasutusjuhendisse ekraanipildid, mis lihtsustavad arusaamist. Kasutatav keel peab olema võimalikult lihtne ning sobima auditooriumile. Ei ole sobiv kasutada žargooni ning erimõisted tuleks lahti seletada.

Kasutusjuhend koosneb:

• pealkirjast ja autoriõiguste selgitusest
• eessõnast, mis annab soovitusi juhendi kasutamiseks ja sisukorrast
• juhendist (olulisemate) süsteemi funktsionaalsuste kasutamiseks
• veaselgituste (troubleshooting) osast, mis peaks hõlmama olulisemad probleemid ja nendega toimetuleku võimalused

Tihti lisandub ka korduma kippuvate küsimuste osa FAQ, mida on kergem pidada ja vajaduse korral täiendada digitaalses vormis, kontaktandmed, viited lisamaterjalidele, sõnastik ja indeks.

Vaata näiteks Google Earthi kasutusjuhendit:

http://earth.google.com/support/bin/static.py?page=guide_toc.cs

Juhend ise peab andma juhiseid lõppkasutajale tema töö tegemiseks ning sisaldama:

• sisendite kirjeldust : millist informatsiooni ootab süsteem kasutajalt, milline peaks olema sisendi formaat ja väärtuste lubatud piirid, kuidas andmeid sisestada (klaviatuur, andmefailid jms) jne
• väljundite kirjeldust: milline on väljundid, kuidas neid interpreteerida, samuti peaks juhend kirjeldama ebastandardset väljundit ehk nt veateateid ja nende tähendust jms
• funktsionaalsuste kirjeldust: kuidas süsteemi tegelikult tööle panna, kuidas toimida ühe või teise eesmärgi saavutamiseks.

Kasutusjuhend võib olla organiseeritud kolmel erineval viisil, mis on sobilikud erinevale auditooriumile ja erineva kogemusega kasutajale:

• Õppematerjal (tutorial) - tüüpiliste funktsioonide sammsammuline kirjeldus. See variant sobib algajale esmaseks tutvumiseks tarkvarasüsteemiga
• Temaatiliselt jagatud materjal - iga peatükk on pühendatud omaette teemale, sisaldab reeglina põhjalikumat funktsionaalsuste kirjeldust võrreldes õppematerjaliga ja seetõttu sobib edasijõudnumale kasutajale süsteemi uute võimaluste avastamiseks
• Tähestikulises järjekorras organiseeritud informatsioon - see on vajalik kogenud kasutajale kui teatmematerjal, et midagi meelde tuletada.

Et kasutusjuhendid on enamasti digitaalsed, siis aitab viimast rolli täita ka otsimisvõimalus.

Kasutusjuhendi üks olulisemaid tingimusi on aga see, et ta vastaks tegelikkusele. Tihti kipub ett tulema olukord, kus süsteemi esimesele versioonile on küll loodud juhend, kuid süsteemi täiendamisel jääb (ununeb?) juhend muutmata ja ebaadekvaatne juhend on päris parajaks segaduste allikaks.

# Tehniline dokumentatsioon

Tehniline dokumentatsioon technical reference document on dokumentide kogum, mida kasutatakse tehniliste objektide konstrueerimisel või projekteerimisel, tootmisel (valmistamisel) ja kasutamisel.

Tehniline dokumentatsioon sisaldab tarkvarasüsteemi tehnilist kirjeldust, sh dokumente, mis on tekkinud arendustegevuse käigus. Et erinevad arendusmetoodikad käsitlevad arenduse käigus toimuvat dokumenteerimist veidi erineval viisil, siis on raske anda ühest loetelu dokumentatsiooni osadest.

Kitsamalt peetakse tehnilise dokumentatsiooni all silmas dokumente, mis on abiks süsteemi hooldamisel, töös ja ajakohasena hoidmisel (nt kuidas installeerida uuendusi). Dokument kirjeldab tarkvarasüsteemi ülesehitust (koodi ja muude failide loetelu). Võimalik on ka kommenteeritud lähtekood. Seega võib osa tehnilisest dokumentatsioonist paikneda tarkvara enda sees. Lisaks veel andmestruktuuride ja keerulisemate algoritmide kirjeldused, Dokumentatsioon võib sisaldada mitmeid jooniseid, mida saab näiteks esitada modelleerimiskeeles UML. Tehnilise dokumentatsiooni koostamisel võib olla abi spetsiaalsetest dokumendigeneraatoritest. Näiteks oskab selline generaator kokku korjata kõigi moodulis olevate funktsioonide päised ning päisele järgnevad kommentaarid ning moodustada sellest eraldi dokumendi. Ja ongi olemas dokumenteeritud ülevaade sellest, mida moodul sisaldab ja mida selles olevad funktsioonid teha oskavad.

Süsteemi ülesehituse kirjeldusest on kasu nendele, kes süsteemist vigu otsima või muudatusi ning uusi funktsionaalsuseid lisama peavad.

# B.1.4 Kordamisküsimused

# B.1.5 Süsteemi juhtimine ja turvalisus

Selle alateema materjale läbi töötades saad teadmised, millistes keskkondades milliseid tegevusi on mõistlik ette võtta ning tutvustatakse, milliseid toiminguid on tarvis rakendada süsteemi turvalisuse tagamiseks.

# B.1.5.1 Süsteemi loomise keskkonnad

Arenduskeskkond (development environment) on keskkond, kus on kasutatav kogu vajalik funktsionaalsus tarkvara süsteemi arendamiseks. Arenduskeskkonda võib mõista erinevatel tasanditel. Näiteks programmeerija põhitöövahendiks on integreeritud arenduskeskkond (nn IDE), kus on kõik vahendid mugavaks koodi loomiseks, kompileerimiseks jne. (Vt ka B1.3). Kõrgemal tasemel on arenduskeskkond seadistus koos arendusserveri, andmete, andmebaasimootorite ja muu vajalikuga, et katsetada ja testida arendatava süsteemi osade tööd. Sellisel keskkonnal on ka inglisekeelne nimetus sandbox.

Testmiskeskkond (test environment) on oluline vahelüli arenduse ja tegelikku töökeskkonna vahel. See koosneb riistvarast (serverid, töökohaarvuti(d), jms) ja loogilise taseme komponentidest (Serveri operatsioonisüsteem, kliendi operatsioonisüsteem, andmebaasiserver, kliendi kasutajaliides, veebilehitseja jms tarkvara, mis on vajalik kogu süsteemi käitamiseks). Oluline on, et keskkond hõlmab nii kliendi kui ka serveripoolset osa ning kasutab täpselt samu versioone tarkvaradest, mis on kliendi juures ehk on võimalikult sarnane töökeskkonnale. Vastasel juhul võib selguda juurutusprotsessis, et süsteem ei tööta ja on vaja ümber teha. Testimiskeskkonnas tehakse funktsionaalseid ja jõudlusteste, testitakse süsteemi uuendusi ja veaparandusi. Samas võivad toimuda ka kasutajapoolsed vastuvõtutestid. On rusikareegel, et kogu testimiskeskkond on eraldatud töökeskkonnast ja kõik uuendused ja parandused kontrollitakse-testitakse eelnevalt testimiskeskkonnas ja alles seejärel installeeritakse need töökeskkonda. Testimiskeskkond sobib ka klientide koolitamiseks, mis tagab, et selle käigus ei rikuta nt andmeid.

Töökeskkond (production environment) on keskkond, kus toimub tegelik töö, st mida firma tarvitab oma igapäevases äritegevuses. Sarnaselt testimiskeskkonnale on ta täielik installatsioon kogu vajalikust riist- ja tarkvarast. Töökeskkonna peal ei ole õige katsetada süsteemi uuendusi, sest see võib halvata äritegevuse. Katsetamiseks on testimiskeskkond. Koolituse võimalikkus sõltub pigem sellest, mida konkreetselt tehakse ja kas see võib õppija kogenematuse tõttu mingeid kahjusid põhjustada.

# Konfiguratsioonihaldus ja versioonihaldus

Tarkvarasüsteemi loomisel ning tema hilisemal parandamisel ja muutmisel töötavad mitmed arendajad. See tegevus kestab aastaid ja selle aja jooksul tekib tarkvarast mitmeid variante - nn versioone. Et tarkvarauuenduste töösse andmine ja vajadusel vanemate versioonide taastamine sujuks, on tarvilik järgida mingeid protseduurireegleid, süstematiseerida kogu tekkinud koodi ja vastavat dokumentatsiooni: uuendusnõudeid, vearaporteid jne.

Iga tarkvara muutub ja on kui hulk erinevaid versioone. Uued versioonid realiseerivad muudatusettepanekuid, vigadeparandusi, kohandamisi teiste riistvara ja operatsioonisüsteemidega. Koge selles muutuste virrvarris on vaja korda ja süsteemi.

Konfiguratsioonihaldus (configuration management) on väljatöötamisel oleva tarkvarasüsteemi koodibaasi ja dokumentatsiooni haldamine, järgides protseduure ja kasutades sobivat tarkvara. Konfiguratsioonihaldus on vajalik, et mitte kaotada järge muudatuse ja komponentide versioonide üle erinevates süsteemi versioonides. Konfiguratsioonihaldusega võib tegeleda lausa eraldi meeskond, kelle ülesandeks on jälgida ja tagada, et tarkvarauuendused lisanduksid süsteemi juhitud viisil ning info muudatuste kohta pandaks kirja ning säilitataks piisava detailsusega. Et uuendusi viivad siiski sisse arendajad, siis on nende töö süstematiseerimiseks sisseviidud selged protseduurireeglid. Nt millistel tingimustel võib uue koodi lisada olemasoleva süsteemi juurde, millal kõike kokku kompileerida, kuhu ja kuidas muudatused registreerida jne.

Konfiguratsioonihalduse protsess jagatakse muudatuste halduseks, versioonihalduseks, süsteemi järkude (build) ja redaktsioonide (release) halduseks.

Versioonihalduse ülesandeks on pidada järge tarkvara kõigi komponentide versioonide ja nendes tehtud muudatuste üle. Sellega tagatakse ka, et erinevate arendajate tehtud muudatused ei hakkaks üksteist segama.

Edukaks versioonihalduseks tasub kasutada vastavat tarkvara (nt CVS, Git, Subversion jt). Hea tarkvara lubab isegi üheaegset tööd sama faili kallal.

Versioonihaldusega on tihedalt seotud järkude haldus.

Süsteemi järk on tarkvara versioon, mis tarnitakse kasutajale. Üldkasutatava tarkvara jaoks (kontoritarkvara jms) eristatakse kahte tüüpi järke: peajärk (major release) toob kaasa mõne olulise uue funktsionaalsuse ja pisijärk (minor release) parandab mõne vea või kasutaja teatatud probleemi. Eritarkvara puhul võivad erinevatel klientidel olla tarkvarast erinevad järgud/versioonid ning igaüks neist võib areneda omasoodu. Nii võib ühest süsteemist töötada samaaegselt mitu erinevat versiooni. Probleemi ilmnemisel tarkvara kasutamisel peab olema võimalik taastada täpselt selline tarkvara variant, nagu see on sellele kliendile antud. Seetõttu peab järkude info olema piisava detailsusega säilitatud ehk iga järk tuleb dokumenteerida selliselt, et see oleks hiljem taasesitatav.

# B.1.5.2 Andmeturve

Igasugusel andmetena talletataval või edastataval informatsioonil, sh ka tarkvaratoote koodil, on väärtus tarbija (inimese või tehnilise süsteemi) jaoks. Seetõttu on vajalik andmeturve, mis peab tagama andmete väärtuse säilimise, st andmete turvalisuse. Traditsiooniliselt on andmete turvalisuseks peetud eelkõige nende konfidentsiaalsust ehk salastatust. Tänapäevalgi kiputakse tihti samastama andmeturvet salastusega, kuigi andmeturbe ulatus on tunduvalt laienenud. Andmete turvalisus kui üldeesmärk on mitmemõõtmeline ja koosneb osaeesmärkidest.

Mitmesuguste turbemetoodikate aluseks võivad olla erinevad turvamudelid, mis hõlmavad 3-6 osaeesmärki. Levinuim on turvamudel, mis põhineb kolmel osaeesmärgil, andmete kolme omaduse ja nimelt käideldavuse, tervikluse ja konfidentsiaalsuse tagamisel.

Andmete käideldavus on eelnevalt kokkulepitud vajalikul/nõutaval tööajal kasutamiskõlblike andmete õigeaegne ja hõlbus kättesaadavus (st vajalikul/nõutaval ajahetkel ja vajaliku/nõutava aja jooksul) selleks volitatud tarbijaile (isikutele või tehnilistele vahenditele). Käideldavus on esmane nõue iga infosüsteemi kõigile andmetele ja muudele infovaradele; käideldavuse kadumisel on kogu infosüsteem tarbetu.

Andmete terviklus on andmete õigsuse/täielikkuse/ajakohasuse tagatus ning päritolu autentsus ja volitamatute muutuste puudumine. Asutuse normaalse töö üks eeldusi on, et iga andmekogumi (dokumendi, faili, säiliku, registri kirje jne) kohta saab teha kindlaks, kes ja millal on selle loonud, ning olla kindel selles, et see andmekogum ei ole pärast loomist stiihiliste tegurite toimel või kellegi tegevuse tulemusena volitamatult muutunud. Kõik andmed peavad alati olema seostatavad nende looja, loomisaja, konteksti jms asjaoludega ning nende seoste rikkumisel, samuti andmete endi kaotsiminekul või muutumisel on tööd negatiivselt mõjutavad tagajärjed.

Andmete konfidentsiaalsus on andmete kättesaadavus ainult selleks volitatud tarbijaile (isikutele või tehnilistele süsteemidele) ning kättesaamatus kõigile ülejäänutele.

Avalike andmete turbe korral peavad olema tagatud käideldavus ja terviklus.

# Riskid

Risk on võimalus, et millegi tegemisel või tegemata jätmisel tekib ebasoodne olukord, mille tulemuseks on kaotus. Riske tuleb ette näha ja püüda nende mõju vähendada. Riskiga tegelemise vajalikkuse üle saab otsustada peale vastavat analüüsi. Iga riski kohta saab määrata tema esinemistõenäosuse (madal, keskmine kõrge) ning milline on riski realiseerumise tagajärg (ebaoluline, talutav, tõsine, katastroofiline).

Iga süsteemi (sh tarkvarasüsteemi) tööga kaasnevad riskid. Kaasaegsed tarkvarasüsteemid hoiavad ja töötlevad erinevaid andmeid (meditsiinilisi, isikuandmeid, militaarandmeid ja ka salastatud andmeid). Nende andmete vastu on huvi organiseeritud kuritegevusel, terroristidel jms. Andmed on häkkerite, viiruste ja nuhkvara võimaliku rünnaku igapäevase riski all. Riski kujutavad endast ka ebalojaalsed töötajad, kes võivad andmeid varastada. Neid riske saab vähendada ehitades tarkvara turvaliseks ja võimalikult turvaauguvabaks. Ligipääs andmetele peab olema turvatud nii tarkvaraliselt kui ka riistvaraliselt. Üheks riskide allikaks on ka tõrked süsteemi töös. Ühelt poolt võivad need anda võimaluse andmetele ligipääsuks, teisalt mõjutab süsteemi kokkukukkumine firma igapäevast äritegevust ehk tekib oht, et firma ei saa täita oma põhifunktsioone.

Üheski praktilises süsteemis ei ole olemas täielikku turvet, st täielikku käideldavust, täielikku terviklust ja täielikku konfidentsiaalsust. Millistele infoturbe aspektidele tuleb konkreetsete andmete korral tähelepanu pöörata, oleneb konkreetsest infosüsteemist ja selle otstarbest, st käideldavate andmete väärtusest. Enamasti tuleb arvesse võtta turvalisuse kõiki kolme komponenti, kuid erinevate kaaludega. Organisatsioonis nõutav infoturbe tase sõltub organisatsiooni ülesannetest, õigusaktidest ja eeskirjadest, organisatsiooni tegevuse sisemisest korraldusest, infosüsteemide ja ka teenuseandjate ja koostöö- või lepingupartnerite tagatud või nõutud turvatasemest jms. Niisiis tähendab andmete turvalisus , et on saavutatud kolm eesmärki: teabe käideldavus, teabe terviklus, teabe konfidentsiaalsus.

# B.1.5.3 Süsteemide turvalisuse tagamine

Süsteemide turvalisuse aspekte tuleb arvestada alates arendusprotsessi esimestest sammudest – kasutaja vajaduste, süsteemi visiooni ja süsteemi nõuete püstitamisel. Efektiivsem ja majanduslikult odavam on vajalikud turvameetmed projekteerida ja realiseerida süsteemis loomise ajal, mitte käsitleda turvalisust kui midagi tülikat ja otseselt tulu mittetoovat ning lisada turvameetmed peale toote kasutuselevõttu ja esimest tõsist turvaintsidenti. Turvalisus ei ole "pealisehitus", turvalisus on toote omadus

Oluline on mõista, et turvalisus ei ole saavutatav üksnes tehniliste vahenditega, või veel kitsamalt, turvalist koodi kirjutades. Turvalisus on olulises osas tõstetav vajalikule tasemele organisatoorsete, protseduuriliste, kasutajat harivate koolituste, motivatsiooniga, füüsiliste turvameetmetega jm.

Turvalisuse tõstmine seisneb võimalike süsteemi nõrkuste ja süsteemisiseste ning süsteemiväliste ohtude kaardistamisega. Nõrkuste ja ohtude kombinatsioonidele määratletakse esinemise tõenäosus ning tagajärje tõsidus. Nende korrutise abil järjestatakse olulisemad riskid ning planeeritakse vajalikud ennetavad või leevendavad meetmed.

Järgnevalt mõned näited võimalikest meetmetest, mis peaksid aitama kaitsta firma andmeid mittevolitatud ligipääsu eest:

Füüsiline tase - kontoriruumide turvalisus, sülearvutid ja kodused arvutid. Kodustesse arvutitesse võib jõuda delikaatseid andmeid, kui on lubatud kodus tööd teha. Sülearvutid võidakse varastada nii tänaval kui ka kodus ning need võidakse välismaal arestida. Selle eest kaitseks võib firma keelata sülearvutitega ringi liikumise ning kodus töötamise. Ning töökohal peaksid arvutid paiknema "luku ja riivi taga". samuti võidakse keelata mitmesuguse salvestusmeediaga (CDd ja DVDd, mälupulgad, välised kõvakettad) liikumise kontorisse ja kontorist välja. Kodune töö toob igal juhul kaasa riskid, ka siis, kui töötaja on aus. Sest kodune arvutivõrk (eriti traadita kohtvõrk) ei pruugi olla piisaval määral turvatud.

Protseduuriline tase - kokkulepitud "mängureeglid" andmete käitlemisel, erinevatele töötajatele füüsilise ja loogilise juurdepääsu tagamisel, andmete varundamisel jms tegevuste jaoks. Päris selget joont eelmise tasemega on raske tõmmata. Näide sellest, et töö sülearvutiga ei tohi koju minna, võiks liigitada ka siia alla.

Tarkvaraline tase - piiratakse kasutajate juurdepääsu ning tehakse andmed-süsteemid kättesaadavaks vaid selleks volitatud isikutele. Andmetele ja kogu arvutile ligipääsuks peab kasutaja end autentima. Selleks on paroolid, kuid turvalisemad on sõrmejälje ja silma võrkkesta lugejad. Siiski ei taga see päris kindlat kaitset, sest tarkvara vigu saab ära kasutada kõrvalisi teid mööda süsteemi sissemurdmiseks (back door). Tundlikke süsteeme arendades tuleb turvalisuse probleemidele juba süsteemi arendades suurt tähelepanu pöörata ning tarkvara konkreetsete ründevõimaluste suhtes hoolikalt kontrollida. Kõikvõimalike ründevariantide käsitlemine ei mahu käesolevasse materjali.

Tavapärasemaid võtteid andmete kaotsimineku riski maandamiseks (näiteks süsteemis oleva riist- või tarkvara rikke korral) on süstemaatiline varundamine, andmete hoidmine dubleerituna, RAID-kettasüsteemide kasutamine jne

Kogu turbealast tegevust ei ole vaja vastavatel spetsialistidel otsast leiutama hakata. On väljatöötatud raamistikud, mis näevad ette protsessid, protseduurid, käitumise jms tarkvarasüsteemide ja andmete turvalisuse tagamiseks.

Eestis on laialt levinud infosüsteemide turvameetmete süsteem ISKE.

ISKE on komplekssete turvameetmete kogum, mille eesmärk on aidata kaitsta ja säilitada:

• andmeid ja andmekogusid
• IT-seadmeid
• andmevahetuskeskkondi
• tarkvara.

ISKE koosneb üldisest turvanõuete korrast ja turvameetmete kirjeldustest. Lisaks tehnilistele meetmetele sisaldab ISKE ka soovitusi organisatsiooni, infrastruktuuri ning personali kohta. ISKE on mõeldud eeskätt andmekogude seadusega reguleeritavate andmekogude pidamisel kasutatavate infosüsteemide ja nendega seotud infovarade turvalisuse saavutamiseks ja säilitamiseks, kuid on rakendatav ka muudes riigi- ja omavalitsusasutustes, äriettevõtetes ja mittetulunduslikes organisatsioonides.

Konkreetsetele andmetele vajaliku kaitse saavutamiseks liigitatakse andmed esmalt turvaklassidesse, arvestades teabe konfidentsiaalsust, terviklust, käideldavust. Seejärel määratakse turvaklassi järgi andmete kaitsmiseks vajalik turbeaste.

ISKE turbeastmed on madal keskmine ja kõrge.

Igale turbeastmele vastab kindel ISKE turvameetmete komplekt, mille abil andmeid kaitstakse. Kasutaja ülesandeks jääb nende ellu viimine.

Igapäevased turbetoimetused on järgmised:

Kõiki olulisi andmeid tuleb regulaarselt varundada. On väljatöötatud skeemid näiteks väiksema varundamise tegemiseks iga päev ja suuremaks varundamiseks üks kord nädalas. Milline skeem täpselt sobib, seda saab otsustada juba andmete olulisuse alusel (liigne varundamine läheb liiga kalliks ja ressurssi nõudvaks). Kui varundamine on tehtud piisavalt automaatseks, tuleb siiski süsteemi perioodiliselt kontrollida, et kõik jätkuvalt töötaks. Ning oluline on ka see, kus hoida varukoopiaid. Kui nad seisavad näiteks serveri kõrval laua peal, siis tulekahju korral ei ole hiljem koopiatest suuremat kasu.

Inimfaktor - turvapoliitikatest on kasu vaid siis kui neid järgitakse ja kasutatakse igapäevaselt. Töötajaid tuleb koolitada igapäevaselt turvanõudeid täitma, kuni see muutub harjumuseks. Kuid samas tuleb arvestada, et ka kõige läbimõeldum turvapoliitika ei suuda ette näha kõiki ohte ja neid ennetada. Tuleb jälgida, kus on konfidentsiaalsed andmed ja vajadusel hävitada välised andmekandjad. Igapäevaselt andmeid kasutades on otstarbekas neid krüpteerida. Korralik krüpteerimise võimalus peab olema infosüsteemi sisseehitatud.

Juurdepääsu kontroll - kasutada tuleb hoolikalt valitud turvalisi paroole. Halvad paroolid on jätkuvalt turvalisuse puudujääkide pingereas kõrgel kohal. Ka töökohalt ajutisel lahkumisel tuleb takistada ligipääs oma arvutile - kas parooliga kaitsta ekraanikaitse või end süsteemist välja logida.

Igapäevaselt tuleb hoolitseda, et igasugused tarkvarauuendused saaksid süsteemile lisatud. Kui need ei puuduta ka tarkvarasüsteemi ennast, siis uuendused operatsioonisüsteemile, viirusetõrje tarkvarale jms on hädavajalikud.

# B.1.5 Kordamisküsimused

# B.1.6 Süsteemiarenduse arengujooned

Selle alateema materjale läbi töötades saad teadmised süsteemiarenduse suundumustest.

Tarkvaraarenduse roll on ettevõtetes aegade jooksul muutunud. Algselt oli tarkvara innovatsiooni ja ettevõtte toodete/teenuste parendamisel üks elementidest, aja jooksul on tarkvarast saanud iseseisev toode.

Tarkvaraarenduse ja halduse protsess on muutunud keerukamaks: on kasvanud tarkvara funktsioonide keerukus ning sellest tulenevalt kulud, mis tema loomise ja käigushoidmise peale ettevõtetel lähevad. Suurenenud on sõltuvus tarkvarast, keerukamaks muutunud tarkvaraarenduse vahendid (CASE-vahendid), tarkvarasüsteeme liidestatakse omavahel. Arusaadavalt on see toonud kaasa suurema tähelepanu tarkvara kvaliteedi tõstmise ja tarkvaraarenduse protsessi efektiivsemaks ja tõhusamaks muutmise vastu. Kui tööd teha nö õigesti, järelemõeldult ja järeleproovitud töövõtteid kasutades, siis on suurem lootus, et tekkiv toode on kvaliteetne, samuti valitseb lootus, et toode valmib kiiremini ning annab firmale sealjuures rahalist kokkuhoidu.. See põhimõte on mujal inimtegevuses täiesti tavaline - pahteldades seina õigeid töövõtteid ja -vahendeid kasutades saab töö kiiremini tehtud ja tulemus näeb ka tunduvalt parem välja.

Ajalooliselt on tarkvaraarendusprotsessi parendamisega enim tegeletud sellistes valdkondades nagu militaarvaldkond, kosmosevaldkond, tööstus, ja valdkonnad, kus tarkvarale usaldati kriitiliste protsesside juhtimine ning seega oli kvaliteet eriti oluline. Nendest valdkondadest on välja kasvanud ka esimesed süstematiseeritud ja kirjeldatud arendusmetoodikad. Esialgu pandi efektiivsema tarkvaraarenduse nimel suuremat rõhku arenenumate keelte kasutamisele. Edasi omandasid metoodika aspektid üha suurema tähtsuse. Algselt püüti igas valdkonnas luua oma tarkvaraarenduse meetod, hiljem taibati, et eri valdkondades on mõistlik kasutusele võtta samad põhimõtted ja protsesside raamistikud. Nii on kirjeldatud mitmeid arendusmeetodeid, samuti loodud standarte, mis peaksid kõik aitama tarkvaraarendusprotsessi mõistlikus suunas juhtida

# B.1.6.1 Kvaliteedi juhtimine ja standardid

Standardid tegelevad peamiselt kvaliteedikindlustamise probleemidega, hinnangu andmisega kriitiliste äriprotsesside haldamisele ja juhtimisele. Järgnevalt mõned näited süsteemiarenduse standarditest

# ISO 9000

ISO 9000 on ISO (International Organization for Standardization) standardite osa, mis on rakendatav projekteerimise ja tootmisega tegelevas ettevõtluses. Viimane versioon standardist on piisavalt üldine, et sobida äri ja teenindusega seotud ettevõtetesse ning on enam suunatud klientide rahulolu saavutamisele. ISO9000 reguleerib toodete hankimise, kavandamise, dokumenteerimise, tarnimise, väljatöötamise, testimise ja hoolduse. ISO 9000 kvaliteedistandardite sari on kehtestatud ka Eesti standarditena. ISO9000 lähenemine ei ole normatiivne vaid nõutakse, et standardit rakendav ettevõte tuvastaks oma võtmeprotsessid ning valiks meetodid ja tehnikad nende protsesside efektiivseks läbiviimiseks. Tähelepanu pööratakse protsesside pidevale parendamisele ning mõõdikutele, mille abil saab kontrollida protsesside ja toodete kvaliteeti.

# ISO 12207

ISO 12207 on tarkvara elutsükli protsessi standard.

Standard kehtestab tarkvara elutsükli protsesside tarbeks üldise, täpselt määratletud terminoloogiaga raamstruktuuri, millele saab viidata tarkvara valdkonnas. Struktuur sisaldab protsesse, tegevusi ja töid, mida rakendada tarkvaratoote või -teenuse hankimisel ning tarkvaratoodete tarnimisel, väljatöötamisel, käitamisel, hooldamisel ja kõrvaldamisel. Tarkvara hõlmab ka püsivara tarkvaraosa. Standard annab protsessi, mida saab rakendada tarkvara elutsükli protsesside määratlemiseks, juhtimiseks ja täiustamiseks. Selle standardi protsesse, tegevusi ja töid võib – eraldi või seoses standardiga ISO/IEC 15288 – rakendada ka tarkvara sisaldava süsteemi hankimisel. (Eesti Standardikeskuse kodulehelt)

Standard kirjeldab kogu elutsükli protsessi, sh tegevused ja protseduurid tarkvara omaksvõtmiseks ning süsteemi teenuste konfigureerimiseks. Igal protsessil (neid kirjeldatakse kokku 23) on oma väljundid. Standardi põhieesmärgiks on esitada üldine struktuur, nii et kõik osapooled arendajast kliendi ja hooldajani-haldajani räägiksid ühes keeles ehk kasutaksid sama mõistebaasi. Standardi struktuur on modulaarne ja tänu sellele saab seda kohandada sobivaks erinevatele olukordadele. Esmased elutsükli protsessid sisaldavad protsesse, mille abil tarkvara luuakse.

Standard toob välja 5 põhiprotsessi:

• hankimine (Acquisition) - projekti algatamisega seotud tegevused,
• pakkumine (Supply) - projekti haldusplaani koostamine,
• arendamine (Development) - tarkvara luuakse, testitakse ning on valmis kliendile üleandmiseks,
• kasutamine (Operation) - süsteemiga töötavate inimeste toetamine
• hooldus (Maintenance) - toote hoidmine töötavana, laienduste ja täienduste lisamine vastavalt kasutaja soovidele.

Standard on vastuvõetud ka Eesti standardina **(****EVS-ISO/IEC 12207)**. Jälgides Eesti tarkvaraarendajate veebilehti võib leida viiteid, et oma arendusprotsessis peetakse kinni just sellest standardist. See peaks omakorda tõstma usaldust vastavate ettevõtete vastu.

# SEI/CMMI

Aastal 1986 kirjeldas Watts Humphrey tarkvara küpsuse mudelit (Software Maturity Framework), mille abil on võimalik hinnata tarkvara arendusfirma küpsustaset. Sellest algsest mudelist on erinevate firmade tarbeks ajapikku välja arenenud rida küpsusmudeleid, millest tarkvara alal kaks tuntumat on CMM-SW , mille andis välja Software Engineering Institute(SEI) 1993. aastal, ning Capability Maturity Model Integration (CMMI), mis anti välja 2000. aastal.

CMM-SW mudel sisaldab nõudeid tarkvara kvaliteetsele arendamisele. Mudeli abil on võimalik hinnata tarkvara arendus- ning arendamisega seotud protsesside ja selle kaudu kogu tarkvarafirma küpsust. CMM-SW kirjeldab viit küpsuse taset, millest igal on nõuded teatud protsessidele. Soovitud taseme saavutamiseks peab tarkvarafirma täitma kõik nõuded protsessidele, mida sel tasemel nõutakse. Puuduste esinemisel järgmise taseme protsesse hindama ei asuta, vaid kõigepealt parandatakse puudulikud protsessid. Seega näitab CMM-SW, millised protsessid peavad firmal olema korras, et soovitud taset saavutada.

CMMI erineb CMM-SW mudelist mitme protsessidele seatud nõude poolest. Peamiseks erinevuseks on see, et CMMI mudelil on kaks varianti: CMMI tasememudel (staged model) ja CMMI jätkuv mudel (continuous model). Tasememudel sarnaneb ülesehituselt ja loogikalt CMM-SW mudeliga. CMMI jätkuv mudel erineb neist selle poolest, et selle alusel ei ole võimalik hinnata kogu organisatsiooni küpsustaset, vaid hinnatakse iga protsessi küpsustaset eraldi. Seega on CMMI jätkuv mudel paindlikum, võimaldades tarkvara arendusfirmal hinnata kõigepealt talle olulisemaid protsesse.

SEI/CMMI on suunatud (arendus)protsessi parandamisele ning annab organisatsioonidele efektiivse protsessi olulised elemendid.

# Agiilmeetodid

Arendusmetoodikates on vanade nn tardmeetodite (raskete meetodite) asemel tulnud kerged ehk agiilsed ehk paindmeetodid. Agiilmeetodite tuleku üheks põhjuseks oli tardmeetodite sobimatu paljude tarkvaraprojektide läbiviimiseks. Erinevalt muust tööstusest osutus tarkvaraprojekti läbiviimine algselt paika pandud põhjalike plaanide järgi väga keeruliseks. Eriti sel juhul, kui toodet tehti kliendi soovide kohaselt ning need soovid ei olnud väga selgelt välja kujunenud. 2001 aastal koostatud Agile Manifesto';s toodi muuhulgas välja, et planeerimisse põhjaliku panustamise asemel tuleks siiski teha "asja ennast", kuid see ei tähenda samal ajal plaanipärasest tegevusest lahti ütlemist. Agiilsete arendusmeetodite puhul on protsess ja iganädalased tegevused väga selgelt reglementeeritud.

# SCRUM

Siinkohal võib näiteks tuua SCRUM'i , mis on Eestiski levinud.

"SCRUMi raamistik aitab meeskondadel saada ülitõhusaks. See võimaldab arendajail teostada suuri projekte vaid murdosa jooksul ajast, mis kulub tavaarenduspraktikas" – ütles Jim Cundiff, Scrum Alliance';i tegevjuht. "Samuti teeb Scrum defektid meeskonnale koheselt nähtavaks", lisab Cundiff. "Lihtsalt öeldes – Scrum parendab tõhusust ja aitab organisatsioonil ülesannetega toime tulla." Scrumi kasvavat populaarsust võib seletada tema suutlikkusega tõsta ja võimendada investeeringult teenitavat tulusust ning võimega ühendada juhtkonda ja arendajaid firma ärieesmärkide saavutamise nimel. SCRUMi on lihtne mõista ja rakendada, koolitusprogrammid on olemas ja töötavad. Scrum pakub paindlikku raamistikku, mis aitab suurtel meeskondadel keskenduda sihile, et ühiselt, kogu meeskonnaga, saavutada iga sprindi ülesanded.

SCRUM-töö põhineb tsüklilisusel, mille etappe nimetakse sprintideks sprints. Sprindi kestus on tavaliselt kaks kuni neli nädalat. Igaks sprindiks võtavad meeskonnad töösse tähtsuse põhjal järjestatud ülesanded, lähtudes kliendi vajadustest. Ülesandeid nimetatakse kasutuslugudeks user story, nii et funktsioonid, mida arendatakse eelkõige, on kliendile kõige suurema väärtusega. Iga sprindi lõpus tarnitakse kliendile potentsiaalselt kasutatav toode.

Kuigi SCRUM on enimlevinud tarkvaraarenduses, sobib see metoodika väga hästi igasuguste agiilsete (olud ja lähteandmed muutuvad sageli) arendusprojektide teostamiseks.

SCRUM sisaldab pea ainult töö organiseerimisega (projekti juhtimisega) seotud tegevusi, nähes ette võimalikud igapäevased / iganädalased tegevused. Näiteks ei alustata esmaspäeva hommikul mitte usina koodikirjutamisega, vaid kulutatakse päevast märkimisväärne osa nädala tegevuste planeerimisele (nt planning poker - tegemist vajavate tööde jaotamine sprintidesse). Peetakse hommikusi lühikesi nn püstijala koosolekuid stand-up, kus igaüks saab öelda nii seda, mida ta eelmisel päeval tegi kui ka seda, mis teda töötamast segab. Peetakse tagasivaate koosolekuid retrospective, et toimunut kokku võtta ning avaldatakse arvamust oma meeskonna liikmete kohta, kui nende tegevus näiteks teiste töötamist segab. Seinal hoitaks tööde edenemise graafikut, kus on jooksvalt kõigile näha, kui kaugele erinevate funktsionaalsustega ollakse jõudnud.

"Agiilsetest tegevustest" Eestis vaata agile.ee ja scrum.ee.

# B.1.6.2 IT arhitektuur

Veel mõned aastad tagasi oli üks levinumaid viise struktureerida rakendusi kaheks komponendiks: klient ja server. Sellist lähenemist tuntakse nimetuse kahekihiline arhitektuur all. Klient on komponent, mis vahendab kasutaja ja serveri vahel infot. Server osutab ühele või enamale kliendile teenuseid. Tüüpiliselt paiknes serveris tsentraalne andmebaas ja üks osa äriloogikast, klientides aga äriloogika ja kasutajaliides. Sellise arhitektuuri puuduseks on, et äriloogika muutudes on vaja tarkvara uuendada tihti kümnetes ja sadades kliendiarvutites, samuti nõuab see suurte andmemahtude liigutamist kliendi ja serveri vahel ning suurt arvutusvõimsust kliendi poolel.

# Mitmekihiline arhitektuur

Mitmekihiline arhitektuur n-tier client-server architecture on klient-server arhitektuur, kus esituse, töötlemise ja andmete haldamise protsessid on üksteisest loogiliselt eraldatud protsessid. Mitmekihiline arhitektuurimudel aitab luua paindlikku ja korduvalt kasutatavat tarkvara. Muudatuste puhul on vajalik need teha vaid üksikutes kihtides, mitte kogu rakenduses korraga. See lubab hakkama saada vähema töö, lühema aja ja väiksema potentsiaalse vigade hulgaga.

Tüüpilisemaks ja enam kaustatavamaks variandiks on kolmekihiline arhitektuur three-tier client server architecture. Kolmekihilise rakenduse puhul paikneb iga kiht arvutivõrgus erinevas kohas ning võib paikneda ka erinevatel platvormidel.

Kliendile kõige lähemal on tema arvutis olev tööjaama tarkvara (nn esitusloogika kiht ). See võib piirneda vaid sisestusvormidega ja platvormile tüüpilise graafilise kasutajaliidesega. Ei ole välistatud selle kihi olemasolu erinevatele platvormidele. Esitusloogika kiht suhtleb rakenduse kihiga (ka äriloogika kiht, keskmine kiht).

Äriloogika või firmaloogika kihi business logic ülesandeks on juhtida funktsionaalsust, töödeldes selleks alumisest kihist saadud andmeid vastavalt kasutajalt ülemisest kihist tulnud päringutele. See kiht paikneb tavaliselt kohtvõrgu serveril.

Andmekiht on kolmas kiht. See sisaldab andmebaasi ning selle haldamiseks vajalikku tarkvara ning võib paikneda mõnes suurarvutis. Kihi ülesanne on muuhulgas hoida andmeid sõltumatutena rakendusest ja esitusloogikast.

Praegu laialt levivatel veebirakendustel on reeglina sarnane arhitektuur. Sel juhul on esitusloogika kiht seotud veebilehitsejaga ning kasutajaliidese renderdamisega veebilehitseja aknasse. Osa sisu võib olla staatiline ja osa dünaamiline.

Mitmekihiline arhitektuur n-tier architcture on üldistus. Siin võivad vastavalt vajadusele lisanduda erinevad kihid (või jaotuda kirjeldatud kihid omakorda osadeks). Olukorras, kus järjest enam on väärtust mitte üksikul rakendusel või andmebaasil, vaid koosvõimelistel infosüsteemidel, on arenduses pudelikael liikunud süsteemide liidestamisele-integratsioonile. Oluline on kasutada läbiproovitud praktikaid (nt mustreid sarnaste probleemide lahendamiseks), teenusorienteeritud lähenemist, infosüsteemide semantilist kirjeldamist.

# Teenusorienteeritud arhitektuur

Teenusorienteeritud arhitektuur SOA / Service Oriented Architecture on samuti olemuselt mitmekihiline ja seda kasutatakse veebirakenduste loomisel. Arhitektuur moodustub üksteisega suhtlevatest (veebi)teenustest, mis ei sõltu üksteise kontekstist ega olekust ning töötavad hajussüsteemide mudelil. Teenuste vahel puuduvad tugevad seosed ning ükski teenus pole teadlik teise teenuse tehnilistest detailidest nagu näiteks andmestruktuurid, tarkvaraline platvorm, operatsioonisüsteem, kasutatav andmebaasisüsteem jne. SOA-d võib käsitleda kui rakenduste väljatöötamise kõrgeimat tasandit, kus kasutajate eest on peidetud kogu tehnilise keskkonna keerukus.

SOA eelised:

• SOA abil on võimalik integreerida erinevaid infosüsteeme. Arendajad ei pea töötama välja uusi lahendusi erinevate süsteemide kasutamiseks. Oluline on kasutada standardseid protokolle (nt andmevahetusprotokollid). Standardeid mittejärgivaid teenuseid on raske juurutada.
• Liidesed on taaskasutatavad. Liidest, mida kasutati ühe konkreetse süsteemi arendamisel, saab kasutada ka kõikide teiste analoogsete süsteemide arendamisel.
• Kasvab arendusprojektide tootlikkus. Taaskasutamine aitab sarnaseid lahendusi ehitada kiiremini, odavamaks ja kiiremaks muutub ka süsteemide integratsioon.

SOA on asendamatu veebiportaalide ehitamisel. Portaal võib hankida uudiseid ja ilmateateid kolmanda osapoole veebiteenuste vahendusel. Veebikauplused ja tootjate veebilehed võivad vahendada kaupade andmeid oma andmebaasidest teineteisele edasimüügiks. Seejuures suhtlevad infosüsteemid teenustega automaatselt. Võibki öelda, et SOA levinumaid ärilisi kasutusi on tellijate ja tarnijate infosüsteemide liidestmine. Samamoodi saab panna SOA abil suhtlema sama firma erinevad infosüsteemid, sõltumata kasutatud tehnoloogiatest ja platvormidest – operatsioonisüsteem, andmebaas jne.

Erinevad SOA-tehnoloogiad on ellu kutsutud selleks, et lihtsustada eri süsteemide omavahelist suhtlust. (kirjeldus firma DT veebilehelt)

# B.1.6.3 Süsteemide keerukus

Pärandtarkvara (legacy software) töös hoidmine ja integreerimine uute tarkvarasüsteemidega on üks 21. sajandi tarkvaraarenduse väljakutsetest. Firmad, mis on investeerinud suurarvutitesse (mainframe), on huvitatud oma investeeringu ehk suurarvuti jätkuvast kasutamisest. Tekib küsimus, kas suurarvuti saab olla tänapäevase paindliku integreeritud IT-süsteemi osa ning kas pärandtarkvara ja pärandandmeid saab jätkuvalt kasuta? Vastuseks on, et peab saama, kasvõi juba sellepärast, et kogu arvutiparki ega rakendusi ei ole võimalik korraga välja vahetada. Samas suurarvuteid võikski nende võimsuse tõttu rahulikult edasi kasutada.

Suurarvutite ja nendel töötavate süsteemide jätkuvaks kasutamiseks ning uute süsteemidega integreerimiseks on vaja spetsiaalseid tarkvaralisi laiendusi (legacy mainframe extension). Laiendused töötavad ka selliselt, et neid on võimalik liidestada SOA-arhitektuuri. Laiendusi toodavad ja lisavad oma tarkvarasse ka suurte andmebaasisüsteemide ja arendustarkvara loojad (nt Oracle, IBM)

Arvutisüsteemid on oma kasvamise ja arenemisega toonud kiiruse ja automatiseerituse läbi palju kasu mitmesuguse inimtegevuse valdkondadesse ja nüüd jõuab kätte aeg, kus arvutisüsteemid peaksid iseend automaatselt hooldama. Praegu kulub nende hooldamise peale palju oskustööjõudu. Kaasaegsete hajussüsteemide suurimaks probleemiks on nende endi keerukus ja nende haldamise keerukus. Keerukus ei piirdu ainult tarkvaraga, vaid süsteemis tahetakse koos kasutada erinevaid seadmeid alates serveritest ja lõpetades mobiiltelefonidega. See kõik peab suutma võrgus suhelda. Kasvavast keerukusest saab peagi süsteemide edasiarengut piirav faktor.

Artiklis "The Vision of Autonomic Computing" hoiatavad Kephart ja Chess, et unistus kõigi tarkvarasüsteemide ja seadmete ühendamisest muutub lausandmetöötluse õudusunenäoks, kus arhitektid ei ole enam võimelised ettenägema, kavandama ja hooldama kõigi süsteemide vastastikuse toime keerukust. Nad märgivad, et autonoomse andmetöötluse (autonomic computing) olemus on süsteemi enesehooldus (self-management), kus süsteemi parema toimimise läbi vabastatakse administraatorid madala taseme tegevusest. Autonoomse andmetöötluse idee on inspireeritud inimese autonoomsest närvisüstemist. Sellises süsteemis omandab administraator uue rolli - tema ülesandeks on kirjeldada üldsuunad ja haldamisreeglid, mille alusel enesehooldus toimima peab. On välja toodud 4 peamist kasutusala/omadust, kus esialgu autonoomse andmetöötlusega tegeletakse:

• isekonfigureeruv - automaatne komponentide konfigureerimine;
• iseparanev - vigade automaatne avastamine ja parandamine;
• iseoptimeeruv - ressursside automaatne jälgimine ja juhtimine vastavalt reeglitele;
• enesekaitse - rünnakute äratundmine ja kaitse.

End ise hooldavate süsteemideni on siiski veel hulk maad minna.

# B.1.6 Kordamisküsimused

# Kasutatud materjalid ja lisalugemist

• EUCIP programmi materjal: http://ecdl.ee/EUCIP_eksami_sooritajale.html

• Tauno Hanni materjal e-uni repositooriumis "Infosüsteemi elutsükkel":
  http://www.e-ope.ee/repositoorium/otsing?@=6wob#euni_repository_10895

• Natalia Prishvitsyna materjal e-uni repositooriumis "Infosüsteemi elutsükkel":
  http://www.e-ope.ee/repositoorium/otsing?@=6x0f#euni_repository_10895

• Ian Sommerville. Software Engineering 9th EditionPearson Education, 2010

• Sama raamatu veebilehel olevad slaidid ja joonised:
  http://www.cs.st-andrews.ac.uk/~ifs/Books/SE9/

• Jaak Tepandi. Tarkvara kvaliteet ja standardid (IDX5721, IDX5722)
  http://deepthought.ttu.ee/users/tepandi/pdf/tks-loeng.pdf

• Sense foorum Scrumist:
  http://www.illimar.com/foorum/viewtopic.php?t=148

• ISKE- tutvustav materjal: http://www.ria.ee/iske

• Jones, Capers. Software Engineering Best Practices McGraw-Hill Professional Publishing, 2009

• Alistair Cockburn. Using both incremental and iterative development:
  http://alistair.cockburn.us/Using+both+incremental+and+iterative+development

• Computer Aided Software Engineering (CASE Tools):
  http://www.theecommercesolution.com/usefull_links/case_tools.php

• Computer-aided software engineering:
  http://www.enotes.com/topic/Computer-aided_software_engineering

• John W. Horch. Practical Guide to Software Quality Management:
  http://site.ebrary.com/lib/tallinn/docDetail.action?docID=10081955&p00=horch

• Terminid: http://vallaste.ee/, http://en.wikipedia.org

• Artiklid ajakirjas Arvutustehnika ja andmetöötlus (http://deepzone0.ttu.ee/aa/):

• M. Lepmets. Mis on tarkvaraprotsesside parandamine ehk Software Process Improvement

• G. Piho. Eesti tarkvaraarendajate kogemused arendusmetoodikate kasutamisel

• P. Leis. Agiilse projektijuhtimise karkass

• P. Leis. CMM on suremas, elagu CMMI!