Tarkvarasüsteemi ohutus

Mida teha tarkvarasüsteemide ohutuse suurendamiseks?

Põhiline on parandada programmeerijal iseenda tööd ning olla teadlik, et programmeerimisel tehakse tavaliselt palju vigu. Neid esineb ka suurte ning tähtsate süsteemide seas, mis mõnevõrra juba testitud võivad kellegi poolt olla. Inglismaa kaitseministeeriumi uuring näiteks selgitas välja, et isegi juba kasutusel olnud sõjaväe relvade ja masinate juhtsüsteemides, esines siiski ikka vigu, mis oleks suutnud kaks maksimaalset äärmust ära vahetada. 
Samuti tuleb arendajatel pidevalt endale meelde tuletada, kui katastroofilised võivad mõne juhtprogrammi vead olla ja vajalikul määral ka ohutusele tähelepanu pöörata, kuigi funktsionaalsus tundub lõpuks olevat see mida müüakse. Inglismaal kehtib EL-i masinaohutusdirektiivil põhinev seadus, mis määrab, et firma direktor või osakonnajuht, kes on hooletusse jätnud ohutuse tagamise masina disainil või ehitusel, mis põhjustab vigastusi, võidakse vastva õnnetuse põhjustamise eest kriminaalvastutusele võtta.
On küll mitmeid nii tegevusalade kui üldisi (IEEE STD 1228–1994 Software Safety Plans) tarkvara ohutust tagada püüdvaid tegevusjuhiseid, kuid on need enamuses ainult väga üldised meetodite kirjeldused. Tähtis on, et ohutuskriitilistes süsteemides oleks ohutuse pool kohe algusest sisse projekteeritud ning ehitatud põhiosa, mitte eraldi lisatud funktsioon ning et selle täideviimist pidevalt jälgitaks ja juhitaks mõne eraldi kõrgemal positsioonil oleva isiku poolt. Et tellijal oleks toodete talitlusest pidev ülevaade ning et ka tema vastutaks vigade tekkimise korral, sest klient teab võimalikke ohusituatsioone ja vigu paremini. Siin on oluline ka korraliku tegelikkusele vastava dokumentatsiooni loomine arendusprotsessi käigus, et klient saaks õigesti asjadest aru. Therac-25-l loodi ka korraliku mahuga dokumentatsioon, kuid ülevaatamisel selgus, et see oli vaid n-ö ilus jutt. 
Samuti pole hea, kui minnakse kogu süsteemi koondamise teed, nagu antud kiiritusravimasinal ning kogu tavaline mitmetahuline kontrollsüsteem on usaldatud vaid ühe arvuti hoolde. See toob kaasa oluliselt suurema riski, sest kui mingis väikses osas tekib tõrge, siis kantakse see sealt kogu süsteemile üle. See rikub ohutustehnika (safety engineering) põhimõtteid, millega peaks ka ohutuskriitiliste süsteemide tarkvara insener tuttav olema, kuid pahatihti see nii pole.
Kõikides teistes inseneriteaduste harudes vaatab ja kontrollib kõik plaanid ja tööd eraldi veel kord üle suurte kogemustega vaneminsener, nii peaks see ka olema tarkvaraarenduses. On arutletud ka selle üle, et kõik insenerid peavad olema läbinud oma ameti kutsekvalfikatsiooni eksamid, et ehk peaks see olema nii ka tarkvaratehnikutel, kes ennast insenerideks peavad.

Formaalsed meetodid

Kui üldiselt on tarkvara ohutuse ala alles arengu algusfaasis ning pole väljatöötatud meetmeid, mis suudaks suure tõenäosusega ohutuse tagada, siis on siiski üks laiemalt levinud ja tunnustust leidnud tehnikate kogum – formaalsed meetodid. See sisaldab meetodeid nagu B-method, Lustre, Abstract State Macine jne. Need kõik on mõnevõrra varieeruvad oma käsitlusviisidelt ja lõppeesmärkide osas. Ühine on neil see, et juba programmi spetsifikatsioon kirjutatakse üles matemaatika ning loogika tehteid kasutades ning üritatakse selle põhjal siis analüüsides väljaselgitada kõikvõimalikud programmi käitumisviisid, programmeerimisel lähtutakse ja kasutatakse spetsifikatsiooni osasid ning lõpus võrreldakse programmi ning spetsifikatsioonide põhjal koostatud lõpptulemusi. Formaalsete meetodite kasutamine on äärmiselt kallis ning selle vastaste arvates ei anna vajalikku tulemust. Samas järjest enam nõutakse seda suuremate ohutuskriitiliste süsteemide korral (näiteks lennunduses), sest see suudab parandada arusaamist programmi tööst, enam ei selgu programmi käitumine arendamise lõppjärgus testimise käigus ning ühtlasi sunnib kasutama lihtsamaid/arusaadavamaid osi.