Advertisement

HMD Praxis der Wirtschaftsinformatik

, Volume 53, Issue 2, pp 153–168 | Cite as

Qualität in der Softwareentwicklung

  • Wolfgang Osterhage
Article
  • 668 Downloads

Zusammenfassung

Für Entwicklung und Einsatz von Quality Management in der Softwareentwicklung stehen bekanntlich sich wandelnde Methodologien unterschiedlicher Ausprägung aus unterschiedlichen Beratungs- oder Lehrstuhlkulturen zur Verfügung, um solche Aufgaben zu unterstützen. Es ist ebenso offensichtlich, dass auf Grund unterschiedlicher Organisationsstände in den Unternehmen die Stringenz zu Gunsten pragmatischer Ansätze leiden muss.

Schlüsselwörter

Abnahme Test Anforderungsmanagement Change Management Fehlermanagement 

xxx

1 Normative Verweisungen und Methodologien

Neben den allgemeingültigen Qualitätsnormen der DIN-ISO-Familie (9000 ff.) soll an dieser Stelle hingewiesen sein auf die Standards des Bundesamts für Sicherheit in der Informationstechnik (BSI). Obwohl der Schwerpunkt des IT Grundschutzkatalogs auf Fragen der IT-Sicherheit liegt, finden sich wertvolle Hinweise unter G 2.26 „Fehlendes oder unzureichendes Test- und Freigabeverfahren“ sowie unter S 2.83 „Testen von Standardsoftware“.

Für die Einführung komplexer Systeme wird normalerweise ein eigenes Projekt aufgesetzt, bzw. die Struktur eines schon vorhandenen Projektes genutzt. Es gibt nun eine Reihe von Methodologien, in die auch die Abnahmeverfahren eingebettet werden können. Dazu gehören z. B. CMMI (Capability Maturity Model Integration) und SPICE (Software Process and Capability Determination).
  • CMMI dient zur Beurteilung und Verbesserung der Qualität im Produktentwicklungsprozess, ist also der eigentlichen Qualitätsprüfung aus Kundensicht vorgeschaltet, deckt allerdings auch Teile der Vorlaufstrecke wie z. B. Anforderungsmanagement ab.

  • Bei SPICE handelt es sich um eine echte Norm (ISO/IEC 15504), die zunächst allgemein Unternehmensprozesse bewertet, deren Schwerpunkt aber auf der Softwareentwicklung liegt. Ein Teil davon beschäftigt sich auch mit Kunden-/Lieferantenprozessen.

Neben diesen mittlerweile klassischen Methodologien zeigt sich allerdings in der Praxis, dass häufig nur Versatzstücke davon zum Einsatz kommen. Das liegt an den gewachsenen Strukturen und Prozessen in Unternehmen. Eine Komplettumstellung vor Projektstart erweist sich häufig als schwierig wegen der damit verbundenen Kosten und Zeitaufwände. In einer praxisorientierten Vorgehensweise kann es durchaus vorkommen, dass Elemente aus dem einen oder anderen Regelwerk erscheinen.

2 Qualitätsmanagement als Projekt

Grundsätzlich ist zu unterscheiden zwischen der Linienfunktion „IT-Quality Management“ und einem Qualitätsmanagementprojekt. Abnahmen neuer Software oder neuer Releases oder Teile daraus haben typischen Projektcharakter.

Zudem besteht die Möglichkeit, dass Abnahmen als Teilprojekt in einem größeren Projektzusammenhang von z. B. Restrukturierungsmaßnahmen stehen können. Die Leitung eines solchen Projektes bzw. Teilprojektes wird in die Hand der Organisationseinheit „IT Quality Management“ gelegt. IT Quality Management umgreift allerdings mehr als nur das reine Bewerten der Qualität z. B. eines Softwareproduktes, sondern schließt alle Elemente der Vor- und Nachlaufstrecken ein.

In den folgenden Ausführungen wird davon ausgegangen, dass die Entwicklungsorganisation des Softwarelieferanten ein eigenes Qualitätswesen unterhält. Dieses Qualitätswesen sorgt dafür, dass nur qualitätsgesicherte Softwarekomponenten zur Auslieferung an den Kunden gelangen. Das bedeutet
  • durch Entwickler getestete und

  • eindeutig versionierte, durch den Kunden beauftragte Module.

Als Pendant dazu wird auf der Kundenseite eine Kompetenz geschaffen, die ihrerseits sicherstellt, dass „geliefert wird, wie bestellt worden ist“. Ähnlich wie bei einem Wareneingang werden also Bestellung und Lieferung miteinander abgeglichen und eventuelle Mängel festgehalten bzw. deren Nachbesserung eingefordert. Grundlage der Bestellung sind gemeinsam vereinbarte Lastenhefte. Während die interne Qualitätssicherung des Lieferanten für ihre Belange eine Art „Werksabnahme“ durchführt, nimmt das kundenseitige Qualitätsmanagement die ausgelieferte Software ab mit dem Ziel einer qualitätsgesicherten, unmittelbar auf den Abnahmeprozess folgenden Inbetriebnahme.

Im gesamten Prozess der Qualitätssicherung zu berücksichtigen sind die Schritte (Abb. 1)
  • Anforderungsmanagement,

  • Change Management (Abb. 2),

  • Fehlermanagement,

  • Qualitätsmanagement als solches,

  • Migrationsmanagement,

  • Dokumentation,

  • Betrieb und

  • Datenbereinigung.

Abb. 1

Aufgaben aus Sicht der Projektleitung

Abb. 2

Change-Managment

Zum Qualitätsmanagement wiederum gehören:
  • die Abnahmekoordination,

  • die Betriebsbereitschaftsprüfung und evtl.

  • der Probebetrieb.

2.1 Anforderungsmanagement

Das Anforderungsmanagement bündelt möglichst alle Anforderungen zu einem zu realisierenden oder zu erweiternden Softwarepaket innerhalb eines Einführungsprojektes. Diese Anforderungen können aus unterschiedlichen Quellen kommen:
  • Beschreibung des Leistungsumfanges des gesamten Paketes oder wesentlicher Teile (Module) daraus. Dabei kann es sich um Workshop-Ergebnisse handeln oder auch um komplette Prozessbeschreibungen der relevanten Geschäftsvorfälle in einem Unternehmen.

  • Wünsche aus dem Benutzerumfeld nach neuen Funktionalitäten.

  • Wünsche aus dem Benutzerumfeld nach spezifischen Funktionserweiterungen.

  • Erkenntnisse und Vorschläge des Lieferanten zur Arbeitserleichterung mit seinem System.

  • Technische Erfordernisse aus dem Umgang mit der vorhandenen Software.

Das Anforderungsmanagement sammelt all diese Anforderungen. Sie können sporadisch einlaufen oder aufgrund von Workshop-Abstimmungen zur Vorbereitung eines größeren Updates oder eines kompletten Releases entstehen. Bewährt hat sich die strukturierte Zusammenfassung aller Anforderungen in einer Datenbank mit entsprechender Statusverfolgung.

Bevor konkrete Anforderungen weiterverfolgt werden können, sollten sie in Form von Lastenheften formuliert worden sein. Erst nach Vorliegen eines Lastenheftes kann eine erste Aufwandsschätzung erfolgen.

Nach der Beauftragung kann der Lieferant das korrespondierende Pflichtenheft erstellen. Während das Lastenheft den Funktionsinhalt abdeckt („Was“), beschäftigt sich das Pflichtenheft mit der Art der technischen Umsetzung („Wie“). Damit ergeben sich zwei zusätzliche Statusinformationen für Anforderungen:
  • Lastenheft vorhanden und abgenommen,

  • Pflichtenheft vorhanden und abgenommen.

Die jeweiligen Abnahmen sollten durch Vertreter des Fachbereichs des Kunden erfolgen.

Um das der Realisierung nachfolgende Abnahmegeschehen handhabbar zu gestalten, sollten Einzelanforderungen gesammelt werden und zu einem festgesetzten Meilenstein als Release bzw. Teilrelease (Version) zusammengefasst und gemeinsam zur Abnahme bereitgestellt werden. Dieses Prinzip lässt sich nicht immer durchhalten. Aufgrund von Dringlichkeiten, die technisch-inhaltlicher Art und auch von außerhalb des Projektes beeinflusst sein können, besteht immer die Möglichkeit von zwischenzeitlichen Sonderauslieferungen einzelner Funktionalitäten. Grundsätzlich jedoch sollte das Anforderungsmanagement zusammen mit dem Lieferanten einen verbindlichen Release-Plan erstellen mit vereinbartem Horizont und mit den Releases als Meilensteine auf der Zeitachse.

2.2 Change-Management

Unterhalb der Organisation des eigentlichen Anforderungsmanagements wird häufig das sog. Change-Management (Abb. 2) angesiedelt.

Aufgrund von Erkenntnissen im Umgang mit im Betrieb befindlicher Software kommt es häufig zu sog. Change Requests, also Einzelanforderungen, die Änderungen an vorhandenen Funktionalitäten verlangen. Dabei kann es sich um eine Reduzierung des bestehenden Funktionsumfanges handeln, weil z. B. das Geschäftsfeld sich vereinfacht hat. Oder es geht um Modifikationen z. B. auf Grund von Prozessänderungen. Die Verursacher für solche Change Requests finden sich
  • im Benutzerumfeld oder

  • in der Entwicklungsabteilung des Lieferanten.

Bevor solche Anfragen in die Datenbank des Anforderungsmanagements zur Weiterverfolgung eingestellt werden, wird eine sorgfältige Aufwands-/Risikobetrachtung durchgeführt, wobei sich das Risiko auf systemtechnische und fachliche Gegebenheiten bezieht, aber auch Budgetrisiken berücksichtigt werden müssen. Unstrittig sind sicherlich solche Anforderungen, die für das korrekte Funktionieren des Geschäftsprozesses inklusive des technischen Funktionierens des Systems von Bedeutung sind. Nicht immer werden bei der ursprünglichen Lastenhefterstellung alle Konsequenzen im Voraus durchdacht, und prozessuale Inkonsistenzen werden erst bei der intensiven Nutzung des umgesetzten Produktes sichtbar.

Die Behandlung der Change Requests folgt den gleichen Richtlinien wie den übrigen Anforderungen innerhalb des Anforderungsmanagements. Aufgrund von unterschiedlichen Priorisierungen kann es aber häufiger zu Realisierungen und Inbetriebnahmen zwischen den längerfristig geplanten Release-Meilensteinen kommen.

2.3 Fehlermanagement

Softwarefehler werden in unterschiedlichen Konstellationen erkannt und weitergemeldet:
  • bei der Nutzung der Anwendung im Tagesbetrieb durch die Benutzer,

  • bei Weiterentwicklungen im Projekt, die auf schon vorhandene Funktionalitäten aufsetzen und

  • bei den Abnahmen vor der Inbetriebnahme, d. h. im Zuge der eigentlichen Qualitätssicherung.

Abb. 3 zeigt den prinzipiellen Verfahrensweg nach der Fehlererkenntnis.
Abb. 3

Fehlermanagement

Mit Ausnahme der während einer Abnahme erkannten Fehler durchlaufen alle anderen eine Supportschleife, die normalerweise mit der Aktivierung einer Hotline (Service Desk) beginnt. Der 2nd Level Support greift erst, wenn der Service Desk nicht in der Lage ist, einen nutzbaren Beitrag zur Fehlerbehebung zu leisten. Dabei muss bedacht werden, dass sich häufig vom Enduser als Fehler gemeldete Probleme später als Bedienungsfehler herausstellen; hier sollen nur echte Softwarefehler behandelt werden. Die Rückmeldung der technischen Instanzen soll hier nicht weiter verfolgt werden.

Alle Korrekturen, die auf Grund von Fehlermeldungen vorgenommen werden und zur Auslieferung kommen, unterliegen – ähnlich den Bereitstellungen aus dem Change-Management oder den übrigen Abnahmegegenständen – dem gleichen Abnahmeprozedere, wenn auch möglicherweise in verkürzter Form. Die folgende Abb. 4 differenziert noch einmal nach Fehlertypen und zugehörigem Bereinigungsprozess:
Abb. 4

Fehlerdifferenzierung

Was subjektiv als Fehler erscheint, kann auf verschiedene Ursachen zurückzuführen sein:
  • echte Softwarefehler, die bei der Umsetzung vom Pflichtenheft auf den Code zustande gekommen sind,

  • korrekt realisierte Anforderungen, die aber in der Anwendung zu fachlich falschen Ergebnissen führen (Algorithmen, Plausibilitätsprüfungen etc.),

  • Datenfehler, die z. B. durch Übernahme von Daten aus anderen, vernetzten Systemen entstehen können; hier gibt es eine Vielfalt von Typisierungen, die an dieser Stelle nicht weiter behandelt werden.

Je nach Fehlertypus durchläuft der Korrekturprozess dann eine eigene Schleife:
  • Fehlerbereinigung wie oben beschrieben,

  • als Change Requests zur Erzeugung einer modifizierten oder neuen Anforderung oder

  • Weitergabe an das Teilprojekt, das sich mit Datenbereinigung befasst.

3 Ziele des Softwarequalitätsmanagements

Ganz allgemein dient das kundenseitige Qualitätsmanagement bei der Einführung komplexer IT-Systeme der Sicherstellung einer hohen Qualität der realisierten Software inklusive der Schnittstellen vor der Auslieferung zur Inbetriebnahme. Alle Industrienormen, die dazu entwickelt wurden, und die teilweise oder in ihrer Gänze dafür relevant sind, finden dabei ihre Berücksichtigung. Deren Einhaltung ist jedoch kein Ziel in sich selbst, sondern folgt einer Interessenlage und damit wirtschaftlichen Überlegungen, der die Einhaltung solcher Vorschriften entgegen kommen. Insofern lassen sich die folgenden allgemeinen Ziele konkretisieren.

3.1 Vermeidung von langen Pilotbetrieben

Dieses Teilziel selbst orientiert sich an Aufwandsreduzierung (Kosten) und Engpassbeseitigung (Meilenstein bezogen). Software wird häufig unter hohem zeitlichem Druck entwickelt. Gründe dafür liegen in der Vorgabe, dass bestimmte Geschäftsvorfälle zügig und konkurrenzfähig am Markt zum Einsatz kommen müssen. Von dem auf diese Weise vorgegebenen Meilenstein wird sodann rückwärts terminiert, um den Start der Inbetriebnahme und damit des Endwicklungsbeginns und anderer Elemente der Vorlaufstrecke (Lastenheft, Pflichtenheft) zu ermitteln. Da jedoch nur endliche Entwicklungskapazität zur Verfügung steht, entsteht jener Zeitdruck fast zwangsläufig.

Eine Möglichkeit der Reduzierung auf der Zeitskala besteht eben nun im Vermeiden langer Pilotbetriebszeiträume. Pilotbetrieb meint hier die Simulation des Echtbetriebes auf einem möglichst gespiegelten Abnahmesystem mit einem Komplettabzug der Echtdaten entweder vor (besser) Inbetriebnahme der Software oder parallel dazu. Ein Pilotbetrieb benötigt bis zur endgültigen Freigabe nicht nur Kalenderzeit, sondern bindet auch in hohem Masse Entwicklungs-, Qualitäts- und ganz besonders Enduser-Ressourcen.

Einen entscheidenden Beitrag, Zeiten und Ressourcen zu optimieren, leistet das Qualitätsmanagement, indem es dafür sorgt, möglichst fehlerfreie Software in den Pilotbetrieb zu geben, sofern er dann noch für notwendig erachtet wird. Im Idealfalle sollte der Abnahmeprozess ausreichen, um den Pilotbetrieb gänzlich fortfallen zu lassen.

3.2 Vermeidung von Produktionsausfällen

Mit oder ohne Pilotbetrieb geht es bei diesem Teilziel um die Abwendung von Konsequenzen aus der Inbetriebnahme einer unzureichend getesteten Software. Nicht immer sind komplette Systemausfälle erforderlich, um das Tagesgeschäft zum Erliegen zu bringen. Falsche Bildschirmsteuerung z. B., systematische Datenfehler aus Schnittstellenübertragungen oder ein kritischer Umrechnungsalgorithmus reichen aus, um das Arbeitsgebiet eines einzelnen Sachbearbeiters zu blockieren. Und gerade solche Fehler fallen häufig beim Entwicklertest nicht auf.

Eine saubere Auswahl des Testdatenbettes sowie sorgfältige und vollständige Entwicklung von Testskripten sorgen für die Prüfung einer maximal denkbaren Variantenzahl für einen Geschäftsvorfall. Wie überall gilt hier ganz besonders: Die Arbeit muss ohnehin getan werden. Was im Vorfeld an Aufwand nicht geleistet wird, kostet im Nachhinein ein Vielfaches davon.

3.3 Sofortige Korrektur von Mängeln

Die Ausführungen zum Fehlermanagement zeigen auf, dass die Schleife der Fehlererkennung und -korrektur im Zuge der Abnahme durch das Qualitätsmanagement die kostengünstigste und beherrschbarste ist. Sowohl die Identifikation als auch die Steuerung der einzuleitenden Maßnahmen aus einer Fehlererkennung aus dem Betrieb heraus sind kommunikationsaufwendig. Dem gegenüber erfolgt die Fehlererkennung während einer Abnahme durch Projektfachleute, die meistens auch an der Abfassung der Lastenhefte mitgewirkt haben. Häufig haben diese Spezialisten auch den direkten Draht zu den zugehörigen Entwicklern, sodass inhaltliche Klärungen rasch erfolgen können.

Besonders hilfreich ist der für eine Abnahme im Vorhinein festgelegte Patch-Prozess, der praktisch eine unmittelbare Fehlerkorrektur (mit geringen zeitlichen Einschränkungen für den Testbetrieb) durch einen Hotfix oder Ähnliches ermöglicht. Dem kann dann sofort die Nachabnahme dieser Korrektur folgen.

Software-Korrekturen, die aus Erkenntnissen aus dem Betrieb selbst heraus erfolgen, unterliegen dagegen dem Planungsprozess von Updates. Eine zeitnahe Umsetzung ist deshalb nur in Ausnahmefällen, z. B. bei extremen Störungen, machbar – mit allen Unwägbarkeiten für den laufenden Betrieb durch das Einspielen und dann Anwenden von unerprobten Änderungen. Bei Änderungen am Datenmodell sind längere Ausfallzeiten des Regelbetriebes unvermeidlich.

3.4 Vermeidung von Dateninkonsistenzen

Beim Zusammenschalten von unterschiedlichen Systemen, die jedes für sich konkrete Geschäftsbereiche eines Unternehmens abdecken und dabei aus Notwendigkeit oder Rationalisierungsgründen Daten austauschen oder auf eine gemeinsame Datenbasis zugreifen müssen, stellt sich das Problem der Datenkonsistenz. Bei komplett neu entwickelten Systemen sollte es gering sein oder überhaupt nicht auftreten. Es potenziert sich allerdings, wenn ein oder mehrere Altsysteme in den Verbund treten, da jedes System – und damit die zugehörigen Datentöpfe – eine eigene Geschichte haben.

Unabdingbar bleibt also ein sorgfältig vorbereiteter Schnittstellentest möglichst mit realen Daten, bei dem nicht nur die Schnittstellenfunktionalität sichergestellt wird, sondern auch die Datenqualität im Sinne von Konsistenz bzw. Rückweisungsquoten. Datenbereinigungsprojekte, die im Ernstfall später auf Produktionsdatenbestände angewendet werden müssen, weil im Vorfeld keine ausreichende Prüfung geschah, sind enorm kostenintensiv und dauern sehr lange. Fast immer laufen solche Maßnahmen dem sich während des Betriebs ständig neu wandelndem Bestand hinterher. Extrem teuer kann es werden, wenn Daten betroffen sind, die nach außen sichtbar werden, wie z. B. Kundenrechnungen im Massengeschäft.

4 Verantwortlichkeiten für das Softwarequalitätsmanagement

Grob umschrieben liegt die Hauptverantwortlichkeit des Qualitätsmanagements auf der Planung und Durchführung von Abnahmetests vor Auslieferung einer Software oder von Schnittstellen zur Inbetriebnahme. Sämtliche anderen Verantwortlichkeiten sind entweder peripher oder haben Regelcharakter. In letzteren Fällen wirken sie in vor und nach geschaltete Prozesse hinein. Erleichtert wird die Wahrnehmung der Gesamtverantwortlichkeiten des Qualitätsmanagements durch die Verabschiedung einer Abnahmespezifikation mit allgemeiner Gültigkeit innerhalb eines Einführungsprojektes.

Abweichungen werden als Fehler dokumentiert, bevor über eine Zurückweisung der Auslieferung oder Teilen davon entschieden wird.

Die Verantwortlichkeiten im Einzelnen gliedern sich in folgende Schritte:
  • Identifikation von Testanforderungen,

  • Festlegen personeller Zuständigkeiten für den Abnahmeprozess,

  • Koordination von Testskripten und Testdaten,

  • Gesamtplanung der Abnahmen zusammen mit dem Lieferanten,

  • Durchführung der Abnahmen und

  • Abschlussbewertung mit Empfehlung.

4.1 Identifikation von Testanforderungen

Je nach Abnahmegegenstand
  • Release,

  • Sonderfunktionen/einzelne Change Requests,

  • Fehlerkorrektur,

  • Datenmigration,

gibt es unterschiedliche Anforderungen an einen Abnahmetest. Die Anforderungen gliedern sich zunächst nach den erforderlichen Ressourcen:
  • Hardware und Systemumgebung,

  • Testpersonal aus dem Benutzerumfeld mit entsprechenden Freistellungsvereinbarungen durch die Fachbereichsverantwortlichen für den Testzeitraum, Spezialisten aus dem Einführungsprojekt, die an der Erstellung von Lastenheften beteiligt waren, und Support vom Lieferanten – meistens Entwickler, die an der Realisierung beteiligt waren,

  • Zuordnung von abzunehmenden Funktionalitäten zu Spezialisten, die in der Lage sind, Testskripte dafür zu erstellen,

  • Identifikation und Anforderung von Testdaten, insbesondere die Grundentscheidung, ob mit realen und/oder synthetischen Daten getestet werden soll,

  • Anforderung von Schnittstellen, deren Input/Output für bestimmte Funktionsnachweise erforderlich sind, unter Umständen auch Schnittstellensimulationen z. B. über Logfiles.

4.2 Festlegen personeller Zuständigkeiten für den Abnahmeprozess

Nach der grundsätzlichen Identifikation der Personalressourcen müssen nunmehr die Einzelaufgaben mit Namen hinterlegt werden. Sofern diese Dokumente noch nicht vorliegen, müssen Autoren für Lastenhefte und Co-Autoren für Pflichtenhefte (mit dem Lieferanten zusammen) benannt werden. Innerhalb eines Projektes kann man jedoch erwarten, dass solche Dokumente vor dem Beginn der eigentlichen Abnahme vorliegen und freigegeben sind.

Der Lieferant sollte aufgefordert werden, für den Abnahmezeitraum Entwicklungsressourcen für die entsprechenden Funktionalitäten zumindest im Standby- Modus bereitzustellen. Außerdem ist die Beteiligung der lieferanteninternen Qualitätssicherung erforderlich, sollten während des Abnahmezeitraums Fehler-Patches oder Hotfixes eingespielt werden müssen.

Je nach Zuständigkeit müssen Systemspezialisten für den Betrieb der Testumgebung benannt und eingeplant werden.

Sofern nicht über die eigentliche Struktur des Einführungsprojektes bereits festgelegt, müssen Eskalationspfade und -instanzen nominiert werden – und das aus drei Gründen:
  • um Entscheidungen im Konfliktfall bzgl. der Klassifizierung von Fehlern zu treffen,

  • um den Abbruch oder die Weiterführung einer Abnahme zu regeln, sollten schwerwiegende Störungen auftreten (Systemprobleme, Softwarestillstand, Engpässe bei personellen Ressourcen etc.) und

  • als Adresse für den Abnahmebericht.

4.3 Koordianation von Testskripten und Testdaten

Testskripte orientieren sich an drei Quellen:
  • Lastenheft,

  • Pflichtenheft,

  • Geschäftsprozess.

Alle drei hängen voneinander ab. Man sollte annehmen, dass Lastenhefte auf Basis dokumentierter Geschäftsprozesse erstellt werden. Diese wiederum sind Grundlage für die von den Entwicklern zu erstellenden Pflichtenhefte. Nur, wenn diese Voraussetzungen gegeben sind, können Testskripte letztendlich auf der alleinigen Basis von Geschäftsvorfällen entwickelt werden. Leider finden sich in den wenigsten Unternehmen vollständig und aktuell dokumentierte Geschäftsprozesse. Für Einzelfunktionen, deren Entwicklung möglicherweise auch noch aus Adhoc-Erkenntnissen über die Nutzung der vorhandenen Software getrieben wird, ist das noch weniger der Fall. Man muss deshalb von einer ziemlich heterogenen Dokumentenhistorie ausgehen, wenn dann unter Zeitdruck plötzlich Abnahmen erfolgen sollen.

Auf keinen Fall sollte sich der Kunde damit begnügen, die Testskripte aus den Entwicklungstests des Lieferanten zu übernehmen, da diese meistens rein technisch ausgelegt sind und den Geschäftsprozess häufig nicht im Blick haben. Wichtig ist an dieser Stelle, festzuhalten, dass auf der Verrichtungsebene getestet werden muss. Diese folgt der Hierarchie in Abb. 5.
Abb. 5

Prozesshierarchie

Bei der Abb. 5 handelt es sich um ein Grundsatzschema. Je nach Komplexität des Hauptprozesses kann die Hierarchisierung ausgeprägter oder flacher sein. Entscheidend ist die unterste Ebene der Arbeitsanweisung (Verrichtungsebene), an der sich die Testskripte zu orientieren haben.

Bei der Festlegung von Testdaten werden naturgemäß die Erfordernisse der Testskripte berücksichtigt – insbesondere, was die Kombinatorik der Datenfeldvarianten betrifft. Daraus leiten sich die inhaltlichen Anforderungen ab. Zum einen muss abgeprüft werden, ob sich diese durch einen Auszug aus der Produktivdatenbank abdecken lassen. In diesem Falle wird zu entscheiden sein, ob partielle Auszüge ausreichen, oder ob die Produktivdatenbank komplett abgebildet werden muss. Zu beachten sind hier möglicherweise die Kapazitätsgrenzen des Testsystems und die zu erwartende Performance bei großen Datenmengen.

Wenn es sich bei den abzunehmenden Funktionalitäten darum handelt, auch neue Daten zu erzeugen oder neue Algorithmen zu prüfen, reichen reale Daten oft nicht aus. In diesem Falle müssen synthetische Daten angelegt werden – oftmals in einer leeren Datenbank. Wenn solche Anforderungen über einige Dutzend Datensätze hinausgehen, muss man den Aufwand einplanen, der für den Aufbau komplexer und zahlreicher synthetischer Daten anfällt. Wenn möglich, sollte man große Mengen von synthetischen Daten über eigens geschriebene Programme generieren.

4.4 Durchführung der Abnahmen

Bei dieser Kernverantwortlichkeit ist die Akzeptanz bei allen Beteiligten – Fachbereich, Projekt, Lieferant – wichtig. Dazu gehört eine entsprechende Rückendeckung durch die Gesamtprojektleitung und eine damit einhergehende Vorabkommunikation. Neben diesen Flankierungen sollte der verantwortliche Funktionsträger fachlich und sozial anerkannt sein, Durchsetzungsvermögen besitzen, sowie diplomatisches Geschick zur Herbeiführung von Kompromissen haben.

5 Grundsätze des Abnahmeverfahrens

5.1 Bereitstellungstermine

Es werden drei unterschiedliche Bereitstellungstermine unterschieden:
  • BzT = Bereitstellung zum Test.

    Damit ist der Zeitpunkt nach dem vorläufigen Abschluss der Entwicklungsarbeiten gemeint. Die Entwickler übergeben ihre Ergebnisse der internen Qualitätssicherung des Lieferanten. Dazu gehören technische Testskripte, die die Software auf rein funktionale Eigenschaften prüfen. Die Software befindet sich entweder auf den individuellen Entwicklungssystemen oder einem eigens für die interne (Werks-)Abnahme eingerichteten Stand. Getestet wird auf Basis synthetischer Daten. Eine Teilnahme des Kunden ist formell nicht vorgesehen, kann aber aus praktischen Gründen sinnvoll sein. Wenn schon funktionale Fehler im Vorfeld bekannt werden, brauchen später Geschäftsvorfälle gar nicht erst in Angriff genommen zu werden. Der BzT-Termin ist ziemlich entkoppelt vom restlichen Geschehen, außer dass er unbedingt vor den beiden Folgeterminen zu liegen hat.

  • BzA = Bereitstellung zur Abnahme.

    Dieser Termin ist definitiv der erste Tag der Abnahme unter Beteiligung des Kunden. Es wird erwartet, dass alle Systeme bereit stehen, die Infrastruktur stimmt, die Testskripte vorliegen und Testdaten aufgespielt sind. Das Bereitstellungsprotokoll liegt vor.

  • BzI = Bereitstellung zur Inbetriebnahme.

    Die Abnahme ist erfolgt; der Ergebnisbericht liegt vor. Die neue Software kann in Betrieb gehen. Dazu ist entweder ein Release-Wechsel mit allen Migrationsdetails einzuplanen oder ein Update bereitzustellen. Das Update wird während eines Betriebsstillstands eingespielt und steht anschließend produktiv zur Verfügung.

5.2 Einleitung des Abnahmeverfahrens

Das Abnahmeverfahren selbst beginnt weit vor dem BzA-Termin. Schon bald nach bekannt werden des funktionalen Inhalts eines Abnahmegegenstandes (Prozess: Anforderungsmanagement) sollte das Qualitätsmanagement ein Kick-off einberufen mit allen wesentlich Beteiligten. Hier werden der Status der Spezifikationsdokumente ermittelt, die Grobplanung der Abnahme vorgestellt und Verantwortlichkeiten zugeordnet. Nach Möglichkeit sollte ein Vertreter der Gesamtprojektleitung zugegen sein, um durch sein Gewicht die Bedeutung des Vorhabens zu unterstreichen. Die Ergebnisse des Kick-offs werden protokolliert und als Teil der Abnahmedokumentation archiviert.

5.3 Review-Prozess

Mit dem Beginn der Abnahme, also noch vor dem Ende des ersten Abnahmetages, spätestens jedoch bei Vorliegen erster Abnahmeergebnisse finden möglichst täglich Abnahmereviews unter Beteiligung des gesamten Abnahmeteams statt. Aus dieser Runde heraus wird der Abnahmefortschritt verfolgt und die Abnahme gesteuert. Während des Abschlussreviews wird über den Gesamterfolg der Abnahme entschieden und eine entsprechende Empfehlung ausgesprochen.

5.4 Patch-Prozess

Bereits beim Kick-off sollte mit der Qualitätssicherung des Lieferanten ein auf den Wochentag genauer Zyklus abgestimmt werden, der festlegt, wann eine Softwarekorrektur nach Behebung von Fehlern, die während der Abnahme erkannt werden (Prozess: Fehler-Management), in Form eines Patches eingespielt wird. Die Vorabkenntnis der exakten Termine ist wichtig für die Neueinplanung von Testressourcen im Laufe der Abnahme.

5.5 Nachabnahme

Es macht Sinn, den gesamten für eine Abnahme zur Verfügung stehenden Zeitrahmen aufzuteilen in ein Zeitfenster für die eigentliche Abnahme und ein anschließendes für eventuelle Nachabnahmen – Verhältnis etwa 2:1 auf der Zeitachse. Anzustreben ist der vollständige Abschluss der Abnahme im ersten Zeitfenster, sodass im zweiten Teil nur noch Korrekturen nachgetestet werden müssen. Das ist insofern schwer durchzuhalten, als dass das Abnahmezeitfenster wegen des Zeitdrucks aus der Rückwärtsterminierung vom BzI meistens zu klein dimensioniert wird, sodass in den Nachabnahmezeitraum unweigerlich auch Nachläufer aus der eigentlichen Abnahme einlaufen. Die Zielplanung sollte allerdings zunächst diese Unterscheidung beinhalten.

6 Dokumentation

Zu unterscheiden sind Dokumente, die vor, während und nach dem Projekt erstellt und benötigt werden.

6.1 Abnahmehandbuch

Das Abnahmehandbuch enthält:
  • eine Abnahmerichtlinie,

  • Bereitstellungsprotokoll,

  • Template Testskripte,

  • Akzeptanzkriterien,

  • Fehlerprotokolle,

  • Task-Liste,

  • Ressourcen-Feinplanung,

  • Reviewprotokoll,

  • Problemspeicher,

  • Ideenspeicher und

  • Abnahmeprotokoll.

6.2 Referenzdokumente

Referenzdokumente sind solche, die vor und während einer Abnahme benötigt werden, um ein eindeutiges Abnahmeverständnis zwischen Kunde und Lieferanten herbeizuführen. Es handelt sich dabei um eine Mischung aus technischer und kommerzieller Dokumentation, die teilweise über das Vertragswerk, das der Einführung zu Grunde liegt, referenziert wird.

6.3 Auslieferungsdokumentation

Die mit der Software zu liefernde Dokumentation ist umfänglich im Einführungsvertrag festgeschrieben. Zu dieser Dokumentation gehören normalerweise:
  • Leistungsbeschreibung,

  • Produktionsplan,

  • Bestandsdokument,

  • Inventardokument,

  • Betriebskonzept,

  • Benutzerdokumentation und

  • Customizing-Dokumentation.

Lastenhefte und Pflichtenhefte sollten den letzten Freigabestatus vor Abnahme enthalten.

7 Abschlussbewertung mit Empfehlung

Der Entwicklung einer Software geht eine Beauftragung zur Realisierung voraus, es sei denn, es handelt sich um einen Standard. Ansonsten erfolgt die Beauftragung in Form eines Vertrages, der gleichzeitig Bestellung ist. In diesem Vertrag sind Auslieferungszustand und sonstige Eigenschaften der Software festgeschrieben sowie Zahlungsmodalitäten. Dieser Vertrag ist somit ein Dokument mit juristischer Relevanz.

Die Begleichung der gelieferten Leistung kann unmittelbar mit Bezug zu einem solchen Vertrag erfolgen. Revisionssicherheit erfordert jedoch, dass diese Leistungserbringung in irgendeiner Form dokumentiert wird. Das geschieht am besten an der Stelle und zu dem Zeitpunkt, an dem die Korrektheit der Lieferung festgestellt wird – im vorliegenden Falle am Ende einer Abnahme durch ein entsprechendes Protokoll.

8 Kommunikation

Es gibt mehrere Regelkommunikationsprozesse, die für ein Abnahmeprojekt relevant sind. Grundsätzlich unterscheidet man die Kommunikation nach innen und nach außen. Intern sind damit die Kommunikationswege innerhalb des Einführungsprojektes selbst gemeint. Die Außenkommunikation teilt sich in die Berichterstattung an das Management und in diejenige, die die Linie zum Adressaten hat.

8.1 Interne Kommunikation

Im Vorlauf zu den Abnahmen gibt es das so genannte Kick-off. Zugegen sein sollten alle Testverantwortlichen, die Projektleitung, Ansprechpartner des Lieferanten während der Abnahme, sonstige Spezialisten und – wenn möglich – ein Vertreter des Anforderungsmanagements sowie Vertreter der Auftraggeber entweder aus dem Fachbereich oder der IT-Linienorganisation. Im Kick-off müssen folgende Fragen geklärt werden:
  • Zuordnung der Testverantwortlichen zu den Einzelfunktionalitäten,

  • erforderliche Testdaten (Abzüge aus Produktivsystemen oder synthetische Daten),

  • Schnittstellenläufe,

  • die zu testenden Geschäftsprozesse – Testskripte (zur Erstellung oder Verteilung),

  • User-Berechtigungen,

  • Testreihenfolgeplanung,

  • Patch-Zyklus und

  • Review-Zyklus.

8.2 Regelkommunikation nach außen

Das Management, unter der das Qualitätsmanagement fungiert, konsolidiert normalerweise alle Projektberichte und erwartet deshalb einen meilensteinbezogenen Status in fester Frequenz: wöchentlich oder vierzehntägig.

Die Linienverantwortlichen erwarten Sicherheit gegenüber der Inbetriebnahme der angekündigten Funktionalitäten, was Zeitpunkt und Qualität betrifft. Meistens wird die Abnahmeleitung zu einer der regelmäßigen Besprechungsrunde eingeladen und kann zu einem eigenen Tagesordnungspunkt dazu berichten.

Literatur

  1. Osterhage WW (2004) Qualitätsmanagement bei der Einführung komplexer IT-Systeme. In: IT-Management. WEKA Fach-Verlag, KissingGoogle Scholar
  2. Osterhage WW (2009) Abnahme komplexer Software-Systeme. Springer, HeidelbergGoogle Scholar

Copyright information

© Springer Fachmedien Wiesbaden 2016

Authors and Affiliations

  1. 1.Johann Wolfgang Goethe-Universität FrankfurtWachtberg-NiederbachemDeutschland

Personalised recommendations