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 ohjelmisto- 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
4. Vaatimusanalyysi Laadukkaiden ohjelmistojen tuottaminen ei ole helppo tehtävä. Sen lisäksi, että ohjelman täytyy toimia virheettömästi, sen täytyy täyttää sille asetetut implisiittiset ja eksplisiittiset vaatimukset. Implisiittiset vaatimukset: ominaisuudet, jotka oletetaan olevan kaikilla kehitettävän tyyppisillä laadukkailla ohjelmistoilla. Tällaisia ovat esimerkiksi hyvä ylläpidettävyys, selkeä ja yhdenmukainen käyttöliittymä ja virheettömyys. Näitä ei välttämättä listata erikseen, mutta siitä huolimatta tuotettavan ohjelman täytyy toteuttaa ne. Eksplisiittiset vaatimukset: vaatimukset, jotka on lueteltu erikseen ja jotka tuotettavan ohjelman täytyy toteuttaa. Nämä selvitetään vaatimusanalyysissa. Sivu - 65 - Vaatimusanalyysin tavoitteet Vaatimusanalyysin tavoitteena on selvittää ohjelmistolle asetettavat vaatimukset sellaisella tarkkuudella, että niiden perusteella voidaan tuottaa haluttu ohjelmisto. Lineaarisissa malleissa työvaiheen lopputuloksena saadaan täydellinen lista vaatimuksista ja analyysi niiden vaikutuksista. Iteratiivisissa malleissa saadaan lista tällä iteraatiokierroksella vaikuttavista vaatimuksista. Vaatimukset ovat eritasoisia. Osa on hyvin korkealla tasolla, osa menee syvälle yksityiskohtiin. Sivu - 66-33
Vaatimusten luonteesta Dokumentoitavien vaatimusten on oltava virheettömiä. Vaatimusanalyysissä tehty virhe vaikuttaa koko projektin elinkaaren ajan ja tulee kalliiksi. ristiriidattomia. Ristiriitaisuus syntyy puhutun ja kirjoitetun kielen moniselitteisyydestä. täydellisiä. Vaatimukset muuttuvat lähes poikkeuksetta projektin elinkaaren aikana, joten täydellisyyteen (ja virheettömyyteen) ei päästä. realistisia. Vaatimusanalyysissa selvitetään myös järjestelmäsuunnittelun ja toteutusympäristön asettamat rajoitukset. tarpeellisia. Tarpeellisten vaatimusten selvittäminen on yllttävän vaikea tehtävä. Vaatimukset kannattaa priorisoida. todennettavissa. Jokainen vaatimus on löydettävä tuotteesta, ja tuotteen jokainen ei-triviaali ominaisuus on oltava tunnistettu vaatimus. jäljitettävissä. Jokaisella vaatimuksella on esittäjä, joka on voitava selvittää tarpeen vaatiessa. Sivu - 67-4.1. Vaatimustyypit Vaatimusanalyysia vaikeuttaa, että vaatimukset on tarkoitettu eri tarkoituksiin: Vaatimuksia käytetään kuvaamaan tehtävää ohjelmistoa Vaatimukset toimivat sopimuksena asiakkaan ja ohjelmistoyrityksen välillä. Vaatimukset kuvaavat ohjelmiston toiminnan yksityiskohtia Vaatimukset toimivat suunnittelun perustana. Vaatimusten monimerkityksisyyden johdosta Sommerville jakaa vaatimukset kolmeen tyyppiin: käyttäjän vaatimukset (user requirements), järjestelmävaatimukset (system requirements) ja ohjelmiston määrittelykuvaukset (software design specification). Sivu - 68-34
Vaatimustyypit jatkuvat Käyttäjän vaatimukset Vaatimukset listaavat ohjelmiston tarjoamat palvelut ja ohjelmistolle asetettavat rajoitukset. Vaatimukset kuvataan luonnollisella kielellä ja kaavioilla. Käyttäjän vaatimuksia käytetään analyysin pohjana ja yhteydenpidossa asiakkaan kanssa. Järjestelmävaatimukset Vaatimukset kuvaavat ohjelmiston palvelut ja rajoitukset yksityiskohtaisesti. Kaikki vaatimukset kuvataan samalla formaatilla. Järjestelmävaatimuksia käytetään sopimuksena asiakkaan ja ohjelmistoyrityksen välillä. Ohjelmiston määrittelykuvaukset Määrittelykuvaus on yksityiskohtainen ja kattava kuvaus ohjelmistosta. Kuvauksessa käytetään standardoituja menetelmiä, kaavioita ja strukturoitua kuvausta. Kuvaus toimii suunnittelun esiasteena. Sivu - 69-4.2. Vaatimusten luokittelu Äsken tyypiteltiin, nyt luokitellaan vaatimuksia. Käyttäjä- ja järjestelmävaatimukset voidaan luokitella toiminnallisiin (functional) vaatimuksiin ja eitoiminnallisiin (non-functional) vaatimuksiin. Toiminnalliset vaatimukset: Nämä määrittelevät, mitä palveluja ohjelmiston on tarjottava, miten ohjelmisto reagoi syötteisiin ja miten se käyttäytyy annetuissa tilanteissa. Joskus toiminnalliset vaatimukset myös määrittelevät, mitä ohjelmiston ei pidä tehdä. Ei-toiminnalliset vaatimukset: Nämä määrittelevät rajoitukset ja reunaehdot toiminnallisille vaatimuksille. Sivu - 70-35
Vaatimusten luokittelu (jatkuu) Esimerkiksi vaikka näin: Ohjemistoon pitää pystyä tekemään kyselyjä kulloinkin paikalla olevista käyttäjistä (toiminnallinen vaatimus). Ohjelmiston on selvittävä sadasta kyselystä sekunnissa (eitoiminnallinen vaatimus). Ohjelmiston on reagoitava hälytykseen hälytysmerkkiäänellä ja vilkkuvalla näytöllä (toiminnallinen vaatimus). Hälytykseen on reagoitava alle 0,1 sekunnin sisällä hälytyksen aiheuttaneen signaalin saapumisesta (ei-toiminnallinen vaatimus). Ohjelmistossa on oltava ylläpidolle tarjotut palvelut toiseen käyttöympäristöön siirtymiseksi (toiminnallinen vaatimus). Ohjelmiston on toimittava Windows- ja Linux-ympäristöissä (eitoiminnallinen vaaatimus). Sivu - 71 - Toiminnalliset vaatimukset Toiminnalliset vaatimukset ovat intuitiivisesti selkeitä. Tarkoitus on listata, mitä palveluja järjestelmä tarjoaa. Toiminnallisiin vaatimuksiin kuuluvat luonnollisesti ohjelmiston normaalit palvelut, mutta niihin kuuluvat myös virhetilanne- ja poikkeuskäsittelyn tarjoamat toiminnot ja toipumistavat. Toiminnalliset vaatimukset etsitään alkaen suurista kokonaisuuksista ja edeten kohti pienempiä osia. Vaatimukset pyritään kartoittamaan eri näkökulmista, jotta vaatimuksista saadaan mahdollisimman kattavat. Sivu - 72-36
Ei-toiminnalliset vaatimukset Koska ei-toiminnalliset vaatimukset eivät liity suoraan palveluihin, ne eivät ole yhtä intuitiivisia kuin toiminnalliset vaatimukset. Ei-toiminnalliset vaatimukset asettavat ohjelmistolle ja sen toteutukselle rajoituksia. Rajoitus: jokin sääntö, joka ohjelmiston on toteutettava. Esimerkiksi edellä esimerkissä oli aika- ja ylläpitorajoituksia. Koska ei-toiminnalliset vaatimukset eivät suoraan käsittele ohjelmiston tarjoamia palveluja, niiden löytäminen, luokittelu ja validointi on vaikeampaa kuin toiminnallisten vaatimusten. Sivu - 73 - Ei-toiminnallisia vaatimusluokkia Seuraava luokittelu voi auttaa löytämään eitoiminnallisia vaatimuksia: Nopeus: tapahtumia sekunnissa, vasteajat, päivitysajat ym. Koko: ohjelmiston koko, syöttö-/tulostiedoston koko ym. Helppokäyttöisyys: koulutusaika, opastusjärjestelmä ym. Luotettavuus: vikasietoisuusaste, saavutettavuusaika ym. Sitkeys (robustness): toipumisaika, kaatumistodennäköisyys, virhetilanteessa tietojen katoamistodennäköisyys ym. Siirrettävyys (portability): alustariippuvan koodin määrä, tuettavien järjestelmäalustojen määrä ym. Ei-funktionaaliset vaatimukset pyritään aina kuvaamaan tarkasti numeroarvoilla. Sivu - 74-37
Ympäristövaatimukset Ympäristövaatimukset (domain requirements) ovat vaatimuksia, joiden lähtökohtana on ohjelmistoa ympäröivä toimintaympäristö käyttäjien sijaan. Ympäristövaatimukset voivat olla joko toiminnallisia tai ei-toiminnallisia vaatimuksia. Ympäristövaatimukset ovat tärkeitä, sillä ne määrittelevät ehdot, jotka ohjelmiston tulee täyttää, jotta se voi toimia järjestelmässä. Ympäristövaatimuksia ovat esimerkiksi ohjelmistolle määriteltävät rajapinnat muihin ohjelmistokomponentteihin. Sivu - 75-4.3. Vaatimusdokumentti Vaatimusanalyysin lopputuloksena saadaan vaatimusdokumentti. Se kuvaa yksiselitteisesti kaikki ohjelmistolle asetetut vaatimukset ja kehitetyt mallit. Vaatimusdokumentin täytyy täyttää seuraavat vaatimukset: Se määrittelee vain ulkoisen toiminnan: mitä ohjelmisto tarjoaa. Se määrittelee toteutukselle asetettavat rajoitukset. Se on helposti muutettavissa. Se toimii lähdeteoksena ohjelmiston ylläpitäjille. Se sisältää arvion tuotteen elinkaaresta. Se käsittelee myös virhetilanteet. Sivu - 76-38
Vaatimusdokumentti (jatkuu) Jokaisella yrityksellä on vaatimusdokumentin pohja, joka helpottaa vaatimusdokumentin kirjoittamista. Kirjallisuudesta löytyy myös standardoituja pohjia, kuten IEEE:n standardi vaatimusdokumenteille (IEEE/ANSI 830-1993). Vaatimusdokumentti hyväksytään sekä asiakkaan että ohjelmistoyrityksen puolelta. Sen pitää olla rakenteeltaan sellainen, että kaikki sidosryhmät voivat käyttää sitä: asiakkaat, johtoryhmä, laadunvalvontaryhmä, halinto, projektipäällikkö, projektiryhmä ym. Sivu - 77 - Vaatimusdokumentin sisällysluettelo Seuraava lista perustuu Sommervillen esittämään vaatimusdokumentin rakenteeseen. 1. Esipuhe (preface) Selvittää kenelle dokumentti on tarkoitettu, dokumentin versiohistorian ja yhteenvedon edellisen version jälkeen tehdyistä muutoksista. 2. Johdanto Sisältää järjestelmän yleiskuvauksen, tärkeimmät tehtävät ja yhteistyön muiden järjestelmien kanssa. Johdanto voi sisältää myös lyhyen vanhan järjestelmän kuvauksen ja viitteet vanhan järjestelmän dokumentaatioon. 3. Sanasto Määrittelee dokumentissa käytetyt termit. Dokumentin tulee olla myös alan sanastoa tuntemattoman henkilön luettavissa. Sivu - 78-39
Sisällysluettelo (jatkuu) 4. Käyttäjän vaatimukset Määrittelee käyttäjän vaatimukset luonnollisella kielellä ja kaavioilla. Myös mahdolliset käyttäjän vaatimuksiin laskettavat ympäristövaatimukset luetellaan täällä. 5. Järjestelmäarkkitehtuuri Antaa yleiskuvan toteutettavan ohjelmiston rakenteesta. Luku sisältää myös tiedot jo valmiina olevista ohjelmistokomponenteista. Järjestelmäarkkitehtuurista tarvitaan sopivalla kuvaustekniikalla tehty kaaviokuva. 6. Järjestelmävaatimukset Märittelee yksityiskohtaiset toiminnalliset ja ei-toiminnalliset vaatimukset. Sivu - 79 - Sisällysluettelo (jatkuu II) 7. Järjestelmämallit Sisältää yksityiskohtaisemmat mallit järjestelmän osajärjestelmistä, komponenteista ja niiden välisistä suhteista. Järjestelmämallit ovat suunnittelun perustana. Ne kuvataan yhdellä tai useammalla kuvaustekniikalla. 8. Järjestelmän kehitys Selittää odotetut laitteiston, käytön ja ohjelmiston vaatimusten muutokset. 9. Liitteet Sisältää sellaiset olemassaolevat dokumentit tai viitteet, jotka vaikuttavat tuotteeseen, mutta joita ei ole määritelty vaatimusanalyysissa. Esimerkiksi käytettävän tietokannan hallintajärjestelmän kuvaus voi olla tällainen liitedokumentti. 10. Hakemisto Sivu - 80-40
4.4. Vaatimusanalyysin vaiheet Vaatimusanalyysissa on seuraavat työvaiheet: Kelpoisuusselvitys (feasibility study). Katsotaan, kannattaako ohjelmistoa ylipäänsä toteuttaa. Vaatimusten kartoitus ja analyysi (requirements elicatation and analysis). Kerätään vaatimuksia yhteistyössä asiakkaan kanssa ja mallinnetaan löydettyjen vaatimusten perusteella kehitettävää järjestelmää. Vaatimusten määrittely (requirements specification). Jaetaan kartoitetut vaatimukset käyttäjävaatimuksiin ja järjestelmävaatimuksiin. Kehitetään ohjelmiston määrittelykuvaukset. Vaatimusten validointi (requirements validation). Varmennetaan, että löydetyt vaatimukset todella määrittelevät asiakkaan haluaman järjestelmän. Sivu - 81 - Kelpoisuusselvitys Kelpoisuusselvitys on lyhyt esivaihe vaatimusanalyysille. Siinä pyritään vastaamaan: 1. Tuoko kehitettävä järjestelmä lisäarvoa asiakkaalle? 2. Voidaanko järjestelmä toteuttaa nykyisellä teknologialla, projektille varatulla aikataululla ja budjetilla? 3. Voidaanko järjestelmä integroida jo olemassaoleviin järjestelmiin? Lisäksi, vaikka Sommerville ei sitä listaa: 4. Kannattaako järjestelmä toteuttaa, vai voidaanko vastaava järjestelmä ostaa valmiina. Onko ostettava järjestelmä sovitettavissa asiakkaan tarpeisiin? Tuloksena saadaan päätös siitä, kannattaako järjestelmän kehitystyötä jatkaa. Sivu - 82-41
Vaatimusten kartoitus ja analyysi Tavoitteena on löytää, luokitella ja mallintaa kaikki prosessin työvaiheeseen kuuluvat vaatimukset. Vesiputousmallissa tämä tarkoittaa kaikkia vaatimuksia. Prorotyyppimallissa tämä tarkoittaa seuraavalle prototyypille asetettavia vaatimuksia jne. Työvaiheeseen kuuluvat seuraavat osavaiheet: 1. Sovellusympäristön selvitys (domain understanding). 2. Vaatimusten keruu (requirements collection). 3. Vaatimusten luokittelu (classification). 4. Ristiriitaisuuksien selvitys (conflict resolution). 5. Vaatimusten priorisointi (priorisation). 6. Vaatimusten tarkastus (requirements checking). Sivu - 83 - Skenaariot Eräs tapa kartoittaa vaatimuksia on pyytää asiakkaalta skenaarioita (scenarios) nykyisestä ja tulevasta järjestelmän toiminnasta. Skenaariot ovat kuvauksia järjestelmän käytöstä eri näkökulmista. Skenaario sisältää yleensä järjestelmän tilan kuvauksen ennen toiminnan alkua, normaalin toiminnan kuvauksen, poikkeustilanteiden kuvauksen (voi olla oma skenaarionsa), tiedot mahdollisista muista samanaikaisista tapahtumista, jotka vaikuttavat tähän skenaarioon ja järjestelmän tilan kuvauksen toiminnan päättymisen jälkeen. Sivu - 84-42
Käyttötapaukset Käyttötapaus (use-case) sisältää yhden tai useamman skenaarion järjestelmästä. Samankaltaiset tai samoihin järjestelmän osiin vaikuttavat skenaariot kootaan saman käyttötapauksen alle. Jokainen käyttötapaus kertoo yhden tavan toimia kehitettävässä järjestelmässä, toiminnan tehtävät ja toimintaan osallistuvat sidosryhmät. Käyttötapaukset voivat olla selväkielistä tekstiä tai niihin voidaan käyttää sopivaa kuvaustekniikkaa. Käyttötapauksia voidaan tarkentaa käymällä asiakkaan luona katsomassa nykyistä toimintaa. Sivu - 85 - Vaatimusten tyypittely Kun vaatimukset on saatu kerättyä, luokiteltua ja mallinnettua, ne tyypitellään käyttäjän vaatimuksiin ja järjestelmävaatimuksiin. Samalla tarkistetaan, että vaatimukset vastaavat kehitettyjä malleja ja että mallit ovat täydelliset ja riittävät. Tarvittaessa palataan takaisin keräämään ja analysoimaan lisää vaatimuksia. Tämän työvaiheen tuloksena saadaan yksityiskohtaiset vaatimuslistat ja korkean tason ohjelmistosuunnitelmat kehitettävästä ohjelmistosta. Sivu - 86-43
Vaatimusten validointi Viimeisenä vaiheena kerätyt, analysoidut, tarkennetut ja tyypitellyt vaatimukset validoidaan. Tarkoituksena on selvittää, että saatu vaatimuslista ja vaatimusten perusteella kehitetyt mallit ovat yhtenäiset ja toteuttavat vaatimuksille asetetut ominaisuudet: Vaatimusten on oltava virheettömiä, ristiriidattomia, täydellisiä, realistisia, tarpeellisia, todennettavissa ja jäljitettävissä. Vaatimusten validointia varten saatetaan rakentaa järjestelmästä prototyyppi tai kirjoittaa alustava käyttöohje. Sivu - 87-4.5 Vaatimusanalyysin hallinta Vaatimusanalyysi on prosessi, joten se tarvitsee hallintaa. Hallinnan tehtävä on organisoida työvaiheet ja varustautua siihen, että vaatimukset muuttuvat projektin edetessä. Myös vaatimusanalyysiin kuuluu riskienhallintaa. Riskit tunnistetaan ja niihin varaudutaan. Esimerkiksi jos on todennäköistä, että vaatimukset elävät voimakkaasti projektin aikana, kehitetään mieluummin lisäävällä mallilla tai prototyyppimallilla ohjelmistoa vähän kerrassaan toivottuun suuntaan. Sivu - 88-44
3a. Projektin hallinta (lisäys lukuun 3) Tehokas projektin hallinta keskittyy kolmeen osaalueeseen: henkilökuntaan, tehtävään ja prosessiin. Henkilökunta: on yrityksen tärkein voimavara, oikea henkilö oikeassa tehtävässä = menestys, väärä henkilö väärässä tehtävässä = kaaos. Henkilöhallinnan alueita: palkkaus, valinta tehtäviin, souritusten seuranta, koulutus, hyvitysperiaatteet, urakehitys, työnkuva ja ryhmätyön kehittäminen. Tehtävä: Onnistunut projekti vaatii tarkan rajauksen ja yksityiskohtaisen tehtäväkuvauksen. Sivu - 89 - Projektin hallinta (jatkuu) Prosessi: Sopivaa prosessia käyttämällä saadaan kehys projektille. Yksityiskohtaiset tehtävät määritellään projektin alkuvaiheessa käytetyn prosessin mukaisesti. Sekä tuotteen että projektin laatua valvotaan koko projektin kestoajan. Tehtävästä ja prosessista on puhuttu aiemmin. Sen sijaan henkilöistä ei ole puhuttu juuri mitään. Projektin tärkeimmät osallistujat ovat projektipäällikkö ja projektin jäsenet. Muita osallistujia ovat mm. asiakkaan tekniset asiantuntijat, johtoryhmä ja markkinointiosastojen työntekijät. Sivu - 90-45
Projektipäällikkö Projektipäällikkö vastaa projektin lisäksi projektin jäsenistä. Projektipäälliköltä vaaditaan: ongelmanratkaisukykyä: Hän ymmärtää työalueen ja pystyy löytämään uusia ratkaisuja. Hän osaa motivoida muita. johtamistaitoa: Hän ottaa suurimman vastuun projektin onnistumisesta. Hän osaa tehdä päätöksiä ja ottaa vastuuta myös vaikeissa tilanteissa. kannustuskykyä: hän kannustaa ryhmää hallittuun riskinottoon ja uusien ideoiden tuottamiseen. pyskologista silmää: hän ymmärtää ryhmän jäsenten välisiä jännitteitä. Hän järjestää tehtävät sillä tavalla, että ryhmän jäsenet tuntevat työskentelevänsä miellyttävässä ympäristössä. Sivu - 91 - Projektiryhmä Projektiryhmän rakenne: Demokraattinen hajautettu (DD, democratic decentralized): Ryhmällä ei ole pysyvää johtajaa. Jokaisella tehtävällä on vastuuhenkilö, joka vaihtuu tehtävän vaihtuessa. Kommunikointi tapahtuu demokraattisesti ryhmän sisällä. Ohjattu hajautettu (CD, controlled decentralized): Koko projektilla on vastuussa oleva johtaja. Projektiryhmä on jaettu osaryhmiin, joista jokaisella on päällikkö. Ongelmanratkaisu tapahtuu yleensä ryhmässä, mutta toteutus tehdään osaryhmissä. Kommunikointi tapahtuu pääasiassa osaryhmien sisällä. Ohjattu keskitetty (CC, controlled centralized): Ryhmällä on projektipäällikkö, joka hoitaa keskitetysti koko projektin hallinnan. Projektin jäsenille annetaan selkeät tehtävät. Kommunikointi tapahtuu projektipäällikön kautta. Sivu - 92-46