Optimierung von Anforderungskommunikation mit Feedback

Slides:



Advertisements
Ähnliche Präsentationen
Identifizierung und Ausbildung von Führungskräften
Advertisements

Developing your Business to Success We are looking for business partners. Enterprise Content Management with OS|ECM Version 6.
Benutzerorientierte Designprinzipien für die Microsoft-Guidelines
Risiko-Management im Projekt
Programmieren im Großen von Markus Schmidt und Benno Kröger.
Vorgehensmodell - Wasserfallmodell
Zum Leitbild der Abendschule Vor dem Holstentor
Fach Ziele Vorgehen Rollen Ergebnisse Bewertung Erfahrungen
Von David Keß, Heinrich Wölk, Daniel Hauck
On the Criteria to Be Used in Decomposing Systems into Modules

Was ist ein Team? Zwei oder mehr Leute……….
Bewertung des Prozessoptimierungsansatzes 'ITIL' am Beispiel des Projektes PolyWorkPlace bei Bayer Business Services GmbH.
Prototyping.
Universität Stuttgart Institut für Kernenergetik und Energiesysteme I nstitut für K ernenergetik und E nergiesysteme Rational Unified Process (RUP) - Definitionen.
Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE 3.2- LM 8 - LO 9 Definitionen zu LM 8.
Risiken und Chancen Risiko Beurteilung: Dazu gehört die Identifikationen von Risiken, ihre Analyse und das Ordnen nach Prioritäten. Risiko Kontrolle: Dazu.
Prozessmodelle als Teil des Management-Prozesses
Beispiel: Wasserfallmodell als einfaches Phasenmodell
Universität Stuttgart Institut für Kernenergetik und Energiesysteme Agile Software Entwicklung mit dem RUP Agile Softwareentwicklung Best Practice bei.
WIRTSCHAFTSINFORMATIK Westfälische Wilhelms-Universität Münster WIRTSCHAFTS INFORMATIK Seminar Software Agenten Agenten als Informationsfilter Referent.
Rational Unified Process (RUP) - Definitionen
eXtreme Programming (XP)
Beurteilung der Wirksamkeit von Schulungen Dr. Barbara Moos
Die Bank von morgen - eine neue Welt für IT und Kunden? 23. Oktober 2001.
Grundschutztools
Ralf KüstersDagstuhl 2008/11/30 2 Ralf KüstersDagstuhl 2008/11/30 3.
INSTITUT FÜR DATENTECHNIK UND KOMMUNIKATIONS- NETZE 1 Harald Schrom ViEWcon08.
Vorgehensmodelle: Schwergewichtige Modelle
Spezifikation von Anforderungen
Das Wasserfallmodell - Überblick
Prof. Dr. Gerhard Schmidt pres. by H.-J. Steffens Software Engineering SS 2009Folie 1 Weitere Vorgehensmodelle Der Rational Unified Process RUP –bei IBM.
Prof. Dr. Gerhard Schmidt pres. by H.-J. Steffens Software Engineering WS 2006 / 2007Folie 1 Agile Vorgehensweisen Hintergrund –in den letzten Jahren hat.
Synergieeffekte durch softwaregestützte Prozessmodelle
Fünf-Fünf-Zwei der 3. Vorlesung/Übung Requirements Engineering WS 10/11 Marin Zec.
«Die Rolle der Führung im WKS-Modell»
Management, Führung & Kommunikation
Projektvorgehen.
Framework for Integrated Test (FIT)
Service Design by EstherKnaus® Der Benchmark für Dienstleistungen
ZEvA Expert ein neuer Beratungsansatz für Hochschulen
Kanton Basel-Stadt Folie September 2005 RR Dr. U. Vischer C. Tschumi.
Präsentation läuft auch vollautomatisch ab … wie du möchtest
Auslegung eines Vorschubantriebes
Definitionen der SWT (1)
Seminar: Entwicklung verteilter eingebetteter Systeme WS05/06 Betreuer: Info:
NDK Enterprise Technologien Informationen Infrastruktur und Fallstudie Daniel Nydegger Studienleiter Enterprise System Entwicklung.
Spice Info-Point 2008 Urs Frei.
Management, Führung & Kommunikation
Projektmanagement Ziel und Umfang eines Softwareprojektes definieren
Schneider. Event. Kommunikation.
Analyseprodukte numerischer Modelle
2014 Januar 2014 So Mo Di Mi Do Fr Sa So
Management, Führung & Kommunikation
Das Unternehmen.
xRM1 Pilot Implementierung
Leben in der Dorfgemeinschaft
Unified Process Historisch-Kulturwissenschaftliche Informationsverarbeitung Übung: Planung von Softwareprojekten Dozent: Christoph Stollwerk WS 2014/2015.
Infopoint, , Jörg Wüthrich Infopoint "Social Coding", Jörg Wüthrich
Agile Softwareentwicklung
Scrum Andreas Voraberger.
7. H-forte Tagung Sind Totalunternehmer für Spitalbau-Projekte sinnvoll? 7. November 2014.
Systematisches Requirements Engineering Anforderungen ermitteln, spezifizieren, analysieren und verwalten AM2 – Planung von Softwareprojekten Dozent:
Requirements Engineering Universität zu Köln Medienkulturwissenschaften/Medieninformatik Kurzreferat in Planung von Softwareprojekten bei Herrn Christoph.
Kurze Rekapitulation aus der Einführungsvorlesung Stunde VII: Planen und Realisieren Manfred Thaller, Universität zu Köln Köln 20. Oktober 2011.
Seminar: Software-Architektur Einführender Vortrag
Persönliche Assistenz
Software Product Line Adoption
Technologietag Baugruppentest Wege der Standardisierung im Funktions- und EOL-Test Markus Koetterl National Instruments Germany GmbH.
 Präsentation transkript:

Optimierung von Anforderungskommunikation mit Feedback Kopfzeile 28.03.2017 Steer Your Development! Optimierung von Anforderungskommunikation mit Feedback 21. August 2008 Samuel Fricker fricker@ifi.uzh.ch, http://www.ifi.uzh.ch/rerg/people/fricker/ Fusszeile

Produkt-/Systemverantwortlicher und sein Umfeld (Beispiel) Fricker, Grünbacher: „Negotiation Constellations – Method Selection Framework for Requirements Negotiation“, RefsQ‘08 Conference.

Handshaking mit Stakeholdern Kopfzeile 28.03.2017 Handshaking mit Stakeholdern Select, Domain-RE Fusszeile

Handshaking mit Steuerungsgremium Kopfzeile 28.03.2017 Handshaking mit Steuerungsgremium Coalition, VORD Fusszeile

Anforderungskommunikation: Handshaking mit Entwicklungsteam Kopfzeile 28.03.2017 Anforderungskommunikation: Handshaking mit Entwicklungsteam Constituent, H-S Fusszeile

Anforderungskommunikation in Schulbüchern - Interessiert, seine Ziele zu erreichen Passiv Erfahren Bedürfnisse, Ziele, Ideen Erhebung (Elicitation) Review Review Anforderungs- Spezifikation Projektplan Review Architektur und Design … - Keine persönlichen Ziele Aktiv Unerfahren

Beobachtete Anforderungskommunikation Bedürfnisse, Ziele, Ideen - Interessiert, seine Ziele zu erreichen Aktiv Erfahren Review Anforderungs- Spezifikation Analyse des Umfangs Review Review verfeinerte Anforderungs- Spezifikation Projektplan Review Architektur und Design … - Interessiert, seine Ziele zu erreichen Passiv im RE, Aktiv in Architektur Erfahren

Problematik Produktmanager (PM): Ich habe Mühe, die Architektur des Produktes zu beeinflussen. Trotz Architekturreviews und detaillierten Vorgaben ist das gelieferte Produkt ungenügend. Entwicklungsteam: Wir bekommen nicht genügend Anforderungen und verstehen nicht, was der PM wirklich möchte. Daher schaffen wir es nicht, eine sinnvolle Implementierung zu erarbeiten.

… Eskalation Micro-Management Projektplan Architektur und Design Bedürfnisse, Ziele, Ideen - Interessiert, seine Ziele zu erreichen Aktiv Erfahren Micro-Management Projektplan Architektur und Design … - Interessiert, seine Ziele zu erreichen Passiv im RE, Aktiv in Architektur Erfahren Fricker, Gorschek, Byman, Schmidle: Handshaking: Negotiate to Provoke the Right Understanding of Requirements, in submission process

Verbesserungsziel und Fragestellungen Verbessern der Anforderungskommunikation Sicherstellung von Produkt-Akzeptanz Minimaler Aufwand für Anforderungsspezifikation Fragestellungen Machbare Spezifikations-Qualität Prinzipien der Anforderungskommunikation Kommunikationsprozess Fricker, Gorschek, Glinz: Goal-Oriented Requirements Communication in New Product Development, IWSPM’08

Erwartete vs. machbare Qualität von Anforderungsspezifikationen Standards Korrekt Eindeutig Komplett Konsistent Priorisiert Wichtigkeit Stabilität Überprüfbar Modifizierbar Nachvollziehbar Zurück: zu Quellen PM-Verantwortung Gültig Konsistent Priorisiert Stabil Nachvollziehbar (Zurück + Vorwärts) Kommunikationsprozess Notwendig Komplett Machbar Während Projekt (wenn überhaupt) Eindeutig Überprüfbar Formalisiert Neutral Struktur der Spezifikation Fricker, Gorschek, Glinz: Goal-Oriented Requirements Communication in New Product Development, IWSPM’08 IEEE Standard 830-1998: Recommended Practice for Software Requirements Specifications

Naives Modell der Anforderungskommunikation Fricker, Gorschek, Glinz: Goal-Oriented Requirements Communication in New Product Development, IWSPM’08

Effizienzsteigerung durch Feed-Forward Verständlichkeit für spezifischen Lieferanten optimieren - Innovationen in Zusammenarbeit erarbeiten - Neue Anforderungen im Detail spezifizieren - Auf bekannte Anforderungen und Ressourcen Bezug nehmen Fricker, Gorschek, Glinz: Goal-Oriented Requirements Communication in New Product Development, IWSPM’08

Verständnis gewährleisten durch Feedback Überprüfen der Absichten und Resultate - Korrigieren von inakzeptablen Absichten und Resultaten - Korrigieren von falschen Annahmen und Missverständnissen - Transferieren von Domänenwissen und Businesshintergründen Fricker, Gorschek, Glinz: Goal-Oriented Requirements Communication in New Product Development, IWSPM’08

Entwicklung als Ziel-orientiertes System Vorteile Feed-Forward Lenken von Entwicklungsentscheiden (explizite Referenzen) Wahrscheinlicheres Verständnis (Detail und Zusammenarbeit wo nötig) Einsparen von Spezifikationsaufwand (gerade genug Detail) Vorteile Feedback Kennen der wahren Ressourcen-Situation (Informationen über Machbarkeit) Absichten beeinflussen (Information über Absichten) Missverständnisse aufdecken und Implizites Wissen weitergeben (Beurteilung von Lösungsansätzen) Vertrauen bilden (Bestätigen des gemeins. Verständnisses) Fricker, Gorschek, Glinz: Goal-Oriented Requirements Communication in New Product Development, IWSPM’08

Wie setzt man Ziel-orientierte Anforderungskommunikation um? Neue Fragestellungen Welche Rolle spielen…? Etabliertes Requirements Engineering Reviews Agile Ansätze Wie setzt man Ziel-orientierte Anforderungskommunikation um?

Bezug zu etabliertem Wissen Erhebung von Anforderungen (Elicitation) - Ermittlungszyklen (Nutzerbedürfnisse, Ziele von weiteren Stakeholdern) - Systemanalyse (Modellierung) - Usability Engineering (Prototyping von Schnittstellen) Lösungsorientierte Anforderungen - Graphische Systemspezifikation (z.B. UML, Adora) - Formale Sprachen (z.B. für System-Zuverlässigkeit) Perfektionieren der Spezifikation - Verständlichkeit (Linguistische Aspekte) - Testbarkeit (Spezifikationsstil, z.B. PLANGUAGE) - Komplettheit (Kataloge von Anforderungstypen) Gemeinsame Entscheide treffen - Anpassen von Positionen und Erwartungen - Gemeinsamen Wert schaffen (Varianten, Alternativen) - Eine aus 16 Verhandlungskonstellationen Fricker, Gorschek, Glinz: Goal-Oriented Requirements Communication in New Product Development, IWSPM’08

Verhandlung: Handshaking mit Implementierungs-Vorschlägen Fricker, Gorschek, Myllyperkiö: Handshaking between Software Projects and Stakeholders, RefsQ‘07 Fricker, Gorschek, Byman, Schmidle: Handshaking: Negotiate to Provoke the Right Understanding of Requirements, in submission process

Win-Win Verhandlungsprinzipien Fricker, Grünbacher: Negotiation Constellations – Method Selection Framework, RefsQ’08 Rubin, Pruitt, Kim: Social Conflict: Escalation, Stalemate and Settlement, McGraw-Hill, 1994

Verhandlungsphasen Bestimme Deine Position Persönliche Bedürfnisse, Ziele, und Ideen Kommunikation der Positionen Akzeptanz der Position des Partners „Verhandlungs-Tanz“ Änderung der Anforderungen Änderung der Implementierungsvorschläge Bestätige die Abmachung Tuning der Abmachung Dokumentation der Abmachung End-Review (Senior Management) Change Management Handhaben von Überraschungen Grünbacher, Seyff: Requirements Negotiation. In Aurum, Wohlin: Engineering and Managing SW Requirements Fricker, Gorschek, Byman, Schmidle: Handshaking: Negotiate to Provoke the Right Understanding of Requirements, in submission process

Verhandlungsbeispiel mit Reflektionen - Interessiert, seine Ziele zu erreichen Aktiv Motivation: unterstützt Interpretation der Anforderung Anforderung - Erfahren Fricker, Gorschek, Byman, Schmidle: Handshaking: Negotiate to Provoke the Right Understanding of Requirements, in submission process

Verhandlungsbeispiel mit Reflektionen - Interessiert, seine Ziele zu erreichen Aktiv Motivation: unterstützt Interpretation des Impl.Vorschlags Implementierungsvorschlag - Interessiert, seine Ziele zu erreichen - Aktiv in Architektur - Erfahren Fricker, Gorschek, Byman, Schmidle: Handshaking: Negotiate to Provoke the Right Understanding of Requirements, in submission process

Verhandlungsbeispiel mit Reflektionen - Interessiert, seine Ziele zu erreichen Aktiv Erfahren Motivation: unterstützt Interpretation der Anforderung Neue Anforderung: Antwort auf (negativen) Effekt des Vorschlags Implementierungsvorschlag - Interessiert, seine Ziele zu erreichen - Aktiv in Architektur - Erfahren Fricker, Gorschek, Byman, Schmidle: Handshaking: Negotiate to Provoke the Right Understanding of Requirements, in submission process

Verhandlungsbeispiel mit Reflektionen - Interessiert, seine Ziele zu erreichen Aktiv Erfahren Neue Alternative (Implementierungsvorschlag) - Interessiert, seine Ziele zu erreichen - Aktiv in Architektur - Erfahren Fricker, Gorschek, Byman, Schmidle: Handshaking: Negotiate to Provoke the Right Understanding of Requirements, in submission process

Dokumentation eines Implementierungsvorschlags Minimal Titel Thema des Vorschlages Anforderungen Welche Erwartungen des Auftraggebers erfüllt? Entwurfsentscheide Welche Funktionalität und Teile sollen implementiert werden? Welche Strukturen, Stile, und Regeln befolgt werden? Welche Technologien? Welche Schnittstellen? Verhandlung Annahmen Interpretation der Anforderungen Auswirkungen Vorteile, Einschränkungen, Risiken für Stakeholder Ausgeschlossene Alternativen Alternativen mit Begründung für Ausschluss Offene Punkte z.B. Vorschlag bestätigen oder mehr Infos liefern Planung Umfang Vom Vorschlag betroffene Teile der Lösung Notwendige Aktivitäten Grundlage für Projektplanung und Aufwandschätzung Aufwandschätzung Aufwand für obige Aktivitäten mit Begründung Fricker, Gorschek, Byman, Schmidle: Handshaking: Negotiate to Provoke the Right Understanding of Requirements, in submission process

Erfahrungen aus 10 kleinen bis grossen Projekten Nachteile Implementierungsvorschläge müssen erstellt und beurteilt werden Vorteile Lerneffekt: Anforderungen werden besser. Anforderungen können „erzwungen“ werden. Rollencommitment: Klare Aufteilung von RE-Aktivitäten Wert: Reichere Variantenanalyse und bessere Entwicklungsentscheide Projektvorbereitung: Aktive Verbreitung von Anforderungsverständnis in Firma Entscheidungsgrundlagen: Mehr und bessere Infos für Auftraggeber sowie bessere Planungsgrundlagen Neutral Gegenseitige Verpflichtungen: Fördert kürzere Entwicklungszyklen Fricker, Gorschek, Byman, Schmidle: Handshaking: Negotiate to Provoke the Right Understanding of Requirements, in submission process

Messungen in 5 Projekten Termintreue: „50-70% Verbesserung“ Fehlerkosten: „40% Verbesserung“ Fricker, Gorschek, Byman, Schmidle: Handshaking: Negotiate to Provoke the Right Understanding of Requirements, in submission process

Next Steps: Our Interests Forschung auf „Gemeinschaftlichem Requirements Engineering“ Handshaking, z.B. Deckungsgrad zwischen 13% und 67% Studium weiterer Konstellationen (1-n, n-1, n-n) Peer-to-peer Technologien für Anforderungsverhandlungen Technologietransfer Training und Beratung: Fuchs-Informatik RE-Grundlagen (Zertifizierung) Handshaking, Verhandlungstechnik Priorisieren und Entscheidungsfindung Prozess-Entwicklung Samuel Fricker, http://www.ifi.uzh.ch/rerg/people/fricker/

… Danke… und viel Glück! Projektplan Architektur und Design Bedürfnisse, Ziele, Ideen Projektplan Architektur und Design …