Her man argumentere seg frem til ulike svar, poenget er at man viser forståelse for XP som tilnærmingsmåte.

Transkript

1 SYSTEMUTVIKLING VÅR 2005 LØSNINGSMOMENTER (NB! Punktvis og ikke fulldekkende ) OPPGAVE 1. Systemutviklingsmodeller (30 %) Standish Group har i pensumartikkelen Extreme Chaos rangert følgende 10 faktorer som de viktigste suksessfaktorene for systemutviklingsprosjekter: The CHAOS Ten : 1) Executive Support 2) User Involvement 3) Experienced Project Manager 4) Clear Business Objectives 5) Minimized Scope 6) Standard Software Infrastructure 7) Firm Basic Requirements 8) Formal Methodology 9) Reliable Estimates 10) Others a) Trekk frem den suksessfaktoren du mener XP legger best tilrette for og den suksessfaktoren XP legger dårligst til rette for å håndtere (velg blant de 9 første). Vis til XP-practices med stor relevans for din vurdering. Her man argumentere seg frem til ulike svar, poenget er at man viser forståelse for XP som tilnærmingsmåte. Best : Dårligst : 5. Minimized Scope Dette er et kjernepunkt innen XP. Practice : Planning Game der man setter mål for inneværende iterasjonsom ofte er på 3 ukers varighet. ( avhengig av argumentasjon bør også 2 og 4 gis en belønning hvis man støtter seg på practicen On-site customer og kommenterer at det er denne som priorieterer blant User Storiene i Planning Game) 8. Formal Methodology Dette strider klart med XP som jobber minst mulig innslag av formalisme og byråkrati rundt utviklingsaktivitetn. (Belønning kan gis til punkt 7, der man søker å minimalisere endringsbehovene strider også med at man innen XP embraces change, og 6 der XP baserer seg på prinsippet om Simple Design fremfor stabilitet i infrastruktur ) XP utmerker seg i liten grad i positiv eller negativ retning når det gjelder de øvrige punktene. b) Trekk frem den suksessfaktoren du mener RUP legger best til rette for og den suksessfaktoren RUP legger dårligst til rette for å håndtere (velg blant de 9 første). Vis til Disipliner, Artefakter og Roller med stor relevans for din vurdering.

2 Best : Siden RUP er et stort rammeverk, har denne modellen mekanismer som støtter veldig mange aspekter ved en systemutviklingsprosjekt. Viktig at kandidatene viser at de kan prioritere, og ikke minst vise til hvilke deler av RUP som støtter deres valg. Punkt 8 om formalisme er nok mest fremtredende. Med tilgang på å konfigurerer prosjektet ut på basis av at RUP definerer over 100 artefakter og over 30 roller er støtteapparatet rundt formalisme formidabelt. Her bør det henvises til artefaktet Development Case i Environment disiplinen. Andre punkter man kan finne støtte for er 1 og 4 som begge støttes av disiplinene Bus.Mod. og Vision artefaktet. Punkt 6 har klar støtte i Software Arhitecture Document (Analysis & Design) og i at rollen Software Architect er fremtredende, og 7. kan støttes av sterk fokus på artefaktet Use Case i disiplinen Requirements i fasene Inception og Elaboration. Dårligst : Punktet 5 er ikke i samsvar med RUP filisofi. RUP har mekanismer som i i første rekke kommer til sin rett når kompleksiteten i prosjekten blir større, og fokus på å minimalisere omfanget er derfor ikke fremtredende. c) (Denne oppgaven er ikke koblet til Extreme Chaos artikkelen) Du skal i denne oppgaven benytte deg av det vi har lært om domenemodellering og vise forståelse for sentrale elementer i et XP-prosjekt. Lag et konseptuelt klassediagram over et XPprosjekt og kommenter modellen. Skissen under viser noen sentrale konsepter i et XP-prosjekt. Ikke helt gjennomtenkt ennå, men viser mye av det jeg er ute etter. Modellen bør være kommentert. On Site Customer User Story Programmin g Pair n User Task Unit Test Acceptanc e Test 1..n Kildekode Small Release Figur 1 OPPGAVE 2. Verifikasjon og validering (20 %)

3 a) Inspeksjoner og Testing er to komplementære tilnærminger for validering og verifikasjon av programvare. Forklar med utgangspunkt i V-modellen hvordan de to tilnærmingene utfyller hverandre. Dette er et tema som du jo sitter med mye kompetanse på. Punktene her er derfor mer ment som hint om hvordan min dekning av temaene kan prege svarene. Man bør vise god forståelse for V-modellen, og direkte anvende denne i forklaringen. Videre er det essensielt at man viser at Inspeksjon er noe man gjør på dokumenter, modeller og andre artefakter etter hvert som de utformes hele veien gjennom prosjektet (fra kravspek- til programinspeksjoner). Inspeksjoner kan dermed knyttes til den venstre siden av V- modellen. Man trenger her ikke vente til det foreligger en kjørbar og dermed testbar versjon av programvaren. Testing gjøres på kjørbar programvare altså i etterkant og uløselig knyttet til høyre side i V-modellen(evt. i pilotversjon eller også på prototyper). Vi har sett på BB og WB testing og dekket hele spekteret fra Enhetstesting til Systemtesting og Akseptansetest. Inspeksjoner og Testing utfyller hverandre gjennom at man får sjekket produktet både før og etter at programvaren kjøres. b) Gi en vurdering av hvor lett du mener det er å estimere innsatsbehovet for henholdsvis inspeksjon og feilretting på et tidlig tidspunkt i et prosjekt der man følger fossefallsmodellen. Kjernen her er at inspeksjonene kan planlegges lang tid på forhånd, men kan tidlig avklare hvor mange som skal være med og hvor lang tid de skal bruke på forberedelser og gjennomføring av inspeksjonene. Dermed er dette av de lettere aktivitetene å estimere. Feilretting derimot er svært uforutsigbar, siden man har stor utsikkerhet både rundt antall feil man må rette opp i, og rundt at tiden det tar å rette opp i den enkelte feil også er meget varierende og uforutsigbart. Det eneste man her kan basere seg på er erfaringer fra tidligere prosjekter, men siden det ofte er utskiftinger i mannskapet blir dette svært vanskelig. Poenget blir da at feilretting generelt må sies å være svært vanskelig å estimere. OPPGAVE 3. Arkitektur (20 %) a) Sommerville beskriver tre arkitekturmodeller (repository, klient-tjener og lagdelingsmodellen). Samtidig omtales et generelt designprinsipp om å utvikle moduler som har høy styrke og lave koblinger. Forklar hvordan arkitekturmodellene og designprinsippet komplementerer hverandre i arbeidet med å oppnå et godt design på programvaren. Sommerville omtaler arkitekturmodellene som grunnleggende måter å organisere en programvare på (brukt hver for seg eller i kombinasjon). Dette gir altså en basisskisse for systemets organisering f.eks kan den vise sub-systemer løsningen skal bestå av. Designprinsippet om høy styrke og lave koblinger er med på å sikre at også den finere inndelingen av systemet gjøres på en måte som gjør løsningen lettere vedlikeholdbar og gjenbrukbar. Det er viktig at kandidaten viser innsikt i poenget om modulær dekomponering.

4 Det er bra hvis man henviser til for eksempel et tre-lagsstruktur som en arkitekturmodell og så viser hvordan man har nytte av å benytte det omtalte designprinsippet til å få en god og ryddig struktur innen hvert enkelt av lagene i modellen. b) Gi begrunnede forslag til hvilken kontroll-modell (call-return, manager, broadcast eller interrupt-driven) du ville valgt for hvert av følgende to systemer : Et batch-orientert system som henter informasjon om ansattes arbeidstimer, finner lønningssatser, skriver ut lønningsslipp og sender betalingsinformasjon til bankforbindelsen En samling av programvareverktøy som utvikles av ulike underleverandører som du senere skal sette sammen til et større utviklingsmiljø Batch-orientert system : Her er det helt klart at kandidaten bør argumentere for at det bør anvendes en sentralisert kontroll-mekanisme ut fra systemets natur. De bør vise til karakteristika ved systemet. Systemets sekvensielle natur der det ikke er behov for noen form for samtidighetskjøring gjør Call-Return modellen til den best egnede kontrollstrukturen (her sa jeg vel ved feil til deg på telefonen i går). Gode besvarelser viser innsikt i hvordan denne modellen fungerer. Utviklingsmiljøet : Her skal ulike underleverandører uavhengig av hverandre lage delsystemer som senere skal fungere sammen. De må hver for seg programmeres for hvordan de skal reagere ved ulike hendelser (events) og være i stand til å respondere på alt som angår dem. Delsystemene vil vite når de trenger assistanse fra andre deler av systemet, men kjenner på det tidspunktet ikke til hvem de skal henvende seg til. Alt dette taler for at man her har fordeler av å basere seg på en hendelse-basert kontrollmekaniske, da i form av en Broadcast modell. CASEBESKRIVELSE TIL BRUK I OPPGAVE 4: Med statskanalen NRK som en sentral aktør har man de senere årene sett en rivende utvikling innen mediene og deres måte å formidle informasjon på. Du har som nyansatt i NRKs ITavdeling blitt med i et prosjekt som jobber med utvikling av en IT-løsning som skal støtte redaksjonene i deres formidling. Hverdagen for journalistene preges i økende grad av at reportasjene de lager anvendes på tvers av de tradisjonelle grensene mellom medier (radio, TV, tekst-tv, internett) og mellom redaksjoner (nyhet, sport, kultur ). Den enkelte journalist vil lage reportasjer til bruk i alle kanaler. For eksempel vil et høykvalitetsopptak av en reportasje benyttes i fjernsynet mens en versjon med lav oppløsningen legges ut for avspilling via internett. Lydopptaket legges tilgjengelig i så vel kortversjon som i fullt format slik at det kan spilles av i alle radiokanaler og på internett. Tid er særdeles viktig i medienes kamp om tilhørerne. Journalistene skal under arrangementer som for eksempel fotballkamper både kommentere kampen, legge ut digitale bilder og skrive en kortfattet versjon av kamputviklingen som løpende kan legges ut på nettet samtidig som de gjøres tilgjengelig for redaksjonene i radio og TV. Forut for selve dekningen vil man i redaksjonsmøter ha avklart hvilke saker som skal dekkes. En programsekretær vil rett i etterkant av disse møtene klargjøre alle reportasjer som vil komme inn i løpet av dagen

5 med hensyn til å kategorisere det forventede innhold, tidspunkter etc. For journalisten blir det derfor bare å hente opp og fylle reportasjen med innhold. Det blir viktig at IT-løsningen også gir støtte for å sette sammen innholdet i kjøreplanene for eksempel for radio. Her må løsningen dekke forhold som sendeskjema for hele dagen, enkeltprogram med programleder og reportasjer man ønsker å benytte. Videre består et program av musikkinnslag og opplesningstekst. Løsningen skal anvendes når programmene er på lufta og musikkinnslagene vil da bli hentet fra NRK s musikkarkivsystem. Journalistene skal fremover oppnå bonuser i lønna, og vårt system skal derfor ha en mekanisme for å holde på historikken for bruken av en reportasje. Personalavdelingen vil hver uke hente ut et statistikkgrunnlag for å lønne egne journalister og freelancemedarbeidere. OPPGAVE 4. Objektorientert Analyse (30 %) a) Sett opp et Use Case diagram for systemet og foreta en grov risikoanalyse av Use Casene gjerne i form av en enkel tabell. Se her bort fra risikoer knyttet til selve prosjektgruppa da du ikke kjenner bakgrunn til de andre som skal delta. Jeg har lagt vekt på UC fokus på brukernes mål. Har sagt at det ikke er noe mål å prøve å finne include eller extends bar for å vise at man kan det. Jeg vil trekke klart på feilaktige koblinger (for eksempel en include mellom Lag reportasje og Klargjøre reportasje). Viktig å ikke bryte et helhetlig brukermålsetting ned i små enkeltsteg derfor mener jeg at journalisten kun har ett Use Case. Journalist Lag reportasje Ajourholde kjøreplan Kjøreplan -ansvarlig Kjøre program Programleder Programsekret ær Klargjøre reportasje Personalavdeli ng Hent lønningsgrunnlag Musikkarkiv -system Figur 2 I Risikoanalysen kan en løsning se noe sånn ut :

6 USE CASE Forretningsmessig risiko Teknologisk / Arkitekturmessig risiko Lag reportasje HØY HØY.. Klargjøre reportasje MIDDELS LAV.. Hent lønningsgrunnlag LAV LAV Gode besvarelse kommenterer enkelte forhold rundt priorriteringen man har gjort. b) Sett opp et konseptuelt klassediagram (en domenemodell) der du spesielt kommenterer din bruk av strukturer. Under er sentrale konsepter innen probelmområdet. Jeg forventer mange aggregeringsstrukturer er, men kommentarene til kandidaten må trekkes inn i bildet i forhold til de valg de har gjort. Journalist Kjøreplan Dato Ansvarshavende Kanal 1 Reportasje Tidspunkt Tekst Programkategori Program Programkode Opplesningstekst Programleder (from Use Case View) Bilde Lydopptak Film Rapport Musikkinnslag Figur slutt på oppgavesett