Systemer, krav og konsekvenser (oblig1)

Vipps
Uppgift 1.

Beskriv i tekst en sluttbruker av systemet du har valgt. Det kan være deg selv eller
noen du kjenner. Beskriv hvor ofte vedkommende bruker systemet, fra hvilke
terminaler (smarttelefon, bærbar PC, nettbrett, annet) systemet brukes, og hvilke
motivasjoner sluttbrukeren har for å anvende systemet. Beskriv også hva som er
viktige funksjoner for brukeren. a)

Brukaren jag valde för denna uppgift är mig själv. Jag är en ny brukare av vipps tjänsten,
och jag måste säga att hittills är jag väldigt nöjd. Jag och samt dem allra flesta som brukar
denna tjänst använder den på sin mobiltelefon (Android) minst en gång om veckan oftast om
helgerna. Motivationen till att använda tjänsten är dess universalitet, då alla jag känner samt
flera andra tjänster som är (nästan) nödvändiga för mig brukar vipps som ett betalningssätt
(ruter f.ex.). Den viktigaste funktionen av vipps är nog den mest fundamentala funktionen; att
kunna snabbt och säkert föra över pengar till vänner eller tjänster.

Beskriv i tekst hvem du antar er interessenter i systemet, utover sluttbrukeren fra

oppgave 1a. Få med både individer, grupper og organisasjoner samt hvilke interesser
disse har i utviklingen og bruken av systemet. b)

Jag tycker att de främsta intressenterna av vipps tjänsten är bankerna, privatpersonen,

företagsägare, vipps AS och eventuellt den norska staten. Privatpersonen samt
företagsägare delar delvis samma intressen när det gäller vipps tjänsten, de bägge
använder vipps för att förenkla transaktioner. Skillnaden är bara att företagsägaren använder
den till att möjliggöra enkla transaktioner mellan företaget och enkelpersonen, priset för detta
är en procentuell ränta per varje transaktion. Därför är även vipps AS samt dess ägare
(bankerna) som tjänar pengar av varje transaktion som utförs vid bruk av tjänsten. Norska
staten däremot är en intressant eftersom vipps hjälper ekonomin växa, eftersom det är ett
enklare sätt att spendera pengar på, dvs. pengarna cirkulerar mer i ekonomin som bidrar till
mera skatt.

Tegn et rikt bilde for systemet du har valgt. Det rike bildet skal inkludere
interessentene fra oppgave 1b. Det rike bildet skal illustrere de ulike interessentenes
interesser (eng. concerns) samt relasjonene mellom interessentene (og systemet).
Bruk hjerter for å illustrere positive
c)
 Rike bilder kan brukes til å identifisere konflikter eller motsetninger mellom
interessentenes ulike perspektiver. Ta utgangspunkt i interessentene og deres
interesser som du beskrev i oppgave 1b, samt det rike bildet du tegnet i oppgave 1c.
Beskriv med egne ord de positive relasjonene samt de konfliktene eller
motsetningene du eventuelt har identifisert. Hvordan tror du dette kan påvirke
systemutviklingsprosessen og/eller bruken av systemet? d)

Jag har tagit en utgångspukt i slutbrukaren, alltså privatpersonen. Här ser vi två olika
perspektiv, det ena av den “vanliga” brukaren och det andra av den “äldre” brukaren. Ålder
enligt mig spelar stor roll när det gäller perspektiv, då den “vanliga” brukaren är väldigt glad i
vipps då tjänsten gör dess transaktioner mycket enklare. Medan den “äldre” brukar kan ha
svårigheter med att registrera sig på appen samt bruka den vardagligt. Därför kan även den
“äldre” brukaren hamna i konflikt med tjänsten då den brukas mer och mer vardagligt ju tiden
går. Konsekvensen av detta kan bli att utvecklingen av vipps kommer att gå åt retningen av
att göra den mer tillgänglig samt (ännu) enklare i bruk för de äldre brukarna. Andra positiva
relationer är mellan vipps och företagsägare samt den norska staten. Den norska staten vill
inte att folk håller deras pengar sparade i ett sparkonto, och vipps gör det enklare för dem att
spendera dessa pengar, som i sin tur håller pengarna i cirkulation som bidrar till mer skatt
som går till staten. Privata företagsägaren däremot, bryr sig väldigt mycket om att det ska
vara enkelt för folk att spendera pengar på dess tjänst, därför har även han en positiv
relation till vipps AS, som gör det enkelt för folk att skicka små summor av pengar snabbt
och riskfritt. Symbiosen i detta förhållande är att företagsägaren betalar en liten avgift för
vipps tjänsten förutsatt att den omsätter mer än 10 miljoner NOK per år genom vipps
tjänsten.

Uppgift 2
Les notatet Samspill (se pensum). Velg én av de ti påstandene i dette notatet, og drøft
dine tanker om samspill relatert til denne påstanden. Argumenter for og/eller imot
påstanden med minst tre eksempler, gjerne basert på egne erfaringer med bruk av
teknologi. a)

Disse interessentene deltar i (sam)spillet med ulike ressurser, de har ulike motiver og de får
ulike gevinster av å involvere seg. Detta påståendet stämmer, och det kan man se om man
ser på exemplet med vipps. Å ena sidan har vi enkel brukaren som bryr sig inte om bolaget
utan snarare om tjänsten. Medan å andra sidan har vi shareholders/ägarna alltså bankerna,
de måste nästan bry sig om allt, både brukarna och bolaget, då de vill se vinst som ett
resultat av deras investeringar. Detta exemplet visar hur olika aktörer anknyter sig olikt
mycket med tjänsten baserat på vilket perspektiv de har, eftersom ägarna riskerar att förlora
pengar om bolaget går i konkurs, må de engagera sig mycket mer än en brukare som bara
vill bruka tjänsten.

Kunnskap om hvordan teknologi har utviklet seg over tid kan være nyttig når man
skal løse eksisterende eller nye utfordringer. Nyskapning gjennom det å kunne
forestille seg hvordan noe kan være annerledes forutsetter ofte en fremtidsvisjon. De
siste årene har det blitt vanligere med netthandel (Oda, Vy) samt strømmetjenester for
både musikk og video. Dette endrer adferdsmønstrene våre og vår forståelse av det å
handle eller konsumere underholdning. Diskuter hvordan digital teknologi kan påvirke
hverdagen og dermed endre samfunnet. Diskuter gjerne problemstillingen ut fra flere
perspektiver og bruk eksempler. b)

Mänsklighetens moderna tillgång till teknologi och därmed underhållning är en sak vi kunde
förr bara drömt om. Faktumet att vi kan med ett par clicks bli underhållna i timmar är allt
förutom naturligt, som i sin tur har eller kan ha en rad negativa konsekvenser för oss. Snabb
underhållning i form av Tiktok, Youtube, Twitch etc., tjänster som fångar in dig snabbt och
förväntar dig att inte stanna på samma video längre än bara ett par minuter eller sekunder
kräver väldigt lite uppmärksamhet för att bruka. Det har redan blivit visat att ungdomar får
kortare och kortare uppmärksamhet intervaller, då de har blivit vana till de snabba
“belöningarna” av dessa tjänster. Förr i tiden var man tvungen att spendera lång tid innan
man fick se sin favoritfilm eller se på en show för att få sin artificiella dos av dopamin, en dos
som nu kan fås med hjälp av ett par clicks under sekunders tid. Detta är inte särskilt bra om
man ska faktiskt använda hjärnan på ett akademiskt sätt, jag själv känner att det kan vara
svårt ibland att fokusera på föreläsningen, och istället sitter jag hellre på mobilen. Därför är
snabbt tillträde till sociala medier eller andra tjänster väldigt farligt för en person som måste
kunna fokusera i långa perioder av tid för att lyckas. Dessvärre ger denna åtkomsten till
sådana tjänster en större exponering för reklamer. Detta är en dålig konsekvens eftersom
aldrig förr har stora korporationer haft sådan makt över unga och enkelt manipulerade
ungdomar som idag. Dessa reklamer är trots allt inte gjorda för att gynna individens
utveckling på något sätt, utan snarare få företaget att tjäna pengar. Därför påstår jag att en
ökad exponering för reklamer minskar ungdomars förmåga att tänka självt och rationellt, och
ökar mängden folk som kommer att blint tro vad andra säger istället för att tänka själv. I
slutsats, tycker inte jag att snabb åtkomst till sociala medier eller underhållning är någonting
bra för oss människor, det går direkt emot vår natur och hjärnans hormonsystem, därför
hoppas jag även på att denna åtkomst kommer att minska så att vi förebygger framtida
problem.

Hvorfor mener du det er viktig å kunne drøfte samspillet mellom teknologi og

individer, organisasjon og samfunn? Skriv minst tre argumenter. c)

Det är väldigt viktigt för utvecklare och projektledare att aktivt modellera och förutse
relationerna mellan brukare och system. Man kan inte simpelt programmera någonting och
blint släppa ut det i marknaden och detta är anledningarna varför: Först och främst så måste
man veta ungefär hur folk kommer att reagera till din produkt, det handlar delvis om user-
experience men även måste man lägga lite fokus på de övriga intressenterna av din tjänst.
Dessa kan vara shareholders men även staten i lander du opererar i samt lagen. Om man
redan vet hur folk kommer att reagera till din produkt i förtid, kan du lätt göra ändringar innan
det är för sent, dvs. utan att förstöra din reputation. Med en god reputation är det lättare att
attrahera investerare, men även lojala kunder. Dessutom kan försiktig planering och
modellering av din produkt öka kvaliteen av produkten, vet du redan vissa saker som bör
ändras i förtid, kan du lättare göra ändringar som du skulle ändå införa förr eller senare, bara
billigare och snabbare. När ditt system ännu inte är implementerat, finns det inte lika mycket
stress över att ändra på saker. Sist men inte minst, är det viktigt att upptäcka potentiella
problem i ditt system före det är implementerat, det kan innebära lagliga fel eller bara
generella problem med systemet självt. Inte bara leder denna modellering till en ökad kvalite
av din produkt då den är närmare till att vara felfri, utan det sparar enn del av pengar och
resurser som kan istället ägnas till utveckling. Då som tidigare nämnt, problem som upptäcks
i förtid kostar mindre pengar och tid. I slutsats är modellering ett väldigt bra, förebyggande
verktyg som kan avgöra om en tjänst överlever eller dör i förtid.

Obligatorisk oppgave 2: Bruk og brukerundersøkelser

Oppgave 1 - Observasjon av bruk

a) Planlegg datainnsamlingen. Beskriv følgende:

Vipps:
 - Jag förväntar mig att testa ut funktionaliteten av vipps mobilapplikation och potentiellt hitta
något/några sätt att förbättra denna funktionalitet på. Även kommer jag vela ta reda på hur
deltagaren brukar applikationen och lite om deras vanor om att betala med hjälp av vipps.

- Målgruppen till systemet tror jag omfamnar dem allra flesta människor som har hand om
sitt eget bankkonto, exempelvis 15-95, men eftersom dem som använder systemet som
mest är unga vuxna mellan 18-28, väljer jag denna åldersgruppen att representera
målgruppen i undersökelsen.

- Uppgifterna är följande;
- Logga in på appen genom att bruka personlig kod eller scannaren.
- Skicka en förfrågan på 1kr till en valfri person.
- Skapa en grupp på 3 personer.
- Hitta dina personuppgifter.
- Ändra till “dark theme”
- Deltagaren är en del av målgruppen, och har en väldigt god relation till mig (planeraren).
Detta påverkar mest troligt inte undersökelsen, då vipps är inte lagad av mig och deltagaren
har lovat att vara ärlig med mig. Men hade jag varit en utvecklare hos vipps, hade detta nog
varit relevant, då resultaterna hade varit biased.

b) Elektronisk behandling av personopplysninger blir regulert i

Personopplysningsloven. Forklar hvorfor vi har samtykkeskjema ved undersøkelser
av bruk.

Jag vill registrera data på ett google docs dokument, denna informationen kommer att
raderas så fort undersökelsen är färdig. Samtyckescheman är viktiga vid undersökelser då
de skyddar deltagaren från olaglig hantering av dess data, men det ger även ett lagligt sätt
för företag och skolor att utföra undersökelser på. Samtycktescheman ger deltagaren en
direkt översikt kring hur dess data kommer att användas, samt dess egna rättigheter.

c ) Utform et samtykkeskjema tilpasset din undersøkelse som du legger ved

besvarelsen din. Obs: inkluder samtykkeskjema uten navn/underskrift fra deltaker i
PDF-filen du leverer
d) Gjennomfør en pilotundersøkelse av den planlagte datainnsamlingen. Rapporter
kort hva du erfarte. Hvilke lærdommer tar du med deg til hovedundersøkelsen?
Beskriv eventuelle modifikasjoner på planen og modifiser planen før
hovedundersøkelsen.

Jag tyckte att pilotundersökelsen gick bra, man hade kunnat se lite mer på djupet av de olika
funktionerna, men i grunden täckte undersökningen nästan alla stora områden av vipps
appen. En modifikation av metoden hade varit att potentiellt se lite djupare på inställningarna
och se hur enkelt det är att hitta rätt inom inställningarna - se på djupet. Lärdomarna jag tar
med mig till huvud undersökningen är att jag behöver se lite mer på djupet av programmet
för att verkligen kunna hitta möjliga förbättringar

e) Gjennomfør hovedundersøkelsen (observasjonen). Rapporter kort fra

undersøkelsen, hvilke erfaringer og innsikter fikk du? Husk å ta et ikke identifiserbart
bilde for å dokumentere gjennomførelsen. Legg til det sensurerte bildet i PDF-filen du
leverer.
Resultatet av huvudundersökelsen var att vipps generellt sagt är en väldigt bra app.
Den är simpel i bruk och väldigt svår att tappa sig bort i, den använder fina “tillbaka-pilar”
och allt är på den plats man förväntar sig att dem ska vara på. Också var applikationen
designad till att man ska lätt kunna ha åtkomst till majoriteten av funktionerna med bara ett
få klicks, då vipps applikationen inte är så komplex, och innehåller kategorier av grensesnitt

Oppgave 2 - Analyse: Sekvens av handlinger

a) Les gjennom notatet ‘Sekvens av handlinger mellom menneske og maskin’. Forklar

hva formålet med tabellen er, og hva som skal føres inn i de ulike kolonnene. Bruk
gjerne eksempler

Föremålet till sekvenstabellen är att enklare kunna representera interaktionen mellan

människa och maskin, eftersom inte alla delar av brukarupplevelsen är märkbara av en
människa, måste även maskinens interaktion med människor beskrivas. Sekvenstabeller
hjälper med detta, då de innehåller 2 huvudkolumner för människa samt maskin, sedan
innehåller den 4 subkolumner, 2 som ingår i “brukare” och 2 för “maskin”. Dessa kolumner
beskriver; “handling inte synlig för maskin”, “handling synlig för maskin” för brukaren och
“effekt synlig för brukaren” och “design rationale”. Handling inte synlig för maskin beskriver
brukarens baktanke kring uppgiften dem fick av observatören tex: “hmmm, var finner jag
denna funktionen”. Handling synlig för maskinen är input, det brukaren trycker på eller
skriver in för att komma till den teoretiska funktionen. Handling synlig för brukaren är output,
det brukaren får upp eller ett tillbakameddelenade. Sist är syftet med design rationale för att
beskriva det som sker bakom kulisserna inne i mjukvaran, till exempel att inputen matchar
informationen i ett register osv.

Bruk observasjoner du gjorde i oppgave 1. Velg én eller flere av oppgavene du ba

deltakeren om å utføre, og beskriv sekvensen(e) ved hjelp av tabellen fra Sekvens av
handlinger mellom menneske og maskin.
Analyser tabellen du fylte ut i oppgave 2b. Hvordan oppfatter du interaksjonen mellom
bruker og system? På hvilke måter kan interaksjonen forbedres eller bli gjort
annerledes?

Nu när jag har istället fått analysera sekvenstabellen, hade man kunnat göra den “kortare”
dvs. komma fram till rätt ställe vid bruk av färre klicks. Istället för att ha inställningar under
“profil”, hade man kunnat ha en liten ikon bubbla som representerar inställningar, då hade
denna uppgiften kunnat skett i ett färre klick än det gjorde. Däremot är inte ändringen av
theme färg en central del av vipps applikation, samma gäller för åtkomst till inställningar,
därför kan jag även förstå den nuvarande design valet.

Obligatorisk oppgave 3: Lover og etikk

Oppgave 1 - Universell utforming

a) Se videoen Ein introduksjon til universell utforming som du finner nederst på siden
her:
https://www.uutilsynet.no/veiledning/hvordan-jobbe-med-universell-utforming/245

1. Använd dig utav hög kontrast mellan text och bakgrund. Det är viktigt för folk att lätt kunna
läsa din text, därför ska texten även vara lättläslig genom att ha hög kontrast mellan texten
och bakgrunden som den befinner sig på. Folk med färgblindhet kan ibland ha det svårt att
skilja åt färger som är lika varandra, därför är det viktigt att inkludera dessa människor
genom att bruka hög kontrast. Ofta är vit text på en mörkare bakgrund en bra lösning.

2. Använd tydliga bildtexter som beskriver bilder precist, det gör det enklare för tex. blinda
människor att få en översikt över vad bilden visar genom en textläsare. Till exempel om man
har en bild på en katt, så kallar man bilden för katt.jpeg och bildtexten kan vara; “En bild på
en katt”.

3. Ge brukaren kontroll över att byta textstorlek och färg på hemsidan, detta kan vara viktigt
för universell utformning då alla människor kan inte läsa text som är liten. Detta kan man
implementera genom att ha en navigation bar med olika inställningar på sidan, till exempel
en för dark theme eller för större text.

Velg ut tre av de 24 tipsene som presenteres i videoen, og forklar disse tre. Bruk
gjerne eksempler for å illustrere hvordan disse kan implementeres i praksis. b)
Forklar med egne ord de fire WCAG 2.1 prinsippene.

Velg deretter ut og beskriv én retningslinje for hver av de fire prinsippene. Bruk
eksempler for å illustrere hvordan dette kan brukes i praksis. Den norske
oversettelsen av WCAG 2.1 finner du her:

1. Perceivable - att brukaren har möjligheten att förstå all information visad i applikationen
samt, alla grensesnitt som programmet brukar. Detta kan göras till exempel vid bruk av ett
text-to-speech program implementerat i applikationen, så att blinda människor kan även ha
åtkomst till informationen i applikationen.

2. Operable - Brukaren ska kunna bruka applikationen och dess funktioner, dvs.
applikationen ska inte kräva rörelser som inte alla kan utföra för att bruka applikationen.
Detta görs genom att ha stora och lätt tillgängliga knappar på skärmen till exempel, och/eller
genom att inte ha alldeles för svåra (att utföra) “i am not a robot” checker.

3. Understandable - Brukaren ska kunna förstå vad som står på brukargränsesnittet,

applikationens innehåll och vilken funktionalitet funktionerna utför. Detta görs genom att
anpassa språket i programmet till vardagligt språk, så att dem allra flesta förstår. Att inte
använda sig utav ämnesrelaterat språk, dvs. “programmerar språk”. I denna kontexten är det
viktigt att även brukaren ska kunna uppfatta informationen, som tidigare nämnt kan detta
göras via implikationen av ett text-to-speech program.

4. Robust - Brukaren ska kunna lätt interpretera informationen på sidan trots att den
utvecklas teknologiskt. dvs. att innehållet av applikationen ska kunna lätt tolkas i framtiden
av alla trots att sidan uppdateras. Detta görs genom slippa göra val som antingen väljer
funktionalitet eller universell utforming, designet av applikationen ska inte vara tvunget att
välja det ena eller det andra, utan dessa beslut om design ska alltid gå parallellt med
universell utforming. Detta kan göras genom att ständigt uppdatera sitt text-to-speech
program i samband med nya design implementationer.

https://www.w3.org/Translations/WCAG21-no/

Beskriv formålet med en tilgjengelighetserklæring.

Syftet med en tillgänglighetförklaring är att låta brukaren veta vad de kan förvänta sig att
webbsidan eller applikationen gör den tillgänglig för vem/vilka. Det är en beskrivning på hur
tillgänglig sidan eller applikationen är och vad det innebär. Detta görs så att folk med
störningar eller andra problem kan lätt se om webbsidan eller applikationen dem är på
stötter deras hindring.

Beskriv disse begrepene (minimum én setning for hvert begrep):

Universell utforming - Det är hänsyn som man tar vara på i designen av en hemsida eller
applikationen så att alla kan ha tillgång till informationen av tjänsten. Detta görs ofta i form
av programmer som kan spela upp ljud av texten som står på tjänsten.

Inkludering - Inkludering betyder att få med alla typer av människor, i detta fallet- att få med
alla typer av människor med i tjänstens funktionalitet. Dvs. att alla möjliga människor med
alla möjliga funktionsnedsättningar, ska vara inkluderade i möjligheten av att bruka tjänsten.

Tillgänglighet - innebär att någonting ska vara tillgängligt, att till exempel att kunna ha
tillgång till dina personuppgifter på en hemsida sådan som tex. Helsenorge.no.

GAP- modellen - är en modell som beskriver förhållandet mellan en individs

funktionsförmåga i jämförelse med samhällets krav för funktionalitet. Samhällets krav kan
vara att kunna operera en hemsida, men om individen inte kan utföra denna funktionen,
finns det ett “gap” mellan förväntningar och verklighet. Man kämpar emot detta “gapet”
genom att minska kravet för funktion i bruket av hemsidan.

I denne oppgaven blir du invitert til å reflekterer over hva tilbakemelding (engelsk:
feedback) betyr for deg med tanke på inkludering og universell utforming i en
studiesituasjon.

Feedback ansikte mot ansikte kan medföra problem för vissa människor med vissa speciella
funktionshinder, speciellt om den som ger feedback inte har blivit utbildad i teckenspråk osv.
Vid tillfället då det inte finns en person som kan teckenspråk, kan personen som får
feedback bli excluderad från att få feedback över huvud taget. Därför vis man ska ge mer
seriös feedback, kan det vara lurt att ha någon som kan teckenspråk på tex. arbetsplatsen
eller skolan, alltså finns det lösningar på denna excluderingen, men en som inte gäller för
alla fall.

Feedback via digitala medel som zoom, teams eller mail är mer inkluderande, då man kan
bruka en textläsare för att läsa texten på skärmen, samt bruka chattfältet vis man inte kan
höra bra. De programmerna är säkert inte helt perfekt universellt utformade, men de
möjliggör enkel åtkomst till information, då zoom tex. är väldigt enkelt designat

Därför hade jag sagt att dataprogram sådana som zoom tex. gör det enklare för
funktionshindrade människor att få lätt åtkomst till information eller feedback genom, då man
inte behöver en tolk som kan tolka till teckenspråk, utan ett program gör det åt en.

Oppgave 2 - Personopplysninger

a) Les artikkelen om Folkeopplysningen og hvordan informasjonen Facebook lagrer

om deg kan bli misbrukt.
Se deretter Youtube-klippet om hvordan Cambridge Analytica brukte
personopplysninger.

Lenker til artikkelen og dokumentaren finner du nedenfor. Beskriv problemstillingene

som tas opp i artikkelen og Youtube-klippet og drøft deres relevans.
Artikkel: https://www.nrk.no/dokumentar/xl/ble-manipulert-etter-nrk-spionering-pa-
hans-digitale-liv-1.1 4759796
Video: https://www.youtube.com/watch?v=VDR8qGmyEQg

) Problemställningen i artikeln är lite annorlunda från den i youtube klippet, då artikeln

baserar sig på hur lätt det är att ta reda på saker om en person bara baserat på personens
vanor på internet. Medan youtube klippet beskriver hur facebook kan exploateras och varför
det är ett problem. På sätt och vis är de relaterade till varandra eftersom de både handlar om
personlig data, artikeln är ett indirekt bevis på det som sägs i klippet. Relevansen av artikeln
och klippet är väldig stort, då det är relevant att folk ska veta hur lätt det är att ta reda på
information om folk, så att fler människor kan välja att inte bruka facebook eller andra sociala
medier som inte hanterar deras insamlad data på rätt sätt.

Se for deg at du tar opp lyd eller tar bilde i en av gruppetimene dine. Er det nødvendig
å informere de som er tilstede om opptaket? Og i så fall hvordan ville du gått fram?

Om man ska filma folk måste dem först godkänna att denna filmningen råder plats om deras
ansikten är synliga på videon. Därför är det nödvändigt att dem samtycker till denna filmning
då en bild på en person är en personuppgift. Istället kan man få muntligt samtycke till att
filmningen ska kunna råda plats, eller “radera” ansiktena genom att bruka ett mosaic filter på
de berördas ansikten.

En IT-bedrift som behandler personopplysninger beslutter å legge lagring og

behandling av personopplysninger til en skytjeneste lokalisert i utlandet.
1) Er dette lov ifølge Personopplysningsloven? Husk å henvise til lovverket.

2) Hva må bedriften gjøre for å kunne outsource lagring og behandling av

personopplysninger?

1. Det är inte lagligt för en databehandlare att plötsligt engagera en annan databehandlare
till att lagra och bearbeta dess data utan ett tidigare skriftligt avtal angående detta. Enligt
personopplysningsloven, kapitel 4, artikel 28, paragraf 2.

2. Företaget måste ingå i ett databehandingsavtal med det externa cloud-företaget. Det
gäller säkerhet av datan samt hur de blir behandlade och använda. Då datan inte längre
ligger i IT-företaget utan i en cloud-service, så är det cloud servicen som är ansvarig för att
personupplysningarna blir behandlade på rätt sätt, därför har man detta avtalet.

Finn frem til personvernerklæringen til det systemet du jobbet med i Oblig 1 og Oblig
2 (Vipps, Vy, Oda, eller Yr). Hvem kan brukerens personopplysninger utleveres til?
Det holder å nevne to interessenter/aktører i denne oppgaven. Hvis det er vanskelig å
finne konkrete interessenter/aktører reflekterer du rundt hva dette har å si for
brukeren.

Vipps behandlar deras kunders personupplysningar på sådant sätt så att de förebygger

straffbara handlingar, det innebär att vis det är nödvändigt, så delar Vipps en kunds
personupplysningar till Politin. Politin är en direkt intressant av detta, då de vill att vipps
säger till när någon bryter lagen via deras tjänst så att de kan fånga den personen och
straffa den. Detta är nyttigt för politin då det ger en förhoppning att färre människor kommer
att begå liknande brott vis någon har blivit fångad för det. Dessutom samlar vipps data om
dig för att senare bruka den datan i marknadsföring, intressenterna i detta fallet är företag
som passar din “personlighet” så att de kan visa dig anpassade reklamer som du har större
odds att trycka och köpa deras produkt.

Oppgave 3 - Digitalisering, automatisering og etisk refleksivitet

a) Se filmen om etiske dilemma ved programmering av førerløse biler av Patrick Lin

(4:15 min). Redegjør først for dilemmaet, og drøft deretter mulige tilnærminger for å
jobbe med dette dilemmaet. Filmen finner du her:

https://www.youtube.com/watch?v=ixIoDYVfKA0.

Filmen om av Patrick Lin visar ett viktigt etiskt dilemma där en självkörande bil ska göra ett
beslut, låta föraren av bilen hamna i fara, eller välja mellan två andra bilister att hamna i fara.
Detta är ett svårt dilemma då man inte längre kan skylla på att handlingen var en mänsklig
reaktion, då bilen är styrd av en AI. Vem är ansvarig vis en AI dödar någon? Eller vem
bestämmer vilka beslut en AI ska utföra? Hur löser man då detta dilemmat? Jo, man
behöver tydligt avgöra vem som juridiskt står till felet vis en sådan situation sker. Jag tycker
personligen att det borde inte straffa en AI på samma sätt som en människa, alltså behöver
man ha ett helt separat lagverk för sådant. Men när det gäller att maskinen ska aktivt begå
“goda” etiska beslut, borde man programmera den på liknande sätt som en människa hade
tänkt, att den ska först och främst skydda passagerarna i bilen och sedan tänka på vem som
kommer bli skadad som minst vis en olycka sker. Detta minimaliserar både skador på
mänskligheten i det hela samt som skyddar “sig själv” genom att skydda passagerarna i
bilen.

Hva menes med etisk refleksivitet?

Etisk reflexivitet är det jag gjorde nu, just att reflektera kring etiska frågor. Det var även syftet
av videon, att stress-testa sina egna etiska värden och kanske till och med lära sig hur man
skulle reagerat angående andra etiska frågor

Obligatorisk oppgave 4: Foranalyse og kravhåndtering

Oppgave 1 a)

Nevn minst 3 fordeler og minst 3 ulemper ved å utvikle et nytt system i forhold til å
benytte seg av det allerede eksisterende systemet.

Fordeler: 1. Den største fordelen jeg vil ta opp er at man får skreddersydd opplevelsen så
mye man ønsker for brukerne.

2. Man kan også tilby en helt unik opplevelse til kunder og markedsføre tjenesten som dette
og dermed oppleve større interesse.

3. Ved å bruke et egetutviklet system kan man også fritt oppdatere det og komme med nye
løsninger for å gjøre det mer lettvint og raskere å bruke uten å være avhengig av at en
ekstern part gjør dette.

Ulemper: 1. En ulempe er at kunder som er vant til det eksisterende systemet kan ha
vanskeligheter med å bruke det nye systemet.

2. En annen ulempe er at de ansatte må lære et helt nytt system, og det kan føre til
forsinkelser for kundene.

3. Systemet de bruker nå blir også brukt av andre kinoer, ved å ha et nytt system kan det
være vanskeligere for kunder fra de andre kinoene å prøve noe nytt.

b) Basert på fordelene og ulempene dere fant i oppgave b, ta stilling til om dere ville
valgt å benytte dere av det eksisterende systemet eller utviklet et nytt system.
Begrunn svaret.

Ettersom Virtuoso Kino skal tilby en opplevelse som ingen andre kinosaler tilbyr, tenker vi at
det hadde vært best med et nytt system som er tilrettelagt de nye tjenestene. De burde
fremdeles ta hensyn til at de eksisterende kundene deres er vant til det gamle systemet og
kanskje ikke er interessert i de nye tjenestene og derfor gjøre det like enkelt som før å kjøpe
en standard billett.

Oppgave 2 a) Hva er forskjellen på en aktør og en interessent? Bruk gjerne eksempler.

 En interessent er en som kan bli påvirket av systemets utvlikling, et eksempel er at eierenes
interesser kan bli påvirket dersom Virtuoso Kino taper kunder til konkurrenter. En aktør er en
som anvender systemet. En aktør kan dermed også være en interessent, men legger
vanligvis ikke like mange føringer for systemet.

b) Kartlegg minst seks interessenter i systemet til Virtuoso Kino. Få med navn
(eksempelvis “Utvikler”, ikke fornavn), interesse til hver interessent og eventuelt
ansvar interessenten har knyttet til utvikling og/eller drift av systemet. Sett dette opp i
en oversiktlig tabell som inneholder kolonnene: navn, interesse og eventuelt
ansvarsområde.

c) Hvilke av interessentene du fant er også aktører? Gi en begrunnelse for hvorfor.

Alle interessentene er aktører utenom konkurrentene. Det er fordi eiere og andre ansatte,
kunder, utviklere og samarbeidspartnere anvender seg av systemene til Virtuoso. De som
ikke gjør dette og som heller ikke har noen mål ved systemet til Virtuoso er konkurrentene,
ettersom deres fokus er på deres egne systemer.

Oppgave 3

a) Hva er hovedforskjellene mellom plandrevne og smidige prosessmodeller?

Hovedforskjellen mellom smidig utvikling og plandrevet utvikling er at plandrevet følger en

oppsatt plan og at det dermed er vanskeligere å håndtere endringer underveis i
utviklingsprosessen. Underveis i utviklingen prioriteres håndtering av endringer i smidig
utvikling, over å følge en plan til punkt og prikke i plandrevet utvikling. Anvender man smidig
utvikling er altså inkrementell utvikling og korte iterasjoner viktig.

b) Diskuter hovedforskjellene mellom tidsboksbasert tidsflyt (Scrum) og flytbasert

smidig prosessmodell (Kanban). Diskusjonen skal inneholde fordeler og ulemper ved
begge prosessmodellene.

Scrum er en utviklingsprosess som baserer seg på tidsbokser. Med tidsbokser menes det at
oppgaver settes opp til en sprint på et visst antall uker. Kanban er mer orientert mot at
oppgavene jobbes med til de er ferdige. Det er altså et mindre fokus på estimering hvis man
benytter Kanban istedenfor Scrum. Flyten i Kanban fungerer vet at man definerer noen
oppgaver som skal gjøres og leveres så snart de er ferdigstilt. Flyten i Scrum er basert på at
man utformer de viktigste oppgavene og jobber med de i bestemte tidsrammer.

c) I hvilken grad bør man ta høyde for at kravspesifikasjonen til systemet til Virtuoso.
Kino må endres underveis i utviklingen? Begrunn svaret.

Man burde forvente dette ettersom brukernes behov kan endres underveis i utviklingen. Det
kan også være at det er mangler i kravspesifikasjonen, som må endres på, som for
eksempel ting man glemte å ta med eller at det kommer nye krav i WCAG. Det kan også
være at man hadde krav som viste seg å ikke fungere i praksis.

d) Hvilken utviklingsprosess mener du/dere er mest egnet for utviklingen av systemet

til Virtuoso Kino? Trekk gjerne inn teknikker og praksiser fra ulike prosessmodeller.
Begrunn svaret.

Jeg ville argumentert for bruk av Kanban i utviklingen av systemet. Billettsystemet er veldig
viktig og åpenbart kanalen hovedinntekten til kinoen flyter gjennom. Derfor er en grundig
utviklingsprosess hvor man er sikker på at alt får oppmerksomheten og sikkerheten det
trengs viktig.

Oppgave 4 a) Skriv minst seks funksjonelle krav som brukerhistorier for

billettsystemet til Virtuoso Kino. Brukerhistoriene skal være fra minst tre forskjellige
aktører. Sett brukerhistoriene opp i en prioritert liste basert på hva dere anser som
viktigst for sluttproduktets funksjonalitet.

1. Kunde: Ønsker å ha tilgang til billetten sin helt til filmen har blitt vist, dette for å kunne
dobbeltsjekke seteplassering og hva slags billettype de har valgt. Ønsker at billettsystemet
er enkelt å bruke, dette fordi noen kan ha vansker med teknologi, eller trenger et system
som er tilrettelagt for andre type utfordringer.

2. Eier: Ønsker statistikk på hvilke filmer som selger mest, da kan de legge til flere billetter av
den filmen og fjerne billetter for filmer som selger dårlig og eventuelt utvide eller innskrenke
hvor lenge en film vises. De kan også ønske statistikk på hvor mye billetter selger i forhold til
pris og dermed få en peker på hvordan de skal justere prisene.
3. Kundebehandler: Ønsker å kunne hente opp kunders billetter, dette i tilfelle de trenger
hjelp til å hente opp billetten sin. Ønsker en egen oversikt over hvilke seter/type billetter som
er solgt til en film, dette for å være forberedt hvis noen kjøper en billett i kassen.
b) Sett opp en liste over minst fire ikke-funksjonelle krav som dere ønsker å stille til
billettsystemet. Del opp kravene i produktkrav, organisatoriske krav og eksterne krav,
og få med minst ett krav av hver type.

1.Organisasjonskrav: Systemet skal utvikles ved hjelp av Kanban.

2.,3. Produktkrav: Tjenesten skal kunne håndtere 1000 brukere samtidig. Man skal kunne
finne, betale for og motta ønsket billett på under 2 minutter.

4.Eksternt krav: Billetter beregnet for brukere med nedsatt funksjonsevne skal holdes av til
de som kan bevise at de har disse behovene. Dette skal også kunne gjøres like raskt som i
krav 3.

c) Forklar hvordan hver av de ikke-funksjonelle kravene du/dere presenterte i oppgave

4b skal testes.

Krav 1: Dette kravet “testes” ved å simpelthen anvende Kanban når systemet utvikles.

Krav 2: Kravet kan testes ved å simulere at 1000 eller flere bruker systemet.

Krav 3: Kravet kan testes med en brukerundersøkelse, hvor man ber en bruker finne billetten
de ønsker og observere resultatene.

Krav 4: Utvikle en løsning for å bevise behov og utføre en brukerundersøkelse som i krav 3.

Oppgave 5 a) Tegn et use case-diagram som inkluderer alle nødvendige use case som
trengs for å oppfylle de funksjonelle kravene du spesifiserte som brukerhistorier i
oppgave 4a. Ta med alle involverte aktører (både primære og sekundære).
b) Lag en tekstlig beskrivelse av et av use casene du/dere foreslo i oppgave 5a. Ha
med navn på use caset, aktør(er), pre- og post-betingelser og minst to alternative
flyter.

Navn: Tilgang til billett

Aktør: Kunde, og kundebehandler
Prebetingelser: At serveren er oppe
Postbetingelser: At de har riktig innlogging
Alternative flyter:
Flyt 1: Serveren er nede
1. Systemet gir beskjed til kunde/kundebehandler om at serveren er nede
Flyt 2: Feil innlogging
1. Mulighet for å resette passord via mailadresse
2. Kunden/kundebehandleren får mail om forsøk på innlogging i tilfelle det ikke var de

Obligatorisk oppgave 5: Modellering av krav

Oppgave 1 - Klassediagram Lag et klassediagram for det systemet dere planla i

Oblig4. Ta med assosiasjoner med multiplisitet mellom klassene, metoder og
attributter til hver klasse. Dere kan skrive egne forutsetninger, og forenkle der det er
nødvendig. Husk at alle objekter og metoder som kommer frem i oppgave 2 også skal
være med her.

Oppgave 2
a) Lag en tekstlig bekrivelse for brukstilfellet “Kjøp billett som eksisterende kunde”
ved bruk av deres tenkte system. Ha med aktører, hovedflyt og alternativ flyt der
kunden har glemt passordet, og eventuelle pre- og postbetingelser.

Tekstlig beskrivelse av use case

Navn: Kjøp billett som eksisterende kunde
Aktør: Kunde
Prebetingelse: Kunden må være registrert i systemet
Postbetingelse: Riktig innlogging Hovedflyt:
1. Kunde skriver inn brukernavn og passord, og logger inn i systemet.
2. Kunden får opp en oversikt hvor de henter billetten(e) de vil ha.
3. Kunden tas deretter til betalingstjenesten hvor de betaler
4. Kunden får så se billetten(e) på “min side
5. Kunden får tilsendt en kopi på mail.
Alternativ flyt:
Flyt: Glemt passord
1. Mailadressen som er tilknyttet kontoen får en mail med passord
2. Kunden skriver in passordet

b) Lag et sekvensdiagram for brukstilfellet “Kjøp billett som eksisterende kunde” etter
den tekstlige beskrivelsen i oppgave 2a. Bruk de nødvendige klassene og metodene
fra oppgave 1. Ta med alternativ flyt der kunden har glemt passordet. Objekter og
metoder i sekvensdiagrammet skal reflektere klassediagrammet i oppgave 1.
Oppgave 3 a) Hva er karakteristisk for et aktivitetsdiagram, og hvorfor kan det være
nyttig å benytte et slikt diagram?

Et aktivitetsdiagram kjennetegnes ved at stegene i et use-case vises som rektangler og at

beslutninger underveis vises som diamanter. Man benytter et aktivitetsdiagram når man vil
representere hendelsesflyten i et use-case grafisk. Dette er nyttig fordi man kan finne
prosesser som kan kjøre parallelt og er uavhengige fra hverandre, og få en bedre forståelse
for bruksrutinene i systemet. Et eksempel på et tilfelle hvor man kan bruke et
aktivitetsdiagram er hvis man vil utvikle en tjeneste for bestilling av frakt og man vil få et
bilde på hvordan en bruker vil bruke tjenesten

b) Modeller et aktivitetsdiagram for kjøp av billett enten via nettside eller app. Presiser
i besvarelsen hvilken plattform dere modellerer for.

Oppgave 4
a) Hvordan kan bedriften korte ned tiden fra ide til produkt-slipp og samtidig være
sikker på systemets kvalitet? Begrunn.

Genom att bruka DevOps arbetssättet, den handlar främst om flyt där utvecklare jobbar
ständigt med testare och projektledare. Eftersom utvecklare jobbar samtidigt som
projektledare och testare på samma projekt, betyder det att testarna kan tidigare börja testa
projektet och på så sätt tidigare få tillbaka meddelanden och upptäcka fel i koden. När man
fixar fel tidigt, slutar man gå längst en väg som leder en vilse, därför spenderar man senare
mindre tid för bug fixing och tweaking för att få projektet att nå kraven. Alltså når även
projektet marknaden/kunden fortare

b) Hva er forskjellen på “continuous integration”, “continuous delivery” og

“continuous deployment”?

Continuous integration handlar om kontinuerlig implementering, testing och hantering av

kod sådant som utvecklarna producerar den. Koden testas ständigt efter bugs och
uppdateras.
Continuous delivery handlar om kodens färdighet för levering, istället för testningen av
själva koden, testas hela programmet, funktionerna samt master branschen så att den alltid
är redo att lanseras till klienten.
Continuous deployment handlar om att programmet ska alltid vara redo att lanseras till
brukarna av tjänsten, det vill säga att programmet ska utföra en mängd tester på brukar nivå.

Man kan alltså se olikheterna mellan de olika begreppen, däremot ingår alla de i samma
arbetsprocess och därför är starkt sammankopplade med varandra.

Oppgave 5 Gjennomfør en risikoanalyse av utviklingsprosjektet ved å lage en

usikkerhetsmatrise (risikotabell). Få med eksempler fra de tre hovedtypene av risiko.
Sosio teknikk
ansvar 1. Digital teknologi som et sosio-teknisk fenomen
Et sosio-teknisk system innbefatter hvordan mennesker og teknologi forholder seg til
hverandre. Sosio-tekniske systemer omfatter tekniske systemer, men også prosesser og
interessenter som bruker og samhandler med det tekniske systemet.
2. Utvikling av digital teknologi innebærer ansvar
Juridisk ansvar vil si å bære følgene av skadegjørende handlinger eller unnlatelser, særlig i
form av straff eller erstatningsplikt. For eksempel: personvernloven og likestillingsloven.
Moralsk ansvar innebærer forpliktelsen til å forsvare eller rettferdiggjøre handlinger under
henvisning til en moralsk norm, regel eller autoritet. For eksempel: Lage løsninger og
systemer som inkluderer flest mulig mennesker.

Om avstanden mellom designere/utviklere og brukere

“The greater the temporal and spatial distance between the construction of a technology
and its application, the greater the likelihood that the technology will be interpreted and used
with little flexibility. Where technology developers consult with or involve future users in the
construction and trial stages of a technology, there is an increased likelihood that it will be
interpreted and used more flexibly. This should be even more the case where developers of
a technology are also users of that technology”.

En interessent er en person, gruppe eller organisasjon som kan påvirke eller bli påvirket
av en sak eller et anliggende, for eksempel en digital teknologi.

Interesse (eng. Concern), visse faktiske eller bare forestilte behov som søkes tilfredsstilt
av en interessent.

• En aktør for et system representerer en rolle som et menneske eller et annet system som
har et mål med systemet.
• Det er ofte flere interessenter enn aktører, og en aktør er som oftest også en interessent.

Rike bilder Kan brukes brukes individuelt og i grupper/teams. Kan brukes for å få oversikt.
Kan brukes for å utvikle eller endre systemer og tjenester, for å analysere eksisterende
systemer, for å evaluere systemer.

Hvem har interesser? Hvem er brukerne? Hvilke verdier råder? Hvem bestemmer/har makt?
Hvem bestemmer hvem som bestemmer? Hvem sitter på informasjonen? Hvem betaler?
Hvem er kunden? Er det noen konflikter? Er det noe vi trenger å undersøke mer?

Hvordan lage et rikt bilde?

● Start
● Først tegner du en situasjon tilknyttet et digitalt system. Det er den nåværende situasjonen
du skal tegne.
● Hvem er interessentene og hva er deres relasjon til situasjonen?
● Tegn relasjonene mellom interessentene (streker og evt. hjerter)
● Illustrer eventuelle konflikter som kryss eller kryssede klinger
● Tegn inn relevante elementer av konteksten, som sosiale, økonomiske, politiske og
miljørelaterte faktorer.
● Bruk tankebobler for å forklare interessentenes interesser (eng. concerns).
● Om mulig, bruk begreper som interessentene bruker i tankeboblene
Tekst og forklaring trengs også!!

Hva er analyseenhet (unit of analysis)?

● Subjekt (isolert)?
● Objekt (isolert)?
● Subjekt + objekt?
● Subjekt + objekt + omgivelse/situasjon/aktivitet/oppgave?

Individ nivå (mikro)

Gruppe nivå (meso)
Samfunns nivå (makro)

Brukerundersökelse
Hvorfor undersøke bruk?
- Kritiske systemer
- “failure is not an option”
- Fly, romskip, biler, våpen….
- Hverdagslivet
- telefonen må fungere!
-Universell utforming
- tilgjengelighet
- inkludering
- Alle skal være med.
- Kostnader/resurser ved utvikling
- Historien viser seg at det kan være dyrt å ikke ha med brukere.

Det er en rekke andre måter å beskrive brukskvalitet. Jakob Nielsen har en mye brukt
liste av karakteristikker; at systemet skal være...
● Lett å lære.
● Effektivt.
● Lett å huske.
● Relativt feilfritt og feiltolerant.
● Behagelig å bruke.

Brukerundersøkelser kan for eksempel gjøres gjennom å operasjonalisere noe av det

overfor – og undersøke spesifikke brukskvaliteter. En ser her at gjennom å være mer
spesifikk enn å kun bruke ordet brukervennlig, så kan vi gå inn og finne mer ut av enkelte
deler av brukskvaliteten, som for eksempel hvordan det er å lære for en gitt bruker, for en
gitt oppgave, i en gitt kontekst.

Det er flere steg i en brukerundersøkelse

1. Beskrive formålet; hvorfor?
2. Planlegge studie:
a) sette oppgaver og mål
b) samtykk
c) pilotere
d) rekruttere
3. Gjennomføre
4. Beskrive og representere dataene
5. Analysere dataene
6. Bruk resultatene

Skjult observasjon I hverdagen benytter vi oss ofte av skjult observasjon ved å iaktta folk i
omgivelsene, legge merke til bestemte hendelser osv. Dette er uproblematisk så lenge det
ikke er snakk om forskning og systematisk datainnsamling for en bestemt bruk.
Åpen, passiv observasjon Basert på de observertes samtykke gjør man en systematisk
observasjon av hvordan en eller flere personer opptrer i en situasjon
Deltagende observasjon En engasjerer seg i en aktivitet og får et blikk på situasjonen som
både er basert på at en er deltaker og tilskuer, eventuelt veksler mellom det ene og det
andre.

Lover
1. Personopplysningsloven - skyddar personens data som kan brukas för att
identificera en individ.
2. Likstillings- och Diskrimineringsloven
3. GDPR - implementerad i Personopplysningsloven.
4. Åndsverksloven
5. Arbeidsmiljøloven

1. Personopplysningsloven
- Personopplysning er enhver opplysning om en identifisert eller identifiserbar
fysisk person eller en person som direkte eller indirekte kan identifiseres
- Definition 11 i personopplysningsloven handler om samtykk; det er hvordan vi
får lov å behandle personopplysninger
- Samtykk er enhver frivillig, spesifikk, informert og utvetydig viljesytring fra den
registrerte der vedkommende ved en erklæring eller en tydelig bekreftelse gir
sitt samtykk til behandling av personopplysninger som gjelder vedkommende
- Frivillig samtykket må ikke være et resultat av press
- Spesifikt må være knyttet opp til de formål som personopplysninger
behandles for
- Informert person har krav på å vite hvilke personopplysninger som blir
samlet inn, hvordan de blir lagret, hva de skal brukes til, hvor lenge de vil bli
lagret, hvordan man kan få innsyn i egne personopplysninger, og annet som
er relevant
- Utvetydig må bekreftes ved en aktiv handling (ikke stille-samtykke) «klikk-
lisenser» er sannsynligvis tilstrekkelig
2. GDPR
General Data Protection Regulation (GDPR) på norsk: Personvernforordningen
(PVF)
• Trådte i kraft som lov i EU 25.05.2018, i Norge 20.07.2018, kalles som regel GDPR.
• Brudd på GDPR kan medføre bøter opp til €20 mill. eller 4% av omsetning.
• Håndheves av hvert lands tilsynsmyndighet, som er Datatilsynet i Norge.
• EUs lovtekst (GDPR) oversatt til norsk uten endring, 99 artikler .
• Følgende artikler presenteres her:
– Art. 5: Prinsipper for behandling av personopplysninger
– Art. 6: Behandlingens lovlighet (behandlingsgrunnlag)
– Art. 25: Innebygd personvern
– Art. 32: Sikkerhet ved behandlingen (innebygd informasjonssikkerhet)
– Art. 35: Vurdering av personvernkonsekvens (DPIA)
– Art. 45: Overføringer på grunnlag av en beslutning om tilstrekkelig beskyttelsesnivå
– Art. 46: Overføringer som omfattes av nødvendige garantier
– Art. 83: Generelle vilkår for ilegging av overtredelsesgebyr

Art. 6: Behandlingens lovlighet (behandlingsgrunnlag)

1. Behandlingen er bare lovlig når minst ett av følgende vilkår er oppfylt:
a) den registrerte har samtykket til behandling for ett eller flere spesifikke formål,
b) behandlingen er nødvendig for å oppfylle en avtale som den registrerte er part i,
eller for å gjennomføre tiltak på den registrertes anmodning før en avtaleinngåelse,
c) behandlingen er nødvendig for å oppfylle behandlingsansvarliges rettslig
forpliktelser,
d) behandlingen er nødvendig for å verne den registrertes eller andre personers
vitale interesser,
e) behandlingen er nødvendig for å utføre en oppgave i allmennhetens interesse eller
utøve offentlig myndighet som den behandlingsansvarlige er pålagt,
f) behandlingen er nødvendig for formål knyttet til de berettigede interessene som
forfølges av den behandlingsansvarlige eller en tredjepart, med mindre den
registrertes interesser eller grunnleggende rettigheter og friheter går foran og krever
vern av personopplysninger, særlig dersom den registrerte er et barn. Punkt f) får
ikke anvendelse på behandling som utføres av offentlige myndigheter som ledd i
utførelsen av deres oppgaver (fordi dette tilfellet dekkes av punkt e) ).

Art. 45: Overføringer på grunnlag av en beslutning om tilstrekkelig

beskyttelsesnivå
1. Personopplysninger kan overføres til en tredjestat eller en internasjonal
organisasjon når Kommisjonen har fastslått at tredjestaten, et territorium eller en eller
flere angitte sektorer i nevnte tredjestat eller den aktuelle internasjonale
 organisasjonen sikrer et tilstrekkelig beskyttelsesnivå. En slik overføring skal ikke
kreve en særlig godkjenning.
2. Ved vurderingen av om beskyttelsesnivå er tilstrekkelig skal Kommisjonen særlig
ta hensyn til det følgende:
a) prinsippet om rettsstaten
b) om det finnes en eller flere velfungerende, uavhengige tilsynsmyndigheter i
tredjestaten
c) de internasjonale forpliktelsene som den berørte tredjestaten har påtatt seg
3. Etter å ha vurdert om beskyttelsesnivået er tilstrekkelig, kan Kommisjonen beslutte
at en tredjestat sikrer et tilstrekkelig beskyttelsesnivå i henhold til nr. 2 i denne
artikkel (adekvansbeslutning).

3. Likstillings- och Diskrimineringsloven

§ 18. ”Løsninger for IKT som underbygger virksomhetens alminnelige funksjoner, og
som er hovedløsninger rettet mot eller stilt til rådighet for allmennheten, skal være
universelt utformet fra det tidspunktet som er fastsatt i § 41. Med IKT menes
teknologi og systemer av teknologi som brukes til å uttrykke, skape, omdanne,
utveksle, lagre, mangfoldiggjøre og publisere informasjon, eller som på annen måte
“gjør informasjon anvendbar.”
Forskrift om universell utforming av ikt-løsninger stiller krav om at nettsider
må oppfylle 35 av 61 suksesskriterier i standarden: Retningslinjer for
tilgjengelig webinnhold: WCAG 2.0.
Artikkel 18 är specifikt riktad mot ITtjänster

4. Åndsverksloven:
Rettigheter omkring åndsverk - selve verket man har opphavsrett til. Gir både ideelle
og økonomiske rettigheter.
Et datamaskinprogram er åndsverk. Åndsverkloven har en særregel: opphavsrett
til «datamaskinprogram som er skapt av en arbeidstaker under utførelsen av
oppgaver som omfattes av arbeidsforholdet» overføres automatisk (med mindre
annet er avtalt) til arbeidsgiveren

5. Arbeidsmiljøloven:
Hvilke rettigheter og plikter arbeidstakere og arbeidsgivere har. § 4.2: Krav til
tilrettelegging, medvirkning og utvikling som er viktig for informatikere å kjenne til.
Her står det at arbeidstakerne (og deres tillitsvalgte) skal informeres om endringer i
systemer de bruker i arbeidet, og de “skal medvirke ved utformingen av dem”. Det
legges stor vekt på et godt psyko-sosialt arbeidsmiljø (se detaljert beskrivelse i § 4.3)

Sekvensdiagram
Etik
Universell utforming

Modeller å tenke med

GAP modellen

Brukbarhetspyramiden

Medisinsk modell
Sosial modell
Implikasjoner av å bruke et sosial modell-perspektiv
• Funksjonshemning er ikke noe som er, det er noe vi gjør. Funksjonshemning kan skapes,
forverres, eller minimeres.
• Det er ikke mulig å forstå funksjonshemming bare ved å fokusere på ”funksjonshemmedes
behov og forutsetninger” – man må se på den sosiale rammen

Universell Utforming handlet opprinnelig om fysiske, bygde miljøer. Stammer fra North
Carolina State University - 7 prinsipper
1. Enkel og intuitiv i bruk – Utformingen skal være lett å forstå uten hensyn til brukerens
erfaring, kunnskap, språkferdigheter eller konsentrasjonsnivå.
2. Forståelig informasjon – Utformingen skal kommunisere nødvendig informasjon til
brukeren på en effektiv måte.
3. Toleranse for feil – Utformingen skal minimalisere farer og skader som kan gi ugunstige
konsekvenser, eller minimalisere utilsiktede handlinger.
4. Like muligheter for alle – Utformingen skal være brukbar og tilgjengelig for personer med
ulike ferdigheter.
5. Fleksibel i bruk – Uansett individuelle preferanser og ferdigheter. Den synshemmede skal
kunne høre, den hørselshemmede se og så videre.
6. Lav fysisk anstrengelse – Utformingen skal kunne brukes effektivt og bekvemt med
minimum besvær.
7. Størrelse og plass for tilgang og bruk – Hensiktsmessig størrelse og plass skal muliggjøre
tilgang, rekkevidde, betjening og bruk, uavhengig av brukerens kroppsstørrelse,
kroppsstilling og mobilitet.

Web Content Accessibility Guidelines (WCAG) brukes for å gjøre digitale innhold
tilgjengelig: delt i 4 prinsipper
1. Mulig å oppfatte
2. Mulig å betjene
3. Forståelig
4. Robust

hur man designar angående WCAG https://www.w3.org/WAI/tips/designing/

regerlverk: https://www.uutilsynet.no/regelverk/regelverk/266
Systemutveckling
Definisjon: Systemutvikling (software engineering)
• – er læren om utvikling og forvaltning av IT-systemer av høy kvalitet innen gitte tids- og
kostnadsrammer.
• Viktige kvalitetsegenskaper er funksjonell egnethet «hva kan systemet gjøre», effektivitet,
pålitelighet, brukskvalitet, vedlikeholdbarhet og sikkerhet
• Typiske aktiviteter er planlegging, kravinnsamling og kravanalyse, design,
programmering/koding, testing, konfigurasjonsstyring og versjonshåndtering

Vedlikehold (forvaltning)
• Vedlikehold av IT-systemer betyr ikke å bevare originalversjonen mest mulig slik som for
bil, hus etc.
• Vedlikehold er alle endringer utført på et system etter at det er satt i drift
• Utgjør 50%–90% av kostnadene i levetiden til et system
• Stor andel av nedarvede (“legacy”) systemer: bank, forsikring, offentlige etater

Code management
-git hub
-inga crasher

Olikheter i kostnad/tid
• Ulike måter å jobbe på, dvs. ulike systemutviklingsprosesser, gir ulike resultater
Prosessen påvirker resultatet
• Systemutviklingsprosessen vil påvirke kvaliteten både på prosjektet selv og
systemet som utvikles
• Måten man jobber på påvirker også arbeidsmiljøet (trivsel, motivasjon,
kompetanseutvikling etc.) som igjen påvirker prosjekt- og produktkvalitet
• Din kompetanse og måten du og ditt team jobber på avgjør hvordan prosjektet og
sluttproduktet blir!

• Viktig å være bevisst hvilke kvalitetsegenskaper man ønsker å vektlegge

Systemutviklingsprosess
• – er de aktivitetene som utføres for å utvikle et IT-system
• Aktivitetene varierer, men vil alltid ha elementer av
– spesifisering av kravene, dvs. hva systemet skal gjøre
– design av systemet (for eksempel lage en datamodell)
– implementering av koden (programmering)
– validering av at systemet gjør det kunden ønsker
– endringer av systemet i forhold til nye og endrede krav hos kunden
Hvordan tilpasse prosesser?
• Prosesser må tilpasses
– ingen prosjekter er like
– Mange faktorer påvirker prosessen
• Hva kan tilpasses?
– Faser/aktiviteter, roller, ansvarsforhold, utforming/frekvens på rapporter og gjennomganger
• Hvordan tilpasse?
– Identifiser prosjektomgivelser
– utviklingsstrategi, risiko, krav, applikasjonsområde, type kunde etc.
– Innhent synspunkter fra utviklere, brukere, kunder
– Definer prosesser, aktiviteter og roller
– Begrunn og dokumenter tilpasningene
Fossefallsmodellen – klassisk ingeniørtilnærming
• Sivilingeniørprosjekter (bygg & anlegg) er plandrevet, dvs. relativt mye tid på planlegging
og utviklingen dokumenter som styrer prosjektet
• Separate faser
• Vanskelig å tilpasse endringer i krav underveis

Behov for smidighet

• Klassisk ingeniørtilnærming vist seg ofte å ikke være egnet
• Derfor er “smidige metoder” nå blitt det normale
– Vektlegging av kode fremfor (omfattende) design og dokumentasjon
– Vektlegging av samarbeid med kunde fremfor kontraktsforhandlinger
– Raskere levering av kode og raske endringer tilpasset endrede brukerkrav

Prosessprinsipp: Timeboxing versus “task-boxing” / “task-flyt”

Tidsbokser (Scrum)
• Velg noen prioriterte oppgaver og jobb med dem i faste tidsintervaller (tidsbokser*) med
definerte oppstarts- og avslutningsaktiviteter
Flyt av oppgaver (Kanban)
• Definerer et sett med oppgaver eller “features” som skal lages, og lever så snart man er
ferdig. Oppgaver skal ”flyte” uten avbrudd gjennom de nødvendige aktivitetene til de er
ferdige (”oppgaveboksing”)

Scrum – tre faser

• Planleggingsfasen: overordnede mål for prosjektet etableres og programvarearkitekturen
designes
• Gjennomføringsfasen: en serie med iterasjoner (kalt ”sprint”), der hver iterasjon leverer et
inkrement av systemet
• Avslutningsfasen: nødvendig dokumentasjon som hjelpfunksjoner og brukermanualer
fullføres, og man oppsummerer hva man har lært i prosjektet
Brukerhistorie (user story)
• Én eller flere setninger som beskriver hva brukeren av et system ønsker å få ut av
systemet på formen:
– ”Som en ønsker jeg for å oppnå ”
• Kort beskrivelse, passer på et kort eller gul lapp

(Antatte) fordeler ved Scrum

• Systemet blir delt opp i en mengde forståelige og håndterbare deler
• Ustabile krav hindrer ikke progresjon i prosjekt-gjennomføringen
• Hele teamet observerer hva som skjer i prosjektet, og kommunikasjon innen teamet blir
god
• Kundene får inkrementer levert fortløpende og kan gi tilbakemelding på hvordan deler av
systemet fungerer
• Tillit mellom kunder og utviklere kan etableres tidlig
• Kryss-funksjonelle team (kompetansene på ulike områder finnes innen teamet) sikrer
framdrift og reduserer risiko

Kanban
• Fokus på å få oppgaver (arbeidspakker) raskt utført = antall brukerhistorier (features)
implementert per tidsenhet
• Begrense antall arbeidspakker som det jobbes med i parallell (WIP = Work In Progress) for
å hindre flaskehalser
• Antakelse: Jo høyere WIP, jo saktere flyter arbeidspakken gjennom arbeidsprosessene
• Når en pakke er ferdig, kan man etterspørre en ny som man begynner å jobbe med (pull)
• Mindre fokus på estimering av tid og kostnader

Fordeler ved Kanban

• Flaskehalser i prosessen blir synlige
– Fokus på å bli ferdig med oppgaver som hindrer gjennomstrømning fremfor å begynne på
flere oppgaver som vil hope seg opp
• Kan drive smidig utvikling uten å bruke “tidsbokser”
– Spesielt for drifts- og supportoppgaver og vedlikeholdsoppgaver vil veldefinerte “sprinter”
ofte ikke gi mye mening
• Gunstig der det er svært vanskelig å estimere oppgavene
Refaktorering (forbedring)
• Forbedre koden selv om ikke umiddelbart behov for dem
• Koden mer forståelig og enklere å endre, og mindre behov for dokumentasjon (mer
vedlikeholdbar)
• Noen endringer krever at arkitekturen omstruktureres (kostbart)
• Eksempler på refaktorering
– Reorganisering av klassehierarki for å fjerne duplisert kode
– Forbedre navn på attributter og metoder
– Erstatte kode med kall til metoder i et programbibliotek
• Dårlig kode vil ha ”teknisk gjeld”

Parprogrammering To programmerere utvikler kode sammen:

– Fører
• skriver på tastaturet
– Navigatør
• observerer arbeidet til føreren og ser etter feil og svakheter
• ser etter alternativer
• noterer ting som må gjøres
• slår opp referanser
– Kan brukes uavhengig av smidige metoder
- forskning visat mindre effektivt med erfarna programmerare.

Krav
Typer krav
• Brukerkrav (funktionellt krav)
– Krav uttrykt i naturlig språk eller diagrammer som viser ønskede tjenester (funksjoner) til
systemet og føringer som gjelder (andre kvalitetsegenskaper)
– Skal forstås greit av kunden
 • Systemkrav (funktionellt krav)
– Strukturert, detaljert beskrivelse av systemets funksjoner og kvalitetsegenskaper
– Definerer mer detaljert hva som skal designes og implementeres
– Utgangspunkt for kontrakt mellom kunde (oppdragsgiver) og utviklerorganisasjon

Funksjonelle krav

Hva systemet skal gjøre

– Hvilke tjenester (funksjoner) skal systemet tilby?
• Tjenestedesign en en aktivitet for å forstå hva brukerne “egentlig” trenger
• Resultatet av tjenestedesign er input til kravspesifisering
– Hvordan skal det reagere på ulike typer input?
– For å avgrense systemet, vil man også kunne beskrive hva systemet ikke skal gjøre

EXEMPEL:
Avstand mellom tog:
– Overordnet
1. Stor nok til å unngå kollisjoner
2. Liten nok til å tillate tett trafikk
– Detaljert
1. Minimum bremselengde + 1 min * togets hastighet
2. Max hastighet for at 20 tog per time kan passere

Ikke-funksjonelle krav
• Hvordan systemet skal implementere de funksjonelle kravene

Produktkrav: ”Usability requirements”

– er systemet lett å lære og bruke?
• Brukskvalitet/Brukervennlighet
– avhenger av krav til opplæring
– varierer for ulike brukergrupper
– universell utforming
• Kan måles:
– Hvor lang tid tar det å lære systemet for nybegynnere?
– Hvor mange “brukerfeil” oppstår med erfarne brukere?
– Hvor ofte får brukerne meningsløse tilbakemeldinger?
 – Responstid: Tid fra brukeren trykker ’OK’ til systemet svarer

Produktkrav: ”Efficiency requirements” (Effektivitet)

• Ytelse (”Performance requirements”)
– Kapasitet (transaksjoner pr. timer i betalingskortsystemer)
– Antall samtidige brukere
– Responstid (min/maks/gjennomsnitt ved ulik belastning)
• Lagringsplass (”Space requirements”)

Produktkrav: ”dependability requirements”

– I hvilken grad kan man stole på systemet?
• Pålitelighet (”reliability”)
– Feilrater (mean time between failures (MTBF))
– Oppetid (% tid tilgjengelig for bruker)
• Ulike systemer, ulike krav

Produktkrav: ”Security requirements”

• Sikring av data, for eksempel
– grad av kryptering
– valg av autentiseringsprotokoller/innlogging

Begrepene safety og security brukt innen systemutvikling

• Safety: Det skal ikke være risikabelt å bruke IT-systemer (sikkerhet mot uønskede
hendelser som resultat av tilfeldigheter og ulykker), jfr. Boeing 737 MAX
• Security: IT-systemer skal hindre at de selv eller deres data blir angrepet utenfra
(sikkerhet mot uønskede hendelser som resultat av overlegg)

Organisasjonskrav: “Development requirements”

• Kostnader og ressurser er alltid en begrensning!
• Leveransetidspunkt (påvirker også kostnader og ressursbruk)
• Prosessmodeller og utviklingsmetoder
• Programmeringsspråk, verktøy, komponenter
• Standarder og regler i organisasjonen

• Ikke-funksjonelle krav ofte vanskelige å uttrykke presist, og upresise krav er vanskelige å

verifisere
• Verifiserbart ikke-funksjonelt krav
– En påstand som uttrykker noe målbart som kan testes objektivt
– Eks. romreservasjonssystem:
• ”90 % av brukerne skal bruke mindre enn 1 minutt på å reservere ønsket rom etter å ha
brukt systemet 3 ganger (gjennomført vellykkede reservasjoner)”

Smidig vs. standarder/regler

• Bra å være smidig, dvs. justere kursen underveis ved behov, men:
• Spesielt i sikkerhetskritiske systemer bør regler/standarder/konvensjoner sjekkes for å
hindre ulykker
– Alle tog sjekkes hvert døgn, all skinnegang sjekkes hver uke, etc.
– Bør ha samme forhold til programvare. Etter endringer, automatisk sjekking/testing

Kravspesifikasjonen (dokument)
• Spesifiserer bruker- og systemkrav.
• Ofte del av kontrakt for systemutviklingsprosjektet
– Derfor bør være så komplett og presis som mulig
• Informasjonen i ”kravspec’en” vil avhenge av type system og utviklingsprosjekt
• Ulike standarder – F.eks. utgitt av IEEE og ISO

Sätt att skriva kravspecifikationer;

Naturlig språk
Kravene skrives som nummererte setninger på norsk, engelsk etc.
Strukturert naturlig språk Naturlig språk men på en standard form (skjema). Hvert felt gir
informasjon om ett aspekt ved kravene
Grafiske notasjoner Grafiske modeller støttet av tekstbeskrivelser, beskriver funksjonelle
krav; UML use case (bruksmønstre / brukstilfeller) og sekvensdiagrammer er vanlig å bruke
Matematiske spesifikasjoner Notasjoner basert på matematiske begreper, eks.
tilstandsmaskiner og mengder. Kan redusere flertydighet, men de fleste kunder forstår ikke
formelle spesifikasjoner. De vil derfor ikke kunne sjekke at de faktisk representerer deres
ønsker og vil derfor være skeptiske til bruk av slike spesifikasjoner i en kontrakt

Retningslinjer for skriving av kravspec

• Bruk et standard format på alle krav
• Bruk “må” for absolutte krav og “bør” for ønsker
• Uthev teksten på spesielt viktige deler
• Unngå IT-sjargong
• Forklar hvorfor et krav er nødvendig

Retningslinjer for skriving av kravspec

• Bruk et standard format på alle krav
• Bruk “må” for absolutte krav og “bør” for ønsker
• Uthev teksten på spesielt viktige deler • Unngå IT-sjargong
• Forklar hvorfor et krav er nødvendig

Utfordringer
• Forståelighet
– Kravene er ofte uttrykt i ved bruk av spesiell fagterminologi
– Ofte uforståelige for systemutviklere
• Implisitt
– Domenespesialister kan kjenne fagområdet så godt at de ikke tenker på å
formulere krav eksplisitt som de tar for gitt
• En god systemutvikler har ofte god domene-kunnskap. Industri og næringsliv etterspør ofte
begge deler
Krav og design
• I teorien: krav uttrykker hva systemet skal gjøre, designet angir hvordan man skal lage det
• I praksis: vanskelig å skjelne mellom krav og design
– En systemarkitektur må designes for å strukturere kravene
– Systemet vil kunne måtte samspille med andre systemer som igjen gir opphav til nye
designkrav
– En spesifikk arkitektur for å imøtekomme ikke-funksjonelle krav vil kunne være et viktig
krav, for eksempel for å tilfredsstille lovgivning.
Eksempel: skatte-opplysninger som utveksles elektronisk over landegrenser stiller krav til
arkitekturen

Kravspec i smidige prosjekter

• I smidig systemutvikling er det færre detaljer i krav-spec’en
• Kravene gjerne uttrykt som en liste av “brukerhistorier” kalt backlog
– Merk: bruker trenger ikke være sluttbruker. ”Som sikkerhetsansvarlig ønsker jeg …”
• Et scenario beskriver detaljert hvordan en bruker benytter en tjeneste (scenario = sekvens
av hendelser)
• I statusmøter (sprint-slutt/”retrospective” i Scrum) evalueres backlog’en. Innholdet kan
endres, dvs. “levende” kravspec
• En Epic er en stor brukerhistorie eller ide (for stor for en sprint) og som etter hvert brytes
ned til flere mindre brukerhistorier

Warning för smidig kravspec

• Hevdes ofte i smidig utvikling at det er bortkastet å bruke tid på å lage detaljerte kravspec’s
fordi kravene endrer seg likevel
• Brukes som unnskyldning for ikke å jobbe nok med kravspesifikasjonen, spesielt bør
fundamentale krav spesifiseres tidlig
• Bare bruk av user stories som kravspec. vil være en utfordring i store prosjekter. Hvordan
vil kravspesifikasjonen til E-resept se ut – 2000 gule lapper?

Kravhåndteringsprosessen

Aktivitet 1: Forstudie/målanalyse
• Analyser nå-situasjonen, ønsket situasjon og mulige tiltak for å oppnå ønsket situasjon
• Hvilke (del)mål kan oppnås ved å lage et nytt eller endre et IT-system?
• Hva er kost/nytte for forskjellige delmål? Risikomomenter?
• Prosjektmandat: “Ja, vi skal lage et system for å oppnå følgende mål:”

Aktivitet 2: Kravinnsamling og -analyse

• Engelsk: Requirements elicitation, collection, capture or discovery
• Forstå domenet – forretningsområde og terminologi
• Identifiser interessentenes krav
• Organiser kravene i hierarkier eller grupper
• Identifiser og løs konflikter mellom krav
– Omfatter mange av de samme aktivitetene som i foranalysen bortsett fra at man nå
typisk har et prosjektmandat og derfor innhenter flere fakta og systematiserer dem

Kravinnsamling – utfordringer
• Ulike forretningsområder har egen terminologi
• Ulike organisasjoner har egen terminologi, struktur og forretningsprosesser som en utvikler
kanskje ikke kjenner til
• Interessenter vet ikke nøyaktig hva de vil ha eller kjenner ikke til tekniske muligheter og
begrensninger
• Motstridende krav fra forskjellige interessenter, forskjellige meninger om hva som er viktig,
organisasjonsstruktur og politikk, skjulte agendaer etc. Ofte ikke mulig å nå konsensus. Da
må det skjæres igjennom …
• Kravene vil ofte endres underveis, nye interessenter dukker opp, forretningsområdet
endrer seg, organisasjonen endrer seg (reorganisering, oppkjøp) etc.
• Må skille mellom ’need to have’ og ’nice to have’

En prosjektleder må forholde seg til ulike interessenter (stakeholders)

Oppdragsgivere (kunder): prioriterer de eller vil de ”ha alt, og det feilfritt og med en gang”?
– Brukergrupper: brukervennlighet
– Ledere: planer, mål, ikke overraskelser
– Utviklere: god teknisk løsning, stilig
– Vedlikeholdere: feilfritt, forståelig og veldokumentert
– Systemeiere og forvaltere: økonomi – Andre interessenter (fagforeninger, lovgivere, andre
systemer)

Brukere av kravspesifikasjonen

Hvordan samle inn kravspec-informasjon?

Finnes en rekke metoder og teknikker
• Bruksmønstre/brukstilfeller (use cases)
• Intervjuer
• Spørreskjemaer
• Etnografi/observasjon
Aktivitet 3: Validering av kravspec
• Sjekk at kravene definerer det systemet som kunden faktisk vil ha
• Feil i krav koster mye
– Å rette opp en kravfeil etter at systemet er utviklet og tatt i bruk koster svært mye
mer enn å rette opp feilen mens kravene spesifiseres

Aktivitet 4: Håndtering av kravendringer

• Forretningsområde og tekniske omgivelser vil endre seg etter at systemet er tatt i bruk
• Brukere vil oppdage nye behov etter hvert som systemet tas i bruk
• Trenger oversikt over avhengigheter mellom kravene slik at man kan vurdere
konsekvensene av å endre dem
• Trenger en formell (strukturert) prosess for å vurdere og evt. gjennomføre endringsforslag
– Hvilken endring foreslås?
– Hvem foreslår?
– Hvem vurderer behovet for endringen, lager konsekvensanalyse, og beslutter om
endringen skal implementeres?
– Hvem skal involveres i implementeringen?
– Hvem følger opp? Etc.

Kravspec som grunnlag for testing

• For dårlig arbeid med kravspesifisering er én av årsakene til ”IT-skandaler”
• Hvis kravene er dårlig spesifiserte, kan man ikke stole på at systemet er bra selv om
systemet er testet mot kravspec.

Risikohåndtering
• En risiko er en sannsynlighet for at uønskede omstendigheter skjer
• Tre hovedtyper av risiko:
– Prosjekt-risikoer vil ha effekt på tidsplanen og/eller ressurser
– Produkt-risikoer vil ha effekt på kvaliteten eller av programvaren som utvikles
– Forretnings (Business)-risikoer vil ha effekt på organisasjonen som utvikler eller
eier programvaren

Risikoanalyse
• Vurder sannsynlighet og mulig konsekvens for hver risiko
• Sannsynlighet kan være svært lav, lav, moderat, høy eller svært høy
• Konsekvensen kan være katastrofal, alvorlig, mindre alvorlig eller ubetydelig

Motivasjon
• Er ikke folk motiverte, er de lite interesserte i hva de gjør
• Motivasjon er komplekst, men ulike typer motivasjon er basert på
– Basis behov (mat, søvn, etc.)
– Sosiale behov (å bli akseptert i en gruppe, etc.)
– Personlige behov (respekt, selvtillit , etc.)

Personlighetstyper
– Oppgaveorientert (Task-oriented)
• Motivasjonen for å gjøre arbeidet er oppgavene i seg selv
– Selvorientert (Self-oriented)
• Arbeidet er et middel for å oppnå individuelle mål
– bli rik, få posisjon, reise, etc.
– Samspillorientert (Interaction-oriented)
• Motivasjonen er først og fremst å samarbeide og ha det bra med medarbeiderne. Man går
på jobb fordi man liker å gå på jobb

Diagrammer i UML (Unified Modeling Language)

• Use case diagrammer viser systemets funksjonalitet og samspillet mellom systemet og
omgivelsene (brukere, andre systemer, komponenter)
• Sekvensdiagrammer viser samspill mellom system og omgivelser og mellom de
forskjellige delene av systemet (mer detaljer for hvert Use Case med objekter og metodekall)
• Klassediagrammer viser klassene i systemet og assosiasjonene mellom disse klassene
• Aktivitetsdiagrammer viser forretningsprosesser og - arbeidsprosesser

Use case modellering Identifiser aktører

• En aktør representerer en rolle som et menneske eller et annet system når det
kommuniserer med dette systemet
• En aktør kommuniserer med systemet via ett eller flere use case
• En aktør er ofte også en interessent (stakeholder), men det finnes en del interessenter som
ikke er aktører

• I workshop
– Brainstorming
• Fra tekstlige krav
• Blant prosjektets interessenter
• Spørsmål
– Hvem skal bruke systemet? (primär aktör)
– Hvem skal administrere systemet? (sekundär)
– Hvem (sekundär)
• tilbyr informasjon til
• bruker informasjon fra, eller
• fjerner informasjon fra systemet?
– Hvilke eksterne ressurser skal systemet bruke?
– Hvilke andre systemer skal kommunisere med dette systemet?

Et use case beskriver hvordan systemet oppnår et mål av verdi for en aktør
- En historie
- Et komplett use case består av flere ulike hendelsesforløp (flyt)
• Et use case beskriver en komplett funksjonell enhet Ø
One person – one place – one time
• Et use case er testbart

Alternativ flyt

• Use casene kan oppnå sitt mål på flere måter, og kan feile på flere måter, så detaljerte use
case har også alternative flyt.
• Alternative flyt (blant annet feilsituasjoner) er viktige da det ofte er mer ”uenighet” blant
prosjektets interessenter om hva som skjer i de tilfellene enn for hovedløpet.
• Ethvert steg i hovedløpet kan være utgangspunkt for et alternativ flyt.

Relasjoner mellom og use case – Extend og Include relasjonen

• Include-relasjonen: Et use case kan være en del av ett flere andre use case.
• Extend-relasjonen: Et use case som beskriver tilleggsoppførsel som utføres under gitte
omstendigheter

Include-relasjonen
• To eller flere use cases kan ha en felles del (noen like steg). Denne delen kan da legges ut
i et eget use case som disse use casene kan inkludere.
• Basis use caset vet hvilke use case det inkluderer
Extend-relasjonen
• Alternativ oppførsel som utføres i noen tilfeller kan skrives som eget use case som utvider
(extends) et annet
• Extend use case beskriver hvordan oppnå et tilleggsresultat
– utvider funksjonaliteten
• Basis use caset kjenner sine extend use cases
• Bruk av alternativ flyt vs. bruk av extend use case:
- Alternativ flyt beskriver hva som skjer ved avvik i normal flyt, mens
- Extend use case beskriver hvordan oppnå tilleggsresultat.

Use case vs. smidig utvikling

• I smidig utvikling jobber produkteier ofte sammen med utviklere i samme team
• Det er mindre behov for detaljerte beskrivelser av krav og ofte brukes user stories (en ”lett”
versjon av use case)
Eks: Som lånekonsulent ønsker jeg å kunne vurdere lånesøknader slik at jeg kan gi en riktig
og rask vurdering
• Krav utvikles underveis og beskrives ”on demand”
- Først tilstrekkelig for prioritering i produktkøen
- Så tilstrekkelig for prioritering i sprint backloggen

Use case vs. user stories

• Likheter. Begge viser
– Hvem som skal bruke systemet
– Hva de skal gjøre med det
– Hvorfor de skal gjøre det
• Forskjeller
– Omfang, kompletthet, livslängd, hensikt
– User stories er godt egnet for å finne krav og bruke disse i smidig utvikling i samarbeid
med produkteier/kunde
– Use case er mer detaljert, har flere bruksområder videre i prosjektet og er mer egnet som
dokumentasjon
• Men, det er en flytende overgang mellom dem.

Use case i design

• Hendelsesflyt i use casene detaljeres ut i sekvensdiagram
• Domenemodellen utvides til klassediagram med systemklasser

Domenemodell
• UML klassediagrammer uten metoder
• Domenemodellen viser objekter i problemdomenet.
• Hensikten med domenemodellen er å forstå objektene og få en oversikt over terminologi.
• Domenemodellen er nyttig i forbindelse med use case modellering fordi:
– Domenemodellen viser informasjonen om objekter i use casene.
– Den er et viktig verktøy for å sjekke at use casene er beskrevet med riktig
detaljeringsnivå.

Sekvensdiagrammer
• Et flyt i et use case kan modelleres med sekvensdiagrammer.
• For hvert use case lages typisk sekvensdiagram for hovedflyt og for hyppig forekommende
alternative flyt.
• Stegene (sekvensene – se tekstlig beskrivelse) i et use case vises som meldinger som
sendes mellom objektene ved kall på objektenes metoder.
Aktivitetsdiagrammer
• Et aktivitetsdiagram kan grafisk representere hendelsesflyten i et use case.
• Stegene i use casene vises som aktiviteter (rektangel)
• Beslutninger underveis vises som (diamant)
• Aktivitetsdiagrammer og sekvensdiagrammer brukes noe overlappende, men
sekvensdiagrammer er typisk mer kodenært mens aktivitetsdiagrammer er mer
forretningsnært.

Klassediagram

Identifisere klasser
- Det finnes ingen “magisk formel” for å identifisere
klasser.
- Avhenger av kompetanse, erfaring og
domenekunnskap (kunnskap om systemet og
omgivelser) til utvikleren eller systemdesigneren
- Iterativ prosess. Umulig å få det riktig første gang
- Bruk en grammatisk tilnærming – objekter og attributter
er subjekter, operasjoner (metoder) er verb
- Bruk gjenkjennelige ting (entiteter) – som Emne og
Kurs, roller som Student og Foreleser
- Bruk en scenario-basert analyse og identifiser
objektene, attributtene og metodene i hver scenario
Spesifikasjon av grensesnitt/interface
 - Grensesnitt/Interface bør spesifiseres slik at objektene
og andre komponenter kan designes i parallell.
- Ikke design representasjonen av data – kun “navn” og
metoder (uten innhold). Innholdet defineres i objektene
som “implementerer “grensesnittet.
- Objekter kan ha flere grensesnitt med ulike
perspektiver av metodene som er spesifisert.
- Klassediagrammer blir brukt i UML for spesifikasjon av
grensesnitt.

Finne ansvarsområder til klasser

- Hvert funksjonelle krav må tilordnes en eller flere klasser
>Hvis en klasse har for mange ansvarsområder, vurder å splitte den i ulike klasser.
> Hvis en klasse ikke har noe ansvar, så er den antageligvis overflødig
> Når et ansvar ikke kan tilordnes til en eksisterende klasse, opprett en ny klasse.
- For å finne ansvarsområder
> Analyser use casene
> Se etter verb og substantiver som beskriver handlinger

Kategorier av ansvar:
-Sette og hente verdier av attributter
- Opprette nye instanser (objekter)
- Hente fra og lagre til persistent minne (database…)
- Slette instanser
- Legge til og slette linker for assosiasjoner
- Kopiere, konvertere og endre
- Beregne numeriske resultater
- Navigere og søke

Modularisering
Høy kohesjon
- Et objekt skal bare ha ansvar for relaterte ting
Lav kobling
- Et objekt skal samarbeide med et begrenset
antall andre objekter

Høy kohesjon
- Kohesjon er et mål på hva slags ansvar et
objekt har og hvor fokusert ansvaret er
- Et objekt som har moderat ansvar og utfører et
begrenset antall oppgaver innenfor ett
funksjonelt område har høy kohesjon
- Objekter med lav kohesjon har ansvar for
mange oppgaver innen ulike funksjonelle
områder

Lav kobling
- Kobling er et mål på hvor sterkt et objekt er
 knyttet til andre objekter
- Et objekt med sterk kobling er avhengig av
mange andre objekter, noe som kan gjøre
endring vanskelig

Analyse- vs. designmodell

- Analysemodellen utelater mange klasser som er nødvendige i
et komplett system
- Er typisk en domenemodell
- Kan inneholde mindre enn halvparten av klassene i systemet.
- Uavhengig av spesielle
brukergrensesnittsklasser
arkitekturklasser (f.eks. design patterns klasser)
- Den komplette designmodellen inneholder
- Domenemodellen
- Brukergrensesnittsklasser
- Arkitekturklasser (f.eks. slik at objekter kan kommunisere)
- Utility klasser (f.eks. håndtering av mengder og strenger
-
Designmønstre – ”Design patterns”
- Et designmønster er en måte å gjenbruke abstrakt
kunnskap om et problem og løsningen på problemet
- Et mønster er en beskrivelse av et problem og
essensen av løsningen
- Bør være tilstrekkelig abstrakt til å kunne bli gjenbrukt i
ulike situasjoner

- Mønstre er navngitte retningslinjer for hvordan ansvar skal

fordeles i ulike situasjoner.
- Mønstre brukes bl.a. i prosessen med å forfine
sekvensdiagrammer
- Sentrale prinsipper er
- Ekspertprinsippet:
- La det objektet som har kunnskapen (dataene) også behandle den
- Kontrollobjektprinsippet:
- To typer kontrollere:
- Fasadekontroller: En kontrollklasse har ansvar for alt (brukes i et lite
system)
- Use case kontroller: Styrer ett use case (brukes i større systemer. Ett
kontrollobjekt for hvert use case).
- Skaperprinsippet:
- Legg ansvar for å opprette et nytt objekt i klassen som må vite om
det nye objektet

Ekspertprinsippet:
(Information Expert)
Problem: Hva er det generelle prinsipp for å tilordne ansvar til objekter?
Løsning: La det objektet som har kunnskapen (dataene) også ta ansvaret
Hvordan:
- Begynn med å formulere ansvarsområdet:
- Eks: Student-Kurs:
Hvilket objekt har ansvar for å vite om hvilke emner som kreves for å ta et gitt emne?
Hvilket objekt har ansvar for å gi en liste over alle studentene på et kurs?

Skaperprinsippet (Creator)
Problem: Hvem er ansvarlig for å opprette nye objekter?
Løsning: La det objektet som må vite om de nye objektene,
lage dem
Hvordan: Gi klasse B ansvaret for å opprette et objekt av
klasse A dersom ett av følgende er sant:
- B inneholder A-objekter
- B registrerer A-objekter
- B bruker A-objekter
- B har data som sendes til A-objektet når det opprettes

Kontrollobjektprinsippet (Controller)
Hvilken klasse skal behandle en hendelse/melding?
- Kontrolleren ligger gjerne på klienten
- Kontrolleren har bare metoder, få eller ingen attributter
- Kontrolleren gjør ikke jobben selv, men mottar og fordeler oppgaver – er en slags
administrator
- Delegerer oppgaver og styrer use case
- Er et bindeledd mellom brukergrensesnittet og applikasjonslaget
(modellen)

Informationssäkerhet
Definisjon av informasjonssikkerhet:
– Beskyttelse av informasjonens Konfidensialitet, Integritet og Tilgjengelighet. I
tillegg kan andre egenskaper, f.eks. autentisitet, sporbarhet, uavviselighet og
pålitelighet omfattes. (ISO 27000:2018)

Krav
• Juridiske, lovbestemte, regulatoriske og kontraktsmessige krav til informasjonssikkerhet,
f.eks,:
– Sikkerhetsloven setter en rekke krav om sikkerhetstiltak for de som er underlagt loven.
– GDPR setter krav om beskyttelse av persondata.
• Krav om adekvat sikkerhet i forretningsprosesser i henhold til vanlig praksis og god
forvaltning.
– Vanlig praksis setter f.eks. krav om brukerautentisering og tilgangskontroll.
• Krav om å begrense sikkerhetsrisiko i til et akseptabelt nivå. Tiltak for dette formål
identifiseres gjennom sikkerhetsrisikovurdering og risikobehandling.
– Risikovurdering kan f.eks. sette krav om 2-faktorautentisering
alla säkerhetsfaror kan inte lösas

KIT
- konfidensialitet
- Integritet
- Tillgänglighet
-
Konfidensialitet
• Egenskapen av at informasjon ikke blir gjort tilgjengelig eller vist til uautoriserte individer,
entiteter eller prosesser. (ISO/IEC 27000)
• Trusler:
– Datatyveri (ekstern trussel)
– Datalekkasje (intern trussel).
• Sikkerhetstiltak eksempler:
– Kryptering,
– Kryptografiske kommunikasjonsprotokoller, f.eks.
TLS – Autentisering og tilgangskontroll,
– Anonymisering, f.eks. gjennom pseudonym eller VPN
– Skallsikring
– Sikkerhetskultur, bevissthet

Integritet
• Dataintegritet: Egenskapen av at data ikke har blitt endret eller slettet på en uautorisert
måte. (X.800)
• Systemintegritet: Egenskapen av å opprettholde korrekthet og kompletthet av
dataressurser (ISO/IEC 27000)
• Trusler: Ødelagte data og miskonfigurerte systemer
• Sikkerhetstiltak eksempler:
– Hashing, MAC, kryptering
– Konfigurasjonsstyring
– Endringsledelse
– Autentisering
– Tilgangskontroll
– Sertifisert programvare
– Sikkerhetskultur, bevissthet

Tilgjengelighet
• Egenskapen av at data og tjenester er tilgjengelige og anvendbare ved forespørsel fra en
autorisert entitet. (ISO/IEC 27000)
• Trusler:
– Tjenestenekt (DoS / DDoS)
– Løsepengevirus
– Forsinkelse av tidskritiske funksjoner.
• Sikkerhetstiltak eksempler:
– Redundans av ressurser,
– Failover-konfigurasjon
– Brannmur
– Sikkerhetskopiering (backup)
– Hendelsesrespons og beredskap,

• Verdier: (Informasjons)ressurser som er av verdi for organisasjonen.

– Data, systemer, applikasjoner, nettverk, enheter, tjenester, mennesker Mål for
informasjonssikkerhet er å beskytte verdienes KIT, avhengig av behov.
– Person(opplysnings)vern

• Generell modell for risiko

– Jo større og flere verdier du har, jo større og flere trusler du er utsatt for, og jo mere sårbar
du er, desto større risikoeksponering har du.

• På fagspråket er den en klar forskjell:

– Risiko er en relevant kombinasjon av trussel / sårbarhet / hendelse som utgjør et brudd på
KIT + P for en verdi. Risikoidentifisering er å kartlegge slike relevante kombinasjoner.

– Risikonivå (også kalt risikoeksponering) er kombinasjonen av hendelsens sannsynlighet

og konsekvens. Risikonivå beregnes med risikoanalyse.
Sikkerhetstiltak – ulike faser
• Preventive tiltak:
– Forhindre og avskrekke angrepsforsøk
• Eksempel: kryptering av filer for konfidensialitet
• Detektive tiltak:
– Varsle angrep som forsøkes eller som allerede er skjedd. Eksempel:
Inntrengingsdeteksjon (IDS)
• Korrigerende tiltak:
– Gjenopprette skade på dataressurser etter angrep.
• Eksempel: Hente backup av programmer og data ved tap/kompromittering av ressurser
• Det er alltid nødvendig å benytte en kombinasjon av tiltak fra alle tre faser for å
opprettholde dekkende beskyttelse
Personvern i grunnloven •
§ 102: Enhver har rett til respekt for sitt privatliv og familieliv, sitt hjem og sin
kommunikasjon. Husransakelse må ikke finne sted, unntatt i kriminelle tilfeller. Statens
myndigheter skal sikre et vern om den personlige integritet.

Personopplysninger er alle opplysninger og vurderinger som kan knyttes til deg som
enkeltperson.
Begrepet «personopplysning» er ekvivalent med persondata eller personinformasjon.
Person(opplysnings)vern er å beskytte spesifikke aspekter ved personopplysninger:
• Forhindre urettmessig innsamling og oppbevaring av personinformasjon
• Forhindre urettmessig bruk av innsamlet personinformasjon
• Sørge for at personinformasjon er korrekt
• Sørge for åpenhet og innsyn
• Sørge for adekvat informasjonssikkerhet (KIT) rundt personinformasjon
• Definere klar ansvarsfordeling

Personvernombud Personvernombudet gir råd til behandlingsansvarlige eller

databehandleren om forpliktelser som virksomheten har etter personvernloven. Alle
virksomheter kan ha personvernombud.
Personvernombud må oppnevnes når:
• Behandlingen utføres av en offentlig myndighet.
• Databehandlingen har en art, omfang og/eller formål som krever regelmessig og
systematisk monitorering i stor skala.
• Behandlingsansvarliges eller databehandlerens hovedvirksomhet består av behandling i
stor skala av særlige kategorier av opplysninger i henhold til artikkel 9 (sensitive
personopplysninger) eller personopplysninger knyttet til straffedommer og straffbare forhold
som er nevnt i artikkel 10.

Mulige konsekvenser av dårlig personvern

• Personlig belastning
• Uønsket oppmerksomhet
• Forskjellsbehandling
• Identitetstyveri eller
–bedrageri
• Økonomisk tap
• Skade på omdømme
• Tap av fortrolighet for taushetsbelagte personopplysninger
• Uautorisert oppheving av pseudonymisering
• Andre økonomiske eller sosiale ulemper
se: https://www.uio.no/studier/emner/matnat/ifi/IN1030/v22/forelesningsressurser/in1030-
2022-04-19-informasjonssikkerhet-krav.pdf

Kontrakt

Kontraktens innhold
• Partene •
Leveransen
– Bistandsforpliktelse
– Spesifisert resultat
– Definert tjenestenivå eller kvalitet
• Fremdriftsplan
• Prismodell
– Variabel pris
– Fastpris
– Målpris
– Ytelsesbasert pris

Utordringer i store IT-prosjekter

• Uklar målsetting og manglende avgrensning
• Udefinerte suksesskriterier • Usikkerhet håndteres ikke underveis
• Mange endringer underveis i gjennomføringen
• Systeminnføring blir undervurdert
– ofte betydelige krav til omstilling i organisasjonen
• Manglende kompetanse og prosjekterfaring hos deltagerne
• Dårlig kommunikasjon mellom kunde og leverandør
• Prosjektene blir for store og komplekse
• Erfaringer underveis blir ikke tilstrekkelig hensyntatt
Hva er "Smidig"?
• Forretningsverdi som viktigste kvalitetsmål
• Kontinuerlig prioritering av funksjonalitet ut fra kost/nytte
• Tett dialog mellom fagpersoner og utviklere
• Autonomi: Selvorganiserte tverrfaglige team
• Korte iterasjoner
• Hyppige leveranser til produksjon
• Beslutninger tas så sent som mulig ("Rolling Wave Planning")
• Evaluering, læring og forbedring underveis

Fordeler og ulemper med "Smidig"

Fordeler
• Rask igångsättning
• Lite ressursbruk på kravspesifikasjon og endringshåndtering
• Fleksibilitet
• Brukerinvolvering
• Absorberer læring underveis
• Løpende, gradvis ferdigstillelse
• Kompetanseoverføring
• Effekivitet
Ulemper
• Begrenset ansvarliggjøring av leverandør for resultat og budsjett

Vi kan ikke løfte begge vektskålene samtidig...

Mange kunder erkjenner ikke hva som er konsekvensene av å velge smidige prosesser…
• Kvalitet / Scope • Kostnader
• Tid …
- og inkluderer spesifikasjon av funksjonelle krav i kontrakten
• …men endringshåndtering avvises, fordi dette underminerer smidigheten
• …og avvik mellom avtalt og levert scope utgjør mislighold av kontrakten

Anskaffelsesprosess - Tradisjonell vs Smidig

Tradisjonell prosess
• Kravs- og løsningsspesifikasjon
• Tilbudsinvitasjon
• Tilbud
• Evaluering / Forhandlinger
• Kontraktsinngåelse
• KontrakYorvaltning
• Avslutning
Smidig prosess
• Tilbudsinvitasjon
• Tilbud
• Evaluering / Forhandlinger
• Kontraktsinngåelse
• Kravs- og løsningsspesifikasjon
• Kontraktforvaltning • Avslutning
"Den perfekte kontrakten for programvareutvikling" …avhenger av bruksområde, men
vil kunne være:

"Fossefall"; når resultatet er klart spesifisert, og omfang og kompleksitet er begrenset

"Seriefossefall"; når resultatet kan defineres på overordnet nivå og partene er enige om å

følge en avtalt gjennomføringsmodell hvor resultatet i hver delleveranse spesifiseres
underveis

"Ressurskjøp"; når det skal utvikles etter smidig metode eller resultatet av andre grunner
ikke er klart definert

Eller kanskje en smidig kontraktmodell hvor leverandøren aldri overtar det kontraktsansvaret
for funksjonaliteten, men likevel er ansvarlig for ressurser, å følge avtalt
gjennomføringsmodell og definerte ikke-funksjonelle krav

Till examen:

Fattas något i denna?

https://www.uio.no/studier/emner/matnat/ifi/IN1030/v21/timeplan/
gruppe7_notater_varen21.pdf
lösningsförslag:

v20
v21 https://www.uio.no/studier/emner/matnat/ifi/IN1030/v22/tidligere-eksamensoppgaver/
losningsforslag-2020-2.pdf

Bra källor:
WCAG2.0
https://www.w3.org/TR/WCAG20/ (W3C, 2008)
Personvernsloven
https://lovdata.no/dokument/NL/lov/2018-06-15-38 (Lovdata, 2018)

diskrimineringsloven
https://lovdata.no/dokument/NL/lov/2017-06-16-51?q=Diskrimineringloven (Lovdata, 2017)
inom universiell utforming:
https://lovdata.no/dokument/NL/lov/2017-06-16-51?q=Diskrimineringloven#KAPITTEL_3
Krav https://www.uutilsynet.no/regelverk/regelverk/266
(Lovdata, 2017)
Åndsverksloven
https://lovdata.no/dokument/NL/lov/2018-06-15-40 (Lovdata, 2018)
arbetsmiljöloven
https://lovdata.no/dokument/NL/lov/2005-06-17-62 (Lovdata, 2005)

Smdiig:
101 https://www.agilealliance.org/agile101/ (Agile Allience, 2022)
12 priciples of manifesto https://www.agilealliance.org/agile101/12-principles-behind-the-
agile-manifesto/ (Agile Allience, 2022)
Mainfesto: https://www.agilealliance.org/agile101/the-agile-manifesto/ (Agile Allience, 2022)

smidig vs waterfall samt pros/cons om varje:*

https://www.edrawsoft.com/agile-vs-waterfall.html (eDraw,James Freeman, 2021)
smidig 101
https://dzone.com/articles/the-difference-between-agile-programming-vs-agile (DZone,
Alesia Krush, 2018)
Scrum vs Kanban:
https://www.atlassian.com/agile/kanban/kanban-vs-scrum (Atlassian, Max Rehkopf, 2022)