How to deal with the cube of complexity -

Größe: px

Ab Seite anzeigen:

Download "How to deal with the cube of complexity -"

Thilo Engel
vor 8 Jahren
Abrufe

1 How to deal with the cube of complexity - the difference between project success and failure Prof. Dr.-Ing. Peter Fromm Hochschule Darmstadt Karsten Kiehlmann Continental AG

2 Das Wunder Requirements Engineering Requirements Engineering steht am Anfang des Projektes Und häufig am Ende der Prozesskette Fragen: Warum haben Projekte in der Vergangenheit ohne explizites Requirements Engineering funktioniert? Sind die heute verfügbaren methodischen RE Lösungen notwendig, sind sie hinreichend? Welche Methoden sind wirtschaftlich sinnvoll? 2

3 Einige methodische Thesen Nur atomare Anforderungen sind gute Anforderungen Traceability erhöht die Produktqualität Die Einführung eines RE Tools erhöht die Produktivität des Teams Aus guten Anforderungen lässt sich automatisiert Code generieren Je detaillierter ich die Anforderungen zu Beginn eines Projektes definiere, desto deterministischer verläuft das Projekt Nur niedergeschriebene verständliche, widerspruchsfreie, eineindeutig formulierte Anforderungen führen zu einem klaren Verständnis zwischen Auftraggeber und Auftragnehmer 3

4 Einige Projekte aus dem Automotive Umfeld Projekt 1 Deutscher Kunde Anspruchsvolles Kombiinstrument Lasterhefte werden als DOORS Module geliefert Projekt 2 Deutscher Kunde Kombiinstrument mittlerer Komplexität Lastenhefte nur für Einzelkomponenten Projekt 3 Asiatischer Kunde Kombiinstrument einfacher Komplexität Lastenhefte nur für Einzelkomponenten 4

5 Projekt 1 Szenario Lange Beziehung / komplexes Gerät Lastenheften wurden themenspezifisch als DOORS Module (ca. 250) geliefert Darin enthalten ca Anforderungen Update alle 3 Monate mit Änderungen Herausforderung Analyse und Bewertung der geänderten Anforderungen Zu Beginn des Projektes manuell anhand der mitgelieferten Change Listen Später automatisiert über DOORS Lösung Automatisierte Analyse über DOORS 5

6 Batch Importer Projekt 1 Einsatz von DOORS zur Delta-Analyse DOORS Exchange Kundenspezifische Plug-Ins DOORS Consolidation Module Beyond Compare DOORS Archive Word Modification Request Database Requirements Management Metric Database (RMMDB) Excel Some Facts and figures: Initial Release 2005 Development together with HOOD DXL, Perl, VBA, Access 200k+ LOC XML Trace Together 6

7 Projekt 1 Einsatz von DOORS zur Delta-Analyse Features Textueller Vergleich der Einzelanforderungen Eintrag des Analyseergebnisses in das Dokument Unterstützung mehrerer Views 7

8 Projekt 2 Szenario Lange Beziehung Mittel-komplexes Gerät Anforderungen werden nur für einzelne Komponenten (z.b. Beleuchtung) geliefert. Know-How ist primär beim Zulieferer verfügbar. Update der Anforderungen erfolgt sporadisch. Herausforderung Übersicht über gelieferte Anforderungen behalten Sicherstellung der Analyse aller Anforderungsdokumente Lösung Manuelles Analyse Verfahren 8

9 Projekt 2 Manueller Analyse Ansatz Customer Specs 1.1..n Project Plan / Ressource Assignment Change Requests Open Item Lists 9

10 Projekt 3 Szenario Neuer asiatischer Kunde Einfacheres Gerät Aber Sprachprobleme Lange Kommunikationswege Detailfallen Herausforderung Abstimmung Spezifikation mit Kunden Klärung technischer offener Punkte Kommunikation von Änderungen Lösung Nach Eskalation Einstellung zusätzlicher Residents und Tester Folgeprojekt: Kunde fordert DOORS 10

11 Die Projekte im Vergleich Projekt Kundenzufriedenheit RE Methodik Projekt 1 ++ Advanced Projekt 2 ++ Medium Projekt 3 +/- Low Fragen: Hätte der Einsatz von DOORS bei Projekt 3 geholfen? Sind Anforderungen nötig, um ein Kombiinstrument zu beschreiben? Warum führen 4000 geänderte Anforderungen nur zu echten Change Requests? Wie erziehe ich meinen Kunden? Was mache ich, wenn die Erziehung nicht klappt? 11

12 Ein einfacherer Blick auf Requirements Engineering Es ist Aufgabe des Projektes, die Anforderungen zu implementieren nicht sie zu dokumentieren Requirement Engineering ist Kommunikation und Wissensmanagement 12

13 Verhältnis Kunde / Auftragnehmer Die Wissenslücke Wissen Kunde Wissen Auftragnehmer 13

14 Der Aspekt Wissen Kunde Weiß der Kunde, was er will? Kann und möchte er sein Wissen kommunizieren? Sind alle Stakeholder beim Kunden involviert? Welche Aspekte des Produktes sind ihm besonders wichtig? Was traut der Kunde dem Auftragnehmer zu? Auftragnehmer Versteht der Auftragnehmer, was der Kunde will? Wird das Wissen im Projektteam verlustfrei und widerspruchsfrei kommuniziert? Wissen wir, welche Aspekte dem Kunden besonders wichtig sind?. Requirement Engineering Basics Wichtiger als jede Detailmethodik 14

15 Projektkomplexität Requirements Engineering im Kontext 15

16 Best Practices für RE Basics Definition der Kommunikationsstruktur Analyse der Wissenslücken Dynamischer Detaillierungsgrad Systematische Analyse und Change Management Maßvolle Nutzung von Tools 16

17 Definition der Kommunikationsstruktur Ziel Klare Kommunikationswege im Projekt installieren Ansatz Auf Basis der identifizierten Wissenlücken die Ansprechpartner auf Kunden und Auftragnehmerseite definieren Mommunikationsmedien vereinbaren (Simulation, Modelle, etc) Infrastruktur (Ablage, ) installieren Performance der Kommunikation frühzeitig prüfen zum Kunden und intern im Projekt Benefit Verhindert späte Überraschungen, Doppelarbeit und teure Eskalationen 17

18 Analyse der Wissenslücken Ziel Identifikation der kritischen Produktfunktionalitäten Gemeinsames Big-Picture aller Stakeholder Ansatz Identifikation der relevanten Stakeholder Frühzeitig Diskussion von Features (ein Satz anstelle eines Dokuments) Erstellung von Simulationsmodellen und Mustern Benefit Frühzeitige Fokussierung der RE Aufwände mögliche 18

19 Dynamischer Detaillierungsgrad Ziel Die richtige Sprache finden. Wesentliche Aspekte im Detail und mit geeigneten Medien beschreiben. Beschreibungs- und Analyseaufwände für bekannte Features reduzieren Ansatz Artefakte bekannter Vorgängerprodukte nutzen (z.b. auch Testspezifikationen, User Manuals) Wichtige Anforderungen (z.b. Piktogramme, Protokolle) durch den Kunden selber umsetzen lassen Benefit Reduzierung der Aufwände bei der Anforderungsanalyse Fokussierung auf wesentliche Aspekte 19

20 Systematische Analyse und Change Management Ziel Jederzeit wissen, welcher vereinbarte Stand der Anforderungen umgesetzt werden soll Planung der Entwicklung (Iterationen) Ansatz Systematische Erfassung und Versionierung der Anforderungsdokumente Analyse der Dokumente planen und tracken Unklare Anforderungen über Open Item Listen klären Geänderte Anforderungen in das Change Management System einpflegen Benefit Jederzeit eindeutiger Status der Anforderungsanalyse Planung und Steuerung des Projektes nach dem ersten Muster über Change Management 20

21 Einsatz von Tools Ziel Produktivität der Analyse durch RE Tools verbessern Ansatz Ein RE Tool kann lediglich bei der Ablage, Identifikation und syntaktischer Analyse von Anforderungen helfen Ohne klares Ziel was soll durch den Tooleinsatz erreicht werden - ist die Einführung eines RE Tools häufig kontraproduktiv In der Regel müssen mehrere Mannmonate oder Jahre in die Anpassung des Werkzeugs gesteckt werden, damit sich der Einsatz tatsächlich lohnt Benefit Einfache Arbeitsschritte können vom Tool übernommen werden Arbeitsprozesse werden über das Tool erzwungen Besseres Monitoring 21

22 Rückblick auf die Thesen Nur atomare Anforderungen sind gute Anforderungen Traceability erhöht die Produktqualität Die Einführung eines RE Tools erhöht die Produktivität des Teams Aus guten Anforderungen lässt sich automatisiert Code generieren Je detaillierter ich die Anforderungen zu Beginn eines Projektes definiere, desto deterministischer verläuft das Projekt Nur niedergeschriebene verständliche, widerspruchsfreie, eineindeutig formulierte Anforderungen führen zu einem klaren Verständnis zwischen Auftraggeber und Auftragnehmer 22

23 Fazit Requirements Engineering ist in erster Linie Kommunikation und erst in zweiter Linie Dokumentation Requirements Engineering hat viele Facetten und muss im Kontext der Projektkomplexität betrachtet werden, um die richtigen Methoden auszuwählen. Bevor mit der RE-Methoden/Tool-Kür begonnen wird, müssen die RE Basics im Projekt stimmen Performante Kommunikationswege zum Kunden und im Projekt Identifikation der Wissenslücken Wahl eines vernünftigen Detaillierungsgrades der Beschreibung Etablierung eines systematischen Analyseprozesses Maßvoller Einsatz von Tools 23

24 Der Traum eines jeden Projektleiters Wenn Du ein Schiff bauen willst dann trommle nicht Männer zusammen, um Holz zu beschaffen und Arbeit einzuteilen, sondern lehre die Männer die Sehnsucht nach dem weiten endlosen Meer. Antoine de Saint-Exupéry ( ) 24

25 Mimir The Professional Project Guide Methoden aus der Praxis für die Praxis 25

26 Mimir The Professional Project Guide Inhalt Praxisnahe Prozess Workflows auf Basis CMMi Methoden für den Projektalltag, z.b Programmierrichtlinien Testmethoden Schätzmethoden Dokumententemplates, z.b. Projektplan Anforderungsspezifikation Architektur Testspezifikationen Rollenbeschreibungen und Rollenanforderungen, z.b. Projektleiter Requirement Engineer Entwickler Einfache Erweiterbarkeit für Firmenspezifika 26

27 Mimir The Professional Project Guide Konsortium 27

28 Vielen Dank für Ihre Aufmerksamkeit Prof. Dr.-Ing. Peter Fromm Hochschule Darmstadt - University of Applied Sciences FB Elektrotechnik und Informationstechnik (EIT) Birkenweg Darmstadt Tel.: +49 (6151) Fax: +49 (6151) Web: peter.fromm@h-da.de 28

Ähnliche Dokumente

Einführung und Motivation

Einführung und Motivation iks-thementag: Requirements Engineering 16.11.2010 Autor Carsten Schädel Motto Definiere oder Du wirst definiert. Seite 3 / 51 These Im Privatleben definiert jeder (seine) Anforderungen.