WOC2006 foranalyse workshop del 1

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

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

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 SW & HW implementering af X Use Case’s OO Ana- lyse Accept test Use Case Model næste iteration Denne figur viser vigtigheden af Use Cases i processen

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

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

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 Use Case 1 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. Aktør-kontekst diagram System/ Produkt Use Case diagram Use Case 1 Use Case 2 Use Case n ... 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 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. næste iteration Accept-testspecifikation Arkitektur-testspecifikation Udførelse af accepttest Test af arkitektur Accepttest Kravspecifikation System integrationstest Arkitekturdesign SW/HW implementering af X Use Cases V-modellen for test (i en iterativ proces)

16. Iterativ og inkrementel udvikling og aflevering af et antal Use Cases Kørende delsystem eller delprodukt næste iteration Udviklingsmodel for eksterne kunder Domæne- modellering Krav- specifikation med Use Cases 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. Iterativ og inkrementel specifikation, udvikling og aflevering af et antal Use Cases Kørende delsystem eller delprodukt næste iteration Udviklingsmodel for egenudvikling Domæne- modellering Krav- specifikation med Use Cases 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 • Alle grupper har forberedt et oplæg om dette • 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.?