David Lorge Parnas and Paul C. Clements A Rational Design Process: How and Why to Fake It

1. David Lorge Parnas and Paul C. ClementsA Rational Design Process:How and Why to Fake It

2. Der ideale Design-Prozess • Studien: Design subjektiv nicht Top-Down eher zufällig • Gesucht: Design-Prozess als systematische Ableitung  rationaler Design-Prozess • Parnas/Clements: nicht real umsetzbar, aber Dokumentation des idealen Prozesses möglich • „Fake“: Dokumentation so, als ob sie aus dem idealen Prozess entstanden wäre

3. Schritte zum rationalen Design-Prozess • Warum ein rationaler Design-Prozess? • Was ist ein rationaler Design-Prozess? • Welche Phasen hat der Design-Prozess, und welche Dokumente entstehen dabei? • Warum einen idealen Prozess vortäuschen?

4. Warum ein rationaler Design-Prozess? • SW-Design irrational gewünschtes Verhaltens unklar Beschränkungen für die Implementation unklar • Design-Entscheidungen ohne Begründung • Gewünscht: Ableitung aus Anforderungen wie Theoreme aus Axiomen (Beweis) Top-Down-Methoden • rationalen Design-Prozess vortäuschen Entwicklung und Wartung leichter

5. Idealisierter Design-Prozess SW-Projekte nie auf rationale Art: • Auftraggeber weiß nicht genau, was er will und kann nicht alles mitteilen. • Details werden erst während der Entwicklung klar. • Einteilung von Aufgabenbereichen • „Human errors can only be avoided if one can avoid the use of humans.“  immer Fehler • Design belastet mit früheren Ideen • Wiederverwendung anderer Projekte

6. Nutzen des rationalen Design-Prozesses • kein reales System rational entwickelt • Design-Methoden: Design logisch vollziehen • realer Prozess so nah wie möglich am idealen Prozess  „fake a rational design process“ • Reihenfolge: idealer Prozess sagt, womit man beginnen soll • besser als ad-hoc: Wissenslücken identifizieren • Standard-Prozedur: Austausch möglich • Messen von Fortschritt, Review einfacher

7. Der rationale Design-Prozess • für jede Phase: Welches Produkt soll entstehen? Kriterien, Beteiligte, Referenzinformationen • Anforderungen: Requirements Document • Architektur: Module Guide • Schnittstellen: Module Interface Specification • Hierarchie: Uses Hierarchy • Interne Struktur: Module Design Document • Implementation • Wartung und Pflege

8. Requirements Document I • vom User gewünschtes Verhalten (Review) • alle Entscheidungen über Anforderungen hier • Konsistenz: Fragen der Designer, Programmierer und Reviewer beantworten • Aufwandsabschätzung • schwierigster Teil: gesuchte Information finden • soll genau das enthalten, was nötig ist, um für User akzeptable SW zu entwickeln keine Implementationsdetails fehlende Information explizit kennzeichnen Referenz-Dokument, keine Erzählung

9. Requirements Document II • Autor: ideal User, real Entwickler (Entwurf) • mathematisches Modell : hybrider Computer analog: kontinuierlicher Input  kont. Output digital: diskrete Änderung des Output • Hauptteil des Requirement Document: mathematische Funktionen (Output als Funktion externer Zustandsvariablen • Organisation des Requirement Document: Zielrechner, I/O-Schnittstellen, Ausgabe, Zeit- und Genauigkeitsanforderungen, Änderungswahrscheinlichkeit, Fehlerfall

10. Module Guide • Aufgaben: Design-Entscheidungen für jedes Modul • Submodule: Guide für Substruktur • Anzahl der Module: Baum-Struktur, am Ende kleine Module • enthält gesamtes Design: besonders für Wartung

11. Module Interface Specification • unabhängige Implementation: module interface specification • „black box“: andere können die Funktionen des Moduls nutzen, mehr nicht • Autor: Designer, Review durch Programmierer • Inhalt: rufbare Funktionen – „access programs“ Parameter und äußere Effekte Zeit- und Genauigkeitsanforderungen unerwünschte Ereignisse

12. Uses Hierarchy • Module und access programs: Abhängigkeit • binäre Matrix: Position (A, B) true gdw. Programm A nur dann korrekt, wenn korrektes Programm B im System existiert • Mengen von Modulen, die ohne andere Module funktionsfähig sindstückweise Fertigstellung fail-soft-Systeme Programmfamilien • Autor: Designer

13. Module Design Document • Hauptanliegen des Moduls beschreiben • effizientes Review vor der Implementation • beschreibt Submodule oder interne Datenstruktur und Auswirkung der Funktionen darauf • unerwünschte Ereignisse • Verifikation: Programm mit diesen Eigenschaften erfüllt Module Specification • falls keine lesbare Hochsprache verwendet wird, zusätzlich Pseudocode-Notation

14. Implementation und Pflege • Anforderungen: Requirements Document • Architektur: Module Guide • Schnittstellen: Module Interface Specification • Hierarchie: Uses Hierarchy • Interne Struktur: Module Design Document Code erstellen, schnell und flüssig • keine redundanten Kommentare (Gefahr der Inkonsistenz) • Pflege ist Redesign: Prinzipen beibehalten, Änderungen in allen betroffenen Dokumenten

15. Bedeutung der Dokumentation • meist: schwer zu verwenden, nicht gelesen • notwendiges Übel, wegen Bürokratie hinterher dazu • Stil: „stream of consciousness“, „stream of execution“  Information nicht auffindbar • langweilige Erzählung: viele Worte statt einer Anweisung, Formel oder Grafik • Terminologie konfus und inkosistent • falscher Inhalt: gut Vertraute dokumentieren Details

16. Ideale Dokumentation • Bedürfnisse aller Beteiligten (vom Projektbeginn bis zur Wartung) • Referenz-Dokumente (Reifung) • für jedes Detail genau eine Stelle in der Dokumentation • erst Struktur der Dokumente, dann Inhalt erstellen • typisierte Terminologie (!+Variable+!, %Wert%, #Funktion#)

17. Faking the Ideal Process • Dokumente so erstellen, wie man sie erstellt hätte, wenn der Entwicklungsprozess ideal verlaufen wäre • keine Design-Entscheidung ohne Dokumentation • egal, wie oft man in Sackgassen landet, endgültige Dokumentation ist genau und rational • dokumentiert nicht reale Entstehung, aber der Leser will auch das Programm verstehen, nicht die Entwicklung nachvollziehen • wenn Dokumentation vernünftig, ist sie lebenslang verwendbar und nützlich, und wenn sie lange verwendet wird, sollte sie gut sein

18. Schlussfolgerung (Parnas und Clements) Es ist schwer, ein rationaler Designer zu sein, auch das Vortäuschen ist nicht leicht. Aber es entsteht ein Ergebnis, das verstanden, gewartet und wiederverwendet werden kann. Wenn das Projekt es wert ist, durchgeführt zu werden, sind auch die beschriebenen Methoden es wert, angewandt zu werden.

19. Diskussion • Die von Parnas und Clements entwickelte Vorgehensweise ist eigentlich nur ein Wasserfallmodell. • Der rationale Design-Prozess hat keinen Nutzen, weil jeder Entwickler ihn wieder subjektiv interpretiert. Er bedeutet nur zusätzlichen Aufwand, der sich nicht lohnt.