VAASAN YLIOPISTO 

 

Markkinoinnin ja viestinnän yksikkö 

 

Teknisen viestinnän maisteriohjelma 

 

 

 

 

 

 

 

 

 

 

 

 

 

Taina Prusti 

 

Termit ohjelmistoprojektissa 

 

Lähtökohtia terminologisen prosessin suunnitteluun 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Soveltavan kielitieteen pro gradu -tutkielma 

 

Vaasa 2018  



1 

 

SISÄLLYS 

KUVAT               2 

KUVIOT                2 

TAULUKOT              3 

TIIVISTELMÄ              5 

1 JOHDANTO 7 

1.1 Tutkimuksen tavoite 8 

1.2 Tutkimusaineisto 10 

1.3 Tutkimusmenetelmä 12 

1.4 Kohdeyritys 14 

2 OHJELMISTOTUOTANTO JA SIIHEN LIITTYVÄ DOKUMENTAATIO 16 

2.1 Ohjelmistotuotantoprosessit ja -projektit 16 

2.2 Kohdeyrityksen ohjelmistotuotantoprosessi ja dokumentit 20 

3 TERMISTÖN TARKASTELUN LÄHTÖKOHTIA 25 

3.1 Termit ja käsitteet terminologiatyön peruselementteinä 25 

3.2 Terminmuodostusmenetelmiä 27 

3.3 Hyvän termin ominaisuuksia 28 

3.4 Terminpoiminta 30 

4 YRITYSTEN TERMINOLOGIATYÖ 32 

4.1 Televiestintäalan termistö ja standardisointi 32 

4.2 Terminologiatyö ja termistönhallinta 33 

4.3 Terminologiatyön ja termistönhallinnan merkitys yrityksissä 35 



2 

 

4.4 Terminologiatyön vaiheita 40 

5 ANALYYSI OHJELMISTOPROJEKTIN TERMEISTÄ 45 

5.1 Aineistolähteiden esittely 45 

5.2 Termien poiminta projektidokumentaatiosta 47 

5.3 Termien määrällinen tarkastelu eri projektivaiheissa 50 

5.4 Termien arviointi 58 

5.4.1 Termien rakennetyypit ja sanaluokat 59 

5.4.2 Aineiston termien rakenteen ja muodon tarkastelua 63 

5.4.3 Aineiston termien suhde käsitteisiin 66 

5.4.4 Aineiston termien käytön johdonmukaisuus 68 

5.5 Projektiryhmän jäsenten osallistuminen 69 

5.6 Yhteenveto 72 

6 TERMINOLOGISIA TOIMENPIDE-EHDOTUKSIA 

OHJELMISTOPROJEKTILLE 75 

7 PÄÄTELMÄT 84 

LÄHTEET 89 

KUVAT 

Kuva 1. DOORS-vaatimustenhallintaohjelmiston ulkoasu 22 

 

KUVIOT 

Kuvio 1. Projektin eri vaiheissa syntyvää dokumentaatiota 11 

Kuvio 2. Esimerkki satelliittimallin käytöstä yhden projektidokumentin osalta 13 

Kuvio 3. Ohjelmistotuotantoprojektin jakautuminen 17 

Kuvio 4. Ohjelmistotuotantoprosessi ja tukiprosesseja 18 

Kuvio 5. Prosessin kehittämishankkeen vaiheet 19 



3 

 

Kuvio 6. Kuvaus kohdeyrityksen tuoteprosessista 20 

Kuvio 7. Kuvaus kohdeyrityksen ohjelmistotuotantoprosessista 21 

Kuvio 8. Kohdeyrityksen teknisten dokumenttien rakenne 23 

Kuvio 9. Käsitemallikolmio 26 

Kuvio 10. Termien tarkasteluperiaatteita 29 

Kuvio 11. Tehokkaan termistönhallinnan tuomat hyödyt yritykselle 37 

Kuvio 12. Tehokkaan termistönhallinnan esteitä 39 

Kuvio 13. Sanastoprojektin vaiheet Nykäsen mukaan 41 

Kuvio 14. Sanastoprojektin suunnitteluvaiheessa käsiteltävät asiat 42 

Kuvio 15. Sanaston laatimisvaihe 43 

Kuvio 16. Satelliittimalli terminpoiminnan työkaluna 48 

Kuvio 17. Aineiston käsitejärjestelmän aloitusnoodit 49 

Kuvio 18. Account-termi päänoodina satelliittimallissa 49 

Kuvio 19. Poimittujen termien esiintymiskerrat dokumenteissa projektivaiheittain 52 

Kuvio 20. Poimittujen termien yksittäiset esiintymiset projektivaiheittain 53 

Kuvio 21. Termien määrät sen mukaan, monessako dokumentissa ne esiintyivät 54 

Kuvio 22. Evaluointi- eli testausvaiheen dokumentit termimäärineen 56 

Kuvio 23. Asiantuntijalle läpinäkyvää mutta ei välttämättä yksiselitteistä 67 

Kuvio 24. Terminologisen työn aloittaminen yrityksessä 75 

Kuvio 25. Termiongelmien tunnistaminen 76 

Kuvio 26. Terminologisen prosessin hahmottelu 77 

Kuvio 27. Ihmisten valmisteleminen muutokseen 78 

Kuvio 28. Pilottiprojekti 79 

Kuvio 29. Terminologinen työ ohjelmistoprojektin suunnitteluvaiheessa 80 

Kuvio 30. Vapaasti esitettyjä käsitesuhteita satelliittimallissa 81 

Kuvio 31. Terminologiatyö projektin kehitys-, evaluointi- ja julkaisuvaiheissa 82 

Kuvio 32. Ylläpito ja seuranta 83 

 

TAULUKOT 

Taulukko 1. Aineiston asiakasdokumentaatiossa esiintyviä merkintätapoja 24 

Taulukko 2. Aineistolähteinä toimivat dokumentit 46 



4 

 

Taulukko 3. Poimittujen termien määrät dokumenteissa 50 

Taulukko 4. Aineiston termien rakennetyypit 59 

Taulukko 5. Aineiston termien sanaluokat 61 

Taulukko 6. Aineistossa esiintyneitä prefiksejä ja suffikseja 64 

Taulukko 7. Esimerkkejä aineiston sanojen alkuperästä 65 

Taulukko 8. Projektin jäsenten osallistuminen dokumentaation tuottamiseen 70 

 

  



5 

 

 

VAASAN YLIOPISTO 

Markkinoinnin ja viestinnän yksikkö 

Tekijä:         Taina Prusti 

Pro gradu -tutkielma:            Termit ohjelmistoprojektissa  

      Lähtökohtia terminologisen prosessin suunnitteluun 

Tutkinto:        Filosofian maisteri 

Koulutusohjelma/ oppiaine: Teknisen viestinnän maisteriohjelma/Soveltava kielitiede 

Suuntautumisvaihtoehto:      Terminologia 

Valmistumisvuosi:       2018 

Työn ohjaaja:       Anita Nuopponen 

 

 

TIIVISTELMÄ:  

 

Tutkimuksen tavoitteena oli selvittää lähtökohtia terminologiatyön tuomiseksi osaksi 

ohjelmistoprojektia. Tätä tutkittiin tarkastelemalla televiestintäalan yrityksen ohjelmisto-

projektia ja siinä käytettäviä käsitteitä ja termejä sekä projektin jäsenten osuutta termien 

käyttäjinä. Epäjohdonmukaisuudet käytetyssä termistössä voivat heikentää ohjelmisto-

tuotteen laatua, jota voidaan parantaa terminologiatyön avulla. Tulosten ja alan kirjalli-

suuden pohjalta annettiin toimenpide-ehdotuksia, miten terminologiatyön voisi ottaa 

osaksi ohjelmistoprosessia. Tutkimuksen viitekehyksenä toimi käytännön terminologia-

työhän liittyvä tutkimus ja aineistoa tarkasteltiin terminologisin ja systemaattisen käsite-

analyysin keinoin sekä määrällisesti. 

 

Tavoitteeseen etsittiin vastausta selvittämällä kohdeyrityksen ohjelmistoprojektin doku-

mentaation avulla sitä, millaisia termejä käytetään ohjelmistoprojektissa, missä projektin 

vaiheissa käsitteitä ja termejä esiintyy eniten, sekä ohjelmistoprojektin jäsenten osuus 

projektissa termien ja käsitteiden käyttäjinä. Lähestymistapa oli sekä laadullinen että 

määrällinen. Käytetyt termit täyttivät pääsääntöisesti toimiville termeille asetetut vaati-

mukset, mutta termien käytössä ja ulkoasussa oli vaihtelevuutta, ja tällaisia termejä 

esiintyi myös asiakkaille menevissä dokumenteissa. Termejä esiintyi eniten suunnittelu-

vaiheen vaatimusmäärittelydokumentissa sekä evaluointivaiheen testitapauksissa. Kaikki 

projektin jäsenet osallistuivat joko vaatimusmäärittelydokumentin tuottamiseen tai sen 

katselmointiin, mutta läpi projektin termien käytössä oli epäjohdonmukaisuuksia. 

 

Tutkimus osoitti, että terminologiatyö kannattaa aloittaa ohjelmistoprojektin suunnittelu-

vaiheessa, koska siinä käytetään eniten termejä ja siihen osallistuu eniten projektiryhmän 

jäseniä. Projektissa olisi hyvä olla vastuuhenkilö, joka varmistaa, että sovittua termistöä 

käytetään, ja että luotu sanasto on saatavilla ohjelmistoprojektin myöhemmissä vaiheissa. 

Termistön laadun varmistaminen tuotteessa, esimerkiksi sen käyttöliittymissä, dokumen-

teissa ja online-ohjeissa, olisi hyvä olla osa ohjelmistoprojektin evaluointivaihetta.  

 

AVAINSANAT: ohjelmistoprojekti, ohjelmistotuotanto, ohjelmistotuotantoprosessi, 

sanastotyö, televiestintä, terminologia, terminologiatyö 



 



7 

 

1 JOHDANTO 

 

Työelämässä esiintyy tilanteita, joissa samasta käsitteestä käytetään eri nimityksiä tai 

jonkin käsitteen määritelmä on erilainen riippuen siitä, keneltä määritelmää kysyy. Nämä 

epäjohdonmukaisuudet käytetyissä termeissä ja käsitteissä hankaloittavat monen työtä 

myös ohjelmistotuotantoalalla. On mahdollista, että yrityksissä ohjelmistosuunnittelijat 

ja -kehittäjät uskovat puhuvansa samasta asiasta, ja vasta myöhemmässä vaiheessa 

paljastuukin keskustelijoiden tarkoittaneen eri asioita. Sekaannusta aiheuttavat myös 

saman käsitteen eri nimitykset, ja tämä aiheuttaa ongelmia myöhemmin lokalisoinnissa 

ja käännöstyössä.  

 

Erikoisalojen viestintä ei ole haastavaa vain suhteessa alan ulkopuolisiin, vaan myös 

erikoisalan sisällä asiantuntijoiden välillä (mm. Sauberer 2011: 57). Ongelmat saattavat 

alkaa jo ohjelmistotuotteen suunnitteluvaiheessa, jatkuen siitä eteenpäin toteutusvaiheen 

ja testauksen kautta dokumentaatioon sekä vaikuttaa myös myyntiin ja asiakastukeen. 

Epäjohdonmukaisuudet termistössä saattavat aiheuttaa sen, että lopullinen 

ohjelmistototeutus on virheellinen, kun yhteneväinen käsitys käsitteiden sisällöstä 

puuttuu. 

 

Alihankkijana tai palveluntarjoajana epämääräisten termien käytöstä voi aiheutua virheitä 

toteutukseen, jos ohjelmiston tilaajan tai asiakkaan ymmärrys termien määritelmistä 

eroaa huomattavasti ohjelmiston toteuttajien käsityksestä. Tilauksien ja toimeksiantojen 

yhteydessä pelkkien vaatimusten määrittely ei myöskään riitä, jos tuotetussa 

ohjelmistossa tai sen osassa on käytössä termejä, jotka eivät ole yhteneväisiä muiden 

ohjelmistojen tai esimerkiksi tietokantojen kanssa. 

 

Ohjelmistoalan yrityksillä ei useinkaan ole tietoa tai resursseja panostaa käytettyyn 

termistön luomiseen tai huoltamiseen, vaikka terminologiatyölle on tarvetta. Lombard 

(2006: 160) kokee, että ideaalitilanteessa ohjelmistoyritykset ymmärtäisivät yhtenäisen 

termistön merkityksen tuotteen käytettävyydelle ja luotettavuudelle, asiakas-

tyytyväisyyteen ja mahdollisen tuotteen lokalisoinnin kannalta.  

 



8 

 

Monet yrityksille suunnatut kielipalvelut ja termistönhallintaratkaisut saattavat tuntua 

niistä liian suurilta ja kalliilta hankinnoilta, tai ei edes ymmärretä ongelmien johtuvan 

käytetyn termistön epäjohdonmukaisuudesta (Kremer, Kolbe & Brenner 2005: 293). 

Panostus terminologiseen työhön vaikuttaa kuitenkin tuotteen ja prosessien laatuun 

parantavasti ja auttaa erottumaan kilpailijoista (Steurs & Sauberer 2016: 9). Tässä 

tutkimuksessa lähdenkin tarkastelemaan lähtökohtia terminologiatyön ottamiseksi 

mukaan osaksi ohjelmistotuotantoprojektia. 

 

 

1.1 Tutkimuksen tavoite 

 

Tutkimukseni tavoitteena on selvittää lähtökohtia terminologiatyön tuomiseksi osaksi 

ohjelmistoprojektia. Tutkimukseni kohteena on televiestintäalan ohjelmistotuotanto-

projektissa käytettävät käsitteet ja termit. Selvitän ja kuvailen, millaista termistöä 

ohjelmistotuotantoprojektin eri vaiheissa käytetään, kuka käyttää ja miten. Tarkastelun ja 

aiemman tutkimuksen pohjalta teen toimenpide-ehdotuksia terminologiatyön ottamiseksi 

mukaan osaksi yrityksen ohjelmistotuotantoprosessia ja sen eri vaiheita.  

 

Tutkimukseni tavoitteen saavuttamiseksi haen vastauksia kolmeen kysymykseen. 

 

1) Millaista termistöä käytetään ohjelmistotuotantoprojektin teknisessä dokumen-

taatiossa? 

 

Ennen terminologiatyöprosessin suunnittelua yritykselle on hyvä kartoittaa millaisia 

käsitteitä ja termejä yrityksen teknisessä dokumentaatiossa esiintyy sekä niiden määrä ja 

käyttö ohjelmistotuotantoprojektin eri vaiheissa. Teknisellä dokumentaatiolla tarkoite-

taan yleensä tuotteiden suunnitteluun tai käyttöön liittyviä dokumentteja ja informaatiota 

eri muodoissa (esimerkiksi paperina, sähköisinä dokumentteina, piirroksina tai videoina). 

Tällaisia ovat esimerkiksi tuotteen suunnitteludokumentit, rakenteen kuvaukset sekä 

asennus- ja käyttöohjeet (Transcom 2017). 

 

 



9 

 

Alustavan tarkastelun pohjalta näytti, että osa ohjelmistotuotantoprojektin teknisestä 

dokumentaatiosta oli suhteellisen muuttumatonta projektista toiseen (esimerkiksi 

dokumentaation tai tuotteen metatietoa), minkä oletan vaikuttavan myös termeihin ja 

niiden käyttöön. Osa taas saattaa sisältää paljonkin uutta, esimerkiksi tuotteen uusiin 

ominaisuuksiin liittyviä käyttöliittymätermejä tai käyttöliittymäkenttien selityksiä. 

Lisäksi oletan, että voi esiintyä muita tilapäisempiä käsitenimityksiä sekä käsitteisiin 

liittyviä ilmauksia, jotka eivät ole varsinaisia termejä.  

 

Tarkastelen, millaisia ohjelmistotuotantoprojektin eri vaiheissa käytetyt termit ovat 

rakenteeltaan sekä millaisia haasteita niiden muodostamiseen ja käyttöön liittyy. Arvioin 

toteutuvatko hyvän termin ominaisuudet ohjelmistoprojektissa käytetyissä termeissä, vai 

olisiko esimerkiksi tarvetta harkita olemassa olevien termien parantamista, tai mihin olisi 

jatkossa hyvä kiinnittää erityistä huomiota käsitteiden nimeämisessä. Käytetyn termistön 

merkitystä käyttöliittymien käytettävyyden kannalta ovat tutkineet esimerkiksi Isohella 

& Nissilä (2015).  

 

2) Miten ohjelmistoprojektin eri vaiheet eroavat toisistaan termien ja erikoissanaston 

käytöltään?  

 

Ohjelmistoprojektin eri vaiheet eroavat toisistaan tarkoitukseltaan ja tehtäviltään. Myös 

projektin eri vaiheissa tuotetut tekniset dokumentit eroavat sisällöltään toisistaan, ja näin 

on oletettavissa, että niissä käytetään myös termejä ja muuta erikoissanastoa vaihtelevia 

määriä. On hyvä tunnistaa ne ohjelmistoprojektin vaiheet, joissa käytetään eniten erilaisia 

termejä ja erikoissanastoa. Näin niihin voi myös kiinnittää enemmän huomiota projektin 

aikana tehtävässä terminologiatyössä. Oletan, että ohjelmistoprojektin suunnitteluvaihe 

on tällainen, ja siinä käsitteiden läpikäynti ja määrittely helpottaisi muun projektin 

viestintää sekä dokumentaation tuottamista. Lisäksi vältyttäisiin projektin loppupuolen 

”kriisi-orientoituneesta termistönhallinnasta”, eli hätäisestä ja nopeasta oikeiden termien 

etsimisestä, kun aletaan tuottaa markkinointi- ja käyttömateriaaleja (Wright & Budin 

2001: 474–475). 

 

 



10 

 

3) Ketkä ohjelmistoprojektin jäsenet ovat keskeisiä termistön käyttäjinä? 

 

Jokaisessa ohjelmistoalan yrityksessä käytetään erikoiskieliä ja termejä ja tehdään 

terminologiatyötä osana tuotteiden ja ohjelmistojen suunnitteluun liittyvää toimintaa 

ilman, että sitä mielletään erikseen terminologiatyöksi. Yrityksen eri työntekijöillä on 

erilaisia rooleja ohjelmistotuotantoprojektin eri vaiheissa, ja tutkimuksessani tarkastelen, 

millaisissa rooleissa projektiryhmän jäsenet osallistuvat missäkin vaiheessa ohjelmisto-

projektiin ja miten he käyttävät alan termejä ja käsitteitä eri ohjelmistoprojektivaiheiden 

dokumentaatiossa.  

 

Oletan esimerkiksi, että järjestelmäsuunnitteluvaiheessa ohjelmistosuunnittelijan panos 

saattaa vaikuttaa termien syntymiseen ja käyttöön. Kehitysvaiheessa taas ohjelmoija voi 

muuttaa termejä luomalla käyttöliittymiin sopivia versioita suunnitteludokumentaation 

pohjalta. Tunnistamalla henkilöt, jotka osallistuvat erityisesti runsaasti termejä sisältä-

vien teknisten dokumenttien luomiseen ohjelmistoprojektin eri vaiheissa, voidaan 

kohdentaa terminologiatyön periaatteiden ja menetelmien ohjeistusta oikeille henkilöille. 

 

Näihin tutkimuskysymyksiini saamieni tulosten sekä käyttämieni lähteiden pohjalta 

muotoilen lopuksi toimenpide-ehdotuksia terminologiatyön ottamiseksi mukaan osaksi 

ohjelmistotuotantoprojektia. Nämä toimenpide-ehdotukset esittelen luvussa 6. 

 

 

1.2 Tutkimusaineisto 

 

Tutkimuksen aineistona käytän termejä ja käsitteitä, jotka kerään televiestintäalan 

yrityksen CBOSS Oy:n ohjelmistoprojektin aikana syntyvästä teknisestä 

dokumentaatiosta (kuvio 1). Tarkasteltavassa ohjelmistoprojektissa yrityksen tuotteeseen 

tehdään erääseen sen ominaisuuteen kohdistuvaa kehitystyötä. Tutkimusaineistoni lähteet 

koostuvat tietotekniikan ja televiestinnän erikoiskielisistä teksteistä, jotka syntyvät 

ohjelmistotuotantoprojektin aikana. Nämä projektin aikana tuotettavat tekniset 

dokumentit on määritelty yrityksen ohjelmistotuotantoprosessin kuvaukseen, joka antaa 

suuntaviivat jokaiselle yksittäiselle ohjelmistoprojektille. 



11 

 

Kerään termi- ja käsiteaineistoni englanninkielisestä projektidokumentaatiosta, jonka 

laajuus on noin 100 A4-sivua. Otan termin- ja käsitteenpoimintaan dokumentit kohteena 

olevan ominaisuuden lisäkehitysprojektista, joka sisältää suunnitteluvaiheen vaatimus-

määrittely- ja suunnitteludokumentaatiota, sen jälkeen ohjelmointi- eli kehitysvaiheen 

teknisen suunnittelun dokumentit ja siitä edelleen evaluointi- ja julkaisuvaiheen 

dokumentit kuten esitetty kuviossa 1.  

 

 

 

 

Kuvio 1. Projektin eri vaiheissa syntyvää dokumentaatiota 

 

 

Projektin suunnitteluvaiheessa tuotetaan tarkempaa suunnittelu- ja määrittelydokumen-

taatiota, joka kattaa uusien ominaisuuksien vaikutukset koko tuotteen kehittämiselle 

(HLD eli High Level Design). Lisäksi tässä vaiheessa tuotetaan ominaisuuskohtaiset 

vaatimusmäärittelydokumentit (FRS, Feature Requirement Specifications).  

 

Kehitysvaiheessa tarkennetaan vielä vaatimusmäärittelydokumentteja ja tuotetaan 

tarkemmat tekniset suunnittelu- ja määrittelydokumentit. Kehitysvaiheessa valmistuvat 

myös asiakasdokumentaation ensimmäiset versiot. Evaluointivaihe kattaa sekä 

Suunnittelu

•Suunnittelu- ja määrittelydokumentit (System Design)

•Vaatimusmäärittely (FRS)

Kehitys

•Tarkennettu FRS, RFE

•Tekniset suunnitteludokumentit (HLD, TD)

•Asiakasdokumentaatio

Evaluointi

•Ominaisuuksien testitapaukset

•Integrointitestaus

•Järjestelmätestaus

Julkaisu

•Markkinointidokumentaatio

•Asiakasdokumentaatio



12 

 

ohjelmistokehittäjien suorittaman integrointitestauksen että erityisen laadunvalvonnan 

suorittaman järjestelmätestauksen. Kaikista testeistä on olemassa kirjalliset 

testitapaukset, joita käytän myös aineistolähteinäni.  

 

Kaikki kohdeyrityksen ohjelmistotuotantoprojektin dokumentit katselmoidaan eli 

tarkastetaan ennen hyväksymistä. Myös nämä katselmointipöytäkirjat toimivat 

aineistolähteinä, joista kerään tietoa käsitteiden ja termien esiintymisestä ja käytöstä. 

Lisäksi saan niistä tietoa projektin jäsenten osallistumisesta dokumentaation tuottamiseen 

ja hyväksymiseen.  

 

 

1.3 Tutkimusmenetelmä 

 

Yhdistän tutkimuksessani laadullista ja määrällistä tutkimusta. Aineiston ja erilaisen 

tiedon keräämiseen käytän ns. satelliittimallia (Nuopponen 2016). Satelliittimalli on 

miellekarttamainen graafinen esitystapa, jota terminologisessa tutkimuksessa voidaan 

käyttää joustavasti esittämään ja järjestämään erilaista tietoa sekä käsitesuhteita niiden 

välillä. Käsiteanalyysissa satelliitin keskusnoodiin tulee pää- tai ydinkäsite, ja alanoodit 

voi jaotella erilaisten käsitesuhdetyyppien mukaan (kuvio 2). (Nuopponen 2016: 190, 

193) 

 

 



13 

 

 

 

Kuvio 2. Esimerkki satelliittimallin käytöstä yhden projektidokumentin osalta 

 

 

Ennen termien ja käsitteiden poimintaa teen satelliittimallin ohjelmisto-

tuotantoprojektista, johon merkitsen eri vaiheet, niistä syntyvät dokumentit ja eri 

vaiheisiin osallistuvat ja vaikuttavat henkilöt. Kerään aineiston oman erikoisalani 

dokumentaatiosta, jolloin alan erikoistietoni intuition lisäksi auttaa minua termin-

poiminnassa ja termien ja käsitteistön tunnistamisessa tekstissä. Käyn läpi 

aineistolähteeni ja kerään niistä satelliittimalleihin käsitteitä ja termejä. 

 

Saadakseni vastauksen ensimmäiseen tutkimuskysymykseeni, eli millaista termistöä 

ohjelmistotuotantoprojektin teknisessä dokumentaatiossa käytetään, siirrän 

satelliittimalliin kerätyt termit taulukkoon termien rakenteen ja muiden ominaisuuksien 

tarkastelua varten. Tutkin termejä rakentaakseni kuvan millaisia termejä ja muuta 

erikoissanastoa ohjelmistoprojektissa käytetään. Termeille on asetettu useita kriteereitä, 

joita niiden tulisi täyttää ollakseen hyviä (esim. ISO 704 2009: 38–41), ja kirjallisuudessa 

näitä kriteereitä on pohdittu ja jaoteltu vielä enemmän (esim. Isohella & Nuopponen 

2016). 

 

                 
      

              

    
          

              

       

                

       
                   

                  

            
                 

                

            

    

        

                      

                    

                        

            



14 

 

Vastatakseni toiseen tutkimuskysymykseeni siitä, miten ohjelmistoprojektin eri vaiheet 

eroavat toisistaan termien ja erikoissanaston käytöltään, lasken edellisessä tutkimus-

vaiheessa keräämieni termien määrät dokumenteittain ja projektivaiheittain. Lisäksi 

tarkastelen lähemmin termejä, jotka esiintyvät useimmissa dokumenteissa. Tarkoituk-

senani on tunnistaa ne ohjelmistotuotantoprojektin vaiheet, joihin kannattaa kiinnittää 

enemmän huomiota, kun halutaan parantaa yrityksen tuotteen termien yhtenäisyyttä. 

 

Vertailen myös projektin jäsenten osallistumista projektidokumentaation tuottamiseen 

saadakseni vastauksen kolmenteen tutkimuskysymykseeni, ketkä ohjelmistoprojektin 

jäsenet ovat keskeisiä termistön käyttäjinä. Dokumenttien versionhallinnassa ilmoitetaan 

dokumenttien luojat ja muokkaajat, ja tämän avulla pystyn tarkastelemaan kuka tuottaa 

ja lisää sisältöä dokumentteihin. Lisäksi dokumenttien katselmointipöytäkirjoista selviää 

eri vaiheissa mukana olevat työntekijät sekä heidän palautteensa katselmoitavan 

dokumentin sisällöstä. Esimerkiksi tietyn ominaisuuden kehittäjällä voi olla merkittävä 

rooli toteutusvaiheessa mitä termiä tai nimitystä käytetään, vaikka alun 

määrittelyvaiheessa hänellä ei olisikaan vaikutusta käytettyihin termeihin. 

Terminologiatyön merkityksen korostamista ja toimintatapojen ohjeistamista voisi siten 

kohdentaa vastuullisille projektiryhmän jäsenille.  

 

Etsimällä vastaukset näihin kolmeen kysymykseen saan tietoa ohjelmistoprojektin eri 

vaiheista ja niissä käytetyistä termeistä, sekä projektin jäsenistä termistön käyttäjinä. 

Vastaukset auttavat minua suunnitellessani toimenpide-ehdotuksia, joilla saadaan 

terminologiatyö osaksi kohdeyrityksen ohjelmistotuotantoprosessia.  

 

 

1.4 Kohdeyritys 

 

Tutkimukseni kohdeyrityksenä toimii televiestintäalalla toimiva CBOSS Oy. CBOSS 

Oy:llä on yli 20 vuoden kokemus laskutusjärjestelmien ja IN-teknologiapalveluiden 

(Intelligent Network) tarjoajana kansainvälisille matkapuhelinoperaattoreille. (rtBilling 

2004.) Yhtiön virallisena kielenä on englanti, ja myös kaikki sisäinen dokumentaatio on 

englanniksi. 



15 

 

 

CBOSS Oy:n tuote on nimeltään rtBilling (”real-time billing”), ja se koostuu Transaction 

Processor (TP), Management Gateway (MG) ja Voucher Services -osajärjestelmistä. TP 

huolehtii puhe-, teksti- ja multimediaviestien sekä m-Commerce- eli langattoman 

kaupankäynnin transaktioiden reaaliaikaisista prosesseista, laskutus- ja 

lataustoiminnoista. MG hallinnoi asiakastilejä ja liittymiä sekä tarjoaa erilaisia 

rajapintoja, joiden kautta asiakkaat voivat hallinnoida hinnoittelu- ja liittymä-ohjelmiaan. 

Voucher Services -ohjelma tarjoaa matka-puhelinoperaattoreille mahdollisuuden tuottaa 

ja seurata prepaid-latauslipukkeiden elinkaarta myyjiltä liittymien käyttöön. (rtBilling 

2004) 

 

Työskentelen yrityksessä ohjelmistotestaajana (Test Specialist -nimikkeellä). Aiemmin 

toimin samassa yrityksessä teknisenä kirjoittajana melkein kymmenen vuotta, jolloin 

vastuullani oli niin sisäisen kuin ulkoisen dokumentaation tuottaminen ja ylläpito 

yhteistyössä suunnittelijoiden ja kehittäjien kanssa sekä dokumentaationhallinta. 

Ohjelmistotestaajana työhöni kuuluu testisuunnittelu ja -raportointi sekä osallistuminen 

teknisten dokumenttien suunnittelu- ja katselmointikokouksiin.  

 

Olen työssäni käyttänyt paljon aikaa termien ja käsitteiden selvittämiseen eri tahoilta, ja 

osallistunut useisiin epävirallisiin keskusteluihin, joissa selvitetään ”mitä tämä termi 

tarkoittaa?” ja ”miksi X on toisessa käyttöliittymän näkymässä Y?”. Näiden kokemusten 

pohjalta syntyi tutkimusideani ja tavoitteeni luoda toimenpide-ehdotuksia 

järjestelmällisen terminologiatyön ottamiseksi osaksi ohjelmistotuotantoprojekteja 

tulevaisuudessa. 



16 

 

2 OHJELMISTOTUOTANTO JA SIIHEN LIITTYVÄ DOKUMENTAATIO  

 

Tässä luvussa taustoitan tutkimuskohdettani eli ohjelmistotuotantoprojektia. Ensin 

käsittelen yleisellä tasolla ohjelmistotuotantoa ja ohjelmistotuotantoprosesseja sekä 

niihin liittyviä toimintoja (2.1). Yleisen pohdinnan jälkeen esittelen alaluvussa 2.2 

kohdeyrityksen ohjelmistotuotantoprosessin ja dokumentaation, joka syntyy eri 

projektivaiheiden tuloksena ohjelmistoprojektin aikana. Hahmottelen 

ohjelmistotuotantoprosessin rakennetta ja kuvaan myös tutkimusaineistoni lähteisiin 

kuuluvien teknisten dokumenttien rakennetta saadakseni lisätietoa, joiden avulla teen 

luvussa 6 toimenpide-ehdotuksia terminologiatyön ottamiseksi mukaan yrityksen 

ohjelmistotuotantoprojekteihin.  

 

 

2.1 Ohjelmistotuotantoprosessit ja -projektit 

 

Ohjelmistotuotanto käsitteenä on peräisin jo 1960-luvulta, mutta sen määritelmä ei ole 

täysin vakiintunut. Yleisesti sen katsotaan tarkoittavan tietokoneohjelmistojen 

valmistamisessa käytettäviä menettelytapoja, tekniikoita ja työkaluja, ja ohjelmisto 

käsitteenä kattaa sekä tietokoneohjelman että siihen liittyvän dokumentaation. (Haikala 

& Mikkonen 2011: 11).  

 

Ohjelmistojen tuottaminen tapahtuu ohjelmistoprojekteissa. Tekijöiden näkökulmasta 

ohjelmistoprojektit jakaantuvat usein kahteen osaprojektiin: määrittely- ja 

toteutusprojekteihin (kuvio 3). Määrittelyvaiheessa kuvataan mm. ohjelmiston toimin-

nallisuus (functional specification). Toteutusvaiheessa tehdään tarkempi tekninen 

määrittely (technical specification), ohjelmointi eli kehitystyö sekä testaus. (Haikala & 

Mikkonen 2011: 21.) Ohjelmistoprojekteihin on olemassa monia erilaisia 

lähestymistapoja ja -malleja, mutta yleensä niihin aina liittyvät jossain muodossa 

määrittely, suunnittelu, kehitys/ohjelmointi ja testaus eli evaluointi (emt. 29–30). 



17 

 

 

 

Kuvio 3. Ohjelmistotuotantoprojektin jakautuminen 

 

 

Vaatimusten (requirements) keräämis- ja määrittelyvaiheet toimivat pohjana ohjelmiston 

suunnittelulle ja toteutus- eli kehitystyölle. Vaatimusten kerääminen aloitetaan 

yleisemmältä tasolta, ja niistä hiotaan aina tarkempien tavoitteiden kautta 

yksityiskohtaisia vaatimuksia, joiden avulla ohjelmistojen kehitystyön voi suorittaa. 

(Davis 2013: 99)  

 

Ohjelmistoprojekteissa vaatimusten yksiselitteinen kirjaaminen on usein avainasemassa, 

kun ohjelmiston laadun halutaan olevan erittäin hyvä (ks. esimerkiksi Evans 2003). Myös 

ohjelmiston virheiden korjaaminen on sitä kalliimpaa, mitä myöhäisemmässä vaiheessa 

projektin elinkaarta ne löydetään. Vaatimusten määrittelyvaiheessa virheiden korjaus on 

halvinta, mutta suunnitteluvaiheessa korjausten hinta voi olla viisinkertainen, 

testausvaiheessa 50-kertainen ja asiakkaan tuotantoympäristössä olevan ohjelmiston 

virheiden korjaaminen aina 1000-kertaisesti kalliimpaa vaatimusten määrittelyvaiheessa 

korjattuun virheeseen verrattuna. (Stecklein ym. 2004) 

 

 

Määrittelyvaihe

•Ohjelmiston 
toiminnallisuudelle 
asetettujen 
vaatimusten määrittely

Toteutusvaihe

•Kehitys

•Tekninen suunnittelu

•Ohjelmointi

•Evaluointi eli testaus



18 

 

Tapa, jolla kussakin yrityksessä ohjelmistoprojektit toteutetaan, määritellään yrityksen 

ohjelmistotuotantoprosessissa. Oakland (2014: 12) määrittelee prosessin toiminnaksi, 

jossa joukko syötteitä (input) muutetaan asiakkaan odotukset ja tarpeet tyydyttäviksi 

tuloksiksi (output). Prosessissa asiakas voi olla sisäinen tai ulkoinen, esim. 

ohjelmistotuotantoprosessissa asiakas voi olla järjestelmätestausyksikkö ja tulos 

kehitysyksikössä tuotettu dokumentaatio tai ohjelmisto.   

 

Yrityksen prosessit siis kuvaavat yksinkertaistettuna yrityksen tapaa toimia eri 

liiketoimintansa osa-alueilla (Haikala & Mikkonen 2011: 137). Kyseessä on eri vaiheiden 

kuvaus siitä, miten ja missä järjestyksessä eri asiat tulisi suorittaa sekä mikä prosessin 

lopputulos tulisi olla. Ohjelmistotuotantoprosessiin liittyy ohjelmistotyön lisäksi vielä 

muita tuotantoprosessin osa-alueita kuten esimerkiksi laatujärjestelmään, 

tuotteenhallintaan, projektinhallintaan ja dokumentointiin liittyviä tukiprosesseja (kuvio 

4). (Emt.: 11–12)  

 

 

 

Kuvio 4. Ohjelmistotuotantoprosessi ja tukiprosesseja 

 

 

Ohjelmisto-
tuotanto

Laadunhallinta

Projektinhallinta Tuotteenhallinta

Dokumentointi



19 

 

Prosesseihin liittyy olennaisesti systemaattisuus ja prosesseihin liittyvien toimintatapojen 

kirjaaminen on usein tarpeellista, vaikka pienemmissä yrityksissä sitä eri aina koeta 

tarpeelliseksi. Niille olisi hyvä määritellä mitattavat tavoitteet sekä laatia ohjeistus, joissa 

kuvataan prosessiin kuuluva toiminta, toimijat sekä vastuut. Prosesseille määrätään myös 

omistajat, joiden tehtävänä on prosessin toiminnan hallitsemisen sekä kehittäminen. 

(Haikala & Mikkonen 2011: 137–138.)  

 

Prosessien kehittämisellä pyritään erilaisiin tavoitteisiin, esimerkiksi tuotteen laadun 

parantamiseen tai valmistuksen nopeuttamiseen. Yksinkertaisimmillaan prosessin 

kehittäminen koostuu kuviossa 5 esitellyistä vaiheista, joita ovat ongelman tunnistaminen 

(ja tunnustaminen), oikean kehittämiskohteen valinta, yksityiskohtainen ongelmakohtien 

diagnosointi, muutoksen esitteleminen ihmisille, muutoksen toteutus ja muutoksen 

ylläpitäminen (Kenett & Baker 1999: 30).  

 

 

 

 

Kuvio 5. Prosessin kehittämishankkeen vaiheet (Kenett & Baker 1999: 30) 

 

 

Prosessin kehittämiseen tarvittavaa tietoa saadaan erilaisilla mittareilla, joita voivat olla 

esimerkiksi projektin resursoinnin tai aikataulun pitäminen tai virheilmoitusten määrä. 

Mitattuja arvoja voidaan verrata edellisiin projekteihin, ja näin saadaan tietää, onko 

prosessissa tarvetta muutoksille. (Haikala & Mikkonen 2011: 143–144.) Prosessien 

kehittämisessä pienellä muutoksella saattaa olla huomattava merkitys ja pienikin muutos 

saattaa tilapäisesti laskea tuottavuutta. Haikala & Mikkonen (2011: 150) korostavat siksi 

johdon sitoutumisen olevan tärkeää, että kehittämishanke saadaan toteutettua: tällaiset 

hankkeet vaativat aina aikaa ja rahaa.  

 

 

Ongelman 
tunnista-

minen

Kohde-
projektin 

valinta

Diagno-
sointi

Ihmisten 
valmiste-
leminen

Ratkaisun 
toteutta-

minen

Muutok-
sen 

ylläpitä-
minen



20 

 

Raninen (2014) on tutkinut mm. henkilöstön motivaation merkitystä prosessien 

kehittämishankkeiden onnistumisessa. Tutkimuksessa selvisi, että tekijät jotka 

motivoivat työntekijöitä ja toisaalta yrityksen johtohenkilöä olivat hyvin erilaisia. Johtoa 

motivoivat konkreettisemmat tuotantoon liittyvät seikat, kuten tavoitteiden 

saavuttaminen, kustannushyödyllisyys sekä näkyvä menestyminen; työntekijöitä taas 

motivoivat työtyytyväisyys, autonomia sekä menetelmien standardisointi, yleisesti 

tekijät, jotka helpottivat töitä. (Raninen 2014: 34–35) 

 

Tutkimukseni kannalta tämä tarkoittaa sitä, että suunnitellessani ehdotuksia 

kohdeyrityksen terminologiatyölle, tulen huomioimaan nämä prosessin 

kehittämisvaiheet. Toinen huomioitava seikka on sekä niin johdon kuin työntekijöiden 

motivoinnin tärkeyden huomioiminen muutoksessa ja sen ylläpitämisessä, ja miten 

motivoituminen on erilaista, kun kyseessä on johto tai työntekijät. 

 

 

2.2 Kohdeyrityksen ohjelmistotuotantoprosessi ja dokumentit 

 

Kohdeyrityksellä on yksityiskohtaiset prosessikuvaukset eri toiminnoilleen. Kuviossa 6 

on yrityksen tuoteprosessin kuvaus, sekä viittaukset myös tukitoimintojen prosesseille, 

jotka edeltävät (esimerkiksi myyntiprosessi) ja seuraavat (palveluprosessi) tuote-

prosessia. Tuoteprosessi koostuu tuotehallinnasta ja tuotekehityksestä, joka 

kohdeyrityksessä siis on ohjelmistotuotantoa. Tuotekehityksen kehityskohteet syntyvät 

yrityksen tuotestrategisten suunnitelmien sekä asiakkailta tulevien muutos- ja 

kehitysvaatimusten kautta. 

 

 

 

Kuvio 6. Kuvaus kohdeyrityksen tuoteprosessista 

 

 

             
               

                                                

                                 

             
                          

                            



21 

 

Kuvioon 7 olen koonnut tarkemman kuvauksen ohjelmistotuotantoprosessista. Prosessin 

eri vaiheet on kuviossa numeroitu 1. suunnittelu, 2. kehitys, 3. evaluointi ja 4. julkaisu. 

Ne vaiheiden toiminnot ja tehtävät, joista syntyy seuraavassa vaiheessa käytettävää 

teknistä dokumentaatiota, on kirjoitettu kursiivilla. Edellisen vaiheet tehtävät ja toiminnot 

on suoritettava ja hyväksyttävä ennen kuin seuraavaan vaiheeseen voidaan siirtyä. Näin 

esimerkiksi kehitysvaihe ei voi alkaa, ennenkö suunnitteluvaiheessa on katselmoitu ja 

hyväksytty projektisuunnitelma, järjestelmäsuunnittelu ja vaatimusmäärittelyt.  

 

 

 

Kuvio 7. Kuvaus kohdeyrityksen ohjelmistotuotantoprosessista 

 

 

Kaikki yrityksen ohjelmistotuotantoprojektissa syntyvä dokumentaatio on kuvattu 

tarkasti yrityksen tarkassa sisäisessä prosessikuvauksessa. Projektikohtaista 

dokumentaatiota ja tietoa tuotetaan, säilytetään ja muokataan kohdeyrityksessä eri tavoin. 

                                 

        

                     

                                 
             

     

                     

                       

          

                         

                  

                           

                 

                 

              

       

                     

                

                  

                         

          

       

                

       

              

           

        

                    

                               

                            

                   

           

                  

                      

                 

                   



22 

 

Esimerkiksi suunniteltaviin ominaisuuksiin liittyvät uudet vaatimukset (requirements) 

ovat omassa tietokannassaan, jota käytetään kaupallisen vaatimustenhallintasovelluksen 

DOORSin kautta, josta esimerkki alla (kuva 1).  

 

 

 

 

Kuva 1. DOORS-vaatimustenhallintaohjelmiston ulkoasu (IBM 2017)  

 

 

Kun yksilöidyt vaatimukset on kirjattu vaatimustenhallintakantaan, niitä voidaan 

tarkastella joko ohjelman käyttöliittymän kautta tai ne voidaan ohjelman kautta tulostaa 

tekstitiedostoiksi ja esimerkiksi lähettää lausuntokierrokselle sähköpostitse. Ohjelmiston 

rakenne antaa mahdollisuuden lisätä vaatimusten lisäksi erilaista metatietoa tai muuta 

selittävää tekstiä. 

 

Suunnittelu- ja kehitysvaiheen dokumentaatio on tekstitiedostomuodossa. Dokumentteja 

säilytetään sekä verkkolevyillä että versionhallintajärjestelmän kautta erillisessä 

tietokannassa. Yrityksen käytössä on Open Office Writer -ohjelma, jolle on luotu 

mallipohjat eri prosessivaiheiden dokumenteille. Mallipohjat määrittelevät dokumentin 

rakenteen ja siinä käytetyt tyylit. Jos kehitettävä ominaisuus ei ole uusi, vaan vaatimukset 

kohdistuvat jo olemassa olevaan ominaisuuteen, käytetään edellisen version 

dokumentteja ja versioidaan käsiteltävä dokumentti suuremmalla versionumerolla.  

 

 



23 

 

Yhteistä rakenteessa kaikille näille dokumenteille on esimerkiksi alun dokumentin 

esittely, jossa kerrotaan dokumentin tarkoitus ja kohdeyleisö, taulukko, johon 

dokumentin muokkaajat kirjoittajat nimensä ja muokkauspäivämäärän sekä mitä osaa 

ovat siitä muokanneet, käytetyt lyhenteet -taulukko sekä sisällysluettelo (kuvio 8). 

Dokumentin tarkka rakenne vaihtelee sen mukaan, onko kyseessä järjestelmän kokonais-

tason suunnittelua kuvaava dokumentti vai yksityiskohtaisemman tason suunnittelu-

dokumentti. 

 

 

 

Kuvio 8. Kohdeyrityksen teknisten dokumenttien rakenne 

 

 

Mallipohjien tyylimäärittelyt koskevat esim. koodissa käytettävää kirjasinta, joka erottaa 

sen leipätekstistä, sekä erilaisia tyylikeinoja, joilla erotetaan erityisesti huomioitavat 

seikat pienemmän prioriteetin asioista. Mallipohjia ja määriteltyjä tyylejä käytetään myös 

asiakasdokumentaatiossa, eli erilaisissa referenssi-, asennus- ja ohjelmointioppaissa, 

jotka toimitetaan asiakkaalle PDF-muodossa osana järjestelmätoimitusta.  

Asiakasdokumenttien esittelyluvussa on taulukkomuodossa esitelty käytetyt 

merkintätavat (taulukko 1). 

 

 

 

 

 

                    

        

                      

               

                     

                    

                           

   

   

   

                

                        

                    

         

              

       

                           

                        

                      

                 

     

   

     

            

                           



24 

 

Taulukko 1. Aineiston asiakasdokumentaatiossa esiintyviä merkintätapoja 

 

Tyyli Kuvaus Esimerkki 

Lihavointi Lihavointia käytetään viitattaessa 

näyttöteksteihin, kenttien ja 

näppäinten nimiin, valikkoihin ja 

valikkojen kohteisiin jne. 

In the File menu, select Open.  

Kursiivi Kursiivia käytetään viitatessa muihin 

dokumentteihin tai toisiin lukuihin 

samassa dokumentissa. 

For more information, see 

Installation Guide. 

Alleviivaus Alleviivauksella korostetaan URL-

osoitteet ja sähköpostit. 

The Java package can be 

downloaded from http://java.com/ 
Courier Käytetään komentojen, tiedostojen ja 

hakemistojen nimissä sekä 

kuvaamaan komentojen 

näyttötulosteita esimerkeissä. 

$volume.subvolume 

 

Courier 

bold 
Käytetään kuvaamassa komentoja, 

jotka käyttäjä syöttää järjestelmään. 

Start the installation with the 

start command: 
> ./start 

Courier 

italic 
Käytetään komentoriviesimerkissä 

paikkamerkkiarvona, joka korvataan 

oikealla arvolla. 

Login as user and enter the 

password when prompted: 
Login: user 

Password: password 

 

 

Lisäksi järjestelmässä on graafisessa käyttöliittymässä online-ohje sekä tekstipohjaisessa 

käyttöliittymässä kenttäkohtaiset ohjenäytöt, jotka tulevat esiin painamalla F2-näppäintä 

kursorin ollessa halutun kentän kohdalla. Nämä ovat sekä sisäiseen että asiakkaan 

käyttöön tarkoitettuja.  

 

Kohdeyrityksen tekniseen dokumentaatioon ja tuotteen käyttöliittymään olisi mahdollista 

lisätä tietoa projektissa ja tuotteessa käytetystä termistöstä. Teknisessä dokumentaatiossa 

tämä palvelisi parhaiten yrityksen työntekijöitä mutta myös asiakkaita. Sanastot voisivat 

helpottaa myös ohjetekstien tuottamista käyttöliittymien ohjenäyttöihin. Otan nämä 

havainnot huomioon terminologiatyön toimenpide-ehdotuksia suunnitellessani.  



25 

 

3 TERMISTÖN TARKASTELUN LÄHTÖKOHTIA 

 

Käsittelen tässä luvussa olennaisia käsitteitä, jotka liittyvät terminologiseen tutkimukseen 

sekä omassa tutkimuksessani käyttämiini menetelmiin. Esimerkiksi termien 

tunnistaminen lähteistä edellyttää tietoa mikä ja minkälainen termi on. Voidakseni 

arvioida kohdeyrityksessä käytettävien termien asianmukaisuutta käsittelen myös hyvälle 

termille asetettuja erilaisia kriteereitä. 

 

Terminologian erikoisalan omat käsitteet eivät aina alan kirjallisuudessa ole täysin 

yksiselitteisiä. Esimerkiksi englannissa (mm. Sager 1990: 3) sana terminology viittaa 

kolmeen eri asiaan: 

 

1. Käytäntöihin ja menetelmiin, joiden avulla kerätään, kuvataan ja esitetään termejä 

2. Teoriaan, joka tutkii käsitteiden ja termien välisten suhteiden selvittämistä 

3. Tietyn alan erikoissanastoon  

 

Suomen kielessä edelliset on helpompi erottaa, esimerkiksi tietyn erikoisalan käyttämiin 

nimityksiin viitataan termillä termistö (Terminologinen sanasto 2006: 30). Tässä 

tutkimuksessa käytän lisäksi terminologinen tutkimus -ilmausta viitatessani 

terminologiaan teoriana, terminologiatyötä, kun viittaan terminologisiin työmenetelmiin. 

Lisäksi sanastolla viittaan erikoisalalta kerättyyn ja määriteltyyn konkreettiseen 

käsitteiden ja niiden nimitysten eli termien luetteloon.  

 

 

3.1 Termit ja käsitteet terminologiatyön peruselementteinä 

 

Terminologinen tutkimus ja terminologinen työ keskittyvät erikoiskieliin, joita käytetään 

tietyillä erikoisaloilla, eli yleensä jollain tiede-, ammatti- tai harrastusaloilla, joilla on 

yleiskielestä eriytynyttä termistöä. Erikoiskielillä jäsennetään, kuvataan ja muokataan 

alan käsitemaailmaa. Toimiakseen hyvin erikoiskielten olisi hyvä täyttää tiettyjä 

vaatimuksia: hyvän erikoiskielen ominaisuuksia ovat esimerkiksi yksiselitteisyys, 

tarkkuus, loogisuus ja selkeys. (Haarala 1981: 9−11)  



26 

 

Terminologisen työn keskeisimpiä käsitteitä on käsite. Terminologinen käsitemalli 

esitetään usein kolmiona (kuvio 9), jonka kärkinä ovat käsite, tarkoite ja termi. 

Sanastotyön käsikirja (1988: 25) määrittelee erikoiskielen käsitteen tarkoitteesta 

muodostetuksi mielikuvaksi ja termin tämän kielelliseksi tunnukseksi. Terminologian 

sanasto (Sanastokeskus TSK 2006) määrittelee nämä käsitteet tarkemmin. Käsite 

määritellään tiedon yksiköksi, joka koostuu käsitepiirteiden yksilöllisestä yhdistelmästä, 

tarkoitteen ollessa ”olio, joka voidaan osoittaa, käsittää tai kuvitella ja joka vastaa tiettyä 

käsitettä”. Termi taas on erikoisalalla käytössä oleva yleiskäsitteen nimitys. 

(Sanastokeskus TSK 2006: 10, 22) 

 

 

 käsite 

 

 

 

  

 tarkoite    termi 

 

Kuvio 9. Käsitemallikolmio (Sanastotyön käsikirja 1988: 24) 

 

 

Käsitteet muodostavat käsitejärjestelmiä, joissa käsitteet liittyvät toisiin erilaisten 

käsitesuhteiden avulla. Käsitteiden esittäminen erilaisten käsitejärjestelmäkaavioiden 

avulla selkeyttää käsitteiden määritelmien tekemistä. Käsitejärjestelmäkaavioiden avulla 

käsitteiden väliset suhteet konkretisoituvat ja niiden määritteleminen helpottuu. 

(Suonuuti H. 1999: 29−30) Käsitejärjestelmien kuvaamiseksi on siis olemassa erilaisia 

graafisia esitystapoja, joissa käsitesuhteet esitetään erilaisilla merkintätavoilla. Tässä 

tutkimuksessa käytän käsiteanalyysin apuna ja käsitejärjestelmien visualisoimisessa 

menetelmäluvussa (1.3) esiteltyä satelliittimallia. 

 

Läheisten käsitteiden erottamiseksi toisistaan tulevat apuun käsitepiirteet. Käsitepiirteet 

voivat perustua tarkoitteen sisäisiin tai ulkoisiin ominaisuuksiin, esimerkiksi olemukseen 

(väri, koko, materiaali) tai sijaintiin, tarkoitukseen tai valmistustapaan liittyviin 



27 

 

ominaisuuksiin. Niiden selvittäminen auttaa käsitteiden luonnehtimisessa ja niiden avulla 

rajataan ja erotetaan läheisiä käsitteitä toisistaan. Käsitepiirteiden avulla luodaan myös 

käsitteiden määritelmät. (Sanastotyön käsikirja 1988: 26–27.) Terminologian sanastossa 

(Sanastokeskus TSK 2006: 19) määritelmä on ”käsitteen kuvaus, jonka tulee erottaa 

käsite sen lähikäsitteistä”. Tarkemmin määritelmä on siis ”käsitteen kielellinen kuvaus”, 

jolla on kolme tehtävää: käsitteen yksilöiminen sen erottamiseksi muista käsitteistä, 

käsitteen suhteiden määrittäminen muihin käsitteisiin nähden sekä normien luominen 

käsitteen käyttämistä varten (Sanastotyön käsikirja 1988: 41).  

 

 

3.2 Terminmuodostusmenetelmiä 

 

Uusien käsitteiden syntyminen synnyttää myös uutta termistöä. Sager (1990: 71) jakaa 

uusien termien muodostamisen kolmeen lähestymistapaan: olemassa olevien resurssien 

(eli tässä tapauksessa kielen aineksen) käyttämiseen, olemassa olevien resurssien 

muokkaamiseen ja uusien kielellisten yksiköiden luomiseen. Sanastotyön käsikirja (1988: 

83) listaa seuraavat tavat muodostaa termejä: termittäminen, yhdistäminen, johtaminen, 

lainaaminen, lyhentäminen, konversio ja tekosanat. Vaikka Sanastotyön käsikirja 

käsittelee näitä edellä mainittuja terminmuodostustapoja suomen kielen kannalta, niin ne 

ovat kuitenkin käytössä myös kaikissa eurooppalaisissa kielissä (emt.).  

 

Termittämisellä tarkoitetaan termin muodostamista erikoiskieleen yleiskielen sanasta 

(Sanastotyön käsikirja 1988: 84). Tällöin sanan perusmerkityksen tulisi säilyä, eikä sanaa 

saisi erikoiskielessä esiintyä yleiskielisessä merkityksessä sekaannusten välttämiseksi 

(emt.). Sager (1990: 71) puhuu termin merkityksen laajentamisesta vertauksen tai 

metaforan kautta. Esimerkki tällaisesta voisi aineistostani olla esimerkiksi library 

(kirjasto), joka on yleiskielen merkityksensä lisäksi termi myös tietotekniikan alalla 

(ohjelmakirjasto).  

 

Yhdistäminen terminmuodostuskeinona sisältää sekä yhdyssana- että sanaliittotermien 

muodostamisen Niin yhdyssanatermit kuin sanaliitotkin muodostuvat määriteosasta tai 



28 

 

osista ja perusosasta (Sanastotyön käsikirja 1988: 87, 92). Esimerkkinä yhdys-

sanatermistä on database (data + base), sanaliittotermistä database table.  

 

Johtamalla muodostetuissa sanoissa perussanaan liitetään alkuliite tai pääte, jolla sanoista 

muodostetaan uusia sanoja (emt. 93). Näin esimerkiksi verbistä subscribe (tilata) voidaan 

muodostaa tekijä subscriber (tilaaja) ja teon kohde tai tulos subscription (tilaus). Sager 

(1990: 75–76) toteaa, että englannissa prefiksien ja suffiksien määrä on suuri, koska 

englannin kielessä on muun muassa suuri määrä alkuperältään latinan ja kreikan kielestä 

lähtöisin olevia lainasanoja. Termejä muodostetaan siis myös lainaamalla vieraista 

kielistä, jolloin uuden käsitteen mukana tulee myös uusi termi (Sanastotyön käsikirja 

1988: 94).  

 

Termien muodostaminen lyhentämällä tarkoittaa sitä, että sanaliiton tai yhdyssanan 

alkukirjaimista, tavuista tai sanan osista muodostetaan termi (Sanastotyön käsikirja 1988: 

92), kuten esimerkiksi SMS (Short Message Service). Sager (1990: 79) luettelee tähän 

vielä tavan muodostaa termejä, joka on englannin kielessä yleisempi kuin suomessa, eli 

termin osien lyhentämisen ja yhdistämisen, kuten ”biological + electronic = bionic”.  

 

Konversio tarkoittaa sitä, että termi muodostetaan sanan sanaluokkaa muuttamalla. Tämä 

terminmuodostuskeino on englannissa yleinen. (Sanastotyön käsikirja 1988: 98). 

Esimerkkinä verbin muuttamisesta substantiiviksi on aineistostani termi recharge (verbi 

ladata, substantiivi lataus). Sager (1990: 79) huomauttaa kuitenkin, että käytännössä on 

vaikea tietää, onko substantiivi muutettu verbiksi vai päinvastoin. Uusien termien 

muodostaminen tekosanoina on harvinaista. Tekosanat tarkoittavat uutta sanaa, joka ei 

perustu mihinkään aikaisempaan malliin. (Sanastotyön käsikirja 1988: 98).  

 

 

3.3 Hyvän termin ominaisuuksia 

 

Isohella & Nuopponen (2016) ovat tutkineet useita erilaisia ihanteellisen termin määri-

telmiä terminologisen tutkimuksen alalta. Heidän ovat tarkastelleet näitä määritelmiä ja 

muun muassa soveltaneet niitä käyttöliittymätermien käytettävyyden arviointiin. He 



29 

 

jakoivat kirjallisuudesta poimimansa ihannetermien lukuisat kriteerit laajempien periaat-

teiden alle: 1. termin rakenne ja muoto, 2. termin suhde käsitteeseen, 3. termin 

tarkoituksenmukaisuus sekä 4. termin käyttö (kuvio 10). (Emt. 229–232)  

 

 

 

Kuvio 10. Termien tarkasteluperiaatteita (Isohella & Nuopponen 2016: 229–232)  

 

 

Termien rakenteeseen ja muotoon liittyvän periaatteen kriteereihin Isohella & 

Nuopponen (2016: 229–230) ovat keränneet mm. erottuvuuden, moitteettomuuden, 

produktiivisuuden ja taloudellisuuden. Näillä tarkoitetaan, miten hyvin termi erottuu 

muista termeistä, onko termi kieliopillisesti ja ulkoasultaan yleisiä termin-

muodostuskeinoja vastaava, miten hyvin siitä voi muodostaa uusia johdoksia sekä termin 

pituuden ja läpinäkyvyyden suhdetta (emt.). Termin pituus on usein merkittävä seikka, 

kun tarkastellaan käytettäviä termejä: lyhemmät termit vakiintuvat käyttöön helpommin, 

ja liian pitkistä termeistä muodostetaan usein epävirallisempia lyhenteitä (Sanastotyön 

käsikirja 1988: 77). 

 

Isohella & Nuopponen (2016: 230) tarkastelevat termien suhdetta käsitteisiin lähinnä 

läpinäkyvyyden ja yksiselitteisyyden kriteerien kautta. Läpinäkyvyydellä tarkoitetaan 

            

           

             
                 

               

                                       

      

           

       

             

           

             

                         
                

                            

                       

              

               

              

          



30 

 

sitä, miten selvästi termin eri elementit kertovat käsitteen piirteistä. Selkein esimerkki 

tällaisesta tutkimallani alalla voisi olla vaikkapa yhdyssanoja tai sanaliittoja käyttämällä, 

kun yläkäsitteen termi muodostaa alakäsitteen termin perusosan: telephone  

radiotelephone; subscription  default subscription, alternative subcription. Niin 

sanaliitto- kuin yhdyssanatermejä luotaessa on kuitenkin pidettävä huoli, että aiemmin 

mainittu termin erottuvuus säilyy, eli että termit eivät ole keskenään liian samannäköisiä. 

(Sanastotyön käsikirja 1988: 74–76.) Yksiselitteisyys taas tarkoittaa sitä, viittaako termi 

mahdollisesti useampaan kuin yhteen käsitteeseen tai vastaavasti viitataanko käsitteeseen 

useammalla termillä (Isohella & Nuopponen 2016: 230–231). 

 

Termin tarkoituksenmukaisuus tarkoittaa sen soveltuvuutta esimerkiksi erikoisalalle, 

missä sitä käytetään, tai kohderyhmälleen, ja että se ei ole vanhentunut tai sisällä 

negatiivisia konnotaatioita. Termien käytön periaatteella Isohella & Nuopponen (2016: 

232) viittaavat erilaisiin termien käytön suosituksiin, joista tärkeimmäksi nousee 

johdonmukaisuus. Samaan käsitteeseen viittaavia eri termejä ei siis esimerkiksi tulisi 

käyttää markkinointimateriaaleissa ja käyttöohjeissa (emt 231–232). 

 

Paitsi, että aion tarkastella näiden yllä esiteltyjen periaatteiden mukaan aineistoni termejä 

selvittääkseni, onko tarvetta termien parantamiselle, tulen hyödyntämään näitä kriteereitä 

jatkossakin ja pohtimaan sitä, miten nämä tulisi huomioida ohjelmistoprojektin 

terminologiatyössä.  

 

 

3.4 Terminpoiminta  

 

Terminpoiminnasta tai termi-inventaariosta puhutaan yleensä terminologisen työn yhtey-

dessä, kun kerätään lähteistä käsitteitä ja termiehdokkaita alustavaa listaa varten. Kään-

täjä tai terminologi pyrkii poimimaan termit lähdeaineistoista, tai kääntäjä voi pyytää 

erikoisalan asiantuntijaa poimimaan termit (Pasanen 2009: 43−44). Nykänen (1999: 65) 

käyttää termiä termi-inventaario terminologisesta työvaiheesta, jossa kerätään sanaston 

laatimiseksi lähtöaineistosta termiehdokkaita ja mahdollisesti jo alustavia määritel-

miäkin.  



31 

 

Kaikkien termiehdokkaiden määrä voi terminpoiminnassa nousta suureksikin, vaikka 

lopullisen sanaston koko olisikin maltillinen. Pieniin aineistoihin ja aihealueisiin, jotka 

ovat vain muutaman käsitejärjestelmän kokonaisuuksia, sopii myös lähestymistapa, jossa 

kerätään kohdealalta muutama ydinkäsite, joiden ympärille lisätään käsitteitä ja termejä 

(Nykänen 1999: 65).  

 

Terminpoiminta voi olla manuaalista tai puoliautomaattista, jolloin terminpoiminnassa 

käytetään apuna erilaisia tietokoneohjelmia. Tässä tutkimuksessa poimin termit lähde-

aineistosta manuaalisesti. Suurimpana syynä tähän on se, että lähdeaineistoa on eri 

tiedostomuodoissa. Sopivan terminpoimintatyökalun etsiminen ja sen käytön opettele-

minen olisi vienyt enemmän aikaa kuin manuaalinen terminpoiminta paperitulosteista 

kynän kanssa, kun lähdeaineisto ei ole useita satoja sivuja.  

 

Pasanen (2009: 45) on käsitellyt manuaalisen terminpoiminnan etuja ja haittoja. Etuihin 

hän lukee terminpoiminnassa tarvittavien välineiden yksinkertaisuuden; se ei vaadi eril-

lisiä tietokoneohjelmia, vain kynä ja paperi periaatteessa riittävät. Tekstit eivät vaadi 

esivalmisteluja, eikä niiden tarvitse olla sähköisessä muodossa. Lisäksi menetelmä on 

varsin luotettava ja koottavaan termilistaan tulee varmemmin heti varsinaisia termejä. 

Huonoihin puoliin hän lukee manuaalisen terminpoiminnan hitauden ja sitovuuden 

(suuret lähdeaineistot on käytävä kokonaan läpi, vaikka tekstit toistaisivat itseään eikä 

terminologi saisi enää erikoisalalta uutta taustatietoa) sekä subjektiivisuuden: poimitut 

termit riippuvat aina työn tekijän käsityksestä mikä on alaan kuuluva termi. (Emt. 45) 

 

Kuten edellisessä luvussa (3.2) kävin läpi, termit voivat olla esimerkiksi perussanoja, 

sanojen johdoksia, yhdyssanoja tai kahden tai useamman sanan muodostamia sanaliittoja. 

Termit voivat olla myös lyhenteitä tai lyhenteen ja perussanan yhdistelmä. (Nuopponen 

& Pilke 2016: 62−63) Poimiessani termiehdokkaita voi esimerkiksi sanaliittotermien 

hahmottaminen tuottaa vaikeuksia, jos yleiskielisten sanojen erottaminen termeistä on 

hankalaa tai jos termit ovat käytössä myös yleiskielen sanoina (esimerkiksi termi common 

library). Aion selvittää tällaiset ongelmalliset termiehdokkaat tarkastelemalla näitä 

termejä tarvittaessa kontekstissaan. Koska tutkimukseni kohdealue on minulle tuttu, 

toimin sekä terminologina että erityisalan asiantuntijana termejä poimiessani.  



32 

 

4 YRITYSTEN TERMINOLOGIATYÖ 

 

Tässä luvussa tarkastelen lähemmin yritysten tekemää terminologiatyötä, sen haasteita ja 

merkitystä yrityksille. Terminologiatyö, johon suomeksi usein viitataan myös termillä 

sanastotyö ja terminologinen työ, tarkoittaa tiettyyn erikoisalaan, kuten omassa tutkimuk-

sessani televiestintäalaan, kuuluvien käsitteiden ja niiden nimitysten järjestelmällistä 

"keräämistä, analysointia, kuvaamista ja esittämistä" (Terminologian sanasto 2006: 31). 

Näitä erilaisia terminologiatyön vaiheita käsittelen myös tässä luvussa. Käytän näistä 

keräämääni tietoa suunnitellessani kohdeyritykselle terminologisia toimenpide-

ehdotuksia terminologiatyön aloittamiseksi. 

 

Terminologiatyö voi olla joko deskriptiivistä, jolloin tarkoituksena on kohdealan 

käsitteistön ja termistön kuvaileminen, tai normatiivista. Normatiivisen terminologiatyön 

tarkoitus on erikoisalan käsitteistön yhdenmukaistaminen ja selkeyttäminen. (TSK 2018) 

Normatiivista terminologiatyötä tekevät esimerkiksi erilaiset standardisointiorganisaatiot 

kuten ISO tai televiestintäalan ITU-T, ja aluksi esittelen näitä televiestintäalan standardi-

sointiorganisaatioita ja niiden historiaa. 

 

 

4.1 Televiestintäalan termistö ja standardisointi 

 

Tutkimusaineistoni termit tulevat pääasiassa televiestintäalalta, jolla on pitkät perinteet ja 

kehittyneet prosessit terminologiatyössään. Alan standardisointiorganisaatiot pyrkivät 

auttamaan kaikkia alalla toimivia viestinnässä ja tiedonvälityksessä. Televiestinnän juuret 

ulottuvat paljon moderneja mobiili- ja data-aikoja kauemmas menneisyyteen, ja siihen 

liittyvää standardisointityötä on termienkin osalta tehty alalla pitkään. The 

Telecommunications Industry Association (TIA) perustettiin 1920-luvulla (TIA 2016), ja 

International Telecommunication Unionin (ITU) historia alkaa 1860-luvulla, jolloin 

perustettiin ITU, silloin International Telegraph Union. ITU:n standardisointihaara sai 

käytännössä alkunsa 1925, vaikka virallisesti ITU-T aloitti työnsä 1992, kun ITU jaettiin 

kolmeen sektoriin: Telecommunication Standardization (ITU-T), Radiocommunication 

(ITU-R) ja Telecommunication Development (ITU-D). (ITU 2018:1–3, 6) 



33 

 

Yksi ITU-T:n komiteoista on the Standardization Committee for Vocabulary. Sen tarkoi-

tuksena on konsultoida terminologiatyötä ja auttaa termien ja käsitteiden 

harmonisointityössä ITU-T:n eri työryhmiä. Lisäksi komitea toimii yhteistyössä mm. 

International Organization for Standardization (ISO), the International Electrotechnical 

Commission (IEC) sekä ISO/IEC JTC Joint Technical Committee for Information 

Technology -järjestöjen kanssa. Sanastotyötä tehdään ITU-T:ssä kuudella kielellä: 

englanniksi, arabiaksi, espanjaksi, ranskaksi, saksaksi ja venäjäksi. Lisäksi ITU-T:llä on 

julkinen termipankki (https://www.itu.int/ITU-R/go/terminology-database), jossa on 

tutkimushetkellä 147991 termi- ja lyhennetietuetta, joista osa on normatiivisia ja osa 

ohjeellisia. (ITU-T 2018) 

 

Televiestinnän siirryttyä yhä enemmän puhelinverkoista Internetiin ja tietoverkkoihin, 

myös tietotekniikan sanasto on tullut osaksi televiestinnän erikoissanastoa. Niin 

englanniksi kuin suomeksi on tietojenkäsittelyyn liittyvää terminologiatyötä tehty paljon 

ja käyttöliittymien standardisointiin on termienkin osalta panostettu. Kansainvälisellä 

tasolla esimerkiksi Internet Engineering Task Force (IETF 2015) vastaa Internet-

protokollien standardisoinnista ja samalla suosittelee käytettävää termistöä. Suomessa 

standardisointiorganisaatioiden lisäksi esimerkiksi TSK:n Tietotekniikan termitalkoot 

(2015) on vuodesta 1999 antanut suosituksia erilaisiin tietojenkäsittelyyn liittyviin 

termeihin.  

 

 

4.2 Terminologiatyö ja termistönhallinta  

 

Terminologiatyöhön liittyy vahvasti myös termistönhallinta, eli termistön tallentaminen 

ja esittäminen, erityisesti termipankkien ja vastaavien työkalujen yhteydessä (Steurs, De 

Wachter & De Maiche 2014: 224). Alan englanninkielisessä kirjallisuudessa taas 

tunnutaan usein viitattavan termillä terminology management nimenomaan 

terminologiatyöhön.  

 

Esimerkiksi Wrightin ja Budinin määrittelevät termistönhallinnan (terminology 

management) kattamaan yleisesti "kaiken terminologisen tiedon tarkoituksellisen 



34 

 

käsittelemisen". Tähän he lukevat mukaan sen terminologiatyön, jota eri alojen 

asiantuntijat ovat tehneet jo pitkään, erilaisten termistöjen ja sanastojen keräämisen ja 

esittämisen, sekä kaiken sen erilaisen termitiedon etsimisen, jota erikoisaloilla 

työskentelevät kääntäjät ja tekniset dokumentoijat usein tekevät (emt. 2001: 1–2).  

 

Samoin Sauberer, Villar, Dreβler, Schmitz & Clarke (2017: 654) luettelevat 

termistönhallinnan tehtäviksi uusien termien luomisen, olemassa olevien termien 

keräämisen ja dokumentoinnin, määritelmien muotoilun uusille käsitteille sekä 

tietokannan kokoamisen termistölle olennaisine tietoineen (konteksti, käyttö, tyyli sekä 

tietueen luontipäivät ja muuta metatietoa). Heidän määritelmässään mainittua uusien 

termien luomista ei kuitenkaan yleensä yhdistetä termistönhallintaan vaan nimenomaan 

terminologiatyöhön kuuluvaksi.  

 

TerminOrgs on terminologien muodostama konsortio (Terminology for Large 

Organizations), jonka tarkoitus on lisätä tietoisuutta termistönhallinnasta ja sen eduista 

osana suurten yritysten identiteettiä, sisällöntuotantoa sekä kansanvälistä viestintää 

(TerminOrgs 2012). Heidän julkaisemassaan Terminology Starter Guidessa 

termistönhallinta on määritelty tarkoittamaan yrityksissä toimia, joilla varmistetaan 

oikeiden, määrättyjen termien johdonmukainen käyttö yrityksen kaikessa viestinnässä. 

(emt. 13–14). Tätäkin määritelmää vastaa suomessa paremmin terminologiatyö. 

 

Steurs, De Wachter & De Maiche (2014: 224) käsittävät, että termistönhallinta 

(terminology management) on osa terminologiatyötä (terminology work), ja he liittävät 

termistönhallinnan myös yhdeksi osa-alueeksi yritysten tiedonhallinnassa. Myös 

Lombard (2016: 156) vertaa termistönhallintaa yritysten muuhun tiedonhallintaan, ja 

toteaa, että samalla tavoin, kuin muu tieto, termistö on hyödyllisintä, kun se on 

organisoitua ja dokumentoitua. Tämä vastaa enemmän omaa käsitystäni, jonka mukaan 

termistönhallinta on se osa terminologiatyötä, joka keskittyy termistön tallentamiseen ja 

esittämiseen.  

 

Kuten edellä olevista eri tahojen termistönhallinnan (terminology management) 

määritelmistä huomaa, sillä viitataan usein nimenomaan terminologiatyöhön. 



35 

 

Suomessakin terminologiatyöstä käytetään mm. termejä sanastotyö tai termityö. 

Tutkimukseni kannalta korostan terminologiatyön määritelmästä (eli erikoisalaan 

kuuluvien käsitteiden ja niiden nimitysten järjestelmällistä "keräämistä, analysointia, 

kuvaamista ja esittämistä" (Terminologian sanasto 2006: 31)) sanaa järjestelmällistä, 

koska se sisältää itseensä myös terminologiatyön suunnittelun. Termistönhallintaan 

viittaan sinä terminologiatyön osa-alueena, joka keskittyy termistön ja sanastojen 

järjestelmälliseen tallentamiseen, esittämiseen ja ylläpitämiseen, toimien tavallaan 

terminologiatyöprosessin viimeisenä vaiheena.  

 

 

4.3 Terminologiatyön ja termistönhallinnan merkitys yrityksissä 

 

Kremer ym. (2005: 282) toteavat, että yrityksissä on runsaasti tarjolla erilaista tietoa 

erilaisissa intranet-sivustoissa ja tietämyskannoissa, mutta tietyn tiedon löytäminen 

saattaa olla usein vaikeaa. He näkevät, että suurimmat epäkohdat ovat huonot 

hakutulokset tietokannoista ja intraneteistä, epäselvät nimeämiset hierarkiassa sekä 

harhaanjohtavien termien käyttö. Näiden epäkohtien korjaamiseen olisi apua yritysten 

terminologiatyöstä ja sen seurauksena valmistuneista sanastoista ja käsitteiden 

luokitteluista. Niitä voitaisiin käyttää, kun suunnitellaan tiedon varastointia, esittämistä 

ja välittämistä niin ihmisten kuin erilaisten tietojärjestelmien tai ohjelmien välillä. (Emt. 

282)  

 

TerminOrgin julkaisemassa oppaassa korostetaan, että tehokas termistönhallinta tuottaa 

yritykselle myös suoraa rahallista etua pienentämällä kääntämisestä aiheutuvia 

kustannuksia, ja terminologiatyötä perusteltaessa viitataankin usein ensimmäisenä 

kääntämiseen. Yksikielisenkin terminologiatyön ja termistönhallinnan etuja yritykselle 

ovat mm. säästöt kuluissa, joita aiheutuu oikeiden termien etsimisestä ja huonojen tai 

virheellisten termien käytöstä dokumentaatiossa, tuotteen ja sen dokumentaation laadun 

parantaminen sekä yrityksen työntekijöiden osaamisen dokumentointi esimerkiksi uusien 

työntekijöiden perehdytystilanteita varten (TerminOrgs 2012: 17).  

 

 



36 

 

Sauberer (2011) esittelee artikkelissaan syitä termistön ja terminologisten menetelmien 

käyttämiselle, ja ensimmäisenä hän mainitsee teknisen dokumentaation ja muun 

yritysviestinnän parantamisen. Teknisen sanaston määritteleminen mahdollisimman 

aikaisessa vaiheessa luo hyvän pohjan viestinnän onnistumiselle eri tahojen kesken niin 

yrityksen sisällä kuin ulkoisten sidosryhmien kanssa (emt. 57). Johdonmukainen ja selkeä 

termistö mahdollistaa tiedon uudelleenkäytön ja saavutettavuuden sekä vahvistaa 

mielikuvaa yrityksen ja tuotteen laadukkuudesta (Brändle & Bauer 2013: 7) Myös 

Lombard (2006: 156) korostaa, että terminologiatyö suunnitelmallisesti suoritettuina 

toimintoina varmistaa yrityksen termistön saatavuuden, että tiedetään mitä termistöä 

yrityksellä on. Dokumentoimaton termistö taas edustaa termejä ja määritelmiä, joista 

harvalla yrityksessä on selkeä kuva (emt.).  

 

Olen koonnut kuvioon 11 tehokkaan termistönhallinnan yrityksille tuomat hyödyt edellä 

käsittelemieni lähteiden pohjalta. Rahallisten etujen lisäksi tehokas termistönhallinta 

vaikuttaa suuresti yrityksen viestintään eri sidosryhmien välillä sekä mielikuvaan niin 

yrityksestä kuin tuotteesta. Johdonmukaisesti käytetty termistö esimerkiksi 

dokumentaatiossa, tuotteessa ja koulutustilaisuudessa antaa hyvän kuvan yrityksestä. 

Kaikenlaisen tiedon määrän kasvaessa yrityksissä termistönhallinta helpottaa myös 

tiedon saavutettavuutta esimerkiksi suunniteltaessa intranetin tai tietämyskantojen 

rakennetta.  

 

 

 

 

 

 

 

 

 

 

 

 



37 

 

 

 

Kuvio 11. Tehokkaan termistönhallinnan tuomat hyödyt yritykselle 

 

 

SDL Internationalin teettämässä kyselyssä monet yritykset kokevat, että hyvällä 

termistönhallinnalla on merkittävä vaikutus niin yrityksen ulkoiseen kuin sisäiseen 

mielikuvaan ja viestintään. Silti suuri osa kyselyyn vastanneista oli havainnut 

epäjohdonmukaisuuksia ja virheitä yrityksensä käyttämässä termistössä. Heistä useat 

olivat sitä mieltä, että epäjohdonmukaisuudet yrityksen viestinnässään käyttämässä 

termistössä vaikuttavat negatiivisesti myös yrityksen brändiin. Negatiivinen vaikutus 

brändiin koettiin merkittäväksi myös yrityksen sisäisessä viestinnässä. Melkein puolet 

kyselyyn vastanneista kertoivat, että heidän yrityksessään oli määritelty 

terminologiatyöprosessi, mutta silti jopa 85% oli havainnut epäjohdonmukaista termien 

käyttöä. (Hurst 2009) 

 

Vaikka tämän pohjalta terminologiatyö siis koetaan tärkeäksi yrityksissä, 

terminologiatyötä ei usein kuitenkaan yrityksissä tehdä, ja mahdollisia riskejä yrityksen 

terminologiatyön ja termistönhallinnan aloittamisessa onkin useita (Bauer & Brändle 

         

                  

      

                   

                   
                   

                  

                  

            

                   

                  

                             

                   

               

                           

                                    

                     

         

                              

          

                                 

                             
                        

             

                

               
                         

                         

                      

                 



38 

 

2013: 41–42). Kuten prosessinkehityshankkeissa yleensä, myös tässä motivaation 

puuttuminen on suuri riski: niin johdon kuin työtekijäportaan taholta tulisi saada 

riittävästi tukea terminologiatyöprosessille niin sanaston valmistamisen aikana kuin sen 

käyttöönotossakin. Terminologiatyöhön vaadittavien resurssien puuttuminen on riski, eli 

ihmisiä voi liian vähän, heillä ei ole aikaa, tai muut projektit vievät etusijan termityöltä. 

Lisäksi terminologiatyöprosessi tulisi saada liitetyksi osaksi ohjelmistoprosessia, eikä 

jäädä suoritettavaksi projektin loppupuolella. (Emt.) Terminologiatyöprosessin tulisi siis 

olla proaktiivista ja toimia yhdistettynä eri liiketoimintaprosessien välillä. (TerminOrgs 

2012: 13–14) 

 

Terminologiatyön puuttuminen voi johtua myös tietämättömyydestä. Esimerkiksi 

Kremer ym. (2005: 293) toteavat, etteivät yritykset välttämättä osaa tarttua epäselvien 

termien aiheuttamiin epäkohtiin. Syynä voi olla, ettei tunnisteta niiden aiheutuvan 

nimenomaan termiongelmista, tai yritykset eivät osaa lähteä korjaamaan niitä 

riittämättömän tiedon tai muiden resurssien, kuten rahan tai tekijöiden puutteen vuoksi. 

Myös Lombard (2006: 161) pitää tietoisuuden puuttumista yhtenä syynä, miksi 

yrityksissä ei tehdä terminologiatyötä. Termiongelmia ei tunnisteta, koska ohjelmiston 

tekijöille kaikki termit ovat selviä, eikä ohjelmistojen laadunvalvontaan yleisesti kuulu 

käytetyn termistön tarkasteleminen (emt. 161). 

 

Kuvioon 12 olen kerännyt tehokkaan termistönhallinnan tiellä olevia esteitä edellä 

tarkastelemieni lähteiden perusteella. Terminologiatyön ja termistönhallinnan 

aloittaminen vaatii, että yrityksessä tunnistetaan ongelmat, jotka aiheutuvat 

epäjohdonmukaisen ja sekavan termistön käytöstä, ja että löytyy halua ratkaista ne. Tämä 

vaatii sekä johdon että työntekijöiden motivoitumista terminologiatyön aloittamiseksi ja 

ylläpitämiseksi, sekä erityisesti johdon halukkuutta panostaa termistönhallintaan 

tarvittavia resursseja. Viimeisenä esteenä tehokkaalle termistönhallinnalle on vielä 

terminologisen työn aikatauluttaminen väärin: vasta projektin lopussa suoritettava 

termistön kerääminen ei enää ehdi vaikuttaa tuotteeseen tai sen dokumentaatioon. 

 



39 

 

 

 

Kuvio 12. Tehokkaan termistönhallinnan esteitä 

 

 

Käytännön esimerkkinä viestinnän epäonnistumisesta sanaston puuttumisen vuoksi 

toimii eräs tilanne tutkimukseni kohdeyrityksen espanjankielisen asiakkaan 

koulutustilaisuudessa. Tilaisuudessa käytettiin tulkkia kääntämään englanninkielinen 

koulutus espanjaksi. Eri puhelutyyppien hinnoitteluun liittyy englanninkielinen termi 

rate, josta tulkki käytti espanjankielistä vastinetta la tarifa. Eri rate profilet kootaan 

ohjelmistossa kuitenkin englanniksi tariff-nimiseen tietueeseen, eikä tulkki tiennyt enää 

mitä ohjelmistossa tarkoitettiin näillä termeillä. Tässä tilanteessa olisi ollut suurta hyötyä 

sanastosta, jossa käsitteet ja niiden suhteet olisi määritelty selkeästi. Selityksien tuloksena 

selvisi kuitenkin, että espanjaksi kyseessä on la tarifa plana. Tiedonvälityksen ja 

viestinnän virheettömyyden näkökulmasta terminologisella työllä merkitys on suuri. 

 

Eräs ratkaisuehdotus termistön rakentamiseen yritykselle on jo olemassa olevien 

erikoissanastojen käyttäminen. (Kremer ym. 2005: 293, 295.) Kohdeyritykseni erikois-

alalla on esimerkiksi olemassa kattava, standardisoitu televiestinnän sanasto, jota voisi 

käyttää hyödyksi kohdeyrityksen tuotteeseen liittyvän sanaston laatimisessa ja käsitteiden 

määritelmien laatimisessa. Sauberer (2011: 59) suosittelee, että yritysten kannattaa 

kuitenkin kerätä omaakin sanastoa nimenomaan yritys- ja tuotekohtaisen käsitteistön 

tallentamiseksi. Usein yrityksissä saattaa jo ollakin asiantuntijoilla omia listojaan 

termeistä ja käsitteistä, ja näitä voi käyttää pohjana termitietokannalle. Helposti 

         

                  

       

                                  

                       

                

                              

    

           

                 
           

               

                         

                           



40 

 

päivitettävä ja laajennettava termitietokanta voi tulevaisuudessa olla koko yrityksen 

käytössä oleva tietämyskanta. (Sauberer 2011: 59)  

 

 

4.4 Terminologiatyön vaiheita  

 

Terminologista työtä tehdään usein projektimuotoisesti, jolloin projektilla on määritetty 

alku ja loppu, mahdollisesti oma työryhmänsä sitä tekemässä sekä määritelty lopputulos, 

kuten esimerkiksi julkaistavan sanaston muodossa (ks. esimerkiksi Sanastotyö käsikirja 

1988). Yritysten terminologiatyö saattaa kuitenkin olla erilaista, eikä tarve ole yhden 

sanaston tuottamiselle vaan jatkuvalle terminologiatyölle kehitysprojektista toiseen.  

 

Terminologiatyön suunnittelu tulee aloittaa ajoissa kohdeyritykseni kaltaisissa tilanteissa, 

joissa aiemmin ei ole tehty järjestelmällistä terminologista työtä. Sauberer ym. (2017: 

655–656) korostavat, että aivan ensimmäiseksi täytyy saada yrityksen johdon ja 

avainhenkilöiden tuki, joka mahdollistaa terminologisen työn toimintaperiaatteiden 

kehittämisen ja toteuttamisen yrityksessä. Avoin viestintä kaikkien eri sidosryhmien 

kanssa on tärkeää alusta asti, ja on hyvä käsitellä myös uusien toimintatapojen esittelyn 

esiin nostamat negatiivisetkin asiat: esimerkiksi työmäärän lisääntyminen saattaa herättää 

vastustusta (emt.). 

 

Samoin Lombard (2006: 168) korostaa johdon tuen merkitystä, kun suunnitellaan 

terminologiatyön ja järjestelmällisen termistönhallinnan aloittamista yrityksessä. Johdon 

tuen saamiseen tarvitaan kuitenkin koko työyhteisön tuki ja apu. Yhden työntekijän on 

vaikea saada ääntään kuuluviin tai hoitaa ainoana henkilönä termistönhallinnan tehtäviä, 

mutta eri osastojen välinen yhteistyö voi tuottaa paremmin tulosta. Tärkeimmäksi asiaksi 

termistönhallinnan suunnittelussa hän kuitenkin nostaa työkalun, ja ennen kaikkea, että 

sen on oltava keskitetty. Työkalu voi olla termistönhallintatietokanta tai Excel-taulukko, 

mutta sille on osoitettava yrityksen tietojärjestelmässä keskeinen paikka, johon kaikilla 

työntekijöillä on pääsy. (Emt.) 

 

 



41 

 

Sauberer ym. (2017: 657) suosittelevat, että uutena esiteltävät terminologiset toimenpide-

ehdotukset on hyvä dokumentoida jonkinlaiseen toimintasuunnitelmaan tai 

ohjeistukseen, joka on yhteensopiva yrityksen muiden alueiden (esimerkiksi myynti, 

tuotanto, dokumentointi, viestintä) toimintasuunnitelmien kanssa. Toiminta-

suunnitelmassa tulisi huomioida terminologiatyön sidosryhmät, työn tarkat tavoitteet ja 

laajuus (esimerkiksi onko tarkoitus saada termistönhallinnan piiriin kaikki yrityksessä 

käytettävä termistö vai keskittyä tuotteessa käytettävään termistöön) sekä 

terminologisesta työstä saatavat hyödyt. (Sauberer ym. 2017: 657–658) 

 

Terminologiatyön suunnittelun avuksi löytyy siihen liittyviä standardeja ja ohjeita 

runsaasti. Esimerkiksi tärkeimpiä ISO-standardeja ovat mm. ISO 704: 2009 Terminology 

work -- Principles and methods, ISO-1087 Terminology work – Vocabulary Part 1: 

Theory and application sekä ISO-15188 Project guidelines for terminology 

standardization. Suomenkielistä ohjeistusta antaa mm. Sanastotyön käsikirja (1988) ja 

Sanastokeskuksen kotisivuilla on todella runsaasti tietoa terminologiatyöhön ryhtyville 

tai siitä kiinnostuneille (Sanastokeskus TSK 2018). 

 

Kun yrityksen tavoitteet terminologiatyölle on saatu määriteltyä ja yritystasoinen 

toimintasuunnitelma on luotu, seuraa näiden suunnitelmien toteuttaminen käytännön 

tasolla. Kattavan sanastoprojektikuvauksen on tehnyt Nykänen (1999) Sanastoprojektin 

vaiheet -artikkelissaan, ja aion mukailla hänen sanastoprojektivaiheitaan ehdotuksessani 

kohdeyrityksen terminologiatyön vaiheiksi. Kuvioon 13 olen koonnut vaiheet, jotka hän 

on esittänyt sanastoprojektiin kuuluviksi.  

 

 

 

Kuvio 13. Sanastoprojektin vaiheet Nykäsen mukaan 

 

                

       

                     

                

               

                   

                

           



42 

 

Sanastoprojektin suunnittelu. Nykänen (1999: 63) korostaa ennen projektin alkamista 

tehtävän suunnittelun tärkeyttä. Projektilla täytyy olla selkeä tavoite, ja täytyy selvittää 

mihin tarpeisiin projektilla ollaan vastaamassa: mikä on ongelma, mikä aiheuttaa sen, 

ovatko syynä esimerkiksi termistön epäselvyydet ja väärin käyttäminen? Lisäksi täytyy 

miettiä projektiin tarvittavat resurssit ja toimet, millainen halutaan lopputuloksen olevan, 

julkaistaanko se paperina vai talletetaan sähköisenä, sekä mitä hyötyjä projektista 

odotetaan saatavan. (kuvio 14). Tässä vaiheessa myös tehdään alustava 

projektisuunnitelma. (Emt. 63) 

 

 

 

Kuvio 14. Sanastoprojektin suunnitteluvaiheessa käsiteltävät asiat 

 

 

Monet Nykäsen listaamista seikoista käsitellään jo yrityksen terminologiatyön 

toimintasuunnitelmassa, jos sellainen tehdään. Projektitasolla suunniteltavaksi jää 

konkreettiset tavoitteet (esimerkiksi ”Dokumentoida projektissa X ominaisuuden Y uudet 

käsitteet”), projektissa käytössä olevat resurssit sekä aikataulu. Laadun tulisi olla 

etusijalla myös terminologisessa työssä, mutta käytännössä esimerkiksi liian tiukat 

aikataulut saattavat vaikuttaa siihen negatiivisesti. Tällöin terminologiselle työlle tulisi 

miettiä myös tavoitteiden prioriteetit: onko tärkeintä sanaston laatu, nopea saatavuus vai 

esimerkiksi projektissa käytetyn termistön yhdenmukaistaminen. (Sauberer ym. 2017: 

661) 

 

 

           

      

                      

            

          

               

      

         

       

                       



43 

 

Aloittamispäätös. Aloittamispäätös tarkoittaa projektille vihreän valon näyttämisen 

lisäksi sitä, että projektille tehdään viimeistelty projektisuunnitelma. Sanastoprojektin 

projektisuunnitelma voi olla erillinen, tai jos sanastoprojekti on osa 

ohjelmistotuotantoprojektia, se voi olla osana sen projektisuunnitelmaa. 

Projektisuunnitelmassa tulee kuitenkin ilmetä terminologiatyön tehtävät, näiden 

tehtävien tekijät, aikataulu, budjetti, raportointi ja esimerkiksi projektissa käytössä olevat 

työkalut. Myös projektin organisaatio ja mahdollinen perehdytystarve on hyvä olla osa 

projektisuunnitelmaa (Nykänen 1999: 64–66).  

 

Laatimisvaihe. Sanaston laatimisvaiheessa tehdään varsinainen termityö. Nykänen (1999: 

65–67) jakaa tämän vaiheen kolmeen osaan: termien keräämiseen, käsiteanalyysiin ja 

määrittelyyn sekä sanaston tallennustyöhön (kuvio 15). Termien keräämisessä voi käyttää 

hyväkseen jo olemassa olevia sanastoja ja kerätä lähdeaineistosta termiehdokkaita. 

Pienien sanastojen ollessa kyseessä voi aloittaa termien ja käsitteiden keräämisen 

muutaman ydinkäsitteen ympärille kasvavaan käsitejärjestelmään. Käsiteanalyysissa 

tunnistetaan käsitteiden olennaiset käsitepiirteet ja -suhteet. Tämä auttaa myös käsitteiden 

määritelmien tekemisessä. (Emt. 65–67)  

 

 

 

Kuvio 15. Sanaston laatimisvaihe 

 

 

Lausuntokierros. Seuraava vaihe on lausuntokierros, jossa sanasto lähetetään työryhmää 

laajemmalla jakelulla kommentoivaksi. Nykänen (1999: 67) näkee, että lausuntokierros 

        

          

                     

               

           

              

                            
             

              

                  

                                

                                   

                 

                  

                



44 

 

on myös sanaston markkinointia eri sidosryhmille. Lausuntokierrokseen olisi hyvä varata 

riittävästi aikaa, jopa kuukausi (emt.). Tällainen kuukauden lausuntokierros ei useinkaan 

olisi mahdollista ohjelmistotuotantoprojektin aikana, mutta sanaston etenemisestä voisi 

esimerkiksi tiedottaa erilaisilla uutissähköposteilla tai intranetissä, ja pyytää siitä 

palautetta suunnittelu- ja kehitysvaiheiden aikana.  

 

Viimeistelyvaihe. Lausuntokierroksen jälkeen seuraa sanaston viimeistelyvaihe. 

Lausuntokierroksella saadut palautteet sekä muut tarkistukset ja huomiot korjataan 

sanastoon. Valmis sanasto talletetaan ja julkaistaan lopullisessa julkaisumuodossaan, ja 

sen valmistumisesta tiedotetaan laajasti. (Nykänen 1999: 69)  

 

Projektin päättäminen on viimeistelyn viimeinen työvaihe. Projektille voidaan laskea 

lopullinen hinta, ja arvioida muutenkin projektin onnistuminen. (Nykänen 1999: 69) 

Monissa kohdeyrityksen kaltaisissa yrityksissä on projektin jälkeen tapana kerätä 

projektiryhmän jäseniltä palautetta päättyneestä projektista (Lessons to Learn), miten 

hyvin onnistuttiin, olivatko työkalut, menetelmät ja vastuiden jaot onnistuneita ja niin 

edelleen. Tällainen on tärkeää erityisesti uudenlaisten projektien kohdalla.  

 

Aion käyttää tässä luvussa läpikäytyä teoriaa termistönhallinnasta sekä terminologiatyön 

vaiheista luvussa 6, johon kerään toimenpide-ehdotuksia terminologiatyön ottamiseksi 

mukaan osaksi kohdeyrityksen ohjelmistotuotantoprojekteja. Tarkastelen luvussa 4.2 

esiteltyjä tehokkaan termistönhallinnan esteitä ja hyötyjä, vertailen niitä yrityksen 

tilanteeseen sekä yhdistän nämä tiedot, terminologisen työn vaiheiden kuvauksen ja 

yrityksen ohjelmistoprojektin luodakseni kuvauksen terminologiatyön yhdistämiseksi 

osaksi päivittäistä toimintaa kohdeyrityksessä. 



45 

 

5 ANALYYSI OHJELMISTOPROJEKTIN TERMEISTÄ  

 

Tässä luvussa selvitän, millaista termistöä tarkastelemani ohjelmistotuotantoprojektin eri 

vaiheissa käytetään, kuka käyttää ja miten. Tarkoitukseni on muodostaa kokonaiskuva 

sekä kohdealalla käytettävän termistön ominaispiirteistä että siitä, miten termejä 

käytetään ja muodostetaan kohdeyrityksessä. Tulosten pohjalta teen seuraavassa 

pääluvussa 6 yritykselle toimenpide-ehdotuksia terminologisen työn aloittamiseksi osana 

ohjelmistotuotantoprojektia.  

 

Kohdeyritykseni erään ohjelmistotuotantoprojektin tekninen dokumentaatio muodostaa 

tutkimukseni aineistolähteen, josta keräsin käsitteitä ja termejä määrällistä ja laadullista 

tarkastelua varten. Kuvaan aineistoa ja terminpoimintaa alaluvuissa 5.1 ja 5.2, jonka 

jälkeen käyn läpi termien määrät ohjelmistoprojektin eri vaiheissa alaluvussa 5.3. Sen 

jälkeen tarkastelen termien rakennetta ja ominaisuuksia (5.4) selvittääkseni, millaista 

termistöä kohdeyrityksen ohjelmistotuotantoprojektissa käytetään. Käyn läpi ensin 

määrällisesti termien rakennetyyppejä ja sanaluokkia (5.4.1), jonka jälkeen analysoin 

termien rakennetta ja muotoa (5.4.2), muun muassa millaisista elementeistä termejä on 

muodostettu. Sen jälkeen siirryn arvioimaan ohjelmistoprojektin termien ominaisuuksia 

niiden suhteissa käsitteisiin (5.4.3) sekä käytön johdonmukaisuuden mukaan (5.4.4). 

Lopuksi selvitän miten ja ketkä projektiryhmän jäsenet osallistuivat ohjelmistoprojektin 

eri vaiheisiin (5.5) ja lopuksi yhteenvedon (5.6). Aivan aluksi esittelen aineistolähteet 

sekä kuvailen, miten suoritin terminpoiminnan. 

 

 

5.1 Aineistolähteiden esittely 

 

Käytän aineistolähteenä 15 erilaista ohjelmistotuotantoprojektiin liittyvää määrittely- ja 

suunnitteludokumenttia, evaluointivaiheen testitapauksia ja asiakasdokumentaatiota, 

jotka kattavat yhden ohjelmisto-ominaisuuden lisäkehitystyön. Rajasin tämän ohjelmisto-

ominaisuuden dokumentaation aineistolähteikseni, koska siihen kohdistuvat muutokset 

olivat merkittäviä, ja tämä kehitystyö oli koko projektin suurin niin työmäärällisesti kuin 

dokumentaation määrältään. Muut samassa ohjelmistoprojektissa tehdyt työt olivat 



46 

 

huomattavasti pienempiä tai liittyivät ohjelmiston aiempien välijulkaisujen 

yhdistämiseen uuden julkaisun kanssa. Taulukkoon 2 olen koonnut projektivaiheittain 

dokumentit, niiden lyhyen kuvauksen sekä A4-sivumäärän. 

 

 

Taulukko 2. Aineistolähteinä toimivat dokumentit 

 

Vaihe Dokumentit Dokumentin kuvaus Sivu- 

määrä 

Vaihe 1: 

suunnittelu 

System Design Järjestelmätason kuvaus ja suunnitelma uuden 

julkaisun vaikutuksista tuotteeseen 

13 

 
Feature Requirement 

Specifications (FRS) 

Vaatimusmäärittelydokumentti kehitysvaiheen 

työn pohjaksi 

10 

 
FRS Review Record Vaatimusmäärittelydokumentin 

katselmointipöytäkirja, jossa kommentoituina 

FRS-dokumenttiin tehtävät muutokset ennen 

FRS-dokumentin hyväksymistä 

1 

Vaihe 2: 

kehitys 

High Level Design 

(HLD) 

Järjestelmätason suunnitelma ominaisuuksien 

vaikutuksesta tuotteeseen 

13 

 
TP Tech Design Suunnitelma yksittäisen ominaisuuden 

teknisestä toteutuksesta tuotteen 

osajärjestelmässä 

16 

 
TP UI Design Suunnitelma ominaisuuden kehitystyön 

aiheuttamista käyttöliittymämuutoksista 

tuotteen osajärjestelmässä 

2 

Vaihe 3: 

evaluointi 

TP Integration tests Integrointitestitapaukset 7 

 
MG Integration tests Integrointitestitapaukset 3 

 
TP Test Cases Osajärjestelmän testitapaukset 7 

 
TP Test Case Review 

Record 

Osajärjestelmän testitapauksien 

katselmointipöytäkirja 

1 

 
MG Test Cases Osajärjestelmän testitapaukset 10 

 
MG Test Case Review 

Record 

Osajärjestelmän testitapauksien 

katselmointipöytäkirja 

1 

 
MG API Test Cases Osajärjestelmän testitapaukset 8 

Vaihe 4: 

julkaisu 

Feature Description Ominaisuuden kuvaus ja käyttöohje 12 

 
What's New Tuotteen uusien ja kehitettyjen 

ominaisuuksien lyhyt esittely 

2 

  yhteensä 106 

 

 

 

 

 

 



47 

 

Dokumentit on tuotettu tarkastelemani ohjelmistoprojektin eri vaiheissa. Näiden 

dokumenttien tarkoitus ja sisältö on kuvailtu yrityksen ohjelmistotuotantoprosessissa. 

Edellisen projektivaiheen dokumentit toimivat aina syötteinä eli tietona, jota projektin 

seuraavan vaiheen toiminnot ja dokumentit käyttävät pohjanaan. 

 

Projektidokumenteilla on omat tarkoituksensa ja sillä voi olla merkitystä niissä 

esiintyvien termien määrään. Jotkut dokumentit ovat esimerkiksi eräänlaista meta-

dokumentaatiota: ne eivät sisällä projektin teknistä informaatiota, vaan käsittelevät sen 

dokumentaatiota eli ovat dokumentteja dokumenteista. Tällaisia ovat projektin teknisten 

dokumenttien katselmointipöytäkirjat. Ne eivät sisällä niin paljon termejä ja käsitteitä 

kuin dokumentit, jotka käsittelevät itse ominaisuutta eivätkä sen dokumentaatiota. 

 

Tulostettuna aineistolähteiden määrä oli n. 100 A4-liuskaa. Suurin osa dokumenteista on 

PDF-muotoisina, mutta osa on HTML-sivuina sekä vaatimustenhallintajärjestelmän 

käyttöliittymästä tulostettuina. Osan ohjelmistotuotantoprosessissa määritellyistä ja 

tarkastelemassani projektissa tuotetuista dokumenteista rajasin aineistolähteistä pois, 

koska ne eivät sisältäneet käsite- tai termitietoa. Tällaisia olivat esimerkiksi sellaiset 

dokumentit, jotka sisälsivät vain tietokantakenttien koodeja, tai katselmointipöytäkirjat, 

joissa ei ollut mitään kommentteja eli sisälsivät pelkästään taulukon kommenttien 

keräämistä varten. FRS Review Record -dokumentissa oli vain yksi kommentti, jossa 

käytettiin tarkasteltavaan ominaisuuteen liittyvää termiä, ja niin otin sen dokumentin 

aineistoläheisiin mukaan. 

 

 

5.2 Termien poiminta projektidokumentaatiosta 

 

Keräsin termit aineistolähteistä manuaalisesti. Luin läpi tulostamani dokumentit, ja 

alleviivasin niistä kaikki löytämäni termiehdokkaat. Nämä termiehdokkaat sijoitin sitten 

dokumenteittain satelliittimalliin ja ryhmittelin ne niin, että samaan käsitteeseen liittyviä 

termejä tuli saman noodin alle. Satelliittimalli rakentui niin, että keskusnoodina toimi 

otsikko Termit vaiheittain. Keskusnoodista lähtevissä neljässä alanoodissa oli projektin 

vaiheen nimi, ja sen jälkeen omina alanoodeinaan eli jakoperusteina projektin vaiheeseen 



48 

 

kuuluvien dokumenttien nimet, joiden alle keräsin termit. Kuviossa 16 on nähtävissä, 

miten satelliittimalli muodostui keskusnoodin ympärille. 

 

 

 

Kuvio 16. Satelliittimalli terminpoiminnan työkaluna 

 

 

Satelliittimallissa pystyin tarkastelemaan useampisanaisia termejä, erityisesti olivatko 

kaikki keräämäni sanaliiton sanat osa termiä vai vain muita kuvailevia ilmaisuja. Koska 

aineistoni oli kokonaisuudessaan teknistä erikoissanastoa, oli suhteellisen helppo erottaa 

yleiskielen sanat erikoiskielen sanoista. Esimerkiksi aineistossa termi library oli helposti 

ymmärrettävissä tarkoittamaan tietokantoihin liittyvää kirjastoa, eikä fyysisten kirjojen 

julkista tai yksityistä kokoelmaa. 

 

Synonymian selvittämiseksi tein vielä subscription-termin ympärille käsite-

järjestelmäkaavion. Tähän käsitejärjestelmään kuuluivat luontevasti kaikki aineistosta 

poimitut termit. Subscription muodostaa satelliittimallin päänoodin. Seuraavat alanoodit 

                      

                      
              

                       

                     

                 

                     

                 

                       

                       

                     

                     

                              

                  

             

       

        
      

           

    

      

         

            

                              

             

        

        
      

            

            

            

        
                  



49 

 

sisältävät subscription-käsitteeseen eri tavoin liittyviä muita termejä ja käsitteitä (kuvio 

17). Jaottelin ne erilaisten apunoodien alle, jotka sisältävät vapaamuotoisen sanallisen 

kuvauksen käsitteiden välisestä suhteesta.  

 

 

 

Kuvio 17. Aineiston käsitejärjestelmän aloitusnoodit 

 

 

Kuvion olisi helposti voinut jakaa pienempiin käsitejärjestelmäkaavioihin, esimerkiksi 

päänoodeihin subscription sekä account, joka muodosti jo laajan kokonaisuuden siihen 

liittyvien käsitteiden kanssa. Kuviossa 18 näkee, millaisilla apunoodeilla jaottelin 

account-käsitteeseen kuuluvia termejä. Apunoodit luokittelevat termejä tai jakautuvat 

edelleen, kuten esimerkiksi tasoon vaikuttaa -noodi jakautuu edelleen noodeihin 

alentavasti ja korottavasti, joihin liittyviä termejä oli seuraavissa noodeissa.  

 

 

 

Kuvio 18. Account-termi päänoodina satelliittimallissa 

 

 

            

                           

                  

            

                   

             

      

                

          

           

                    

       

    

                   

       

           

           

            

             

               

         

        

           

               

        

                

       



50 

 

5.3 Termien määrällinen tarkastelu eri projektivaiheissa 

 

Tässä luvussa tarkastelen lähinnä määrällisesti, miten ohjelmistotuotantoprojektin eri 

vaiheet eroavat toisistaan termien käytöltään. Vertailen ensin termimääriä eri 

dokumenttien ja projektivaiheiden kesken ja olen koonnut nämä tiedot taulukkoon 3. Sen 

jälkeen tarkastelen lähemmin eroja eri dokumenteissa ja niissä esiintyvissä termeissä.  

 

 

Taulukko 3. Poimittujen termien määrät eri vaiheissa ja dokumenteissa 

 

Vaihe Termien 

määrä 

% Dokumentti Termien 

määrä 

% 

Suunnittelu 69 (74) 38,33 FRS 67 30,04 

FRS review record 1 0,45 

System Design 6 2,69 

Kehitys 30 (39) 16,67 HLD 18 8,07 

Technical Design 11 4,93 

UI Design 10 4,48 

Evaluointi 49 (74) 27,22 TP INT tests 14 6,28 

MG INT tests 5 2,24 

TP Test cases 23 10,31 

TP Test case review 7 3,14 

MG Test cases 10 4,48 

MG Test case review 3 1,35 

MG API Test cases 12 5,38 

Julkaisu 32 (36) 17,78 Feature Description 32 14,35 

What's New? 4 1,79 

Yhteensä 180 (223) 100  223 100 

 

 

Selvittääkseni, miten ohjelmistoprojektien eri vaiheet eroavat toisistaan termien 

käytöltään, laskin missä ohjelmistotuotantoprojektin vaiheessa oli käytössä eniten eri 

termejä. Laskin ensin, moniko keräämistäni termeistä kussakin projektin dokumentissa 

esiintyi (taulukko 3, oikealla). Kun olin selvittänyt eri vaiheissa esiintyvien eri termien 

määrät dokumenteittain, laskin montako eri termiä ohjelmistoprojektin eri vaiheissa 



51 

 

esiintyi (taulukko 3, vasemmalla). Suluissa näkyvä luku on käytettyjen termien määrä 

yhteenlaskettuna vaiheen kaikista dokumenteissa, ja varsinaisen termimäärän olen saanut 

laskemalla eri termien esiintymisen pelkästään vaiheen mukaan. 

 

Selvästi eniten termejä, 67 termiä, oli käytössä vaatimusmäärittelydokumentissa (FRS). 

Termimäärä on huomattavan suuri verrattuna seuraavaksi eniten termejä sisältävään 

dokumenttiin, joka oli ohjelmisto-ominaisuuden kuvailudokumentissa (Feature 

Description 32 termiä). Kolmanneksi eniten termejä esiintyi järjestelmätestauksen 

testitapauksissa. Testitapausten kohteena oli tuotteen osajärjestelmä, johon ominaisuuden 

kehitystyö projektissa vaikutti eniten. Vähiten termejä oli FRS-dokumentin 

katselmointipöytäkirjassa (yksi termi) sekä toisen osajärjestelmän testitapauksissa (kolme 

termiä). Tähän toiseen osajärjestelmään ei kohdistunut niin paljon kehitystyötä 

tarkasteltavan ohjelmisto-ominaisuuden osalta, mikä selittää harvan terminkin 

esiintymisen.  

 

Tämän jälkeen laskin montako eri aineiston termiä esiintyi ohjelmistoprojektin eri 

vaiheissa. Ensin laskin eri termien määrän kussakin vaiheessa laskemalla yhteen 

vaiheeseen kuuluvien dokumenttien termimäärät (kuvio 19). Eniten termejä esiintyi 

suunnitteluvaiheessa ja evaluointivaiheessa, joissa molempien vaiheiden dokumenteissa 

esiintyi 74 termiä. Kehitys– ja julkaisuvaiheen termimäärät olivat huomattavasti 

pienemmät, 39 ja 36 termiä.  

 



52 

 

 

 

 

Evaluointivaiheessa oli kuitenkin projektin suurin määrä erilaisia dokumentteja, joten sen 

sijaan, että olisin vain laskenut yhteen dokumenttien termimäärät niin, että laskin saman 

termin mukaan useamman kerran eri dokumenteista, laskin termien esiintymisen vain 

kerran kunkin projektivaiheen aikana (kuvio 20). Tällä tavalla vain kerran mukaan 

laskettuina eniten termejä esiintyi edelleen suunnittelu- ja evaluointivaiheissa, mutta 

suunnitteluvaiheessa eri termejä esiintyi 69 ja evaluointivaiheessa vain 49. Kehitys- ja 

julkaisuvaiheiden termimäärät olivat melkein samat, 30 ja 32 termiä. Suunnittelu-

vaiheessa esiintyvä termimäärä on siis yli kaksinkertainen verrattuna kehitys- ja 

julkaisuvaiheen dokumenttien termeihin. 

 

 

Kuvio 19. Poimittujen termien esiintymiskerrat dokumenteissa 

projektivaiheittain 

74

39

74

36

0

10

20

30

40

50

60

70

80

Vaihe I suunnittelu Vaihe II kehitys Vaihe III evaluointi Vaihe IV julkaisu

Termit vaiheittain (yhteenlaskettu dokumentit)



53 

 

 

 

Mitään aineiston termeistä ei käytetty kaikissa 15 dokumentissa. Syynä tähän lienee 

dokumenttien erilaiset tarkoitukset ja sisällöt, eli samoja tietoja ei kierrätetä eri 

dokumenteissa. Kaksi termiä esiintyi 13 dokumentissa ja yksi 12 dokumentissa. Nämä 

termit olivat alternate subscription, notification ja default subscription. Neljässä tai 

useammassa dokumentissa käytettyjä termejä oli 9. Ainoastaan yhdessä dokumentissa 

esiintyneitä termejä oli siis peräti 94 kappaletta (kuvio 21). 

 

 

Kuvio 20. Poimittujen termien yksittäiset esiintymiset projektivaiheittain 

69

30

49

32

0

10

20

30

40

50

60

70

80

Vaihe I suunnittelu Vaihe II kehitys Vaihe III evaluointi Vaihe IV julkaisu

Termit vaiheittain 



54 

 

 

 

Kuvio 21. Termien määrät sen mukaan, monessako dokumentissa ne esiintyivät 

 

 

Vaatimusmäärittelydokumentissa (FRS) esiintyi 67 termiä. System Design –

dokumentissa esiintyi kuusi termiä. Näistä yhteisiä FRS-dokumentin termien kanssa oli 

kolme, alternate subscription, default subscription ja FRS:n katselmointipöytäkirjassa 

ainoana terminä esiintynyt notification.  

 

FRS:ssä esiintyvien eri termien suuri määrä selittyy dokumentin luonteella: se kerää 

ominaisuudelle esitetyt vaatimukset yhteen sekä sisältää myös kuvailevampaa tekstiä 

käyttöesimerkkien muodossa. System Design –dokumentissa ei ollut ominaisuuteen 

liittyen niin paljon viittauksia, jolloin termimäärä jäi pieneksi. FRS-dokumentin 

katselmointipöytäkirjaan oli kirjattu vain yksi huomautus, jossa mainittiin yksi termi.  

 

Suurin termimäärä oli kehitysvaiheessa HLD-dokumentissa, 18 termiä. Technical Design 

ja UI Design –dokumenteissa oli 11 ja 10 termiä. Vaikka ero eniten termejä sisältävän 

dokumentin ja muiden välillä ei ole niin suuri kuin suunnitteluvaiheessa oli dokumenttien 

kesken, tässäkin ero selittynee HLD-dokumentin yleisemmällä luonteella kehitystyön 

94

18

8

3 2 11 2

Monessako dokumentissa termi esiintyi

1 dokumentissa

2 dokumentissa

3 dokumentissa

4 dokumentissa

5 dokumentissa

9 dokumentissa

12 dokumentissa

13 dokumentissa



55 

 

määrittelyssä. HLD-dokumentissa esiintyi myös eniten ohjelmointiin liittyvää termistöä, 

kuten API, common library, database library ja XML.  

 

Jokaisessa kolmessa dokumentissa esiintyviä termejä oli vain kaksi: subscription ja 

alternate subscription. Kahdessa dokumentissa esiintyviä termejä oli viisi (nämä kaikki 

HLD- ja TD-dokumenteissa), eli suurin osa termeistä esiintyi vain yhdessä dokumentissa. 

UI Design –dokumentissa termejä löytyi käyttöliittymän näyttökuvista, ja ne liittyivät 

esimerkiksi muihin kuin kehitettävään ominaisuuteen, ja niitä termejä ei ollut sen takia 

muissa kehitysvaiheen dokumenteissa.  

 

Evaluointi- eli testausvaiheen dokumenttimäärä on suurin, seitsemän dokumenttia. 

Ohjelmistokehittäjät ja –testaajat kirjoittavat ominaisuuden vaatimus- ja toteutus-

dokumentaation pohjalta erilaisia testitapauksia. Testitapaukset on tallennettu 

laadunhallintatietokantaan, josta olen tulostanut ne. Dokumentit olivat A4-tulosteina 1–

10 sivuisia ja kokonaisuudessaan evaluointivaiheen materiaalia oli 38 A4-liuskaa. 

Testitapaukset on katselmoitu, ja katselmointipöytäkirjat ovat aineistolähteissä mukana, 

jos niissä on ollut testitauksiin liittyviä kommentteja, eikä pelkästään ”Ei kommentteja”. 

 

Tässä projektivaiheessa kehittäjät testaavat ominaisuuden ja järjestelmän 

yhteensopivuuden, ja sen lisäksi testataan ominaisuuden uusi toiminnallisuus koko 

järjestelmässä muiden ominaisuuksien kanssa. Näitä dokumentteja aineistossani (kuvio 

22) ovat TP Integration tests (TP INT tests), MG Integration tests (MG INT tests) sekä 

MG API Integration tests (MG API INT tests).  

 

 



56 

 

 

 

Laajemmat järjestelmätestit suoritetaan testaamalla uusi toiminnallisuus yhdessä vanhan 

kanssa. Erilaiset testitapaukset suunnitellaan ja dokumentoidaan, ja dokumentit 

katselmoidaan eli tarkastetaan yhdessä kehittäjien sekä järjestelmäsuunnittelijan kanssa. 

Nämä testitapaukset ovat dokumenteissa TP Test Cases, MG Test Cases ja MG API Test 

cases. Katselmointipöytäkirjat, joissa aineistossani oli kommentteja, olivat TP test case 

Review Record ja MG Test Case Review Record.  

 

Näissä dokumenteissa esiintyvien eri termien määrät eivät ole suuria. Eniten eri termejä 

esiintyi TP Test Cases –dokumentissa, jossa oli 23 termiä poimituista 129:stä. Vähiten 

termejä oli MG-testitapausten katselmointipöytäkirjassa MG Test Case review, jossa oli 

kolme termiä. Myös TP Integration tests –dokumentissa esiintyi enemmän termejä kuin 

MG Integration tests –dokumentissa (14 termiä ja 5 termiä). Ero johtunee paljolti siitä, 

että kehitettävän ominaisuuden muutokset heijastuivat näihin järjestelmän eri osiin 

(TP=Transaction Processor eli tapahtumien prosessointijärjestelmä, MG=Management 

Gateway eli asiakastiedonhallintajärjestelmä) eri tavalla. 

 

Yksikään poimituista termeistä ei esiintynyt jokaisessa tämän vaiheen dokumentissa. 

Kolme termiä esiintyi kuudessa dokumentissa, yksi termi neljässä ja yksi kolmessa 

14

5

23

7

10

3

12

0

5

10

15

20

25

TP INT tests MG INT
tests

TP Test
cases

TP Test case
review

MG Test
cases

MG Test
case review

MG API Test
cases

Vaihe III: Evaluointi

 

Kuvio 22. Evaluointi- eli testausvaiheen dokumentit termimäärineen 



57 

 

dokumentissa. Loput termit esiintyivät kahdessa tai vain yhdessä dokumentissa. 

Dokumenttien tarkoitus ja testitapausten kohteena oleva järjestelmän osa vaikuttaa 

millaiset termit esiintyvät kussakin dokumentissa. Kehitettävään ominaisuuteen suoraan 

liittyvät termit default subscription, alternate subscription ja notification esiintyivät 

kaikissa dokumenteissa lukuun ottamatta MG Test Case Review –dokumenttia, koska 

katselmointipöytäkirjaan ei tullut yhtään kommenttia näihin liittyen.  

 

Julkaisuvaiheen dokumenttien kohderyhmä on aiemmista dokumenteista poiketen 

asiakasyritys eivätkä ne ole pelkästään yrityksen sisäiseen käyttöön. Kohderyhmä on 

saman erikoisalan asiantuntijoita, mutta näitä dokumentteja voidaan käyttää myös 

markkinoinnin tukena. What’s New –dokumentti esittelee asiakkaalle lyhyesti julkaisun 

uudet tai edelleen kehitetyt ominaisuudet. Dokumentti on lyhyt ja tarkastelemani ominai-

suuden osuus oli noin kaksi A4-liuskaa. Feature Description –dokumentti esittelee 

ominaisuuden tarkemmin, ja sen lisäksi dokumentissa on ohjeet ominaisuuden käyttöön-

ottoon ja käyttämiseen.  

 

Lyhyessä What’s New –dokumentissa esiintyi neljä termiä poimimistani 129:stä. Niin 

sisällöltään kuin sivumäärältäänkin laajemmassa Feature Description –käyttöohjeessa 

esiintyi 32 termiä. Kaikki What’s New –dokumentin neljä termiä esiintyivät myös Feature 

Description –dokumentissa, ja ne olivat suoraan kehitettävään ominaisuuteen liittyviä. 

Kaikki vaiheessa esiintyvät termit olivat tuotteeseen liittyviä tai televiestintäalan sanas-

toa, eikä esimerkiksi erityisesti tietotekniikan alan termejä juurikaan ollut.  

 

Projektidokumentaatiossa siis käytetään erilaisia termejä eri dokumenteissa riippuen 

niiden tarkoituksesta. Synonyymisten termien käyttöä niin eri projektivaiheissa kuin 

saman dokumentin sisälläkin esiintyi. Käytetyissä termeissä oli eroja myös tuotteen 

osajärjestelmien dokumenttien välillä.  

 

Kohdeyrityksen terminologiatyön kannalta yksittäisissä dokumenteissa esiintyvien 

termien suuri määrä voi tarkoittaa sitä, että ohjelmistoprojektin aikana – ja nimenomaan 

kyseisen ohjelmistoprojektin termistönkäytön yhtenäistämisessä – tehtävässä termi-

nologisessa työssä ei ole tarvetta sisältää sanastoon kaikkia projektin aikana esiintyviä 



58 

 

käsitteitä ja termejä. Projektin aikana voisi keskittyä vain olennaisimpiin käsitteisiin, 

joiden lukumäärä on merkittävästi rajallisempi. Projektin ydinkäsitteet on asiantuntijan 

luultavasti helppo tunnistaa, koska ne liittyvät kehitystyön kohteena olevaan projektiin 

selkeästi. Näiden ydinkäsitteiden ympärille rakennettavaan käsitejärjestelmään 

lisättävien käsitteiden tunnistamisessa voisi auttaa esimerkiksi käsitekarttojen tai 

satelliittimallin käyttäminen työkaluna vaatimustenkeräys- ja –määrittelyvaiheissa.  

 

Jos taas terminologisen työn tavoitteena on saada vasta projektin jälkeen koottu ja 

julkaistu sanasto, terminologisen työn apuna voisi projektissa käyttää terminpoiminnassa 

automaattisia työkaluja, ja laskea esimerkiksi termien esiintymistiheyttä lähde-

dokumentaation sisällä olennaisten termien ja käsitteiden selvittämiseksi. Seuraavassa 

projektivaiheessa tuotettujen dokumenttien uudet termit voisi poimia mukaan alustavaan 

termilistaan esimerkiksi kohdeyrityksen tekninen kirjoittaja, jonka tehtäviin kuuluisi 

käsitteiden määrittely sanastoa varten yrityksen asiantuntijoiden avulla. Ohjelmisto-

tuotantoprojektin lopussa katselmoitaisiin ja hyväksyttäisiin valmis sanasto