RUP och lite användbarhet...

Transkript

1 RUP och lite användbarhet... Eva Hådding Volvo IT 1 Volvo IT en del i Volvo-koncernen Volvo Lastvagnar Volvo Bussar Volvo Anläggningsmaskiner Volvo Penta Volvo Aero Volvo Financial Services Även externa kunder, t ex Volvo Personvagnar (Ford) 2

2 Key figures 2004 Sales: SEK 6,300 million Infrastructure & Operations 50% System Development 50% Employees: approx. 4,000 Presence: at over 30 sites globally 3 Volvo IT - A global player Sweden USA United Kingdom- 110 Poland Belgium France/Spain China - 9 India Malaysia - 15 South America - 60 Australia - 30 Employees approx. 5,200 (incl. contractors) 4

3 RUP hos Volvo IT RUP-implementation påbörjades 1999 Ingen större förändringar av själva processen Dock: egen modell för verksamhetsmodellering Väl utprövad modell för att etablera RUP i projekt utbildning workshops granskningar 5

4 Projektkaos. Chaos-rapporten 34% av projekten avslutades i tid och enligt budget % misslyckades! 1 Standish Group, 2003 ( Praxis Hantera krav Använd komponentarkitekturer Modellera visuellt (UML) Verifiera kvalitet kontinuerligt Hantera ändringar Utveckla iterativt 2

5 Praxis 1: Hantera krav Praxis Hantera krav Använd komponentarkitekturer Modellera visuellt (UML) Verifiera kvalitet kontinuerligt Hantera ändringar Utveckla iterativt 3 Kravhantering Se till att ni löser de verkliga problemen bygger det rätta systemet mha ett systematiskt tillvägagångssätt för kravfångst organisation dokumentation hantering av de föränderliga kraven på en programvarutillämpning. 4

6 Praxis 2: Använd komponentarkitekturer Praxis Hantera krav Använd komponentarkitekturer Modellera visuellt (UML) Verifiera kvalitet kontinuerligt Hantera ändringar Utveckla iterativt 5 Förändringståliga, komponentbaserade arkitekturer Förändringstålig Uppfyller nuvarande och framtida krav Underlättar utbyggnad Möjliggör återanvändning Kapslar in systemberoenden Komponentbaserad Återanvänd eller anpassa komponenter Välj bland kommersiellt tillgängliga komponenter Vidareutveckla existerande programvara inkrementellt 6

7 Praxis 3: Modellera visuellt (UML) Praxis Hantera krav Använd komponentarkitekturer Modellera visuellt (UML) Verifiera kvalitet kontinuerligt Hantera ändringar Utveckla iterativt 7 Varför visuell modellering? Fånga struktur och beteende Visa hur systemets delar passar ihop Hålla designen och implementationen konsistenta Dölja eller visa detaljer efter behov Förenkla tydlig kommunikation Dynamiska diagram Klassdiagram Användningsfallsdiagram Modeller Objektdiagram Komponentdiagram Aktivitetsdiagram Sekvensdiagram Samarbetsdiagram Tillståndsdiagram Driftsättningsdiagram Statiska diagram 8 UML erbjuder ett språk för alla inblandade

8 Praxis 4: Verifiera kvalitet kontinuerligt Praxis Hantera krav Använd komponentarkitekturer Modellera visuellt (UML) Verifiera kvalitet kontinuerligt Hantera ändringar Utveckla iterativt 9 Verifiera programvarans kvalitet kontinuerligt Programvaruproblem blir gånger dyrare att hitta och åtgärda efter driftsättning Kostnad Kostnad för åtgärdande Kostnad för uteblivna möjligheter Kostnad för förlorade kunder Förberedelse Etablering Konstruktion Överlämning 10

9 Testa varje iteration Iteration 1 Iteration 2 Iteration 3 Iteration 4 UML-modell och implementation Testsvit 1 Testsvit 2 Testsvit 3 Testsvit 4 Tester 11 Praxis 5: Hantera ändringar Praxis Hantera krav Använd komponentarkitekturer Modellera visuellt (UML) Verifiera kvalitet kontinuerligt Hantera ändringar Utveckla iterativt 12

10 The Configuration and Change Management (CCM) Cube 13 Hantera förändringar Ändringshantering Konfigurationshantering 14

11 Praxis 6: Utveckla iterativt Praxis Hantera krav Använd komponentarkitekturer Modellera visuellt (UML) Verifiera kvalitet kontinuerligt Hantera ändringar Utveckla iterativt 15 Egenskaper hos vattenfallsutveckling Vattenfallsprocess Kravanalys Design Kodning och enhetstest Delsystemintegration Systemtest Försenar möjligheten att bekräfta kritiska riskåtgärder Mäter framskridande genom att utvärdera arbetsprodukter som är dåliga på att visa mängden återstående arbete Försenar och försvårar integration och testning Förhindrar tidig driftsättning Leder ofta till stora, oplanerade iterationer 16

12 Iterativ utveckling producerar körbara utgåvor Risk! Krav Analys & design Initial planering Planering Projektledning Implementation Test Utvärdering Varje iteration resulterar i en körbar utgåva Driftsättning 17 Riskprofiler Vattenfallsrisk Risk Riskreducering Iterativ risk Tid 18

13 RUP förverkligar dessa praxis Praxis En praktisk process Hantera krav Använd komponentarkitekturer Modellera visuellt(uml) Verifiera kvalitet kontinuerligt Hantera ändringar Utveckla iterativt 19 Processtruktur - Livscykelfaser Förberedelse Etablering Konstruktion Överlämning tid Rational Unified Process definierar fyra faser: Förberedelse (Inception) Definierar projektets omfattning Etablering (Elaboration) Planera projektet, specificera egenskaper, ta fram grundversion av arkitekturen Konstruktion (Construction) Bygg produkten Överlämning (Transition) Överlämna produkten till slutanvändarna 20

14 Fasgränserna utgör större milstolpar Förberedelse Etablering Konstruktion Överlämning tid Milstolpe: Livscykelmål Milstolpe: Initialt funktionsduglig Milstolpe: Livscykelarkitektur Produktutgåva 21 Iterationer och faser Förbered. Etablering Konstruktion Överlämning Iteration F1 Iteration E1 Iteration E2 Iteration K1 Iteration K2 Iteration K3 Iteration Ö1 Iteration Ö2 Mindre milstolpar: Interna utgåvor 22

15 Nio discipliner 23 Tillsammans blir det: Ett iterativt tillvägagångssätt I en iteration går man igenom alla discipliner Discipliner grupperar aktiviteter logiskt 24

16 RUP är en omfattande process, ett processramverk RUP bör införas stegvis RUP måste anpassas till organisationen till projektet 3 Även RUP har sina brister... Dåligt stöd för användbarhet Produkten RUP on-line är svåranvänd Svårnavigerad Hög inlärningströskel Ojämn kvalitet på innehåll Omfattande process, många dokument Tillämpning i praktiken... 4

17 Användarcentrering i RUP Requirements: Analysis & Design: Deployment: Conceptual Road Map: Usability Engineering Concepts: User-Centered Design, Usability Testing Guidelines: Role playing, Interviews, Storyboarding, User Interface etc Use Cases Ux Plug-In 5 Användningsfall och användarcentrering... + Fokus på användarna och deras uppgifter!! - Oftast bara beskrivning av nuläget... - Användarna är inte utvecklare... - Sekventiell struktur... - Ett användningsfall blir ett fönster... - Ingen entydig definition... Användarna ska delta! 6

18 Användarcentrering i RUP Detta kunde ha varit bättre Användbarhet är utspritt och otydligt kan nedprioriteras eller helt enkelt försvinna Ingen samordnande, ansvarig roll Detta är bra! Användningsfall... Fokus på krav Iterativ utveckling Tvärdisciplinärt samarbete 7 Design & Usability discipline Volvo IT 8

19 Arbete pågår... IBM paketerar sin generella användbarhetskunskap i RUP-format... 9 Frågor? eva.hadding@volvo.com 10

20 IBM Software Group Real World Trends Impacting Software Best Practices Per Kroll, Development Manager of RUP 2004 IBM Corporation IBM Software Group Rational software Key Principles for Business-Driven Development 2

21 IBM Software Group Rational software Principle: Adapt the Process Benefits Lifecycle efficiency, open/honest communication of risks Pattern Adapt the process to the size and distribution of the project team, to the complexity of the application, and to the need for compliance Precision and formality evolve from light to heavy over the project lifecycle as uncertainties are resolved Improve your process continuously Anti-patterns More process is better Always using the same amount of process throughout the lifecycle 3 IBM Software Group Rational software Principle: Balance Stakeholder Priorities Benefit Align applications with business and user needs Reduce custom development, and optimize business value Pattern Understand what assets you can leverage; and balance user needs and reuse of assets Define and prioritize business processes and user needs, and couple user needs to software capabilities Center development activities around user needs Anti-pattern Requirements focus drives towards custom solution Achieve precise and thorough requirements before any project work begins 4

22 IBM Software Group Rational software Principle: Collaborate Across Teams Benefits Team productivity, fewer meetings Better coupling between business needs, and the development and operations of software systems Pattern Motivate people to perform at their best Encourage cross-functional collaboration Provide effective collaborative environments Integrate business, software, and operation teams Anti-pattern Nurture heroic individuals and arm them with power tools 5 IBM Software Group Rational software Principle: Demonstrate Value Iteratively Benefits Early risk reduction Higher predictability Trust among stakeholders Pattern Attack major technical, business and programmatic risks first Enable feedback by delivering incremental user value in each iteration Demonstrations provide more tangible insight into progress/quality Embrace and manage change Adaptive management using an iterative process Anti-pattern Plan the whole lifecycle in detail, track variances against plan Less reliance on expensive and error prone human inspection Assess status by reviewing specifications 6

23 IBM Software Group Rational software Principle: Elevate the Level of Abstraction Benefits Productivity Reduced complexity Pattern Plan with evolving levels of details Reuse existing assets Reduce the amount of human generated stuff through higher-level tools and languages Architect for resilience, quality, understandability, and complexity control (Focus on architecture first) Anti-pattern Go directly from vague high-level requirements to custom-crafted code 7 IBM Software Group Rational software Principle: Focus Continuously on Quality Benefits Higher quality and earlier progress/quality insight Pattern Team responsibility for end product Test early and continuously Incrementally build test automation Anti-pattern Peer-review all artifacts, rather than also driving partial implementation and testing to discover issues Complete and unit test all code before integration testing System level behaviors tested late in the lifecycle 8

24 IBM Software Group Rational software Key Principles for Business-Driven Development 9 IBM Software Group Rational software Key Principles for Business-Driven Development < 10