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
© Copyright 2024