ohjelmointi (programming)

Järjestelmän käyttäjien kanssa määritellyn ohjelmiston toteuttaminen ohjelmointikieliä käyttäen.

"Nykyiset kehittyneet ohjelmointiympäristöt sallivat ajattelemattomat kokeilut", toteaa Donn Seeley artikkelissaan How Not to Write Fortran in Any Language (Seeley 2004) esittäessään vastakohdan sillä kuinka "vanhat kamalat järjestelmät vaativat ohjelmoijia ajattelemaan sitä, mitä he toteuttavat". Useimmat Fortran-ohjelmat olivatkin luonnontieteilijöiden kirjoittamia, eivätkä niinkään tietojenkäsittelyn ammattilaisten, minkä vuoksi tuotettu ohjelmakoodi oli usein tietojenkäsittelyllisten kriteerien valossa melko kelvotonta.

Käytetyllä ohjelmointikielellä on vaikutuksensa ohjelmakoodin laatuun, mutta useimpien ohjelmointikielten perusprimitiivit ovat kuitenkin niin samankaltaisia, että ohjelmointikielen valinta ei olennaisesti vaikuta suunnitelman toteutukseen (Raatikainen 2007). Huonon ohjelmakoodin kirjoittamista itse ohjelmointikieli ei pysty estämään, vaan esimerkiksi muuttujien nimeämiskäytäntöjen osalta ohjelmoijan on pysyttäydyttävä valitussa käytännössä systemaattisesti. Tämä on erityisen tärkeää monen kehittäjän käsitellessä samaa koodia.

Hyvin valitut käytännöt, myös koodin asetteluun ja rakenteeseen liittyvät, helpottavat sekä ohjelmoijan omaa työtä, että tekevät muille helpommaksi ymmärtää mitä koodi tekee ja mihin se on tarkoitettu. Lukijan tarpeetonta kognitiivista kuormittumista vähentävät myös koodin lomassa olevat kommentit. Oman artikkelinsa Seeley päättääkin toteamalla, että "ohjelmakoodia pitäisi olla yhtä helppo lukea kuin sanomalehteä". Näinhän se ihmisen kannalta onkin; tietokoneet eivät niin välitä, vaikka kaikki koodi olisi kirjoitettu yhdelle riville.

Lähitulevaisuudessa ei-tietojenkäsittelyn ammattilaiset saattanevat voida nauttia kehittynyistä ohjelmointiympäristöistä, jotka toimivat sillä tapaa älykkäästi, että ne analysoisivat jo koodia kirjoitettaessa algoritmien tehokkuutta, asettelun järkevyyttä ja muuttavat itsestään muuttujien nimiä kuvaavimmiksi. Kunhan joku ne ensin ohjelmoi.

Keskeinen opetus: Koodin selkeys vähentää sekä tekijän, että lukijan kognitiivista kuormitusta, mikä jättää enemmän "ajatteluresursseja" oleellisempien asioiden miettimiselle.

järjestelmien rakentaminen (engineering systems)

Tietoverkossa toimivien hajautettujen järjestelmien suunnitteleminen ja toteuttaminen ohjelmisto- ja laitteistokomponenteista.

Richard E. Fairley ja Mary Jane Willshire kuvailevat artikkelissaan Why the Vasa Sank: 10 Problems and Some Antidotes for Software Projects (2003) yhtäläisyyksiä 1600-luvulla rakennetun Vasa-laivan ja nykyaikaisten ohjelmistoprojektien toteuttamisen välillä. Johtamiskyky, viestintätaidot, dokumentointi ja aikataulutus lienevät nykyään tuttuja kaikille "vähänkään isompien" ohjelmistoprojektien vetäjille ainakin sanoina, mutta edelleenkin on täydet mahdollisuudet tyriä koko projekti samantapaisesti kuin Vasa-laivan tapauksessa.

Vasa-laivan tilaaja Kustaa II Adolf teki useita muutosvaatimuksia, jotka toteutettiin sillä tapaa puutteellisesti, että niiden vaikutusta suhteessa lopputuloksen onnistumisen edellytyksiin ei tarkasteltu riittävästi. Kuinka olisivatkaan voineet tarkastella, kun vastuunjako ja viestintä laivan rakentamisesta vastaavien kolmen henkilön välillä oli puutteellista, eikä minkäänlaista yhteistä dokumentaatiota ollut olemassa? Noihin aikoihin lieventäväksi seikaksi saattoi laskea sen, että jotkin asiat oli pakko oppia virheiden kautta, koska päätelmien tueksi ei ollut käytettävissä tietokonelaskelmia.

Aikataulupaineet ovat pahimpia ongelmia mitä voi ollakaan, varsinkin jos aikataulut ovat alun perin epärealistisia. Ne pilaavat hyvätkin ideat ja jättävät jälkeensä hutaisten tehtyjä toteutuksia, varsinkin jos välillä tapahtuu henkilövaihdoksia johtotasolla – ja viestintä on edelleen puutteellista. Laivan rakentaminen on sinänsä erilaista kuin tietokoneohjelmien, sillä palaaminen johonkin aiempaan tilanteeseen on paljon helpompaa – ohjelmistotuotannossa vesiputousmallin sijaan käytetään mieluummin iteratiivisia menetelmiä. Keskeiset tekniikat, joilla ohjelmistoprojektit pidetään hallinnassa, ovat alustavan dokumentaation luominen sekä vaatimusten ja suunnitelmien toistuva päivittäminen (Fairley ja Willshire 2003).

Keskeinen opetus: Dokumentoi, kommunikoi, hallitse muutokset, tee yhteistyötä..

mallintaminen ja validointi (modeling and validation)

Järjestelmien mallintaminen niiden käyttäytymisen ennustamiseksi erilaisissa tilanteissa ja olosuhteissa.

Laitteistojen ja käyttöjärjestelmän suoriutumiskyvyn matemaattinen simulointi erilaisissa kuvitelluissa tilanteissa mahdollistuu jonoverkkomallien avulla, sillä niiden perusteella tehdyt laskelmat vastaavat usein melko hyvin todellista tilannetta. Tämä mahdollistaa muutoksien tarpeen ennakoinnin ja on erityisen hyödyllinen uutta tuotetta kehitettäessä. Jonoverkot soveltuvat sellaisten tilanteiden kuvaamiseen, joissa synkronointi laitteistossa ja käyttöjärjestelmässä on yksinkertaista odottamista (Hirvisalo 2000). Näillä malleilla voidaan arvioida esimerkiksi a) keskimääräistä viipymisaikaa palvelupisteessä k, kun järjestelmässä on n asiakasta tai b) palvelupisteen k keskimääräistä jonopituutta, kun järjestelmässä on n asiakasta.

Charles E. Knadler Junior on artikkelissaan The Robustness of Separable Queueing Network Models (1991) analysoinut suorituskykyanalyysissa käytettyjen jonoverkkomallien robustisuutta. Eräässä hänen tutkimassaan järjestelmässä oli yhden prosessorin ja yhden väylän järjestelmä, mistä jonoverkkomallin antama vasteaika eroaa alle 15 % simulointituloksesta ja suoritusteho alle 11 %.

Hänen tutkiessaan monimutkaisempia järjestelmiä, joissa saattoi olla erillisiä tapahtumankäsittelyjärjestelmiä rajoittamassa samanaikaisesti käsiteltävien transaktioiden määrää (parantaa järjestelmän sisäistä suorituskykyä), ei jonoverkkomalli enää pitänytkään paikkaansa muistinkäyttörajoitusten alkaessa rajata asiakkaiden määrää – jonoverkkomalleissahan ei mallinneta komponenttien sisäistä toimintaa. Jonoverkkomalleihin sisältyy myös muita rajoitteita, kuten se, että asiakas siirtyy palvelupisteestä toiselle käyttäen vain yhtä resurssia kerrallaan. Järjestelmissä, joissa on kilpailua muistista, tämä oletus ei päde (Raatikainen 2007).

Knadler pitää silti jonoverkkomalleja tiettyihin rajoihin asti käyttökelpoisina, sillä ne antavat hyviä tuloksia myös tilanteissa, joissa mallitettu järjestelmä ei täytä matemaattisen ratkaisun tarvitsemia oletuksia.

Keskeinen opetus: Jonoverkkomallit ovat riittävän robusteja suorituskyvyn arvioimiseen, simulaatioon tukeutumisen sijasta, ainakin tietyissä rajoissa.

innovointi (innovation)

Johtajuuden (engl. leadership) käyttäminen pysyvien muutosten aikaansaamiseksi ryhmien ja yhteisöjen toimintatavoissa.

Peter J. Denning tekee kolumnissaan The Social Life of Innovation (2004) selkeän eron innovaation ja keksinnön välillä (Raatikainen 2007). Hän katsoo keksinnön olevan jonkin uuden, kuten ajatuksen, esineen, laitteen tai toimintatavan luomista, mutta innovaatioksi keksintö muuttuisi vasta sitten kun sitä sovelletaan sillä tapaa, että se aiheuttaa sosiaalisen muutoksen yhteisössä. Lisäksi hän toteaa, että on tärkeää erottaa innovaatio ja keksintö eri käsitteiksi, koska "innovoinnin käytännöt eivät ole keksimisen käytäntöjä". Innovaatio on aina jonkin uuden etsimistä, eikä täten sellaiseksi kelpaa prosessi, jota vain toistetaan sellaisenaan, mutta systemaattisten toimintapojen noudattaminen voi silti kuulua innovoivaan toimintaan.

Toisin kuin saatetaan ajatella, innovointia voidaan (Denningin mukaan) tehdä systemaattisesti ja sen perusperiaatteita voidaan opettaa; innovoinnin menestys on koulutuskysymys. Toisaalta, innovoinnin onnistumiseksi tarvitaan teknisissäkin innovaatioissa myös sosiaalisia taitoja. Innovoinnin kohteiden etsintään organisaatioympäristössä voi soveltaa Peter Druckerin kirjassa Innovation and Entrepreneurship julkaisemaa listaa poikkeavissa tilanteissa esiintyvistä mahdollisuuksista. Esimerkiksi sisäisinä haasteina, joita "voidaan kehittää ilman ulkoisen kilpailun tuottamaan painetta" hän listaa odottamattomat tapahtumat, epäsuhdat, prosessin tarpeet ja liike-elämän rakennemuutokset.

Denning itse on tunnistanut kahdeksan menestyksekkään innovoinnin olennaista elementtiä. Näitä ovat tietoisuus, keskittyminen ja pitkäjänteisyys, kuunteleminen ja sovittaminen, julistukset, laajakatseisuus, tarjoukset, verkottuminen ja instituutiot, sekä oppiminen. Muistiinpanojen tekemistä Denning suosittelee erityisesti, sillä "tämä kehittää taitoa tulla mahdollisuuksien havaitsijaksi ja huolenaiheiden kuuntelijaksi".

Keskeinen opetus: Innovoinnin käytännöt, joiden perusperiaatteita voidaan opettaa, eivät ole keksimisen käytäntöjä. Keksiminen voi osana innovaatiota, mutta keksintö itsessään ei ole innovaatio ellei se saa aikaan sosiaalista muutosta. Pyrkimys muutokseen voi olla ollut tarkoituksena alun perin, jolloin keksintö toimii muutoksen välineenä.

soveltaminen (applying)

Työskentely sovellusalueiden ammattilaisten kanssa näitä palvelevien tietojenkäsittelyjärjestelmien toteuttamiseksi.

Käyttäjän kuunteleminen on yksi periaatteista ihmiskeskeiselle suunnittelulle, minkä Donald Norman varoittelee poleemisessa kolumnissaan Human-Centered Considered Harmful (2005) tulleen liiankin dominoivaksi, koska "se hyväksytään automaattisesti suunnittelun lähtökohdaksi ajattelematta ja kritiikittömästi". Käyttäjän kuunteleminen ei sellaisenaan riitä, koska "käyttäjillä ei useinkaan ole loistavan suunnittelun tarvitsemaa näkemystä", Norman jatkaa. Siltikin, käyttäjän tarpeita palvelevien tietojenkäsittelyjärjestelmien luomiseksi yhteistyö on tarpeellista ja juuri tästä Peter Denning katsoo soveltamisessa olevan kyse, yhteistyöstä: "Työskennellään yhdessä tietojenkäsittelyn sovellusalueiden ammattilaisten kanssa näitä palvelevien tietojenkäsittelyjärjestelmien toteuttamiseksi."

Ahmed Seffah on artikkelissaan Learning the Ropes: Human-Centered Design Skills and Patterns for Software Engineer's Education (2003) identifioinut yhdeksäntoista taitoa, joita ohjelmistoammattilaiset tarvitsevat ihmiskeskeisessä suunnittelussa. Nämä taidot ryhmiteltiin kolmeen ryhmään: välttämättömät edellytykset, erityistaidot ja yleistaidot. Taito (skill) on sarja koordinoituja toimenpiteitä, jotka ovat yleensä tehokkaita tavoitteen saavuttamiseksi (Raatikainen 2007).

Välttämättömiin taitoihin hän laskee mukaan ohjelmistojen kehitysmenetelmien perusperiaatteiden, perusteiden ja standardien sekä käyttöliittymien kehitystyövälineiden ja oliopohjaisten suunnittelumenetelmien perusteiden hallitsemisen. Erityistaitoihin hän sisällyttää muun muassa a) visuaalisen ja tietosisällön suunnittelun, b) asiantuntijavetoisen varhaisten suunnittelukonseptien ilman käyttäjiä tapahtuvan katselmoinnin ja arvioinnin ja c) käyttäjien ominaisuuksien, heidän tehtäviensä ja työympäristön sekä käytettävyyden ja käyttöliittymän vaatimusten kokoaminen, analysointi ja määrittely.

Yleistaidot ovat tärkeitä, sillä niihin sisältyvät suurelle yleisölle tarkoitettujen dokumenttien kirjoittaminen ja esittely, sekä monialaisessa ryhmässä kommunikointi ja työskentely – näitä tarvitaan ohjelmiston koko elinkaaren ajan.

Keskeinen opetus: Jotta voitaisiin soveltaa, täytyy osata kommunikoida ja viestiä hyvin, päästääkseen mahdollisimman hyvin selville siitä, millainen sovellutus pitäisi muodostua.