Projekt: Projekt Abnahmeprotokoll /-bericht „klein“

Dokumentenart & Status

Kunde	Gültigkeit des Dokuments
xx	xx
Status	Zweck und Abgrenzung des Dokuments
xx	xx
Datum	Dateiname	Version
9. März 2016	abnahmeprotokoll_v2-1	V0-1

Freigabe
Name	Datum	Unterschrift
Name Projektleiter	14.12.2014
Name Betriebsverantwortlicher	14.12.2014
Name Applikationsverantwortlicher	14.12.2014
SName Applikationsverantwortlicher	14.12.2014
Name Applikationsverantwortlicher	14.12.2014

Inhaltsverzeichnis

1	Einleitung und Ausgangslage	3

1.1	Zweck des Dokuments	3

1.2	Ausgangslage / Scope	3

1.3	Hauptprüfkriterien	3

1.3.1	Applikation „Funktionale Anforderungen“	3

1.3.3	Applikation „Ergänzende Systemkomponenten“	4

1.3.4	Applikation „Nicht funktionale Anforderungen“	4

2	Prüfelemente und Aspekte	5

2.1	Applikatorischer Funktionsumfang (Brauchbarkeit, Vollständigkeit)	5

3	Nicht funktionale Anforderungen	6

3.2	Ergänzungen	7

4	Mängel	8

4.1	Mängelliste	8

5.1	Installation, Installationskontrolle	9

5.2	Informationen, Erkenntnisse aus den Tests für den Betrieb	9

5.3	Überführen der Mängel und Restanzen in den Change-Management-Prozess	9

Einleitung und Ausgangslage

Zweck des Dokuments

Dieses Dokument soll die

Ausgangslage / Scope

.

Hauptprüfkriterien

Applikation „Funktionale Anforderungen“

Die zusammenfassende Beurteilung bezüglich der funktionalen Anforderungen der laufenden Applikation erfolgt bezüglich den folgenden vier Hauptaspekte:

Nr.	Finale Aspekte	Erfüllt	Mit Vorbehalt	Nicht erfüllt
01	Adäquatheit des Systemverhaltens (Brauchbarkeit)
02	Vollständigkeit
03	Anleiten/Konzepte
04	Rahmenanforderungen
05	Bausteine und Module
06	Test
07	Technische Dokumentation

Beim Abnahmetest geht es nicht darum Fehler zu finden, sondern zu zeigen, dass die Applikation die gestellten Anforderungen im laufenden Betrieb erfüllt, d.h. in allen getesteten Fällen fehlerfrei (ohne Fehlerklasse A) arbeitet! Die Abnahme erfolgte auf dem Release ????

Bewertung	Abnahme	Kriterium	Beschreibung
0	Ja	Erfüllt	--
D (1)	Ja (<=30)	leichte Fehler	Es sind Mängel in der Darstellung, im Layout oder in der Dokumentation enthalten.
C (2)	Ja (<=10)	mittlere Fehler	Teile des Systems, die unmittelbar weder für den Betrieb noch für die Nutzung des Systems notwendig sind, können nicht verwendet werden. Ein Betrieb und die Nutzung des Systems sind mit geringen Einschränkungen möglich.
B (3)	Ja (<=3)	schwere Fehler	Wesentliche Teile des Systems, die nicht zwingend zum Betrieb, aber zur Nutzung des Systems notwendig sind, sind nicht nutzbar. Ein Betrieb des Systems ist eingeschränkt möglich. Aus Sicht KStA dürfen maximal 3 Fehler dieser Art auftreten. Andernfalls kann die Abnahme verweigert werden.
A (4)	NEIN	abnahmehinderliche Fehler	Wesentliche Teile, die für den Betrieb und die Nutzung des Systems erforderlich sind, können nicht verwendet werden. Die Abnahme kann verweigert werden.

Applikation „Ergänzende Systemkomponenten“

Die zusammenfassende Beurteilung bezüglich der ergänzenden Systemkomponenten der laufenden Applikation erfolgt bezüglich der folgenden Hauptaspekte:

Nr.	Finale Aspekte	Erfüllt	Mit Vorbehalt	Nicht erfüllt
01	Change Request Liste
02	Qualitätssicherungs-System
03	Softwarearchitektur
04	Verträge
05	Sicherheit und Datenschutz
06	Weitere Anforderungen

Applikation „Nicht funktionale Anforderungen“

Die zusammenfassende Beurteilung bezüglich der nicht funktionalen Anforderungen der laufenden Applikation erfolgt bezüglich der folgenden Hauptaspekte:

Nr.	Finale Aspekte	Erfüllt	Mit Vorbehalt	Nicht erfüllt
01	Brauchbarkeit
02	Schnittstellen
03	Robustheit
04	Performance
05	Konfigurierbarkeit
06	Laufzeit
07	Wartbarkeit
08	Ausbaufähigkeit

Prüfelemente und Aspekte

Applikatorischer Funktionsumfang (Brauchbarkeit, Vollständigkeit)

Nr.	Checkpunkt	Beschreibung	erfüllt?	Nicht benötigt
Ja	mit Vorbehalt	Nein
01	Funktionsbezogene Hauptziel gemäss Offerte
02	Funktionen	Funktionen
03	Vollständigkeit Bausteine	Sind die Bausteine vollständig um den Betrieb zu gewährleisten? (Menge an Bausteinen)
04	Vollständigkeit Module	Sind die Module vollständig um den Betrieb zu gewährleisten? (Menge an Modulen)
05	Abnahme Bausteine	Haben genügend Bausteine den Gesamtstatus 4 um den Betrieb zu gewährleisten?
06	Abnahme Module	Haben genügend Module den Gesamtstatus 4 um den Betrieb zu gewährleisten?
07
08	Abräumen des alten Systems/Produktes	Wurde das alte System vollständig aus dem Betrieb genommen? Was muss allenfalls noch weiter gepflegt werden?

Nicht funktionale Anforderungen

Da dieses „nur“ eine Applikations- respektive Systemabnahme ist, beziehen sich die folgenden „nicht funktionalen Anforderungen“ nur auf das Softwaresystem und nicht auf den Betrieb der Applikation. Dieser wurde in der Betriebsabnahme geprüft.

Nr.	Checkpunkt	Beschreibung	erfüllt?	Nicht benötigt
Ja	mit Vorbehalt	Nein
01	Brauchbarkeit	Entspricht die Applikation den Wünschen und Vorstellungen der Benutzer? Bedienbarkeit
02	Schnittstellen	Funktionieren die Zusammenarbeit von voneinander unabhängiger Komponenten
03	Robustheit	Ist das System robust? Hat die neue Infrastruktur eine adäquate Ausfallsicherheit? Wurden notwendige Redundanzen geschaffen.
04	Performance	Ist die Performance aus applikatorischer Sicht akzeptabel?
05	Konfigurierbarkeit	Kann das System auf die Kundenbedürfnisse konfiguriert werden?
06	Laufzeit	Ist die Laufzeit des Systems/Produktes gut?
07	Wartbarkeit	Ist das System einfach zu warten?
08	Ausbaufähigkeit	Ist das System ausbaufähig.
09	Verfügbarkeit	Ist Systemverfügbarkeit aus applikatorischer Sicht gemäss den Vereinbarungen,

Ergänzungen

Nr.	Checkpunkt	Beschreibung	erfüllt?	Nicht benötigt
Ja	mit Vorbehalt	Nein
01
02

Mängel

Mängelliste

Thematik	Sequenz / Dokument / Kapitel	Beschreibung	Kategorisierung	Erledigungsdatum	Bemerkungen

Weiteres Vorgehen, Installationskontrolle

Installation, Installationskontrolle

Mit dieser Freigabe wird die Software dem Betrieb übergeben. Das detaillierte weitere Vorgehen für die Inbetriebnahme und die Installationskontrolle wurden bereits vorgenommen.

Informationen, Erkenntnisse aus den Tests für den Betrieb

-

Überführen der Mängel und Restanzen in den Change-Management-Prozess

Die aufgeführten Mängel und Restanzen wurden ausführlich dokumentiert und der Entwicklungsfirma übermittelt. Für Neuanforderungen, die nicht im Kapitel 3 aufgeführt und terminiert sind, werden auf vordefiniertem Weg via Releasemanagement separate Aufträge erteilt.