Avoimen tuotteen hallinta monitoimittaja ympäristössä

Transkriptio

1 TUTKIMUSRAPORTTI VTT-CR Avoimen tuotteen hallinta monitoimittaja ympäristössä Kirjoittajat: Luottamuksellisuus: Tapio Matinmikko, Jukka Kääriäinen, Pasi Pussinen Luottamuksellinen Luonnos 0.9

2 2 (30) Raportin nimi Avoimen tuotteen hallinta monitoimittaja ympäristössä Asiakkaan nimi, yhteyshenkilö ja yhteystiedot Asiakkaan viite Valtiovarainministeriö, JulkICT toiminto, KuntaIT, Tommi Oikarinen. PL 28, Aleksanterinkatu VALTIONEUVOSTO GSM: Faksi: Projektin nimi Projektin numero/lyhytnimi KuntaIT Raportin laatija(t) Sivujen/liitesivujen lukumäärä Tapio Matinmikko, Jukka Kääriäinen, Pasi Pussinen 30/ Avainsanat Raportin numero VTT-CR Tiivistelmä Tämä dokumentti kuvaa erilaisia hallintamalleja kuntasektorille yhteisesti kehitettyjen ja levitettävien ohjelmistojen hallintaan. Hallintamallien kehittämisessä on huomioitu avoimen lähdekoodin ja perinteisen tuotteenhallinnan käytäntöjä. Dokumentti koostuu johdantokappaleesta sekä mallikuvauksista. Jokainen malli on kuvattu sekä esitetty mallien hyvät puolet ja haasteet. Liitteissä on kuvattu mallien vertailut, mallien tekemiseen vaikuttaneet tutkimustulokset sekä tutkimusmenetelmä ja tutkimustapa. Dokumentti toimii luonnoksena malleista jatkokeskusteluja varten. Luottamuksellisuus Oulussa Laatija luottamuksellinen Tarkastaja Hyväksyjä Tapio Matinmikko, Senior Scientist Matias Vierimaa Technology Manager VTT:n yhteystiedot Kaitoväylä 1, OULU Jakelu (asiakkaat ja VTT) Valtiovarainministeriö, JulkICT toiminto, KuntaIT VTT Tommi Oikarinen, Neuvotteleva virkamies

3 3 (30) VTT:n nimen käyttäminen mainonnassa tai tämän raportin osittainen julkaiseminen on sallittu vain VTT:ltä saadun kirjallisen luvan perusteella. Sisällysluettelo 1 Johdanto Käsitteistö Vaatimukset tuotteenhallinnan malleille Hallintamallit Malli 0: Vapaa jakelu Kuvaus Hyödyt ja haasteet Malli 1: Lupa/rekisteröinti Kuvaus Hyödyt ja haasteet Malli 2: Yhteisöohjautuva uudelleenkäyttö Kuvaus Hyödyt ja haasteet Malli Variaatio 1: Perusversion toimittaja Kuvaus Variaatio 2: Edunvalvoja Kuvaus Variaatio 3: Vakio perusversio Kuvaus Variaatioiden hyödyt ja haasteet Tutkimuksessa käytetyt lähdeviitteet LIITE 1: Mallien vertailu LIITE 2: Mallien kehittämiseen vaikuttaneet tutkimustulokset LIITE 3: Tutkimuksen toteutustapa... 30

4 4 (30) 1 Johdanto Tämä dokumentti kuvaa erilaisia hallintamalleja kuntasektorille yhteisesti kehitettyjen ja levitettävien ohjelmistojen hallintaan. Hallintamallien kehittämisessä on huomioitu avoimen lähdekoodin ja perinteisen tuotteenhallinnan käytäntöjä. Dokumentti koostuu johdantokappaleesta sekä mallikuvauksista. Jokainen malli on kuvattu sekä esitetty mallien hyvät puolet ja haasteet. Liitteissä on kuvattu mallien vertailut, mallien tekemiseen vaikuttaneet tutkimustulokset sekä tutkimusmenetelmä ja tutkimustapa. Kaupungit ovat yhteistyössä ja KuntaIT:n rahoituksella kehittäneet eri laajuisia ohjelmistoja kuntasektorille hyödynnettäväksi. Toteutusten keskeisenä tavoitteena on ollut ohjelmistojen avoimuus, levitettävyys ja yhteinen jatkokehitys. Kuva 1 esittää lähtötilannetta ja hallittavuuden ongelmaa. Kuvassa Ohjelmistotalo 1 on kehittänyt Kaupunki 3:n toimeksiannosta Rahoittaja 1:n rahoittamana Ohjelmiston X. Esitetyssä tilanteessa Kaupungit 1 ja 2 haluaisivat uudelleenkäyttää Ohjelmiston X ja kehittää sitä eteenpäin. Hallintamallin puuttuminen tällaisessa tilanteessa voi aiheuttaa seuraavanlaisia ongelmia: Jokainen kaupunki tekee oman version sovelluksesta ohjelmistotoimittajansa kanssa. - Kaikki kunnat maksavat samat uudet ominaisuudet sovellukseen, jolloin ei synny säästöjä. - Yhteistyö ja yhteinen kehittäminen päättyy sovelluksen 1.0 version tasolle. Versionhallinta ohjelmistolle on mahdotonta tehdä. Sovelluksen toiminnallisuus, laatu sekä tietoturva eivät kehity kaupunkien toivomaan suuntaan.

5 5 (30) Kaupunki 1 Kaupunki 2 Kaupunki 3 Kaupunki X Rahoittaja 1 Ohjelmisto X Rahoittaja 2 Ohjelmistotalo 1 Ohjelmistotalo 2 Ohjelmistotalo 3 = ovat kehittäneet ensimmäisen version ohjelmistosta = haluavat ottaa ohjelmiston käyttöön ja kehittää sitä eteenpäin Kuva 1: Toimintaympäristön kuvaus. 1.1 Käsitteistö Avoimuudella tarkoitetaan lähdekoodin ja teknisen dokumentoinnin hallintamallin mukaista jakamista. Levitettävyydellä tarkoitetaan ohjelmiston hallintamallin mukaista käyttöoikeutta eri kaupungeissa. Yhteisellä jatkokehityksellä tarkoitetaan kaupunkien ja heidän IT toimittajiensa tekemää ohjelmiston ominaisuuksien jatkokehittämistä siten, että versionhallinta säilyy. Avoimuus, yhteinen jatkokehittäminen ja levitettävyyden hallinta vaatii kuitenkin yhteisesti sovitun toiminnallisen hallintamallin ohjelmistoille. Toiminnallinen hallintamalli tarkoittaa yhteisten toimintatapojen ja sääntöjen luomista tuotteenhallintaan. Tässä dokumentissa esitettävät hallintamallit kuvaavat toimintakonsepteja. Tulevaisuudessa pilotoitavat käytännön tekniset ratkaisut hallintaan konkretisoivat näitä malleja. Tuotteenhallinnalla tarkoitetaan tässä toimia, jotka mahdollistavat ohjelmiston hallitun kehityksen ja kehityksen seurannan. Tällä hetkellä yhteisesti sovittua hallintamallia ei ole kuntasektorilla. Sovellusportaalilla tarkoitetaan uudelleenkäytettävien ohjelmistojen jakelupaikkoja. Portaali voi tarjota työkalut ohjelmistojen jakamiseen, kommunikointiin ja yhteisön koordinointiin. 1.2 Vaatimukset tuotteenhallinnan malleille Tutkimuksessa on määritelty vaatimukset tuotteenhallinnan toiminnallisille hallintamalleille. Kyseisten vaatimusten lähtökohtana ovat olleet ongelma-

6 6 (30) asettelu, kirjallisuus sekä asiantuntijakeskustelut. Vaatimukset on esitetty taulukossa 1. Taulukko 1: Vaatimukset tuotteenhallinnan malleille. ID Req_1 Req_2 Req_3 Req_4 Req_4_1 Req_4_2 Req_4_3 Req_4_4 Vaatimukset Ohjelmiston tulee olla levitettävä ja lähdekoodi pitää olla jaettavissa Mallien tulee tukea tilannetta jossa kaupungeilla on mahdollisuus ottaa käyttöön ohjelmisto valitsemansa toimittajan kanssa: lisäksi ohjelmistolle tulee varmistaa toimitus- ja ylläpitovarmuus ja käyttötuki Mallin on tuettava ohjelmistojen jakamista esimerkiksi yhteisön kautta johon osallistuvat lukuisat toimijat yhtä aikaa, jolloin syntyy ohjelmistojen uudelleenkäyttöä edistävä ekosysteemi. Yhteisölle luodaan toimintaedellytykset ja jäsenet sitoutetaan toimintaan. Mallia hyödyntävän ohjelmiston elinkaari on hallittu monitoimittaja ja monikäyttäjä ympäristössä käyttäen tuotteenhallinnan perusperiaatteita siten että se kehittyy yhteisöä palvelevaan suuntaan. Jakelukanava, jossa on kuvattu ohjelmiston uudelleenkäyttöä varten riittävä dokumentaatio. Julkisen sektorin sovellusportaali. Kommunikaatiotuki yhteisölle, jotta ohjelmistoista voidaan vaihtaa kokemuksia. Muutostenhallinta siten että ohjelmiston ominaisuudet ja laatu kehittyvät kaupunkeja palvelevaan suuntaan. Ohjelmistolla tulee olla luotettava julkaisun hallinta (release management), joka johtaa selkeään release-polkuun, jossa ohjelmiston kehittyminen on koordinoitua. Ensimmäinen vaatimus tarkoittaa myös, että lähdekoodin ja teknisen dokumentoinnin voi saada kaupunki ohjelmistotalonsa kanssa tai pelkkä ohjelmistotalo tilanteessa, jossa se haluaa tutustua koodiin ja dokumentaatioon. Kyseinen avoin toimintatapa helpottaa myös paikallisten, pienten kasvuyritysten osallistumismahdollisuutta julkisen hallinnon toimituksiin (JHS 169, 2009). Tässä dokumentissa esitetyt hallintamallit tarvitsevat toimintaa tukevat rahoitusmallit. Rahoitusmallit riippuvat hallittavasta ohjelmistosta, tuotteenhallintamallista sekä toimijoista. Alustavia rahoitusmalleja on hahmoteltu hallintamalleihin mukaan. 2 Hallintamallit Seuraavissa kappaleissa esitetään hallintamalleja, jotka pyrkivät vastaamaan kappaleessa 1.2 esitettyihin vaatimuksiin. Mallit tuovat kumulatiivisesti avoimen lähdekoodin yhteisöjen ja tuotteenhallinnan ominaisuuksia mukaan ja voidaan siten nähdä toimintamalleina, jotka tuovat asteittain tuotteenhallinnan ominaisuuksia edellisen mallin päälle (Kuva 2).

7 7 (30) Lupa/ rekisteröintikäytännöt Malli 0 Malli 1 Yhteisö, Tuotteenhallinnan elementtejä (jakelupaikka, kommunikaatio) Malli 2 Kuva 2: Hallintamallien peruseroavaisuudet. Tuotteenhallinta (ChM, Release mgm) Malli 3 Ensimmäisenä on esitetty Malli 0, joka kuvaa tämän hetken tilannetta. Tätä mallia voidaan pitää vertailumallina kun verrataan uusia malleja tämän hetkiseen toimintatapaan. Malli 0:a voidaan myös pitää yhtenä hallintamallina. 3 Malli 0: Vapaa jakelu 3.1 Kuvaus Kuva 3 esittää mallia 0, jossa toimintaa ei ole koordinoitu. Pyydettäessä ohjelmisto annetaan uudelleenkäyttöä varten. Mallissa ei ole määritelty yhteisesti mitä dokumentaatiota tulee ohjelmiston luovutustilanteessa antaa uudelleenkäyttävälle osapuolelle, vaan kussakin tapauksessa toimitaan luovuttavan ja vastaanottavan osapuolen sopimuksen mukaan. Vastaanottava kaupunki ohjelmistotalonsa kanssa huolehtii kaupunkikohtaisen ohjelmistoversion muokkaamisesta, ylläpidosta ja käyttötuesta. Ohjelmisto 1 V2 Ohjelmistotalo 1 Kaupunki 1 Ohjelmistotalo 2 Kaupunki 2 Ohjelmistotalo 3 Kaupunki 3 Ohjelmisto 1 V1 Ohjelmisto 1 V3 Kuva 3: Malli 0. Taulukko 2:Mallin piirteet. Ohjelmiston omistajuus Ohjelmiston Ei yhtä omistavaa tahoa vaan kukin kaupunki omistaa sille muodostetun version ohjelmistosta ja saa pyydettäessä jakaa sitä eteenpäin toisille kaupungeille. Ohjelmistoversiot käytettävissä eri kaupungeille.

8 8 (30) lisenssointiehdot Toimijat Toiminnan rahoitus Ulkopuoliset rahoittajat (esimerkiksi KuntaIT): ei roolia mallissa Kaupungit: ohjelmistojen tilaajia ja käyttäjiä (uudelleenkäyttö räätälöinti) Ohjelmistotalot: kehittävät ja räätälöivät ohjelmistoa kaupunkien tilauksesta Kukin kaupunki rahoittajansa kanssa rahoittavat oman ohjelmistoversionsa kehittämisen/räätälöinnin sekä käyttöönoton. Ei ole yhteisöä. Uudelleenkäyttöyhteisön rooli ja rakenne Ohjelmiston Ohjelmisto voi olla tietyllä kaupungilla, jakelupaikka ohjelmistotalolla tai rahoittajalla. Uudelleenkäyttö Kaupungit voivat uudelleen käyttää toistensa ohjelmistoja, koska kukin kaupunki on velvoitettu luovuttamaan ohjelmiston sitä pyydettäessä. Muutostenhallinta Ohjelmistojen kehittyminen Kukin kaupunki ohjelmistotoimittajansa kanssa sopivat muutoksista ohjelmistoon. Ohjelmistot kehittyvät asteittain kunkin kaupungin tarpeiden pohjalta ilman yhteistä suunnitelmaa. 3.2 Hyödyt ja haasteet Seuraavassa taulukossa on lueteltuna tähän mallin tunnistettuja hyötyjä ja haasteita. Hyödyt Mahdollistaa nopean aloituksen toiminnalle Taulukko 3: Mallin hyödyt ja haasteet. Yksinkertaisuus: ei tarvita tuotteenhallintaan juurikaan organisointia, käytäntöjä tai resursseja Muokattavuus: jokainen kaupunki tekee oman version ohjelmistosta oman IT toimittajan kanssa - Haasteet - Mahdolliset päällekkäisyydet: kunta mahdollisesti maksaa samat uudet ominaisuudet eikä käytännössä mitään säästöjä synny vaan päinvastoin - Kuntien yhteistyö kehittämisessä riippuu heistä itsestään, eikä sitä ole koordinoitu tai keskitetty. Ohjelmiston tilasta ei ole kokonaisnäkemystä eikä edes tietoa keskitetysti vaan se on hajaantunut eri toimijoille (tiedon/kokemusten jakaminen on vaikeaa) - Ei mahdollista todellista ohjelmistojen uudelleenkäyttöä, koska ei ole keskitettyä paikkaa mihin ohjelmistotietoja talletetaan ja josta niitä voi etsiä. - - Ohjelmiston elinkaaren aikainen kehittyminen ei ole hallinnassa (muutosten hallinta, versioituminen) vaan ohjelmisto alkaa elämään erilaisina versioina/variantteina kentällä Ensimmäisen version jälkeen vaarana lukkiutuminen yhteen ohjelmistotoimittajaan

9 9 (30) - Ei ole määritelty/ohjeistettu mitä tietoja ohjelmistosta tulee antaa luovutettaessa sitä, jolloin uudelleenkäyttö vaikeaa. Välttämättä kaikkea uudelleenkäyttöä varten tarvittavaa dokumentaatiota ei edes ole olemassa. 4 Malli 1: Lupa/rekisteröinti 4.1 Kuvaus Kuva 4 esittää mallia 1. Pyydettäessä ohjelmisto annetaan uudelleenkäyttöä varten rahoittajan luvalla sovitun dokumentaation kanssa. Vastaanottava kaupunki ohjelmistotalonsa kanssa huolehtii kaupunkikohtaisen ohjelmiston muokkaamisesta, ylläpidosta ja käyttötuesta. Lupa koordinoi sitä kuka käyttää ohjelmistoa, joka erottaa tämän mallin mallista 0. Tällöin tallennetaan tietoa kuka käyttää kyseistä ohjelmistoa ja siten voidaan esimerkiksi kysyä käyttökokemuksia ja käyttökohteita ohjelmistosta Ohjelmistotalo 1 Kaupunki 1 Ohjelmistotalo 2 Kaupunki 2 Luovuttaa uudelleenkäyttöä varten Ottaa Lupa/rekisteröinti rahoittajalta Ohjelmisto 1 Ohjelmistokohtainen tietovarasto Kuva 4: Malli 1. Ohjelmiston omistajuus Ohjelmiston lisenssointiehdot Taulukko 4: Mallin piirteet Ei yhtä omistavaa tahoa vaan kukin kaupunki omistaa sille muodostetun version ohjelmistosta ja saa jakaa sitä eteenpäin toisille kaupungeille rahoittajan luvalla. Ohjelmistoversiot käytettävissä eri kaupungeille rahoittajan luvalla. Määriteltynä lisenssiehdot, jotka estävät tuotteen sulkemisen kun sitä uudelleenkäytetään. Toimijat Ulkopuoliset rahoittajat: luvanantaja

10 10 (30) Toiminnan rahoitus Uudelleenkäyttöyhteisön rooli ja rakenne Ohjelmiston jakelupaikka Kaupungit: ohjelmistojen tilaajia ja käyttäjiä (uudelleenkäyttö räätälöinti) Ohjelmistotalot: kehittävät ja räätälöivät ohjelmistoa kaupunkien tilauksesta. Kehitys / räätälöinti: kukin kaupunki rahoittajansa kanssa rahoittavat oman ohjelmistoversion kehittämisen/räätälöinnin sekä käyttöönoton. Lupa/rekisteröinti: rahoittaja huolehtii lupa/rekisteröintimenettelyn rahoituksesta. Ei yhteisöä. Rahoittaja voi tehdä pientä koordinointia, koska voi hallinnoida tietoa kelle ohjelmisto on mennyt. Ohjelmisto sen lähdekoodi ja tarvittava dokumentaatio ovat jossakin ohjelmistokohtaisessa jakelupaikassa, josta sen saa lupaa vastaan: ohjelmisto voi olla tietyllä kaupungilla, ohjelmistotalolla tai rahoittajalla. Kuitenkin toimitus- ja ylläpitovarmuuden varmistamiseksi lähdekoodi tulisi olla osapuolella, jolta kaupunki voi sen saada, mikäli toimittajan kanssa tehtävässä yhteistyössä ilmenee ongelmia. Uudelleenkäyttö Kaupungit voivat uudelleen käyttää toistensa ohjelmistoja rahoittajan luvalla, mutta ovat velvoitettuja antamaan muokatun ohjelmiston toiselle uudelleenkäyttöluvan saaneelle kaupungille. Muutostenhallinta Ohjelmistojen kehittyminen Kukin kaupunki ohjelmistotoimittajansa kanssa sopivat muutoksista ohjelmistoon. Ohjelmistot kehittyvät asteittain kunkin kaupungin tarpeiden pohjalta ilman yhteistä suunnitelmaa 4.2 Hyödyt ja haasteet Seuraavassa taulukossa on lueteltuna tähän mallin tunnistettuja hyötyjä ja haasteita. Hyödyt Mahdollistaa nopean aloituksen toiminnalle Taulukko 5: mallin hyödyt ja haasteet. Yksinkertaisuus: ei tarvita tuotteenhallintaan juurikaan organisointia ja käytäntöjä Muokattavuus: jokainen kaupunki tekee oman version uudelleen käytettävästä ohjelmistosta oman IT toimittajan kanssa - Lupakäytännöt ohjelmiston käyttöön, joten rahoittajalle jää tieto kelle Haasteet - Mahdolliset päällekkäisyydet: jokainen kunta maksaa samat uudet ominaisuudet eikä käytännössä mitään säästöjä synny vaan päinvastoin - Kuntien yhteistyö kehittämisessä riippuu heistä itsestään, eikä sitä ole koordinoitu - tai keskitetty Eri ohjelmistoista, niiden tilasta ja omistajuudesta ei ole kokonaisnäkemystä eikä edes tietoa keskitetysti vaan se on hajaantunut eri toimijoille (tiedon/kokemusten jakaminen on vaikeaa) Ei mahdollista todellista ohjelmistojen uudelleenkäyttöä, koska ei ole keskitettyä

11 11 (30) ohjelmisto on mennyt. Mahdollistaa kevyen koordinoinnin Dokumentaatio, joka pitää jakaa uudelleenkäytettäessä ohjelmistoa, on määritelty. Tämä helpottaa - uudelleenkäyttöä. paikkaa mihin ohjelmistotietoja talletetaan ja josta niitä voi etsiä. Ohjelmiston elinkaaren aikainen kehittyminen ei ole hallinnassa (muutosten hallinta, versioituminen) vaan ohjelmisto alkaa elämään erilaisina versioina/variantteina kentällä - Vaarana on ensimmäisen version jälkeen lukkiutuminen yhteen ohjelmistotoimittajaan ja sen tarjoamaan ylläpitoon ja päivityksiin. 5 Malli 2: Yhteisöohjautuva uudelleenkäyttö 5.1 Kuvaus Ohjelmistotalo 1 Kaupunki 1 Ohjelmisto 1 K3 Ohjelmistotalo 3 Kaupunki 3 Takaisin yhteisön kantaan Ohjelmistotalo 2 Kaupunki 2 Takaisin yhteisön kantaan Ohjelmisto 1 K2 Ohjelmisto 1 K1 Sovellusportaali Lähdekoodi ja dokumentaatio Lupa rahoittajalta Yhteisö Kuva 5 esittää mallia 2. Rahoittajat ja kaupungit muodostavat yhdessä yhteisön, jonka kautta ohjelmistojen uudelleenkäyttö tapahtuu. Yhteisöllä on uudelleenkäytettävälle ohjelmistolle yksi jakelupaikka (esimerkiksi sovellusportaali ). Yhteisöön kuuluva kaupunki luovuttaa ja dokumentoi ohjelmiston kaikkine uudelleenkäyttöä varten tarvittavine tietoineen sovellusportaaliin. Tästä jakelupaikasta voivat muut kaupungit etsiä jaettavana olevia ohjelmistoja, tietoja ja käyttökokemuksia ohjelmistoista sekä osallistua ohjelmistoihin liittyviin keskusteluihin. Uudelleenkäyttävä kaupunki pyytää lupaa ohjelmiston rahoittajalta uudelleenkäyttöä varten ja luvan saatuaan lataa ohjelmiston lähdekoodeineen ja dokumentaatioineen uudelleenkäyttöä varten. Kaupunki luovuttaa materiaalin omalle ohjelmistotoimittajalleen, joka räätälöi ohjelmiston kohdekaupunkiin sopivaksi ja lisää tarvittaessa toiminnallisuuksia, jotka ohjelmistosta puuttuu. Näin muodostettu kaupunkikohtainen ohjelmistoversio luovutetaan sovellusportaaliin edelleen uudelleenkäytettäväksi kaikkine tarvittine dokumentteineen ja tietoineen.

12 12 (30) Ohjelmistotalo 1 Kaupunki 1 Ohjelmisto 1 K3 Ohjelmistotalo 3 Kaupunki 3 Takaisin yhteisön kantaan Ohjelmistotalo 2 Kaupunki 2 Takaisin yhteisön kantaan Ohjelmisto 1 K2 Ohjelmisto 1 K1 Sovellusportaali Yhteisö Lähdekoodi ja dokumentaatio Kuva 5: Malli 2. Lupa rahoittajalta Taulukko 6: Mallin piirteet. Ohjelmiston omistajuus Ohjelmiston lisenssointiehdot Yhteisö omistaa jaettavana olevat ohjelmistot. Ohjelmistoversiot ovat käytettävissä eri kaupungeille rahoittajan luvalla. Määriteltynä lisenssiehdot, jotka estävät tuotteen sulkemisen kun sitä uudelleenkäytetään. Toimijat Ulkopuoliset rahoittajat: luvanantaja. Toimivat yhteisössä. Kaupungit: ohjelmistojen tilaajia ja käyttäjiä. Toimivat yhteisössä. Ohjelmistotalot: kehittävät ja räätälöivät ohjelmistoa kaupunkien tilauksesta. Toiminnan rahoitus Uudelleenkäyttöyhteisön rooli ja rakenne Ohjelmiston jakelupaikka Kehitys / räätälöinti: kukin kaupunki rahoittajansa kanssa rahoittavat oman ohjelmistoversion kehittämisen/räätälöinnin. Lupa / rekisteröinti: rahoittaja huolehtii lupa/rekisteröintimenettelyn rahoituksesta. Yhteisö: yhteisön toiminnan ja jakelupaikan ylläpitotahon rahoitus: Hallintamaksu/ylläpitomaksu kaupungeille, ulkopuolisten rahoittajien mahdollinen rooli. Yhteisö koostuu kaupungeista ja rahoittajista. Yhteisöllä on ohjelmistojen ja jakeluun sekä siihen liittyvään yhteisötoimintaan tarvittava jakelupaikka sovellusportaali. Yhteisö määrittelee mitä tietoja ohjelmistoista on jaettava.

13 13 (30) Uudelleenkäyttö Kaupungit voivat uudelleenkäyttää toistensa ohjelmistoja rahoittajan luvalla, mutta ovat velvoitettuja palauttamaan muokatun ohjelmiston sovittuine dokumentaatioineen uudelleenkäyttöä varten yhteisölle. Muutostenhallinta Kukin kaupunki ohjelmistotoimittajansa kanssa sopivat muutoksista ohjelmistoon (ei koordinoitua muutostenhallintaa sovellusportaalissa jaettaville Ohjelmistojen kehittyminen ohjelmistoille). Ohjelmistot kehittyvät asteittain kukin kaupungin tarpeiden pohjalta ilman yhteistä suunnitelmaa. Toisaalta yhteisö tarjoaa keskusteluyhteyden ja siten mahdollistaa yhteistyön ohjelmistojen ja suunnitteluun liittyen. 5.2 Hyödyt ja haasteet Seuraavassa taulukossa on lueteltuna tähän mallin tunnistettuja hyötyjä ja haasteita. Taulukko 7: mallin hyödyt ja haasteet. Hyödyt Ei tarvetta organisoida ja rahoittaa tuotteenhallintaa Muokattavuus: jokainen kaupunki tekee oman version ohjelmistosta oman IT toimittajan kanssa. Ylläpidettävyys. Ohjelmistoista on tietoa keskitetysti yhteisön jakelukanavassa (portaali). Yhteisö tuottaa yhteisen ohjelmistojen jakelukanavan jota kautta voidaan hakea ohjelmistoista kaupunkien tarpeisiin (ei mahdollista aikaisemmin). Toimitus- ja ylläpitovarmuus on varmistettu, koska lähdekoodi ja tarvittava dokumentaatio ovat saatavilla yhteisölle. Jakelukanava toimii kaupunkien ja rahoittajien (esim Kunta IT) muodostaman yhteisön kommunikointikanavana, jonka kautta voidaan tietoa saatavilla olevista ohjelmistoista ja niihin liittyvistä kokemuksista jakaa. Yhteisö tarjoaa kanavan ominaisuuksien suunnitteluun ja kokemusten jakamiseen. Avoimien ohjelmistojen parhaita tietolähteitä ovat toiset samaa ohjelmistoa käyttävät organisaatiot (JHS 169, 2009). Haasteet Mahdollistaa edelleen päällekkäisyydet: ohjelmiston elinkaaren aikainen kehittyminen ei ole koordinoitua: eri - kaupungit saattavat ostaa samat ominaisuudet (haaroittuminen eri kehityspoluiksi) - Ohjelmistolla ei ole selkeää tahoa joka huolehtii sen kehittymisestä yhteisöä - palvelevaan suuntaan Vaatii ohjelmistot ja käytännöt jakelukanavan ja yhteisön toimintaan tuotteenhallintaa varten sekä ylläpidon => hyödyt vs. kustannukset kaupungeille ja rahoittajille. Yhteisön jakelukanavan ylläpitäjätaho tulee olla määriteltynä ja tahon toiminta rahoitettuna. - Toiminnan koordinointi ja ohjaaminen yhteisöä palvelevaan suuntaan on vaikeaa: malli ja toimintatavat mahdollistavat sekavan toiminnan - Ohjelmiston elinkaaren aikainen kehittyminen ei ole hallinnassa (muutosten hallinta, versioituminen) vaan ohjelmisto alkaa elämään erilaisina versioina kentällä

14 14 (30) - Rahoitusmalli haasteellinen yhteisön toiminnalle, koska ei ole yhtä toimijaa joka ottaa kokonaisvastuun jakelukanavasta => mahdollisuuksia: hallintamaksu / ylläpitomaksu kaupungeille. Yhteisö tarvitsee johtajan (ulkopuoliset rahoittajat). - Ensimmäisen version jälkeen riskinä lukkiutuminen yhteen toimittajaan ja tämän tekemiin päivityksiin ja ylläpitoon, koska ei ole yhtenäistä elinkaarenhallintaa - Yhteisössä toimiminen vie resursseja (aika / raha). Motivaatio kaupungeilla kontribuoida oma versionsa yhteisölle ja osallistua yhteisön toimintaan. 6 Malli Variaatio 1: Perusversion toimittaja Malli 3:sta esitetään 3 variaatiota, joiden ominaisuuksia voidaan myös yhdistellä Kuvaus Kuva 6 esittää variaatiota 1. Rahoittajat ja kaupungit muodostavat yhdessä yhteisön, jonka kautta ohjelmistojen uudelleenkäyttö tapahtuu. Yhteisöllä on uudelleenkäytettävälle ohjelmistolle yksi jakelupaikka (esimerkiksi sovellusportaali ). Sovellusportaalissa on kaupunkikohtaiset ohjelmistoversiot sekä ylläpidettävä ohjelmiston perusversio. Tästä jakelupaikasta voivat muut kaupungit etsiä jaettavana olevia ohjelmistoja, tietoja ja käyttökokemuksia ohjelmistoista sekä osallistua ohjelmistoihin liittyviin keskusteluihin. Ohjelmiston perusversion kehittämisestä vastaa ohjelmistotalo, joka on kehittänyt ensimmäisen version ohjelmistosta. Kaupungit uudelleenkäyttävät perusversiota tai joissakin tapauksissa kaupunkikohtaisia versioita, jotka on talletettu sovellusportaaliin. Uudelleenkäyttävä kaupunki pyytää lupaa ohjelmiston rahoittajalta uudelleenkäyttöä varten ja luvan saatuaan lataa ohjelmiston lähdekoodeineen ja dokumentaatioineen uudelleenkäyttöä varten. Kaupunki luovuttaa materiaalin omalle ohjelmistotoimittajalleen, joka räätälöi ohjelmiston kohdekaupunkiin sopivaksi ja lisää tarvittaessa toiminnallisuuksia, jotka ohjelmistosta puuttuu. Näin muodostettu kaupunkikohtainen ohjelmistoversio luovutetaan sovellusportaaliin edelleen uudelleenkäytettäväksi kaikkine tarvittavine dokumentteineen ja tietoineen ja soveltuvin osin integroitavaksi seuraavaan ohjelmiston perusversioon. Ohjelmiston perusversio kehittyy versioidun vaihemallin (Rajlich & Benneth, 2000)(Kuva 7) mukaisesti siten, että sille muodostuu lineaarinen versiopolku, jossa viimeisin perusversio on pohjana seuraavalle versiolle. Kukin kaupunki huolehtii oman ohjelmistotoimittajan kanssa oman perusversioon pohjautuvan ohjelmistoversionsa ylläpidosta. Perusversiota kehitetään yhteisön muutosten ja julkaisujen hallinnan käytäntöjen mukaan siten, että se kehittyisi yhteisöä palvelevaan suuntaan. Tällöin esimerkiksi havaitut virheet ohjelmistossa voidaan korjata perusversioon ja näin yhteisen perusversion laatu paranee. Mallissa integroinnin rahoitus on haasteellinen.

15 15 (30) Ohjelmistotalo 2 Kaupunki 2 Ohjelmistotalo 3 Kaupunki 3 Ottaa Vie takaisin yhteisön kantaan integrointiin Ohjelmisto 1 V2 Vie takaisin yhteisön kantaan integrointiin Ottaa Lupa Rahoittajalta/yhteisöltä Ohjelmisto 1 V1 Ohjelmistotalo 1 (Integraattori) Sovellusportaali Yhteisö Lähdekoodi ja dokumentaatio Kuva 6: Malli 3:Variaatio 1. Kuva 7: Malli 3:n liittyminen versioituun vaihemalliin. Ohjelmiston omistajuus Ohjelmiston lisenssointiehdot Taulukko 8: Mallin piirteet. Yhteisö omistaa jaettavana olevat versiot sekä kehitettävän perusversion ohjelmistosta. Ohjelmistoversiot ovat käytettävissä eri kaupungeille rahoittajan luvalla. Määriteltynä lisenssiehdot, jotka estävät tuotteen sulkemisen kun sitä uudelleenkäytetään. Toimijat Ulkopuoliset rahoittajat: luvanantaja. Toimivat yhteisössä. Kaupungit: ohjelmistojen tilaajia ja käyttäjiä. Toimivat yhteisössä.

16 16 (30) Toiminnan rahoitus Uudelleenkäyttöyhteisön rooli ja rakenne Ohjelmiston jakelupaikka Ohjelmistotalot: räätälöivät ohjelmistoa kaupunkien tilauksesta sekä toimivat tuottamansa perusversion ylläpitäjinä Kehitys / räätälöinti: kukin kaupunki rahoittajansa kanssa rahoittavat oman ohjelmistoversion kehittämisen/räätälöinnin. Lupa / rekisteröinti: rahoittaja huolehtii lupa/rekisteröintimenettelyn rahoituksesta. Yhteisö: yhteisön toiminnan ja jakelupaikan ylläpitotahon rahoitus: Hallintamaksu/ylläpitomaksu kaupungeille, ulkopuolisten rahoittajien mahdollinen rooli. Integraattorin rahoitus: mahdollisuuksia: osallistumismaksu yhteisössä toimiville kaupungeille, käyttömaksu yhteisön ohjelmistoista. Yhteisö koostuu kaupungeista ja rahoittajista. Lisäksi ohjelmistotalot toimivat integraattorin roolissa yhteisön päätösten mukaisesti. Yhteisöllä on ohjelmistojen ja jakeluun sekä siihen liittyvään yhteisötoimintaan tarvittava jakelupaikka sovellusportaali. Yhteisö määrittelee mitä tietoja ohjelmistoista on jaettava. Uudelleenkäyttö Kaupungit voivat uudelleenkäyttää toistensa ohjelmistoja rahoittajan luvalla, mutta ovat velvoitettuja palauttamaan muokatun ohjelmiston sovittuine dokumentaatioineen uudelleenkäyttöä varten yhteisölle. Integraattorina toimiva ohjelmistotalo integroi yhteisön sopimat muutokset ylläpidettyyn perusversioon. Muutostenhallinta Yhteisön määrittelemät muutostenhallinnan käytännöt ja vastuut (koordinoitu muutostenhallinta). Ohjelmistojen kehittyminen yhteisö päättää jokaiseen julkaisuun (release) tulevat ominaisuudet ja toteuttaa ne ylläpitäjien (integraattori) kanssa. Ohjelmistojen perusversiot kehittyvät asteittain kaupunkeja palvelevaan suuntaan (yhteinen jatkokehitys). Yhteisö tarjoaa keskusteluyhteyden ja siten mahdollistaa yhteistyön ohjelmistojen ja suunnitteluun liittyen kaupungeille. 6.2 Variaatio 2: Edunvalvoja Kuvaus Kuva 8 esittää variaatiota 2, joka on samanlainen kuin edellinen variaatio. Tässä variaatiossa toimii erillinen edunvalvoja -osapuoli integraattorina yhden tai useamman ohjelmiston osalta. Tämä edunvalvoja ei välttämättä ole ohjelmiston

17 17 (30) ensimmäisen version muodostaja, vaan jokin ohjelmistotalo tai projektin eri osapuolten toiminnan koordinointiin erikoistunut muu taho. Myös integraation toteutus voi olla ulkoistettu kolmannelle osapuolelle, jonka toimintaa myös edunvalvoja valvoo rahoittajan/yhteisön etujen mukaisesti. Etuina tässä mallissa on, että on määritelty keskitetty vastuu rahoittajan/yhteisön toimeksiantona koko toiminnan hallinta, valvonta- ja ohjaustehtäviin (vrt. Takanen, 2005). Siten vastuu hallinnasta sekä jakelukanavan hoitamisesta on yhdellä taholla: selkeys, valvonta. Haasteena on, että edunvalvoja -osapuolella ei ole välttämättä tarvittavaa kompetenssia muutosten arviointiin, integrointiin ja testaamiseen, koska he eivät ole sama osapuoli joka on kehittänyt ensimmäisen version (vrt. Rajlich & Benneth, 2000). Samoin edunvalvonnan ja integroinnin rahoitus ei ole mallissa ratkaistu. Ohjelmistotalo 2 Kaupunki 2 Ohjelmistotalo 3 Kaupunki 3 Ottaa Vie takaisin yhteisön kantaan integrointiin Ohjelmisto 1 V2 Vie takaisin yhteisön kantaan integrointiin Ottaa Lupa Rahoittajalta/yhteisöltä Ohjelmisto 1 V1 Edunvalvoja Sovellusportaali Yhteisö Lähdekoodi ja dokumentaatio Kuva 8: Malli 3: Variaatio Variaatio 3: Vakio perusversio Kuvaus Kuva 9 esittää variaatiota 3. Se poikkeaa variaatioista 1 ja 2 siten, että ohjelmistosta toteutetaan yhteisön määrittelemänä ja rahoittamana uusi versio. Siten kaupungit eivät tässä variaatiossa rahoita suoraan omia toiminnallisuuksia vaan kaikki rahoittavat uutta perusversiota. Malli korostaa perusversion merkitystä. Pyrkimyksenä on päästä yhteiseen perusversioon, jossa ei tarvita kaupunkikohtaista räätälöintiä vaan kaikki investoivat yhteiseen versioon, joka sovitetaan sellaisenaan kaupungin tarpeisiin. Toteuttajaksi voidaan valita yhteisöön kuuluvan kaupungin ohjelmistotalo (perusversion tuottaja tai joku muu ohjelmistotalo). Tässä variaatiossa on myös mahdollista, että yksi osapuoli valitaan toimeksiantona edunvalvojaksi rahoittajien/yhteisön intressien varmistamiseksi. Etuina tässä toimintamallissa on se, että integroinnin rahoitus on helpommin ratkaistavissa ja periaatteessa toimintamalli on yksinkertainen. Toimintatavassa tulee kuitenkin huomioida uuden version toteuttajan valinta, esimerkiksi kilpailutuksella. Mallissa myös kustannusten jakaminen uuden

18 18 (30) version toteutuksessa on ratkaistava: esimerkiksi toimimalla tasajaon tai kunnan koon mukaan. Ohjelmistotalo 2 Kaupunki 2 Ohjelmistotalo 3 Kaupunki 3 Ottaa Ehdottaa ja rahoittaa uusia ominaisuuksia Ohjelmisto 1 V2 Ohjelmisto 1 V1 Ehdottaa ja rahoittaa uusia ominai suuksia Ottaa Lupa Rahoittajalta/yhteisöltä Sovellusportaali Yhteisö Lähdekoodi ja dokumentaatio Ohjelmistotalo x Toteuttaa uuden version Kuva 9: Malli 3: Variaatio Variaatioiden hyödyt ja haasteet Seuraavassa taulukossa on lueteltuna mallin 3 variaatioihin tunnistettuja hyötyjä ja haasteita. Taulukko 9: mallin hyödyt ja haasteet. Hyödyt Muokattavuus: jokainen kaupunki tekee oman version ohjelmistosta oman IT toimittajan kanssa Perusversiota ja sen kehittymistä hallinnoi tuotteenhallinnan näkökulmasta sama taho, joka on kehittänyt ensimmäisen version => hyvä ymmärrys ohjelmistosta muutosten integroimista varten (domain osaaminen) (Rajlich & Benneth, 2000) (Variaatio 1) Mahdollistaa ohjelmiston uudelleenkäytön: ohjelmisto on saatavilla eri kaupungeille läpi sen elinkaaren ja se kehittyy ja versioituu koordinoidusti (JHS 169, 2009), tämä on mahdollista yhteisön toimesta Portaali toimii kaupunkien ja rahoittajien muodostaman yhteisön kommunikointikanavana, jonka kautta voidaan hankkia tietoa saatavilla olevista ohjelmistoista ja niihin Haasteet Perusversion ylläpito voidaan lukitaan mahdollisesti pitkäksikin aikaa yhteen ohjelmistotoimittajaan: riippuvuus - ohjelmistotoimittajasta ja sen kyvystä toimia luotettavasti ja pitkäjänteisesti => kuinka varmistutaan toimittajan kyvykkyydestä hallintaan Vaatii ohjelmistot ja käytännöt jakelukanavan ja yhteisön toimintaan tuotteenhallintaa varten sekä ylläpidon => hyödyt vs. kustannukset kaupungeille ja rahoittajalle Yhteisön tuotteenhallinta mahdollisesti hajaantuu eri ohjelmistojen osalta eri tahoille ja näin ollen osaaminen tuotteenhallintaan liittyen ei kumuloidu yksittäiselle taholle Rahoitusmalli yhteisön toiminnalle koska ei ole yhtä toimijaa joka ottaa kokonaisvastuun hallinnasta sekä jakelukanavasta => mahdollisuuksia: Hallintamaksu/ylläpitomaksu

19 19 (30) liittyvistä kokemuksista Yhteisö vastaa perusversioiden elinkaarenhallinasta, ja integraattori (esimerkiksi perusversion toimittaja) toteuttaa muutokset yhteisön vaatimusten mukaisesti. Perusversiot ovat saatavilla yhteisön kautta ja ohjelmiston ominaisuudet ovat dokumentoitu läpi elinkaaren. Yhteisön osaamisen hyödyntäminen on mahdollista. Yhteistyön tekeminen muiden kaupunkien kanssa esimerkiksi ominaisuuksien suunnittelussa, kokemusten jakamisessa ja ohjelmistojen levittämisessä. Kaupungeilla mahdollisuus vaikuttaa ohjelmiston elinkaareen yhteisön kautta. - - kaupungeille. Yhteisö tarvitsee selkeät roolitukset ja vastuut sekä johtajan. Yhteisössä toimiminen vie resursseja (aika / raha). Motivaatio kaupungeilla kontribuoida oma versionsa yhteisölle. Miten rahoitetaan integraattorin/edunvalvojan toiminta? Mahdollisuuksia: osallistumismaksu yhteisöön, käyttömaksu yhteisön ohjelmistoista.

20 20 (30) Tutkimuksessa käytetyt lähdeviitteet Asklund, U., Bendix, L. (2002) A study of configuration management in open source software projects. IEE Proceedings of Software Engineering 149(1): Capiluppi, A., González-Barahona, J., Herraiz, I., Robles, G. (2007) Adapting the Staged Model for Software Evolution to Free/Libre/Open Source Software, IWPSE 07 September 3-4, 2007, Dubrovnik, Croatia. Chappell, D. (2008) What is application lifecycle management, Chappell & Associates, White paper. Clements, P., Northrop, L. (2002) Software product lines practices and patterns, Addison-Wesley. Dahlander, L. (2007) Penguin in a new suit: a tale of how de novo entrants emerged to harness free and open source software communities, Industrial and corporate change, vol. 16, no. 5, pp Erenkrantz, J. (2003) Release Management Within Open Source Projects, 3rd Workshop on Open Source Software Engineering, ICSE 03, International Conference on Software Engineering, Portland, Oregon, May 3-11, Eskeli, J., Heinonen, S., Matinmikko, T., Parviainen, P., Pussinen, P. (2010) Challenges and Alternative solutions for ERP's, VTT, Oulu. 55 p. Research report : VTT-R , Estublier, J., Leblang, D., van der Hoek, A., Conradi, R., Clemm, G., Tichy, W. and Wiborg-Weber, D. (2005) Impact of software engineering research on the practice of software configuration management, ACM Transactions on Software Engineering and Methodology (TOSEM), Vol. 14, No. 4, October 2005, pp Göthe, M., Pampino, C., Monson, P., Nizami, K., Patel, K., Smith, B. and Yuce, N. (2008) Collaborative Application Lifecycle Management with IBM Rational Products, An IBM Redbooks publication, December IEEE Std-828. (2005) IEEE Standard For Software Configuration Management Plans. IEEE Std (Revision of IEEE Std ). JHS 169. (2009) Avoimen lähdekoodin ohjelmien käyttö julkisessa hallinnossa, Julkisen hallinnon tietohallinnon neuvottelukunta, Versio 1.0, Jonassen Hass, A. (2003) Configuration Management Principles and Practice, Addison Wesley. Lattemann, C., Stieglitz, S. (2005) Framework for Governance in Open Source Communities Conditions for Governance in Open, Proceeding of the 33th Hawaii International Conference on System Sciences 2005.

21 21 (30) Leon, A. (2000) A Guide to Software Configuration Management, Artech House, Boston. Puolustustaloudellinen suunnittelukunta. (2005) Viestintäverkkojen ja viestintäpalvelujen varmistaminen: opas käyttäjälle, Tietoyhteiskuntasektori, Tietoverkkopooli. Rajlich, V., Bennett, K. (2000) A staged model for the software life cycle, Computer, July/2000. Rossberg, J. (2008) Pro Visual Studio Team System: Application Lifecycle Management, Apress; 1 edition, 344 p. Takanen, S. (2005) Monitoimittajaprojektin hallinta, Systeemityö 2/2005. Weiß, G., Pomberger, G., Beer, W., Buchgeher, G., Dorninger, B., Pichler, J., Prähofer, H., Ramler, R., Stallinger, F. and Weinreich, R. (2009) Software engineering processes and tools, In: Hagenberg Research, Eds.: Buchberger, B., Affenzeller, M., Ferscha, A., Haller, M., Jebelean, T., Klement, E.P., Paule, P., Pomberger, G., Schreiner, W., Stubenrauch, R., Wagner, R., Weiß, G. and Windsteiger, W., Springer-Verlag, Berlin, Heidelberg, pp Wesselius, J. (2008) The Bazaar inside the Cathedral: Business Models for Internal Markets, IEEE Software, pp , May/June, West, J. (2005) Contrasting Community Building in Sponsored and Community Founded Open Source Projects, Proceeding of the 33th Hawaii International Conference on System Sciences 2005.

22 22 (30) LIITE 1: Mallien vertailu Oheinen Taulukko 10 kuvaa miten muodostetut mallit vastaavat kappaleessa 1.2 kuvattuihin vaatimuksiin. Eri mallien tunnuspiirteitä ovat: Malli 1: Useita versioita sovelluksesta, ei yhtä jakelupaikkaa, ei systemaattista tuotteenhallintaa, ei yhteisöä, koordinoitu jakelu. Malli 2: Useita versioita sovelluksesta, yhteinen jakelupaikka, tuotteenhallinnan piirteitä, yhteisö, koordinoitu jakelu. Malli 3 variaatioineen: Yksi versio/kehityshaara sovelluksesta aina saatavilla, yksi jakelupaikka, yhteisö, perusversio kehittyy hallitusti. Taulukko 10:Mallien vertailu.

23 23 (30) LIITE 2: Mallien kehittämiseen vaikuttaneet tutkimustulokset Avoin lähdekoodi ja yhteisöt Avoimella lähdekoodilla (eng. Free/Open Source Software FOSS tai OSS) tarkoitetaan ohjelmistoja, joiden lähdekoodi on kaikkien vapaasti luettavissa. Avoimuus syntyy ohjelmistolisenssistä, joiden alaisina ohjelmistoja julkaistaan. Tunnetuimpia avoimen lähdekoodin lisenssejä ovat GPL (GNU General Public License) ja BSD (Berkley Software Distribution. Avoimen lähdekoodin ohjelmistojen levittämistä säädetään lisenssien ominaisuuksilla (eng. copyleft), sillä osa lisensseistä vaatii kaikki muutokset ja lisäykset koodiin palautettavaksi takaisin samalla avoimella lisenssillä (esim. GPL). Jopa linkittäminen toiseen ohjelmaan voi tartuttaa lisenssin. Toiset lisenssit taas antavat vapaat kädet muokata lähdekoodia ja tehdä siitä esimerkiksi suljettuja, kaupallisen lisenssin ohjelmistoja (esim. BSD-lisenssi). Historiallisesti avointa lähdekoodia on ollut olemassa yhtä kauan kuin tietokoneohjelmia on tuotettu. Erityisesti kotitietokoneiden aikakauden alussa avointa lähdekoodia tuotettiin paljon yliopistoissa ja tutkimuslaitoksissa, sillä kaupallista tai suljettua ohjelmistotuotantoa ei ollut tarjolla. Avoimen lähdekoodin ohjelmistoihin liittyy oleellisesti yhteisöt, joissa yksittäiset ohjelmoijat sekä myös organisaatiot osallistuvat avoimeen ohjelmistokehitykseen projektiluontoisesti. Yhteisöt toimivat Internetin välityksellä ja tuottavat ohjelmistoja perustuen lähinnä yhteisön jäsenten omiin tarpeisiin. Yhteisön jäsenet eivät lähtökohtaisesti saa palkkaa tai muuta rahallista korvausta toiminnastaan, toiminta perustuu pitkälti vapaaehtoisuuteen. Yhteisöjen toimivat haasteellisessa ympäristössä, jossa kehittäjät ja projektit ovat maantieteellisesti hajallaan ja toimintaa sitoo tietty avoin ohjelmistolisenssi. Silti yhteisömuotoinen ohjelmistotuotanto on osoittanut toimivuutensa myös ohjelmistomarkkinoilla (Dahlander, 2007), joille avoimen lähdekoodin ohjelmistot ovat kasvaneet houkuttelevina vaihtoehtoina kaupallisille (suljetuille) ohjelmistoille (esim. Linux-käyttöjärjestelmä). Yksittäisten ihmisten aloitteesta syntyneet yhteisöt on usein rakennettu niin, että kaupalliselle yritykselle on mahdollisimman vaikeaa vallata yhteisöä tai sen tuotantoa (West, 2005), näin pyritään myös osalta varmistamaan avoimen ohjelmistotuotteen jatkuvuus. Tämä tarkoittaa myös sitä, että kaikki kustannukset sekä resurssit on tultava yhteisön jäseniltä, jotta avoimen lähdekoodin yhteisö saa toimintansa etenemään kypsään vaiheeseen. Esimerkiksi Internetin suurin avoimen lähdekoodin portaali SourceForge sisältä yli erilaista projektia, mutta näistä vain 2% voidaan luokitella olevan kypsässä vaiheessa (West, 2005). Yhteisöjen rakenne voi vapaaehtoisuudesta huolimatta olla hyvinkin hierarkkinen. Päätökset tehdään yleensä äänestämällä, äänestys voi olla rajattu vain tiettyjen päättäjien oikeudeksi yhteisöissä. Yleensä päättäjät valitaan yhteisön jäsenten keskuudesta, ja ehdokkaaksi pääseminen edellyttää huomattavia meriittejä yhteisön hyväksi toimimisessa (Lattemann and Stieglitz, 2005).

24 24 (30) Ohjelmistotuotteen hallinta Ohjelmistotuotteen hallinnalla (Software Configuration Management, SCM) tarkoitetaan toimia, jotka mahdollistavat ohjelmiston hallitun kehityksen ja kehityksen seurannan. SCM on aihealueena paljon tutkittu ja sitä pidetäänkin yhtenä onnistuneimmista ohjelmistokehitykseen liittyvistä osa-alueista, johon tutkimus on vaikuttanut positiivisesti (Estublier et al., 2005). Ohjelmistotuotteen hallinnan avulla: Muutokset ohjelmistoon tehdään koordinoidusti siten, että se kehittyisi käyttäjiä palvelevaan suuntaan. Eli muutokset tehdään yhteisesti sovittujen käytäntöjen mukaan. Ohjelmisto säilyy laadukkaampana, koska puutteelliseen versionhallintaan ja epäselviin toimintatapoihin perustuvat virheet ja inhimilliset erehdykset vähenevät. Ajantasainen riittävä tieto ohjelmistotuotteesta on oikeiden henkilöiden/tahojen saatavilla, oikeaan aikaan ja sovitun tiedonvaihtokanavan kautta. Ohjelmistotuotteen hallinnan tärkeys korostuu ns. kriittisissä ohjelmistoissa, joissa ohjelmiston toimimattomuus voi johtaa merkittäviin henkilövahinkoihin, taloudellisiin menetyksiin, tietoturvaongelmiin tai vaikkapa vakaviin ympäristövahinkoihin (Jonassen Hass, 2003). Liiketoimintakriittisissä sovelluksissa asiakkaalla tulee olla varmuus, että sovellukselle löytyy tuki ja ylläpito sekä useiden vuosien elinkaari (Eskeli et al., 2010). Siten liiketoimintakriittisten ohjelmistojen lähdekoodin tulisi olla asiakkaan saatavilla ylläpidon ja kehittämisen varmistamiseksi, jos esimerkiksi toimittaja joutuu selvitystilaan (Puolustustaloudellinen suunnittelukunta, 2005). Ohjelmistotuotteen hallinta jaotellaan sen suunnitteluun ja aktiviteetteihin (Kuva 10). Ohjelmistotuotteen hallinnan suunnittelun avulla suunnitellaan kysessä olevalle organisaatiolle ja ohjelmistolle soveltuvat tuotteenhallinnan käytännöt ja dokumentoidaan ne. Ohjelmistotuotteen hallinnan suunnitteluun on olemassa valmiita standardipohjia, esimerkiksi IEEE standardin kuvaama, jota voi käyttää pohjana organisaation tuotteenhallinnan suunnitelmille. Johdonmukaiset ohjelmistotuotteen hallinnan käytännöt tunnistetaan tärkeäksi myös IT standardeissa kuten ITIL ja ISO Kuva 10: Ohjelmistotuotteen hallinnan osa-alueet.

25 25 (30) SCM:n perusaktiviteetteja ovat: Tunnistaminen: käytännöt hallinnan alle tarkoitettujen alkioiden tunnistamiseen, niiden tallennukseen ja versiointiin. Muutosten hallinta: käytännöt sille että hallinnan alla oleviin alkioihin kohdistettavat muutokset ovat dokumentoituja, koordinoituja ja kommunikoituja. Raportointi: käytännöt ohjelmiston hallitsemiseksi tarvittavan tiedon keräämistä, tallentamista ja raportointia varten. Käytetään ohjelmiston kehittämiseen ja kehittymiseen liittyvään seurantaan ja päätöksentekoon. Tarkastus: käytännöt, joilla varmistetaan, että ohjelmisto tai sen muutos on tehty sidosryhmiä tyydyttävällä tavalla ja kaikki ohjelmistoon liittyvä dokumentaatio on ajan tasalla. Näiden lisäksi aktiviteeteiksi esitetään lähteistä riippuen myös: Julkaisemisen hallinta: käytännöt julkaistavan ohjelmistotuotteen elementtien identifiointiin, paketointiin ja jakamiseen. Alihankkijoiden hallinta: käytännöt alihankittavien ohjelmisto-osien hallintaan. Esimerkiksi, miten varmistutaan, että alihankkijan toimittama ohjelmisto dokumentaatioineen vastaa sitä mistä on sovittu. Rajapintojen hallinta: käytännöt kuinka hallitaan muutoksia ohjelmistoosiin, joilla on liityntöjä esimerkiksi toisiin ohjelmistoihin tai laitteistoon. Toisaalta kyseiset aktiviteetit voidaan kuvata myös osana edellä esitettyjä SCM perusaktiviteetteja. Ohjelmistotuotteen hallintaa on tutkittu eri näkökulmista, joista avoimen lähdekoodin ja ohjelmiston uudelleenkäytön näkökulmat ovat mielenkiintoisia tämän tutkimuksen näkökulmasta. Kirjallisuudesta voidaan poimia seuraavanlaisia havaintoja. Julkaisuprosessi (release management) ja julkaisun vaadittava sisältö (koodi, uudelleenkäyttöä tukeva dokumentaatio) tulee olla määriteltynä ja jakamisen tapahduttava yhden kanavan kautta jotta varmistetaan laadukas uudelleenkäyttö (JHS 169; Erenkrantz, 2003; Asklund & Bendix, 2002). Muutokset perussovellukseen (virheiden raportointi, ominaisuusmuutokset) tulee olla koordinoituja (käytännöt, vastuut) ja kommunikoituja, jotta sovellus kehittyy yhteisöä palvelevaan suuntaan (Clements & Northrop, 2002; Asklund & Bendix, 2002). Toisaalta muutosten hyödyllisyys tulee punnita, koska mikäli uusi versio ei tuo mitään oleellista parannusta sen hetkiseen toteutukseen, on päivitystyö todennäköisesti turhaa ajankäyttöä ja riskinottoa (JHS 169, 2009). Vältä kehityksen haaroittumista rinnakkaisiksi versioiksi mielellään yksi lineaarinen kehityspolku. (JHS 169; Clements & Northrop, 2002; Asklund & Bendix, 2002). Varmista toimitus- ja ylläpitovarmuus pyytämällä lähdekoodit osana kokonaistoimitusta. Tällöin on mahdollista ryhtyä toimenpiteisiin heti, jos toimittajan kanssa tehtävässä yhteistyössä ilmenee vakavia ongelmia. (JHS 169, 2009; Puolustustaloudellinen suunnittelukunta, 2005). Tuotteenhallinta vaatii formalismia kun useita organisaatioita toimii yhteistyössä hajautetussa ympäristössä uudelleen käyttäen yhteisiä ohjelmistoja (Jonassen Hass, 2003) - Muodosta ja dokumentoi ohjelmistolle tuotteenhallinnan suunnitelma (käytännöt), joka perustuu yhteisesti sovittuihin

26 26 (30) tuotteenhallinnan kriteereihin. Yhteisössä toimivien edellytetään noudattavan näitä käytäntöjä. - Tuotteenhallinnan vastuut tulee olla määritelty selkeästi (Clements & Northrop, 2002) - Määriteltyjä sovittuja toimintatapoja tulee noudattaa, eli huolehdi tuotteenhallinnan auditoinnista => mikäli joku osapuoli ei toimi määriteltyjen käytäntöjen mukaan se vahingoittaa koko yhteisön toimintaa Ohjelmistojen elinkaarenhallinta Viimeaikoina englanninkielisen termin Application Lifecycle Management (ALM) käyttö on lisääntynyt järjestelmätoimittajilla sekä kirjallisuudessa. ALM suomennetaan ohjelmistojen elinkaarenhallinta tai sovellusten elinkaarenhallinta riippuen viitteestä. Käsitteen käyttö ei ole vakiintunut, jonka johdosta siitä on erilaisia määritelmiä eri järjestelmätoimittajien ja konsulttien toimesta (Weis et al., 2009; Göthe et al., 2008). Myös kirjallisuuslähteissä viitataan että monesti ALM käsitteenä rinnastetaan tiettyyn vaiheeseen ohjelmiston koko elinkaarta (Rossberg, 2008; Chappell, 2008). Yleisesti ottaen käsitteellä tarkoitetaan kaikkien ohjelmistotuotteen elinkaaren aikaisten vaiheiden organisointia ja ohjelmistotuotteen hallintaa siten, että tuotetta kehitetään hallitusti siten, että se kehittyy tarpeita palvelevaan suuntaan. Kaikilla ohjelmistotuotteilla on elinkaari joka kattaa kehitys, käyttö ja ylläpito sekä käytöstä poiston vaiheet (Leon, 2000). Chappell (2008) esittää ohjelmistojen elinkaarenhallinnan kolmen ohjelmistotuotteen elinkaaren aikaisten toimintojen kokonaisuutena (Kuva 11). Kuva 11: Ohjelmistojen elinkaarenhallinnan toiminnot (Chappell, 2008). Chappell (2008) kuvaa toimintoja seuraavasti: Governance, which encompasses all of the decision making and project management for this application, extends over this entire time. Development, the process of actually creating the application, happens first between idea and deployment. For most applications, the

27 27 (30) development process reappears again several more times in the application s lifetime, both for upgrades and for wholly new versions. Operations, the work required to run and manage the application, typically begins shortly before deployment, then runs continuously until the application is removed from service. Chappell (2008) jatkaa ALM:n roolista: The three aspects of ALM governance, development, and operations are tightly connected to one another. Doing all three well is a requirement for any organization that aspires to maximize the business value of custom software. But this isn t an easy goal to achieve. Each of the three is challenging to get right on its own, and so getting the combination right is even more challenging. Siten ohjelmistotuotteen hallinnan voidaan nähdä olevan osa ohjelmiston elinkaarenaikaista hallintaa. Elinkaarenaikaiseen hallintaan, eli ALM:ään, liittyy myös tuki päätöksenteolle ohjelmistoa koskevien asioiden osalta. Esimerkiksi, mitä ominaisuuksia tai ominaisuuskokonaisuuksia kannattaisi ottaa missäkin vaiheessa mukaan ohjelmistoon. Siten ohjelmistot kehittyvät ajan mittaan esimerkiksi virheenkorjausten ja muuttuvien tarpeiden mukaan. Tätä kehittymistä voidaan tarkastella ohjelmiston evoluution kautta. Ohjelmistojen evoluutio Rajlich & Bennett (2000) esittävät vaihemallin ohjelmiston elinkaarelle, johon on viitattu laajasti. Kyseinen malli käsittelee ohjelmiston kehittymisen problematiikkaa. Malli jakaa ohjelmiston kehittymisen viiteen vaiheeseen (Rajlich & Bennett, 2000): Initial development. Engineers develop the system s first functioning version. Evolution. Engineers extend the capabilities and functionality of the system to meet user needs, possibly in major ways. Servicing. Engineers make minor defect repairs and simple functional changes. Phaseout. The company decides not to undertake any more servicing, seeking to generate revenue from the system as long as possible. Closedown. The company withdraws the system from the market and directs users to a replacement system, if one exists. Artikkelissa on esitetty myös variaatio mallista, joka on erityisen mielenkiintoinen tämän tutkimuksen näkökulmasta. Kyseinen variaatio on nimeltään versioitu vaihemalli (versioned staged model) (Kuva 12).

28 28 (30) Kuva 12: Versioitu vaihemalli (Rajlich & Bennett, 2000). Versioidun vaihemallin perusta ovat evoluutioversiot, joita ohjelmistoorganisaatio tuottaa tietyillä sovituilla ajanhetkillä. Kyseiset versiot edustavat suurempia muutoksia ohjelmistossa, kun taas ylläpito (servicing) edustaa pieniä muutoksia ja virheenkorjauksia. Kyseinen malli johtaa yhteen kehityspolkuun, jossa ohjelmisto kehittyy evoluutioversioiden kautta ja aiempia versioita tuetaan vain ylläpidon kautta. Rajlich & Bennett (2000) esittävät, että evoluutioversioiden kehittäminen vaatii vahvaa osaamista, koska muutokset ovat suuria. He esittävätkin, että kyseinen osaaminen kehittyy ohjelmisto-organisaation henkilökunnalle ensimmäisen version kehittämisen aikana (initial development) ja tätä osaamista voi olla vaikeaa hankkia muuta kautta. Rajlich & Bennett (2000) mukaan ylläpito sen sijaan voitaisiin kyseisessä mallissa ulkoistaa, koska muutokset ovat pienempiä ja eivät artikkelin kirjoittajien arvion mukaan vaadi yhtä suurta ymmärrystä ohjelmiston rakenteesta. Capiluppi et al. (2007) ovat tarkastelleen vaihemallia avoimen lähdekoodin ohjelmistojen näkökulmasta. Kyseinen tarkastelu toteaa, että vaikka avoin lähdekoodi tuo tiettyjä erityispiirteitä malliin, niin vaihemallin vaiheet ovat päteviä myös esittämään avoimen lähdekoodin kehittymistä. Referenssitapaukset Case Philips (Wesselius, 2008) Wesselius (2008) raportoi artikkelissaan tapauksen Philips Healthcare yksiköstä, jossa sovellettiin avoimen lähdekoodin yhteisöjen toimintatapoja rajattuun