Qualität ist die subjektive und objektive Beschaffenheit einer Software in Hinblick auf die gestellten Anforderungen
an das Softwareprodukt. Qualität steht dabei durchaus in direkter Konkurenz zur Geschwindigkeit mit der ein Produkt
entwickelt wird. Ziel eines Qualitätsmanagments sollte es daher sein die geforderte Qualität mit möglichst
geringer Beinträchtigung der Produktion zu erreichen.
Ein Beispiel: In einem Projekt in dem ich u.a. tätig war wurde sehr viel Wert auf die Qualitätssicherung gelegt -
sehr lobenswert. Dies ging schließlich soweit, das in den Qualitätssicherungsprotokollen inkorrekte Kommasetzung in
der Dokumentation von Klassendiagrammen bemängelt wurde. Wer sich hier noch nicht an den Kopf faßt der höre / lese
folgendes. Nun wurde nicht allgemein darauf hingewiesen, dass bitte auf die Kommasetzung zu achten sei sondern wie
erwähnt dies in die Protokolle der Qualitätssicherung [QS] aufgenommen. Dabei wurden Textpassagen in das Protokoll
kopiert, das Komma an der richtigen Stelle eingesetzt und farblich hervorgehoben. In der Dokumentation der
eigentlichen Klassendiagramme wurde eine Änderung jedoch nicht vorgenommen. Dies hatte nun zur Folge das die
Softwareentwickler zur Abarbeitung der QS Protokolle die Kommasetzung (wie vorgemacht) im Klassendiagramm gesetzt
haben. (Haken an das Protokoll, wieder was erledigt, 5 Minuten Arbeitszeit abzurechnen...)
In jedem Projekt müssen gewisse Grundvoraussetzungen erfüllt sein, um einen erfolgreichen Projektabschluß zu ermöglichen. Hierzu gehören eine Regelung zur Zuständigkeit, Verschaffung eines Überblicks, eine Leitung und nicht zuletzt die Ausbildung der Projektmitarbeiter. Daneben muss der Projektauftrag definiert sein.
Ohne Zuständigkeiten zu verteilen und abzugrenzen geht nichts. Dabei ist die Zuständigkeit nicht für den gesamten Entwicklungzyklus star zu sehen. Ohne eine Regelung werden Sie jedoch sehen, dass entweder Teilbereiche von mehreren Personen bearbeitet werden oder aber ganz außen vor bleiben.
Jeder an der Entwicklung Beteiligte muss das Ziel kennen. Nur so lassen sich Fehlentwicklungen vermeiden.
In einem Projekt wurde zum Start alle Betroffenen zusammengerufen und in einer mehrstündigen
Veranstaltung die Ziele vorgestellt. Dabei waren Diskussionsbeiträge genauso erwünscht wie kurze
Statements soweit das Ziel des Projektes nicht in Frage gestellt wurde. Hier wurden selbst Beteiligte
informiert, die absehbar in den nächsten Monaten noch nicht im Projekt mitarbeiten würden.
Die (An)Leitung bzw. Projektleitung kann aufgrund Ihrer Vorgaben erheblichen Einfluß auf die Qualität der Entwicklung nehmen. Ziel muss es sein das richtige Mittelmaß zu finden - zwischen ausreichend Tests der Komponenten und Vorantreiben des Projektes/der Entwicklung. Dabei können zu hoch gesteckte Ziele genauso schädlich sein wie zu viel Spielraum (von "Das schaffen wir sowieso nicht." bis "Da haben wir noch so viel Zeit, da bleibt uns auch noch etwas zum...").
Die Ausbildung der (internen) Mitarbeiter ist eine wesentliche Grundkomponente. Aber insbesondere bei
großen Projekten ist auch die "Ausbildung" der externen Mitarbeiter notwendig.
In einem Projekt an dem ich teilnehmen durfte wurde mit einer Ausbildung von ca. 12 Monaten für
interne Mitarbeiter gerechnet. Externe Mitarbeiter wurden zumindest hinsichtlich Projektstruktur und
deren Vorgaben eingewiesen.
In einem anderen Projekt wurden gestandene Programmierer nach ein paar
Java Grundkursen in die Entwicklung einer komplexen Swinganwendung "gesteckt" - die Anlaufschwierigkeiten
waren entsprechend hoch...
Der Projektauftrag muss definiert sein und vorallem in seinen groben Zielrichtungen festgelegt werden.
Es bringt wenig, wenn sich der Projektauftrag elementar verändert. Was Elementar ist kann in jedem Projekt
unterschiedlich sein.
In einem Projekt zur Betriebssystemumstellung einer Software ist die Änderung der Zielplattform
eine elementare Veränderung. Selbst die Änderung hinsichtlich einer Betriebssystem Version kann hierbei
gewichtige Auswirkungen haben.
Ein anderes Beispiel ist die Vorgabe der Anwendungsplattform: ob ich eine
Stand-Alone-Client Anwendung aufsetze oder eine serverbasierte mehrschichtige Anwendung haben möchte hat
gravierende Auswirkungen auf die Softwarearchitektur.
Eine Änderung des Projektauftrages während des Projektes hat eine entscheidene Auswirkung auf die
Qualität des abgelieferten Produktes und/oder den Zeitpunkt des Projektendes.
Softwareentwicklungsumgebung [SEU] als maßgebender Faktor zur Qualitätssicherung? Ja! Dies scheint vielleicht nicht auf den ersten Blick so zu sein doch es gibt einiges zu bedenken. Kleine Projekte können Sie problemlos mit einem Texteditor und einem Kommandozeilenorientierten Compiler durchführen.
Die SEU soll die Entwickler unterstützen. Dies bedeutet der Softwareentwickler bekommt die SEU
bereitgestellt in einer Form das dieser mit der SEU sofort arbeiten kann. Weiterhin soll der Entwickler alle notwendigen
Funktionalitäten in seiner SEU haben. Hierzu gehören heut zu Tage u.a. integriertes Refactoring ebenso wie Debugging
(auch Animieren genannt).
Zwei Beispiele: In einem weiteren Projekt konnte ich mich am ersten Tag an meinen Schreibtisch setzen, hatte
Stifte, Papier, Locher etc. Ich schaltete meinen Entwickler PC ein, meldete mich mit dem Passwort an (auch dies hatte
ich unaufgefordert benannt bekommen) und konnte sofort die Entwicklungswerkzeuge benutzen. So muss es sein. Es geht
jedoch auch anders... so gibt es die Auffassung ein Entwickler ist selbst für seinen PC verantwortlich. D.h. der
Entwickler "verschwendet" seine wertvolle Zeit damit den PC ersteimal mit der notwendigen SEU zu installieren - um
genau zu sein nicht der Entwickler sondern JEDER Entwickler. Auch dies ist leider ein Praxisbeispiel.
Es gibt zahlreiche Vorgehensmodelle zur Softwareentwicklung.
Extreme Programming [XP] auch als eine Lösung gerühmt propagiert einige Konzepte, welche einer hohen Qualität Ihres
Softwareproduktes zu Gute kommen kann. Dabei werden u.a. das Pair Programming (zwei Entwickler codieren gleichzeitig)
den selben Quellcode, Testgesteuerte Programmierung (erst den Test für die Funktionalität dann die Funktionalität
selbst kodieren), ständiges Refactoring und globales Eigentum am entstehenden Quellcode (jeder Entwickler des Teams
kann zu jeder Zeit jeden beliebigen Quellcode ändern) sowie ein Minimum an Überstunden gefordert.
XP wird für große Projekte meist abgelehnt, da es keine genauen Termine festlegt.
Nun ja XP ist nichts neues. Fast jeder Entwickler hat schon mal einen Kollegen gerufen, um ein Stück
problematischen Quellcode anzupacken. Tests zu schreiben bevor man programmiert würde ich eher als heres Ziel
ansehen, da die Zeit der Entwickler meist dagegen spricht. Andere Punkte sollten Sie in Hinblick auf die Qualität
IMHO sogar ersthaft hinterfragen. So ist es in Projekten wichtig klare Schnittstellen zu haben die durch das oben
angesprochene globale Eigentum eher gefährdet sind. In den Projekten an denen ich mitarbeiten durfte wurde XP auf
Teamebene meist in mehr oder weniger Umfang erfolgreich eingesetzt. Es ist aber kein Allheilmittel!
Softwaretest - ja das braucht man um qualitativ hochwertige Software zu erstellen! Aber was ist eigentlich Softwaretest? Das Testen von Software nimmt häufig einen zu geringen Stellenwert ein. Den Satz "Das Programm wird verteilt [...] aber OHNE IRGENDEINE GARANTIE, nicht einmal die Garantie auf Funktionsfähigkeit. Für mögliche durch das Programm verursachte Fehler und Schäden an Soft- und Hardware übernimmt der Autor keine Haftung!" kennen Sie sicher in der einen oder anderen Ausprägung. Diesen habe ich übrigens aus der Hilfe des Werkzeugs entnommen, mit dem ich gerade diese Seiten erstelle - IMHO ein sehr gutes Produkt. Eingentlich ist diese Aussage ein Armutszeugnis aber wahrscheilich lesen Sie genau deshalb diesen Artikel hier. Das Testen selbst umfaßt mehrere Teile, wobei wir und den Bereich der Kodierung später anschauen werden.
Ein Testsystem ist ein System bei welchem dem Entwickler weitestgehende Rechte eingeräumt werden. Ziel des Testsystem
ist es funktionsfähige Software in eine definierte Umgebung zu bringen und auf Fehlerfreiheit zu prüfen. In
ein Testsystem kommt hierbei Software, welche noch nicht an den Kunden ausgeliefert worden ist. IMHO sollte
stets ein Testsystem betrieben werden.
Mal wieder ein Beispiel wie es nicht sein sollte: Bei einer Software, welche in der ganzen Bundesrepublik Deutschland
im Einsatz ist wurde auf ein Testsystem verzichtet. Warum ist mir nicht bekannt. Das Produkt war in den ersten drei
Versionen derart mit Fehlern gespickt, dass einzelne Kunden nicht bereit waren das Produkt einzusetzen bzw. andere
Produkte eingesetzt haben.
Ein Referenzsystem stellt ein System dar wie es beim Kunden im Einsatz ist. Es dient insbesondere der
Problemlösung bei auftretenen Störungen. Diese sollen durch eine möglichst getreue Wiedergabe des System beim
Kunden [Produktionssystem] nachvollzogen werden. Standardmäßig hat ein Entwickler keine besonderen Rechte. Software,
welche ein Problem beheben sollen können temporär in ein Referenzsystem eingespielt werden. Ein wesentliches
Merkmal eines Referenzsystem ist, dass es jederzeit möglich ist den Zustand wie im Bereich der Produktion (wieder)
herzustellen.
Mal wieder ein Beispiel gefällig? In einer größeren Firma die die Software nur für Ihre Kunden mit genau definierten
Zielsystem herstellt ist man der Meinung Test- und Referenzsystem in einem abbilden zu können. Dummerweise
treten immer wieder Fehler in dem Produktionsbereich auf, welche in diesem System nicht vorhanden sind - woran dies
wohl liegen mag???
Diese Art von Test durchzuführen ist mehr verbreitet als man glauben möchte. Teilweise entspricht dies der sogenannten
Beta-Version. Lasse einen Teilbereich deiner Kunden meckern bevor du dir alle Kunden verprellst. Ziel
ist es bei einer Konzeption der neuen Software (Stufe 1) oder kurz vor der Freigabe (Beta) Probleme zu finden und diese
möglichst vor Auslieferung zu beseitigen. Während bei dem Test einer Konzeption speziell der Akzeptanztest im
Vordergrund steht um frühzeitig Fehlentwicklungen zu vermeiden, ist es Ziel des Betatest die letzten Bugfixes
vorzunehmen.
Ein positives Beispiel aus einem Projekt in das ich mehr zufällig hereingerutscht bin: Aufgrund geänderter
Rahmenbedingungen wird in der Firma ein neues Oberflächendesign mit geänderte Handhabung angestrebt. Aus diesem Grund
wurde bereits vorab ein Team gebildet welches auch mit späteren Anwendern besetzt ist. Parallel zu den Bestrebungen
dieses Teams wird ein Oberflächenprototyp entwickelt der die Anforderungen der Anwender des Teams wiederspiegelt. In
einem weiteren Schritt werden "unbedarfte" weitere Anwender auf diesen Prototyp losgelassen um die Anforderungen des
Teams weiter zu verifizieren.
package visible oder protected ausgestattet. Um Zugriff zu bekommen wurde eine Klassenfactory
genutzt, welche Schnittstellentypen zurückliefert. Dies hatte den klaren Vorteil, dass die Fachprogrammierer ohne
fertige Implementation des Zugriffschutzes bereits loslegen konnten.
D Schalter in Spalte 7).