SFS-ISO 29881:2013 julkistus

Transkriptio

1 SFS-ISO 29881:2013 julkistus FiSMA 1.1 menetelmä vihdoin myös suomeksi Pekka Forselius, Senior Advisor, FiSMA ry

2 Mikä FiSMA 1.1 on? Järjestelmä- ja ohjelmistotekniikka-standardeihin lukeutuva kansainvälinen standardi (ISO/IEC 29881:2010) Kaikentyyppisille ohjelmistoille soveltuva yleinen ja parametrisoitu toiminnallisen laajuuden mittausmenetelmä Sen on kehittänyt Finnish Software Measurement Association (FiSMA) -yhdistyksen työryhmä FiSMA 1.1 perustuu ainoastaan käyttäjän toiminnallisuusvaatimuksiin (FUR) FiSMA 1.1 menetelmän käyttö edellyttää, että kaikki mitattavan ohjelmiston käyttäjälle tuottamat eri palvelut tunnistetaan Mittaamisen tarkoitus on tuottaa ohjelmiston toiminnalliselle laajuudelle numeerinen arvo Määrittely Johtaminen KÄYTTÄJÄ Käyttäjän tarpeet Toiminnallisuusvaatimukset Toiminnot MITATTAVA OHJELMISTO FiSMA

3 Mihin (uusia) menetelmiä (muka) tarvitaan? Prosessien parantamiseen, kun halutaan hoitaa usein toistuvia työtehtäviä entistä paremmin On tärkeätä ymmärtää että paraskaan menetelmä ei yksinään riitä merkittävään prosessin parantamiseen: sen tueksi tarvitaan myös oikeanlainen organisaatio ja tehokkaat työvälineet (Bootstrap instituutti, 1995) Sama pätee myös organisaatiomuutoksiin ja työvälineiden hankintaan, nekään eivät toimi yksinään, ilman menettelyjen muuttamista FiSMA

4 Toiminnallisen laajuuden ja toimintopisteiden hyödyntämismahdollisuudet FiSMA

5 Toiminnallisen laajuuden hyödyntäminen käytännössä: FiSMA

6 Ohjelmistojen toiminnallisen laajuuden mittaaminen Ison ohjelmiston kehittäminen vaatii enemmän työtä kuin pienen. Iso ohjelmisto on yleensä kalliimpi kuin pieni. Jos emme pysty mittaamaan määritellyn ohjelmiston toiminnallista laajuutta, ei sitä kukaan pysty toteuttamaankaan. Aivan liian moni ohjelmistoprojekti epäonnistuu tai tuntuu epäonnistuneelta, kun aikaansaannosten laajuutta ei mitata missään vaiheessa. FiSMA

7 FiSMA 1.1 menetelmänä menetelmien joukossa Toimintopisteiden historia -5 ISO-standardia vuonna 2013 FiSMA

8 Miksi FiSMA alunperin? Miksi myös ISO ja SFS-standardiksi? Albrechtin FPA/IFPUG vanhanaikainen ja hitaasti kehittyvä 1990, myös karkea, kolmiportainen kompleksisuusluokitus koettiin ongelmaksi ja VAF koettiin harhaanjohtavaksi turhakkeeksi koon mittausmenetelmässä Tietokannat tulivat yksinkertaisten tiedostojen tilalle, graafiset käyttöliittymät yleistyivät, client-server- ja monikerrosarkkitehtuurit tekivät tuloaan, tarve huomioida monimutkaiset algoritmiset käsittelyvaatimukset yleistyi Käyttäjälähtöinen ajattelu KISS-laskennan myötä oman menetelmämme keskeiseksi periaatteeksi 1990-luvun lopussa: pois kehittäjäkeskeisyydestä Halu siirtyä viisiportaisesta jatkuvaan asteikkoon uusien teknologioiden myötä (Notes Domino, karttapohjaisuus, portaalisovellukset yms.) Hyvät kokemukset menetelmän soveltamisesta hinnoittelun ja sopimusten perustana, läpinäkyvyys ja ymmärrettävyys sekä tilaajan että toimittajan osalta Lopulta EU koettiin uhkaksi: epästandardien mittausmenetelmien käyttö julkisissa hankintasopimuksissa voitaisiin kieltää. Haluttomuus siirtyä takaisin vanhojen, kehittäjäkeskeisten menetelmien käyttöön. FiSMA

9 Mielipide MAANANTAINA It-hankinnoissa voidaan onnistua "Väljästi määritellyssä projektissa tilaajan ja toimittajan välinen liiketoimintasuhde on haastava." Markku Marjamäki valvontajohtaja sosiaali- ja terveysministeriö Vesa Teikari käsitteli (HS Mielipide ) it-hankintoja mielenkiintoisella tavalla. Teikarin mukaan monimutkaisen tietojärjestelmän yksityiskohtainen määrittäminen etukäteen on mahdotonta. Tilaajan ja toimittajan välinen suhde tulisi järjestää niin, että alussa sovittaisiin vain suurista linjoista. Käytännön asioista ja osavaiheiden hyväksymisehdoista neuvoteltaisiin projektin aikana. Omat kokemukseni työsuojeluhallinnon valvontatietojärjestelmän luomisesta tukevat Teikarin näkemystä. Projekti alkoi vuonna Alun perin osatoimitusprojekteja oli suunnitelmissa neljä, nyt hanke koostuu viidestä toimitusprojektista. Lisäksi tietojärjestelmän ominaisuudet ovat laadullisesti hyvin toisenlaiset kuin alussa suunniteltiin. Tietojärjestelmien kehittäminen liittyy kiinteästi toiminnan muuhun kehittämiseen. Siksi suunnitelmia on jouduttu päivittämään ja täydentämään, jotta uusi järjestelmä pystyisi palvelemaan mahdollisimman hyvin työsuojeluvalvonnan tarpeita. On täysin epärealistista kuvitella, että vuonna 2008 olisimme voineet määrittää tarkasti kaikki ne ominaisuudet, joita uudelta toimivalta tietojärjestelmältä lopulta edellytetään. Teikarin mukaan tällainen on vallitseva tilanne tietojärjestelmäprojekteissa. Väljästi määritellyssä projektissa tilaajan ja toimittajan välinen liiketoimintasuhde on haastava. Riittääkö vain "tiivis ja läpinäkyvä yhteistyö" kuten Teikari esittää? Mielestäni ei. Projektin aikana käytäviä neuvotteluja varten tarvitaan työkalu, jolla sekä tilaaja että toimittaja voivat arvioida it-projektissa tehtävää työtä sekä laadullisesti että määrällisesti mahdollisimman puolueettomasti. Työsuojeluhallinnon valvontatietojärjestelmän kehittämisessä on käytetty apuna niin sanottua toimintopistemenetelmää (Fisma 1.1). Se perustuu standardoituun tapaan arvioida muun muassa sitä, kuinka paljon järjestelmä sisältää näyttöjä, liittymiä muihin tietojärjestelmiin sekä kuinka paljon tietoa tallennetaan tietovarastoihin. Kun tietojärjestelmän rakentamisessa poiketaan ennakkomäärittelyistä tai toteutetaan aivan uusia osia, työkalun avulla voidaan arvioida muutoksia niin tilaajan kuin toimittajankin näkökulmasta. Sopimuksissa perinteinen tapa on määritellä lisätöiden työtunnin hinta. Työsuojeluhallinnon tietojärjestelmäprojektin kilpailutus perustui keskeisiltä osiltaan toimintopisteen hintaan. Tämä on osoittautunut hyväksi ratkaisuksi. Tarkentavat sopimusneuvottelut ovat sujuneet tilaajan ja toimittajan välillä vaivattomasti. Valvontatietojärjestelmää koskevassa projektissa toimintopistemenetelmää on käytetty laajasti. Sitä on hyödynnetty projektin alustavan laajuuden selvittämisessä, lopullisen tietojärjestelmän laajuuden mittaamisessa tilaajan ja toimittajan välisissä sopimusasioissa sekä toimittajan työn edistymisen seurannassa. Kokemukset toimintopistemenetelmän käyttämisestä ovat rohkaisevia. Tutkimuksella on selvitetty, miten 107 julkishallinnossa toteutettua tietojärjestelmäprojektia ovat onnistuneet. Työsuojeluvalvonnan tietojärjestelmän kaksi ensimmäistä toimitusprojektia ovat tässä joukossa toimitustehokkuudeltaan kaksi parasta. FiSMA

10 FiSMA 1.1 menetelmästandardin sisältö 1. Soveltamisala (Scope) 2. Velvoittavat viittaukset 3. Termit ja määritelmät 4. FiSMA 1.1 menetelmän toimintoluokat ja toimintotyypit 5. FiSMA1.1-mittausprosessi 6. Toimintoluokkien laskentasäännöt 7. Toiminnallisen laajuuden mittayksikkö 8. Ohjelmiston toiminnallisen kokonaislaajuuden laskeminen FiSMA 1.1 menetelmällä 9. Mittaustulosten raportointi 10.FiSMA 1.1 -menetelmän muunnettavuus muihin toiminnallisen laajuuden mittausmenetelmiin FiSMA

11 Toimintoluokat ja toimintotyypit FiSMA

12 FiSMA 1.1 menetelmän määritelmät 3.1 toimintoluokka toimintotyyppien määritelty joukko 3.2 rajapinta käsitteellinen liittymäpinta tutkittavan ohjelmiston ja sen käyttäjien välillä 3.3 tietoelementti toiminnon ainutkertainen, käyttäjän tunnistettavissa oleva ja toistumaton kenttä 3.4 tietovarasto dataa ja informaatiota sisältävä organisoitu ja pysyvä kokoelma, josta on mahdollista hakea tietoa 3.5 loppukäyttäjä henkilö, joka jossain vaiheessa viestii tai on vuorovaikutuksessa ohjelmiston kanssa 3.6 toiminnot FiSMA 1.1 -menetelmällä määritellyt ohjelmiston käyttäjälle tuottamat palvelut (BFC:t) 3.7 operaatio algoritmisen toiminnon tai käsittelytoiminnon sisältämä aritmeettinen tai looginen operaatio 3.8 lukuviite toiminnon hakeman tiedon saantipaikka, joka voi olla oman tietovaraston käsite tai tietue, tai toisesta ohjelmistosta vastaanotettava liittymätietue 3.9 käyttäjä henkilö tai jokin muu toimija, joka viestii tai on vuorovaikutuksessa ohjelmiston kanssa 3.10 kirjoitusviite toiminnon käyttämän tai muodostaman tiedon tallennuspaikka, joka voi olla oman tietovaraston käsite tai tietue, tai toiseen ohjelmistoon lähetettävä liittymätietue FiSMA

13 FiSMA 1.1 käytännössä laajuuden arvioinnista mittaamiseen Alustava arviointi oletusarvoin Baseline mittaus osin oletusarvoin Edistymisen valvonta ja muutoshallinta sprinteittäin tai määräväliajoin Toteutetun Laajuuden mittaus Käyttötilanteet Käsitemalli Käyttötarinat Prosessikaaviot Toimintojen kuvaukset Laatuvaatimukset Tekniset vaatimukset Kuvaruutuja raporttimallit ohjelmakoodi Lopullinen dokumentaatio Käyttöohjeet Ohjelmisto tuotannossa FiSMA

14 Arviot kehittämisen elinkaaren aikana Alun virhe -% riippuu n. 90% vaatimusten epätarkkuudesta ja < 10 % FiSMA 1.1 mittaustarkkuudesta Alun virhe-% on harvoin yli 30 % FiSMA

15 Tuumasta toimeen omien prosessien parantamiseen FiSMA

16 Kiitos! Kaikille FiSMAn piirissä vuosien varrella tähän SFS-ISO-standardiin johtaneeseen yhteistyöhön annetusta panoksesta! Erityisesti FiSMA 1.0 ydinryhmän Juhani Jokela, Hannu Toivonen, Jorma Hirvonen, Paula Männistö ja Juha Salmi! Kansainvälisille asiantuntijoille, jotka omalla merkittävällä panoksellaan auttoivat ISO/IEC-standardimme läpi menoa ja korkeata laatua, erityisesti Carol Dekkers, Jacky Takahashi ja Debbie Dickson! SFS:n IT-standardointiporukan asiantuntijoille, jotka ottivat menetelmästandardimme suomentamisprojektin vastuulleen ja auttoivat sen loppuun saattamisessa Teille aktiivisille kuulijoille, jotka viette viestiä eteenpäin suomalaisen tietojärjestelmätyön kilpailukyvyn ja jatkuvuuden varmistamiseksi! Pekka Forselius, FM, MBA, CSM sähköposti: Katso myös ja FiSMA