TDT4735 Systemutvikling, fordypning. Metoder for systemtest av websystemer

Størrelse: px
Begynne med side:

Download "TDT4735 Systemutvikling, fordypning. Metoder for systemtest av websystemer"

Transkript

1 TDT4735 Systemutvikling, fordypning Metoder for systemtest av websystemer Hong Trang Thi Nguyen Veileder: Tor Stålhane Høst Norges teknisk-naturvitenskapelige universitet

2 Forord Dette prosjektet er skrevet i forbindelse med fordypningsfaget TDT4735 Systemutvikling på NTNU i 5. årskurs ved Institutt for Datateknikk og Informasjonsvitenskap, IDI. Oppgaven handler om metoder for systemtesting med fokus på websystemer. Jeg vil gjerne sende en stor takk til IT-sjefen for Proxycom, Trond Johansen, for å ha delt sine praktiske erfaringer og gitt meg gode råd når det gjelder systemtesting. Jeg setter også stor pris på Proxycom og Sparebank 1 som har tatt seg tid til intervjuer, slik at jeg fikk mange gode opplysninger om deres arbeid innenfor dette emnet. Til slutt vil jeg gjerne takke min veileder, Tor Stålhane, for den gode oppfølgingen og hjelpen gjennom dette semesteret. Trondheim 20/ Hong Trang Thi Nguyen II

3 Innhold 1 Innledning Oppgavebeskrivelse Mål med prosjektet Testing Definisjon av testing Testklassifisering Black Box White Box Testfaser Modul/Enhetstest Integrasjonstest Systemtest Regresjonstest Usability test Akseptansetest Plassering av systemtesting i prosjektutviklingen Forstudium Kravspesifikasjon Design Programmering Testing Vedlikehold Praktiske erfaringer med systemtest Feilfinning Testplan Testteam Testrapport Risikoanalyse Konfigurasjonshåndtering Websystem Definisjon av websystem Struktur Krav til websystem Intervju med IT-bedrifter Proxycom Bedriftsintervju med Proxycom Sparebank Bedriftsintervju med Sparebank Krav til metoder for systemtesting av websystemer Metodeundersøkelse 23 III

4 7.1 Metoder for systemtesting Resultat fra metodeundersøkelsen Oversikt over aktiviteter ved systemtesting Generell fremgangsmåte for utførelsen av systemtesting Design for testcase Definisjon av testcase Fremgangsmåte for å lage testcase Illustrering av å lage testcase Oppsummering Validering av prosjektet 42 A Vedlegg - Spørsmål til bedriftsintervju 43 B Vedlegg - Bedriftsintervju med Proxycom 44 C Vedlegg - Bedriftsintervju med Sparebank 1 47 D Vedlegg - Ordforklaringer 50 Figurer 1 Testmodell Testrekkefølge V-modell Websystem arkitektur Use Case diagram for funksjonenene kunden har i systemet Use Case for Bestill produkt Tabell over alle hendelser i riktig rekkefølge Sekvensdiagram - Bestill produkt Tabeller 1 Tabell som viser ansvarsfordeling Tabell for risikoanalyse Kravmatrise for metodene A: Gradering av feil B: Gradering av feil Tabell over alle testene med tilhørende krav Malen for testtabell basert på IEEE std Liste over feil ved første systemtest Liste for testresultatene Use Case - Bestill produkt Testcase - Bestill produkt

5 1 Innledning 1.1 Oppgavebeskrivelse Testing er viktig for å kontrollere validering og verifikasjonsprosessen. Validering er å finne ut om vi har laget det rette produktet, mens verifikasjon ser på om man har laget produktet på riktig måte. Validering og verifikasjon brukes på alle trinn i systemutviklingen for å sikre at systemet følger spesifikasjonen og at man lager det som brukeren ønsker [35]. Testing er et stort emnet i systemutvikling, derfor har jeg begrenset oppgaven til metoder for systemtesting av websystemer. Dette syns jeg er et interressant emnet, for det er viktig å utføre så god systemtesting av websystemer som mulig, ellers kan det få katastrofale konsekvenser for bedrifter. I kapittel 2 vil jeg beskrive hva testing er og hvilke typer tester som man bør utføre for websystemer. Kapittel 3 handler om ulike faser i prosjektutviklingen med tilhørende dokumenter. Det er viktig å vite de praktiske erfaringer med systemtesting som er beskrevet i kapittel 4. Oppgaven går ut på å finne en systematisk metode eller retningslinjer for systemtesting og utforming av testcase manuelt, derfor har jeg foretatt metodeundersøkelser i kapittel 7 ved å intervjue to IT-bedrifter. Hvilke krav disse bedriftene har til systemtesting av websystemer er beskrevet i kapittel 6, og nærmere beskrivelser av strukturen til websystemer i kapittel 5. Hvilke aktiviteter som finnes ved systemtesting, og hvordan man utformer gode og testbare testcase er beskrevet i kapittel 8. Oppsummering og validering av prosjektet finnes i kapittel 9 og Mål med prosjektet Dårlig systemtesting av websystemer kan føre til store økonomiske konsekvenser, derfor er det behov for bedrifter å få mer informasjon om flere metoder for systemtesting av websystemer slik at man kan tilpasse en metode til sitt eget prosjekt. Det er mange bedrifter som ikke benytter noen bestemte metoder eller verktøy for systemtesting. Fremgangsmåten som mange benytter idag er manuell systemtesting basert på egne erfaringer. Å utføre systemtesting av websystemer systematisk er en god fremgangsmåte for å sikre at alle de viktige aktiviteter blir utført. Det er også viktig å ha en god fremgangsmåte til å lage testcase i systemutvikling. Målet med dette prosjektet er derfor å finne informasjoner om metoder for systemtest av websystemer, og samtidig beskrive en systematisk fremgangsmåte i systemtesting av websystemer og utforming av testcase slik at bedrifter kan høy sannsynlig utvikle et kvalitetsprodukt. Alle bedrifter vil at deres produkter og tjenester skal vise kvalitet og effektivitet, og det er essensielt at testing må være godt utført. Ved å ha en formalisert testprosess kan man oppdage feil som oppstår på et tidlig tidspunkt, og da har man mulighet til å rette dem opp før man lanserer produktet. Dette vil føre til mange fordeler for en bedrift som besparelse av tid, ressurser og kostnader. Jo senere en feil oppdages, desto mer alvorlig og større konsekvenser får den. 2

6 2 Testing Testing har lenge vært undervurdert i systemutvikling, og mange prosjekter mislykkes på grunn av dette. Testing er viktig i alle utviklingsarbeid, fordi testing vil kunne validere om kravene til et system er tilfredsstilt som forventet. Testing er nødvendig, så det er viktig å vite hva testing egentlig er. 2.1 Definisjon av testing Testing brukes for å kontrollere utførelse, pålitelighet og brukergrensesnitt og for å sjekke om kravene var riktig i forhold til hva brukeren ønsker [34]. Målet for testing er å sjekke hvor godt et system oppfyller kundenes krav, og resultatet av kjøringer blir sammenlignet med fasit. Det er derfor lønnsomt å teste tidlig og jevnlig under hele utviklingen. Når man snakker om testing vil man ofte forbinde det med kvalitetssikring. Hensikten med testing er å finne feil, og en vellykket test er en test der man finner feil i programkoden, designet, kravspesifikasjonen eller dokumentasjonen for systemet [27]. Fordelen med testing er at man kan finne feil i tidlig fase av utviklingen, slik at man kan spare tid og arbeid. Testing kan ikke garantere at systemet er feilfri, men testing kan brukes til å vurdere om man vil eller kan produksjonssette en release av et system. Det er større sannsynlig at testing blir vellykket, dersom den inneholder disse tre punktene [7]: Repeterbarhet : hvis man finner feil, repeterer man senere testen for å sjekke at feil er blitt fikset. Systematisk : random (tilfeldig) testing er ikke tilstrekkelig, derfor er det lurt å gjennomføre testing systematisk for å dekke alle brukstilfellene i systemet. Dokumentert : bedre oversikt når man har skrevet testdokumentet med resultater fra testene, slik at kunden kan også se hvilke tester som er blitt utført for systemet. Det er viktig å skille mellom debugging og testing. Debugging reparerer en påvist feil, og testing søker å påvise slike feil. Debugging er en prosess for lokalisering hvor i koden feilen ligger, og deretter blir feilen rettet opp. Debugging skjer på følgende måte [2]: Bruke minimal test som fremprovoserer feil. Lokaliser feil. Reparer feil. Teste igjen med minimal test. 3

7 Figur 1 viser en typisk testmodell i systemutvikling. Under testingen setter man opp et sett av inndata og forventede utdata basert på de gitte inndata, og kjører deretter testen for å sjekke om de faktiske resultatene stemmer overens med de forventede resultatene. Figur 1: Testmodell Her er en nærmere beskrivelse av figuren: Testobjekt: systemet vi skal teste Testprogram: aktiviteter i testprosessen 1. Spesifisere tester 2. Utføre tester 3. Skrive testrapport Inndata: det som skal testes Utdata: forventede resultater eller output 4

8 Et system kan befinne seg i ulike tilstander avhengig av hvor i utviklingsprosessen det er. De lagrede data i databasen bestemmer systemets tilstand. Systemets output bestemmes ikke bare av input, men også av systemets tilstand. Variablene i det kjørende programmet vil forandre seg under testingen, og systemets tilstand vil være avhengig av databasens innhold. Det er viktig å identifisere hver enkelt transaksjon med en transakjonsid som er generert automatisk av databasesystemet. Systemloggen lagres regelmessig på disk og brukes for å gjenopprette tilstanden i databasen rett før feilsituasjonen oppstod [17]. 2.2 Testklassifisering Nedenfor har jeg tatt for meg to måter å gjennomføre test på, Black box- og White box testing Black Box Black box testing eller funksjonell testing er en testmetode der testen bygger på programmet eller komponentspesifikasjon. Under black box testing velger man tester ved å se på systemets eller komponentens grensesnitt og ikke på hvordan komponenten er realisert [1]. Black box [11]: Sterke sider: Lett å bevare fokus på og teste funksjonaliteten. Lett å automatisere testen ut fra kravspesifikasjonen. Svake sider: Kan ikke hjelpe oss når vi skal finne feil i koden White Box White box er en metode der testene bygger på kunnskap om programvarestrukturen og implementasjon. White box testing skjer når man velger tester ut fra hvordan systemet eller komponenten er realisert. Hensikten er å teste alle veier gjennom systemet [1]. White box [11]: Sterke sider: Kan teste alle veier og ta hensyn til spesielle forhold ved implementasjonen. Svake sider: Lett å fortape seg i detaljer ved implementasjonen og glemme funksjonaliteten. 5

9 2.3 Testfaser Testing er en aktivitet som vil foregå under hele utviklingsprosjektets levetid. Det er viktig å gjennomføre testing på flere nivåer for å avdekke feil og kvalitetssikre produktet. Typiske former for testing underveis er enhetstesting av kodemoduler, integrasjonstesting når man setter sammen flere moduler eller skal ha systemet til å fungere sammen med eksterne systemer, brukbarhetstesting for å avdekke problemer med brukergrensesnitt. Vi kan begynne å teste modulene etterhvert som de blir utviklet, for så å teste om den fungerer i samspill med resten av systemet som er utviklet. Dermed vil feil bli oppdaget på et så tidlig tidspunkt som mulig [29]. Teststrategien medfører følgende tester : Modul/Enhetstest Integrasjonstest Systemtest Regresjonstest Usability test Akseptansetest Alle disse testfasene er ikke nødvendig for alle prosjekter, men i websystemer bør man ihvertfall bruke de fire testfasene enhetstest, integrasjonstest, systemtest og akseptansetest. Det er vanlig å gjennomføre disse testfasene i den rekkefølgen som er vist i figur 2, og gjerne i flere iterasjoner. En iterasjon er gjennomgang av hele rekken av arbeidsoppgaver. Man planlegger, spesifiserer, designer, implementerer, integrerer og tester litt av gangen for hver iterasjon. Figur 2: Testrekkefølge 6

10 Alle disse testene utføres når systemet lages første gang og ved enhver senere endring av systemet. Enhetstest og integrasjonstest utføres med White box testing, fordi testene gjerne forutsetter innsikt i systemets indre oppbygning. Metoder og verktøy for disse to testfasene er ofte ganske like, og det er ikke uvanlig at de flettes mer eller mindre sammen. Systemtest og akseptansetest utføres med Black box testing, fordi testene ikke skal forutsette innsikt i systemets indre oppbygning. Metoder og verktøy for disse to fasene er ofte ganske like, så i prosjekter med sterk brukermedvirkning er det derfor er det vanlig at de flettes mer eller mindre sammen [28] Modul/Enhetstest Enhetstest eller modultest er testing av en avgrenset del av et system separat. Enheten som tester en enkelt modul som f.eks. en klasse eller kildekodefil uten de andre enhetene som den normalt kommuniserer med Integrasjonstest Integrasjonstest er testing av grensesnittet mellom enheter eller moduler i et system. Denne testingen utføres med White box testing og tar utgangspunkt i både koden og designet. Integrasjonstesten skal ikke dekke all kode, og heller ikke all funksjonalitet. Den har fokus på det som ikke er med i enhetstestene, det vil si fokusere på at de enhetstestede modulene fungerer sammen som de skal [28]. Integrasjonstesten kan godt inneholde noe ad hoc testing i tillegg, og ad hoc testing betyr i denne sammenheng å teste brukergrensesnittet på tvers av enhetene som systemet er bygget opp av. Ad hoc testing bør tas med når man har integrert seg opp til et nivå med brukergrensesnitt Systemtest Systemtest består i å teste systemet som helhet, og grunnlaget for testingen er kravspesifikasjonen for systemet. Her tester man om systemet oppfører seg korrekt i samspill med omgivelsene, og denne testingen blir ofte utført av en egen testgruppe. Systemtest skal ikke bare teste funskjonelle kravene, men skal også inkludere ikke-funksjonelle tester [28]. 7

11 De typiske testene innen systemtest for websystemer er ytelsestest, sikkerhetstest, stresstest, recoverability-test og nettlesertest. For websystemer trenger man [11]: Funksjonell test for å sjekke om en modul tilfresstiller de eksterne kravene man har satt til den. Ytelsestest for å teste hastigheten for en transaksjon. Sikkerhetstest for å sikre systemet mot inntrengere. Stresstest for å teste hastigheten på mange samtidige transaksjoner. Nettlesertest for å sørge at systemet støtter alle versjoner av nettleserne. Recoverability-test for å sjekke systemets håndtering av uforutsette avbrudd Regresjonstest Regresjonstest betyr gjentagelse av en eller flere testfaser for å verifisere at feilrettinger eller endringer ikke har introdusert nye feil eller uønskede effekter [28]. Denne testingen skal samtidig sjekke at systemet fremdeles tilfredsstiller de spesifiserte kravene. Man kjører bare en utvalgt del av de aktuelle testfasene for å spare tid. Regresjonstest er nødvendig i forbindelse med feilretting under nyutvikling, eller når man senere lager nye utgaver av systemet Usability test Usability testing, eller brukbarhetstesten er testen for å finne ut hvor lett systemet er å forstå og bruke [31]. Ved å observere brukere under brukbarhetstesten vil man få tilbakemeldinger på hva som bør forbedres i eksisterende systemer. Man trenger brukbarhetstest for å teste designet mot virkeligheten, altså av reelle brukere Akseptansetest Akseptansetest blir ofte kalt for en alfa test, og hensikten med denne testen er å få systemet godkjent av kunden [35]. For at systemet skal bestå akseptansetest må systemet fungere i henhold til brukernes krav. Akseptansetest er nesten samme som systemtest, men her blir testingen utført av kunden. 8

12 3 Plassering av systemtesting i prosjektutviklingen Det finnes mange forskjellige systemutviklingsmodeller idag. Fossefallsmodell og inkrementellutvikling er de mest brukte i prosjektutvikling. Systemutviklingsmodellene gir en oversikt over faser, aktiviteter og milepæler til et IT-prosjekt [20]. I fossefallsmodellen deles prosjektene opp i forstudie, kravspesifisering, design, programmering og vedlikehold, mens inkrementell utvikling innebærer at et system utvikles trinnvis i flere iterasjoner [25]. Uansett hvilke modell man bruker i systemutvikling, så bør den inneholde disse fasene: 1. Forstudium 2. Kravspesifikasjon 3. Design 4. Programmering 5. Testing 6. Vedlikehold Når man har analysert kundekravene grundig og konstruert en logisk modell for systemet, vil det være mer sannsynlig at prosjektet lykkes. Det er vanlig å bruke de fire testtypene enhetstest, integrasjonstest, systemtest og akseptansetest i websystemer. Her er en V-modell som skal vise sammenhengen mellom dokumenttyper og testfasene [28]: Figur 3: V-modell 9

13 3.1 Forstudium Forstudiet fokuserer på å avklare omfanget av systemet, slik at man kan finne ut hvor stor kostnad og tid det vil være for å utvikle et bestemt system. Man trenger denne fasen for å avgjøre om det er lønnsomt for organisasjonen å gå videre med prosjektet eller om den bør stoppes. Noen av hovedaktivitene i denne fasen er [12]: Å definere målsetning og omfang for systemet. Å lage et overordnet systembeskrivelse. Organisering av prosjektgruppen. Estimering av kostnader og tid. Utarbeide risikoliste. Å vurdere alternative løsninger. Planlegging av videre arbeid. 3.2 Kravspesifikasjon I denne fasen er det viktig å forstå kundekravene, og for å sjekke om man har forstått kunden riktig bør man tenke gjennom hva kunden ønsker seg, hvilke problemer som skal løses og hvordan man kan omforme kundekrav til systemkrav på best mulig måte. En annen viktig del av kravspesifikasjonen er sporing av kundekravene. Sporing fra kode til krav og omvendt kan være viktig for å skjønne implementasjonen, og det vil lett oppstå problemer dersom kravene ikke er entydig spesifisert. Det finnes mange krav, så det er vanlig å dele dem inn i to hovedgrupper: Funksjonelle krav : Hva systemet skal gjøre. Ikke funksjonelle krav : Hvordan systemet skal gjøre det, f.eks. responstid. 3.3 Design Når man har analysert kundekravene, kan man gå til designfasen. I denne fasen er det viktig at man lager modeller som for eksempel systemstruktur på en forståelig måte, slik at programmerer realiserer løsningen. 10

14 3.4 Programmering I programmeringsfasen skal man utvikle programsystemet med fokus på å tilfredsstille kundekravene. Programmerere skal realisere løsningen ut fra designdokumentet, og noen oppgaver som programmerer må utføre er [18]: Utarbeide programmoduler Utføre refaktorering: refaktorering er en teknikk som går ut på minst mulig kostnad å endre på programkoden. Skrive kode for metoder 3.5 Testing Det er viktig å teste grundig for å sikre kvaliteten på produktet. Testtypene som finnes er beskrevet i kapittel 2.3, og det er i denne fasen systemtest blir utført. Det er nødvendig å dokumentere testene slik at man får oversikt over hva man har testet og hvilke problemer som oppstår under testingen. Man kan velge mellom automatisert- eller manuell systemtesting, og det er fortsatt mange som benytter manuell testing siden dagens automatiserte verktøy er tidkrevende. 3.6 Vedlikehold Det finnes flere typer vedlikehold : man retter feil, tilpasser til nye omgivelser, legger til ny funksjonalitet eller endre eksisterende funksjonalitet [36]. 11

15 4 Praktiske erfaringer med systemtest 4.1 Feilfinning Når man har funnet feil i en test, må man lete etter feilkilden og rette den opp [32]. Det kan være vanskelig å finne kilden til feilen, særlig når det er flere som har bidratt i kodingen. Det er derfor vanlig å innskrenke området for hvor feilkilden ligger ved å legge inn utskrifter med meldinger om hvor langt kjøringen av programmet har kommet istedenfor å gjøre mange omkompileringer [11]. Når man observerer rekkefølgen av utskriftene etter at feilen har oppstått, vil man ha en viss anelse hvor feilen kommer fra. Dette er en systematisk måte å gjøre dette på, men endelig har man etterhvert feilfinningsverktøy som gjør det enklere for de som programmerer. 4.2 Testplan Systemtestplan Før man skal utføre systemtesting, lønner det seg å lage en systemtestplan. Uansett hvilke metode man velger for systemtesting bør man lage testplan basert på IEEE-standard [15] som inneholder: sammendrag innledning målsetting for systemtesting testverktøy: hvilke hardware/software som brukes under systemtesting klassifisering av feil gradering av feil rapportprosedyre: Testresultatene tidspunkt og personer til å utføre testing ansvarsfordeling for godkjenning av testingen: se eksempel i tabell 1 Hvorfor trenger vi en testplan? Det er nyttig å ha en testplan for alle store prosjekter, siden dette letter koordinering med andre aktiviteter i prosjektet [11]. Når man har en testplan vet man hvem som er ansvarlig for hvilke aktiviteter, hva som skal testes og hvordan man skal kjøre testene. Testplan er spesielt nødvendig å ha dersom kostnaden eller risikoen ved å feile er stor. Tabell 1 er et eksempel på ansvarsfordelingen mellom prosjektmedlemmer. 12

16 Test Tid timer Ansvarlig Systemtest timer Hong Trang Thi Nguyen Brukbarhetstest timer Berit Eleni Sirris Akseptansetest timer Olav Engelsåstrø Tabell 1: Tabell som viser ansvarsfordeling 4.3 Testteam Testing blir en stadig viktigere del av det totale utviklingsprosjektet. Et av problemene med testingen er at man ikke har fått nok opplæring i testing. Det kan være vanskelig å sette seg inn i brukerens situasjon eller at det har vært dårlig testledelse i prosjektet. Hvem burde teste hva? 1. Testere og kundestøtte : Tester det funksjonelle og grensesnittet. 2. Utviklere : Testing av funksjoner og moduler. 4.4 Testrapport Når man har fullført en test, skal man skrive en rapport som oppsummerer resultatet av testingen. Rapporten bør beskrive de feilene som er funnet, for små prosjekt holder det med testlogg [19]. 4.5 Risikoanalyse Risikoanalysen innebærer at man går gjennom alle aktiviteter i prosjektet, og tenker på hva som kan gå galt, hvor sannsynlig er det og hvilke konsekvenser det vil få [1]. Risikoanalyse er nødvendig for å prøve å forhindre slike situasjoner og eventuelt sette tiltak hvis tilfellet skjer [9]. For å oppnå en god kvalitetssikring av systemet er det viktig å utføre risikoanalyse i testing, slik at bedrifter kan vurdere hvilke tiltak som må iverksettes dersom en avvik oppstår. Risikoanalyse hjelper til å kontrollere hvorvidt endringene eller tiltak vil påvirke systemet [21].Tabell 2 er et eksempel på hvordan man kan sette opp en iverk risikoanalyse. 13

17 R3 Forandringer i kravspesifikasjon fra kunde Nr Risiko Beskrivelse Sannsynlighet Alvorlighetsgrad Begrenset innsikt i R1 Gruppen mangler kunnskap og erfaring verktøy kan forsinke prosjektarbeid eller av Høy Middels prosessen R2 Forfall i gruppen Sykdom Høy Lav R3 Feil i estimering Undervurdering av tids- Høy Høy forbruk Må gjøre deler av prosjektet på nytt. Tabell 2: Tabell for risikoanalyse Lav Høy 4.6 Konfigurasjonshåndtering En konfigurasjon er en samling av alle komponentene til et system, og der hver komponent er representert med nøyaktig en versjon. Konfigurassjonsstyring skal håndtere endringer og ulike versjoner av komponenter, og den er basert på et sett av standarder [13]. En konfigurasjonsstyringsplan bør inneholde: Info om endringer og ulike versjoner. Definering av typer dokumenter og navngivningskonvensjon Beskrivelse av verktøyene som brukes for konfigurasjonsstyring, og deres begrensninger Ferdiglagde skjemaer for endringer Oppfølging og arkivering Definering av personansvar 14

18 5 Websystem Websystemer representerer en stadig økende teknologi med mange internett brukere. Det som er utfordrende for slike applikasjoner er å benytte testing til å sikre pålitelighet, sikkerhet, robusthet og høy ytelse. Hva er kjennetegnet til websystemer og hvilke områder man bør teste når man utvikler websystemer vil bli beskrevet i kapittel 5. Hvordan vi skiller systemtesting av websystemer fra tradisjonelle programvarer blir diskutert i kapittel Definisjon av websystem Websystem innebærer lagdelte applikasjoner som aksesseres via en webbrowser; standard HTTP-protokoll, og det er den store forskjellen fra tradisjonelle programvarer. Testingen av internettløsninger vil ha tilnærmet samme strategier og metoder som testing av grafiske brukergrensesnitt. Den første utfordringen for websystemer er testing av flere nettlesere, og det bør også testes på ulike operativsystemer. Testingen går ut på å sette opp et sett av inndata og forventede utdata basert på de gitte inndata. Deretter blir testen kjørt, og man ser om de oppnådde resultatene stemmer overens med de forventede resultatene [27]. En annen utfordring er presset til å ha en time-to-market som er kort som mulig. Testene som blir gjennomført vil da ha fokus på å oppdage feil som kan forårsake uakseptable oppførsel. Det er viktig å finne en god metode eller et verktøy til å måle robusthet i websystemet, noe som jeg har utelatt på grunn av begrensing av oppgaven. Målet for alle prosjekter er å levere en feilfri vare, men i tillegg til det vil websystemer fokuserer mye på høy kvalitet, ytelse og stabilitet. Det er derfor nødvendig å benytte stabilitetstest og stresstest for å finne hvor bra systemet takler når en mengde brukere blir koplet til systemet samtidig (skalerbarhet) [14]. 5.2 Struktur Websystemer innebærer klienter som for eksempel er kundens nettleser, og en eller flere fysiske servere som bidrar til flere typer av service [14]. En server kan for eksempel være en webserver eller databaseserver som inneholder alle data. En webservice er en samling av protokoller og standarder som brukes for å dele data mellom applikasjoner. En nettleser (browser) er et program som brukes til å vise innhold ifra internett, og all spørringer vil gå fra klienten til serveren [1]. Figur 5 viser en typisk struktur for et websystem: 15

19 Figur 4: Websystem arkitektur Et websystem skal være organisert som en bok med sider, og koblingen mellom sidene bør være logisk og lett og oppfatte [22]. Det er viktig å ha et forståelig og godt brukergrensesnitt, slik at brukeren kan finne fram til den han/hun leter etter uten å måtte gå via for mange sider med linker. Linker bør plasseres slik at brukeren lett finner dem, og for å fremheve dem kan man skille linkene tydelig fra annen tekst med farge eller grafiske symboler. 5.3 Krav til websystem Følgende faktorer er viktige når vi utvikler et nettsted [37]: 1. Time-to-market: Hvor fort kan produktet leveres? Tiden det tar fra å starte produktutviklingen til produktet er ferdigstilt og tilgjengelig på markedet. 2. Robusthet: Tåler systemet uventede problemer? Et robust system må bygges på en solid fundament for ikke å feile. 16

20 3. Understøttelse: Støtter systemet eksisterende standarder og ulike versjoner av nettlesere og operativsystemer? Det bør støtte eksisterende standarder og tilrettelegge for enkle oppgraderinger. 4. Brukervennlighet: Er det lett å forstå logikken i systemet? For at systemet i det hele tatt skal få noen brukere så må det være brukervennlig og intuitivt. Hvor brukervennlig er navigasjonen på nettstedet, og hvor klart og lett forståelig er budskapet? 5. Testbarhet: Kunne alle kravene testes i det ferdige systemet? Det bør også være lett å teste systemet etter modifisering. 6. Yteevne: Oppfyller systemet kravene til responstid? Her bør man definere krav for systemets ytelse i form av nedlastingstider for hver side. 7. Sikkerhet: Er systemet sårbar for inntrengere? Systemet bør ha en beskyttelse mot hackere, og en måte man kan finne ut om systemet kan hackes på er å prøve hacke det selv. 8. Flyttbarhet: Kan systemet kjører på ulike plattformer? Systemet bør være flyttbarhet, det vil si at for eksempel klientene er web-browsere og at database løsningen kan flyttes fritt fra web-server til web-server. 17

21 6 Intervju med IT-bedrifter Oppgaven går ut på å finne gode metoder for systemtesting av websystemer og hvilke krav metodene må tilfredstille. For å vite mer om dagens bedrifter innen systemtesting, har jeg intervjuet to bedrifter for å undersøke hvilke metoder disse bedriftene benytter idag. Etter at metodeundersøkelsen er utført, skal jeg beskrive hvilke framgangsmåte og teknikker som er effektiv for systemtesting av websystemer i kapittel 8. Hensikten med intervjuene er å finne ut hvordan bedriftene jobber med systemtesting spesielt av websystemer, og hvilke krav de har til metode av systemtesting. Jeg har fulgt rådene for hvordan man bør lage og forberede et intervju fra Norsk Nettskole [16]. Det er viktig å være klar over hva du skal spørre om under intervjuet, derfor laget jeg en liste over alle de spørsmålene som skal stilles. Begge bedriftene får samme spørsmål å svare på, siden dette gjør det lettere å sammenligne svarene [9]. Først kontaktet jeg bedriftene for å avtale tidspunkt for intervjuet med IT-sjefen, så sendte jeg en til intervjuobjektene om hva dette går ut på slik at de kan forberede seg og eventuelt finne personalet som har kompetanse innenfor emnet. Det er viktig å finne generell info om bedriften og hvilket forhold intervjuobjektet har til systemtesting. Referat fra disse intervjuene ble sendt ut til intervjuobjektene for godkjennelse fra dem om at det som står der er riktig før jeg legger dem inn i prosjektrapporten min. I kapittel 6.1 og 6.2 er det en liten oppsummering fra disse to intervjuene, selve referatene har jeg lagt som vedlegg på slutten av denne rapporten. 18

Livsløpstesting av IT-systemer

Livslø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

Detaljer

Validering og verifisering. Kirsten Ribu

Validering 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

Detaljer

Akseptansetesten. Siste sjanse for godkjenning Etter Hans Schaefer

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

Detaljer

Statisk 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 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

Detaljer

Ulike typer prosessmodeller. Systemutvikling. Utviklingsmodeller. Prosessmodell - faser

Ulike typer prosessmodeller. Systemutvikling. Utviklingsmodeller. Prosessmodell - faser 1 Ulike typer prosessmodeller Systemutvikling Oppsummering av hovedområdene i kurset LO 135A Kirsten Ribu 19.05.2004 De røde er viktige i kurset: Evolusjonær (prototyping) Inkrementell (RUP) XP fossefall

Detaljer

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

Detaljer

Krav som bør stilles til leverandørens verifikasjon og test

Krav som bør stilles til leverandørens verifikasjon og test Krav som bør stilles til leverandørens verifikasjon og test Av Hans Schaefer Versjon 1.2, 14.9.2005 Dette dokument beskriver krav en bør stille til verifikasjon under utviklingen og test hos en seriøs

Detaljer

Testrapport Prosjekt nr. 2011-22 Det Norske Veritas

Testrapport 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

Detaljer

Use 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. 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,

Detaljer

UKEOPPGAVER 2: SYSTEMUTVIKLINGSPROSESSER OG PROSJEKTARBEID INNSPILL TIL SVAR

UKEOPPGAVER 2: SYSTEMUTVIKLINGSPROSESSER OG PROSJEKTARBEID INNSPILL TIL SVAR INF 1050 UKEOPPGAVER 2: SYSTEMUTVIKLINGSPROSESSER OG PROSJEKTARBEID INNSPILL TIL SVAR Oppgave 1 a) Foranalyse: Foranalysen kan med fordel gjøres i to trinn. Den første er å undersøke finansiering og øvrige

Detaljer

Grunnleggende testteori. Etter Hans Schaefer

Grunnleggende 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,

Detaljer

Lykke til! Eksamen i fag SIF8018 Systemutvikling. 20 mai, 2003 kl 0900-1400. Fakultet for fysikk, informatikk og matematikk

Lykke til! Eksamen i fag SIF8018 Systemutvikling. 20 mai, 2003 kl 0900-1400. Fakultet for fysikk, informatikk og matematikk NTNU Norges teknisk-naturvitenskapelige universitet BOKMÅL Fakultet for fysikk, informatikk og matematikk Institutt for datateknikk og informasjonsvitenskap Sensurfrist: XX Eksamen i fag SIF8018 Systemutvikling

Detaljer

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

Use case modellen. Use case modellering i analysefasen. Hva er en Aktør? Hva er et Use case? 1/15/2004 1 Use case modellen Use case modellering i analysefasen Metode for å identifisere og beskrive de funksjonelle kravene til et system Kapittel 3 i UML Distilled Kapittel 8 i Gurholt og Hasle Kirsten

Detaljer

ChiCMS Hovedprosjekt ved Høgskolen i Oslo 2011

ChiCMS Hovedprosjekt ved Høgskolen i Oslo 2011 TESTRAPPORT Forord Denne testrapporten har som formål å beskrive all testing som er utført på systemet, både under utviklingen og etter ferdigstilling. Målet for testingen er for å verifisere at vi har

Detaljer

ISTQB Foundation Level Prøveeksamen

ISTQB 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

Detaljer

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

Hensikten 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

Detaljer

Produktdokumentasjon. Madison Møbler Administrasjonsside og Nettbutikk

Produktdokumentasjon. Madison Møbler Administrasjonsside og Nettbutikk Produktdokumentasjon Madison Møbler Administrasjonsside og Nettbutikk 1 1. Forord 1.1 Dokumentasjonen Dette er en teknisk dokumentasjon på produktet som er utviklet. Denne er tiltenkt personer med teknisk

Detaljer

I dag UML. Domenemodell visualisering av konsepter. Eksempel. Hvordan finne domeneklasser?

I dag UML. Domenemodell visualisering av konsepter. Eksempel. Hvordan finne domeneklasser? UML Use case drevet analyse og design 31.01.2005 Kirsten Ribu I dag Domenemodell (forløper til klassediagram) Interaksjonsdiagrammer Sekvensdiagram Kollaborasjonsdiagram 1 2 Domenemodell visualisering

Detaljer

BlackBox, WhiteBox og andre testmetoder. Etter ønske fra studentene 26. november 2009

BlackBox, 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

Detaljer

Kravspesifikasjon. Forord

Kravspesifikasjon. Forord Kravspesifikasjon Forord Kravspesifikasjonen skal beskrive applikasjonens funksjonalitet og betingelsene som oppdragsgiver krever. Det skal også hjelpe utviklerne med å begrense applikasjonen slik at den

Detaljer

Testbilag til IT kontrakter

Testbilag til IT kontrakter Testbilag til IT kontrakter Grunner til å lage dette testbilaget Unngår å diskutere de samme problemstillingene i hver kontrakt testfaglige selvfølgeligheter blir landet av testfaglig personell en gang

Detaljer

System 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, 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

Detaljer

Oppsummering : IMT2243 Systemutvikling. Hensikt med kurset. Innfallsvinkel : Tom Røise 29.04.2009. IMT2243 : Systemutvikling 1

Oppsummering : IMT2243 Systemutvikling. Hensikt med kurset. Innfallsvinkel : Tom Røise 29.04.2009. IMT2243 : Systemutvikling 1 Oppsummering : IMT2243 Systemutvikling Målformuleringen i emnebeskrivelsens : Studentene skal ha forståelse for grunnleggende administrative og teknologiske aspekter ved spesifisering, utvikling, innføring

Detaljer

Kvalitet og programvare. Når bare det beste er godt nok. Produktet prosessen eller begge deler?

Kvalitet og programvare. Når bare det beste er godt nok. Produktet prosessen eller begge deler? Kvalitet og programvare Når bare det beste er godt nok. Produktet prosessen eller begge deler? To nøtter Hva forbinder du med et IT-system som har (høy) kvalitet? Formuler 3 kriterier for (høy) kvalitet

Detaljer

UML 1. Use case drevet analyse og design. 20.01.2004 Kirsten Ribu

UML 1. Use case drevet analyse og design. 20.01.2004 Kirsten Ribu UML 1 Use case drevet analyse og design 20.01.2004 Kirsten Ribu 1 I dag Domenemodell (forløper til klassediagram) Interaksjonsdiagrammer Sekvensdiagram Kollaborasjonsdiagram 2 Domenemodell visualisering

Detaljer

4.1. Kravspesifikasjon

4.1. Kravspesifikasjon 4.1. Kravspesifikasjon Dette delkapittelet beskriver nærgående alle deler av systemet, hvordan det er tenkt ferdigutviklet med fokus på oppdragsgivers ønsker. 4.1.1. Innledning Informasjon om hvordan kravspesifikasjonens

Detaljer

Modernisering av IKT i NAV

Modernisering 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

Detaljer

A tool for collaborating to success in a development project Experience with Visual Studio 2010 and Test Manager at Lånekasse

A tool for collaborating to success in a development project Experience with Visual Studio 2010 and Test Manager at Lånekasse A tool for collaborating to success in a development project Experience with Visual Studio 2010 and Manager at Lånekasse 21.mars.2013 Heza Wasfy Hvem er Sogeti? Sogeti Norge er et heleid datterselskap

Detaljer

Kvalitet i programvaresystemer Dokumentasjon av tester

Kvalitet i programvaresystemer Dokumentasjon av tester Kvalitet i programvaresystemer Dokumentasjon av tester Dette notatet handler om dokumentasjon av tester. Gjennom utforming og gjennomføring av tester søker man å avdekke så mange feil i et program som

Detaljer

UNIVERSITETET I OSLO

UNIVERSITETET 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:

Detaljer

Eksamen i fag TDT4140 Systemutvikling. 22. mai, 2008 kl 0900-1300

Eksamen i fag TDT4140 Systemutvikling. 22. mai, 2008 kl 0900-1300 Side 1 av 11 NTNU Norges teknisk-naturvitenskapelige universitet BOKMÅL Fakultet for fysikk, informatikk og matematikk Institutt for datateknikk og informasjonsvitenskap Sensurfrist: 15. juni, 2008 Eksamen

Detaljer

KRAVSPESIFIKASJON FOR SOSIORAMA

KRAVSPESIFIKASJON FOR SOSIORAMA KRAVSPESIFIKASJON FOR SOSIORAMA Innhold 1. Forord... 2 2. Definisjoner... 3 3. Innledning... 4 3.1 Bakgrunn og formål... 4 3.2 Målsetting og avgrensninger... 4 4. Detaljert beskrivelse... 8 4.1 Funksjonelle

Detaljer

PROSJEKTPLAN FOR INF [4 3]120-PROSJEKT: PROJECT HOSPITAL 2004

PROSJEKTPLAN FOR INF [4 3]120-PROSJEKT: PROJECT HOSPITAL 2004 PROSJEKTPLAN FOR INF [4 3]120-PROSJEKT: PROJECT HOSPITAL 2004 VERSJON: PROSJEKTPLAN (1.0) 24. SEPTEMBER, 2004 prosjektplan.doc GRUPPE 12 PROSJEKTPLAN: PROSJEKTLEDELSE: USE CASE: KVALITETSSIKRING: ANDRÉ

Detaljer

Oppgraderinger i SAP. Planlegge, organisere og gjennomføre en oppgradering til ECC 5.0/ECC 6.0. Sveinung Gehrken

Oppgraderinger i SAP. Planlegge, organisere og gjennomføre en oppgradering til ECC 5.0/ECC 6.0. Sveinung Gehrken Oppgraderinger i SAP Planlegge, organisere og gjennomføre en oppgradering til ECC 5.0/ECC 6.0. Sveinung Gehrken Gehrken Systems Agenda Vurdere 1 2 oppgradering 4 Erfaringer og hjelpemidler Planlegge oppgradering

Detaljer

Test i Praksis. NTNU Februar 2014. Copyright 2014 Accenture All Rights Reserved.

Test 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

Detaljer

Produktrapport Gruppe 9

Produktrapport Gruppe 9 Forord Dette dokumentet er ment for personer som skal vedlikeholde, endre eller utvikle systemet. Produktdokument innholder informasjoner om programmets funksjoner og hvordan de fungerer. Før bruk av dette

Detaljer

Eksamen 2012 INF1050 Lars- Martin Hejll Universitetet i OSLO

Eksamen 2012 INF1050 Lars- Martin Hejll Universitetet i OSLO Eksamen 2012 INF1050 Lars- Martin Hejll Universitetet i OSLO Høgskolen i Telemark 2 Lars- Martin Hejll Høgskolen I Telemark Oppgave 1 Spørsmål fra pensum (20%) 1. Nødvendige aktiviteter i systemutvikling:

Detaljer

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

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

Detaljer

Brukbarhet ved benyttelse av fri programvare i systemutvikling - en praktisk studie

Brukbarhet ved benyttelse av fri programvare i systemutvikling - en praktisk studie Brukbarhet ved benyttelse av fri programvare i systemutvikling - en praktisk studie Tarjei Eriksen Ormestøyl Anders Kløvrud Rognstad Master i datateknikk Oppgaven levert: Juni 2010 Hovedveileder: Dag Svanæs,

Detaljer

Krav. Beskriver tjenestene produktet skal håndtere Kravene kan testes

Krav. Beskriver tjenestene produktet skal håndtere Kravene kan testes Krav og terminologi Krav Et utsagn som gjelder produktet vi skal teste og evaluere. Vi skal vurdere graden av sannhet i kravet opp mot funksjonen i produktet Funksjonelle krav Beskriver tjenestene produktet

Detaljer

Forstudierapport. Magne Rodem og Jan-Erik Strøm. 18. juni 2006

Forstudierapport. Magne Rodem og Jan-Erik Strøm. 18. juni 2006 Forstudierapport Magne Rodem og Jan-Erik Strøm 18. juni 2006 Innhold 1 Introduksjon 3 2 Bakgrunn for prosjektet 3 2.1 Beskrivelse av problemer og behov........................... 3 2.2 Kort om dagens systemer................................

Detaljer

BRUKERMANUAL. Telsys Online Backup

BRUKERMANUAL. Telsys Online Backup BRUKERMANUAL Telsys Online Backup TELSYS AS - 06.08.2009 Innhold Generelt... 3 Kom i gang... 4 Installasjon av Telsys Online Backup Proff/Standard... 4 Start opp klienten for første gang!... 10 Logg inn...

Detaljer

Oppgave 1. Finn krav. Finn krav. Finn test

Oppgave 1. Finn krav. Finn krav. Finn test Oppgave 1 1. Hensikten med use case er å oppnå en felles forståelse av krav til systemet mellom brukere / kunder og utviklere. Et use case er et scenario, ikke en komplett, deltaljert kravspesifikasjon.

Detaljer

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

Detaljer

KTN1 - Design av forbindelsesorientert protokoll

KTN1 - Design av forbindelsesorientert protokoll KTN1 - Design av forbindelsesorientert protokoll Beskrivelse av A1 A1 skal tilby en pålitelig, forbindelsesorientert tjeneste over en upålitelig, forbindelsesløs tjeneste A2. Det er flere ting A1 må implementere

Detaljer

Testrapport for Sir Jerky Leap

Testrapport for Sir Jerky Leap Jasmine Garry (s135600) Line Sørensen (s135590) Fredrik Hoem Grelland (s135595) Tor Anders Gustavsen (s127668) 1 1. Forord Dette dokumentet inneholder informasjon og redegjøring av tester foretatt i forbindelse

Detaljer

Oppsummering : IMT2243 Systemutvikling. Hensikt med kurset. Innfallsvinkel : Tom Røise 30.04.2007. IMT2243 : Systemutvikling 1

Oppsummering : IMT2243 Systemutvikling. Hensikt med kurset. Innfallsvinkel : Tom Røise 30.04.2007. IMT2243 : Systemutvikling 1 Oppsummering : IMT2243 Systemutvikling Målformuleringen i emnebeskrivelsens : Studentene skal ha forståelse for grunnleggende administrative og teknologiske aspekter ved spesifisering, utvikling, innføring

Detaljer

Artist webside. Gruppe medlemmer Joakim Kartveit. Oppdragsgiver Tetriz Event & Management. Frode Mathiesen. Gry Anita Nilsen.

Artist webside. Gruppe medlemmer Joakim Kartveit. Oppdragsgiver Tetriz Event & Management. Frode Mathiesen. Gry Anita Nilsen. Artist webside Innhold Artist webside...1 Gruppe medlemmer...1 Oppdragsgiver...1 Kontaktperson...2 Veileder...2 Oppgaven...2 Muligheter...2 Sammendrag...2 Dagens situasjon...2 Mål og rammebetingelser...3

Detaljer

Prosjektet - leveranser. Testing og evaluering av systemer. Hva er sikkerhetskritiske systemer? I dag: Systemfeil og testing. Robust kraftforsyning?

Prosjektet - 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,

Detaljer

Presentasjon 1, Requirement engineering process

Presentasjon 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

Detaljer

Erfaring med funksjonell testing i en integrert ALM prosess

Erfaring 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

Detaljer

KRAVSPESIFIKASJON. Tittel: Pris++ Oppgave: Utvikle en Android applikasjon med tilhørende databasesystem. Periode: 1. Januar til 11. Juni.

KRAVSPESIFIKASJON. Tittel: Pris++ Oppgave: Utvikle en Android applikasjon med tilhørende databasesystem. Periode: 1. Januar til 11. Juni. KRAVSPESIFIKASJON Tittel: Pris++ Oppgave: Utvikle en Android applikasjon med tilhørende databasesystem. Periode: 1. Januar til 11. Juni. Prosjektgruppe: 27 Prosjektmedlem: Ole Almenning Stenhaug Veileder.

Detaljer

Vedlegg Brukertester INNHOLDFORTEGNELSE

Vedlegg Brukertester INNHOLDFORTEGNELSE Vedlegg Brukertester INNHOLDFORTEGNELSE Vedlegg Brukertester... 1 Testrapport Wireframe... 2 1. INTRODUKSJON... 2 1.1 Systemoversikt... 2 1.2 Meningen med testen... 2 2 TESTPLAN... 2 2.1 Funksjoner som

Detaljer

RETNINGSLINJER FOR SKRIVING AV SLUTTRAPPORT VED BACHELOROPPGAVE

RETNINGSLINJER FOR SKRIVING AV SLUTTRAPPORT VED BACHELOROPPGAVE RETNINGSLINJER FOR SKRIVING AV SLUTTRAPPORT VED BACHELOROPPGAVE Det gis ulike anbefalinger for hvordan en prosjektrapport skal se ut. Noen krav til innhold og utseende er beskrevet i forslaget nedenfor.

Detaljer

Kravspesifikasjon med UML use case modellering. Erik Arisholm 25.02.2009

Kravspesifikasjon med UML use case modellering. Erik Arisholm 25.02.2009 Kravspesifikasjon med UML use case modellering Erik Arisholm 25.02.2009 Unified Modeling Language (UML) Notasjon som støtter opp under modellbasert systemutvikling objektorientert analyse ( hva systemet

Detaljer

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

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

Detaljer

Agenda. TDT4140: Kravinnhenting. Kravprosessen Forståelsesproblemet Teknikker for innhenting av krav. Den organisatoriske dimensjonen

Agenda. TDT4140: Kravinnhenting. Kravprosessen Forståelsesproblemet Teknikker for innhenting av krav. Den organisatoriske dimensjonen TDT4140: Kravinnhenting Torbjørn Skramstad IDI / NTNU Introduksjon til objektorientert design Agenda Kravprosessen Forståelsesproblemet Teknikker for innhenting av krav Intervju Scenarier Etnografi Eksempel

Detaljer

Verifikasjon og validering

Verifikasjon og validering Verifikasjon og validering 19. oktober 2006 - INF3120 Nils Christian Haugen & Stein Grimstad Hvem er vi? Nils Christian Haugen Chief Scientist i Objectnet Utdannelse fra NTNU E-post: nch@objectnet.no Stein

Detaljer

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

Modellering av krav. INF1050: Systemutvikling 11. februar 2015. Universitetslektor Yngve Lindsjørn INF1050: Systemutvikling 11. februar 2015 Modellering av krav Universitetslektor Yngve Lindsjørn INF1050 ->Systemutvikling-> Modellering av krav / Yngve Lindsjørn 1 Temaer i dagens forelesning Modellering

Detaljer

24.01.2014 Hovedprosjekt i Informasjonsteknologi ved Høgskolen i Oslo og Akershus. Forprosjektrapport. Presentasjon

24.01.2014 Hovedprosjekt i Informasjonsteknologi ved Høgskolen i Oslo og Akershus. Forprosjektrapport. Presentasjon 24.01.2014 Hovedprosjekt i Informasjonsteknologi ved Høgskolen i Oslo og Akershus Forprosjektrapport Presentasjon Tittel Precision Teaching App for Android Oppgave Å lage en Android app som skal benyttes

Detaljer

Oppgave 1 Multiple Choice

Oppgave 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

Detaljer

Kandidat nr. 1, 2 og 3

Kandidat nr. 1, 2 og 3 Kandidat nr. 1, 2 og 3 Rapport 1 IT202E Bacheloroppgave i Informatikk Vår 2011 Mobilapplikasjonsutvikling med Scrum 1 Innhold Innledning... 3 Overordnet Prosjektplan... 3 Produktbacklog... 5 Sprint planning

Detaljer

Saksnummer 13/00203 1 / 29

Saksnummer 13/00203 1 / 29 Bilag 6 Vedlegg 6 7 Vedlegg - Kundens teststrategi 7 - Kundens teststrategi Saksnummer 13/00203 1 / 29 Versjonshåndtering Versjon Dato Initiert av Endringsårsak 1.0 16.05.2013 Difi Dokument distribuert

Detaljer

UNIVERSITETET I OSLO

UNIVERSITETET I OSLO UNIVERSITETET I OSLO Det matematisk-naturvitenskapelige fakultet Eksamen i: INF1050 Eksamensdag: 2. juni 2014 Tid for eksamen: 09:00-13:00 Oppgavesettet er på 4 sider Vedlegg: Ingen Tillatte hjelpemidler:

Detaljer

Innhold. Innledning... 15. Del 1 En vei mot målet

Innhold. Innledning... 15. Del 1 En vei mot målet Innledning.............................................. 15 Del 1 En vei mot målet Kapittel 1 Utviklingsarbeidet.............................. 22 1.1 Systemutviklerens arbeid...............................

Detaljer

Kontrakter 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 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

Detaljer

Hovedprosjekt 2014, Høgskolen i Oslo og Akershus

Hovedprosjekt 2014, Høgskolen i Oslo og Akershus Forprosjektrapport Gruppe 2 Hovedprosjekt 2014, Høgskolen i Oslo og Akershus 1 INNHOLD 2 Presentasjon... 2 2.1 Gruppen medlemmer... 2 2.2 Oppgave... 2 2.3 Oppdragsgiver... 2 2.4 Veileder... 2 3 Sammendrag...

Detaljer

Kravspesifikasjon. Android app for aktivering av jakt- og fiskekort. Bacheloroppgave vår 2014. Høgskolen i Oslo og Akershus. Charlotte Sjøthun s180495

Kravspesifikasjon. Android app for aktivering av jakt- og fiskekort. Bacheloroppgave vår 2014. Høgskolen i Oslo og Akershus. Charlotte Sjøthun s180495 Charlotte Sjøthun s180495 Nanna Mjørud s180477 Anette Molund s181083 Kravspesifikasjon Android app for aktivering av jakt- og fiskekort Bacheloroppgave vår 2014 Høgskolen i Oslo og Akershus Forord Hensikten

Detaljer

TESTRAPPORT... 91 FORORD... 91 INNHOLD... 92 23 INNLEDNING... 93 24 TEST AV SYSTEMET... 93. 24.1 Databasen og SQL spørringer... 93

TESTRAPPORT... 91 FORORD... 91 INNHOLD... 92 23 INNLEDNING... 93 24 TEST AV SYSTEMET... 93. 24.1 Databasen og SQL spørringer... 93 90 Testrapport Forord Dette dokumentet er testrapporten for hovedprosjektet, og skal gi en oversikt over all testing utført på systemet under og etter ferdigstilling, samt feil og løsninger gruppen har

Detaljer

Innholdsfortegnelse: Resymé: Denne leksjon gir en kort og enkelt oversikt over hvilke oppgaver som skal utføres i design- og programmeringsfasen.

Innholdsfortegnelse: Resymé: Denne leksjon gir en kort og enkelt oversikt over hvilke oppgaver som skal utføres i design- og programmeringsfasen. Kort innføring i design og programmeringsfasen Jarle Larsen/Tore Berg Hansen 2.11.04 Opphavsrett: Forfatter og Stiftelsen TISIP Lærestoffet er utviklet for faget LO314 Prosjektrettet systemarbeid Resymé:

Detaljer

Kom i gang. Nå er det enklere en noensinne å redigere hjemmesiden din med Plone CMS. 17. mars 2010

Kom i gang. Nå er det enklere en noensinne å redigere hjemmesiden din med Plone CMS. 17. mars 2010 Kom i gang Nå er det enklere en noensinne å redigere hjemmesiden din med Plone CMS. 17. mars 2010 Innholdsfortegnelse Introduksjon til Bedrift Online 4 Web-basert publiseringsverktøy 4 Hva du trenger 4

Detaljer

JigZaw. Teststategi utviklet av. Erik Drolshammer Bård Lind. Verifiser Forventet Funksjonalitet

JigZaw. Teststategi utviklet av. Erik Drolshammer Bård Lind. Verifiser Forventet Funksjonalitet JigZaw Verifiser Forventet Funksjonalitet Teststategi utviklet av Erik Drolshammer Bård Lind Bård Lind Java siden 1997 Arkitekt siden 2000 JavaBin siden 1999 Enterprise Domain Repository og JigZaw-teststrategi

Detaljer

Kunden er en av Norges ledende leverandører av digital-tv og bredbåndstjenester.

Kunden 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

Detaljer

Vedlegg Side 83 av 155

Vedlegg Side 83 av 155 4 Side 83 av 155 Innholdsfortegnelse 1 Kravspesifikasjon... 86 2 Kravspesifikasjon 2.0... 92 3 Domenemodell... 98 4 UseCase Diagram Oversikt... 102 6 Detaljert beskrivelse av UseCase Diagram... 106 Webapplikasjon...

Detaljer

Mellom barken og veden Smidig testing i krevende terreng TTC 2015

Mellom 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

Detaljer

Ansvarsdrevet OO: CRC og UML Sekvensdiagrammer

Ansvarsdrevet OO: CRC og UML Sekvensdiagrammer Fra krav til objekter Ansvarsdrevet OO: CRC og UML Sekvensdiagrammer INF1050--1 Dagens forelesning o Kort repetisjon av kravspesifikasjon med UML Hva skal systemet gjøre? UML: Bruksmønstermodeller (Use

Detaljer

Løsningsforslag til Case. (Analysen)

Løsningsforslag til Case. (Analysen) Løsningsforslag til Case (Analysen) Dette er en skisse til løsning av Case et med bussinformasjonssystemet. Jeg kaller det en skisse fordi det på den ene siden ikke er noe fasitsvar og fordi løsningen

Detaljer

Debugging. Tore Berg Hansen, TISIP

Debugging. Tore Berg Hansen, TISIP Debugging Tore Berg Hansen, TISIP Innhold Innledning... 1 Å kompilere og bygge et program for debugging... 1 Når debugger er i gang... 2 Symbolene i verktøylinjen... 3 Start på nytt... 3 Stopp debugging...

Detaljer

Spesifikasjon av Lag emne

Spesifikasjon av Lag emne Dagens forelesning o Kort repetisjon av kravspesifikasjon med UML Fra krav til objekter Hva skal systemet gjøre? UML: Bruksmønstermodeller (Use Cases) o Objektdesign Ansvarsdrevet OO: CRC og UML Sekvensdiagrammer

Detaljer

En kravspesifikasjon skal være så konkret og detaljert at det er mulig å teste det ferdige produkt/system opp mot store deler av denne.

En kravspesifikasjon skal være så konkret og detaljert at det er mulig å teste det ferdige produkt/system opp mot store deler av denne. A KRAVSPESIFIKASJON Dette notat er en generell beskrivelse av en kravspesifikasjon for et (teknisk) datasystem. Den er basert på «The STARTS Purchasers Handbook» kap.4 og Appendix B, oversatt til norsk

Detaljer

Why Desperate Houswives make Excellent Test Managers Testprosjektet som suksessfaktor i et hvert prosjekt

Why Desperate Houswives make Excellent Test Managers Testprosjektet som suksessfaktor i et hvert prosjekt Why Desperate Houswives make Excellent Managers prosjektet som suksessfaktor i et hvert prosjekt dagen ODIN 21.November 2012 Hvem er jeg Astrid Notø Larsen Cand Scient i Informatikk fra UiO 15 års erfaring

Detaljer

Dokument 1 - Sammendrag

Dokument 1 - Sammendrag Dokument 1 - Sammendrag Automatnett - Nytt CMS-verktøy for Uno-X Automat Fakultet for teknologi, kunst og design Høgskolen i Oslo og Akershus, 2013 Innholdsfortegnelse Sammendrag 1 1. Innledning 1 2. Om

Detaljer

Erlend Oftedal. Risiko og sikkerhet i IKT-systemer, Tekna

Erlend Oftedal. Risiko og sikkerhet i IKT-systemer, Tekna Sikkerhet i Web 2.0 Erlend Oftedal Risiko og sikkerhet i IKT-systemer, Tekna Hva er spesielt med Web 2.0? Innhold fra flere kilder Sosiale nettsteder med brukergenerert innhold Mashups gjerne med innhold

Detaljer

Effektiv testing. Per Otto Bergum Christensen. 9.-10. September, JavaZone. Bergum Christensen Consulting

Effektiv testing. Per Otto Bergum Christensen. 9.-10. September, JavaZone. Bergum Christensen Consulting Effektiv testing Per Otto Bergum Christensen 9.-10. September, JavaZone Bergum Christensen Consulting Om meg Per Otto Bergum Christensen (33) Siv.ing, Datateknikk, NTNU Jobbet med utviklingsprosjekter

Detaljer

K O N S U L E N T - I D : 2 5 2 2 C U R R I C U L U M V I T A E

K O N S U L E N T - I D : 2 5 2 2 C U R R I C U L U M V I T A E K O N S U L E N T - I D : 2 5 2 2 C U R R I C U L U M V I T A E Utdannelse 1996-1998 2 årig Informatikk ved Høyskolen i Østfold 1994-1996 2 årig Økonomi og Administrasjon ved Høyskolen i Østfold Sertifiseringer

Detaljer

Technical Integration Architecture Teknisk integrasjonsarkitektur

Technical Integration Architecture Teknisk integrasjonsarkitektur Kap. 6 Technical Integration Architecture Studentpresentasjon av Cato Haukeland Oversikt Introduksjon -spesifikasjon Krav Beskrivelse Servicenivå Sikkerhet Plan Best practices Introduksjon Masterdokument

Detaljer

INF1500 Høst 2015 Magnus Li Martine Rolid Leonardsen. Utviklingsprosesser & krav og behov

INF1500 Høst 2015 Magnus Li Martine Rolid Leonardsen. Utviklingsprosesser & krav og behov INF1500 Høst 2015 Magnus Li Martine Rolid Leonardsen Utviklingsprosesser & krav og behov I DAG GENERELT - Generell informasjon - Et par eksempler på dårlig utforming UTVIKLINGSPROSESSER - Fire tilnærminger

Detaljer

INF 5120 Obligatorisk oppgave Nr 2

INF 5120 Obligatorisk oppgave Nr 2 INF 5120 Obligatorisk oppgave Nr 2 Vigdis Bye Kampenes Stein Grimstad Gruppe 26 INF 5120 Obligatorisk oppgave Nr 2... 1 1 Business model... 2 Innledende kommentarer... 2 Andre avgrensninger... 2 Scoping

Detaljer

Eksamen i fag TDT4140 Systemutvikling. 6. juni, 2006 kl 0900-1300

Eksamen i fag TDT4140 Systemutvikling. 6. juni, 2006 kl 0900-1300 Side 1 av 10 NTNU Norges teknisk-naturvitenskapelige universitet BOKMÅL Fakultet for fysikk, informatikk og matematikk Institutt for datateknikk og informasjonsvitenskap Sensurfrist: 27. juni, 2006 Eksamen

Detaljer

Akseptansetest av mottak Rekvirering av medisinske tjenester Medisinsk biokjemi

Akseptansetest av mottak Rekvirering av medisinske tjenester Medisinsk biokjemi Akseptansetest av mottak Rekvirering av medisinske tjenester Meldingsversjon: versjon 1.4, datert 20.05.2005 2 Akseptansetest av mottak Rekvirering av medisinske tjenester Innholdsfortegnelse 1. Revisjonshistorikk...

Detaljer

1. Forord 2. Leserveiledning

1. Forord 2. Leserveiledning KRAVSPESIFIKASJON 1 1. Forord Hensikten med kravspesifikasjonen er at den skal fungere som et styringsdokument under prosessen og definere rammer og betingelser rundt hovedprosjektet. Den er utviklet etter

Detaljer

Testplan PROSJEKT. Signal Communication Unit OPPDRAGSGIVER. Kongsberg Maritime AS UTFØRT VED. Høgskolen i Buskerud og Vestfold, avd.

Testplan PROSJEKT. Signal Communication Unit OPPDRAGSGIVER. Kongsberg Maritime AS UTFØRT VED. Høgskolen i Buskerud og Vestfold, avd. Testplan PROSJEKT Signal Communication Unit OPPDRAGSGIVER Kongsberg Maritime AS UTFØRT VED Høgskolen i Buskerud og Vestfold, avd. Kongsberg MEDLEMMER Marius Johanssen, Stefan Dasic, Eivind Nielsen, Armaan

Detaljer

DRI2001 / FINF september Utvikling av en offentlig nettjeneste: MinSide. 21. september 2006 Marius Pellerud 1

DRI2001 / FINF september Utvikling av en offentlig nettjeneste: MinSide. 21. september 2006 Marius Pellerud 1 DRI2001 / FINF4001 21. september 2006 Utvikling av en offentlig nettjeneste: MinSide 21. september 2006 Marius Pellerud 1 1 Tema i forelesningen Hva skal MinSide bli? Faser i prosjektet Eksempel på strategi

Detaljer

Oblig 5 Webutvikling. Av Thomas Gitlevaag

Oblig 5 Webutvikling. Av Thomas Gitlevaag Oblig 5 Webutvikling Av Thomas Gitlevaag For oppgave 1 og 2 skal dere levere en funksjonell webside på deres hjemmeområde. Dere skal også levere alle phps-filene slik at man for en hver side kan slenge

Detaljer

AP221 Use Case - TUL - Utarbeid prosessflytmal og komponenter

AP221 Use Case - TUL - Utarbeid prosessflytmal og komponenter AP221 Use Case - TUL - Utarbeid komponenter Utarbeid komponenter En tjeneste i Sluttbrukerløsningen har en arbeidsflyt som bestemmer de forskjellige stegene som må gjennomføres i skjemainnsendingen. Disse

Detaljer

Bachelorprosjekt 2015

Bachelorprosjekt 2015 Bachelorprosjekt 2015 Høgskolen i Oslo og Akershus Tam Ha (s171513) Arslan Yousaf (s189135) Gabriel Noraker Alfarrustad (s161910) Eivind Lund (s180381) Phillip Padiernos Næss (s162951) Forprosjekt Prosjektets

Detaljer

Kvalitetskrav til løsninger

Kvalitetskrav til løsninger Prosjektoppgaven Kvalitetskrav til løsninger Noen retningslinjer for å styre beslutningene deres finnes i form av hva brukere forlanger av software (og hardware): Brukbarhet. - Produktet skal være selvforklarende

Detaljer

STE6221 Sanntidssystemer Løsningsforslag

STE6221 Sanntidssystemer Løsningsforslag HØGSKOLEN I NARVIK Avdeling for teknologi MSc.-studiet EL/RT Side 1 av 3 STE6221 Sanntidssystemer Løsningsforslag Tid: Fredag 02.03.2007, kl: 09:00-12:00 Tillatte hjelpemidler: Godkjent programmerbar kalkulator,

Detaljer