4. Verifiointi ja validointi. Kevät 2005 Empiirinen ohjelmistotutkimus / Taina. Kevät 2005 Empiirinen ohjelmistotutkimus / Taina

Koko: px
Aloita esitys sivulta:

Download "4. Verifiointi ja validointi. Kevät 2005 Empiirinen ohjelmistotutkimus / Taina. Kevät 2005 Empiirinen ohjelmistotutkimus / Taina"

Transkriptio

1 4. Verifioinnissa varmennetaan, että järjestelmä on toimiva ja optimaalinen. Yleensä se muotoillaan kysymykseksi Kehitämmekö järjestelmää oikein? Validoinnissa varmennetaan, että järjestelmä vastaa siitä kirjattuja vaatimuksia. Yleensä se muotoillaan kysymykseksi Kehitämmekö oikeaa järjestelmää? Verifiointia ja validointia (V&V) tehdään koko projektin keston ajan. Verifiointi- ja validointitekniikat Tärkeimmät V&V-tekniikat ovat tarkastukset ja testaus: tarkastukset: selvitetään ohjatussa kokouksessa dokumentin puutteita ja virheitä. (dynaaminen) testaus: annetaan ohjelmalle syötteitä ja katsotaan, minkälaisia tuloksia se antaa niillä. Muita V&V-tekniikoita ovat mm. mallinnus, simulaatiot ja todistaminen. 1 2 Verifioinnin ja validoinnin luonne V&V:n lait ja hypoteesit V&V on laadunvarmistusta, ryhmätyötä ja rinnakkaisia menetelmiä. Miksi? Fagan: Tarkastukset parantavat merkittävästi tuotteen laatua. Hezer-Myers: Parhaat tulokset saadaan yhdistelemällä V&V:n tekniikoita. Weinberg: Ohjelmoijan ei pidä testata omaa koodiaan. Djikstra: Täydellinen testaus ei onnistu. Oppikirjassa esitellyt V&V:n lait ovat käytännöllisiä. Siten ne eroavat selvästi esimerkiksi vaatimusmäärittelyn laeista. Lakien ja hypoteesien sanoma voidaan tiivistää näin: V&V on laadunvarmistuksen työkalu. Siinä tarvitaan yhteistyötä sekä menetelmien että tekijöiden välillä. 3 4 V&V:n lait ja liittyminen ohjelmistotekniikkaan V&V:n lait ja liittyminen ohjelmistotekniikkaan 2 Seuraavassa ovat lait ja hypoteesit ja niiden liittyminen ohjelmistotekniikkaan: Faganin laki: tarkastukset Porter-Vottan laki: tarkastukset Basilin laki: tarkastukset Hetzel-Myersin laki: tarkastukset, mustalaatikkotestaus, lasilaatikkotestaus Mills-Jonesin hypoteesi (ei käsitellä): laadunvarmistus, prosessinhallinta Maysin hypoteesi: mustalaatikkotestaus Hoaren hypoteesi (ei käsitellä): verifiointi Sackmanin ensimmäinen laki (ei käsitellä): virheenjäljitys Djikstran laki: mustalaatikkotestaus, lasilaatikkotestaus Weinbergin laki: mustalaatikkotestaus Pareto-Zipf laki: ohjelmistotekniikka Gray-Serlin laki (ei käsitellä): rasitustestaus 5 6 1

2 V&V:n lait ja liittyminen ohjelmistotekniikkaan 3 Nielsen-Normanin laki (ei käsitellä): käytettävyystestaus Gutjahrin hypoteesi (ei käsitellä): mustalaatikkotestaus Weyukerin hypoteesi (ei käsitellä): lasilaatikkotestaus Endres-Glatthaar hypoteesi (ei käsitellä): lasilaatikkotestaus Hamletin hypoteesi: mustalaatikkotestaus V&V:n lait ja liittyminen ohjelmistotekniikkaan 4 Kuten edellisestä listasta nähdään, V&V:n lakeja ja hypoteeseja on paljon ja niillä on usein täsmällinen merkitys. Näin ne eroavat selvästi yleisemmistä vaatimusmäärittelyn ja suunnittelun laeista. Itse asiassa varsinkin lasilaatikkotestauksesta olisi enemmänkin lakeja, mutta ne eivät kuulu eot:n piiriin. 7 8 V&V:n lait ja liittyminen ohjelmistotekniikkaan 5 Eniten kaivattaisiin lisää mustalaatikkotestauksen teoriaa ja menetelmiä. Tällä hetkellä mustalaatikkotestaus perustuu pääasiassa syöteavaruuden ositukseen. Tarkastusten tilanne on parempi. Teoria on osoittautunut hyväksi ja uutuudet ovat olleet kosmeettisia. Lasilaatikkotestaus on matemaattisesti parhaiten hallittu V&V-tekniikka Faganin laki Tarkastukset parantavat merkittävästi tuottavuutta, laatua ja prjektien stabiiliutta. Fagan esitti 1970-luvulla IBM:lla, miten dokumenteista voidaan tehokkaasti löytää virheitä muodollisilla tarkastustilaisuksilla. Tarkastusten hyvyys on yksi vahvimmista EOT:n laeista. Sitä on sekä validoitu että varmennettu käytössä yli 30 vuoden ajan. 10 Faganin lain taustaa Faganin tarkastukset ovat tuttuja: 1. Joukko tarkastajia saa tarkastettavan dokumentin luettavaksi useita päiviä ennen sovittua tarkastustilaisuutta. 2. Tarkastustilaisuutta johtaa puheenjohtaja. 3. Tarkastajat esittävät tilaisuudessa löytämiään dokumentin puutteita ja virheitä. 4. Puutteet ja virheet kirjataan ylös. 5. Lopuksi päätetään dokumentille tehtävät toimenpiteet. 11 Faganin lain taustaa 2 Faganin lakia voidaan soveltaa minkä tahansa prosessin dokumenttiin. Parhaimmillaan se on kuitenkin silloin, kun dokumentti on saatu monesta lähteenä ryhmätyönä. Tarkastuksia pidetään aiheesta kaikkein tehokkaimpana V&V:n tekniikkana. Tästä huolimatta tarkastuksia tehdään yrityksissä edelleen yllättävän vähän. 12 2

3 Faganin lain perusteluja Faganin lain perusteluja 2 Fagan perustaa tuloksensa empiiriseen kokeeseen. Hän vertaili kahta prosessia, joista toisessa tarkastusten avulla tuotosta muokattiin aikaisin, ja joista toisessa ilman tarkastuksia muokkaus tehtiin testauksen jälkeen. Faganin mukaan tarkastukset antoivat 23% tuottavuuslisän. 13 Tuottavuuden lisäksi Fagan vertasi laatua. Faganin mukaan tarkastusryhmässä kaikkien löydettyjen virheiden lukumäärä oli 38% pienempi kuin vertailevassa ryhmässä. Myös muista lähteistä on saatu vastaavia tuloksia: jopa lähes 100% kaikista virheistä on löydetty tarkastuksissa. 14 Faganin lain teoria Faganin laki on oikeastaan seurauslause Boehmin ensimmäisestä laista. Tarkastusten avulla virheet löydetään aikaisin, joten niiden kustannus pysyy pienenä. Tarkastukset eivät kuitenkaan korvaa testausta. Varsinkin monimutkaisten oliopiirteiden virheiden löytäminen tarkastuksilla voi olla hyvin vaikeaa Porter-Vottan laki Tarkastusten tehokkuus ei juurikaan riipu niiden järjestelytavasta. Porter ja Votta pyrkivät selvittämään empiirisin kokein, miten tarkastuksia kannattaisi järjestää. Heidän tutkimuksensa tulos oli, että järjestelyt eivät erityisesti vaikuta. Alkuperäiset järjestelyt ovat ihan hyvät. Tarkastusprosessia on vaikea parantaa Porter-Vottan lain taustaa Porter-Vottan lain taustaa 2 Faganin tarkastukset on kuvattu aika yleisesti, joten niistä on tehty useita variaatioita. Esimerkiksi seuraaviin kysymyksiin on vastattu eri tavoin: Onko tarkastustilaisuuden tarkoituksena tehdä päätöksiä valmisteluvaiheessa löytyneistä virheistä, vai pitääkö virheet tunnistaa tarkastustilaisuudessa? Käytetäänkö dokumenttia kohden yhtä vai useaa tarkastustilaisuutta? 17 Intuitiivisesti tuntuisi, että yritykselle räätälöity tarkastusprosessi antaisi yleistä parempia tuloksia. Porter-Vottan lain mukaan intuitio on väärässä. Tarkastusvariaatioiden väliset erot ovat pienet. Merkittävin poikkeus laista ovat näkökulmaperustaiset tarkastukset, joita käsitellään Basilin laissa. 18 3

4 Porter-Vottan lain perusteluja Porter ja Votta perustavat lakinsa tapaustutkimukseen. He analysoivat Lucent Technologiesin puhelinkeskusjärjestelmän tarkastuksia. Porter ja Votta kävivät läpi 88 puhelinkeskusjärjestelmän tarkastusta 18 kuukauden aikana. He saivat varsin mielenkiintoisia tuloksia. 19 Porter-Vottan lain perusteluja 2 Empiirisen kokeen tulokset: Virheiden luokitteluun perustuva lähestymistapa korkeampi virheiden tunnistustahti: pätee Fyysinen tapaaminen korkeampi virheiden tunnistustahti: heikko yhteys Ositetut tarkastukset korkeampi virheiden tunnistustahti: heikko yhteys Enemmän kuin kaksi tarkastajaa korkeampi virheiden tunnistustahti: ei päde 20 Porter-Vottan lain perusteluja 3 Näin ollen Porter-Vottan perustelujen mukaan tarkastuksille pätee: Tarkastuksessa kannattaa keskittyä ennalta määrätyn tyyppisiin virheisiin. Kaksi ihmistä tarkastaa paremmin kuin yksi, neljä ei tarkasta paremmin kuin kaksi. Yhteistä tilaisuutta ei ole pakko järjestää. Tarkastusta ei kannata osittaa peräkkäisiksi istunnoiksi. 21 Porter-Vottan lain teoria Jokainen tarkastaja käyttää omaa virheiden tunnistuksen menetelmää. Nämä menetelmät ovat jonkun verran päällekkäisiä, mutta kuitenkin erilaisia. Kahdella tarkastajalla ei ole paljon päällekkäisyyttä, kolmella on enemmän, neljällä vielä enemmän jne. Päällekkäisyys on resurssien tuhlausta ja johtaa tehottomaan prosessiin. 22 Porter-Vottan lain teoria 2 Tarvittaviin resursseihin verrattuna paras tulosparannus saadaan siirryttäessä yhdestä tarkastajasta kahteen tarkastajaan. Kahta useamman tarkastajan käyttö ei enää juuri paranna tulosta, paitsi jos tarkastajille sovitaan toisistaan eroavat näkökulmat dokumenttiin. Muut tekijät ovat toisarvoisia Basilin laki Näkökulmaperustaiset tarkastukset ovat (erittäin) tehokkaita. Näkökulmaperustaisessa (perspectivebased) tarkastuksessa etsittävät virhetyypit luokitellaan sidosryhmittäisiksi näkökulmiksi. Näkökulmia käyttämällä tarkastajien keskinäinen päällekkäisyys minimoidaan, ja tarkastettava dokumentti saadaan katettua paremmin. 24 4

5 Basilin lain taustaa Porter-Vottanin lain yhteydessä mainittiin virheiden luokitteluun perustuvat tarkastukset. Niissä tunnettuja virhelähteistä sadaan näkökulmat tarkistuslistan kohdille. Basilin laissa idea viedään askelta pitemmälle käyttämällä sidosryhmiä näkökulmien lähteenä. Basilin lain taustaa 2 Näkökulmaperustaisessa tarkastuksessa kullekin tarkastukseen osallistujalle valitaan rooli. Roolissaan hän esittää jonkin sidosryhmän edustajaa, ja toimii sekä valmistautumisessa että tarkastustilaisuudessa roolinsa mukaan. Roolien avulla tarkastajat keskittyvät eri tyyppisiin virheisiin virheluokittelun tapaan Basilin lain perusteluja Basilin lain teoria Basili käytti tutkimuksessaan ohjattua koetta. Toisessa ryhmässä käytettiin tavallista tarkastusprosessia, toisessa näkökulmapohjaista tarkastusprosessia. Oppikirjan mukaan näkökulmapohjainen tarkastus oli tehokkaampi kuin tavallinen tarkastus. Kirjassa ei kuitenkaan anneta tarkkoja lukuarvoja. Aivotyö on raskasta ja kallista. Jos joukolla saman alan asiantuntijoita on sama tarkastus, he hyvin helpolla saattavat nähdä ongelman samasta suunnasta ja näin löytää samat viat. Roolijaolla kukin asiantuntia keskittyy toisista eroavaan näkökulmaan, jolloin ongelmat nähdään eri suunnista Hezel-Myersin laki Hezel-Myersin lain taustaa Useaa V&V-tekniikkaa käyttämällä saavutetaan parempia tuloksia kuin yhdelläkään menetelmällä yksinään. Hezel-Myersin laki käsittelee kolmea V&Vtekniikkaa: tarkastuksia, mustalaatikkotestausta ja lasilaatikkotestausta. Hetzel vertasi tekniikoita 1976 ja Myers julkaisi tulokset Tarkastukset ja testausmenetelmät täydentävät toisiaan. Kaikkia tarvitaan. Tarkastuksilla löydetään parhaiten vaatimusmäärittelyn ja korkean tason suunnittelun virheitä Mustalaatikkotestauksella löydetään parhaiten määrittelyvirheitä Lasilaatikkotestauksella täydennetään mustalaatikkotestauksen testitapaukset kattamaan koko ohjelmakoodi. 30 5

6 Hezel-Myersin lain perusteluja Hezel-Myersin lain perusteluja 2 Hezel-Myersin lain ohjatussa kokeessa testaajalle annettiin testattavaksi ohjelma, johon oli upotettu 15 virhettä. Testaajat eivät tienneet virheistä. Osallistujat jaettiin kolmeen ryhmän, joista yhdessä testattiin mustalaatikkotestauksella, yhdessä lasilaatikkotestauksella ja yhdessä tarkastuksilla. 31 Kokeen tulokset olivat mielenkiintoiset. Eniten Myersia yllätti, että löydettyjen virheiden määrä vaihteli vahvasti osallistujien kesken. Tästä hän päätteli, että on erityisen tärkeää selvittää, kuka käyttää mitäkin menetelmää. Seuraavalla kalvolla on Hezel-Myersin ohjatun kokeen yhteenveto. 32 Hezel-Myersin lain perusteluja 3 Hezel-Myersin lain teoria Löydettyjen virheiden keskiarvo Löydettyjen virheiden keskihajonta Löydettyjen virheiden mediaani Löydettyjen virheiden vaihteluväli Löydettyjä virheitä yhteensä Hakuaika minuuttia/virhe Lasilaatikko Mustalaatikko 4,5 4,8 4, ,4 5,5 5, Tarkastukset 5,7 3, Mustalaatikko + tarkastukset 7,6 4, Hezel-Myersin lain menetelmät eivät kilpaile keskenään. Kullakin menetelmällä on vahvuudet ja heikkoudet. Ne käsittelevät virheiden löytymistä eri suunnilta. Kaikki virheet eivät ole samanlaisia tai esiinny samassa kehitystyön vaiheessa. Eri tyyppisten virheiden etsintään pitää olla erilaisia menetelmiä Maysin hypoteesi Virheiden välttäminen on parempi kuin virheiden poistaminen. Maysin hypoteesi on vain hypoteesi, sillä sen todistaminen on äärimmäisen vaikeaa. Silti kaikki vähänkään testauksen kanssa tekemisissä olleet uskovat, että Maysin hypoteesi pätee. Jos virheitä ei synny, niiden korjaukseen vaadittavia resursseja ei myöskään tarvita. Maysin hypoteesin taustaa Jokainen virhe, vaikka miten pieni ja aikaisin havaittu, vaatii ylimääräistä työtä ja lisäkustannuksia. Siis virheiden synty kannattaa estää. Estäminen vaatii sekä virheiden syiden tunnistamista että syiden poistamista. Hypoteesi on voimassa, jos virheiden syntymisen estäminen vaatii vähemmän resursseja kuin virheiden korjaus

7 Maysin hypoteesin perusteluja Mays esitteli artikkelissaan 1990 IBM:lla kehitettyä virheiden välttöprosessia. Prosessissa havaitut virheet analysoitiin, ja analysoinnin perusteella kehitettiin strategia vastaavien virheiden välttämiseksi. Artikkelissa ei kerrottu, miten tehokkaaksi prosessi osoittautui. Maysin hypoteesin perusteluja 2 Vastaava tutkimus tehtiin 1994 myös IBM:lla. Tällöin käytettiin seuraavaa prosessia: 1. Etsitään ja korjataan tuotteen virheet 2. Etsitään ja eliminoidaan virheiden syyt 3. Etsitään prosessin syitä, joiden takia virheitä ei huomattu ajoissa. Korjataan prosessia. 4. Etsitään samanlaisia toistaiseksi havaitsemattomia virheitä ja eliminoidaan myös ne Maysin hypoteesin perusteluja Djikstran laki Jälkimmäisen tutkimuksen tuloksena saatiin seuraavaa: 85% kaikista virheistä löydettiin ennen koodin liittämistä kehitysversioon, siis ennen testausta. 7% virheistä löydettiin testauksessa. Tulokset ovat hyviä, vaikka eivät kerro virheiden korjauskustannuksista suhteessa prosessin kustannuksiin. Testauksella voidaan löytää virheitä mutta ei osoittaa ohjelmaa virheettömäksi. Djikstran laki on testauksen tärkein laki. Djikstra esitteli lakinsa 1970, ja siitä lähtien se on esitelty varmaankin kaikilla testaukseen liittyvillä kursseilla Djikstran lain taustaa Djikstran laki asettaa testaukselle selkeän rajan: testaus ei voi koskaan olla täydellistä. Täydellinen testaus vaatisi ainakin seuraavat testit: kaikki syötekombinaatiot, kaikki reitit ohjelman alusta loppuun, kaikki ajoitukset. Käytännössä tämä on mahdotonta. 41 Miksi täydellinen testaus on mahdottomuus? Koska kaikissa ei-triviaaleissa ohjelmissa testitapausten määrä kasvaa hetkessä niin suureksi, että yksikään kone ei pysty ajamaan niitä järjellisessä ajassa. Koska kaikkien mahdollisten reittien määrä ei-triviaalissa ohjelmassa kasvaa niin suureksi, että yksikään kone ei pysty suorittamaan niitä järjellisessä ajassa. Koska triviaaleja ohjelmia ei kannata speksata, joten kaikki ovat ei-triviaaleja. 42 7

8 Djikstran lain perusteluja Djikstran laki on luonteeltaan matemaattinen, joten siitä ei ole empiirisiä tuloksia. Matemaattisesti se voidaan osoittaa oikeaksi konstruoimalla sellainen ohjelma, jossa on niin monta virheellistä polkua, että yksikään tietokone ei voi käydä niitä läpi järkevässä ajassa. Djikstran lain teoria Djikstran laki pätee, koska minkä tahansa ei-triviaalin ohjelman syötteiden, tilojen, siirtymien ja ajoitusten kombinaatioiden lukumäärä kasvaa hallitsemattomiin lukuihin. Djikstran laki on erinomainen esimerkki siitä, että pelkkä mustalaatikkotestaus ei takaa virheetöntä ohjelman toimintaa Weinbergin laki Weinbergin lain taustaa Ohjelmoija on soveltumaton testaamaan kirjoittamaansa koodia. Weinbergin laki on laadunvalvonnan peruslaki. Sillä voidaan perustella laadunvarmistuksen käyttö. Faganin laki tarkastuksista ja Weinbergin laki testauksesta ovat saman asian kaksi puolta: laadunvarmistus vaatii ulkopuolista työpanosta. 45 Weinbergin laki esiintyy jatkuvasti projekteissa. Jokainen löytää tietyt virheet, mutta hankalissa tapauksissa virheen löytää vasta ulkopuolinen silmäpari. Sen jälkeen kun ohjelmoija on vakuuttunut, että hänen koodinsa on virheetön, siitä löytyy vielä 1-3 virhettä/100 koodiriviä! 46 Weinbergin lain perusteluja Weinbergin lain teoria Vaikka miten katsoo kirjoittamaansa koodia ja etsii sieltä virheitä, niin sen näkee samalla tavalla kuin sen kirjoitti. Omat ajatuskulut ohjaavat koodin näkemistä. Jos koodissa on virhe, sen huomaa paremmin sellainen henkilö, jonka ajatuskulut eivät liity ohjelmakoodin kirjoitukseen. Omille virheilleen tulee sokeaksi. 47 Weinbergin laki perustuu psykologian teoriaan, jonka mukaan ihmiset haluavat ennen kaikkea olla itselleen rehtejä. Vaikeiden virheiden löytyminen vaatisi ratkaisusta poikkeavaa ajatuskulkua. Koska ulkopuolinen ei ole tehnyt ratkaisua, hänen ajatuskulkunsa poikkeaa ratkaisusta. 48 8

9 4.8. Pareto-Zipf -tyyppiset lait Arviolta 80% virheistä esiintyy 20% moduuleista. Pareto-Zipf lait tunnetaan paremmin tuttuna sääntönä. Laki esiintyy myös muussa tieteessä. Esimerkiksi kielitieteessä sääntö selittää sanojen frekvenssejä. Taloustietissä sääntö selittää tulojakaumia. Pareto-Zipf -lakien taustaa sääntö esiintyy lähes kaikkialla ohjelmistotekniikassa: 80% virheistä on 20% moduuleista. 80% suoritusajasta kulutetaan 20% moduuleista. 80% viittauksista tehdään 20% moduuleihin. 80% käyttäjistä käyttää 20% ohjelman ominaisuuksista Pareto-Zipf -lakien perusteluja Pareto-Zipf lakien perusteluja 2 Endres (yksi oppikirjan kirjoittajista) teki tutkimuksen ohjelmistojen virheistä Hän tutki DOS/VS käyttöjärjestelmää. Järjestelmästä löytyi 740 ongelmaa, joista 430 tulkittin virheiksi. Virheet löydettiin testattaessa noin 500 käyttöjärjestelmän moduulia. Endresin tutkimuksen tulokset olivat: Yli puolet virheistä oli vaatimusmäärittelyja suunnitteluvirheitä. Arviolta 80% virheistä oli 20% moduuleista Arviolta 85% virheistä koski yhtä moduulia. Pienten moduulien virhetiheys oli suurten moduulien virhetiheyttä suurempi. Koodin muuttaminen oli virhealttiimpaa kuin uuden koodin kirjoittaminen Pareto-Zipf -lakien teoria 4.9. Hamletin hypoteesi Pareto-Zipf lait tuntuvat esiintyvän jatkuvasti ohjelmistotekniikassa ja tietojenkäsittelytieteessä sääntöjen tapauksissa aineisto on jakautunut mitattavan suureen suhteen logaritmisesti. Ei ole selvää, miksi useat aineistot käyttäytyvät näin. Epäilyihin perustuva testaus voi olla useimpia muita testaustapoja tehokkaampi. Toistaiseksi testauksen lait ovat olleet aika negatiivisia. Hamletin hypoteesi ei ole. Epäilyihin (suspicion) perustuva testaus kohdistaa testit niihin osiin ohjelmaa, joissa virheitä uskotaan olevan entien. Hypoteesiin sopii myös Pareto-Zipf laki

10 Hamletin hypoteesin taustaa Testauksen tarkoituksena on löytää virheitä. Oppikirjan mukaan sellainen testitapaus, joka ei paljasta virhettä, on resurssien tuhlausta. (Luennoijana olen eri mieltä asiasta. Jo testattua asiaa testaava testitapaus on resurssien tuhlausta. Toimiva uusi testitapaus ei sitä ole.) Hamletin hypoteesin taustaa 2 Testaus on sekä kallista että vaikeaa. Toteutuessaan Hamletin hypoteesi antaisi sellaisen testausstrategian, jonka avulla riittävän kattava testaus voidaan tehdä vähemmillä resursseilla. Valitettavasti Hamletin hypoteesi ei ole laki. Varmoja empiirisiä todisteita hypoteesin oikeudesta ei vielä ole Hamletin hypoteesin perusteluja Pelkkä moduulien rakenne ei yksin kerro virheistä, vaan muutakin tietoa voidaan käyttää testattaessa hyväksi: ohjelmoijien kokemusta (kokemattomien koodiin enemmän testausta), tilastotietoa virheiden jakaumista, tietoja moduulien tarkastushistoriasta, tietoja tehdyistä muutoksista, ohjelmoijan omaa arviota moduuleista. Hamletin hypoteesin perusteluja 2 Edellä listattuja ominaisuuksia voidaan käyttää täsmäaseena etsimään virheitä. Pitää kuitenkin muistaa, että virheitä on muuallakin kuin epäilyttävissä ohjelman osissa. Vaikka 80% virheistä löytyisi epäilystrategialla, jäljellä on vielä 20% virheistä (Pareto-Zipf laki) Esiteltyjen lakien seurauksia Esiteltyjen lakien seurauksia 2 Tarkastukset ovat tehokas keino havaita virheitä aikaisessa vaiheessa. Faganin, Porter-Vottanin ja Basilin lait johtavat tähän tulokseen. Tulokset pätevät osittain myös muihin vähemmän muodollisiin katselmointitekniikohin, kuten koodin läpikäyntiin (walkthrough) tai tekniikkapalaveriin. Katselmointi: tilaisuus, missä kaksi tai useampi henkilö etsii samasta dokumentista vikoja. V&V-tekniikoita pitää käyttää rinnakkain. Ne eivät ole toisaan poissulkevia vaan antavat yhdessä parhaan tuloksen. Hetzel-Myersin, Djikstran ja Weinbergin lait johtavat tähän tulokseen. Lait sopivat myös ketterien prosessimallien parityöskentelyyn. Sekä pariohjelmointi että -testaus ovat katselmointeja, joten niihin voidaan soveltaa V&V:n lakeja

TARKASTUSMENETTELYT JA NIIDEN APUVÄLINETUKI

TARKASTUSMENETTELYT JA NIIDEN APUVÄLINETUKI TARKASTUSMENETTELYT JA NIIDEN APUVÄLINETUKI Vesa Tenhunen Tarkastusmenettelyt Keino etsiä puutteita ohjelmakoodeista, dokumenteista ym. ohjelmistoprosessissa syntyvästä materiaalista Voidaan käyttää kaikissa

Lisätiedot

Harjoitustyön testaus. Juha Taina

Harjoitustyön testaus. Juha Taina Harjoitustyön testaus Juha Taina 1. Johdanto Ohjelman teko on muutakin kuin koodausta. Oleellinen osa on selvittää, että ohjelma toimii oikein. Tätä sanotaan ohjelman validoinniksi. Eräs keino validoida

Lisätiedot

Menetelmäraportti Ohjelmakoodin tarkastaminen

Menetelmäraportti Ohjelmakoodin tarkastaminen Menetelmäraportti Ohjelmakoodin tarkastaminen Sisällysluettelo 1. Johdanto...3 2. Menetelmän kuvaus...4 2.1. Tarkastusprosessi...4 2.1.1. Suunnittelu...4 2.1.2. Esittely...5 2.1.3. Valmistautuminen...5

Lisätiedot

1. Johdanto. Empiirinen ohjelmistotutkimus. Empiirisen tutkimuksen perusta. Havainnot, laki, teoria. Havainto-laki-teoria

1. Johdanto. Empiirinen ohjelmistotutkimus. Empiirisen tutkimuksen perusta. Havainnot, laki, teoria. Havainto-laki-teoria 1. Johdanto Building software will always be hard. There is inherently no silver bullet. F. Brooks, 1987. Ohjelmisto- ja järjestelmätekniikka (software engineering, software systems engineering) määrittelevät,

Lisätiedot

Ohjelmiston testaus ja laatu. Ohjelmistotekniikka elinkaarimallit

Ohjelmiston testaus ja laatu. Ohjelmistotekniikka elinkaarimallit Ohjelmiston testaus ja laatu Ohjelmistotekniikka elinkaarimallit Vesiputousmalli - 1 Esitutkimus Määrittely mikä on ongelma, onko valmista ratkaisua, kustannukset, reunaehdot millainen järjestelmä täyttää

Lisätiedot

Katselmoinnit. review) Katselmoinnit (review( Mitä ovat katselmoinnit? Katselmoinnin määritelmä (IEEE 1988)

Katselmoinnit. review) Katselmoinnit (review( Mitä ovat katselmoinnit? Katselmoinnin määritelmä (IEEE 1988) Katselmoinnit Johdatus ohjelmistotekniikkaan Sami Kollanus 19.10.2004 Katselmoinnin määritelmä (IEEE 1988) An evaluation of software element(s) or projects status to ascertain discrepancies from planned

Lisätiedot

Ylläpidon merkitys. Ylläpidon lakien suhde ohjelmistotuotantoon. Ylläpidon osa-alueet. Ylläpidon lakien suhde ohjelmistotuotantoon 2

Ylläpidon merkitys. Ylläpidon lakien suhde ohjelmistotuotantoon. Ylläpidon osa-alueet. Ylläpidon lakien suhde ohjelmistotuotantoon 2 5. tarkoittaa niitä toimintoja, jotka tehdään ohjelmalle sen käyttöönoton jälkeen. on kallein työvaihe. Glassin mukaan 40-80% kustannuksista kuluu siihen. Kumma kyllä tätä ei ole listattu ylläpidon laeissa.

Lisätiedot

Katselmoinnin määritelmä. Katselmoinnit osa 1. ja vielä ajatuksia katselmoinneista. Katselmointi. Katselmointi, katselmus (review) IEEE Std

Katselmoinnin määritelmä. Katselmoinnit osa 1. ja vielä ajatuksia katselmoinneista. Katselmointi. Katselmointi, katselmus (review) IEEE Std Katselmoinnin määritelmä Katselmoinnit osa 1 Sami Kollanus 1.12.2006, katselmus (review) IEEE Std 1028-1988 Ohjelmiston osien tai projektin tilan arviointi (evaluation), jonka tarkoitus on tunnistaa tuotosten

Lisätiedot

Onnistunut Vaatimuspohjainen Testaus

Onnistunut Vaatimuspohjainen Testaus Onnistunut Vaatimuspohjainen Testaus Kari Alho Solution Architect Nohau Solutions, Finland Sisältö Mitä on vaatimuspohjainen testaus? Vaatimusten ymmärtämisen haasteet Testitapausten generointi Työkalujen

Lisätiedot

dokumentin aihe Dokumentti: Testausraportti_I1.doc Päiväys: Projekti : AgileElephant

dokumentin aihe Dokumentti: Testausraportti_I1.doc Päiväys: Projekti : AgileElephant AgilElephant Testausraportti I1 Tekijä: Petri Kalsi Omistaja: ElectricSeven Aihe: Testausraportti Sivu 1 / 5 Dokumentti Historia Muutoshistoria Revision Numero Revision Päiväys Yhteenveto muutoksista Revision

Lisätiedot

Convergence of messaging

Convergence of messaging Convergence of messaging Testaussuunnitelma The Converge Group: Mikko Hiipakka Anssi Johansson Joni Karppinen Olli Pettay Timo Ranta-Ojala Tea Silander Helsinki 20. joulukuuta 2002 HELSINGIN YLIOPISTO

Lisätiedot

tsoft Tarkastusmenettelyt ja katselmukset Johdanto Vesa Tenhunen 4.2.2004

tsoft Tarkastusmenettelyt ja katselmukset Johdanto Vesa Tenhunen 4.2.2004 Tarkastusmenettelyt ja katselmukset tsoft Vesa Tenhunen 4.2.2004 http://cs.joensuu.fi/tsoft/ Johdanto Yksi tärkeimmistä tekijöistä laadukkaiden ohjelmistojen tuottamisessa on puutteiden aikainen havaitseminen

Lisätiedot

Verifioinnin ja validoinnin ero. 7. Verifiointi ja validointi. Verifiointi- ja validointitekniikat. Verifiointi- ja validointitekniikat II

Verifioinnin ja validoinnin ero. 7. Verifiointi ja validointi. Verifiointi- ja validointitekniikat. Verifiointi- ja validointitekniikat II 7. Verifiointi ja validointi Verifiointi ja validointi (V&V) on ohjelmistotuotannon työvaihe, missä varmistetaan, että ohjelmisto täyttää sille asetetut implisiittiset ja eksplisiittiset vaatimukset ja

Lisätiedot

Testaus käsite. Sekalaista testausasiaa. Testauksen käsitteestä. Kattavuusmitat. Jos ajatellaan, että testaus = V&V, voidaan erottaa:

Testaus käsite. Sekalaista testausasiaa. Testauksen käsitteestä. Kattavuusmitat. Jos ajatellaan, että testaus = V&V, voidaan erottaa: Testaus käsite Sekalaista asiaa Sami Kollanus 15.11.2006 Jos ajatellaan, että = V&V, voidaan erottaa: Staattinen Dynaaminen Toisaalta voidaan määritellä Myersin (1979) mukaan: Testaus on ohjelman suoritusta,

Lisätiedot

Ohjelmistotuotanto, verifiointi ja validointi Syksy Verifioinnin ja validoinnin ero. 7. Verifiointi ja validointi

Ohjelmistotuotanto, verifiointi ja validointi Syksy Verifioinnin ja validoinnin ero. 7. Verifiointi ja validointi 7. Verifiointi ja validointi Verifiointi ja validointi (V&V) on ohjelmistotuotannon työvaihe, missä varmistetaan, että ohjelmisto täyttää sille asetetut implisiittiset ja eksplisiittiset vaatimukset ja

Lisätiedot

7. Verifiointi ja validointi

7. Verifiointi ja validointi 7. Verifiointi ja validointi Verifiointi ja validointi (V&V) on ohjelmistotuotannon työvaihe, missä varmistetaan, että ohjelmisto täyttää sille asetetut implisiittiset ja eksplisiittiset vaatimukset ja

Lisätiedot

Ohjelmistojen testaus

Ohjelmistojen testaus Ohjelmistojen testaus Juha Taina 1. Perusteet (P&Y:1-4) Kurinalainen insinöörityö sisältää suunnittelun ja rakentamisen lisäksi välttämättä tehtäviä, joiden tarkoitus on tunnistaa ja poistaa keskeneräisestä

Lisätiedot

Testausdokumentti. Kivireki. Helsinki Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos

Testausdokumentti. Kivireki. Helsinki Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Testausdokumentti Kivireki Helsinki 17.12.2007 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Kurssi 581260 Ohjelmistotuotantoprojekti (6 ov) Projektiryhmä Anu Kontio Ilmari

Lisätiedot

SEPA diary. Dokumentti: SEPA_diary_PK_HS.doc Päiväys: Projekti: AgileElephant Versio: V0.3

SEPA diary. Dokumentti: SEPA_diary_PK_HS.doc Päiväys: Projekti: AgileElephant Versio: V0.3 AgilElephant SEPA Diary Petri Kalsi 55347A Heikki Salminen 51137K Tekijä: Petri Kalsi Omistaja: ElectricSeven Aihe: PK&HS Sivu 1 / 7 Dokumenttihistoria Revisiohistoria Revision päiväys: 29.11.2004 Seuraavan

Lisätiedot

Ohjelmistoprosessit ja ohjelmistojen laatu Kevät Ohjelmistoprosessit ja ohjelmistojen laatu. Projektinhallinnan laadunvarmistus

Ohjelmistoprosessit ja ohjelmistojen laatu Kevät Ohjelmistoprosessit ja ohjelmistojen laatu. Projektinhallinnan laadunvarmistus LAADUNVARMISTUS 135 Projektinhallinnan laadunvarmistus Projektinhallinnan laadunvarmistus tukee ohjelmistoprojektien ohjaus- ja ylläpitotehtäviä. Projektinhallinnan laadunvarmistustehtäviin kuuluvat seuraavat:

Lisätiedot

TIE Ohjelmistojen testaus 2015 Harjoitustyö Vaiheet 1 ja 2. Antti Jääskeläinen Matti Vuori

TIE Ohjelmistojen testaus 2015 Harjoitustyö Vaiheet 1 ja 2. Antti Jääskeläinen Matti Vuori TIE-21204 Ohjelmistojen testaus 2015 Harjoitustyö Vaiheet 1 ja 2 Antti Jääskeläinen Matti Vuori Työn yleiset järjestelyt 14.9.2015 2 Valmistautuminen Ilmoittaudu kurssille Lue harjoitustyön nettisivut

Lisätiedot

Testaussuunnitelma. Pizzeria - Pitseria HAAGA-HELIA ammattikorkeakoulu Tietojenkäsittelyn koulutusohjelma. WebPizza

Testaussuunnitelma. Pizzeria - Pitseria HAAGA-HELIA ammattikorkeakoulu Tietojenkäsittelyn koulutusohjelma. WebPizza Testaussuunnitelma Pizzeria - Pitseria HAAGA-HELIA ammattikorkeakoulu Tietojenkäsittelyn koulutusohjelma Versio 1.0 Ehdotus Laatija Raine Kauppinen VERSIOHISTORIA Versionotyyppi Versio- Päiväys Tekijä

Lisätiedot

Dynaaminen analyysi IV

Dynaaminen analyysi IV Dynaaminen analyysi IV Luento 9 Antti-Pekka Tuovinen 16 April 2013 1 Tavoitteet Kokemusperäinen testitapausten suunnittelu Yhteenvetoa suunnittelutekniikoista 16 April 2013 2 1 Testitapausten kokemusperäinen

Lisätiedot

2. Vaatimusmäärittely. Kevät 2005 Empiirinen ohjelmistotutkimus / Taina. Kevät 2005 Empiirinen ohjelmistotutkimus / Taina

2. Vaatimusmäärittely. Kevät 2005 Empiirinen ohjelmistotutkimus / Taina. Kevät 2005 Empiirinen ohjelmistotutkimus / Taina 2. on ensimmäinen projektin osavaihe. Sitä pidetään myös tärkeimpänä vaiheena. Miksi? Ehkä seuraavat lait selittävät asiaa: Glass: huono vaatimusmäärittely on todennäköisin epäonnistuneen projektin syy.

Lisätiedot

58160 Ohjelmoinnin harjoitustyö

58160 Ohjelmoinnin harjoitustyö 58160 Ohjelmoinnin harjoitustyö Testaus 30.3.2009 Tuntiop. Sami Nikander sami.nikander@helsinki.fi 58160 Ohjelmoinnin harjoitustyö, Sami Nikander 30.3.2009 1 Testaus Ohjelman systemaattista tutkimista

Lisätiedot

Ohjelmiston testaus ja laatu. Testausmenetelmiä

Ohjelmiston testaus ja laatu. Testausmenetelmiä Ohjelmiston testaus ja laatu Testausmenetelmiä Testausmenetelmiä - 1 Testauksen menetelmien päälähestymistapoina ovat black-box testi testaaja ei voi tutkia lähdekoodia testaus perustuu sovellukselle suunnitteluvaiheessa

Lisätiedot

Tik-76.115 Tietojenkäsittelyopin ohjelmatyö Tietotekniikan osasto Teknillinen korkeakoulu. LiKe Liiketoiminnan kehityksen tukiprojekti

Tik-76.115 Tietojenkäsittelyopin ohjelmatyö Tietotekniikan osasto Teknillinen korkeakoulu. LiKe Liiketoiminnan kehityksen tukiprojekti Tik-76.115 Tietojenkäsittelyopin ohjelmatyö Tietotekniikan osasto Teknillinen korkeakoulu TESTIRAPORTTI LiKe Liiketoiminnan kehityksen tukiprojekti Versio: 1.1 Tila: hyväksytty Päivämäärä: 13.2.2001 Tekijä:

Lisätiedot

SEPA päiväkirja. BetaTeam. Juho Mäkinen, 57796V, Jari Leppä, 42710V, Versio Pvm Tekijä Kuvaus

SEPA päiväkirja. BetaTeam. Juho Mäkinen, 57796V, Jari Leppä, 42710V, Versio Pvm Tekijä Kuvaus SEPA päiväkirja BetaTeam Juho Mäkinen, 57796V, jvmakine@cc.hut.fi Jari Leppä, 42710V, jleppa@cc.hut.fi Versio Pvm Tekijä Kuvaus 0.1 10.11.2005 Juho Mäkinen Johdanto 1. 0.2 11.11.2005 J.Mäkinen, Käytäntöön

Lisätiedot

Dynaaminen analyysi IV Luento 6 Antti-Pekka Tuovinen

Dynaaminen analyysi IV Luento 6 Antti-Pekka Tuovinen Dynaaminen analyysi IV Luento 6 Antti-Pekka Tuovinen 23 April 2018 1 Tavoitteet Kokemusperäinen testitapausten suunnittelu Yhteenvetoa suunnittelutekniikoista 23 April 2018 2 Testitapausten kokemusperäinen

Lisätiedot

Projektinhallinnan merkitys

Projektinhallinnan merkitys 6. ei ole työvaihe, vaan se on läsnä koko tuotteen elinkaaren ajan. Se siirtää ohjausvastuun pois kehitystiimiltä. Työvaihe sisältää prosessin ohjaukseen liittyviä tehtäviä: koko- ja kustannusarviot, aikataulun

Lisätiedot

Virheiden etsintä: katselmoinnit vai testaaminen?

Virheiden etsintä: katselmoinnit vai testaaminen? hyväksymispäivä arvosana arvostelija Virheiden etsintä: katselmoinnit vai testaaminen? Timo Usenius Helsinki 10.11.2009 HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos HELSINGIN YLIOPISTO HELSINGFORS

Lisätiedot

Ohjelmistotuotantoprojekti

Ohjelmistotuotantoprojekti Ohjelmistotuotantoprojekti Ryhmä Muppett TESTAUSDOKUMENTTI Helsinki 5.8.2008 HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Ohjelmistotuotantoprojekti, kesä 2008 Projekti: Muutos- ja korjauspyyntöjen

Lisätiedot

Laatu ohjelmistotyössä

Laatu ohjelmistotyössä Laatu ohjelmistotyössä Laatuongelmia Budjetin ylitys Aikataulun viivästyminen Bugit lopputuotteessa Sädehoitokone Asiavirheet sisällössä Ylläpito-ongelmat Dokumentointi Arkkitehtuuri Sisäiset kustannukset

Lisätiedot

LAATU, LAADUNVARMISTUS JA f RISKIEN HALLINTA JOUNI HUOTARI ESA SALMIKANGAS PÄIVITETTY 18.1.2011

LAATU, LAADUNVARMISTUS JA f RISKIEN HALLINTA JOUNI HUOTARI ESA SALMIKANGAS PÄIVITETTY 18.1.2011 LAATU, LAADUNVARMISTUS JA f RISKIEN HALLINTA JOUNI HUOTARI ESA SALMIKANGAS PÄIVITETTY 18.1.2011 TEHTÄVÄ Määrittele laatu Mitä riskien hallintaan kuuluu? Jouni Huotari & Esa Salmikangas 2 LAATU JA LAADUNVARMISTUS

Lisätiedot

Kuopio Testausraportti Asiakkaat-osakokonaisuus

Kuopio Testausraportti Asiakkaat-osakokonaisuus Kuopio Testausraportti Asiakkaat-osakokonaisuus Kuopio, testausraportti, 25.3.2002 Versiohistoria: Versio Pvm Laatija Muutokset 0.1 11.2.2002 Matti Peltomäki Ensimmäinen versio 0.9 11.2.2002 Matti Peltomäki

Lisätiedot

Ohjelmiston testaus ja laatu. Testaus yleistä

Ohjelmiston testaus ja laatu. Testaus yleistä Ohjelmiston testaus ja laatu Testaus yleistä Määritelmä Testaus on systemaattinen lähestymistapa ohjelmistoissa esiintyvien virheiden löytämiseksi ohjelmaa suorittamalla. Testattaessa pyritään luomaan

Lisätiedot

Ohjelmistojen mallintaminen. Luento 11, 7.12.

Ohjelmistojen mallintaminen. Luento 11, 7.12. Ohjelmistojen mallintaminen Luento 11, 7.12. Viime viikolla... Oliosuunnittelun yleiset periaatteet Single responsibility eli luokilla vain yksi vastuu Program to an interface, not to concrete implementation,

Lisätiedot

Automaattinen yksikkötestaus

Automaattinen yksikkötestaus Teknillinen Korkeakoulu T-76.115 Tietojenkäsittelyopin ohjelmatyö Lineaaristen rajoitteiden tyydyttämistehtävän ratkaisija L models Automaattinen yksikkötestaus Ryhmä Rajoitteiset Versio Päivämäärä Tekijä

Lisätiedot

Sovellettu todennäköisyyslaskenta B

Sovellettu todennäköisyyslaskenta B Sovellettu todennäköisyyslaskenta B Antti Rasila 16. marraskuuta 2007 Antti Rasila () TodB 16. marraskuuta 2007 1 / 15 1 Epäparametrisia testejä χ 2 -yhteensopivuustesti Homogeenisuuden testaaminen Antti

Lisätiedot

Laadunvarmistuksen suunnitelma. Ryhmä ExtraTerrestriaLs Aureolis Oy

Laadunvarmistuksen suunnitelma. Ryhmä ExtraTerrestriaLs Aureolis Oy Laadunvarmistuksen suunnitelma Ryhmä ExtraTerrestriaLs Aureolis Oy Versi Päiväys Tekijä Kuvaus o 1.0 8.11.2004 Risto Kunnas Ensimmäinen versio 1.1 8.11.2004 Risto Kunnas Korjauksia 1.2 9.11.2004 Mika Suvanto

Lisätiedot

T Testiraportti - integraatiotestaus

T Testiraportti - integraatiotestaus T-76.115 Testiraportti - integraatiotestaus 16. huhtikuuta 2002 Confuse 1 Tila Versio: 1.1 Tila: Päivitetty Jakelu: Julkinen Luotu: 19.03.2002 Jani Myyry Muutettu viimeksi: 16.04.2002 Jani Myyry Versiohistoria

Lisätiedot

Good Minton QA Raportti Iteraatio 1 Sulkapalloliiton Kilpailujärjestelmä

Good Minton QA Raportti Iteraatio 1 Sulkapalloliiton Kilpailujärjestelmä Good Minton QA Raportti Iteraatio 1 Sulkapalloliiton Kilpailujärjestelmä Versiohistoria: Versio: Pvm: Laatijat: Muutokset: 0.1 2006 12 09 Jani Eränen Alustava DOKUMENTIN TILA: Alustava Valmis Tarkastettu

Lisätiedot

10. Tarkastukset. Tarkastusten rakenne

10. Tarkastukset. Tarkastusten rakenne 10. Tarkastukset Tarkastus (inspection) on tehokas analyysitekniikka, jota voidaan käyttää minkä tahansa projektin tuotoksen läpikäyntiin. Tarkastus on systemaattinen ja yksityiskohtainen katselmointi

Lisätiedot

Tarkastusten rakenne. 10. Tarkastukset. Tuotoksen tekijän rooli. Tarkastustiimi. Tarkastusprosessin vaiheet. Tarkastusprosessi

Tarkastusten rakenne. 10. Tarkastukset. Tuotoksen tekijän rooli. Tarkastustiimi. Tarkastusprosessin vaiheet. Tarkastusprosessi 10. Tarkastukset Tarkastus (inspection) on tehokas analyysitekniikka, jota voidaan käyttää minkä tahansa projektin tuotoksen läpikäyntiin. Tarkastus on systemaattinen ja yksityiskohtainen katselmointi

Lisätiedot

Testausraportti. Orava. Helsinki Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos

Testausraportti. Orava. Helsinki Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Testausraportti Orava Helsinki 5.5.2005 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Kurssi 581260 Ohjelmistotuotantoprojekti (6 ov) Projektiryhmä Juhani Bergström Peter

Lisätiedot

Testaussuunnitelma Labra

Testaussuunnitelma Labra Testaussuunnitelma Labra Helsinki 25.8.2008 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos 1 Kurssi 581260 Ohjelmistotuotantoprojekti (9+1op) Projektiryhmä Anssi Kapanen,

Lisätiedot

Laadunvarmistuksen suunnitelma. Ryhmä ExtraTerrestriaLs Aureolis Oy

Laadunvarmistuksen suunnitelma. Ryhmä ExtraTerrestriaLs Aureolis Oy Laadunvarmistuksen suunnitelma Ryhmä ExtraTerrestriaLs Aureolis Oy Versio Päiväys Tekijä Kuvaus 1.0 8.11.2004 Risto Kunnas Ensimmäinen versio 1.1 8.11.2004 Risto Kunnas Korjauksia 1.2 9.11.2004 Mika Suvanto

Lisätiedot

Mihin kaikkeen voit törmätä testauspäällikön saappaissa?

Mihin kaikkeen voit törmätä testauspäällikön saappaissa? Mihin kaikkeen voit törmätä testauspäällikön saappaissa? Arto Stenberg Copyright Kuntien Tiera Oy Kuntien Tiera Copyright Kuntien Tiera Oy Tiera on vuonna 2010 perustettu yli 200:n kuntatoimijan omistama

Lisätiedot

Yksikkötestaus. Kattava testaus. Moduulitestaus. Ohjelman testaus. yksikkotestaus/ Seija Lahtinen

Yksikkötestaus. Kattava testaus. Moduulitestaus. Ohjelman testaus. yksikkotestaus/ Seija Lahtinen Yksikkötestaus Kattava testaus Moduulitestaus Ohjelman testaus 1 Kattava testaus Testauksen perimmäinen tarkoitus on LÖYTÄÄ VIRHEITÄ Testaus pitäisi olla täydellinen: - Jokainen pyydetty arvo pitäisi testata

Lisätiedot

Mihin kaikkeen voit törmätä testauspäällikön saappaissa?

Mihin kaikkeen voit törmätä testauspäällikön saappaissa? Mihin kaikkeen voit törmätä testauspäällikön saappaissa? Arto Stenberg Copyright Kuntien Tiera Oy Kuntien Tiera Copyright Kuntien Tiera Oy Tieran toiminta perustuu osaamisverkoston rakentamiseen, mikä

Lisätiedot

TESTIRAPORTTI - VYM JA KANTA Virtuaaliyhteisöjen muodostaminen Versio 1.0

TESTIRAPORTTI - VYM JA KANTA Virtuaaliyhteisöjen muodostaminen Versio 1.0 TESTIRAPORTTI - VYM JA KANTA Versio 1.0 i Sisällysluettelo 1. YLEISTÄ 2 1.1. Dokumentin tarkoitus ja yleisiä toimintaohjeita 2 1.2. Viittaukset muihin dokumentteihin 2 2. SUORITETTAVA TESTI 3 2.1. Testauksen

Lisätiedot

Kehittää ohjelmointitehtävien ratkaisemisessa tarvittavia metakognitioita!

Kehittää ohjelmointitehtävien ratkaisemisessa tarvittavia metakognitioita! Kehittää ohjelmointitehtävien ratkaisemisessa tarvittavia metakognitioita! eli... Hyvä kaava sanoo enemmän kuin,... tuhat riviä koodia!... sata riviä tekstiä!... kymmenen diagrammia! YLEISTÄ FORMAALEISTA

Lisätiedot

Käyttäjien tunnistaminen ja käyttöoikeuksien hallinta hajautetussa ympäristössä

Käyttäjien tunnistaminen ja käyttöoikeuksien hallinta hajautetussa ympäristössä www.niksula.cs.hut.fi/~jjkankaa// Testauksen loppuraportti v. 1.0 Päivitetty 23.4.2001 klo 19:05 Mikko Viljainen 2 (14) Dokumentin versiohistoria Versio Päivämäärä Tekijä / muutoksen tekijä Selite 1.0

Lisätiedot

T Testiraportti - järjestelmätestaus

T Testiraportti - järjestelmätestaus T-76.115 Testiraportti - järjestelmätestaus 18. huhtikuuta 2002 Confuse 1 Tila Versio: 1.0 Tila: Päivitetty Jakelu: Julkinen Luotu: 18.04.2002 Jani Myyry Muutettu viimeksi: 18.04.2002 Jani Myyry Versiohistoria

Lisätiedot

T Johdatus käyttäjäkeskeiseen tuotekehitykseen. suunnitteluprosessissa. Käyttäjän huomiointi. Iteroitu versio paljon kirjoitusvirheitä

T Johdatus käyttäjäkeskeiseen tuotekehitykseen. suunnitteluprosessissa. Käyttäjän huomiointi. Iteroitu versio paljon kirjoitusvirheitä Käyttäjäkeskeinen suunnittelu Käyttäjän huomiointi suunnitteluprosessissa Iteroitu versio 1.1 muutettu klo12.10 - paljon kirjoitusvirheitä Käyttäjäkeskeinen suunnittelu Perusidea: käyttäjät huomioidaan

Lisätiedot

Käyttäjäkeskeinen suunnittelu

Käyttäjäkeskeinen suunnittelu Käyttäjäkeskeinen suunnittelu Käyttäjän huomiointi suunnitteluprosessissa Iteroitu versio 1.1 muutettu klo12.10 - paljon kirjoitusvirheitä Käyttäjäkeskeinen suunnittelu Perusidea: käyttäjät huomioidaan

Lisätiedot

Testaussuunnitelma. Oppimistavoitteiden hallintajärjestelmä harri

Testaussuunnitelma. Oppimistavoitteiden hallintajärjestelmä harri Testaussuunnitelma Oppimistavoitteiden hallintajärjestelmä harri Helsinki 15.11.2007 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Kurssi 581260 Ohjelmistotuotantoprojekti

Lisätiedot

Testaaminen ohjelmiston kehitysprosessin aikana

Testaaminen ohjelmiston kehitysprosessin aikana Testaaminen ohjelmiston kehitysprosessin aikana 04.02.2004 http://cs.joensuu.fi/tsoft/ Sisällys 1. Johdanto 2. Yksikkö- ja integrointitestaus 3. Järjestelmätestaus 4. Hyväksymistestaus http://cs.joensuu.fi/tsoft/

Lisätiedot

Versio Päiväys Tekijä Kuvaus Tikkanen varsinainen versio

Versio Päiväys Tekijä Kuvaus Tikkanen varsinainen versio Testiraportti 26.2.2006 1/5 - Noheva II Testiraportti Versio Päiväys Tekijä Kuvaus 1.0 26.2.2006 Tikkanen varsinainen versio 1 Yleistä Toteutusvaiheen 2 virallinen testaus on muodostunut automaattisista

Lisätiedot

Lohtu-projekti. Testaussuunnitelma

Lohtu-projekti. Testaussuunnitelma Lohtu-projekti Testaussuunnitelma Versiohistoria: 1.0 19.2.2003 1. versio Mari 1.1 20.2.2003 Muutoksia Mari 1.2 25.2.2003 Katselmoinnissa esiin tulleet Mari muutokset 1.3 17.3.2003 2. syklissä tehtävät

Lisätiedot

SEPA: Staattiset menetelmät Timo Sallinen, 51134F & Risto Kunnas, 50498T. Sisällysluettelo. 1 Johdanto. 2 SEPA harjoittelu käytännössä.

SEPA: Staattiset menetelmät Timo Sallinen, 51134F & Risto Kunnas, 50498T. Sisällysluettelo. 1 Johdanto. 2 SEPA harjoittelu käytännössä. Sivu 1 (5) SEPA: Staattiset menetelmät Timo Sallinen, 51134F & Risto Kunnas, 50498T Versio Päiväys Tekijä Kuvaus 0.1 27.10.2004 Timo Sallinen Ensimmäinen versio 1.0 31.10.2004 Timo Sallinen Korjauksia,

Lisätiedot

CT60A4150 OHJELMISTOTESTAUKSEN PERUSTEET. Jussi Kasurinen (etu.suku@lut.fi) Kevät 2016

CT60A4150 OHJELMISTOTESTAUKSEN PERUSTEET. Jussi Kasurinen (etu.suku@lut.fi) Kevät 2016 CT60A4150 OHJELMISTOTESTAUKSEN PERUSTEET Jussi Kasurinen (etu.suku@lut.fi) Kevät 2016 VIIME KERRALLA MENETELMIÄ Musta laatikko Valkea laatikko Harmaa laatikko Regressio Automaatio Rasitus (kuormitus)

Lisätiedot

Testauksen tuki nopealle tuotekehitykselle. Antti Jääskeläinen Matti Vuori

Testauksen tuki nopealle tuotekehitykselle. Antti Jääskeläinen Matti Vuori Testauksen tuki nopealle tuotekehitykselle Antti Jääskeläinen Matti Vuori Mitä on nopeus? 11.11.2014 2 Jatkuva nopeus Läpäisyaste, throughput Saadaan valmiiksi tasaiseen, nopeaan tahtiin uusia tuotteita

Lisätiedot

Tutkittua tietoa. Tutkittua tietoa 1

Tutkittua tietoa. Tutkittua tietoa 1 Tutkittua tietoa T. Dybå, T. Dingsøyr: Empirical Studies of Agile Software Development : A Systematic Review. Information and Software Technology 50, 2008, 833-859. J.E. Hannay, T. Dybå, E. Arisholm, D.I.K.

Lisätiedot

WCLIQUE. Ohjelmistoprojekti. Testaussuunnitelma

WCLIQUE. Ohjelmistoprojekti. Testaussuunnitelma TKK/DISKO/Tik-76.115 WCLIQUE Projektiryhmä Clique http://www.hut.fi/jekahkon/wclique/testplan.html WCLIQUE Ohjelmistoprojekti Projektiryhmä Clique: Janne Dufva, 75008T, email: janne.dufva@nokia.com, 75014C,

Lisätiedot

Siis mikä suunnittelun haastavuus ja ristiriitaisuus? Suunnittelun työvaiheet. Suunnittelun lait ja hypoteesit

Siis mikä suunnittelun haastavuus ja ristiriitaisuus? Suunnittelun työvaiheet. Suunnittelun lait ja hypoteesit 3. on teknisesti kaikkein haastavin ja luonteeltaan kaikkein ristiriitaisin työvaihe. Miksi? Curtis: Hyvä suunnittelu vaatii syvällistä tuotteen sovellusalueen hallintaa. Dyer: Siirtyminen vaatimusmäärittelystä

Lisätiedot

Testaus-tietoisku: Tärkeimpiä asioita testauksesta projektityökurssilaisille

Testaus-tietoisku: Tärkeimpiä asioita testauksesta projektityökurssilaisille 1(23) Testaus-tietoisku: Tärkeimpiä asioita testauksesta projektityökurssilaisille Matti Vuori, Tampereen teknillinen yliopisto 30.10.2012 Sisällysluettelo 1/2 Esityksen tarkoitus 4 Laatu on tärkeää, ei

Lisätiedot

Testaussuunnitelma PULSU. Syksy 2008 Ohjelmistotuotantoprojekti. HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos

Testaussuunnitelma PULSU. Syksy 2008 Ohjelmistotuotantoprojekti. HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Testaussuunnitelma PULSU Syksy 2008 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Kurssi 581260 Ohjelmistotuotantoprojekti (9 op) Projektiryhmä Heikki Manninen Noora Joensuu

Lisätiedot

Ohjelmistotuotanto s

Ohjelmistotuotanto s Laadunvarmistustekniikoita Ohjelmistotuotanto 1 testaus (testing) ohjelman suorittamista tarkoituksena löytää virheitä tarkastukset (inspections, reviews) asiantuntijoiden suorittamia dokumentin (voi olla

Lisätiedot

Ohjelmistoprosessit ja ohjelmistojen laatu Ohjelmistoprosessit ja ohjelmistojen laatu (4op)

Ohjelmistoprosessit ja ohjelmistojen laatu Ohjelmistoprosessit ja ohjelmistojen laatu (4op) 581361 Ohjelmistoprosessit ja ohjelmistojen laatu (4op) Ohjelmistojärjestelmien syventävien opintojen kurssi Myös ohjelmistotekniikan profiilin pakollinen kurssi eli ohjelmistotekniikka-aiheisen gradun

Lisätiedot

Onnistunut SAP-projekti laadunvarmistuksen keinoin

Onnistunut SAP-projekti laadunvarmistuksen keinoin Onnistunut SAP-projekti laadunvarmistuksen keinoin 07.10.2010 Patrick Qvick Sisällys 1. Qentinel 2. Laadukas ohjelmisto täyttää sille asetetut tarpeet 3. SAP -projektin kriittisiä menestystekijöitä 4.

Lisätiedot

Testausprosessin vaatimukset. 2. Testausprosessi (Artikkelit) Vesiputousmallin ongelmia. V-mallin neljä osavaihetta. Testausprosessimalli V-malli

Testausprosessin vaatimukset. 2. Testausprosessi (Artikkelit) Vesiputousmallin ongelmia. V-mallin neljä osavaihetta. Testausprosessimalli V-malli 2. ausprosessi (Artikkelit) Nykyisin useimpien prosessimallien lähtökohta on, että testaus on oleellinen osa ohjelmistotuotantoprosessia. Itse asiassa huolellinen testaus vie helposti 50% tai enemmän käytettävistä

Lisätiedot

SYSTEEMITYÖ. Tärkeitä sanoja

SYSTEEMITYÖ. Tärkeitä sanoja SYSTEEMITYÖ Tärkeitä sanoja SYSTEEMITYÖN TÄRKEITÄ SANOJA Laatu (itse tuotteessa ja sen tekemisessä) Dokumentaatio Riskienhallinta Vaatimustenhallinta Uudelleenkäytettävyys Versionhallinta 2 LAATU Parityönä:

Lisätiedot

Laadunvarmistustekniikat

Laadunvarmistustekniikat Laadunvarmistustekniikat Ohjelmistojen laadunvarmistustekniikoita: testaus (testing) ohjelman suorittamista tarkoituksena löytää virheitä tarkastukset (inspections, reviews) asiantuntijoiden suorittamia

Lisätiedot

Ohjelmiston testaus ja laatu. Testaustasot

Ohjelmiston testaus ja laatu. Testaustasot Ohjelmiston testaus ja laatu Testaustasot Testauksen vaihejako Tarpeet / sopimus Järjestelmätestaus Hyväksymiskoe Määrittely testauksen suunnittelu ja tulosten verifiointi Arkkitehtuurisuunnittelu Moduulisuunnittelu

Lisätiedot

2. TILASTOLLINEN TESTAAMINEN...

2. TILASTOLLINEN TESTAAMINEN... !" # 1. 1. JOHDANTO... 3 2. 2. TILASTOLLINEN TESTAAMINEN... 4 2.1. T-TESTI... 4 2.2. RANDOMISAATIOTESTI... 5 3. SIMULOINTI... 6 3.1. OTOSTEN POIMINTA... 6 3.2. TESTAUS... 7 3.3. TESTIEN TULOSTEN VERTAILU...

Lisätiedot

T Tietojenkäsittelyopin ohjelmatyö. Testiraportti, vaihe T1. Tietokonegrafiikka-algoritmien visualisointi. Testiraportti, vaihe T1

T Tietojenkäsittelyopin ohjelmatyö. Testiraportti, vaihe T1. Tietokonegrafiikka-algoritmien visualisointi. Testiraportti, vaihe T1 T-76.115 Tietojenkäsittelyopin ohjelmatyö Sisältö Tästä dokumentista ilmenee T1-vaiheessa suoritettu testaus, sen tulokset ja poikkeamat testisuunnitelmasta. Päivämäärä 1.12.2002 Projektiryhmä Keimo keimo-dev@list.hut.fi

Lisätiedot

Testaussuunnitelma. PUSU-ryhmä. Helsinki Ohjelmistotuotantoprojekti. HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos

Testaussuunnitelma. PUSU-ryhmä. Helsinki Ohjelmistotuotantoprojekti. HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Testaussuunnitelma PUSU-ryhmä Helsinki 13.12.2007 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Kurssi 581260 Ohjelmistotuotantoprojekti (9 op) Projektiryhmä Jussi Hynninen

Lisätiedot

Mallintarkistus ja sen

Mallintarkistus ja sen VERSIO 0.1 LUONNOS Mallintarkistus ja sen soveltaminen PLCohjelmien verifioinnissa AS-0.3200 Automaatio- ja systeemitekniikan projektityöt -projektisuunnitelma Markus Hartikainen 2/1/2009 Sisältö 1. Projektityön

Lisätiedot

Menetelmäraportti - Konfiguraationhallinta

Menetelmäraportti - Konfiguraationhallinta Menetelmäraportti - Konfiguraationhallinta Päiväys Tekijä 22.03.02 Ville Vaittinen Sisällysluettelo 1. Johdanto... 3 1.1 Tärkeimmät lyhenteet... 3 2. Konfiguraationhallinnan tärkeimmät välineet... 4 2.1

Lisätiedot

LAATURAPORTTI Iteraatio 1

LAATURAPORTTI Iteraatio 1 LAATURAPORTTI Iteraatio 1 LAATURAPORTTI 2 (7) VERSION HALLINTA Versio Päivä Tekijä Kuvaus 0.1 9.12.2006 Kaarlo Lahtela Ensimmäinen versio 0.2 Kaarlo Lahtela Korjauksia 1.0 Lauri Kiiski Katselmointi ja

Lisätiedot

TIE Ohjelmistojen testaus 2016 Harjoitustyö Vaiheet 1 ja 2. Antti Jääskeläinen Matti Vuori

TIE Ohjelmistojen testaus 2016 Harjoitustyö Vaiheet 1 ja 2. Antti Jääskeläinen Matti Vuori TIE-21201 Ohjelmistojen testaus 2016 Harjoitustyö Vaiheet 1 ja 2 Antti Jääskeläinen Matti Vuori Työn yleiset järjestelyt 20.9.2016 2 Valmistautuminen Ilmoittaudu kurssille Lue harjoitustyön nettisivut

Lisätiedot

Testausdokumentti. Sivu: 1 / 10. Ohjelmistotuotantoprojekti Sheeple Helsingin yliopisto. Versiohistoria

Testausdokumentti. Sivu: 1 / 10. Ohjelmistotuotantoprojekti Sheeple Helsingin yliopisto. Versiohistoria Sivu: 1 / 10 Testausdokumentti Ohjelmistotuotantoprojekti Sheeple Helsingin yliopisto Versiohistoria Versio Päivitykset 0.4 Lisätty mod_form.php -tiedostoon liittyvät testit 0.5 Lisätty johdanto 1.0 Dokumentti

Lisätiedot

Testauspäällikön tarinoita Arto Stenberg

Testauspäällikön tarinoita Arto Stenberg Testauspäällikön tarinoita Arto Stenberg 2.12.2013 A software foundry that helps companies create breakthrough product innovations. We help our clients to: 1. Create new products 2. Scale out their product

Lisätiedot

Kontrollipolkujen määrä

Kontrollipolkujen määrä Testaus Yleistä Testaus on suunnitelmallista virheiden etsimistä Tuotantoprosessissa ohjelmaan jää aina virheitä, käytettävistä menetelmistä huolimatta Hyvät menetelmät, kuten katselmoinnit pienentävät

Lisätiedot

Ohjelmistojen suunnittelu

Ohjelmistojen suunnittelu Ohjelmistojen suunnittelu 581259 Ohjelmistotuotanto 154 Ohjelmistojen suunnittelu Software design is a creative activity in which you identify software components and their relationships, based on a customer

Lisätiedot

Yhtälönratkaisusta. Johanna Rämö, Helsingin yliopisto. 22. syyskuuta 2014

Yhtälönratkaisusta. Johanna Rämö, Helsingin yliopisto. 22. syyskuuta 2014 Yhtälönratkaisusta Johanna Rämö, Helsingin yliopisto 22. syyskuuta 2014 Yhtälönratkaisu on koulusta tuttua, mutta usein sitä tehdään mekaanisesti sen kummempia ajattelematta. Jotta pystytään ratkaisemaan

Lisätiedot

Testauksen hallinta Testaustyökalut Luento 7 Antti-Pekka Tuovinen

Testauksen hallinta Testaustyökalut Luento 7 Antti-Pekka Tuovinen Testauksen hallinta Testaustyökalut Luento 7 Antti-Pekka Tuovinen 23 April 2018 1 Tavoitteet Yleiskuva seuraavista aiheista Testauksen organisointi Testaussuunnittelma Testauksen kustannukset Testausstrategia

Lisätiedot

Testaussuunnitelma. Asdf. Helsinki Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos

Testaussuunnitelma. Asdf. Helsinki Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Testaussuunnitelma Asdf Helsinki 22.2.2008 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Kurssi 581260 Ohjelmistotuotantoprojekti (6 ov) Projektiryhmä Kuisma Sami Louhio

Lisätiedot

Miten selvitä matematiikasta? Tutkitusti hyviä opiskelutaitovinkkejä

Miten selvitä matematiikasta? Tutkitusti hyviä opiskelutaitovinkkejä Miten selvitä matematiikasta? Tutkitusti hyviä opiskelutaitovinkkejä Panu Erästö Matemaatikko-tilastotieteilijä (Ph.D) Opettaja/pedagogi/opetuksen kehittäjä Kaikilla on edellytykset Usko omiin kykyihin

Lisätiedot

Mat Tilastollisen analyysin perusteet, kevät 2007

Mat Tilastollisen analyysin perusteet, kevät 2007 Mat-2.2104 Tilastollisen analyysin perusteet, kevät 2007 2. luento: Tilastolliset testit Kai Virtanen 1 Tilastollinen testaus Tutkimuksen kohteena olevasta perusjoukosta esitetään väitteitä oletuksia joita

Lisätiedot

KÄYTETTÄVYYSTESTAUS OSANA KETTERÄÄ KEHITYSTÄ

KÄYTETTÄVYYSTESTAUS OSANA KETTERÄÄ KEHITYSTÄ KÄYTETTÄVYYSTESTAUS OSANA KETTERÄÄ KEHITYSTÄ Eeva Kangas 05.11.2015 @FixUi Oy 2013 2015 FIXUI "Autamme yrityksiä suunnittelemaan sellaisia tuotteita, joita ihmiset osaavat ja haluavat käyttää" Käyttäjätutkimukset

Lisätiedot

Ohjelmoinnin perusteet Y Python

Ohjelmoinnin perusteet Y Python Ohjelmoinnin perusteet Y Python T-106.1208 2.3.2011 T-106.1208 Ohjelmoinnin perusteet Y 2.3.2011 1 / 39 Kertausta: tiedoston avaaminen Kun ohjelma haluaa lukea tai kirjoittaa tekstitiedostoon, on ohjelmalle

Lisätiedot

7. Tutkimuksen teko. Kevät 2005 Empiirinen ohjelmistotutkimus / Taina. Kevät 2005 Empiirinen ohjelmistotutkimus / Taina

7. Tutkimuksen teko. Kevät 2005 Empiirinen ohjelmistotutkimus / Taina. Kevät 2005 Empiirinen ohjelmistotutkimus / Taina 7. 7.1. Johdanto Tämä luku perustuu kirjaan C. Wohlin et al., Experimentation in Software Engineering, An Introduction, Kluwer Academic Publishers, 2000. ISBN 0-7923-8682-5. Tähän asti olemme käsitelleet

Lisätiedot

TIE-21200 Ohjelmistojen testaus Harjoitustyön esittely osa 2: Vaiheet 3 & 4. Antti Jääskeläinen Matti Vuori

TIE-21200 Ohjelmistojen testaus Harjoitustyön esittely osa 2: Vaiheet 3 & 4. Antti Jääskeläinen Matti Vuori TIE-21200 Ohjelmistojen testaus Harjoitustyön esittely osa 2: Vaiheet 3 & 4 Antti Jääskeläinen Matti Vuori Vaiheet 3 & 4: Järjestelmätestaus 27.10.2014 2 Päämäärä jedit-ohjelmointieditorin järjestelmätestaus

Lisätiedot

TIE-21200 Ohjelmistojen testaus Harjoitustyön esittely osa 2: Vaiheet 3 & 4. Antti Jääskeläinen Matti Vuori

TIE-21200 Ohjelmistojen testaus Harjoitustyön esittely osa 2: Vaiheet 3 & 4. Antti Jääskeläinen Matti Vuori TIE-21200 Ohjelmistojen testaus Harjoitustyön esittely osa 2: Vaiheet 3 & 4 Antti Jääskeläinen Matti Vuori Vaiheet 3 & 4: Järjestelmätestaus 28.10.2013 2 Päämäärä jedit-ohjelmointieditorin järjestelmätestaus

Lisätiedot

Testausraportti. Oppimistavoitteiden hallintajärjestelmä harri

Testausraportti. Oppimistavoitteiden hallintajärjestelmä harri Testausraportti Oppimistavoitteiden hallintajärjestelmä harri Helsinki 13.12.2007 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Kurssi 581260 Ohjelmistotuotantoprojekti

Lisätiedot

HY / Matematiikan ja tilastotieteen laitos Johdatus logiikkaan I, syksy 2018 Harjoitus 5 Ratkaisuehdotukset

HY / Matematiikan ja tilastotieteen laitos Johdatus logiikkaan I, syksy 2018 Harjoitus 5 Ratkaisuehdotukset HY / Matematiikan ja tilastotieteen laitos Johdatus logiikkaan I, syksy 2018 Harjoitus 5 Ratkaisuehdotukset 1. Päättele resoluutiolla seuraavista klausuulijoukoista: (a) {{p 0 }, {p 1 }, { p 0, p 2 },

Lisätiedot

Laatukustannukset. Laadun hallinta. Laadun kustannuksista

Laatukustannukset. Laadun hallinta. Laadun kustannuksista Laatukustannukset Laadun hallinta Sami Kollanus TJTA330 Ohjelmistotuotanto 13.2.2007 US National Institute of Standards and Technology: Riittämättömän testauksen kustannusten arvioitiin olevan 59 Mrd dollaria

Lisätiedot

Avainsanojen poimiminen Eeva Ahonen

Avainsanojen poimiminen Eeva Ahonen Avainsanojen poimiminen 5.10.2004 Eeva Ahonen Sisältö Avainsanat Menetelmät C4.5 päätöspuut GenEx algoritmi Bayes malli Testit Tulokset Avainsanat Tiivistä tietoa dokumentin sisällöstä ihmislukijalle hakukoneelle

Lisätiedot