Triablog V-Modell Teil 2: Das V Gebäude

 

Entwicklung muss organisiert und strukturiert werden, das ist klar. Das V kann wohl als das Erfolgsmodell bezeichnet werden, um dieses zu tun. In Deutschland ist es aber nicht nur das standardisierte V Model XT des Bundes, es sind viele Variationen von V-Modellen, die für das Vorgehen in großen und kleinen Produktentwicklungen Pate standen.

Die Grundprinzipien, die zum V führen

Nach einem allgemeinen Grundverständnis lassen sich stets folgende Prinzipien in den V-artigen Modellen erkennen: einmal die Aufteilung zwischen Erstellung, der linke Schenkel und Prüfung, der rechte Schenkel, zweitens eine Soll-Beschreibung des Systems auf der Erstellungsseite und der Prüfungsseite, drittens ist immer eine Systemzerlegung auf der linken Seite, einer prüfenden Test- und Integrationsseite rechtsseitig gegenübergestellt.

Dieser Aufteilung liegt die Erkenntnis zugrunde, dass eine gesonderte Prüfungssicht hilfreich und nützlich sein kann, Stichwort „Black Team“ (http://wiki.c2.com/?BlackTeam), als auch dass die Kette von der Anforderung über das Design zu weiteren Systembestandteilen durch Verfolgbarkeit effizientere Entwicklung möglich macht. Ich muss es aber jetzt schon sagen, diese Sicht gewinnt dabei zu viel Dominanz über die darin nur schlecht erkennbare Entwicklung über die Produktreifungsphasen und Zyklen. Es wird auch nicht besser, wenn man das V stampft, und der ultimative Planungs-Blueprint, nämlich Plan/Do/Check(Act) offensichtlich wird.

Der Prozessdesigner legt los

Mit der obigen V Bauanleitung lassen sich jetzt die passenden Modelle bauen, die für jede entsprechende Entwicklungssituation eine ausreichende Abstraktion darbieten. Hat man erst einmal das Grundgerüst können nun Rollen, Ablaufprozesse und Ergebnisdokumentation hineingedacht und hineingebracht werden. Bewähren muss sich das Modell dann im rauen Projektalltag, wo dann auch vielleicht verschiedene Verständnisse aufeinanderprallen:

Komponenten-Experten und System-Integratoren:„ Wir müssen in zwei Wochen einen ersten Prototypen bereitstellen, wir bräuchten seit gestern die fertigen Designs“.

Architekten und Designteams: „Erst müssen uns die Anforderungsmanager ihre geprüften und freigegebenen Anforderungen geben, dann können wir das Arbeiten anfangen“.

Das V wird zementiert

Heute hat sich das V-Modell in die Organisationen und in die Rollenmodelle eingeprägt. Manche Firmen bauen Ihre Gebäude nach dem Modell und lassen Anforderungsspezialisten im 4. Stock einziehen. Im Erdgeschoss werden die Komponenten zusammengeschraubt oder Code gestrickt. Ein fertiges System darf das Gebäude erst verlassen, wenn der Systemtest im 4. Stock gegenüber, sein i.O. auf alle Dokumente und Abnahmeprotokolle gegeben hat.

Das selbstverbessernde Element darf im V-Modell jedoch auch nicht fehlen. Wächter über Prozesse, Methoden und Werkzeuge, Qualitätsmessende und Verbesserungsmaßnahmen überwachende Einheiten. Leider fehlt eigentlich immer die Selbstzweckmessung.

Rollen, Rollen, Rollen

Die Kompetenzfelder und damit das gängige Rollenmodell, also die notwendigen Spezialisten und Experten sind durch das Modell und seine Elemente erst mal recht offensichtlich vorgegeben. Jedes Kästchen muss mindestens mit einer Rolle bevölkert werden. Die Landkarte prägt dann ihre Bewohner, das Rechte Schenkel-Land und das Linke Schenkel-Land dürfen jetzt nur über definierte horizontale Brücken miteinander Handel betreiben.

In der Hauptsache lassen sich folgende Grundrollen nennen:

Der Anforderungsmanager oder Requirements Engineer mit z.B. einer IREB-konformen Grundausbildung oder einer Qualifikation zum Business Analysten.

Tester und  Prüfer Rollen. Bekannt sind in dieser Domäne Qualifikationen nach ASQF.

Der Architekt, eigentlich ein Berufsstand aus dem Bauwesen, ist eine Rollenbezeichnung die sich stark aus einer entsprechenden Bewegung in der Softwareentwicklung ergeben hat. Der Umstand, dass die Beachtung qualitativer Anforderungen starken Einfluss auf die Grob- und Feingestaltung von Systemen hat, führt zu einer Kapselung der Gestaltungsverantwortung in einer Person oder eben einer Rolle. Dass diese Rolle viel Erfahrung und erworbenes Geschick bedarf, wird leider durch nur notwendige Modellierkenntnisse, oder eine als ausreichend empfundene Kenntnis von SW-Architektur-Lehrinhalten, manchmal übersehen. Heute scheint eine Besetzung in diese Rolle für Berufseinsteiger möglich. Dort, wo es so gehandhabt wird, kann es sich nur als wenig zielführend erweisen. Die Rolle wird dann oft zu einem Modell-Wartungstechniker degradiert. Die wahren Architekten können mit evtl. verminderter Verantwortung im Hintergrund agieren.

Auf der Subdesign-Ebene stehen in den Modellen dann oft Rollenbezeichnungen wie Umsetzer, Entwickler, Codierer oder Konstrukteur. Oft teilen sich diese Rollen in domänenspezifische Rollenbilder auf. Typisch dabei die Aufteilung in z.B. Mechanik, Software, Elektronik. An dieser Stelle prägen sich natürlich die Systemtechnologien auf, aber auch die funktionale Partitionierung des Systems drängt sich auf, und es wird hier stets ein Kompromiss zu finden sein.

Wichtiges Beiwerk

Prominente Prozessreifemodelle, die in enger Verwandtschaft mit dem V-Modell stehen und dieses auch, wie z.B. SPICE, mit ihren ENG-Prozessgebieten als Hauptentwicklungszyklus darstellen, ergänzen das Modell um unterstützende    bzw. führende  Tätigkeitsbeschreibungen, und damit indirekt auch mit bekannten Rollen. So wird man da auf der Suche nach der Projektmanager- , Konfigurations-, Änderungsmanager- oder auch Risikomanager Rolle fündig.

Die V-Maschine und ihre Bedienmannschaft

Es ist immer fast erschreckend, wie in den gängigen Lehr- und Bildungsmaterialien das V-Modell wie eine Maschine dargestellt wird, die wenn nur richtig konstruiert, ihren Dienst tun wird. Aber das ist natürlich auch dem Umstand gezollt, dass in den meisten Fällen technisch geschultes Personal sich in der Organisationsgestaltung übt. Ich beziehe mich da gerne mit ein.

Es kommt dann die allgemein anerkannte und wenig hinterfragte Meinung hinzu, welche sagt, dass Erfahrung und einmal gefundenes funktionierendes Handeln in Prozesse gegossen werden kann. Diese könnten fast blind von zumindest anlernbarem Personal, unterstützt durch den Automatenkollegen, zu den gewünschten Ergebnissen führen. Das mag für Herstellungsprozesse von Seriengütern gelten. Der Entwicklungsprozess braucht eigentlich nur recht wenig von dieser Ware- er lebt eigentlich mehr vom stetigen Brechen der Regel. Es spricht eigentlich nur für die grandiose Anpassungsfähigkeit von uns Menschen, dass wir unter den widrigsten Prozessbedingungen immer noch nach Zielerreichung Ausschau halten.

Das V steht Kopf, dreht sich und zerfällt

Das V-Modell hat seinen Reiz. Es ist ein Lehrmodell, das ob seiner vielfältigen Interpretierbarkeit zu weitreichenden Erklärungen einlädt. Es lassen sich wichtige Begriffe des Entwickelns damit vergegenwärtigen. Der Einsatz in der Praxis, und dass es irgendwie funktioniert, spricht ja für die Verwendung.

Trotzdem haben Experten des Scientific Engineering-Managements wie z.B. Boehm mit seinem Spiralmodell schon früher Alternativen aufgezeigt. Dieses hatte im Gegensatz zu einem seiner Erben, dem RUP (Rational Unified Prozess), eher theoretische Betrachter denn echte Anwender. Beiden Ansätzen kann man jedoch zugute halten der Iteration wieder den Ihr gerechten Platz eingeräumt zu haben.

Das V agil machen

Verschiedene Vorschläge der vergangenen Zeit sprechen vom agilen V-Modell. Gemeint ist dann oft die SW-Entwicklung im Scrum Modus zu betreiben. Etwas verwaschener sind Aussagen, dass die Architekten jetzt Modelle auf Grundlage des agilen Manifests erstellen wollen. Verallgemeinert kann man sagen, man lässt die spezialisierten V-Model-Domänen-Experten nun ihre Dokumentarien im Sprint-Takt erzeugen. Tatsächlich liegt der Nutzen hier wohl weniger in der erhofften Steigerung irgendwelcher Produktivität, als vielmehr in einer geordneten und schrittweisen Transition in neue Zusammenarbeitsmodelle, die Produktivität neu definieren werden.

Die “No V” Bewegung

Die agile Bewegung könnte man fast als die Abrisskugel für das V betrachten.  Bei agilen Buchautoren wie Marc Cohen lässt sich gut erkennen, dass er die unerfüllbaren dokumentarischen Forderungen der Wasserfallmodelle, zu denen er das V-Modell sicherlich auch zählen würde, erkannt hat.

Legendär ist schon die „Waterfall“ Konferenz-Website https://www.waterfall2006.com/. Eine „Fake“ Seite, die das klassische Software Engineering, also nach V-Modell, gehörig aufs Korn nimmt.

Im dritten Teil dieses Triablogs gehe ich daher auf die heute vor allem in der SW System Entwicklung gedachten und angewendeten Vorgehensweisen ein, die sich aber auch in anderen technischen Entwicklungsdomänen schon bewährt haben.

Mehr dazu kann ich Ihnen auch auf dem Kongress zu Requirements Engineering, der REConf 2019 in München erzählen.

Möchten Sie mehr zum Thema “Anforderungen” erfahren? Dann empfehle ich Ihnen auch, eines unserer beliebten Trainings zum Requirements Engineering oder Agile zu besuchen.

Series Navigation

<< Triablog V-Modell Teil 1: Das V entstehtTriablog V-Modell Teil 3: Das V-Modell ist tot, es lebe Scrum! >>