Avainsana: Sytyke

Osaamista, liiketoimintaa ja vettä pilveen

pilvipalvelu
vettä, mielikuvia
taivas rajana

jalat maassa, pää
pilvessä, osaaminen
joustaa, laajenee

Systeemityöyhdistys Sytyken kolmastoista laivaseminaari ”Pilviteknologiat – ohutta yläpilveä, näkyvyys hyvä” 8.-10.9.2010 oli suositumpi kuin koskaan: noin sata toimittajien, asiakkaiden ja oppilaitosten edustajaa mahtui mukaan, vaikka kokoushuoneen ahtaat seinät jättivät monta kiinnostunutta rannalle.
Ilkka Pirttimaa johdatteli Spotifyn kautta pilvipalveluihin, esitteli seminaarityöryhmän ja sponsorit. Sytyken puheenjohtaja Juha Jääskinen jatkoi kertomalla Sytyken toiminnasta ja osaamisyhteisöistä. Yhteistyötä oppilaitosten ja yritysten kesken syvennetään, verkkosivusto uusitaan lähikuukausina, sosiaalista mediaa hyödynnetään ja Systeemityölehden paperimuotoa pohditaan.
IBM
Jouko Ruuskanen kertoi IBM:n pilvipalveluista, joissa voi nähdä kolme trendiä:

  • yritetään edelleen kehittää soa-arkkitehtuuria lähemmäs liiketoimintaa
  • asiakasyritys voi tapauskohtaisesti ulkoistaa joitain paloja liiketoiminnastaan joksikin ajaksi
  • rinnakkaisuutta lisätään.

Pilven ominaisuuksia ovat virtualisoitu alusta, jossa palvelu pyörii, automatisoitu palvelunhallinta ja standardoidut palvelut. Lisäksi tarvitaan palvelukatalogit, käyttäjärajapinnat, joiden kautta automatisoituja palveluja pyydetään. Tällöin maksetaan vain siitä, mitä käytetään, päästään nopeaan skaalautuvuuteen ja paikasta riippumattomuuteen. Pilvipalveluna menestyy riittävän yleinen palvelu, jota riittävän monet ihmiset haluavat käyttää.
Pilvipalveluiden perustermit ovat SaaS (Software as a Service), PaaS (Platform as a Service) ja IaaS (Infrastructure as a Service). Palveluja voidaan pyörittää paitsi yksityisessä tai yleisessä myös hybridi-ympäristössä, jota kohti kehitys näyttää menevän. Liiketoiminnan kannalta kriittinen data hoidetaan yksityisessä ympäristössä.
Asiakas saattaa olla kiinnostunut palvelun maantieteellisestä sijainnista. Suomen ja EU:n markkinoilla onkin palveluntarjoajia, jotka takaavat, että data sijaitsee maantieteellisesti turvallisessa paikassa.
Perinteisen palvelimen käyttöaste on noin 10-20 %, koska joudutaan varautumaan myös kuormituspiikkeihin. Pilvipalveluissa käyttöastetta voidaan minuuteissa nostaa 70-90 %:iin. Pilvipalveluissa voidaan myydä enemmän resursseja kuin on tarjottavissa, koska kaikki eivät ole yhtaikaa pilvessä.
Pilven toteuttamisen arkkitehtuurisia elementtejä ovat mm. katalogi ja standardoitujen palvelujen templatet sekä automatisoinnin, lisenssien ja palvelupyyntöjen hallinta. Kun käyttäjä kertoo, millaisen palvelun haluaa ja millaisin ominaisuuksin, palvelu haetaan resurssialtaasta, provisointimanageri pystyttää palvelun, jonka jälkeen viesti valmiista palvelusta lähtee käyttäjälle.
Google
Marko Saarinen kertoi Googlen yritysratkaisujen periaatteista: huolehditaan tietoturvasta, hyödynnetään globaalia palvelinverkostoa ja minimoidaan riippuvuus kolmannen osapuolen ohjelmistoista. Offline-palvelut ovat olleet mahdollisia jo vuoden ajan.
Google voi taata, että asiakkaan data on EU:n sisällä, mutta ei voi osoittaa palvelinta, jossa se sijaitsee, koska data on pirstaloituneena usealle palvelimelle moneen palvelinkeskukseen. Ratkaisulla varaudutaan pommi-iskuun johonkin palvelukeskukseen, jolloin data pitäisi nopeasti siirtää toiseen ilman, että asiakas huomaisi katkosta.
Googlella on SAS 70 Type II -sertifiointi prosesseihin, mikä edellyttää tarkkaa kuvausta siitä, kuka pääsee mihin käsiksi, mitä käyttäjätilitietoja saa luovuttaa viranomaisille, miten lisätyt koodit auditoidaan ja evaluoidaan, miten asiat raportoidaan ja miten niihin reagoidaan. Sertifikaatti on FISMA-yhteensopiva. Googlella on myös toimialakohtaisia pilviä, joissa voidaan ottaa huomioon toimialan juridiset vaatimukset datalle.
Googlen palvelut eivät tarvitse uusia asennuksia käyttäjien työasemiin, ainoastaan joitain selainlaajennuksia. Peruspalveluita ovat sähköposti ja toimisto-ohjelmistot, joita ei kannata pyörittää omilla palvelimilla. Melko vähän kustomoitavia peruspalveluita ovat sähköposti, pikaviestintä ja videoneuvottelu, videomateriaalin jakaminen organisaation sisällä turvallisesti, sekä google-sivustot, joiden päälle voi rakentaa omia sivustoja. Lisäksi tarjolla on joukko tietoturvaan liittyviä palveluita, joita voi hyödyntää missä tahansa sähköpostiohjelmistossa.
Esimerkiksi Priority Inboxissa 78 algoritmia määrittelee, mitkä ovat meille tärkeitä sähköposteja ja vähentää viestintävälineiden hallintaan kuluvaa aikaamme. Sähköpostilaatikko on määritelty riittävän isoksi, jotta aikaa ei mene viestien jatkuvaan arkistointiin. Sähköpostit voidaan kontekstin mukaan pinota yhden säikeen alle niin, että viestien sisällöt näkee yhdellä silmäyksellä. Kansiokäsitteestä on luovuttu ja korvattu se viesteihin liitettävillä tageilla; yhdellä viestillä voi olla useita tageja eli se periaatteessa voisi olla useassa ”kansiossa”.
Googlen pilvipalvelut sopeutuvat exchange-sharepoint-maailmaan, ja ovat yhteensopivia minkä tahansa Open LDAP -hakemiston kanssa. Googlen palvelut hyödyntävät yksisuuntaisella yhteydellä asiakkaan organisaatiohakemistossa olevia tietoja. Palveluihin tulee jatkuvasti uusia ominaisuuksia, mutta asiakas voi valita, milloin ottaa uudet ominaisuudet käyttöön tai missä rooleissa olevat henkilöt haluavat testata niitä ensin.
Vuonna 2007 Googlella oli vain kolme palvelua; nykyisin tarjonnassa on kymmeniä palveluita, jotka toimivat myös mobiilikäyttöjärjestelmissä.
Salesforce ja Fluido, asiakascase YIT
Kai Mäkelä kertoi Fluidon edustamasta Salesforce-palvelusta ja Tuuli Jahnsson kertoi palvelusta YIT:n näkökulmasta. Fluidon viiden hengen yrityksen ainoa it-infra on reititin, kaikki muu on pilvessä. Salesforce on sertifikoitu monikäyttäjäympäristö, jonka käyttäjämäärä lisääntyy noin 4000:lla yrityksellä vuosittain.
Yritys voi räätälöidä käyttöliittymänsä Salesforce-palveluun, saada sieltä osan palveluista ja liittää niihin omia sovelluksiaan. Liiketoimintalogiikkaa on helppo määritellä klikkaamalla tai koodaamalla.
YIT:llä kaikki prosessikuvaukset olivat jo olemassa, kun Salesforce-projekti alkoi. Käyttäjän näkökulmasta kyse on valistuneesta taulukkolaskennasta. YIT:llä tarvittiin ohjelmisto, jota voidaan kustomoida liiketoiminnan tarpeiden mukaisesti. Muutaman ohjelmiston testaamisen jälkeen Salesforce-valinta oli selvä. Tuuli Jahnson kertoi tehneensä sovelluksen kaikki  kentät omin pienin käsin, mutta ei kuitenkaan ruvennut koodaamaan; hän ei halunnut käyttää aikaansa sellaiseen, joka ei ollut hänen ydinosaamistaan.
Salesforcen käyttöönoton yhteydessä alettiin suoristaa prosesseja, poistettiin sivurönsyjä ja otettiin käyttöön Salesforceen valmiiksi miettitty myyntiprosessi. Salesforce-käyttäjät Wärtsilä, Kone ja YIT pitävät säännöllisesti yhteyttä ja jakavat keskenään parhaita käytäntöjään.
Salesforce tarkistaa, ettei järjestelmässä ole samaa tietoa useaan kertaan. Jos järjestelmän automaattiset huomautukset eivät johda datan korjaamiseen, YIT:n tiimiadministraattorit käyvät huomauttamassa korjaamisesta datasta vastuussa oleville henkilöille.
Parhaillaan YIT:ssä on meneillään Salesforcen integrointi ulkoisiin verkkopalveluihin, toimitilalaskuri, reklamaatioprosessi sekä auditointi.
Keskustelussa todettiin, että pilvipalveluiden integrointi toiminnanohjausjärjestelmiin lienee pilvipalveluiden akilleenkantapää. Voidaanko pilvipalveluiden varmistuksiin luottaa? Koneella data varmistetaan erikseen tiedostopohjaisesti pari kertaa päivässä. Myös YIT ottaa omat varmistuksensa datasta.
Salesforcen transaktioiden lukumäärää voi seurata osoitteessa http://trust.salesforce.com/.
Jyväskylän yliopisto
Lauri Frank Jyväskylän yliopiston ohjelmistoteollisuuden tutkimusryhmästä (SIRT, software industry research team) kertoi Cloud Software Program -tutkimusprojektista, joka vuosina 2010-13 keskittyy pilviteknologioihin, ketterään yritykseen (lean, agile), liiketoimintaan, käyttökokemukseen, tietoturvaan ja energiatehokkuuteen.
Pilvi tarkoittaa tietokonekeskusten laitteita, ohjelmia ja verkkoja. Pilvi voi olla julkinen, yksityinen ja hybridipilvi, joista viimeksi mainittu on selvästi nousussa. SaaS on vuoden 2009 Tietotekniikan termitalkoissa suomennettu ”verkkosovelluspalveluksi”. Termi ei erottele pilvipalvelua räätälöidystä tai ASP-palvelusta. ASPissa joka yrityksellä on oma ohjelmistoversio, tosin monet SaaS-palvelutkin voivat olla räätälöityjä niin, että kaikki eivät käytä samaa palvelua. SaaSissa pieni yritys voi saada kaiken kapasiteetin käyttöönsä, jos muut eivät ole sitä käyttämässä.
Verkkosovelluspalvelun, SaaSin, ominaisuuksia ovat:

  • palveluperusteisuus
  • skaalautuva ja elastinen kapasiteetti
  • jaettu (multi-tenant)
  • käytön mittaus (laskutus)
  • internet-teknologiat (selain tms.)

Pilvipalvelussa asiakkaan ei tarvitse huolehtia päivityksestä, ylläpidosta eikä tietoturvasta. Palvelusta voidaan maksaa erissä tai käytön mukaan. Yrityksen infrastruktuuri ei välttämättä kestä sitä, että kaikki tieto pitäisi hakea netin yli. Läpinäkyvyys ohjelmistoon katoaa. Pilvipalveluiden ominaisuudet ovat yleensä vaatimattomampia kuin räätälöityjen palvelujen.
Uudelle yritykselle pilvipalvelut tarjoavat uudenlaisia mahdollisuuksia, kun yrityksen ei tarvitse hankkia omaa it-henkilöstöä. Pilvipalvelun etuja ovat kustannukset, nopea käyttöönotto ja resurssien optimointi. Haittoja taas ovat palvelutason säilyminen, erityisesti tiedon saatavuus, tietoturva ja tiedon omistajuus sekä integrointi taustajärjestelmiin.
Miten ohjelmistoyritys muuttuu? Yhteys infrastruktuurin toimittajiin voi katketa, mutta palvelun ja prosessin pitää toimia jatkuvasti. Ennusteen mukaan pilvimarkkinat kaksinkertaistuvat vuosina 2008-2012 ja infrastruktuuripalvelut kasvavat 40 %. Pilvipalvelu kohdistuu pitkään häntään; kun palvelun käyttö on runsasta, sen hinta laskee ja samalla käyttäjämäärä kasvaa.
Keskustelussa kysyttiin, voisiko Suomesta tulla suurvalta pilvipalveluiden tuottajana? Meillähän on kylmä ilma, tuhansia järviä, tyhjiä tiloja, vakiintuneet poliittiset olot ja sekä toimivat suhteet Venäjään. Toisaalta tarvitaan investointeja ja hyvät yhteydet muualle; Ruotsin kautta kulkevien yhteyksien sijaan napojen yli Kanadaan.
Reaktor – pilvestä toiseen hyppääminen
Tuomas Kärkkäinen Reaktorilta kiteytti jo aiemmin esitetyn: pilvipalveluista saat skaalautuvuutta, mutta luovut sovelluksen hallinnasta.
Palveluntarjoajaa on joskus pakko vaihtaa: palveluntarjoaja voi mennä konkurssiin, palvelu voi loppua tai palveluntarjoajan kovalevy, jolla asiakkaan tiedot sijaitsevat, saatetaan takavarikoida.
NASAn Nebula-pilvi on sovelluspaketti, jolla kuka tahansa voisi luoda oman pilven. Mårten Mickosin Eucalyptuksella on yksityisen ja julkisen pilven rakentamiseen tuotteet, jotka ovat Api-yhteensopivia Amazonin EC2:n kanssa. Vaikka Eucalyptus on yhteensopiva EC2:n kanssa, sen avulla ei voida luoda EC2:n tasoista palvelua. Nasan ehdottamia parannuksia Eucalyptuksen avoimen lähdekoodin osaan ei hyväksytty, koska ne olivat päällekkäisiä Eucalyptuksen kaupallisen tuotteen premium-ominaisuuksien kanssa.
Vastuullinen pilven käyttö tarkoittaa, että asiakas ottaa vastuun datansa omistuksesta ja hallinnasta. Pilvi on aluksi ilmaista, mutta kustannukset kasvavat vähitellen. Varmuuskopioinnin tasosta voidaan sopia esim. Googlen pilvipalvelussa. Muokataanko liiketoimintaprosesseja sovellusten mukaan? YIT:llä niitä muokattiin jonkin verran, lähinnä objektien relaatioita. Perusdata toki oli samaa, josta yritys tarvitsi tiedot.
Tuomas Kärkkäisen diapakan lopussa oli asiallisesti kiitokset Flickristä otetuista kuvista osoitteineen.
Microsoft – ensimmäinen pilvisovellus kolmessa vartissa
Pasi Mäkinen Microsoftilta kertoi Windows Azuresta, PaaSista, sovellusalustapalvelusta. Pilvipalvelun optimaaliset työkuormat voidaan määritellä sen mukaan, onko kyseessä jaksottainen palvelu (esim. vakuutuspalvelut), nopean kasvun palvelu (esim. alkava yritys) tai palvelu, jossa on ennustettava piikki tai jossa voi olla ei-ennustettavia piikkejä.
Azuressa on skeematon tietokanta, jonka joka rivillä voi olla omannäköinen skeemansa. Skeemojen oikeanlainen käyttö on sovelluksen vastuulla. Vastaava ratkaisu löytyy myös Googlelta ja Amazonilta. Hinnoitteluun ei vaikuta pelkästään sanomamäärä vaan yhtaikaa käynnissä olevien sovellusyhteyksien määrä. Asiakkaille on tärkeää, että he voivat valita, missä data-keskuksessa heidän sovellustaan ajetaan, esim. EU-alueella.
Azuressa on konttipohjainen rakenne, jonka lisäksi tarvitaan vesijohtovettä, ulkoilmaa ja tietoliikennekapasiteettia. Virityksessä haasteellisia ovat olleet kylmät alueet, koska jäähdytysvesi ei saa päästä jäätymään.
Azure-alustalle voidaan siirtää helposti .net, liiketoimintalogiikka ja SQL-server. CGI-pohjaiset sovelluskehikot vaativat enemmän työtä. Uuden Facebookin kehittäminen edellyttäisi suunnittelua ja toteutusta. Tällä hetkellä ei voida siirtää asennuspaketin vaativia tai admin-oikeudet tarvitsevia sovellusympäristöjä kuten SharePoint.
Qentinel – tykistötulta pilvilinnasta
Teemu Vesala Qentinelilta kertoi, että pilvipalveluiden riskejä ovat käytettävyys, tietoturva, suorituskyky ja siirrettävyys. Hän oli testannut kaksi palvelua LoadStormin (SaaS) ja Amazon EC2:n (IaaS).
Toiminnalliset riskit kasvavat, kun järjestelmiä on eri tasoissa. Tietoturvaa on vaikea testata ilman toimittajan kirjallista lupaa, koska järjestelmässä voi olla muidenkin dataa. Käsin prosesseja säätämällä Teemu Vesala sai yhtäkkiä esiin jonkun toisen testiraportit. Virhe korjattiin nopeasti, mutta luottamus järjestelmään himmeni. Onneksi oma asias tiesi, että palvelu oli pilottikäytössä; riskit piti tietää etukäteen ja viestiä asiakkaille. Jos data menee bugin vuoksi jollekulle toiselle, onko se liiketoiminnan kannalta fataalia?
Pilvipalveluissa menetetään kontrolli moneen asiaan, joita mittaustilanteissa tarvitaan. Todelliset kustannukset saattavat jäädä jonnekin piiloon ja olla jotain ihan muuta kuin on kuviteltu. Lisäksi saatetaan tarvita lakimiespalveluita.
DataCenter Finland
Mika Leno DataCenter Finlandilta räätälöi esityksensä yleisölleen. Suomessa on poikkeuksellisen hyvät olosuhteet konesalitoiminnalle: sähkö on edullista, ilmaista kylmää saadaan merestä ja ilmasta, meillä on luotettava infrastruktuuri, korkea koulutusaste sekä yritysystävällinen lainsäädäntö ja valtiollinen toiminta. Merivesi Itämeren alueella on riittävän kylmää ympäri vuoden, kun mennään riittävän syvälle, kun taas järvet eivät ole jatkuvasti riittävän kylmiä, ei edes Laatokka. Järvistä voisi saada sähköä patoamalla, mutta se taas häiritsisi kalojen normaalia kutemista.
Tukholma – Helsinki -taso olisi konesalille optimi, Oulu – Rovaniemi -tasolla jäähdytysvesi saattaisi jäätyä. Menestyvälle konesalitoiminnalle Suomessa tarvitaan kuitenkin nykyistä paremmat tietoliikenneyhteydet ja investointivoimaa.
Tulevaisuuden pilvipalvelut ovat hybridejä, palvelut ovat osin asiakkaalla itsellään, osin pilvessä. Toistaiseksi kaikki vastaan tulevat järjestelmät on pystytty virtualisoimaan. Palvelutuotanto on syytä auditoida ja varmistusten varmistuksista on huolehdittava.
Mika Leno neuvoi ensin kokeilemaan pilvipalveluita, sitten modernisoimaan organisaation teknologiat, prosessit ja ihmisten osaamisen, tuotteistamaan palvelut ja kehittämään strategiaa. Vuoden sisällä organisaatiolle pitäisi kehittää kokonaisvaltainen cloud computing -strategia ja rakentaa dynaaminen cloud computing -hankintaa osaava organisaatio.
Pilvipaneeli
Mitro Kivisen juontama esiintyjäpaneeli totesi, että koulutuksessa olisi hyvä edelleen lähteä tunnetuista arkkitehtuureista ja lisätään niihin pilviteknologiaa ja liiketoimintaa. Pilvet mahdollistavat opiskelijoille ilmaiset välineet, opiskelu- ja tutkimusympäristön. Rikkinäisiä järjestelmiä voisi näyttää opiskelijoille ja kertoa, miten ne olisi saatu toimimaan ja mitä ostajan olisi pitänyt tehdä.
Pilviturvallinen ohjelmointi ei synny liian tiukoilla aikatauluilla. Huono ohjelmisto ei muutu pilvessä paremmaksi. Tietoturva pitää integroida koko sovelluskehitysprosessiin jo määrityksistä lähtien. Hakkeri voidaan mallintaa yhdeksi aktoriksi käyttötapauskaavioon, jolloin voidaan kuvata sisäiset ja ulkoiset hyökkäykset ja keinot niiden torjuntaan. Ohjelmoijien pitää ymmärtää, että ohjelmiston haavoittuvuus testataan ja auditoidaan. Ulkoistuksessa tietoturvaa on vaikea kyseenalaistaa. Tiedemaailmassa taas paras tapa suojata jotain on panna se julkiseksi; silloin sitä ei kukaan huomaa.
Pilviteknologian käyttö kannattaa aloittaa pienessä tutussa piirissä ja laajentaa vähitellen. Koko ratkaisun arkkitehtuuria ei tarvitse muuttaa; jos oma konesali puuttuu, sovelluksen voi viedä pilven reunalle. Erilaisten pilviteknologioiden tuntemus ja kyky yhdistellä niitä nousevat tärkeiksi. Entä jos kaikki käyttävät samoja ohjelmistoja ja muokkaavat prosessinsa niiden mukaisiksi, niin mistä yritykset saavat kilpailuetua?
Pilvestä saa skaalautuvan verkkopalvelun ja testiympäristön silloin, kun sitä tarvitsee, mutta palveluun ei tarvitse sitoutua. Pilviteknologian riskit ja rajoitukset olisi hyvä tuntea ja ymmärtää, ettei kaikkea kannata siirtää pilveen. Pilvi ei sovi luottamuksellisen datan käsittelyyn, tosin kymmenen vuoden kuluttua käsityksemme luottamuksellisesta ja arkaluontoisesta datasta saattaa olla erilainen kuin tänään.

Prosessimalli ja ihminen

globaalin haaste
innovatiivisuudelle
ketterä tiimi?

prosessimalli
motivoi, mahdollistaa
ihmisen tarpeet
Laskeva aurinko sinkosi punertavat liekkinsä SYSOPENDIGIAn tornin yllä kaartuvalle taivaalle Sytyken MallinnusOSYn pienseminaarin ”Toiminnan tehostaminen prosessimallein” alussa.
Ohjelmistokehitysprosessin mallintaminen
Henrik Terävä SYSOPENDIGIAsta kertoi ohjelmistokehitysprosessin mallintamisesta ja käytöstä diplomityönsä ”Software processing modelling with EPF” pohjalta. Ohjelmistokehityksen yleisiä haasteita ovat tiedonjako tiimeille, prosessien integrointi, koulutusmateriaalien ajantasaisuus ja tehokkaat prosessit. Turhan usein prosessimalli eroaa käytännön mallista, vaikka ohjelmistokehityksen pitäisi perustua ihmisen toimintaan. Prosessin pitäisi motivoida kehittäjän tarpeiden mukaiseen oikeaan toimintaan – kuten häkistä toiseen siirrettävää oravaa motivoi toisessa häkissä avoimen oven takana odottava pähkinä.
Suomalainen, avoimen lähdekoodin tuote OpenMethod säästää aikaa ja mahdollistaa tietämyksen hallinnan. Se tarjoaa standardit rajapinnat räätälöintiin ja uudelleenkäyttöön. Haasteena ovat eri kielialueet ja muutosvastarinta.
Ensimmäisessä demossa Sytyken pienseminaarin työvaiheet ja kestot mallinnettiin ohjelmistokehityksen työkaluilla, toisessa tutkittiin kirjaston staattista ja dynaamista sisältöä, vaatimusmäärittelyn tehtäviä sekä raportteja ja ohjeita, kolmannessa projektista laadittiin julkaisu asiakkaalle.
Yleisöstä kysyttiin, käytetäänkö oikeassa projektissa tällaista tuotetta: menetelmiä on muutenkin niin paljon, ettei niihin tutustumiselta ehdi tehdä oikeita töitä. Onko taustalla kuvitelma ohjelmistokehitystyön jakamisesta yksinkertaisiin paloihin? Eiväthän palat loksahda kohdalleen ilman syväosaamista.
Rami Talme RP5 Softwaresta kertoi EPF Composerin ja Rational Method Composerin käyttökokemuksistaan. Miten asiakas saataisiin osallistumaan sovelluskehitykseen? Kuvaaminen on raakaa työtä ja sisällön tuottaminen vaikeaa; tätä tosiasiaa työkalu ei muuta. EPF:n sateenvarjosta voidaan poimia tarvittava, kerätä sisältöjä eri paikoista ja menetelmistä kuten Scrumista, XP:stä ja RUPista. Menetelmät periytyvät, omia menetelmäsisältöjä ja steppejä voidaan lisätä tai poistaa.
Yleinen väärinkäsitys lienee, ettei Scrumissa tarvitse dokumentoida eikä välittää arkkitehtuureista, koska ne kasvavat prosessin mukana. Hyvä tiimi osannee toimia ilman kuvausta, mutta uudet jäsenet tarvitsevat jotain kättä pidempää. Aiemmin menetelmäkehityksessä laadittiin sisältöjä kuvaamatta niiden järjestystä tai käyttötapauksia – mikä selittänee prosessikuvausten nykytilaa.
Miksi projektia säädellään? Eikö valmis ohje sovellu omaan tilanteeseen? Malliksi voidaan ottaa osaavan tiimin prosessi ja katsoa, sopiiko se omaan tilanteeseen vai pitäisikö iteratiivisesti edeten tuunata siitä omiin tarpeisiin soveltuva.
Ohjelmistoprosessit muuttuvassa maailmassa
Antero Järvi Turun yliopistosta puhui ohjelmistoprosesseista muuttuvassa maailmassa. Muutos syntyy liiketoiminnasta, ei menetelmistä tai teknologiasta. Globaalien markkinoiden hajautetuissa hankkeissa ja lyhyissä tuotesykleissä innovaatioverkostot ja asiakas nousevat keskeisiksi.
Ketterä kehitys yhdistettyjen kompetenssien tiimeineen vastaa muuttuvan maailman tehokkuus- ja reaktiivisuusvaatimuksiin. Ohjelmistokehityksen perusyksikkö voisikin olla ketterä tiimi, jossa jokainen vastaa tekemisistään.
Miten itsenäiset ja ketterät kehitystiimit toimivat tuotehankkeessa tarkoituksenmukaisesti? Kun hallitsemme toisaalta laajat, muokattavat prosessikehykset, toisaalta ketterien menetelmien skaalauksen, tarjoaisivatko monitiimiset sovellukset nykykehitykseen optimaalisen ratkaisun?
Laajoissa prosessikehyksissä kehittämisstrategia on mietitty, riskinhallinta korostunut ja vaiheet päättyvät tarkistuspisteisiin. Työkäytänteiden tarkka kuvaaminen aiheuttaa turhia riippuvuuksia. Ketterässä kehityksessä asiakas on kiinnostunut tuotteesta ja tiimi on tuotteen kehityskone. Ketteryyteen kuuluu epävarmuus: ymmärrys siitä, mitä ollaan tekemässä, kasvaa iteratiivisessa prosessissa.
Miten tiimit suojataan prosessirajapinnalla? Yhdestä käyttötapauksesta voi tulla vaatimuksia kahteen tuotekomponenttiin, joita eri tiimit tekevät yhtaikaisesti. Tällöin tarvitaan scrum-mastereiden yhteydenpitoa ja kustomointia sprinttien aikana. Voidaanko hanketta skaalata entistä isommaksi lisäämällä scrum-tiimejä, joiden välisiä riippuvuuksia scrum-masterit selvittävät scrum-tapaamisissaan?
Kehitysprojektit kytkeytyvät liiketoimintaprosesseihin, toiminnan kehittämiseen ja organisaation oppimiseen. Tuoteprojektit tarvitsevat valmiita ratkaisuja; aikaa on turha kuluttaa organisoitumistapojen miettimiseen. Menetelmästä riippumatta tarvitaan tiimijakoa, työnkulkuja, koordinointia ja vaatimusmääritystä. Tilannekuva auttaa mukauttamaan prosesseja projektin aikana ja viestimään – ja antaa tiimeille tilaa keskittyä kehitystyöhön.
Pienseminaarin esitysmateriaali löytyy Sytyken MallinnusOsyn sivulta.

Yhteistyöllä laatua projekteihin

miksi-kysyjän
tehokkuus tuo laatua
kuviouintiin

kylmä jäävuori
harmaan veden sylissä
hukkuu miljooniin

Dipolissa 13.-14.11.07 pidettyjen Projektipäivien järjestelyissä oli esimerkillisesti panostettu verkostoitumiseen: esitysten välillä oli vartin tauko, kahvia, teetä ja vettä sai jatkuvasti, puolentoista tunnin lounas nautittiin coctail-pöydissä ja ensimmäisen päivän iltana oli parin tunnin verkostoitumistilaisuus ennen projekti-iltamia. Sääli, tauti söi ääneni muutamaa päivää aikaisemmin ja verkostoituminen ja virikkeet jäivät räpistelyksi. Yskän yltyessä jouduin jättämään illanvietot ja valtaosan luennoista. Erityisesti harmitti, etten päässyt Sytyken järjestämään ketterien menetelmien paneelikeskusteluun, johon olin etukäteen lähettänyt kysymyksenkin. Toivottavasti saan jostain tietää, millaista keskustelua kysymykseni herätti.

Ehdin kuitenkin poimia muutaman idun tiistaiaamupäivän esityksistä.
Anders Ericsson Ruotsin TietoEnatorista kehotti meitä kysymään ”Miksi?” vähintään kerran päivässä – kohteliaasti esimieheltä. Projekteissa tiedetään yleensä, kuka tekee ja koska, mutta harvemmin tiedetään, miksi. Pienet lapset kysyvät jatkuvasti ”miksi?”. Aikuisena työelämässä ja projekteissa on myös hyvä kysyä ”miksi?”.
Projektin ohjaus varmistaa, että joukko kulkee kohti liiketoiminnan tavoitteita – kuten kalat akvaariossa. Jos yksi eksyy kuviosta, hänet on välittömästi korvattava toisella.
Työvälineet eivät ratkaise ongelmia, projektia voi hallita vaikka tavallisella taulukkolaskentaohjelmistolla, kunhan käyttää sitä järkevästi. Tiedämmehän sanonnan: vale, emävale ja tilasto. Viimeksi mainittuja ei pidä tuijottaa liikaa.
Mitä on tehokkuus? Tehdään nopeammin? Tehdään asioita rinnan? Vai tehdään laadukkaammin?
Marjukka Markkanen KPMG:stä luovi harmailla vesillä pohtiessaan, mitä yrityksen johto odottaa projekteilta. Yritysten toimintaympäristöt muuttuvat rajusti ja rahaa palaa epäonnistuneisiin muutoksiin. Strategioissa kerrotaan tavoite, ei välttämättä edellytyksiä tavoitteeseen pääsemiseksi. Toki tahtotilan kuvaaminen on tärkeää, mutta toteutustakin tarvitaan: prioriteetit, vastuut, resurssit ja mitattavat hyödyt.
Osa toiminnasta, jäävuoren huippu, projektoidaan ja seurataan – samalla kun kaikkeen muuhun ”mukavaan puuhasteluun” voi huomaamatta viuhua miljoonia.
Menestyvä yritys valitsee tuottavat kohteet ja pitää sitoumuksensa projektin aikana. Toteuttajien ja johdon näkökulmat pitäisi yhdistää, koska toteuttajat tietävät realiteetit; mikä on mahdollista ja mikä ei. Toteuttajat miettivät, miten asia tehdään ja johto miettii, mitä siitä saa. Toteuttajat toivovat standardeja ja menetelmiä, johto joustavuutta ja nopeaa reagointia. Tarvitaan vuorovaikutusta: miten oma näkökulma ilmaistaan niin, että eri tahojen yhteisymmärrys voidaan saavuttaa.
Muutosten projektointi ei ole oikotie onneen. Johdon seuranta saattaa loppua investointipäätökseen. Johdon tuki ei riitä, tarvitaan johdon tahto.
Sam Ehnholm Epicor Software Finland – EMEA:sta esitteli MS SharePointin avulla välineiden integroinnin merkitystä. SharePoint sinällään ei ole arvokas, ellei siihen voida integroida aiemmin tuotettuja sisältöjä muista järjestelmistä. Demo toimi hyvin: projektin seurantaan saatiin vaivatta erilaisia tietoja, kunhan ne oli viety järjestelmiin. Integrointiperustuu malleihin ja olemassa oleviin työkaluihin. Kyse on siitä, miten työkaluja käytetään ja miten olemassa oleva tieto saadaan esiin.
Muistin Anders Ericssonin varoituksen tilastoihin tuijottamisesta. Toisaalta, vaivatta saatavat halutun muotoiset ja ajantasaiset tilastot antavat päätöksenteolle nopeasti suuntaa – toisin, kuin ennalta määrätyn perusmuodon mukaiset tilastot, jotka pitää etukäteen tilata (tällaiseen törmäsin Virtuaaliammattikorkeakoulun Opintopalveluissa).
Kari Vanhalakka Andrizilta painotti projektien ensimmäistä sataa ”kylmää” päivää: mitä jokainen projektin jäsen tuona aikana ajattelee. Näinä päivinä opittu pyritään siirtämään seuraaviin projekteihin, vaikka jokainen projekti olisikin yksilöllinen. Mitä isompi projekti, sitä tärkeämpiä ovat nuo ensimmäiset sata päivää.
Mieleeni palasivat Anders Ericsson aiemmat ohjeet projektin seurannasta ja tavoitteiden mukaisen kuvion varmistamisesta.
Dipolissa oli runsaasti näytteilleasettajia, mutta mukaani tarttui vain Wakarun faaraon esite Egyptin haaste -projektisimulaatiopelistä. Pelin idea pohjautuu tekemällä oppimiseen ja oivaltamisen; sitä voisi olla hauska kokeilla käytännössä niin projekteissa kuin projektityön koulutuksessa.

Pyrähtelevä ohjelmistokehitys

vaatimus jäätyy
putoukseen, pyrähtää
sulaen scrumiin

rup ruoppaa pienen
palan valmiiksi, muuttaa
lennossa suuntaa
Nykyaikaiset ohjelmistokehityksen mallit olivat aiheena Sytyken MallinnusOsyn jäsentilaisuudessa 17.9.07 SYSOPENDIGIAlla.
Paula Salmi Osuuspankkikeskuksesta (OPK), nykyisestä OP-Pohjolasta esitteli heidän kehittämänsä V5-mallin, Allan Halme Accenturalta pureutui RUPin teoriaan ja Lasse Koskela Reaktor Innovationsista pohdiskeli Scrumin taustaa ja todellisuutta tänään.
Yleisössä istuneet kokeneet systeemityöläiset toisaalta kritisoivat Allan Halmen turhan teoreettista esitystä RUPista, toisaalta täydensivät Lasse Koskelan esitystä omilla kokemuksillaan scrumista.
V5-malli kehittää
OP-Pohjolan organisaatiouudistus pyrki eroon eri palvelualueilla toimineiden järjestelmäkehittäjien erillisten ratkaisujen koordinointiongelmista. Ict-palvelut ostetaan keskitetystä ict-organisaatiosta, vaikka liiketoiminnan tavoitteet määritetään edelleen palvelualueilla ja liiketoiminnan edustajat päättävät hankkeiden priorisoinnista ja etenemisestä.
Kehitysprosessin vaiheet noudattelevat perinteistä systeemityömallia idean kiteyttämisestä pilotointiin, jalkauttamiseen ja hyötyjen mittaukseen. Malli on ryhdistänyt ja selkeyttänyt prosessia ja vastuunjakoa, mutta haasteet eivät ole kadonneet: tehtävät ja dokumentit ovat vielä osin päällekkäisiä ja riittävän informaation takaaminen kapulanvaihtotilanteissa eri yksiköissä toimivien määrittelijöiden ja testaajien välillä vaatii ponnisteluja.
Paula Salmi kevensi esitystään kuvalla näppikseen nojaavasta pääkallosta, jota näytöltä tuijotti teksti ”Waiting for reply”. Hän kertoi ketterän kehittämisen käynnistyneen OP-Pohjolassa sertifioitujen projektipäälliköiden ja OWASP-tietoturvaan erikoistuneiden testaajien myötä.
RUP palastelee
Allan Halme vertasi RUPia vesiputousmalliin. RUPissa vaatimuksia ei jäädytetä, mutta koodaus kannattaa aloittaa vasta kun neljä viidesosaa järjestelmästä on määritelty. Kiinteähintainen tilaus edellyttää mahdollisimman hyvää vaatimusmääritystä.
Systeemityötä voi verrata Firenzen katedraalin kupolin rakentamiseen 1400-luvulla: järjestelmästä saa todellisen kuvan vasta, kun toteutus on jonkin matkaa edennyt ja nähdään, pysyykö toteutus sovituissa raameissa ja onko järjestelmän suorituskyky riittävä.
Kun tilaajalta tulee uusia tarpeita kesken projektin, RUPissa osa järjestelmästä on valmiina ja suuntaa voidaan muuttaa kohti uusia tavoitteita. Vesiputousmallissa taas kaikki olisi levällään eikä suunnan muuttamiseen löytyisi kiintopistettä.
Yleisö oli aktiivinen: Vastaava palasteleva suunnittelu-toteutus-idea kehitettiin jo 1990-luvun alussa Sytyken STST-työryhmässä, nykyisen Rela-yhteisön edeltäjässä. OP-Pohjolan V-malli ei tietenkään noudata vaihejakoa vesiputousmaisesti, kuten Allan Halme tulkitsi, vaan sisältää luonnollista iteraatiota, kun käyttäjät, ongelma, teknologia tai markkinat saattavat muuttua projektin aikana. Esitetyt RUPin työmääriä kuvaavat käyrät eivät toimi versioivassa tuotekehityksessä, jossa vaatimusmäärityksen työmäärä ei vähene työn edetessä.
Scrum pyrähtää
Lasse Koskela esitti Scrumin tausta-ideat kuvaamalla Toytan toisen maailmansodan jälkeisestä innovoivaa tuotekehityksestä, jossa pienin askelin tehokkaasti tehtiin jotain konkreettista, mikä tuotti lyhimmän kehitysajan ideasta valmiiseen tuotteeseen. Tältä pohjalta kehitettiin Scrum 1990-luvun alussa.
Asiakkaan priorisoimat tärkeät kehittämistoimenpiteet kootaan Product Backlogiin, josta kahdesta neljään viikkoon kestävän pyrähdyksen työmäärä poimitaan Sprint Backlogiin. Pyrähdyksen jälkeen tuotos on valmis eikä vaadi hiomista.
Ict-ammattilaisten velvollisuus on selvittää asiakkaalle priorisointiin ja toteutusjärjestykseen vaikuttavat tekniset asiat. Yleisön joukosta todettiin, että Scrumissa käytetään jatkuvasti aikaa Backlogin kampaamiseen, ettei se happane.
Scrumia opitaan tekemällä, ei kurssilla. Prosessi on yksinkertainen, mutta vaikea soveltaa. Scrumin toimijoita ovat tuotteen omistaja, moniosaava ja itseohjautuvat tiimi, johon kuuluu 5-9 henkilöä sekä Scrum-master. Scrum-master on kuin voi leivän välissä, poistaa esteitä ja ylimääräisiä välikäsiä sekä huolehtii prosessin järkevästä soveltamisesta.
Asiakkaiden kanssa keskustellaan heidän ymmärtämällään kielellä. Siihen ei kuulu pariohjelmointi eikä Scrum-master.

Mikä on systeemityössä IN?

hanke purjehtii
vesiputouksesta
muutoskaaokseen

hiljainen tieto
siivittää muuttolinnun
laadunhallinnan

tutkija testaa
haarukalla perunaa
ilman speksejä

Systeemityöyhdistys Sytyken kymmenennessä laivaseminaarissa Viking Mariellalla 5.-7.9.2007 kysyttiin: ”Mikä mahtaa olla IN?”
Sytyken sytyttämiä sponsoreita oli niin paljon, ettei kaikille riittänyt puheenvuoroa paripäiväisessä seminaarissa. Niinpä puheenvuorotta jäänyt Samcom ilmoittautui jo ensi vuoden sponsoriksi.
Timo Kaisla Ixonos Projektinjohtopalveluista kertoi haasteista suurissa tietojärjestelmähankkeissa, sata kertaa tavallisia suuremmissa, tuhansia henkilötyövuosia ja yli kolme kalenterivuotta nielevissä migraatio eli konsolidointi- tai vaihtohankkeissa. Alustava suunnitelma ja lopullinen todellisuus poikkeavat toisistaan merkittävästi: kustannukset kasvavat nelinkertaisiksi ja aikataulu kolminkertaiseksi, hanke koskettaa koko organisaatiota ja suurta alihankkijajoukkoa.
Ainutkertaisen hankkeen skaalasokeutta ei riko konsulttikaan. Johto ja kokenut projektipäällikkö hallitsevat normaaliprojektit, ei koko henkilöstöä koskevaa muutosta. Organisaation pitäisi lääkitä itseään ulkopuolisten kokemuksilla suurista projekteista.
Puolet meneillään olevista projekteista pitäisi tappaa, jotta migraatiohankkeeseen saataisiin kaikkien divisioonien parhaat resurssit. Päällikkövetoinen vaatimusmääritys, vaikka siihen varattaisiin reilut puoli vuotta, tuottaa puutteellisia ja tasoltaan kirjavia tuloksia, jos päälliköt eivät ole systeemityön ammattilaisia. Systematisointi on saattanyt rämettyä organisaation pienissä projekteissa; suurissa sitä tarvitaan. Pienissä projekteissa kannuksensa ansainnut projektipäällikkö ei ehkä uskalla skaalata resurssi- ja aikatarvetta riittävän ylös – ja jos uskaltaisi, esimies ei sitä hyväksyisi.
PMBOK kuvaa, mitä pitäisi tehdä, ei sitä, miten se tehtäisiin.
Vaatimusten- ja muutostenhallinnassa työpajat toimivat, ne tuottavat paljon dokumentoimatonta, ns. hiljaista tietoa. Aikataulu annetaan yleensä ylhäältä, vaikka suurta hanketta pitäisi suunnitella alhaalta ylös. Linjaihmiset arvioivat työmäärät kirjavasti. Katselmointi vaatii pari kuukautta ja kymmenen henkilöä, ettei ”takaseinä jää puuttumaan”.
Laadunhallinnasta tarvitaan kuvaus, jossa käsitellään muutakin kuin testausta. Testaajiksi tarvitaan ulkopuolisia ammattitestaajia, he oppivat nopeasti prosessit kuin prosessit. Jos talon omat asiantuntijat pannaan kolmeksi kuukaudeksi ajamaan erilaisia testejä, kyse on heidän ammattitaitonsa väärinkäytöstä.
Miten henkilöstö saadaan mukaan? Aluksi voisi kutsua vaikka Esa Saarisen luennoimaan, muutoshan koskee kaikkea ja kaikkia. Projektipäälliköt ovat avainasemassa: jos homma on liian iso jollekulle heistä, hänet pitäisi vaihtaa toiseen mahdollisimman pian, muuten muutosvastarinta kasvaa.
Miten suuri tietojärjestelmäprojekti ostetaan? Vaatimusmääritys on niin vaativa, että kiinteä hinta johtaa yleensä jatkuvaan sopimuspapereiden läpikäyntiin juristien kanssa.
Ostavan ja tilaavan organisaation toiminta- ja kulttuurierot vaikuttavat projektiin. Jos organisaatiot ovat eri maissa, ongelmat yleensä lisääntyvät. Halvin tapa rakentaa siltoja saattaa joissain tapauksissa olla ilmainen viina. Projektissa työskentelevien ihmisten pitäisi kokea olevansa ”yhdessä veneessä” eikä vain asiakassuhteessa. Parhaimmillaan projektin lopussa ei enää voi erottaa, kuka on toimittajan ja kuka asiakkaan edustaja.
Nopeasti muuttuvassa maailmassa isoissa projekteissa voidaan käyttää ketteriä menetelmiä monin sprintein.
Claus Günther ja Sakari Lehtonen IDS Scheer Finlandilta selvittivät meille Open BPM:n merkitystä liiketoiminnalle. Claus Güntherin mukaan nykyinen muutosten aika edellyttää kokonaisratkaisuja, liiketoiminnan harmonisointia ja segmentointia. Miten se näkyy attribuuttitasolla? Mitä tehdään itse ja mitä ostetaan?
Kokonaisuuden hallinta tarkoittaa suhteiden hallintaa, asioiden välisten suhteiden ymmärtämistä. Onko tämän hallitseva toimitusjohtajasukupolvi vasta kasvamassa? Kolme vuotta sitten puhuttiin malliin perustuvasta arkkitehtuurista (Model Driven Architecture), nykyisin arkkitehtuurin pitäisi perustua liiketoimintaan (Business Driven Architecture).
Mikä on IN? Olisiko Business Driven SOA? Tulevaisuudessa yritysarkkitehtuuria ja SOA:a hallitaan yhdessä.
Sakari Lehtonen kysyi, miten järjestelmät palvelevat liiketoimintaa kokonaisuutena. Monessa organisaatiossa on kiinnitetty huomiota prosessien hallintaan, mutta laajempi kehikko, sovellukset, tiedot, laitteistot ja integrointi, on jäänyt hoitamatta. Olennaista olisi saada nämä kaikki samaan tietokantaan, jotta tiedetään, mitä sovellusta, tietoja ja laitteistoja tietty prosessi tarvitsee. Miten tällaista tietokantaa ylläpidetään? Tuskin PowerPointilla.
SOA:ssa on aina sama kerrosarkkitehtuuri: käyttöliittymät – integraatioalusta – ERPit. Portaalista tuleva käsky reitittyy integraatiokerroksen läpi keskuskoneelle, jossa kaikki tiedot ovat luontevissa moduuleissa. Muutaman vuoden kuluttua integrointikerroksen korvaa ohjaava kerros.
Entä tulevaisuus? Yrityksellä on yksi sovittu tapa kuvata ohjelmalogiikka, joka voidaan generoida eri alustoille. Prosessit mallinnetaan BPM:lla ja tekniikka UML:lla – ja nämä kuvaustavat pidetään erillään!
Joakim Sandström nSenselta vakuutti innostavassa puheessaan, että tietoturvan testaaminen on osa systeemityötä. Hän kertoi aloittaneensa uusmediahypen aikana ohjelmoijana, törmänneensä koodin tietoturvaongelmiin ja innostuneensa sovellustietoturvahaavoittuvuudesta, josta kukaan ei tuolloin ymmärtänyt mitään. Ohjelmistorobotilla hän löysi viikossa puolesta miljoonasta verkkopalvelusta pari miljoonaa haavoittuvuutta.
Hän kertoi esimerkin, miten oli sovellushaavoittuvuuksia käyttäen muuttanut tilaukseensa 80 %:n alennuksen. Varastomies alkoi kuitenkin ihmetellä suurta alennusprosenttia ja tarttui puhelimeen. Entä tulevaisuudessa, jos tuotantoketju automatisoituu eikä ole enää varastomiestä lukemassa tilausta?
Ohjelmoijille ei kerrota, miten tehdään tietoturvallista SOAP:ia. Heille opetetaan, että ensin koodataan ja sitten testataan, vaikka tietoturva pitäisi rakentaa osaksi koko prosessia.
Monet kuvittelevat, että palomuuri, VPN ja SSL takaavat tietoturvan. Uusia haavoittuvuuksia on kuitenkin 75 % enemmän kuin ennen; nyt ne ovat sovelluksissa eivätkä linjoissa tai palvelimissa.
Jos autoja rakennettaisiin kuin tietojärjestelmiä, niissä ei olisi ikkunoita eikä jarruja; eihän niitä itsestäänselvyyksinä mainittaisi vaatimusmäärittelyissä.
nSense teki vuonna 2006 yli sata turvatestiä, joista löytyi vain viisi puhdasta sovellusta.
Yrityksen pitäisi analysoida, mitä tietoturvaongelmista seuraa? Ensimmäinen raportoitu verkkopankkihaavoittuvuus lienee se, kun äiti jätti verkkopankin auki ja 16-vuotias poika huomasi, että osoitekentässä pyöri tilinumeroita. Hän pääsi vaivattomasti siirtämään rahoja toisten tileiltä.
Http-protokolla on tilaton ja ohittaa kaikki tietoturvat. Se suosii ”pahiksia”. OWASP kuvaa, millaisia haavoittuvuuksia sovelluksista löytyy. Niitä löytyy 80 % sovelluksista, mikäli tietoturvatestaus uupuu.
Tietoturvahaavoittuvuudet voidaan jakaa teknisiin ja loogisiin. Jälkimmäiset liittyvät tilanteisiin, joissa sovellus ei tarkista syötettä: sushia saatiin parissakymmenessä minuutissa, vaikka ohjeellinen vähimmäisaika oli pari tuntia. 95 % haavoittuvuuksista voitaisiin välttää validoimalla syöte ja enkoodaamalla tuloste.
Missään ei rakenneta ohjelmistoja niin, että tietoturvallisuus olisi ohjelmoijasta riippumatonta. Liian usein ohjelmoija itse testaa sovelluksen tietoturvan ja liian harva asiakas vaatii tietoturvallista toimintaa. Tietoturva pitäisi testata silloin, kun ympäristö muuttuu – mutta ympäristöhän muuttuu päivittäin.
Koulutuksessa pitäisi korostaa, että sovelluksen tietoturva on laatukriteeri siinä missä toiminnallisuuskin. Kaikille sovelluksille pitäisi määrittää minimivaatimukset. Organisaatio jää riskianalyysissaan liian usein sille tasolle, että tunkeutujaa ei päästetä palvelimelle, mutta unohdetaan, että tunkeutuja voi hintoja muuttamalla huijata itselleen ilmaiseksi musiikkifirman kaikki kappaleet.
Pentti Virtanen Tieturilta kertoi kouluttajan ottein, miten vaatimukset valmistuvat viikossa. Riittävän pieniksi pilkotuilla kokonaisuuksilla, joita osaavat ihmiset käsittelevät.
Perinteinen vesiputousmenetelmä on kuin organisaatiota vaihdettaisiin joka vaiheen jälkeen ja tieto välitettäisiin kuvauksissa keskustelua välttäen. Ketterissä menetelmissä myönnetään, ettei vaatimuksia saada kerralla oikein – varsinkaan sitä, mitä kaivataan neljän vuoden kuluttua tai ensi joulumarkkinoilla. Sitäpaitsi: jatkuvasti löytyy uusia tapoja tietojärjestelmien toteuttamiseen. Miksi ne jätettäisiin hyödyntämättä kiveen hakatuilla vaatimusmäärityksillä ja tietojärjestelmäprojekteilla?
Sopimukset eivät tee järjestelmää eikä tavoitteena ole voitto välimiesoikeudessa vaan toimiva järjestelmä. Sopimusten sijaan tarvitaan luottamusta ja sopeutumista muutoksiin!
Ketterissä projekteissa asioita tehdään rinnakkain, siksi kalenteriaika lyhenee. Ketteryys edellyttää ammattitaitoisia, motivoituneita ihmisiä sekä kommunikointia tiimien sisällä, niiden välillä ja asiakkaiden kanssa. Projektissa pitää olla riittävästi osaavia ihmisiä, jotka voivat keskittyä päätoimisesti, tuntea ”flown”. Mieluummin tehdään heti tietoturvallista koodia kuin etsitään haavoittuvuuksia jälkeenpäin.
Kallein tapa rakentaa on kokonaishintainen budjetti. Jos järjestelmä tilataan paloissa, voidaan lopettaa ajoissa. Scrum tuottaa asiakkaalle joka kuukausi toimivan sovelluksen, jota on helppo arvioida. Miten perinteisessä projektissa voidaan tietää, milloin sovelluksesta 22 % olisi valmiina?
Millainen projektisuunnitelma on muuttolinnuilla? Niillä ei ole projektipäällikköä ja ne sopeutuvat kulloinkin eteen tuleviin tilanteisiin.
Miten keität perunoita? Mittaatko veden määrän ja perunoiden koon ja lasketko siitä, kuinka kauan perunoiden pitää kiehua? Vai kokeiletko perunoiden kypsyyttä haarukalla?
Ketterät menetelmät eivät ole hopealuoti. Ohjelmistotuotannossa vaikeinta on ajatteleminen.
Byrokraattisessa organisaatiossa, jossa luvan saamiseen menee kuukausia, on vaikea toimia ketterästi. Perinteistä ohjelmistokehityksestä siirrytään ketteriin pienin askelin – aluksi vaikka lisäämällä kommunikointia.
Minna Oksanen SysOpen Digialta innosti meidät Business Intelligencesta. Onko organisaatiosi pulloposti, purjevene vai laiva? Ajelehditko vai ohjaatko itse? Business Intelligence tarkoittaa liiketoimintatiedon hallintaa yhtenäisen tietomallin avulla. Muutosta mitataan mahdollisimman pienin syklein, jotta saadaan konkreettisia tuloksia järkevässä ajassa.
Mitä tällä alueella on tapahtunut kymmenessä vuodessa? Voisiko metatiedoin kertoa, että tiedot liittyvät toisiinsa niin, ettei tietoa tarvitsisi toistaa? Perustiedot keskittyvät transaktioihin, kuutiot analyysiin. Kahden eri järjestelmän raportit saattavat poiketa toisistaan, jos luvut lasketaan eri tavoin. Samalle näytölle voidaan yhdistää eri elementtejä, kunhan tiedot ovat olemassa.
Näkyviä ratkaisuja saadaan sadassa päivässä. Real Time Datawarehousing and Reporting tarjoaa vastauksen kysymykseen, kuinka monelta kalkkunalta pitää katkaista kaula, jotta huomenna liikkeessä on riittävä määrä kalkkunaleikkeitä. Vastaus ei saa perustua viime viikon tilanteeseen, jos huomisen tilaukset ovat jo tiedossa.
Metadatan merkitys kasvaa, mallinnuksesta ei koskaan saa luopua ja liiketoiminnan kanssa pitää keskustella.
Perttu Karvinen ja Mikko Holmberg CodeBakersista kertoivat Java-kehityksessä puhaltavista tuulista. Kehitysrytmi on hidastunut, Java on vakiinnuttanut asemansa, mutta vaihtoehtojakin löytyy. Suppeimmillaan Java on ohjelmointikieli, laajimmillaan ohjelmistoalusta. Skriptikielillä pystytään nopeasti tekemään jotain tilanteissa, joissa Javalla joudutaan vääntämään paljon.
Spring on ohjelmointikehys, joka hoitaa sille esiteltyjen olioiden väliset riippuvuudet. Hibernate on olio-relaatio-tulkki, joka piilottaa relaatiomaailman olio-ohjelmoijalta. Java-koodaajan ei siis tarvitse tietää mitään SQL:stä. Hibernaten ongelmana on, että sovellus voi lähettää SQL-käskyjä ilman, että tulkki huomaa sitä. Eclipse taas on avoin kehitysympäristö.
Ketterään kehitykseen on tulossa kollaboraatioalustoja. Työkalutuki on jo olemassa ja kasvaa jatkuvasti. TDD eli Test Driven Development vaatii aloittamaan testauksen heti. Jatkuva integraatio varmistaa, että koodi toimii. Silti projektinhallintaakin tarvitaan. SOA ja BPM, joista aiemmin puhuttiin, eivät periaatteessa vaikuta sovelluskehitykseen Javalla.
Juhani Snellman Qentinelista kysyi: Testaus, Quo Vadis? Hän aloitti esityksensä kolmesta taidemaalarista, joiden piti kuvata omena. Yksi kuvasi omenan, toinen omenapuun ja kolmas puutarhan, jossa omenapuu kasvoi. Juhani Snellman kuvasi meille testauksen ympäristössään, nopeutuvan liiketoiminnan ja globalisaation puutarhassa, jossa kaikkea halutaan enemmän, nopeammin ja kustannustehokkaammin.
Testaus tekee näkyviksi liiketoiminnan riskit ja mahdollisuudet. Testaus sinänsä ei paranna ohjelmistoa vaan tuottaa relevanttia informaatiota liiketoimintariskien hallintaan. Testaus on ohjelmistokehityksen ja tietojärjestelmähankkeiden tukiprosessi.
Testauksen trendeinä voidaan mainita halpatuotanto, erikoistuminen ja ketterä testaus. Kymmenen erikoistunutta testaajaa voivat korvata tuhat halpatuotantomaista ostettua perustestaajaa.
Ketterän menetelmän kirjat eivät käsittele testausta. Osaava ketterä testaaja tukee sekä kehittäjätiimiä että liiketoimintaa.
Yksikkötesti ohjaa suunnittelua ja hyväksyntätesti tavoitteiden määrittelyä. Näistä voidaan automatisoida ne, jotka eivät vaadi aivokapasiteettia.
Tutkivassa testauksessa testaajan ammattitaito korostuu: hän ei toimi etukäteen mietittyjen määritysten mukaan vaan kokeilee asioita, joista tiedetään, että niissä joskus on ongelmia tämänkaltaisissa järjestelmissä. Kyse on negatiivisesta testaamisesta. Se ei onnistu perinteisessä organisaatiossa, jossa vaaditaan paljon kuvauksia ja testitapausten katselmointia etukäteen.
Siirtyminen perinteisestä ohjelmistokehityksestä ketterään tuottaa välivaiheessa kaaoksen; ihmisen toimintahan ei muutu nopeasti.
Lopuksi Silja Räisänen Osuuspankkikeskuksesta kertoi omien kokemustensa ja Systeemityölehtien valossa, mikä kymmenen vuoden aikana Sytyken laivaseminaareissa on ollut IN.

Sytyken MallinnusOSY

abstrakti malli
kehittää ketterästi
verkkopalvelut
Historian siivet havisivat, kun Sytyken OlioOSYn tuhkasta nousevan MallinnusOSYn ensimmäisessä miniseminaarissa 18.4.07 SysOpenilla kaksi puhujaa ja kaksi osallistujaa muistelivat yhdessä Sytyken Oliotyöryhmää, jossa viisitoista vuotta sitten työstivät yhdessä raporttia Oliot systeemityössä.
Jukka Tamminen aloitti historiakatsauksella 1980-luvun lopulla Finnairilla tehtyihin SRM-tutkimuksiin, jotka paljastivat yksitoista asiakastietojärjestelmää; joka sovelluksella oli omansa ja jokaisessa niistä tiedot eri tiloissa. Kokonaismallintaminen selkeytti tilannetta, mutta toi raskaat vuosia kestäneet projektit, jotka vastasivat huonosti nopeasti muuttuvan liiketoiminnan tarpeisiin.
Tänään tietojärjestelmiä kehitetään ketterästi. Muutamassa päivässä laadittava abstrakti oliomalli auttaa hallitsemaan useat samanaikaiset ketterät projektit. Malliin kootaan kaikki keskeiset käsitteet, joista liiketoiminta tarvitsee tietoa. (Otus, jota Jukka Tamminen nimitti oliomalliksi, on mielestäni UML:n mukainen luokkamalli.)
Malli tuottaa todellisuudesta toisen todellisuuden, lennoista varausjärjestelmän. Tarvitsemme älykkään ihmisen, joka huomaa vastaavuudet näiden todellisuuksien välillä – ja tämän älykkään ihmisen soisi olevan mukana jo järjestelmän rakennusvaiheessa.
Jukka sanoi, että jos liiketoiminnan abstrakti malli tietää jotain käyttöliittymistä, se on saastunut. (Saman tapaista ajatusta olen itse vuosikausia yrittänyt tolkuttaa opiskelijoilleni.)
Sakari Lehtonen heitti, että olioiden aika oli vuosina 1991-2006, mutta nyt on siirrytty SOAan. 1980-luvulla meillä oli moduulit, 1990-luvulla käyttötapaukset ja 2000-luvulla palvelut. Modulaarisuus tarkoittaa metsän näkemistä puilta. B2B tarkoittaa verkostoliiketoimintaa. Domain Modelista eli liiketoimintamallista saadaan XML-malli – niin, yksinkertaisesti väkäsillä.
Tilakaavion käyttö ja merkitys on herännyt uudestaan henkiin, kun mallinnetaan liiketoimintatapahtuman tilaa. Nykyisin puhutaan rekisterien sijaan komponenteista, mutta transaktiot ovat samoja kuin ne ovat olleet neljännesvuosisadan ajan. Uutta on integraatiokerros ja sen BPEL-kieli. BPM-prosesseissa orkesteroidaan liiketoimintaprosessit karkealla tasolla kun taas UML:n käyttötapaukset kertovat käsittelysäännöt tarkemmalla tasolla.
Sakarin mielestä luokkamallia ei pidä esittää liiketoiminnan edustajille vaan heidän kanssaan keskustellaan käyttöliittymien avulla. Oma kokemukseni on erilainen: käyttäjät, asiakkaat tai tilaajat, vaikka heillä ei olisi it-alan koulutusta, osaavat lukea luokkamallia ja ottaa kantaa luokkiin ja niiden välisiin yhteyksiin, kunhan heille annetaan selkokielellä mallin lukuohjeet. Käyttäjät ovat toimintansa asiantuntijoita; juuri he pystyvät kertomaan, voiko tilauksella olla yksi vai monta tilaajaa – tai asuntolainalla monta lainanottajaa, esimerkiksi mies ja vaimo.
Joku yleisön joukosta tiesi kertoa Ivar Jakobsonin sanoneen viime vuoden lopulla Suomen-vierailullaan, että UML on kuollut. Mielenkiintoista! Kun viisitoista vuotta sitten työstimme Sytyken Oliotyöryhmässä Oliot systeemityössä -raporttia, ei UML ollut vielä syntynyt eikä käyttötapauksia keksitty.
Sakari ja Jukka väittelivät kiivaasti käyttötapauksista ja kollaboraatiokaavioista. Sakari kannatti edellisiä ja piti jälkimmäisiä tarpeettomina kun taas Jukka oli täysin toista mieltä.
Illan viimeinen esiintyjä, nuori teoreetikko Tomi Reinikainen kertoi intressiperusteisesta lähestymistavasta. Intressejä on eri tahoilla ja niitä päivitetään järjestelmän elinkaaren ajan, myös ylläpitovaiheessa.