31.10.2005Markku Tukiainen1 Tivi:n yhteiskunnallinen vaikuttavuus Tivi = tieto- ja viestintäteknologia ICT = information and communication technology.

Esitys aiheesta: "31.10.2005Markku Tukiainen1 Tivi:n yhteiskunnallinen vaikuttavuus Tivi = tieto- ja viestintäteknologia ICT = information and communication technology."— Esityksen transkriptio:

1 31.10.2005Markku Tukiainen1 Tivi:n yhteiskunnallinen vaikuttavuus Tivi = tieto- ja viestintäteknologia ICT = information and communication technology

2 31.10.2005Markku Tukiainen2 Johdanto •Teknologian kehittyminen on aina muuttanut yhteiskuntaa •esim. höyrykone ja rautatie •kehityksen nopeus aliarvioidaan aina

3 31.10.2005Markku Tukiainen3 Johdanto •3 osa-aluetta –yhteiskunnallinen vaikutus –lainsäädäntö –ammatillinen/eettinen vaikutus

4 31.10.2005Markku Tukiainen4 Tietokoneohjelmien rooli •Rahan käsittely •Puhelin- ja tietoliikenneverkot •Tavaroiden jakelu •Palvelujen tuotto •Media •Koti ja ympäristö •Työ

5 31.10.2005Markku Tukiainen5 Tietokoneohjelmien rooli •Turvallisuus-kriittiset järjestelmät –liikenne •lennon ohjaus •junaliikenteen ohjaus •kulkuneuvojen digitalisoituminen –prosessien kontrollointi •(ydin)voimaloiden ohjaus •lääketeollisuus –yksilön turvallisuus •teho-osasto •hoitolaitteet

6 31.10.2005Markku Tukiainen6 Therac-25 •sädehoito syövän parantamisessa •perustuu elektronien tykitykseen kohteeseen •jos kohde on pinnalla, tykitetään suoraan, annostuksen määrä tarkka •jos kohde on syvemmällä, muutetaan tykitys röntgensäteilyksi asettamalla rautalevy tykityksen eteen •kun käytetään röntgensäteitä, tykityksen intensiteettiä on nostettava voimakkaasti

7 31.10.2005Markku Tukiainen7 Therac-25 •1982 Atomic-Energy of Canada Ltd kehitti tietokoneohjatun sädehoitolaitteen •Therac-25 perustui Therac-20 -laitteeseen, jossa oli ohjelmisto-ohjattu säätöjärjestelmä, mutta mekaanisesti kontrolloitu turvajärjestelmä •suuria höytyjä: ei kuluvia säätimiä, tarkempi säteilyannos •1986 3 potilasta kuoli ylisuuren säteilyannoksen vuoksi

8 31.10.2005Markku Tukiainen8 Therac-25 •ongelma: jos käyttäjä valitsi vahingossa ensin elektronipohjaisen sädetyksen ja sitten vaihtoi sen nopeasti röntgensädepohjaiseen, laite ei asettanut metallilevyä riittävän nopeasti paikoilleen, ja potilas sai ylisuuren säteilyannoksen •ratkaisu: •mutta 1987 kuoli seuraava potilas, ongelma oli eri softa-ongelma

9 31.10.2005Markku Tukiainen9 Muita ohjelmistovirheitä •Bank of New York, 1985, ohjelmistovirhe laskentarutiinissa, 32 miljardin dollarin tilinylitys, tappiot 5 M$ •AT&T, 1995, reitityssoftan vaihto, Amerikan puhelinliikenne jumissa 9 h, arviolta 5 miljoonaa puhelua estyi •Dockland Light Railway, Lontoo 1987, uuden järjestelmän käyttöönotto, junankuljettaja vaihtoi manuaaliohjaukseen ja aiheutti törmäyksen

10 31.10.2005Markku Tukiainen10 Muita ohjelmistovirheitä •Sellafieldin ydinvoimala, 1991, ohjelmistovirhe johti suojakilpien aukaisuun radioaktiivisen materiaalin käsittelyssä •tienviittojen matkat mitattiin käyttäen 40€ softaa, asiakas maksoi toimittajalle 130.000€, virheet luokkaa 40-50% pahimmissa tapauksissa, esim. matkaa todellisuudessa 6,5 km ja tieviitassa 11,5 km

11 31.10.2005Markku Tukiainen11 Muita (ohjelmisto)virheitä •uudessa oppilaiden arvosanoja säilyttävässä järjestelmässä kaikille aiemman järjestelmän käyttäjille annettiin sama salasana •26 miljoonaa käyttäjätiliä jätettiin avoimesti aktivoitaviksi (kenen tahansa toimesta) siirryttäessä uuteen järjestelmään (tarvisttiin ainoastaan pääsy puhelimeen)

12 31.10.2005Markku Tukiainen12 Ohjelmoinnin luonne •Insinööritieteet ja ohjelmointi •luonnonlakien jatkuvuus vs. tietokoneiden diskreetit tilakoneet •data ja ohjelma muodostavat yhdessä tilan •kaikki siirtymiset tilasta toiseen tulisivat olla oikeita, jotta ohjelma toimisi oikein

13 31.10.2005Markku Tukiainen13 Testaaminen •Testaaminen osoittaa ohjelman toimivan oikein? •Tällöin on testattava kaikilla syötteillä •Mutta esimerkiksi ohjelma, joka lukee syötteinään 5 kokonaislukua väliltä 1- 100 (vai 0-99)

14 31.10.2005Markku Tukiainen14 Testaaminen •Tällöin erilaisia mahdollisia syötteitä on 100 x 100 x 100 x 100 x 100 •eli 10.000.000.000 kappaletta •jos 1 testi veisi aikaa 1 s, niin kokonaistestausaika oli luokkaa 300 v •tämän lisäksi tulee varmistua, että testaus suoritetaan oikein •tämän lisäksi olisi testattava myös kaikki virheelliset syötteet •tämän lisäksi vaatimusmäärittely oltava oikein

15 31.10.2005Markku Tukiainen15 Softan pehmeys •Perinteinen insinöörituote on yleensä vaikeasti muutettavissa, esim. vaatii paljon rahaa ja kokonaan tai osittain uudelleen suunnittelun/toteuttamisen •Tästä syystä muutoksiin suhtaudutaan huomattavasti vakavammin (ts. esim. resurssoidaan kunnolla) •Ohjelmistojen muuttamista on perinteisesti ajateltu helpoksi (niin kuin se onkin esim. implementaation muuttaminen ”lennosta”)

16 31.10.2005Markku Tukiainen16 Käytännön ongelmia ohjelmistotuotannossa •Ohjelmistotyö on työskentelyä useiden ihmisten ja ryhmien kanssa samaan aikaan •Projektien eri vaikutusryhmillä on erilaisia tavoitteita projektin suhteen •Väärinkäsitysten vaara kasvaa osallistuvien lukumäärän lisääntyessä •Ei voida käyttää samanlaisia menetelmiä yhden/kahden hengen projekteissa kuin kahdenkymmenen hengen projekteissa

17 31.10.2005Markku Tukiainen17 London Ambulance Service •London Ambulance Service Dispatch System (LAS, 1992) •7 milj. ihmistä, 1600 keikkaa päivässä •Manuaalijärjestelmä: ambulanssi lähti kohteeseen 3 minuutissa 45 % tapauksista, saapui kohteeseen 14 min kuluessa 55 % tapauksista •Uusi järjestelmä: VM tammikuu 1991, tarjouskilpailu helmikuu 1991, suunniteltu tuotannollinen käyttö tammikuu 1992

18 31.10.2005Markku Tukiainen18 London Ambulance Service •Tarjouksen voitti yritys, joka lupasi pysyä aikataulussa (tosin myöh. tutkimuksissa selvisi, että hinta oli ollut myös tarkeä päätöksentekokriteeri) •Ongelmia kehityksen aikana: versiot aina myöhässä, ei kunnollista projektinhallintaa, ominaisuuksia muutettiin käyttäjien toiveiden mukaan lähes milloin tahansa •Käyttäjät olivat skeptisiä uuden järjestelmän suhteen, koulutusta ei järjestetty tarpeeksi

19 31.10.2005Markku Tukiainen19 London Ambulance Service •Järjästelmä tuotantokäyttöön 26.10.1992 klo 7.00 •Järjestelmä poistettiin tuotantokäytöstä 27.10.1992 klo 14.00 •Ainoastaan puheluiden vastaanotto-osaa järjestelmästä voitiin käyttää (tosin sekin kaatui softavirheeseen 4.11.1992 ja poistettiin käytöstä) •Pahin tapaus ambulanssin tulo kesti 11 h, todennäköisesti 20 ihmistä kuoli tapauksen takia

20 31.10.2005Markku Tukiainen20 LAS mikä meni pieleen •uusi menetelmä projektinhallintaan (PRINCE) •ad hoc-muutokset asiakkaan miellyttämiseksi •järjestelmän implisiittinen reunaehto: tiedetään aina kunkin ambulanssin paikka ja tila •aikataulu liian tiukka •käyttöönottovaihe täysin puutteellisesti hoidettu

21 31.10.2005Markku Tukiainen21 Yleisiä ongelmia •Pitäisi tietää mitä implementoidaan –mutta vaatimukset muuttuvat kuitenkin •Organisatooriset ongelmat –käyttöönotto erityisen tarkkaan, jos toiminnallisuus on kriittistä •Ohjelmistoprosessi –pitäisi olla •Koulutus ja standardointi –pitäisi olla

22 31.10.2005Markku Tukiainen22 3 suurinta ongelmaa •Yhteiskunnallisesti ajatellen meidän pitää ratkaista ainakin seuraavat ongelmat –Ohjelmisto(prosessin)virheet –Tiedon käsittelyyn liittyvät ongelmat (tietokannat) –Tietoliikenteeseen liittyvät ongelmat

23 31.10.2005Markku Tukiainen23 Datan oikeellisuuden ongelmat •Esim. luottotietojen oikeellisuus ja virheiden korjaaminen •Tiedon tuottajalla ei vastuuta virheellisyyksistä ja yksilöllä näyttövelvollisuus virheiden kohdalla •

24 31.10.2005Markku Tukiainen24 Datan kertymisen ongelmat •Tietoa kerätään kaikkialla: kyselyt (palkinnoilla), bonus-kortit,... •Viranomaisrekisterit •Suurin ongelma on useiden rekisterien tietojen yhdisteleminen