Matematiikan tarve ohjelmistotyössä

Antti Valmari

Tampereen teknillinen korkeakoulu
Ohjelmistotekniikan laitos
PL 553, 33101 TAMPERE
ava@cs.tut.fi

Artikkeli ilmestyi lehdessä Arkhimedes 2/2001 ss. 18--22. Muokkasin HTML-muotoon 10.5.2001.

Ohjelmistotyön uskotaan vaativan matemaattista lahjakkuutta ja koulutusta. Kuitenkin ohjelmistoammattilaisten enemmistö sijoittaa matematiikan kurssit hyödyttömimpien opinnoissaan suorittamiensa kurssien joukkoon. Missä vika?

Lethbridgen tutkimus

Arvovaltaisen IEEE Computer -lehden toukokuun 2000 numeron kansikuvajuttuna oli Ottawan yliopistossa tehty ohjelmistoammattilaisten osaamistarpeita kartoittava kyselytutkimus [7]. Teollisuudessa työskenteleviltä ammattilaisilta oli kysytty kaikkiaan 75:stä aiheesta kuinka paljon vastaaja oli opinnoissaan oppinut aiheesta, kuinka hyvin vastaaja osaa aihetta nyt, kuinka tärkeää aiheen yksityiskohtainen tieto on ollut vastaajan työn kannalta, ja mikä on ollut aiheen yleissivistävä merkitys vastaajalle ammatillisesti ja muuten. Tutkimuksen tulokset ovat saatavana Internetin kautta [6].

Tärkeysjärjestyslistan kärkipäähän pääsi sekä perinteisiä että moderneja ohjelmistotyöhön liittyviä aiheita, kuten yksittäiset ohjelmointikielet (1. sija), tietorakenteet (2.), ohjelmistojen suunnittelumallit (3.) ja ohjelmistoarkkitehtuurit (4.). Tärkeiksi koettiin myös esimerkiksi käyttöliittymät ja käytettävyys (6.), etiikka ja ammatillinen toiminta (8.) sekä esiintymistaito (10.). Vastaajien jakaumasta kertonee jotain se, että lähimmäksi kärkeä päässyt taloustieteellinen aihe oli markkinointi sijalla 51.

Differentiaali- ja integraalilaskenta, kombinatoriikka, Laplace- ja Fourier-muunnokset sekä differentiaaliyhtälöt olivat kymmenen viimeisen joukossa. Paljon paremmin eivät menestyneet lineaarialgebra ja matriisit (56. sija), informaatioteoria (60.), graafiteoria (61.) ja jonoteoria (62.). Joukko-oppi oli sijalla 48 ja predikaattilogiikka sijalla 39. Parhaiten menestynyt matematiikan piiriin kuuluva aihe oli todennäköisyyslaskenta ja tilastotiede sijalla 31. Korkeimmalle sijoittuneet selkeästi teoreettiset aiheet olivat ohjelmointikielten teoria (28. sija) ja algoritmien kompleksisuusanalyysi (30.). Fysiikka oli sijalla 59 ja kemia 73.

Lethbridgen tulosten paikkansapitävyyttä voi epäillä sillä perusteella, että vastaajien joukko oli vain vajaa 200 ja kovasti painottunut Pohjois-Amerikkaan. Kuitenkin ohjelmistoammattilaisille suunnatun matematiikan opetuksen epäonnistuminen on ollut Suomessa nähtävissä jo pitkään, jos vain on suostunut uskomaan näkemänsä. Niin kauan kuin olen alalla ollut, on kohtaamieni ohjelmistoammattilaisten valtaosan suhtautuminen matematiikkaan vaihdellut välinpitämättömyydestä vihamielisyyteen. En minä heitä syytä: heidän oli aikanaan pakko opiskella vaikeaa matematiikkaa, joka ei sittemmin ollutkaan heille avuksi --- voiko heiltä odottaa muunlaista suhtautumista?

Valitettavasti ohjelmistoalan varauksellinen suhtautuminen matematiikkaan on ainakin Suomessa laajentunut kielteiseksi ennakkoasenteeksi kaikkeen teoreettiselta haiskahtavaan. Tämä näkyy selvästi siinä, että määrittelyssä ja suunnittelussa laajalti käytetyt kaaviomenetelmät ovat semantiikaltaan hyvin epämääräisiä silloinkin, kun yksikäsitteisyys ja tarkkuus on mitä ilmeisimmin ollut tavoitteena. Tämä näkyy myös yritysten suhtautumisessa henkilökuntansa jatko-opiskeluaikeisiin. (Onneksi asenteet ovat alkaneet hitaasti sulaa.)

Ohjelmistotyö on muuttunut

Vielä 20 vuotta sitten ohjelmistotyön pääpaino oli toisaalta numeerisissa sovelluksissa, kuten kemiallisten prosessien ohjauksessa ja osittaisdifferentiaaliyhtälöiden ratkaisemisessa; ja toisaalta kaupallishallinnollisissa sovelluksissa, kuten pankkitilien ylläpidossa.

Vaikka tällaiset sovellukset eivät ole mihinkään kadonneet --- päinvastoin, niitä tehdään enemmän kuin ennen ---, on muiden sovellusten merkitys kasvanut vielä paljon enemmän, niin että ohjelmistotyön kokonaiskuva on tänään aivan toisenlainen. Tietoliikenne ja Internet ovat kasvaneet suuriksi sovellusalueiksi. Koska mikroprosessorit ovat nykyisin tehokkaita ja halpoja, valtava määrä ohjelmistotyötä uppoaa erilaisiin laitteisiin, kuten hisseihin ja lukkiutumattomiin jarruihin. Myös toimisto-ohjelmistot ja pelit ovat merkittäviä alueita, vaikkakaan eivät Suomessa keskeisiä.

Toinen merkittävä muutosvoima on ohjelmistojen koon nopea kasvu. Mitä isompi ohjelmisto on, sitä enemmän siinä on sisäisiä riippuvuuksia, puhtaasti ohjelmistoteknisiä abstrakteja rajapintoja, monimutkaisia algoritmeja, rinnakkain toimivia osia ja muuta sellaista, ja sitä varmemmin se joudutaan tekemään monen ihmisen yhteistyönä ja kenties jopa monessa paikassa. Tästä seuraa, että ohjelmiston laadinnan kustannukset kasvavat nopeammin kuin lineaarisesti suhteessa ohjelman kokoon. Eräässä tutkimuksessa työn määrän todettiin olevan suunnilleen kertaluokkaa ( rivien määrä )1,43.

Ohjelmistotyön menetelmät ovat muuttuneet suuresti viimeksi kuluneen vuosikymmenen aikana. Alimmalla eli kielten tasolla tapahtunutta kehitystä kuvaa hyvin se, että helppolukuinen ja varsin kattava Pascal-kielen oppikirja 1970-luvun puolenvälin tienoilta [5] jäi selvästi alle 200 sivun, kun taas C++-kielen perusteos vuodelta 1997 [9] on hyvin tiivis, vaikealukuinen ja ylimalkainenkin, mutta silti yli 900 sivua pitkä. Korkeammalla tasolla ohjelmistosuunnittelijan on nykyisin hallittava oliomenetelmiä, UML-notaatiota, asiakas-palvelin-ohjelmointia ja monia muita asioita, joista oli 10 vuotta sitten korkeintaan kuultu huhuja. Hankkeiden koon kasvu on kasvattanut hyvän ohjelmointityylin, dokumentoinnin, testauksen, projektin hallinnan ja version hallinnan merkitystä.

Kuitenkaan ohjelmistot eivät valmistu ajallaan, ja niiden laadussa on pahoja puutteita.

Eikö differentiaalilaskentaa tarvita sovellusten vuoksi?

Tarvitaan, mutta yllättävän vähän.

Silloinkin kun järjestelmän tehtävänä on säätää jotakin tosimaailman prosessia, on säätöalgoritmin suunnittelu ja toteuttaminen vain pieni osuus ohjelmiston laadintatyöstä. Paljon enemmän työtä menee käyttöliittymään, järjestelmän sisäiseen ja ulkoiseen tietoliikenteeseen sekä tietovarastoihin. Siksi riittää, että ohjelmiston toteuttajista yksi ymmärtää säätämisen ja säädettävän prosessin lainalaisuudet syvällisesti. Toisaalta tälle yhdelle usein riittää sivuaineen tasoinen ohjelmisto-osaaminen. Niinpä differentiaalilaskennan merkitys jää keskimäärin vähäiseksi jopa sulautettuja järjestelmiä valmistavissa yrityksissä työskentelevien ohjelmistoammattilaisten keskuudessa.

Lähes puolet Lethbridgen tutkimukseen vastanneista oli tehnyt reaaliaikaisia ohjelmistoja, ja viidesosa ei ollut muita tehnytkään. Säätöjärjestelmien tekijät olivat siis aineistossa hyvin edustettuina. Silti Lethbridge oli tehnyt sellaisenkin havainnon, että mitä paremmin vastaaja katsoi osaavansa differentiaalilaskentaa, sitä vähäisemmäksi hän arvioi sen merkityksen [6, s. 51]. Missään muussa aiheessa tällaista riippuvuutta ei ollut tai se oli toisin päin.

Differentiaalilaskentaa tarvitaan toki laitetekniikassa. Mutta tietotekniikasta hämmästyttävän pieni osa on laitetekniikkaa. Suomen Akatemian Luonnontieteiden ja tekniikan tutkimuksen toimikunta on todennut, että ``Arvioiden mukaan ohjelmistokehitykseen suuntautuu usein yli puolet sähkö- ja elektroniikka-alan yritysten tuotekehityspanostuksesta'' [3, s. 174] (korostus AV:n). Vaikka Tampereen teknillisen korkeakoulun Tietotekniikan osastossa on vahvat Signaalinkäsittelyn, Tietokonetekniikan ja Tietoliikennetekniikan laitokset, osaston diplomitöistä reilusti yli puolet tehdään Ohjelmistotekniikan laitokselle.

Ohjelmistoammattilaisia tarvitaan elektroniikkateollisuuden lisäksi SSH:lle toteuttamaan salausohjelmistoja, Sonera Zediin tuottamaan kännykkään lisäarvopalveluja, VR-konserniin käsittelemään GPS-paikantimien tuottamia ja kännykkäverkon kautta välitettyjä junanvaunujen sijaintitietoja ja niin edelleen. He tarvitsevat differentiaalilaskentaa vielä vähemmän kuin elektroniikkateollisuuden ohjelmistoammattilaiset.

Differentiaalilaskennan tarpeellisuus tietotekniikan ammattilaisille on siis suurelta osin katteeton myytti.

Mitä tilalle --- vai eikö mitään?

Väliotsikon kysymykseen on olemassa arvovaltainen vastaus. IEEE Computer Society ja Association for Computing Machinery tekevät noin kymmenen vuoden välein suosituksen ``computing''-alan koulutusohjelmien sisällöksi. Vuoden 2001 suosituksen luonnos on saatavana Internetissä [4].

Edellisessä suosituksessa tietojenkäsittelyllinen oppiaines oli jaettu yhdeksään alueeseen: algoritmit ja kompleksisuus, ohjelmointikielet ja niiden toteutus, tietokoneen rakenne ja toiminta, käyttöjärjestelmät, ihmisen ja koneen vuorovaikutus, älykkäät järjestelmät, tietokannat, ohjelmistotuotanto sekä tieteellinen laskenta. Nyt oli nähty tarpeelliseksi perustaa viisi uutta aluetta.

Internetin esiinmarssi pakotti nostamaan grafiikan ja visualisoinnin sekä verkkokeskeisen laskennan omiksi alueikseen. Yhteiskunnallisten ja juridisten asioiden alueen perustaminen heijastaa tietojenkäsittelyn yhteiskunnallisen merkityksen kasvua.

On ehkä yllättävää, että neljäs uusi alue on ohjelmoinnin perusteet. Edellisessä suosituksessa ohjelmoinnin perusopetus oli jätetty valinnaiseksi, koska silloin ennustettiin sen siirtyvän lukioihin. Niin ei kuitenkaan käynyt. Ohjelmoinnissa viime aikoina tapahtunut muutos näkyy sekä alueen sisällössä että koossa. Alue sisältää enemmän kaikille välttämättömäksi katsottua asiaa kuin mikään muu alue.

Ensimmäisenä alueiden luettelossa esiintyy uusi alue ``diskreetit rakenteet''. Sisällöltään se on joukko-oppia, logiikkaa, todistustekniikoita, kombinatoriikan alkeita, graafiteoriaa ja puita sekä diskreettiä todennäköisyyslaskentaa. Suosituksen osan II luvun 12.1 mukaan diskreetit rakenteet otettiin alueeksi siksi, että monessa tapauksessa tietojenkäsittelyn laitokset joutuvat opettamaan sen itse. Välttämättömän asian määrällä mitattuna alue on toiseksi suurin. Se ja ohjelmoinnin perusopetus oli määritelty kokonaisuudessaan välttämättömiksi.

Lisäksi suosituksessa ehdotetaan, että jokaiselle tietojenkäsittelijälle opetetaan matemaattisten kykyjen kehittämiseksi vielä jotakin. Se voi olla esimerkiksi tilastotiedettä, differentiaalilaskentaa, lineaarialgebraa, numeerisia menetelmiä, lukuteoriaa tai symbolista logiikkaa. Numeeriset menetelmät tulevat tietysti esiin myös tieteellisen laskennan alueessa, mutta opiskelija ei välttämättä suorita siitä mitään, sillä se on ainoa alue, josta mitään ei määritelty kaikille pakolliseksi. Lethbridgen tutkimuksessa numeerisen analyysin sijoitus oli 52.

Suositusta lukiessa kannattaa pitää mielessä, että suomalaiset perustutkinnot ovat laajempia kuin amerikkalaiset. Täkäläisessä tutkinnossa on ainakin yksi sivuaine jonka sisältö ei ole pääaineen suunnittelijoiden määrättävissä, ja ainakin teknillisissä yliopistoissa opiskelijoilla on olennaisesti suuremmat valinnanvapaudet kuin suosituksessa on ajateltu. Diskreettien rakenteiden ehdotettu sisältö on mielestäni vähäinen ja osittain huonosti valittu. Kombinatoriikan ja graafien tilalla voisi olla vaikka lausekkeiden rakenteen teoriaa, BNF:ää, määritelmien muodostamisen ja sisällön analyysin opetusta tai reaktiivisuuden ja rinnakkaisuuden perusmatematiikkaa.

Kohti parempaa ohjelmistomatematiikkaa

Mielestäni ensimmäinen askel onnistuneen ohjelmistomatematiikan opetuksen suunnittelussa on sen korostaminen, että sovelluksen tarpeet ja ohjelmistotyön tarpeet ovat eri asioita. Matriisilaskentaa tarvitaan varmasti kun laaditaan kolmiulotteisten kappaleiden kuvia näytössä pyörittäviä ohjelmia, mutta sitä ei tarvita siksi, että ohjelmoidaan, vaan siksi, että sovellusalueena on 3D-mallintaminen. Ohjelmistotyön tarpeet ovat myös eri asia kuin muun tietotekniikan tarpeet.

Lineaarialgebraa, numeerisia menetelmiä tms. tarvitseva sovellusalue vaatii yleensä paljon muutakin erikoistietoa. Alueesta on siksi mielekästä muodostaa suuntautumisvaihtoehto, sivuaine tai pääaine, jossa opetetaan kaikki sille välttämätön. Mielestäni lineaarialgebran paikka on siellä, eikä kaikkien ohjelmistoammattilaisten yleisopinnoissa. Väite ``melkein jokainen ohjelmistoammattilainen tulee kuitenkin tarvitsemaan lineaarialgebraa'' on ehkä joskus pitänyt paikkansa, mutta ei todellakaan enää pidä.

Kaikkien ohjelmistoammattilaisten opintoihin varmuuden vuoksi sijoitettu, mutta todellisuudessa valtaosalle tarpeeton matematiikka on haitallista ainakin kahdella tavalla. Opiskelijat kokevat sen turhaksi rasitteeksi, josta tulee valmistumisen hidaste tai jopa este, ja joka kasvattaa vihamielisiä asenteita matematiikkaa ja teoriaa kohtaan. Ehkä vielä pahempaa on kuitenkin ollut se, että kun opetusohjelmassa on ollut sopiva määrä matematiikan opintoviikkoja, on erehdytty luulemaan, että ohjelmistotyön matematiikan tarpeet on hoidettu.

Toinen askel on huomion kiinnittäminen siihen miten aines opetetaan. Formaalit kielet olivat Lethbridgen tutkimuksessa sijalla 36 ja automaattiteoria joutui tyytymään sijaan 49, vaikka kummallakin on välittömiä ja erinomaisesti toimivia sovelluksia hierarkkisten rakenteiden ja tiedostomuotojen suunnittelussa ja tekstimuotoisten tiedostojen lukemisessa. Vika lienee siinä, että opiskelija ei oma-aloitteisesti oivalla, että yhteysriippumattomat kieliopit ovat sama asia kuin Backus-Naur Format, ja että ne voi esittää havainnollisesti niin sanotuilla ratapihakaavioilla. Jos eivät opiskelijat ole tällaisia yhteyksiä hoksanneet tähänkään mennessä, niin vielä vähemmän tulevaisuudessa, kun sisäänottojen kasvattamisen myötä keskimääräiset valmiudet laskevat koko ajan.

Kyse on siis samasta asiasta kuin että differentiaalilaskenta opetetaan tuleville koneinsinööreille eri kirjoista ja eri tavalla kuin matematiikan pääaineopiskelijoille. Uskon, että joukko-opin heikko sijoitus Lethbridgen tutkimuksessa johtuu siitä, että sitä opetettaessa ei ole riittävän selvästi näytetty, miten sitä voi käyttää hyväksi ohjelmistotyössä. Tarvitsisimme ``Advanced Engineering Calculus'' -kirjan rinnalle kirjoja tyyliin ``Programmers' Introduction to Automata and Formal Languages'', ``Set Theory for Software Engineers'' ja ``Advanced Logic for Practical Computer Scientist''. Jotkut kirjat kuten [1,2] ovat ottaneet askelia tähän suuntaan, mutta vielä kuluu aikaa ennen kuin ne puhuvat kunnolla ohjelmistoihmisten kieltä.

Edes teoreettinen tietojenkäsittelytiede ei ole oikea tapa opettaa tulevia ohjelmistoammattilaisia. Tähänkin on kiinnitetty pohjoisamerikkalaisessa keskustelussa huomiota [8]. Vaikka koulutusohjelma olisi nimeltään ``tietojenkäsittelytiede'' ja sijaitsisi luonnontieteellisen tiedekunnan tietojenkäsittelytieteen laitoksessa, on se silti ilman muuta ohjelmistoammattilaisten koulutusohjelma, jos sen sisäänotto on suuri.

Suomi tarvitsee myös aitoja tietojenkäsittelyteoreetikoita. Heitä voidaan tuottaa ohjelmistoammattilaisten koulutusohjelmissa tarjoamalla sopivia syventäviä opintoja. Olen toisessa yhteydessä esittänyt lyhyesti syitä, miksi kuitenkin saattaisi olla parempi kouluttaa heidät erillisissä pienen sisäänoton koulutusohjelmissa [10].

Ohjelmistomatematiikan sisältö

Mitkä sitten ovat ohjelmistotyön omat matematiikan tarpeet? Ohjelmistotyön suurin haaste nykyisin on hankkeiden suuret koot sekä laatu- ja aikatauluongelmat. Niistä selviämiseksi on parinkymmenen vuoden ajan kiinnitetty kasvavaa huomiota sellaisiin asioihin kuin vaatimusten keruu, projektin hallinta, version hallinta ja testaus. Nämä aiheet ovat Lethbridgen tärkeysjärjestyslistassa lähellä kärkeä, mutta matematiikkaahan ne eivät tietenkään ole.

Mielestäni matematiikka voisi olla parhaiten avuksi tarjoamalla työkaluja abstraktioiden tunnistamiseen ja muotoiluun sekä niistä päättelemiseen. Ohjelmistotyön pääpaino ei enää pitkään aikaan ole ollut jokaiselle tuttujen asioiden koodaamisessa ohjelmointikielelle. Paljon keskeisempää on esimerkiksi käyttäjien tarpeiden kokoaminen hajanaisista ja välillä keskenään ristiriitaisista toivomuksista yhtenäiseksi johdonmukaiseksi esitykseksi, jota voi käyttää suunnittelun lähtökohtana. Äärimmilleen tämä korostuu kansainvälisten standardien valmistelussa! Myös ohjelman osien välisten rajapintojen, tietovarastojen ja tiedostomuotojen sekä ohjelmakomponenttikirjastojen suunnittelu vaatii hyvää abstraktioiden tajua, jotta lopputulos olisi tarkoituksenmukainen.

Kun abstraktiot on tunnistettu, ne pitää esittää muiden samaan hankkeeseen osallistuvien ymmärtämässä muodossa. Esitystavan pitää olla riittävän täsmällinen, koska muussa tapauksessa osapuolet ymmärtävät jonkin tärkeän yksityiskohdan eri tavalla. Ristiriita ei useinkaan paljastu ennen kuin hankkeen loppuvaiheessa osia toisiinsa liitettäessä huomataan, että ne eivät pelaa kunnolla yhteen. On yleisesti tunnettu ohjelmistotuotannon tosiasia, että tällaisten virheiden korjaaminen on erityisen kallista.

Tietojenkäsittelyteoreetikot ovat ehdottaneet tähän ratkaisuksi niin sanottuja formaaleja määrittelymenetelmiä. Niistä on jo sen verran kokemuksia, että mielestäni voidaan todeta, että ne toimivat silloin kun laatu ja luotettavuus ovat erityisen tärkeitä --- esimerkiksi ydinvoimalan ohjausjärjestelmän suunnittelussa --- mutta useimmiten ne ovat kömpelöitä ja tuottamiinsa hyötyihin nähden aivan liian kalliita käyttää. Niiden perusvika on mielestäni se, että ne pakottavat formalisoimaan liikaa ja liian valmiiksi mietityn mallin mukaan. Lethbridgen tutkimuksessa ne olivat juuri ja juuri puolivälin yläpuolella (37.). Sijoitus vihjaa, että formaaleista määrittelymenetelmistä on apua abstraktioiden hallinnassa, mutta ihanteellinen ratkaisu ne eivät ole.

Matemaatikot ovat mestareita muotoilemaan asiat niin, että olennainen on sanottu täsmällisesti ja epäolennaiseen ei ole tuhlattu mustetta. Tämän taidon opettaminen tuleville ohjelmistoammattilaisille olisi suuri palvelus.

Kun abstraktio on muotoiltu, on välttämätöntä kyetä lukemaan, mitä muotoilu täsmälleen ottaen sanoo, ja minkälaisia seurausvaikutuksia sillä on. Esimerkiksi suunnatun graafin tuttu määritelmä (V, E) : E osajoukko V2 sallii eristyksissä olevat solmut, mutta ei kahta kaarta samojen solmujen välillä samaan suuntaan. Edellä mainitsemani kalliita virheitä aiheuttavat yksityiskohdat ovat usein luonteeltaan tämän kaltaisia. Siksi toivon, että matematiikan opetuksessa opetettaisiin ennakoimaan määritelmien seurauksia ja tarkistamaan, että määritelty käsite on myös haluttu käsite eikä vain samalta kuulostava.

Tällaisen ajattelutavan opettaminen on tietysti vaikeampaa kuin ennalta sovittujen sisältöjen opettaminen. Kun yhdessä TTKK:n matemaatikkojen kanssa pohdimme tätä, eräs heistä ehdotti klassisen geometrian kurssia. Minusta ajatus on kokeilemisen arvoinen!

Lopuksi

Siitä, mitä yllä totesin, seuraa, että sekä perinteinen insinöörilähestymistapa että perinteinen matemaatikkojen lähestymistapa ovat osoittautuneet huonosti toimiviksi ohjelmistoalalla. Miten se on mahdollista? Miksi vuosisatojen aikana hioutuneet menetelmät epäonnistuvat näennäisesti helpossa tehtävässä?

Ihmiskunta on jo kauan muodostanut pieniä täsmällisiä aineettomia kohteita, esimerkiksi matemaattisia määritelmiä. Ihmiset ovat tehneet myös suuria epätäsmällisiä aineettomia kohteita --- muun muassa elokuvia --- sekä suuria täsmällisiä aineellisia kohteita, kuten avaruusaluksia. Mutta koskaan ennen ohjelmistojen paisumista nykyisiin mittoihinsa ihmiset eivät ole tehneet kohteita, jotka ovat samanaikaisesti suuria, täsmällisiä ja aineettomia.

Viitteet

  1. Grassmann, W. K. & Tremblay, J.-P.: Logic and Discrete Mathematics, A Computer Science Perspective. Prentice-Hall 1996, 750 p.
  2. Hein, J. L.: Discrete Structures, Logic, and Computability. Jones and Bartlett 1995, 866 p.
  3. Husso, K., Karjalainen, S. & Parkkari, T. (toim.): Suomen tieteen tila ja taso, Katsaus tutkimukseen ja sen toimintaympäristöön Suomessa 1990-luvun lopulla. Suomen Akatemian julkaisuja 6/00, Helsinki 2000, 308 s.
  4. IEEE Computer Society and Association for Computing Machinery: Computing Curricula 2001. http://www.computer.org/education/cc2001/.
  5. Jensen, K. & Wirth, N.: The Programming Language Pascal. Springer-Verlag 1975.
  6. Lethbridge, T. C.: The Relevance of Education to Software Practitioners: Data from the 1998 Survey. University of Ottawa Computer Science Technical Report TR-99-06, July 1999, http://www.site.uottawa.ca/%7etcl/edrel/.
  7. Lethbridge, T. C.: ``What Knowledge Is Important to a Software Professional?'' IEEE Computer, May 2000, pp. 44--50.
  8. Parnas, D. L.: ``Software Engineering Programs Are Not Computer Science Programs''. IEEE Software November/December 1999 pp. 19--30.
  9. Stroustrup, B.: The C++ Programming Language, Third Edition. Addison-Wesley 1997, x+910 p.
  10. Valmari, A.: ``Tietotekniikan huippukoulutus on vinoutunutta''. Puheenvuoro, Suomen Kuvalehti 18, 5.5.2000 ss. 72--73.