B.1.2. Süsteemiarenduse põhimõtted ja metoodikad

iDevide ikoon Eesmärgid

1)      Mõista süsteemiarenduse põhisamme ja kirjeldada neid;

2)      Eristada süsteemiarenduse erinevad mudelid ja nende näited;  

3)      Kirjeldada süsteemi elutsükkel.


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.

 

1. 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.
img25_8
Joonis 1. Koskmudel

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.

 

2. 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.
img27_8
Joonis 2. Iteratiivne arendus

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.

 

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.

iDevide ikoon Ülesanne

1. Tutvuda mõne arendusraamistikuga, nt OpenUP/Basic

http://www.eclipse.org/epf/downloads/openup/openup_downloads.php

 

2. Tutvuda mõne tarkvarasüsteemi dokumenteerimisviisiga, nt „4+1 vaade” tehnikaga.