Dokumentation

1. Dokumentation Oversigt og principper Kapitel 16

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

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

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

5. Klassediagram - strukturbillede

6. 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).

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

8. 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).

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