IT kontrakter 2015 - Godkendelseskriterier og ændringshåndtering

IT-arkitektur IT-governance Udvikling Udbud

IT kontrakter 2015Godkendelseskriterier og

ændringshåndtering

Baseret på et konkret projekt


Henrik Gørup Rasmussen – Konsulent, partnerSilverbullet

• Silverbullet

– Stiftet i 2003

– 5 partnere, i alt 24 M/K

– Kontorer i København og Århus

– Det lidt aparte navn stammer fra Frederick P. Brooks (amerikansk videnskabsmand indenfor datalogi) som erkendte der ikke, modsat indenfor hardware (Moores lov), er en kontinuerlig effektivisering indenfor udvikling og leverance af systemer.

– Dvs. No Silver Bullet indenfor software udvikling og systemleverancer.


Primære arbejdsområder

• Silverbullet har 4 primære arbejdsområder

– IT-arkitektur

– Udbud

– Udvikling

– IT-Governance

• Silverbullet har mange offentlige kunder, men også en del kunder i den private sektor

• Silverbullet har speciale indenfor sundheds IT


Indlægget tager udgangspunkt i et konkret projekt

• Flere projekter hvor der anvendes en kravspecifikation i traditionel forstand, hvor kunden ønsker:– Indflydelse i systemkonstruktionsfasen på hvordan kravene opfyldes

– Løbende leverancer for at kunne verificere at løsningen bliver som ønsket

– Vha. tidlig præcisering, undgå stort antal ændringsønsker

– Vha. klare godkendelseskriterier i de løbende leverancer, undgå størstedelen af de disputer der vedrører de kravspecifikke godkendelseskriterier

• Men ikke ønsker et agilt projekt• Dermed ikke en K03 kontrakt

• Kan måske kaldes K01.5, eller Scrum-fall


Baseline og nedbrydning

KravUse cases

KravsbesvarelseUse case beskrivelserLøsningsbeskrivelse

Forretningsfeatures

Systemfeatures Product backlog item (Tasks)

Forretnings-feature

Baseline

Nedbrydning

• Der er flere lag af krav

• Krav i kravstabeller

• Use cases

• Tekst der omgiver krav/use cases

• Øvrigt kontraktmateriale

Kunden Leverandøren Kunde + Leverandør

- foretages af leverandøren


Leverancemodel – Iterativ (elefantfoden)

Page 6

KundetestIteration

Formålet med denne tilgang er:

• Løbende at verificere løsningen – leveres det som er specificeret i kravene

• Løbende at validere løsningen – får vi den forretningsmæssige ønskede løsning

• Løbende at sikre kvaliteten af leverancerne – sikre den forventede kvalitet

Formelle prøver


Standard Iteration – 3 ugers varighed

Uge 2Uge 1 Uge 3

Demo

Præsentation af den leverede funktionalitet i iterationen

Planlægningsmøde af næste iteration. (Forretningsfeatures)

Der skal være beslutningskraft ved demoen

Prioriteringsmøde

Workshop hvor der arbejdes med de forretningsfeatures der ønskes præciseret i Iterationen.

Udarbejdelse af godkendelseskriterier og testcases

Koordineringsmøder

Status på fremdrift

Koordinering af opgaverne uddelegeret på prioriteringsmødet.


Sporopdeling (moduler)

Iteration 1 Iteration 3Iteration 2 Iteration NSpor 1






Demotyper

• Koncept demo– Koncept demo’en er den tidligste form for demonstration, som

leverandøren viser for kunden. Demo’en er kendetegnet ved at være af konceptet i ”skitse” form, det vil sige, at der ikke er implementeret noget endnu.

• Prototype demo– Prototype demo’en indeholder en implementeret prototype, det kan

fx være et skærmbillede, et koncept for interaktion med en menu, eller en initiel udveksling af data mellem to eller flere systemer.

• Funktionel demo– Den funktionelle demo foretages af leverandøren på den software

som ønskes overgivet til kundetest. Formålet er at give leverandøren mulighed for at demonstrere den tiltænkte brug af løsningen, inden kunden påbegynder test af den – og dermed klæde kunden på til gennemførelse af testen.


Funktionel demo

• Den funktionelle demo viser et udsnit af funktionalitet i det (de) pågældende spor der leveres i iterationen

• Her arbejdes med godkendelseskriterier og testcases

• Kunden skal give en skriftlig tilbagemelding på demo’en, dvs. hvilke elementer kan godkendes og hvilke der ikke kan godkendes

• Dermed giver kunden en foreløbig accept af det leverede, som møder godkendelseskriterierne.

• Praktisk bør kunden have adgang til systemet før og efter demoen, således de kan forberede sig, og følge op på punkter hvor der er usikkerhed


Præciseringer

• Præciseringer tidligt i forløbet skal imødekomme behovet for en stor del af de ÆØ der ellers traditionelt ville komme sent i forløbet

• Præciseringer kan have karakter af ‘Word’ præciseringer

• De kan også have karakter af demoer, både konceptuel, prototype og funktionel demo

– Leverandøren kommer sædvanligvis med første bud en forretningsfeature, så præciseringerne kan foretages ved demoen

– Jo højere færdiggørelsesgrad (dvs. jo tættere på funktionel demo), jo kortere vej til beslutninger

• Præciseringer er omkostnings- og tidsmæssigt neutrale


Godkendelseskriterier - Principper

Godkendelseskriterierne er skrevet ud fra følgende principper:• Tag udgangspunkt i kravet eller use casen• Brug de begreber afklaringsfasen har fundet frem til, så det kan relateres

til øvrig dokumentation. • Hvis en forretningsfeature dækker over flere delområder, så opdel

godkendelseskriterierne i de enkelte delområder (spor).• Opdel om muligt godkendelseskriterierne i grundfunktionalitet (Opret,

Opdater, Slet, Vis), og derudover øvrig funktionalitet mv.• Skriv alle aftalte værdier samlet i grupper, således det er let at overskue • Brug ensartet sprog og form. Generelt er der forsøgt brugt ’Det er muligt

at….’, som indledning. De enkelte udsagn kan man dermed sige ja eller nej til i forbindelse med en afprøvning af systemet ud fra acceptkriterierne.

• Generelle acceptkriterier som er gennemgående i løsningen hører til i generelle features– Fejlbeskeder, håndtering af manglende indtastning i krævede felter,

søgning, oversigter mv.


Godkendelseskriterier - eksempel

Godkendelseskriterie til forretningsfeature: AdmBruger

Opret Bruger

Status

Overordnet område: Oprettelse af BrugerOpretDet er muligt at Oprette en Bruger ud fra en anmodning oprettet i

Brugerselvbetjening Oprette en Bruger med et unikt nummer iht.

Brugernummerserien for området Registrere en Brugers informationer jf. feltdefinitionerne Kontrollere om data relateret til oprettelse af Bruger er i

overensstemmelse med regler og feltdefinitioner


Godkendelseskriterier - eksempelGodkendelseskriterie til forretningsfeature: AdmBruger

Opret Bruger

Status

Overordnet område: Oprettelse af Bruger

OpdaterDet er muligt at ændre en alle informationer på en Bruger på nær

Brugernummeret. kontrollere om ændringer af en Brugers informationer er i

overensstemmelse med regler og feltdefinitioner

Det er ikke muligt at At ændre et Brugernummer

Vis• Det er muligt at se en Brugers informationer


Køkkenprojekt - eksempel

- 3 spor + tværgående spor

- Køkkenelementer

- Hårde hvidevare

- Klinker og gulve

- Tværgående: el og vand

Spor: Hårde hvidevare

- Afklaringsfasen: Hvilke typer hårde hvidevarer?

- Præcisering: Hvilken type opvaskemaskine og placering?

- Demo: Kvalitativ vurdering: Type, placering, el/vand, bestikkurv, antal kuverter, tid, støj mv.

- Kundetest/afsluttende test: Ændre type bestikskurv (går tilbage i processen som product backlog item – leveres i næste iteration)

En sådan ændring på et sent tidspunkt i leverancen, ville typisk ikke være mulig uden en ÆØ


Hvorfor får vi ÆØ – hvor er tvisterne

• Elementer kunden alligevel ikke har brug for (negativ)

• Elementer kunden har brug for, men ikke kravsat

• Elementer som leverandøren har tilbudt, men ønsker at ændre

• Tvister

– Områder hvor kunden har stillet for vage/uklare krav

– Områder hvor leverandøren ikke er kommet i bund med forståelsen af det efterspurgte. Typisk bliver det tilbudte dermed også beskrevet vagt/uklart/overordnet.

– Meget fokus på den primære brugervendte funktionalitet og konkrete servicemål

• Dermed mindre fokus på områder som ligger lidt i periferien, eller er vanskeligt forståelige for de der kender de primære forretningskrav


ÆØ – Proces - eksempel

Husk fasttrack! – ÆØ uden økonomi og scope ændringer


CB og CAB

• Change Board (CB)

– Projektets change board

– Afvikles når projektet er slut

– Skal sikre at ÆØ er tilstrækkeligt dokumenteret

– Skal sikre at ÆØ overordnet set ikke bringer projektet i fare

• Change Advisery Board (CAB)

– Produktets change board

– Starter på første produktionsdag

– Skal sikre at ÆØ er tilstrækkeligt dokumenteret

– Skal sikre at ÆØ ikke kompromitterer driften


Prøver

• Der var kravsat flg. obligatoriske prøver

– Fabrik, Installation, Konvertering, Delleverance, Overtagelse, Drift

• For alle Prøver, Tests og Reviews, var der beskrevet:

– Definition

– Formål

– Testens genstand

– Testdata

– Startkriterier

– Godkendelseskriterier

– Ansvar for testdata

– Ansvar for afvikling af prøven


Tests og reviews

• Der var lavet et katalog af test og reviews som leverandøren kunne byde ind med

– 10 funktionelle tests

– 13 non-funktionelle tests

– 2 reviews

• Baggrunden for denne tilgang var at tilgodese tilbudsgivere som bød med henholdsvist et udviklingsprojekt eller standard system, da disse to typer typisk giver to meget forskellige testforløb, med meget forskellig økonomi


Fordele ved modellen

• Det overordnede formål med modellen er at sikre at kunden får en anvendelig løsning, inden for de krav der er stillet

• Tidlig indsigt i leverandørens evne til at levere, både for så vidt angår kapacitet som kvalitet.

• Antageligvis kan mange ÆØ undgås (vha. præciseringer)

• Metoden er særdeles anvendelig hvis leverandøren udvikler off-shore, da krav bliver nedbrudt til Tasks, og dermed er beskrevet med et højt detaljeringsniveau, klar til at udvikle


Observationsområder

• Metoden fordrer en stor grad af kundedeltagelse tidligt i projektet.

– Om omfanget af kundedeltagelse er større eller mindre totalt set er uklart


Problemområder

• Risiko følger traditionelt mønster, trods kundens tidlige involvering

– Leverandøren får godkendt iterationer og kundetests løbende, men kan alligevel risikere ikke at få godkendt leverancen til sidst.

– Risikoen er dermed i stor udstrækning på leverandørens side.

• Metoden er ikke kendt af alle

– Det kan betyde at de første iterationer ikke når i mål, hvorfor det giver mening at have et begrænset indhold i disse

Presentations & Public Speaking

IT kontrakter 2015 - Godkendelseskriterier og ændringshåndtering