testin" korraldus. Kui kasutaja ja arendaja on erinevad ja toode pole vastutusrikas- võib kasutada järgmist skeemi: tellija annab tellimuse, programmeerija annab tellijale arendatud tarkvara, tellija katsetab tarkvara ja annab programmeerijale leitud vigade kirjelduse, programmeerija parandab vead ja annab üle parandatud toote. Vastutusrikas tarkvara- võib kasutada sellist skeemi: arendajapoolne testimine, rakenduse ja testimise eksperdi poolne testimine, kasutajate grupi testimine. Sobivaim- olenevalt olukorrast. 41. Millal tekib vajadus keerukamaks korralduseks? Keerukas toode- otstarbekas alustada kontrolli arenduse algetappidest ja jaotada see hallatavateks osadeks. Töökindluse poolest kriitiline toode- testimine tuleb jaotada etappideks, kasutada erimeetodeid. Organisatsiooniliselt lahutatud arendusetapid- peab olema korraldatud projekteerijate
· programmeerija annab tellijale arendatud tarkvara · tellija katsetab tarkvara ja annab programmeerijale leitud vigade kirjelduse · programmeerija parandab vead ja annab üle parandatud toote Ülaltoodud tegevusi võib korrata üks või rohkem kordi. Vastutusrikka tarkvara puhul, mida hakkab kasutama palju kasutajaid, eelmine skeem enam hästi ei toimi, sest seda peavad katsetama erinevad kasutajad. Reaalselt on kasutatud sellist skeemi: · arendus ja arendajapoolne testimine · rakendus- ja testimiseksperdi (nt toetusrühma) poolne testimine · kasutajate rühma testimine · igalt etapilt võib minna tagasi eelmistele etappidele, kui leiti vigu Kas viimasest meetodist piisab ka kriitilistes rakendustes? Osutub, et paljudes olukordades mitte. Põhjusteks, mis sunnivad kasutama keerukamat töökorraldust, võivad olla · tarkvara on süsteemi sisse ehitatud, süsteemi testimine on kallis - tekib vajadus lahutada
· Testigrupi liikmed moodustavad firmasisese tugigrupi, kes ülejäänud töötajaskonda juhendavad (eelkõige kassapidajate / raamatupidajate korral). · Seadistamisel rõhk töökiiruste ning töökindluse tagamisele reaalses olukorras. Iga komponentide komplekti (kuna suure tõenäosusega tuleb mõned allsüsteemid rakendada üheagselt) üleviimist võib käsitleda iteratsioonina. Faasile planeeritud 2 kuud. Hiljem arendajapoolne tugi. Teatud aeg peale süsteemi tegelikku töösserakendamist ideede, nõudmiste ja vigade kogumine ning analüüs tagasisideks, kogemustepagasi suurendamiseks ning potentsiaalse versioon 2 pakkumise tegemiseks. 110
annaabi.ee 
