Kvalitet av modeller (ikke i bok) + Mer om Dataflytdiagrammer (DFD)

Presentasjon om: "Kvalitet av modeller (ikke i bok) + Mer om Dataflytdiagrammer (DFD)"— Utskrift av presentasjonen:

1 Kvalitet av modeller (ikke i bok) + Mer om Dataflytdiagrammer (DFD)
Institutt for datateknikk og informasjonsvitenskap Guttorm Sindre Kvalitet av modeller (ikke i bok) + Mer om Dataflytdiagrammer (DFD) Marakas, kap. 5 TDT4175 InfoSys TDT4175 Informadsjonssystemer

2 Oversikt over forelesningen
Kvalitetssikring av modeller Motivasjon for kvalitetssikring Ulike typer kvalitetssikringsaktiviteter Semiotisk kvalitetsrammeverk (spesielt relevant for øving 5) Mer om DFD (Marakas kap 5) Hvordan lage gode DFD? DFD vs. Flytkart Prosesslogikk I morgen: Mer om DFD (eks.oppg.) + kap 7. TDT4175 InfoSys

3 Motivasjon for kvalitetssikring
Ofte forlangt i kontrakt …eller nødvendig for sertifisering (f.eks., ISO9000) Uansett nyttig for å få gode løsninger og fornøyde kunder Hva er kvalitet? Produktkvalitet vs. prosesskvalitet Funksjonalitet, anvendbarhet, ytelse, datakorrekthet, nøyaktighet, pålitelighet, sikkerhet, trygghet, interoperabilitet, vedlikeholdbarhet, … Systemløsning stemmer med spesifiserte krav Krav i overenstemmelse med kundens behov Viktig å finne feil tidlig Økte kostnader jo lenger feilen trekkes med i utviklingen TDT4175 InfoSys

4 Kvalitetssikring i IS-utv. (1)
Testing Kun aktuelt for kjørbar kode Fins ulike typer testing Mathematiske teknikker Korrekthetsbevis: hvis spesifikasjon i formelt logisk språk Beregninger F.eks. av tidsforbruk, algoritmekompleksitet Simulering F.eks., ytelsesvurdering, finne flaskehalser Gjennomgang av dokumenter Gjøres manuelt Aktuelt både for kode og dokumentasjon TDT4175 InfoSys

5 Kvalitetssikring i IS-utv. (2)
Verifisering ”Doing the thing right” Stemmer design, kode, test planer, … med kravene? Validering ”Doing the right thing” Stemmer systemet (eller kravene) med kundens reelle behov? Dvs., dokumenter / produkter i senere faser Kan sammenholdes med kravdokumenter Kravdokumentene selv Lite å sammenligne disse med annet enn evt. strategidokumenter, men disse ofte vage Kvalitetssikring vanskeligere – men minst like viktig Felle: tendens til overfokus på format heller enn innhold TDT4175 InfoSys

6 Velkjente review-teknikker
Formalitetsspektret (Wiegers, 2002) Most formal Least formal Inspection Team Review Walkthrough Pair Progr. (Pair Modelling?) Peer Deskcheck, Passaround Ad hoc review TDT4175 InfoSys

7 Forskjeller (Wiegers 2002)
Review Type Planning Prepa-ration Meeting Correc-tion Verifi-cation Inspec-tion Yes Team Review No Walk-through Pair Prog/ Modeling Con-tinuous Pass-around Maybe Ad hoc review TDT4175 InfoSys

8 Mer forskjeller (Wiegers 2002)
Characteristic Inspection Team Review Walkthrough Leader Moderator Mod / Author Author Presenter Reader Granularity Small chunks Pages/sections Author’s pref. Recorder? Yes Maybe Documented Procedure? Spec. Roles for Participants? No Checklists? Data analyzed Product appraisal determined? TDT4175 InfoSys

9 Semiotisk kvalitetsrammeverk
Domain (D) Interpre- tation (I) Language (L) Model (M) Syntactic quality Semantic Pragmatic Generelt rammeverk for å evaluere kvaliteten av konseptuelle modeller (Lindland et al, 1994) Ser på modellen som en mengde setninger Sammenligner denne med tre andre mengder TDT4175 InfoSys

10 Syntactisk kvalitet Q: Følger modellen språkets grammatikk?
Mål: syntaktisk korrekthet, M \ L = Ø To typer feil: Syntaktisk ugyldighet (a) Syntaktisk inkompletthet (b) (a) (b) TDT4175 InfoSys

11 Semantisk kvalitet Q: Stemmer modellen overens med den delen av virkeligheten (problemdomenet) som vi prøver å modellere? Mål: Validitet (gyldighet): M \ D = Ø Kompletthet: D \ M = Ø Kan sjelden oppnås 100%; må tenke kost/nytte TDT4175 InfoSys

12 Pragmatisk kvalitet Q: Forstår interessentene hva modellen sier?
Mål: forståelse (I = M) dvs., modellen blir korrekt oppfattet NB: Forstått ≠ forståelig Kan sjelden oppnås 100% Må igjen tenke kost/nytte Ulike deler av modellen kan være relevant for ulike interessenter TDT4175 InfoSys

13 Total kvalitet Hvor god er modellen i forhold til hensikten med modelleringen, i.e. Analysemodell: Dokumentere og forstå eksisterende system Analysere problemer med eksisterende system Kravmodell Gi en god fremtidig løsning for organisasjonen Dokumentere kravene på en måte som er forståelig for designere, testere etc. Total kvalitet er ikke nødvendigvis snittet av syntaktisk, semantisk og pragmatisk kvalitet Oppgave: finn syntaktiske, semantiske og pragmatiske feil i neste slide TDT4175 InfoSys

14 Faglærer 1. Forbered eksamen 2. Forbered sensur Sensor Vitass Student
mulige sensorer FAGDATA oppg Datoer, Målformer Ant. oppmeldte oppg.frist, målformer Tilbud om sensuroppdrag, respons 1. Forbered eksamen 2. Forbered sensur studentlister Sensor oppgaver oppg, LF Ø-poeng besv sensurliste poeng Vitass Student besv oppg 4. Gjør arbeid 3. Gjennomfør eksamen oppg besv karakterer studnr 5. Finn karakter karakterer poeng fremmøteinfo besv sensurlister karakterer Faglærer TDT4175 InfoSys STUDENTDATA

15 Spesielle utfordringer relatert til Ø5
Oppdiktet case Ikke noe reelt problemdomene, ingen virkelige interessenter Syntactisk kvalitet: ikke noe problem Semantisk kvalitet: vurder Konsistens innen om mellom ulike modeller Datakonservering Flytbalansering Konsistens mellom modeller og tekst Konsistens mellom det konsulentgruppa kom fram til og det som dere som kundegruppe ga uttrykk for Sunn fornuft Pragmatisk kvalitet: vurder Forstår du selv modellene og teksten? Er det deler av dokumentet som tok uforholdsmessig lang tid å forstå? Er det deler av dokumentet som du forstår, men som du tror interessenter med mindre teknisk kompetanse ville ha problemer med å forstå? TDT4175 InfoSys

16 Hvordan lage gode DFD? (1)
Følg syntaksretningslinjer Tab 5-1 Normal leseretning: venstre topp → høyre bunn Etabler klar systemgrense hva er innefor /utenfor? Intern prosess: ikke inkluder utførende mennesker / org.enheter som eksterne entiteter Klare, distinkte prosesser Selvforklarende navn Problem med å finne godt navn? Symptom på at selve prosessen er inkoherent? TDT4175 InfoSys

17 Hvordan lage gode DFD? (2)
Vær klar på formål med modellen Vil bestemme fokus, hvor mye man dekomponerer, etc. Hva trengs dekomponeres? Prosesser som er komplekse, har mye flyt inn og ut Tenk HVA, ikke HVORDAN Særlig mhp logiske diagrammer Tenk DATAFLYT, ikke kontrollflyt Flytkart: mer fokus på kontroll, mer detaljert fysisk TDT4175 InfoSys

18 Flytkart, notasjon (ANSI-standard)
Fig 5-8 TDT4175 InfoSys

19 Flytkart, eksempel (Fig 5-9)
TDT4175 InfoSys

20 Steg for utvikling av DFD
Informasjonsinnhenting (f.eks intervju, ...) Del inn aktiviteter Modeller separate aktiviteter Lag preliminært kontekstdiagram Lag preliminært toppnivå (nivå-0) diagram Dekomponer til nivå 1, 2 osv. Kombiner og juster nivå 0-n diagrammene Lag endelig diagram (sjekk konsistens) TDT4175 InfoSys

21 Analyse og bruk av DFD Kontinuerlig verifisering og validering
Er DFD'ene konsistente? Sjekk innhold av DFD Med brukere / domeneeksperter For ny/ønsket situasjon: Med uttrykte målsetninger for systemet (strategi) Modellkvalitet Kan vurderes på syntaktisk, semantisk og pragmatisk nivå TDT4175 InfoSys

22 Modellering av prosesslogikk
Kan ikke dekomponere DFD i all evighet Max 7 nivåer anbefalt, men stopp gjerne før f.eks., hvis prosessen er blitt så banal at dens indre logikk lett kan beskrives Ulike representasjonsformer for prosesslogikk: Strukturert engelsk Beslutningstrær og beslutningstabeller Tilstandsdiagrammer ... TDT4175 InfoSys

23 Structured English En slags pseudokode Syntaks vist i Tab 5-2
Navn fra DFD brukes som «variable» Sentrale elementer: sekvens, valg, repetisjon Hver prosess må ha kun et inngangspunkt og et utgangspunkt i koden Syntaks vist i Tab 5-2 Bør være enkelt for dere, går derfor ikke i detalj TDT4175 InfoSys

24 Structured English, eksempel
Table 5-3 TDT4175 InfoSys

25 Tilhørende DFD Fig 5-10 (jfr Tab 5-3) TDT4175 InfoSys

26 Beslutningstabeller og -trær
Viser beslutningslogikk og mulige utfall for en prosess: Tabell: Prosessregler, betingelser, aksjoner FORDEL: Kan være lettere å lese enn strukturert engelsk hvis flere ulike betingelser spiller inn ULEMPE: tabellen kan bli unødig stor og glissen (dvs. mange irrelevante ruter) hvis de ulike betingelsene ikke er helt uavhengige Tre: beslutningspunkter (noder), starter fra roten og utover (rekkefølge på beslutninger), ender i aksjoner (løvnoder) FORDEL vs glisne tabeller hvis beslutninger er innbyrdes avhengige TDT4175 InfoSys

27 Eksempel, strukturert engelsk
Tab 5-4 TDT4175 InfoSys

28 Samme m. tabell Tab 5-5 TDT4175 InfoSys

29 Samme m. tre: Fig 5-12 TDT4175 InfoSys

30 Tilstandsdiagrammer Lært tidligere i andre fag?
Diskret matematikk, MMI, Systemutvikling, ...? Går derfor ikke inn på dette Se evt boka for forklaring TDT4175 InfoSys

31 Kriterier for valg av representasjon
Tab 5-7 TDT4175 InfoSys

32 Være med på eksperiment?
Foreslått tidspunkt: Fredag 27.april etter forelesningen (dvs. ca. kl 15-16:30) Evt. andre tidspunkter som er bedre?? Betaling: 300 kr per pers Ingen direkte relevans for faget TDT4175 InfoSys