Tarkvaraprojekti
esialgne kavandamineTarkvaraprojekti esialgsel
kavandamisel koostatakse tarkvaraarenduskava. See hõlmab järgmisi
tegevusi:
- Projekti visiooni määratlemine,
- Põhiotsustaja määratlemine,
- Projekti eesmärkide määratlemine,
- Riskihaldus ,
- Efektiivsete personalikasutuse strateegiate kujundamine,
- Ajaarvestus.
Nagu eelmisest punktist nähtub, peab ka Tarkvaraarenduskava suhtes
rakendama
muudatuste juhtimise skeemi. Käsitleme järgnevas lühidalt
tarkvaraarenduskava iga alajaotust.
Projekti visioon . Enne
mistahes projekti käivitamist peab
projektimeeskond projekti
põhieesmärgi suhtes kujundama ühised arusaamad ja need ka
kirjalikult lühidalt formuleerima. Põhieesmärk peab olema kõrge,
kuid reaalne.
Halvim on, kui projekti täitjad saavad aru eesmärkide
ebareaalsusest, kuid projekti
juhtkond mitte; sellisel juhul täitjate
motivatsioon langeb kiiresti. Visioonist peaks lähtuma,
määratlemaks, mida loodav
tarkvara peab võimaldama ja mida mitte.
Näiteks
MS Word for Windows 1.0 arendamine võttis algselt
kavandatud ühe aasta asemel aega viis aastat, kuna eesmärgid olid
seatud liiga kõrged!
Seega on näiteks “Luua maailma parim tekstitöötlussüsteem”
liiga üldine, parem oleks “Luua maailma kõige kasutajasõbralikum
tekstitöötlussüsteem”, kuna annab arendajatele ka
ideid, mida ei peaks
tarkvara koosseisu lülitama.
Põhiotsustaja
määratlemine.
Projektiga seonduvate lõplike otsustuste
tegija peab olema
määratletud; see võib olla üks inimene või rühm (näiteks
juhtrühm).
Viimasel juhul peaksid selles olema
esindatud kõik põhilised
huvirühmad.
Projekti
eesmärkide määratlemine.
Eesmärgid võivad projekti täitmise käigus oluliselt täpsustuda
ja ka teiseneda, sõltuvalt näiteks projekti täitmise ajagraafikus
püsimisest, eelarve muutumisest jne.
Näiteks NASA SEL (Software Engineering Laboratory ) täpsustab reeglina oma
projektides eesmärke viis korda, arvestades seejuures ka vastavaid
“määramatuse kordajaid”, vastavalt allpoololevale tabelile:Eesmärkide täpsustamise
aeg Ülemise piiri tegur Alumise piiri tegurNõuete väljatöötamise
järel 2,0 0,5
Nõuete analüüsi
järel 1,75 0,57
Esialgse disaini
järel 1,4 0,71
Detailse disaini
järel 1,25 0,80
Kodeerimise 1,1 0,91
Süsteemi testimise
järel 1,05 0,95
Eesmärkide ja muude kavade
suuremaks adekvaatsuseks on oluline kogu projektimeeskonna kaasamine
nende väljatöötamisse. Kui projektimeeskond kavasid heaks ei
kiida, siis ta neid reeglina ka ei täida. Projekti täitmise käiku
iseloomustavad näitajad peaksid pidevalt olema projektimeeskonnale
teada (näiteks projekti kodulehekülg intranetis); nende hulgas
peaks kindlasti olema järgmised:
- Juba täidetud ülesannete loetelu
- Vigade statistika
- Põhiliste riskide loetelu
- Projekti täitmise protsent ajaliselt
- Projekti täitmise protsent ressursside osas
- Projekti vahearuanded
Riskihaldus.
Lõviosa tarkvaraprojekte pöörab riskide vähendamisele vaid
sümboolset tähelepanu. Optimaalne on kulutada sellele 5-10%
projekti vahenditest; suurem osakaal muudab projekti liiga
bürokraatlikuks ja kohmakaks,
kusjuures projekti edukus kasvab
minimaalselt. Liiga suure osa vahendite kulutamine riskihaldusele
(üle 25%) vähendab projekti tulemuslikkust, kuna põhitegevusele
jääb sel juhul liiga vähe vahendeid. Riskihaldamise edukus sõltub
sellest, kuivõrd pühendunult seda tehakse, selle läbiviimise
võime arendamisest, vastavate riske vähendavate tegevuste
sooritamisest ja selle kontrollimisest, et iga riski haldamise kava
oli efektiivne. Riskihalduse kava peab olema kirjalik, koos vajalike
eelarveliste vahenditega ja riskide analüüsi tulemusi peab
arvestama projekti edasisel täitmisel. Keskmiste ja suurte
projektide korral on otstarbekas määratleda riskide analüüsi ja
võimalike probleemide ennetamise peale eraldi töötaja –
riskihaldur (kel võib projekti raames olla ka muid ülesandeid).
Sageli on need ülesanded ühitatud testimisega. Riskihalduri üheks
ülesandeks on ka regulaarselt (näiteks iga kahe nädala tagant)
antud momendi põhiliste riskide loetelu koostamine, aga samuti
riskide vähendamiseks lahenduste pakkumine.
Näide.
Põhiliste
riskide tabel.
Nr.
Mitu nädalat
loetelus Riski nimetus
Riski vähendamise võimalused
1.
4
Väljastatud tarkvara madal kvaliteet
Loodud
kasutajaliidese prototüüp, veendumaks kasutajate rahulolus.
Kasutatakse süsteemset arendusprotsessi.
Testimine kavandatakse nii, et see kataks kogu funktsionaalsuse.
Süsteemi testimine sõltumatute ekspertide poolt.
2.
4
Ajagraafikust mittekinnipidamine
Ajagraafik vaadatakse projekti käigus korduvalt üle.
Aktiivne protsessi jälgimine toob
nihked ajagraafikus koheselt välja.
Kasutatakse mitmeetapilist
tarkvaraarendus - ja väljastusmudelit.
3.
1
Kõrged kulutused
Detailne projekti kavandamine loob selged ootused.
Keskkond toetab kõrget tööviljakust, motivatsiooni ja kokkuhoidu.
4.
5
Tööruumide ebaotstarbekas kasutamine
Peale kasutajaliidese prototüübi valmimist viiakse arendustegevus teistesse ruumidesse (erapindadele).
Tabelis võib kasutada
lisaveerge, näiteks riskide vähendamist realiseerivate inimeste
nimedega. Iga riski jaoks peaks looma eraldi riskikäsitluskava, mis
vastaks järgmistele küsimustele:
Riski realiseerumise tõenäosus ja tagajärjed.
Riski vähendamise võimalikud teed.
Riski vähendamiseks vajalikud konkreetsed sammud ja meetmed, kui riski ei õnnestu vähendada.
Kes vastutab iga sammu teostamise eest.
Sammude teostamise tähtajad.
Millised eelarvelised vahendid eraldatakse riski vähendamiseks, iga sammu jaoks eraldi.
Kuna riskide käsitlemiseks on vajalik projekti käiguga pidevalt
kursis olla, siis probleemiks võib osutuda halbades uudiste kiire
teadasaamine (head uudised levivad välgukiirusel iseenesest).
Selleks tuleb luua vastav anonüümne kanal vastavate teadete edastamiseks, näiteks kasvõi projekti veebilehe kaudu.
Tarkvaraprojektide täitmisega seotud riskide hindamiseks on töötatud
välja ka vastavaid meetodeid (vt näiteks http://www-cgi.cs.cmu.edu/~SW_Managemnt/pdf/tr19.94.pdf , SEI
tehniline aruanne CMU/SEI-94-TR-19 “Software Risk Evaluation
Method”).
Efektiivsete
personalikasutuse strateegiate kujundamine.
Põhiidee on, et projektijuht kannab vastutust selle eest, et
projekti täitmise tulemusena asutuse inimressursi kvaliteet paraneb .
Kui näiteks projekti täitmine põhjustab viie inimese lahkumise,
siis kannab asutus seeläbi otsest kahju. Seega peaks arvestama
näiteks järgmiste aspektidega:
- Juhte tuleb hinnata ka selle järgi, kuivõrd hästi nad säilitavad projektimeeskonna,
- Projektimeeskonna kõikidel liikmetel peavad olema võimalused enda personaalseks arendamiseks .
Projektimeeskonna
koostamisel tasub pigem natuke rohkem vaeva näha heatasemelise
töötaja otsimisel kui et võtta koheselt tööle vähem kogenud
spetsialist, lootes tema edasisse arengusse . Tarkvaraarendajate seas
on laialt levinud seisukoht, et parimad arendajad on kuni 10 korda
suurema tööviljakusega kui halvimad tarkvaraarendajad. Seejuures 31
tarkvaraarendajate rühma uurimisel selgus, et individuaalsetest
oskustest olulisem on projektimeeskonna kooskõla (B.Lakhanpal,
Information
and Software Technology,
35 (8), 468-73), st kui hästi laabub nende koostöö. Seetõttu on
väga oluline ka probleeme tekitavatest meeskonnaliikmetest vabanemine . Nagu vastavatest uuringutest nähtub (Carl E.Larson,
Frank M.J. LaFasto, tuginedes 75 projekti analüüsile), on
etteheidetest projektijuhtidele esikohal probleemsete inimeste
küsimuste lahendamine. Väga sageli on ka “raske inimese”
tööviljakus väga madal. Mõnikord – mõne äärmiselt
olulise probleemi ülikiireks lahendamiseks – on vaja moodustada
väike (1-2 inimest) “tiigrirühm”, kes selleks ajaks
vabastatakse oma muudest töökohustustest. Siinjuures peab arvestama
inimeste erineva suhtumisega: mõni tõlgendab “tiigrirühma”
kuulumist kui erilist tunnustust, teine aga kui põhitöö segamist.
Ajaarvestus.
Projekti algusfaasis on oluline järgida projektimeeskonna
ajakasutust. See on aluseks ajakulu hinnangute tegemisel, seda
nii jooksvas projektis kui eriti uute projektide kavandamisel. Näite ajakasutuse kategooriatest (st tegevustest, millele kuluvat aega
mõõdetakse ja analüüsitakse), võib leida aadressilt
www.construx.com/survivalguide.
Ajaarvestuseks on loodud ka sellekohast tarkvara (time- accounting programs,
vt. eelpooltoodud aadressilt).
Nõuete väljatöötamine
Nõuete
väljatöötamise faasis analüüsitakse tarbija/ tellija vajadusi
(sealhulgas ka analoogseid turul olevaid tooteid) ning töötatakse
selle alusel välja tarkvaraspetsifikatsioon. Viimane võib olla ka
kasutajaliidese prototüübi kujul.
Tarbija
vajaduste kindlakstegemisel peab teda sageli aitama oma vajaduste
määratlemisel. Ebaadekvaatsuse või vigade korrigeerimine võib
edaspidi – tarkvara väljatöötamise hilisemates faasides – väga
kalliks maksma minna. Näiteks tervikliku rakendustarkvara väljatöötamisel võiksid sooritatavad sammud olla järgmised:
Rühma usaldusväärsete (lõpp)kasutajate määratlemine, kes aitaksid otsustada loodava tarkvara eri aspektide üle. Nende hulgas peaks lisaks oma ala tunnustatud tegijatele ka keskpäraseid kasutajaid olema.
Kasutajate intervjueerimine esialgsete nõuete määratlemiseks. Kogemused on näidanud, et professionaalsete tarkvaraarendajate ja tavakasutajate arusaamad heast tarkvarast reeglina mõnevõrra erinevad. Sageli – eriti infosüsteemide arendamisel – on vaja korraldada kõiki osapooli kaasates seminare ja õpitube (JAD, Joint Application Design).
Kasutuslugude modelleerimine , määratledes ja modelleerides kasutaja vajadustest lähtuvaid tegevusi tarkvara rakendamisel.
Lihtsa kasutajaliidese prototüübi loomine, pakkudes ka mitmeid alternatiive. Prototüüp peab olema võimalikult lihtne, kuid siiski andma tarbijale võimalikult adekvaatse ettekujutuse (ka visuaalse) tööst loodava tarkvaraga. Üheks võimaluseks on näiteks stsenaariumi koostamine, kus koostatakse joonised ekraanipiltidest, dialoogikastidest, menüüdest ja muudest elementidest. Prototüüpi tuleb täiustada niikaua , kuni kasutajad selle aktsepteerivad. Seejuures peavad kasutajad teadma ja arvestama, et tegemist on vaid prototüübiga, mille loomiseks ei tohi liigselt aega kulutada.
Koostada stiilijuhis, mis sätestab tarkvara visuaalse ja loogilis-tunnetusliku standardi. Stiilijuhis sisaldab näiteks standardsete nuppude suuruse ja asetuse , lubatavad kirjatüübid, veateadete stiili, põhioperatsioonide mnemoonika jne.
Kasutajaliidese prototüübi väljaarendamine, mis sisaldaks kogu funktsionaalsuse (ilma et funktsionaalsus ise realiseeritud oleks). Probleemsed funktsionaalsused (st need, mille realiseerimine on problemaatiline) peab dokumenteerima eesmärgiga saada nende realiseerimiseks võimalikult rohkelt ideid ja ettepanekuid . Kuna tegemist on prototüübiga, mitte valmistarkvara komponendiga, siis ei tohi ka sellele liiga palju ressursse kulutada. Sageli teostatakse prototüüp hoopis teises keskkonnas kui arendatav tarkvara (näiteks Visual Basic versus Java või C++). Nii stiilijuhise kui kasutajaliidese prototüübi peab võtma muudatuste juhtimise protsessi.
Kasutajaliidese prototüübi alusel detailse kasutusjuhise kirjutamine. Enamasti kirjutatakse kasutusjuhendid projekti lõpus, kuid sellisel juhul 1) ei jää aega kasutajatelt tagasiside arvestamiseks ja 2) tarkvara kasutamise loogika võib kohati olla mittekooskõlaline (kasutajat ei huvita mitte niivõrd ühe operatsiooni, kuivõrd eesmärgi saavutamiseks vajaliku operatsioonide jada sooritamine ).
Suur osa tarkvara sisaldab lisaks ka funktsionaalsust, mida ei saa piisavalt hästi kasutajaliidese või kasutusjuhise abil kirjeldada: erinevad algoritmid, suhtlemine muu tarkvaraga, mälukasutus jne. Nende kirjeldamiseks peab looma omaette dokumendi.
Nõuded
peavad olema kirjalikult fikseeritud ning kõikidele osapooltele
kättesaadavad.
Ülesanne.
Leida kolm internetiallikat, milles käsitletakse IT-projekti skoobi
liigsest laiendamisest (scope creep) tingitud ebaõnnestumist.
Kvaliteedikindlustus
Kõige
üldisemalt mõistetakse kvaliteedi all määra, mil tarkvara vastab
sätestatud ja nendest tulenevatele nõuetele. Üldjuhul see, kas
tarkvara valmis tähtaegselt või ületati tähtaeg mõne nädala
võrra, ununeb ruttu; samas ebakvaliteetsest tarkvarast põhjustatud rahulolematus on pikaaegne. Seega on kvaliteet olulisem kui mistahes
muu näitaja. Selle tagamiseks koostatakse kirjalik
kvaliteedikindlustuse
kava.
Seejuures tuleb arvestada järgmiste asjaoludega:
- Tarkvara kvaliteedikindlustuse tegevused peavad olema kavandatud,
- Need tegevused peavad algama hiljemalt tarkvaranõuete väljatöötamise faasis,
- Kvaliteedikindlustus tuleb sätestada kellelegi (või rühmale) eraldi tööülesandena,
- Kvaliteedikindlustuse töötaja peab saama piisavat sellealast koolitust,
- Tarkvara kvaliteedikindlustuse tegevused tuleb adekvaatselt finantseerida,
Kvaliteedikindlustuse
kava peaks sisaldama järgmiseid tegevusi:
- Vigade otsing. Iga vea peab dokumenteerima (asukoht; vea kirjeldus ja raskusaste; millal, kes ja kuidas avastas ja lahendas jne) ning avalikustama; vigade otsinguks kasutatakse spetsiaaltarkvara (vt. näiteks www.construx.com/survivalguide/ )
- Üksuse testimine. Seda teeb arendaja lähtekoodi testimise kaudu
- Lähtekoodi läbimine interaktiivse siluja abil, teostab tarkvaraarendaja. Oluline eelkõige enne tarkvara integreerimist
- Tehniline ülevaatus, läbi viidud põhiliselt kvaliteedikindlustuse töörühma poolt. Teostatakse tehniliste töötulemuste (kasutajaliidese prototüüp, nõuete spetsifitseerimine, arhitektuur , disain jne) kvaliteedi kontrollimiseks. See toimub reeglina ühtse skeemi kohaselt: 1) töö teostaja teavitab selle ülevaatuseks valmisolekust ja edastab vajalikud mater jalid; 2) Kontrollijad analüüsivad töö tulemusi; 3) Töö teostajad ja kontrollijad kohtuvad, arutamaks töötulemusi; 4) Ülevaatuse aruande koostamine (sisaldab muuhulgas ka avastatud vigade loendi ja nende kõrvaldamise ajagraafiku); 5) Töö ülevaatusejärgne täiustamine. Tehnilise ülevaatuse läbiviimisel peaks järgima järgmiseid soovitusi : 1) Ülevaatus peaks piirduma vigade otsimisega, mitte hõlmama lahenduste pakkumist; 2) Ülevaatus peaks olema tehniline, mitte kaasama tarbijaid ja juhtkonda; 3) Jälgima, et tehnilise ülevaatuse käigus avastatud puudused edaspidi tõesti kõrvaldataks; 4) Ülevaatuse tulemused tuleb avalikustada projektirühmale; 5) Ülevaatuste ja puuduste kõrvaldamise jaoks peab eraldi aja reserveerima, seda ei saa teha muu tegevuse kõrval.
- Terviklikkuse testimine toimub tarkvaraarendaja poolt ning eesmärgiks on tagada viimati loodud koodi ühilduvus varem loodud tarkvaraosaga
- Süsteemi testimine, mille käigus analüüsitakse produkti valmiskomponente. Arvestama peaks järgmiste soovitustega: 1) Testijateks ei tohiks olla tarkvara arendajad; 2) Testimise kavandamist peab alustama nõuete fikseerimise järel ja testimist alustama juba 1.etapil; 3) Süsteemi testimine peab katma 100% funktsionaalsusest; 4) Süsteemi testimiseks peab olema piisavalt ressursse. Näiteks kvaliteetse laiatarbetarkvara tootmisel on testijate arv võrreldav arendajate arvuga; lennujuhtimistarkvara tootmisel ületab testijate arv arendajate arvu kuni 10 korda! Testimine võimaldab hinnata tarkvara kvaliteeditaset, mitte ei ole kvaliteedikindlustuse vahendiks (ainuüksi testimine parandab tarkvara kvaliteeti samavõrd nagu enda kaalumine vähendab kaalujälgija kehakaalu).
Kvaliteedikindlustuse
kava peaks ka määratlema, millal tunnistada tarkvara
levitamiskõlbulikuks. Näiteks: “kõik 1. ja 2. raskusastme vead
on parandatud”, “keskmine vigade avastamise intervall 8 tundi”
vmt.
Beeta-testimine.
Eriti komplekssete tarkvarasüsteemide testimine antakse peale
asutusesisest testimist laiemale asutusevälisele ringile testimiseks ( eksperdid , erialaajakirjad, kliendid, avalikkus ).
Eesmärgiks on võimalikult laia ja mitmekesise tagasisideme
saamine (näiteks loodava tarkvara ühilduvuse kohta kõikvõimaliku
riist- ja tarkvaraga). Beeta-testimine on suhteliselt ebaefektiivne,
kuna 1) suur osa testijaist ei viitsi avastatud vigadest teatada ja
2) tarkvaratootjaile laekub tohutul hulgal ettepanekuid tarkvara
muutmise kohta. Efektiivsem on, kui palgata kasutajate esindajad
mõneks ajaks testijaina tööle kogenud tugiisikute käe all.
Kvaliteedikindlustuse
rühm peaks osalema ka Tarkvaraarenduskava, standardite ja
protseduuride väljatöötamisel.
Kvaliteedikindlustuse
osas on loodud omaette institutsioone (näiteks www.sqi.gu.edu.au,
Software Quality Institute), aga samuti terve rida veebilinkide
kogusid, nagu (näiteks www.cs.umu.se/~jubo/Projects/ QMSE ,
Quality Management for Small Enterprices).
Tarkvaraarhitektuur
Tarkvaraarhitektuur
hõlmab tarkvara üldist disaini: alamsüsteemide ja nendevahelise
interaktsiooni määratlemine, vigade tööt lemise põhimõtted,
mäluhaldus jne. Arhitektuur peab olema võimalikult lihtne ja
kontseptuaalselt terviklik. Üldjuhul peaks põhiliste alamsüsteemide
arv olema alla kümne, näiteks: 1) kasutajaliides , 2) funktsionaalsed alampro grammid , 3) andmete salvestamine , 4)
väljastamine, 5) kasutaja abivahendid , 6) alamtaseme vahendid
(näiteks mäluhaldus). Ka ei tohiks alamsüsteemidevaheline
interaktsioon olla liiga keerukas. Eraldi peaks olema kirjeldatud iga
alamsüsteemi funktsioonid ja esialgne mooduliteks jaotus ja milline
infovahetus on erinevate alamsüsteemide vahel lubatud (hea
arhitektuuri korral toimub kommunikatsioon võimalikult väikese arvu
alamsüsteemide vahel, isegi kui selleks on vaja mõnes alamsüsteemis
lisakoodi luua). Suuremamahuliste projektide kirjeldamiseks peaks
kasutama UML-i
(Unified
Modeling Language ).
Juba arhitektuuri etapil peaks püüdma määratleda need
tarkvaraosad, kus kõige tõenäolisemalt võib edaspidi osutuda
vajalikuks muudatuste sisseviimine (põhjustatuna näiteks
muudatustest arendatava tarkvaraga seotud tarkvaras), aga samuti
tarkvarakomponendid, mis ostetakse/tellitakse väljastpoolt, mis
võetakse kasutusele varemarendatud tarkvarast ja mis arendatakse
uuena. Viimati nimetatud komponentide oskusliku kombineerimise
tulemusena võib tarkvara arendamise aega ja selleks kuluvaid
ressursse oluliselt vähendada.
Arhitektuuri
faasis peab käsitlema ka tervet rida tarkvara funktsionaalsusega
seotud küsimusi, nagu näiteks:
- Kas ja millise muu tarkvaraga ning millise protokolliga ja andmetega peab loodav tarkvara suhtlema ,
- Mil määral on kasutajaliides seotud tarkvara muude osadega,
- Milline on kasutatavate andmebaaside struktuur ja sisu,
- Kuidas salvestatakse muud (st andmebaasidevälised) andmed,
- Milliseid põhialgoritme kasutatakse,
- Kuidas korraldatakse mäluhaldus,
- Kuidas on lahendatud paralleelprotsessid ja mitmekasutaja võrguopeatsioonid,
- Turvaprobleemide lahendamise põhimõtted,
- Tarkvara adapteeritavus teistesse keeltesse, aga samuti teistele platvormidele,
- Kuivõrd avatud täiendavate funktsioonide realiseerimiseks ja dünaamiline on loodav tarkvara,
- Vigade käitlemise kooskõlalised põhimõtted.
Arhitektuuri
käsitlev dokument peab ka selgitama, kuidas arhitektuur on kooskõlas
projekti etappidega ning sellesse tuleb kõik projekti täitmise
käigus tehtud muudatused sisse viia. Arhitektuuri juures ei saa
taotleda maksimaalset, vastasel korral ei jõuta projekti
realiseerimisega lõpule või kui jõutaksegi, on see juba
lootusetult vananenud. Nii arhitektuuri kui ka teistes (eelkõige
realisatsiooni) faasides peab püüdma lihtsuse poole: suure hulga
programmide ebaõnnestumine on tingitud just seetõttu, et on
muutunud keerulisteks ja ebaülevaatlikuks.
Arhitektuuri
kavandamisel peab arvestama töömahu ja programmimahu sõltuvusega:
kui näiteks 25 000-realise programmi loomine nõuab keskmiselt 20
inimkuud, siis 75 000-realise juba keskmiselt 140 inimkuud (suhteline
kasv rohkem kui 2 korda).
Väikesemahuliste
projektide korral arhitektuuri ja disaini ei eristata. Tööd
arhitektuuri alal on otstarbekas alustada, kui nõuete
väljatöötamisest on täidetud ligikaudu 80%. Sellel etapil peab
selgelt sõnastama ka tarkvarastruktuuri kujundamise üldised
eesmärgid, näiteks kuivõrd peab arendatav tarkvara olema
modifitseeritav.
Lisaks
on sageli otstarbekas vaadelda ka arhitektuuri teatud vaateid,
mis hõlmavad vaid arhitektuuri teatud elemente. Vaateid võib
kujutada näiteks disaini-faasis koostatud UML-mudelite teatud
abstraktsioonide või osahulkade abil.
Kõige
sagedamini vaadeldakse järgmiseid vaateid (vt. Näiteks http://www.rational.com/media/whitepapers/Pbk4p1.pdf ):
- Disaini vaade (loogiline vaade), mis kirjeldab disaini mudeli arhitektuurselt olulisi struktuure ja funktsioone. Lähtutakse eelkõige kasutajast.
- Protsessi vaade, mis kirjeldab ülejäänud kolme vaate vahelisi seoseid . Aluseks on mittefunktsionaalsed nõuded (jõudlus, tarkvara integreeritus, veakindlus jne), kusjuures protsessina käsitletakse mingit terviklikku täidetavat üksust. Võib esitada erineval abstraktsioonitasemel.
- Komponentide vaade, mis kirjeldab tarkvaramoodulite struktuuri,
- Evitamise vaade (füüsiline vaade), mis kirjeldab tarkvara evitamisega/rakendamisega seotud füüsiliste elementide ( arvutid , võrgud, lisaseadmed jne) ja tarkvara koostööd .
Eelpoolviidatud
aadressil lähtutakse vaadete 4+1-mudelist, kus loetletud neljale on
lisandunud nn stsenaariumite (scenarios) vaade. Kasutusmall on
süsteemi osa funktsioonide kirjeldus kasutaja terminates,
stsenaariumid aga kasutusmallide
(use cases ) elemendid (mis ei pruugi olla kirja pandud kasutaja
terminates).
Tarkvara väljastamine
Tarkvara
väljastamiseks valmisolek peaks saavutatama iga etapi lõpus, see
välistab vigade ja mittekavandatud töö kuhjumise. Üldiselt võib
protsessi pidada väga efektiivseks, kui 95% vigu kõrvaldatakse
nende tekkimise faasis. Tarkvara väljastamiseks valmisoleku üle
otsustamiseks on kasutatavad mitme tehnikad.
Vigade
loendamine.
Vead võib nende olulisuse järgi jagada kolme kategooriasse:
kriitilised,
olulised, kosmeetilised.
Hinnates vigade kõrvaldamise keskmist aega, saab leida summaarse
vigade kõrvaldamiseks kuluva aja. Lihtsaim programmi valmisoleku
otsustamise viis on vigade tiheduse järgi (st keskmine vigade arv
koodirea kohta). Kui varasemate kogemuste järgi kõigub vigade arv
1000 koodirea kohta vahemikus 7…9, siis 50 000 uue koodirea puhul
vaid 250 vea fikseerimine viitab sellele, et tarkvara ei ole
väljastamiseks küps.
Vigade
arvu ennustamine kahe testirühma kasutamisega.
Kui avastatud vigade arv on vastavalt N ja M, kusjuures mõlema rühma
poolt avastatud samade vigade arv on L, siis vigade koguarvu hinnanguks on N*M/L. Kahe testirühma kasutamine on kulukas , mistõttu
seda tehnikat kasutatakse eelkõige tarkvara puhul, kus vähene
vigade arv on eluliselt oluline.
Tõenäosusmeetod.
Genereeritakse teatud arv vigu, mille avastamise sageduse järgi
hinnatakse vigade koguarv : kui tekitati M viga, millest N avastatud
vea hulgas oli L, siis vigade tõenäosuslik koguarv on N*M/L.
Genereeritud vead peavad olema teatud mõttes representatiivsed;
samuti ei tohi unustada sisestatud vigade hilisemat parandamist.
Otsus
tarkvara väljastamise kohta peaks tuginema mitmele indikaatorile.
Samuti on oluline kasutada väljastamise kontroll-lehte, kus on
loetletud kõik väljastamisega seotud tegevused; viimane võib
koosneda mõnest kuni mõnesaja (näiteks MS Windows korral)
punktini. Vabamüüki mineva tarkvara korral võiks see olla näiteks
järgmine (sulgudes vastutav isik):
- Täienda versiooni kohta käiv info (arendaja)
- Eemalda testimisega seotud informatsioon programmikoodist (arendaja)
- Eemalda isegenereeritud vead (arendaja)
- Kontrolli kõikide registreeritud vigade eemaldatust (testija)
- Installeeri programm CD-lt (testija) tühjale arvutile
- Installeeri programm Interneti veebilehelt (testija) tühjale arvutile
- Installeeri programm CD-lt arvutisse, kus on olemas programmi varasem versioon (testija)
- Kontrolli, et installeerimisprogramm loob korrektsed Windows- registrid (testija)
- Installeeri programm arvutilt maha (testija)
- Fikseeri distributsioonifailide nimekiri (väljastusrühm)
- Sünkroniseeri kuupäev ja kellaaeg kõikidel väljastusfailidel (väljastusrühm)
- Valmista lõplik programmiplaat (väljastusrühm)
- Kontrolli, et kõik failid oleksid programmiplaadil olemas (väljastusrühm)
- Teosta viiruskontroll (väljastusrühm)
- Teosta halbade sektorite kontroll (väljastusrühm)
- Loo varukoopia ja rakenda loodud tarkvarale muudatuste juhtimise skeemi (väljastusrühm)
- Kontrolli readme.txt faili versiooni loodud plaadil (dokumentatsioonirühm)
- Kontrolli abiinfofailide versiooni loodud plaadil (dokumentatsioonirühm)
- Kontrolli copyrighti, litsentsi ja muu õigusalaseid materjale (projektijuht, õigusnõunik).
Enne
tarkvara väljastamist peaksid kõikide oluliste lõikude juhid alla
kirjutama ühisele protokollile, millega nad tõendavad tarkvara
väljastamiseks valmisolekut.
Peale
projekti lõppu peaks koostama projekti
ajaloo.
Viimane tugineb eelkõige projekti log’idel ning projektimeeskonna
seisukohtadel, sisaldades seega nii kvantitatiivset kui kvalitatiivset informatsiooni (vt näidet lisas). Projekti
ajaloodokument tuleks läbi arutada projektimeeskonna
ühisnõupidamisel, eesmärgiga saada võimalikult suurt kasu
järgnevte projektide jaoks. Seega peab jälgima, et lõplik projekti
ajaloodokument oleks lihtsalt loetav , kõikidele kättesaadav ja
arvesse võetud järgnevate projektide kavandamisel.
Projektimeeskonna seisukohad võib saada teada ka spetsiaalsete
küsimustike abil, kus erinevaid aspekte hinnatakse näiteks 5-palli
süsteemis.
Tarkvaraprojekti maksumus
Tarkvaraprojekti
mudelite edasiarendamisel on oluline teada, millest ja kuidas sõltub
tarkvara arendamise maksumus. Suur osa kasutatavatest mudelitest on
esitatavad järgmise üldkujuga (parameetrite tähtsuse kahanemise
järjekorras):
Töökulu
= (MahtProtsess
)(Personal)(Keskkond)(Kvaliteet), kus
- Maht: sõltub kas loodava lähtekoodi suurusest või funktsioonide arvust,
- Protsess: võime hoiduda mittetootlikust tegevusest (ümbertegemine, bürokraatia jne) ja optimeerida toetavat tegevust (protsessi monitoorimine, riskianalüüs, finantsanalüüs, kvaliteedikontroll, testimine, täienduskoolitus, haldustegevus jne),
- Personal: arendajate pädevus, sh kogemused sarnaste projektide täitmisel,
- Keskkond: tarkvaraarendusvahendite ning kasutatavate tehnoloogiate ja tehnikate tase,
- Kvaliteet: arendatava tarkvara kvaliteet (jõudlus, töökindlus, kohandatavus jne).
Kuna Protsess
> 1, siis mida mahukam on programm, seda suurem on maksumus
keskmiselt ühe ühiku kohta (näiteks 10 korda suurem programm on
ühiku kohta reeglina vähemalt 1,5 korda kallim).
Ülalolev
valem hõlmab vaid arendajate poolt loodavat ning ei arvesta näiteks
valmiskomponentide kasutamist ja koodi automaatset genereerimist.
Valemi adekvaatne rakendamine on suhteliselt keeruline, kuna erinevad
elemendid on omavahel keerulises sõltuvuses: näiteks uute
tarkvaraarendusvahendite ja tehnoloogiate efektiivne kasutamine toob
kaasa ka programmi mahu vähenemise.
Momendil on
kasutuses umbes 50 erinevat tarkvara kuluarvutusvahendit, tuntumateks
COCOMO, CHECKPOINT, ESTIMACS, knowledgePlan, Price -S, ProQMS, SEER,
SLIM, SOFTCOST, SPQR/20. Kuluarvestusele on pühendatud ka veebilehti
(vt näiteks www.jsc.nasa.gov/bu2).
Mudeli valikul ja rakendamisel peab arvestama terve rea asjaoludega:
- Kuigi koodiridade arv on mahu mõõduna lihtne, tervel real juhtudel ei ole see adekvaatne, eriti objekt-orinteeritud programmeerimise korral; funktsioonide arvu kasutamise eeliseks on selle sõltumatus kasutatavatest tehnoloogiatest. Loodud on isegi vastav ühendus (The International Function Point User Group). Üldiselt on funktsioonide arvule tuginemine adekvaatsem projekti algusfaasis, koodiridadele tuginemine aga projekti edasistes faasides. Eritüübiliste mudelite vahelise ülemineku hõlbustamiseks on erinevate keelte jaoks leitud keskmised arvestuslikud koodiridade arvud, mis on vajalik ühe funktsiooni realiseerimiseks (funktsioonidena vaadeldakse kasutaja sisendit , väljundit, väliseid andmeliideseid, päringuid jne): assembler – 320, C – 128, C++ – 56, Java – 55, Visual Basic – 35 jne.
- Kulude mudelid aitavad kaasa riskide analüüsile ning võimaldavad ligikaudselt kavandada projekti, kui selle maksumus on ette antud (muutes vastavaid parameetreid, kuni kulud etteantud piiridesse mahub).
- Kulude hinnang saab tugineda eelkõige senise praktika kompetentsele analüüsile, mistõttu seda ei saa heal tasemel teha projekti- või asutuseväliste inimeste poolt: kindlasti peab kaasama projektijuhi ja põhiliste lõikude juhid.
- Kulude hinnang peab olema piisavalt detailne, võimaldamaks aru saada põhilistest riskidest ja edu tõenäolisusest.
Lähtuvalt
ülaltoodud valemist on töökulu vähendamiseks järgmised põhilised
võimalused:
Mahu
vähendamiseks:
- Korduvkasutus, seda nii arhitektuuri, protsessi, arenduskeskkonna kui tarkvarakomponentide osas. Kui korduvkasutus on alla kümne, siis komponendi arendamise kulu on kasutusarvust ligikaudu logaritmilises sõltuvuses (näiteks 2 kasutuse korral suureneb kulu keskmiselt 50% võrra ja 5 kasutuse korral 125% võrra).
- Objekt-orienteeritud tehnoloogia (sealhulgas UML) kasutamine võimaldab paremini visualiseerida arendatavat tarkvara ning keskenduda arendamist vajavale, suurendades arendatava probleemi mõistmist ja erinevate osapoolte (sh lõppkasutajate) võimet tarkvaraarenduse protsessis osaleda ja koostööd teha.
- Koodi automaatne genereerimine ( CASE vahendid, visuaalse modelleerimise vahendid, graafiliste kasutajaliideste loomise vahendid) ja muude kommertskomponentide kasutamine.
- Kõrgtaseme programmeerimiskeelte kasutamine, tulenevalt suhteliselt väikesest koodiridade arvust.
Esimese kolme meetodi
rakendamine võib vähendada (näiteks C++ kasutamisel ) omaloodud
koodiridade arvu 2-3 korda, mis omakorda suurendab programmist arusaamist ja töökindlust.
Protsessi
osas
eristatakse kolme tasandit :
- Metatasand ehk organisatsiooni tasand, mis hõlmab organisatsiooni pikaajalisi strateegiaid, investeeringute tootlust ja kogu organisatsiooni hõlmavaid regulatsioone. Põhiprobleemid: bürokraatia ja standardiseerimine .
- Makrotasand ehk projekti tasand, mis seisneb metatasandi rakendamises konkreetse projekti kontekstis; hõlmab projektiga seoduvat poliitikat, protseduure ja praktikat, eesmärgiga konkreetsete ajaliste ja materiaalsete vahendite juures toota nõuetele vastav tarkvaratoode. Põhiprobleemid: kvaliteet ja kulude optimeerimine .
- Mikrotasand ehk projektirühma tasand, hõlmates vaheesmärgi saavutamiseks vajalikku poliitikat, protseduure ja praktikat. Põhiprobleemid: sisu ja ajagraafik.
Protsess võib oluliselt
vähendada eesmärgi saavutamiseks vajalikku tööjõukulu. Näiteks
n-sammulise protsessi korral võib püüda suurendada iga sammu efektiivsust , aga võib ka mõne sammu elimineerida või kavandada
sammude paralleelset täitmist.
Üldiseks eesmärgiks on
suurendada ressursipaigutust tootlikuks tegevuseks ja vähendada
toetava tegevuse nõudlust tootlikuks tegevuseks vajaliku ressursi
järele. Koolitus on eelkõige organisatsiooni, mitte projekti
ülesanne, mistõttu projekti täitmisse on soovitatav kaasata
piisavalt koolitatud inimesed.
Personali
efektiivsuse tõstmisel on oluline, et see kataks vajadused ja oleks
tasakaalustatud (nagu jalgpallimeeskond). Eriline roll on seejuures
projektijuhil: korralikult juhitud projekt on isegi keskpärase
meeskonna puhul reeglina edukas, samas kui halvasti juhitud projekt
on isegi suurepärase meeskona puhul reeglina ebaedukas.
Võtmepositsioonidel olevad inimesed peavad piisavalt olema kolleegide poolt toetatud: vaid ambitsioonikatest juhtidest koosnev meeskond on meeskonnatöö seisukohalt äärmiselt riskantne.
Kogemusteta algajate ja kogemustega ekspertide kasutamisel on
tootlikkusel keskmiselt neljakordne vahe.
Personali osas võib välja
tuua järgmised põhimõtted:
- Kasuta vähem ja paremaid inimesi,
- Kohanda ülesanded inimeste võimete ja motivatsiooni järgi (tippdisaineri “edutamine” projektijuhiks võib lõppeda katastroofiga),
- Inimesi peab aitama saavutada eneseteostust,
- Vali üksteist täiendavad ja omavahel harmoneeruvad inimesed.
Eraldi võiks välja tuua
tarkvaraprojektide juhtide olulisemad omadused:
- Oskus värvata sobivaid inimesi,
- Oskus suhelda tarbijaga, oskus vältida erinevate osapoolte vahelisi ebasõbralikke suhteid,
- Otsustusvõime,
- Meeskonna kujundamise oskused, usalduse loomine, ühisseisukohtade kujundamine, saavutuse motiveerimine , ebaõnnestumiste parandamine jne,
- Oskus “müüa” kõikidele osapooltele oma seisukohti, otsuseid, prioriteete, staatuse muutust jne.
Keskkond
hõlmab kavandamise vahendeid, nõuete haldamise vahendeid, visuaalse
modelleerimise vahendeid, programmeeri mise vahendeid,
kompilaatoreid, redaktoreid, muudatuste haldamise ja
kvaliteedikindlustamise analüüsi vahendeid, testimise vahendeid,
kasutajaliideseid. Olulisim on konfiguratsiooni haldamise keskkonna
kasutamine. Eesmärgiks on käsitsitöö maksimaalne
automatiseerimine; Kõikvõimalike vahendite otstarbekas kasutamine
võib anda kokku kuni 40%, iga üksiku vahendi kasutamine aga kuni 5%
kokkuhoidu (kuigi nimetatud vahendite reklaam lubab enamasti palju
suuremat kokkuhoidu).
Kvaliteedi
parandamise
põhilisteks teedeks on:
- Olulisematele nõuetele keskendumine juba projekti elutsükli varases faasis, nõuete täielikkuse tagamine projekti hilisemates faasides,
- Projekti edenemist ja kvaliteeti mõõtvate indikaatorite ja meetrikate kasutamine,
- Integreeritud kogu elutsüklit hõlmavate keskkondade kasutamine, mis toetaks konfiguratsiooni kujundamist, muudatuste juhtimist, disainimeetodeid, dokumendiloomet ja testimise automatiseerimist,
- Visuaalse modelleerimise ja kõrgtaseme keelte kasutamine, mis toetaks arhitektuuri kujundamist, programmeerimist, korduvkasutust ja dokumenteerimist; oluline on, et informatsiooni ülekandmine järgnevatesse faasidesse oleks adekvaatne,
- Demode-põhise hindamise alusel varane ja pidev ülevaade arendatava tarkvara tasemest.
Teatud rolli võivad omada ka
töökontrollid (eriti noorte töö ülevaatus kogenud ekspertide
poolt); see on ka teatud koolitamise vormiks, halva praktika
väljajuurimise ja ühise töökultuuri kujundamise viisiks.
Üleüldine kontroll on liiga kulukas, mistõttu peaks fokuseerima
tähelepanu kriitilistele lõikudele (üldise kontrolli rakendamisel
on see pealiskaudne ning üldreeglina ei avasta olulisi sisulisi
vigu, vaid piirduvad stiili ja semantika - alaste märkustega).
50 punkti
Autor soovib selle materjali allalaadimise eest saada 50 punkti.
~ 12 lehte
Lehekülgede arv dokumendis
2008-11-26
Kuupäev, millal dokument üles laeti
114 laadimist
Kokku alla laetud
0 arvamust
Teiste kasutajate poolt lisatud kommentaarid
LyAnn
Õppematerjali autor
annaabi.ee 
Kõik kommentaarid