Samstag, 14. Dezember 2013

Softwareentwurf ist ein organisierter Kreislauf

Prozessübersicht Softwareentwicklung

Artikelübersicht
1. Teil Missing Links im Modell.
2. Teil Gibt es einen eklatanten Wissensbruch in der Softwareentwicklung?
3. Teil Entwurf und Bauen von Software – eine falsche Vorstellung.
4. Teil Softwareentwurf ist ein organisierter Kreislauf.
5. Teil In Softwareprojekten gibt es viel zu entdecken!
6. Teil Die Interaktion mit dem Kontext ist ein wesentlicher Grund für den Erfolg eines Softwareprojektes.
7. Teil Das unentdeckte Land oder wo noch nie ein Mensch gewesen.
8. Teil Mit schlanken Methoden zu gewollter Software.
9. Teil Die Flexibilität des Vorgehens schenkt laufende Verbesserungen.
10. Teil Vom Problem seiner Rolle gerecht zu werden.
11. Teil Wir gründen eine virtuelle Firma.
12. Teil Warum ist unsere virtuelle Firma nur ein Torso?
13. Teil Eine Arbeitsvorlage, ein strategisches Team und ein tolles Geschäft.
14. Teil Ein fortgesetztes tolles Geschäft.


In einem Kommentar zum letzte Post wurde ich darauf hingewiesen, dass es nicht nur den Rücksprung zum Requirements Engineering geben darf. Wir können natürlich in jede Phase zurückspringen, in das Requirements Engineering genauso wie in die Softwarearchitektur oder die Implementierung. Nur ein sich ewiges Wiederholen des Bauens würde sich mir nicht erschließen. Auch können die Phasen verschieden lange dauern. Des weiteren kann es durchaus sein, dass verschiedene Teile des Teams oder Einzelleistungen in den Phasen gefragt sind. Eines muss jedoch klar sein: In welcher Phase befinde ich mich gerade? Die Vermischung der Phasen führt zu einer Vermischung des WAS mit dem WIE oder auch dem WIE im Großen (die Softwarearchitektur) mit dem WIE im Kleinen (das Softwaredesign, die Implementierung). Da kann es schon mal vorkommen, dass aus einem User Interface (einer Lösung, also ein WIE) Anforderungen abgeleitet werden (also das WAS). Das kann in ein und demselben Augenblick passieren.




Bleibt die Frage: Warum soll das gefährlich sein? Ich denke, dass ist gefährlich, weil wir nicht mehr von der Problemlage aus denken, sondern vom Lösungsansatz aus. Wenn beispielsweise innerhalb einer Abteilung ein Problem mit einem bestimmten Arbeitsablauf entsteht, dann ist es unsere erste Aufgabe zu erfassen worin dieses Problem eigentlich besteht. Haben wir das herausgefunden, wissen wir welches Problem wir beheben müssen. Dazu untersuchen wir das gesamte Umfeld des Problems (Systemkontextanalyse). Wir erfassen alle Schritte des IST-Arbeitsablaufes und versuchen die Stellen herauszufinden, an denen unser Problem zuschlägt. In einem zweiten Schritt legen wir einen optimierten Arbeitsablauf vor. Dabei haben wir versucht das Problem zu beseitigen. Ist uns das gelungen, suchen wir nach den Arbeitsschritten, die sich automatisieren lassen. Diese fassen wir in einer Software zusammen. Die Kommunikation zwischen diesen automatisierten Arbeitsschritten und den nicht automatisierten Arbeitsschritten läuft zum großen Teil über das User Interface. Denken wir vom User Interface aus, beeinflussen wir die Form der Interaktion zwischen automatisierten und nicht automatisierten Schritten des Arbeitsablaufes. Das Bedenken, Durchdenken und Gestalten dieser Kommunikation ist die Aufgabe des Usability Engineering. Die Kunst des Usability Engineering oder deren Vernachlässigung ist „Schuld“ an mehr oder weniger benutzerfreundlichen User Interfaces.

Folgt man der oben dargestellten Denkweise, so finden sich im Requirements Engineering verschiedene Teilaufgaben. Bisher gefunden haben wir die Problemanalyse (Was ist das Problem), die Systemkontextanalyse (Wie sieht das Umfeld aus, welche Optimierungen gibt es und was gehört in das System?), das Usability Engineering (Schaffung eines benutzerfreundlichen User Interfaces) und das eigentliche Requirements Engineering (Ermittlung, Dokumentation und Abstimmung der Anforderungen). Auch diese Tätigkeiten laufen nicht sequentiell ab. Sie beinflussen sich gegenseitig. Trotzdem sollte man sich immer bewusst sein, welche Tätigkeit man gerade ausübt. Versuchen wir diese vier Schritte durch eine andere Denkweise klar zu machen. Wieder erfassen wir zuerst das Problem, dann legen wir den Raum fest (der Systemkontext) in dem das Problem existiert und untersuchen diesen Raum (die Systemkontextanalyse). Innerhalb des Raumes finden wir Dinge, die wir zum System zusammenfassen können, einen automatisierten Bearbeiter von Arbeitsschritten. Diesem Bearbeiter muss man etwas geben, damit man etwas bekommt. Wie man ihm etwas gibt und wie man etwas bekommt sagt uns die zu entwickelnde Schnittstelle (Usability Engineering). Nun haben wir ein System, welches ganz bestimmte Arbeitsschritte erledigen soll und welches eine Schnittstelle zur Interaktion besitzt. Am Schluss ist es unsere Aufgabe die Arbeitsschritte in allen fachlichen Einzelheiten zu beschreiben.

Verfeinerung des Schrittes Requirements Engineering aus der obigen Darstellung :


Beschäftigen wir uns jetzt etwas genauer mit der Problemanalyse. Ein oft anzutreffendes Problem ist die Gestaltung von Prozessen, die ökonomischer sind als der Altprozess. Man möchte z.B. einen Teil der Aufgaben automatisieren. Durch diese Automatisierung sollen Kosten gespart werden. In diesem Fall könnte man das Problem wie folgt beschreiben: Die Kosten sind zu hoch. Mit dem Problem verbunden ist das Ziel: Die Kosten sollen gesenkt werden. Direkt aus der Problemanalyse lassen sich also Ziele ableiten. Trotzdem würde ich zwischen der Problembeschreibung und der Zielbeschreibung unterscheiden. Dabei sollte ein jedes Ziel sich auch auf ein wirklich zu beseitigendes Problem beziehen. Ziele, die meiner Meinung nach keine Probleme beseitigen, ändern nichts. Das Ziel ist somit eine Form der Problembeseitigung.

Verfeinerung des Schrittes Problemanalyse aus der obigen Darstellung :


Schon zum zweiten Mal finde ich eine Unterteilung eines Prozesses, in dem ein Teilschritt des Unterprozesses genauso heißt, wie der gesamte Oberprozess (Requirements Engineering, Problemanalyse). Vielleicht könnte man dafür andere Namen finden und diese Prozesse so besser voneinander abgrenzen?

Jede Analyse durchläuft immer mehrere Teilschritte. Das zu Analysierende wird ermittelt (die eigentliche Analysearbeit), es wird dokumentiert, damit dieses Wissen nicht verloren geht, und es wird abgestimmt, dass heißt es wird überprüft, ob die ermittelten Dinge konsistent und zureichend sind. Diese drei Phasen können wir auf jede Analyse anwenden: Ermittlung, Dokumentation und Abstimmung.



Durch geeignete Rücksprünge und flexible Phasendauer in diesem Modell wollen wir einem bekannten Antipattern des Projektmanagements entgehen, dem Analysis Paralysis. Dieses Antipattern ist auch als Wasserfall oder Process Mismatch bekannt. „Für dieses AntiPattern darf es keine Ausnahmen geben.“ [S. 230, BROWN04] „Eine objektorientierte Analyse konzentriert sich auf das Zerlegen eines Problems in seine einzelnen Bestandteile, es gibt aber keine eindeutige Methode zur Bestimmung des für das System-Design erforderlichen Detaillierungsgrades. Der Fokus verschiebt sich oft vom Zerlegen auf eine Ebene, wo Probleme vom Designer leicht zu erkennen sind, um Techniken anzuwenden, mit denen die mystische „Vollständigkeit“ erreicht werden kann.“ [S. 230, BROWN04] Um ein Problem genauer zu erfassen müssen wir also oft die Ebenen wechseln. Wir gehen im Prozess für einen Teilprozess vorwärts und in die Tiefe, haben neue Erkenntnisse und springen wieder zurück. Eigentlich sollte das ganz normal sein. Das Durchdenken eines Problems ist kein gradliniger Prozess. Mehrmals wird an Grenzen gestoßen und man endet in Irrwegen.

Leider gibt es Ursachen, die uns zum Anwenden dieses Antipattern zwingen. „Das Management besteht auf dem Abschluss der Analyse, bevor die Designphase eingeleitet wird.“ [S. 231, BROWN04], Das ist nur eine Ursache von vielen, die uns zwingen mit diesem Antipattern Kontakt aufzunehmen. Die Folgen sind Kostenerhöhung. Spätere Nacharbeiten sind ungewollt bereits notwendig geworden. Beim Durcharbeiten der anderen Phasen fallen die Unzulänglichkeiten im Entwurf auf, müssen korrigiert werden, haben erneut Auswirkungen auf andere Teile des Entwurfs. Ich denke für Einige ein erlebtes Desaster.

  • [BROWN04] William J. Brown, Raphael C. Malvenau, Hays W. "Skip" McCormick III, Thomas J. Mowbray: "AntiPatterns Entwurfsfehler erkennen und verweiden", 1. Auflage, mitp-Verlag, Bonn, 2004


vorheriger Post dieses Themas     folgender Post dieses Themas


Print Friendly Version of this page Print Get a PDF version of this webpage PDF

Keine Kommentare:

Kommentar veröffentlichen