Prozessverbesserung im Requirements Engineering. Erfahrungen aus Projekten mit und ohne RE

Größe: px

Ab Seite anzeigen:

Download "Prozessverbesserung im Requirements Engineering. Erfahrungen aus Projekten mit und ohne RE"

Johann Schmid
vor 8 Jahren
Abrufe

1 Prozessverbesserung im Requirements Engineering Erfahrungen aus Projekten mit und ohne RE Referentin: Gabriele Frenzel Buchenweg Pfaffenhofen a.d.roth Telefon

Gabriele Frenzel gabriele.frenzel@newtec.

2 Zu meiner Person Gabriele Frenzel Mathematikerin Trainerin und zertif. Coach Teamleitung Requirements-Engineering bei Firma NewTec Leitung des Arbeitskreises Soft Skills Required bei der GI-Fachgruppe RE 2/ 22

3 Themen Allgemeine Beschreibung der beiden Projekte historische Abfolge der Aktivitäten und Ergebnisse Stakeholder Interviews Erfolgsfaktoren und Methoden für die Veränderung des Requirement Engineering 3/ 22

Stakeholder Interviews Erfolgsfaktoren und Methoden

4 Die Projekte Zwei große IT-Projekte Projekt 1: Angeordnetes Requirements Engineering durch AG Einführung von DOORS Projekt 2: Folgeprojekt Ebenso angeordnetes Requirements Engineering Weiternutzung von DOORS 4/ 22

Einführung von DOORS Projekt 2: Folgeprojekt Ebenso

5 Rqmts. Kunden- Wünsche Systemhaus für hardwarenahe Echtzeitlösungen Aktivitäten in Projekt 1: Import in DB Komplette Dokumentation Folder Kundenwünsche Ableitung von Requirements Folder Requirements 1400 Seiten Word-Dokumentation DOORS - DB 5/ 22

6 Ergebnisse in Projekt 1: Verhältnis : Anzahl Kundenwünsche in DB Verhältnis 50 : 1 Anzahl Requirements in DB Undifferenzierter, unstrukturierter Import in DB Keine Analyse der Kundenwünsche Dokumentation und Beschreibung eines Requirements Prozesses Auslieferung eines Dokumentes Traceability-Matrix 6/ 22

in DB Keine Analyse der Kundenwünsche Dokumentation und Beschreibung eines

7 Projekt 1: ausgeliefertes Dokument zur Nachverfolgbarkeit Identifier Projectname-TA-TX-1370 Projectname-TA-TX-1380 Projectname-TA-TX-1390 Outlinks to Documentation Doc: D.1.32 Doc: Table D-A CLEAR Doc: D.1.34 Doc: Table D-A DIFFERENCE REPORT Doc: D.1.34 Doc: Table D-A DIFFERENCE REPORT => Traceability-Matrix nicht vertrauensbildend 7/ 22

Documentation Doc: D.1.32 Doc: Table D-A1-24.. CLEAR Doc: D.1.34 Doc: Table D-A1-25.

8 Ergebnisse in Projekt 1: Auftraggeber nicht zufrieden Beauftragung einer Analyse der in Projekt 1 erstellten Requirements Kriterien für die Analyse von Requirements für das Projekt nach Vorgaben verschiedener Standards (IEEE Std , IEE 1233, 1998 Edition, MIL-STD-490A Businesshandbücher Sprachlichen Regeln 8/ 22

Requirements für das Projekt nach Vorgaben verschiedener Standards (IEEE Std

9 Contract Rqmts System Rqmts. Systemhaus für hardwarenahe Echtzeitlösungen Aktivitäten in Projekt 2: Import in DB Anteil aus Vertrag Folder Contract Requirements Ableitung von System Requirements Folder System Requirements 37 Seiten Word-Dokumentation 181 Systemforderungen DOORS - DB 9/ 22

Import in DB Anteil aus Vertrag Folder Contract Requirements Ableitung

10 Aufbau des Dokumentes für Nachverfolgbarkeit Jede Kundenanforderungen wird mit Kundennummer und DOORS- Identifier im Klartext angegeben Zu jeder Kundenanforderung werden alle System Requirements mit DOORS-Identifier und Text aufgelistet, die diese Anforderung abdecken Und vice versa für die Rückverfolgbarkeit: Jedes System Requirement wird mit DOORS-Identifier im Klartext angegeben Alle Kundenanforderungen, von denen es abgeleitet wurde, werden ebenfalls im Klartext aufgelistet => hohe Akzeptanz dieses Dokumentes beim Auftraggeber 10/ 22

Und vice versa für die Rückverfolgbarkeit: Jedes System Requirement wird mit DOORS-Identifier im Klartext angegeben Alle

11 Aktivitäten in Projekt 2: Planung und Durchsetzung eines RE Prozesses Kommunikationsstrukturen im Projekt eingeführt Meetings Trainings/ Schulungen internen/ externen Review-Terminen Rollendefinition und Zuweisung von Verantwortlichkeiten im RE Sprachliche und technische Überprüfung der Requirements Erstellen von System-, Komponenten- und Element-Requirements Traceability von Kundenanforderung bis zu Dokumentation und Test 11/ 22

von Verantwortlichkeiten im RE Sprachliche und technische Überprüfung der Requirements Erstellen von

12 Ergebnisse in Projekt 2: Verhältnis : Anzahl Kundenwünsche in DB Verhältnis 1 : 5 Anzahl System Requirements in DB Auch für den Kunden lesbares und verständliches Dokument als Traceability-Matrix Vertrauensvolle Miteinander aller am Projekt beteiligten Parteien Kommunikation Gute Zusammenarbeit aller Stakeholder => Commitment zu Requirements => der Requirements Engineering Prozess wurde gelebt 12/ 22

Vertrauensvolle Miteinander aller am Projekt beteiligten Parteien Kommunikation Gute Zusammenarbeit

13 Die RE-Prozess-Schritte in Projekt 1 Projekt 2 Erhebung v. Kundenwünschen Erhebung v. Kundenwünschen Analyse v. Kundenwünschen Analyse v. Kundenwünschen Dokumentation v. Kundenw. Dokumentation v. Kundenw. Erstellung v. Requirements Erstellung v. Requirements Dokumentation v. Requirements Dokumentation v. Requirements Verfeinerung v. Requirements Verfeinerung v. Requirements 13/ 22

Requirements Erstellung v. Requirements Dokumentation v. Requirements Dokumentation v. Requirements Verfeinerung v.

14 Interviews mit den Stakeholdern Wie empfanden die anderen Projektbeteiligten die Situation in Projekt 1 und Projekt 2 Interviews mit Requirementsmanager Interview mit Requirements-Teammitgliedern Interviews mit Kunden 14/ 22

und Projekt 2 Interviews mit Requirementsmanager

15 Interview-Ergebnisse: Requirements-Manager Vorher ein echter Kampf - Wir sind auf dem richtigen Weg Bringt was gibt Sicherheit Beim letzten Projekt waren wir bei Erstellung der Traceability-Matrix kurz vorm Wahnsinn Man hat mit 2,3 Klicks alle Infos und muss nicht lange in Dokumenten suchen -> echte Zeitersparnis Wenig Änderungen, da strukturierter, mit Kunden abgesprochener Erstellungsprozess bereits vor Projektbeginn und über komplette Laufzeit (Nur 2 von 900 Requirements geändert) Konsortialpartner hatte sich mit Händen und Füßen gewehrt Nun haben sie alles einschließlich Dokumentation in DOORS Gute, projektbezogene DOORS-Dokumentation hat viel Entlastung gebracht, da alle Teammitglieder damit DOORS bedienen konnten Viele Pluspunkte bei SCAMPI Audit für CMMI Requirements Management und Development gesammelt (Level 3) 15/ 22

bereits vor Projektbeginn und über komplette Laufzeit (Nur 2 von 900 Requirements geändert) Konsortialpartner hatte sich mit Händen und Füßen gewehrt Nun haben sie alles einschließlich Dokumentation

16 Interview-Ergebnisse: Requirements-Teammitglieder (1) Vorher in Projekt 1 Keiner wusste, wo es hinging Schwer getan mit Tooleinsatz Jeder hat die Requirements für sich alleine geschrieben und hinterher fehlte die Zeit noch darüber zu diskutieren in Projekt 2 Sicherheit im Prozess: jeder wusste, wo es hinging Gemeinsames Verständnis über System durch geschlossenen Kommunikationsregelkreis Was will der Kunde <-> Ich beschreib es <-> Der Kunde prüft 16/ 22

darüber zu diskutieren in Projekt 2 Sicherheit im Prozess: jeder wusste, wo es hinging Gemeinsames Verständnis

17 Interview-Ergebnisse: Requirements-Teammitglieder (2) Einfache Arbeitszuweisung an Personal: Übersicht, Fertigstellungsgrad Strukturierte Kundenanforderungen werden zum Maß für Aufwandsschätzung Diskutieren über Requirements - learning by doing Interne Reviews : Multiplikator, jeder lernt von jedem Reviews der Beraterfirma anderer Blickwinkel Klare Systemgrenzen und Schnittstellen Controlling für SW-Entwicklung anhand der Rqmts in DOORS 17/ 22

Requirements - learning by doing Interne Reviews : Multiplikator, jeder lernt von jedem Reviews der

18 Interview-Ergebnisse: Auftraggeber/ Nutzer Fehlendes Vertrauen im Vorprojekt: Was verheimlichen die wohl wieder Jetzt wissen wir, was wir bekommen Ich bin mit wenig offenen Fragen in die Meetings gegangen, das ist nicht normal ganz ohne Bauchwandgrimmen. Wir waren auch für die Reviews vorbereitet, weil die Dokumente rechtzeitig geliefert wurden Wir möchten eigentlich auch gerne einen DOORS-Zugang Es ist eine ganz andere Zusammenarbeit mit der Firma Die Reviews fanden in ganz entspannter Atmosphäre statt Wir haben sogar festgestellt, dass wir 8 Anforderungen gar nicht brauchen Warum werden wir nicht darin geschult, wie Anforderungen auszusehen haben, dann könnten wir sie gleich richtig formulieren 18/ 22

Wir waren auch für die Reviews vorbereitet, weil die Dokumente rechtzeitig geliefert wurden Wir möchten eigentlich auch gerne einen DOORS-Zugang Es ist eine ganz andere

19 Was war anders in Projekt 2, welches waren die Erfolgsfaktoren? Einführung neuer Methoden/ Vorgehensweisen im RE Verwendung des vorhandenen Tools DOORS Andere Kommunikationsstrukturen in Projekt 2 Änderung der Kommunikation und Vorgehensweisen Verdeutlicht durch die 8 Stufen der Managements von Veränderungen nach John P. Kotter 19/ 22

DOORS Andere Kommunikationsstrukturen in Projekt 2 Änderung der Kommunikation und

20 The Eight Stage Change Process by John P. Kotter 1. Establishing a Sense of Urgency Bewusstsein für die Notwendigkeit von RE wurde geschaffen 2. Creating the Guiding Coalition Projektleiter, Leiter System Engineering und NewTec (Berater) 3. Developing a Vision and Strategy Die Visionen und Vorgehensweise im RE wurden entwickelt 4. Communicating the Vision Der RE Prozess wurde dem ganzen Team kommuniziert => Der alte Status Quo im Projekt wurde erfolgreich in Frage gestellt 20/ 22

Creating the Guiding Coalition Projektleiter, Leiter System Engineering und NewTec (Berater) 3.

21 Eight Stage Change Process Step 2 5. Empowering Broad-Based Action Einführung des RE bei allen im Projekt Beteiligten (Auftragnehmer und Auftraggeberseite) 6. Generating Short-Term Wins Erfolge bei internen Reviews/ System Design Review 7. Consolidating Gains and Producing More Change weitere Requirements-Level einführen => RE wurde in Projekt 2 erfolgreich implementiert 21/ 22

22 Eight Stage Change Process - Vision 8. Anchoring New Approaches in the Culture Dauerhafte Verankerung der RE-Tätigkeiten in dem Team/ Abteilung/ Firma Die Erkenntnis um die Bedeutung von Requirements Engineering/ Management wächst Das Verhalten der Teammitglieder hat sich verändert Soft Skills bestimmen den Verlauf des Verbesserungsprozesses 22/ 22

23 Sie können die Anforderungen oder Requirements in Ihrem Projekt nicht immer beeinflussen. Sehr wohl beeinflussen, verändern und verbessern können Sie Ihren RE Prozess. Und damit haben Sie den Schlüssel für Ihren Projekterfolg in Ihren Händen. Referentin: Gabriele Frenzel Buchenweg Pfaffenhofen a.d.roth Telefon

Ähnliche Dokumente

Was meinen die Leute eigentlich mit: Grexit?

Was meinen die Leute eigentlich mit: Grexit? Grexit sind eigentlich 2 Wörter. 1. Griechenland 2. Exit Exit ist ein englisches Wort. Es bedeutet: Ausgang. Aber was haben diese 2 Sachen mit-einander zu tun?