Modellering IT konferanse
|
|
- Grete Rød
- 5 år siden
- Visninger:
Transkript
1 Modellering IT konferanse 1. Interessenter Utviklere som besøker konferansen: besøke IT konferanse Frivillige hjelpere: få gratis inngang på konferansen Ledelse: Tjene penger Matkjeder: Selge mat og drikke, tjene penger Utviklere som utvikler systemet: tjene penger, få godt rykte Foredragsholdere på konferansen: dele kunnskap om det de kan, få godt rykte Myndigheter, DIFI, datatilsyn: Sikkerhet, personvern, universell utforming
2 Modellering IT konferanse 2. Use Case diagram Primære aktører: utvikler (besøkende av konferanse), frivillig hjelper, ledelse Sekundære aktører: betalingsmodul, administrasjonsmodul
3 Modellering IT konferanse 3. Brukerhistorier Som utvikler ønsker jeg å kjøpe billetter til IT konferanse for å lære meg mer om systemutvikling Som en i ledelsen av IT konferansen ønsker jeg å se hvor mange som har kjøpt billetter for å kartlegge om denne konferansen er av interesse for utviklere Som frivillig hjelper ønsker jeg å sende inn søknad for å komme inn på konferansen gratis Som en i ledelsen ønsker jeg å kunne godkjenne hvem som får lov til å være frivillig hjelper for å sikre god service under konferansen -Som utvikler ønsker jeg å kunne velge hvilken dag av konferansen jeg skal kjøpe billetter for for å kun få med meg de foredragene jeg ønsker
4 Modellering IT konferanse 4. Sekvensdiagram Antagelse: Det er ikke begrenset antall billetter som kan selges (dvs. når brukeren har lyst til å kjøpe en billett vil det alltid være en ledig billett for den/de dagene)
5 Modellering IT konferanse 5. Klassediagram Antagelser: En person kan bare ha en billett fordi jeg antar at en og samme billett kan være billett for en, to eller alle dagene. Klassen Frivillig som er subklassen til Person kan ha flere attributter (variabler) avhengig av hvilke opplysninger som skal legges inn.
6 Oppgave 12 Spørsmål (maks 5 poeng pr spørsmål) 1. Forklar arkitekturen bak MVP (Model View Presenter) og redegjør for hvordan dere brukte det i prosjektet?
7 MVP (Model View Presenter) er et arkitekturmønster som er anbefalt for utvikling av native Android applikasjoner. Denne arkitekturen tilrettelegger for en lagdeling som blant annet gjør det enklere å teste og videreutvikle applikasjonen. - Model har ansvaret for hvordan dataene blir lagret og behandlet - View viser passivt dataene og tar i mot hendelser fra bruker (f.eks. klikk eller scrolling) - Presenter har ansvar for å tolke hendelser fra bruker som View-et får i tillegg til å avgjøre hvilke data som trengs og hvordan det skal vises fram. I applikasjonen vår er denne arkitekturen ivaretatt på følgende måte: - Vi har en Backend klasse som får melding fra presentere til de ulike sidene om hvilke data som skal hentes. Backend gjør et metodekall til HTTPMethod-klassen som i sin tur avgjør om dataene ligger i cachen (lagret fra før) eller må hentes fra databasen med et API-kall. Hvis dataene skal hentes fra cache ligger all nødvendig informasjon lagret i objektene som Movie, Person eller Genre. Dette er Model-laget. - Hver side i applikasjonen består av en kontraktklasse som definerer tre interfaces (View, Presenter og Backend) som de ulike delene må implementere, en Fragmentklasse og en Presenterklasse. Fragmentklassen utgjør viewet og har dermed ansvaret for å vise fram dataene og ta i mot hendelser fra bruker. Presenterklassen inneholder i sin tur metoder som er relatert til tolkning av hendelser fra bruker og sending av meldinger til Backend, dvs. avgjøre hvilke data som skal hentes.
8 Oppgave 12 Spørsmål (maks 5 poeng pr spørsmål) 2. Forklar prinsippene høy kohesjon og lav kobling. Forklar med eksempler hvordan dere brukte dette i prosjektet?
9 Kohesjon er et mål på hvor mye ansvar et objekt har og hvor fokusert dette ansvaret er. Objekter med høy kohesjon har et moderat ansvar og et begrenset mengde oppgaver den kan utføre. Kobling er et mål på hvor avhengig et objekt er av andre klasser og objekter. Objekter med lav kobling har få avhengigheter. På denne måten blir det enklere å erstatte et objekt med et annet, noe som gjør vedlikehold og videreutvikling lettere. I prosjektet vårt har vi fra utviklernes perspektiv fokusert på at applikasjonen skal være lett å teste og videreutvikle. Derfor har vi laget klasser som har ansvar for en bestemt oppgave i stedet for å ha klasser som har ansvar for mye forskjellig funksjonalitet i applikasjonen. Eksempel på dette kan være at funksjonaliteten til de ulike sidene ("de mest populære"-siden, "filmdetaljer"- siden, "persondetaljer"-siden) er fordelt på forskjellige klasser og hver klasse har kun metoder som tilhører en bestemt side. På denne måten sikrer vi høy kohesjon til objektene våre. Prinsippet om lav kobling er ivaretatt i applikasjonen vår blant annet gjennom lagdelingen som ble beskrevet i oppgave 12.1 for eksempel ved at View-klassene ikke er direkte koblet til Model-klassene, men all kommunikasjon foregår gjennom Presenter. Slik vil det være enklere å skifte ut modellene ved eventuell videreutvikling av applikasjonen.
10 Oppgave 12 Spørsmål (maks 5 poeng pr spørsmål) 3. I hvilken grad har programvaren deres i appen fått teknisk gjeld, og hva har har dere gjort for å begrense denne gjelden?
11 Teknisk gjeld innebærer alle suboptimale løsninger gjort under utvikling som fører til lav kodekvalitet og dermed økte kostnader for vedlikehold og videreutvikling av applikasjonen. I prosjektet vårt opplevde vi teknisk gjeld som følge av lite førarbeid knyttet til etablering av en mer detaljert arkitekturdesign. Vi hadde blitt enige om en overordnet arkitektur og hadde MVP-mønstret i bakhodet, men implementerte det ikke slik vi burde fra starten av. Dette førte til at appen ble vanskelig å teste og i det lange løp kunne føre til at det ble vanskeligere og vanskeligere å legge til funksjonalitet. Når vi ser tilbake på prosjektet vårt, kan vi si at ekstra tid brukt på å tilegne se. kunnskaper om arkitekturmønstre før utviklingsfasen kunne vært en god løsning for å hindre at teknisk gjeld oppstod. Vi kan derfor si at mangel på kunnskap var en av grunnene til at den tekniske gjelden oppstod. I tillegg var tidspress en faktor som vi måtte ta hensyn til og som kanskje førte til at vi implementerte suboptimale løsninger først. Når vi først hadde opparbeidet oss en teknisk gjeld ønsket vi å synliggjøre at vi hadde fått en teknisk gjeld. Vi la inn en issue på Kanban-boardet vårt slik at denne oppgaven kunne bli prioritert i en av sprintene. En av sprintene våre gikk altså ut på å gjennomføre en omfattende refaktorering som hjalp oss å kvitte oss med gjelden knyttet til dårlig arkitektur. Vi var også nøye med å teste applikasjonen statisk, altså se etter potensielle forbedringer i koden for å hindre at vi opparbeidet oss enda mer teknisk gjeld. Til dette fikk vi hjelp av vektøy i AndroidStudio (InteliJ) som pekte på steder der vi hadde dårlig kodeskikk eller små feil som for eksempel ubrukte variabler.
12 Oppgave 12 Spørsmål (maks 5 poeng pr spørsmål) 4. Beskriv de fire testnivåer som er sentrale i systemutvikling? For hvert testnivå, nevn minst ett eksempel fra prosjektet deres som dere har testet/ evt. kunne hatt testet.
13 De fire mest sentrale testnivåene i systemutvikling er enhetstesting, integrasjonstesting, systemtesting og brukertesting (akseptansetesting). Enhetstesting går ut på å teste de enkelte komponentene hver for seg. I prosjektet har vi hatt mye fokus på dette testnivået der vi testet at klassene fungerer slik de skulle. I og med at vi ikke hadde et eget testteam ble testing gjennomført av utviklerne innad i teamet og white-box testing ble brukt som metode fordi vi kjente godt til koden og kunne raskt avdekke hvilken del av kode som førte til feil i testene. For å gjennomføre enhetstesting brukte vi verktøy som JUnit for å automatisere testene, Mockito som lar oss lage testobjekter av klasser som klassen vi tester er avhengig av og Roboelectric som lar oss enklere teste klasser som er avhengige av mange bibliotekklasser. Integrasjonstesting innebærer testing av hvordan de ulike komponentene samhandler og kommuniserer med hverandre. Vi hadde litt mindre fokus på dette testnivået enn på enhetstesting i prosjektet vårt da vi ønsket å forsikre oss om at klassene fungerer som de skal hver for seg før vi testet samhandling mellom de ulike klassene, men vi gjennomførte også noe integrasjonstesting ved å blant annet bruke de samme verktøyene som beskrevet under enhetstesting for å teste kommunikasjonen mellom klassene. Systemtesting går ut på å teste programvaren som en helhet. I prosjketet vårt testet vi applikasjonen vi hadde laget ved å blant annet bruke spesifikasjonsbasert testeteknikk som kalles use-case testing. Vi tok altså utgangspunkt i hvilke use-case systemet skulle implementere og testet at disse use-casene ble utført feilfritt. Brukertesting (akseptansetesting) gjennomføres av kunden/brukere til applikasjonen med mål om å forsikre seg om at applikasjonen tilfredsstiller kundenes ønsker og forventninger og funksjonene fungerer slik de skal. Brukertesting ble gjennomført jevnlig gjennom hele prosjektet som en del av designiterasjoner vi hadde. Teknikkene som ble brukt under brukertesting er observasjoner av hvordan brukerne brukte applikasjonen, samt uformelle intervjuer der brukerne ga tilbakemeldinger både på design av applikasjonen og eventuelle tekniske feil som hadde oppstått.
14 Oppgave 12 Spørsmål (maks 5 poeng pr spørsmål) 5. Forklar hvilke prinsipper eller praksiser fra smidig utvikling dere hadde nytte av. Beskriv prinsipper eller praksier som eventuelt ikke passet for deres prosjekt, og hvorfor de ikke virket.
15 Svar del 1: I prosjektet vårt brukte vi metodikken Scrum med enkelte tilpasninger av aktivitetene som Scrum rammeverket anbefaler. Vi valgte å bruke Scrum fremfor Kanban fordi Scrum virket som mer strukturert metodikk, noe vi trengte i vårt team som aldri hadde jobbet sammen før. Vi brukte rollene som Scrum rammeverket anbefaler, altså ScrumMaster som sørger for at reglene i Scrum blir fulgt og gjennomfører daglige stand-up møter og PO (produkteier) som er et bindeledd mellom kunden og teamet og har ansvar for å prioritere oppgavene i backlogen. ScrumMaster rollen rullerte vi på gjennom hele prosjektet slik at alle kunne prøve seg på det. I etterkant av prosjektet ser vi at det kan være bedre med en fast ScrumMaster som har god forståelse av Scrum rammeverket. Produkteierrollen var fast gjennom hele prosjektet for å sikre at prioritering av oppgavene i backlogen var konsistent. Vi så nytten av å ha en produkteier fordi det var til tider utfordrende å bli enige om hvilke oppgaver som skulle prioriteres. Ved hjelp av produkteier fikk vi derimot en bedre felles mentale modell ved at vi hadde et mål og en visjon for sprinten (og hele prosjektet). Vi gjennomførte både sprintplanleggingsmøter, stand-up møter og en form for sprint review og sprint retrospective møter.
16 Svar del 2: Under planleggingsmøter ble teamet og produkteieren enige om målet for sprinten. Deretter brukte vi planning poker som metode for estimering av tid og kompleksitet til oppgavene. Vi lagde sprint backlog ved å flytte noen oppgaver fra product backlog og markere den som "Planned" på Kanban-boardet vårt. Kanban board har vært et viktig verktøy for å kunne se progresjonen og holde seg oppdatert på hvem som jobbet med hva til enhver tid. Stand-up møter ble ikke gjennomført hver dag, men dette var en av de mest nyttige møtene vi hadde blant annet for å støtte prinsippet om at den beste kommunikasjonen er ansikt-til-ansikt kommunikasjon. ScrumMaster sørget for at alle fikk fortelle hva de har gjort siden siste møte, hvilke problemer eller utfordringer de har og hva de planlegger å gjøre til neste gang. På denne måten holdt alle seg oppdatert. Selve møtene ble gjennomført stående for å gjøre de korte og konsise, etter stand-up møter hadde vi ofte en aktivitet der vi kunne hjelpe hverandre med problemene vi eventuelt hadde. Siden møtene ikke ble gjennomført hver dag var vi nødt til å finne alternative løsninger for å holde seg oppdatert og da ble chat mye brukt. Sprint review og sprint retrospective gjennomførte vi ikke like formelt som Scrum rammeverket anbefaller, men hadde fortsatt vår versjon av disse. På slutten av hver sprint hadde vi et møte der vi først diskuterte eventuelle forbedringer eller feil knyttet til selve applikasjonen (sprint review). Vi hadde ikke nytte av å lage en demo-presentasjon da det ikke var andre enn utviklere i teamet til stede. Denne diskusjonen gikk over i sprint retrospective der vi diskuterte selve prosessen og hva vi kunne forandre på i gjennomføring av de neste sprintene. Vi prøvde ut noen teknikker for å "sette atmosfære" som er den første anbefalte fasen i en retrospective møte, men dette fungerte ikke så godt for oss på grunn av tidsrammer for møtet og fordi vi allerede hadde sprint review før det slik at diskusjonen allerede var i gang.
Oppgave 1 Multiple Choice
Oppgave Multiple Choice a 2c 3a 4c 5d 6d 7a 8b 9b 0a b 2c 3c 4a 5b 6b 7a 8d 9c 20b Se video fra forelesningen (Kahoot) for mer detaljer) Eksamen INF050-204 Oppgave 2 a Aktivitetsdiagram Enkelt Eksamen
DetaljerOppgave 1: Multiple choice (20 %)
Oppgave 1: Multiple choice (20 %) For alle oppgavene gjelder at det bare er ett riktig svar. No Spørsmål Svar A Svar B Svar C Svar D 1 Kanban er et eksempel på: Prosess Software prosess Prosess modell
DetaljerGJENNOMGANG 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:
DetaljerForside Eksamen INF1055 V17
Forside Eksamen INF1055 V17 Eksamensdato: 12. juni 2017 Eksamenstid 15:30-19:30 Hjelpemidler: Ingen Les denne forsiden nøye Oppgaven består av seks deler. Del 1 Modul A - Undersøkelser av bruk 2 diskusjonsspørsmål
DetaljerEksamen 2013 Løsningsforslag
Eksamen 2013 Løsningsforslag Oppgave 1. Multiple choice 1b# 2a# 3b# 4c# 5b# 6a# 7a# 8b# 9d# 10b# Oppgave 2 - Bibliotek - Utlån av bøker a) Måle størrelse eller mengde funksjonalitet Denne oppgaven ser
DetaljerLø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
DetaljerUKE 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
DetaljerLø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
DetaljerGJENNOMGANG 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.
DetaljerProsessmodeller 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
DetaljerGJENNOMGANG 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
Detaljer1. 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)
Detaljer1. 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
DetaljerUNIVERSITETET 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:
DetaljerInf1055 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
DetaljerKap 11 Planlegging og dokumentasjon s 310
Kap 11 Planlegging og dokumentasjon s 310 11.1 Ulike arbeidsmetoder Systemutvikling Som systemutvikler er du i stand til å omsette din innsikt i brukerbehov til praktiske programbaserte løsninger. Samarbeid:
DetaljerTeamarbeid og smidig metodikk. Lean og Scrum. Prosjektarbeid
IN 2001 29 januar 2018 Teamarbeid og smidig metodikk. Lean og Scrum. Prosjektarbeid Yngve Lindsjørn ynglin@ifi.uio.no IN 2001 > Prosjekt og teamarbeid 1 Utvikling av programvare - Suksesskriterier Levere
DetaljerMellom barken og veden Smidig testing i krevende terreng TTC 2015
Mellom barken og veden Smidig testing i krevende terreng TTC 2015 FOREDRAGSHOLDERE Kristian Bjerke-Gulstuen Accenture siden 1999 Fra utvikler til Testleder og Kvalitetsansvarlig Leder Accenture Norway
DetaljerKravhå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
DetaljerBachelorprosjekt i informasjonsteknologi, vår 2017
Bachelorprosjekt i informasjonsteknologi, vår 2017 Gruppe 29: Marthe Janson Skogen, s236357, Ingeniørfag - data Odd Einar Hoel, s236313, Ingeniørfag - data Forprosjektrapport Rapporten inneholder presentasjon,
DetaljerCONNECTING BUSINESS & TECHNOLOGY KURS OG SERTIFISERINGER - SCRUM
CONNECTING BUSINESS & TECHNOLOGY KURS OG SERTIFISERINGER - SCRUM Scrum Master og Product Owner i Høst 2015 1 Om Scrum Scrum er et populært rammeverk laget med henblikk på å utvikle komplekse informasjonssystemer.
Detaljer11 Planlegging og dokumentasjon
11 Planlegging og dokumentasjon Ulike arbeidsmetoder Systemutvikling Som systemutvikler er du i stand til å omsette din innsikt i brukerbehov til praktiske programbaserte løsninger. Samarbeid: Programmerer
DetaljerGJENNOMGANG 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
DetaljerEksamen 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
DetaljerTogether. Free your energies Moden og modig! Ansvarsfull og fleksibel!
Moden og modig! Ansvarsfull og fleksibel! Anine Ragnif og Bodil Rabben 13. Mai 2009 Agile Hvorfor? Gjennomsnittlig overskridelse i arbeidsmengde var 24% for prosjektene som benyttet en fleksibel metodikk,
DetaljerPrø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
DetaljerGJENNOMGANG 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
DetaljerLykke 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:
DetaljerUNIVERSITETET 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:
DetaljerUKE 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
DetaljerSCRUM Smidig prosjektledelse og utvikling. 10 september 2009 JOSÉ MANUEL REDONDO LOPERA AVDELINGSLEDER PROSJEKT OG RESSURSANSVARLIG
SCRUM Smidig prosjektledelse og utvikling 10 september 2009 JOSÉ MANUEL REDONDO LOPERA AVDELINGSLEDER PROSJEKT OG RESSURSANSVARLIG HVORDAN SPISER DU EN ELEFANT? EN BIT AV GANGEN 'HOW WILL YOU LIVE, RAMBO?'
DetaljerUNIVERSITETET 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:
DetaljerNeste generasjon ERP-prosjekter
Neste generasjon ERP-prosjekter Jan-Olav Arnegård 27. okt 2016 Nøkkeltall 2015 22 Land der vi er direkte representert 36 BearingPoint-kontorer 67 Kontorer der vi er representert via vår globale alliansepartnere
DetaljerTesting av programvare
Inf1050 07 mars 2017: Testing av programvare Yngve Lindsjørn ynglin@ifi.uio.no 1 Oversikt Hva er testing? Validering &Verifisering Testfaser Enhetstesting Integrasjonstesting Systemtesting Akseptansetesting
DetaljerScrum. en beskrivelse V 2012.12.13
Scrum en beskrivelse Scrum prinsipper Verdier fra Agile Manifesto Scrum er det mest kjente av de smidige (Agile) rammeverkene. Scrum er også kilden til mye av tankegodset bak verdiene og prinsippene i
DetaljerProsjektledelse - fra innsiden av et utviklingsprosjekt. Presentasjon hos UiO Ida Lau Borch, prosjektleder i Bouvet ASA
Prosjektledelse - fra innsiden av et utviklingsprosjekt Presentasjon hos UiO 09.09.2011 Ida Lau Borch, prosjektleder i Bouvet ASA Agenda De umulige IT-prosjektene Hvordan vi gjør det Utfordringer og lykkestunder
DetaljerKontrakter og test i smidige prosjekter. Fagmøte Dataforeningen i Trondheim 12.Mars 2012
Kontrakter og test i smidige prosjekter Fagmøte Dataforeningen i Trondheim 12.Mars 2012 Agenda Smidige manifest Smidige prosjekter og testing Samarbeid og tillit teori Hva er en kontrakt Gjennomgang av
DetaljerForside. Eksamen i IN1030 for Våren Ingen hjelpemidler tillatt.
Forside Eksamen i IN1030 for Våren 2018. Ingen hjelpemidler tillatt. I dette oppgavesettet har du mulighet til å svare med digital håndtegning (oppgave 1, 4 og 5). Du bruker skisseark du får utdelt. Det
DetaljerEventhandler Teknologi, kunst og design Høgskolen i Oslo og Akershus, våren 2013. Testrapport
Eventhandler Teknologi, kunst og design Høgskolen i Oslo og Akershus, våren 2013 Testrapport 1 INNHOLDSFORTEGNELSE 1 INNHOLDSFORTEGNELSE... 1 2 Innledning... 2 3 Formål med testing... 3 3.1 Funksjonalitet...
DetaljerDistributed object architecture
Forelesning IMT2243 6. April 2010 Tema: forts. arkitektur og design av programvare Prosjektstatus Programvarearkitektur Oppsummering fra før påske Distribuerte objektarkitektur MDA - Model Driven Architecture
DetaljerProsjektledelse - fra innsiden
Prosjektledelse - fra innsiden Presentasjon hos UiO 31.08.2012 Ida Lau Borch, fagansvarlig i Metier AS Det ligger et fantastisk potensial i det å være best i prosjektledelse og -styring Prosjekteierstyring
DetaljerKandidat nr. 1, 2 og 3
Kandidat nr. 1, 2 og 3 Rapport 1 IT202E Bacheloroppgave i Informatikk Vår 2011 Mobilapplikasjonsutvikling med Scrum 1 Innhold Innledning... 3 Overordnet Prosjektplan... 3 Produktbacklog... 5 Sprint planning
DetaljerScrum. -nøkkelbegreper og noen personlige erfaringer
Scrum -nøkkelbegreper og noen personlige erfaringer Agile Manifesto Manifest for smidig systemutvikling Vi oppdager stadig nye og bedre måter å utvikle systemer på, både ved å gjøre det selv og ved å hjelpe
DetaljerKravspesifikasjon
24.05.2017 Kravspesifikasjon Gruppe 10 BACHELORPROSJEKT 2017 INNHOLDSFORTEGNELSE 1 PRESENTASJON... 3 2 OM BAKGRUNNEN... 3 3 FORORD... 4 4 LESERVEILEDNING... 4 5 KORT SYSTEMBESKRIVELSE... 4 6 RAMMEKRAV...
DetaljerErfaringer fra bruk av Scrum i PS2000-prosjekter NSP temadag Agile metoder i prosjekt 13.05.2009. Motivasjon av kunder og Nyttige verktøy
Erfaringer fra bruk av Scrum i PS2000-prosjekter NSP temadag Agile metoder i prosjekt 13.05.2009 Motivasjon av kunder og Nyttige verktøy 2009-05-20 Computas AS 2008 Computas-metodikk fra da til nå Computas
DetaljerIS Introduksjon til informasjonssystemer
KANDIDAT 3644 PRØVE IS-100 1 Introduksjon til informasjonssystemer Emnekode IS-100 Vurderingsform Skriftlig eksamen Starttid 13.12.2016 07:00 Sluttid 13.12.2016 11:00 Sensurfrist 05.01.2017 23:00 PDF opprettet
DetaljerGruppe 43. Hoved-Prosjekt Forprosjekt
Gruppe 43 Hoved-Prosjekt Forprosjekt Mobil Applikasjon Utvikling HiOA Bacheloroppgave forprosjekt våren 2017 Presentasjon Gruppen består av: Gebi Beshir Ole-Kristian Steiro Tasmia Faruque s182414 s189141
DetaljerSCRUM EB og TMG 2010
SCRUM Hovedmål Mer om roller i SCRUM Es/mering av innhold i sprinter Visualisering av fremdri; ved burndown Scrum Daily SCRUM 24h Product backlog Sprint backlog 1 uke Sprint Delprodukt / delleveranse Roller
DetaljerFORPROSJEKT RAPPORT PRESENTASJON
FORPROSJEKT RAPPORT PRESENTASJON Tittel: Oppgave: Appenes App Utvikle en Windows 8.1 Applikasjon for Tablet, og en Windows 8 Phone App og en backend. Periode: 06.01.2013-27.05.2013 Gruppemedlemmer: Athavan
DetaljerKravspesifikasjon. Forord
Kravspesifikasjon Forord Hensikten med en kravspesifikasjon er å gi et overblikk over programmets funksjonalitet og tilleggsfunksjoner, dette vil si både over de som er utviklet før prosjektstart, og de
DetaljerStikkord: Java EE, EJB, JSF, JPA, SWT, klient/tjener, Glassfish server, Application Client.
Stikkord: Java EE, EJB, JSF, JPA, SWT, klient/tjener, Glassfish server, Application Client. Studenter: Magnus Skomsøy Bae, Marius Eggen, Magnus Krane Klasse: 3ING, Systemutvikling Produserer redaksjonelle
DetaljerModellering 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
DetaljerPresentasjon 2 Gruppe 2 Oppgave 2 Oppdragsgiver 2. Sammendrag 3. Dagens situasjon 3 ServiceNow 3 Coop 3. Mål og rammebetingelser 3 Mål 3 Teknologier 4
Forprosjektrapport Bachelorprosjekt for gruppe 8, våren 2017 Innholdsfortegnelse Presentasjon 2 Gruppe 2 Oppgave 2 Oppdragsgiver 2 Sammendrag 3 Dagens situasjon 3 ServiceNow 3 Coop 3 Mål og rammebetingelser
DetaljerPROGRAMUTVIKLINGSPLAN. Big Data and Machine Learning
PROGRAMUTVIKLINGSPLAN Big Data and Machine Learning Innholdsfortegnelse Produkt beskrivelse... 1 Team beskrivelse... 2 Prosjektets kunnskapskrav... 2 Medlemmer og roller... 2 Program prosessmodell beskrivelse...
DetaljerHvordan evaluerer man kvaliteten på et IT-system?
IN2001: Software Engineering og prosjektarbeid 19. februar 2018 Forskningsmetoder / Evaluering av ITsystemer med fokus på prosjektet Professor Dag Sjøberg IN2001/ 19.2.2018 / Dag Sjøberg Slide 1 Hvordan
Detaljeraltinn tjenester 3.0
14.09.2016 altinn tjenester 3.0 Agenda Hva er tjenester 3.0? Status Konsepter Demo og diskusjoner altinn tjenester 3.0 Hva er tjenester 3.0? Hva er tjenester 3.0? Brukervennlige og responsive tjenester
DetaljerIN2001: Kravhåndtering, modellering, design
IN2001: Kravhåndtering, modellering, design 30 januar 2018 Yngve Lindsjørn ynglin@ifi.uio.no IN2001 -> Kravhåndtering og modellering 1 Gode beskrivelser av krav er viktig for kontrakt oppdragsgiver leverandør
DetaljerGruppenavn. 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
DetaljerModellering 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
DetaljerObligatorisk 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
DetaljerForprosjektrapport. Gruppe 3, Anvendt Datateknologi våren 2016
Forprosjektrapport Gruppe 3, Anvendt Datateknologi våren 2016 1. Presentasjon 2. Sammendrag 3. Dagens situasjon 4. Mål og rammebetingelser 5. Løsninger/alternativer 6. Analyse av virkninger 1. Presentasjon
DetaljerUse 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
DetaljerUKE 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
DetaljerVEDLEGG 4 FUNKSJONELLE
VEDLEGG 4 FUKSJOELLE BRUKERHISTORIER Side 1 av 8 IHOLDSFORTEGELSE 1 ILEDIG... 3 1.1 BRUK AV ETTBRETT I BÆRUMSSKOLE... 3 1.1.1 Skoleledelsen... 3 1.1.2 Læreren... 4 1.1.3 Eleven... 4 1.1.4 Eleven med lærevansker...
DetaljerKravspesifikasjon. Forord
Forord Kravspesifikasjonen skal gi en oversikt og forståelse over det planlagte systemets funksjonalitet. Dokumentet skal gi både utviklere og oppdragsgivere innblikk i hvordan og hva systemet skal levere.
DetaljerFra 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
DetaljerForprosjektrapport Hovedprosjekt våren 2015 HiOA
Forprosjektrapport Hovedprosjekt våren 2015 HiOA Gruppe 9 Innhold 1. Presentasjon.... 3 2. Sammendrag.... 3 3. Dagens situasjon... 4 4. Mål og rammebetingelser... 5 5. Løsninger/Alternativer.. 6 6. Analyse
DetaljerGruppetime
Gruppetime 2 01.01.18 Bli med i Slack-kanalen vår hvis du enda ikke har gjort det! https://join.slack.com/t/in2001/shared_invite/enqtmzayntq4nji0ntawltuymjbjzwzindm1ytvkmg RmOTc4ZDI4NGIyMDFmMGZkMGMyYzJmYjk1M2NlZGQyNGNmOWM0Mzc1ODM4NTM5NzY
DetaljerVEDLEGG 1 KRAVSPESIFIKASJON
VEDLEGG 1 KRAVSPESIFIKASJON INNHOLDSFORTEGNELSE Forord... 2 1 Systembeskrivelse... 2 2 Mål for systemet... 3 3 Funksjonelle krav... 4 4 Ikke-funksjonelle krav... 5 5 Use-case diagram... 6 6 Rammekrav...
DetaljerIntroduksjon,l SCRUM. EB og TMG 2010 1
Introduksjon,l SCRUM EB og TMG 2010 1 Hva er Scrum? Kilde: http:/image.google.com EB og TMG 2010 2 Kompleksitet Kilde: http://www.coderfriendly.com/ EB og TMG 2010 3 SCRUM - kortversjonen Scrum er en smidig
DetaljerUKE 14 Versjonshåndtering og testing. Gruppetime INF1055 Julie Hagen Nilsen & Maria Stolinski
UKE 14 Versjonshåndtering og testing Gruppetime INF1055 Julie Hagen Nilsen & Maria Stolinski UKENE FREMOVER OBS! Ikke forelesning 17. mai ikke gruppetime 19. og 23. mai Felles gruppetime for alle fredag
DetaljerKravspesifikasjon Hovedprosjekt ved Høgskolen i Oslo Våren 2008
Kravspesifikasjon Hovedprosjekt ved Høgskolen i Oslo Våren 2008 1.Forord I dette dokumentet skal vi gi et bildet av de kravene som er satt til prosjektet. Dokumentet er hovedsakelig beregnet som et styringsdokument
DetaljerKRAVSPESIFIKASJON DAGSPLANAPPLIKASJON FOR NETTBRETT. Gruppe 28 Hovedprosjekt våren 2015
KRAVSPESIFIKASJON Kravspesifikasjon er en beskrivelse av hvilke krav oppdragsgiver har til systemet som skal utvikles. Den fungerer som en kontrakt mellom oppdragsgiver og utviklere. DAGSPLANAPPLIKASJON
DetaljerForprosjektrapport. Sammendrag. Hovedoppgave våren 2019 Gruppe 3
Forprosjektrapport Hovedoppgave våren 2019 Gruppe 3 Sammendrag Vi skal overføre en eksisterende nettside over på en ny plattform samt legge til noe tilleggsfunksjonalitet. Hovedutfordringene ved den eksisterende
DetaljerTesting 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
DetaljerProsjektledelse, 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
DetaljerForprosjektrapport ElevApp
Forprosjektrapport ElevApp Bachelorprosjekt i informasjonsteknologi ved Høgskolen i Oslo og Akershus, våren 2017 Gruppe 14 Mirko Grimm, s236630 Andreas Krutnes, s236656 Japple John Regalario, s236621 Innholdsfortegnelse
DetaljerKravspesifikasjon. Android app for aktivering av jakt- og fiskekort. Bacheloroppgave vår 2014. Høgskolen i Oslo og Akershus. Charlotte Sjøthun s180495
Charlotte Sjøthun s180495 Nanna Mjørud s180477 Anette Molund s181083 Kravspesifikasjon Android app for aktivering av jakt- og fiskekort Bacheloroppgave vår 2014 Høgskolen i Oslo og Akershus Forord Hensikten
DetaljerModernisering av IKT i NAV
Modernisering av IKT i NAV Test, Leverandørperspektiv Vedtaksløsningen 28.05.13 Kristian Bjerke-Gulstuen Innhold Kort introduksjon til Moderniseringsprogrammet i NAV Overordnet oversikt over test i NAV
DetaljerReferat. Møte i EpN ekspertgruppe
Felles studentsystem Telefon: 22852738 USIT, Universitetet i Oslo Telefax: 22852970 Postboks 1086, Blindern E-mail: fs-sekretariat@usit.uio.no 0316 Oslo URL: www.fs.usit.uio.no Referat Møte i EpN ekspertgruppe
DetaljerSRD GLIS. Cecilie Dortea Gløsmyr, Espen Buø og Henrik Lie
SRD GLIS Cecilie Dortea Gløsmyr, Espen Buø og Henrik Lie Innholdsfortegnelse 1. Systemoversikt... 2 2. Tekniske krav... 3 2.1. Funksjonskrav og brukergrensesnitt spesifikasjon... 3 2.2. Begrensninger...
DetaljerKonfigurasjonsstyring
INF1050: Systemutvikling 28. mars 2017 Konfigurasjonsstyring Yngve Lindsjørn ynglin@ifi.uio.no INF1050 Systemutvikling ->Konfigurasjonsstyring 1 Temaer i dagens forelesning Versjonshåndtering Systembygging
DetaljerTestplan (Software Test Plan)
Testplan (Software Test Plan) Amanuel K. Tedla Eleonora Ntreska Ingrid Vik Hansen Joakim Moen Innholdsfortegnelse Innholdsfortegnelse 1.. Introduksjon... 3 1.1 Definisjoner... 3 1.2 Antagelser ved testing
DetaljerSoftware Development Plan. Software Development Plan. Forum / Nettverkssamfunn Team 2
Forum / Nettverkssamfunn Team 2 1 Innholdsfortegnelse 1 Introduksjon... 3 2 Team & Organisering... 3 3 Brainstorming, tanker og utførelse... 4 3.1 Bruker Registrering og metoder... 4 3.2 Generering av
DetaljerCRIStin 2.0 Om videreutvikling av CRIStin-systemet. Oppstartseminar 22. Oktober 2013
CRIStin 2.0 Om videreutvikling av CRIStin-systemet Oppstartseminar 22. Oktober 2013 CRIStin og de gode hjelperne Mål for CRIStin-systemet Nav i norsk forskning Gi oversikt og pekere til mer detaljer Koblinger
DetaljerAvegility og ledelse av smidige prosjekter. Avenir AS > slide 1
Avegility og ledelse av smidige prosjekter Avenir AS > slide 1 Avenir AS > slide 2 Erfaringer fra utvikling av Energimerkesystemet for NVE Bakgrunn for Energimerkesystemet Stortinget har besluttet innføring
DetaljerForprosjektsrapport MMS - MakeSpace Management System BO19-G03
Forprosjektsrapport MMS - MakeSpace Management System BO19-G03 Andreas Harnes Celina Marie Kristiansen Magnus Klerck Morten Offerdal Kvigne 21. januar 2019 1 Innhold 1 Prosjektgruppen 3 2 Oppdragsgiver
DetaljerGjennomgang av eksamen IN1030 Gruppe 4
Gjennomgang av eksamen 2017 IN1030 Gruppe 4 Hva skal vi i dag? Litt om oblig 4 Gjennomgang av oppgaveteksten til oblig 5 Gjennomgang av eksamen fra 2017 Jobbe med oblig 4/5 Oblig 4 - hva jeg har sett når
DetaljerDatabaser og moderne systemutvikling - dag én
Databaser og moderne systemutvikling - dag én Harald Holone DAS - 2011-10-17 Databasen Demo Design Eclipse Endringer Enhetstesting Hibernate IoC Iterasjon JUnit Klienten Logikk Maven Mock-ups MySQL Objekter
DetaljerGjennomgang 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.
DetaljerForprosjektrapport. Bachelorprosjekt i informasjonsteknologi ved Høgskolen i Oslo og Akershus, våren 2016. Pillbox Punchline
Forprosjektrapport Bachelorprosjekt i informasjonsteknologi ved Høgskolen i Oslo og Akershus, våren 2016 Pillbox Punchline Gruppe 8 André Østhagen Bye, s198607 Annika Hammervoll, s198611 Hanne Rygge, s198613
DetaljerUML-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
DetaljerErfaringer med PS2000 kontrakt og kontraktsstyring i PERFORM. Mette Gjertsen Prosjektleder Statens Pensjonskasse
Erfaringer med PS2000 kontrakt og kontraktsstyring i PERFORM Mette Gjertsen Prosjektleder Statens Pensjonskasse mette.gjertsen@spk.no Agenda 1. Statens pensjonskasse 2. Kort om prosjektet 3. Gjennomføringsmodell
DetaljerProsjektledelse, prosjektplanlegging, teamarbeid
INF1050: Systemutvikling 25. mars 2015 Prosjektledelse, prosjektplanlegging, teamarbeid Universitetslektor Yngve Lindsjørn INF1050 Systemutvikling ->Prosjektledelse og teamarbeid 1 Temaer i dagens forelesning
DetaljerTest og kvalitet To gode naboer. Børge Brynlund
Test og kvalitet To gode naboer Børge Brynlund To gode naboer som egentlig er tre Kvalitetssikring, kvalitetskontroll og testing Kvalitet I Betydningen Kvalitet er den viktigste faktoren for å avlede langsiktig
DetaljerStøtter din digitale reise
Støtter din digitale reise Teknologi og prosess tenkt på nytt Sebastian Reichmann, Advisor for Analytics & Cognitive; EVRY Cloud analytics Product innovation Smart Automation Use more data to generate
DetaljerUKE 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
DetaljerForprosjektrapport Bachelorprosjekt i data/informasjonsteknologi ved OsloMet Oslo / fredag, 19. januar 2018
Forprosjektrapport Bachelorprosjekt i data/informasjonsteknologi ved OsloMet Oslo / fredag, 19. januar 2018 Utvikling av Spires Medlemsregister Gruppe 2, medlemmer Etternavn Fornavn og mellomnavn Studentnummer
DetaljerPresentasjon 1, Requirement engineering process
Presentasjon 1, Requirement ing process Prosessodeller Hvorfor bruke prosessmodeller? En prosessmodell er en forenklet beskrivelse av en prosess En prosessmodell er vanligvis lagd ut fra et bestemt perspektiv
Detaljer