Ohjelmistotekniikka - Luento 14 Jouni Lappalainen Luku 28: Riskien hallinta - reaktiivinen ja proaktiivinen riskien hallinta - riskien tunnistus, arviointi ja tarkentaminen - riskien vähentäminen, valvonta ja hallinta (MMM), RMMM suunnitelma Luku 29: Ylläpito ja uudelleensuunnittelu - ylläpito - liiketoimintaprosessin ja ohjelmiston uudelleensuunnittelu - takaisinmallintaminen/käänteistekniikka Luku 30: Ohjelmistoprosessin parantaminen - menetelmiä ja malleja - kyvykkyysmalli CMMI
Core Body of Knowledge Areas Graduate Software Engineering 2009 (GSwE2009) Curriculum Guidelines for Graduate Degree Programs in Software Engineering Integrated Software & Systems Engineering Curriculum (issec) Project 2
Soveltuvat lait ja pohdiskelun aiheita 1. Projektiriskit voidaan ratkaista tai niitä voidaan lieventää, kun ne tunnistetaan aikaisessa vaiheessa /hyp_no 17, Boehm 1989 2. Pienissä muutoksissa on suurempi virhetiheys kuin suurissa muutoksissa / no 30, Basili&Perricone 1984, Möller 1995
Soveltuvat lait ja pohdiskelun aiheita Mitkä kahdeksan omiin kokemuksiin perustuvaa, COTS perustaisten järjestelmien ylläpitoon liittyvää oppimaa Reifer et al. oheisessa paperissa esittävät? Buschmann esittelee kahdessa paperissaan kolme arkkitehtuurin hoitamiseen (gardening) ja parantamiseen liittyvää periaatetta, refaktoroinnin (refactoring), uudelleensuunnittelun (reengineering) ja uudelleen kirjoittamisen (rewriting). Kerro, mitä niillä tarkoitetaan ja miten ne pitäisi suorittaa, jos haluaa tehdä ne hyvin. ) Jacobson et al. esittelevät Semat periaatteen (Semat ydin & käsitemalli) oheisessa paperissa. Mitä etuja Semat ydin tarjoaa käyttäjälle tekijöiden mukaan? Mitä tarkoitetaan käsitteellä alpha? Miten tiimin tilannetta voidaan arvioida Semat korttien avulla?
28. Projektin riskien hallinta Mikä voi mennä pieleen?!! Millä todennäköisyydellä?!!miten pahasti?!!miten siitä selvitään?! 5
Mitä riskillä tarkoitetaan? Riscare (uskaltaa / to dare) -> risk If there is no choice, there is no risk, even though there may be loss incurred (Charette 1989) jos valinnan mahdollisuutta ei ole, ei ole myöskään mahdollisuutta välttää tulevia tapahtumia Yleinen määritelmä: the possibility of loss or injury tappion tai vahingon mahdollisuus
Negatiivinen / positiivinen riski Negatiivinen riski tavoitteena ymmärtää mahdolliset ongelmat jotka voivat sattua projektissa ja kuinka ne voivat estää projektin onnistumisen negatiivinen riskinhallinta voidaan nähdä eräänlaisena vakuutuksena Riski voi olla positiivinen positiiviset riskit aiheuttavat toteutuessaan hyviä asioita, ne voidaan nähdä mahdollisuutena riskinhallinnan tavoitteena on minimoida mahdollisia negatiivisia riskejä ja maksimoida positiivisia
Johdon osuus onnettomuuksiin In the inquiries into numerous major accidents, including the Chernobyl nuclear explosion, the sinking of the Herald of Free Enterprise, the Challenger space shuttle explosion, and the Piper Alpha oil rig fire, senior management failure was concluded to be a primary cause / Redmill 2002 Johdon toiminnasta aiheutuva häiriö Inhimillinen virhe Laitevika Käytetty työpanos Todellinen tärkeys Challenger onnettomuudessa NASA:n insinööreillä oli onnettomuuden todennäköisyydestä arvio 1:200 (parhaimmillaan 1:1000), mutta johdolla arvio 1:100.000
Reaktiivinen riskien hallinta projekti reagoi riskeihin niiden lauetessa vähentäminen resursseja myös tulen sammutuksen ennakointiin häiriön poisto resursseja on käytettävissä, kun riski laukeaa kriisin hallinta häiriötä ei saada kuriin ja projekti on vaarassa
Proaktiivinen riskien hallinta tehdään riskianalyysi korjataan riskien aiheuttajat Total Quality Management (TQM) ja tilastollinen laadunvarmistus tutkitaan ohjelmiston ulkopuoliset riskien aiheuttajat kehitetään muutosten hallinnan taitoja
Seitsemän periaatetta /SEI Kokonaisvaltainen tarkastelu view software risks within the context of system and the business problem Ennakoiva tarkastelu think about the risks that may arise in the future; establish contingency plans Avoin kommunikointi if someone states a potential risk, don t discount it. Integrointi a consideration of risk must be integrated into the software process Jatkuva prosessi the team must be vigilant (tarkkaavainen) throughout the software process, modifying identified risks as more information is known and adding new ones as better insight is achieved. Yhteinen näkemys tuoteesta if all stakeholders share the same vision of the software, it likely that better risk identification and assessment will occur. Tiimityön rohkaisu the talents, skills and knowledge of all stakeholder should be pooled 11
Risk Assessment Methodology/NIST - hakkerit - teollisuusvakoilu - palomuuri - käyttäjätunnukset - SQL injektio Järjestelmän tarkoituksen määrittely Uhkien tunnistus Haavoittuvuuksien tunnistus Valvonnan analyysi Todennäköisyyden määrittely Vaikutusanalyysi RE = P * C Riskien määrittely Suositeltu valvonta Tulosten dokumentointi Stoneburner, Goguen, Feringa, Risk Management Guide for Information Technology Systems, 2002
Riskiin varautuminen Riskiin (riskin laukeamiseen) varautuminen! RE (risk exposure) määritellään kaavalla [Hall 1998]:!!!RE = P x C! missä!! P todennäköisyys riskin laukeamisesta! C kustannus projektille riskin lauetessa.!! 13
Riskiin varautumisen aste (risk exposure) Kustannus Todennäköisyys Pieni Keskisuuri Korkea Pieni Pieni Pieni Keskisuuri Keskisuuri Pieni Keskisuuri Suuri Suuri Keskisuuri Suuri Suuri
Yleisimpiä riskejä ja niiden hallintakeinoja Avainhenkilö vaihtaa työpaikkaa Epärealistiset aikataulut ja budjetit Kehitetään vääriä toimintoja ja turhia piirteitä Huono käyttöliittymä Muutokset määrittelyissä Ongelmat muualta hankituissa komponenteissa ja/tai palveluissa Tekniset ongelmat (suoritusteho, reaaliaikaisuus, muistitila, epäkypsä teknologia) Tehtävien kierto, varahenkilöt, sopimustekniset keinot Huolellinen projektisuunnittelu, inkrementit, ketterät menetelmät Prototyyppien käyttö, ketterät menetelmät, markkinatutkimukset Prototyyppien käyttö, ulkopuoliset asiantuntijat, käyttäjän työskentelyn analysointi Prototyyppien käyttö, ketterät menetelmät, muutosten byrokratisointi ja rahastus, huolellinen määrittely Referenssiasiakkaiden hyödyntäminen, suorituskyvyn ja toiminnallisuuden testaus, yhteensopivuuden varmistaminen, toimittajan laatujärjestelmän arviointi Simulointi, mallintaminen, prototyypit, referenssiasiakkaiden hyödyntäminen perustuu lähteisiin Boehm 1989 ja Haikala & Märijärvi 2000
Syklomaattinen kompleksisuus 80 40 20 0 6 4 5 2 3 0 1 0 50 100 150 200 Suoritettavia lauseita C++ koodi esimerkki (315 moduulia) 0 ei riskiä 1 pieni riski 2 pienikeskink. riski 3 keskinkertainen riski 4 keskink. - korkea riski 5 korkea riski 6 hyvin korkea riski moduulien määrä 238 51 0 15 2 9 0 % osuus 75.5 16.2 0 4.8 0.6 2.9 0 Ohjelmamoduulien riskialttius Software Assurance Technology Center (SATC) tutkimus / Buttigieg A.D. http://www.cis.um.edu.mt/~abut/#section%203
11 tärkeintä ohjelmistoprojektin riskitekijää Keil M., Cule P., Lyytinen K., Schmidt R., Communications of the ACM, no 11,1998
Riskien tunnistus / Keil et al. 1998 1. Ovatko tärkeimmät päälliköt (sekä ohjelmiston kehittämisen että asiakkaan puolella) sitoutuneet projektin tukemiseen? 2. Ovatko loppukäyttäjät innostuneesti sitoutuneet projektiin ja rakennettavaan järjestelmään/ tuotteeseen? 3. Ymmärtävätkö ohjelmistotuotantotiimi ja asiakkaat täysin vaatimukset? 4. Ovatko asiakkaat täysin mukana vaatimusten määrittelyssä? 5. Ovatko loppukäyttäjien odotukset realistisia? 18
Riskien tunnistus / Keil et al. 1998 6. Onko projektin tarkoitus vakaa? 7. Onko ohjelmistotuotantotiimissä oikea sekoitus osaamista? 8. Ovatko projektin vaatimukset vakaita? 9. Onko projektiryhmässä kokemusta käytettävästä teknologiasta? 10. Onko projektiryhmän koko riittävä tehtävään nähden? 11. Ovatko asiakkaan ja käyttäjän edustajat yhtä mieltä projektin tärkeydestä ja rakennettavan järjestelmän/tuotteen vaatimuksista? 19
Riskien luokittelu / U.S. Air Force suorituskykyriski tuote ei ehkä täytä vaatimuksia ja eikä sovi tarkoitukseen. kustannusriski projektin budjettia täytyy mahdollisesti päivittää. tukiriski ohjelmistoa voi olla hankala korjata, sovittaa käyttöön ja laajentaa. aikatauluriski projektin aikataulu ei ehkä pidä eikä tuotetta toimiteta ajoissa. 20
Riskien välttäminen, valvonta ja hallinta (Risk Mitigation, Monitoring and Management) mitigation kuinka riskejä voidaan välttää? monitoring mitä tekijöitä seuraamalla voidaan ennustaa riskien laukeamista? management millaisia varasuunnitelmia on, jos riskit toteutuvat?
Riskien luettelointi Riskit Luokittelu Todennäköisyys Vaikutus RMMM Kokoarvio liian pieni Käyttäjiä arvioitua enemmän Uudellenkäyttöä arvioitua vähemmän Julkistusaikaa aikaistetaan Rahoitusongelmia Käyttäjä muuttaa vaatimuksia Teknologia ei vastaa odotuksia PS PS PS BU FU PS TE 60 % 30 % 70 % 50 % 40 % 80 % 30 % 3 2 3 3 4 3 4 Vaikutus 4 = katastrofaalinen 3 = kriittinen 2 = pieni 1 = vähäinen Luokittelu PS = Project size risk BU = Business risk FU = Funding risk TE = Technical risk
Riskin raportointilomake Tunnus: < numero tai tunniste > Kuvaus: < milloin riskitilanne syntyy - mitä siitä aiheutuu > (esim. kaikki asiakkaat eivät ole tyytyväisiä tuotteelle asetettuihin vaatimuksiin, voimme toteuttaa vain tärkeimmän asiakkaan vaatimukset) Todennäköisyys: Kustannus: Riskiin varautuminen: < todennäköisyys * kustannus > Ensimmäinen indikaattori: < mikä voi ilmaista riskin muuttumista ongelmaksi > Kuinka välttää: < millä toimilla riskin vaikutusta voi vähentää tai välttää > Vastuuhenkilö: < kuka on vastuussa Milloin: < milloin viimeistään riskin vähentämistoimista> vähentämistoimet täytyy tehdä >
Esimerkki riskin laukeamiseen varautumisesta Riskin tunnistaminen: Vain 70 prosenttia komponenteista, joita on suunniteltu käytettäväksi sovelluksen rakentamisessa, voidaan todellisuudessa käyttää. Loput toiminnallisuudesta joudutaan rakentamaan sovellusta varten. Riskin todennäköisyys: 80 % Riskin vaikutus: Sovelluksen rakentamisessa suunnitellaan käytettäväksi 60 ohjelmistokomponenttia. Jos vain 70 % voidaan käyttää, 18 komponenettia joudutaan rakentamaan sovellusta varten. Kun komponentin keskimääräinen koko on 100 LOC ja jos (kokemuksen mukaan) ohjelmiston rakentaminen maksaa 15 euroa / LOC, niin kokonaiskustannukset komponenttien rakentamiselle on 18 * 100* 15 = 27.000 euroa Riskin laukeamiseen varautuminen (Risk exposure) RE = 0.80 x 27.000 ~ 21.600 euroa. 24
29. Ylläpito ja uudelleensuunnittelu ylläpito ja Lehmanin lait liiketoimintaprosessin ja ohjelmiston uudelleensuunnittelu takaisinmallintaminen/käänteistekniikka 25
Ohjelmiston ylläpito Muutokset ohjelmistoon ovat väistämättömiä katso Lehmanin lait E-tyypin järjestelmille Ylläpidon luokittelu on elänyt ajan kuluessa Swanson 1976 esitteli kolme: korjaavan, mukauttavan ja täydellistävän Pfleeger 1998 esitteli neljä: korjaavan, mukauttavan, ennalta ehkäisevän ja täydellistävän Sommerville 2004 ei suosittele luokittelun käyttöä, koska on sitä on vaikea käyttää kiistattomasti oikein Korjaus Laajennus Proaktiivinen Reaktiivinen Ennalta ehkäisevä (preventive) Korjaava (corrective) Täydellistävä (perfective) Mukauttava (adaptive) eteenpäin suunnittelu (forward engineering) on lähinnä ennalta ehkäisevää (preventive) ja täydellistävää (perfective)
Lehmanin lait 1. Jatkuvan muutoksen laki E-tyypin järjestelmiä täytyy jatkuvasti sovittaa käyttöön, muuten ne tulevat käyttökelvottomiksi 2. Kasvavan mutkikkuuden laki Kun E-tyypin järjestelmä elää, sen mutkikkuus kasvaa - jossakin vaiheessa sitä täytyy parantaa tai se täytyy hylätä 3. Itsesäätelyn laki Globaalin E-tyypin järjestelmän evoluutioprosessi on itseään säätävä 4. Organisationaalisen pysyvyyden laki Keskimääräinen globaalin toiminnan määrä on kehittyvän E- tyypin järjestelmässä muuttumaton koko järjestelmän elinjakson ajan
Lehmanin lait 5. Tuttuuden säilyttämisen laki Uusien piirteiden määrä E-tyypin järjestelmän uusissa julkaisuissa on vakio koko järjestelmän aktiivisen elämän ajan 6. Jatkuvan kasvun laki E-tyypin järjestelmien toiminnallisuuden täytyy jatkuvasti lisääntyä, jotta käyttäjät pysyvät tyytyväisinä 7. Laadun heikentyminen E-tyypin järjestelmien laatu huononee, kunnes järjestelmää korjataan ja sovitetaan ympäristössä tapahtuneisiin muutoksiin 8. Takaisinkytketyn järjestelmän laki E-tyypin järjestelmien evoluutioprosessi on monitasoinen, monisilmukkainen ja moniagenttinen takaisinkytketty järjestelmä ja sitä pitää kohdella sellaisena, jota muutokset tai parannukset onnistuvat
Esimerkki elinkaarikustannusten jakautumisesta (Schach 2005) 40-60 % ylläpitotyöstä kuluu ylläpidettävän järjestelmän ymmärtämiseen ohjelmiston elinjakson pituus vaikuttaa ylläpidon osuuteen aikana 1976-1981 tehdyissä mitauksissa ylläpidon osuus oli 67 % aikana 1992-1998 tehdyissä mitauksissa ylläpidon osuus kasvoi ja oli 75 % ohjelmiston kehitysvaiheiden työmäärissä ei tapahtunut suuria muutoksia ylläpito koostuu (räätälöidylle) virheiden korjauksista (17 %) asiakkaan toiminnan ja ympäristön muuttumisen vaatimista korjauksista (18 %) uusien piirteiden lisäämisestä (65 %)
Ylläpidon työpanos koko ohjelmiston elinaikana 100 % Korjaava ylläpito Mukauttava ylläpito 90 % 80 % 70 % 60 % Täydellistävä ylläpito 50 % 40 % 30 % 20 % 10 % Ajankohta, kun täydellistävä vie 65 %, korjaava 17 % ja mukauttava 18 %? aika Wiederholdin (2006) esitystä mukaellen
Uudelleensuunnittelu Liiketoiminta prosessit# Tieto- järjestelmät# Uudelleensuunnittelu# Ohjelmisto- sovellukset# 31
Liiketoimintaprosessin uudelleensuunnittelu Tehdään tarkennukset (protoiluun perustuen) ja otetaan uusi prosessi käyttöön Liiketoiminnan määrittely Tavoitteet - kustannusten pienentäminen - ajan lyhentäminen - laadun parannus - henkilöstön kehittäminen Testataan uutta prosessia protoilemalla Tarkennus ja käyttöönotto Tunnistetaan kriittiset prosessit tavoitteiden saavuttamiseksi Protoilu Tuotetaan käyttötapaukset uudelleensuunniteltaville prosesseille, Niiden avulla suunnitellaan uudet tehtävät. Prosessin määrittely ja suunnittelu Prosessin arviointi Prosessin tunnistus Tunnistetaan prosessin tehtävät ja niiden kustannukset ja ajantarpeet. Tunnistetaan laatuja suorituskykyongelmat. 32
Ohjelmiston uudelleensuunnittelu Muokataan ohjelmistoa laadun parantamiseksi ja ylläpidon helpottamiseksi. Siirrytään esim. asiakas/palvelin arkkitehtuuriin tai palvelupohjaiseen arkkitehtuuriin. Esim. tiedostot korvataan tietokannalla. Muutokset voivat aiheuttaa muutoksia arkkitehtuuriin ja koodiin refaktorointi tiedon" uudelleen-" muotoilu" eteenpäin" suunnittelu! uudelleen-" koodaus! inventointi! uudelleen-" dokumentointi! Arvioidaan kaikki sovellukset - tarpeellisuus - ylläpidettävyys (katso kuvaus) kuinka paljon, kuinka täydellisesti takaisinmallintaminen! Ohjelmasta tuotetaan suunnittelutason kuvaus (katso kuvaus) 33
Olemassaolevien järjestelmien arviointi Koska järjestelmä on yritykselle tärkeä mutta huonolaatuinen (ylläpito kallista) kannattaa uudelleensuunnitella tai korvata uudella Järjestelmä pitää säilyttää toimintakunnossa, mutta tavalliset ylläpitotoimet riittävät Arvokas yritykselle & Laadultaan huono Arvokas yritykselle & Laadultaan hyvä Liiketoiminnan arvo Ei tärkeä yritykselle & Laadultaan huono Ei tärkeä yritykselle & Laadultaan hyvä Niin kauan kun tavalliset ylläpitotoimet riittävät, kannattaa pitää käytössä Laadultaan huonoa järjestelmää & yritykselle arvotonta ei kannata pitää toiminnassa Järjestelmän laatu Sommerville 2004
Takaisinmallintaminen / käänteistekniikka (reverse engineering) vain rakenteellisen ohjelmoinnin rakenteita dirty source code restructure code Käytetään aputyökaluja toiminnan ymmärtämiseksi clean source code extract abstractions processing interface Miten nykyinen käyttöliittymä toimii? Mikä on relevanttia jatkossa? initial specification refine & simplify database Tietomäärittelyjen arviointi esim. luokan attribuuttien kannalta. Tietokannan kaavan arviointi. final specification 35
30. Ohjelmistoprosessin parantaminen menetelmiä ja malleja kyvykkysmalli CMMI 36
Prosessin arviointi ja parantaminen Software Process identifies modifications to is examined by identifies capabilities and risk of Software Process Assessment Software Process Improvement leads to leads to Capability Determination motivates Pressman 2005
Ohjelmistoprosessin parantaminen yrityksessä PSP (Personal Software Process) Humphreyn (1996) esittämä menetelmä, joka tavoitteena on henkilökohtaisen osaamisen parantaminen TSP (Team Software Process) Humphreyn (2000) esittämä menetelmä, joka tavoitteena on ryhmätyön parantaminen SW-CMM (Capability Maturity Model) US DoD:n kehittämä malli alihankkijoiden ohjelmistoprosessin arvioimiseksi. Kiinnittää prosessin parannuskohteet viidellä kypsyystasolla (Humphrey 1989). Crosby esitteli tasot jo 1979. BOOTSTRAP Eurooppalainen versio SW-CMM mallista. Joustavampi kuin CMM, koska parantaminen voidaan kohdistaa haluttuun osaprosessiin (Kuvaja et al. 1994). Tuki loppui 2004. Ilkka Tervonen 38
Ohjelmistoprosessin parantaminen... SPICE (Software Process Improvement and Capability Determination) malli = ISO 15504 standardi BOOTSTRAPin periaatteiden pohjalle rakennettu standardi ISO 9001 CMM mallin kaltainen malli, jonka avulla varmistutaan alihankkijoiden ohjelmistoprosessin laadusta ISO 9001 sertifikaatti vastaa CMM tasoa 1-3 CMMI (Capability Maturity Model Integration) CMM mallin kehittyneempi versio (V1.1 julkistettiin Tammikuussa 2002) Mallin staged representation osa vastaa CMM mallia Mallin continuous representation osa vastaa SPICE mallia Ilkka Tervonen 39
Organisaatiokohtainen prosessin suorituskyky Mittauksiin perustuva projektin hallinta Organisaatiokohtainen innovointi ja käyttöön ottaminen Kausaalinen analyysi ja ratkaisut Vaatimusten kehittäminen Tekninen ratkaisu Tuotteen integrointi Verifiointi ja validointi Organisaatiokohtainen prosessin suuntaaminen Organisaatiokohtainen prosessinmäärittely Organisaatiokohtainen koulutus Integroitu projektin hallinta Integroitu sopimusten hallinta Riskien hallinta... Taso 3: Määritelty (defined) prosessin standardointi Taso 2: Hallittu (managed) projektin hallinta Taso 5: Optimoiva (optimizing) jatkuva parantaminen Taso 4: Määrällisesti hallittu Vaatimusten hallinta Projektin suunnittelu Projektin valvonta Alihankkijoiden sopimusten valvonta Mittaus ja analyysi Laadunvarmistus (prosessi ja tuote) Tuotteenhallinta Taso 1: Suoritettu (performed) CMMI (staged, tasoittainen) kypsyystasot ja prosessialueet
Jatkuva (continuous) CMMI malli Kyvykkyystaso 4 3 2 1 0 PP REQM MA CM PPQA... Prosessialue PP Project planning REQM Requirements management MA Measurement and analysis CM Configuration management PPQA Process and product quality assurance Taso 0: Epätäydellinen prosessialue (esim PP) ei toteuta tason 1 tavoitteita Taso 1: Suoritettu kaikki prosessialueen tavoitteet täytetty Taso 2: Hallittu kaikki tason 1 kriteerit saavutettu lisäksi noudatetaan organisaatiolle määriteltyjä menettelytapoja Taso 3: Määritelty kaikki tason 2 kriteerit saavutettu lisäksi prosessi on räätälöity organisaatiolle Taso 4: Määrällisesti hallittu kaikki tason 3 kriteerit saavutettu lisäksi prosessialuetta parannetaan mittauksin ja arvioinnein Taso 5: Optimoiva kaikki tason 4 kriteerit saavutettu lisäksi prosessialuetta optimoidaan tilastollisin keinoin Ilkka Tervonen 41
Jatkuva CMMI malli Jokaiselle prosessialueelle määritellään tavoitteet (specific goals, SG) ja käytänteet (specific practices, SP). Esim. projektin suunnittelu SG 1: Ota käyttöön arvioinnit SP 1.1 arvioi projektin laajuus SP 1.2 arvioi erilliset tehtävät projektissa SP 1.3 määrittele projektin elinjakso SP 1.4 määrittele työpanos- ja kustannusarviot SG 2: Kehitä projektisuunnitelma SP 2.1 tee budjetti ja aikataulu SP 2.2 tunnista projektin riskit SP 2.3 tee suunnitelma tiedon hallinnalle SP 2.4 tee suunnitelma projektin resursseista SP 2.5 tee suunnitelma tarvittavasta tietämyksestä ja taidoista SP 2.6 tee suunnitelma, miten asiakkaat otetaan mukaan SP 2.7 tee projektisuunnitelma SG 3: Hanki sitoutuminen suunnitelmaan Ilkka Tervonen 42
Jatkuva CMMI malli CMMI määrittelee myös viisi geneeristä tavoitetta GG (ja niitä vastaavat käytännöt GP), joiden avulla arvioidaan mille kyvykkyystasolle prosessialueessa on päästy GG 1: Toteuta prosessialueen erityiset tavoitteet (SG) GG 2: Vakiinnuta hallittu prosessi GP 2.1 ota käyttöön organisaatiokohtainen menettelytapa GP 2.2 suunnittele prosessi GP 2.3 varaa resurssit GP 2.4 kiinnitä vastuut GP 2.5 kouluta henkilöstö GP 2.6 hallitse tuotteet (konfiguraatiot) GP 2.7 tunnista ja sido prosessiin asiakkaan edustajat GP 2.8 valvo prosessia GP 2.9 arvioi prosessin noudattamista GO 2.10 katselmoi tilanne ylemmän johdon kanssa GG 3: Vakiinnuta määritelty prosessi GG 4: Vakiinnuta määrällisesti hallittu prosessi GG 5: Vakiinnuta optimoiva prosessi Ilkka Tervonen 43
ROI (Return on Investment) eri prosessin parantamistavoille David F. Rico 2003 (www.davidfrico.com/rico03apdf.htm) ROI = Ratio of adjusted benefits to costs Benefits - Costs x 100% Costs 40:1 33:1 Benefit/Cost Ratio 30:1 20:1 26:1 23:1 10:1 8:1 3:1 2:1 Inspection PSP TSP SW-CMM ISO 9001 CMMI
SEMAT (Software Engineering Methods and Theory) ydin (Asiat (alphat), joita työstetään ohjelmistojen kehittämisen aikana) Ilkka Tervonen Jacobson Ivar, Ng Pan-Wei, McMahon Paul, Spence Ian, Lidman Svante, The Essence of Software Engineering: the Semat Kernel CSI Communications, August 2013, pp. 7-14 45
Asiat, joita tehdään ohjelmistojen kehittämisen aikana Jacobson Ivar, Ng Pan-Wei, McMahon Paul, Spence Ian, Lidman Svante, The Essence of Software Engineering: the Semat Kernel CSI Communications, August 2013, pp. 7-14 46
Korttien avulla saadaan kehitys näkyväksi Jacobson Ivar, Ng Pan-Wei, McMahon Paul, Spence Ian, Lidman Svante, The Essence of Software Engineering: the Semat Kernel CSI Communications, August 2013, pp. 7-14 47
Korttien avulla arvioidaan tiimin/projektin tilanne Jacobson Ivar, Ng Pan-Wei, McMahon Paul, Spence Ian, Lidman Svante, The Essence of Software Engineering: the Semat Kernel CSI Communications, August 2013, pp. 7-14 48
Mitä seuraavaksi (mitä ei vielä olla tehty)? Jacobson Ivar, Ng Pan-Wei, McMahon Paul, Spence Ian, Lidman Svante, The Essence of Software Engineering: the Semat Kernel CSI Communications, August 2013, pp. 7-14 49
Soveltuvat lait ja pohdiskelun aiheita 1. Projektiriskit voidaan ratkaista tai niitä voidaan lieventää, kun ne tunnistetaan aikaisessa vaiheessa /hyp_no 17, Boehm 1989 Riskien hallinnan tulee olla luonnollinen osa projektin hallintaa. Spiraalimalli on hyvä esimerkki riskiohjatusta prosessimallista, joka ohjaa riskien tunnistamiseen varhaisessa vaiheessa.
Soveltuvat lait ja pohdiskelun aiheita 2. Pienissä muutoksissa on suurempi virhetiheys kuin suurissa muutoksissa / no 30, Basili&Perricone 1984, Möller 1995 Pienen muutoksen tekeminen vaatii laajan kokonaisuuden ymmärtämistä, aivan kuten suurissa muutoksissa. Pienten muutosten suhteellinen kustannus ja virhealttius on korkeampi. Lakia perustellaan esim. oheisella taulukolla (Basili&Perricone) tulosta on perusteltu rajapintavirheiden suurella osuudella ja niiden jakautumisella tasaisesti kaikkiin moduuleihin aineiston vinoudella (vain vähän suuria moduuleja, niitä testattu ehkä paremmin) Moduulin koko (lkm, virheellisten lkm) Kompleksisuus (keskiarvo) Virheitä / KLOC 0-50 (258, 49) 6.2 65.0 51-100 (70, 25) 19.6 33.3 101-150 (26, 13) 27.5 24.6 151-200 (13, 7) 56.7 13.4 > 200 (3, 2) 77.5 9.7
Soveltuvat lait ja pohdiskelun aiheita 3 Kypsät prosessit ja yksilöllinen taito parantaa suunnittelua, kasvattaa tuottavuutta ja vähentää virheitä / no 35, Humphrey 1989 Motorolan esimerkissä CMM 2 tasolla virheitä/kloc 4.4, tuottavuus 1.0 CMM 3 tasolla virheitä/kloc 2.1, tuottavuus 0.8 (syy: peer reviews) CMM 4 tasolla virheitä/kloc 1.0, tuottavuus 2.3 52
Soveltuvat lait ja pohdiskelun aiheita Mitkä kahdeksan omiin kokemuksiin perustuvaa, COTS perustaisten järjestelmien ylläpitoon liittyvää oppimaa Reifer et al. oheisessa paperissa esittävät? Buschmann esittelee kahdessa paperissaan kolme arkkitehtuurin hoitamiseen (gardening) ja parantamiseen liittyvää periaatetta, refaktoroinnin (refactoring), uudelleensuunnittelun (reengineering) ja uudelleen kirjoittamisen (rewriting). Kerro, mitä niillä tarkoitetaan ja miten ne pitäisi suorittaa, jos haluaa tehdä ne hyvin. Reifer D., Basili V., Boehm B., Clark B., Eight Lessons Learned during COTS-Based Systems Maintenance, IEEE Software, vol. 20, no. 5, 2003, pp. 94-96 Buschmann F., Gardening Your Architecture, Part 1: Refactoring, IEEE Software, vol 28, no 4, 2011, pp. 92-94 Buschmann F., Gardening Your Architecture, Part 2: Reengineering and Rewriting, IEEE Software, vol 28, no 5, 2011, pp. 21-23
Soveltuvat lait ja pohdiskelun aiheita Jacobson et al. esittelevät Semat periaatteen (Semat ydin & käsitemalli) oheisessa paperissa. Mitä etuja Semat ydin tarjoaa käyttäjälle tekijöiden mukaan? Mitä tarkoitetaan käsitteellä alpha? Miten tiimin tilannetta voidaan arvioida Semat korttien avulla? Jacobson I., Ng P-W, McMahon P., Spence I., Lidman S., The Essence of Software Engineering: the Semat Kernel, http://www.csi-india.org/c/ document_library/get_file?uuid=8e251272-4c46-49b5- a692-01564bae237f&
Harjoitustehtävät: viikko 9 Asenna Git versionhallintajärjestelmä koneellesi. Asennusohjeita löytyy esim. sivulta http://git-scm.com ja materiaalista http://git-scm.com/book 1. Tutustu Git versionhallintajärjestelmään sivulla http://linux.fi/wiki/git olevan esimerkkimateriaalin avulla ja aseta Gitille käyttäjänimesi ja sähköpostiosoite. 2. Ota jonkin hakemistosi tiedostot versionhallintaan, tee johonkin tiedostoon muutoksia ja commitoi (vahvista) ne commit komennolla. 3. Katsele tekemiäsi muutoksia log komennolla. 4. Luo uusi kehityshaara ja tee siellä muutoksia johonkin tiedostoosi ja commitoi ne. 5. Palaa takaisin master haaraan ja tee siellä muutoksia saman nimiseen tiedostoon kuin edellä ja commitoi ne. 6. Yhdistä kehityshaara ja master haara merge komennolla, korjaa tiedoston ristiriitaa aiheuttavat rivit ja commitoi muutokset versionhallintaan. 7. Katsele tekemiäsi muutoksia log komennolla. 8. Nimeä commitoidut versiot komennolla tag siten, että ensimmäinen versio on v1.0 ja viimeinen v2.0 (väliversiolle voit antaa nimet v1.1 jne.). 9. Vertaile versioiden eroja komennolla diff. 55
Harjoitustehtävät: viikko 9 Lisätehtävä (ei pakollinen) Jos haluat lisäharjoittelua voit tutustua sivulla http://nvie.com/posts/a-successful-git-branching-model/ esiteltyyn esimerkkiin, kuinka haarautumista voidaan käyttää eri versioiden ja julkaisujen hallintaan. Tee samankaltaista kehitys- ja julkaisuversioiden hallintaa jollekin omalle tiedostolle. 56
Harjoitustehtävät: viikko 10 Projektin tavoitteena on kehittää ohjelmisto varastettujen pyörien etsimiselle, joka toimii varastettujen kameratarvikkeiden etsimiskäytännön tapaan. Rahoitus projektille hankitaan joukkorahoituksella (crowdfunding). Tehtävänäsi on suorittaa projektin tilanteen arviointi SEMAT analyysin mukaisesti. Tässä riittää arvioida SEMAT alphat Asiakas (Customer) ja Ratkaisu (Solution) aihealueilla (areas of concern). Tämä tarkoittaa alphoja Mahdollisuus (Opportunity), Sidosryhmät (Stakeholders), Vaatimukset (Requirements) ja Ohjelmisto (Software system). Käytä arvioinnissa arviointipohjaa, joka löytyy tehtäväkuvauksesta (SEMAT esimerkki) kurssisivulta (Noppa) kohdasta Yhteinen lisämateriaali. 57