Systemutviklingen er ferdig når et system er operativt. Med operativt menes når systemet blir brukt av brukerne på et faktisk arbeidssted.

Størrelse: px
Begynne med side:

Download "Systemutviklingen er ferdig når et system er operativt. Med operativt menes når systemet blir brukt av brukerne på et faktisk arbeidssted."

Transkript

1 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 når et system er operativt Alt arbeid som utføres på et system etter at det har blitt operativt, regnes som vedlikehold Software vedlikehold kan ikke betraktes på samme måte som hardware vedlikehold Systemutviklingen er ferdig når et system er operativt. Med operativt menes når systemet blir brukt av brukerne på et faktisk arbeidssted. Alt arbeid som utføres på et system etter at det har blitt operativt, regnes som vedlikehold. Software vedlikehold kan ikke betraktes på samme måte som hardware vedlikehold. Av den enkle grunn at HW vedlikehold stort sett består av å reparere eller skifte ut deler, mens dette ikke er tilfelle med SW vedlikehold. (Husk at funksjonen tostring() må skiftes ut etter å ha blitt brukt ganger ;-)) SW er i mye større grad bygget for å kunne forandres.

2 Slide 3 The changing system and the nature of maintenance Ulike systemer S-system P-system E-system Alle systemer, unntagen de som er veldig små, kommer til å forandre seg gjennom sitt livsløp. Helt generelt kan vi beskrive et system etter hvordan det er relatert til miljøet som omgir systemet. Jo mer avhengig et system er av den virkelige verden (real world) for sine krav, jo sikrere er det at systemet vil forandre seg.

3 Slide 4 The changing system and the nature of maintenance S-system Problemet er helt definert Det er en eller flere løsninger til problemet. Utvikler er ikke bekymret for riktigheten av løsningen, men med riktigheten av implementasjonen av løsningen. Real Wold Problem Requirements specification System Information Comparison Subject to change Noen systemer er formelt definert av spesifikasjoner. Problemet i disse systemene er helt definert og det er en eller flere løsninger på problemet. Løsningen er vel kjent, slik at utvikler ikke er opptatt med riktigheten av løsningen, men med riktigheten av implementasjonen av løsningen, og løsningens presisjon. Figuren viser problemet løst av et S-system som er relatert til den virkelige verden, og at den virkelige verden kan forandres. Hvis den virkelige verden forandres, er resultatet er helt nytt problem som må spesifiseres. Regneeksempel

4 Slide 5 The changing system and the nature of maintenance P-system Beskriver et problem på en abstrakt måte Systemets kravspesifikasjon blir skrevet ut fra vårt abstrakte synspunkt Mer basert på praktisk abstraksjon enn på en komplett og definert spesifikasjon Mer dynamisk enn et S-system Real Wold Problem Abstraction Requirements specification System Information Comparison Subject to change Det er ikke alltid lett eller mulig å beskrive et virkelig-verden problem fullstendig. I mange tilfeller eksisterer den teoretiske løsningen til et problem, men implementeringen av løsningen er upraktisk eller umulig. Sjakkeksempel Et P-system baserer seg mer på praktisk abstraksjon av problemet enn på en komplett definert spesifikasjon. Figuren forteller at P-systemet er mer dynamisk enn S-systemet. Løsningen produserer informasjon som blir sammenlignet med problemet. Hvis det da viser seg at informasjonen er dårlig egnet på noen som helst måte kan problemabstraksjonen bli forandret og kravene modifisert for å prøve å lage løsningen mer realistisk.

5 Slide 6 The changing system and the nature of maintenance E-system Systemet er integrert i den virkelige verden Forandrer seg når verden gjør det Problemet ikke fullt spesifisert Løsningen er basert på en modell av de abstrakte prosessene som er involvert Real World Problem Abstraction Requirements specification System Information Comparison Subject to change Et E-system er integrert (embedded) i den virkelige verden og forandrer seg når verden gjør det. Problemet kan ikke spesifiseres fullt ut. (Eksempel: forutse en nasjons helseutvikling) Løsningen er basert på en modell av de abstrakte prosessene som er involvert. Figuren illustrerer forandringsmulighetene til et E-system og systemets avhengighet av dens virkelige verden. Suksessen til et E-system er helt avhengig av kundens evaluering av systemets oppførsel (performance). Fordi problemet et E-system tar for seg ikke fullt ut kan spesifiseres må systemet bli vurdert kun etter sin oppførsel under virkelige kjøreforhold (actual operating conditions)

6 Slide 7 The changing system and the nature of maintenance SW vedlikehold Trenger all SW vedlikehold? Behov for vedlikehold kan sees i lys av systemets kategori Vedlikeholdsfase = videreutviklingsfase Vedlikeholdsfasen til et system kan være lengre enn utviklingsfasen av systemet Hele tiden vurdere om det lønner seg å videreutvikle et system, eller erstatte det med et nytt Lehmans Law of Software Evolution Trenger all SW vedlikehold? JA, knapt noe system unngår å bli forandret Behov for vedlikehold kan sees i lys av systemets kategori S-system: Lite utsatt for forandringer P-system: Høyst sannsynlig utsatt for forandringer E-system: Garantert forandringer Vedlikeholdsfase = videreutviklingsfase Vedlikeholdsfasen til et system kan være lengre enn utviklingsfasen av systemet. Har økt med årene, nå brukes opp til 80 % av arbeidsinnsatsen i vedlikeholdsfasen. Hele tiden vurdere om det lønner seg å videreutvikle et system, eller erstatte det med et nytt Lehmans Law of Software Evolution For de spesielt interesserte, står i læreboka kap. 11.1

7 Slide 8 Når vi utvikler et system er vår hovedfokus på å produsere kode som implementerer kravene og som fungerer korrekt. På hvert steg i utviklingen, refererer utviklingsteamet konstant til arbeid som er produsert tidligere i utviklingen. De sjekker for eksempel at designkomponentene er knyttet opp til kravspesifikasjonen og de har tester som sjekker at funksjoner virker i henhold til krav og design. Når vi snakker om vedlikehold er det litt annerledes. Vedlikeholdsteamet ser tilbake på utviklingsprodukter, samtidig som de er også opptatt av å etablere et samarbeid med brukerne og systemansvarlig for å finne ut hvor fornøyde de er med systemet. Vedlikeholdsteamet ser også framover for å prøve å finne feil før de oppstår, for å tenke over funksjonelle forandringer som kreves hvis bedriften forandres eller for å se på systemforandringer som kan være nødvendige hvis HW, SW eller interfacet forandres.

8 Slide 9 Aktivitetene rundt vedlikehold er nokså like aktivitetene til utvikling. De skal analysere krav, evaluerer systemet og programdesign. Skrive og se igjennom kode, teste forandringer og oppdatere dokumentasjonen. Vi kan fastslå at de som utfører vedlikeholdet, analytikere, programmere og designere, har samme roller. Men fordi endringer ofte krever en intim kunnskap til kodestrukturen og innhold, vil programmerere spille en større rolle i vedlikehold enn de gjorde i utviklingen.

9 Slide 10 Fokuserer på fire store aspekter ved systemets utvikling - Opprettholde kontrollen over systemets dag-til-dag funksjoner - Opprettholde kontrollen over systemets modifikasjoner - Perfeksjonere eksisterende akseptable funksjoner - Forhindre at systemets ytelse går under akseptabelt nivå

10 slide 11 Corrective Maintenance (korrigerende vedlikehold) For å kontrollere dag-til-dag funksjoner, vil vedlikeholdstemaet reagere på problemer som har oppstått på grunn av feil. Når feil inntreffer vil vedlikeholdsteamet få beskjed; de finner grunnen til feilen og gjør korreksjonene og forandrer kravene, designet, koden, test pakkene og dokumentasjonen. Ofte så blir problemet bare løst midlertidig slik at systemet kan fortsatt kjøre. Adaptive Maintenance (tilretteleggende vedlikehold) Det er slik at noen ganger kan en forandring i en del av systemet kreve at andre deler av systemet også forandres. Adaptive maintenance kan også benyttes ved forandringer i hardware og i miljøet. Hvis for eksempel et system opprinnelig var designet for et tørt, stabilt miljø, og skal flyttes over til en ubåt, må systemet blant annet tilpasse seg magnetisme og fuktighet.

11 Perfective Maintenance (utviklende vedlikehold) Involverer forandringer for å forbedre visse aspekter ved systemet, selv når forandringene ikke har kommet på grunn av feil. Når vi vedlikeholder et system, undersøker vi dokumentasjon, design og kode for å sjekke om noe kan gjøres bedre og mer tydeligere. Forandringer i dokumentasjon for å klare opp i poster, testpakker forandres for å forbedre test dekningen og kode og design modifiseres for å bedre lesbarheten er alle eksempler på perfective maintenace.

12 Slide 12 Preventive Maintenance (forebyggende vedlikehold) Denne metoden for vedlikehold oppstår når programmerer eller kodeanalytikere finner en feil eller en potensiell feil som ennå ikke har blitt til en feil i systemet. Retter feilen får den oppstår. Who Performs Maintenance (hvem utfører vedlikehold) Som regel er det ikke utviklingsteamet som også vedlikeholder systemet. Det er vanlig at en bedrift ansetter egne vedlikeholdsteam som skal sørge for at systemet fungerer korrekt. Det er positive og negative sider ved å la utviklingsteamet også vedlikeholde systemt: Positivt: De som har laget systemet kjenner systemet godt. De kjenner koden, designet, og filosofien bak systemet. Hvis de som utviklet systemet vet at de også skal vedlikeholde systemet, vil de bygge/designe systemet slik at vedlikehold vil være lettere. Negativt De forstår selv hva de mener slik at de ikke holder dokumentasjon oppdatert. Vanskelig å være objektiv når du selv har laget systemet.

13 Team Responsibility (ansvaret til vedlikeholdsteamet) Å vedlikehold et system krever at alle medlemmer i vedlikeholdsteamet er aktive. Det er vanlig at brukere, systemansvarlige kunder kontakter vedlikeholdsteamet med kommentarer og spørsmål. Deretter må analytikerne og programmererne finne ut hvilke deler av koden som berørt, hva som må gjøres med designet og hvor mye resurser (tid og innsats) som er nødvendig for å gjennomføre endringene.

14 Slide 13 Use of Maintenance Time (bruken av tiden ved vedlikehold) Perfective 50 % Adaptive 25% Corrective 21 % Preventive 4 %

15 Slide 14 Spørsmål

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

Kravhåndtering. INF1050: Gjennomgang, uke 03

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

Detaljer

Grunnleggende testteori

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

Detaljer

Grunnleggende testteori

Grunnleggende 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

Detaljer

Visma EasyCruit. Et kort innblikk i den siste produktutviklingen. August Norsk

Visma EasyCruit. Et kort innblikk i den siste produktutviklingen. August Norsk Visma EasyCruit Et kort innblikk i den siste produktutviklingen August 2019 - Norsk Innhold Innhold 2 Hva har vi jobbet med? 3 Forbedringer av den nye kandidathåndteringen 3 Video søknader - tips and tricks

Detaljer

GJENNOMGANG UKESOPPGAVER 9 TESTING

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

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

GJENNOMGANG UKESOPPGAVER 2 PROSESSMODELLER OG SMIDIG PROGRAMVAREUTVIKLIG

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

Detaljer

GJENNOMGANG UKESOPPGAVER 3 KRAVHÅNDTERING

GJENNOMGANG 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

Detaljer

Characteristics of a good design

Characteristics 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

Detaljer

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

Detaljer

Model Driven Architecture (MDA) Interpretasjon og kritikk

Model Driven Architecture (MDA) Interpretasjon og kritikk Model Driven Architecture (MDA) Interpretasjon og kritikk Ragnhild Kobro Runde (Ifi, UiO) Veileder: Ketil Stølen (Ifi/SINTEF) Stuntlunsj SINTEF Oversikt Bakgrunn/utgangspunkt for presentasjonen MDA stuntlunsj

Detaljer

Nye krav i ISO 9001, hvilke er de og hvordan implementere disse i TQM? Ragna Karoline Aasen

Nye krav i ISO 9001, hvilke er de og hvordan implementere disse i TQM? Ragna Karoline Aasen Nye krav i ISO 9001, hvilke er de og hvordan implementere disse i TQM? Ragna Karoline Aasen IMPLEMENTERINGSPLAN September 2015 ISO 9001:2015 publiseres Høst 2015 Akkreditering av sertifiseringsorganene

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

Gruppenavn. Prosjektnavn Beskrivelse av design For Navn på systemet. Versjon <1.0>

Gruppenavn. Prosjektnavn Beskrivelse av design For Navn på systemet. Versjon <1.0> Gruppenavn Prosjektnavn Beskrivelse av design For Navn på systemet Versjon Revisjonshistorie Dato Versjon Beskrivelse av endring Forfatter Innhold 1. Innledning

Detaljer

Presentasjon av hovedprosjekt ved HIST Nettbutikk www.midt-svartdal.no

Presentasjon av hovedprosjekt ved HIST Nettbutikk www.midt-svartdal.no Presentasjon av hovedprosjekt ved HIST Nettbutikk www.midt-svartdal.no Hovedprosjekt 2008 av Audun M. Solheim, student HIST/BAIN, audun@c2i.net Oppdragsgiver:Bjørg Minnesjord Solheim, bjorg@midt-svartdal.no

Detaljer

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

Tittel Objektorientert systemutvikling 2

Tittel Objektorientert systemutvikling 2 EKSAMENSFORSIDE Fagnr. OBJ208 Tittel Objektorientert systemutvikling 2 Ansvarlig faglærer Viggo Holmstedt Klasse(r) Dato IS/IN 2 11.06.2009 Eksamensoppgaven Ant. sider inkl. består av følgende: forside

Detaljer

Tom Røise 9. Februar 2010

Tom Røise 9. Februar 2010 Forelesning IMT2243 9. Februar 2010 Tema : Kravspesifisering : prosessen og produktet Viewpoint en myk tilnærming Pensum : Kap. 6 og 7 i Sommerville, Kravspesifisering Kravspesifisering = arbeidet med

Detaljer

Rettslige krav til styring av informasjonssikkerhet. Karin Kristiansen og Amund Eriksen

Rettslige krav til styring av informasjonssikkerhet. Karin Kristiansen og Amund Eriksen Rettslige krav til styring av informasjonssikkerhet Karin Kristiansen og Amund Eriksen Hva får dere IKKE? Informasjonssikkerhet? Informasjonssikkerhet dreier seg om å håndtere risiko relatert til virksomhetens

Detaljer

Jernbaneverkets erfaringer med implementering av RAMS

Jernbaneverkets erfaringer med implementering av RAMS Jernbaneverkets erfaringer med implementering av RAMS Terje Sivertsen, seksjonsleder signal Infrastruktur Teknikk, Premiss og utvikling Jernbaneverket RAMS-seminar, NJS, Oslo, 18. april 2007 1 Innhold

Detaljer

Løsningsforslag: Oblig 1. INF1050: Gjennomgang, uke 12

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

Detaljer

Drosjesentralen. I-120: Obligatorisk oppgave 2, 2000

Drosjesentralen. I-120: Obligatorisk oppgave 2, 2000 Drosjesentralen I-120: Obligatorisk oppgave 2, 2000 Frist Mandag 20. November 2000 kl.10:00, i skuff merket I120 på UA. Krav Se seksjon 4 for kravene til innlevering. Merk krav om generisk løsning for

Detaljer

Test of English as a Foreign Language (TOEFL)

Test of English as a Foreign Language (TOEFL) Test of English as a Foreign Language (TOEFL) TOEFL er en standardisert test som måler hvor godt du kan bruke og forstå engelsk på universitets- og høyskolenivå. Hvor godt må du snake engelsk? TOEFL-testen

Detaljer

Kan micro:biten vår brukes som en terning? Ja, det er faktisk ganske enkelt!

Kan micro:biten vår brukes som en terning? Ja, det er faktisk ganske enkelt! Microbit PXT: Terning Skrevet av: Geir Arne Hjelle Kurs: Microbit Språk: Norsk bokmål Introduksjon Kan micro:biten vår brukes som en terning? Ja, det er faktisk ganske enkelt! Steg 1: Vi rister løs Vi

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

Kap 11 Planlegging og dokumentasjon s 310

Kap 11 Planlegging og dokumentasjon s 310 Kap 11 Planlegging og dokumentasjon s 310 11.1 Ulike arbeidsmetoder Systemutvikling Som systemutvikler er du i stand til å omsette din innsikt i brukerbehov til praktiske programbaserte løsninger. Samarbeid:

Detaljer

DRI 2001 Systemutviklingsarbeidet et overblikk Forelesning

DRI 2001 Systemutviklingsarbeidet et overblikk Forelesning Systemutviklingsarbeidet et overblikk DRI2001 forelesning 12. sept. 06 Forholdet mellom informasjonssystemet og virkeligheten Hva innebærer utvikling av et IS (systemutvikling: SU) Å utvikle et IS det

Detaljer

Lykke til! Eksamen i fag TDT4140 Systemutvikling 28.11.2012 9.00. NTNU Norges teknisk-naturvitenskapelige universitet

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

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

Forord av Anne Davies

Forord av Anne Davies Forord av Anne Davies Anne Davies (ph.d.) er en canadisk forfatter, lærer, konsulent og forsker som har bred erfaring med kompetanseutvikling for lærere, skoleledere og kommuner både i Canada og USA. Hennes

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

STE6221 Sanntidssystemer Løsningsforslag kontinuasjonseksamen

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

Detaljer

DRI2001 Offentlige nettsteder. Litt om systemutvikling Torsdag 24 aug Arild Jansen, AFIN, UiO

DRI2001 Offentlige nettsteder. Litt om systemutvikling Torsdag 24 aug Arild Jansen, AFIN, UiO DRI 2001 13.9 : Introduksjon til systemutvikling. Introduksjon til systemutvikling Systemutvikling og nettstedsutvikling Om ulike typer offentlige nettsteder Kvalitetskrav til offentlige nettsteder Litt

Detaljer

Hvor mye praktisk kunnskap har du tilegnet deg på dette emnet? (1 = ingen, 5 = mye)

Hvor mye praktisk kunnskap har du tilegnet deg på dette emnet? (1 = ingen, 5 = mye) INF102 Er du? Er du? - Annet Hvor mye teoretisk kunnskap har du tilegnet deg på dette emnet? (1 = ingen, 5 = mye) Hvor mye praktisk kunnskap har du tilegnet deg på dette emnet? (1 = ingen, 5 = mye) Hvor

Detaljer

Konfigurasjonsstyring. INF1050: Gjennomgang, uke 11

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

Detaljer

Læringsmål og pensum. Utvikling av informasjonssystemer. Oversikt. Systemutvikling Systemutvikling i seks faser Femstegs prosedyre for programmering

Læringsmål og pensum. Utvikling av informasjonssystemer. Oversikt. Systemutvikling Systemutvikling i seks faser Femstegs prosedyre for programmering 1 2 Læringsmål og pensum TDT4110 Informasjonsteknologi grunnkurs: Uke 38 Utvikling av informasjonssystemer Læringsmål Kunne seks faser for systemanalyse og design Kunne femstegs prosedyre for programmering

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

Skriv vinnende tilbud

Skriv vinnende tilbud Skriv vinnende tilbud Workshop Sales 15.-16.09.2009 Introduksjon Hva vi skal gjennom i dag Kort introduksjon Hva er kunden opptatt av, og hva kan vi gjøre for å øke vår mulighet for suksess Tema 2: Utforming

Detaljer

DRI 2001 Systemutviklingsarbeidet et overblikk Forelesning

DRI 2001 Systemutviklingsarbeidet et overblikk Forelesning Systemutviklingsarbeidet et overblikk DRI2001 forelesning 21. sept. 05 Informasjonssystem og datasystem Hva er systemutvikling (SU) Et enkelt eksempel å bygge et hus Rammer og perspektiver for SU-arbeidet

Detaljer

Spørsmål og aktiviteter på ulike nivåer

Spørsmål og aktiviteter på ulike nivåer og aktiviteter på ulike nivåer Blooms taksonomi Evaluering Analyse Syntese Kunnskap Forståelse Anvende Kunnskap Her starter elevene med egen tekstproduksjon. Bilder, tegninger o.l. vil kunne hjelpe til

Detaljer

INF Modellering med objekter (Oblig 2) **TimeregistreringSystem** (Designet av Alen Cemer

INF Modellering med objekter (Oblig 2) **TimeregistreringSystem** (Designet av Alen Cemer INF5120 - Modellering med objekter (Oblig 2) **TimeregistreringSystem** (Designet av Alen Cemer alence@ifi.uio.no) 1 2 2-1: Business Model... 5 Scoping Statements Context Statements... 5 Goal modell...

Detaljer

Første kontakt med god potensiell kunde

Første kontakt med god potensiell kunde Jobb med meg skjema Steg 1 av 4 Første kontakt med god potensiell kunde I denne leksjonen skal du lære hvordan du effektivt får de svar du trenger fra en potensiell kunde, slik at du kan vurdere om dere

Detaljer

Obligatorisk oppgave 1 INF1050 Foranalyse og kravhåndtering. av Andreas Johansen Alexander Storheill Martin Dørum Nygaard Tobias Langø Aasmoe

Obligatorisk oppgave 1 INF1050 Foranalyse og kravhåndtering. av Andreas Johansen Alexander Storheill Martin Dørum Nygaard Tobias Langø Aasmoe Obligatorisk oppgave 1 INF1050 Foranalyse og kravhåndtering av Andreas Johansen Alexander Storheill Martin Dørum Nygaard Tobias Langø Aasmoe Oppgave 1: Bakgrunn for systemet a) Fordeler ved å integrere

Detaljer

Systemutvikling - oppsummering. Alexander Nossum blog.eksplisitt.net 22. mai 2006

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

Detaljer

Første kontakt med god potensiell kunde

Første kontakt med god potensiell kunde Første kontakt med god potensiell kunde I denne leksjonen skal du lære hvordan du effektivt får de svar du trenger fra en potensiell kunde, slik at du kan vurdere om dere er en god match. Uten en gang

Detaljer

UKE 11 UML modellering og use case. Gruppetime INF1055

UKE 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

Detaljer

Promaps Online et simuleringsverktøy

Promaps Online et simuleringsverktøy Promaps Online et simuleringsverktøy Den avgjørende rollen design spilte i utviklingen av Promaps - nominert til teknologibragden 2014 Av Arne Brufladt Svendsen 1 04/03/14 Bakgrunn Det startet med en diplomoppgave

Detaljer

Verden. Steg 1: Vinduet. Introduksjon

Verden. Steg 1: Vinduet. Introduksjon Verden Introduksjon Processing Introduksjon Velkommen til verdensspillet! Her skal vi lage begynnelsen av et spill hvor man skal gjette hvilke verdensdeler som er hvor. Så kan du utvide oppgava til å heller

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

Ledelsen lar stort sett ansatte ta sine egne beslutninger. Ledelsen holder streng kontroll med arbeidet til de ansatte

Ledelsen lar stort sett ansatte ta sine egne beslutninger. Ledelsen holder streng kontroll med arbeidet til de ansatte NOCM Dimensjoner og ledd Autonomi Ledelsen lar stort sett ansatte ta sine egne beslutninger Ledelsen har tillit til at folk kan ta arbeidsrelaterte beslutninger uten å innhente tillatelse først Ledelsen

Detaljer

Test og kvalitet To gode naboer. Børge Brynlund

Test 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

Detaljer

Kap. 2 Prosessen. Utviklingsmodeller -2. Utviklingsmodeller. Utviklingsmodeller -4. Utviklingsmodeller - 3. Software Engineering - definisjoner

Kap. 2 Prosessen. Utviklingsmodeller -2. Utviklingsmodeller. Utviklingsmodeller -4. Utviklingsmodeller - 3. Software Engineering - definisjoner Software Engineering - definisjoner Kap. 2 Prosessen Utviklingsprosessen Modeller for utvikling Bauer: Etablering og bruk av gode ingeniørmessige prinsipper for å fremskaffe økonomisk programvare som er

Detaljer

Design og dokumentasjon

Design og dokumentasjon Design og dokumentasjon Information Architecture Peter Morville& Louis Rosenfeld Kapittel 12 29.01.2015 Håkon Tolsby 1 Ny fase i prosjektet Fokusskifte: Fra planlegging til produksjon Fra overordnet arkitektur

Detaljer

IT Service Management

IT Service Management IT Service Management Forelesning uke 7 Innhold Endringer Endringer i ITIL: Service Transition Endringer - en nødvendig onde? If it ain t broke don t fix it. De fleste supportsaker synes å skyldes endringer

Detaljer

GJENNOMGANG UKESOPPGAVER 7 REPETISJON

GJENNOMGANG 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

Detaljer

Hva er datakvalitet? Hvordan skal arkivtjenesten forholde seg til det?

Hva er datakvalitet? Hvordan skal arkivtjenesten forholde seg til det? Hva er datakvalitet? Hvordan skal arkivtjenesten forholde seg til det? Thomas Sødring Høyskolen i Oslo og Akershus thomas.sodring@hioa.no 99570472 1/20 Bakgrunn Flere og flere depot institusjoner gjør

Detaljer

Vår kognitiv-semiotiske modell gir muligheten til å forstå kunnskapsdynamikken som finner sted i individet og i en innovasjonsprosess.

Vår kognitiv-semiotiske modell gir muligheten til å forstå kunnskapsdynamikken som finner sted i individet og i en innovasjonsprosess. Sammendrag Innledning Organisatorisk innovasjon følges ofte av problemer [e.g. van de Ven 1986; Leonard-Barton 1988/1995; Geerts 1999; Laudon & Laudon 2000/2002; van Stijn 2006]. Vi mener at kunnskap er

Detaljer

Kapittel 7 & 8. Kravspesifikasjoner & Data design. Thomas Tjøstheim og Thomas Edvinsen. 20 September Kapittel 7 & 8 p.1/20

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

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

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

Detaljer

Innhold Forord...3 Begreper og akronymer...4 Systembeskrivelse...5 Generelt...5 Funksjonelle krav...7 Ikke-Funksjonelle krav...9 Prioritering...

Innhold Forord...3 Begreper og akronymer...4 Systembeskrivelse...5 Generelt...5 Funksjonelle krav...7 Ikke-Funksjonelle krav...9 Prioritering... Innhold Forord...3 Begreper og akronymer...4 Systembeskrivelse...5 Generelt...5 Funksjonelle krav...7 Ikke-Funksjonelle krav...9 Prioritering...9 2 Forord Denne kravspesifikasjonen har blitt utviklet i

Detaljer

Genitalkirurgi i Beograd!

Genitalkirurgi i Beograd! Dr. Miro i blå skjorte, her omringet av kirurger fra hele verden som kommer for å lære teknikkene hans. Journalisten snek seg med på bildet. Genitalkirurgi i Beograd! Dr. Miro er viden kjent for de fleste

Detaljer

Fagartikkel. 12 kriterier for å lykkes med outsurcing

Fagartikkel. 12 kriterier for å lykkes med outsurcing Fagartikkel 9. desember 2004 12 kriterier for å lykkes med outsurcing Bortsetting av it-oppgaver til en ekstern leverandør øker. Tilgang på kompetanse, økt servicenivå og et ønske om å fokusere på egne

Detaljer

Testplan (Software Test Plan)

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

Detaljer

Steg 1: Få noe på skjermen

Steg 1: Få noe på skjermen Skrive egen kode Skrevet av: Erik Aasmundrud Kurs: Elm Tema: Tekstbasert, Nettside Fag: Matematikk, Programmering, Teknologi Klassetrinn: 8.-10. klasse, Videregående skole Introduksjon Denne oppgaven har

Detaljer

Om du allerede kjenner Scratch og har en Scratchbruker kan du gå videre til Steg 1.

Om du allerede kjenner Scratch og har en Scratchbruker kan du gå videre til Steg 1. Pingviner på tur Skrevet av: Geir Arne Hjelle Kurs: Scratch Tema: Blokkbasert, Spill Fag: Programmering Klassetrinn: 1.-4. klasse, 5.-7. klasse, 8.-10. klasse Introduksjon Velkommen til Scratch. Vi skal

Detaljer

PROEX.NO. En webbasert samhandlingsløsning. Utviklet av Eskaler as. Rogaland Kunnskapspark Postboks 8034 Postterminalen 4068 Stavanger

PROEX.NO. En webbasert samhandlingsløsning. Utviklet av Eskaler as. Rogaland Kunnskapspark Postboks 8034 Postterminalen 4068 Stavanger PROEX.NO En webbasert samhandlingsløsning. Utviklet av Eskaler as Rogaland Kunnskapspark Postboks 8034 Postterminalen 4068 Stavanger Telefon: 51 87 48 50 Fax: 51 87 40 71 Dette dokumentet inneholder en

Detaljer

CORBA Component Model (CCM)

CORBA 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

Detaljer

Omstendigheter omkring dødsfallet:. Min helse er: 1 veldig god 2 - god 3 sånn passe 4 ikke så god 5 ikke god i det hele tatt

Omstendigheter omkring dødsfallet:. Min helse er: 1 veldig god 2 - god 3 sånn passe 4 ikke så god 5 ikke god i det hele tatt Tosporsmodellen ved sorg. Selvrapporteringsskjema. The Two-Track Bereavement Questionnaire; Rubin, Malkinson, Bar Nadav & Koren, 2004. Oversatt til norsk ved S.Sørlie 2013 kun for klinisk bruk. De følgende

Detaljer

Saksnr. 2013/188 2-faktor autentisering. Spørsmål og svar: :

Saksnr. 2013/188 2-faktor autentisering. Spørsmål og svar: : Spørsmål og svar: 1 26.07.2013: 2 3 I «Bilag 1 - Kundens kravspesifikasjon» under krav T9 og T10 spesifiseres krav til integrasjon mot Microsoft Forefront Threat Management Gateway. Denne løsningen er

Detaljer

Tom Røise 26.02.2007. IMT2243 : Systemutvikling 1. IMT2243 Systemutvikling 26. februar 2007. Klassediagrammet. Klasse

Tom Røise 26.02.2007. IMT2243 : Systemutvikling 1. IMT2243 Systemutvikling 26. februar 2007. Klassediagrammet. Klasse IMT2243 Systemutvikling 26. februar 2007 Tema : Domenemodellering og Kravspeken - Repetisjon konseptuelle klassediagram - Eksempler - konseptuelle klassediagram (IHID løsningen og OL-Veiviseren) - Maler

Detaljer

Forprosjekt. Oppgdragsgiver Unikia, Lille grensen 7, 0159 Oslo, Kontaktperson Anders Kose Nervold,

Forprosjekt. Oppgdragsgiver Unikia, Lille grensen 7, 0159 Oslo, Kontaktperson Anders Kose Nervold, Hovedprosjekt i data/informasjonsteknologi Høgskolen i Oslo og Akershus Forprosjekt Prosjekttittel Unikia Android applikasjon Gruppe 13 Markus Bugge-Hundere s188909 Morten Wold Aksel Wiig s236326 s232324

Detaljer

Steg 1: Bli kjent med spillet

Steg 1: Bli kjent med spillet Krabbeangrep! Remiks Skrevet av: Gudbrand Tandberg Kurs: Scratch Tema: Blokkbasert, Spill, Animasjon Fag: Programmering Klassetrinn: 1.-4. klasse, 5.-7. klasse, 8.-10. klasse Introduksjon Denne uken skal

Detaljer

Verden. Introduksjon. Skrevet av: Kine Gjerstad Eide og Ruben Gjerstad Eide

Verden. Introduksjon. Skrevet av: Kine Gjerstad Eide og Ruben Gjerstad Eide Verden Skrevet av: Kine Gjerstad Eide og Ruben Gjerstad Eide Kurs: Processing Tema: Tekstbasert Fag: Matematikk, Programmering, Samfunnsfag Klassetrinn: 8.-10. klasse, Videregående skole Introduksjon Velkommen

Detaljer

Gruppenavn. Prosjektnavn Kravdokument For Navn på systemet. Versjon <1.0>

Gruppenavn. Prosjektnavn Kravdokument For Navn på systemet. Versjon <1.0> Gruppenavn Prosjektnavn Kravdokument For Navn på systemet Versjon Revisjonshistorie Dato Versjon Beskrivelse av endring Forfatter Innhold 1. Innledning 4 1.1

Detaljer

IT Service Management

IT Service Management IT Service Management Forelesning uke 3 Innhold Repetisjon fra forrige uke. Service Operation: Incident Management Repitisjon Service Operation: Finne rette balansen Event Management: Få oversikt over

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

FORPROSJEKT KIM LONG VU DUY JOHNNY KHAC NGUYEN ADRIAN SIIM MELSOM HÅKON THORKILDSEN SMØRVIK

FORPROSJEKT KIM LONG VU DUY JOHNNY KHAC NGUYEN ADRIAN SIIM MELSOM HÅKON THORKILDSEN SMØRVIK 2017 FORPROSJEKT BACHELOROPPGAVE 2017 KIM LONG VU DUY JOHNNY KHAC NGUYEN ADRIAN SIIM MELSOM HÅKON THORKILDSEN SMØRVIK PRESENTASJON OPPGAVE: Oppgaven er å lage en webapplikasjon som kan hjelpe bachelor

Detaljer

Quo vadis prosessregulering?

Quo vadis prosessregulering? Quo vadis prosessregulering? Morten Hovd PROST industrimøte Granfos, 24. Januar 2001 PROST Industrimøte, Granfos, 24. januar 2001 Hvor står vi? Et subjektivt bilde PROST Industrimøte, Granfos, 24. januar

Detaljer

Prototyping og kommunikasjon med brukere

Prototyping og kommunikasjon med brukere Inf 1510: Bruksorientert design Prototyping og kommunikasjon med brukere 04.04.2016, Rune Rosseland Oversikt Brukerinvolvering Hva er brukerens motivasjon for å bidra? Hva skal brukerens rolle være? Hvordan

Detaljer

Gruppe 11. Frank Petter Larsen Vegard Dehlen

Gruppe 11. Frank Petter Larsen Vegard Dehlen qoskets Gruppe 11 Frank Petter Larsen Vegard Dehlen Problematikk Dagens mellomvare for objektbaserte distribuerte systemer har ikke innebygget støtte for å spesifisere, overvåke og kontrollere tjenestekvalitet

Detaljer

Datakvalitet og Noark

Datakvalitet og Noark Datakvalitet og Noark IKA Hordaland 24.04.2017 thomas.sodring@hioa.no 1/17 Datakvalitet Datakvalitet som et eget forskningsfelt har eksistert siden 1970 tallet men det var etter 2000 tallet at flere og

Detaljer

Statusrapport. MUSIT Ny IT-arkitektur Pilot. NØKKELINFORMASJON Rapporteringstidspunkt 9. mai 2016 Rapporteringsperiode April 2016

Statusrapport. MUSIT Ny IT-arkitektur Pilot. NØKKELINFORMASJON Rapporteringstidspunkt 9. mai 2016 Rapporteringsperiode April 2016 Statusrapport MUSIT Ny IT-arkitektur Pilot NØKKELINFORMASJON Rapporteringstidspunkt 9. mai 2016 Rapporteringsperiode April 2016 Prosjektleder Line Arild Sjo Prosjekteier Leder MUSIT styre Prosjektnummer

Detaljer

Produktrapport. Produktrapport. Hjelpemiddel portal for Parkinsonforbundet

Produktrapport. Produktrapport. Hjelpemiddel portal for Parkinsonforbundet Produktrapport Hjelpemiddel portal for Parkinsonforbundet 1 Innhold: Forord ------------------------------------------------------------------------------------------------------2 Planlegging og arbeidsmetode

Detaljer

Kostnadseffektivt eller bortkastet tid? Øyvind Woll Seniorkonsulent, Vivento AS

Kostnadseffektivt eller bortkastet tid? Øyvind Woll Seniorkonsulent, Vivento AS Kostnadseffektivt eller bortkastet tid? Øyvind Woll Seniorkonsulent, Vivento AS Input Output Hvordan kan vi fastslå om systemet er testbart? Hvordan kan vi lære mer om systemet? Hvordan kan vi bli bedre

Detaljer

11 Planlegging og dokumentasjon

11 Planlegging og dokumentasjon 11 Planlegging og dokumentasjon Ulike arbeidsmetoder Systemutvikling Som systemutvikler er du i stand til å omsette din innsikt i brukerbehov til praktiske programbaserte løsninger. Samarbeid: Programmerer

Detaljer

Spørsmål og svar til Konkurransegrunnlag

Spørsmål og svar til Konkurransegrunnlag CMS-løsning Saksnr.: INTER-030-13 Spørsmål og svar til Konkurransegrunnlag # 2, utsendt 20.11.2013 1. Introduksjon 1.1 Formål Formålet med dette dokumentet er å gi svar på innkomne spørsmål til Konkurransegrunnlaget

Detaljer

GJENNOMGANG OBLIGATORISK OPPGAVE 1

GJENNOMGANG 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

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

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

Finansportalen Historiske bankdata

Finansportalen Historiske bankdata Bilag 5: Testing og godkjenning For Finansportalen Historiske bankdata Bilag 5 Testing og godkjenning Innholdsfortegnelse 1.1 OMFANG... 3 1.1.1 Systemtest 3 1.1.2 Godkjenningsprøve 3 1.2 GJENNOMFØRING...

Detaljer

Hvilke forventinger har bedriften? - våre erfaringer som «stor» og «liten» Jøran Bøch, CEO / Daglig leder

Hvilke forventinger har bedriften? - våre erfaringer som «stor» og «liten» Jøran Bøch, CEO / Daglig leder Hvilke forventinger har bedriften? - våre erfaringer som «stor» og «liten» Jøran Bøch, CEO / Daglig leder Agenda 1. Hvem er vi, Egde Consulting? 2. Våre erfaringer med forskjellige virkemiddel Som en del

Detaljer

SPAR TID OG PENGER. med en bedre og mer effektiv KUNDEBEHANDLING.

SPAR TID OG PENGER. med en bedre og mer effektiv KUNDEBEHANDLING. SPAR TID OG PENGER med en bedre og mer effektiv KUNDEBEHANDLING 1 Jobb med meg skjema Leksjon 1 av 4 Første kontakt med potensiell kunde I denne leksjonen skal du lære hvordan du effektivt får de svar

Detaljer

Kontrakter. INF1050: Gjennomgang, uke 12

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

Detaljer

Lynkurs 10. Januar 2012

Lynkurs 10. Januar 2012 Lynkurs 10. Januar 2012 Mål : Dagens lynkurs skal gi dere noen holdepunkter for å komme i gang med arbeidet med bacheloroppgaven på en systematisk og strukturert måte. Fokus er rettet mot arbeidet knyttet

Detaljer

Forprosjektrapport. Gruppe Januar 2016

Forprosjektrapport. Gruppe Januar 2016 Forprosjektrapport Gruppe 22 22. Januar 2016 Innholdsfortegnelse Innholdsfortegnelse Presentasjon Sammendrag Dagens situasjon Mål og rammebetingelser Mål Rammebetingelser Løsninger og alternativer Løsning

Detaljer

! Slik består du den muntlige Bergenstesten!

! Slik består du den muntlige Bergenstesten! Slik består du den muntlige Bergenstesten Dette er en guide for deg som vil bestå den muntlige Bergenstesten (Test i norsk høyere nivå muntlig test). For en guide til den skriftlige delen av testen se

Detaljer

EKSAMEN. Evaluering av IT-systemer. Eksamenstid: kl 0900 til kl 1300

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

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) 2. Verdien av etnografi er at den hjelper til å oppdage som reflekterer hvordan folk faktisk jobber a)

Detaljer