Jussi Isotupa 1 (13) Riskienhallintasuunnitelma v. 2.0 Päivitetty 11.2.2001 klo 21:30 RISKIENHALLINTASUUNNITELMA 1
Jussi Isotupa 2 (13) Dokumentin versiohistoria Versio Päivämäärä Muutoksen tekijä Selite 2.0 11.2.2001 Jussi Isotupa 3.1 & 3.2 Lisätty heikkoa koodia ja lisenssisiivousta koskevat riskit 3.3 Lisätty skenaariot Sk18, Sk19, Sk20 3.4 Riskien priorisointi päivitetty ajantasalle 3.5.3 Skenaarion käsittely poistettu ei-ajankohtaisena 3.5.4 Sk19:n käsittely lisätty 3.5.5 Sk20:n käsittely lisätty 1.0 11.12.2000 Jussi Isotupa Päivitetty ajantasalle palautusta varten 0.9 7.11.2000 Jussi Isotupa Sisällysluettelo 1. JOHDANTO...3 2. TAVOITTEET...3 2.1 Projektiryhmä...3 2.2 Asiakas...3 2.3 Koulu...3 3. RISKIT...3 3.1 Vapaamuotoinen riskilista...3 3.2 Riskianalyysi...5 3.3 Riskiskenaariot...6 3.4 Riskien priorisointi... 11 3.5 Toimenpiteet pahimmille riskeille... 11 LÄHDELUETTELO...13 RISKIENHALLINTASUUNNITELMA 2
Jussi Isotupa 3 (13) 1. Johdanto 2. Tavoitteet 2.1 Projektiryhmä 2.2 Asiakas 2.3 Koulu 3. Riskit Riskienhallinnan tehtävänä on projektin riskien kartoittaminen ja niihin varautuminen. Kartoittaminen on todennäköisten riskien tunnistamista ja niiden toteutumismahdollisuuksia arviointia. Tunnistamalla todennäköiset riskit, voidaan niihin varautua etukäteen ja riskeille ominaisia tunnusmerkkejä seuraamalla seurata riskien toteutumista. Riskien tunnistamiseen ja hallintaan käytetään Jyrki Kontion RiskIt menetelmää. RiskIt menetelmä perustuu eri sidosryhmien tavoitteiden määrittelyyn, jonka jälkeen pyritään tunnistamaan tavoitteiden toteutumista uhkaavia riskejä. Näin saadaan vapaamuotoinen riskilista. Riskilistasta pyritään tunnistamaan yksittäiset tekijät riskeille, näiden mahdolliset seuraukset ja reaktiot niihin. Tätä kutsutaan riskianalyysiksi. Riskianalyysista tunnistetaan pahimmat riskit ja suunnitellaan niihin varautuminen ja niiden tunnistaminen. Riskejä seurataan jatkuvasti projektin aikana, ja muutokset projektissa tai uudet identifioidut riskit lisätään riskianalyysiin, jonka jälkeen tulee jälleen priorisoida riskit jne. RiskIt menetelmä on jatkuva syklinen prosessi. Lisää tietoa RiskIt menetelmästä liitteessä [1].?? Aikataulu pitää (Aikataulu)?? Työmäärä ei ylity (Työmäärä)?? Vaatimukset saadaan toteutettua (Vaatimukset)?? jäsenten työmäärä on tasapuolinen (Tasapuolisuus)?? TOP-10, kts. projektisuunnitelma [2]?? Aikataulu pitää, niin että projekti on valmis kurssin loppuessa?? Hyvien projektityöskentelytapojen opettaminen -> kurssin läpäisy?? jäsenten työmäärä pysyy järkevi ssä mitoissa 3.1 Vapaamuotoinen riskilista?? toteutettavat ratkaisut eivät ole geneerisiä RISKIENHALLINTASUUNNITELMA 3
Jussi Isotupa 4 (13)?? luodaan metodirajapinnalla tietoturva-aukko?? ei tunneta LDAP-rajapintaa tarpeeksi hyvin, että voitaisiin luoda geneeriset rajapinnat?? ei osata ajatella tulevaisuuden tarpeita?? LDAP pelkkä protokolla, hakemistojen toteutukset vaihtelevat -> geneerisyys menetetään?? ei olla tiedostettu kaikkia asiakkaan tarpeita ja vaatimuksia?? asiakas ei tiedä mitä haluaa?? sovelluskehikko ei riittävä suorituskyvyltään?? dokumentointi riittämätöntä, että kehikkoa voisi jatkossakin käyttää ja kehittää?? käytetään J2EE standardiin kuulumattomia sovelluspalvelimen toimintoja?? ohjelmistot ryppyilevät?? projektiryhmän jäsen kyllästyy?? sovelluskehikko liian vaikea käyttää?? projektiryhmän jäsen sairastuu?? sovelluskehikosta ei saavuteta riittävää hyötyä vanhaan tapaan verrattuna?? projektiryhmän jäsenten muut sitoumukset vievät liikaa aikaa?? projekti hyvin abstrakti?? tehtävät aliarvioidaan?? omat kyvyt ja ajankäytön tehokkuus yliarvioidaan?? A-Waren lisenssiasiat aiheuttavat ongelmia testiympäristön kanssa?? tuotettu koodi on huonoa RISKIENHALLINTASUUNNITELMA 4
Jussi Isotupa 5 (13) 3.2 Riskianalyysi Sovelluskehikko ei vastaa vaatimuksia Ei tehdä mitään Ei vastaa vaatimuksia Projektin abstraktius Rajapintojen määrittelyssä epäonnistutaan Koodia kirjoitetaan uudelleen Aikataulu pitää Tuotettu koodi on heikkolaatuista Projektinryhmän kokemattomuus JAVAn ja J2EE tekniikoiden suhteen Sovelluskehikko liian vaikea käyttää Määritellään uudelleen Aikataulu ylittyy Työmäärä ylittyy Vaatimukset toteutuvat Toteutettava esimerkkiprojekti Sovelluskehikko liian jäykkä eikä laajennettavissa Haetaan ongelmakohta ja optimoidaan Aikataulu venyy Työmäärä ylittyy Tekniikka, palvelinalusta ja sovelluspalvelinsoftat Sovelluskehikko vastaa vain esimerkkisovellu ksen tarpeita Hyväksytään hitaus Sovelluskehikko ei vastaa vaatimuksia Sovelluskehikko on liian hidas RISKIENHALLINTASUUNNITELMA 5
Jussi Isotupa 6 (13) jäsen lopettaa Siirretään vastuuta toiselle ryhmän jäsenelle Yhden työmäärä kasvaa merkittävästi Aikataulut ylittyy lievästi Projektinryhmän jäsenet jäsen sairastuu väliaikaisesti Jaetaan vastuu kaikille muille Kaiikkien työmäärä kasvaa hieman Aikataulu ylittyy lievästi Työnjako epäselvä Aikataulu ylittyy Koulun ulkopuoliset sitoumukset Ryhmän jäsenen muut sitoumukset vievät ajan projektilta Annetaan runtua Muiden työmäärä kasvaa Tasapuolisuus menetetään Tasapuolisuus toteutuu Työmäärä tasoittuu Aikataulu pitää Ryhmän jäsentä rupeaa laiskottamaan RISKIENHALLINTASUUNNITELMA 6
Jussi Isotupa 7 (13) Alimitoitetut aikatauluarviot Siirretään resursseja esimerkkisovellu ksesta Esimerkkisovelluksen vaatimusmäärittely ei toteudu Kokemattomuus projektityöskentelyssä Yliarvioidaan omat kyvyt ja tehokkuus Ei tehdä mitään Aikataulu ylittyy Muuttuvat vaatimukset Toteutus ei vastaa määrittelyä Tehdään vaadittavat muutokset Työmäärä ylittyy Ei tehdä mitään Vaatimukset eivät toteudu RISKIENHALLINTASUUNNITELMA 7
Jussi Isotupa 8 (13) Webspherelisens si ei käytössä Käytetään TomCattia Työmäärä ylittyy Aikataulu ylittyy A-Waren lisenssisiivous EJB ei käytettävissä Käytetään Websphereä ILMAN EJB:tä EJB-toteutusta ei voida teatata RISKIENHALLINTASUUNNITELMA 8
Jussi Isotupa 9 (13) 3.3 Riskiskenaariot Riskiskenaario Indikaattorit Sk1 Projektin abstraktius Rajapintojen määrittelyssä epäonnistutaan > Sovelluskehikko ei vastaa vaatimuksia Sk2 Projektin abstraktius Rajapintojen määrittelyssä epäonnistutaan > Sovelluskehikko liian vaikea käyttää Demoryhmä valittaa Sk3 kokemattomuus Javan ja J2EE -tekniikoiden suhteen Rajapintojen määrittelyssä epäonnistutaan > Sovelluskehikko ei vastaa vaatimuksia Sk4 kokemattomuus Javan ja J2EE -tekniikoiden suhteen Rajapintojen määrittelyssä epäonnistutaan > Sovelluskehikko liian vaikea käyttää Demoryhmä valittaa Sk5 kokemattomuus Javan ja J2EE -tekniikoiden suhteen Sovelluskehikko liian hidas Stressitestaus Sk6 Toteutettava esimerkkiprojekti Sovelluskehikko liian jäykkä eikä laajennettavissa Use Caset Arton feedback arkkitehtuurista Sk7 Toteutettava esimerkkiprojekti Sovelluskehikko vastaa vain esimerkkisovelluksen tarpeita Use Caset Arton feedback arkkitehtuurista Sk8 Tekniikka, palvelinalusta ja sovelluspalvelinsoftat Sovelluskehikko liian jäykkä eikä laajennettavissa Use Caset Arton feedback arkkitehtuurista Kokeet muilla sovelluspalvelimille, esim J2EE-referenssiimplementaatiolla Sk9 Tekniikka, palvelinalusta ja sovelluspalvelinsoftat Sovelluskehikko liian hidas Stressitestaus Sk10 jäsenet jäsen lopettaa Ei tee töitä RISKIENHALLINTASUUNNITELMA 9
Jussi Isotupa 10 (13) lopettaa Selityksiäselityksiä Perävalot vilkkuu Sk11 jäsenet jäsen sairastuu väliaikaisesti Sk12 jäsenet jäsenen muut sitoumukset vievät ajan projektilta Tehtävät eivät tule tehtyä ajallaan Tehtävien suoritus aloitetaan vasta viime hetkellä Selityksiä Jäsen tekee töitä viikossa yli 30 tuntia. Sk13 jäsenet jäsentä rupeaa laiskottamaan Tehtävät eivät tule tehtyä ajallaan Tehtäviä ei aloiteta Selityksiä Sk14 jäsenet Avainhenkilö Tomas sairastuu vakavasti tai kyllästyy tai lopettaa Tomaksen motivaatio heikkenee Sk15 Kokemattomuus projektityöskentelyssä Alimitoitetut aika-arviot Työajat ylittyvät toistuvasti Sk16 Kokemattomuus projektityöskentelyssä Toteutus ei vastaa määrittelyä Arton feedback Sk17 kokemattomuus Javan ja J2EE -tekniikoiden suhteen Alimitoitetut aika-arviot ja omien kykyjen yliarviointi Tehtävät aloitetaan myöhään Aikataulut ylittyvät Selitykset ja valitukset Sk18 A-Waren lisenssisiivous WebSphere ei käytettävissä Sk19 A-Waren lisenssisiivous WebSpheren Enterpriseversio ei käytettävissä Sk20 kokemattomuus Javan ja J2EE -tekniikoiden suhteen Tuotettu koodi on heikkolaatuista Paljon riippuvuuksia Paljon toiminnallisuutta yhdessä luokassa Ei virhetarkistuksia Sovelluskehikon tai Java APIn väärä käyttötapa Vähäinen kommentointi Huono ohjelmointitapa yleensä RISKIENHALLINTASUUNNITELMA 10
Jussi Isotupa 11 (13) 3.4 Riskien priorisointi Vakava Normaali Mitätön Todennäköinen Sk19, Sk20, Sk12, Sk15, Sk17 Sk11 Ei kovin todennäköinen Sk8, Sk16 Sk2, Sk4, Sk5, Sk9 Epätodennäköinen Sk3, Sk1, Sk6, Sk7, Sk10, Sk14 3.5 Toimenpiteet pahimmille riskeille Tähän lukuun on listattu pahimmat ja ajankohtaiset riskit, joita tulisi seurata tarkemmin ja joihin on varauduttu. 3.5.1 Sk12 jäsenen muut sitoumukset vievät ajan projektilta Tämä on todennäköisin riski, johtuen jo siitä faktasta, että kaikki ryhmän jäsenet ovat tällä hetkellä töissä. Indikaattorit: Riskin indikaattorit ovat myöhästyneet tehtävät, myöhässä aloitetut tehtävät, jatkuvat selitykset ja yksinkertaisesti se, että jäsen kertoo töiden painavan päälle. Vaikutukset: Aikataulu ylittyy, kun suunniteltuja tehtäviä ei saada tehtyä. Vaihtoehtoisesti voidaan tinkiä toteutettavista ominaisuuksista. t: Analysoidaan ongelma, jonka jälkeen siirretään Mickey tai Timo esimerkkisovelluksen parista sovelluskehikon puolelle tai tingitään tavotteista. Esimerkkisovelluksen jääminen vaatimuksistaan ei ole vakavaa, toisin kuin sovelluskehikon. Jos esimerkkisovelluksen toteutus ontuu pahasti ja sovelluskehikko etenee mainiosti, kuten tällä hetkellä näyttää, voi sovelluskehikkoryhmä auttaa hieman, jotta sovelluskehikkoa saadaan kokeiltua käytännössä. Tavotteista voidaan tingiä vain, jos näyttää siltä että ryhmän työmäärä ylittyy huomattavasti, kts. projektisuunnitelma. Huomiot: Timon työpanos tulee tiputtaa KOKONAAN pois suunnitelmista. Ei Timo kuitenkaan mitään ehdi tekemään. Timon ja projektijohdon tulisi harkita, jatkaako Timo ryhmässä vai ei. RISKIENHALLINTASUUNNITELMA 11
Jussi Isotupa 12 (13) 3.5.2 Sk15 & Sk17 - Alimitoitetut aika-arviot ja omien kykyjen yliarviointi Indikaattorit: Tehtävien suoritus kestää toistuvasti yli suunnitellun työajan. Ryhmän jäsenet purnaavat ja valittavat sekä selittelevät. Tehtävien suoritus aloitetaan liian myöhään suhteessa aikatauluun. Vaikutukset: Aikataulu venyy ja suunniteltuja asioita on vaikea saada tehdyksi palautukseen mennessä. t: Pyritään pilkkomaan tehtävät selkeämpiin ja pienempiin kokonaisuuksiin jo etukäteen, joiden arviointi on helpompaa. Näin pyritään ennaltaehkäisemään riskin tapahtumista seuraavassa vaiheessa. Riskin käydessä päälle siirretään resursseja muualta, mikäli mahdollista sekä järjestetään koulutusta aiheesta (Tomas), joka aiheuttaa ongelmia. Muistetaan korostaa säännöllisen työnteon merkitystä, johon ryhmän jäseniä yritetään painostaa projektipalavereilla ja sähköpostin avulla tehtävillä edistymisraporteilla. Huomiot: Esimerkkisovellusryhmän vähäinen kokemus Java-tekniikoiden osalta ja Mickeyn osalta ylipäätään palvelinpuolen tekniikoiden suhteen tekee heidän aikatauluarviointinsa käytännössä mahdottomaksi. Sovelluskehikkoryhmän tulisi tulla vastaan tässä osassa ja antaa konsultaatioita aika-arvioiden suhteen. 3.5.3 Sk4 - kokemattomuus Javan ja J2EE-tekniikoiden suhteen Riski ei liene enää ajankohtainen. 3.5.4 Sk19 A-Waren lisenssisiivous A-Warella on käynnissä lisenssitarkastus, jossa tarkastetaan onko kaikki A-Waren lisenssit tarpeellisia, ja onko koneilla lisensoimattomia asennuksia. Voi olla, että ryhmällä ei ole tarkastuksen jälkeen käytettävissä WebSpheren Enterprise-versiota, jolloin ei EJB-toteutusta voida kokeilla. Indikaattorit: A-Waren lisenssitarkastus Vaikutukset: EJB-toteutusta ei voida kokeilla WEBSPHEREllä, joka toimii testi- ja demoympäristönä. t: Ryhmällä on käytössään myös Sunin J2EE-referenssi-implementaatio sekä TomCat. Näillä työkaluilla EJB-toteutus voidaan testata, mutta kumpikaan sovelluspalvelimista ei sinällään kelpaa demoympäristöksi. Lisäksi TomCatia ei ole tämän projektin yhteydessä kokeiltu, joten sen asentaminen toimintakuntoon lienee työlästä. RISKIENHALLINTASUUNNITELMA 12
Jussi Isotupa 13 (13) Toisin sanoen, ensisijaisesti kokeillaan EJB:tä J2EE-referenssi-implementaatiolla. Toissijaisesti käytetään TomCatia. Mikäli WebSphere ei ole käytettävissä, tulisi uuden sovelluspalvelimen asennukseen sekä siihen liittyvään säätöön varata aikaa n. 10 tuntia. 3.5.5 Sk20 Heikkolaatuinen koodi Heikkolaatuisella koodilla tarkoitetaan tässä koodia, joka on tehokkuudeltaan tai ylläpidettävyydeltään huonoa. Indikaattorit:?? Paljon riippuvuuksia luokkien välillä?? Paljon toiminnallisuutta yhdessä luokassa?? Ei virhetarkistuksia?? Sovelluskehikon tai Java APIn väärä käyttötapa?? Vähäinen kommentointi?? Huono ohjelmointitapa yleensä Vaikutukset: Koodin ylläpidettävyys ja toimivuus on huono. Koodi on myös vaikeaselkoista, jolloin sitä ei ymmärrä muu kuin tekijä. Koodi on huonosti uudelleenkäytettävää. t: Kirjoitetaan uudelleen, kunnes koodi läpäisee sisäisen laadunvalvonnan. Timo ei koodia katsele, mutta työparit keskenään tekevät pienimuotoisia koodikatselmuksia. Huomiot: Mickeyn ja Mikon kokemattomuus Java-ohjelmoinnin suhteen näyttäisi aiheuttavan, että heidän koodinsa ei kriittisempien ryhmän jäsenten silmää miellytä. Mikolle ja Mickeylle tulee neuvoa kuinka asiat tulisi tehdä. Lähdeluettelo [1] Jyrki Kontio: The Riskit Method for Software Risk management, version 1.00, CS-TR-3782, 1997 [viitattu 11.12.2000], Computer Science Techical Reports, University of Maryland, College Park, MD. RISKIENHALLINTASUUNNITELMA 13