Tämä jättipostaus koostuu viidestä esseestä, jotka kirjoitin Johdatus tietojenkäsittelytieteeseen kurssilla. Ensimmäinen essee perustuu Peter Denningin artikkeliin Is Computer Science Science? sekä John Horgannin artikkeliin The End of Science Revisited. Toisen esseen aiheena on ohjelmointiparadigmat, kolmannen tietojenkäsittelyn mekaniikat, neljännen suunnitteluperiaatteet ja viidennen tietojenkäsittelyn käytännöt. Nämä esseet perustuvat luentomuistiinpanoihin ja -materiaaleihin.
1. ESSEE: THE END
John Horgan perustelee artikkelissaan The End of Science Revisited miten tietotekniikka ei ole saavuttanut, eikä luultavasti ikinä tule saavuttamaan, sille ladattuja odotuksia. Tiede ei tule enää koskaan tuottamaan niin suuria paljastuksia kuin esim. evoluutioteoria, suhteellisuusteoria, kvanttimekaniikka ja Big Bang- teoria. Ja kaikki kaukaa haetut tavoitteet joita sovellettaville tieteille on asetettu jäävät ikuisesti saavuttamattomiksi. Tietojenkäsittelytieteilijä Marvin Minsky ennusti 60- luvun puolivälissä, että tietokone tulisi olemaan yhtä älykäs kuin 3-8- vuotias lapsi, mutta on sittemmin todennut, ettei olla päästy edes lähelle sitä.
Horgan kertoo muokannensa vuonna 1984 artikkelin jossa tekoälyasiantuntija Frederick Hayes- Roth ennusti että asiantuntijajärjestelmät tulevat anastamaan ihmisten rooleja mm. lääketieteessä ja liike-elämässä. Kun hän parikymmentä vuotta myöhemmin kysyi Hayes-Rothilta mitä hän nyt ajattelee ennustuksistaan, tämä myönsi, että asiantuntijajärjestelmä, ja tekoälytutkimus ylipäätään, oli ollut pysähdyksissä siitä saakka kun se koki kukoistuksensa 1980-luvun alussa. Horganin mukaan kaikki tekoälytutkijat eivät kuitenkaan vielä ole myöntäneet tappiotaan, vaan mm. Hans Moravec ja Ray Kurzwell edelleen profetoivat siitä että koneet tulevat jättämään lihaa ja verta olevat ihmiset taakseen kognitiivisissa kyvyissä. Horgan itse kutsuu tällaista spekulointia tiedeuskovaisuudeksi. Oikeastaan se, että IBM:n kehittämä shakkitietokone Deep Blue voitti Garry Kasparovin shakkiturnauksessa 1997 Horganin mielestä todistaa, että tietokoneista on vain suorittamaan tehtäviä jotka on tarkkaan määritelty. Ne eivät tule koskaan saavuttamaan joustavaa, monikäyttöistä älykkyyttä, jonka jokainen normaali ihminen saavutta viiteen ikävuoteen mennessä.
Peter J. Denningin kuva tietojenkäsittelytieteen tulevaisuudesta on valoisampi. Hän ei ajattele että tietojenkäsittelytiede olisi jo tavoittanut kaikki suuret saavutukset, tai että tieteenalojen määrä ylipäätänsä olisi rajoittunut, ja jokaisessa oltaisiin jo tultu määränpäähän. Pikemminkin tietojenkäsittelytiede muodostaa jatkuvasti uusia suhteita muiden tieteiden kanssa, ja näin muodostaa täysin uusia tieteenaloja, ja takaa tietojenkäsittelytieteen kehityksen ja tulevaisuuden.
Horgan kirjoitti artikkelinsa noin kymmenen vuotta sitten, ja väittäisin että jo nyt on nähtävissä miten pitkälle siitä ajasta on tultu. Ehkä edelleen on olemassa tiedemiehiä jotka eivät usko esimerkiksi itsetietoiseen tekoälyyn, mutta nyt kun robotit tekevät jo hampurilaisia ja kirurgisia toimenpiteitä, jotkut Horganin epäilykset vaikka siitä, etteikö koneet voisi anastaa ihmisten rooleja, vaikuttaa yhtä käsittämättömältä kuin se, että miten aikana ennen Kopernikusta ja Galileita on voitu luulla että Maa on maailmankaikkeuden keskus tai litteä. Ja ennen kuin aletaan vähättelemään koneiden kykyä itseohjautuvuuteen tai tiedostamiseen, voitaisiin kysyä, onko tämä meidän ”todellisuus” ainut olemassa oleva. Emmehän me edes tiedä mistä tietoisuus tai tajunta kumpuavat. Ehkä itsetietoinen tekoäly voisi ratkaista tämän kysymyksen, ja ehkä hän voisi jopa siirtyä todellisuudesta toiseen.
Tekoälytytkija Douglas Lenartin yritystä luoda itsenäinen ja luova ohjelma, joka keksii uusia ratkaisuja, on väheksytty. Hänen luomansa Cyc-ohjelman on sanottu olevan vain hieno sanakirja, joka selaa sanomalehtiä, kirjoja ja muita tietolähteitä, mutta on kaukana ihmisen luovuudesta ja joustavuudesta. Mutta jos ihmiset ovat eläimiä jotka on ohjelmoitu keräämään marjoja, luulisi ettei koneella olisi edes suuria vaikeuksia ohittaa ihmistä kognitiivisissa kyvyissä.
Lähteet:
Denning, Peter, J. Is Computer Science Science?
Horgan, John: The End of Science Revisited
Horgan, John: The End of Science Revisited
2. ESSEE: OHJELMOINTIPARADIGMAT
Tässä esseessä kerron lyhyesti eri ohjelmointiparadigmoista, ja vertailen niitä keskenään. Käsittelyssä on proseduraalinen, funktionaalinen ja olio-ohjelmointi. Ohjelmointiparadigma tarkoittaa tapaa ja mallia ohjelmoida. Se määrittelee tavan jolla kuvataan ohjelman käyttämä data sekä sen logiikka- ja kontrollivuo (järjestys). Se on laskennan malli, joka ohjaa ohjelman ongelmanratkaisutapaa. Yksi keskeinen jakolinja eri paradigmojen välillä on jako imperatiiviseen ja deklaratiiviseen. Imperatiivinen on eniten ja laajimmin käytetty, mikä johtuu sen tehokkuudesta. Siinä ongelman ratkaisu kuvataan tarkasti ja yksiselitteisesti vaihe vaiheelta, ja annetaan tietokoneelle toimintaohjeina miten toiminta suoritetaan. Deklaratiivisessa ohjelmoinnissa ongelma ratkaistaan esittämällä haluttu ratkaisu ja kertomalla mitä pitää tehdä, ja kone huolehtii yksityiskohdista.
Proseduraalinen ohjelmointi on imperatiivinen paradigma, jossa ohjelma rakennetaan proseduureista, eli aliohjelmista. Se koostuu erilaisista muuttujista ja datasta, jota ohjelmiston kontrollivuon muodostavat proseduurikutsut muokkaavat. Kullakin proseduurilla tulee olla oma nimi ja paluuarvo, jotka määrittävät proseduurin ainutlaatuisuuden. Menetelmässä ongelma ratkaistaan jakamalla se yhä uudestaan osatehtäviin, kunnes tuloksena on niin yksinkertisia tehtäviä, että niiden ratkaisut voidaan ilmaista ohjelmointikielen lauseilla. Suosituin proseduraalista paradigmaa soveltava ohjelmointikieli on C.
Funktionaalinen ohjelmointi kuuluu deklaratiivisten ohjelmointiparadigmojen luokkaan. Sen lähtökohtana on esittää asiat matemaattisen funktion käsitteen avulla, ja tavoitteena on tuottaa parempia ohjelmia nopeammin. Funktionaalisen ohjelman voidaan ajatella olevan tarkemmin määritellyn kuin proseduraalisen ohjelmoinnin. Ja koska funktioilla ei esimerkiksi ole riippuvuuksia globaalista datasta, laskenta tuottaa samoilla lähtöarvoilla aina saman tuloksen. Erona olio-ohjelmointiin on, että funktionaalinen ohjelmointi on tilatonta, ja muuttuja voi olla nimi lausekkeelle.
Ensimmäinen funktionaalinen kieli LISP kehitettiin 1950- luvulla, koska haluttiin luoda tekoälyohjelmiin paremmin sopiva kieli kuin silloiset valtakielet. Funktionaalisten kielten universaali ominaisuus on roskien keruu, eli automaattinen muistin varaus ja vapauttaminen. Koska käytössä ei ole muuttujia, jotka veisivät muistia, niin sitä voidaan käyttää roskien keruun automaattiseen hoitamiseen. Funktionaalisen ohjelmoinnin ero proseduraaliseen on mm. se, että funktionaaliset kielet ovat abstraktiotasoltaan korkeampia. Funktionaaliset menetelmät eivät kuitenkaan ole saavuttaneet kovin suurta suosiota tekoälytytkimuksen ulkopuolella. Vaikka ne soveltuvatkin hyvin matemaattisiin tehtäviin, niitä on kritisoitu hitaudesta ja siitä, että tosielämän ohjelmointitilanteissa se kyllä häviää olioparadigmalle.
Olio-ohjelmointi on selvästi suosituin ohjelmistoparadigma. Siinä ohjelmoinnin tila muodostuu erilaisista olioista, jotka sisältävät toisiinsa loogisesti liittyvää tietoa ja toiminnallisuutta. Kun perinteinen proseduraalinen tietokoneohjelma on lista suoritettavia ohjeita tietokoneelle, olio-ohjelma muodostuu kokoelmasta yhteistyössä toimivia olioita. Olio-ohjelmointiin liittyy ominaisesti luokat, perintä ja dynaaminen sidonta. Periytymisen ansioista on mahdollista käyttää uudestaan jo tehtyä ohjelmakoodia (yliluokka) uusien luokkien pohjana (aliluokka). Dynaamisen sidonnan ja perinnän ansiosta aliluokkia voidaan käyttää siellä missä yliluokkiakin, ja tämän lisäksi aliluokat voivat tuoda näihin yhteyksiin uutta toiminnallisuutta.
Olio-ohjelmointi nousi ohjelmistokehityksen valtavirtaan 1990-luvun alkupuolella. Käytetyimpiä ohjelmointikieliä, jotka tukevat olio-ohjelmoinnin paradigmaa, ovat luultavasti Java ja C++. Mutta kuten mikä tahansa ohjelmointiparadigma, olioparadigma on ensisijaisesti keino suunnitella ja kuvata ohjelmissa esitettyjä ongelmia ja relaatioita. Se ei myöskään ole kielisidonnainen, vaan oliopohjaista koodia voidaan kirjoittaa myös kielillä jotka eivät suoranaisesti tue luokkia.
Useat ohjelmointikielet ovat kuitenkin moniparadigmaisia, eikä niitä voi lokeroida selkeästi yhteen paradigmaan, vaikka ne olisikin suunniteltu ensisijaisesti tiettyä paradigmaa varten. Paradigmat ovat osin päällekkäisiä keskenään. Voikin olla parempi pohtia, missä määrin jokin ohjelma edustaa tiettyä paradigmaa. Ohjelmakokonaisuus voikin olla pääosin olio-ohjelmoitu mutta tietyltä osaltaan funktionaalinen.
Mielestäni kaikkia eri ohjelmistoparadigmoja ei tarvita, vaan pitäisi olla ainakin yksi niin moniparadigmainen kieli, jolla voisi tehdä kaikkea. Mutta tietenkin eri ohjelmointiparadigmat tulee tuntea, koska jos ohjelmoija ei tunne eri ohjelmointikielten ominaisuuksia, hänen toimintansa tulee olemaan melko rajoittunutta.
3. ESSEE: TIETOJENKÄSITTELYN MEKANIIKAT
Tässä esseessä kerron viidestä tietojenkäsittelyn mekaniikkoihin liittyvästä tarinasta ja kerron lyhyesti miksi kyseinen tarina on omasta mielestäni valittu edustamaan kyseisen perustoiminnallisuuden osa-aluetta.
Turingin kone
Turningin koneet ovat yksinkertaisia abstrakteja laskentalaitteita, joilla selvitetään laskettavuuden rajoja. Sen kehitti 1936 brittiläinen matemaatikko Alan Turing algoritmien havainnollistamiseksi. Turingin kone on ikään kuin tietokoneohjelma, joka toimii tietyn syötteen mukaan, ja univertaali Turingin kone on kuin ohjelmoitava tietokone. Sen ideana oli antaa ihmiselle riittävän tarkat ohjeet laskentatehtävän suorittamiseksi. Laskennallisesti se on yhtä voimakas kuin nykyiset tietokoneet, vaikka tehokkuudellaan se ei yletä nykyisten koneiden tasolle. Church-Turingin teesin mukaan kaikki laskettavissa oleva on laskettavissa Turingin koneella. Teesin oletetaan olevan totta, mutta sitä ei ole voitu todistaa oikeaksi. Universaali Turingin kone voi simuloida mitä tahansa olemassa olevaa tietokonetta, eikä ainakaan tähän mennessä ole onnistuttu kehittämään laskentalaitteita, jota Turingin koneella ei voisi jäljitellä.
Turingin kone koostuu äärettömän pitkästä nauhasta, joka toimii muistina ja lukupäästä, joka mm. lukee nauhalta symboleita. Lisäksi koneeseen kuuluu tilarekisteri sekä siirtymäfunktio, joka kertoo miten tilasta toiseen siirrytään nauhalta luetun symbolin perusteella. Turingin kone on tilakone, ja sen toiminnan täydelliseen määrittämiseen tarvitaan koneen nykyinen tila, nykyisen muistipaikan arvo ja tilasiirtymät—> uusitila, toimenpide. Nauhan muisti on ääretön ja se on jaettu muistipaikkoihin, joista jokaiseen voidaan tallettaa yksi arvo. Lukupäätä voidaan siirtää eteen- tai taaksepäin ja sillä voidaan lukea ja kirjoittaa nykyisen muistipaikan arvo. Tilasiirtymät määräytyvät muistipaikoista luettujen arvojen perusteella ohjelman suorituksen aikana.
Turingin koneita käytetään perustana lukuisissa eri matemaattisen logiikan ja tietojenkäsittelytieteen peruskäsitteiden määritelmissä. Alun perin se tarkoitettiin yleiseksi laskentaformalismiksi, jolla voidaan esittää mikä tahansa algoritminen laskenta. Kuuluisin kaikista Touringin koneella todistettavista tuloksista on pysähtymisongelma, joka kysyy, voidaanko sanoa pysähtyykö mielivaltainen ohjelma annetulla syötteellä. Alan Turing todisti ettei ole algoritmia, joka ratkaisisi pysähtymisongelman kaikilla syötteillä.
Turingin malliin perustuvaa konetta ei rakennettu aikoinaan, vaan jo vuonna 1944 olivat käytössä Colossus-tietokoneet. Ensimmäinen Turingin- kone rakennettiin vuonna 1986. Ajattelen tämän tarinan tulleen valituksi kuvaamaan tätä tietojenkäsittelyn osa-aluetta koska laskennan peruskysymykset liittyvät laskennan rajoihin ja Turingin koneet ovat laskentalaitteita jotka on kehitelty tutkimaan niitä.
Protokollapino
Protokollapino on tietoliikenneohjelmisto, jolla toteutetaan tiedonsiirtoa ja siihen liittyviä toimintoja. Se on mielestäni valittu kommunikaation tarinaksi, koska kommunikoinnin peruskysymykset liittyvät sanoman välittämiseen paikasta toiseen. Protokollapinossa ilmentyy myös haasteiden eriyttäminen, joka on yksi tietojenkäsittelyn keskeisimmistä lähestymistavoista. Protokollapino koostuu kerroksista, joista jokainen toteuttaa sille määrätyt asiat. Käsitteellisenä kehikkona toimii yleensä OSI- malli (Open System Interconnect), joka koostuu seitsemästä kerroksesta, vaikka nykyisin käytetäänkin lähes yksinomaan TCP/IP-pinoa. Kukin kerros käyttää alemman kerroksen palveluja ja tarjoaa palveluja ylemmälle. Malli kehitettiin 1980-luvun alussa. OSI- mallin kerrokset ovat:
Sovelluskerros, jota käytetään kunkin sovelluksen viestintään mm. sähköposti, uutisryhmät, Web. Esitystapakerros, joka vastaa mm. eri merkistökoodauksien yhteensovittamisesta
Istuntokerros, joka mahdollistaa istunnon muodostamisen
Kuljetuskerros, joka huolehtii sanoman siirtämisestä päätepisteiden välillä
Istuntokerros, joka mahdollistaa istunnon muodostamisen
Kuljetuskerros, joka huolehtii sanoman siirtämisestä päätepisteiden välillä
Verkkokerros; reitittää tietoliikennepaketit lähettäjältä vastaanottajalle. Huolehtii myös ruuhkanhallinnasta.
Linkkikerros; yhteys solmulta toiselle, virheiden huomaaminen (ja joskus korjaaminen) tarkistuskoodilla
Linkkikerros; yhteys solmulta toiselle, virheiden huomaaminen (ja joskus korjaaminen) tarkistuskoodilla
Fyysinen kerros; bittien lähettäminen tiedonsiirtokanavaa (sähkökaapeli, valokuitu, radioaallot) pitkin
OSI-mallilla ja TCP/IP-pinolla on paljon yhteistä, mutta keskeisimmät erot ovat että TCP/IP-mallista puuttuvat esitystapa- ja istuntokerrokset. Näihin liittyvä toiminnallisuus toteutetaan jokaisessa sovellustason protokollassa erikseen. Toinen eroavuus on että TCP/IP-mallissa fyysinen kerros ja linkkikerros on yhdistetty verkkoonpääsykerrokseksi, mutta tällä ei ole käytännössä merkitystä.
TCP/IP-on ollut erittäin menestyksekäs kun on rakennettu laajoja verkkoja, koska kaikki verkon solmut voivat viestiä toistensa kanssa käyttäen kaikille yhteistä protokollaa, IP:tä. IP-paketteja voidaan lähettää minkä tahansa peruskerroksen protokollan päällä, ja kaikki muut palvelut, sovellukset ja protokollat käyttävät IP:tä. OSI-malli soveltuu paremmin kun puhutaan tietoliikenneverkoista tai opetetaan niitä.
Synkronointi
Synkronointi eli tahdistaminen on aikaan liittyvää koorninointia eli yhteistyötä. Se on olennaista tietokoneiden välisessä yhteistyössä, ja mielestäni siksi valittu koordinoinnin tarinaksi. Esimerkiksi monikanavaviestinnässä, kuten televisiossa, ääni ja kuva on koordinoitu, jotta ne etenevät samaa tahtia. Synkronoinnilla voidaan myös varmistaa että itsenäisten toimijoiden aikaansaannokset valmistuvat oikeassa järjestyksessä. Synkronoinnissa ilmenevät ongelmat liittyvät yleensä yhteiskäyttöisten resurssien hallintaan. Ongelmien ratkaisut kuuluvat tietojenkäsittelytieteen ydinainekseen. Resurssien hallintaan liittyvien ratkaisujen on estettävä nälkiintyminen ja lukkiutuminen.
Nälkiintymisongelmassa jotkut prosessit voivat varata niin paljon resursseja että muut eivät pääse etenemään, tai joku joutuu odottamaan vuoroaan ikuisesti. Aterioivien filosofien ongelmassa filosofi vapauttaa varaamansa haarukan odotettuaan hetken, jos toinen haarukka ei ole vapaana. Ellei odotusaika ole satunnainen, filosofit eivät pääse syömään. Ja vaikka odotusaika olisikin satunnainen, eivät kaikki filosofit välttämättä pääse syömään. Lukkiutumisongelmassa kaikki odottavat että joku toinen tekisi jotain. Eli esimerkin mukaan jokainen filosofi tarttuu yhteen haarukkaan, ja odottaa ikuisesti että joku vapauttaisi toisen haarukan.
Klassisia synkronpontiongelmia ovat tuottaja-kuluttaja -ongelma, jossa tuottajalta tulee tuotteita varastoon ja kuluttaja ostaa niitä. Mutta jotta kuluttaja voi kuluttaa, varasto ei voi olla tyhjä. Eikä varasto myöskään voi olla täysi, jotta tuottaja voi tuottaa sinne tavaraa. Toinen klassinen ongelma on lukija-kirjoittaja -ongelma. Tässä ongelmassa useampi prosessi kirjoittaa ja lukee samaa resurssia, vaikka vain yksi kerrallaan voi kirjoittaa. Ja kun kirjoittaja ei saa kirjoitusvuoroa, kaikki lukijat lukevat vanhentunutta tietoa, eli sekä lukija että kirjoittaja nälkiintyvät.
Turingin testi
Turingin testi on tarkoitettu mittaamaan koneen ihmismäisyyttä asettamalla se keskustelemaan tekstipohjaisesti kokeen tarkkailijana olevan ihmisen kanssa. Kokeen on luonut Alan Turning vuonna 1950 tarkoituksenaan älykkyyden määritteleminen. Ajatuksena on, että tietokone on älykäs jos keskustelija ei kykene erottelemaan onko kyseessä kone vai ihminen. Turingin testistä on tullut teköälytytkimuksen klassikko, vaikka testin mielekkyydestä on käyty kiivasta väittelyä, eikä sen läpäisystä ansaittavaa Loebnerin palkintoa ole toistaiseksi jaettu (2014). Vaikka kesäkuussa 2014 Eugene Goostmanin väitetään läpäisseen testin, pidetään kuitenkin epäselvänä että voiko testin katsoa läpäistyksi.
Testi on saanut runsaasti kritiikkiä, ja sen käyttökelpoisuutta todellisen älykkyyden määritelmänä on arvosteltu. Sanotaan, että kone joka läpäisisi Turingin testin, kyllä jäljittelisi ihmisen käyttäytymistä ja noudattaisi jotain nokkelasti luotua sääntöä, vaikka ei olisikaan älykäs tai ajatteleva. Toisekseen, myös jotkut älykkäinä pidetyt ihmiset saattaisivat epäonnistua testissä. Testin innoittajana oli englantilainen seurapiirileikki, jossa tarkoituksena oli että mies ja nainen yrittävät tekstivälitteisesti kysymyksiin vastaamalla uskotella muille olevansa toista sukupuolta kuin on. Eli eikö Turingin testin tarkoitus ole ennemminkin uskotella ihmiselle olevansa ihminen. Siinä on siis kyse koneen kyvystä harhauttaa ihmistä, ei koneen kyvystä olla ihminen.
Testin tavoiteasettelussa sanotaan, että järjestelmän tulisi käyttäytyä kuin ihminen. Tällainen tavoite on tietojenkäsittelytieteessä vähän hassu, koska ihminenhän tunnetusti tekee virheitä. Hyödyllisempää olisi odottaa, että järjestelmä käyttäytyisi siten kuin ihminen haluaa. Automatisoinnin mekaniikkoihin liittyy monta mielenkiintoista tarinaa, mutta luulen että Turingin testi tuli valituksi, koska se tavallaan kuuluu yleissivistykseen.
Välimuisti
Välimuistin tehtävä on nopeuttaa tietokoneen toimintaa. Luulen että se on valittu muistamisen tarinaksi, koska se on konkreettinen ja tärkeä osa tietokoneen toimintaa. Kun tieto tallennetaan tilapäisesti välimuistiin lähelle käsittelypaikkaa, se nopeuttaa noutojen valmistumista, koska aina kun muistista haetaan jotain tietoa, tarkastetaan ensin löytyykö tarvittavan tiedon kopio välimuistista. Jos tieto löytyy välimuistista, se haetaan suoraan sieltä, mutta jos ei, niin se haetaan varsinaisesta muistista ja tallennetaan samalla välimuistiin. Jos välimuisti on täynnä, siellä pisimpään käyttämättömänä ollut tietoalkio poistuu, jonka jälkeen se pitää hakea uudestaan hitaammasta muistista.
Kirjoituspolitiikka ohjaa sitä ajoitusta, missä vaiheessa välimuistissa oleva tieto kirjoitetaan varsinaiseen muistiin. Tässä välimuisti voi toimia kahdella eri tavalla. Siinä oleva tieto voidaan välittömästi kirjoittaa varsinaiseen muistiin, jolloin kyseessä on läpikirjoittava välimuisti. Tai välimuisti voi pitää kirjaa niistä tietoalkioista joita on muutettu, ja nämä kirjoitetaan varsinaiseen muistiin, kun alkio poistetaan välimuistista.
Keskusmuistiin tehdään viittaus muistipaikan osoitteella, joka kertoo missä muistipaikassa haluttu tieto on. Jokaisella keskusmuistin alkiolla ei kuitenkaan voi olla omaa kopiota välimuistissa, ja jotta tiedetään mihin paikkaan välimuistia keskusmuistin tietoalkiot sijoitetaan, käytetään assosiatiivista muistia. Erilaiset assosiatiiviset muistit eroavat toisistaan siinä, kuinka vapaasti keskusmuistissa oleva muistipaikka voidaan sijoittaa välimuistiin: täysin assosiatiivisessa tietoalkiot voidaan sijoittaa minne tahansa, suorasijoituksessa sijainti lasketaan tietoalkion osoitteen perusteella. Mitä useampaan paikkaan tietoalkio voidaan sijoittaa, sitä useammasta paikasta sitä on myös etsittävä, ja tarvittava enemmän virtaa, tilaa piireille ja aikaa. Yleensä prosessorien välimuistit käyttävät näiden kahden välimuotoa.
Lähteet
cs.helsinki.fi
cse.tkk.fi eluova.fi
hs.fi itviikko.fi
wikipedia.orgSuunnitteluperiaatteet
cse.tkk.fi eluova.fi
hs.fi itviikko.fi
wikipedia.orgSuunnitteluperiaatteet
4. ESSEE: SUUNNITTELUPERIAATTEET
Tässä esseessä kerron suunnittelun tärkeydestä ohjelmistoja kehitettäessä. Kerron miksi suunnittelu on tärkeää, ja mihin sillä pyritään. Vuosien saatossa on ilmennyt hyväksi todettuja suunnittelun käytäntöjä, joilla pyritään saavuttamaan yksinkertaisuus, suorituskyky, luotettavuus, kehitettävyys ja tietoturva.
Yksinkertaisuus - monimutkaisuuden hallinta
Tietojenkäsittelyjärjestelmät ovat yksiä monimutkaisimmista konstruktioista joita ihminen on tehnyt. Monimutkaisuus on tunnetusti hidasta ja tuo ongelmia. Sen vuoksi siitä tulisi mahdollisuuksien mukaan päästä eroon, ja Edsger W. Dijkstra onkin määritellyt 1972 tietojenkäsittelytieteen olevan monimutkaisuuden hallitsemisen tutkimista.
Rakenteeltaan erinomaisissa ohjelmissa ohjelmointityyli on johdonmukainen, yksinkertainen, selkeä ja siitä puuttuu ohjelmointitrikit. Tällaisiin ohjelmiin on helppo tehdä muutoksia jälkikäteen, ilman että rakenne rikkoutuu. Yksinkertaisuus ei kuitenkaan synny itsestään, vaan se vaatii huolellista suunnittelua ja aikaa järjestelmän rakenteen ajatteluun. Aiemmin tehdyistä virheistä tulisi myös ottaa opiksi. Käyttämällä aikaa aiempien yritysten tutkimiseen ja analysointiin, olisi mahdollista ymmärtää heikkoudet joita niissä lähestymistavoissa on. Monet ohjelmistotuotteet tekevät kuitenkin samat virheet uudestaan, ja toisaalta jättävät hyviä ratkaisuja hyödyntämättä.
Vaikka ohjelmoinnista ja ohjelmistojen rakentamisesta on saatavilla runsaasti hyviä oppikirjoja ja alan taitureiden kertomuksia, johdonmukaisia ohjelmistoja on hyvin vähän. Yksi syy tähän saattaa olla nykyisen ohjelmistoteollisuuden olosuhteet. Ohjelmistoja tuotettaessa on mietittävä kaupallista menestystä, jolloin toiminnallisuus ja suorituskyky painavat enemmän kuin koodin selkeä rakenne. Toisaalta, suunnittelijat saavat harvoin lähteä alusta, vaan useimmat käytössä olevat ohjelmistot ovat vain laajentuneet vuosien saatossa, jolloin niissä on mukana paljon historian painolastia. Laajeneminen ei olisi ongelma, jos ohjelmistot olisi alun perin suunniteltu laajennettavaksi. Mietin, että ohjelmakoodia voi monimutkaistaa myös se että sitä on ollut tekemässä eri firmat, mutta myös se, että koodista on ehkä tarkoituksella haluttu tehdä vaikealukuista, etteivät muut firmat voi tehdä muutoksia ohjelmistoon.
Suorituskyky - suunnittelu
Ohjelmiston suunnitteluvaiheessa on tavoitteena arvioidan myös tulevan järjestelmän tehokkuutta ja sen tarvitsemaa kapasiteettia. Daniel A. Menacén (2002) mukaan kuitenkin suorituskykyvaatimukset otetaan hyvin harvoin huomioon suunnitteluvaiheessa, reaaliaikasovelluksia lukuunottamatta. Yksi syy tähän hänen mukaansa on se, että ohjelmistotekniikassa suorituskykyvaatimuksia kutsutaan ei-toiminnallisiksi vaatimuksiksi. Ohjelmistotekniikassa suorituskyvystä ruvetaan huolestumaan ohjelmiston kehitysprosessin viimeistelyvaiheessa. Menacé hämmästelee tällaista asennetta insinööritaidossa, sillä ohjelmistojen suorituskyvyn suunnittelun tulisi olla osa jokapäiväistä ohjelmistotuotantoa. Ratkaisuna tähän voisi olla:
1. Formaalien ja kvantitatiivisten mallien systemaattinen käyttö ohjelmistotekniikassa osana ohjelmiston elinkaarta. Erilaisten formalismien ja menetelmien kehittäminen myös ei- toiminnallisten vaatimusten (minä suorituskykyä pidetään) tukemiseen. Suorityskykymallien eksplisiittinen mallintaminen, suorituskykyanalyysin yhteisön toimesta, jotta suorituskykyvaikutuksia voitaisiin helposti analysoida.
2. Tietojenkäsittelytieteen opiskelijoiden valmistaminen teollisuudessa vastaantuleviin ohjelmistotekniikan haasteisiin ja alalla toimijoiden valistaminen ohjelmistojen suorituskykyongelmista. Toisin sanoen parantaa ohjelmoijien ammattitaitoa.
3. Useiden samanaikaisten käyttäjien huomioonotto, sekä käsiteltävän tietokannan koon huomioiminen jo tietokannan käyttöä toteutettaessa.
Itse ajattelen että opiskelijoiden ja työntekijöiden kouluttaminen olisi varmasti hyvä ratkaisu moneen ongelmaan. Pitää olla riittävästi tietoa ja taitoa, jotta pystyy näkemään asiat monesta näkökulmasta ja ratkoa/ välttää ongelmia laajasti.
Luotettavuus - toipuminen
Yksi lähestymistapa luotettavuuden lisäämiseksi olisi ohjelmien kaatumisen teko turvalliseksi, ja siitä toipuminen nopeaksi. Usein järjestelmän hallittu alasajo ja uudelleen käynnistäminen on hitaampaa kuin sen kaataminen ja käynnistäminen toipumisen kautta. George Gandea ja Armando Fox kuitenkin ehdottavat että kaataminen ja toipumisen käynnistäminen olisivat ainoita keinoja päättää ohjelman suoritus. Kaatumatonta tietojenkäsittelyjärjestelmää on yleensä epäkäytännöllistä yrittää rakentaa, joten järjestelmän olisi varauduttava kaatumiseen. Onkin aiheellista kysyä, miksi järjestelmään on rakennettava sekä hallittu alasajo, että kaatumiseen varautuminen. Tällaisessa ”crash-only”- järjestelmässä toipumismekanismia käytetään aina kun järjestelmä käynnistetään. Tällainen järjestelmä mahdollistaa myös yksinkertaisen vikamallin. Eli jokainen häiriö voidaan käsitellä ohjelmistokomponentin kaatumisena, koska toipuminen on nopeaa. Tällöin komponenttien on toivuttava vain yhdestä häiriöstä, eli kaatumisesta.
”Crash-only” ohjelmistokomponentin ominaisuuksiin kuuluu erityinen tilatietovarasto, johon tallentuu kaikki ei-tilapäinen tilatieto. Järjestelmä on suunniteltava niin, että erilliset komponentit varautuvat muiden komponenttien kaatumisiin ja tilapäisiin käytöstä poissaoloihin, jotta se olisi ”crash-only”. Useimmat nykyisin saatavilla olevat tilatietovarastot takaavat turvallisen kaatumisen, eli ne osaavat kaatua niin että tietoa ei huku, mutta useimmat tietokannat ja verkkojen tallennuslaitteet eivät kuitenkaan ole ”crash-only”, sillä toipuminen on melko hidasta.
Kehitettävyys - muutoksiin varautuminen
David Parnas nostaa ohjelmistotekniikan perusongelmaksi ohjelmistojen ikääntymisen. Ohjelmistojen ikääntyminen on keskeinen tekijä ohjelmistojen kehitettävyydessä ja ylläpidettävyydessä. Lisääntyvä tietotekniikan hyväksikäyttö luo paineita muuttaa ohjelmistokehityksen arviointia, suunnittelua ja hallinnointia. Eri tietojenkäsittelyjärjestelmiä joutuu myös nykyisin yhdistää ja ne on saatava keskustelemaan keskenään, vaikka ne ovat aikaisemmin olleet irrallisia järjestelmiä. Kuitenkin niiden on edelleen toimittava organisaation aiempien prosessien ja käytäntöjen kanssa. Kun jo toiminnassa olevia järjestelmiä yhdistellään, uusien sovellusten käyttöaluetta, laajuutta ja yksityiskohtia joudutaan rajaamaan, mikä saattaa aiheuttaa rajoituksia käytettävyydessä. Jotkut järjestelmiin kohdistuvat muutospaineet olisi vältettävissä sillä, että ne suunniteltaisiin alun perin mahdollisiksi muuttaa helposti.
Ohjelmisto ei voi mukautua ulkoisiin muutoksiin itsestään kuin ainoastaan siinä tapauksessa, että ohjelmiston laatijat varautuvat muutoksiin ja toteuttavat tarvittavat mukautumismekanismit. Mukautuvuus on mahdollista saada aikaan koodiin vain siinä määrin kuin mahdollisiin muutostarpeisiin on osattu varautua. Meir Lehman (1998) korostaa, että erityisen tärkeää on luoda ohjelmiston perustalle hyvä suunnitelma. Muutettavuus on suunniteltava osaksi ohjelmistoarkkitehtuuria ja on hyväksyttävä että ohjelmistokehityksen ja ajan myötä sovellutusten ja käyttöalueiden rajat muuttuvat. Kehityksen myötä rajoja on päivitettävä vastaamaan uusia vaatimuksia. Kaikki suunnitelmat, sekä oletukset tulevien muutosten todennäköisyyksistä, tulisi kirjata ylös ja dokumentoida. Kaikkien suunnitelmiin tehtävien muutosten vaikutukset rajoihin ja oletuksiin on myös käytävä läpi ennen kuin ne tehdään, jotta yhteensopimattomuudet ja sivuvaikutukset voidaan välttää.
Mietin vaan, että mitä jos oletuksissa ja suunnitelmissa on menty aivan metsään, eivätkä ne vastaa ollenkaan muuttuvia tilanteita. Tietysti maailmassa voi tapahtua odottamattomia asioita, joihin ei voi varautua, mutta ehkä suurin osa tulevista muutoksista on kuitenkin ennustettavissa. Suurin ongelma taitaa olla se ettei tilanteisiin reagoida ennen kuin ne kehittyvät ”kriisiksi”.
Turvallisuus
Onnettumuuksien välttämiseksi on tärkeä ottaa huomioon turvallisuus. Onnettomuudet eivät ole mitenkään yksinkertaisia, vaan niiden taustalla on yleensä monimutkainen tapahtumien vyyhti, joka johtuu teknisistä, inhimillisistä ja työyhteisöön liittyvistä tekijöistä. Voi olla vakava virhe uskoa, että ongelma poistetaan korjaamalla yksi virhe. Toinen vakava virhe on olettaa että korjaamalla yksi virhe estetään uusien onnettomuuksien ilmaantuminen. On vastuutonta ja ylimalkaista väittää että onnettomuudet johtuisivat laitteistoviasta tai inhimillisestä erehdyksestä, koska yleensä taustalla on se, ettei niitä ole älytty tai viitsitty ottaa huomioon ja varautua ongelmiin. Esimerkiksi Fukushiman ydinonnettomuuden väitettiin johtuvan luonnonmullistuksesta, maanjäristyksestä ja tsunamista, vaikka oikeasti taustalla oli tehtaan ränsistyminen ja tarvittavien korjausten ja huoltotöiden laiminlyönti, ja muutenkin ydinvoimalan rakentaminen alueelle, jossa luonnonmullistusten riski on suuri. Toinen esimerkki on Indian Point Yhdysvalloissa, joka on rakennettu lähelle mannerlaattojen saumaa. (The Atomic States on America- dokumentti).
Kun analysoidaan monimutkaisten järjestelmien aiheuttamia onnettomuuksia, on lähestymistavan perustuttava järjestelmien rakentamiseen. Taustalta löytyy yleensä:
1. Puutteita valmistajan raporteissa
2. Laitteistovarmistusten poisjättö. Esim. ehdotonta turvallisuutta vaativissa järjestelmissä ei saa
olla varmistamattomia virtalähteitä.
olla varmistamattomia virtalähteitä.
3. Kohtuuton luottaminen ohjelmistoon. Ohjelmistovirheiden löytäminen on huomattavasti hankalampaa kuin laitteistosta johtuvien virheiden huomaaminen, mutta ainakaan laitteistovarmistuksia ei ole syytä jättää pois, kun ohjelmistoa aletaan käyttää järjestelmän ohjaamiseen.
4. Puutteita ohjelmistotekniikan käytännöissä. Tietokoneperäiset virheet johtuvat yleensä ohjelmiston suunnitteluvirheestä. Yleensä tällaiset virheet johtuvat virheellisestä vaatimusmäärittelystä; kaikkia ulkoisia olosuhteita ei oteta huomioon tai niitä käsitellään väärin.
5. Epärealistinen riskien arviointi.
Lähteet
Luentomoniste
The Atomic States of America- dokumentti
The Atomic States of America- dokumentti
5. ESSEE: TIETOJENKÄSITTELYN KÄYTÄNNÖT
Tietojenkäsittelyn käytännöt täydentävät kuvaa tietojenkäsittelytieteestä, ja ne voidaan jakaa viiteen pääalueeseen: ohjelmointi, järjestelmien rakentaminen, mallintaminen ja validointi, innovointi ja soveltaminen. Näiden hallisemisesta saadaan viime kädessä selville tietojenkäsittelijän ammatilliset taidot ja osaaminen.
Ohjelmointi
Ei ole mitään järkeä kirjoittaa muuta kuin hyvää ohjelmakoodia, sillä hyvän ohjelmakoodin kirjoittaminen ei ole kovinkaan paljon vaikeampaa kuin huonon, mutta hyvän koodin hyödyt tulevat selkeästi esille ohjelman ylläpidon aikana (Donn Seeley, 2005). Hyvän ohjelmakoodin ominaisuuksia on mm. helppo luettavuus. Kun ohjelmakoodi on ryhmitelty sopivasti, ihmisen on helpompi hahmottaa ja ymmärtää sitä. Luettavuutta lisää myös se että koodia on kommentoitu tarkoituksenmukaisesti, mielellään kokonaisilla lauseilla. Hyvän ohjelmakoodin ominaisuuksiin kuuluu myös hyvä nimeäminen. Vaikka tietokoneelle nimet eivät ole muuta kuin merkkijonoja, ihmisille ne lisäävät huomattavasti koodin luettavuutta. Nimiä tulisi käyttää myös systemaattisesti, eli samaa nimeä aina samassa merkityksessä. Hyvä ohjelmakoodi on myös johdonmukaista. Esimerkiksi isommissa projekteissa ohjelmointityöryhmän on sovittava yhteisistä tyyleistä ja nimeämistavoista.
Käytetyn ohjelmointikielen vaikutuksia on yliarvioitu ohjelmakoodin laatuun, sillä koodin ominaisuudet ovat jokseenkin kielestä riippumattomia, vaikka joillakin kielillä on helpompi tai vaikeampi kirjoittaa käsittämätöntä koodia. Jotkut ratkaisut voi olla helpompi toteuttaa jollakin tietyllä ohjelmointikielellä, mutta samankaltaisia ohjelmointiongelmia kohdataan kielestä riippumatta. Tämä johtuu ohjelman suunnittelusta. Huono suunnittelu johtaa aina huonoon lopputulokseen kielestä riippumatta. Ohjelmoinnissa hyvin suunniteltu on enemmän kuin puoliksi tehty.
Olen ehdottomasti samaa mieltä Seeleyn kanssa, että ohjelmoijien on oltava nöyriä ja hyväksyttävä ohjelmakoodin luettavuus niin keskeiseksi tavoitteeksi , että jokaisen on luovuttava omasta suosikkityylistään ja käytettävä yleistä ohjelmointityyliä. Itse ainakin aijon pyrkiä toimimaan näin.
Järjestelmien rakentaminen
Ohjelmistotekniikan keskeisin haaste on järjestelmien rakentaminen. Denningin mukaan järjestelmien rakentamiseen kuuluu suunnittelu, toteutus ja käyttö. Tietojenkäsittelyn ammattilaisella on oltava taidot osallistua laajojen järjestelmien laatimiseen. Monissa ohjelmistoissa kuitenkin nousee esille samantyyppisiä ongelmia aikakaudesta riippumatta, joten Richard E. Fairley sekä Mary Jane Willshire (2003) ovat listanneet keskeisimmät ongelmat ja ehdotuksia niiden parantamiseksi.
Yksi tavanomainen ongelma on ohjelmistojen tarpeiden muuttuminen. Syitä tähän voivat olla ulkoiset kilpailutekijät, käyttäjien tarpeiden tai suoritusympäristön muuttuminen ja projektin aikana tarkentunut näkemys. Vaatimusten muuttumista voidaan hallita ottamalla huomioon aikataulun, resurssien ja teknologian asettamat rajoitukset, sekä käsittelemällä muutokset versioiden hallinnan menetelmillä. Jotta ongelmilta voitaisiin yrittää välttyä, kaikki ohjelmistoprojektiin liittyvä tiedonvaihto tulisi tapahtua kirjallisesti ja dokumentoida. Myös projektisuunnitelma tulisi tehdä alusta alkaen kirjallisena. Suunnitelmasta on käytävä ilmi ainakin työn vaatimukset, työnjako, aikataulut ja hankinnat.
Muita ohjelmistoprojektien ongelmia voi olla yletön ja toissijainen innovointi sekä vaatimusten luisuminen. Jotta innovointi ei pääsisi ylittämään sen hetkistä tietotaitoa eivätkä epäolennaisuudet muodostuisi dominoiviksi, on erittäin tärkeää että projektilla olisi vastuullinen ohjelmistoarkkitehti, joka huolehtii ohjelmatuotteen eheydestä. Kaikkien ehdotettujen muutosten vaikutuksia tulisi myös analysoida.
Fred Brooks väittää, että yleisin ohjelmistoprojektien epäonnistumisen syy on epärealistisen tiukka aikataulu. Se on hänen mukaansa yleisempi kuin kaikki muut syyt yhteensä. Aikataulussa pysymistä voitaisiin edistää lisäämällä projektin resursseja ja käydä ohjelmiston vaatimukset uudelleen läpi. Myöskään eettisiä näkökohtia, eikä olennaista, eli sitä mitä varten ohjelmaa ollaan tekemässä, tulisi unohtaa.
Itse korostaisin vielä vastuuntuntoisen ohjelmistoarkkitehdin roolin tärkeyttä. Projektilla on oltava yksi selkeä johtaja, joka osaa olla tarpeeksi tiukka ja sanoa suoraan mitä voidaan toteuttaa ja mitä ei. Hänen tulisi osata myös arvioida realistisesti resursseja, kuten aikaa.
Mallintaminen ja validointi
Tietokonejärjestelmien suorituskyvyn analysoinnin keskeiseksi työvälineeksi nousi 1970-luvulla jonoverkkomallit. Niitä voidaan siis käyttää erilaisten tietokonesysteemien suorituskykymallien tekemiseen, joista voidaan analysoida mallinnetun systeemin suorituskykyarvot. Jonoverkkomalleista saadaan analysoitua mm. palvelinten käyttöasteet, keskimääräiset jononpituudet sekä jonotusajan ja palveluajan jonoissa.
Järjestelmä kuvataan verkkona, joka koostuu useista resursseista joiden välillä työt siirtyvät. Tällainen verkko eli jonoverkkomalli voi olla avoin tai suljettu. Avoimia verkkoja käytetään esimerkiksi pankkiautomaateissa, tietokantapalvelimissa ja Google-haussa. Suljetut verkot sopivat esim. interaktiivisten ja istuntopohjaisten järjestelmien mallintamiseen. Jonoverkkomallissa oletetaan, että asiakas siirtyy palvelupisteestä toiselle käyttäen kerrallaan vain yhtä resurssia.
Tulomuotoisten jonoverkkomallin keskeiset suorituskykysuureet saadaan laskettua nk. MVA- algoritmilla, eli keskiarvoanalyysilla, käymättä kaikkia tiloja läpi.
Innovaatiot
Innovaatio on yksi teknologian arvostetuimmista alueista. Peter J. Denning väittää, että innovaatioiden käytännön voi oppia, ja sitä voidaan opettaa ja tehdä systemaattisesti, kunhan tiedetään mitä innovaatio on. Termiä on käytetty tarkoittamaan sekä uusia ajatuksia että uusia käytäntöjä, mutta Denning tarkoittaa innovaatiolla uuden käytännön soveltamista, sillä muuten uusilla ajatuksilla ei ole käytännön vaikutusta. Sen sijaan keksintö eroaa olennaisesti innovaatiosta. Keksinnöllä tarkoitetaan uuden luomista, ja siinä voidaan keskittyä teknologioihin sosiaalisen yhteisön sijaan. Innovoinnin käytännöt ovat ensisijaisesti sosiaalisia, ei teknisiä. Ja tekniset innovaatiot edellyttävät innovaattorilta sekä sosiaalisia että teknisiä taitoja.
Peter Drucker (1985) nostaa innovaatioprosessin kulmakiviksi mahdollisuuksien etsimisen, suunnittelemisen ja laskelmien teon, työyhteisön kuuntelemisen, keskittymisen olennaiseen ja johtajuuden. Erityisen tärkeänä hän pitää mahdollisuuksien etsimistä, joita tulisi nähdä tavanomaisesta poikkeavissa tilanteissa, esim. odottamattomissa tapahtumissa tai muutostilanteissa. Tähän tietysti tarvitaan laajaa tietoisuutta (Denning), eli kykyä oivaltaa mahdollisuuksia ja tunnistaa kiinnostavat asiat. Myös Denning pitää tärkeänä keskittymistä olennaiseen, eli innovaation ytimeen, ja välttää liikaa rönsyilyä.
Innovaattoriksi kehittyminen edellyttää, että ymmärtää innovaatioprosessiin kuuluvat keskeiset asiat. Denningin mukaan tätä voi oppia lukemalla, mutta siihen liittyviä sosiaalisia taitoja, kuten parantaa tietoisuutta ja keskittymistä, laatia julistuksia ja toimintasuunnitelmia ja tehdä tarjouksia, ei voi oppia itseopiskelulla, vaan näiden taitojen oppimista helpottaa valmentaja tai opettaja. Denning muistuttaa, että innovaatioiden ei työssä tarvitse olla isoja, työyhteisön työtapoja voi oppia parantamaan kuka tahansa, innovaatiot eivät aina perustu uusiin ajatuksiin ja että innovaatioita tapahtuu kaikenlaisilla ja -kokoisilla aloilla ja yhteisöillä.
Mietin, että voisiko innovaattoriksi kehittyä ilman että ymmärtää mitään innovaatioprosessista, mutta olisi vain käytännön kautta huomannut jotkut käytännöt tehottomiksi ja saanut idean kehittää niitä paremmiksi. Vai onko innovaattori sellainen unifield- ammatti, että voi toimia alalla kuin alalla tavallaan ulkopuolisena.
Soveltaminen
Soveltamisella tarkoitetaan moniammatillisen työryhmän yhteistyötä, jossa eri tietojenkäsittelyn sovellusalueilla työskentelevät pyrkivät erilaisten tietojenkäsittelyjärjestelmien, tai niitä tukevien ydinteknologioiden kehittämiseksi. Suunnittelussa keskeiseksi teemaksi on noussut ihmiskeskeinen suunnittelu, jonka yksi keskeisistä periaatteista on kuunnella käyttäjiä. Mutta koska käyttäjillä ei useinkaan ole riittävästi näkemystä siitä mitä hyvään suunnitteluun tarvitaan, ohjelmistoammattilaisen tulee tietää, mm. miten käytettävyyttä mitataan ja miten päätöksiä tehdään.
Ihmiskeskeisessä suunnittelussa ohjelmistoammattilaiset tarvitsevat taitoja, jotka Ahmed Seffah on koonnut listaksi, joka on jaoteltu välttämättömiin edellytksiin, erityistaitoihin ja yleistaitoihin. Välttämättömiin edellytyksiin kuuluu tietenkin perustaidot ohjelmistojen kehittämiseksi, ohjelmoitikielten hallinta ja tietokoneen käyttötaito. Erityistaitoihin kuuluu joukko taitoja, jotka liittyvät mm. kykyyn/ taitoon analysoida ja määritellä käyttäjien ominaisuuksia ja heidän vaatimuksia, ottaa huomioon ihmisen ja koneen vuorovaikutuksessa esiin tulevat haasteet, visuaalisuuteen liittyvät valinnat, ennen ohjelman käyttöönottoa suoritettavat asiat kuten prototyyppien tekeminen ja testaus, sekä varsinaiseen käyttöön liittyvät asiat, kuten käyttöohjeet ja suoritusaikaiset opasteet. Lisäksi erityistaitoihin kuuluu mm. eri laitteille tarkoitetut sovellukset sekä web-sovellukset. Kolmenteen ryhmään, eli yleistaitoihin Seffah on koonnut taitoja, jotka ovat olennaisia ihmiskeskeisen suunnittelun tehtävissä, koska ne parantavat käyttäjien ja muiden asianosaisten kanssa käytävää yhteistoimintaa. Näitä taitoja ovat mm. käyttäjäkeskeisten dokumenttien kirjoittaminen, ohjelmistojen tutkiminen empiirisesti ja kustannustehokkaasti sekä kommunikointi monialaisessa ryhmässä.
cs.helsinki.fi
cs.hut.fi
luentomoniste
cs.hut.fi
luentomoniste
