Ohjelmistotuotanto: Ohjelmien tuotannon erityispiirteet

Jatkan listaamalla ajatuksiani tuosta ohjelmistotuotannon kurssista (Ohjelmistotuotannon ja OHJELMOINNIN itse asiassa… Mutta taisi se Java-osio mennä kokonaan itseopiskeluna. Ensimmäisellä ohjelmoinnin luennolla nimittäin luin läpi kaikki kurssin kalvot ja totesin, että opin enemmän lukemalla Sunin omat tutoriaalit)

Ohjelmistot siis otsikon mukaisesti eroavat perinteisistä fyysisistä tuotteista. Tämä ei liene kenellekään yllätys. Usein kuitenkin (erityisesti liikejohto, sekä asiakkaan että toimittajankin puolella) unohdetaan mitkä asiat oikeasti ovat ominaisia ja erityisiä ohjelmille. Tulen käymään tässä blogipostissani näitä asioita lyhyesti läpi.

“Ohjelmistotuotanto on se tietojenkäsittelytieteen osa-alue, joka käsittelee niin laajojen ja monimutkaisten ohjelmistojen rakentamista, että kehitystyöhön tarvitaan kehittäjäryhmä (tiimi) tai useita.” [Ghezzi et al.]

1. Ohjelmat ovat monimutkaisia
Ohjelmia kehitetään ratkaisemaan monimutkaisia ongelmia. Ne ovat siis jo lähtökohtaisesti monimutkaisia, sillä harvoin monimutkaisia ongelmia voidaan ratkaista yksinkertaisilla ohjelmilla. Vaikka monimutkaisuutta ja sen aiheuttamia ongelmia voidaankin vähentää hierarkisuudella, kätkemällä informaatiota ja hyödyntämällä esim. suunnittelumalleja, ei mitään häkellyttäviä ratkaisuja olla löydetty. Kompleksisuutta aiheuttavat perinnejärjestelmissä suuri koko ja oliojärjestelmissä komponenttien väliset suhteet ja vuorovaikutus.

2. Ohjelmat ovat näkymättömiä
Näkymättömyyden takia aikataulutuksen seuraaminen ja projektien etenemisen arviointi voivat aiheuttaa pienelle ihmismielelle paljon vaivaa. Puolet varatusta ajasta saattaa olla jo käytetty, koodia ei ole yhtään riviä ja silti projekti on vielä hyvin aikataulussa. Toisaalta puolet ajasta saattaa olla jo käytetty, koodi “valmis” ja testaus käynnissä, mutta silti projekti on nyt jo myöhässä.

3. Ohjelmat ovat “helposti” muunneltavia
Ohjelmaa on helppo muuttaa. Se on halpaa ja “vaivatonta”. Laitetaan koodari kirjoittamaan vaan joitain moduuleita tai moduulien osia uusiksi. Seurauksena on, että asiakas haluaa koko ajan lisää ja lisää muutoksia ja toimittaja ei ikinä pääse a) siirtymään todelliseen ylläpitovaiheeseen ja/tai b) keskittymään uusiin projekteihin.

4. Ohjelmat (tai ohjelmistoprojektit) ovat ainutkertaisia
Fyysisiä tuotteita tuotetaan usein kymmeniä, satoja, tuhansia tai satoja tuhansia kappaleita. Tällöin pystytään hyödyntämään muun muassa oppimiskäyrän (learning curve / experience curve) mukaista kustannusten pienenemistä sekä skaalaetuja (economics of scale). Ohjelmistoprojektit ovat kuitenkin usein ainutlaatuisia. Ohjelmia joudutaan toteuttamaan ja/tai muokkaamaan ympäristöön ja asiakkaan tarpeisiin sopiviksi. Lisäksi ne vaativat ylläpitoa. Vaikka uudelleenkäyttöä on pikkuhiljaa yritetty lisätä, on parametrointityö ainakin ainutkertaista (vaikka kokemuksen perusteella voidaan luoda best practices -tapoja myös esim. implementoinnille ja parametroinnin suorittamiselle).

5. Skaalautuvat huonosti
“Ainoa varma asia on muutos – on konsulttien suosikkimantra tällä hetkellä. Valitettavasti se on myös totta. Muutospaineet, jotka toivottavasti järjestelmän korkea ylläpidettävyys pystyy hoitamaan, aiheuttavat useimmiten aina kasvua. Kasvu tarkoittaa aina lisää käyttäjiä, liittymiä tai jopa kolmannen osapuolen järjestelmiä. Skaalautuvuus voidaan tiettyyn rajaan hallita ostamalla suurempia koneita, mutta keino on suhteettoman kallis jos ohjelmistoa ei voida sijoittaa pienempiin osiin.” – Teemu Ikonen, Teknillinen korkeakoulu

Tästä ei minulla enemmän sanottavaa. Saatan palata skaalautuvuuteen myöhemmin, tosin lähinnä ketterien menetelmien yhteydessä

6. Ohjelmat ovat epäjatkuvia
Auto yleensä toimii vaikka siitä jokin mutteri irtoaisikin. Ruoste tai maalipinnan ilmakuplat eivät vielä estä sinua ajamasta autolla töihin. Ohjelmat ovat kuitenkin epäjatkuvia: Pienikin virhe voi kaataa koko järjestelmän. Mitään oletuksia ei siis voida tehdä, vaan homma pitää alusta alkaen hoitaa tarkkaan. Lisäksi korjaamalla virheen paikassa A, saatat löytää virheen paikasta B.

Lisäksi ohjelmiston virheet ovat jokaisessa teoskappaleessa. Näin ei fyysisten tuotteiden tapauksessa ole. Ostaessasi kaksi hampurilaista, joista toisesta löytyy matoja, saattaa toinen olla vielä ihan syötävä. Ohjelmistoa kopioitaessa myös virheet kopioituvat (Yksi syy siihen, miksi vastuurajoitukset ovat tärkeitä sopimuksissa. Mikäli toimittaja olisi vastuussa kaikille asiakkailleen suhtellisen pienistäkin virheistä, olisivat ohjelmistot todella kalliita. Markkinataloudessa nimittäin riskit hinnoiteltaisiin jo alkuperäiseen sopimukseen. Nykyinen ratkaisu ja vastuun rajoittaminen on siis parempi valinta.)

Suurimmat ongelmat syntyvät kuitenkin kun edetään lineaarisesti eteenpäin (vaikkapa vesiputousmallin mukaisesti) ja järjestelmälle on alun perin asetettu väärät vaatimukset. Projekti etenee, toteutusmahdollisuudet muuttuvat ja asiakas haluaakin jotain muuta. Seurauksena on paniikki: Jotain pitäisi muuttaa ja siirrytään hallitsemattoman iteroinnin vyöhykkeelle. Palaillaan aikaisempiin vaiheisiin, ei tiedetä mitä tehdään ja tuhlataan resursseja aikaisempien virheiden korjaamiseen. Projekti myöhästyy ainakin seuraavasti: Todellinen käytetty aika = ( Alkuperäinen arvio * Pii ) * 1,3… Ja kustannukset kasvavat vähintään samassa suhteessa.

Mitä ohjelmistotuotannon ongelmille voidaan tehdä?

• Hopealuoteja ei ole!
• Systemaattisuudella voidaan saavuttaa merkittäviä parannuksia.
• Avainasemassa ovat:

1. Toiminnan kehittäminen, jatkuvan parantamisen periaate

2. Laatujärjestelmät

3. Henkilöstön kehittäminen

4. Liiketoimintalähtöinen toiminta

• Ei niinkään ”know how” vaan ”know when”.

Muistutan vielä lopuksi, että ohjelmistotuotannossakin painavat liiketaloudelliset tavoitteet. Raha on valtaa ja raha määrää mihin suuntaan kehitys kulkee. Näin käy “aina” rakastamassamme länsimaisessa markkinataloudessa.

ps. Lueskelin tässä läpi Weinbergin teesejä. Nämäkin olisi muuten voinut kurssin aikana mainita! Kurssikirjasta sentään löytyi viittauksia Weinbergin artikkeleihin