010758000 Ohjelmistotekniikka - Yleiskuva ohjelmistotuotannosta

1. 010758000 Ohjelmistotekniikka- Yleiskuva ohjelmistotuotannosta . Kevät 2003 Hanna-Kaisa Lammi LTKK/Tite

2. Sisältö • Ohjelmiston elinkaari • Ohjelmistokehityksen vaihejakomalleja • Ohjelmistokehityksen tukitoimintoja • Ohjelmiston elinkaarikustannuksista

3. Ohjelmistotuotannon osa-alueita Haikala, Märijärvi: Ohjelmistotuotanto, 2000.

4. Termejä • Ohjelmiston elinkaari (life cycle) on aika, joka kuluu ohjelmiston kehittämisen aloittamisesta sen poistamiseen käytöstä • Vaihejakomallilla (process model) tarkoitetaan tapaa, jolla ohjelmiston kehitystyö tai koko elinkaari jaetaan vaiheisiin • Ohjelmisto vai tuote?

5. Ohjelmiston elinkaari Tuotteen / ohjelmiston ylläpito Tuote versio 1 Tuote versio 2 … Tuote versio N Tuotteen / ohjelmiston kehitys TUOTTEEN / OHJELMISTON ELINKAARI

6. Ohjelmistokehityksen vaiheet Esitutkimus Asetetaan asiakasvaatimukset: mitä asiakas haluaa? Miksi ohjelmisto tulisi tehdä? Analysoidaan asiakasvaatimukset: mitä voidaan toteuttaa? Johdetaan ohjelmistovaatimukset: mitä projektissa tehdään? Määrittely Suunnitellaan, kuinka määrittelyssä kuvatut vaatimukset toteutetaan. (Arkkitehtuurisuunnittelu, modulisuunnittelu) Suunnittelu Toteutetaan suunniteltu. Toteutus Integrointi: yhdistetään toteutetut osat niin, että niistä saadaan yksi toimiva kokonaisuus. Testaus: etsitään ohjelmiston virheitä ja korjataan ne. Integrointi ja testaus Käyttöönotto: toimitaan ohjelmisto asiakkaalle Ylläpito: ratkotaan asiakkaan ongelmia, korjataan virheitä, muutetaan tarvittaessa ohjelmistoa uusia vaatimuksia vastaavaksi. Käyttöönotto ja ylläpito

7. Vaatimusten kertyminen

8. Määrittely Suunnittelu& toteutus Vaatimuksesta tuotteeksi asiakasvaatimukset ohjelmistovaatimukset

9. Projektin eteneminen • Projektissa toteutetaan vain juuri se, mitä asiakas halusi. Asiakas ei maksa ylimääräisistä ominaisuuksista! • Projektissa noudatetaan niin hyvää laatua, kuin asiakas halusi. Asiakas ei maksa ylihyvästä laadusta! Toisaalta jokainen projektissa työskentelevä on velvollinen tekemään niin hyvää työtä kuin aikataulun ja budjetin rajoissa on suinkin mahdollista.

10. Vaihejakomalleja • vesiputousmalli (waterfall model) • evoluutiomalli (evolutionary models) • protoilumallit (prototyping models) • spiraalimalli (spiral model) Näistä kolme viimeistä mallia ovat iteratiivisia.

11. Esimerkki vesiputousmallista Käytetään nopeassa komponenttipohjaisessa kehityksessä, jossa vaatimukset ovat alussa hyvin selvillä. Esitutkimus Määrittely Suunnittelu Toteutus Integrointi ja testaus Käyttöönotto ja ylläpito

12. Käytetään, kun heti alussa ei tarkasti tiedetä mitä halutaan. Vaatimukset tarkentuvat joka kierroksella: riski pienenee.

13. ... Määrittely Määrittely Määrittely Suunnittelu Suunnittelu Suunnittelu Toteutus Toteutus Toteutus Testaus Testaus Testaus Versio 1 Versio 2 Versio 3 Esimerkki evoluutiomallista Haikala, Märijärvi: Ohjelmistotuotanto, 2000.

15. Esimerkki spiraalimallista Tuotekonseptin- kehitysprojekti Uuden tuotteen kehitysprojekti Tuotteen kehitys- projekti Tuotteen ylläpito- projekti = Projektin aloituspiste

16. Ite Iter. Iter. Iter. Iter. Iter. Iter. Iter. Iter. Iter. Iter. Iter. Iter. r. Inception Elaboration Construction Transition - Installointivalmis - Tuotteen ominaisuudet - Täydennetyt mallit - Lähes täydelliset ohjelmisto - Alustavat mallit - Toteutettu toimiva mallit - Byrokratiadokumentit - Alustava tuotearkkitehtuuri perusarkkitehtuuri - Beta-versio - Täydelliset mallit - Tarvittaessa proto - Arkkitehtuurikuvaus - Arkkitehtuurikuvaus - Arkkitehtuurikuvaus - Riskit - Riskit - Seuraavan vaiheen - Käsikirjat - Alustava projektisuunnitelma - Seuraavan vaiheen projektisuunnitelma - WWW-palvelut yms. - Onnistumiskriteerit projektisuunnitelma - Onnistumiskriteerit - Onnistumiskriteerit - Käyttöohje - Alustava käyttöohje RUP (Rational Unified Process) esimerkkinä EVO- ja spiraalimalleista Haikala, Märijärvi: Ohjelmistotuotanto, 2000. Alkuperäinen lähde: Jacobson et al. 1998

17. RUP-iteraation vaiheet

18. Construction Inception Elaboration Transition Requirements Analysis Design Implementation Test ... iter. 1 iter. 2 ... ... .... .... .... ... Työmäärien jakautuminen RUP-prosessissa Haikala, Märijärvi: Ohjelmistotuotanto, 2000. Alkuperäinen lähde: Jacobson et al. 1998

19. Esimerkkejä protoilumallista Haikala, Märijärvi: Ohjelmistotuotanto, 2000.

20. Muita prosessimalleja • Prosessimalleja on lukuisia muitakin, esim: • Component Assemble Model: kun käytetään paljon jo valmiita komponentteja • Concurrent Process Model: projektin eri osia tehdään rinnakkain toisistaan erillään • Formal Methods: matemaattisia ohjelmistoja rakennettaessa • Cleanroom software engineering: pyritään löytämään ohjelmistovirheet ennen testausta

21. Esimerkki sulautettujen järjestelmien kehittämismallista

22. Prosessimallin soveltaminen • Prosessimallia tulee aina soveltaa juuri kyseiseen projektiin sopivalla tavalla! • Soveltamistapa riippuu projektin koosta ja sen erityispiirteistä. • Maalaisjärjen käyttö on erittäin suotavaa ellei jopa pakollista!

23. Asiakas- ja tuotekehitys-prosessien suhde Asiakkaan prosessit • tuoteideat • markkinatutkimukset ja kilpailija-analyysit • myynti ja markkinointi • tuotteen/ohjelmiston testaaminen ja koulutus • … Ohjelmistotuotantoprosessi Toiminta on siis koko ajan rinnakkaista ja molempien tahojen tulisi koko ajan saada tietoa toistensa edistymisestä.

24. Tarvittavat tukitoiminnot • Laadunvarmistus • Dokumentointi • Tuotteenhallinta • Vaatimustenhallinta • …

25. Mitä on laatu? • Ohjelmistotuotteen kykyä täyttää käyttäjänsä kohtuulliset toiveet ja odotukset • Laatu on subjektiivinen, käyttäjästä ja käyttöympäristöstä riippuva käsite • Toiminnan laatu ja tuotteen laatu on erotettava toisistaan • Toiminnan hyvä laatu tarkoittaa lopputuotteen laatuun positiivisesti vaikuttavia toimintatapoja

26. Yrityksen laatujärjestelmä • Laatujärjestelmä kertoo tavan, kuinka yrityksessä tehdään ohjelmistoja ja tuotteita • Tavoitteena taata, että tuotantoprosessi tuottaa suunniteltua laatutasoa vastaavia tuotteita aikataulun ja budjetin mukaisesti • Kuvaus yrityksen laatukäsikirjassa • Laatusertifikaatti todiste siitä, että yritys toimii laatujärjestelmänsä mukaisesti, mutta se ei todista laatujärjestelmän erinomaisuutta

27. Laadunvarmistustoiminta • Mitä kauemmin virheet ovat järjestelmässä, sen kalliimmaksi ne tulevat. • Terveydenhoito: toimintatavat, jotka vähentävät virheitä. • Sairaanhoito: virheiden seulominen mahdollisimman aikaisessa vaiheessa: tarkastukset.

28. 60 - 100 X Muutoksen hinta Muutoksen tekeminen eli esim. havaitun virheen korjaaminen on sitä kalliimpaa mitä myöhemmin muutos tehdään. Siksi virheiden löytämiseen pitäisi panostaa kaikissa projektin vaiheissa! 1,5 - 6 X 1x Kehitys Ylläpito Määrittely

29. Tarkastukset ja katselmoinnit, esimerkki Haikala, Märijärvi: Ohjelmistotuotanto, 2000.

30. Esitutkimus Suunnittelu Alustava sopimus, Tekninen määrittely, alustava projektisuunnitelma, integrointitestaussuunnitelma, alustava toiminnallinen määrittely, tarkennettu käyttöohje, alustava toteutussuunnittelu, alustava ylläpito-ohje, alustava testaussuunnittelu, alustava operointi/huolto-ohje, alustava tuotteenhallintasuunnitelma, alustava asennusohje. alustava laatusuunnitelma, dokumentointisuunnitelma. Toteutus Määrittely Moduulisuunnitelmat, moduulitestaussuunnitelmat, Tarkennettu sopimus, moduulitestauspöytäkirjat, tarkennettu projektisuunnitelma, koodimoduulit, toiminnallinen määrittely, integrointitestaussuunnitelma, alustava tekninen määrittely, integrointitestauspöytäkirjat, tarkennettu testaussuunnitelma integroitu ohjelmisto, (järjestelmä- ja hyväksymistestaus) tarkennettu ylläpito-ohje, tarkennettu tuotteenhallintasuunnitelma, tarkennettu operointi/huolto-ohje, tarkennettu laatusuunnitelma, tarkennettu asennusohje. alustava käyttöohje. Testaus Järjestelmätestauspöytäkirjat, hyväksymistestauspöytäkirjat, paketointi-ohje, koulutusmateriaali, tuotedokumenttien viimeistellyt versiot Dokumentointi, esimerkki Haikala, Märijärvi: Ohjelmistotuotanto, 2000.

31. Tuotteenhallinta Haikala, Märijärvi: Ohjelmistotuotanto, 2000.

32. Alustavat asiakasvaatimukset Vaatimustenhallinta: kartoitus, analysointi, jäljitettävyys, muutokset Vaatimukset Hallitut muutokset ominaisuus 1 Kelpuutetut moduuli a Toiminto 1 2 1 5 5 2 5 5 2 5 moduuli b 1 2 1 5 2 2 5 5 5 1 1 5 2 Toiminto 2 1 1 moduuli c 5 Myöhempään 5 2 2 2 5 5 2 2 2 versioon 2 moduuli d 1 1 1 1 5 2 2 1 2 8 7 6 3 5 Toiminto 3 5 2 5 5 2 Hylätty 2 moduuli e 2 1 1 2 1 1 moduuli f 1 4 5 1 ominaisuus 2 Järjestelmän Toteutettu Analysoidut Ohjelmisto- tekninen järjestelmä vaatimukset vaatimukset: määrittely Järjestelmän toiminnallinen määrittely Vaatimusten hallinta

33. Mitä siis asiantuntijan pitäisi osata? Johtamis- taidot Esiintymis- ja Neuvottelutaidot, Ryhmätyötaidot Erityisalueen tekninen osaaminen Yleinen tekninen osaaminen Sovellusalueen asiantuntemus Prosessi- osaaminen

34. Tuotteen elinkaarikustannukset

35. Arvoketju, esimerkki

36. Ohjelmistoprojekti • Esitutkimusprojekti • Määrittelyprojekti • Toteutusprojekti • Käyttöönottoprojekti • Koulutusprojekti • Nyrkkisääntö: projekti ei saisi kestää yli vuotta

37. Toimitusprojekti

38. Ohjelmistoprojektin ongelmia epärealistiset aikataulut ja budjetit sovellusalueen huono tuntemus vaatimusten muuttuminen projektin aikana tekniikan huono tuntemus henkilöstöongelmat asiakas ei tiedä mitä haluaa työmääräarviot pettävät, budjetit ylittyvät

39. Onko järkevä tuotantoprosessi edes mahdollinen? • Parnas&Clemens: • Ohjelmistolle asetettavat vaatimukset eivät juuri koskaan ole täysin tunnettuja alkuvaiheessa • Vaikka vaatimukset tunnettaisiinkin, monet toteutukseen liittyvät seikat selviävät vasta projektin aikana • Vaikka kaikki tosiseikat olisivatkin tiedossa jo alussa, on tosiseikkoja niin paljon, ettei ihminen pysty käsittelemään niitä virheettömästi • Vaikka tosiseikat pystyisikin käsittelemään virheettömästi, ne voivat muuttua ulkoisista syistä

40. Onko järkevä tuotantoprosessi mahdollinen? • Ihminen takertuu aikaisemmin oppimiinsa ratkaisuihin, jolloin rationaalisesti perusteltavissa oleva ratkaisu jää huomaamatta • Aikaisemmin kirjoitettujen ohjelmien uudelleenkäyttö johtaa myös usein omituisiin ratkaisuihin

41. Kannattaako siis edes yrittää? • Kannattaa, koska prosessit • antavat ohjeita mitä missäkin vaiheessa pitäisi tehdä • helpottavat siirtymistä projektista toiseen, jos ne muistuttavat toisiaan • projektinhallinta helpottuu • ulkopuolisen arvioijan helpompi arvioida projektin tilannetta • mahdollistavat mittatietojen keräämisen ja toiminnan kehittämisen tähän perustuen • Programming-in-large vs. programming-in-small eli suurissa projekteissa enemmän systemaattisuutta kuin pienissä