Samstag, 9. November 2013

Entwurf und Bauen von Software – eine falsche Vorstellung.

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.


Im Post Missing Links im Modell haben wir den gesamten Lebenszyklus von Software in die beiden groben Schritte Softwareerstellung und in das Betreiben von Software eingeteilt. Das ist natürlich eine nicht sehr erhellende Unterteilung. Deshalb versuchen wir, mit einem Top-Down-Ansatz in die Tiefe zu gehen. Stück für Stück werden wir neue Schritte finden, Unklarheiten beseitigen und Schwierigkeiten aufdecken. Am Anfang konzentrieren wir uns auf die Erstellung von Software.

Im Vorfeld des Schreibens dieses Posts hat mich ein Freund auf den folgenden Artikel aufmerksam gemacht: "Agile Entwicklung im Vergleich mit anderen Branchen - Agil oder ingenieurmäßig?" von Uwe Friedrichsen. [FRIED10] Dort unterteilt Uwe Friedrichsen den Prozess der Erstellung von Produkten in Entwurfs- und Bauprozess. Dabei stößt er auf die Erkenntnis, dass der Bauprozess in der Softwarebranche fast keine Zeit benötigt. Er ist nämlich nicht das Codieren, sondern lediglich das Kompilieren und Linken. Dadurch verkürzt sich der Bauprozess auf ein Minimum und wir haben die Möglichkeit unser Produkt so oft zu bauen, wie wir wollen.

Diese Tatsache bietet ungeahnte Möglichkeiten. Es ist eine der wichtigsten Voraussetzungen für Agilität. Wir entwerfen eine Brücke, bauen sie, gestalten den Entwurf um, bauen sie erneut. Dieses im Baugewerbe unmögliche Vorgehen ist in der Softwareentwicklung inzwischen normal. Damit verbunden ist die wichtige Erkenntnis, dass wir zu 99% Entwurfsarbeit leisten. Über die Arbeitsteilung dieser Entwurfsarbeit wurde bisher keine Einigkeit erzielt. Im Großen und Ganzen können wir jedoch eine Einteilung in Requirements Engineering, Softwarearchitektur und Implementierung feststellen. Welche Entwurfstätigkeiten werden in diesen Prozessschritten erledigt und wie sollten sie ablaufen?

Im Requiements Engineering definieren wir das WAS. Wir definieren fachliche Anforderungen und Qualitätsanforderungen an das zu schaffende System. In diesem Schritt durchdringen wir das Problem. Eines der wichtigsten Gründe für das Requirements Engineering ist die Trennung von WAS und WIE. Weder die Oberfläche noch andere technische Lösungen sollen das WAS beeinflussen. Kennen wir erst einmal die Fach- und die Qualitätsanforderungen, so können wir optimale technische Lösungen finden. Nur gegebene Randbedingungen, die auch im Requirements Engineering aufzunehmen sind, schränken unseren Lösungsraum ein.

Die Softwarearchitektur erzeugt Strukturen des Softwaresystems, die in Bezug auf die Fach- und Qualitätsanforderungen am besten geeignet sind für die Implementierung, die Pflege und das Betreiben des Systems. Wir finden also eine technische Lösung aus der Draufsicht. Es werden Komponenten und ihre Schnittstellen definiert. Man legt zu verwendende Frameworks fest und bestimmt zentrale Techniken.

Die Implementierung hat auf Grundlage der dokumentierten Softwarearchitektur zu erfolgen. Hier werden die Feinheiten im Design festgelegt. Algorithmen werden in Bezug auf Fachanforderungen umgesetzt. Meiner Meinung nach bezieht sich das notwendige und heute übliche Test Driven Development ausschließlich auf diesen Prozessschritt.

Nachdem der Entwurf durch die drei Prozessschritte erstellt wurde, kann das Produkt gebaut werden. Den Schritt der Softwareerstellung können wir also in vier Teilschritte unterteilen.



Nachdem die grundsätzlichen Schritte von Entwurf und Bauen geklärt sind, möchte ich auf die sequenzielle Folge der Schritte im Diagramm verweisen. Natürlich möchte ich kein Wasserfallmodell entwerfen. Da wir aufgrund der kurzen Bauphase die Möglichkeit haben, das Produkt faktisch so oft zu bauen, wie wir wollen, ist uns das Tor für eine iterative und inkrementelle Entwicklung weit geöffnet. Wir werden jeden dieser Entwurfsschritte in einer eigenen Phase ausführen und den nächsten Entwurfsschritt in der folgenden Phase mit den Ergebnissen des davor liegenden Prozessschrittes versorgen.

Das Requirements Engineering erweitert, ändert und löscht in jeder Phase die dokumentierten Fach- und Qualitätsanforderungen. Diese werden am Anfang der neuen Phase dem Prozessschritt Softwarearchitektur übergeben. Die Architektur wird in Bezug auf die geänderten Fach- und Qualitätsanforderungen angepasst. Die angepasste Architektur ist Voraussetzung für die Implementierung der Fachanforderungen. Am Ende der Implementierungsphase wird das System in einem Release gebaut. Die Länge der Phasen ist flexibel, sie können Minuten, Stunden, aber auch Tage dauern.



Damit haben wir die Voraussetzung für weitere Überlegungen geschaffen. Von besonderer Wichtigkeit sind die Transformationsprozesse zwischen den Teilprozessen. Im Artikel Gibt es einen eklatanten Wissensbruch in der Softwareentwicklung ? habe ich versucht die Schwierigkeiten mit Wahrnehmungs- und Darstellungstransformationen darzustellen. Mit jeder erneuten Wahrnehmung der vorangegangenen Darstellung und mit jeder erneuten daraus erzeugten Darstellung kommt es zu Transformationsverlusten. In den kommenden Verfeinerungen der Prozessschritte sind dafür geeignete Vorgehensweisen zu finden, die diese Verluste minimieren. Außerdem verwiesen Kommentare auf die Notwendigkeit eines Lernprozesses, um die Transformationsverluste zu mindern. Auch das sollte in den zu verfeinernden Prozessen berücksichtigt werden.



vorheriger Post dieses Themas     folgender Post dieses Themas


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

Kommentare:

  1. ich hab nicht alles gelesen ;-) aber IMHO ist es schon so das die analogie zum baugewerbe die bauphase eher der codierungs-implementierungs phase entspricht

    AntwortenLöschen
  2. Der Rückbezug muss aber nicht immer bis zum RE gehen. Es gibt sicherlich auch Situationen, wo sich keine Änderungen im RE ergeben.
    Im Gegenteil, in Anlehnung an ein Wasserfallmodell/V-Modell kann dies den Rücksprung in die Grobkonzeptphase bedeuten, was die Entwicklung immens verteuern kann. Aus Wirtschaftlichkeitsgründen muss die fachliche Konzeption soweit vollständig und stabil sein, dass es durch den Bau-Prozess zu keinen Änderungen mehr kommt.

    AntwortenLöschen
  3. Hallo Stefan, der Rückbezug zum RE ist wirklich sehr absolut von mir gedacht worden und ich denke die Rücksprünge sind so zu korrigieren, dass ich in jede Phase zurückspringen kann. Danke für diesen wichtigen Hinweis. Ob eine fachliche Konzeption wirklich vollständig und stabil sein kann, daran habe ich allerdings Zweifel. Meinst Du nicht, dass sich Projekte immer entwickeln und damit auch Veränderungen unterliegen? An Deinen Erfahrungen in diesem Bereich wäre ich sehr interesssiert.

    AntwortenLöschen
    Antworten
    1. Hallo Ralf,
      sicherlich hast du recht, dass die fachliche Konzeption oftmals unvollständig ist. Es stellt sich aber die Frage des warum bzw. wie man zu einer besseren Konzeption kommt. Denn Ziel ist die Entwicklung für einen Kunden, der sich dann auch in dem Ergebnis wiederfinden soll.
      Iterative oder agile Vorgehensweisen oder Prototyping haben da schon ihren Grund. Meines Erachtens läuft man in diese "Falle", wenn Projekte zu groß geschnitten sind. Schon nach V-Modell 97 ist die Bildung von Teilprojekten in fast allen Projektphasen möglich, so kann man kleinere "Scheibchen" schneiden, die zu konzeptionierenden Inhalte werden überschaubarer. Denkbar ist sicherlich zunächst die fachl. Anforderungen grob zu beschreiben, wenn möglich das Projekt danach zu zergliedern und die nächsten Phasen des Projekts iterativ durchzuführen.
      Im letzten größeren Projekt haben wir auf Basis des Grobkonzepts einen Prototypen erstellt, auf dessen Basis wiederum die fachliche Konzeption durchgeführt wurde. Klar auch da hat es durch Entscheidungen im Rahmen der Software-Architektur und Implementierung Abweichungen gegeben, diese waren aber im Vergleich zum großen Ganzen marginal.

      Löschen
  4. Zunächst 'Hallo' allerseits.

    Das Zurück zum RE unterschreibe ich bedingungslos!

    Die Problematik ist doch die, daß es dem Kunden mitunter selbst schwer fällt zu beschreiben, was die fertige
    Software letztendlich leisten soll. Der /große/ Rahmen dagegen ist ja immer klar.

    Dies hat IMHO jedoch nichts mit der Qualifikation/Durchblick der Beteiligten zu tun.

    Eher ist dies einem beiderseitigen Erkenntnis-Prozeß während der Realisierung des Projektes geschuldet.

    Sowas ist normal, so ist das Leben - wenn nur nicht der bisher erstellte Programm-Code wäre, in welchem viel Arbeit investiert wurde.

    Also, aus rein philosophischer Sicht betrachtet, wäre das Problem doch garkeines, wenn es da am Horizont einen Hoffnungsschimmer gäbe.

    Aber ist denn der Hoffnungsschimmer nicht der, meine Software von Anfang an so lose und so entkoppelt zu bauen, daß da Platz für Änderungen ist? Für sich ändernte Anforderungen?

    Dies mag zwar nicht jedenmanns Geschmack sein, ständig mit irgendwelchen Facaden, Adaptern, Interfaces rum zu werkeln.

    Bloß der Zeitpunkt kommt doch so oder so. Wo man plötzlich seinen Quell-Code aufbohren muß, weil sich die Anforderungen verfeinert/geändert haben.

    Wäre es da nicht viel leichter, seine Komponenten einfach nur in einen neuen Zusammenhang zu stellen, ein paar Neue hinzu zufügen und man ist wieder auf der Ziel-Geraden?

    So wie Karten neu durchmischen?

    Soweit zu /meiner/ bescheidene Sicht der Dinge.

    AntwortenLöschen
  5. Hallo Zusammen,

    einige Jahrzehnte Erfahrung in Software-Engineering haben mich letztlich folgendes gelehrt: es gibt keinen Fachbereich auf dieser Welt, der in der ersten Grobkonzeptphase seine vollständigen Anforderungen und kompletten Wünsche an eine, seine Software überblickt.

    Das erste RE ist schon in der Grobkonzeptphase anzusetzen, bevor es zum ersten Feinkonzept kommen kann. Das ist auch immens wichtig, ein einigermassen stabiles Grobkonzept zu haben. Bisher sind es meistens drei bis vier RE-Phasen gewesen. Erst dann hat der Auftraggeber/Kunde eine ungefähre Vorstellung von dem, was er bekommen will.
    Das zweite RE ist schon nach der Feinkonzeptphase anzusetzen, schlägt ab und an und je nach Komplexität der Aufgabe/Software wieder beim Grobkonzept auf. Das ist aber glücklicherweise eher selten der Fall.
    Die Feinkonzeptphase durchläuft sehr oft seine eigene Schleife, vor allem dann, wenn auch ein Prototyp zur Verfügung steht.
    Ich habe in verschiedenen Firmen die Erfahrung gemacht, dass man am Besten damit fährt (zumindest ich oder wir), wenn man Entwicklerwissen und User Experience in Form von Fachabteilungswissen und Anwenderwissen (Bedienbarkeit) möglichst eng und ausdauernd miteinander verbindet. Das erfordert oft sehr viel Geduld, einerseits von den Fachbereichsleuten, denen das alles zu abstrakt wird und andererseits von der Softwareentwicklung/Projektleitung, alle Parteien immer wieder neu zu motivieren und für das Vorhaben zu begeistern.
    Sind letztere Faktoren gegeben, kommt der folgende Satz von Anfangs der Seite zum Tragen:

    "Menschen, die sich wohl fühlen, Menschen, die geachtet werden, schaffen beachtliche Software."

    Und sogar viel mehr...nämlich brauchbare Software ;-)

    AntwortenLöschen
  6. Die Erfahrung jahrelanger Arbeit im Bereich Software-Engineering hat mich gelehrt, dass der erste RE schon nach dem Grobkonzept (GK) erfolgen muss. Fachbereiche erkennen sich bzw. ihre Anforderungen nicht im ersten und nicht im zweiten Wurf eines GK wieder. Erst der dritte und vierte GK-Entwurf ist so klar, dass der Fachbereich sich beginnt wohlzufühlen und sich mit (eigentlich) seinem Projekt identifiziert.

    Selbiges gilt für das Feinkonzept, wobei im Feinkonzept vor allem die Standhaftigkeit gefragt ist. Und natürlich die Fähigkeit, Softwareentwicklungswissen mit Fachabteilungswissen und User Experience (vor allem der Bedienbarkeit) gewinnbringend zu kombinieren.

    Die Bedienbarkeit steht oft mehr im Vordergrund als die eigentliche fachliche Anforderung, denn, und Achtung: man geht ja davon aus, dass diese wie gefordert/gewünscht in der Software abgebildet wird. Somit findet das Prototyping oftmals mehr Beachtung als das abstrakte Ausformulieren der Funktionen, was den Entwickler in Verzückung versetzt, den Anwender in die Gähnvermeidungsphase drängt. Und das Entsetzen über ein RE vor das Feinkonzept in Freude über einen neuen Denkansatz zu verwandeln.

    Die Kunst besteht jetzt darin, alle Beteiligten bei Laune zu halten und für die Software zu begeistern, auch wenn einige Dinge im Funktionsumfang noch nicht realisiert werden.

    Trotzdem kommen wir somit zur Aussage vom Anfang dieser Seite:

    Menschen, die sich wohl fühlen, Menschen, die geachtet werden, schaffen beachtliche Software.

    Und noch viel mehr...nämlich brauchbare, zielgerichtete Software, die sich leicht bedienen lässt.

    Ich bin der Meinung, dass die Softwareentwicklung im Prinzip ein ewiger Kreislauf ist, die RE-Punkte überall anzusetzen sind. Nur durch das immer wieder umwälzen von Denk- und Schaffensprozessen ermöglicht eine beachtliche Software. Einschränkend ist natürlich der zeitliche und finanzielle Hintergrund eines Projektes.

    Soviel Realität braucht es dann schon.

    AntwortenLöschen