About SW-Quality Safety SW-Entwicklung UML Nachschlagen Programme
Q-Kriterien
Basics
Prozess
CodingRules
SourceCode Metriken
ISO9000 und SW
ISO9000
Speziell für Software: 
4.1Leitung/QMS 4.4Designlenkung Problemanalyse SW-Design 
4.6Lenkung/Beschaffung  4.13Korrektur Vorgehensweise  SW-Test
4.17Q-Audits/Schulung  Q-System 
 
Software-Entwicklung nach ISO 9000 Schritt 2: Software-Design und Implementierung 
Implementierungsstandards
  • Festlegen von Programmierrichtilinien

  • und Einhalten dieser Richtlinien.
  • Zweckmäßige Implementierungsmethoden und Werkzeuge einsetzen.
  • Warum?

  • Die einzelnen Codeteile sollen zusammen passen und die Entwicklung soll vorhersagbar sein.
  • Standards / Coding Rules sind wichtig, aber zu viele sind schädlich.
  • Innovative Projekte erfordern die Nichtbeachtung von Standards man will ja gerade Neues/Ungewohntes.
Designart
prozessorientiertes
Design
Funktionalität des Problems und der Lösung
datenorientiertes
Design
Prozess der zu manipulierenden Daten
objektorientiertes
Design 
Prozess+Daten. Bestimmte Datenobjekte werden mit zugehörenden Prozessen versehen.
ereignisorientiertes
Design
Ereignisse müssen während ihres Auftretens gelöst werden (real time).

Vorgehensweise

top down immer weiter unterteilen/verfeinern 
bottom up Algorithmen (wiederverwendbare Komponenten) zuerst, dann zum System zusammenbauen
Hard part first  Opportunistisch. down im Mix mit bottom up, je nach erkanntem Problem.
Kritischre Teilprobleme werden sofort behandelt, dann wieder das Gesamtsystem.
Empfehlung top down als Grobstruktur und zur Dokumentration. Aber opportunistisches Vorgehen anwenden.
.
Design
  • Design ist heuristisch und iterativ (trial and error).
  • Für Design ist Erfahrung nötig (alte Problemlösung vorhnanden?)
  • Problematisch ist die Übergabe des Designs an die SW Entwickler. Diese haben andere Erfahrungen, andere Lösungswege. Diskrepanz lässt sich nicht verhindern.
  • Review für Design und Codierung.


Darstellung

  • Formlos zur Unterstützung des Denkprozesses
  • Formal zur Unterstützung der Kommunikation und der Übergabe (z.B. UML).
  • Abhängig von der gewählten Designart und der Vorgehensweise.


Design Review

  • Kann das Design ein vorhandenes Problem hinreichend lösen ?
  • Diese Art von Review sollte nicht formal durchgeführt werden, es gibt dafür keine allgemeingültige Vorgehensweise.
  • Das Design Review gehört zu den effektivsten Fehlerbeseitigungsmaßnahmen (frühzeitige Fehlererkennung). 
Fehlertolerantes Design
  • Fehler sollen möglicht geringe Auswirkungen auf die Funktionsfähigkeit haben.
  • Diversity/Diversität

  • Verschiedenheit der SW Teile statt Redundanz (2 Teams entwickeln mit unterschiedlichem Ansatz)
  • Recovery Blocks: Bereiche mit unterschiedlichem Code, die Fehler erkennen und in den ursprünglichen Zustand wiederherstellen können
  • n-Versionen, entwickelt von n-Teams; Umschalten auf anderen Code wenn ein Code fehlerhaft arbeitet 
  • Data Diversity: verschiedene Datgen mit dynamischem Übergabemechanismus 

  • Problematisch: noch keine anerkannten Methoden dazu vorhanden!
Automatische Designprüfung
  • Tools checken meist nur Syntax, aber besser als nichts...

  • Ob die entwickelte Lösung die Richtige ist, kann nicht automatisch geprüft werden. 
 

 
©; created Mon Aug 07 22:31:53 CEST 2006; eMail