kapitel 11 rationale management - sewiki.iai.uni-bonn.de · rationale sind die Überlegungen, die...

Vorlesung „Softwaretechnologie“Wintersemester 2009 R O O T Ste se este 009

Kapitel 11 Kapitel 11 Rationale Management

Nach Bernd Bruegge, Allen Dutoit: Object-Oriented Software Engineering – Conquering Complex and Changing Systems“„Object Oriented Software Engineering Conquering Complex and Changing Systems ,

Prentice Hall, 2000

Stand: 05.02.2009

Vorlesung „ Softwaretechnologie“Kapitel 11: Rationale Management R O O T Sap te at o a e a age e t

Motivation

Ein Flugzeugbeispiel

A320E t P i fl it Fl b Wi “ St Erstes Passagierflugzeug mit „Fly-by-Wire“-Steuerung

150 Sitzplätze, kurze bis mittlere Reichweite

A319 & A321 Nachfolgermodelle des A320g Gleiche Handhabung wie beim A320

„Rationale“ (engl. für „Begründung“, „vernunftsmäßige Erklärung“, „Argumentation“)

Reduzieren der Kosten für Pilotenausbildung und Wartung Reduzieren der Kosten für Pilotenausbildung und Wartung Mehr Flexibilität für die Fluglinie

© 2000-2009 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ (SWT) Seite 11-4 R O O T S

Ein Flugzeugbeispiel (2)

A330 & A340L t k b Ult l t k fl Langstrecken- bzw. Ultralangstreckenflugzeug

2x Sitzplätze, 3x Reichweite Handhabung ähnlich wie bei der A320 Familie Handhabung ähnlich wie bei der A320 Familie

Rationale Nach nur minimaler Umschulung können A320-Piloten die Zulassung

zum Flug der A330 und A340 erwerben.

Konsequenz Jede Änderung an einem der fünf Flugzeugtypen muss diese Jede Änderung an einem der fünf Flugzeugtypen muss diese

Ähnlichkeiten beibehalten.


Überblick

Rationale W i t ? Was ist es? Warum ist es wichtig?

Verfahren... ... zur Repräsentation von Rationale

f ... zum Erfassung von Rationale ... zum Zugriff auf Rationale

Aktueller Stand in Praxis & Forschung

Zusammenfassung


Was ist „Rationale“?

Rationale sind die Überlegungen, die zum System (in seiner jetzigen Form) geführt habenForm) geführt haben.

Rationale beinhaltetRationale beinhaltet Fragen (issues), die angegangen wurden, Alternativen, die in Betracht gezogen wurden, Entscheidungen, die getroffen wurden um die Fragen zu klären, Kriterien, die als Grundlage für die Entscheidungsfindung dienten,

sowiesowie Diskussionen, durch die die Entwickler zu den Entscheidungen

gekommen sind.


Warum „Rationale Management“?

Softwaresysteme ähneln PassagierflugzeugenSi i d F l i ß A hl E t h idSie sind Folge einer großen Anzahl von Entscheidungen, die über einen ausgedehnten Zeitraum getroffen wurden.

Gemeinsame Probleme Sich verändernde Annahmen Veraltete Entscheidungen Konflikte zwischen verschiedenen Kriterien

Daraus resultieren Hohe Wartungskosten Hohe Wartungskosten Informationens-Verlust und aufwendige „Wiederbeschaffung“


„Rationale“ hilft beim Umgang mit VeränderungenVeränderungen

Verbessert die Wartbarkeit D W t l hält Ei bli k i d E t f k t t Das Wartungspersonal erhält Einblick in den Entwurfskontext.

Erleichtert das Erlernen Neues Personal kann den Entwurf verstehen, indem es die

Entscheidungen durchspielt, die zu dem Entwurf geführt haben.

Verbessert Analyse und Entwurf Vermeidet wiederholtes Auswerten untauglicher Alternativeng Ermöglicht eine konsistente und explizite Abwägung von Alternativen ... und somit wohlbegründete Entscheidungen



Rationale Management an einem Rationale Management an einem Beispiel

CRC-SystemeIssues

AlternativesCriteria

ArgumentsResolution

Beispiel: Zugleitsystem (Centralized Traffic Control)Traffic Control)

Züge

GleiseS2 S3

Signale WeichenSW1 SW2

S1 S4

CTC-Systeme ermöglichen es, Züge ferngesteuert zu kontrollieren und zu überwachen.

CTC Systeme ermöglichen die Streckenplanung sowie die CTC-Systeme ermöglichen die Streckenplanung, sowie die Neuplanung in Problemfällen.


Zugleitsystem (2)

CTC-Systeme sind ein ideales Beispiel für Rationale-Erfassung

Langlebige Systeme Manche CTC-Systeme enthalten Relais aus dem 19 Jahrhundert! Manche CTC-Systeme enthalten Relais aus dem 19. Jahrhundert! Ausgedehnter Wartungslebenszyklus Ursprüngliche Entwickler stehen nicht (mehr) zur Verfügung.

Ausfallzeiten sind teuer (wenn auch nicht sicherheitskritisch) Niedrige Toleranz gegenüber Bugs Niedrige Toleranz gegenüber Bugs Übergang zu ausgereifter Technologie


Probleme / Fragen (engl. „issues“)

Konkrete Probleme, für die es typischerweise keine eindeutige, korrekte Lösung gibtkorrekte Lösung gibt.

Probleme werden als Fragen formuliert

input?:Issuedisplay?:Issue

Wie soll ein Gleisabschnitt visualisiert werden?

Wie soll der Streckenfahrdienstleiter mit dem

System interagieren?System interagieren?


Lösungsvorschläge („Proposals”)

Lösungsvorschläge sind mögliche Alternativen zum Lösen eines Problems.Problems.

Ein Lösungsvorschlag kann mehreren Problemen zugeordnet sein.input?:Issuedisplay?:Issue

addressed byaddressed byaddressed by

point&click:Proposaltext-based:Proposal

Für den Streckenfahrdienstleiter genügt eine einfache Textanzeige. Gl i b h itt kö it

Die vom Streckenfahrdienstleiter verwendete Benutzerschnittstelle könnte

lGleisabschnitte können mit Sonderzeichen dargestellt werden.

alsPoint & Click UI realisiert werden.


Folgeprobleme („Consequent issues“)

Folgeprobleme sind Probleme, die durch die Einführung eines Lösungsvorschlags entstehenLösungsvorschlags entstehen.




t i l? I

raises

terminal?:Issue

Was für eine Terminalemulation soll für die Anzeige verwendet

werden?


Kriterien

Ein Kriterium ist ein Maß für die Güte von Vorschlägen.K it i i d ft E t f i l d i ht f kti l A f d Kriterien sind oft Entwurfsziele oder nicht-funktionale Anforderungen.




raises meetsmeets

t i l? I

failsfails

terminal?:Issue

availability$:Criterionusability$:Criterion

Das CTC System sollte eineDie zur Eingabe eines Kommandos Das CTC-System sollte eine Verfügbarkeit von mindestens 99%

aufweisen.

Die zur Eingabe eines Kommandos benötigte Zeit sollte weniger als zwei

Sekunden betragen.

Argumente

Argumente repräsentieren die Debatten, durch die die Entwickler zur Lösung eines Problems gekommen sindLösung eines Problems gekommen sind.

Argumente könne für oder gegen einen beliebigen anderen Teil des Rationale geführt werden.

Argumente machen den größten Teil des Rationale aus.


Arguments (2)

input?:Issue

addressed byaddressed by

display?:Issue


meetsmeets


terminal?:Issue

raises meetsmeets

availability$:Criterionusability$:Criterion

failsfails is opposed by

yy

is supported by

availability-first!:Argument

Point & click UIs sind in ihrer Implementierung komplexer als Text-basierte Schnittstellen. Infolge dessen sind sie komplizierter zu testen. Wir würden riskieren, schwere Fehler in das Systemdessen sind sie komplizierter zu testen. Wir würden riskieren, schwere Fehler in das System

einzuführen. Das würde jeden Benutzbarkeits-Vorteil aufwiegen, den eine solche Benutzerschnittstelle hätte.

Lösungen („Resolutions“)

Lösungen repräsentieren Entscheidungen.Ei Lö f t d ählt Lö hl i di Eine Lösung fasst den ausgewählten Lösungsvorschlag, sowie die Argumente, die für ihn sprechen, zusammen.

Ein gelöstes Problem („issue“) wird als „geschlossen“ („closed“)Ein gelöstes Problem („issue ) wird als „geschlossen („closed ) bezeichnet, ein ungelöstes als „offen” („open”).

Ein gelöstes Problem kann, wenn nötig, jederzeit neu „eröffnet“ (engl. reopened“) erden„reopened“) werden.

In diesem Fall wird die Lösung zur Alternative zurückgestuft.


Lösungen (2)

text-based&keyboard:Resolution

input?:Issue

resolvesresolves

display?:Issue



i l? I

raises meetsmeets

point&click:Proposaltext based:Proposal

terminal?:Issue

failsfails is opposed by

usability$:Criterion availability$:Criterion

is supported by

availability-first!:Argument

is supported by


Rationale Repräsentation Erfassung Rationale Repräsentation, Erfassung, Zugriff

Ebenen von Rationale ManagementRepräsentation: Rationale-Modell

ÜErfassung: ÜbersichtErfassung: Record-and-replay Beispiel

Zugriff: Ansätze, Tools

Ebenen von „Rationale Management”

Keine Rationale-Erfassung R ti l i t i F M O li K ik ti d i d Rationale ist nur in Form von Memos, Online-Kommunikation oder in den

Köpfen der Entwickler vorhanden.

Rationale-Rekonstruktion Rationale besteht aus einem Dokument, das den endgültigen Entwurf

begründet (nachträglich)begründet (nachträglich).

Rationale-Erfassung Rationale wird zusammen mit dem Entwurf dokumentiert, noch während er

entwickelt wird.

Rationale-Integration Rationale ist die treibende Kraft des Entwurfs.


“Rationale Integration”: Methodisches Vorgehen / An Rationale Management orientierter Entwicklungsprozessg g p

Anforderungen

HerausforderungÄnderung

F ?

gÄnderung

Frage ?

Antwort !

E l tiBegründung .Entscheidung

Evolution


Repräsentation von Rationale: Problemmodelle ( Issue models“)Problemmodelle („Issue models )

löst

Problem?Lösung.

löst

Vorschlag Kriterium$genügt +

genügt nichtnicht -

befürwortet +beanstandet -

befürwortet +beanstandet -

Argument!


Repräsentation von Rationale (Fortsetzung) (Fortsetzung)

Es wurden schon viele verschiedene Problemmodelle vorgeschlagenIBIS QOC DRL Wi Wi IBIS, QOC, DRL, WinWin

Ähneln sich im Wesentlichen Unterscheiden sich in dem Maß an Detailliertheit das erfasst werden Unterscheiden sich in dem Maß an Detailliertheit, das erfasst werden

kann

Herausforderungen: Erfordern Werkzeuge für Erfassung und Zugriff Erfordern Integration in CASE- und Projektmanagementwerkzeugen Erfordern Integration in Methodik


Erfassung von Rationale

AnsätzeR k t kti Rekonstruktion

Record & replay Inkrementelle und halbautomatische Strukturierung Inkrementelle und halbautomatische Strukturierung

Herausforderungen g Große Menge von Informationen muss erfasst werden Störend für Entwickler Formalisierung von Wissen ist teuer.


Record & Replay-Beispiel: Meeting ManagementManagement

Der Moderator verschickt eine Tagesordnung. T d kt i d P bl Tagesordnungspunkte sind Probleme.

Die Teilnehmer antworten auf die Tagesordnung. Vorgeschlagene Zusätze/Änderungen sind Lösungsvorschläge oder Vorgeschlagene Zusätze/Änderungen sind Lösungsvorschläge oder

zusätzliche Probleme. Der Moderator vervollständigt die Tagesordnung und führt das Meeting

durchdurch. Jede der Diskussionen umfasst einen einzelnen Problem-Baum.

Der Protokollant zeichnet das Meeting auf.g Der Protokollant hält die Diskussionen in Form von Problemen,

Vorschlägen, Argumenten, und Kriterien fest. Der Protokollant verzeichnet Entscheidungen als Lösungen und Action Der Protokollant verzeichnet Entscheidungen als Lösungen und Action

Items. Action Items halten fest, wer, was, (bis) wann, tun soll.


Record & Replay-Beispiel: Tagesordnungspunkte eines Meetings Tagesordnungspunkte eines Meetings

TOP 3. Diskussion

I[1] Auf welche Weise sollen Gleisabschnitte aus der Datenbank geladen werden?geladen werden?

I[2] Wie sollen die Gleisabschnitte in den Transaktionen kodiert d ?werden?

I[3] Welche Abfragesprache soll für die Datenbankanfragen verwendet dwerden?


Record & Replay-Beispiel: Diskussion

I[1] Auf welche Weise sollen Gleisabschnitte aus der Datenbank geladen werden?g

Jim: Wie wäre es, wenn wir einfach nur den einen, angefragten Abschnitt laden? Das ist einfach zu implementieren, und wir können uns immer noch damit beschäftigen wenn es sich als zukönnen uns immer noch damit beschäftigen, wenn es sich als zu langsam herausstellen sollte.

A Ei P f t hi d b hb t Gl i b h itt ä hAnn: Ein Prefetching der benachbarten Gleisabschnitte wäre auch nicht viel schwieriger und um einiges schneller.

Sam: Bei der Streckenplanung brauchen wir die benachbarten Abschnitte in der Regel ohnehin. Die meisten Anfragen sind Anfragen zur Streckenplanung.

Jim: OK, dann lasst uns die Prefetching-Variante probieren. Wenn es zu kompliziert wird, können wir uns immer noch eine einfachere Lösung überlegen


Lösung überlegen.

Record & Replay-Beispiel:DiskussionsprotokollDiskussionsprotokoll

3. Diskussion

I[1] Auf welche Weise sollen Gleisabschnitte aus der Datenbank geladen werden?

P[1.1] einzelne Abschnitte!

A- Geringer Durchsatz.

A+ Einfacher.A+ Einfacher.

P[1.2] Gleisabschnitte + benachbarte Abschnitte!

A+ Insgesamt bessere Performance: Bei der Streckenplanungwerden die benachbarten Abschnitte ohnehin benötigtwerden die benachbarten Abschnitte ohnehin benötigt.

{ref: 1/31 Meeting „Streckenplanung“}

R[1] Wir implementieren P[1.2]. Das Prefetching sollte aber in der Datenbankschicht implementiert werden, um diese Entscheidung zu kapseln. Wenn alle Stricke reißen, kommen wir auf P[1.1] zurück.


zurück.

Zugriff auf Rationale

Blättern & Suchen V llt t h ö li ht d A ffi d i t t Ei t ä Volltextsuche ermöglicht das Auffinden interessanter Einträge. Verknüpfungen im Problemmodell ermöglichen ein schnelles Durchsehen

verwandter Probleme.

Passive & aktive Entwurfs-Bewertung R ti l Wi k t ti i t i b i t B t Rationale-Wissen kann zur automatisierten, wissensbasierten Bewertung

von Entwürfen genutzt werden.

Herausforderungen Sich entwickelnde Terminologie N i ti i i ß fl h R Navigation in einem großen, flachen Raum


Aktueller Stand in der Praxis

Problembasierte Stand-alone-Werkzeuge Q tM QuestMap

Problemmanagementwerkzeuge Problemmanagementwerkzeuge Work-flow-Anwendungen verfolgen Probleme und Lösungen. Integriert in die Konfigurationsverwaltung Einige Werkzeuge (e.g., ClearQuest) erlauben eine Anpassung des

Schemas.

RequisitePro Anforderungsverwaltung Integriert in die Konfigurationsverwaltung Explizite Erfassung des Rationale hinter einer bestimmten Änderung


Aktueller Stand in der Forschung

Es existieren viele Lösungen für die Repräsentation von Rationale, die sich auf spezifische Lösungen zuschneiden lassensich auf spezifische Lösungen zuschneiden lassen.

Fortschritte in Hypertexttechnologie und Verarbeitung natürlichsprachlicher Anfragen erleichtern Rationale-Zugriff

Momentane Herausforderungen Integration in Methodik Integration in Werkzeuge Aufwand Aufwand


Offene Fragen

Formalisierung von Wissen ist teuer. Ei k i t t E t f d ll fl i t t Ein konsistentes Entwurfsmodell zu pflegen ist teuer. Das Erfassen und Pflegen von Rationale ist noch teuerer.

Der Nutzen von Rational wird von den augenblicklichen Entwicklern nicht wahrgenommen. W d j i d di A b it ht i ht it d j i d ih Wenn derjenige, der die Arbeit macht, nicht mit demjenigen, der von ihr

profitiert, identisch ist, erhält diese Arbeit eine niedrigere Priorität. 40-90% aller Standart-Softwareprojekte sind abgeschlossen, bevor das

P d k li f i dProdukt ausgeliefert wird. Rationale-Erfassung ist meistens lästig.

Momentane Ansätze skalieren nicht mit den tatsächlichen Problemen.


Zusammenfassung

Erfassung von Rationale ist wichtig. Di k i Alt ti Diskussion von Alternativen Explizite Entwurfskriterien Information hat Relevanz für die Zukunft / für zukünftige Änderungeng g

Problemmodelle liefern eine gute Repräsentationf bieten strukturierte Lösung zum Erfassen von Rationale

machen es leichter, in Rationale Informationen zu navigieren

Rationale muss in jeder Phase des Prozesses integriert sein kurzfristige Motivation wichtig Einstiegsaufwand reduzieren!


kapitel 11 rationale management - sewiki.iai.uni-bonn.de · rationale sind die Überlegungen, die...

Documents