UKE 14 Versjonshåndtering og testing. Gruppetime INF1055 Julie Hagen Nilsen & Maria Stolinski
|
|
- Ådne Antonsen
- 7 år siden
- Visninger:
Transkript
1 UKE 14 Versjonshåndtering og testing Gruppetime INF1055 Julie Hagen Nilsen & Maria Stolinski
2 UKENE FREMOVER OBS! Ikke forelesning 17. mai ikke gruppetime 19. og 23. mai Felles gruppetime for alle fredag 26. mai gjennomgang av prøveeksamen + tips og triks
3 Hva skal vi i dag? Versjonshåndtering og testing (kapittel 8 og 25) Ukesoppgaver 5: testing (del 1) og konfigurasjonsstyring (del 2)
4 TESTING Kompetansemål - Testing av programvare - Hva og hvorfor? - Testfaser - Ulike nivåer - Testtyper - Spesifikasjonsbasert testing/strukturbasert testing - Testdrevet utvikling
5 BAKGRUNN FOR TESTING Hva er testing? Hvorfor er testing viktig? De syv testprinsippene
6 TESTING: hva og hvorfor? - Testing utforsker et system/systemkomponenter for å avdekke feil eller mangler - Nødvendig for kvalitetssikring av et system - Sørge for at systemet som bygges holder høy standard Etablere gode kunderelasjoner - Påser at systemet innfrir funksjonelle og ikke-funksjonelle krav - Forsikre seg om at man har laget det man skal lage, og på en god måte - Økonomisk gevinst - Avdekking av feil under utvikling er ofte rimeligere enn når systemet er tatt i bruk - Et svært viktig tema i systemutvikling
7 TESTING: de syv testprinsippene 1. Testing viser feil - Testing kan bare vise at feil/defekter eksisterer - Testing kan ikke bevise at et program er feilfritt 2. Fullstendig testing er umulig - Det er umulig å teste alt - Kan ikke teste alle mulige kombinasjoner mellom input og betingelser 3. Tidlig testing - Testing bør starte så tidlig som mulig i utviklingsprosessen - Testinnsatsen bør fokuseres på tydelig definerte mål
8 TESTING: de syv testprinsippene 4. Konsentrasjon av feil - Et samlet mindretall av komponenter/moduler inneholder de fleste feilene - Feil er ikke jevnt fordelt i kildekoden - Noen komponenter er mer komplekse å utvikle enn andre - Enkelte utviklere kan være mindre kompetente og dermed produsere flere feil 5. Plantevernmiddelparadokset - Hvis de samme testene kjøres hver gang, vil de til slutt ikke finne flere feil - Tester bør oppdateres og tilpasses jevnlig - Nye tester bør inkluderes ved behov - Øker sannsynligheten for å oppdage ytterligere feil i systemet
9 TESTING: de syv testprinsippene 6. Testing er kontekstavhengig - Testinnsatsen avhenger av konteksten - Ulike systemer bør testes på ulike måter Testfokus varierer fra system til system. Eksempelvis kan ikke sikkerhetskritiske system testes på samme måte som trivielle spill 7. Fravær av feil -fellen - Et feilfritt system er ikke nødvendigvis et brukbart system - Validering versus verifisering Bygger vi det riktige produktet? Bygger vi produktet riktig?
10 KONFIGURASJONSSTYRING Kompetansemål - Konfigurasjonsstyring - Hva og hvorfor? - I en smidig sammenheng - Endringshåndtering - Versjonhåndtering - Systembygging - Release -håndtering
11 BAKGRUNN FOR KONFIGURASJONSSTYRING Hva? Hvorfor? Ulike aktiviteter
12 KONFIGURASJONSSTYRING: hva? - Output fra en systemutviklingsprosess kan deles inn i tre kategorier
13 KONFIGURASJONSSTYRING: hva? - Konfigurasjon: samling av alle komponenter som inngår i et system - Hver komponent representeres med en versjon - Konfigurasjonsstyring: Software Configuration Management (SCM) - Aktiviteter, prosesser og verktøy: - Håndtere endringer i programvaresystemer gjennom hele utviklingsprosessen - Spore endringer som gjøres - Systematisk kontroll over utviklingsprosessen og det som utvikles
14 KONFIGURASJONSSTYRING: hvorfor? - Programvaresystemer er i konstant endring - Systemer og kode kan bli veldig komplekse - Lett å miste oversikten over endringer/versjoner av komponenter - Varierer fra versjon til versjon - Ønsker å ha kontroll over endringer - Hva ble endret? Hvem har endret hva? - Bringer kontroll over systemutviklingsprosessen! - Forenkler teamarbeid/koordinering - Unngå endringsrelaterte problemer - Vil feks. spille en sentral rolle for å sikre kvalitet
15 KONFIGURASJONSSTYRING: aktiviteter
16 KONFIGURASJONSSTYRING: aktiviteter - Endringshåndtering (Change Management) - Oversikt over endringer fra kunde/utviklere >> Change Request Form - Kostnadsestimering og virkning (fordeler, ulemper) av foreslåtte endringer - Slutninger om hvorvidt foreslåtte endringer skal implementeres - Versjonhåndtering (Version Management) - Oversikt over ulike versjoner av system og systemkomponenter - Sørge for at endringer fra ulike utviklere ikke kolliderer med hverandre >> Git
17 KONFIGURASJONSSTYRING: aktiviteter - Systembygging (System Building) - Setter sammen systemkomponentene - programvare, data, biblioteker - Kompilering og integrering - Skaper et fullstendig (kjørbart) system - Release-håndtering (Release Management) - Forberede/ferdigstille programvare for ekstern utgivelse (release) - Oversikt over ulike versjoner av systemet som har blitt gitt til kunden
18 KONFIGURASJONSSTYRING: forholdet til smidig utvikling - Systemer/komponenter endres flere ganger daglig - Hyppig bygging og testing av programvare - Selvstyrte team med mye frihet - Kunden er i stor grad involvert i endringshåndtering - Pågående kommunikasjon om hva som har blitt gjort/skal gjøres - Håndtering av endringer er tilnærmet umulig uten konfigurasjonsstyring
19 UKESOPPGAVER
20 SPØRSMÅL 1a Spørsmål: Testing viser feil som oppdages under kjøring av testen. Forklar hvorfor testing ikke kan vise at det ikke er flere gjenstående feil.
21 SPØRSMÅL 1a Spørsmål: Testing viser feil som oppdages under kjøring av testen. Forklar hvorfor testing ikke kan vise at det ikke er flere gjenstående feil. Svar:
22 SPØRSMÅL 1a Spørsmål: Testing viser feil som oppdages under kjøring av testen. Forklar hvorfor testing ikke kan vise at det ikke er flere gjenstående feil. Svar: Kun fordi det ikke oppdages, betyr det ikke at feil ikke finnes. - Å bevise et negativ: Kan man bevise at julenissen ikke eksisterer? - Hvordan vite det man ikke vet? - Tester kan være skrevet av utviklere - Tunnelsyn: Fokuserer bare på det man forventer av feil - Utfordrende å sette seg fullt inn i brukerens perspektiv - Tester kan være skrevet feil/inneholde mangler
23 SPØRSMÅL 1b Spørsmål: Forklar hvorfor det ikke er nødvendig for et program å være fullstendig feilfritt før det overleveres til kunden.
24 SPØRSMÅL 1b Spørsmål: Forklar hvorfor det ikke er nødvendig for et program å være fullstendig feilfritt før det overleveres til kunden. Svar: - Enkelte feil kan aksepteres/ignoreres - De fleste programmer er ikke så kritiske at de ikke kan inneholde feil - Feil i systemet betyr ikke nødvendigvis at systemet er ubrukelig - Det kan være feil i områder brukeren aldri oppdager - Økonomisk motivasjon - Som regel lite lønnsomt å avdekke/rette opp alle feilene før release
25 SPØRSMÅL 2 Spørsmål: Diskuter fordeler og ulemper med at utviklere selv tester sin egen kode.
26 SPØRSMÅL 2 Spørsmål: Diskuter fordeler og ulemper med at utviklere selv tester sin egen kode. Svar: FORDELER - Ressursbesparende: redusert tid og reduserte kostnader - Unødvendig at eksterne team skal finne feil utviklere selv kan finne - Desto mindre kode, desto lettere er testingen - utviklere kan derfor delta i testinnsatsen tidlig i utviklingsprosessen ULEMPER - Testing og utvikling er to forskjellige grener - Testere og utviklere har derfor helt ulike utgangspunkt - Hvordan kan jeg lage det? vs. hvordan kan jeg ødelegge det?
27 SPØRSMÅL 2 Spørsmål: Diskuter fordeler og ulemper med at utviklere selv tester sin egen kode. Svar: Flere ulemper: - Vanskelig å skille mellom hvordan det virker og hvordan det skal virke - Utviklere kan se seg blinde på egen kode - Utviklere har ofte en formening om hvor feilene ligger, og fokuserer ensidig på disse - Kan være vanskelig å løsrive seg fra utviklermentaliteten - Utviklere er ikke nødvendigvis kompetente testere
28 SPØRSMÅL 2 Spørsmål: Diskuter fordeler og ulemper med at utviklere selv tester sin egen kode. Svar: Løsningen på utviklerens rolle: bruk eksterne testere/team til å gjennomføre testingen - Interne eller eksterne testere? - Testing er en vurdering av kvalitet - Interne testere kan oppleve det som vanskelig å poengtere medarbeideres feil - Eksterne testere/testteam - Eksterne testere kan ofte se (andre) feil/mangler som utviklere ikke oppdager - Kommer inn med andre antakelser og forutsetninger enn utviklerne - Eksterne testere nyter ofte mer troverdighet hos organisasjonen/ledelsen - Kan uttrykke feil på en ærlig og kritisk måte
29 SPØRSMÅL 3 Spørsmål: Hva er regresjonstesting? Forklar hvorfor bruk av automatiserte tester og rammeverk forenkler regresjonstesting.
30 SPØRSMÅL 3 Spørsmål del 1: Hva er regresjonstesting? Svar: Regresjonstesting er testing relatert til endringer - Når? Etter at kildekoden/systemet har blitt endret - Mål Avdekke eventuelle feil som har blitt introdusert i kildekoden etter endring Konsekvensanalyse gjennomføres i forkant - Kartlegger deler av kildekoden som har stor sannsynlighet for å bli påvirket
31 SPØRSMÅL 3 Spørsmål del 1: Hva er regresjonstesting? Svar: Teknikker for regresjonstesting - Test alt (full regresjonstest) - Test utvalg - Prioriter tester - Kombinasjon av disse Regresjonstester og konfirmasjonstester er ikke det samme! - Konfirmasjonstester skal bekrefte at eventuelle feil er blitt rettet opp
32 SPØRSMÅL 3 Spørsmål del 2: Forklar hvorfor bruk av automatiserte tester og rammeverk forenkler regresjonstesting. Svar: Automatiserte tester og rammeverk er: - Bruk av programvare/verktøy for å gjennomføre testing - Tester kildekode om og om igjen, uten at dette må gjøres manuelt Hvorfor? - Testinnsatsen kan være tidkrevende, kostbar, og ikke minst repetitiv - Umulig å dekke testbehovet manuelt (spesielt for større systemer) - Programvare og rammeverk forenkler testinnsatsen - Kan overlate testingen til automatiserte prosesser
33 SPØRSMÅL 3 Spørsmål del 2: Forklar hvorfor bruk av automatiserte tester og rammeverk forenkler regresjonstesting. Fordeler: - Tester utføres på nøyaktig samme måte som tidligere - Umiddelbar sammenligning av forventet og faktisk utfall av testene - Økt testomfang - Ressursbesparende Tid/Innsats/Penger - Kan mate verktøyet med data - Mange ulike kombinasjoner av input og betingelser - Kan la programvaren, og ikke menneskene, gjøre jobben - Slipper å teste 100, eller 1000 kombinasjoner for hånd! - Kan lage samlinger av ulike (regresjons)tester - Kan kjøre flere (regresjons)tester etter hverandre
34 SPØRSMÅL 4a Spørsmål: Hva forstår du med begrepet stresstesting?
35 SPØRSMÅL 4a Spørsmål: Hva forstår du med begrepet stresstesting? Svar: Stresstesting Stresse systemet under test - Kartlegge systemets stabilitetsegenskaper - Avdekke antall transaksjoner/operasjoner et system er i stand til å takle - Fremprovosere systemkollaps Hensikt: - Eksponere breaking points - Avdekke kapasitet i henhold til systemkrav og spesifikasjon - Avdekke hvordan systemet håndterer kollaps
36 SPØRSMÅL 4b Spørsmål: Foreslå hvordan du vil stressteste et minibanksystem der det er mulig å sjekke saldo på konto og ta ut kontanter.
37 SPØRSMÅL 4b Spørsmål: Foreslå hvordan du vil stressteste et minibanksystem der det er mulig å sjekke saldo på konto og ta ut kontanter. Svar: Fremgangsmåte: - La minibanksystemet utføre mange transaksjoner samtidig - Sjekk deretter om alle transaksjoner ble behandlet korrekt - Redegjør for hvorvidt systemet taklet stresset/hvordan? - Utvid stresstesten til systemet krasjer/tilfredsstiller spesifikasjonen
38 SPØRSMÅL 5 Spørsmål: Hva er forskjellen på enhetstest og integrasjonstest?
39 SPØRSMÅL 5 Spørsmål: Hva er forskjellen på enhetstest og integrasjonstest? Svar: Man har først og fremst ulike testnivåer: - Testing av programvare er en omfattende prosess Bør stykkes opp - Man kan (bør) ikke teste alt på en gang - Testing bør starte så tidlig som mulig - Hvordan? - Det er begrenset hvor mye man kan teste tidlig i utviklingsfasen - Testing deles ofte opp i ulike testnivåer: enhetstesting, integrasjonstesting, systemtesting og akseptansetesting - Hvert nivå er tydelig definert med tanke på formål og aktiviteter
40 SPØRSMÅL 5 Spørsmål: Hva er forskjellen på enhetstest og integrasjonstest? Svar: Enhetstesting tester individuelle enheter/komponenter (kildekode) - Eksempel: Enheter i programmering som klasser eller metoder - Enheten testes isolert fra resten av systemet - Gjennomføres ofte tidlig i utviklingen/testingen Formål: - Forsikre seg om at enheten gjør akkurat som den skal - Uavhengig av samspill med øvrige komponenter
41 SPØRSMÅL 5 Spørsmål: Hva er forskjellen på enhetstest og integrasjonstest? Svar: Karakteristikker for god enhetstesting: - Isolasjon - Testene til en klasse X avhenger ikke av å ha implementert andre klasser - Testene i en klasse X skal ikke feile på grunn av feil i øvrige klasser - Uavhengighet - Hver enhetstest skal være selvforsynt - Skal virke uavhengig av andre enhetstester som kjøres - Enkelhet - En enhetstest = ett scenario
42
43 SPØRSMÅL 5 Spørsmål: Hva er forskjellen på enhetstest og integrasjonstest? Svar: Integrasjonstesting - Sammensetning av flere enkeltstående enheter til komponenter - Tester disse komponentene sammen - Avdekker hvordan komponentene interagerer med hverandre
44 SPØRSMÅL 6a Spørsmål: Hva er forskjellen på blackbox- og whitebox-testing?
45 SPØRSMÅL 6a Spørsmål: Hva er forskjellen på blackbox- og whitebox-testing? Svar: Blackbox-testing = spesifikasjonsbasert testing - Tester funksjonaliteten til en komponent i henhold til spesifikasjonen - Hva skal komponenten gjøre? Gjør den det? - Ikke fokus på underliggende intern struktur/logikk
46 SPØRSMÅL 6a Spørsmål: Hva er forskjellen på blackbox- og whitebox-testing? Svar: Whitebox-testing = strukturbasert testing - Tester den interne strukturen til et system - Hvordan realiseres funksjonaliteten? Hvilken logikk ligger i grunn? - Inspisere kildekoden - Brukes ofte for å måle dekningsgrad av testene Hvor mye har vi testet?
47 SPØRSMÅL 6b Spørsmål: Forklar fordeler og ulemper med hver av teknikkene. Svar: Fordeler Blackbox-testing: - Krever ikke teknisk kompetanse - Enkelte tester kan gjennomføres av ulike brukergrupper - Planlegging av testinnsatsen kan starte tidlig - Vi vet hva systemet skal gjøre - Kan bruke uavhengige testere (ikke involvert i utviklingen) - Resultater kan tolkes uten kjennskap til systemets interne strukturer - Finner krav som ikke er implementert riktig/mangler
48 SPØRSMÅL 6b Spørsmål: Forklar fordeler og ulemper med hver av teknikkene. Svar: Ulemper Blackbox-testing: - Usikkerhet rundt hvor mye/hvilke deler av systemet som er testet - Vet ikke hva som forårsaker problemet - Hvor i kildekoden ligger feilen? Hva trigget feilen? - Vanskelig å utforme tester uten en tydelig kravspesifikasjon - Tester kan vise seg å være redundante (overflødige) - Utviklere har allerede kjørt tilsvarende tester
49 SPØRSMÅL 6b Spørsmål: Forklar fordeler og ulemper med hver av teknikkene. Svar: Fordeler Whitebox-testing: - Kan utføres tidlig i systemutviklingsprosessen - Trenger ikke vente på at grensesnittet skal lages - Ser nærmere på underliggende logikk/struktur i koden - Optimalisering av kode/fjerne unødvendige kodelinjer - Grundigere analyse av hva som forårsaker eventuelle problemer - Kartlegger data/input som mest effektivt tester programmet - Utviklere må begrunne kode/beslutninger rundt implementasjon
50 SPØRSMÅL 6b Spørsmål: Forklar fordeler og ulemper med hver av teknikkene. Svar: Ulemper Whitebox-testing: - Krever teknisk kompetanse - Programmerings- og testeferdigheter - Bør være ekspert og allerede ha kjennskap til koden - Krever tid og tilgang til kildekoden - Utfordrende å gjennomføre hvis implementasjonen endres hyppig - Finner ikke krav eller mangler som ikke er implementert
51 SPØRSMÅL 7 Spørsmål: Foreslå testcases for use caset ta ut penger. Ta for deg enhetstesting og integrasjonstesting.
52 SPØRSMÅL 7 Spørsmål: Foreslå testcases for use caset ta ut penger. Ta for deg enhetstesting og integrasjonstesting. Svar: Enhetstester Blir PIN-koden validert korrekt? Blir kortet godkjent korrekt? Blir kortet returnert korrekt? Integrasjonstester Henter man saldo fra rett konto? Trekkes korrekt beløp fra rett konto? Blir saldo oppdatert korrekt etter uttak?
53 SPØRSMÅL 8 Spørsmål: Hvorfor er det viktig å utføre både funksjonell og ikke-funksjonell testing?
54 SPØRSMÅL 8 Spørsmål: Hvorfor er det viktig å utføre både funksjonell og ikke-funksjonell testing? Svar: Forskjell på hvilke system-aspekter man tester - Funksjonell testing - HVA systemet gjør - Tester hvorvidt de funksjonelle kravene fra systemspesifikasjonen innfris - Ikke-funksjonell testing - HVORDAN systemet virker - Tester ikke-funksjonelle krav Kvalitetsattributter (brukervennlighet, effektivitet) - Samlet testinnsats øker produktkvaliteten
55 SPØRSMÅL 8 Spørsmål: Hvorfor er det viktig å utføre både funksjonell og ikke-funksjonell testing? Validering Bygger vi det riktige produktet? Programvaren gjør det brukerne virkelig ønsker seg Fokus på hele systemet Verifisering Bygger vi produktet riktig? Stemmer det med kravspesifikasjonen? Fokus på komponenter / delsystemer
56 SPØRSMÅL 9 Spørsmål: Hvorfor er det viktig å utføre vedlikeholdstesting?
57 SPØRSMÅL 9 Spørsmål: Hvorfor er det viktig å utføre vedlikeholdstesting? Svar: Vedlikeholdstesting = testing etter at systemet er tatt i bruk - Vanlig med endringer i et system - Korrigeringer/utvidelser/øvrige forandringer - Plattformer endres eller fjernes - Avdekker om vedlikehold har introdusert nye feil/mangler - Først: Kjør tester for endringene som ble utført - Deretter: Kjør regresjonstest for systemet
58 SPØRSMÅL 1 (fra konfigurasjonsstyring) Spørsmål: Foreslå 3-5 mulige problemer som kan oppstå hvis et softwareselskap ikke bruker effektive styringsverktøy og prosesser (policies).
59 SPØRSMÅL 1 (fra konfigurasjonsstyring) Spørsmål: Foreslå 3-5 mulige problemer som kan oppstå hvis et softwareselskap ikke bruker effektive styringsverktøy og prosesser (policies). Svar: - Begrenset oversikt over - Systemets tilstand - Utviklingsprosessen - Mangel på oversikt over endringer - Kildekode/krav - Svekket dokumentasjon - Tilnærmet umulig å gjenskape eldre (tidligere) versjoner av systemet
60 SPØRSMÅL 2 Spørsmål: Forklar følgende begrep innen konfigurasjonsstyring og versjonhåndtering: Codeline, Baseline, Versjon, Release og Branching.
61 SPØRSMÅL 2 Spørsmål: Forklar følgende begrep innen konfigurasjonsstyring og versjonhåndtering: Codeline, Baseline, Versjon, Release og Branching. Svar: Codeline = sekvens av versjoner av en programvarekomponent (kildekode) - Senere versjoner i sekvensen er utledet av tidligere versjoner
62 SPØRSMÅL 2 Spørsmål: Forklar følgende begrep innen konfigurasjonsstyring og versjonhåndtering: Codeline, Baseline, Versjon, Release og Branching. Svar: Baseline = beskrivelse av en samling av komponenter som utgjør et system - Spesifiserer codeline-versjonene som er inkludert i systemet - Definerer øvrige komponenter (og versjoner) inkludert i systemet - Biblioteker, konfigurasjonsfiler, øvrig dokumentasjon - Kan gjenskape komplette og spesifikke versjoner av et system - Viktig funksjonalitet - Nødvendig dersom kunden rapporterer om feil
63
64 SPØRSMÅL 2 Spørsmål: Forklar følgende begrep innen konfigurasjonsstyring og versjonhåndtering: Codeline, Baseline, Versjon, Release og Branching. Svar: Versjon = et tilfelle av en konfigurasjon - Skiller seg fra andre tilfeller av samme konfigurasjon - Har en unik identifikator - Konfigurasjonsnavn + versjonsnummer Release = versjon av et system overført til kunden, klar for bruk
65 SPØRSMÅL 2 Spørsmål: Forklar følgende begrep innen konfigurasjonsstyring og versjonhåndtering: Codeline, Baseline, Versjon, Release og Branching. Svar: Branching = forgrening av codelines - Opprettelse av nye codelines fra eksisterende codelines - Kan ha flere uavhengige sekvenser av versjoner - Vanlig scenario: utviklere jobber med ulike versjoner av kildekoden - Til slutt blir det nødvendig å flette sammen (merge) codeline-grenene - Lager ny komponentversjon som inneholder alle endringer
66
67 SPØRSMÅL 3 Spørsmål: Hva er et repository? Forklar forskjellen på sentraliserte og distribuerte systemer for versjonhåndtering.
68 SPØRSMÅL 3 Spørsmål del 1: Hva er et repository? Svar: Lagringsplass for kildekode/programvarekomponenter - Verktøy for versjonhåndtering - Oversikt over endringer som utføres - Kan være - Sentraliserte - Distribuerte
69 SPØRSMÅL 3 Spørsmål del 2: Forklar forskjellen på sentraliserte og distribuerte systemer for versjonhåndtering. Svar: Sentraliserte systemer - Det finnes én kopi av systemet Master repository, ligger på en server - Utviklere sjekker ut komponenter fra master repository, over på eget arbeidsområde - Etter at endringer er utført sjekkes komponentene inn igjen gjennom commit - Commit Registrere endringen i det sentrale systemet - Andre utviklere kan nå se denne endringen - Ikke nødvendig å lagre mange kopier av filer på privat arbeidsområde
70 SPØRSMÅL 3 Spørsmål del 2: Forklar forskjellen på sentraliserte og distribuerte systemer for versjonhåndtering. Svar: Distribuerte systemer - Master repository ligger på en server - Utviklere laster ned (pull) en klone til privat arbeidsområde - Har nå tilgang til hele historien på egen maskin Data + metadata - Endringer blir oppdatert privat gjennom commit - Endringer oppdateres globalt ved push til master repository - Git er et eksempel på dette
71 SPØRSMÅL 4 Spørsmål: Hvilke problemer kan oppstå når to utviklere samtidig gjør endringer i tre programvarekomponenter?
72 SPØRSMÅL 4 Spørsmål: Hvilke problemer kan oppstå når to utviklere samtidig gjør endringer i tre programvarekomponenter? Svar: En utvikler endrer en funksjon som en annen utvikler er avhengig av Oppstå feil Endringer som ikke er kompatible
73 SPØRSMÅL 5 Spørsmål: Diskuter faktorer som innvirker på om en endring skal implementeres eller ikke.
74 SPØRSMÅL 5 Spørsmål: Diskuter faktorer som innvirker på om en endring skal implementeres eller ikke. Svar: Sentral aktivitet inngår i endringshåndtering - Ønskede endringer presenteres gjennom et Change Request Form - Avgjør om foreslåtte endringer er gyldige/gjennomførbare - Husk: Ikke alle endringer er nødvendige å gjennomføre! - Analyseres i lys av kostnader og gevinst - Prioriterer de viktigste og mest kostnadseffektive endringene
75 SPØRSMÅL 5 Spørsmål: Diskuter faktorer som innvirker på om en endring skal implementeres eller ikke. Svar: Faktorer i en endringsanalyse: - Konsekvenser - Hva skjer dersom foreslåtte endringer ikke følges opp/utføres? - Fordeler/gevinst av foreslåtte endringer - Brukere - Hvem, og hvor mange, berøres av de foreslåtte endringene? - Kostnader knyttet til implementasjon av endringene
76 Neste uke Teamarbeid og smidige prinsipper, kapittel 22 og
Konfigurasjonsstyring. INF1050: Gjennomgang, uke 11
Konfigurasjonsstyring INF1050: Gjennomgang, uke 11 Kompetansemål Konfigurasjonsstyring Hva og hvorfor? I en smidig sammenheng Endringshåndtering Versjonhåndtering Systembygging Release -håndtering Del
DetaljerTesting av programvare. INF1050: Gjennomgang, uke 08
Testing av programvare INF1050: Gjennomgang, uke 08 Kompetansemål Testing av programvare Hva og hvorfor? Testfaser Ulike nivåer Testtyper Spesifikasjonsbasert testing / Strukturbasert testing Testdrevet
DetaljerGJENNOMGANG UKESOPPGAVER 9 TESTING
GJENNOMGANG UKESOPPGAVER 9 TESTING INF1050 V16 KRISTIN BRÆNDEN 1 A) Testing viser feil som du oppdager under kjøring av testen. Forklar hvorfor testing ikke kan vise at det ikke er flere gjenstående feil.
DetaljerKonfigurasjonsstyring
INF1050: Systemutvikling 28. mars 2017 Konfigurasjonsstyring Yngve Lindsjørn ynglin@ifi.uio.no INF1050 Systemutvikling ->Konfigurasjonsstyring 1 Temaer i dagens forelesning Versjonshåndtering Systembygging
DetaljerInf1055 Modul B 26 april 2017:
Inf1055 Modul B 26 april 2017: Del 1: - Testing Yngve Lindsjørn ynglin@ifi.uio.no 1 Oversikt - Testing Hva er testing? Validering &Verifisering Testfaser Enhetstesting Integrasjonstesting Systemtesting
DetaljerLivsløpstesting av IT-systemer
Livsløpstesting av IT-systemer Testing, validering og evaluering Teste Undersøke ved hjelp av tester om systemet fungerer slik det er beskrevet Validere Bekrefte hvordan systemet virkelig fungerer, om
DetaljerPrøveeksamen INF1050: Gjennomgang, uke 15
Prøveeksamen 2016 INF1050: Gjennomgang, uke 15 Overblikk Multiple choice Modellering Aktivitetsdiagram Sekvensdiagram Klassediagram Tilstandsdiagram Krav Ikke-funksjonelle krav og målbarhet Smidig metodikk
DetaljerGjennomgang av prøveeksamen. Gruppetime INF1055 Julie Hagen Nilsen & Maria Stolinski
Gjennomgang av prøveeksamen Gruppetime INF1055 Julie Hagen Nilsen & Maria Stolinski OPPGAVE 1: MUlTIPLE CHOICE SPØRSMÅL 1.1 Hva er et funksjonelt krav? a) Teksten på skjermen skal være svart med hvit bakgrunn.
DetaljerGrunnleggende testteori
1 Grunnleggende testteori Industri - og software produkt Industriprodukt: Fysisk produkt Testes under produksjon og til slutt om produktet oppfyller kravene Tilpasses, endres, redesignes, og justeres så
DetaljerKravhåndtering. INF1050: Gjennomgang, uke 03
Kravhåndtering INF1050: Gjennomgang, uke 03 Kompetansemål Kravhåndtering Anvende metoder og teknikker for å Innhente / Analysere / Spesifisere krav Ulike typer krav Funksjonelle krav Ikke-funksjonelle
DetaljerTesting av programvare
Inf1050 07 mars 2017: Testing av programvare Yngve Lindsjørn ynglin@ifi.uio.no 1 Oversikt Hva er testing? Validering &Verifisering Testfaser Enhetstesting Integrasjonstesting Systemtesting Akseptansetesting
DetaljerUKE 9 Prosesser og prosessmodeller inkludert smidige metoder. Gruppetime INF1055
UKE 9 Prosesser og prosessmodeller inkludert smidige metoder Gruppetime INF1055 Hva skal vi i dag? Introduksjon til modul B - systemutvikling (kap. 1, 2 og 3) Prosesser og prosessmodeller + smidig utvikling
DetaljerGrunnleggende testteori. Etter Hans Schaefer
Grunnleggende testteori Etter Hans Schaefer Industri- og softwareprodukt Industriprodukt Fysisk produkt Testes under produksjon og til slutt om produktet oppfyller kravene Tilpasses, endres, redesignes,
DetaljerStatisk testing. Testing uten datamaskin, men med vår egen evne til å vurdere og analysere
Statisk testing Testing uten datamaskin, men med vår egen evne til å vurdere og analysere Hva er statisk testing Analyser som utføres på skrevne dokumenter Hensikten er å finne avvik fra spesifikasjonene
DetaljerGrunnleggende testteori
1 Grunnleggende testteori Error-Fault-Failure 2 Error : når en programmerer koder feil eller utelater kode (evt. miljøpåvirkning) årsaken til en fault Fault (defect eller bug): feil i kode kan lede til
DetaljerUNIVERSITETET I OSLO
Bokmål Kandidat nummer: UNIVERSITETET I OSLO Det matematisk-naturvitenskapelige fakultet Prøveeksamen i: INF1050 Eksamensdag: 0. mai, 2011 Tid for eksamen: 00:00 00:00 Oppgavesettet er på 6 sider Vedlegg:
DetaljerTestplan (Software Test Plan)
Testplan (Software Test Plan) Amanuel K. Tedla Eleonora Ntreska Ingrid Vik Hansen Joakim Moen Innholdsfortegnelse Innholdsfortegnelse 1.. Introduksjon... 3 1.1 Definisjoner... 3 1.2 Antagelser ved testing
DetaljerOppgave 1: Multiple choice (20 %)
Oppgave 1: Multiple choice (20 %) For alle oppgavene gjelder at det bare er ett riktig svar. No Spørsmål Svar A Svar B Svar C Svar D 1 Kanban er et eksempel på: Prosess Software prosess Prosess modell
DetaljerLøsningsforslag Sluttprøve 2015
Høgskolen i Telemark Løsningsforslag Sluttprøve 2015 Emne: IA4412 Systemutvikling og dokumentasjon Fagansvarlig: Hans- Petter Halvorsen, Olav Dæhli Klasse: IA2, A- vei Dato: 2015.05.27 Time: 09:00-12:00
DetaljerErfaring med funksjonell testing i en integrert ALM prosess
Erfaring med funksjonell testing i en integrert ALM prosess Forutsetninger for å kunne gjennomføre effektiv test Høy testdekning ved hjelp av regresjonstesting Feilhåndtering gjennom hele livssyklusen
DetaljerUKE 10 Kravhåndtering. Gruppetime INF1055
UKE 10 Kravhåndtering Gruppetime INF1055 Hva skal vi i dag? Kravhåndtering - kapittel 4 Ukesoppgaver: Smidig programvareutvikling og kravhåndtering Krav KRAV KOMPETANSEMÅL: Kravhåndtering: anvende metoder
DetaljerValidering og verifisering. Kirsten Ribu
Validering og verifisering Kirsten Ribu 2005 1 I dag Validering og verifisering Inspeksjon Testing 2 Noen ord om prosjektet Sjekk kurssidene jevnlig. Endringer forekommer (forelesningsplanen) Hvordan fungerer
DetaljerBlackBox, WhiteBox og andre testmetoder. Etter ønske fra studentene 26. november 2009
BlackBox, WhiteBox og andre testmetoder Etter ønske fra studentene 26. november 2009 Hva er testing? Testing er å undersøke IT-systemer eller deler av det for å vurdere om kravene til det som testes er
DetaljerKort om evaluering og testing av It-systemer. Hvordan vurdere, verdsette, velge og teste?
Kort om evaluering og testing av It-systemer Hvordan vurdere, verdsette, velge og teste? Evaluere - Bokmålsordboka Evaluere Vurdere, verdsette, gi karakter for. Vurdere Bedømme, verdsette. Bedømme Dømme
DetaljerUKE 15 Prosjektledelse, planlegging og teamarbeid. Gruppetime INF1055 Julie Hagen Nilsen & Maria Stolinski
UKE 15 Prosjektledelse, planlegging og teamarbeid Gruppetime INF1055 Julie Hagen Nilsen & Maria Stolinski Hva skal vi i dag? Se på oblig 5 Prosjektledelse og teamarbeid (kap. 22) Prosjektplanlegging og
DetaljerGJENNOMGANG UKESOPPGAVER 7 REPETISJON
GJENNOMGANG UKESOPPGAVER 7 REPETISJON INF1050 V16 KRISTIN BRÆNDEN DAGENS TEMA Oppgaver hentet fra tidligere eksamensoppgaver om temaene vi har gått gjennom til nå DAGENS PLAN Gjennomgang av oppgaver Repetisjon
DetaljerMellom barken og veden Smidig testing i krevende terreng TTC 2015
Mellom barken og veden Smidig testing i krevende terreng TTC 2015 FOREDRAGSHOLDERE Kristian Bjerke-Gulstuen Accenture siden 1999 Fra utvikler til Testleder og Kvalitetsansvarlig Leder Accenture Norway
DetaljerForside Eksamen INF1055 V17
Forside Eksamen INF1055 V17 Eksamensdato: 12. juni 2017 Eksamenstid 15:30-19:30 Hjelpemidler: Ingen Les denne forsiden nøye Oppgaven består av seks deler. Del 1 Modul A - Undersøkelser av bruk 2 diskusjonsspørsmål
DetaljerGJENNOMGANG UKESOPPGAVER 2 PROSESSMODELLER OG SMIDIG PROGRAMVAREUTVIKLIG
GJENNOMGANG UKESOPPGAVER 2 PROSESSMODELLER OG SMIDIG PROGRAMVAREUTVIKLIG INF1050 V16 HVA ER EN SYSTEMUTVIKLINGSPROSESS? De aktivitetene som utføres for å utvikle et IT-system Eksempler på aktiviteter:
DetaljerAkseptansetesten. Siste sjanse for godkjenning Etter Hans Schaefer
Akseptansetesten Siste sjanse for godkjenning Etter Hans Schaefer Akseptansetesting Formell testing med hensyn til brukerbehov, krav, og forretningsprosesser som utføres for å avklare om et system oppfyller
DetaljerTestdekning og automatisering - Er 100% testdekning et mål?
Testdekning og automatisering - Er 100% testdekning et mål? Shomaila Kausar, Senior prosjektleder/testleder Ole Fingal Harbek, Senior Testleder Testdagen Odin 2017 Kort om oss Shomaila Kausar - cand scient
DetaljerUNIVERSITETET I OSLO
Bokmål Kandidat nummer: UNIVERSITETET I OSLO Det matematisk-naturvitenskapelige fakultet Eksamen i: INF1050 Eksamensdag: 31. Mai, 2011 Tid for eksamen: 09:00-13:00 Oppgavesettet er på 6 sider Vedlegg:
DetaljerForelesning IMT mars 2011
Forelesning IMT2243 17.mars 2011 Dagens : Kvalitetssikring i systemutviklingsprosjekter Konfigurasjonsstyring Teorigjennomgang Demonstrasjon av Subversion SVN v/jon Langseth Pensum : Sommerville kap. 24.1
DetaljerAltinns nye tjenesteverksted. Lars Vegard Bachmann, produkteier portal og tjenester, Altinn
Altinns nye tjenesteverksted Lars Vegard Bachmann, produkteier portal og tjenester, Altinn 01 Nytt tjenesteverksted? Hva mener du med det? Bakgrunn, mål, konsept og overordnet beskrivelse 02 Det høres
DetaljerEksamen 2013 Løsningsforslag
Eksamen 2013 Løsningsforslag Oppgave 1. Multiple choice 1b# 2a# 3b# 4c# 5b# 6a# 7a# 8b# 9d# 10b# Oppgave 2 - Bibliotek - Utlån av bøker a) Måle størrelse eller mengde funksjonalitet Denne oppgaven ser
DetaljerLøsningsforslag: Oblig 1. INF1050: Gjennomgang, uke 12
Løsningsforslag: Oblig 1 INF1050: Gjennomgang, uke 12 Obligatorisk oppgave 1: Pensum Bakgrunn for systemet Aktører og interessenter Utviklingsprosesser Kravhåndtering og kravspesifikasjon Use case-modellering
DetaljerISTQB Foundation Level Prøveeksamen
ISTQB Foundation Level Prøveeksamen Svar på følgende spørsmål For hvert spørsmål er der ETT og BARE ETT rett svar! (Unntak er avmerket spesielt). Spørsmål til Kap 1 ("Fundamentals") 1.1. (K2) Hva er betydningen
DetaljerSystem integration testing. Forelesning Systems Testing UiB Høst 2011, Ina M. Espås,
System integration testing Forelesning Systems Testing UiB Høst 2011, Ina M. Espås, Innhold Presentasjon Hva er integration testing (pensum) Pros og cons med integrasjonstesting Når bruker vi integration
DetaljerHensikten med denne delen av kurset. Objektets egenskaper. Objektorientering hva er det? Best practises ved programvareutvikling. Kravspesifikasjonen
Hensikten med denne delen av kurset Objektorientert systemutvikling Rational Unified Process (RUP) Gurholt og Hasle kap. 6 UML Distilled kap. 2 Å lære modellerings- og designprinsipper og øve opp teknikker
DetaljerModellering IT konferanse
Modellering IT konferanse 1. Interessenter Utviklere som besøker konferansen: besøke IT konferanse Frivillige hjelpere: få gratis inngang på konferansen Ledelse: Tjene penger Matkjeder: Selge mat og drikke,
DetaljerObligatorisk oppgave 3. INF1050: Gjennomgang, uke 16
Obligatorisk oppgave 3 INF1050: Gjennomgang, uke 16 Pensum for oppgaven Estimering Arkitektur 4+1 view-modellen og lagdeling Arkitektoniske stiler UML-modellering Tilstands- og aktivitetsdiagrammer Testing
DetaljerGJENNOMGANG UKESOPPGAVER 3 KRAVHÅNDTERING
GJENNOMGANG UKESOPPGAVER 3 KRAVHÅNDTERING INF1050 V16 HVA ER KRAVHÅNDTERING? Kravhåndtering er prosessen å identifisere, analysere og spesifisere kravene til et nytt system eller et system som skal forbedres
DetaljerForfattere: Daníelsdóttir, Drífa Meland, Maiken Mijalkovic, Biljana Svendsen, Simen H. Gruppelærer: Zarei, Amir Hossein. 5.
2 Forfattere: Daníelsdóttir, Drífa Meland, Maiken Mijalkovic, Biljana Svendsen, Simen H. Gruppelærer: Zarei, Amir Hossein 5. april 2017 Innhold 1 Klassediagram 2 Sekvensdiagram 2.1 Oppgave 2a 2.2 Oppgave
DetaljerEventhandler Teknologi, kunst og design Høgskolen i Oslo og Akershus, våren 2013. Testrapport
Eventhandler Teknologi, kunst og design Høgskolen i Oslo og Akershus, våren 2013 Testrapport 1 INNHOLDSFORTEGNELSE 1 INNHOLDSFORTEGNELSE... 1 2 Innledning... 2 3 Formål med testing... 3 3.1 Funksjonalitet...
DetaljerProsjektledelse, planlegging og teamarbeid. INF1050: Gjennomgang, uke 10
Prosjektledelse, planlegging og teamarbeid INF1050: Gjennomgang, uke 10 Kompetansemål Prosjektstyring og prosjektledelse Hva og hvorfor? Risikohåndtering Ledelse av mennesker og motivasjon Teamarbeid og
DetaljerSystemutviklingen er ferdig når et system er operativt. Med operativt menes når systemet blir brukt av brukerne på et faktisk arbeidssted.
Presentasjon nummer 5 The changing system and the nature of maintenance Silde 1 Gruppen introduseres Slide 2 The changing system and the nature of maintenance The Changing system Systemutviklingen er ferdig
DetaljerUKE 11 UML modellering og use case. Gruppetime INF1055
UKE 11 UML modellering og use case Gruppetime INF1055 Hva skal vi i dag? Analyse og design - kapittel 5 og 7 UML modellering Ukesoppgaver 3: Modellering av krav UML UML Kompetansemål Modellering av krav
DetaljerEstimering. INF1050: Gjennomgang, uke 09
Estimering INF1050: Gjennomgang, uke 09 Kompetansemål Estimering Hva og hvorfor? Estimeringsprinsipper Estimeringsprosessen Spesifikasjonsbasert testing / Strukturbasert testing Estimeringsmodeller COCOMO
DetaljerEksamen INF1050: Gjennomgang, uke 15
Eksamen 2012 INF1050: Gjennomgang, uke 15 Overblikk Varierte spørsmål fra pensum Modellering Use case Tekstlig beskrivelse Sekvensdiagram Klassediagram Krav Empiriske metoder Smidig metodikk Varierte spørsmål
DetaljerTestrapport. Aker Surveillance. Gruppe 26. Hovedprosjekt ved Høgskolen i Oslo og Akershus. Oslo, 24.5.2013. Public 2013 Aker Solutions Page 1 of 5
Testrapport Aker Surveillance Gruppe 26 Hovedprosjekt ved Høgskolen i Oslo og Akershus Oslo, 24.5.2013 Public 2013 Aker Solutions Page 1 of 5 Innledning I denne rapporten vil vi skrive om testingen som
DetaljerRepetisjon av testing. Vi undersøker om systemet virker slik det skal
Repetisjon av testing Vi undersøker om systemet virker slik det skal Test av software For å teste om alle kravene er oppfylt må kravspesifikasjon og utviklingsdokumenter gjennomgås. Hvordan programmet
DetaljerProsessmodeller og smidig programvareutvikling. INF1050: Gjennomgang, uke 02
Prosessmodeller og smidig programvareutvikling INF1050: Gjennomgang, uke 02 Kompetansemål Prosessmodeller Kunne redegjøre for hva som kjennetegner ulike prosessmodeller Vurdere prosesser for utvikling
DetaljerKontrakter og test i smidige prosjekter. Fagmøte Dataforeningen i Trondheim 12.Mars 2012
Kontrakter og test i smidige prosjekter Fagmøte Dataforeningen i Trondheim 12.Mars 2012 Agenda Smidige manifest Smidige prosjekter og testing Samarbeid og tillit teori Hva er en kontrakt Gjennomgang av
DetaljerOppsummering. Thomas Lohne Aanes Thomas Amble
Oppsummering Thomas Lohne Aanes Thomas Amble 14.11.04 Kapittel 2: Data Modell Mål: Data som skal brukes av applikasjonen blir spesifisert på en formell og likevel intuitiv måte. Resultat: Vi får et konseptuelt
DetaljerUKE 13 Mer UML modellering. Gruppetime INF1055 Julie Hagen Nilsen & Maria Stolinski
UKE 13 Mer UML modellering Gruppetime INF1055 Julie Hagen Nilsen & Maria Stolinski Hva skal vi i dag? Objektorientert design - kapittel 5 og 7 UML modellering Aktivitetsdiagrammer Klassediagram Ukesoppgaver
DetaljerRepetisjon av testing. Vi undersøker om systemet virker slik det skal
Repetisjon av testing Vi undersøker om systemet virker slik det skal Test av software For å teste om alle kravene er oppfylt må kravspesifikasjon og utviklingsdokumenter gjennomgås. Hvordan programmet
DetaljerTest i Praksis. NTNU Februar 2014. Copyright 2014 Accenture All Rights Reserved.
Test i Praksis NTNU Februar 2014 Hvem er vi? Erik Gjerdrum Master i Kommunikasjonssystemer fra IFI UiO Jobbet med test i siden 2006 Markus Living Master i Industriell Økonomi fra Linköping, Sverige Jobbet
DetaljerUKEOPPGAVER 13: KONFIGURASJONSSTYRING
UKEOPPGAVER 13: KONFIGURASJONSSTYRING Formål: I denne oppgaven skal dere få litt hands on med versjonskontrollsystemet Subversion. Meningen er at du skal prøve å relatere prinsippene det ble forelest om
DetaljerUKE 16 Kontrakter. Gruppetime INF1055 Julie Hagen Nilsen & Maria Stolinski
UKE 16 Kontrakter Gruppetime INF1055 Julie Hagen Nilsen & Maria Stolinski Hva skal vi i dag? OBS!! Siste ordinære gruppetime Kontrakter Ukesoppgaver Gjennomgang av oblig 4 Kontrakter Kompetansemål - Kontrakter
DetaljerCORBA Component Model (CCM)
CORBA Component Model (CCM) INF5040 Høst 2005 Erlend Birkedal Jan Erik Johnsen Tore Ottersen Løkkeberg Denne presentasjonen CORBA Svakheter ved CORBA Object Model Komponenter CORBA Component Model Hva
DetaljerPresentasjon 1, Requirement engineering process
Presentasjon 1, Requirement ing process Prosessodeller Hvorfor bruke prosessmodeller? En prosessmodell er en forenklet beskrivelse av en prosess En prosessmodell er vanligvis lagd ut fra et bestemt perspektiv
DetaljerLykke til! Eksamen i fag TDT4140 Systemutvikling 28.11.2012 9.00. NTNU Norges teknisk-naturvitenskapelige universitet
Side 1 av 10 NTNU Norges teknisk-naturvitenskapelige universitet BOKMÅL Fakultet for informasjonsteknologi, matematikk og elektroteknikk Institutt for datateknikk og informasjonsvitenskap Sensurfrist:
DetaljerTESTRAPPORT Tittel på hovedprosjektet: Varebestillingssystem for Wokas Salg AS
TESTRAPPORT Tittel på hovedprosjektet: Varebestillingssystem for Wokas Salg AS Medlemmer av gruppe 35: Joakim Larsen, s150070, 3AB Kristian Kjelsrud, s147787, 3IA Anastasia Poroshina, s140720, 3AB Prosjektperiode:
DetaljerForskningsmetoder. INF1050: Gjennomgang, uke 13
Forskningsmetoder INF1050: Gjennomgang, uke 13 Kompetansemål Forskningsmetoder Hva? Hvorfor? Empiriske forskningsmetoder Eksperiment Case-studier Etnografi Aksjonsforskning Spørreskjema Systematisk litteraturstudie
DetaljerSystemutvikling. Universitetet i Oslo, Institutt for informatikk Vår 2017
Systemutvikling Universitetet i Oslo, Institutt for informatikk Vår 2017 Dagens plan Introduksjon Emnets oppbygging Praktisk om ukesoppgaver og obligatoriske oppgaver Gjennomgang av ukesoppgaver Registrering
DetaljerKirsten Ribu
Validering og verifisering Kirsten Ribu 03.03.04 1 I dag Validering og verifisering Prototyping Inspeksjon Testing 2 Validering og verifisering Å sørge for at et datasystem tilfredsstiller brukerens behov
DetaljerAutomatisert Robusthetstesting. Erik Arisholm Testify AS
Automatisert Robusthetstesting Erik Arisholm Testify AS 21. september Robusthetstesting Robusthetstesting er testing som avslører sårbarheter i et system overfor uventede (kombinasjoner av) input stressende
Detaljeraltinn tjenester 3.0
14.09.2016 altinn tjenester 3.0 Agenda Hva er tjenester 3.0? Status Konsepter Demo og diskusjoner altinn tjenester 3.0 Hva er tjenester 3.0? Hva er tjenester 3.0? Brukervennlige og responsive tjenester
DetaljerEKSAMEN. Evaluering av IT-systemer. Eksamenstid: kl 0900 til kl 1300
EKSAMEN Emnekode: ITL24006 Dato: 4. desember 2007 Hjelpemidler: Emne: Evaluering av IT-systemer Eksamenstid: kl 0900 til kl 1300 Faglærer: Ingen, heller ikke kalkulator eller mobiltelefon Kåre Sorteberg
DetaljerTest i smidig. Laila Sandbæk Testrådgiver og testleder Sogeti
Test i smidig Laila Sandbæk Testrådgiver og testleder Sogeti 03.03.2016 Produktkøen til foredraget Sprintrytme Plassering av testaktivitetene i sprintrytmen Teamet Test som en integrert del av gjennomføringsmodellen
DetaljerTest og kvalitet To gode naboer. Børge Brynlund
Test og kvalitet To gode naboer Børge Brynlund To gode naboer som egentlig er tre Kvalitetssikring, kvalitetskontroll og testing Kvalitet I Betydningen Kvalitet er den viktigste faktoren for å avlede langsiktig
DetaljerProsjektet - leveranser. Testing og evaluering av systemer. Hva er sikkerhetskritiske systemer? I dag: Systemfeil og testing. Robust kraftforsyning?
Testing og evaluering av systemer Kirsten Ribu 23.10.2007 Prosjektet - leveranser Utfyll prosjektplanen etterhvert: Estimat Risikoplan Kravspesifikasjon Roller og arbeidsoppgaver Lag mappe med gruppenavn,
DetaljerGJENNOMGANG OBLIGATORISK OPPGAVE 1
GJENNOMGANG OBLIGATORISK OPPGAVE 1 INF1050 V16 KRISTIN BRÆNDEN 1 Systemet for utleie av markasykler ønsker a benytte seg av en eksisterende betalingsløsning, og valget har falt pa det samme betalingssystemet
DetaljerGJENNOMGANG UKESOPPGAVER 4 USE CASE MODELLERING HELGA NYRUD & KRISTIN BRÆNDEN
GJENNOMGANG UKESOPPGAVER 4 USE CASE MODELLERING INF1050 V16 HELGA NYRUD & KRISTIN BRÆNDEN TEMAER SÅ LANGT I KURSET Forelesning 1: Systemutvikling og systemutviklingsprosesser Forelesning 2: Prosessmodeller
DetaljerOppgave 1 Multiple Choice
Oppgave Multiple Choice a 2c 3a 4c 5d 6d 7a 8b 9b 0a b 2c 3c 4a 5b 6b 7a 8d 9c 20b Se video fra forelesningen (Kahoot) for mer detaljer) Eksamen INF050-204 Oppgave 2 a Aktivitetsdiagram Enkelt Eksamen
DetaljerSystemutvikling - oppsummering. Alexander Nossum blog.eksplisitt.net 22. mai 2006
Systemutvikling - oppsummering Alexander Nossum alexander@nossum.net blog.eksplisitt.net 22. mai 2006 INNHOLD 2 Innhold 1 Utviklingsprosessmodeller 3 1.1 Fossefall/waterfall................................
DetaljerModernisering av IKT i NAV
Modernisering av IKT i NAV Test, Leverandørperspektiv Vedtaksløsningen 28.05.13 Kristian Bjerke-Gulstuen Innhold Kort introduksjon til Moderniseringsprogrammet i NAV Overordnet oversikt over test i NAV
DetaljerKravspesifikasjon MetaView
Kravspesifikasjon MetaView BACHELOROPPGAVE VÅREN 2014 1. Presentasjon Tittel: MetaView Oppgave: Lage en applikasjon og api som skal kommunisere med MetaVision slik at det skal bli enklere for leger og
DetaljerHva, Hvorfor og litt om Hvordan
Dokumentasjon Hva, Hvorfor og litt om Hvordan Basert på materiale fra SAGE og andre kilder Hva skal du dokumentere Dokumentere for ditt spesifikke miljø/behov Kilder som er eksterne er ikke tilgjengelig
DetaljerSystemutvikling (Software Engineering) Professor Alf Inge Wang
1 Systemutvikling (Software Engineering) Professor Alf Inge Wang 2 Undervisningsmål og henvisning Målet med timen er: Få kunnskap om hva systemutvikling er Forstå hva en utviklingsprosess består av Få
DetaljerSoftware Test Plan. Team2. Høgskolen i Sørøst-Norge Fakultet for teknologi, naturvitenskap og maritime fag Institutt for elektro, IT og kybernetikk
Software Test Plan Høgskolen i Sørøst-Norge Fakultet for teknologi, naturvitenskap og maritime fag Institutt for elektro, IT og kybernetikk Software Test Plan 06/04/2018 Systemutvikling og dokumentasjon/ia4412
DetaljerInnhold uke 7. Objektorientert programmering i Python: Introduksjon. Lite tilbakeblikk: Programflyt og skop. Lite tilbakeblikk: Funksjoner er uttrykk
Innhold uke 7 Objektorientert programmering i Python: Introduksjon IN1000 Høst 2017 uke 7 Siri Moe Jensen Lite tilbakeblikk: Prosedyrer og funksjoner Objektorientert programmering Introduksjon: Hvorfor,
DetaljerAutomatisert test som leveransekrav
Automatisert test som leveransekrav Testdagen Odin 2015 Marianne Rynning, Skatteetaten Magnus Halvorsen, Testify Skatteetatens IT- og servicepartner (SITS) Skatteetatens leverandør av IT- og administrative
DetaljerCharacteristics of a good design
Characteristics of a good design (PPT. side 1) Innledning Høykvalitetsdesign bør ha visse karakteristikker for å oppnå kvalitetsprodukter, dvs.: enkelt å forstå enkelt å implementere enkelt å teste enkelt
DetaljerKontrakter. INF1050: Gjennomgang, uke 12
Kontrakter INF1050: Gjennomgang, uke 12 Kompetansemål Kontrakter I plandrevet utvikling I smidig utvikling Behov for smidige kontrakter Kontraktsmodeller PS2000 Del I: Kontrakter Grunnleggende: Hva? Plandrevet
DetaljerGruppenavn. Beskrivelse av arkitektur For Navn på systemet. Versjon <1.0>
Gruppenavn Beskrivelse av arkitektur For Navn på systemet Versjon Revisjonshistorie Dato Versjon Beskrivelse av endring Forfatter Innhold 1. Innledning 4 1.1
DetaljerTestrapport Prosjekt nr. 2011-22 Det Norske Veritas
Prosjekt nr. 2011 22 Testrapport Hovedprosjektets tittel Implementering av plugin og utvikling av wizard for Det Norske Veritas Prosjektdeltakere Magnus Strand Nekstad s156159 Jørgen Rønbeck s135779 Dato
Detaljer3.3 Case 3: Opprette en bruker Case 4: Endre en bruker... 8
Testdokumentasjon 1 Forord Denne rapporten omhandler testingen av systemet. Rapporten er først og fremst beregnet på sensor og intern veileder ved Høgskolen i Oslo, men kan gjerne leses av andre som måtte
DetaljerEvaluering av It-systemer i et forvaltningsperspektiv. Drift, vedlikehold og videreutvikling av IT-systemet
Evaluering av It-systemer i et forvaltningsperspektiv Drift, vedlikehold og videreutvikling av IT-systemet Bakgrunnen IT-systemer har ofte lenger levetid enn forventet er ofte forretningskritiske utvikler
Detaljer1. Hvilke type krav angår sikkerhet og pålitelighet?
1. Hvilke type krav angår sikkerhet og pålitelighet? a) Funksjonelle b) Ikke-funksjonelle Svar: b), IS side 88, lærebok s.96 2. Verdien av etnografi er at den hjelper til å oppdage som reflekterer hvordan
DetaljerDel VII: Kravspesifikasjon
1 2 Forord Dette dokumentet inneholder retningslinjer for gruppen vår og beskrivelse av betingelsene for utviklingen av vårt prosjekt. Vår gruppe benyttet dette dokumentet som et styringsdokument for å
DetaljerInnlevering 2b i INF2810, vår 2017
Innlevering 2b i INF2810, vår 2017 Dette er del to av den andre obligatoriske oppgaven i INF2810. Man kan oppnå 10 poeng for oppgavene i 2b, og man må ha minst 12 poeng tilsammen for 2a + 2b for å få godkjent.
DetaljerLæringsmål for forelesningen
Læringsmål for forelesningen Objektorientering Regler for oppførsel Java-programmering JUnit-testing Eclipse Opprette JUnit-test og kjøre den 1 Pensum Testing dekkes ikke av Liang! Er en viktig del av
DetaljerUse case modellen. Use case modellering i analysefasen. Hva er en Aktør? Hva er et Use case? Use case modellering. Eksempel
Use case modellen Use case modellering i analysefasen Metode for å identifisere og beskrive de funksjonelle kravene til et system Kapittel 3 i UML Distilled Kirsten Ribu beskriver kravene til systemet,
DetaljerKunden er en av Norges ledende leverandører av digital-tv og bredbåndstjenester.
1 Forord Hensikten med kravspesifikasjonen er å gi oppdragsgiver og utviklere en enighet og forståelse av funksjonaliteten til applikasjonen som skal produseres. en definerer i tillegg prosjektets rammer
DetaljerEtter uke 6 skal du. Introduksjon til objektorientert programmering. Hva skjedde ~1967? INF1001. Grunnkurs i objektorientert programmering
Etter uke 6 skal du Kjenne til motivasjonen for objektorientert programmering Introduksjon til objektorientert programmering INF1001 Høst 2016 Forstå hva en klasse er, og forskjellen på klasse og objekt
DetaljerProgramvareutvikling hos Sun Microsystems. Jørgen Austvik Sun Microsystems Database Technology Group
Programvareutvikling hos Sun Microsystems Jørgen Austvik Sun Microsystems Database Technology Group Innhold Sun i Trondheim Hva vi lager Utviklingsprosesser Kvalitetsarbeid > Mål > Hva vi gjør Verktøy
DetaljerKapittel 7 & 8. Kravspesifikasjoner & Data design. Thomas Tjøstheim og Thomas Edvinsen. 20 September Kapittel 7 & 8 p.1/20
Kapittel 7 & 8 p.1/20 Kapittel 7 & 8 Kravspesifikasjoner & Data design Thomas Tjøstheim og Thomas Edvinsen 20 September 2004 Kapittel 7 & 8 p.2/20 Introduksjon Kravspesifikasjoner består av to underdeler:
DetaljerAnsvarlig: Faglig ansvarlig for innhold og revisjon, Testseksjonen TestiT, Avd. for Tjenesteproduksjon HN IKT
Teststrategi IKT-testing i Helse Nord Ansvarlig: Faglig ansvarlig for innhold og revisjon, Testseksjonen TestiT, Avd. for Tjenesteproduksjon HN IKT Endring Versjon Rolle / Organisasjon Revidert Revisjon
Detaljer