RUP och lite användbarhet... Eva Hådding Volvo IT eva.hadding@volvo.com Eva Hådding, Consulting Services, 2006-11-20 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) Eva Hådding, Consulting Services, 2006-11-20 2
Key figures 2005 Sales: SEK 7 billion Infrastructure & Operations 50% System Development 50% Employees: approx. 6,000 Presence: at over 30 sites globally Eva Hådding, Consulting Services, 2006-11-20 3
RUP hos Volvo IT RUP-implementation påbörjades 1999 Ingen större förändringar av själva processen Dock: egna metoder för verksamhetsmodellering Väl utprövad modell för att etablera RUP i projekt utbildning workshops granskningar Eva Hådding, Consulting Services, 2006-11-20 4
Projektkaos. Chaos-rapporten 34% av projekten avslutades i tid och enligt budget...... 66% misslyckades! 1 Standish Group, 2003 (www.standishgroup.com)
Praxis Hantera krav Använd komponentarkitekturer Modellera visuellt (UML) Verifiera kvalitet kontinuerligt Hantera ändringar Utveckla iterativt 2
Praxis 6: Utveckla iterativt Praxis Hantera krav Använd komponentarkitekturer Modellera visuellt (UML) Verifiera kvalitet kontinuerligt Hantera ändringar Utveckla iterativt 3
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 4
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 5
Riskprofiler Vattenfallsrisk Risk Riskreducering Iterativ risk Tid 6
RUP förverkligar dessa praxis Praxis En praktisk process Hantera krav Använd komponentarkitekturer Modellera visuellt(uml) Verifiera kvalitet kontinuerligt Hantera ändringar Utveckla iterativt 7
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 8
Fasgränserna utgör större milstolpar Förberedelse Etablering Konstruktion Överlämning tid Milstolpe: Livscykelmål Milstolpe: Initialt funktionsduglig Milstolpe: Livscykelarkitektur Produktutgåva 9
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 10
Nio discipliner 11
Tillsammans blir det: Ett iterativt tillvägagångssätt I en iteration går man igenom alla discipliner Discipliner grupperar aktiviteter logiskt 12
Att använda RUP RUP är en omfattande process, ett processramverk RUP bör införas stegvis RUP måste anpassas till organisationen till projektet Eva Hådding, Consulting Services, 2006-11-20 1
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 Eva Hådding, Consulting Services, 2006-11-20 2
Användarcentrering i RUP Detta kunde ha varit bättre Detta är bra! Användbarhet är utspritt och otydligt kan nedprioriteras eller helt enkelt försvinna Ingen samordnande, ansvarig roll Tunt och ofullständigt beskrivet Användningsfall... (Use Cases) Fokus på krav Iterativ utveckling Tvärdisciplinärt samarbete Eva Hådding, Consulting Services, 2006-11-20 3
Design & Usability discipline Volvo IT Eva Hådding, Consulting Services, 2006-11-20 4
D&U i praktiken Samarbete med kravdisciplinen Ett eller två team? Egna dokument eller projektgemensamma? Vad kommer först krav eller D&U?... Samarbete med övriga discipliner - ett generellt problem för användbarhetsområdet Eva Hådding, Consulting Services, 2006-11-20 5
Arbete pågår... IBM paketerar sin generella användbarhetskunskap i RUP-format... Eva Hådding, Consulting Services, 2006-11-20 6
Ä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... Eva Hådding, Consulting Services, 2006-11-20 7
Dalande stjärna...? Eva Hådding, Consulting Services, 2006-11-20 8
Frågor? eva.hadding@volvo.com Eva Hådding, Consulting Services, 2006-11-20 9
IBM Software Group Real World Trends Impacting Software Best Practices Per Kroll, Development Manager of RUP 2004 IBM Corporation
IBM Software Group Rational software Defining Principles for Business-Driven Development Input Current 6 best practices for IBM Rational Ongoing workshops with +1,000 development managers and executives in 1999-2005 Input from +80 key technical leaders within IBM How did we develop these principles? 10 months of collaborative effort with various workgroups Many rounds of feedback from technical communities within IBM Guiding focus Based on real world experiences Applies to a broad set of contexts Time resistant 2
IBM Software Group Rational software Key Principles for Business-Driven Development 3
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 4
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 5
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 6
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 7
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 8
IBM Software Group Rational software 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 9
IBM Software Group Rational software Key Principles for Business-Driven Development 10