2         Kehittämistyön vaiheet ja elinkaarimallit

 

(kirja luku 3)

 

A. Tietojärjestelmien kehittämisen vaiheet

 

• Lähtökohtana tarve kehittää uusi tietojärjestelmä tai ylläpitää vanhaa tietojärjestelmää

• Kehitystyö on systemaattista toimintaa, jossa tietyt tehtäväkokonaisuudet edeltävät toisia tehtäviä.

• Tietojärjestelmän elinkaari on joukko peräkkäisiä, toisiinsa liittyviä vaiheita.

• Tietojärjestelmän elinkaaren vaihejaolla pyritään määrittämään tietojärjestelmän kehittämisen tehtävät, ajoitus ja eri vaiheiden riippuvuudet toisistaan.

 

 

1. Esitutkimus

 

• Esitutkimuksen tehtävänä on tuottaa tietoa tietojärjestelmän kehittämisestä päättäville sekä määrittää lähtökohdat mahdolliselle kehittämishankkeelle.

• Esitutkimusraportti sisältää:

• Organisaation kehittämishanketta koskevan nykytilanteen kuvaaminen

• Ongelmien kuvaukset, joihin haetaan ratkaisua

• Kuvaus viite- ja sidosryhmistä (esim. kassatyöntekijät), joita kehittämishanke koskee.

• Alustavat järjestelmälle asetettavat tavoitteet ja rajaukset

• Uuden järjestelmän kehittämistavoitteet

• Eri toimintavaihtoehdot

• Alustava suunnitelma hankkeen läpiviemiseksi

• Esitutkimuksen perusteella tehdään päätös järjestelmän kehittämisestä tai kehittämättä jättämisestä.

 

 

2. Vaatimusmäärittely

 

• Dokumentti, johon on koottu kehitettävälle järjestelmälle asetetut vaatimukset eri sidosryhmiltä.

• Tässä vaiheessa ei oteta kantaa tekniseen toteutustapaan.

• Vaatimusten luokittelu:

• Toiminnalliset vaatimukset määrittelevät mitä järjestelmän odotetaan tekevän

–                siinä määritellään miten järjestelmä kommunikoi ympäristönsä kanssa, esim. miten käyttäjät työskentelevät järjestelmän kanssa.

• Ei toiminnalliset vaatimukset määrittelevät järjestelmän reunaehdot (vastausajat, käytettävyys, rajoitteet)

–                Ei toiminnallisia vaatimuksia voi olla esim. tietojärjestelmä toimii Windows NT/ 2000-ympäristössä.

–                Ei toiminnallisen vaatimuksen rajoite voi olla esim. ’Asiakas ei saa varata kerrallaan kuin max. 10 tuotetta).

 

• Asiakasvaatimusten kerääminen

• Haastattelut

• Aivoriihet ja ideointipalaverit

• Markkinatutkimukset

• Vanhojen tietojärjestelmien analysointi

• Ulkoisten tekijöiden huomioiminen (lainsäädäntö, standardit, asetukset)

• Vaatimusmäärittelyn ongelmia

• Vaatimusten keskeneräisyys

• Vaatimusten keskinäinen ristiriitaisuus

 

Vaatimusmääritysdokumentaatio

• Myöhempien vaiheiden epäselvyyksien välttämiseksi vaatimukset tulisi kirjata niin tarkasti kuin mahdollista. Dokumentaation tulisi sisältää:

• Kuvaus kehittämishankkeen toimeksiannosta

• Yleiskuvaus kohdejärjestelmän nykytilasta

• Kuvaus kohdejärjestelmälle asetetuista tavoitteista

• Jokaisen toiminnallisen vaatimuksen kuvaus

• Jokaisen ei toiminnallisen vaatimuksen kuvaus

• Jokaisen rajoitteen kuvaus

• Vaatimukset ja rajoitteet numeroituna ja priorisoituna

• Mahdolliset lisäselvitykset

 

 

3. Järjestelmän määrittely eli järjestelmäanalyysi

 

• Selvitetään, mitä rakennettavan järjestelmän tulee tehdä.

• Analysoidaan edellinen vaihe (vaatimusmäärittelyn vaatimukset) ja johdetaan niistä toiminnallinen määrittely.

• Toiminnallinen määrittely sisältää mm:

• Järjestelmän jokaisen toiminnon yksityiskohtaisen kuvauksen

• Järjestelmän käsittelemien tietojen ja tietokantojen kuvaukset

• Järjestelmän rajapintojen kuvaukset

• Dokumentoinnin selkeys on tärkeää!

 

 

4. Suunnittelu

 

• Suunnittelun tarkoituksena on muuntaa toiminnallinen määrittely tekniseksi määrittelyksi.

• Suunnitteluvaihe jaetaan arkkitehtuuri- ja moduulisuunnitteluun.

  • Arkkitehtuurisuunnittelussa määritellään järjestelmän yleinen rakenne ja jaetaan se niin pieniin osiin, että osat voidaan antaa yksittäisten kehittäjien suunniteltaviksi ja toteutettaviksi.

  • Moduuli on kokonaisuus, joka sisältää kaikki tiettyyn järjestelmän osakokonaisuuteen liittyvät toiminnot. (Esim. Moodlessa on seuraavia moduuleita: chat, foorumi, tehtävä, jne.)

  • Arkkitehtuurisuunnittelun ideana on pyrkiä jakamaan järjestelmä mahdollisimman itsenäisiin moduuleihin.

• Tekninen määrittelydokumentaatio kuvaa järjestelmän toteutuksen ja sisältää mm.

• Kuvauksen järjestelmän laitteisto- ja ohjelmistoympäristöstä

• Kuvauksen järjestelmän arkkitehtuurista (mm. kuvaus ohjelmisto- ja tietokanta-arkkitehtuurista)

• Kuvauksen jokaisesta yksittäisestä järjestelmän moduulista ja alijärjestelmästä

• Kuvaukset mahdollisista vaihtoehtoisista/hylätyistä ratkaisuista.

• Kuvauksen toteutuksen reunaehdoista

 

 

5. Toteutus

 

• Toteutusvaiheessa ohjelmisto toteutetaan jollakin ohjelmointikielellä.

• Toteutuksen loppuvaiheessa ohjelmamoduulit integroidaan (kasataan) toimivaksi kokonaisuudeksi.

• Toteutuksen tulee vastata järjestelmälle asetettuja vaatimuksia ja sen tulee olla toiminnallisten ja teknisten määrittelyjen mukainen.

 

Toteutus/laatu

• Toteutusvaiheessa joudutaan huomioimaan mm. seuraavia laatuun vaikuttavia seikkoja:

• Toiminnallisuus

• Luotettavuus

• Siirrettävyys

–                Järjestelmiä tai niiden osia pitää pystyä käyttämään erilaisissa laite- ja käyttöympäristöissä.

• Ylläpidettävyys

–                Järjestelmät ovat usein pitkäikäisiä, ja niitä ylläpidetään useita vuosia. Sen vuoksi toteutuksessa on huomioitava ylläpidon helpottaminen. Ylläpitoa voidaan helpottaa mm:

·         kapseloimalla järjestelmän toiminnot omaan moduuliinsa, jolloin niiden muuttaminen myöhemmin on helpompaa.

·         muuttuvien tekijöiden parametroinnilla. Muuttuvia tekijöitä (esim. korkoprosentti) ei saa koodata kiinteästi.

• Laadunvarmistuksen ratkaisuna on mm. ohjelmiston rakenteen asianmukainen suunnittelu ja toteutuksessa noudatettava kurinalaisuus (mm. koodin asianmukainen kommentointi).

 

6. Testaus

 

• Testauksen tarkoituksena on löytää ohjelmistosta virheitä.

• Testaus voidaan jakaa:

• Moduulitestaus eli yksikkötestaus

–                Etsitään virheitä yksittäisistä moduuleista, testauksen tekee ohjelmistokehittäjä, joka laatii testitapausluettelon

–                White-box testing, moduulien sisäinen testaus

 

White-box –testauksessa testataan ohjelmistokomponenttien sisäisten algoritmien virheettömyys. Tarkoituksena on varmistaa, että jokainen lause ja ehto on suoritettu vähintään yhden kerran. Testausmenetelmänä peruspolkutestaus ja silmukkatestaus.

 

Peruspolkutestauksessa:

lasketaan syklomaattinen kompleksisuus eli rajattujen alueiden lukumäärä esim. 4, joka on sama kuin peruspolkujen määrä.

Tämän jälkeen testataan kaikki neljä eri polkua erikseen.

 

Silmukkatestauksessa testataan:

o        yksinkertainen silmukka

o        sisennetyt silmukat

o        ketjutetut silmukat

o        rakenteeton silmukka

 

• Integrointitestaus

–                Etsitään virheitä moduulien yhteistoiminnasta

–                Black-box testing, moduulien ulkoinen testaus eli syötteiden ja tulosteiden oikeellisuuden testaus

 

Black-box –testauksessa testataan ohjelmistokomponenttien tuottamien tulosarvojen oikeellisuutta suhteessa syöttöarvoihin.

Syöttötietoja voi olla esim.

o        käyttäjien syöttämät tiedot

o        alustusarvot

 

• Järjestelmätestaus eli systeemitestaus

–                Etsitään virheitä koko järjestelmän toiminnoista ja suorituskyvystä. Testaus tehdään vertaamalla valmista järjestelmää sen toiminnalliseen määrittelyyn.

 

 

7. Käyttöönotto

 

• Kun järjestelmä on testattu ja tuotteistettu, voidaan se ottaa käyttöön.

• Tuotteistamiseen kuuluu mm. asennuspaketin kasaaminen (erillinen asennusohjelma esim. InstallShield), asennusohjeet, käyttöohjeet.

• Käyttöönoton valmisteluun kuuluu mm.

• olemassa olevien tietojen siirtäminen uuteen järjestelmään

• mahdollinen vanhan ja uuden järjestelmän rinnakkaiskäyttö

• käyttäjien ja ylläpitäjien kouluttaminen

 

 

8. Ylläpito

 

• Ylläpitovaihe on ohjelmiston elinkaaren pisin yksittäinen vaihe.

• Ylläpito kattaa tuotantokäytössä olevan järjestelmän:

• virhekorjaukset

• jatkokehityksen (uusia ominaisuuksia)

• muutokset (muutoksia jo toteutettuihin toimintoihin)

• Ylläpitoa vaikeuttaa usein puutteellinen dokumentaatio.

• Jos järjestelmästä ylläpidetään useita eri versioita, pyritään ylläpitoa helpottamaan erilaisilla versionhallinta työkaluilla.

 

 

B. Tietojärjestelmien elinkaarimallit

 

• Ohjelmistoprosessi eli tietojärjestelmän elinkaari on tietojärjestelmän kokonaisvaltainen mallintaminen

• Ohjelmistoprosesseja kuvattaessa toiminnot organisoidaan integroituneeksi kokonaisuudeksi.

 

1. Vesiputousmalli

 

 

Kuva 2. Vesiputousmalli

 

• Vesiputousmalli kehitettiin 1960-luvun lopussa.

• Vesiputousmallissa kehittäminen nähtiin eteenpäin kulkevana prosessina, jossa on hankalaa tai turhaa peruuttaa taaksepäin. Näin kuitenkin todellisuudessa tapahtuu harvoin.

• Vesiputousmallin ongelmia:

• Malli kuvaa ohjelmistoprosessille tyypillisen iteratiivisuuden huonosti.

–            Iteratiivisuus: tietyn vaiheen suoritus paljastaa edellisen vaiheen virheen, jolloin prosessissa on peruutettava taaksepäin ja korjattava virhe.

• Ohjelmistoprojektin tulokset pystytään esittämään asiakkaalle vasta prosessin loppuvaiheessa.

• Malli on edelleen yleisimmin sovellettu elinkaarimalli.

 

 

2. Prototyyppilähestymistapa

 

 

 

Kuva 3. Prototypointi

 

• Prototyyppilähestymistavassa järjestelmästä tuotetaan nopeasti asiakkaan arvioitavaksi prototyyppi. Prototyyppi sisältää vain yleisen toiminnallisuuden, ei yksityiskohtia.

• Asiakkaan arvioinnin jälkeen prototyyppiä parannellaan niin kauan, että asiakas on siihen tyytyväinen.

• Tämän jälkeen kohdejärjestelmä toteutetaan prototyypin pohjalta.

• Protoilu on ns. iteratiivinen prosessi:

• Prosessin aikana kokeillaan vaihtoehtoisia ja epävarmojakin ratkaisuja, palataan korjaamaan ja hylätään epäsopivat ratkaisut.

• Ongelmat:

• järjestelmän ’kaksinkertainen’ rakentaminen vaatii paljon resursseja.

 

 

3. Spiraalimalli

 

 

 

Kuva 4. Spiraalimalli

 

• Spiraalimallin keskeiset ajatukset ovat:

• Iteratiivisuus

• kokeillaan erilaisia vaihtoehtoja

• palataan korjaamaan virheellisiä ratkaisuja

• hylätään epäsopivat ratkaisut.

• Riskien jatkuva analysoiminen ja prosessin uudelleen ohjaaminen riskianalyysin tulosten mukaan

• Spiraalimallissa on neljä vaihetta, joita toistetaan, kunnes järjestelmä on valmis

• Suunnittelu (tavoitteet, vaihtoehdot, rajoitukset)

• Riskianalyysi (ongelmien arviointi)

• Tuotanto (uuden version valmistuminen)

• Asiakkaan suorittama arviointi (katselmoinnit)

• Spiraalimalli ei edellytä jotakin tiettyä menetelmää ohjelmistotuotantovaiheessa, jolloin voidaan soveltaa esim. vesiputousmallia tai protoilua.

• Spiraalimalli on uusi elinkaarimalli, josta on vähän käytännön kokemuksia.

• Mallin ongelmia:

• mallin soveltaminen on aikaa vievä