16.1 Mathiassen, Munk-Madsen, Nielsen & Stage, 2001 © Dokumentation Oversigt og principper Kapitel 16

16.2 Mathiassen, Munk-Madsen, Nielsen & Stage, 2001 © Generelle erfaringer med dokumentation Brugere og systemudviklere kan som regel først formulere de fuldstændige krav til et edb-system, når det er færdigt. Systemudviklere foretrækker ofte at udsætte færdiggørelse af specifikationen, indtil konstruktionen er igang. Systemudviklere har en tendens til at afgrænse sig fra brugere ved kun at acceptere helt faste specifikationer for derefter at udvikle og aflevere den færdige implementation. Brugerne har store problemer med at forstå og forholde sig til abstrakte specifikationer af bestemte forhold ved et edb- system. Under udviklingsforløbet er der behov for løbende gensidig koordinering, hvor forskellige grupper af deltagere lærer om hinandens arbejde.

16.3 Mathiassen, Munk-Madsen, Nielsen & Stage, 2001 © Skab overblik og fasthold detaljer Arbejdsredskab, hvori der kan opsamles og holdes orden på delresultater, efterhånden som de bliver lavet. Styringsredskab, der kan bruges til at afgøre, om arbejdet skrider fornuftigt frem Aftaleredskab Referencegrundlag for det videre arbejde

16.4 Mathiassen, Munk-Madsen, Nielsen & Stage, 2001 © Brugerrettet standard 1.Opgaven. Kortfattet beskrivelse af dokumentets baggrund og sammenhæng. 2.Oversigt. 2.1.Rigt billede 2.2.Systemdefinition 3.Brug. Samlet beskrivelse af systemets anvendelse i brugerens arbejde. 3.1.Navigationsdiagram 3.2.Brugssituationer (ud fra vinduer) 4.Indhold. Samlet beskrivelse af de informationer, systemet indeholder. 4.1.Strukturbillede 4.2.Forløbsbeskrivelser 5.Funktioner. Beskrivelse af systemets funktioner ud fra de vinduer, de kan aktiveres i. 6.Begrebskatalog. Oversigt over nøglebegreber. 7.Anbefalinger. Argumentation for det videre udviklingsarbejde.

16.5 Mathiassen, Munk-Madsen, Nielsen & Stage, 2001 © Klassediagram - strukturbillede

16.6 Mathiassen, Munk-Madsen, Nielsen & Stage, 2001 © Adfærdsspecifikation Generelt forløb for Artikel: Artiklen tilmeldes (tilmeldingsdato, titel, og resume). Artiklen indsendes (modtagelsesdato). Artiklen reviewes: –Den tildeles et antal reviewere (tildelingsdato). –Den bedømmes af et antal reviewere (bedømmelse). Der tages en beslutning: –Enten er artiklen ok, hvilket betyder at den udvælges og programsættes. –Eller også afvises artiklen (begrundelse). Beslutningen meddeles forfatterne (meddelelsesdato).

16.7 Mathiassen, Munk-Madsen, Nielsen & Stage, 2001 © Hvad er en prototype? En operationel model af et edb-system. Den realiserer bestemte aspekter ved dette system. En udførbar specifikation, der kan bruges til at fjerne usikkerhed om edb-systemets design. En hjælp til identifikation af vanskeligheder, klargøring af problemer og beslutninger om design. Et konkret grundlag for diskussioner mellem brugere, systemudviklere og ledelse. Er komplementær til en specifikation.

16.8 Mathiassen, Munk-Madsen, Nielsen & Stage, 2001 © Prototype: mulige reduktioner Udviklingsmæssigt: Prototypen udvikles på en anden teknisk platform og udføres på en anden maskine. Der er ikke behov for håndtering af mange, store komponenter i forskellige versioner. Der er ikke behov for sikring af kvaliteten – det gælder både koden og dokumentationen. Produktmæssigt: Prototypen er målt i “kode” klart mindre end det endelige system. Pålidelighed og robusthed betones normalt ikke. Ingen faciliteter til fejlhåndtering, backup og genstart (recovery). Datasikkerhed skal normalt ikke håndteres (autorisation).

16.9 Mathiassen, Munk-Madsen, Nielsen & Stage, 2001 © Oversigt At fastholde resultater og beslutninger på en sammenhængende måde. Analysedokument: En sammenhængende præsentation af en analyse. Designdokument: En sammenhængende præsentation af et design. Skriv kortfattet i fagprosa suppleret med formalismer. Fasthold resultater og beslutninger løbende. Mål fremdrift på dokumenterede resultater. Et analysedokument. Et designdokument. Formål Begreber Principper Resultat