Stefan Wörthmüller hat in seinem aktuellsten Newsletter der XING-Gruppe “Softwareprojekte in Krisensituationen” einen interessanten Hinweis auf einen Artikel in Dr. Dobb’s – The World of Software Development gegeben. Hier fasse ich die wichtigsten Inhalte zusammen – die Grafiken sind Links auf den Originalartikel:
Dr Dobbs – Get Software Quality Right.
Einleitend bemerkt der Autor Capers Jones, dass das National Institute of Standards and Technology 2002 in einer Studie herausfand, dass mehr als 60% der befragten produzierenden Unternehmen schwerwiegende Fehler (Major) in gekaufter Software fand, und dass die Anzahl der kleineren Fehler (minor) nur knapp unterhalb von 80% lag.
Capers Jones argumentiert, dass Fehler / Lines of Code (LOC) kein geeignetes Maß für die Qualität sind, da sie andere Phasen des Software-Lebenszyklus ignorieren und stellt die Maße Fehlerpotenzial (defect potential) und Effizienz der Fehlerbehebung (defect removal efficiency) der IBM vor.
Für die Ermittlung des Fehlerpotenzials nutzt er Function Points und zeigt, warum dieses Maß besser geeignet ist als LOCs.
Fehlerpotenzial und Effizienz der Fehlerbehebung ist abhängig von den benutzten Vorgehensmodellen (CMMI ML 1, 3 und 5; Agile; XP; RUP; TSP), die er vergleicht. Die Daten stammen aus Studien seines Unternehmens und werden leider nicht detailliert erklärt. Er erläutert aber ausführlich, wie er die Tabelle interpretiert.
Anschließend zeigt Caspers Jones auf, wie die Effizienz der Fehlerbehebung gesteigert werden muss und warum.
Zusammengefasst sind folgende neun Schritte in genau dieser Reihenfolge notwendig, um die Effizienz der Fehlerbehebung auf einen kumulierten Wert von 95% erreichen zu können:
- Design Inspektionen
- Code Inspektionen
- Automatisierte statische Analyse
- Modultests
- Tests neuer Funktionen
- Regressionstests
- Performanztests
- Systemtests
- Externer Betatest
Seine Schlussfolgerung ist, dass Kombination aus Inspektionen, statischer Analyse und Testen billiger als reines Testen ist und die Entwicklungszeiten um mehr als 45% kürzt, da bereits bei Beginn der Tests 85% aller Fehler bereits behoben sind.
Anschließend stellt er noch ein paar beeindruckende Zahlen vo IBM vor, die für sich selbst sprechen:
Formale Inspektionen in einem Datenbankprojekt reduzierten die Anzahl der ausgelieferten Fehler im Vergleich zu vorherigen Versionen um 50%, der Zeitplan wurde um 15 % gekürzt. Statt 60 Tage lang im Dreischicht-Betrieb zu testen, war nur noch eine Schicht über 40 Tage notwendig. Und am wichtigsten war die Kundenzufriedenheit, die sich von”sehr schlecht” auf “gut” erhöhte.
Die Effizienz der Fehlerbehebung stieg von 80% auf über 95%, Wartungskosten sanken mit 45% Reduktion für das erste Entwicklungsjahr deutlich.
Guten Abend, die 60% schwerwiegende Fehler in gekaufter Software
kann ich aus unserer Erfahrung nur bestätigen. Was mich persönlich dabei am meisten nervt ist der Zustand, dass ich nach Tagen an Testerei eindeutig den Fehler dem Softwarehersteller belegt habe und dieser schon intern bekannt war. Nur wenige Firmen gewähren Ihrem Kunden einen Zugang zum Entwicklerstand – schade genau das würde mich veranlassen Kunde zubleiben. Diese Kostenverursacher konnten wir innerhalb kurzer Zeit austauschen und das Beste daran, wir haben bessere und vertrauensvollerer Partner gefunden.
.
Herzlich Rudof Pusterhofer