Suomeelle hyvä terveydenhuoltojärjestelä halvalla

 

Blogiteksti on julkaistu WordPressissä  12. 10. 2011  - olen edelleen samaa mieltä asiasta!

Tilanne tänään

Pitkään on käyty keskustelua Suomen terveydenhuollon tietojärjestelmien tilasta. Keskustelu on vain kiihtynyt viimeisen vuoden aikana. Kriittisiä kommentteja on kuultu jo paljonkin. Tässä kannan minäkin korteni yhteiseen kekoon.

Terveydenhuollon tietojärjestelmät ovat ajan mittaan - varsin pitkän ajan kuluessa - enemmänkin sattumalta muotoutuneet sellaisiksi kuin ne nyt ovat, kuin että niiden ympärillä olisi joku systemaattinen kokonaissuunnitelma tai näkemys. Tämä koskee itse asiassa monta muutakin toimialaa sekä julkisella että yksityisellä puolella. Julkisen terveydenhuollon tietojärjestelmämarkkinoille on muotoutunut muutama iso toimija, jotka hallitsevat alaa Suomessa. Näiden toimijoiden varsin vanhat ja osittain tästäkin syystä jäykät ja raskaat tietojärjestelmät hallitsevat markkinaa. Näyttää siltä, että nämä markkinajohtajat ovat varsin haluttomia tekemään isoja muutoksia, sillä nämä tämänhetkiset ratkaisut takaavat näille varsin vakaan ja muhkean kassavirran ja voitot. Toisaalta uudistaminen vaatisi investointeja ja sisältäisi huomattavia riskejä. Tässä yhteydessä kuvaan astuu myös konsortio, jonka nimi on HL7. Tämä on amerikkalaisen organisaation: Health Level Seven International
(3300 Washtenaw Avenue, Suite 227, Ann Arbor, MI 48104) johtama maailmanlaajuinen yhteenliittymä. Liittymän  HL7:n 2300 + jäseninä ovat noin 500 yrityksen jäsentä, jotka edustavat yli 90% tietojärjestelmien toimittajista  terveydenhoidossa. Tällä organisaatiolla on liiketoimintamallin kaltainen RIM ( Reference Information Model). En aivan tarkkaan tiedä minkä metodologian mukainen tämä malli on, mutta se näyttää vanhalta ER- tietomallilta. Malli on todella huono eikä ainakaan edistä operatiivisen ohjausjärjestelmän rakentamista. Se ei myöskään ole liiketoiminnan oliomallinnuksen mukainen malli.

Minulla ei ole tietoa siitä, kuinka paljon Suomen terveydenhuollon nykyiset tietojärjestelmät nojaavat mihinkään standardeihin, mutta ammatillinen arvaukseni on, että ei paljoakaan. Toisaalta onko sellaisia varteenotettavia edes olemassa?

Soraääniä koko tämän toiminnan tiimoilta on kuulunut paljonkin. Viimeksi Valtiontalouden Tarkastusviraston kitkerät lausunnot siitä, että tähän on (taas) hukattu 500 miljoonaa euroa saamatta aikaan mitään merkittävää

Minun vaihtoehtoni

Olen erilaisista sattumista johtuen tehnyt oman terveydenhuollon oliomallin ja sen pohjalta mahdollisen etenemispolun tehokkaaseen, halpaan, hajakeskitettyyn ja korkealaatuiseen terveydenhuollon tietojärjestelmäkokonaisuuteen.

Seuraava luokkakaavio kuvaa tämänhetkistä käsitystäni kohdealueesta:

Mallissa on 22 luokkaa ja näiden välisiä assosiaatioita on 39. Näiden lisäksi kaaviossa on kaksi periytyvyyttä. Tämä malli on laadittu kuvaamaan tyypillistä terveyskeskustoimintaa. Tämän mallin olen laatinut minä ja sen tekemisessä olen vain vähän keskustellut terveydenhuollon  työntekijöiden kanssa. Siinä suhteessa tämä malli on laadittu kaikkien ohjeiden ja hyvien suositusten vastaisesti. Puolustuksekseni voin sanoa, että olen seurannut hyvin läheltä terveyskeskuslääkärin ja sittemmin terveysaseman yleislääkärin arjen toimintaa.  Mallia tulee tarkastella kuitenkin karkeana toimialaa koskevana luonnoksena. Malli kattaa pienin muunnoksin myös sairaalan osastotoiminnan. Näin ollen mallia voidaan pitää karkeana koko Suomen terveydenhuoltoa kattavana mallina. Tämä on siis HL7 RIM- mallista poiketen kyseisen liiketoiminnan abstrakti oliomalli ja näin ollen kuvaa kohdealueen rakenteiden lisäksi tähän liittyvän operatiivisen ohjauksen liiketoiminnan.

Tästä näytteenä olkoon seuraava Kalle Kehvelin angiinan tutkimusta ja hoitoa kuvaava olioiden yhteistoimintakaavio . (Tästä maallikko saa paremman käsityksen katsomalla tähän liittyvän PowerPoint –animaation  http://www.slideshare.net/jukkatamminen/terveydenhuolto-ja-esim )

Esittämäni oliomalli (kts: http://fi.wikipedia.org/wiki/Oliomalli) siis kuvaa varsin kattavasti terveydenhuollon operatiiviseen ohjaukseen ja logistiikkaan liittyvät todellisuuden tapahtumien vastineet tietojärjestelmässä. Kun tietojärjestelmä tehdään räätälöidysti noudattaen loogista 3-kerrosarkkitehtuuria, (kts. blogini:  http://jukkatamminen.wordpress.com/)niin saadaan edullisesti tehokas ja laadultaan maksimaalinen sovellusjoukko, jonka ytimessä on em. mallin toteutus.

Järjestelmäkokonaisuuden toteutus ja kustannukset.

Tämän ytimen toteutuksen kokonaiskustannukset, kun se toteutetaan tästä suoraviivaisesti Javalla, ovat todella vaatimattomat. Mallista toki tässä vaiheessa puutuu suurin osa luokkien vapaista ominaisuuksista (attribuuteista), mutta käsitteet (luokat) ja näiden väliset yhteydet (assosiaatiot) ovat suurelta osin jo tässä.

Kun tämä malli generoidaan Java- koodiksi ja siihen vielä kirjoitetaan tässä näkyvien palvelunimien sisältö, on tämän hinta korkeitaan noin yksi kuukausi työtä eli noin 15 000 € luokkaa. Tämä on siis vain osa ytimen lopullisista kustannuksista, mutta antaa asiatuntijalle käsitystä ytimen kustannusten kertaluokasta.

Tähän liittyvä sovellusrypäs sisältää esimerkiksi seuraavia sovelluksia:

• Ajanvaraus

–        Hallinnoidaan vastaanottoaikoja

–        Lisätään, muutetaan ja poistetaan

–        Hallinnoidaan lääkärien läsnäoloaikoja

–

• Vastaanottojärjestelmä

–        Hallinnoidaan potilaan statustietoja

–        Hallinnoidaan potilaan oire/löydöstietoja

–        Hallinnoidaan potilaan tautitietoja

–        Hallinnoidaan potilaan lääkitystietoja ja reseptejä

–        Hallinnoidaan potilaan tutkimuskäyntejä ja tuloksia

–

• Laboratoriojärjestelmä

–        Hallinnoidaan tutkimuskäyntejä

–        Talletetaan ja käsitellään tutkimustietoja

• Työntekijöiden työajan suunnittelu- ja seirantajärjestelmä
• Laskutusjärjestelmä
• Yhteysrajapinnat vastaaviin järjestelmiin

Tämä kolmikerrosmallin perustuva räätälöity ratkaisu antaisi mahdollisuuden käyttää yllä olevan mallin täydennettyä versiota eri sovellustoteutusten standardina rajapintana ulkopuolisille yhteistyötahoille. Nämä luokat, niiden assosiaatiota pitkin tapahtuva navigaatio ja joukko keskeisimpiä palveluita mahdollistaisivat vahvasti yhteen sovitettavan kokonaisuuden valtakunnan tasolla ja loisi samalla hyvän mahdollisuuden ydintietojen keskitettyyn tallennukseen. Tässä toisena varteenotettavana ja itse asiassa houkuttelevampana vaihtoehtona onkin hajakeskitetty talletus sekä keskitetty indeksi, joka mahdollistaisi tietojen nopean hakemisen indeksitiedon perusteella.

Vaihtoehtoisia tulevaisuuksia

Tällä hetkellä näyttää siltä, että voimakkaiden vaikuttajien kapeat omat intressit ajavat tätä huomattavasti enemmän kuin yhteinen etu. Mikäli nykyisiä valtarakenteita vaalitaan ja pönkitetään, kustannukset yhteiskunnalle tulevat olemaan sekä lyhyellä että pitkällä aikavälillä huomattavan paljon suuremman kuin olisi suotavaa tai tarpeen. Onnettomin vaihtoehto on sellainen – jollaisia huhuja on kantautunut korviini – että yritetään hoitaa pahaa yhteensopimattomuusongelmaa sillä, että kaikki julkiset toimijat pakotetaan hankkimaan sama järjestelmä. Tämähän tarkoittaisi yhden (lähes arvalla valitun) toimittajan nostamista kiistattomaan monopoliasemaan. Tästä vuorenvarmasti seuraa teknisen kehityksen täydellinen pysähtyminen ja raaka rahastus. Tällaiset julkiset hankinnat tulee aina jättää avoimeksi jatkuvalle kilpailulle ja näin turvataan tekninen kehitys. Tämä edellyttää onnistuakseen kuitenkin kahta asiaa: 1) kovaa teknistä osaamista ja tietämystä hankkivissa organisaatioissa ja 2) näiden asiantuntijoiden todellista riippumattomuutta kaikista toimitusketjun intressiryhmistä.

Suuri harppaus

 

Tietojärjestelmien kehitys olioilla ja ketterästi

Siitä kun lopetin sovelluskehitys työn alkaa olla kutakuinkin 10 vuotta. Törmäsin tilanteeseen, jossa minulle tuli tarve kertoa ketterästä kehittämisestä ja Scrumista ja havaitsin yllätyksekseni, että mistään blogistani EI löytynyt yhtään  artikkelia aiheesta.

No nyt korjaan tämän puutteen.

Tietojärjestelmistä ja monimutkaisuuden hallinnasta

Tietojärjestelmien kehittämisen ja ylläpidon haaste on aina ollut niiden monimutkaisuus. 

Tietokoneiden teknologian kehittymisen myötä,  tietojärjestelmien monimutkaisuus on kasvanut lähes eksponentiaalisesti viimeiset 50 vuotta. On siis aika luonnollista, että tietojärjestelmien toteutukset ovat aina olleet tuskaista taistelua.

Monimutkaisuuden hallinta onkin keskeisin avaintekijä tämän työn menestykseen.

Ensimmäinen näkemäni voitto monimutkaisuuden hallinnassa olivat tietokantojen synty.  

Relaatiokantojen käyttöönotto toi merkittävän edistysaskeleen.

80-luvun lopulla oivalsin, että tiedon ja siihen luonnollisesti liittyvän toiminnan yhteenliittäminen toisi oleellisen yksinkertaistuksen kokonaisuuteen. Koko tietokantayhteisö etsi tällaista ratkaisua. Kun sitten silkasta uteliaisuudesta 1989 osallistuin Petrer Coadin kahden päivän olioseminaariin Tukholmassa, ymmärsin kahdessa tunnissa, että nämä ihmiset olivat löytäneet tuon ratkaisun ja  kuinka yksinkertainen ja elegantti se olikaan.

Siitä alkoi pitkä ja monivaiheinen matkani olioiden maailmassa. Se päättyi vasta 2010 Yleisradion uuden Areenan oliomallin laatimiseen ja se ensimmäisen version toteutukseen.

Tämän jälkeen alalla ja varsinkin Tieto OYJ:ssä toteutui imperium vastaisku konservatiivisim ja ohjelmistobisneksen vaatimukset aiheuttivat menetelmien taantumisen ainakin 10 vuodella taaksepäin enkä tiedä onko tästä vieläkään toivuttu. Uusi olioparadigma oli selvästi liian vaikea ja abstrakti vanhoille tekijöille. Tieto irtisanoin minut 2011 kuukausi jälkeen 60-vuotis syntymäpäivieni.

Olioanalyysissä, suunnittelussa ja toteutuksessa keskeisin tavoite on kompleksisuuden hallinnassa. Tämä saavuttamisessa on olioparadigma ja abstraktiotason hallinta täysin keskeisiä. Olimme Finnairilla hankkineet Smalltalk-kehitysympäristön ja olimme oppineet ohjelmoimaan sen avulla tehokkaasti vuoteen 1995 mennessä.

Olin tehnyt olioanalyysia ja oliomalleja ihan  alusta lähtien, mutta kun yritin välittää ajatuksiani ja opettaa mallintamista, niin ihmiset eivät tuntuneet ymmärtävän ja oivalsin. että ajatukseni eivät olleet riittävän selkeät ja kirkkaat. Kävin useissa olioseminaareissa ympäri maailmaan ja olin sekä kuuluut, että pääosin lukenut kaikkia merkittäviä guruja.

Meni kuitenkin melko pitkään, ennen kuin kykenin selkäsi ajattelemaan ja argumentoimaan asiasta. Oivalsin monta asiaa: olioitettujen tapahtumien merkityksen, liiketoiminnan oliomallin irrottamisen sovelluksien vastaavista. Lähes kukaan guruista ei irroittanut liiketoimintamallia sovellusmallista ja tämä johti lopputulosten tarpeettomaan monimutkaisuuten. Olin saanut ajatteluni kiteytettyä 2005 vuoteen mennessä. Näinä vuosina tein paljon olionanlyysi koulutusta. Näiltä ajoilta on myös peräisin kolme olioanalyysi videota, jotka tein Tiedolla. Nämä ajatukset on koottu blogiteksteihin IT-dinosaurus blogille.

Itse asiassa useasti oliomenetelmiin petyttiin juuri väärän abstraktiotason valinnan takia. Kun aiemmin oli juuri painotettu sitä, että kaikki asiat pitää ensin analysoida ja lyödä lukkoon pinitä yksityiskohtaa myöten. Tämä johti kompleksisuuden räjähdykseen, jota kukaan ei kyennyt hallitsemaan. Kompleksisuuden hallinnassa ylivoimaisesti tärkeintä on pitää detaljien määrää mahdollisimman pienenä, jotta keskeiset rakenteet ja mekanismit paljastuvat. Tästä oli hyvä  esimerkki, kun IBM kehitti oliosovellusta ja olin tavannut yhden suunnittelutiimin jäsenen. Puolen vuoden jälkeen kun kyselin siitä, hän kertoi että luokkia oli suunniteltu 20 000 ja toteutusta ei oltu vielä aloitettu. Tästä hankkeesta ei koskaan tullut mitään. Liiketoimintaytimen ensimmäisessä toteutuksessa on tärkeää olla alle 100 luokkaa mieluummin noin 30 liiketoimintaluokkaa. 

Seuraava askel tällä tiellä onkin sitte Ketterä sovelluskehitys. Olen tutustunut Scrumiin jossain 2000-luvun puolivälissä. Tämä itseohjautuvien tiimien työskentelytapa on alun perin peräisin Japanin teknologiateollisuudesta 1980 ja 1990 lukujen vaihteesta. Scrum kehitettiin tukemaan oliokehitystä. 

1900-luvun lopulla oli sovelluskehityksessä vallaa V-malli ja vesiputosmalli. Tässä uusi tietojärjestelmä analysoitiin ja suunniteltiin viimeistä piirto myöten ja sen jälkeen syntyneet suunnitelmat toteutetiin. Usein tuo ensivaihe saattoi kestää yli vuoden isolta työryhmältä. 

Käytännössä nämä periaatteet eivät toimineet koskaan, sillä rakennelma on jo teoriassa mahdoton. Ensinkin laajojen kokonaisuuksien toteutettavissa oleva virheetön suunnittelu on inhimillisesti mahdoton tehtävä. Tämä johti siihen, että suunnitelmiin jäi ylimalkaisuutta ja vaiketa kohdat ohitettiin. Suunnitelmat sisälsivät paljon ristiriitaisuuksia ja dokumentaatiota oli liian paljon ollakseen toteutusvaiheessa mitenkään hallittavissa. Oleelliset rakenteet hukkuivat detaljeihin. Hanki siis konkreettisesti hukkui omiin suunnitelmiinsa. Jälkeenpäin voi vain ihmetellä sitä sokeutta, kun itsepäisesti päätä hakattiin tähän samaan seinään kerta toisensa jälkeen! 

Kun Ken Schwaber vei 1995 asiakkaidensa käyttämät sovelluskehitys prosessien kuvaukset DuBontin (kemianteollisuuden) tuotantoprosessin asiantuntijoille, ei naurulle tullut loppua.

Nämä asiantunijat kertoivat sovelluskehtys on niin monimutkainen ja ennustamaton, että tämä onnistui vain “empiirisellä” menetelmällä. He kertoivat, että tämä ei ollut mitään uutta vaan näin toimitaan kaikkien monimutkaisten ja vaikeasti hallittavien prosessien kohdalla.

Aina 1900 loppupuolelle saakka yleisesti uskottiin sovelluskehitys hankkeiden voitavan analysoida ja suunnitella täydellisesti ennen toteutusta. Näin siis opetettiin ja yritettiin toimiakin, mutta tämä ei toteutunut koskaan ja niinpä 1900-luvun sovellushankkeiden historia  on todella surullinen epäonnistumisien kertomus.. Todellisuudessa edes analyysi ei ole mahdollinen kuin johonkin pisteeseen saakka, jossa sovitaan keskeisten osien toteutusten periaatteista.

Aivan oleellinen ero tähän saadaan aikaan kun 1) analyysi aloitetaan rajatulla abstraktille pelkästään liiketoiminnan oliomallilla. Tästä saadaan liiketoiminna ytimen oleellinen oliorakenne ja toiminnallisuus olioiden yhteistoimintamalleilla (collaboration diagrams). 

2) Koko kehittämistyötä ohjataan ketterästi. Tämä tarkoittaa sitä, että lyhyehkön suunnittelujakson jälkeen toteutetaan jotain konkreettista lopullisesta tavoitteesta ja sitä seuraa taas suunnittelu. 

Tuo koko toiminnan raami on sitten Scrum. Scrum antaa mahdollisuuden suunnitella lähellä olevaan  kohtuulliseen horisonttiin saakka ja sen jälkeen todentaa suunnitelma toteuttamalla jotakin. Näin edeten pienin askelin kaikki osapuolet voivat arvioida konkreetisia saavutuksia ja tarkistaa etenemisen suunta ja tehdyt ratkaisut. 

Scrum sovelluskehitys

Olen 2000-lluvun alussa tutustunut Scrumiin ja toiminut hetken Scrum Masterina. Tässä Scrum esittely 

Johdanto

Scrum- menetelmä sopii ihanteellisesti monimutkaisiin tai nopeasti muuttuvien vaatimusten ympäristöihin. Scrum –projektin tehtävistä laaditaan luettelo nimeltään Product Backlog. Tämä on luettelo tulevan ohjelmiston ominaisuuksista. Scrum -ryhmä työskentelee ajallisesti rajatun jakson (30 pv) puitteissa. Tällaista jaksoa kutsutaan Sprintiksi. Sprintin alkaessa pidetään Sprintin suunnittelukokous (4 + 4 tuntia). Tämän aikana tiimi yhdessä tuotteen omistajan kanssa valitsee ne ominaisuudet, jotka tiimi sitoutuu toteuttamaan Sprintin aikana. Nämä ominaisuudet muutetaan Sprint Backlogin tehtäviksi.

Scrumin aikana työn tekemistä ryhmän sisällä ohjataan päivittäisillä Scrum –kokoontumisilla. Tällaisen kokoontumisen kesto on noin 15 min ja tämän aikana ryhmä pyrkii ymmärtämään työn edistymisen kokonaistilanteen ja työn esteet.

 

(kst. Ken Scwaber & Mike Beedle: Agile Software Development with Scrum

  Prntice Hall 2002)

Scrum perustuu työn edetessä tarkkeneviin tavoitteisiin ja ryhmän voimakkaaseen itseohjautuvuuteen. Tarkasti ennalta määritellyt prosessit ovat mahdollisia vain hyvin yksinkertaisten asioiden yhteydessä. 

Scum roolit ja vastuut

Scrum- projektin kolme roolia ovat tuotteen omistaja:  Tuotteen omistaja  (Product Owner),

Scrum Master ja Scrum Tiimi 

Tuotteen omistaja ja Sprintin suunnittelukokous

Tuotteen omistajan vastuulla on ylläpitää ja järjestään tekemättömien tuoteominaisuuksien listaa (Produck Backlog) 

Toteuttamaton tuotteen ominaisuuslista on luettelo tuotteen piirteistä, joita ei vielä ole tuotteeseen toteutettu. Kun projekti käynnistyy, se alussa ei ole massiivista aikaa vievää pyrkimystä tuottaa täydellistä tehtävälistaa, vaan kirjata täysin ilmeiset suuntaviivat kehitykselle ja antaa tuotteen ”kehittyä” tai ”elää” oikeihin mittoihinsa. Näin toteuttamattomien ominaisuuksien lista elää, täydentyy ja tarkkenee oppimisprosessin myötä. 

Sprintin suunnittelukokouksessa tuotteen omistaja priorisoi toteutettavat ominaisuudet ja kuvailee ne tiimille. Tämän jälkeen tiimi päättää, mitkä ominaisuudet listan alusta se pystyy toteuttamaan Sprintin aikana. Tämän jälkeen tiimi siirtää tuotteen ominaisuuslistalta nämä ominaisuudet Sprintin ominaisuuslistalle (BackLog)  

Sprintin suunnittelukokoukset ovat aikarajoitettuja. Kumpikin kestää neljä (tai 3) tuntia. Kun jälkimmäinen osa alkaa siitä virallisesti myös Sprint. Jälkimäiseen kokoukseen osallistuu vain srcum tiiimi ja sen lopputuloksena tiimi muodostaa alkuosan aikana syntyneestä srpinttiin valituista tuoteominaisuuksista sprintin tehtäväluettelon.

 

  

Päivittäinen Scrum palaveri

Scum tiimi pitää päivittäin scrum- palaverin. Tyypillisesti nämä pidetään samaan aikaan samassa paikassa päivittäin.

Palaverin kesto on noin 15 minuuttia. Näissä palavereissa kukin tiimin jäsen kertoo 

    • mitä Sprintiin kuuluvaa työtä on tehnyt edellisen scrum palaverin jälkeen 

    • mitä työtä aikoo tehdä seuraavaan palaveriin saakka

    •  mitä esteitä tehtävän suorittamiselle on tullut

 Tällä tavoin koko tiimi pidetään ajan tasalla siitä, miten työ edistyy. Tällöin kukin työntekijä kertoo julkisesti kunkin päivän sitoutumisensa yhteiseen tavoitteeseen. Palaverin keskeinen tehtävä on päivittäin tunnistaa työn edistymistä haittaavat esteet. 

Scrum Masterin keskeisin tehtävä on huolehtia pikaisesti syntyneiden esteiden poistamisesta.

Päivittäiseen Scrum palaveriin voi osallistua myös ”kanoja”, mutta heidän tulee olla pelkästään tarkkailijoita eivätkä he saa yrittää mitenkään (puhumalla, ilmeillä tai muut) vaikuttaa palaverin kulkuun.

Sprintin valmistumiskokous 

Sprintti päättyy valmistumiskokoukseen. Kokouksessa tiimi esittelee sprintin tulokset. Yleensä tämä tapahtuu esittelemällä aikaansaadun ohjelmiston toimintaa. Tämä kokous pyritään pitämään epävirallisena. Tämä merkitsee sitä, että PowerPoint –kalvojen esittäminen on jyrkästi kielletty ja tämän valmisteluun ei saa kuluttaa kahta tuntia enempää. Tämän kokouksen tavoitteena ei ole olla scrum tiimin taakka, vaan luonteva lyhyt aikaansaannosten esittely. 

Sääntöjä

Veli- Srcum –työskentelyssä noudatetaan seuraavia Scrum –sääntöjä.

    • Tiimi voi pyytää ukonpuolista neuvoa, apua, tietoa tai tukea

    • Sprintin aikana tiimi on ainoa taho, joka tekee suunnittelu- ja toteutuspäätökset ja tiimi on näin ollen täysin itseohjautuva eikä tiimin päätöksentekoon Scrumin aikana saa yrittää vaikuttaa ulkopuolelta

    • Jos Sprintin aikana tämän tavoitteet osoittautuvat ylivoimaisiksi, voi Scrum Master keskeyttää Sprintin ja käynnistää uuden Sprintin suunnittelukokouksen

    • Jos tiimi toteaa, että sen ei kykene saavuttamaan koko alussa asetettua Sprintin product backlogia, niin tiimi voi neuvotettl Scrum Masterin ja Product Ownerin kanssa mitkä ominaisuudet poistetaan nykyisen Sprintin listalta. Jos Srintin saavutettava lisäarvo osoittautuu liian pieneksi, voi Scrum Master keskeyttää Sprintin.

    • Tiimi päättää voiko se toteuttaa sovittua enemmän ominaisuuksia Srintin kuluessa.

    • Tiimin jäsenillä on 3 hallinnollista velvollisuutta

        ◦ Osallistua päivittäisiin Scrum- palavereihin

        ◦ Ylläpitää Sprint backlogin jäljellä olevia työmääriä päivittäin

        ◦ Kirjata työtunnit oman organisaation työkirjausjärjestelmään (kuten TERP)  

Kirjallisuutta

 Kent Schwaber & Mike Beedle: Agile Development with Scrum

Malli ja oliomalli

 

Oliomalli on tehokkain ja tuottavin tunnetuista sovelluskehitykseen käytetyistä malleista nyt ja näköpiirissä olevassa tulevaisuudessa. kts:http://fi.wikipedia.org/wiki/Oliomalli

Käsitteet malli ja mallinnus.

Malli on ihmistä (siis meidän rajoittunutta tietokapasiteettia varten) tehty pelkistys valitusta osasta todellisuutta. Tässä on siis kaksi avainsanaa 1) pelkisty (hienommin abstraktio) ja todellisuus.

Ensimmäinen ”mallinnuksen” sekaannus yleisessä kielenkäytössä näyttää liittyvän heti tähän käsitteeseen ”malli”. Aloittakaamme siitä mitä malli ei ole. Matemaattinen yhtälö tai yhtälöryhmä olipa siinä mitä tahansa matemaattisia elementtejä ei sellaisenaan koskaan voi olla malli. Yhtä vähän kielen kielioppi voi olla malli. Malli siis on joillakin sovituilla säännöillä tehty pelkisty –siis yksinkertaistus todellisuuden osasta.

Nämä pelkistyksen säännöt ovat siis mallin rakennuselementtejä eivätkä ne ole malli. Tällainen sääntö saattaa sisältää esim. matemaattisen yhtälön, mutta tulkita on yhtä kuin malli. Seuraava on yhtälö: v*t=s.

Tämä yhtälö voi toimia keskinopeuden mallina. Tästä tekee mallin seuraava toteamus: Yhtälössä s edustaa matkaa, t edustaa aikaa ja v keskinopeutta. Näin meillä on keskinopeuden pelkistyksen malli.

Liikkuvan kappaleen keskinopeus annettuna aikana on hyvin korkean tason abstraktio. Se siis selittää koko todellisuuden tapahtumasta erinomaisen vähän.

Koko tämä tematiikka on käsitelty laajasti ja ehkä parhaana yhteenvetona tästä aiheesta kehottaisin itse kutakin kääntymään Ludwig Wittgensteinin puoleen ja lukemaan: Tractatus logico-philosophicus

http://fi.wikipedia.org/wiki/Tractatus_logico-philosophicus

(Logisch-philosophische Abhandlung, 1921).

Hän käyttää esimerkkinä mittanauhaa ja toteaa, että mittanauhalla ei ole semanttista sisältöä. Se on sopimus tai sääntö – siis eräänlainen ymmärtämisen rakenne. Malliksi se muuttuu kun mittanauhan reuna koskettaa todellisuutta ja kertoo kappaleen pelkistyksen –siis sen mitan annettuun suuntaan.

Sovelluskehityksen mallit

Puhun operatiivisista ohjausjärjestelmistä. Tähän tarvitaan malleja, joiden avulla ohjaus onnistuu. Tällaisia malleja voisi kutsua simulaatiomalleiksi. Siis malli on laadittu niin, että se matkii todellisuutta mahdollisimman tarkasti. Kun todellisuudessa sattuu ilmiö, joka muuttaa kohdetodellisuutta, niin tätä vastaava muutos toteutuu mallissa kyseisen käynnistysilmiön vastineella.

Huonoja ja hyviä malleja

Yleistäen voi sanoa, että mitä yksinkertaisempi mallin laatimisen säännöstö on sitä pelkistetymmän (abstraktimman) osan todellisuudesta saa.

Yksinkertaiset aikamallit

Nämä mallit esiintyvät monilla nimillä: prosessimalli, aktiviteettikaavio, vuokavio käyttötapaus vain muutaman mainitakseni. Mallinnuksen ainoa rakennesääntö on määritä tapahtumia ja osoita tapahtumien välinen aikajärjestys. Sääntö on niin yksinkertainen että sitä on lähes mahdoton rikkoa! Niinpä mallien sisällöt voivat olla melkeinpä mitä tahansa! Näin malli siis selittään tapahtumien jonkinlaisen ajallisen peräkkäisyyden ja kaikki muu onkin sitten sattumaa.

Kaksi mallia

Tätä mallinnusta on terästetty tekemällä toinen tästä mallista riippumaton rakennemalli, kuten ER-malli. Kahden mallin lähestymisessä on seuraava pulma: malli selittää toiminnan ja rakenteen, mutta näiden mallien vuorovaikutus –siis yhtyeenliittäminen - käy mallien kasvaessa hyvin nopeasti mahdottomaksi.

Oliomalli

Oliomalli on edellisen mallityypin jalostunut muoto (ja muuten kehitettiin juuri eo. ongelman ratkaisemiseksi). Tässä mallissa lähdetään hyvin todellisuusvetoisesti ja todetaan, että todellisuus koostuu hyvin itsenäisistä agenteista (mallissa olioista) näiden keskinäisistä riippuvuuksista ja vuorovaikutuksista. Näin tässä yhdistetään orgaanisesti edellisen kahden mallin tapaukseen verrattuna sekä rakenne että toiminta nyt yhteen malliin. Kun sovelluksen toteutukseen käytetään loogista 3-kerrosjakoa ja toteutus tapahtuu oliokielellä, ollaan tämän hetken tietämyksen kompleksisuusminimissä. Tällä hetkellä voin osoittaa väitteen todeksi Stuart Kauffmania mukaillen.

Tämä on juuri mallilähtöistä sovelluskehitystä. Tähän liittyy ketterä inkrementaalisuus ja generointi luontevina jatkeina.

XLM ei todellakaan riitä simulaationmallien säännöksi, ellei sitten simuloida pelkästään hierarkiarakenteita. Mallit ovat silloin kaikki organisaatiokaavioita ja toiminnallisuutta mallilla ei ole ollenkaan! En myöskään ymmärrä mitenkään mitä tarkoitetaan ”semanttisilla” malleilla. Kuten olen kuvannut muunlaisia todellisuuden malleja EI VOI olla olemassa. Ainoastaan jotain todellista voi yksinkertaistaa!

Tästä syystä aikoinaan perustin OlioOSY:n. Jäin ajatuksineni vähemmistöön ja sitten ehdotin ”nimenmuutosta” MallinnusOSYyn. Minulle koko ajan nämä kaksi ovat käytännössä sama asia.

ja blogini: http://jukkatamminen.wordpress.com/

Oliomalli on ominaisuuksiensa takia kompleksisuusminimissä.