Artikel
Optimierung von Entwicklungsprozessen


Rubrik:
Entwicklung

Typ:
Zusammenfassung

Stand:
abgeschlossen

Stichworte:
Qualität, Fehlerklassifizierung, Walkthrough, Inspektion, Software Entwicklung, Prüfungsschemata


"Software-Qualität ist die Gesamtheit d. Merkmale und Merkmalswerte
eines Softwareproduks die sich auf dessen Eignung beziehen, festge-
legte und vorausgesetzte Erfodernisse zu erfüllen."


DIN ISO 9126



Gründe für Qualität:
  • Die Behandlung eines Fehlers kostet Geld
  • Fehler können die Auslieferung des Produkts verzögern
  • Nicht behobene Fehler führen zu einem Imageverlust

Tatsachen
  • Fehlerfreie Software existiert nicht.
  • 1000 Codezeilen enthalten durchschnittlich 25 Fehler (basicpro)

Qualität ist die Übereinstimmung mit den vereinbarten Forderungen
(Klare Definition der Anforderungen, Pflichtenheft)


Ziel von Qualitätssicherung
  • Aufwand zur Erreichung der Qualität minimieren
  • Fehler von vornherein vermeiden.

Zusätzliche Maßnahmen zur Sicherung der Qualität senken mittelfristig die Kosten


Merkmale von Qualität:
  1. Funktionalität
  2. Zuverlässigkeit
  3. Benutzbarkeit
  4. Effizienz
  5. Änderbarkeit
  6. Übertragbarkeit

Definition von Standards zur Qualitätssicherung:
  • Namenskonventionen
  • Routinemäßige Fehlerüberprüfung
  • Standardroutinen

Codeinspektion

Regeln
  • Kann nicht durch den Autor, sondern nur durch das Team erfolgen
  • die Inspektion dient nicht zur Kontrolle der Leistung des Programmierers
    (nur zur Verbesserung des Produktes, keine Inspektion durch Vorgesetzte, keine Verwendung zur Beurteilung des Programmierers)
  • nicht nur der Programmierer, sondern insbesondere die Inspektoren tragen die Verantwortung für den Code.
    (kollektive Verantwortung des Teams)

Vorteile
  • Wissen über zukünftige Inspektion erhöht die Konzentration des Programmierers
  • Mitglieder des Prüfungsteams lernen die Arbeitsmethoden des Programmierers (Know-how Transfer)
  • nachfolgende Produkte des selben Autors enthalten weniger Fehler
  • Kostenreduktion durch geringeren Aufwand für spätere Fehlerbeseitigungen, weniger Hotline/Support

Nachteile
  • Längere Entwicklungszeit (i.d.R. gering im Verhältnis zum eingesparten Support bzw. späteren Fehlerbehebungszeiten)
  • Programmierer 'sitzt auf der Anklagebank'

Prüfungsschemata's

'Walkthrough'
"A review process in which a designer or programmer leads one or more members of the development team through a segment of design or code that he or she has written, while the other members ask questions and make comments about technique, style, possible errors, violation of development standards, and other problems"
(-> ANSI/IEEE Std. 729-1983/)
  • Ziel: finden kleinen Fehlern (keine Überarbeitung des gesamten Produkts)
  • Programmierer präsentiert das Prüfobjekt
  • für kleine Entwicklungsteams geeignet
  • stichprobenartige Prüfung
  • spontane Fragen während der Prüfung
  • Geringer Aufwand, geringer Nutzen
  • Schulung des Teams
  • Autor kann Prüfungsverlauf manipulieren, bestimmt die Reihenfolge

'Inspektion' (M.E.Fagan/IBM)
"A formal evaluation technique in which software requirements, design, or code are examined in detail by a person or group other than the author to detect faults, violations of development standards, and other problems."
(-> /ANSI/IEEE Std. 729-1983/)
  • Ziel: finden großer Fehler (ggf. Überarbeitung des gesamten Produkts)
  • die Inspektion wird durch einen Moderator geführt
  • für mittlere bis große Entwicklungsteams
  • stichprobenartige Prüfung
  • vor der Sitzung prüft jeder den Code gemäß einem zugeteilten Aspekt, in der Prüfung trägt jeder seine (protokollierten) Prüfungsergebnisse vor, weiter Defekte werden während der Sitzung gemeldet
    (die Aspekte werden gemäß Interesse und Talent zugewiesen)
  • mittlerer Aufwand, hoher Nutzen (Empirie : 50-75% der Fehler identifiziert, 20% Entwicklungseinsparung, 30% Wartungseinsparung)
  • Schulung des Teams, Verbesserung des Entwicklungsprozesses
  • keine Manipulation durch den Autor
  • Sitzung wird protokolliert
  • keine Diskussion/Kommentierung während der Sitzung ggf. darauffolgendes Brainstorming
Korrektur der Fehler, Nachüberprüfung durch den Moderator.


Sonstige
  • Schreibtischtest:
    Simulation und Test eines Algorithmus im Kopf. (Aufdecken von Denkfehlern)
  • Black-Box Test:
    Eingabe von Testfällen ohne Betrachtung der internen Funktionen (zB. Anwender)
  • White-Box Test:
    Testfälle generieren, so daß alle Anweisungen mindestens einmal durchlaufen werden.
  • [Verifikation (kein Test):
    Quasi mathematischer Beweis, daß die Software keinen Fehler besitzt (sehr aufwendig).]

 

Unabhängig von der verwendeten Methode sollte immer ein Testprotokoll erstellt werden.

 

Psychologie des Programmierens

Fehlerklassifizierung:


Ursachen von Denkfallen (Menschliches Denkmodell) :
-> Begrenzte Ressourcen des menschlichen Gehirn
  • nur geringe Mengen von Informationen werden bewusst verarbeitet
  • Sparsamkeitsprinzip, Minimierung des Aufwandes
  • Strukturerwartung -> Schubladendenken
  • Überschätzung bestätigter Informationen (Lösung wird für optimal gehalten, nur weil sie funktioniert)
  • lineares Ursache-Wirkungs-Denken (Reduktion auf eine Ursache)
=> Versagen bei komplexen, ungewöhnlichen Problemen
=> mögliche Lösung: Begründung der Lösung als Bestandteil des Entwicklungsprozesses


Verbesserung des Programmierprozesses:
-> Die Qualität eines Produktes wird durch die Qualität des Entwicklungsprozesses bestimmt

  • Einhaltung von Regeln zur Vermeidung von Fehlern
  • Schreiben wiederverwendbarer Module
  • Aufstellung eines Katalogs mit individuellen Programmierregeln (BSP)
  • Dokumentation von Fehlern in einem Fehlerbuch (BSP)
  • Suchen nach Optimierungsmöglichkeiten vorhandener Lösungen

 

Software-Engeniering

Durch Software-Engeniering, das strukturierte Vorgehen beim Programmentwurf, werden Fehlerquellen frühzeitig augeschaltet.
Der Kunde übergibt dem Entwickler eine unstrukturierte Aufgabenbeschreibung (Lastenheft), die dieser strukturieren muss. Im Gegensatz zu 'Quick and Dirty' gilt dabei 'KISS - Keep it simple and smart' ... ;)

Techniken:


Modularisierung Zerlegung in Teilprobleme
Normierung Vereinheitlichung von Programmabläufen
Jackson Methode Der Programmentwurf gemäß den Datenstrukturen
Top-Down Entwurf Ausgang vom Gesamtproblem und Zerlegung in immer kleinere Teilprobleme
Bottom-Up Entwurf Ausgang von den kleinsten Teilproblemen
Unterprogrammtechnik  Entwicklung mehrerer Personen, wiederholende Abläufe
Strukturierter Entwurf Unterteilung in
  1. Folgestrukturen
  2. Auswahlstrukturen
  3. Wiederholstrukturen
  4. Unterprogrammstrukturen
(in strukturierten Programmiersprachen teilw. erzwungen)

Praxis: Mischung der Techniken, oft keine spezifische Trennung

 

Referenzen:
- basicpro: Definieren Sie mal 'Qualität'
- Lehrbuch Grundlagen der Informatik
- Algorithmen und Datenstrukturen (FH München, Prof. Jürgen Plate)




Impressum
 


Copyright 2002,2003 M. Schmitz