Miks Ei erine lihtsalt vaadatakse erinevaid aspekte 3 Millal võib kvaliteedi määratluses piirduda vaid tootega?

Vastus leiad õppematerjalist: Tarkvara kvaliteet ja standardid kordamisküsimused

Kui tarkvara enam ei arendata 16 Milline elutsükli mudel on parim?

Vastus leiad õppematerjalist: Tarkvara kvaliteet ja standardid kordamisküsimused

Tarkvara kvaliteet ja standardid kordamisküsimused (1)

Tallinna Tehnikaülikool - Informaatika - Tarkvara kvaliteet ja standardid

1 Hindamata

Esitatud küsimused

Miks Ei erine lihtsalt vaadatakse erinevaid aspekte 3 Millal võib kvaliteedi määratluses piirduda vaid tootega?
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"?
Millal on võimalik et kvaliteeti pole?
Kui nõuded puuduvad?
Mis on vahe kas neid saab koos kasutada?
Millal pole mõtet rääkida tarkvara elutsüklist?
Kui tarkvara enam ei arendata 16 Milline elutsükli mudel on parim?
Millised on hankija tegevused kuidas nad sõltuvad arendusprotsessist ja hankijast?
Kuidas on seotud teenused tarkvara nõuded ja protsessid?
Milleks on vaja teenustaseme leppeid ja mida nad sisaldavad?
Mis on test testimine viga hea test edukas test silumine verifitseerimine valideerimine sertifitseerimine ?
Kuidas valida sisendeid?
Kuidas hinnata väljundit?
Millal testimine lõpetada?
Kes on testijad?
Missugune on testimise ja verifitseerimise vahekord ?
Mis on testimine programmi teksti põhjal?
Mis on adekvaatsuskriteeriumid?
Milline on viimaste võimsuse suhe kuidas neid kasutada?
Mis jäid süsteemi peale testimist 26 Kuidas testida mittefunktsionaalseid nõudeid?
Mis on siin erinev funktsionaalsete nõuete testimisest?
Kuidas testida kasutatavust?
Millised arutelude ja hindamiste liigid on kasutusel?
Milline neist on parim?
Millal tekib vajadus keerukamaks korralduseks?
Millises järjekorras kasutada?
Mida teha kui testida ei saa?
Millal tasub kasutada testimise automatiseerimise süsteeme?
Miks levib ebakvaliteetne tarkvara?
Mida peaks süsteemi arendaja tellija kasutaja hooldaja tarnija firmajuht teadma kvaliteedist ja standarditest?
Millest alustada tarkvaraprotsessi kvaliteedihalduse kavandamist?

Tarkvara kvaliteedi kordamisküsimused

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.

Kas tarkvara kvaliteedi määratlus erineb teiste toodete kvaliteedi määratlusest? Miks?
Ei erine, lihtsalt vaadatakse erinevaid aspekte.

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.

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.

Tarkvara arenduse tulemid
Toode, teenus, mis hõlmab:

Arenduse käigus hangitud infotehnoloogia vahendeid
Arenduse käigus tehtud tööd
Muudatusi tellija organisatsioonis
Projektdokumentatsioon kasutamise, loodavate objektide, installeerimise ja seadistamise, arenduse kohta
Metoodika
Vahendid hoolduseks
Teadmised projekti tulemuste kasutamisest
Õigused kasutamiseks

Tarkvara nõuete liigitusi
Toote-, protsessi-, äri-, andme-, ja kasutusnõuded.

Tarkvara kvaliteedi atribuutide struktuuri vajalikkus, näide struktuurist, integreerimine
Vaja kvaliteediomaduste süstematiseerimiseks.
Atribuudid
Faktorid: juhtkonnale, Funktsionaalsus Kasutuskõlblikkus
kasutajale (üldine ettekujutus)
Kriteeriumid: väljatöötajale Sobivus Arusaadavus
(arendus)
Meetrikad: mõõdetavad
Sellise süsteemi puhul saab näitajatest alustades integreerida väärtusi ülespoole.
Integreerimiseks kasutatakse mitmesuguseid tehnikaid, nagu lihtne väärtuste liitmine , kaalutud summad, hägune loogika , otsustusmeetodid. Valides sobivad integreerimismeetodit toetavad objektid, saab alustada näitajatest ja liikuda ülespoole, kuni lõpuks on olemas üks kvaliteeti iseloomustav arv. Seda võrreldakse etteantud arvuga, et otsustada, kas süsteemi kvaliteet on piisav.

ISO/IEC 25000 [ja ISO/IEC 9126] standardite seeriad
ISO/IEC 25010- kvaliteedimudelite standard (tootekvaliteet, kasutuskvaliteet).
ISO/IEC 9126- kasutus-, välis-, sise- ja protsessi kvaliteeti.

Tooge näiteid funktsionaalsete ja mittefunktsionaalsete nõuete kohta
Funktsionaalne nõue- „Süsteem peab võimaldama kauba tellimist“.
Mittefunktsionaalne nõue- „Süsteemi vastuse aeg peab jääma etteantud piiridesse“.

Tooge näiteid testitavate ja mittetestitavate, reaalsete ja ebareaalsete nõuete kohta
Testitav - „Süsteem peab väljastama jooksva hetke laoseisu“.
Mittetestitav- „Süsteem peab olema töökindel“.
Reaalne- „Süsteem peab töötama järgmiste brauseritega“.
Mittereaalne- „Süsteemi vastuse aeg peab jääma alla kolme sekundi“.

Kas saab testida, kui nõuded puuduvad?
Ei saa, sest siis ei teata, mida tahetakse.

Tarkvara protsessiraamistike ja protsesside näited: ISO/IEC 12207, CMMI, COBIT
ISO/IEC 12207- Tarkvara elutsükli protsessid ( primaar -, abi-, organisatsioonilised protsessid).
CMMI- Ülevaade hankimistegevustest ( hanke , arenduse, teenuse mudelid)
COBIT- Üldine auditi korraldus, viimastel aastatel pigem üldine protsessiraamistik

Tarkvara protsessiraamistikud ja elutsükli mudelid – mis on vahe, kas neid saab koos
kasutada?
Raamistik - iseloomustab kõiki protsesse.
Elutsükkel - iseloomustab arendusprotsessi.
Levinud raamistikud lubavad arendusprotsessis kasutada erinevaid elutsükli mudeleid .

Näited erinevate elutsükli mudelite kohta: kosemudel, V-mudel, spiraalmudel, XP, Scrum , testipõhine arendus.
Kosemudel- iga tegevus toimub eraldi etapina. Eelmine etapp peab olema lõpetatud , enne kui minna täitma järgmist etappi.
Nõudmiste analüüs – Süsteemi ja tarkvara kavandamine – Realiseerimine ja
testimine – Installeerimine – Kasutamine ja hooldus
V-mudel- arenduse ja kontrolli tegevused kulgevad sümmeetrilised. Igale arendustegevusele vastab kontrolli tegevus. Valides erinevaid tegevusi, saab erinevaid V-mudeleid.
Süst nõuete analüüs Süst kvalif test
Tarkv nõuete analüüs Tarkv kvalif test
Tarkv projekteerimine Tarkv testimine
Nõuete analüüs Tarkvara testimine
Spiraalmudel- protsessi kulgemist kujutab spiraal. Iga keerd on tarkvara protsessi faas.
XP- tarkvaraarenduse metoodika, mis on mõeldud tarkvara kvaliteedi parandamiseks ja suurem paindlikkus muutuvate nõuete tingimustes.
Tee selgeks, mida pead tegema
Kirjuta unit test
Pane unit test tööle
Kui esineb probleem, siis paranda see
Scrum- iteratiivne ja kasvava populaarsusega agiilse tarkvara arendamise raamistik. Koosneb sprintidest, mis jäävad nädala kuni ühe kuu vahele. Iga sprindi päeval toimub lühikoosolek, kus arutatakse seniseid saavutusi ning eesmärke.
Testipõhine arendus- luuakse testid enne realiseerimist kliendi kasutuslugude põhjal (ühikstestid, vastuvõtutestid).

Millal pole mõtet rääkida tarkvara elutsüklist?
Siis kui tarkvara enam ei arendata.

Milline elutsükli mudel on parim?
Oleneb projektist, aga tavaliselt kombinatsioon kõigist.

Millised on hankija tegevused, kuidas nad sõltuvad arendusprotsessist ja hankijast?
Hankija tegevused:

Hankimise ettevalmistamine
Hanke väljakuulutamine
Tarnija valimine
Lepingu sõlmimine
Hankijapoolne vastuvõtmine
Sulgemine

Kuidas on seotud teenused, tarkvara, nõuded ja protsessid? Tarkvaranõuded ja teenuse
sihttasemed? Milleks on vaja teenustaseme leppeid ja mida nad sisaldavad?
Tarkvaral võib olla teenuse osutamisel oluline roll, kuid teenuse osutamiseks tuleb tavaliselt kaasata ka mitmeid muid komponente- riistvara , keskkonda; need peavad pidevalt toimima (protsessid); seda toimimist tuleb mõõta (näitajad).
Teenustaseme lepe määratleb teenused ja nende sihttasemed. Leppes kirjeldatakse kvaliteedinõuded, mille täitmiseks peavad tavaliselt nii tarkvara, protsessid, organisatsioon kui ka keskkond rahuldama nendele kehtestatud nõuded.
Teenustaseme leppeid on vaja, et teenuseosutaja ja klient saaksid sätestada nõudeid konkreetsele teenusele.

Mis on test, testimine, viga, hea test, edukas test, silumine, verifitseerimine ,
valideerimine , sertifitseerimine ?
Test- komplekt sisendandmeid ja sisendandmetele vastav oodatud komplekt väljundandmeid .
Testimine- programmi täitmine eesmärgiga leida vigu.
Viga- programmi käitumine spetsifikatsioonile mittevastavalt.
Hea test- test, mis avastab võimalikult palju vigu.
Edukas test- test, mille tulemusena leiti vigu.
Silumine- leitud vea kõrvaldamine.
Verifitseerimine- püüab näidata, et järgmise etapi produkt vastab eelneva etapi määratlusele.
Valideerimine- püüab näidata, et on tehtud seda, mida vaja.
Sertifitseerimine- kolmanda osapoole tegevus, mis püüab näidata, et antud toode vastab vajalikele standarditele ja normdokumentidele.

Kuidas valida sisendeid ? Kuidas hinnata väljundit? Millal testimine lõpetada? Kes on
testijad? Missugune on testimise ja verifitseerimise vahekord ?
Kuidas valida sisendeid- valida selliselt , et kõik programmi osad töötaksid vähemalt korra.
Kuidas hinnata väljundeid- väljundid võetakse ülesande püstitusest.
Millal testimine lõpetada- kui on rahuldatud tarkvara veakindluse nõuded või juhul kui tekkinud veasituatsiooni tõttu pole edaspidine testimine võimalik.
Kes on testijad- kõige halvem testija on programmi looja, kõige parem tulevane kasutaja.
Testimise ja verifitseerimise vahekord- nad täiendavad üksteist.

Suitsutestimine, veaotsing, uuriv testimine, riskipõhine testimine.
Suitsutestimine- täidetakse alamhulk kõigist testidest selgitamaks, kas põhilised funktsioonid töötavad.
Veaotsing- testimine ekspertteadmiste põhjal. Kogenud arendaja oskab tõenäolisi vea kohti ette aimata. Vigu aitavad leida üldised teadmised, teadmised konkreetse rakendusvaldkonna kohta, riist -, või tarkvarakeskkonna kohta. Väga efektiivne vahend, mida võib kasutada nii süsteemselt kui ka intuitiivselt .
Uuriv testimine- mitteformaalne tarkvara testimise tehnika, mille puhul testija hindab testide kavandamist nende täitmise käigus ning kasutab saadud infot uute ja paremate testide projekteerimiseks.
Riskipõhine testimine- testitakse esmalt tootega seotud kriitilisi riske. Selleks selgitatakse välja riskid, omistada neile prioriteedid , testida kõige prioriteetsemaid riske, informeerida teisi osapooli tulemustest ning võtta vastu otsused edasise kohta.

Funktsionaalne testimine, erinevus programmipõhisest testimisest, ekvivalentsiklasside analüüs, piirolukorrad, otsustustabelid, kasutusjuhud.
Funktsionaalne testimine- testimine, mis põhineb süsteemi või komponendi funktsionaalsuse analüüsil.
Erinevus programmipõhisest testimisest- FT puhul vaatame programmi kui "musta kasti" - me ei tea tema sisemist ehitust, teame vaid sisendeid ja vastavaid väljundeid. Erinevus on selles, mille põhjal leitakse testide sisendid . FT-st vaatame ekvivalentsiklasside, piirjuhtude ja vea otsingu meetodeid.
Ekvivalentsklasside analüüs- püüab leida selliseid sisend - ja väljundandmete klasse, et (1) kui mingite andmetega klassist K leitakse viga, siis leitakse sama viga ka teistsuguste andmetega klassist K ja (2) kui mingite andmetega klassist K viga ei ilmne, siis ei aita ka teistsugused andmed klassist K. Piisab siis sellest, et valida mingi üks punkt (test) klassist K, et testida kõik andmed samast klassist. Kui ekvivalentsiklassid on valitud, tuleb nende põhjal koostada testolukorrad ja siis testid.
Piirolukorrad- On leitud, et vigu esineb palju ekvivalentsklasside piiridel, seega tasub teha eraldi teste . Kui piir on reaalarv, siis tehakse teste piiril, sellest veidi suuremal ja väiksemal väärtusel.
Otsustustabelid- kasutatakse kui sisendid on omavahelises sõltuvuses. Otsustustabel sisaldab eeltingimusi, tegevusi ja reegleid. Iga reegli kohta saab defineerida testi.
Kasutusjuhud- kui süsteem on spetsifitseeritud kasutusjuhtude abil, saab nende abil kavandada teste. Näiteks iga kasutusjuhu põhistsenaariumi kohta tehakse vähemalt üks test, kasutusjuhtude sisendid ja väljundid testitakse, kattes nii ekvivalentsklassid kui ka piirjuhud.

Funktsionaalse testimise korraldus ja hinnang
Funktsionaalset testimist võib etappideks jagada järgmiselt:

eristada sisend- ja väljundandmete ekvivalentsiklassid
leida igas klassis, nende piiridel ja kombinatsioonidel esinevad testolukorrad
leida igale testolukorrale vastavad sisend-väljundandmed
identifitseerida testid, koostada testimise plaan
testida, võrrelda tulemusi, hinnata

Hinnang: hea.

Mis on testimine programmi teksti põhjal? Mis on adekvaatsuskriteeriumid? Milline on viimaste võimsuse suhe, kuidas neid kasutada? Kas teeadekvaatsus garanteerib
programmi korrektsuse? Anda hinnang programmi keerukusele. Kuidas toimub tsüklite testimine?
Testimine programmi teksti põhjal- võetakse ette programm ja luuakse teste selle teksti põhjal.
Lauseadekvaatsus- testimise tulemusena peab programmis iga lause olema vähemalt üks kord töötanud.
Haruadekvaatsus- läbib kõik harud, ka tühjad. Seega on täielikum kui lauseadekvaatsus.
Elementaartingimuste adekvaatsus- kui If-lause tingimus on loogiline avaldis , siis tekivad selle avaldise läbimisel sisuliselt programmi harud, mis peavad olema testide käigus läbitud.
Teeadekvaatsus- Kõik programmi teed peavad olema läbitud.
Kas teeadekvaatsus garanteerib programmi korrektsuse- peaks garanteerima.
Programmi keerukus- McCabe’i programmi keerukuse mõõt V(G) põhineb programmi hargnemistel. V(G) annab haruadekvaatsete testide arvu.
Tsüklite testimine- testimisel võib eristada testimist mingi testimiskriteeriumi või – meetodi põhjal. Esimesel juhul koostatakse vajalikke teste valitud meetodite või kriteeriumite põhjal.

Andmepõhine testimine, testimine juhuslike andmetega, lisatud vead
Andmepõhine testimine- sisendandmed tekitatakse programmi tekstis antud andmestruktuuride alusel. Testi oodatavad väljundid võetakse ülesande püstitusest.
Testimine juhuslike andmetega- testimisel kasutatakse sisendandmetena juhuslikke andmeid. Juhuslikult valitud sisendandmed ei taga enamasti piisavat testikatet, kuid juhuslikke andmeid on lihtne automaatselt genereerida.
Lisatud vead- ülesanne on prognoosida süsteemi jäänud vigu. Selleks lisab sõltumatu isik süsteemile juhuslikke vigu. Testimise käigus avastatakse nii lisatud kui ka tegelikke vigu. Eeldades, et vigade avastamise protsent on mõlemal juhul sama, saab prognoosida vigade arvu, mis jäid süsteemi peale testimist.

Kuidas testida mittefunktsionaalseid nõudeid? Mis on siin erinev funktsionaalsete
nõuete testimisest? Tooge näiteid.
Kuidas testida mittefunktsionaalseid nõudeid- staatiliste meetodid, juhusliku testimise ja lisatud vigade meetodid võimaldavad testida töökindlust, küsimustik , vaatlus
Erinevus- funktsionaalne tähendab kindla tegevuse või funktsiooni töötamise kontrollimist. Mittefunktsionaalne on seotud omadustega.

Kuidas testida kasutatavust? Kas võib kasutatavuse testimisena vaadelda ka ekspertide
või kasutajate poolset hääletamist (näiteks kodulehekülgede konkursse)?
Kasutatavuse testimine- uuring, küsimustik, vaatlus

Testimise maht ja lõpetamine. Kuidas hinnata testimise meetodi efektiivsust , millised
meetodid on hinnaefektiivsemad, kas kõige hinnaefektiivsemad meetodid on piisavad ja miks?
Testimise maht ja lõpetamine- Testimise maht peaks sõltuma tarkvara veakindluse nõuetest- testitakse seni, kuni need on rahuldatud.
Testimismeetodite efektiivsuse järjestus:

programmeerija poolne esialgne testimine
suitsutestimine
testimine kasutaja andmetega
riskipõhine testimine
uuriv testimine
ekspertteadmistepõhine testimine
piirjuhud
ekvivalentsklassid
programmipõhine testimine

Ühe meetodi kõrge 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.

Millised arutelude ja hindamiste liigid on kasutusel?
Töö analüüs autori poolt, läbivaatus, audit , programmeerija hindamine

Läbivaatus, selle plussid, miinused, eeltingimused, osavõtjad, korraldus, mängud, suhe
Juhtkonda
Idee- toote rühmapoolne ühisarutelu kindlate reeglite järgi.
Pluss- vigu saab leida varastel arenduse etappidel .
Miinus- rühma liikmed võivad olla väga erinevad inimesed.
Korraldus- nii palju ettevalmistusi kui vaja ning nii vähe kui võimalik.
Eeltingimus- kõigil grupi liikmel on ettekujutus sellest, mida neilt oodatakse.
Osavõtjad- esitaja, koordinaator, sekretär, liikmed.
Mängud- läbivaatusi võivad häirida osavõtjate vahelised mängud. Näiteks korduvalt kasutatud sõnaühend „Jah, aga…“ viitab mängule.

Töö analüüs autori poolt, programmeerija hindamine
Töö analüüs autori poolt- kõige odavam meetod ja leiab vigu. Kui võib siiski olla ebapiisav, sest autori motivatsioon on lõpetada töö, mitte leida vigu.
Programmeerija hindamine- anda programmeerijale arusaamine oma tugevatest ja nõrkadest külgedest. On anonüümne , ei mõjuta liikmete käekäiku.

Küsimustikkude liigitusi, programmeerimisele orienteeritud küsimustiku struktuuri
näide, standard kui küsimustik
Programmeerimisele orienteeritud küsimustiku struktuur:

andmete kirjeldamine
pöördumine andmete poole
arvutusvead
võrdluste vead
juhtimise vead
alamprogramm
sisend ja väljund

Standard kui küsimustik- standardid esitavad küsimustikke standardi ala kohta.

Saavutatav töökindluse tase seniste meetoditega, selle olulise suurendamise võimalusi
Testimisega on saavutatav tase 10-4 viga tunnis ehk umbes üks viga aastas. NASAl aga 10-10 ehk üks viga miljoni aasta jooksul.

Arenduse dubleerimine /N-versiooniline programmeerimine
Paralleelselt arendatakse ja kasutatakse mitut programmi versiooni. Kasutamisel võrreldakse tulemusi, enam levinud vastused loetakse õigeks. Hea riistvara puhul, halb tarkvara puhul.

Veapuu analüüs
Ehitatakse veapuu, kus alustatakse suurest veast, mida tahetakse vältida, vaadatakse selle vea eeltingimusi, eeltingimuste eeltingimusi.

Programmide tõestamine, idee, ajalugu, probleeme, võimalusi jne. Tõestamise tasemed
Idee- luuakse loogiline arvutus. Selle arvutuse terminites kirjeldatakse spetsifikatsioon ning programm. Tõestatakse, et lähtudes antud sisenditest ja kasutades antud programmi jõutakse nõutud väljunditeni.
Ajalugu- tekkis 1960. Avaldati arvukalt töid, kus tõestati lihtsamaid programme . 1990 algas uus tõus, sest oli tekkinud tõestamist teostav tarkvara.
Eeltingimused- spetsifikatsioon, programm, loogikavahendid.
Eelised- suurem töökindlus .
Puudused- töömahukas.
Tulemused- programm tõestatakse spetsifikatsiooni suhtes.
Tõestamise tasemed- spetsifikatsioon, projekt, programmi kood, tõestusmeetodid, objektkood, täitmine.

Cleanroom development : suhe formaalsete meetoditega, testimise korraldus, ülevaade
Suhe meetoditega- kasutatakse testimist juhuslike andmetega, statistilist analüüsi, koodi tõestamist.

Common Criteria : suhe formaalsete meetoditega, tasemete võrdlus, ülevaade
Formaalselt verifitseeritud disain ja testitud . Kokku seitse taset, kus esimene on kõige nõrgem ja seitsmes kõige tugevam.

Võrdlus: töökindluse saavutamine riist- ja tarkvara puhul
Üks vahend töökindluse parandamiseks on dubleerimine (hea riistvara, halb tarkvara puhul). Sest inimlik loogika jälgib samu radu, tehakse samu vigu.

Iseloomustage tarkvara kontrolli korralduse lihtsamaid skeeme . Milline neist on parim?
Kasutaja ja arendaja on sama isik- kui toode pole vastutusrikas , toimib "ise teen, ise testin" korraldus.
Kui kasutaja ja arendaja on erinevad ja toode pole vastutusrikas- võib kasutada järgmist skeemi: tellija annab tellimuse, programmeerija annab tellijale arendatud tarkvara, tellija katsetab tarkvara ja annab programmeerijale leitud vigade kirjelduse, programmeerija parandab vead ja annab üle parandatud toote.
Vastutusrikas tarkvara- võib kasutada sellist skeemi: arendajapoolne testimine, rakenduse ja testimise eksperdi poolne testimine, kasutajate grupi testimine.
Sobivaim- olenevalt olukorrast.

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 ja programmeerijate vaheline koostöö.
Organisatsiooniliselt keerukas kasutaja- nõuab erinevate kasutajate koostööd.

Kontrolli meetodite efektiivsuse võrdlus. Millises järjekorras kasutada?
Suureneva maksumuse järjestuses.

Iseloomustage kontrolli korralduse loogikat: olukord ja testitavad objektid, meetodid,
tegevused (valdkonnad)
Põhineb meetodite efektiivsuse ja maksumuse hinnangul. Nõrgemate nõuete puhul alustatakse kõige odavamatest ja efektiivsematest meetoditest .

V-mudel, arendusprotsessi integreeritud kontroll
Kaasaaegses süsteemiarenduseprotsessis alustatakse kontrolli tegevusega võimalikult varakult. Seepärast projekteeritakse iga arendusetapi käigus ka testid. Eri arendusetappidele vastavad eri tüüpi testid, tekib tarkvara elutsükli V-mudel.

Testimise etapid: ühiku-/mooduli-, integratsiooni-, valideerimise- ja süsteemitestid
Moodultest- mooduli tasemel testimiseks on kasutatavad programmipõhised meetodid, tõestamine, testipõhine arendus.
Integratsioonitest- kõik moodulid kokku ja test, alt üles test, ülalt alla test, segameetod.
Valideerimistest- tarkvara katsetatakse vastavuse suhtes nõudmistele.
Süsteemi testimine- kogu süsteemi tervikuna testimine.

Mida teha, kui testida ei saa?
Rakendada läbivaatusi, tõestamist, töökindluse mudeleid, vigade arvu prognoosi.

Tooge näiteid erinevatest missioonidest sama arenduse erinevatel iteratsioonidel.
Leia nii palju defekte kui võimalik.
Leia tähtsad probleemid ruttu.

TPI või TPI NEXT metoodika põhilised komponendid
Testimise strateegia, testide spetsifitseerimise meetodid, testimise vahendid.

Kontrolli testimise automatiseerimise vahendite liigitus, vajalikud ressursid , eelised,
puudused, näited. Oskus kasutada vähemalt kahte testimise automatiseerimise vahendit
Eelised- võimaldab kvaliteeti parandada, võib kasutada peaaegu kõigis testimise protsessides.
Puudused- kõiki test case -i ei saa automatiseerida, disainivigu ei leita.
Näited- Selenium, JUnit.

Millal tasub kasutada testimise automatiseerimise süsteeme?
Kui on vaja läbi viia korduv testimine.

Kvaliteet, tarkvara, nõuete liigitusi, tarkvara elutsükkel, elutsükli liigid
Kvaliteet- vastavus nõudmistele.
Tarkvara- tarkvara arenduse tulem.
Nõuete liigitusi- Määratud või eeldatud. Tulenevad spetsifikatsioonist, standartitest, normidest, seadustest.

Kvaliteedihaldus, -poliitika, -süsteem, -tõendus
Kvaliteedihaldus- üldine juhtimisfunktsiooni osa, mis määrab kindlaks ja rakendab kvaliteedipoliitikat.
Kvaliteedipoliitika- organisatsioon tippjuhtkonna ametlikult esitatud kvaliteedialased ühised eesmärgid ja juhtnöörid .
Kvaliteedisüsteem- organisatsiooniline struktuur, vastused, protseduurid ja vahendid kvaliteedi juhtimiseks .
Kvaliteeditõendus- tegevuste kogum, mis on vajalik piisava usaldatavuse tagamiseks, et toode või protsess rahuldab esitatud kvaliteedinõudeid.

Miks levib ebakvaliteetne tarkvara?
Võrgumajandus ehk “võitja võtab kõik” efekt. Võitja saab kõige rohkem kasutajaid.
Kvaliteedi mõiste võib tähendada erinevatele kasutajatele erinevaid asju, seega ei saa kõiki rahuldada.

Kvaliteet ja organisatsiooni juhtimine
Usa, Euroopa ja Jaapani arusaamad kvaliteedist on teistsugused. Usa ja Euroopa kvaliteedijuhtimine on orienteeritud tulemusele, oluline roll on lõpptulemusel , mitte projekti kvaliteedil. Jaapanis on kvaliteedi juhtimine orienteeritud protsessile, on oluline, et kogu tootmine oleks kvaliteetne.

Kvaliteedihalduse ja arendusmeetodite seos
Kui Usas ja Euroopas tehakse kardinaalselt uusi otsuseid, siis Jaapan on osanud areneda pidevalt, ilma suurte hüpeteta.

Kvaliteedihalduse integreerimine tarkvara elutsüklisse
Usa ja Euroopa kvaliteedijuhtimine on olnud ajalooliselt enam orienteeritud statistilistele meetoditele. Jaapanis on see seevastu rohkem iga töötaja küsimus.

Kvaliteedihalduse käsitlusi, teese, süsteeme ja auhindu
Teesid- Tee kohe õigesti, ei ühtegi vigast toodet, kvaliteet on tasuta.
Süsteemid- kvaliteedi hindamiseks on mitmeid süsteeme.
Auhinnad - The European Quality award , Eesti juhtimiskvaliteedi auhind, Malcolm Baldridge auhind.

ISO 9000 seeria, ISO 90003. Rakendamine ja sertifitseerimine
Seeria - ISO 8402, 9000, 9001 , 9002, 9003, 9004
ISO 9003 - Masstootmise standard, lõpliku katsetamise ja inspektsiooni standardid.
Rakendamine- ISO 9001 rakendamisel tuleks lähtuda ärivajadustest, kvaliteedijuhtimise põhimõtetest ja oma valdkonna võimalustest, muuhulgas arvestades järgmises jaotises toodud esimesi kvaliteedijuhtimise tegevusi ettevõttes.
Sertifitseerimine- ISO 9000 seeria standardite jaoks on olemas rahvusvaheline tunnustamise infrastruktuur, mis lubab vajaliku taseme saavutanud ettevõtetel taotleda rahvusvahelist sertifikaati ning seda oma klientidele teadvustada.

Mida peaks süsteemi arendaja (tellija, kasutaja, hooldaja , tarnija, firmajuht) teadma
kvaliteedist ja standarditest?
Tellija- tal on sellest tarkvarast rohkem teadmisi, ei kuluta nii palju aega tarkvara paranduseks.
Kasutaja- on teadmised, seega oskab valida parema tarkvara, teab, miks üks on halb ja teine hea.
Hooldaja- kui ta teab, mida arendaja mõtles, on tal lihtsam vigu leida. (standardi järgi)
Tarnija- kui tal on teadmised standardi järgi tehtud tarkvara kohta, siis ta oskab selle kohta ka kõige tähtsamaid asju öelda.
Firmajuht- teab, mida firma rahaga tehakse, otsib uusi kliente, vaatab, kuhu turule minna, et oma ettevõtet reklaamida.

Millest alustada tarkvaraprotsessi kvaliteedihalduse kavandamist?

Juhtkonna toe kindlustamine
Kvaliteedihalduse eesmärkide planeerimine lähtudes ettevõtte strateegiast
Eesmärkide ja poliitika tutvustamine töötajatele
Kvaliteedihalduse meetodi valimine

Põhimõisted, eesmärgid, ülevaade, millal ja kuidas kasutada: ISO/IEC 20000 seeria ja ITIL , ISO/IEC 27000 seeria ja ISKE , RUP.
ISO/IEC 20000- teenusehaldust käsitlev standard.
ITIL- it teenuste haldamise parima praktika kogum, mida saab kasutada ISO 20000 nõuete rakendamiseks. Infotehnoloogia haldamise tavade ja protsesside standardite kogu.
ISO/IEC 27000- Sisaldab infoturbe halduse süsteeme.
ISKE- infosüsteemide kolmeastmelise etalonturbe sü steem . põhineb infovarade kaardistamisel, nende turbeastmete määramisel, tüüpmoodulite kasutamisel, turvameetmete valikul vastavalt tüüpmoodulitele ning turbeastmele ning turvameetmete rakendamisel.
RUP- iteratiivne tarkvaraarenduse raamistik. Testid põhinevad spetsifikatsioonil.

Kvaliteedinäitajate näiteid, väärtuse määramispiirkond , parim väärtus
Näited- arvestatakse vaid lõpliku koodi-vahepealseid versioone ei loeta. Arvestatakse koodi, mis on loodud arendustiimi poolt, mitte abivahendeid.
Määramispiirkond- keskmine tõrgetevaheline aeg, probleemi keskmine lahendamise aeg.
Parim võimalik väärtus- spetsifikatsiooni muutumise tase, tehnilise ülesande ja spetsifikatsiooni vastavus.

Tarkvara mahu ja arendusmaksumuse prognoos, selle vahendid, usaldatavus
Prognoos- sisendiks on tarkvara spetsifikatsioon ning väljundiks arenduse maksumus.
Vahendid- publitseeritud materjalid või prognoositarkvara.

Eesti IT valdkonda puudutavad standardid

Tarkvaraga seotud tööprotsesside kujundamiseks, juhtimiseks ja korrastamiseks (ISO/IEC 12207)
Kvaliteedihalduseks (ISO/IEC 25000 seeria, ISO/IEC 9000 seeria)
Infoturbe haldamiseks (ISO/IEC 27000 seeria)
Teenuste loomiseks ja haldamiseks (ISO/IEC 20000 seeria)
Eestikeelse tarkvara loomisel (EVS 8)

Standardi mõiste, eelised, puudused
Mõiste- normdokument, mis on suunatud standardimiseesmärkide saavutamiseks.
Eelised- kulutuste minimeerimine, protseduuride lihtsustamine, kvaliteedijuhtimine.
Puudused- lisakulu, lisaaeg.

Standardite liigitus

Ametlik, mitteametlik
Üldine, organisatsiooniline, tehniline
Rahvusvaheline, riiklik
Ettevõttesisesed, ettevõttevälised

Standardimiskehamite näited
ANSI/IEEE, ISO/IEC, BS, MIL, DoD, IEE

Standardimine Eestis: korraldus, IT standardite tehniline komitee
Korraldus- Eesti Standardimiorganisatsioon, Tehniline Komitee, Informaatikafond.
IT standardite tehniline komitee- asutati 1997, üle 20 liikme.

Standarditavad valdkonnad
Kvaliteedihaldus, testimine, dokumenteerimine , turve.

Standardite kasutamine
Rahvusvahelised standardid on eeskujuks firmasisestele.
Ettevõtte standardi koostamine rahvusvahelisel tasemel.

Infoturbe standardid
ISO/IEC 27001

Dokumenteerimist käsitlevad standardid
ISO 15489. Dokumendihaldus
ISO 5127. Informatsioon ja dokumentatsioon . Sõnastik

IT audit, selle eesmärgid, auditeeritavad objektid, maht, audiitor , riskid
IT audit- ülevaade ja hinnang ettevõttele.
Eesmärk- hinnata süsteemide ja infotöö vastavust ettevõtte huvidele. Hinnata süsteemide korralduse kvaliteeti.
Maht- infosüsteemi maht sõltub ülesandest.
Audiitor- valida, kes on sõltumatu auditeeritavast rakendusest, jälgib head tava ja reegleid.
Riskid- tegevusrisk IS toimimisel ja arendamisel. Avastamisrisk ehk autor ei avasta olulisi vigu.

Planeerimine, korraldus
Planeerimine- määratletakse kriitilised valdkonnad, töö õiges järjekorras, raportid, tähtajad .
Korraldus- eelläbirääkimised, auditeerimislepingu sõlmimine, auditi planeerimine, olukorra dokumenteerimine, hinnang ja raportid.

Organisatsioonid , sertifitseerimine
Organisatsioonid- ISACA ehk infosüsteemide audiitorite ühendus.
Sertifitseerimine- Sertifitseeritud infosüsteemide audiitor peab sooritama vastava eksami, tõendama pidevat koolitust, jälgima audiitori eetikanorme ja standardeid, omama töökogemust, maksma aastamaksu.

.DOCX Laadi alla originaalfail 11 lk · .docx · 39 allalaadimist

Tarkvara kvaliteet ja standardid kordamisküsimused #1

Tarkvara kvaliteet ja standardid kordamisküsimused #2

Tarkvara kvaliteet ja standardid kordamisküsimused #3

Tarkvara kvaliteet ja standardid kordamisküsimused #4

Tarkvara kvaliteet ja standardid kordamisküsimused #5

Tarkvara kvaliteet ja standardid kordamisküsimused #6

Tarkvara kvaliteet ja standardid kordamisküsimused #7

Tarkvara kvaliteet ja standardid kordamisküsimused #8

Tarkvara kvaliteet ja standardid kordamisküsimused #9

Tarkvara kvaliteet ja standardid kordamisküsimused #10

Tarkvara kvaliteet ja standardid kordamisküsimused #11

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

~ 11 lehte Lehekülgede arv dokumendis

2017-01-11 Kuupäev, millal dokument üles laeti

39 laadimist Kokku alla laetud

1 arvamus Teiste kasutajate poolt lisatud kommentaarid

lotatimmu Õppematerjali autor

Tarkvara kvaliteet ja standardid kordamisküsimused tepandi konspekti põhjal.

Tarkvara kvaliteet ja standardid kordamisküsimused tarkvara kvaliteet tarkvara standardid tepandi spetsifikatsioon seeria sisend testimine tarkvara

Sarnased õppematerjalid

docx

Tarkvara kvaliteet ja standardid

1. 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

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

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

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

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öö

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

Rohkem sarnaseid