Luku 7 Analyysi- ja suunnitteluvaiheet Analyysivaihe Käyttäjävaatimukset User Requirements Vaatimusanalyysi Requirements Analysis Nykyisen Recover järjestelmän Current tutkiminen Design Create Prosessimallin Process luominen Model Tietomallin luominen Create Data Model Quality Laatuvaatimukset Requirements Confirm Työnkulun Work ja organisaation Flow and vahvistaminen Organization Käyttäjävaatimusten Identify User määrittäminen Requirements Liiketoimintaprosessin Business Prototype prototyyppi Process Tapahtumamallin Create Event luominen Model Laatuvaatimusten Identify määrittäminen Quality Requirements Laatumittareiden Establish ja -tavoitteiden Metrics and määrittäminen Goals
80 7. Analyysi- ja suunnitteluvaiheet Tarkoitus Analyysivaiheen tarkoitus on laatia järjestelmälle ja sen toiminnalle asetettavat viralliset vaatimukset loppukäyttäjien vaatimusten ja odotusten mukaisesti. Nämä vaatimukset muokataan liiketoiminta-, tieto-, tapahtuma- ja prosessimalleiksi sen osoittamiseksi, että vaatimukset on ymmärretty oikein. Näin varmistetaan, että järjestelmän kehittäjillä ja asiakkailla on yhtenevät odotukset projektin laajuudesta ja vaatimuksista. Edellisen sivun prosessikaavio kuvaa analyysivaiheen korkean tason aktiviteetteja. Tavoitteet Analyysivaiheen avaintavoitteet ovat seuraavat: Rakennetaan järjestelmän omistajuutta käyttäjien keskuudessa. Muutetaan nykyiset liiketoimintamallit uuden järjestelmän mukaisiksi liiketoimintamalleiksi. Varmistetaan asianmukaisella johtamisella projektin laajuuden pysyminen taloudellisen perustelun eli business casen määrittämissä rajoissa. Saavutetaan käyttäjien ja projektin tukijoiden kesken yhteisymmärrys järjestelmän toiminnoista, jotta laajuus ei muutu suunnittelu- ja rakennusvaiheiden aikana. Aktiviteetit Käyttäjävaatimukset Projektitiimin täytyy ymmärtää ja dokumentoida muuttunut rakenne ja uusi kokonaistyönkulku, jossa uusi järjestelmä toimii. Nykyinen järjestelmä analysoidaan tarvittavalla tarkkuudella, jotta ymmärretään muutostarpeet ja voidaan dokumentoida ne osat, joihin ei tule muutoksia. Projektitiimi määrittää ja kuvaa käyttäjävaatimukset uuden järjestelmän sekä uuden ja vanhan järjestelmän välisten erojen suhteen. Vaatimukset kootaan loppukäyttäjiltä helpotettujen osallistuvan sovelluskehityksen (JAD, joint application development) istuntojen, henkilökohtaisten haastattelujen, erilaisten
7. Analyysi- ja suunnitteluvaiheet 81 analyysien ja muiden soveltuvien menetelmien avulla. Jos vaatimukset täytyy määrittää hyvin nopeasti, voidaan hyödyntää nopeaa sovelluskehitystä (RAD, rapid application development). Nopeaa sovelluskehitystä käsitellään tarkemmin luvussa 13. Työnkulun ja organisaation vahvistaminen. Valmistellaan tai vahvistetaan organisaatiota koskeva dokumentaatio, jossa kuvaillaan esimerkiksi liiketoimintaprosesseja, rakennetta ja tietosuunnitelmia. Sekä nykyistä toimintaa että tulevaisuudensuunnitelmia käsittelevä dokumentaatio auttaa projektitiimiä ymmärtämään uuden järjestelmän toimintaympäristöä. Käyttäjävaatimusten määrittäminen. Haastatellaan loppukäyttäjiä sen ymmärtämiseksi, mitä uuden järjestelmän täytyy tehdä ollakseen käyttäjien tarpeita vastaava. Suunnitellaan ja pidetään haastatteluja (tarvittaessa myös JADkokouksia), tutkitaan nykyisen järjestelmän dokumentaatiota, analysoidaan uuden ja vanhan järjestelmän välisiä eroja ja päätetään, mitä muutoksia järjestelmien erot edellyttävät. Vaatimukset täytyy määritellä riittävän tarkasti järjestelmän testattavuuden varmistamiseksi. Kun vaatimukset on laadittu, ne käydään läpi loppukäyttäjien kanssa sen varmistamiseksi, että tiedot on ymmärretty oikein ja dokumentoitu kunnolla. Nykyisen järjestelmän tutkiminen. Tutkitaan nykyisen järjestelmän tietokanta, tiedostosuunnitelmat, ohjelmat ja käyttöliittymät. Saatuja tietoja hyödynnetään järjestelmän uusien ja olemassaolevien komponenttien välisten rajapintojen määrittelyssä. Laatuvaatimukset Kuvaillaan, kuinka hyvin järjestelmä suorittaa toimintonsa. Analysoidaan ja ositetaan neljä yleistä laatuvaatimusta - suorituskyky, luotettavuus, käytettävyys ja joustavuus - yksityiskohtaisemmiksi kvantitatiivisiksi vaatimuksiksi. Seuraavaksi jokaiselle laatuvaatimukselle määritetään mittausmenetelmä ja tavoite. Laatuvaatimukset asetetaan tärkeysjärjestykseen sellaisia tilanteita varten, joissa laatutavoitteet ovat ristiriidassa toistensa tai budjetin ja toteutusaikataulun kanssa. Laatuvaatimusten määrittäminen. Tarkistetaan laatuvaatimukset sekä projektin kustannukset ja aikataulu. Laatuvaatimusten perusteella määritetään suunnitteluominaisuudet neljää vaatimuskategoriaa eli suorituskykyä, luotettavuutta, käytettävyyttä ja joustavuutta varten.
82 7. Analyysi- ja suunnitteluvaiheet Määritettyjen vaatimusten täytyy olla myös testattavia. Projektin tukija antaa laatuvaatimusten priorisointikriteerit. Laatumittareiden ja -tavoitteiden määrittäminen. Projektitiimin on kyettävä määrittämään, onko laatuvaatimukset täytetty. Siksi laatuominaisuudet ositetaan yksittäisiksi mitattaviksi ominaisuuksiksi. Asetettujen tavoitteiden perusteella määritetään tämänhetkiset suoritustasot, joihin tulevia suorituksia verrataan. Vaatimusanalyysi ja vaatimustenhallinta Järjestelmävaatimukset analysoidaan, jotta ne ymmärretään paremmin ja jotta niitä voidaan ryhtyä muuntamaan järjestelmäsuunnitelmaksi. Vaatimusanalyysi auttaa suunnittelijoita ymmärtämään, mitä järjestelmän täytyy tehdä vastatakseen käyttäjien vaatimuksia. Kolme virallista vaatimusmallia laaditaan samanaikaisesti: tapahtumamalli määrittelee järjestelmän ulospäin näkyvän toiminnan, tietomalli määrittelee järjestelmän ylläpitämän tiedon rakenteen ja prosessimalli kuvailee järjestelmän sisäistä toimintaa. Näitä malleja kuvaillaan tarkemmin jäljempänä. Usein myös liiketoimintaprosessista luodaan tässä vaiheessa malli eli prototyyppi, jonka avulla varmistetaan, että sekä loppukäyttäjät että projektitiimi ymmärtävät täysin aiemmin muotoillut käyttäjävaatimukset. Koska monien ihmisten on vaikea visualisoida abstrakteja käsitteitä tai uusia teknisiä ratkaisuja, prototyypin avulla voidaan varmistua myös siitä, että käyttäjävaatimukset ovat toteutettavissa ja testattavissa ja että ne täyttävät loppukäyttäjien tarpeet. Prototyyppi antaa heille jotakin konkreettista nähtäväksi ja joskus jopa kokeiltavaksi. Liiketoimintaprosessin prototyyppi Tämän vaiheen tarkoitus on luoda ja iteroida uuden liiketoimintaprosessin kuvaus. Prosessimalli on tulevan sovelluksen käsitteellisten tietovirtojen ja prosessikulkujen kuvaus. Malli koostuu tietovirtakaavioista tai ositetuista liiketoimintatehtävistä, ja sitä tukevat tarpeen vaatiessa prosessien peruskuvaukset. Prototyyppiä voidaan usein käyttää elävänä prosessimallina. Kun prototyypin laajuus on määritelty, se suunnitellaan ja rakennetaan.
7. Analyysi- ja suunnitteluvaiheet 83 P1 Receive Payments Payment Received P2 Process Moneys Received Payment Info P4 Monitor Payments Payments Changes to Account Info P3 Assemble Deposits Account Balance P5 Maintain Account History Financial Institutions Deposits Kuva 7-1 Esimerkki prosessinkulkukaaviosta. Prototyypin valmistuttua projektitiimi pitää demonstraation valituille loppukäyttäjille ja dokumentoi heidän reaktionsa. Tiimi iteroi prototyyppiä tarpeen mukaan saadakseen sille käyttäjien hyväksynnän ja auttaakseen loppukäyttäjiä ottamaan uuden järjestelmän omistukseen. Laajuudeltaan ja monimutkaisuudeltaan rajoitetussa järjestelmässä prototyyppimenetelmä on hyvä tapa simuloida liiketoimintaa. Monimutkaisemmissa tai laajemmissa järjestelmissä prototyyppiä ei ehkä pystytä toteuttamaan. Niissä prosessimalli havainnollistetaan erilaisilla kirjallisilla dokumenteilla ja grafiikalla, esimerkiksi prosessikaavioilla (kuva 7-1). Grafiikan tarkoitus on näyttää liiketoimintaprosessien kulku, ja kirjalliset dokumentit kuvailevat kunkin prosessin yksityiskohtia, kuten syötteitä ja tulosteita sekä prosessin vaiheita. Prosessimallia parannellaan ja ositetaan, kunnes järjestelmän alimmankin tason prosessit on määritelty kokonaan.
84 7. Analyysi- ja suunnitteluvaiheet Prosessimallikaavion, kuten prototyypinkin, tarkistuksia toistetaan järjestelmän loppukäyttäjien kanssa siihen asti, kunnes osapuolet ovat yksimielisiä siitä, että prosessimalli esittää liiketoimintaprosessit oikein ja täydellisesti. Tapahtumamallin luominen Tässä vaiheessa projektitiimi luo mallin liiketapahtumista, jotka osallistuvat sovelluksen ulkoiseen toimintaan, ja todentaa mallin tarkkuuden valittujen loppukäyttäjien kanssa. Tapahtumamalli kuvaa tulevaa sovellusta käsittelemiensä ulkoisten tapahtumien (liike- ja ajastetut tapahtumat) ja käsittelyn tuloksena syntyvien reaktioiden perusteella. Malli koostuu tapahtuma-ärsyke-vaste - kuvauksista, käsitteiden elinkaarikaavioista ja haluttaessa käsite-tapahtuma - matriisista. Tietomallin luominen Luodaan malli sovelluksen tietovaatimuksista, joita käytetään myöhemmin tietokannan ja tiedostorakenteen suunnittelussa. Tietomalli koostuu käsitekaaviosta ja jokaisen uudessa järjestelmässä esiintyvän käsitteen, yhteyden, ominaisuuden ja tietotyypin kuvauksesta. Uuden järjestelmän tietorakenteet rakennetaan tämän mallin perusteella. Mallin oikeellisuus on tärkeä todentaa valittujen loppukäyttäjien kanssa. Monet loppukäyttäjät eivät kuitenkaan ole tutustuneet tietomallikaavioihin, joten projektipäällikkö saattaa joutua järjestämään jonkin verran koulutusta ja perehdytystä, ennen kuin käyttäjät kykenevät vaivatta osallistumaan tietomallikatselmukseen. Kuvassa 7-2 on edellisen sivun prosessikaavioesimerkki muunnettuna tietomalliksi. Roolit Tässä vaiheessa mukana ovat seuraavat projektitiimin jäsenet (tässä kuvaillaan myös edellisen luvun jälkeen mukaan tulleet uudet tiiminjäsenet): Liiketoimintaprosessin suunnittelija
7. Analyysi- ja suunnitteluvaiheet 85 Kuva 7-2 Esimerkki tietomallista. Asiakas Tietosuunnittelija: tietosuunnittelijan vastuulla on ymmärtää ja kuvata niitä tietoja, joita käytetään liiketoiminnassa ja tarvitaan liiketoiminnan uudelle järjestelmälle asettamien vaatimusten täyttämiseksi. Inhimillisten tekijöiden asiantuntija: asiantuntija, joka on perehtynyt ihmisen ja tietokonejärjestelmien väliseen vuorovaikutukseen. Projektin johto Liiketoiminta-alueen asiantuntija: nimetty omien alojensa asiantuntija, jonka antama tieto ja palaute on erittäin arvokasta, koska sen perusteella kelpuutetaan mallit, prototyypin toiminta ja lopulta järjestelmäsuunnittelu. Testaaja: testaaja vastaa prototyypin testaamisesta ja varmistaa, että se toimii suunnitelman mukaisesti. Resurssit Käsitteellinen suunnitelma Järjestelmän korkean tason suunnitelma valmistellaan ennen kehittämistyön aloittamista. Se kuvaa uutta järjestelmää ja näyttää sen laajuuden, kokonaisarkkitehtuurin ja suhteen muihin järjestelmiin. Käsitteellinen suunnitelma on projektisuunnitteluvaiheessa valmisteltu tuote.
86 7. Analyysi- ja suunnitteluvaiheet Nykyisen järjestelmän kuvaus Nykyisen järjestelmän kuvaus voi sisältää tietokanta- ja tiedostosuunnitelmat, ohjelmadokumentaation ja/tai ohjelmakoodin. Yritysmalli Yritysmalli kuvaa koko yrityksen kannalta kiinnostavia käsitteellisiä prosesseja, käsitteitä ja suhteita. Yritysmalli ei ole tarkka eikä yksityiskohtainen kuvaus vaan väline, jonka avulla voidaan vaihtaa ajatuksia uuden järjestelmän tukijoiden ja käyttäjäorganisaation johdon kanssa järjestelmäsuunnitelmista. Yksittäinen kehitysprojekti kattaa yleensä vain pienen osa-alueen koko yritysmallista. Tietosuunnitelma Tietosuunnitelma sisältää korkean tason kuvauksen yrityksen tietojärjestelmistä ja niihin liittyvistä liiketoiminnan tavoitteista. Tuotteet Liiketoimintaprosessin prototyyppi Liiketoimintaprosessin prototyyppi havainnollistaa uuden järjestelmän toimintaa. Prototyypin tulisi keskittyä järjestelmän olennaisiin tai ongelmallisiin osiin. Prototyyppejä on erilaisia: käytettävän prototyyppilajin valinnan ratkaisee sen tarkoitus. Tavoitteena saattaa esimerkiksi olla keskustelun kulun tai järjestelmän käytettävyyden testaaminen. Vaatimusmäärittely Vaatimusmäärittely sisältää tieto-, tapahtuma- ja prosessimallit sekä laatuvaatimukset ja/tai viittaa niihin.
7. Analyysi- ja suunnitteluvaiheet 87 Laatuvaatimukset löytyvät aiemmin kuvailtujen tieto-, tapahtuma- ja prosessimallien lisäksi myös laatuvaatimusdokumentista (ks. seuraava kappale). Laatuvaatimukset Sovelluksen laatuvaatimukset ilmaistaan joukkona mitattavissa olevia laatuominaisuuksia sekä suoritustasona, joka sovelluksen täytyy saavuttaa. Lisäksi laatuvaatimukset sisältävät ohjeita siitä, millä perusteella jokin laatuominaisuus vaihdetaan toiseen (tai millä perusteella laatuominaisuudesta luovutaan kustannusarviosta ja toteutusaikataulusta johtuvien syiden takia). Välietapit Arkkitehtuurianalyysin arviointi valmis Arkkitehtuurin arviointi on tarkistuspiste, jossa projektitiimi ja ulkopuolinen tarkastusryhmä tutkivat perusteellisesti projektin ohjelmistot, laitteet ja pohjana olevan tekniikan tarjotakseen ohjeita yritysstrategioita ja standardiympäristöjä varten. Kyseessä on ohjelmistonkehitysprosessin laadunvarmistusmekanismi. Tämä arviointi ei ole välttämätön. Vaatimusten hyväksyminen Asiakas hyväksyy vaatimusmäärittelyn eli tapahtumamallin, tietomallin, prosessimallin ja laatuvaatimukset.
88 7. Analyysi- ja suunnitteluvaiheet Työkalut Projektin analyysivaiheessa käytetään useita työkaluja tarvittavien tuotteiden ja työdokumenttien luomiseksi. Jotkut tuotteet edellyttävät erikoistyökaluja tai niiden käyttö on ainakin perusteltua, kun taas joillekin tuotteille riittävät standardityökalut, kuten tekstinkäsittelyohjelmat, esitystyökalut ja laskentataulukot. Tiedonmallinnustyökalut: Näitä työkaluja käytetään käsitekaavioiden ja/tai tietomallien tai tietohakemistojen komponenttien yksityiskohtaiseen kuvaamiseen. Suosittuja ohjelmia valmistavat mm. Rational Software (Rational Rose), Platinum Software, Sterling ja Cayenne. Windows-pohjainen Logic Works ER win - työkalu on kohtuuhintainen ja helppokäyttöinen ohjelma järjestelmille, jotka eivät ole valtavan monimutkaisia ja laajoja. Prosessien ja tapahtumien mallinnustyökalut: Monet tiedonmallinnusohjelmien valmistajat myyvät ohjelmiinsa myös moduuleita tai lisäosia, joilla voi mallintaa ja järjestelmällisesti ositella prosesseja. Myös Visiota käytetään usein prosessikaavioiden luomiseen, ja tekstinkäsittelyohjelmalla, esimerkiksi Microsoft Wordillä, kirjoitetaan prosessien yksityiskohtaiset kuvaukset. Suunnitteluvaihe Tarkoitus Suunnitteluvaiheen tarkoitus on suunnitella valmiiksi järjestelmä, joka täyttää analyysivaiheessa määritetyt vaatimukset. Suunnitteluvaiheen päämäärä on määritellä ne keinot, joilla projektissa kehiteltävä ratkaisu toteutetaan, mutta mitään ei vielä toteuteta käytännössä. Luvun alussa oleva prosessikaavio kuvaa suunnitteluvaiheen korkean tason aktiviteetteja.
7. Analyysi- ja suunnitteluvaiheet 89 Tavoitteet Suunnitteluvaiheen avaintavoitteet ovat seuraavat: Suunnitellaan käyttöliittymä: liiketoimintaprosessien kulku, syöttö- ja tapahtumanäytöt, raportit ja dokumentit. Varmistetaan, että suunnittelu täyttää sekä liiketoimintaprosessin että kaikkien tarvittavien tukitoimintojen toiminnalliset vaatimukset. Varmistetaan, että suunnittelu täyttää erityisesti käytettävyydelle ja luotettavuudelle (tietoturva ja valvonta) asetetut laatuvaatimukset. Aktiviteetit Käyttöliittymän suunnittelu Suunnitellaan se uuden järjestelmän osa, jonka loppukäyttäjät näkevät. Keskeisin tehtävä on suunnitella käyttäjän ja järjestelmän vuorovaikutusmekanismit, kuten näytöt ja tapahtuma- ja tietovirrat, joiden pohjalta yksittäiset ikkunat ja muut syötteet ja tulosteet suunnitellaan. Lopuksi määritellään työnkulun yksityiskohdat (esimerkiksi työryhmä- tai osastokohtaisesti). Keskustelujen suunnittelu. Ihmisen ja tietokoneen välisen liittymän korkean tason suunnittelu alkaa liiketoimintatehtävän kulun tutkimisella. Tätä mallia käytetään pohjana niiden keskustelujen kehittämisessä, jotka järjestelmä esittää käyttäjälle näyttö- tai komento/vaste -sarjoina. Keskustelujen suunnittelun täytyy tukea liiketoimintatehtäviä ja -prosesseja sekä niihin liittyviä tapahtumia. Viimeistään suunnittelun tässä vaiheessa on tärkeää luoda keskustelutyyppistandardit yhdenmukaisen käyttöliittymäsuunnittelun tueksi. Näyttöjen suunnittelu. Suunnitellaan näytöt sellaisiksi, että ne ovat yhdenmukaisia keskustelujen suunnittelun kanssa. Sommitellaan järjestelmän näytöt täysin valmiiksi, määritellään näytöissä navigointi ja näyttöjen vaihtuminen ja varmistetaan, että ne vastaavat esteettisiä ja käytännöllisiä vaatimuksia. Suunnittelu voidaan tehdä piirrosten tai kaavioiden avulla, tai näytöistä voidaan tehdä prototyypit samoilla työkaluilla, joilla järjestelmän varsinaiset keskustelut luodaan.
90 7. Analyysi- ja suunnitteluvaiheet Raporttien ja dokumenttien suunnittelu. Sommitellaan raportit ja dokumentit, jotka sovellus luo. Standardoidaan raportit ja dokumentit aina, kun se on mahdollista, ja pyritään käyttämään muiden sovellusten raportteja ja dokumentteja malleina. Kuten näyttöjen suunnittelussakin, samoja työkaluja, joilla lopulliset raportit laaditaan, voidaan käyttää myös raporttien suunnittelussa. Yksi vaihtoehto on tarvittaessa käyttää tekstieditoreja ja tekstinkäsittelyohjelmia varatyökaluina. Kun dokumentteja sommitellaan tekstinkäsittelyohjelmalla, malleissa kannattaa käyttää samoja fontteja ja kirjainkokoja kuin aiotaan käyttää varsinaisten dokumenttien laatimisessa. Näin vältytään ongelmilta, kun oikeita raportteja rakennetaan järjestelmään. Tekninen suunnittelu Projektitiimin täytyy määritellä sovellusarkkitehtuuri. Arkkitehtuurin määrittely sisältää vaatimusten siirtämisen teknisen arkkitehtuurin komponentteihin ja ne globaalit suunnittelupäätökset, jotka muodostavat standardit ja suuntaviivat järjestelmän komponenttien yksityiskohtaiselle suunnittelulle. Tieto ja prosessit jaetaan tarvittaessa koko verkkoon. Ohjelmat määritetään ja ositetaan moduuleiksi. Ohjelmien väliset ja moduulien väliset viestit sekä liittymät ulkoisiin järjestelmiin suunnitellaan. Tietomalli muunnetaan ensin loogiseksi ja sitten fyysiseksi tietokantasuunnitelmaksi. Sovellusarkkitehtuurin määrittely Määritellään sovelluksen toiminnallisten komponenttien väliset suhteet ja se, miten nuo komponentit ovat vuorovaikutuksessa eri järjestelmien kanssa. Nämä päätökset vähentävät seuraavien kehityspäätösten monimutkaisuutta ja auttavat varmistamaan, että laatuvaatimuksiin vastataan. Arkkitehtuurimallin katselmuksella varmistetaan, että mallin koko, laatu ja toiminnalliset ominaisuudet ovat sopivat ja että malli vastaa liiketoiminnan vaatimuksia. Kaikki arkkitehtuuriin liittyvät ongelmat ratkaistaan vertaamalla laatuvaatimuksia kehitys- ja ylläpitokustannuksiin ja -aikatauluihin, ja tarvittaessa ratkaisuihin hankitaan suostumus ja tukea projektin tukijalta tai muilta johdon avainhenkilöiltä. Käsittelyjärjestyksen määrittely Tarkennetaan kokonaissuunnitelmaa määrittämällä luotavat ohjelmat ja määritellään yksityiskohtaisesti tiedon käsittelyjärjestys ja se, kuinka tieto siirtyy prosessista toiseen.
7. Analyysi- ja suunnitteluvaiheet 91 Kuva 7-3 Esimerkki loogisesta tietokantasuunnittelusta. Kuten projektin muissakin tähän mennessä käsitellyissä vaiheissa niin suunnittelussakin kaavioiden ja piirrosten laatiminen ohjelman kulusta on kätevä dokumentointi- ja viestintäkeino. Loogisen tietokanta/tietorakenteen suunnittelu Loogisen tietokanta/tietorakenteen suunnittelu muuntaa vaatimusanalyysin aikana luodun tietomallin loogisiksi tietorakenteiksi, joita tiedonhallintaohjelmisto tukee. Tämän aktiviteetin aikana tietokanta ja/tai tietorakenteet suunnitellaan ja dokumentoidaan sellaiseen muotoon, jossa sovelluskehittäjät ja loppukäyttäjät ne näkevät. Looginen tietokannan tai tietorakenteen suunnittelu määrittelee kaikki uuteen järjestelmään tallennettavat yksittäiset tietoelementit. Loogisissa tietomallikaavioissa näkyy jokainen tiedon osa ja kaikki osien väliset riippuvuudet. Kuvassa 7-3 on esimerkki loogisesta tietomallista. Automatisoitujen prosessien suunnittelu Arvioidaan riittävän yksityiskohtaisesti sovelluksen kustannukset, resurssien tarve ja vasteajat. Suunnitellaan jokainen ohjelma jakamalla se alemman tason moduuleiksi.
92 7. Analyysi- ja suunnitteluvaiheet Kuvaillaan jokaisen moduulin tarkoitus ja käsittelysäännöt. Suunnitellaan ohjelma ohjelmapakettien mukaan. Kehitetään tietokannan saantimallit ja muut siirräntätoiminnot. Järjestelmän liittymien suunnittelu Suunnitellaan rajapinta rakenteilla olevan sovelluksen ja niiden muiden järjestelmien välille, joiden kanssa sovellus kommunikoi (esimerkiksi jaettu tietokanta, tapahtumatiedostorajapinta tai yksittäisten viestien online-siirto). Tarvittaessa tehdään muutospyyntöjä nykyisten järjestelmien muokkaamiseksi. Fyysisen tietokanta/tietorakenteen suunnittelu Määritellään tarkasti fyysinen muisti ja saantirakenteet, jotka auttavat varmistamaan optimaalisen suorituskyvyn ja luotettavuuden. Tietorakenteen fyysinen suunnittelu on erittäin riippuvainen valitusta tekniikasta. Esimerkiksi Oracletietokannan fyysinen tietorakenne eroaa huomattavasti sellaisen tietokannan tietorakenteesta, joka käyttää järjestelmätiedostoissa olevaa tietoa. Yleensä fyysinen tietokantasuunnitelma luodaan ohjelmakohtaisella komentojonokielellä tai sellaisella teksti/tiedostoeditorilla, jota ohjelmapaketti pystyy lukemaan. Laadun todentaminen ja kelpuuttaminen Loppukäyttäjät ja tekninen henkilöstö todentavat ja kelpuuttavat sen, että kaikki toiminnalliset vaatimukset ovat mukana suunnittelussa ja että laatutavoitteisiin todennäköisesti päästään. Erityistä huomiota tulisi kiinnittää käytettävyyteen ja suorituskykyyn. Toiminnallisuuden todentaminen Varmistetaan, että suunnittelu vastaa toiminnallisia (eli käyttäjien) vaatimuksia ja että jokainen toiminnallinen vaatimus on sisällytetty yhteen tai useampaan suunnitteluolioon (esimerkiksi ohjelmiin, prosesseihin tai tietoon).
7. Analyysi- ja suunnitteluvaiheet 93 Laatuominaisuksien testaaminen ja todentaminen Varmistetaan, että suunnittelu täyttää suorituskyvylle, luotettavuudelle, käytettävyydelle, joustavuudelle, projektikustannuksille ja aikataululle asetetut laatuvaatimukset. Roolit Tässä vaiheessa mukana ovat seuraavat projektitiimin jäsenet (tässä kuvaillaan myös edellisen luvun jälkeen mukaan tulleet uudet tiiminjäsenet): Liiketoimintaprosessin suunnittelija Asiakas Tietosuunnittelija Suunnittelija: suunnittelija on vastuussa suunniteltujen elementtien osista tai elementtien kokonaissuunnittelusta, ja hänellä on asiantuntemusta käyttöliittymien, järjestelmän vuorovaikutuksen ja tietomallien suunnittelusta. Inhimillisten tekijöiden asiantuntija Projektin johto Liiketoiminta-alueen asiantuntija Tekninen arkkitehti Loppukäyttäjä Resurssit Yrityksen standardit Kaikki yritykset tarvitsevat sovelluskehitysstandardit, jotka voivat sisältää itstandardiympäristön standardien lisäksi myös muita standardeja. It-standardiympäristön standardeissa määritetään ohjelmistot ja tekniikat sekä ohjelmistojen versiotasot ja it-arkkitehtuuri, joita yrityksessä käytetään. Ne määrittävät myös arkkitehtuuristrategiat, alustat, verkot ja protokollat tietotekniikan eri käyttöalueille. Standardeja tulisi käyttää standardienkehityksen elinkaaressa ohjeistamaan tekniikan soveltamista uudessa järjestelmässä.
94 7. Analyysi- ja suunnitteluvaiheet Jos standardeja ei ole tai ne eivät sovellu projektissa käytettäviksi, projektitiimi joutuu tekemään ylimääräistä työtä suunnitellessaan ja testatessaan uusia tekniikoita. Liiketoimintaprosessin prototyyppi Liiketoimintaprosessin prototyyppi havainnollistaa uuden järjestelmän toimintaa. Prototyyppi myös keskittyy järjestelmän olennaisiin tai ongelmallisiin osiin. Vaatimusmäärittely Vaatimusmäärittely sisältää tieto-, tapahtuma- ja prosessimallit sekä laatuvaatimukset ja/tai viittaa niihin. Tuotteet Suunnitteludokumentti Suunnitteludokumentti sisältää sovellusarkkitehtuurin, sovellusvirran, tietokantasuunnitelman, käyttöliittymäsuunnitelman ja työnkulkukaavion ja/tai viittaa niihin. Näitä suunnitteludokumentin osia kuvaillaan seuraavaksi tarkemmin. Sovellusarkkitehtuuri Sovellusarkkitehtuuri muodostuu yleisistä päätöksistä, jotka dokumentoidaan siirtämällä sovelluksen toiminnalliset vaatimukset sen tekniseen arkkitehtuuriin (ohjelman pakkausmalleihin ja arkkitehtuurin perusyksiköihin) ja suunnittelustandardeihin.
7. Analyysi- ja suunnitteluvaiheet 95 Sovellusvirta Sovellusvirta kuvaa tiedon yleistä virtaamista järjestelmän läpi. Siinä esitetään graafisesti kaikki sovelluksen ja sen ulkopuolisten rajapintojen ohjelmat (online-, asynkroniset ja eräajoohjelmat) ja kaikki ohjelmien väliset yhteydet (tiedostot ja tietokannat). Tietokantasuunnitelma Tietokantasuunnitelmassa on kaksi osaa: looginen suunnittelu (ohjelmoijan ja loppukäyttäjien näkökulma) ja fyysinen tietokantasuunnittelu (tietokannan valvojan näkökulma). Käyttöliittymäsuunnitelma Käyttöliittymäsuunnitelma kattaa käyttäjän toimet työasemalla (päätteiden syöttöruudut ja näytöt sekä älykkäiden työasemien syöttöruudut ja ikkunat) ja työaseman ulkopuolella (raportit ja muut oliot). Työnkulkukaavio Työnkulkukaavioita käytetään automatisoitujen prosessien ja manuaalisen työnkulun suunnittelun dokumentoimiseen. Automatisoitujen prosessien suunnitelma on sovelluksen suoritettavien ohjelmien ja moduulien kuvaus, jossa esitetään, miten tieto ja kontrolli kulkee suoritettavasta ohjelmasta toiseen. Manuaalisen työnkulun suunnitelma sisältää liiketoimintaprosessin automatisoimattoman osan: syötteiden valmistelun, raporttien jakelun, työaseman käytön, virheellisen tiedon korjaamisen ja oikean tiedon syöttämisen, työnkulun ohjauksen, suorituskyvyn, tietoturvan ja hallintalaitteet. Käyttäjädokumentaatioluonnos Käyttäjädokumentaatioluonnokseen kirjataan kehitettävät manuaaliset prosessit ja se, kuinka ne organisoidaan.
96 7. Analyysi- ja suunnitteluvaiheet Välietapit Arkkitehtuurisuunnittelun arviointi valmis Arkkitehtuurin arviointi on tarkistuspiste, jossa projektitiimi ja ulkopuolinen tarkastusryhmä tutkivat perusteellisesti projektin ohjelmistot, laitteet ja pohjana olevan tekniikan varmistaakseen, että ne ovat yritysstrategioiden ja standardiympäristöjen mukaisia. Kyseessä on ohjelmistonkehitysprosessin laadunvarmistusmekanismi. Tämä arviointi voidaan yhdistää elinkaaren arviointiin, jos molemmat halutaan suorittaa. Suunnittelun hyväksyminen Suunnitteludokumentin hyväksyminen merkitsee, että valmiiksi saatu järjestelmän suunnittelu on hyväksytty. Hyväksyntä hankitaan kaikilta asianomaisilta rooleilta tai sidosryhmiltä, ennen kuin rakentaminen voi alkaa. Suunnittelun hyväksyminen sisältää myös loppukäyttäjien hyväksynnän käyttöliittymälle ja yksityiskohtaiselle työnkululle. Elinkaaren arviointi valmis Elinkaaren arviointi on projektitiimin ja ulkopuolisen tarkastusryhmän suorittama muodollinen projektin edistymiskatselmus, jossa arvioidaan riskialueita ja ehdotaan toimenpiteitä havaittujen riskien käsittelemiseksi. Elinkaaren arviointi tarkastelee projektia yritysjohdon näkökulmasta.kyseessä on ohjelmistokehityksen laadunvarmistusmekanismi. Elinkaaren arviointia suositellaan käytettäväksi uusissa kehitysprojekteissa sekä ohjelmiston uudelleensuunnittelussa, jossa on vähintään 50%:n onnistumismahdollisuus. Työkalut Projektin suunnitteluvaiheessa käytetään useita työkaluja tarvittavien tuotteiden ja työdokumenttien luomiseksi. Jotkut tuotteet edellyttävät erikoistyökaluja tai niiden käyttö on ainakin perusteltua, kun taas joillekin tuotteille riittävät standardityökalut, kuten tekstinkäsittelyohjelmat, esitystyökalut ja laskentataulukot.
7. Analyysi- ja suunnitteluvaiheet 97 Tiedonmallinnustyökalut: Näitä työkaluja käytetään loogisten tietomallien tai tietohakemistojen kehittämiseen. Suosittuja ja hyödyllisiä ohjelmia valmistavat mm. Rational Software (Rational Rose), Platinum Software, Logic Works (ER/ win tai ER/Studio), Sterling ja Cayenne. Prosessien ja tapahtumien mallinnustyökalut: Monet tiedonmallinnusohjelmien valmistajat myyvät ohjelmiinsa myös moduuleita tai lisäosia, joilla voi mallintaa ja järjestelmällisesti ositella prosesseja. Myös Visiota käytetään usein prosessikaavioiden luomiseen, ja tekstinkäsittelyohjelmalla, esimerkiksi Microsoft Wordillä, kirjoitetaan prosessien yksityiskohtaiset kuvaukset.
98 7. Analyysi- ja suunnitteluvaiheet