Ohjelmistotekniikka Projektinhallinta, osa 2

1. OhjelmistotekniikkaProjektinhallinta, osa 2 Kevät 2002 Päivi Ovaska LTKK/Tite

2. Työmäärien arviointi • Edellytys aikataulun ja budjetin laatimiselle. • Vaikeaa mm. koska • ihmisten työn tuottavuus vaihtelee (edes 10-20 -kertaiset erot eivät ole harvinaisia • työn vaativuus vaikuttaa tuottavuuteen (kerroin 1-20) • yllättävät ongelmat eivät ole harvinaisia. • tuotteen kokoa on vaikea arvata

3. Koon arviointi • Montako koodiriviä • Pascal-kääntäjä • Unix-shell • Assembler-kääntäjä • Reaaliaika-KJ (hissi, GSM-puhelin, televisio) • Yleiskäyttöinen KJ.

4. Menetelmiä työmäärien arviointiin • Kolmen arvion malli • Cocomo (Constructive cost model) • FPA (function point analysis) • Analogia (kokemukseen perustuva arvaus) • Historiatiedon merkitys! • Murheellinen paradoksi: kaupan saa usein se joka arvioi työmäärän eniten väärin.

5. Kolmen arvion malli • Maximum likelihood -estimaati p+4a+o / 6 , missä p= pessimistinen arvio, a=todennäköinen arvio, o=optimistinen arvio esim. jos projektin työmääräksi arvioidaan optimistisesti 10 viikkoa, todennäköisenä pidetään 12 viikkoa ja pessimistinen arvio on 20 viikkoa, saadaan projektin kestoksi 13 viikkoa

6. Cocomo • Barry Boehmin laajoihin tutkimuksiin ohjelmistotyön tuottavuutten vaikuttavista tekijöistä perustuva menetelmät • osoitteesta http://sunset.usc.edu/research/COCOMOII löytyy kaikenlaista materiaalia kyseisestä mallista • KLOC (KLinesOfCode)-> COCOMO->työpanos MM (htkk) ja kalenteriaika T(kk) • Cocomon kertoimet kansainvälisesti kerättyä tilastotietoa kattaen koko projektin vaatimusmäärittelystä testaukseen, kehittyneemmässä versiossa (Intermediate, Detailed) voidaan painottaa erilaisilla vaikeusasteilla

7. Basic Cocomo • Helppo tehtävä MM=2.4*KLOC1.05 Tdev=2.5*MM0.38 • Normaali tehtävä MM=3.0*KLOC1.12 Tdev=2.5*MM0.35 • Vaikea tehtävä MM=3.6*KLOC1.20 Tdev=2.5*MM0.32 Esimerkkiohjelmisto, jossa tuotetaan palvelu matkapuhelinverkkoon, 35 000 riviä koodia : jos luokitellaan normaaliksi, KLOC=35-> MM=160 htkk, T=15 kk jos luokitellaan vaikeaksi, KLOC=35 ->MM=257htkk, T= 15 kk *) Mallissa työmäärä kasvaa ohjelmiston koon funktiona, mutta tuottavuus ei juurikaan laske projektin koon kasvaessa

8. Intermediate Cocomo • Projektin vaativuutta arvioidaan basic mallin karkean vaikeusastejaottelun lisäksi tuotetta, henkilöstöä, kehitysympäristöä ja projektia kuvaavien kustannuskertoimien avulla. Kukin näistä tekijöistä arvioidaan 6-arvoisella asteikolla: hyvin alhainen, alhainen, normaali, korkea, hyvin korkea ja erittäin korkea • Normaali homma nMM=3.0*KLOC1.12 Tdev=2.5*MM0.35 • Vaikea homma nMM=3.6*KLOC1.20 Tdev=2.5*MM0.32 Esimerkkiohjelmisto: Seuraavat tekijät otetaan huomioon: tuotteen monimutkaisuus korkea 1.17, sovellusalueen tuntemus alhainen 1.13, -> tällöin normaalin homman MM=1.13*1.17*160=211 htkk, T=16kk ja vaikean homman MM=1.13*1.17*257=339 htkk, T=16 kk

9. Cocomo mallin arviointia • Käytännössä on todettu tuottavan työmääräarviot noin 20% tarkkuudella • Mallia on erityisesti hyvä käyttää projektien jälkiarviointiin vertaamalla mallin ennustamaa tulosta projektin toteumaan • On olemassa vielä Detailed Cocomo, jossa käytetään erilaisia kustannuskertoimia ohjelmiston eri osissa • Mallin toteuttavia ohjelmistoja on kaupallisesti saatavissa, arvioiden perustanan yrityskohtaisesti kalibroidut (historiatieto) tietokannat

10. Kustannuskertoimet

11. Toimintopisteanalyysi (Function Point Analysis, FPA) • Tarkastelee ohjelman tietojenkäsittelyn laajuutta ja teknistä monimutkaisuutta • Tietojenkäsittelyn laajuusi UFP • Tekninen kompleksisuus TCF • Toimintopisteet FP=UFP*TCF • Toimintopisteet muutetaan tilastollisen tiedon mukaan tietyillä kertoimilla työmääriksi • Auttaa myös sovelluksen toiminnallisuuden ja kompleksisuuden läpikäynnissä

12. Slide 13 of 18

13. Työmäärien arviointimenetelmistä • Yksinkertaisimmat menetelmät perustuvat arvaukseen, joko projektin tekijöiden, asiantuntijoiden tai esimerkiksi kilpailijan antamaan tarjoukseen • Kehittyneemmät menetelmät perustuvat historiatietojen hyväksikäyttöön • Kannattaa käyttä useampia menetelmiä paremman lopputuloksen saamiseksi • Arvioista ei tulisi tehdä kovin tiukkoja, sillä arviot ovat helposti liian optimistisia

14. Riskien hallinta • Riskien tunnistaminen • Riskien analysointi • Riskien priorisointi • Riskienhallinnan suunnitelu • Riskien toteutumisen seuranta ja hallinta • riskien ennakointi (ennusmerkit ??) • riskien eliminointi (poistaminen, torjunta ennakolta) • riskien väistäminen (jos riski uhkaa) • seurausten minimointi (jos riski on toteutunut). • Riskien luokittelu • asiakkaaseen liittyvät • tekniikkaan liittyvät • omaan henkilöstöön liittyvät riskit.

15. Top risks, USA • Avainhenkilö vaihtaa työpaikkaa • Epärealistiset aikataulut ja budjetit • Kehitetään ohjelmistoon vääriä toimintoja ja turhia piirteitä • Huono käyttöliittymä • Muutokset määrittelyssä = "liikkuva maali" • Ongelmat muualta hankituissa komponenteissa ja/tai palveluissa • Tekniset ongelmat (suoritusteho, reaaliaikaisuus, muistitila).

16. Top risks, Lappeenranta • MITEN • aikataulu petti • kustannukset ylittyivät • asiakas tyytymätön tuotteeseen (ei vastaa tavoitteita, liiketaloudelliset menetykset) jälkihoidon työmäärä valtava. • MIKSI ? • työmääräarvio virheellinen • määrittely puutteellinen • liian suuri projekti • asiakkaan/toimittajan asiantuntemattomuus • suunnittelematon käyttöönotto • henkilöstön vaihtuvuus • huono projektipäällikkö • ongelmat työvälineissä/laitteissa.

17. Critical (anti) success factors in software projects (J. S. Reel, IEEE Software May/June 1999) • 1. projektinvetäjä ei ymmärrä asiakasvaatimuksia • 2. projektin laajuutta ei ole määritelty kunnolla • 3. muutostenhallinta on puutteellista • 4. teknologiassa tapahtuu muutoksia • 5. asiakasvaatimukset muuttuvat • 6. aikataulu on epärealistinen • 7. käyttäjien vastustus • 8. tuki projektille loppuu • 9. projektiryhmässä ei ole tarvittavaa ammattitaitoa • 10. ei oteta oppia toimivista käytännöistä ja tehdyistä virheistä. Johtopäätös: Projektien ongelmat eivät niinkään ole teknisiä, vaan liittyvät projektinhallintaan, ihmisten johtamiseen, ryhmätyöhön, kommunikointiin, asiakastarpeiden ymmärtämiseen…

18. Hallinta • Projektipäällikkö ja ohjausryhmä. • Riskit projektisuunnitelmaan tai erilliseen riskienhallintasuunnitelmaan. • Jokaisesta riskistä • Miksi riski on tärkeä. • Miten hallitaan (kuka vastaa, havaitseminen, reagointi) ja milloin hallintaan liittyviä asioita tehdään. • Miten toteutumistodennäköisyys minimoidaan. • "Plan B" toteutumisen varalle.

19. Mikä ohjelmistotyössä maksaa? • Työvoimakustannukset (palkat, henkilösivukulut), yleensä 50-70% kaikesta • yleiskustannukset (tilojen vuokra, konttorikustannukset, puhelin, posti,...) • alihankinta • kalusto- ja tilajärjestelyt • koulutus • palkitseminen • projektiryhmän huolto, edustus (syöttäminen, juottaminen, saunotus, seminaarit korpihotellissa) • matkakustannukset • kirjallisuus yms. tiedonhankinta • laitteet • pääomakustannukset • katetavoite…

20. Ihmistyön kustannustekijät • palkka (kk-palkka, ylityöt, palkkiot) • pakolliset henkilösivukulut (lomakorvaukset, sosiaaliturva, eläke- yms. vakuutukset, palkalliset sairauspäivät, arkipyhät, yhteensä 50-60% palkasta) • vapaaehtoiset henkilösivukulut (ruoka, auto, terveydenhoito, virkistys...) • koulutus • rekrytointi (voi olla merkittäväkin, esimerkiksi 6-10 kk palkka).

21. Eräs karkea hinta-arvio • Perustuntihinta: laskutettavan työtunnin hinta yrityksessä, • nyrkkisääntö: Keskimääräinen palkka pitäisi saada laskutettua perustuntihinnalla 2,5-4 kertaisena. • Projektin hinnoittelu saadaan summaamalla • aika-arvio * perustuntihinta (*hhh-vakio)1 • projektiin ulkoa ostettavat laitteet, ohjelmistot, laitteet • mahdolliset muut kulut… 1) hhh-vakio = hiha, hanska ja hattu, voi joskus olla ykköstä pienempikin.

22. Perustuntihinnan määrääminen • Perustuntihinta saadaan jakamalla kustannustekijöiden summa laskutuskelpoisten tuntien kokonaismäärällä. • Laskutuskelpoisten tuntien määrä saadaan vähentämällä kaikesta työajasta (n. 225 päivää/henkilö vuodessa, eli n. 1700 tuntia) • johtajien, sihteerien yms. työaika sekä • laskutettavaa työtä tekevien henkilöiden työpanoksesta esimerkiksi 25% (perustuu kokemukseen).

23. Summittainen esimerkki • 10 hengen ohjelmistotalo • Päätoiminen johtaja, ei sihteeriä • Muut tekevät laskutettavaa työtä 75% työajasta • Vaihtuvuus n. 1 hlö / vuosi • Palkat ja henkilösivukustannukset 1.6 * 15 kmk * 12 kk • Otetaan huomioon vuokrat, laitteiden poistot, leasing-autot, konttorikustannukset jne... kertomalla summa 1.5:llä =>> menopuolella n. 4500 kmk.

24. …summittainen esimerkki • Laskutettavia tunteja voi arvioida tulevan vuoden aikana yhdeksälle työtekijälle. • Vaihtuvuuden ja sairaslomien yms. huomioon ottamiseksi käytetään kertoimena kuitenkin lukua 8: 8*1700*0.75 = noin 10000 laskutettavaa tuntia. • Työtunnin hinnaksi tulee siis noin 450 mk/tunti ja päivähinnaksi 3600 mk. • esimerkiksi 3 KDSI kokoisen ohjelman teettäminen tässä firmassa maksaisi siis suunnilleen: 16*22*8*450 = noin 1300 kmk !!! • Konsulttityön tuntiveloitus on tyypillisesti välillä 300 - 800 mk.

25. Projektinhallintatyökalut • Perustietojen hallinta. • kalenteri, jossa vapaapäivät (sekä henkilöille) että muille resursseille) • resurssit ja kustannukset (henkilöt, laitteet ...) • aikataulun laatiminen. • Edut ja haitat. • Moniprojektihallinta?

26. …projektinhallintatyökalut • Syötetään tehtävät ja niiden työmäärät. • Määritetään tehtävien riippuvuudet. • Kerrotaan kuka/ketkä tehtävät suorittavat. • Aikataulua muokataan kunnes resursseja kuormitetaan tasaisesti ja kokonaiskustannukset ovat mahdollisimman pienet. • Tuloksena saadaan aikataulut ja kustannusarviot. • Valmis aikataulu (baseline) voidaan jäädyttää. • Järjestelmaan voidaan tallettaa toteutumatietoja, joita voidaan verrata suunniteltuun (projektin seuranta ja raportointi).

27. Hyödyt ja haitat • paperinpyöritys vähenee • mahdollistaa kokeilut (hylkää tehdyt muutokset) • helpompi ylläpitää • virheiden mahdollisuus vähenee • mahdollistaa kokemustietojen keruun

28. Kokouskäytäntöjen ryhdistäminen, tulos Pahimmat syyt tehottomiin kokouksiin (% vastaajista mainitsi); 1. kokoukseen ei oltu valmistauduttu kunnolla (85 %) 2. keskustelu harhautui asiasta (77 %) 3. kokouksen olisi voinut viedä läpi lyhyemmässä ajassa (68 %) 4. joku poistui ennen kokouksen päättymistä (60 %) 5. joku poistui välillä hoitamaan asioitaan (57 %) 6. joku ulkopuolinen häiritsi kokousta (40 %) 7. kokouksen tarkoitus ja tavoitteet eivät olleet selvillä (40 %) 8. kokous alkoi myöhässä (31 %) 9. kaikkia asioita ei ehditty käsittelemään (31 %) 10. kokouksen tekemiä päätöksiä ei ole pantu toimeen (31 %).

29. Kokouskäytäntöjen ryhdistäminen • Onko kokous välttämätön, voidaanko asia hoitaa muuten • Optimoi osallistujien määrä • Mieti palaverin tavoite, tarkoitus ja käsiteltävät asiat etukäteen • Valitse sopiva aika ja paikka • Varmista että kokoukseen on valmistauduttu • Tiedota ajoissa, aloita ajoissa, lopeta ajoissa • Tärkeä asiat esityslistan alkuun • Varmista, että joku tekee muistion • Varmista, että päätöksentekovalta on kunnossa • Valitse asioiden käsittelytapa tavoitteen mukaan (ideointipalaveri vs. päätöksenteko)

30. … kokouskäytäntöjen ryhdistäminen • Tee yhteenvetoja: aluksi, lopuksi, tarvittaessa välilläkin • Pysy asiassa, keskeytä pitkät kaksinpuhelut • Huolehdi tavoitteen saavuttamisesta • Varmista osallistujien sitoutuminen päätöksiin, esitä tarvittaessa provosoivia kysymyksiä. • Varmista päätösten toteutumisen seuranta • Kertaa lopuksi johtopäätökset ja toimeksiannot sekä kirjaa ne ylös • Pidä kokous tilassa, jossa ei ole tuoleja ("stand-up meeting") • Jokainen kännykkään saapunut puhelu aiheuttaa 1 euron maksun kahvikassaan • Pullia yksi vähemman kuin osallistujia?

31. Ideointipalaverit • Generointi • yritetään generoida mahdollisimman paljon ideoita • rikotaan rajoja ja totunnaisia menettelytapoja • ei kritiikkiä -- älä ammu "mahdottomiakaan" ideoita alas • usein on hyvä, jos ideat eivät "personoidu": kirjallinen aivoriihi, ideakävely, "innotiimi". • Arviointi • ideoiden ryhmittely ja näkyville asettaminen • hyvät & huonot puolet • vastaesimerkki ei välttämättä tee ideaa käyttökelvottomaksi • pisteyttäminen toisinaan tehokas keino vaihtoehtojen valitsemiseksi • jatkojalostus.

32. Ihmisten (ja itsensä) johtaminen • Yksilön ja ryhmän tavoitteiden tulee olla samansuuntaisia • Ihmiset tarvitsevat onnistumisen kokemuksia • Johtaminen on helppoa niin kauan kun asiat menevät hyvin • Asiat, joita seurataan, tehdään hyvin • Asiat, joista palkitaan, tehdään hyvin • Pelisääntöjen pitää olla vakiintuneita ja kaikkien tiedossa • Avoimuus uusille asioille -- etsi positiiviset puolet ensin • Kuuntele muita, ole aidosti kiinnostunut • Ihmiset eivät kerro mielellään huonoja uutisia • Sitoutuminen yhteisiin päätöksiin (vaikka olisikin eri mieltä) • Erilaisuuden salliminen • Turhan muodollisuuden ja byrokratian karttaminen • Leadership vs. Management: molempien oltava kunnossa • Ihmiset tärkeämpiä kuin tekniikka • Muista positiivinen palaute (se ei maksa mitään) • Pohdi (epä)onnistumisen syitä.

33. Itsensä johtaminen • Seuraa ajankäyttöä ainakin ajoittain tarkasti, tulevaisuuden suunnittelu helpottuu • Varaa kalenteriin aikaa pikku hommille ja yllättäville tehtäville • Realismi: kaikkia tehtäviä ei ehdi tekemään • Priorisoi tehtävät; valitse tehtävät prioriteettijärjesteyksessä, älä mielihyväohjautuvasti -- yritä tehdä keljut hommat ensin • Minimoi keskeytykset, lyhyimpääkin hukkautuu 15 min • Estä keskeytykset, sulje ovi, pane lappu luukulle • Tee mahdollisimman pitkään samaa asiaa, älä hypi tehtävästä toiseen • Aloita aikaisemmin • Delegoi • Pysähdy välillä miettimään, mitä voit oppia lähihistoriasta • Miten hallita stressiä?

34. Kansanviisauksia 1 • On tyhmää toistaa samoja virheitä (tai toisten virheitä) • Valitse projektiin mahdollisimman harvoja ja mahdollisimman hyviä tekijöitä jotka kykenevät kiinteään yhteistoimintaan • Projektin tarkempi suunnittelu on tehtävä uudestaan vähintään kahden kuukauden välein, koska vain tällä aikamarginaalilla tehtävät voidaan tuntea etukäteen tarkasti • Asiat joita seurataan (palkitaan) tulevat tehdyiksi • Projektin osallistujat osallistuvat myös työmääräarvioiden tekemiseen • Älä esitä (edes) alustavaa aikatauluarviota liian aikaisin, tai tuo ainakin selkeästi esille mihin arvio perustuu, arvion epävarmuustekijät ja se, että arvioon ei voi mitenkään sitoutua.

35. Kansanviisauksia 2 • Käytä työmääräarvioijina aina useampia kuin yhtä henkilöä • Älä hyväksy muutoksia ja lisäyksiä määrittelyyn projektin aikana ilman, että niiden vaikutus aikatauluun ja kustannuksiin arvioidaan ja tehdään selväksi kaikille osapuolille • Projektiin osallistuvat seuraavat itse omaa ajankäyttöään • Seuraa toteutumatietoja, päivitä projektisuunnitelmaa • Tee jälkiarviointi: mitä opit projektista (loppuraportti) • Palkitse hyvät suoritukset (aika-arvioiden alitukset). Mieti mitä palkitset (toivottu suoritus). • "Tee tärkeät asiat ennen kiireellisiä." • "Kahvipöytä on firman tärkein projektinhallinnan apuväline."

36. Kansanviisauksia 3 • Aina ei kannata paljastaa todellisia aikataulutavoitteita Julkistetut tavoitteet voi asettaa esimerkiksi siten, että niistä 50% myöhästynyt projekti ei todellisuudessa ole täysin epäonnistunut • Projekti täyttää aina sille varatun ajan, varataanpa aikaa sitten kuinka paljon hyvänsä • Jos projektinhallinta on liian byrokraattinen, töitä aletaan tehdä salaa projektihallinnan ulottumattomissa • Raportointi on määriteltävä projektisuunnitelmassa riittävän formaaliksi, muuten se unohtuu projektikiireiden keskellä • 80% maailman ongelmista johtuu pohjimmiltaan puutteellisesta kommunikoinnista. Lisää projektisuunnitelmaan suunnitelma tiedottamisesta sekä projektin sisällä että projektin ja ulkomaailman välillä: kuka kertoo, mitä, kenelle ja kuinka usein. • Tiedottaminen on yksisuuntaista, viestintä kaksisuuntaista.

37. Syitä erään suuren projektin epäonnistumiseen 1/2 • Järjestelmän ominaisuuksia ja kokoa ei pystytty mitenkään arvioimaan suunnitteluvaiheessa • Järjestelmästä tuli huomattavasti suurempi kuin oli alunperin suunniteltu • Järjestelmään tehtiin projektin aikana jatkuvasti muutoksia: uusia piirteitä lisättiin ja vanhoja muutettiin • Koordinointi osaprojektien välillä oli lähes olematonta • Projektin loppupuolella vallitsi tavaton kiire.

38. Syitä erään suuren projektin epäonnistumiseen 2/2 • Projektin loppupuolella projektipäällikkö sairastui ja hänen tilalleen tuli verraten kokematon henkilö • Järjestelmässä oli useita piirteitä, joita ei oltu kokeiltu aikaisemmissa vastaavissa tuotteissa • Järjestelmätestauksessa todettiin, että järjestelmä on liian epästabiili käyttöönotettavaksi. Projekti oli kuitenkin jo myöhässä ja paine asiakkaan taholta oli kova, joten järjestelmä otettiin tästä huolimatta käyttöön • Jälkikäteen pystyttiin arvioimaan, että järjestelmän rakenne oli sellainen, ettei se olisi mitenkään voinut toimia: ... paarlastia olisi tarvittu niin paljon, että alemmat tykkiportit olisivat joutuneet veden alle. Lähde; Curt Borgenstam: Why the Wasa Capsized.

40. Tekevälle sattuu... • Verohallitus aloitti syyskuussa 1988 ATK-projektin verotusohjelmistojen uudistamiseksi. Vanhat FAS-kielellä kirjoitetut ohjelmistot päätettiin korvata kokonaan uusilla • Projekti oli erittäin laaja. Parhaimmillaan projektin kimpussa hääräsi yli 100 henkeä • Kesäkuussa 1989 määrittelyvaihe oli valmis (muutamalla kuukaudella myöhästyneenä) • Marraskuussa 1989 toteutusvaihe alkoi, mutta määrittelyt osoittautuivat epätäsmällisiksi. • Tammikuussa 1990 tekijät havaitsivat aikataulun epärealistiseksi, mutta eivät raportoineet tästä riittävän äänekkäästi: edes johtoryhmä ei saanut tietoa tästä • Huhtikuussa 1990 projektin piti päättyä, mutta loppua ei ollut näkyvissä.

41. …tapaus verohallitus • Kesäkuussa 1990 projektista tuli suosittu uutisaihe • Joulukuussa 1990 viimeiset osat laskentaohjelmistosta valmistuivat • Huhtikuu 1991: vuoden 1989 verotus valmistuu? • Myös vuoden 1990 • verotus viivästyi • SYYT: • epärealistinen aikataulu • paloittelu ja vaiheistus unohtui • riskejä ei analysoitu • poikkeamista ei raportoitu tai niitä ei havaittu • "uudet" työkalut: Cobol ja Oracle • Oracle-konsultit eivät tunteneet sovellusalueen kieltä.