Esipuhe Kirjallisuutta:

Transkriptio

1 Esipuhe Tämä moniste sisältää perustietoa tietojärjestelmistä ja niiden kehittämisestä. Siinä on myös suhteellisen kattava kuvaus tietojärjestelmien tunnetuimmista kehitysmenetelmistä ja niiden perusperiaatteista. Tietojärjestelmien suunnittelua tarkastellaan esimerkkien avulla osana laajempaa organisaation toiminnan suunnittelua. Tavoitteina on selvittää mitä ovat tietojärjestelmät, miksi ne ovat organisaatioille välttämättömiä ja miten niitä sovelletaan erilaisiin ympäristöihin. Monisteessa käsitellään tietojärjestelmien kuvaustekniikkoja ja suunnittelumenetelmiä, erityisesti ER- ja oliomallia. Varsinaisia perustietoja kurssin suorittaminen ei vaadi - tosin alan peruskäsitteiden hallinnasta ja käytännön kokemuksesta on kurssilla hyötyä. Tämä moniste perustuu lähinnä englanninkieliseen lähdemateriaaliin, kuten DeMarcon, Elmasri & Navathen ja Coad & Yourdonin teoksiin sekä moniin aiempiin, enemmän tai vähemmän kyseisten teosten pohjalta laadittuihin monisteisiin, joita ovat vuosien varrella olleet kirjoittelemassa ainakin (aakkosjärjestyksessä) Erkki Innola, Jari Kesti, Mika Kirveennummi, Päivi Saalasto, Jukka Teuhola ja Vesa Torvinen. Kirjallisuutta: Avison, D. & Fitzgerald, G. Information Systems Development: Methodologies, Techniques and Tools, 2nd ed., McGraw-Hill Publishing Company, Coad, P. & Yourdon, E. Object-oriented analysis, Second edition. Yourdon Press, New Jersey, DeMarco, T. Structured Analysis and System Specification. Prentice-Hall Inc., Elmasri, R. & Navathe, S. Fundamentals of Database Systems. Addison-Wesley, Gane, C. & Sarson, T. Structured Systems Analysis: tools and techniques. Prentice- Hall Inc., Kroenke, David & Hatch, Richard: Management Information Systems, 3 edition, McGraw-Hill, USA, Mannila, H. & Räihä, K-J. The Design of Relational Databases. Addison-Wesley, Teuhola, J. Tietokantojen jatkokurssi, Yourdon, E. Modern Structured Analysis. Prentice-Hall,

2 SISÄLLYSLUETTELO 1 JOHDANTO TIETOJÄRJESTELMIIN Tietokoneen historia Tietojärjestelmien historia Tietojärjestelmien kehittäminen 5 2 TIETOJÄRJESTELMIEN KEHITTÄMINEN Lineaarinen elinkaari Tietojärjestelmäprojekti 12 2

3 1 JOHDANTO TIETOJÄRJESTELMIIN 1.1 Tietokoneen historia Tietokone on alun perin kehitetty laskukoneeksi. Tietokoneen englanninkielinen nimi, computer, onkin tarkkaan suomennettuna laskija. Kenties ensimmäinen ihmisen historian varsinainen laskukone on ollut kiinalainen helmitaulu (1300-luku). Muita tietokoneen historiaan liittyviä kuuluisia laskukoneita ovat olleet William Oughtredin vuonna 1622 luoma laskukone (slide rule), jota insinöörit käyttivät aina 1900-luvun alkuun saakka sekä Blaise Pascalin laskukone (1642), jossa oli jo eräänlainen tulostusikkuna sekä näppäimistö. Tietokoneen taustalta löytyy hieman yllättäviäkin keksintöjä. Esimerkiksi ranskalaisen Joseph-Marie Jacquardin keksimä automaattinen kutomakoneen (1801), jossa reikäkortit ohjasivat eri kuvioiden vaihtumista kankaan kudonnassa, noudattaa paljolti samoja periaatteita kuin aikaisimmat tietokoneet. Toisaalta 1800-luvun suuri laivastoihin liittyvä ongelma, navigointi, on aikoinaan johtanut tietokonetta muistuttavan koneen kehittämiseen. Charles Babbage kehitti koneen (1822, Difference Engine), joka auttoi laivojen navigoinnissa ja näin vähensi laskennassa sattuvia virheitä sekä laivoille tapahtuvia onnettomuuksia. Charles Babbagen toinen kone, Analytical Engine, sisälsi jo niin paljon modernin tietokoneen komponentteja, että häntä pidetään yleisesti tietokoneen isänä. Tietokoneen historia ei suinkaan ole pelkkää miesten historiaa. Maailman ensimmäisenä ohjelmoijana pidetään kreivitär Ada Augusta Kingiä. Hän oli amatööri matemaatikko, joka käytti Charles Babbagen Analytical Engineä ohjelmointiin (1842). Seuraava merkittävä tapahtuma tietokoneen historiassa oli USA:n väestönlaskenta vuonna Sitä helpottamaan pidettiin kilpailu, jossa etsittiin tiedon prosessointiin uusia apuvälineitä. Kilpailun voittaja perusti C-T-R -nimisen yhtiön vuonna Yhtiö nimettiin uudelleen vuonna 1924 IBM:ksi. Varsinaisen tietokoneen keksimistä ennen on nähtävissä eri puolilla maailmaa tapahtunut kehittämisen kilpajuoksu. Esimerkiksi saksalainen Konrad Zuse kehitti oman versionsa tietokoneesta vanhempiensa olohuoneeseen ( , Z-1). John Vincent Atanasoff yhdessä John Berryn kanssa kehitti koneen nimeltä ABC ( , Atanasoff-Berry Computer) USA:ssa. Kone on ehkä aikaisin esimerkki elektronisesta laskimesta. Alan Turing kehitti idean koneesta, joka olisi niin yleinen, että sillä voitaisiin ratkaista mitä tahansa, kuvattavissa olevia algoritmeja (1937). Toisen maailmansodan aikaan monet tiedemiehet ympäri Atlanttia työskentelivät salakirjoituksen parissa. Kuuluisin kone, joka tuona aikana syntyi, oli Oxfordin ja Cambridgen yliopistoissa kehitetty Colossus (1943). Mm. Turing oli mukana kehittämässä tätä konetta. Ensimmäinen suuri, automatisoitu, yleisiin ongelmiin tarkoitettu, elektromekaaninen laskin oli Harvard Mark I (1944). Koneen rakentamista sponsoroi USA:n armeija ja se oli tarkoitettu erilaisten matemaattisten taulukoiden, kuten myös navigointiin liittyvien taulukoiden laskentaan. Modernin tietokoneen syntymisvuotena pidetään kuitenkin vuotta 1948, jolloin Englannissa julkaistiin kone 3

4 nimeltä Manchester Mark I (tai Manchester Baby), jossa ensimmäistä kertaa voitiin tallettaa ohjelma koneen muistiin. Vain vuosi Manchester Mark I:n julkaisun jälkeen, julkaistiin USA:ssa kilpaileva tietokone, EDSAC (Electronic Delay Storage Automatic Computer). Nämä ensimmäiset tietokoneet olivat huoneen kokoisia laitoksia, jotka perustuivat elektroniputkitekniikkaan. Ohjelmointikielet ottivat ison harppauksen kehityksessään eteenpäin, kun vuonna 1957 julkaistiin ensimmäinen FORTRAN kääntäjä. Tämä merkitsi sitä, että ennen niin harvoille ja erikoistuneille ohjelmoijille varattu ohjelmointityö alkoi kehittyä käyttäjäystävällisemmäksi ja helpommaksi. Edsger Dijkstra oli ensimmäinen, joka alkoi puhua tarpeesta ohjelmakoodin rakenteistamiseksi (1968). Tästä sai alkunsa GO TO -lauseen kritisointi ja rakenteisen ohjelmoinnin kehittäminen. Rakenteisen suunnittelun periaatteita opiskellaan myöhemmin tälläkin kurssilla. Tietokoneiden historia on kulkua entistä pienempiin, tehokkaampiin ja suurimuistisimpiin koneisiin. Vuonna 1963 sovittiin ASCII -standardista, joka tarkoitti ensimmäistä kertaa sitä, että eri valmistajien tietokoneet saattoivat vaihtaa tietoa keskenään. Ensimmäisen todellisen minitietokoneen, PDP-8, julkaisi Digital Equipment Corporation vuonna Henkilökohtaisen tietokoneen juuret ovat vuodessa 1971, jolloin tuli markkinoille ensimmäinen kaupallinen mikroprosessori ja ensimmäinen levyke. Ensimmäinen digitaalinen, henkilökohtainen tietokone oli MITS 816 (1972), jossa tosin ei ollut näyttöä eikä näppäimistöä. IBM julkaisi ensimmäisen henkilökohtaisen tietokoneen nimeltä 5100 vuonna 1975, Apple II julkaistiin vuonna 1976 ja IBM julkaisi Personal Computer eli PC:n, jonka käyttöjärjestelmänä oli Microsoftin kehittämä DOS, vuonna Nykyisen graafisen käyttöliittymän juuret ovat vuodessa 1984, jolloin Apple julkaisi Macintosh in. Siinä oli sekä hiiri että käyttöliittymän ikonit. Huhutaan, että todellinen kehitystyö olisi kuitenkin tehty Xerox PARCin toimesta, Alto -järjestelmän kehittämisen yhteydessä. 1.2 Tietojärjestelmien historia Tietojärjestelmä sanana viittaa tiedon käsittelemiseen. Perusoperaatioita ovat tiedon talletus, säilytys, haku ja poisto. Lisäoperaatioita ovat erilaiset laskutoimitukset, joita tietojen avulla voidaan tehdä. Tietojärjestelmälle ei kuitenkaan ole olemassa vakiintunutta määritelmää. Toiset rajaavat tietojärjestelmän käsitteen tietokoneella toteutettuun järjestelmään, kun toiset taas ymmärtävät sillä mitä tahansa tiedon talletukseen, varastointiin, muokkaukseen ja hakemiseen tarkoitettu järjestelmää. Laajemman määritelmän mukaan tietojärjestelmän ei tarvitse olla toteutettu tietokoneella, vaan esimerkiksi arkistokaappi tai puhelinluettelo täyttävät tietojärjestelmän määritelmän. Kaikkein laajin määritelmä sisällyttää tietojärjestelmän käsitteeseen koko organisaation: ihmiset, heidän työnsä sekä kaikki ne apuvälineet, joita tuossa työssä käytetään. Edellisestä ilmiöstä johtuu, että tietojärjestelmien historia ei ole välttämättä aivan sama asia kuin tietokoneen historia. Ihmiset ovat kautta vuosisatojen pyrkineet varastoimaan tietoa erilaisille tietovälineille. Tässä mielessä tietojärjestelmien historia on lähes yhtä pitkä kuin ihmisenkin historia. Savitauluja käytettiin kirjanpidon apuvälineenä muinaisessa Babyloniassa jo 3000 vuonna ekr. 4

5 Tietokonetuettujen tietojärjestelmien historia on puolestaan verraten lyhyt - tosin kehitys on ollut nopeaa verrattuna moneen muuhun alueeseen luvulla tietotekniikan käyttö yrityksissä oli vähäistä ja sitä käytettiin lähinnä laskennan apuvälineenä luvulla tulivat yrityksiin tietojenkäsittelyosastot luvulla yleistyivät varsinaiset tietokonepohjaiset tietojärjestelmät. Järjestelmät olivat yleensä eräajopohjaisia, osastojen sisäisiä järjestelmiä luvulla tulivat henkilökohtaiset tietokoneet ja tietoverkot alkoivat kehittyä ja yleistyä luvulla tietokonetta sovelletaan organisaatioissa jo lähes kaikilla työn osa-alueilla. Tietoverkot eivät rajoitu enää edes yrityksen sisäisten toimintojen tukemiseen, vaan ne ovat laajentuneet yrityksen ulkopuolelle. Suurilla tuotantoyrityksillä on esimerkiksi useita alihankkijoita, joiden kanssa kommunikoidaan tietotekniikan välityksellä. Useimmiten myös pankkiasiat hoidetaan yrityksestä käsin tietotekniikan avulla. Tietoverkkojen laajeneminen yritysten ulkopuolelle mahdollistaa myös työntekijöiden työskentelemisen fyysisesti yrityksen ulkopuolella. Tietotekniikka mahdollistaa etätyön tekemisen esimerkiksi työntekijän kotona. Työntekijä voi tehdä työtään yrityksen tietojärjestelmissä kotoaan käsin, jos hänellä on siihen tarvittavat laitteet. Tietojärjestelmien suunnittelu ja rakentaminen edellyttää useiden alueiden tietämystä. Relevantteja tietämysalueita voisivat olla esimerkiksi tietojärjestelmän tulevien käyttäjien toimintatavat, algoritmit ja tietorakenteet, ohjelmisto-, tietokone- ja tietojärjestelmäarkkitehtuuri sekä yrityksen liiketoiminnan sovellusalue. 1.3 Tietojärjestelmien kehittäminen Tietojärjestelmän määritelmä vaikuttaa suoraan siihen, mitä tietojärjestelmien kehittämisellä tarkoitetaan. Jos tietojärjestelmää ajatellaan tietokonepohjaisena järjestelmänä, on kehittämisen kohteena luonnollisesti tietokonepohjainen sovellus. Tuon sovelluksen oletetaan tukevan jotain tiettyä toimintaa. Jos tietojärjestelmät ymmärretään laajemmin käsittäen kaikki tiedon hallintaan liittyvät välineet, on kehittäminenkin määriteltävä laajemmin. Tietojärjestelmien kehittäminen olisi tässä tapauksessa tiettyyn ihmisen toimintaan liittyvien tiedonhallintavälineiden kehittämistä - oli ne sitten toteutettu tietokoneella tai ei. Tästä jälkimmäisestä määritelmästä on se etu, että tietojärjestelmien analysointi ja suunnittelu voi olla kokonaisvaltaisempaa ja mahdollisten kehittämistoimenpiteiden kohde on laajempi. Laajimmillaan tietojärjestelmien kehittämisellä voidaan ymmärtää koko organisaation toiminnan kehittämistä. Tällöin ihmisten tekemää työtä ei oteta annettuna, vaan kaikkia työhön liittyviä osa-alueita voidaan kehittää: niin työn tekemisen apuvälineitä kuin työntekijöiden käsityksiä heidän työnsä tavoitteista. Nykyään yritykset keskittyvät yhä enemmän toimintansa kehittämiseen. Syitä tähän ovat nopeutunut kehitys, laatuajattelu, kova kilpailu ja taloudelliset tekijät. Yritysten toiminnan kehittämiseen liittyvät ongelmat ovat moninaiset. Tietämys työn tekemisestä saattaa olla myös pirstaloitunutta; yksittäiset työtekijät tekevät vain erikoistuneita tehtäviä, mutta kokonaisuus ei välttämättä ole kenenkään hallussa. Työn siirtyessä henkilöltä toiselle tehtävien alustus- ja lopetusoperaatioita saattaa olla paljon, mikä hidastaa työn kulkua. Toiminta voi olla byrokraattista ja hierarkioita voi olla paljon, mikä saattaa tehdä organisaation toiminnan suhteellisen jäykäksi. Organisaatioissa 5

6 tehdään usein myös päällekkäistä työtä, vaikka saman asian tekeminen vain yhteen kertaan olisikin edullisempaa. Lisäksi pitkälle erikoistunut työnjako ja tiedonkulun heikkoudet saattavat aiheuttaa sen, että asiakaspalvelun taso on heikkoa. Tämä taas vähentää yrityksen kiinnostavuutta ja kilpailukykyä. Yrityksen toiminnan, tuotteiden ja palvelujen laatu syntyy sen prosessien ominaisuuksista, pelkät resurssit eivät riitä. Tietotekniikka on yksi keino kehittää näitä prosesseja suoraan esimerkiksi nopeuttamalla tiedonkäsittelyä ja tiedon saatavuutta tai välillisesti esimerkiksi tarjoamalla työntekijöille hyödyllisiä työvälineitä ja lisäämällä heidän mahdollisuuksiaan tehostaa prosesseja oman työnsä osalta. Tosin tietotekniikan kehittäminen harvoin yksin riittää. Liiketoimintaa on usein kehitettävä kokonaisvaltaisesti. Teknologian kehittymisen myötä yrityksissä keskitytään nykyisin enemmän toiminnan kehittämiseen, kun taas aikaisemmin keskityttiin enemmän tekniseen kehittämiseen. Tämä johtuu mm. siitä, että tietotekniikan soveltaminen olemassa olevien työtapojen tukemiseen on huomattu johtavan suhteellisen huonoihin lopputuloksiin. Työt kyllä saadaan tällaistenkin järjestelmien avulla tehtyä. Tosin vaihtoehtoinen ratkaisu, jossa työn rakenteita ensin muutetaan ja järjestelmä rakennetaan tukemaan uutta toimintamallia, johtaa toiminnan tehostumiseen. Kilpailutilanteissa, jossa kilpailijat tehostavat toimintaansa ja alentavat hintojaan, organisaatioiden kannattaa usein muuttaa toimintatapojaan tietokonepohjaisten tietojärjestelmien kehittämisen yhteydessä. 2 TIETOJÄRJESTELMIEN KEHITTÄMINEN Tässä luvussa kuvataan tietojärjestelmien suunnittelun taustoja ja elinkaarimalli karkealla tasolla. Lisäksi pohditaan projektityöskentelyä tietojärjestelmäsuunnittelun yhteydessä. Tietojärjestelmien suunnittelua on tutkittu ja erilaisia suunnittelumenetelmiä kehitetty jo 1950-luvulta lähtien. Jotkut suunnittelijat keskittyvät tietojärjestelmien suunnittelussa ainoastaan teknisiin ongelmiin, toiset puolestaan tietojärjestelmän strategisiin vaikutuksiin organisaatiossa, toiset kustannusten pienentämiseen ja toiset työn muutoksiin. Kuitenkin nämä kaikki tulisi ottaa huomioon. Täydellisempi kuva tietojärjestelmän suunnitteluprosessista saadaan, kun identifioidaan nämä erilaiset näkökulmat ja selvitetään niiden väliset suhteet. Suunnitteluprosessin ymmärtäminen helpottuu, kun tutkitaan järjestelmän suunnittelun elinkaarta (life cycle). Järjestelmän elinkaari sisältää kaikki suunnitteluprosessin vaiheet ongelman havaitsemisesta valmiiseen ja toimivaan järjestelmään. Kaikista elinkaarimalleista voidaan identifioida viisi päävaihetta: toiminnan tai ongelma-alueen analysointi sekä järjestelmän suunnittelu, toteutus, käyttöönotto ja ylläpito. Valittaessa menetelmää tietojärjestelmien suunnitteluun on muistettava, että erilaisia menetelmiä käytetään erilaisissa tilanteissa. Rakennettaessa suuria rakenteeltaan tarkasti määrättyjä tietojärjestelmiä käytetään muodollisempia suunnittelumenetelmiä. Suunnittelumenetelmästä riippumatta on aina muistettava, että tietojärjestelmä rakennetaan ratkaisemaan oikeaa ongelmaa. Järjestelmän täytyy sopia olemassa olevaan ympäristöön ja tulevien käyttäjien työtehtäviin. 6

7 Tietojärjestelmien suunnittelumenetelmä voidaan määritellä yhtenäiseksi joukoksi käsitteitä, uskomuksia, arvoja ja periaatteita, jotka auttavat ongelmaa ratkaisevaa ryhmää havaitsemaan, tuottamaan, arvioimaan ja toteuttamaan muuten kuin satunnaisella tavalla muutoksia informaatiotilanteessa. Menetelmä on siis enemmän kuin joukko ohjeita selvitä erilaisista ongelmista. Yhtä ainoaa oikeaa menetelmää ei ole olemassa, vaan jokaisella menetelmällä on oma, suhteellisen erilainen teoria maailmasta. Koska tietojärjestelmän rakentaminen vie paljon aikaa, järjestelmät ovat laajoja ja rakentaminen itsessään on suhteellisen monimutkaista, jaetaan kehittämisprojektit usein osiin. Näin on kehitetty erilaisia vaihejakoja systemointia varten. Koska vaihejaot yleensä noudattavat järjestelmän ajallista kehitystä, niitä kutsutaan myös elinkaarimalleiksi (life cycle models). 3.1 Lineaarinen elinkaari Lineaarinen elinkaari on perinteinen lähestymistapa tietojärjestelmien suunnittelussa. Sen vaiheet ovat peräkkäisiä ja seuraava vaihe perustuu aina edellisen tuloksiin. Kunkin vaiheen tuloksena on jonkinlainen raportti (kuvaukset, päätökset, ongelmat), joten dokumentoinnilla on tärkeä osa suunnittelussa. Seuraavassa esitetään yksi mahdollinen lineaarinen elinkaarimalli. Vaihe 1: Tehtävän määrittely Tehtävän määrittely on ehkä vaiheista tärkein. Tässä vaiheessa määritellään ratkaistava ongelma, sen rajat, suunnittelun tavoitteet ja käytettävät resurssit. Itse ongelman määrittely ei välttämättä ole yksinkertainen tehtävä. Se, mikä tässä vaiheessa ymmärretään ratkaistavaksi ongelmaksi, saattaa kehitystyön edetessä paljastua huonoksi määrittelyksi. Tehtävänä voisi olla esimerkiksi suunnitella uusi myyntitoimintaa tukeva järjestelmä, josta olisi apua sekä operatiiviseen myyntitoimintaan että markkinoinnin suunnitteluun. Ongelman ulkopuolelle voitaisiin rajata laskutukseen liittyvät toiminnot, joita varten on jo olemassa oma järjestelmänsä. Näin ongelmaalueen sisälle voisi kuulua automaattinen liittymä näiden kahden ohjelmiston välillä. Tehtävän määrittelyvaiheessa tehdään usein myös projektisuunnitelma, jossa määritellään mm. tarvittavat resurssit. Projektin tulosten seuranta ja arviointi tapahtuvat usein tehtävän määrittelyn perusteella. Vaihe 2: Toteutettavuustutkimus Toteutettavuustutkimusvaiheessa laaditaan ehdotus periaateratkaisuksi ja esitetään idea järjestelmän rakenteesta ja toteutuksesta. Tietojärjestelmän toteutettavuuteen liittyvät seuraavat näkökohdat: tekninen (löytyykö taitoa ja teknologiaa) toiminnallinen (käyttäjien hyväksyntä) taloudellinen (projektin resurssitarve). 7

8 Vaihe 3: Järjestelmän analyysi Järjestelmän analyysivaiheessa tutkitaan olemassa olevaa järjestelmää (siltä osin kuin se on olemassa) keräämällä tietoa eri lähteistä. Tässä vaiheessa suoritetaan tietoanalyysi ja laaditaan järjestelmän yksityiskohtainen malli käyttäen erilaisia kuvaustekniikoita. Vaihe 4: Järjestelmän suunnittelu Järjestelmän suunnitteluvaihe voidaan jakaa kahteen alavaiheeseen: Yleissuunnittelu, jossa selvitetään järjestelmän päätoiminnot, tärkeimmät syötteet ja tulosteet sekä erotetaan automatisoitavat ja manuaaliset osat. Yksityiskohtainen suunnittelu, jonka tuloksena määritellään tietokannat, ohjelmamoduulit, proseduurit, laitteet, käyttöliittymät, käyttöohjeet ja lomakkeet. Vaihe 5: Järjestelmän rakentaminen Järjestelmän rakentaminen voidaan jakaa kahteen alavaiheeseen: Kehittäminen, jossa kirjoitetaan ohjelmat, ladataan tietokannat ja testataan käyttöliittymät. Implementointi, jossa kootaan osat toimivaksi järjestelmäksi. Vaihe 6: Seuranta Järjestelmän oltua jonkin aikaa toiminnassa tarkistetaan, onko tavoitteet saavutettu. Jos asetettuja tavoitteita ei ole saavutettu, etsitään epäonnistumisen syitä. Tässä vaiheessa järjestelmään voidaan tehdä pieniä korjauksia, mutta pahimmassa tapauksessa tulisi aloittaa uusi kehityssykli. Käytännössä tähän ei usein ole mahdollisuutta, sillä projekti voi olla jo muutenkin ylittänyt suunnitellun budjettinsa. On hyvin tyypillistä, että tehtävän määrittelyvaiheessa ei osata arvioida tulevaa työmäärää oikein. Lisäksi käyttäjien koulutus hoidetaan usein aivan liian kevyesti, mikä huonontaa uuden järjestelmän vastaanottoa. Vaihe 7: Ylläpito Ylläpitovaiheessa korjataan käytössä havaittuja virheitä, viritetään ja sovitetaan valmista järjestelmää ympäristön ja muuttuneiden tarpeiden mukaisesti. 8

9 Tehtävän määrittely Käyttäjien vaatimukset Reunaehdot: -Projektin tavoite -Projektin rajat -Resurssit Tarkista Jatkoimplementointi Toteutettutkimus tavuus- Järjestelmäanalyysi Käsitteellinen ratkaisu Arvioidut kustannukset ja hyödyt Tarkista Oikeellisuus Implementointi Yleissuunnittelu Tietomalli Järjestelmän yksityiskohtaiset tavoitteet Tarkista Oikeellisuus Järjestelmän suunnittelu Tarkista Käyttäjien tehtävät Ehdotetut laitteistot Ohjelma- ja tietokantamääritykset Oikeellisuus Oikeellisuus Tarkista Kehittäminen Järjestelmän rakentaminen Seuranta Yksityissuunnittelu kohtainen Ylläpito Toimiva järjestelmä Oikeellisuus Kuva 3.1. Lineaarinen elinkaarimalli Lineaarisen elinkaaren suunnitteluvaiheiden puhdas peräkkäisyys ei aina käytännössä toimi, vaan suunnittelijan pitää voida perääntyä ja tarkistaa aiemmissa vaiheissa tehtyjä ratkaisuja. Yleensä paluu tapahtuu edeltävään vaiheeseen, jolloin elinkaaresta käytetään nimitystä 'loopy linear' (silmukkainen lineaarinen). Esimerkiksi jos järjestelmän rakentamisvaiheessa huomataankin, ettei aiemmin suunniteltua tietomallia voidakaan toteuttaa, on palattava suunnitteluvaiheeseen. Toisaalta odottamattomat ongelmat järjestelmän käytössä voivat aiheuttaa paluun järjestelmän toteutusvaiheeseen, suunnitteluvaiheeseen tai jopa analyysivaiheeseen. Mitä aikaisemmaksi elinkaaressa joudutaan palaamaan, sitä suuremmasta ja kalliimmin ratkaistavasta ongelmasta todennäköisesti on kysymys. Pahin tilanne on tietysti silloin, kun huomataan, että itse projektin tavoite on ollut pielessä. Kuvassa 3.2 on esitelty joitakin lineaarisen elinkaarimallin käytössä mahdollisesti esiintyviä ongelmatilanteita, jotka saattavat vaatia paluun aikaisempaan vaiheeseen. 9

10 Tehtävän määrittely Järjestelmä ei täytä operationaalisia eikä taloudellisia vaatimuksia Tietomallia ei voida rakentaa Toteutettutkimus tavuus- Järjestelmän analyysi Järjestelmän suunnittelu Tarvitaan enemmän tietoa järjestelmästä Suunnitelmia ei voida implementoida Odottamattomia ongelmia valmiissa järjestelmässä Järjestelmän rakentaminen Kuva 3.2. Lineaarisen elinkaarimallin ongelmia. Klassisen vaihejaon noudattamisessa on se vaara, että suunnittelija luulee vaihejaon sinänsä takaavan hyvän lopputuloksen. Tämä ei tietenkään itsessään riitä. Vaihejako on hallinnollisesti selkeä, mutta dokumentoinnin osuus on ylikorostunut - usein kehitystyön kustannuksella. Dokumentoinnin tulisi olla vain sivutuote. Eräs ilmaus perinteisen suunnittelutavan ongelmista on ylläpidon osuus, joka nykyisin nielee jopa 70 % järjestelmän kokonaiskustannuksista. Eräänä syynä on ollut se, että elinkaaren alkupäähän ei ole panostettu riittävästi. Analyysiin ja suunnitteluun on käytetty ehkä noin 20 % kokonaispanoksesta, kun nykyisen käsityksen mukaan osuuden tulisi olla jopa 70-80%. Käyttäjien osuus perinteisessä suunnittelumetodiikassa on ollut liian pieni. On oletettu, että käyttäjät osaavat ilmaista tarpeensa analyysivaiheessa tarkasti. Tämä ei yleensä pidä paikkaansa, joten käyttäjien tulisi voida osallistua aktiivisesti koko prosessiin. Jos käyttäjien tarpeiden määrittelyssä tehdään virheitä, sillä on laajakantoinen vaikutus lopputulokseen. Myös organisaation johdon tulee olla mukana ja sitoutua tehtyihin ratkaisuihin. Klassinen menetelmä on eräänlainen 'big bang' -lähestymistapa; järjestelmä tehdään kerralla valmiiksi ja käyttäjä tutustuu siihen vasta toteutuksen jälkeen. Toteutuksen jälkeen on kuitenkin liian myöhäistä enää tehdä kovin syvällisiä muutoksia. Klassinen vaihejako ei sisällä varsinaista suunnitelmien testausvaihetta ennen järjestelmän rakentamista. Kuitenkin on todettu, että noin 64 % virheistä tehdään analyysi- ja suunnitteluvaiheissa ja vain 36 % ohjelmoinnissa. Lineaarisen elinkaarimallin yhteydessä esille nousseiden ongelmien ratkaisemiseksi on vaihtoehtoiseksi lähestymistavaksi esitetty evoluutionaarista kehittämisratkaisua. Tällöin tietojärjestelmän kehittäminen ei tapahdu järjestelmän kertakaikkisena 10

11 implementointina, vaan järjestelmää kehitetään osaprosesseina, joiden tulosta evaluoidaan ja tämän jälkeen tuotetta kehitetään edelleen. Esimerkiksi protoilu (prototyyppisuunnittelu) toteuttaa evoluutionaarista kehittämisperiaatetta. Protoilu on prosessi, joka antaa järjestelmäkehittäjän mahdollisuuden luoda mallin, prototyypin, rakennettavasta järjestelmästä (ohjelmasta). Tätä mallia arvioidaan yhdessä tulevien käyttäjien kanssa ja mallin pohjalta kehitetään edelleen uusi malli, joka edellistä paremmin vastaa tilaajan vaatimuksia. Kuvassa 3.3 on hahmoteltu prototyypin käyttöön perustuvaa tietojärjestelmän kehittämisprosessia Pressmanin (1992) mukaan. Määrittely Lopullinen toteutus pika design Proton uudell. määrittely Proton evaluointi (käyttäjät/tilaaja) Proton rakentaminen Kuva 3.3. Protoilun käyttö tietojärjestelmän kehittämisessä. Prototyypit voi jakaa toteutustavan mukaan kahteen pääryhmään horisontaalisiin ja vertikaalisiin prototyyppeihin. Horisontaalisessa prototyypissä mallinnetaan toiminnallinen kokonaisuus mutta jätetään mallintamatta järjestelmän yksityiskohdat. Vertikaalisessa prototyypissä puolestaan valitaan mallinnettava osa-alue ja implementoidaan se kokonaisuudessaan, pienintä yksityiskohtaa myöten. Spiraalimalli pitää sisällään useita protoilun elementtejä. Spiraalimalli on protoilua strukturoidumpi tietojärjestelmän kehittämismalli. Kehittäminen lähtee liikkeelle suunnitteluvaiheesta. Ensimmäinen kierros perustuu suunnittelun tuloksiin. Riskianalyysin jälkeen tehdään päätös kehittämisen jatkamisesta. Kehittämisvaiheessa luodaan prototyyppi. Asiakas / tilaaja arvioi prototyypin toimintaa. Tämän jälkeen palataan suunnitteluvaiheeseen, tosin jo toiselle kierrokselle. Toisella kierroksella vastaavat vaiheet ja muutettavat osa-alueet perustuvat jo asiakkaan kommentteihin. Spiraali etenee sisäkehältä ulospäin. Kehittämisprojektin ja tuloksena olevan tuotteen luonteesta riippuu spiraalin kierrosten määrä. 11

12 3.2 Tietojärjestelmäprojekti Projekteista ja projektinhallinnasta on olemassa runsaasti materiaalia. Tämä pitää paikkansa myös tietojärjestelmäprojektien osalta. Ei ole kuitenkaan perusteltua ottaa mitään lähestymistapaa absoluuttisena totuutena. Projekti käsitteenä on laajasti käytetty ja ymmärretty mutta sen eksakti ja tässä yhteydessä käyttökelpoinen määrittely ei enää olekaan yhtä triviaali. Forsman määrittelee projektin tarkoittamaan työn tekemistapaa ja rakennetta seuraavine tunnuspiirteineen. Projekti on ainutlaatuinen ja ainutkertainen Projekti tähtää sovittuun lopputulokseen Projektilla on sovittu aikataulu Projektin voimavarat ovat lyhytvaikutteisia. Projektisuunnitelman laatiminen on merkittävin yksittäinen toimenpide kehitysprojektia käynnistettäessä. Seuraava projektisuunnitelma on muokattu Pressmanin (1992) ohjelmistoprojektin suunnitelmasta. Kyseinen suunnitelma nojautuu varsin pitkälle lineaariseen elinkaarimalliin. Toisaalta evolutionaarisen kehittämisparadigman käyttö on mahdollista varsin pienin muutoksin suunnitelman perusrakenteeseen. Projektisuunnitelma aloitetaan johdannolla, jossa kerrotaan dokumentin tarkoitus (kuvata tietojärjestelmän kehitysprojekti), määritellään projektin tavoitteet ja ongelmaalue sekä projektin ulkopuolelle jäävät asiat. Ongelma-aluetta kannattaa havainnollistaa sekä kuvin että sanoin. Kaikenlaisen taustatiedon antaminen on vain hyväksi ja nostaa dokumentin luettavuutta ja laatua. Myös projektin rajaus on tärkeää, koska sen perusteella saadaan parempi käsitys siitä, mihin projektilla todella tähdätään ja mihin ei. Projektin rajauksen syitä kannattaa pohtia kuten myös vaihtoehtoisia rajauksia. Projektin ulkopuolelle jäävistä ongelmista kannattaa myös antaa mahdollisimman tarkka selonteko. Projektisuunnitelma voi jatkua esittelemällä projektiin liittyvät riskit. Riskianalyysissä tulisi keskustella niin teknisistä kuin sosiaalisistakin riskeistä. Kannattaa pohtia, onko rakennettava järjestelmä teknisesti mahdollinen, liittyykö tekniikkaan riskejä, onko projektin käytössä riittävästi tietämystä käytetyistä tekniikoista, millaisia sosiaalisia vaikutuksia tulevalla järjestelmällä voi olla, onko todennäköistä, että käyttäjät tulevat hyväksymään järjestelmän ja niin edelleen. Suuret riskit eivät välttämättä tarkoita sitä, että projektia ei kannattaisi toteuttaa. Riskien tiedostaminen ja analysointi on kuitenkin osa hyvää projektinhallintaa. Lisäksi riskien hallintaan liittyvä suunnitelma on kuitenkin hyvä esittää. Projektisuunnitelmassa esitetään myös suunnitelma projektin aikatauluksi. Aikataulun suunnittelu on erittäin vaikea tehtävä ja se arvioidaankin hyvin usein liian pieneksi. 12

13 Varsinkin, jos projektisuunnitelman tekijällä ei ole aikaisempaa kokemusta aikatauluista, kannattaa projektisuunnitelma tarkistuttaa jollain kokeneella henkilöllä. Jos projektisuunnitelmaa käytetään tarjouksen laskentaan, tulee aikataulun suhteen olla erityisen tarkka. Aikataulu esitetään usein osatehtävittäin. Aikataulusta käy myös ilmi osatehtävien suoritusjärjestys, niiden tulokset sekä tarkistuspisteet. Työn tulos tulee aina tarkastaa määräajoin. Tällaisella käytännöllä voidaan välttää ainakin osa budjettiin liittyvistä epäselvyyksistä. Projekti on voitava ja uskallettava myös lopettaa tarkastuspisteissä, jos sen tulokset eivät tyydytä. Projektisuunnitelmassa on esitettävä, miten projektia valvotaan ja miten sen toimintaa ohjataan. Projektin resurssien kuvaus kuuluu myös projektisuunnitelmaan. Suunnitelmasta tulee käydä ilmi, ketkä henkilöt ottavat osaa projektiin ja millaisin panoksin. Jos esimerkiksi joku tuleva käyttäjä on osa projektiryhmää, on huolehdittava, että hän saa helpotusta päivittäisten tehtäviensä hoitoon. Myös johtajien ja kehittäjien panokset projektiin tulee arvioida. Projektit tarvitsevat usein myös muita resursseja: laitteistoja, projektihuoneen, erilaisia mallinnusvälineitä sekä mahdollisesti lisäkoulutusta. Projekteille on tapana muodostaa myös itsenäinen organisaatiorakenne. Projektilla on tyypillisesti johtaja, jäseniä sekä ohjausryhmä. Ohjausryhmä valvoo projektin toimintaa, eikä ota varsinaisesti osaa tuloksen tekemiseen. Projektin organisaatiokaavio esitetään tyypillisesti projektisuunnitelmassa. Alla on hahmoteltuna projektisuunnitelman runko karkealla tasolla. 13

14 1. Johdanto Dokumentin tarkoitus Projektin tavoitteiden määrittely Projektin rajaus 2. Projektin riskit Riskien analysointi Riskinhallinta 3. Aikataulu Aikataulu osatehtävittäin Osatehtävien suoritusjärjestys Osatehtävien vaatimat resurssit 4. Resurssit Henkilöresurssit Resurssit 5. Organisaatio Projektiorganisaation kuvaus 6. Valvonta- ja ohjausjärjestelmät Liitteet Lähteet: Forsman, Ulf. Hahmotelma korkeakoulujen talouden ja taloudenpidon malliksi, Computer Science University of Turku Research reports R-94-13, Pressman Roger S., Software engineering a practitioner s approach. McGraw-Hill int.,