INF112 CS
| Nr. | Tema | Fullført | Hvem? |
|---|---|---|---|
| 1 | Kommunikasjon | Arild | |
| 2 | Testing | Vetle/Vabø | |
| 3 | Prosjektmetodikk | Vetle | |
| 4 | Versjonskontroll | Vabø | |
| 5 | Spesifisering og krav | Mathias | |
| 6 | Planlegging/MVP | André | |
| 7 | Realisere et krav, akseptansekriterier og Intro til UML | Lars | |
| 8 | Refaktorering | Mathias | |
| 9 | Logging | Lars | |
| 10 | Introduksjon til Design og UX | André | |
| 11 | Build/deploy/arkitektur | Mathias | |
| 12 | Kodekvalitet | Arild | |
| 13 | Personvern/etikk | Arild | |
| 14 | Designmønstre | Lars | |
| 15 | Lovverk, åndsverk og lisenser | Vetle | |
| 16 | Sikkerhet og brukbarhet | André | |
| 17 | Spørsmål og svar fra tidligere eksamener | ||
| 18 | Ordbok | ||
| 19 | Mulige tema for eksamen | Vetle |
Vellykket kommunikasjon er tilfellet når:
- Meldingen betyr det samme for mottaker og avsender
- Meldingen er nyttig for mottakeren
- Epost
- Chat
- Issue tracking
- Ansikt til ansikt
- Møter
- Telefon/video
- Tekst og figur
- Både dokumentasjon og kode er tekst. Begge er kommunikasjonskanaler.
Eksempler på hvordan å etablere en forståelse, som videre kan brukes til å forbedre kommunikasjon og samarbeid:
- Alle sliter med å forstå andre innimellom: Sett kontekst
- Finn ut hva kommunikasjonen handler om
- Finn ut hvilken relevant bakgrunn personen du kommuniserer med har
- Finn ut hva du ønsker å oppnå med kommunikasjonen
- Finn ut om mottaker har fått nok informasjon til å kunne ta stilling til det du ønsker å ta opp
- Pass på å fortelle om antagelser når dere diskuterer
- Vær åpen for diskusjon: åpen for å greie ut misforståelser basert på upresis ordbruk
- Tips: bruk fraser som: "Jeg forstår det på følgende måte, korriger meg gjerne om jeg tar feil"
- "Har jeg forstått det riktig at .. "
- "Jeg oppfatter at .... , stemmer dette?"
Eksempler hvordan kroppsspråk kan brukes til å forbedre kommunikasjon og samarbeid:
- Utrykke avslappethet ved å senke skuldre, være blid og åpen for kommunikasjon
- Øyekontakt (tillit), ansiktsmimikk
- Ikke stå over noen andre, prøv å være på samme høydenivå, eksempelvis ved å sette seg ned
- Ikke invader andres personlige område
- Ikke vær bakoverlent med kryssede armer/ben (antyder negativitet)
- Vær fremoverlent (antyder interesse)
- Uavhengig av hvilken måte vi samarbeider på, må vi være trygge for å klare å være effektive
- for andres tid
- for andres oppmerksomhet
- alle blir frustrerte over ting uten nytteverdi, vær kritisk til hvem som blir inkludert
- tilstrekkelig mengde informasjon: nok til å forstå, ikke mer enn nødvendig
- alle er travle
- for andres forståelse
- for andres mangel på forståelse
- Viktig prosjektorganiseringsverktøy
- Eksempler: Github Project board, Trello, Jira osv.
- Kan også være fysisk: tavle med lapper
- Formelt, brukes av både team og kunder/brukere
- Inneholder: hvilke arbeidsoppgaver finnes?
- Inneholder: Hva er status på arbeidsoppgaver?
- Inneholder: Hvem jobber med hva?
- Inneholder: Kommentarer på pågående oppgaver
- Inneholder: Historie på kommunikasjon og valg som blir tatt på oppgaver
-
Lag et arbeidsmiljø som tilrettelegger for begge parter (like my plass, to tastatur, to skjermer, etc)
-
Interkasjoner som gjør samarbeidet lettere. (Hei hvordan har du det og lignende piss)
-
Dette fører til regelmessig feedback.
-
Vi har to roller: driver og navigator
-
Driver er den som styrer tastur og mus, med andre ord den som koder
-
Navigator er den som ser på koden, stiller kritiske spørsmål og ser på hvordan koden vil passe inn i det større bildet (prosjektet)
-
Viktig å bytte roller ofte, slik at begge er likestilt og man oppnår flere perspektiv
- Bedre kunnskapsdeling: to stk har dyp forståelse av problemet
- To hoder tenker bedre enn ett, særlig på komplekse problemer. Bare det å forklare løsningen din for andre gjør at du forstår den bedre selv.
- Løser problemet fortere totalt sett, selv om det virker som om det går tregere i begynnelsen
- Utforsker flere måter å løse problemer på
- Færre feil
- Veldig ulike personligheter kan ha problemer med å jobbe sammen
- Noen foretrekker å jobbe alene, er evt bare ikke vant til å jobbe sammen med andre
- Slitsomt der og da (veldig intenst)
- Ulike arbeidsmetoder (feks cowboy mot planleggeren)
- Kan være lett å bli distrahert
- Kode er ekstremt personlig, tanke oversatt direkte til tekst
- Mange tar kritikk av kode som personlig kritikk
- Hvis du reagerer på noe: hva kan være et alternativ? Vær løsningsorientert, ikke problemorientert
- Partner er ikke tankelesere, forklar retningen du beveger deg i. Vær høflig, profesjonell, konstruktiv
Tester skrives først, før det finnes noe annen kode. Koden skrives for å få testene til å passere, og hver gang man får syntaksfeil (klasse som mangler etc.) kan man implementere det som mangler. Når koden kompilerer vil testen feile og man kan begynne å implementere forretningslogikken.
Et annet viktig prinsipp er at det ikke skal skrives mer kode en det som krever for å få testen til å bli grønn
Når testene passerer kan man begynne å refaktorere for å forbedre koden.
Fokus på testing gjør koden mer testbar og uavhengig (mindre rigid kode). Dette gjør det lettere å gjøre endringer i koden over tid.
Det er viktig at kvaliteten på testene er høy slik at testene ikke hindrer nødvendige endringer i koden
TDD følger denne rekkefølgen: Red (tester feiler) -> Grønn (tester passerer) -> Refaktorering (Øke kodekvalitet, lesbarhet etc.)
Tester skal følge denne formen: Arrange, act and assert.
Det finnes tre lover i TDD:
- Det er ikke tillat å skrive mer på testen enn det som holder for at den skal feile. Compilation feil er også feil. Engelsk: You are not allowed to write any more of a unit test that is sufficient to fail, and compilation failures are failures
- Det er ikke tillat å skrive NOE produksjons-kode som ikke gjør at en test passerer. Engelsk: You are not allowed to write any production code unless it is to make a failing unit test pass
- Det er ikke tillat å skrive mer produksjons-kode enn det som gjør at testen passerer. Engelsk: You are not allowed to write any more production code that is sufficient to pass the one failing unit test
I tillegg finnes det tre lover for å skape fremdrift i TDD:
- Fake it: Returnér det som trengs. Det er bedre å ha noe som fungerer enn ingenting.
- Obvious implementation: Hvis du er sikker på hva som skal til for at testens skal passere, skriv det!
- Triangulation: Del opp problemet i mindre deler og løs disse.
Enhetstester tester spesifikke deler av systemet. De tester ofte funksjoner eller deler av funksjoner. De skal være raske ettersom de skal kjøres ofte.
Integrasjonstester tester spesifikke deler av systemet og at disse interagerer på riktig måte. Disse tar ofte lengre tid, og kjøres ikke like ofte som enhetstester.
GUI-tester tester elementer av GUI, enten manuelt eller automatisk. Disse kan teste at oppførselen er korrekt, feks at de rette elementene dukker opp når en knapp klikkes på.
Mock-tester tester funksjoner som interagerer med moduler eller eksterne API-er (ofte databaser). Disse brukes ved behov for å kontrollere ytre faktorer. Disse kan redusere mengden integrasjonstester.
System-tester tester helheten av systemet, i kontrast til integrasjonstester som tester koblingen mellom deler av systemet. Disse tester hele stacken - frontend, backend, forretningslogikk, persistance-layer osv.
Ytelsetester utforsker grensene til ytelsen av et system. Disse genererer reelle (eller enda større) last på et kjørende system. Disse brukes ofte sammen med analyseverktøy for å sjekke hvordan ulike moduler oppfører seg.
Regresjonstester. En regresjon er at noe som har virket tidligere, slutter å virke i senere tid. Disse tester at all den eksisterende funksjonaliteten fortsatt virker etter du har lagt på ny funksjonalitet.
Akseptansetester utføres ofte av en kunde med det formål å godkjenne eller underkjenne ny funksjonalitet, enten det er manuelt eller automatisk.
Utforskende tester handler om å utforske programvare, gjøres manuelt. Feks klikke på rare og uventede steder i brukergrensesnittet. Gjøres som oftest på system- eller integrasjonsnivå.
Sikkerhetstesting og penetrasjonstesting tester programvaren for å se om systemet tilfredstiller sikkerhetskrav. Disse er gjerne en kombinasjon av manuelle og automatiske.
Hypotesetesting brukes ofte for å teste matematiske funksjoner/komplekse scenario der du trenger tilfelidgheter/mye ulik input.
Tester er en form for dokumentasjon, den viser hvordan koden er ment til å brukes. De avslører også antagelser. Testkode er også kode, som krever samme type vedlikehold og omtanke som resten av prosjektet.
Open-Closed Principle handler om at koden skal være åpen for utvidelser og stengt for modifikasjon. Når koden får nye funksjonaliteter, skal man ikke måtte endre koden som allerede eksisterer. Ideelt sett skal man kunne legge til ny kode og alt som eksisterte skal fungere som før
Praktisk sett bruker man Interfaces i open-closed principle for å forhindre modifikasjon av eksisterende kode selv om man legger til ny funksjonalitet.
It-bransjen er en umoden bransje (vi regner fra 60-tallet), dette har konsekvenser som at utviklingen går veldig fort og vi vet enda ikke hva som virkelig fungerer (prosjekt-metodikker). Prosjekt- og arbeidsmetodikk handler om hvordan folk skal samarbeide.
Et prosjekt har en livssyklus: Planlegging/utredning -> Implementasjon -> Forvaltning, som gjentar seg gjennom hele levetident il prosjektet. Et prosjekt er aldri helt ferdig (vedlikehold og forvaltning).
Verden er i hurtig og konstant endring, derfor trenger vi smidige prosjekt-metodikker som tar høyde for disse endringene fortløpende. De alle fleste (om ikke alle) prosjektmetodikker idag følger til varierende grad "Agile manifesto".
Agile manifesto handler om hvordan vi vil jobbe, og om hva som egentlig er viktig i et utviklingsprosjekt. Denne inneholder 4 punkter (eller regler) om hvordan utvikling bør foregå:
-
Individuals and interactions over processes and tools En person i et prosjektteam er ikke en ressurs, denne personen har en unik kompetanser, bakgrunn, kontekst og synspunkter. Stor kostand involvert i å bytte ut et team-medlem.
-
Working software over comprehensive documentation. Tidligere kunne software bli levert med enorme avhandlinger av dokumentasjon. Problemet er at dokumentasjonen lyver ofte, særlig hvis det er mye av det. Nå er vi mer kritisk til hva som skal inngå i dokumentasjonen, og vi skal ikke bruke mer tid på å skrive dokumentasjon enn kode. Hvis løsingen/koden krever dokumentasjon for å være brukbar, er det mest sannsynlig et symptom på et annet problem.
-
Customer collaboration over contract negotiation Best resultat ved hyppig dokumentasjon med kunden. Kontraktene burde heller si noe om hvordan samarbeiud skal foregå og rammene, men ikke hva som skal lages (i mer enn veldig overordnede former.)
-
Responding to change over following a plan Vi vet at verden endrer seg, derfor kan vi ikke planlegge over lengre tid. Ved tett kontakt med kunden kan vi oppdage feil fortløpende og rette opp i eventuelle feil, eller endre planen.
Prosjekt-metodikker er en samling av ulike teknikker for få prosjekter til å fungere bedre. De første metodikkene involverte strengere regler, med mange roller og aktiviteter, senere metodikker har mindre føringer. Nå er de aller fleste metodikker smidige og følger Agile Manifesto. Felles for disse er noen viktige punkter:
- Ikke planlegge altfor langt frem i tid.
- Lage de viktigste tingene først. Dette gir et brukbart system raskere, derav raskere feedback.
- Prøve å ikke gjøre for mye på en gang
- Alle i teamet skal være i samme båt
- Lære av det som allerede er gjort
- Jevnlig tilbakemelding!
Extreme Programming eller XP regnes som en rigid arbeidsmetodikk og handler i stor grad om aktivitetene som skal til for å få et prosjekt til å bli vellykket. Dette er daglige aktiviteter som teammedlemmer utfører for å høyne kvaliteten på prosjektleveranser og arbeidsmiljøet. Noen av de vanligste er; testdrevet utvikling (TDD), parprogrammering, kodekvalitetsprinsipper, Continous Integration (CI), akseptansetester etc. Første aktivitet i XP er vanligvis en planleggingsfase hvor målet er å få ned historier (gjøremål) som er viktigst. Dette hovedsaklig for å få en oversikt over overordnede mål. Denne aktiviteten gjentas hver 2. til 3. måned (også kalt release). Så startes en iterasjon i XP, hvor oppgavene fra første fase brytes ned i mindre oppdager som skal ferdigstilles på 2-3 uker. Etterhvert kan man justere farten (hvor mange oppgaver i en iterasjon) etter hvor lang tid teamet bruker på hver oppgave. Sentralt i XP er feedback-loopen, på flere nivåer. Vi får umiddelbar feedback fra parprogrammering eller TDD. Vi får daglig feedback fra standup eller fordeling av hvem som jobber med hvem. Vi får ukentlig feedback gjennom akseptansetester. Vi får feedback hver 2. til 3. uke etter hver iterasjon og planning av neste iterasjon. Annet viktig punkt med XP er at ingen oppgaver skal inn i en påbegynt iterasjon. XP har vanligvis roller slik som programmerer, tester, coach osv. Coach er den som har oversikt på teamet og sørger for at alle klarer å levere så bra som mulig.
Scrum fokuserer mindre på aktiviteter (som pargrammering, TDD) og er derfor mindre rigid enn XP. Derimot har den et likt tidsperspektiv som XP, en iterasjon i XP kalles en sprint i Scrum. Denne sprinten varer vanligvis i 2-4 uker. Sprinten starter med en planlegging av hva som skal inngå i sprinten. Etter sprinten, utføres en retrospektiv hvor man ser tilbake på hva som funket/ikke funket. Det finnes ingen regler for hvordan team-medlemmer jobber sammen eller organiserer seg, det finnes derimot en begrensning på arbeidet i en sprint/iterasjon. Det er ikke lov å legge inn flere oppgaver enn det som kan løses i en sprint og det er ikke lov å legge inn nye oppgaver i en påbegynt sprint. Rollene i Scrum er vanligvis produkteier (utenfor team), scrum master, utvikler osv. Scrum master har ansvar for at prosjekt-metodikken følges og utføres riktig.
Kanban er den minst rigide av disse prosjekt-metodikkene og den som setter minst begrensninger. I motsetning til XP og Scrum, har vi ingen iterasjon eller sprint, det handler om kontinuerlig flyt. Til enhver tid vil det være oppgaver i alle deler av prosjekttavlen og teamet avgjør når det er behov for å planlegge mer arbeid. På grunn av dette setter Kanban større krav til disiplin, men tillater samtidig endriger når det er nødvendig. Den enest reelle begrensningen i Knaban er antall oppgaver som kan utføres samtidig.Dette fordi kontekstbytte er kostbart! Antallet er noe teamet blir enige om.
Vi avslutter med noen viktige punkter om prosjekt-metodikker:
- Målet er rask feedback. Derfor vil vi begrense arbeidsmengene til enhver tid og så prioritere på nytt etter feedback.
- Vi må kunne nedre kurs ved behov. Lær av fortiden og feedback.
- Levere verdi kontinuerlig. Ved å levere hurtig, får kunden verdi raskt.
Illustrasjon av Scrum vs Kanban
Working Directory er arbeidsområdet ditt lokalt på en disk der du har sjekket ut en gitt commit fra et repository.
Staging area er der git får oversikt over alle endringene som er gjort og som skal legges til i git. Basert på disse endringene beregner git en hash som er summen av endringene som gjøres. Når du gjør git add blir endringene i filene tatt med fra working directory til staging area. Når du så gjør git commit vil alle endringene som er lagt til i staging area legges til i ditt lokale repository, hvor alle endringene du har gjort også er lagt til.
Versjonskontroll gjør at du sporer endringene du har gjort. Du får oversikt over hvilke endringer som er gjort, når, og av hvem. Du får backup hvis du har arbeidet på ulike enheter, du er garantert at det er samme versjon av koden så lenge alle har samme commit. Lettere å dele kode. Lettere å eksperimentere fordi du kan kaste endringene og gå tilbake til “forrige save” (forrige punkt der du vet at koden virker). Reduserer risiko ved å gjøre endringer og øker tryggheten når man utvikler (gitt ryddig commit-historikk og regelmessige commits).
Som [bruker/rolle] ønsker jeg [funksjonalitet] slik at [behov oppfylles].
En god brukerhistorie er konkret. Den er skrevet på en måte slik at alle har samme forståelse av hva som skal lages og hva dette oppnår. En brukerhistorie skal ikke inneholde implementasjonsdetaljer, kun behov. Hva problemet er ikke hvordan det skal løses.
Brukerhistorier skrives etter et format for å oppfylle et behov som må utvikles og hvem som har dette behovet. Grunnen til at dette korte formatet brukes er for å raskt få et overblikk over hvilken funksjonalitet som oppfyller hvilket behov. Slik at en ikke skal trenge å sette seg inn i hele problemstillingen som er som kunden/teamet skal takle for å levere funksjonaliteten som trengs. Dette kan være veldig verdifullt når en sitter i møte hvor mange forskjellige aspekter av en problemstilling skal diskuteres, det hjelper også med å spare tid når spesifikke ting ved utviklingen skal diskuteres.
- For store brukerhistorier også kalt isfjell. Detter fører til usikkerhet når brukerhistorien er ferdig og når akseptansekravene er oppfylt. Samt at hver brukerhistorie tar veldig lang til.
- Brukerhistorier uten verdi også kalt kråkesølv. Kan virke som brukerhistorien gir oppfyller et behov som gir verdi, men egentlig ikke gir verdi for brukeren av systemet.
- Uklare brukerhistorier hvor det kan være veldig vanskelig å få en felles forståelse for hva som skal lages og hvilke akseptansekrav brukerhistorien oppfyller for det endelige produktet.
- Historier uten begrunnelse hvor det ikke blir beskrevet hva slags behov en slik brukerhistorie vil oppfylle for bruker.
Et akseptansekriterie er et mål for tilstanden til programvaren for at den skal tilfredsstille et krav fra enten bruker eller en integrasjon. Et slags sluttkriterie for et system som må oppfylles for å bli godkjent av en autorisert enhet. Akseptansekriterier brukes for å definere og bekrefte forventet resultat på funksjonelle og ikke-funksjonelle krav. En er gjerne ferdig med en brukerhistorie når akseptansekriteriet er oppfylt.
- Setter en ramme for hva som skal med i en brukerhistorie og ikke.
- Definerer planlagt feilhåndtering.
- Sørger for at alle brukerhistorier blir forstått på samme måte av alle. (Siden den konkretiseres)
- Kan være med på estimeringen siden det blir tydeligere hva som må realiseres.
Nøkkelpunkter angående akseptansekriterie
- Testbart
- Klart definert
- på formen "gitt x så y"
- Kan forstås entydig
- engelsk: requirements
- et krav er akkurat det det høres ut som, noe systemet skal gjøre
- Deler disse inn i to hovedtyper, funksjonelle og ikkefunksjonelle krav
- Funksjonelle krav: presis beskrivelse av hva et system skal gjøre, ofte gitt i form av hvilken output en bestemt input gir
- Eksempel: Systemet skal la en student melde seg opp i et fag
- Eksempel: Systemet skal la foreleser sende ut beskjeder til alle som tar faget
- Ikke-funksjonelle krav: beskrivelse av begrensninger eller krav til systemet som ikke direkte omhandler hvilke oppgaver systemet skal utføre
- Handler om feks responstid, oppetid, sikkerhet, integrasjoner mot andre systemer, hvilke platformer tjenesten er tilgjengelig på osv.
- Eksempel: Systemet skal være brukbart for blinde
- Eksempel: Systemet skal ha oppetid på mer enn 99,99%
- Mange har tidligere skilt veldig på funksjonelle krav og ikke-funksjonelle krav, men i praksis havner alle kravene i samme spesifikasjon
- OBS: Beskriver sjelden behov/problemer som skal løses, hopper rett i løsningsmodus
- Eksempel løsningsmodus: "Systemet skal fungere både på Android og iOS"
- Eksempel behovsmodus: "Systemet skal fungere på mobil for minst 97% av brukerne"
- Krav handler ofte om HVA
- Krav er ofte overordnede, men kan også være svært detaljerte. Andre skiller på krav, use cases og brukerhistorier
- Krav kan være skumle fordi de ofte handler om HVA som skal lages
Funksjonelle krav er en preis beskrivelse av hva systemet skal gjøre ofte gitt på en input output form.
Ikke-funksjonelle krav er en beskrivelse av begrensinger til et system, som ikke direkte omhandler hvilke oppgaver systemet skal utføre. Eksempler på dette kan være:
- Responstid
- Oppetid
- Integrasjoner mot andre systemer
- Hvilke platformer systemet er tilgjengelig for
- kalles også aktører
- noen som skal bruke systemet
- noen system har bare en type bruker, de fleste har flere
- Oppgave: Mitt UiB. Hvilke roller har dette systemet? (2 min)
- Studieadministrasjon
- Foreleser
- Gruppeleder
- Student
- Dette er hovedgruppene av roller. I tillegg finnes det "subgrupper" av roller, fordi folk bruker systemene på ulike måter.
- Oppgave: hvilke roller finnes for twitter? (2-3 min) skriv resultat ned på tavlen
- Tweeter (innholdsprodusent?), tilhører, moderator, ikke-person-brukere som systemer som ønsker å tweete på vegne av noen, eller konsumere ulike typer tweets
- en rolle trenger ikke være en person, det kan også være et system
- Rolle forteller noe om hva en bruker ønsker å få utført
- Rollene som er mennesker har noen fellesegenskaper: de er mennesker som bruker systemene
- Finnes annet aspekt også: brukere sine egenskaper
- Først introdusert av Eric Ries, Lean Startup
- Konsept som går ut på at utvikleren leverer en enkel versjon av produktet til kunden, slik at kunden kan teste og gi tilbakemelding til teamet.
- Bedre for kunden å teste produktet enn at kunden skal fortelle hvordan produktet skal være.
- Kan også skaffe inntjening tidligere
- Dette kan bidra til et bedre samarbeid, og et mer velutviklet produkt som kunden er fornøyd med.
- Skaffer viktig informasjon fra kunden s.a. utviklingen blir mer effektiv.
- Mest mulig læring for minst mulig jobb
- Har nok features til: -validere det som skiller dette produktet fra andre -tiltrekke seg noen første brukere
- prøve ut høy risikoelementer
Viktig:
- MVP skal inneholde delene av prosjektet der det er høyest risiko (tekniske planet og funksjonalitetsmessig), prioriteres først.
- Teknisk vanskelig å få til . '
- Virksomhetskritisk funksjonalitet.
- Inneholde funksjonalitet som er viktig for brukeren.
- Sikrer at hele stacken blir utprøvd: Persistering, kommunikasjon, forretningslogikk og brukergrensesnitt.
- Tester også at bygg- deploy fungerer.
- Mer detaljering av problemet.
- Gå i dybden på noen brukerhistorier og gjøre dem om til noe som det går an å jobbe med.
BDD er en agile utviklingsmetodikk som sentrerer seg rundt akseptansekriterier og bygger på Test Driven Development. Utviklingen er eksempeldrevet hvor vi finner avgrensninger og funksjonalitet i systemet ved hjelp av konkrete eksempler. Den oppfordrer til samarbeid mellom utviklere. BDD følger de samme prinsippene som TDD, men skiller seg ut i forhold til ønsket utfall/oppførsel av en enhet av programmet. Her er det forretningslogikken som sier hvilke kriterier den ønskede oppførselen skal være.
Outside-in development skiller seg fra andre agile software development metoder i form av at fokuset ligger i å prioritere aksjonærene(shareholders). Teorien er at for å lage god software, må utviklerne ha en god forståelse av målene og motivasjonen til aksjonærene. Målet med metoden er å lage et forbruksvennlig produkt som møter eller overgår forventningene til klienten. Outside-in er ment til å supplere eksisterende software devlopment metoder.
UML står for unified modelling language. Det er et visuelt språk for å vise flyt og relasjoner. Vanlige bruksområder der alle disse handler om oppførsel og modellering av oppførsel:
- Flyt gjennom program
- Oppgaverekkefølge
- Interaksjonsdesign
To eksempler på bruk av UML:
- Relasjon mellom klasser/moduler (klassediagram)
- Eksempler på objekter med verdier (objektdiagram)
Mer informasjon her:
- Inneholder klassenavn
- Lister viktige variabler/egenskaper ved klassen
- Lister viktige metoder
- Som oftest vises ikke alt
- Viser relasjon mellom to klasser vha linjer
- Hva er en relasjon?
- Annotasjoner på linjene definerer hvilken type relasjon to klasser har
- Tegn opp: en til en, en til mange, arv, interface
- Representerer en tilstand på et gitt tidspunkt i applikasjonen
- Viser klasser som er instansiert til konkrete objekter
- Tegn inn hvilke verdier ulike felter i klassene har på det tidspunktet
- Brukes ofte for å forklare endringer i tilstand på ulike tidspunkt
- Viser relevante feltvariabler (de som er viktig for det man diskuterer)
- Viser ikke metodesignaturer
- Refaktorere variabelnavn slik at de gir mening og er selvforklarende.
- Trekke ut konstanter som bruker flere plasser i koden.
- Fjerne unødvendige kommentarer.
- Trekke ut store mengder kode som passer sammen i selvstendige metoder slik at hele koden blir mer oversiktlig.
Logging er en lagret liste av hendelser sortert på tid. Den inneholder:
- Tidspunkt
- Hva
- Hvem
- Resultat
Det er analyse av logger som avdekker innbrudd, som f.eks. det hos Equifax. Her ble informasjonen(også personlig identifiserende informasjon(PII)) til 150 millioner amerikanere og 15 millioner briter sendt på avveie. Logging er data for andre brukere enn primærbrukrne av et system. Dette kan være trafikkhistorikk, bruksmønstre eller overvåkning(oppdage at ting som ikke burde skjedd har skjedd). Logging har evnen til å hente ut informasjon for å svare på spørsmål vi ikke vet enda.
SLF4J - Simple Logging Facade for Java er et standardisert grensesnitt for logging i Java.
Hva skal logges?
- Vesentlige hendelser. Kan være opprettelse av bruker, sletting av bruker, logget på, logget av
- Uventede hendelser. Kan være exeptions, try/catch
- Kontakt med verden utenfor
Hva skal ikke logges?
- Store binære datastrømmer
- Informasjon dekket av GDPR
- PCI-DSS - Payment Card Industry Data Security Standard
- Personlig indentifiserbar informasjon
- Handler om å skape best mulig brukeropplevelse
- God brukeropplevelse:
- Useable
- Må være designet til å være enkel å bruke og forstå
- Useful
- Må dekke alle behov og være brukbart for målgruppen
- Desirable
- Systemet bør være ønsket av brukeren, med bruk av bilder, identitet og merkevare
- Accesible
- Tilrettelagt for brukere med spesielle behov (Bline, fargeblinde, høreselhemmede etc)
- Credible
- Brukerne må kunne stole på informasjonen i Systemet
- Valuable
- Useable
- Hva er viktig å legge vekt på?
- Prosess, design og brukervennlighet
- Skal ikke bare "se fint ut", må også fungere
- UX pyramiden Link
- Fokusere på det grunnleggende først
- Handler om å gjøre prioriteringer innenfor gitte rammer, Tid, kostnad er ofte slik rammer.
- Hva er viktig å huske på som UX designer?
- Logisk for deg som utvikler (designer) er ikke nødvendigvis logisk for andre
- Ikke anta hva bruker tenker og vil gjøre
- Vis heller løsningen til andre og få feedback
- Viktig å huske på at UX kommer tidlig inn i utviklingsprosjektet
- UX briller: Typisk yrkesskade som rammer de som jobber med brukeropplevelse og design
- De trenger også en god brukeropplevelse når de jobber med utvikling, testing eller andre deler
- Hva definerer god DX?
- Automatisering
- Repetetive oppgaver
- Arkitektur
- Enkel vs kompleks oppsett og drifting
- Kultur og prosess
- Dekker behovet til utvikleren, samt at det skal være gøy å utvikle.
- Automatisering
- Noen lager forvirrende design med vilje for å "forvirre brukeren"
- Dark patterns:
- Lage et system som endrer brukerens atferd
- Typiske lurespørsmål, skjulte kostnader, villedning,
- Eksempel:
- I 2010 ble Amazon anklaget av forbrukerrådet for å gjøre det mest mulig vanskelig for brukeren å avslutte abonnomentet.
Det finnes forskjellige byggeverktøy for forskjellige språk. Det mest modne og brukte for java er Maven. Dette verktøyet automatiserer mye i bygge prosessen slik at når en endrer og refaktorerer kode kan en bygge projektet ved hjelp av disse verktøyene for å være mer sikker på at koden er produksjonsklar før den eventuelt blir deployet. Hele byggeprosessen er bygget opp av flere steg
- Valider (Pass på at det er korrekt prosjekt og at all nødvendig informasjon er til stede)
- Kompiler (Kompiler kildekoden)
- Test (Test den kompilerte koden)
- Pakk (Ta den kompilerte koden og pakk den i distribuerbart format, feks. JAR)
- Verifiser (Kjør sjekker på resultater på integrasjons testene)
- Installer (Installer pakkene til det lokale repoet)
- Deploy (Ferdig i det lokale byggemiljøet. Sendes nå til et remote repo, se under)
Å deploye en tjeneste er å kopiere og kjøre filer til en ekstern server/skyen/din egen maskin, hvor denne tjenesten kan kjøres kontinuerlig slik at den alltid er tilgjengelig for kunden/brukeren av tjenesten. Dette gjøres hver gang ny funksjonalitet skal bli gjort tilgjengelig for brukeren av systemet.
Produksjonskode har andre krav en proof of concept kode. Produksjonskode varer ofte over lengre til og er der for å levere funksjonalitet til en kunde/bruker i form av en tjeneste. Mens POC-kode ofte blir skrevet for å bevise at noe går ann eller gjøre eksperimenter i bransjen.
- Tjenesten er bare en eksikverbar fil som må bo på en server slik at den kan være tilgjengelig for kunden/brukeren.
- Å laste op filene til en server kalles å deployet, og dette skjer gjerne til flere miljøer.
- Må forsikres om at koden bygger hos alle, og på alle sytstemer hvor tjenesten vil bli brukt (Windows/Linux/MacOS)
- Mye testing i på en byggeserver før endringene går i prod, hvor en må være sikker på at koden kjører og at tjenesten fungerer for kunden.
- Build og deploy ble gjort manuelt før, som var tidkrevende og detaljert arbeid som gjorde at det var lett og gjøre feil.
- Koden må bli vedlikeholdt over tid.
- Tenke sikkerthet med tanke på angrep, bruk og videre utvikling
- Kontroll over utvikling og den koden som havner ut mot kunder. Trenger gjerne også integrasjoner mot eksterne systemer, ordentlig feilhåndtering (både mot bruker og mot integrasjoner)
- Vi trenger trygge, reproduserbare og forutsigbare omgivelser til produksjonskode.
- Vi ønsker å redusere risiko for å gjøre feil under utvikling, men også under produksjonssetting
- pom.xml: konfigurasjon av maven
- src/ inneholder all kildekode, både test og produksjonskode
- Pakkestruktur mellom main/ og test/ dupliseres
- Kode i java-katalog
- Andre filer som trengs (filer for testing, konfig osv) ligger i resources
- Feks ligger typisk logback.xml i src/main/resources
- Du må ha kildekode organisert etter det maven krever, ellers finner den ikke filer og ressurser den trenger for å bygge
- Enkleste eksempelet: ingen resources, tddDemo fra tdd-forelesning
- Skiller mellom test og prod-ressurser (ofte er oppsett ulikt)
- Maven genererer også filer, feks ved bygg: target-katalog i projectName-katalogen
- En tjeneste som lytter på repositoriet ditt på github (eller andre public repositories) og bygger prosjektet for deg hver gang det kommer endringer i prosjektet.
- Byggserver bygger på riktig måte, hver gang, med alle stegene du ønsker å ha med --> sikkerhetsventil
- Bygger prosjektet til release, sikrer at ikke debug-kode er med.
- Vanlige byggservere: Travis, CircleCI, Jenkins, Team City
- utvikle små, logiske biter av gangen
- skriv automatiserte tester, kjør dem ofte
- commit hver logiske bit
- før push, gjør clean install slik at du ser at kodebasen virker før du pusher koden, gjør så evt linting og andre steg hvis ikke automatikk
- alle tester SKAL kjøre før du pusher. Ellers vil bygget sentralt feile, og alle som henter ned siste versjon vil få ikke-fungerende tester og vil dermed ikke kunne jobbe effektivt selv
- Jo oftere endringer integreres med alle andre sine, jo lavere er risiko for at endringer ikke er kompatible
- Hvis alle alltid committer til master, og ikke venter lenge med å committe: continuous integration
- kalles ofte trunk based development
- hvor ofte bør man integrere? MINST en gang om dagen.
- husk: lokale endringer som ikke er delt med andre == branch, bare lokal
- oppnår to ting med jevnlig integrasjon: du vet at dine endringer virker med andre sine, og andre vet at deres endringer virker med dine
- for å klare å integrere ofte: små steg, alltid ha kontroll
- tegne på tavlen: git med ulike branches som deles i ulikt tempo
- har nevnt dette før, men særlig aktuelt med byggeverktøy
- ingen generert kode i repositoriet
- typisk skal følgende eksluderes: target, .idea (IntelliJ sin prosjektkatalog), .iml-filer, .swp-filer, .jar-filer osv.
- Ingen biblioteker heller, dette laster maven ned for deg
- slike genererte filer endres ofte og alle vil "ødelegge" for hverandre siden alle filene som genereres vil være ulike
- gir også grisete git-log fordi disse filene endres i HVER commit fra forskjellige personer
- Nå har vi utviklet en feature, og vi vil vise dette til kunden.
- Da må vi ikke bare bygge systemet, men også få den kjørbare filen med featuren ut til brukeren
- for java: som oftest en jar-fil, som er en zipfil med spesiell katalogstruktur der alle .class-filene ligger og alle bibliotekene som brukes finnes
- også vanlig (i alle fall tidligere) .war
- annerledes for andre språk, men felles er at det som oftest samles til en eksekverbar fil
- når du gjør mvn package får du en .jar-fil i target-katalogen hvis det står at du skal lage jar i pom-en
- jar-filen må kjøre et sted
- kan kjøre java -jar i kommandolinje på en server
- som oftest er det en applikasjonsserver eller webserver som server jar-filen din, fordi applikasjonen gjerne skal kommunisere med andre tjenester og være tilgjengelig vi HTTP/HTTPS
- vanlige servere for java: jetty og tomcat
- kan gi deg mulighet til å bytte ut jar-fil uten å skru av tjenesten
- hvis dere vil eksperimentere med denne type stack: bruk spring-boot som utgangspunkt, ferdigkonfigurert oppsett som tar mange fornuftige valg rundt applikasjonsserver og hvordan alt henger sammen der
- byggserver kan settes opp til å deploye hver gang man merger til master (kan være risikabelt)
- enkel tjeneste hvis dere vil eksperimentere: Heroku
- tegne på tavlen: fra build-server til prod, og etterpå via testmiljø
- Oppgave: diskuter hva dere mener med arkitektur i kontekst av det å lage programvare (2-3 minutter)
- hvilke elementer inngår i arkitektur på ulike nivå? (muligens diskutere?)
- ulike miljø (lokal, utvikling, test, prod)
- andre interne systemer dere kommer i kontakt med: brannmur, proxy, last-delere
- redundans-løsninger i egen rigg
- hvordan koden er adskilt
- hvordan ulike deler av systemet skal kommunisere
- hva er typiske mønstre vi ser for å skille ulike ansvarsområder?
- Persistens-lager, back-end (hoveddel av forretningslogikk), front-end (grafisk brukergrensesnitt)
- tegne på tavle: persistens, backend, frontend (inn i eksisterende prod-løsning)
- Persistenslaget handler om å lagre (persistere) data over tid
- Oppgave: Hva kan persistering være? (1 minutt)
- Database, relasjon eller annen type
- lagring av enkeltverdier og hvordan disse relaterer til hverandre
- Dokumenter/filer på disk
- brukerdata
- konfigurasjon
- tilstand på en aktivitet (spilltilstand, søknad som er halvveis utfylt osv)
- skiller på persistering brukerdata og av oppsett for å tilpasse et system
- skiller på strukturerte data og ustrukturerte data
- tegnes ofte som en boks, men i realiteten er det både kode og en separat kjørende instans (feks db-skjema, hvordan databasen er bygget opp, er kode)
- hente data fra ulike kilder
- sette sammen data fra ulike kilder
- Kan være mange systemer som integrerer med backend, ønsker å begrense hvor mange samtidige koblinger (feks database og "dyre" integrasjoner)
- løse forretningsproblemer
- sørge for at brukeren får gjort det som er nødvendig
- sørge for planlagt feilhåndtering
- presentere data til bruker
- tilpasse data før visning
- ta imot oppgaver fra bruker til systemet (brukeren utfører brukerhistorier)
- logikk for visning <-- ofte uklar linje mellom forretningslogikk og visningslogikk
- det aller viktigste prinsippet for å lage kode med god kvalitet er å skille ulike ansvarsområder logisk (også vanskelig, tenk sjakk) (separation of concerns)
- noen ganger skilles dette logisk og fysisk, andre ganger ikke
- ulike ansvar: hvordan ting lagres har ingenting med hvordan ting tegnes å gjøre
- deres spill: har kanskje ikke persistenslag, og visning og forretningslogikk (kjernen) er i samme eksekverbare fil.
- Likevel viktig å skille ansvarsområdene, da i ulike kodefiler/pakker hvis nødvendig
- i prosjektet skal dere la folk spille sammen over nett, da må vi tenke arkitektur
- Hvilken arkitektur legger vi opp til i prosjektet?
- ingen sentral kjørende node/instans/maskin
- alle aktører er likeverdige og kan kommunisere med hverandre
- arbeidsoppgaver kan fordeles likt
- koden som kjøres på alle noder er lik
- git er i utgangspunktet p2p
- prosjektet deres er p2p. Vet ikke på forhånd hvilken node som er "serveren", avhengig av hvem som kobler seg til først
- samme koden kjører på alle nodene
- Mot andre enden av skalaen ligger client-server, der en fast node har en koordinerende rolle: serveren
- koden som kjøres på server er ulik den som kjøres i klientene
- mittUiB: eksempel på klient-server-arkitektur
- en (eller flere) eksekverbare systemer håndterer backend og visning
- annen kode (egen klient eller i browser) håndterer interaksjon med systemet
- kode er stort sett ikke delt mellom klient og server, de har ulike arbeidsoppgaver
- spill med sentral koordinering
- tegne på tavlen: kun klient -- klienter -- klient/server -- bare server
- ytterpunktene er at det bare finnes en variant (feks offline spill, eller server som serverer statisk html)
- fet klient/tynn klient (klient kan være eget program eller webbrowser som kjører kode)
- må bruke VPN for å få kontakt med testmiljø mm.
- deler av applikasjonssystemet ligger i egne nett
- brannmur mm skjermer deler av systemet
- kompliserer tilkobling for eksterne aktører
- kompliserer systemene vi bygger, fordi vi må jobbe rundt sikkerhetskrav hele tiden, feks i forhold til autentisering og autorisering (har tilgang, har rolle som tillater spesifikk bruk)
- dev-miljø
- testmiljø
- akseptansetestmiljø
- ulike nivåer av likhet til prodmiljø (bør være så likt som mulig) der hele applikasjonsuniverset er tilgjengelig for mest mulig realistisk testing
- kan spinnes opp der og da eller leve over tid
- må tenke på hvilke type data som kan finnes der (skal det leve lenge, skal man kunne importere proddata?), hva med sensitive data?
- Ulike krav til respons fra ulike deler av systemet fordi de oppfører seg ulikt under last
- en del av koden krever mer maskinressurser enn andre, og må skaleres annerledes
- ulike operasjoner: skrive til system er krevende, lesing av system er trivielt
- ulike brukerbehov: nesten ingen skriver, men veldig mange leser
- last varierer: skalere opp på gitte tidspunkt, feks når selvangivelsen kommer, rundt eksamenstid, semesterbaserte undervisningssystemer, ulike tider på døgnet --> ulik last osv.
- Ved skalering må lasten fordeles til de ulike nodene
- Tegne på tavlen: proxy/lastbalanserer som fordeler trafikk
- eks: systemene jeg jobber med har uavhengige noder i produksjon (gjør det mulig å oppgradere/deploye nye features uten nedetid)
- dersom systemet må være oppe hele tiden er det vanskelig å gjøre oppgradering av disse
- feks journalsystemer, systemer på sykehus, offentlige systemer (postutsending og henting av post), taxi-bestilling, nødetater osv.
- kan løses med lastbalanserer og redundante instanser: ta ut en node og oppgradere denne, sette den inn i trafikk igjen og ta ut neste osv.
- kjente skytjenester: AWS, Azure, Google Cloud, Heroku
- dette er hele økosystemer av tjenester, AWS har > 100 tjenester og enda flere produkter
- kan sette opp separate nett for flere virtuelle maskiner som kjører koden din, databasen din osv.
- kan skalere for deg, feks:
- hvis backenden trenger mye CPU, bestill det
- hvis frontenden får mange forespørsler, sett opp flere noder og sett en lastbalanserer foran
- hva hvis trafikk er ujevnt fordelt? Sett opp prod-miljøet til å skalere dynamisk
- Kubernetes er en teknologi som også kan brukes for å gjøre konfigurering av sånt
- Denne disiplinen kalles devops i dag, fordi mye av konfigurasjonen på driftsmiljøet er kodebasert idag og dermed kan utvikles mer likt som kode
- alle er uavhengige entiteter og må kunne fungere (og feile på en god måte) uten de andre systemene: husk å ta med i designet og planlegging av systemet
- oppdatering skjer noen ganger uavhengig av hverandre, noen ganger samkjørt (feks om du endrer på interface)
- Systemer med stor last trenger gjerne caching (midlertidig minne for ofte brukte data), dette må tas hensyn til i koden. Caching er forferdelig vanskelig å få til.
- uavhengig kjørende instanser som går mot samme type persistens må være trygge på at de ikke ødelegger for hverandre
- brukes ofte til lokal utforskning, og til å distribuere programvare på en enklere måte
- kan gjøres gjennom virtuelle maskiner feks gjennom VMWare, HyperV, VirtualBox
- feks: trenger å teste webapp i en spesifikk windows-browser: har windows-image i virtualbox
- en full virtuell maskin er tungt å kjøre opp, krever plass til et helt operativsystem mm, windows-vm-en er 8gb, og må leve i minne på maskinen
- vokst frem en annen type virtualisering: docker: en container som oppfører seg som brukerområdet på en spesifikk platform i stedet for en full VM med operativsystem.
- jeg bruker docker for å kjøre spesifikk software: feks visning av slides. I stedet for å installere programvare, kjører jeg bare et docker-image. Får gitpitch satt opp riktig (alle dependencies og konfig satt)
- eks: database må installeres på riktig operativsystem og trenger en del systemspesifikt oppsett
- med docker kan dette gjøres en gang og gjøres tilgjengelig for andre
- også mye brukt til lokal utforskning, feks fordi det kan gi deg reell database uten at du trenger å installere db lokalt (ofte vanskelig eller umulig)
- hvis du klarer dette, er sjansen større for at du har et lesbart og vedlikeholdbart system over tid
- arkitektur endrer seg også
- hva betyr dette i praksis?
- påloggingstjeneste endres fordi organisasjonen du jobber opp mot endrer sin innlogging. Eget konsept som holdes så separat fra koden som mulig gjør det enklere å bytte ut spesifikk teknologi
- håndtering av brukere og roller gjøres ofte utenfor applikasjonen (stort og komplekst felt)
- bygg og deploy er også et ansvarsområde, for uten dette virker ikke koden din ordentlig
- maven håndterer dependencies og bygg, så slipper du å tenke altfor mye på det
- all konfigurasjon rundt dette holdes så separat som mulig fra resten av koden (pom.xml)
- byggserver håndterer det å bygge i riktig miljø, egen konfig for dette
- så deployes den eksekverbare filen, vi får konfig av serveren den lever på
- neste lag: hvor kjører serveren/tjenesten, og hva er kravene til feks oppetid og respons?
Kodekvalitet betyr forskjellige ting i forksjellige domener. Eksempler på domener:
- Nettverk eller operativsystemer med C-programmering
- High-performance computing
- Hardware-spesifikasjoner (VHDL)
- Applikasjonsutvikling (Java)
Domener vil ha forskjellige krav, og kodekvalitet innenfor disse domenene vil derfor bety forskjellige ting. Det viktigste er at koden er lesbar for andre innenfor samme domene. Likevel vil en mer generell lesbarhet være et universelt krav, som vil gjelde på tvers av alle domener.
Kode man skriver skal leses og forstås av mennesker. Mennesker er begrenset, og kan ikke holde mer enn 3-7 ting i hjernen samtidig. Verden endrer seg, og det gjør de fleste andre ting også. Derfor må man ta hensyn og ha et fremoverrettet tankesett med tanke på både funksjonalitet og utforming av kode.
- Abstraksjon
“The goal is to compartmentalize some functionality into a nice, easier to reason about thing (function).”
Detaljer kan abstraheres bort for å forbedre lesbarhet som videre forbedrer kodekvalitet. Funksjoner abstraherer bort oppførsel, en prosedyre, en beregning eller lignende. Et objekt pleier å abstrahere bort en ting, et konsept eller en samling.
- Principle of Least Astonishment (PLA)
Det viktigste og kanskje det vanskeligste prinsippet man kan følge. Prøv å ikke overrask brukerene dine (andre utviklere) ved å bruke uvanlige konvensjoner eller personlige preferanser i koden. Hvis man retter seg mot en vanlig og lettforståelig fremgangsmåte mot et problem, i steden for en unødvendig kompleks løsning, vil brukeren bli mindre overrasket og forstå sammenhengen lettere.
- Kommentarer
Kommentarer i koden skal være overordnet og beskrive hva som er spesielt, og bør inneholde essensen av hva koden gjør, men mer viktig hva man bør passe på når man bruker koden. Kode som ikke trengs lenger (i et prosjekt hvor koden anses som ferdig produsert) bør ikke kommenteres ut, men fjernes. Dette er fordi gammel kode som tidligere har blitt brukt vil (ved bruk av versjonskontroll) være tilgjengelig i for eksempel git.
- Keep It Simple Smart Person (KISS)
Dette prinsippet er viktig fordi det er såpass ekstrem kompleksitet i datasystemer. Enklere er alltid bedre. Kompleksitet er killeren. Å redusere kompleksitet vil alltid hjelpe.
-
Navngivning
- Bruk beskrivende og entydige navn.
- Bruk navngivningen til å definere hva variabelen representerer.
- Man snakker om kode, så bruk navn man uttale.
- "ah32n_ll" er vanskelig å snakke om.
- authenticationHeader er ikke vanskelig å snakke om.
- Bruk navn man kan søke på.
- Vær varsom med å bruke navn som er deler av andre navn.
- Hjelp leseren til å forstå hva som skjer.
- sum() forteller hva du får.
- listUtility() forteller ingenting.
- Hvis det er mulig å forstå hva det handler om med en kort setning, bruk den.
- Vi forteller en historie med koden vår, la den være lettlest.
Spør:
- Hva gjør denne tingen?
- Hva handler den om?
- Hvilke effekter har den?
- Utfører den noen spesielle ting?
- Klasser: Hvilke konsepter pakker du inn her? En adresse?
-
Don't Repeat Yourself
- “A piece of knowledge should be found once in a code base”
- Bruk navngitte konstanter.
- Lag en funksjon for samme funksjonalitet.
- Hvis du har konfigurasjon - samle den på ett sted
- Tommelfingerregel (Rule of Three):
- Tredje gang du bruker det, trekk det ut til en egen ting
-
Reduce side effects
En funksjon burde fortelle deg hva den gjør, spesielt hvis den inneholder side-effects. Kodekvaliteten øker umiddelbart ved reduksjon av unødvendige side-effects, ettersom det er såpass vanskelig å forklare innad i koden hva funksjonen egentlig gjør hvis den inneholder mye av det.
Likevel vil prinsippet bli brutt ofte, ettersom man trenger å bruke side-effects ofte. Void brukes til gi beskjed om at det skjer en side-effect. Da bør den også forklares godt i kommentarer.
- Single Responsibility Principle (SRP)
"A class should only have a single reason to change". Hver bit av koden skal ha kun et ansvarsområde, videre forklart under SOLID prinsippet under Designmønstre.
- i en ideell verden, intet behov
- selv i en positiv verden: ulike grenser for hva som er OK
- virkeligheten nå: mange tar nøyaktig det de kan få uten tanke på konsekvenser
- stadig utvikling og mye debatt rundt lovverk rundt personvern
- lovverk og juss tar LANG tid og er veldig tregt
- lovverk som ikke er tilpasset digitalt samfunn
- i tillegg: juridisk språk er vanskelig og utrolig detaljert
- vanlige folk skjønner ikke det
- folk har ikke hatt kontroll på egne data (ikke rart: mange aktører over lang tid)
- lite klare rutiner for hvordan personvern skal opprettholdes
- variasjoner fra land til land
- mye vanskelig språk så folk ikke forstår hva de samtykker til
- mange gjemmer vekk hva de egentlig gjør (feks facebook sine avtaler med andre som får dine data, cambridge analytica)
- mange firmaer prøver å lure seg unna
- Facebook samler inn så mye data om brukere de kan, vært utydelig på hva de samler inn, hvor ofte, og hva det brukes til
- FB sin forretningsmodell er personlig data. Koster ingenting for brukere å være med, da finnes det en annen kostnad
- Hos FB har det vært et utydelig skille mellom hvilken informasjon som deles med andre parter, og lite oversikt over hvilken verdi denne informasjonen har
- Cambridge Analytica laget i 2013? en app: thisismydigitallife. Denne appen betalte brukere for å ta en personlighetstest. Under 300 000 tok quizen, men CA fikk tilgang til over 50 millioner brukerprofiler appen krevde tilgang til fb-profil OG dine kontakter sine profiler. Facebook er nemlig designet slik at man kan dele andre sin personlige informasjon. CA påsto de bare skulle bruke dataene for forskning, men hadde oppdrag fra politikere, feks trump sin presidentkampanje, og sannsynligvis også Brexit-politikere i 2016 (målet: påvirke velgere i USA, potensielt også i UK). Derfra fikk de nok informasjon til å lage profiler og forslag til hvilken type reklame som har størst sjans for å påvirke spesifikke brukere.
- Er disse de eneste? Neppe. Lovverk kommer, men ligger langt etter teknologi-utviklingen
- Reklame for politiske partier og kandidater er ikke det samme som vanlig reklame.
- Fake news
- Tildels kontinuerlig GPS-tracking av posisjon
- Deling av religiøs tilhørighet
- Deling av seksuelle preferanser
- Deling av siviltilstand
- Deling av hvilke andre apper bruker har installert
- Standardinnstillinger skal være til fordel for burkeren
- Bygg funksjonalitet slik at tjenesten virker både med og uten samtykke
- Standard: uten samtykke, må da brukeren ta et aktivt valg om å være med
- Opt-in for ekstra ting
- Like lett å slette som å legge inn
- Brukergrensesnitt som er enkle å forstå (hva har du sagt ja til, har du sagt ja)
- Alltid tenke gjennom hvilke data som faktisk trengs
- Vi er mye lettere å påvirke enn vi tror
- Psykologi, biologi, forskning på hvordan hjernen virker gjøres i større og større grad, for å manipulere brukere
- Hvis vi får noe, er det lettere å si ja til noe du ikke egentlig ønsker. Hvis du først har sagt ja til en ting, er det lettere å si ja til neste ting. Dette brukes for ALT det er verdt i markedsføring
- Siden alle har hver sin mobil og hver sine apper som er personlig tilpasset, er reklame MYE tettere innpå oss nå, og det er mye kortere vei til å påvirke deg
- Reklame treffer best hvis den er personlig tilpasset. Bedrifter ønsker å vite hvilken reklame som kan treffe, og hvem de skal sende den til
- Da trenger de å vite mest mulig om deg --> Personopplysninger
- Personopplysninger er enhver opplysning om en identifisert eller identifiserbar fysisk person (den registrerte: En fysisk person som direkte eller indirekte kan identifiseres, særlig ved hjelp av identifikator (som navn, id-nr. eller ett eller flere andre elementer))
- Kan være navn, telefonnummer, venner, adresse, hva du kjøpte i butikken sist fredag, hvilken buss du tar til jobb osv.
Personvernforordningen er et lovverk som skal regulere hvordan personopplysninger behandles, og privatpersoners rettigheter til egne personopplysninger i møte med alle som ønsker å bruke deres data.
Hensikten med Personvernforordningen er å sikre at personer skal ha kontroll på sine egne data, hva som finnes (samle inn) og hva informasjonen brukes til. Bedrifter skal ikke kunne selge videre personopplysninger uten at personen får vite og samtykker til det. Bedrifter skal tvinges til å opptre redelig og rettferdig, eksempelvis rundt samtykke. Det skal være like lett å trekke tilbake samtykke som at det er gitt, og det er krav til at personen skal vite at samtykke er gitt.
- Lovverket som regulerer personopplysninger i EU heter personvernforordningen
- General Data Protection Regulation
- EU/Europa ligger nok først i løypen her, andre steder er dette ikke kommet like langt
- California har nylig vedtatt en tilsvarende lovverk, California Consumer Privacy Act (CCPA)
- Rett til innsyn (om opplysninger behandles & hvilke opplysninger behandles, til hvilket formål, hvor lenge skal data lagres, hvem data evt deles med)
- Rett til korrigering: du kan kreve korreksjoner i data, som må etterkommes og spres til alle som data deles med (innen rimelighetens grenser)
- Rett til begrensning av behandling (du har innsigelser, behandling er ulovlig, behandlingsansvarlig trenger ikke opplysninger lenger)
- Rett til utlevering av informasjon innen 1 mnd, må utleveres elektronisk dersom forespørsel kommer elektronisk
- Rett til overføring (dataportabilitet), strukturert, maskinlesbart, alminnelig format
- Rett til sletting
- Personopplysninger skal kun oppbevares så lenge det er nødvendig
- Personopplysninger skal kun brukes til sitt opprinnelige formål (det vil si at hvis du har samlet inn informasjon får du ikke lov å bruke informasjonen til noe annet enn det du først har bedt om lov til/informert om)
- Løsninger vi lager skal ha innebygd personvern
- Løsninger skal oppfylle krav til dokumentasjon
- Alle som behandler personopplysninger kalles databehandlere og skal ha databehandleravtale. En databehandleravtale er en avtale som regulerer hensikt med behandling av informasjon, varighet, formål, rettigheter og plikter osv. Skal finnes i alle ledd som behandler informasjon (alle underleverandører)
- Innhenting krever i hovedsak samtykke, hvor samtykke skal være spesifikt
GDRP Regulerer:
- Hva data kan brukes til (uten å hente inn samtykke)
- At data ikke kan brukes til noe annet enn originalt formål
- At data skal kunne slettes eller korrigeres
- Data skal kunne utleveres på et fornuftig format
- Samtykke skal kunne tas tilbake (like lett som det ble gitt)
- Samtykke skal bekreftes (personen skal vite at samtykke er gitt)
- Data skal ikke lagres lenger enn nødvendig, lagres og behandles sikkert
- Personvern skal være standardinnstillingen (opt-in heller enn opt-out)
- Flytte eierskap over data om deg selv fra andre til DEG. Videre gi deg som fysisk person rettigheter og muligheter for å kunne håndtere og kontrollere data om deg selv
- Vite hvilken informasjon som samles inn, og hva den brukes til
- Mulighet for data til å bli slettet
- Mulighet til å korrigere data
- Mulighet til å kontrollere hvem som får tilgang til informasjon
- HVORFOR? Dine data er verdifulle. FB har bygget et helt imperie på dine personopplysninger
- Generelt: er en tjeneste gratis, er du produktet
Kode begynner å lukte ganske fort, sannsyneligvis etter 2-3 linjer. Prinsipper som gjør at kode stinker:
- Rigid (rigidity): Omfattende å endre koden
- Skjør (fragility): Uventede konsekvenser ved endringer av koden
- Immobil (immobility): Vanskelig å dele opp koden i mindre deler
- Viskøs(viscosity): Koden motsetter seg endring, det er krevende å følge designprinsipper
Dette kan fikses ved å følge prinsippet SOLID, enseste som er pensum er S som står for Single Responsibility Principle:
- Single Responsibility Principle: hver bit av koden har kun et ansvarsområde (dette gjelder på alt fra funksjons- til klasse, til pakkenivå). Skill abstraksjonsnivå og ulike ansvarsområder.
Vanskelig kode:
- Overkomplisert kode er like ille som rotete eller uleselig kode
- Unødig kompleksitet: designvalg som ikke gir noen reell fordel
- Unødig repetisjon: copy/paste, særlig hvis ikke alt er likt
- Ugjennomsiktig kode: det er vanskelig å forstå hva koden gjør, språket er for generelt, generaliseringen er tatt for langt (opacity)
Det har over tid utviklet seg løsninger på gjentakende og velkjente problemstillinger i form av designmønstre.
- Opprettelsesmønstre (Creational design patterns)
Creational er designmønstre som omhandler hvordan vi oppretter eller instansierer objekter. Den håndterer kontroll på hvor mange instanser det finnes av en klasse, hvordan skjule implementasjonsdetaljer for andre deler av koden (generalisering) og det å gjøre det enklere å jobbe med objekter med mange parametre.
- Oppførselsmønstre (Behavioural design patterns)
Oppførselsmønstre omhandler hvordan vi håndterer oppførsel og kommunikasjon på et strukturelt nivå. Strukturere kode slik at oppførsel blir gjenbrukbart, eller skjermer resten av koden for detaljer i oppførsel. Handler ofte om hvordan objekter kommuniserer med hverandre.
- Strukturelle mønstre (Structural design patterns)
I strukturelle mønstre er klasse- og objektkomposisjon er viktig, bruk av interface osv. Det handler også om kommunikasjon, men da i form av egenskaper og ikke oppførsel. Kan f.eks. være bruk av ulike eksterne API-er som skal oppføre seg som ett for resten av koden. skjerming av deler av koden (lage flaskehalser som alle må gjennom for å ha kontroll).
For mer informasjon om spesifikke prinsipper se linken: https://sourcemaking.com/design_patterns
- "Eneretten som skaperen av et verk får til å fremstille eksemplarer, og gjøre det tilgjengelig for allmenheten.
- Et verk er et uttrykk for original og individuell skapende åndsinnsats
- En rett som oppstår i det verket er skapt.
- Uten krav registrering Retten er tidsbegrenset
- I Norge, reguleres dette av Åndverksloven
- Datamaskinprogrammer går under åndsverkloven
- Åndsverket må være skapt av personer
- Verket må ha preg av noe (nytt og) originalt, og være uttrykk for en individuelt skapende åndsinnsats
- Gjelder ikke bare uttrykket i opprinnelig form, men også i "endret skikkelse, i oversettelse eller bearbeidelse."
- Gjelder ikke generiske ideer, teknikker, metoder eller lignende som ligger bak
- Fungerer i hovedssak som ettligningsvern
- Gir innehaver av opphavsretten
- Rett til å avgjøre om og hvordan et verk skal kunne benyttes
- Rett til å avgjøre hvem som skulle få adgang til å utnytte verket
- Rett til å bestemme vilkår for bruk. f.eks om det skal betales
- "Fair use" er et prinsipp fra US-opphavsrett
- Gir anledning til å bruke verket uten tillatelse fra den som har opphavsrett
- Et begrep vi ikke har i Norge, men som likevel er dekket under åndverksloven
- Sitatrett, kopiering for privat bruk, eller lån fra bibliotek er eksempler på dette
- Hardware, OS og kompilatorer leveres stort sett sammen med kildekode.
- Programmet gjøres tilgjengelig for andre under "public domain"
- 1953 - A-2 releases som første eksempel av fri programvare. Alle kunder fikk kildekode, og ble oppfordret til å sende forbedringer tilbake til UNIVAC
- IBM stormaskin ble solgt med kildekode inkludert SHARE og DECUS brukergrupper som fasiliterer deling av kildekode og programmer
- 1959 SHARE OS blir released for IBM 704
- 1969 (nice :) ) ARPANET
- 60-70 årene begynner en programvareindustri å oppstå
- Konkurranse mellom leverandører av programvare
- AT&T dsitribuerer tidlige UNIX versjoner, gratis. (Fra 80-tallet og utover selges disse under kommersielle lisenser.)
- 1974 - Programvare omfattes av copyright i USA for første gang
- Flere og flere selskaper går over til å ikke distribuere kildekode.
- 1978 TeX, releases av Donald Knuth som fri programvare
- 1983 Apple Computer Inc, v. Franklin Computer Corp. for første gang i US rettsystem. OS kan beskyttes av copyright (dom i 1988)
- 1983 RMS oppretter GNU prosjektet
- 1985 Free Software Foundation (FSF)
- 1989 GNU General Public License v1
- Linux
- Første versjon releases i 1991
- Blir i 1992, re-lisensiert under GPL v2
- Siste brikken i Richard Stallmans GNU prosjekt er på plass
- 1999 Gir Eric S. Raymond ut en bok "The Catheadral and the Bazaar" som omhandler to type open source modeller
- The Catheadral model: Kildekode alltid tilgjengelig for brukere ved release, men utvikles av en "lukket" gruppe (feks GNU, Emacs, GCC)
- The Bazaar model: "Linux-modellen", produktet utvikles offentlig kontinuerlig over Internet (den verdensomspennende interwebben)
Angrep på linux:
- SCO proprietær UNIX leverandør saksøker IBM for brudd på opphavesrett
- Taper saken i ulike instanser og går konkurs
Angrep på FSF/GPL
Hva er fri programvare?
Fri programvare referer til brukernes frihet ti å kjøre, kopiere, distribuere, studere, forandre på og forbedre programvaren/ Mer presist referer det til fire typer frihet, for brukerne av programvaren:
- Friheten til å kjøre programmet som du ønsker, uansett hensikt
- Friheten til å studere hvordan programmet virker, og tilpasse det til dinebehov
- Friheten til å redistribuere kopier så du kan hjelpe din neste
- Friheten til å forbedre programmet, og gi det ut med dine forbedringer til offentlig eie, slik at hele samfunnet kan få utbytte.
"Copyleft is a general method for making a program (or other work) free, and requiring all modified and extended versions of the program ot be free as well"
Lisenser med færre restriksjoner på hvordan programvaren kan distribueres. Feks MIT License.
"Do whatever you want, Use at your own risk, Acknowledge me"
-
Beskyttelse av verdier mot skade
-
Konfidensialitet
-
Integritet
-
Tilgjengelighet
- Hvem er du?
- Ikke alltid fysisk identitet
- Man kan ha mange identiteter
- Hva har du lov til?
- Nå og i fremtiden
- Begrenset tilgang til systemet
- Bruker: Bruke Systemet
- Admin: Endre/ jobbe med systemet
- Har lov til å be om flere tilganger
Autentisering:
- Prosess for å sjekke om personen (eller enhet) som ber om tilgang er riktig identitet.
- Passord og brukernavn
- To-faktor autentisering (MFA: Multi Faktor Autentisering)
- Biometrics
- Fingerprint
- Ansiktgjenkjenning
MFA
- Multifaktor, bruk mer enn en type
- Ting du vet (kunnskap): Passord, pin, otp
- Ting du har (besittelse): Bankkort, nøkkel, minnepinne
- Ting du er (inherence): biologi: fingerprint, ansiktgjenkjenning
- Sted du er: Nettverk, GPS
Eksempel:
- Uttak av minibank: Krever bankkort (besittelse) og pin-kode (kunnskap)
Out of band (må finne litt mer om dette)
- Fysisk kontakt
- Telenett
- posten
- andre nettverk
- En trussel som utnytter en sårbarhet fører til trusselscenario, det utløser risiko som skader verdi
Hvordan vurdere risiko:
- Risikomatrise (Sannsynlighet og konsekvens)
- Se slide 24/25 på forelesningen for illustrasjoner.
Hvilke verdier finnes?
- Penger, informasjon, omdømme, fysiske verdier, mennesker etc
Hvilke trusler finnes?
- Målrettet angrep, forretningsspionasje, hacking, utpressere
OWASP
- Open source rammeverk
- Top 10
- Gir råd om sikkerhet
- Injections
- XXS
- SQL Injections
- Inputs
- Ikke eksponer mer data enn nødvendig
- Kjente feil er en meget vanlig angrepsfaktor
- Feilmeldinger
- Sårbarheter i databaser må sikres
- Ha et system på passordene
- Sekvensielle passord
- Hardkodede passord
- Data som er lagret på et obskurt sted (lite kjent, vanskelig å forstå, ubetydelig)
Spørsmål om MVP
- Hva er hensikten?
- Tilbakemelding fra kundene, er de fornøyd? Hva gjøres videre? Hva bør endres?
- Skaffe en større oversikt over hva som må gjøres videre og hva som skal endres.
- Levere best mulig produkt
- Skaffe en bedre forståelse av kundenes ønske.
- Teste nye idéer
- Hvordan oppgaver bør prioriteres
- Hva må settes opp? (Fra slidsa)
- Testmiljø og produksjonsmiljø
- Bygg/deploy- pipeline
- Avtaler om drift og støtte
- Hva oppnår teamet?
- Bedre samarbeid mellom kunde og utviklere
- En mer fornøyd kunde
- Hvis hele business caset ditt er bygget opp rundt en feature, få testet den så tidlig som mulig slik at du kan justere kurs (hva betyr dette?)
- Tilbakemelding fra kundene:
- Hvordan bruker de systemet?
- Finner de riktige funksjoner?
- Godt UI design?
- Hva savner brukerne?
- Hvor mange skal bruke systemet?
- MVP - Minimum Viable Product.
- Krav - Konkretisering av et behov som kunden har
- Brukerhistorie - Spesifisering av et krav, må være detaljer og forklare hvorfor det er viktig. Alle må forstå kravet Hvem har behovet? Hva er behovet? Hvorfor (nytteverdi)?
- Funksjonelle krav - Hvilke behov som må gjøres
- Ikke funksjonelle krav - Handler om hvordan oppgaver skal utføres (responstid, plattformkrav, integrasjoner, sikkerhet)
- Kråkesølv - Oppgave med tilsynelatende verdi, som egentlig ikke er viktig.
- Isfjell - Oppgave som er for stor og tar for lang tid.
- Konfidensialitet - Du er den eneste med tilgang til informasjonen.
- Integritet - Informasjon er det samme, endres ikke uten din tillattelse
- Tilgjengelighet - Informasjonen er der når du trenger den
- Retrospektiv - Lære av tidligere erfaringer
- Kommunikasjon - Viktigste verktøy en utvikler har: Bedre samarbeid, bedre løsninger, kreativitet osv. Email, chat, issuetracking
- Thrunk-Based-utvikling - Alle jobber på samme kodebase, alle er oppdatert hele tiden.
- Tanker rundt lisensiering. Hva en type lisens vil ha å si for deg som skal videreutvikle et prosjekt.
- GDPR (Siv: Hett eksamenstips!)
- Risikovurdering (Sikkerhet), men ikke veldig detaljert
- Prosjekttavle: XP vs Scrum vs Kanban
- Prosjektmetodikk knytte til eget prosjekt, drøft!
- Trunk vs branch based
- Fordeler / ulemper med versjonskontroll. (Denne er jeg noe mer usikker på)
- Arkitektur: Nivåer av arkitektur, gjerne knyttet opp til eget prosjekt. Feks P2P vs Client-Server
- Testing: Test først vs test etter (koden er skrevet)? Drøft
- "Vurder denne testen". Kanskje lurt å se på form? Arrange, act and assert
- Foreslå tester til produksjons-kode
- Vurder kode (mulig refaktoreringsspørsmål)
Generelt eksamenstips fra Siv: På grunn av åpen bok blir det mer evaluering av ulike aspekter ved eget prosjekt eller kode, ved hjelp av prinsipper fra faget!