Tarkvara kvaliteet ja standardid

Q: Mis siia kuulub?

Vastus leiad õppematerjalist: Tarkvara kvaliteet ja standardid

Q: Mis on erinevus?

Vastus leiad õppematerjalist: Tarkvara kvaliteet ja standardid

Q: Kuidas võivad läbivaatused nurjuda?

Vastus leiad õppematerjalist: Tarkvara kvaliteet ja standardid

Q: Milline on vajalik tase?

Vastus leiad õppematerjalist: Tarkvara kvaliteet ja standardid

Q: Milline on olemasolev tase?

Vastus leiad õppematerjalist: Tarkvara kvaliteet ja standardid

Q: Mida teises järjekorras?

Vastus leiad õppematerjalist: Tarkvara kvaliteet ja standardid

Q: Milline neist on parim?

Vastus leiad õppematerjalist: Tarkvara kvaliteet ja standardid

Q: Millal tasub kasutada testimise automatiseerimise süsteeme?

Vastus leiad õppematerjalist: Tarkvara kvaliteet ja standardid

Q: Millest alustada tarkvaraprotsessi kvaliteedihalduse kavandamist?

Vastus leiad õppematerjalist: Tarkvara kvaliteet ja standardid

Merivald, Triin

Tarkvara kvaliteet ja standardid (1)

Informaatika - Tarkvara kvaliteet ja standardid

5 VÄGA HEA

Esitatud küsimused

Mis siia kuulub?
Mis on erinevus?
Kuidas võivad läbivaatused nurjuda?
Milline on vajalik tase?
Milline on olemasolev tase?
Mida teises järjekorras?
Milline neist on parim?
Millal tasub kasutada testimise automatiseerimise süsteeme?
Millest alustada tarkvaraprotsessi kvaliteedihalduse kavandamist?

Tarkvaratoode – mis siia kuulub?
Tarkvara arenduse tulem (toode, teenus) hõlmab mitmesuguseid komponente, mis kõik võivad
olla kvaliteedihalduse objektid, näiteks
 arenduse käigus hangitud infotehnoloogiavahendid: riistvara , standardtarkvara,
sideseadmed
 arenduse käigus tehtud töö: täitja arendatud tarkvara (sealhulgas lähtekood, objektkood,
täitmiskood jm); installatsioonid , kohandamised, muudatused; andmehõive
 muudatused tellija organisatsioonis, protsessides, töökorralduses...
 projektdokumentatsioon kasutamise kohta (kasutajajuhendid); objektsüsteemi kohta;
loodavate objektide kohta (programmi/testimise dokumentatsioon); installeerimise ja
seadistamise kohta; arenduse (sh testimise) kohta
 metoodika: tulemuste kasutamine; tulemuste edasiarendamine; uute arenduste tegemine
 vahendid hoolduseks, muudatusteks, arenduseks
 teadmised projekti tulemuste kasutamisest; objektsüsteemist (süsteemianalüüs või
vajalikud muudatused seadusandluses); projektist; arendusest
 õigused tööks, arendamiseks , levitamiseks
2. Näited tarkvara probleemidest tulenenud rasketest intsidentidest. Tarkvara probleemide
ulatuse ja maksumuse hinnangud

A booster(rakett) went off course during launch , resulting in the destruction of NASA Mariner 1. This was the result of the failure of a transcriber to notice an overbar in a written specification for the guidance program, resulting in the coding of an incorrect formula in its FORTRAN software. ( July 22, 1962).[1] Note that the initial reporting of the cause of this bug was incorrect.
A bug in the code controlling the Therac-25 radiation therapy machine was directly responsible for at least five patient deaths in the 1980s when it administered excessive quantities of X-rays.
An error in the payment terminal code for Bank Of Queensland rendered many devices inoperable for up to a week. The problem was determined to be an incorrect hexadecimal number conversion routine. When the device was to tick over to 2010, it skipped 6 years to 2016, causing terminals to decline customer's cards as expired.

3. Nõuded - näide nõuete (kvaliteediatribuutide) süsteemist, kahe faktori kriteeriumid
Toote nõuded spetsifitseerivad, milliseid funktsioone peab
süsteem realiseerima ( funktsionaalsed nõuded) ja kuidas neid funktsioone täidetakse
( mittefunktsionaalsed nõuded). Protsessinõuded määravad arenduse kitsendused (näiteks,
nõuded arhitektuurile, vahenditele või keskkonnale). Ärinõuded võivad lisaks sisaldada
strateegilisi, keskkonna, maksumuse ja muid piiranguid. Eri tüüpi nõuded võivad olla omavahel sõltuvuses. Enamasti tulenevad toote ja protsessi nõuded
ärinõuetest. (Arendus)protsessi nõuded võivad suures osas tuleneda toote nõuetest.
kvaliteediatribuutide puu
Süsteemi kasutatakse, muudetakse ja kantakse üle
teistele riist - ja tarkvaraplatvormidele. Kasutamisel peaks süsteem täitma vajalikke funktsioone
ning olema töökindel, efektiivne ja kasutajasõbralik
4. Funktsionaalsed ja mittefunktsionaalsed nõuded, testitavad ja mittetestitavad nõuded.
Funktsionaalsed nõuded vastavad küsimusele "Mida peab tarkvara tegema?" (näiteks, süsteem
peab võimaldama kauba tellimist). Ülaltoodud nimistus määravad funktsionaalsuse põhiliselt
sobivuse ja õigsuse atribuudid . Mõnikord pannakse funktsionaalsete nõuete alla ka ülejäänud
atribuudid funktsionaalsuse faktorist (koostalitlusvõime teiste süsteemidega; turvalisus;
funktsionaalsuse vastavus normidele).
Mittefunktsionaalsed nõuded vastavad küsimusele "Kuidas tarkvara peab vajalikke funktsioone
täitma?". Näiteks, süsteemi vastuse aeg peab jääma etteantud piiridesse (tõhusus); süsteem peab
teatud ajavahemike jooksul tõrgeteta töötama (töökindlus) jne.
Otstarbekas on püstitada testitavad nõuded, muidu ei saa nende täidetust hinnata. Funktsionaalsuse (täpsemalt, sobivuse) korral on see enamasti nii. Mittefunktsionaalsete nõuete puhul on asi keerukam . Nõue võib olla testitav , kuid ebareaalne , ebamõistlik, ebapiisavalt spetsifitseeritud jne. Näide: "süsteemi vastuse aeg peab jääma alla 3 sekundi". Kui sellised nõuded on lepingus, on see
tavaliselt ühe poole lisarisk. Eesmärkide ja nõuete hindamiseks võib kasutada ka laiemat SMART kriteeriumit ( Specific , Measurable, Agreed, Realistic and Time bound).
5. Tarkvara elutsükli mudelid ja protsessimudelid – mis on erinevus? Ülevaade
Tarkvara elutsükli mudelid iseloomustavad esmajoones arendusprotsessi,
protsessiraamistikud – kõiki protsesse. Seepärast on protsessiraamistikud tihti mahukamad
protsessimudelitest ja tarkvara elutsükli mudelitest. Selliste raamistike mahukus tuleneb eelkõige sellest, et nad hõlmavad väga mitmesuguseid protsesse, mitte ainult tarkvara arendust. Näiteid protsessidest: hankimine , tarnimine , ekspluatatsioon, hooldus , konfiguratsiooni haldus, muudatuste haldus jne. Tänapäeval on pakutud mitmeid erinevad tarkvara protsesside raamistikke ja standardeid (nt ISO/IEC 12207, CMMI, COBIT, ITIL ).
Protsesside vajadus sõltub olukorrast, näiteks ettevõtte tüübist, süsteemidest, töötajate ja
asukohtade arvust, ettevõtte arengustaadiumist jne. Liiga vähesed protsessid ei võimalda tööd
toimivalt korraldada näiteks keeruka struktuuri ja paljude kasutajate korral, liigsed protsessid
muudavad töö bürokraatlikumaks ja kahandavad loovust . Arendus võib olla vähem reguleeritud
kui muud valdkonnad, näiteks hooldus ja kasutamine. Lihtne reegel (raske rakendada): nii vähe fikseeritud protsesse kui võimalik, aga mitte vähem.
Zachmani ettevõtte arhitektuuri raamistik sisaldab nii elutsükli mudeli kui ka protsessiraamistiku elemente.
Tarkvara elutsükli mudelid hõlmavad esmajoones tarkvara arendust, mis on üks protsess
paljudest.
Kosemudeli idee pärineb tööstusest, kus muudatuste tegemine eelmise etapi
tulemitesse võib olla väga kulukas või võimatu. Ülekantuna tarkvara arendusse tähendab see, et
"puhta" kosemudeli puhul peaksid eelmised etapid olema lõpetatud enne, kui minna täitma
järgmist etappi - tagasipöördumist eelmisse etappi ei ole. Võrreldes hoopis ilma struktuurita
programmeerimisega (ülesanne -> programm) aitab kosemudel süsteemi paremini kavandada,
võimaldab jagada tööd etappideks , parandab dokumentatsiooni.
Samal ajal on süsteemi nõudeid raske täpselt ette kavandada, kosemudel viib tihti liiga jäiga ja
bürokraatliku arendustsüklini. Seepärast ei kasutata kosemudelit selle puhtal kujul tänapäeval
eriti tihti. Samas selle mudeli ideed ja modifikatsioonid
(näiteks, et arendus tuleks jagada etappideks; et sisuliselt võib olla vaja teha analüüsi, disaini ja
hindamise tegevusi, kuigi võib-olla teisiti organiseeritult) on kasutusel mitmetes teistes elutsükli
mudelites.
V- mudelis kulgevad arenduse ja kontrolli tegevused sümmeetriliselt - igale arendustegevusele vastab kontrolli tegevus. Valides erinevaid arenduse ja kontrolli tegevusi saame erinevad V-mudelid.
Spiraalmudel: Esimene põhietapp on eesmärkide määratlemine ja planeerimine . Teisel etapil toimub valikute hindamine ja riskianalüüs. Kolmas etapp on tootearendus, mis sisaldab disaini, kodeerimist,
testimist ja integreerimist. Neljandal etapil saadakse kasutaja hinnang ning minnakse üle
järgmiste etappide planeerimisele . Spiraalmudeli põhjal toimuvas arenduses luuakse tavaliselt
mitu tarkvaraversiooni. Esimene on prototüüp, järgmised võivad olla juba lõplikud, sõltuvalt
kasutaja hinnangust.
Detailne spiraalmudel koos kõigi alametappidega on liiga kulukas väikeste projektide jaoks,
kuid selle üldist loogikat saab rakendada ka väikesemahulistes projektides ning seda on
rakendatud ka erinevate hilisemate metoodikate väljatöötamisel.
XP ( Extreme Programming) üheks eesmärgiks on suurem paindlikkus muutuvate nõuete tingimustes.
Testipõhisel arendusel (test driven development ) luuakse testid enne realiseerimist kliendi kasutuslugude põhjal. Testide hulka kuuluvad ühiktestid (programmeerijalt, kohe enne realiseerimist) ja vastuvõtmise testid (Tellijalt, funktsionaalsed).
Scrum is an iterative and incremental agile software development framework for managing software projects and product or application development. Scrum focuses on project management institutions where it is difficult to plan ahead.
RUP
6. Tarkvara kvaliteet
Töökindluse tõstmise üks võimalusi on kvaliteedihaldus. Väga lühidalt on kvaliteet toote
vastavus nõuetele. Keerukate toodete puhul tuleb vastavuse hindamisel arvesse võtta ka toote
loomise protsessi. Seega seob kvaliteet toote, nõuded tootele ja tootmise protsessi.
Standard võtab arvesse kasutus-, välis-, sise- ja protsessi kvaliteeti. Elutsükli protsesside
kvaliteet soodustab toote kvaliteedi (sise- ja väliskvaliteedi) parandamist, toote kvaliteet aga
soodustab kasutuskvaliteedi tõstmist.
Kasutuskvaliteedi atribuudid on tõhusus, tööviljakus, ohutus ja rahuldus .
7. Läbivaatus/inspektsioon, selle plussid, miinused, eeltingimused, osavõtjad, korraldus
Läbivaatus on suunatud toote kvaliteedi parandamisele, selle tulemused ei tohiks mõjutada
töötajate palka, heaolu, ametikõrgendust vms. Läbivaatuse idee on toote ( spetsifikatsioon ,
projekt, dokumentatsioon,...) ühisarutelu kindlate reeglite järgi.
Läbivaatusel on palju soodsaid külgi:

vigu saab leida varastel arenduse etappidel. Mida varasemal etapil viga on tehtud, seda

suurema maksumusega on selle negatiivsed tagajärjed, kui viga jääb avastamata. Kuna
vea leidmine läbivaatuse abil on suhteliselt odav, siis kokkuvõttes on läbivaatuse
efektiivsus varastel etappidel suur. See on ka läbivaatuse oluline eelis testimise ees
(miks?)
Läbivaatuse eelised:

ta on parim viis vigade vähendamiseks (suurusjärk)
kontaktid rühmas paranevad
tootlikkus ja kvaliteet paranevad
ühe osavõtja lahkumisel saab teda asendada

Läbivaatuse probleeme:

rühma liikmed võivad olla erinevatest osakondadest
rühma liikmed võivad olla erinevad: kõrge IQ-ga, kannatamatud, konservatiivsed, vähe

huvitatud "reaalsest maailmast", eelistavad eraldatust jne

kellelegi ei meeldi, kui teda kritiseeritakse

Kuidas võivad läbivaatused nurjuda?

Pole arusaamist , mida on vaja läbi vaadata, läbivaatused korraldatakse arenduse

lõpupoole (efekt on väiksem)

Puuduvad ühised sihid, kvaliteedikriteeriumid , arusaamine läbivaatuse protsessist
Läbivaatuse sisendid ja väljundid on kontrollimata
Leitud vigade parandamist ei jälgita
Leitakse vaid antud toote / dokumendi probleeme, ei püüta leida vigade algpõhjust (kogu

protsessi vigu)

Keskendutakse inimeste, mitte toote probleemidele
Keskendutakse vaid tootele, ignoreeritakse inimeste probleeme

Eeltingimused:

kõigil rühma liikmetel peaks olema ettekujutus sellest, mida neilt oodatakse
koostööõhkkond
materjalid on ette valmistatud ja kätte jagatud
osavõtjad on nendega tutvunud, nt igaühel on üks positiivne ja üks negatiivne kommentaar

8. Riskipõhine, ekspertteadmiste põhine, uuriv , suitsu- jm testimine
Enne kui hakata spetsifikatsiooni- või programmipõhiselt süstemaatiliselt testima, võib olla
otstarbekas läbi viia esialgne testimine, mis selgitab, kas on mõtet põhjalikumaid meetodeid
rakendada.
Riskipõhise testimise idee on testida esmalt tootega seotud kriitilisi riske. Selleks on vaja
identifitseerida riskid , omistada neile prioriteedid , testida kõige prioriteetsemaid riske,
informeerida teisi osapooli tulemustest ning võtta vastu otsused edasise kohta.
Riski prioriteeti saab iseloomustada mõju ja sageduse (tõenäosuse) kombinatsiooniga.
Riske võib otsida näiteks järgnevast (osa neist ei pruugi olla testitavad).

Tellijale või kasutajale kõige suuremat väärtust andvad ja sagedamini kasutatavad

süsteemi funktsioonid (risk on siis, et need ei toimi).

Mittefunktsionaalsete nõuetega seotud riskid: töökindlus, efektiivsus, turve, kasutatavus

jne.

Kõige suuremad ohud, nt valesti teostatud makse, katla plahvatus jne (risk on siis, et need

ohud realiseeruvad). Ohud ei pruugi olla seotud põhifunktsionaalsusega.

Tehnilised omadused, nt süsteemi uudsus ja keerukus , suured andmemahud, osapoolte

arvukus jne.

Arendusprotsessiga seotud riskid, nt kiired tähtajad, tellija või täitja ressursside vähesus

jne.
Riskipõhise testimise tulemuste põhjal võib võtta vastu otsused riskide vähendamiseks,
aktsepteerimiseks või jagamiseks, tegevuse lõpetamiseks jne.
Riskipõhine testimine on osa laiemast organisatsiooni IT riskihaldusest. IT riskihaldus on
infotehnoloogilise süsteemi ressursse mõjutada võivate määramatute sündmuste tuvastuse, ohje
ja välistamise või minimeerimise protsess tervikuna .
Riskihalduse põhitegevused:

Riskianalüüs (riskide tuvastamine , hindamine ja turvameetmeid vajavate alade tuvastus ).

Milline on vajalik tase? Milline on olemasolev tase?

Riskihalduse strateegia väljatöötamine. Kuidas katta vahe olemasoleva ja vajaliku taseme

vahel?

Riskide minimeerimine või välistamine. Meetmete rakendamine, et jõuda vajaliku

tasemeni. "Riskihalduse 4 T": treat, transfer , tolerate, terminate.
Ekspertteadmiste põhine testimine. Kogenud arendaja või testija oskab tõenäolisi vea kohti ette aimata. Tõenäoliste vigade leidmine võib sõltuda mitut sorti eelteadmistest, milleks on

üldised teadmised
teadmised konkreetse rakendusvaldkonna kohta
teadmised riist- või tarkvarakeskkonna (näiteks konkreetse programmeerimiskeele) kohta
teadmised arendusmetoodika kohta
teadmised konkreetse arendaja või tellija kohta jne

Uuriv testimine (exploratory testing) on mitteformaalne tarkvara testimise tehnika, mille puhul
testija hindab testide kavandamist nende täitmise käigus ning kasutab saadud informatsiooni uute
ja paremate testide projekteerimiseks.
Suitsutestimisel ( smoke testing) täidetakse alamhulk kõigist testidest selgitamaks, kas põhilised
funktsioonid töötavad. Nimetus tuleneb elektroonikatööstusest (seadme esmane sisselülitamine).
9. Funktsionaalne testimine, ekvivalentsiklasside analüüs, piirolukorrad, otsustustabelid,
veaotsing, andmepõhine testimine. Antud nõuded, pakkuda testid
Spetsifikatsiooni põhise testimise puhul vaatame programmi kui musta kasti, sest me ei tea tema
siseehitust, teame vaid sisendeid ja väljundeid (spetsifikatsiooni). Erinevus programmipõhise
testimisega ongi selles, mille põhjal leitakse testide sisendid (spetsifikatsioon või programmi
tekst); väljundid tekitatakse mõlemal juhul spetsifikatsiooni alusel.
Spetsifikatsiooni põhisest testimisest vaatame ekvivalentsiklassidel, piirjuhtudel,
otsustustabelitel ja kasutusjuhtudel (kasutusmallidel) põhinevaid meetodeid. Kõik need
meetodid tuginevad vähemalt kahel lihtsustusel.

Kogu sisendite ala jaotatakse klassideks (ühte klassi võib kuuluda vaid üks väärtus, nt

piirjuhtude puhul), mille kohta eeldatakse, et süsteem käitub kõigi samasse klassi
kuuluvate andmete testimisel ühtemoodi. See lihtsustus võimaldab lõpmatu arvu sisendite
asemel vaadelda lõplikku hulka klasse.

Testimisel püütakse katta kõik klassid. Kuna kõigi klasside kombineerimine viib ikkagi

liiga suure arvu testideni, siis rakendatakse teist lihtsustust: püütakse klasse testidesse
panna nii, et testide arv oleks minimaalne.
Ekvivalentsiklasside analüüsi idee on selles, et sisendandmed jaotuvad töötluse suhtes enamasti
rühmadesse, nii et ühes rühmas asuvaid andmeid töödeldakse ühtemoodi.
On leitud, et vigu esineb palju ekvivalentsiklasside piiridel, seega tasub teha piirolukordade
teste .
Leitakse, et funktsionaalne testimine on hinnaefektiivsem kui programmipõhine (vea leidmise
maksumus on väiksem). Funktsionaalsetest meetoditest on omakorda efektiivseim piirjuhtude
meetod, kuigi sellest enamasti ei piisa
Kokkuvõte funktsionaalsest testimisest ekvivalentsiklasside ja piirjuhtude põhjal.

Idee: süstemaatiline testimine sisendi/väljundi (spetsifikatsiooni) põhjal
Eeltingimused: vajadus; spetsifikatsioon on mingil kujul olemas; selle analüüs on teostatav
Eelised: kasutatav funktsionaalsus on süstemaatiliselt testitud; kasutajale arusaadavam

kui programmi teksti põhine testimine; õigel arendamisel koostatakse testid juba
spetsifikatsiooni koostamise ajal, mis võimaldab ühtlasi testida spetsifikatsiooni;
hinnaefektiivsem kui programmipõhine testimine

Puudused: spetsifikatsiooni pole alati olemas. Ei pruugi avastada funktsionaalsusega

mitte seotud koodi. Kui ekvivalentsiklassid on sõltuvuses, võib testimine olla mahukas

Tulemused: testikomplekt, mis katab funktsionaalsuse
Suhe teistesse: võib kasutada iseseisvalt või koos teiste meetoditega
Hinnang: hea
Vahendid sõltuvad spetsifikatsiooni formalismidest. Kuna need pole unifitseeritud, on

selle meetodi jaoks vähe üldlevinud testigeneraatoreid.
Kui sisendid on omavahelises sõltuvuses, siis võib olla kasulik otsustustabelite põhine testimine.
Otsustustabel sisaldab eeltingimusi, tegevusi ja reegleid.
Staatiliste meetodite jaotises toodud küsimustikud võivad olla näide programmeerimiskeeltele orienteeritud veaotsingu metoodikast. Veaotsing on väga efektiivne vahend, mida võib kasutada süsteemselt või intuitiivselt . Esimesel juhul on ees küsimustikud kindla valdkonna kohta, mida süstemaatiliselt läbi vaadatakse. Intuitiivset laadi veaotsingu juures jääb alles mittesüsteemsete meetodite puudus - testimine kipub olema juhuslikku laadi; eeliseks on tugeva eksperdi puhul head testid ja aja kokkuhoid . Selle meetodi eeldus on kas eksperdi või abivahendite (nt küsimustikkude) olemasolu.
Andmepõhine testimine. Ekvivalentsiklasside, piirjuhtude ja veaotsingu ideid saab kasutada ka programmipõhisel testimisel. Sel juhul tekitatakse sisendandmed programmi tekstis antud andmestruktuuride alusel, eristades siingi ekvivalentsiklasse ja piirolukordi. Erinevus funktsionaalsest testimisest on selles, et nüüd võivad nt piirolukorrad tekkida programmis või arenduskeskkonnas antud kitsendustest, nagu massiivi lubatud pikkus, reaalarvu võimalik väärtus vms. Väljundid võetakse, nagu ikka, ülesande püstitusest.
Lisatud vead. Meetodi ülesanne on prognoosida süsteemi jäänud vigu. Selleks lisab sõltumatu isik
või rühm süsteemile juhuslikke, kuid mitte süntaktilisi vigu. Testimise käigus avastatakse
nii lisatud kui ka tegelikke vigu. Eeldades, et vigade avastamise protsent on mõlemal
juhul sama (kehtib ainult teatud tingimustel), saab prognoosida vigade arvu, mis jäid
süsteemi peale testimist

Eeltingimused: vajadus; on olemas programmi tekst, sõltumatu rühm/isik, programmi

teksti analüüsi ja muutmise võimalused

Eelised: vigade arvu prognoos

10. Testimine programmi teksti põhjal, adekvaatsuse (katvuse) kriteeriumid, nende võimsuse
suhe. Antud programm, pakkuda testid.
Kokkuvõte lauseadekvaatsuse kriteeriumist

Idee: kõik programmi osad on töötanud
Eeltingimused: programmi tekst on olemas, selle analüüs
Eelised: programmi on süstemaatiliselt katsetatud. Vähe teste. Selge idee
Puudused: mitte eriti tugev kriteerium . Ei anna andmete teste. Ei leia puuduvaid harusid.

Programmi teksti pole alati olemas. Mitte alati saavutatav
Tulemused: testikomplekt, mis katab programmi
Suhe teistesse: kasutada koos teiste meetoditega
Vahendid: on olemas vahendid, mis aitavad leida lauseadekvaatset testikomplekti

Lauseadekvaatsuse puhul läbitakse kõik laused, kuid harud, milles lauseid pole, jäetakse
läbimata. Haruadekvaatsuse nõue eeldab ka tühjade harude läbimist, seega on ta täielikum,
Lauseadekvaatsus ≤ Haruadekvaatsus. Haruadekvaatsust saab illustreerida programmi graafil .
Sellel vastab igale hargnemisele graafi tipp, millest väljub rohkem kui üks haru. Üksteisele
järgnevad täidetavad hargnemiseta laused võib ühendada üheks tipuks. Haruadekvaatsuse nõuet
võib sõnastada järgmiselt: testimise käigus peavad programmi graafi kõik kaared olema läbitud.
Järgneval joonisel on kujutatud lihtne programm ja sellele vastav graaf. Graafis on kolm esimest
lauset ühendatud üheks tipuks. Selle programmi lauseadekvaatseks testimiseks piisab ühest
testist, mis läbib lause 5 (tooge testi näide). Samas haruadekvaatseks testimiseks tuleb teha
vähemalt kaks testi - eelmisele lisaks ka test, mis läbib tühja else -haru. Kui selles harus oleks
mingi lause, siis oleks nii lause- kui ka haruadekvaatseks testimiseks vaja teha vähemalt kaks
testi.
Programmi keerukus (kõik mõõdud on samaväärsed) V(G)=
= programmi graafi tsüklomaatiline keerukus (cyclomatic complexity) V(G)
= graafi regioonide arv
= E-N+2 (E-kaared, N- tipud )
= P+1 (P-predikaadid)
Kasutamine:

V(G) annab haruadekvaatsete testide soovitatava arvu
tekib keerukuse ja arendusaja hinnang
keerukust saab hinnata juba projekti staadiumis , s.t enne programmi tegelikku koostamist
saab kasutada arenduses oleva mooduli hindamiskriteeriumina, ühe mooduli V(G) mõõt

peaks olema ≤ 10
Kui If-lause tingimus on loogiline avaldis , siis tekivad selle avaldise läbimisel sisuliselt
programmi harud, kuigi näiliselt selliseid harusid ei ole. Näiteks võidakse disjunktsiooni puhul
hinnata tingimus tõeseks juba esimese komponendi tõesuse korral; järgmisi komponente siis
enam ei hinnata ega testita. Neid harusid saab programmi graafis kujutada. Järgmine
haruadekvaatsusest tugevam nõue ongi elementaartingimuste adekvaatsus - ka loogilise
avaldise harud peavad olema testide käigus läbitud. Ka see on üsna mõistlik kriteerium ja
praktikas kasutusel.
Viimase kriteeriumina sellest klassist vaatame nõuet, et programmi testimisel peavad
kõikvõimalikud teed programmi graafis olema läbitud. Idee on selge ja kena, kuid tsükleid
sisaldavate reaalsete programmide puhul on vajalike testide maht enamasti väga suur ja see ei
luba teeadekvaatsuse kriteeriumit selliste programmide testimisel kasutada. Ilma tsükliteta
programmi puhul võib see olla hea kriteerium.
11. Mittefunktsionaalsete nõuete testimine
Mittefunktsionaalsete nõuete puhul on enamasti raskem tagada nende testitavust. Lisaks on neid tihti ka raskem testida, isegi kui nõuded ise on testitavad.
Kui nõue on testitavalt sõnastatud, viitab ta ise sellele, kuidas testimist põhimõtteliselt läbi viia.
Näiteks nõuet "Süsteemi töö võib kuu aja pikkuses ekspluatatsioonis keskkonnas XYZ,
kasutusaktiivsuse UVW ja kasutuslaadi NML korral olla häiritud maksimaalselt ühe tunni
jooksul" saaks testida nii, et installime süsteemi keskkonda XYZ, kasutame seda
kasutusaktiivsusega UVW ja kasutuslaadiga NML kuu aega ning mõõdame, kui kaua aega oli
süsteemi töö häiritud. Selliseid teste tuleks teha korduvalt, et saada statistiliselt põhjendatud
hinnanguid.
Mõnikord on sellised testid tehtavad pigem simulatsioonivahendite abil või rakendades staatilisi (süsteemi läbivaatuse jne) meetodeid.
Mittefunktsionaalsete nõuete testimine võib nõuda mahukaid eksperimente.
12. Testimise ja kontrollimeetodite efektiivsuse võrdlus ja soovitused kasutamiseks (mida
kasutada kõigepealt , mida teises järjekorras?)
Vaadeldud meetodite hinnaefektiivsuse järjestus (selles mõttes, et vea leidmise maksumus on
väikseim; alates efektiivseimast) on üldjuhul järgmine: programmeerija poolne esialgne
testimine, suitsutestimine, testimine kasutaja andmetega , riskipõhine testimine, uuriv testimine,
ekspertteadmiste põhine testimine, piirjuhud, ekvivalentsiklassid, programmipõhine testimine,
muud meetodid. Ühe meetodi hinnaefektiivsus ei tähenda, et teisi meetodeid ei tuleks kasutada.
Meetod võib olla efektiivne ja leida esialgu kiiresti vigu, kuid kõiki vigu ei leia ükski meetod.
Seega võib vastavalt programmi kriitilisuse astmele olla vaja kasutada ka kallimaid meetodeid.
Vt. Punkti 14 lõpus olevat tabelit.
13. Saavutatav töökindluse tase seniste meetoditega, selle oluline suurendamine .
Verifitseerimine .
Töökindluse parendamise vahendeid on palju. Mõningaid neist vaadatakse allpool: Nversiooniline programmeerimine (N-version programming); veapuu analüüs; formaalsed meetodid, sealhulgas programmide tõestamine; teatud kvaliteediomadustele, nt töökindlusele või turvalisusele orienteeritud arenduse ja halduse meetodid (sh Cleanroom development, Common Criteria, ka ISKE mõned moodulid).
N-versioonilise programmeerimise (N-version programming) idee on, et paralleelselt
arendatakse ja kasutatakse mitut programmi versiooni. Kasutamisel võrreldakse tulemusi, enam
levinud vastused loetakse õigeks (hääletamine).
Meetod, millelt palju loodeti ja mis õigustab ennast hästi riistvara puhul, on kasutatav, kuid ei
anna sama häid tulemusi tarkvara korral. Üks põhjus on selles, et inimlik loogika jälgib tihti
samu radu ja paralleelsetes arendustes tehakse ühesuguseid vigu.
Veapuu analüüsi puhul ehitatakse ja/või veapuu. Alustatakse suurest veast, mida tahetakse
vältida, vaadatakse selle vea eeltingimusi, eeltingimuste eeltingimusi ja nii edasi. Kui iga puu
lehega seostada eeltingimuse tõenäosuse hinnang, saab lehtedest puu tipu suunas liikudes kätte
analüüsitava suure vea tõenäosuse.
Meetod toimib hästi tehniliste süsteemide puhul. Süsteemi või programmi veapuu analüüs
võimaldab lokaliseerida ja analüüsida süsteemi kriitilisi komponente, analüüsida kriitiliste
komponentide vahelisi seoseid ning paremini kvantifitseerida riske.
Algoritmide või programmide tõestamist võib käsitleda ühe staatilise meetodina. Lühikokkuvõte
tõestamisest:

Siht. Näidata, et programm vastab spetsifikatsioonile
Idee. Luuakse loogiline arvutus (valemid, aksioomid , tuletusreeglid, tõestused,

teoreemid). Selle arvutuse terminites kujutatakse spetsifikatsiooni (sisendid ja väljundid)
ning programmi. Tõestatakse, et lähtudes antud sisenditest ja kasutades antud programmi
jõutakse nõutud väljunditeni (tavaliselt ka, et programm lõpetab töö)

Eeltingimused. Spetsifikatsioon, programm, loogikavahendid, vajadus, ressursid ,

soovitavalt toetav tarkvara

Eelised. Suurem töökindlus, formaalne korrektsus , ainuke viis tsüklite korrektsuse

formaalseks põhjendamiseks

Puudused. Töömahukas, sobib halvasti suurte süsteemide jaoks, ei välista

spetsifikatsiooni vigu (samuti arenduskeskkonna ja muid vigu), tsükleid on tehniliselt
raske tõestada

Tulemused. Programm tõestatakse spetsifikatsiooni suhtes
Suhe teistesse. Kasutatakse koos teiste meetoditega
Hinnang. Kasutada vajadusel. Vähekriitiliste süsteemide puhul pole otstarbekas
Vahendid. On tehtud tõestamist toetavat tarkvara, kuid see pole levinud

Üks komplekssetest metoodikatest, mis rakendab eelpooltoodud meetodeid, on tarkvaraarendus
puhtas /kontrollitud keskkonnas (Cleanroom software engineering).
Eesmärk: kõrge kvaliteediga kontrollitud töökindlusega tarkvara arendus (sõna cleanroom tuleb
elektroonikatööstusest, kus kasutatakse füüsiliselt väga puhast keskkonda, et vältida vigaseid
detaile). Rõhk on vigade vältimisel ja sertifitseeritud töökindlusel.
14. Tarkvara kontrolli korralduse lihtsamaid skeeme. Milline neist on parim?
Kontrolli korraldus nagu ka kasutatavad meetodid sõltuvad nõuetest arendatavale süsteemile,
firma üldisest töökorraldusest, firma ambitsioonidest, näiteks soovist saada uusi tellimusi jne.
Järgnevalt mõni näide.
Kui kasutaja ja arendaja on sama isik (võib olla firmas erinevates rollides) ja toode pole
vastutusrikas , toimib “ise teen, ise testin” korraldus.
Kui kasutaja ja arendaja on küll erinevad (seepärast eelmine skeem enam ei toimi), kuid
arendatavale süsteemile ei esitata suuremaid nõudmisi ja ka firma töös pole korraldusele erilist
tähelepanu pööratud, siis võib toimida tellija (tellija esindaja) ja programmeerija vahel järgmine
suhtlus:

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

Ü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

tarkvara ja süsteemi test

keerukas toode - on otstarbekas alustada kontrolli arenduse algetappidest ja jaotada see

hallatavateks osadeks

kriitilise töökindlusega toode - testimine tuleb jaotada etappideks, kasutada erimeetodeid
organisatsiooniliselt lahutatud arendusetapid - sel juhul peab näiteks olema korraldatud

analüüsijate, projekteerijate ja programmeerijate koostöö

organisatsiooniliselt keerukas kasutaja - nõuab erinevate kasutajarühmade koostööd
mitmeetapiline mahukas testimine, mis vaheldub arendustegevustega - nõuab vigade ja

nende paranduste jälgimist ning regressioontestimist (kas vanad testid töötavad peale
parandusi?)

ja nii edasi

15. XP, V-mudel, arendusprotsessi integreeritud kontroll, TPI mudel
Nüüdisaegses süsteemiarendusprotsessis alustatakse kontrolliga võimalikult varakult. Mida
varem vead leitakse, seda odavam on neid parandada. Seepärast projekteeritakse iga
arendusetapi käigus ka testid. Lihtsustatult võib öelda, et arendusetappidele vastavad eri tüüpi
testid, tekib nn tarkvara elutsükli V-mudel. Kuna elutsüklid erinevad, erinevad ka V-mudelid.
Üks levinum on järgmine:

süsteemi üldprojektile (sealhulgas tarkvara) vastab süsteemitestimine
tarkvara nõudmiste spetsifikatsioonile vastab valideerimistestimine
tarkvara realisatsiooniprojektile vastab integratsioonitestimine
tarkvara kodeerimisele vastab mooduli testimine

XP (Extreme Programming) üheks eesmärgiks on suurem paindlikkus muutuvate nõuete
tingimustes. XP ja testimise vahekorda võib lühidalt iseloomustada järgmiselt:

Põhimõtted: Tellija-orienteeritus, tiimitöö, V-mudel (testimine paaris arendusega),

prototüüpimine, lihtsuse püüd

Testipõhine arendus (test driven development): testid luuakse enne realiseerimist kliendi

lugude (stories) põhjal: ühiku testid (programmeerijalt, kohe enne realiseerimist) ja
vastuvõtmise testid (Tellijalt, funktsionaalsed)

Läbivaatuste asemel koostöö

TPI(Test Process Improvement) mudeli eesmärk on analüüsida testimise olemasolevat protsessi ja näidata selle tugevaid ning nõrku külgi. Seda võib rakendada tarkvarale , aga ka laiemalt infotehnoloogiasüsteemidele.
16. Testimise etapid: ühiku-/mooduli-, integratsiooni-, valideerimise- ja süsteemitestid.
Mooduli tasemel testimiseks on kasutatavad programmipõhised meetodid, tõestamine, mitmed
testimise automatiseerimise vahendid jne. Seejuures on kasulik jälgida testimise
hinnaefektiivsust.
On leitud, et suureneva maksumuse järjekorras võib meetodid reastada järgmiselt:

arendaja poolne esmane testimine (saab teha kiirelt arenduse käigus, on mitmete

arendusmetoodikate komponent )

suitsutestimine (väga kiire esmane testimine)
riskipõhine testimine (katsetab kõige kriitilisemaid omadusi)
uuriv testimine
testimine kasutaja andmetega (peavad kindlasti töötama), selleks võib kasutada ka normaalse töö ekvivalentsiklasside teste
läbivaatused (avastavad vigu vara)
vea otsing (kui testija on ekspert)
piirjuhud (vigade kuhjumise kohad)
ekvivalentsiklassid (sealhulgas veaolukorrad)
programmi põhjal testimine
lisatud vead
tõestamine

Integratsioonitestimine. Kui mooduli taseme testid töötavad, tuleb moodulid kokku panna ja testida. Selleks on mitu meetodit:

“pane kõik kokku ja testi” - võib töötada lihtsate süsteemide korral; keerukate puhul on

vigu raske lokaliseerida

alt üles integreerimistestid – kõigepealt luuakse alumise taseme moodulid, nendest

lähtudes liigutakse ülataseme moodulite suunas

ülalt alla integreerimistestid – kõigepealt luuakse ülataseme moodulid, nendest lähtudes

liigutakse alumise taseme moodulite suunas

segameetod ("võileib") – eelmise kahe kombinatsioon

Puuduvate komponentide asendamiseks kasutatakse sellisel testimisel komponendi reaalset
käitumist imiteerivaid objekte ( mock objects: draiverid , lühised), milles on realiseeritud vaid teatud komponendi omadused.
Eelkirjeldatud testimise etapid lähtuvad tihti projektist (nt tarkvara spetsifikatsioonist, disainist )
ja püüavad vastata küsimusele "Kas ehitasime tarkvara õigesti?" (verifitseerimistest,
verifitseerimine). Projekt võib aga olla vigane . Valiidsustestimine vastab küsimusele: ”Kas
ehitasime õige tarkvara?” - tarkvara katsetatakse selle vastavuse suhtes tarkvara lähtenõuetele.
Üldjuhul kuulub tarkvara süsteemi koosseisu. Spetsifitseeritud nõuded tarkvarale võivad olla
vigased. Seega ei anna ka tarkvara valiidsustestid õigsuse garantiid, vaid testida tuleb süsteemi
tervikuna lähtudes süsteemi nõuetest. Süsteemi nõuded spetsifitseeritakse enamasti juba
süsteemi, mitte tarkvara mõistetes (nt sõiduki töökindlus teatud kiiruste puhul).
Süsteemitestide hulka kuuluvad peale tavalise töörežiimi testide tihti ka jõudlus-, taluvus -,
taastumis-, turbe- ja muud testid.
Jõudlustestid testivad maksimumkoormusi, mida süsteem peab taluma .
Taluvustestides katsetatakse süsteemi käitumist üle normaalse ulatuva koormuse korral. Süsteem
peab ära hoidma suured õnnetused. Lubatud on mõne funktsiooni või kasutaja blokeerimine .
Taastumistestid näitavad, kuidas süsteemi töö taastub peale katkestusi (nt katkestused peale
taluvusteste, voolukatkestust, mõne seadme riket jne).
Turbetestid näitavad, kuidas süsteem on kaitstud hooletuste ja rünnete vastu.
17. Testimise automatiseerimine, eeltingimused, eelised, puudused, näited.
Eelised:

Võib ära hoida suure hulga mehaanilist pidevalt korduvat käsitööd

Mõnikord reklaamitakse testimise automatiseerimise vahendeid kui kiiresti tasuvaid ja lihtsalt
rakendatavaid. Tegelikkus pole siiski nii lihtne. Testimise (laiemalt, tarkvara kontrolli)
automatiseerimine nõuab lisaressursse järgnevaks:

vahendite hange või arendus (mõnikord üsna kulukas)
vahendite alane koolitus (vahendid võivad olla keerukad)
võib olla vajalik arendustegevuse ümberkorraldus, näiteks arendajate ja testijate suhtlemise osas (sageli kaugemas perspektiivis kasulik tegevus)
testide kogumite loomine iga testitava rakenduse jaoks, mis nõuab testide dokumenteerimist (kui korduvtestimist ei tehta , pole sellel mõtet)
testide täitmine
testide kogumi uuendamine, kui testitav toode muutub (võib olla üsna töömahukas)
testide ülekanne, kui muutub arendusplatvorm
muud ressursid, näiteks testide jagamiseks eri arendusgruppide vahel

testimise vahendite eelised ja puudused. Eelisteks on, et need vahendid
võimaldavad kokku hoida hulga käsitööd. Puudused - nad võivad kaasa tuua palju lisatööd, eriti
muutuva tarkvara või selle keskkonna puhul.
18. Millal tasub kasutada testimise automatiseerimise süsteeme? Oskus kasutada vähemalt kahte testimise automatiseerimise vahendit.
Regressioonitestimisel (Selenium, jUnit)
19. Kvaliteet, standard, tarkvara, kvaliteedihalduse ja arenduse seos
Kvaliteet on toote, teenuse või protsessi omaduste kogum, mis rahuldab määratletud või
eeldatavaid vajadusi. Kvaliteeti saab juhtida, kui vajadused on määratletud (on olemas nõuded;
siis on kvaliteet vastavus nõuetele).
Kvaliteedipoliitika - organisatsiooni tippjuhtkonna ametlikult esitatud kvaliteedialased
üldeesmärgid ja juhtnöörid.
Kvaliteedihaldus - üldise juhtimisfunktsiooni osa, mis määrab kindlaks ja rakendab
kvaliteedipoliitikat.
Kvaliteedisüsteem - organisatsiooniline struktuur, vastutus, protseduurid ja vahendid kvaliteedi
juhtimiseks .
20. Verifitseerimine ja valideerimine , protsessi ja toote kvaliteedihaldus, arendus- ja
kvaliteediohje protsessid - võrdlus ja standardid .
Valideerimine - tegevus, mis püüab näidata, et tehtud on seda, mis vaja.
Verifitseerimine - tegevus, mis püüab näidata, et järgmise etapi tulemus vastab eelnenud
etapi määratlusele.
21. Kvaliteedihalduse käsitlusi, teese, süsteeme ja auhindu, ISO 9000 seeria
Kvaliteedi hindamiseks on loodud mitmesuguseid süsteeme. Selliste süsteemide alla võib
paigutada ka kvaliteedi konkursid ja auhinnad, näiteks Euroopas EFQM (The European Quality
Award ), Eestis Eesti juhtimiskvaliteedi auhinna ja USA-s Malcolm Baldridge auhinna (The
Malcolm Baldridge National Award for Quality).
Philip B. Crosby on sõnastanud kolm populaarset teesi.

Tee kohe õigesti (do it right first time)
Ei ühtegi vigast toodet ( zero defects)
Kvaliteet on tasuta (quality is free)

ISO 9000 seeria: võimalused

Protsesside parendamine ettevõttes
Süstemaatiline (IT alane) kvaliteedihaldus
Sertifikaadi taotlemine ja ettevõtte taseme teadvustamine avalikkusele
Kasulik kui orienteerutakse ekspordile (EL, aga ka mujale)

22. Mida peaks süsteemi arendaja (tellija, kasutaja, hooldaja, tarnija, firmajuht) teadma
kvaliteedist ja standarditest?

süsteemiarendajatele, laiemalt süsteemse töö täitjale, et luua paremat toodet, saavutada

tellija rahulolu

tellijale, ostjale, et olla kursis tarkvarale esitatavate nõuetega, osata paremini koostada

pakkumiskutset ning valida toodet, jälgida arendusprotsessi ja hinnata tulemust

kasutajale, et osata küsida ostetava tarkvara omadusi ja teada, mida võib tarkvaratootelt

oodata
23. Millest alustada tarkvaraprotsessi kvaliteedihalduse kavandamist?
Kõigepealt tuleb lähtudes ettevõtte strateegiast planeerida kvaliteedihalduse eesmärgid (näiteks,
kas soovitakse ainult töökorralduse parendamist või lisaks sellele ka kvaliteedisertifikaati) ja
kvaliteedipoliitika.
Vastavalt eesmärkidele valitakse kvaliteedihalduse meetod.
Kvaliteedihaldus - esimesed sammud ettevõttes
1. Kindlustage juhtkonna tugi
2. Lähtudes ettevõtte strateegiast planeerige kvaliteedihalduse eesmärgid ja kvaliteedipoliitika
3. Valige kvaliteedihalduse meetod
4. Valige ettevõtte kõige kriitilisem töölõik
5. Parandage seda töölõiku vastavalt valitud metoodikale
6. Kui põhimõtted ja metoodika on ennast õigustanud, minge tagasi sammule 4
7. Kui metoodika või kvaliteedipoliitika vajavad ümbervaatamist, minge tagasi sammudele 3, 2
või 1
24. Võrdlus: protsessihalduse raamistikud ja arendusmetoodikad. ISO 9000 seeria, ISO
90003, EVS-ISO/IEC 12207, CMMI, ITIL ja ISO/IEC 20000, RUP, XP, IT
Grundschutzhandbuch / ISKE/ ISO 27000 seeria – sisu ja omavaheline võrdlus.
Standard (EVS-)ISO/IEC 12207 võib olla aluseks ettevõtte tarkvaraprotsesside haldusele . Oluline on teada, et ISO/IEC 12207 ei kirjuta ette konkreetset elutsükli mudelit ega tarkvara
arendusmeetodit. Standardiga sobivad väga mitmesugused elutsükli mudelid, sealhulgas agiilsed.
Standardit järgivate huvipoolte hooleks jääb elutsükli mudeli valimine tarkvaraprojekti tarbeks
ning standardi protsesside, tegevuste ja tööde peegeldamine selles mudelis.
CMMI
Sisu:

sisaldab mitut mudelit (hange, arendus, teenused, inimesed)
laiendab ja kombineerib eelnevaid mudeleid - the Capability Maturity Model for

Software (SW-CMM), the Systems Engineering Capability Model and the Integrated Product Development Capability Maturity Model.

tarkvara arenduse, hoolduse ja muude protsesside head tavad
enesehindamine, võrdlus teistega
5 taset: Level 1 (initial), 2 (managed), 3 (defined), 4 (predictable) and 5 (optimizing)
taseme- ja jätkuv mudel
protsessid ütlevad, mida tehakse
tasemed ütlevad, kui hästi seda tehakse

Tugevused:

Võib valida sobiva mudeli
Detailne
Spetsiaalselt tarkvara arendavatele organisatsioonidele
Rõhub pidevale arengule, mitte vaid sertifitseerimisele
Võib kasutada nii sertifitseerimise , täiendamise kui ka enesehindamise vahendina

ISO/IEC 20000 on teenusehaldust käsitlevate standardite pere. Need sisaldavad teenuse nõuetele
vastavate ning nii kliendile kui ka teenuseosutajale väärtust pakkuvate teenuste projekteerimist,
üleminekut, tarnimist ja täiustamist.
ITIL (IT Infrastructure Library) on IT teenuste haldamise parima praktika kogum, mida saab
kasutada ISO/IEC 20000-1 nõuete rakendamiseks.
Infosüsteemide kolmeastmeline etalonturbe süsteem (ISKE) põhineb infovarade turbeastme
määramisel, varade kirjeldamisel tüüpmoodulite abil ning turvameetmete valikul vastavalt
tüüpmoodulitele ning turbeastmele. ISKE rakendamine sisaldab järgmisi tegevusi:
1. Infovarade inventuur
2. Andmekogude kaardistamine ja turvaklasside määramine
3. Muude infovarade turvaklasside määramine
4. Turvaklassiga infovarade turbeastme määramine
5. Tsoonide vajaduse analüüs, asutuse tsoneerimine vajadusel
6. Tüüpmoodulite spetsifitseerimine
7. Turvameetmete loetelu koostamine
8. Turvameetmete rakendamise plaani koostamine
9. Turvameetmete rakendamine
10. Tegeliku turvaolukorra kontroll, vajadusel täiendavate meetmete rakendamine
11. Konfiguratsiooni- ja muudatustehalduse sisseviimine
ISKE põhineb Saksamaa Infoturbeameti (Bundesamt für Sicherheit in der Informationstechnik,
BSI) poolt publitseeritaval IT etalonturbe käsiraamatul (IT Grundschutzhandbuch’il).
25. Kvaliteedimeetrikate näiteid, väärtuse määramispiirkond, parim väärtus
Tarkvara arendusprotsessi (arendusprotsessi kvaliteeti) on vaja mõõta või hinnata mitmetel
põhjustel - näiteks selleks, et teha korrektset pakkumist, et otsustada toote vastuvõtmise üle või
et osata arendajate tööd rahaliselt väärtustada. Selliseks mõõtmiseks kasutatakse tarkvara
meetrikaid - arvutatavaid või hinnatavaid suurusi, mis iseloomustavad olulisi omadusi ja võivad
olla seotud ülesande, projekti, dokumendi või ettevõttega. Tarkvara meetrikate kasutamine on
efektiivne vahend arendusprotsessi parandamiseks, kuid sellega peavad kaasnema teised
kvaliteedihalduse tegevused ning võrdlevad hinnangud teiste arendajatega.
Võimalikke meetrikaid on palju, ülevaate saamiseks võib neid klassifitseerida

tehnoloogia järgi (nt programmeerimiskeeltele orienteeritud meetrikad, andmebaaside

meetrikad jne)

elutsükli protsessi järgi (näiteks arenduse või hoolduse meetrikad)
rakendusala järgi (näiteks juhtimissüsteemides või panganduses kasutatavad meetrikad)

näiteks: koodi ridade arv, produktiivsus, vigade tihedus.
Kvaliteedimeetrika näited:

Spetsifikatsiooni muutmise tase = (E+M+L)/A, kus E - eemaldatud funktsioonid, M-

muudetud funktsioonid, L - lisatud funktsioonid, A - algne funktsioonide arv.

Tehnilise ülesande ja spetsifikatsiooni vastavus = (Funktsioonide arv tehnilises

ülesandes) / (Funktsioonide arv spetsifikatsioonis).

Keskmine tõrgetevaheline aeg = ( Funktsioneerimise kestvus) / (Tõrgete arv)
Probleemi lahendamise keskmine aeg = (Probleemide arv)/(Probleemide lahendamise

summaarne aeg)
26. Tarkvara mahu ja arendusmaksumuse prognoos, selle vahendid, usaldatavus
Meetrikate rakendamise näitena vaatame tarkvara arendusmaksumuse prognoosi. See on
maailmas tunnustatud kui keerukas ülesanne. Ideaalis, selle ülesande sisendiks on tarkvara
spetsifikatsioon ning väljundiks - arenduse maksumus või arenduseks vajalike inimkuude (-
päevade, -aastate) arv. Kahjuks pole head spetsifikatsiooni alati olemas, ka on palju parameetreid
peale funktsionaalsuse, mis maksumust mõjutavad, näiteks mittefunktsionaalsed nõuded
(töökindlus, turvalisus jne), arenduskeskkond, arendusvahendid, arendajate tase ja nii edasi.
Et paljusid neist suurustest ei saa lihtsal viisil mõõta, on nende hinnangud paratamatult kogemuslikku laadi.
Teades orienteeruvat tarkvara mahtu, on võimalik prognoosida arenguks vajalikku töömahtu.
Selleks kasutatakse mitmesuguseid mudeleid, enamlevinud on COCOMO mudel.
Tarkvara arendusmaksumuse prognoosi kokkuvõtteks:

Tarkvara maksumuse prognoosi enamlevinud meetodid kasutavad tarkvara mahu

prognoosi ja selle baasil töökulu prognoosi

Mõlemad prognoosid nõuavad seniste projektide andmebaase ja nende põhjal

prognoosimetoodika kalibreerimist

Tarkvara mahu prognoosi võib teha, kasutades olemasolevaid publitseeritud materjale või

prognoositarkvara. Prognoositarkvara vähendab töömahtu (näiteks Costar)

Prognoosid on kasulikud, kuid võivad ka oma kalibreerituse alas anda tulemusi, mis

erinevad tegelikest. Seepärast on kasulik arvestada lisaks lokaalseid, ettevõtte oma
kogemusi ja andmeid
27. IT standardite ülevaade. Standardimine Eestis, Eesti IT alased standardid
Sertifitseerimine ISO 9001 (hetkel ISO 9001:2008) alusel on Eesti ettevõtete, sealhulgas IT
ettevõtete poolt kõige rohkem kasutatav. Lisaks ettevõtte töö korrastamisele ja
efektiivsemaks muutmisele annab see konkurentsieelise rahvusvahelisel turul.
Nii EVS-ISO/IEC 12207 kui ka EVS-EN ISO 9000 on vastu võetud eesti standardina, mis
hõlbustab nende kasutamist. Esimesel puudub sertifitseerimine, teisel on olemas rahvusvaheline
tunnustamise metoodika ja infrastruktuur . Esimene on protsesside juhtimisele orienteeritud,
näiteks ekspluatatsioon ja hooldus on paremini kajastatud. Teine on orienteeritud
kvaliteedihaldusele, näiteks käsitletakse kvaliteedipoliitikat, kontrolli- ja testimisvahendite ohjet.

tarkvaraga seotud tööprotsesside kujundamiseks, juhtimiseks ja korrastamiseks (ISO/IEC

12207, ISO/IEC 15288)

kvaliteedihalduseks (ISO/IEC 9126, ISO/IEC 90003)
infoturbe haldamiseks (ISO/IEC 27000 seeria)
teenuste loomiseks ja haldamiseks (ISO/IEC 20000 seeria)
eestikeelse tarkvara loomisel (EVS 8)
IT terminoloogia korrastamiseks (ISO/IEC 2382 seeria)
dokumenteerimiseks (ISO/IEC 6592, ISO/IEC 9294 jt)

28. Infosüsteemi audit, selle eesmärgid, auditeeritavad objektid, maht, audiitor , riskid,
korraldus, infrastruktuur, COBIT
Infosüsteemi audit on mitmekülgne ülevaade ja hinnang auditeeritava ettevõtte, asutuse või
organisatsiooni automatiseeritud infosüsteemile või selle osadele, kaasa arvatud seostele
automatiseerimata protsessidega ja organisatsioonilise struktuuriga.
Näiteid auditi eesmärkide kohta:

hinnata süsteemide ja infotöö vastavust ettevõtte (äri)huvidele
hinnata ettevõttega seotud kolmandate osapoolte (näiteks avalikkuse) nõuete rahuldatust
hinnata firma tegevusele eluliselt vajaliku info usaldatavust, kättesaadavust ja kaitstust
hinnata süsteemide või infotöö korralduse kvaliteeti, turvet ja töökindlust
kaitsta tellija huve, kui tellitavas projektis on põhiline teadmine täitja poolel
kontrollida venivaid või muus mõttes ebaedukaid projekte
pakkuda tuge uute projektide käivitamisel

Auditeeritakse kõiki infosüsteemidega seotud objekte, tegevusi, protsesse ja valdkondi, sealhulgas
planeerimist, organisatsiooni, dokumentatsiooni, hanget, projekti, projekti juhtimist, arendust,
metoodikaid, kasutamist, hooldust , mõõtmist, aruandlust, jälgimist (sisemist kvaliteedihaldust).
Audiitor võib kuuluda organisatsiooni koosseisu või olla väljaspool seda. Infosüsteemi audiitor on
isik, kes soovitatavalt omades kehtivat infosüsteemi audiitori sertifikaati, auditeerib auditi
eesmärgist lähtudes auditeeritava organisatsiooni infosüsteemi vastavalt infosüsteemide
audiitorkontrolli eeskirjadele ja järgib infosüsteemi audiitori eetikanormistikku.
Audiitorile esitatakse mitmesuguseid nõudmisi. Ta peaks olema sõltumatu auditeeritavast
rakendusest ja organisatsioonist, olema ekspert infosüsteemide auditeerimises ja infotehnoloogia
vastavas valdkonnas, jälgima auditeerimise head tava ja reegleid, olema tuttav Eesti
seadusandlusega ja standarditega ning tundma mõnda tunnustatud auditeerimise metoodikat.
Auditi läbiviimine sisaldab tavaliselt selliseid samme nagu

eelläbirääkimised, auditeerimislepingu sõlmimine
auditi planeerimine
olukorra identifitseerimine ja dokumenteerimine , näiteks kehtestatud infosüsteemi

kasutamise ja arendamise poliitika; protseduurireeglid; vastavus seadusandlusele,
organisatsiooni äriplaanile, rahvusvahelistele de jure ja de facto standarditele,
tehnoloogilistele nõuetele ja standarditele

reeglite tegeliku täitmise ulatuse hindamine
vajadusel sisuline testimine
hindamine, nt riskide hinnang
hinnang ja raportid.

Auditi planeerimise käigus määratletakse kriitilised valdkonnad, pühendatakse neile piisavalt
tähelepanu ja varutakse ressursse. Lepitakse kokku töö õige järjekord ja koordineerimine,
tõendusmaterjalid, kontrolli metoodika, raportid, tähtajad ja töö maht.
Kuna audit ei kontrolli kõike, siis jääb nagu teistegi auditi tüüpide puhul risk, et auditi käigus ei
avastata ka suhteliselt olulisi vigu. Seda riski tuleb teadvustada lepingu läbirääkimistel ja sellele
tuleb viidata ka auditi lepingus. Auditiga on seotud ka korralduse ja ootuste riskid. Näiteks kui vead
olid enne teada ja nende parandamiseks pole soovi või ressursse, võib auditi kasu olla piiratud.
Maailmas ühendab infosüsteemide audiitoreid eelkõige Infosüsteemide Auditi ja Kontrolli
Assotsiatsioon (Information Systems Audit and Control Association, ISACA).
Üks ISACA olulisemaid töölõike on audiitorite sertifitseerimine. Sertifitseeritud infosüsteemide
audiitor (CISA) peab sooritama vastava eksami, tõendama pidevat koolitust, jälgima audiitori
eetikanorme ja standardeid, omama töökogemust, maksma aastamaksu.
ISACA poolt välja antud info- ja sellega seotud tehnoloogia kontrolli sihid (COBIT), millest on
ilmunud viis versiooni, annavad auditi korralduse üldise metoodika. Viimastel aastatel on COBIT
arenenud pigem üldise protsessiraamistiku suunas. Viimane versioon , COBIT 5, on äriraamistik
ettevõtte IT valitsemiseks ja juhtimiseks.

.DOCX Laadi alla originaalfail 21 lk · .docx · 237 allalaadimist

50 punkti Autor soovib selle materjali allalaadimise eest saada 50 punkti.

~ 21 lehte Lehekülgede arv dokumendis

2013-01-08 Kuupäev, millal dokument üles laeti

237 laadimist Kokku alla laetud

1 arvamus Teiste kasutajate poolt lisatud kommentaarid

Triin Merivald Õppematerjali autor

Lühikonspekt Jaak Tepandi ainest Tarkvara kvaliteet ja standardid

tarkvara programm testid mudel audit analüüs efekt protsessid klassid organisatsiooni eelis arendaja kriteerium teenus

Sarnased õppematerjalid

docx

Tarkvara kvaliteet ja standardid kordamisküsimused

Tarkvara kvaliteedi kordamisküsimused 1. Pakkuge ise kvaliteedi mõiste, võrrelge ülal pakutud mõistega Kvaliteet on nii tootja või kaubamärgiga kaasas käiv omadus, kui ka suhe toote ja nõuete vahel. 2. Kas tarkvara kvaliteedi määratlus erineb teiste toodete kvaliteedi määratlusest? Miks? Ei erine, lihtsalt vaadatakse erinevaid aspekte. 3. Millal võib kvaliteedi määratluses piirduda vaid tootega? Vaid toote ja nõudmistega? Kui kvaliteet on mingi tootja või kaubamärgiga kaasas käiv omadus. 4. Kuidas suhtuda väitesse "Tarkvara kvaliteeti pole olemas, kogu aeg on kiirustamine ja pole aega ühte asja valmis saada, juba tuleb järgmine"? Millist kvaliteedi mõistet siin arvestatakse? Kas / millal on võimalik, et kvaliteeti pole? See oleneb keskkonnast, kus see toode asub. Mõeldud on ideaalse kvaliteedi mõistet. Sageli ei pruugi ideaalset kvaliteeti olemas olla. 5. Tarkvara arenduse tulemid

Tarkvara kvaliteet ja standardid

doc

Tarkvara testimist käsitlev juhendmaterjal

Tarkvara testimist käsitlev juhendmaterjal Tarkvara testimine Testimise parimad praktikad Nõudmiste määratlemine Maili Markvardt ASA Quality Services OÜ Tallinn 2006 Sisukord 1 Lugejaskond ja käsitlusala.......................................................................................3 2 Kasutatavad mõisted.................................................................................................3 3 Sissejuhatus testimisse..............................

Informaatika

Tarkvaratehnika 2016 2017 eksami materjal

138

docx

Tarkvaratehnika 2016/2017 eksami materjal

Tarkvaratehnika: Loeng 1:  Taust: o Tarkvara iseloom o Kõrgenenud nõudmised:  Suuremad süsteemid  Keerulisemad süsteemid  Kiiremini  Erinevad näited vigadest mis on tehtud: o Ariane Crash 1996 kosmosesüstiku alla kukkumine, tuli välja et selle alla kukkumise põhjuseks oli tarkvarasüsteemis viga ilmus trajektoori osas. o Therac-25 kiiritusravi andmises tehti viga kasutaja liideses, kus

Tarkvaratehnika

pdf

Tarkvaratehnika konspekt eksamiks

Ärilised mittefunktsionaalsed nõuded • Peab teenindama 1000 üheaegset kasutajat • Peab olema kättesaadav välisvõrgus • Peab saama kasutada õues päikese käes Süsteemsed mittefunktsionaalsed nõuded – see ei puutu ärist. • Millised tehniloogiaid kasutatakse • Kuidas toimub logimine • Kuidas süsteemi konfigureeritakse Tarkvara kvaliteet Väga lühidalt on kvaliteet toote vastavus nõuetele. Keerukate toodete puhul tuleb vastavuse hindamisel arvesse võtta ka toote loomise protsessi. Tarkvara kvaliteet seob toote, nõuded tootele ja tootmise protsessi. Kvaliteeti ei saa sisse testida. Halvasti arendatud süsteemi pole võimalik kontrolli abil heaks muuta. Lõpptulemus sõltub kogu arendusprotsessist: • vajadustele vastavast riistvarast, • tarkvara arenduse meetoditest ja vahenditest,

Tarkvaratehnika

docx

Tarkvaratehnika

Tarkvaratehnika 1. Loeng Kvaliteetse tarkvara atribuudid: 1. Teostab ettenähtud funktsionaalsust 2. Hooldatav Tarkvara peab arenema, et vastata muutuvatele vajadustele. 3. Usaldusväärne Töökindlus ja turvalisus. 4. Vastuvõetav Kasutajad on aktsepteerinud selle. Tarkvara on neile arusaadav, kasutatav ja ühilduv teiste süsteemidega. Mis on tarkvaratehnika? Tarkvaratehnika on tiimide poolt rakendatav distsipliin tootmaks kõrgekvaliteedilist, suuremastaabilist ja hinnaefektiivset tarkvara, mis rahuldab kasutajate nõudmisi ja mida saab hooldada teatud ajaperioodi vältel. Tarkvaratehnika on süstemaatilise, distsiplineeritud ja mõõdetava lähenemisviisi rakendamine tarkvara arendamisele, käitamisele ja hooldamisele,

Tarkvaratehnika

210

pdf

Tarkvaratehnika kordamisküsimused

TARKVARATEHNIKA KORDAMISKÜSIMUSED 1. Mis on tarkvaratehnika? Software engineering ! “Engineers Australia” definitsioon: Tarkvaratehnika on tiimide poolt rakendatav distsipliin tootmaks kõrgekvaliteedilist, suuremastaabilist ja hinnaefektiivset tarkvara mis rahuldab kasutajate nõudmisi ja mida saab hooldada teatud ajaperioodi vältel. IEEE definitsioon: Tarkvaratehnika on süstemaatilise, distsiplineeritud ja mõõdetava lähehemisviisi rakendamine tarkvara arendamisele, käitamisele ja hooldamisele, see tähendab, inseneriteaduste rakendamine tarkvarale. Tarkvaraarendus on nõrgem termin, kus tingimata ei kasutata protsesse, tööriistu, standardeid, jne. Tarkvaraarendus on progemine + konfigursatsiooni haldus. Tarkvaratehnika ei ole ainult programmi kirjutamine, vaid teemad hõlmavad ka kvaliteeti, ajakavasid,

Tarkvaratehnika

docx

Tarkvaratehnika konspekt ja kordamisküsumused 2016-2017

6. Kuidas liigitada nõudeid? eksam 7. Nõude 3 põhiomadust. 8. Nõuete valideerimise tehnikad. 9. Komponentidel põhinev arhitektuur 10.Kihiline arhitektuur eksam 11.Objektorienteeritud arhitektuur 12.Teenusorienteeritud arhitektuur 13.Lihtsa koodi disaini 4 elementi 14.Miks peab nõudeid haldama? 15.Milleks kasutatakse versioonihaldust? eksam 16.Funktsionaalne nõue eksam 17.Mittefunktionaalne nõue eksam 18.Tarkvara elutsükkel 19.Millest koosneb tarkvara? 20.Mis on testimine? 21.Staatiline testimine eksam 22.Dünaamiline testimine eksam 23.Valge kasti testimine 24.Musta kasti testimine 25.Testimise tasemed 26.Re-testmine ja regressioonitestimine 27.eXtreme programmingu alustalad 28.Kirjelda lühidalt XP-d 29.Mis on mudel? eksam 30.Mis on UML? Miks on seda vaja? 31.Tarkvaratehnika 3 vaadet. 32.Tarkvara protsessi etapid. 33.Tabel disaini ja analüüsi abstraktsioonitasemete kohta 34

Tarkvaratehnika

doc

Tarkvaratestimine

............................................................... 3 MIS ON VIGA?.................................................................................................................................. 4 MIKS VEAD TEKIVAD?.................................................................................................................... 5 KUI PALJU VEAD MAKSAVAD?....................................................................................................... 5 MIDA TÄPSELT TEEB TARKVARA TESTIJA?................................................................................. 5 TARKVARA TESTIJAL PEAVAD OLEMA KA KINDLAD OMADUSED............................................. 6 ERINEVAD TARKVARA ARENDUS MEETODID.............................................................................. 6 MUSTA-KASTI, VALGE-KASTI JA HALLI-KASTI TESTIMINE......................................................... 9 STAATILINE JA DÜNAAMILINE TESTIMINE..............................................

Ainetöö

Rohkem sarnaseid