Redovisning av mikroprojekt SESAM

En presentation över ämnet: "Redovisning av mikroprojekt SESAM"— Presentationens avskrift:

1 Redovisning av mikroprojekt SESAM
Metoder och tekniker för granskning av OO-modeller - del som berör intervjuer inom Bofors-företag Torbjörn Jungeby och Hans Linderholt Saab Bofors Dynamics AB Avd RTKP Karlskoga e-post:

2 Totalt har 8 personer, representerande 4 olika projekt, intervjuats.
Inledning SESAM Syftet har varit, och är, att samla, skapa och sprida information och kunskap beträffande metoder och tekniker för granskning av OO-modeller. Intervjuer inom Bofors-företag; f d Bofors Missiles, f d Bofors Weapon Systems och Bofors Underwater Systems. Totalt har 8 personer, representerande 4 olika projekt, intervjuats.

3 Frågeställningar SESAM
Vilka problem/brister finns idag genom att man granskar dokument? Dessa är ju enbart en vy av en OO-modell. Hur skall man rent arbetsmässigt gå till väga när man granskar modeller? Skiljer sig förfarandet under olika faser av utvecklingen, vilka aspekter av modellen granskas? Vilka krav ställs på konfigurationsstyrning? Vad utgör konfigurationsenheter (configuration items) i modellen?

4 Erfarenheter från projekt A SESAM
Projektet utvecklar ett uppdragsplaneringssystem. OO, UML och Rational Rose används. Två intervjuer. Vilka problem/brister finns idag genom att man granskar dokument (dessa är ju enbart en vy av en OO-modell)? Projektet upplever inga större brister I första hand granskas modelldiagram och inte verbal beskrivning (dokument). Användarfalls-, klass- och sekvensdiagram används. Modeller mycket tydligare (entydigare att tolka) än text- beskrivningar.

5 Erfarenheter från projekt A, forts SESAM
Allmän kommentar som inte bara gäller OO-modeller: granskning av dokument kan ha fördelen att det är tydligare vad som skall granskas och efteråt vad som har granskats (i jämförelse med granskning av modell i ett modelleringsverktyg), risk med att granska modell i modelleringsverktyg kan vara att man kan tappa granskningsfokus (t ex lätt att fastna i detaljer), vilket man till stor del undviker med att dokumentera de vyer som är relevanta för dokumentet i fråga. förklaringar för varför en viss lösning valts saknas oftast i dokumentationen

6 Erfarenheter från projekt A, forts SESAM
Hur skall man rent arbetsmässigt gå till väga när man granskar modeller? Skiljer sig förfarandet under olika faser av utvecklingen, vilka aspekter av modellen granskas? Följa checklistor, som bygger på erfarenheter av vad som är viktigt att granska. En aspekt som är viktig på tidiga stadium är ansvarsfördelningen mellan olika objekt och hur lätt det kommer att vara att vidare- utveckla och/eller modifiera programvaran. Sekvensdiagrammen är viktiga att granska för förståelsen av programvarans uppbyggnad. Användandet av pekare, arv, polymorfism och andra "farliga konstruktioner" granskas (dels om det är motiverat att användas och dels om det används på rätt sätt).

7 Erfarenheter från projekt A, forts SESAM
Även att modellen är lätt att förstå granskas. Aspekter av OO-modeller som granskas i de olika faserna: kravanalys: användarfallsdiagram och -beskrivningar, preliminärutformning: gränsytedokument, Ada-specar och -typer, detaljutformning: klass- och sekvensdiagram, plus granskning av kravuppfyllelse. Vilka krav ställs på konfigurationsstyrning? Vad utgör konfigurationsenheter (configuration items) i modellen? Inga särskilda krav ställs. Modellen betraktas som del av konfigurationsdokumentationen för en konfigurationsenhet. Modeller inkluderande flera konfigurationsenheter används inte, men inga problem beträffande hantering av detta förutses.

8 Erfarenheter från projekt B SESAM
Projektet utvecklar en kontrollenhet. OO, UML och Rational Rose används. Intervju av två personer. Vilka problem/brister finns idag genom att man granskar dokument (dessa är ju enbart en vy av en OO-modell)? Modeller är lätta att granska. Diagram kopieras till dokument, vilket medför att det är svårt att hålla dokumenten aktuella då ändring i modellen medför ändring i dokumentet. Projektet använder sig inte av användarfall, utan det är krav- specifikationer som styr. De diagramtyper som används är: klass-, sekvens- och tillståndsdiagram.

9 Erfarenheter från projekt B, forts SESAM
Hur skall man rent arbetsmässigt gå till väga när man granskar modeller? Skiljer sig förfarandet under olika faser av utvecklingen, vilka aspekter av modellen granskas? Fokus skiljer sig i de olika faserna. Arbetsmässigt genomförs granskningar på samma sätt som tidigare. Vilka krav ställs på konfigurationsstyrning? Vad utgör konfigurations- enheter i modellen? Inga särskilda krav ställs. Komplext på grund av olika kunder med avvikande krav.

10 Erfarenheter från projekt C SESAM
OO och Teamwork används. Två intervjuer. Vilka problem/brister finns idag genom att man granskar dokument (dessa är ju enbart en vy av en OO-modell)? Modeller är lätta och bra att granska. Alla relevanta delar måste vara med på granskning. Ser inga direkta brister för tillfället. Om brister, dokumenten kompletteras med de data och/eller diagram som saknas. Om modellen är löst kopplad mellan olika diagram och faser riskerar man att felaktigheter inte upptäcks. Om hierarkisk modulering inte används är det lätt att modellen blir stor och komplex, vilket kan resultera i svårgranskad modell, speciellt om modellbeskrivningen skrivs ut på papper.

11 Erfarenheter från projekt C, forts SESAM
Hur skall man rent arbetsmässigt gå till väga när man granskar modeller? Skiljer sig förfarandet under olika faser av utvecklingen, vilka aspekter av modellen granskas? Granska med kravdokumentet som referens. Allokera krav på t ex användarfall, sekvensdiagram, dataflödesdiagram, etc. Annotera analysmodellen med referenser till överliggande krav. Granska gränsytor, beroenden, klassdiagram, sekvensdiagram etc. Genomgång av simuleringar, eller motsvarande manuella exekveringar, av sekvensdiagram etc är väldigt bra granskningsaktiviteter, med fokusering på centrala sekvenser.

12 Erfarenheter från projekt C, forts SESAM
Vid stor komplexitet kan modellvyer vara svåra att granska; kan ställa speciella krav på genomgångar innan granskning. Använd modelleringsverktyget för att hitta notationsfelen (checker) och lägg den manuella granskningens tyngdpunkt på feltänk, principfel etc. Alltså, låt människan göra det den är bra på och datorn det den är bra på. Vilka krav ställs på konfigurationsstyrning? Vad utgör konfigurationsenheter i modellen? Inga särskilda krav ställs. Modellen betraktas som del av konfigurationsdokumentationen för en konfigurationsenhet. Modeller inkluderande flera konfigurationsenheter används inte.

13 Erfarenheter från projekt C, forts SESAM
Generellt tycker man att det är effektivare (framförallt tidsbesparande) att utnyttja modellerna utan att transformera informationen till textdokument. Detta kräver i och för sig att alla är insatta i modellens språk, vilket anses rimligt.

14 Erfarenheter från projekt D SESAM
Projekt tar fram en funktionsmodell (funktionsprototyp). En intervju. Granskningar har inte varit speciellt prioriterade. Modeller har inte granskats, utan modellerna har mer fungerat som diskussions- underlag eller hjälpmedel för att kunna strukturera sina egna tankar under konstruktionen. De modeller som har använts har varit "Use Case"-modeller, för att ihop med kunden ta fram ett arbetssätt hur personalen ska arbeta och fungera med en framtida produkt. UML har använts på flera nivåer, dels på systemnivå för att utveckla ett fungerande bussystem och dels på lägre nivå för att utveckla noder i systemet.

15 Erfarenheter från projekt D, forts SESAM
På lägre nivå har det varit individuellt hur mycket man nyttjat UML. Följande diagramtyper har använts: "Class Diagram" "Sequence Diagram" eller "Collaboration Diagram" "State Diagram" För att förstå vilken kod som kopplas till en viss nod så förklaras det i ett utformnings-/designdokument. "Component View" har inte används. Det har visat sig att desto längre projektet lidit desto större användande av modeller; dvs, även i detta projektet så lönar sig "tänka efter först".

16 Informationssökning SESAM
Informationssökning med hjälp av internet för att finna information om erfarenheter av granskning av OO-modeller har gjorts. En hel del om granskning hittades, dock inget speciellt beträffande granskning av OO-modeller.

17 Slutsats och kommentarer SESAM
Särskilda metoder och tekniker för granskning av OO-modeller synes inte finnas i någon mångfald, om de ens finns. Detta kan bero på att OO-modellerande är en relativt ny metod för att utveckla programvara. De intervjuade ser dock inga större problem med att granska OO-modeller, snarare fördelar, t ex att informationen är mer strukturerad och entydig jämfört med enbart textinformation.