1 / 32

Guttorm Sindre Kvalitet av modeller (ikke i bok) + Mer om Dataflytdiagrammer (DFD) Marakas, kap. 5

Institutt for datateknikk og informasjonsvitenskap. Guttorm Sindre Kvalitet av modeller (ikke i bok) + Mer om Dataflytdiagrammer (DFD) Marakas, kap. 5. TDT4175 Informadsjonssystemer. Oversikt over forelesningen. Kvalitetssikring av modeller Motivasjon for kvalitetssikring

limei
Télécharger la présentation

Guttorm Sindre Kvalitet av modeller (ikke i bok) + Mer om Dataflytdiagrammer (DFD) Marakas, kap. 5

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. 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) TDT4175 InfoSys

  8. Mer forskjeller (Wiegers 2002) TDT4175 InfoSys

  9. Interpre- tation (I) Pragmatic quality Domain (D) Model (M) Language (L) Semantic quality Syntactic quality Semiotisk kvalitetsrammeverk • 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 mulige sensorer FAGDATA oppg Datoer, Målformer Ant. oppmeldte oppg.frist, målformer Tilbud om sensuroppdrag, respons 1. Forbered eksamen 2. Forbered sensur Sensor studentlister oppgaver oppg, LF Ø-poeng besv sensurliste poeng Vitass Student oppg besv 4. Gjør arbeid 3. Gjennomfør eksamen oppg besv studnr karakterer 5. Finn karakter karakterer poeng fremmøteinfo besv sensurlister Faglærer karakterer 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) • 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 • 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

More Related