Sissejuhatus

Käesolevas osas vaatleme, kuidas tarkvara on n-ö tööstuslikult arendatud ja praegu arendatakse. Kuigi ka siin materjalis tuuakse välja erinevaid käsitlusi, on neid tegelikult veel märksa rohkem. Vähemalt osa termineid ei ole üheselt määratud ja nii võivad näiteks erinevates firmades varieeruda ametikohtade nimetused. Konkreetsed kohustused võivad erinevalt jaotuda vastavalt firma või projekti eripäradele. Kasutusel võivad olla ka täpsustavad eesliited, nt nooremarendaja ja vanemarendaja. Aga alustame ajaloolise ülevaatega.

Kunagi ammu-ammu, 50 aastat tagasi (1968-1969), sai maailm esimest korda kuulda sõnapaari “software engineering” (tarkvaraarendus) [NATO konverents]. Selleks ajaks olid juba mitmed tarkvaraprojektid edukalt või mitte nii väga edukalt lõppenud (aastatel 1950-1960) ning selleks, et töö saaks korralikult tehtud, oldi juba pikemat aega otsitud õigeid tööprotsesse. Pole siin maailmas midagi uut: esimene tarkvara arendamise protsessi mudel oli pärit tööstuses ning ehituses kasutusel olnud protsessidest.

Väiksema maja ehitamisel võivad olla järgmised etapid:

1. leidub üks inimene (tellija), kes püstitab eesmärgi – tahan endale maja, odavalt;
2. arhitekt püüab tema soovidest aru saada, luua eskiise, kirja panna, suhelda kohaliku omavalitsusega (paberid tuleb ju korda teha);
3. insener arvutab välja tüütud detailid;
4. ehitajad ehitavad, ehitusmeister juhib;
5. ehitusjärelevalve vaatab, et ehitus käiks reeglite järgi;
6. tellija võtab maja vastu ning kas kolib sisse või laseb sel maha laguneda.

Maja ehitamisel on selline protsess ennast õigustanud, niisiis lootsid inimesed, et see töötab ka kujuteldava maja (ehk tarkvara) ülesehitamisel.

Rollid

Esitatud skeem ei näita kõiki ehituse etappe ega ka inimesi, kes sinna kaasatud on. Suure projekti puhul teevad kaasa veel näiteks joonestaja, visualisaator, materjalide ekspert, elektriinsener, eelarvestaja, sisekujundaja, dekoraator, elektrik, santehnik, plaatija, maaler, laminaatparketi paigaldaja ja teised. Projekti eduka lõpu nimel töötavad paljud inimesed, kes täidavad erinevaid ülesandeid. Mõnes projektis on neid rohkem, mõnes vähem. Väiksema maja puhul tegeleb eelarvestamisega kas tellija ise või ehitaja. Arhitekt joonestab, arvutab välja detailid ja suhtleb nii tellija kui ka omavalitsusega. Tarkvara loomisel on palju sarnaseid rolle – inimene täidab samalaadseid funktsioone ning teda kutsutakse sarnaselt (nt insener vs tarkvara insener). Tarkvara loomisel osaleb palju inimesi.

Tarkvara valmimise seisukohast olulisim inimeste rühm (inimene) on tellija. Tellijaks võib olla ärimees, firma, omavalitsus, asutuse teine osakond, eraisik. Tarkvaraarenduse protsessi kirjeldamisel nimetatakse seda poolt äriks (ingl bussiness).

Äri poolel on mitu rolli, nendest on põhilised:

Tooteomanik (ingl product owner) on tellija esindaja, kes tunneb vajadust tarkvara järele ning otsustab, et toode tuleb luua. Olenevalt asutuse suurusest võib tooteomanikuks olla äriomanik (ingl  business owner) ise või mitte.

Äriarhitekt (ingl business architect) on inimene, kes näeb ning paneb kirja (joonestab) suure pildi, nt kaardistab tarkvaravajadused vastavas äriprotsessis.

Ärianalüütik (ingl business analyst) aitab panna kirja, mida tahetakse saavutada (esmane tõlge inimkeelest IT-keelde).

Tarkvara kasutaja (ingl software user) on valmiva toote lõppkasutaja (võib olla ka tooteomanik).

Alati ei pruugi äri poolel äriarhitekti ja ärianalüütikut olla. Sellisel juhul võib neid ülesandeid täita vastav spetsialist projekti täitja poolel.

Ärist alustab IT-firmaga suhtlemist tooteomanik. IT-firmast on suure tõenäosusega esmaseks kontaktiks müügiosakond (ingl sales). Lepingud on sõlmitud ning saab alustada projekti sisulise poolega. Oluline on, et äri ja IT-firma vahel jutt sujuks, seepärast on tihti esmaseks “sisuliseks” kontaktiks tarkvaraarhitekt või süsteemianalüütik.

Tarkvaraarhitekt (ingl software architect) planeerib tarkvara ülesehituse: millistest osadest tarkvara koosneb, kuidase need omavahel ja välismaailmaga suhtlevad.

Süsteemianalüütik (ingl system analyst) aitab “tõlkida” ärisoovid arendajatele sobivateks juhisteks.

Tarkvaraarhitekti ja süsteemianalüütiku plaanide järgi saab tarkvara loomisega alustada. Tarkvara kirjutamise ehk programmeerimisega on seotud mitmed ametinimetused. Tasub märkida, et neid nimetusi kasutatakse paindlikult, erinevalt ja teineteisega vahetatavalt, mistõttu ei ole need alati siintoodud tähendusega.

Programmeerija (ingl programmer) on keegi, kes kirjutab programmi. Kõige lihtsamalt võib see olla keegi, kes instruktsioonide järgi programmi kirjutab, ise programmi ehitusele vähe mõeldes. Üldnimetusena võib see tähistada ükskõik millist programmi kirjutamisega seotud ametit.

Arendaja (ingl developer) on üldmõiste töötaja kohta, kes tarkvara loob. Arendustööks on vaja arusaamist programmeerimiskeelest ja nõuetest, kuid keerukamate ülesannete jaoks võib olla tarvis laialdasemaid teadmisi. Oskuste, kogemuste ning vastutuse põhjal eristatakse vahel nooremarendajat (ingl junior developer), kellele usaldatakse enamasti kergemad ülesanded, ja vanemarendajat (ingl senior developer), kes saab hakkama nõudlikumate töödega.

Tarkvarainsener (ingl software engineer) tunneb programmeerimisega seotud infotehnoloogilisi võimalusi (raamistikke, malle, arhitektuure, protsesse, tehnikaid jne.) ning oskab neid otstarbekohaselt rakendada. Tihti võib see kattuda arendaja või vanemarendaja töökirjeldusega.

Testija (ingl quality assurance tester) kontrollib, et tarkvara teeks seda, mida ta peab tegema, ehk et ärisoovid oleksid täidetud ning tarkvaras ei oleks vigu. Seda rolli saab võrrelda järelevalveametniku rolliga ehituses.

Süsteemiadministraator (ingl system administrator) vastutab arvutisüsteemide eest; hangib, paigaldab ja uuendab tarkvara ja riistvarakomponendid, ehk kannab hoolt, et kõik süsteemid oleksid töökorras.

Andmebaasi administraator (ingl database administrator) haldab andmebaasi, vastutab andmete säilitamise, rakenduse töötamise eest.

Kasutajatugi (ingl helpdesk) aitab kasutajatel tarkvara kasutada. Tavaelus on kasutajatugi alati kõne kaugusel (mõnikord on abiks murelahendaja), nt kui valminud majast peaks kaduma internet, tuleb ennekõike võtta ühendust teenuse osutajaga, kasutajatugi suunab õige lahenduseni.

Koolitaja (ingl training) õpetab lõppkasutajat tarkvara kasutama, vajadusel vastutab kasutamiseks vajalike dokumentide loomise eest. Ka maja ehitamisel saab omanik palju “koolitajatega” kokku. Näiteks pärast uue küttesüsteemi paigaldamist ja tööle panemist “koolitab” vastutav isik omanikku süsteemi hooldama ja kasutama, seda sisse ja välja lülitama, toatemperatuuri reguleerima. Või siis uude korterisse sisse kolimisel võib ees oodata pikem koolitus: kas koduloomad on lubatud, kuhu milline prügi läheb, kuidas reguleerida ventilatsiooni, kütet jne.

Projektijuht (ingl project manager) juhib projekti töökorraldust, hoolitseb lõpptulemuse saavutamise eest, jälgib eelarve täitmist. Ka ehituses võib omanik vajaduse või võimaluse puhul palgata tellija esindaja – projektijuhi. See imeline inimene seisab tellija soovide täitmise eest, jälgib, et ehitus oleks eelarves, tegeleb töötajatega.

Arenduse juht (ingl development manager) koordineerib koostööd projektide vahel, saab projekti katkestada.

Eelpool nimetasime palju erinevaid rolle, mis ei tähenda, et 18 inimese puudumisel tarkvara tegemata jääb. Iga inimene võib täita mitut rolli, ühes rollis võib olla mitu inimest. Vähe sellest –  kõik need rollid polegi igas projektis vajalikud. Rollide arv sõltub projekti suurusest ning valitud tarkvara loomise mudelist.

Enesekontroll (1 ülesanne)

Mudelid

Eelmises peatükis sai mainitud, et rollide arv sõltub tarkvara loomise mudelist. Mis loom see mudel või protsess selline on?

Sõnaraamat Cambridge Dictionary seletab “protsessi” järgmiselt: tegevused, mida võetakse ette tulemuseni jõudmiseks [CambridgeDict].

Mis tegevusi tuleb ette võtta, et tarkvara valmis saaks? Välja uurida, millist tulemust tellija ootab, programmeerida, testida kõige töökorras olemist ning panna tarkvara tööle. Kui ees on väiksem ülesanne, näiteks vanaemale kodulehekülje loomine, on selline nimekiri väga mõistlik ning võib kohe tööle hakata: täpsustada, mis värvid vanaemale meeldivad ning teha lehekülg valmis.  Mikroprojekti puhul on selge, mida teha. Mida suuremaks kasvab ülesanne, seda keerulisem on selle realiseerimine. Suurem on ka oht, et mingil hetkel kaob ära arusaamine tehtud ja tegemata asjadest või eeldatavast ajakulust. Sellistes asjades selgusele jõudmiseks hakati mõtlema struktureeritud tegevuse peale, nii sündisidki esimesed tarkvara loomise protsessi mudelid.

Koskmudel (waterfall)

Aastal 1970 räägiti esimest korda tarkvara loomise mudelist nimega waterfall (koskmudel, lineaarne mudel W. Royce 1970[Royce]) :

1. nõuete kogumine ja analüüs – ülesande püstitus;
2. süsteemidisain – projekteerimine;
3. arendus ja ühiktestimine – arendamine;
4. integreerimine ja testimine – verifitseerimine (kontroll);
5. kasutamine ja hooldus – tööde vastuvõtt, tarkvara kasutuselevõtt.

Varsti oli selge, et seda mudelit tuleb iga sammu juures täiendada ja minna tagasi eelmiste juurde, näiteks kui

• leiti, et mõni ülesanne ei olnudki väga hästi sõnastatud,
• olukord on muutunud,
• leiti viga.

See tähendab, et tuli uuesti korralikult läbi vaadata, mida teha, projekteerida, arendada, kontrollida, võtta kasutusele jne.

Võeti kasutusele täiendatud iteratiivne koskmudel (waterfall iterative):

Möödunud on küll palju aastaid, kuid selline mudel (variatsioonidega) on endiselt kasutusel.

Koskmudeli plussid

Koskmudeli eelised: selged põhjused-tagajärjed, struktuur, juhtidel on lihtsam jälgida, kas projekt on graafikus, väljamaksed konkreetsete etappide eest.

Mõnikord on see ainuvõimalik lahendus.

Näiteks on koskmudel endiselt väga laialt kasutusel, kui tellijaks on riigiasutus. Samuti on mõistlik selle mudeli kasutamine väga väikeste projektide puhul, kus nõuded on selged, ei muutu ning neid ei tule juurde.

Koskmudeli puudused

Koskmudeli puudusteks on kõrge hind, väga pikk valmimisaeg, palju dokumente: iga tagasiminek on väga kallis, igal etapil tehtud muudatus nõuab järgmiste etappide uuesti läbimist ning dokumenteerimist.

On olnud palju projekte, mis lõpetati ning võeti vastu, kuid pole kunagi kasutusele võetud: aja jooksul muutusid nõuded nii palju, et valmistarkvara polnud enam vajalik (suure süsteemi kõikide vajaduste peensusteni kirja panemisele võib minna mitu aastat ning paar metsamassiivi dokumentatsiooni koostamisele).

Millal valida koskmudel?

1. kui nõuded on teada ning need on lõplikud ega muutu protsessi käigus;
2. on teada, mis tehnoloogiaid kasutada;
3. projekt ei ole liiga pikk;
4. tellija võib olla huvitatud selle mudeli kasutamisest, kui tal ei ole ressursi tegeleda projektiga pidevalt, vaid ainult tellimise (nõuete kogumise) ning testimise ajal.

Enesekontroll (1 küsimus)

Iteratiivne mudel

Koskmudeli kitsaskohtade vältimiseks võeti kasutusele iteratiivne mudel (1980 Mills[Mills]). Vaadeldud mudelis on protsess väga otsejooneline: konkreetsed etapid konkreetses järjekorras, liikumine punktist A punkti B ja tulemuseks on lõpptoode.

Iteratiivse mudeli puhul valmistatakse toote esimene variant, see vaadatakse üle, otsustatakse, kas on valitud õige tee. Algab uus iteratsioon: toodet täiendatakse, see vaadatakse üle, otsustatakse, kas on valitud õige tee. Algab uus iteratsioon… kuni toode (imeilus pilt) saab valmis:

Iteratiivse mudeli puhul on kogu protsess jagatud mitmeks etapiks (siin ja edasi – iteratsioon), iga iteratsioon kestab 2-6 nädalat. Alguses valmistatakse tarkvara kriitilisem osa, sisuliselt jälgitakse seejuures samu samme, mida koskmudeli puhul. Järgmise iteratsiooni ajal täiendatakse tarkvara, luues uue funktsionaalsuse või täiendades seda, mis oli varem tehtud. Iteratsioone korrutatakse projekti lõpetamiseni. Kui tarkvara on valmis, võetakse see kasutusele. Protsessi paremaks suunamiseks võetakse arvesse riskianalüüsi tulemusi. Iteratiivset mudelit võib näidata järgmiselt:

Iteratiivse mudeli raamistikud on näiteks RUP (The Rational Unified Process), EUP (The Enterprise Unified Process).

Iteratiivse mudeli eelised

Kuna alustada saab üsna kiiresti, tulevad ka esimesed tulemused kiiresti, mis aitab äril (tellijal) paremini aru saada, kas projekt kulgeb õiges suunas. Tänu sellele on ka riskide haldamine lihtsam. Projekt on lihtsalt mõõdetav, seepärast sobib  suurtele klientidele, kelle jaoks on oluline suure eelarve täpne haldamine. Teoreetiliselt on võimalik panna käima paralleelselt mitu iteratsiooni, mis kiirendab valmistooteni jõudmist. Vigadest õppimine – saab vältida eelmise iteratsiooni käigus avastatud riske ja vigu. Iteratiivne mudel on paindlik – projekti jooksul on võimalik muuta esialgseid nõudeid. [SDLC Models Guide]

Iteratiivse mudeli puudused

Oma paindlikkuse tõttu vajab see mudel väga tugevat ning pidevat projektijuhtimist. Tööressursi haldamine on raskem ning see vajab rohkem tööjõudu kui koskmudel (koskmudeli puhul on analüütikul kindel ning pidev töö projekti alguses, hiljem ainult toetav funktsioon, siis saab teda suunata teise projekti juurde jne). Probleeme võib tekkida arhitektuurses disainis, kui projektiga tegelev seltskond ei ole väga ettenägelik või kogenud. Riskianalüüs vajab täiendavat tööjõudu ja see on kulukas.

Millal kasutada iteratiivset mudelit?

1. On olemas üldine pilt, mida tahetakse saavutada. Väiksemaid ülesandeid saab täpsustada hiljem.
2. Projekt on suur. Kui on oht, et projekt venib pikaks, tasub võtta kasutusele iteratiivne mudel, kuna see lubab rakendada paralleelseid iteratsioone: minimeerib riski, et projekti lõpuks muutuvad tarkvara vajadused/nõudmised.

Agiilne mudel

Tasapisi hakkas välja kujunema uus paradigma: mida kiirem, seda parem. Mitmed inimesed jõudsid järeldusele, et mida varem saab tellija kätte tulemuse, seda parem. Nii saab kiiremini otsustada, kas see, mida tehakse, ikka vastab vajadustele, kas projekti on mõtet arendada või pole see kuluefektiivne ning tuleb aegsasti kinni panna.

Uuteks meetoditeks kujunesid: Extreme Programming, Scrum, DSDM (Dynamic System Development Method), Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming jne.

11.-13.02.2001 kohtusid 17 nimetatud meetodite nimekamat kasutajat ja/või leiutajat ning leppisid kokku uue paradigma sõnastuses ([agiilsuse manifest]):

“Tarkvara luues ning teisi tarkvara loomise juures aidates oleme leidnud selleks tööks paremaid viise. Oleme hakanud hindama:

• inimesi ja nendevahelist suhtlust rohkem kui protsesse ja arendusvahendeid,
• töötavat tarkvara rohkem kui kõikehõlmavat dokumentatsiooni,
• koostööd kliendiga rohkem kui läbirääkimisi lepingute üle,
• reageerimist muutunud oludele rohkem kui algse plaani järgimist.

Ka parempoolsetel teguritel on väärtus, kuid me hindame vasakpoolseid tegureid kõrgemalt.”

Agiilse arendamise mudeli puhul tarnitakse tellijale valmistarkvara iga etapi lõpus. Etapid on lühikesed – 1-2 nädalat (mõni meetod lubab ka 4 nädalat, mis on pigem erand). Iga päev saab projekti meeskond kokku, et kiiresti arutleda, mis möödunud päeval tehtud on, kas mõni ülesanne vajab lisatuge. Agiilse meetodi juures võib olla väga vähe rolle. Näiteks Scrumi puhul on minimaalne rollide arv kolm: tooteomanik, scrum-master ja meeskonnaliige. Iga iteratsiooni lõpus toimub tagasivaade: mida saab antud etapil õppida, mis läks hästi, mis halvasti. Agiilset meetodit võib skemaatiliselt esitada nii:

Agiilse mudeli eelised

Agiilse mudeli peamised eelised on kiirus, reageerimine olukorra muutustele, inimeste suhtlemine. Tellija on motiveeritud liikuma koos projekti meeskonnaga, ta on ise ka meeskonna liige ja kaasatud kogu protsessi.

1. Tellija rahulolu – uus tarkvara tarnitakse tihti ja kiiresti.
2. Inimesed on protsessidest olulisemad: kõik projektis osalevad inimesed on pidevas suhtlemises, mõjutades tulemust.
3. Projektis osalejad saavad kiiresti tagasisidet, kas see, mis tehti, on vajalik.
4. Olukorra muutmisel saab toodet kiiresti muuta.
5. Nõudeid saab muuta isegi väga hilisel projekti etapil.
6. Dokumenteerimine on minimaalne: puhas isedokumenteeriv kood tähendab, et tekib vähem dokumente (mida keegi ei loe) ning koodi puhtana hoidmine on arendaja ülesandeks, ehk on suurem tõenäosus, et dokumentatsioon (minimaalne arv dokumente + isedokumenteeriv kood) on aktuaalne.

Agiilse mudeli puudused

Agiilse meetodi kõige suurem puudus on inimeste kompetents: nii tellija kui ka arendustiim peavad olema väga kogenud, enesekriitilised ja julged otsustama.

1. Tellijal peab olema oskus ning volitus võtta vastu kiireid ning suuri otsuseid.
2. Arendajate tiim peab olema väga kogenud (omama suurt kogemust, et näha ette võimalikke probleeme).
3. Rahastamine pole läbipaistev. On oht, et raha saab otsa enne kui ülesanded.
4. Agiilse mudeli puhul on dokumenteerimise piirid väga hägusad, tihti dokumente ei tekigi. Dokumentatsiooni korrashoidmine on tugevalt seotud meeskonna kohusetundlikkusega.

Millal kasutada agiilset mudelit?

Agiilne mudel sobib, kui

1. meeskond (tooteomanik, arendustiim) on väga tugev;
2. on soov projektiga kiiresti alustada (ei vaja pikka analüüsi faasi);
3. on tõenäosus, et mõned nõuded ilmnevad hiljem;
4. rahastus ei ole probleemiks.

[TRY QA]

Enesekontroll (1 küsimus)

Tuletame meelde, millised meetodeid oleme juba vaadelnud:

Veel mudeleid

On olemas veel mitu erinevat tarkvara loomise protsessi: spiraalmudel, Lean (jah, seesama Toyota Lean), DevOps. Neil kõigil on oma koht tarkvara loomise juures. Internetist leiab palju sellekohast infot.

Ajaloohuvilistele on lisalugemiseks järgmine link: mudelite ajatelg.

Kokkuvõte

Olemas on mitu erinevat tarkvara loomise protsessi, nende klassika on: koskmudel (ingl waterfall), iteratiivne (ingl iterative), agiilne (ingl agile).

Tarkvara loomisse on kaasatud mitmeid inimesi, kes täidavad erinevaid rolle: tellija, arendaja, testija, projektijuht.

Pole olemas üht tõde, mudel tuleb valida lähtuvalt vajadustest ning võimalustest. Tihtipeale valitakse meetod või mitu ning kohandatakse vastavalt enda vajadustele/võimalustele.

Kasutatud kirjandus

[CambridgeDict] https://dictionary.cambridge.org/dictionary/english/process

[NATO konverents] http://homepages.cs.ncl.ac.uk/brian.randell/NATO/Introduction.html

[agiilsuse manifest] https://agilemanifesto.org/iso/et/manifesto.html

[Royce]

http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf , https://airbrake.io/blog/sdlc/waterfall-model]

[Mills] https://trace.tennessee.edu/cgi/viewcontent.cgi?referer=&httpsredir=1&article=1004&context=utk_harlan  “Management of Software Engineering, The – Part I: Principles of Software Engineering” Harlan D. Mills IBM Systelms Journal 1980