Allgemein prüft der Auftraggeber bei der Abnahme von Individualsoftware auf Basis der bestehenden Vertragswerke (Projektvertrag, Pflichtenheft, Anforderungsliste), ob die entwickelte Software die spezifizierten Anforderungen auch vollumfänglich erfüllt. Im positiven Fall kann die Individualsoftware anschließend abgenommen werden. Zu diesem Zweck werden auf Basis der zwischen Auftraggeber und Auftragnehmer existierenden Vertragswerke die Abnahmetestfälle entwickelt. Der Test der funktionalen und nicht funktionalen Anforderungen aus der Anforderungsliste wird hierbei realisiert, indem für jede verifizierbar formulierte Systemanforderung mindestens ein positiver und ein negativer Testfall textuell mit entsprechendem Eingabe- und Ausgabeverhalten sowie den relevanten Vor- und Nachbedingungen beschrieben wird.

Auf Basis der Rollen- und Aktivitätenmatrix können explizite Arbeitsaufträge für einzelne Projektmitarbeiter erstellt werden. Jeder Arbeitsauftrag sollte sich auch im ganzheitlichen Projektplan auf der untersten Ebene wiederfinden, idealerweise ist der Titel eines Arbeitsauftrages mit dem Titel einer Aufgabe im Projektplan samt Gliederungsnummer identisch. Das erleichtert später die Zuordnung einzelner Aufträge.

Der Projektmanager erklärt dem Auftraggeber die Bereitstellung zur Abnahme des definierten Liefergegenstands. Da der Auftraggeber die Abnahme auch seinerseits vorbereiten muss, wird häufig vertraglich vereinbart, die Bereitstellung zur Abnahme mit einem gewissen Vorlauf schriftlich anzukündigen. Die Einhaltung dieser Vorgaben kann von großer Bedeutung sein, denn haben Sie die Anmeldung versäumt, so können Sie einen möglicherweise gesetzten Termin nicht mehr halten.

Sofern sich Änderungsbedarfe ergeben, bedingt dies möglicherweise die Auslösung eines „Change Request“ (CR). Ist die Änderung umfassender, betrifft sie weitere Knowledge Areas oder verändert sie Umfang, Zeit oder Kosten, so ist in jedem Fall ein Change Request gemäß der im Projektmanagementplan vereinbarten Vorgehensweise aufzusetzen. Je nach aufrufendem Prozess wird der Change Request vom Urheber erfasst; das kann z.B. der Anforderungs- oder der Qualitätsmanager sein.

Der Projektmanager involviert auf Basis des Projektauftrags sämtliche Projektbeteiligten, die im Einführungsprozess eine relevante Rolle spielen bzw. innehaben. Als Ergebnis wird der Einführungsplan erstellt.

In dieser Aktivität werden durch einen sogenannten Komponentenschnitt die Softwarekomponenten des zu entwickelnden Softwareprodukts bestimmt. Dazu wird das Spezifikationsdokument benötigt. Die Identifizierung der Softwarekomponenten erfolgt somit auf fachlicher Ebene, um die Softwarekomponenten anschließend auf technischer Ebene entwerfen zu können. Darüber hinaus sind solche Softwarekomponenten auf technischer Ebene zu identifizieren, die keinen fachlichen Ursprung haben und somit in der Regel Querschnittsaufgaben übernehmen. Die Gliederung ist hierbei so vorzunehmen, dass fachlich zusammenhängende Klassen des UML-Klassenmodells aus der Spezifikation formal zusammengefasst werden. Die Zuordnung von Klassen zu realisierenden Komponenten im Komponentenschnitt ist vom Softwarearchitekten mithilfe eines bzw. mehrerer UML-Paketdiagramme durchzuführen.

Gefundene Fehler werden dokumentiert und in Kategorien eingestuft. Um von vornherein nur Meldungen aufzunehmen, die tatsächlich Fehler sind und keine Änderungsanforderungen, sollte der gesamte Test vom Testmanager koordiniert werden

Verschiedene Faktoren können dazu führen, dass ein Projektmitglied aus dem Projekt genommen werden muss, es also „ausgeplant“ wird: In jedem Fall sollte die Arbeit des Mitarbeiters mit ihm bewertet werden. Das kann im Rahmen eines Gespräches geschehen oder – bei größeren Projekten – gemeinsam mit dem Linienvorgesetzten des Mitarbeiters. Je nach Organisationsform können die Ergebnisse auch schriftlich festgehalten werden.

Die Zusammenstellung von Teams kann auf der Basis von Projektrollen, die im Projektplan beschrieben sind, erfolgen. Der Projektmanager stützt sich dabei auf die in den vorangegangenen Aktivitäten erstellte Anforderungsliste und auf die im Projektplan festgehaltenen Arbeitskalender, Verfügbarkeiten sowie die Rollen- und Aktivitätenmatrix. Er ordnet die Mitarbeiter dann gemäß seiner Einschätzung ihrer Kenntnisse, Fähigkeiten und Präferenzen den jeweiligen Rollen zu. Zwischen den Teamrollen nach Belbin und den Projektrollen gibt es Berührungspunkte, die Sie nutzen können, um eine bestmögliche Teambildung und Rollenbesetzung für Ihr Projekt zu erzielen.

In der Projekt-/Teamrollenmatrix aus der PITPM-Vorlage können Sie in der letzten Spalte die Namen der am besten geeigneten Mitarbeiter hinzufügen.

Daraus abgleitet ermitteln Sie die Release-Notes, die im Detail beschreiben,

• welche Anforderungen umgesetzt wurden,
• welche Anforderungen geplant waren, aber nicht umgesetzt wurden,
• welche bekannten Fehler das Deployment noch hat.

Ihr Ziel ist, ihren Auftraggeber umfänglich und ehrlich über die Leistung der Iteration in Kenntnis zu setzen.

Im Testdokument wird festgehalten,

• wann welche Tests
• von welchen Artefakten des Softwareprodukts
• von welchem Tester und
• mit welchem Ergebnis durchgeführt wurden.

Anschließend wird bewertet, ob der Test erfolgreich oder fehlerhaft war. Es wird außerdem betrachtet, welche Fehler zu einem gege-benen Zeitpunkt noch in welcher Softwarekomponente vorhanden waren.

Das Ergebnis einer Iteration der Softwareentwicklung wird einer eingehenden Überprüfung im Rahmen von Testmaßnahmen unterzogen. Die Durchführung des Tests orientiert sich organisatorisch an den Rahmenbedingungen aus dem Testplan und wird jeweils von einem oder ggf. mehreren Testern durchgeführt und protokolliert.