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 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 3 6.1. 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 1968. Lain mukaan työntekijöiden kyvykkyydessä on erittäin merkittäviä eroja. 5 6 1

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,6 2 1 50 Huonoin tulos 50 26 541 3287 8,0 Vaihteluväli 25 26 11 5 13 10 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

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 250. 16 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 = 37.400 tyyppiä projekteja. Oikea luku on hiukan pienempi, sillä tekijät eivät ole toisistaan riippumattomia. 18 3

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 1992. 23 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

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. 25 6.4. 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

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. 32 6.5. 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

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ä 3 9 5 8 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,8 37 38 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. 6.6. 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 1975. 41 42 7

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ä. 46 6.7. 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

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 50 6.8. 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. 51 52 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

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. 55 56 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. 59 60 10