2. Ohjelmistotuotantoprosessi Peruskäsitteet: prosessimalli: mahdollisimman yleisesti sovellettavissa oleva ohjeisto ohjelmistojen tuottamiseen ohjelmistotuotantoprosessi: yrityksessä käytössä oleva tapa tehdä ohjelmistoja projekti: prosessin ilmentymä: tietyn ohjelmiston laatiminen alusta loppuun Kevät 2005 Ohjelmistotuotanto / Taina 1 Prosessimalli Pelkän yleisperiaatteen kuvaus Ei sisällä konkreettisia yksityiskohtaisia toimintasääntöjä Voidaan käyttää eri organisaatioissa ja sovellusalueilla Yrityskohtaiset prosessi(malli)t yleensä perustuvat johonkin seuraavassa esiteltävistä yleisistä prosessimalleista Kevät 2005 Ohjelmistotuotanto / Taina 2 Prosessimallin vaihejako Prosessimallien perustehtävät Prosessimalli sisältää vaiheita: yleensä ennalta määrätty järjestys osavaihe tuottaa määritellyn tuloksen vaiheen tulos on syötteenä toiselle vaiheelle vaiheen valmistumiselle kriteerit Vaihejako voi perustua: tehtävän tyyppiin (esim. määrittely, suunnittelu, ) vaiheen sisältöön (esim. käyttöliittymä, tietokanta, ) Eri prosessimallit rajoittavat eri tavoin vaiheiden ajoitusta Jokaiseen prosessimalliin sisältyy tavalla tai toisella seuraavat perustehtävät: Vaatimusten keruu ja analyysi (vaatimusmäärittely) Ohjelmiston suunnittelu Toteutus ja yksikkötestaus Integrointi ja järjestelmätestaus Käyttö ja ylläpito Kevät 2005 Ohjelmistotuotanto / Taina 3 Kevät 2005 Ohjelmistotuotanto / Taina 4 Vaatimusmäärittely Mitä vaatimuksia ohjelmistolle asetetaan: mitä toimintoja sen pitää sisältää liittyykö toimintaan laadullisia vaatimuksia (esim. nopeuden tai käyttötavan suhteen) Mitä rajoituksia ohjelmiston toimintaan liittyy: esim. yhteistoiminta muiden ohjelmistojen kanssa Kevät 2005 Ohjelmistotuotanto / Taina 5 Ohjelmiston suunnittelu Suunnittelussa vaatimuksista lähtien jalostetaan toteutuskelpoinen kuvaus ohjelmistosta. Suunnittelu aloitetaan tekemällä arkkitehtuurisuunnitelma: ohjelman piirustukset. Arkkitehtuurisuunnitelmaaa ositetaan ja tarkennetaan halutulle tasolle. Kevät 2005 Ohjelmistotuotanto / Taina 6 Taina 1
Toteutus ja yksikkötestaus Toteutuksessa suunnitelman perusteella tehdään komponentteja. Ohjelmakomponentti: yhden asian kunnolla tekevä ohjelman osa, jolla on selkeä rajapinta ulospäin. Komponentti voi olla kooltaan mitä tahansa olioluokasta kokonaiseen ohjelmaan. Yksikkötestauksessa varmistetaan, että komponentit toimivat oikein. Kevät 2005 Ohjelmistotuotanto / Taina 7 Integrointi ja järjestelmätestaus Ohjelmakomponentit kootaan yhteen. Komponenttien välinen yhteistyö testataan integrointitestauksessa. Komponenteista kootaan osajärjestelmiä (käytännössä ohjelmia). Osajärjestelmien yhteistyö testataan. Järjestelmätestauksessa koko ohjelmisto testataan käyttöympäristössä Kevät 2005 Ohjelmistotuotanto / Taina 8 Ohjelmiston käyttö ja ylläpito Ohjelmistoa on usein tarvetta muuttaa myöhemminkin: Käytössä paljastuu virheitä. Käyttäjien vaatimukset täsmentyvät tai muuttuvat. Käyttöympäristö ja laitteisto muuttuvat. Käyttötavat muuttuvat. Ylläpito = ohjelmiston muuttaminen käyttöönoton jälkeen. Kevät 2005 Ohjelmistotuotanto / Taina 9 Yleisimmät prosessimallit Vesiputousmalli Prosessimallien perustehtävät suoritetaan peräkkäin palaamatta edellisiin vaiheisiin. Evoluutiomalli Ohjelmistosta tehdään useita vähän kerrassaan paranevia väliversioita. Komponenttimalli Ohjelmisto kootaan mahdollisimman pitkälle valmiista komponenteista. Kevät 2005 Ohjelmistotuotanto / Taina 10 Yleisimmät prosessimallit II 2.1. Vesiputousmalli Formaalit menetelmät Muunnos vesiputousmallista Suunnittelussa ja toteutuksessa käytetään hyväksi matemaattista mallia Vaikeinta on mallin löytäminen ja validointi. Iteratiiviset mallit Kehitystyö tehdään sykleittäin. Yhdessä syklissä ei välttämättä toteuteta kaikkia ohjelman osia. Kevät 2005 Ohjelmistotuotanto / Taina 11 Vanhin ja tunnetuin prosessimalli. Lineaarinen lähestymistapa: Jo päätettyyn vaiheeseen ei enää palata myöhemmin. Jokainen vaihe saatetaan loppuun, sen tulokset hyväksytään ja jäädytetään ennen seuraavaan vaiheeseen siirtymistä. Vaiheet = prosessimallin perustehtävät. Kevät 2005 Ohjelmistotuotanto / Taina 12 Taina 2
Vaatimusanalyysi Suunnittelu Toteutus Ylläpito Dokumentointi Testaus 1. Vaatimusanalyysi mitkä ovat järjestelmän palvelut rajoitukset tavoitteet? laaditaan ohjelmistoa kuvaava malli, jonka avulla voidaan tarkistaa vaatimusten järkevyys 2. Suunnittelu tarkennetaan vaatimusanalyysissa laadittua mallia: osajärjestelmät ja niiden välinen yhteistyö tarkennetaan jokainen osajärjestelmä halutulle abstraktiotasolle asti riittävä tarkkuus toteutuksen pohjaksi Kevät 2005 Ohjelmistotuotanto / Taina 13 Kevät 2005 Ohjelmistotuotanto / Taina 14 3. Toteutus (+yksikkötestaus) suunnitelma toteutetaan osa kerrallaan eri osat voidaan tehdä eri ohjelmointikielillä kukin osa (yksikkö) testataan toteutuksen jälkeen yksikkötestauksen menetelmät Malli perustuu vahvasti hyvään dokumentaatioon. 4. Integrointi ja testaus toimivista osista kootaan osajärjestelmiä ja näistä edelleen koko järjestelmä integrointitestaus: rajapintojen toimivuus koko järjestelmän verifiointi (selvitetään, että se toimii) ja validointi (selvitetään, että se tekee mitä halutaan) 5. Ylläpito käyttöönotto korjaukset, laajennukset Kevät 2005 Ohjelmistotuotanto / Taina 15 2.2 Evoluutiomalli Tavoitteena on ohjelmiston kehittäminen väliversioiden kautta: Väliversiot ovat joko tuotantokäytössä olevia ohjelmia tai prototyyppejä. Aloitetaan parhaimmin ymmärretyistä osista. Käyttäjä antaa palautetta väliversioista. Palautteen perusteella jatketaan kehitystä. Kevät 2005 Ohjelmistotuotanto / Taina 16 Evoluutiomallin vaiheet Evoluutiomallin edut Yleiskuvaus Määrittely Kehitystyö Validointi 1. Proto Väliproto Väliproto Valmis tuote Nopea reagointi asiakkaan tarpeisiin: Vaatimusten täsmällinen määrittäminen on usein vaikeaa. Kun asiakas näkee toimivan järjestelmän, hänen on helpompi kertoa, mitä hän tahtoo Väärinkäsitykset korjataan nopeammin, jolloin korjaus ei tule niin kalliiksi. Käyttöliittymä on koko ajan näkyvillä: Optimitilanteessa ohjelmiston käyttö on helppo oppia. Kevät 2005 Ohjelmistotuotanto / Taina 17 Kevät 2005 Ohjelmistotuotanto / Taina 18 Taina 3
Evoluutiomallin ongelmat Etenemisen seuranta: Milloin tuote oikeastaan on valmis? Rakenteelliset ongelmat: Jatkuvat muutokset voivat rikkoa suunnitellun arkkitehtuurin. Työvälineiden tarve (sovelluskehitin): Prototyyppien tekeminen vaatii sopivat välineet (ja taidon käyttää niitä). Kevät 2005 Ohjelmistotuotanto / Taina 19 Mitä prototyypille tehdään Prototyypin hylkääminen Tarkoituksena tarkentaa asiakkaan toiveita ja vaatimuksia Prototyypin kehittäminen eteenpäin Tarkoituksena esitellä asiakkaalle ydinohjelmisto tai jokin ydinohjelmistoon liitetty aputoiminto. Asiakkaan voi olla vaikeaa ymmärtää, miksi prototyyppi ei kelpaa lopputuotteeksi. Prototyyppi on esitoteutus. Prototyyppi ei täytä laadukkaalle ohjelmistolle asetettavia vaatimuksia. Kevät 2005 Ohjelmistotuotanto / Taina 20 2.3 Komponenttimalli Komponenttimallin työvaiheet Tavoitteena on käyttää mahdollisimman paljon jo valmiita komponentteja. Valmiita komponentteja saadaan omista aiemmista projekteista, ostamalla ja ilmaisista Free Software projekteista (vaarallisia, koska ylläpidosta ei ole takeita) Uudelleenkäytettäviä komponentteja pidetään komponenttikirjastossa. Kevät 2005 Ohjelmistotuotanto / Taina 21 Työvaiheet vesiputousmallin tapaan: Vaatimusmäärittely Etsitään ja analysoidaan vaatimuksia. Komponenttianalyysi Etsitään komponenttikirjastosta vaatimusanalyysin mukaiseen tuotteeseen sopivia komponentteja. Vaatimusten muokkaus Täydennetään vaatimuksia ottaen huomioon löydetyt komponenttiehdokkaat. Kevät 2005 Ohjelmistotuotanto / Taina 22 Komponenttimallin työvaiheet II Työvaiheet jatkuvat: Suunnittelu ja komponenttien eristys Eristetään komponenttikirjastoon omia kelvollisia komponenttiehdokkaiden suunnitelmia. Toteutus ja komponenttien eristys Eristetään komponenttikirjastoon omia kelvollisia komponenttiehdokkaiden toteutuksia. Järjestelmän validointi Varmistetaan, että tehtiin oikea järjestelmä. Kevät 2005 Ohjelmistotuotanto / Taina 23 2.4 Formaalit menetelmät Vastaavat vaiheet kuin vesiputousmallissa. Perustuu matemaattiseen malliin, jonka avulla määrittely muunnetaan ohjelmaksi. Ohjelman kehitys tapahtuu peräkkäisten muunnosten sarjana. Tarkkenevat esitysmuodot. Ohjelma voidaan todistaa oikeaksi mallien avulla: Lähtien ohjelmasta taaksepäin osoitetaan, että kunkin muunnoksen tulos vastaa yksikäsitteisesti syötettä. Kevät 2005 Ohjelmistotuotanto / Taina 24 Taina 4
Formaalit menetelmät Jos löydetään sopiva formalismi, menetelmä on erinomainen. Sopivia malleja on kehitetty vain eräille pienille hyvin määritellyille ongelma-alueille. Tiukat turvallisuus- ja luotettavuusvaatimukset. Uuden mallin kehittäminen on kallista ja vaatii suurta ammattitaitoa. Mallit ovat usein vaikeita ymmärtää ja selittää asiakkaille (tai edes työkavereille). 2.5 Iteratiiviset mallit Todellisissa ohjelmistoprojekteissa tarvitaan iterointia, koska vaatimuksia ei tunneta kunnolla, vaatimukset ovat epäselviä ja vaatimukset muuttuvat. Iteratiivisissa malleissa vaatimusten määrittely ja ohjelmiston kehitys limittyvät. Kevät 2005 Ohjelmistotuotanto / Taina 25 Kevät 2005 Ohjelmistotuotanto / Taina 26 Lisäävä malli Spiraalimalli Ohjelmisto jaetaan osiin jotka toteutetaan omina sykleinään. Ensiksi ydin, johon seuraavien syklien tulokset voidaan liittää Vain yhden syklin vaatimukset kerrallaan Toteuttamattomien syklien vaatimukset voivat muuttua Vaatimusten prioriteettijärjestys: tärkeimmät vaatimukset ytimeen seuraavissa sykleissä vähemmän tärkeät vaatimukset Pyrkii yhdistämään vesiputousmallin ja evoluutiomallin edut: hyvin määritelty rakenne eteneminen versioittain Kukin spiraalin kierros esittää yhtä prosessin työvaihetta Neljä sektoria: tehtävän asetus = tavoite ja aikataulu riskianalyysi = mitkä ovat tärkeimmät riskit kehitystyö ja validointi suunnittelu = tuloksen arviointi ja seuraavan vaiheen suunnittelu Ei kiinteitä tehtäviä Kussakin kierroksessa voidaan käyttää muita prosessimalleja Esim. 1. kierros = vaatimusanalyysi prototyyppejä käyttäen 2. kierros suunnittelu vesiputousmallina Sopii myös ylläpitoon Kevät 2005 Ohjelmistotuotanto / Taina 27 Kevät 2005 Ohjelmistotuotanto / Taina 28 Spiraalimalliesimerkki Ketterät prosessimallit Determine objectives alternatives and constraints Plan next phas e Kuvalla (C) I. Sommerville 2004 REVIEW Requirements plan Life-cycle plan Development pl an Integration and test plan analys is analysis analysis Prototype 3 Prot otype 2 analysis Prototype 1 C oncept of Operati on Requirement validation S/W requirements Design V&V Acceptance Service test Operati onal protoyp e Simulations, models, b enchmarks Prod uct desi gn Integr ation test Evaluate alternatives identify, resolve risks Code Unit test Detailed desi gn Develop, verify next-level product kehitetään ohjelmaa hyvin pieninä lisäyksinä aluksi pieni ydin lisätään sykli kerrallaan mahdollisimman pieni järkevä joukko ominaisuuksia toteutusjärjestys määräytyy asiakkaiden tarpeista joustavuus: projektia suunnitellaan vain mahdollisimman lyhyt aika eteenpäin dokumentaatio = koodi tunnetuin ketterä prosessimalli: Extreme programming (XP) Kevät 2005 Ohjelmistotuotanto / Taina 29 Kevät 2005 Ohjelmistotuotanto / Taina 30 Taina 5