Remove ads
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.
Remove ads
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ä.[1] Suuri osa ohjelmoijien työstä liittyi tuon ajan tietokoneiden rajoitteisiin.[1]
Termi software engineering (ohjelmistosuunnittelu) on esiintynyt vuonna 1965 Computers and Automation -lehden yritysluettelossa.[2] Myöhemmin termi esiintyi vuonna 1966 ACM:n puheenjohtajan Anthony A. Oettingerin kirjeessä Communications of the ACM -lehdessä.[3] Oettinger kirjoittaa tietojenkäsittelytieteen olevan yksistään liian rajaava termi ja huomauttaa ammattimaisen insinöörialan luonteesta ohjelmiston ja laitteiston suunnittelussa.[3][4]
Ohjelmistokriisi tunnistettiin 1960-luvun loppupuolella.[5] 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.
Remove ads
Ohjelmistoteollisuus on Suomen nopeimmin kasvava vientiala.[6] Ohjelmistoalan merkittävin alatoimiala on ohjelmistojen suunnittelu ja valmistus.[7]
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.
Ohjelmien suunnittelu voidaan ajatella spesifikaatioiden (määritysten) luomisena. Suunnittelussa edellinen vaihe luo spesifikaation, joka on syötteenä seuraavalle vaiheelle. Spesifikaatiot voidaan jaotella formaaleiksi ja informaaleiksi spesifikaatioiksi. Formaalit menetelmät ovat jäykkiä, mutta niiden käsittely on helppoa ja käsittely voidaan koneellistaa. Informaalien menetelmien ilmaisuvoima on hyvä, mutta käsittely monimutkaisempaa.
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.
Remove ads
Ohjelmiston elinkaari jakautuu kahteen pääluokkaan: kehitys ja ylläpito. Ohjelman kehitykseen kuuluvat vaatimusmäärittely, ohjelmistosuunnittelu, toteutus, testaus, julkistus ja käyttöönotto.
Ennenaikainen-Alpha on teknologianäyte ohjelmiston yhdestä tai kahdesta ydintoiminnosta. Vaihe koostuu ennen kaikkea toimintojen suunnittelusta. Alpha on ohjelmiston kehityksen ensimmäinen vaihe, jonka aikana ohjelmisto suunnitellaan pääpiirteissään ja jonka aikana ohjelmiston toiminnot luodaan. Beta on vaihe, jonka aikana ohjelmiston toiminnallisuus on suunniteltu loppuun. Vaiheen aikana on tarkoitus viimeistellä toiminnot ja tuottaa ohjelmisto tilaan, jossa se kykenee toimimaan käytännön tilanteessa omillaan.
Vaatimusanalyysi
Vaatimusanalyysin eli vaatimusmäärittelyn tarkoituksena on selvittää ne ohjelmistotuotteelle asetetut ohjelmistovaatimukset, 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 esimerkiksi sitovat toteutuksen tiettyyn ohjelmointikieleen esimerkiksi asiakkaan erityistarpeiden vuoksi.
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 esimerkiksi 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, 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 (esimerkiksi 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.
Järjestelmäsuunnittelu
Järjestelmäsuunnittelussa 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 tasolla pohditaan mitä laitteita ja ohjelmistoja tarvitaan ja kuinka ne liittyvät toisiinsa.
- Yksittäisen laitteen tasolla päätetään muun muassa 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.
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.
Laajojen ohjelmistojen suunnittelun hallinta helpottuu, jos ohjelmisto jaetaan erilaisiin kerroksiin. Yksi tunnettu malli on MVC-malli, jossa käyttöliittymä erotetaan muista osista. Etuna on se, että esimerkiksi käyttöliittymän muuttaminen on helpompaa kun muutokset tulevat vain siihen osaan ohjelmansuunnittelussa. Toinen tunnettu kerrosmalli on kolmitasomalli, jossa tasoina ovat käyttöliittymä, liiketoimintakerros (businesslogiikka) ja tietokantakerros (tiedon tallennus).
Toiminnalliselle määrittelylle vastakohta on tekninen määrittely. Tekninen määrittely eli arkkitehtuurisuunnittelu 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 esimerkiksi käytetty ohjelmointikieli/kielet, ohjelmistokomponentit kuten kirjastot, ohjelmistokomponenttien rakenne ja keskinäinen hierarkia, käytetyt tietorakenteet ja niiden väliset sovellusrajapinnat jne.
Arkkitehtuurisuunnittelussa voidaan käyttää hyväksi suunnittelumalleja (engl. design patterns)[8], jotka ovat valmiita ratkaisuja suunnitteluongelmiin (tehtäviin). Niiden etuna on tehokkuus ja toimintavarmuus.
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: palvelinohjelma-prosessit, asiakasohjelma-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.
Toteutus
- Pääartikkeli: Ohjelmistokehitys
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ä.
Ohjelmankehitysympäristöissä toteutusvaihe voi olla puoliautomaattinen. Kehitysympäristö osaa kehittää luoduista suunnitelmista ohjelmakoodin rungon, jossa luokkakaaviosta on johdettu valmiit koodit luokille, luokan tietojäsenille sekä metodirungot parametreineen. Se nopeuttaa huomattavasti koodaajan työtä kun hänen pitää lisätä vain metodien toiminnallinen sisältö koodeihin.
Testaus
- Pääartikkeli: Ohjelmiston testaaminen
Alpha-testaus on ohjelmistokehityksen vaihe, jonka aikana tutkitaan luotujen toimintojen kykyä toimia oikein käytännön tilanteessa. Vaiheen aikana on tarkoitus kartoittaa myös ohjelmiston sisäinen koodi dokumentoituun muotoon. Beta-testausvaiheen aikana ohjelmistosta etsitään ja korjataan pois mahdolliset ohjelmointivirheet eli bugit, joita on saattanut aiheutua mahdollisista Beta-vaiheen aikana tehdyistä muutoksista. Beta-testaus on ohjelmistonkehityksessä eräs eniten aikaa vaativista vaiheista.
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 muun muassa 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.
Ohjelmiston testaus voidaan jaotella myös muun muassa seuraaviin:
- Yksikkötestaaminen
- Integraatiotestaaminen
- Regressiotestaaminen
- Hyväksyntätestaaminen
Julkaisu tai käyttöönotto
Julkaisuehdokkuudesta puhutaan kun ohjelmisto on saavuttanut tietyn toiminnallisen tilan, jossa kaikki ohjelmiston ominaisuudet toimivat lähes virheettömästi ja ohjelmisto on valmis julkaistavaksi. Useimmissa tapauksissa julkaisua ei kuitenkaan voi tapahtua, ennen kuin kaikki ohjelmistoa kehittävät tahot ovat siihen tyytyväisiä. Joskus ohjelmiston valmistuminen ajallaan on tärkeämpää kuin riittävä testaus, jolloin Julkaisuehdokkuus kyseenalaisesti ohitetaan.
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ä.
Tuotantoon julkaisemista kutsutaan myös nimellä kultaaminen, joka tulee siitä, että alkuperäinen ohjelmiston Master-levy viedään monistettavaksi ja paketoitavaksi tehtaalle tai se valmistellaan internet-pohjaista levitystä varten. Ohjelmisto saatetaan kääntää eri kielille, lisäksi sen ohjekirjat kirjoitetaan ja tulostetaan. Myös markkinoinnin suunnittelu kuuluu osaksi tätä vaihetta.
Lisenssiehdot määräävät kaupalliset ja juridiset ehdot ohjelman jakelulle, asentamiselle ja käyttämiselle. Kaupallisen (ks. omisteinen ohjelmisto) jakelun lisäksi on avoimen lähdekoodin lisenssejä kuten GNU GPL. Freeware-ohjelmistot ovat maksuttomia, mutta niiden lähdekoodi ei ole aina saatavilla.
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 muun muassa laitteiston asennus ja valmistelu, tietoyhteyksien valmistelu, vanhojen tietojen konvertointi ja käyttäjien valmentaminen.
Ylläpito
Ohjelmien ja ohjelmistojen ylläpito ei kuulu enää ohjelmistotuotantoon eikä ohjelmien kehittelyyn vaiheena. Ylläpidon tarkoitus on pitää ohjelmisto toimintakuntoisena ja raportoida virheistä tuotannolle. Ylläpitoon kuuluu ohjelmien uusien versioiden päivitys vanhojen tilalle ja päivityksestä aiheutuvat muutostoimet. 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.
Elinkaaren loppu
Ohjelma ei ”kuole” koskaan. Ohjelma voi tulla tarpeettomaksi kun
- käyttöympäristö muuttuu siten, että ohjelmaa ei voida enää käyttää
- tulee uusi parempi menetelmä suorittaa ohjelman tekemät asiat
- ohjelman tekemien toimenpiteiden tarve loppuu
- ohjelman toiminnot yhdistetään uuteen ohjelmaan
- ohjelman käyttö ja kehittely loppuu.
Remove ads
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. UML-mallinnuksia voi tehdä esimerkiksi ohjelmilla MS Visio, Argo UML, Eclipseen asennettavalla liitännäisohjelmalla, NetBeans, yms.
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.
Tunnettu ohjelmankehitysympäristö on Eclipse.
Remove ads
Wikiwand in your browser!
Seamless Wikipedia browsing. On steroids.
Every time you click a link to Wikipedia, Wiktionary or Wikiquote in your browser's search results, it will show the modern Wikiwand interface.
Wikiwand extension is a five stars, simple, with minimum permission required to keep your browsing private, safe and transparent.
Remove ads