SFS-ISO/IEC 29881 -standardiOhjelmiston toiminnallisen

laajuuden mittaaminen

FiSMA 1.1 menetelmä kansallisena ja kansainvälisenä standardina

Tervetuloa luentoaineiston käyttäjäksi!

Tämän luentoaineiston on laatinut FM Pekka Forselius FiSMA ry:stä. Kalvosarja on tuotettu SFS:n projektirahoituksella.

Aineisto on suunnattu ammattikorkeakoulujen ja yliopistojen opettajille ja opiskelijoille. Kalvosarja esittelee ohjelmiston laajuuden mittaamisen taustan ja tarkoituksen sekä FiSMA 1.1 mittausprosessin yksityiskohtaisine laskentasääntöineen.

Kalvosarjan tavoitteena on rohkaista kaikkia ohjelmistoja teettäviä ja tekeviä asiantuntijoita hyödyntämään toiminnallisen laajuuden mittaamista. Keskeiset hyödyntämisalueet ovat ohjelmistohankinnan budjetointi, ohjelmistokehittämisen työmäärän arviointi (estimointi) ja ohjelmistoprojektin toteutuneen tuottavuuden arviointi (evaluointi ja benchmarking).

03.05.23 | 2

Aineiston käyttö ja tekijänoikeudet

• Tämän luentoaineiston tekijänoikeudet omistaa Suomen Standardisoimisliitto SFS ry.

• Esitystä saa vapaasti käyttää opetustarkoituksiin ja sitä saa tarvittaessa muokata. Aineistoa lainattaessa lähde tulee mainita.

• Aineiston käyttö kaupallisiin tarkoituksiin on kielletty.

• Tämä materiaali on päivitetty viimeksi 10.3.2016.

03.05.23 | 3

Sisältö

• Toiminnallisen laajuuden mittaamisen (FSM) standardien ja mallien kokonaisuus

• FiSMA 1.1 menetelmän kehityshistoriasta• Laajuuden mittaamisen tarkoitus ja mittarit• FiSMA 1.1 toimintoluokat ja toimintotyypit• FiSMA 1.1 mittausprosessi• Laajuuden mittaamisen tarkkuustasot• Vaatimukset mittaamisen lähtöaineistolle• Esimerkkejä mittausharjoituksia varten• Kokemuksia standardin käytöstä

03.05.23 | 4

Toiminnallisen laajuuden mittaamisen standardien ja

mallien kokonaisuus• Säännöt mittaamismenetelmille – 14143-sarja

– Osa 1 sisältää suuntaviivat ja määritelmät– Osat 2-5: ohjeita FSM-menetelmien kehittäjille– Osa 6 on yhteenveto muiden 14143 osien ja

menetelmästandardien tarkoituksista• Nykyiset ISO/IEC menetelmästandardit ohjelmiston

toiminnallisen laajuuden mittaamiseen– FiSMA (ISO/IEC 29881:2010) Suomi, FiSMA ry– IFPUG (ISO/IEC 20926) USA, IFPUG– Nesma (ISO/IEC 24570) Alankomaat, Nesma– COSMIC (ISO/IEC 19761) COSMIC consortium– Mark 2 (ISO/IEC 20968) Iso-Britannia, UKSMA

03.05.23 | 5

Yleiskuva laajuuden mittaamisen standardeista (lähde: 14143-6)

03.05.23 | 6

FiSMA 1.1 menetelmän käyttäjän näkökulmasta tarpeelliset osat

03.05.23 | 7

FiSMA 1.1 menetelmän kehityshistoriasta

• Kehitys aloitettiin jo 1990 Tieken projektissa

• Syynä tyytymättömyys IFPUG-menetelmään

• FiSMA 1.1 tunnettiin alkuvuosina nimillä Laturi ja Experience

• Nykyinen, portaaton menetelmä valmistui 2004

• ISO-standardiksi PAS-hakemuksen kautta 2008

• Nykyiseen versioon ei tiedossa korjaustarvetta; viimeisin tarkistuskierros tehtiin vuonna 2015 03.05.23 |

8

FiSMA 1.1 menetelmästandardin sisältö

1. Soveltamisala (Scope)2. Velvoittavat viittaukset3. Termit ja määritelmät4. FiSMA 1.1 menetelmän toimintoluokat ja toimintotyypit5. FiSMA1.1-mittausprosessi6. Toimintoluokkien laskentasäännöt7. Toiminnallisen laajuuden mittayksikkö8. Ohjelmiston toiminnallisen kokonaislaajuuden

laskeminen FiSMA 1.1 –menetelmällä9. Mittaustulosten raportointi10.FiSMA 1.1 -menetelmän muunnettavuus muihin

toiminnallisen laajuuden mittausmenetelmiin

03.05.23 | 9

Ohjelmiston toiminnallisuuden käsite

• Ohjelmiston toiminnallisuudella tarkoitetaan niitä käyttäjän tilaamia palveluita, jotka ohjelmisto käyttäjälle tuottaa.

• Toiminnallisuus perustuu VAIN siihen MITÄ ohjelmisto tekee, EI siihen MITEN se sen tekee.

• Mitä useampia erilaisia palveluita ohjelmisto tuottaa, sitä laajempi se toiminnallisesti on. Jokaisen uuden toiminnon lisääminen kasvattaa ohjelmiston kokoa.

• Toiminnallinen laajuus voidaan ilmaista yhtenä numeerisena arvona.

• Laajuuden mittayksikkö on TOIMIN-TOPISTE, lyhenne FP (Function Point)

03.05.23 | 10

03.05.23 | 11

Laajuuden mittaamisen tarkoitus

• Ohjelmiston koolla on väliä!

• Ison ohjelmiston kehittäminen maksaa enemmän ja vaatii enemmän työtä kuin pienen ohjelmiston.

• Laajuuden avulla voidaan suhteuttaa muita ohjelmiston tunnuslukuja.

03.05.23 | 12

Laajuuden mittaaminen ja mittarit• Ohjelmiston laajuus voidaan määrittää missä ohjelmiston

elinkaaren vaiheessa tahansa. Mitä aikaisempi vaihe, sitä epätarkempi mittaustulos.

• Ohjelmiston kehittämisen aikana pitäisi puhua arvioidusta laajuudesta.

• Ohjelmiston käyttöönottohetkellä ja siitä eteenpäin voidaan puhua mitatusta laajuudesta.

• Mittarit vaihtelevat käyttäjän ja käyttötarkoituksen mukana. Edellisen kuvan tapaisiin tarkoituksiin sopisivat esim. €/FP, h/FP, FP/kalenterikuukausi, virhettä/1000 FP/vuosi, toteutunut FP/arvioitu FP, valmisosilla tuotettu FP/kokonais FP, jne.

03.05.23 | 13

FiSMA 1.1 toimintoluokat

1. vuorovaikutteiset navigointi- ja kyselytoiminnot (q)2. vuorovaikutteiset syöttötoiminnot (i)3. yksisuuntaiset tulostetoiminnot (o)4. lähetettävät liittymätoiminnot (t)5. vastaanotettavat liittymätoiminnot (f)6. tiedonvarastointitoiminnot (d)7. algoritmiset toiminnot ja käsittelytoiminnot (a)

FiSMA 1.1 menetelmä tarkastelee ohjelmiston tuottamia palveluita seitsemän toimintoluokan kautta. Jokaisessa ohjelmistossa on vähintään yhteen luokkaan kuuluvaa toiminnallisuutta.

Kukin toiminto voi kuulua vain yhteen luokkaan. Esim. jos näytön kautta voi tallentaa tietoa järjestelmään, se on vuorovaikutteinen syöttönäyttö, ei kyselytoiminto.

03.05.23 | 14

FiSMA 1.1 toimintotyypit• Kukin toiminto-luokka

jakautuu toimintotyyppeihin.

• Jokainen toiminto-tyyppi on määritelty SFS-ISO 29881:ssä.

• Esim.: Lähetettävät sanomat ovat toimintoja, joissa tietojoukkoja lähetetään verkon kautta toiseen sovellukseen (yleensä reaaliajassa)

• Toimintopiste-määrän laskennan kannalta oikean luokan löytäminen on tärkeämpää kuin tarkan tyypin.

03.05.23 | 15

FiSMA 1.1 mittausprosessi

03.05.23 | 16

Mittaaminen käytännössä1. Etsi käytettävissä olevista ohjelmiston kuvauksista eri

toimintoluokkiin/-tyyppeihin kuuluvat toiminnot.2. Laske kunkin toimintotyypin esiintymien lukumäärät.3. Nimeä kaikki löytämäsi toiminnot luetteloon.4. Arvioi tai laske kunkin nimetyn toiminnon

tietoelementtien ja tarvittavien luku- ja/tai kirjoitusviittausten määrät.

5. Laske kunkin toiminnon laajuus toimintopisteinä käyttäen kyseisen toimintoluokan laskentakaavaa.

6. Laske toimintojen laajuudet yhteen. Näin olet saanut koko ohjelmiston toiminnallisen laajuuden (FP).

16

03.05.23 | 17

Laajuuden mittaamisen tarkkuustasot

• Alussa voidaan käyttää SUPER-NOPEAa arviota

• Valittaessa toimittajaa tarvitaan NOPEA arvio

• Kun osa järjestelmästä on valmistunut, voidaan tehdä TARKKA mittaus

• Kun kaikki on valmiina, on mahdollista tuottaa SUPER-TARKKA mitta tehdyn ohjelmiston laajuudelle.

03.05.23 | 18

Vaatimukset mittaamisen lähtöaineistolle

• Ohjelmistokehityksen käynnistämisvaiheessa tarvitaan mitattavan ohjelmiston(-osan) käyttötilanteiden kuvaukset ja käsitemalli. Liiketoimintaprosessikaavioista ja alustavasta toimintoluettelosta on myös apua.

• Toimittajan valintahetkellä tarvitaan edellä luetellut kuvaukset tarkennettuina ja järjestelmätoimintojen alustavia kuvauksia siltä osin kuin pystytään tuottamaan. Yleensä ainakin ensimmäisten iteraatioiden aikana toteutettavat osat.

• Toimituserän hyväksymisen yhteydessä valmistuneiden toimintojen tarkat kuvaukset (esim. kuvaruutukaappaukset, tietuekuvaukset, käsittelysäännöt, tietomalli) ja seuraavien iteraatioiden aikana toteutettavien järjestelmätoimintojen alustavat kuvaukset.

• Toimitusprojektin päättyessä kaikkien valmistuneiden toimintojen tarkat kuvaukset.

03.05.23 | 19

Yksittäisen toiminnon laajuuden mittaaminen

• Jokaisella toimintoluokalla on oma toiminnallisen laajuuden laskentakaavansa. Kaavat noudattavat perusmuotoa:

Laajuus = perustamisvakio + tietoelementtien lkm / luokan tietoelementtivakio + viittausten lkm / luokan viittausvakio.

• Koska eri toimintotyypeissä viittaukset käsitteisiin vaihtelevat tai puuttuvat kokonaan, voivat kunkin toimintoluokan laskentakaavat erota hieman perusmuodosta ja toisistaan. Tarkat kaavat on esitetty standardin kohdassa 6.

• Kaikki samaan toimintoluokkaan kuuluvat toimintotyypit noudattavat samaa laskentakaavaa samoin vakioin.

• Laajuuden määrittämisessä tarvittavat parametrit ovat:–Tietoelementtien lkm (kaikilla toimintoluokilla)–Lukuviittausten lkm (kaikilla paitsi tietovarastointi ja algoritmiset)–Kirjoitusvittausten lkm (vain syöttötoiminnot ja vastaanotettavat liittymät)–Operaatioiden lkm (vain algoritmiset ja käsittelytoiminnot)

03.05.23 | 20

Esimerkki 1 mittausharjoituksia varten

• Kuvassa on pankkitoimintaan liittyvä käsitemalli.

• Yhden käsitteen keskimääräinen attribuuttien lukumäärä on 10.

• Kuinka suuri on koko käsitemallin tuottama toiminnallinen laajuus?

03.05.23 | 21

Esimerkki 1 vastaus• Kuvan

käsitemallissa on 12 käsitettä.

• Yhden käsitteen laajuus lasketaan kaavalla S = 1,5 + 10/4 = 4,0

FP• Koko käsitemallin

laajuus on S = 12 * 4,0 = 48 FP

03.05.23 | 22

Esimerkki 2 mittausharjoituksia varten

• Minkä tyyppinen toiminto on kuvassa?

• Montako tietoelementtiä toiminnossa on?

• Kun tiedämme että kyseiseen toimintoon luetaan tietoja kahdesta käsitteestä (1. = käyttäjä ja 2. = järjestelmäparametrit), mikä on toiminnon toiminnallinen laajuus?

03.05.23 | 23

Esimerkki 2 vastaukset• Kuvassa on

vuorovaikutteisiin navigointi- ja kyselytoimintoihin kuuluva kirjautumistoiminto (sisäänkirjautumisnäyttö).

• Tietoelementtejä on 8 kpl• Näytön toiminnallinen

laajuus on standardin kohdassa 6.1 esitetyn kaavan mukaisesti:0,2 + 8/7 + 2/2 = 2,3 FP

03.05.23 | 24

Esimerkki 3 mittausharjoituksia varten

• Ohessa on pienen ohjelmiston näyttö-kartta.

• Laske erityyppisten näyttöjen lukumäärät.

• Käytä navigointi- ja kyselytoimintojen oletusarvoina 20 tieto-elementtiä ja 3 lukuviittausta sekä syöttötoiminnoilla 15 tietoelementtiä, 2 luku- ja 1 kirjoitusviittaus.

• Laske käyttöliittymän toiminnallinen laajuus.

03.05.23 | 25

Esimerkki 3 vastaus• Tarkemman tiedon puuttuessa

oletamme että kartasta löydetyt 4 ei-päivittävää näyttöä ovat kaikki kyselynäyttöjä.

• Kartasta löytyneiden 4:n syöttönäytön oletamme olevan 2-toimisia (muutos ja luonti).

• Kyselynäytön laajuudeksi saamme:0,2 + 20/7 + 3/2 = 4,6 FP

• Syöttönäytön laajuudeksi:2*(0,2 + 15/5 + 1/1,5 + 2/2) = 9,7 FP•Käyttöliittymän kokonaislaajuus:4*4,6 + 4*9,7 = 57,2 FP

03.05.23 | 26

Kokemuksia standardin käytöstä• Suomessa on 124 sertifioitua Scope Manageria, jotka kaikki ovat

tutustuneet menetelmään ja osa käyttää säännöllisesti FiSMA 1.1 menetelmää Experience® Service ohjelmiston tuella.

• Tunnetuimpia ostajaorganisaatioita, joissa standardia on sovellettu menestyksellisesti, ovat oikeusministeriö ja sosiaali- ja terveysministeriön työsuojeluhallinto.

• Toimittajaorganisaatioista mm. vakuutusalalla toiminut Tieto-konsernin TKP Tieto hyödynsi menetelmää laajasti.

• 4SUM Partners Oy käytti FiSMA 1.1 menetelmää omassa Experience® Service tuotekehityshankkeessaan vuosina 2012-2013.

• FiSMA ry:n piirissä tehtiin kesällä ja syksyllä 2013 lukuisia menetelmän nopeustestejä, joiden tulokset olivat vakuuttavia: kun erilaisten toimintojen lukumäärät tiedettiin, itse toiminnallisen laajuuden mittaamiseen kului keskimäärin vain 2 minuuttia.

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.

Lisätietoa standardeista

• Ohjelmistojen toiminnallisen laajuuden mittaamiseen liittyvistä standardeista vastaa kansainvälinen alakomitea ISO/IEC JTC 1/SC 7, erityisesti sen työryhmä 6 (Software Product and System Quality). Moni muukin JTC 1:n työryhmä on mukana ohjelmistojen ja järjestelmien standardien laadinnassa. Hae lisätietoja www.sfs.fi.

• Suomen osalta FiSMA ry (Finnish Software Measurement Association) seuraa SC 7 -alakomitean ja sen työryhmien työtä ja laatii kansallisia kannanottoja. Hae lisätietoja www.fisma.fi.

03.05.23 | 28