Traceability Controlling:Verbesserte Qualitätssicherung imRequirements-Management Wie Erfahrungen und Befragungen aus der Praxis belegen, fehlen in Unternehmen zumeist effiziente Abläufe, um Fehler in derSystementwicklung so früh wie möglich zu identifizieren. Im eingeführten Traceability Controlling (TraCo) liegt der Fokus auf derEntwurfs- und Designphase in einem Softwareentwicklungsprojekt und auf der Qualitätssicherung der vom Modellierer getroffe-nen Designentscheidungen. Mittels TraCo kann validiert werden, ob die Designkomponenten im Modell in entsprechender Qualitätvorliegen und ob diese den Ansprüchen des Kunden genügen. In diesem Artikel präsentieren wir ein Verfahren, um kontinuierlicheinen Modellierungsansatz von Anforderungen und Systemarchitektur bezüglich Relevanz und Wichtigkeit der Verknüpfung vonAnforderungen zu Designentscheidungen zu überwachen.

liegt in der lückenlosen Nachvoll zieh bar -keit von Anforderungen.

Requirements-Traceability stellt heuteeinen Schlüsselfaktor im Software-Projektmanagement dar und ist ein wichti-ger Teil in der Qualitätssicherung imSoftware-Engineering (vgl. [Poh11]).Traceability wird eingesetzt, um sicherzu-stellen, dass alle Anforderungen hinrei-chend in der Spezifikation berücksichtigtwurden (Validierung) und in die Um -setzung richtig einfließen (Verifikation). Siefungiert als Gradmesser der System ent -wicklungsreife. Zielsetzung ist es, komple-xe Systeme effizient und fehlerarm zu ent-wickeln.

Lücke in verfügbarenWerkzeugen Gängige Requirements-Management-Toolsbieten die Möglichkeit zur Erfassung,Analyse, Spezifizierung und Validierungvon Anforderungen und ermöglichen soeine standardisierte Form des Require -ments-Managements. Dabei findet vorallem die Traceability Matrix, die erstmalsvon [Mac86] eingeführt wurde, Anwen -

komponenten im Hinblick auf dieImplementierung verschaffen zu kön-nen.

n Häufig wird schon zu Beginn derAnalysephase eine Lösung „anmodel-liert“, wodurch lösungsspezifische Fest -legungen und Einschränkungen voreiliggetroffen werden, die in der An -forderungsliste nirgendwo gefordertsind.

n Die Management- bzw. Projektleiter-Ebene wird nicht bewusst in den Pro -zess der Überleitung von Kunden an -forderungen in Systemanforderungeninvolviert, wodurch es vermehrt zuFehlinterpretationen hinsichtlich derUmsetzung kommt.

Ein für den gesamten Projektzyklus durch-gehender Nachweis der Anforderungs -abdeckung ist ein gängiger Standard und inBereichen mit höchstem Sicherheitsbedarf(z. B. in der Medizin-, Flug- und Raum -fahrttechnik) zwingend vorgesehen (vgl.[Poh08]). Der Fokus in der Requirements-Traceability, die ein wesentliches Teilgebietdes Requirements-Managements darstellt,

Aufwendige Qualitätsanalysen findenangesichts eines oft hohen Projektdruckskaum Akzeptanz. Gerade in Großprojektenist es sehr schwierig, Softwarequalitätneben Zeit und Budget gleichermaßen zusteuern, da kontinuierliche und umfassendeRückmeldungen über den aktuellen Statushäufig fehlen (vgl. [Gro10]). Weitere signi-fikante Ursachen für Fehlschläge bei derSoftwareentwicklung von großenProgrammsystemen sind oftmals mangeln-de Management-Awareness und eine hohePersonalfluktuation (vgl. [Ste11]). Meistensergeben sich Probleme aus folgendenPunkten:

n Der Systemarchitekt muss das Modellsehr gut kennen, um jederzeit den Über-blick über die im Modellierungsprozessgetroffenen Designentscheidungen be -halten zu können (derzeit sehr intuitiv).

n Mitarbeiter scheiden vorzeitig aus demProjekt aus und für neue Pro -jektmitarbeiter fehlt zumeist die nötigeDokumentation, um sich rasch einenÜberblick über die Systemarchitekturund die Relevanz der einzelnen System -

der au tor

1 www.objektspektrum.de

fachartikel

Dr. Horst Kargl

(Horst.Kargl@sparxsystems.eu)interessiert sich vor allem für objektorientierte Modellierung undSoftwareentwicklung. Bei Sparx Systems Central Europe beschäftigt ersich mit Forschung und Entwicklung sowie mit Kundenprojekten undProduktentwicklung und gibt sein Wissen als Trainer und Berater inVorträgen und Publikationen weiter.

Mag. Dipl.-Ing. Dr. Alexandra Mazak

(mazak@big.tuwien.ac.at)ist Post-Doktorandin für die Business Informatics Group an der TU Wienim Forschungsprojekt REAlist. Ihre Forschungsinteressen liegen in denBereichen IT-Controlling, Meta-Informationsmodellierung und DecisionSupport Systems mit dem Schwerpunkt Business Performance Management.

dung. Dieses Konstrukt ist eine Art„Completeness Indicator“, das dieVerlinkung von Design-Artefakten mit denentsprechenden Anforderungen visualisiertdarstellt.

Das Framework Scrum (vgl. [Kni07])bietet ein iteratives und inkrementellesVorgehensmodell zur Risikokontrolle undnachhaltigen Entwicklung komplexerSysteme. Scrum basiert auf der Theorie derempirischen Prozesssteuerung. Man gehtvon der Annahme aus, dass Wissen ausErfahrung gewonnen wird und dassEntscheidungen aufgrund von bekanntenFakten getroffen werden. Die Prozess -steuerung stützt sich auf drei Säulen:

n Transparenz, n Überprüfung, n Anpassung.

Aktuell zeigt sich jedoch, dass eine abge-setzte Führung von Requirements-Systemen neben der Modellhaltung (z. B.durch parallel laufende, nicht-integrierteTools) ein aufwendiges, kostenintensivesund vor allem fehleranfälliges Vorgehen ist(vgl. [Ste11]). Eine auf aktueller Literaturbasierende Recherche hat gezeigt, dass dieTraceability Matrix (siehe Abbildung 1) eingeeignetes Werkzeug ist, um die Abdeckungder Anforderungen nachvollziehbar zumachen. Daraus kann jedoch nicht dieRelevanz der Verlinkung zwischen Design -elementen und Anforderungen abgeleitetwerden, um so beispielsweise die Signi -fikanz der Elemente im Hinblick auf dieImplementierung zu evaluieren.

Um dieser Anforderung nach der „Re -levanz von Verlinkungen“ – im Sinne eineswahrgenommenen Nutzwertes – nachzu-kommen, haben wir einen heuristischenAnsatz entwickelt, bei dem Relevanz, aus-gedrückt durch Gewichtungsannotationenals Meta-Information, im Modell explizithinterlegt werden kann. Dieser Ansatzträgt den Namen Traceability Controlling(TraCo) und wurde in das Modellierungs -werkzeug Enterprise Architect (EA) vonSparx Systems integriert.

Entwicklung einesTraceability Controllings In TraCo gehen wir der Frage nach, wiesich Nutzen und Qualität von Verlin -kungen im Kontext der Systemmo del -lierung operationalisieren und visualisierenlassen. Der Fokus liegt dabei auf der Ent -wurfs- und Designphase in einemSoftwareentwicklungsprojekt und auf derQualitätssicherung der – in dieser frühenPhase der Lösungsfindung und Lösungs -spezifikation – vom Modellierer getroffe-nen Designentscheidungen.

TraCo ist ein phasenbezogenes Moni -toring-Verfahren zur kontinuierlichenÜberprüfung der Entwicklungsfacette. Esnimmt Bezug auf jene Kontextaspekte, diedie Entwicklung des Systems nachhaltigbeeinflussen. So kann validiert werden, obdas Architekturmodell – bzw. feingranulardie Systembausteine und Design-Artefakte– im Modell in entsprechender Qualitätvorliegen und ob diese den Ansprüchen desKunden genügen. Die speziellen, qualitäts-bezogenen Kontextkriterien basieren auf

der abstrakten Qualitätsnorm „ISO/IEC25010 – System and software qualitymodels“ (vgl. [ISO]). Generell könnenKontexte aber auch anwenderspezifischgeneriert werden.

In TraCo wird die Integrationssicht aufArchitektur- und Designebene (Sicht desModellierers) mit der Kundensicht aufAnforderungsebene gekoppelt berücksich-tigt. Die Überprüfung der Umsetzung vonKundenanforderungen und Qualitäts merk -malen im Architektur-/Designmodell ist fürdie Einschätzung der Produktqualitäterforderlich und dient zudem als Ent -scheidungsgrundlage für das Pro jekt -manage ment.

Grundsätzlich kann TraCo aber auch injeder anderen Phase der Systement -wicklung verwendet werden, wie beispiels-weise in der Implementierungs- und Inte -grationsphase auf Komponentenebene.Hier liegt der Fokus auf der Umsetzung derSystembausteine in Code. Zentral ist danndie Entwicklersicht im Entwicklungs -kontext.

Kernidee von TraCo ist es, situatives undkontextbezogenes Designwissen zu forma-lisieren. Die Umsetzung dieses Ansatzesbasiert auf der Idee einer gewichteten oderbewerteten Entscheidungsmatrix. Sie hilftmerklich, eine Entscheidung vorzubereitenund zu treffen, und veranschaulicht derenZustandekommen. In TraCo wird versucht,Entscheidungen und deren Folgen bereitswährend der Modellierung zu visualisierenund dadurch nachvollziehbar zu machen,indem die Entscheidungsbildung im Modellexplizit hinterlegt wird. Die Grundlagedafür bildet die jeweilige Entschei dungs -situation im Hinblick auf qualitätsbezoge-ne Kontexte. Implementiert wird das Ver -fahren in zwei Controlling-Instrumenten:

n der gewichteten Entscheidungsmatrix(GEM) und

n dem Design Decision Traceability Grid(DDTG).

In der aktuellen Version ermöglicht TraCoden Nutzern (Modellierer, Projektmanager)die Prüfung des Designmodells unter Be -rücksichtigung inhaltlicher Qualitäts aspekteaus Anwender- und Integrations sicht – undzwar zu jedem beliebigen Zeitpunkt wäh-rend der Erstellung des Modells.

EA Relationship Matrix Im Modellierungswerkzeug EnterpriseArchitect werden die Beziehungen von

2Online-Themenspecial Requirements Engineering 2014

Online-Themenspecial Requirements Engineering 2014 fachartikel

Abb. 1: Enterprise Architect Relationship Matrix.

Integration abschätzen zu können. Daszweite Controlling-Instrument – dasDesign Decision Traceability Grid (sieheAbbildung 3) – hilft dabei, die relevantenBauteile mittels Kennzahlen zu belegen.

TraCo unterstützt den Modellierer aktivbei der prozessbegleitenden Auseinander -setzung mit der Qualität des Architektur-/Designmodells. Dadurch kann rückbli -ckend die Bewertung der Entscheidungs -qualität für künftige Entscheidungen eva-luiert werden. Das bedeutet, dass dieFolgen und Auswirkungen einerEntscheidung frühzeitig erkannt und beiBedarf jederzeit abgeändert werden kön-nen.

So kann rasch identifiziert werden, wel-che Anforderungen nicht oder nicht genü-gend oder aber auch zu detailliert in dasModell übernommen wurden (Erfüllungder Korrektheit). Es können Realisierungenim Modell erkannt werden, die keinen odernur einen minimalen Nutzen stiften(Erfüllung der Notwendigkeit). Zudemkönnen determinante Systembausteine,sogenannte Business-Driver, erkannt undvorrangig bearbeitet werden. LetztereIdentifizierung kann beispielsweise alsAusgangspunkt für den Product Owner imProduct Backlog von Scrum von Nutzensein.

Die Früherkennung von Designfehlerndient der Vermeidung von sogenanntenFlickwerken. Derartige Fehler wirken sichnegativ auf die Entwicklungszeit und -kosten aus und können bis zum Pro -jektabbruch bzw. zu einer komplettenNeuerstellung des gesamten Software -produkts führen, falls diese FehlerArchitektur, Entwurf oder Design betreffen(vgl. [Sch10]).

Durch den TraCo-Ansatz wird den direkt(Systemarchitekt, Requirements Engineer,Modellierer) und indirekt (Kunde,Projektleiter) am Softwareentwick lungs -prozess beteiligten Akteuren eine neueKommunikationsgrundlage geboten. Da -

Ergebnis nachvollziehbar machen.n Eventuell Inkonsistenzen in der

Entscheidungsfindung aufdecken.n Subjektive Bauch-Entscheidungen

über prüfen und ergänzen.n Qualitative Gewichtungsentschei dun -

gen herausarbeiten.n Differenzen im Bereich der System -

auffassung/des Systemverständnissesim Team aufzeigen.

n Die letztlich getroffene Entscheidungund Bewertung der Modellstrukturstrukturiert darstellen.

Traceability-Controlling-Ansatz In TraCo wählen wir einen heuristischenAnsatz, um komplexe Entscheidungen ver-einfacht darzustellen und dadurch transpa-rent und nachvollziehbar für die Nutzer zumachen. Dabei wird informelles, kontext-bezogenes Designwissen – der Model -lierungsfokus – formalisiert und explizit inZahlen gegossen. Als Ergebnis erhält derNutzer eine Matrix, die Designent -scheidungen – erweitert um eine Relevanz-Sicht – widerspiegelt.

Die in TraCo umgesetzte analytischeQualitätssicherungsmaßnahme dient derFeststellung, ob die Komponenten desArchitekturmodells (Systembausteine bzw.Designelemente) der Spezifikation und demKundenwunsch entsprechen. Wird diegewichtete Entscheidungsmatrix (sieheAbbildung 2) von mehreren Akteuren befüllt, erhält man eine Landkarte der ver-schiedenen Bewertungen in unterschied-lichen Kontexten, die als Dis kus sions -grundlage herangezogen werden kann, umdas gemeinsame Verständnis aus den ver-schiedenen Sichten zu validieren.

Darüber hinaus erhalten die Nutzerwertvolle Kennzahlen, um beispielsweisebei Änderungen von Kundenan for -derungen oder Systembausteinen die Aus -wirkungen auf die Architektur und voraus-blickend auf die Implementierung und

Kundenanforderungen und System bau -steinen in der Relationship Matrix visuali-siert. Je nach Modellierungssprache wirdein spezieller Verknüpfungslink verwendet(UML::Realization, SysML::Satisfy).Durch die Verlinkung wird eine „Trace-Kette“ aufgebaut, die eine Impact-Analyseerlaubt und die bei Änderungen von Anfor -derungen oder Designkomponenten einewertvolle Informationsquelle darstellt.

Abbildung 1 zeigt einen Ausschnitt ausdieser Matrix. In den Kreuzpunkten wirdeine vorhandene Verlinkung in Form einesSymbols (Pfeil) dargestellt. Der Modelliererkann so beispielsweise überprüfen, ob alleKundenanforderungen in der Lösungberücksichtigt werden (Vollständigkeit)und ob die Anforderungen an das Systemgemeinsam erfüllbar sind (Konsistenz).

Die Matrix hilft, die Menge an An -forderungen überschaubar zu halten undVerlinkungen nachvollziehbar zu tracken.Allerdings wird durch diese Art der visuali-sierten Realisierungen lediglich dargestellt,dass eine Anforderung von einer anderenAnforderung abgeleitet ist bzw. durch einenSystembaustein umgesetzt werden muss.Weder können Informationen darüber her-ausgelesen werden, inwieweit die Um -setzung schon vorangeschritten ist, nochwird die Information berücksichtigt,warum eine Kundenanforderung mit einerDesignkomponente verknüpft wurde.

Das heißt, die Relevanz der Kopplungaus Integrationssicht – beispielsweise imHinblick auf inhaltliche Qualitätsaspekte,wie Notwendigkeit, Auswirkung, Kor -rektheit, Adäquatheit – bleibt unberück -sichtigt. Das bedeutet, dass das Wissen, dasder Modellierer bei der Erstellung derVerlinkungen nur im Kopf und nicht aufge-zeichnet hat, verloren geht. Dieses situativekontextbezogene Designwissen ist in derStruktur des Modells implizit hinterlegtund daher nicht transparent für andere amProjekt beteiligte Akteure, beispielsweiseProjektleiter, Entwickler und Kunde.

Impact Der Einsatz von TraCo hilft auf der Ebeneder Architektur und des Designs imSoftwareentwicklungsprozess bei folgen-den Aktivitäten:

n Entscheidungen in Teams unterstützen.n Eine gemeinsam tragbare Lösung fin-

den und den dafür erforderlichenZeitaufwand minimieren.

n Die Entscheidungsfindung und das

fachartikel

3 www.objektspektrum.de

Abb. 2: Ausschnitt der gewichteten Entscheidungsmatrix.

durch sollen die interne sowie die externeKommunikation zwischen den Stake -holdern im Sinne der Umsetzung einer effi-zienten Requirements Negotiation wesent-lich erleichtert und verbessert werden.

Sowohl der gedankliche Prozess der kon-textabhängigen Bewertung (Auswahl undErfassung der Gewichtungen) als auchderen Auswertung machen komplexeAbhängigkeiten sichtbar und führen zurKlärung von Prioritäten, gerade wenn dasErgebnis mit anderen diskutiert und hinter-fragt wird. Dadurch soll das Risiko mini-miert werden, dass Projekte aufgrundfalsch verstandener Anforderungen schei-tern.

Die gewichteteEntscheidungsmatrix Die gewichtige Entscheidungsmatrix(GEM) hilft dabei, Designentscheidungenmit Kontextbezug übersichtlich und nach-vollziehbar zu gestalten. In der Matrix wer-den die Verlinkungen zwischen Kunden an -forderungen und Designkomponenten alsBewertungsobjekte (siehe Abbildung 2)herangezogen, um so jede Kombination ausObjekt (Zeile in der GEM) und Kontext -kriterium (Spalte in der GEM) bewerten zukönnen. Zum Beispiel realisiert „Login“die Kundenanforderung „Sicherer Zu -griff“. Der Modellierer entscheidet nunüber die Relevanz der Verlinkung imKontext „Sicherheit“ (z. B. steht „9“ für„hoch relevant“).

Grundsätzlich kann jede Beziehung inbeliebig vielen Kontexten bewertet werden.Der daraus resultierende Gewichtungs -vektor wird zur besseren Visualisierung

zusätzlich farblich hinterlegt. JedesKontextkriterium, das zur Auswahl steht,erhält eine eigene Spalte in der Matrix.Gegebenenfalls kann dadurch die Anzahlschnell anwachsen, aber nur so lassen sichdie Qualitätskriterien sauber und differen-ziert betrachten.

Die Gewichtungsbewertung wird direktvom Modellierer bestimmt und ausgeführt.Sobald eine Verlinkung erstellt wurde, wirdder Modellierer automatisch vom Systemaufgefordert, einen vordefinierten Kontextauszuwählen oder neu zu definieren undeinen Punktewert zu vergeben (sieheAbbildung 4).

Die Skala weist eine Bandbreite von 1(schwach relevant) bis 9 (hoch relevant) auf.Keine Gewichtung bedeutet, dass dasBewertungsobjekt keinen Nutzen imKontext erfüllt. Die Relevanz-Semantik hin-ter dem Konzept der GEM legt Folgendesfest: Je relevanter die gewählte Lösung inBezug zu einem bestimmten Kontext ist,umso höher ist deren kontextueller undsomit qualitätssichernder Effekt (z. B.Benutzerfreundlichkeit und Sicher heit).

Zur Berechnung dieser Effektgröße(Erfül lungsgrad pro Kontextkriterium inAbbildung 2) wird über jede Zeile in derSpalte iteriert und ein prozentueller Wertmittels Summenprodukt errechnet. Hierfürwird als Zwischenschritt eine relativeGewichtung berechnet, die sich aus demVerhältnis zwischen den manuellenBewertungen des Modellierers und derPriorisierung von Kundenseite zusammen-setzt.

Der Erfüllungsgrad ist ein Indikator, derAuskunft darüber gibt, welchen Anteil einbestimmtes Qualitätskriterium (z. B.Sicherheit) im Modell einnimmt. Ein optio-nales Textfeld bietet zudem die Möglichkeiteiner Kurzbeschreibung zu den jeweiligenBewertungen. Es kann Zusatzinforma -tionen, differenzierende Erläuterungen undweiterführende bzw. verweisende Linksenthalten. Das Feld dient nicht der eigent-lichen Entscheidungsfindung, wohl aberder Orientierung und Dokumentation.

Die Option „Validierung“ ermöglichtdem Modellierer, bei Erstellung eines neuenKontextes, diesen mit den bereits bestehen-den Kontexten semantisch zu vergleichen.Existiert bereits ein eventuell gleichbedeu-tender Kontext, so erscheint ein entspre-chender Hinweis (siehe Abbildung 5).

Das Design DecisionTraceability Grid Die zentrale Aufgabe des Design Deci sionTracebility Grit (DDTG) ist es, die Folgeneiner Entscheidung zu visualisieren, um beiunerwünschtem Ergebnis so früh wie mög-lich gegensteuern zu können, indem Hand -lungsalternativen erkannt und genutzt wer-den. Diese praktische Anwendung derpräskriptiven Entscheidungstheorie unter-stützt den Modellierer im Designprozessbei der Überprüfung seiner Entschei -dungen, um Architektur-Verletzungenschon in der Entstehung abzufangen, unddient der Prävention von Flickwerken.

4Online-Themenspecial Requirements Engineering 2014

Online-Themenspecial Requirements Engineering 2014 fachartikel

Abb. 3: Design Decision Tracebility Grit (DDTG).

Abb. 4: Relevanz-Gewichtung.

um dieses in weitere Entscheidungen miteinfließen lassen zu können.

Die Umsetzung von TraCo im Model -lierungswerkzeug Enterprise Architect ver-sucht, die Vergabe der Kennzahlen so ein-fach wie möglich zu gestalten. Dennoch istdie Motivation, über die Relevanz vonBeziehungen nachzudenken, ein wichtigerAspekt, dem derzeit in Form einerPraxisstudie nachgegangen wird. Das sim-ple Vergeben eines Durchschnittswertes(z. B. „5“) für alle Verlinkungen würde spä-testens im DDTG auffallen und diskutiertwerden müssen. n

hinsichtlich der Korrektheit und Not -wendigkeit jeder (einzelnen) Designkompo -nente möglich.

Zudem kann beobachtet werden, wiestark die Designkomponenten auf Ände-rungen der Kundenanforderungen (z. B.durch Löschen, Änderung der Priori -sierung) reagieren, um daraus gegebenen-falls resultierende Entscheidungen und ent-sprechende Handlungsfolgen aufstrate gischer Ebene zu veranlassen.Beispielsweise kann so die Effektivität derModellstruktur abgeleitet werden, um beizeitlichen Engpässen die Entwicklung aufKomponenten mit höherer Relevanz zukonzentrieren.

Jeder Modellierer hat in der Grund -einstellung die Sicht auf seinen Part desModells. In einer erweiterten Funktionwird – je nach Rechtevergabe – zusätzlichdie Möglichkeit geboten, die eigene Sichtauf den Modellierungsstatus andererModellierer auszuweiten. Diese erweiterteFunktionalität schafft Transparenz vonDesignentscheidungen in Bezug auf dasAnforderungsprofil eines Gesamtmodells.

Die kumulierte Sicht auf das Modelldient einerseits der Visualisierung desLeistungsfortschritts und anderseits derRisikoprävention. Fragen wie beispiels-weise „Haben wir ein gleiches Verständnisvon den Anforderungen und davon, wiewir diese umsetzen wollen?“ können sobeantwortet werden.

Fazit Durch den TraCo-Ansatz wird die vorhan-dene Repräsentationssicht der EA Re -lationship Matrix mittels der gewichtetenEntscheidungsmatrix erweitert. Neben derwichtigen Information, welche Artefaktezueinander in Beziehung stehen, wird auchder Grund dafür in Form von Relevanz-Kennzahlen, die sich auf Designent -scheidungen in verschiedenen Kontextenbeziehen, angegeben.

Durch die Aggregation dieser Kenn -zahlen im DDTG entsteht ein neuesWerkzeug. Dieses dient allen Stakeholderndazu, bisher verloren gegangenes Wissensichtbar und nachvollziehbar zu machen,

Das DDTG dient dem gezielten modul-bezogenen Monitoring von Designent -scheidungen mit Blick auf die inhaltlichenQualitätsaspekte des fertigen Systems.Durch die Nachvollziehbarkeit und Sicht -barmachung des Designwissens lassen sichaus dem Grid, ebenso wie aus der vorange-stellten GEM entsprechende Kennzahlen(z. B. der Nutzwert pro Designkompo -nente) ermitteln.

Der Nutzwert (Level of Utility) errech-net sich linear additiv. Er drückt den Anteilaus, den die Designkomponente an derUmsetzung zur Zielerfüllung (Erfüllung dervom Kunden gewünschten Qualitätseigen -schaften eines Produkts) hat und wird indi-rekt über die Gewichtungen der Bewer -tungsobjekte aus der GEM errechnet. Dasbedeutet, dass aus Einzelbewertungen aufeinen Gesamtwert geschlossen wird. Dabeiberechnet sich der Nutzwert aus derMultiplikation des relativen Teilnutzwertsder Designkomponente (Summe der Rele -vanz-Gewichtungen) und der Priorisierungdes Kunden als eine additive-multiplikativeVerknüpfung. Der Wertebereich reichtdabei von 0% (überhaupt nicht) bis 100%(unentbehrlich).

Im DDTG geht es um die optimaleNutzenausprägung der Designelementeund nicht um deren maximale Ausprägung.Das bedeutet: Erfüllt eine Design kompo -nente eine Kundenanforderung mit hoherPriorisierung, ergibt das natürlich einenhöheren prozentuellen Wert als die Um -setzung einer Kundenanforderung mit nie-driger Priorisierung. Mithilfe des Nutz -werts sind Rückschlüsse über die innereSoftwarequalität des Architekturmodells

fachartikel

5 www.objektspektrum.de

Abb. 5: Semantische Validierung.

Literatur & Links

[Gro10] M. Grossmann, Messbasierte Quali -

täts sicherungstechniken für die Steuerung von

innerer Software-Qualität in der Praxis, in:

Proc. of Workshop Software-Reengineering

und Design for Future, Bad Honnef 2010.

[Kni07] H. Knieberg, Scrum and XP from the

Trenches, C4 Media Inc 2007.

[Mac86] J. MacMillian, J.R. Vosburgh, Soft -

ware Quality Indicators, Cambridge: Scien ti fic

Systems Inc, 1986.

[Poh08] K. Pohl, Requirements Engineering:

Grundlagen, Prinzipien, Techniken,

dpunkt.verlag 2008. [Poh11] K. Pohl, C.

Rupp, Basiswissen Requirements Engineering,

dpunkt.verlag 2011.

[Sch10] A. Schatten, S. Biffl, M. Demolsky, E.

Gostischa-Franta, T. Östreicher, D. Winkler,

Best Practice Software-Engineering, Springer

2010.

[Ste11] D. Steinpichler, H. Kargl, Enterprise

Architect – Project management with UML and

EA, SparxSystems Software GmbH, 2011.

[ISO] International Organization for

Standardization, siehe:

http://www.iso.org/iso/iso_catalogue/catalogue_tc/

Der Beitrag wurde ebenfalls in der Print -ausgabe von Objektspektrum 02/2014 ver-öffentlicht.