Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

Kooperation zwischen Entwicklern und Usern läßt in der Praxis zu wunschen übrig:

SW-Eingangskontrolle muß viele Hürden nehmen

03.04.1987

Für die Software-Eingangskontrolle würde eine Kooperation zwischen Entwicklern und Benutzern den Idealfall darstellen. Allerdings zeigt sich in der praktischen Arbeit. daß eine solche Zusammenarbeit vielfach nur Wunschvorstellung ist. Eine echte Eingangsprüfung für SW-Produkte im Vergleich zur Überprüfung des Wareneingangs von Gütern der allgemeinen Produktion ist auch zumindest in absehbarer Zeit nicht zu erwarten.

Wenn die Software geliefert beziehungsweise bereitgestellt wird, ist es eigentlich viel zu spät, über die Eingangskontrolle der abgelieferten Programme und Dokumentationen nachzudenken: Der Empfänger der Software wird mit einer Vielzahl von Funktionen und Vorgängen konfrontiert, die zumindest zum überwiegenden Teil neu für ihn sind; es ist meist nur möglich, zunächst einen Überblick zu bekommen, nicht aber die Details der Leistungen des Systems zu erkennen oder gar zu verifizieren.

Die Zeit für die Abnahmefrist beginnt; dabei müssen die ersten Schritte ausschließlich damit zugebracht werden, das System in die vorhandene Entwicklungsumgebung einzubetten (beispielsweise Bereitstellen/Anpassen der JCL, Einrichten von Datenbanken). Ein Pflichtenheft (Fachkonzept) hat es unter Umständen nicht gegeben oder es ist nicht aktuell, das heißt, Änderungen während der Entwicklung sind im Pflichtenheft nicht nachgetragen worden. Diese Situation findet man sowohl bei der Fremd- als auch bei der Eigenentwicklung.

Die Bedeutung der Software-Eingangskontrolle wird deutlich, wenn man die Software-Entwicklung einmal vergleicht mit der allgemeinen Produktion von Gütern (siehe Abbildung 1).

Bei der allgemeinen Produktion wird ein Auftrag über eine bestimmte Menge eines Artikels (zum Beispiel zwölf Bürostühle eines bestimmten Typs in einer genau festgelegten Ausführung) bestellt; bei der Auslieferung der Ware ist dann relativ einfach zu überprüfen, ob die bestellten Artikel geliefert worden sind. Die Eingangskontrolle reduziert sich vielfach auf einen Abgleich zwischen Auftrag und Lieferung. Eine detaillierte Prüfung der gelieferten Ware im Hinblick auf Faktoren wie Stabilität wird normalerweise nicht durchgeführt; derartige Prüfungen sind durch den Lieferanten - im Rahmen seiner Qualitätssicherung oder Endabnahme - bereits erfolgt. Teilweise wird von dem Abnehmer eine zusätzliche Wareneingangskontrolle durchgeführt. Hervorzuheben ist, daß in der Regel exakt bestimmt ist, was geliefert werden sollte.

Im Gegensatz dazu stellt sich die Situation für die Software-Produktion anders dar. Insbesondere die nicht gegebene Determiniertheit der Festlegungen im Pflichtenheft ist die entscheidende Komponente. Die Ursache für die geringere Determiniertheit bei Aufträgen zur Software-Produktion ist im wesentlichen durch den Charakter der Software-Produktion als erstmalige Einzelfertigung begründet. Dies gilt auch, wenn eine Standard-Software auf die Belange eines Unternehmens angepaßt wird. Wenn dies auch die gegenwärtige Situation darstellt, bedeutet es nicht, daß der gegebene Zustand auf Dauer beibehalten werden muß; vielmehr ist die besondere Gewichtung eines Pflichtenhefts mit konkreten und operationalen Anforderungen das Ziel. Wenn dann nach dem DV-Systementwurf, dem Detailentwurf und der Realisierung die Programme und die Dokumentation zur Abnahme bereitgestellt werden, ist die Eingangskontrolle wesentlich einfacher durchzuführen.

Die Aufgaben der Software-Eingangskontrolle umfassen den Abgleich, ob die gelieferten Produkte (Programme und Dokumentation) dem Auftrag entsprechen. Dabei sollte - ebenso wie dies für allgemeine Produktion gegeben ist - weitestmöglich auf die Ergebnisse, die während der Entwicklung erzielt worden sind, zurückgegriffen werden. So wie zum Beispiel auf Qualitätsprüfungen der ausgelieferten Ware verwiesen beziehungsweise Bezug genommen wird, sollte dies auch bei Software seln. Für die ausgelieferten Programme und Dokumentationen muß - stichprobenartig - die eine oder andere Detailprüfung erfolgen, zu einem hohen Anteil sollte allerdings auf Ergebnisse der Entwicklung zurückgegriffen werden können. Nur dadurch kann der Aufwand für die Eingangskontrolle in vertretbaren Grenzen gehalten werden.

Die Bedeutung der Eingangskontrolle für Software wird deutlich, wenn man die unterschiedlichen Interessengruppen betrachtet:

Nutzer

Nutzer der Software sind bei Fremdentwicklung sowohl der Anwender als auch der DV-Fachmann.

- Für den DV-Fachmann ist die Eingangskontrolle zum Beispiel im Hinblick auf die später durchzuführende Wartung der Software von Bedeutung oder im Hinblick auf die Schnittstellen zu anderen Software-Systemen, für die entsprechende Schnittstellen-Programme zu erstellen sind.

- Für den Anwender (Fachbereich) ist die Eingangskontrolle notwendige Voraussetzung, um die Verantwortung für die Freigabe/Anwendung des Software-Systems übernehmen zu können. Eine unzureichende Eingangskontrolle birgt die Gefahr in sich, daß zum Beispiel die Mitarbeiter mit der Benutzeroberfläche unzufrieden sind oder aufgrund von Fehlern in der Verarbeitung fehlerhafte Datenbestände entstehen.

Entwickler

Aus der Entwickler-Sicht hat die Eingangskontrolle insbesondere hinsichtlich der Kosten beziehungsweise der Abrechnung Bedeutung. Vielfach wird die letzte Zahlung an das Ergebnis der Eingangskontrolle gekoppelt. Dies sollte dann auch die Motivation für den Entwickler sein, die notwendigen Schritte - wenn nicht überflüssig zu machen - so doch in dem möglichen Maße durch Kooperation im Vorfeld zu erleichtern und vorzübereiten. Im Bereich der Software-Produktion sind wesentliche Unterschiede im Hinblick auf die allgemeine Produktion bei der Eingangskontrolle gegeben.

Für die Software-Eingangskontrolle sind als Bereiche zu unterscheiden: Voraussetzungen, Vorbereiten der Eingangskontrolle, Ausführen der Eingangskontrolle, Planung und Steuerung der Eingangskontrolle.

Voraussetzungen für die Software-Eingangskontrolle

Die wesentliche Voraussetzung für die Software-Eingangskontrolle ist das Pflichtenheft beziehungsweise die Fachspezifikation. In dieser Unterlage muß festgelegt sein, was das Software-Produkt leisten soll. Die Festlegungen innerhalb des Pflichtenheftes müssen so weit operationalisiert sein, daß im Rahmen der Software-Eingangskontrolle eine eindeutige Prüfung im Hinblick auf das Erreichen oder Nicht-Erreichen der vorgegebenen Ziele vorzunehmen ist.

Vorbereiten der Software-Eingangskontrolle

Daß eine Software-Eingangskontrolle vorzübereiten ist, wird generell nicht angezweifelt. Fragen gibt es im allgemeinen zu:

- Welche und wie viele Testfälle sind erforderlich?

- Kann man die Testfälle beziehungsweise Testdaten der Entwickler benutzen?

Voraussetzung für die Beantwortung der Fragen ist zunächst, daß man die Aufgaben der Software-Eingangskontrolle konkretisiert. Für Programme ergeben sich folgende grundsätzliche Aufgaben (siehe Abbildung 2):

- Vorgangstest,

- interner Vorgangskettentest,

- externer Vorgangskettentest,

- Qualitätstest,

- Installationstest,

- Pilottest.

Alle Aufgaben, die in einer abgeschlossenen Umgebung durchgeführt werden können - dies sind Vorgangstest und (teilweise) interner Vorgangskettentest -, könnten vonständig vom Entwickler bearbeitet werden. Andere Aufgaben, wobei Schnittstellen zu anderen Anwendungen zu berücksichtigen sind - externer Vorgangskettentest und Qualitätstest - können vom Entwickler nur begrenzt durchgeführt werden. Daher ergibt sich von vorneherein eine gewisse Arbeitsteilung.

Für die Software-Eingangskontrolle, muß angestrebt werden, daß Vorgangstest und interner Vorgangskettentest vollständig vom Entwickler durchgeführt werden und vom Nutzer ausschließlich die Prüfung der Vonständigkeit der Testfälle/Testdaten für Vorgangstest und internen Vorgangskettentest erfolgt. Für diejenigen Bereiche, wo Schnittstellen zu anderen Anwendungen zu berücksichtigen sind (externer Vorgangskettentest), müssen aus Nutzersicht zusätzlich Testfälle ermittelt werden.

Insgesamt ergeben sich für die Testvorbereitung folgende Maßnahmen:

- Prüfen Vollständigkeit Testfälle/Testdaten

Anhand der Testfälle ist der Nutzer bereits frühzeitig in der Lage, die Vollständigkeit der später auszuführenden Testläufe im voraus zu beurteilen. Die Prüfung der Vollständigkeit der von den Entwicklern durchgeführten Tests sollte bereits auf der Basis der ermittelten Testfälle frühzeitig im Entwicklungsprozeß erfolgen. Generell wird davon ausgegangen, daß Testfälle für den Vorgangs- und Vorgangskettentest spätestens mit dem DV-Systementwurf fertiggestellt werden.

Durch das Prüfen der Vollständigkeit der Testfälle werden eventuell Mißverständnisse bei der Interpretation der Festlegung im Pflichtenheft erkannt. Voraussetzung hierfür ist, daß ein geeignetes Verfahren zur Testfallermittlung und eine geeignete Darstellungsform für die Ergebnisse verfügbar ist.

- Ergänzen Testfälle/Testdaten aus Nutzersicht

Für diejenigen Aufgabenbereiche, bei denen Schnittstellen zu existierenden Anwendungen zu berücksichtigen sind, erfolgt die Testvorbereitung (Testfallermittlung und Testdatenerstellung) sinnvollerweise durch den Nutzer. Wichtig ist dabei die Nachvollziehbarkeit der Testfälle, damit man gezielt festlegt, was benötigt wird.

- Fehlerbewertung- 1

Die Erfahrungen aus einer Vielzahl von Projekten haben deutlichgemacht, daß bereits bei der Testfallermittlung beziehungsweise der Bewertung von Testfällen Unzulänglichkeiten erkannt werden, die aus Lücken im Pflichtenheft oder Mißverständnissen gegenüber dem Pflichtenheft resultieren.

Diese Ergebnisse sind im Rahmen der Fehlerbewertung zu gewichten und an die Entwickler weiterzumelden. Der Vorteil der frühzeitigen Fehlererkennung ist offensichtlich: Fehler werden unmittelbar in der Nähe der Fehlerverursachung erkannt, so daß Folgefehler vermieden werden. Ergebnis der Fehlerbewertung-1 sind unter Umständen Änderungen in den Anforderungen.

Die vorgenannte idealtypische Arbeitsteilung ist allerdings vielfach in der Praxis heute noch nicht möglich. Wenn sich nämlich zum Beispiel beim Prüfen der Vonständigkeit von Testfällen/Testdaten herausstellt, daß die von den Entwicklern ermittelten Testfälle/Testdaten entweder nicht vonständig oder nicht methodisch fundiert aufgebaut sind, bleibt dem Nutzer keine andere Möglichkeit, als die Aufgabe vonständig selbst durchzuführen. Dies bedeutet dann unter Umständen, daß der Vorgangstest und der interne Vorgangskettentest vonständig vom Nutzer bearbeitet werden muß. Daß dieser Tatsache entgegengetreten werden muß - nicht zuletzt aus wirtschaftlichen Gründen -, ist unbestreitbar.

Ausführen der Software-Eingangskontzolle

Auch bei der Software-Eingangskontrolle wird davon ausgegangen, daß vom Nutzer nicht alle Teilaspekte wiederholt werden, die bereits vom Entwickler bearbeitet sind.

Für die Ausführung der Software-Eingangskontrolle gelten unter anderem folgende Anforderungen:

- Nachvonziehbarkeit

Die Nachvonziehbarkeit der Testausführung ist wichtig, um für die Fehlerbewertung die entsprechenden Fakten vorliegen zu haben und den Entwicklern die Fehleranalyse zu erleichtern.

- Koordinierte Testausführung

Die Ausführung der Software-Eingangskontrolle muß koordiniert erfolgen; hierzu gehört zum Beispiel, daß die Ergebnisse der Ausführung über eine zentrale Stelle an den Entwickler übermittelt werden (normalerweise über die Projektleitung). Es hat sich als in hohem Maße ungeeignet herausgestellt, wenn gleichzeitig unterschiedliche Stellen (wie DV-Seite und Anwender) mit dem Entwickler Ergebnisse absprechen.

- Die Vonständigkeit der Ausführung ist abhängig von folgenden Faktoren:

Für Aufgaben, die von den Entwicklern nachweisbar bearbeitet worden sind, reichen meist Stichproben aus (zum Beispiel für den Vorgangstest und den internen Vorgangskkettentest). Die Aufgaben, die von dem Nutzer zusätzlich bearbeitet wurden, sind vonständig zu bearbeiten. Darüber hinaus sind alle Aufgaben, die individuelle Komponenten des Nutzers umfassen, intensiver zu bearbeiten als diejenigen, die standardmäßig Bestandteil einer Anwendung sind.

Beim Ausführen der Software-Eingangskontrolle sind folgende Maßnahmen zu bearbeiten:

- Prüfen Vonständigkeit Entwicklertest

Die Vonständigkeit der von den Entwicklern ausgeführten Testläufe ist zu prüfen unter Berücksichtigung der Testprotokolle.

- Ergänzende Testausführung

Die ergänzende Testausführung umfaßt zumindest die erstellten Testfälle/Testdaten aus Nutzersicht. Darüber hinaus können einzelne Testläufe der Entwickler wiederholt werden. Hierbei wird normalerweise stichprobenartig so vorgegangen, daß individuell für einen Nutzer erstellte Komponenten in den Vordergrund gestellt werden und gegebenenfalls standardmäßig verfügbare Komponenten des Anwendungssystems nur stichprobenartig bearbeitet werden; dabei sollten diejenigen Komponenten, bei denen Fehler auftreten, besonders intensiv berücksichtigt werden.

- Fehlerbewertung-2

Nach der Testausführung sind die erkannten Fehler zu gewichten und an den Entwickler zu melden.

- Freigabe

Die Freigabe aus Nutzersicht kann dann erfolgen, wenn die Fehlerbewertung zum Beispiel ergeben hat, daß keine Muß-Fehler mehr vorhanden sind und nur eine vertretbare Anzahl von Kann-Fehlern vorhanden ist.

Planung und Steuerung der Eingangskontrolle

Die gesamten Maßnahmen zur Software-Eingangskontrolle sind zentral zu planen und zu steuern. Dies umfaßt zunächst die Koordinaten des zeitlichen Ablaufs. Hierbei ist besonderer Wert darauf zu legen, daß die Aufgaben zeitgerecht bearbeitet werden. Hinzu kommt die Koordination der Bearbeiter.

Die Zusammenarbeit der unterschiedlichen Bearbeitergruppen auf Nutzerseite bezieht sich auf folgende Funktionen der Bearbeiter: DV-Organisation/Programmierung, Fachbereich, Projektleitung, DV-Management und Qualitätssicherung (siehe Abbildung 3).

Die unterschiedlichen Personengruppen sind jeweils für die Aufgabenbereiche einzuplanen, wo sie einen effizienten Beitrag zur Problemlösung erbringen können. So muß der Fachbereich zwar in der Vorbereitung der Eingangskontrolle, nicht aber bei der Testausführung beteiligt werden. Die Entscheidung über den Abschluß von einzelnen Aufgaben obliegt der Projektleitung oder dem DV-Management.

Die Nutzung vorhandener Ergebnisse ist ein erklärtes Ziel für die Software-Eingangskontrolle. Dies ist allerdings nur in dem Maße möglich, wie die Zusammenarbeit zwischen Entwicklern und Nutzern koordiniert erfolgt. Allerdings zeigt sich in der praktischen Arbeit, daß dies vielfach nicht gegeben ist.

Dies ist unter anderem darauf zurückzuführen, daß die eigentlich erforderliche Zusammenarbeit nicht als Vertragsbestandteil definiert worden ist. Hier gilt dann die allgemeine Erfahrung, daß der Entwickler dem Nutzer nicht unbedingt sagt, was er getan beziehungsweise nicht getan hat.

Der Aufwand für die Software-Eingangskontrolle ist im wesentlichen davon abhängig, wie groß der Anteil der vom Nutzer zusätzlich zu erstellenden Testfälle/Testdaten ist:

- Die eigentliche - stichprobenartige - Prüfung der Vonständigkeit von Teinergebnissen der Entwickler ist weniger aufwendig.

- Das Ergänzen von Testfällen/Testdaten aus Nutzersicht sowie die Testausführung für den externen Vorgangskettentest ist zwar komplex, aber mengennäßig umfaßt diese Aufgabenstellung meist keine große Zahl von Einzelfällen. Daher sollte dieser Aufwand nicht mehr als drei bis fünf Prozent des Entwicklungsaufwands aussachen. Die Bedeutung gerade der Verbindung mit externen Schnittstellen ist allerdings hervorzuheben.

- Aufwendiger ist das Ergänzen von Testfällen/Testdaten für den Vorgangstest und Vorgangskettentest, sofern dies erfotderlich ist. Für die konkrete Planung ist zu berücksichtigen, mit welchem Grad der Vonständigkeit die fehlenden Dinge bearbeitet werden sollen.

Heinz Bons und Rudolf van Megen sind Geschäftsführer der SQS Gesellschaft für Software-Qualitätssicherung mbH, Köln.