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

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

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 Spiral model slutmål Start ROPES

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

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

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

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

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

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

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

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.

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

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