Upload
yagil
View
25
Download
0
Embed Size (px)
DESCRIPTION
WOC2006 foranalyse workshop del 1. Foranalyse samt OOA & OOD baseret udviklingsproces og kravspecifikation. Agenda. Sidste gang: Intro I blev bedt om at medbringe alle relevante projektrelekvier og forberede et oplæg om hvad I har lært om problemområdet indtil nu - PowerPoint PPT Presentation
Citation preview
Ingeniørhøjskolen i Århus
WOC2006 foranalyse workshop del 1
Foranalyse samt OOA & OOD baseret udviklingsproces og
kravspecifikation
Ingeniørhøjskolen i ÅrhusSide 2 af 20
Agenda
• Sidste gang:– Intro– I blev bedt om at medbringe alle relevante projektrelekvier og forberede et oplæg om hvad I har lært om
problemområdet indtil nu
• Intro til OOA & OOD baseret udviklingsproces• Kravspecifikationsaktiviteter
• Vi vil ved fælles hjælp udarbejde en foranalyse– Alle grupper præsenterer det de har lært om problemområdet indtil videre, og hvordan de vil gribe det an– Elementer:
• fælles vision, • fælles tidsplan, • fælles logisk model af systemet (hvis relevant), • fælles teknisk platform (hvor relevant), • fælles værktøjer (versionsstyring, UML, dokument-skabelon, udviklingsmodel) • logisk opdeling af system, • fælles kravspecifikation (hvis relevant), • overordnet deployment diagram• Aftale om fælles indhold af de ugentlige statusrapporter
Ingeniørhøjskolen i ÅrhusSide 3 af 20
Softwareudvikling uden metode: Code and Fix
• Er stadig meget udbredt• Projektet er svært at budgettere, og det er umuligt at
lave en korrekt tidsplan• Ofte ændres kravene til systemet hyppigt• Test foretages usystematisk og integrationstesten er
ofte et mareridt• Ofte bliver resultatet at både budgettet og tidsplanen
overskrides • Ved aflevering indeholder programmet alligevel fejl så
kunden bliver utilfreds• Vi skal passe på at WOC projektet ikke havner her!
– Det er let at opleve et kravskred med denne typer ”kunder”
Ingeniørhøjskolen i ÅrhusSide 4 af 20
Systematisk Program Udvikling
• Ved at følge en systematisk udviklingsproces bringes ingeniørernes disciplin ind i softwareudviklingen – Kaldes for ”Software Engineering”
• Systematisk program udvikling er f.eks. at– Opdele projektet i faser og aktiviteter– Definere kravene– Anvende metoder og teknikker– Skabe synlighed vha. dokumentation og kørende programmer– Foretages systematisk test og verifikation
• I kender dette fra flere tidligere projekter, bl.a. semesterprojekterne
Ingeniørhøjskolen i ÅrhusSide 5 af 20
Iterative Rapid Development Proces
Spiralmodel
slutmålStart
ROPES
Ingeniørhøjskolen i ÅrhusSide 6 af 20
Analyse ogkrav-
specifikation
SW & HWimplementeringaf X Use Case’s
Accepttest
Arki-tekturdesign
Systemintegrations
test
OOAna-lyse
Krav-spec.
med
UseCaseModel
Use Case Model
næste iteration
Denne figur viser vigtigheden af Use Cases i processen
En Use Case drevet og iterativ udviklingsmodel
Ingeniørhøjskolen i ÅrhusSide 7 af 20
SW & HWimplementeringaf X Use Case’s
Arki-tekturdesign
SystemIntegrations
test
SW implementering af X Use Case’s
Detaljeret
design
Implemen-
tering
Unit
test
HW implementering af X Use Case’s
Mekanistisk
design
SWIntegrations
test
Ingeniørhøjskolen i ÅrhusSide 8 af 20
Specifikationsaktiviteter
Produkt-oplæg
Produkt-oplæg
Udarbejd evt. enPrototype
Udarbejd enUse Case baseretKravspecifikation
Udarbejd enOverordnet
domænemodel
Udarbejd enAccepttest
specifikation
Krav-specifikation
medUse Cases
Accepttestspecifikation
ver. 0.x
Prototype
Review
Review
Ingeniørhøjskolen i ÅrhusSide 9 af 20
Hvad er en domænemodel ?
• En domænemodel beskrives vha. et UML klassediagram suppleret med en kort beskrivelse af hver klasse
• Igen kender I domænemodellen fra tidligere projekter– Vigtige ændringer: langt mere komplekst system,
databasebaseret, deling af entiteter
• Klassediagrammet viser kun domæneklasser (dvs. ikke attributter og operationer)
• En domæneklasse:– beskriver et begreb, der er relevant i systemets eller
produktets anvendelsesområde (domæne)– er en klasse som kunden/opgavestilleren kan forstå og
forholde sig til– Eksempler:
• En løber er en entitet
Ingeniørhøjskolen i ÅrhusSide 10 af 20
Hvorfor domænemodel så tidligt ?
• Udarbejdelse af domænemodellen er med til at definere begreberne – Resultat: at der kan opnås en langt bedre og mere
konsistent kravspecifikation
• Der opnåes en bedre forståelse af domænet når domænet udforskes og modelleres vha. klasser
Ingeniørhøjskolen i ÅrhusSide 11 af 20
Domænemodellen i øvrigt• Den udarbejdes normalt af udviklerne alene
– I visse situationer kan kunden medvirke ved f.eks. indledende workshops - skal vi have kontaktpersoner med?
– WOC: flere grupper med overlappende ønsker• Faldgruber:
– Forsøg ikke at få den komplet– Brug ikke for lang tid på den– Kunder forstår sjældent UML
• Her dog evt. en undtagelse (WOC IT-gruppen)– Fælles domænemodel?
• Domænemodellen er ofte kun et internt mellemprodukt – et arbejdsredskab, men her er det ekstra vigtigt at I kommunikerer på tværs
• I visse situationer kan domæne klasse-diagrammet indgå i kravspecifikationen som bilag
Ingeniørhøjskolen i ÅrhusSide 12 af 20
Use Cases og Domænemodel
Use Case 1Klasse A
Klasse C
Klasse B
Klasse D Klasse E
Klasse F
Use Case 2
..A...B…C......A...C....
..C...D...…E..........F...C
UC1 spec.
UC2 spec.
Ingeniørhøjskolen i ÅrhusSide 13 af 20
Kravspecifikation med Use Cases
1. Indledning
2. Generel beskrivelse
3. Funktionelle krav
4. Ekstern grænseflade
5. Krav til ydelse
6. Kvalitetsfaktorer
7. Design krav
8. Andre krav
9. Del-levering
System/Produkt
Aktør-kontekst diagram
Use Case diagram
Use Case 1
Use Case 2
Use Case n...
Følg SPU-vejledningen for KS undtagen for kapitel 3, som specificeres med brug af use case beskrivelsers
Ingeniørhøjskolen i ÅrhusSide 14 af 20
Hvorfor acceptestspecifikation ?
• Accepttest specifikationen (B.Douglass’s Validation test) påbegyndes samtidigt med kravspecifikationen af følgende grunde:– Primært for at opnå en bedre kravspec. da det undersøges
om kravene er testbare• Svartiden skal være rimelig, Produktet skal være pålideligt og
brugervenligt etc.
– Det er typisk andre personer, der skriver testspec. hvorved der stilles gode spørgsmål til kravspec. som ofte er overset
– Man gør sig tidligt overvejelser over hvorledes slut eller afleveringstesten skal foretages
• Medfører at man kan planlægge udvikling af f.eks. specielle test- og simuleringssystemer
Ingeniørhøjskolen i ÅrhusSide 15 af 20
næste iteration
Accept-testspecifikation
Arkitektur-testspecifikation
Udførelse af accepttest
Test af arkitektur
Kravspecifikation Accepttest
ArkitekturdesignSystem
integrationstest
SW/HW implementering
af X Use Cases
V-modellen for test (i en iterativ proces)
Ingeniørhøjskolen i ÅrhusSide 16 af 20
Udviklingsmodel for eksterne kunder
Domæne-modellering
Krav-specifikation
medUse Cases
Iterativ og inkrementel
udvikling og aflevering af
et antal Use Cases
Kørende
delsystem
eller
delproduktnæste iteration
Denne udviklingssituation anvendes typisk når man er underleverandør til en ekstern kunde, der har bestilt systemet eller produktet der udvikles.
Komplet kravspecifikation = aftale/kontraktgrundlag
Ingeniørhøjskolen i ÅrhusSide 17 af 20
Udviklingsmodel for egenudvikling
Domæne-modellering
Krav-specifikation
medUse Cases
Iterativ og inkrementel
specifikation, udvikling og
aflevering af et antal Use Cases
næste iteration
Kørende
delsystem
eller
delprodukt
Denne udviklingssituation kunne anvendes ved udvikling af firmaet egne systemer eller produkter– bør tilstræbes anvendt ved komplet nyudvikling
Ingeniørhøjskolen i ÅrhusSide 18 af 20
Udviklingsmodel WOC
• Vi må forvente at der er relativt stor risiko for kravskred givet projektets natur
• Vi bør sikre os mod dette ved valg af udviklingsmodellen– Mulige løsninger:
• Planlagte iterationer: kan blive svært at nå• Intensivt kravspecifikationsarbejde med
fiksering af kravspec.
Ingeniørhøjskolen i ÅrhusSide 19 af 20
Hvilken model skal vi vælge?
• Diskussion– Hvilken model skal vi vælge?– Hvilke elementer skal være fælles, og hvilke grænseflader
skal vi trække?– Hvordan forholder vi os til:
• fælles vision, • fælles tidsplan, • fælles logisk model af systemet (hvis relevant), • fælles teknisk platform (hvor relevant), • fælles værktøjer (versionsstyring, UML, dokument-skabelon,
udviklingsmodel) • logisk opdeling af system, • fælles kravspecifikation (hvis relevant), • overordnet deployment diagram• Aftale om fælles indhold af de ugentlige statusrapporter
Ingeniørhøjskolen i ÅrhusSide 20 af 20
Workshop
• Udarbejdelse af fælles domæne model– Alle grupper har forberedt et oplæg om dette
• Udarbejdelse af overordnet aktør-kontekst diagram– Alle grupper har forberedt et oplæg om dette
• Udarbejdelse af fælles deployment diagram
Ingeniørhøjskolen i ÅrhusSide 21 af 20
Herfra
• Hvad kunne I tænke jer at høre nærmere om på næste Workshop– Mere Use Case– Kravspec.?