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

Save this PDF as:
 WORD  PNG  TXT  JPG

Størrelse: px
Begynne med side:

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

Transkript

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

2 Innhold 1 Klassediagram 2 Sekvensdiagram 2.1 Oppgave 2a 2.2 Oppgave 2b 2.3 Oppgave 2c Prosjektplanlegging 3.1 Oppgave 3a Oppgave 3b Oppgave 3c Oppgave 3d Referanser

3 1 Klassediagram «Lag et klassediagram for systemet. Ta med assosiasjoner mellom klassene, og metoder og attributter til hver klasse. Husk at dere kan skrive egne forutsetninger, og forenkle der det er nødvendig. (Husk også at alle metoder og attributter dere kommer frem til i oppgave 2 skal være med her).» Diagram 1: Klassediagram som Markasykkelsystemet. To do: Spesifiser eventuelle endringer og utvidelser 2

4 2 Sekvensdiagram 2.1 Oppgave 2a «Lag en tekstlig bekrivelse for brukstilfellet Registrer utlån. Ha med aktører, eventuelle pre- og postbetingelser, hovedflyt og alternativ flyt der kunden ikke finnes i systemet fra før.» Den tekstlige beskrivelsen presentert i denne oppgaven er basert på eksemplene gitt av Meer Fjeld (2017a) og Lindsjørn (2017a). Navn Registrer utlån Aktør Bruker (primær) Markasykkelsystemet (sekundær) Prebetingelse Bruker står ved marka-sykler stativ Bruker har et reisekort fra ruter (antar at ruter sitt reisekort blir brukt som utlånskort for markasykler) Det er minst en ledig sykkel på stasjonen Postbetingelse Utlån registrert og bruker har sykkel Hovedflyt 1 Brukeren drar reisekortet sitt på et markasykkelstativ som starter utlåningsprosessen 2 Systemet verifiserer at brukeren er registrert 3 Systemet sjekker om brukeren har gyldig billett/abonnement 4 Systemet sjekker om stasjonen har ledig sykkel 5 Markasykkelsystemet registrerer utlånet 6 Markasykkelsystemet sender melding til stasjonen om å låse opp en ledig sykkel 7 Stasjonen låser opp en sykkel 8 Stasjonen viser beskjed om hvilken sykkel brukeren har blitt tildelt 9 Brukeren henter sykkelen Alternativ flyt 1 Steg 2 Brukeren er ikke registrert bruker av markasykkeltjenesten A 1. 1 Stasjonen viser beskjed om at brukeren ikke er registrert. 3

5 2.2 Oppgave 2b «Lag et sekvensdiagram for brukstilfellet Registrer utlån. Bruk de nødvendige klassene og metodene fra oppgave 1. Ta med alternativ flyt der kunden ikke finnes i systemet fra før.» Sekvensdiagrammet i denne oppgaven er basert på eksempler fra læreboken (Sjøberg og Lindsjørn, 2016) og presentasjoner fra Lindsjørn (2017c). Diagram 2: Sekvensdiagram for brukstilfellet «registrer utlån». 4

6 2.3 Oppgave 2c «Lag et sekvensdiagram for brukstilfellet Se oversikt over sykler som ikke er levert i tide.» Sekvensdiagrammet i denne oppgaven er basert på eksempler fra læreboken (Sjøberg og Lindsjørn, 2016) og presentasjoner fra Lindsjørn (2017c). Diagram 3: Sekvensdiagram for brukstilfellet «se oversikt over sykler som ikke er levert i tide». 3 Prosjektplanlegging 3.1 Oppgave 3a «Identifiser de overordnede aktivitetene som inngår i utviklingen av systemet for markasykler. Beskriv disse. Ha med minst 8 aktiviteter.» Vi tar utgangspunkt i hvordan plandreven utviklingsprosess blir beskrevet i læreboken (Sjøberg og Lindsjørn, 2016, kapittel 2 og 4). A1 Kravhåndtering Kravhåndtering går utpå å identifisere krav til systemet som skal lages og å lage en kravspesifikasjon. Kravspesifikasjon er er nødvendig for å kunne konstruere en systemarkitektur og for å kunne danne et grunnlag for hvordan et system skal implementeres. Den er også nødvendig for at forskjellige bedrifter skal kunne legge inn anbud på prosjektet, og for at kunden og organisasjonen som skal utvikle systemet skal kunne skrive en kontrakt. Den ene typen krav er brukerkrav, der kravene er satt opp på en enkel måte som er forståelig for kunden. Den andre typen krav er systemkrav, der kravene er avanserte og detaljerte, og som definerer hvordan implementasjonen skal foregå (Sjøberg, 2017). 5

7 Kravspesifikasjonen kan deles inn i funksjonelle og ikke-funksjonelle krav. Funksjonelle krav definerer hva et system skal oppnå, slik som hvilke funksjoner systemet skal ha og hvilke resultat systemet skal oppnå. Disse kravene kommer under systemets design. Ikke-funksjonelle krav definerer hvordan de funksjonelle kravene skal implementeres i systemet, slik som brukervennlighet, sikkerhet og vedlikehold (Sjøberg, 2017). Kravspesifikasjonens rolle i en systemutviklingsprosess varierer med tanke på hvilken prosessmodell som blir tatt i bruk. I plandrevne modeller spiller kravspesifikasjonen en veldig stor rolle siden all dokumentasjon skjer i starten av utviklingsprosessen. Utviklingen av plandrevne systemer skjer i faser, så det er derfor viktig at kravspesifikasjonen er fullstendig og inneholder presise og detaljerte krav før implementasjonen begynner. I smidige modeller spiller kravspesifikasjonen en mye mindre rolle, siden mye av planleggingen skjer gradvis underveis. Smidige modeller tar forbehold for endring av kravene, så i motsetning til plandrevne modeller, er det ikke like viktig at kravene er veldig detaljerte og nøye dokumenterte før implementeringen begynner. A2 Design - danner systemarkitektur Design av et system er en kreativ prosess som innebærer å lage en beskrivelse av strukturen til programvaren som skal implementeres. Prosessen går ut på å identifisere programvarekomponenter og sammenhengen mellom dem. Design og implementasjon er sammenflettede aktiviteter. Type systemarkitektur velges etter hva som passer til systemkravene. Aktiviteter som inngår under designfasen er design av programvare, database og grensesnitt, samt valg av gjenbrukbare komponenter (Sjøberg og Lindsjørn, 2016, kapittel 7). Det som skal til for å oppnå et godt design er å sette objekter i en slik relasjon at de kan utføre den jobben de skal, å ha et riktig abstraksjonsnivå, å ha en god utforming som er gjenbrukbar og forståelig, og å lage objekter med et lite og veldefinert ansvarsområde (Lindsjørn, 2017c). A3 Implementasjon Implementasjonen av et system er en kritisk fase i systemutviklingsprosessen, der en kjørbar versjon av programvaren utvikles for levering til kunde. Utvikliklingen av programkoden som skal implementeres i systemet kommer som følge av design av systemet. Design av programvare og programmering er en del av implementasjonen, som vil si at man jobber parallelt med disse to. Endringer i utviklingen av programvare må håndteres fortløpende, og da blir gjenbruk av programvare, konfigurasjonsstyring og host-target utvikling tatt i bruk. Implementasjonsfasen innebærer samarbeid mellom utviklere på tvers gitte arbeidsområder. Det forventes at endelig utfall i denne fasen er en stabil, funksjonell og kjørbar versjon av programvaren (Sjøberg og Lindsjørn, 2016, s. 40). A4 Enhetstesting Enhetstesting vil si å teste at alle enheter av programkode fungerer slik de skal, før alle enhetene settes sammen til et ferdig system. Siden det vil bli brukt objektorientert programmering for å implementere systemet, kan en enhet for eksempel være en klasse eller en metode (Sjøberg og Lindsjørn, 2016, s. 240). A5 Integrere systemet Integrering av et system er en fase hvor alle ferdigutviklede komponenter kobles sammen, og der selve programvare og harddisk kobles sammen. Det arbeides fortsatt med arkitekturen til systemet på forskellige aspekter. I noen tilfeller kan det sammenkobles forskjellige plattformer og subsystemer, som 6

8 gjennom integrering muliggjør fri dataflyt gjennom hele systemet, men denne fasen kan være tidkrevende. Det er ønskelig at programkoden som lages er gjenbrukbar, og at den eventuelt tilsvarer andre plattformer. På denne måten spares mye tid og ressurser i systemutviklingprosessen. I denne oppgaven er det viktig å ta i betraktning at mulige problemer kan oppstå ved integrering av Ruter sitt betalingssystemet og markasykkel-systemet (Rouse, 2015). A6 Systemtesting Testing av programvare er en veldig viktig del av systemutviklingsprosessen. Gjennom programvaretesting oppdages feil, det sjekkes om systemet innfrir de funksjonelle og ikke-funksjonelle kravene, og selve systemet kvalitetssikres. Det finnes forskjellige typer testing og det er anbefalt å teste systemet så tidlig som mulig, siden det koster mye mer å fikse feilene som oppstår etter at produktet er tatt i bruk. I tillegg er det viktig å vurdere ekstern testing istedenfor at utviklere tester sin egen kode (Meer Fjeld, 2017c). På bildet under viser vi til testing i de forskjellige fasene av systemutviklingen. To veldig viktige faser er validering «bygger vi det som brukerne ønsker?» og verifisering «bygger vi systemet på riktig måte?» (Software Testing Fundamentals, 2017) A7 Installere systemet Det å installere et system vil si å installere programvaren på de maskinene som systemet skal kjøre på, og å sette programvaren i bruk, alstå å kjøre programmet. A8 Vedlikehold Etter som tiden går vil systemet være under stadig endring som resultat av bruk og vedlikehold. Kravene kan endres, kunden kan komme med nye behov, og loven og markedet kan endres. Noen ganger må det gjøres endringen i koden for å holde systemet stabilt og brukbart, og det vil ikke minst bli utført debugging. En løsning er å bruke flere versjoner av systemet som kan tilpasses nyinnkommende krav. På denne måten kan flere mulige varianter bli testen for å fikse problemet (Sjøberg og Lindsjørn, 2016, s. 319). 7

9 3.2 Oppgave 3b «Ta utgangspunkt i de overordnede aktivitetene som foreslått i oppgave a). Gi hver aktivitet et unikt navn, varighet, eventuelle avhengigheter og milepæler. Gjør dette ved å lage en tabell med utgangspunkt i figur 23.5 side 295 i læreboka.» Svar på oppgaven er fremstilt i tabell 1. Tabellen er basert på eksempler gitt i læreboken (Sjøberg og Lindsjørn, 2016, s. 295) og eksempler gitt av Meer Fjeld (2017b) og Lindsjørn (2017b). Tabellen representerer hver av aktivitetene beskrevet i svaret på spørsmål 3a. Disse aktivitetene har også vært gitt unike navn jf. tabellen A1 - A8. Hver aktivitet har varighet for arbeidet som inngår i aktiviteten. Arbeidet blir målt i person-dager hvor en person-dag representerer arbeidet til en person per en vanlig arbeidsdag. Varigheten blir målt i kalenderdager. Hver aktivitet kan være avhengig av at en annen aktivitet må være ferdig før den kan starte. I plandreven utvikling der fossefallsmodellen benyttes, gjelder prinsippet at output for nåværende aktivitet er input for neste aktivitet. I denne oppgaven bruker vi ikke fossefallsmodellen, men tar utgangspunkt i at utviklingen er plandreven. Tabellen inneholder også milepæler for prosjektet, disse er representert med bokstaven M og en tall for hver milepæl. Tabell 1: Prosjektplan, aktivitet, arbeid, varighet, avhengighet og milepæler. Aktivitet Arbeid (person - dager) Varighet (dager) Avhengighet A A A1, M1 A A2 A A3, M2 A A3 A A5, M3 A A5, M3 A8 Resten av systemets levetid Resten av systemets levetid A7, M4 8

10 3.3 Oppgave 3c «Bruk tabellen til å lage et stolpediagram med utgangspunkt i figur 23.6 side 297 i læreboka.» Diagrammet er basert på eksempler gitt i læreboken (Sjøberg og Lindsjørn, 2016, s. 297) og av Meer Fjeld (2017b). Det er også basert på tabell 1 i denne oppgaven. Diagram 3: Sekvensdiagram (Meer Fjeld, 2017b) (Dager) 3.3 Oppgave 3d «Lag en risikoanalyse ved å benytte en usikkerhetsmatrise. Få med risiko, sannsynlighet for risiko, konsekvens av risiko, hvilke tiltak som må iverksettes og hvem som er ansvarlig for hvert risikomoment. Ha med minst seks risikomomenter.» Svaret på denne oppgaven er fremstilt i tabell 2. Utformingen av tabellen bygger på fremstillingen i læreboken (Sjøberg og Lindsjørn, 2016, s ). Innholdet fra tabell 2 er også satt opp i en usikkerhets-matrise i tabell 3, for en mer tydelig fremstilling av resultatene. I besvarelsen på oppgaven har vi valgt å ta med typen av hvert risikomoment. Det finnes tre hovedtyper av risiko; prosjekt-, produkt- og forretningsrisiko. I tillegg finnes det seks underordnede typer risiko vedrørende forskjellige tema innen systemutvikling; estimering, organisasjon, mennesker, krav, teknologi og verktøy. Vi har også valgt å presisere hva slags tiltak vi foreslår for hvert risikomoment, dvs. et forebyggende tiltak, et minimaliserende tiltak eller en beredskapsplan. Risikomomentene er rangert og satt opp i en nummerert liste etter hvor alvorlige konsekvensene kan være. Det bør noteres at for at lage en god risikoanalyse trengs det mye kunnskap og erfaring. Erfaring fra tidligere prosjekter kan være avgjørende for en prosjektleder som skal utføre analysen, samt detaljert kunnskap og informasjon om prosjektet, organisasjonen, utviklingsteamet og prosessen som skal brukes mv. I denne oppgaven sitter vi ikke på slik kunnskap eller erfaring og besvarelsen bør ses i lys av dette. 9

11 Tabell 2: Åtte risikomomenter, type risiko, sannsynlighet, konsekvens, tiltak og ansvar. Risiko / risikotype Sannsynlighet Konsekvens Tiltak Ansvar #1 Estimering av budsjett Budsjettet for prosjektet ble underestimert. #2 Teknisk Stasjonene som står i marka ikke er robuste nok for å tåle vinter og vær. #3 Estimering av tid Tid for programmering og integrering ble underestimert som ev. bidrar til at utviklere ikke setter av nok tid til testing og debugging. Resultatet blir et system med masse feil. #4 Krav Kravspesifikasjonen er ikke tilstrekkelig for å beskrive det systemet som skal lages. #5 Mennesker Kommunikasjons problemer hos utviklingsteamet ev. mellom utviklere og prosjektledelsen Moderat Katastrofal Forebyggende tiltak Bruk kostnadsmodeller i bland med erfarne prosjektledere for å estimere kostnader. Minimalisering av risiko og beredskapsplan Oppsigelse av ansatte og dermed lengre leveringstid for produktet. Svært lav Katastrofal Forebyggende tiltak Velg type stasjoner som har vist at de tåler vær og vind og har vært brukt i lignende prosjekter før. Beredskapsplan Erstatte stasjonene med stasjoner som er mer robuste. Moderat Alvorlig Forebyggende tiltak Test så mye som mulig underveis i programmeringen, bruk automatiske testverktøy. Beredskapsplan Eventuelt rekrutter et eksternt team for å utføre testing. Lav Alvorlig Forebyggende tiltak Prøv å etablere så godt forhold og kommunikasjon med kunden som mulig, bruk arkitektoniske modeller som utgangspunkt i kommunikasjon med kunden og utviklere. Høy Alvorlig Forebyggende tiltak Velg uformell struktur ovenfor hierarkisk struktur for teamet, tenk på teamsammensetning (personlighetstyper/kjønn), bidra til godt arbeidsmiljø. Minimaliserende tiltak Reorganiser rutiner og kommunikasjonsmåter Beredskapsplan Ev. bytt ut teammedlemmer. Arkitekt for hardware Prosjektleder Utvikler Kunden/ oppdragsgiver Prosjektledelsen/ leverandør Prosjektledelsen Prosjektledelsen Prosjektledelse 10

12 #6 Teknisk Serveren til markasyklersystemet håndterer ikke like mange brukere på samme tid som forventet. #7 Bruk av verktøy Testverktøy fungerer ikke som det skulle og oppdager færre feil enn vanlig, brukere oppdager feil i systemet etter lansering Lav Alvorlig Minimaliserende tiltak / beredskapsplan Sjekk hvilke muligheter foreligger for å erstatte eller kjøpe ny server. Lav Alvorlig Minimaliserende tiltak / beredskapsplan La brukere oppdage feiler og rapportere den. Bruk feilrapporteringsverktøy. Fiks de feilene du får rapportert. Arkitekt for hardware Prosjektledelse Utviklere #8 Organisasjon Endringer i lovverk om behandling av personopplysninger skaper utfordringer og stiller høyere krav til sikkerhet i systemet. Svært høy (Nye lover trer i kraft mai 2018, som kommer til å skape mye usikkerhet på dette området) Mindre alvorlig Forebyggende / minimaliserende tiltak Ta i bruk juridisk konsultasjon, samarbeid med datatilsynet. Beredskapsplan Sett av budsjett for ev. bøter som må betales. Bruk flere versjoner av systemet ved testing av innførte endringerkonfigurasjonsstyring Leverandør Ev. kunden/ kommunen for å fastsette retningslinjer for utvikling av systemer for forvaltningen 11

13 (Sannsynlighet) Tabell 3, viser en usikkerhetsmatrise hvor nivå av sannsynlighet og konsekvens av risiko er representert med tre farger; grønn, gul og rød. Grønn er det laveste nivået for risiko, alle risikomomenter som faller inn på de grønne feltene burde minst ha et forebyggende tiltak. Middels nivå for risiko er representert med gul farge, i dette tilfellet burde det hvert risikomoment ha minst et minimaliserende tiltak. Rød farge representerer høyeste nivå for risiko og i disse tilfellene må det eksistere en beredskapsplan. I denne tabellen har vi plassert de risikomomentene fra tabell 2 basert på sannsynligheten at de inntreffer og konsekvensene de kan ha for prosjektet, produktet og forretningen. Tabell 3: Usikkerhetsmatrise, sannsynlighet/konsekvens. (Konsekvens) Ubetydelig Mindre alvorlig Alvorlig Katastrofal Svært høy #3 Høy #5 Moderat #3 #1 Lav #4 #6 #7 Svært lav #2 12

14 Referanser Meer Fjeld, Y. de (2017a). «Use case modellering». PowerPoint-presentasjon. Universitetet i Oslo. URL: /Uke04%20-%20UseCase_gjennomgang.pdf (sjekket ). Meer Fjeld, Y. de (2017b). «Prosjektledelse, planlegging og teamarbeid». PowerPoint-presentasjon. Universitetet i Oslo. URL: gaver/losningsforslag/uke10%20-%20prosjektledelse_gjennomgang.pdf (sjekket ) Meer Fjeld, Y. de (2017c). «Testing av programvare». PowerPoint-presentasjon. Universitetet i Oslo. URL: /Uke08%20-%20Testing_gjennomgang.pdf (sjekket ) Lindsjørn, Y. (2017a). «Modellering av krav». PowerPoint-presentasjon. Universitetet i Oslo. URL: use-case-modellering.pdf (sjekket ). Lindsjørn, Y. (2017b). «Prosjektledelse, prosjektplanlegging, teamarbeid». PowerPoint-presentasjon. Universitetet i Oslo. URL: inger/inf1050_ _prosjektledelse_teamarbeid.pdf (sjekket ) Lindsjørn, Y. (2017c). «Mer om objektorientering og UML». PowerPoint-presentasjon. Universitetet i Oslo. URL: _objektorient-modellering.pdf (sjekket ) Rouse, M. (2015). Definition: Integration. TechTarget. URL: (sjekket ) Sjøberg, D. (2017). «Kravhåndtering». PowerPoint-presentasjon. Universitetet i Oslo. URL: kravha%cc%8andtering.pdf (sjekket ) Sjøberg, D. og Lindsjørn, Y. (2016). Selected Chapters from Ian Sommerville: Software Engineering. 10. utg. Pearson. 816 s. a Software Testing Fundamentals. (2017). System testing fundamentals: Definition, system testing. URL: (sjekket ) 13

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

Løsningsforslag: Oblig 1. INF1050: Gjennomgang, uke 12 Løsningsforslag: Oblig 1 INF1050: Gjennomgang, uke 12 Obligatorisk oppgave 1: Pensum Bakgrunn for systemet Aktører og interessenter Utviklingsprosesser Kravhåndtering og kravspesifikasjon Use case-modellering

Detaljer

UNIVERSITETET I OSLO

UNIVERSITETET I OSLO Bokmål Kandidat nummer: UNIVERSITETET I OSLO Det matematisk-naturvitenskapelige fakultet Prøveeksamen i: INF1050 Eksamensdag: 0. mai, 2011 Tid for eksamen: 00:00 00:00 Oppgavesettet er på 6 sider Vedlegg:

Detaljer

GJENNOMGANG UKESOPPGAVER 7 REPETISJON

GJENNOMGANG UKESOPPGAVER 7 REPETISJON GJENNOMGANG UKESOPPGAVER 7 REPETISJON INF1050 V16 KRISTIN BRÆNDEN DAGENS TEMA Oppgaver hentet fra tidligere eksamensoppgaver om temaene vi har gått gjennom til nå DAGENS PLAN Gjennomgang av oppgaver Repetisjon

Detaljer

GJENNOMGANG OBLIGATORISK OPPGAVE 1

GJENNOMGANG OBLIGATORISK OPPGAVE 1 GJENNOMGANG OBLIGATORISK OPPGAVE 1 INF1050 V16 KRISTIN BRÆNDEN 1 Systemet for utleie av markasykler ønsker a benytte seg av en eksisterende betalingsløsning, og valget har falt pa det samme betalingssystemet

Detaljer

Use Case-modellering. INF1050: Gjennomgang, uke 04

Use Case-modellering. INF1050: Gjennomgang, uke 04 Use Case-modellering INF1050: Gjennomgang, uke 04 Kompetansemål Modellering av krav Kunne modellere ulike typer krav UML-diagrammer Innføring i grunnleggende UML-modellering Bruksmønster (use case) Sekvensdiagram

Detaljer

UNIVERSITETET I OSLO

UNIVERSITETET I OSLO Bokmål Kandidat nummer: UNIVERSITETET I OSLO Det matematisk-naturvitenskapelige fakultet Eksamen i: INF1050 Eksamensdag: 31. Mai, 2011 Tid for eksamen: 09:00-13:00 Oppgavesettet er på 6 sider Vedlegg:

Detaljer

Kravhåndtering. INF1050: Gjennomgang, uke 03

Kravhåndtering. INF1050: Gjennomgang, uke 03 Kravhåndtering INF1050: Gjennomgang, uke 03 Kompetansemål Kravhåndtering Anvende metoder og teknikker for å Innhente / Analysere / Spesifisere krav Ulike typer krav Funksjonelle krav Ikke-funksjonelle

Detaljer

Konfigurasjonsstyring. INF1050: Gjennomgang, uke 11

Konfigurasjonsstyring. INF1050: Gjennomgang, uke 11 Konfigurasjonsstyring INF1050: Gjennomgang, uke 11 Kompetansemål Konfigurasjonsstyring Hva og hvorfor? I en smidig sammenheng Endringshåndtering Versjonhåndtering Systembygging Release -håndtering Del

Detaljer

UKE 9 Prosesser og prosessmodeller inkludert smidige metoder. Gruppetime INF1055

UKE 9 Prosesser og prosessmodeller inkludert smidige metoder. Gruppetime INF1055 UKE 9 Prosesser og prosessmodeller inkludert smidige metoder Gruppetime INF1055 Hva skal vi i dag? Introduksjon til modul B - systemutvikling (kap. 1, 2 og 3) Prosesser og prosessmodeller + smidig utvikling

Detaljer

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

GJENNOMGANG UKESOPPGAVER 4 USE CASE MODELLERING HELGA NYRUD & KRISTIN BRÆNDEN GJENNOMGANG UKESOPPGAVER 4 USE CASE MODELLERING INF1050 V16 HELGA NYRUD & KRISTIN BRÆNDEN TEMAER SÅ LANGT I KURSET Forelesning 1: Systemutvikling og systemutviklingsprosesser Forelesning 2: Prosessmodeller

Detaljer

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

Modellering av krav. INF1050: Systemutvikling 11. februar 2015. Universitetslektor Yngve Lindsjørn INF1050: Systemutvikling 11. februar 2015 Modellering av krav Universitetslektor Yngve Lindsjørn INF1050 ->Systemutvikling-> Modellering av krav / Yngve Lindsjørn 1 Temaer i dagens forelesning Modellering

Detaljer

Systemutvikling. Universitetet i Oslo, Institutt for informatikk Vår 2017

Systemutvikling. Universitetet i Oslo, Institutt for informatikk Vår 2017 Systemutvikling Universitetet i Oslo, Institutt for informatikk Vår 2017 Dagens plan Introduksjon Emnets oppbygging Praktisk om ukesoppgaver og obligatoriske oppgaver Gjennomgang av ukesoppgaver Registrering

Detaljer

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

1. Hvilke type krav angår sikkerhet og pålitelighet? 1. Hvilke type krav angår sikkerhet og pålitelighet? a) Funksjonelle b) Ikke-funksjonelle Svar: b), IS side 88, lærebok s.96 2. Verdien av etnografi er at den hjelper til å oppdage som reflekterer hvordan

Detaljer

UKE 11 UML modellering og use case. Gruppetime INF1055

UKE 11 UML modellering og use case. Gruppetime INF1055 UKE 11 UML modellering og use case Gruppetime INF1055 Hva skal vi i dag? Analyse og design - kapittel 5 og 7 UML modellering Ukesoppgaver 3: Modellering av krav UML UML Kompetansemål Modellering av krav

Detaljer

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

UKE 16 Kontrakter. Gruppetime INF1055 Julie Hagen Nilsen & Maria Stolinski UKE 16 Kontrakter Gruppetime INF1055 Julie Hagen Nilsen & Maria Stolinski Hva skal vi i dag? OBS!! Siste ordinære gruppetime Kontrakter Ukesoppgaver Gjennomgang av oblig 4 Kontrakter Kompetansemål - Kontrakter

Detaljer

Prøveeksamen INF1050: Gjennomgang, uke 15

Prøveeksamen INF1050: Gjennomgang, uke 15 Prøveeksamen 2016 INF1050: Gjennomgang, uke 15 Overblikk Multiple choice Modellering Aktivitetsdiagram Sekvensdiagram Klassediagram Tilstandsdiagram Krav Ikke-funksjonelle krav og målbarhet Smidig metodikk

Detaljer

Kravspesifikasjon med UML use case modellering. Erik Arisholm 25.02.2009

Kravspesifikasjon med UML use case modellering. Erik Arisholm 25.02.2009 Kravspesifikasjon med UML use case modellering Erik Arisholm 25.02.2009 Unified Modeling Language (UML) Notasjon som støtter opp under modellbasert systemutvikling objektorientert analyse ( hva systemet

Detaljer

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

Modellering av krav. INF1050: Systemutvikling 07. februar Førstelektor Yngve Lindsjørn INF1050: Systemutvikling 07. februar 2017 Modellering av krav Førstelektor Yngve Lindsjørn INF1050 ->Systemutvikling-> Modellering av krav / Yngve Lindsjørn 1 Temaer i dagens forelesning Modellering av

Detaljer

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

Hensikten med denne delen av kurset. Objektets egenskaper. Objektorientering hva er det? Best practises ved programvareutvikling. Kravspesifikasjonen Hensikten med denne delen av kurset Objektorientert systemutvikling Rational Unified Process (RUP) Gurholt og Hasle kap. 6 UML Distilled kap. 2 Å lære modellerings- og designprinsipper og øve opp teknikker

Detaljer

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

1. Hvilke type krav angår sikkerhet og pålitelighet? 1. Hvilke type krav angår sikkerhet og pålitelighet? a) Funksjonelle b) Ikke-funksjonelle Svar: b) 2. Verdien av etnografi er at den hjelper til å oppdage som reflekterer hvordan folk faktisk jobber a)

Detaljer

PROSJEKTPLAN FOR INF [4 3]120-PROSJEKT: PROJECT HOSPITAL 2004

PROSJEKTPLAN FOR INF [4 3]120-PROSJEKT: PROJECT HOSPITAL 2004 PROSJEKTPLAN FOR INF [4 3]120-PROSJEKT: PROJECT HOSPITAL 2004 VERSJON: PROSJEKTPLAN (1.0) 24. SEPTEMBER, 2004 prosjektplan.doc GRUPPE 12 PROSJEKTPLAN: PROSJEKTLEDELSE: USE CASE: KVALITETSSIKRING: ANDRÉ

Detaljer

Instituttets krav om autentisitet og regler for obligatoriske oppgaver gjelder.

Instituttets krav om autentisitet og regler for obligatoriske oppgaver gjelder. SKK Mdul B - Institutt fr infrmatikk vår 2017 - Obligatrisk ppgave 5 Mdellering av krav Innleveringsfrist: Mandag 15. mai, kl. 23:59:00 Levering: Fullstendig besvarelse leveres i egen innleveringsmappe

Detaljer

UNIVERSITETET I OSLO

UNIVERSITETET I OSLO 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:

Detaljer

UKEOPPGAVER 2: SYSTEMUTVIKLINGSPROSESSER OG PROSJEKTARBEID INNSPILL TIL SVAR

UKEOPPGAVER 2: SYSTEMUTVIKLINGSPROSESSER OG PROSJEKTARBEID INNSPILL TIL SVAR INF 1050 UKEOPPGAVER 2: SYSTEMUTVIKLINGSPROSESSER OG PROSJEKTARBEID INNSPILL TIL SVAR Oppgave 1 a) Foranalyse: Foranalysen kan med fordel gjøres i to trinn. Den første er å undersøke finansiering og øvrige

Detaljer

Instituttets krav om autentisitet og regler for obligatoriske oppgaver gjelder.

Instituttets krav om autentisitet og regler for obligatoriske oppgaver gjelder. Systemutvikling - Institutt fr infrmatikk vår 2017 - Obligatrisk ppgave 2 Mdellering av krav Innleveringsfrist: Fredag 7. april, kl. 23:59:00 Levering: Fullstendig besvarelse leveres i egen innleveringsmappe

Detaljer

Fra krav til objekter. INF1050: Gjennomgang, uke 05

Fra krav til objekter. INF1050: Gjennomgang, uke 05 Fra krav til objekter INF1050: Gjennomgang, uke 05 Kompetansemål Systemmodellering og systemperspektiv Utvikle abstrakte modeller av et system Ulike modeller representerer ulike perspektiver av systemet

Detaljer

Objektorientering og UML. INF1050: Gjennomgang, uke 06

Objektorientering og UML. INF1050: Gjennomgang, uke 06 Objektorientering og UML INF1050: Gjennomgang, uke 06 Kompetansemål Objektorientert design Objektdesign og ansvarstilordning Bruk av UML Fokus på klassediagrammer Designmodeller Designmønstre ( design

Detaljer

Løsningsforslag Sluttprøve 2015

Løsningsforslag Sluttprøve 2015 Høgskolen i Telemark Løsningsforslag Sluttprøve 2015 Emne: IA4412 Systemutvikling og dokumentasjon Fagansvarlig: Hans- Petter Halvorsen, Olav Dæhli Klasse: IA2, A- vei Dato: 2015.05.27 Time: 09:00-12:00

Detaljer

Eksamen INF1050: Gjennomgang, uke 15

Eksamen INF1050: Gjennomgang, uke 15 Eksamen 2012 INF1050: Gjennomgang, uke 15 Overblikk Varierte spørsmål fra pensum Modellering Use case Tekstlig beskrivelse Sekvensdiagram Klassediagram Krav Empiriske metoder Smidig metodikk Varierte spørsmål

Detaljer

GJENNOMGANG UKESOPPGAVER 2 PROSESSMODELLER OG SMIDIG PROGRAMVAREUTVIKLIG

GJENNOMGANG UKESOPPGAVER 2 PROSESSMODELLER OG SMIDIG PROGRAMVAREUTVIKLIG GJENNOMGANG UKESOPPGAVER 2 PROSESSMODELLER OG SMIDIG PROGRAMVAREUTVIKLIG INF1050 V16 HVA ER EN SYSTEMUTVIKLINGSPROSESS? De aktivitetene som utføres for å utvikle et IT-system Eksempler på aktiviteter:

Detaljer

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

UKE 13 Mer UML modellering. Gruppetime INF1055 Julie Hagen Nilsen & Maria Stolinski UKE 13 Mer UML modellering Gruppetime INF1055 Julie Hagen Nilsen & Maria Stolinski Hva skal vi i dag? Objektorientert design - kapittel 5 og 7 UML modellering Aktivitetsdiagrammer Klassediagram Ukesoppgaver

Detaljer

GJENNOMGANG UKESOPPGAVER 9 TESTING

GJENNOMGANG UKESOPPGAVER 9 TESTING GJENNOMGANG UKESOPPGAVER 9 TESTING INF1050 V16 KRISTIN BRÆNDEN 1 A) Testing viser feil som du oppdager under kjøring av testen. Forklar hvorfor testing ikke kan vise at det ikke er flere gjenstående feil.

Detaljer

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

Obligatorisk oppgave 1 INF1050 Foranalyse og kravhåndtering. av Andreas Johansen Alexander Storheill Martin Dørum Nygaard Tobias Langø Aasmoe Obligatorisk oppgave 1 INF1050 Foranalyse og kravhåndtering av Andreas Johansen Alexander Storheill Martin Dørum Nygaard Tobias Langø Aasmoe Oppgave 1: Bakgrunn for systemet a) Fordeler ved å integrere

Detaljer

Livsløpstesting av IT-systemer

Livsløpstesting av IT-systemer Livsløpstesting av IT-systemer Testing, validering og evaluering Teste Undersøke ved hjelp av tester om systemet fungerer slik det er beskrevet Validere Bekrefte hvordan systemet virkelig fungerer, om

Detaljer

Obligatorisk oppgave 3. INF1050: Gjennomgang, uke 16

Obligatorisk oppgave 3. INF1050: Gjennomgang, uke 16 Obligatorisk oppgave 3 INF1050: Gjennomgang, uke 16 Pensum for oppgaven Estimering Arkitektur 4+1 view-modellen og lagdeling Arkitektoniske stiler UML-modellering Tilstands- og aktivitetsdiagrammer Testing

Detaljer

Eksamen INF

Eksamen INF Eksamen INF5120 06.06.2005 Et løsningsforslag Oppgave 1 a) Business Model Oppgaven spør om en business model for samhandlingen mellom Buyer og Seller, og det er da viktig å ikke modellere alt det andre!!!

Detaljer

Prosessmodeller og smidig programvareutvikling. INF1050: Gjennomgang, uke 02

Prosessmodeller og smidig programvareutvikling. INF1050: Gjennomgang, uke 02 Prosessmodeller og smidig programvareutvikling INF1050: Gjennomgang, uke 02 Kompetansemål Prosessmodeller Kunne redegjøre for hva som kjennetegner ulike prosessmodeller Vurdere prosesser for utvikling

Detaljer

Kontrakter. INF1050: Gjennomgang, uke 12

Kontrakter. INF1050: Gjennomgang, uke 12 Kontrakter INF1050: Gjennomgang, uke 12 Kompetansemål Kontrakter I plandrevet utvikling I smidig utvikling Behov for smidige kontrakter Kontraktsmodeller PS2000 Del I: Kontrakter Grunnleggende: Hva? Plandrevet

Detaljer

UML-Unified Modeling Language

UML-Unified Modeling Language UML-Unified Modeling Language Use case realisering Designmodellering 21.01.2004 Kirsten Ribu Use Case diagram Klassediagram Oppførselsdiagrammer: Sekvensdiagram Kollaborasjonsdiagram Tilstandsdiagram Aktivitetsdiagram

Detaljer

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

Systemutvikling - oppsummering. Alexander Nossum blog.eksplisitt.net 22. mai 2006 Systemutvikling - oppsummering Alexander Nossum alexander@nossum.net blog.eksplisitt.net 22. mai 2006 INNHOLD 2 Innhold 1 Utviklingsprosessmodeller 3 1.1 Fossefall/waterfall................................

Detaljer

Use case modellen. Use case modellering i analysefasen. Hva er en Aktør? Hva er et Use case? Use case modellering. Eksempel

Use case modellen. Use case modellering i analysefasen. Hva er en Aktør? Hva er et Use case? Use case modellering. Eksempel Use case modellen Use case modellering i analysefasen Metode for å identifisere og beskrive de funksjonelle kravene til et system Kapittel 3 i UML Distilled Kirsten Ribu beskriver kravene til systemet,

Detaljer

Løsningsforslag til Case. (Analysen)

Løsningsforslag til Case. (Analysen) Løsningsforslag til Case (Analysen) Dette er en skisse til løsning av Case et med bussinformasjonssystemet. Jeg kaller det en skisse fordi det på den ene siden ikke er noe fasitsvar og fordi løsningen

Detaljer

Konfigurasjonsstyring

Konfigurasjonsstyring INF1050: Systemutvikling 28. mars 2017 Konfigurasjonsstyring Yngve Lindsjørn ynglin@ifi.uio.no INF1050 Systemutvikling ->Konfigurasjonsstyring 1 Temaer i dagens forelesning Versjonshåndtering Systembygging

Detaljer

Kravspesifikasjon med. UML diagrammer. systemutvikling. Dokumentasjon av systemets krav, arkitektur, design og implementasjon

Kravspesifikasjon med. UML diagrammer. systemutvikling. Dokumentasjon av systemets krav, arkitektur, design og implementasjon Kravspesifikasjon med UML use case modellering Erik Arisholm 01.03.2010 Unified Modeling Language (UML) Notasjon som støtter opp under modellbasert systemutvikling objektorientert analyse ( hva systemet

Detaljer

Prosjektledelse, prosjektplanlegging, teamarbeid

Prosjektledelse, prosjektplanlegging, teamarbeid SKK modul B 03. Mai 2017 Prosjektledelse, prosjektplanlegging, teamarbeid Yngve Lindsjørn ynglin@ifi.uio.no INF1055 > SKK -> Prosjektledelse og teamarbeid 1 Temaer i dagens forelesning Prosjektstyring/Prosjektledelse

Detaljer

Kravspesifikasjon med. Erik Arisholm

Kravspesifikasjon med. Erik Arisholm Kravspesifikasjon med UML use case modellering Erik Arisholm 01.03.2010 Unified Modeling Language (UML) Notasjon som støtter opp under modellbasert systemutvikling objektorientert analyse ( hva systemet

Detaljer

Unified Modeling Language (UML) Kravspesifikasjon med UML use case modellering. UML diagrammer. Notasjon som støtter opp under modellbasert

Unified Modeling Language (UML) Kravspesifikasjon med UML use case modellering. UML diagrammer. Notasjon som støtter opp under modellbasert Kravspesifikasjon med UML use case modellering Erik Arisholm 25.02.2009 Unified Modeling Language (UML) Notasjon som støtter opp under modellbasert systemutvikling objektorientert analyse ( hva systemet

Detaljer

Prosjektledelse, planlegging og teamarbeid. INF1050: Gjennomgang, uke 10

Prosjektledelse, planlegging og teamarbeid. INF1050: Gjennomgang, uke 10 Prosjektledelse, planlegging og teamarbeid INF1050: Gjennomgang, uke 10 Kompetansemål Prosjektstyring og prosjektledelse Hva og hvorfor? Risikohåndtering Ledelse av mennesker og motivasjon Teamarbeid og

Detaljer

Use case modellen. Use case modellering i analysefasen. Hva er en Aktør? Hva er et Use case?

Use case modellen. Use case modellering i analysefasen. Hva er en Aktør? Hva er et Use case? 1/15/2004 1 Use case modellen Use case modellering i analysefasen Metode for å identifisere og beskrive de funksjonelle kravene til et system Kapittel 3 i UML Distilled Kapittel 8 i Gurholt og Hasle Kirsten

Detaljer

Ulike typer prosessmodeller. Systemutvikling. Utviklingsmodeller. Prosessmodell - faser

Ulike typer prosessmodeller. Systemutvikling. Utviklingsmodeller. Prosessmodell - faser 1 Ulike typer prosessmodeller Systemutvikling Oppsummering av hovedområdene i kurset LO 135A Kirsten Ribu 19.05.2004 De røde er viktige i kurset: Evolusjonær (prototyping) Inkrementell (RUP) XP fossefall

Detaljer

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

Gruppenavn. Prosjektnavn Beskrivelse av design For Navn på systemet. Versjon <1.0> Gruppenavn Prosjektnavn Beskrivelse av design For Navn på systemet Versjon Revisjonshistorie Dato Versjon Beskrivelse av endring Forfatter Innhold 1. Innledning

Detaljer

Inf1055 Modul B 26 april 2017:

Inf1055 Modul B 26 april 2017: Inf1055 Modul B 26 april 2017: Del 1: - Testing Yngve Lindsjørn ynglin@ifi.uio.no 1 Oversikt - Testing Hva er testing? Validering &Verifisering Testfaser Enhetstesting Integrasjonstesting Systemtesting

Detaljer

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

Oppsummering : IMT2243 Systemutvikling. Hensikt med kurset. Innfallsvinkel : Tom Røise 29.04.2009. IMT2243 : Systemutvikling 1 Oppsummering : IMT2243 Systemutvikling Målformuleringen i emnebeskrivelsens : Studentene skal ha forståelse for grunnleggende administrative og teknologiske aspekter ved spesifisering, utvikling, innføring

Detaljer

Systemarkitektur. INF1050: Gjennomgang, uke 07

Systemarkitektur. INF1050: Gjennomgang, uke 07 Systemarkitektur INF1050: Gjennomgang, uke 07 Kompetansemål Systemarkitektur Hva og hvorfor? Arkitektoniske modeller Kjennetegn Fordeler og ulemper Arkitektoniske stiler Ulike typer: Pipe-and-Filter /

Detaljer

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

UML-Unified Modeling Language. Prosess-oversikt. Use case realisering Use case realisering Designmodellering 31.01.2005 Kirsten Ribu UML-Unified Modeling Language Use Case diagram Klassediagram Oppførselsdiagrammer Sekvensdiagram Kollaborasjonsdiagram Tilstandsdiagram Aktivitetsdiagram

Detaljer

UKE 10 Kravhåndtering. Gruppetime INF1055

UKE 10 Kravhåndtering. Gruppetime INF1055 UKE 10 Kravhåndtering Gruppetime INF1055 Hva skal vi i dag? Kravhåndtering - kapittel 4 Ukesoppgaver: Smidig programvareutvikling og kravhåndtering Krav KRAV KOMPETANSEMÅL: Kravhåndtering: anvende metoder

Detaljer

Systemutvikling (Software Engineering) Professor Alf Inge Wang

Systemutvikling (Software Engineering) Professor Alf Inge Wang 1 Systemutvikling (Software Engineering) Professor Alf Inge Wang 2 Undervisningsmål og henvisning Målet med timen er: Få kunnskap om hva systemutvikling er Forstå hva en utviklingsprosess består av Få

Detaljer

Fra krav til modellering av objekter

Fra krav til modellering av objekter INF1050: Systemutvikling 14. februar 2017 Fra krav til modellering av objekter Førstelektor Yngve Lindsjørn INF1050 -> Systemutvikling -> Fra krav til modellering av objekter 1 Temaer i dagens forelesning

Detaljer

Oppsummering av hovedområdene i kurset LO 135A Kirsten Ribu

Oppsummering av hovedområdene i kurset LO 135A Kirsten Ribu Systemutvikling Oppsummering av hovedområdene i kurset LO 135A Kirsten Ribu 19.05.2004 1 Ulike typer prosessmodeller De røde er viktige i kurset: Evolusjonær (prototyping) Inkrementell (RUP) XP fossefall

Detaljer

UKE 15 Prosjektledelse, planlegging og teamarbeid. Gruppetime INF1055 Julie Hagen Nilsen & Maria Stolinski

UKE 15 Prosjektledelse, planlegging og teamarbeid. Gruppetime INF1055 Julie Hagen Nilsen & Maria Stolinski UKE 15 Prosjektledelse, planlegging og teamarbeid Gruppetime INF1055 Julie Hagen Nilsen & Maria Stolinski Hva skal vi i dag? Se på oblig 5 Prosjektledelse og teamarbeid (kap. 22) Prosjektplanlegging og

Detaljer

Spesifikasjon av Lag emne

Spesifikasjon av Lag emne Dagens forelesning o Kort repetisjon av kravspesifikasjon med UML Fra krav til objekter Hva skal systemet gjøre? UML: Bruksmønstermodeller (Use Cases) o Objektdesign Ansvarsdrevet OO: CRC og UML Sekvensdiagrammer

Detaljer

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

Hensikten med denne delen av kurset. Objektorientering hva er det? Objektets egenskaper. Best practises ved programvareutvikling Objektorientert systemutvikling, litt UML og Rational Unified Process (RUP) UML Distilled kap. 2 Hensikten med denne delen av kurset Å lære og øve på modelleringsteknikker Å lære om gode designprinsipper

Detaljer

Use case drevet design med UML

Use case drevet design med UML Use case drevet design med UML Bente Anda 26.09.2005 23.09.04 INF3120 1 I dag Domenemodeller System sekvensdiagrammer Operasjonskontrakter GRASP patterns Designmodeller med sekvens- og klassediagram 26.09.05

Detaljer

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

Lykke til! Eksamen i fag TDT4140 Systemutvikling 28.11.2012 9.00. NTNU Norges teknisk-naturvitenskapelige universitet Side 1 av 10 NTNU Norges teknisk-naturvitenskapelige universitet BOKMÅL Fakultet for informasjonsteknologi, matematikk og elektroteknikk Institutt for datateknikk og informasjonsvitenskap Sensurfrist:

Detaljer

Forskningsmetoder. INF1050: Gjennomgang, uke 13

Forskningsmetoder. INF1050: Gjennomgang, uke 13 Forskningsmetoder INF1050: Gjennomgang, uke 13 Kompetansemål Forskningsmetoder Hva? Hvorfor? Empiriske forskningsmetoder Eksperiment Case-studier Etnografi Aksjonsforskning Spørreskjema Systematisk litteraturstudie

Detaljer

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

UML- Use case drevet analyse og design. Domenemodeller Sekvensdiagrammer Use case realisering med GRASP patterns Klassediagram - designmodeller UML- Use case drevet analyse og design Bente Anda 23.09.2004 23.09.04 INF320 I dag Domenemodeller Sekvensdiagrammer Use case realisering med GRASP patterns Klassediagram - designmodeller 23.09.04 INF320

Detaljer

Eksamen 2012 INF1050 Lars- Martin Hejll Universitetet i OSLO

Eksamen 2012 INF1050 Lars- Martin Hejll Universitetet i OSLO Eksamen 2012 INF1050 Lars- Martin Hejll Universitetet i OSLO Høgskolen i Telemark 2 Lars- Martin Hejll Høgskolen I Telemark Oppgave 1 Spørsmål fra pensum (20%) 1. Nødvendige aktiviteter i systemutvikling:

Detaljer

Ansvarsdrevet OO: CRC og UML Sekvensdiagrammer

Ansvarsdrevet OO: CRC og UML Sekvensdiagrammer Fra krav til objekter Ansvarsdrevet OO: CRC og UML Sekvensdiagrammer INF1050--1 Dagens forelesning o Kort repetisjon av kravspesifikasjon med UML Hva skal systemet gjøre? UML: Bruksmønstermodeller (Use

Detaljer

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

Eksamen i fag SIF8018 Systemutvikling. Fredag 25. mai 2001 kl Side av 9 NTNU Norges teknisk-naturvitenskapelige universitet BMÅL Fakultet for fysikk, informatikk og matematikk Institutt for datateknikk og informasjonsvitenskap Sensurfrist:. juni Eksamen i fag SIF808

Detaljer

DRI 2001 Systemutviklingsarbeidet et overblikk Forelesning

DRI 2001 Systemutviklingsarbeidet et overblikk Forelesning Systemutviklingsarbeidet et overblikk DRI2001 forelesning 21. sept. 05 Informasjonssystem og datasystem Hva er systemutvikling (SU) Et enkelt eksempel å bygge et hus Rammer og perspektiver for SU-arbeidet

Detaljer

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

Lykke til! Eksamen i fag SIF8018 Systemutvikling. 20 mai, 2003 kl 0900-1400. Fakultet for fysikk, informatikk og matematikk NTNU Norges teknisk-naturvitenskapelige universitet BOKMÅL Fakultet for fysikk, informatikk og matematikk Institutt for datateknikk og informasjonsvitenskap Sensurfrist: XX Eksamen i fag SIF8018 Systemutvikling

Detaljer

Mer om objektorientering og UML

Mer om objektorientering og UML INF1050: Systemutvikling 21. februar 2017 Mer om objektorientering og UML Universitetslektor Yngve Lindsjørn INF1050 > Systemutvikling->objektorientert modellering 1 Temaer i dagens forelesning Ø Objektorientert

Detaljer

Testing av programvare. INF1050: Gjennomgang, uke 08

Testing av programvare. INF1050: Gjennomgang, uke 08 Testing av programvare INF1050: Gjennomgang, uke 08 Kompetansemål Testing av programvare Hva og hvorfor? Testfaser Ulike nivåer Testtyper Spesifikasjonsbasert testing / Strukturbasert testing Testdrevet

Detaljer

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

Gjennomgang av prøveeksamen. Gruppetime INF1055 Julie Hagen Nilsen & Maria Stolinski Gjennomgang av prøveeksamen Gruppetime INF1055 Julie Hagen Nilsen & Maria Stolinski OPPGAVE 1: MUlTIPLE CHOICE SPØRSMÅL 1.1 Hva er et funksjonelt krav? a) Teksten på skjermen skal være svart med hvit bakgrunn.

Detaljer

DRI2001 Offentlige nettsteder. Litt om systemutvikling Torsdag 24 aug Arild Jansen, AFIN, UiO

DRI2001 Offentlige nettsteder. Litt om systemutvikling Torsdag 24 aug Arild Jansen, AFIN, UiO DRI 2001 13.9 : Introduksjon til systemutvikling. Introduksjon til systemutvikling Systemutvikling og nettstedsutvikling Om ulike typer offentlige nettsteder Kvalitetskrav til offentlige nettsteder Litt

Detaljer

Obligatorisk oppgave 1: Foranalyse og Kravhåndtering Lars- Martin Hejll 5611 Systemutvikling

Obligatorisk oppgave 1: Foranalyse og Kravhåndtering Lars- Martin Hejll 5611 Systemutvikling Obligatorisk oppgave 1: Foranalyse og Kravhåndtering LarsMartin Hejll 5611 Systemutvikling Høgskolen i Telemark Oppgave 1: Bakgrunn for systemet LarsMartin Hejll A) Ved å sentralisere bookingsystemet til

Detaljer

GJENNOMGANG UKESOPPGAVER 6 MER OM OBJEKTORIENTERING OG UML

GJENNOMGANG UKESOPPGAVER 6 MER OM OBJEKTORIENTERING OG UML GJENNOMGANG UKESOPPGAVER 6 MER OM OBJEKTORIENTERING OG UML INF1050 V16 KRISTIN BRÆNDEN DAGENS TEMA Klassediagram Aktivitetsdiagram Tilstandsdiagram Sekvensdiagram 1 Ta utgangspunkt i følgende klasser:

Detaljer

Hva gjøres i design? 19. september 2002, Tore Berg Hansen, TISIP

Hva gjøres i design? 19. september 2002, Tore Berg Hansen, TISIP Hva gjøres i design? 19. september 2002, Tore Berg Hansen, TISIP Kursleksjonene er forfatters eiendom. Som kursdeltaker kan du fritt bruke leksjonene til eget personlig bruk. Kursdeltakere som ønsker å

Detaljer

UML 1. Use case drevet analyse og design. 20.01.2004 Kirsten Ribu

UML 1. Use case drevet analyse og design. 20.01.2004 Kirsten Ribu UML 1 Use case drevet analyse og design 20.01.2004 Kirsten Ribu 1 I dag Domenemodell (forløper til klassediagram) Interaksjonsdiagrammer Sekvensdiagram Kollaborasjonsdiagram 2 Domenemodell visualisering

Detaljer

Prosjektledelse, prosjektplanlegging, teamarbeid

Prosjektledelse, prosjektplanlegging, teamarbeid INF1050: Systemutvikling 21. mars 2017 Prosjektledelse, prosjektplanlegging, teamarbeid Yngve Lindsjørn ynglin@ifi.uio.no INF1050 Systemutvikling ->Prosjektledelse og teamarbeid 1 Temaer i dagens forelesning

Detaljer

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

t Institutt for informatikk Erik Arisholm 13. mai 2009 INF1050-oppsummering-1 Oppsummering INF1050 Systemutvikling t INF1050-oppsummering-1 INF1050 dagsorden Erfaringer fra V09 Kort oppsummering: Hvordan utvikles et informasjonssystem? Kanskje noen eksamenstips, og litt teknikk

Detaljer

Prosjektledelse, prosjektplanlegging, teamarbeid

Prosjektledelse, prosjektplanlegging, teamarbeid INF1050: Systemutvikling 25. mars 2015 Prosjektledelse, prosjektplanlegging, teamarbeid Universitetslektor Yngve Lindsjørn INF1050 Systemutvikling ->Prosjektledelse og teamarbeid 1 Temaer i dagens forelesning

Detaljer

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

I dag UML. Domenemodell visualisering av konsepter. Eksempel. Hvordan finne domeneklasser? UML Use case drevet analyse og design 31.01.2005 Kirsten Ribu I dag Domenemodell (forløper til klassediagram) Interaksjonsdiagrammer Sekvensdiagram Kollaborasjonsdiagram 1 2 Domenemodell visualisering

Detaljer

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

Del - leveranse Del 2. Inf 2120 fredag Gruppe 1 Knut Johannes Dahle Del - leveranse Del 2 Inf 2120 fredag 29.4 Gruppe 1 Knut Johannes Dahle AV Catrine Myhre (catrinem@ifi.uio.no) Mehdi Zare (mehdiz@ifi.uio.no) Odd Christer Brovig (oddcb@ifi.uio.no) Christer Aas (chrisva@ifi.uio.no)

Detaljer

Statusrapport. MUSIT Ny IT-arkitektur Pilot. NØKKELINFORMASJON Rapporteringstidspunkt 6. juli 2016 Rapporteringsperiode Juni 2016

Statusrapport. MUSIT Ny IT-arkitektur Pilot. NØKKELINFORMASJON Rapporteringstidspunkt 6. juli 2016 Rapporteringsperiode Juni 2016 Statusrapport MUSIT Ny IT-arkitektur Pilot NØKKELINFORMASJON Rapporteringstidspunkt 6. juli 2016 Rapporteringsperiode Juni 2016 Prosjektleder Line Arild Sjo Prosjekteier Leder MUSIT styre Prosjektnummer

Detaljer

Kap. 2 Prosessen. Utviklingsmodeller -2. Utviklingsmodeller. Utviklingsmodeller -4. Utviklingsmodeller - 3. Software Engineering - definisjoner

Kap. 2 Prosessen. Utviklingsmodeller -2. Utviklingsmodeller. Utviklingsmodeller -4. Utviklingsmodeller - 3. Software Engineering - definisjoner Software Engineering - definisjoner Kap. 2 Prosessen Utviklingsprosessen Modeller for utvikling Bauer: Etablering og bruk av gode ingeniørmessige prinsipper for å fremskaffe økonomisk programvare som er

Detaljer

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

Gruppenavn. Beskrivelse av arkitektur For Navn på systemet. Versjon <1.0> Gruppenavn Beskrivelse av arkitektur For Navn på systemet Versjon Revisjonshistorie Dato Versjon Beskrivelse av endring Forfatter Innhold 1. Innledning 4 1.1

Detaljer

Innhold. Innledning... 15. Del 1 En vei mot målet

Innhold. Innledning... 15. Del 1 En vei mot målet Innledning.............................................. 15 Del 1 En vei mot målet Kapittel 1 Utviklingsarbeidet.............................. 22 1.1 Systemutviklerens arbeid...............................

Detaljer

Systemutviklingen er ferdig når et system er operativt. Med operativt menes når systemet blir brukt av brukerne på et faktisk arbeidssted.

Systemutviklingen er ferdig når et system er operativt. Med operativt menes når systemet blir brukt av brukerne på et faktisk arbeidssted. Presentasjon nummer 5 The changing system and the nature of maintenance Silde 1 Gruppen introduseres Slide 2 The changing system and the nature of maintenance The Changing system Systemutviklingen er ferdig

Detaljer

Universitetet i Bergen Det matematisk-naturvitenskapelige fakultet Institutt for informatikk

Universitetet i Bergen Det matematisk-naturvitenskapelige fakultet Institutt for informatikk Universitetet i Bergen Det matematisk-naturvitenskapelige fakultet Institutt for informatikk BOKMÅL EKSAMEN I EMNET INF 112 Systemkonstruksjon Torsdag 7. juni 2007 Tid: 09:00 12:00 Tillatte hjelpemidler:

Detaljer

Kravspesifiseringsprosessen

Kravspesifiseringsprosessen IMT2243: 18.februar 2010 DAGENS : Metoder for å få kartlagt de Funksjonelle kravene Strukturert Analyse den gamle måten og gjøre det på (dette foilsettet + wikipedia-omtalen er eneste pensum innen SA)

Detaljer

MARE NOSTRUM. Del 2 Kravspesifikasjon

MARE NOSTRUM. Del 2 Kravspesifikasjon MARE NOSTRUM Del 2 Forord Kravenes hensikt og utforming Kravene i kravspesifikasjonen utformet slik at de skal imøtekomme oppdragsgivers krav, ønsker og spesifikasjoner på best mulig måte. Hensikten med

Detaljer

Gruppenavn. Prosjektnavn Kravdokument For Navn på systemet. Versjon <1.0>

Gruppenavn. Prosjektnavn Kravdokument For Navn på systemet. Versjon <1.0> Gruppenavn Prosjektnavn Kravdokument For Navn på systemet Versjon Revisjonshistorie Dato Versjon Beskrivelse av endring Forfatter Innhold 1. Innledning 4 1.1

Detaljer

Institutt for Informatikk, 24. august 2012

Institutt for Informatikk, 24. august 2012 INF5700 - Organisering og ledelse av tekniske prosjekter Institutt for Informatikk, 24. august 2012 joshi@ifi.uio.no Oversikt Del 1: Overgangen Utfordringer En ny verden nye måter å jobbe på Å tenke Del

Detaljer

GJENNOMGANG UKESOPPGAVER 3 KRAVHÅNDTERING

GJENNOMGANG UKESOPPGAVER 3 KRAVHÅNDTERING GJENNOMGANG UKESOPPGAVER 3 KRAVHÅNDTERING INF1050 V16 HVA ER KRAVHÅNDTERING? Kravhåndtering er prosessen å identifisere, analysere og spesifisere kravene til et nytt system eller et system som skal forbedres

Detaljer

Kapittel 5 - Advanced Hypertext Model Kapittel 6 - Overview of the WebML Development Process

Kapittel 5 - Advanced Hypertext Model Kapittel 6 - Overview of the WebML Development Process INF 329 Web-teknologier Kapittel 5 - Advanced Hypertext Model Kapittel 6 - Overview of the WebML Development Process Navn: Bjørnar Pettersen bjornarp.ii.uib.no Daniel Lundekvam daniell.ii.uib.no Presentasjonsdato:

Detaljer

UNIVERSITETET I OSLO

UNIVERSITETET I OSLO UNIVERSITETET I OSLO Det matematisk-naturvitenskapelige fakultet Eksamen i : IN219 (IN218) Store programsystemer Eksamensdag : Lørdag 12. desember 1998 Tid for eksamen : 09.00 15.00 Oppgavesettet er på

Detaljer

Validering og verifisering. Kirsten Ribu

Validering og verifisering. Kirsten Ribu Validering og verifisering Kirsten Ribu 2005 1 I dag Validering og verifisering Inspeksjon Testing 2 Noen ord om prosjektet Sjekk kurssidene jevnlig. Endringer forekommer (forelesningsplanen) Hvordan fungerer

Detaljer

Oppgraderinger i SAP. Planlegge, organisere og gjennomføre en oppgradering til ECC 5.0/ECC 6.0. Sveinung Gehrken

Oppgraderinger i SAP. Planlegge, organisere og gjennomføre en oppgradering til ECC 5.0/ECC 6.0. Sveinung Gehrken Oppgraderinger i SAP Planlegge, organisere og gjennomføre en oppgradering til ECC 5.0/ECC 6.0. Sveinung Gehrken Gehrken Systems Agenda Vurdere 1 2 oppgradering 4 Erfaringer og hjelpemidler Planlegge oppgradering

Detaljer

Produktrapport Gruppe 9

Produktrapport Gruppe 9 Forord Dette dokumentet er ment for personer som skal vedlikeholde, endre eller utvikle systemet. Produktdokument innholder informasjoner om programmets funksjoner og hvordan de fungerer. Før bruk av dette

Detaljer