SFS-ISO 29881:2013 julkistus

FiSMA 1.1 menetelmä vihdoin myös

suomeksi

Pekka Forselius, Senior Advisor, FiSMA ry

FiSMA 2012 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

Käyttäjän tarpeet

Toiminnallisuus-vaatimukset

Toiminnot

KÄYTTÄJÄ

MITATTAVAOHJELMISTO

Määrittely

Johtaminen

FiSMA 2012 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 2012 4

Toiminnallisen laajuuden ja toimintopisteiden

hyödyntämismahdollisuudet

FiSMA 2012 5

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

FiSMA 2012 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 2012 7

FiSMA 1.1 – menetelmänä menetelmien joukossa

Toimintopisteiden

historia

-5 ISO-standardia

vuonna 2013

FiSMA 2012 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 2012 9

Mielipide

MAANANTAINA 1.10.2012

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 26. 9.) 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 2008. 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 mah-

dollisimman 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äky-

vä yhteistyö" kuten Teikari esittää? Mielestäni ei. Projektin aikana käytäviä neuvotteluja varten tarvitaan työkalu, jolla sekä tilaa-ja 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 ennak-

komää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 laa-

juuden 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ösuojelu-

valvonnan tietojärjestelmän kaksi ensimmäistä toimitusprojektia ovat tässä joukossa toimitustehokkuudeltaan kaksi parasta.

FiSMA 2012 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 2012 11

Toimintoluokat ja toimintotyypit

FiSMA 2012 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 2012 13

FiSMA 1.1 käytännössä – laajuuden arvioinnista

mittaamiseen

Toimintojen kuvaukset Laatu- vaatimukset Tekniset vaatimukset

Kuva- ruutu- ja raportti- mallit

ohjelmakoodi Lopullinen dokumentaatio Käyttöohjeet

Ohjelmisto tuotannossa

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 Prosessi- kaaviot

FiSMA 2012 14

Arviot kehittämisen elinkaaren aikana

Alun ”virhe”-% riippuu n.

90% vaatimusten epä-

tarkkuudesta ja < 10 %

FiSMA 1.1 mittaus-

tarkkuudesta

Alun virhe-% on

harvoin yli 30 %

FiSMA 2012 15

Tuumasta toimeen – omien prosessien parantamiseen

FiSMA 2012 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: pekka.forselius@fisma.fi

Katso myös www.fisma.fi ja www.4sumpartners.com