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

Transkript

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

2 Hva skal vi i dag? OBS!! Siste ordinære gruppetime Kontrakter Ukesoppgaver Gjennomgang av oblig 4

3 Kontrakter Kompetansemål - Kontrakter - I plandrevet utvikling - I smidig utvikling - Behov for smidige kontrakter - Kontraktsmodeller - PS2000

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

5 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

6 UKESOPPGAVER

7 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

8 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

9 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

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

11 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

12 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

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

14 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

15 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

16 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

17 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

18 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

19 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

20 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

21 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

22 OBLIG 4

23 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?

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

25 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

26 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

27 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.

28 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

29 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

30 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

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

32 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.

33 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.

34 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

35 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

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

37 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

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

39 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

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

41 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

42 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.

43 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`?

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

45 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

46 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.

47 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?

48 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.

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

50 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.

51 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.

52 DEL 4: Kravspesifikasjon for systemet Løsningsforslag 4c: Forslag på ikke-funksjonelle krav: Produktkrav 1. Nettsiden skal kunne håndtere opptil samtidige brukere. 2. Systemet skal kunne håndtere opptil 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.

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

54 DEL 4: Kravspesifikasjon for systemet Løsningsforslag 4d: Forslag på hvordan de kravene kan evalueres: 1. Nettsiden skal kunne håndtere opptil samtidige brukere. Test: Evalueres ved hjelp av stresstest 2. Systemet skal kunne håndtere opptil 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

55 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).

56

57 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.

58 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

59 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

60 OBLIG 5

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

62 Takk for meg