Sonntag, 15. September 2013

Missing Links im Modell

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.


Das Buch [WEIL10] bot die Gelegenheit, eine Idee zu formulieren, die mir schon lange im Kopf ist. Die gesamte Softwareentwicklung und das Betreiben dieser Software setzt sich aus so vielen Einzelschritten zusammen, dass sie oft nicht zusammen gedacht werden. Das Zerreißen in kleine Schritte ist notwendig, um die Komplexität zu beherrschen. Das Zusammenfügen der kleinen Schritte jedoch auch, um das Ganze nicht aus den Augen zu verlieren. Softwareentwicklung ist nicht nur codieren. Softwareentwicklung besteht aus einer Vielzahl von Artefaktentwicklungen, die alle miteinander verwoben sind und Abhängigkeiten zueinander aufweisen. Das Suchen nach allen Schritten und den Zusammenhängen zwischen ihnen und deren Notwendigkeiten ist die Vision der Posts unter dem Thema "Prozessübersicht Softwareentwicklung".

Für die junge Wissenschaft der Softwaretechnik gibt es einige Besonderheiten zu beachten. Die Softwareentwicklung wird durch einen schlimmen Wissensbruch gekennzeichnet. Jeder Bruch erzeugt eine Schnittstelle, an der es zu erheblichen Verständigungsschwierigkeiten kommen kann. Nehmen wir die Baubranche. Hier gibt es den Architekten, der gelernt hat, ein Modell von einem zukünftigen Bauwerk auf Papier zu bringen, so dass der Maurer es für uns am geeigneten Platz errichten kann. Das gesamte Fachwissen, das ein Haus ausmacht, ist im Kopf des Architekten. Die Modellsprache zwischen Architekt und Maurer ist eine gemeinsame. Man sollte sich verstehen. In der Softwareentwicklung ist das nicht so. Das Fachwissen ist oft getrennt vom Modellwissen. Der Bankmitarbeiter hat das Fachwissen im Kopf. Der Requirements Engineer versucht, es zu verstehen und in ein geeignetes Modell zu übersetzen. Der Softwarearchitekt und der Entwickler versuchen es dann umzusetzen. Der erstgenannte Wissensbruch ist ein ganz erheblicher. Dieser erhebliche Unterschied zu alten Ingenieurwissenschaften verdient eigene Prozessschritte im Herstellungsprozess. Das sollten wir im Hinterkopf behalten.

Eine weitere Besonderheit, jedoch nicht mehr so eklatant, ist die Vorstellung, jeder könnte in der Softwareentwicklung mitdiskutieren. Der oberflächliche Drang, Software in Benutzung und Oberflächen zu denken, führt in vielen Entwicklungen zu Entprofessionalisierungen. Ganz entscheidende und vor allem notwendige Schritte und Kompetenzen trauen sich Menschen zu, die es weder gelernt haben und / oder auch nicht die Begabung dazu besitzen. Diese Reihe von Aufgaben sind zum Beispiel das Software Design, das Usability Engineering oder das Requirements Engineering. Auf all diesen Gebieten sind eine fundierte Ausbildung und langjährige Erfahrung notwendig. Ein weiter Aspekt dieses Betrachtungspunktes ist die Übernahme dieser Kompetenzen durch Entwickler. Entwickler entwickeln Code. Sie sind keine Designer, keine Usibility Engineers und keine Requirements Engineers. Doch das magische Verständnis von Softwareentwicklung führt oft zur Übernahme aller Spezialisierungen in der Hand eines Genies. Doch leider sind Genies sehr selten. Gleichberechtigte Zusammenarbeit verschiedener Kompetenzen und das Vertrauen, jeder andere weiß auch etwas, bringt uns an dieser Stelle wesentlich weiter.

Aus den beiden Gedanken kann man ableiten, dass der zu entwickelnde Prozess Teilprozesse enthalten muss, die spezialisierten Aufgaben zugeordnet sind und Teilprozesse, die eine wirksame Übersetzung unterschiedlicher Fachsprachen ermöglichen. Zum Zusammentragen aller Teilprozesse und einer annähernden Vollständigkeit benötige ich genau das Fachpublikum, auf die meine Artikel abzielen. Ich wäre Euch oder Ihnen sehr dankbar, wenn ich zu diesem Thema Feedback bekommen könnte, so dass ich den Prozess auf dem Fachwissen vieler aufbauen könnte. Diese Form der Zusammenarbeit beginnt beim einfachen Kommentar, beim Hinweis auf eigene Beiträge, den eigenen Blog (also Euren/Ihren) bis hin zu Gastartikeln oder gemeinsam verfassten Posts. Natürlich müsste eine solche Zusammenarbeit organisiert werden, aber bekanntlich ist ja nichts unmöglich.

Zur visuellen Erfassung des Prozesses werden wir die Modellsprachen der Object Management Group (OMG) verwenden, vor allem BMM, BPMN und UML. Die visuelle Darstellung wird die Kommunikation wesentlich erleichtern, sagt doch ein Bild mehr als tausend Worte. Nach diesen Vorbetrachtungen zum Thema möchte ich heute mit der Installation dieser Unternehmung beginnen. Dazu verwenden wir das Business Motivation Model.

Am Anfang definieren wir den Zweck des Unternehmens. Der Zweck setzt sich aus der Vision und dem gewünschten Ergebnis (desired result) zusammen. Das gewünschte Ergebnis wiederum unterteilt sich in strategiesches Ziel (goal) und operatives Ziel (objective). In [WEIL10] kann man das genau nachlesen oder auch in den Spezifikationen der OMG. Hier möchte ich mein Anliegen mit den Mitteln der BMM modellieren.

Ich definiere also eine Vision: Wir verstehen den gesamten Lebensprozess von Software von der Wiege bis zum Grab.

Auf dieses gewünschte Ergebnis beziehen sich die strategischen und die operativen Ziele. "Ein strategisches Ziel führt die Vision … weiter aus" [S.73, WEIL10] Operative Ziele quantifizieren strategische Ziele. Ein operatives Ziel versucht also, ein strategisches Ziel messbar zu machen. Versuchen wir uns also an unserer Unternehmung.

Strategisches Ziel: Der Lebensprozess der Software wird als Modell aufgezeichnet.

Operatives Ziel: In 4 Monaten haben wir den gesamten Lebenszyklus für Software abgebildet. Mindestens 100 Feedbacks bestätigen zu 90% die Richtigkeit des erstellten Modells.

Nachdem wir die Ziele definiert haben, können wir über die Mittel (means) nachdenken. Ziele und Mittel werden streng getrennt betrachtet. Die Ziele werden die gleichen bleiben, die angewendeten Mittel können sich ändern. Die Mittel unterteilen sich in Missionen (missions), Vorgehensweisen (course of actions) und Vorgaben (directives). Vorgehensweisen sind Strategien (strategy) und Taktiken (tactic) und Vorgaben Unternehmensgrundsätze (business policy) und Geschäftsregeln (business rules).


Die Mission beschreibt, was wir unternehmen, um die Vision zu erreichen: Wir erstellen auf der Grundlage von BPMN einen Übersichtsplan über alle Softwareprozesse über den gesamten Lebenszyklus mit Hilfe des Feedbacks aller beteiligten Berufsgruppen für den D.A.CH.-Raum.

In unserer Mission haben wir also eine Maßnahme beschrieben. Wir machen also etwas. Um diese Maßnahme umzusetzen, können wir verschiedene Vorgehensweisen anwenden. Dazu entwickeln wir eine Strategie, die mit Hilfe beliebig vieler Taktiken umgesetzt werden kann. Im Folgenden zähle ich einige Strategien auf und danach die entsprechenden Taktiken.

Strategien:
  • Die Ergebnisse werden in diesem Blog publiziert.
  • Die Ergebnisse werden in Kurzform auf Twitter angekündigt.


Taktiken:
  • Der Blog muss gepflegt werden.
  • Es müssen Blogartikel geschrieben werden.
  • Es müssen Beiträge in Twitter geschrieben werden.
  • Es werden Kontakte über Email gepflegt.


Zum Schluss einige Worte zu den Vorgaben. Zu diesem Zeitpunkt der Unternehmung fällt es mir etwas schwer, dazu Grundsätze und Regeln aufzustellen. Ich denke aber, wenn das Modell Form annimmt und man daraus Anderes ableiten kann, wird auch dieser Teil sich mit Leben füllen. Der Weg ist das Ziel :-). Das letzte Bild ist keine Provokation, sondern nur der Einstieg in eine, so hoffe ich, interessante Unternehmung, für alle, für die Softwareentwicklung mehr ist als codieren.


  • [WEIL10] Tim Weilkiens, Christian Weiss, Andrea Grass: "Basiswissen Geschäftsprozessmanagement", 1. Auflage, dpunkt.verlag GmbH, Heidelberg, 2010


folgender Post dieses Themas


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

Kommentare:

  1. Ich bin dabei wenn es um Gastartikel oder ähnliches geht.

    Was man noch ergänzen kann:

    "Auf all diesen Gebieten sind eine fundierte Ausbildung und langjährige Erfahrung notwendig."

    Oder/Und: Eine Einarbeitung in diese Gebiete durch einen Lehrer, einen Meister, einen Könner. Diese Rolle vermisse ich häufig in Software-Teams.

    AntwortenLöschen
  2. Noch ein Feedback:

    Die Diagramme wirken qualitativ etwas unprofessionell. Das liegt primär an der Komprimierung und den Verpixelungen.

    AntwortenLöschen