3a. Projektin hallinta (lisäys lukuun 3)

3a. Projektin hallinta (lisäys lukuun 3) Tehokas projektin hallinta keskittyy kolmeen osaalueeseen: henkilökuntaan, tehtävään ja prosessiin. Henkilökunta: on yrityksen tärkein voimavara, oikea henkilö oikeassa tehtävässä = menestys, väärä henkilö väärässä tehtävässä = kaaos. Henkilöhallinnan alueita: palkkaus, valinta tehtäviin, souritusten seuranta, koulutus, hyvitysperiaatteet, urakehitys, työnkuva ja ryhmätyön kehittäminen. Tehtävä: Onnistunut projekti vaatii tarkan rajauksen ja yksityiskohtaisen tehtäväkuvauksen. Sivu - 89 - Projektin hallinta (jatkuu) Prosessi: Sopivaa prosessia käyttämällä saadaan kehys projektille. Yksityiskohtaiset tehtävät määritellään projektin alkuvaiheessa käytetyn prosessin mukaisesti. Sekä tuotteen että projektin laatua valvotaan koko projektin kestoajan. Tehtävästä ja prosessista on puhuttu aiemmin. Sen sijaan henkilöistä ei ole puhuttu juuri mitään. Projektin tärkeimmät osallistujat ovat projektipäällikkö ja projektin jäsenet. Muita osallistujia ovat mm. asiakkaan tekniset asiantuntijat, johtoryhmä ja markkinointiosastojen työntekijät. Sivu - 90-1

Projektipäällikkö Projektipäällikkö vastaa projektin lisäksi projektin jäsenistä. Projektipäälliköltä vaaditaan: ongelmanratkaisukykyä: Hän ymmärtää työalueen ja pystyy löytämään uusia ratkaisuja. Hän osaa motivoida muita. johtamistaitoa: Hän ottaa suurimman vastuun projektin onnistumisesta. Hän osaa tehdä päätöksiä ja ottaa vastuuta myös vaikeissa tilanteissa. kannustuskykyä: hän kannustaa ryhmää hallittuun riskinottoon ja uusien ideoiden tuottamiseen. pyskologista silmää: hän ymmärtää ryhmän jäsenten välisiä jännitteitä. Hän järjestää tehtävät sillä tavalla, että ryhmän jäsenet tuntevat työskentelevänsä miellyttävässä ympäristössä. Sivu - 91 - Projektiryhmä Projektiryhmän rakenne: Demokraattinen hajautettu (DD, democratic decentralized): Ryhmällä ei ole pysyvää johtajaa. Jokaisella tehtävällä on vastuuhenkilö, joka vaihtuu tehtävän vaihtuessa. Kommunikointi tapahtuu demokraattisesti ryhmän sisällä. Ohjattu hajautettu (CD, controlled decentralized): Koko projektilla on vastuussa oleva johtaja. Projektiryhmä on jaettu osaryhmiin, joista jokaisella on päällikkö. Ongelmanratkaisu tapahtuu yleensä ryhmässä, mutta toteutus tehdään osaryhmissä. Kommunikointi tapahtuu pääasiassa osaryhmien sisällä. Ohjattu keskitetty (CC, controlled centralized): Ryhmällä on projektipäällikkö, joka hoitaa keskitetysti koko projektin hallinnan. Projektin jäsenille annetaan selkeät tehtävät. Kommunikointi tapahtuu projektipäällikön kautta. Sivu - 92-2

5. Kuvaustekniikat Tämä luku perustuu Sommervillen lisäksi kirjaan Martin Fowler, UML Distilled - Second Edition. Addison-Wesley, 2000. (Kirja löytyy kurssikirjahyllystä eikä sitä tarvitse hankkia erikseen) Nimensä mukaisesti vaatimusanalyysiin kuuluu analyysivaihe. Tässä vaiheessa on järkevää rakentaa yksi tai useampi malli järjestelmästä. Malli toimii sekä yksiselitteisenä kuvauksena vaatimuksista että vaatimusanalyysin ja suunnittelun välisenä siltana. Sivu - 93 - Abstrahointi Mallinnuksen tärkein piirre on abstrahointi. Kaikkea tietoa ei esitetä, vaan mallit esitetään eri abstraktiotasoilla. Korkein abstraktiotaso on käyttäjän vaatimusten taso. Matalin abstraktiotaso on kirjoitettava koodi. Näiden välissä meillä on abstraktiotasoja, joiden kuvaamiseen voidaan käyttää erilaisilla graafisia ja tekstipohjaisilla kuvauskielillä malleja. Jokainen malli näyttää yhden näkymän järjestelmästä. Mallien näkymät ovat erilaiset, mutta kaikki kuvaavat samaa asiaa. Sivu - 94-3

UML Unified Modeling Language (UML) on nykyisin de facto standardi oliojärjestelmien kuvauskieli. Se määrittelee useita kieliä, joita voidaan käyttää prosessin työvaiheissa kuvaamaan ohjelmiston näkymiä ja abstraktioita. Tällä kurssilla esittelen seuraavat UML-kaaviot: käyttötapauskaaviot, luokkakaaviot ja tilasiirtymäkaaviot. Lisäksi esittelen UML:n ulkopuolisina tietovuokaaviot. Sivu - 95-5.1.Käyttötapauskaavio Käyttötapauskaavio kuvaa yhden tai useamman käyttötapauksen, tapausten toimijat tai roolit (actors) ja tapauksien keskinäiset ja roolien väliset suhteet. Kuvattava käyttötapaus on jokin toimijan ja järjestelmän välinen toiminta alusta loppuun. Alku: Tila juuri ennen käyttötapausta. Esim. henkilö on käynnistämässä ohjelmaa. Loppu: Tila käyttötapauksen päätyttyä. Esim. henkilö sulkee käyttämänsä ohjelman. Käyttötapauskaaviossa käyttötapaukset kuvataan soikioina ja toimijat tikku-ukkoina. Käyttötapausten kuvaukset kirjoitetaan erikseen. Sivu - 96-4

Käyttötapauskaavio (jatkuu) Toimija tai rooli liittyy yhteen tai useampaan käyttötapaukseen, ja yhteen käyttötapaukseen liittyy yksi tai useampi toimija. Yksi Henkilö voi olla useassa eri roolissa eli useana eri toimijana käyttötapauksessa. Käyttötapauksista voidaan tehdä erikoistapauksia Yleistys-relaatiolla. Näitä käytetään esimerkiksi silloin, kun halutaan kuvata oikein toimittuun käyttötapaukseen liittyviä virheellisiä toimintoja. Relaatio on Yleistys, koska varsinainen käyttötapaus on yleistys erikoistuneesta käyttötapauksesta. Sivu - 97 - Käyttötapauskaavio (jatkuu) Yleistyksen lisäksi UML määrittelee laajennoksen (extension). Laajennos toimii samoin kuin yleistys, mutta sille voidaan antaa lisäksi sääntöjä, jotka vaikuttavat laajennetun käyttötapauksen toimintaan. Viimeisenä käyttötapausten välisenä relaationa UML määrittelee sisältyvyyden (include). Se tarkoittaa, että useat käyttötapaukset voivat sisältää yhteisiä osia, jotka on eroteltu omaksi käyttötapaukseksi. Käyttötapauskaaviot antavat rakennetta käyttötapauksille, mutta kaavioita tärkeämpiä ovat itse käyttötapausten kuvaukset. Sivu - 98-5

Käyttötapauskaavion symbolit Toimija/rooli (actor) <<extend>> Laajentaa Käyttötapaus (Use Case) Laajennospisteet (extension points) Yleistys (generalization) <<include>> Sisältää Käyttötapaus (Use Case) Käyttötapaus (Use Case) Käyttötapaus (Use Case) Sivu - 99 - Käyttötapauskaavioesimerkki Sivu - 100-6

5.2. Luokkakaaviot Luokkakaavio on UML:n yleisimmin käytetty kuvauskieli. Luokkakaavioita voidaan käyttää järjestelmäanalyysista aina testaukseen asti. Luokkakaavioihin on kolme näkökulmaa: Käsitenäkökulma (conceptual): kuvataan järjestelmää, sen komponentteja, suhteita muihin järjestelmiin ja käyttäjiin. Tämä on vaatimusanalyysin näkökulma. Määrittelynäkökulma (specification): kuvataan ohjelmistoa, mutta keskitytään rajapintoihin toteutuksen sijaan. Tämä on korkean tason suunnittelun näkökulma. Toteutusnäkökulma (implementation): kuvataan ohjelmistoa, sen toteutusta, navigointia oliosta toiseen, olioiden tarjoamia palveluja ja kutsutapoja. Tämä on matalan tason suunnittelun näkökulma. Sivu - 101 - Luokkakaaviot (jatkuu) UML:n luokkakaaviot on kuvattu yksityiskohtaisesti Johdatus sovellussuunnitteluun -kurssilla, joten meille riittää kertaus. Luokkakaavio sisältää: Luokkia (classes). Jokainen luokka esittää kokoelmaa abstrakteja tai todellisia olioita. Samaan luokkaan kuuluvat oliot näyttävät samalta ja toimivat samoilla säännöillä. Yhteyksiä (associations). Luokkien välillä voi olla yhteyksiä. Yhteys kuvaa jonkin suhteen, joka pätee kahden luokan olioiden välillä - tai saman luokan, jos yhteys on rekursiivinen. Yleistyksiä (generalizations). Jokin luokka voi erikoistapaus toisesta. Tällöin erikoistapausluokan oliot ovat myös yleisemmän luokan olioita. Sivu - 102-7

Luokkakaavion sisältöä Luokka sisältää tietoa siihen kuuluvien olioiden ominaisuuksista (attribuuteista) ja tietoa siihen kuuluvien olioiden toiminnoista. Yhteys sisältää asteet: montako oliota kustakin luokasta voi/täytyy osallistua tähän yhteyteen ja roolit: miten yhteyteen osallistuvat luokat esiintyvät yhteydessä. Yleistys sisältää viittauksen yliluokkaan: mistä luokasta yleistetään viittauksen aliluokkaan: mikä on yleistetyn luokan erikoistapaus. Sivu - 103 - Erityisiä yhteyksiä UML määrittelee kaksi erityistä yhteyttä: aggregaatin (aggregate) ja komposition (Composite). Aggregaattiyhteys (kokouma, yhdistelmä) on eräänlainen sisältääsuhde: auto sisältää osinaan moottorin ja pyörät. Komposiittiyhteys (kooste) on aggregaattia vahvempi yhteys. Se määrittelee rakenteisen suhteen: osat kuuluvat täsmälleen yhteen kokonaisuuteen. Kokonaisuus ja osat elävät ja kuolevat yhdessä. Esim. Jos meillä on aggregaattiyhteys auto-rengas, niin tulkintana on, että autossa on renkaat, mutta renkaita voidaan säilyttää erillään autosta (esimerkiksi talvirenkaat). Sen sijaan komposiittiyhteytenä auton renkaat ovat erottamaton osa autoa eikä niitä voida esimerkiksi ottaa erilleen, kun auto viedään romuttamolle. Sivu - 104-8

Luokkakaavioesimerkki Kihlasormus 1..2 1 Avioitunut henkilö 1..* * Avioliiton kautta tullut sukulainen Aviomies 1 Isä 1 1 1 Äiti Aviovaimo Äiti 1 0..1 * 0..1 Ydinperhe 0..1 2..* Lapsi Sivu - 105-5.3. Tietovuokaaviot Tietovuokaavioiden avulla pyritään selvittämään, miten tieto kulkee järjestelmässä ja mitä muutoksia siihen kohdistuu. Tietovuokaavioita pidetään joskus vanhanaikaisina kuvausmenetelminä, mutta oikein käytettyinä ne sopivat erittäin hyvin järjestelmäsuunnitteluun ja vaatimusanalyysin korkean abstraktiotason mallinnukseen. Kaaviot perustuvat tarkennuksiin: ylemmän tason kaavion toimintaa tarkennetaan yhdellä tai useammalla alemman tason kaaviolla. Sivu - 106-9

Tietovuokaavioiden komponentit Tietovuokaavioiden komponentit ovat seuraavat: Ulkoiset oliot eli sidosryhmät. Ulkoiset oliot tuottavat järjestelmään tietoa ja syötteitä ja toisaalta ottavat tulosteet vastaan. Ulkoinen olio vastaa pitkälti käyttötapauskaavioiden toimijaa. Prosessit. Prosessi on järjestelmän sisäinen komponentti, joka muokkaa tietoa toiseen muotoon. Kaikki tiedon käsittely tapahtuu prosesseissa. Tietovuot. Tietovuo kuvaa tiedon kulkua ulkoiselta oliolta järjestlemän sisälle ja järjestelmän sisällä prosessista toiseen. Tietovuossa liikkuu nimensä mukaisesti tieto. Tietovarastot. Tietovarasto on tiedon pysyvä tai väliaikainen talletuspaikka. Tietovaraston toteutustapaa ei ole kiinnitetty. Sivu - 107 - Kaaviot Korkeimmalla tasolla oleva tietovuokaavio on yhteyskaavio. Siinä kuvataan sidosryhmät, niistä järjestelmään tulevat tietovuot ja niille järjestelmästä lähtevät tietovuot. Itse järjestelmä kuvataan yhtenä prosessina. Ensimmäinen varsinainen tietovuotaso on yleiskaavio. Siinä kuvataan järjestelmän tärkeimmät prosessit ja niiden väliset tietovuot. Tietovuokaavioiden piirto on hierarkkista. Järjestelmän prosesseja tarkennetaan kunnes päästään halutulle tarkkuustasolle. Sivu - 108-10

Kaavioiden tarkennus Tarkennuksessa valitaan tarkennettavasta tietovuokaaviosta jokin prosessi, joka sitten kuvataan useana osaprosessina uudessa tietovuokaaviossa. Tietovuokaavioiden tarkennuksessa informaatiota ei synny eikä häviä. Käytännössä tämä tarkoittaa, että jotain tietovuokaavion prosessia tarkennettaessa prosessiin tulevat ja sieltä lähtevät tietovuot tulevat myös tarkennukseen. Sivu - 109 - Ohjaustiedot Edellisillä komponenteilla kuvataan järjestelmiä, joiden toiminta riippuu yksinomaan käsiteltävistä tiedoista. Hyvin usein järjestelmän toiminta on kuitenkin ohjauspainotteista. Tällöin ulkoiset tapahtumat vaikuttavat siirtymisiin prosessista toiseen. Ohjauspainotteisissa tietovuokaavioissa kuvataan myös ohjaustiedon siirtyminen prosessista toiseen. Osa prosesseista ja tietovarastoista voi olla puhtaasti ohjaavia. Sivu - 110-11

Tietovuokaavioiden elementit Rooli Ulkoinen olio Tehtävä Prosessi (ohjausprosessi katkoviivalla) Tieto Tieto Tietovuo (ohjausvuo katkoviivalla) Tietovarasto (ohjaustietovarasto katkoviivalla) Sivu - 111 - Tietovuokaavioesimerkki Sivu - 112-12

5.4. Tilasiirtymäkaaviot Kaikilla järjestelmillä, osajärjestelmillä ja olioilla on tila: kaikkien jo toteutuneiden tapahtumien vaikutus. Järjestelmä siirtyy tilasta toiseen, kun saapuva tapahtuma (event) vaikuttaa sen tilaan. Tilalasiirtymäkaavioita käytetään kuvaamaan järjestelmän, osajärjestelmän tai olion kaikkia tiloja ja siirtymisiä tilasta toiseen. Tilasiirtymäkaavio voidaan piirtää koko järjestelmästä, sen osasta tai oliosta. Periaate on aina sama. Vain mittakaava muuttuu. Sivu - 113 - Tilat Tilasiirtymäkaavioita käytetään kuvaamaan, miten järjestelmä reagoi tapahtumiin ja miten tapahtumat muuttavat järjestelmän tilaa. Esimerkiksi tällä PowerPoint-esityksellä on tila: kulloinkin näytettävä kalvo. Kun painan välilyöntinäppäintä, siirrän samalla esityksen uuteen tilaan, eli seuraavalle kalvolle. UML:ssa tilasiirtymäkaavion tiloja kuvataan pyöreäreunaisella suorakulmiolla ja siirtymiä nuolilla. Lisäksi tilasiirtymäkaaviolla voi olla lähtöpiste ja useita päätepisteitä. Lähtöpiste kuvataan mustalla ympyrällä ja päätepiste avoimella ympyrällä, missä on musta keskipiste. Sivu - 114-13

Tilan rakenne Jokaisella tilalla on tilan merkityksen kertova nimi. Lisäksi tilalla voi olla tilariippuvia muuttujia, kuten laskureita, ja tilassa tapahtuvia toimintoja selittäviä tapahtuma/toiminto -pareja. UML määrittelee kolme vakiotapahtumaa: entry, exit ja do. entry -toiminnot suoritetaan, kun järjestelmä tulee tilaan. exit-toiminnot suoritetaan, kun järjestelmä poistuu tilasta. do-toiminnot suoritetaan, kun järjestelmä on tilassa. Käyttäjä voi määritellä omia tapahtumia, joiden toteutuessa toimitaan vastaavan toiminnon mukaan. Sivu - 115 - Siirtymän rakenne Siirtymä kuvataan nuolella lähtötilasta maalitilaan. Lisäksi siihen voi kuulua tieto siirtymän aiheuttaneesta tapahtumasta ja laukaisimesta. Laukaisin (trigger) on ehto, jonka täytyy toteutua, jotta järjestelmä voi siirtyä tapahtuman tullessa tilasta toiseen. Laukaisinten avulla kuvataan ehdollisia siirtymiä. Siirtymän toteutuminen vaatii sekä saapuneen tapahtuman että toteutuneen laukaisimen. Sekä tapahtuma että laukaisin voivat yksin aktivoida siirtymän. Molempien ei ole pakko olla mukana. Sivu - 116-14

Tilasiirtymäkaavion komponentit Lähtöpiste Päätepiste Nimi Muuttujat tapahtuma/toiminto tapahtuma/toiminto Tila tapahtuma [laukaisin] Siirtymä Sivu - 117 - Tilasiirtymäesimerkki (hissi) Ensimmäisessä kerroksessa ylös (kerros) Menossa ylös perillä perillä ylös (kerros) Menossa ensimmäiseen kerrokseen Menossa alas perillä Odottaa ajastin = 0 do/kasvata ajastinta help/anna opastusta alas (kerros) [ajastin = maksimi odotusaika]/alas (ensimmäinen kerros) Sivu - 118-15

5.5. Muut UML:n kaaviot Edellä esiteltyjen kaaviotekniikkojen lisäksi UML:n nykyinen versio määrittelee seuraavat kaaviot: Oliokaavio (object diagram): Tämä on lähes samanlainen kuin luokkakaavio, mutta luokkien sijaan tässä kuvataan varsinaisia olioita ja niiden välistä yhteistyötä. Oliokaaviot (ja luokkakaaviot) käsittelevät staattista yhteistyötä. Aika ja tapahtumien järjestys eivät näy näissä kaavioissa. Sekvenssikaavio (sequence diagram): Tällä kaaviolla kuvataan olioiden välistä dynaamista yhteistyötä. Kaaviosta selviää, missä järjestyksessä oliot kutsuvat toistensa palveluja tietyllä hetkellä. Yhteistyökaavio (collaboration diagram): Myös tällä kaaviolla kuvataan olioiden välistä yhteistyötä, mutta ajan sijaan kuvataan palveluiden kutsujärjestys. Sekvenssikaavio ja yhteistyökaavio ovat rinnakkaisia dynaamisen yhteistyön kuvaustapoja. Sivu - 119 - Muut UML:n kaaviot (jatkuu) Aktiviteettikaavio (activity diagram): Tämä kaavio on UML:n versio tietovuo- ja lohkokaavioista. Kaavio kuvaa tapahtumat ja niiden järjestyksen, mutta ei kerro tapahtumien tekijöitä. Kaavioihin on mahdollista lisätä alkutila, lopputiloja ja ehtoja. Komponenttikaavio (component diagram): Tällä kaaviolla kuvataan fyysisiä ohjelmistokomponentteja, eli yleensä tiedostoja. Kaavio kuvaa komponentit ja niiden väliset suhteet. Sijoituskaavio (deployment diagram): Kaavio näyttää laitteiston ja ohjelmiston fyysisen arkkitehtuurin. Tämä on UML:n työkalu järjestelmäsuunnitteluun, mitä voidaan käyttää luokkakaavioiden ja tietovuokaavioiden sijaan tai rinnalla. Ylläolevia UML:n kaavioita ei käsitellä sen enempää. Lohkokaavioista puhutaan testauksen yhteydessä. Sivu - 120-16