| 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.
|
| |
|
