Qualitätssicherungsdokumentation

Qualitätssicherungsdokumentation Autoren Christiane Breiter, Oliver Hinz Verteilerliste Auftraggeber: Wirtschaftsinformatik II, Prof. Petzold Heiko Häckelmann, Daniel Walther Email: haeckel@bwl.tu-darmstadt.de Auftragnehmer: Wirtschaftsinformatikpraktikum SS00 WWW: http://w-server.newram.wh.tu-darmstadt.de Email: tspprak@w-server.newram.wh.tu-darmstadt.de Dieses Dokument ist via WWW und Paßwort zugänglich Seite 1 von 10

Inhaltsverzeichnis 1 Einleitung...3 1.1 Änderungsübersicht...3 1.2 Zweck des Dokumentes...3 1.3 Benutzungshinweise...3 2 Organisation der Qualitätssicherung...4 2.1 Aufbauorganisation...4 2.2 Aufgaben und Verantwortlichkeiten...5 2.3 Schnittstellen...5 2.4 Produktbibliothek...5 3 Kritikalität und Q-Stufe...6 3.1 Zweck des Kapitels...6 3.2 Verwendete Richtlinien und Normen...6 3.3 Manuelle Prüfmethode...7 3.4 Vorgehensweise: Inspektion...7 3.5 Zeitplan...8 3.6 Prüfungsverfahren - Black-Box-Test...8 4 Entwicklungsbegleitende Qualitätssicherung...9 4.1 Zu prüfende Produkte...9 4.2 Programmierrichtlinien...9 4.3 Entscheidungen über Fortführung des Projekts...9 5 Spezifische Kontrollmaßnahmen...10 5.1 Eingangskontrolle von Fertigprodukten...10 5.2 Kontrolle von Bearbeitungskompetenzen...10 Seite 2 von 10

1 Einleitung 1.1 Änderungsübersicht Datum Autor Art der Änderung (Kapitel, Thema) 11.05.2000 Oliver Hinz Dokument angelegt 17.05.2000 Oliver Hinz Änderungen nach QS-Besprechung eingebaut 25.05.2000 26.05.2000 Christiane Breiter Christiane Breiter Korrekturen und Formatierung Ergänzung der verwendeten Fertigprodukte 1.2 Zweck des Dokumentes In diesem Dokument werden alle generell geltenden Regelungen bezüglich der Qualitätssicherung im Rahmen des Wirtschaftsinformatikpraktikums definiert. Es wird festgelegt, welches Teammitglied welche Aufgaben und die damit verbundenen Verantwortlichkeiten wahrnimmt. Darüber hinaus werden zu den einzelnen Dokumentarten Richtlinien definiert. 1.3 Benutzungshinweise Das Dokument richtet sich speziell an Auftraggeber und Auftragnehmer, wobei dieses Dokument durch seinen öffentlichen Charakter auch für nachfolgende Wirtschaftsinformatikpraktikums-Gruppen verständlich sein soll. Seite 3 von 10

2 Organisation der Qualitätssicherung Hier findet sich die generell bindende Festlegung zur Organisation der Qualitätssicherung in den Punkten Aufbauorganisation, Aufgaben und Verantwortlichkeiten sowie Schnittstellen zu anderen Organisationseinheiten. 2.1 Aufbauorganisation Die Praktikumsgruppe geht in dieser Organisationseinheit von einem V-Modell aus. Dabei ist zwar generell eine Trennung zwischen QS-Manager und QS-Verantwortlichen vorgesehen, aber im Rahmen dieses Projektes und des studentischen Charakters werden die beiden Rollen in der Rolle des QS-Verantwortlichen zusammengefaßt. Die Rolle des Qualitätsprüfers wird keinem bestimmten Teammitglied zugeordnet. Um einen möglichst hohen Lernerfolg bei allen Teammitgliedern zu erzielen, soll jeder so viel wie möglich an der Arbeit der anderen teilhaben. Dabei bietet sich durch das Testen eine geeignete Chance. In Abhängigkeit des zu prüfenden Produktes / der zu prüfenden Aktivität wird ein Teammitglied vom QS-Verantwortlichen eingesetzt, das nicht an der Entstehung beteiligt war. Eine nähere Erläuterung der Aufgaben und Verantwortlichkeiten folgt im Kapitel 2.2 Rollenname gemäß V-Modell Projekteigener Rollenname Teammitglied QS-Manager QS- Verantwortlicher QS- Verantwortlicher QS- Verantwortlicher Christiane Breiter Christiane Breiter QS-Assistent QS-Assistent Oliver Hinz Qualitätsprüfer Qualitätsprüfer wird in Absprache mit dem QS-Verantwortlichen/QS- Assistenten eingesetzt Seite 4 von 10

2.2 Aufgaben und Verantwortlichkeiten Aufgrund der kleinen Gruppengröße und der Zusammenfassung der Rollen QS-Manager und QS-Verantwortlicher, werden einige Verantwortlichkeiten und Aktivitäten auf den QS- Assistenten übertragen. Aktivitäten Verantwortlicher QS- QS- Assistent Qualitätsprüfer 1.1 QS-Plan erstellen a m 1.2 Prüfplan erstellen a m 1.3 Dokumente zur konstruktiven QS erstellen a m 2 Prozeßprüfung von Aktivitäten a m 3.1 Prüfmethoden und -kriterien festlegen a m 3.2 Prüfumgebung festlegen a m 3.3 Prüffälle festlegen a m 3.4 Prüfprozedur erstellen a m 4.1 Prüfbarkeit feststelllen a m 4.2 Produkt inhaltlich prüfen m a 5 QS-Berichtswesen a m Legende: a = ausführend, m = mitwirkend 2.3 Schnittstellen Sowohl der QS-Verantwortliche als auch sein Assistent dienen innerhalb des Projektteams als auch nach außen als Ansprechpartner bezüglich aller QS-spezifischen Fragen. Sämtliche Aktivitäten der Qualitätssicherung sind mit dem QS-Verantwortlichen und/oder dem QS- Assistenten abzuklären. Beide sind Ansprechpartner sowohl für den Projektleiter als auch für den Auftraggeber. 2.4 Produktbibliothek Alle im Rahmen des Praktikums erstellten Objekte werden in eine Produktbibliothek eingetragen. Dort ist der Fortschritt der Entwicklung, sowie die am Objekt beteiligten Personen eingetragen. Um die Vollständigkeit zu garantieren, wird versucht alle festgelegten Features per Hyperlink mit der Produktbibliothek zu verbinden. Die Produktbibliothek ist per WWW jederzeit einsehbar. Die Verwaltung aller für die Implementierung relevanter Dokumente und Sourcecodes erfolgt über CVS. Seite 5 von 10

3 Kritikalität und Q-Stufe 3.1 Zweck des Kapitels In diesem Kapitel werden grundlegende Richtlinien und Normen bezüglich der konstruktiven Qualitätssicherung definiert. Es werden die analytischen Maßnahmen festgelegt, die zum Erreichen einer bestimmten Kritikalitätsstufe durchgeführt werden müssen. 3.2 Verwendete Richtlinien und Normen Alle Regelungen, die in diesem Kapitel festgehalten werden, gelten für alle Teilprodukte des Gesamtprojekts. Es muß aus jedem Objekt ersichtlich sein, wer die letzte Änderung durchgeführt hat und wann diese stattfand. Zu sämtlichen Produkten müssen zu geeigneten Zeitpunkten Backups erstellt werden. Aussagen Dritter müssen samt Quellenangabe aufbewahrt werden. Das gilt zum Beispiel für Lösungsansätze aus dem Internet. Aktuelle Versionen von Dokumenten müssen im Internet für den Auftraggeber und alle Mitglieder des Teams über WWW einsehbar sein. Regelungen für Dokumente (Pflichtenheft, Konfigurationsmanagement-, Projektmanagementund Qualitätssicherungsdokument) Alle Dokumente haben von der inneren Form her folgenden Kriterien zu entsprechen: Im Dokumentenkopf erscheint der vereinbarte Dokumentenkopf und eine Verteilerliste Am Dokumentenende erscheint das Datum und der Name desjenigen/derjenigen, die zuletzt am Dokument gearbeitet haben Kapitelüberschriften werden fett gedruckt und müssen sich durch ihre Größe absetzen Aufzählungen werden mit Punkten wie dieses Liste dargestellt Insgesamt sollen alle projektzugehörigen Teile als solche erkennbar sein und eine vergleichbare Form und Struktur haben Alle Dokumente sollen in PDF/HTML abgelegt sein Entsprechende Vorlagen werden ausgeteilt. Alle Dokumente werden nach alter Rechtschreibung erstellt. Fremd- und Fachwörter sollen in einem Glossar geklärt werden. Es soll auf Grammatik und Rechtschreibung geachtet werden Seite 6 von 10

Es soll eine sinnvolle Einteilung in Absätze und Kapitel stattfinden, damit eine gute Lesbarkeit gewährleistet ist Alle Aussagen werden auf Wahrheitsgehalt und Widerspruchsfreiheit geprüft Protokolle der Treffen mit dem Auftraggeber und der Teamsitzungen: Alle Protokolle müssen ein einheitliches Erscheinungsbild besitzen Die Protokolle werden nach zeitlicher Reihenfolge auf die Projekt-Website gelegt, damit sie von allen Seiten überprüft werden können Regelungen für den Programm-Code Je nach Entscheidung über die einzusetzende Programmiersprachen wird das QS-Team entsprechende Richtlinien erarbeiten und kommunizieren. Alle Sourcen sind in einem Konfigurationsmanagement-Tool zu verwalten. Es muß aus jeder Version ersichtlich sein, was sich zur vorhergehenden Version geändert hat und wer die Änderung durchgeführt hat und zu welchem Zeitpunkt. 3.3 Manuelle Prüfmethode Die Qualitätssicherung analysiert alle Objekte manuell, prüft und begutachtet sie. Ziel ist es, Fehler, Defekte, Inkonsistenzen und Unvollständigkeiten zu finden. Die Überprüfung erfolgt in einer Gruppensitzung durch ein kleines Team. Dieses Team umfaßt mindestens den Qualitätssicherungsverantwortlichen oder seinen Assistenten und den Autor des betreffenden Objekts. Dokumente und kleinere Objekte können auch über verteilte Sitzungen abgenommen werden. 3.4 Vorgehensweise: Inspektion Jede Klasse und jede Methode wird wie oben beschrieben genau spezifiziert und schriftlich festgehalten. Ziel der Inspektion ist die Identifikation von Defekten im Prüfobjekt. Dabei sind alle Produkte und Teilprodukte, auch Dokumente, einschließlich des Prozesses ihrer Erstellung, Objekte der Prüfung. Als Referenz dient das Pflichtenheft. Es wird versucht, alle Fehler, Defekte, Inkonsistenzen und Unvollständigkeiten zu beseitigen. Es findet eine Eingangsprüfung statt, und der Qualitätssicherungsverantwortliche/-assistent prüft das Prüfobjekt nach den in der Spezifikation festgelegten Aspekten. Sollten Fehler identifiziert werden, muß der Autor das Prüfobjekt überarbeiten. Bei der Nachprüfung wird das Prüfobjekt anhand definierter Kriterien angenommen oder zurückgewiesen. Im Konfigurationsmanagement sind die verschiedenen Zustände und Zustandswechsel der Objekte beschrieben. Seite 7 von 10

3.5 Zeitplan Da nach dem Qualitätssicherungsstandard die Qualitätssicherung einen großen Anteil an der Gesamtentwicklung hat - in der Regel zwanzig Prozent - muß die Qualitätssicherung gut geplant sein. Da zum jetzigen Zeitpunkt die endgültige Version des Entwurfsdokuments noch nicht vorliegt, sind nur grobe Abschätzungen und Planungsvorschriften angeben: Die Erstellung eines Objektes sollte nach sechzig Prozent der gesamten Entwicklungszeit des Objektes betragen. Der Qualitätssicherung wird zwanzig Prozent zur Prüfung und Kritik eingeräumt. Die restlichen zwanzig Prozent entfallen auf mögliche Überarbeitung und eine zweite abschließende Nachprüfung. Dabei sind die Phasen nicht streng sequentiell, sondern können ineinander fließen. Frühzeitig fertiggestellte Objekte können parallel zur Entwicklungsphase getestet und abgenommen werden. 3.6 Prüfungsverfahren - Black-Box-Test Aus Erfahrung läßt sich sagen, daß der C0-Test (Anweisungsüberdeckungstest) bzw. der Zweigüberdeckungstest - auch C1-Test genannt - sich für größere, zeitkritische Projekte wenig eignen. Deshalb versucht die Qualitätssicherung funktionale Testverfahren durchzuführen und greift dabei hauptsächlich auf den Black-Box-Test zurück. Dabei soll für den Tester die Programmstruktur zuerst einmal unsichtbar sein. Dem Tester soll lediglich die Spezifikation des Testobjektes bekannt sein. Es wird versucht, das Programm gegen seine Spezifikation zu testen und dadurch Defekte aufzudecken. Ziel der Testplanung, die dem Qualitätssicherungsverantwortlichen/-assistenten obliegt, ist es, geeignete Testfälle auszuwählen, so daß die Wahrscheinlichkeit möglichst groß ist, eventuelle Fehler aufzudecken. Dabei spielen die Grenzwertanalyse - das Testen spezieller Werte - und Zufallsteste eine vorwiegende Rolle. Für die Zufallstests kann ein entsprechendes Werkzeug herangezogen werden. Seite 8 von 10

4 Entwicklungsbegleitende Qualitätssicherung 4.1 Zu prüfende Produkte Hier finden sich die während der Software-Entwicklung zu prüfenden Produkte: Pflichtenheft Konfigurationsmanagementdokument Qualitätssicherungdokument Dokumente des Sofwareentwurfs Module (Dokumentation im Code, Einhaltung von Programmierrichtlinien) Prüfungsspezifikationen Dokumentation der Tests Bestandteile der begleitenden Website 4.2 Programmierrichtlinien Von den Programmierern wird ein gut lesbarer, wartbarer und erweiterbarer Programmcode entwickelt. Unterstützend werden hierzu Namenskonventionen zur Benennung von Variablen und Methoden vorgesehen. Entsprechende Richtlinien werden von den Chefprogrammierern in Form eines Style-Guide vorgegeben und den anderen Projektteilnehmern zur Verfügung gestellt. Die Einhaltung der Richtlinien erfolgt zum einen durch Selbstkontrolle und zum anderen stichprobenartig durch andere Projektteilnehmer, respektive der Qualitätsbeauftragten. 4.3 Entscheidungen über Fortführung des Projekts Durch die Größe der Gruppe können auch Ausfälle von einzelnen Teammitgliedern kompensiert werden. Es steht deshalb außer Frage, daß das Projekt zu Ende geführt wird. Seite 9 von 10

5 Spezifische Kontrollmaßnahmen 5.1 Eingangskontrolle von Fertigprodukten Die folgenden Produkte finden im Rahmen des Projekts Verwendung, werden aber nicht einer gesonderten Prüfung unterzogen. Es wird davon ausgegangen, daß die Fertigprodukte ihrerseits einer Qualitätssicherung unterliegen. Java Development Kit Rational Rose Netscape Navigator bzw. Communicator Microsoft Excel Microsoft Word Microsoft SQL-Server 7.0 Linux Distribution von Mandrake 7.0 Apache 1.3.9 JServ 1.0 Wu-ftp 2.6.0 Postgresql 6.5.2 Mailman 1.0 CVS 1.10.7 Zusätzliche zu verwendende Produkte werden nachgereicht, sobald endgültig feststeht, welche Produkte im Projekt eingesetzt werden. 5.2 Kontrolle von Bearbeitungskompetenzen Teammitglieder mit gesonderten Bearbeitungskompetenzen tragen jeweils eigenständig Verantwortung dafür, daß kein anderes Teammitglied ihnen vorbehaltene Kompetenzen wegnimmt. Ferner müssen diese Mitglieder ihre Arbeit sorgfältig und nachvollziehbar dokumentieren. Letzte Änderung: 26. Mai 2000 (Christiane Breiter) Seite 10 von 10