osa 3

Erinevates töökeskkondades on kasutusel erinevad nõuded andmesõnastiku elementide, nende
struktuuri ja parameetrite kohta. Tüüpiliselt on vaja teada sisend- ja väljund muutujate loetelu,
nende muutumispiirkonda, lubatud väärtuse muutumise kiirust (ja/või kiirendust), vajalikku
arvutamise/mõõtmise täpsust, muutuja väärtuse kehtivusintervalli, jne. Neile võivad lisanduda
sideprotokollide võimalused, krüpteerimise nõuded, nõutavad andmeedastuse kiirused
(maksimum, keskmine, minimaalne), eeldatav töötlemiskiirus jne.
Eestis antav tarkvara-alane haridus ei pööra (minu andmetel) andmesõnastikele vajalikku
tähelepanu. Kuigi paljudes tarkvaratehnika keskkondades on andmesõnastike kasutamine
kohustuslik ja nende loomine/täiendamine toimub paralleelselt muu projekti arendamisega,
oskavad laisad tarkvara-insenerid leida alati võimaluse kohustustest mööda hiilida – varem või
hiljem kannatab selle all töö tootlikkus ja tarkvaratoote kvaliteet.
Täpsem info andmesõnastike ja nendes kasutatava Backus-Nauri poolt loodud (ja teiste poolt
täiendatud) formalismi kohta on toodud andmevoo mudeleid käsitlevas kursuse osas. (veelgi
detailsem info on saadaval raamatus R. Narayan “Data Dictionary Implementation, Use and
Maintenance”, Prentice-Hall Mainframe Software series, Upper Saddle River, N.J. 1988)
3.7.1.2 Otsustamine ja kompromisside tegemine (Decision support)
Iga tarkvaraprojekti käigus on vaja valida alternatiivsete variantide vahel. Valiku aluseks olevate
otsustuste ja järelduste objektiivsusest ja põhjendatusest sõltub tihti kogu projekti õnnestumine.
Otsustamine on enamasti raskendatud olemasoleva informatsiooni mittetäielikkuse, või
mittepüsiva iseloomu tõttu. Seetõttu on loomulik üritada lõplikku valikut/otsustamist edasi lükata
täieliku info saamiseni, või nii kaua kui võimalik -- otsustamise edasilükkamisest tekkiv võimalik
kasu ei kasva siiski lineaarselt, vaid omab selget maksimumi.
On oluline, et esimese valikuvajaduse ilmnemisel (või esimese valiku tegemisel) fikseeritakse
valiku aluseks olevad kriteeriumid ja vajalikud lähteandmed kirjalikult (veelgi parem oleks valiku
kriteeriumid fikseerida kasutaja nõuete spetsifikatsioonis, kahjuks ei ole see alati võimalik).
Projekti arengu käigus võivad valiku kriteeriumid muutuda (nii kvantitatiivselt kui ka
kvalitatiivselt), on oluline et ka kõik kriteeriumite muutused oleksid kirjalikult fikseeritud.
Otsustusprotsess ise peab selgelt näitama:
- miks üks alternatiiv on parem kui teised
- kui usaldatav on saadud otsus (võrreldes peamiste alternatiividega)
- kuidas saaks otsuse usaldatavust parandada (mida oleks veel vaja arvesse
võtta).
Behforooz & Hudson (1996) soovitavad otsustamise abivahendina kasutada kompromissi
maatriksil (trade-off matrix) baseeruvat meetodit (vt. detaile nimetatud raamatust lk.151 - 153).
Behforooz ja Hudson rõhutavad, et mida kauem saab (administreerimisega seotud) otsustamist
edasi lükata (ilma edasilükkamise negatiivse mõjuta – näiteks, meeskonna moraalile, projekti
85