Bilag 8 - Leverandørens udviklingsleverancer
Forside - Indhold - Forrige/ Næste
"Vejledning - Kontrakter om komplekse it-ydelser"
8.1 Udvikling
Såfremt kontrakten omhandler udviklingsleverancer i relation til konkret definerede projekter, skal kontrakten selvfølgelig indeholde kundens kravspecifikation med angivelse af de endelige forbehold overfor kravspecifikationen, som leverandøren har taget, samt eventuelle ændringer i kravspecifikationen, som der måtte være opnået enighed om mellem leverandøren og kunden.
Såfremt leverandøren, for eksempel i forbindelse med outsourcing af hele kundens udviklingsområde, skal overtage igangværende projekter vedrørende udvikling af brugerprogrammel, skal der angives i dette bilag en meget nøje status på udviklingsprojekterne, samt estimering af resttid på færdiggørelsen. Ligeledes skal der i denne situation udarbejdes en oversigt over de udviklingsprojekter, kunden allerede har planlagt, men ikke er påbegyndt af kunden, og som leverandøren skal udvikle.
Samtidig skal status og kvalitet af dokumentation til igangværende og planlagte udviklingsprojekter beskrives for hvert projekt.
Såfremt leverandøren tillige overtager driften af kundens edb-system, skal endvidere beskrives de udviklingsprojekter, kunden har under udvikling eller har planlagt udviklet, og som kunden færdiggør og sætter i produktion, inden leverandørens overtagelse af driften.
I relation til overtagelse af driften vil allerede eksisterende brugerprogrammel fremgå af bilag 4c.
I relation til leverandørens overtagelse af færdigudviklingen af igangværende projekter eller leverandørens varetagelse af planlagte projekter, skal der tillige fastsættes frister for aflevering af kravspecifikation, aflevering af systembeskrivelse, kundens godkendelse af systembeskrivelse, tidspunkter for udarbejdelse af testmateriale, gennemførelse af test etc. Dette vil være en forudsætning for, at kunden kan anmode leverandøren om at angive tidspunkter for færdiggørelse af udviklingsprojekterne.
8.2 Fejlafhjælpning ved afleveringen, i garanti- og eventuel vedligeholdelsesperiode
Opdelingen af fejl i forskellige typer vil være knyttet sammen med de tidsrum, inden for hvilke de skal være rettet. Fristerne vil typisk fremgå af bilag 7 B, hvoraf det tillige vil fremgå, hvilke konsekvenser den manglende opfyldelse af servicekategorierne vil have. Her vil ligeledes fremgå en kategorisering af bestemte fejltyper.
Nedenfor er angivet en række forhold, som kan behandles i et bilag om fejlafhjælpning ved udviklingsleverancer. Beskrivelsesn tilsigter ikke at være udtømmende, og andre metoder vil også kunne anvendes.
8.2.1 Generelt
Leverandørens fejlafhjælpning omfatter det af nærværende kontrakt omfattede brugerprogrammel, der er individuelt udviklet for kunden og for kundens regning af leverandøren, og dækker således ikke andet programmel, der benyttes i tilknytning hertil.
Fejlafhjælpning for standardprogrammel fremgår af licensbetingelserne i bilag 13.
Assistancen ydes til rettelse af fejl i det specificerede programmel. Fejl, der skyldes andre årsager, herunder for eksempel betjeningsfejl eller set-up fejl hidrørende fra andre end leverandøren, er ikke omfattet.
Leverandøren forpligtelse i garantiperioden og i en eventuel efterfølgende vedligeholdelsesperiode, er kun gældende forudsat, at der ikke er foretaget ændringer i det leverede programmel af andre end leverandøren.
Assistancen ydes på kundens eller leverandørens adresse efter leverandøren valg.
8.2.2 Behandling af klassificering af fejl i specialudviklet programmel
Såfremt kunden ved afleveringen, i den efterfølgende garantiperiode eller vedligeholdelsesperiode konstaterer, at der er fejl i det programmel, som leverandøren udvikler og leverer under nærværende kontrakt, jf . § 8 skal kunden hurtigst muligt informere leverandøren skriftligt om sådanne fejl. kunden indsender en fejlrapport bilagt udførlig dokumentation. Fejlrapporten skal indeholde kundens foreløbige klassifikation af fejlen.
Ved fejl forstås generelt enhver afvigelse fra de godkendte acceptkriterier.
Når eksistensen af en fejl er bekræftet af leverandøren, og det kan verificeres, at fejlen kan genskabes, vil fejlen blive klassificeret i overensstemmelse med reglerne som anført i det følgende. En foreløbig klassifikation foretages af kunden, jf . ovenfor, og efter en nærmere analyse af fejlen, foretages endelig klassifikation af kundens og leverandøren i fællesskab. Klassifikationen baserer sig generelt på såvel manglende funktionalitet som dataopdatering.
8.2.3 Fejltyper i det af leverandøren leverede programmel ved test og aflevering
Type 1 "Alvorlig fejl" er en fejl, som medfører, at testen eller afleveringen må suspenderes på grund af fejlen.
Type 2 "Betydelig fejl" er en fejl, som ikke kan omgås, og som medfører, at dele af testen eller afleveringen ikke kan gennemføres. Dersom en sådan fejl forekommer, skal aktiviteten fortsættes med de kørsler og transaktioner, der ikke er påvirket af denne fundne betydelig fejl.
Type 3 "Ubetydelig fejl" er en fejl, som ikke forhindrer testens eller afleveringens gennemførelse, eller en fejl som kan omgås. Leverandøren skal hurtigst muligt fremlægge en plan for, hvorledes ubetydelig fejl vil blive forsøgt korrigeret. Ubetydelig fejl skal ikke hindre, at afleveringen gennemføres, eller at systemet installeres i produktion.
Type 4 "Dokumentationsfejl" er en fejl i programmellets dokumentation (skriftligt materiale, skærmbillede, hjælpetekst, m.m.) Testen eller afleveringen skal fortsættes på trods af forekomst af Dokumentationsfejl. Leverandøren skal hurtigst muligt fremlægge en plan for, hvorledes Dokumentationsfejl vil blive korrigeret. .
Alle fejl, der klassificeres som type 1 eller type 2, skal være afhjulpet, inden aflevering kan finde sted.
I garantiperioden er leverandøren kun ansvarlig for rettelse af de fejl, der rapporteres til leverandøren, og som kan klassificeres som type 1 og type 2 fejl, jf . definitionen ovenfor.
8.2.4 Fejltyper i det af leverandøren leverede programmel i garanti- og vedligeholdelsesperioden
Type 1 "Alvorlig Fejl" er en fejl, som medfører, at anvendelsen af programmellet må suspenderes på grund af fejlen, eller en fejl, hvor en bruger mister data.
Type 2 "Betydelig Fejl" er en fejl, som medfører, at dele af eller visse funktioner i programmellet ikke kan anvendes, og fejlen ikke med rimelighed kan omgås.
Type 3 "Ubetydelig Fejl" er en fejl, som ikke forhindrer fuld anvendelse af en funktion, eller en fejl, der kan omgås.
Type 4 "Dokumentationsfejl" er en fejl i programmellets dokumentation (skriftligt materiale, skærmbillede, hjælpetekst, m.m.)]
8.2.5 Behandling af fejl
Fejlrapport kan afgives på følgende måde:
• Pr. post
• Pr. elektronisk post
• Pr. telefax
• Pr. telefon
Leverandøren udfører efter modtagelse af fejlrapport med udførlig dokumentation følgende:
• Modtagelse af fejlrapport fra kunden inden for det aftalte servicetidsrum
• Oprettelse og vedligeholdelse af et fejlregister, der indeholder en oversigt over den rapporterede fejl og en status på fejlrettelsen.
• Kommunikation med kundens kontaktperson om udestående registrerede fejl.
• Undersøgelse af, om den rapporterede fejl allerede er kendt, og levering af en eventuel løsning til kunden.
• Modtagelse og behandling af dokumentation af kunden, samt eventuel anmodning om yderligere nødvendig dokumentation.
• Kvittering for modtagelsen af fejlrapport og dokumentation fra kunden (telefonisk eller elektronisk).
• I særlige tilfælde identifikation af det programmel, der er fejlbehæftet.
• Udarbejdelse og levering af løsning til kunden.
8.2.6 Besvarelse af fejlrapporter og levering af fejlrettelser
Leverandøren lukker eller besvarer en modtaget fejlrapport med én af følgende betegnelser:
• "Programfejl": Leverandøren leverer en løsning, der vil bestå i en rettelse til programmellets kode eller i en omgåelse af fejlen.
• "Dokumentationsfejl": Leverandøren leverer eventuelt en rettelse til programmellets dokumentation.
• "Ingen fortsat behandling": Leverandøren kan stoppe behandlingen af en fejlrapport, for eksempel med en af følgende begrundede årsager:
- Fejlrapporten er trukket tilbage af kunden. Den rapporterede fejl kan ikke henføres til det programmel, der er dækket af kontrakten.
- Den rapporterede fejl kan ikke genskabes. Fejlrapporten lukkes indtil videre, og kan genåbnes, hvis fejlen senere opstår og kan genskabes.
- Den rapporterede fejl kan identificeres som en allerede kendt fejl eller som symptom på allerede kendt fejl.
Leverandøren leverer fejlrettelser til programmel elektronisk, på diskette eller på tape.
Der udarbejdes kun rettelser til gældende versioner af programmellet.
Udarbejdede rettelser inkluderes normalt af leverandøren i en eventuel efterfølgende release/version af programmellet.
8.2.7 Servicetidsrum og reaktionstid
Leverandørens assistance er tilgængelig inden for arbejdsdage mellem kl.
og kl.
..
Ved behandling af fejl i programmellet vil leverandøren påbegynde behandlingen af fejlrapporten inden for den reaktionstid, der er anført i kontrakten.
Reaktionstiden er tiden fra leverandøren modtager kundens fejlrapport, og indtil leverandøren bekræfter modtagelsen.
Modtages en fejlrapport, således at reaktionstiden vil løbe ud over den anførte arbejdstid, jf . ovenfor, vil leverandøren normalt påbegynde fejlrettelsen ved starten af den følgende arbejdsdag.
- Foretage foreløbig fejlanalyse for at afgøre, om der er fejl i selve programmellet.
- Indsamle nødvendig dokumentation til fejlrapporten.
- Foretage foreløbig klassifikation af fejlrapporter i type 1 - 4, samt foretage indbyrdes prioritering ved forekomsten af flere samtidige fejl.
- Afgive fejlrapport til leverandøren.
- Hvor muligt genskabe fejlsituationer til brug for programrettelser, samt eventuelt indsamle yderligere dokumentation.
- Installere løsningen, som leverandøren leverer.
Fejlrapporten fra kunden skal minimum indeholde følgende information:
- Identifikation af programmellet incl. version og release.
- Fejlbeskrivelse: Beskrivelse af symptomerne, og i hvilken for bindelse fejlen optræder
- Klassifikation af fejltypen.
- Kontaktperson hos kunden
- Dato/tid for oprettelsen.
- Dato/tid for fejlens konstatering
Afhængig af det aktuelle fejlsymptom kan der være behov for yderligere dokumentation, eksempelvis:
- Relevante datafiler
- Programmellets "error log".
Leverandørens model-fejlrapport anvendes af kunden.
|
Elektronisk publikation fremstillet af J.H. Schultz Grafisk A/S efter Forskningsministeriets retningslinier |