Tarkvaraprojekti esijalgne kavandamine (0)

Tarkvaraprojekti esialgne kavandamine
Tarkvaraprojekti 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ähtu­ma, määratlemaks, mida loodav tarkvara peab võimaldama ja mida mitte. Näiteks MS Word for Windows 1.0 aren­da­mine 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 teks­titöötlus­süsteem” liiga üldine, parem oleks “Luua maailma kõige kasutajasõbralikum tekstitöötlussüsteem”, kuna annab aren­da­jatele 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 tegur
Nõ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 kaasa­mine 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õhitege­vusele jääb sel juhul liiga vähe vahendeid. Riskihaldamise edukus sõltub sellest, kuivõrd pühendu­nult 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 ebaots­tarbekas 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