SÜSTEEMIARENDUSE PROTSESS JA MEETODID

Rakendustarkvara ja süsteemitarkvara

Programme võib liigitada kahte suurde gruppi:

1. rakendustarkvara
2. süsteemitarkvara

Süsteemitarkvara alla kuuluvad programmid, millised toetavad rakenduste tööd, olemata ühegi rakenduse spetsiifiline. Kujutades piltlikult ette arvuti ehitust koosnevana kihtidest või tasemetest, paiknevad süsteemitarkvara alla liigituvad programmid „alumistele” kihtidele, lähemale füüsilisele kihile – riistvarale, mis jooksutab programme.

Rakendustarkvara seevastu paigutub kihilise mudeli järgi „kõrgemale” kihile – „eemale” riistvarast ja lähemale arvutiga suhtlevale kasutajale.

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.

Operatsioonisüsteem on üks tüüpilisemaid süsteemitarkvara näiteid. Samas ei ole üheselt kokku lepitud, kas nt BIOS või andmebaasimootorid kuuluvad süsteemitarkvara alla või mitte. Mõned koolkonnad eristavad süsteemitarkvara alaliigitusena püsivara (riistvaraliselt realiseeritud tarkvara, ingl. k firmware) – tarkvara, milline säilitatakse ROMis või EPROMil.

Rakendustarkvara alla kuuluvad programmid, millised toetavad kasutajate tööd mingi kindla funktsiooniga: tekstitöötlusega, muusika esitamisega. Oma töös rakendustarkvara toetub süsteemitarkvarale.

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 vrs Ameerika Ühendriigid oli üheks põhiküsimuseks, kas internetibrauserit MS Explorer lugeda operatsioonisüsteemi alla kuuluvaks (seega süsteemitarkvaraks) või iseseisvaks rakenduseks (seega – rakendustarkvaraks).

Käsitledes tarkvara justkui iga teist toodet, võib tarkvara eluea jagada faasidesse:

1. toote arenduse (loomise) faas;
2. toote halduse faas;
3. toote mahavõtu (ja võimalik, et uuele tootele ülemineku) faas.

Tarkvara kui toode on süsteemiarenduse väljund. Süsteemiarendus protsessina koosneb nii toote projekteerimisest ehk disainist kui toote valmistamisest. Eesmärk on valmistada toode, milline vastab kasutajate ehk klientide vajadustele ja ootustele.

Tulenevalt klientide vajaduste kiirest muutumisest – võrreldes teiste valdkondade toodetega – peab ka süsteemiarenduse protsess olema agiilne (väle, paindlik) – so suutma reageerida pidevatele toote muutmissoovidele, täiendustele, kohandamistele.

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

1. koskmudel
2. iteratiivne arendus (agiilne arendusmudel, spiraalmudel; inkrementaalarendus)
3. prototüüpimine.

Järgnevalt käsitleme olulisemaid süsteemiarenduse mudeleid. [5]

Koskmudel. Koskmudel on üks enimteatuid ja vanimaid süsteemiarenduse mudeleid. Koskmudelit järgivad süsteemiarendajad teostavad järjestikku hulga samme:

1. eeluuring – sooritatakse süsteemiarenduse tasuvusuuring
2. süsteemi nõuete püstitamine – kaardistatakse kasutajate jt huvipoolte vajadused ning nõuded süsteemile
3. süsteemi nõuete analüüs – süstematiseeritakse nõuded, nõudeid täpsustatakse, lahendatakse vastuolud nõuetes
4. süsteemi arhitektuuri projekteerimine ehk nõuetele vastava lahenduse disain
5. kodeerimine ehk programmeerimine
6. testimine
7. levitamine ehk kasutuselevõtt
8. hooldus

Joonis 1.1 Koskmudel [5]

Iga sammu sooritamise järel sooritatakse järgmine samm. Käesoleva sammu sisendiks on eelneva sammu väljund, käesoleva sammu väljund on järgneva sammu sisendiks (nt arhitektuur baseerub nõuetel ning programm luuakse arhitektuuri alusel). Eelnevate sammude juurde tagasi ei pöörduta, samuti nagu majaehitusel ei pöörduta tagasi vundamendi juurde peale katuse paikapanemist. Kui testimise käigus avastatakse viga, mille juured on arhitektuuris, siis koskmudel jääb hätta juhiste andmisega, kuidas pöörduda tagasi arhitektuuri sammu juurde, läbida uuesti programmeerimise samm ning minna teisele testimise ringile.

Koskmudel on oma nimetuse saanud järjestikuse veekoskede analoogiast – vesi langeb ühest astmelt (sammust) järgmisesse, ning ei pöördu tagasi.

Eelnevalt kirjeldatud samme ei pea organisatsioon täielikult ise läbi viima – võimalik on osta sisse teatud tegevuste täitmist või osta sisse valmistarkvara ja seda kohandada. Tüüpiliselt tuleb eeluuring, süsteemi nõuete püstitamise ja testimise tegevused siiski läbi viia organisatsiooni töötajate olulise osalusega tagamaks tarnitava süsteemi sobivuse organisatsiooni tööprotsessidega. Otsuse – kas valmistada süsteem ise, osta sisse arendus või valmistarkvara ja seda kohandada – tegemisel tuleks lähtuda tulu-kulu analüüsimisest, samuti edasiarenduse jätkusuutlikkusest.

Iteratiivne arendus. Iteratiivne arendus näeb ette ehitada valmis algul väike osa tootest, ning seda järgnevalt mitmes etapis laiendada. Iteratiivne 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.

Joonis 1.2 Iteratiivne arendus [5]

Iga iteratsioon võib sisaldada ühte või mitut sammu koskmudelist. Iteratsiooni tulemiks võib olla töötav tarkvara, mis täidab ainult osasid kasutajale vajalikke funktsioone. Järgmises iteratsioonis parandatakse eelnevate iteratsioonides loodud tarkvara vigu ning realiseeritakse mingi hulk uut funktsionaalsust.

Agiilne arendusmudel on eriliik iteratiivsest mudelist, põhiline erinevus „klassikalise” iteratiivse mudeliga seisneb selles, et enim arvestatakse tagasiside (koormustestimine, kasutajate arvamus jm) käigus saadud info ja õppetundidega kui loodetakse hoolika etteplaneerimise tehnikale. Põhitähelepanu on inimestel, sh kasutajatel, ja pideval testimisel. Öeldakse, et agiilmudeliga saavutatakse parem tulemus sama raha eest, aga agiilmudeliga 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”.

Ekstreemprogrammeerimine ehk XP on tuntumaid agiilseid arendusmetoodikaid. 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, klassikalistes mudelites kuud ja aastad. Enne kodeerimist kirjutatakse automatiseeritud testid, mida tarkvara peab läbima, seejärel programmeeritakse paarides (so kaks programmeerijat ühe arvuti taga kodeerivad ühte programmilõiku). Programmeerimise samm on lõpetatud antud iteratsioonis, kui kood läbib testid.

Spiraalmudel on samuti üks iteratiivseid arendusmudeleid.

Kokkuvõtvalt, erinevalt koskmudelist ei koostata iteratiivse arendusmudeli järgi esmalt kõikehõlmavat analüüsidokumenti, milline sisaldab muutumatuid kasutajate vajadusi ning „kirjutatakse verega alla” süsteemi tellija ja realiseerija vahel – iteratiivne mudel võimaldab 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. Eelnevatest faktoritest lähtuvalt tuleb koostada sobiv projektiplaan.

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 veebibrauseri abil. [5]

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 lähiajal 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 palju toode nõuab mälu, arvutusvõimsust;
• turvalisuse tagamise meetmed;
• portabiilsus, so võimalus käitada tarkvara erinevatel platvormidel.

Süsteemi nõuded ja arhitektuursed otsused peaksid 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 võib rahuldamata jätta.

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.