Skip to main content

Livssyklus

Livssyklus gir forutsigbarhet for brukarar og konsumentar av våre leveransar. Det gir tryggleik for at det dei tek i bruk vil vere stabilt over tid.

  • Produkt og tenester endrar sjeldan livssyklus.
  • Prosessar, komponentar og API som er under tjenestane skiftar tilstand oftare.

Livssyklusfaser​

Vi deler livssyklus inn i følgande hovudfaser og statusar:

Det som skal erstattast eller avviklast setjast i frys, det vil ikkje skje noko vidareutvikling og det foregår kun kritisk feilretting og vedlikehold.

Konsept​

Denne fasen vil oftast dreie seg om prosessar og delprosessar, samt funksjonalitet som skal understøtte dei. Her ønsker vi å synliggjere kva slags konsept vi ser på, slik at ein kan komme med nyttige innspel og vite kva Sikt held på å utforske innanfor Studieadministrasjon.

Innsikt​

Når vi skal ta til med noko nytt eller gjer eit løft på noko eksisterande så vil vi starte med eit innsiktsarbeid for å kartlegge behov og moglegheiter. Det er ikkje sikkert at noko som er under innsikt vil bli jobba vidare med.

  • Utforsking om behov
  • Kan brukast for å utbedre eksisterande løysingar
  • Kan bli avbrutt og kasta eller lagt på vent

Design​

Om innsikten viser at det er ein løysing vi vil jobbe vidare med så vil vi sjå vidare på design av løysing. Dette kan resultere i ein endring av status på ein eksisterande prosess, tjeneste og/eller spørring og endring i API.

  • Brukarinvolvering i form av design og bruksmønstre
  • Brukartesting på brukarreise
  • Kan bli avbrutt og kasta eller lagt på vent

Initiering​

Når vi har kartlagt og designa så går vi over i initieringsfasen. Då vil vi byrje å realisere det vi har komme fram til i den førre fasen, og vi vil jobbe med å få ut ei testbar løysing som er kontrollert av Sikt, slik at vi kan få tilbakemeldingar så tidlig som mulig.

Implementasjon​

Når noko er under implementasjon betyr det at det framleis er utilgjengeleg, men det gir synlighet på kva vi aktivt jobbar med.

  • Arbeid er i gang for å realisere ei løysing
  • Brukarinvolvering i form av brukertesting
  • Gjeld stort sett prosess, funksjonalitet eller graph API

Eksperimentell​

Status eksperimentell betyr at det er tilgjengelig og kan prøvast ut, men at det er under utvikling og kan endre seg utan forvarsel. Her ønsker vi å høre om det er nokon som ønskjer å prøve ut løysinga i produksjon.

  • Moglegheit for høg grad av brukarinvolvering
  • Regelmessige bakoverinkompatible endringar
  • Løpande oppdateringar utan forvarsel

Produksjon​

Når vi har sørga for at noko er sikkert og klart for bruk så går vi over i stabil fase. Her vil vi jobbe med kontinuerlig produktutvikling og vi vil gjere gradvise tilpassingar ved behov, men ikkje noko som brekk eksisterande funksjonalitet.

Beta​

Når det er i beta kan det takast i bruk i produksjon, men det er ikkje fullstendig og ein kan forvente varsla endringar. Beta-funksjonalitet har auka brukarmedvirkning då entiteten framleis utbedrast, og vi kan gjere endringar fortløpande.

  • Høg grad av brukarinvolvering
  • Bakoverinkompatible endringar
  • Løpande oppdateringar med kort forvarsel

Stabil​

Det som har status stabil kan brukast som vanlig utan spesielle hensyn. Her vil det komme løpande oppdateringar etter behov. Brukarstøtte følger overordna SLA og går via kontakt@sikt.no.

  • Vanleg brukarstøtte
  • Årlig versjonsoppgradering med bakoverinkompatible endringar
  • Løpande oppdateringar med lang forvarsel

Avvikling​

Når tenester og komponentar av ulike grunnar treng å skiftast ut eller avviklast, så vil vi gå inn i avviklingsfase. Dette kan f.eks. vere grunna lite bruk og endring i lov og regelverk, eller det kan vere at vi har funne ein måte å automatisere bort deler av ein prosess eller liknande.

Ingen vidareutvikling​

Det som har status ingen vidareutvikling kan brukast som vanlig, men det er fryst for tillegg av ny funksjonalitet. Kva som vil skje med applikasjonen eller tenesta framover er enno ikkje bestemt.

  • Vanleg brukarstøtte
  • Retting av nye, kritiske feil i samsvar med definert alvorlighetsgrad.
  • Endringar som følgje av lovpålagte krav
  • Tiltak knytt til informasjonstryggleik
  • Endringar som må gjøres for å ivareta grunnfunksjonaliteten i applikasjonene og tjenestene som en konsekvens av moderniseringsaktiviteter.

Erstattast​

For dei applikasjonane og tenesta som har status erstattast, er det bestemt at behova den dekkjar som fortsatt er relevante, skal dekkjast i nye applikasjonar eller tenester. Institusjonar må førebu seg på å ta i bruk erstatninga.

  • Vanleg brukarstøtte
  • Retting av nye, kritiske feil i samsvar med definert alvorlighetsgrad.
  • Endringar som følgje av lovpålagte krav
  • Tiltak knytt til informasjonstryggleik
  • Endringar som må gjøres for å ivareta grunnfunksjonaliteten i applikasjonene og tjenestene som en konsekvens av moderniseringsaktiviteter.
  • Avviklingsdato varslast eitt år i forveien
  • Kan avviklast etter endt dato

Avviklast​

Noko som skal avviklast vil etter eit gitt tidspunkt bli gjort utilgjengelig. Dette betyr at brukarens institusjon må  forberede seg på å avvikle bruk av denne entiteten. Tida tilgjengelig for overgang er perioda fram til gitt dato.

  • Varslast eitt år i forveien
  • Retting av nye, kritiske feil i samsvar med definert alvorlighetsgrad.
  • For utviklarar; Vil setjast som deprecated

Avvikla​

Ein entitet som er avvikla skal ikkje vere tilgjengelig for bruk. Sjølv om entiteten er avvikla, så må vi gjere eit arbeid for å ta den ned, dette kan skje når som helst når entiten har status avvikla.

  • End of service. Ingen support.
  • End of life. Ikkje bruk, sjølv om det er tilgjengelig fram til vi faktisk har skrudd av.

Viktige datoar for livssyklushandtering​

Årlig hovudrelease foregår i april. Entiteter som skal avviklast skal varslast om før hovudrelease for at vi forsvarlig kan skru det av ved neste hovudrelease. Unntak her kan vere dersom vi ser at bruken allereie er avvikla og vi kan skru av tidlegare.