Transcript ISO/IEC 29881

OPPILAITOSPORTAALI
SFS-ISO/IEC 29881 -standardi
Ohjelmiston 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).
8.4.2015 | 3
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
17.12.2013.
8.4.2015 | 4
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ä
8.4.2015 | 5
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
8.4.2015 | 6
Yleiskuva laajuuden mittaamisen
standardeista (lähde: 14143-6)
8.4.2015 | 7
FiSMA 1.1 menetelmän käyttäjän
näkökulmasta tarpeelliset osat
8.4.2015 | 8
FiSMA 1.1 menetelmän kehityshistoriasta
• Menetelmä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 PAShakemuksen kautta 2008
• Nykyiseen versioon ei
tiedossa korjaustarvetta
8.4.2015 | 9
FiSMA 1.1 menetelmästandardin sisältö
1.
2.
3.
4.
5.
6.
7.
8.
Soveltamisala (Scope)
Velvoittavat viittaukset
Termit ja määritelmät
FiSMA 1.1 menetelmän toimintoluokat ja toimintotyypit
FiSMA1.1-mittausprosessi
Toimintoluokkien laskentasäännöt
Toiminnallisen laajuuden mittayksikkö
Ohjelmiston toiminnallisen kokonaislaajuuden
laskeminen FiSMA 1.1 –menetelmällä
9. Mittaustulosten raportointi
10.FiSMA 1.1 -menetelmän muunnettavuus muihin
toiminnallisen laajuuden mittausmenetelmiin
8.4.2015 | 10
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 TOIMINTOPISTE, lyhenne FP (Function Point)
8.4.2015 | 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.
8.4.2015 | 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.
8.4.2015 | 13
FiSMA 1.1 toimintoluokat
FiSMA 1.1 menetelmä tarkastelee ohjelmiston tuottamia
palveluita seitsemän toimintoluokan kautta. Jokaisessa
ohjelmistossa on vähintään yhteen luokkaan kuuluvaa
toiminnallisuutta.
1.
2.
3.
4.
5.
6.
7.
vuorovaikutteiset navigointi- ja kyselytoiminnot (q)
vuorovaikutteiset syöttötoiminnot (i)
yksisuuntaiset tulostetoiminnot (o)
lähetettävät liittymätoiminnot (t)
vastaanotettavat liittymätoiminnot (f)
tiedonvarastointitoiminnot (d)
algoritmiset toiminnot ja käsittelytoiminnot (a)
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.
8.4.2015 | 14
FiSMA 1.1 toimintotyypit
• Kukin toimintoluokka jakautuu
toimintotyyppeihin.
• Jokainen toimintotyyppi 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)
• Toimintopistemäärän laskennan
kannalta oikean
luokan löytäminen
on tärkeämpää kuin
tarkan tyypin.
8.4.2015 | 15
FiSMA 1.1 mittausprosessi
8.4.2015 | 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).
17
8.4.2015 | 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.
8.4.2015 | 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.
8.4.2015 | 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)
8.4.2015 | 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?
8.4.2015 | 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
8.4.2015 | 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?
8.4.2015 | 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
8.4.2015 | 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 tietoelementtiä ja 3
lukuviittausta sekä
syöttötoiminnoilla 15
tietoelementtiä, 2 lukuja 1 kirjoitusviittaus.
• Laske käyttöliittymän
toiminnallinen laajuus.
8.4.2015 | 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 2toimisia (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
8.4.2015 | 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 sosiaalija terveysministeriön työsuojeluhallinto.
• Toimittajaorganisaatioista mm. vakuutusalalla toiminut Tietokonsernin TKP Tieto hyödynsi menetelmää laajasti.
• 4SUM Partners Oy käytti FiSMA 1.1 menetelmää omassa
Experience® Service tuotekehityshankkeessaan vuosina 20122013.
• 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.
8.4.2015 | 27
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 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.
Lisätietoa standardeista
• Ohjelmistojen toiminnallisen laajuuden mittaamiseen
liittyvistä standardeista vastaa kansainvälinen ISO/IEC
JTC 1/SC7 – alikomitea, erityisesti sen työryhmä 6 (WG
6 IT Product Quality). Moni muukin JTC1: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 SC7 – alikomitean ja
sen työryhmien työtä ja laatii kansallisia kannanottoja.
Hae lisätietoja www.fisma.fi.
8.4.2015 | 29