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

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

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

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

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

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

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

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

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

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

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

Utforskeren. Stille gode spørsmål

Utforskeren. Stille gode spørsmål Utforskeren Stille gode spørsmål Utforskeren 8-10 En «mal» for timene? Kognisjon og metakognisjon I praksis handler kognisjon om kunnskap (hvor mange meter er det i en kilometer), ordforståelse (hva er,

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

Metoder for evaluering. Flere generelle RRISC

Metoder for evaluering. Flere generelle RRISC Metoder for evaluering Flere generelle RRISC En enkel evalueringsmetode 1. Før evaluering 1. Velg evalueringsnivå 2. Velg evalueringsteknikk 2. Under evaluering 1. Utføre målingene 2. Registrere resultatene

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

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

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

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

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

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

AlgDat 12. Forelesning 2. Gunnar Misund

AlgDat 12. Forelesning 2. Gunnar Misund AlgDat 12 Forelesning 2 Forrige forelesning Følg med på hiof.no/algdat, ikke minst beskjedsida! Algdat: Fundamentalt, klassisk, morsomt,...krevende :) Pensum: Forelesningene, oppgavene (pluss deler av

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

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

SCD kurs. Leksjon 6 SCD i en sammenheng

SCD kurs. Leksjon 6 SCD i en sammenheng SCD kurs Leksjon 6 SCD i en sammenheng SCD i en sammenheng Et multifaglig samarbeid Bidrag fra andre fagdisipliner SCD Utviklingsløp Drift og vedlikehold Operasjonsmanualer SCD er Et multifaglig samarbeid

Detaljer

IEC 61508. Hovedprinsipper og veiledning

IEC 61508. Hovedprinsipper og veiledning IEC 61508 Hovedprinsipper og veiledning Stein Hauge SINTEF Tlf: 75 17 33 70 / 930 18 395 haustein@online.no / stein.hauge@sintef.no 1 Bare måtte bruke IEC 61508 1 2 3 4 5 6 7 8 9 1010 1 1212 1313 1414

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

Hasardidentifikasjon. Hvordan finne ut hva som kan gå GALT FØR det går galt.

Hasardidentifikasjon. Hvordan finne ut hva som kan gå GALT FØR det går galt. Hasardidentifikasjon Hvordan finne ut hva som kan gå GALT FØR det går galt. 1 Hasard (trussel, uønsket hendelse) 2 Hendelse/situasjon som potensielt kan medføre skade på mennesker eller miljø. Bilkollisjon,

Detaljer

Bedre valg av leverandør gjennom trialsourcing & Fastpris eller per time?! Oslo, 1. desember, 2014 Magne Jørgensen

Bedre valg av leverandør gjennom trialsourcing & Fastpris eller per time?! Oslo, 1. desember, 2014 Magne Jørgensen Bedre valg av leverandør gjennom trialsourcing & Fastpris eller per time?! Oslo, 1. desember, 2014 Magne Jørgensen Presentasjonen bygger på:" Better selection of Software Providers Through Trialsourcing,

Detaljer

Factory Patterns Interface Deklarerer at klassen skal bruke et interface (implements i Java) Definerer implementasjoner for alle metodene i interfacet

Factory Patterns Interface Deklarerer at klassen skal bruke et interface (implements i Java) Definerer implementasjoner for alle metodene i interfacet Factory Patterns Interface Deklarerer at klassen skal bruke et interface (implements i Java) Definerer implementasjoner for alle metodene i interfacet Slide 2 v Factory Method Pattern Class creational

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

Kap. 10 Systemutvikling System Engineering

Kap. 10 Systemutvikling System Engineering Kap. 10 Systemutvikling System Engineering - Utvikling og integrering av både maskin- og programvare. - Hvordan oppstår behov for programvare? - Hvordan inngår programvare i en sammenheng med andre (del)systemer,

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

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

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

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

Aktivitet Forberedelse, gjennomføring, rapportering og oppfølging av Risikoanalyse.

Aktivitet Forberedelse, gjennomføring, rapportering og oppfølging av Risikoanalyse. RISIKOANALYSE OG FAREREDUSERENDE TILTAK Hensikt Å etablere en skriftlig oversikt på hva som kan gå galt med tilhørende sannsynlighetsgrad for at det skjer med gradering av konsekvens. Videre fastlegge

Detaljer

2 Om statiske variable/konstanter og statiske metoder.

2 Om statiske variable/konstanter og statiske metoder. Litt om datastrukturer i Java Av Stein Gjessing, Institutt for informatikk, Universitetet i Oslo 1 Innledning Dette notatet beskriver noe av det som foregår i primærlageret når et Javaprogram utføres.

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

Vedlegg 1 til retningslinje 088 - Norsk olje og gass anbefalte retningslinjer for felles modell for arbeidstillatelser.

Vedlegg 1 til retningslinje 088 - Norsk olje og gass anbefalte retningslinjer for felles modell for arbeidstillatelser. Vedlegg 1 til retningslinje 088 - Norsk olje og gass anbefalte retningslinjer for felles modell for arbeidstillatelser Original versjon Nr: 088 Etablert: 15.01.2013 Revisjon nr: 1 Rev. dato: 03.06.2015

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

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

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

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

Nordic Urban Design Association

Nordic Urban Design Association Nordic Urban Design Association Sommerskole 2009, Sandefjord, 18-19 juni Foto: Knut Sten Hvordan skaper vi gode, attraktive og velfungerende plasser i våre byer- og tettsteder? - undervisning i metode,

Detaljer

BOKMÅL Side 1 av 7. KONTINUASJONSEKSAMEN I FAG TDT4100 Objektorientert programmering / IT1104 Programmering, videregående kurs

BOKMÅL Side 1 av 7. KONTINUASJONSEKSAMEN I FAG TDT4100 Objektorientert programmering / IT1104 Programmering, videregående kurs BOKMÅL Side 1 av 7 NTNU Norges teknisk-naturvitenskapelige universitet Fakultet for informasjonsteknologi, matematikk og elektroteknikk Institutt for datateknikk og informasjonsvitenskap KONTINUASJONSEKSAMEN

Detaljer

Tom Røise 18. Februar 2009

Tom Røise 18. Februar 2009 Forelesning IMT2243 18. Februar 2009 Tema : Kravspesifisering : litt mer om prosessen Viewpoint en myk tilnærming Use Case en scenariebasert teknikk innen metoden Objektorientert Analyse brukes til å avklare

Detaljer

GAME CHANGERS APPLICATION GUIDE

GAME CHANGERS APPLICATION GUIDE STEG 1: SØKNAD GAME CHANGERS APPLICATION GUIDE 1.1. Vennligst beskriv det sosiale problemet og utfordringene, for barn i ditt samfunn, som du ønsker å løse. Beskriv problemets omfang og bruk statistikk

Detaljer

Sluttprøve 2014 Løsningsforslag

Sluttprøve 2014 Løsningsforslag Høgskolen i Telemark Sluttprøve 2014 Løsningsforslag Merk! Løsningene som er skissert er ikke nødvendigvis de eneste riktige løsningene, samt noen av løsningsskissene er kun stikkordpreget/mangelfulle.

Detaljer

Ofte stilte spørsmål.

Ofte stilte spørsmål. Ofte stilte spørsmål. Spm.1 Hvordan kan det dokumenteres / bevises at de ansatte er kjent med visjon, formål og kvalitetspolitikk? SVAR.1 Dette kan vises gjennom samme type tilbakemeldinger fra hver av

Detaljer

Hva er et styringssystem?

Hva er et styringssystem? Hva er et styringssystem? Og forholdet mellom ISO 27001 og 27002 Seminar 12. april 2012 Ingvild Høvik Kiland Riksrevisjonens Dok 1 (2010-2011) Revisjonen var basert på Nasjonale retningslinjer for å styrke

Detaljer

Presentasjon Test. Møte med Systemleverandører 5.desember 2014

Presentasjon Test. Møte med Systemleverandører 5.desember 2014 Presentasjon Test Møte med Systemleverandører 5.desember 2014 Agenda Informasjon om status og planer for videre arbeid i Elhubprosjektet Informasjon om organisering av testaktiviteter Presentasjon av kravspesifikasjoner

Detaljer

Styrende dokumenter og informasjonssikkerhet - erfaringer fra Hydro

Styrende dokumenter og informasjonssikkerhet - erfaringer fra Hydro Styrende dokumenter og informasjonssikkerhet - erfaringer fra Hydro Sintef-seminar 22.november 2006 Hege Jacobsen Hydro IS Partner, Norsk Hydro 2006-11-20 Innhold Hydros organisasjon Målene for informasjonssikkerhet

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

INNOVASJON, VELFERDSTEKNOLOGI OG LÆRING. Hanne Hedeman 2015

INNOVASJON, VELFERDSTEKNOLOGI OG LÆRING. Hanne Hedeman 2015 INNOVASJON, VELFERDSTEKNOLOGI OG LÆRING Hanne Hedeman 2015 Innovasjon dreier seg om nyskapning. Innovasjon er å se muligheter og å være i stand til å føre disse muligheter ut i livet på en verdiskapende

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

Requirement Engineering Process

Requirement Engineering Process Prosessaktører Prosesstøtte Prosess management Prosesskalitet Prosessforbedring Horfor bruke prosessmodeller? forenklet beskrielse a en prosess lagd ut fra et bestemt perspekti så det kan ære flere forskjellige

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

Objektorientert programmering med Java ISBN 82-7674-748-5

Objektorientert programmering med Java ISBN 82-7674-748-5 Tema 8 Programdesign som isolerer godt mellom logikk og presentasjon passer godt for å lage ulike grensesnitt mot logikk-delen. Klassen ZipFile som ble brukt i et konsoll-basert grensesnitt på side 67,

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

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

Datastrukturer og Algoritmer

Datastrukturer og Algoritmer TOD 063 Datastrukturer og Algoritmer Forside fra lærebokens Nord Amerikanske utgave Tar for seg praktisk problemstilling: Hvordan håndtere containere som blir lastet fra containerskip i en travel havn

Detaljer

views personlig overblikk over preferanser

views personlig overblikk over preferanser views personlig overblikk over preferanser Kandidat: Ola Nordmann 20.05.2005 Rapport generert: 21.07.2006 cut-e norge as pb. 7159 st.olavsplass 0130 OSLO Tlf: 22 36 10 35 E-post: info.norge@cut-e.com www.cut-e.no

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

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

Tor-Eirik Bakke Lunde torebl@stud.cs.uit.no

Tor-Eirik Bakke Lunde torebl@stud.cs.uit.no Obligatorisk oppgave 1 INF-3200 12. oktober 2003 Tor-Eirik Bakke Lunde torebl@stud.cs.uit.no Oppgavebeskrivelse: Designe og implementere en distribuert ray-tracing applikasjon, med basis i kontroller-

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

Læringsmål for forelesningen

Læringsmål for forelesningen Læringsmål for forelesningen Objektorientering Abstrakte klasser og grensesnitt, redefinering av metoder Java-programmering Arv og bruk av abstrakte klasser Eclipse Undersøke instanser i Eclipse 1 Dagens

Detaljer

Strategier 2010-2015. StrategieR 2010 2015 1

Strategier 2010-2015. StrategieR 2010 2015 1 Strategier 2010-2015 StrategieR 2010 2015 1 En spennende reise... Med Skatteetatens nye strategier har vi lagt ut på en spennende reise. Vi har store ambisjoner om at Skatteetaten i løpet av strategiperioden

Detaljer

Systemutvikling (Software Engineering) TDT 4110 IT Grunnkurs Professor Guttorm Sindre

Systemutvikling (Software Engineering) TDT 4110 IT Grunnkurs Professor Guttorm Sindre Systemutvikling (Software Engineering) TDT 4110 IT Grunnkurs Professor Guttorm Sindre Læringsmål og pensum Mål Lære å lage større og sammensatte programmer Pensum Pythonboka kap. 1-9, 12 Teorikapitlet

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

Hvordan styre anskaffelsen Organisering-kvalitetssikring Hvordan unngå å gå i baret

Hvordan styre anskaffelsen Organisering-kvalitetssikring Hvordan unngå å gå i baret Hvordan styre anskaffelsen Organisering-kvalitetssikring Hvordan unngå å gå i baret Advokat Kristine Vigander, KS Advokatene Innhold Makro Hvordan tilrettelegge for anskaffelsesarbeidet i organisasjonen

Detaljer

omtanke Hvordan bør man restaurere/bygge for å få til leveområder for flora og fauna, og hva er det optimale fra et økologisk synspunkt?

omtanke Hvordan bør man restaurere/bygge for å få til leveområder for flora og fauna, og hva er det optimale fra et økologisk synspunkt? Vann er grunnlaget for liv, å bygge gode leveområder krever omtanke Jonathan E. Colman Sentrale spørsmål/utfordringer Hvordan bør man restaurere/bygge for å få til leveområder for flora og fauna, og hva

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

AP221 Use Case TUL Oversett tjenesteutgave

AP221 Use Case TUL Oversett tjenesteutgave AP221 Use Case TUL En utgave av en tjeneste skal kunne oversettes til valgte språk. Dette gjøres av oversetter når utgaven er utviklet nok til at det er hensiktsmessig å oversette. Det er definert et hovedspråk

Detaljer

SMARTVEILEDERN FOR GRUNNSKOLEN I VÅGAN KOMMUNE

SMARTVEILEDERN FOR GRUNNSKOLEN I VÅGAN KOMMUNE SMARTVEILEDERN FOR GRUNNSKOLEN I VÅGAN KOMMUNE MIN SMARTE IDÈ! SMARTERE ENERGI-KAMPANJEN 2010 INNHOLDSFORTEGNELSE FRAMDRIFTSPLAN FOR SMARTERE ENERGI PÅ TRE DAGER... 3 SMARTDAG 1... 3 SMARTDAG 2... 3 SMARTDAG

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

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

Systemutvikling i henhold til "V-modellen"

Systemutvikling i henhold til V-modellen 1 Systemutvikling i henhold til "V-modellen" TTK4235 Tilpassede datasystemer Øyvind Stavdahl Sist revidert: 2015 Denne lysarkserien er en bearbeidet versjon av tilsvarende serie utviklet av 1.aman.II Geir

Detaljer

Introduksjon til prosjektarbeid del 3. Prosjektadministrasjon Styring, organisasjon og ledelse

Introduksjon til prosjektarbeid del 3. Prosjektadministrasjon Styring, organisasjon og ledelse Introduksjon til prosjektarbeid del 3 Prosjektadministrasjon Styring, organisasjon og ledelse Prosjektadministrasjon Er alle oppgaver som har å gjøre med styring, organisasjon og ledelse av prosjektutførelsen

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

Introduksjon 1. Innledning.

Introduksjon 1. Innledning. Avdeling for informatikk og e-læring, Høgskolen i Sør-Trøndelag Introduksjon Jarle Larsen 03.01.2007 Lærestoffet er utviklet for faget LO340D Multimediaproduksjon med flash - teoridel 1. Innledning. Målet

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

Tildeling av minne til prosesser

Tildeling av minne til prosesser Tildeling av minne til prosesser Tildeling av minne til en prosess Når en ny prosess opprettes har den et krav til hvor mye minne som skal reserveres for prosessen Memory Management System (MMS) i OS må

Detaljer

Kapittel 7: Mer om arv

Kapittel 7: Mer om arv Kapittel 7: Mer om arv Redigert av: Khalid Azim Mughal (khalid@ii.uib.no) Kilde: Java som første programmeringsspråk (3. utgave) Khalid Azim Mughal, Torill Hamre, Rolf W. Rasmussen Cappelen Akademisk Forlag,

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

Det er forventet at du forandrer størrelsen på bilder før du laster dem opp, og ikke endrer størrelsen på dem på siden. Dette har 3 fordeler:

Det er forventet at du forandrer størrelsen på bilder før du laster dem opp, og ikke endrer størrelsen på dem på siden. Dette har 3 fordeler: BETINGELSER OG VILKÅR Lagewebside.no er underlagt disse betingelser og vilkår. Ved å bruke nettsiden og deres funksjonaliteter sier du deg enig i de følgende vilkårene, fra første gang du oppretter en

Detaljer

Fra idé til marked Hvorfor elektronikk handler om mer enn kretskort

Fra idé til marked Hvorfor elektronikk handler om mer enn kretskort NCEI Teknologifrokost 25. Mars 2015 Fra idé til marked Hvorfor elektronikk handler om mer enn kretskort Del 1: Are Hellandsvik Forsker ved SINTEF IKT Kommunikasjonssystemer Del 2: Terje Frøysa Forsker

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

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

Hovedmål. Delmål: Deltakeren skal:

Hovedmål. Delmål: Deltakeren skal: Kursplan trener 2 Hovedmål - Ha en helhetlig forståelse av treningsprosessen, og hva som kreves for å skape en sunn, positiv utvikling i valgt dansegren. - Ivareta utøvernes behov i et sosialt, spennende

Detaljer

Aktivitetskart. Fremdriftsplan: denne prosessen: Peder Sundbø. ferdigstilt uke 8. fastslåing av prosjekt. Magnus Eriksen. Uke 8.

Aktivitetskart. Fremdriftsplan: denne prosessen: Peder Sundbø. ferdigstilt uke 8. fastslåing av prosjekt. Magnus Eriksen. Uke 8. Aktivitetskart Planlegging dato: 29.01-09 TIL 7.2-09 Kravspesifikasjon beskrivelser Papirprototyp ER-diagram Planlegging og fastslåing av prosjekt En del av kravspesifikasjon. Grafisk visning av systemets

Detaljer

Personvern og informasjonssikkerhet ved anskaffelser

Personvern og informasjonssikkerhet ved anskaffelser Personvern og informasjonssikkerhet ved anskaffelser Innledning 2 Datatilsynet Uavhengig forvaltningsorgan Tilsyn og ombud Forvalter personopplysningsloven og forskrifter 40 medarbeidere Faggruppe 1 (justis,

Detaljer

Hva er en god søknad? Erfaringer fra evaluering 2014

Hva er en god søknad? Erfaringer fra evaluering 2014 Hva er en god søknad? Erfaringer fra evaluering 2014 Hilde Elin Haaland Kramer Universitetet i Bergen Katrine Moland Hansen SIU Gardermoen 03.02.2015 Evalueringskriterier Relevans (30%) Prosjektutforming

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

FITS Tilgjengelighets- og kapasitetsstyring

FITS Tilgjengelighets- og kapasitetsstyring FITS Tilgjengelighets- og kapasitetsstyring Becta 2004 Utgitt på norsk av Senter for IKT i utdanningen i 2012 FITS tilgjengelighets- og kapasitetsstyring Innhold TKS 1 Introduksjon... 1 TKS 2 Oversikt...

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

SERO - Brukervennlighet i fokus

SERO - Brukervennlighet i fokus SERO - Brukervennlighet i fokus Det er fint at Sero er norsk fordi det muliggjør tett kontakt uten for mange mellomledd. Tett oppfølging og mulighet til å diskutere problemer med produsenten er viktig

Detaljer

Trygt Boredekk - Sammarbeidprosjekt, Hydro, boreetreprenører og service selskap

Trygt Boredekk - Sammarbeidprosjekt, Hydro, boreetreprenører og service selskap Trygt Boredekk - Sammarbeidprosjekt, Hydro, boreetreprenører og service selskap NFLB-konferanse 09.02.2006 Terje W. Meldahl 2007-02-09 Prosjektet startet etter vellykket samarbeid med boreentreprenørene

Detaljer

Iden%fisere behov og etablere krav. INF 1500; introduksjon %l design, bruk og interaksjon 13 september 2010

Iden%fisere behov og etablere krav. INF 1500; introduksjon %l design, bruk og interaksjon 13 september 2010 Iden%fisere behov og etablere krav INF 1500; introduksjon %l design, bruk og interaksjon 13 september 2010 Oversikt Behov Krav Oppgavebeskrivelse Oppgaveanalyse Behov og krav Behov Noe som ikke er koplet

Detaljer

AssCE-Assessment of Clinical Education*, Bachelornivå

AssCE-Assessment of Clinical Education*, Bachelornivå AssCE*- skjema For vurdering av praksisstudier i bachelor-utdanningen i sykepleie Student: Studentnummer: Praksissted: Praksisperiode: Tidsperiode: 1 Bachelor nivå, sykepleie Mål for praksisstudier i sykepleierutdanningen

Detaljer