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

Koko: px
Aloita esitys sivulta:

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

Transkriptio

1 1. Johdanto Building software will always be hard. There is inherently no silver bullet. F. Brooks, Ohjelmisto- ja järjestelmätekniikka (software engineering, software systems engineering) määrittelevät, miten tietokonepohjaisia järjestelmiä (systems) ja niiden ohjelmistoja (software) tulisi toteuttaa. Ohjelmistojen tekeminen on riittävän vaikeaa, ilman että toistetaan jo todettuja virheitä ja keksitään samat asiat moneen kertaan. Empiirinen ohjelmistotutkimus 1 Empiirinen ohjelmistotutkimus 40 vuoden aikana ohjelmistotekniikassa on löydetty paljon käytännössä toimivia periaatteita: ns hyviksi havaittuja menetelmiä (best practices). Empiirisen ohjelmistotutkimuksen (Empirical software engineering, EOT) tavoitteena on validoida (varmentaa), millä reunaehdoilla käytetyt menetelmät toimivat. Empiirinen ohjelmistotutkimus 2 Empiirisen tutkimuksen perusta EOT kuten kaikki empiirinen tutkimus perustuu havaintoihin, (luonnon)lakeihin ja teorioihin. Yleensä havainnoista johdetaan laki, joka yleistetään teoriaksi. Jos (uudet) havainnot eivät sovi teoriaan, teoriaa täydennetään. Tällöin vanha teoria voi olla uuden teorian erikoistapaus. Empiirinen ohjelmistotutkimus 3 Havainnot, laki, teoria Havainnot ovat aistiemme antamia syötteitä. Ne voivat olla subjektiivisia tai objektiivisia. Kun jonkun ilmiön havainnoilla on jokin tunnistettu toistuva tekijä, saadaan laki. Laki on yleistys, jonka avulla voidaan ennustaa tulevia havaintoja. Laki selittää, miten jokin tapahtuu, mutta ei kerro miksi. Teoria selittää, miksi laki toimii. Empiirinen ohjelmistotutkimus 4 Havainto-laki-teoria Järjestelmällinen havainnointi 1 Havainto Ennustaa Toistuu samanlaisina Laki Selittää Teoria Varmentaa Havainnointi pitää saada sellaiseksi, että sen avulla saatuja tuloksia voidaan analysoida ja yleistää laeiksi ja teorioiksi Projektin tärkein tehtävä on saada tehtäväksi annettu tuotos valmiiksi. Sivutuotteena saadaan myös uutta tietoa. Projekteista kerätystä mittaustiedosta voidaan vetää yleisempiä johtopäätöksiä vastaavien projektien toiminnasta. Kyselytutkimuksessa (survey) käytetään lomakkeita ja haastatteluja kerättäessä tietoja halutusta ilmiöstä. Tulokseksi saadaan mielipiteitä, joita voidaan käyttää täydentämään muuta tutkimusta. Empiirinen ohjelmistotutkimus 5 Empiirinen ohjelmistotutkimus 6 Taina 1

2 Järjestelmällinen havainnointi 2 Tapaustutkimuksessa (case study) projektia tarkkaillaan ulkopuolelta keräämällä siitä tutkimuksen kannalta mielenkiintoista tietoa. Tutkittuun ilmiöön liittyvät tekijät luokitellaan etukäteen ja projektin aikana tekijöihin liittyvät havainnot ja toiminta dokumentoidaan. Ohjatussa kokeessa (controlled experiment) osallistujat valitaan satunnaisesti kahteen tai useampaan valvottuun ryhmään. Koe tehdään laboratorio-olosuhteissa, jossa yhtä ominaisuutta lukuun ottamatta samanlaiset ryhmät tekevät toisistaan riippumattomasti kokeessa vaadittavat tehtävät. Kokeen kannalta mielenkiintoisen ominaisuuden arvot vaihtelevat ryhmittäin. Havainnointimenetelmien heikkoudet Projektien tehtävä on tuottaa haluttu lopputulos, ei tuottaa uutta tietoa. Tulokset voivat olla turhia. Kyselytutkimuksella saadaan mielipiteitä, jotka yleensä eivät ole totuuksia. Tapaustutkimuksissa tutkimuksen kohteeseen ei vaikuteta, joten kohde saattaa ajautua tutkimuksen kannalta yhdentekevään suuntaan. Ohjatut kokeet ovat kalliita, joten niitä voidaan harvoin tehdä todellisessa ympäristössä. Ei ole selvää, miten hyvin laboratorioympäristössä saadut tulokset ovat yleistettävissä. Empiirinen ohjelmistotutkimus 7 Empiirinen ohjelmistotutkimus 8 Lait, hypoteesit ja teoreemat Laki (law): Empiirisin kokein validoitu sääntö, joka sopii reunaehdoilla useimpiin havaintoihin. Hypoteesi (hypothesis): Alustavasti hyväksytty ehdotus, joka tarjoaa hyödyllisen havaintoja tukevan näkökulman; toistaiseksi ei validoitu. Teoreema (theorem): Täsmällinen laki, jonka täytyy sopia kaikkiin havaintoihin. Empiirinen ohjelmistotutkimus 9 Empiirisen ohjelmistotutkimuksen lait EOT:n lait eivät ole yhtä vahvoja kuin fysiikan lait. Ne ovat luonteeltaan lähempänä taloustieteen lakeja. EOT:n lait eivät ole eksakteja (siis teoreemoja), sillä ne eivät päde aina. Kun laki pätee riittävän usein ja riittävän yleisin reunaehdoin, sitä voidaan käyttää teorian pohjana. Edellä riittävä on määrittelykysymys. Mitä vaan havaintoihin edes hiukan sopivaa voidaan kutsua laiksi, mutta kaikki tällaiset lait eivät kestä aikaa ja epäsopivien havaintojen hyökkäyksiä. Empiirinen ohjelmistotutkimus 10 Teoriat Teoria on selitys syistä, miksi jokin laki on voimassa. Teoria on voimassa juuri niin kauan kuin se pystyy selittämään laista tehdyt havainnot. Kun havainnot ovat ristiriidassa teorian kanssa, teoriaa täytyy täydentää tai korvata se paremmalla teorialla. EOT ja ohjelmistotekniikka Seuraavissa luvuissa esiteltävät lait ja hypoteesit auttavat ymmärtämään ohjelmistotekniikan perusteita. Hyväksytyt teoriat auttaisivat vielä enemmän, sillä niiden avulla voitaisiin johtaa uusia lakeja. Valitettavasti EOT:n teorioita on vähän ja lakien tulkinnat ovat kiistanalaisia. Empiirinen ohjelmistotutkimus 11 Empiirinen ohjelmistotutkimus 12 Taina 2

3 2. Vaatimusmäärittely Vaatimusmäärittely on ensimmäinen projektin osavaihe. Sitä pidetään myös tärkeimpänä vaiheena. Miksi? Ehkä seuraavat lait selittävät asiaa: Glass: Puutteelliset vaatimukset ovat todennäköisin epäonnistuneen projektin syy. Boehm: Vaatimusmäärittelyn ja suunnittelun virheiden korjaus on sitä kalliimpaa, mitä myöhemmin niitä yritetään korjata. Lisäksi (Glass, 2003): Glass: Puuttuvat vaatimukset ovat vaikeimmin havaittavia ja korjattavia virheitä. Empiirinen ohjelmistotutkimus 13 Vaatimusmäärittelyn validointi Vaatimusmäärittelystä on myös vaikeaa saada validoituja tuloksia, sillä vaatimusmäärittely on interaktiivista toimintaa, jota on vaikeaa tarkkailla ulkopuolelta häiritsemättä prosessia, ja vaatimusmäärittely on hankala prosessi, sillä kaikki helposti määriteltävät tuotteet on jo määritelty. Jokainen vaatimusmäärittelyprosessi on omalla tavallaan ainutkertainen. Empiirinen ohjelmistotutkimus 14 Vaatimusmäärittelyn lait Oppikirjassa esitellyt vaatimusmäärittelyn lait ja hypoteesit ovat luonteeltaan varoittavia. Ne voidaan tiivistää yhdeksi lauseeksi: Jos et ole tarkkana vaatimusmäärittelyssä, niin projektillesi voi käydä huonosti. Myös vaatimusmäärittelyn tekniikoita voitaisiin validoida, mutta toistaiseksi sellaista tutkimusta on vähän. Empiirinen ohjelmistotutkimus 15 Vaatimusmäärittelyn työvaiheet Vaatimusmäärittelyn työvaiheet ovat: 1. Vaatimusten kartoitus 2. Kartoitettujen vaatimusten analyysi 3. Vaatimusten tarkennus ja spesifiointi 4. Vaatimusten priorisointi 5. Sidosryhmien välisten konfliktien ratkonta 6. Vaatimusten validointi 7. Vaatimusten (dokumentin) hyväksyminen Vaiheet 1-6 toistuvat iteratiivisesti. Empiirinen ohjelmistotutkimus 16 Empiiristen tulosten ja työvaiheiden suhde Nyt esiteltävät vaatimusmäärittelyn empiiriset tulokset liittyvät seuraaviin työvaiheisiin: Glassin laki: Vaatimusten validointi Glassin hypoteesi: Vaatimusten kartoitus Boehmin 1. laki: Vaatimusten validointi Boehmin 2. laki: Vaatimusten validointi Davisin laki: Vaatimusten analyysi Boochin 1. hypoteesi: Vaatimusten kartoitus Empiirinen ohjelmistotutkimus 17 Empiiristen tulosten ja työvaiheiden suhde 2 Edellinen lista painottuu voimakkaasti vaatimusten kartoitukseen ja validointiin. Painottuminen on luonnollista, sillä kartoitus ja validointi ovat eräänlaisia vaatimusmäärittelyn tarkistuspisteitä: Kartoituksen jälkeen on jotain työstettävää. Analyysi, tarkennus, spesifiointi ja priorisointi tähtäävät kaikki samaan tavoitteeseen: vaatimusten validointiin. Empiirinen ohjelmistotutkimus 18 Taina 3

4 2.1. Glassin laki Puutteelliset vaatimukset ovat tärkein projektien epäonnistumisen syy. Robert Glass on eräs ohjelmistotekniikan suurista nimistä. Hänen lakinsa perustuu vaatimusmäärittelystä tehtyihin tapaustutkimuksiin. Vaikka suurin osa projekteista onnistuu, vielä on paljon parantamisen varaa. Glassin lain taustaa Kehno vaatimusmäärittely on vakava ongelma projekteille. Määrittelyongelmia syntyy, sillä usein vaatimusten kartoitus tehdään huonosti, vaatimuksia ei määritellä riittävän tarkasti, vaatimuksia ei ymmärretä oikein, vaatimuksia ei osata tarkentaa ja vaatimukset muuttuvat projektin aikana. Empiirinen ohjelmistotutkimus 19 Empiirinen ohjelmistotutkimus 20 Glassin lain taustaa 2 Tavallisin vaatimusmäärittelyn virhe on epätäydellinen tai virheellinen määrittely. Erityisesti ongelmia syntyy, jos projektin vaatimusmäärittely on ulkoistettu jollekin kolmannelle osapuolelle. Vaatimusmäärittelyyn vaaditaan sekä tarkkuutta että verifiointia, jotta ongelmat havaitaan ja korjataan ajoissa. Empiirinen ohjelmistotutkimus 21 Glassin lain perusteluja Glass perustaa tuloksensa tapaustutkimuksiin. Tällaista lakia ei oikein voi validoida muilla keinoilla. Glassin havaintoja epäonnistuneista projekteista: Liikaa vaatimuksia. Myöhään ilmenneitä muuttuvia vaatimuksia. Moniselitteisiä vaatimuksia. Epätäydellisiä vaatimuksia. Empiirinen ohjelmistotutkimus 22 Glassin lain teoria Vaatimusten määrittely on vaikeaa. Sidosryhmien tarpeet eroavat toisistaan. Vaatimusten priorisointi ei aina onnistu. Vaatimusmäärittely on oppimista ja neuvottelua. Työvaihe vaatii paljon sekä sidosryhmiltä että projektiryhmältä. Osallistujat eivät tiedä kaikkea, unohtavat, eivät osaa jakaa tietojaan jne. Asiakkaat eivät osaa ilmaista vaatimuksia. Empiirinen ohjelmistotutkimus Glassin hypoteesi Puuttuvat vaatimukset ovat vaikeimmat havaita ja korjata. Tätä ei ole listattu oppikirjassa, mutta se on esitelty Glassin omassa kirjassa R. Glass, Facts and Fallacies of Software Engineering. Addison-Wesley, Glass listaa tämän kohdan fakta alle, mutta kurssin terminologialla tämä on hypoteesi. Empiirinen ohjelmistotutkimus 24 Taina 4

5 Glassin hypoteesin taustaa Vaatimusten kartoitus on ratkaistavan ongelman määrittelyä, johon tarvitaan yhteistyötä sidosryhmien edustajien kanssa. Yleensä tämä tarkoittaa sidosryhmien edustajien haastatteluja. Mitä enemmän mukana on inhimillisiä tekijöitä, sitä virhealttiimpaa on toiminta. Tulokset voivat olla sekä moniselitteisiä että vaikeasti kuvattavia: virhealttiita. Empiirinen ohjelmistotutkimus 25 Glassin hypoteesin taustaa 2 Myös vaatimusten mallinnus ja tulkinta ovat virhealttiita työvaiheita. Käyttäjävaatimuksia ei yleensä saada sellaisella tarkkuudella, että niistä voitaisiin suoraan johtaa malli. Järjestelmävaatimuksia varten tarvitaan käyttäjävaatimusten analyysia. Vajailla tiedoilla toimittaessa analyysi voi epäonnistua pahemman kerran. Empiirinen ohjelmistotutkimus 26 Glassin hypoteesin taustaa 3 Kun kaksi virhealtista prosessia yhdistetään, saadaan erityisen virhealtis prosessi. Kaikkia tuotteen vaatimuksia ei löydetä. Toisaalta tuotteen järjestelmätestaus perustuu tunnettuihin vaatimuksiin. Jos jokin vaatimus puuttuu, sitä ei ehkä osata kaivata. Pahimmillaan puuttuva vaatimus huomataan vasta tuotantokäytössä. Empiirinen ohjelmistotutkimus 27 Glassin hypoteesin perusteluja Glass perustaa hypoteesinsa sekä loogiseen päättelyyn että tuotantoon asti päässeiden virheiden analyysiin. Hän huomasi, että sitkeimmät virheet olivat puuttuvan logiikan virheet, kuten puuttuva haarauma koodissa. Miksi haaraumat puuttuvat? Koska niitä ei ole suunniteltu. Miksi? Koska ei ole ollut vaatimusta, joka olisi vaatinut ne. Empiirinen ohjelmistotutkimus Boehmin ensimmäinen laki Virheitä syntyy eniten vaatimusmäärittely- ja suunnitteluvaiheessa. Mitä myöhemmin nämä virheet löytyvät, sitä kalliimmaksi niiden korjaaminen tulee. Boehmin ensimmäinen laki selittää, missä työvaiheessa virheet ylipäänsä ilmaantuvat. Laki voidaan varmentaa luokittelemalla löydetyt virheet ja arvioimalla kunkin virheen korjauskustannus. Empiirinen ohjelmistotutkimus 29 Boehmin ensimmäisen lain taustaa 1970-luvulla havaittiin, että suurin osa tuotteiden virheistä tulevat projektien elinkaaren alussa: suunnittelussa ja vaatimusmäärittelyssä. Molemmissa työvaiheissa tulee paljon virheitä, mutta vakavimmat virheet tehdään vaatimusmäärittelyssä. Pahimmillaan virheet havaitaan vasta asennettaessa ohjelmaa asiakkaalle. Empiirinen ohjelmistotutkimus 30 Taina 5

6 Boehmin ensimmäisen lain taustaa 2 Mitä kauemmin menee virheen teosta sen korjaamiseen, sitä kalliimmaksi sen korjaaminen loppujen lopuksi tulee. Seuraus: Virheen korjaamisen kalleuden määrää virheen elinikä. Kalleimmat virheet tulevat projektin alussa: vaatimusten kartoituksessa ja analyysissa. Seuraus 2: Jos voimme varmistaa, että virheet löytyvät nopeasti, voimme sallia useampia virheitä työvaiheisiin. Empiirinen ohjelmistotutkimus 31 Boehmin ensimmäisen lain perusteluja Boehm perustaa lakinsa 1974 TRW:lla (amerikkalainen monialayritys) tehtyyn tutkimukseen. Tutkimuksessa analysoitiin 224 virhettä. 64% virheistä liittyi suunnitteluun (ja vaatimusmäärittelyyn). Hyväksymistestauksessa suhde oli 45: Endres sai vastaavasti tuloksen: 60-70% kaikista projektin aikana löydetyistä virheistä on vaatimusmäärittely- tai suunnitteluvirheitä. Empiirinen ohjelmistotutkimus 32 Boehmin ensimmäisen lain teoria Miksi vaatimusmäärittelyn ja suunnittelun virheet ovat yleisimmät? Koska näissä työvaiheissa pitäisi hallita ongelma hyvin erilaisilla abstraktioilla kokonaisuudesta osiin ja oikeasta toiminnasta poikkeustilanteisiin. Miksi vaatimusmäärittelyn ja suunnittelun virheet ovat kalleimmat korjata? Koska unohdettu virhe synnyttää tulevissa työvaiheissa uusia virheitä. Empiirinen ohjelmistotutkimus Boehmin toinen laki Prototyyppien käyttö vähentää merkittävästi erityisesti käyttöliittymien vaatimusmäärittelyn ja suunnittelun virheitä. Prototyyppejä on käytetty jo vuosikymmeniä vaatimusmäärittelyn apuvälineinä. Samoin protojen vaikutusta vaatimusmäärittelyyn on tutkittu paljon. Toisin kuin edelliset lait, Boehm validoi väitteensä ohjatulla kokeella. Empiirinen ohjelmistotutkimus 34 Boehmin toisen lain taustaa Laki on intuitiivisesti selkeä: Prototyypit kaventavat määrittelyn ja toteutuksen välistä kuilua. Kuva puhuu enemmän kuin tuhat sanaa. Proto puhuu enemmän kuin tuhat kuvaa. Prototyyppiä on helpompi ymmärtää kuin pelkkiä kirjattuja vaatimuksia. Prototyypit vähentävät sekä sidosryhmien keskinäisiä että sidosryhmien ja projektiryhmän välisiä epäselvyyksiä. Empiirinen ohjelmistotutkimus 35 Boehmin toisen lain perusteluja Boehmin toinen laki perustuu ohjattuun kokeeseen: Boehm käytti seitsemää ryhmää, joista neljässä käytettiin normaalia vaatimusmäärittelyä ilman prototyyppejä ja kolmessa käytettiin prototyyppejä. Kokeessa käytettiin maisteritason opiskelijoita, joiden tehtävänä oli kehittää interaktiivinen versio COCOMO-malliin perustuvasta prosessin arviointityökalusta. Empiirinen ohjelmistotutkimus 36 Taina 6

7 Boehmin toisen lain perusteluja 2 Kokeen tulokset olivat seuraavat: Prototyyppiryhmien tulokset olivat kooltaan hiukan pienemmät (samaa toiminnallisuutta kohden tuli vähemmän koodia). Molempien ryhmien tehokkuus oli suurin piirtein samaa luokkaa (isoa hajontaa). Prototyyppiryhmät tuottivat helppokäyttöisempiä ja helpommin opittavia järjestelmiä. Protoryhmien tuotteissa oli toisaalta vähemmän toimintoja. Empiirinen ohjelmistotutkimus 37 Boehmin toisen lain perusteluja 3 Vaikka Boehmin kokeen tulokset eivät ole kovin kummoisia, myöhemmät tutkimukset ovat vahvistaneet tuloksia. Prototyyppien käyttö vähentää ylimääräisten ominaisuuksien määrää tuotteissa. Bernstein esittää 1993 tehdyssä tutkimuksessa, että prototyypit vähentävät jopa 40% työmäärää. Vaarojakin on: asiakkaat saattavat ihastua liikaa protojen ominaisuuksiin. Empiirinen ohjelmistotutkimus 38 Boehmin toisen lain teoria Vaatimusmäärittelyn pahimpia ongelmia on moniselitteisyys. Mitä useampi sidosryhmä on riippuvainen tuotteesta, sitä varmempaa on, että syntyy väärinkäsityksiä. Prorotyypit vähentävät moniselitteisyyttä, sillä ne näyttävät sidosryhmille tuotteen lähes sellaisena kuin se tulee lopulta olemaan. Empiirinen ohjelmistotutkimus Davisin laki Mallin hyöty riippuu valitusta näkökulmasta, mutta yksikään malli ei ole paras kaikkiin tarkoituksiin. Malleja käytetään kuvaamaan todellista tai suunniteltua järjestelmää, joskus myös käyttötapauksia tai vaatimuksia. Mallien arvo on sama kuin prototyyppien: ne vähentävät moniselitteisyyttä. Davisin lain mukaan vaatimusmäärittelyssä tarvitaan useita rinnakkaisia malleja. Empiirinen ohjelmistotutkimus 40 Davisin lain taustaa Mallinnus on osoittautunut erinomaiseksi keinoksi esittää järjestelmän toimintaa. Esimerkiksi vaatimusmäärittelyssä käytetään seuraavia malleja: Tietomallit: Luokkakaaviot Prosessimallit: Tietovuokaaviot Tilasiirtymät: Tilasiirtymäkaaviot Rakenteet: Oliokaaviot Toiminta: Sekvenssikaaviot Käyttötapaukset: Käyttötapauskaaviot Empiirinen ohjelmistotutkimus 41 Davisin lain taustaa 2 Jokainen kaaviotekniikka esittää näkymän mallinnettuun järjestelmään. Jokainen näkymä antaa jotain tietoa järjestelmästä ja piilottaa jotain muuta tietoa. Malli abstrahoi järjestelmää. Davisin mukaan ei ole olemassa sellaista mallia, joka parempana korvaisi kaikki toiset mallit. Sellainen malli ei piilottaisi järjestelmästä mitään tietoja, eli se olisi itse järjestelmä. Empiirinen ohjelmistotutkimus 42 Taina 7

8 Davisin lain perusteluja Davisin lain perusteluja 2 Davis perusti tuloksensa subjektiiviseen päättelyyn. Hän esitteli kolme toisistaan selvästi eroavaa järjestelmää, ja kokeili näiden vaatimusmäärittelyyn joukkoa mallinnuskeinoja. Järjestelmät olivat: Kirjamyymälän puoliautomaattinen järjestelmä Automatisoitu helikopterin laskeutumisjärjestelmä Järjestelmä siirtämään ihmisiä 30 minuutissa New Yorkista Tokioon. Empiirinen ohjelmistotutkimus 43 Ensimmäisen järjestelmän kohdalla voitiin Davisin mukaan käyttää hyvin eri tyyppisiä mallinnuskeinoja, jotka kaikki tuottivat hyödyllisiä mutta erilaisia tuloksia. Toisen järjestelmän ja varsinkin kolmannen järjestelmän kohdalla mallien hyöty oli pieni verrattuna järjestelmän määrittelyongelmiin. Ongelman määrittelyyn vaaditaan syvällistä tietoa käyttöympäristöstä. Pelkät mallit eivät siihen riitä. Empiirinen ohjelmistotutkimus 44 Davisin lain validointi Davisin perustelut ovat kevyet, mutta tulos on validi. Tulosta voitaisiin varmentaa lisää ohjatulla kokeella: Jaetaan ensin kokeeseen osallistujat sopivan kokoisiin ryhmiin. Puolet ryhmistä saa tehtäväksi tehdä vaatimusmäärittelyn käyttämällä ennalta valitsemaansa kuvaustekniikkaa. Loput saavat käyttää mitä tahansa kuvaustekniikoita. Empiirinen ohjelmistotutkimus 45 Davisin lain validointi 2 Ryhmien vaatimusmäärittelyjä vertaamalla, ja varsinkin jos ryhmät laitetaan tekemään prototyyppi, saataisiin toivottavasti vastauksia seuraaviin kysymyksiin: Miten ryhmien vaatimukset erosivat toisistaan? Miten kehitettävien järjestelmien toiminnallisuus erosi toisestaan? Miten syvällisen kuvan kehitettävästä tuotteesta ryhmät saivat? Miten tyytyväinen asiakas oli kehitettyihin prototyyppeihin? Empiirinen ohjelmistotutkimus 46 Davisin lain teoria Kokonaisuuden rakentaminen isosta joukosta yksityiskohtia on vaikeaa (kokeile esimerkiksi koota palan palapeli.) Malli on kohteen yksinkertaistus. Sen avulla koko järjestelmästä saadaan helpommin hallittava yleistetty näkymä. Tarvitaan useita näkymiä, usea eri abstraktiotasolla oleva malli, kuvaamaan koko järjestelmä. Empiirinen ohjelmistotutkimus Boochin ensimmäinen hypoteesi Oliomallinnus vähentää analyytikkojen ja käyttäjien välisiä kommunikaatio-ongelmia. Oliomallinnuksen hyvistä puolista on kirjoitettu hyllymetreittäin tekstiä. Viime vuosina oliomallinnus on tullut ohjelmointikielten ja suunnittelun kautta myös vaatimusmäärittelyyn. Boochin mukaan suuntauksen pitäisi helpottaa vaatimusten kartoitusta. Empiirinen ohjelmistotutkimus 48 Taina 8

9 Boochin ensimmäisen hypoteesin taustaa Sekä vaatimusmäärittelyssä että suunnittelussa oliomallinnus kuvaa, miten kehitettävä järjestelmä jakautuu eri kokoisiin moduuleihin: osajärjestelmiin, komponentteihin ja luokkiin; ja miten moduulit kommunikoivat keskenään. Intuitiivisesti ositus helpottaa ymmärtämistä, sillä kokonaisuuden sijaan riittää käsitellä vain yhtä osaa. Empiirinen ohjelmistotutkimus 49 Boochin ensimmäisen hypoteesin taustaa 2 Oliomallinnuksesta pidetään, sillä se muistuttaa ihmisten tapaa käsitellä asioita kokonaisuuksina, sen katsotaan helpottavan siirtymistä vaatimuksista suunnittelun kautta toteutukseen, siinä tietoa ja sen käsittelyä ei eroteta toisistaan siinä käytetään hyväksi havaittuja olioparadigman periaatteita, kuten abstrahointia, kapselointia, modulaarisuutta, hierarkkisuutta, tyypitystä ja rinnakkaisuutta. Empiirinen ohjelmistotutkimus 50 Boochin ensimmäisen hypoteesin taustaa 3 Vaikka oliomallinnus voi olla myös vaatimusmäärittelyn työkalu, sen avulla voidaan pääasiassa kuvata tulevaa järjestelmää. Sen sijaan ei ole aivan selvää, auttaako oliomallinnus kartoittamaan vaatimuksia. Itse asiassa perinteinen ositus prosesseihin (toimintoihin) voi olla sidosryhmille oliomaailmaa selkeämpi. Empiirinen ohjelmistotutkimus 51 Boochin ensimmäisen hypoteesin perusteluja (tai tyrmäystä) Oppikirjassa esitellyt perustelut vaikuttavat hypoteesin vastaisilta: Oliopohjaisus ei helpota sidosryhmien ja projektiryhmän välistä kommunkaatiota. Oliopohjaisuudella ei löydetä perinteisiä tapoja tehokkaammin vaatimuksia. Toisaalta tulokset ovat yli kymmenen vuotta vanhoja. Menetelmät kehittyvät. Vähintään voidaan sanoa, että hypoteesin validoinnissa on vielä työtä. Empiirinen ohjelmistotutkimus 52 Esiteltyjen lakien seurauksia Vaatimusmäärittelylle pitää varata tarpeeksi aikaa ja resursseja. Vaatimusmäärittelyn tulee olla iteratiivista. Iteratiivisuus helpottaa havaitsemaan puuttuvia vaatimuksia, kun vaatimuksia voidaan kartoittaa hallittavissa pienissä osissa. Prototyyppejä kannattaa käyttää. Vaatimusten analysoinnissa kannattaa tehdä useita eri abstraktiotasoilla olevia malleja tulevasta järjestelmästä. Ketterien prosessimallien tapa kerätä vähän vaatimuksia kerrallaan lyhentää virheiden elinkaarta ja siten säästää testauskuluissa. Empiirinen ohjelmistotutkimus 53 Lakien ja hypoteesien vaikutus vaatimusmäärittelyyn Oppikirjan lait ja hypoteesit antavat varsin ohuen kuvan vaatimusmäärittelyn lainalaisuuksista. Tämä ei tarkoita, että vaatimusmäärittely on kaaos. Hyväksi havaittuja menetelmiä ei vain ole vielä varmennettu kunnolla. Vaatimusmäärittelyn lainalaisuuksien validoinnissa on vielä paljon tehtävää. Empiirinen ohjelmistotutkimus 54 Taina 9

10 3. Suunnittelu Suunnittelu on teknisesti kaikkein haastavin ja luonteeltaan kaikkein ristiriitaisin työvaihe. Miksi? Curtis: Hyvä suunnittelu vaatii syvällistä tuotteen sovellusalueen hallintaa. Dyer: Siirtyminen vaatimusmäärittelystä suunnitteluun kasvattaa vaatimusten määrän jopa 50-kertaiseksi. Simon jne: Suosi modulaarisuutta. Empiirinen ohjelmistotutkimus 55 Siis mikä suunnittelun haastavuus ja ristiriitaisuus? Curtis & Dyer: Hyvä suunnittelu vaatii laajaa kokemusta. Dyer, Simon, jne.: Suunnittelu alkaa vajaista korkean tason vaatimuksista ja päättyy toteutusläheiseen tulokseen. Suunnittelussa on siis käsiteltävä ongelmaa sekä vaatimusmäärittelyn että toteutuksen näkökulmasta. Lähes jokainen suunnitelma on ainutkertainen, koska kerran tehtyä ohjelmistoa ei kannata suunnitella uudestaan kuin poikkeustapauksissa. Empiirinen ohjelmistotutkimus 56 Suunnittelun lait ja hypoteesit Oppikirjassa esitellyt suunnittelun lait ja hypoteesit liittyvät hyvän suunnittelun ominaisuuksiin. Ne voidaan tiivistää näin: Hyvässä suunnittelussa sovellusalue ja käytetyt menetelmät hallitaan suvereenisti. Suunnittelun tulee olla modulaarista. Mitä vähemmän yhteyksiä suunniteltavien moduulien välillä on, sen parempi. Empiirinen ohjelmistotutkimus 57 Suunnittelun työvaiheet Suunnittelussa on yleensä ainakin seuraavat työvaiheet: 1. Arkkitehtuurisuunnittelu 2. Osajärjestelmäsuunnittelu 3. Komponenttisuunnittelu 4. Luokkasuunnittelu 5. Tietorakennesuunnittelu 6. Algoritmisuunnittelu 7. Käyttöliittymäsuunnittelu Empiirinen ohjelmistotutkimus 58 Empiiristen tulosten ja työvaiheiden suhde Curtisin laki: 1-7 Simonin laki: 1-4 Constantinen laki: 3-4 Parnasin laki: 1-5 Denertin laki (ei käsitellä): 1 Fitts-Shneidermanin laki (ei käsitellä): 7 Boochin 2. hypoteesi: 1-4 Bauer-Zemanekin hypoteesi: 1-6 Dyerin hypoteesi: 1-7 Gamman hypoteesi: 4-6 Empiiristen tulosten ja työvaiheiden suhde 2 Kuten edellisestä listasta näkyy, esiteltävät lait ja hypoteesit ovat yleisiä: ne sopivat lähes kaikkiin työvaiheisiin. Itse asiassa monet laeista eivät rajoitu ohjelmistotekniikkaan vaan pätevät myös muissa insinööritieteissä. Todella hyvä empiirinen laki on niin yleinen, että ympäristö ei rajoita sitä. Empiirinen ohjelmistotutkimus 59 Empiirinen ohjelmistotutkimus 60 Taina 10

11 3.1. Curtisin laki Curtisin lain taustaa Hyvä suunnittelu vaatii syvällistä tuotteen sovellusalueen hallintaa Curtisin laki perustuu erityisesti sotilasteollisuuden ohjelmistojen tarkkailuun mutta pätee mille tahansa sovellusalueelle. Curtisin laki on ehkä tärkein suunnittelun laki. Sen mukaan laadukkaan ohjelmiston suunnittelu ei onnistu, jos suunnittelijat eivät tunne ympäristöä, missä ohjelmistoa tullaan käyttämään. Empiirinen ohjelmistotutkimus 61 Hyvään suunnitteluun vaaditaan sekä tietoa että ymmärrystä ohjelmiston sovellusalueesta (problem domain). Sovellusalueet ja niille tehtävät ohjelmistot eroavat vahvasti toisistaan. Kaikkien alojen asiantuntijaa ei ole. Kaikille aloille sopivia ohjelmia ei ole. Koodaustaito ei takaa suunnittelutaitoa. Empiirinen ohjelmistotutkimus 62 Curtisin lain taustaa 2: suunnittelun vaativuus palvelut, käyttäjien toiminta, rajoitteet, poikkeukset, laitteet Sovellusalueen hallinta Kuvaus rakenteet, arkkitehtuurit, algoritmit, resurssit, tiedot Koodauksen hallinta Hyvään suunnitteluun vaaditaan molempien alueiden hyvää hallintaa. Empiirinen ohjelmistotutkimus 63 Curtisin lain taustaa 3 Suunnittelun ongelmana on, että suunnittelijoiden pitää olla sekä sovellusalueen että kehitystyön asiantuntijoita. Useimmiten näin ei ole. Yleisin lienee tapaus, missä suunnittelijat ovat vain kehitystyön asiantuntijoita. Toki voi myös olla, että suunnittelijat ovat vain sovellusalueen asiantuntijoita. Empiirinen ohjelmistotutkimus 64 Curtisin lain perusteluja Curtis perustaa tuloksensa 1986 tekemäänsä 17 projektia kattaneeseen haastattelututkimukseen. Hänen tuloksensa olivat: Vain harvalla projektien jäsenistä oli sovellusalueen tuntemusta. Useimmiten yksi tai kaksi eniten sovellusaluetta tuntevaa henkilöä ottivat päävastuun suunnittelusta. Empiirinen ohjelmistotutkimus 65 Curtisin lain perusteluja 2 Curtisin tulokset jatkuvat: Samat pari sovellusalueen tuntijaa informoivat muita projektin jäseniä arkkitehtuurista. Suunnittelukokousten tehtävänä oli muokata suunnitelma koko projektiryhmän yhteiseksi näkemykseksi tehtävästä tuotteesta. Johtopäätös: suunnittelu jätettiin suosiolla sovellusalueen asiantuntijoille. Empiirinen ohjelmistotutkimus 66 Taina 11

12 Curtisin lain teoria Teoria 1 (oppikirja): Suunnittelu on yksi tietämyksen sovellus. Osa tietämyksestä on piilotietämystä (tacit knowledge), joka on hienompi sana kokemukselle. Pelkkä kirjoitettu tieto ei riitä matkalla vaatimuksista suunnitteluun, vaan tarvitaan myös vankkaa sovellusalueen tuntemista ja kokemusta. Empiirinen ohjelmistotutkimus 67 Curtisin lain teoria 2 Teoria 2 (luennoija): Jos Dyerin hypoteesi on voimassa, suunnittelussa johdettavien vaatimusten määrä on jopa 50-kertainen verrattuna käyttäjävaatimuksiin. Suuri osa johdetuista vaatimuksista koskee ohjelmiston suhdetta sovellusalueeseen. Näitä ohjelmiston ja sovellusalueen välisiä vaatimuksia ei voida suunnitella ilman vahvoja taustatietoja sovellusalueesta. Empiirinen ohjelmistotutkimus Simonin laki Hierarkkisuus vähentää kompleksisuutta. Simonin laki käy perusteluksi esimerkiksi suunnittelussa käytettyyn luokka komponentti osajärjestelmä jaotteluun. Simonin laki ei ole pelkkää ohjelmistotekniikkaa, vaan sama laki pätee kaikkeen suunnitteluun. Simonin laki on yksi yleisesti hyväksytyistä insinööritieteiden suunnittelun laeista. Empiirinen ohjelmistotutkimus 69 Simonin lain taustaa Hierarkkisuus tarkoittaa, että järjestelmä rakentuu osajärjestelmistä, jotka rakentuvat osajärjestelmistä jne. kunnes päädytään perusosiin. Kompleksisuuden väheneminen tarkoittaa, että järjestelmän ymmärtäminen ja sen toiminta vaativat entistä vähemmän työtä ja energiaa. Hierarkkisten järjestelmien hallinta ja ymmärtäminen on siten helpompaa kuin eihierarkkisten järjestelmien. Empiirinen ohjelmistotutkimus 70 Simonin lain perusteluja Simon perustaa lakinsa havaintoihin luonnosta. Hänen mukaansa luonnossa hierarkkiset järjestelmät kehittyvät nopeammin kuin ilman rakennetta olevat järjestelmät. Evoluutio suosii hierarkkisia järjestelmiä, sillä ne toipuvat paremmin häiriöistä. Sama pätee keinotekoisiin järjestelmiin myös ohjelmistotekniikassa. Empiirinen ohjelmistotutkimus 71 Simonin lain teoria Simonin laki vaikuttaa olevan luonnonlaki, jolle teorian kehittäminen olisi enemmän filosofiaa kuin EOT:ta. Simon itse toteaa: En tiedä, ymmärrämmekö maailmaa, koska se on hierarkkinen, vai näemmekö maailman hierarkkisena, koska emme ymmärrä emmekä osaa havaita sen hierarkian vastaisia rakenteita. Empiirinen ohjelmistotutkimus 72 Taina 12

13 3.3. Constantinen laki Rakenne on stabiili, jos sen yhtenäisyys on vahva ja kytkentäaste matala. Yhtenäisyys (cohesion, binding): miten sidoksissa moduulin (osajärjestelmän, komponentin, luokan) osat ovat toisiinsa. Kytkentäaste: (coupling): miten sidoksissa moduuli on muihin moduuleihin. Eli hyvä moduuli hoitaa omat hommansa mahdollisimman riippumattomasti muista. Empiirinen ohjelmistotutkimus 73 Constantinen lain taustaa Constantinen laki on sukua Simonin laille. Lain perusteella mitä paremmin järjestelmän osat tekevät omat tehtävänsä ja mitä vähemmän niillä on keskinäisiä yhteyksiä, sitä paremmin järjestelmä sietää häiriöitä. Yhtenäisyys ja kytkentäaste näkyvät selvästi esimerkiksi oliopohjaisessa suunnittelussa ja suunnittelumalleissa. Empiirinen ohjelmistotutkimus 74 Constantinen lain perusteluja Sekä yhtenäisyys että kytkentäaste voidaan määritellä matemaattisesti. Määritelmän avulla yhtenäisyyttä ja kytkentäastetta voidaan mitata ohjelmakoodista, joten Constantinen lain testaamiseen voidaan käyttää staattisia metriikoita. Näitä tutkimuksia on jo tehty (Cidamber & Kemerer 1994, Basili 1996, Briand 1998). Empiirinen ohjelmistotutkimus 75 Constantinen lain perusteluja 2 Tutkimusten oleellisia tuloksia: Vahva yhtenäisyysłvähän virheitä: Vahva vastaavuus. Korkea sisäinen kytkentäaste (olio kutsuu muita) Ł enemmän virheitä: Vahva vastaavuus. Korkea ulkoinen kytkentäaste (oliota kutsutaan) Ł enemmän virheitä: Heikko vastaavuus. Empiirinen ohjelmistotutkimus 76 Constantinen lain teoria Korkea yhtenäisyys tarkoittaa, että moduulissa ei ole mitään ylimääräistä. Matala kytkentäaste tarkoittaa, että moduulit voidaan paremmin eristää toisistaan ja järjestelmässä on vähemmän yhteyksiä. Molemmat pienentävät virhealttiutta ja helpottavat testausta (vrt. Simonin laki) Parnasin laki Vain piilotettua tietoa voidaan muuttaa ilman riskiä. Parnasin laki on kapseloinnin perusta, ja siten yksi ohjelmistotekniikan tärkeimmistä laeista. Laki on myös kaiken modulaarisuuden perusta yhdessä Simonin lain kanssa. Parnasin laki pätee yleisemmin myös muissa insinööritieteissä. Empiirinen ohjelmistotutkimus 77 Empiirinen ohjelmistotutkimus 78 Taina 13

14 Parnasin lain taustaa Parnasin laki on varmaankin tunnetuin ohjelmistotekniikan laki. Kaikki käyttävät sitä ajattelematta asiaa sen kummemmin. Parnasin lakia voidaan soveltaa vaikkapa projektinhallinnassa: kaikkien ei tarvitse tietää yksityiskohtia kaikista työvaiheista, vaan työvaiheiden tulokset ratkaisevat. Empiirinen ohjelmistotutkimus 79 Parnasin lain perusteluja Parnas perustaa lakinsa tapaustutkimukseen, missä hän tarkkaili Philipsin insinöörien työskentelyä. Parnas havaitsi, että modularisointi oli tärkeä suunnittelumenetelmä, mutta sitä ymmärrettiin huonosti. Parnasin lain alkuperäiset perustelut ovat varsin kevyet, mutta sittemmin laki on osoittanut voimansa useissa projekteissa ja tapaustutkimuksissa. Empiirinen ohjelmistotutkimus 80 Parnasin lain teoria Parnasin lain teoria voidaan perustaa kahteen faktaan: Suunnittelussa on tärkeää, että päätöksiä voidaan lykätä eteenpäin ilman riskiä siitä, että niiden sivuvaikutukset heijastuvat jo tehtyyn suunnitteluun pilaten sen. Ihmisen käsitys- ja omaksumiskyky on rajallinen. Tehtävään vaadittavan tiedon rajoittaminen helpottaa tehtävän tekoa Boochin toinen hypoteesi Oliopohjaiset suunnitelmat vähentävät virheitä ja rohkaisevat uudelleenkäyttöön. Boochin toinen hypoteesi on sukua vaatimusmäärittelyssä esitellylle Boochin ensimmäiselle hypoteesille. Jos Boochin hypoteesit ovat valideja, olioparadigmaa kannattaa käyttää koko projektin ajan. Empiirinen ohjelmistotutkimus 81 Empiirinen ohjelmistotutkimus 82 Boochin toisen hypoteesin taustaa Oliomallinnuksen katsotaan parantavan erityisesti suunnittelun laatua. Malleina oliot ovat helpompia mallintamiaan luonnon kohteita kuin perinteisen ohjelmoinnin aliohjelmat. Boochin hypoteeseista huolimatta oliomallinnus ei ole mikään viisasten kivi, joka ratkaisee kaikki ongelmat. Boochin toisen hypoteesin perusteluja Oikein käytettynä oliomallinnus on mainio työkalu. Vaatimusmäärittelyn käyttötapauksista voidaan eristää eri tasoisia olioita. Vaatimusmäärittelyn oliot voidaan jalostaa suunnittelussa käytettäviksi olioiksi. Hierarkkiset rakenteet, yhtenäisyys & kytkentäaste ja kapselointi ovat mukana suunnittelun alusta alkaen. Empiirinen ohjelmistotutkimus 83 Empiirinen ohjelmistotutkimus 84 Taina 14

15 Boochin toisen hypoteesin perusteluja 2 Valitettavasti oliomallinnuksella on kääntöpuolensa. Oliomallinnus sallii myös virheherkkiä rakenteita, kuten perintä, kuormitus ja myöhäinen sidonta. Näistä on myös empiirisiä tuloksia: Syvä perintähierarkiałenemmän virheitä Erittäin vahva vastaavuus. Paljon perillisiäłenemmän virheitä Vahva vastaavuus. Metodien korvausłenemmän virheitä Vahva vastaavuus. Empiirinen ohjelmistotutkimus 85 Boochin toisen hypoteesin perusteluja 3 Ei ole sattumaa, että Boochin toinen hypoteesi ei ole laki. Se ei toimi riittävän yleisillä ehdoilla. Sen sijaan on selvää, että oikein käytettynä oliomallinnus on oiva työkalu. Se sisältää aiemmista laeista saadut hyvät tulokset hierarkkisista rakenteista, kapseloinnista, yhtenäisyydestä ja kytkentäasteesta. Empiirinen ohjelmistotutkimus Bauer-Zemanekin hypoteesi Formaalit menetelmät vähentävät merkittävästi suunnitteluvirheitä tai jopa eliminoivat ne aikaisin. Vaikka ohjelmistotekniikka ei perustu matematiikkaan, jotkut ohjelmistotekniikan alueet (esim. lasilaatikkotestaus) on voitu formalisoida matemaattisin menetelmin. B-Z:n hypoteesin mukaan matemaattinen formalismi sopii hyvin myös suunnitteluun. Empiirinen ohjelmistotutkimus 87 Bauer-Zemanekin hypoteesin taustaa Formaalit menetelmät perustuvat johonkin matemaattiseen formalismiin, jonka avulla jokin ratkaisu voidaan todistaa oikeaksi. Formalismin avulla voidaan kirjoittaa ongelman määrittely, todistaa määrittelystä ominaisuuksia, tehdä määrittelyyn perustuva ratkaisu, todistaa ratkaisu matemaattisesti oikeaksi. Empiirinen ohjelmistotutkimus 88 Bauer-Zemanekin hypoteesin taustaa 2 B-Z:n hypoteesille on paljon kannatusta, sillä matemaattista formalismia pidetään perimmäisenä suunnittelun ratkaisuna. Kannattaa kuitenkin huomata, että kaikkia ongelmia ei voida formuloida, formalismin ymmärtäminen ja varsinkin uuden formalismin kehittäminen vaatii vankkaa matemaattista taustaa, formalismin päivittäminen on vaikeaa. Empiirinen ohjelmistotutkimus 89 Bauer-Zemanekin hypoteesin perusteluja B-Z:n hypotesi on eräs eniten kiistellyistä EOT:n alueista. Aiheesta on tehty lukuisia tapaustutkimuksia, mutta tulokset ovat olleet ristiriitaisia. Hallin tutkimuksessa 1990 keskikokoisen projektin (58 KLOC) formaali määrittely paransi suunnittelua ja nopeutti virheiden löytymistä. Tuotteesta ei tarvittu luonnollisella kielellä tehtyä normaalia määrittelyä. Empiirinen ohjelmistotutkimus 90 Taina 15

16 Bauer-Zemanekin hypoteesin perusteluja 2 Hayesin tutkimuksessa 1985 CICSjärjestelmän (Customer Information Control System) ohjelmoijan manuaali määriteltiin uudestaan formaalilla kielellä. Määrittelyssä manuaalista löydettiin useita puutteita ja epäjohdonmukaisuuksia, jotka johtivat muutamien CICS-järjestelmän osien kirjoittamiseen uudestaan. Projektin tuloksena raportoitiin 60% virhevähennys ja 5,5 miljoonan dollarin kustannussäästö. Empiirinen ohjelmistotutkimus 91 Bauer-Zemanekin hypoteesin perusteluja 3 Vaikka tulokset ovat vakuuttavia, niiden yleistäminen isompaan projektijoukkoon ei ole itsestään selvää: Kyseessä oli lähinnä dokumentointi- ja ylläpitoprojekti, mikä pitää ottaa huomion tulosten analyysissa. Koko projekti kesti kaiken kaikkiaan 12 vuotta! Joka tapauksessa projekti on yksi eniten viitatuista formaalien menetelmien käytettävyystutkimuksista ja vahva osoitus siitä, että parhaimmillaan formaalit menetelmät ovat erittäin hyödyllisiä. Empiirinen ohjelmistotutkimus 92 Bauer-Zemanekin hypoteesin perusteluja 4 Pfleegerin ja Hattonin tutkimuksessa 1997 seurattiin noin 200 KLOC kokoisen C- kielisen ohjelman tekoa. Merkittäviä osia ohjelmasta määriteltiin formaalisti. Pfleeger ja Hatton mittasivat tuotteen osien virhetiheyttä sekä projektin aikana että tuotantokäytössä. Bauer-Zemanekin hypoteesin perusteluja 5 Pfleegerin ja Hattonin tulokset olivat: Projektin aikana: Muutoksia / KLOC : Muuttuneita moduuleita Formaalit: 19,6 : 22% Ei-formaalit: 21,0 : 19% Tuotantokäytössä: Muutoksia / KLOC : Muuttuneita moduuleita Formaalit: 0,58 : 0,12% Ei-formaalit: 1,61 : 0,27% Empiirinen ohjelmistotutkimus 93 Empiirinen ohjelmistotutkimus 94 Bauer-Zemanekin hypoteesin perusteluja 6 Pfleegerin ja Hattonin tulokset ovat vakuuttavia varsinkin tuotantokäytössä löytyneiden virheiden osalta. Siitä huolimatta kritiikkiäkin löytyy: Projektiin osallistujien kokemuksesta ei ole tietoa, ei myöskään osallistujen formaalien menetelmien tietotaidosta. Projektissa ei ilmeisesti käytetty tarkastuksia, sillä virheiden elinikä oli pitkä. Tarkastusten käyttö olisi ehkä kutistanut formaalien ja eiformaalien tulosten eroa. Empiirinen ohjelmistotutkimus 95 Bauer-Zemanekin hypoteesin perusteluja 7 Formaaleista menetelmistä on taitettu peistä molempiin suuntiin. Ehkä parhaiten alaa kuvaa seuraava Gerhard, Craigen, Ralston kommentti: There is no simple answer to the question: do the formal methods pay off? All cases involve so many interwoven factors that it is impossible to allocate payoff from formal methods versus other factors. Gerhard et al. Observation on Industrial Practice Using Formal Methods, Proc. Int l Conf. Software Eng., 1993, Empiirinen ohjelmistotutkimus 96 Taina 16

17 3.7. Dyerin hypoteesi Siirtyminen vaatimusmäärittelystä suunnitteluun kasvattaa vaatimusten määrän jopa 50-kertaiseksi. Dyerin hypoteesi on esitelty Glassin kirjassa R. Glass, Facts and Fallacies of Software Engineering. Glass kirjoittaa kirjassaan yrittäneensä saada Dyerin kommentoimaan hypoteesiaan, mutta Glassin mukaan Dyer ei vastannut yhteydenottopyyntöihin. Empiirinen ohjelmistotutkimus 97 Dyerin hypoteesin taustaa Siirtyminen vaatimusmäärittelystä suunnitteluun on samalla iso hyppy abstraktiossa. Vaatimusmäärittelyssä löytyneet vaatimukset eivät riitä suunnitteluun, vaan suunnittelun sivutuotteena löytyy uusia vaatimuksia. Näitä kutsutaan johdetuiksi vaatimuksiksi (derived requirements). Empiirinen ohjelmistotutkimus 98 Dyerin hypoteesin taustaa 2 Johdetut vaatimukset johtuvat erilaisista abstraktiotasoista. Vaatimusmäärittelyn mitä -abstraktio ei riitä suunnittelun miten -abstraktioon. Glassin mukaan johdettuja vaatimuksia voi olla pahimmillaan 50 kertaa alkuperäisiä vaatimuksia enemmän! Empiirinen ohjelmistotutkimus 99 Dyerin hypoteesin perusteluja Dyerin hypoteesia ei ole validoitu, vaikka Glassin mukaan hypoteesi on tunnettu jo vuosikymmeniä. Hypoteesin validointi vaatisi joukon projekteja, joista laskettaisiin vaatimusten lukumäärän suhde johdettujen vaatimusten lukumäärään. Ainakin opiskelijaprojekteissa hypoteesi on todettu useamman kerran oikeaksi. Empiirinen ohjelmistotutkimus Gamman hypoteesi Suunnittelumallien avulla tehtävä uudelleenkäyttö johtaa nopeampaan ja parempaan ylläpitoon. Ohjelmistojen uudelleenkäyttö parantaa parhaimmillaan tuottavuutta ja laatua. Mitä tahansa voidaan käyttää uudestaan: vaatimuksia, suunnittelua, koodia, testejä Suunnittelussa käytetään yleisimmin hyväksi suunnittelumalleja (design patterns), jotka ovat hyväksi havaittuja tapoja ratkaista jokin suunnittelun ongelma. Empiirinen ohjelmistotutkimus 101 Gamman hypoteesin taustaa Suunnittelumallit esiteltiin 1995 Gamman ja kumppaneiden suunnittelumallikirjassa. Mallien kannattajien mukaan mallit parantavat ohjelmoijien tuottavuutta ja koodin laatua, parantavat uusien ohjelmoijíen taitoja näyttämällä valmiita hyviä suunnitelmia, helpottavat suunnittelijoiden välistä kommunikointia, rohkaisevat hyvien ideoiden jakamiseen ja parantavat ohjelmistojen ylläpidettävyyttä. Empiirinen ohjelmistotutkimus 102 Taina 17

18 Gamman hypoteesin taustaa 2 Suunnittelumallit ovat erittäin suosittuja, ja niitä on julkaistu useita satoja. Suosioon vaikuttaa varmasti se, että suunnitteluvaiheeseen ei juuri löydy hyväksi havaittuja tekniikoita. Oppikirja mainitsee suunnittelumallien lisäksi kehykset, jotka eivät ole yhtä yleisiä. Suunnittelumallit ovat juuri tällainen yleisesti käyttökelpoinen tekniikka. Empiirinen ohjelmistotutkimus 103 Gamman hypoteesin perusteluja Prechelt ja Unger tutkivat 1999 ja 2001 ohjatuissa kokeissa, miten suunnittelumallit hyödyntävät ylläpitoa: Ensimmäisessä kokeessa testattiin, vaikuttaako suunnittelumallien kommentointi ylläpitoon. Osallistujat olivat opiskelijoita. Toisessa kokeessa testattiin, vaikuttaako mallien käyttö ylläpidettävyyteen. Osallistujat olivat ammattilaisia. Empiirinen ohjelmistotutkimus 104 Gamman hypoteesin perusteluja 2 Ohjattujen kokeiden tulokset olivat: (1. koe) Mallit kommentoituna koodissa Ł nopea ylläpito: Vahva korrelaatio. (1. koe) Mallit kommentoituna koodissa Ł oikea ylläpito: Vahva korrelaatio. (2. koe) Malleja käytetty koodissa Ł helppo ylläpito: Heikko korrelaatio. 2. kokeessa tulokset olivat positiivisia, jos suunnittelumallin avulla saatiin tehtyä siistimpi ratkaisu kuin ilman suunnittelumalleja. Empiirinen ohjelmistotutkimus 105 Gamman hypoteesin perusteluja 3 Gamman hypoteesin empiiriset todisteet ovat huomattavasti vahvempia kuin monen oppikirjassa listatun lain. Yhtä hyvin voisimme puhua Gamman laista. Suunnittelumallit eivät sovi kaikkiin tilanteisiin. Väärään kohtaan laitettu väärä malli voi pilata koko suunnitelman. Oikein käytettynä suunnittelumallit parantavat ylläpidettävyyttä. Aihepiiriä tutkitaan edelleen. Empiirinen ohjelmistotutkimus 106 Esiteltyjen lakien seurauksia Hyväksi suunnittelijaksi ei tulla pelkällä opiskelulla. Curtisin lain mukaan hyvä suunnittelija hallitsee suvereenisti suunniteltavan ohjelmiston sovellusalueen. Tähän vaaditaan ennen kaikkea kokemusta. Simonin lain mukaan ei-pakollisen tiedon rajoittaminen parantaa suunnittelua. Tällaisen tiedon tunnistus suunnittelussa vaatii ennen kaikkea kokemusta. Empiirinen ohjelmistotutkimus 107 Esiteltyjen lakien seurauksia 2 Modulaarinen lähestymistapa parantaa ja helpottaa suunnittelua. Simonin, Constantinen, Parnasin ja Fitts- Shneidermanin lait johtavat kaikki samaan tulokseen. Lisäksi oppikirjassa on esitelty Denertin laki, jota voidaan käyttää standardoitujen arkkitehtuurien perusteena. Myös tämä laki johtaa samaan tulokseen. Empiirinen ohjelmistotutkimus 108 Taina 18

19 4. Verifiointi ja validointi Verifioinnissa varmennetaan, että järjestelmä toimii speksiensä mukaisesti. Yleensä se muotoillaan kysymykseksi Kehitämmekö järjestelmää oikein? Validoinnissa varmennetaan, että järjestelmä täyttää sille asetetut tarpeet. Yleensä se muotoillaan kysymykseksi Kehitämmekö oikeaa järjestelmää? Verifiointia ja validointia (V&V) tehdään koko projektin keston ajan. Empiirinen ohjelmistotutkimus 109 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 ohjelma antaa niillä. Muita V&V-tekniikoita ovat esimerkiksi mallinnus, simulaatiot ja todistaminen. Empiirinen ohjelmistotutkimus 110 Verifioinnin ja validoinnin luonne V&V on laadunvarmistusta, ryhmätyötä ja rinnakkaisia menetelmiä. Miksi? Fagan: Tarkastukset parantavat merkittävästi tuotteen laatua. Hetzel-Myers: Parhaat tulokset saadaan yhdistelemällä V&V:n tekniikoita. Weinberg: Ohjelmoijan ei pidä testata omaa koodiaan. Dijkstra: Täydellinen testaus ei onnistu. Empiirinen ohjelmistotutkimus 111 V&V:n lait ja hypoteesit Oppikirjassa esitellyt V&V:n lait ovat käytännöllisiä. Ne eroavat luonteeltaan 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ä. Empiirinen ohjelmistotutkimus 112 V&V:n lait ja liittyminen ohjelmistotekniikkaan 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 Empiirinen ohjelmistotutkimus 113 V&V:n lait ja liittyminen ohjelmistotekniikkaan 2 Maysin hypoteesi: mustalaatikkotestaus Hoaren hypoteesi (ei käsitellä): verifiointi Sackmanin ensimmäinen laki (ei käsitellä): virheenjäljitys Dijkstran laki: mustalaatikkotestaus, lasilaatikkotestaus Weinbergin laki: mustalaatikkotestaus Pareto-Zipf laki: ohjelmistotekniikka Gray-Serlin laki (ei käsitellä): rasitustestaus Empiirinen ohjelmistotutkimus 114 Taina 19

20 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. Itse asiassa varsinkin lasilaatikkotestauksesta olisi enemmänkin lakeja, mutta ne ovat eot:n kannalta harmaata aluetta. Lasilaatikkotestauksen lait perustuvat matematiikkaan, mutta niiden hyötyä arvioidaan empiirisin kokein. Empiirinen ohjelmistotutkimus 115 Empiirinen ohjelmistotutkimus 116 V&V:n lait ja liittyminen ohjelmistotekniikkaan 5 Eniten kaivataan 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. Empiirinen ohjelmistotutkimus Faganin laki Tarkastukset parantavat merkittävästi tuottavuutta, laatua ja projektien stabiiliutta. Fagan esitti 1970-luvulla IBM:llä, miten dokumenteista voidaan tehokkaasti löytää virheitä muodollisilla tarkastustilaisuuksilla. Tarkastusten hyvyys on yksi vahvimmista EOT:n laeista. Sitä on sekä validoitu että varmennettu käytössä yli 30 vuoden ajan. Empiirinen ohjelmistotutkimus 118 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. 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. Tarkastusten sijaan muodissa ovat kevyemmät katselmointitekniikat, kuten pariohjelmointi ja koodin läpikäynti. Toki nämäkin parantavat laatua. Empiirinen ohjelmistotutkimus 119 Empiirinen ohjelmistotutkimus 120 Taina 20

21 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. Empiirinen ohjelmistotutkimus 121 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% löydetyistä virheistä on löydetty tarkastuksissa. Empiirinen ohjelmistotutkimus 122 Faganin lain teoria Faganin lain tehokkuus johtuu 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 on vaikeaa. Käännösaikana evaluoitavien rakenteiden (esim. makrot ja aspektit) virheiden löytäminen tarkastuksilla on lähes mahdotonta Porter-Vottan laki Tarkastusten tehokkuus on melko riippumaton niiden toteutustavasta. 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. Empiirinen ohjelmistotutkimus 123 Empiirinen ohjelmistotutkimus 124 Porter-Vottan lain taustaa 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? Empiirinen ohjelmistotutkimus 125 Porter-Vottan lain taustaa 2 Intuitiivisesti tuntuisi, että yritykselle räätälöity tarkastusprosessi antaisi yleistä parempia tuloksia. Porter-Vottan lain mukaan intuitio on osin väärässä. Tarkastusvariaatioiden väliset erot ovat pienet. Merkittävin poikkeus laista ovat näkökulmapohjaiset tarkastukset, joita käsitellään Basilin laissa. Empiirinen ohjelmistotutkimus 126 Taina 21

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

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

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

4. Verifiointi ja validointi. Kevät 2005 Empiirinen ohjelmistotutkimus / Taina. Kevät 2005 Empiirinen ohjelmistotutkimus / Taina 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ä

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

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

Ohjelmistojen mallintaminen, mallintaminen ja UML

Ohjelmistojen mallintaminen, mallintaminen ja UML 582104 Ohjelmistojen mallintaminen, mallintaminen ja UML 1 Mallintaminen ja UML Ohjelmistojen mallintamisesta ja kuvaamisesta Oliomallinnus ja UML Käyttötapauskaaviot Luokkakaaviot Sekvenssikaaviot 2 Yleisesti

Lisätiedot

Copyright by Haikala. Ohjelmistotuotannon osa-alueet

Copyright by Haikala. Ohjelmistotuotannon osa-alueet Copyright by Haikala Ohjelmistotuotannon osa-alueet Ohjelmiston elinkaari 1. Esitutkimus, tarvekartoitus, kokonaissuunnittelu, järjestelmäsuunnittelu (feasibility study, requirement study, preliminary

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

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

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

Tietojärjestelmän osat

Tietojärjestelmän osat Analyysi Yleistä analyysistä Mitä ohjelmiston on tehtävä? Analyysin ja suunnittelun raja on usein hämärä Ei-tekninen näkökulma asiakkaalle näkyvien pääkomponenttien tasolla Tietojärjestelmän osat Laitteisto

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

Suunnitteluvaihe prosessissa

Suunnitteluvaihe prosessissa Suunnittelu Suunnitteluvaihe prosessissa Silta analyysin ja toteutuksen välillä (raja usein hämärä kumpaankin suuntaan) Asteittain tarkentuva Analyysi -Korkea abstraktiotaso -Sovellusläheiset käsitteet

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

2. Ohjelmistotuotantoprosessi

2. Ohjelmistotuotantoprosessi 2. Ohjelmistotuotantoprosessi Peruskäsitteet: prosessimalli: mahdollisimman yleisesti sovellettavissa oleva ohjeisto ohjelmistojen tuottamiseen ohjelmistotuotantoprosessi: yrityksessä käytössä oleva tapa

Lisätiedot

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

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

Ohjelmistotuotanto vs. muut insinööritieteet. (Usein näennäinen) luotettavuus ja edullisuus

Ohjelmistotuotanto vs. muut insinööritieteet. (Usein näennäinen) luotettavuus ja edullisuus Yhteenveto Ohjelmistotuotanto vs. muut insinööritieteet Monimutkaisuus Näkymättömyys (Usein näennäinen) luotettavuus ja edullisuus Muunnettavuus Epäjatkuvuus virhetilanteissa Skaalautumattomuus Copyright

Lisätiedot

Prosessimalli. 2. Ohjelmistotuotantoprosessi. Prosessimallin vaihejako. Prosessimallien perustehtävät. Ohjelmiston suunnittelu. Vaatimusmäärittely

Prosessimalli. 2. Ohjelmistotuotantoprosessi. Prosessimallin vaihejako. Prosessimallien perustehtävät. Ohjelmiston suunnittelu. Vaatimusmäärittely 2. Ohjelmistotuotantoprosessi Peruskäsitteet: prosessimalli: mahdollisimman yleisesti sovellettavissa oleva ohjeisto ohjelmistojen tuottamiseen ohjelmistotuotantoprosessi: yrityksessä käytössä oleva tapa

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

5. Järjestelmämallit. Mallinnus

5. Järjestelmämallit. Mallinnus 5. Järjestelmämallit Käyttäjävaatimukset pitää kirjoittaa luonnollisella kielellä. Niitä lukevat myös asiakkaat ja loppukäyttäjät. Järjestelmävaatimukset kannattaa kirjoittaa jollain rakenteisella kuvaustavalla.

Lisätiedot

Käsitteistä. Reliabiliteetti, validiteetti ja yleistäminen. Reliabiliteetti. Reliabiliteetti ja validiteetti

Käsitteistä. Reliabiliteetti, validiteetti ja yleistäminen. Reliabiliteetti. Reliabiliteetti ja validiteetti Käsitteistä Reliabiliteetti, validiteetti ja yleistäminen KE 62 Ilpo Koskinen 28.11.05 empiirisessä tutkimuksessa puhutaan peruskurssien jälkeen harvoin "todesta" ja "väärästä" tiedosta (tai näiden modernimmista

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

Mallinnus. 5. Järjestelmämallit. Abstraktiot. Mallinnuksen etuja. Arkkitehtuurimalli. Yhteysmallit. Ohjelmistotuotanto, järjestelmämallit Kevät 2005

Mallinnus. 5. Järjestelmämallit. Abstraktiot. Mallinnuksen etuja. Arkkitehtuurimalli. Yhteysmallit. Ohjelmistotuotanto, järjestelmämallit Kevät 2005 5. Järjestelmämallit Käyttäjävaatimukset pitää kirjoittaa luonnollisella kielellä. Niitä lukevat myös asiakkaat ja loppukäyttäjät. Järjestelmävaatimukset kannattaa kirjoittaa jollain rakenteisella kuvaustavalla.

Lisätiedot

ohjelman arkkitehtuurista.

ohjelman arkkitehtuurista. 1 Legacy-järjestelmällä tarkoitetaan (mahdollisesti) vanhaa, olemassa olevaa ja käyttökelpoista ohjelmistoa, joka on toteutettu käyttäen vanhoja menetelmiä ja/tai ohjelmointikieliä, joiden tuntemus yrityksessä

Lisätiedot

Oleelliset vaikeudet OT:ssa 1/2

Oleelliset vaikeudet OT:ssa 1/2 Oleelliset vaikeudet OT:ssa 1/2 Monimutkaisuus: Mahdoton ymmärtää kaikki ohjelman tilat Uusien toimintojen lisääminen voi olla vaikeaa Ohjelmista helposti vaikeakäyttöisiä Projektiryhmän sisäiset kommunikointivaikeudet

Lisätiedot

Tämän lisäksi listataan ranskalaisin viivoin järjestelmän tarjoama toiminnallisuus:

Tämän lisäksi listataan ranskalaisin viivoin järjestelmän tarjoama toiminnallisuus: Dokumentaatio, osa 1 Tehtävämäärittely Kirjoitetaan lyhyt kuvaus toteutettavasta ohjelmasta. Kuvaus tarkentuu myöhemmin, aluksi dokumentoidaan vain ideat, joiden pohjalta työtä lähdetään tekemään. Kuvaus

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

Yhteenvetoa, pieniä laajennuksia, tulevaisuuden haasteita

Yhteenvetoa, pieniä laajennuksia, tulevaisuuden haasteita Yhteenvetoa, pieniä laajennuksia, tulevaisuuden haasteita 581259 Ohjelmistotuotanto 378 Lemström, 2006-2011 581259 Ohjelmistotuotanto Kiitos Tuomolle kuvasta 379 Ohjelmistotuotannon perustehtävät projektinhallinta:

Lisätiedot

Uudelleenkäytön jako kahteen

Uudelleenkäytön jako kahteen Uudelleenkäyttö Yleistä On pyritty pääsemään vakiokomponenttien käyttöön Kuitenkin vakiokomponentit yleistyneet vain rajallisilla osa-alueilla (esim. windows-käyttöliittymä) On arvioitu, että 60-80% ohjelmistosta

Lisätiedot

Ohjelmistotekniikka - Luento 2

Ohjelmistotekniikka - Luento 2 Ohjelmistotekniikka - Luento 2 Luku 2: Prosessimallit - miten spiraalimalliin päädyttiin - spiraalimallista (R)UP malliin - oman ammattitaidon kehittäminen; PSP ja TSP mallit 1 Luento 2: Prosessimallit

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

Dokumentointi ketterissä menetelmissä

Dokumentointi ketterissä menetelmissä Dokumentointi ketterissä menetelmissä Dokumentointi kuuluu ketteriin menetelmiin niin kuin kaikkeen ohjelmistotuotantoon Dokumentointi itsessään yksi vaatimus, jonka prioriteetti pitää arvioida (asiakkaan

Lisätiedot

Määrittely- ja suunnittelumenetelmät

Määrittely- ja suunnittelumenetelmät Menetelmädokumentti Määrittely- ja suunnittelumenetelmät Versio Päiväys Tekijä Kuvaus 0.01 5.12.01 Pekka Koskinen Alustava sisällysluettelo 0.1 7.12.01 Pekka Koskinen Ensimmäinen luonnos 1.0 11.12.01 Pekka

Lisätiedot

Projektisuunnitelma. KotKot. Helsinki Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos

Projektisuunnitelma. KotKot. Helsinki Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Projektisuunnitelma KotKot Helsinki 22.9.2008 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Kurssi 581260 Ohjelmistotuotantoprojekti (9 + 1 op) Projektiryhmä Tuomas Puikkonen

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

$$$ Raha ratkaisee. $$$ Raha ratkaisee. Ohjelmistotuote. Ohjelmistotekniikan määritelmä

$$$ Raha ratkaisee. $$$ Raha ratkaisee. Ohjelmistotuote. Ohjelmistotekniikan määritelmä $$$ Raha ratkaisee On vaara rakastua tekniikkaan, myös asiakkailla Kaikki pitää pystyä perustelemaan taloudellisesti Projektin toteutus yleensä -> voidaan jättää toteuttamatta, jos ei maksa itseään takaisin

Lisätiedot

Ohjelmistotekniikan menetelmät, kevät 2008

Ohjelmistotekniikan menetelmät, kevät 2008 582101 - Ohjelmistotekniikan menetelmät, kevät 2008 1 Ohjelmistotekniikan menetelmät Methods for Software Engineering Perusopintojen pakollinen opintojakso, 4 op Esitietoina edellytetään oliokäsitteistön

Lisätiedot

Tenttikysymykset. + UML- kaavioiden mallintamistehtävät

Tenttikysymykset. + UML- kaavioiden mallintamistehtävät Tenttikysymykset 1. Selitä mitä asioita kuuluu tietojärjestelmän käsitteeseen. 2. Selitä kapseloinnin ja tiedon suojauksen periaatteet oliolähestymistavassa ja mitä hyötyä näistä periaatteista on. 3. Selitä

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

Ohjelmistotekniikka - Luento 2 Jouni Lappalainen

Ohjelmistotekniikka - Luento 2 Jouni Lappalainen Ohjelmistotekniikka - Luento 2 Jouni Lappalainen Luku 2: Prosessimallit - miten spiraalimalliin päädyttiin - spiraalimallista (R)UP malliin - oman ammattitaidon kehittäminen; PSP ja TSP mallit 1 Luento

Lisätiedot

UML- mallinnus: Tilakaavio

UML- mallinnus: Tilakaavio UML- mallinnus: Tilakaavio Karkea kuvaus UML- kaavioiden käytöstä ohjelmistonkehityksen eri vaiheissa ja tehtävissä. Mallinnus tilakaavioilla Tilakaaviolla kuvataan yhden luokan olioiden tilan muuttumista

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

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

13/20: Kierrätys kannattaa koodaamisessakin

13/20: Kierrätys kannattaa koodaamisessakin Ohjelmointi 1 / syksy 2007 13/20: Kierrätys kannattaa koodaamisessakin Paavo Nieminen nieminen@jyu.fi Tietotekniikan laitos Informaatioteknologian tiedekunta Jyväskylän yliopisto Ohjelmointi 1 / syksy

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

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

TT00AA12-2016 - Ohjelmoinnin jatko (TT10S1ECD)

TT00AA12-2016 - Ohjelmoinnin jatko (TT10S1ECD) TT00AA12-2016 - Ohjelmoinnin jatko (TT10S1ECD) Ohjelmointikäytännöt 21/3/11 Mikko Vuorinen Metropolia Ammattikorkeakoulu 1 Sisältö 1) Mitä on hyvä koodi? 2) Ohjelmointikäytäntöjen merkitys? 3) Koodin asettelu

Lisätiedot

Ohjelmistotekniikan menetelmät, UML

Ohjelmistotekniikan menetelmät, UML 582101 - Ohjelmistotekniikan menetelmät, UML 1 Sisältö DFD- ja sidosryhmäkaavioiden kertaus Oliomallinnus UML:än kaaviotyypit 2 Tietovuokaaviot Data flow diagrams, DFD Historiallisesti käytetyin kuvaustekniikka

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

Software engineering

Software engineering Software engineering Alkuperäinen määritelmä: Naur P., Randell B. (eds.): Software Engineering: A Report on A Conference Sponsored by the NATO Science Committee, NATO, 1968: The establishment and use of

Lisätiedot

käyttötapaukset mod. testaus

käyttötapaukset mod. testaus käyttötapaukset Jari Ojasti Nokia email : jari.ojasti@nokia.com puh : 040 5926 312 Kartta hyväksyntä määrittely suunnittelu suunnittelu mod. testaus integrointi sys. testaus Ylläpito koodaus (toteutus)

Lisätiedot

T Tietojenkäsittelyopin ohjelmatyö Tietokonegrafiikka-algoritmien visualisointi Vaatimustenhallinta

T Tietojenkäsittelyopin ohjelmatyö Tietokonegrafiikka-algoritmien visualisointi Vaatimustenhallinta T-76.115 Tietojenkäsittelyopin ohjelmatyö Sisältö Tämä on dokumentti esittelee tietokonegrafiikkaalgoritmien visualisointijärjestelmän kehitysprojektissa käytettävän vaatimustenhallintamenetelmän. Päivämäärä

Lisätiedot

T Käyttäjäkeskeisen tuotekehityksen harjoitustyö kevät 2005

T Käyttäjäkeskeisen tuotekehityksen harjoitustyö kevät 2005 T-121.110 Käyttäjäkeskeisen tuotekehityksen harjoitustyö kevät 2005 Kurssin tavoitteet Muodostaa näkemys käyttäjäkeskeisestä tuotesuunnittelusta Kasvattaa ymmärrystä prosessin vaiheista Tutustua käyttäjäkeskeisen

Lisätiedot

Ohjelmistotekniikan menetelmät, kesä 2008

Ohjelmistotekniikan menetelmät, kesä 2008 582101 - Ohjelmistotekniikan menetelmät, kesä 2008 1 Ohjelmistotekniikan menetelmät Methods for Software Engineering Perusopintojen pakollinen opintojakso, 4 op Esitietoina edellytetään oliokäsitteistön

Lisätiedot

Todistusmenetelmiä Miksi pitää todistaa?

Todistusmenetelmiä Miksi pitää todistaa? Todistusmenetelmiä Miksi pitää todistaa? LUKUTEORIA JA TO- DISTAMINEN, MAA11 Todistus on looginen päättelyketju, jossa oletuksista, määritelmistä, aksioomeista sekä aiemmin todistetuista tuloksista lähtien

Lisätiedot

Ohjelmistojen mallintaminen, kurssikoe esimerkkivastauksia

Ohjelmistojen mallintaminen, kurssikoe esimerkkivastauksia Ohjelmistojen mallintaminen, kurssikoe 15.12. esimerkkivastauksia Tehtävä 1 a: Ohjelmistotuotantoprosessi sisältää yleensä aina seuraavat vaiheet: määrittely, suunnittelu, toteutus, testaus ja ylläpito.

Lisätiedot

Matematiikan ohjelmointi. Joakim von Wright

Matematiikan ohjelmointi. Joakim von Wright Matematiikan ohjelmointi Joakim von Wright Formaali menetelmä käytännössä miten todistetaan ohjelman oikeellisuus? miltä todistus näyttn yttää? isot ohjelmat? miljoona riviä koodia nykyajan ohjelmat? rinnakkaisuus,

Lisätiedot

Arkkitehtuurien tutkimus Outi Räihä. OHJ-3200 Ohjelmistoarkkitehtuurit. Darwin-projekti. Johdanto

Arkkitehtuurien tutkimus Outi Räihä. OHJ-3200 Ohjelmistoarkkitehtuurit. Darwin-projekti. Johdanto OHJ-3200 Ohjelmistoarkkitehtuurit 1 Arkkitehtuurien tutkimus Outi Räihä 2 Darwin-projekti Darwin-projekti: Akatemian rahoitus 2009-2011 Arkkitehtuurisuunnittelu etsintäongelmana Geneettiset algoritmit

Lisätiedot

Täydentäviä muistiinpanoja laskennan rajoista

Täydentäviä muistiinpanoja laskennan rajoista Täydentäviä muistiinpanoja laskennan rajoista Antti-Juhani Kaijanaho 10. joulukuuta 2015 1 Diagonaalikieli Diagonaalikieli on D = { k {0, 1} k L(M k ) }. Lause 1. Päätösongelma Onko k {0, 1} sellaisen

Lisätiedot

Ohjelmien automaattisen verifioinnin reunamailla

Ohjelmien automaattisen verifioinnin reunamailla Ohjelmien automaattisen verifioinnin reunamailla Antti Siirtola Tietotekniikan laitos, Perustieteiden korkeakoulu, Aalto-yliopisto, antti.siirtola@aalto.fi Suomalainen Tiedeakatemia, Nuorten akatemiaklubi,

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

Kurssin aihepiiri: ohjelmistotuotannon alkeita

Kurssin aihepiiri: ohjelmistotuotannon alkeita Kurssin aihepiiri: ohjelmistotuotannon alkeita [wikipedia]: Ohjelmistotuotanto on yhteisnimitys niille työnteon ja työnjohdon menetelmille, joita käytetään, kun tuotetaan tietokoneohjelmia sekä monista

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

Alkukartoitus Opiskeluvalmiudet

Alkukartoitus Opiskeluvalmiudet Alkukartoitus Opiskeluvalmiudet Päivämäärä.. Oppilaitos.. Nimi.. Tehtävä 1 Millainen kielenoppija sinä olet? Merkitse rastilla (x) lauseet, jotka kertovat sinun tyylistäsi oppia ja käyttää kieltä. 1. Muistan

Lisätiedot

Test-Driven Development

Test-Driven Development Test-Driven Development Ohjelmistotuotanto syksy 2006 Jyväskylän yliopisto Test-Driven Development Testilähtöinen ohjelmistojen kehitystapa. Tehdään ensin testi, sitten vasta koodi. Tarkoituksena ei ole

Lisätiedot

Software product lines

Software product lines Thomas Gustafsson, Henrik Heikkilä Software product lines Metropolia Ammattikorkeakoulu Insinööri (AMK) Tietotekniikan koulutusohjelma Asiantuntijateksti 17.11.2013 Sisällys 1 Johdanto 1 2 Software product

Lisätiedot

Ohjelmoinnin perusteet, syksy 2006

Ohjelmoinnin perusteet, syksy 2006 Ohjelmoinnin perusteet, syksy 2006 Esimerkkivastaukset 1. harjoituksiin. Alkuperäiset esimerkkivastaukset laati Jari Suominen. Vastauksia muokkasi Jukka Stenlund. 1. Esitä seuraavan algoritmin tila jokaisen

Lisätiedot

Test-Driven Development

Test-Driven Development Test-Driven Development Syksy 2006 Jyväskylän yliopisto Test-Driven Development Testilähtöinen ohjelmistojen kehitystapa. Tehdään ensin testi, sitten vasta koodi. Tarkoituksena ei ole keksiä kaikkia mahdollisia

Lisätiedot

Johdantoluento. Ohjelmien ylläpito

Johdantoluento. Ohjelmien ylläpito Johdantoluento Ylläpito-termin termin määrittely Ylläpito ohjelmistotuotannon vaiheena Evoluutio-termin määrittely Muita kurssin aiheeseen liittyviä termejä TTY Ohjelmistotekniikka 1 Ohjelmien ylläpito

Lisätiedot

Ohjelmointitekniikka lyhyesti Survival Kit 1 Evtek KA ELINKAARIMALLEISTA

Ohjelmointitekniikka lyhyesti Survival Kit 1 Evtek KA ELINKAARIMALLEISTA Ohjelmointitekniikka lyhyesti Survival Kit. Vesiputousmalli ELINKAARIMALLEISTA. Ohjelmiston elinkaari Ohjelmiston elinkaarella (life cycle) tarkoitetaan aikaa, joka kuluu ohjelmiston kehittämisen aloittamisesta

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

Teoreettisen viitekehyksen rakentaminen

Teoreettisen viitekehyksen rakentaminen Teoreettisen viitekehyksen rakentaminen Eeva Willberg Pro seminaari ja kandidaatin opinnäytetyö 26.1.09 Tutkimuksen teoreettinen viitekehys Tarkoittaa tutkimusilmiöön keskeisesti liittyvän tutkimuksen

Lisätiedot

Ohjelmistojen mallintaminen, kesä 2009

Ohjelmistojen mallintaminen, kesä 2009 582104 Ohjelmistojen mallintaminen, kesä 2009 1 Ohjelmistojen mallintaminen Software Modeling Perusopintojen pakollinen opintojakso, 4 op Esitietoina edellytetään oliokäsitteistön tuntemus Ohjelmoinnin

Lisätiedot

Määrittelyvaihe. Projektinhallinta

Määrittelyvaihe. Projektinhallinta Määrittelyvaihe Projektinhallinta testaus määrittely suunnittelu ohjelmointi käyttöönotto, testaus tuotteenhallinta laadunvarmistus dokumentointi vaatimustenhallinta Määrittely Määrittely, eli kansanomaisesti

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

Sisäänrakennettu tietosuoja ja ohjelmistokehitys

Sisäänrakennettu tietosuoja ja ohjelmistokehitys Sisäänrakennettu tietosuoja ja ohjelmistokehitys Petri Strandén 14. kesäkuuta, 2018 Petri Strandén Manager Cyber Security Services Application Technologies Petri.stranden@kpmg.fi Petri vastaa KPMG:n Technology

Lisätiedot

Ohjelmistotekniikan menetelmät, käyttötapauksiin perustuva vaatimusmäärittely

Ohjelmistotekniikan menetelmät, käyttötapauksiin perustuva vaatimusmäärittely 582101 - Ohjelmistotekniikan menetelmät, käyttötapauksiin perustuva vaatimusmäärittely 1 Vaatimukset ja käyttötapaukset Vaiheittainen mallintaminen ja abstraktiotasot Järjestelmän rajaaminen sidosryhmäkaaviolla

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

Hieman lisää malleista ja niiden hyödyntämisestä

Hieman lisää malleista ja niiden hyödyntämisestä Hieman lisää malleista ja niiden hyödyntämisestä Ohjelmistojen mallintaminen Kesä 2012 (Avoin yliopisto) Toni Ruokolainen, 23.8.2012 Mallit Mallit ovat todellisuuden abstraktioita, jotka on muodostettu

Lisätiedot

Kant Arvostelmia. Informaatioajan Filosofian kurssin essee. Otto Opiskelija 65041E

Kant Arvostelmia. Informaatioajan Filosofian kurssin essee. Otto Opiskelija 65041E Kant Arvostelmia Informaatioajan Filosofian kurssin essee Otto Opiskelija 65041E David Humen radikaalit näkemykset kausaaliudesta ja siitä johdetut ajatukset metafysiikan olemuksesta (tai pikemminkin olemattomuudesta)

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

Ohjelmistotuotanto, prosessit Syksy Ohjelmistotuotantoprosessi. Prosessimalli. Prosessimallien perustehtävät. Prosessimallin vaihejako

Ohjelmistotuotanto, prosessit Syksy Ohjelmistotuotantoprosessi. Prosessimalli. Prosessimallien perustehtävät. Prosessimallin vaihejako 2. Ohjelmistotuotantoprosessi peruskäsitteet: prosessimalli: mahdollisimman yleisesti sovellettavissa oleva ohjeisto ohjelmistojen tuottamiseen ohjelmistotuotantoprosessi: yrityksessä käytössä oleva tapa

Lisätiedot

IT2015 EKT ERITYISEHTOJA OHJELMISTOJEN TOIMITUKSISTA KETTERIEN MENETELMIEN PROJEKTEILLA LUONNOS

IT2015 EKT ERITYISEHTOJA OHJELMISTOJEN TOIMITUKSISTA KETTERIEN MENETELMIEN PROJEKTEILLA LUONNOS 20.4.2015 IT2015 EKT ERITYISEHTOJA OHJELMISTOJEN TOIMITUKSISTA KETTERIEN MENETELMIEN PROJEKTEILLA 1 1.1 SOVELTAMINEN Näitä erityisehtoja sovelletaan ohjelmistojen tai niiden osien toimituksiin ketterien

Lisätiedot

812347A Olio-ohjelmointi, 2015 syksy 2. vsk. IX Suunnittelumallit Proxy, Factory Method, Prototype ja Singleton

812347A Olio-ohjelmointi, 2015 syksy 2. vsk. IX Suunnittelumallit Proxy, Factory Method, Prototype ja Singleton 2015 syksy 2. vsk IX Suunnittelumallit Proxy, Factory Method, Prototype ja Singleton Sisältö 1. Johdanto luontimalleihin 2. Proxy 3. Factory Method 4. Prototype 5. Singleton Suunnittelumallit Proxy et.

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

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

Harjoitus 7: NCSS - Tilastollinen analyysi

Harjoitus 7: NCSS - Tilastollinen analyysi Harjoitus 7: NCSS - Tilastollinen analyysi Mat-2.2107 Sovelletun matematiikan tietokonetyöt Syksy 2006 Mat-2.2107 Sovelletun matematiikan tietokonetyöt 1 Harjoituksen aiheita Tilastollinen testaus Testaukseen

Lisätiedot

Sisäänrakennettu tietosuoja ja ohjelmistokehitys

Sisäänrakennettu tietosuoja ja ohjelmistokehitys Sisäänrakennettu tietosuoja ja ohjelmistokehitys Petri Strandén 8. kesäkuuta, 2018 Agenda Ohjelmistokehitys Ohjelmistokehitys vs. konsultointi Vaatimukset Tietosuoja Tietosuoja ohjelmistokehityksessä kiteytettynä

Lisätiedot

Ohjelmistojen virheistä

Ohjelmistojen virheistä Ohjelmistojen virheistä Muutama sana ohjelmistojen virheistä mistä niitä syntyy? Matti Vuori, www.mattivuori.net 2013-09-02 1(8) Sisällysluettelo Ohjelmistojen virheitä: varautumattomuus ongelmiin 3 Ohjelmistojen

Lisätiedot

Simulation and modeling for quality and reliability (valmiin työn esittely) Aleksi Seppänen

Simulation and modeling for quality and reliability (valmiin työn esittely) Aleksi Seppänen Simulation and modeling for quality and reliability (valmiin työn esittely) Aleksi Seppänen 16.06.2014 Ohjaaja: Urho Honkanen Valvoja: Prof. Harri Ehtamo Työn saa tallentaa ja julkistaa Aalto-yliopiston

Lisätiedot

Ohjelmistotuotanto, s

Ohjelmistotuotanto, s Ohjelmistotuotanto Ohjelmiston määrittely n tavoitteena on selvittää ohjelmistolle asetettavat vaatimukset niin yksityiskohtaisesti, että niiden perusteella voidaan tuottaa haluttu ohjelmisto. Lineaarisissa

Lisätiedot

Testaajan eettiset periaatteet

Testaajan eettiset periaatteet Testaajan eettiset periaatteet Eettiset periaatteet ovat nousseet esille monien ammattiryhmien toiminnan yhteydessä. Tämä kalvosarja esittelee 2010-luvun testaajan työssä sovellettavia eettisiä periaatteita.

Lisätiedot

Sisällys. Ratkaisumallien historia. Ratkaisumalli. Ratkaisumalli [2] Esimerkki: Composite [2] Esimerkki: Composite. Jaakko Vuolasto 25.1.

Sisällys. Ratkaisumallien historia. Ratkaisumalli. Ratkaisumalli [2] Esimerkki: Composite [2] Esimerkki: Composite. Jaakko Vuolasto 25.1. Sisällys Ratkaisumallien historia Jaakko Vuolasto 25.1.2001! Ratkaisumalli! Christopher Alexander! Ohjelmistotuotannosta arkkitehtuuriin! Henkilöhistoriaa! Ensimmäisiä käyttökokemuksia! Yhteenveto 25.1.2001

Lisätiedot

Analyysi, staattinen mallintaminen, kohdealueen malli ja luokkakaavio

Analyysi, staattinen mallintaminen, kohdealueen malli ja luokkakaavio Analyysi, staattinen mallintaminen, kohdealueen malli ja luokkakaavio Analyysi Tarkentaa ja jäsentää vaatimusmäärittelyä, vastaa kysymykseen MITÄ järjestelmän tulisi tehdä. Suoritetaan seuraavia tehtäviä:

Lisätiedot

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

Testaussuunnitelma. Koskelo. Helsinki Ohjelmistotuotantoprojekti. HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Testaussuunnitelma Koskelo Helsinki 16.12.2004 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Kurssi 581260 Ohjelmistotuotantoprojekti (6 ov) Projektiryhmä Tom Bertell Johan

Lisätiedot

Kuvitettu YVA- opas 2018

Kuvitettu YVA- opas 2018 Kuvitettu YVA- opas 2018 Oppaan sisältö I Perusasiat YVA-menettelystä s. 4 II Vähän täsmennystä tekijöistä ja osallistumisesta s. 8 III YVA-menettelyn sisällöt s. 13 IV Arvioinnin tulokset ja kuinka niihin

Lisätiedot

Laadullinen tutkimus. KTT Riku Oksman

Laadullinen tutkimus. KTT Riku Oksman Laadullinen tutkimus KTT Riku Oksman Kurssin tavoitteet oppia ymmärtämään laadullisen tutkimuksen yleisluonnetta oppia soveltamaan keskeisimpiä laadullisia aineiston hankinnan ja analysoinnin menetelmiä

Lisätiedot