SlideShare una empresa de Scribd logo
1 de 23
Descargar para leer sin conexión
IT-arkitektur IT-governance Udvikling Udbud
IT kontrakter 2015
Godkendelseskriterier og
ændringshåndtering
Baseret på et konkret projekt
IT-arkitektur IT-governance Udvikling Udbud
Henrik Gørup Rasmussen – Konsulent, partner
Silverbullet
• 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.
IT-arkitektur IT-governance Udvikling Udbud
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
IT-arkitektur IT-governance Udvikling Udbud
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
IT-arkitektur IT-governance Udvikling Udbud
Baseline og nedbrydning
Krav
Use cases
Kravsbesvarelse
Use case beskrivelser
Lø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
IT-arkitektur IT-governance Udvikling Udbud
Leverancemodel – Iterativ (elefantfoden)
Page 6
Kundetest
Iteration
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
IT-arkitektur IT-governance Udvikling Udbud
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.
IT-arkitektur IT-governance Udvikling Udbud
Sporopdeling (moduler)
Iteration 1 Iteration 3Iteration 2 Iteration NSpor 1
Iteration 1 Iteration 3Iteration 2 Iteration NSpor 2
Iteration 1 Iteration 3Iteration 2 Iteration NSpor 3
Iteration 1 Iteration 3Iteration 2 Iteration NSpor 4
Iteration 1 Iteration 3Iteration 2 Iteration NSpor 5
IT-arkitektur IT-governance Udvikling Udbud
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.
IT-arkitektur IT-governance Udvikling Udbud
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
IT-arkitektur IT-governance Udvikling Udbud
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
IT-arkitektur IT-governance Udvikling Udbud
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.
IT-arkitektur IT-governance Udvikling Udbud
Godkendelseskriterier - eksempel
Godkendelseskriterie til forretningsfeature: AdmBruger
Opret Bruger
Status
Overordnet område: Oprettelse af Bruger
Opret
Det 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
IT-arkitektur IT-governance Udvikling Udbud
Godkendelseskriterier - eksempel
Godkendelseskriterie til forretningsfeature: AdmBruger
Opret Bruger
Status
Overordnet område: Oprettelse af Bruger
Opdater
Det 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
IT-arkitektur IT-governance Udvikling Udbud
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 ÆØ
IT-arkitektur IT-governance Udvikling Udbud
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
IT-arkitektur IT-governance Udvikling Udbud
ÆØ – Proces - eksempel
Husk fasttrack! – ÆØ uden økonomi og scope ændringer
IT-arkitektur IT-governance Udvikling Udbud
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
IT-arkitektur IT-governance Udvikling Udbud
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
IT-arkitektur IT-governance Udvikling Udbud
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
IT-arkitektur IT-governance Udvikling Udbud
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
IT-arkitektur IT-governance Udvikling Udbud
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
IT-arkitektur IT-governance Udvikling Udbud
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

Más contenido relacionado

Destacado

Anteprojeto do C.E.D. da Advocacia (em 22/05/14)
Anteprojeto do C.E.D. da Advocacia (em 22/05/14)Anteprojeto do C.E.D. da Advocacia (em 22/05/14)
Anteprojeto do C.E.D. da Advocacia (em 22/05/14)'Roberto Morgado
 
Alytics - Александр Егоров: Сквозная аналитика в контекстной рекламе
Alytics - Александр Егоров: Сквозная аналитика в контекстной рекламеAlytics - Александр Егоров: Сквозная аналитика в контекстной рекламе
Alytics - Александр Егоров: Сквозная аналитика в контекстной рекламеAlytics
 
'La Regaera' 12 Fidel Pavón, el fotógrafo de nuestras vidas
'La Regaera' 12 Fidel Pavón, el fotógrafo de nuestras vidas'La Regaera' 12 Fidel Pavón, el fotógrafo de nuestras vidas
'La Regaera' 12 Fidel Pavón, el fotógrafo de nuestras vidasGrupo TMS Media
 
Профилактика гриппа
Профилактика гриппаПрофилактика гриппа
Профилактика гриппаlyudok_osnk
 
Знакомство со звуком "Ж"
Знакомство со звуком "Ж"Знакомство со звуком "Ж"
Знакомство со звуком "Ж"yablonka
 
Thực phẩm phù hợp cho người có cholesterol cao
Thực phẩm phù hợp cho người có cholesterol caoThực phẩm phù hợp cho người có cholesterol cao
Thực phẩm phù hợp cho người có cholesterol caowinfred427
 
Elora natalia
Elora nataliaElora natalia
Elora nataliaaescude2
 
KÕIGILE, KES OSALESID VERD JA HÄVITAMINE, SISESTAGE KINGDOM OF HEAVEN; KÕIK L...
KÕIGILE, KES OSALESID VERD JA HÄVITAMINE, SISESTAGE KINGDOM OF HEAVEN; KÕIK L...KÕIGILE, KES OSALESID VERD JA HÄVITAMINE, SISESTAGE KINGDOM OF HEAVEN; KÕIK L...
KÕIGILE, KES OSALESID VERD JA HÄVITAMINE, SISESTAGE KINGDOM OF HEAVEN; KÕIK L...Lo Que Vendra
 

Destacado (15)

AAI
AAIAAI
AAI
 
Anteprojeto do C.E.D. da Advocacia (em 22/05/14)
Anteprojeto do C.E.D. da Advocacia (em 22/05/14)Anteprojeto do C.E.D. da Advocacia (em 22/05/14)
Anteprojeto do C.E.D. da Advocacia (em 22/05/14)
 
Agentes o que dizer
Agentes  o que dizerAgentes  o que dizer
Agentes o que dizer
 
Alytics - Александр Егоров: Сквозная аналитика в контекстной рекламе
Alytics - Александр Егоров: Сквозная аналитика в контекстной рекламеAlytics - Александр Егоров: Сквозная аналитика в контекстной рекламе
Alytics - Александр Егоров: Сквозная аналитика в контекстной рекламе
 
'La Regaera' 12 Fidel Pavón, el fotógrafo de nuestras vidas
'La Regaera' 12 Fidel Pavón, el fotógrafo de nuestras vidas'La Regaera' 12 Fidel Pavón, el fotógrafo de nuestras vidas
'La Regaera' 12 Fidel Pavón, el fotógrafo de nuestras vidas
 
Профилактика гриппа
Профилактика гриппаПрофилактика гриппа
Профилактика гриппа
 
Yashomani 17 feb 2015
Yashomani 17 feb 2015Yashomani 17 feb 2015
Yashomani 17 feb 2015
 
Знакомство со звуком "Ж"
Знакомство со звуком "Ж"Знакомство со звуком "Ж"
Знакомство со звуком "Ж"
 
Thực phẩm phù hợp cho người có cholesterol cao
Thực phẩm phù hợp cho người có cholesterol caoThực phẩm phù hợp cho người có cholesterol cao
Thực phẩm phù hợp cho người có cholesterol cao
 
Elora natalia
Elora nataliaElora natalia
Elora natalia
 
Centros caleb UPN
Centros caleb UPNCentros caleb UPN
Centros caleb UPN
 
Git
GitGit
Git
 
Projeto simbora galera
Projeto simbora galeraProjeto simbora galera
Projeto simbora galera
 
KÕIGILE, KES OSALESID VERD JA HÄVITAMINE, SISESTAGE KINGDOM OF HEAVEN; KÕIK L...
KÕIGILE, KES OSALESID VERD JA HÄVITAMINE, SISESTAGE KINGDOM OF HEAVEN; KÕIK L...KÕIGILE, KES OSALESID VERD JA HÄVITAMINE, SISESTAGE KINGDOM OF HEAVEN; KÕIK L...
KÕIGILE, KES OSALESID VERD JA HÄVITAMINE, SISESTAGE KINGDOM OF HEAVEN; KÕIK L...
 
Practica audacity
Practica audacityPractica audacity
Practica audacity
 

Similar a IT kontrakter 2015 - Godkendelseskriterier og ændringshåndtering

Vælg den rigtige leverandør
Vælg den rigtige leverandørVælg den rigtige leverandør
Vælg den rigtige leverandørBestBrains
 
Erfaringer med agile EU-udbud
Erfaringer med agile EU-udbudErfaringer med agile EU-udbud
Erfaringer med agile EU-udbudBestBrains
 
Få fordelene ved agil udvikling i it-porteføljen (IBM Global Business Services)
Få fordelene ved agil udvikling i it-porteføljen (IBM Global Business Services)Få fordelene ved agil udvikling i it-porteføljen (IBM Global Business Services)
Få fordelene ved agil udvikling i it-porteføljen (IBM Global Business Services)IBM Danmark
 
Product Ownerens værktøjskasse
Product Ownerens værktøjskasseProduct Ownerens værktøjskasse
Product Ownerens værktøjskasseBestBrains
 
It arkitektur - forankring & værditilførsel
It arkitektur - forankring & værditilførselIt arkitektur - forankring & værditilførsel
It arkitektur - forankring & værditilførselLars Rosenberg Nielsen
 
Molio konference vejledning i udbud med mængder
Molio konference   vejledning i udbud med mængderMolio konference   vejledning i udbud med mængder
Molio konference vejledning i udbud med mængderMichael Sebbelin Porskær
 
Agile kontrakter ghm marts2012
Agile kontrakter ghm marts2012 Agile kontrakter ghm marts2012
Agile kontrakter ghm marts2012 BestBrains
 
BestBrains Agile kontrakter marts 2012
BestBrains Agile kontrakter marts 2012BestBrains Agile kontrakter marts 2012
BestBrains Agile kontrakter marts 2012Jesper Thaning
 
Workshop A - Fra produkt til service - TOPdesk on Tour Denmark 2017
Workshop A - Fra produkt til service - TOPdesk on Tour Denmark 2017Workshop A - Fra produkt til service - TOPdesk on Tour Denmark 2017
Workshop A - Fra produkt til service - TOPdesk on Tour Denmark 2017TOPdesk
 
Maguire - Quality, Focus and Process
Maguire - Quality, Focus and ProcessMaguire - Quality, Focus and Process
Maguire - Quality, Focus and ProcessStina Rhindal Maguire
 
Sådan vurderer du Cloud Compliance
Sådan vurderer du Cloud ComplianceSådan vurderer du Cloud Compliance
Sådan vurderer du Cloud ComplianceMicrosoft
 
Hvorofor offshore, når man kan nearshore af Orla Pedersen, Boas Specialister
Hvorofor offshore, når man kan nearshore af Orla Pedersen, Boas SpecialisterHvorofor offshore, når man kan nearshore af Orla Pedersen, Boas Specialister
Hvorofor offshore, når man kan nearshore af Orla Pedersen, Boas SpecialisterInfinIT - Innovationsnetværket for it
 
Lav bedre digitale løsninger med brugerinddragelse
Lav bedre digitale løsninger med brugerinddragelseLav bedre digitale løsninger med brugerinddragelse
Lav bedre digitale løsninger med brugerinddragelseanjaflebbe
 
BestBrains Agile kontrakter marts 2011
BestBrains Agile kontrakter marts 2011BestBrains Agile kontrakter marts 2011
BestBrains Agile kontrakter marts 2011Jesper Thaning
 
Sådan skriver du et godt tilbud
Sådan skriver du et godt tilbudSådan skriver du et godt tilbud
Sådan skriver du et godt tilbudPeytz & Co
 
Valg af nyt projektbaseret ERP system, Claus Birkholm, Alectia
Valg af nyt projektbaseret ERP system, Claus Birkholm, AlectiaValg af nyt projektbaseret ERP system, Claus Birkholm, Alectia
Valg af nyt projektbaseret ERP system, Claus Birkholm, AlectiaMediehuset Ingeniøren Live
 
Agile kontrakter mar 2016 café-møde BestBrains
Agile kontrakter mar 2016 café-møde BestBrainsAgile kontrakter mar 2016 café-møde BestBrains
Agile kontrakter mar 2016 café-møde BestBrainsRikke Veng Petersen
 
Juridiske udfordringer ved aftaler til agile projekter
Juridiske udfordringer ved aftaler til agile projekterJuridiske udfordringer ved aftaler til agile projekter
Juridiske udfordringer ved aftaler til agile projekterBestBrains
 
20050518 FVS præsentation
20050518 FVS præsentation20050518 FVS præsentation
20050518 FVS præsentationKim Holm
 

Similar a IT kontrakter 2015 - Godkendelseskriterier og ændringshåndtering (20)

Vælg den rigtige leverandør
Vælg den rigtige leverandørVælg den rigtige leverandør
Vælg den rigtige leverandør
 
Erfaringer med agile EU-udbud
Erfaringer med agile EU-udbudErfaringer med agile EU-udbud
Erfaringer med agile EU-udbud
 
Få fordelene ved agil udvikling i it-porteføljen (IBM Global Business Services)
Få fordelene ved agil udvikling i it-porteføljen (IBM Global Business Services)Få fordelene ved agil udvikling i it-porteføljen (IBM Global Business Services)
Få fordelene ved agil udvikling i it-porteføljen (IBM Global Business Services)
 
Product Ownerens værktøjskasse
Product Ownerens værktøjskasseProduct Ownerens værktøjskasse
Product Ownerens værktøjskasse
 
It arkitektur - forankring & værditilførsel
It arkitektur - forankring & værditilførselIt arkitektur - forankring & værditilførsel
It arkitektur - forankring & værditilførsel
 
Molio konference vejledning i udbud med mængder
Molio konference   vejledning i udbud med mængderMolio konference   vejledning i udbud med mængder
Molio konference vejledning i udbud med mængder
 
Agile kontrakter ghm marts2012
Agile kontrakter ghm marts2012 Agile kontrakter ghm marts2012
Agile kontrakter ghm marts2012
 
BestBrains Agile kontrakter marts 2012
BestBrains Agile kontrakter marts 2012BestBrains Agile kontrakter marts 2012
BestBrains Agile kontrakter marts 2012
 
Workshop A - Fra produkt til service - TOPdesk on Tour Denmark 2017
Workshop A - Fra produkt til service - TOPdesk on Tour Denmark 2017Workshop A - Fra produkt til service - TOPdesk on Tour Denmark 2017
Workshop A - Fra produkt til service - TOPdesk on Tour Denmark 2017
 
Maguire - Quality, Focus and Process
Maguire - Quality, Focus and ProcessMaguire - Quality, Focus and Process
Maguire - Quality, Focus and Process
 
Sådan vurderer du Cloud Compliance
Sådan vurderer du Cloud ComplianceSådan vurderer du Cloud Compliance
Sådan vurderer du Cloud Compliance
 
Hvorofor offshore, når man kan nearshore af Orla Pedersen, Boas Specialister
Hvorofor offshore, når man kan nearshore af Orla Pedersen, Boas SpecialisterHvorofor offshore, når man kan nearshore af Orla Pedersen, Boas Specialister
Hvorofor offshore, når man kan nearshore af Orla Pedersen, Boas Specialister
 
Lav bedre digitale løsninger med brugerinddragelse
Lav bedre digitale løsninger med brugerinddragelseLav bedre digitale løsninger med brugerinddragelse
Lav bedre digitale løsninger med brugerinddragelse
 
BestBrains Agile kontrakter marts 2011
BestBrains Agile kontrakter marts 2011BestBrains Agile kontrakter marts 2011
BestBrains Agile kontrakter marts 2011
 
Sådan skriver du et godt tilbud
Sådan skriver du et godt tilbudSådan skriver du et godt tilbud
Sådan skriver du et godt tilbud
 
Valg af nyt projektbaseret ERP system, Claus Birkholm, Alectia
Valg af nyt projektbaseret ERP system, Claus Birkholm, AlectiaValg af nyt projektbaseret ERP system, Claus Birkholm, Alectia
Valg af nyt projektbaseret ERP system, Claus Birkholm, Alectia
 
instant@larm workshop | Digicure
instant@larm workshop | Digicureinstant@larm workshop | Digicure
instant@larm workshop | Digicure
 
Agile kontrakter mar 2016 café-møde BestBrains
Agile kontrakter mar 2016 café-møde BestBrainsAgile kontrakter mar 2016 café-møde BestBrains
Agile kontrakter mar 2016 café-møde BestBrains
 
Juridiske udfordringer ved aftaler til agile projekter
Juridiske udfordringer ved aftaler til agile projekterJuridiske udfordringer ved aftaler til agile projekter
Juridiske udfordringer ved aftaler til agile projekter
 
20050518 FVS præsentation
20050518 FVS præsentation20050518 FVS præsentation
20050518 FVS præsentation
 

IT kontrakter 2015 - Godkendelseskriterier og ændringshåndtering

  • 1. IT-arkitektur IT-governance Udvikling Udbud IT kontrakter 2015 Godkendelseskriterier og ændringshåndtering Baseret på et konkret projekt
  • 2. IT-arkitektur IT-governance Udvikling Udbud Henrik Gørup Rasmussen – Konsulent, partner Silverbullet • 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.
  • 3. IT-arkitektur IT-governance Udvikling Udbud 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
  • 4. IT-arkitektur IT-governance Udvikling Udbud 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
  • 5. IT-arkitektur IT-governance Udvikling Udbud Baseline og nedbrydning Krav Use cases Kravsbesvarelse Use case beskrivelser Lø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
  • 6. IT-arkitektur IT-governance Udvikling Udbud Leverancemodel – Iterativ (elefantfoden) Page 6 Kundetest Iteration 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
  • 7. IT-arkitektur IT-governance Udvikling Udbud 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.
  • 8. IT-arkitektur IT-governance Udvikling Udbud Sporopdeling (moduler) Iteration 1 Iteration 3Iteration 2 Iteration NSpor 1 Iteration 1 Iteration 3Iteration 2 Iteration NSpor 2 Iteration 1 Iteration 3Iteration 2 Iteration NSpor 3 Iteration 1 Iteration 3Iteration 2 Iteration NSpor 4 Iteration 1 Iteration 3Iteration 2 Iteration NSpor 5
  • 9. IT-arkitektur IT-governance Udvikling Udbud 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.
  • 10. IT-arkitektur IT-governance Udvikling Udbud 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
  • 11. IT-arkitektur IT-governance Udvikling Udbud 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
  • 12. IT-arkitektur IT-governance Udvikling Udbud 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.
  • 13. IT-arkitektur IT-governance Udvikling Udbud Godkendelseskriterier - eksempel Godkendelseskriterie til forretningsfeature: AdmBruger Opret Bruger Status Overordnet område: Oprettelse af Bruger Opret Det 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
  • 14. IT-arkitektur IT-governance Udvikling Udbud Godkendelseskriterier - eksempel Godkendelseskriterie til forretningsfeature: AdmBruger Opret Bruger Status Overordnet område: Oprettelse af Bruger Opdater Det 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
  • 15. IT-arkitektur IT-governance Udvikling Udbud 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 ÆØ
  • 16. IT-arkitektur IT-governance Udvikling Udbud 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
  • 17. IT-arkitektur IT-governance Udvikling Udbud ÆØ – Proces - eksempel Husk fasttrack! – ÆØ uden økonomi og scope ændringer
  • 18. IT-arkitektur IT-governance Udvikling Udbud 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
  • 19. IT-arkitektur IT-governance Udvikling Udbud 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
  • 20. IT-arkitektur IT-governance Udvikling Udbud 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
  • 21. IT-arkitektur IT-governance Udvikling Udbud 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
  • 22. IT-arkitektur IT-governance Udvikling Udbud 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
  • 23. IT-arkitektur IT-governance Udvikling Udbud 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

Notas del editor

  1. Agil metode = få krav, og endnu færre MK (absolutte krav) Denne metode = mange krav, men til dels samme leverancemodel som agil. Forskellen ligger i agil metode åbner for en generel bred fortolkning af det system der skal leveres, hvor denne metode sætter klarere (snævrere) rammer op i form af krav i traditionel forstand. Styringsmæssigt, mht. godkendelseskriterier og ÆØ er der stor forskel på de to modeller, ligesom der er forskel til et traditionelt vandfaldsprojekt Mht. non-funktionelle krav er der stort sammenfald, der kan stilles samme krav til tilgængelighed, svartider, disaster recovery SPOC, support mv. i alle modeller.
  2. MK, PK, K Use cases lidt mere overordnede Kunden får indsigt i forretningsfeatures, men ikke det der ligger under, det er udelukkende leverandøren ansvar Forretningsfeautres skal kunne forstås af kunden – det underliggende ikke nødvendigvis – Tasks kan gives til udviklere Når der testes er det vigtigt at forstå at kunden validerer forretningsfeatures, ikke systemfeatures, dvs. godkendelseskriterier skal laves på forretningsfeatures Eksempel Kunden -Data skal løbende kunne overføres til datavarehus Leverandøren – OK, det bliver det med max 24 timers forsinkelse, og vha. snitflade X. Systemfeatures - Datamodel skal understøtte kravet, snitflade skal laves, dataselektion skal programmeres, overførsel skal skeduleres osv.
  3. Godkendelseskriterier i hver iteration, akkumuleret til kundetests, dernæst akkumuleret til endelige prøver Afkobling af risici, problemområder findes tidligt, prøver bliver mest en skrivebordsopgave
  4. Iteration starter ved demomøde i den foregående iteration Leverandøren har forinden leveret en overordnet plan for hvad de enkelte iterationer forventes at indeholde, således det kan godtgøres at leverancen kan leveres i de planlagte iterationer Sammenhæng mellem spor (moduler) Godkendelseskriterier og testcases meget vigtige, det forhindrer mange ÆØ’er Beslutningskraft afgørende, da det ellers bliver en akademisk øvelse.
  5. Basisfunktionalitet først (brugerstyring mv.) Afhængigheder mellem leverancer i spor Det fremgår at det er en kompliceret
  6. Regressionstest skal gennemføres af leverandøren så ny funktionalitet ikke medfører fejl i alle leveret funktionalitet Tværgående funktionalitet 12 forretningsfeatures – 10 godkendte, 1 delvist godkendt, 1 afvist Alle på baggrund af godkendelseskriterier og testcases. Kunden kan alligevel afvise en forretningsfeature, hvis de ikke mener den opfylder formålet, selvom godkendelseskriterier er opfyldte. Her kommer ÆØ så ind, igen tidligt i forløbet. kan det evt. klares med en præcisering?
  7. grupper af værdier – f.eks. stamdata på en bruger
  8. Understregninger er forretningsfeatures for sig selv.