Ohjelmiston elinkaarimallit

1. Ohjelmiston elinkaarimallit RASE 2.5.2006

2. Ohjelmiston elinkaari • Aika, joka kuluu ohjelmiston kehittämisen aloittamisesta käytöstä poistumiseen • Vaihejakomalleilla kuvataan ohjelmiston elinkaaren eri vaiheita • malleista löytyy yleensä ainakin määrittely-, suunnittelu- ja toteutusvaiheet • Yleisin malli on vesiputousmalli

3. Ohjelmiston elinkaari mikä on ongelma, onko valmista ratkaisua, kustannukset, reunaehdot Esitutkimus millainen järjestelmä täyttää ongelman vaatimukset Määrittely miten järjestelmä toteutetaan ja ositetaan Suunnittelu Toteutus osien ohjelmointi osien yhtyeenliittäminen ja testaaminen Integrointi ja testaus Käyttöönotto ja ylläpito

4. Ohjelmiston elinkaari • Kaikkiin vaiheisiin liittyy tarkastuksia, katselmointeja ja testausta • laadunvarmistus • Tarkastuksilla ja testaamisella pyritään virheet kitkemään mahdollisimman aikaisessa vaiheessa • Katselmoinnit järjestetään yleensä tietyn vaiheen lopuksi • projektin tilanteen läpikäynti ja todennetaan, että kaikki tietyn vaiheen tavoitteet on saavutettu ja dokumentit ovat kunnossa

5. Ohjelmiston elinkaari • Esitutkimuksen tavoitteena on asettaa yleiset vaatimukset järjestelmälle • määrittävät yleensä asiakkaan tarpeet, asiakasvaatimukset • eivät ota kantaa millainen järjestelmän tulee olla • Esitutkimus antaa vastauksen kysymykseen, miksi järjestelmä tai ohjelmisto tulisi tehdä • tai miksi se pitäisi jättää tekemättä • Hyvän järjestelmän ehdoton edellytys on, että oikeat asiakasvaatimukset on saatu selville • suuri haaste on selvittää asiakkaan todelliset tarpeet ja ymmärtää ne perusteellisesti • Esitutkimus mielletään myös osaksi määrittelyä • tarpeiden analysointi ja tarkentuminen jatkuu läpi koko määrittelyvaiheen

6. Ohjelmiston elinkaari Esitutkimus: asiakasvaatimukset Järjestelmäsuunnittelu: järjestelmävaatimukset Laitteiston määrittely: laitteistovaatimukset Ohjelmiston määrittely: ohjelmistovaatimukset

7. Ohjelmiston elinkaari • Määrittelyvaiheessa asiakasvaatimuksista johdetaan ohjelmistovaatimukset • ohjelmistovaatimukset määrittelevät toteutettavan järjestelmän • Määrittelyvaiheessa tuotetaan dokumentti, jossa kuvataan ohjelmiston toiminnot, toteutuksen ei-toiminnalliset vaatimukset ja rajoitukset • toiminnallinen määrittely

8. Ohjelmiston elinkaari • Ohjelmiston toiminnoissa määritellään • toteutettavat ominaisuudet • käyttöliittymä • liitynnät muihin järjestelmiin • Ei-toiminnallisia vaatimuksia ovat • vasteajat • käytettävyys • suoritusteho

9. Ohjelmiston elinkaari • Rajoituksissa voidaan kuvata • käytössä oleva muistin määrä • tietty ohjelmointiympäristö • tietty käyttöjärjestelmä • Seuraavassa kuvassa on esitetty määrittelyprosessi

10. Ohjelmiston elinkaari määrittelyprosessi ideat, lähtökohdat rajoitteet, reunaehdot ongelman ymmärtäminen, vaatimusten kartoitus toteutettavan järjestelmän spesifiointi korjattavaa toiminnallinen määrittely, alustava käyttöohje, toteutusprojektin projektisuunnitelma, testaussuunnitelma tarkastus ok arkkitehtuurisuunnittelu

11. Ohjelmiston elinkaari IEEE830, toiminnallinen määrittely • 1. Johdanto • 1.1 Tarkoitus • - kenelle tarkoitettu • 1.2 Tuote • - kenelle tehty • - järjestelmän tavoitteet • 1.3 Määritelmät, termit ja lyhenteet • - Määritelmät, termit ja lyhenteet • esitellään tässä kohtaa • 1.4 Viitteet, muut tähän liittyvät • dokumentit • - mitä muita asiaan liittyviä dokumentteja on olemassa • 1.5 Yleiskatsaus dokumenttiin • - kuvataan dokumentin rakenne (lukijalle selviää, mutta kohdat dokumentista hänelle hyödyllisiä) • 2. Yleiskuvaus • 2.1 Ympäristö • - järjestelmän liittymät ympäristöön ja myös itse ympäristö • 2.2 Toiminta • - yleiskuvaus järjestelmän toiminnoista • 2.3 Käyttäjät • - järjestelmän käyttäjät ja käyttöympäristö (jos ei kuvattu edellisissä kohdissa) • 2.4 Yleiset rajoitteet • - lainsäädäntöön liittyvät • - toteutustyökaluihin liittyvät • 2.5 Oletukset ja riippuvuudet • - ne oletukset, joiden voimassa ollessa määrittely on voimassa (muiden projektien tuotokset, laitteistojen teho ja muisti…) • 3. Tiedot ja tietokanta • - tietosisällöt, tiedon pysyvyysvaatimukset, kapasiteetti- ja saantiaikavaatimukset järjestelmän käsittelemistä tiedoista ja tietokannoista

12. Ohjelmiston elinkaari • 4. Toiminnot • 4.n Toiminnon kuvaus • - jokaisesta järjestelmän toiminnosta kuvataan tarkoitus, mitä tarvitaan syötteinä, miten käsittely tapahtuu ja mitkä ovat vaikutukset (tulosteet) • 5. Ulkoiset liittymät • 5.1 Käyttöliittymä • - käyttöliittymä voidaan esitellä jo tässä vaiheessa tarkalla tasolla. Jos se esitetään yleisellä tasolla, niin tarkentaminen tehdään suunnittelu- vaiheessa • 5.2 Laitteistoliittymät • - liittymät oheislaitteisiin • 5.3 Ohjelmistoliittymät • - liittymät muihin ohjelmistoihin • 5.4 Tietoliikenneliitynnät • - tietoliikenneyhteydet • 6. Muut ominaisuudet • 6.1 Suorituskyky • 6.2 Käytettävyys, toipuminen, • turvallisuus ja suojaukset • 6.3 Ylläpidettävyys • 6.4 Siirrettävyys, yhteensopivuus • 7. Suunnittelurajoitteet • 7.1 Standardit • 7.2 Laitteistorajoitteet • 7.3 Ohjelmistorajoitteet • 7.4 Muut rajoitteet

13. Ohjelmiston elinkaari • Suunnitteluvaiheessa toimintojen toteutus suunnitellaan • määrittely muutetaan tekniselle kielelle eli järjestelmän toteutuksen kuvaukseksi • Suunnitteluvaihe jaetaan yleensä kahteen osaan • arkkitehtuurisuunnittelu • moduulisuunnittelu

14. Ohjelmiston elinkaari • Arkkitehtuurisuunnittelussa järjestelmä jaetaan moduuleihin, jotka ovat mahdollisimman riippumattomia toisistaan • osien työnjako ja rajapinnat • tavoitteena toisistaan riippumattomat moduulit, jolloin yhden moduulin muutokset eivät vaikuta muihin moduuleihin • uudelleenkäytettävyyteen pyrittävä • tekninen määrittely

15. Ohjelmiston elinkaari • Suunnittelun yleisiä tavoitteita ovat • selkeys • ymmärrettävyys • tehokkuus • luotettavuus • ylläpidettävyys • siirrettävyys

16. Ohjelmiston elinkaari • Määrittelyvaiheessa kerrotaan mitä järjestelmä tekee ja suunnitteluvaiheessa kerrotaan kuinka se tehdään • Seuraavassa kuvassa esitetään suunnitteluprosessi

17. Ohjelmiston elinkaari uudelleen käytettävät komponentit määrittely arkkitehtuuri- suunnittelu toiminnallinen määrittely tekninen määrittely korjattavaa moduuli- suunnitelmat moduulisuunnittelu, toteutussuunnittelu tarkastus korjattavaa koodi ohjelmointi tarkastus tarkastukseen, testaukseen

18. Ohjelmiston elinkaari IEEE1016, tekninen määrittely • 1. Johdanto • 1.1 Tarkoitus • 1.2 Dokumentin kattavuus • 1.3 Määritelmät, termit ja lyhenteet • 1.4 Viitteet, muut tähän liittyvät • dokumentit, standardeihin • 1.5 Yleiskatsaus dokumenttiin • 2. Järjestelmän yleiskuvaus • Sovellusalueen kuvaus, järjestelmän osuus siinä, laitteisto- ja ohjelmistoympäristön kuvaus, toteutuksen keskeiset reunaehdot ja järjestelmän liittyminen ympäristöönsä • 3. Arkkitehtuurin kuvaus • 3.1 Ratkaisuperiaatteet • 3.2 Tietokanta-arkkitehtuuri • 3.3 Ohjelmistoarkkitehtuuri moduulit ja prosessit • 3.4 Uudelleenkäytettävät komponentit • 4. Moduuli (ja prosessi) kuvaukset • 4.n Kustakin moduulista yleiskuvaus, attribuutit (ylläpidettävät tilatiedot), operaatiot (rajapinnat), poikkeus- ja virhetilanteiden käsittely, mahdolliset ohjeet moduulisuunnittelua ja toteutusta varten • Muita mahdollisia kohteita: • Ylläpito-ohjeet, siirrettävyys, luotettavuus, erityiset tekniset ratkaisut, hylätyt vaihtoehdot (ja miksi ne hylättiin), käyttöliittymä, rajoitteet, testattavuus

19. Ohjelmiston elinkaari • Ohjelmointivaiheessa ohjelma ”kirjoitetaan” • Yleensä ohjelmoija myös yksikkötestaa oman ”tekeleensä” ennen varsinaista testaus-vaihetta • Joskus erehdytään kuvittelemaan, että ohjelmistotekniikka sisältää vain ohjelmoinnin

20. Ohjelmiston elinkaari • Testauksen tavoite on yksinkertaisesti löytää ohjelmistosta virheitä • Testaus suoritetaan yleensä monella tasolla alkaen ohjelmointivaiheen yksikkötestauksella ja päättyen järjestelmätestaukseen • V-malli

21. Ohjelmiston elinkaari Testauksen v-malli Järjestelmä- testaus Määrittely testauksen suunnittelu ja tulosten verifiointi Integrointi- testaus Arkkitehtuuri- suunnittelu Moduuli- testaus Moduuli- suunnittelu Ohjelmointi

22. Ohjelmiston elinkaari • Moduulitestauksessa virheitä etsitään yksittäisistä moduuleista • testaus suunnitellaan moduulisuunnittelun yhteydessä • Integrointitestauksessa virheitä etsitään moduulien yhteistoiminnasta • testaus suunnitellaan arkkitehtuurisuunnittelun yhteydessä • Järjestelmätestauksessa virheitä etsitään koko järjestelmän toiminnoista ja suorituskyvystä • testaus suunnitellaan määrittelyvaiheessa

23. Ohjelmiston elinkaari • Mitä aikaisemmassa vaiheessa virheet löydetään, sitä halvemmaksi niiden korjaaminen tulee • Testaaminen vaatii erityistä tarkkuutta sen suorittajalta. Yksikään virhe ei saa lipsahtaa läpi huomaamatta • testaus voi olla erittäin yksitoikkoista ja ikävää ja samankaltaisia testitapauksia voi olla paljon

24. Ohjelmiston elinkaari • Käyttöönotto- ja ylläpitovaiheessa • käyttäjät koulutetaan • järjestelmä otetaan tuotantokäyttöön • ratkotaan asiakkaiden ongelmia • korjataan virheitä • muutetaan ohjelmaa vaatimusten muuttuessa • lisätään uusia ominaisuuksia ohjelmaan

25. Ohjelmiston elinkaari • Hyvä muistaa, että käytännössä ohjelmistokehitys ei etene orjallisesti vesiputousmallin mukaisesti • osa vaatimuksista selviää vasta projektin edetessä • vaatimukset muuttuvat projektin aikana • Pyrittävä kuitenkin toimimaan mallin mukaisesti mahdollisuuksien mukaan

26. Ohjelmiston elinkaari • Muita elinkaarimalleja ovat mm Evo-malli ja protoilumallit • Evo-mallissa pyritään ensimmäisessä vaiheessa rakentamaan perusjärjestelmä, jota myöhemmissä vaiheissa kehitetään • jokainen vaihe on vesiputousmallin mukainen • Evo-mallia voidaan käyttää • tuotekehitysprojekteissa, joiden tarkoituksena on julkistaa esimerkiksi vuosittain uusi versio tuotteesta • Yhdessä projektissa, jossa versioita tehdään n kappaletta ennen lopullista järjestelmää. Ominaisuuksia lisätään kierros kierrokselta

27. Ohjelmiston elinkaari Määrittely Määrittely Määrittely Suunnittelu Suunnittelu Suunnittelu Toteutus Toteutus Toteutus Testaus Testaus Testaus Versio 1 Versio 2 Versio 3

28. Ohjelmiston elinkaari • Evo-mallia sovellettaessa ongelmaksi saattaa muodostua julkaistun version virheiden korjaus ja asiakkaiden ongelmien ratkominen • kaikki projektilaiset ovat kiinni näissä tehtävissä ja seuraavaa versiota ei päästä kehittämään • Versioiden (inkrementtien) ominaisuudet tulee myös suunnitella järkevästi, ettei uusia ominaisuuksia lisätä liikaa tai liian vähän seuraavaan versioon

29. Ohjelmiston elinkaari • Protoilulla tarkoitetaan sitä, että tehdään jonkinlainen kokeilumalli ennen kuin varsinaista järjestelmää aletaan kehittämään • Protoilulla voidaan selvittää epäselviä asiakasvaatimuksia • Uudet tekniset ratkaisut voidaan testata prototyypeillä ennen kuin päätetään ratkaisun käyttöönotosta

30. Ohjelmiston elinkaari • Käyttöliittymien suunnittelu on järkevää tehdä protoilemalla • lopullisten käyttäjien hyväksyntä erittäin tärkeä • Suorituskyky voidaan etukäteen varmistaa erityisillä suorituskykyprototyypeillä

31. Ohjelmiston elinkaari • Kun prototyyppi on kehitetty, niin sen jälkeen on useita vaihtoehtoja jatkolle • ajateltu järjestelmä ei tuo asiakkaalle lisäarvoa ja projekti ”ammutaan alas” tai aloitetaan protoilu alusta hieman eri perspektiivistä • määritellään järjestelmä, jota aletaan kehittämään alusta alkaen uudestaan • jatketaan prototyypin kehittelyä oikeaksi järjestelmäksi • kahden viimeksi mainitun tapauksen välimuodot ovat yleisiä

32. Ohjelmiston elinkaari Varsinainen tuoteprojekti Proto-projekti Määrittely Määrittely Suunnittelu Suunnittelu Toteutus Toteutus Testaus Testaus Prototyyppi Järjestelmä

33. Ohjelmiston elinkaari Esitutkimusraportti Esikartoitus Määrittely Määrittely Projektisuunnitelma Arkkitehtuurisuunnittelu Ohjelmistoarkkitehtuuri Prototyyppi Tarkastus Järjestelmädokumentit Testitapaukset Asennettavan järjestelmän teko Käyttöohjeet Testaus Muutosten määrittely Toimitus ja hyväksymistestaus Testitulokset Käyttöönotto Ylläpito

34. Ohjelmiston elinkaari • Protoilun ongelmana on, että asiakas saattaa luulla järjestelmän olevan jo suurimmalta osin valmis • todellisuudessa ”demo-polut” ovat yleensä kapeita ja käyttäjien toimenpiteisiin vastataan esimerkiksi kovakoodatuilla viesteillä • Aina ei kannata protosta tehdä valmiin näköistä • asiakkaalle selviää ohjelmiston tarkoitus, mutta myös se, että työt ovat alkutekijöissään • Mitä ongelmia saattaa koitua edellisen kuvan protoilumallista?