Toteutuksen luotettavuusanalyysi

Deduktiivinen tapahtumaketju, jonka lähtökohtana ovat vaatimusten määrittelyssä tun-nistetut mahdolliset virhetoiminnot ja joka täydentyy arkkitehtuurisuunnittelussa ja de-taljisuunnittelussa, päättyy toteutuksen tarkastelussa. Kaikissa edeltävissä vaiheissa, kuten myös toteutuksen analyysivaiheessa, luotettavuusanalyysi kelpoistaa ohjelmiston luotettavuusvaatimukset, mitä osaltaan tukevat erillisenä toimenpiteenä myös oikeelli-suuden todennukset. Aikaisemmissa analyyseissa kelpoistamistoimen ohessa pääpaino on ollut ohjelmistoprosessien ja analyysien ohjaamisessa. Ohjaava vaikutus on ollut suurimmillaan määrittelyn analyysivaiheessa ja vähentyy asteittain jälkimmäisissä vai-heissa. Toteutuksen analyysivaiheen tuloksena suositellaan etenkin dynaamisia tai ra-kenteellisia testejä sekä tietyin edellytyksin palaamista edeltäviin luotettavuusanalyy-seihin.

Toteutuksessa tarkasteluiden oikeellisuuden todentaminen on tärkeämpää kuin mahdol-listen uusien vaaratekijöiden tarkastelu, jos aikaisemmat kolme luotettavuusanalyysia on tehty riittävän perusteellisesti.

Yleiskäyttöiset riskianalyysitekniikat ohjelmiston FTA ja FMECA soveltuvat myös läh-dekielisen koodin analysointiin. Erityisesti Leveson [& Harvey 1983, 1991, 1995] on kehittänyt vikapuutekniikkaa, joka perustuu eräiden rakenteellisten ohjelmakielten, ni-mittäin Pascalin ja Adan, käskykohtaisille mini-vikapuille (ks. luku 5). Muille kuin ra-kenteellisille ohjelmakielille, esimerkiksi C-kielelle, menetelmää ei ole tiettävästi so-vellettu mini-vikapuiden kehittämishankaluuden takia. Myös ohjelmiston FMECA ei ole erityisessä koodintarkastajien suosiossa. Vaikka tiedettäisiinkin erityiset tarkastelu-kohdat ohjelmassa, seurausvaikutusten sekä havainto- ja estomekanismien tunnistami-nen on työlästä, sillä tarkastelutaso on syvällä koodin sisällä, josta on lähes mahdotonta nähdä ohjelmistoa kokonaisuutena. Näitä kahta tekniikkaa suositeltavampia ovat staatti-set analyysit, mm. saavutettavuusanalysaattorit ja koodintarkastukstaatti-set.

Tässä toteutusvaiheen luotettavuusanalyysi jatkaa pääpiirteissään myös samaa menet-telyä, jota aikaisemmatkin analysoinnit noudattavat. Tavoitteena on ollut kehittää me-nettelytapa, joka karsii ohjelmiston FMECA- ja FTA-tekniikoiden työläät ominaisuudet ja yhdistää menettelyn ohjelmistotuotannon tarkastus- ja katselmointiprosesseihin. Sa-maa edellisten analyysien kanssa ovat jossakin määrin avainlauseiden sekä mahdollisten uusien ominaisuuksien ja niiden seurausvaikutusten tunnistamiset. Lisäksi, samoin kuin aikaisemmissakin analyyseissa, estimoidaan tapahtumaketjun tietyn kohdan riskinsuu-ruus toteutusvaiheen jälkeen.

Toteutusvaiheessa luotettavuusanalyysi eroaa edellisistä lähinnä siinä, että pääpaino ei ole avainlauseprosessilla, vaan analyysi noudattaa tarkistuslistamenettelyä (luku 5) tai yhdistyy suoraan lähdekielisen koodin tarkistuksiin. Tarkistuslistat koostuvat mm. oh-jelmakielen toteutussäännöistä. Lisäpiirteitä tarkistuksiin tuovat luotettavuusanalyysien aikaisempien vaiheiden tulosten hyödyntämiset. Niiden ja jäljitettävyysmatriisin perus-teella tiedetään tarkasti, mitä kohtia lähdekoodista tarkastellaan, sekä lisäksi, mitä asioita niissä käydään läpi. Koko vikatapahtumaketju ylhäältä seurauksista määrittelyn, arkkitehtuurin ja suunnittelun kautta fokusoituu tiettyihin proseduureihin, funktioihin, aliohjelmiin tai yksittäisiin käskyihin tai niiden tiettyihin kokonaisuuksiin lähdekielises-sä ohjelmakoodissa.

Aikaisempien luotettavuusanalyysien tulokset viestivät kriittiset tapahtumaketjut lähtien kunkin ketjun loppupäästä eli seurauksista. Alkupään muodostavat alkutapahtumat, jot-ka tapahtumaketju kokoaa pitkin ohjelmistotuotannon elinjot-kaarivaiheita eri luotettavuus-analyyseissa. Ohjelmistovirheet ovat ensi sijassa suunnitteluvirheitä sisältyen lopulli-seen ohjelmakoodiin. Koska niiden syntylähde voi olla esimerkiksi vaatimusten

määrit-telyssä, niitä ei välttämättä voida tunnistaa ohjelmakoodista. Määrittelyvirheitä ei myöskään aina kyetä tunnistamaan määrittelyvaiheen aikana, vaan myöhemmistä tar-kastelujaksoista tai testauksista saadaan viitteitä mahdollisista määrittelyvirheistä.

Alkutapahtumat eivät kuitenkaan koostu virheistä, jotka on koottu elinkaaren vaiheista, sillä todetut todelliset virheet poistetaan sitä mukaa, kun ne on tunnistettu. Alkutapah-tumat koostuvat mahdollisista virheistä, joiden olemassaolo on tarkoitus tarkistaa joko jo heti kyseisen tarkasteluvaiheen aikana tai myöhemmissä testauksissa ja tarkistuksissa.

Toteutusvaiheen luotettavuusanalyysiin kohdistuvat siis aikaisempien luotettavuusana-lyysien tulokset, joiden kriittisyystasot ilmaistaan luotettavuusprofiililla. Profiilissa ovat mukana kaikki käsiteltävät luotettavuusattribuutit, ja ne myös kohdentavat toteutuksen tarkastelua mm. sopivien avainlauseiden valitsemiseksi. Kuten edellä jo todettiin, luo-tettavuusanalyysi perustuu toteutusvaiheessakin avainlauseiden käyttöön, mutta nämä ovat nyt hyvin sovelluskohtaisia. Normaalit tarkistuslistat ja ohjelmointisäännöt ovat myös hyviä perusteita vioittumistapojen valinnoille.

Seuraavaa aineisto tarvitaan toteutusvaiheen luotettavuusanalyysissa:

− alustava kriittisyyslista

− luotettavuusprofiili suunnitteluvaiheen jälkeen

− kaikki edeltävät luotettavuusanalyysin tulokset

− edeltävät luotettavuusanalyysien tarkasteluaineistot (mm. ohjelmiston toi-minnallinen vaatimusmäärittely, ohjelmiston arkkitehtuuri- ja moduulisuun-nittelukuvaukset)

− jäljitettävyysmatriisi suunnittelukuvauksista lähdeohjelman koodikohtiin ja takaisin suunnitteluun

− lähdekielinen koodi.

Toteutusvaiheen Stérna-tulosdokumentaatio sisältää analyysien tulokset.

Toteutuksen luotettavuusanalyysi noudattaa seuraavia askeleita:

1. Tunnistetaan tarkasteltavat kohdat ja asiat lähdekielisestä ohjelmakoodista edellisten analyysien tuloksista.

2. Tarkistetaan tunnistettujen ohjelmakoodin osien oikeellisuus ja täydellisyys.

3. Tunnistetaan mahdollisia virhetilanteita avainlauseiden avulla (taulukko 19).

4. Tarkastellaan mahdollisten yhteisvikojen esiintymistä.

5. Varmistaudutaan siitä, että lähdekoodi on riittävästi dokumentoitu.

6. Varmistutaan testien riittävyydestä, sekä suositellaan lisätarkasteluja.

7. Varmistaudutaan siitä, että kriittisten vaatimusten testikattavuus on riittävä.

8. Päivitetään käyttöoppaan ja muiden asianomaisten dokumenttien tietoja.

9. Dokumentoidaan analyysin tulokset.

10. Käsitellään analyysivaiheen tulokset vastaavissa toteutusvaiheen katselmuk-sissa.

Ensimmäisessä tunnistetaan ja valitaan edellisen analyysin tuloksista tarkasteltavat koo-dinosat ja tapahtumat, jotka seuraavassa vaiheessa tarkistetaan. Suositeltavin tekniikka on yksinkertainen kvalitatiivinen ohjelmiston vikapuuanalyysi (ks. luku 5). Mahdolli-sesti suunnittelun luotettavuusanalyysia joudutaan päivittämään tai löydetään uusia ris-kejä, jolloin mahdollisesti uusitaan kaikki edelliset analyysit asiaankuuluvilta osilta. Jos resurssit ovat riittämättömiä, kannattaa keskittyä joko riskitasoltaan korkeimpiin osiin tai perussysteemin toimintoihin.

Toisessa askeleessa varmistutaan siitä, että lähdekielinen ohjelma on koodattu ainakin laatukriteereiden oikeellisuuden ja täydellisyyden edellyttämällä tavalla edellisten luo-tettavuuden analyysitulosten ja -suositusten perusteella.

Kolmannessa askeleessa ohjelmaa tarkastellaan avainsanoilla esimerkiksi taulukon 19 tukemana. Tunnistetaan mahdolliset kriittiset tilat, jotka johtuvat syötteet/tulosteet-ajastuksesta, lukkiutumista, vääristä tapahtumista tai laitteiston vikaherkkyydestä.

Neljännessä askeleessa keskitytään yhteisvikatarkasteluun tunnistamalla riskialttiita ohjelmointisääntöjä sekä työkalujen käyttösääntöjä ja käyttöjärjestelmistä riskitekijät, mm. riskitoiminnot. Seuraavassa askeleessa tarkistetaan dokumentoinnin riittävyys ja ymmärrettävyys.

Kuudennessa askeleessa tarkistetaan, että kriittisten kohtien rakenteelliset ja toiminnal-liset testit ovat riittäviä. Suositetaan tarpeen vaatiessa testitapauksia ja lisätarkastuksia jollakin soveliaalla tarkastustekniikalla (luku 5). Askeleessa seitsemän suositetaan käyttöoppaaseen täydentäviä ohjeita kriittisten vaatimusten osalta. Kahdeksannessa as-keleessa tulokset dokumentoidaan.

Tarkasteluiden tuloksena (askel 9) voidaan päätyä lisätarkasteluiden suosittamiseen esimerkiksi siksi, etteivät käytetyt tekniikat ole riittäviä tietyssä kriittisyystasossa tai tarkastelukohde on niin kompleksinen, että tarvitaan kohdennettuja black- tai white-box-testejä siitä selviytymiseen.