Freitag, 14. August 2015

Ein Produkt ist ein Produkt und ein Projekt ist ein Projekt.

Prozessübersicht Softwareentwicklung: Produkte

Es gibt Unternehmen, in denen werden zwar Produkte erstellt, deren Umsetzung erfolgt jedoch ausschließlich auf Projektebene. Es existiert also ein Produkt für eine Vielzahl von Kunden, eine Planungsebene für das Produkt gibt es jedoch nicht. Aus Kostengründen werden nur Projektbeauftragungen einzelner Kunden umgesetzt. Diese werden einzelnen Entwicklern oder kleinen Entwicklergruppen übertragen. Eine organisierte Abstimmung in Bezug auf das Produkt entfällt. Flur- und Zimmergespräche ersetzen notwendige Planungsaufgaben. Das ganze Problem verschlimmert sich, wenn es im Unternehmen nicht nur ein Produkt, sondern mehrere Produkte gibt. Am Ende haben wir eine projektgetriebene, konfuse Einzelentwicklung hin zu seltsamen Produkten.

Aber was soll so schlimm daran sein? Ohne Requirements Engineering und Softwarearchitektur auf produktübergreifender Ebene sowie auf Produktebene gibt es keine allgemeingültigen Abstraktionen. Es kommt zu Doppelentwicklungen, weil die eine Hand von der anderen nichts weiß. Es kommt zu einem Technologiemischmasch und Schwierigkeiten, wenn einer dieser Wissenden das Unternehmen verlässt. Der angeblich kostengünstige Verzicht auf Abstimmung erzeugt also immense Mehrkosten, die diesen Unternehmen nicht klar sind. Aus welchen Gründen auch immer sind solche Unternehmen auch nicht bereit, über Ursachen und Wirkungen zu reflektieren.

Marktstrategen behaupten nun, solche Firmen werden vom Markt bereinigt. Bereinigt heißt natürlich, es werden Menschen entlassen. Man muss sich umorientieren. In einer Gesellschaft, in der die Existenz an den Job gebunden ist, ist das keine leichte Sache. Es wäre eigentlich leichter, die Managementprozesse in diesen Firmen zu verbessern. Leider fehlen oft das soziale Gewissen und die soziale Einsicht für solche Änderungen. Auf der anderen Seite laufen solche Firmen erstaunlich gut. Viele verdienen sogar jede Menge Geld. Kapitalistische Wirkmechanismen sind nicht so wirksam, wie manche Leute glauben. Man schafft sich Nischen gegen Konkurrenzmechanismen, in die neue kleine Firmen kaum eindringen können. Langfristige Geschäftsbeziehungen, Freundschaften auf der richtigen Ebene und kleine Aufmerksamkeiten ersetzen gute Produkte und effiziente Entwicklungsmethoden. Beziehungen sind das halbe Leben. Besser getarnt kann man auch Networking dazu sagen.

Doch nun zu Möglichkeiten, wie man seine Produktentwicklung verbessern könnte. Eine Unterteilung der Entwicklung in Teams, die sich um bestimmte Domänen kümmern, wäre ein Weg. Ein jedes dieser Teams ist verantwortlich für bestimmte Teilgebiete der Fachdomäne. In Bezug auf diese Teilgebiete werden Fachmodule entwickelt. Zur Arbeit des Teams gehören alle Teilbereiche der Entwicklung: Requirements Engineering, Softwarearchitektur, Realisierung und Tests. Diese Komponenten werden so erstellt, dass sie in verschiedenen Varianten anwendbar sind. Auf diese Art und Weise kann ich später Produkte durch unterschiedliche Varianten dieser Komponenten zusammenstellen. „Variabilität ermöglicht die Definition und Realisierung unterschiedlicher Produkte durch Auswahl von Varianten aus einer vorgegebenen Menge von Varianten." [S.650, POHL08]



An dieser Stelle können wir uns fragen, wo dieses Zusammenstellen der Komponenten zum Produkt erfolgt. [POHL08] unterscheidet zwischen Domänen-Engineering und Applikations-Engineering. "Im Domänen-Engineering wird Entwicklung für die Wiederverwendung betrieben. Im Applikations-Engineering wird Entwicklung mit Wiederverwendung betrieben." [S.650, POHL08] Es gibt also einen Verantwortungsbereich, der wiederverwendbare Komponenten erstellt und einen anderen Verantwortungsbereich, der diese Komponenten zum Produkt zusammenstellt. Diese Verantwortungsbereiche sollten, zumindest mental, streng getrennt sein.

Eine notwendige Denkleistung ist das Herausfinden von Gleichem und die Separierung von Unterschieden. Diese Unterscheidung beginnt bereits im Requirements Engineering und muss bis in den Code fortgeführt werden. Die Unterschiede müssen genau beschrieben werden. Es muss beschrieben werden, was variiert (Variationspunkt) und wie etwas variiert (Varianten). Im Applikations-Engineering müssen wir zudem wissen, wer mit wem zusammenarbeiten darf oder muss. Das nennt man Variabilitätsabhängigkeit. Nicht jede Komponente kann mit jeder Komponente interagieren. Die Abhängigkeiten zwischen Komponenten sollten in jedem Fall minimiert werden. Trotzdem wird sich diese Komplexität nicht beseitigen lassen, weder im fachlichen Zusammenspiel der Komponenten, noch aus historischen Gründen. (deprecated, zu alte Versionen, …)

Wie findet man solche Unterschiede? Das Requirements Engineering im Domänenmanagement nimmt Anforderungen auf. Diese Anforderungen werden in Bezug auf die Systemkonstellationen untersucht. Dazu kann man eine Systemanforderungsmatrix erstellen. "Als Spalten sind die unterschiedlichen Systeme aufgeführt. Diese Systeme sind entweder existierende Systeme oder Systeme, die in der Zukunft auf der Basis der Produktlinie erstellt werden sollen. Die Zeilen repräsentieren die Produktlinienanforderungen." [S.664, POHL08] "Enthalten Produktlinienanforderungen selbst noch Variabilität, so ist es für den Aufbau einer Systemanforderungsmatrix zweckmäßig, die betrachteten Anforderungen zu verfeinern. Bei der Verfeinerung wird aus jeder Variante, die in der Anforderung enthalten ist, eine eigene Produktlinienanforderung." [S665, POHL08]



Auf die beschriebene Weise wird Variabilität ermittelt. Die ermittelten Zusammenhänge müssen dokumentiert werden. Dokumentationsanforderungen im Domänen-Engineering sind andere als im Applikations-Engineering. Im Domänen-Engineering dokumentiere ich die Anforderungen auf der Ebene des Fachmoduls. Ich finde beschriebene Variationspunkte und Varianten. Im Applikations-Engineering wird das Zusammenspiel beschrieben. Wer kann mit wem kombiniert werden und warum.

Das Domänen-Engineering und das Applikations-Engineering beinhalten unterschiedliche Aktivitäten. Sie benötigen aus diesem Grund ein ebenso unterschiedliches Management. "Das Produktmanagement befasst sich mit der Planung, Organisation, Ausführung und Kontrolle aller Aufgaben, die auf die erfolgreiche Entwicklung und Vermarktung einer Produktlinie sowie deren verschiedener Systeme abzielen." [S.660, POHL08] Eine Produktlinie ist die Zusammenfassung von Produkten und deren verschiedenen Ausprägungen unter einem Dach. Das Produktmanagement ist also für das große Ganze zuständig. Genau auf diese Art des Managements wird in dem eingangs beschriebenen Szenario verzichtet. Man herrscht über eine Reihe von Projektmanagements, die keiner wirklich koordiniert.

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

Kommentare:

  1. Das Ergebnis eines Projekts ist immer ein Produkt.

    AntwortenLöschen
  2. Der Text ist hervorragend. Ich glaube, wenn die Angst vor Requirement Engineering schwindet (bei den Autobauern erzeugt DOORS die größte Angst) und wenn man die Formulierungen übt und nicht Requirements mit Pflichtenheft verwechselt, ist viel Spuk vorbei.
    Sobald Hardware mit im Spiel ist, genügt es dann aber nicht, Nachhaltigkeitsfragen, Sicherheitsthemen und Umweltschutz bei der Entwicklung nur den Chinesen zu überlassen.

    AntwortenLöschen
  3. Sehr guter Blogbeitrag. Im Alltag gibt es aber doch viele Graustufen zwischen Projekt (= In Reinform eine einzelne Auftragsentwicklung für einen Kunden) und Produkt. Von daher sind die Konsequenzen die zu ziehn sind gar nicht so einfach. Aber viel wäre schon gewonnen, wenn alle die das Thema betrifft, sich das beschriebene Problem bewusst machen würden.

    AntwortenLöschen
  4. Guter Artikel. Am Wichtigsten ist immer die Planung, also die Unternehmensplanung. Ohne gründlicher Planung sind Unternehmen gleich zum Scheitern verurteilt.

    AntwortenLöschen