Her er løsningsmomenter for oppgavene Høst 2003 :

Transkript

1 Her er løsningsmomenter for oppgavene Høst 2003 : OPPGAVE 1. Estimering (20 %) Du er leder i et firma med 20 ansatte. Nesten alle er IT-konsulenter som fyller ulike roller i systemutviklingsprosjekter. Dere avslutter normal prosjekter pr. år. Firmaet utvikler kundespesifikke IT-løsninger, og er vant til å måtte kjempe om nye oppdrag gjennom å gi tilbud om fastpris på systemutviklingsoppdrag. Tilbudene utarbeides ut fra kundenes kravspesifikasjoner. Dere benytter en detaljert rutine for å registrere alle utviklingstimer på ulike aktiviteter innen et prosjekt selv om dere får betalt i henhold til fastprisavtalen. Oppdragene som utføres er svært forskjellige. Estimeringskompetansen i selskapet er meget lav. Du får som sjef stadig nærmest likelydende spørsmål rundt temaet estimering. Både prosjektledere og vanlig utviklere som blir bedt om å estimere føler seg lite komfortable med å estimere innsatsbehov. Du har derfor bestemt deg for å formulere korte og faglig begrunnede svar på følgende fire spørsmål du har fått fra dine medarbeidere den senere tid : Det viktigste i denne oppgaven er at kandidatene viser faglig forståelse for ulike aspekter ved estimering. a.) Er det forskjell på et tilbud og et estimat, og er det ikke din oppgave som sjef å drive med disse aktivitetene? Jo, det er forskjell. Et estimat er en mest mulig realistisk prediksjon på behovet for utviklingsinnsats på en forespeilet oppgave. Dette må settes opp av de som har best mulig forutsetninger for det i form av domene, teknologi og estimeringskunnskap. Det er derfor ikke naturlig at sjefen i bedriften sitter å gjør dette. Både prosjektleder og potensielle utviklere i aktuelle caset bør involveres. Et tilbud derimot er en strategisk satt pris, der blant annet estimatene benyttes om input, men der også vurderinger rundt hva kunde er villig til å betale, fremtidig potensiale ved å gjennomføre et prosjekt m.m. trekkes inn. Dette er det i langt større grad sjefens oppgave å bestemme (da ofte i samarbeid med prosjektleder) b.) En kunde har spurt om vi bruker COCOMO når vi estimerer. Hva i all verden er det for noe, og er det aktuelt for oss å bruke det? Dette er en algoritmisk modell for beregning av innsatsestimater. (s i Sommerville). En maksbesvarelse viser grunnformelen, og kommenterer at denne er fremkommet ut fra empiriske målinger på et stort antall (gamle) SU-prosjekter. Bonus for kommentarer rundt at modellen baserer seg på en prediksjon om størrelse (LOC, FP, UC-point..) og produktivitet, samt nødvendigheten av at modellen kalibreres til bruk i organisasjonen. Aktuelt å bruke? : Argumentasjonen det vesentlige, ikke noe riktig svar her. For : liten generell estimeringskompetanse gjør aktuelt å ta i bruk modell. Mot : tung innføringsprosess med tilhørende kalibrering. Problem rundt eierskap på estimatene.

2 c.) Jeg har så vidt hørt om tre ulike tilnærminger til estimering: Algoritmiske modeller, Analogibasert estimering og Ekspertvurderinger. Hvilken av de tre er mest relevant for vårt firma å benytte? Argumentasjonen det klart viktigste. Må vise kunnskap om forskjellene i tilnærmingene og koble disse til enkelt trekk ved det oppsatte scenariet. Analogi virker tilsynelatende meget aktuelt ut fra at man har detaljerte data på historisk forbruk, men kommentaren om at Oppdragene som utføres er svært forskjellige taler direkte mot denne estimeringsformen. Algoritmiske modeller se opg. B. Ekspertvurderinger : Fordeler her er liten ressursbruk, ekspertene takler svært forskjellige oppdragstyper godt, man oppnår godt eierskap og tro på estimatene og involvering av de som sitter med detaljkunnskap taler for. Liten estimeringskompetanse taler mot denne estimeringsformen. Jeg tenderer mot at Ekspertvurderinger er det mest riktige valg, deretter Algoritmiske, med Analogi som minst relevant. De detaljerte dataene fra historiske prosjekter bør benyttes som en av flere kilder som ekspertene bør støtte seg på ved estimering. d.) I prosjektet Kvikk har vi valgt å bruke XP som utviklingsmodell. Da trenger man vel ikke estimere? Jo, men i første rekke på et detaljert nivå. I XP estimerer man med fokus på å få realisme i hvor mye utviklerne kan ta på seg av oppgaver i den iterasjonen man er i ferd med å påbegynne. Estimering gjøres av de som selv skal utvikle det aktuelle User task, og brukes innen Planning Game. Pensum som går inn på dette : OPPGAVE 2. Testing og Systemutviklingsmodeller (20 %) a) Forklar V-modellen og dens anvendelse innen testing i systemutviklingsprosjekter. Vurder relevansen av hvert av de fem understående punktene i denne sammenheng, og plasser de som har relevans på riktig sted i V-modellen. - Use Case beskrivelser - White-box testing - Risikoanalyse - Stress Testing - Refactoring Astrid : Denne modellen kjenner du bedre til enn meg, så forklaringen tar jeg lett på her. Jeg har brukt tid på å gå gjennom fig i Sommerville. Use Case beskrivelser : Bør plasserers ved Kravspesifisering, kommentarer rundt at det danner grunnlag for å sette opp Akseptanse testplan og anvendes i black-box brukerstesting premieres White-box : plasseres ved Enhets og modultest Risikoanalyse : ikke relevant å trekke inn her

3 Stress Testing : plasseres ved Systemtest (etter integrasjonstest) Refactoring : en practice i XP, men ikke relevant for testing. Vanligvis er det vanskeligere for studenter å si Nei, dette er ikke relevant. enn å prøve å forklare at jo det er jo litt relevant. Jeg premierer derfor spesielt de som utelukker de riktige punktene nemlig Risikovurdering og Refactoring. b) Det er klare forskjeller på hvordan man legger opp testaktivitetene i utviklingsmodellene XP og RUP. Trekk frem sentrale trekk i hvordan testingen legges opp i hver av disse, og hva forskjellene går ut på. Testing i XP : Poenget er et kandidatene viser forståelse for Test first practicen i XP. Utviklerne skal altså først skrive/sette opp testcase, så skal de utvikle, og deretter kjøre gjennom testcasene. Brukere gjennomfører blackbox testing etter iterasjoner eller i allefall ved releaser. Kommentarer på fokusen på automatisering innen test er bar. Testing i RUP : Testing bygd opp rundt at RUP er en inkrementell og iterativ utviklingsprosess. En aktivitet som stadig gjennomføres etter hvert som utviklingen skrider frem, men som intensiveres mot slutten av prosjektet, etter hvert som stadig mer implementeres. Testing er en egen disiplin (kalt workflow i whitepaper som er pensum). CASE (som skal danne basis for løsingen av oppgave 3 og 4 på neste side) : Eiendomsmegleren: Du er leid inn av et nyetablert eiendomsmeglerfirma som har tenkt å ta opp kampen med de veletablerte konkurrentene ved blant annet å utvikle og ta i bruk mer avanserte internett baserte løsninger til kjøp og salg av boliger, hytter og næringseiendommer. Mens nettauksjoner (QXL, gibud.no. ) er blitt meget utbredt for mindre salgsobjekter, er det foreløpig lite utbredt i forbindelse med eiendomssalg. De etablerte eiendomsmeglerne har derimot i lang tid anvendt internett løsninger som en støtte i kjøp og salg av eiendommer. Fra helt enkle løsninger med en ren presentasjon av salgsobjektene til mer omfattende løsninger der man kan sjekke innlagte bud og hente ut budskjemaer som så kan fakses inn. Systemet du skal være med å utvikle skal selvfølgelig dekke innlegging og ajourhold av presentasjoner av salgsobjektene. Et salgsobjekt har en del kjernekarakteristika som eiendomstype, adresse, boareal, bruttoareal, tomtestørrelse og prisantydning. Videre kan det bestå av en videopresentasjon, en mer detaljert tekstlig beskrivelse og/eller en bildeserie. Firmaets forretningside baserer seg på at selgerne selv tar over flere av de funksjonene meglerne tradisjonelt har hatt. Selger sitter selv med ansvaret for å legge inn og ajourholde informasjon om eiendommen de skal selge, samt å foreta visninger. Interesserte vil finne informasjon om selgerens mobiltelefon, e-post og faks når de søker seg frem til salgsobjektet på nettsidene. Av kvalitetssikringshensyn skal en ansatt i eiendomsfirmaet alltid godkjenne de endringer som ulike selgere legger inn. Inntil dette er gjort er det den sist godkjente

4 versjonen av presentasjonen som er aktiv. Den ansvarlige vil spesielt sjekke at riktig verditakst og lånetakst oppgis av selgeren. Meglerfirmaet får nemlig tilsendt denne informasjonen fra alle takstmenn via e-post så snart denne foreligger. Administrasjon av budrundene er sentralt i systemet. For å kunne delta i disse må man som potensiell kjøper først skaffe seg et tidsbegrenset budsertifikat. Vedkommende registrerer seg som budgiver i systemet, og angir personalia som fødselsnummer, adresse, e-postadresse, mobiltelefonnr. Systemet vil under registreringen koble seg opp mot Brønnøysundregisteret, betalingsdyktighets-systemet hos et inkassobyrå samt utlånssystemet hos din bankforbindelse. På basis av innhentet informasjon vil det så bli skapt et budsertifikat tilknyttet deg som budgiver. Dette inneholder et fra og til tidspunkt og en maksimal budstørrelse. Ved innlegging av et bud fra en budgiver, sjekkes dette mot at man har gyldig sertifikat før det godkjennes. De fem siste budgiverne vil samtidig bli varslet om det nye budets størrelse og tidsfrist via en SMS-tjeneste. En time før selgers oppgitte budfrist stenges muligheten til å operere med åpne bud. Kun de budgiverne som hadde gitt de tre høyeste budene inviteres til en lukket budrunde. Man vil i en lukket budrunde ikke få vite noe om de andre to budgivernes eventuelle sluttbud. OPPGAVE 3 : Objekt Orientert Analyse på caset a) Lag et Use Case diagram for systemet og kommenter dette. (15 %) Vi bruker Rational Rose på HiG, men har problemer med at lisensnøkkelen i Rational SEED-avtalen vår nettopp denne uka går over til en IBM Scholar Program avtale. Dette gjør at jeg faktisk ikke får benyttet Rose til å lage løsningsforslaget!!! Følgende Aktører og Use Case bør fremgå av en god løsning : Aktør : Use Case : ================================================================ Selger Legge inn salgsobjekt (disse to kan evt. slås sammen) Selger Ajourføre salgsobjekt Megler Potensiell kjøper Potensiell kjøper og <<system >> SMS-tjeneste Potensiell kjøper og <<system >> Brønnøysund og <<system >> Inkasso og <<system >> Bank Godkjenne endringer på salgsobjekter Søk frem informasjon om salgsobjekt Legg inn bud Generer budsertifikat Som du ser benytter jeg ingen uses / include eller extends i mitt løsningsforslag, men noen av Use Casene involverer aktører både i form av sluttbrukerroller (som vi tegner som

5 fyrstikk menn) og aktører i form av andre datasystemer (som vi både har tegnet som fystikkmenn, men også som stereotypede bokser med <<system>>). God navngivning, gode forklaringer teller positivt. Dataflyt trekker sterkt ned. b) Det finnes alternative måter å uttrykke variasjonene rundt at budgivning skal kunne foregå i så vel åpne og lukkede runder. Beskriv hvordan dette kan løses henholdsvis internt innen et Use Case, og i form av at man her kan spesifiserer dette med å lage koblinger mellom Use Case (10%) Jeg har fokusert sterkt på at tekstbeskrivelsen er det desidert viktigste innen UC. Vi har likevel jobbet noe med alternative måter å håndtere varianter på. Dette er nok den mest perifere og vanskeligste oppgaven i dette eksamenssettet. Her forventer jeg svar som viser at man innen en Use Case beskrivelse kan operere med Extensions i form av at man etter å ha beskrevet en Main Success Scenario/Happy Day kan beskrive alternative use-case forløp som en variant ( Variants ) med en numerert henvisning til hvor denne varianten er aktuell. Alternativet med å koble flere use-case burde man vise ved å lage Use-Caset Legg inn lukket bud, og sette inn en extends pil mot Use Caset Legg inn bud. c) Sett opp et konseptuelt klassediagram (en domenemodell) der du også angir multiplisitet på relasjonene og legger inn sentrale attributter (15 %) Siden Rose er nede, blir det igjen tekstbeskrivelse. Her gir jeg rimelig god score til modeller som er enkle men korrekte, fremfor modeller som kompliserer det hele. At man klarer å identifisere sentrale konsepter som Salgsobjekt, Selger, Bud, Budgiver og Budsertifikat vektlegges tungt. Jeg trekker strengt for de som modellerer funksjoner som klasser, dette har vært fokusert veldig i kurset. De som blander inn forhold som Epost fra takstmann eller Visning eller forhold som ikke inngår i det domene den fremtidige løsingen skal dekke trekkes. Det er også sterkt poengtert at vi ikke skal ha med metoder/operasjoner i et konseptuelt klassediagram, så det trekker klart ned. De som legger inn type fremmednøkkel -attributter på klassene skal trekkes for dette, og de som ukritisk relaterer klassene gjennom overdreven bruk av assosiasjoner, aggregering, compositions og gen-spec strukturer trekkes. For de besvarelsene som skal skille seg positivt ut blir riktig plassering av relevante attributter vurdert. For eksempel vil de gode også legge inn mindre opplagte attributter på Salgsobjekt (., prisantydning, lånetakst, budfrist,.). De beste bør også vise mestring av aggregerings-strukturer (Salgsobjekt aggregerer både Videopresentasjon og Bildeserie, Budsertifikat kan være en composition under Budgiver) og arvestrukturer ( Lukket bud er en spesialisering av Bud).

6 Sentrale klasser her er : Salgsobjekt (som aggregerer Videopresentasjon og Bildeserie ) - eiendomstype, adresse, boareal, tomtestørrelse, lånetakst, prisantydning Selger som er assosiert til Salgsobjekt Bud som er assosiert til Salgsobjekt (et bud et salgsobjekt, et salgsobjekt flere bud) Lukket bud som er en spesifikasjon av Bud Budgiver som er assosiert med Bud Budsertifikat som er uløselig knyttet til Budgiver (composition) OPPGAVE 4 : Gjenbruk (20 %) Eiendomsmeglerfirmaet har et søsterselskap som driver med utleie av hytter og fritidseiendommer. De ønsker også å satse på internett baserte løsninger som kan støtte presentasjon og utleieformidlingen. Her er det både privatpersoner og bedrifter som kan reservere et utleieobjekt på ukebasis. Det er et sterkt ønske om å få sjekket leietakernes betalingsdyktighet. Ut fra din kunnskap om løsningen som skal utvikles for eiendomsmeglervirksomheten, blir du bedt om å foreta en vurdering av potensialet som ligger i gjenbruk av deler av spesifikasjoner og programvareløsning. Gi her din vurdering av hvorvidt man her bør satse på gjenbruk, eller om man heller bør la løsningene bli utviklet helt uavhengig av hverandre. Uansett om du her argumenterer for eller mot gjenbruk skal du benytte deg aktivt av eksempler fra både Use Case-diagrammet og fra det konseptuelle klassediagrammet i oppgave 3 for å underbygge din argumentasjon. Ikke pensum i 2008.