Kooste kotitehtävien vastauksista Kotitehtävä 6 - Ylläpito- ja kehittämismalli 29.4.2011
1.) Järjestelmän ylläpitomalli? ja 2.) Järjestelmän jatkokehittämismalli? OPH on omistaja ja ylläpitäjä ja huolehtii koko järjestelmästä, säilyttäen kokonaisnäkemyksen ja vastuun Tarvitaan ainakin seuraavat ryhmät Päätöksentekoryhmä: korkeakoulut, Opetushallitus sekä opetus- ja kulttuuriministeriö (sekä ehkä CSC) yhdessä Tilaajaryhmä: Korkeakoulujen on perustettava tilaajaorganisaatio kaikkia yhteisiä IT-järjestelmiä varten. Sitä voidaan käyttää myös KSHJ:n kehittämisessä. Ylläpitoon ja hallintaan voisi soveltaa Raketti-OPIn pelisääntötyöryhmän tuloksia
Kehittäminen ja ylläpito jaetaan kahteen ryhmään: ydinjärjestelmä ja erilliset lisämoduulit Ydinjärjestelmään tehtyjen lisäominaisuuksienkin ylläpidosta vastaisi OPH, vaikka nämä lisäominaisuudet olisivatkin tilattu korkeakouluvetoisesti. Erillisien lisämoduulien (niissä tapahtuvat muutokset/ virheet/ katkokset eivät vaaranna ydinjärjestelmän/ muiden korkeakoulujen toiminnallisuutta) ylläpidosta voivat vastata korkeakoulut itse. Jos jokin korkeakoulu tms. kehittää/ kustantaa lisäominaisuuden, tulee se kaikkien käyttöön. Vain maksajat voivat tehdä määrittelyä Myös erillisten moduulien toteuttamiseen on saatava lupa päätöksentekoryhmältä
Korkeakoulujen tekemiin virheraportteihin on saatava kuittaus ja virheraportin tekijän on pystyttävä seuraamaan asian käsittelyä (esim. Jira) Tiedotus järjestelmälle tehtävistä huolto- ja muutostoimenpiteistä tulee toimia, esim. muutoksista rajapintoihin saatava tieto jo hyvissä ajoin ennen muutoksen tekemistä. On myös mietittävä, kenellä on testausvastuu ydinjärjestelmään toteutettavien ominaisuuksien osalta ja mitä tämä vastuu käytännössä tarkoittaa. Kehittämisvaiheessa voidaan opetella moderni ohjelmistokehityskonsepti, jota voidaan käyttää myös järjestelmän jatkokehityksessä. Viemällä käsitemäärittelyä, käyttöliittymäprotoilua, rajapintamäärittelyä, tietokantamäärittelyä ja käytettävyysarviointia koko ajan rinnakkain eteenpäin varmistetaan työn nopea eteneminen. Samalla työtä voidaan hajauttaa esim. useammalle kehittämisryhmälle tai toimittajalle.
3.) Ylimääräisten sovelluskustannusten laskuttaminen korkeakouluilta? Ainoastaan kaksi korkeakoulua vastusti Periaatteena: lasku jos on syntynyt haittaa hakijalle Hinnasto tulee olla selvillä etukäteen Korvaukset useaan suuntaan: atk-toimittaja korkeakoulu OPH
4.) Miten huolehditaan siitä, että riippuvuutta tiettyyn järjestelmätoimittajaan ei synny? Onnistunut kilpailutus ja onnistunut sopimus Tilausvaiheessa on määriteltävä, että Opetushallitus omistaa ohjelmakoodin kokonaan tai ainakin tilaajalla on oltava ohjelmistoon samanarvoiset oikeudet kuin tuottajalla. Palastelu: tilataan valmis kokonaisuus, ylläpito ja jatkokehitys erikseen Sopimuksen tulisi mahdollistaa ns. alihankkijoiden käyttö Useampi kuin yksi toimittaja Ohjelman oikeudet ja ajantasainen lähdekoodi tulee säilyttää OPH:lla
Järjestelmän modulaarisuus: pienemmät toimittajat mukaan JHS-suositusta 169: avoin lähdekoodi, avoimet rajapinnat Dokumentaatio: selkeä, ajantasainen, siirrettävä, riittävän laaja Työkalut: yleisiä, toimittajista, laitteista ja käyttöjärjestelmistä riippumattomia Ketterä toteutus: nopea korjausliike esim. määrittelyjen tarkentuessa Näkymien ja raporttien itsenäinen räätälöintimahdollisuus Määräaikainen järjestelmätoimijoiden ja -toimittajien kilpailuttaminen
5.) Palaute ja onnistumisen mittaaminen? OPH kerää keskitetysti palautteet, virheet ja kehittämisideat: järjestelmästä ja palvelukokonaisuudesta sekä prosessin sujuvuudesta, hakijoilta, virkailijoilta ja korkeakouluilta Palautteet ja kehittämisideat käsitellään kehittämis-/ yhteistyöryhmässä, joka tekee toimenpide-ehdotukset ohjausryhmälle Ohjausryhmässä tehdään lopulliset linjaukset kehittämiskohteista. Palautetta voitava antaa jatkuvasti ja monikanavaisesti Koonti ja jatkotoimenpiteet tiedoksi korkeakouluille Kehitystiketit ja niiden kautta tapahtuva priorisointi