Ohjelmistotuotanto

Wikipedia

Ohjelmistotuotanto tarkoittaa ohjelmistojen suunnittelua ja kehitystä järjestelmällisesti. Prosessiin kuuluu perinteisesti eri vaiheita, esim.:

vaatimusmäärittely
järjestelmäsuunnittelu
ohjelmistosuunnittelu
1. toiminnallinen määrittely
2. tekninen määrittely
toteutus
testaus
julkistus
ylläpito.

Yhdessä nämä vaiheet vaatimusanalyysista aina ylläpitoon ja lopulta sen lopettamiseen asti muodostavat ohjelmiston elinkaaren.

[muokkaa] Vesiputousmalli

Tässä perinteisessä prosessissa vaiheet soljuvat eteenpäin kuin vesiputous tasolta toiselle (vain yhteen suuntaan), ja siksi tätä prosessia kutsutaankin vesiputousmalliksi. Ajatuksena on, että kukin vaiheista tuottaa dokumentin tai joukon dokumentteja, jotka toimivat syötteenä seuraavalle vaiheelle. Esimerkiksi vaatimusanalyysi määrää ja asettaa minimivaatimukset ja rajat toiminnalliselle määrittelylle, jotta määrittelyn lopussa voidaan tarkastaa, vastaako määritelty ohjelmisto vaatimusanalyysin mukaista järjestelmää. Toisaalta taas toteutusvaiheessa (koodaus) teknisen määrittelyn pitäisi kattaa ne tarvittavat tiedot, joiden perusteella ohjelmisto voidaan kirjoittaa.

Vesiputousmallissa suurin vaikeus on suunnitella koko tuote kerralla toteutuskuntoon. Nykyisin tuotantoprosessi on usein iteratiivinen, eli suunnittelua ja toteutusta tehdään pienimmissä osissa ja prosessia toistetaan. Näin ohjelmisto kehittyy inkrementaalisesti eli koko ajan kasvaen kohti lopullista muotoaan.

Kun vesiputousmalliin yhdistetään joka vaihetta vastaava testaus (esim. vaatimusmäärittelystä hyväksymistestaus) aikajanalle syntyy nk. V-malli, jonka vasen sakara kuvastaa prosesin vaiheita ja oikea kunkin testausta. Prosessia, joka toistaa alemman tason suunnittelua ja toteutusta, kutsutaankin W-malliksi, jossa keskisakara kuvastaa iteraatiota.

Nopeasti muuttuvassa ympäristössä ennalta suunnittelun vaikeus on noussut suurimmaksi esteeksi perinteiselle vesiputousmallille. Iteratiivinen prosessi antaa mahdollisuuden muuttaa projektin kulkua ja suuntaa hallitusti kesken prosessin. Ohjelmisto ei useinkaan tule kerralla valmiiksi, ja monet ohjelmistotuotteet jatkavat kehitystään julkaisun jälkeenkin. Nopeiten kehittyvillä ohjelmistotuotannon aloilla ja etenkin pienemmissä ohjelmpistoprojekteissa on omaksuttu nk. ketteriä ohjelmistoprosesseja, jotka korostavat muutosten hallintaa ja nopeita iteraatiosyklejä.

Vesiputousmalli kuvastaa ohjelmistotuotantoa melko kehnosti ja sopii paremmin talonrakennusprojekteihin, mutta eri vaiheiden tavoitteet ja tehtävät ovat suurin piirtein samat, vaikka järjestys ja toteutustapa saattaa vaihdella suurestikin.

[muokkaa] Ohjelmiston elinkaaren vaiheet

[muokkaa] Vaatimusanalyysi

Tämän vaiheen tarkoituksena on selvittää ne ohjelmistotuotteelle asetetut tavoitteet, mitkä valmiin järjestelmän tulisi täyttää. Vaatimusanalyysin tarkoituksena ei ole ottaa millään tavoin kantaa siihen, miten nämä tavoitteet saavutetaan. Näin toimitaan siksi, että on edullisinta siirtää toteutusmenetelmiin liittyvät päätökset mahdollisimman myöhäiseen vaiheeseen. Tyypillisesti ohjelmiston tekninen toiminta muuttuu sen elinkaaren myötä monistakin syistä, ja muutosten tekeminen on sitä kalliimpaa taloudellisesti, mitä aikaisempaan vaiheeseen ne joudutaan kohdistamaan.

Toisinaan vaatimuksiin voi toki kuulua rajoituksia, jotka esim. sitovat toteutuksen tiettyyn ohjelmointikieleen asiakkaan erityistarpeiden tms. syistä.

Esimerkiksi ohjelmistotuotteelle asetettuja vaatimuksia voisivat olla seuraavat: ohjelmiston pitää kyetä numeeriseen sekä symboliseen laskentaan ja lukemaan käyttäjältä tarvittavat syötteet. Nyt huomattavaa on, että tässä vaatimuksessa ei ole kuvattu esim. sitä, millaisessa muodossa syöte tulee antaa, onko järjestelmä graafinen vai ei, pitääkö tiloja kyetä tallentamaan jne. Yksi suurimpia vaikeuksia vaatimusanalyysissä (kuin myös muissa vaiheissa) onkin huomata se, että onko saatujen tietojen määrä riittävä, jotta seuraavaan vaiheeseen voidaan edetä. Sen vuoksi kukin vaiheista yleensä hyväksytetäänkin loppuvaiheessa, yleensä vähintäänkin ensimmäiset vaiheet myös asiakkaan kesken.

Vaatimusanalyysi tulee tehdä tiiviissä yhteistyössä ohjelmiston asiakkaan kanssa. Analyysi ei juurikaan muutu, vaikka asiakas olisi kuvitteellinen (esim. siksi, että tuotteella ei ole etukäteen tiedossa asiakasta). Analyysissä on tärkeää osata sivuuttaa turhat toteutustekniset vaatimukset – esimerkiksi asiakas saattaa toivoa laitteeseen kymmentä eri painonappia, vaikka parempi olisi nappien toiminnallisuudet toteuttava valikko.

Vaatimusanalyysi tuottaa lopputuloksenaan dokumentin asiakasvaatimukset.

[muokkaa] Järjestelmäsuunnittelu

Järjestelmäsuunnittelussa (system design) tarkastellaan järjestelmien välistä työnjakoa ja integrointia sekä laitteiston ja ohjelmiston välistä työnjakoa. Järjestelmäsuunnittelussa voidaan päättää hajauttaa eri ohjelmistoja eri laitteille tai asentaa samaa ohjelmistoa usealle laitteelle.

Järjestelmäsuunnittelua voidaan tehdä esimerkiksi kahdella tasolla:

Järjestelmäkartan (system blueprint) tasolla pohditaan mitä laitteita ja ohjelmistoja tarvitaan ja kuinka ne liittyvät toisiinsa.
Yksittäisen laitteen tasolla päätetään mm. laitteistosta, käyttöjärjestelmästä ja ohjelmistoista, yhteyksistä ja tietoturvasta.

Järjestelmäsuunnittelu on tavallinen vaihe räätälöityjen ohjelmistojen tuotannossa. Valmisohjelmien tuotannossa sitä ei yleensä tarvita.

[muokkaa] Ohjelmistosuunnittelu

Ohjelmistosuunnittelu koostuu kahdesta vaiheesta. Näistä ensimmäinen on toiminnallinen määrittely. Siinä kuvataan kaikki järjestelmän toteuttamat toiminnot ja liitännät järjestelmän ulkopuolelle. Vaiheen tuotoksena syntyvä määrittelydokumentti kuvaa siis mitä kaikkea järjestelmällä voi tehdä sekä miten käyttäjä voi ne tehdä. Järjestelmä ei kuvaa sitä, miten toiminnot tulee toteuttaa. Näin määrittelydokumentti kuvaa esimerkiksi tekstinkäsittelyohjelman eri näytöt, valikot ja niissä olevat asetukset ja kaikki käyttöliittymäkontrollit. Mikäli järjestelmä tuottaa tulosteita, niin määrittelydokumentin tulisi sisältää sekä visuaaliset että riittävät tekstuaaliset kuvaukset kaikista järjestelmän eri näytöistä.

Ideaalinen määrittelydokumentti on niin kattava, että teknisessä suunnittelussa tai sitä seuraavissa vaiheissa ei ole enää missään vaiheessa epäselvää, että miten ohjelman tulee toimia kussakin tilanteessa, miten tulosteet ja syöte on muotoiltu jne. Vaikka tähän on käytännössä mahdotonta päästä, niin on kuitenkin havaittu, että siihen tulee pyrkiä.

Toisaalta on myös tutkittu, että hyvä määrittelydokumentti ei saa olla liian vuolassanainen. 500 A4-sivua pitkä kaiken kattava määrittelydokumentti ohjelmasta, joka piirtää ainoastaan 2D-kuvaajia polynomifunktioista näytölle, on todennäköisesti aivan liian pitkä. Kuitenkin 100-sivuinen määrittelydokumentti mistään kunnollisesta tekstinkäsittelyohjelmasta on varmasti aivan liian lyhyt.

Tyypillinen ohjelmistoalan ongelma on se, että määrittelydokumentteja ei jakseta kirjoittaa. Jonkinlainen vaatimusanalyysi (yleensä hyvin epämuodollinen) saatetaan tehdä, mutta sen jälkeen aletaankin heti koodata ohjelmaa. Ajatellaan, että määrittelydokumentin kirjoittamiseen menevä aika ei ole verrannollinen siitä saatavaan hyötyyn. Kuitenkin asia on juuri päinvastoin, koska asioita on paljon helpompi muuttaa luonnollisella kielellä kirjoitetusta dokumentista kuin ohjelmakoodista, ja suoraan koodia kirjoittavat huomaavat hyvin pian tekevänsä määrittelyä samaan aikaan kuin kirjoittavat ohjelmaa. Näin ohjelma muodostuu ad hoc -ratkaisujen varaan, ja isoista ohjelmista muodostuu rakenteellisesti hyvin vaikeaselkoisia ja sitä kautta erittäin virhealttiita rakennelmia.

Toiminnalliselle määrittelylle vastakohta on tekninen määrittely. Tekninen määrittely seuraa toiminnallisen määrittelyn jälkeen, ja siinä ei enää tehdä valintoja tai päätöksiä siitä, millaisia ominaisuuksia laitteessa on – sen tarkoituksena on kuvata ohjelmiston tai ohjelman tekninen arkkitehtuuri tarkasti, joskaan ei vielä ohjelmakoodina. Syötteenä sille toimii toiminnallinen määrittely, ja se kuvaa ne ohjelmistokomponentit, jotka toteuttavat määrittelyn vaatimat toiminnot.

Tekniseen määrittelyyn sisältyy esim. käytetty ohjelmointikieli/kielet, ohjelmistokomponentit kuten kirjastot, ohjelmistokomponenttien rakenne ja keskinäinen hierarkia, käytetyt tietorakenteet ja niiden väliset sovellusrajapinnat jne.

Huomattavaa on, että ohjelmiston koosta ja monimutkaisuudesta riippuen dokumentti koostuu usean eri kerroksen kuvauksista. Esimerkiksi kompleksissa ohjelmistossa ensimmäisellä tasolla voi näkyä eri moduulit, mistä järjestelmä koostuu: palvelinprosessi, asiakasohjelmaclient-prosessit, tietovarastot sekä niiden liitynnät ympäristöön. Toisella tasolla kukin näistä komponenteista on pilkottu pienempiin osiin kuten luokkiin, ja niistä näkyy tarkemmin, mitä ulkoiset liitännät ovat (käytetty protokolla jne). Kolmannella tasolla on kuvattu luokkien metodit ja luokkamuuttujat, käytettyjen tietorakenteiden tyypit (merkkijono, kokonaisluku, liukuluku...) jne.

[muokkaa] Toteutus

Määrittelydokumentin valmistuttua toteutus voi alkaa. Toteutus käsittää lähinnä varsinaisen koodaamisen valitulla ohjelmointikielellä sekä tarvittavien oheiskomponenttien tuottamisen (käytetyt kuvat, äänet jne). Mikäli edelliset vaiheet on toteutettu kunnolla, niin toteutukseen menevä aika on noin 10–20 % koko ohjelmistoprojektiin käytetystä ajasta. Tämän vaiheen tuotoksena on siis ajettava ohjelmisto, mutta siinä on kuitenkin yleensä suhteellisen paljon toiminnallisia virheitä.

[muokkaa] Testaus

Testauksen tarkoituksena on löytää ohjelmistossa olevat virheet. Virheitä löytyy toteutuksen huolellisuudesta riippumatta käytännössä kaikista ohjelmistoista. Esimerkiksi yritykselle on erittäin tärkeää löytää virheet (ja korjata ne) itse sen sijaan, että asiakas löytää ne ja kertoo sitten huonoista kokemuksistaan muille.

Vaikka testaus onkin osana kaikkea ohjelmistokehitystä, niin sen harteille ei pidä sälyttää vastuuta lopputuotteen hyvästä laadusta. Laatuajattelun on oltava mukana aivan ensimmäisestä vaiheesta alkaen, sillä tutkitusti testattaessa ei löydetä kuitenkaan käytännössä koskaan kaikkia virheitä, ja myös virheiden korjaaminen aiheuttaa usein uusia virheitä.

Testaukseen kuuluu mm. testausmenetelmien suunnittelu, erilaisten testidokumenttien sekä testipenkkien laatiminen. Testitulosten mukaan ohjelmistoon tehdään tarvittavat muutokset – jos muutoksia pitää tehdä ylemmille tasoille kuten toiminnalliseen määrittelyyn, niin se on yleensä merkki koko projektin yli ulottuvasta heikosta laadusta.

Siinä missä toteutuksessa on tarkoituksena tehdä mahdollisimman virheetön ohjelmisto, testauksessa on tarkoitus löytää mahdollisimman paljon virheitä. Testaus vaatii siis testaajalta destruktiivisen eli hajottavan asenteen. Monet virheet vaativat korjaamista, joten hyvin suoritettu testaus aiheuttaa lisätöitä ohjelmiston toteuttajille. Tämän vuoksi on usein järkevää, että organisaatiossa testauksesta huolehtii eri yksikkö kuin toteutuksesta. Pienissä organisaatioissa tämä ei välttämättä onnistu, mutta mahdollisuuksien mukaan ohjelmoijat voivat kuitenkin testata toistensa valmistamat ohjelmistot tai niiden osat.

[muokkaa] Julkaisu tai käyttöönotto

Julkisesti saataville tarkoitetun ohjelmatuotteen valmistuttua se yleensä julkaistaan. Julkaistaessa kerätään ohjelman osat ja dokumentointi yhdeksi paketiksi sekä tiedotetaan uuden ohjelman tai ohjelmaversion saatavuudesta, lisenssiehdoista sekä ominaisuuksista. Näitä toimenpiteitä varten on olemassa työkaluja ja hallintajärjestelmiä.

Lisenssiehdot määräävät kaupalliset ja juridiset ehdot ohjelman jakelulle, asentamiselle ja käyttämiselle. Kaupallisen jakelun lisäksi tavallisia ehtoja ovat esimerkiksi freeware tai GNU GPL.

Jos ohjelmisto on rakennettu tietylle asiakkaalle, julkaisun sijaan tehdään käyttöönotto. Käyttöönotossa ohjelmistosta valmistellaan asennettava kokonaisuus, joka sitten suunnitellusti asennetaan määrätyille laitteille. Käyttöönottoon liittyy usein myös mm. laitteiston asennus ja valmistelu, tietoyhteyksien valmistelu, vanhojen tietojen konvertointi ja käyttäjien valmentaminen.

[muokkaa] Ylläpito

Ylläpito käsittää ne toimenpiteet, mitä asiakkaat tarvitsevat ollakseen tyytyväisiä ohjelmistotuotteeseen. Tyypillisesti ohjelmistojen katsotaan vanhenevan ennen pitkää, ja tarpeet myös muuttuvat; lisäksi laadukkaastakin ohjelmistotuotteesta löytyy yleensä vähintäänkin pieniä ohjelmistovirheitä, joten käyttäjät odottavat uusia versioita täyttämään muuttuvat tarpeet ja esiintyneet ongelmat.

[muokkaa] Eri tuotantomalleista

Vaikka yllä kuvatut vaiheet ovat enemmän tai vähemmän osana kaikkea ohjelmistotuotantoa, niin niitä voidaan soveltaa eri tavoin. Usein esitetty (ideaali)malli on nk. vesiputousmalli, missä kukin vaihe tehdään loppuun ja hyväksytetään ennen seuraavaan siirtymistä. Mallin heikkoutena on sen utopistisuus ainakin jossain määrin, ja lisäksi vesiputousmallissa syntyvä lopputuote tulee asiakkaan nähtäväksi vasta projektin loppuvaiheessa.

Prototyyppimalli perustuu siihen ajatukseen, että suuri osa projektiin liittyvistä kysymyksistä ja ongelmista selviää vasta, kun tuote on ensimmäisen kerran tehty. Mallissa tehdäänkin alussa hyvin karkea ja erittäin paljonkin yksinkertaistettu malli nopeasti valmiiksi, johon myös asiakas voi tutustua. Prototyypin kautta asiakas osaa esittää tarkemmin vaatimuksiaan havaitessaan konkreettisesti, minkä tyyppinen myöhemmin syntyvä lopullinen tuote olisi. Toisaalta myös kehittäjät oppivat erinäisistä prototyypin valmistusvaiheessa esiintyneistä ongelmista ja rajoitteista, ja kykenevät siten kehittämään esimerkiksi paremman arkkitehtuurin lopulliseen versioon, joka tuotettaisiin esim. vesiputousmallin mukaisesti.

Prototyyppimallissa suuri kiusaus voi olla käyttää jo toteutettuja ohjelmistokomponentteja lopputuotteessa. Näin ei kuitenkaan tule tehdä, koska silloin menetetään prototyyppimallin perusidea.

Myös muita yleisiä malleja on kehitetty, kuten inkrementaalinen malli, jossa ohjelmisto rakennetaan vesiputousmallin mukaisesti siten, että 1. versio on hyvin yksinkertainen toiminnoiltaan. Ensimmäiseen versioon on siis toteutettu vain kaikkein kriittisimmät tai eniten toivotuimmat toiminnot. Seuraavat sukupolvet lisäävät aina uusia ominaisuuksia, ja muutosten tekeminen aloitetaan aina vesiputousmallin alusta asti. Ns. ketterässä ohjelmistokehityksessä uusia versioita tuotetaan usein, ja uusien ominaisuuksien tärkeysjärjestys arvioidaan uudestaan kunkin kierroksen jälkeen.

Formaalit menetelmät käyttävät matemaattisen eksakteja määritelmiä luotaessa, ja niiden tavoitteena on tuotettavan ohjelmiston oikeellisuus, esimerkiksi todistamalla jokin ohjelma tai sen käyttämä algoritmi oikein toimivaksi. Niissä ongelmana on kuitenkin niiden toteuttamisessa vaadittava matemaattinen pätevyys, sekä asiakkaiden suhteen helposti vaikeaselkoisuus. Toisaalta voidaan myös ajatella, että ongelma ohjelmien käsitettävyydestä vain siirtyy matematiikan puolelle – vaikka ohjelma olisikin todistettu oikeaksi, niin ei ole mitenkään itsestään selvää, että todistamisvaiheessa ei olisi virhettä, ja pitkästä matemaattisesta todistuksesta virheen etsiminen voi olla aivan yhtä vaikeaa (tai vaikeampaa) kuin sen itse ohjelmakoodista etsiminen.

[muokkaa] Ohjelmistotuotannon työkalut

Prosessia helpottamaan on kehitetty erilaisia työkaluja. Perustyökaluja ohjelmistotuotannossa ovat mallit, joiden avulla prosessin vaiheita voi hallita. Esim. vesiputousmallissa vaiheet suoritetaan yksi kerrallaan loppuun asti – testausvaiheesta ei voi palata analyysiin.

Muita ohjelmistotuotannon työkaluja ovat UML ja CASE. UML (Unified Modeling Language, yhtenäistetty mallinnuskieli) auttaa visualisoimaan suunnitelmia. UML on kokoelma yksinkertaisia graafisia merkintöjä, kuten laatikoita ja nuolia, joilla on määrätty merkitys. UML on kehitetty olio-ohjelmointiin.

CASE (Computer Aided Software Engineering, tietokoneavusteinen ohjelmistotuotanto) on ollut käytössä 1970-luvulta alkaen. CASE-työkalut ovat ohjelmia, joiden avulla voi organisoida ja visualisoida ohjelmistotuotannon prosesseja. Eri ohjelmointikielille ja -ympäristöille on omat CASE-työkalunsa.