Systemutviklingen er ferdig når et system er operativt. Med operativt menes når systemet blir brukt av brukerne på et faktisk arbeidssted.
|
|
- Tordis Bråthen
- 7 år siden
- Visninger:
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 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
DetaljerKravhåndtering. INF1050: Gjennomgang, uke 03
Kravhåndtering INF1050: Gjennomgang, uke 03 Kompetansemål Kravhåndtering Anvende metoder og teknikker for å Innhente / Analysere / Spesifisere krav Ulike typer krav Funksjonelle krav Ikke-funksjonelle
DetaljerGrunnleggende testteori
1 Grunnleggende testteori Industri - og software produkt Industriprodukt: Fysisk produkt Testes under produksjon og til slutt om produktet oppfyller kravene Tilpasses, endres, redesignes, og justeres så
DetaljerGrunnleggende testteori
1 Grunnleggende testteori Error-Fault-Failure 2 Error : når en programmerer koder feil eller utelater kode (evt. miljøpåvirkning) årsaken til en fault Fault (defect eller bug): feil i kode kan lede til
DetaljerVisma 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
DetaljerGJENNOMGANG UKESOPPGAVER 9 TESTING
GJENNOMGANG UKESOPPGAVER 9 TESTING INF1050 V16 KRISTIN BRÆNDEN 1 A) Testing viser feil som du oppdager under kjøring av testen. Forklar hvorfor testing ikke kan vise at det ikke er flere gjenstående feil.
DetaljerKort om evaluering og testing av It-systemer. Hvordan vurdere, verdsette, velge og teste?
Kort om evaluering og testing av It-systemer Hvordan vurdere, verdsette, velge og teste? Evaluere - Bokmålsordboka Evaluere Vurdere, verdsette, gi karakter for. Vurdere Bedømme, verdsette. Bedømme Dømme
DetaljerGJENNOMGANG UKESOPPGAVER 2 PROSESSMODELLER OG SMIDIG PROGRAMVAREUTVIKLIG
GJENNOMGANG UKESOPPGAVER 2 PROSESSMODELLER OG SMIDIG PROGRAMVAREUTVIKLIG INF1050 V16 HVA ER EN SYSTEMUTVIKLINGSPROSESS? De aktivitetene som utføres for å utvikle et IT-system Eksempler på aktiviteter:
DetaljerGJENNOMGANG UKESOPPGAVER 3 KRAVHÅNDTERING
GJENNOMGANG UKESOPPGAVER 3 KRAVHÅNDTERING INF1050 V16 HVA ER KRAVHÅNDTERING? Kravhåndtering er prosessen å identifisere, analysere og spesifisere kravene til et nytt system eller et system som skal forbedres
DetaljerCharacteristics of a good design
Characteristics of a good design (PPT. side 1) Innledning Høykvalitetsdesign bør ha visse karakteristikker for å oppnå kvalitetsprodukter, dvs.: enkelt å forstå enkelt å implementere enkelt å teste enkelt
DetaljerEvaluering av It-systemer i et forvaltningsperspektiv. Drift, vedlikehold og videreutvikling av IT-systemet
Evaluering av It-systemer i et forvaltningsperspektiv Drift, vedlikehold og videreutvikling av IT-systemet Bakgrunnen IT-systemer har ofte lenger levetid enn forventet er ofte forretningskritiske utvikler
DetaljerModel 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
DetaljerNye 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
DetaljerTestrapport Prosjekt nr. 2011-22 Det Norske Veritas
Prosjekt nr. 2011 22 Testrapport Hovedprosjektets tittel Implementering av plugin og utvikling av wizard for Det Norske Veritas Prosjektdeltakere Magnus Strand Nekstad s156159 Jørgen Rønbeck s135779 Dato
DetaljerGruppenavn. 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
DetaljerPresentasjon 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
DetaljerLivsløpstesting av IT-systemer
Livsløpstesting av IT-systemer Testing, validering og evaluering Teste Undersøke ved hjelp av tester om systemet fungerer slik det er beskrevet Validere Bekrefte hvordan systemet virkelig fungerer, om
DetaljerTittel 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
DetaljerTom 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
DetaljerRettslige 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
DetaljerJernbaneverkets 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
DetaljerLøsningsforslag: Oblig 1. INF1050: Gjennomgang, uke 12
Løsningsforslag: Oblig 1 INF1050: Gjennomgang, uke 12 Obligatorisk oppgave 1: Pensum Bakgrunn for systemet Aktører og interessenter Utviklingsprosesser Kravhåndtering og kravspesifikasjon Use case-modellering
DetaljerDrosjesentralen. 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
DetaljerTest 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
DetaljerKan 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
DetaljerErfaring med funksjonell testing i en integrert ALM prosess
Erfaring med funksjonell testing i en integrert ALM prosess Forutsetninger for å kunne gjennomføre effektiv test Høy testdekning ved hjelp av regresjonstesting Feilhåndtering gjennom hele livssyklusen
DetaljerKap 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:
DetaljerDRI 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
DetaljerLykke til! Eksamen i fag TDT4140 Systemutvikling 28.11.2012 9.00. NTNU Norges teknisk-naturvitenskapelige universitet
Side 1 av 10 NTNU Norges teknisk-naturvitenskapelige universitet BOKMÅL Fakultet for informasjonsteknologi, matematikk og elektroteknikk Institutt for datateknikk og informasjonsvitenskap Sensurfrist:
DetaljerKvalitetskrav 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
DetaljerForord 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
DetaljerGrunnleggende testteori. Etter Hans Schaefer
Grunnleggende testteori Etter Hans Schaefer Industri- og softwareprodukt Industriprodukt Fysisk produkt Testes under produksjon og til slutt om produktet oppfyller kravene Tilpasses, endres, redesignes,
DetaljerSTE6221 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
DetaljerDRI2001 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
DetaljerHvor 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
DetaljerKonfigurasjonsstyring. 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
DetaljerLæ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
DetaljerAkseptansetesten. Siste sjanse for godkjenning Etter Hans Schaefer
Akseptansetesten Siste sjanse for godkjenning Etter Hans Schaefer Akseptansetesting Formell testing med hensyn til brukerbehov, krav, og forretningsprosesser som utføres for å avklare om et system oppfyller
DetaljerSkriv 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
DetaljerDRI 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
DetaljerSpø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
DetaljerINF 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...
DetaljerFø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
DetaljerObligatorisk 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
DetaljerSystemutvikling - oppsummering. Alexander Nossum blog.eksplisitt.net 22. mai 2006
Systemutvikling - oppsummering Alexander Nossum alexander@nossum.net blog.eksplisitt.net 22. mai 2006 INNHOLD 2 Innhold 1 Utviklingsprosessmodeller 3 1.1 Fossefall/waterfall................................
DetaljerFø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
DetaljerUKE 11 UML modellering og use case. Gruppetime INF1055
UKE 11 UML modellering og use case Gruppetime INF1055 Hva skal vi i dag? Analyse og design - kapittel 5 og 7 UML modellering Ukesoppgaver 3: Modellering av krav UML UML Kompetansemål Modellering av krav
DetaljerPromaps 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
DetaljerVerden. 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
DetaljerDokument 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
DetaljerLedelsen 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
DetaljerTest og kvalitet To gode naboer. Børge Brynlund
Test og kvalitet To gode naboer Børge Brynlund To gode naboer som egentlig er tre Kvalitetssikring, kvalitetskontroll og testing Kvalitet I Betydningen Kvalitet er den viktigste faktoren for å avlede langsiktig
DetaljerKap. 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
DetaljerDesign 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
DetaljerIT 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
DetaljerGJENNOMGANG UKESOPPGAVER 7 REPETISJON
GJENNOMGANG UKESOPPGAVER 7 REPETISJON INF1050 V16 KRISTIN BRÆNDEN DAGENS TEMA Oppgaver hentet fra tidligere eksamensoppgaver om temaene vi har gått gjennom til nå DAGENS PLAN Gjennomgang av oppgaver Repetisjon
DetaljerHva 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
DetaljerVå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
DetaljerKapittel 7 & 8. Kravspesifikasjoner & Data design. Thomas Tjøstheim og Thomas Edvinsen. 20 September Kapittel 7 & 8 p.1/20
Kapittel 7 & 8 p.1/20 Kapittel 7 & 8 Kravspesifikasjoner & Data design Thomas Tjøstheim og Thomas Edvinsen 20 September 2004 Kapittel 7 & 8 p.2/20 Introduksjon Kravspesifikasjoner består av to underdeler:
DetaljerSpesifikasjon 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
DetaljerInnhold uke 7. Objektorientert programmering i Python: Introduksjon. Lite tilbakeblikk: Programflyt og skop. Lite tilbakeblikk: Funksjoner er uttrykk
Innhold uke 7 Objektorientert programmering i Python: Introduksjon IN1000 Høst 2017 uke 7 Siri Moe Jensen Lite tilbakeblikk: Prosedyrer og funksjoner Objektorientert programmering Introduksjon: Hvorfor,
DetaljerInnhold 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
DetaljerGenitalkirurgi 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
DetaljerFagartikkel. 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
DetaljerTestplan (Software Test Plan)
Testplan (Software Test Plan) Amanuel K. Tedla Eleonora Ntreska Ingrid Vik Hansen Joakim Moen Innholdsfortegnelse Innholdsfortegnelse 1.. Introduksjon... 3 1.1 Definisjoner... 3 1.2 Antagelser ved testing
DetaljerSteg 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
DetaljerOm 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
DetaljerPROEX.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
DetaljerCORBA Component Model (CCM)
CORBA Component Model (CCM) INF5040 Høst 2005 Erlend Birkedal Jan Erik Johnsen Tore Ottersen Løkkeberg Denne presentasjonen CORBA Svakheter ved CORBA Object Model Komponenter CORBA Component Model Hva
DetaljerOmstendigheter 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
DetaljerSaksnr. 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
DetaljerTom 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
DetaljerForprosjekt. 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
DetaljerSteg 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
DetaljerVerden. 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
DetaljerGruppenavn. 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
DetaljerIT 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
DetaljerAnsvarsdrevet 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
DetaljerFORPROSJEKT 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
DetaljerQuo 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
DetaljerPrototyping 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
DetaljerGruppe 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
DetaljerDatakvalitet 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
DetaljerStatusrapport. 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
DetaljerProduktrapport. Produktrapport. Hjelpemiddel portal for Parkinsonforbundet
Produktrapport Hjelpemiddel portal for Parkinsonforbundet 1 Innhold: Forord ------------------------------------------------------------------------------------------------------2 Planlegging og arbeidsmetode
DetaljerKostnadseffektivt 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
Detaljer11 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
DetaljerSpø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
DetaljerGJENNOMGANG OBLIGATORISK OPPGAVE 1
GJENNOMGANG OBLIGATORISK OPPGAVE 1 INF1050 V16 KRISTIN BRÆNDEN 1 Systemet for utleie av markasykler ønsker a benytte seg av en eksisterende betalingsløsning, og valget har falt pa det samme betalingssystemet
DetaljerKunden er en av Norges ledende leverandører av digital-tv og bredbåndstjenester.
1 Forord Hensikten med kravspesifikasjonen er å gi oppdragsgiver og utviklere en enighet og forståelse av funksjonaliteten til applikasjonen som skal produseres. en definerer i tillegg prosjektets rammer
DetaljerUNIVERSITETET I OSLO
Bokmål Kandidat nummer: UNIVERSITETET I OSLO Det matematisk-naturvitenskapelige fakultet Eksamen i: INF1050 Eksamensdag: 31. Mai, 2011 Tid for eksamen: 09:00-13:00 Oppgavesettet er på 6 sider Vedlegg:
DetaljerFinansportalen 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...
DetaljerHvilke 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
DetaljerSPAR 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
DetaljerKontrakter. INF1050: Gjennomgang, uke 12
Kontrakter INF1050: Gjennomgang, uke 12 Kompetansemål Kontrakter I plandrevet utvikling I smidig utvikling Behov for smidige kontrakter Kontraktsmodeller PS2000 Del I: Kontrakter Grunnleggende: Hva? Plandrevet
DetaljerLynkurs 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
DetaljerForprosjektrapport. 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 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
DetaljerEKSAMEN. Evaluering av IT-systemer. Eksamenstid: kl 0900 til kl 1300
EKSAMEN Emnekode: ITL24006 Dato: 4. desember 2007 Hjelpemidler: Emne: Evaluering av IT-systemer Eksamenstid: kl 0900 til kl 1300 Faglærer: Ingen, heller ikke kalkulator eller mobiltelefon Kåre Sorteberg
Detaljer1. Hvilke type krav angår sikkerhet og pålitelighet?
1. Hvilke type krav angår sikkerhet og pålitelighet? a) Funksjonelle b) Ikke-funksjonelle Svar: b) 2. Verdien av etnografi er at den hjelper til å oppdage som reflekterer hvordan folk faktisk jobber a)
Detaljer