VAASAN YLIOPISTO 

TEKNILLINEN TIEDEKUNTA 

TIETOTEKNIIKKA 

 

 

 

 

 

 

 

 

 

 

Jukka Kumpusalo 

SISÄLLÖNHALLINTAJÄRJESTELMÄN OMINAISUUDET SEKÄ 

KÄYTTÖÖNOTTO PIENESSÄ OHJELMISTOPROJEKTISSA: CASE LIITERI 

 

 

 

 

 

 

         Tietotekniikan 

pro gradu -tutkielma 

 

 

 

 

 

 

VAASA 2014 

 

 



1 

 

 

 

SISÄLLYSLUETTELO         sivu 

 

LYHENNE- JA KÄSITELUETTELO 3 

 

KUVALUETTELO 4 

 

TIIVISTELMÄ 5 

 

ABSTRACT 6 

 

1. JOHDANTO 7 

1.1 Tutkimustavoitteet ja rajaus 8 

1.2 Tutkimusmenetelmät ja tutkielman rakenne 8 

 

2. SISÄLLÖNHALLINTAJÄRJESTELMÄT 9 

2.1 Yleiset ominaisuudet 10 

2.2 Käyttöliittymän tasot 12 

2.2.1 Käyttäjätasot ja -ryhmät 12 

2.2.2 Hallintaliittymä 13 

2.2.3 Julkaisuliittymä 14 

2.3 Laajennettavuus liitännäisillä 15 

2.4 Käyttöönotto ja vaatimukset 16 

2.4.1 Ohjelmisto- ja palvelinvaatimukset 16 

2.4.2 Asentaminen 17 

2.5 Avoimen lähdekoodin lisensointi 18 

 

3. PIENET OHJELMISTOPROJEKTIT 20 

3.1 Eroavuudet muista projekteista 20 

3.2 Sopimuksen muodostaminen 21 

3.3 Pienen ohjelmistoprojektin vaiheet 23 

 

4. CASE LIITERI 27 

4.1 Projektissa käytettävät menetelmät 27 

4.2 Sivuston tarpeet 29 

4.2.1 Toiminnallisuudet 29 



2 

 

 

4.2.2 Ylläpito ja palvelin 31 

4.2.3 Sopimusmäärittely 32 

4.3 Sivuston perustoiminnot ja niiden käyttöönotto 32 

4.3.1 Projektissa käytettyjä työkaluja 33 

4.3.2 Suomenkielisyys 33 

4.3.3 Rakenne 33 

4.3.4 Sivupohja 36 

4.3.5 Ulkoasu ja värimaailma 37 

4.4 Sivuston laajennukset 38 

4.4.1 Tekstieditori ja uutisten lisääminen 38 

4.4.2 Ilmoittautumislomake 40 

4.4.3 Kalenteri 42 

4.4.4 Sosiaalinen media 42 

4.4.5 Kuvagalleria 43 

4.4.6 Videogalleria 43 

4.5 Kävijäseurantaraportit vuonna 2013 44 

4.6 CASEn yhteenveto ja arviointia 46 

 

5.  YHTEENVETO JA KEHITYSEHDOTUKSIA 49 

 

LÄHDELUETTELO 50 

 

LIITTEET 54 

LIITE 1 54 

LIITE 2 65 

 



3 

 

 

LYHENNE- JA KÄSITELUETTELO 

 

 

ACL Access Control Level 

Backend Ylläpitoliittymä, hallintaliittymä 

Breadcrumbs Murupolku 

CAPTCHA Completely Automated Public Turing test to tell Computers and 

Humans Apart 

CMS Content Management System 

DNS Domain Name System 

Frontend Julkinen liittymä, julkaisuliittymä 

FTP File Transfer Protocol 

HTML Hypertext Markup Language 

IP-osoite Internet Protocol address 

Localhost Paikallinen palvelin 

NAT Network Address Translation 

PHP Hypertext Preprocessor 

SQL Structured Query Language 

Template Sivupohja 

XML Extensible Markup Language 

URL Uniform Resource Locator 

WYSIWYG What You See Is What You Get 

WWW World Wide Web 

 

 

 

 

 

 

 

 

 

 

 

 

 



4 

 

 

 

 

KUVALUETTELO                              sivu 

 

Kuva 1. Sivustolle toteutuneen sivupohjan elementit. 34 

Kuva 2. Lopullinen ulkoasu. 37 

Kuva 3. Sisällön muokkausikkunan avaaminen julkaisuliittymässä. 39 

Kuva 4. Tekstieditori JCE julkaisuliittymässä. 39 

Kuva 5. Artikkelin luominen julkaisuliittymästä. 40 

Kuva 6. Ilmoittautumislomake ja CAPTCHA. 41 

Kuva 7. Otos kalenterin käyttöliittymästä. 42 

Kuva 8. Otos kuvagallerian käyttöliittymästä. 43 

Kuva 9. Videogallerian käyttö. 44 



5 

 

 

 

VAASAN YLIOPISTO  

Teknillinen tiedekunta  
Tekijä:    Jukka Kumpusalo  

Tutkielman nimi:  Sisällönhallintajärjestelmän ominaisuudet sekä 

käyttöönotto pienessä ohjelmistoprojektissa: 

CASE Liiteri  

Ohjaajan nimi:   Töyli Jari  

Tutkinto:    Kauppatieteiden maisteri  

Oppiaine:    Tietotekniikka  

Opintojen aloitusvuosi:   2003  

Tutkielman valmistumisvuosi:  2014  Sivumäärä: 53 

 

TIIVISTELMÄ: 

 

Tutkielman tavoitteena oli tuoda esiin yleistä tietoutta sisällönhallintajärjestelmiin ja 

pieniin ohjelmistoprojekteihin liittyen sekä toteuttaa asiakasprojekti tehtyjen 

havaintojen perusteella. Projektin jälkeen sivustoa seurattiin kahden 

kävijäseurantaraportin avulla. Sisällönhallintajärjestelmiä tutkittiin siten, miltä pohjalta 

sisällönhallintajärjestelmät oli luotu ja paneuduttiin sisällönhallintajärjestelmiin 

käyttäen esimerkkinä sisällönhallintajärjestelmää nimeltä Joomla. Tutkielmassa 

tutkittiin myös pieniä ohjelmistoprojekteja ja eritoten sitä millä tavalla pieni 

ohjelmistoprojekti oli hyvä suunnitella ja toteuttaa yhden henkilön tuottaessa 

kokonaisen projektin.  

 

Näiden tutkimustulosten pohjalta toteutettiin ohjelmistoprojekti nimeltä Liiteri, joka oli 

nuorten tieto- ja neuvontapalvelu Laihian ja Isonkyrön kuntien nuorisolle. Liiteri oli 

toteutettu esimerkkinäkin käytetyllä sisällönhallintajärjestelmä Joomlalla.  

 

Casen läpiviennissä tutkittiin miten sisällönhallintajärjestelmällä voitiin toteuttaa 

mahdollisimman laaja helppokäyttöinen sisällön hallinnointi käyttäjälle, jolla ei ollut 

laajaa tietoteknistä taustaa. Projektissa käytiin läpi sivustolle luodut toiminnallisuudet 

sekä tutkittiin, millä tavoin noin puoli vuotta ohjelmistoprojektin käyttöönottamisen 

jälkeen kohderyhmä oli käyttänyt sivuston toiminnallisuuksia sekä sivustoa yleensä 

ottaen. Tutkimisvälineenä käytettiin kahta toteutettua, suuntaa antavaa, 

kävijäseurantaraporttia. 

 

Projekti vietiin onnistuneesti läpi ja tutkitut menetelmät osoittautuivat hyväksi tavaksi 

toteuttaa pieni ohjelmistoprojekti. Kävijäseurantaraportit antoivat viitteitä ainakin siitä, 

että osa Liiterin kohderyhmästä oli löytänyt sivuston ja että toteutettuja 

toiminnallisuuksia oli käytetty laajahkosti. Asiakkaiden kannalta helppokäyttöinen 

sisällön muokkaaminen saatiin otettua huomioon kaikissa muissa paitsi yhdessä 

toiminnallisuudessa. 

 

AVAINSANAT: Sisällönhallintajärjestelmä, Joomla, pienet ohjelmistoprojektit, 

asiakaslähtöinen käyttöliittymä, kävijäseuranta. 



6 

 

 

 

UNIVERSITY OF VAASA  

Faculty of technology  
Author:    Jukka Kumpusalo  

Topic of the Master’s Thesis: Properties and implementation of content 

management systems in a small software 

project: CASE Liiteri 

Instructor:  Jari Töyli 

Degree:  Master of Science in Economics and Business 

Administration  

Major subject:  Computer Science 

Year of Entering the University:  2003  

Year of Completing the Master’s Thesis:  2014     Pages: 53  

 

ABSTRACT:  

 

Goal of this thesis was to bring forward common knowledge regarding content 

management systems and small software projects while implementing a project for 

clients using the research results and analyzing the project afterwards using web 

analytics. Content management systems were researched to find out in what way and 

why such systems were designed and created. Perspective was gathered using examples 

regarding a content management system called Joomla. Small software projects were 

also researched in this thesis and especially from the perspective in what way a small 

software project could be designed and implemented when a single person is producing 

a whole project. 

 

Based on the research results, a small software project called Liiteri was implemented. 

Liiteri is an information and counselling service for the young people of municipalities 

of Laihia and Isokyrö. Liiteri was implemented using the content management system 

Joomla, which was also used as an example in this thesis.  

 

In the follow-through of the CASE, methods of creating a wide and easy to use user 

interface for content management was created for the clients of Liiteri, who didn’t have 

extensive experience regarding information technology. Functionalities which were 

chosen for the site were discussed in the CASE and two suggestive web analytics 

reports which were created after Liiteri was published were analyzed in this thesis. Goal 

of the web analytics was to find out how Liiteri and its functionalities were received 

among the target audience. 

 

Project was successful and researched methods provided a good way of implementing a 

small software project. Web analytics provided references that at least a part of Liiteri’s 

target audience had found the site and the functionalities chosen for Liiteri were used 

broadly. Creating a way of managing content widely and easily for the clients was taken 

into account in all of the functionalities except one. 

 

KEYWORDS: Content Management Systems, Joomla, small software projects, 

customer-oriented user interface, web analytics. 



7 

 

 

1. JOHDANTO  

 

Pro Gradu -tutkielma käy läpi sisällönhallintajärjestelmien yleisten ominaisuuksien ja 

periaatteiden esilletuonnista teoreettisella tasolla. Tutkielmassa toteutetaan pieni 

ohjelmistoprojekti sisällönhallintajärjestelmällä nimeltä Joomla. Tutkielman 

sisällönhallintajärjestelmiä käsittelevässä teoriaosiossa käydään läpi teoriaa päällisin 

puolin ja tuodaan esimerkkejä liittyen Joomlaan. Esiin tuodaan myös sitä miten Joomlan 

käyttöönotto on toteutettu, mitä ominaisuuksia se on pitänyt sisällään ja miten kyseistä 

sisällönhallintajärjestelmää pystyy laajentamaan mahdollisimman asiakaslähtöiseksi 

luomalla mahdollisimman laajan ja helppokäyttöisen sisällön muokattavuuden.  

 

Tutkitun teorian perusteella on tavoitteena rakentaa asiakkaille parhaiten sopiva Internet 

-sivusto. Asiakkaina ovat Laihian ja Isonkyrön kuntien nuorisotoimet, joille toteutetaan 

projektina yhteinen nuorten tieto- ja neuvontapalvelu nimeltä Liiteri. Tavoitteena on 

luoda kohderyhmää eli nuoria palveleva verkkosivusto, jossa on asiakkaiden kannalta 

vaivaton ylläpito sekä helppo sisällön päivittäminen. Tutkielmassa tuodaan esiin sitä, 

millä ratkaisuilla sivusto saadaan mahdollisimman helppokäyttöiseksi asiakkaalle 

ottamalla myös tietoturvalähtökohdat huomioon. 

 

Tutkielman aihetta käsitellään pienen ohjelmistoprojektin näkökulmasta yhden 

työntekijän toteuttaessa projektin jokaisen vaiheen. Tavoitteena on tutkia ovatko esiin 

tuodut metodit projektin läpivientiin liittyen olleet toimivia yhden työntekijän 

ohjelmistoprojektissa. 

 

Projektin valmistumisen jälkeen toteutetaan kaksi suuntaa antavaa 

kävijäseurantaraporttia, joita käytetään apuna sen arvioimisessa miten hyvin nuoret ovat 

vastaanottaneet Liiterin eri toiminnallisuuksineen. Esiin tuodaan myös muutamia 

kehitysehdotuksia jatkoa ajatellen. Tutkielman tekijä on perustanut toiminimen Sivuriihi 

J. Kumpusalo projektin toteuttamista varten. 



8 

 

 

1.1 Tutkimustavoitteet ja rajaus 

 

Tutkimuksen tarkoituksena on tuoda esiin sisällönhallintajärjestelmien yleisimpiä 

ominaisuuksia sekä teoreettisesti että käytännössä ja yhdistää kerätyt havainnot 

toteuttamalla ohjelmistoprojekti havaintoihin nojaten. Tekstissä tutkitaan millä tavoin 

yksi työntekijä voi toteuttaa kokonaisen pienen ohjelmistoprojektin ja mitkä ovat 

projektin eri vaiheissa heränneitä havaintoja. Projektin toteutusvaiheessa tutkitaan 

mahdollisimman laajan ja helppokäyttöisen sisällön muokkausmenetelmän tarjoamista 

projektin asiakkaille. 

 

Tutkimuksessa pyritään hakemaan vastauksia seuraaviin kysymyksiin. 

 

1. Miten CASE on edennyt pienen ohjelmistoprojektin eri vaiheissa ja onko 

teoriaan perustuva toteutusmenetelmä ollut toimiva tutkielman projektin 

toteuttamisen kannalta? 

2. Kuinka sisällönhallintajärjestelmä Joomlalla voidaan toteuttaa Internet-sivusto, 

jossa laaja sisällön muokkaus tehdään mahdollisimman vaivattomaksi henkilölle 

jolla ei ole laajaa tietoteknistä taustaa? 

3. Millä tavalla toteutettava asiakasprojekti on onnistunut toiminnallisuuksiltaan, 

eli palveleeko se kohderyhmää tarpeenmukaisesti ja millä tavalla sivusto on 

otettu vastaan nuorten keskuudessa? 

 

1.2 Tutkimusmenetelmät ja tutkielman rakenne 

 

Tutkimus seuraa osittain kvalitatiivisia ja osittain tapaustutkimuksellisia periaatteita. 

Laadullisen tutkimuksen tavoitteena on teorian kautta löytää menetelmiä, joita on hyvä 

käyttää toteutettavassa pienessä ohjelmistoprojektissa. CASE Liiteri -luku on 

tutkimusluonteeltaan tapaustutkimus, jonka toteuttamisessa käytetään laadullisen 

teoriatutkimuksen kautta hyväksi havaittuja menetelmiä. Kävijäseurantaraportteja 

vertaillaan projektin lopputulokseen, jotta projektin valmistuttua saadaan suuntaa siihen, 

miten Liiteri ja sen toiminnallisuudet on otettu vastaan.  

 

Tutkielma koostuu kahdesta pääosasta jotka rakentuvat viiteen lukuun. Luku kaksi 

keskittyy sisällönhallintajärjestelmiin ja luku kolme pieniin ohjelmistoprojekteihin. 

Luku neljä käsittelee CASE Liiteriä, jonka lopussa käydään läpi yhteenveto CASEsta. 

Luvussa viisi käydään läpi johtopäätökset tutkielmasta sekä jatkosuunnitelmista. 



9 

 

 

2. SISÄLLÖNHALLINTAJÄRJESTELMÄT 

 

Sisällönhallintajärjestelmät on kehitetty isompien ja nopeasti muuttuvien 

verkkosivustojen parempaan hallinnointiin. Luvussa käydään läpi 

sisällönhallintajärjestelmien toimintaperiaatteita sekä sisällönhallintajärjestelmien eri 

käyttäjätasoja, eli tutkitaan sitä miksi yleensä ottaen sisällönhallintajärjestelmien 

käyttöliittymiin on rakennettu käyttäjätasoja. Luvussa käydään myös läpi esimerkein 

sisällönhallintajärjestelmän asennusperiaatteet, jotta jo asennusvaiheessa on tiedossa 

mihin on hyvä kiinnittää huomiota turvallisen verkkosivun rakentamisessa.  

 

Koska tutkielman asiakasprojekti on toteutettu Joomlalla, ovat tässä luvussa käytetyt 

esimerkit enimmäkseen kyseiseen sisällönhallintajärjestelmään liittyviä. Luvussa 

käydään myös läpi kyseiseen sisällönhallintajärjestelmään liittyvän avoimen 

lähdekoodin lisensointi, joka toimii lähtökohtana CASEn toteutuksen 

mahdollistamiseen tässä tutkielmassa esitetyssä muodossa. 

 

Joomla on yli 10 vuotta sitten aloitettu projekti. Nykyinen Joomla perustuu 

sisällönhallintajärjestelmään nimeltä Mambo, josta ensimmäinen versio julkaistiin 

vuonna 2001. Ensimmäinen versio Joomlasta eli Joomla 1.0 julkaistiin vuonna 2005. 

(Joomla 2014a.) 

 

Mambon muutos Joomlaksi eteni osittain OpenSourceMatters-verkkosivuston kautta 

joka oli tulevien Joomlan perustajajäsenien luoma. Joomla-projektin tarkoitus oli 

entisestään painottaa avoimen lähdekoodin mahdollisuuksia, josta kuluttajia tiedotettiin 

OpenSourceMatters-verkkosivuston välityksellä. Tietyn ajan kuluessa Joomla sai 

lopullisen muotonsa ja ensimmäinen versio Joomlasta julkaistiin. Joomla perustuu GNU 

GPL -lisenssiversioon kaksi, joka mahdollistaa sisällönhallintajärjestelmän toiminnan 

avoimen lähdekoodin periaatteilla. (Joomla 2014a.)  

 

Joomlan uusin julkaistu versio vuoden 2013 alussa oli Joomlan versio 3.0, joka oli vielä 

projektin toteuttamisvaiheessa kehittämisasteella. Kyseistä versiota ei vielä vuoden 

2012 toisella neljänneksellä suositeltu tuotantoon, koska suurin osa liitännäisistä ei vielä 

sitä tukenut. Liitännäiset olivat silloin vielä kehitysasteella. Uusimpaan versioon ei 

toisin sanoen vielä löytynyt yhtä laajaa tukiverkostoa kuin edelliseen laajaan julkaisuun, 

eli Joomlan versioon 2.5. 

 



10 

 

 

Joomlan laaja suomalainen tukiverkosto toimii Internet-osoitteessa 

http://www.joomla.fi ja tarjoaa laajaa tukea Joomlan käyttöönottoon esimerkiksi 

erilaisten ohjeiden muodossa. Sivustolta löytyy myös laaja yhteisö, jolta voi tarpeen 

vaatiessa kysyä tuoreinta tietoa mahdollisiin ongelmiin liittyen. Sivustolta löytyvät 

myös suomenkieliset kielipaketit Joomlan eri versioihin sekä moniin Joomlan 

laajennuksiin. (Joomla 2013.) 

 

 

2.1 Yleiset ominaisuudet 

 

Sisällönhallintajärjestelmä koostuu sanoista ”Content Management System”. Usein 

käytetään pelkästään lyhennettä CMS. Tämä tutkielma keskittyy www-

sisällönhallintajärjestelmään, jonka kevyemmästä versiosta kuulee usein käytettävän 

myös yleisnimitystä ”julkaisujärjestelmä” (Tolvanen 2008). Sisällönhallintajärjestelmät 

on kehitetty isompien ja nopeasti muuttuvien verkkosivustojen parempaan 

hallinnointiin. Sisällönhallintajärjestelmien tavoitteena on myös tiedon ja sisällön 

kerääminen sekä julkaiseminen monipuolisilla tavoilla. Sisällönhallintajärjestelmät 

pohjautuvat vahvasti tietokannan käyttöön apuvälineenä sekä perustana verkkosivuston 

luomiselle. (Boiko 2002: 63–65.) 

 

Sisällönhallintajärjestelmien suurimpia vahvuuksia ovat niiden modulaarisuus sekä 

mahdollisuus kehittää valmiita laajennuksia pidemmälle ja enemmän tarkoitukseen 

sopivaksi. Toisin sanoen perusominaisuudet, kuten käyttäjien hallinnointi ja 

tekstieditori, ovat jo jossain määrin valmiiksi integroituna sisällönhallintajärjestelmään. 

Kyseisiä ominaisuuksia ei toisin sanoen tarvitse rakentaa uudestaan. Sivuston 

toteuttaja(t) pystyvät keskittymään enemmän sivuston kehittyneempiin ominaisuuksiin, 

jolloin ohjelmistontuottajien ei tarvitse toteuttaa samoja asioita montaa kertaa. (Stahl et 

al 2013: 3.) 

 

Sisällönhallintajärjestelmien idea perustuu oletukseen, jossa sisällön päivittäminen 

suoraan HTML-koodiin todettiin kankeaksi. Verkkosivustojen alkuaikoina oli tapana 

käyttää sisällön lisäämistä suoraan HTML-koodiin verkkosivuston sisällön 

muokkaamisessa (Eden 2006: 5). HTML on aikoinaan luotu sisällön kuvauskieleksi ja 

liittyy ajankohtaan, jolloin käytettiin enimmäkseen tekstipohjaisia selaimia kuten 

Lynxiä. Silloin sivuston ulkoasulla ei ollut niin suurta merkitystä kuin nykyään. Pelkän 



11 

 

 

HTML:n käyttäminen muodostui lopulta liian kankeaksi, joten ratkaisuksi kehitettiin 

XML. (Eden 2006: 8.) 

 

XML:n lähtökohtana oli mahdollistaa luodun sisällön helppo muokattavuus muihin 

formaatteihin. Näitä olivat esimerkiksi mobiililaitteet, ohjelmistot, selaimet tai 

tulostimet. Kyseinen ominaisuus myös mahdollisti sisällön muokkaamisen ja lisäämisen 

ohjelmistoihin myös käyttäjille, jotka eivät omaa laajaa teknistä osaamista. Lisätty tieto 

siirrettiin suoraan XML-pohjaiseen tietokantaan. (Eden 2006: 8.) 

 

Ennen varsinaista sisällönhallintajärjestelmän luomista lähimmäksi vastaavaa tuotetta 

oli päässyt Macromedian Dreamweaver -sivustojen hallinta- sekä suunnittelutyökaluna. 

Siinä ongelmana oli sivustojen kankeus tapauksissa, joissa tarpeena oli sivuston laaja 

mukautuminen eri tilanteisiin. Toinen Dreamweaverin suurista ongelmista oli suuri riski 

sisällön katoamiseen tai tuhoutumiseen sivuston eri osioissa käyttäjien tekemien 

virheiden vuoksi. Käyttäjien oli myös mahdollista muuttaa tai vääristää sivuston 

ulkoasua virheen tapahtuessa. Tämä johtui käyttöoikeustasojen puutteesta eri tietotaidon 

omaaville käyttäjille. Ratkaisuksi tähän kehitettiin sisällönhallintajärjestelmä eli CMS. 

(Eden 2006: 9–10.) 

 

Sisällönhallintajärjestelmä, joka korjasi edellä mainittuja ongelmia, oli XML-pohjainen 

Luwak-nimeä kantava ohjelmisto. Kyseinen sisällönhallintajärjestelmä oli tehty Java-

ohjelmointikielellä ja perustui Jakarta Struts MVC -kirjastoon. 

Sisällönhallintajärjestelmä käytti MySQL-tietokantaa. Luwakissa käytetty ratkaisu oli 

kokonaisuudessaan avointa lähdekoodia (Eden 2006: 9–10). Luwakissa oli 

sisäänrakennettuna käyttäjätasojen hallintajärjestelmä, jossa eritasoisille käyttäjille 

annettiin erilaiset oikeudet sivuston muokkaamiseen. Luwakissa käyttäjät olivat joko 

kirjoittajia, muokkaajia tai ylläpitäjiä. Kirjoittaja pystyi sekä muokkaamaan että 

lisäämään sisältöä. Muokkaaja pystyi tekemään samat asiat mutta ne vaativat 

hyväksynnän ennen niiden siirtoa sivuston näkyvälle puolelle eli julkaisuliittymään. 

Ylläpitäjillä oli kaikki oikeudet sivuston muokkaamiseen (Eden 2006: 10–11). Näitä 

periaatteita käytetään edelleen laajasti nykyisissä sisällönhallintajärjestelmissä. 

 

 



12 

 

 

2.2 Käyttöliittymän tasot 

 

Käyttöliittymätasot sisällönhallintajärjestelmissä perustuvat täysin sivustolla vierailevan 

käyttäjän tunnistamiseen.  

 

Tämän luvun tarkoituksena on esitellä sisällönhallintajärjestelmien hallinta- sekä 

julkaisuliittymiä lähinnä ominaisuuksien näkökulmasta alkaen siitä, millä perusteella 

käyttäjälle valitaan käyttöoikeudet. Luvussa ei mennä liialti teknisiin yksityiskohtiin 

siitä miten eri käyttäjätasoja käytetään, vaan tuodaan esille perusperiaatteita. 

Käyttäjätasojen esiintuominen on olennaista hallintaliittymän ja julkaisuliittymän 

ominaisuuksien erittelyyn sekä ymmärtämiseen. 

 

2.2.1 Käyttäjätasot ja -ryhmät 

 

Käyttäjälle annettavat oikeudet riippuvat täysin sisällönhallintajärjestelmän käyttäjälle 

myöntämästä käyttäjätasosta ja käyttäjäryhmästä. Tässä luvussa käydään läpi Joomlaan 

sisäänrakennetut käyttäjätasot ja käyttäjäryhmät sekä mitä toimintoja kuhunkin on 

saatavissa. Näitä käyttäjätasoja on mahdollista muokata haluamakseen ja saatavilla on 

myös monipuolisia käyttäjätasolaajennuksia. Käyttäjätasoja nimitetään lyhenteellä ACL 

eli ”Access Control Level”. (Joomla 2014b.) 

 

Esiteltävät käyttäjätasot vaativat tunnistautumisen sivustolle eli kirjautumisen. 

Kirjautuminen sivuston ”Frontendiin” eli julkaisuliittymään tapahtuu aina sivuston 

julkaisuliittymän puolelta, kun taas ”Backendille” eli hallintaliittymälle on oma erillinen 

kirjautumisosionsa. Joomlassa kirjautumiseen käytetään käyttäjätunnusta ja salasanaa, 

jotka ovat sidottuja sähköpostiosoitteeseen. Nämä yhdistetään MySQL -pohjaiseen 

tietokantaan. (Joomla 2014a.) 

 

Jo pelkälle julkaisuliittymälle on olemassa eriasteisia käyttäjätasoja. Toisin sanoen 

julkaisuliittymään kirjautuneiden käyttäjien käyttäjätasoja voidaan muokata tarpeen 

mukaan esimerkiksi sellaisiksi, jossa osa julkaisuliittymän käyttäjistä pystyy 

muokkaamaan sisältöä toisen käyttäjätason pystyessä ainoastaan lukemaan sisältöä. 

Hallintaliittymään voidaan myös luoda useita käyttäjätasoja (Joomla 2014a). Tämä on 

suositeltavaa, koska luvussa 2.1 tutkittujen sisällönhallintajärjestelmien yleisempien 

ominaisuuksien mukaan kokemattomampi käyttäjä voi saada hallintaliittymässä liian 

suurilla oikeuksilla merkittävää haittaa aikaan.  



13 

 

 

 

Käyttäjätaso määrittää sen mitkä käyttäjäryhmät ovat sivua selaavalle vierailijalle 

saatavilla. Käyttäjäryhmillä tehdään varsinainen vierailijan käyttöoikeuksien 

asettaminen, joka määritellään sivustolle tehtävän tunnistautumisen perusteella. 

Käyttäjätasoja on Joomlan oletusasetuksissa kolme, joihin kuhunkin kuuluvat tietyt 

käyttäjäryhmät. Toisin sanoen käyttäjä kuuluu sekä tiettyyn käyttäjätasoon että johonkin 

kyseiseen tasoon kuuluvista käyttäjäryhmistä. Tasot ovat nimeltään ”Public”, 

”Registered”, ja ”Special”. Taulukko 1 kuvastaa olemassa olevia käyttäjätasoja sekä 

mitkä pääkäyttäjäryhmät kuuluvat millekin käyttäjätasolle. (Joomla 2014b; Wakode 

2013: 571.) 

 

Taulukko 1. Käyttäjätasot ja niihin kuuluvat käyttäjäryhmät. 

 

Public Public 

Registered Super Users, Registered, Manager 

Special Super Users, Author, Manager 

 

Ensimmäinen käyttäjätaso on ”Public”, jolla on vähiten oikeuksia – sivustolle 

kirjautumaton käyttäjä on oletuksena kyseisessä käyttäjätasossa sekä käyttäjäryhmässä, 

jolla on ainoastaan lukuoikeus sivustolle. Käyttäjätasolla ”Registered” on 

kirjautumisoikeus julkaisuliittymään ja yleensä suppeat oikeudet sisällön 

muokkaamiseen. ”Special”-käyttäjätasolla on käytössä suuri osa Joomlan tarjoamista 

oikeuksista ja ”Super Users”-käyttäjäryhmällä on täydet oikeudet CMS:n 

muokkaamiseen, koska se kuuluu kaikkiin käyttäjätasoihin. ”Manager” 

pääkäyttäjäryhmällä on oikeus kirjautua hallinta- sekä julkaisuliittymään. 

Käyttäjäryhmästä ”Author” polveutuvilla käyttäjäryhmillä on oikeus muokata 

julkaisuliittymää eriasteisesti. (Joomla 2014b.) 

 

2.2.2 Hallintaliittymä 

 

Sisällönhallintajärjestelmissä käytettävä hallintaliittymä on monipuolinen työkalu, jolla 

on mahdollista muokata sivuston julkaisuliittymä halutunlaiseksi (Wakode 2013: 570). 

Hallintaliittymän ominaisuudet tähtäävät pohjimmiltaan julkaisuliittymän 

muokkaamiseen. Toisin sanoen hallintaliittymä on se paikka, jossa julkisesti näkyvä 

sivusto pääosin muodostetaan.  

 



14 

 

 

Hallintaliittymä on graafinen käyttöliittymä, joka mahdollistaa 

sisällönhallintajärjestelmien asetusten suunnittelun ja toteuttamisen tarpeenmukaisiksi. 

Hallintaliittymässä määritellään esimerkiksi käyttäjätasot ”Super Userin” eli ylläpitäjän 

toimesta, kuin myös asennetaan sivupohjat, liitännäiset, moduulit, kielipaketit sekä 

muut laajennukset. Näitä voidaan muokata hyvin pitkälle hallintaliittymän puolella. 

Toiminnallisuuksia, joita sisällönhallintajärjestelmä ei anna suoraan muokattavaksi 

voidaan aina muokata suoraan ohjelmistokoodista. (Joomla 2014a; Wakode 2013: 569–

571.)  

 

Joomlassa ohjelmistokoodiin pääsy hallintaliittymässä koskee lähinnä valittua tai luotua 

sivupohjaa. Henkilö joka on luonut valitun sivupohjan, valitsee sivupohjaa luodessa ne 

tiedostot jotka tulevat muokattaviksi suoraan Joomlan hallintaliittymästä. Useimmissa 

moduuleissa on myös mahdollisuus tehdä ohjelmistokoodiin liittyviä ylikirjoittavia 

muutoksia suoraan moduuliin tai liitännäisiin liittyvillä ylikirjoitustoiminnoilla. Nämä 

ylikirjoitukset voi asettaa myös suoraan sivupohjaan (Rahmel 2013: 97–98), mutta 

yleensä on monipuolisempaa muokata ohjelmistokoodia suoraan palvelimelle tuoduista 

liitännäisiin ja moduuleihin liittyvistä tiedostoista. Toisaalta tällä menetelmällä 

liitännäisten päivitettävyys kangistuu. 

 

2.2.3 Julkaisuliittymä 

 

Julkaisuliittymä pohjautuu täysin siihen millaiseksi sivusto halutaan luoda 

hallintaliittymästä käsin. Julkaisuliittymään on mahdollista luoda käyttäjätasoja, joihin 

kuuluvat käyttäjät pystyvät laajasti muokkaamaan sivuston sisältöä (esimerkiksi tekstiä, 

kuvia, videoita, uutispalstoja) ilman että vaarana on sivuston rakenteiden muuttuminen 

(Joomla 2014a). Sisältöä voi muokata myös hallintaliittymästä ja sisällön 

muokkaaminen on siellä haastavuuden lisäksi myös monipuolisempaa.  

 

Sivustoa selaava käyttäjä voi olla joko sivustolla oleva vierailija tai tunnistautumisen 

suoritettuaan sivustolle kirjautunut käyttäjä. (Joomla 2014b.)  

 

Julkaisuliittymään luotuja käyttäjätasoja voi olla useita. Kaikilla julkaisuliittymän 

käyttäjätasoilla ei ole pääsyä sivuston hallintapaneeliin, mutta niille voidaan lisätä laajat 

toisistaan eroavat oikeudet julkaisuliittymän muokkaamiseen (Joomla 2014b; Wakode 

2013: 569–571). Myös tietyillä Joomlan laajennuksilla (esimerkiksi K2) voidaan 

laajentaa julkaisuliittymän käyttäjätasoja, jolloin eri käyttäjätasoille on mahdollista 



15 

 

 

luoda omat alueensa kirjautuneille käyttäjille. Tämä antaa mahdollisuuden Intra- ja/tai 

Extranet -ominaisuuden tuomiseksi Joomlaan, jolloin eri julkaisuliittymän käyttäjätasot 

näkevät eri osiot kirjauduttuaan sivustolle (Joomla 2014c). 

 

 

2.3 Laajennettavuus liitännäisillä 

 

Liitännäisillä ja moduuleilla eli laajennuksilla on mahdollista luoda 

sisällönhallintajärjestelmiin monipuolisempia sisällönkäsittelymenetelmiä. Esimerkiksi 

Joomlalle on olemassa noin 4500 valmiiksi tehtyä laajennusta (Wakode 2013: 569). 

Avoimen lähdekoodin sovelluksissa kuka tahansa ohjelmointitaitoinen voi tehdä omia 

laajennuksiaan sekä kehittää olemassa olevia laajennuksia. Asennettaessa useita 

laajennuksia sisällönhallintajärjestelmään, on olemassa suurempi todennäköisyys 

aiheuttaa ristiriitoja laajennusten välille. Nämä ristiriidat voivat aiheuttaa suuria 

toimintaongelmia järjestelmään (Jones et. al 2011: 16). Hankalia tilanteita tulee 

tapauksissa, jolloin asennettu laajennus vaurioittaa sivustoa tai saattaa sivuston 

toimintakyvyttömäksi. Näissä tapauksissa on hyvä harkita hakeeko ratkaisua 

tilanteeseen korjaamalla ongelman, vai onko hyvä käyttää toista laajennusta, joka 

saattaisi toimia paremmin ilman suurempia muutoksia. 

 

On olemassa monia erityyppisiä laajennuksia. Niitä käytetään muun muassa sivuston 

hallintaominaisuuksien sekä sivuston käyttökokemuksen parantamiseen. 

Julkaisuliittymään tuotavia käyttökokemusta parantavia laajennuksia voivat olla 

esimerkiksi tapahtumakalenteri, video- ja kuvagalleriat, ilmoittautumislomakkeet, 

laajennetut sisällön muokkaustyökalut, liittäminen sosiaaliseen mediaan sekä erilaiset 

graafista ulkoasua parantavat laajennukset (Wakode 2013: 569–570). 

Hallintaominaisuuksia voidaan parantaa tuomalla esimerkiksi tietoturvaa tai 

käyttäjätasojen monimuotoisuutta parantavia liitännäisiä hallintaliittymään (Joomla 

2014c). Laajennusten kehittäjillä on yleensä omat verkkosivustonsa, joista on 

mahdollista saada tukea suoraan eri sisällönhallintajärjestelmien eri laajennuksiin 

liittyen.  

 

 



16 

 

 

2.4 Käyttöönotto ja vaatimukset 

 

Sisällönhallintajärjestelmän käyttöönotto on monivaiheinen prosessi, jossa täytyy 

huomioida ensin ohjelmisto- sekä palvelinvaatimuksien täyttyminen www-palvelimella. 

http://www.joomla.org-sivustolta on haettavissa asennuspaketteja eri Joomlan 

versioihin. Paketit asennetaan palvelimelle luomalla tietokantayhteys luodun 

tietokannan sekä asennettavan Joomlan version välille. Seuraavissa luvuissa kuvaillaan 

tätä prosessia sekä tarkennetaan ohjelmisto- ja palvelinvaatimuksia. 

Asennusmenetelmän tarkastelun tavoitteena on ottaa tietyt asiat huomioon jo 

asennusvaiheessa, jotta asennusta voidaan lähteä toteuttamaan tietoturvallisesti. 

 

2.4.1 Ohjelmisto- ja palvelinvaatimukset 

 

Joomlan käyttöönotto vaatii palvelimelta tiettyjä ominaisuuksia joita ilman käyttöönotto 

ei onnistu. Palvelimen käyttöjärjestelmäksi käyvät sekä Linux- että Windows-pohjaiset 

alustat. Pakollisia käytettäviä ohjelmia palvelimella ovat PHP, jokin SQL:ää käyttävä 

ohjelmisto kuten esimerkiksi MySQL sekä palvelinohjelmisto kuten esimerkiksi 

Apache. Joomla 2.5 version käyttöönottoon on olemassa suositeltu versiokartta eri 

palvelinohjelmistoista.  

 

Taulukko 2. Joomla 2.5 palvelinvaatimukset (Joomla 2014d). 

 

Ohjelmisto Suositeltu versio Minimiversio Lisää informaatiota 

PHP 5.4 + 5.2.4 + http://www.php.net  

MySQL 5.0.4 + 5.0.4 + http://www.mysql.com  

Tuetut verkkopalvelimet 

Apache 

(joku seuraavista: 

mod_mysql,mod_xml, 

mod_zlib) 

2.x + 2.x + http://www.apache.org  

Nginx 1.1 1.0 http://wiki.nginx.org/  

Microsoft IIS 7 7 http://www.iis.net 

 

http://www.php.net/
http://www.mysql.com/
http://www.apache.org/
http://wiki.nginx.org/
http://www.iis.net/


17 

 

 

Uudemmat Joomlan versiot ovat yhteensopivia käyttämään myös SQL-ohjelmistoja 

MSSQL sekä PostgreSQL (Joomla 2014d). Monipuolisesta SQL-ohjelmistotarjonnasta 

huomaa Joomla-projektin kehittyvän monipuolisempaan suuntaan myös 

palvelinmahdollisuuksissa. 

 

On olemassa myös ratkaisuja, joissa palvelimelle ei ole tarpeen asentaa ja konfiguroida 

kaikkia edellä mainittuja ohjelmistoja erikseen siinä laajuudessa mitä kyseisten 

ohjelmistojen erillinen asentaminen vaatii. Vaihtoehtoisia nopeita ratkaisuja, joita 

suositellaan käytettävän enimmäkseen väliaikaisilla palvelimilla (muilla kuin 

tuotantopalvelimilla) ovat muun muassa Xampp (monialustainen), Wamp (Windows), 

Lamp (Linux) sekä Mamp (Macintosh) (Joomla 2014d). Vaihtoehtoisia palveluja on 

paljon ja useimmat niistä ovat perusominaisuuksiltaan riittäviä paikallisen CMS-

pohjaisen verkkosivuston rakentamiseen. Lopullisella palvelimella on hyvä olla edellä 

olevassa kaaviossa mainitut ohjelmistot erikseen asennettuina sekä konfiguroituina.  

 

2.4.2 Asentaminen 

 

Tämän asennuskatsastuksen tarkoitus ei ole mennä liialti asennusprosessin 

yksityiskohtiin, vaan tuoda esiin asennusprosessin kannalta merkittävimmät asiat ja 

niihin liittyviä huomioita. 

 

Joomlan asennuspaketti puretaan www-palvelimen juurihakemistoon. Paikallisella 

palvelimella Joomlan asennustoiminto löytyy kirjoittamalla selaimeen http://localhost. 

Jos asennus tehdään suoraan www-palvelimelle, löytyy Joomlan asennusohjelma 

kirjoittamalla selaimeen palvelimen www-osoite eli URL (Joomla 2014e). 

Käytännöllistä onkin aloittaa sivuston rakentaminen paikallisella palvelimella ennen 

sivuston käyttöönottoa tuotantopalvelimella. 

 

Seuraavaksi valmistellaan tietokantayhteys Joomlan ja tietokannan välille. Joomlan 2.5 

version ollessa kyseessä käytetään MySQL-tietokantasovellusta esimerkiksi 

PhpMyAdminia. Tietokantasovellukseen luodaan tietokantakäyttäjä sekä tyhjä 

tietokanta johon luodulla käyttäjällä on vaadittavat oikeudet. Tietokantakäyttäjälle 

määritetään salasana, jonka on syytä olla riittävän vahva (Joomla 2014e). Hyväksi 

havaittu tapa on käyttää salasanageneraattoria joka luo halutun bittisyyden salasanan 

vahvuudeksi. Tässä tapauksessa on hyvä käyttää salasanapankkia. Salasanapankki on 

sovellus, joka mahdollistaa monipuolisten salasanojen käytön laajasti eikä käyttäjän 



18 

 

 

tarvitse tietää kaikkia salasanojaan. Tietoturvan kannalta tämä poistaa merkittävästi 

suurinta tietoturvariskiä joka on käyttäjä itse.  

 

Asennusvaiheiden jälkeen Joomlan asennustoiminto pyytää poistamaan asennuksessa 

apuna käytetyt tiedostot, joiden poistamatta jättäminen mahdollistaisi Joomlan 

uudelleenasentamisen kyseisistä tiedostoista.  Tässä tapauksessa kaikki asennusvaiheen 

jälkeen tehdyt muutokset häviäisivät ja Joomla olisi uudestaan perustilassa. Tämä on 

suuri tietoturvariski. Tästä johtuen käytetyt asennustiedostot poistetaan ennen kuin 

siirrytään varsinaiseen sivuston luontiin. (Joomla 2014e.) 

 

Asennuksessa määritettyjä tietoja on jälkikäteen mahdollista muuttaa hallintaliittymän 

globaalit asetukset -osiosta tai suoraan Joomlan juurikansiossa olevasta 

configuration.php -tiedostosta. (Joomla 2014a.) 

 

Joomlan asentamisen jälkeen voidaan keskittyä varsinaiseen ohjelmistoprojektiin. Syy 

asennuksen läpikäymiseen liittyy tutkielman tietoturvanäkökulmaan. Jos Joomla on 

asennettu heikoilla salasanoilla ja perusasioita ei ole asennusvaiheessa otettu huomioon, 

on sisällönhallintajärjestelmäasennus heikolla pohjalla valmiin verkkosivuston 

tietoturvaa ajatellen. On suositeltavaa, että tietokanta sekä pääkäyttäjätunnukset on 

suojattu vahvoilla salasanoilla. 

 

 

2.5 Avoimen lähdekoodin lisensointi 

 

Useimmat avoimen lähdekoodin sisällönhallintajärjestelmät perustuvat GNU GPL- tai 

MIT-lisensseihin. Joomla perustuu GNU GPL -lisenssin versionumeroon kaksi. GNU 

GPL -lisenssin perustuu idealle, jossa kuka tahansa saa oikeuden käyttää, kopioida, 

muuttaa ja jakaa lisenssiin pohjautuvia ohjelmia sekä niiden lähdekoodia. Jokaisen tällä 

lisenssillä toteutetun tuotoksen täytyy sisältää julkaisuissaan viittaus lisenssin käyttöön, 

oli tuotos alkuperäinen, kopioitu tai muokattu versio lisenssiä käyttäneestä 

ohjelmistokoodista. Tämä tarkoittaa sitä että valmista ohjelmistokoodia saa vapaasti 

muokata, kunhan ohjelmistokoodia levitetään eteenpäin samalla periaatteella. 

(OpenSourceMatters 2013; Free Software Foundation 2013.) 

 

Parhaimmillaan lisenssi mahdollistaa kehittyneemmän ohjelmistoprojektin 

toteuttamisen, jossa yhteisö toimii ohjelmistokehittäjän roolissa. Seurauksena voi olla 



19 

 

 

että alkuperäistä ohjelmistokoodia muokannut yhteisön jäsen kehittää tuotteen sille 

asteelle, että siitä hyvin pienellä vaivalla saadaan uusi versio alkuperäisestä 

ohjelmistosta (OpenSourceMatters 2013; Free Software Foundation 2013). Tämä 

mahdollistaa levitettävien perusohjelmistojen kehittämisen yhteisön tuella, jolloin 

uusien ohjelmoijien ei tarvitse kehittää omia perustuotteitaan lähtemällä ohjelmoinnissa 

liikkeelle alusta alkaen. 

 



20 

 

 

3. PIENET OHJELMISTOPROJEKTIT 

 

Puhuttaessa ohjelmistoprojekteista herää usein kysymys siitä, miten ohjelmistoprojekti 

eroaa muun tyyppisistä projekteista. Tässä luvussa tuodaan esille projektinhallintaa 

pienessä ohjelmistoprojektissa, joka on verrattavissa pienyritykseen silloin kun pieni 

ohjelmistotiimi toteuttaa yhden ohjelmistoprojektin. Tämän tutkielman projektin toteutti 

yksi työntekijä alkaen projektinviennistä päättyen projektin tekniseen läpivientiin. 

 

 

3.1 Eroavuudet muista projekteista 

 

Projektinhallinta ohjelmistoprojekteissa eroaa muista projektityypeistä muun muassa 

tässä luvussa esitellyillä tavoilla.  

 

Ohjelmistoprojektit ovat niin sanotusti läpinäkyviä, eli asiakkaalle tai 

ohjelmistoprojektin kohderyhmälle jää usein arvoitukseksi ohjelmistoprojektin toteutus 

ellei sitä tuoda asiakkaalle sopivalla informaatiolla esiin. Projektissa jossa esimerkiksi 

rakennetaan tie, on koko projektin toteutus nähtävissä projektin alusta loppuun eli se on 

konkreettisemmin hahmotettavissa (Hughes & Cotterell 2006: 4). Toisin sanoen asiakas 

on hyvä pitää selvillä projektin eri vaiheista, mutta mielellään sellaisella informaation 

tasolla joka ei mene liialti teknisiin yksityiskohtiin. Asiakkaalle on hyvä tuoda esiin 

ohjelmistoprojektin olennaisimmat piirteet.  

 

Ohjelmistoprojektit ovat monimuotoisia ja useissa tapauksissa saatu vastine rahalle on 

pienempi kuin monissa muissa tekniikan alan tuotteissa  (Hughes et al. 2006: 4). Saadun 

vastineen määrä johtuu ohjelmistoprojektien monimuotoisuudesta, ja voidaan olettaa 

että jokaiseen vaiheeseen käytetään aikaa enemmän kuin monessa muussa tekniikan 

alan projektissa.  

 

Ohjelmistoprojektien jatkuvuudella tarkoitetaan ohjelmistokehittäjien sopeutumista 

asiakkaiden tarpeisiin. Tilanne on hieman erilainen projektissa jonka onnistumista 

säätelevät fysiikan lait. Esimerkiksi insinöörin suunnitellessa kohdetta sementistä tai 

teräksestä täytyy ohjelmistonkehittäjän vastaavasti käsitellä asiakkaita, joihin eivät päde 

fysiikan lait. Kyse ei myöskään ole pelkän asiakasyksilön mahdollisesta 

ristiriitaisuudesta, vaan usein saattaa olla että ohjelmistoprojektissa kohdataan niin 

sanottua ”organisaationaalista hölmöyttä” johtuen mahdollisista ongelmista esimerkiksi 



21 

 

 

organisaatioiden sisäisessä kommunikaatiossa tai tehokkaassa päätöksenteossa. 

Ohjelmistokehittäjien täytyy valmistautua palvelemaan asiakasta muuttuvissa 

ongelmatilanteissa. (Hughes et al. 2006: 4.) 

 

Ohjelmistoprojektin joustavuudella tarkoitetaan ohjelmistojen mukautuvuutta eri 

tilanteisiin ja tarpeisiin sopivaksi. Joustavuus on ohjelmistojen vahvuus. Usein oletetaan 

että ohjelmistot ovat kykeneviä muuntautumaan sopiviksi muita ohjelmistoja varten, sen 

sijaan että muut ohjelmistot mukautuisivat kyseistä ohjelmistoa varten. Ohjelmistojen 

joustavuus mahdollistaa korkean muuttuvuuden asteen ohjelmistojen välillä. (Hughes et 

al. 2006: 4.) 

  

 

3.2 Sopimuksen muodostaminen 

 

Pienet ohjelmistoprojektit voidaan usein mieltää projekteiksi, joissa yksi työntekijä 

toteuttaa kokonaisen projektin asiakkaalle. On olemassa tiettyjä asioita, jotka on hyvä 

ottaa huomioon yhden työntekijän projekteissa. Esiin tuotavia metodeja käytetään 

osittain pohjana CASE Liiterissä. 

 

Ohjelmistoprojektit pienyrityksissä käynnistetään usein huomioimatta suuremmin 

muotoseikkoja. Projektin käynnistämiseen kuuluvat muun muassa tilaustiedot, 

sopimuksen luominen tai ehdotus jonka projektin asiakas on hyväksynyt. Olennaista 

projektin käynnistämisessä kuin myös jatkotoimenpiteissä on toimintojen 

samankaltaisuus organisaation sisällä. (Phillips 2011: 37–38.) 

 

Projektiasiakkaan ollessa ulkoinen käytetään seuraavia metodeja sopimuksen 

muodostamiseen: 

 

1. Tarjouspyyntö. 

2. Tarjous johon sisältyvät ohjelmistoarvio, toimittamiseen sitoutuminen, projektin 

hinnoittelu sekä kokonaistarjouksen valmistelu. 

3. Neuvottelu. 

4. Sopimuksen hyväksyminen. (Murali 2010: 31–32.) 

 

Ohjelmistoarvioon kuuluu tarjouksen hinnan arvio. Todellinen arvio tarkentuu 

myöhemmin. Hinnoitteluun voidaan käyttää monia metodeja, jotka liittyvät muun 



22 

 

 

muassa siihen millainen kilpailuasetelma projektiin liittyy. Hinnoittelun jälkeen tehdään 

kokonaistarjous kahdessa osassa, johon yleisimmin kuuluvat ohjelmiston tekninen 

määrittely sekä projektin tarkka hinnoittelu. Neuvottelussa asiakas tekee päätöksen 

tarjouksen hyväksymisestä. Usein tässä vaiheessa kokonaistarjous muodostuu vielä 

tarkemmaksi asiakkaan pyytäessä tarkentamaan tarjousta liittyen joko hintaan tai 

tekniseen määrittelyyn.  

 

Neuvotteluvaiheen jälkeen viimeisin kokonaistarjouksen versio hyväksytään ja 

tarkistetaan, että kaikki tiedot sekä asiakkaalla että projektin toteuttajalla vastaavat 

toisiaan. Tämän jälkeen muodostetaan sopimus ohjelmistoprojektille. Sopimuksessa 

mainittavat asiat ovat niitä, jotka määrittelevät ohjelmistoprojektin tarpeet ja hinnan. 

Kyseisiä sopimusmäärittelyjä käytetään tarpeen vaatiessa erimielisyyksien ratkomiseen 

(Murali 2010: 32–43). Projektin sekä projektiin liittyvien vastuuhenkilöiden kannalta on 

olennaista, että sopimus on tarkasti muodostettu koko projektin elinkaarelle. 

 

Projektin käynnistäminen ja siihen käytetyt metodit ovat olennaisessa asemassa koko 

projektin onnistumisen kannalta. Pienemmissä organisaatioissa henkilö joka vastaa 

toimituksesta on vastuussa projektista (Murali 2010: 49–50). Projektipäällikön tehtäviin 

kuuluvat muun muassa seuraavat asiat pienen ohjelmistoprojektin 

käynnistämisvaiheessa:  

 

1. Käy läpi projektin eri määritykset sekä varmistaa niiden oikeellisuuden. 

2. Käy läpi projektista tehdyt arviot sekä tarkistaa niiden vastaavan asiakkaan 

tilausta. 

3. Tekee arvioinnin ohjelmistosta eri näkökulmista ellei ole tehnyt sitä 

aikaisemmin: millainen ohjelmistoprojektin aikataulutus on, millainen 

ohjelmisto on laajuudeltaan sekä mitä siihen käytettävä työaika kustannuksineen 

vaatii. 

4. Käy läpi mitä resursseja projektiin vaaditaan: millaiset henkilöstö-, laitteisto-, 

ohjelmistoresurssit ja tilat projekti vaatii sekä mitä käytettävä tietoympäristö 

tietoturvineen vaatii. (Murali 2010: 50–51.) 

 

 



23 

 

 

3.3 Pienen ohjelmistoprojektin vaiheet 

 

Projektin aikatauluttaminen täytyy aloittaa jo ohjelmistoprojektin alkuvaiheessa. 

Asiakas haluaa tietää arvion projektin kestosta sekä eri välivaiheista. Projektin 

suunnittelussa on hyvä arvioida mahdolliset projektin eri vaiheiden riskitekijät sekä 

ottaa ne huomioon aikatauluttamisessa (Phillips 2011: 123–124). On olemassa niin 

kutsuttu rautakolmiomalli, jonka eri kärkiin kuuluvat aikataulu, kulut sekä laajuus. 

Näiden kolmen on oltava tasapainossa, jotta projektista tulee onnistunut (Phillips 2011: 

125). 

 

Yksi ongelmista on työntekijälle ennalta tuntemattomien työkalujen käyttäminen. Usein 

uusissa projekteissa saatetaan käyttää työkaluja, joiden toiminta on teoreettisesti 

tiedossa – työntekijä tietää mitä työkalulla voi saada aikaan, mutta ei ole käytännössä 

vielä niitä vielä käyttänyt. Tämä on otettava huomioon tehtäessä aikatauluja projektia 

varten, jonka arvioiminen voi olla hankalaa. On myös mahdollista, että ennalta 

näkemättömät tekniset ongelmat pysäyttävät hetkellisesti ohjelmistoprojektin. Tätä 

riskiä on mahdollista välttää käyttämällä tuttuja ohjelmistotyökaluja. (Hughes et al. 

2006: 283–284.) 

 

Toinen merkittävä ongelma yhden työntekijän projekteissa on ennakkoon vaadittava 

perehtymisen määrä, jotta työntekijä pystyy määrittelemään tarkoin sen mitä 

ohjelmistoprojektiin kuuluu. Usein voi olla jopa tarpeen rakentaa osa ohjelmistosta 

valmiiksi ennen kuin on mahdollista tarkasti määrittää koko ohjelmistoprojektin 

aikataulu. Käytettävissä oleva aika määrittelee tarkoin sen miten projektin aikataulu 

kannattaa suunnitella. Seuraava listaus kertoo suhdeluvuista, jotka kuvastavat projektin 

aikataulutusta eri vaiheissa pienessä ohjelmistoprojektissa:  

 

- Ohjelmistoprojektin analysointiin 20%, 

- suunnitteluun 10%, 

- järjestelmän toteuttamiseen 40%, 

- testaamiseen sekä arviointiin 20% ja 

- satunnaisiin tapahtumiin 10%. (Hughes et al. 2006: 284.) 

 

Painotukset voivat vaihdella riippuen projektista, mutta yllä olevat suhteet ajankäyttöön 

liittyen toimivat hyvänä lähtökohtana ajankäytölle pienessä ohjelmistoprojektissa. 

Alustavaan analysointiin kannattaa käyttää huomattava määrä koko projektin ajasta, 



24 

 

 

sillä mitä enemmän siihen käyttää aikaa sitä tarkemmin pystyy määrittelemään projektin 

kokonaisaikataulua sekä suunnittelemaan eri välivaiheisiin liittyvää ajankäyttöä. Myös 

kunkin vaiheen erillistä suunnittelua kannattaa viivyttää siinä määrin, että saa enemmän 

informaatiota esille koko projektiin liittyen. On siis hyvä varata joustavuutta aikataulun 

suunnittelulle. (Hughes et al. 2006: 284.) 

 

Kolmas yleinen ongelma on ajan riittämättömyys työntekijän kaikista toimista 

huolimatta. Toisin sanoen aika ei riitä välivaiheiden toteuttamiseen suunnitellulla 

tavalla. On siis hyvä rakentaa ohjelmistosta jo alkuvaiheessa toiminnallisuuksiltaan 

rajoitettu prototyyppi, jota voi esitellä asiakkaalle siltä varalta, jos myöhemmissä 

vaiheissa joidenkin ominaisuuksien toteuttaminen viivästyy. Näissä tilanteissa on 

mahdollista esitellä suunnitelmaa tai rautalankamallia tulevista ominaisuuksista. On siis 

hyvä olla valmiina tietyt ominaisuudet omaava versio ohjelmistosta jo aikaisessa 

vaiheessa, jotta jokaisessa projektin vaiheessa on jotain esiteltävää asiakkaalle. 

Seuraava lista kuvastaa yhtä vaihtoehtoa, miten ominaisuuksia voi toteuttaa jo projektin 

aikaisissa vaiheissa, mutta kuitenkin siten että koko projekti valmistuu suunnitellussa 

projektiaikataulussa. Mallissa on myös dokumentoinnille sekä satunnaisesti tapahtuville 

asioille varattu hyvin aikaa. Esimerkkinä on 10 viikkoa kestävä pieni 

ohjelmistoprojekti.  

 

- Viikot 1-2 käytetään ohjelmistoprojektin analysointiin, 

- viikko 3 ensimmäisen ohjelmistoversion suunnittelu, 

- viikko 4 ensimmäisen ohjelmistoversion toteutus ja testaus, 

- viikko 5 toisen ohjelmistoversion suunnittelu, 

- viikko 6 toisen ohjelmistoversion toteutus ja testaus, 

- viikko 7 kolmannen ohjelmistoversion suunnittelu, 

- viikko 8 kolmannen ohjelmistoversion toteutus ja testaus, 

- viikko 9 koko järjestelmän arviointi ja 

- viikko 10 dokumentointi sekä satunnaisuudet. (Hughes et al. 2006: 285.) 

 

Kyseistä menetelmää voi verrata ketterään ohjelmistokehitykseen. Niin kutsutussa 

”Agile”-menetelmässä eli ketterässä kehittämisessä ohjelmistosta rakennetaan ensin 

yksi toimiva versio, joita tehdään useampia kunnes ohjelmisto on kokonaan valmis. 

Ketterässä kehittämisessä edetään yleiset ohjelmistoprojektin vaiheet läpi yksi 

kerrallaan alkaen suunnittelusta ja toteuttamisesta päättyen testaukseen ja version 



25 

 

 

hyväksyttämiseen. Suurimpia etuja ketterässä kehittämisessä ovat kokonaisriskin 

minimointi sekä nopea muutoksiin mukautuminen. (Rashmi 2013: 153–154.) 

 

Yleisenä ohjeena dokumentoinnissa on sen toteuttaminen ohjelmistoprojektin edetessä. 

Tällä tavoin voidaan välttää tilannetta, jossa ohjelmistoprojekti on lähes valmistunut, 

mutta dokumentointi on merkittävästi jäljessä. Vaikka yllä olevassa esimerkissä 

dokumentointi on varattu viikolle kymmenen, voidaan dokumentointi integroida osaksi 

suunnittelu-, toteutus- ja testausprosesseja. Ohjesääntöä on hyvä noudattaa myös siksi, 

että toteutetut asiat ovat projektin edetessä vielä työntekijällä tuoreessa muistissa. 

Dokumentoinnista tulee tällöin todennäköisesti laajempi sekä laadukkaampi 

kokonaisuus kuin jättäessä dokumentoinnin projektin loppuvaiheeseen. (Hughes et al. 

2006: 285.) 

 

Neljäs yleinen ongelma liittyy asiakkaisiin sekä asiakkaiden mahdolliseen heikkoon 

sitoutumiseen ohjelmistoprojektiin liittyen. Tämä liittyy projektin arvoon eli kuinka 

paljon projektissa on asiakkaan kannalta käytetty rahaa vai onko rahaa käytetty 

ollenkaan. Etenkin projektin ollessa ilmainen, voi sitoutuminen projektiin olla asiakkaan 

kannalta merkittävästi alhaisempi. Tilanne voi olla toinen, jos projektiin sisältyy 

enemmän rahallista riskiä – silloin asiakas vaatii ohjelmistoprojektilta enemmän 

saadakseen rahalleen vastinetta. (Hughes et al. 2006: 285.) 

 

On myös suositeltavaa, että jokaisessa pienessä ohjelmistoprojektissa työn toteuttaja 

tapaa asiakkaan puolelta kaikki projektiin läheisesti liittyvät työntekijät ennen kuin 

varsinainen ohjelmistoprojekti käynnistetään. Asiakkaille toimitetaan myös 

projektisuunnitelma liittyen ohjelmistoprojektiin, johon liittyen on hyvä pyytää 

asiakkaan kommentteja hyvissä ajoin. Ohjelmistoprojektin alkuvaiheessa on hyvä sopia 

tapaamisaikataulusta projektin aikana, jolloin asiakas pysyy hyvin selvillä siitä, missä 

vaiheessa ohjelmistoprojekti etenee. (Hughes et al. 2006: 285–286.) 

 

Ohjelmistoprojekteissa puhutaan usein niin kutsutusta Parkinsonin laista, jossa työ 

laajenee sille määrättyyn aikatauluun. Esimerkki Parkinsonin laista voi olla työ, jonka 

kesto on todennäköisesti 44 tuntia, mutta sille on varattu aikaa 55 tuntia. Todellinen 

kestoaika tulee olemaan lähempänä 55 tuntia, vaikkei jäljellä olevaa kymmentä tuntia 

olisi välttämättä tarvittukaan. On olemassa kolme tapaa, joilla voidaan estää 

Parkinsonin lain perinteisesti ajateltua haittavaikutusta. (Phillips 2011: 128–129.) 

 



26 

 

 

1. Historialliseen tietoon perustuen on olennaista oppia aikaisemmista projekteista. 

Tulevien projektien ajankäytön on hyvä perustua vanhoihin projekteihin ja 

niiden eri vaiheiden ajankäyttöön (Phillips 2011: 129). 

2. Hallinto voi rohkaista työntekijöitä tekemään tarkempia arvioita työn kestosta. 

Jokaisen projektin lopussa voi lisätä 10–15 prosenttia käytettyyn aikatauluun 

riskitekijöille. Tätä kautta aikataulutus tarkentuu entisestään (Phillips 2011: 

129). Yhden työntekijän projekteissa tämän toteuttaminen jätetään työntekijän 

oman arvion varaan. 

3. Kolmikohtainen arvio perustuu sille olettamukselle että projektia tarkastellaan 

kolmen eri periaatteen perusteella, joita ovat optimistiset, todennäköiset sekä 

pessimistiset lähtökohdat. Tätä menetelmää voi käyttää myös kulujen 

arvioinnissa (Phillips 2011: 129). 

 

Tässä luvussa mainittuja menetelmiä on hyvä käyttää toiminnan perustana pienissä 

ohjelmistoprojekteissa. Asiakasprojekti Liiteri toteutettiin käyttäen edellä mainittuja 

toimintamenetelmiä. 

 



27 

 

 

 

4. CASE Liiteri 

 

Asiakkaita Pro Gradu tutkielman projektille olivat Laihian ja Isonkyrön kuntien 

nuorisotoimet. Tavoitteena oli saada uusi nuorten tieto- ja neuvontapalvelu toteutettua 

nuorisotoimien käyttöön. Asiakkaat valitsivat valmiin projektin nimeksi Liiterin. 

 

Tässä luvussa käsitellään projektin eri vaiheita aloittamalla projektin toteutuksessa 

käytettävistä menetelmistä ja periaatteista. Luvussa edetään sen jälkeen varsinaisen 

projektin läpikäyntiin. Projekti aloitettiin määrittelemällä sivuston tarpeet, joiden 

perusteella sopimus muodostettiin. Tämän jälkeen varsinainen sivuston kehitys saatiin 

käynnistettyä. Sivuston kehitystä käsiteltiin osittain teknisestä näkökulmasta ja tuotiin 

esiin mahdolliset välivaiheet projektin etenemisestä. Seuraavaksi esiteltiin lopulliset 

versiot toteutuneista toiminnallisuuksista ja niissä käyttöönotetuista käyttöliittymistä 

loppukäyttäjälle. Luvussa käydään läpi kuinka laajaksi laajennusten muokkaaminen 

saatiin toteutettua julkaisuliittymän puolelle eri toiminnallisuuksiin liittyen. Sivuston 

kehityksestä tuodaan esiin myös mahdollisia teknisiä että rakenteellisia ongelmakohtia 

ja miten ne ratkaistiin menemättä liialti teknisiin yksityiskohtiin. 

 

Liiterin käyttöönottoa projektin valmistumisen jälkeen arvioitiin analytiikkatyökaluihin 

perustuvien raporttien pohjalta. Tällä tavoin saatiin näkökulmaa siihen, miten 

kohderyhmä otti sivuston vastaan sekä kokonaisuudessaan että toteutettujen 

toiminnallisuuksien osalta. 

 

 

4.1 Projektissa käytettävät menetelmät 

 

Tutkielmaan liittyvä projekti oli aloitettu vuoden 2012 kesäkuussa, jolloin Joomlan 

tuetuin versio oli Joomla 2.5. Laaja tuettavuus ja tukijärjestelmä olivat syitä miksi 

kyseinen Joomlan versio valittiin Liiteri-projektille. 

 

Pieneen ohjelmistoprojektiin liittyviä tapaamisia järjestettiin useita ennen sopimuksen 

muodostamista. Asiakasprojektia ideoitiin näissä tapaamisissa yhdessä asiakkaan kanssa 

ja lopulta Liiteriin tulevat toiminnallisuudet saatiin ideoitua ja valittua ne 

toiminnallisuudet, jotka olivat olennaisimpia sivustolle. Tapaamisten tavoitteena oli 

saada ennen vuoden 2012 heinäkuuta selvitettyä sopimusta varten sivuston tarpeet, jotta 



28 

 

 

niitä voitaisiin käyttää sopimuspohjana. Näiden tapaamisten jälkeen ohjelmistoprojektin 

tekninen puoli voitiin aloittaa.  

 

Sisällönhallintajärjestelmiin liittyvässä teoriakatselmuksessa todettiin hallintaliittymän 

olevan haasteellinen kokemattomalle käyttäjälle. Tästä johtuen ohjelmistoprojektissa 

päädyttiin luomaan sisällön muokattavuus mahdollisimman laajaksi julkaisuliittymään 

kirjautuneille käyttäjille. Jos käyttäjä ei ollut tietoinen kaikista hallintaliittymän 

ominaisuuksista, oli sangen suuri tietoturvariski antaa liian laajat käyttöoikeudet 

hallintaliittymään – saati käyttöoikeutta sinne laisinkaan. Kokematon käyttäjä voisi 

saada koko verkkosivuston toimintakelvottomaksi virheen sattuessa jos käyttäjälle olisi 

annettu liian laajat käyttöoikeudet. Julkaisuliittymän puolella hallinnoitiin ainoastaan 

sivuston sisältöä – ei rakenteita – kuten tutkielman sisällönhallintajärjestelmiin 

liittyvässä luvussa tuotiin esille. Tässä tapauksessa asiakkaille järjestettävä koulutus oli 

myös tärkeää suunnitella vaikeusasteeltaan sopivaksi, jotta ei tulisi vastaan tilannetta, 

jossa koulutettavien henkilöiden pohjatiedot eivät olisi tarpeeksi laajoja tietyille 

koulutettaville asioille.  

 

Tämän tutkimuksen tarkoituksena ei ole esitellä sisällönhallintajärjestelmiä 

ohjelmistokoodin muokkauksen ja luomisen näkökulmasta, mutta joissain tapauksissa 

pieniä muutoksia tehtiin ohjelmistokoodiin suoraan – etenkin lisäosien ulkoasuun ja 

laajennuksiin. Olisi ollut myös mahdollista rakentaa kokonaan omia liitännäisiä, 

sivupohjia tai kääntää kielitiedostoja, mutta tässä projektissa keskityttiin olemassa 

olevien laajennusten muokkaamiseen projektille sopivaksi. 

 

Liiterin suunnittelu, toteutus ja testaaminen tehtiin tekemällä ensin yksi versio 

sivustosta, jota kehitettiin eteenpäin tuomalla sivustolle uusia moduuleja yksi kerrallaan. 

Toisin sanoen sivustosta tehtiin jokaisessa esittelyvaiheessa edellistä versiota 

kehittyneempi uusi versio. Jokaista uuden ominaisuuden tuomista edelsi aikaisempien 

ominaisuuksien testaaminen ja hyväksyttäminen asiakkaalla. Tämä mahdollisti 

projektin eri vaiheista tiedottamisen asiakkaalle, jolloin asiakas pysyi hyvin selvillä siitä 

millainen sivustosta oli muodostumassa. Ajoittain asiakas puuttuikin siihen jos sivustoa 

oltiin viemässä sellaiseen suuntaan, jota he eivät toivoneet. Tämä ketterähkö menetelmä 

mahdollisti ohjelmiston kehityksen asiakaslähtöisesti. Sivuston edettyä vaiheeseen jossa 

kaikki ominaisuudet olivat yhdistettyinä, oli asiakas jo hyvin perillä siitä millainen 

sivusto oli kyseessä. Projektin loppuvaiheessa muutoksia ei juuri tarvinnut tehdä.  

 



29 

 

 

4.2 Sivuston tarpeet 

 

Projekti koettiin onnistuneeksi kun Internet-sivusto nuorille oli saatu valmiiksi ja 

perustetun toiminimen Sivuriihi J. Kumpusalon sekä Laihian ja Isonkyrön välillä 

muodostetussa sopimuksessa sovitut toiminnallisuudet löytyivät sivustolta. Olennaista 

oli myös kouluttaa projektin valmistuttua asiakkaat käyttämään luotua sivustoa, joten 

Sivuriihi laati 26 sivua laajan ohjekirjan asiakkaille sisällön omatoimisesta 

päivittämisestä ja opasti asiakasta kaikissa sisältöön sekä sisällön lisäämiseen ja 

muokkaamiseen liittyvissä asioissa. Sivuriihi järjesti kaksi koulutuspäivää asiakkaille 

sivuston toimintaan liittyen.   

 

Asiakkaat valitsivat sivuston nimeksi Liiterin. Hankittuun http://liiteri.info-domainiin 

rakennettiin nuorisotöille yksi yhteinen nuorten tieto- ja neuvontapalvelu jonka eri 

välilehdillä olivat kuntakohtaiset osiot sekä yhteinen etusivu, josta löytyi infoa 

molempien kuntien nuorisotöiden tapahtumista.  

 

4.2.1 Toiminnallisuudet 

 

Sivustolle suunniteltiin joukko toiminnallisuuksia, jotka valikoituivat asiakkaiden 

kanssa käydyissä yhteisissä neuvotteluissa. Nämä toimivat osittain osapuolten kesken 

muodostetun sopimuksen pohjana.  

 

Sisällönhallintajärjestelmän ydinominaisuuksiin kuuluu tekstieditori, jossa sivuston 

julkisesta liittymästä kirjautumisen jälkeen oli helppo muokata sivulla jo olemassa 

olevaa sisältöä sekä luoda uutta. Tähän toimintoon asiakkaat toivoivat erityisesti 

ajastustoimintoa, jolla sivustolle voi julkaista automaattisesti uutisia halutuille 

aikaväleille. Tämän lisäksi vanhat tiedot saataisiin myös poistumaan sivustolta 

ajastetusti. 

 

Sivustolle toteutettavaksi suunniteltiin ilmoittautumislomake. Lomakkeen tarkoituksena 

oli toimia ilmoittautumisvälineenä leireille ja retkille, joten erityyppisiä lomakepohjia 

oli tarkoitus luoda useampia. Erilaiset lomakkeet oli suunniteltu eri käyttötarkoituksia 

varten.  

 



30 

 

 

Sivustolle suunniteltiin ja toteutettiin kalenteri nuorisotoimien toimintaan liittyvien 

tapahtumien esiintuomiseksi, jota asiakas pystyi omatoimisesti päivittämään sivuston 

julkisesta käyttöliittymästä. 

 

Facebook-moduulin todettiin myös olevan sivustolle olennainen, sillä nykyään nuoret 

käyttävät aktiivisesti sosiaalista mediaa. Näin ollen näkyvyys sosiaalisessa mediassa oli 

olennaista. Moduulin tavoitteena oli tuoda sivustolle helppo tapa löytää kummankin 

kunnan nuorisotöiden sekä etsivien nuorisotöiden omat Facebook-sivustot. 

 

Myös kuvagalleriaa toivottiin Liiteriin. Galleriasta voisi selata nuorisotoimien 

julkaisemia kuvia, joiden lisäämiselle otettaisiin käyttöön asiakkaiden kannalta selkeä 

käyttöliittymä. Kuvia pystyisi lisäämään eri kategorioiden perusteella molempien 

kuntien osioihin sekä yhteiseen galleriaan.  

 

Videogalleria-moduuli toimisi samalla periaatteella kuin kuvagalleria. Sivuston 

palvelimen käyttötilan ollessa rajallinen, sivustolle tulevat videot tuotaisiin näkyviin 

yleisen videopalvelun Youtube kautta. Tämä toiminto otettaisiin käyttöön ladatessa 

Youtubeen videota ja asettamalla video yksityiseksi.  Yksityisestä videosta lisättäisiin 

videogalleriaan suora linkki, jolloin video on nähtävissä Liiterissä, mutta ei Youtuben 

oman haun kautta. (Youtube 2014.) 

 

Seuraavaksi esiteltävät toiminnallisuudet olivat alusta alkaen sivustolle mahdollisesti 

toteutettavia ominaisuuksia, mutta monet toiminnallisuuksista vaatisivat asiakkailta 

aktiivisempaa sivuston seuraamista sekä sisällön päivittämistä. Nämä toiminnallisuudet 

päätettiin jättää toteuttamatta sivustolle, koska ne olisivat vaatineet asiakkailta 

merkittävästi enemmän työajan käyttöä sivuston hallinnoinnissa.  

 

Sivustolle suunniteltiin Kysy meiltä -palstaa, jossa pystyisi anonyymisti esittämään 

kysymyksiä työntekijöille. Tämä olisi mahdollistanut henkilökohtaisemman palvelun 

jos jollekin nuorista olisi tullut tarvetta ottaa yhteyttä nuorisotoimeen yksityisesti. Myös 

etsivä nuorisotyö oli toivonut tätä toimintoa, mutta asiakas muutti myöhemmin 

mielensä. 

 

Sivustolle suunniteltiin blogitoimintoa, josta olisi pystynyt lukemaan nuorisotoimien 

ajatuksia. Tämän toiminnallisuuden ylläpitämiseksi päivityksiä olisi täytynyt olla 



31 

 

 

suhteellisen usein, jotta idea olisi kannattanut toteuttaa. Blogiin käytettävää 

toteutustapaa pystyy käyttämään myös sivuston uutispalstoissa. 

 

Sivustolle oli kaavailtu julkaisujen kommentointia, jolloin sivuston sisällöntuottajat 

olisivat lukeneet ja hyväksyneet sivustolle tulleita kommentteja. Tämä olisi vaatinut 

erityisen paljon aikaa asiakkaiden toimesta. 

 

4.2.2 Ylläpito ja palvelin 

 

Eräs olennaisista asioista ohjelmistoprojektin valmistuttua oli sopia sivuston ylläpidosta 

projektin jälkeen. Asiakkaan kanssa sovittiin sivuston ylläpidon toteuttamisesta 

perustetun toiminimen sekä Laihian ja Isonkyrön kuntien välisen ylläpitosopimuksen 

perusteella.  

 

Ylläpito määriteltiin jo hyvissä ajoin määrittämään selkeästi ne asiat, jotka siihen 

kuuluvat ja eivät kuulu. Ohjelmistoprojektin on toisin sanoen tarkoitus jatkua projektin 

valmistuttua ylläpidon muodossa.  

 

Ensimmäiset versiot sivustosta toteutettiin paikallisella palvelimella jonka toiminimi 

tarjosi. Palvelin oli paikallinen ja suljettu: tarkka termi tälle on ”localhost”. Suljetun 

palvelimen näkyvyyden Internetiin esti palomuuri. Sivuston eri versioita oli mahdollista 

esitellä asiakkaalle avaamalla palomuurista pääsy Liiterin kehitysversioon. Palvelimen 

sijaitessa usean tietokoneen lähiverkossa apuna käytettiin reitittimen NAT-toimintoa eli 

osoitteenmuutosta, jolla pystyttiin ohjaamaan tietoliikenne siihen lähiverkossa 

sijaitsevaan tietokoneeseen, jossa kehitysversio Liiteristä sijaitsi. Tällä menettelyllä oli 

mahdollista ohjata liikenne usean tietokoneen lähiverkossa haluttuun kohteeseen 

(Houston 2004: 2–4). Koska on suositeltavaa käyttää selkokielisiä verkko-osoitteita 

pelkän IP-osoitteen eli verkossa toimivan tietokoneen tai Internet-liittymän 

tunnistenumeron sijaan toimiessa asiakkaan kanssa, Sivuriihi käytti dynaamista 

nimipalvelua eli DNS-palvelua muuttaakseen IP-osoitteen selkokieliseksi www-

osoitteeksi eli URL:ksi (Jung et al. 2013). Palomuuri aukaistiin ainoastaan silloin kun 

sivustoa esiteltiin asiakkaalle. 

 

Varsinainen palvelin, johon sivusto toimitettiin lähellä sivuston valmistumista, oli 

klusteroitu palvelin. Se tarkoittaa, että tietokannalle, sivustolle ja tiedonsiirrolle FTP:n 

eli tiedonsiirtoprotokollan kautta oli jokaiselle oma IP-osoitteensa (Microsoft Developer 



32 

 

 

Network 2013). Klusteroitu palvelin mahdollisti tehokkaamman ja nopeamman sivuston 

toteuttamisen, jolloin kohderyhmälle näkyy toimiva sivusto tietämättä sen tarkemmin 

palvelinteknologiasta – tätä vaikutusta kutsutaan läpinäkyvyydeksi.  

 

4.2.3 Sopimusmäärittely 

 

Sopimusmäärittely tehtiin lukujen 4.2.2 ”Ylläpito ja palvelin” ja 4.2.1 

”Toiminnallisuudet” perusteella. Sopimusta muodostettaessa apuna käytettiin myös 

erillistä projektisuunnitelmaa asiakkaiden ja toiminimen välillä. Näistä kohdista 

koostettiin sopimus projektin koko elinkaarelle alkaen projektin läpiviennistä päättyen 

sivuston ylläpitoon. Sopimus muodostettiin sähköpostin välityksellä vaihdettujen 

dokumenttien pohjalta. Kaikki sähköpostitse määritellyt toiminnallisuudet eivät 

päätyneet lopulliseen sopimukseen, mutta sillä ei ollut projektin etenemisen kannalta 

käytännön vaikutusta. Toisin sanoen valmiiseen projektiin ei toteutettu ominaisuuksia, 

joista ei oltu etukäteen sovittu. 

 

 

4.3 Sivuston perustoiminnot ja niiden käyttöönotto 

 

Sivuston suunnittelun tavoitteena oli olla toteuttamatta asiakkaille pääsyä sivuston 

hallintaliittymään. Sisällön muokkaaminen asiakkaiden toimesta toteutettiin 

varsinaisella sivustolla julkaisuliittymästä. Tavoitteena oli saada julkaisuliittymään 

mahdollisimman paljon ominaisuuksista hallittavaksi. Jos joku sivustolle tulevista 

ominaisuuksista ei ollut siihen soveltuva, jäi sisällön päivittäminen ja muokkaus 

ylläpidon alaisuuteen. Kun sivusto suunniteltiin ensisijaisesti siten, että julkaisuliittymä 

oli ainoa mihin asiakas saa käyttöoikeuden, oli mahdollista jättää monimutkaisempi ja 

riskialttiimpi hallintaliittymä pelkästään ylläpidon käyttöön. Tämä lisäsi itsessään 

huomattavasti sivuston tietoturvaa, koska sivuston ohjelmistokoodiin, käyttäjiin sekä 

rakenteisiin pääsi käsiksi ainoastaan sivuston ylläpito. 

  

Rakenteiden suunnittelun ja esiintuomisen tarkoituksena oli käsitellä sivuston 

helppokäyttöisyyttä ja sivuston tarkoituksenmukaisuutta kohderyhmän eli nuorison 

näkökulmasta: palvelivatko sivustolle tarkoitetut toiminnallisuudet nuoren tarpeita ja 

oliko rakenne toimiva.  

 



33 

 

 

4.3.1 Projektissa käytettyjä työkaluja 

 

Sivupohjan ulkoasun muokkauksen apuvälineinä projektissa käytettiin muun muassa 

Netbeans-ohjelmointiympäristöä sekä kuvankäsittelyohjelmia tarpeen vaatiessa 

(Netbeans 2014). Ohjelmista oli paljon hyötyä yllättävissä ongelmakohdissa sivuston 

ohjelmistokoodia muokattaessa. Joomlan oma käyttöliittymä tarjosi tiettyyn rajaan asti 

hyvin ohjelmistokoodin muokkausmahdollisuuksia, mutta läheskään kaikkea ei tätä 

kautta pystynyt muokkaamaan. 

 

Muun muassa käyttämällä Firefox-selaimeen integroitua Aurora-kehitystyökalua oli 

mahdollista tutkia sivuston rakennetta ja muokata sitä väliaikaisesti selainpohjaisesti. 

Tässä tapauksessa muutokset oli mahdollista nähdä ilman välitallennuksia. Tämä 

mahdollisti nopeamman sivuston muokkaamisen, jolloin kaikkia muutoksia ei tarvinnut 

viedä läpi ennen kuin näki mitä aiottu muutos saisi sivustolla aikaan. (Mozilla 

Developer Network 2014.) 

 

4.3.2 Suomenkielisyys 

 

Sivuston kohderyhmänä olivat suomalaiset nuoret. Oli olennaista, että sivustosta tehtiin 

mahdollisimman laajasti suomenkielinen kokonaisuus. Osa tästä tavoitteesta 

saavutettiin asentamalla Joomlaan suomenkielinen kielipaketti, joka löytyi osoitteesta 

http://www.joomla.fi. Myös monille yleisimmin käytetyille liitännäisille ja moduuleille 

löytyi sivustolta suomenkieliset kielipaketit. Näistä päädyttiin käyttämään kielipaketteja 

kalenterimoduuliin sekä tekstieditoriin. Http://www.joomla.fi-sivusto tarjosi myös 

muita Joomlaan liittyviä tarpeellisia tiedostoja, oppaita sekä käytännön neuvoja (Joomla 

2013). 

 

Monet muut käytetyt laajennukset tarjosivat erillisiä kielipaketteja, jotka löytyivät 

kunkin laajennuksen omalta sivustolta. Ainoat käytetyt laajennukset, joihin laajoja 

kielipaketteja ei löytynyt, olivat video- sekä kuvagalleriat. 

 

4.3.3 Rakenne 

 

Sivuston rakennetta pohdittiin yhdessä asiakkaan ja toiminimen välisissä neuvotteluissa. 

Niissä päädyttiin tutkielman tekijän tekemien kysymysten perusteella tässä luvussa 

esiteltyyn ratkaisuun. Asiakkaiden kanssa pohdittiin paljon sitä mikä sivustolla oli 



34 

 

 

olennaista nuoren kannalta. Tämän tarkoituksena oli selvittää miten sivusto saataisiin 

rakenteeltaan selkeäksi, jotta olennaisin sisältö olisi helposti löydettävissä, mutta 

tarkempaa informaatiota löytyisi helposti muutaman hiiren painalluksen jälkeen.  

 

Yläreunaan tuotiin isokokoinen otsakekuva, jonka alle toteutettiin päävalikko. 

Liikkumalla päävalikon eri kohtiin pääsi käyttäjä valitsemaan sivuston sisältöosion 

vasemmassa palstassa sijaitsevasta sivuvalikosta tarkempaa tietoa valittuun 

aihealueeseen liittyen. Päävalikko-elementin oikeaan reunaan tuli hakupalkki, josta 

pystyi hakemaan tietoa koko sivuston sisällöstä käyttämällä avainsanoja. (Kuva 1.) 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Kuva 1. Sivustolle toteutuneen sivupohjan elementit. 

 

Sivuston sisältöalue luotiin kooltaan staattiseksi, eli se ei mukauttanut itseään 

erikokoisten näyttöjen tarkkuuden eli resoluution tai laitteen koon mukaan. Vastakohta 

olisi ollut responsiivinen eli mukautuva sivupohja, jonka perusominaisuuteen kuului 

käytettävän laitteen tarkkuuden tai laitteen fyysisen koon tarkastaminen ja sivuston 

ulkoasun mukauttaminen sen mukaan. Liiterissä käytettävä sivupohja ei ollut 

mukautuva, koska sellaisen toteuttaminen avoimen lähdekoodin sovelluksilla ei vuonna 

2012 ollut vielä yleistä. Käytetyssä ratkaisussa sivuston perusrakenteet pienenivät 



35 

 

 

samassa suhteessa koko sivustolla sen sijaan että muuttuisivat eri laitteiden koon 

mukaan (Radtke 2012: 59). Liiteriin suunnitellun sisältöalueen leveys ei kuitenkaan 

ollut liian suuri ollakseen yhteensopiva eri laitteille, jolloin pienemmillekin näytöille 

sisältöalue näkyi sopivan kokoisena. Käytettävä ratkaisu ei ollut niin kehittynyt kuin 

jälkeenpäin yleistyneet avoimen lähdekoodin ratkaisut ovat mahdollistaneet. Liiterissä 

käytetty sivuston taustakuva oli niin sanotusti kiinteä, jolloin sama kuva näkyi sivustolla 

koko ajan samanlaisena liikuttaessa sivustolla vertikaalisesti (W3schools 2013). 

 

Sivuston sisältöosion rakenne luotiin käyttämällä sisällössä kahta palstaa, vasempaan 

reunaan tulivat sivuston päävalikkojen alavalikot sekä isompien liitännäisten 

minimoduulit. Loppuosa sivustosta koostui tekstistä ja niihin liittyvistä kuvista sekä 

kokonaisista laajennuksista.  

 

Sivustolle valittu navigointirakenne mahdollisti tiedon selkeän esittämisen sivustolla. 

Tässä rakennemallissa mikään tieto ei ollut monen hiiren painalluksen takana – 

tarkalleen ottaen sivuston valikkorakenne sisälsi syvimmillään neljä tasoa (päävalikko 

mukaan lukien) eli hierarkiassa yhden aihealueen takana oli korkeintaan kolme hiiren 

painallusta. Tätä kutsutaan leveäksi navigointirakenteeksi, joka ei ole rakenteellisesti 

kovinkaan syvä. Toisin sanoen sivuston rakenne oli monitasoinen eli sivuston 

päävalikot olivat saatavilla sivuston jokaisessa osiossa. Tällaista rakennetta kutsutaan 

myös puurakenteeksi. Edetessä syvemmälle puuhierarkiassa sivustolle aukesi uusia 

valikkoja, joista löytyi eri aiheista tarkempaa tietoa (Tidwell 2011: 80–85). Sivusto 

myös osoittaa värittämällä valikkorakenteessa tummemmalla värillä sen osion, jossa 

käyttäjä liikkui. Vieraillut valikot näkyivät aktiivisen ja vieraillun linkin 

väriyhdistelmään sopivana sävynä (Spool et al. 1999: 28). Toinen yleinen vaihtoehto, 

jolla voi ilmoittaa käyttäjälle hänen sijaintinsa sivustolla, on murupolku eli 

”breadcrumbs” (Tidwell 2011: 121–123). Murupolku kertoo käyttäjälle hänen 

sijaintinsa sivustohierarkiassa tekstipolkuna, jossa käyttäjä näkee puurakenteen koskien 

sitä osiota missä hän sivustolla sijaitsee. Liiterissä murupolkua ei otettu käyttöön koska 

valikkorakenne ei johtanut sivustolla tarpeeksi syvälle kuin harvoissa tapauksissa. 

Päävalikon ollessa saatavilla sivuston jokaisessa osiossa, ei murupolku olisi ollut 

perusteltu.  

 

Hakutoiminto oli yksi leveää navigointirakennetta tukeva vaihtoehto, jolloin käyttäjä 

voi etsiä suoraan haluamaansa tietoa hakusanalla sivustolta ja vastaavasti päästä tietoon 

käsiksi nopeammin. Hakutoiminto luotiin Liiteriin saataville jokaiselle sivulle sivuston 



36 

 

 

oikeaan yläreunaan. Noin yksi kolmasosa Internet-sivustojen käyttäjistä käyttää 

aktiivisesti sivuston sisäistä hakutoimintoa navigoinnin apuvälineenä (Spool et al. 1999: 

30). 

 

Sivuston päävalikon kohdiksi valittiin Etusivu, Info, Isokyrö, Laihia, Tapahtumat, 

Galleria, Etsivä nuorisotyö sekä Yhteystiedot. Tavoitteena tällä asettelulla oli selkeä 

yleisen nuoren tietopaketin tarjoaminen Info-osiossa, josta löytyi laajasti tietoa nuorta 

askarruttaviin kysymyksiin. Tietopakettiin liittyi muun muassa tietoa opiskeluun ja 

työelämään liittyen. Kunkin kunnan nuorisotöille kuuluvat paikalliset tiedot löytyivät 

kuntien omista valikoista. Tällä mahdollistettiin nuorelle helppo tiedon löytäminen. 

Asiakkaat halusivat myös yleisimpien yhteystietojen löytyvän haluttaessa nopeasti, 

joten yhteystiedot luotiin näkyvälle paikalle myös päävalikkoon. 

 

4.3.4 Sivupohja 

 

Sivupohjaksi sivustolle valittiin avoimeen lähdekoodiin perustuva sivupohja eli 

”template”, joka kopioitiin uudeksi erilliseksi sivupohjaksi, josta sitä lähdettiin 

kehittämään sivustolle sopivammaksi.  

 

Ohjelmistoprojektin edetessä valitun sivupohjan rajallisuus tuli monta kertaa vastaan. 

Esimerkiksi päävalikkoa muokattiin paljon. Valikkorakenne ei alun perin 

mahdollistanut päävalikon alasvetovalikkojen näkymistä. Alasvetovalikko aukeaa 

valikkorakenteessa valitun toiminnon eli tässä tapauksessa valikkonapin alapuolelle 

uudeksi valikoksi. Tämä ongelma korjattiin, mutta lopulta asiakkaan kanssa päädyttiin 

kyseisen ominaisuuden poisjättämiseen sivustolta. Sen sijaan alasvetovalikot päädyttiin 

ottamaan käyttöön erillisen valikon muodossa sivuston sisältöosion vasempaan reunaan, 

jossa valikko saatiin selkeämmin esille. Esimerkiksi Info-osion laajuuden vuoksi tämä 

oli parempi ratkaisu helpomman navigoinnin mahdollistamiseksi. Päävalikko ei 

myöskään mahdollistanut alun perin hakukentän lisäämistä päävalikon oikeaan reunaan, 

vaan sille lisättiin PHP:n avulla oma kohtansa.  

 

Tutkielmassa aiemmin esiintynyt kuva 1 tuo esiin Liiterissä käytettävän sivupohjan 

lopullisen rakenteen. Paikat löytyivät päävalikolle, hakukentälle sekä laajennuksien 

pienoisversioille erikseen sivun vasempaan reunaan. Vasemmassa reunassa on 

käytännössä yksi moduulipaikka, jonka oikealle puolelle eli sivuston keskiosioon 

sijoittuu sivuston varsinainen sisältö. Tulevaisuudessa on mahdollista ottaa käyttöön 



37 

 

 

sisältöosion alapuolella oleva valmis moduulipaikka, johon esimerkiksi murupolku olisi 

tarvittaessa looginen vaihtoehto. 

 

4.3.5 Ulkoasu ja värimaailma 

 

Ulkoasu suunniteltiin helposti muunnettavaksi sivupohjan muokkaamisvaiheessa. Tässä 

tapauksessa kyseisenlaisella muunnettavuudella tarkoitettiin sivustolla olevaa kahta 

pääelementtiä, joita vaihtamalla sivuston ilmettä saatiin muokattua merkittävästi. 

Pääelementit olivat sivuston tausta- ja otsakekuva. Asiakkaat toivoivat sivuston 

ulkoasun olevan sarjakuvamainen sekä sivuston nimen tuovan siihen oman leimansa. 

 

Sivuston värimaailma koostui vihreästä, oranssista, valkoisesta ja mustasta. Logon 

suunnittelua toiminimi ei toteuttanut itse, vaan kunnat järjestivät logokilpailun nuorille. 

Asiakkaat valitsivat kilpailuun osaa ottaneiden tuotoksista uuden logon, joka oli samalla 

logokilpailun voittaja. 

 

Erilaisia ulkoasumalleja kehitettiin yhdessä eteenpäin, jonka jälkeen ennen lopullista 

versiota tehtiin muutamia sarjakuvamaisia luonnoksia. Kuva 2 esittelee sivuston 

toteutunutta ulkoasua, jossa on mukana asiakkaiden järjestämän kilpailun voittajan 

luoma logo. 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Kuva 2. Lopullinen ulkoasu. 

 



38 

 

 

Olennaisessa asemassa ulkoasun suunnittelussa oli kuunnella asiakasta. Monen 

välivaiheen jälkeen ulkoasusta muodostui helppolukuisempi, joka täytti asiakkaan 

toivomukset alkaen värien käytöstä sivuston sarjakuvamaiseen tyyliin. Asiakkaan 

kuuntelemisen tärkeyden lisäksi myös asiakkaan opastaminen oli olennaista. 

Kommunikoinnissa oli tärkeää unohtaa alan sanasto ja pyrkimyksenä oli käytännön 

esimerkein havainnollistaa sitä mistä elementeistä sivuston ulkoasu voi koostua. 

 

 

4.4 Sivuston laajennukset 

 

Tässä luvussa esitellään sivustolle toteutuneet laajennukset ja käydään läpi suppeasti 

niiden muokkaamista sivuston julkaisuliittymästä kirjautuneiden käyttäjien kesken. 

Luvussa esitellään käyttöliittymiä lyhyesti sekä tuodaan esiin ne asiat jotka jäivät 

ylläpidon alaisuuteen. Tarkoituksena oli tuoda julkaisuliittymään mahdollisimman 

paljon laajennuksia asiakkaiden hallittavaksi, jolloin helppokäyttöisyys oli ensisijaista 

laajennuksien valinnassa. Tavoitteena oli mahdollisimman laaja sisällön 

muokkaamismahdollisuus laajennuksia koskien. 

 

4.4.1 Tekstieditori ja uutisten lisääminen 

 

Tekstieditoriksi valittiin JCE-editori joka oli WYSIWYG-editori (”What You See Is 

What You Get”), joka loi sivuston julkiseen liittymään kirjautuneille mitä tahansa 

yleistä tekstinkäsittelyohjelmaa muistuttavan editorin. JCE on laajempi editori kuin 

Joomlan asennuksessa mukana tuleva Tiny MCE -editori (Joomla 2014c; Wakode 2013: 

570). Editori oli pitkälle muokattavissa ja siihen otettiin mukaan ainoastaan sivuston 

sisällön muokkaamisessa tarvittavat ominaisuudet. Editori mahdollisti myös 

artikkeleiden luonnin sivustolle julkaisuliittymästä, jolloin oli mahdollista ajastaa 

sivustolle esimerkiksi uutisia tulevista tapahtumista. Editoriin pääseminen 

julkaisuliittymästä tapahtui halutusta artikkelista lehtiö-kuvakkeen kautta. Sama 

periaate toimii sivuston jokaisessa osiossa haluttaessa muokata jo olemassa olevaa 

sisältöä. Kuvissa 3-5 tuodaan esille miten sisältöä muokataan Joomlaan 

sisäänrakennetussa julkaisuliittymässä käyttämällä JCE-editoria. 

 

 

 

 



39 

 

 

 

 

 

 

 

 

 

 

 

 

 

Kuva 3. Sisällön muokkausikkunan avaaminen julkaisuliittymässä. 

 

Tekstieditori eli muokkausikkuna oli sivukohtainen, eli jokaisesta sisältöosiosta aukesi 

sama editori, mutta kyseiselle sivulle tarkoitetulla sisällöllä. 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Kuva 4. Tekstieditori JCE julkaisuliittymässä. 

 

Kuva 5 demonstroi uutisartikkeleiden lisäämistä Joomlaan julkaisuliittymästä 

kategorioiden perusteella. Hallintaliittymästä täytyi antaa sivuston julkaisuliittymän 

hallinnoijille oikeudet lisätä artikkeleita ja suunnitella käytettävät kategoriat 

asiakaslähtöisiksi.  



40 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Kuva 5. Artikkelin luominen julkaisuliittymästä. 

 

4.4.2 Ilmoittautumislomake 

 

Lomakelaajennukseksi valittiin Proforms-laajennus, jolla oli mahdollista luoda 

lomakepohjia erilaisia retkiä ja tilaisuuksia varten. Laajennus käytti vahvasti tietokantaa 

eikä siihen ollut siitä syystä käyttöliittymää sisällönhallintaan julkaisupuolelle. Jokaista 

tapahtumaa varten luotiin uusi lomakepohja, joka tuotiin erikseen sivustolle. 

Lomakkeen tuontia ja suunnittelua ei pystytty toteuttamaan sivuston julkaisuliittymään 

kirjautuneille käyttäjille. Toisin sanoen asiakkaan ottaessa käyttöön uuden 

ilmoittautumislomakkeen, he eivät pystyneet sitä itse tekemään, vaan lomakkeen 

tuominen sivustolle tapahtui ylläpidon kautta. Kuvassa 6 on esimerkki 

ilmoittautumislomakkeesta, jollainen Liiteriin tuotiin aina uusien tapahtumien 

yhteydessä. 

 



41 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Kuva 6. Ilmoittautumislomake ja CAPTCHA. 

 

Lomakkeen toimintaperiaatteisiin kuului ilmoituksen varmentaminen lähettämällä 

ilmoittautuneelle nuorelle sähköpostiviesti onnistuneesta ilmoittautumisesta ja 

ilmoittamalla onnistuneesta lomakkeen täyttämisestä sivustolla heti lomakkeen 

lähettämisen jälkeen. Onnistunut ilmoittautuminen merkittiin tietokannan kautta 

sivustolle lisäämällä kaikki kyseiselle retkelle ilmoittautuneet henkilöt samaan listaan. 

Lomakemoduuli toimitti listan ilmoittautujista nuorisotöille.  

 

CAPTCHA toimii estona haittaohjelmien tekemille ilmoittautumisille (kuva 6). 

CAPTCHA on automatisoitu testi jonka ihminen pystyy päättelemään, mutta 

tämänhetkiset keinoälyyn pohjautuvat haittaohjelmat eivät pysty. Käytännössä 

CAPTCHA on muuttuva teksti- tai kirjainyhdistelmä ja joissakin tapauksissa kysymys 

tai laskutoimitus (von Ahn et al. 2013). Lopullisessa versiossa päädyttiin käyttämään 

vaihtuvaa laskutoimitusta, jossa CAPTCHA:n läpäistäkseen täytyy syöttää kenttään 

laskun lopullinen tulos.  

 



42 

 

 

4.4.3 Kalenteri 

 

Kalenteriksi sivustolle valittiin JEvents, joka täytti kaikki asiakkaalla olleet kriteerit 

tapahtumien esiintuomiselle. Kalenterista löytyivät nuorisotöiden järjestämät erilliset 

sekä yhteiset tapahtumat, joita asiakkaan oli helppo hallinnoida. Kalenterin erityinen 

vahvuus oli toistuvien tapahtumien luonti, joita voi kuitenkin jälkikäteen poistaa 

yksittäin. Tämä oli toivottu toiminto, koska jos esimerkiksi jokin suunnitelluista 

tapahtumista peruuntui, oli pelkästään peruuntunut tapahtuma mahdollista poistaa 

erikseen. Kaikki tapahtumien lisäykset ja muokkaukset oli mahdollista suorittaa 

julkaisuliittymästä. Kuvassa 7 on esimerkkiotos kalenterissa käytettävästä tapahtumien 

muokkaamisesta jälkikäteen, josta ilmenee mitä kaikkea olemassa oleville tapahtumille 

pystyi jälkikäteen toteuttamaan. 

 

 

 

 

 

 

 

 

 

 

 

 

Kuva 7. Otos kalenterin käyttöliittymästä. 

 

4.4.4 Sosiaalinen media 

 

Facebook-moduuli toteutettiin Facebookin tarjoamalla kuvalinkillä, joka lisättiin kunkin 

kunnan erillisen osion vasempaan reunaan. Tämä mahdollisti työntekijöiden 

ajankohtaisimpien palstojen helpon löytymisen nuorisolle. Nuorisotoimet käyttivät 

Facebookia myös Liiterissä tapahtuneiden muuttuneiden sisältöjen markkinointiin. 

 



43 

 

 

4.4.5 Kuvagalleria 

 

Kuvagalleriaksi valittiin Joomgallery, joka mahdollisti gallerian yhtäaikaisen 

muokkaamisen julkaisuliittymästä usealle eri käyttäjälle. Sivustolla kokeiltiin myös 

muita kuvagallerialaajennuksia, mutta ne eivät toimineet toivotulla tavalla. Joomgallery 

mahdollisti kuvien lisäämisen kategorioiden perusteella, jolloin kummallekin 

asiakkaalle saatiin sekä oma että yhteinen kuvagalleria. Kuvatietojen muokkaaminen ja 

poistaminen onnistui myös julkaisuliittymästä. Tämä mahdollisti asiakkaille moduulin 

tarpeellisen muokattavuuden. Kuvassa 8 ilmenee suppeasti otos kuvan lisäämisestä 

kuvagallerian käyttöliittymässä sivun julkaisuliittymässä. Tätä laajennusta ei ollut 

saatavilla kokonaisuudessaan suomenkielisenä. 

 

 

 

 

 

 

 

 

 

 

Kuva 8. Otos kuvagallerian käyttöliittymästä. 

 

4.4.6 Videogalleria 

 

Videogalleriaksi valittiin All Video Share, jossa oli toimiva julkaisupuolen 

käyttöliittymä, jolla asiakas pystyi itse lisäämään sivustolle videoita luotuun 

videogalleriaan. Videotiedostot ovat usein suuria, joten sivuston palvelimen rasituksen 

vähentämiseksi oli suositeltua tuoda videot sivustolle yleisen videopalvelun Youtube 

kautta. Tämä oli mahdollista Youtube-palvelun tarjoamilla videon 

yksityisyysasetuksilla, jolloin videoon pääsee käsiksi ainoastaan videon linkin ollessa 

selvillä. Suoran videolinkin voi silloin tuoda galleriaan, jolloin videota oli mahdollista 

katsoa Liiterissä, mutta videolinkki ei rasita varsinaista sivustoa liikaa (Youtube 2014). 

Tämä laajennus oli täysin englanninkielinen, joka oli Liiterissä poikkeustapaus, sillä 

suurin osa kaikesta käytettävästä informaatiosta ja sisällöstä asiakkaiden näkemässä 



44 

 

 

julkaisuliittymässä olivat suomenkielisiä. Kuvassa 9 on esimerkki videon lisäämisestä 

sivuston julkaisuliittymästä videogalleriaan. 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Kuva 9. Videogallerian käyttö. 

 

 

4.5 Kävijäseurantaraportit vuonna 2013 

 

Liiteriin liittyvät kävijäseurantaraportit tehtiin 28.5.2013 sekä 5.11.2013. Tässä luvussa 

käydään läpi molempia raportteja ja niitä verrataan keskenään. Raportit löytyvät 

tutkielman liitteistä. Raportit olivat suuntaa antavia ja ne oli toteutettu Laihian ja 

Isonkyrön kuntien nuorisotoimien pyynnöstä Liiterin käyttöönottoon liittyen. Raporttien 

läpikäynnin tarkoituksena ei ole keskittyä niinkään yksityiskohtiin vaan siihen mitä 

ominaisuuksia kohderyhmä oli sivustolla aktiivisesti käyttänyt, kuinka kauan sivustolla 

oli keskimäärin vietetty aikaa sekä miten Liiteri löytyi hakukoneilla.  

 

Kävijäseurannassa käytettyjä työkaluja olivat Googlen analytiikkatyökalu sekä 

palvelinpohjainen analytiikkatyökalu AWStats.  

 



45 

 

 

Kävijämäärät olivat tasaisessa nousussa vuoden 2013 maaliskuun jälkeen, jolloin Liiteri 

avattiin. Kesän aikana kun koulutoimintaa ei niinkään ollut, olivat kävijämäärät 

luonnollisesti pienempiä. Kävijämäärissä oli havaittavissa myös tiettyinä ajankohtina 

enemmän kävijöitä kuin muulloin. Normaalista poikkeavia kävijämäärähuippuja voi 

kutsua kävijämääräpiikeiksi. Kun sivustolle oli luotu uutta sisältöä, oli kävijöitä myös 

enemmän. Eritoten tämä kävi ilmi niistä ajankohdista, jolloin nuorisotoimet olivat 

suunnitelleet ja toteuttaneet retkiä nuorille. Toisin sanoen sivustolle lisätyt 

ilmoittautumislomakkeet olivat aiheuttaneet sivustolle kävijäpiikkejä.  Huomattavissa 

oli myös kävijöiden suurempi määrä liittyen viikkoaikatauluun. Alkuviikosta 

vierailijoita oli sivustolla enemmän kuin loppuviikosta. Raporteissa kehotettiin 

ajastamaan sivuston päivittyvää sisältöä alkuviikolle, jolloin sivustolla kävi enemmän 

vierailijoita.  

 

Jälkimmäisestä kävijäseurantaraportista kävi ilmi, että poistumisprosentti, eli yhden 

sivun verran Liiteriä selanneiden vierailijoiden osuus, oli sivustolla suhteellisen korkea. 

Tämä johtui osittain siitä, että suurin osa Liiterin muuttuvasta sisällöstä löytyi etusivun 

uutispalstasta. Tässä lukemassa oli havaittavissa nousua verraten ensimmäiseen 

raporttiin, joka oli perusteltavissa osittain sillä, että sivustolle palaava käyttäjä kävi läpi 

usein ainoastaan sivustolla muuttuneet tiedot. Palaavien vierailijoiden määrä oli 

jälkimmäisessä raportissa sivustolla noin 33 prosenttiyksikköä. 

 

Suurin osa sivustoa käyttävistä ihmisistä vieraili sivustolla alle kahden minuutin ajan. 

Uudet sivustolle tulleet vierailijat käyttivät todennäköisesti enemmän aikaa tutustumalla 

sivuston eri osioihin. Sivustolla vierailu ajoittui enimmäkseen virastoaikaan, eli 

aamukahdeksasta iltapäiväneljään asti, mutta pientä kävijämääräpiikkiä oli havaittavissa 

uudestaan illalla. Tämä sopi sivuston kohderyhmään, sillä sivuston käyttäjät olivat 

koululaisia jotka vierailivat sivustolla kouluaikaan sekä mahdollisesti myöhemmin 

uudestaan. Osa yhden sivun vierailijoista oli saattanut myös olla sellaisia vierailijoita, 

jotka etsivät muuta informaatiota Internetistä, mutta eivät sitä Liiteristä löytäneet. 

 

Analytiikkatyökalut osoittivat suosituimmaksi sisällöksi etusivun jälkeen 

tapahtumakalenterin, josta näkyi nuorisotoimien järjestämät tapahtumat muun muassa 

kouluiltojen jälkeen. Myös tapahtumat, joissa oli käytetty ilmoittautumislomaketta, 

olivat nousseet Liiterissä vierailluimman sisällön joukkoon. Merkittävä muutos sisällön 

vierailumäärissä oli huomattavissa jälkimmäisessä raportissa Info-osion putoamisessa 

listalla alaspäin verraten ensimmäiseen raporttiin. Ensimmäisessä raportissa Info-osio 



46 

 

 

oli vierailluimpien listalla neljäntenä, kun toisessa raportissa se oli tipahtanut listalla 

kymmenenneksi. Tämä havainto tukisi poistumisprosenttiluvun suurenemisen syytä. 

Liiterin alkuaikoina vierailijat lukivat Info-osuutta enemmän, koska silloin 

informaatiopakettiin liittyvä sisältö oli vielä tuoretta. Kuvagalleriat kuuluivat myös 

vierailluimpien sisältöjen joukkoon. Myös muut toiminnallisuudet olivat olleet 

vierailluimpien sivujen joukossa lukuun ottamatta videogalleriaa, jota ei oltu otettu 

kovinkaan aktiiviseen käyttöön, koska galleriassa oli ainoastaan yksi videolinkki. 

Jälkimmäisessä raportissa huomio keskittyi enemmän sivuston muuttuneen sisällön 

selaamiseen. Sivuston toiminnallisuuksien sekä laajahkon käyttöasteen perusteella voi 

myös olettaa, että sivustolle toteutettu rakenne oli ollut toimiva. 

 

Hakukonenäkyvyyden kartoittamiseen oli käytetty Googlen analytiikkatyökalua 

liitettynä Googlen ”Webmaster Tools” -työkaluun. Hakukonenäkyvyys oli analytiikan 

perusteella ollut onnistunut. Liiteri löytyi monilla eri hakusanoilla hakukoneilla. 

Hakemalla pelkästään yleisellä hakusanalla ”Liiteri”, oli projektin sivusto ollut Googlen 

haussa keskimäärin sijalla 8,7 eli ensimmäisellä sivulla suurimman osan hakukerroista. 

Yksi Googlen hakutulossivu sisältää kymmenen hakutulosta. Hakemalla suoraan 

sanoilla ”liiteri.info” projektisivu oli löytynyt hakutuloksissa ensimmäisenä. Liiteri 

löytyi hakukoneista myös monilla muilla hakusanoilla, johtuen suuresta informaation 

määrästä nuorelle suunnatussa informaatiopaketissa. 

 

Molemmissa raporteissa suurin osa Liiterin vierailijoista tuli sivustolle kirjoittamalla 

Liiterin verkko-osoitteen suoraan osoitekenttään. Toiseksi suosituin liikennöinnin lähde 

oli Google, jonka jälkeen tulivat Laihian kunnan sivut sekä Facebook. Sivusto löytyi 

toisin sanoen monilla eri tavoilla. Facebook todennäköisimmin toi vierailijoita 

tutkimaan sivuston muuttunutta sisältöä, johtuen Liiterin Facebook-ryhmissä 

toteutetusta sivuston muuttuneen sisällön markkinoinnista. Sivusto löytyi myös 

http://www.koordinaatti.fi -sivuston kautta, joka listaa kaikki Suomessa käytössä olevat 

nuorten tieto- ja neuvontapalvelut löydettäviksi samalta sivustolta (Koordinaatti 2014). 

 

 

4.6 CASEn yhteenveto ja arviointia 

 

Tapaamiset asiakkaiden ja Sivuriihen välillä koostuivat Sivuriihen suunnittelemista 

kysymyksistä, jotka perustuivat siihen miten laajan sivuston asiakkaat halusivat. Pieniin 

ohjelmistoprojekteihin liittyvät tapaamiskäytännöt olivat toimivia projektin 



47 

 

 

onnistumisen kannalta.  Kysymysten perusteella valikoitui sivustolle perusidea, jota 

kehitettiin jatkotapaamisissa. Toteutettaviksi valitut toiminnallisuudet määrittelivät 

pitkälti sopimuksen sisällön, mutta sopimuksen syntyyn vaikuttivat myös sivuston 

jatkotarpeet projektin valmistuttua.  

 

Pohjana sopimukselle toimi erillinen projektisuunnitelma sekä luvussa 4.2.3 esitellyt 

muut dokumentit. Sopimus muodostettiin elokuussa 2012 määrittämään koko projektin 

elinkaarta projektin teknisestä toteutusvaiheesta projektin ylläpitovaiheeseen. Kaikki 

tekniseen toteutukseen kuuluneet toiminnallisuusmäärittelyt eivät päätyneet lopulliseen 

sopimukseen, mutta tästä huolimatta kaikki suullisesti ja kirjallisesti sovitut 

toiminnallisuudet toimitettiin sivustolle. Ylimääräisiä projektiin kuulumattomia 

toiminnallisuuksia ei sivustolle toteutettu. 

 

Projektissa käytettävä sisällönhallintajärjestelmä Joomla oli projektin toteuttajalle tuttu 

ennakkoon, mutta uusia asioita tuli esille valtavasti projektin aikana. Uudet asiat 

liittyivät olennaisesti käytäntöön eli asioihin jotka eivät olleet tulleet vastaan samaan 

aiheeseen liittyvillä aiemmin Vaasan yliopistossa suoritetuilla kursseilla. Opiskeltava 

kauppatieteiden maisterin tutkinto tietotekniikan pääaineesta toisaalta mahdollisti esiin 

tulleiden ongelmien nopeahkon löydettävyyden ja tätä kautta oli mahdollista tutkia 

nopeasti miten ongelmat ratkaistaisiin käytännössä. 

 

Toteuttamisvaiheessa asiakkaalla hyväksytettiin uusia sivustolle tuotuja 

toiminnallisuuksia yksi kerrallaan. Tämä osoittautui toimivaksi menettelytavaksi 

projektin loppuvaiheessa. Silloin suurempia muutoksia ei enää tehty, koska tarvittavat 

muutokset oli tehty jo aikaisemmin.  

 

Tavoitteena oli saada valmis tuote julkaistua loppusyksyllä 2012, mutta projektin 

tekninen toteutus viivästyi hieman ja tuote oli valmis joulukuussa 2012. Sivusto avattiin 

maaliskuussa 2013. Vaikka sivusto oli valmis joulukuussa, oli sivustolle tuleva sisältö 

vielä osittain kesken. Koska sivustoa ei haluttu julkaista sisällöllisesti keskeneräisenä 

heti tuotteen valmistuttua, päätettiin sivusto julkaista vasta sitten kun sisältö oli 

suurimmaksi osaksi valmis. Sivuriihi vastasi sisällöstä ainoastaan neuvonnallisessa 

mielessä. Neuvonta koski kouluttamista asiakkaan omatoimiseen sisällön lisäämiseen ja 

päivittämiseen sivustolle. Neuvonnan tueksi järjestettiin kaksi koulutuspäivää sekä 

luotiin ohjekirja.  

 



48 

 

 

Alkuperäinen suunniteltu projektin toteuttamisaikataulu oli todennäköisesti muodostettu 

liian tiukaksi. Projekti oli toteuttajalle ensimmäinen kokonaan yksin toimitettuna, joten 

aikaisemman vastaavan kokemuksen puuttuminen aiheutti liian optimistisen 

projektiaikatauluarvion. Projektin aikataulutusta suunniteltaessa olisi ollut hyvä ottaa 

huomioon laajemmin myös todennäköiset ja pessimistiset näkökulmat viitaten 

Parkinsonin lakiin (Phillips 2011: 128–129). 

 

Toiminnallisuudet saatiin suunniteltua ja toteutettua asiakaslähtöisiksi. Suunnitelluista 

toiminnallisuuksista ainoastaan lomaketoiminto vaati ylläpidon osallistumista sisällön 

tuottamiseen. Muiden toiminnallisuuksien käyttö onnistui täysin julkaisuliittymään 

kirjautuneille käyttäjille. Koska asiakkaille annettiin käyttöoikeus ainoastaan sivuston 

julkaisuliittymään, oli tärkeää saavuttaa tutkielman tavoite helppokäyttöisen, turvallisen 

ja laajan sisällön tuottamisen mahdollistamisesta. 

 

Asiakkaat ovat maaliskuussa 2014 käyttäneet sivustoa vuoden verran. He ovat 

omatoimisesti päivittäneet sivuston sisältöä toteutettujen koulutusten sekä ohjekirjan 

pohjalta. Asiakkaan puolelta on tullut harvemmin yhteydenottopyyntöjä 

toiminnallisuuksien käyttöön liittyvissä asioissa. Sisältö Liiterissä on ollut muuttuvaa ja 

ajankohtaista. On syytä myös tästä näkökulmasta olettaa, että projektin tavoitteista 

helppokäyttöisyys on toteutunut hyvin. 

 

Suuntaa antavat kävijäseurantaraportit antoivat viitteitä Liiterin käyttöönotosta nuorten 

keskuudessa tai ainakin siitä, että osa kuntien nuorisosta oli löytänyt Liiterin. 

Kohderyhmä oli tutkinut sivustolta löytyviä eri toimintoja liittyen enimmäkseen 

ajankohtaisiin uutisointeihin sekä sivuston muutoksiin, kuten tapahtumakalenterista 

löytyviin tapahtumiin. He olivat tutkineet myös laajasti sivuston informaatiopakettia 

sekä sivuston muuttuvaa uutissisältöä. Ajastetut ilmoittautumislomakkeet olivat 

aiheuttaneet sivustolle kävijäpiikkejä. Suunnitellut toiminnallisuudet löytyvät 

lopulliselta sivustolta ja se osa kohderyhmästä, joka on sivuston löytänyt, on 

kävijäseurantaraporttien perusteella ottanut ne laajahkosti vastaan. 

 



49 

 

 

5.  YHTEENVETO JA KEHITYSEHDOTUKSIA 

 

Yksi tutkielman tavoitteista oli saada selville miten sisällönhallintajärjestelmiin liittyvä 

pieni ohjelmistoprojekti oli kannattavaa toteuttaa yhden henkilön ohjelmistoprojektissa. 

Tutkielmassa käytiin läpi myös kuinka sisällönhallintajärjestelmällä saatiin luotua 

mahdollisimman vaivaton laaja sisällönhallinta henkilöille, joilla ei ollut laajaa 

tietoteknistä taustaa. Asiakasprojekti Liiterin käyttöönottoa seurattiin myös reilun 

puolen vuoden ajan analytiikkatyökaluilla, jonka tavoitteena oli saada selville oliko 

kohderyhmä, eli Laihian ja Isonkyrön kuntien alueella asuva nuoriso löytänyt nuorten 

tieto- ja neuvontapalvelu Liiterin ja siihen toteutetut eri toiminnallisuudet. 

 

Tutkitut pienen ohjelmistoprojektin menettelytavat osoittautuivat toimiviksi 

ratkaisumalleiksi projektin eri vaiheisiin. Kyseisiä menettelytapoja käyttämällä pieni 

ohjelmistoprojekti Liiteri toteutettiin onnistuneesti eri vaiheineen.  Vaikka projektin 

valmistuminen viivästyi suunnitellusta muutamalla kuukaudella, oli tuote valmis kolme 

kuukautta ennen sen varsinaista julkaisupäivämäärää. 

 

Koulutetut, sivustolle rekisteröityneet käyttäjät olivat aktiivisesti luoneet ja päivittäneet 

sivustolle uutta sisältöä koulutuksen jälkeen ja ohjekirjaa apuna käyttäen. Oli syytä 

olettaa, että Liiteriin toteutettu sisällön hallinnointi julkaisuliittymästä oli ollut 

rekisteröityneille käyttäjille helppokäyttöinen. 

 

Liiteri otettiin käyttöön maaliskuussa 2013. Projektin jälkeen toteutettuihin suuntaa 

antaviin kävijäseurantaraportteihin perustuvat havainnot osoittivat Liiterin ainakin 

osittain löytäneen kohderyhmänsä. Käyttäjät olivat käyttäneet sivun eri 

toiminnallisuuksia monipuolisesti ja sivusto oli löytynyt hyvin eri lähteistä. 

Ensimmäinen kävijäseurantaraportti antoi viitteitä koko sivuston laajasta selaamisesta, 

kun jälkimmäisen kävijäseurantaraportin perusteella vierailijat selasivat enemmän 

sivuston muuttunutta sisältöä. 

 

Jatkossa sivustoa voidaan kehittää toteuttamalla eriasteisia kyselytutkimuksia sivuston 

käyttäjille liittyen sivuston toimintaan ja toiminnallisuuksiin, joiden pohjalta sivustoa 

voidaan kehittää entistä enemmän kohderyhmän tarpeita vastaaviksi. Tekniikan 

kehittyessä on asiakkaiden myös mahdollista harkita, voisiko sivustossa käytetyn 

sivupohjan päivittää eri laitteisiin mukautuvaksi eli responsiiviseksi.  



50 

 

 

LÄHDELUETTELO 

 

Boiko, B. (2002). Content management bible. New York, Hungry Minds Inc. ISBN:0-

7645-4862-X. 

 

Eden, Bradford Lee (2006). Content Management Systems.  [online]. Saatavana World 

Wide Webistä: <URL: 

http://site.ebrary.com/lib/tritonia/docDetail.action?adv.x=1&d=all&f00=author&f

01=all&f02=&hitsPerPage=500&p00=eden&p01=Content+Management+System

s&p02=&page=1&id=10120698 >.  pISBN: 9781845449407 

 

Mozilla Developer Network (2014). Firefox Developer Tools. [online]. [siteerattu 

24.3.2014]. Saatavana World Wide Webistä: <URL: 

https://developer.mozilla.org/en-US/docs/Tools >.  

 

Free Software Foundation (2013). The Free Software Foundation (FSF) is a nonprofit 

with a worldwide mission to promote computer user freedom and to defend the 

rights of all free software users. [online]. [siteerattu 15.11.2013] Saatavana World 

Wide Webistä: <URL: https://www.fsf.org/licensing/>. 

 

Hughes, Bob & Mike Cotterell (2006). Software Project Management, Fourth Edition.  

Maidenhead Berkshire, McGraw-Hill Education. ISBN: 978-0-07-710989-9. 

 

Jones, Kyle M. L. et al. (2011). Using Wordpress as a Library Content Management 

System: A Library Technology Report. [online]. [siteerattu 15.10.2013]  Saatavana 

World Wide Webistä:<URL: 

http://site.ebrary.com/lib/tritonia/docDetail.action?adv.x=1&d=all&f00=author&f

01=all&f02=&hitsPerPage=500&p00=jones&p01=Using+Wordpress+as+a+Libra

ry+Content+Management+System&p02=&page=1&id=10477325 >.  ISBN: 978-

0-8389-5831-5. 

 

Joomla (2013).  Joomla tuki, uutiset ja kielitiedostot. [online]. [siteerattu 11.11.2013] 

Saatavana World Wide Webistä: <URL:http://www.joomla.fi>. 

 

Joomla (2014a).  Official Joomla! Project website. [online]. [siteerattu 

1.2.2014].Saatavana World Wide Webistä: <URL:http://www.joomla.org>. 



51 

 

 

 

Joomla (2014b).  Access Control List Tutorial. [online]. [siteerattu 12.2.2014]. 

Saatavana World Wide Webistä: <URL: 

http://docs.joomla.org/J2.5:Access_Control_List_Tutorial>. 

 

Joomla (2014c). The Joomla! Extensions Directory. [online]. [siteerattu 12.2.2014]. 

Saatavana World Wide Webistä: <URL: http://extensions.joomla.org/>. 

 

Joomla  (2014d).  Technical Requirements. [online]. [siteerattu 13.1.2014]. Saatavana 

World Wide Webistä: <URL: http://www.joomla.org/technical-

requirements.html>. 

 

Joomla  (2014e). Installing Joomla. [online]. [siteerattu 8.1.2014]. Saatavana World 

Wide Webistä: <URL: http://docs.joomla.org/J3.2:Installing_Joomla >.  

 

Jung, Jaeyeon et al. (2013). DNS Performance and the effectiveness of caching.[online]. 

[siteerattu 31.10.2013]. Saatavana World Wide Webistä: 

<URL:http://nms.lcs.mit.edu/papers/dns-ton2002.pdf>. 

 

Koordinaatti.fi (2014).  Nuorten tieto- ja neuvontapalvelut Suomessa. [online]. 

[siteerattu 17.3.2014]. Saatavana World Wide Webistä: <URL: 

http://www.koordinaatti.fi/fi>. 

 

Microsoft Developer Network (2013). Server Clustering. [online]. [siteerattu 

19.10.2013]. Saatavana World Wide Webistä: 

<URL:http://msdn.microsoft.com/en-us/library/ff649250.aspx>. 

 

Murali, Chemuturi, Thomas M. Cagley, Jr. (2010). Mastering Software Project 

Management: Best Practises, Tools and Techniques. [online]. Saatavana World 

Wide Webistä: <URL: 

http://site.ebrary.com/lib/tritonia/docDetail.action?adv.x=1&d=all&f00=author&f

01=all&f02=&hitsPerPage=500&p00=murali&p01=Mastering+Software+Project

+Management%3A&p02=&page=1&id=10520058>.  pISBN: 9781604270341. 

 

Netbeans (2014). Netbeans IDE. [online]. [siteerattu 20.3.2014]. Saatavana World Wide 

Webistä: <URL: https://netbeans.org/>. 



52 

 

 

 

OpenSourceMatters.org (2013). Protecting the financial and legal interests of the 

Joomla Project.  [online]. [siteerattu 15.11.2013]. Saatavana World Wide Webistä: 

<URL:http://www.opensourcematters.org>. 

 

Phillips, Joseph (2011). Project Management for Small Business: A streamlined 

approach from Planning to Completion.  [online]. [siteerattu 7.2.2014]. Saatavana 

World Wide Webistä: <URL: 

http://site.ebrary.com/lib/tritonia/docDetail.action?adv.x=1&d=all&f00=all&f01=

&f02=&hitsPerPage=500&p00=Project+Management+for+Small+Business%3A+

A+streamlined+approach+from+Planning+to+Completion.&p01=&p02=&page=

1&id=10511630> . ISBN-10: 0-8144-1767-1. 

 

Radtke, Angie (2012). Joomla! Templates. [online]. [siteerattu 10.11.2013]. Saatavana 

World Wide Webistä: <URL: http://it-ebooks.info/book/1042>.  ISBN: 978-0-

321-82731-9.  

 

Rahmel, Dan (2013). Advanced Joomla! [online]. [siteerattu 10.11.2013]. Saatavana 

World Wide Webistä: <URL: http://it-ebooks.info/book/2395/>.  ISBN: 978-1-

4302-1628-5. 

 

Rashmi Popli & Naresh Chauhan (2013). Agile Software Development. [online]. 

[siteerattu 24.3.2014]. Saatavana World Wide Webistä: <URL: 

http://www.csjournals.com/IJCSC/PDF4-2/28.pdf />. 

 

Stahl Olivier et al. (2013). Djeen (Database for Joomla!’s Extensible Engine): a 

research information management system for flexible multitechnology project 

administration. [online]. [si