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

Like dokumenter
GJENNOMGANG OBLIGATORISK OPPGAVE 1

Kontrakter. INF1050: Gjennomgang, uke 12

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

GJENNOMGANG UKESOPPGAVER 13 KONTRAKTER

GJENNOMGANG UKESOPPGAVER 7 REPETISJON

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

UKE 9 Prosesser og prosessmodeller inkludert smidige metoder. Gruppetime INF1055

SYSTEMUTVIKLINGSKONTRAKTER SMIDIG OG PS2000

Use Case-modellering. INF1050: Gjennomgang, uke 04

Kravhåndtering. INF1050: Gjennomgang, uke 03

GJENNOMGANG UKESOPPGAVER 2 PROSESSMODELLER OG SMIDIG PROGRAMVAREUTVIKLIG

UNIVERSITETET I OSLO

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

UKE 11 UML modellering og use case. Gruppetime INF1055

KONTRAKTER FOR PROGRAMVAREUTVIKLING. Ståle L Hagen UiO 20. april

UKE 10 Kravhåndtering. Gruppetime INF1055

Obligatorisk oppgave 5: Modellering av krav

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

Hvordan PS2000 blir tilpasset til smidig gjennomføring

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

Prosessmodeller og smidig programvareutvikling. INF1050: Gjennomgang, uke 02

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

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

UNIVERSITETET I OSLO

Valg av utviklingsmetode hva betyr dette for kontraktsutformingen

Forskningsmetoder. INF1050: Gjennomgang, uke 13

Eksamen INF1050: Gjennomgang, uke 15

KONTRAKTER FOR PROGRAMVAREUTVIKLING. Ståle L Hagen UiO 10 mai 2017

Oppgave 1: Multiple choice (20 %)

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

Fra krav til objekter. INF1050: Gjennomgang, uke 05

GJENNOMGANG UKESOPPGAVER 9 TESTING

Instituttets krav om autentisitet og regler for obligatoriske oppgaver gjelder.

Løsningsforslag Sluttprøve 2015

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

PÅ VEI MOT SMIDIGE KONTRAKTER. Ståle L Hagen IT-kontraktsdagen september

UNIVERSITETET I OSLO

Eksamen 2013 Løsningsforslag

GJENNOMGANG UKESOPPGAVER 3 KRAVHÅNDTERING

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

Modellering IT konferanse

Oppgave 2: Kontraktsutforming a) Refererer innledningsvis til følgende temaer i presentasjonen knyttet til særtrekkene i PS2000:

Instituttets krav om autentisitet og regler for obligatoriske oppgaver gjelder.

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

Forside Eksamen INF1055 V17

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

Smidig metodikk, erfaringer fra NAV Fagportal

Smidig modell for moderniseringen av NAV

Smidig leveranseprosjekt en selvmotsigelse. Dataforeningen og Norsk Senter for Prosjektledelse Temadag 31. mai En lyntale av Jon Øgar

Usikkerhet i omfang og kostnader hvordan håndtere dette i kontrakten? IT-kontraktsdagen 2015 Kjetil Strand, Promis AS

Ny kontraktsstandard: Fleksibel utviklingskontrakt

Hovedprosjekt 2014, Høgskolen i Oslo og Akershus

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

Mellom barken og veden Smidig testing i krevende terreng TTC 2015

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

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

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

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

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

Spesifikasjon av Lag emne

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

Universitetet i Bergen Det matematisk-naturvitenskapelige fakultet Institutt for informatikk

Konfigurasjonsstyring. INF1050: Gjennomgang, uke 11

Ansvarsdrevet OO: CRC og UML Sekvensdiagrammer

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

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

Store programmer når behovene er store. Perspektiver på fleksibilitet og modning i et stort digitaliseringsprogram. Nokios 2015

Prøveeksamen INF1050: Gjennomgang, uke 15

Erfaringer fra offentlige anskaffelser

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

Forprosjektrapport. Hovedprosjekt for gruppe 13, Anvendt datateknologi våren 2016

UNIVERSITETET I OSLO

Kap 11 Planlegging og dokumentasjon s 310

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

Kontrakt for oppdragsbasert smidig utvikling av programvare PS2000 SOL

Kravspesifikasjon med UML use case modellering. Erik Arisholm

Hvordan styre prosjekter frem til suksess Kontraktsformer og metodikk som fungerer Jørgen Petersen PROMIS AS 1

Guide. Valg av regnskapsprogram

DRI 2001 Systemutviklingsarbeidet et overblikk Forelesning

Hvordan kjøpe SAP? Rolf Larsen Adm.Dir, Skye AS

Evaluer & iverksett personvernarbeidet

Smidig innhold Hvordan smidige metoder hjelper oss å lage kvalitetsinnhold. Ove Dalen

Kontrakter. IT-Ledelse, 19.mars. Faglærer : Tom Røise. IMT1321 IT-Ledelse 1. Relevante avtaleformer innen IT. Dagens tema : Avtaler og kontrakter

Neste generasjon ERP-prosjekter

Strategitips til språkkommuner

Kravspesifikasjon. Dagens forelesning. Mal for kravspesifikasjon. Hvordan finne fram til kravene? Kravspesifikasjon og objektorientert analyse

UKE 3 Krav og behov. Plenum IN1050 Julie og Maria

Nye kontraktsreguleringer i vår digitale virkelighet - et innblikk i utviklingen som skjer med Statens standardavtaler

Hvordan innovative anskaffelser og Prosjektveiviseren går utmerket hånd i hånd

FÅ KONTROLL PÅ DE USTRUKTURERTE DATAENE

IT I PRAKSIS!!!!! IT i praksis 20XX

Alminnelige bestemmelser Gjennomføring av Leveransen Endringer etter avtaleinngåelsen

PRAKTISKE ERFARINGER MED DATAFORENINGENS SKYTJENESTEAVTALE. IT-kontraktsdagen 2017

Kapittel 7 & 8. Kravspesifikasjoner & Data design. Thomas Tjøstheim og Thomas Edvinsen. 20 September Kapittel 7 & 8 p.1/20

Oppgave 1 Multiple Choice

Utvikling fra skallet og inn

Drammen Bysykler er et lånesystem for sykler. For å kunne låne sykler fra Drammen Bysykler, må følgende betingelser oppfylles.

Hovedprosjekt i Informasjonsteknologi 2016 Høgskolen i Oslo og Akershus. Forprosjektrapport. Bravo Booking App

Transkript:

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 - I plandrevet utvikling - I smidig utvikling - Behov for smidige kontrakter - Kontraktsmodeller - PS2000

Kontrakter Hva? En kontrakt er en avtale som mellom partene etablerer en bindende forpliktelse til å gjøre eller til å unnlate å gjøre noe

Kontrakter - Ulike måter å utvikle systemer på vil kreve ulike kontrakter - Plandrevet vs. smidig utvikling - Anskaffelsesprosessen vil være forskjellig - Tradisjonell tilnærming er ikke tilstrekkelig dekkende for smidige metodikker - Avveining mellom fleksibilitet og forutsigbarhet

UKESOPPGAVER

SPØRSMÅL 1 Spørsmål: Beskriv minst to modeller for kontrakter for programvareutvikling. Modeller: 1. Fossefall/Resultatansvar 2. Ressurskjøp/Bistandsforpliktelse 3. Iterativ gjennomføringsmodell/ Seriefossefall

SPØRSMÅL 1 Spørsmål: Beskriv minst to modeller for kontrakter for programvareutvikling. Svar: Fossefall/Resultatansvar - Spesifisert resultat - Første steg er å utarbeide kravspesifikasjonen - Hva som skal lages spesifiseres konkret - Fast pris - Konkrete krav sørger for at man kan sette en pris på forhånd - Forutberegnelighet - Lite rom for kundeinvolvering underveis begrenset fleksibilitet - Kan sjekkes direkte Oppfylt kravspesifikasjon = overholdt kontrakt

SPØRSMÅL 1 Spørsmål: Beskriv minst to modeller for kontrakter for programvareutvikling. Svar: Iterativ gjennomføringsmodell/ Seriefossefall - Definert gjennomføringsmodell - Har en plan for hvordan prosjektet skal gjennomføres - Ingen detaljert kravspesifikasjon - Løpende spesifisering av del-leveranser - Målpris/estimeringsmodell - Forutberegnelighet øker underveis - Samtidig som fleksibiliteten reduseres - Krevende kontrakt Vanskelig å definere måloppnåelse

SPØRSMÅL 2 Spørsmål: Beskriv gjennomføringsmodellen i PS2000-kontrakten.

SPØRSMÅL 2 Spørsmål: Beskriv gjennomføringsmodellen i PS2000-kontrakten. Svar: PS2000 er en kontraktsstandard utviklet i regi av NTNU og SINTEF - Verktøy for gjennomføring av IT-prosjekter - Elementer og prinsipper: - Effektivisering av tilbudsprosessen - Erfaringsbasert (beste praksis) - Håndtering av usikkerhet er tilrettelagt - Samarbeid mellom kunde og leverandør - Trinnvis/iterativ utvikling ligger til grunn

SPØRSMÅL 2 Spørsmål: Beskriv gjennomføringsmodellen i PS2000-kontrakten. Svar: PS2000 Kontraktstruktur - Del I: Kontraktdokument - Nøkkelinformasjon - Partene/kontraktens omfang/avvik - Del II: Generelle kontraktbestemmelser - Alle generelle prinsipper og føringer - Juridiske betingelser - Del III: Bilag - Konkret regulering av den spesifikke leveransen

3. Iterativ konstruksjonsfase 2. Løsningsbeskrivelsefase 4. Godkjennings- og avslutningsfase 1. Behovsfase

SPØRSMÅL 2 Spørsmål: Beskriv gjennomføringsmodellen i PS2000-kontrakten. Svar: Fase 1 - Behovsfase: - Undersøker kundens behov og mål til leveransen - Spesifiserer problemområdet - Bruker en prioritert liste over overordnede krav Muliggjør godkjenningskriterier Følgende elementer bør vurderes: - Partenes forståelse og målsettinger - Kompleksitet - Tilgjengelig tid og avhengigheter til øvrige parter - Fleksibilitet, smidighet, risikovillighet

SPØRSMÅL 2 Spørsmål: Beskriv gjennomføringsmodellen i PS2000-kontrakten. Svar: Fase 2 - Løsningsbeskrivelsesfase: - Utarbeider en beskrivelse av den tenkte løsningen - Ikke nødvendigvis veldig detaljert/omfattende - Innebærer en grundig gjennomgang av behovsanalysen - Gir dermed større trygghet til behovsanalysen Godkjenning av løsningsanalysen bør formaliseres - Skal godtas av både leverandør og kunde - Formelt dokumentert

SPØRSMÅL 2 Spørsmål: Beskriv gjennomføringsmodellen i PS2000-kontrakten. Svar: Fase 3 - Iterativ konstruksjonsfase: - Går inn i perioden med iterasjoner - Består av tre underfaser - Detaljert planlegging/analyse og design - Utvikling - Testing Etter endt iterasjon.. - Evaluer det som er laget (med kunden) og bli enige om hva som lages i neste

SPØRSMÅL 2 Spørsmål: Beskriv gjennomføringsmodellen i PS2000-kontrakten Svar: Fase 4 - Godkjennings- og avslutningsfase: - Overtakelsesfasen innebærer at kunden godkjenner produktet - Prosjektet avsluttes - Gjennomfører godkjenningsprøver - Funksjonelle tester/ytelsestester - Sikre at leveransen oppfyller kravene i løsningsbeskrivelsen - Avsluttes med en prosjektevaluering - Begge parter er forpliktet til å delta på denne evalueringen

SPØRSMÅL 3 Spørsmål: Beskriv minst tre eksempler på sentrale prinsipper i PS2000 og hva som ligger i dem. Prinsipper: 1. Fokus på vellykket prosjektgjennomføring 2. Visualisering og regulering av gjennomføringsmodellen 3. Absorberer læring underveis i gjennomføringen 4. Balansert fleksibilitet og forutsigbarhet 5. Deling av kommersiell risiko gjennom målprismodell 6. Integrert samarbeid og håndtering av usikkerhet

SPØRSMÅL 3 Spørsmål: Beskriv minst tre eksempler på sentrale prinsipper i PS2000 og hva som ligger i dem. Svar: 1. Fokus på vellykket prosjektgjennomføring - Kontrakten fokuserer på gjennomføring, ikke kun på hva som lages - Setter krav til samarbeid mellom kunde og leverandør 2. Visualisering og regulering av gjennomføringsmodellen - Har en mal for prosjektgjennomføringen - Vet hvordan man skal gå frem

SPØRSMÅL 3 Spørsmål: Beskriv minst tre eksempler på sentrale prinsipper i PS2000 og hva som ligger i dem. Svar: 3. Absorberer læring underveis i gjennomføringen - Legger til rette for at man kan bli enige om endringer underveis - Baserer seg på erfaring 4. Balansert fleksibilitet og forutsigbarhet - Setter enkle føringer/krav til prosjektgjennomføringen - Prosjektet gjøres mer forutsigbart

SPØRSMÅL 3 Spørsmål: Beskriv minst tre eksempler på sentrale prinsipper i PS2000 og hva som ligger i dem. Svar: 5. Deling av kommersiell risiko gjennom målprismodell - Mindre risiko for at kunden ikke vil betale - Blir enige om endringer og pris underveis 6. Integrert samarbeid og håndtering av usikkerhet - Kartlegger usikkerhet på forhånd, og blir enige om ansvar - Kunde, leverandør, eller begge? - Oppdaterer usikkerhetsmatrisen underveis

OBLIG 4

Case: Markasykler Tips til å forstå et case i systemutvikling (eksamensmat) - Les beskrivelsen nøye! - Marker/noter viktige aspekter ved systemet som beskrives: - funksjonalitet, egenskaper, eventuelle begrensninger - Husk å skrive ned alle antakelser dere gjør - Ha fokus på systemet identifiser hva som er en del av systemet, og hva er en del av tjenesten eller konteksten systemet inngår i?

DEL 1: Bakgrunn for systemet Oppgave 1a: Nevn fordeler og ulemper ved å benytte Ruters betalingsløsning istedenfor å utvikle en betalingsløsning selv.

DEL 1: Bakgrunn for systemet Oppgave 1a: Nevn fordeler og ulemper ved å benytte Ruters betalingsløsning istedenfor å utvikle en betalingsløsning selv. Løsningsforslag: Forslag på fordeler som man kan diskutere ved å benytte Ruters betalingsløsning: - Det tar mindre tid enn å utvikle selv - Sparer tid (evt. penger?) - Mindre eksterne krav å ta hensyn til - Løsningen fungerer den er godt testet - Kundene har kjennskap til denne løsningen - Mindre å forholde seg til for kundene - Mange bruker løsningen fra før av

DEL 1: Bakgrunn for systemet Oppgave 1a: Nevn fordeler og ulemper ved å benytte Ruters betalingsløsning istedenfor å utvikle en betalingsløsning selv. Løsningsforslag: Forslag på ulemper som man kan diskutere ved å benytte Ruters betalingsløsning: - Det kan bli dyrt dersom man må betale Ruter for å kunne bruke deres løsning - Blir avhengig av Ruters teknologi - Løsningen er ikke originalt laget for sykler - Det kan være vanskelig å implementere løsningen - Får ikke satt opp betalingsautomater uten Ruters samtykke - Kundene må forholde seg til to aktører, én for betaling og én for registrering med mer informasjon

DEL 1: Bakgrunn for systemet Oppgave 1b: Hvilke aspekter ved markasykler skiller seg fra bysykler? Nevn fordeler og ulemper ved å utvikle et nytt system i forhold til å benytte seg av bysykler-systemet.

DEL 1: Bakgrunn for systemet Oppgave 1b: Hvilke aspekter ved markasykler skiller seg fra bysykler? Nevn fordeler og ulemper ved å utvikle et nytt system i forhold til å benytte seg av bysykler-systemet. Løsningsforslag: Forslag på aspekter man kunne diskutert: - Ulikt bruksmønster ulik målgruppe - Utlånstid av syklene - Type sykler - Kan ha noe å si for stativene - Må ha funksjonalitet til å velge sykkeltype man ønsker - GPS-system som rapporterer turene - Mer vedlikehold av syklene brukes i et annet terreng - Vanskeligere å hente og flytte sykler

DEL 1: Bakgrunn for systemet Oppgave 1b: Hvilke aspekter ved markasykler skiller seg fra bysykler? Nevn fordeler og ulemper ved å utvikle et nytt system i forhold til å benytte seg av bysykler-systemet. Løsningsforslag: Forslag på fordeler ved å utvikle et nytt system man kunne diskutert: - Man får et spesialtilpasset system - Blir uavhengig av Bysykkel-systemet - Kan bli billigere for kundene dersom man kun bruker markasykler - En felles løsning kunne krevd at man var kunde hos begge parter, noe som kan bli unødvendig dyrt

DEL 1: Bakgrunn for systemet Oppgave 1b: Hvilke aspekter ved markasykler skiller seg fra bysykler? Nevn fordeler og ulemper ved å utvikle et nytt system i forhold til å benytte seg av bysykler-systemet. Løsningsforslag: Forslag på ulemper ved å utvikle et nytt system man kunne diskutert: - Kan være tidsbesparende å implementere løsningen i bysykler-systemet - For de som benytter seg av begge løsningene vil det være enklere å registrere seg kun ett sted fremfor to

DEL 2: Interessenter for systemet Oppgave 2a: Hva er forskjellen på en aktør og en interessent?

DEL 2: Interessenter for systemet Oppgave 2a: Hva er forskjellen på en aktør og en interessent? Løsningsforslag: - En aktør er en som bruker systemet, eller et system som brukes av systemet. Vi skiller mellom primær- og sekundæraktører: - En primæraktør er en bruker som har et eget mål med å anvende systemet. - En sekundæraktør hjelper primæraktøren med å oppnå sitt mål i systemet. - Samme aktør kan både være primær- og sekundæraktør, avhengig av use caset man vil beskrive. - En interessent er et individ, en gruppe, eller en organisasjon som påvirker eller blir påvirket av systemets utvikling og/eller drift. Alle aktører i systemet er interessenter, men ikke alle interessenter er aktører.

DEL 2: Interessenter for systemet Oppgave 2b: Kartlegg minst seks interessenter i markasykler-systemet. Få med navn, ansvarsområder og interesser til hver interessent i systemet. Sett dette opp i et oversiktlig skjema.

DEL 2: Interessenter for systemet Løsningsforslag 2b: INTERESSENT ANSVARSOMRÅDE INTERESSER Kunde/bruker Ingen Vil ha et brukervennlig system Ønsker et robust system Utvikler Eier Utvikle systemet i henhold til kravspesifikasjonen Vedlikehold av systemet Kravspesifikasjonen At systemet følger lovverket Økonomisk ansvar Ønsker et system som er lett å vedlikeholde Enkelt å utvikle Gjenbruk Tjene mest mulig penger Ønsker et velfungerende system

DEL 2: Interessenter for systemet Løsningsforslag 2b: INTERESSENT ANSVARSOMRÅDE INTERESSER Ruter At betalingsløsningen fungerer som den skal/er pålitelig Tjene penger Kundebehandler Ingen Et brukervennlig system Et velfungerende system Myndigheter Passe på at systemet ikke bryter med norsk lov eller personopplysingsloven At norsk lov og personopplysningsloven følges

DEL 2: Interessenter for systemet Oppgave 2c: Hvilke av interessentene er også aktører?

DEL 2: Interessenter for systemet Oppgave 2c: Hvilke av interessentene er også aktører? Løsningsforslag: - Kunde - Vil låne sykkel, vil betale billett, vil ha oversikt over tilgjengelige sykler og ledige stativ. - Ruter - Stiller med betalingssystem, vil hente statistikk over betalte billetter - Eier - Vil hente statistikk og rapporter generert i systemet - Kundebehandler - Vil se oversikt over omsetning, vil lokalisere for sent leverte sykler, vil registrere nye brukere

DEL 3: Utviklingsprosess for systemet Oppgave 3a: Hva kjennetegner plandrevne utviklingsprosesser?

DEL 3: Utviklingsprosess for systemet Løsningsforslag 3a: Forslag på punkter man kunne diskutert i en slik besvarelse: - Prioriterer å utvikle systemet basert på en forhåndsdefinert plan - Aktivitetene som inngår i prosessen - Kravhåndtering - System- og software design - Implementering og enhetstesting - Integrering og systemtesting - Vedlikehold - Statisk kravspesifikasjon - Oftest ett endelig produkt - Fokus på dokumentasjon og rapportering - Beskriv typiske prosjekt hvor det er hensiktsmessig å benytte en slik prosess - Fossefallsmodellen

DEL 3: Utviklingsprosess for systemet Oppgave 3b: Hva kjennetegner smidige utviklingsprosesser?

DEL 3: Utviklingsprosess for systemet Oppgave 3b: Hva kjennetegner smidige utviklingsprosesser? Løsningsforslag: Forslag på punkter man kunne diskutert i en slik besvarelse: - Fokus på iterasjoner og inkrementell utvikling - Dynamisk kravspesifikasjon hvor brukerhistorier spiller en viktig rolle - Prioriterer å håndtere kravendringer underveis - Hvordan/hvorfor det er enklere å håndtere endringer underveis - Fokus på kundekontakt - Fokus på testing - Mindre fokus på dokumentasjon og rapportering - Typiske prosjekt hvor det er hensiktsmessig å benytte en slik prosess - Scrum og Kanban

DEL 3: Utviklingsprosess for systemet Oppgave 3c: I hvilken grad bør man ta høyde for at kravspesifikasjonen til markasykler-systemet må endres underveis i utviklingen. Forklar.

DEL 3: Utviklingsprosess for systemet Oppgave 3c: I hvilken grad bør man ta høyde for at kravspesifikasjonen til markasykler-systemet må endres underveis i utviklingen. Forklar. Løsningsforslag: Forslag til aspekter man kunne diskutert i en slik oppgave: - Det finnes en lignende løsning fra før (bysykler), så utviklerne vet ca. hva de er ute etter. - Bysykler og markasykler har ulikt bruksmønster dette stiller ulike krav - Ulik målgruppe kan føre til ulike krav og ønsker om endringer i brukergrensesnittet - Forskjellig domene ingen garanti for at teknologien bak bysykler fungerer like bra i skogen; for eksempel mtp. lokasjon, vedlikehold og materialer - Ulike interessenter disse kan stille forskjellige krav - Hvor stabile tror du kravene er`?

DEL 3: Utviklingsprosess for systemet Oppgave 3d: Hvilken type utviklingsprosess mener du/dere er mest egnet for dette systemet? Forklar hvorfor.

DEL 3: Utviklingsprosess for systemet Oppgave 3d: Hvilken type utviklingsprosess mener du/dere er mest egnet for dette systemet? Forklar hvorfor. Løsningsforslag: Forslag på diskusjonselementer (vil avhenge av hva dere har svart på de tidligere oppgavene viktig med samsvar): - I og med at mye backend kan utvikles med utgangspunkt i Bysykler vil plandrevet være passende - Plandrevet krever derimot en forhåndsspesifisert plan og det vil være krevende å håndtere endringer underveis dette vil imidlertid avhenge av hvor godt kravhåndteringen er blitt gjort og hvor sannsynlig det er at endringer vil skje - Kan løse dette ved å ta i bruk elementer som inkrementell levering og jevnlige brukertester

DEL 4: Kravspesifikasjon for systemet Oppgave 4a: Gi 10 eksempler på brukerhistorier. Nevn minst tre forskjellige aktører. Sett brukerhistoriene opp i en prioritert liste basert på hva som er viktigst for sluttproduktets funksjonalitet.

DEL 4: Kravspesifikasjon for systemet Løsningsforslag 4a: Forslag på 10 brukerhistorier: - Syntaks Som <aktør> ønsker jeg <funksjon> for å oppnå <nytteverdi> - Skal uttrykke et krav til systemet: - Funksjonelle og ikke-funksjonelle - Nytteverdi er viktig fordi man gjerne ønsker å prioritere - Hvilke krav er viktig å implementere tidlig? - Hvilke av disse uttrykker kritisk funksjonalitet?

DEL 4: Kravspesifikasjon for systemet Løsningsforslag 4a: Forslag på 5 brukerhistorier: Eksempler: 1. Som kunde ønsker jeg å se oversikt over hvilke typer sykler det er på hver stasjon, slik at jeg vet at ønsket type er ledig. 2. Som kunde ønsker jeg et GPS-system som måler tidsforbruk og turlengde slik at jeg kan sammenligne med tidligere turer. 3. Som kunde ønsker jeg å se oversikt over hvor det er ledig plasser slik at jeg kan planlegge hvor jeg kan sette fra meg sykkelen. 4. Som kundebehandler ønsker jeg et effektivt system slik at jeg kan gi kundene best mulig behandling. 5. Som eier ønsker jeg å se omsetning slik at jeg får en oversikt over inntekter.

DEL 4: Kravspesifikasjon for systemet Oppgave 4b: Sett opp en liste over 10 funksjonelle krav som dere ønsker å stille til systemet.

DEL 4: Kravspesifikasjon for systemet Oppgave 4b: Sett opp en liste over 10 funksjonelle krav som dere ønsker å stille til systemet. Løsningsforslag: Forslag på 5 funksjonelle krav: 1. Systemet skal kunne generere oversikt over mest brukte stasjoner. 2. Systemet skal via en GPS-løsning gi kunden informasjon om tidsbruk og rute. 3. Systemet skal benytte seg av Ruters betalingsløsninger. 4. Systemet skal lage oversikt over sykler som ikke blir levert i tide. 5. Systemet skal kunne vise informasjon om hvilke sykler som er på hvilke stasjoner.

DEL 4: Kravspesifikasjon for systemet Oppgave 4c: Sett opp en liste over 10 ikke-funksjonelle krav som dere ønsker å stille til systemet. Del opp kravene i produktkrav, organisatoriske krav og eksterne krav, og få med minst to krav av hver type.

DEL 4: Kravspesifikasjon for systemet Løsningsforslag 4c: Forslag på ikke-funksjonelle krav: Produktkrav 1. Nettsiden skal kunne håndtere opptil 5.000 samtidige brukere. 2. Systemet skal kunne håndtere opptil 1.000 samtidige utlånere av sykler. Organisatoriske krav 3. Systemet skal holde et budsjett på maks 30 millioner norske kroner. 4. Systemets brukergrensesnitt skal utvikles ved hjelp av smidige utviklingsmetoder. Eksterne krav 5. Systemet betalingssløsning må følge Ruters krav til samarbeidspartnere. 6. Systemet skal følge personopplysningsloven.

DEL 4: Kravspesifikasjon for systemet Oppgave 4d: Forklar hvordan de ikke-funksjonelle kravene skal evalueres.

DEL 4: Kravspesifikasjon for systemet Løsningsforslag 4d: Forslag på hvordan de kravene kan evalueres: 1. Nettsiden skal kunne håndtere opptil 5.000 samtidige brukere. Test: Evalueres ved hjelp av stresstest 2. Systemet skal kunne håndtere opptil 1.000 samtidige utlånere av sykler. Test: Evalueres ved hjelp av stresstest 3. Systemet skal holde et budsjett på maks 30 millioner norske kroner. Test: Direkte målbart: ja/nei-spørsmål 4. Systemets brukergrensesnitt skal utvikles ved hjelp av smidige utviklingsmetoder. Test: Direkte målbart: ja/nei-spørsmål 5. Systemet betalingssløsning må følge Ruters krav til samarbeidspartnere. Test: Krever ekspertise innenfor temaet 6. Systemet skal følge personopplysningsloven. Test: Krever ekspertise innenfor temaet: noen som kan sjekke lovgivningen

DEL 5: Use case for systemet Oppgave 5a: Tegn et use case-diagram som inkluderer alle nødvendige use case som trengs for å oppfylle de funksjonelle kravene som ble spesifisert i oppgave 4. Ta med alle involverte aktører (både primære og sekundære).

DEL 5: Use case for systemet Oppgave 5b: Lag en tekstlig beskrivelse til et av use casene du foreslo i oppgave (a). Ha med pre- og postbetingelser og minst to alternative flyt.

DEL 5: Use case for systemet Løsningsforslag 5b: Forslag på en tekstlig beskrivelse. Navn: Registrere ny bruker via nettside Prebetingelser: Ingen Postbetingelser: Ny bruker opprettet i systemet Hovedflyt: 1. Bruker velger registrer ny bruker 2. Systemet ber bruker om å oppgi navn, tlfnr, alder og mailadresse 3. Bruker skriver inn informasjon 4. Systemet validerer informasjonen 5. Systemet ber bruker om å opprette passord 6. Bruker skriver inn valgt passord 7. Systemet validerer passord 8. Systemet legger inn bruker i systemet 9. Systemet sender bekreftelse på skjerm og mail

DEL 5: Use case for systemet Løsningsforslag 5b: Forslag på en tekstlig beskrivelse. Navn: Registrere ny bruker via nettside Prebetingelser: Ingen Postbetingelser: Ny bruker opprettet i systemet Alternativ flyt, steg 4: Ugyldig tlfnr. A4.1. Ugyldig tlfnr, for få siffer A4.2. Systemet ber bruker taste inn tlfnr på nytt A4.3. Bruker taster inn tlfnr A4.4. Returnerer tilbake til steg 4 Alternativ flyt, steg 7: Ugyldig passord. A7.1. Ugyldig passord, mangler vanskelighetsgrad A7.2. Systemet ber bruker taste inn et annet passord A7.3. Bruker taster inn passord A7.4. Returnerer til steg 7

OBLIG 5

Neste (og siste) gruppetime: 26. mai - Gjennomgang av oblig 5 (løsningsforslag) - Gjennomgang av prøveeksamen - Tips og triks til eksamen

Takk for meg