Symptom på problemen vid programvaruutveckling

Transkript

1 eller Varför är det bättre med halsbränna i början av ett projekt än i slutet? Eva Hådding ehadding@rational.com Symptom på problemen vid programvaruutveckling Användarnas och verksamhetens behov ej uppfyllda Ständigt nya krav Moduler omöjliga att integrera Svårt att underhålla Sen upptäckt av allvarliga fel Dålig kvalitet eller missnöjda användare Låg prestanda vid hög belastning Dålig koordination inom teamet Bygg- och utgåveproblem 2 Page 1

2 Praxis En praktisk process Hantera krav Använd komponentarkitekturer Modellera visuellt (UML) Verifiera kvalitet kontinuerligt Hantera ändringar Utveckla iterativt 3 Praxis 1: Hantera krav Praxis En praktisk process Hantera krav Använd komponentarkitekturer Modellera visuellt (UML) Verifiera kvalitet kontinuerligt Hantera ändringar Utveckla iterativt 4 Page 2

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. 5 Översikt över kravhantering Behov Problem Egenskaper Lösningsområde Problemområde Programvarukrav Spårbarhet Produkt att bygga Testskript Design Anv. dok. 6 Page 3

4 Praxis 2: Använd komponentarkitekturer Praxis En praktisk process Hantera krav Använd komponentarkitekturer Modellera visuellt (UML) Verifiera kvalitet kontinuerligt Hantera ändringar Utveckla iterativt 7 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 8 Page 4

5 Syftet med en komponentbaserad arkitektur Grund för återanvändning Av komponenter Av arkitekturer Grund för projektledning Planering Bemanning Leverans Intellektuell kontroll Hantera komplexitet Upprätthålla integriteten En skiktad, komponentbaserad arkitektur Verksamhets- specifikt Applikations- specifikt Anpassnings- programvara System- programvara 9 Praxis 3: Modellera visuellt (UML) Praxis En praktisk process Hantera krav Använd komponentarkitekturer Modellera visuellt (UML) Verifiera kvalitet kontinuerligt Hantera ändringar Utveckla iterativt 10 Page 5

6 Varför visuell modellering? För att: Fånga struktur och beteende Visa hur systemets delar passar ihop Hålla designen och implementationen konsistenta Dölja eller visa detaljer efter behov Uppmuntra tydlig kommunikation UML erbjuder ett språk för alla inblandade 11 Visuell modellering med Unified Modeling Language Multipla vyer Exakt syntax och semantik Klassdiagram Användningsfallsdiagram Objektdiagram Komponentdiagram Sekvensdiagram Samarbetsdiagram Modeller Dynamiska diagram Aktivitetsdiagram Tillståndsdiagram Driftsättningsdiagram Statiska diagram 12 Page 6

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

8 Testa varje iteration Iteration 1 Iteration 2 Iteration 3 Iteration 4 UML-modell och implementation Testsvit 1 Testsvit 2 Testsvit 3 Testsvit 4 Tester 15 Praxis 5: Hantera ändringar Praxis En praktisk process Hantera krav Använd komponentarkitekturer Modellera visuellt (UML) Verifiera kvalitet kontinuerligt Hantera ändringar Utveckla iterativt 16 Page 8

9 Vad vill man ha kontroll över? Säkra arbetsareor för varje utvecklare Automatiserad hantering av integration/byggen Parallell utveckling Hantering av arbetsareor Parallell utveckling CM är mer än att bara kunna checka in och checka ut RAPPORT LARM Processintegration Bygghantering 17 Egenskaper hos ett CM-system Hantering av ändringsbegäran (CRM Change Request Management) Konfigurationshantering (CM Configuration Management) Rapportering av konfigurationsstatus Spårning av ändringar Versionshantering Programvaruproduktion 18 Page 9

10 Praxis 6: Utveckla iterativt Praxis En praktisk process Hantera krav Använd komponentarkitekturer Modellera visuellt (UML) Verifiera kvalitet kontinuerligt Hantera ändringar Utveckla iterativt 19 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 20 Page 10 1

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

12 RUP förverkligar dessa praxis Praxis En praktisk process Utveckla iterativt Hantera krav Använd komponentarkitekturer Modellera visuellt(uml) Verifiera kvalitet kontinuerligt Hantera ändringar 23 Processtruktur - Livscykelfaser Förberedelse Etablering Konstruktion Överlämning tid 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 24 Page 12 1

13 Fasgränserna utgör större milstolpar Förberedelse Etablering Konstruktion Överlämning tid Milstolpe: Livscykelmål Milstolpe: Initialt funktionsduglig Milstolpe: Livscykelarkitektur Produktutgåva 25 Iterationer och faser Förbered. Etablering Konstruktion Överlämning Preliminär iteration Arkitekt. iteration Arkitekt. iteration Utv. iteration Utv. iteration Utv. iteration Överl. iteration Överl. iteration Mindre milstolpar: Utgåvor En iteration är en tydlig sekvens av aktiviteter med en grundläggande plan och värderingskriterier som resulterar i en utgåva (intern eller extern). 26 Page 13 1

14 Nio discipliner 27 Tillsammans blir det: Ett iterativt tillvägagångssätt I en iteration går man igenom alla discipliner Discipliner grupperar aktiviteter logiskt 28 Page 14 1

15 RUP är en användningsfallsdriven, arkitekturcentrisk, samt riskdriven process. 29 Nyckelbegrepp i RUP: Roller, aktiviteter, artefakter utför Roll Aktivitet Designer Use-Case Realizations Användningsfallsrealiseringar Use-Case Användningsfallsanalys Analysis ansvarig för Artefakt 30 Page 15 1

16 Arbetsflödesdetaljer Exempel: Arbetsflödet för utvecklingsmiljö Exempel: Arbetsflödesdetalj: Färdigställ projektmiljön 31 RUP är en omfattande process, ett processramverk RUP bör införas stegvis RUP måste anpassas till organisationen till projektet 32 Page 16 1

17 Användbarhet i RUP Requirements: Deployment: Environment: Use cases Roadmap: Usability Engineering Ux Plug-In Concepts: Work guidelines: Användbarhet i RUP Detta kunde varit bättre... Användbarhet är utspritt och otydligt kan försvinna Ingen samordnande, ansvarig roll Detta är bra! Användningsfall användarcentrering Fokus på krav Iterativ utveckling Tvärdiciplinärt samarbete 34 Page 17 1