Skip to content. | Skip to navigation

Personal tools

Sections
You are here: Home / Publikationen / Informatik / Theorie und Praxis der automatischen Stundenplanerstellung / Diplomarbeit / html / Qualitätsprüfung und -management

Qualitätsprüfung und -management

next up previous contents
Next: Zusammenfassung Up: Implementierung des Rahmenprogrammes Previous: Sonstiges

Qualitätsprüfung und -management

DIN ISO 9001-3, DIN ISO/IEC 12119

Die DIN ISO 9001-3 beschreibt generelle Vorgehensweisen zur Qualitätssicherung bei Produktionprozessen; eine Anwendung auf die Softwareerstellung findet sich in SCHMAUCH [Sch94]. Es zeigt sich, daß die vorgeschlagenen Verfahren überwiegend für die Abstimmung größerer Teams gedacht sind und der wesentliche Schwerpunkt auf der Erstellung vorgeschriebener Dokumentation beruht. Im Rahmen dieser Diplomarbeit war eine Kooperation nicht gegeben und die Dokumentation erfolgte zeitgleich mit der Erstellung des Programms in der vorliegenden Arbeit. Daher beschränkte sich die Anwendung der entsprechenden Norm auf die Erstellung einer Qualitätspolitik und dem Festlegen einiger Verfahrensweisen (guter Vorsätze), die im wesentlichen eingehalten werden konnten.
Die DIN ISO/IEC 12119 beschreibt die Verfahren, die zur Produktprüfung verwandt werden sollen. Auch hier liegt wiederum der Schwerpunkt auf festgelegten Formularen (s. [LS95]), die eine Klassifikation der verschiedenen Teile und die jeweilige Prüfungstiefe festlegen. Da in diesem Projekt nur ein einziger Entwickler - der Diplomand - und zwei Tester - die betreuenden Assistenten - gegeben waren, reduzierte sich die Dokumentation hier auf ein Notizbuch mit Testideen für den White-Box Test - entsprechend dem analogen Formular aus [LS95] - und elektronischer Post für die Black-Box Tests. Eine weitere Formalisierung erschien nicht angemessen.

Sperrvariablen

Im Programm kommt es an einigen Stellen vor, daß Variablen einer Klasse von verschiedenen Routinen verwandt werden und eine Implementierung mit mehreren Variablen zu speicheraufwendig wäre. Hier wurde in der Test-Versiongif ein umfangreiches Schema von Sperr-Methoden eingerichtet, das eine Fehlermeldung auslöst, sobald eine Routine auf eine Variable zugreifen will, die gerade von einer anderen benutzt wird. Da hier keine echte Nebenläufigkeit auftritt, konnte dies jeweils mit einer einzigen Boolschen Variablen realisiert werden. In der Endversion des Programms werden diese Konstrukte vom Preprozessor entfernt. Als Nebeneffekt ermöglichte dieses Vorgehen eine schnelle Aufspürung und Diagnostizierung ungewollter Rekursionen, die entstanden, da die Aufrufketten innerhalb des Frameworks nicht bekannt sind.

Datumsabhängigkeiten

Das Programm verwendet das aktuelle Datum als Zusatzinformation beim Ausdruck und bei der Erzeugung eindeutiger Schlüssel für Objekte. Beim Druck kann es nicht zu Fehlern kommen, ein Schlüssel hingegen kann sich nach ca. 40 Jahren wiederholen. Es genügt in diesem Fall, das doppelte Objekt zu entfernen. Datensätze die mit verschiedenen Kopien des Programms zur gleichen Zeit - oder bei verstelltem Zeitgeber - erstellt wurden, dürfen nur mit der Import-Funktion, aber keinesfalls von Hand gemischt werden, da es ansonsten ebenfalls zu doppelt auftretenden eindeutigen Schlüsseln kommen kann. Momentan könnte dieses Problem umgangen werden, indem jedes Dokument mit einem eigenen Zähler versehen wird, aber eine Möglichkeit, Datensätze zwischen Dokumenten zu kopieren, würde hier neue Probleme schaffen. Der Austausch zwischen verschiedenen Installationen sollte grundsätzlich nur über die Im- und Exportfunktionen vorgenommen werden.

Unterstützung durch die Entwicklungsumgebung

Als Entwicklungsumgebung wurde Visual C++ 5.0gif verwandt. Die Fehlermeldungen der lexikalischen Analyse bewegen sich im Rahmen des Üblichen; der Parser ist relativ anfällig für ein fehlendes Semikolon am Ende einer Klassendefinition. Einige erwartete (Parser-) Warnungen werden nicht oder nur sporadisch angezeigt. Insbesondere fehlt eine Warnung bei unerreichbarem Code.

Die Sprache selbst bietet mit der Möglichkeit, eigene Klassen von CObject abzuleiten, Features zur genauen Überprüfung der Speicherallokation und der Integrität von Objekten, die bei der Fehlersuche ebenfalls sehr hilfreich sind.
Als zusätzliche Hürde machte sich die Verwendung des Multi-Document-Environment bemerkbar, da es kaum mehr möglich war, globale Variablen zu benutzen, weil mehrere Dokumente konkurrierend darauf zugreifen könnten. Dies führte zu einem erhöhten Dereferenzierungsaufwand und war auch während der gesamten Programmentwicklung eher störend. Da keine direkte Möglichkeit der Datenübertragung zwischen verschiedenen Dokumenten vorgesehen wurde, bringt es dem Benutzer zudem kaum Vorteile.


next up previous contents
Next: Zusammenfassung Up: Implementierung des Rahmenprogrammes Previous: Sonstiges

(c) Martin Loehnertz 1999