Prosessien kehittäminen osa 2 Sami Kollanus TJTA330 Ohjelmistotuotanto 26.4. SEI:n mukan kolme odotettavissa olevaa ongelmaa Tämä ei sovellu meille Resurssit valuvat prosessien kehittämisestä tärkeämpiin asioihin Yleinen muutosvastarinta mihin tahansa muutoksiin SEI. CMMI Executive Overview presentation. 2 1
Prosessien kehittämisen haasteita Ei ole aikaa Tiedon puute Väärä motivaatio Noustaan CMMI tasolle 3 ennen joulua Dogmaattinen lähestymistapa Kuitenkin nähtävä yhteinen hyöty Riittämätön sitoutuminen 3 Wiegers 2005. Software Process Improvement Handbook: A Practical Guide. Prosessien kehittämisen onnistumisen tekijöitä Kerättiin kirjallisuudesta lista aiemmista tutkimustuloksista Onnistumiseen mahdollisesti vaikuttavat tekijät -> hypoteesit Kyselyyn 120 vastausta 55 yrityksestä Vastaajat keskijohtoa Tilastollinen analyysi Dyba, T. 2005. An empirical investigation of the key factors for success in software process improvement. Transaction on Software Engineering 31(5), 410-424. 4 2
Tutkimuksen konsepti Dyba, T. 2005. An empirical investigation of the key factors for success in software process improvement. Transaction on Software Engineering 31(5), 410-424. 5 Tutkimuksen hypoteesit H1: SPI success is positively associated with business orientation H2: SPI success is positively associated with involved leadership. H3: SPI success is positively associated with employee participation. H4: SPI success is positively associated with concern for measurement. Dyba, T. 2005. An empirical investigation of the key factors for success in software process improvement. Transaction on Software Engineering 31(5), 410-424. 6 3
Tutkimuksen hypoteesit H5: SPI success is positively associated with exploitation of existing knowledge. H6: SPI success is positively associated with exploration of new knowledge. H7: The six independent variables of business orientation, involved leadership, employee participation, concern for measurement, exploitation of existing knowledge, and exploration of new knowledge will explain a large amount of the variance in SPI success. Dyba, T. 2005. An empirical investigation of the key factors for success in software process improvement. Transaction on Software Engineering 31(5), 410-424. 7 Tutkimuksen tuloksia Tilastollisten analyysien perusteella kyselytutkimusten tulokset tukivat kaikkia esitettyjä hypoteeseja Dyba, T. 2005. An empirical investigation of the key factors for success in software process improvement. Transaction on Software Engineering 31(5), 410-424. 8 4
Demingin laatuympyrä Deming 1986, Out of the Crisis. 9 CMMI ja kehittämisen toteuttaminen Ei varsinaista tukea muutoksen johtamiseen, mutta seuraavat mainitaan: Organisaatiopolitiikan/johdon sitoutumisen merkitys Suunnitellaan prosessi Järjestä resurssit Määritä vastuut Kouluta ihmiset Tunnista ja sitouta asiaan kuuluvat henkilöt (relevant stakeholders) Valvo prosessia SEI 2002. CMMI v. 1.1. 10 5
SEI:n askeleet CMMI:n käyttämiseen 1. Varmista johdon tuki ja rahoitus 2. Järjestä perustiedon koulutus 3. Valitse malli, jota haluat käyttää 4. Valmista organisaatio muutokseen kustannuslaskelmat, mahdollisuudet, ongelmat Avainhenkilöiden koulutus 5. Muodosta prosessinkehittämisestä vastaava työryhmä www.sei.cmu.edu/cmmi 11... SEI:n askeleet CMMI:n käyttämiseen 6. Tiedä, missä olet (epämuodollinen arviointi) 7. Tiedä, minne olet menossa (tavoitteet) 8. Rehellinen kommunikointi ja koordinointi (kommunikoidaan avoimesti kaikille ja kuunnellaan kommentteja) 9. Seuraa edistymistä www.sei.cmu.edu/cmmi 12 6
IDEAL-malli Learning Propose Future Actions Analyze and Validate Implement Solution Refine Solution Stimulus for Change Set Context Build Sponsorship Charter Infrastructure Acting Initiating Diagnosing Characterize Current & Desired States Develop Recommendations Pilot/Test Solution Create Solution Set Priorities Develop Approach Plan Actions www.sei.cmu.edu/ideal Establishing 13 NAH (not applicable here) - syndrome Ongelmia tarkastusten käyttöönotossa, monet näkevät vain resurssien kulutukseksi Testataan menetelmää koodia katselmoimalla ja verrataan testaukseen Esitetään tulokset johdolle -> positiivisia kokemuksia Jalote, P. & Haragopal, M. 1998. Overcoming the NAH syndrome for inspection deployment. Proceedings of the 20th International Conference on Software Engineering, 371-378. 14 7
SEAS case Computer Science Corporation (CSC) Yli 65 000 työntekijää Engineering and Analysis Support Center (SEAS) 850 työntekijää Toimii NASA:n Goddard Space Flight Centerin kanssa Suuri ja vanha organisaatio + laatuvaatimukset 15 SEAS case Prosessien kehittämistä ja metriikoita 1980- luvulta asti Vuonna 1992 oli jo olemassa melko laaja jouko määriteltyjä prosesseja Vuonna 1994 asetettiin uudet tavoitteet prosessien kehittämiselle -> kehittämishanke aloitettiin vuonna 1995 Vuonna 1998 yritys oli CMM tasolla 5 16 8
SEAS case tavoitteet prosessien kehittämiselle Tuottavuus Laatu Ennustettavuus Projektin läpimenoaika Benchmarking -> arvioinnin tuoma status 17 SEAS case kehittämisen periaatteet Koordinointi Paimenet, Process deployment team meeting Etusijalle tuotteeseen liittyvät tavoitteet Laatu, tuottavuus yms. Käytetään vertailumalleja (esim. CMM) prosessien kehittämisen tukena separations of concerns strategiaa Tunnistetaan nykytaso ja asetetaan tavoitteet 18 9
SEAS case hyötyjä ja kustannuksia Kustannukset 2.2 % kokonaiskustannuksista Suorituskyvyn parantuminen: Organisaatio toimi kokonaisuutena yhteisten tavoitteiden mukaan Korkea kurinalaisuus kaikissa projekteissa Merkittävä parannus aiempiin prosesseihin ja standardeihin Nopeutunut uuden teknologian käyttöönotto Ylpeyden tuntu omasta organisaatiosta 19 SEAS case hyötyjä ja kustannuksia Lisää tilauksia: USA:n valtio teki 500 M$ lisää tilauksia Tärkeimmiksi koettiin tuotevaikutukset: Tuottavuus, laatu yms. 20 10
SEAS case yhteenvetoa kokemuksista Toimi 5. tason organisaationa: älä keskity tiettyjen toimintojen ajoittaiseen kehittämiseen, vaan luo kulttuuri jatkuvalle kehittämiselle. Aseta spesifejä inkrementaalisia tavoitteita Separations of concern periaate Jalkauta prosessit projekteihin Paimenet ja viikottaiset PDT-palaverit toimivat hyvin 21 SEAS case yhteenvetoa kokemuksista Mittaa tuotetta, älä prosessia (CMM-tasoa) Varaa tarvittavat resurssit Kolme tärkeää dokumenttia mahdollisimman varhain: Laatukäsikirja Prosessien kehittämissuunnitelma Organisaation profiili 22 11
Pienen yrityksen kokemuksia DataStream Content Solution Neljä vuotta: 4 -> 28 työntekijää Suurten tiedostojen konvertointia muodosta toiseen Firmassa kaksi avainhenkilöä: toimitusjohtaja ja pääohjelmoija Lähtökohtana CMM luokitus + tekninen delegointi Dangle, K., Larsen, P., Shaw, M. & Zelkowitz, M. 2005. Software process 23 improvement in small organizations: a case study. IEEE Software 22(6), 68-75. Pienen yrityksen kokemuksia Aloitettiin projekti yliopiston kanssa yhteistyössä Kehitettiin systeemiarkkitehtuuria (palvelinjärjestelmä + versionhallinta) Merkittävimpiä kohteita olivat konfiguraationhallinta ja katselmoinnit Resurssien allokointi: aluksi yhteyshenkilönä pääohjelmoija Dangle, K., Larsen, P., Shaw, M. & Zelkowitz, M. 2005. Software process 24 improvement in small organizations: a case study. IEEE Software 22(6), 68-75. 12
Luotiin seuraavat periaatteet Prosessi ei ole vain prosessia varten, sen pitää liittyä liiketoiminnan tavoitteisiin Järjestä käytänteiden määrittely hyötyjen mukaan, älä ohjaudu vain mallin prosessialueiden mukaan esim. katselmoinnit, vaikka ne kuuluvat 3 tason käytänteisiin Et voi ylläpitää prosessien kehitystä ilman asianmukaisia resursseja Testaa ensin uudet käytänteet valituissa projekteissa Suunnittele uuden prosessin käyttöönotto meneillään olevat aktiviteetit huomioon ottaen Dangle, K., Larsen, P., Shaw, M. & Zelkowitz, M. 2005. Software process 25 improvement in small organizations: a case study. IEEE Software 22(6), 68-75. Kehittämiselle tavoitteet Organisaation kyky ennustaa projektin aikataulu ja kustannukset Pienentää tuotantoaikaa (time-to-market) Laatutavoitteet, kilpailukykyinen laatu CMM taso 3 Dangle, K., Larsen, P., Shaw, M. & Zelkowitz, M. 2005. Software process 26 improvement in small organizations: a case study. IEEE Software 22(6), 68-75. 13
Lopputuloksia 18 kuukauden jälkeen Enemmän kuin yksi henkilö voi kehittää ohjelmistoa Kaikki työntekijät ymmärtävät selkeästi työnkuvansa Yritys tuottaa ohjelmistoja tehokkaammin ja nopeammin Yritys ymmärsi alkuperäisten tavoitteidensa epärealistisuuden (CMM taso 3 vuodessa) Taso ei ole ensisijainen tavoite Dangle, K., Larsen, P., Shaw, M. & Zelkowitz, M. 2005. Software process 27 improvement in small organizations: a case study. IEEE Software 22(6), 68-75. Yhteenvetoa prosessien kehittämisestä Ei saa jättää kehitystä huomiotta, muuten mennään takapakkia. Ei voi kuitenkaan kiirehtiä liikaa! Johdon sitoutuminen Koulutus + avoin viestintä Avainhenkilöt Lähtökohdaksi tuote + liiketoiminta Tavoitteet + seuranta 28 14