Asiakkaan roolista ja vastuusta. (Mutta ensin harjoitustyöstä)

Transkriptio

1 Asiakkaan roolista ja vastuusta (Mutta ensin harjoitustyöstä) Johdatus ohjelmistotuotantoon Kari Systä JOTU2014/Kari Systä 1

2 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 : IPR, sopimukset, open source 25.11: 1.12: Kertausta JOTU2014/Kari Systä 2

3 ENSIN MUUTAMA SANA HARJOITUSTYÖSTÄ JOTU2014/Kari Systä 3

4 Ryhmä A Harjoitustyön idea (ei ihan UML:ää) Ryhmä B Assari Asiakasvaatimukset Asiakasvaatimukset Toiminnalliinen määrittely Palaute Toiminnalliinen määrittely JOTU2014/Kari Systä 4

5 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ä JOTU2014/Kari Systä 5

6 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ä JOTU2014/Kari Systä 6

7 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: JOTU2014/Kari Systä 7

8 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? JOTU2014/Kari Systä 8

9 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 JOTU2014/Kari Systä 9

10 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ä JOTU2014/Kari Systä 10

11 Käsitekaavio (UML:n luokkakaavio) Nimi Ominaisuudet lkm nimi lkm Nimi Ominaisuudet (Metodit) (Metodit) JOTU2014/Kari Systä 11

12 Esimerkki Navigointisuunta JOTU2014/Kari Systä 12

13 Tietohakemistonotaatio merkki merkitys + ja () optionaalinen (voi puuttua) {} toisto (0-N kertaa) n{}m toisto n-m kertaa [] vaihtoehtoja vaihtoehtojen avainkenttä * kommentti JOTU2014/Kari Systä 13

14 Esimerkkejä henkilötiedot = nimi + 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"] JOTU2014/Kari Systä 14

15 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! JOTU2014/Kari Systä 15

16 Näyttökartta t. navikaatiokartta (kuvitteellinen sähköpostiohjelma) Pääikkuna Kirjoita viesti Osoitekirja Lue viesti Kurssilla User interface design opetetaan yksityiskohtaisempi kaaviomalli JOTU2014/Kari Systä 16

17 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 JOTU2014/Kari Systä 17

18 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! JOTU2014/Kari Systä 18

19 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ä JOTU2014/Kari Systä 19

20 MUISTA: MÄÄRITTELY ON MITÄ EI MITEN!!! VAATIMUSMÄÄRITTELY ON ASIAKASTA VARTEN JOTU2014/Kari Systä 20

21 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 JOTU2014/Kari Systä 21

22 TLO 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 JOTU2014/Kari Systä 22

23 TLO 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 JOTU2014/Kari Systä 23

24 Perinteinen Toimittaja tutkimus toteutus testaus tarjous määrittely käyttöönotto määrittely käyttöönotto tarjouspyyntö tarjous Asiakas JOTU2014/Kari Systä 24

25 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 JOTU2014/Kari Systä 25

26 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/ JOTU2014/Kari Systä 26

27 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 JOTU2014/Kari Systä 27

28 Tiejärjestelmän hankintaprosessi (Tietojärjestelmän hankinta - Ohjelmistotoimittajan ja -ratkaisun valinta. TTL-julkaisusarja, Helsinki 2005) JOTU2014/Kari Systä 28

29 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 JOTU2014/Kari Systä 29

30 Tietojärjestelmähankkeiden onnistuminen vuosina Onnistunut Epäonnistunut Haasteellinen Lähde: The Standish Group. Chaos Summary for 2010 [WWW] Saatavissa: (Uudelleen visualisoitu Erkka Vastamaan diplomityössä) JOTU2014/Kari Systä 30

31 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 Lähde: The Standish Group. The Standish Group Report CHAOS [WWW]. 1995, Saatavissa: JOTU2014/Kari Systä 31 (Uudelleen visualisoitu Erkka Vastmaan diplomityössä)

32 JOTU2014/Kari Systä 32

33 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 JOTU2014/Kari Systä 33

34 VR:n lippu-uudistus ( 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 JOTU2014/Kari Systä 34

35 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 JOTU2014/Kari Systä pohdintaa. 35 Asiakas

36 Oulun seudun päivähoito ( Luennolla pohdittiin eri näkökulmia ja spekulaatioita JOTU2014/Kari Systä 36

37 Oulun seudun päivähoito ( Tietoviikko : 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 JOTU2014/Kari Systä 37

38 Oulun seudun päivähoito ( 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 JOTU2014/Kari Systä 38

39 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 JOTU2014/Kari Systä 39

40 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 JOTU2014/Kari Systä 40

41 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ää JOTU2014/Kari Systä 41

42 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ä JOTU2014/Kari Systä 42

43 Abrahamsson ja Mikkonen Helsingin sanomien vieraskynä (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 euron hankinnat. Järjestelmien kehittäminen jaetaan projekteiksi, jotka kilpailutetaan JOTU2014/Kari Systä 43

44 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 JOTU2014/Kari Systä 44

45 Avoin menettely Taustamateriaalia Ei käsitelty luennoilla Lähde: JUHTA julkisen hallinnon tietohallinnon neuvottelukunta. JHS Neuvottelumenettelyjen käyttö ICT-hankinnoissa [WWW] , [ JOTU2014/Kari Systä 45 Sekä Erkka Vastamaan diplomityö

46 Rajoitettu menettely Taustamateriaalia Ei käsitelty luennoilla Lähde: JUHTA julkisen hallinnon tietohallinnon neuvottelukunta. JHS Neuvottelumenettelyjen käyttö ICT-hankinnoissa [WWW] , [ JOTU2014/Kari Systä 46 Sekä Erkka Vastamaan diplomityö

47 Neuvottelumenettely Taustamateriaalia Ei käsitelty luennoilla Lähde: JUHTA julkisen hallinnon tietohallinnon neuvottelukunta. JHS Neuvottelumenettelyjen käyttö ICT-hankinnoissa [WWW] , [ JOTU2014/Kari Systä 47 Sekä Erkka Vastamaan diplomityö

48 JOTU2014/Kari Systä 48

49 JOTU2014/Kari Systä 49

50 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ö JOTU2014/Kari Systä 50

51 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 JOTU2014/Kari Systä 51

52 Avoimet rajapinnat - esimerkki JOTU2014/Kari Systä 52

53 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 JOTU2014/Kari Systä 53

54 Komponentit Flash sovellus - puoliavoin JPEG-kuva - yleinen standardi JOTU2014/Kari Systä 54

55 JPEG avoin? ( 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 JOTU2014/Kari Systä 55

56 Rajapinnat liiketoiminnan mahdollistajina Flash sovellus Flash sovellus Plugin Plugin Selain Selain Ohjelmointikieli ja kirjasto Käyttöjärjestelmä JOTU2014/Kari Systä 56

57 Serverin pää voisi olla Sovellus Ohj kieli (PHPI HTTP-palvelin Ohjelmointikieli ja kirjasto (C++) Käyttöjärjestelmä JOTU2014/Kari Systä 57

58 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 JOTU2014/Kari Systä 58

59 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ä JOTU2014/Kari Systä 59

60 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ä JOTU2014/Kari Systä 60

61 Esimerkkinä Java ME Taustamateriaalia Ei käsitelty luennoilla Yhteensopivuus Valmistajan pelivara Yksi digtaattori takaisi yhteensopivuuden, mutta onko tulos silloin avoimiuus? JOTU2014/Kari Systä 61

62 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 JOTU2014/Kari Systä 62

63 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 JOTU2014/Kari Systä 63