osa 3
osa 3
osa 3
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
tarkvara inseneride vastutust – tarkvara inseneride vastutus on äärmuseni viidud ohutuskriitiliste<br />
reaalajasüsteemide (safety-critical real-time systems) tegemisel ja kasutamisel.<br />
Järgnevalt on loetletud mõned tüüpilised probleemid, mis tekivad kõigi küllalt suurte süsteemide<br />
tegemisel -- eriti huvitavad meid suured tarkvarasüsteemid. On loomulik, et tarkvaratehnika<br />
püüab leida meetodeid, mis vähendaksid nende sageliesinevate probleemide poolt põhjustatud<br />
riski tarkvaraprojekti õnnestumisele.<br />
Süsteemi loomise kestus (Development time problem) Süsteemi loomise kestuseks loetakse aega<br />
tulevase süsteemi esimese kontseptsiooni fikseerimise hetkest kuni esimese töötava eksemplari<br />
andmiseni lõppkasutaja kätte. Suurte süsteemide loomise käigus võib tegevuse algul aluseks<br />
võetud tehnoloogia (arvutid, tarkvara, tehnoloogilised seadmed, jne) põhjalikult muutuda. Paljude<br />
projektide alustamisel ei ole süsteemi teisi osi veel olemas (isegi mitte projektina), eksisteerivad<br />
vaid nõuded tulevase süsteemi <strong>osa</strong>dele. Taoliste projektide näideteks võiksid olla:<br />
• võimsa elementaar<strong>osa</strong>keste kiirendaja tegemine – töö alustamisel on peamiseks piiravaks lüliks<br />
hajutatud arvutisüsteemi võime erinevates arvutites töötavaid kelli piisava täpsusega<br />
sünkroniseerida, piisava kiirusega infot koguda, töödelda ja teiste arvutitega vahetada, ning<br />
kiiresti ja piisavalt hästi sünkroniseeritult juhtida hajusalt paiknevaid tehnilisi seadmeid–<br />
pärast nende küsimuste põhimõttelist lahendamist saab tõsiselt hakata projekteerima ja<br />
katsetama ka muid süsteemi komponente;<br />
• järgmise sajandi tanki projekt – milles on 15-20 erinevat kohtvõrku ja ligi 100 protsessorit,<br />
hajutatud reaalaja-andmebaas, satelliitside; projekti eesmärgiks on süsteemi maksimaalne<br />
vastupanu riketele ja kahjustustele (viability = visadus); peamiseks probleemiks on sobiva<br />
võrgu topoloogia ja tarkvara arhitektuuri väljatöötamine, mis tagaks piisava kiirusega<br />
küllaldase ning usaldatava info kättesaadavuse kõigile süsteemi <strong>osa</strong>dele võimalikult suurte<br />
riistvaraliste ja tarkvaraliste kahjustuste korral; pärast selle probleemi lahendust saab kogu<br />
süsteemi projektiga edasi minna – s.t. defineerida ka teiste tarkvaraprojekti <strong>osa</strong>de kohta<br />
täpsemad funktsionaalsed ja mittefunktsionaalsed nõuded.<br />
Süsteemi loomise käigus võib üsna sageli kaduda vajadus süsteemi kui terviku, või mõne tema<br />
<strong>osa</strong> järele. Samuti võib olukord muutuda sedavõrd, et süsteemi esialgne spetsifikatsioon kaotab<br />
oma mõtte. Ideaalne projekt näeb sellised variandid ette -- kindlates kontrollpunktides hinnatakse<br />
projekti jätkamise otstarbekust, samades punktides võidakse otsustada projekti lähtetingimusi<br />
muuta, kooskõlas värskelt tekkinud uute arusaamadega.<br />
Nimetatud probleemi mõju nõrgendamiseks kasutatavad vastuabinõud aitavad vaid <strong>osa</strong>liselt,<br />
vahel aga võivad teha asja isegi hullemaks. Efektiivsed universaalsed vastuabinõud seni (ja vist<br />
põhimõtteliselt) puuduvad, igal konkreetsel juhul sõltub edu projektijuhi ja meeskonna<br />
ettenägemisvõimest ja töökogemusest. Väga pikaajalise projektiga seotud riskide vähendamiseks<br />
kasutatakse näiteks järgmisi vastumeetmeid:<br />
• puuduva tehnoloogiaga tugevalt seotud projektotsused lükatakse ajas nii kaugele kui vähegi<br />
võimalik; selle otsuse vastu võitleb “bürokraatia traditsioon” -- enne projektile rahade<br />
eraldamist nõutakse kasutatavate seadmete ja tehnoloogiate detailset kirjeldust; seega tuleb<br />
loota ka haritud bürokraatide olemasolule;<br />
53
Change language