Luonnos

Betavaihe

Kettera_toteutus_03

Kuvaus

Betavaihe on käyttöönottoon tähtäävä vaihe, joka alkaa investointipäätöksellä ja päättyy päätökseen siitä, että palvelu on valmis julkaistavaksi. Betavaiheessa tapahtuu palvelun varsinainen kehitystyö, jonka aikana palvelua rakennetaan palvelusta vastaavan henkilön tiiviissä ohjauksessa. Kehittämisessä keskitytään niihin ominaisuuksiin, joista on käyttäjille eniten hyötyä (nk. MVP eli Minimum Viable Product, yksinkertaisimman käyttöönotettavissa olevan tuotteen ajattelumalli). Vaiheen kesto riippuu täysin palvelun laajuudesta.

 

Edellytykset betavaiheen aloittamiselle

Kokeiluvaiheen protoilun jälkeen betavaiheessa palvelua ryhdytään varsinaisesti kehittämään eli tässä syntyy ensimmäinen merkittävä investointi tulevan palvelun osalta. Tämän takia vaatimus alfavaiheesta betavaiheeseen siirtymiselle on tiukka: alfavaiheen testikäyttäjien on oltava laajalti tyytyväisiä alfavaiheessa kokeiltuun ratkaisuun, jonka pohjalta harkitaan betavaiheeseen siirtymistä.

Betavaihe tarvitsee rahoituksen, jonka osana on mietittävä myös tuotanto- eli ylläpitovaihe ja kaikki tarvittavat järjestelmäintegraatiot. Betavaiheen aluksi toteutustyö joudutaan yleensä hankkimaan. Hankinta tehdään ensisijaisesti puitesopimusten kautta ja lähtökohtaisesti ostamalla kehitysresursseja omaan käyttöön ja palvelusta vastaavan johdettavaksi. Julkaisua välittömästi seuraava ylläpito tulee sisällyttää hankintaan.

Kun valitaan ketterä toteutusmalli on huolehdittava siitä, että käyttäjätarinoihin on sisällytetty riskianalyysin ja tietoturvatason huomioon ottavat riittävät tietoturvallisuuspiirteet sekä muut tärkeät ei-toiminnalliset vaatimukset. Kehittäjätiimillä on myös oltava riittävä asiantuntemus valittujen ohjelmistokielten, kehitysvälineiden ja ohjelmistokehyksien tietoturvallisuuspiirteistä sekä globaalin kehittäjäyhteisön hyvistä käytännöistä.

  

Milloin betavaihe on onnistuneesti valmis

Betavaiheen jälkeen käynnistetään palvelun julkaisu tuotantoympäristöön aiemman palveluversion tilalle. Vaiheen päättyessä palvelun on oltava kypsä tuotantokäyttöön.

 

Milloin betavaihe täytyy toistaa tai siirtyä toisenlaiseen toteutusmalliin

Mikäli huomataan, että resurssipohjainen omassa ohjauksessa kehittäminen ei ole välttämätöntä vaan hankkeelle pystytään määrittelemään lopputulos vaikkapa tuotetta tai valmisratkaisua vasten, siirrytään betavaiheen sijaan perinteisen toteutuksen käynnistysvaiheeseen. Myös jos toteutuksen osana hankitaan valmisteknologiaa, hoidetaan tämä perinteisen toteutuksen työkaluilla.

Mikäli betavaiheen jälkeen tuotannon ylläpito- ja jatkokehitystyötä ei haluta enää omaan ohjaukseen, kehityksen voi ostaa ulkopuolelta ja käyttää toimittajan prosessia. Tällöin siirrytään betan jälkeen perinteisen toteutuksen transitiovaiheeseen.

Mikäli betavaiheen lopussa palvelu ei ole kypsä julkaistavaksi, betavaihetta jatketaan niin kauan kunnes riittävä valmius on saavutettu.



 

Betavaiheen kulku ja tuotokset

 

Beta eteneminen

Betavaiheen varsinainen tuotos on julkaistavaksi valmis palvelu, joka on tärkeimmiltä osiltaan käyttäjien hyväksymä, saavuttaa keskeiset onnistumiselle asetetut mittarit sekä läpäisee tietoturvallisuustarkastuksen.

Betavaiheessa pyritään taloudellisuuteen eli keskitytään niihin ominaisuuksiin, jotka tuottavat käyttäjille eniten arvoa, ja pidetään muiden toteutus yksinkertaisena (nk. MVP- eli Minimum Viable Product -ajattelu). 

 

Betan valmistelu

eli tarvittava suunnittelutyö ja päätökset toteutustyön kilpailuttamista ja/tai toteutuksen aloitusta varten


1. Kokonaisuus, arkkitehtuuri, tietosuoja ja -turva

Kokonaisuus (lisätietoa)

tarvittaessa lisäksi... 

  • Palvelun alfaversio (proto)
  • Kehitysjono (lisätietoa)

Arkkitehtuuri

  • Ratkaisuarkkitehtuuri, sisältäen toiminta-arkkitehtuurin, tieto- ja käsitemallit, loogisen ratkaisuarkkitehtuurin, rajapintakuvaukset sekä alustavat teknologiavalinnat
  • Reunaehdot -pohja (lisätietoa)

Tietosuoja ja -turva


2. Hankinnan valmistelu


3. Kilpailutus

eli puitesopimuksen hyödyntäminen tai avoimen, rajoitetun tai neuvottelumenettelyn mukaisen hankinnan läpivienti ja hankintapäätökset


 

Betan toteutus

eli itse beta-toteutuksen jatkuva suunnittelu- ja toteutussykli 


4. Scrum-menetelmä (lisätietoa)

sekä lisätyökaluja kehitysjonon hallintaan ja tekniseen toteutukseen


5. Havainnointi ennen julkaisua


Jatkuva raportointi ja eskalointi

eli edistymisen raportointi päätöksentekijöille

Työkaluja palvelusta vastaavalle näiden muodostamiseen:


Muutoshallinta

eli kokonaismuutokset sisältöön, budjettiin, kestoon tai vaiheistukseen


Tärkeimmät tehtävät

 

Asiakaslähtöisyys ja ohjaus

Palvelusta vastaava

  • Suunnitelma kehitystyön järjestämisestä betavaiheessa 
  • Vision päivittäminen sekä käyttäjätarinoiden kirjoittaminen ja priorisointi kokeilun käyttäjäpalautteen, teknisten tulosten ja sidosryhmäviestinnän perusteella
  • Jatkuva testaus
  • Käyttäjäpalautteen jatkuva analysointi ja suunnitelmien muokkaaminen sen perusteella
  • Palvelun esteettömyyden ja tietoturvan tarkkailu
  • Toteutuksen edistymisen ohjaaminen ja raportointi - sen varmistaminen, että käytettävissä olevassa kehitysajassa syntyy palvelun tavoitteiden ja käyttäjien tarpeiden kannalta tärkeimmät ominaisuudet

 

Johto-/ohjausryhmä

  • Viimeistään tässä vaiheessa mieluiten sama kokoonpano, joka vastaa palvelusta myös julkaisun jälkeen käyttövaiheen aikana
  • Päättää tehdäänkö investointi varsinaiseen palvelun toteutukseen. Tämä päätös myös valtuuttaa hankinnan aloittamisen.
  • Seuraa etenemistä kehityksen varrella ylätasolla, mittareista ja palvelun tavoitteesta käsin
  • Päättää vaiheen lopuksi onko palvelu valmis tuotantokäyttöön koko käyttäjäkunnalle eli voidaanko julkaisun valmistelu aloittaa

 

Toteutus

  • Betaversion rakentaminen tuotantoon yhteensopivalla tavalla (joko jatketaan siitä mihin alfaversiossa jäätiin tai aloitetaan alusta mikäli prototyyppi ei sopinut pohjaksi laajemmalle kehitykselle - aloitettaessa alusta palataan käytännössä alfavaiheeseen ja toistetaan se)
  • Kehitystyö kehitysmenetelmän ohjaamana, oletuksena Scrum
  • Jatkuva käyttäjäpalautteen huomiointi palvelusta vastaavan linjausten mukaan 
  • Jatkuva julkaiseminen ja integrointi DevOps-kulttuurin ohjaamana
  • Laadunhallinta valmiin määritelmällä sekä koodikatselmoinneilla
  • Mekanismi jatkuvan oppimisen takaamiseksi

 

Hankinta

Palvelusta vastaava

  • Vetää läpi betavaiheen hankinnan tehdään ensisijaisesti puitesopimusostona, tai tilanteen niin vaatiessa kilpailutuksena, jos esimerkiksi sopivaa puitesopimusta ei ole 
    • Betavaiheen toteutustyö on lähes aina laajempi kuin alfavaiheen toteutus, joten on todennäköistä, että kansallinen kynnysarvo (60 000 €) ylittyy ja hankinta joudutaan (mini)kilpailuttamaan
    • Ketterän toteutuksen hankintatapa on lähtökohtaisesti (henkilö-)resurssipohjainen eli hankitaan tietyn asiantuntemuksen omaavia tekijöitä palvelun kehitystyöhön tilaajan johdettavaksi, toisin sanoen ei osteta valmista tuotetta tai palvelua vaan henkilöresursseja kehittämishankkeen käyttöön
    • Toteutuksen osana on suositeltavaa hankkia myös välittömästi julkaisua seuraava ylläpito määräajaksi (esim. 6 kk)
    • Helsingin kaupungin hankintaohjeet (hankintakäsikirja) kuvaavat tarkemmin, miten hankinta tehdään
    • Sähköisen hankintapalvelun avulla hankinta toteutetaan käytännössä

 

Arkkitehtuuri

Palvelusta vastaava

  • Ratkaisee teknisten asiantuntijoiden kanssa, käytetäänkö alfavaiheen teknistä toteutusta varsinaiseen kehitykseen vai aloitetaanko alusta. Jos jatketaan prototyypin teknisellä ratkaisulla ja alfavaiheen proto näyttää valmiilta, on pinnan alla paljon tilapäisratkaisuja, joiden laatuvelka tulee maksettavaksi uudelleen kirjoittamisen muodossa
  • Teknisten asiantuntijoiden kanssa varsinaisen toteutusratkaisun suunnittelu ja teknisten reunaehtojen hahmottaminen

 

Toteutus

  • Alfavaiheen tekninen asiantuntija vastaa varsinaisen kehitystyön teknisen toteutustavan suosittelemisesta kokeilun tulosten perusteella
  • Järjestelmän dokumentointi osana kehitystyötä

 

Tietoturva

Palvelusta vastaava

  • Vastaa vaiheen aluksi betavaiheen tietoturva- ja tietosuojavaatimusten laatimisesta riskianalyysin tuloksena syntyvän riskienkäsittelysuunnitelman avulla. Yksinkertaisimmillaan käytetään selvitysvaiheessa tehtyä alustavaa riskianalyysiä. Tietoturvakriittisten kehityskohteiden osalta tarkennetaan ja syvennetään tässä vaiheessa aiempaa riskianalyysiä, koska alfavaiheessa on saatu uutta tietoa ja kokemusta käyttäjiltä sekä myös teknisten ratkaisujen toimivuudesta.  Tietoturva- ja tietosuojavaatimuksia käytetään hankintaprosessissa, ja ne dokumentoidaan osaksi Ratkaisuarkkitehtuuri, tietoarkkitehtuuri laatuvaatimukset ja tietoturvapiirteet -asiakirjaa.
  • Palvelun tietoturvatarkastusten organisointi. Ketterän kehityksen periaatteiden mukaisesti tarkastuksia kannattaa järjestää useita osana normaalia kehitysprosessia. Samalla on huolehdittava siitä, että kaikki kehitettävän järjestelmän osiot tulevat tarkastuksilla katettua ennen tuotantokäytön alkamista. Tietoturvatarkastusten tuloksia verrataan alkuvaiheessa asetettuihin tavoitteisiin, vaatimuksiin ja liian suuriksi arvioituihin riskeihin.

 

Johto-/ohjausryhmä

  • Käsittelee tietoturvallisuutta osana palvelun tavoitteista ja mittareista lähtevää ohjaustyötä

 

Toteutus

  • Arkkitehtuurin suunnittelu niin, että se tukee tietoturvallisuuden ja tietosuojan toteuttamista
  • Tietoturvallisuudesta ja tietosuojasta varmistuminen sekä kehityssprinteissä että testauksessa
  • Tietoturvaratkaisujen riittävä dokumentointi

 

Luonnos