Tietojärjestelmän suunnitteluteorian soveltuvuus projektin estimointi- ja mittaustyökalun kehittämiseen design-science näkökulmasta
|
|
- Siiri Parviainen
- 8 vuotta sitten
- Katselukertoja:
Transkriptio
1 Timo Kaipiainen Tietojärjestelmän suunnitteluteorian soveltuvuus projektin estimointi- ja mittaustyökalun kehittämiseen design-science näkökulmasta Tietojärjestelmätieteen kandidaatin tutkielma Jyväskylän yliopisto Tietojenkäsittelytieteiden laitos Jyväskylä
2 TIIVISTELMÄ Kaipiainen, Timo Allan Tietojärjestelmän suunnitteluteorian soveltuvuus projektin estimointi- ja mittaustyökalun kehittämiseen design-science näkökulmasta Jyväskylä: Jyväskylän yliopisto, s. Projektin estimointi- ja mittaus (PEM, Project Estimation and Measurement) on ilmiönä tutkijoita kiinnostava ala, koska ohjelmistoprojektien myöhästyminen ja budjetin ylittyminen aiheuttaa ongelmia organisaation sisällä. Kuten (Matikainen, 2006) toteaa, on näiden hallintatyökalujen (PEMT, Project Estimation and Measurement Tools) tutkimus jäänyt vähemmälle. Vaikka kaupallisia sovelluksia on tarjolla useita erilaisia ja eritasoisia, nämä eroavat huomattavasti toisistaan esimerkiksi toiminnallisuuksien ja hyödyllisyyden osalta (Matikainen, 2006). Tämä aiheuttaa organisaatioissa epätietoisuutta siitä, millainen työkalu olisi sopiva heidän tarpeisiinsa. Tutkielman tarkoituksena on esitellä tietojärjestelmä tuetun projektin estimoinnin ja mittauksen menetelmiä lähinnä FiSMAssa kehitetyn konseptin, sekä Matikaisen Pro-gradu tutkielmassa (Matikainen, 2006) esitettyjen metavaatimusten ja tuotteensuunnittelu hypoteesien pohjalta. AVAINSANAT estimointi, mittaus, projektinhallinta suunnitteluteoria, ISDT, PEM, PEMT
3 SISÄLLYSLUETTELO 1 JOHDANTO Ohjelmistoprojektin estimointi Tutkimusongelma TIETOJÄRJESTELMIEN SUUNNITTELUKEHYS (ISRF) JA TIETOJÄRJESTELMÄN SUUNNITTELUTEORIA (ISDT) Tietojärjestelmien suunnittelukehys (ISRF) Tietojärjestelmien suunnitteluteoria (ISDT) Design-science Behavioral-science Dual information systems Emergent knowledge processes (EKP s) OHJELMISTOPROJEKTIN ESTIMOINTI- JA MITTAUSTYÖKALUT FiSMAn konsepti organisaation oppimiseen ja prosessien parantamiseen TUOTTEEN SUUNNITTELUHYPOTEESIT PROJEKTIN ESTIMOINTI JA MITTAUSTYÖKALULLE Tuotteensuunnittelu hypoteesit Toimintopisteet Tilanne analyysi Uudelleenkäyttö analyysi Tuottoaste Vertailututkimus (Benchmarking) Projektin estimointi- ja mittaustyökalun tunnistaminen (DPEMT) Tuotehypoteesien yhteenveto JOHTOPÄÄTÖKSET JA YHTEENVETO Organisaation tarpeet ja niiden huomioonottaminen Yleisiä ongelmia ja näiden välttäminen LÄHDELUETTELO... 30
4 1 JOHDANTO Ohjelmistoprojektien ongelmana on jo pitkään tunnustettu olevan myöhästymiset ja budjetin ylittyminen. Olennainen tekijä näiden välttämiseksi on projektin ennalta tapahtuva estimointi. Johtuen ohjelmien abstraktista luonteesta, on estimointi kuitenkin erittäin vaativa tehtävä, joka edellyttää järjestelmällistä tilanteen läpikäymistä, kokemusta ja hyvien työvälineiden tarjoamaa tukea. Työvälineiden on pystyttävä tarjoamaan selkeä kuva sen tuottamista tiedoista, niin että niitä voidaan käyttää projektinjohdon tukena (Kitchenham;Pickard;MacDonell;& Shepperd, 2001) Finish software measurement association (FiSMA ry) on suomalainen järjestö joka keskittyy ohjelmisto-, järjestelmä- ja palveluprojektien ja prosessien mittaamiseen ja niihin liittyvien standardien soveltamiseen ja kehittämiseen (FiSMA 2008)(FiSMA, 2008). FiSMAn jäseninä on lukuisia suuria ohjelmisto ja it-palvelutaloja sekä oppilaitoksia. Pro-gradu tutkielmassa Information system supported project estimation and measurement (Matikainen, 2006) esittää osittaisen tietojärjestelmän suunnitteluteorian (ISDT, Information system design theory) projektin estimointi- ja mittaustyökalua (PEMT, Project estimation and measurement tool) varten. Tässä kuvataan tietojärjestelmän suunnitteluteorian ja tietojärjestelmän suunnittelukehyksen (ISRF) välinen yhteys. Suunnitteluteoria on myös yhteensopiva Dual information system (DIS) mallin kansa, Dis-mallin ohjaamana on mahdollista rakentaa joustavia ja tehokkaita tietojärjestelmiä, jotka tukevat liiketoimintaprosesseja sekä niiden kehittämistä, vaikkei yhdelläkään sidosryhmällä olisi täydellistä tietämystä kaikista projektin estimointi- ja mittaustyökalun rakentamiseen vaadittavista osa-alueista. 1.1 Ohjelmistoprojektin estimointi Yleisesti käytettyjä ja hyväksyttyjä tapoja ohjelmistoprojektien estimoinnissa ovat toimintopisteiden (Function Point) laskeminen, minkä perustana ovat vaatimusmäärittelyt. Sekä tuottoaste (Delivery rate), jonka määritelmänä
5 5 pidetään tyypillisesti kuinka paljon aikaa yhden toimintopisteen tuottamiseen kuluu (h/fp). Myös projektikohtaiset tekijä, jotka vaikuttavat tuottavuuteen, pyritään ottamaan huomioon edellä mainitun lisäksi. Uudelleenkäytöllä ja uudelleenkäytettävyysmetodeilla on myös huomattava vaikutus ohjelmistoprojektin työmäärän arviointiin. Projektin estimointi ja mittaaminen on siis hyvin kriittinen tekijä realistisen aikataulun ja budjetin laadinnan kannalta, joka koostuu seuraavista edellä mainituista osioista: Funktionaalisesta koon määrittämisestä (Functional size measurement) Tuottoasteen arvioinnista (Delivery rate determination) Tilanne analyysista (Situation analysis) Uudelleenkäytön vaikutusten arviointi (Reuse analysis) Johtuen ohjelmistojen abstraktista rakenteesta ja muokattavuudesta, ohjelmistoprojektien vaatimukset voivat muuttua huomattavasti projektin aikana jolloin tarvitaan toimivaa projektin laajuuden-hallintaa (scopemanagement). Ohjelmistoprojektien mittaamisen tulisi olla standardoitua, jotta tiedot olisivat vertailtavissa niin eri projektien, kuin eri organisaatioiden ja yritysten välillä. Tästä johtuen projektin historiatiedon tallennus on tärkeä osa projektin estimointia ja mittausta (PEM), sekä olennainen osa projektin estimointi- ja mittaustyökalun ominaisuuksia. Historiatietokantaa voidaan käyttää kahteen tarkoitukseen, joko toimitusajan määrittämiseen tai prosessien parantamiseen. Prosessien vertailututkimuksessa pyritään kokemustietokannasta vertaamaan tietoja käynnissä olevaan projektiin ja näin parantamaan ohjelmistonkehitysprosessia. Esimerkkinä kokemustietokannoista voidaan mainita esimerkiksi FiSMA ry:n kehittämä Experience sekä ISBGin CDR10 -tietokanta. Matikaisen (2006) mukaan projektin estimointi ja mittausprosesseja voidaan parantaa erilaisten tietojärjestelmien avulla. Nämä työkalut jakaantuvat viiteen
6 6 eri kategoriaan: Projektin koon laskeminen Uudelleenkäytön vaikutus Tietoisuus tuottoasteesta Tilanneanalyysi Vertailututkimus Monet markkinoilla olevista työkaluista tukevat ainakin kahta näistä kategorioista, osa kaikkia viittä. Työkalun olisi kuitenkin pystyttävä vastaamaan mahdollisimman kokonaisvaltaisesti projektin mittaus- ja estimointi tarpeisiin ottaen huomioon organisaation erityisvaatimukset. 1.2 Tutkimusongelma Tämän tutkielman tarkoituksena on luoda kokonaiskatsaus Matikaisen (2006) esittämään osittaiseen tietojärjestelmien suunnitteluteoriaan (ISDT) projektin estimointi ja mittaustyökalua varten (PEMT). Useissa organisaatioissa on koettu tarpeita vastaavaan projektien estimointi- ja mittaustyökalun hankkimisen ja käyttöönoton olevan yleensä hyvin hankalaa, johtuen työkalujen ominaisuuksien erilaisuudesta sekä käyttötarkoituksista. Ongelmaksi voi myös muodostua työkaluista saatavan hyödyn välittömän näkyvyyden puuttuminen, jolloin näiden käyttöönotto herkästi tuomitaan epäonnistuneiksi. Projektin mittaus- ja estimointityökalun tulisi toimia läpinäkyvänä ja joustavana apuvälineenä ohjelmistoprojektien hallinnassa. Jotta työkalun käyttö olisi mahdollisimman tehokasta on sen käyttäjät sitoutettava ja koulutettava sen käyttöön. Ongelmaksi estimointi- ja mittaustyökalun käyttöönotossa koetaan tai saatetaan kokea myös kouluttautumisen ja omien projektien historiatietojen keräämisen aiheuttama resurssitarve. Hyvän työkalun tulisi siis olla helposti käytettävä sekä sen omaksuminen organisaatioon olisi tehtävä mahdollisimman helpoksi. Voidaan olettaa että hyvin moni hallintatyökalu lisää varsinaista
7 7 työmäärää projektinhallinnassa eikä alkuperäisen tarkoituksensa mukaisesti vähennä sitä. Tämä voi olla yksi tekijä miksi uusien työkalujen käyttöönotossa esiintyy ongelmia.
8 8 2 TIETOJÄRJESTELMIEN SUUNNITTELUKEHYS (ISRF) JA TIETOJÄRJESTELMÄN SUUNNITTELUTEORIA (ISDT) Sekä tietojärjestelmän suunnittelukehys (ISRF, Information system research framework) että suunnitteluteoria (ISDT, Information system design theory) pohjautuvat molemmat suunnitteluteorian konseptiin, minkä tarkoituksena on tuottaa entistä tehokkaampia ja tuottavampia tietojärjestelmiä. Tietojärjestelmän suunnitteluteorian (ISDT) päämääränä on rakentaa tietojärjestelmäartefakti määrittelemällä kernel-teoria, meta-vaatimukset, metasuunnittelu ja validoimalla artefakti nk. tuotteensuunnittelu hypoteeseilla. Puolestaan suunnittelukehys (ISRF) on jakaantunut behavioral- (ks. vasen KUVIO 1) ja design-scienceen (ks. oikea KUVIO1). 2.1 Tietojärjestelmien suunnittelukehys (ISRF) Hevner ym. (2004) esittävät kehyksen auttamaan tietojärjestelmien tutkimuksen ymmärtämistä, toteuttamista ja arviointia. Kehys jakaantuu desing-science ja behavioral science osioihin ympäristön mukaan (Knowledge base Environment). (Hevner;March;Park;& Ram, 2004) mukaan ympäristö määrittää ongelma-alueen. Tietojärjestelmien suunnittelussa tämä koostuu ihmisistä, organisaatioista ja olemassa olevista tai tulevista teknologioista. Matikainen (2006) esittää, että liiketoimintatarpeet arvioidaan organisaation strategian, rakenteen, kulttuurin sekä olemassa olevien liiketoiminta prosessien kontekstissa. Tietojärjestelmien suunnittelu on jakautunut suunnittelukehyksen mukaan kahteen toisiaan täydentävään osaan: design- ja behavioral scienceen, jotka erottuvat (ks. KUVIO 1) Knowledge base (design science) ja Environment (behavioral science) osioissa. Desing-science paradigman avulla luodut artefaktit voidaan testata behavioral science paradigmalla. Molemmat käyttävät samoja metodeja, myös design sciencessä voidaan käyttää empiirisiä menetelmiä, mutta ei niin kattavasti kuin behavioral sciencessä.
9 9 Edellä mainittu tietojärjestelmien suunnittelukehyksen tietämyspohja tuottaa materiaalia liiketoimintatarpeisiin tietojärjestelmä tutkimuksessa. Tietämyspohjaa ja toimintaympäristöä käytetään meta-vaatimusten ja metasuunnittelun toteuttamiseen. Liiketoimintatarpeet puolestaan määrittelevät meta-vaatimukset, jonka jälkeen meta-suunnitelma voidaan rakentaa edellä määriteltyjen meta-vaatimusten pohjalta. KUVIO 1 Information System research framework (Hevner;March;Park;& Ram, 2004) 2.2 Tietojärjestelmien suunnitteluteoria (ISDT) Tietojärjestelmien suunnitteluteorian tarkoituksena on ohjata tietojärjestelmäartefaktien luomista. Nämä artefaktit käsittävät kaikki tietojärjestelmien kehityksessä syntyvät objektit, kuten lähdekoodin, sen sisältämät moduulit, luokat, dokumentaation ym. Termillä artefakti tarkoitetaan tässä yhteydessä erityisesti nk. IT-artefaktia, minkä Walls ym. (2004) määrittelevät seuraavasti tarkentaen vuoden 1992 määritelmäänsä;
10 10 Artefakti on objekti, ja suunnittelun lopputulos, tässä tapauksessa suunnitteluteorian tuottama objekti. Suunnitteluteorian tavoitteena on siis kuvailla IT-artefaktin ominaisuudet sekä metodit, jotta artefakti voidaan rakentaa. Lisäksi suunnitteluteoria parantaa sekä lopputuotteen laatua että prosessien suunnitelmallisuutta. Koska suunnitelmallisuus voidaan ymmärtää sekä verbinä, että adjektiivina, on myös suunnitteluteorian huomioitava nämä kaksi aspektia. Verbillä tarkoitetaan suunnittelua ja substantiivi puolestaan suunnittelun prosessin lopputulosta (artefaktia). Lopputuloksena syntyvä artefakti vastaa määriteltyihin liiketoimintatarpeisiin, joten suunnitteluteorialla on oltava testattavissa olevia hypoteeseja. Eräs esimerkki näiden testaamiseksi luoduista menetelmistä on Matikainen (2006) esittämät tuotteensuunnittelu hypoteesit, joiden validoimiseen ja testaamiseen palataan luvussa neljä. Kuten (Salo & Käkölä, 2005) toteavat tutkimuksessaan Nokia Oyj:n organisaatiolle, ovat tämän päivän vaatimukset ja paineet tuoda tuotteita markkinoille entistä nopeammin kasvaneet. Jotta yritys pystyisi säilyttämään ja kasvattamaan toimintaansa ja sen kannattavuutta on pystyttävä jatkuvasti etsimään uusia ja entistä kustannustehokkaampia tapoja toteuttaa ohjelmistoja, kuitenkaan laadun kärsimättä. Tässä tilanteessa voidaan myös ottaa avuksi projektin estimointi- ja mittaustyökalu mikä on suunniteltu suunnitteluteorian pohjalta.
11 11 KUVIO 2 Tietojärjestelmän suunnitteluteorian komponentit Tuotteen suunnitteluteorian lähtökohtana ovat meta-vaatimukset, jotka käsittävät niiden tavoitteiden joukon johon teorian on vastattava. Koska suunnitteluteoria ei vastaa vain yhteen ongelmaan vaan laajempaan kokonaisuuteen on syytä puhua joukosta. Meta-suunnittelu puolestaan pyrkii täyttämään meta-vaatimuksissa asetetut tavoitteet artefaktien avulla. Kolmas komponentti tuotteensuunnittelussa on ns. kernel-teoriat, jotka kattavat suunnitteluvaatimukset luonnon- tai yhteiskuntatieteen pohjalta. Kernel-teoriat toimivat lähtökohtina tietojärjestelmän suunnitteluteorian komponenttien välisissä yhteyksissä (ks. KUVIO 2). Lopputuloksena syntyneen artefaktin soveltuvuutta täyttämään meta-suunnitelman vaatimukset voidaan testata ns. tuotehypoteeseilla, joilla konkreettisesti todennetaan teorian toimivuus. (ks. luku 4) Varsinaisen artefaktin rakentamisen suunnitteluprosessin kattamiseksi on esitetty vastaavanlainen kolmiportainen järjestelmä kuin edellä kuvailtuun tuotteensuunnitteluun. Suunnittelu metodin tarkoituksena on kuvata
12 12 tarvittavat toimenpiteet halutunlaisen artefaktin luomiseksi, sitä puolestaan täydennetään kernelteorioiden luonnon- ja yhteiskuntatieteellisellä pohjalla, kuten em. tuotteensuunnittelussakin. Myös suunnitteluprosessin teorioita voidaan ja tulee testata, joten tämän toteuttamiseksi voidaan luoda hypoteeseja suunnitteluprosessia varten joilla voidaan todentaa, että suunnitteluprosessi ja sen suunnittelumetodi tuottaa meta-suunnittelussa määritellyn artefaktin. 2.3 Design-science Seuraavassa esitetään Hevner ym. (2004) määritelmä tietojärjestelmien tutkimuskehykselle sekä design- ja behavioral sciencen erot. Tietojärjestelmien tarkoituksena organisaatioissa on useimmiten parantaa tehokkuutta ja tuottavuutta. Tavoitteiden saavuttamiseen vaikuttavat niin itse tietojärjestelmä, organisaation piirteet, työtavat, kehitys kuin näiden implementointimetodit yhdessä. Tiedon hankkimiseksi näistä on erotettavissa, Hevner ym. (2004) mukaan kaksi erilaista paradigmaa; behavioral science ja design science näkökulmat. Desing-sciencellä lähestymistapa on ongelmanratkaisukeskeinen ja insinööritieteellinen. Design-science pyrkii luomaan innovaatioita jotka määrittelevät ideoita, käytänteitä, teknisiä mahdollisuuksia ja tuotteita joiden avulla analysointi, suunnittelu, toteutus, hallinta ja tietojärjestelmien käyttö voidaan suorittaa. Design-science on siis pohjimmiltaan ongelmanratkaisuprosessi. Tätä prosessia ohjaamaan on kehitetty (Hevner ym. 2004) seitsemänosainen ohjenuora, joka on esitetty seuraavassa: 1. Suunnittele artefakti 2. Ymmärrä ongelman merkitys 3. Tee suunnitelman arviointi 4. Tutkimuksen panos 5. Muista tutkimuksen kurinalaisuus 6. Tee suunnitelma etsimis prosessina 7. Muista tutkimuksen kommunikointi
13 13 Näistä erityisesti viimeinen kohta on erityisen tärkeä, koska ilman kaikkien sidosryhmien ymmärtämistä, toimii prosessi vain osittain, tai ei ollenkaan. 2.4 Behavioral-science Behavioral science keskittyy enemmän organisaation ja inhimillisen käytöksen selittämiseen analyysin, suunnitteluun sekä toteuttamiseen johtamis- ja tietojärjestelmien käytössä. Behavioral-science toimii tärkeänä palautemekanismina tietojärjestelmien suunnittelukehyksessä (ISRF) syöttäen tietoa reaalimaailman olosuhteista ja vaatimuksista kehitysprosessiin. Tietojärjestelmän suunnitteluteorian tuottaman artefaktin validointi suoritetaan tietojärjestelmien suunnittelukehyksen syklisessä mallissa. 2.5 Dual information systems Dual information systems (DIS) mallin hyödyntäminen projektin estimointi- ja mittaustyökalun rakentamisessa on aiheellista kun eri osapuolet (engl. Agents) eivät ymmärrä kaikkia tekijöitä mm. vertailututkimuksesta (Matikainen 2006). Koska DIS malli keskittyy osapuolten oppimisen ja työskentelyn tallentamiseen, on huomioitava että yhteyksiä voidaan löytää myös PEMT työkalun suunnitteluteorian sekä DIS mallin suunnitteluteorian välillä. 2.6 Emergent knowledge processes (EKP s) Eräänä suunnitteluteoriaan liittyvänä lisäkohtana voidaan mainita lyhyesti nk. Emergent knowledge processes. Kuten edellä on todettu, projektin estimointija mittaustyökalun toimintaolosuhteet voivat olla hyvinkin erilaiset riippuen organisaatiosta, joten yksilöidyn työkalun rakentaminen on jokaisella kerralla ainutkertainen prosessi. Emergent knowledge process tarkoittaa prosesseja (Markusym. 2002), joiden tarkoituksena on auttaa tietämyksen kehittymistä organisaatioissa uusien asioiden ja käytänteiden suhteen.
14 14 3 OHJELMISTOPROJEKTIN ESTIMOINTI- JA MITTAUSTYÖKALUT Kuten johdannossa on todettu, ohjelmisto projektien estimointiin ja mittaukseen on kehitetty runsaasti työkaluja (kuten esimerkiksi Microsoft project) joiden menetelmät ja sisältö vaihtelevat suuresti. Tässä tutkielmassa keskitytään FiSMAn kehittämään konseptiin. Olennainen tekijä mittaustyökalun toiminnassa ja sen antamien estimaattien tarkkuudessa on käytettävissä oleva historiatieto edellisistä projekteista. FiSMAn kehittämässä järjestelmässä tämä historiatieto on tallennettuna Experience tietokantaan. Kuten Käkölä ym. (Käkölä;Wu;Yalaho;& Nahar, 2006) toteavat, ohjelmistoteollisuuden kansainvälistyessä on myös tämän asettamat vaatimukset otettava huomioon työkalujen suunnittelussa. Perinteisien sähköpostin ym. Lisäksi kommunikoinnissa esimerkiksi eri toimipisteiden välillä voidaan käyttää erilaisia video-neuvottelu sovelluksia, jotka täydentävät omalta osaltaan projektin kokonaisvaltaista hallintaa estimointi- ja mittaustyökalun lisäksi. Luvussa 3.1 kerrotaan pääpiirteet FiSMAn konseptista ja sen sisältämistä Organisationaalisen oppimisen konsepteista, Fisman aktoreista, Projektin työmäärän estimoinnin, Projektin estimointi ja mittaus prosessin ja Fisman mittausmetodit. Matikaisen (2006) Pro-gradu työssä näiden pohjalta on määritelty meta-vaatimukset projektin estimointi ja mittaustyökalulle. 3.1 FiSMAn konsepti organisaation oppimiseen ja prosessien parantamiseen Fisman kehittämä konsepti organisaation oppimiseen ja prosessien parantamiseen käsittää seuraavat osapuolet projektin estimoinnissa ja mittauksessa ohjelmiston tuottajan puolella: Ylempi johto, projektitoimisto sekä projektin johto. Tässä luvussa käydään seikkaperäisesti lävitse Matikaisen (2006) identifioimat FiSMAn menetelmien tuottamat metavaatimukset projektin mittaus- ja estimointityökalulle.
15 15 Kaikkien PEMT-artefaktien tulee tukea verkoston rakentamista tiedon keruuta varten projekteista, sekä pystyä jakamaan kokemustietokannasta uusia versioita. Oleellinen osa FiSMAn menetelmää on työmäärän laskeminen jota työkalun on tuettava seuraavin osin: Toiminnallinen koon mittaaminen, uudelleenkäytön analyysi, tilanne analyysi ja tuottoaste joka pohjautuu kokemustietokannan tietoihin. Työkalun tulee luonnollisesti myös pystyä suorittamaan estimointi ja analyysi em. mainittujen tekijöiden avulla sekä tallentamaan tästä analyysista saadut tiedot kokemustietokantaan. Laajuuden hallintaa (scope management) tukevat Matikaisen (2006) esittämät viisi prosessia työkalun kehittämiseen suunnitteluteorian pohjalta ovat; 1) projektin asettaminen, jota seuraa 2) kustannusten ja keston arviointi sen jälkeen siirrytään itse 3)kehitysvaiheeseen jonka aikana 4) edistymisen valvonta ja muutosten hallinta vuorottelevat. Kehitysprosessin lopussa on vielä 5)kehityksen lopettaminen. Meta-vaatimuksina projektin asettamis prosessille ovat metodien ja mallien valinta, luokittelevien kysymysten esittäminen. KUVIO 3 FiSMA effort esimation process (Matikainen, 2006) Kustannusten ja keston arviointia pidetään usein projektin estimointi- ja mittaustyökalun tärkeimpänä tehtävänä, joten myös FiSMAn konseptissa
16 16 estimointimenetelmien tuelle tälle annetaan verrattain suuri painoarvo. Estimointiprosessi alkaa toiminnallisen koon laskemisella, sen lähteenä ovat vaatimusmäärittelyt, toimintoluettelon pohjalta arvioidaan uudelleenkäytön vaikutukset ja näiden kahden tekijän pohjalta otetaan vielä huomioon tilanne analyysi perustana mm. saatavilla olevat resurssit ja tuotteen ei-toiminnalliset vaatimukset. Viimeisenä estimointiprosessin vaiheena on tuottoasteen päätteleminen kokemustietokannan ja/tai muun ulkoisen historiatietokannan avulla ja tämän tiedon yhdistäminen muihin arvioihin. Muutoksen hallinta on erittäin tärkeää projektissa, joten työkalun tulisi täyttää myös seuraavat meta-vaatimukset: muutoksen hallinta, version hallinta, valmiusasteen arviointi (muutos tilanteissa uudelleenlaskenta) ja lisäksi tukea historiatiedon tallentamista kokemustietokantaan tulevia projekteja varten. Työkalun on selvittävä myös muutosten vaikutusten arvioinnista tai uusien vaatimusten tuomisesta projektiin, pystyä vertailemaan nykyistä ja muutettua versiota projektista sekä tuottamaan näistä asianmukaiset raportit sekä laskemaan uuden version arviosta pohjautuen em. tekijöihin. Projektin lopettaminen on varsinkin asiakkaan kannalta erittäin tärkeä prosessi johon Matikainen (2006) ehdottaa työkalun ominaisuuksiksi mm. Seuraavia asioita: toiminnallisuuksien lukitseminen ja viimeisimmän version määrittelyt, viimeiset tuottavuus ja toimitusajan pituus analyysit sekä loppuraportin tuottaminen.
17 17 4 TUOTTEEN SUUNNITTELUHYPOTEESIT PROJEKTIN ESTIMOINTI JA MITTAUSTYÖKALULLE Jotta suunnitteluteorian toimivuus voitaisiin todentaa, on luotava hypoteeseja ja todistuksia näille hypoteeseille, että suunnitteluteorian noudattaminen todella avustaa tehokkaan projektin estimointi ja mittaus työkalun kehittämisessä. Sekä tutkittava niiden avulla toimisivatko nämä käytännössä. Tässä tutkielmassa käytetään lähtökohtana Matti Matikaisen (2006) luomia tuotteensuunnittelu hypoteeseja. Koska hypoteesien todentaminen todellisessa ympäristössä on erittäin tärkeää, luodaan tässä tutkielmassa perusta hypoteesien toiminnan testaukselle esimerkiksi haastattelututkimuksen avulla. Luvussa myös esitellään ja täydennetään Matikainen (2006) esittämiä tuotteensuunnittelu hypoteeseja, ja pyritään antamaan näin pohja tulevaisuuden validointitutkimukselle. Hypoteesit on seuraavissa kappaleissa purettu osiin ja näiden avulla pyritty avaamaan mahdolliset vuorovaikutus suhteet näiden sisällä. Esitetyt hypoteesit pohjautuvat FiSMAn kehittämiin menetelmiin ja näiden arvioinnissa on käytetty hyväksi FiSMAn tarjoamia artikkeleita ja raportteja. Eräs tuotehypoteesien avulla tässä tutkimuksessa esille noussut asia on laajuudenhallinan (scope management) tarve ohjelmistoprojekteissa, mihin em. Esitetyt tuotetteensunnittelu hypoteesit eivät ota kantaa millään tavalla. Laajuudenhallintaan FiSMA on myös esittänyt oman konseptinsa, uusimpana northernscopekonseptin mikä on esitelty ja otettu käyttöön organisaatioissa kevään ja kesän 2007 aikana ja jonka ensikokemukset ovat olleet lupaavia (FiSMA, 2007) 4.1 Tuotteensuunnittelu hypoteesit Matikainen (2006) jakaa tuotteensuunnittelu hypoteesien ryhmät kuuteen eri kategoriaan, toimintopisteisiin, tilanne analyysiin, uudelleenkäyttö analyysiin, tuottoasteeseen, vertailututkimukseen ja projektin estimointi- ja
18 18 mittaustyökalun tunnistamiseen. Kaikkien näiden hypoteesien noudattamisen tavoitteena on tuottaa artefakti, mikä noudattaa ainakin seuraavia Matikaisen määrittelemiä piirteitä: standardoitu-, tarkka-, jäljitettävä- ja läpinäkyvä prosessi tai käytäntö. Seuraavassa käydään lävitse nämä tuotteen suunnitteluhypoteesit kriittisesti tarkastellen niitä erityisesti design-science näkökulmasta. Hypoteeseista lähes kaikki ovat syklisiä ja tässä tutkielmassa olen pyrkinyt havainnollistamaan hypoteesien sisältöä ja yhteyksiä kaavioilla, joissa on kuvattu artefaktin ominaisuuksia parantavat tekijät + merkillä ja huonontavat - merkillä, lisäksi hypoteesien osien välillä olevat nuolet osoittavat mihin muihin osiin hypoteesia kyseinen ominaisuus vaikuttaa Toimintopisteet Toimintopisteiden (FSM) laskemisella pyritään saavuttamaan yhteneväinen laskutapa ohjelmiston koolle, jonka perusteella voidaan tehdä erilaisia arvioita mm. ohjelmistoprojektin kestosta. Kuten (Tran-Cao;Levesque;& Abran, 2002) toteavat, että toimintopisteiden laskentaan on olemassa perinteisesti kaksi erilaista lähestymistapaa: 1. Koodirivien (LOC) määrä ja 2. erilaisten ominaisuuksien, kuten funktioiden tai metodien määrä ja monimutkaisuus. Näistä koodirivien määrä on yksinkertaisin sekä jälkikäteen tehtynä tarkka, mutta ennalta tehtynä mahdoton arvioitava sekä vaikeasti yleistettävä johtuen esimerkiksi erilaisten ohjelmointikielien syntaksista eroista. Puolestaan ohjelmiston ominaisuuksiin ja toiminteisiin (kohta 2.) nojaava toimintopisteiden laskenta on huomattavasti tarkempi, mut(walls;george R;& Omar A El, 2004)ta vaati myös paljon enemmän paneutumista jokaisen toiminnallisuuteen, sekä määritellyn tavan laskea tietyn monimutkaisuuden omaavien ominaisuuksien toimintopistemäärä. Esimerkiksi FiSMA:n kehittämä FSM metodi pohjaa jälkimmäisenä mainittuun menetelmään (FiSMA, 2006) ja sillä on saatu erinomaisia tuloksia osassa sitä käyttäneissä organisaatioissa. Toimintopisteisiin perustuva projektin koon arviointi vaikuttaa positiivisesti projektin dokumentaatioon, mahdollistamalla tarkemman
19 19 dokumentaation projektin etenemisestä (KUVIO 4). Projektin toteuttamiseen vaadittavan ajan estimaatit myös tarkentuvat, kun toimintopisteiden avulla määritellään tarkasti kuinka paljon resursseja jokaisen toiminnallisuuden toteuttaminen vie. Puolestaan kun tiedetään tarkemmat arviot toiminnallisuuksien toteuttamiseksi, myös projektin kokonaisvaltainen suunnittelu helpottuu. Tulosten ja projektin tilan seurannan ja valvonnan tehostuminen on seurausta paremmin dokumentoidusta ja hyvin määritellyistä toteutusajoista kullekin toiminnallisuudelle, jolloin tiedetään jatkuvasti projektin tila sekä voidaan puuttua mahdollisiin epäkohtiin ajoissa. Edellä mainitut tekijät puolestaan kokonaisuudessaan lisäävät projektista tehtävien (mm. kesto- ja kustannusestimaattien) estimaattien tarkkuutta (KUVIO 4). Puolestaan kun projektin suoritusarvoja myöhemmin vertaillaan toisiin projekteihin (Benchmarking) hyvin toteutetulla toimintopisteiden määrittelyllä projektissa saadaan vertailutukimusta tarkempia arvioita. Projektin koordinoinnin, eli sen miten projektia kokonaisuudessaan ohjataan. sekä ongelmista toipumiseen kuluvan ajan väheneminen ovat selkeitä etuja, jotka polveutuvat edellä mainituista hypoteesin osista.
20 20 KUVIO 4 Funktionaalisen koon laskennan tuotehypoteesit (Matikainen 2006) Tilanne analyysi Tilanne analyysin tarkoituksena on lisätä aktoreiden tietoisuutta projektin kulusta (mm. resurssien allokoinnista, aikataulun pitävyydestä ja mahdollisista ongelmista) joka auttaa projektinjohtoa tekemään olosuhteita korjaavia toimenpiteitä sekä parantaa projektin dokumentaatiota, jonka kautta myös motivaatio kasvaa (Matikainen 2006). Tässä tutkielmassa tilanneanalyysin hypoteesi pohjaa FiSMAn kehittämään Situation Analysis ND21 metodiin (FiSMA, 2003). Tämä metodi koostuu 21 erilaisesta tuottavuustekijästä, joista jokainen on tasapainotettu kokemustietokannan perusteella. FiSMA:n tilanneanalyysi metodi on pyritty tekemään mahdollisimman helppokäyttöiseksi, ja em. 21 tuottavuustekijää on ryhmitelty neljään eri kategoriaan: Projekti, Prosessi, Tuote ja Ihmiset. Näitä 21 tekijää arvioidaan yksinkertaisella ++,+,+/-,-, asteikolla missä ++ on paras mahdollinen tilanne ja huonoin mahdollinen. Tilanne analyysin pohjalta voidaan esimerkiksi havaita työvoiman riittämättömyys/liiallisuus tai työkalujen sopimattomuus kyseiseen projektiin
21 21 (KUVIO5). Tilanne analyysin tarkoituksena on ennekaikkea toimia ennalta ehkäisevänä ja analyyttisena työkaluna projektin johdolle (Matikainen 2006). KUVIO 5 Tilanneanalyysin tuotehypoteesit (Matikainen 2006) Uudelleenkäyttö analyysi Ohjelmistojen kehityksessä komponenttien uudelleenkäytöllä voidaan aikaansaada huomattavia säästöjä niin ajankäytössä kuin rahallisestikin (FiSMA, 2002). FiSMA on luonut uudelleenkäytön estimointiin oman metodinsa (FiSMA Reuse Measurement Method, FiSMA RMM version 2002), monet organisaatiot ovat pyrkineet em. syistä nostamaan uudelleenkäytön tasoa, mutta kunnollista uudelleenkäytö estimointi menetelmää ei ole ollut saatavilla. Menetelmä pohjautuu toimintopisteiden sekä neljän toimitettavan osa-alueen (Ohjelmakoodi, testitapaukset, ohjelmiston dokumentaatio ja loppukäyttäjien dokumentaatio) arviointiin esitetyin oletuspainotuksin. Uudelleenkäyttöä suunnitellessa on tärkeää pystyä tiedostamaan mitä hyötyjä ja haittoja uudelleenkäyttö aiheuttaa ohjelmistoprojektille. Ei ole itsestään selvää, että kaikki uudelleenkäyttö vähentäisi esim. resurssitarpeita. Uudelleenkäytön tässä esitetyt tuotehypoteesit auttavat projektin johtoa määrittämään oikean uudelleenkäytön tason sekä valitsemaan oikeat komponentit mitä voidaan uudelleenkäyttöä. Oikein toteutetulla uudelleenkäytöllä projektin työmäärää ja toimitusaikaa voidaan vähentää huomattavasti, tosin epäonnistuessaan tämä voi muuttua päinvastaiseksi (KUVIO 6). Keskustelu ja systemaattinen läpikäynti auttavat maksimoimaan
22 22 hyödyllisen komponenttien käytön. Uusien komponenttien tuottaminen muuttuu myös entistä suunnitelmallisemmaksi (Fan & Leung 2002). KUVIO 6 Uudelleenkäytön tuotehypoteesi (Matikainen 2006) Tuottoaste Tuottoasteella tarkoitetaan aikaa mikä kuluu projektin tietyn osan valmistamiseen, esimerkiksi 10 toimintopistettä kuukaudessa / sovelluskehittäjä. Tässä erityisen tärkeäksi nousevat kaikki aikatauluun vaikuttavat tekijät, kuten henkilöstö resurssien määrä ja saatavuus. Tuottoasteen estimoinnissa esim. tieto henkilöresurseista on olennainen, joten näiden historiatiedon hyödyntäminen estimoinnissa on erittäin olennaista (Matikainen 2006). Tuottoaste voidaan siis ilmaista esimerkiksi työtunneilla / toimintopiste. Tuottoaste on hyvin riippuvainen muista projektin osa-alueista, kuten lopputuotteen vaatimat muutokset luonnollisesti vaikuttavat suoraan tuottoasteeseen, joka on tarpeen mukaan laskettava uudestaan.
23 23 KUVIO 7 Tuottoaste tuotehypoteesi (Matikainen 2006) Vertailututkimus (Benchmarking) Vertailututkimuksen tavoitteena on vertailla projektin suoritusarvoja edellisiin projekteihin ja näin saada palautetta sekä ohjausta projektin johtoon ja estimointiin. Vertailututkimuksen avulla tulevat aika- ja kustannus estimaatit saadaan tarkemmiksi, edellyttäen että historiatietoa on tarpeeksi saatavilla ja että se on hyvin heterogeenistä. Tärkeä osa vertailututkimusta on vertailudatan kerääminen, esimerkiksi ISBSG ja suomalainen FiSMA ovat kehittäneet menetelmiä omien kokemustietokantojensa pohjalle. Vertailututkimuksen avulla voidaan asettaa tavoitteita prosessien parantamiselle, jolla voidaan parantaa yrityksen kilpailukykyä markkinoilla. Vertailtutukimusta on muilla insinööritieteellisillä aloilla käytetty jo pitkään hyväksi projektien keston estimoinnissa, mutta vasta nyt ohjelmistoteollisuus on löytänyt sen tuomat edut (Lokan;Wright;Hill;& Stringer, 2001) Kuten seuraavassa vertailututkimus tuotehypoteesia kuvaavassa kaaviossa (KUVIO8) on esitetty, hyödyn saaminen liittyy kiinteästi varsinaista projektia edeltäviin valmistelutoimiin, mutta vertailtava data on oltava olemassa etukäteen, joko ulkoisista (esimerkiksi FiSMAn Experience-tietokanta) tai sisäisistä lähteistä. Kattavin vertailututkimus voidaan tehdä, kun projekti on loppunut tai loppumassa, jolloin projektin suoritusarvot ovat lopulliset
24 24 KUVIO 8 Vertailututkimus tuotehypoteesi (Matikainen 2006) Projektin estimointi- ja mittaustyökalun tunnistaminen (DPEMT) DPEMT (Dual project estimation and measurement tool) toimii kuten aiemmin on kuvailtu Dual Information Systems-mallin esittelyn yhteydessä, tilanteissa joissa eri sidosryhmien tietoisuus projektin osatekijöistä ei ole täydellistä. Ongelmana ohjelmistoprojekteissa on usein eri sidosryhmien väliset ymmärtämys ja kommunikaatioerot (Keung;Jeffery;& Kitchenham, 2004) Erityisesti projektien jakaantuessa entistä laajemmalle niin tietämyksellisesti kuin maantieteellisestikin, erilaisten ryhmien edustajien tieto esimerkiksi teknisistä ratkaisuista voi olla hyvin pientä, tai sitä ei ole ollenkaan. Hypoteesin pohjalta suunniteltu artefakti lisää projektin koon ja keston estimaattien tarkkuutta, jolloin myös sidosryhmien ja aktoreiden tietoisuus projektin kulusta ja tilasta kasvaa. Kun puolestaan sidosryhmät ovat tietoisia projektin kulusta voidaan myös dokumentaatiota rakentaa vastaamaan heidän nykyisiä ja tulevia tarpeitaan vastaavaksi. Kun projektin estimaatit ovat tarkkoja, ja dokumentaatio on hallittu oikein on myös ongelmista toipumiseen kuluva aika lyhyempi. DPEMT-työkalulla koko hypoteesin tarkoituksena on olla itseään iteraatio toisensa jälkeen parantava, jolloin viimeisenä kohtana on estimaattien tarkentuminen.
25 25 KUVIO 9 DPEMT tuotehypoteesi (Matikainen 2006) 4.2 Tuotehypoteesien yhteenveto Näiden edellä mainittujen hypoteesien avulla voidaan validoida Matikainen (2006) esittämän osittaisen suunnitteluteoria projektin estimointi- ja mittaustyökalulle. Keskeisimpinä hypoteeseina pitäisin Toimintopiste-, ja vertailututkimus hypoteeseja joiden merkitys projektin estimoinnille ja mittaamiselle on erittäin suuri ja perustavanlaatuinen. Edellä mainitut tuotteensuunnitteluhypoteesit ovat suunniteltu validoimaan osittaista (Matikainen 2006) esittämää suunnitteluteoriaa, näiden täydentäminen vastaamaan paremmin organisaatioiden tarpeita on hyvin tärkeää (Keung ym.2004). Koska tietojärjestelmien kehittäminen on usein useiden erilaisten sidosryhmien yhteistyönä tapahtuva iteratiivinen prosessi, asettaa tämä kovat vaatimukset artefakteille, joiden on otettava huomioon eri projekteissa hyvinkin erilaiset ympäristöt. Olennaisinta kaikissa hypoteeseissa on sisällyttää historiatiedon tallentaminen osaksi prosessia, jolloin voidaan työkalun käytön myötä kasvattaa myös estimaattien kannalta ensiarvoisen tärkeää historiatiedon määrää. DPEMT-työkalu ja menetelmä soveltuu em. kaltaisiin projekteihin, joissa kaikilla osapuolilla ei ole täydellisiä tietoja projektin vaatimuksista, jolloin työkalulla voidaan luoda jatkuvasti itseään tarkentava estimointi malli.
26 26 5 JOHTOPÄÄTÖKSET JA YHTEENVETO Tietojärjestelmän suunnitteluteorian soveltaminen organisaation tarpeisiin projektinestimointi ja mittaustyökalun suunnittelussa on erittäin tärkeää toimivan työkalun aikaansaamiseksi. Ohjelmistoprojektin estimointi on myös monimutkainen prosessi ja muuttujia on paljon, joten täysin pitävän arvion saaminen on tällä tietämyksellä harvinaista. Kuitenkin suunnitteluteorian pohjalta luodulla estimointityökalulla voidaan saavuttaa huomattavia parannuksia estimaattien tarkkuudessa, ja näin aikaansaada huomattavia parannuksia mm. projektien läpimenoajoissa. Tämä täsmällisyys luonnollisesti heijastuu asiakkaiden luottamuksena organisaatioon tai yritykseen luotettava toimittajana ja näin takaa myös tulevaisuuden liiketoiminnan jatkuvuuden. Walls ym. (2004) esittävät, että suunnitteluteorian käyttö voidaan organisaatioissa jakaa neljälle tasolle, riippuen siitä kuinka pitkälle käyttö on viety. Ensimmäisellä tasolla suunnitteluteorian käyttö on hyvin pinnallista ja siihen viitataan vain sopivuuden kannalta. Toisella tasolla puolestaan soveltaminen on viety pidemmälle, ja suunnitteluteoriaa käytetään kehyksenä ja yhteisenä kielenä mm. meta-vaatimusten määrittelyssä uudelle luokalle. Kolmannella tasolla suunnitteluteorian soveltaminen on viety jo suhteellisen pitkälle, jolloin teorian avulla pystytään jo luomaan uusia näkemyksiä kehitettävien luokkien sisällä, jolla pystytään löytämään aivan uusia näkökulmia mitä ei muilla menetelmillä olisi muuten löydetty. Ylimmällä neljännellä tasolla suunnitteluteoria kehittää itseään jatkuvasti saamalla palautetta työskentelyn alla olevista luokista ja järjestelmistä, näin myös itse teoria on jatkuvan kehityksen kohteena. Tähän sisältyykin myös tämän tutkimukseni ongelma, suurin osa organisaatioista on suunnitteluteorian hyödyntämisessä tasoilla yksi tai kaksi, harvat tasolla kolme. Hevner ym. (2004) mukaan tasolle neljä ei todistetusti ole vielä päässyt yksikään organisaatio. Kappaleissa 5.1 ja 5.2 esitetään menetelmiä näiden ongelmien löytämiseksi ja
27 27 suunnitteluteorian ongelmakohtien verifioimiseksi käytännön projektinhallinta ja estimointityökalun toteutuksessa. Kuten edellä on todettu on organisaatioiden pääseminen ylemmille tasoille suunnitteluteorian hyödyntämisessä hyvin harvinaista, jopa mahdotonta, joten (Walls;George R;& Omar A El, 2004) esittävät neljä strategiaa joiden avulla voidaan mahdollisesti saavuttaa parempia tuloksia. 5.1 Organisaation tarpeet ja niiden huomioonottaminen Ohjelmistoprojektin laajuuden hallinta vaati lähes poikkeuksetta työkaluja. Mutta kuten edellä on todettu, eri työkalut soveltuvat hyvin vaihtelevasti organisaatioiden tarpeisiin ja tarve yksilöityyn ratkaisuun tai työkalujen yhdistelyyn on monessa organisaatiossa ilmeinen. Kuitenkaan ei kaikkien organisaatioiden tapauksissa voida edes olettaa että yksilöity työkalu olisi tarpeellinen tai taloudellisesti kannattava, vaan nk. hyllytuotteena löytyviä järjestelmiä voidaan myös käyttää hyväksi. 5.2 Yleisiä ongelmia ja näiden välttäminen (Walls;George R;& Omar A El, 2004) esittämät strategiat suunnitteluteorian paremman hyödyntämisen edesauttamiseksi ovat seuraavat: 1. Yleinen suunnitteluteorian parantaminen käytännön esimerkkien kautta. Suunnitteluteorian erilaisten komponenttien yhdistäminen ei välttämättä ole lukijalle tai kuulijalle helppoa. Tätä tulisi myös harrastaa projektin laajuudenhallinta työkaluille kehitettävässä suunnitteluteoriassa, jolloin organisaation johto ja muut sidosryhmät ymmärtäisivät siitä saatavan hyödyn, kehittäjien ja tutkijoiden lisäksi. 2. Työkalu strategiat, jotka käsittävät digitaalisessa muodossa olevan dokumentaation, esimerkkejä ja pohjia suunnitteluteorian hyödyntämisen tueksi.
28 28 3. Suunnitteluteorian rakenteen tarkentaminen jatkuvasti tutkimalla suunnitteluteoriaa ja jalostamalla sitä eteenpäin muuttuvien vaatimusten ym. mukana. (Walls;George R;& Omar A El, 2004) esittämä tekijä tämän kohdalla on, että suunnitteluteoria ei juurikaan auta ohjaamaan kernel-teorioiden tunnistamisessa, joten jatkuva teorian tarkastaminen ja jalostaminen on tarpeellista. 4. kohtana (Walls;George R;& Omar A El, 2004) mainitsee tarpeen levittää tietoa (nk. ISDT evankelismi) suunnitteluteorian käytöstä ja soveltamisesta niin akateemisessa kuin yritysmaailmassakin. Ongelmakohdiksi tässä tutkimuksessa tietojärjestelmien suunnitteluteorian implementoinnissa käytäntöön on identifioitu seuraavat asiat: 1. Tuloksien välitön näkyvyys 2. Referenssien puute ja/tai vähäisyys 3. Pitkäjänteisyyden puute käyttöönotossa 4. Tietämättömyys suunnitteluteorian hyödyntämisestä Tuloksien näkyvyyden lisäämiseksi vaaditaan organisaatioissa pitkäjänteisyyttä ja työkaluilta puolestaan nopeampaa ja välittömämpää näkymistä organisaation prosesseissa. Myös referenssien puute (kohta 2) saattaa haitata varsinkin suunnitteluteoriaan pohjautuvan estimointityökalun käyttöönoton aloittamista, koska esim. johdolle ei ole esittää menetelmien konkreettista toimivuutta. Tämän korjaamiseksi on akateemisessa tutkimuksessa pyrittävä tuomaan esille onnistuneita referenssejä joiden avulla voidaan vakuuttaa eri sidosryhmät menetelmien toimivuudesta. Luonnollisesti näiden referenssien on oltava luotettavia. Pitkäjänteisyyden puutteeseen käyttöönotossa voidaan vaikuttaa luomalla työkalu, jolla tulokset näkyvät nopeammin sekä organisaation sisällä antamalla työkalulle aikaa vaikuttaa prosesseihin. Koska tietojärjestelmien suunnitteluteoriaan pohjautuvan projektin estimointi ja mittaustyökalun tutkimus ja kehitys on ollut hyvin vähäistä on myös tietämys organisaatiossa tästä hyvinkin heikkoa, jolloin ei
29 29 osata edes vaatia em. asioita. Tätä voidaan parantaa lisäämällä tietoisuutta suunnitteluteorian eduista estimointityökalun rakentamisessa(walls;george R;& Omar A El, 2004)). Jotta edellä mainittuihin suunnitteluteorian soveltamisen ongelmakohtiin voitaisiin perehtyä tarkemmin, on tämän tutkielman pohjalta esitetty kyselytutkimuksen runko, jossa käsitellään käytännönläheisemmin soveltamiseen liittyviä ongelmia lähinnä Matikainen (2006) esittämien tuotteensuunnittelu hypoteesien avulla. Koska esimerkiksi suomalaisen FiSMAn kehittämän menetelmän ja järjestelmän avulla on saavutettu huomattavia parannuksia projektinhallinnassa pienessä osassa organisaatioita, olisi erityisen tärkeää saada tietoa siitä, mitkä ovat kriittiset kohdat suunnitteluteorian soveltamisessa ohjelmistoprojektinhallintatyökalun suunnittelussa ja ennen kaikkea käyttöönotossa, joka tämän tutkielman pohjalta on ilmennyt suurimmaksi esteeksi hyödyntämiselle. Toisaalta ohjelmistoprojektin estimointi ja mittaus on erittäin laaja käsite, jonka takia pelkällä mittaustyökalulla ei saada tarkimpia mahdollisia estimaatteja, vaan on myös osattava hyödyntää asiantuntija tietoa. Tutkielman johtopäätöksenä voidaan todeta, että suunnitteluteorian avulla voidaan siis tuottaa erittäin toimiva projektin estimointi- ja mittaustyökalu ohjelmistoprojektien hallintaan esimerkiksi FiSMA ry:n tarjoamien menetelmien pohjalta kehitys on tulevaisuudessa mahdollista laajemmassa mittakaavassa. Ennen kaikkea näen tärkeänä työkalun suunnittelussa organisaation tarpeiden kartoituksen ennen työkalun rakentamista, jolloin pystytään helpommin soveltamaan tietoa itse suunnitteluteorian malleihin.
30 30 LÄHDELUETTELO FiSMA. (2003). Experience ND21 Situation Analysis Model. FiSMA. FiSMA. FiSMA. (2006). FiSMA 1.1 PAS Submission. FiSMA. FiSMA. FiSMA. (2002). FiSMA Reuse Measurement Method. FiSMA ry. FiSMA. FiSMA. (2008, 3 16). Retrieved 3 16, 2008, from Fisma ry website: FiSMA. (2007). NorthernScope - customer driven scope control for ICT projects. FiSMA. Hevner, A. R., March, S. T., Park, J., & Ram, S. (2004). Design science in Information systems research. MIS Quarterly, 28 (1), Käkölä, T., Wu, C., Yalaho, A., & Nahar, N. (2006). A Framework for ICTsupported international outsourcing of software production process and management. Deparment of Computer Science and Information systems. Keung, J., Jeffery, R., & Kitchenham, B. (2004). The Challenge of Introducing a New Software Cost Estimation Technology into a Small Software Organisation. Proceedings of the 2004 Australian Software Engineering Conference. Kitchenham, A. B., Pickard, M. L., MacDonell, G. S., & Shepperd, J. M. (2001). What accuracy statistics really measure. IEEE Proc.-Softw., 148 (3). Lokan, C., Wright, T., Hill, P. R., & Stringer, M. (2001, September). Organizational Benchmarking Using the ISBSG Data Repository. IEEE SOFTWARE, Matikainen, M. (2006). Information system supported project estimation and measurement. Jyväskylä: Jyväskylän yliopisto. Salo, A., & Käkölä, T. (2005). Groupware support for requirements management in new product development. Journal of organizational computing and electronic commerence, 15,
31 31 Tran-Cao, D., Levesque, G., & Abran, A. (2002). Measuring Software Functional Size: Towards an Effective Measurement of Complexity. Proceedings of the International Conference on Software Maintenance (ICSMí02). IEEE. Walls, J. G., George R, W., & Omar A El, S. (2004). Assessing information system desing theory in perspective: how useful was our 1992 initial rendition? Journal of information technology theory and application,
Estimointityökalut. Pekka Forselius, Senior Advisor Finnish Software Measurement Association FiSMA ry
Estimointityökalut Pekka Forselius, Senior Advisor Finnish Software Measurement Association FiSMA ry 1 Työkalujen rooli ohjelmistotyössä A fool with a tool is still a fool! Ohjelmistotyökalujen käyttäminen
Ohjelmistoprosessit ja ohjelmistojen laatu Kevät Ohjelmistoprosessit ja ohjelmistojen laatu. Projektinhallinnan laadunvarmistus
LAADUNVARMISTUS 135 Projektinhallinnan laadunvarmistus Projektinhallinnan laadunvarmistus tukee ohjelmistoprojektien ohjaus- ja ylläpitotehtäviä. Projektinhallinnan laadunvarmistustehtäviin kuuluvat seuraavat:
OHJ-3010 Ohjelmistotuotannon perusteet. Ohjelmistoprojektin hallinta
OHJ-3010 Ohjelmistotuotannon perusteet Ohjelmistoprojektin hallinta 1 Sisältö Projektiorganisaatio ja sidosryhmät Ohjelmistoprojektin kulku Projektin suunnittelu Ositus Osallistujat Työmäärän arviointi
Työmäärän arviointi. Vaihtoehtoja. Sami Kollanus TJTA330 Ohjelmistotuotanto
Työmäärän arviointi Sami Kollanus TJTA330 Ohjelmistotuotanto 20.3. Vaihtoehtoja Arvioidaan projektin jälkeen (onnistuu varmasti) Verrataan karkeasti samanlaisiin aiempiin projekteihin Ositetaan projekti
Työmäärän arviointi. Vaihtoehtoja. Arviointiprosessi. Sami Kollanus TJTA330 Ohjelmistotuotanto
Työmäärän arviointi Sami Kollanus TJTA330 Ohjelmistotuotanto 20.3. Vaihtoehtoja Arvioidaan projektin jälkeen (onnistuu varmasti) Verrataan karkeasti samanlaisiin aiempiin projekteihin Ositetaan projekti
CMM Capability Maturity Model. Software Engineering Institute (SEI) Perustettu vuonna 1984 Carnegie Mellon University
CMMI Sami Kollanus TJTA330 Ohjelmistotuotanto 13.3. CMM Capability Maturity Model Software Engineering Institute (SEI) www.sei.cmu.edu Perustettu vuonna 1984 Carnegie Mellon University 1985 SEI aloitti
CMMI CMM -> CMMI. CMM Capability Maturity Model. Sami Kollanus TJTA330 Ohjelmistotuotanto Software Engineering Institute (SEI)
CMMI Sami Kollanus TJTA330 Ohjelmistotuotanto 13.3. CMM Capability Maturity Model Software Engineering Institute (SEI) www.sei.cmu.edu Perustettu vuonna 1984 Carnegie Mellon University 1985 SEI aloitti
Sisäänrakennettu tietosuoja ja ohjelmistokehitys
Sisäänrakennettu tietosuoja ja ohjelmistokehitys Petri Strandén 14. kesäkuuta, 2018 Petri Strandén Manager Cyber Security Services Application Technologies Petri.stranden@kpmg.fi Petri vastaa KPMG:n Technology
CMMI CMMI CMM -> CMMI. CMM Capability Maturity Model. Sami Kollanus TJTA330 Ohjelmistotuotanto
CMM Capability Maturity Model CMMI Sami Kollanus TJTA330 Ohjelmistotuotanto 16.1.2007 Software Engineering Institute (SEI) www.sei.cmu.edu Perustettu vuonna 1984 Carnegie Mellon University 1985 SEI aloitti
Ohjelmistojen suunnittelu
Ohjelmistojen suunnittelu 581259 Ohjelmistotuotanto 154 Ohjelmistojen suunnittelu Software design is a creative activity in which you identify software components and their relationships, based on a customer
Ohjelmistotekniikka kevät 2003 Laatujärjestelmät
Laatujärjestelmät Ohjelmistotekniikka kevät 2003 Prosessiajattelu Sisään Prosessi Ulos ohjaus mittaus Laatujärjestelmät Laatujärjestelmät määrittelevät sen, mitkä prosessit täytyy olla määritelty ei sitä,
Tutkittua tietoa. Tutkittua tietoa 1
Tutkittua tietoa T. Dybå, T. Dingsøyr: Empirical Studies of Agile Software Development : A Systematic Review. Information and Software Technology 50, 2008, 833-859. J.E. Hannay, T. Dybå, E. Arisholm, D.I.K.
Mikä sitten on kallista? Milloin raha on viisaasti käytetty? Miten kallis määritellään toimintopistelaskennan näkökulmasta?
Mikä sitten on kallista? Milloin raha on viisaasti käytetty? Miten kallis määritellään toimintopistelaskennan näkökulmasta? ICT hyödyttämään liiketoimintaa siis oikeesti ja vähän äkkiä Mikko Paalasmaa,
2. päivä. Etätehtävien purku Poikkeamat. Poikkeamat Auditoinnin raportointi Hyvän auditoijan ominaisuudet Harjoituksia
OAMK / Luova 4.5. ja 11.5. Sisäinen auditointi osa Oamkin ympäristöohjelmatyötä Sisältö 1. päivä Johdanto Auditoinnin tavoitteet Ympäristöstandardin (ISO 14001) pääkohdat Alustava ympäristökatselmus Auditoinnin
Projektin tavoitteet
VBE II, vaihe 1: 2005-2006 Data yrityksistä ja rakennushankkeista TUT Tekniset ratkaisut RAK (VRLab)+ARK iroom validointi Työpajat Seminaarit Esitelmät Osallistuvat yritykset VTT Käyttöönotto- ja hyötymallit,
Loppuraportti. Virtuaali-Frami, CAVE-ohjelmisto. Harri Mähönen projektiassistentti Seinäjoen ammattikorkeakoulu. Versio
1 Loppuraportti Virtuaali-Frami, CAVE-ohjelmisto Harri Mähönen projektiassistentti Seinäjoen ammattikorkeakoulu Versio 1.0 15.1.2006 2 Sisällys Tiivistelmä... 3 1 Johdanto... 4 1.1 Dokumentin tarkoitus...
Software engineering
Software engineering Alkuperäinen määritelmä: Naur P., Randell B. (eds.): Software Engineering: A Report on A Conference Sponsored by the NATO Science Committee, NATO, 1968: The establishment and use of
Tenttikysymykset. + UML- kaavioiden mallintamistehtävät
Tenttikysymykset 1. Selitä mitä asioita kuuluu tietojärjestelmän käsitteeseen. 2. Selitä kapseloinnin ja tiedon suojauksen periaatteet oliolähestymistavassa ja mitä hyötyä näistä periaatteista on. 3. Selitä
SFS, 27.11 2014 STANDARDIEHDOTUKSEN ISO/DIS 14001 ESITTELY
SFS, 27.11 2014 STANDARDIEHDOTUKSEN ISO/DIS 14001 ESITTELY Anna-Liisa Koskinen SISÄLTÖ Uusi rakenne Uusia määritelmiä Keskeisistä muutoksista 2 ISO 14001 ympäristöjohtamisjärjestelmä ISO 14001 on tunnettu
PARTNERSHIP MONITOR. POTRA-NIS Oy I I
Partnership Monitor PARTNERSHIP MONITOR Partnership Monitor on menetelmä teollisuusyrityksille tuottavuuden lisäämiseksi ja liiketoiminnan kasvattamiseksi hyvin toimivien asiakas- ja toimittajasuhteiden
Tietojärjestelmän osat
Analyysi Yleistä analyysistä Mitä ohjelmiston on tehtävä? Analyysin ja suunnittelun raja on usein hämärä Ei-tekninen näkökulma asiakkaalle näkyvien pääkomponenttien tasolla Tietojärjestelmän osat Laitteisto
ISO/IEC 29881:2010 => SFS-ISO 29881:2013. FiSMA 1.1 menetelmä vihdoin myös suomeksi. Pekka Forselius, Senior Advisor, FiSMA ry
ISO/IEC 29881:2010 => SFS-ISO 29881:2013 FiSMA 1.1 menetelmä vihdoin myös suomeksi Pekka Forselius, Senior Advisor, FiSMA ry Ohjelmistojen toiminnallisen laajuuden mittaaminen Ison ohjelmiston kehittäminen
Tietojärjestelmän kehittäminen syksy 2003
Tietojärjestelmän kehittäminen syksy 2003 Ryhmä C2 Väliraportti 2-24.10. Päivi Laiterla Tomas Windahl Toni Nikkanen Antti Lehto 1 Sisällysluettelo Rich Picture...4 Käsitemalli...5 P-tason
Big Room -toiminta tutkimuksen näkökulmasta. Sari Koskelo, Vison Oy
? Big Room -toiminta tutkimuksen näkökulmasta Sari Koskelo, Vison Oy 16.3.2018 Sisältö Big Room konseptin moniulotteisuus Tavoitteet Johtaminen Big Room toiminta kehitys- ja toteutusvaiheissa Big Room
Johdantoluento. Ohjelmien ylläpito
Johdantoluento Ylläpito-termin termin määrittely Ylläpito ohjelmistotuotannon vaiheena Evoluutio-termin määrittely Muita kurssin aiheeseen liittyviä termejä TTY Ohjelmistotekniikka 1 Ohjelmien ylläpito
Ohjelmiston testaus ja laatu. Ohjelmistotekniikka elinkaarimallit
Ohjelmiston testaus ja laatu Ohjelmistotekniikka elinkaarimallit Vesiputousmalli - 1 Esitutkimus Määrittely mikä on ongelma, onko valmista ratkaisua, kustannukset, reunaehdot millainen järjestelmä täyttää
Software product lines
Thomas Gustafsson, Henrik Heikkilä Software product lines Metropolia Ammattikorkeakoulu Insinööri (AMK) Tietotekniikan koulutusohjelma Asiantuntijateksti 17.11.2013 Sisällys 1 Johdanto 1 2 Software product
IEC Sähköisten/eletronisten/ohjelmoitavien elektronisten turvallisuuteen liittyvien järjestelmien toiminnallinen turvallisuus
IEC 61508 Sähköisten/eletronisten/ohjelmoitavien elektronisten turvallisuuteen liittyvien järjestelmien toiminnallinen turvallisuus Risto Nevalainen, FiSMA ry FiSMA 1 Taustaa, historiaa IEC 61508 standardin
Projektinhallinta SFS-ISO mukaan
Projektinhallinta SFS-ISO 21500 mukaan (Ohjeita projektinhallinnasta, 2012) 13.4.2017 Panu Kiviluoma Osaamistavoitteet Luennon jälkeen osaat selittää, mitä tarkoitetaan Projektilla Projektinhallinnalla
Ohjelmistotekniikka - Luento 2 Jouni Lappalainen
Ohjelmistotekniikka - Luento 2 Jouni Lappalainen Luku 2: Prosessimallit - miten spiraalimalliin päädyttiin - spiraalimallista (R)UP malliin - oman ammattitaidon kehittäminen; PSP ja TSP mallit 1 Luento
QL Excellence -käsikirja
QL Excellence -käsikirja QL Laatutoiminta Oy:n laadunhallinta 2010 Sisällysluettelo: QL Excellence -käsikirja...3 Yleiskuvaus... 3 Laatupolitiikka...3 Laatukäsikirja...3 Laadunhallintajärjestelmän kuvaus...
Kokonaisvaltainen mittaaminen ohjelmistokehityksen tukena
Kokonaisvaltainen mittaaminen ohjelmistokehityksen tukena Mittaaminen ja ohjelmistotuotanto seminaari 18.04.01 Matias Vierimaa 1 Miksi mitataan? Ohjelmistokehitystä ja lopputuotteen laatua on vaikea arvioida
Projektin suunnittelu A71A00300
Projektin suunnittelu A71A00300 PESTLE-malli Poliittinen - mitä poliittisia riskejä projektiin voi liittyä? (verotus, hallinto ) Ekonominen - mitä taloudellisia riskejä projektiin liittyy? (työvoiman saatavuus,
Valtionhallinnon arkkitehtuurin kehittäminen
arkkitehtuurin kehittäminen Kehittämisohjelman esittely RASKE2-seminaari 16.5.2006 neuvotteleva virkamies Aki Siponen Valtion IT-toiminnan johtamisyksikkö arkkitehtuurin kehittäminen Arkkitehtuurista ja
Tuotekehitys ja yrityksen laatujärjestelmä
Tuotekehitys ja yrityksen laatujärjestelmä Torstai 9.11.2017 Marika Kilpivuori Toimintajärjestelmä vs. käytännön tuotekehitys Suunnitelmallista Dokumentoitu näyttö Vastuut ja valtuudet kuvattu Riskit ja
Prosessien kehittäminen. Prosessien parantaminen. Eri mallien vertailua. Useita eri malleja. Mitä kehitetään?
Prosessien kehittäminen Prosessien parantaminen Sami Kollanus TJTA330 Ohjelmistotuotanto 21.2.2007 Mitä kehitetään? CMMI, SPICE yms. Miten kehittämishanke saadaan toteutettua? Organisaation kehittämisen
Ohjelmistotekniikka - Luento 2
Ohjelmistotekniikka - Luento 2 Luku 2: Prosessimallit - miten spiraalimalliin päädyttiin - spiraalimallista (R)UP malliin - oman ammattitaidon kehittäminen; PSP ja TSP mallit 1 Luento 2: Prosessimallit
Koekysymyksiä. Ohjelmistoprosessit ja ohjelmistojen laatu Ohjelmistojen suorituskyky
Koekysymyksiä Ohjelmistoprosessit ja ohjelmistojen laatu 30.4.2015 58153003 Ohjelmistojen suorituskyky 1 Kurssikokeeseen tulee neljä koetilaisuudessa vastattavaa kysymystä KOKEESSA VASTATTAVAT KYSYMYKSET
Torstai Mikkeli
Torstai 14.2.2013 Mikkeli OSUVA (2012 2014) - Osallistuva innovaatiotoiminta ja sen johtamista edistävät tekijät sosiaali- ja terveydenhuollossa. hanke tutkii minkälaisilla innovaatiojohtamisen toimintatavoilla
Työkaluja esimiestyön tehostamiseen
Työkaluja esimiestyön tehostamiseen 7.5.2009 Anna-Maija Sorvoja, HR Management Consultant Aditro Ohjelma 1. Esimiestyön haasteita 2. Työkaluja haasteiden kohtaamiseen, 3. Yhteenveto case-esimerkkejä 2
INTEGROIDUT PROJEKTITOTEUTUKSET. IPT-strategiapäivä , Lauri Merikallio, Vison Alliance Partners Oy
INTEGROIDUT PROJEKTITOTEUTUKSET IPT-strategiapäivä 16.1.2014, Lauri Merikallio, Vison Alliance Partners Oy Arkipäivän pohdintaa epävarmuuksia ja riskejä sisältävien hankkeiden johtamisessa Kuka/ketkä hinnoittelevat
Ohjelmistojen mallintaminen, mallintaminen ja UML
582104 Ohjelmistojen mallintaminen, mallintaminen ja UML 1 Mallintaminen ja UML Ohjelmistojen mallintamisesta ja kuvaamisesta Oliomallinnus ja UML Käyttötapauskaaviot Luokkakaaviot Sekvenssikaaviot 2 Yleisesti
TUKIMATERIAALI: Arvosanan kahdeksan alle jäävä osaaminen
1 FYSIIKKA Fysiikan päättöarvioinnin kriteerit arvosanalle 8 ja niitä täydentävä tukimateriaali Opetuksen tavoite Merkitys, arvot ja asenteet T1 kannustaa ja innostaa oppilasta fysiikan opiskeluun T2 ohjata
Ohjelmistoprojektien hallinta Vaihejakomallit
Ohjelmistoprojektien hallinta Vaihejakomallit Vaihejakomallit TAVOITE: YMMÄRTÄÄ eri vaihejakomallien etujajahaittoja 2 Erilaisia malleja Tee ja korjaa (Code-and-Fix) Vesiputousmalli (Waterfall) Vesiputousmalli
Projektin suunnittelu A71A00300
Projektin suunnittelu A71A00300 Projektisuunnitelma 1. Projektitiimi 2. Projektin tausta 3. Projektin tavoitteet 4. Tiimin roolit 5. Sisäinen viestintä 6. Riskianalyysi 7. Aikataulutus Projektisuunnitelman
Uudelleenkäytön jako kahteen
Uudelleenkäyttö Yleistä On pyritty pääsemään vakiokomponenttien käyttöön Kuitenkin vakiokomponentit yleistyneet vain rajallisilla osa-alueilla (esim. windows-käyttöliittymä) On arvioitu, että 60-80% ohjelmistosta
Autamme asiakkaitamme menestymään parantamalla tekemisen luottamustasoa ja läpinäkyvyyttä uusilla innovatiivisilla konsepteilla ja ratkaisuilla.
Celkee Oy:n Missio Autamme asiakkaitamme menestymään parantamalla tekemisen luottamustasoa ja läpinäkyvyyttä uusilla innovatiivisilla konsepteilla ja ratkaisuilla. Tuomme organisaatioiden piilossa olevan
Copyright by Haikala. Ohjelmistotuotannon osa-alueet
Copyright by Haikala Ohjelmistotuotannon osa-alueet Ohjelmiston elinkaari 1. Esitutkimus, tarvekartoitus, kokonaissuunnittelu, järjestelmäsuunnittelu (feasibility study, requirement study, preliminary
Verkko-oppiminen: Teoriasta malleihin ja hyviin käytäntöihin. Marleena Ahonen. TieVie-koulutus Jyväskylän lähiseminaari
Verkko-oppiminen: Teoriasta malleihin ja hyviin käytäntöihin Marleena Ahonen TieVie-koulutus Jyväskylän lähiseminaari Virtuaaliyliopistohankkeen taustaa: - Tavoitteena koota verkko-oppimisen alueen ajankohtaista
Millainen on menestyvä digitaalinen palvelu?
Millainen on menestyvä digitaalinen palvelu? TOIMIVA ÄLYKÄS ILAHDUTTAVA Ohjelmistokehitys Testaus ja laadunvarmistus Ohjelmistorobotiikka Tekoäly Käyttöliittymäsuunnittelu Käyttäjäkokemussuunnittelu 1
Teoreettisen viitekehyksen rakentaminen
Teoreettisen viitekehyksen rakentaminen Eeva Willberg Pro seminaari ja kandidaatin opinnäytetyö 26.1.09 Tutkimuksen teoreettinen viitekehys Tarkoittaa tutkimusilmiöön keskeisesti liittyvän tutkimuksen
Hyvin määritelty on puoliksi tehty kuinka vältetään turha tekeminen jo alussa
1 Hyvin määritelty on puoliksi tehty kuinka vältetään turha tekeminen jo alussa Passion leads to design, design leads to performance, performance leads to SUCCESS! OLLI NIEMI Yoso Oy Mitä määrittelyltä
Onnistunut SAP-projekti laadunvarmistuksen keinoin
Onnistunut SAP-projekti laadunvarmistuksen keinoin 07.10.2010 Patrick Qvick Sisällys 1. Qentinel 2. Laadukas ohjelmisto täyttää sille asetetut tarpeet 3. SAP -projektin kriittisiä menestystekijöitä 4.
SFS-ISO/IEC Tietoturvallisuuden hallintajärjestelmät. Ohjeistusta. Riku Nykänen
SFS-ISO/IEC 27003 Tietoturvallisuuden hallintajärjestelmät. Ohjeistusta Riku Nykänen 14.12.2018 SFS-ISO/ IEC 2 70 0 3 Tietoturvallisuuden hallintajärjestelmät. Ohjeistusta Riku Ny kän en, 14.12.2 0 18
Laatukäsikirja - mikä se on ja miten sellainen laaditaan?
Laatukäsikirja - mikä se on ja miten sellainen laaditaan? Matkailun laatu laatukäsikirja osaksi yrityksen sähköistä liiketoimintaa Sähköinen aamuseminaari matkailualan toimijoille 24.8.2010 Riitta Haka
Mistä on kyse ja mitä hyötyä ne tuovat?
Pilvipalvelut Mistä on kyse ja mitä hyötyä ne tuovat? Pilvipalvelut - Mistä on kyse ja mitä hyötyä ne tuovat? Suurin osa kaikista uusista it-sovelluksista ja -ohjelmistoista toteutetaan pilvipalveluna.
Keskitetyn integraatiotoiminnon hyödyt
Keskitetyn integraatiotoiminnon hyödyt Janne Kangasluoma / Chief Enterprise Architect, Ilmarinen Teemu O. Virtanen / Director, Information Logistics, Digia 2013 IBM Corporation HUOLEHDIMME NOIN 900 000
Rakentamisen 3D-mallit hyötykäyttöön
Rakentamisen 3D-mallit hyötykäyttöön 1 BIM mallien tutkimuksen suunnat JAO, Jyväskylä, 22.05.2013 Prof. Jarmo Laitinen, TTY rakentamisen tietotekniikka Jarmo Laitinen 23.5.2013 Jarmo Laitinen 23.5.2013
SYSTEEMIJOHTAMINEN! Sami Lilja! itsmf Finland 2014! Oct 2-3 2014! Kalastajatorppa, Helsinki! Reaktor 2014
SYSTEEMIJOHTAMINEN! Sami Lilja! itsmf Finland 2014! Oct 2-3 2014! Kalastajatorppa, Helsinki! Reaktor Mannerheimintie 2 00100, Helsinki Finland tel: +358 9 4152 0200 www.reaktor.fi info@reaktor.fi 2014
TARKASTUSMENETTELYT JA NIIDEN APUVÄLINETUKI
TARKASTUSMENETTELYT JA NIIDEN APUVÄLINETUKI Vesa Tenhunen Tarkastusmenettelyt Keino etsiä puutteita ohjelmakoodeista, dokumenteista ym. ohjelmistoprosessissa syntyvästä materiaalista Voidaan käyttää kaikissa
Yritysturvallisuuden johtamisen arviointi
Yritysturvallisuuden johtamisen arviointi Kiwa Rima Kiwa Inspecta Trust, Quality & Progress Mitä hyvä yritysturvallisuuden johtaminen on? Turvallisuuden johtaminen on tavoitteellista ja liiketoimintaa
AVOIMEN TUOTTEEN HALLINTAMALLIT. Kunnassa toteutettujen tietojärjestelmien uudelleenkäyttö. Yhteentoimivuutta avoimesti 2.12.2011
AVOIMEN TUOTTEEN HALLINTAMALLIT Kunnassa toteutettujen tietojärjestelmien uudelleenkäyttö Yhteentoimivuutta avoimesti 2.12.2011 Erikoistutkija, MSc. Tapio Matinmikko, Teknologian tutkimuskeskus VTT 2 Esittäjästä
Automatisoidun talousraportoinnin koulutusohjelma Olli Ahonen Valtiokonttori. Tietokiri on alkanut tule mukaan!
Automatisoidun talousraportoinnin koulutusohjelma Olli Ahonen Valtiokonttori Tietokiri on alkanut tule mukaan! 2 MISTÄ TIETOKIRISSÄ ON KYSE? #Tietokiri eli julkishallinnon analysointi- ja raportointipalveluiden
Sisäänrakennettu tietosuoja ja ohjelmistokehitys
Sisäänrakennettu tietosuoja ja ohjelmistokehitys Petri Strandén 8. kesäkuuta, 2018 Agenda Ohjelmistokehitys Ohjelmistokehitys vs. konsultointi Vaatimukset Tietosuoja Tietosuoja ohjelmistokehityksessä kiteytettynä
lähes nollaenergiapientalon rakennuttamisen mallintaminen Hankkeen toteutus kysely ja haastattelututkimuksen tuloksia nzeb Hankeosaaminen
lähes nollaenergiapientalon rakennuttamisen mallintaminen Hankkeen toteutus kysely ja haastattelututkimuksen tuloksia Kyselytutkimuksen tavoitteet Kysely-ja haastattelututkimuksen tavoitteena oli selvittää
MIKKO-projekti ja mittausten automatisointi
MIKKO-projekti ja mittausten automatisointi FiSMA-seminaari 11.12.00 Matias Vierimaa VTT Elektroniikka 1 MIKKO-projekti Projektin tavoitteena on kehittää mittauskehikko, joka tukee ohjelmistoprosessin
ICT:n johtamisella tuloksia
Tuottava IT ICT:n johtamisella tuloksia Data: Tietohallintojen johtaminen Suomessa 2012 Tietääkö liiketoimintajohto mitä IT tekee? Ei osaa sanoa tietääkö Ei tiedä Osittain Tietää 0 % 10 % 20 % 30 % 40
ITK130 Ohjelmistojen luonne
ITK130 Ohjelmistojen luonne Luennon sisältö Ohjelmistotekniikka ja vaatimukset Ohjelmistotuote Ei-toiminnallisten vaatimusten luokittelu Sisäiset ja ulkoiset vaatimukset Oikeellisuus Luotettavuus Kestävyys
MIKÄ ON TIIMI? Tiimi on pieni ryhmä ihmisiä, joilla on: Lisäksi tiimin jäsenet pitävät itseään yhteisvastuussa suorituksistaan.
MIKÄ ON TIIMI? Tiimi on pieni ryhmä ihmisiä, joilla on: - Toisiaan täydentäviä taitoja - Jotka ovat sitoutuneet yhteiseen päämäärään - Yhteisiin suoritustavoitteisiin ja - Yhteiseen toimintamalliin Lisäksi
KORJAUSVELAN LASKENTAMALLI KÄYTTÖÖN
KORJAUSVELAN LASKENTAMALLI KÄYTTÖÖN KEHTO-foorumi Seinäjoki 23.10.2014 TAUSTAA Korjausvelan määrityshanke vuonna 2012-2013 Katujen ja viheralueiden korjausvelan periaatteita ei ollut aiemmin määritelty
Menetelmäraportti - Konfiguraationhallinta
Menetelmäraportti - Konfiguraationhallinta Päiväys Tekijä 22.03.02 Ville Vaittinen Sisällysluettelo 1. Johdanto... 3 1.1 Tärkeimmät lyhenteet... 3 2. Konfiguraationhallinnan tärkeimmät välineet... 4 2.1
Käytettävyyslaatumallin rakentaminen web-sivustolle. Oulun yliopisto tietojenkäsittelytieteiden laitos pro gradu -suunnitelma Timo Laapotti 28.9.
Käytettävyyslaatumallin rakentaminen web-sivustolle Tapaus kirjoittajan ABC-kortti Oulun yliopisto tietojenkäsittelytieteiden laitos pro gradu -suunnitelma Timo Laapotti 28.9.2005 Kirjoittajan ABC-kortti
FARAX johtamisstrategian räätälöinti
FARAX johtamisstrategian räätälöinti Sisältö Taustaa Johtamisstrategian luominen ja instrumentin luominen Hyödyt ja referenssit Esimerkkejä matriiseista Prosessi Taustaa Esityksessä käydään läpi FaraxGroupin
EcoProP Potilashuoneen toiminnalliset vaatimukset
EcoProP Potilashuoneen toiminnalliset vaatimukset HospiTool 1.12.2006 Janne Porkka Esityksen sisältö Taustatietoja Vaatimustenhallinta Toimivuusajattelu HospiTool hankkeen 1.vaiheen esittely Pyritään määrittelemään
MONOGRAFIAN KIRJOITTAMINEN. Pertti Alasuutari
MONOGRAFIAN KIRJOITTAMINEN Pertti Alasuutari Lyhyt kuvaus Monografia koostuu kolmesta pääosasta: 1. Johdantoluku 2. Sisältöluvut 3. Päätäntäluku Lyhyt kuvaus Yksittäinen luku koostuu kolmesta osasta
Käytännön ideoita verkostotyöhön & toimintatutkimuksellinen ote verkostojen kehittämiseen. Timo Järvensivu, KTT Aalto-yliopiston kauppakorkeakoulu
Käytännön ideoita verkostotyöhön & toimintatutkimuksellinen ote verkostojen kehittämiseen Timo Järvensivu, KTT Aalto-yliopiston kauppakorkeakoulu Toimintatutkimus? Toimintatutkimus on sosiaalinen prosessi,
Mitä opittiin? Service Design työpajoissa. Helena Ahola,Taina Vuorela, Päivi Aro
Mitä opittiin? Service Design työpajoissa Helena Ahola,Taina Vuorela, Päivi Aro Fasilitointi liiketoiminnankehittämistyöpajoissa: vähän tutkittua! MITÄ FASILITOINTI ON? Innovointityöpajan hallittua managerointia
JULKISEN HALLINNON SÄHKÖISEN ASIOINNIN VIITEARKKITEHTUURI. Kuntaliitto Hannu Ojala Neuvotteleva virkamies/julkict
JULKISEN HALLINNON SÄHKÖISEN ASIOINNIN VIITEARKKITEHTUURI Kuntaliitto 02.10.2012 Hannu Ojala Neuvotteleva virkamies/julkict Lähtökohdat Laaditaan kokonaisarkkitehtuuri tietylle sektorille, joka menee läpi
Oleelliset vaikeudet OT:ssa 1/2
Oleelliset vaikeudet OT:ssa 1/2 Monimutkaisuus: Mahdoton ymmärtää kaikki ohjelman tilat Uusien toimintojen lisääminen voi olla vaikeaa Ohjelmista helposti vaikeakäyttöisiä Projektiryhmän sisäiset kommunikointivaikeudet
RAIN RAKENTAMISEN INTEGRAATIOKYVYKKYYS
RAIN RAKENTAMISEN INTEGRAATIOKYVYKKYYS Loppuseminaari 11.12.2018 YIT:n pääkonttori, Helsinki RAIN hankkeen loppuseminaari 11.12.2018 Käyttäjälähtöinen tiedonhallinta (WP 4) Professori Harri Haapasalo OY
Yhteisöllisen toimintatavan jalkauttaminen!
Yhteisöllisen toimintatavan jalkauttaminen! Käyttöönoton vaiheet Yrityksen liiketoimintatavoitteet Yhteisöllisen toimintatavan käyttöalueet Työkalut Hyödyt yritykselle Hyödyt ryhmälle Hyödyt itselle Miten
How to Support Decision Analysis with Software Case Förbifart Stockholm
How to Support Decision Analysis with Software Case Förbifart Stockholm (Valmiin työn esittely) 13.9.2010 Ohjaaja: Prof. Mats Danielson Valvoja: Prof. Ahti Salo Tausta -Tukholman ohikulkutien suunnittelu
ADE Oy Hämeen valtatie 144 20540 TURKU. Tuotekonfigurointi. ADE Oy Ly Tunnus: 1626957-3
Tuotekonfigurointi ADE Oy lyhyesti Asiakkaiden tarpeisiin suunnattua innovatiivista ja toimivaa ohjelmisto- ja 3d animaatiopalvelua. Ade Oy on toteuttanut vuodesta 2000 alkaen haastavaa interaktiivista
Ei näyttöä tai puheen tasolla
Jyväskylän yliopisto 1(5) Dokumenteilla tarkoitetaan suuntaa ohjaavia asiakirjoja, strategioita ja linjauksia. Keskeisiä ovat vain ko. auditointikohdetta koskevat ja ohjaavat dokumentit. Dokumentit voivat
Rekursiolause. Laskennan teorian opintopiiri. Sebastian Björkqvist. 23. helmikuuta Tiivistelmä
Rekursiolause Laskennan teorian opintopiiri Sebastian Björkqvist 23. helmikuuta 2014 Tiivistelmä Työssä käydään läpi itsereplikoituvien ohjelmien toimintaa sekä esitetään ja todistetaan rekursiolause,
Advanced Test Automation for Complex Software-Intensive Systems
Advanced Test Automation for Complex Software-Intensive Systems Aiheena monimutkaisten ohjelmistovaltaisten järjestelmien testauksen automatisointi Mistä on kyse? ITEA2-puiteohjelman projekti: 2011-2014
Toimintaja rjestelma (johtamisja rjestelma ) opas
1 (6) Toimintaja rjestelma (johtamisja rjestelma ) opas Sisällys Mikä on toimintajärjestelmä... 2 Hyvä toimintajärjestelmä... 3 Hyödyt... 3 Toimintajärjestelmän rakentaminen... 4 Autamme sinua... 6 Business
Mobiilit käyttöliittymät lääkitystietoon
Mobiilit käyttöliittymät lääkitystietoon Katja Leiviskä, Harri Oinas-Kukkonen, Teppo Räisänen Oulun yliopisto, Tietojenkäsittelytieteiden laitos katja.leiviska@oulu.fi, harri.oinas-kukkonen@oulu.fi, teppo.raisanen@oulu.fi
Ohjelmistotuotteen hallinnasta
Ohjelmistotuotteen hallinnasta Luennon tavoitteista Luennon sisällöstä Motivointia Lähteinä: Haikala ja Märijärvi, Ohjelmistotuotanto Royce, Software Project Management, A Unified Framework 1 Tavoitteista
Tietoturvallisuuden kokonaisvaltainen hallinta Heikki O. Penttinen Castilsec Oy.
Tietoturvallisuuden kokonaisvaltainen hallinta 3.12.2015 Heikki O. Penttinen Castilsec Oy Tietoturvallisuuden päätavoitteet organisaatioissa Tietoturvallisuuden oikean tason varmistaminen kokonaisvaltaisesti
Miten kuvaat ja kehität organisaation kokonaisarkkitehtuuria?
Miten kuvaat ja kehität organisaation kokonaisarkkitehtuuria? Kuntamarkkinat Tietoisku 10. ja 11.9.2014 1 Mitä on kokonaisarkkitehtuuri? Kokonaisarkkitehtuuri on organisaation johtamis- ja kehittämismenetelmä,
Soveltuvuustutkimus Lifebelt-ohjelman ideologian käytettävyydestä olioorientoituneeseen
Soveltuvuustutkimus Lifebelt-ohjelman ideologian käytettävyydestä olioorientoituneeseen ohjelmointiin Jukka Talvitie Valvoja: Professori Jorma Jormakka Paikka: TietoEnator oyj Ongelma Ideologia Lifebelt
Testauksen tuki nopealle tuotekehitykselle. Antti Jääskeläinen Matti Vuori
Testauksen tuki nopealle tuotekehitykselle Antti Jääskeläinen Matti Vuori Mitä on nopeus? 11.11.2014 2 Jatkuva nopeus Läpäisyaste, throughput Saadaan valmiiksi tasaiseen, nopeaan tahtiin uusia tuotteita
Hiljaisen tietämyksen johtaminen
Hiljaisen tietämyksen johtaminen Uudista ja uudistu 2009 Hiljainen tietämys on osa osaamista Hiljainen ja näkyvä tieto Hiljainen tieto Tiedämme enemmän kuin kykenemme ilmaisemaan *) kokemusperäistä, alitajuista
Osaamispassi ja erityisosaamistietokanta tulevaisuuden osaajille
Osaamispassi ja erityisosaamistietokanta tulevaisuuden osaajille Futurex -seminaari Korkeakoulujen täydennyskoulutusten laatu Helsinki 6.3.2013 Anne-Maritta Tervakari Intelligent Information Systems Laboratory
Yritysturvallisuuden johtamisen arviointi
Yritysturvallisuuden johtamisen arviointi Kiwa Rima Kiwa Inspecta Trust, Quality & Progress Mitä hyvä yritysturvallisuuden johtaminen on? Turvallisuuden johtaminen on tavoitteellista ja liiketoimintaa
Työssäkäyvä opiskelija haastaa ammattikorkeakoulun pedagogiikan ja rakenteita Joustavat opintopolut ja opinnollistaminen
Työssäkäyvä opiskelija haastaa ammattikorkeakoulun pedagogiikan ja rakenteita Joustavat opintopolut ja opinnollistaminen 28.3.2017 29.3.2017 1 liisa.vanhanen-nuutinen@haaga-helia.fi hannu.kotila@haaga-helia.fi
Tapahtuipa Testaajalle...
Tapahtuipa Testaajalle... - eli testaus tosielämässä 09.10.2007 Juhani Snellman Qentinel Oy 2007 Agenda Minä ja mistä tulen Testauksen konteksti Tapauksia tosielämästä ja työkaluja 2 Minä Juhani Snellman
Simulation and modeling for quality and reliability (valmiin työn esittely) Aleksi Seppänen
Simulation and modeling for quality and reliability (valmiin työn esittely) Aleksi Seppänen 16.06.2014 Ohjaaja: Urho Honkanen Valvoja: Prof. Harri Ehtamo Työn saa tallentaa ja julkistaa Aalto-yliopiston