Wikipediaan on ilmestynyt artikkeli Kalle Kotipsykiatrista, Commodore 64:ssä 1980-luvulla toimineesta mainiosta keskusteluohjelmasta. En muistanutkaan, että ohjelman oli kirjoittanut Jyrki J. J. Kasvi.
Ah, nostalgiaa... Olin nimittäin yksi artikkelissa mainituista MikroBitin toimituksen rikkoman Kallen korjaajista. Korjasin muistaakseni ainakin lauseiden muuntamisen minämuotoisista sinämuotoisiksi tyyliin ”Minulla on ongelma.” ”Miksi sanot, että sinulla on ongelma?”, joten tämä oli kaikkien aikojen ensimmäinen kieliteknologiaohjelmointityöni.
Hajahuomioita tuotekehityksen parantamisesta, ohjelmistotuotannosta, lääkintälaitteiden kehittämisestä ja muistakin aiheista vuosina 2006–2015.
27.1.2007
26.1.2007
Ohjelmistotuotantoblogi ryhmätyönä?
Nimimerkki Teme ehdotti ryhmätyönä kirjoitettavan ohjelmistotuotantoblogin perustamista. Olisikohan sellaiselle sosiaalista tilausta? Ja olisiko suomalaisessa blogosfäärissä (tulipa tuokin sana kerran kirjoitettua) tarpeeksi kirjoittajia tällaiseen hankkeeseen? Vaikka ehkä kaikki haluavat säästää nerokkaimmat ideat omiin julkaisuihinsa.
18.1.2007
IEC 62304 tulee
Lueskelen taas standardia IEC 62304: Medical device software – Software life cycle processes. Standardissa kuvataan, millaista lääketieteellisten laitteiden ohjelmistokehityksen, testauksen, ylläpidon, riskinhallinnan, konfiguraationhallinnan jne. tulisi olla potilasturvallisuuden takaamiseksi.
Suurin uutuus tässä standardissa lienee ohjelmiston ja sen osien jakaminen turvaluokkiin A, B ja C sen mukaan, millaisia seurauksia ohjelmiston viasta voi olla potilaan terveydelle. Vähemmän vaaralliset osat voidaan sitten dokumentoida ja testata hieman kevyemmin. C-luokassa pitää jo miettiä sitäkin, voisiko riskejä pienentää jakamalla ohjelmisto pyörimään eri suorittimille.
Alan standardit ovat menossa yksityiskohtaisempaan suuntaan, mutta taataanko tiptop-kunnossa olevalla prosessilla turvallisuus? Olennaista on myös tuotteen kehittäjien ja projektinjohdon ammattitaito ja asenne turvallisuutta kohtaan, mutta niitä olisikin jo vaikeampi standardoida.
Olisi joskus mielenkiintoista verrata kehitysprosessiamme muiden turvakriittisten alojen prosesseihin. Miten kehitetään koodia vaikka ydinvoimaloiden järjestelmiin?
Suurin uutuus tässä standardissa lienee ohjelmiston ja sen osien jakaminen turvaluokkiin A, B ja C sen mukaan, millaisia seurauksia ohjelmiston viasta voi olla potilaan terveydelle. Vähemmän vaaralliset osat voidaan sitten dokumentoida ja testata hieman kevyemmin. C-luokassa pitää jo miettiä sitäkin, voisiko riskejä pienentää jakamalla ohjelmisto pyörimään eri suorittimille.
Alan standardit ovat menossa yksityiskohtaisempaan suuntaan, mutta taataanko tiptop-kunnossa olevalla prosessilla turvallisuus? Olennaista on myös tuotteen kehittäjien ja projektinjohdon ammattitaito ja asenne turvallisuutta kohtaan, mutta niitä olisikin jo vaikeampi standardoida.
Olisi joskus mielenkiintoista verrata kehitysprosessiamme muiden turvakriittisten alojen prosesseihin. Miten kehitetään koodia vaikka ydinvoimaloiden järjestelmiin?
Tilaa:
Blogitekstit (Atom)