Die Erstellung der Software wird zunehmend ein Kostenfaktor in Unternehmen. KMU können davon in besonderem Maße betroffen sein. Neben dem Einsatz der finanziellen Ressourcen spielen die knappe Verfügbarkeit fähiger Mitarbeiter und Time-to-Market eine wichtige Rolle.

Während in der industriellen Fertigung die Skalierungseffekte in der Regel positiv sind, (größere Stückzahlen führen zu niedrigeren Stückkosten), beobachtet man in der Softwareentwicklung einen gegenteiligen Effekt: je größer das Projekt, desto höher der Verlust durch Kommunikation und Koordination.

Je kleiner das Unternehmen und die IT-Abteilung, desto höher ist im Allgemeinen die natürliche Transparenz und desto direkter und gezielter die Steuerung vom Management. In größeren Unternehmen kann es hier jedoch schnell zu Defiziten kommen, wenn nicht durch eine aktive Governance der Software-Entwicklung gegengesteuert wird. Es gibt eine ganze Reihe von Optimierungsmöglichkeiten, wie z. B. die Verbesserung der Prozesse, Automatisierung, Transparenz sowie Portfoliosteuerung. Die folgende Liste erhebt keinen Anspruch auf Vollständigkeit, beinhaltet jedoch wesentliche Aspekte; im Einzelnen:

Verbesserung der Prozesse

Über den richtigen Prozess bei der SWE wird seit Jahrzehnten nachgedacht. Durch die agilen Methoden ist in den letzten Jahren wieder Bewegung in die Diskussion gekommen. Eine Vorgehensweise ausschließlich nach Wasserfallmodell ist heute nur noch selten anzutreffen. Die Regel ist ein mehr oder weniger ausgeprägtes iteratives Vorgehen in der Entwicklung. Eine Folge dieser höheren Dynamik ist die Zersplitterung der Dokumente. So wird z. B. anstatt eines abgenommenen und in Stein gegossenen Anforderungsdokuments heute mit Listen gearbeitet, die immer wieder geändert und umgeordnet werden. Zugleich steigen die Anforderungen an die Nachverfolgbarkeit und Nachweisbarkeit im Entwicklungsprozess.

Das führt dazu, dass heute ein größeres SWP gleichzeitig auch ein Dokumentations- und Versionierungsprojekt ist. Es gibt Geschäftsvorgaben, Produktpläne, Analysedokumente, funktionale Anforderungen, nicht-funktionale Anforderungen, Architekturen, Designdokumente, Entwicklungspläne, Entwicklungsaufträge, Änderungsaufträge, Entwicklerdokumentationen, Buildreports, Testpläne, Testfälle, Testreports und vieles mehr. Und zwischen all diesen Artefakten gibt es Verknüpfungen. Wir stoßen hier an die Grenzen dessen, was noch mit herkömmlichen Office-Dokumenten zu leisten ist. Wir benötigen stattdessen dedizierte Repositories, deren Artefakte untereinander verlinkt werden können, ähnlich wie die Inhalte eines Web-Portals miteinander verlinkt sind.

Automatisierung

Automatisierung in der SWE ist kein leichtes Thema, aber lohnend. SWE ist keine Fließbandarbeit, trotzdem gibt es repetitive Tätigkeiten, die automatisiert werden können. So gibt es beispielsweise für die Testausführung inzwischen ausgereifte Werkzeuge, die einen einmal durchgeführten Testfall aufzeichnen und automatisch auf Knopfdruck wiederholen. Auch können wir heute mit entsprechenden Werkzeugen immer mehr Codes aus Modellierungssprachen heraus automatisiert generieren.

Außerdem können wir durch Integration der Werkzeuge fehleranfällige und aufwändige Doppeleingaben weitgehend vermeiden. Allerdings ist gerade für kleinere Entwicklungsabteilungen der Integrationsaufwand zu hoch, hier benötigen wir Werkzeuge, die wirklich leicht integrierbar sind oder schon vom Hersteller integriert wurden.

Transparenz

Für eine sorgfältige Projektsteuerung sind vielfältige Kennzahlen notwendig, z. B. über den Fertigstellungsgrad bestimmter Artefakte, Fehlerhäufigkeiten und ähnliches.

In kleinen Teams lässt sich Transparenz noch relativ einfach herstellen. Die agile Methode SCRUM z. B. arbeitet viel mit Whiteboards, Kärtchen und Pinnwänden. Bei anderen Verfahren oder bei größeren bzw. verteilten Projekten behilft man sich dann mit teilweise sehr umfangreichen Spreadsheets (Projektmanagement by Excel). Nachteil ist der doch erhebliche Verwaltungsaufwand, die Tabellen aktuell zu halten und auszuwerten. Besser ist es, auch hier zu automatisieren. Die Informationen zur Berechnung der Kennzahlen sollten möglichst direkt am Entstehungsort automatisiert von den Werkzeugen erfasst werden.

Also zum Beispiel Informationen zu Anzahl und Zustand der Anforderungen im Anforderungsmanagement-Werkzeug, Informationen zur Testabdeckung, Fehlerraten usw. im Qualitätsmanagement-Werkzeug. Um diese Informationen auch miteinander zu verknüpfen und in Beziehung zu setzen, ist der Einsatz eines Entwicklungs-Datawarehouse sinnvoll. Mit dessen Auswertemöglichkeiten (Reports, Dashboards) können die Informationen ohne großen Aufwand übersichtlich aufbereitet werden.

Portfoliosteuerung

Es ist nicht nur wichtig, die Projekte richtig durchzuführen, es ist vor allem wichtig, die richtigen Projekte durchzuführen. Natürlich sollten wir die Projekte auswählen, die den höchsten ROI versprechen. Wie findet man diese Projekte? Dazu bedarf es einer sorgfältigen Projekt/Produkt-Portfoliosteuerung. Um hier den Überblick zu behalten und die richtigen Entscheidungen zu treffen, kann eine Produkt- und Portfoliomanagement-Datenbank hilfreich sein. Damit ist dann auch eine projektübergreifende Planung der finanziellen und personellen Ressourcen möglich.

Das Team

All diese Maßnahmen zur Verbesserung der Software-Entwicklungs-Ökonomie stehen und fallen mit dem Team. Neben einem guten Team sind ein kooperativer Führungsstil, möglichst wenig Bürokratie sowie flache Hierarchien Erfolgsfaktoren.

Dazu hat in den vergangenen Jahren der Gedanke der agilen Softwareentwicklung viel Aufklärungsarbeit geleistet und erhebliche Fortschritte gebracht. Ideen wie selbstorganisierende Teams werden ausprobiert. Bei der Umsetzung dieser Ideen tun sich naturgemäß kleinere Teams leichter. Das beschränkt sich allerdings nicht auf kleine Unternehmen, man findet auch in Großunternehmen agile Keimzellen.

Noch Schwierigkeiten bereitet oft die Übertragung dieser Ideen auf große Projekte. IBM zeigt seit Jahren mit der Entwicklung von Eclipse, dass der agile Gedanke auch bei verteilten Großprojekten seine Berechtigung hat. Allerdings reichen hier eine Pinnwand und Kaffeeecken zur Diskussion nicht aus. Eine Unterstützung durch Werkzeuge mit ausgeprägten Kollaborationseigenschaften ist unbedingt notwendig.

Sourcing Model-Strategie

Selbst Großunternehmen sind heute nicht mehr der Meinung, alles selber machen zu müssen. „Rückzug auf Kernkompetenz“ ist das Schlagwort, abnehmende Fertigungstiefe und zunehmende Arbeitsteilung zwischen unabhängigen Firmen sind die Folgen. Und das gilt für MU umso mehr.

Ähnliche Tendenzen gibt es auch bei der Software-Entwicklung. Das bedeutet, dass die Eigenentwicklung zurückgeht zugunsten standardisierter Kaufsoftware (z. B. Siebel, SAP), dass zunehmend OpenSource eingesetzt wird, dass die Entwicklung einzelner SW-Module nach außen vergeben wird oder manchmal sogar die komplette IT outgesourced wird.

Dort, wo aber immer noch selbst entwickelt wird, weil z. B. die Software zur Maschinensteuerung nur in ganz enger Abstimmung mit der Hardware und Mechanik entwickelt werden kann, oder weil ganz spezifische Unternehmensprozesse unterstützt werden müssen, sollte man zumindest darüber nachdenken, ob Aufbau und Pflege der Entwicklungsumgebung wirklich mit den eigenen knappen Ressourcen bewerkstelligt werden müssen.

Alternativen sind der Kauf von bereits vorintegrierten Werkzeug-Suiten oder sogar das Outsourcing des Betriebs der Entwicklungs-Umgebung. Die dabei freiwerdenden Mitarbeiter können dann ihr firmenspezifisches Wissen voll in die Entwicklung der Software stecken, ohne von Aufgaben rund um Integration und Betrieb der Werkzeuge abgelenkt zu werden.

Zusammenfassung

Für eine moderne, ökonomische SWE müssen viele Aspekte berücksichtigt werden und es gibt eine Reihe von Erfolgsfaktoren. Es zeigt sich aber auch, dass die Komplexität ohne geeignete und integrierte Werkzeuge nicht mehr effizient zu bewältigen ist. Mit seinen integrierten, jazz-basierten Werkzeugen bietet IBM gerade auch dem Mittelstand eine Alternative zu dem herkömmlichen do-it-youself-Ansatz.

Dabei kann der Kunde wählen, ob er die Werkzeuge selbst betreiben will oder von IBM aus einer dynamischen Infrastruktur (Cloud) beziehen will.

IBM Deutschland GmbH, Ehningen
www.ibm.de