Upload
others
View
16
Download
0
Embed Size (px)
Citation preview
2
Projektkaos….
Chaos-rapporten
28% av projekten avslutades i tid ochenligt budget.49% av projekten drog över de ursprungliga estimaten.- Tid i genomsnitt 63%.- Kostnad i genomsnitt 45%.
23% av projekten lades ner.
Standish Group, ‘01 (www.standishgroup.com)
3
PraxisPraxis
Hantera kravAnvänd komponentarkitekturer
Modellera visuellt (UML)Verifiera kvalitet kontinuerligt
Hantera ändringarUtveckla iterativt
Hantera kravAnvänd komponentarkitekturer
Modellera visuellt (UML)Verifiera kvalitet kontinuerligt
Hantera ändringarUtveckla iterativt
4
Praxis 1: Hantera krav
PraxisPraxis
Hantera kravAnvänd komponentarkitekturer
Modellera visuellt (UML)Verifiera kvalitet kontinuerligt
Hantera ändringarUtveckla iterativt
Hantera kravAnvänd komponentarkitekturer
Modellera visuellt (UML)Verifiera kvalitet kontinuerligt
Hantera ändringarUtveckla iterativt
5
Kravhantering
Se till att nilöser de verkliga problemenbygger det rätta systemet
mha ett systematiskt tillvägagångssätt förkravfångstorganisationdokumentationhantering
av de föränderliga kraven på en programvarutillämpning.
6
Översikt över kravhantering
Problem
Behov
Egenskaper
Programvaru-krav
TestskriptDesign Anv.
dok.
ProduktProduktattatt
byggabygga
Spårbarhet
Problem-område
Lösnings-område
7
Praxis 2: Använd komponentarkitekturer
PraxisPraxis
Hantera kravAnvänd
komponentarkitekturerModellera visuellt (UML)
Verifiera kvalitet kontinuerligtHantera ändringarUtveckla iterativt
Hantera kravAnvänd
komponentarkitekturerModellera visuellt (UML)
Verifiera kvalitet kontinuerligtHantera ändringarUtveckla iterativt
8
Förändringståliga, komponentbaserade arkitekturer
FörändringståligUppfyller nuvarande och framtida kravUnderlättar utbyggnadMöjliggör återanvändningKapslar in systemberoenden
KomponentbaseradÅteranvänd eller anpassa komponenterVälj bland kommersiellt tillgängligakomponenterVidareutveckla existerande programvarainkrementellt
9
Praxis 3: Modellera visuellt (UML)
Hantera kravAnvänd komponentarkitekturer
Modellera visuellt (UML)Verifiera kvalitet kontinuerligt
Hantera ändringarUtveckla iterativt
Hantera kravAnvänd komponentarkitekturer
Modellera visuellt (UML)Verifiera kvalitet kontinuerligt
Hantera ändringarUtveckla iterativt
PraxisPraxis
10
Varför visuell modellering?Fånga struktur och beteendeVisa hur systemets delar passar ihopHålla designen och implementationenkonsistentaDölja eller visa detaljer efter behovFörenkla tydlig kommunikation
Statiskadiagram
Dynamiskadiagram
Aktivitets-diagram
Modeller
Sekvens-diagram
Samarbets-diagram
Tillstånds-diagram
Driftsättnings-diagram
Komponent-diagram
Objekt-diagram
Klass-diagramAnvändnings-
fallsdiagram
UML erbjuder ettspråk för allainblandade
11
Praxis 4: Verifiera kvalitet kontinuerligt
Hantera kravAnvänd komponentarkitekturer
Modellera visuellt (UML)Verifiera kvalitet
kontinuerligtHantera ändringarUtveckla iterativt
Hantera kravAnvänd komponentarkitekturer
Modellera visuellt (UML)Verifiera kvalitet
kontinuerligtHantera ändringarUtveckla iterativt
PraxisPraxis
12
Verifiera programvarans kvalitet kontinuerligtK
ostn
adK
ostn
ad
Kostnad för åtgärdande
Kostnad för uteblivna möjligheter
Kostnad för förlorade kunder
Kostnad för åtgärdande
Kostnad för uteblivna möjligheter
Kostnad för förlorade kunder
Programvaruproblem blir 100–1000 gångerdyrare att hitta och åtgärda efter driftsättning
Programvaruproblem blir 100–1000 gångerdyrare att hitta och åtgärda efter driftsättning
Förberedelse Etablering Konstruktion Överlämning
13
Testa varje iteration
UML-modelloch
implementation
Tester
Iteration 1Iteration 1
TestsvitTestsvit 11
Iteration 2Iteration 2
TestsvitTestsvit 22
Iteration 3Iteration 3
TestsvitTestsvit 33
Iteration 4Iteration 4
TestsvitTestsvit 44
14
Praxis 5: Hantera ändringar
Hantera kravAnvänd komponentarkitekturer
Modellera visuellt (UML)Verifiera kvalitet kontinuerligt
Hantera ändringarUtveckla iterativt
Hantera kravAnvänd komponentarkitekturer
Modellera visuellt (UML)Verifiera kvalitet kontinuerligt
Hantera ändringarUtveckla iterativt
PraxisPraxis
16
Praxis 6: Utveckla iterativt
PraxisPraxis
Hantera kravAnvänd komponentarkitekturer
Modellera visuellt (UML)Verifiera kvalitet kontinuerligt
Hantera ändringarUtveckla iterativt
Hantera kravAnvänd komponentarkitekturer
Modellera visuellt (UML)Verifiera kvalitet kontinuerligt
Hantera ändringarUtveckla iterativt
17
Egenskaper hos vattenfallsutveckling
Försenar möjligheten attbekräfta kritiskariskåtgärderMäter framskridandegenom att utvärderaarbetsprodukter som ärdåliga på att visa mängden återståendearbeteFörsenar och försvårarintegration och testningFörhindrar tidigdriftsättningLeder ofta till stora, oplanerade iterationer
Vattenfallsprocess
Kodning och enhetstest
Systemtest
Delsystemintegration
Design
Kravanalys
18
Iterativ utveckling producerar körbara utgåvor
Risk!Krav
Initialplanering
Planering
Analys & design
Implementation
Driftsättning
Utvärdering
Projektledning
Varje iteration resulterar i en körbar utgåva
Test
20
RUP förverkligar dessa praxis
PraxisEn praktisk process
PraxisEn praktisk process
Hantera kravAnvänd komponentarkitekturer
Modellera visuellt(UML)Verifiera kvalitet kontinuerligt
Hantera ändringarUtveckla iterativt
Hantera kravAnvänd komponentarkitekturer
Modellera visuellt(UML)Verifiera kvalitet kontinuerligt
Hantera ändringarUtveckla iterativt
21
Processtruktur - Livscykelfaser
FörberedelseFörberedelse EtableringEtablering KonstruktionKonstruktion ÖverlämningÖverlämning
tid
Rational Unified Process definierar fyra faser:Förberedelse (Inception) – Definierar projektetsomfattningEtablering (Elaboration) – Planera projektet, specificera egenskaper, ta fram grundversion avarkitekturenKonstruktion (Construction) – Bygg produktenÖverlämning (Transition) – Överlämna produkten till slutanvändarna
22
Fasgränserna utgör större milstolpar
FörberedelseFörberedelse EtableringEtablering KonstruktionKonstruktion ÖverlämningÖverlämning
Milstolpe:Livscykelmål
Milstolpe:Livscykel-arkitektur
Milstolpe:Initialt
funktionsduglig
Produkt-utgåva
tid
23
Iterationer och faser
IterationIterationF1F1
Iteration Iteration E1E1
IterationIterationE2E2
IterationIterationK1K1
IterationIterationK2K2
IterationIterationK3K3
IterationIterationÖ1Ö1
IterationIterationÖ2Ö2
FörberedFörbered.. EtableringEtablering KonstruktionKonstruktion ÖverlämningÖverlämning
Mindre milstolpar: Interna utgåvor
25
Tillsammans blir det: Ett iterativt tillvägagångssätt
Disciplinergrupperaraktiviteterlogiskt
I en iterationgår man igenom alladiscipliner
28
RUP är en omfattande process, ett ”processramverk”
RUP bör införas stegvis
RUP måste anpassastill organisationentill projektet
Användarcentrering i RUPRequirements: Analysis & Design:
Deployment:
Conceptual Road Map:Usability Engineering
Use CasesGuidelines: Role playing, Interviews, Storyboarding, User Interface etc
Ux Plug-InConcepts:User-Centered Design,Usability Testing
30
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!
31
Användarcentrering i RUP
Detta kunde varit bättre... Detta är bra!Detta är bra!
Användbarhet är utspritt och otydligt →kan nedprioriteras –eller helt enkelt ”försvinna”
Användbarhet är utspritt och otydligt →kan nedprioriteras –eller helt enkelt ”försvinna”
Användningsfall →användarcentreringAnvändningsfall →användarcentrering
Fokus på kravFokus på krav
Iterativ utvecklingIterativ utvecklingIngen samordnande, ansvarig roll Ingen samordnande, ansvarig roll Tvärdisciplinärt samarbeteTvärdisciplinärt samarbete