581259-4 Ohjelmistotuotanto Juha Taina Helsingin yliopisto Tietojenkäsittelytieteen laitos 1. Johdanto Mitä on ohjelmistotuotanto? Ohjelmisto, ohjelmointi, tekniikkaa, insinööritaitoa, kurinalaisuutta, systemaattisia menetelmiä. Alkuperäinen määritelmä: P. Naur, R. Randell (eds.): Sofware Engineering: A Report on a Conference Sponsored by the NATO Science Committee. Nato, 1968: The establishement and use of sound engineering principles in order to obtain economically software that is reliable and works efficiently on real machines. Synty-ympäristö 60-luvun ohjelmistokriisi: miten pystytään täyttämään yhä lisääntyvä ohjelmistokysyntä. Sivu - 2-1
Ohjelmistotuotannon ongelmia Ohjelmistojen koon ja monimutkaisuuden jatkuva kasvu. Yhä vaikeampia ongelmia ratkotaan tieto- ja ohjelmistoteknisin keinoin. Yli 10 miljoonan koodirivin isot ohjelmat yleistyvät jatkuvasti. Tuotantoprosessin määrittely ja mittaaminen. On vaikeaa hallita prosessia, jos sitä ei voida mitata. Liikaa taidetta, liian vähän raakaa työtä. Tuotteen määrittely Asiakas ei tiedä mitä haluaa. Tieteellisten menetelmien puute. Sivu - 3 - Ongelmat jatkuvat Tuotteen laadun tai toimivuuden varmistus. Formaali määrittely on vaikeaa. Täysin kattava testaus on mahdotonta. Jälkihoidon raskaus. Usein ylläpitokustannukset ovat huomattavasti suuremmat kuin kehityskustannukset. Etukäteisarviointi. Projektin vaatiman työmäärän arviointi onnistuu liian harvoin. Teorian puuttuminen. Tieteellisen pohjan puuttuminen. Ohjelmistotuotanto perustuu enemmän hyväksi havaittuihin menetelmiin kuin eksaktiin tieteeseen. Sivu - 4-2
Ongelmista ei päästä vieläkään eroon Standardiosien puute. Vain pieni osa (10-20%) kirjoitettavasta koodista on todella uutta. Kaikki muu on joskus kirjoitettu jossain. Tieteellisen tutkimustyön ja käytännön tuotantotyön välinen kuilu. Usein tieteellinen tutkimusongelma ei kohtaa käytännön ongelmaa. Tieteelliset tulokset sopivat usein tarkasti yhteen tiettyyn pienehköön ongelmaan. Yrityksissä ei tunneta uutta tutkimusta. Yritysten ratkaisut ovat teknologiakeskeisiä. Yritykset eivät pitkäjännitteisesti ratko ohjelmistotuotannon perusongelmia. Sivu - 5 - Kysy ohjelmistotuotannosta Mikä on ohjelmisto? Toisiinsa sidoksissa olevat tietokoneohjelmat, niiden dokumentaatio ja käytetyt konfigurointitiedostot. Mitä on ohjelmistotuotanto? Kaikkiin ohjelmiston tuotannon osa-alueisiin vaikuttavaa insinööritaitoa ja -toimintaa (Sommerville, vapaa käännös). Myös alkuperäinen -68 annettu määritelmä on varsin hyvä. Onko ohjelmistotuotanto tiedettä? Tästä käydään jatkuvaa kädenvääntöä. Ohjelmistotuotannossa on paljon tiedettä, mutta on myös alueita, jotka eivät perustu esitettyihin todennettaviin teorioihin vaan käytännössä hyviksi koettuihin menetelmiin. Toistaiseksi ohjelmistotuotanto on (valitettavasti) enemmän insinöörityötä kuin tiedettä. Sivu - 6-3
Kysy lisää ohjelmistotuotannosta Mikä on ohjelmistotuotantoprosessi? Joukko toimintoja, joiden tarkoituksena on ohjelmiston kehittäminen tai ylläpito. Mikä on ohjelmistotuotannon prosessimalli? Yksinkertaistettu esitys ohjelmistotuotantoprosessista. Mallissa keskitytään suuriin kokonaisuuksiin yksityiskohtien kustannuksella. Miten ohjelmistotuotannon kustannukset jakautuvat? 60% kehitystyötä, 40% testausta (arvio). Ylläpitokustannukset saattavat helposti ylittää tuotantokustannukset. Lisää kysymyksiä: Sommerville luku 1.1 Sivu - 7-1.1. Järjestelmäsuunnittelu Järjestelmäsuunnittelu (system engineering - huono käännös) käsittelee järjestelmiä kokonaisuuksina. Järjestelmä on joukko toisiinsa liittyviä komponentteja, jotka toteuttavat yhdessä ennalta määritellyn toiminnallisuuden. Järjestelmään kuuluu yleensä ainakin laitteisto- ja ohjelmistokomponentteja, käyttäjiä ja käyttöympäristö. Järjestelmäsuunnittelu käsittelee järjestelmien määrittelyä, suunnittelua, toteutusta, käyttöönottoa ja käytettävyyttä. Sivu - 8-4
Järjestelmäsuunnittelu: so what? Miksi ohjelmistotuotannossa pitää tietää järjestelmäsuunnittelusta? Koska ohjelmistotekniikan asiantuntijoiden täytyy ymmärtää koko järjestelmän toiminta voidakseen tuottaa laadukkaita ohjelmistoja. Koska useista ohjelmistotekniikan asiantuntijoista tulee yrityksissä koko järjestelmän asiantuntijoita. Koska ohjelmisto on erottamaton osa (ohjelmistopohjaista) järjestelmää. Kurssin kannalta kiinnostavimpia järjestelmiä ovat tietokonepohjaiset järjestelmät, sillä ne usein sisältävät yllättävänkin suuria ohjelmistoja. Ei ole ohjelmistoa ilman sen sisältämää järjestelmää. Sivu - 9 - Osajärjestelmät Järjestelmäsuunnittelussa järjestelmä jaetaan usein osajärjestelmiin. Jokainen osajärjestelmä on itsenäinen kokonaisuus, joka toimii yhteistyössä muiden osajärjestelmien kanssa. Jokainen osajärjestelmä voidaan jakaa edelleen ohjelma- ja laitteistokomponentteihin. Nämä komponentit puolestaan toimivat yhteistyössä täyttääkseen osajärjestelmien tehtävät. Käyttäjät ovat osa järjestelmää käyttäessään järjestelmän toimintoja osajärjestelmien kautta. Sivu - 10-5
Järjestelmät ja ympäristö Järjestelmät eivät toimi yksin, vaan ne toimivat ja vaikuttavat jossain ympäristössä. Esimerkiksi käyttäjille uuden järjestelmän käyttöönotto voi vaikuttaa toimintatapoihin: käyttö saattaa erota vanhan järjestelmän käytöstä. Tarvitaan käyttökoulutusta. työtehtäviin: järjestelmä saattaa luoda uusia työtehtäviä ja tehdä joistain vanhoista turhia. Tarvitaan organisaation sisäisiä työtehtävien järjestelyä. organisaatioon: uuden järjestelmän järjestelmäasiantuntijat saattavat saada lisää vaikutusmahdollisuuksia. Muutos voi olla suuri, ja siihen pitää varautua. Sivu - 11 - Järjestelmäsuunnitteluprosessi Uutta järjestelmää kehitettäessä tai vanhaa parannettaessa tarvitaan kehys, minkä mukaan voidaan rakentaa varsinainen projektisuunnitelma. Tämä kehys, järjestelmäsuunnitteluprosessi, sisältää seuraavat työvaiheet: 1. Vaatimusten määrittely 2. Koko järjestelmän suunnittelu 3. Osajärjestelmien kehitystyö 4. Järjestelmän integrointi 5. Järjestelmän asennus 6. Järjestelmän ylläpito 7. Järjestelmän alasajo Sivu - 12-6
Järjestelmäsuunnitteluprosessi - osa II Näyttääkö tutulta? Aivan, tämä muistuttaa suuresti perinteistä ohjelmistotuotannon vesiputousmallia Itse asiassa vesiputousmalli on saanut paljon vaikutteita huomattavasti vanhemmasta järjestelmäsuunnitteluprosessista. Erojakin toki on: Eri insinöörialoilla on oma sanastonsa, periaatteensa ja standardinsa. Järjestelmäsuunnittelussa on suuri riski siinä, että eli osajärjestelmien asiantuntijat eivät ymmärrä toisiaan. Muutokset ovat kalliita. Jostain riippusillasta ei tuosta vaan rakenneta prototyyppiä, mikä sitten voidaan heittää menemään. Kun jokin suunnittelupäätös on tehty, siinä myös pysytään. Sivu - 13 - Järjestelmäsuunnittelun menetelmät Järjestelmäsuunnittelussa voidaan käyttää samoja menetelmiä kuin ohjelmistotuotannossa. Vai meneekö tämä päin vastoin? Ohjelmistotuotannossa voidaan käyttää samoja menetelmiä kuin järjestelmäsuunnittelussa. Joka tapauksessa jatkossa esiteltävät menetelmät sopivat sellaisenaan tai soveltuvin osin myös järjestelmäsuunnitteluun. Esimerkiksi koko järjestelmä on järkevää kuvata kaaviolla, joka sisältää osajärjestelmät ja niiden väliset yhteistyötavat. Sivu - 14-7
Esimerkkijärjestelmä (Sommerville) Radar system Transponder system Data comms. system Aircraft comms. Telephone system Position processor Backup position processor Comms. processor Backup comms. processor Aircraft simulation system Flight plan database Air Traffic Control system architecture Weather map system Accounting system Controller info. system Controller consoles Kuvalla (C) I. Sommerville 2000 Activity logging system Sivu - 15 - Se järjestelmäsuunnittelusta Järjestelmäsuunnittelu on hankalaa. Sen lisäksi, että ohjelmiston on sovittava järjestelmään, myös osajärjestelmien on sovittava yhteen. Ohjelmistoa pidetään usein syntipukkina ongelmiin, vaikka syyt saattavat olla huonossa järjestelmäsuunnittelussa. Ohjelmistoasiantuntijoilla ei ole hyviä vastauksia järjestelmäsuunnittelun vaikeisiin kysymyksiin. Vähin, mitä voidaan vaatia, on että ohjelmistotuotannossa otetaan ympäröivä järjestelmä mahdollisimman hyvin huomioon. Sivu - 16-8
2. Ohjelmistotuotantoprosessit Ohjelmistotuotantoprosessin systematisoimiseksi on kehitetty lukuisia prosessimalleja. Malli = mahdollisimman yleisesti sovellettavissa oleva ohjeisto ohjelmistojen tuottamiseen. Malli ei tarjoa konkreettisia yksityiskohtaisia toimintasääntöjä, vaan se on pelkän yleisperiaatteen kuvaus. Malli on käytettävissä eri organisaatioissa ja sovellusalueilla. Nykyisin käytännössä jokaisella itseään kunnioittavalla ohjelmistoja tuottavalla yrityksellä on oma prosessimalli. Nämä yrityskohtaiset prosessimallit yleensä perustuvat johonkin tässä luvussa esitellyistä yleisistä prosessimalleista. Sivu - 17 - Prosessimallien perustehtävät Vaikka prosessimalleja on lukuisia, niillä kaikilla on yhteisiä perustehtäviä. Näitä ovat: Ohjelmiston määrittely. Ohjelmistolle asetetut vaatimukset ja ohjelmistoon liittyvät rajoitukset on selvitettävä. Ohjelmiston suunnittelu ja toteutus. Määrittelyn mukainen ohjelmisto pitää saattaa suoritettavaan kuntoon. Ohjelmiston verifiointi ja validointi. Verifiointi tarkastaa, että ohjelmisto toimii virheettömästi. Validointi tarkastaa, että ohjelmisto toteuttaa sille määrittelyssä asetetut vaatimukset. Ohjelmiston ylläpito. Ohjelmisto muuttuu elinkaarensa aikana, kun ohjelmiston käyttäjien vaatimukset, käyttöympäristö ja laitteisto muuttuvat. Sivu - 18-9
Prosessimallin vaihejako Jokainen prosessi on jaettavissa osavaiheisiin, joilla on ennalta määrätty suoritusjärjestys. Vaihejaossa jokainen osavaihe tuottaa määritellyn tuloksen, osavaiheen tulos toimii syötteenä seuraavalle osavaiheelle, osatulokset ohjaavat seuraavan osavaiheen suoritusta, osavaiheiden tulokset ovat jollain määritellyillä kriteereillä hyväksyttävissä/hylättävissä ja jokaisen osavaiheen alku ja loppu ovat selvästi havaittavissa Käytännössä prosessi on aina iteratiivinen. Yhtä tulosta tarkennetaan, siirrytään seuraavaan, palataan takaisin edelliseen jne. Sivu - 19-2.1. Vesiputousmalli Vesiputousmalli on vanhin julkaistu ohjelmistotuotannon prosessimalli. Sen juuret ovat vahvasti systeemisuunnittelussa. Vesiputousmallin lähestymistapa on lineaarinen. Jo päätettyyn työvaiheeseen ei enää palata myöhemmin. Jokainen työvaihe on saatettava päätökseen ja tulokset on hyväksyttävä ja jäädytettävä ennen seuraavaan työvaiheeseen siirtymistä. Prosessimallien perustehtävät muodostavat vesiputousmallin työvaiheet. Sivu - 20-10
Vesiputousmallin työvaiheet 1. Vaatimusten kartoitus ja vaatimusanalyysi Järjestelmän tarjoavat palvelut, rajoitukset ja tavoitteet selvitetään. Vaatimuksien perusteella tehdään ohjelmistosta yksi tai useampi malli, joita käytetään vaatimusten järkevyyden tarkistukseen. 2. Suunnittelu Vaatimusanalyysista saatu mallia tarkennetaan, jolloin järjestelmästä tarkentuvat osajärjestelmät ja niiden välinen yhteistyö. Jokainen osajärjestelmä tarkennetaan halutulle abstraktiotasolle asti. 3. Toteutus ja yksikkötestaus Suunnitelma toteutetaan yhdellä tai useammalla ohjelmointikielellä. Aina yhden jakamattoman osan toteutuksen jälkeen se testataan yksikkötestauksen menetelmin. Sivu - 21 - Vesiputousmallin työvaiheet - II 4. Integrointi- ja järjestelmätestaus Yksittäiset ohjelman osat integroidaan osajärjestelmiksi, minkä jälkeen osajärjestelmät integroidaan valmiiksi järjestelmäksi. Samalla suoritetaan integrointitestausta, millä varmistetaan rajapintojen toimivuus. Integrointitestauksen jälkeen koko järjestelmä verifioidaan (selvitetään, että se toimii) ja validoidaan (selvitetään, että se tekee mitä halutaan). 5. Ylläpito Ohjelmisto otetaan käyttöön ja sen käyttöä valvotaan. Ongelmatapauksissa ja vaatimusten muuttuessa ohjelmistosta voidaan tehdä korjattuja/uusia versioita, jolloin ylläpitovaihe vaikuttaa kaikkiin aikaisempiin työvaiheisiin. Malli perustuu vahvasti hyvään dokumentaatioon. Sivu - 22-11
Vesiputousmallin työvaiheet Vaatimusanalyysi Suunnittelu Toteutus Testaus Ylläpito Dokumentointi Sivu - 23-2.2. Prototyyppimalli Prototyyppimallissa (tai Sommervillen mukaan Evoluutiokehitysmallissa, Evolutionary development) ohjelmisto kehitetään iteratiivisesti vaiheittain. Ensin tuotetaan yksikertainen prototyyppi mahdollisimman nopeasti. Asiakas arvioi proton, ja arvion perusteella suunnitellaan seuraava versio. Prosessia jatketaan, kunnes ollaan saatu viimeisellä iteraatiolla lopullinen versio. Ensimmäiset prototyypit sisältävät sellaisia osia, jotka ovat näkyvissä käyttäjille. Toteutus voi olla aluksi hyvin kevyttä. Käyttöliittymä on alusta asti mukana. Sivu - 24-12
Prototyyppimallin ihmeitä Usein prototyyppimallissa ei käytetä selkeää tehtävien vaihejakoa. Protoa kehitettäessä saatetaan olla samanaikaisesti määrittely-, suunnittelu- ja toteutusvaiheessa. Asiakas on jatkuvasti mukana prosessissa. Seuraavan iteraatiokierroksen prototyyppi tehdään asiakkaan palautteen ja jatketun vaatimusanalyysin perusteella. Usein prototyyppimallin vaatimuksena on jonkinlainen alaan sopiva sovelluskehitin. Muuten yhteen iteraatioon kuluu liikaa aikaa. Sovelluskehitin saatetaan toteuttaa projektin yhteydessä. Sivu - 25 - Mitä tehdä prototyypille? Edellisen kierroksen prototyyppi voidaan joko hylätä, jolloin tarkoituksena on ollut tarkentaa prototyypin avulla asiakkaan ohjelmistolle asettamia toiveita ja vaatimuksia tai kehittää seuraavan kierroksen prototyypiksi, jolloin prototyypin tarkoituksena on ollut esitellä asiakkaalle ydinohjelmisto tai jokin ydinohjelmistoon liitetty aputoiminto. Asiakkaalle voi olla vaikeaa ymmärtää, miksi täysin toimiva prototyyppi ei vielä kelpaa lopputuotteeksi tai jalostettavaksi. Prototyyppiä on nimensä mukaisesti esitoteutus. Se ei vielä täytä laadukkaalle ohjelmistolle asetettavia vaatimuksia. Sivu - 26-13
Prototyyppimallin työvaiheet Määrittely 1. Proto Yleiskuvaus Kehitystyö Väliproto Väliproto Validointi Valmis tuote Sivu - 27-2.3. Formaalit menetelmät Formaaleissa menetelmissä ohjelmisto kehitetään pitkälti samaan tapaan kuin vesiputousmallissa. Menetelmien ero on siinä, että formaaleissa menetelmissä kehitetään jokin matemaattinen malli, jonka avulla määritelty ongelma muunnetaan ongelman ratkaisevaksi ohjelmaksi. Muunnoksia voi olla useita. Tällöin yksi malli tekee muunnoksen välimuotoon, seuraava muuntaa välimuotoa jne. Jos sopiva formalismi löydetään, menetelmä on ylivertainen kaikkiin muihin menetelmiin verrattuna. Sivu - 28-14
Formaalit menetelmät jatkuvat Mallien avulla ohjelma voidaan todistaa oikeaksi. Todistus tehdään osoittamalla taaksepäin ohjelmasta lähtien, että kukin saavutetun tason tulos vastaa yksikäsitteisesti lähtötason syötettä. Valitettavasti sopivia malleja on vähän ja niiden käyttö on rajoittunut pienille hyvin määritellyille ongelma-alueille. Uuden mallin kehitystyö on kallista eikä usein onnistu. Harvalla ohjelmistotekniikan ammattilaisella on riittävästi valmiutta kehitystyöhön. Mallia on vaikeaa selittää asiakkaalle. Sivu - 29-2.4. Iteratiiviset mallit Ideaalimaailmassa ohjelmistolle asetettavat vaatimukset ovat selkeät eivätkä muutu projektin aikana. Todellisuudessa tämä ei toteudu koskaan. Kaikissa todellisissa prosesseissa on iteratiivisuutta. Työvaiheissa joudutaan palaamaan edellisiin vaiheisiin sitä mukaa kun järjestelmälle asetettavat vaatimukset muuttuvat. Onneksi kaikkiin listattuihin malleihin voidaan lisätä iteratiivisia piirteitä. Sivu - 30-15
Lisäävä malli Lisäävässä mallissa (Incremental development) ohjelmisto jaetaan erillisiin osiin, jotka toteutetaan sykleissä. Jokainen sykli voidaan toteuttaa esimerkiksi vesiputousmallin mukaan. Vaatimusanalyysissa keskitytään vain kyseisen syklin vaatimiin vaatimuksiin. Ensimmäisellä syklillä rakennetaan ohjelmiston ydin, johon seuraavien syklien tulokset voidaan liittää. Jokaisella syklillä voi olla oma prosessimalli tarpeen mukaan. Sivu - 31 - Lisäävän mallin luonteesta Lisäävä malli pyrkii hyödyntämään sekä vesiputousmallin että prototyyppimallin parhaat puolet. Tuote voidaan määritellä sellaiseksi, että ydinohjelmistossa ovat tärkeimmät vaatimukset, kun taas myöhemmissä sykleissä vaatimusten prioriteetti pienenee. Jokaisen syklin kohdalla syklissä toteutettavat vaatimukset kiinnitetään samaan tapaan kuin vesiputousmallissa. Toteuttamattomien syklien vaatimukset voivat muuttua. Sivu - 32-16
Extreme programming Extreme programming (XP) kehitettiin 1990-luvun loppupuolella. Malli on erittäin kevyt lisäävä prosessimalli. XP perustuu ajatukseen, että ohjelma on mahdollista kehittää hyvin pienillä lisäyksillä. Ydinohjelman toteutuksen jälkeen jokaisella syklillä lisätään mahdollisimman pieni järkevä kokonaisuus ominaisuuksia. Vastaavasti projektia suunnitellaan vain mahdollisimman lyhyt aika eteenpäin. Projektin dokumentaatio on pääosin pelkkää koodia. Sivu - 33 - Extreme programming piirteitä XP perustuu seuraaviin asioihin: Lyhyt sykli. Jokaisen uuden version pitää olla mahdollisimman pieni. Versioon toteutetaan loogisesti yhtenäiset ominaisuudet, mutta ei mitään muuta. Kuvaus. Tämä vastaa XP:ssa arkkitehtuurikuvausta. Se kertoo, miten järjestelmän tulisi toimia. Yksinkertainen suunnittelu. Toteutus on aina kevyin mahdollinen. Testaus. Toteutuksessa XP:ssa rakennetaan ensin testitapaukset, jotka toteutettavan koodin tulee läpäistä. Testaus automatisoidaan: kirjoitetut testit voidaan suorittaa automaattisesti uudelleen. Refaktorointi. XP:ssa jo tehtyä koodia pyritään korjaamaan jatkuvasti uusien vaatimusten mukaiseksi tai paremmin ylläpidettäväksi. Sivu - 34-17
XP:n piirteet jatkuvat Lisää piirteitä: Pariohjelmointi. XP:ssa koodi kirjoitetaan aina pareittain. Toinen kirjoittaa koodia ja toinen miettii parasta tapaa toteuttaa ratkaistava ongelma. Yhteinen koodi. XP:ssa koodilla ei ole omistajaa. Jokaisella on oikeus ja velvollisuus korjata toisten ratkaisuja. Jatkuva integrointi. Kirjoitettu uusi koodi liitetään kehitysversioon saman tien. 40-tuntinen työviikko. Tämä on tosiaan XP:n vaatimuksissa. Läsnäoleva asiakas. XP:ssa asiakas on jatkuvasti mukana projektiryhmässä. Koodausstandardit. Tavoitteena on, että kirjoitettu koodi näyttää yhtenäiseltä (eli tyylierot eivät tule näkyville). Sivu - 35 - Spiraalimalli Spriaalimallissa prosessi esitetään spiraalina. Jokainen spiraalin silmukka esittää yhtä prosessin työvaihetta. Spiraalimallin silmukka jakautuu neljään sektoriin: Tehtäväasetus. Silmukan tavoite ja aikataulu asetetaan. Riskianalyysi. Silmukkaan liittyvät riskit tunnistetaan, analysoidaan ja priorisoidaan. Tärkeiksi luokitelluille riskeille mietitään vastatoimia. Kehitystyö ja validointi. Työvaihe toteutetaan ja validoidaan sopivilla menetelmillä ja prosessimalleilla. Syklin suunnittelu. Lopputulos arvioidaan ja pätetään jatkosta (eli seuraavasta syklistä). Sivu - 36-18
Spiraalimalli Spiraalimalli ei määrittele kiinteitä tehtäviä, vaan käyttää syklien sektoreissa muita prosessimalleja tai niiden osia. Yksi sykli voi esimerkiksi käsitellä yksinomaan vaatimusanalyysia, jolloin käytettävä prosessi on vaatimusanalyysin prosessi. Toisaalta sykli voi olla yhden prototyypin teko, jolloin käytettävä prosessi voi vaikkapa perustua vesiputousmalliin. Spiraalimallia voidaan käyttää myös ohjelmiston ylläpitoon. Tällöin yksi sykli tarkoittaa uuden ohjelmiston version tuottamista. Sivu - 37 - Spiraalimalliesimerkki Determine objectives alternatives and constraints Plan next phase Kuvalla (C) I. Sommerville 2000 REVIEW Requirements plan Life-cycle plan Development plan Integration and test plan Risk analysis Risk analysis Risk analysis Prototype 2 Risk analysis Prototype 1 Concept of Operation S/W requirements Requirement validation Design V&V Service Acceptance test Evaluate alternatives identify, resolve risks Prototype 3 Operational protoype Simulations, models, benchmarks Product design Integration test Code Unit test Detailed design Develop, verify next-level product Sivu - 38-19
3. Ohjelmistotuotantoprojektin ohjaus Ohjelmistotuotannon alkuaikoina 1960- ja 1970- luvuilla törmättiin ohjelmistokriisiin. Ohjelmistojen koko kasvoi. Ohjelmistot toimitettiin myöhässä. Ohjelmistot olivat heikkolaatuisia. Ohjelmistotuotantoprojektien budjetit ylitettiin roimasti. Tuotettujen ohjelmistojen tehokkuudessa oli toivomisen varaa jne. Projektit pettivät, koska niiden hallintaan käytettiin muista insinööritieteistä lainattuja menetelmiä. Ohjelmistotuotanto eroaa kuitenkin selvästi muista insinööritieteistä. Ohjelmistolla ei ole fyysistä olemusta, jokaiselle tuotteelle on omat prosessiin vaikuttavat vaatimukset, tuotteiden vertailukohtia ei välttämättä löydy jne. Sivu - 39-3.1. Projektipäällikkö Kuten muissakin insinööritieteissä, myös ohjelmistotuotannossa projektia johtaa projektipäällikkö (software manager). Projektipäällikkö vastaa projektista ja sen valmistumisesta ajallaan budjetin mukaan. Projektipäällikön tehtävät vaihtelevat yrityksittäin ja projekteittain. Pääasiassa vastuun lisäksi projektipäällikkö toimii projektin teknisenä asiantuntijana sekä kanavana projektin johtoryhmän ja projektiin osallistujien välillä. Johtoryhmä seuraa projektin etenemistä. Sivu - 40-20
Projektipäällikön vastuualueet Yleensä projektipäällikön vastuulla on seuraavaa: Tehtäväkuvauksen laadinta: kuvaus selvittää projektin tavoitteet ja yleissuunnitelman tavoitteiden saavuttamiseksi. projektisuunnitelman ylläpito: projektisuunnitelma kertoo projektin työvaiheet, tarkistuspisteet ja toimitettavat tuotokset. ja niille lasketut ajat. Aikataulun ylläpito: aikataulu on osa projektisuunnitelmaa. Se kertoo työvaiheiden suunnitellut toteutusajat ja työvaiheisiin osallistuvat henkilöt. Projektin kustannusarvio: kustannusarvion teon apuna voidaan käyttää jo päättyneitä vastaavia projekteja. Sivu - 41 - Vastuualueet jatkuvat Projektin seuranta ja tarkastukset: projektia seurataan säännöllisesti sekä aikataulun että tuotteen laadun mukaan. Tarkastuksissa katsastetaan projektin eteneminen tai jokin projektin tuotoksista. Työntekijöiden valinta ja arviointi: tavoitteena on jokainen työntekijä omia erikoistaitojaan vastaaviin tehtäviin. Raportointi: projektipäällikkö raportoi säännöllisin väliajoin projektin edistymisestä johtoryhmälle. Kaikissa yrityksissä ja projekteissa ei ole johtoryhmää. Tällöin raportointi tehdään yleensä projektin johtajalle, joka on vastuussa useasta samaan aikaan käynnissä olevasta projektista. Luonnollisesti projektipäällikön vastuualueet saattavat jakaantua usean projektin jäsenen kesken. Sivu - 42-21
3.2. Projektin suunnittelu Jotta projektia voidaan ohjata, tarvitaan kehys, jonka mukaan projekti etenee. Kehys, eli projektisuunnitelma on projektin tärkein dokumentti. Se tehdään ennen varsinaisia projektin työvaiheita. Projektin etenemistä seurataan projektisuunnitelman avulla. Tarvittaessa projektisuunnitelmaa päivitetään ja täydennetään, kun projekti etenee. Projektisuunnitelma antaa mahdollisuudet saada projekti valmiiksi ajoissa ja keinot huomata aikataulusta lipsumiset mahdollisimman pian. Sivu - 43 - Projektin seuranta Projektia seurataan Sommervillen mukaan seuraavan pseudokoodin tapaan: 1. Selvitetään projektin rajat (aikarajat, henkilöt, budjetti jne.) 2. Selvitetään projektin yleiset parametrit (rakenne, koko, ym.) 3. Määritellään projektin tarkistuspisteet ja tuotokset 4. Toistetaan vaiheita 5-12 kunnes projekti on päättynyt tai keskeytetty: 5. Tehdään aikataulu 6. Sijoitetaan tehtävät ja henkilöt aikatauluun 7. Annetaan projektiryhmän toimia aikataulun ja tehtäväjaon mukaan 8. Tarkistetaan projektin eteneminen 9. Muutetaan tarvittaessa projektin parametreja 10. Päivitetään tarvittaessa aikataulua 11. Neuvotellaan tarvittaessa päivityksistä projektin rajoihin ja tuotoksiin 12. Jos onglemia ilmenee, pidetään tekninen tarkastus prosessista ja mahdollisesti kirjoitetaan uusi versio projektisuunnitelmasta Sivu - 44-22
3.3. Projektisuunnitelma Projektisuunnitelma sisältää vähintään välttämättömät tiedot projektin etenemiseksi ja seuraamiseksi. Lisäksi se saattaa sisältää laaduntarkkailusuunnitelman: miten projektissa varmistetaan, että valmistettava tuote on riittävän laadukas, validointisuunnitelman: miten tehdyn järjestelmän ja vaatimusten yhtenäisyys varmistetaan, versionhallintasuunnitelman: miten tehtävän ohjelmiston eri versiota hallitaan, ylläpitosuunnitelman: mitä ylläpitoa ohjelmisto tarvitsee valmistumisensa jälkeen ja miten ylläpitopalvelut hoidetaan, ja koulutussuunnitelman: miten projektiin osallistuvien koulutus hoidetaan. Sivu - 45 - Projektisuunnitelma (jatkuu) Yleensä edellisellä kalvolla listatut suunnitelmat ovat erillisiä dokumentteja. Tällöin projektisuunnitelmaan jäävät pelkästään projektin työvaiheisiin, tehtäviin ja aikatauluun vaikuttavat kohdat. Projektisuunnitelmaa päivitetään koko projektin kestoajan. Jotkut osat projektisuunnitelmasta, kuten aikataulun yksityiskohdat, saattavat muuttua tiheään. Niinpä dokumentti kannattaa laatia sellaiseksi, että muuttuvien osien päivitys on suoraviivaista eikä vaadi pysyvämpien osien päivittämistä. Sivu - 46-23
Projektisuunnitelman rakenne Projektisuunnitelma sisältää yleensä ainakin seuraavat osat: 1. Johdanto Selvittää lyhyesti projektin tavoitteet ja listaa budjetin, ajoituksen, henkilöresurssien ym. ylärajat. Johdanto antaa projektille rakenteen ja rajoitukset, joihin projektisuunnitelma perustuu. 2. Projektiorganisaatio Selvittää projektiin osallistuvat henkilöt, heidän roolinsa ja mahdollisesti heidän erityisosaamisensa. 3. Riskianalyysi Selvittää mahdolliset projektin riskit, arvioi riskien todennäköisyyden, määrittelee riskin vakavuuden ja selvittää strategian, jonka avulla riskin toteutuessa siitä selvitään. Sivu - 47 - Projektisuunnitelma jatkuu 1. Laitteisto- ja ohjelmistovaatimukset Selvittää kehitystyössä tarvittavat laitteisto- ja ohjelmistokomponentit. Jos projektia varten tarvitaan uusia komponentteja, annetaan komponenttien kustannusarvio. 2. Työn ositus Selvitetään projektin toiminnot, tarkistuspisteet ja kunkin toiminnon tuloksena saatavat tuotokset. 3. Projektin aikataulu Selvitetään osituksen toimintojen väliset riippuvuudet, aika kunkin tarkistuspisteen vaatimasta ajasta ja henkilöiden tehtävät kussakin toiminnossa. 4. Seuranta- ja raportointitavat Selvitetään, miten projektia seurataan ja miten hoidetaan sekä projektin sisäinen että projektista ulos lähtevä raportointi. Sivu - 48-24
3.4. Tarkistuspisteet ja tuotokset Projektia suunniteltaessa projektille määritetään joukko tarkistuspisteitä (milestones). Jokainen tarkistuspiste on jonkin työvaiheen lopussa. Tarkistuspisteiden avulla tarkastetaan, että projekti pysyy aikataulussa. Aikataulu tehdään työvaihden ja tarkistuspisteiden mukaan. Projektin tuotos (deliverable) on jokin projektista saatava asiakkaalle merkittävä tulos. Esimerkiksi vaatimusdokumentti on yleensä tuotos, mutta suunnitteludokumentti ei välttämättä ole. Sivu - 49 - Tarkistuspisteet ja tuotokset (jatkuu) Tuotokset ovat käytännössä aina tarkistuspisteitä, mutta tarkistuspisteiden ei tarvitse olla tuotoksia. Tarkistuspisteiden määrittämiseksi projekti on ensin jaettava yhtenäisiin perustoimintoihin. Perustoiminto: jokin kokonaisuus, jolla on selkeä alku ja selkeä lopputuotos. Esimerkiksi vaatimusanalyysissä yksi perustoiminto voisi olla vaatimusten kartoitus, minkä lopputuloksena saadaan vaatimuslista. Jokainen tarkistuspiste päättää perustoiminnon, mutta perustoiminto ei välttämättä pääty tarkistuspisteeseen. Sivu - 50-25
3.5. Projektin aikataulu Kun projekti on saatu jaettua perustoimintoihin, jokaiselle perustoiminnolle annetaan kestoarvio ja selvitetään riippuvuudet muihin perustoimintoin. Kullekin tuotokselle ja tarkistuspisteelle päätetään perustoiminto, mikä tuottaa tuotoksen tai minkä päättyminen merkitsee tarkistuspisteen saavuttamista. Tämän jälkeen perustoiminnot yhdistetään toimintoverkoksi, mistä selviävät perustoimintojen järjestys ja kesto. Toimintoverkko käytännössä kertoo perustoimintojen järjestyksen ja aikataulun. Sivu - 51 - Toimintoverkko Yleensä Toimintoverkolla kuvataan yksi laajempi työvaihe, esimerkiksi vaatimusanalyysi. Projektissa on kuitenkin useita tarkistuspisteitä, missä kaikki käynnissä olevat perustehtävät yhtyvät. Näitä on hyvä käyttää hyväksi aikataulun laadinnassa. Toimintoverkon teko kuuluu yleensä projektipäällikön tehtäviin. Jos samasta projektista annetaan kahdelle eri projektipäällikölle tehtäväksi tehdä toimintoverkko, tuloksena saadaan melko varmasti kaksi eri verkkoa. Sivu - 52-26
Kriittinen polku Määritetyillä perustehtävillä on keskinäisiä riippuvuuksia, jotka on otettava huomioon toimintoverkossa. Joitain tehtäviä ei voida aloittaa ennen kuin jotkin muut tehtävät on saatu päätökseen. Vastaavasti toimintoverkossa voi olla rinnakkaisia tehtäviä: useita toisistaan riipumattomia tehtäviä voidaan hoitaa samanaikaisesti, kunhan jokaiselle tehtävälle on riittävästi henkilöresursseja. Rinnakkaisuus nopeuttaa projektia, mutta aiheuttaa työtä aikataulun laadinnalle. Laadinnassa on otettava huomioon kriittinen polku. Sivu - 53 - Ajoituskaavio Kriittinen polku määrittelee tehtävät, jotka on saatava valmiiksi aikataulussa, jotta projektin aikataulu pitää. Kaikille perustehtäville tehdään seuraava jaottelu: 1. Aikaisin hetki, jolloin tehtävä voi alkaa. 2. Viimeisin hetki, jolloin tehtävän pitää alkaa. 3. Aikaisin mahdollinen lopetusaika. 4. Viimeisin mahdollinen lopetusaika. 5. Ylijäämäaika, joka riippuu tehtävästä ja kriittisestä polusta. Työvaiheen lopputuloksena saadaan ajoituskaavio. Siitä näkyvät kaikki perustehtävät kestoaikoineen ja tarkistuspisteet. Sivu - 54-27
Muuta aikataulusta Kaikkien isompien työvaiheiden ajoituskaaviot yhdessä antavat projektin aikataulun. Tietenkin projekti voi myös tyytyä yhteen isoon ajoituskaavioon, joka silloin sisältää kaikki projektin työvaiheet. Ratkaisu riippuu projektin luonteesta. Tehtäväjaon ei pitäisi olla liian hienojakoinen, sillä se vaikeuttaa sekä projektin toteutusta että sen seuraamista. Pienimmät perustehtävät voivat olla suurusluokkaa 1-2 viikkoa. Seuraavilla kalvoilla on Sommervillen esimerkki tehtäväjaosta, kriittisestä polusta ja ajoituskaaviosta Sivu - 55 - Task durations and dependencies Task Duration (days) Dependencies T1 8 T2 15 T3 15 T1 (M1) T4 10 T5 10 T2, T4 (M2) T6 5 T1, T2 (M3) T7 20 T1 (M1) T8 25 T4 (M5) T9 15 T3, T6 (M4) T10 15 T5, T7 (M7) T11 7 T9 (M6) T12 10 T11 (M8) Kuvalla (C) I. Sommerville 2000 Sivu - 56-28
Activity network 4/7/99 start 8 days T1 15 days T2 14/7/99 15 days M1 T3 5 days 25/7/99 T6 M3 20 days T7 4/8/99 M4 15 days T9 25/8/99 M6 7 days T11 10 days T4 Kuvalla (C) I. Sommerville 2000 18/7/99 M5 25/7/99 M2 10 days T5 25 days T8 11/8/99 M7 5/9/99 M8 15 days T10 10 days T12 Finish 19/9/99 Sivu - 57 - Activity timeline 4/7 11/7 18/7 25/7 1/8 8/8 15/8 22/8 29/8 5/9 12/9 19/9 T4 T1 T2 Start M1 T7 T3 M5 T8 Kuvalla (C) I. Sommerville 2000 M3 M2 T6 T5 T9 M4 M7 T10 T11 T12 M6 M8 Finish Sivu - 58-29
3.6. Riskienhallinta Riskienhallinta on projektin hallintaa, missä projektin valmistuminen pyritään takaamaan myös tilanteissa, milloin jotain ei-toivottua tapahtuu. Riskienhallinnassa pyritään tunnistamaan projektin onnistumista vaikeuttavat riskit, analysoidaan tunnistetut riskit: annetaan riskien toteutumiselle todennäköisyys ja selvitetään riskin toteutumisen vaikutukset, suunnitellaan vastatoimet: riskin toteutuminen pyritään estämään tai pyritään minimoimaan riskin haittavaikutukset ja seurataan riskejä: riskejä arvioidaan projektin kestoajan, ja projektisuunnitelman riskianalyysia päivitetään sitä mukaa, kun uutta tietoa projektin riskeistä tulee selville. Sivu - 59 - Riskit, siis mitä? Riski on tapahtuma, jonka todennäköisyys on alle yksi ja joka toteutuessaan vahingoittaa projektia. Jos riskin todennäköisyys on yksi, eli se totetutuu aina, se ei ole riski vaan rajoitus. Riskit voivat olla projektikohtaisia: nämä vaikuttavat projektin aikatauluun tai käytössä oleviin resursseihin, tuotekohtaisia: nämä vaikuttavat kehitettävän tuotteen laatuun tai yrityskohtaisia: nämä vaikuttavat organisaatioon tai tuotteen menestykseen. Vaikka riskit ovat projektikohtaisia, samankaltaiset riskit esiintyvät useimmissa projekteissa. Sivu - 60-30
Riskien tunnistus Riskien tunnistuksessa pyritään löytämään kaikkia mahdollisia riskejä, mitkä voivat vaikuttaa projektin onnistumiseen. Käytännössä kaikkein epätodennäköisimmät ja vaikutuksiltaan merkityksettömimmät riskit unohdetaan suosiolla. Tunnistusta auttaa riskityypittely: Teknologiariskit. Henkilökuntariskit. Organisaatioriskit. Työkaluriskit. Vaatimusten kartoituksen riskit. Kustannus- ja aikatauluarvioinnin riskit. Sivu - 61 - Riskien analysointi Tunnistetuille riskeille mietitään riskin todennäköisyys ja vakavuus. Todennäköisyys: miten varmasti riski toteutuu. Luokitteluna käy epätodennäköinen (< 10%), mahdollinen (10%- 25%), keskimääräinen (25-50%), todennäköinen (50-75%) ja erittäin todennäköinen (>75%). Vakavuus: miten merkittävä riski on projektille. Luokitteluna käy tuhoisa, vakava, siedettävä ja vähäpätöinen. Lopulta päätetään, mihin riskeihin varaudutaan erityisen hyvin, mihin normaalisti ja mitkä jätetään huomioimatta. Sivu - 62-31
Riskien vastatoimet Riskien analysoinnin jälkeen jokaiselle valitulle riskille mietitään vastatoimet. Vastatoimet otetaan käyttöön, jos riski toteutuu. Vastatoimet riippuvat riskin luonteesta ja vakavuudesta. Toimet voivat olla riskien välttämistä: pyritään pienentämään todennäköisyyttä, että jokin riski tapahtuu, vaikutusten minimointia: riskiä ei pystytä välttämään, mutta pyritään vähentämään riskin toteutumisesta syntyviä haittavaikutuksia, jatkosuunnitelmia: mietitään toimintatapoja, joita voidaan seurata riskin toteutuessa (esim. yrityiskohtaiset riskit). Sivu - 63 - Riskien seuranta Riskianalyysin jälkeen meillä on listattuna projektisuunnitelmassa joukko riskejä ja niiden vastatoimia. Riskien toteutumista seurataan koko projektin elinkaaren ajan. Projektin kestäessä saattaa ilmaantua uusia riskejä. Nämä otetaan huomioon riskianalyysissa, mikä saattaa pakottaa projektisuunnitelman päivitykseen. Myös jo tunnistettujen riskien todennäköisyydet ja vakavuudet voivat muuttua. Sivu - 64-32