1 / 9

Dokumentation

Dokumentation. Oversigt og principper Kapitel 16. 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.

tieve
Download Presentation

Dokumentation

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related