Dataforeningens kontraktsstandard for oppdragsbasert, smidig leveranse av programvare
Dataforeningens kontraktsstandard for oppdragsbasert, smidig leveranse av programvare
Veiledning for utarbeidelse og bruk av kontrakten
DEN NORSKE DATAFORENING
Versjon : 1.3
Dato oppdatert : 25.04.2018
INNHOLDSFORTEGNELSE
3
1.4 Forutsetninger for å velge denne kontrakten 7
2 KONTRAKTSSTRUKTUR OG INNHOLD 78
2.3 REVISJON SIDEN VERSJON 1.0 10
3 KONTRAKTENS PROSESSER OG GJENNOMFØRINGSMODELL
11
3.2 Oppstartsaktiviteter og første leveranse 11
3.3 Gjennomføring av senere leveranser 12
4 ANSKAFFELSESPROSESS OG ETABLERING AV KONTRAKT
14
4.1 Forutsetninger for etablering av kontrakt 14
4.2 Konkurransegrunnlag og krav til utforming av tilbud 15
4.3 Leverandørens utfylling av tilbudstekst i kontrakt 16
4.4 Grunnlag for evaluering av tilbud 16
17
5.4 Bruk av estimeringsmodellen 19
5.5 Bruk av bistandsavtaler 21
5.6 Bruk av oppdragsavtaler 22
5.6.1 Oppdragsavtaler - statisk del 22
5.6.2 Oppdragsavtaler – dynamisk del 23
5.8.1 Leverandørens mislighold 25
5.9 Avslutning av kontrakten 26
1 Innledning
1.1 Bakgrunn
Smidige metoder benyttes i stadig større utstrekning i systemutviklingsprosjekter, både i privat og offentlig sektor. Samtidig opplever mange kunder og leverandører store utfordringer med å benytte standardkontrakter i prosjekter som skal følge smidig metodikk. Dette gjelder særlig der det innenfor det antatte omfang ikke er mulig beskrive et detaljert innhold i leveranser som grunnlag for prisfastsettelse før arbeidet påbegynnes.
I praksis gjennomføres derfor mange smidige utviklingsprosjekter med grunnlag i timebaserte bistandsavtaler der kunden selv tar resultatansvaret. Det kan imidlertid være mange fordeler ved å gjennomføre smidige utviklingsprosjekter basert på en utviklingskontrakt, selv om innholdet ikke er veldefinert på forhånd, da det gir:
- deling av ansvar og økonomisk risiko,
- tydelig og avtalt arbeidsdeling mellom kunde og leverandør,
- klare krav til både kundens og leverandørens forarbeid for etablering og godkjenning av leveranser,
- grunnlag for oppfølging av kvalitetskrav for utviklingstjenester istedenfor kun oppfølging av leverandørens timeforbruk og
- forpliktelser til kapasitet og estimeringsmodell.
Forpliktelser til kapasitet og estimeringsmodell er sentralt, da det sikrer en stabil og adekvat bemanning fra leverandørens side, i kombinasjon med en estimeringsmodell som skal bidra til mest mulig effektiv systemutvikling, basert på godt dokumenterte erfaringstall.
En ny kontraktsstandard må kunne håndtere oppdragsbasert utvikling av programvare, både i forbindelse med nyutvikling (også omtalt som grunnutvikling) og videreutvikling.
Gjennomføringsmodellen bør være smidig med løpende prioritering av behov ut fra definerte mål og rammer for leveransene, og tilrettelegge for at prosessene for behovsanalyse, løsningsbeskrivelse og konstruksjon kan løpe kontinuerlig og delvis i parallell.
PS2000 og den smidige versjonen som ble lansert i 2009, kalt PS2000 Smidig, har ivaretatt mange av de ovenstående punktene, og det er gode erfaringer med bruk av disse kontraktsstandardene. De fordrer imidlertid at det inngås en samlet avtale på et definert omfang, basert på kundens behovsanalyse. Endringshåndteringsprosessen i kontrakten må dermed benyttes for senere avdekket endringsbehov knyttet til omfang. I mange smidige prosjekter er det i første omgang kun hensiktsmessig å definere mål og rammer for prosjektet samt innledningsvis å detaljere noen av de høyest prioriterte behovene utfra nytteverdi.
Detaljering av øvrige funksjonelle og ikke-funksjonelle behov avventes til erfaringer med de første leveransene er vunnet.
I mindre prosjekter hvor det ikke har vært ønskelig å avklare omfang i forkant, har Dataforeningens rammeavtale for utviklingstjenester ofte vært benyttet. Denne kontraktsstandarden er relativt kortfattet, uten regulering av forhold som er spesifikke verken for en smidig eller noen annen gjennomføringsmodell, og baserer seg på utvikling og tilpasning gjennom enkeltstående oppdragsavtaler.
Denne nye kontraktsstandarden muliggjør en vurdering av behov for en kortere horisont, og hvor resten av behovene prioriteres ut fra et definert ressurs- og kapasitetsbehov og en forutsetning om smidige prosesser. Dette ressurs- og kapasitetsbehovet må sammenholdes
med et tilhørende budsjett og forventet leveranseevne ut fra en definert estimeringsmodell fra leverandøren. Det totale innholdet i løsninger og leveranser er ikke detaljert på forhånd, men vil fremkomme gjennom læring og modning underveis.
For å kunne forstå og tolke spesielle ord og begreper som er benyttet i kontraktsstandarden, er det inkludert en definisjonskatalog i de generelle kontraktsbestemmelsene.
1.2 Formål med kontrakten
Dette dokumentet utgjør en veiledning for etablering og bruk av Dataforeningens kontraktsstandard for oppdragsbasert, smidig leveranse av programvare (heretter benevnt som kontrakten) også kalt PS2000 SOL.
Kontrakten er en selvstendig og fullverdig avtale, men den kan også inngås sammen med en vedlikeholdskontrakt. Kontrakten kan benyttes for grunnutvikling av ny programvare og for videreutvikling av programvare over tid. Utvikling av programvare omfatter her egenutvikling av programvare. I tillegg kan utvikling av programvare omfatte systemintegrasjon og eventuelt konfigurering av standard programvare som er av betydelig omfang. I utgangspunktet er kontrakten utviklet for relativt langvarig kontraktsforhold med en leverandør da det er omfattende regulering både av
- oppstartsaktiviteter,
- kapasitet og ressursbruk,
- estimeringsmodell og xxxxxxxx og
- endringer og sanksjoner knyttet til mislighold.
Kontrakten regulerer partenes overordnede forpliktelser og rettigheter i kontraktsperioden herunder leverandørens forpliktelse til en gitt kapasitet og bemanning, mens forberedelse og gjennomføring av tjenester og leveranser under kontrakten leveres gjennom følgende to avtaleformer:
- bistandsavtaler, i hovedsak for leverandørens bistand til behovsanalyse og utarbeidelse av løsningsbeskrivelser som grunnlag for smidig systemutvikling, og
- oppdragsavtaler for leverandørens arbeid med utvikling av programvaren under konstruksjon og feilretting i godkjenningsprøven, som resulterer i en eller flere leveranser per oppdragsavtale.
Kontrakten er basert på at arbeidet med å realisere leveranser og løsninger skjer gjennom smidige prosesser basert på overordnede mål i form av et målbilde. Disse målene realiseres gjennom kontinuerlig prioritering av de viktigste behovene og de som i størst mulig grad bidrar til å nå målene, basert på følgende hovedstruktur:
Figur 1 Produktnedbrytningsstruktur
Dersom kontrakten benyttes for utvikling av nye systemløsninger, bør effekt- og resultatmål, overordnede behovsbeskrivelser, samt målbilder for arkitektur, normalt foreligge ved kontraktsinngåelse. Dette vil være sentralt i slike situasjoner, da kontrakten ikke vil kunne baseres på en referanseramme som ellers foreligger i form av beskrivelse av eksisterende programvare. Brukerhistorier og løsningsbeskrivelser utarbeides som en del av kontrakten. Det meste av dette vil også være relevant for videreutvikling.
Det at kontrakten behandler en definert programvare og at kunden forplikter seg til å utnytte den leverandørkapasitet som til enhver tid er avtalt, gjør at kontrakten skiller seg klart fra rammeavtaler. Kapasitetsutnyttelsen sikres ved etablering av bistandsavtaler og oppdragsavtaler i henhold til avtalt kapasitet og en produktkø som løpende prioriteres av kunden.
Kontrakten er basert på at samme leverandør har ansvar for både utvikling og vedlikehold av programvaren, og kontrakten er forberedt for å fungere sammen med en separat vedlikeholdskontrakt. Det er imidlertid ikke en forutsetning at det er etablert en egen vedlikeholdskontrakt. Vedlikeholdstjenester kan alternativt leveres gjennom bruk av bistandsavtaler og oppdragsavtaler innenfor denne kontrakten.
Dersom kontrakten benyttes i forbindelse med standard programvare, vil ressurser dedikert til denne programvaren ikke nødvendigvis inngå i den definerte kapasiteten, men håndteres separat. Det er da naturlig å benytte bistandsavtaler og ikke oppdragsavtaler for slike ressurser.
Ved bruk av kontrakten i forbindelse med videreutvikling av programvare, er det ingen forutsetninger i forhold til hvilken kontrakt som tidligere er benyttet for utvikling og videreutvikling av programvaren.
1.3 Dataforeningens rolle
Dataforeningens Faggruppe for IT-kontrakter er ansvarlig både for denne kontrakten og for videreutvikling og forvaltning av PS2000 kontraktsstandarden og de øvrige, tilhørende
kontraktstandardene. Med denne nye kontrakten har Dataforeningen følgende portefølje av kontraktstandarder som dekker hele livssyklusen for programvarebaserte løsninger:
Figur 2 Dataforeningens kontraktsstandarder
Denne nye kontraktstandarden fremstår som et alternativ til PS2000 Smidig og/eller Dataforeningens rammeavtale for utviklingstjenester og er illustrert med blå bakgrunnsfarge i figuren over. Den blir derfor kalt PS2000 SOL (Smidige, Oppdragsbaserte Leveranser).
Utarbeidelse av denne kontraktstandarden ble gjennomført høsten 2012 og frem til sommeren 2013 slik at en versjon 1 kunne ferdigstilles i august 2013. Arbeidet er utført av en arbeidsgruppe hvor PROMIS AS ved Xxxxxx Xxxxxxxx har produsert forslag og ledet arbeidet.
Arbeidsgruppen ble nedsatt av Dataforeningens styre for Faggruppen for IT-kontrakter, med tilnærmet lik representasjon fra både kunde-, leverandør- og rådgiversiden:
- Xxxxxxxxxxxxxx Xxxxxxx AS, ved Xxx Xxxxxxxxxxx
- Xxxxxxxxxxxxxx Xxxxxxxx Xxxx Xxxx AS, ved Xxxxx Xxxxx
- Arbeids- og velferdsetaten (NAV), representert ved en konsulent fra PROMIS AS, Xxx Xxxxxx Xxxxxxxxx
- Xxxx Consulting AS, ved Xxxxxxxx Xxxxxxxxxxx
- Capgemini Norge AS, ved Xxxxx Xxxxxx
- Computas AS, ved Xxxx-Xxxx Xxxxxx Xxxxxx
- Direktoratet for forvaltning og IKT (Difi), ved Xxxx X. Xxxxxxxx
- PROMIS AS, ved Xxxxxx Xxxxxxxx
- Statens lånekasse for utdanning, ved Xxxx Xxxx Xxxxxxx
- Timebox AS, ved Xxxxxxxx Xxxxxxxx
I siste revisjon er det faggruppens styre som selv har stått for arbeidet. Styret består for tiden av:
- PROMIS AS, ved Xxxxxx Xxxxxxxx (leder)
- Xxxxxxxxxxxxxx Xxxxxxxx Xxxx Xxxx AS, ved Xxxxx Xxxxx
- Arbeids- og velferdsetaten (NAV), ved Xxxxxx Xxxxxxx
- Xxxx Consulting AS, ved Xxxxxxxx Xxxxxxxxxxx
- Capgemini Norge AS, ved Xxxxxx Xxxxxxxxx
- Computas AS, ved Xxxx Xxxxx Xxxxxx
- Departementenes sikkerhets- og serviceorganisasjon, ved Xxxx Xxxxxxxxx
- Direktoratet for forvaltning og IKT (Difi), ved Xxxx Xxxxxx
- Sopra Steria, ved Xxxx Xxxxxx Xxxxxxxxxxx
- Statens vegvesen, ved Xxxxx Xxxxx
- Timebox AS, ved Xxxxxxxx Xxxxxxxx
Feltkode endret
Feltkode endret
Mer informasjon om Dataforeningen og faggruppens arbeid kan fås ved henvendelse til Den Norske Dataforening (xxx.xxxxxxxxxxxxxx.xx) eller PROMIS AS (xxx.xxxxxx.xx).
1.4 Forutsetninger for å velge denne kontrakten
Kontrakten forutsetter en viss erfaring med og modenhet innenfor smidig systemutvikling, eventuelt at kunden skaffer seg slik kompetanse ved kjøp av tjenester fra en tredjepart. Det er en forutsetning at kunden:
- har ressurser med god innsikt i de aktuelle forretningsprosessene og erfaring fra produkteierrollen med tilstrekkelig beslutningsmyndighet,
- har fungerende prosesser slik at leveranser planlegges med en horisont på minimum noen måneder slik at milepæler for leveranser kan avtales i oppdragsavtaler,
- har fungerende prosesser slik at kapasitetsplanleggingen gir tilstrekkelig forutsigbarhet, det vil si at kunder kan forplikte seg til å bruke avtalt kapasitet og at endringer i kundens kapasitetsbehov svinger innenfor terskler og frister som definert i kontrakten,
- er systemintegrator, ved egne ressurser eller ved kjøp av tjenester, med ansvar for
- arkitekturstyring og overordnet virksomhetsarkitektur,
- produkteierskap og forberedelse av produktkøen,
- prosesser og metode for smidig gjennomføringsmodell,
- gjennomføring av kontrollpunkt og godkjenningsprøve,
- tilgang til utviklingsverktøy og eventuelle standardprodukter og
- teknisk infrastruktur.
I neste omgang må kunden velge en leverandør som har tilsvarende forståelse av disse forutsetningenes betydning.
Dersom kunden trenger bistand fra en tredjepart for dekke rollen som systemintegrator, vil kunden være ansvarlig for etablering av slike tjenester samt at tjenestene er avstemt i forhold til reguleringene i kontraktens bestemmelser om kundens ansvar ved smidig oppdragsbasert utvikling.
Kunden vil som utgangspunkt også ha ansvaret for å anskaffe lisenser til utviklingsverktøy og standardprodukter som skal benyttes i forbindelse med systemutviklingen. Tilsvarende har kunden ansvaret for eventuelle kontrakter for drift og støttetjenester relatert til den tekniske infrastrukturen dersom ikke annet er avtalt.
2 Kontraktstruktur og innhold
2.1 Hovedinndeling
Kontrakten er delt inn i:
Del I Kontraktsdokument
Del II Generelle kontraktsbestemmelser Del III Bilag
Kontraktsdokumentet består av en forside med nøkkelinformasjon om kunde, leverandør og inngått kontrakt og er skilt ut som en egen del for å gi partene frihet til å velge form og innhold på dette overordnede dokumentet. Som et minimum må alle deler av kontrakten refereres og rangordningen mellom disse må beskrives i tillegg til å angi kontraktens varighet. Kontraktsdokumentet utarbeides når partene har oppnådd enighet om kontraktsbestemmelsene.
De generelle kontraktsbestemmelsene skal kunne brukes med få eller ingen endringer. Alle spesifikke vilkår for kontrakten reguleres derfor i bilagene. Eventuelle endringer til de generelle kontraktsbestemmelsene skal fremgå klart av kontraktsdokumentet.
De generelle kontraktsbestemmelser inneholder beskrivelse av hvordan konsulentbistand og systemutvikling gjennomføres i form av bistandsavtaler og oppdragsavtaler basert på krav og betingelser til følgende områder:
- partenes plikter,
- organisering av arbeidet og partenes sentrale roller,
- prosessene innenfor gjennomføringsmodellen og hvordan bistandsavtaler og oppdragsavtaler etableres,
- økonomiske vilkår og
- juridiske bestemmelser, herunder sikkerhet, taushetsplikt, rettigheter, mislighold, avbestilling og endringer
Kontrakten er bygget opp med ”halvfabrikata” bilag. Dette skal forenkle utarbeidelsen av bilagene og legge til rette regulering av alle forhold som de generelle kontraktsbestemmelsene foreskriver at skal være nærmere regulert i bilag. For ytterligere å forenkle avtaleinngåelsen, er det i bilagene inntatt forslag til detaljregulering av tjenestene, samt hvilke tjenester og forpliktelser som bør reguleres. Det presiseres at forslagene ikke er ment som førende fra Dataforeningens side.
Den preutfylte bilagsteksten må uansett kompletteres og gjennomgås grundig for å kunne benyttes til å regulere spesifikke kontraktsforhold. Primært skal spesifikke forhold legges inn i forhåndsdefinerte tabeller. Der det ikke er hensiktsmessig med tabeller, er behov for utfylling markert med <kursiv og klammeparenteser> og eventuelt forslag til tekst. Merk at bilagsteksten på enkelte områder primært fungerer som en kryssreferanse fra de generelle kontraktsbestemmelser og som eksempel (i kursiv) for mulig innhold, ikke som en standard.
Bilagene inneholder:
1. Beskrivelse av programvaren (ved grunnutvikling av ny programvare beskrives overordnede behov, løsningsmålbilder og krav til løsningsområdet/subsystemet), standard programvare, miljøer og ansvarsforhold for miljøer.
2. Gjennomføring av oppstartsaktiviteter, hovedprosesser for bistand og systemutvikling, hvordan bistandsavtaler og oppdragsavtaler etableres samt avslutningsaktiviteter
3. Leverandørens kapasitet, ressurser og ansvar
4. Administrative bestemmelser, kontaktpersoner, faste møter og rapportering
5. Xxxxxx, estimeringsmodell og vederlag for avtaler
6. Mal for bistandsavtaler
7. Xxx for oppdragsavtaler
8. Xxx for oppdragslogg
9. Leverandørens estimeringsmodell
2.2 Kontraktstruktur
Kontrakten omfatter bruk av avtaledokumenter på flere nivåer:
- Kontrakten regulerer partenes overordnede forpliktelser og rettigheter i kontraktsperioden.
- Bistandsavtaler og oppdragsavtaler definerer forutsetninger, rammer og omfang for leveranser med følgende fordeling:
- Bistandsavtalene omfatter all bistand fra leverandøren som ikke er direkte knyttet til utvikling av programvaren og består i hovedsak av leverandørens bistand til behovsanalyse og utarbeidelse av løsningsbeskrivelser, men kan også omfatte bistand til andre oppgaver knyttet til programvaren.
- Oppdragsavtalene omfatter leverandørens arbeid med utvikling av programvaren under konstruksjon og feilretting i godkjenningsprøven. Oppdragsavtalene består igjen av to deler:
- Statisk del: Xxxxxxx oppdragsavtalen som helhet, og regulerer blant annet oppdragets bemanning, timeomfang, vederlagsmodell, milepæler, antall iterasjoner og godkjenningskriterier for leveransene innenfor oppdragsavtalen.
- Dynamisk del: Den delen av oppdragsavtalen som består av prioriterte brukerhistorier med tilhørende godkjente estimater og løsningsbeskrivelser. Den dynamiske delen utarbeides normalt i flere versjoner underveis i leveransen der hver nye versjon inkluderer nye brukerhistorier som kunden prioriterer inn i neste eller senere iterasjoner.
Ved inngåelse av kontrakt for oppdragsbasert, smidig leveranse av programvare skal det samtidig inngås en bistandsavtale for oppstartsaktiviteter. Oppstartsaktivitetene er beskrevet i punkt 3.2.
Figuren viser hvordan kontrakten brukes på prosjektnivå, bistandsavtaler og oppdragsavtaler statisk del brukes på leveransenivå (én eller flere leveranser) og oppdragsavtaler dynamisk del brukes på iterasjonsnivå (én eller flere iterasjoner).
Figur 3 Avtaledokumenter
2.3 Revisjon sidenav versjon 1.0
På bakgrunn av erfaringer med bruk av versjon 1.0, er PS2000 SOL revidert til en 1.1- versjon. Endringene består hovedsakelig av følgende:
- Ansvaret for løsningsbeskrivelsen endres fra i utgangspunktet å være kunde til leverandør
- Utvidet beskrivelse av partenes oppgaver og arbeidsdeling i behovsanalyse og løsningsbeskrivelse
- Presisering av kundens ansvars som systemintegrator ved behov for koordinering med systemutvikling som foregår utenfor kontrakten
- Sanksjoner ved mangler i leverandørens arbeid med løsningsbeskrivelsen samt i kundens medvirkning er presisert
- Krav til at leverandøren skal fremlegge underlag for estimater samt erfaringstall for oppgavetyper innenfor estimeringsmodellen for gjennomførte leveranser
- Diverse andre, mindre presiseringer og forbedringer
I 2017 ble det utarbeidet en 1.2-versjon som ikke ble utgitt, da det ble avdekket behov for ytterligere presiseringer. Disse ble da inkludert i 1.3-versjonen som ble utarbeidet våren 2018. Denne revisjonen inkluderer:
- Akseptansekriterier i tilknytning til brukerhistorier er inkludert i tillegg til godkjenningskriterier knyttet til godkjenningsprøven
- Feil er inkludert som en definisjon som da benyttes i forbindelse med godkjenningskriterier i godkjenningsprøven for en leveranse
- Bilag 8 er fjernet da det ikke lenger anses som nødvendig
I tillegg er det også i denne revisjonen inkludert en rekke mindre forbedringer og presiseringer.
3 Kontraktens prosesser og gjennomføringsmodell
3.1 Hovedprosesser
Kontrakten er skreddersydd for en smidig gjennomføringsmodell der utvikling av programvare består av fire hovedprosesser for hver leveranse:
- Behovsanalyse
Kunden skal definere og prioritere kundens behov i form av epos og brukerhistorier. Leverandøren skal bistå med løsningsskisser og estimater på overordnet nivå som støtte til kundens prioriteringer. Prismodell for leverandørens bistand er løpende timer.
- Løsningsbeskrivelse
Leverandøren skal utarbeide løsningsdesign og estimater for utviklingen av den delen av produktkøen som kunden prioriterer. Kunden skal bistå leverandøren med nødvendige avklaringer, detaljering av brukerhistorier og prioritering av Produktkøen. Prismodell for leverandørens arbeid er fortsatt løpende timer. Det må da være fokus på å ha et detaljeringsnivå for løsningsdesign som gjør at både tidsbruk og kostnader holder seg innenfor rammene som er forutsatt og at hovedprosessen konstruksjon kan gjennomføres i henhold til forutsetningene definert i estimeringsmodellen.
- Konstruksjon
Under konstruksjon utvikler leverandøren programvaren gjennom et avtalt antall iterasjoner i henhold til signerte og omforente brukerhistorier, løsningsbeskrivelser og estimater. Etter hver iterasjon leveres brukerhistorier, som leverandøren har ferdigstilt i iterasjonen, til et kontrollpunkt for kundens godkjenning i forhold til underliggende dokumentasjon samt de rammebetingelser som foreligger i kontrollpunktet.
- Godkjenningsprøve
Godkjenningsprøven er kundens avsluttende verifikasjon og godkjenning av en leveranse. Leverandøren skal utbedre eventuelle feil og mangler i leveransen. Prismodell for leverandørens arbeid er fast pris.
Arbeidet med behovsanalyse og løsningsbeskrivelse videreføres i parallell med konstruksjon slik at hver iterasjon under en oppdragsavtale har et tilstrekkelig omforent omfang. Arbeidet i prosessene foregår iterativt og i henhold til en smidig gjennomføringsmodell.
3.2 Oppstartsaktiviteter og første leveranse
Ved inngåelse av kontrakt skal det samtidig signeres en bistandsavtale for leverandørens gjennomføring av oppstartsaktiviteter. Oppstartsaktivitetene skal etablere leverandørens organisasjon, styringsmodell og samarbeid mellom kunde og leverandør inklusive forutsetninger vedrørende kundens oppstartsaktiviteter og ressursinnsats, mobiliseringsplan for etablering av leverandørens kapasitet samt rutiner og dokumentasjon.
Oppstartsaktivitetene skal baseres på krav og forutsetninger definert av kunden slik at den samlede gjennomføringen av systemutvikling under kontrakten blir effektiv.
Denne bistandsavtalen skal inneholde en samlet plan for oppstartsaktivitetene og for mobilisering av ressurser. I tillegg skal den inneholde plan for leverandørens bistand til behovsanalyse og løsningsbeskrivelse for den første leveransen samt hovedmilepæler for gjennomføring av den første oppdragsavtalen, se figur under. Det skal etableres en egen
bistandsavtale for gjennomføring av bistanden for den første leveransen. Leverandøren er forpliktet til å etablere en kapasitet i henhold til mobiliseringsplanen.
Figur 4 Oppstart av kontraktsperioden og første leveranse
I den første leveransen er det ofte programvare, verktøy, relasjoner og rammebetingelser som er nye for leverandøren, og å etablere full effektivitet i hovedprosessene tar tid. I behovsanalysen og løsningsbeskrivelsen for den første leveransen er det derfor viktig å fokusere både på hensynet til målbildet og det mer detaljerte underlaget for de første iterasjonene i form av brukerhistorier med scenarier, løsningsbeskrivelse og estimater.
Dersom arbeidet med den dynamiske delen av oppdragsavtalen ikke er tilstrekkelig planlagt slik at den ikke kommer på plass i tide, vil oppstart av konstruksjon bli forsinket.
3.3 Gjennomføring av senere leveranser
I parallell med konstruksjon av den første leveransen må behovsanalyse og løsningsbeskrivelse for den neste leveransen starte opp, og prosessene løper videre i parallell gjennom hele kontraktens levetid slik det er beskrevet i figuren nedenfor.
Som beskrevet ovenfor, er leverandørens kapasitet for oppstartsaktivitetene definert i en bistandsavtale som signeres samtidig med kontrakten. Kundens videre behov for kapasitet til bistand til behovsanalyse og løsningsbeskrivelse, eventuell annen bistand samt gjennomføring av oppdragsavtaler, avtales mellom partene i senere avtaler.
Figur 5 Parallelle prosesser i gjennomføringsmodellen
Leverandøren er forpliktet til å stille til disposisjon en kapasitet for bistandsavtaler og oppdragsavtaler i henhold til mobiliseringsplanen, eller ved endringer i henhold til den til enhver tid avtalte kapasitet.
For gjennomføring av effektive prosesser, er det en fordel med en bemanning som for både kunde og leverandør er relativt stabil. Dersom kunden imidlertid vurderer at det er behov for å endre kapasiteten for bistands- og oppdragsavtaler for kommende leveranser, må dette avtales i henhold til frister som er definert i kontrakten.
For å ha en samlet behandling av kapasiteten for en eller flere leveranser, er det normalt en fordel å etablere en bistandsavtale og oppdragsavtalens statiske del for en eller et definert antall leveranser samtidig. Ved en kontinuerlig prosess for konstruksjon der stadig nye oppdragsavtaler inngås, vil oppdragsavtalenes statiske del til dels bli overlappende, slik det er illustrert i figuren under.
Figur 6 Etablering av bistands- og oppdragsavtaler (eksempel med oppdragsavtale som omfatter én leveranse)
Dersom det er behov for det, kan det også etableres bistands- og oppdragsavtaler i parallell, for eksempel for håndtering av feilrettinger og eventuelle mindre endringer fra tidligere produksjonssatte leveranser i parallell med utviklingen av programvaren.
Det gir normalt best ressursplanlegging ved å unngå overlappende bistandsavtaler, og bistandsavtaler omfatter ofte aktiviteter som behandler flere påfølgende leveranser.
4 Anskaffelsesprosess og etablering av kontrakt
4.1 Forutsetninger for etablering av kontrakt
Dersom anskaffelsen skal håndtere systemutvikling for en omfattende systemportefølje, der multisourcing er aktuelt for å etablere en god konkurransesituasjon og hensiktsmessig kompetansebredde, må antall kontrakter og omfang for de ulike kontraktene avklares. For hver delportefølje av programvaren forutsettes det at kontrakt etableres med kun én leverandør.
Kontrakten baserer seg på et løpende samarbeid mellom partene. Kundens og leverandørens ressurser for gjennomføring av bistandsavtaler og oppdragsavtaler bør derfor primært være samlokalisert eller alternativt ha etablert effektive elektroniske møteplasser for å ivareta det løpende samarbeidet.
Det tar tid å bygge opp kompetanse for systemutvikling og vedlikehold, avhengig av omfang og kompleksitet for programvarekomponenter og fagområde. Varigheten for kontrakten bør derfor være relativt lang (eksempelvis to til seks år), for at ikke oppstartsaktiviteter for en ny leverandør skal bli av for stort omfang i forhold til totalkostnaden for kontrakten. Dette gir også bedre kontinuitet for kundens systemforvaltning.
I tillegg er det flere andre temaer som kunden må avklare og som må defineres i bilagene til kontrakten:
- Hvem skal ha det overordnede ansvaret for ledelse og styring av løsningsbeskrivelsen?
Dersom kunden velger å ta dette ansvaret, forutsetter det relevant kompetanse og ledererfaring fra prosesser både for arkitekturstyring og løsningsutforming. Uansett er det leverandøren som utarbeider løsningsdesignet som skal legges til grunn for den etterfølgende oppdragsavtalen. På dette grunnlag anbefales det normalt at leverandøren gis ansvaret for ledelse og styring av løsningsbeskrivelsen.
- Hvordan skal vedlikehold av den utviklede programvaren håndteres?
Dersom vedlikehold av den utviklede programvaren skal anskaffes separat, må kontraktsstandard og tjenestekrav for vedlikehold defineres. Ved bruk av denne kontrakten, anbefales det sterkt at samme leverandør utfører både utvikling og vedlikehold for programvaren og at kontraktene fortrinnsvis inngås samtidig. Dersom det ikke er behov for å inngå en separat vedlikeholdskontrakt med klare krav til levering av vedlikeholdstjenestene, kan disse istedenfor bli levert som oppdragsbasert utvikling og konsulentbistand under kontrakten. Da vil vedlikeholdsoppgaver inngå som brukerhistorier i ordinære leveranser som inngår i kundens prioritering sammen med nye brukerhistorier. Eventuelt kan det inngås egne oppdragsavtaler med særlig fokus på vedlikehold. Omfanget for vedlikeholdsoppgavene må tas inn i omfanget for anskaffelsen.
- Hvordan skal ansvarsfordelingen og samarbeid være for håndtering av utviklings-, test- og produksjonsmiljøer?
Dersom ikke kunden drifter miljøene selv og heller ikke har en etablert driftsleverandør, må egen avtale for driftstjenester etableres.
- Hvordan skal metode og fremgangsmåte for test utformes?
Effektiv test innenfor en smidig gjennomføringsmodell forutsetter en egnet testmetode samt god verktøystøtte for å oppnå god testdekning innenfor hver iterasjon. Automatisert test samt effektiv verktøystøtte for miljøhåndtering og hyppig bygg er sentrale temaer her. En samlet testmetode vil være grunnlaget for krav til leverandørens gjennomføring av test på ulike nivåer.
4.2 Konkurransegrunnlag og krav til utforming av tilbud
Ved utsendelse av tilbudsforespørsel bør de generelle kontraktsbestemmelser og bilag, så langt de lar seg utfylle fra kundens side, være inkludert som grunnlag for potensielle leverandørers tilbud. I offentlige anskaffelser må dette ses i sammenheng med lov om offentlige anskaffelser med tilhørende forskrifter. Uansett bidrar kontraktsbestemmelser og bilag som er utfylt så komplett som mulig, til at leverandørenes tilbud mer effektivt kan sammenlignes, men også til at eventuelle uklarheter avdekkes og de blir mindre arbeidskrevende å ferdigstille som endelig kontrakt mellom partene.
Følgende punkter i bilagene bør forberedes av kunden så langt det er mulig i konkurransegrunnlaget:
- I bilag 1 skal kunden definere behov, formål, arkitektur og løsningskonsept som grunnlag for kontrakten, eventuell eksisterende programvare, standard programvare, tekniske miljøer og ansvar for miljøhåndtering. Videre må opphavs- og disposisjonsrett til programvaren være definert, herunder rettigheter til standard programvare spesielt.
- I bilag 2 skal gjennomføring av den oppdragsbaserte utviklingen beskrives, herunder fastsettelse av hovedmilepæler for oppstart og for gjennomføring av første leveranse. Kunden kan også beskrive overordnede krav til metode og dokumentasjon innenfor behovsanalyse, løsningsbeskrivelse, konstruksjon, test og godkjenning og videre krav til avslutningsaktiviteter. Forutsetninger for leverandørens oppstartsaktiviteter må inkluderes i tilbudsforespørselen. Kravene bør være så presise at leverandørene kan beskrive sine metoder og dokumentasjon på et hensiktsmessig nivå for kunden.
- I bilag 3 skal kunden definere krav til leverandørens kapasitet for avtaler samt terskler for endring av kapasitet. Det er viktig at det gjøres gode vurderinger for å fastsette disse tersklene så presist som mulig. Dette fordi, som et eksempel, et underforbruk i forhold til avtalt terskel for samlet reduksjon av kapasitet i kontraktsperioden ut over en periode på tre måneder, vil medføre at leverandøren kan si opp kontrakten. Kunden kan legge inn krav til metoder og retningslinjer, til kompetanseoverføring og bruk av underleverandører. Eventuelle krav til behandling av personopplysninger og sikkerhet skal også defineres her.
- I bilag 4 skal kundens kontaktpersoner være angitt. Videre skal krav til ressurshåndtering, rapportering og møter avklares. Kunden skal definere krav til lokalisering og eventuelle elektroniske møteplasser.
- I bilag 5 skal kunden definere terskel for endring av estimeringsmodellen, forutsetninger for årlig prisregulering, grenser for misligholdsbestemmelser samt grunnlag for avbestilling av kapasitet.
- Bilag 6 og 7 legges ved som mal for bistands- og oppdragsavtaler. Dersom kunden ønsker å innarbeide tilleggspunkter til malene, bør dette legges ved tilbudsforespørselen.
- Bilag 8 som i utgangspunktet er en tom avtalelogg, legges også ved utsendelse av tilbudsforespørselen.
- Leverandøren skal som del av tilbudet legge ved sin estimeringsmodell i bilag 9. Dersom kunden har noen instrukser til leverandørens utfylling av bilag 9 bør disse innarbeides og legges ved tilbudsforespørsel.
I tillegg til bilagene utarbeider kunden normalt et dokument som beskriver betingelser for konkurransen. Her defineres rammer for forventet omfang og kapasitet for kontraktsperioden, mål for kontrakten samt plan og betingelser for gjennomføring av konkurransen.
4.3 Leverandørens utfylling av tilbudstekst i kontrakt
Det anbefales at kunden gjennom konkurransegrunnlaget stiller krav om at leverandøren som del av tilbudet utarbeider en utfylt versjon av kontraktens bilag. Følgende punkter i bilagene bør da minimum fylles ut:
- I bilag 2 skal aktiviteter, plan, risiko og andre forutsetninger for oppstart av kontraktsperioden beskrives. Leverandørene skal også utdype aktiviteter, plan og ansvar ved avslutning av kontraktsperioden. Riskoen bør være dokumentert i en risikomatrise med angivelse av sannsynlighet, konsekvens og aktuelle tiltak.
- I bilag 3 skal leverandørens bemanning samt eventuelle underleverandører identifiseres.
- I bilag 4 skal leverandørens kontaktperson defineres. Dersom partene ikke samlokaliseres skal krav til kommunikasjonsløsninger og samarbeidsprosesser beskrives.
- I bilag 5 skal timepriser og tilleggspris på oppdrag i tilknytning til godkjenningsprøven defineres. Videre skal pris for oppstartsaktiviteter, prismodeller, sanksjonsgrunnlag og grenseverdier samt leverandørens timesats ved avbestilling oppgis. Leverandøren kan eventuelt kreve at timepriser legges til separat underbilag.
- I bilag 9 skal leverandørens estimeringsmodell og referanseestimater beskrives.
- I tillegg skal den første bistandsavtalen med leverandørens oppstartsaktiviteter legges ved tilbudet i utfylt form.
I tillegg er det nødvendig med et utvidet grunnlag for å evaluere leverandøren i forhold til det som vil fremgå av bilagene og den første bistandsavtalen. Dette omtales i etterfølgende punkt.
4.4 Grunnlag for evaluering av tilbud
Evaluering av tilbud i en konkurranse om oppdragsbasert, smidig leveranse av programvare vil i hovedsak basere seg på hovedområdene tilbudt kompetanse, gjennomføring av leveranser, kostnader og kontrakt. Selve evalueringen vil basere seg på leverandørenes besvarelse av kontrakten. Dette må være definert allerede i tildelingskriteriene som inngår i konkurransegrunnlaget.
Følgende områder kan inngå som grunnlag for evaluering av tildelingskriterier og dermed som krav til leverandørens besvarelse:
- Beskrivelse av kompetanse og erfaring for leverandørens tilbudte ressurser i forhold til relevante kompetansekrav for programvaren, standard programvare, relevante metoder samt det aktuelle domenet/forretningsområdet.
- Organisering og roller i leverandørens team for å håndtere parallelle prosesser innenfor utvikling og vedlikehold av programvaren samt samarbeid med kunden.
- Hvilke tiltak leverandøren vil gjennomføre for å sikre stabilitet i bemanningen over tid, og hvilken beredskap og forberedelser leverandøren vil gjennomføre for å håndtere kundens krav til eventuelle endringer av kapasitet.
- Leverandørens tilnærming til prosesser for arkitektur, løsningsutforming og test for programvaren basert på en smidig gjennomføringsmodell og kundens krav.
- Beskrivelsen av oppstartsaktiviteter, ref. bilag 2.
- Priser gitt i bilag 5, se også tilleggskommentar nedenfor.
- Beskrivelse av estimeringsmodell, ref. bilag 9.
- Leverandørens beskrivelser og eventuelle kommentarer og forbehold til øvrige punkter i bilagene.
For evaluering av tildelingskriterier for kostnader, bør det benyttes en simuleringsmodell, eventuelt også en referansecase, for beregning av kostnader for leverandørens aktiviteter basert på kontraktens prosesser, definerte krav til kapasitet og kontraktens totale varighet inklusive eventuelle opsjonsperioder.
5 Anvendelse av kontrakten
5.1 Kontraktens dokumenter
Kontraktsdokumentene beskriver omfang og rammebetingelser med ulike perspektiver:
- Kontraktens del I, II og III som er beskrevet i kapitelene ovenfor, regulerer prosesser og rammebetingelser som skal gjelde i hele kontraktsperioden.
- Bistandsavtalene regulerer kapasitet, ressurser, hovedmilepæler og rammebetingelser for bistand for en periode som normalt vil ligge innenfor to til seks måneder.
- Oppdragsavtalene regulerer omfang, kapasitet, gjennomføring og rammebetingelser som gjelder for en leveranse. Tidshorisonten for en oppdragsavtale vil normalt være tre til ni måneder.
- Oppdragsavtalens statisk del regulerer kapasitet, ressurser, tidsplan og rammebetingelser for en eller et definert antall leveranser.
- Oppdragsavtalens dynamiske del regulerer brukerhistorier, løsningsbeskrivelser og estimater og oppdateres fortløpende gjennom leveransen. En ny versjon av den dynamiske delen omfatter normalt brukerhistorier som realiseres innenfor en tidshorisont på en til tre iterasjoner innenfor leveransen. Likevel er det mulig å inngå avtale for hele leveransen slik at første versjon av den dynamiske delen av oppdragsavtalen blir fylt opp med brukerhistorier for leverandørens avtalte kapasitet for leveransen.
Denne inndelingen av kontraktsdokumentene støtter opp under sentrale prinsipper innen smidig systemutvikling som å utsette forpliktende beslutninger, hyppige leveranser og kontinuerlig forbedring. Omfang og pris for kontrakten kan ikke fastsettes på et detaljert nivå for hele kontraktsperioden, men vil være basert på den kapasitet som til enhver tid er avtalt
mellom partene sammen med kundens løpende prioritering av epos og tilhørende brukerhistorier, i kombinasjon med den estimeringsmodellen som er avtalt.
Kontrakten har ikke en generell regulering av endringer til kontrakten. Dette er basert på at partene primært håndterer endringer gjennom de bistands- og oppdragsavtaler som inngås, og at partene til enhver tid kan bli enige om endringer gjennom å utarbeide nye versjoner av avtalene og eventuelt også kontrakten. Spesifikk endringshåndtering er beskrevet i det etterfølgende for endring av ressurser, kapasitetsendringer og endringer i estimeringsmodell i de generelle kontraktsbestemmelser.
5.2 Ressurser
Leverandøren skal stille til rådighet avtalte, navngitte ressurser, ref. bilag 3. I bilaget skal det også fremgå hvilke av ressursene som anses som kritiske ressurser og hvilken kompetanse og erfaring som kvalifiserer for slik betegnelse.
Ressurser som kunden i kontraktsperioden ønskes skiftet ut, skal kunne erstattes med andre ressurser med minst tilsvarende kompetanse og gis tilstrekkelig opplæring og innføring. Det er angitt frister for slik utskiftning.
De som er angitt som kritiske ressurser, skal ikke kunne skiftes ut av leverandøren uten forutgående skriftlig godkjenning fra kunden. Det er angitt frister for slik godkjenning. Ved slik utskifting plikter leverandøren å erstatte ressursen med en tilsvarende ressurs uten kostnad for kunden. Dersom kontrakten inngås for en lang tidsperiode, vil det være naturlig med en viss utskiftning, også av kritiske ressurser.
Andelen kritiske ressurser anbefales å være i størrelsesorden 20-40 %.
5.3 Kapasitet
Leverandøren er forpliktet til å stille til disposisjon en kapasitet for bistandsavtaler og oppdragsavtaler i henhold til den initielle mobiliseringsplanen og deretter i henhold til kontrakten slik det skal fremgå av bilag 3. Behov for endret kapasitet må avtales mellom partene i henhold til frister og terskler som er regulert i kontrakten.
Hovedprinsippene for endringer i kapasitetsforpliktelser kan illustreres som følger:
Figur 7 Kapasitetsendringer
Kunden er forpliktet til å bruke den leverandørkapasitet som til enhver tid er avtalt. Dette gjøres ved etablering av bistandsavtaler og oppdragsavtaler. I bistands- og oppdragsavtalene defineres hvilke ressurser og hvilken andel av ressursene som skal disponeres innenfor de ulike avtalene. Dersom kunden har behov for avbestilling av bistands- eller oppdragsavtaler, er betingelser for dette regulert i kontrakten. Videre er det en beskrevet en prosedyre dersom det er behov for å avbestille hele kontrakten.
Ved økning av kapasitet vil nye ressurser fra leverandøren normalt ha behov for å sette seg inn i forretningsprosesser, programvare, verktøy, relasjoner og rammebetingelser, og det tar tid å oppnå full effektivitet. Hyppige og store endringer av leverandørens kapasitet kan gi et prosesstap som gjør at kundens realisering av gevinster blir redusert. Det er derfor viktig at kunden har gode prosesser for leveranse- og kapasitetsplanlegging slik at behovet for kapasitet ikke svinger mer enn nødvendig.
5.4 Bruk av estimeringsmodellen
Estimeringsmodellen skal brukes for å utarbeide alle estimater for det som skal utvikles av programvare innenfor den enkelte oppdragsavtale. Leverandørens bistand til behovsanalyse og løsningsbeskrivelse, samt eventuell annen bistand, inngår ikke i estimeringsmodellen.
Figur 8 Estimeringsmodell
Påslagsfaktor Beskrivelse | |||
8 Godkjenningsprøve | Leverandørens arbeid under godkjenningsprøven på grunn av manglende kvalitet i leveransen, herunder utbedring av feil. Faktorverdien er fast i avtaleperioden. | ||
7 Usikkerhet | Usikkerhetsfaktoren skal fange opp modenhet i behov, løsningsbeskrivelse samt teknisk kompleksitet og modenhet. Sammen med valg av prismekanisme dekker denne faktoren usikkerhetsnivået for en oppdragsavtale. Faktorverdi for påslagsfaktoren er fast for alle brukerhistorier og produktelementer innenfor en oppdragsavtale. | ||
6 Korreksjon i forhold til kundens deltagelse | Korreksjon hvis kunden utfører oppgaver som estimeringsmodellen forutsetter utføres av leverandøren eller leverandøren utfører oppgaver som skulle vært utført av kunden | ||
5 Administrasjon | |||
Prosjektledelse | Leverandørens ressursstyring, planlegging, merkantile oppfølging, faste møter (ut over faste iteasjonsmøter definert i kjerneestimatet) og løpende rapportering. Se også kontraktens Del III punkt 4.3. | ||
Iterasjonsdemo og iterasjonstilbakeblikk | Iterasjonsdemo - demonstrasjon ved avslutning av en iterasjon der produktene fra iterasjonen demonstreres for Kunden og andre interessenter. Iterasjonstilbakeblikk - møte ved avslutning av en iterasjon der utviklingsteamet ser på erfaringer og tiltak fra den iterasjonen de nettopp har vært gjennom. | ||
4 Dokumentasjon | Utarbeidelse og oppdatering av systemdokumentasjon, installasjons- og driftsdokumentasjon samt evt andre dokumentasjonskrav. | ||
3 Konfigurasjonsstyring og miljøhåndtering | Oppsett og kontroll av moduler og rapporter for bygging, kontinuerlig integrasjon og konfigurasjonsstyring, vedlikehold av miljøer for bygg og utvikling samt utarbeidelse av relevante deler av release-notater. | ||
2 Test | Leverandørens feilhåndtering og feilretting i forbindelse med integrasjonstest, systemtest og tekniske tester. Skal dekke arbeid i iterasjonene og ved evt. sluttest innenfor konstruksjon. | ||
Testledelse | Planlegging, forberedelse, oppfølging/koordinering og rapportering av testaktiviteter (inklusive testdata og testmiljøer). | ||
Integrasjons- og systemtest | Leverandørens testdatahåndtering og gjennomføring av integrasjonstest, systemtest og tekniske tester. Skal dekke arbeid i iterasjonene og ved evt. sluttest innenfor konstruksjon. | ||
Feilretting i integrasjons- og systemtest | Leverandørens feilhåndtering og feilretting i forbindelse med integrasjonstest, systemtest og tekniske tester. Skal dekke arbeid i iterasjonene og ved evt. sluttest innenfor konstruksjon. | ||
1 Design avklaringer | Leverandørens arbeid med tekniske og funksjonelle avklaringer overfor egne utviklingsteam. | ||
Kjerneestimat | Kjerneestimatet skal forholde seg til avtalens referanseestimater for typiske komponenter med definerte kompleksitetsnivåer. | ||
Detaljdesign | Leverandørens systemutvikling i henhold til relevante retningslinjer, krav og føringer fra Kunden. | ||
Utvikling | |||
Teknisk og funksjonell enhetstest inkl. feilretting | |||
Kodegjennomgang og bygging | |||
Testscenarier | Leverandørens utarbeidelse av testscenarier for leverandørens tester. | ||
Iterasjonsplanlegging | Aktivitet på første dag i en iterasjon for å beslutte hvilke deler av produktkøen som skal inngå i iterasjonen samt å dekomponere den utvalgte delen av produktkøen til oppgaver i utviklingsteamets iterasjonskø. | ||
Daglig møte | Xxxx, daglig møte i utviklings-teamet der hver deltager avklarer hva som er gjort siden forrige møte, hva som skal gjøres til neste møte samt eventuelle hindringer. | ||
Figur 9 Kort beskrivelse av påslagsfaktorene i estimeringsmodellen
Kontrakten beskriver en estimeringsmodell med en oppbygning som vist i figuren ovenfor. Estimeringsmodellen skal brukes som verktøy for leverandørens utarbeidelse av estimater som skal inngå i oppdragsavtale dynamisk del. Denne modellen er utarbeidet basert på erfaringer fra en rekke programvareprosjekter de senere årene. I kundens forberedelse av konkurransegrunnlaget samt gjennom anskaffelsesprosessen, må partene avklare eventuelle endringer i forhold til estimeringsmodellen i kontrakten. I kontraktsperioden bør det tilstrebes å holde oppbygging av modellen stabil slik at det er mulig å etablere et best mulig erfaringsgrunnlag for arbeidet med estimater.
Estimeringsmodellen skal omfatte referanseestimater for kjerneestimater for repetitive oppgavetyper i forhold til programvaren. Dette bidrar til å gi partene god forutberegnelighet for repetitive utviklingsoppgaver innenfor leveransene og en viss forutberegnelighet for det samlede kostnadsnivået for konstruksjon. Kjerneestimat for oppgaver der det ikke er etablert referanseestimater, vil normalt håndestimeres ved bruk av ulike estimeringsteknikker eller gjennom parvis sammenligning med oppgaver innenfor leverte brukerhistorier.
Alle faktorer utenfor kjerneestimatet er normalt rene prosentpåslag slik at det ikke er estimering basert på vurdering utenom kjerneestimatet. Faktorverdiene skal være gjeldende for hele kontraktsperioden. Dette bidrar til god forutberegnelighet for estimatene.
For at estimeringsmodellen skal håndtere ulike kompleksitetsnivåer for test som skal gjennomføres innenfor en leveranse, er det for denne faktorverdien normalt definert flere lovlige verdier. Hensynene bak dette kan være at det er særskilt komplekse verdikjeder i leveransen, spesielt behov for regresjonstest og/eller spesielt lav feiltoleranse. Den laveste verdien vil dekke situasjoner for test som er enkle, men normale, for programvaren.
Maksimalverdi vil avhengig av testkompleksitet, kompleksitet av verdikjeder, feiltoleranse og rammebetingelser for test.
Programmatiske tester og automatisk generering av testdata for kompleks integrasjons-, ytelses- og regresjonstest kan defineres som oppgavetyper med referanseestimat som inngår i kjerneestimatet.
Partene kan bli enige om endringer av påslagsfaktorene på kjerneestimatet, eventuelt også av referanseestimater for relevante oppgavetyper, innenfor definerte terskler. Dette for å tilpasse modellen i henhold til erfaringer fra gjennomføringen av oppdragsavtalene. Endringene må være rimelige, dokumenterbare og baseres på konkrete begrunnelser. Dersom endringene i estimeringsmodellen medfører en samlet endring av kostnadsnivået over en avtalt terskel i forhold til forutsetningene ved inngåelse av kontrakten, kan en av partene kreve å få gjennomført en revisjon av endringene av estimeringsmodellen. Dette for å belyse om endringene er forsvarlige.
5.5 Bruk av bistandsavtaler
Bistandsavtaler etableres ved at:
- kunden utarbeider forslag til bistandsavtale basert på malen i bilag 6,
- leverandøren kommenterer og kompletterer forslaget til bistandsavtale og
- kunden ferdigstiller bistandsavtalen; ved behov gjennomføres forhandling av utestående punkter.
Bistandsavtaler må understøtte maksimal arbeidsflyt og effektivitet knyttet til leverandørens arbeid og samarbeidet mellom partene slik at kontinuerlige prosesser for behovsanalyse og løsningsbeskrivelse kan gjennomføres effektivt og i tide og være et godt grunnlag for konstruksjon. Dette innebærer at bistandsavtale må være inngått før oppstart av behovsanalyse for en kommende leveranse.
Bistandsavtaler skal ikke omfatte aktiviteter som utgjør endring eller utvidelse av selve programvaren. Alle slike leveranser skal inngå i Oppdragsavtaler.
Omfanget i avtalen defineres i henhold til hovedaktiviteter som skal gjennomføres, og som også vil definere nivå for leverandørens timeføring for konsulentbistand. Hovedaktivitetene kan for eksempel bestå av:
- bistand til behovsanalyse for leveranse n,
- bistand til løsningsbeskrivelse for leveranse n,
- bistand til behovsanalyse for leveranse n+1 og
- bistand for å støtte kundens håndtering av testmiljøer og testplan for godkjenningsprøve for leveranse n.
Dersom kunden ikke har etablert en separat vedlikeholdsavtale, kan vedlikeholdstjenester relatert til programvaren som er satt i produksjon tas inn i bistandsavtaler.
Aktivitetene i bistandsavtalen følges normalt opp av kundens produkteiere og eventuelt andre teamledere gjennom partenes samarbeid innenfor de definerte hovedaktivitetene. I tillegg må kunden ha en funksjon/rolle som følger opp at timeføring og fakturering følger den avtalte rammen samt definerte rutiner.
5.6 Bruk av oppdragsavtaler
Oppdragsavtaler består av en statisk og en dynamisk del.
5.6.1 Oppdragsavtaler - statisk del
Oppdragsavtalers statiske del etableres ved at:
- kunden utarbeider forslag til oppdragsavtale basert på malen i bilag 7,
- leverandøren kommenterer og kompletterer forslaget til oppdragsavtale og
- kunden ferdigstiller oppdragsavtalen; ved behov gjennomføres forhandling av utestående punkter.
En oppdragsavtale kan omfatte én eller flere leveranser. Dersom leveransene består av flere enn 5 iterasjoner, vil det normalt etableres flere oppdragsavtaler; typisk en for hver leveranse. For kunder som gjennomfører leveranser med få iterasjoner og hyppige produksjonssettinger, kan oppdragsavtalene omfatte flere leveranser. Det er også mulig med større enkeltleveranser, som i PS2000 Smidig, slik at det inngås én oppdragsavtale for alle (flere enn 5) iterasjonene i en leveranse. Løsningsbeskrivelsen må imidlertid uansett gjennomføres på en bistandsavtale og vil da ikke inngå i målpris.
For systemutvikling av prioriterte brukerhistorier, vil det innenfor en og samme kontrakt normalt ikke etableres parallelle oppdragsavtaler. Dersom det inngår brukerhistorier som hos kunden finansieres fra ulike interne oppdragsgivere og med behov for kostnadsoppfølging for hver oppdragsgiver, vil det normalt defineres separate epos og tilhørende brukerhistorier for hver oppdragsgiver. Disse inngår da samlet i produktkøen for leveransen for prioritering, detaljering og realisering. Alternativt etableres parallelle oppdragsavtaler. Det kan særlig være aktuelt dersom kunden ikke har etablert en separat vedlikeholdsavtale. Slike parallelle oppdragsavtaler kan da inkludere vedlikeholdsaktiviteter som medfører endring av programvaren.
Dersom kunden ikke har etablert en separat vedlikeholdskontrakt, men ønsker å gjennomføre feilretting av produksjonssatt programvare som en del av leveransen, kan det være hensiktsmessig å etablere en separat oppdragsavtale for slik feilretting. Dette siden leveransemodellen for feilretting, spesielt for kritiske og alvorlige feil, avviker fra leveransemodellen for utvikling av programvare.
Kunden må definere inngangskriterier og utgangskriterier for godkjenningsprøven i oppdragsavtalen.
Kunden bør definere vederlagsmekanismen for hver oppdragsavtale basert på en vurdering av omfanget av usikkerheten i leveransen:
- Dersom det er vesentlige usikkerhetsfaktorer for systemutviklingen som ikke kan styres av leverandøren, noe det oftest er i starten av kontraktsperioden, bør eventuelt oppdraget gjennomføres basert på løpende timer.
- Ved en mer balansert styring av usikkerhetsfaktorer mellom kunde og leverandør, bør vederlagsmodellen være basert på målpris. Målpris bør være den normale vederlagsmodellen for kontrakten.
- Dersom usikkerhetsfaktorene for oppdraget i hovedsak styres av leverandøren, kan kunden vurdere å be om fast pris.
De ulike vederlagsmodellene kan illustreres som beskrevet nedenfor:
Figur 10 Vederlagsmodeller
Figuren over viser hvordan leverandørens timesats endrer seg ved under- og overforbruk gitt ulike vederlagsmodeller. En oppdragsavtale kan unntaksvis også defineres med flere vederlagsmodeller avhengig av rammebetingelser og risikonivå for ulike deler av leveransen.
Vederlagsmodellene beskrevet ovenfor benyttes for alt som inngår i konstruksjon i en oppdragsavtale. Videre tilkommer det en forhåndsdefinert tilleggspris for Godkjennings- prøven. Alle andre oppgaver karakteriseres som bistand og skal inngås som bistandsavtaler.
5.6.2 Oppdragsavtaler – dynamisk del
Samtidig med den statiske delen av oppdragsavtalen, må det etableres en dynamisk del av oppdragsavtalen for minimum den første iterasjonen slik at arbeidet med konstruksjon kan komme i gang. Som nevnt tidligere er det likevel er det mulig å inngå avtale for hele leveransen slik at den dynamiske delen av oppdragsavtalen blir fylt opp med brukerhistorier for hele leverandørens avtalte kapasitet for leveransen. For øvrig må nye versjoner av den dynamiske delen av oppdragsavtalen løpende komme på plass i tide for de neste iterasjonene. Omfanget for en brukerhistorie bør ha som utgangspunkt at brukerhistorien normalt skal kunne realiseres i løpet av en iterasjon.
Kunden kan endre prioritet for brukerhistorier innenfor dynamisk del som skal utvikles etter inneværende iterasjon. Dersom kunden vil endre prioritet for brukerhistorier i en iterasjon som er påbegynt, må leverandøren få godtgjort for det merarbeidet dette medfører og nye versjoner av den dynamiske del av oppdragsavtalen må utarbeides på bakgrunn av dette.
Leverandøren skal gjøre en vurdering av eventuelle konsekvenser av endring av prioritet for brukerhistorier i dynamisk del, med mindre partene er enige om at dette ikke er nødvendig.
Kontrakt: <Kontraktsnavn og kontraktsnummer> | |||||||||||
Oppdragsavtale: <avtalenummer> | |||||||||||
Vedlegg 1 Oppdragsavtale dynamisk del | |||||||||||
Versjon: <versjonsnummer> | |||||||||||
Dato: <dato> | Epos | Brukerhistorie | |||||||||
Produktkø nivå | Referanse til brukerhistorie og løsningsbeskrivelse | Kort beskrivelse | Planlagt leveranse | Omfang epos | Omfang signert | Vederlags- form | Estimat timer | Risikopåslag timer | Timer inkludert risikopåslag | Versjon | Kommentar |
Epos | |||||||||||
Historie | |||||||||||
Historie | |||||||||||
Historie | |||||||||||
Historie | |||||||||||
Historie | |||||||||||
Historie | |||||||||||
Epos | |||||||||||
Historie | |||||||||||
Historie | |||||||||||
Historie | |||||||||||
Epos | |||||||||||
Historie | |||||||||||
Historie | |||||||||||
Historie | |||||||||||
SUM signert | |||||||||||
Signatur Kund | e ……………………………… | ……………………. | Signatur Le | erandør ……… | …………………… | ………………… | .. | ||||
v
Figur 11 Oppdragsavtale dynamisk del
Den dynamiske delen av oppdragsavtalen etableres normalt ved et enkelt skjema som signeres av partene når ny versjon etableres, se figuren over. Referanser til brukerhistorier og løsningsbeskrivelser realiseres lettest ved henvisninger til et administrasjonsverktøy for en produktkø, der brukerhistoriene og løsningsbeskrivelser med riktig versjon er håndtert.
Feltene innenfor Epos brukes for å styre omfanget av brukerhistoriene i forhold til budsjett for et epos. Timetall for feltene innenfor Brukerhistorie hentes normalt fra regneark som beregner estimat og risikopåslag basert på estimeringsmodellen i kontrakten. Risikopåslag for brukerhistorier med vederlagsmodell basert på løpende timer er null, mens risikopåslag for alle brukerhistorier med vederlagsmodell basert på målpris benytter samme prosentpåslag definert i en oppdragsavtale statisk del.
5.7 Konfliktløsning
Gjennomføringsmodellen i kontrakten forutsetter et tett samarbeid mellom partene for gjennomføring av hovedprosessene. Effektiv gjennomføring av til dels komplekse prosesser med høy grad av avhengighet mellom partene over lang tid forutsetter god og løpende håndtering av konflikter. Kontrakten legger derfor opp til at konflikter håndteres på lavest mulige nivå, og med en tydelig eskalering av konfliktløsningen til neste nivå ved behov.
Kontrakten forutsetter at konflikter i første omgang håndteres av partenes prosjektledere. Konflikter som ikke kan løses på dette nivået, skal skriftlig legges fram for koordineringsgruppen. Det er en fordel om partenes prosjektledere utarbeider et felles underlag for behandling i koordineringsgruppen.
For eventuelle konflikter som ikke kan løses av partenes ledelse som en del av arbeidet i koordineringsgruppen, kan partene enes om en uavhengig ekspert som enten gjennomfører en megling eller utarbeider en skriftlig uttalelse med løsningsforslag for konflikten.
Siste nivå i prosedyren for konflikthåndtering er å bringe konflikten inn for behandling i alminnelige domstoler eller voldgiftsbehandling.
5.8 Mislighold
Mislighold er situasjoner der en av partene ikke oppfyller sine forpliktelser i kontrakten. Det er i kontrakten regulert flere situasjoner som det er ansett kan oppstå med en viss sannsynlighet, særlig i en smidig gjennomføringsmodell, og som derfor er definert med standardiserte sanksjoner.
En smidig gjennomføringsmodell krever god flyt ved kontinuerlig gjennomføring av flere prosesser i parallell og hvor partene samarbeider løpende. Dette har betydning for hvilke misligholdssituasjoner som kan oppstå. Nedenfor er de spesifikke misligholdssituasjonene kommentert.
5.8.1 Leverandørens mislighold
- Mangler ved løsningsbeskrivelsen
Misligholdet oppstår dersom arbeidet i løsningsbeskrivelsen, under leverandørens overordnede ledelse og styring, er forsinket eller har mangler. Konsekvensen kan være at leverandørens ressurser ikke kan utnyttes effektivt på grunn av at produktkøen ikke er klar i tide for konstruksjon i kommende iterasjon. I dette tilfellet må leverandøren selv dekke kostnaden for ledige ressurser. En annen konsekvens kan være at oppstart av konstruksjon for en leveranse blir forsinket, noe som kan medføre erstatningskrav fra kunden.
- Forsinkelse av en leveranse
Dagbotsanksjonerte milepæler er i kontraktsmalen begrenset til milepælen for godkjenning i godkjenningsprøven for en leveranse. Dette på grunn av at samarbeidet mellom partene i de øvrige prosessene er så tett, kombinert med løpende prioritering og omprioritering, at det ikke er rimelig med sanksjoner knyttet til forsinkelse der.
- Vesentlige avvik mellom estimat og faktisk forbruk i en leveranse
Dette er en situasjon der leverandøren har et merforbruk i forhold til estimat som er vesentlig og som i lengden vil være uakseptabel for kunden. Situasjonen kan typisk oppstå i starten av en leveranse, og spesielt helt i starten av kontraktsperioden på grunn av initiell læringsprosess. Dette er bakgrunnen for at misligholdet kun er aktuelt etter at et antall iterasjoner er gjennomført i en leveranse. Det vil kun bli ansett som mislighold dersom merforbruket ikke reduseres i løpet av leveransen. Misligholdet er definert ved at faktisk forbruk overstiger det dobbelte av godkjent estimat. Antall iterasjoner der dette misligholdet kan oppstå, bør være definert slik at denne situasjonen ikke oppstår i leveranser med få iterasjoner. Beregningen foretas kun i forhold til godkjente brukerhistorier. Det vil si at så lenge brukerhistorier ikke godkjennes, vil heller ikke avvik kunne beregnes. Dersom brukerhistorier ikke godkjennes, er det andre sanksjonsmekanismer som trer i kraft, herunder at vederlag først avregnes når brukerhistorier er godkjent.
- Manglende bemanning i forhold til avtalt kapasitet
Misligholdet oppstår dersom leverandørens kapasitet for å gjennomføre avtaler, i form av forbrukte timer, ikke er i henhold til den kapasitet som er avtalt i kontrakten.
Kunden vil da få levert mindre omfang enn forutsatt ved kontraktsinngåelsen. For å kunne avklare bemanningen i forhold til avtalt kapasitet presist, er avregningsperioden definert til kontraktsperioden for en oppdragsavtaleet kvartal.
- Rettsmangler i forbindelse med en avtale
Dersom resultatet av en avtale medfører at en tredjepart fremmer krav om at dennes opphavs- eller eiendomsrettigheter er krenket, har leverandøren en plikt til avhjelp til
kunden. Hvis leverandøren ikke kan avhjelpe rettsmangelen, og dette er vesentlig for kunden, kan kunden heve kontrakten og kreve erstatning.
- Medvirkning ved gjennomføring og andre plikter
Mislighold ved manglende medvirkning fra kunden kan oppstå i forbindelse med alle hovedprosessene for systemutvikling. I misligholdsbestemmelsen er krav til kundens utforming og prioritering av produktkøen i behovsanalysen og løsningsbeskrivelsen samt kundens utprøving av brukerhistorier og gjennomføring av kontrollpunkt under konstruksjon spesielt fremhevet. Grunnlaget for anvendelse av misligholdsbestemmelsen i denne kontrakten er bredere enn i tradisjonelle kontrakter siden kontraktens beskrivelse av kundens ansvar er omfattende i en smidig gjennomføringsmodell.
- Leverandøren kan midlertidig ikke utnytte avtalt kapasitet
Dette er en situasjon der leverandøren i en kortere periode, og typisk på kort varsel, ikke kan utnytte bemanningen effektivt. Et eksempel er at det oppstår en feil i kundens testmiljø slik at leverandørens team ikke kan gjennomføre planlagte testaktiviteter.
- Manglende inngåelse av bistands- og oppdragsavtaler for å utnytte avtalt kapasitet Dersom kunden ikke etablerer avtaler med et omfang som utnytter leverandørens avtalte kapasitet, er dette å betrakte som et mislighold. Enten må leverandøren kreve at kunden endrer avtalt kapasitet eller dersom misligholdet er vesentlig, heve kontrakten.
5.9 Avslutning av kontrakten
Dersom kunden ved avslutning av Kontrakten har behov for å etablere en ny kontrakt for å videreføre utviklingen av programvaren, bør kunden gjennomføre følgende aktiviteter i tide før utløp av kontraktsperioden:
- Forberede og gjennomføre en anskaffelsesprosess for å etablere en ny kontrakt for oppdragsbasert, smidig leveranse av programvaren.
- Gjennomføre et prosjekt for overføring av videreutviklingen av programvaren til en ny leverandør.
For store og komplekse programvareporteføljer kan de ovennevnte aktivitetene ta opp mot et kalenderår.
Det er derfor viktig å sette av tid nok til å gjennomføre et prosjekt der etableringen av en eventuell kontrakt med ny leverandør gis tilstrekkelig omfang og kvalitet. Dette er viktig for å etablere en god konkurransesituasjon i markedet og sikre at alle leverandører gis en mest mulig lik mulighet for å vinne kontrakten.
Ved overføring av ansvaret for utvikling av programvaren til en ny leverandør, må dagens leverandør være forpliktet til delta slik at prosjektet kan gjennomføres effektivt og på en måte som reduserer risiko for kvalitetsavvik for kunden i forbindelse med leverandørskiftet.