© 2005Michael Schäfer Seminar Erfahrungen & Experimente im SE Experience Bases Konstruktion und Anwendung

© 2005 Michael SchäferSeminar Erfahrungen & Experimente im SE

Experience BasesKonstruktion und Anwendung

4. Erfahrungen und Probleme bei der Entwicklung 2© 2005 Michael SchäferSeminar Erfahrungen & Experimente im SE

Gliederung

1. Einführung

2. Die Experience Base

3. Erfahrungen und Probleme bei der Entwicklung

4. Alternativer Ansatz: Die Experience Engine

5. Beispiel: Die Experience Base des Softwareprojekts

6. Der Schluss


1. Einführung

1. Einführung 4© 2005 Michael SchäferSeminar Erfahrungen & Experimente im SE

Motivation

• Früher: Hardware, Heute: Software

• Steigende Komplexität von Software

• Fehleranfälligkeit, Entwicklungskosten und -risiken steigen

• Fehler in einer Entwicklung kosten Geld

• Entsprechend wertvoll sind erfahrene Mitarbeiter

Ein erfahrener Mitarbeiter geht. Und nun?

Erfahrung muss bewahrt werden!

?

!

1. Einführung 5© 2005 Michael SchäferSeminar Erfahrungen & Experimente im SE

Die Experience Factory (EF)

• Framework für Experience Management

• Project Organization ↔ Experience Organization

Grafik: Aus [1], Seite 86


2. Die Experience Base

2. Die Experience Base 7© 2005 Michael SchäferSeminar Erfahrungen & Experimente im SE

Die Experience Base (EB)

• Kern der EF ist die Experience Base

• Enthält die gesammelten Erfahrungen und das Wissen eines Unternehmens

• Mitarbeiter können über die EB– auf Erfahrungen und Wissen zugreifen

– eigene Erfahrung und Wissen teilen

• Beispiel einer EB:

http://www.software-kompetenz.de/


Anforderungen

• Jede EB muss Methoden und Abläufe bereitstellen, um Erfahrung– zu erheben

– zu strukturieren

– als neue Objekte einzufügen

– zu suchen

– zu warten

→ Möglichst viel automatisiert!


Rollen

• Benutzer: Verwendet die EB um Probleme zu lösen, sich zu informieren, weiterzubilden

• Projektmitglied: Liefert Erfahrungen und Feedback um die EB zu erweitern und anzupassen

• Experience-Engineer: Wertet Feedback aus, verarbeitet es, und fügt diese in die EB ein

• Administrator: Verwaltet die Technik


Grundsätzliche Architekturentscheidungen

• Web-basiert ↔ Eigenständiges System

• Struktur von „Knowledge Objects“

• Art des Informationszugangs:– Pull: Vom User initiierte Suche

– Push: Vom System vorgeschlagene Inhalte

• Art und Funktionsweise der Suche (z.B. Inhaltssuche, Attribut Suche, Assoziative Suche)

• Art der Interaktion um Feedback zu erhalten (z.B. Email, Formulare, Foren)

• Mögliche Quellen für Erfahrungen (z.B. Chats, FAQs, Interviews)


3. Erfahrungen und Probleme bei der Entwicklung von Experience Bases


Knowledge Objects

• Knowledge Objects enthalten die Erfahrungen

• Die Granularität ist kritisch– Zu grob: Nicht alle

notwendigen Informationen sind enthalten

– Zu fein: Hoher Aufwand bei der Erstellung

Aufwendige Erstellung von Knowledge Objects kann die Verwendung einer EB verhindern!!

Grafik: Basierend auf [1], Seite 86


Seeding

• Problem: Eine leere EB wird niemand verwenden

• User sollten immer etwas neues und für sie interessantes vorfinden

Für eine EB müssen initiale Inhalte erstellt werden!

• Möglichkeiten für eine “Saat“:– Grundlage offline erstellen

– Zusätzliches Material: Checklisten, Vorlagen etc.

!


Wartbarkeit

• Problem: Inhalt und Aussehen einer EB ändern sich laufend

Plane für Veränderung!

• Flexibilität kann erreicht werden durch:– XML, JavaSkript, Stylesheets

– Tool-Unterstützung z.B. für Link-Aktualisierung

– Baukasten-System

!


Usability (I)

• Darstellung und Benutzerführung müssen an den User und seine Bedürfnisse angepasst sein

Auch ein gutes System kann an der Benutzbarkeit scheitern!

• Verbesserung der Usability:– Grafiken für komplexe Zusammenhänge

– Navigation (Buttons, Zoomen, Rotieren etc.)

– Prozess-orientierte Nagivation (z.B. Guided Tours)

– Perspektiven

!


Usability (II)

• Beispiel Visual Query Interface (VQI): Grafik: Aus [2], Seite 7


User Roles / Perspectives

• Unterschiedliche User brauchen unterschiedliche Sichten

• Nicht jeder muss alles können / sehen• Klare Unterscheidung in User Roles• Jede User Role hat eine andere Perspective

– Shopping-Window: Der normale User braucht nur eine Übersicht mit Standard-Interaktion

– Erfahrene User: Mehr Details, mehr Interaktionsmöglichkeiten

Fehlende Informationen/Aktionsmöglichkeiten sind genauso fatal für eine EB wie überflüssige!!


Motivation

• Warum sollte ein Mitarbeiter eine vorhandene EB verwenden?

• Gegenargumente: Z.B. wenig Zeit, Marktwert etc.

• Motivation durch konkrete Belohnungen/Bestrafung

• Bewertung der Beteiligung, Unterstützung bei Problemen

• Mit der Zeit sollte der „Wert“ der EB von alleine erkannt werden

Verwendung einer EB muss motiviert werden!!


4. Alternativer Ansatz: Die Experience Engine

4. Alternativer Ansatz: Die Experience Engine 20© 2005 Michael SchäferSeminar Erfahrungen & Experimente im SE

Die Experience Engine (EE)

• Kritik an EBs: sind sehr aufwändig, zu starr

• Ericsson Software: Förderung informeller Kommunikation in Form der EE

• Erfahrung wird in den Köpfen der Mitarbeiter gespeichert

• Soll die Fähigkeit unterstützen und schulen, Wissen und Erfahrungen an andere weiterzugeben


Ablauf der Kommunikation

4. Alternativer Ansatz: Die Experience Engine 22© 2005 Michael SchäferSeminar Erfahrungen & Experimente im SE

Bewertung der Experience Engine

• Nachteile:– Erfahrung immer noch an Mitarbeiter gebunden

– Schlechter Experience Broker ist fatal

• Vorteile:– Leicht in vorhandene Strukturen einzubinden

– Ständiger Transfer von Erfahrungen


5. Beispiel: Die Experience Base des Softwareprojekts

5. Beispiel: Die Experience Base des Softwareprojekts 24© 2005 Michael SchäferSeminar Erfahrungen & Experimente im SE

Die Experience Base des Softwareprojekts

• Zur Erinnerung: Wichtig bei der Konstruktion einer EB istSeeding, initiale InhalteWartbarkeit, VeränderungUsabilityUser Roles, PerspectivesLeichte Erstellung von Knowledge ObjectsMotivation

• Die Experience Base


6. Der Schluss

5. Der Schluss 26© 2005 Michael SchäferSeminar Erfahrungen & Experimente im SE

Literatur

Einige Beispiele für Literatur zu diesem Thema:

[1] Kurt Schneider, Thilo Schwinn: Maturing experience base concepts at DaimlerChrysler. Software Process: Improvement and Practice 6(2): 85-96 (2001)

[2] M. Mendonca, C. Seaman, V. Basili, and Y. Kim, A Prototype Experience Management System for a Software Consulting Organization, Proceedings of SEKE 2001 Conference, Buenos Aires, Argentina, June 2001 [Link]

[3] V. Basili, M. Lindvall, and P. Costa, Implementing the Experience Factory Concepts as a Set of Experience Bases, Proceedings of SEKE 2001 Conference, Buenos Aires, Argentina, June 2001 [Link]

[4] Victor R. Basili and Gianluigi Caldiera, Improve Software Quality by Reusing Knowledge and Experience, Sloan Management Review, MIT Press, Volume 37, Number 1, Fall 1995 [Link]

[5] Victor R. Basili, The Experience Factory and its Relationship to Other Improvement Paradigms, 4th European Software Engineering Conference (ESEC) in Garmish-Partenkirchen, Germany. The Proceedings appeared as the Springer-Verlag Lecture Notes in Computer Sciences Series 717, September 1993 [Link]

5. Der Schluss 27© 2005 Michael SchäferSeminar Erfahrungen & Experimente im SE

Vielen Dank!

Fragen?

1. Einführung• Motivation• Die Experience Factory

2. Die Experience Base• Die Experience Base• Anforderungen• Rollen• Grundsätzliche Architekturentscheidungen

3. Erfahrungen und Probleme bei der Entwicklung• Knowledge Objects• Seeding• Wartbarkeit• Usability• User Roles / Perspectives• Motivation

4. Alternativer Ansatz: Die Experience Engine• Die Experience Engine• Ablauf der Kommunikation• Bewertung der Experience Engine

5. Beispiel: Die Experience Base des Softwareprojekts• Die Experience Base des Softwareprojekts

?

??

??

??

?

??

?

?

Documents

© 2005Michael Schäfer Seminar Erfahrungen & Experimente im SE Experience Bases Konstruktion und Anwendung