Waterfall model

Alt planlegges, alt utvikles, alt testes. Foss - vannfall. Hvis den er i bruk i dag brukes det gjerne i kombinasjon med smidige metoder, på en eller annen måte.

Incremental development

Man deler opp det ferdige produktet og utvikler det inkrementelt. En del av gangen. Jamfør Scrum, agile osv.

Reuse-oriented software engineering

Går ut på at produktet baseres på ferdige rammeverk og moduler. Skriver kode der kode mangler.

Spesifikasjon

• Feasibility study: Finnes det eksisterende produkter som allerede dekker behovene?
• Requirements elicitation and analysis: samle informasjon og analysere denne for å finne behovene til kunden
• Requirement speicification: Skrive spesifikasjon
• Requirement validation: Se til at kravene er innenfor "kravenes krav" (se Kapittel 4: Requirements engineering). Går stort sett ut på å sjekke at kravene er relaistiske, konsistente og fullstendige.

Design og implementasjon

• Architectural design: den overordnede strukturen til systemet
• Interface design: definer hvordan komponenter skal fungere sammen, altså interface/grensesnitt mellom komponenter
• Component design: hvordan skal komponenter fungere
• Database design: databasen, hvordan skal den være.

Validering

• Development testing: utviklerne tester at komponenter fungerer som de skal
• System testing: Komponenter integreres med hverandre og man tester at de fungerer sammen
• Acceptance testing: Siste tester for å sjekke at systemet er klart for bruk. Gjøres gjerne med kunde

Evolusjon

Etter utgivelse kan man gjøre store endringer i produktet, og videreutvikle det. Dette er gjerne den aktiviteten som tar mest tid og koster mest penger.

Prosessen

1. Inception (Innleding): Etablere business case for systemet - hvor skal det være i bruk?
2. Elaboration (Utforming): Utvikle en forståelse av for problemets domene, etablere arkitektuelt rammeverk, prosjektplan osv.
3. Construction (Bygging): Systemdesign, implementasjon og testing
4. Transition (Overgang): Bevege systemet fra et utviklingsmiljø til et brukermiljø

Fundamentale best practices

Disse er viktige best practices for RUP.

1. Utvikle programvare interaktivt
2. Behandle krav
3. Bruke komponentbaserte arkitekturer
4. Modeller programvaren visuelt
5. Verifiser kvalitet
6. Ha kontroll på forandringer

Tjenesteorientering

Prinsipp: Funksjonalitet og ytelsesnivå skal være hovedhensyn ved utvikling av IT-løsninger. IT-tjenester som er nødvendig for å understøtte hele eller deler av en eller flere arbeidsprosesser skal identifiseres.

Forklaring: Dette bidrar til å bryte opp siloer, både innad i egen virksomhet og på tvers av sektorer, som igjen legger til rette for gjenbruk.

Komponenter kan være nasjonale felleskomponenter, sektorvise felleskomponenter eller virksomhetsspesifikke komponenter.

Konsekvenser: Gjenbruk bidrar til raskere og mer kostnadseffektiv utvikling. Virksomheten bør sørge for at løsninger og komponenter er modulariserte, løst koblede og har veldefinerte grensesnitt.

Virksomheter skal vurdere om de har løsninger eller komponenter som kan gjenbrukes eller har relevans for hele eller andre deler av offentlig sektor.

Interoperabilitet

Prinsipp: Virksomheten og dens IT-løsninger må ved behov kunne samhandle med andre. Dette skal sikre effektiv informasjonsflyt og sørge for at IT-løsninger i staten støtter arbeidsprosesser og regelverk.

Forklaring: Vi skiller mellom tre typer interoperabilitet:

• Organisatorisk: Samordning av arbeidsprosesser, avtaleverk og endringer av organisatoriske forhold.
• Semantisk: Avklare meningsinnholdet for informasjonselementene som utveksles.
• Teknisk: Å bruke tekniske standarder som legger til rette for veldefinerte grensesnitt.

Denne samhandlingen skal ikke foregå dersom det er juridiske hindre for det.

Konsekvenser: Samhandling vil vi gode økonomiske konsekvenser; man bør alltid tenke på samhandling når man går i gang med et prosjekt.

God samhandling forutsetter at du tar hensyn til alle de ulike delene av interoperabilitet. Man må vurdere ut fra skjønn hvilken av formene for samhandling som skal vektlegges mest.

• Organisatorisk interoperabilitet: Avklar regelverk, finansiering og driftsavtaler. Mål, roller, ressurser, ansvar og krav må gjøres tydelige og være likt forstått blant alle parter.
• Semantisk interoperabilitet: Sørg for å ha felles begreper om det du skal samhandle om. Sørg for at dette stemmer med regelverk og lov.
• Bruk av forvaltningsstandarder og åpne standarder: Ved valg av standarder (for organisasjon, semantikk og det tekniske) skal Referanskekatalog for IT-standarder i offentlig sektor følges. Der den ikke gir et klart svar, skal du bruke en åpen standard.

Tilgjengelighet

Prinsipp: Elektroniske tjenester skal være tilgjengelige når brukerne trenger dem, lette å finne frem til og brukervennlig og universelt utformet.

Forklaring: Tjenester skal kunne benyttes av alle relevante brukergrupper uten å diskriminere noen. Dette gjelder særlig tjenester rettet mot allmenheten. Se diskriminerings- og tilgjengelighetsloven og annet relevant regelverk.

Konsekvenser: Vurder følgende når du etablerer nye elektroniske tjenester:

• Valg av standarder: Ta utgangspunkt i referansekatalogen for IT-standarder i offentlig sektor og forskrift om IT-standarder i offentlig forvaltning ved valg av standarder. Når svar ikke finnes, bruk åpne standarder.
• Kanalvalg: Gjør tjenesten tilgjengelig i de kanaler (PC, mobiltelefon, osv.) som er egnet og relevante. Vær forutsigbar og gjenkjennelig.
• Publisering: Det skal være lett å finne frem til; ikke tro at brukeren vet hvordan forvaltningen er organisert.
• Språktilpasning: Tjenestene bør være tilgjengelig på målgruppens språk. (Her vil jeg personlig legge til at man bør bruke et klart språk; unngå bruk av departementsspråk eller flotteri av typen feilbruk av «i forhold til» og «problematikken med hensyn på» i stedet for «problemet med».)
• Åpningstid: Tilgjengeligheten til elektroniske tjenester skal være basert på brukernes behov. Som regel døgnet rundt, men selvangivelsen trenger f.eks. kun å være tilgjengelig visse deler av året. Dette handler selvsagt ikke om behandlingstid; offentlige ansatte kan ikke forventes å være tilgjengelige til alle døgnets tider.
• Teknologiuavhengighet: Tjenestene bør, så langt det lar seg gjøre, være teknologi- og plattformuavhengige.

Vurder å involvere relevante brukergrupper i utvikling, testing og implementering.

Sikkerhet

Prinsipp: Behandle løsningen og informasjonen som er involvert med utgangspunkt i formelle og risikobaserte krav. Disse skal sikre konfidensialitet, integritet og tilgjengelighet. Med andre ord, driv tjenestene sikkert, men sørg også for at de er tilgjengelige.

Forklaring: Sikkerhet er nødvendig for at folk skal stole på offentlig sektor. Du må ta utgangspunkt i eForvaltningsforskriften, personopplysningsloven, sikkerhetsloven og regler om taushetsplikt.

Oppfyll krav til konfidensialitet; ikke noe innsyn for uvedkommende.

Ivareta integritet: Ikke la informasjon bli utilsiktet eller urettmessig endret. Det bør være mulig å spore hvem som har foretatt endringer og når.

Informasjon skal være tilgjengelig for de personer og på de tidspunkt det er besluttet. Finn en balanse mellom tilgjengelighet og konfidensialitet.

Dette prinsippet kan begrense andre prinsipper dersom det er avgjørende.

Konsekvenser: Virksomheten må kartlegge krav som er relevante for sikkerhet, særlig med tanke på regelverk, instrukser og avtaler med tredjeparter, og dokumentere at tjenesten oppfyller disse kravene.

Du må også:

• Kartlegge hvilket informasjons hvilket informasjonsinnhold løsningen skal omfatte.
• Ha definert et nivå for hvilken risiko som kan aksepteres
• Gjennomføre en risikoanalyse av løsningen.
• Gi den et passende sikkerhetsnivå.
• Implementere sikkerhetstiltak som passer det sikkerhetsnivået dere har vedtatt.
• Teste at tiltakene fungerer som forventet.

Sikkerhetsnivået må kunne endres ved behov.

Åpenhet

Prinsipp: Virkemåten og datagrunnlaget til IT-løsinger skal kunne gjøres rede for.

Forklaring: Dette skal understøtte rettssikkerheten ved at folk skal kunne bli kjent med hvilke prinsipper som ligger til grunn for avgjørelser.

Dette er særlig relevant for IT-løsninger som fungerer som beslutnings- eller beslutningsstøttesystemer og som har betydning for den enkeltes rettigheter eller plikter.

Konsekvenser: For å ivareta prinsippet må avgjørelsene dokumenteres og være sporbare. Dette betyr også at du må kunne redegjøre for datagrunnlag og regelanvendelse dersom dette skulle trenges.

Kravene til bruk av forvaltningsstandarder er beskrevet i punktene om interoperabilitet og tilgjengelighet.

Fleksibilitet

Prinsipp: Løsningene skal være utformet slik at de ikke fremstår som begrensende for endringer i arbeidsprosesser, innhold, organisering, eierskap og infrastruktur.

Forklaring: Virksomhetenes behov og oppgaveløsning skal være hovedhensynet når man utvikler nye IT-løsninger. Dette er for at løsningene ikke skal bli ubrukelige eller kreve store omlegginger dersom virksomheten endrer seg.

Konsekvenser: Dette krever at man er god på å modularisere. Dette vil som bonus gi mulighet for økt gjenbruk. Organisatoriske forhold må kunne endre seg, f.eks. avtaler med driftsleverandører, lisensavtaler eller brukerstøtte.

Forvaltningsprosessene må kunne fange opp og behandle behov for endring.

Vurder graden av fleksibilitet ut fra forventede endringbehov og antatte merkostnader.

Skalerbarhet

Prinsipp: Ved endringer i bruksbehov, skal IT-løsninger kunne skaleres.

Forklaring: Det er viktig at man skal kunne tilpasse seg økt brukervolum, nye krav til responstid osv.

Konsekvenser: Nok en gang er modularisering et stikkord; dette gjør det lett å opp- og nedskalere, også etter at systemene er satt i drift.

I tillegg til å forutsi økt brukervolum, må du også tenke på at avtaler med driftsleverandører, lisensavtaler eller brukerstøtte kan endre seg. Nok en gang må forvaltningsprosessene kunne fange dette opp.