Die in vielen Unternehmen laufende Diskussion um die IT-Vollkosten führt unter anderem zu folgendem Ergebnis: Das Ziel eines Entwicklungsprojekts darf heute nicht nur die Lieferung eines hochwertigen Ergebnisses sein. Es reicht auch nicht, dass es die Erwartungen des Markts oder des Kunden erfüllt. In die Erfolgsrechnung einfließen müssen ebenso die fortgesetzte Pflege und Wartung des realisierten Systems, sprich: der Produktlebenszyklus. Der Begriff des Anforderungs-Managements (siehe auch: "Aus Beschaffung wird Beratung") zielte bislang nur auf den Projektstart. Er ist nun auszudehnen.

Verschärfte Rahmenbedingungen

Einem IT-Verantwortlichen kann ein Entwicklungsprojekt vorkommen wie die Quadratur des Kreises: In funktionaler Hinsicht werden von ihm immer komplexere und leistungsfähigere Systeme erwartet. Organisatorisch ist er gefordert, die Kosten mit Hilfe von Offshoring- und Outsourcing-Konstruktionen einzugrenzen (siehe beispielsweise: "Sinkende Preise – auch im Outsourcing"). Die diversen Einsatzszenarien im globalen Wettbewerb erfordern kürzere Realisierungszeiten sowie die Erfüllung rasch wechselnder Anwenderwünsche.

Können die Unternehmen unter diesen Rahmenbedingungen darauf vertrauen, dass die von den Mitarbeitern in irgendwelchen Tabellen notierten Anforderungen durch die jeweils Zuständigen schon richtig bearbeitet werden? Wer das tut, handelt mehr als leichtfertig. Ohne klare Vorgaben und ein hohes Maß an Einheitlichkeit droht das in den Anforderungen Spezifizierte früher oder später im Laufe der Entwicklungsphase rettungslos unterzugehen.

Was Projekt-Management-Tools (nicht) können

Hochkomplexe Szenarien aus Features, Optionen und Priorisierungen erfordern den begleitenden Einsatz von Werkzeugen. Im Hinblick auf eine stringente Softwareentwicklung reichen die weithin bekannten Tools für das Projekt- und Portfolio-Management aber nicht aus.

Produkte wie Microsoft Project Server, SAP DVS, SAP xRPM, Artemis 7 oder Doors unterstützen den Anwender, indem sie mit Hilfe von Attributen fachliche Zuordnungen darstell- und verfolgbar machen. Sie ermöglichen ihm, Projekte – auch Teilprojekte und Arbeitspakete – zu terminieren und zu budgetieren sowie ein effizientes Controlling zu praktizieren.

Diese Werkzeuge sind jedoch nicht in der Lage, funktionale Erwartungen als Prozesse darzustellen. Geschweige denn, aus diesen Prozessen Anforderungen für die weiteren Phasen eines Projekts bis hin zur Abnahme und Wartung abzuleiten und weiterzugeben beziehungsweise zu empfangen.

Gute Anforderungs-Management-Tools sorgen dafür, dass die Anforderungen nicht nur aufgenommen, sondern auch von der Abbildung der Geschäftsprozesse bis zur Codegenerierung durchgereicht werden. Und ein ganzheitliches Anforderungs-Management adressiert nicht nur die erste Phase eines Entwicklungsprojekts, sondern auch die weiteren Stufen der Softwareentwicklung.

Das modellbasierende Verfahren

Ganzheitlich ist ein Anforderungs-Management, wenn es die Anforderungen als technische Merkmale funktional – in Form von Use-Cases – darstellt und bis auf die Datenebene hinunter projiziert. Damit die Kernbestandteile einer Software möglichst lange nutzbar sind, werden die Anforderungen am besten von Anfang an im Kontext eines modellbasierenden Verfahrens gemanagt. Aus den Modellierungsergebnissen einer Phase lassen sich dann in der Folgephase konsistente Modelle ableiten.

Die Konsistenz, die ein solcher modellgestützter Ansatz garantiert, ist auch deshalb von Bedeutung, weil heute sowohl auf Fach- wie auf IT-Seite verteilte Teams die Regel sind. Um einen schlüssigen Arbeitsstand zu erreichen, müssen die Teammitglieder dafür sorgen, dass ihre Arbeiten an den Teilmodellen stets zusammenpassen. Nur mit einer zentralen Datenhaltung ist im Fall von Änderungen an den Anforderungen, beispielsweise am Geschäftsprozessmodell, eine unmittelbare Harmonisierung mit dem zugehörigen Objekt- oder Datenmodell möglich.

Eine SOA (Service-orientierte Architektur) mit wiederverwendbaren Services erfordert in allen Phasen der Entwicklung nachvollziehbare und dokumentierte Entscheidungen, die laufend in einem gemeinsamen Repository hinterlegt werden. (Mehr zum Thema SOA und Modelle unter: "Reduzierte Komplexität") Auch die immer relevanter werdenden Offshoring- und Outsourcing-Szenarien benötigen Transparenz über alle an einem Projekt beteiligten Disziplinen hinweg. Der Nutzen eines ganzheitlich definierten Anforderungs-Managements liegt damit auf der Hand.

Neues von der SAP

Neuerdings spricht sich auch die SAP für den modellgetriebenen Ansatz aus. Seit Jahren dienten die SAP-Referenzmodelle im Werkzeug "Aris" von IDS Scheer vor allem dazu, die Geschäftsprozesse zu dokumentieren. Nun sollen die Modellierungsobjekte für Neuentwicklungen ("Composites" genannt) direkten Bezug zur Applikation erhalten.

Die SAP hat Anstrengungen unternommen, ihr "Enterprise Service Repository" auf dem Standard BPMN (Business Process Modeling Notation) aufzusetzen (siehe auch "SOA und BPM konvergieren"). Anlässlich seiner Anwenderkonferenz im vergangenen Mai hat der Softwareanbieter angekündigt, auf das hauseigene Paket zur Abbildung von Prozessen (den unter Netweaver geführten Solution Manager) einen neuen Layer zur Umsetzung der Orchestrierungssprache BPEL (Business Process Execution Language) aufbringen zu wollen. Die SAP-eigene BPEL-Engine soll sich der BPMN bedienen, um horizontale wie vertikale Web-Services zu komponieren.

Bislang erlaubte das in Netweaver enthaltene "Composite Application Framework" nur ansatzweise, die Funktionen der zugrunde liegenden IT-Systeme in Web-Services zu kapseln. Stand der SAP-Technik ist heute, eine Standardarchitektur für Bedienoberfläche und Prozesssteuerung zu implementieren und über eine Objektzugriffsschicht die entsprechenden Repositories aus den zugrunde liegenden Systemen herauszugreifen. Diese Objektzugriffsschicht ist eine zentrale Schnittstelle, die es ermöglicht, die Kommunikation mit den teilnehmenden Systemen über Web-Services und die "Netweaver Exchange Infrastructure" (XI) zu steuern.

Die Unified Modeling Language

BPMN generiert den Web-Service und konzentriert sich auf die Geschäftsprozesssicht. Umsetzen lässt sich der Web-Service mit der Unified Modeling Language (UML), einer international standardisierten Sprache zur Spezifikation, Visualisierung und Dokumentation im Rahmen der Softwareentwicklung. Dabei heißt umsetzen, im Systemumfeld Ergebnisse erzeugen, die auch der auf diverse Artefakte (wie Dokumentation, Code, Objektmodelle) zielende Entwickler verwenden kann. (Mehr zum Thema finden Sie unter "UML eignet sich auch für komplette Systeme".)

Die UML wird derzeit häufig kritisiert, weil die Version 2.0 noch komplexer ist als die frühere Ausführung der Sprache, weshalb sie umfangreiche Kenntnisse vom Entwickler verlangt. Der Nürnberger Softwarehersteller MID begegnet diesem Problem, indem er den Anwendern seines Werkzeugs "Innovator" die Möglichkeit gibt, eine unternehmensspezifisch angepasste Modellierungssprache auf UML-Basis zu definieren (im Fachjargon "Domain-specific Language" genannt). Die Komplexität der UML wird dabei mit Hilfe von Profilen eingegrenzt. Eine geringere Komplexität führt zu belastbareren Resultaten und sichert ein hohes Maß an konzeptioneller Gleichförmigkeit. Die Mitarbeiter kommen zudem mit weniger Detailkenntnissen aus.

Die Vorteile eines durchgängigen Modells

Ein solches Werkzeug macht die Abbildung von Geschäftsmodellen in einer anderen Notation überflüssig. Das durchgängige semantische Modell erleichtert auch die Weitergabe der Informationen aus den Anforderungen. Produkten wie IBM Rational, Eclipse UML oder dem UML Designer von Aris, um einige der bekannteren zu nennen, fehlt es hier noch an der einen oder anderen Facette. Auch "Borland Together" geht in der Profilbildung nicht weit genug.

Die Kombination aus konsequenter Methodik und optimierten Werkzeugprofilen spart dem Anwender den Bereinigungsaufwand, der anfällt, wenn mehrere ähnliche Modelle mit unterschiedlichen Konstrukten verwendet werden. Zudem werden die Entscheidungsprozesse entlang dem Modell schlanker. Es entfallen die Abhängigkeiten von "Experten", die gern neue Details einbringen, ohne sie zu hinterlegen. Darüber hinaus lassen sich eventuelle Werkzeugübergänge auf sichere Weise managen. Lösungen, die sich als Irrwege herausstellen, können von einem beliebigen Punkt an neu aufgesetzt werden. Damit sind Effizienzsteigerungen von 30 Prozent des üblichen Projektaufwands möglich – gerechnet in Mitarbeiterstunden, Laufzeit, Modellanzahl pro Wertschöpfungsstufe etc.

Nicht jeder Werkzeughersteller hat es bislang geschafft, eine komplexe Applikationsentwicklung in einen planbaren, messbaren und transparenten Geschäftsprozess zu transformieren. Die SAP scheint hier auf einem guten Weg zu sein. MID und Borland haben viele der notwendigen Hausaufgaben bereits erledigt. (qua)