EFFIZIENTE UNDHOCHQUALITATIVE SOFTWAREENTWICKLUNGEinsatz von Enterprise Architect von SparxSystems,einem Modellierungswerkzeug, das den komplettenProjektzyklus abdeckt

den und zum Selbstzweck entarten.Systeme und Projekte sind komplex.Vereinfachende Aufbereitung ist notwen-dig. Das Verständnis der Entscheidungs-träger für die Inhalte und ihre Zeit, die sieden Unterlagen und dem Projekt widmenkönnen, sind begrenzt.

Sind Vereinfachung und Strukturierungmöglich? Verschaffen wir uns mit Hilfe vonAbb. 1 einen Überblick!

ModellierungswerkzeugeZunächst fällt auf, dass Modellierungs-werkzeuge mit ihren Standards Sprachenund keine Prozesse darstellen. UML 2.1(Unified Modeling Language, www.uml.org)ist eine Sprache, sie definiert Symbole,

Professionelle Softwareentwicklung ist ein arbeitsteiliger Prozess, an den hoheQualitätsanforderungen gestellt werden. Anforderungserhebung, Anforderungs-management, Systemarchitekturplanung, Systementwurf, Implementierung,Testen und Ausführungsplanung unterliegen einer immer strengeren Standardi-sierung. Kontinuierlich aktuell gehaltene Dokumentation, zeitparalleles Arbeiten imTeam, Qualitätskontrolle, Nachvollziehbarkeit der Abdeckung von Anforderungen,Abschätzung und Handhabung von Risiken, Ressourcenplanung, Versionierungund transparentes Projektmanagement sind notwendige Anforderungen. DieseFunktionen und die logischen Vernetzungen (alle lösungs- und projektrelevantenAbhängigkeiten) in einem Werkzeug zu konzentrieren, beschleunigt und erleichtertdie Projektumsetzung wesentlich. Enterprise Architect bietet diese Leistung zugünstigen Kosten – das gesamte Projektteam kann mit dem Werkzeug ausgestat-tet werden.

Ing. Dietmar Steinpichler(E-Mail: trainer@sparxsystems.at) hatlangjährige, praktische Methoden-erfahrung in architektonischemProjektvorgehen als selbständigerSoftwaredienstleister und Berater. AlsMitarbeiter von mobilkom austria ag hater als Solution Architect mehrereGroßprojekte mit diesem Ansatz analy-siert, spezifiziert, projektleitend betreutund am Lösungsdesign mitgearbeitet. AlsCallcenterspezialist war er an derEntwicklung einer Programmiersprachefür CRM-optimiertes Inbound-Call-Routing spezifizierend beteiligt. Derzeitist Dietmar Steinpichler als SeniorConsultant und Trainer für SparxSystemsSoftware GmbH in Europa tätig.www.sparxsystems.at

tierung? Welche Zusammenhänge bestehenzwischen Anforderungsmanagement, demVorgehen im Entwicklungsprozess und der(objektorientierten) Systemmodellierung?Welche Überlappungen treten auf, bedeu-ten sie Mehraufwand, oder können sie ver-mieden werden? Wie kann die Lesbarkeitvon Anforderungslisten sichergestellt wer-den, wie kann die Übersichtlichkeitgewahrt werden? Was soll ein Werkzeugbieten, das Anforderungsmanagementunterstützt?

Qualitätssicherung ist notwendig. Pro-zessorientierung ist sinnvoll. Modellierungbeschleunigt den Entwicklungsprozess undsichert Wiederverwendbarkeit. Jeder dieserBereiche kann missbräuchlich gelebt wer-

Requirements Management1) bedeutet dieErfassung, Aufbereitung, Abstimmung,Verwaltung, Versionierung und Dokumen-tation von Anforderungen an das zu ent-wickelnde System und die (nachvollziehen-de) Sicherstellung der Abdeckung undEinhaltung der Anforderungen währendeiner Systementwicklung2).

Welchen Nutzen bietet Anforderungs-management? Dient die Auflistung derMerkmale der geforderten Systemlösungnur der Qualitätssicherung im Sinne einerAbsicherung des vereinbarten Liefer-umfangs und der Prüfbarkeit der Erfüllungund damit auch als Abnahmekriterium?Ersetzen Anforderungslisten Ablaufbe-schreibungen, Anwendungsfälle oder garandere Punkte die Anforderungsdoku-mentation? Ist Anforderungsmanagementabhängig vom Bereich und Gegenstand derSystementwicklung (eingebettete Lösun-gen, kaufmännische Applikationen, und soweiter) unterschiedlich zu handhaben?Anforderungsmanagement ist elementarerProzessbestandteil von System-Reifegrad-Modellen – wie ist es optimal in dieAnalysephase einzubinden, oder betrifft esausschließlich Design und Implemen-

der au toradver tor i a l

1

1) Requirements Management und Anforderungs-management werden in gleicher Bedeutung verwendet.

2) Als elementare Prozesse in den Software- undSystem-Reifegrad-Modellen CMMI® und ISO/IEC15504 (SPICE) sowie im Standard ISO/IEC 12207enthalten. Abb. 1: Modellierungssprache, Modellierungswerkzeug und Projektvorgehen

w w w. o b j e k t s p e k r u m . d e

Diagrammtypen für spezielle Zwecke – zurVisualisierung und Dokumentation,Strukturierung, Analyse, Design, und soweiter. Bestimmte Vorgehensweisen imProjekt zu wählen, zum Beispiel anwender-zentriert mit der Erhebung von funktiona-lem Bedarf zu beginnen und dabei auchAnforderungen zu identifizieren, liegt nahe,ist aber keineswegs durch UML vorgege-ben. Modellierungswerkzeuge werden alsoinnerhalb eines Vorgehens, innerhalb einesvon ihnen unabhängigen Systementwick-lungsprozesses eingesetzt. Dieser Prozess-verlauf kann reglementiert und auch zerti-fiziert oder aber dem Projektleiterüberlassen sein.

VorgehensmodelleViele verschiedene Vorgehensmodelle sindverfügbar, werden zumeist heftig diskutiertund mehr oder minder erfolgreich gelebt.Der Marktdruck, eine Zertifizierungvorweisen zu können, motiviert zur Prozess-orientierung. Sicher ist nur: Nicht jede Vor-gehensweise passt zu jeder Aufgabenstel-lung. Rapid Prototyping oder iterativesVorgehen (siehe Abb. 2) werden wahr-scheinlich schlecht zu einem Hochhausbaupassen, Oberflächenoptimierung mit einemstarren V-Modell (siehe Abb. 3) zu betrei-ben, wird auch unbefriedigend sein. Ebensoist offensichtlich, dass Prozessorientierungsehr oft sinnvolle Flexibilität verhindert,weil zumeist schlussendlich nur noch aufdem niedrigsten Detaillierungsgrad – über-blickslos – umgesetzt wird

ProzessrichtlinienBei der Festlegung von Prozessrichtlinienfür Systementwicklungsaufgaben ist alsogroße Vorsicht geboten. Die Idee, miteinem einzigen, standardisierten Prozess –Anforderungsmanagement mit eingeschlos-

sen – in einem Entwicklungsunternehmenfür alle Projekte auszukommen, ist gefähr-lich. Auch die Annahme, Qualität schonausschließlich durch die Einhaltung vonFormalismen erzielen zu können, istabstrus und falsch. In der Praxis ist siedurchaus öfters zu beobachten. Jedenfallsbeeinflusst das gewählte Vorgehensmodelldie Anforderungen an ein Anforderungs-managementwerkzeug wesentlich.

PragmatischeRandbedingungenAuch die ganz einfachen, pragmatischenRandbedingungen, denen alle Vorgehens-modelle unterliegen, haben starken Einflussauf die Form und den Umfang von Anfor-derungsaufstellungen. Welcher Festschrei-bungsgrad muss bei Angebotslegung, beiAuftragsannahme erreicht sein? In welcherGliederung? Handelt es sich um einelösungsorientierte Ausschreibung, das heißtliegt die Verantwortung für die Erreichungder gewünschten Ziele mittels der vorgege-benen Lösung beim Ausschreibenden, odermuss auch der Auftragnehmer Verant-wortung für die Wirkungserreichung über-nehmen? Ist das Projekt in Analyse-,Beratungs-, Design- und Umsetzungsphasemit getrennter Beauftragung, Abnahmeund Abrechnung geteilt? Welche Kompe-tenzen hat der Auftraggeber? Wie sind die-se verteilt? Wo liegt die Verantwortung füreinzelne Anforderungspunkte? Wie werdenRisiken adressiert, in Bezug gestellt, bewer-tet und verantwortet?

Umfassende Abdeckung zu fordern ist sinn-voll. Die Maximalanforderung entsteht, wennder Umsetzer auch in die Aufgabendefinitionmit eingebunden ist, beziehungsweise – washäufiger auftritt – diese gemeinsam mit demAuftraggeber aufzuarbeiten hat.

Systematische AnsichtAn dieser Stelle ist es von Vorteil, zu einermethodischen, systemischen Ansicht über-zugehen – und nach Literatur, beziehungs-weise Standards zu fragen3):

■ Systemdesign ist methodisch betrachtetein Entwurfsvorgang.

■ Entwurfstätigkeit kann kategorisiertwerden.

■ Für die einzelnen Entwurfskategorienlassen sich Qualitätsmerkmale undImplikationen aufzählen.

Natürlicher EntwurfNatürlicher Entwurf ist gekennzeichnetdurch die (spontane) Verwendung verfüg-barer Materialien zur Deckung eines aku-ten Bedarfs. Wir denken sofort an primitiveKulturen. Halbe Kokosnüsse werden zuTellern, Lehm und Stroh zu Baumaterial.Diese Vorgehensweise wird, abgesehen vonökologischen Überlegungen, in professio-nellem (System-)Design keine Rolle spielen.Dennoch kann man sie tagtäglich beobach-ten. Denken Sie an Kollegen und Kollegin-

adver tor i a l

2

Abb. 2: Objektorientiertes, iterativesVorgehen

Abb. 3: Klassisches Projektvorgehen

3) Quelle: Univ. Prof. Heinz Zemanek , „AbstrakteArchitektur“, Vorlesung an der TU-Wien

o n l i n e - a u s g a b e re q u i re m e n t s e n g i n e e r i n g 2 0 0 7

Anforderungen anzuschreiben, zu sortierenund in saubere Form zu bringen und allesLösungsspezifische, das eine unnötigeEingrenzung darstellt, sofort herauszustrei-chen. Auch dies geschieht vorzugsweise ingrafischer Form.

Diese Art der Annäherung an eineAnforderungsaufstellung hat neben denNachteilen

■ Lösungsdenkern eine Herausforderungbieten zu müssen und

■ manchen Teilnehmer des Arbeits-kreises überzeugen zu müssen, dass einFormulieren von Zielen ohne den Wegdorthin zu kennen, durchaus sinnvollist

wesentliche Vorteile:

■ Motive treten an die Oberfläche –sowohl die Notwendigkeit, zu errei-chende Ziele auflisten zu müssen, alsauch das implizite Erfordernis, siemessbar zu machen, zeigt automatischdie (vorab zumeist verdeckten) wahrenMotive auf.

■ Voreilig eingebrachte Einschränkungenwerden erkannt und zurückgestellt.

■ Die Kriterien, die das Projekt rechtferti-gen, werden umgehend transparent.

■ Die Teamarbeit ist konfliktfrei – nochwetteifern keine Lösungsvorschläge,sondern es wird ausschließlich abge-stimmt, was als funktionales Ergebniserreicht werden soll oder muss.

■ Diese Sammlung übergeordneter An-forderungen wird auf Vollständigkeit,Konfliktfreiheit, hinreichende Unter-teilung, und so weiter geprüft und im(Kern-)Team abgesegnet.

■ Ab diesem Zeitpunkt ist das Einbringenvon Lösungsansätzen freigegeben. Jetztist es ein Leichtes, vollkommen unkon-ventionelle Lösungen zu erkennen, die(auch) die Anforderungen erfüllen.

■ Alle Lösungsvorschläge werden an denübergeordneten, architektonischenAnforderungen auf Übereinstimmunggeprüft. Es entstehen keine Konflikte,weil die Beitragenden selbst dieVerträglichkeit mit den Anforderungenbeurteilen (siehe Abb. 5). Es gilt die ein-fache Regel: Alles, was ausLösungsvorschlägen einzelnen Anfor-derungspunkten nicht zugeordnet wer-den kann, ist entweder (unnötiger)Luxus oder es sind Ergänzungen, zumBeispiel klassifiziert als nice to have

mentiert. Es entsteht Flickwerk, weilgewünschte Zusatzeigenschaften oderOptionen bloß (ein einzelnes Symptombehebend) nachgerüstet werden.Architektonisches VorgehenArchitektonisches Vorgehen ist gekenn-zeichnet durch eine umfassende Analyseder gewünschten Zielwirkungen, Ergeb-nisse und funktionalen Eigenschaften(nicht der Funktionsweise!) – genau ge-nommen unter temporärem Ausschluss desAndenkens von Lösungsansätzen. Ein guterArchitekt analysiert Ihren (abstrakten)Bedarf. Nur dadurch, dass er sich auf diegewünschte Wirkung konzentriert, kann erIhnen – im Gegensatz zum Baumeister – fürIhren Wohnbedarf zu einem großenWohnwagen oder zum wohnlichen Ausbaueines Verkehrsflugzeugs raten – wenn ererkennt, dass dies Ihre Anforderungen bes-ser erfüllt.

Kreativität selbst kann natürlich nichtschematisiert werden, aber die Voraus-setzungen zu kreativen Einsichten könnenmethodisch geschaffen werden! Check-listen und Anleitungen zu architektoni-schem Vorgehen, zur Erstellung architekto-nisch gegliederter, gut strukturierter,übergeordneter Anforderungen lassen sichdurchaus formulieren und anwenden.

ÜbergeordneteAnforderungenIn Systementwicklungsprojekten architekto-nisch vorzugehen, bedeutet daher, die überge-ordneten Anforderungen zu erarbeiten, zugliedern und gut zu dokumentieren – alsoauch zu visualisieren (siehe Abb. 4). Das heißtauch, Anforderunsgmanagement bereits inder Analysephase voll zu integrieren.

Gleichzeitig ist es erforderlich, allfälligangeführte Lösungsansätze in zu erreichen-de Ergebnisse, Wirkungen und Ziele umzu-gestalten und diese als qualitative

nen, die sich die Bildschirmhöhe ihres PCsdurch Unterschieben von Kopierpapiermillimetergenau justieren.

Ingenieurmäßiges VorgehenIngenieurmäßiges Vorgehen ist gekenn-zeichnet durch die kombinatorische Ver-wendung – zumeist genormter – vorgefer-tigter Teile, Werkzeuge oder Methoden, seies bei der Konstruktion oder auch nur inderen produktiver Verwendung. Dies ist dieHauptschiene unserer Kultur, aber auch dieUrsache für das unendlich vielgestaltigeFlickwerk, das uns umgibt.

Denken Sie an einen Baumeister. Siegehen zu ihm, um ihn nach einem zu bau-enden Haus zu fragen. Er wird Ihnen seinenMusterkatalog zeigen, wird Ihnen zugeste-hen, im Detail noch Änderungen vorsehenzu können; Sie wählen aber schlussendlichaus Mustern aus. Der Satz „Für uner-wünschte oder schädliche Wirkungen fra-gen Sie bitte ...” fällt nicht. Viele Wirkun-gen Ihrer Auswahlentscheidung werden Sievorab nicht kennen, manche vielleicht niebemerken. Manche werden angenehm sein,andere werden Sie hinnehmen.

Besonders gefährlich wird dieses Vorgehen,wenn nur einzelne Symptome befriedigt wer-den: Sie wollen ein Gerät zum Ausdruckenvon Rechnungen mit drei Durchschlägen. Siefahren glücklich mit ihrem neuen Nadel-drucker vom Händler ins Büro. Kaum ange-schlossen, lernen Sie, dass Nadeldrucker lautsind. Später lernen Sie, dass Schallschutz-hauben mühsam zu öffnen sind und demDrucker thermische Probleme bereiten.

Aus einem anderen Blickwinkel kannman diese Vorgehensweise auch unter demBegriff Denken in Lösungen zusammenfas-sen. Wirklich Neues mit hoher Wert-schöpfung entsteht so kaum; immer wiederwerden unbeabsichtigte Nebenwirkungen –zum Teil vorerst unerkannt – mit imple-

adver tor i a l

3

Abb. 4: Requirements in UML-Schreibweise

w w w. o b j e k t s p e k r u m . d e

nachzutragen. Bleiben Punkte unerfüllt,muss der Lösungsvorschlag ergänztoder verworfen werden.

■ Möglicherweise werden nochErgänzungspunkte oder anderer Ände-rungsbedarf an den übergeordnetenAnforderungen erkannt, diese müssenabgestimmt und sauber eingearbeitetwerden. Bereits geprüfte Lösungsan-sätze müssen in diesem Fall nochmalsgegengeprüft werden.

■ Es ergibt sich eine strukturierteGliederung der übergeordneten Anfor-derungen, der alles Weitere zugeordnetwird. Diese Dokumentation kann vonEntscheidungsträgern, also vomManagement, gelesen, verstanden undgetragen werden.

■ Eine vollständige und nachvollziehbareEinbettung in die Systemmodellierungbleibt möglich.

Visualisierung: Grammatikder UML für KlassenSowohl für die Visualisierung dieser über-geordneten Anforderungen als auch der

später nachfolgenden, aus der Reali-sierungsschicht oder der Implementierungs-schicht stammenden, verfeinerndenAnforderungen bietet sich die Grammatikder UML für Klassen zur Übernahme instereotyper Form an. Zwischen einzelnenAnforderungen können die BeziehungenAggregation, Komposition beziehungs-weise Verschachtelung, <<deriveRqt>>,<<refine>>, Realisierung oder <<satisfy>>und Abhängigkeit (Dependency) auftreten.Zu Testfällen bietet sich die Beziehung<<verify>> an. Die UML-Grammatik mitihren Symbolen reicht hier völlig aus, umalle denkbaren Beziehungen und Abhängig-keiten zwischen Anforderungen in Dia-grammen grafisch und im Modell logischdarzustellen.

Dies ist eine deutliche Absage an abge-setzte, lineare Anforderungslisten inTextform, ein Wechsel hin zu Anfor-derungsstrukturen, die logisch in dasSystemmodell eingebettet werden, die gra-fisch top-down in Diagrammen mitBeziehungssymbolen abgebildet werdenund die eine vollständige Vernetzung mit

Lösungen, Testfällen und Risikobewertun-gen aufweisen. Je nach Rolle und Aufgabendes Betrachters können sie gemeinsamgenutzt werden – und in unterschiedlicherTiefe nachvollzogen werden.

Weitere AnforderungsdetailsWeitere Anforderungsdetails: Anforderun-gen müssen in mehreren Dimensionen klas-sifizierbar sein: Status, Phasenzuordnung,Anforderungskategorie, Ownership,Dringlichkeit, Komplexität, Prüfstatus, undso weiter. Hier ist einerseits wichtig, dass dieKlassifikationslisten gestaltbar, das heißterweiterbar und änderbar sind und anderer-seits weitere Klassifikationsdimensionendurch geeignete Mechanismen wie zumBeispiel UML-TaggedValues durch denAnwender hinzugefügt werden können.

Verlinkungsmöglichkeiten mit einemRisikomanagement-Funktionsblock, einemMetrics- und einem Ressourcen-Zuord-nungsblock werden sinnvoll sein.Versionierung und Außerkraftsetzung ein-zelner Anforderungen, ohne sie aus derDokumentation entfernen zu müssen, sind

adver tor i a l

4

Abb. 5: Diagramm mit Realisierungsbeziehungen

o n l i n e - a u s g a b e re q u i re m e n t s e n g i n e e r i n g 2 0 0 7

den, vernetzten und aktuellen Projekt-darstellung.

Enterprise ArchitectEnterprise Architect von SparxSystemssetzt die skizzierten Anforderungen um,ohne Sie in der Wahl ihres Vorgehens-modells im Projekt festzulegen oder einzu-schränken. Sie können diesen Funktions-umfang nutzen, egal, ob Sie iterativvorgehen, Rapid Prototyping betreibenoder anderen Prozessmodellen folgen.

Sollten Sie dennoch – trotz der Vorteileder internen Anforderungsverwaltung desEnterprise Architect – externe Require-ments-Management-Systeme einsetzen wol-len, stehen Ihnen mehrere Mechanismenzur Verfügung, diese anzubinden oder sieauch voll zu integrieren. ■

Was ist dieSchlussfolgerung?Abgesehen von reinen Umsetzungspro-jekten mit einer fixen Lösungsvorgabe istarchitektonisches Vorgehen im Anfor-derungsteil – unabhängig von der projekt-umsetzenden Vorgehensweise – immer diebeste Wahl. Die Visualisierung vonAnforderungen in Diagrammform stellt diemeist komplexen Zusammenhänge verein-fachend, leicht lesbar, aber dennoch richtigdar. Erst dadurch wird ein strukturierter,nachvollziehbarer und im Projekt lebbarerTop-Down-Ansatz möglich, der kontinu-ierlich den Blick auf die Zusammenhängemit den zu erzielenden Wertschöpfungensichert. Zusätzlich wird das Projektrisikoverkleinert, Auftraggeber und Auftragneh-mer haben sich auf die unterstelltenZusammenhänge verständigt und entneh-men den Projektstand aus einer umfassen-

zusätzlich zu fordern. Eine Nachvollzieh-barkeit von Änderungen, Such- undFilterfunktionen werden benötigt. Diesbetrifft aber ohnehin das Modellierungs-werkzeug in seiner Gesamtheit – Anfor-derungsmanagement ist ja nur ein Funk-tionsteil des Modellierungswerkzeuges.

Die Realisierungs- und Abhängigkeitsbe-ziehungen müssen zu weiteren Elementendes Modells (Anwendungsfälle, Abläufe,Statemodels, OOP-Klassen, und so weiter)hergestellt werden können, so dass dieVerkettungen mit der weiteren Analyse, mitdem Design und der Implementierung dar-stellbar, visualisierbar, und abfragbar wer-den. Berichte hierzu müssen abgerufenwerden können, einschließlich Teststandund Implementierungsgrad verketteterElemente. Eine abrufbare, automatischeDarstellung in Form einer Beziehungs-matrix ist von Vorteil.

adver tor i a l

5 w w w. o b j e k t s p e k r u m . d e