UNIVERSITETET I OSLO



Like dokumenter
Forside. Eksamen i IN1030 for Våren Ingen hjelpemidler tillatt.

UNIVERSITETET I OSLO

Oppgave 1 Multiple Choice

CRIStin 2.0 Om videreutvikling av CRIStin-systemet. Oppstartseminar 22. Oktober 2013

GJENNOMGANG UKESOPPGAVER 7 REPETISJON

Oppgave 1: Multiple choice (20 %)

UNIVERSITETET I OSLO

Prøveeksamen INF1050: Gjennomgang, uke 15

Forside Eksamen INF1055 V17

Hensikten med denne delen av kurset. Objektets egenskaper. Objektorientering hva er det? Best practises ved programvareutvikling. Kravspesifikasjonen

GJENNOMGANG UKESOPPGAVER 2 PROSESSMODELLER OG SMIDIG PROGRAMVAREUTVIKLIG

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

UKE 11 UML modellering og use case. Gruppetime INF1055

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

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

Eksamen 2013 Løsningsforslag

Individer og samspill framfor prosesser og verktøy. Fungerende system framfor utførlig dokumentasjon

Eksamen INF1050: Gjennomgang, uke 15

UKE 9 Prosesser og prosessmodeller inkludert smidige metoder. Gruppetime INF1055

GJENNOMGANG UKESOPPGAVER 4 USE CASE MODELLERING HELGA NYRUD & KRISTIN BRÆNDEN

Obligatorisk oppgave 5: Modellering av krav

Spesifikasjon av Lag emne

Use Case-modellering. INF1050: Gjennomgang, uke 04

Ansvarsdrevet OO: CRC og UML Sekvensdiagrammer

UKE 16 Kontrakter. Gruppetime INF1055 Julie Hagen Nilsen & Maria Stolinski

Modellering av krav. INF1050: Systemutvikling 07. februar Førstelektor Yngve Lindsjørn

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

Forfattere: Daníelsdóttir, Drífa Meland, Maiken Mijalkovic, Biljana Svendsen, Simen H. Gruppelærer: Zarei, Amir Hossein. 5.

Gjennomgang av prøveeksamen. Gruppetime INF1055 Julie Hagen Nilsen & Maria Stolinski

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

UML-Unified Modeling Language

Ulike typer prosessmodeller. Systemutvikling. Utviklingsmodeller. Prosessmodell - faser

UML 1. Use case drevet analyse og design Kirsten Ribu

GJENNOMGANG UKESOPPGAVER 6 MER OM OBJEKTORIENTERING OG UML

UML-Unified Modeling Language. Prosess-oversikt. Use case realisering

Løsningsforslag: Oblig 1. INF1050: Gjennomgang, uke 12

t Institutt for informatikk Erik Arisholm 13. mai 2009 INF1050-oppsummering-1

Gruppenavn. Prosjektnavn Beskrivelse av design For Navn på systemet. Versjon <1.0>

GJENNOMGANG OBLIGATORISK OPPGAVE 1

Løsningsforslag Sluttprøve 2015

Universitetet i Oslo Institutt for informatikk. Eskild Busch. UML hefte

UML- Use case drevet analyse og design. Domenemodeller Sekvensdiagrammer Use case realisering med GRASP patterns Klassediagram - designmodeller

Objektorientering og UML. INF1050: Gjennomgang, uke 06

Prosessmodeller og smidig programvareutvikling. INF1050: Gjennomgang, uke 02

I dag UML. Domenemodell visualisering av konsepter. Eksempel. Hvordan finne domeneklasser?

UNIVERSITETET I OSLO

UNIVERSITETET I OSLO

Tittel Objektorientert systemutvikling 2

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

Smidig metodikk, erfaringer fra NAV Fagportal

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

Kontrakter. INF1050: Gjennomgang, uke 12

Modellering IT konferanse

Mer$om$objektorientering$og$UML

Fra krav til objekter. INF1050: Gjennomgang, uke 05

UNIVERSITETET I OSLO

IN2001: Kravhåndtering, modellering, design

Kap 11 Planlegging og dokumentasjon s 310

UNIVERSITETET I OSLO

11 Planlegging og dokumentasjon

UNIVERSITETET I OSLO

Spesifikasjon av Lag emne. Kursregistrering bruksmønstermodell. Dagens forelesning. Fra krav til objekter

Del - leveranse Del 2. Inf 2120 fredag Gruppe 1 Knut Johannes Dahle

EKSAMEN 05HBINDA, 05HBINFA, 05HBISA, 05HBMETEA, 06HBINFA. Tom Røise. INNFØRING MED PENN, evt. trykkblyant som gir gjennomslag

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

Fra krav til modellering av objekter

Use case drevet design med UML

Systemutvikling - oppsummering. Alexander Nossum blog.eksplisitt.net 22. mai 2006

God objektorientert design Flere UML diagrammer UML Distilled kap. 7,8, 9 Using UML, kap. 11, 12, 14 Kirsten Ribu

Spesifikasjon av Lag emne. Kursregistrering g bruksmønstermodell. Dagens forelesning. Fra krav til objekter

Prosjektledelse, prosjektplanlegging, teamarbeid

GJENNOMGANG UKESOPPGAVER 13 KONTRAKTER

Obligatorisk oppgave 1 INF1050 Foranalyse og kravhåndtering. av Andreas Johansen Alexander Storheill Martin Dørum Nygaard Tobias Langø Aasmoe

UKEOPPGAVER 2: SYSTEMUTVIKLINGSPROSESSER OG PROSJEKTARBEID INNSPILL TIL SVAR

Gjennomgang av eksamen IN1030 Gruppe 4

Kravhåndtering. INF1050: Gjennomgang, uke 03

Gruppetime

Lykke til! Eksamen i fag SIF8018 Systemutvikling. 20 mai, 2003 kl Fakultet for fysikk, informatikk og matematikk

UNIVERSITETET I OSLO

Kandidat nr. 1, 2 og 3

Erfaringer med PS2000 kontrakt og kontraktsstyring i PERFORM. Mette Gjertsen Prosjektleder Statens Pensjonskasse

Forskningsmetoder. INF1050: Gjennomgang, uke 13

System Dokumentasjon. Team2. Høgskolen i Sørøst-Norge Fakultet for teknologi, naturvitenskap og maritime fag Institutt for elektro, IT og kybernetikk

UNIVERSITETET I OSLO

Kontrakter og test i smidige prosjekter. Fagmøte Dataforeningen i Trondheim 12.Mars 2012

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

Planlegging og dokumentasjon

S Y S T E M U T V I K L I N G ( L O A )

Kravspesifikasjon med UML use case modellering. Erik Arisholm

Prosjektledelse, prosjektplanlegging, teamarbeid

Transkript:

UNIVERSITETET I OSLO Det matematisk-naturvitenskapelige fakultet Eksamen i: INF1050 Eksamensdag: 2. juni 2014 Tid for eksamen: 09:00-13:00 Oppgavesettet er på 4 sider Vedlegg: Ingen Tillatte hjelpemidler: Alle trykte og skrevne Les nøye igjennom hver oppgave og kontroller at oppgavesettet er komplett før du begynner å besvare spørsmålene. Gjør dine egne forutsetninger og vurderinger hvis du mener oppgaven er mangelfull eller du ønsker å legge til noe eller gjøre endringer. Gjør i så fall rede for de forutsetningene du tar. Oppgave 1: Multiple choice (25 %) For alle oppgavene gjelder at det bare er ett riktig svar. Det holder at du i besvarelsen oppgir alternativene A, B, C eller D for hver oppgave. No Spørsmål Svar A Svar B Svar C Svar D 1 Hva gjør Spesifikasjonen er Det er mer omfattende Smidig metode kontraktregulering ikke avklart ved endringshåndtering enn i forutsetter at det ikke av smidig mer krevende enn tradisjonelle "fossefall" prosjekter? kontraktsinngåelse. "fossefall" prosjekter. inngås kontrakt mellom partene. 2 Hvilket svar er ikke i samsvar med PS2000? 3 Et inkrement i inkrementell utvikling indikerer... 4 Validering i testing av programvare betyr å teste at.. 5 Hva representerer en valgdiamant i et aktivitetsdiagram? 6 I hvilken prosessmodell er det vanligst med daglige standupmøter? Læring absorberes underveis i utviklingsprosessen.... et tillegg i programvaren.... komponenter og delsystemer fungerer sammen. Gjennomføringsmodellen er beskrevet i kontrakten.... en iterasjon i smidig utvikling.... produktet bygges på riktig måte. Endelig spesifikasjon av utviklingsiterasjonene skjer ved kontraktsinngåelse. et tillegg i kravspesifikasjonen.... systemet gjør det brukeren virkelig ønsker. Det forutsetter en klar spesifikasjon ved kontraktsinngåelse. Partene deler kommersiell risiko gjennom en målprismodell. en milepæl for prosjektet. 'for'-løkke 'Class' 'while'-løkke 'if then else'-test XP Fossefall Spiralmodellen Scrum 1

No Spørsmål Svar A Svar B Svar C Svar D 7 Hvilken kontraktmodell "Fossefall" Ressurskjøp Iterativ modell En smidig kontraktmodell gir leverandøren mest omfattende ansvar for hvilket resultat som vil bli levert? 8 Kanban brukt i. indikerer bruk av indikerer anvendelse av er en fase i er en del av Scrum. systemutvikling... 9 Hva brukes i UML for spesifikasjon av grensesnitt (Interface)? 10 Hva menes med høy kohesjon for et objekt? 11 Hva menes med lav kobling for et objekt? 12 Hva inngår i kontrollobjekt prinsippet (Kontroller)? 13 Hva er sammenhengen mellom systemutvikling og programmering? 14 Hvilket av disse utsagnene er feil? tidsbokser. konseptet just-in-time. fossefallsmodellen. Sekvensdiagrammer Klassediagrammer Use Case-diagrammer Tilstandsdiagrammer Objektet har oppgaver innenfor ett funksjonelt område. Objektet samarbeider med så mange andre objekter som mulig. Kontrolleren har kun attributter. Programmering gjøres uavhengig av systemutvikling. Prototyping er gunstig for å hindre feil i koden. 15 Hva er Kjennskap til domenekunnskap? aspektene ved domeneservere 16 Hvilket krav er funksjonelt? 17 Når to eller flere Use Cases har en felles del kan vi benytte... 18 Hvilke av følgende er et ikke-funksjonelt krav? 19 Hvilken hovedtype av krav omhandles i Use Casediagrammer? 20 Hvilke diagramtyper er sentrale i modeller av brukerinteraksjoner? Systemet skal implementeres i Java. Objektet har oppgaver innenfor mange funksjonelle områder. Objektet samarbeider med et lite antall andre Kontrolleren gjør all jobben selv. Programmering og systemutvikling er det samme. Prototyping gjøres før produksjon av mange typer produkter. Kunnskap om et bestemt fagfelt Skjermbildet som vises skal kunne skrives ut. include-relasjonen. extend-relasjonen. multiplisere to tall. Krav til brukergrensesnitt Klassediagrammer og aktivitetsdiagrammer Systemet bør kunne legge til registreringer av flybilletter. Ikke-funksjonelle krav Use Case diagrammer og sekvensdiagrammer Objektet oppretter mange andre Objektet har ingen kobling til andre Kontrolleren delegerer oppgaver og styrer ett eller flere Use Case. Programmering er en viktig del av systemutvikling. En prototype kan tidlig vise viktig funksjonalitet til kunden. Utvikling av domener Innlogging skal ta mindre enn 15 sek. i gjennomsnitt. generalisering. søke etter navn i et personregister. Funksjonelle krav Aktivitetsdiagrammer og tilstandsdiagrammer Objektet kaller mange metoder i andre Kontrolleren ligger alltid på serveren. Systemutvikling er en viktig del av programmering. En prototype kan være gunstig for å vise et brukergrensesnitt. Utvikling av nettsider med eget domene takle 1000 samtidige brukere. 2

Oppgave 2: Modellering sykkelutleie og bestilling av hotellrom (45 %) Sykling på Mallorca har blitt svært populært. Et norsk firma har etablert seg med sykkelutleie, sykkelverksted og sykkelgarasje i tilknytning til et hotell på Mallorca. Firmaet har også avtale med andre hoteller i nærheten. Firmaet tilbyr i dag en enkel webside der interesserte kan sende e-post om ønsket periode for leie av sykkel og tilsvarende ønsket periode for bestilling av hotellrom. Ettersom det blir stadig flere interesserte, er det tungvint å håndtere all e-post på grunn av mye manuelt arbeid i etterkant. Selskapet ønsker nå å tilby et web-basert system for bestilling og betaling av både sykler og hotellrom. Web-løsningen skal altså kommunisere med to forskjellige bestillingssystemer: ett for bestilling av sykler og et annet for bestilling av hotellrom. Bestillingssystemene kommuniserer igjen med hvert sitt betalingssystem. Ved bestilling av sykkel og/eller hotellrom oppgis personalia: Navn, adresse, telefon og e-postadresse. Personalia oppgis kun én gang, selv om kunden vil bestille både sykkel og hotellrom. Ved bestilling av sykkel oppgis type sykkel (landeveissykkel eller vanlig sykkel) og ønsket periode (fra og til dato). Ved bestilling av hotellrom velges hotell fra en liste av hoteller, type rom (singel eller dobbeltrom) og ønsket periode (fra og til dato). Det er ikke lagt opp til å ha med barn, slik at maksimalt to personer kan dele rom. Alle rom har inkludert frokost, men det er mulig å bestille opphold med alle måltider inkludert mot et tillegg i prisen. Det er mulig å bestille hotellrom uten å bestille sykkel, og bestille sykkel uten å bestille hotellrom. Periode for leie av sykkel og hotellopphold trenger ikke være det samme. Leie av sykkel og hotellrom må betales med Visa eller Mastercard via den web-baserte løsningen. Betalingen gjøres separat: ett beløp for sykkel og ett beløp for hotellrom. Endelig bekreftelse på bestilling av sykkel og hotellrom gis først når betalingen er fullført. Man antar at mange vil ønske å endre tidsperiode for bestillingen hvis det ikke er ledig sykkel eller hotellrom i angitt periode. Det skal derfor være mulig å bestille både sykkel og hotellrom før man starter betalingen. Hvis det ikke finnes ledig sykkel av angitt type i hele perioden bestillingen gjelder for, gis det melding om dette, og det må bestilles på nytt. Tilsvarende gjelder for bestilling av hotellrom. a) Lag et aktivitetsdiagram for bestilling av sykkel og hotell. Diagrammet skal ta hensyn til at den som bestiller, kan bestille to typer sykler (vanlig sykkel eller landeveissykkel). Hotellrom kan være singel eller dobbeltrom, og det skal være mulig å bestille med full pensjon (alle måltider) hvis ønskelig. Det skal være mulig å avbryte bestillingen hvis ingen sykler av valgt type er ledige eller ingen rom er ledige på valgt hotell. b) Definer aktører for det web-baserte systemet (sykkel- og hotellbestilling) og tegn et use-case diagram. 3

c) Lag et sekvensdiagram for brukstilfellet bestill sykkel og hotellrom. Du kan anta at det finnes en metode reserversykkel(type:string, fradato:dato, tildato:dato):pris_sykkel som returnerer totalprisen for leie av sykkelen i angitt periode hvis det finnes minst én ledig sykkel av denne typen. Du kan også anta at det finnes en metode reserverrom (hotell:string, typerom:string, fullpensjon: boolean, fradato:dato, tildato:dato): pris_rom som returnerer totalpris for rommet i angitt periode hvis det finnes minst ett ledig rom. Sekvensdiagrammet skal ha med hovedflyt (at sykkel og rom eksisterer) og alternativ flyt (mangler sykkel og/eller hotellrom) i samme diagram. Denne oppgaven skal ikke fokusere på betalingsløsningen, så du kan bruke følgende objekter i sekvensdiagrammet; bss:betalingssystem_sykkel og bsh:betalingssystem_hotell. I klassen Betalingssystem_sykkel er metoden betalsykkel(beløp:int) definert, tilsvarende i klassen Betalingssystem_hotell er betalrom(beløp:int) definert. Du kan anta at sjekking av kredittkort etc. blir utført på en tilfredsstillende måte, så dette skal du ikke modellere. d) Lag et klassediagram som tilsvarer sekvensdiagrammet fra oppgave (c). Klassediagrammet skal ha med attributter, metoder og assosiasjoner med multiplisitet. Oppgave 3: Arkitektur (10 %) Hvilken arkitektonisk stil ( architectural pattern ) mener du vil være best egnet for systemet i oppgave 2. Begrunn svaret. Oppgave 4: Testing (10 %) I oppgave 2 er det fem systemer som kommuniserer. Det web-baserte systemet kommuniserer med to ulike bestillingssystemer som igjen kommuniserer med hvert sitt betalingssystem. Beskriv hvordan du ville testet at denne kommunikasjonen fungerer som den skal. Oppgave 5: Smidig utvikling (10 %) Scrum har blitt en vanlig prosessmodell for utvikling av programvare. a) Gi en kort bekrivelse av rollen Produkteier og beskriv hvilke av de 12 smidige prinsippene denne rollen understøtter og på hvilken måte den gjør det. b) Gi en kort beskrivelse av teknikken «daily standup» og beskriv hvilke av de 12 smidige prinsippene denne teknikken understøtter og på hvilken måte den gjør det. --------------------- Lykke til ------------------------- 4

Vedlegg: De 12 smidige prinsippene: 1. Vår høyeste prioritet er å tilfredsstille kunden gjennom tidlige og kontinuerlige leveranser av programvare som har verdi. 2. Ønsk endringer i krav velkommen, selv sent i utviklingen. Smidige prosesser bruker endringer til å skape konkurransefortrinn for kunden. 3. Lever fungerende programvare hyppig, med et par ukers til et par måneders mellomrom. Jo oftere, desto bedre. 4. Forretningssiden og utviklerne må arbeide sammen daglig gjennom hele prosjektet. 5. Bygg prosjektet rundt motiverte personer. Gi dem miljøet og støtten de trenger, og stol på at de får jobben gjort. 6. Den mest effektive måten å formidle informasjon inn til og innad i et utviklingsteam, er å snakke ansikt til ansikt. 7. Fungerende programvare er det primære målet på fremdrift. 8. Smidige metoder fremmer bærekraftig programvareutvikling. Sponsorene, utviklerne og brukerne bør kunne opprettholde et jevnt tempo hele tiden. 9. Kontinuerlig fokus på fremragende teknisk kvalitet og godt design fremmer smidighet. 10. Enkelhet kunsten å maksimere mengden arbeid som ikke blir gjort er essensielt. 11. De beste arkitekturer, krav og design vokser frem fra selvstyrte team. 12. Med jevne mellomrom reflekterer teamet over hvordan det kan bli mer effektivt og så justerer det adferden sin deretter. 5