Projektinhallinnan merkitys

Koko: px
Aloita esitys sivulta:

Download "Projektinhallinnan merkitys"

Transkriptio

1 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 laadinta, riskien hallinta, henkilöhallinto, projektin seuranta. Projektinhallinnan merkitys kuuluu kaikkiin projekteihin. Ilman sitä projektit myöhästyvät, kustannukset ylittyvät, riskeihin ei varauduta ja laatu kärsii. Myös ketterissä prosessimalleissa on projektinhallintaa, vaikka niiden kuvauksissa siitä ei ehkä puhuta. Projektinhallinnan lait käsittelevät työvaiheen vaikutusta projekteihin. 1 2 Projektin hallinnan lakien suhde ohjelmistotuotantoon Projektinhallinnan lakien suhde ohjelmistotuotantoon 2 Seuraavassa ovat oppikirjassa esitellyt projektinhallinnan lait ja hypoteesit : Sackmanin toinen laki: henkilöhallinto Nelson-Jonesin laki: henkilöhallinto Boehmin kolmas laki: aikataulun laadinta, koko- ja kustannusarviot DeMarco-Glassin laki: koko- ja kustannusarviot Humphreyn laki: aikataulun laadinta, riskien hallinta, projektin seuranta Brooksin laki: henkilöhallinto, aikataulun laadinta Baumoilin laki (ei käsitellä): taloushallinto(!) Boehmin hypoteesi: riskien hallinta Woodfieldin laki: koko- ja kustannusarviot, aikataulun laadinta, riskien hallinta, projektin seuranta 3 4 Projektinhallinnan suhde ohjelmistotuotantoon Sackmanin toinen laki Projektinhallinnan lait kattavat aika hyvin kaikki projektinhallinnan työvaiheet. Tämä on luonnollista, sillä projektinhallintaa on aika helppo seurata tapaustutkimuksilla. Sen sijaan ohjattujen kokeiden tekeminen ei useimmiten onnistu. Ohjelmistotuotantoprojektien työntekijöiden tehokkuus vaihtelee merkittävästi. Sackmanin toinen laki on eräs vanhimmista ohjelmistotekniikan laeista. Sackman, Erikson ja Grant esittelivät sen Lain mukaan työntekijöiden kyvykkyydessä on erittäin merkittäviä eroja

2 Sackmanin toisen lain taustaa Sackmanin toisen lain taustaa 2 Sackmanin toinen laki on syntynyt Sackmanin ensimmäisen lain sivutuotteena. Sackmanin ensimmäinen laki käsitteli online- ja offline-virheenjäljityksen eroa. Sitä ei käsitelty kurssilla. Kuten toisinaan käy, Sackmanin toinen laki ohitti merkittävyydessä selvästi alkuperäisen ensimmäisen lain. Sackmanin toinen laki on intuitiivisesti selvä kaikille. Ihmiset ovat erilaisia, joten myös työpanokset ovat erilaisia. Sen sijaan osallistujien erojen suuruus yllättää. Erot voivat olla 25-kertaiset! Mikään uusi menetelmä ei anna näin isoja eroja, joten oikeiden henkilöiden palkkaaminen on tärkein projektien onnistumisen voimavara. 7 8 Sackmanin toisen lain perusteluja Sackman et al analysoivat ensimmäisen lain validoinnin yhteydessä 12 kokeneen ohjelmoijan työsuoritusta. Tulokset olivat erittäin yllättävät. Tulosten mukaan parhaat työntekijät voivat olla yli 25 kertaa huonoimpia työntekijöitä tehokkaampia. Kokeen yksityiskohdat ovat seuraavalla kalvolla: 9 Sackmanin toisen lain perusteluja 2 Mitattava suure Koodausaika (tunteja) Virheenjäljitysaika (tunteja) CPU-aika (sekunteja) Ohjelman koko (LOC) Suoritusaika (sekunteja) Paras tulos 651 0, Huonoin tulos ,0 Vaihteluväli Sackmanin toisen lain perusteluja 3 Sackmanin toisen lain tuloksia on kritisoitu. 12 ohjelmoijan otos on pieni. Ääripäiden etäisyyden laskeminen korostaa vaihtelua pienellä otoksella. Kaikki kokeessa olijat eivät käyttäneet samaa ohjelmointikieltä. Ottamalla kritiikki paremmin huomioon virheenjäljitykselle saadaan 7:1 suhde. 11 Sackmanin toisen lain perusteluja 4 Vaikka koejärjestelyjen anomaliat otetaan huomioon, tulokset ovat silti hurjia. Kaikki kokeeseen osallistuneet ovat olleet ammattilaisia, ja siitä huolimatta tehokkuudessa on seitsenkertainen ero. Sackmanin tuloksia ei ole validoitu myöhemmin. Ilmeisesti kukaan ei odota tulosten muuttuvan erityisemmin. 12 2

3 Sackmanin toisen lain teoria 6.2. Nelson-Jonesin laki Ohjelmointi ja virheenjäljitys ovat esimerkkejä luovasta toiminnasta. On luonnollista, että toiminnassa on eroja ihmisten välillä. Mielenkiintoisempaa on, miksi erot ovat näin suuria. Tuskin missään muussa toiminnassa saadaan ammattilaisten välille seistenkertaisia eroja. Tähän oppikirja ei anna vastausta. 13 Monet tekijät vaikuttavat ohjelmistotuotantoprojektien työntekijöiden tehokkuuteen. Siinä missä Sackmanin laki esittää, että työntekijöissä on isoja eroja, Nelson- Jonesin laki yrittää selittää niitä tekijöitä, miksi näin on. Nelson-Jonesin laki sanoo myös, että erojen syyt eivät ole vain henkilöissä. 14 Nelson-Jonesin lain taustaa Nelson-Jonesin lain perusteluja On selvää, että tuottavuus riippuu muustakin kuin yleisestä tiedosta. Projektissa käytettävien tekniikoiden hallinta, työympäristö, projektin tyyppi ja oma motivaatio ovat tekijöitä, jotka vaikuttavat työtehoon. Projektipäälliköillä on vaikea tehtävä löytää sellaiset työntekijät, jotka ovat parhaimmillaan tietyssä projektissa. 15 Nelson-Jonesin laki sisältää Nelsonin 1964 tekemän tutkimuksen ja Jonesin 2000 tekemän tutkimuksen. Kokeilla on siis 36v ero, mutta tuloksilla ei. Nelsonin tapaustutkimuksiin perustuvan tutkimuksen mukaan tuottavuus on ainakin 15 tekijän summa. Jonesin 600 projektin konsultointiin perustuva tulos sanoo tekijöiksi Nelson-Jonesin lain perusteluja 2 Jones jaottelee mm. projektit seuraavien tekijöiden mukaan: Tehtävän ohjelmatuotteen tyyppi (22kpl): ei-proseduraalinen, applet, interaktiivinen sovellus, ym. Projektin luonne (10kpl): uusi projekti, tuotteen parannus, ylläpito ym. Projektin tavoite (10kpl): aliohjelma, moduuli, tuhottava proto ym. 17 Nelson-Jonesin lain perusteluja 3 Projektin luokka (17kpl): henkilökohtainen ohjelmisto yksityiseen käyttöön, henkilökohtainen usean käyttäjän ohjelmisto, akateeminen ohjelmisto, paikallinen yhden käyttäjän ohjelmisto ym. Kaikkiaan Jones saa tulokseksi jo neljällä parametrilla 10x10x17x22 = tyyppiä projekteja. Oikea luku on hiukan pienempi, sillä tekijät eivät ole toisistaan riippumattomia. 18 3

4 Nelson-Jonesin lain teoria 6.3. Boehmin kolmas laki Ohjelmistojen ja järjestelmien monimuotoisuus johtuu niiden käyttöympäristöjen monimuotoisuudesta. Lisäksi jokainen ohjelmistoprojekti on erilainen, sillä täsmälleen samaa tuotetta ei kannata speksata ja toteuttaa kahdesti. Projektien ja ympäristön erilaisuus tulee huomioida projektinhallinnassa. 19 Kehitystyöhön vaadittava työmäärä on tehtävän tuotteen koon (eilineaarinen) funktio. Boehmin kolmas laki on ohjelmistoyhtälöiden peruslaki. Laki selittää, miten meidän on mahdollista arvioida edes jollain tarkkuudella ohjelmistojen tekekemisen kustannuksia ennen ohjelmistoprojektin alkua. 20 Boehmin kolmannen lain taustaa Boehmin kolmannen lain perusteluja Boehm esitteli 1981 ehkä merkittävimmän ohjelmistoyhtälöperheen, COCOMOn (Constructive Cost Model). COCOMO, kuten muutkin ohjelmistoyhtälöt, vaatii ohjelmiston kokoarvion. Tämä arvio muunnetaan sitten ohjelmiston kehitystyön kustannusarvioksi. 21 COCOMOn validoinnissa Boehm analysoi 63 teollisuuden projektia. Boehm tutki projektien keston ja ohjelmakoon välistä korrelaatiota. Näin hän päätyi yleiseen kaavaan: E = c x S g, ja T = 2,5 x E h E = työmäärä (htk), S = koko (KLOC), T = käytetty aika (kk), c,g,h = vakioita. 22 Boehmin kolmannen lain perusteluja 2 Boehmin työn lisäksi usea tutkija on kehitellyt omia ohjelmistoyhtälöitä. Kaikki nämä yhtälöt perustuvat päättyneiden projektien analyysiin. Ehkä mielenkiintoisimmat viimeisimmät tulokset ovat Putnamin ja Myersin kaavat vuodelta Boehmin kolmannen lain perusteluja 3 Putnam ja Myers analysoivat omaan kaavaansa yli 4000 ohjelmistoprojektia. Heidän kaavansa seuraavat samaa eksponentiaalista mallia kuin COCOMOn kaavat. Vain kertoimet eroavat Boehmin kertoimista. Samoin muilla ohjelmistoyhtälöitä kehittäneillä kaavat ovat eksponentiaalisia. 24 4

5 Boehmin kolmannen lain teoria Kuten aikaisemmista laeista (Simonin laki, McCaben hypoteesi) on havaittu, ohjelman kompleksisuus korreloi parhaiten ohjelman koon kanssa. Tästä seuraa koon ja kustannuksen yhteys. Lisäksi ohjelman kompleksisuus moduulien liittymien määrän kanssa. Liittymien määrä kasvaa lineaarista nopeammin koon kasvaessa DeMarco-Glassin laki Projektin kustannusarviot jäävät helposti liian mataliksi. Kaikille ohjatuille ohjelmistotuotantoprojekteille pitää tehdä koko- ja kustannusarviot. DeMarcon 1982 julkaistun artikkelin ja Glassin vuosituhannen vaihteen aikoihin tehtyjen tulosten mukaan arviot jäävät järjestään liian pieniksi. Ohjelmisto ei pysy sille asetetuissa raameissa. 26 DeMarco-Glassin lain taustaa DeMarco-Glassin lain taustaa 2 Arvioita tarvitaan ja niitä tehdään yleensä projektin elinkaaren alussa, usein jopa ennen vaatimusmäärittelyä. Näin ollen arviot tehdään ennen kuin on täysin ymmärretty tehtävää ongelmaa ja toimintaympäristöä. Näin ei ole ihme, että arviot menevät helposti vikaan. Miten ne voisivat yleensä onnistua noilla ehdoilla? 27 Järkevä paikka arviolle olisi suunnitteluvaiheen jälkeen, sillä vasta silloin voidaan arvioida, miten annettu ongelma ratkaistaan, miten paljon toteutetaan itse, mitä meillä on jo valmiina ja miten paljon ostetaan. Jopa tällaisessa tapauksessa arvio voi vanhentua, saati sitten silloin, kun se tehdään ennen vaatimusmäärittelyä. 28 DeMarco-Glassin lain taustaa 3 DeMarco-Glassin lain perusteluja Usein aikataulujen suunnittelussa toteutuu Parkinsonin efekti: aikatauluun lisätty joustovara tulee aina käytettyä. Parkinsonin efekti on seuraus yleisemmästä organisaatiolaista: jokaisella organisaatiolla on taipumus pitää itsensä täystyöllistettynä. DeMarcon (1982) mukaan vain ammattiarvioijien pitäisi tehdä arvioita. 29 Myöhästyneiden projektien tutkimuksessaan 1998 Glass määrittelee karanneet projektit (runaway projects) sellaisiksi, jotka ylittävät kustannusarvionsa vähintään 30%. Ei tiedetä, onko karanneiden projektien lukumäärä kasvussa vai vähenemässä. Ilmeisesti ainakin aikataulun ylityksiä on enemmän kuin kustannusten ylityksiä. 30 5

6 DeMarco-Glassin lain perusteluja 2 Myöhemmässä tutkimuksessaan Glass listaa syitä, miksi kustannusarviot jäävät liian mataliksi: liika optimistisuus, arviot tehdään liian aikaisin, arvion tekijät eivät osallistu kehitystyöhön: asiakas tai markkinointi vastaa arviosta, arviota ei säädetä projektin edetessä, kukaan ei ole vastuussa aikataulusta. 31 DeMarco-Glassin lain teoria Arviointien tekeminen on vaikeaa. Kokonaisuuteen kuuluu paljon pieniä yksityiskohtia. Arvioija unohtaa yksityiskohtia helpommin kuin lisää ylimääräisiä. Yllätykset (tai riskit) kuuluvat jokaiseen projektiin. Vaikka yllätyksiin varauduttaisiin miten hyvin, ne vaikuttavat aina projektin aikatauluun Humphreyn laki Humphreyn lain taustaa Kehittyneet prosessit ja henkilökohtainen kurinalaisuus parantavat suunnittelua, lisäävät tuottavuutta ja vähentävät virheitä. Humphrey on parhaiten tunnettu mittauksiin perustuvasta prosessimallista PSP ja prosessien kypsyysmallista CMM. Humphrey on yksi maailman merkittävimmistä ohjelmistotuotannon kehittäjistä. 33 Humphreyn laki ja ennen kaikkea lakiin johtanut työ on yksi merkittävimmistä ohjelmistotuotannolle tehdyistä asioista. Humphreyn työn ansiosta ymmärryksemme kurinalaisista kehittyneistä prosesseista on korkealla tasolla. CMM on sittemmin saanut monia johdannaisia, mutta Humphreyn aloittama on alkuperäinen. 34 Humphreyn lain taustaa 2 Humphreyn lain taustaa 3 Sekä CMM että PSP perustuvat tasojen kautta tapahtuvaan kehitykseen. Tietyllä tasolla oleva henkilökohtainen tai yritysprosessi täyttää sille kyseiselle tasolle asetetut ehdot. Tasoissa voidaan nousta askel kerrallaan. Humphreyn mukaan jokainen askelma parantaa prosessia. 35 CMM:n tasot ovat: 1. Lähtötaso: ei vaatimuksia 2. Toistettava: mm. projektin seuranta 3. Määritelty: mm: katselmoinnit 4. Hallittu: mm. laadunvalvonta 5. Optimoiva: mm. virheiden välttäminen PSP:n tasot ovat: 1. Henkilökohtainen mittaus: mm vikojen laskenta 2. Henkilökohtainen arviointi: mm. kokoarviot 3. Henkilökohtainen laatu: mm. katselmoinnit 4. Skaalautuvuus: syklinen kehitystyö 36 6

7 Humphreyn lain perusteluja Humphreyn lain perusteluja 2 Varsinkin CMM:sta on tehty paljon empiiristä tutkimusta. Seuraavassa on Diazin ja Sligon 1997 Motorolalle tekemä tutkimus CMM:n tasojen vaikutuksesta laatuun. Tutkimuksessa kirjoittajat kävivät 34 projektia ja 13 yritystä läpi. Kypsyystaso CMM 1 CMM 2 CMM 3 CMM 4 Projektien määrä Virheitä/KLOC n/a 4,4 2,1 1,0 Syklin tiivistyskerroin 1,0 3,2 2,7 5,0 Tuottavuuskerroin n/a 1,0 0,8 2,3 Tulokset ovat seuraavalla kalvolla: CMM 5 9 0,6 7,8 2, Humphreyn lain perusteluja 3 Humphreyn lain perusteluja 4 Taulukossa: Syklin pituus kerroin = kuinka paljon nopeampaa kehitystyö on ollut verrattuna vastaavaan vertailuprojektiin. Tuottavuuskerroin = tuottavuuden kasvu CMM:n tasolta tasolle normalisoituna keskimääräiseen kakkostason projektiin. Diaz ja Sligo määrittelevät tuottavuuden kaavalla tehty työmäärä / työhön kulunut aika. 39 Vastaavia tutkimuksia on viime aikoina tehty myös PSP:sta, joskin PSP:ta on lähinnä testattu opiskelijoilla. Tulokset ovat kuitenkin samansuuntaiset kuin CMMtutkimuksissa. PSP-projektit pysyvät paremmin aikataulussa ja tuottavat keskimäärin virheettömämpää koodia kuin tavalliset projektit. 40 Humphreyn lain teoria Oppikirjassa Humphreyn lain teoria on lähinnä filosofista pohtimista: Hyvä laatu ja tuottavuus ovat tavoittelemisen arvoisia ja saavutettavissa kurinalaisella työskentelyllä. Parannuksia ei saavuteta kerralla vaan osana asteittain kehittyvää prosessia. Jokainen oppii parhaiten analysoimalla omaa suoritustaan Brooksin laki Uusien työntekijöiden lisääminen myöhässä olevaan projektiin saa sen myöhästymään lisää. Brooksin laki on todennäköisesti tunnetuin ohjelmistotekniikan laki. Brooks on esittänyt lakinsa 1975 alan klassikkokirjassa F. Brooks, The Mythical Man-Month Esasys on Software Engineering. Addison-Wesley

8 Brooksin lain taustaa Brooksin lain perusteluja Brooksin lain mukaan ohjelmistoprojektissa työmäärä ja kestoaika eivät ole keskenään vaihdettavia mittoja. Tulos pätee sellaisiin ryhmätyöprojekteihin, joissa projektin aikana saatu tietotaito on oleellisessa roolissa. Mitä myöhemmin työntekijöitä lisätään, sitä vahvemmin Brooksin laki vaikuttaa. 43 Brooks perustaa lakinsa kokemuksiinsa OS/360 käyttöjärjestelmästä. Laki on sittemmin Brooksin mukaan validoitu kahdessa tutkimuksessa 1991 ja 1994, joita oppikirja ei esittele sen kummemmin (luultavasti kirjoittajat eivät ole löytäneet kyseisiä artikkeleita). Laki on kuitenkin yksi eot:n kulmakiviä. Kukaan ei kyseenalaista sitä. 44 Brooksin lain perusteluja 2 Brooksin lain teoria Brooksin laki pätee muuallakin kuin ohjelmistotekniikassa. Missä tahansa, missä työpanos riippuu projektin aikana opittavista tiedoista ja taidoista, uusien työntekijöiden lisääminen vähintään vaarantaa projektin aikataulun. Uusien työntekijöiden integrointiin vaadittava työmäärä on lähes aina heidän antamaa työpanosta suurempi. 45 Brooks luettelee kolme syytä, miksi hänen lakinsa on validi: koulutus vaatii lisäresursseja, työtehtävät pitää jakaa uudestaan, kasvanut kommunikointitarve vie vanhoilta työntekijöiltä kehitystyöhön varattua aikaa. Lisäksi on sellaisia tehtäviä, kuten vaatimusmäärittely, joita ei voi tiivistää, vaikka miten lisättäisiin henkilöitä Boehmin hypoteesi Boehmin hypoteesin taustaa Projektin riskit voidaan ratkoa tai niiden vaikutusta voidaan pienentää merkittävästi huomioimalla ne aikaisessa vaiheessa. Boehm on kaiken muun hienon lisäksi tutkinut riskien hallintaa. Hän on muun muassa kehittänyt kaikkien tunteman spiraalimallin, jossa riskien hallinta on erityisen merkittävässä roolissa. 47 Oppikirjan mukaan riskitön projekti on turha projekti. Tässä on paljon perää. Missä tahansa todellisessa projektissa on aina todellisia riskejä. Huolellisinkaan suunnittelu ei voi estää joitain riskejä toteutumasta. Riski saattaa syntyä projektin kestoaikana tai olla sellainen tekijä, johon ei voida vaikuttaa projektissa. 48 8

9 Boehmin hypoteesin perusteluja Boehmin perustelut hypoteesilleen ovat laadullisia. Hän on esitellyt spiraalimallin ja siihen perustuvan Win-Win mallin, joissa molemmissa riskien hallinta on tärkeässä roolissa. Sen sijaan hänen esittämänsä todisteet perustuvat yksittäisiin projekteihin. Tämän johdosta oppikirjan kirjoittajat eivät listaa hypoteesia Boehmin 4. laiksi 49 Boehmin hypoteesin perusteluja 2 Vaikka Boehmin hypoteesi ei ole laki, yleisesti ollaan sitä mieltä, että se pätee. Myös teollisuudessa tehdyistä tapaustutkimuksista näkee, että riskien hallinta auttaa projekteja. Toisaalta järkevien ohjattujen kokeiden tekeminen riskien hallinnasta ei onnistu. Aineiston pitää tulla oikeista projekteista Woodfieldin laki Jokaista 25% ongelman monimutkaisuuden kasvua kohden seuraa 100% kasvu ongelman ratkaisevassa ohjelmistossa. Suhdelukua ei voi kutistaa. Woodfieldin laki, vaikka vähän tunnettu, on eräänlainen ohjelmistotekniikan peruslaki. Itse tulos julkaistiin alun perin 1979 kahden sivun (!) mittaisessa artikkelissa. Woodfieldin lain taustaa Laki perustuu Woodfieldin 1979 tekemään tutkimukseen. Glass on tehnyt lain paremmin tunnetuksi omassa kirjassaan Facts and Fallacies of Software Engineering. Ohjelmistoja on vaikea määritellä, tuottaa ja ylläpitää. Woodfieldin laki selittää, miksi näin on Woodfieldin lain taustaa 2 Woodfieldin lain taustaa 3 Seuraavassa on muutamia Glassin luettelemia kysymyksiä, joihin Woodfieldin laki antaa vastauksen: Miksi työntekijät ovat yrityksen tärkein voimavara? Koska lahjakkuutta tarvitaan ratkaisemaan lisääntyneen monimutkaisuuden asettamat haasteet. Miksi arviointi on vaikeaa? Koska ongelmat vaikuttavat todellisia pienemmiltä. 53 Miksi vaatimusten määrä kasvaa määrittelystä suunnitteluun? Koska vaatimusmäärittely on 25% osaa ja suunnittelu on 100% osaa. Miksi iteratiiviset ja heuristiikkaan perustuvat menetelmät ovat suosittuja? Koska ongelmiin on harvoin yksinkertaisia helppoja ratkaisuja (100%-osa). Jne. Kaikkiaan Glass vastaa Woodfieldin lailla 13 kysymykseen. 54 9

10 Woodfieldin lain perusteluja Woodfield perustelee tuloksensa ohjatulla kokeella. Hän antoi 18 opiskelijalle ohjelmoitavaksi saman algoritmin kaksi eri versiota. Algoritmit tekivät saman asian, mutta toinen oli arvioitu 25% työläämmäksi kuin toinen. Ratkaisuissa oli keskimäärin 100% ero. Woodfieldin lain perusteluja 2 Woodfieldin koe oli varsin suppea, eivätkä tulokset sellaisenaan olisi olleet yleistettävissä. Käytetty ohjelmointikieli oli muun muassa Fortran. Onneksi Woodfieldin laki on evaluoitu jatkuvasti ohjelmistoprojekteissa. Laki on vähän tunnettu, mutta kaikesta huolimatta se näyttää olevan validi Woodfieldin lain teoria Woodfieldin lain ja Dyerin hypoteesin johtopäätös Sen paremmin Woodfield kuin Glass eivät esitä teoriaa tuloksen tueksi. Ehkä parhaiten Woodfieldin lakia selittää Dyerin hypoteesi. Ongelman monimutkaistuminen kasvattaa vaatimuksia. Kasvaneet vaatimukset lisäävät johdettuja vaatimuksia. Johdettujen vaatimuksien seurauksena työmäärä kasvaa. 57 Jos muistatte vain yhden empiirisen ohjelmistotutkimuksen lain, muistakaa Woodfieldin laki tässä muodossa: 25% lisäys määrittelyssä tarkoittaa 100% lisäystä toteutuksessa! Kun muistatte lisäksi Dyerin hypoteesin johdettujen vaatimusten määrästä, olette vähän paremmin valmistautuneita tuleviin projekteihin. 58 Esiteltyjen lakien seurauksia on varmaankin eniten eot:n menetelmin tutkittu osa-alue. Tämä ei ole ihme, sillä managerointi on yksi yritysten päättäjien kannalta mielenkiintoisimmista alueista. CMM:n tasoja luotaavalle projektille annetaan helpommin rahaa kuin jollekin kehitystyön työkalun evaluoinnille. Esiteltyjen lakien seurauksia 2 Vaikka tutkimuksen takana saattaa olla raadollisia syitä, itse tulokset ovat hyviä: Laadukas ohjelmistoprosessi kannattaa. Työntekijöissä on erittäin isoja eroja. Projektin vaatimaa työmäärää on mahdollista arvioida ohjelmistoyhtälöillä. Työntekijöiden lisääminen myöhässä olevaan projektiin ei kannata. Työmäärä ei kasva lineaarisesti

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

Ohjelmistotekniikka kevät 2003 Laatujärjestelmät

Ohjelmistotekniikka kevät 2003 Laatujärjestelmät Laatujärjestelmät Ohjelmistotekniikka kevät 2003 Prosessiajattelu Sisään Prosessi Ulos ohjaus mittaus Laatujärjestelmät Laatujärjestelmät määrittelevät sen, mitkä prosessit täytyy olla määritelty ei sitä,

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

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

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

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

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

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

OHJ-3010 Ohjelmistotuotannon perusteet. Ohjelmistoprojektin hallinta

OHJ-3010 Ohjelmistotuotannon perusteet. Ohjelmistoprojektin hallinta OHJ-3010 Ohjelmistotuotannon perusteet Ohjelmistoprojektin hallinta 1 Sisältö Projektiorganisaatio ja sidosryhmät Ohjelmistoprojektin kulku Projektin suunnittelu Ositus Osallistujat Työmäärän arviointi

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

582104 Ohjelmistojen mallintaminen, Johdatus ohjelmistotuotantoon

582104 Ohjelmistojen mallintaminen, Johdatus ohjelmistotuotantoon 582104 Ohjelmistojen mallintaminen, Johdatus ohjelmistotuotantoon 1 Lyhyt johdatus ohjelmistotuotantoon Ohjelmistotuotanto, ohjelmistoprojektit Miten ohjelmistojen tuottaminen eroaa teollisesta tuotannosta

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

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

Ohjelmistojen mallintaminen, Johdatus ohjelmistotuotantoon

Ohjelmistojen mallintaminen, Johdatus ohjelmistotuotantoon 582104 Ohjelmistojen mallintaminen, Johdatus ohjelmistotuotantoon 1 Lyhyt johdatus ohjelmistotuotantoon Ohjelmistotuotanto, ohjelmistoprojektit Miten ohjelmistojen tuottaminen eroaa teollisesta tuotannosta

Lisätiedot

Koekysymyksiä. Ohjelmistoprosessit ja ohjelmistojen laatu Ohjelmistojen suorituskyky

Koekysymyksiä. Ohjelmistoprosessit ja ohjelmistojen laatu Ohjelmistojen suorituskyky Koekysymyksiä Ohjelmistoprosessit ja ohjelmistojen laatu 30.4.2015 58153003 Ohjelmistojen suorituskyky 1 Kurssikokeeseen tulee neljä koetilaisuudessa vastattavaa kysymystä KOKEESSA VASTATTAVAT KYSYMYKSET

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

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

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

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

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

Projektityö

Projektityö Projektityö 21.10.2005 Projektisuunnitelma Työn ositus Projektisuunnitelman sisältö Kurssin luennoitsija ja projektiryhmien ohjaaja: Timo Poranen (email: tp@cs.uta.fi, työhuone: B1042) Kurssin kotisivut:

Lisätiedot

Tietojärjestelmän kehittäminen syksy 2003

Tietojärjestelmän kehittäminen syksy 2003 Tietojärjestelmän kehittäminen syksy 2003 Ryhmä C2 Väliraportti 2-24.10. Päivi Laiterla Tomas Windahl Toni Nikkanen Antti Lehto 1 Sisällysluettelo Rich Picture...4 Käsitemalli...5 P-tason

Lisätiedot

arviointi edellyttää historiatietoja, esim. mittareiden kalibroimiseksi

arviointi edellyttää historiatietoja, esim. mittareiden kalibroimiseksi Työmäärän arviointi algoritmiset menetelmät asiantuntija-arviot analogiaan perustuvat arviot Parkinsonin laki: "Työ vie kaiken käytettävissä olevan ajan." hinnoittelu kilpailun mukaan top-down arviointi

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

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

Matematiikan tukikurssi

Matematiikan tukikurssi Matematiikan tukikurssi Kurssikerta 4 Jatkuvuus Jatkuvan funktion määritelmä Tarkastellaan funktiota f x) jossakin tietyssä pisteessä x 0. Tämä funktio on tässä pisteessä joko jatkuva tai epäjatkuva. Jatkuvuuden

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

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

AVOIMEN TUOTTEEN HALLINTAMALLIT. Kunnassa toteutettujen tietojärjestelmien uudelleenkäyttö. Yhteentoimivuutta avoimesti 2.12.2011

AVOIMEN TUOTTEEN HALLINTAMALLIT. Kunnassa toteutettujen tietojärjestelmien uudelleenkäyttö. Yhteentoimivuutta avoimesti 2.12.2011 AVOIMEN TUOTTEEN HALLINTAMALLIT Kunnassa toteutettujen tietojärjestelmien uudelleenkäyttö Yhteentoimivuutta avoimesti 2.12.2011 Erikoistutkija, MSc. Tapio Matinmikko, Teknologian tutkimuskeskus VTT 2 Esittäjästä

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

Oletetaan, että virhetermit eivät korreloi toistensa eikä faktorin f kanssa. Toisin sanoen

Oletetaan, että virhetermit eivät korreloi toistensa eikä faktorin f kanssa. Toisin sanoen Yhden faktorin malli: n kpl sijoituskohteita, joiden tuotot ovat r i, i =, 2,..., n. Olkoon f satunnaismuuttuja ja oletetaan, että tuotot voidaan selittää yhtälön r i = a i + b i f + e i avulla, missä

Lisätiedot

58131 Tietorakenteet ja algoritmit (syksy 2015)

58131 Tietorakenteet ja algoritmit (syksy 2015) 58131 Tietorakenteet ja algoritmit (syksy 2015) Harjoitus 2 (14. 18.9.2015) Huom. Sinun on tehtävä vähintään kaksi tehtävää, jotta voit jatkaa kurssilla. 1. Erään algoritmin suoritus vie 1 ms, kun syötteen

Lisätiedot

3. Projektinhallinta. Miksi ohjelmistoprojektin hallinta on erilaista?

3. Projektinhallinta. Miksi ohjelmistoprojektin hallinta on erilaista? 3. Projektinhallinta Ohjelmistoprojektien koon kasvaessa on törmätty projektinhallinnan ongelmiin, kuten jatkuva, osin huonosti hallittu kasvu, myöhästymiset, huono laatu, budjettien ylitykset, projektien

Lisätiedot

Tietorakenteet, laskuharjoitus 7, ratkaisuja

Tietorakenteet, laskuharjoitus 7, ratkaisuja Tietorakenteet, laskuharjoitus, ratkaisuja. Seuraava kuvasarja näyttää B + -puun muutokset lisäysten jälkeen. Avaimet ja 5 mahtuvat lehtisolmuihin, joten niiden lisäys ei muuta puun rakennetta. Avain 9

Lisätiedot

Työmäärän arviointi. Vaihtoehtoja. Sami Kollanus TJTA330 Ohjelmistotuotanto

Työmäärän arviointi. Vaihtoehtoja. Sami Kollanus TJTA330 Ohjelmistotuotanto Työmäärän arviointi Sami Kollanus TJTA330 Ohjelmistotuotanto 20.3. Vaihtoehtoja Arvioidaan projektin jälkeen (onnistuu varmasti) Verrataan karkeasti samanlaisiin aiempiin projekteihin Ositetaan projekti

Lisätiedot

Työmäärän arviointi. Vaihtoehtoja. Arviointiprosessi. Sami Kollanus TJTA330 Ohjelmistotuotanto

Työmäärän arviointi. Vaihtoehtoja. Arviointiprosessi. Sami Kollanus TJTA330 Ohjelmistotuotanto Työmäärän arviointi Sami Kollanus TJTA330 Ohjelmistotuotanto 20.3. Vaihtoehtoja Arvioidaan projektin jälkeen (onnistuu varmasti) Verrataan karkeasti samanlaisiin aiempiin projekteihin Ositetaan projekti

Lisätiedot

Matematiikan tukikurssi

Matematiikan tukikurssi Matematiikan tukikurssi Kurssikerta 6 1 Korkolaskentaa Oletetaan, että korkoaste on r Jos esimerkiksi r = 0, 02, niin korko on 2 prosenttia Tätä korkoastetta käytettään diskonttaamaan tulevia tuloja ja

Lisätiedot

Onnistunut ohjelmistoprojekti

Onnistunut ohjelmistoprojekti Onnistunut ohjelmistoprojekti 2.12.2008 Hermanni Hyytiälä Reaktor Innovations Oy Agenda Yritysesittely Keinoja onnistuneeseen ohjelmistoprojektiin Ihmiset Menetelmät Käytännöt ja työkalut Tulevaisuuden

Lisätiedot

Algebralliset tietotyypit ym. TIEA341 Funktio ohjelmointi 1 Syksy 2005

Algebralliset tietotyypit ym. TIEA341 Funktio ohjelmointi 1 Syksy 2005 Algebralliset tietotyypit ym. TIEA341 Funktio ohjelmointi 1 Syksy 2005 Tällä luennolla Algebralliset tietotyypit Hahmonsovitus (pattern matching) Primitiivirekursio Esimerkkinä binäärinen hakupuu Muistattehan...

Lisätiedot

Luku 6. Dynaaminen ohjelmointi. 6.1 Funktion muisti

Luku 6. Dynaaminen ohjelmointi. 6.1 Funktion muisti Luku 6 Dynaaminen ohjelmointi Dynaamisessa ohjelmoinnissa on ideana jakaa ongelman ratkaisu pienempiin osaongelmiin, jotka voidaan ratkaista toisistaan riippumattomasti. Jokaisen osaongelman ratkaisu tallennetaan

Lisätiedot

Tietojärjestelmän kehittäminen syksy 2003

Tietojärjestelmän kehittäminen syksy 2003 Tietojärjestelmän kehittäminen syksy 2003 Ryhmä C2 Korjattu väliraportti 2-31.10. Päivi Laiterla Tomas Windahl Toni Nikkanen Antti Lehto Sisällysluettelo Rich Picture...3 Rich Picturen

Lisätiedot

Osoitin ja viittaus C++:ssa

Osoitin ja viittaus C++:ssa Osoitin ja viittaus C++:ssa Osoitin yksinkertaiseen tietotyyppiin Osoitin on muuttuja, joka sisältää jonkin toisen samantyyppisen muuttujan osoitteen. Ohessa on esimerkkiohjelma, jossa määritellään kokonaislukumuuttuja

Lisätiedot

Algoritmit 1. Luento 1 Ti Timo Männikkö

Algoritmit 1. Luento 1 Ti Timo Männikkö Algoritmit 1 Luento 1 Ti 10.1.2017 Timo Männikkö Luento 1 Algoritmi Algoritmin toteutus Ongelman ratkaiseminen Algoritmin tehokkuus Algoritmin suoritusaika Algoritmin analysointi Algoritmit 1 Kevät 2017

Lisätiedot

Esimerkkejä vaativuusluokista

Esimerkkejä vaativuusluokista Esimerkkejä vaativuusluokista Seuraaville kalvoille on poimittu joitain esimerkkejä havainnollistamaan algoritmien aikavaativuusluokkia. Esimerkit on valittu melko mielivaltaisesti laitoksella tehtävään

Lisätiedot

Algoritmit 1. Luento 3 Ti Timo Männikkö

Algoritmit 1. Luento 3 Ti Timo Männikkö Algoritmit 1 Luento 3 Ti 17.1.2017 Timo Männikkö Luento 3 Algoritmin analysointi Rekursio Lomituslajittelu Aikavaativuus Tietorakenteet Pino Algoritmit 1 Kevät 2017 Luento 3 Ti 17.1.2017 2/27 Algoritmien

Lisätiedot

SataSPIN. Prosessien parantaminen verkostoitumalla. Porin korkeakouluyksikkö, TTKK

SataSPIN. Prosessien parantaminen verkostoitumalla. Porin korkeakouluyksikkö, TTKK SataSPIN Prosessien parantaminen verkostoitumalla Porin korkeakouluyksikkö, TTKK Ohjelmistoasiantuntemuksen keskus Centre of Software Expertise - CoSE Timo.Varkoi@pori.tut.fi http://www.pori.tut.fi SPI

Lisätiedot

Tietorakenteet ja algoritmit - syksy 2015 1

Tietorakenteet ja algoritmit - syksy 2015 1 Tietorakenteet ja algoritmit - syksy 2015 1 Tietorakenteet ja algoritmit - syksy 2015 2 Tietorakenteet ja algoritmit Johdanto Ari Korhonen Tietorakenteet ja algoritmit - syksy 2015 1. JOHDANTO 1.1 Määritelmiä

Lisätiedot

A ja B pelaavat sarjan pelejä. Sarjan voittaja on se, joka ensin voittaa n peliä.

A ja B pelaavat sarjan pelejä. Sarjan voittaja on se, joka ensin voittaa n peliä. Esimerkki otteluvoiton todennäköisyys A ja B pelaavat sarjan pelejä. Sarjan voittaja on se, joka ensin voittaa n peliä. Yksittäisessä pelissä A voittaa todennäköisyydellä p ja B todennäköisyydellä q =

Lisätiedot

Yhtälöryhmä matriisimuodossa. MS-A0004/A0006 Matriisilaskenta. Tarkastellaan esimerkkinä lineaarista yhtälöparia. 2x1 x 2 = 1 x 1 + x 2 = 5.

Yhtälöryhmä matriisimuodossa. MS-A0004/A0006 Matriisilaskenta. Tarkastellaan esimerkkinä lineaarista yhtälöparia. 2x1 x 2 = 1 x 1 + x 2 = 5. 2. MS-A4/A6 Matriisilaskenta 2. Nuutti Hyvönen, c Riikka Kangaslampi Matematiikan ja systeemianalyysin laitos Aalto-yliopisto 5.9.25 Tarkastellaan esimerkkinä lineaarista yhtälöparia { 2x x 2 = x + x 2

Lisätiedot

Matemaatikot ja tilastotieteilijät

Matemaatikot ja tilastotieteilijät Matemaatikot ja tilastotieteilijät Matematiikka/tilastotiede ammattina Tilastotiede on matematiikan osa-alue, lähinnä todennäköisyyslaskentaa, mutta se on myös itsenäinen tieteenala. Tilastotieteen tutkijat

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

Algoritmit 2. Luento 1 Ti Timo Männikkö

Algoritmit 2. Luento 1 Ti Timo Männikkö Algoritmit 2 Luento 1 Ti 14.3.2017 Timo Männikkö Luento 1 Algoritmi Algoritmin valinta Algoritmin analysointi Algoritmin suoritusaika Peruskertaluokkia Kertaluokkamerkinnät Kertaluokkien ominaisuuksia

Lisätiedot

Ohjelmistotuotanto, k

Ohjelmistotuotanto, k Ohjelmistotuotanto Projektisuunnitelmassa projektin tehtävät aikataulutetaan ja niiden suorittamiseen allokoidaan henkilöresursseja. Tällöin on tiedettävä paljonko resursseja työhön pitäisi allokoida ja

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

Johdatusta ohjelmistotekniikkaan

Johdatusta ohjelmistotekniikkaan Johdatusta ohjelmistotekniikkaan OT:n historiaa 4 vaihetta (1/2) 1. Vaihe (0 60-luvun alku) Vähän tietokoneita Eräajo-tyyppisiä ohjelmia Pääasiassa matemaattisia, pieniä yhden käyttäjän sovelluksia Ei

Lisätiedot

4. Funktion arvioimisesta eli approksimoimisesta

4. Funktion arvioimisesta eli approksimoimisesta 4. Funktion arvioimisesta eli approksimoimisesta Vaikka nykyaikaiset laskimet osaavatkin melkein kaiken muun välttämättömän paitsi kahvinkeiton, niin joskus, milloin mistäkin syystä, löytää itsensä tilanteessa,

Lisätiedot

PS-vaiheen edistymisraportti Kuopio

PS-vaiheen edistymisraportti Kuopio PS-vaiheen edistymisraportti Kuopio Kuopio, PS-vaiheen edistymisraportti, 30.10.2001 Versiohistoria: Versio Pvm Laatija Muutokset 1.0 30.10.2001 Ossi Jokinen Kuopio2001, vain kurssin T-76.115 arvostelun

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

8. Laadunvalvonta. Mitä laatu on?

8. Laadunvalvonta. Mitä laatu on? 8. Laadunvalvonta Ohjelmistojen laatu on parantunut paljon viimeisen 15 vuoden aikana. Tämä näkyy mm. siinä, että asiakkaat ovat keskimäärin tyytyväisempiä tuotteiden toimintaan kuin 90-luvun alussa. Tähän

Lisätiedot

A4.1 Projektityö, 5 ov.

A4.1 Projektityö, 5 ov. A4.1 Projektityö, 5 ov. Kurssin esitietovaatimuksia Kurssin tavoitteista Kurssin sisällöstä Luentojen tavoitteista Luentojen sisällöstä Suoritustavoista ja -vaatimuksista Arvostelukriteereistä Motivointia

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

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 154 Projektinhallinnan laadunvarmistus Projektinhallinnan laadunvarmistus tukee ohjelmistoprojektien ohjaus- ja ylläpitotehtäviä. Projektinhallinnan laadunvarmistustehtäviin kuuluvat seuraavat:

Lisätiedot

STEP 1 Tilaa ajattelulle

STEP 1 Tilaa ajattelulle Työkalu, jonka avulla opettaja voi suunnitella ja toteuttaa systemaattista ajattelutaitojen opettamista STEP 1 Tilaa ajattelulle Susan Granlund Euran Kirkonkylän koulu ja Kirsi Urmson Rauman normaalikoulu

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

2.2.1 Ratkaiseminen arvausta sovittamalla

2.2.1 Ratkaiseminen arvausta sovittamalla 2.2.1 Ratkaiseminen arvausta sovittamalla Esimerkki: lomitusjärjestäminen (edellä) Yleistys: Ratkaistava T (1) c T (n) g(t (1),..., T (n 1), n) missä g on n ensimmäisen parametrin suhteen kasvava. (Ratkaisu

Lisätiedot

PROJEKTIN OHJAUS JA SEURANTA JOUNI HUOTARI 28.9.2009

PROJEKTIN OHJAUS JA SEURANTA JOUNI HUOTARI 28.9.2009 PROJEKTIN OHJAUS JA SEURANTA JOUNI HUOTARI 28.9.2009 POHDINTAA Mitä asioita projektissa seurataan? Kuka vastaa ohjauksesta? Millä tavoin projektia seurataan ja ohjataan? Mitä asioita ohjaukseen kuuluu?

Lisätiedot

Ohjelmistotuotanto, projektinhallinta Kevät 2005

Ohjelmistotuotanto, projektinhallinta Kevät 2005 3. Projektinhallinta Ohjelmistoprojektien koon kasvaessa on törmätty projektinhallinnan ongelmiin, kuten jatkuva, osin huonosti hallittu kasvu, myöhästymiset, huono laatu, budjettien ylitykset, projektien

Lisätiedot

Miten johdan huolto- ja korjaamotoimintaa laadukkaasti? Autokauppa 2015 6.11.2014 Finlandiatalo

Miten johdan huolto- ja korjaamotoimintaa laadukkaasti? Autokauppa 2015 6.11.2014 Finlandiatalo Miten johdan huolto- ja korjaamotoimintaa laadukkaasti? Autokauppa 2015 6.11.2014 Finlandiatalo Keijo Mäenpää Liikkeenjohdon konsultti Diplomi-insinööri Tavoitteena Sujuvasti toimiva kyvykäs organisaatio

Lisätiedot

E-laskun asiakasarvo pk-sektorilla

E-laskun asiakasarvo pk-sektorilla 1 E-laskun asiakasarvo pk-sektorilla 2 Esityksen sisältö Miksi tutkimus tehtiin? Mitä haluttiin selvittää? Tutkimuksen suoritus Tulokset Koetut hyödyt ja haitat Miksi pk-yritys siirtyi käyttämään e-laskua

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

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

Ohjelmistojen mallinnus (OMa) - Johdatus ohjelmistotuotantoon Harri Laine 1

Ohjelmistojen mallinnus (OMa) - Johdatus ohjelmistotuotantoon Harri Laine 1 Ohjelmistojen mallinnus (OMa) - Johdatus ohjelmistotuotantoon 31.10.2008 Harri Laine 1 Ohjelmisto Tietokoneohjelma (computer program) toimintaohje, jonka mukaan toimien tietokone suorittaa jonkin tietojenkäsittelytehtävän

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

Tilastollinen testaus. Vilkkumaa / Kuusinen 1

Tilastollinen testaus. Vilkkumaa / Kuusinen 1 Tilastollinen testaus Vilkkumaa / Kuusinen 1 Motivointi Viime luennolla: havainnot generoineen jakauman muoto on usein tunnettu, mutta parametrit tulee estimoida Joskus parametreista on perusteltua esittää

Lisätiedot

9. Lineaaristen differentiaaliyhtälöiden ratkaisuavaruuksista

9. Lineaaristen differentiaaliyhtälöiden ratkaisuavaruuksista 29 9 Lineaaristen differentiaaliyhtälöiden ratkaisuavaruuksista Tarkastelemme kertalukua n olevia lineaarisia differentiaaliyhtälöitä y ( x) + a ( x) y ( x) + + a ( x) y( x) + a ( x) y= b( x) ( n) ( n

Lisätiedot

Jatkuvat satunnaismuuttujat

Jatkuvat satunnaismuuttujat Jatkuvat satunnaismuuttujat Satunnaismuuttuja on jatkuva jos se voi ainakin periaatteessa saada kaikkia mahdollisia reaalilukuarvoja ainakin tietyltä väliltä. Täytyy ymmärtää, että tällä ei ole mitään

Lisätiedot

f(n) = Ω(g(n)) jos ja vain jos g(n) = O(f(n))

f(n) = Ω(g(n)) jos ja vain jos g(n) = O(f(n)) Määritelmä: on O(g(n)), jos on olemassa vakioarvot n 0 > 0 ja c > 0 siten, että c g(n) kun n > n 0 O eli iso-o tai ordo ilmaisee asymptoottisen ylärajan resurssivaatimusten kasvun suuruusluokalle Samankaltaisia

Lisätiedot

Ohjelmistoprojekteista. Datanomiopiskelijat 2.vuosi

Ohjelmistoprojekteista. Datanomiopiskelijat 2.vuosi Ohjelmistoprojekteista Datanomiopiskelijat 2.vuosi Yleistä projekteista Projekti on selkeästi asetettuihin tavoitteisiin pyrkivä, ajallisesti rajattu kertaluonteinen hanke, jonka toteuttamisesta vastaa

Lisätiedot

INTERVALLIPÄÄTÖSPUUT JANNE GUSTAFSSON 45433E. Mat Optimointiopin seminaari Referaatti

INTERVALLIPÄÄTÖSPUUT JANNE GUSTAFSSON 45433E. Mat Optimointiopin seminaari Referaatti 12.11.1999 INTERVALLIPÄÄTÖSPUUT JANNE GUSTAFSSON 45433E Mat-2.142 Optimointiopin seminaari Referaatti Syksy 1999 1. JOHDANTO Thomas M. Stratin artikkeli Decision Analysis Using Belief Functions käsittelee

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

Työkalut ohjelmistokehityksen tukena

Työkalut ohjelmistokehityksen tukena 1 Työkalut ohjelmistokehityksen tukena Johdanto 2 Työkaluja eli ohjelmistotyötä tukevia ohjelmistoja käytetään ohjelmistoalan yrityksissä nykypäivänä paljon. Työkalut auttavat ohjelmistoalan ihmisiä suunnittelemaan

Lisätiedot

Koulussamme opetetaan näppäilytaitoa seuraavan oppiaineen yhteydessä:

Koulussamme opetetaan näppäilytaitoa seuraavan oppiaineen yhteydessä: TypingMaster Online asiakaskyselyn tulokset Järjestimme toukokuussa asiakkaillemme asiakaskyselyn. Vastauksia tuli yhteensä 12 kappaletta, ja saimme paljon arvokasta lisätietoa ohjelman käytöstä. Kiitämme

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

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

Monipuolisen yhteistyön haaste pyrittäessä korkealle

Monipuolisen yhteistyön haaste pyrittäessä korkealle 1 Monipuolisen yhteistyön haaste pyrittäessä korkealle Markus Hellström 2 Esityksen kiteytys 3 Esityksen sisältö Tavoite ja sen merkitys liiketoiminnan johtamisessa Miten vien liiketoiminnan tavoitteeseen?

Lisätiedot

Numeeriset menetelmät TIEA381. Luento 12. Kirsi Valjus. Jyväskylän yliopisto. Luento 12 () Numeeriset menetelmät / 33

Numeeriset menetelmät TIEA381. Luento 12. Kirsi Valjus. Jyväskylän yliopisto. Luento 12 () Numeeriset menetelmät / 33 Numeeriset menetelmät TIEA381 Luento 12 Kirsi Valjus Jyväskylän yliopisto Luento 12 () Numeeriset menetelmät 25.4.2013 1 / 33 Luennon 2 sisältö Tavallisten differentiaaliyhtälöiden numeriikasta Rungen

Lisätiedot

Kurssin tavoitteista uennot. 4.1 Projektityö, 5 ov. Esitietovaatimukset

Kurssin tavoitteista uennot. 4.1 Projektityö, 5 ov. Esitietovaatimukset Kurssin tavoitteista uennot ma ls. 1097, klo 10-12. pe ls. DXI, klo 12-14. uennot ovat viikoilla 40-42. uentojen yhteydessä ei järjestetä erillisiä harjoituksia. Opinto-oppaasta: Opintojakson tavoitteena

Lisätiedot

Johdatus matematiikkaan

Johdatus matematiikkaan Johdatus matematiikkaan Luento 7 Mikko Salo 11.9.2017 Sisältö 1. Funktioista 2. Joukkojen mahtavuus Funktioista Lukiomatematiikassa on käsitelty reaalimuuttujan funktioita (polynomi / trigonometriset /

Lisätiedot

Fiksumpi käyttöliittymä kuntaan. Miten kuntien tietojärjestelmät saadaan palvelemaan kuntalaisia? LapIT-päivät 2015

Fiksumpi käyttöliittymä kuntaan. Miten kuntien tietojärjestelmät saadaan palvelemaan kuntalaisia? LapIT-päivät 2015 Fiksumpi käyttöliittymä kuntaan Miten kuntien tietojärjestelmät saadaan palvelemaan kuntalaisia? LapIT-päivät 2015 Otso Kivekäs 20.8.2015 Otso Kivekäs+ Codento Kehittämispäällikkö, kunta-alan projektit

Lisätiedot

Mitä Lean on? Lean5 Europe Oy Ltd

Mitä Lean on? Lean5 Europe Oy Ltd Mitä Lean on? Lean5 Europe Oy Ltd Tommi Elomaa MITÄ ON LEAN? 1. ARVO TEHDÄÄN VAIN SITÄ, MIKÄ TUOTTAA ARVOA ASIAKKAALLE. EI TEHDÄ MITÄÄN MUUTA. Leanin keskeinen ajatus on päinvastainen Tarkoitus ei ole

Lisätiedot

Algoritmit 1. Luento 2 Ke Timo Männikkö

Algoritmit 1. Luento 2 Ke Timo Männikkö Algoritmit 1 Luento 2 Ke 11.1.2017 Timo Männikkö Luento 2 Algoritmin esitys Algoritmien analysointi Suoritusaika Asymptoottinen kertaluokka Peruskertaluokkia NP-täydelliset ongelmat Algoritmit 1 Kevät

Lisätiedot

FoA5 Tilastollisen analyysin perusteet puheentutkimuksessa. Luentokuulustelujen esimerkkivastauksia. Pertti Palo. 30.

FoA5 Tilastollisen analyysin perusteet puheentutkimuksessa. Luentokuulustelujen esimerkkivastauksia. Pertti Palo. 30. FoA5 Tilastollisen analyysin perusteet puheentutkimuksessa Luentokuulustelujen esimerkkivastauksia Pertti Palo 30. marraskuuta 2012 Saatteeksi Näiden vastausten ei ole tarkoitus olla malleja vaan esimerkkejä.

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

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

1. Johdanto. Ohjelmistotuotannon ongelmia

1. Johdanto. Ohjelmistotuotannon ongelmia 1. Johdanto Mitä ohjelmistotuotanto on? ohjelmointi + ohjelmisto + tekniikat + insinööritaito + kurinalainen työskentely Määritelmä (60-luvun ohjelmistokriisi): The establishment and use of sound principles

Lisätiedot

pitkittäisaineistoissa

pitkittäisaineistoissa Puuttuvan tiedon ongelma p. 1/18 Puuttuvan tiedon ongelma pitkittäisaineistoissa Tapio Nummi tan@uta.fi Matematiikan, tilastotieteen ja filosofian laitos Tampereen yliopisto mtl.uta.fi/tilasto/sekamallit/puupitkit.pdf

Lisätiedot

Nimi: Opnro: Harjoitustyön suoritus: ( ) syksy 2006 ( ) syksy 2005 ( ) muu, mikä. 1. Selitä seuraavat termit muutamalla virkkeellä ja/tai kaaviolla:

Nimi: Opnro: Harjoitustyön suoritus: ( ) syksy 2006 ( ) syksy 2005 ( ) muu, mikä. 1. Selitä seuraavat termit muutamalla virkkeellä ja/tai kaaviolla: Harjoitustyön suoritus: ( ) syksy 2006 ( ) syksy 2005 ( ) muu, mikä 1. Selitä seuraavat termit muutamalla virkkeellä ja/tai kaaviolla: a) käytettävyys b) käyttäjäkeskeinen suunnittelu c) luonnollinen kieli

Lisätiedot

Identifiointiprosessi

Identifiointiprosessi Alustavia kokeita Identifiointiprosessi Koesuunnittelu, identifiointikoe Mittaustulosten / datan esikäsittely Ei-parametriset menetelmät: - Transientti-, korrelaatio-, taajuus-, Fourier- ja spektraalianalyysi

Lisätiedot

10 Liiketaloudellisia algoritmeja

10 Liiketaloudellisia algoritmeja 218 Liiketaloudellisia algoritmeja 10 Liiketaloudellisia algoritmeja Tämä luku sisältää liiketaloudellisia laskelmia. Aiheita voi hyödyntää vaikkapa liiketalouden opetuksessa. 10.1 Investointien kannattavuuden

Lisätiedot