Ennen uuden teknologian käyt-töönottoa pitää sen hyödyt muuntaa mitattaviksi. Myös mahdolliset riskit pitää huomioida. Useimmat riskeistä on tilapäisiä rajoituksia joiden pitäisi häipyä, kun teknologia ja markkinat kypsyvät.
Oliokeskeisessä systeemityössä korostuu näkemys, jonka mukaan kaikkea siihen liittyvää mallintamista voidaan pitää todellisen maailman mallintamisena tai simulointina. Mallit ja ohjelmat kuvaavat reaalimaailman oliota, niiden toimintaa ja keskinäisiä vuorovaikutuksia. Oliokeskeiset-rakenteet vastaavat tapaa, jolla ihmiset luonnostaan organisoivat ja ymmärtävät todellista maailmaa. Näitä samoja käsitteitä käytetään ko-ko systeemityön elinkaaren ajan.
Oliotyöskentelyssä määrittely, suunnittelu ja toteutus nivoutuvat perinteistä tapaa tiukemmin toisiinsa, jolloin ei menetetä osaa tuotoksesta ja sijoitetusta työpanoksesta siirryttäessä vaiheesta toiseen. Valmis määrittelyn luokkarakenne täydentyy suunnittelussa ja lopulta on myös toteutuksen luokkarakenne. Lisäksi oliomäärittelyn kuvaukset ovat perinteistä paremmin reaalimaailman mukaisia ja siten loppukäyttäjien ym. on helpom-paa osallistua systeemityöhön.
Kaikki oliokeskeisestä systeemityöstä mainostetut hyödyt ovat joh-dannaisia tästä todellisen maailman mallin simuloinnista.
Luonnollisesti teknologia sinäl-lään ei ole itsearvo: edelleenkin jär-jestelmiä kehitetään tukemaan liike-toimintaa. Sen käyttöönotolla pitää olla siis olla jotakin konkreettista hyötyä.
Tärkeimpinä näistä on taloudelli-nen hyöty. Pienempiin kustannuksiin päästään uudelleenkäyttämällä jo olemassa olevaa, tuottamalla järjes-telmät nopeammin ja parempi laatui-sina sekä tuottamalla ne niin, että myöhempi ylläpito ja mahdolliset laajennukset on helppo toteuttaa. Näitä kaikkia hyötyjä lupaillaan olio-teknologialla saataviksi. Nämä eivät kuitenkaan tule itsestään ja useat näistä hyödyistä saavutetaan vasta ajan myötä. Ensimmäisien oliopro-jektien yhteydessä niitä on turha odottaa.
Olio on luonnollinen uudelleen-käytön yksikkö, jossa tiedot ja sitä käsittelevät toiminnot on kapseloituina yhteen. Myös muut olioihin liittyvät käsitteet (polymorfismi, pe-rintä) tukevat hyvin uudelleenkäyttöä. Lisäksi käytetään samaa oliokäsitettä riippumatta siitä kuinka laajasta asiasta on kyse: yksittäinen olio (esim. kynä) tai kokonainen sovellus.
Älä kuitenkaan odota saavuttavasi uudelleenkäytettäviä tuloksia heti. Ensimmäisissä projekteissa puuttuu vielä mm. kokemus ja sen mukana laatu sekä tieto siitä, mitä kannattaa uudelleenkäyttää ja miten.
Nopeampi kehitys on seurauksena lähinnä kahdesta asiasta: uudelleenkäytöstä ja olioajattelun käytön mah-dollistavasta nopeammasta kehitys-prosessista.
Mutta ilman uudelleenkäyttöä to-dennäköisesti kehitys on jopa hitaam-paa. Pelkkä oliokieleen vaihtaminen ei nopeuta kehitysprosessia; käytettä-vä menetelmistö ja prosessi pitää myös vaihtaa.
Lisäksi on syytä ottaa huomioon, että alussa on odotettavissa jopa hi-dastumista. Tähän on useita syitä. Tärkeimpänä ehkä se, että alussa ih-miset vasta opettelevat ja oppimispro-sessi on hidasta. Eikä ensimmäisissä olioprojekteissa ole juuri mitään, mitä uudelleenkäyttää ja tällähän sitä nopeampaa kehitystä pitäisi saada aikaiseksi. Ja jos projekteissa uudel-leenkäytettävää pyritään luomaan, niin sen tuottaminen on hitaampaa kuin ei-uudelleenkäytettäväksi aiotun.
Parempi laatuisia lopputuloksia saadaan uudelleenkäytöllä. Lisäksi olioilla saavutetaan parempi modu-laarisuus kuin perinteisellä tavalla, jossa tiedot ja toiminnot on eroteltui-na toisistaan.
Mutta olioteknologia ei itsessään takaa hyvää laatua. Edelleenkin on mahdollista kirjoittaa huonoja ohjelmia. Laadun pitää tulla teknologiaa käyttäviltä organisaatioilta ja yksilöil-tä.
Laadun aikaansaamiseksi tarvitaan mm. osaavia henkilöitä, standardeja, hyvät välineet ja menetelmät. Ja siksi tarvitaan aika mittaviakin alkuponnis-tuksia. Tärkeänä on myös pitää mie-lessä se, että ensimmäisille oliopro-jekteille ei aseteta turhan kovia vaa-timuksia: ensimmäisistä tekeleistä on turha odottaa laadukkaita: henki-löthän vasta opettelevat.
Olioista seuraava parempi laatu, todellisen maailman malli ja parempi modulaarisuus helpottavat tulevaa ylläpitoa ja laajentamista. Virheiden ja muutoskohtien paikallistaminen on helpompaa, muutokset voidaan tehdä ilman, että uudelleenrakennetaan jär-jestelmä ja uuden tyyppisiä oliota voidaan lisätä, ilman että kosketaan olemassa oleviin.
Oliosovelluksen osille löytyy vas-tineet reaalimaailmasta ja siten muu-tokset kohdistuvat reaalimaailman olioita vastaaviin sovelluksen olioi-hin: muutoskohdat on helppo löytää ja muutoksilla ei ole kauaskantoisia vaikutuksia.
Mutta olioteknologia ei tuo tätä-kään automaattisesti. Tämän päivän kokemukset osoittavat, että vaatii oikeita ja laadukkaita yleiseen tarkoi-tukseen tehtyjä luokkia ja malleja sekä oliomenetelmien käyttöä.
Olioteknologia on ollut jo olemas-sa yli 25 vuotta (SIMULA, 1960-luvun loppu), mutta alan tutkimus-painotteisuus ei ole edistänyt yleistä käyttöä. Käyttö on yleistynyt vasta tämän vuosikymmenen puolella ja tänä päivänä välinemarkkinoiden valtasuuntauksena ovat välineet, jotka sisältävät olioteknologiaa ainakin jossakin määrin.
Ongelmana tässä on se, että jos käytön aloittaa nyt, niin on odotetta-vissa muutoksia kun teknologia kehit-tyy. Tämä ei ole ehkä kovin suuri ongelma: yleensä uudet versiot tuke-vat myös vanhempia. Suurempana ongelmana on se, että kehitys on tänä päivänä vielä enemmän taidetta kuin tiedettä. Jotkin perusasiat ovat selviä, mutta näiden soveltaminen ei aina ole (esim. uudelleenkäyttö, mittarit, projektinhallinta). Menetelmistöt ovat vielä suuressa kehitysvaiheessa ja nimenomaan ne kaipaavat parantamista; miten esim. otetaan uudelleenkäyttö huomioon.
Olioajattelun käyttöönoton riskit liittyvät karkeasti jaoteltuina teknologian kypsyyteen ja sitä kautta kustan-nuksiin. Teknologian kypsyys ja or-ganisaation panostus seuraaville osa-aluille vaikuttaa suuresti riskien hal-lintaan:
Useat organisaatiot unohtavat, että minkä tahansa uuden asian käyt-töönotto vaatii suunnitelmallisuutta: odotetaan tuloksia ilman että ekspli-siittisiä päämääriä tai tavoitteita on asetettu. Tai olioteknologia itsessään nähdään päämääränä. Päämäärien ja tavoitteiden lisäksi myös lähtötilanne jää usein selvittämättä. Usein myös tuloksia odotetaan ilman, että pro-sessia tai resursseja muutetaan, so. käytetään perinteisiä menetelmiä, ei koulutusta, ohjeistusta jne. Suunnitte-lemattomuus johtaa usein siihen, että yritetään omaksua kaikki oliotekno-logiasta kerralla, väärillä ihmisillä liian nopeasti.
Henkilöiden osalta vaikeutena (ja riskinä) on kokeneiden henkilöiden saatavuus sekä motivointi / sitouttaminen ja koulutus.
Osaavien olio-ohjelmoijien puute on vain ongelman näkyvin osa. Osaajia tarvitaan koko systeemityöalueelle, ei vain toteutukseen. Koska teknologia vaatii kokonaan uuden lähestymistavan niin myös esim. projektipäälliköiden pitää ymmärtää oliokehityksen luonne.
Koulutusta jossakin muodossa tu-levat tarvitsemaan kaikki, myös johto (sitouttaminen ja motivointi). Jos organisaatiolta puuttuu johdon todelli-nen sitoutuminen, niin hyvin suurella todennäköisyydellä olioiden käyt-töönotossa epäonnistutaan. On myös varottava olioiden ylimyyntiä: lupauksia, joita ei voida pitää sekä vääriä odotuksia. Johdon lisäksi myös kehittäjät on sitoutettava: heidän työssäänhän tapahtuu suuria muutok-sia ja nämä eivät tule onnistumaan, jos heitä ei saada vakuuttuneiksi nii-den hyödyistä. Pakottamalla saadaan aivan varmasti aikaiseksi muutosvas-tarintaa.
Koulutuksen ja koulutettavien va-linta vaatii myös suunnitelmallisuutta. Suurimmat epäonnistumiset lienee tehdään henkilöiden valinnan suh-teen. Tyypillisesti projektit täytetään henkilöillä, jotka sattuvat olemaan käytettävissä, eikä varmisteta henki-löiden kykyä täyttää vaadittava rooli (jos roolitkaan on ylipäänsä määritel-ty). Ja sattuu jopa niin, että olioasian-tuntijan rooli jää kokonaan täyttämät-tä. Usein myös kuvitellaan, että teo-rian osaava osaa myös käytännössä.
Koulutettavat aiheet, vaadittavat pätevyystasot. koulutusmuodot ja kouluttajat sekä ajoitus on suunnitel-tava kaikille tarvittaville henkilöille ja rooleille. Yksin ajattelutavan muuntaminen proseduraalisesta olio-keskeiseksi on pitkä prosessi. Ei ole siis kysymys vain uuden välineen / kielen opettelemisesta, jonka sinänsä voi oppia muutamassa viikossa. Ja luonnollisesti oliokoulutusta suunni-teltaessa on mietittävä myös kaikki muu tarvittava koulutus. On nimittäin sattunut niinkin, että keskuskone/Cobol-ohjelmoijille on opetettu uusi graafinen Windowsissa toimiva oh-jelmointiympäristö ilman, että heille opetettiin Windowsin käyttöä.
Koska kyse on ajattelutavasta, niin ns. normaalit koulutusmuodot (itseopiskelu, luokkahuoneopetus) eivät ole riittäviä, vaan tarvitaan myös aktiivista käyttöä ja sen ohessa opastusta. Vaativana tehtävänä onkin löytää sopiva sekoitus oppijoita ja opastajia yhteen.
Koulutusta alkaa pikkuhiljaa ole-maan jo hieman laajemminkin saatavilla. Silti yhtenä suurena riskinä tänä päivänä on kuitenkin vielä pätevien ja kokeneiden kouluttajien puute.
Koulutuksen järjestämisessä voi epäonnistua monella tavalla. Yksi ääripää on, että ei järjestetä koulutus-ta ollenkaan, vaan oletetaan, että sii-nä se sivussa. Tai luottaa "fiksuihin" ihmisiin, ilman tukevia resursseja. Toinen ääripää on, että opetetaan olioista kaikki kerralla ilman sula-tusaikaa.
Suurin kustannus tulee oppimises-ta mutta vielä suuremmat kustannuk-set tulevat, jos koulutus jätetään huomioonottamatta. Väärien ihmisien kouluttaminen väärään aikaan on ajan ja rahan haaskausta. Oikeastaan usein esitetyn kysymyksen: "Onko mitään aluetta, johon oliot eivät sovi?" (johon vastaus on "Ei.") voisikin esittää toisessa muodossa: "Onko tilannetta, jossa ei ole suositeltavaa käyttää olioteknologiaa?". Tähän vastaus olisi: "On, jos koulutusta ei mahdollisteta.".
Olioteknologiaan siirtyminen edellyttää yleensä aina ohjelmistohankintoja ja siten kustannuksia. Vä-linevalintoja tehtäessä kannattaa ar-vioida välineiden ominaisuuksien lisäksi mm. toimittajien tulevaisuu-den suunnitelmia ja standardien omaksumista.
Välineet ovat luonnollisesti aina teknologiaa jäljessä. Useimmilla sa-roilla oliopuolen tuotteet ovat jo kyp-syneet; useimmissa versionumerona on suurempi kuin yksi.
Teknologia on vakautumassa ja standardisoitumassa. Vaikka kielille ei ole olemassakaan hyväksyttyä standardia, niin luonnoksia on jo olemassa (Smalltalk, C++, OO-Cobol,..), joita yleisesti aika hyvin noudatetaan. Yleensäkin linjauksena on tehdä välineet toimimaan keske-nään.
Mutta puuttuu vielä TODELLA HYVIÄ välineitä, mm.:
Yhtenä riskinä on myös nähtävä suoritusnopeus sekä tarvittava laitteis-tokapasiteetti, vaikka tämän päivän laitteistokehitys ja hintataso pienen-tääkin tätä riskiä. Koska oliopiirteet edellyttävät ajonaikasta tulkkausta, niin olio-ohjelmat voivat olla hitaampia. Tosin tämä on muuttumassa. Yhä enemmän välinetoimittajat kiinnittävät optimointiin huomiota. Ja toisaalta ne voivat olla jopa nopeampia monimutkaisen informaation käsittelyssä (relaatio- vs. oliotietokanta).
Vaarallisena ajatuksena on nähdä kieli THE teknologiana ja unohtaa kaikki muut aspektit systeemityöstä, joihin olioajattelu tuo muutoksia. Usein THE kielenä nähdään C++ ja tällöinkin siten, että C++ on pa-rempi C. Tässä myös virheellisesti ajatellaan systeemityön olevan ohjel-mointia. C++:n oppimisen vaikeutta ei myöskään koskaan voi liioitella. Vaarana on myös tänä päivänä valita välineeksi sellainen, joka on oliope-rustainen vain nimellisesti.
Menetelmistöt ovat olleet kuuma-na peruna koko 90-luvun. Nyt sillä-kin puolella on näköpiirissä vakiin-tumista ja odotettavissa on jopa jon-kinlaisen standardimenetelmistön saamista (Booch&Rumbaugh; mahdolli-sesti myös Jacobson).
Kuitenkin ne ovat vielä monien asioiden suhteen hyvin kypsymättö-miä. Niistä puuttuu vielä mm. isojen järjestelmien tuki. Olioihin liittyvä modulaarisuus on rajoittunut paikalli-selle tasolle, so. olioihin. Menetel-missä (ja välineissä) on vain rajoittu-nut tuki olioiden ryhmittämiselle suu-rempiin toiminnallisiin moduleihin. Rakenteen puute saattaa johtaa "ravioli-koodiin": paljon hyvin ra-kennettuja olioita, joita on helppo ymmärtää yksinään, mutta joiden vuorovaikutusta on lähes mahdotonta käsittää. Lisäksi useimmat menetel-mät suosivat iteratiivista lähestymistapaa mutta antavat vain vähän ohjei-ta siihen (milloin ja miten iteroida).
Koska monilla menetelmillä on taustalla jokin kieli, joka on suuresti vaikuttanut esim. notaation rikkau-teen, niin myös suunniteltavien sovel-luksien toteutuskieli sanelee omat ehtonsa menetelmistön sekä CASE-välineen valinnalle. Kuitenkin on syytä pitää mielessä, että notaatio*menetelmä.
Menetelmää ei kannata valita (hyvän) olio-CASE-välineen mukaan, vaan menetelmäksi pitäisi valita ja sovittaa organisaation tarpeet täyttävä menetelmä ja vasta tämän jälkeen valita markkinoilta lähin menetelmää tukeva CASE-väline. Riskinä tässä on tietenkin ettei sellaista löydy ja siksi menetelmäksi ei kannata valita ei-yleisesti-tunnettua menetelmää.
Organisaatiolle tämä kaikki mer-kitsee sitä, että sille ei riitä pelkkä menetelmistön valinta vaan tarvitaan myös sen sovittamista organisaation tarpeisiin sekä ohjeistusta, koulutusta ym.
Menetelmistöllä on vaikutuksensa myös mm. ohjelmistotuotannon pro-sessimalliin sekä projektinhallintaan, joten myös näihin tulee muutoksia. Perinteiseen vesiputousmalliin tottu-neille vaikeasti hyväksyttävissä oleva muutos lienee se, että systeemityön alkupäähän pitäisi varata enemmän aikaa, kun perinteisesti toteutus oli se isoin kakku. Lisäksi olioilla kehittämiseen soveltuu erinomaisesti kasvattava ja iteroiva lähestymistapa johon liittyy protoilu (tärkeää kuitenkin on edelleenkin erottaa proto ja tuote toisistaan). Tällainen lähestymistapa tuo projektinhallintaan sellaista epämääräisyyttä, että esim. aikataulua ei voida tehdä silläkään tarkkuudella kuin perinteisellä puolella. Toisaalta on myös huomioitava, että yksi ja sama prosessimalli ei sovi kaikille projek-teille.
Tänä päivänä puuttuu myös mitta-reita sekä projektin että laadun hallin-taan. Aiheesta löytyy kyllä jo kirjalli-suutta, mutta parhaimmatkin niistä pohjautuvat kuitenkin vielä arvai-luun: kokemusperäistä tietoahan on vain vähän saatavilla. Esim. luokan kehittämiseen kulunut kokonaismäärä eri lähteiden perusteella vaihtelee välillä 10-30pv/luokka. Suurin vai-kuttava tekijä on toteutuskielen valin-ta; esim. Smalltalk-luokat vaativat huomattavasti vähemmän ponnistusta kuin C++:n. Kehittäjän kokemus tai taito on seuraavaksi suurin tekijä (kokematon *1½*kokenut).
Uudelleenkäyttö vaatii organisointia, muutoin se on parhaimmillaankin ainoastaan valmisosien suoraa käyttöä (vrt. yleismodulit). Ei auta jos on olemassa sopiva uudelleenkäytettävä komponentti (suunnitelma / luokka / ..) jollei se ole helposti löydettävissä. Sen lisäksi, että organisointi on edellytys käytölle, niin se on myös edellytys sille, että uudelleenkäytettäviä komponentteja yleensä syntyy: ne eivät synny automaattisesti muun työn "sivutuotteina" vaan ne vaativat ensinnäkin uudelleenkäytettävän komponentti havaitsemisen ja huomattavasti enemmän sekä suunnittelu- että toteutustyötä. Kunnollisen organisoinnin lisäksi uudelleenkäyttö vaatii myös koulutusta: liian helposti ajatellaan tyyliin "itse teen paremmin".
Vaikka oliot tukevatkin uudel-leenkäyttöä, niin ne eivät kuitenkaan tee maagisesti uudelleenkäyttöä hel-poksi. Suurimpia virheajatteluja (ja riskejä) edellä olevan lisäksi on odottaa uudelleenkäyttöä välittömästi siirryttäessä olioteknologiaan ja että jo ensimmäinen projekti tuottaa uu-delleenkäyttöä. Lisäksi on virhe vaa-tia kaikkien projektien tuottavan uu-delleenkäyttöä riippumatta niiden tavoitteista. Ja koska uudelleenkäytet-täväksi tekeminen on vaativaa puu-haa, niin on turha odottaa, että kaikki kehittäjät pystyvät tuottamaan uudel-leenkäyttöä tai ylipäänsä sekoittaa uudelleenkäytön tuottajan ja kulutta-jan rooli samaan henkilöön.
Teknologia kypsyy nopeasti: lu-paukset ovat suuria mutta riskejäkään ei voi unohtaa. Onneksi tämän hetken paine teknologian kaupallistamiseksi tuo paljon muutoksia näihin riskeihin.
Ottaako vai eikö ottaa? Molem-missa on riskinsä: liian aikaisin vs. liian myöhään. Järkevä strategia on pilotoida teknologiaa, jolloin päätöstä siirtymisestä ei tarvitse tehdä heti. Lisäksi organisaatio saa omasta takaa ensikäden tietoa teknologian arvosta ja jos siihen siirrytään, niin on jo kokemusta.
Olimenetelmien ja -kielien, yleen-säkin olioajattelun omaksuminen on vaikea asia: kokemukset ovat välttä-mättömiä ja siksi kokemuksien hankkiminen kannattaa aloittaa jo nyt!
Riskeinä käyttöönotolle nyt ovat puuttuvat standardit, menetelmien ja välineiden kypsymättömyys sekä vä-häinen osaaminen. Myöhemmin käyttöönotettaessa riskeinä on nähtävä teknologian nopea eteneminen - hel-pompaa aloittaa nyt - sekä kilpailu-hyödyn menettäminen.
Kuten kaikkien uusien teknologi-en käyttöönotossa niin myös olioteknologiankin alkukustannukset ovat suuret: tarvitaan harjaannuksen ja koulutuksen lisäksi uudet välineet ja jopa organisaatiorakenteen muutoksia (mm. uudelleenkäytön organisointi). Kustannukset laskevat, mitä pidem-mälle uudelleenkäytössä päästää (ja vain tällöin).
Ennen kaikkea pitää tiedostaa, että olioteknologian käyttöönotto ei ole helppo asia: se vaatii suunnitelmalli-suutta mm. koulutuksen ja uudelleenkäytön organisoimiseksi. Missään nimessä käyttöönottoa ei pidä aloittaa ottamalla käyttöön jokin oliototeutus-väline, vaan ennen sitä on otettava käyttöön ja myös opittava olioajattelu (sekä -menetelmä). Useilla toteutusvälineillä (kuten C++-kielellä) voi tehdä täysin perinteisiä ohjelmia, ja jos olioideologiaa ei olla sisäistetty näin tulee käymäänkin. Ainoastaan sovittamalla olioajattelua läpi koko systeemin elinkaaren voidaan saavuttaa luvatut hyödyt.
Silja Räisänen,