LØSNINGSMOMENTER TIL EKSAMEN FAGNAVN: FAGNUMMER: SYSTEMUTVIKLING IMT2243 EKSAMENSDATO: 27. mai 2008 KLASSE: TID: 0900-200 06HBINDA, 06HBISA, 06HBMETEA, 07HBPUA FAGLÆRER: Tom Røise ANTALL SIDER UTLEVERT: TILLATTE HJELPEMIDLER: 4 inkl. denne forsiden Alle trykte og skrevne INNFØRING MED PENN, evt. trykkblyant som gir gjennomslag Ved innlevering skilles hvit og gul besvarelse og legges i hvert sitt omslag. Oppgavetekst, kladd og blå kopi beholder kandidaten. Husk kandidatnummer på alle ark. Denne skriftlige eksamen teller 40 % av samlet karakter i emnet og må bestås separat for å oppnå tellende karakter i emnet. På hver oppgave er det angitt en prosentsats som viser oppgavens vekt ved sensur. Ta hensyn til dette når du disponerer tiden for å løse oppgaven.
Oppgave Ivaretagelse av ulike perspektiver i systemutviklingsprosjekter (45 %) : a) Innen kravspesifisering : I sin artikkel 0 Small Steps to Better Requirements påpeker Ian Alexander viktigheten av å ivareta ulike Stakeholders (det norske begrepet vi har brukt er Interessenter ) i systemutviklingsprosjekter. Trekk frem og kommenter de metoder og teknikker fra emnets pensum innen kravspesifisering som du mener er best på å ivareta dette aspektet. Her er det i først rekke lagt vekt på Viewpoint som en metode med en myk tilnærming der det legges helt spesiell fokus på dette med å ivareta ulike Stakeholders sine interesser. Forventer at kandidatene forklarer noe om hvordan metoden ivaretar dette. Videre bør kandidatene trekke frem Use Case som en teknikk innen OOA-metoden som legger stor vekt på å ivareta dette. b) Innen arkitektur : I Rational Unified Process har man en tilnærming til programvarearkitektur der det legges spesielt vekt på å belyse løsningen fra ulike perspektiv. Beskriv mekanismen/ tilnærmingsmåten i RUP som ivaretar dette. I denne beskrivelsen skal du også oppgi hvilken fase og disiplin dette tilhører og hvilken RUP-rolle, hvilket RUP-artefakt og hvilke UML-diagrammer som er mest sentrale her. Her er RUP sin 4+ (+n) view som er riktig svar. Spørsmålet dreier seg om perspektiver relatert til arkitektur, og generell omtale av RUP gir ingen belønning. Kandidatene bør navngi viewene og trekke frem hva som settes i fokus i de ulike perspektivene. Aktuelt innhold her vil være : Use Case View viser arkitekturdrivende funksjonelle krav, Logical View viser systemets logiske struktur for hele løsningen med lagdeling og modularisering Process View viser et runtime bilde av systemet med fokus på kontroll Deployment View viser fysisk inndeling med noder og bl.a. hva som legges på klienter og på ulike servere Implementation View viser de enkelte programmene som skal implementeres og deres plassering Den sentrale Rup rollen Software Architect, fasen er Elaboration, disiplinen er Analysis& Design og RUP-artefaktet som er mest sentralt er Software Architecture Document. Eksempler på sentrale UML-diagrammer er Design Klassediagram og Deployment Diagram c) Innen estimering : Ekspertestimering er en utbredt arbeidsform når man gir prediksjoner på innsatsbehovet i systemutviklingsprosjekter. Forklar hvordan man kan legge opp ekspertestimering på måter som legger til rette for at ulike perspektiver og aspekter blir ivaretatt ved innsatsestimeringen. Vi har gått gjennom ekspertestimering og belyst problematikken rundt skjevhetstendenser når man lar en ekspert sette opp et innsatsestimat. En enkelt ekspert ikke ha full innsikt i alle forhold og slik sett få man et snevert perspektiv.
Derfor bør kandidatene forklare viktigheten av at man for å ivareta ulike perspektiver må involvere flere eksperter som dels kan estimere ulike deler, og dels kan komme med alternative estimater på samme oppgave. Dermed minskes tendensen til skjeve estimater. Flere eksperter gjerne med matematisk aggregering eller jobbing gjennom en såkalt ustrukturert gruppe vil ivareta dette. Kandidater som i tillegg kommenterer at man har ulike former for ekspertise som for eksempel forretningsekspertise, estimeringsekspertise og teknologiekspertise og at slike forhold bør legges til grunn ved valg av eksperter gis full score. Oppgave 2 Modellering av funksjonelle krav (0 %) I analysemetoden Strukturert Analyse inngår Kontekstdiagram som høyeste nivå av dataflytdiagrammer. I Objektorientert Analyse benyttes Use-Case diagram i modelleringen av funksjonelle krav. Det finnes likhetstrekk mellom diagramtypene, men også klare forskjeller. Modellen under er hentet fra pensum og viser et Kontekstdiagram for studentopptakssystem. Lag et Use Case diagram som dekker alle forhold du kan lese ut av dette Kontekstdiagrammet og bruk modellene til å forklare likheter og forskjeller mellom de to diagramtypene. Kontekstdiagram hentet fra pensumlitteraturen innen strukturert analyse. Studentopptakssystem Søke studieplass Registrere opptakskriterier Søker Svare på studietilbud Ajourføre salgsbudsjett Skoleleder sende forespørsel Generere rapporter Sende ut studieinformasjon Administrere kontrakter Studentadministrasjon
Use Case diagram for tilsvarende system har likheten i at de er de samme eksterne aktører/terminatorer. Forskjeller som bør kommenteres er at UC-diagrammet viser alle enkelt tjenestene brukerne ønsker, mens DFD kun er en boble. Kontekstdiagrammet spesifiserer til gjengjeld i større grad informasjonsflyten (hvilke info og retningen på den). Oppgave 3. Oppgaver i tilknytning til casebeskrivelsen (45 %) Det er en relativt kompleks situasjon som beskrives under. Det er ikke en komplett beskrivelse, men din oppgave er å forholde deg kun til den foreliggende informasjonen og systematisere og gi forslag på grunnlag av denne. LEteaksjonsStøtteSystem (LESS) : Når liv og helse står på spill er det alltid kritisk å ha best mulige støttesystemer. I Norge har vi stadig små og store leteaksjoner etter savnede enkeltindivider og grupper. Som regel ledes og koordineres letingen av politiet. Ofte deltar mannskaper fra mange ulike organisasjoner i samme leteaksjon. Dette kan være spesialutstyrte enheter som hundepatruljer og dykkere, Røde Kors og andre frivillige organisasjoner og enkeltpersoner. Tid er alltid viktig i slike saker og det er avgjørende at man får utnyttet alt tilgjengelige personell og utstyr mest mulig systematisk og effektivt fra første stund. Det er her informasjonsteknologien kommer inn i bildet. Du skal i denne oppgaven se nærmere på noen av utfordringene som ligger i å utvikle et datasystem (LESS) som støtter letearbeidet. Det understrekes at dette systemet skal støtte både de som leder leteaksjonen og mannskapet som deltar i selve letingen. Det skal benyttes til å se hvor og hvordan man hittil har lett og til å planlegge og disponere mannskapet i de kommende leteøktene. Systemet skal også hjelpe den enkelte som er ute og leter. Det skal bidra til at ikke flere leter på samme sted, samtidig som hele det aktuelle området blir godt gjennomsøkt. Alle som er ute og leter utstyres derfor med en bærbar GPS-basert enhet som etter endt søkeøkt overfører informasjon om gjennomført søk. Deretter lastes enhetene med informasjon om neste søkeøkt. Utover dette skal systemet også dekke behovene til de som evaluerer leteaksjonen i ettertid. Politiskolen skal bruke systemet i opplæring av leteaksjonsjonsledere og trenger derfor funksjonalitet for å sette opp ulike lete-scenarier. Det er allerede inngått en avtale mellom partene som skal involveres i utviklingen. Et eksternt datakonsulentfirma skal stå for systemutviklingen. Politidirektoratet vil stå som kunde og vil handle i henhold til retningslinjer gitt av Justisdepartementet. Enkelte politidistrikt vil bistå i prosjektet med folk med erfaring i leteaksjonsledelse. Politihøgskolen skal ivareta krav rundt opplæringsmodulen. Videre ser man det som helt avgjørende for prosjektets suksess at parter som Hovedredningssentralen, spesialenhetene og de frivillige organisasjonene involveres i deler av utviklingsprosjektet. Når det gjelder kart så er det inngått avtale med Statens Kartverk angående nedhenting av deres kart og annen geografisk informasjon. Arbeidet har knapt startet, men det har vært avholdt en idedugnad der følgende ustrukturerte liste med punkter er det eneste du har å forholde til deg utover det som står beskrevet over: - Letemannskaper av ulike typer som hundepatruljer, dykkere, helikoptersøk, medisinsk personell, vanlig personer
- Leteoppdrag der tidspunkt for hele aksjonen, kontaktinformasjon til nøkkelpersoner og navn på selve aksjonen ligger. I tilfeller der det ikke er et reelt oppdrag, men bruk av systemet i opplæringssammenheng, skal man operere med Letescenario. - Kapasitetsplanlegger som forteller om hvem av letemannskapet skal delta når, på hvilke leteøkt og leterute. - Vise gjennomførte søk med angivelse av tid, soner som er gjennomsøkt, hvordan man har søkt - Kart, Soner og kartposisjoner - GPS enheter som de som søker utstyres med. Viser informasjon om tidligere søk og loggfører løpende posisjonen som nåværende letemann befinner seg i. Denne informasjonen lastes ned på sentralenhet når søkeøkten avsluttes. - Funn som skal kunne spores til hvem som gjorde det, når det ble gjort og hvor - Evaluering av leteaksjon - Beskrivelse av objektet man leter etter. Antall personer hvis det er en gruppe man leter etter, navn, alder, signalement, spesielle kjennetegn, medisinsk tilstand a) Ta utgangspunkt i at det er valgt RUP som utviklingsmodell. Lag et utkast til prosjektorganisasjon der du forslår styringsgruppe og prosjektgruppe samtidig med at du kommenterer hvordan de ulike fremtidige brukergruppenes interesser er tenkt ivaretatt. (0 %) Her skal kandidatene vise god kontroll over forholdet Styringsgruppe kontra Prosjektgruppe(evt.utviklingsgruppe) og ikke sette opp andre enn prosjektleder som deltager i begge disse. Videre har det vært veldig sterkt oppmerksomhet på at brukermedvirkning ikke skal gjennomføres i styringsgruppa, men at dette på skje på prosjektgruppenivå. Styringsgruppa skal være liten og bestå av ledere (gjerne en fra kunde og minst en fra leverandørsiden) som kun skal jobbe med strategiske beslutninger og ikke med daglige utviklingsoppgaver. Kandidatene bør anvende RUPterminologi når de snakker om roller i prosjektgruppen og også vise RUP sin fokus på å ha mange spesialister med på ulike nivå i prosjektorganisasjonen. Her er det ingen fasit, men et eksempel på Prosjektorganisasjon kan være : Styringsgruppe : Direktør for strategiavdlingen i Politidirektoratet (leder) Adm.dir fra Datakonsulentfirmaet IT-direktør i Politidirektoreatet Project Manager fra Prosjektgruppen Prosjektgruppe (Utviklingsgruppe) : Project Manager Software Architect System Analyst 4 Programmerere 2 GUI-designere Databaseekspert 0 Brukerrepresentanter fra Ledeaksjonsledelse, Politihøgskole og frivillige som deltar i Requirement-aktiviteter og Test-aktiviteter.
b) Lag et konseptuelt klassediagram som viser sammenhengene i den virkelighet som er beskrevet i casebeskrivelsen. Du skal ikke innføre andre forhold enn det som er omtalt. (20 %) Leteobjekt -Navn -Beskrivelse -Alder -Kjennetegn -Medis.Tilst.. 0.. Funn -Tidspunkt -Beskrivelse Oppdrag -Oppdragsnavn -Starttid -Leteleder - -Søkid -Søktid -Status Søk Søkeområde -Søkekoordinater Søkeposisjon Letescenarie -Kursnavn Leteoppdrag -Antall savnede Søkegruppe -Leder - Letemann -Navn -Mob.tlf -Leteid Spesialressurs -Type -Utstyr Organisasjon -Navn -Kontaktperson Modellen behøver ikke favne så mye, men her skulle de fleste av de omtalte forholdene være med samtidig med at lesbarheten er god. Som ved tidligere eksamener er jeg her meget kritisk hvis man modellerer funksjonaliteten fremfor tingene. Alle attributter må ikke med og strukturene må ikke nødvendigvis ser helt slik ut, men igjen fokus har vært sterk på å skape seg en modell av hvordan tingene ute i den virkelige verden henger sammen. Det skal ikke inn operasjoner her, og multiplisitet bør i alle fall inn der det er rom for ulike fortolkninger. c) Argumenter for hvor mye (i prosent av samlede utviklingsressurser) du i dette prosjektet vil legge i de kvalitetssikrende aktivitetene Inspeksjoner og Testing, og forklar hvilke fordeler man har av å benytte RUP som utviklingsmodell når man skal anvende seg av Inspeksjoner. (5 %) Kandidaten må belyse at dette systemet i en driftssituasjon er med på å spille en helt livskritisk rolle. Et godt og gjennomtestet system bidrar til å få gjennomført systematiske søk av høy kvalitet. Kvalitetssikring i form av testing og inspeksjoner bør derfor tildeles
betydelige ressurser. Viktigheten av å kombinere helholdsvis Inspeksjoner og Testing bør poengteres, og RUP sin store støtte og sterke fokus for begge bør trekkes frem. Kandidaten bes spesielt om å kommentere RUP sin støtte til Inspeksjoner, og det vesentlige her er at RUP med sin sterke dokumentasjonsfokus i form av at det lages artefakter innen alle områder gjør at man på alle stadier i utviklingsløpet har dokumenter man kan legge til grunn i selve inspeksjonen. I tillegg har man egne artefakter og en rekke review roller i RUP for å håndtere inspeksjoner på en god måte. RUP danner derfor en meget god platform for å gjennomføre inspeksjoner. Diskusjonen er langt viktigere enn den rene prosentangivelsen, men et sted mellom 20 og 40 % av utviklingsressursene skulle være relevant her. Geir : Håper dette er tilstrekkelig, men ta gjerne kontakt for fredag hvis du ønsker mer detaljer eller har kommentarer til løsningsmomentene. TomR