Avaa tiedosto

Tietojärjestelmän kehittäminen
– Case Retkilaskuri.net
Euren, Juhani
2015 Leppävaara
2
Laurea-ammattikorkeakoulu
Leppävaara
Tietojärjestelmien kehittäminen
– Case Retkilaskuri.net
Juhani Euren
Tietojenkäsittelyn koulutusohjelma
Opinnäytetyö
Toukokuu, 2015
3
Laurea-ammattikorkeakoulu
Leppävaara
Tietojenkäsittelyn koulutusohjelma
Tiivistelmä
Juhani Euren
Tietojärjestelmien kehittäminen – Case Retkilaskuri.net
Vuosi
2015
Sivumäärä
28
Toiminnallinen opinnäytetyö toteutettiin Retkilaskuri.net-verkkopalvelun toimeksiantona.
Toimeksiantoa lähdettiin toteuttamaan ideointivaiheella, jonka jälkeen tehtiin vaatimusmäärittely yhdessä Retkilaskuri.net-verkkopalvelun edustajan kanssa. Toteutusvaiheessa järjestelmästä tuotettiin vaatimusmäärittelyn mukainen prototyyppi, joka validoitiin haastattelemalla
toimeksiantajaa.
Opinnäytetyön tavoitteena oli toteuttaa toimiva järjestelmäprototyyppi Reppu-sovelluksesta
retkilaskuri.net-verkkopalvelulle. Edeltävä versio sovelluksesta on toteutettu PHP- ja SQL-tekniikoita hyödyntäen ja jonka suurimmat ongelmat olivat palvelun hitaus sekä dokumentaation
puute. Toimeksiantaja asetti reunaehdoksi sen, että prototyyppi toteutetaan Drupal-sisällönhallintajärjestelmän päälle, Ubercart-moduulia hyödyntäen.
Opinnäytetyön toiminnallinen osio on retkilaskuri.net tietojärjestelmän kehittämishanke,
jonka viitekehykseksi tunnistettiin tietojärjestelmien kehittäminen sekä siihen liittyvä vaihejako. Teoreettista pohjaa tietojärjestelmien kehittämisestä hyödynnetään toteutusosiossa,
jonka tavoitteena oli tuottaa Retkilaskuri.net-verkkopalvelulle prototyyppi Reppu-sovelluksesta.
Asiasanat: Drupal-sisällönhallintajärjestelmä, Retkilaskuri.net-verkkopalvelu, Ubercart-moduuli
4
Laurea University of Applied Sciences
Leppävaara
Degree Programme in Business Information Technology
Abstract
Juhani Euren
Information Systems Development – A Case Study of Retkilaskuri.net
Year
2015
Pages
28
This functional thesis was executed as a commission, which was ordered by Retkilaskuri.net
online service. The work started with an ideation phase leading to requirement elicitation,
which was conducted in cooperation with the representative of Retkilaskuri.net online service. In the implementation phase, a prototype of the system was constructed according to
the specification. The Prototype was validated based on an interview with the commissioner.
The aim of this thesis was to implement a functional system prototype of Reppu application
for Retkilaskuri.net online service. The previous version of the system was implemented by
utilizing PHP- and SQL techniques. The biggest challenges in relation to the previous techniques are slowness of the service and lacking of documentation. The Commissioner set the
precondition for the platform, which is utilization of Drupal CMS in conjunction with Ubercart-module.
The Functional part of the thesis is the development project of Retkilaskuri.net information
system. To be able to implement the project, the development of the information systems
was recognized as essential theoretical framework. By applying the presented theoretical
framework to the functional phase, it was possible to implement the functional prototype of
Reppu application for the Retkilaskuri.net online service.
Keywords: Drupal, Retkilaskuri.net Service, Ubercart-module
5
Sisällys
1
2
Johdanto ............................................................................................. 6
1.1
Opinnäytetyön rajaukset .................................................................. 6
1.2
Opinnäytetyön menetelmät .............................................................. 6
Tietojärjestelmien kehittäminen ............................................................... 7
2.1
Tietojärjestelmien kehittämisen ongelmat ja niiden hallinta ..................... 8
2.2
Tietojärjestelmien kehittämisen vaiheet .............................................. 8
2.2.1 Esitutkimus .......................................................................... 8
2.2.2 Vaatimusmäärittely ................................................................ 9
2.2.3 Järjestelmäanalyysi ................................................................ 9
2.2.4 Suunnittelu .......................................................................... 9
2.2.5 Toteutus ........................................................................... 10
2.2.6 Testaus ............................................................................. 10
2.2.7 Käyttöönotto ...................................................................... 11
2.2.8 Ylläpito ............................................................................. 11
2.3
Tietojärjestelmän elinkaarimallit ..................................................... 12
2.3.1 Vesiputousmalli ................................................................... 12
2.3.2 Prototyyppilähestymistapa ..................................................... 13
2.3.3 Spiraalimalli ....................................................................... 14
3
Retkilaskuri.net-verkkopalvelu ................................................................ 15
3.1
Reppu-projektin elinkaari .............................................................. 16
3.2
Drupal ...................................................................................... 16
3.3
Ubercart ................................................................................... 17
3.4
Repun määritykset ....................................................................... 17
3.5
Palveluun kirjautuminen ................................................................ 18
3.6
Repun kerääminen ja tallennus ........................................................ 19
3.7
Oman repun muokkaus .................................................................. 19
3.8
Kaikkien reppujen selaus ja muokkaus ............................................... 21
3.9
Omien tuotteiden lisääminen .......................................................... 21
4
Haastattelu ja tutkimus ......................................................................... 23
5
Yhteenveto ........................................................................................ 24
Lähteet .................................................................................................... 25
Kuvat ....................................................................................................... 26
Liitteet ..................................................................................................... 27
6
1
Johdanto
Retkilaskuri.net-verkkopalvelu on kohdennettu luonnossa liikkuville ja matkustaville ihmisille,
jotka joutuvat miettimään kantamustensa painoa sekä käytettävyyttä. Retkilaskuri.net-verkkopalvelu on pääsääntöisesti tehty PHP- ja SQL-koodia käyttäen. Retkilaskuri.net-verkkopalvelu on aloitettu alun perin tekemään vuonna 2008 ja sitä on kehitetty jatkuvasti. Retkilaskurin ongelmaksi on muodostunut palvelun hitaus sekä dokumentaation puute.
Opinnäytetyöni voidaan mieltää kolmeen osaan jotka ovat teoria-, toteutus- ja loppuvaihe.
Opinnäytetyön teoriaosuuden tavoite on tuottaa dokumentaatiota tietojärjestelmien kehittämisen vaiheista ja elinkaarivaihtoehdoista. Opinnäytetyön toteutusosassa Retkilaskuri.netverkkopalvelun ostoskorin eli verkkopalvelussa kutsutun Reppu-sovelluksen prototyyppi toteutetaan Drupal-sisällönhallintajärjestelmän Ubercart-moduulilla, Retkilaskuri.net-verkkopalvelun kanssa yhteistyössä tehtyjen määrityksien mukaan. Opinnäytetyössä havainnollistetaan
prototyyppiä kuvakaappauksilla. Mahdolliset haasteet ja ratkaisut prototyypin toteutuksesta
dokumentoidaan jatkokehitystä varten. Opinnäytetyön yhteenvetovaiheessa pohditaan omaa
oppimista, saatuja tuloksia sekä pohditaan Retkilaskuri.net-verkkopalvelun jatkokehitystä.
1.1
Opinnäytetyön rajaukset
Opinnäytetyöhön tehtiin kaksi rajausta.
Retkilaskuri.net-verkkopalvelun ostoskorista eli Reppu-sovelluksesta tuotetaan prototyyppi,
Drupal-sisällönhallintajärjestelmässä toimivalla Ubercart-moduulilla. Koska verkkopalvelun
edustaja on määritellyt, että Retkilaskuri.net verkkopalvelun siirto tullaan tekemään Drupalsisällönhallintajärjestelmällä toimivaksi kokonaisuudeksi.
Opinnäytetyöstä on rajattu ohjelmointi ulkopuolelle, jonka vuoksi Ubercart-moduulin ohjelmakoodin mahdollinen muokkaus rajataan tästä opinnäytetyön ulkopuolelle. Mikäli Ubercartmoduulin ominaisuus vaatii ohjelmakoodin muokkausta, niin toiminto sivuutetaan opinnäytetyöstä ja asiasta tehdään lyhyt dokumentointi jatkokehitystä varten.
1.2
Opinnäytetyön menetelmät
Opinnäytetyön teoriaosuudessa käsiteltiin tietojärjestelmien kehittämisen vaiheita ja tietojärjestelmän kolmea elinkaarivaihtoehtoa, jotka olivat vesiputousmalli, prototyyppilähestymistapa ja spiraalimalli. Opinnäytetyössä käytettiin prototyyppilähestymistapaa, koska tiedettiin, mitä Retkilaskuri.net-verkkopalvelussa tulisi olla, mutta sitä ei vielä ollut aloitettu Retkilaskuri.net-verkkopalvelun toimesta toteuttamaan eikä havainnollistamaan. Verkkopalvelulla
7
ei ollut tarkkaa tietoa, miten halutut ominaisuudet teknisesti toteutettaisiin, mutta kuitenkin
haluttiin toteutuksen tapahtuvan Drupal-sisällönhallintajärjestelmällä. Drupal-sisällönhallintajärjestelmän valintaan vaikutti sen ominaisuudet verrattuna muihin samankaltaisiin ohjelmiin(Alexander, K. 2014) ja varsinkin Ubercart-moduuli, sekä Retkilaskuri.net-verkkopalvelun
edustaja, joka halusi toteutuksen tapahtuvan Drupal-sisällönhallintajärjestelmällä. Edustaja
toivoi nähtäväksi Drupal-sisällönhallintajärjestelmällä toteutetun prototyypin mahdollisimman
nopeasti, jonka vuoksi päädyttiin prototyyppilähestymistapaan.(Pohjonen 2002, 26-43.) Teoriaosuudessa myös esiteltiin Drupal-sisällönhallintajärjestelmä(Burge & McCourt 2013, 3-4.) ja
Ubercart-moduuli(What is Ubercart 2012).
Toteutusvaiheessa implementoidaan Reppu-sovelluksen toiminnot sekä havainnollistetaan
Reppu-sovellus tekstein ja kuvakaappauksin.
Opinnäytetyön yhteenvetovaiheessa kerrotaan Reppu-projektin saaduista tuloksista sekä Retkilaskuri.net-verkkopalvelun jatkokehityksestä.
Drupal-sisällönhallintajärjestelmän opiskeluun käytetään Drupal-oppimateriaaleja. Esimerkiksi, drupal.org-foorumia, Drupal-kirjallisuutta ja lähdeluettelosta löytyvää Shreves, R. &
Dunwoodie, B. 2011 kirjoittamaa erinomaista kirjaa.
2
Tietojärjestelmien kehittäminen
Tietojärjestelmien kehittämisen keskeinen tavoite on uusien ja vanhojen tietojärjestelmien
kehittäminen. Tietojärjestelmien kehittämisen osa-alueet eivät ole nykypäivänä vain yksittäisien IT-ammattilaisien työtä, kuten aikaisemmin miellettiin, vaan tietojärjestelmien kehittäminen tapahtuu yleensä aina ryhmätyönä. Tietojärjestelmien kehittämiseen osallistuvat
usein myös käyttäjät ja työntilaajat(Pohjonen 2002, 15-16).
Tietojärjestelmä usein ajatellaan ennalta määritellyksi kokonaisuudeksi, joka muodostuu eri
toiminnoista muodostaen tietojärjestelmän. Koska tietojärjestelmät ovat läsnä monesti huomaamatta, kuten esimerkiksi ruokakaupassa asioidessamme. Kun maksamme ostoksia ruokakaupassa, niin kassakoneessa on tietojärjestelmä. Järjestelmään on syötetty eri ruokien hintoja, joita haetaan tietojärjestelmästä, jonka tietojen mukaan hinta muodostuu. Tämän jälkeen kassajärjestelmä osaa veloittaa käyttämästämme kortista oikean summan. Tietojärjestelmät yleistyvät sekä laajentuvat ja keräävät enemmän tietoa kuluttajista. Tämän vuoksi on
entistä tärkeämpää huomioida tietojärjestelmien kehittämisessä niiden tietoturvallisuus sekä
keräämien tietojenvalvonta(Paananen 2005, 338-339).
8
2.1
Tietojärjestelmien kehittämisen ongelmat ja niiden hallinta
Tietojärjestelmien kehittämisessä toistuu usein samankaltaisia ongelmia, joita kutsutaan nimellä ohjelmistokriisi. Ohjelmistokriisi voidaan jakaa karkeasti neljään ryhmään. Hankkeiden
hallinta, tuottavuus ja kustannukset, laadulliset ongelmat ja ylläpito(Paananen 2005, 341).
Usein ohjelmakriisiksi kutsutut ongelmat johtuvat siitä, että isoja ja monimutkaisia toimintoja
suorittavat tietojärjestelmät ovat haasteellisia rakentaa tarkasti määritettyjen ehtojen mukaisesti. Tietojärjestelmien rakentamisen tekee haasteelliseksi myös kilpailu, jonka vuoksi
tietojärjestelmä tulisi tuottaa nopealla aikataululla, jolloin laatu vaarantuu ja tietojärjestelmän epäonnistumisen riski kasvaa. Tietojärjestelmien kehittämisessä on hyvin yleistä, että
kehitetyssä järjestelmässä on vielä virheitä, kun otetaan jo käyttöön ja virheitä korjataan
lennosta. Tietojärjestelmien kehittämisessä toisinaan ongelmatilanteita muodostuu myös
siitä, että tekniikka ei ole tunnettua(Paananen 2005, 340-342).
2.2
Tietojärjestelmien kehittämisen vaiheet
Tietojärjestelmien kehittäminen on systemaattista toimintaa, jossa tehtävät tehdään järjestyksessä, noudattaen kurinalaisesti annettuja tehtäviä, kunnes siirrytään seuraavaan vaiheeseen. Seuraavan tehtävän tietopohjana ja määrittäjänä, toimii edellinen vaihe, kuten kuva 2
vesiputousmallista osoittaa. Peräkkäisiä vaiheita tietojärjestelmän kehittämisessä kutsutaan
tietojärjestelmän elinkaareksi, joita ovat esitutkimus, vaatimusmäärittely, järjestelmäanalyysi, suunnittelu, toteutus, testaus, käyttöönotto ja ylläpito(Pohjonen 2002, 26,). Vaihejaolla
voidaan erimerkiksi määrittää tehtäviä, kuten tietojärjestelmän tehtävät, ajoitukset, riippuvuudet, kehittämishankkeen tarkistuspisteet(Paananen 2005, 344).
2.2.1
Esitutkimus
Tietojärjestelmän kehittämisen vaiheista ensimmäisenä on esitutkimus, jonka tarkoituksena
on kartoittaa tietojärjestelmän tarve ja mahdolliset haasteet. Selvityksestä tulisi selvitä ainakin, että kuinka tietojärjestelmä tulisi toteuttaa, mitä yritetään ratkaista ja millä vaatimuksilla. Esitutkimuksessa ei kuitenkaan tarkastella toteutusta eikä teknisiä ratkaisuja tai niiden
rajauksia(Paananen 2005, 344). Esitutkimuksen tulisi tuottaa esitutkimusraportti ainakin kehityshankkeen organisaation nykytilasta, ongelmien kuvaukset jotka järjestelmällä pyritään ratkaisemaan, alustavat tavoitteet ja rajauksien määritykset, kehittämistavoitteiden määritys
sekä alustava suunnitelma tietojärjestelmän läpiviemiseksi. Esitutkimus on tietojärjestelmän
kehittämisessä alun tärkein asia, koska esitutkimuksen perusteella päätetään tietojärjestelmän kehittämisen aloittamisesta tai hylkäämisestä. Esitutkimuksen tuotoksena syntyy erilaisia
materiaaleja ja tietopohjia, joita pystyy hyödyntämään myöhemmissä kehitysvaiheissa tai toisien tietojärjestelmien rakentamisen tietopohjana(Pohjonen 2002, 27).
9
2.2.2
Vaatimusmäärittely
Hyväksytyn esitutkimuksen jälkeen siirrytään toteuttamaan vaatimusmäärittelyä. Vaatimusmäärittely voidaan jakaa kahteen toiminnalliseen ryhmään. Eli toiminnallisiin ja ei-toiminnallisiin vaatimuksiin. Toiminnalliset vaatimukset määrittelevät sen, miten järjestelmän halutaan toimivan eri tilanteissa. Esimerkiksi voiko Retkilaskuri.net-verkkopalvelua käyttää ilman
kirjautumista sivustolle. Ei-toiminnallisilla määrityksillä rajataan tilanteet ja ehdot sille, että
järjestelmä toimii määritetyllä tavalla. Esimerkiksi millä selaimilla Retkilaskuri.net-verkkopalvelu tulee toimimaan. Vaatimusmäärittelyssä sidosryhmien järjestelmälle asettamat vaatimukset dokumentoidaan, ottamatta vielä kantaa tekniseen toteutukseen. Kaikkia sidosryhmien asettamista vaatimuksista on usein hankala todentaa, koska ei ole vain yhtä oikeaa tapaa kerätä vaatimuksia, joka takaisi kattavan lopputuloksen. Tämän takia on hyvä käyttää
vaatimuksien kartoittamiseen erilaisia menetelmiä. Kuten Pohjonen (2002, 28-29) kirjassa toteaakin, että yleisimpiä vaatimuksien keräystapoja on haastattelut, erilaiset benchmarkingit
ja markkinointitutkimukset. Vaatimuksien kartoittamisessa tulee aina muistaa, että vaatimusmäärittelyn tulisi olla selkeä ja tarkasti tulkittavissa, koska vaatimusmäärittelyn muuttaminen
jälkeenpäin on hankalaa sekä kallista(Pohjonen 2002, 29-30).
2.2.3
Järjestelmäanalyysi
Vaatimusmäärittelyn jälkeen on vuorossa toteutettavan järjestelmän määrittely, eli järjestelmäanalyysi. Järjestelmäanalyysillä pyritään analysoimaan esitutkimuksessa sidosryhmien asettamia vaatimuksia, mitä järjestelmän tulisi tehdä, toteutuksesta riippumatta. Järjestelmäanalyysin tavoite on myös tuottaa looginen kuvaus järjestelmästä sekä sidosryhmistä. Vaihetta
kutsutaan toiminnalliseksi määrittelyksi(Paananen 2005, 344). Pohjonen(2002, 32) toteaa,
että järjestelmäanalyysiin ja sen tuotosten laatuun ja yksiselitteisyyteen tulisi kiinnittää erityistä huomiota, koska myöhäisemmät kehitysvaiheet pohjautuvat tehdyn tuotoksen tiedoille.
Pohjonen(2012, 31-32) kirjassaan toteaa myös, että toiminnallisen määrittelyn tulisi sisältää
vähintään dokumentaation järjestelmän tarkoituksesta, ympäristöstä, toiminnasta, käyttäjistä
ja järjestelmän rajoituksista karkealla tasolla.
2.2.4
Suunnittelu
Määrittelyn jälkeen on vuorossa suunnittelu. Suunnitteluvaiheessa tarkoituksena on tehdä
tarkka suunnitelma ja muuntaa aiempien vaiheiden tutkimus sekä määrittelyt järjestelmän
tekniseksi määrittelyksi. Teknisessä määrittelyssä järjestelmä kuvataan niin tarkasti kuin
mahdollista, koska toteutusvaihe pitää olla mahdollinen teknisen määrittelyn pohjalta(Paananen 2005, 344-345). Suunnittelussa käytetään pääsääntöisesti kahta vaihtoehtoa, jotka ovat
10
arkkitehtuuri- ja moduulisuunnittelu. Arkkitehtuurisuunnittelussa määritellään järjestelmän
yleinen rakenne ja järjestelmä pyritään jakamaan mahdollisimman moniin pieniin moduuleihin ja mahdollisimman vähäisillä yhteyksillä toisiinsa. Moduulien välisiin yhteyksiin tulisi kiinnittää erityistä huomiota, koska liialliset yhteydet hankaloittavat ylläpito- ja testaamisvaihetta(Pohjonen(2002, 32). Moduulisuunnittelussa moduulin sisältö suunnitellaan ja siinä tulisi
pyrkiä mahdollisimman pieneen kokoon moduulin hallittavuuden vuoksi (Pohjonen 2002, 33).
Pohjosen(2002, 33) mukaan teknisen määrittely dokumentaatiossa tulisi olla vähintään kuvaus
järjestelmän tarkoituksesta, sovellusalueesta ja järjestelmän osuudesta, laitteisto ja ohjelmistoympäristöstä, toteutuksen reunaehdoista, vuorovaikutuksesta, arkkitehtuurista, moduuleista ja alijärjestelmästä, toteutuksen määrittelyt, kuvaukset vaihtoehdoista tai hylätyistä
ratkaisuista.
2.2.5
Toteutus
Suunnittelu vaiheen jälkeen on toteutus. Toteutusvaihe on suhteellisen suoraviivaista tekemistä teknisiä apuvälineitä tai ohjelmointikieliä apuna käyttäen, aikaisempien vaiheiden määrityksien ja suunnitelmien mukaan. Aikaisemmat vaiheet olivat esitutkimus, määritykset ja
suunnitelma. Toteutuksen ehkä haasteellisimpia tilanteita on huomioida järjestelmän ylläpidettävyys sekä huomioida toiseen järjestelmään siirtäminen(Pohjonen 2002, 35). Järjestelmien kehittämisessä on tärkeää ymmärtää suunnittelun ja toteutuksen vaiheet, jotta järjestelmä voidaan toteuttaa toimivaksi suunnitelman mukaisesti(Paananen 2005, 345).
2.2.6
Testaus
Toteutuksen jälkeen siirrytään testausvaiheeseen. Testauksen tarkoitus on löytää virheet ja
ongelmat järjestelmästä. Testaus tapahtuu yleensä monessa kerroksessa V-mallin (kuva 1)
mukaisesti. V-mallin mukaisesti järjestelmän testaus jaetaan kolmeen osaan, jotka ovat: Moduuli-, integrointi-, ja järjestelmätestaus. Moduulitestauksessa vikoja etsitään yksittäisistä
moduuleista, integrointitestauksessa vikoja etsitään rajapinnoista ja järjestelmätestauksessa
etsitään virheitä koko järjestelmästä ja sen toiminnoista(Paananen 2005, 345). Testauksessa
suoritettavat toimenpiteet eivät saa kohdistua ohjelmointiin, vaan aikaisempiin määrittelyvaiheen ja suunnitteluvaiheen dokumentointeihin. Testauksessa tulee aina huomioida, että testauksella todennetaan mahdolliset virheet, mutta ei niiden puuttumista. Teoriassa on mahdollista testauksella löytää järjestelmästä kaikki virheet, mutta käytännössä tämä ei ole mahdollista. Järjestelmässä saattaa olla tuntemattomia virheitä tai ongelmia, joita ei voi järjestelmän tai tietovirtojen koon vuoksi testauksessa havaita(Pohjonen 2002, 35-36).
11
Kuva 1 Testauksen V-malli
2.2.7
Käyttöönotto
Testauksen jälkeen on vuorossa järjestelmän käyttöönotto. Uusien järjestelmien käyttöönottoon liittyy monia riskejä, joihin pitää kiinnittää erityistä huomiota. Näitä riskejä ovat esimerkiksi tiedonhallinnan eri osa-alueet, kuten tietokannat ja tiedostot. Huomioon tulee ottaa
myös toiset järjestelmät, joiden kanssa uuden järjestelmän tulee toimia sekä käyttäjien ja
ylläpitäjien kouluttaminen tulee huomioida. Käyttöönoton suunnittelussa tulee huomioida
myös tekniset vaatimukset sekä tekniset muutokset. Käyttöönotossa tulee ottaa huomioon
monia asioita, mutta kuitenkin Pohjonen(2002,37) kirjassaan toteaa, että uudesta järjestelmästä vähimmäisvaatimuksena täytyy olla ajantasainen käyttöohjeistus saatavilla.
2.2.8
Ylläpito
Käyttöönoton jälkeen on ylläpitovaihe, joka on elinkaaren pisin vaihe. Ylläpitovaihe alkaa
siitä, kun järjestelmä on toimintakuntoinen ja on toiminnassa. Ylläpitovaihe loppuu vasta siihen, kun katsotaan sen tuleen elinkaarensa päähän. Ylläpitovaiheeseen voi sisältyä monia eri
tehtäviä, kuten järjestelmän toimintakunnossapito eli järjestelmäpäivitykset, laitteistopäivitykset tai järjestelmän jatkokehittäminen. Ylläpitovaiheessa järjestelmien muuttaminen on
usein hyvin haastavaa puuttuvan dokumentaation vuoksi. Tämän vuoksi järjestelmän kaikki
vaiheet tulisi dokumentoida esitutkimuksesta lähtien tarkasti ylläpitovaihe huomioon ottaen.
Ylläpitovaihe huomioiden ja kattava dokumentaatio säästäisi ylläpitoon meneviä resursseja.
12
Ylläpitoon menee Pohjosen(2012, 38) mukaan 70 % järjestelmän resursseista, joten laadukkaalla ja kattavalla dokumentaatiolla olisi mahdollista toimia huomattavasti kustannustehokkaammin(Pohjonen 2002, 37-38).
2.3
Tietojärjestelmän elinkaarimallit
Elinkaari tunnistetaan myös ohjelmistoprosessina ja kokonaisvaltaisena mallintamiskohteena.
Tietojärjestelmän elinkaarimalleissa vaiheet kuvataan toteutusjärjestyksessä sekä vaiheiden
pitää sisältää kaikki tärkeimmät järjestelmän osat. Aina tulisi kuitenkin muistaa, että kyseessä on malli, jonka mukaan olisi suositeltavaa edetä. Kyseessä ei kuitenkaan ole sääntö tai
määräys, jonka mukaan olisi ehdotonta edetä. Tämä tulisi aina huomioida ohjelmistoprosessissa, koska valittu malli ei välttämättä ole parhain juuri kyseisen organisaation tarpeisiin(Pohjonen 2002, 39).
2.3.1
Vesiputousmalli
Vesiputousmalli on eniten käytetty ja vanhin elinkaarimalli. Winston W. Royce 1970 julkaisemassaan artikkelissa(Winston W. Royce. 1970) käsitellään ensimmäistä kertaa vesiputousmallia ja siihen liittyviä toimintatapoja. Artikkeli on edelleen yksi eniten vesiputousmalliin viitatummista lähteistä(Haikala & Mikkonen 2011, 36-37).
Vesiputousmallin ajatus on tehdä vaihe kokonaan valmiiksi ja edetä suoraviivaisesti seuraavaan vaiheeseen Paanasen(2005, 346) kuvan 2 mukaisesti. Järjestelmien kehittäminen sujuu
harvoin niin ideaalisesti, ettei aikaisempiin vaiheisiin tarvitse palata ja kaikki toimisi sekä vastaisi kaikkia vaiheita ensimmäisellä kerralla. Jälkeenpäin vesiputousmallisesti toteutetussa
järjestelmässä on hankalaa ja työläistä korjata ilmenneitä puutteita, koska usein vaatisi muutoksia mahdollisesti kaikkiin aikaisempiin vaiheisiin vesiputousmallisesti Pohjonen(2002, 40).
13
Kuva 2 Vesiputousmalli
2.3.2
Prototyyppilähestymistapa
Vesiputousmallin jälkeen on kehitetty erilaisia kehitysmalleja. Yksi näistä kehitysmalleista on
prototyyppilähestymistapa. Prototyyppilähestymistapa on hyvä tapa havainnollistaa tilaajalle
järjestelmää prototyyppien kautta, kun tilaajalla on vaikeuksia määritellä järjestelmän toimintoja. Myös silloin prototyyppinenlähestymistapa on hyvä, kun tilaaja haluaa päästä testaamaan järjestelmää ja sitä kautta tehdä havaintoja tarpeestaan(Paananen 2005, 346).
Prototyyppilähestymistavan (kuva 3) puutteiksi voidaan laskea resurssien suuri käyttö, koska
järjestelmän kehittäminen tapahtuu tilaajan palautteen ja hyväksynnän kautta. Tällöin karkeita protoja voidaan joutua muuttamaan useita kertoja ja joiden pohjalta järjestelmä rakennetaan lopulliseen muotoon. Joissain tilanteissa on huomattu, että prototyyppien karkeuden
vuoksi ongelmia ei ole tunnistettu ennen kuin ne ovat tulleet ilmi järjestelmän toteutusvaiheessa(Pohjola 2002, 41-42).
14
Kuva 3 Prototyyppilähestymistapa
2.3.3
Spiraalimalli
Spiraalimallin (kuva 4) keskeinen ajatus on toistuvuus ja toisia elinkaarimalleja tarkempi riskien jatkuva analysointi ja niiden huomiointi prosessin aikana. Spiraalimallissa kuljetaan kehää pienemmästä kehästä isompaan kehään. Jokaisella kehällä tarkistetaan osa-alueet uudelleen, eli mitä isommalla kehällä ollaan, sen tarkemmin osa-alue tarkistetaan. Osa-alueet voidaan jakaa neljään lohkoon joita toistetaan niin kauan, että järjestelmä todetaan valmiiksi
tai riskit kasvavat niin suuriksi, että projekti lopetetaan. Spiraalimallin lohkot ovat suunnittelu, riskianalyysi, tuotanto sekä arviointi.(Pohjonen 2002, 42-43).
15
Kuva 4 Spiraalimalli
3
Retkilaskuri.net-verkkopalvelu
Retkilaskuri.net-verkkopalvelu on kohdennettu luonnossa liikkuville ja matkustaville ihmisille,
jotka joutuvat miettimään kantamustensa painoa sekä omaa energiatarvetta. Retkilaskuri.net-verkkopalvelu on pääsääntöisesti tehty php- ja sql-kieliä käyttäen. Retkilaskuri.netverkkopalvelu on aloitettu alun perin tekemään vuonna 2008 ja sitä on kehitetty jatkuvasti.
Palvelun ongelmiksi ovat muodostuneet koodin raskaudesta johtuva hitaus sekä muutosten toteuttamisen hitaus. Ongelmien takia Retkilaskuri.net-verkkopalvelu on päätetty siirtää Drupal-sisällönhallintajärjestelmälle.
Opinnäytetyön toteutusosassa esitellään Reppu-sovelluksen toteutettu prototyyppi kuvakaappauksin määritysten mukaan. Tavoitteena on myös tehdä prototyypistä dokumentaatio, jonka
pohjalta retkilaskuri.net-verkkopalvelun Reppu-sovellusta olisi mahdollista jatkojalostaa havaintojen pohjalta. Tarkoitus ei ole tehdä valmista tuotetta, koska opinnäytetyössä ja sen toteutuksessa käytetään prototyyppilähestymistapaa. Prototyyppilähestymistavalla tekemisen
toteutustapa on tehdä prototyyppejä ja niiden pohjalta kehittää järjestelmää annetun palautteen mukaan. Prototyypit ovat hyvin karkealla tasolla esitettyjä, jotka harvoin siinä mallissa
toteutetaan. (Pohjola 2002, 41-42).
16
3.1
Reppu-projektin elinkaari
Tässä kappaleessa kuvataan Reppu-projektin elinkaari, johon kuuluu esitutkimus, vaatimusmäärittely, järjestelmäanalyysi, suunnittelu, toteutus, testaus, käyttöönotto ja ylläpito.
Reppu-projektin ulkopuolelle määriteltiin kolme elinkaaren vaihetta. Vaiheet olivat esitutkimus, käyttöönotto ja ylläpito. Esitutkimus määriteltiin projektin ulkopuolelle, koska Retkilaskuri.net-verkkopalvelun edustaja oli päättänyt ennen projektin alkua, että ”reppu” toteutetaan Ubercart-moduulia muokaten. Käyttöönotto ja ylläpito rajattiin, koska tarkoitus oli
tehdä ensimmäinen prototyyppi, ei käyttöönotettavaa verkkopalvelua. Reppu-projektissa ei
myöskään keskitytty visuaalisiin tai teknisiin ominaisuuksiin kuten miten Reppu-sovellus skaalautuu eri selaimilla.
Reppu-projekti lähti käyntiin Reppu-sovelluksen määrittelystä ja suunnittelusta. Reppu-projektin alussa oli Retkilaskuri.net-verkkopalvelun edustaja, eli työntilaaja päättänyt julkaisujärjestelmän ja Reppu-sovelluksen teon Ubercart-moduulia muokaten. Määritykset oli edustajan puolesta listattu koko Retkilaskusi.net-verkkopalvelun määrittelyyn(liite 1). Yhdessä
Retkilaskuri.net-verkkopalvelun edustajan kanssa pohdimme, mitkä olivat Reppu-sovelluksen
tärkeimmät ominaisuudet ja siitä muodostui viisikohtainen määritys (kuva 6). Verkkopalvelussa on yhteensä 20 määritystä(liite 1). Reppu-projektissa ei ollut tarkoitus miettiä, mikä selain näyttää sivuston oikein, vaan oli tarkoitus saada Reppu-sovellustoimimaan asetettujen tavoitteiden mukaan, koska kyseessä oli ensimmäinen prototyyppi.
Reppu-projektin toteutus ja testaus oli suoraviivaista toimintaa. Tiesin miten Reppu-sovelluksen tuli toimia, koska määritykset päätettiin yhteistyössä Retkilaskuri.net-verkkopalvelun
edustajan kanssa. Reppu-sovelluksen piti pystyä tallentamaan palveluun, ladata, nimetä,
muokata ja käyttäjien piti pystyä lisäämään myöskin tuotteita palveluun. Toteutuksesta ja tuloksista on kerrottu tarkemmin opinnäytetyön kappaleissa 3.5 - 3.9. Reppu-sovellusta testattiin kokeilemalla kyseisiä toimintoja niiden valmistuttua ja vertailemalla niitä Reppu-projektin viisi kohtaiseen määritykseen (kuva 6). Osa testauksesta suoritettiin yhteistyössä Retkilaskuri.net-verkkopalvelun edustajan kanssa.
3.2
Drupal
Drupal on sisällönhallintajärjestelmä, jonka ensimmäisen version kehitti Belgialainen Dries
Buytaert. Drupal on tehty PHP-ohjelmointikielellä ja perustuu avoimeen lähdekoodiin. Drupal
on lisenssimaksuton(Burge & McCourt 2013, 3-4.). Drupal-sisällönhallintajärjestelmää kehitetään aktiivisesti ympäri maailmaa ja sitä on tähän menneessä kehittänyt eri yhteisöjen kautta
17
yli miljoona käyttäjää ja kehittäjää ja kehitys jatkuu edelleen. Drupal-sisällönhallintajärjestelmän yksi vahvuuksista on se, että Drupal tukee uusimpia ja yleisimpiä teknologioita, mitä
web-pohjaisissa sivustoissa voidaan käyttää(Drupal.org 2015).
3.3
Ubercart
Ubercart on moduuli, joka asennetaan Drupal-sisällönhallintajärjestelmään(What is Ubercart
2012). Ubercart on aluksi hyvin yksinkertaisen näköinen, kuten Retkilaskuri.net-verkkopalveluun asennetusta Ubercart-moduulista otettu kuvakaappaus havainnollistaa (kuva 5). Opinnäytetyössä muokataan Ubercart-moduulista prototyyppi repusta määrityksien mukaan.
Kuva 5 Ubercart
3.4
Repun määritykset
Reppu-sovelluksen toiminnoista toteutettiin määrittely, yhteistyössä Retkilaskuri.net-verkkopalvelun kanssa. Määrittelyn mukaan Reppu-sovelluksesta toteutettiin myöhemmin prototyyppi. Repun määrittely muodostui viisi kohtaa (kuva 6). Rekisteröityneen käyttäjän pitää
pystyä valitsemaan tuotteita ja tallentamaan ne omaksi repuksi. Rekisteröityneen käyttäjän
pitää pystyä nimeämään reppu halutessaan. Rekisteröityneen käyttäjän pitää pystyä selaamaan kaikkia reppuja ja halutessaan muokata reppujen sisältöä, kuitenkaan poistamatta alkuperäistä. Rekisteröityneen käyttäjän tulisi pystyä lisäämään uusia tuotteita palveluun.
18
Repun määritykset
Teht.Nro
Tehtävän kuvaus
1
Repun tallentaminen palveluun
2
Repun nimeäminen
3
Tallennettujen reppujen selaus
4
Käyttäjän mahdollista muokata reppujen sisältöä
5
Käyttäjän mahdollista lisätä tuotteita palveluun
Kuva 6 Repun määritys
3.5
Palveluun kirjautuminen
Käyttäjän täytyy olla rekisteröitynyt Retkilaskuri.net-verkkopalveluun, jotta hän voi käyttää
Retkilaskuri.net-verkkopalvelun toimintoja hyödykseen. Mikäli käyttäjällä ei ole tunnuksia,
Hänen tulee sellaiset luoda. Muuten käyttäjä ei voi kuin selata sivustoa, käyttämättä Retkilaskuri.net-verkkopalvelun toimintoja. Tunnukset tehdään itse ja järjestelmä lähettää tunnuksista tiedon käyttäjän ilmoittamaan sähköpostiin. Käyttäjän pitää kuitata sähköpostissa tullut
linkki klikkaamalla sitä, jolloin tunnus aktivoituu automaattisesti. Tämän jälkeen tunnuksilla
pääsee käyttämään verkkopalvelun toimintoja.
Kuva 7 Retkilaskuri.net-verkkopalveluun kirjautuminen
19
3.6
Repun kerääminen ja tallennus
Käyttäjä valitsee halutut tuotteet reppuunsa, jonka jälkeen käyttäjä näkee valitsemansa
tuotteet. Mikäli käyttäjä ei ole tyytyväinen valitsemiinsa tuotteisiin, niin hän voi niitä poistaa
Reppu-sovelluksestaan remove-painikkeella. Mikäli valitut tuotteet ovat oikein, niin niistä
muodostetaan käyttäjälle oma reppu.
Kuva 8 Kerätyt tavarat
3.7
Oman repun muokkaus
Käyttäjä-valikosta valitaan omat reput-valikko. Omat reput-valikko tulostaa näkyviin kaikki
käyttäjän tekemät reput, niille antamat nimet, painot, tavaroiden kappalemäärät sekä repun
katselu ja muokkaus-toiminnot (kuva 9). Reppu esimerkkinä käytetään kuvassa olevaa Kesäreissu 2015-reppua. Reppu on luotu 24.5.2015, kuten luontipäivämäärästä ilmenee.
Kun käyttäjä menee katselemaan haluamaansa reppua ja muokkaa-valikkoon (kuva 10), pystyy
hän sieltä käsin nimeämään reppunsa ja tarkastelemaan reppunsa sisältöä.
20
Kuva 9 Omien reppujen listaus
Kuva 10 Repun sisältö ja nimeäminen
21
3.8
Kaikkien reppujen selaus ja muokkaus
Kaikki reput-valikosta, käyttäjä näkee kaikki palveluun tallennetut reput. Käyttäjä ei pysty
muiden reppuja poistamaan, mutta hän näkee niiden sisällön ja voi muokata niitä itselle klikkaamalla repun numeroa. Toiminnot ovat samat kuin omat reput-valikossa (kuva 10).
Kuva 11 Reppulistan tulostus
3.9
Omien tuotteiden lisääminen
Lisää tuote-valikon alta käyttäjä voi itse lisätä palveluun tuotteita. Tuotteille tulee antaa
nimi, tuotekuvaus, valmistaja, osoite tuotteen valmistajan sivustolle, tuotteen paino ja pituus.
22
Kuva 12 Tuotteen lisääminen
23
4
Haastattelu ja tutkimus
Työn laadun varmistuksessa ja tutkimisessa käytettiin Retkilaskuri.net-verkkopalvelun edustajan haastattelua. Edustajan haastattelun perusteella, pystyttiin toteamaan projektin saavutuksien ja määrityksien toteutuminen onnistuneen tavoitteiden mukaan (kuva 13). Haastattelun tuloksien pohjalta, pystyttiin toteamaan kaksi kehitysehdotusta, jotka tullaan ottamaan
huomioon verkkopalvelun jatkokehityksessä.
Reppu-projekti
Haastateltavana: Retkilaskuri.net-verkkopalvelun
edustaja
Tehtävän kuvaus
Onko toteutus onnistunut
Kyllä
Toteutuuko repun tallentaminen palveluun
X
Voiko repun nimetä verkkopalvelussa
X
Voiko tallennettuja reppuja selata
X
Retkilaskuri.net-verkkopalvelun
edustajan kehitysehdotuksia
Ei
Toimii määrityksien mukaan.
Jatkokehityksessä olisi hyvä tutkia,
miten reppu voidaan ladata omalle
koneelle
Toimii määrityksien mukaan. Ei
kehitysehdotuksia
Toimii määrityksien mukaan. Ei
kehitysehdotuksia
Voiko käyttäjä muokata reppujen sisältöä
X
Toimii määrityksien mukaan. Ei
kehitysehdotuksia
Voiko käyttäjä lisätä tuotteita palveluun
Kuva 13 Reppu-projektin haastattelu
X
Toimii määrityksien mukaan.
Jatkokehityksesä tutkitaan, olisiko
tuotteiden valmistajan tuotteidan
mahdollista myydä verkkopalvelun
kautta
24
5
Yhteenveto
Opinnäytetyössä hyödynnettiin Drupal-sisällönhallintajärjestelmää sekä Ubercart-moduulia,
joka on tarkoitettu verkkokauppojen ostoskoriksi. Tekninen kokemus esiteltyjen järjestelmien
suhteen oli rajallinen, jonka takia osana opinnäytetyön toiminnallista osiota perehdyttiin tarpeellisiin järjestelmiin perusteellisesti.
Opinnäytetyön aluksi kartoitettiin sekä perehdyttiin Drupalin ja Ubercart-moduulin toimintaan, jonka jälkeen toteutettiin määrityksien mukainen prototyyppi. Opinnäytetyön teoreettiseksi viitekehykseksi tunnistettiin tietojärjestelmien kehittäminen ja toiminnallisen osion
tuloksena toteutettiin määrityksien mukainen prototyyppi Reppu-sovelluksesta.
Retkilaskuri.net-verkkopalvelun Reppu-sovelluksen kehittämiseen määriteltiin viisi toimintoa,
jotka opinnäytetyössä toteutettiin onnistuneesti. Reppu-sovelluksessa Retkilaskuri.net-verkkopalvelussa on vielä monia toimintoja määritelty(liite 1), joita tullaan toteuttamaan verkkopalvelun jatkokehityksessä. Validointi osoittaa, että työn tilaaja on tyytyväinen ehjään ja tavoitteet täyttävään prototyyppiin.
Retkilaskuri.net-verkkopalvelussa on vielä monia toimintoja, jotka rajattiin opinnäytetyöstä
pois. Toiminnoista on tehty dokumentaatio, joka löytyy opinnäytetyön lopusta(liite 1). Esimerkiksi yksi toiminnoista on lomakkeiden luominen. Eli Reppu-sovellukseen tullaan kehittämään lomake, jolla käyttäjä voi tulostaa repun sisällön valituilla tavaroilla perinteiselle paperille.
25
Lähteet
Burge, S. & McCourt, C. 2013. Drupal 7 Explained. R.R Donnelley. United State
Haikala, I. & Mikkonen, T. 2011. Ohjelmistotuotannon käytännöt. Talentum Media Oy. Hämeenlinna.
Paananen, J. 2005. Tietotekniikan peruskirja. Docendo. Jyväskylä
Pohjonen, R. 2002. Tietojärjestelmien kehittäminen. Docendo. Jyväskylä.
Shreves, R. & Dunwoodie, B. 2011. Drupal 7 Bible. Wiley Publishing. Canada
Sähköiset lähteet
Alexander, K. 2014. WordPress vs. Drupal: How to Choose a CMS for Your Business. Viitattu
25.4.2015.
http://www.searchenginejournal.com/wordpress-vs-drupal-choose-cms-business/114426/
Drupal.org. 2015 Viitattu 26.4.2014
https://www.drupal.org/about
Retkilaskuri.net Viitattu 1.3.2015
http://www.retkilaskuri.net/index.php
What is Ubercart. 2012 Viitattu 25.4.2015
http://www.ubercart.org/what_is_ubercart
Winston W. Royce. 1970. Managing the development of large software systems. Viitattu
25.4.2015
http://leadinganswers.typepad.com/leading_answers/files/original_waterfall_paper_winston_royce.pdf
Haastattelu- ja muut materiaalit
Retkilaskuri.net-palvelun Edustaja. 2014. Puhelin haastattelut, palaverit ja materiaalit.
Retkilaskuri.net-palvelun Edustaja. Helmikuu2015. Puhelin haastattelut, palaverit ja materiaalit.
Retkilaskuri.net-palvelun Edustaja. Maaliskuu 2015. Puhelin-palaverit ja palaverit.
Retkilaskuri.net-palvelun Edustaja. Huhtikuu 2015. Skype-palaverit.
Retkilaskuri.net-palvelun Edustaja. Toukokuu 2015. Skype-palaverit, puhelin haastattelut, palaverit ja materiaalit.
26
Kuvat
Kuva
Kuva
Kuva
Kuva
Kuva
Kuva
Kuva
Kuva
Kuva
Kuva
Kuva
Kuva
Kuva
1 Testauksen V-malli ............................................................................. 11
2 Vesiputousmalli ................................................................................. 13
3 Prototyyppilähestymistapa .................................................................... 14
4 Spiraalimalli ..................................................................................... 15
5 Ubercart .......................................................................................... 17
6 Repun määritys .................................................................................. 18
7 Retkilaskuri.net-verkkopalveluun kirjautuminen ......................................... 18
8 Kerätyt tavarat .................................................................................. 19
9 Omien reppujen listaus ........................................................................ 20
10 Repun sisältö ja nimeäminen ................................................................ 20
11 Reppulistan tulostus .......................................................................... 21
12 Tuotteen lisääminen .......................................................................... 22
13 Reppu-projektin haastattelu ................................................................ 23
27
Liitteet
Liite 1 Retkilaskuri.net-verkkopalvelun toiminnollinen määrittely ............................. 28
28
Liite 1
Retkilaskuri.net-verkkopalvelun määrittely
Teht. Nro
1
2
3
4
5
6
7
8
9
10
12
13
14
15
16
17
18
19
20
Tehtävän kuvaus
Repun tallentaminen palveluun
Repun nimeäminen
Tallennettujen reppujen selaus
Käyttäjä pystyy muokkaamaan reppujen sisältöä
Käyttäjän mahdollista lisätä tuotteita palveluun
Graafeja repun sisällöstä
Palautelomake
Päällä olevat vaatteet
Energiatervelaskuri käyttäjän sivuille
Energiatarpeen tallentaminen käyttäjän tietoihin
käyttäjäkyselyt
Mainostaminen
Retkeilyvinkit
Julkaisijan ohjeet
Mainostajan ohjeet
Sivujen selkokielinen osoitemuutos (retkilaskuri.net/tuotteet/kengät)
Yksityisviestit käyttäjien välillä
Kieliversiot Google-translaten avulla
Kuinoma.fi integraatio
Opinnäytetyössä toteutetut määritykset vihreällä
Jatkokehityksen määrittely keltaisella