Ohjelmistotuotanto on yhteisnimitys niille työnteon ja työnjohdon menetelmille, joita käytetään, kun tuotetaan tietokoneohjelmia sekä monista tietokoneohjelmista koostuvia tietokoneohjelmistoja. Laajasti ymmärrettynä ohjelmistotuotanto kattaa kaiken tietokoneohjelmistojen valmistukseen liittyvän prosessinhallinnan sekä kaikki erilaiset ohjelmistokehitysmenetelmät. Ohjelmistotuotantoon kuuluu siis periaatteessa mikä tahansa toiminta, joka tähtää tietokoneohjelmien tai -ohjelmistojen valmistukseen. Tarve valmistukseen tulee asiakkaalta tai ohjelman tuottaja tekee markkinointitutkimuksen ja päättelee tarpeen ohjelmistolle.
Jotta ohjelmistojen valmistusta voitaisiin käsitellä järjestelmällisesti, ohjelmistotuotannossa on pyritty mallintamaan ohjelmistojen valmistusprosessia niin sanotun elinkaarimallin mukaisesti. Elinkaarimallissa ohjelmiston valmistus pyritään näkemään mahdollisimman laajana, aikaan sidottuna prosessina, jossa ohjelmiston varsinainen tekninen valmistus on vain pieni – joskin äärimmäisen tärkeä osa – kokonaisketjua.
Ohjelmistotuotannossa tieteenhaarana tutkitaan myös ohjelmien rakenteellisia ominaisuuksia kuten dokumentointia, versionhallintaa, sekä jäljitettävyyttä. Tutkimuksen kohteena ovat myös erilaiset ohjelmistojen tukiprosessit, kuten määrittelyprosessi, ylläpitoprosessi ja projektinhallinta. Myös erilaisia toteutus- ja suunnittelumenetelmiä, joilla itse tuotannon laatua voidaan tehostaa, tutkitaan.
Ohjelmistotuotantoon kuuluvat myös erilaiset laatujärjestelmät, joita käytetään erityisesti yrityksissä dokumentoimaan yrityksen toimintatapoja. Laatujärjestelmän tavoitteena on dokumentoida ja ottaa käyttöön hyväksi havaitut toimintatavat, jotka parantavat yrityksen toimintaprosessin laatua.
Kaupallista ohjelmistokehitystä tehdään yleensä projektityönä. Toisaalta useiden ohjelmistojen kehitys ja ylläpito jatkuvat koko niiden elinkaaren ajan ilman ennakoitavaa päätepistettä. Ylläpitotyökin voidaan jakaa määrämittaisiksi toisiaan seuraaviksi projekteiksi. Projektin toteuttamista ohjaavat ohjelmistoprosessit, jotka kuvaavat toistuvan tavan toteuttaa ohjelmistoprojekteja. Prosessit vaihtelevat suuresti laajuudeltaan ja sen suhteen, millaisia menettelytapaohjeita ne antavat. Noudatettava prosessimalli voi olla kevyt, jos kehityshankkeet ovat pieniä ja niiltä odotetaan suurta kustannustehokkuutta. Raskaita prosesseja käytetään toimialoilla, joissa ohjelmistoilta odotetaan poikkeuksellisen suurta luotettavuutta.
Ohjelmistotuotannon historia
Ensimmäiset digitaaliset tietokoneet tulivat käyttöön 1940-luvulla. Näiden koneiden suorittamat tehtävät määriteltiin muuttamalla koneiden sähköisiä kytkentöjä. Von Neumannin arkkitehtuurin mukaiset ohjelmoitavat tietokoneet kehitettiin 40-luvun lopulla, jolloin myös ensimmäiset tietojärjestelmä- ja ohjelmistokehityshankkeet käynnistettiin.
Ennen vuotta 1954 lähes kaikki ohjelmointi tehtiin matalan tason ohjelmointikielillä kuten konekielellä tai assemblyllä. Suuri osa ohjelmoijien työstä liittyi tuon ajan tietokoneiden rajoitteisiin.
Termi software engineering (ohjelmistosuunnittelu) on esiintynyt vuonna 1965 Computers and Automation -lehden yritysluettelossa.http://www.bitsavers.org/magazines/Computers_And_Automation/196506.pdf Myöhemmin termi esiintyi vuonna 1966 ACM:n puheenjohtajan Anthony A. Oettingerin kirjeessä Communications of the ACM -lehdessä. Oettinger kirjoittaa tietojenkäsittelytieteen olevan yksistään liian rajaava termi ja huomauttaa ammattimaisen insinöörialan luonteesta ohjelmiston ja laitteiston suunnittelussa.
Ohjelmistokriisi tunnistettiin 1960-luvun loppupuolella. Sillä tarkoitettiin tilannetta, jossa pula ohjelmoijista ja selkeiden systeemityömenetelmien puuttuminen johti heikkoon tuottavuuteen, paljon ohjelmointivirheitä sisältäviin ohjelmiin ja kustannusten karkaamiseen käsistä. 1900-luvun loppupuolella alkanut tietokoneohjelmien merkityksen ja lukumäärän kasvu ovat tuoneet julkisuuteen lukuisia tietokoneiden aiheuttamia virheitä, jotka ovat lähes aina olleet seurausta inhimillisistä erehdyksistä: tietokoneohjelmien lähdekoodeissa on ollut virheitä tai ohjelmien käytettävyys on ollut huono. Ohjelmistotuotanto tutkimusalueena on kehitetty vastaamaan kysymykseen, miten ohjelmistoja tulisi valmistaa niin, että niiden laatu olisi mahdollisimman korkea. Ohjelmiston laatu pitää tässä yhteydessä käsittää ohjelmiston tavoiteltavana toimintana, mikä ei ole sama asia kuin lähdekoodin tai käyttöliittymän täydellinen virheettömyys.
Ohjelmistotuotannon merkityksestä Ohjelmistoteollisuus on Suomen nopeimmin kasvava vientiala. Ohjelmistoalan merkittävin alatoimiala on ohjelmistojen suunnittelu ja valmistus.
Vaihejakomallit
Ohjelmiston tai ohjelman tuottaminen on laaja ja monimutkainen tehtävä. Onnistuneen tuotannon varmistamiseksi kehitystyö jaetaan osiin. Seuraavaan osaan ei voida edetä, ennen kuin edellinen osa on tarpeellisin osin saatu valmiiksi. Tätä ositusta ohjelmien suunnittelussa sanotaan vaihejakomalliksi.
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 vähimmäisvaatimukset 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. Käytännössä 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. Tästä käytännön sanelemasta tarpeesta ovat syntyneet useat iteratiiviset prosessimallit, kuten Rational Unified Process, spiraalimalli tai niin sanottu ketterä kehitys.
Kun vesiputousmalliin yhdistetään joka vaihetta vastaava testaus (esimerkiksi vaatimusmäärittelystä hyväksymistestaus) aikajanalle syntyy niin kutsuttu V-malli, jonka vasen sakara kuvastaa prosessin vaiheita ja oikea kunkin testausta. Prosessia, joka toistaa alemman tason suunnittelua ja toteutusta, kutsutaankin W-malliksi, jossa keskisakara kuvastaa iteraatiota.
Vesiputousmalli kuvastaa ohjelmistotuotantoa teoreettisella tasolla hyvin, mutta sen soveltuvuudesta käytännön ohjelmistotuotantoon ollaan erimielisiä. Vesiputousmallin tärkein ansio onkin antaa puitteet, joita myös iteratiiviset prosessit noudattavat, vaikkakin huomattavasti tiheämmissä sykleissä ja kevyemmillä menetelmillä. Voidaankin sanoa, että kaikki ohjelmistotuotantohankkeet noudattavat jollain tasolla vesiputousmallia, mutta eivät välttämättä toteuta kaikkia sen vaiheita dokumentoiduilla menetelmillä.
Prototyyppimenetelmä
Prototyyppimenetelmässä ohjelman kehittäminen etenee spiraalimaisesti. Prototyyppimallissa ulkoasu (käyttöliittymä) rakennetaan ensin ja vasta sitten spiraalimaisesti laajenevin kehin tuotteen liiketoiminnallinen kerros (bisneslogiikka) sekä tietokantakerros. Menetelmän etuna asiakas saa nopeasti nähtäväksi tuotteen lopullisen ulkoasun. Asiakas voi jo tässä vaiheessa kertoa, jos kehittelijät ovat toteuttaneet jotain toisin kuin hän on halunnut. Mahdolliset muutokset on vielä helppo ja kustannuksiltaan edullista ja työmäärältään vähäistä tehdä tässä vaiheessa. Prototyyppimenetelmä on hyvä myös silloin kun (asiakkaan) vaatimukset muuttuvat usein.
Kun asiakas on hyväksynyt kehityskierroksen esitetyn prototyypin, kehittelyä jatketaan spiraalin laajenevalla kehällä. Syvennetään ja laajennetaan suunnittelua. Kun kehitysprosessi on kiertänyt kokonaisen ympyrän, seuraavaa prototyyppiä esitellään asiakkaalle. Näin jatketaan iteratiivisesti, kunnes päädytään tuotteen lopulliseen kehitysversioon. Kun asiakas on hyväksynyt tuotteen, se on valmis.
RUP
RUP (Rational Unified Process) perustuu peräkkäisiin iteraatioihin, joista jokainen iteraatio suunnitellaan vesiputousmallin mukaisesti. Kehittäminen jakautuu neljään vaiheeseen: aloitus, tarkennus, rakennus ja käyttöönotto.
Ketterät menetelmät
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. Nopeimmin kehittyvillä ohjelmistotuotannon aloilla ja etenkin pienemmissä ohjelmistoprojekteissa on omaksuttu niin kutsuttuja ketteriä ohjelmistoprosesseja, jotka korostavat muutosten hallintaa ja nopeita iteraatiosyklejä. Periaate on suunnata ja korjata kehittelyä mahdollisimman aikaisessa vaiheessa. Virheellistä kehitystyötä on tehty silloin vasta mahdollisimman vähän ja kehittelyn resurssien (muun muassa aika- ja kustannusresurssit) hukkaaminen on mahdollisimman vähäistä.
Yksi uusimpia ketteriä menetelmiä on Scrum.
Muita menetelmiä
Muita ohjelmankehitysmenetelmiä on muun muassa Suihkulähdemalli. Menetelmässä ohjelma koodataan suoraan ja sen jälkeen luodaan dokumentointi. Varsinaista mallinnusta ja suunnittelua ei tässä menetelmässä ole. Suunnittelu tapahtuu koodaajan mielessä. Suihkulähdemalli soveltuu pienien (apu)ohjelmien tekoon. Laajempien ohjelmistojen suunnittelun hallinta ei onnistu suihkulähdemenetelmällä.
EVO-mallissa rakennetaan ensin ydinjärjestelmä, jota kehitellään edelleen seuraavissa projektin iteraatioissa.
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. Lisäksi havaitun virheen korjaaminen voidaan joutua tekemään iteratiivisesti edellisiin vaiheisiin. Se on aikaavievä ja kallis prosessi.
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 esimerkiksi 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. Jos jokainen sukupolvi sisältää vaiheet aina vesiputousmallin alusta asti, on kyseessä iteratiivinen malli. Tällöin sukupolvea kutsutaan iteraatioksi. Niin sanotussa ketterässä ohjelmistokehityksessä uusia versioita tuotetaan usein, ja uusien ominaisuuksien tärkeysjärjestys arvioidaan uudestaan kunkin kierroksen jälkeen.