SÜSTEEMIARENDUSE PROTSESS JA MEETODID
Süsteemiarenduse ja levituse arengujooned
Kvaliteedi juhtimine ja standardid
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. [5]
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 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. [5]
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.
SEI/CMMI
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.
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. [5]
Agiilmeetodid
Arendusmetoodikates on vanade nn tardmeetodite(raskete meetodite) asemel tulnud kerged ehk agiilsed ehk paindmeetodid(vt ka B1.2). 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. [5]
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. 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 "planningpoker"- 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.
