Management von Anforderungen im Rational Unified Process (RUP)

Transkript

1 Management von Anforderungen im Rational Unified Process (RUP) Peter Fröhlich ABB DECRC Heidelberg Fröhlich-8/98-1 Themen: Was ist RUP? RM im RUP Core Workflows Dokumente Tools Erfahrungen RUP Objectory (Jacobsen, 92) Rational Software Process (Kruchten et al, 96) Fröhlich-8/98-2 Rational Objectory Process (ROP) 4.1 Rational Unified Process (RUP) 5.0 Rational Unified Process (RUP) 5.1 Rational Unified Process (RUP) 5.5 Changed Terminology CM and CRM Class -> Component Performance Testing Business Modeling More references to tools 1

2 RUP als Produkt 2000 Seiten HTML, Templates, Tool-Mentoren Einstiegspunkte Phasen Workflows Workers (Rollen) Artifacts Tools Templates Fröhlich-8/98-3 Fröhlich-8/98-4 2

3 RUP - Eigenschaften Inkrementell und Iterativ Tool-gestützt Starke Verknüpfung mit UML-Notation Anpaßbar Fröhlich-8/98-5 RUP: Inkrementeller Prozeß Entwicklung des Systems als Folge ausführbarer Teilsysteme (Ausbaustufen) Vision System (Integ. & Getestet) Fortschritt belegt durch ausführbare Systeme in richtiger Technologie und Architektur Zusätzliche Requirements in jedem Inkrement, Vision von Anfang an bekannt Fröhlich-8/98-6 3

4 RUP Phasen Inception Elaboration Construction Transition Milestone 1 Lifecycle Objectives Milestone 2 Lifecycle Architecture Milestone 3 Initial operational capability Milestone 4 Product Release Zeit Fortschritt der Requirements: Identifikation aller Use Cases Beschreibung wichtiger Use Cases Beschreibung der meisten Use Cases (80%) Supplementary Specs Beschreibung der restlichen Use Cases Fröhlich-8/98-7 Core Workflows Business Modeling Requirements Inception RUP Übersicht Phases: Elaboration Construction Transition A & D Implementation Test Iteration n n+1... Fröhlich-8/98-8 4

5 Business Modeling Fröhlich-8/98-9 BUC Realizations Business -> System Fröhlich-8/

6 Requirements Req. Attributes Fröhlich-8/98-11 Dokumentenstruktur Glossar Aktorendokument Use Case Modell Use Case Dokument Supplementary Specification Use Case Realisierungen Use Case Attribute Fröhlich-8/

7 Use Case Modell Student Register for courses Billing system Use Case Dokument Name, Brief Description, Flow of Events Pre / Post-condition Extension Points Fröhlich-8/98-13 Supplementary Specification Minimales Template (FURPS) 1. Functionality 2. Usability 3. Reliability 4. Performance 5. Supportability Fröhlich-8/

8 Use Case Realisierungen Lieferant : Lieferant sendet Kunde : Kunde schreibt Quittung : Quittung Fröhlich-8/98-15 Tool Unterstützung RequisitePro Req Status Author Prio Requirements Requirements Document (Microsoft Word) Requirements Views Attributes Dependencies Fröhlich-8/98-16 Requirements Database (Microsoft Access) 8

9 Tools Eigenschaften RequisitePro Links zu Rose und SQA Traceability Views Versionierung von Requirements Konfigurierbare Attribute und Datenbankviews Fröhlich-8/98-17 Beschreibung des Prozesses Viele Einstiegspunkte Hoher Detaillierungsgrad Surfen im Prozess Fröhlich-8/

10 Fröhlich-8/98-19 Fröhlich-8/

11 Fröhlich-8/98-21 Erfahrungen - allgemein Instabile Prozeßdefinition Ständige Modifikationen, neue Bereiche Gute Präsentation Rollen, Workflowkonzept Tutorial-Charakter dank hohem Detaillierungsgrad (für technische Aktivitäten trotzdem nicht ausreichend) Mitarbeiter begeistern sich für RUP Fröhlich-8/

12 Erfahrungen - allgemein (2) Suggeriert manchmal, daß alles ganz einfach ist Umfang und technische Schwierigkeit des Inhaltes werden leicht unterschätzt z.b. Notwendigkeit des Tailorings spät erkannt Templates nicht ausgereift Teilweise zu einfach (Non-functional Req) Architektur-Template führt zu Mißverständnissen Fröhlich-8/98-23 Use Case Philosophien Ansatz nach Cockburn Ziel-basiert Decomposition (solange für den Benutzer interessant) (nicht auf Software-Ebene - Fowler) Kleine Schritte in prägnanter Formulierung Actor - Action - Target Formalere Darstellung der Sequenzen Fröhlich-8/

13 Use Case Philosophien (2) RUP (Rational Consultants) Nur eine Ebene von Business/System use cases Informelle/neutrale Terminologie Description statt Goal Main Flow statt Main Success Scenario Nicht alle Sequenzen beschreiben sondern textuelle Hinweise geben (Falls... wiederhole ab Schritt 5) Längere Texte bei den einzelnen Schritten Fröhlich-8/98-25 Use Case Philosophien (3) Erfahrungen (Umstellung auf RUP) positiv Einfaches Rational-Template wird als angenehmer empfunden Vermeidung der Dekomposition hilft bei Requirements- Erstellung zu beachten Zielorientierung darf nicht aufgegeben werden Schritte nach Prinzipien der Requirements-Formulierung gestalten (Rational-Beispiele oft zu romanartig) Formlose Beschreibung der Abläufe ohne Main success scenario kann zu Sammel-Usecases führen Fröhlich-8/

14 Use Case Realisierungen Business Use Case Realizations Ziele: Kommunikation Finden von Entitäten für das Domänen-Modell Erweiterung von UML durch Stereotypen Fröhlich-8/98-27 Erfahrungen - Use Case Realisierungen Business Use Case Realizations - Probleme Zweifelhafte Semantik, Mißverständnisse bei der Notation Lieferant : Lieferant Kunde : Kunde schreibt sendet Quittung : Quittung empfängt Quelle neuer Inkonsistenzen Analyse des Use Case Dokumentes liefert äquivalentes Ergebnis Fröhlich-8/

15 Fröhlich-8/98-29 Erfahrungen - Tools Zusammenspiel der Tools noch in der Entwicklung Traceability-Lücke bei Befolgung des Prozesses RequisitePro Einfaches Tool, steile Lernkurve Bekannte Umgebung (Word) anschaulich, aber problematisch bei Kopieren, Verschieben von Requirements Formatierung Attributänderung (da Redundanz zwischen DB und Text schwer zu vermeiden ist) großen Dokumenten Reporting mit SoDA Einzige Möglichkeit Erfahrung - Tools (2) konsistente DB-Attribute mit Requirements-Texte zu reporten Rose und RequisitePro zusammenzuführen Aufwendig, besonders wenn eigene Templates verwendet werden (was fast unvermeidlich ist) Sichert Konsistenz Fröhlich-8/