1. Mer om iterative utviklingsprosesser

Størrelse: px
Begynne med side:

Download "1. Mer om iterative utviklingsprosesser"

Transkript

1 Avdeling for informatikk og e-læring, Høgskolen i Sør-Trøndelag Mer om iterative utviklingsprosesser Tore Berg Hansen Lærestoffet er utviklet for faget LV339D Objektorientert ssytemutvikling 1. Mer om iterative utviklingsprosesser Resymé: I denne leksjonen skal vi se litt nærmere på iterative utviklingsprosesser. Vi tar for oss to av de mest kjente. Disse er UP og XP og oppfattes av mange som motpoler i dagens til dels hete debatt om utviklinghsprosesser. Innhold 1.1. INNLEDNING ROUND-TRIP ENGINEERING ITERASJONSLENGDE OG TIMEBOXING ER UP EN TUNG PROSESS? PLANER I UP XP ER EN LETTVEKTSPROSESS Rollene i et xp-team Trinnene i xp LESESTOFF LITTERATUR

2 1.1. Innledning Som vi skrev i innledningen til forrige leksjon, handler dettet faget hovedsakelig om objektorientert analyse og design, og at vi har lagt Unified Process (UP) som ramme rundt temaene i dette faget. I leksjon 1 tok vi for oss utviklingsprosesser generelt. Nå skal vi se litt nærmere på planleggings- og gjennomføringssiden ved en iterativ og inkrementell prosess. Vi har UP som bakteppe, men de fleste prinsipper og praksiser gjelder også for andre prosesser basert på de samme ideer. UP er en iterativ og inkrementell prosess. Det sentrale med iterativ utvikling er: En iterasjon er et miniprosjekt som har en på forhånd fastsatt varighet. Alle iterasjoner skal vanligvis ha samme lengde. Det kalles på engelsk timeboxing. Resultatet fra hver iterasjon er et testet, integrert kjørbart delsystem. Hver iterasjon har aktiviteter for å finne krav, designe, implementere og teste. Systemet vokser og tilpasses gjennom stadige utvidelser og raffineringer. Dette gjøres på basis av tilbakemeldinger fra brukere og andre interesseparter. Resultatet av hver iterasjon, unntatt den siste, er et ufullstendig system. Først etter iterasjoner, kan systemet gå i produksjon. I hver iterasjon plukker man ut en del av kravene som raskt designes, implementeres og testes. Man prøver først å realisere de mest problematiske og kritiske kravene og få på plass en overordnet arkitektur. Prosessen er risiko- og arkitekturdrevet. Det er bedre å finne ut av det som er vanskelig først, slik at alvorlige problemer ikke kommer som overraskelser mot slutten av prosjektet, når de er vanskelige og kostbare å løse. Iterativ utvikling er en mekanisme for å håndtere dette Round-trip engineering UP er iterativ. Hver iterasjon resulterer i et kjørbart system som er testet. Det kan prøves ut av brukere som gir tilbakemeldinger. Det betyr at kode generert fra modellene i iterasjonen kan ha blitt endret. Modellene som er input til neste iterasjon, må derfor oppdateres slik at de er i samsvar med aktuell kode. Sekvensen fra modell til kode til ny modell, kalles round-trip engineering. Prosessen med å lage modeller med utgangspunkt i kode kalles gjerne reverse engineering, mens det motsatte er forward engineering. Hvis dette skal fungere i praksis, trenger man verktøy. Ellers blir det tungt å vedlikeholde kode og modeller som skal høre sammen. Verktøy som Rational Rose inneholder denne muligheten. 2

3 1.3. Iterasjonslengde og timeboxing Hvor lang tid skal en iterasjon ta? Det anbefales fra 2 til 6 uker. En iterasjonslengde på særlig mindre enn to uker gir ikke tid til å gjøre arbeid som gir fornuftige resultater. Med mer enn seks uker faller noe av vitsen med iterativ utvikling bort. Et av poengene er jo å få tidlig tilbakemelding fra brukerne. Så kort er godt, men ikke for kort. Timeboxing vil si å holde iterasjonslengden konstant. På den måten vil man aldri overskride tidsfrister. Hvis man ikke får gjort alt man først planla i en iterasjon, må man redusere omfanget og overføre arbeid til neste iterasjon Er UP en tung prosess? I fagkretser pågår en debatt om ulike prosesser og deres fortrinn og ulemper. Det brukes begreper som tungvektsprosesser, lettvektsprosesser, fortunge prosesser, baktunge prosesser, balanserte prosesser, predikative prosesser og adaptive prosesser. En tungvektsprosess er karakterisert ved: Mange artefakter. Disse er resultat av mye formalisme og byråkrati. Lite rom for fleksibilitet, mye kontroll. Arbeidskrevende detaljplanlegging i starten av prosjektet. Predikativ fremfor adaptiv (forklares snart). Lettvektsprosesser er motstykket til tungvektsprosesser. Her vektlegges å få frem kjørbare systemer så tidlig som mulig. Man nedtoner betydningen av formelle dokumenter. Det utarbeides ikke detaljplaner for mer enn neste fase. Kunder/brukere deltar aktivt i utviklingsgruppen. I en predikativ prosess prøver man å forutsi og planlegge aktiviteter og ressurser i detalj tidlig i prosjektet. Tungvektsprosesser er gjerne predikative. Fossefallsmodellen er et eksempel på en predikativ tungvekstsprosess. En adaptiv prosess er karakterisert ved at man aksepterer at endringer er normalt. Endringer driver på en måte prosessen. Adaptive prosesser er gjerne lettvekts og evolusjonære. I en fortung prosess brukes relativt mye tid i de tidlige fasene frem tilkoding og relativt mindre tid til koding og testing. En baktung prosess blir dermed på en måte det motsatte, mens en balansert prosess har en mer jevnt fordelt innsats. 3

4 Hvilken plass har UP i dette bildet? Mange hevder at UP er en tungvektsprosess fordi det er beskrevet mange artefakter i prosessen. Men folkene bak UP hevder at ideen er en prosess som er lett å tilpasse prosjekters egenart. Artefaktene og praksisene er tilbud som man kan velge blant. Det eneste som står fast er iterativ og inkrementell utvikling. Det legges ikke opp til detaljerte planer for hele prosjektet i starten. Man lager bare en overordnet faseplan med datoer for viktige milepæler. Detaljplaner lages etter hvert for den løpende og etterfølgende iterasjon Planer i UP Planlegging i UP foregår på to nivåer makronivå og mikronivå. På makronivå lager man Faseplanen. Man fastsetter milepæler og overordnede mål. En milepæl markerer slutten på en fase eller en viktig hendelse i en fase. En milepæl har en dato, artefakter og kriterier som forteller om den er nådd. På mikronivå lages Iterasjonsplanen. Ettersom lengden på en iterasjon er fast og bestemt ved starten av prosjektet, blir den vesentlige oppgaven å finne ut hvor mye arbeid som det er plass til i iterasjonen. UP er use case-drevet. Men ikke alle krav og egenskaper ved systemet kan uttrykkes ved hjelp av use case. Use case er de funksjonelle kravene, men et system har også ikkefunksjonelle krav og egenskaper som ikke tilhører en bestemt use case. Eksempel på en slik egenskap er at det skal logges ting. Og man tar sikte på å løse de problematiske tingene først. Iterasjonsplanlegging består derfor i å prioritere use case realiseringer, hvor man også trekker inn egenskaper og ikkefunksjonelle krav. Store use case må fordeles på flere iterasjoner. En iterajon vil derfor bestå av: et eller flere hele use case deler av et use case ikkefunksjonelle krav egenskaper som ikke beskrives i use case Disse må altså prioriteres. Hvordan man kan gjøre rangeringen er beskrevet på side 130 i læreboken XP er en lettvektsprosess Extreme Programming (XP) er hett stoff for tiden. Denne prosessen oppfattes som motstykket til UP, selv om mange av ideene bak er de samme. I leksjon 1 hadde vi også en oversikt over prinsippene bak XP og hva som er ekstremt. Vi gjentar det ekstreme her: Hvis koderevisjoner er bra, må vi revidere kode hele tiden. To programmerere må arbeide sammen hele tiden. (Pair programming) Hvis testing er bra, skal alle teste hele tiden, også kundene. Hvis det å designe er bra, må det være noe enhver holder på med hver dag. Hvis enkelhet er bra, skal systemet være i den enkleste form som støtter ønsket funksjonalitet. 4

5 Hvis arkitektur er viktig, skal alle arbeide med å definere og raffinere arkitekturen hele tiden. Hvis integrasjonstesting er viktig, så skal man integrere og teste mange ganger hver dag. Hvis korte iterasjoner er bra, gjør man iterasjonene virkelig korte sekunder, minutter og timer, ikke uker, måneder og år. I denne leksjonen ser vi litt nærmere på XP-prosessen Rollene i et xp-team Programmereren hjertet i xp. Den som gjør de tekniske tingene i prosjektet. Kunden den andre halvdelen. Den som vet hva som skal programmeres. Dette dokumenteres i fortellinger (stories) på kartotekkort. Kunden er den virkelige brukeren av systemet som skal utvikles og skal inngå permanent i teamet. Tester hjelper kunden med akseptansetester. Oppfølger (tracker) noterer ned ressursbruken. Samler data for bruk i senere estimater. Skal kunne svare på om prosjektet følger tidsplanen. Trener (coach) ansvarlig for totalprosessen. Må være ekspert på xp. Konsulent (consultant) brukes hvis man har behov for å finne løsninger på vanskelige tekniske problemer. Big Boss lederen av hele bedriften som skal gjøre jobben Trinnene i xp Xp har disse trinnene: 1. Utforskning 2. Planlegging (av første frislipp, senere i prosessen nye frislipp) 3. Planlegging av iterasjon (første iterasjon, senere nye iterasjoner) 4. Utvikling av iterasjon 5. Gjenta for nye iterasjoner og frislipp Utforskning Utforskning kommer i stedet for kravspesifikasjonen. Kunde og programmerer møtes for å komme til enighet om hva som skal lages. Kunden skriver korte fortellinger (stories) på små kort (kartotekkort). Programmerer sjekker kortene for tvetydigheter og om fortellingene er testbare. Man kan godt sammenligne en fortelling med en høynivå use case. Det vil si at teksten bare består av noen få linjer. Programmereren estimerer hvor lang tid det vil ta å realisere fortellingen. Måleenheten kan være dager målt i ideell tid. På engelsk brukes begrepet ideal engineering time. Det vil si den tiden man ville brukt hvis man kunne arbeide alene og uforstyrret. En fortelling skal 5

6 være så kort at den kan realiseres innen en iterasjon (1 til 3 uker). Kunden spesifiserer en akseptansetest for hver fortelling. Kunden prioriterer fortellingene. De kan for eksempel legges i tre bunker en med de fortellinger som umiddelbart må realiseres, en bunke med de som kan vente en kort tid og resten i en bunke for de som kan vente noe lengere. Arbeidet i dette trinnet kan være kaotisk. Det er ikke slik at fortellingene spretter frem en etter en nesten av seg selv. Fortellingene kommer ganske tilfeldig som resultat av diskusjoner mellom kunde og programmerere. Ny innsikt kan føre til at fortellinger endres og at nye blir skrevet. Man kan også eksperimentere under utforskningen. Hvis man er usikker på om ting lar seg realisere eller det er knyttet risiko til ting, kan man skrive bruk-og-kast-kode for å få større visshet. I xp-terminologi sier man at man gjør en spike. Planlegging av frislipp Et xp-prosjekt brytes ned i en rekke frislipp (release). Hvert frislipp skal gi noe av verdi for kunden. Kunden bestemmer hvilke fortellinger som skal med i et frislipp. Det tar typisk en til tre måneder å realisere et frislipp. Måleenheten er arbeidsdager. Hvis man sier at tiden til frislipp er en måned, så betyr det at resultatet skal foreligge etter fire arbeidsuker. I Norge er som kjent en arbeidsuke 5 arbeidsdager. (Men kanskje ikke for studenter?). Hvor mange fortellinger som kan realiseres i et frislipp, bestemmes av programmerernes hastighet. Den er definert som antall ideelle dager som kan gjennomføres i løpet av en arbeidsuke. Hvis f.eks en programmerer kan gjennomføre 2,5 ideelle dager i en uke så er hastigheten 2,5. Eller sagt på en annen måte programmereren gjør 2,5 mengder arbeid i en uke. Skal man fylle opp en hel uke med arbeid for prosjektet, må man ha flere programmerere som arbeider samtidig. Planlegging av iterasjon Et frislipp deles opp i iterasjoner. En iterasjon tar fra en til tre uker. Også her er måleenheten arbeidsdager. Altså, hvis iterasjonslengden er en uke, betyr det at iterasjonen varer fem arbeidsdager. Iterasjonslengden bestemmes i starten av prosjektet og skal holdes fast i hele prosjektet. Hvor mye som kan gjøres i en iterasjon er altså bestemt av programmerernes hastighet. Til hjelp for iterasjonsplanleggingen gis kunden et budsjett. Det beskriver den mengde arbeid som utviklingsgruppen kan gjennomføre i en iterasjon. Det brukes samme måleenhet som ved estimeringen av fortellingene. Kunden bestemmer så hvilke fortellinger som skal realiseres, og forplikter seg til ikke å komme med endringer eller tillegg så lenge iterasjonen løper. Kunden spesifiserer en akseptansetest for iterasjonen. Programmereren bryter fortellingene ned i oppgaver (tasks). Størrelsen på en oppgave er slik at den kan utføres i løpet av en til to dager. En oppgave er altså en bit av en fortelling, som for eksempel å få på plass en database, lage en algoritme for å utføre en beregning, osv. En oppgave kan også berøre flere fortellinger. 6

7 Programmererne i utviklingsgruppen melder seg nå på de oppgaver de har lyst til å utføre. Ingen blir altså pådyttet oppgaver, men alle oppgaver må ha en ansvarlig og må løses innenfor iterasjonen. Programmereren lager et estimat for oppgaven, gjerne i timer. Estimatene for alle oppgaver summeres og sammenholdes med lengden av iterasjonen. Hvis det blir for mye arbeid, må kunden velge hva som skal realiseres innenfor denne iterasjonen og hva som eventuelt skal overføres til neste eller senere iterasjoner. Hvis det er ledig tid, sørger kunden for å få frem flere fortellinger. Man praktiserer her strengt prinsippet om fordeling av ansvar kunden bestemmer hva som skal lages og når. Rammene settes av de estimater som programmererne lager. Programmererne har ansvaret for å velge implementasjonsstrategi. Utvikling Programmererne utvikler koden for iterasjonen. Skrivingen foregår ved at programmerere arbeider i par. Et par kan jobbe sammen i noen timer. Deretter kan de bytte makker. Par dannes når en programmerer som har ansvar for en oppgave ber om hjelp. Den som blir spurt, kan ikke si nei. Før kode skrives lager paret sammen en test som skal vise om koden fungerer riktig. Deretter skrives koden. En test/utvikle-episode er meget kort. Den tar fra fem til ti minutter. Programmererne følger disse enkle reglene: Tenk ikke på gjenbruk i andre fortellinger. Skriv bare den kode som er nødvendig for å få gjennom den aktuelle oppgaven. Gjør hyppige refaktoreringer slik at koden blir så ren og enkel som mulig. Det er ikke tillatt å duplisere kode. Hvis det har skjedd, må koden abstraheres f. eks i en egen klasse eller funksjon. Integrasjon gjøres hyppig, minst en gang per dag eller helst oftere. Programmerere eier ikke koden de skriver eller modifiserer. Ethvert par kan sjekke ut og modifisere en modul når de finner grunn til det. Det er ikke tillatt å arbeide to eller flere uker overtid i strekk Lesestoff Stoff til denne leksjonen finner dere i kapittel 2 og 40. De som vil trenge dypere inn i UP kan lese boken til Jacobson (Jacobson m.fl., 1999). En bok som gir en introduksjon til UP er The Rational Unified Process An Introduction (Kruchten, 2004). Den grunnleggende boken for de som vil vite mer om XP er boken til Kent Beck (Beck, 2000). 7

8 1.8. Litteratur Jacobson, Ivar; Booch, Grady; Rumbaugh, James 1999: The unified software development process. USA: Addison-Wesley. Kruchten, Philippe, 20004: The Rational Unified Process An Introduction,Tredje utgave. USA: Addison-Wesley. Beck, Kent 2000: Extreme programming explained. Embrace change. USA: Addison-Wesley. Opphavsrett: Forfatter og Stiftelsen TISIP

Inception Elaboration Construction Transition Bemanning 1 1,5 2 2 Varighet i uker Antall iterasjoner (lengde i uker i parentes) Tabell 1

Inception Elaboration Construction Transition Bemanning 1 1,5 2 2 Varighet i uker Antall iterasjoner (lengde i uker i parentes) Tabell 1 Innhold Innledning... 2 Faseplan... 2 Iterasjonsplanlegging... 3 Oppstartsfasen... 3 Artefaktene i oppstartsfasen... 4 Utdypingsfasen... 5 Konstruksjonsfasen... 5 Overføringsfasen... 6 Litteratur... 7

Detaljer

HiST/AITeL - RAPPORT 20O6: 2 Avdeling for informatikk og e-læring Høgskolen i Sør-Trondheim. utviklingsmodeller

HiST/AITeL - RAPPORT 20O6: 2 Avdeling for informatikk og e-læring Høgskolen i Sør-Trondheim. utviklingsmodeller HiST/AITeL - RAPPORT 20O6: 2 Avdeling for informatikk og e-læring Høgskolen i Sør-Trondheim utviklingsmodeller ISBN 82-7877-137-5 ISSN 1504-5587 HiST/AITeL - RAPPORT 2 Trondheim 2006 av Tore Berg Hansen

Detaljer

UKEOPPGAVER 2: SYSTEMUTVIKLINGSPROSESSER OG PROSJEKTARBEID INNSPILL TIL SVAR

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

Detaljer

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

Hensikten med denne delen av kurset. Objektets egenskaper. Objektorientering hva er det? Best practises ved programvareutvikling. Kravspesifikasjonen Hensikten med denne delen av kurset Objektorientert systemutvikling Rational Unified Process (RUP) Gurholt og Hasle kap. 6 UML Distilled kap. 2 Å lære modellerings- og designprinsipper og øve opp teknikker

Detaljer

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

Kompleksitetsanalyse Helge Hafting 25.1.2005 Opphavsrett: Forfatter og Stiftelsen TISIP Lærestoffet er utviklet for faget LO117D Algoritmiske metoder

Kompleksitetsanalyse Helge Hafting 25.1.2005 Opphavsrett: Forfatter og Stiftelsen TISIP Lærestoffet er utviklet for faget LO117D Algoritmiske metoder Helge Hafting 25.1.2005 Opphavsrett: Forfatter og Stiftelsen TISIP Lærestoffet er utviklet for faget LO117D Algoritmiske metoder Innhold 1 1 1.1 Hva er en algoritme?............................... 1 1.2

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

UNIVERSITETET I OSLO

UNIVERSITETET I OSLO Bokmål Kandidat nummer: UNIVERSITETET I OSLO Det matematisk-naturvitenskapelige fakultet Prøveeksamen i: INF1050 Eksamensdag: 0. mai, 2011 Tid for eksamen: 00:00 00:00 Oppgavesettet er på 6 sider Vedlegg:

Detaljer

Om prosesser 1. Om prosesser

Om prosesser 1. Om prosesser Tore Berg Hansen 27.1.2004 Opphavsrett: Forfatter og Stiftelsen TISIP Lærestoffet er utviklet for faget LV339D Objektorientert systemutvikling 1. Resymé: Denne leksjonen handler om utviklingsprosesser.

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

Prosessmodeller og smidig programvareutvikling. INF1050: Gjennomgang, uke 02

Prosessmodeller og smidig programvareutvikling. INF1050: Gjennomgang, uke 02 Prosessmodeller og smidig programvareutvikling INF1050: Gjennomgang, uke 02 Kompetansemål Prosessmodeller Kunne redegjøre for hva som kjennetegner ulike prosessmodeller Vurdere prosesser for utvikling

Detaljer

Hva gjøres i analysen? 2. oktober 2001, Tore Berg Hansen, TISIP

Hva gjøres i analysen? 2. oktober 2001, Tore Berg Hansen, TISIP Hva gjøres i analysen? 2. oktober 2001, Tore Berg Hansen, TISIP Kursleksjonene er forfatters eiendom. Som kursdeltaker kan du fritt bruke leksjonene til eget personlig bruk. Kursdeltakere som ønsker å

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

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

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

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

1. Leksjon 01: Introduksjon til faget Prosjektrettet systemarbeid

1. Leksjon 01: Introduksjon til faget Prosjektrettet systemarbeid Avdeling for informatikk og e-læring, Høgskolen i Sør-Trøndelag Leksjon 01: Introduksjon til faget Prosjektrettet systemarbeid Greta Hjertø og Tore Berg Hansen 30.08.2005 Revidert av Kjell Toft Hansen

Detaljer

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

Systemutviklingen er ferdig når et system er operativt. Med operativt menes når systemet blir brukt av brukerne på et faktisk arbeidssted. Presentasjon nummer 5 The changing system and the nature of maintenance Silde 1 Gruppen introduseres Slide 2 The changing system and the nature of maintenance The Changing system Systemutviklingen er ferdig

Detaljer

prosjektarbeid Forelesning 3 - INF1050 Systemutvikling

prosjektarbeid Forelesning 3 - INF1050 Systemutvikling Systemutviklingssprosesser, prosjektarbeid Forelesning 3 - INF1050 Systemutvikling 28.1.2009 Rune Steinberg International Development Manager ERP INF1050 Systemutvikling Vår 2009 - Copyright Rune Steinberg

Detaljer

prosjektarbeid Forelesning 3 - INF1050 Systemutvikling Eksempel Evolusjonære modeller Utviklingsprosesser Evolusjonære modeller Foranalyse

prosjektarbeid Forelesning 3 - INF1050 Systemutvikling Eksempel Evolusjonære modeller Utviklingsprosesser Evolusjonære modeller Foranalyse Evolusjonære modeller Foranalyse Systemutviklingssprosesser, prosjektarbeid Forelesning 3 - INF1050 Systemutvikling 28.1.2009 Rune Steinberg International Development Manager ERP Iterasjonsplan Iterasjon

Detaljer

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

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

Detaljer

Snake Expert Scratch PDF

Snake Expert Scratch PDF Snake Expert Scratch PDF Introduksjon En eller annen variant av Snake har eksistert på nesten alle personlige datamaskiner helt siden slutten av 1970-tallet. Ekstra populært ble spillet da det dukket opp

Detaljer

UKE 9 Prosesser og prosessmodeller inkludert smidige metoder. Gruppetime INF1055

UKE 9 Prosesser og prosessmodeller inkludert smidige metoder. Gruppetime INF1055 UKE 9 Prosesser og prosessmodeller inkludert smidige metoder Gruppetime INF1055 Hva skal vi i dag? Introduksjon til modul B - systemutvikling (kap. 1, 2 og 3) Prosesser og prosessmodeller + smidig utvikling

Detaljer

1. Om prosesser. Avdeling for informatikk og e-læring, Høgskolen i Sør-Trøndelag Om prosesser Tore Berg Hansen

1. Om prosesser. Avdeling for informatikk og e-læring, Høgskolen i Sør-Trøndelag Om prosesser Tore Berg Hansen Avdeling for informatikk og e-læring, Høgskolen i Sør-Trøndelag Om prosesser Tore Berg Hansen Lærestoffet er utviklet for faget IFUD1019 Objektorientert systemutvikling 1. Om prosesser Resymé: Denne leksjonen

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

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

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

Prosjektledelse - fra innsiden

Prosjektledelse - fra innsiden Prosjektledelse - fra innsiden Presentasjon hos UiO 31.08.2012 Ida Lau Borch, fagansvarlig i Metier AS Det ligger et fantastisk potensial i det å være best i prosjektledelse og -styring Prosjekteierstyring

Detaljer

1. Å lage programmer i C++

1. Å lage programmer i C++ Avdeling for informatikk og e-læring, Høgskolen i Sør-Trøndelag Å lage programmer i C++ Tore Berg Hansen og Else Lervik Rividert siste gang 24. august 2006 1. Å lage programmer i C++ Resymé: Dette notatet

Detaljer

Steg 1: Streken. Steg 2: En hoppende helt. Sjekkliste. Sjekkliste. Introduksjon. Hei der! Hoppehelt

Steg 1: Streken. Steg 2: En hoppende helt. Sjekkliste. Sjekkliste. Introduksjon. Hei der! Hoppehelt Hei der! Hoppehelt Ser ut som dette er ditt første besøk, vil du ha en omvisning? Ekspert Scratch PDF Introduksjon Hoppehelt er litt inspirert av musikkspillet Guitar Hero. I Hoppehelt skal man kontrollere

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

TESTRAPPORT Tittel på hovedprosjektet: Varebestillingssystem for Wokas Salg AS

TESTRAPPORT   Tittel på hovedprosjektet: Varebestillingssystem for Wokas Salg AS TESTRAPPORT Tittel på hovedprosjektet: Varebestillingssystem for Wokas Salg AS Medlemmer av gruppe 35: Joakim Larsen, s150070, 3AB Kristian Kjelsrud, s147787, 3IA Anastasia Poroshina, s140720, 3AB Prosjektperiode:

Detaljer

Hva gjøres i design? 19. september 2002, Tore Berg Hansen, TISIP

Hva gjøres i design? 19. september 2002, Tore Berg Hansen, TISIP Hva gjøres i design? 19. september 2002, Tore Berg Hansen, TISIP Kursleksjonene er forfatters eiendom. Som kursdeltaker kan du fritt bruke leksjonene til eget personlig bruk. Kursdeltakere som ønsker å

Detaljer

Systemutviklingssprosesser, prosjektarbeid Forelesning 3 - INF1050 Systemutvikling 1. feb.2010

Systemutviklingssprosesser, prosjektarbeid Forelesning 3 - INF1050 Systemutvikling 1. feb.2010 Systemutviklingssprosesser, prosjektarbeid Forelesning 3 - INF1050 Systemutvikling 1. feb.2010 Arne Maus, Ifi med takk til Gerhard Skagstein(Ifi), Rune Steinberg, (Visma), Jo Hannay (Ifi), Ian Sommerville

Detaljer

Systemutviklingsprosesser Forelesning 2 - INF1050 Systemutvikling

Systemutviklingsprosesser Forelesning 2 - INF1050 Systemutvikling Systemutviklingsprosesser Forelesning 2 - INF1050 Systemutvikling 21.1.2009 Rune Steinberg International Development Manager ERP INF1050 Systemutvikling Vår 2009 - Copyright Rune Steinberg 2009 1 Innledning

Detaljer

Systemutviklingsprosesser Forelesning 2 - INF1050 Systemutvikling

Systemutviklingsprosesser Forelesning 2 - INF1050 Systemutvikling Innledning Læringsmål Systemutviklingsprosesser Forelesning 2 - INF1050 Systemutvikling 21.1.2009 Forstå hvorfor systemutviklingsprosessen er viktig Forstå de viktigste prinsippene for ulike prosesser

Detaljer

Om prosesser 21. august 2002, Tore Berg Hansen, TISIP

Om prosesser 21. august 2002, Tore Berg Hansen, TISIP Om prosesser 21. august 2002, Tore Berg Hansen, TISIP Kursleksjonene er forfatters eiendom. Som kursdeltaker kan du fritt bruke leksjonene til eget personlig bruk. Kursdeltakere som ønsker å bruke leksjonene

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

Denne teksten er en oversettelse av en originaltekst fra ThinkerSmith, og er lisensiert i henhold til retningslinjene nederst på siden.

Denne teksten er en oversettelse av en originaltekst fra ThinkerSmith, og er lisensiert i henhold til retningslinjene nederst på siden. Mine Robotvenner Uten datamaskin Denne teksten er en oversettelse av en originaltekst fra ThinkerSmith, og er lisensiert i henhold til retningslinjene nederst på siden. Mine Robotvenner introduserer elevene

Detaljer

Hoppehelt. Introduksjon. Steg 1: Streken. Sjekkliste. Skrevet av: Geir Arne Hjelle

Hoppehelt. Introduksjon. Steg 1: Streken. Sjekkliste. Skrevet av: Geir Arne Hjelle Hoppehelt Skrevet av: Geir Arne Hjelle Kurs: Scratch Tema: Blokkbasert, Spill Fag: Matematikk, Programmering, Kunst og håndverk Klassetrinn: 5.-7. klasse, 8.-10. klasse Introduksjon Hoppehelt er litt inspirert

Detaljer

Forelesning 30: Kompleksitetsteori

Forelesning 30: Kompleksitetsteori MAT1030 Diskret Matematikk Forelesning 30: Kompleksitetsteori Roger Antonsen Institutt for informatikk, Universitetet i Oslo Forelesning 30: Kompleksitetsteori 19. mai 2009 (Sist oppdatert: 2009-05-19

Detaljer

Kravspesifikasjon. Dagens forelesning. Mal for kravspesifikasjon. Hvordan finne fram til kravene? Kravspesifikasjon og objektorientert analyse

Kravspesifikasjon. Dagens forelesning. Mal for kravspesifikasjon. Hvordan finne fram til kravene? Kravspesifikasjon og objektorientert analyse Dagens forelesning Kravspesifikasjon Kravspesifikasjon og objektorientert analyse Hva skal systemet gjøre? Hvem og hva påvirker krav? Motivasjon: Hvorfor trenger vi UML? Noen resultater fra et UML-eksperiment

Detaljer

System integration testing. Forelesning Systems Testing UiB Høst 2011, Ina M. Espås,

System integration testing. Forelesning Systems Testing UiB Høst 2011, Ina M. Espås, System integration testing Forelesning Systems Testing UiB Høst 2011, Ina M. Espås, Innhold Presentasjon Hva er integration testing (pensum) Pros og cons med integrasjonstesting Når bruker vi integration

Detaljer

Kravspesifikasjon. Kravspesifikasjon. Mal for kravspesifikasjon. Hvordan finne fram til kravene? Hva skal systemet gjøre? Hvem og hva påvirker krav?

Kravspesifikasjon. Kravspesifikasjon. Mal for kravspesifikasjon. Hvordan finne fram til kravene? Hva skal systemet gjøre? Hvem og hva påvirker krav? Kravspesifikasjon Kravspesifikasjon Erik Arisholm Simula Research Laboratory & Institutt for Informatikk Hva skal systemet gjøre? Hvem og hva påvirker krav? Motivasjon: Hvorfor trenger vi UML? o Noen resultater

Detaljer

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

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

Detaljer

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

STATUSRAPPORT 3: Produksjon av nettside for Skjerdingen Høyfjellshotell.

STATUSRAPPORT 3: Produksjon av nettside for Skjerdingen Høyfjellshotell. statusrapport 2 I produksjon av webside for skjerdingen høyfjellshotell STATUSRAPPORT 3: Produksjon av nettside for Skjerdingen Høyfjellshotell 1 29. APRIL 2010 http://hovedprosjekter.hig.no/v2010/imt/mp/skjerdingen

Detaljer

Kravdokument Innholdsfortegnelse 1 Innledning 2 Bakgrunn og oversikt 3 Detaljerte krav 4 Systemsekvensdiagram

Kravdokument Innholdsfortegnelse 1 Innledning 2 Bakgrunn og oversikt 3 Detaljerte krav 4 Systemsekvensdiagram Kravdokument Innholdsfortegnelse 1 Innledning 1.1 Avgrensning 1.2 Definisjoner og forkortelser 1.3 Referanser 1.4 Oversikt over innholdet 2 Bakgrunn og oversikt 2.1 Use-case UML-diagram 2.1.1 Oversiktsdiagram

Detaljer

Arne Maus, Ifi. med takk til Gerhard Skagstein(Ifi), Rune Steinberg, (Visma), Jo Hannay (Ifi), Ian Sommerville m. fl. for lån av gamle foiler

Arne Maus, Ifi. med takk til Gerhard Skagstein(Ifi), Rune Steinberg, (Visma), Jo Hannay (Ifi), Ian Sommerville m. fl. for lån av gamle foiler Evolusjonære modeller Systemutviklingssprosesser, prosjektarbeid Forelesning 3 - INF1050 Systemutvikling 1. feb.2010 Foranalyse Iterasjonsplan Iterasjon 1 Analyse og Design Arne Maus, Ifi med takk til

Detaljer

Oppgave 1. Finn krav. Finn krav. Finn test

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

Detaljer

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

Konfigurasjonsstyring

Konfigurasjonsstyring INF1050: Systemutvikling 28. mars 2017 Konfigurasjonsstyring Yngve Lindsjørn ynglin@ifi.uio.no INF1050 Systemutvikling ->Konfigurasjonsstyring 1 Temaer i dagens forelesning Versjonshåndtering Systembygging

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

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

1. Å lage programmer i C++

1. Å lage programmer i C++ Avdeling for informatikk og e-læring, Høgskolen i Sør-Trøndelag Å lage programmer i C++ Tore Berg Hansen og Else Lervik Rividert siste gang 29. august 2005 1. Å lage programmer i C++ Resymé: Dette notatet

Detaljer

UML-Unified Modeling Language

UML-Unified Modeling Language UML-Unified Modeling Language Use case realisering Designmodellering 21.01.2004 Kirsten Ribu Use Case diagram Klassediagram Oppførselsdiagrammer: Sekvensdiagram Kollaborasjonsdiagram Tilstandsdiagram Aktivitetsdiagram

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

Kundesamtale teste hypoteser

Kundesamtale teste hypoteser Kundesamtale teste hypoteser 1 Forberedelser: Lean Business Modell (forretningsideen) Hvem vil ha problemet / Målgruppen som du tror har problemet Problem: De problemene vi antar at kundene har Samt en

Detaljer

AlgDat 10. Forelesning 2. Gunnar Misund

AlgDat 10. Forelesning 2. Gunnar Misund AlgDat 10 Forelesning 2 Oversikt Java repetisjon IDE eller teksteditor + kommandolinje? Java Collections and Generics Programvareutvikling En mengde mer eller mindre veldefinerte metoder (software engineering):

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

Ulike typer prosessmodeller. Systemutvikling. Utviklingsmodeller. Prosessmodell - faser

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

Detaljer

Web Service Registry

Web Service Registry BACHELORPROSJEKT 21 Web Service Registry Prosjektpresentasjon Ola Hast og Eirik Kvalheim 05.05.2010 Dette dokumentet er en kort presentasjon av bachelorprosjektet Web Service Registry Innhold 1. Om oppgavestiller...

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

Bygg et Hus. Steg 1: Prøv selv først. Sjekkliste. Introduksjon. Prøv selv

Bygg et Hus. Steg 1: Prøv selv først. Sjekkliste. Introduksjon. Prøv selv Bygg et Hus Introduksjon I denne leksjonen vil vi se litt på hvordan vi kan få en robot til å bygge et hus for oss. Underveis vil vi lære hvordan vi kan bruke løkker og funksjoner for å gjenta ting som

Detaljer

MAT1030 Forelesning 28

MAT1030 Forelesning 28 MAT1030 Forelesning 28 Kompleksitetsteori Roger Antonsen - 12. mai 2009 (Sist oppdatert: 2009-05-13 08:12) Forelesning 28: Kompleksitetsteori Introduksjon Da er vi klare (?) for siste kapittel, om kompleksitetsteori!

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

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

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

TDT4102 Prosedyreog objektorientert programmering Vår 2016

TDT4102 Prosedyreog objektorientert programmering Vår 2016 Norges teknisk naturvitenskapelige universitet Institutt for datateknikk og informasjonsvitenskap TDT4102 Prosedyreog objektorientert programmering Vår 2016 Øving 4 Frist: 2016-02-12 Mål for denne øvingen:

Detaljer

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

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

Detaljer

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

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

CRIStin 2.0 Om videreutvikling av CRIStin-systemet. Oppstartseminar 22. Oktober 2013

CRIStin 2.0 Om videreutvikling av CRIStin-systemet. Oppstartseminar 22. Oktober 2013 CRIStin 2.0 Om videreutvikling av CRIStin-systemet Oppstartseminar 22. Oktober 2013 CRIStin og de gode hjelperne Mål for CRIStin-systemet Nav i norsk forskning Gi oversikt og pekere til mer detaljer Koblinger

Detaljer

Systemutvikling. Universitetet i Oslo, Institutt for informatikk Vår 2017

Systemutvikling. Universitetet i Oslo, Institutt for informatikk Vår 2017 Systemutvikling Universitetet i Oslo, Institutt for informatikk Vår 2017 Dagens plan Introduksjon Emnets oppbygging Praktisk om ukesoppgaver og obligatoriske oppgaver Gjennomgang av ukesoppgaver Registrering

Detaljer

Software Development Plan. Software Development Plan. Forum / Nettverkssamfunn Team 2

Software Development Plan. Software Development Plan. Forum / Nettverkssamfunn Team 2 Forum / Nettverkssamfunn Team 2 1 Innholdsfortegnelse 1 Introduksjon... 3 2 Team & Organisering... 3 3 Brainstorming, tanker og utførelse... 4 3.1 Bruker Registrering og metoder... 4 3.2 Generering av

Detaljer

Forskningsmetoder i informatikk

Forskningsmetoder i informatikk Forskningsmetoder i informatikk Forskning; Masteroppgave + Essay Forskning er fokus for Essay og Masteroppgave Forskning er ulike måter å vite / finne ut av noe på Forskning er å vise HVORDAN du vet/ har

Detaljer

Oppsummering av hovedområdene i kurset LO 135A Kirsten Ribu

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

Detaljer

1. Normalisering Kommentarer til læreboka

1. Normalisering Kommentarer til læreboka Tore Mallaug 6.11.2007 Opphavsrett: Forfatter og Stiftelsen TISIP Lærestoffet er utviklet for fagene LN323D Databaser 1. Resymé: Denne leksjonen viser et eksempel på normalisering av en liten database.

Detaljer

Kapittel 5 - Advanced Hypertext Model Kapittel 6 - Overview of the WebML Development Process

Kapittel 5 - Advanced Hypertext Model Kapittel 6 - Overview of the WebML Development Process INF 329 Web-teknologier Kapittel 5 - Advanced Hypertext Model Kapittel 6 - Overview of the WebML Development Process Navn: Bjørnar Pettersen bjornarp.ii.uib.no Daniel Lundekvam daniell.ii.uib.no Presentasjonsdato:

Detaljer

Presentasjon 1, Requirement engineering process

Presentasjon 1, Requirement engineering process Presentasjon 1, Requirement ing process Prosessodeller Hvorfor bruke prosessmodeller? En prosessmodell er en forenklet beskrivelse av en prosess En prosessmodell er vanligvis lagd ut fra et bestemt perspektiv

Detaljer

TDT4102 Prosedyre og Objektorientert programmering Vår 2014

TDT4102 Prosedyre og Objektorientert programmering Vår 2014 Norges teknisk naturvitenskapelige universitet Institutt for datateknikk og informasjonsvitenskap TDT4102 Prosedyre og Objektorientert programmering Vår 2014 Øving 10 Frist: 2014-04-11 Mål for denne øvinga:

Detaljer

Neste generasjon ERP-prosjekter

Neste generasjon ERP-prosjekter Neste generasjon ERP-prosjekter Jan-Olav Arnegård 27. okt 2016 Nøkkeltall 2015 22 Land der vi er direkte representert 36 BearingPoint-kontorer 67 Kontorer der vi er representert via vår globale alliansepartnere

Detaljer

Forslag til løsning. Oppgave 1

Forslag til løsning. Oppgave 1 Forslag til løsning Eksamen 2003 Oppgave 1 A) Lag en Business Model (COMET) for krisehåndteringssystemet. B) Diskuter fordeler og ulemper ved bruk av COMET i forhold til (Rational) Unified Process for

Detaljer

1. Datamodellering. 1.1. Kommentarer til læreboka

1. Datamodellering. 1.1. Kommentarer til læreboka Tore Mallaug 20.10.2009 Opphavsrett: Forfatter og Stiftelsen TISIP Lærestoffet er utviklet for fagene LN323D Databaser 1. Datamodellering Resymé: Denne leksjonen viser et par eksempler på ER-modellering

Detaljer

Fire kort. Mål. Gjennomføring. Film. Problemløsing Fire kort

Fire kort. Mål. Gjennomføring. Film. Problemløsing Fire kort Fire kort Mål Generelt: Søke etter mønster og sammenhenger. Gjennomføre undersøkelse og begrunne resultat. Utfordre elevene på å resonnere og kommunisere. Spesielt: Finne alle kombinasjoner når de adderer

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

Fire kort. Mål. Gjennomføring. Film. Problemløsing Fire kort

Fire kort. Mål. Gjennomføring. Film. Problemløsing Fire kort Fire kort Mål Generelt: Søke etter mønster og sammenhenger. Gjennomføre undersøkelse og begrunne resultat. Utfordre elevene på å resonnere og kommunisere. Spesielt: Finne alle kombinasjoner når de adderer

Detaljer

Forskningsmetoder i informatikk

Forskningsmetoder i informatikk Forskningsmetoder i informatikk Forskning; Masteroppgave + Essay Forskning er fokus for Masteroppgave + Essay Forskning er ulike måter å vite / finne ut av noe på Forskning er å vise HVORDAN du vet/ har

Detaljer

CONNECTING BUSINESS & TECHNOLOGY KURS OG SERTIFISERINGER - SCRUM

CONNECTING BUSINESS & TECHNOLOGY KURS OG SERTIFISERINGER - SCRUM CONNECTING BUSINESS & TECHNOLOGY KURS OG SERTIFISERINGER - SCRUM Scrum Master og Product Owner i Høst 2015 1 Om Scrum Scrum er et populært rammeverk laget med henblikk på å utvikle komplekse informasjonssystemer.

Detaljer

GJENNOMGANG UKESOPPGAVER 13 KONTRAKTER

GJENNOMGANG UKESOPPGAVER 13 KONTRAKTER GJENNOMGANG UKESOPPGAVER 13 KONTRAKTER INF1050 V16 KRISTIN BRÆNDEN Kontrakter En kontrakt er en avtale som mellom partene etablerer en bindende forpliktelse til å gjøre eller å unnlate å gjøre noe Smidig

Detaljer

UML- Use case drevet analyse og design. Domenemodeller Sekvensdiagrammer Use case realisering med GRASP patterns Klassediagram - designmodeller

UML- Use case drevet analyse og design. Domenemodeller Sekvensdiagrammer Use case realisering med GRASP patterns Klassediagram - designmodeller UML- Use case drevet analyse og design Bente Anda 23.09.2004 23.09.04 INF320 I dag Domenemodeller Sekvensdiagrammer Use case realisering med GRASP patterns Klassediagram - designmodeller 23.09.04 INF320

Detaljer

1. Relasjonsmodellen. 1.1. Kommentarer til læreboka

1. Relasjonsmodellen. 1.1. Kommentarer til læreboka Avdeling for informatikk og e-læring, Høgskolen i Sør-Trøndelag Relasjonsmodellen Tore Mallaug 2.9.2013 Lærestoffet er utviklet for faget Databaser 1. Relasjonsmodellen Resymé: Denne leksjonen gir en kort

Detaljer

STE6221 Sanntidssystemer LØSNINGSFORSLAG TIL EKSAMEN

STE6221 Sanntidssystemer LØSNINGSFORSLAG TIL EKSAMEN HØGSKOLEN I NARVIK Avdeling for teknologi MSc.-studiet EL/RT Side 1 av 3 STE6221 Sanntidssystemer LØSNINGSFORSLAG TIL EKSAMEN Tid: Torsdag 09.03.2006, kl: 09:00-12:00 Tillatte hjelpemidler: Godkjent programmerbar

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

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

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

Forskning på gruppe-estimeringestimering

Forskning på gruppe-estimeringestimering Eksperiment: individuell vs gruppe-estimeringestimering Gruppe-estimering Tyve fagpersoner fra samme firma estimerte hver for seg arbeidsmengden for det samme systemutviklingsprosjektet [*] Deltakerne

Detaljer

Heggset Engineering er et kreativt og uavhengig kompetansemiljø med ti ingeniører/tekniske tegnere lokalisert i moderne lokaler i Dale Industripark i

Heggset Engineering er et kreativt og uavhengig kompetansemiljø med ti ingeniører/tekniske tegnere lokalisert i moderne lokaler i Dale Industripark i Heggset Engineering er et kreativt og uavhengig kompetansemiljø med ti ingeniører/tekniske tegnere lokalisert i moderne lokaler i Dale Industripark i Kristiansund. Bedriften tilbyr engineering og maskintekniske

Detaljer

HØGSKOLEN I SØR-TRØNDELAG

HØGSKOLEN I SØR-TRØNDELAG HØGSKOLEN I SØR-TRØNDELAG Avdeling for informatikk og e-læring - Kandidatnr: AITeL Eksamensdato: 4.mai 2011 Varighet: 0900-1300 Emnekode: Emnenavn: Klasser: LV195D Objektorientert programmering i C++ Nettstudenter

Detaljer

Kommentarer til eksempelinnleveringene

Kommentarer til eksempelinnleveringene Kommentarer til eksempelinnleveringene Det er lagt ut 4 eksempelinnleveringer, en som er nesten perfekt og får 100 poeng uten opprunding. De andre 3 er kommentert i detalj her. Merk at tilbakemeldingene

Detaljer