TDT4175 InfoSys

1

Trondheim, Norway

Guttorm Sindre

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

TDT4175 Informadsjonssystemer

Institutt for datateknikk oginformasjonsvitenskap

TDT4175 InfoSys

2

Trondheim, Norway

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

Trondheim, Norway

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

Trondheim, Norway

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

Trondheim, Norway

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

Trondheim, Norway

Velkjente review-teknikker

• Formalitetsspektret (Wiegers, 2002)

Mostformal

Leastformal

Inspection TeamReview

Walkthrough PairProgr.

(PairModelling?)

PeerDeskcheck,

Passaround

Ad hocreview

TDT4175 InfoSys

7

Trondheim, Norway

Forskjeller (Wiegers 2002)Review

Type

Planning Prepa-ration

Meeting Correc-tion

Verifi-cation

Inspec-tion

Yes Yes Yes Yes Yes

Team Review

Yes Yes Yes Yes No

Walk-through

Yes No Yes Yes No

Pair Prog/ Modeling

Yes No Con-tinuous

Yes Yes

Pass-around

No Yes Maybe Yes No

Ad hoc review

No No Yes Yes No

TDT4175 InfoSys

8

Trondheim, Norway

Mer forskjeller (Wiegers 2002)Characteristic Inspection Team Review Walkthrough

Leader Moderator Mod / Author Author

Presenter Reader Moderator Author

Granularity Small chunks Pages/sections Author’s pref.

Recorder? Yes Yes Maybe

Documented Procedure?

Yes Maybe Maybe

Spec. Roles for Participants?

Yes Yes No

Checklists? Yes Yes No

Data analyzed Yes Maybe No

Product appraisal determined?

Yes Yes No

TDT4175 InfoSys

9

Trondheim, Norway

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

Domain (D)

Interpre-tation (I)

Language (L)Model (M)

Syntacticquality

Semanticquality

Pragmatic quality

TDT4175 InfoSys

10

Trondheim, Norway

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

Trondheim, Norway

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

Trondheim, Norway

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

Trondheim, Norway

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

Trondheim, Norway

4. Gjør arbeid

1. Forberedeksamen

3. Gjennomfør

eksamen

FAGDATA

Datoer,MålformerAnt. oppmeldte

2. Forberedsensur

Sensoroppgaver

Faglærer

oppg

oppg

poeng

poeng

Vitass

Ø-poengsensurliste

karakterer

Student

5. Finn

karakter

karakterer

karakterer

oppg, LF

oppg

besv

besv

besv

Tilbud om sensuroppdrag, respons

oppg.frist,målformer

sensurlister

muligesensorer

STUDENTDATA

fremmøteinfo

studentlister

studnr

Faglærer

besv

TDT4175 InfoSys

15

Trondheim, Norway

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

Trondheim, Norway

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

Trondheim, Norway

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

Trondheim, Norway

Flytkart, notasjon (ANSI-standard)

• Fig 5-8

TDT4175 InfoSys

19

Trondheim, Norway

Flytkart, eksempel (Fig 5-9)

• Fig 5-9

TDT4175 InfoSys

20

Trondheim, Norway

Steg for utvikling av DFD

1 Informasjonsinnhenting (f.eks intervju, ...)

2 Del inn aktiviteter

3 Modeller separate aktiviteter

4 Lag preliminært kontekstdiagram

5 Lag preliminært toppnivå (nivå-0) diagram

6 Dekomponer til nivå 1, 2 osv.

7 Kombiner og juster nivå 0-n diagrammene

8 Lag endelig diagram (sjekk konsistens)

TDT4175 InfoSys

21

Trondheim, Norway

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

Trondheim, Norway

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

Trondheim, Norway

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

Trondheim, Norway

Structured English, eksempel

• Table 5-3

Process ID

S tructured English

4 .1.1

M ultip ly G R O SS_P A Y b y FED _T A X_R A TE and store in EM P_T A X_D ED U C T .

4 .1.2

IF EM P_N O N T A X_ D ED U C T > 0 T H EN append EM P_N O N T A X_ D ED U C T to em ployee data.

4 .1.3

M ultip ly G R O SS_PA Y b y .01 and store in EM P_R ETIR E .

4 .1.4

M ultip ly C U R R _EM P_V A C A TIO N b y EM P_D A Y_R A T E and store in EM P_V A C A TIO N _P A Y .

TDT4175 InfoSys

25

Trondheim, Norway

Tilhørende DFD

• Fig 5-10 (jfr Tab 5-3)

TDT4175 InfoSys

26

Trondheim, Norway

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

Trondheim, Norway

Eksempel, strukturert engelsk

• Tab 5-4

Structured English Process Description IF Driver_Age < 25 THEN IF Accident_Free = “N” THEN Surcharge = 0.20 ENDIF ELSE IF Driver_Gender = “F” THEN Surcharge = 0.10 ENDIF ELSE IF Driver_Educ = “N” THEN Surcharge = 0.15 ENDIF ELSE IF College = “N” THEN Surcharge = 0.12 ENDIF ELSE IF HS_GPA < 3.25 THEN Surcharge = 0.10 ENDIF ELSE IF HS_GPA >= 3.25 THEN Surcharge = 0.07 ENDIF ELSE IF Accident_Free = “Y” THEN Surcharge = 0.00 ENDIF ELSE IF Accident_Free = “N” THEN Surcharge = 0.07 ENDIF ENDIF

TDT4175 InfoSys

28

Trondheim, Norway

Samme m. tabell

• Tab 5-5

Driver Age 25 yrs +

25 yrs +

< 25 yrs

< 25 yrs

< 25 yrs

< 25 yrs

< 25 yrs

< 25 yrs

Accident Free Y N N Y Y Y Y Y

Driver Gender - - - Female Male Male Male Male

Driver’s Education

- - - - N Y Y Y

College (attending /completed)

- - - - - N Y Y

High School GPA

- - - - - - < 3.25 3.25+

20% surcharge

X

15% surcharge

X

12% surcharge

X

10% surcharge

X X

7% surcharge

X X

No surcharge

X

TDT4175 InfoSys

29

Trondheim, Norway

Samme m. tre:

• Fig 5-12

TDT4175 InfoSys

30

Trondheim, Norway

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

Trondheim, Norway

Kriterier for valg av representasjon

• Tab 5-7

Primary Criteria 1=Best 2=Better 3= Good

Structured English

Decision Table

Decision Tree

State-Transition

Transformation of conditions or actions into specific sequence.

1 3 1 -

Portraying complex logic sequences.

3 1 2 -

Portraying simple logic sequences.

2 2 1 -

Making basic decisions. 3 2 1 -

Determining conditions or actions.

2 3 1 -

Checking logic consistency and completeness.

3 1 1 -

Ease of Manipulation. 3 1 2 -

Compactness 3 1 2 -

Portraying temporal logic sequences

- - - 1

TDT4175 InfoSys

32

Trondheim, Norway

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