Oversikt over forelesningen. Kvalitetssikring i IS-utv. (1) Motivasjon for kvalitetssikring

Like dokumenter
Oversikt over forelesningen. DFD sentrale konsepter. Intro til Dataflytdiagrammer (DFD) Marakas, kap. 5

LØSNINGSFORSLAG TDT 4175 INFORMASJONSSYSTEMER Lørdag 24. mai 2008 Tid: kl

Tom Røise 2/28/2007. IMT2243 : Systemutvikling 1. Forelesning IMT mars Tema : Litteratur : Strukturert analyse. Strukturert analyse

Oppgave 1. Modelleringsperspektiver og modelleringsspråk (40%) Alle underoppgavene teller likt

Kravspesifikasjon med UML use case modellering. Erik Arisholm

UKE 13 Mer UML modellering. Gruppetime INF1055 Julie Hagen Nilsen & Maria Stolinski

Lykke til! Eksamen i fag TDT4140 Systemutvikling NTNU Norges teknisk-naturvitenskapelige universitet

Kirsten Ribu - Høgskolen i Oslo

Oppgave 1 Referent Modell (20%)

Python: Valg og betingelser. TDT4110 IT Grunnkurs Professor Guttorm Sindre

Plenumsregning 1. MAT1030 Diskret Matematikk. Repetisjon: Algoritmer og pseudokode. Velkommen til plenumsregning for MAT1030

MAT1030 Diskret Matematikk

Forelesning 25. MAT1030 Diskret Matematikk. Litt repetisjon. Litt repetisjon. Forelesning 25: Trær. Dag Normann

KONTINUASJONSEKSAMEN I FAG SYSTEMERING 2 Torsdag 24. august 2000 Tid: kl

MAT1030 Diskret Matematikk

SIF 8035 Informasjonssystemer Våren Øving 2 DFD-modellering. Innlevering: Mandag 12. februar

MAT1030 Diskret matematikk

Innledning. MAT1030 Diskret matematikk. Kapittel 11. Kapittel 11. Forelesning 33: Repetisjon

Presentasjon 1, Requirement engineering process

EKSAMEN I FAG SYSTEMERING 2 LØSNINGSFORSLAG Mandag 18. mai 1998 Tid: kl

Kap. 12 Analysemodellering (Analysis Modeling)

Statisk semantisk analyse - Kap. 6

UKE 11 UML modellering og use case. Gruppetime INF1055

Statisk semantisk analyse - Kap. 6

Velkommen til plenumsregning for MAT1030. MAT1030 Diskret matematikk. Repetisjon: Algoritmer og pseudokode. Eksempel fra boka. Eksempel

MAT1030 Diskret matematikk

Syntax/semantics - I INF 3110/ /29/2005 1

MAT1030 Diskret matematikk

KONTINUASJONSEKSAMEN I FAG 78052/45161 SYSTEMERING 2 Onsdag 18. august 1999 Tid: kl

Eksamensoppgave i TDT4120 Algoritmer og datastrukturer

Forelesning 27. MAT1030 Diskret Matematikk. Bevistrær. Bevistrær. Forelesning 27: Trær. Roger Antonsen. 6. mai 2009 (Sist oppdatert: :28)

INF2820 Datalingvistikk V gang, Jan Tore Lønning

MAT1030 Diskret Matematikk

Prosessmodellering. Strukturert design med dataflytdiagrammer (DFD) Gurholt & Hasle Kapittel 10. Kirsten Ribu Høgskolen i Oslo

MAT1030 Diskret Matematikk

MAT1030 Forelesning 25

Prosjektrettet systemarbeid

MAT1030 Diskret matematikk

MAT1030 Plenumsregning 1

Eksamen i fag SIF8018 Systemutvikling. Fredag 25. mai 2001 kl

Forelesning 33. Repetisjon. Dag Normann mai Innledning. Kapittel 11

MAT1030 Diskret matematikk

Tom Røise IMT2243 : Systemutvikling 1. IMT2243 Systemutvikling 26. februar Klassediagrammet. Klasse

Kravhåndtering. INF1050: Gjennomgang, uke 03

Semantisk Analyse del I

Nasjonale retningslinjer for karaktersetting i matematikk i GLUutdanningene. Andreas Christiansen Ole Enge Beate Lode

Læringsmål og pensum. Utvikling av informasjonssystemer. Oversikt. Systemutvikling Systemutvikling i seks faser Femstegs prosedyre for programmering

Eksamen i fag TDT4140 Systemutvikling. 6. juni, 2006 kl

Test of English as a Foreign Language (TOEFL)

Objektorientering og UML. INF1050: Gjennomgang, uke 06

TDT4110 Informasjonsteknologi, grunnkurs Uke 35 Introduksjon til programmering i Python

FIAS Fjernundervisning

Fakultet for informasjonsteknologi, Løsning på kontinuasjonseksamen i TDT4190 Distribuerte systemer 19. august 2006,

Eksamensoppgave i TDT4120 Algoritmer og datastrukturer

System integration testing. Forelesning Systems Testing UiB Høst 2011, Ina M. Espås,

Repetisjon og mer motivasjon. MAT1030 Diskret matematikk. Repetisjon og mer motivasjon

Kapittel 3: Litt om representasjon av tall

Vektede grafer. MAT1030 Diskret matematikk. En kommunegraf. En kommunegraf. Oppgave

Kort om evaluering og testing av It-systemer. Hvordan vurdere, verdsette, velge og teste?

Hvordan komme i gang med ArchiMate? Det første modelleringsspråket som gjør TOGAF Praktisk

SIE 4005, 9/10 (4. Forelesn.)

Eksamensdato: 31. mai 2017 Eksamenstid 14:30-18:30 Hjelpemidler: Ingen. Les denne forsiden nøye. Oppgaven består av fire deler.

UNIVERSITETET I OSLO

Forbrytelse og straff

Oppgaver til kodegenerering etc. INF-5110, 12. mai, 2015

INF2810: Funksjonell Programmering. Dataabstraksjon og Trerekursjon

Kravspesifisering (2): Validering av kravspek er

Læringsmål og pensum. if (be): else (not_to_be):

TDT4110 IT Grunnkurs Høst 2012

Eksamen I En Digital Verden Hva slags funksjon bør eksamen ha i en helhetlig sluttvurdering i fremtidens skole?

Kravspesifiseringsprosessen

INF3430/4431. VHDL byggeblokker og testbenker

Eksamensoppgave i TDT4120 Algoritmer og datastrukturer

INF2820 Datalingvistikk V gang, Jan Tore Lønning

GJENNOMGANG UKESOPPGAVER 2 PROSESSMODELLER OG SMIDIG PROGRAMVAREUTVIKLIG

Kvalitet av konseptuelle modeller

LØSNINGSORSLAG TDT 4175 INFORMASJONSSYSTEMER Lørdag 9. juni 2007 Tid: kl

KONTINUASJONSEKSAMEN I EMNE TDT4195 BILDETEKNIKK ONSDAG 13. AUGUST 2008 KL

GJENNOMGANG UKESOPPGAVER 7 REPETISJON

Python: Løkker. TDT4110 IT Grunnkurs Professor Guttorm Sindre

Kirsten Ribu - Høgskolen i Oslo

1. Hvilke type krav angår sikkerhet og pålitelighet?

Forelesning 30: Kompleksitetsteori

Modellering av brukstilfeller og forretningsprosesser. Kurs i standarder, Oslo, 12. juni 2018

Modellering av krav. INF1050: Systemutvikling 11. februar Universitetslektor Yngve Lindsjørn

Oppsummering : IMT2243 Systemutvikling. Hensikt med kurset. Innfallsvinkel : Tom Røise IMT2243 : Systemutvikling 1

MAT1030 Diskret matematikk

ALGORITMER OG DATASTRUKTURER

Systemutviklingen er ferdig når et system er operativt. Med operativt menes når systemet blir brukt av brukerne på et faktisk arbeidssted.

1. Hvilke type krav angår sikkerhet og pålitelighet?

EKSAMEN. Evaluering av IT-systemer. Eksamenstid: kl 0900 til kl 1300

Kombinatorikk. MAT1030 Diskret Matematikk. Oppsummering av regneprinsipper

MAT1030 Diskret Matematikk

Livsløpstesting av IT-systemer

TDT4110 Informasjonsteknologi grunnkurs: Tema: Betingelser og logiske uttrykk. - 3rd edition: Kapittel 3. Professor Alf Inge Wang

INF Repetisjon: Hvordan bygge treet og analysere? 8. september Typisk situasjon. De problematiske syntaks-diagrammene

Planleggingsfasen.. Estimering av kostnader i IT-prosjekter. Gjennomføringen. Hvor gode er vi til å planlegge (estimere kostnader) ihht Standish Group

MAT1030 Diskret matematikk

INF2820 Datalingvistikk V2017 Forelesning 1.2 Jan Tore Lønning

Forelesning 25. MAT1030 Diskret Matematikk. Litt repetisjon. Litt repetisjon. Forelesning 25: Trær. Roger Antonsen

Transkript:

1 2 Oversikt over forelesningen Institutt for datateknikk og informasjonsvitenskap Guttorm Sindre Kvalitet av modeller (ikke i bok) + Mer om Dataflytdiagrammer (DFD) Marakas, kap. 5 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 Informadsjonssystemer 3 4 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 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

5 6 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 Velkjente review-teknikker Formalitetsspektret (Wiegers, 2002) Most formal Inspection Team Review Walkthrough Pair Progr. (Pair Modelling?) Peer Deskcheck, Passaround Ad hoc review Least formal 7 Forskjeller (Wiegers 2002) 8 Mer forskjeller (Wiegers 2002) Review Type Planning Correction Preparation Meeting Verification Characteristic Leader Inspection Moderator Team Review Mod / Author Walkthrough Author Inspection Team Review Presenter Granularity Recorder? Reader Small chunks Moderator Pages/sections Author Author s pref. Continuous Walkthrough Pair Prog/ Modeling Passaround Documented Procedure? Spec. Roles for Participants? Checklists? Data analyzed Ad hoc review Product appraisal determined?

9 10 Semiotisk kvalitetsrammeverk Syntactisk kvalitet Interpretation (I) Pragmatic quality Q: Følger modellen språkets grammatikk? Mål: syntaktisk korrekthet, M \ L = Ø To typer feil: Syntaktisk ugyldighet (a) Syntaktisk inkompletthet (b) Domain (D) Semantic quality Model (M) Syntactic quality Language (L) (a) 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 (b) 11 12 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 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

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 14 Student karakterer FAGDATA studentlister oppg studnr 5. Finn karakter besv Datoer, Målformer Ant. oppmeldte karakterer STUDENTDATA 1. Forbered eksamen oppg oppg 3. Gjennomfør eksamen fremmøteinfo oppg.frist, målformer oppgaver Ø-poeng besv Faglærer karakterer 2. Forbered sensur sensurlister mulige sensorer sensurliste oppg, LF 4. Gjør arbeid Tilbud om sensuroppdrag, respons besv besv poeng poeng Sensor Vitass Faglærer 15 16 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 Hvordan lage gode DFD? (1) Følg syntaksretningslinjer Tab 5-1 rmal 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?

17 18 Hvordan lage gode DFD? (2) Flytkart, notasjon (ANSI-standard) 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 Fig 5-8 19 20 Flytkart, eksempel (Fig 5-9) Steg for utvikling av DFD Fig 5-9 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)

21 22 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å 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... 23 24 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 Structured English, eksempel Process ID Table 5-3 Structured English 4.1.1 Multiply GROSS_PAY by FED_TAX_RATE and store in EMP_TAX_DEDUCT. 4.1.2 IF EMP_NONTAX_DEDUCT > 0 THEN append EMP_NONTAX_DEDUCT to employee data. 4.1.3 Multiply GROSS_PAY by.01 and store in EMP_RETIRE. 4.1.4 Multiply CURR_EMP_VACATION by EMP_DAY_RATE and store in EMP_VACATION_PAY.

25 26 Tilhørende DFD 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 Fig 5-10 (jfr Tab 5-3) 27 Eksempel, strukturert engelsk Tab 5-4 Structured English Process Description IF Driver_Age < 25 THEN IF Accident_Free = N THEN Surcharge = 0.20 IF Driver_Gender = F THEN Surcharge = 0.10 IF Driver_Educ = N THEN Surcharge = 0.15 IF College = N THEN Surcharge = 0.12 IF HS_GPA < 3.25 THEN Surcharge = 0.10 IF HS_GPA >= 3.25 THEN Surcharge = 0.07 IF Accident_Free = Y THEN Surcharge = 0.00 IF Accident_Free = N THEN Surcharge = 0.07 28 Samme m. tabell Tab 5-5 Driver Age 25 yrs 25 < 25 < 25 < 25 < 25 < 25 < 25 + yrs + yrs yrs yrs yrs yrs yrs Accident Free Y N N Y Y Y Y Y Driver Gender - - - Female Male Male Male Male Driver s Education College (attending /completed) High School GPA 20% 15% 12% 10% 7% - - - - N Y Y Y - - - - - N Y Y - - - - - - < 3.25 3.25+ X X X X X X X X

29 30 Samme m. tre: Tilstandsdiagrammer Lært tidligere i andre fag? Diskret matematikk, MMI, Systemutvikling,...? Går derfor ikke inn på dette Se evt boka for forklaring Fig 5-12 31 Kriterier for valg av representasjon Tab 5-7 Primary Criteria 1=Best 2=Better 3= Good Transformation of conditions or actions into specific sequence. Structured English Decision Table Decision Tree State- Transition 1 3 1 - Portraying complex logic 3 1 2 - sequences. Portraying simple logic 2 2 1 - sequences. Making basic decisions. 3 2 1 - Determining conditions or 2 3 1 - actions. Checking logic consistency and 3 1 1 - completeness. Ease of Manipulation. 3 1 2 - Compactness 3 1 2 - Portraying temporal logic sequences - - - 1