Neue Herausforderungen für den Markt

Gerhard Versteegen

Offshoring und Nearshoring - zwei Begriffe, die sich im Tagesgeschäft der IT ständig wiederfinden. Der Hintergrund beider Begriffe lässt sich etwas überspitzt wie folgt darstellen: Durch kostenbedingtes Outsourcing wird ein Software-Entwicklungsvorhaben in Indien oder im Osten durchgeführt, wo die Tagessätze der Informatiker vergleichbar zu den Stundensätzen hierzulande sind.

Allerdings hat die Erfahrung der letzten Jahre gezeigt, dass das doch nicht ganz so einfach ist, wie es klingt. Immer häufiger will man nicht 100% der gesamten Entwicklung outsourcen - immer häufiger verlässt man sich nicht auf nur einen Partner sondern will mehrere Unternehmen integrieren - immer häufiger will man selbst kontinuierlich involviert sein.

Ein weiteres Szenario der verteilten Entwicklung sind Unternehmen, die selber an verschiedenen Standorten Software erstellen oder auch Software Projekte, die von einer Vielzahl von Unternehmen parallel abgewickelt werden. Somit haben wir drei Facetten der verteilten Entwicklung vorliegen, für die im Wesentlichen die gleichen Herausforderungen existieren.

Um eins gleich vorweg zu nehmen - die mit Abstand größte Herausforderung, die es bei verteilter Entwicklung zu bewältigen gilt, ist die Überbrückung kultureller Unterschiede sowie die Harmonisierung der Kommunikation zwischen allen Beteiligten. Ersteres kann kein Tool der Welt lösen - hier ist einzig und alleine der menschliche Faktor ausschlaggebend - zweiteres kann toolgestützt unterstützt, aber nicht gelöst werden! Das soll heißen: Werkzeuge zur Kommunikationsunterstützung sind zwingende erforderlich - aber nicht ausreichend! Das wichtigste ist der implementierte Prozess! Und diesen kann man nirgendwo "von der Stange" kaufen - der muss individuell eingerichtet werden.

Eine derartige Prozesseinführung ist teuer - darüber muss man sich bewusst sein - und sie lebt, das heißt, sie wird kontinuierlich angepasst (verbessert). Hier den optimalen Partner zu finden, der einen dabei unterstützt, ist Vertrauenssache und sollte gut überlegt sein.

Differenzierungen

Bei der eigentlichen verteilten Entwicklung selbst sind hinsichtlich zeitlicher Aspekte die folgenden Arten zu unterscheiden:

• Entwicklung innerhalb einer Zeitzone,
• Entwicklung innerhalb mehrer Zeitzonen.

Bezüglich der Datenhaltung ist zu unterscheiden zwischen:

• Verteilter Datenhaltung jeweils beim zuständigen Entwicklungsteam,
• Zentraler Datenhaltung an einem Standort (wo auch immer!).

Die nächste Unterscheidung ist zu treffen bezüglich:

• Entwicklung hinter einer Firewall (also klassische Entwicklung innerhalb eines Unternehmens),
• Entwicklung vor einer Firewall (das ist die echte Herausforderung, tritt auf bei einem Entwicklungsvorhaben, wo mehrere Firmen beteiligt sind).

Sicherlich lässt sich noch eine ganze Fülle weiterer Unterscheidungsmerkmale finden, doch soll an dieser Stelle der Fokus auf diesen drei Aspekten liegen. Die Unterscheidung bei den Zeitzonen ist in erster Linie lizenzrechtlich zu beachten, so haben "clevere" Hersteller mittlerweile die entsprechende Verdreifachung des Lizenzpreises vorgesehen, wenn Ihre Produkte für derartige Projekte benutzt werden.

Aber auch regelmäßige Statusgespräche übers Web gestalten sich immer schwieriger, desto mehr Zeitzonen betroffen sind. Dies hat unmittelbare Auswirkungen auf die Entscheidungsfähigkeit innerhalb eines Projektes, was gerade zu Projektbeginn Konsequenzen hat. Das Anforderungsmanagement muss daher über eine entsprechende Toolunterstützung verfügen, Mehrsprachigkeit des einzusetzenden Werkzeugs wäre ein wichtiges Feature. Derzeit bietet hier QA Systems mit dem Produkt IRqA (siehe Abbildung 1) ein entsprechendes Werkzeug an, das insbesondere im Bereich der verteilten Entwicklung prädestiniert ist.

Bei der Datenhaltung sind in erster Linie Performanceaspekte zu berücksichtigen. Klassische Client Server Lösung kommen hier schon ins Trudeln, wenn die Datenhaltung nicht ebenfalls verteilt wird. Hier bieten sich dann eher moderne webbasierte Systeme an. Mittlerweile findet man hier auch im Open Source Bereich Lösungen, so zum Beispiel Subversion von CollabNet. Inzwischen ist Subversion zum offiziellen Nachfolger der OpenSource CVS geworden, CollabNet bietet da zur Source Code Verwaltung mittlerweile auch eine kommerzielle Software an, die sich für verteilte Entwicklung bei zentralisierter Datenhaltung anbietet. Der Kick hier: Die Software wird als SaaS (Software as a Service) angeboten - man investiert also nur während der Nutzungszeit. Ein Modell, was in den USA schon verbreitet ist, in Europa aber noch in den Kinderschuhen steckt.

Will man hinter der Firewall bleiben, so bietet sich hier Polarion an, ein Newcomer auf dem Markt, der durch seinen rein webbasierten Ansatz sowie die wahlweise Nutzung von der Open Source Subversion oder SAP NetWeaver auf sich aufmerksam macht. Besonders die Integration von Anforderungsmanagement, Projektmanagement und Konfigurationsmanagement stellt hier eine interessante Alternative dar. Besonders hilfreich beim Einsatz in verteilten Projekten ist der in Abbildung 2 dargestellte Dashboard, das dem Projektmanager einen guten Überblick über den aktuellen Entwicklungsstand in verteilten Projekten gibt.

Der dritte Knackpunkt bei der verteilten Entwicklung stellt das Thema Sicherheit dar. Wie sicher sind meine Daten, wenn sie außerhalb der Firewall liegen? Sind sie doch noch nicht mal hinter der Firewall zu 100% sicher, wie sieht es dann erst vor der Firewall aus? Können militärische Projekte, die natürlich erhöhten Sicherheitsanforderungen unterliegen, jemals auf diese Art und Weise abgewickelt werden? Ist Industriespionage damit Tür und Tor geöffnet? Alles Fragen, auf die in naher Zukunft eine Antwort gefunden werden muss, da ansonsten dem Thema verteilter Entwicklung seitens der Security ein Riegel vorgeschoben werden wird.

Programmierrichtlinien und Modelle

In der Automobilbranche zum Beispiel haben sich Programmierrichtlinien mittlerweile etablieren können, MISRA-C ist hier ein Standard. Entsprechende Werkzeuge wie QA-C (ebenfalls von QA Systems) überwachen die Einhaltung solcher Programmierrichtlinien. Für die verteilte Entwicklung sind Programmierrichtlinien ein Muss - doch die Realität sieht leider noch anders aus. Die Vorschrift der Einhaltung von Programmierrichtlinien gehört allerdings auch zu den eingangs erwähnten Elementen einer Prozesseinführung. Ebenso wie die Dokumentation - und die bitte nicht auf indisch, polnisch oder welche Sprache auch immer - Modelle sind hier gefragt! Mit der Unified Modeling Language 2.0 steht hier eine Sprache zur Verfügung, die zwar mittlerweile extrem mächtig geworden ist, doch wer verteilte Entwicklung nicht modellgetrieben vornimmt, wird auf kurz oder lang scheitern! Im Modellierungsbereich selbst existiert eine Vielzahl von Werkzeugen, die wichtigsten wurden in der jüngsten Studie der iX [1] getestet.

Literatur:

[1] Gerhard Versteegen, Hrsg.; Bernd Oestereich, Tim Weilkiens, Fabrizio Ferrandina, Dr. Christoph Bröcker: Bessere Software, Heise 2005