Seuraavat 12kk menevätkin tämän jälkeen gradun parissa! Vielä kun keksisi gradulle sopivan aiheen

Toinen hieno valittamisenaihe on tuo tietojärjestelmätieteen pää- ja sivuaineopiskelijoilleen osoittama tyytyväisyys- ja kehittämiskysely… Ei jumalauta, jos Webropolin kautta osallistutaan “NIMETTÖMÄNÄ” ja nimi / opiskelijanumero annetaan kyselyn lopussa vain “ARVONTATARKOITUKSIIN” (porkkana, että edes joku osallistuisi) niin ei sieltä laitokselta saa saatana tulla mulle henkilökohtaista haukkumapostia, kun minä hiukan kerron rehellisiä mielipiteitäni laitoksen kurssitarjonnasta. TJ4 (Tietotekniikan perusteet?) ja TJ13 (Ohjelmoinnin ja ohjelmistotuotannon perusteet) nyt vain sattuivat molemmat olemaan täyttä kuraa. Ei minua kiinnosta perustelut ja selittely siitä, miksi ne olivat kuraa. En minä niitä uudestaan tule käymään. Molemmista nappasin vitosen pois kuleksimasta, kun sitä puoli-ilmaiseksi tyrkyttivät. Olihan se ihan kiva kopioida javaa suoraan netistä ja opettaa tj4:n luennoilla opettajaa siitä, mitä eroa on eri muistityypeillä ja miten ne tietokoneet oikein nykyään toimivat. Ja jos kurssilla yritetään opettaa jotain sosiaalisen median juttuja, niin niihin voisi etukäteen tutustua. Lisäksi tällaisella kurssilla on täysin turhaa laittaa ihmisiä tekemään jotain esitelmiä ja pakottaa porukka istumaan luennoilla… Kalvot nettiin ja pari linkkiä sähköpostiin, niin opiskelijat kyllä mielellään jättävät luennot väliin ja oppivat ihan yhtä paljon!

Noh, nuo kurssit on nyt takanapäin. Turha niistä on enää kitistä – mutta en kuitenkaan arvosta sitä, että minulle lähetetään jälkikäteen postia, jos olen ollut tyytyväisyyskyselyssä rehellinen ja puhunut suuni puhtaaksi. Jättäkää se tekosyiden keksiminen sinne ala-asteelle ja tehkää kurssitarjonnallenne jotain!

Ystävällisin terveisin,

Närkästynyt opiskelija Turusta.

ps. Onneksi elämä muuten hymyilee, ja kuka siitä koulusta oikeasti jaksaisi kovin paljoa stressata

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

Näihin kysymyksiin en ole saanut vielä kunnollista vastausta. Laatujärjestelmä, laadunhallinta, laaduvalvonta, laadunsitäsuntätä. Termit lentelevät ees sun taas tunnista toiseen päivä päivän perään.

Let’s cut to the chase –Wikpedian määritelmän mukaan:

Laatu-termiä käytetään kuvaamaan esineiden, ihmisten tai prosessien ominaisuuksia ja haluttavuutta. Välineiden ja toiminnan ominaisuudet ovat suhteellisen objektiivisia asioita. Ne voidaan määritellä ja luetella hyvinkin tarkkaan. Subjektiiviseksi laatu muuttuu vasta, kun erilaiset käyttäjät arvioivat sitä omien tarpeidensa ja kokemustensa pohjalta.

Tuote on siis objektiivisesti laadukas, jos se täyttää spesifikaationsa. Onko tuote kuitenkaan laadukas edes objektiivisesti, jos se täyttää spesifikaationsa, mutta spesifikaatiot on luotu virheellisten tarvemäärittelyiden pohjalta? Millä tavoin spesifikaatiot ja tarvemäärittelyt siis vaikuttavat objektiiviseen laatuun?

Subjektiivinen laadun käsite on tässä mielessä helpompi ymmärtää. Tuote on laadukas (eli niin hyvää laatua, huippulaatua), jos se tyydytyttää ihmisen tarpeet riittävän kattavasti. Subjektiivisuudessa on se hieno puoli, että oikeaa ja väärää ei voida erotella. Jokin on mielestäni laadukas, ja sinulla ei ole siihen mitään sanottavaa. Asia vain on niin, kun minä kerran olen sitä mieltä. Markkinataloudessa tilanne on mielenkiintoisempi. Subjektiiviset laatukäsitykset tulisi ymmärtää markkinoiden kokonaisuutena, yleisenä keskiarvona.

Laatujärjestelmä

Mikäs helvetti on sitten laatujärjestelmä?

“Laatujärjestelmä on käsite, jota käytettiin erityisesti 1980-90-luvuilla kuvaamaan organisaatioiden laatutoiminnan kokonaisuutta.” (Wikipedia)

Ja kuten meillekin ohjelmistotuotannon kurssilla ilmeisesti jossain vaiheessa mainittiin: Laatujärjestelmä = Yrityksen toimintatavat.

Termille laadun hallinta (quality management) alisteisia ovat taasen

• Laatupolitiikka (quality policy)
• Laadunsuunnittelu (quality planning)
• Laadunohjaus (quality control)
• Laadunvarmistus (quality assurance, QA)
• Laadun parantaminen (quality improvement)

Laatujärjestelmät siis määrittelevät sen, mitkä prosessit täytyy olla määritelty… Eikä suinkaan sitä, miten ne toteutetaan. Oman ymmärrykseni mukaan näitä laatu- ja laadunhallintajärjestelmiä tarvitaan pääasiassa näin ollen seuraaviin tehtäviin:

• Antamaan raamit toiminnalle
• Löytämään sidosryhmien keskeiset tarpeet
• Lisäämään asiakkaiden luottamusta
• Hallitsemaan toimeksiantoja
• Lisäämään best practices -käytäntöjen läpinäkyvyyttä
• Auttamaan best practices -käytäntöjen viemistä “lattiatasolle”
• Määrittelemään dokumentoinnin

Näistä johtuen prosessien analysointi ja kehittäminen on mahdollista. Organisaatio voi parantaa toimintaansa vain tuntemalla nykyiset tapansa ja prosessinsa.

Nyt mulla meni jo ajatukset solmuun. Palataan CMMI:n ja ISO-standardien pariin vaikka joku toinen kerta?