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.


19.02.1982

Qualitätssicherung über Checkliste und Dokumentation

Harry Sneed

SES GmbH,Mmünchen

Die DV-Systeme werden ständig komplexen. Die Anzahl der Funktionen und Datenelemente geht in die Tausende. Ihre Beziehungen sind das Quadrat ihrer Anzahl. Es wird immer schwieriger, den Überblick zu behalten; wer überhaupt soll noch den Überblick behalten?

Bis das Gesamtsystem fertig ist, ist es nämlich zu spät. Das System verschließt sich dann jedem Einblick. Es ist eine große, geschlossene Black box, und man kann nur hoffen, daß es alles tut, was erwartet wird und nicht mehr! Beweisen läßt es sich nicht. Eine genaue Aussage bezüglich seiner Sicherheit und Zuverlässigkeit ist nicht mehr möglich. Der einzige Lösungsansatz ist eine projektbegleftende Qualitätssicherung.

Damit ist aber noch lange nicht das Problem gelöst. Eine projektbegleitende Qualitätssicherung setzt einiges voraus.

Erstens muß das Projekt in Phasen geteilt sein, wobei jede Phase ein nachprüfbares Zwischenergebnis liefert.

Zweitens muß es eine Konvention geben, wie diese Zwischenergebnisse auszusehen haben.

Drittens müssen dem Qualitätsprüfer diese Zwischenergebnisse so aufbereitet werden, daß er sie ohne allzu großen Aufwand verstehen kann.

Schließlich braucht der Prüfer selbst eine Checkliste der Merkmale und Maßnahmen, die nach jeder Phase zu kontrollieren ist.

Phasen

Jede Systementwicklung durchläuft mindestens fünf Phasen. In der ersten Phase - der Requirements-Phase - werden die Ziele des Systems gesetzt. Das Ergebnis ist eine Liste aller Anforderungen. Dazu gehören die Systemleistungen und die Qualitätsmerkmale. In der zweiten Phase - der Spezifikationsphase wird das System in seiner funktionalen Leistung genauestens definiert. Das Ergebnis ist ein allumfassendes fachliches Konzept, in dem alle fachlichen Elemente und Beziehungen festgelegt sind. In der dritten Phase - der Entwurfsphase - wird eine DV-technische Lösung ausgearbeitet. Das Ergebnis ist ein technisches Konzept, aus dem hervorgeht, wie das System an einer bestimmten Maschine zu realisieren ist. In der vierten Phase - der Programmierphase - wird das System in einer bestimmten Notation codiert. Das Ergebnis ist hier das Programm selbst. In der fünften Phase - der Testphase - werden zuerst die einzelnen Programme und anschließend das System in seiner Gesamtheit in bezug auf den Entwurf und die Spezifikation bestätigt. Das Ergebnis des Tests ist eine Testdokumentation, aus der man entnehmen kann, wie sich das System wirklich verhält, das heißt, ob es die bestehenden Daten tatsächlich sichert, ungültige Daten abweist und sich vor unzulässigen Funktionen und Störungen von außen schützt.

Konventionen

Entsprechend den Phasen muß es für jedes Zwischenprodukt eine Konvention geben, zum Beispiel eine Konvention für die Spezifikation, eine für den Entwurf, eine für die Programme und eine für den Test. Diese Konventionen bestimmen den Inhalt und die Gestaltung der einzelnen Dokumente einschließlich der Programme. Es wird natürlich nicht möglich sein, alle Systeme über einen Kamm zu scheren. Inhaltlich und auch methodisch sind die Unterschiede zu groß. Man kann jedoch einen Rahmen abstecken, in den Inhalt und Methode hineinzupassen haben.

Aufbereitung

Dies ist im wesentlichen eine Frage der verfügbaren Werkzeuge. Die letzteren müßten zumindest so leistungsfähig sein, daß sie die Zwischenprodukte klar und übersichtlich darstellen. Hier geht es um die Visuahsierung abstrakten Zusammenhänge, logischer Objekte, ihrer Eigenschaften und ihrer Beziehungen. Es muß für den Qualitätsprüfer stets ersichtlich sein, welche Daten und Funktionen es gibt, wie sie geartet sind und wie sie sich zueinander verhalten. Die Testdokumentation muß zum Beispiel genau aufzeigen, in welcher Reihenfolge Funktionen stattfinden und welche Zwischendatenzustände sie erzeugen. Insbesondere müssen gerade die Ausnahmesituationen deutlich werden, als Beweis dafür, daß sie "geprobt" wurden.

Checkliste

Bei jedem Zwischenergebnis gibt es bestimmte Merkmale, die zu beachten sind. An den Anforderungen ist zu prüfen, ob sie vollständig sind und ob sie sich miteinander vertragen. An der Spezifikation sind Merkmale wie Konsistenz, Vonständigkeit, Einhaltung der gesetzlichen und organisatorischen Vorschriften sowie die Erfassung der Abnahmekriterien zu prüfen. An dem Entwurf sind die technischen Eigenschaften wie Modularität, Portabilität, Zuverlässigkeit und Effizienz an der Reihe. An den Programmen läßt sich die Einhaltung solcher Programmierrichtlinien wie zum Beispiel normierte Satzwahl und Gruppenwechsel, modularer Progrmmaufbau und strukturierte Ablaufsteuerung kontrollieren. Zum Schluß ist anhand der Testdokumentation feststellbar, welche Funktionen, Ausnahmebedingungen und Störungen getestet wurden und wie das System darauf reagiert hat.

Nur mit der Checkliste in der einen Hand und der Dokumentation in der anderen wird (...)Qualitätsprüfer in der (...)sein, seiner Funktion voll gerecht zu werden. Aber nur insofern, als er diese Funktion nach jeder vollendeten Phase ausübt. In dem Augenblick, wo er eine Zwischenprüfung versäumt, verliert er den Anschluß und damit auch seinen Einfluß auf die Systementwicklung.

Überblick

Es ist also doch möglich einen Überblick zu behalten, aber nur zu einem Preis, nämlich dem Preis der Methodik, der Werkzeuge und des Personaleinsatzes Wer bereit ist, diesen Preis zu bezahlen, hat eine gute Chance, seine Systementwicklung in den Griff zubekommen. Wer es nicht tut, wird weiter schwimmen, bis in den Abgrund (...) ein.