LØSNINGSFORSLAG TIL Eksamen i TDT4250 Modellering av IS

Transkript

1 NORGES TEKNISK-NATURVITENSKAPELIGE UNIVERSITET INSTITUTT FOR DATATEKNIKK OG INFORMASJONSVITENSKAP LØSNINGSFORSLAG TIL Eksamen i TDT4250 Modellering av IS Tirsdag 18. mai 2004 Det som står i kursiv er ikke en del av svaret men kommentarer til sensor. Oppgave 1 Denne teller 20% totalt, dvs. 4 poeng for perfekt svar på hver enkelt av de fem deloppgavene. a) Tre roller: fasilitator, skribent/referent, og deltager/interessent/kunderepresentant b) 7 perspektiver/orienteringer: i) Strukturelt (entiteter), ii) funksjonelt (aktiviteter/prosesser), iii) oppførsel (tilstander/transisjoner), iv) objekt, v) regel, vi) vi) kommunikasjon (talehandlinger), vii) aktør/rolle (aktører, roller, agenter, ) c) 3 dimensjoner: representasjon (representation: fra uformell til formell), spesifikasjon (specification, fra inkomplett til komplett), enighet (agreement: fra personlige oppfatninger til felles spesifikasjon) d) Konsistenssjekk: Virkemiddel for å oppnå semantisk kvalitet. Formell analyse av en spesifikasjon, resultatet blir enten konsistens (alt stemmer overens) eller inkonsistens (noe stemmer ikke, symptom på semantisk feil). e) Begrensninger ved konsistenssjekk: Krever at språket har formell semantikk. En modell kan være uavgjørbar. Inkonsistens forteller ikke hva som er feil, så dette må avgjøres manuelt. 1

2 Oppgave 2 Her blir det max 20 poeng på hver av de to deloppgavene a) Modellen har følgende feil / svakheter: Empirisk: Unødvendig mange kryssende linjer, kan for eksempel bedres ved å flytte KundeInfonoden Lønnsomme produkter har helt uten grunn en annen font enn resten Halvsirkel mellom Produkter og Markedsavd. er dumt plassert ved at den havner oppå to kryssende linjer Syntaktisk: Relasjon mlm Kunde og Produkt: gal notasjon Attributter på Produkt: ikke i språket i* Høy Prod.kval. Prod.avd: mangler relasjon Semantisk: Ugyldighet Høy Prod.kval modellert som ressursmål, er mykmål Produktspesifikasjon modellert som mykmål, er ressursmål Markedsavd LEDES_AV James: Intet om dette i beskrivelsen Inkompletthet Mangler mykmål Rask utvikling mellom Markedsavd og FoU Intet om ulike former for betaling, og at kun prioriterte kunder kan få kreditt Info om to typer kunder osv. ikke inkludert. (Noe av dette dekkes ikke av språket, men det er jo en semantisk feil også hvis det er valget av språk som gjør at man ikke klarer å modellere det) Andre påståtte svakheter enn de som er angitt her kan også gi uttelling dersom det er fornuftig argumentert for dem, f.eks er det fullt mulig å komme med ytterligere kritikk av layout. LEDES_AV relasjonen kan gjerne hevdes å være syntaktisk feil også (i tillegg til at det allerede er nevnt som en semantisk feil), for pensum har ikke vist noe eksempel som tilsier at den er lovlig. 2

3 b) For å få en topp karakter på denne oppgaven bør man både klare å oversette det som framgår direkte av teksten til et i*-diagram, samt legge til noe ekstra som man kan resonnere seg fram til (relasjoner som ikke er direkte nevnt i teksten). Løsningsdiagrammet her viser, i tillegg til det som sies direkte i teksten, følgende: - Når produktet hentes av kunden, vil servicekostnadene bli lavere (Helps), og tilsvarende dyrere (Hurts) hvis produktet leveres av forretningen. - Et flatpakket produkt vil være lettere for Kunden å hente (Helps) - Et flatpakket produkt vil gi lavere produksjonskostnad siden fabrikken ikke trenger sette sammen delene (Helps), et montert produkt vil tilsvarende øke produksjonskostnadene (Hurts) - Et montert produkt kan tilsi bedre kvalitet (iallfall forbindes flatpakkede produkter vanligvis med lavere kvalitet), men på den andre siden må flatpakkede produkter nødvendigvis ha enkle og robuste sammenføyninger, som på sin side kan øke kvaliteten. Lavere produksjonskostnad for flatpakkede produkter tilsier dessuten at man for disse for samme pris kan oppnå høyere kvalitet. Alt i alt settes derfor en Unknown på denne relasjonen. De nevnte eksemplene representerer ikke noen absolutt fasit for hva som bør være med. Studentene kan derfor godt ha kommet med til dels andre relasjoner i stedet. Det viktige for å få topp score er at man viser at man kan bruke språket aktivt og klare å finne på noe i tillegg til det som kan oversettes direkte fra teksten og at det som kommer i tillegg virker fornuftig. Det kan videre legges til at i* sin notasjon varierer litt mellom ulike artikler, så det bør ikke trekkes noe om pilbruken skulle være en litt annen enn det som er vist her. 3

4 Anskaff e Kunde tilfreds And And And Finne Velg produ Leveres av Or Produkt bli levert Or Hentes av Helps Hurts Produkt klart for bruk Helps Helps Lav kostnad And Lav prodkostnad Hurts And Lav service kostnad Rask tilgjengelighet Høy kvalitet Unknown Helps Kund Flatpakket produkt Montert produkt Hurts 4

5 Oppgave 3 Her blir det max 10 poeng på hvert av de fire delspørsmålene 3a-i, 3a-ii, 3b-i, 3b-ii. a-i) Det som oppgaven legger opp til er at man på generell basis skal sammenligne analytiske vurderinger av kravinnhentingsteknikker (dvs vurdering vha teoretiske rammeverk) med empiriske vurderinger (for eksempel ekspertintervjuer eller eksperimenter). Analytiske vurderinger: - fordeler: o forholdsvis enkelt og billig å gjennomføre (kan gjøres av en enkelt person med blyant og papir og tilgang til informasjon om teknikken som skal vurderes) o mulig å vurdere nylig foreslåtte eller endrede teknikker, som foreløpig ikke er særlig utprøvd i praksis o gir et bra grunnlag for å sammenligne ulike teknikker mhp potensielle styrker og svakheter o de teoretiske rammeverkene kan også være en kilde til råd mhp å lage nye teknikker - ulemper: o vurderingen er avhengig av rammeverkets kvalitet, hvis dette er mangelfullt blir vurderingen også det o selv om rammeverkene kan være teoretisk elegante, kan vurderingen hvorvidt en teknikk tilfredsstiller et kriterium eller ikke likevel bli subjektiv o rammeverkene er ofte generelle, tar ikke spesielle hensyn til kontekst og situasjonen i en konkret bedrift som vurderer å ta i bruk en teknikk o gir ikke noe bevis på at en teknikk vil fungere i praksis Empiriske vurderinger (som videre kan deles opp i erfaring med lang tids bruk av teknikker, for eksempel hentet inn ved ekspertintervjuer, og erfaring fra mer spesifikk bruk, for eksempel i eksperimenter) - fordeler: o gir erfaringer fra praktisk bruk av teknikkene o Spesifikke fordeler med ekspertintervjuer kan basere vurderingen på et stort erfaringsmateriale kan vurdere hvorfor ulike teknikker passer i ulike kontekster o Spesifikke fordeler med eksperimenter Kan gi mer bastante konklusjoner (statistisk hypotesetesting) Kan måle graden av eventuell forbedring Kan sammenligne to ulike teknikker utført på samme oppgave - Ulemper: o Mer tidkrevende og kostbart å gjennomføre empiriske vurderinger enn analytiske o Spesifikke ulemper med ekspertintervjuer: Vanskelig å vurdere helt nye teknikker (fordi det ikke fins noen som har lang tids erfaring med å bruke dem, dermed ingen passende intervjuobjekter) 5

6 Blir svæ rt avhengig av kvaliteten på ekspertene, og hvorvidt deres virksomhet er representativ for det som andre skal gjøre; må kanskje intervjue svæ rt mange eksperter for å få et bredt nok bilde o Spesifikke ulemper med eksperimenter: Kan trenge et stort antall forsøkspersoner for å få statistisk signifikante resultater Vanskelig å eliminere forstyrrende faktorer som ødelegger resultatenes pålitelighet (f.eks mhp motivasjon, ulik kunnskap, sammensetning av grupper av forsøkspersoner) Arbeidsoppgaver gitt i kontrollerte eksperimenter blir nødvendigvis små og enkle, og dermed ikke sæ rlig realistiske i forhold til hva man gjør i reelle prosjekter Også et spørsmål om forsøkspersonene er representative (f.eks hvis man bruker studenter som prøvekaniner, mens det man egentlig ønsker å finne ut er om metode A vil væ re bedre enn metode B i industrien, med profesjonelle utviklere på den ene siden og kunder som kanskje kan lite om IT på den andre siden. 6

7 3a-ii) Analytiske vurderinger: - mindre kostbare, forholdsvis raskt: realistisk å få til innen 3 mnd - kan gjøres av metodeansvarlig alene - forutsetter at man finner et passende rammeverk (en kandidat: lista over best practices av Sawyer/Sommerville, ref A11, se om man nå mangler noe som står her og om den nye teknikken TK har dette) - ulemper o tester ikke om teknikken virker i praksis o tar ikke hensyn til spesielle rammebetingelser i KF Ekspertintervjuer - vanskelig hvis TK er en helt ny teknikk (finner ikke eksperter som har brukt den, kanskje bortsett fra de som oppfant teknikken og disse er gjerne ikke objektive) - men ny kan bety ny for KF slik at TK har eksistert en stund, da kan det væ re verdt å finne fram til personer som har en del erfaring med TK - men kan bli kostbart og tidkrevende (og eksperter har lite tid, vanskelig å få dem til å stille opp med mindre man kjenner dem iallfall hvis de skal stille opp gratis) Eksperimenter - kostbart og tidkrevende hvis man skal få statistisk signifikans - vanskelig å få til et kontrollert eksperiment. TK er en kravinnhentingsteknikk og involverer sikkert interaksjon med kunder/brukere, disse kan ikke kontrolleres 100% - utprøving av nye teknikker på kunder kan gi badwill dersom prosjektet flopper på grunn av dette, også mulig økonomisk tap - intern utprøving i KF (liksom-prosjekt eller et internt prosjekt) gir større kontroll og mindre risiko, men reduserer også realismen. Utprøving ved parallelle løp (gjøre en kravspek vha TK, en annen med gamle teknikker) reduserer risiko men gir økte kostnader til dobbeltarbeid. De fleste konsulentfirmaer har ikke råd til å ta et betydelig antall ansatte ut av vanlig innbringende aktivitet for et slikt formål - trengs den rigiditeten som kreves av et kontrollert eksperiment? Metodeansvarlig skal ikke skrive en vitenskapelig artikkel men gi en anbefaling til ledelsen. Begrenset utprøving av TK, f.eks kun av metodeansvarlig selv mot et par kunde- / brukerrepresentanter i et passende prosjekt, er bedre enn ingenting og et viktig supplement til en rent analytisk vurdering Det som synes mest realistisk innenfor tidsrammen på 3 mnd er altså en analytisk vurdering (gitt at det fins et rammeverk som passer) pluss en begrenset utprøving av teknikken av metodeansvarlig selv pluss eventuelt noen få personer til. Dette kan suppleres med noen ekspertintervjuer hvis mulig. I tillegg kan man selvsagt søke etter artikler som evaluerer TK (for eksempel også med eksperimenter) for å kompensere for de evalueringene man ikke har mulighet til å gjøre selv. Plusspoeng skal også gis til studenter som tar et kritisk utgangspunkt til selve problemstillingen: Det sies at man er misnøyd med nåvæ rende teknikker, men ikke hvorfor. Det man bør starte med, heller enn bare å vurdere TK, er derfor å 7

8 - få klarhet i hva man er misnøyd med - sette seg inn i TK og se om den gjør noe med dette (Liten vits i å innføre TK hvis den kun er god på ting som KF gjør bra allerede) Et sentralt spørsmål er videre hva slags avgjørelse som egentlig skal tas etter 3 mnd: a) droppe gamle teknikker og gå 100% over til TK i stedet? b) begynne å bruke TK side om side med andre teknikker? Hvis ledelsen egentlig tenker på (a) bør man som metodeansvarlig si at dette er en urealistisk avgjørelse å ta etter kun 3 mnd, og dessuten sannsynligvis en dum avgjørelse. Mhp kravinnhenting viser flere artikler i pensumlitteraturen at man trenger mange ulike teknikker side om side (intervjuer, krav-verksted, skriftlige kilder, observasjon, prototyping, ), avhengig av kontekst og type krav man skal finne. Hvis det derimot er snakk om (b), blir det mindre dramatisk og mer realistisk å gi et svar innen 3 mnd. Da kan man gradvis fase inn TK i reelle prosjekter, og kan lett ombestemme seg senere. (Forutsetter dog at TK ikke er en veldig fundamentalistisk teknikk hvor det er alt eller ingenting ) 8

9 3b-i) Likheter: - begge er analytiske vurderinger, dvs. vurderer UML ut fra teoretiske rammeverk. - vurderingene kan således gjøres på papiret av enkeltpersoner, uten å prøve ut UML i praksis, ved å se på UMLs språkdefinisjon og sammenligne denne med det aktuelle rammeverket - begge ender opp med lister av forhold ved UML som er i samsvar med de respektive rammeverkenes anbefalinger, og andre forhold ved UML som ikke er i samsvar med rammeverket. Forskjeller: - Krogsties vurdering basert på det semiotiske rammeverket er bredere enn det som gjøres av Opdahl og Henderson-Sellers. Krogstie ser både på språkets evne til å uttrykke fakta om problemdomenet, hvorvidt språket er forståelig for menneskelige interessenter, og hvorvidt det er forståelig for verktøy. Han ser både på konseptuell basis og diagramnotasjon, og dessuten på metode- og verktøystøtte (dvs. hvilke virkemidler man har for å oppnå kvalitet på ulike semiotiske nivåer). - Opdahl/Henderson-Sellers ser til gjengjeld kun på språkets konseptuelle basis og sammenligner denne med BWW-ontologien. Denne vurderingen er således smalere (sier lite om diagramnotasjon, hvorvidt språket er forståelig, hvilke virkemidler man har for ulike typer kvalitet, osv.), men til gjengjeld grundigere på det den vurderer, idet hvert eneste konsept i UML blir vurdert opp mot BWW og vice versa. - Krogsties vurdering blir noe mer subjektiv enn Opdahls (spørsmål som Har UML et konsept som tilsvarer konsept X i BWW? kan ofte besvares nokså bastant JA/NEI, mens spørsmål om UML vil væ re forståelig for ulike deltakere i utviklingsprosjekter blir mer preget av synsing). Begge vurderingene har altså fordeler og ulemper og de kan sies å komplettere hverandre (oppdager til dels ulike svakheter ved UML). 9

10 3b-ii) Standardeksempler kan væ re bra å bruke for å finne ut hva språket er i stand til å uttrykke og ikke, og hvor elegant dette eventuelt uttrykkes. En fordel med standardeksempler kan væ re at de ikke er laget spesifikt for å vurdere NewML, mens eksempler laget av de som har funnet opp NewML typisk vil vise fram sterke sider ved dette språket og skjule de svake. Eksperimenter vil væ re lettere å bruke for å vurdere et modelleringsspråk enn en kravinnhentingsteknikk, da man i noen grad kan eksperimentere med utviklere alene og ikke trenger interaksjon med kunder. Slike eksperimenter kan si noe om hvorvidt utviklerne er i stand til å lage gode modeller i det aktuelle språket. Hvis modellene i stor grad skal brukes til kommunikasjon med brukerrepresentanter, vil imidlertid eksperimenter som går på brukernes forståelse av modellene også væ re viktig. I avveininger mellom de to har en enkel utprøving på standardeksempler den fordelen at det er billig og kan gjøres relativt raskt av få personer. På den annen side vil eksperimenter kunne gi mer bastante konklusjoner mhp sammenligning av UML og NewML. Det er ikke nødvendigvis noe motsetningsforhold mellom standard-eksempler og eksperimenter (de modelleringsoppgavene som gis i eksperimenter kan jo nettopp væ re basert på standardeksempler), spørsmålet er snarere hvilken grad av vitenskapelig rigiditet man legger opp til: en enkel, uformell utprøving av et modelleringsspråk eller et kontrollert eksperiment hvor man ønsker å se målbare forskjeller. Ting man må huske på for at resultater skal væ re pålitelige: - modelleringsoppgavene må væ re mest mulig representative for problemstillinger som firmaet støter på i praksis - modelleringsoppgavene bør ikke væ re slik at de urettmessig favoriserer ett av språkene - man bør ikke bare se på ren oversetting av (f.eks) en tekstlig case-beskrivelse til modell, men ha mer dynamiske oppgaver hvor det gradvis blir behov for å endre modellen eller ta beslutninger på grunnlag av den - sæ rlig for eksperimenter må man eliminere andre faktorer som kan ødelegge for pålitelige resultater, f.eks at forsøkspersonene har ulik forkunnskap eller motivasjon i forhold til UML og NewML, at rekkefølgen oppgavene gjøres i favoriserer det ene språket, at ulike gruppesammensetninger favoriserer det ene språket, osv. I likhet med 3a-ii gis det igjen plusspoeng for å væ re kritisk til selve spørsmålet: - man sier at man ikke er 100% fornøyd med UML, men ikke hva man er misnøyd med. Hvis man får klarlagt dette, kan det bli lettere å vurdere om NewML inneholder nye ting som forbedrer akkurat dette. - Hvorvidt det er smart å bytte avhenger ikke bare av modelleringsspråket isolert sett, men også for eksempel at hva slags verktøystøtte som er tilgjengelig, hva slags opplæ ringstilbud som fins, osv. Hvis NewML nettopp er funnet opp, er kanskje ikke verktøystøtten robust nok for industriell bruk, slik at det ikke lønner seg å bytte språk selv om det skulle ha noen positive egenskaper i forhold til UML. Et annet forhold er at nyansatte sannsynligvis vil ha læ rt UML der de har studert, ikke NewML. - Et bytte vil også i seg selv innebæ re betydelige kostnader (opplæ ring, nytt verktøy, vanskeligere kommunikasjon med evt subkontraktører som bruker UML, ), så det vil ikke væ re nok at en evaluering viser at NewML er marginalt bedre enn UML det må væ re vesentlig bedre, og det må gjøres en avveining mellom kostnader og mulig inntjening 10