Asiakkaan roolista ja vastuusta (Mutta ensin harjoitustyöstä) Johdatus ohjelmistotuotantoon 27.10.2014 Kari Systä 27.10.2014 JOTU2014/Kari Systä 1
Alustava luentoaikataulu 25.8: Johdanto + historiaa, mitä on ohjelmistotuotanto 1.9: Ohjelmistojen roolista ja tyypeistä ohjelmistotyön merkitys 8.9: Miten ohjelmistotyö organisoidaan (vaihejako ja prosessi-mallit) 15.9: Vaatimusmäärittelyt 22.9: Vaatimukset 2; tiedon mallintaminen 29.9: Käyttäjä ja käyttäjäkokemus ohjelmisto-projektissa (Jarmo Palviainen) 6.10: Esimerkkiprojekti (M-files) 20.10: Yleiset notaatiot erityisesti UML 27.10: Projektitoiminta 3.11: Asiakasroolista 10.11: Ohjelmisto osana laitetta 1 17.11: IPR, sopimukset, open source 25.11: 1.12: Kertausta 27.10.2014 JOTU2014/Kari Systä 2
ENSIN MUUTAMA SANA HARJOITUSTYÖSTÄ 27.10.2014 JOTU2014/Kari Systä 3
Ryhmä A Harjoitustyön idea (ei ihan UML:ää) Ryhmä B Assari Asiakasvaatimukset Asiakasvaatimukset Toiminnalliinen määrittely Palaute Toiminnalliinen määrittely 27.10.2014 JOTU2014/Kari Systä 4
Erilaisia vaatimuksia - esimerkki Asiakasvaatimus tyypillisesti asiakkaan ongelma, jolle toivotaan ratkaisua: tuotetaan mahdollisimman virheettömiä dokumentteja. Ominaisuus, feature jokin asiakkaan kannalta mielekäs kokonaisuus ohjelmiston toiminnallisuudesta: tuki oikeinkirjoituksen tarkastamiselle. Ohjelman toiminto yksittäinen ohjelmistolla tehtävä asia: tarkasta oikeinkirjoitus, ehdota korjausta, korjaa automaattisesti... Tekniset vaatimukset miten ohjelmisto toteutetaan: tiedostopuskuri, dialogin toteutus,... Kannattaa huomata, että luokittelu ei ole mitenkään itsestään selvä. 27.10.2014 JOTU2014/Kari Systä 5
Vaatimukset vs. rajoitteet Toiminnallinen vaatimus (functional requirement), esimerkiksi ohjelmassa on tuki oikeinkirjoituksen tarkastamiselle. Ei-toiminnallinen vaatimus (non-functional requirement), esimerkiksi ohjelman käyttöliittymä on UI-tyyliopaan mukainen tai ohjelmiston asennus saa käyttää korkeintaan 5 Mt levytilaa. Reunaehdot (constraints), esimerkiksi ohjelmisto on toteutettava Windows-ympäristöön C++kielellä. 27.10.2014 JOTU2014/Kari Systä 6
http://www.cs.tut.fi/ohj/dokumenttipohjat/ pohjat/maarittely/hytt_drmaarittely.doc Yleiskäyttöinen runko kattaa myös vesiputousmaailman vaatimukset Valmiin ohjelmiston dokumentin mukainen (osa kohdista täytetään vasta kun ohjelma on valmis) Tällä kurssilla sovelletaan. Kts seuraava kalvo: 27.10.2014 JOTU2014/Kari Systä 7
Toiminnallisen määrittelyn runko Kohta 1.4 (Viitteet): Viiteluettelosta pitää löytyä ainakin asiakasvaatimukset Kohta 1.3 (Määritelmät, termit ja lyhenteet): Muista selventää kaikki "maallikolle" tuntemattomat termit, lyhenteet ja käsitteet (ajattele lukijoita!) Kohta 2.1 (Ympäristö): Olisi hyvä olla selventävä kuva järjestelmän liittymisestä ympäristöönsä. ohjelmistot laitteistot Kohta 2.2 (Toiminta): Muista käyttötapauskaavio aktorit (toimijat) tärkeimmät käyttötapaukset Kohta 2.5 (Oletukset ja riippuvuudet): älkää miettikö mahdollista toteutusta (se esimerkki kyselykielestä on huono) Esim älypuhelin? 27.10.2014 JOTU2014/Kari Systä 8
Käyttötapauskaavio, versio 2 Dipparekisteri Lisää uusi opiskelija Lisää uusi kenttä Ohjaaja Etsi ehdot täyttävät opiskelijat tee palaverimuistio lisää/poista ohjaaja kirjoita lausunto Laitoksen johtaja tarkastele tilastoja 27.10.2014 JOTU2014/Kari Systä 9
Luku 3: Muista tietosisällön käsitekaavio. Käsitteet (luokat) attribuutit (ominaisuudet) luokkien väliset yhteydet lukumääräsuhteet (Metodeja ei tarvita) Tietohakemistonotaation käyttö on vapaaehtoista, esim. taulukko, jossa attribuutti, sen tyyppi, tarkoitus, mahdolliset muotoilut ja rajoitteet on kuvattu tekstinä käy myös. Kohta 3.4: Täällä voi selittää ohjelmiston tarvitsemat resurssitiedostot, esimerkiksi kartat. Älkää pelästykö pohjan liian teknisiä esimerkkejä 27.10.2014 JOTU2014/Kari Systä 10
Käsitekaavio (UML:n luokkakaavio) Nimi Ominaisuudet lkm nimi lkm Nimi Ominaisuudet (Metodit) (Metodit) 27.10.2014 JOTU2014/Kari Systä 11
Esimerkki Navigointisuunta 27.10.2014 JOTU2014/Kari Systä 12
Tietohakemistonotaatio merkki merkitys + ja () optionaalinen (voi puuttua) {} toisto (0-N kertaa) n{}m toisto n-m kertaa [] vaihtoehtoja vaihtoehtojen erotin @ avainkenttä * kommentti 27.10.2014 JOTU2014/Kari Systä 13
Esimerkkejä henkilötiedot = nimi + @henkilötunnus + aviosääty + lapset nimi = 1{etunimi}3 + sukunimi aviosääty = [naimaton naimisissa eronnut leski] osoite = (toimitusosoite) + (laskutusosoite) osoite = [toimitusosoite laskutusosoite toimitusosoite + laskutusosoite] osoite = toimitusosoite + (laskutusosoite) luottoraja = *asiakkaalle myönnettävän luoton enimmäismäärä markkoina* luottoraja_ilmoitus = *vastaus luottorajan muutosyritykseen* ["Tuntematon asiakas" "Virheellinen luottoraja" "Uudeksi luottorajaksi on muutettu xxx markkaa"] 27.10.2014 JOTU2014/Kari Systä 14
Luku 4 : Jokainen toiminto omaksi alakohdakseen 4.x. Toimintojen tulee kattaa järjestelmä 100- prosenttisesti Tietokoneella (tai käsin hyvin, hyvin selkeästi) tehdyt käyttöliittymäkuvat jokaisesta toiminnosta. Ei kuitenkaan mennä teknisiin yksityiskohtiin Varmista, että kaikki 4.luvun toiminnoilla käsiteltävät pysyväistiedot on mahdollista tallentaa järjestelmään tietosisällön puolesta. Esim. jos järjestelmään on mahdollista luoda uusia käyttäjiä (käyttöliittymästä syötetään tiedot: nimi, tunnus, salasana), täytyy nämä tiedot olla mahdollista tallentaa jonnekin (Käyttäjäluokka, jolla atribuutit nimi, tunnus, salasana). Lue: onko luvut 3 ja 4 keskenään yhdenmukaisia! 27.10.2014 JOTU2014/Kari Systä 15
Näyttökartta t. navikaatiokartta (kuvitteellinen sähköpostiohjelma) Pääikkuna Kirjoita viesti Osoitekirja Lue viesti Kurssilla User interface design opetetaan yksityiskohtaisempi kaaviomalli 27.10.2014 JOTU2014/Kari Systä 16
Kohta 4.2 (toiminnot): Teknisiä detaljeja ei ole välttämätöntä dokumentoida tässä vaiheessa. Luvut 5 (ulkoiset liittymät), 6 (muut ominaisuudet) ja 7 (suunnittelurajoitteet): Jos jokin kohta tuntuu turhalta järjestelmän suhteen, esim. web-järjestelmässä kohta 6.3, niin asian voi kuitata lyhyesti mainitsemalla epärelevanttiudesta kyseisessä kohdassa. Muutenkaan näihin lukuihin ei kannata kovin montaa sivua uhrata. Tärkeintä on, että vaaditut ei-toiminnalliset vaatimukset tulevat katetuiksi ja järjestelmän rajat muihin järjestelmiin (tietoliikenne-, rauta- ja ohjelmistorajapinnat) tulevat selväksi. Ks. myös kohta 2.1. 27.10.2014 JOTU2014/Kari Systä 17
Liite A: Käyttötapaukset (vähintään 4 kpl): Käyttötapauksen tulee olla sellainen, että sen suorittamiseen tarvitaan useampi toiminto, eli EI esim. sisäänkirjautuminen. Käyttötapausten nimien tulee vastata käyttötapauskaaviota. Liite B: Asiakasvaatimukset, joiden pohjalta järjestelmä on toteutettu. Liite C: Selostus yhteydenpidosta asiakasryhmään (toimittajan näkökulmasta kirjoitettu) Liite D: Asiakastapaamisen dokumentit Muita UML-kaavioita saa käyttää vaadittujen lisäksi. Muista laittaa päällimmäiseksi kurssin kansilehti! 27.10.2014 JOTU2014/Kari Systä 18
Erilaisia vaatimuksia - esimerkki Asiakasvaatimus tyypillisesti asiakkaan ongelma, jolle toivotaan ratkaisua: tuotetaan mahdollisimman virheettömiä dokumentteja. Ominaisuus, feature jokin asiakkaan kannalta mielekäs kokonaisuus ohjelmiston toiminnallisuudesta: tuki oikeinkirjoituksen tarkastamiselle. Ohjelman toiminto yksittäinen ohjelmistolla tehtävä asia: tarkasta oikeinkirjoitus, ehdota korjausta, korjaa automaattisesti... Tekniset vaatimukset miten ohjelmisto toteutetaan: tiedostopuskuri, dialogin toteutus,... Kannattaa huomata, että luokittelu ei ole mitenkään itsestään selvä. 27.10.2014 JOTU2014/Kari Systä 19
MUISTA: MÄÄRITTELY ON MITÄ EI MITEN!!! VAATIMUSMÄÄRITTELY ON ASIAKASTA VARTEN 27.10.2014 JOTU2014/Kari Systä 20
Asiakasrooli => Tietojärjestelmän hankkiminen Ostajan rooli Kilpailuttaminen, sopimukset Ketterä, iteratiivinen, vesiputous Käyttöönotto Käyttäjän näkökulma Muita sidosryhmiä HW suunnittelija Johtaja Monitoimittajaprojektit Avoimet rajapinnat ja muut arkkitehtuuriasiat 27.10.2014 JOTU2014/Kari Systä 21
TLO-35200 Liiketoiminnan ja tietojärjestelmien yhteensovittaminen Liiketoiminnan tavoitteiden huomioimista yrityksen tietohallinnon toiminnassa ja toisaalta tietoteknisten mahdollisuuksien hyödyntäminen liiketoiminnassa on erittäin haastavaa. Kurssin tavoitteena on tarjota opiskelijoille tietojärjestelmien kokonaisvaltaisesta kehittämisestä organisaatioiden tarpeisiin. Kurssin päätyttyä opiskelijat ymmärtävät liiketoiminnan asettamien vaatimusten vaikutukset tietohallinnolle ja tietojärjestelmille, sekä erilaisia vaikutusmahdollisuuksia uusien tietojärjestelmien tarjoamien liiketoimintamahdollisuuksien toteuttamiseksi. Kurssilla opiskelijoille tarjotaan tiedot yritysten strategioiden vaikutuksesta toimintaprosesseihin ja edelleen tietojärjestelmiin sekä toisaalta uusien tietojärjestelmien tarjoamista uusista liiketoimintamahdollisuuksista. 27.10.2014 JOTU2014/Kari Systä 22
TLO-35210 Tietojärjestelmien uusiminen ja käyttöönotto Kurssin suoritettuaan opiskelija ymmärtää tietojärjestelmien uusimiseen liittyvät vaihtoehdot ja vaihtoehtojen edut ja haitat. Lisäksi opiskelija hallitsee tietojärjestelmien käytöönottoon liittyvän problematiikan. 27.10.2014 JOTU2014/Kari Systä 23
Perinteinen Toimittaja tutkimus toteutus testaus tarjous määrittely käyttöönotto määrittely käyttöönotto tarjouspyyntö tarjous 27.10.2014 Asiakas JOTU2014/Kari Systä 24
Iteratiiviset, ketterät yms Toimittaja tutkimus tot tot tot tot tarjous määr. test demo test demo test demo test käyt.otto määr. demo demo demo käyt.otto tarjouspyyntö Asiakas tarjous Demo tarkoittaa yhdessä käyttäjän kanssa tehtävää uudelleen pohdintaa. 27.10.2014 JOTU2014/Kari Systä 25
Tietojärjestelmän rakentaminen Liiketoimintastrategia Strategiset tavoitteet Mittaus ja analysointi Järjestelmävaatimukset Tietojärjestelmätoimitus Käyttöönotto ja hyväksyminen Ylläpito Mukailtu lähteestä: Timo Koivisto: Tietojärjestelmätoimituksen jälkiseuranta, Systeemityö 3/2006 27.10.2014 JOTU2014/Kari Systä 26
Tarpeet / Riskit Järjestelmän vaatimusten on vastattava liiketoimintatavoitteita tai tarpeita yleensäkin Järjestelmän on toteutettava kaikki (ainakin tärkeät) vaatimukset Järjestelmän on toteutettava vaatimukset oikein Järjestelmän on oltava valmis ajoissa Järjestelmän kaikkien kustannusten on oltava suhteessa tuottoihin 27.10.2014 JOTU2014/Kari Systä 27
Tiejärjestelmän hankintaprosessi (Tietojärjestelmän hankinta - Ohjelmistotoimittajan ja -ratkaisun valinta. TTL-julkaisusarja, Helsinki 2005) 27.10.2014 JOTU2014/Kari Systä 28
Eräs kiva havainnollistaminen: CxO Mentor Oy:n kehityshankemalli Lähde: Myllymäki, R., Hinkka, T., Dahlberg, T. & Uimonen, B. Miksi tietojärjestelmäprojekti epäonnistuu? Tositarinoita tuhon teiltä ja onnistumisen siemeniä. Helsinki 2010, CxO Mentor Oy. 286 s. 27.10.2014 JOTU2014/Kari Systä 29
Tietojärjestelmähankkeiden onnistuminen vuosina 2000-2008 60 50 40 30 Onnistunut Epäonnistunut Haasteellinen 20 10 0 2000 2002 2004 2006 2008 Lähde: The Standish Group. Chaos Summary for 2010 [WWW]. 2010. Saatavissa: http://insyght.com.au/special/2010chaossummary.pdf. (Uudelleen visualisoitu Erkka Vastamaan diplomityössä) 27.10.2014 JOTU2014/Kari Systä 30
Ongelmiin ajautumiseen johtaneet tekijät tietojärjestelmäprojekteissa (%) Käyttäjäpalautteen puute Puutteelliset vaatimukset ja spesifikaatiot Muuttuvat vaatimukset ja spesifikaatiot Johdon tuen puute Teknologiset ongelmat Puutteelliset resurssit Epärealistiset odotukset Epäselvät tavoitteet Epärealistinen aikataulu Uusi teknologia 0 2 4 6 8 10 12 14 Lähde: The Standish Group. The Standish Group Report CHAOS [WWW]. 1995, 27.10.2014 Saatavissa: https://cs.nmt.edu/~cs328/reading/standish.pdf. JOTU2014/Kari Systä 31 (Uudelleen visualisoitu Erkka Vastmaan diplomityössä)
27.10.2014 JOTU2014/Kari Systä 32
Huomioitava lause Koska itse järjestelmän koodaus on kolmannen osapuolen käsissä, ei Salibandyliitto voi määritellä tarkkoja aikatauluja järjestelmän eri vaiheiden käyttöönotosta. 27.10.2014 JOTU2014/Kari Systä 33
VR:n lippu-uudistus (http://www.vrgroup.fi/fi/vakiolinkit/vrkonsernitiedottaa/news_20110901085340.html) Tämä tiedote kertoo, että taustalla on ollut liiketoimintatavoitteita Yksittäisen junamatkan hintaan tulee nykyistä enemmän valinnanvaraa, sillä tarjouksia lisätään ja muita lippuja edullisempi Ennakkolippu tulee pysyväksi osaksi lippuvalikoimaa. Verkkopalvelujen valikoima laajenee, ja junamatkojen hankintaan tulee uusia tapoja. Myös junien matkustusluokkien nimet uudistuvat, ja samalla nykyisen Business-luokan lipun hinta laskee. Nyt tehtävät uudistukset ovat ensimmäinen askel kohti mallia, jossa yksittäisen junavuoron hinnoitteluun vaikuttaa kysyntä. Verkkokauppaan tulee uutuutena asiakkaiden toivoma vaunukartta, josta voi itse valita matkalleen haluamansa istumapaikan. Samoin säännöllisesti matkustavien sarjalipun maksuton paikanvaraus on jatkossa mahdollista tehdä verkossa. Myös polkupyörän ja lemmikkieläinten liput saa uudistuksen myötä verkkokaupasta. 27.10.2014 JOTU2014/Kari Systä 34
Toimittaja tutkimus tarjous tarjouspyyntö tarjous määrittely määrittely toteutus testaus käyttöönotto käyttöönotto Kunnon määrittely ensin + On selkeä sopimus +Tiedetään etukäteen mitä saadaan + Kun on etukäteen mietitty ei matkan varrella tehdä turhaa + Riitatilanteissa tuomareilla on helppoa - Muutosten tekeminen vaikeaa - Voiko määrittelyä tehdä kunnolla? Asiakas Toimittaja Tehdään yhdessä iteratiivisesti + voidaan yhdessä oppia * vaatii molemminpuolista sitoutumista ja luottamusta tutkimus tarjous määr. tot test demo tot test demo tot test demo tot test käyt.otto määr. demo demo demo käyt.otto tarjous Demo tarkoittaa yhdessä käyttäjän tarjouspyyntö kanssa tehtävää uudelleen 27.10.2014 JOTU2014/Kari Systä pohdintaa. 35 Asiakas
Oulun seudun päivähoito (http://www.tietoviikko.fi/kaikki_uutiset/tietoyhteiskuntahanke+epaonnistui+oulussa+ndash+mutta+tietoenator+teki+tilin/a136937) Luennolla pohdittiin eri näkökulmia ja spekulaatioita 27.10.2014 JOTU2014/Kari Systä 36
Oulun seudun päivähoito (http://www.tietoviikko.fi/kaikki_uutiset/tietoyhteiskuntahanke+epaonnistui+oulussa+ndash+mutta+tietoenator+teki+tilin/a136937) Tietoviikko 17.3.2008: Tietoyhteiskuntahanke epäonnistui Oulussa mutta TietoEnator teki tilin Oulussa haluttiin luoda seudullinen toimintamalli, jossa päivähoito-paikka on mahdollista saada yli kuntarajojen. Asiaa lähdettiin kehittämään tietoyhteiskuntaohjelman Julkiset palvelut verkkoon (Jupa)-hankkeena. Hanke kuitenkin epäonnistui. Tarkastusviraston raportin mukaan suurin syy siihen oli oli TietoEnatorin ja Logican yhteistyökyvyttömyydessä ja kapseloidussa liiketoimintapolitiikassa. Ne eivät halunneet avata rajapintojaan. 27.10.2014 JOTU2014/Kari Systä 37
Oulun seudun päivähoito (http://www.tietoviikko.fi/kaikki_uutiset/tietoyhteiskuntahanke+epaonnistui+oulussa+ndash+mutta+tietoenator+teki+tilin/a136937) Raporttia varten haastatellut vastuuhenkilöt arvioivat myös, että TietoEnatorin Effica-järjestelmän tekniset ongelmat estivät rajapintojen toteuttamisen siten, että hakemuslomakkeen voisi välittää sinne asiointijärjestelmästä. Ylitarkastaja Voutilaisen mukaan Oulussa vallitsi epäselvyyttä myös siitä, mitä rajapintojen kehittäminen ja toteuttaminen tarkoittaa. 27.10.2014 JOTU2014/Kari Systä 38
Selitykset. TietoEnatorin johtaja Hannu Puurosen mukaan väitteet rajapintojen suojelusta ja huonosta yhteistyökyvystä eivät pidä paikkaansa. Mitä Oulun pro-jektiin tulee, Puurosen mukaan sopimukset eivät olleet epäonnistumisen tärkein syy. Sopimuksen sisältö muuttui jonkin verran projektin kuluessa. Sovimme silloin käyttöönoton siirtämisestä myöhempään ajankohtaan, jota ei kuitenkaan tullut. Hän painottaa projektijohdon roolia. Ratkaisun tavoitteenmukaisuuden varmistaminen on tilaajan tehtävä. Olemme toteuttaneet rajapinnat juuri niin kuin piti, Logican johtaja Kimmo Koivisto sanoo. Niitä ei Oulun alueella viety tuotantoon, mutta saimme niillä spekseillä tehtyä vastaavan projektin Pohjois-Karjalassa. Koivisto arvioi, ettei Oulussa riittänyt aikaa, panoksia ja intressiä viedä hanketta loppuun. Riskit liittyvät aina sen aliarviointiin, paljonko käyttäjäorganisaatioiden resursseja hankkeeseen voidaan sitouttaa ja miten ajankäyttö järjestetään. Luulen, että näissäkin hankkeissa on ollut kyse siitä, hän sanoo. 27.10.2014 JOTU2014/Kari Systä 39
Entä tilaaja Ylitarkastaja Voutilaisen mukaan Oulussa vallitsi epäselvyyttä myös siitä, mitä rajapintojen kehittäminen ja toteuttaminen tarkoittaa. It-talojen mukaan siihen ei kuulunut varsinaista käyttöönottoa, mikä tuli projektivastuullisille yllätyksenä. Oulun tietohallintojohtaja Ilari Heikkinen myöntää epäselvyydet. Täällä ei osattu vaatia sopimuksiin oleellisia asioita, eikä toimittajalla ollut intressiä huomauttaa asiasta. Valtiovarainministeriön KuntaIT-yksikön projektipäällikkö Tommi Oikarisen mukaan Jupa-hankkeiden perimmäinen ongelma on ollut puuttuva muutoksenhallinta. Kun suunnitelmia muutettiin, ne olisi pitänyt hyväksyttää ja kirjata tavoitteisiin. Toisaalta hankkeen aikana emme sisäasianministeriössä osanneet arvioida työmääriä tai resursointia oikein ja tehdä riittävän tiukkoja sopimuksia. 27.10.2014 JOTU2014/Kari Systä 40
Yhteenveto Syyllistä emme tiedä, emmekä edes etsi. Emme edes tiedä kuinka paljon lainatussa jutussa on virheitä. Mutta: Tilaajalla on aina iso vastuu ja tilaajan on osattava hommansa. Varsinkin jos on monta toimittajaa, kokonaisvastuun on oltava tiedossa. Ja konkreettisista tapauksista voi aina myös oppia Monitoimittajatilanne Rajapinnat ja niiden merkitys Käyttööoton huolellinen suunnittelu Asiakasorganisaation sitoutuminen tärkeää 27.10.2014 JOTU2014/Kari Systä 41
Monitoimittajaprojektit Tarvittavaa järjestelmää rakentaa usein monen toimijan verkosto Koska projekti on liian suuri yhdelle, tai Tarvitaan monenlaista osaamista, tai Kilpailutus tai liiketoimintasyistä Haasteita Vastuun jakaminen (yksi toimittaja vastuussa kokonaisuudesta vaiko tilaaja) Rajapintojen määritteleminen tärkeä 27.10.2014 JOTU2014/Kari Systä 42
Abrahamsson ja Mikkonen Helsingin sanomien vieraskynä 23.9.2011 (case VR:n lipunmyynti) Käytännössä ohjelmistot toimitetaan nykyisin niin sanotussa monitoimittajaverkostossa, jossa yhdessä projektissa voi olla useita päätoimittajia ja heidän lukuisia alihankkijoitaan. Lainsäädännön kannalta tarkasteltuna kilpailutus on toiminut hienosti, mutta järjestelmän tilaajan näkökulmasta tilanne on monimutkainen. Ohjelmistontoimittajat ovat kilpailijoita eivätkä keskustele toistensa kanssa. Ostajan on luotettava päätoimittajien sanaan siitä, että kaikki toimii sitten aikanaan. Ongelmatilanteisiin varaudutaan lakimiesten avulla. Tilanne on osin jopa paradoksaalinen: ostaja kyllä omistaa tilaamansa tietojärjestelmän mutta ei voi itse kehittää sitä edelleen, vaikka järjestelmä olisi keskeinen osa liiketoimintaa. Yksi selitys VR:n ongelmiin piilee rakenteissa. Sekä Suomessa että EU:ssa laki velvoittaa kilpailuttamaan kaikki yli 15 000 euron hankinnat. Järjestelmien kehittäminen jaetaan projekteiksi, jotka kilpailutetaan. 27.10.2014 JOTU2014/Kari Systä 43
Periaatteita Hankintalaki Saamalla tarjouksia mahdollisimman monelta toimittajalta, pyritään julkisten varojen tehokkaaseen käyttöön. Julkisen sektorin yksiköt ovat lisäksi velvollisia käyttämään hyväksi markkinoilla olemassa olevia kilpailumahdollisuuksia. Ylipäätään pyrkii varmistamaan kilpailun syntymisen hankintoja tehtäessä. Kilpailuttamisvelvoitteeseen ja sen laajuuteen vaikuttaa hankintojen luonteen lisäksi hankinnan arvo (kynnysarvo). Suositellut menettelyt Avoin menettely Rajoitettu menettely Neuvottelumenettely Kilpailullinen neuvottelumenettely 27.10.2014 JOTU2014/Kari Systä 44
Avoin menettely Taustamateriaalia Ei käsitelty luennoilla Lähde: JUHTA julkisen hallinnon tietohallinnon neuvottelukunta. JHS 167 - Neuvottelumenettelyjen käyttö ICT-hankinnoissa 27.10.2014 [WWW]. 5.10.2012, [http://docs.jhs-suositukset.fi/jhs-suositukset/jhs167/jhs167.pdf. JOTU2014/Kari Systä 45 Sekä Erkka Vastamaan diplomityö
Rajoitettu menettely Taustamateriaalia Ei käsitelty luennoilla Lähde: JUHTA julkisen hallinnon tietohallinnon neuvottelukunta. JHS 167 - Neuvottelumenettelyjen käyttö ICT-hankinnoissa 27.10.2014 [WWW]. 5.10.2012, [http://docs.jhs-suositukset.fi/jhs-suositukset/jhs167/jhs167.pdf. JOTU2014/Kari Systä 46 Sekä Erkka Vastamaan diplomityö
Neuvottelumenettely Taustamateriaalia Ei käsitelty luennoilla Lähde: JUHTA julkisen hallinnon tietohallinnon neuvottelukunta. JHS 167 - Neuvottelumenettelyjen käyttö ICT-hankinnoissa 27.10.2014 [WWW]. 5.10.2012, [http://docs.jhs-suositukset.fi/jhs-suositukset/jhs167/jhs167.pdf. JOTU2014/Kari Systä 47 Sekä Erkka Vastamaan diplomityö
27.10.2014 JOTU2014/Kari Systä 48
27.10.2014 JOTU2014/Kari Systä 49
Vaatimukset tehdään yhdessä? 12 % 8 % 80 % 41 % 39 % Tilaaja teettää ulkopuolisella Toimittajan ohjauksessa Tilaaja tekee itse Kun tilaajalta kysytään Tilaajan ohjauksessa 50 % 45 % 17 % 28 % Tilaaja teettää ulkopuolisella Toimittajan ohjauksessa Tilaaja tekee itse Kun toimittajalta kysytään Tilaajan ohjauksessa 5 % Lähde: Erkka Vastamaan diplomityö 27.10.2014 JOTU2014/Kari Systä 50
Palataan Ouluun Ylitarkastaja Voutilaisen mukaan Oulussa vallitsi epäselvyyttä myös siitä, mitä rajapintojen kehittäminen ja toteuttaminen tarkoittaa. It-talojen mukaan siihen ei kuulunut varsinaista käyttöönottoa, mikä tuli projektivastuullisille yllätyksenä. Oulun tietohallintojohtaja Ilari Heikkinen myöntää epäselvyydet. Täällä ei osattu vaatia sopimuksiin oleellisia asioita, eikä toimittajalla ollut intressiä huomauttaa asiasta. Valtiovarainministeriön KuntaIT-yksikön projektipäällikkö Tommi Oikarisen mukaan Jupa-hankkeiden perimmäinen ongelma on ollut puuttuva muutoksenhallinta. Kun suunnitelmia muutettiin, ne olisi pitänyt hyväksyttää ja kirjata tavoitteisiin. Toisaalta hankkeen aikana emme sisäasianministeriössä osanneet arvioida työmääriä tai resursointia oikein ja tehdä riittävän tiukkoja sopimuksia. 27.10.2014 JOTU2014/Kari Systä 51
Avoimet rajapinnat - esimerkki 27.10.2014 JOTU2014/Kari Systä 52
Webin peruselementit HTML CSS JavaScript HTTP protokolla Täysin avoimia standardeja Määrittelyt kaikkien saatavilla Kaikilla lupa toteuttaa Ilmaisia ja kaupallisia toteutuksia saatavilla Apua ja ohjeita saatavilla Yhteensopivuus melko hyvä Follow the cow-path be strict when sending tolerant when receiving 27.10.2014 JOTU2014/Kari Systä 53
Komponentit Flash sovellus - puoliavoin JPEG-kuva - yleinen standardi 27.10.2014 JOTU2014/Kari Systä 54
JPEG avoin? (http://en.wikipedia.org/wiki/jpeg) In 2002, Forgent Networks asserted that it owned and would enforce patent rights on the JPEG technology, arising from a patent that had been filed on October 27, 1986, and granted on October 6, 1987 (U.S. Patent 4,698,672). The announcement created a furor reminiscent of Unisys' attempts to assert its rights over the GIF image compression standard. The JPEG committee investigated the patent claims in 2002 and were of the opinion that they were invalidated by prior art. [30] Others also concluded that Forgent did not have a patent that covered JPEG. [31] Nevertheless, between 2002 and 2004 Forgent was able to obtain about US$105 million by licensing their patent to some 30 companies. As of October 27, 2006, the U.S. patent's 20-year term appears to have expired, and in November 2006, Forgent agreed to abandon enforcement of patent claims against use of the JPEG standard. [36] The JPEG committee has as one of its explicit goals that their standards (in particular their baseline methods) be implementable without payment of license fees, and they have secured appropriate license rights for their upcoming JPEG 2000 standard from over 20 large organizations. 27.10.2014 JOTU2014/Kari Systä 55
Rajapinnat liiketoiminnan mahdollistajina Flash sovellus Flash sovellus Plugin Plugin Selain Selain Ohjelmointikieli ja kirjasto Käyttöjärjestelmä 27.10.2014 JOTU2014/Kari Systä 56
Serverin pää voisi olla Sovellus Ohj kieli (PHPI HTTP-palvelin Ohjelmointikieli ja kirjasto (C++) Käyttöjärjestelmä 27.10.2014 JOTU2014/Kari Systä 57
Mitäs tämä voisi esimerkiksi tarkoittaa käytännössä? IDEA: Visualisoi esitietoketjut kurssille XXX. Selain Lisä 3 vaihtoehtoa - lisämoduuli ROCK/POP työkaluun - Uusi web-sovellus - Selaimen sisällä toimiva HTML5 sovellus Lisä ROCK POP Lisä Edut ja haitat + lisämoduulin voi tehdä kuka vaan (asiakkaan etu - toimittajan ei välttämättä) - tekee alkuperäisestä järjestelmästä kalliimman - potenttiaalinen turvallisuusriski, jos ei tehdä kunnolla 27.10.2014 JOTU2014/Kari Systä 58
Avoimuusspekulointia Tässä esimerkissä kolme kahdenlaista rajapintaa: 1. API uusille komponenteille. 2. Palvelurajapinta 3. Web-liittymä Näissä on erilaiset mahdollisuudet Kehittäjille Käyttäjille Ja erilaiset turvallisuushaasteet Selain Lisä ROCK Lisä POP Lisä 27.10.2014 JOTU2014/Kari Systä 59
Mitä on avoin rajapinta? Mitä on avoimuus? Sovellus API on dokumentoitu tarkkaan ja dokumentti on kaikkien saatavilla API on sama kaikille API ei muutu liian usein tai yllättäen Platform Kilpailevat toteutukset sallittuja (plugin, selain, kääntäjä) Ei ole Copyright- tai patentti-esteitä 27.10.2014 JOTU2014/Kari Systä 60
Esimerkkinä Java ME Taustamateriaalia Ei käsitelty luennoilla Yhteensopivuus Valmistajan pelivara Yksi digtaattori takaisi yhteensopivuuden, mutta onko tulos silloin avoimiuus? 27.10.2014 JOTU2014/Kari Systä 61
Avoin data Wikipedia: Open data is the idea that certain data should be freely available to everyone to use and republish as they wish, without restrictions from copyright, patents or other mechanisms of control. The goals of the open data movement are similar to those of other "Open" movements such as open source, open content, and open access. 27.10.2014 JOTU2014/Kari Systä 62
Rajapinnat ja monitoimittajaverkostot Rajapinta on yleisin tapa toteuttaa työnjako projektin aikana Vaatii ylimääräistä vaivaa, mutta vaihtoehto on vielä kalliimpi Dokumentoitu ja erikseen hallittu rajapinta mahdollistaa uusien toimittajien käyttämisen lisäkomponentteihin Standardi (tai de-facto) rajapinta mahdollistaa valmiiden komponenttien käytön Toinen puoli asiasta vendor lock-in 27.10.2014 JOTU2014/Kari Systä 63