WOC2006 foranalyse workshop del 1

Præsentationer af emnet: "WOC2006 foranalyse workshop del 1"— Præsentationens transcript:

1 WOC2006 foranalyse workshop del 1
Foranalyse samt OOA & OOD baseret udviklingsproces og kravspecifikation

2 Agenda Sidste gang: Intro til OOA & OOD baseret udviklingsproces
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

3 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”

4 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

5 Iterative Rapid Development Proces
Spiral model slutmål Start ROPES

6 En Use Case drevet og iterativ udviklingsmodel
Analyse og krav- specifikation Krav- spec. med Use Case Model Arki-tektur design System integrations test OO Ana- lyse SW & HW implementering af X Use Case’s Accept test Use Case Model næste iteration Denne figur viser vigtigheden af Use Cases i processen

7 SW & HW implementering af X Use Case’s Arki-tektur design System Integrations test SW implementering af X Use Case’s Detaljeret design Implemen- tering Unit test HW implementering af X Use Case’s Mekanistisk SW Integrations

8 Specifikationsaktiviteter
Udarbejd en Use Case baseret Kravspecifikation Overordnet domænemodel Krav- specifikation med Use Cases Produkt- oplæg Review Udarbejd en Accepttest specifikation Udarbejd evt. en Prototype Accepttest specifikation ver. 0.x Review Prototype

9 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

10 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

11 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

12 Use Cases og Domænemodel
Klasse A Klasse B UC1 spec. ..A...B …C... ...A...C.... Klasse C Klasse D Klasse E Use Case 2 UC2 spec. Klasse F ..C...D... …E.... ......F...C

13 Kravspecifikation med Use Cases
System/ Produkt Aktør-kontekst diagram 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 Use Case diagram Use Case 1 Case 2 Case n ... Følg SPU-vejledningen for KS undtagen for kapitel 3, som specificeres med brug af use case beskrivelsers

14 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

15 V-modellen for test (i en iterativ proces)
næste iteration Accept-testspecifikation Arkitektur-testspecifikation Udførelse af accepttest Test af arkitektur Kravspecifikation Accepttest Arkitekturdesign System integrationstest SW/HW implementering af X Use Cases

16 Udviklingsmodel for eksterne kunder
Domæne- modellering Iterativ og inkrementel udvikling og aflevering af et antal Use Cases Kørende delsystem eller delprodukt Krav- specifikation med Use Cases næste iteration Komplet kravspecifikation = aftale/kontraktgrundlag Denne udviklingssituation anvendes typisk når man er underleverandør til en ekstern kunde, der har bestilt systemet eller produktet der udvikles.

17 Udviklingsmodel for egenudvikling
Domæne- modellering Iterativ og inkrementel specifikation, udvikling og aflevering af et antal Use Cases Kørende delsystem eller delprodukt Krav- specifikation med Use Cases næste iteration Denne udviklingssituation kunne anvendes ved udvikling af firmaet egne systemer eller produkter – bør tilstræbes anvendt ved komplet nyudvikling

18 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.

19 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

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 Udarbejdelse af fælles deployment diagram

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