WOC2006 foranalyse workshop del 1

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


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”


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


Iterative Rapid Development Proces

Spiralmodel

slutmålStart

ROPES


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


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


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


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


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


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


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.


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


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


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)


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


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


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.


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


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


Herfra

• Hvad kunne I tænke jer at høre nærmere om på næste Workshop– Mere Use Case– Kravspec.?

WOC2006 foranalyse workshop del 1

Documents

Transcript of WOC2006 foranalyse workshop del 1