Et lite kompendium i Systemutvikling

Størrelse: px
Begynne med side:

Download "Et lite kompendium i Systemutvikling"

Transkript

1 Et lite kmpendium i Systemutvikling Kapittel Utviklingsprsesser kapittel Fssefall... 4 Prttyping... 5 Inkrementell utvikling... 5 RAD... 5 Spiralmdellen Kapittel Nye algritmiske mdeller... 6 Walstne g Felix... 6 COCOMO... 7 Funksjnspunkter... 7 COCOMO II... 8 Kst / nytte analyse Eksempel Kalendertid Eksempel Kapittel Risikstyring Prsjektplanlegging Fwler kapittel Inceptin Elabratin Kravrisik Klassediagram Aktivitetsdiagram Interaksjnsdiagram Mer m kravrisik Pakker Tilstandsdiagrammer Mer m kravrisik Teknlgisk risik Kunnskapsrisik Plitisk risik Når er Elabratin ferdig Knstruksjnsfasen Planlegging Knstruksjn Transisjn Kapittel Partisjnstesting Testing g utvikling Manuelle testteknikker Dekningsbaserte testteknikker Feilbasert testing Nen egenskaper ved testkriterier Tp-Dwn vs. Bttm-Up kapittel Finne/ekstrahere/ppdage krav Teknikker fr å finne krav Intervju Taskanalyse Use case analyse Dmeneanalyse Prttyping Dkumentasjn av krav KS dkumentet Naturlig språk... 29

2 ER diagrammer Tilstandsdiagrammer SADT diagrammer Ikke-funksjnelle krav Rammeverk Fwler kapittel Fri frmat tekst Diagram Strukturert tekst kapitel O-O analyse g design Ntasjn Klassediagram Tilstandsdiagram Sekvensdiagram Samarbeidsdiagrammer O-O analyse g design Metder Bch metden OMT metden Fusjnsmetden Nen generelle kmmentarer Fwler kapittel Asssiasjner Attributter Operasjner Generalisering Oppsummering Fwler kapittel Sekvensdiagrammer Samarbeidsdiagrammer CRC krt Fwler kapittel Pakker Samarbeid i pakker Nen gde råd Fwler kapittel Guard g aktivitet Supertilstander Genererte hendelser Parallelle tilstandsdiagrammer Nen gde råd kapittel Evaluering av en arkitektur Endringer i data Endringer i algritmer Endringer i funksjnalitet Separat utvikling av mduler Frstålighet Ytelse Gjenbruk Beskrivelse av arkitekturer Designmønster pattern Kapittel Hva er en gd design Abstraksjn Mdularitet Infrmasjnsskjuling Kmpleksitet Systemstruktur Designmetder Funksjnsdekmpsisjn... 52

3 Dataflytbasert design Design basert på datastrukturer JSP Valg av designmetde Ntasjner Dkumentasjn av design Kapittel Reverse engineering Ledelsens rlle Vedlikehld sm en tjeneste Kntrll med vedlikehld Kapittel Perspektiver på kvalitet Kvalitetssystemer Kvalitetsystemer fr prgramvare Kapittel Bibliteker Maler Design Arkitektur Gjenbruk g livssyklus Utvikling med gjenbruk Utvikling fr gjenbruk Beskrivelsesspråk Utvikling av gjenbruk Ikke-tekniske prblemer Ledelse Øknmi Prsjektregnskap Kapittel Feiltleranse Pålitelighet Basis mdell - BM Lgaritmisk Pissn mdell LPM Bruk av mdellene Til diskusjn Kapittel Grunnleggende begreper Knfigurasjnsplan Diskusjnstema Kapittel Ledelsesstil Prsjektrganisering Hierarkisk rganisasjn Matriserganisasjn Chief prgrammer rganisasjn SWAT Åpen struktur Nen gde råd Kapittel Verktøysett - Unix Språkavhengig mgivelser Verktøybenk Prsessentrerte mgivelser Sluttkmmentarer... 82

4 01-14 Kapittel 2 Nen viktige årsaker til fr sein levering: Prgrammerer ga feilaktig status fr egen kdeutvikling Arbeidet var underestimert blir frelest Dårlig eller ufullstendig planlegging blir frelest Ingen versikt ver prsjektstatus Lavere prduktivitet enn frventet / planlagt Kunden visste ikke hva han ønsket blir frelest Viktig å være klar ver at prgramvare ikke blir utviklet alene det er alltid mer rundt sm fr eksempel brukere, prsedyrer fr bruk, maskinvare g dkumentasjn. Alt dette må være på plass fr å få gjrt de ppgavene sm systemet er tiltenkt. Husk. Ingen kjøper et datasystem frdi de gjerne vil ha et datasystem. De kjøper et datasystem frdi de ønsker å få løst et prblem eller utført en ppgave. Mister vi det av synet blir resultatet misfrnøyde kunder. Vis fig 2.1. Vi må starte med planlegging. Når prsjekter går galt g det gjør de inne imellm så ligger mye av årsaken i dårlig planlegging. Hva bør være med i planleggingen: Prsessmdell hvrdan skal vi utvikle. Dette skal vi se på senere Prsjektrganisasjn. Standarder, retningslinjer g prsedyrer. Vi skal se på ne av dette senere Ledelsesaktiviteter Risikanalyse. Dette skal vi se på senere Persnell Metder g teknikker. Vi skal se på mye av dette senere. Kvalitetssikring. Vi kmmer ikke til å si så mye m dette. Det er et eget kurs sm behandler mrådet. Arbeidspakker. Skal snakke m dette under prsjektplanlegging Budsjett g tidsplan. Blir behandlet under planlegging Endringer g endringsplanlegging Leveranse Utviklingsprsesser kapittel 3 Fr å kntrllere prsjekter deler vi de pp i faser g aktiviteter. Skal se på flere mdeller: Fssefall Prttyping Inkrementell utvikling RAD Spiralmdellen Fssefall Fig 3.1. hvedfrmålet er eventuelt var å unngå å kaste brt arbeid. Dette skulle ppnåes ved å fkusere på å ha en slid ( frsset ) kravspesifikasjn. Mdellen legger vekt på at hver fase blir avslutta med et dkumentert resultat kravspesifikasjn, verrdnet design dkument sv. Hvedprblemene sm gjør at mdellen i sin rendyrkede frm sjelden blir brukt - er at: Stre prblemer hvis kunden har tatt feil, gitt ufullstendig infrmasjn eller bare frandrer mening. Det er vanskelig å gjøre ferdig fr eksempel all design før man begynner å kde. Prsessen detaljert design kde er i seg selv iterativ. Vi ser fr eksempel at ca. 34% av design blir gjrt i kdingsfasen g ca. 10% blir gjrt under integrasjnstesting. Tegn tabellen i fig. 3.2 på tavla g kmmenter.

5 Prttyping Dette er løsningen på prblemet med ufullstendig eller misfrstått kravspesifikasjn g kunder sm frandrer mening fte sm knsekvens av at de får mer kunnskap eller erfaring med systemet. Vi kan bruke prttyper på flere måter: Fr å frstå kundens krav vis fig 3.3 Fr å eksperimentere med en algritme eller løsning Prttyping kan gjøres billig ved å gjenbruke kmpnenter man allerede har, fr eksempel Excel g Access pluss litt lim fr å lage et enkelt lagerstyringssystem. Man kan gså bruke deler av systemer man har laget før fr å lage deler av den funksjnaliteten kunden etterspør. Vanligvis vil en prttyp ha dårligere ytelse g være vanskeligere å vedlikehlde pga. at kdekvaliteten jamt ver er dårligere mer uryddig kde. Dette kan avhjelpes med streng kvalitetskntrll, men dette vil gjøre hele prsessen tyngre g langt på vei gjøre prttypingen m til inkrementell utvikling eller til xp extreme prgramming, sm bka dessverre ikke behandler. De frdelene frfatteren beskriver med evlusjnær prttyping er gså relatert til xp. Ved å bare implementere det kunden ser han har behv fr vil man i nen tilfeller lage et system med mindre, men mer brukerretta funksjnalitet. Prttyping setter vanligvis større krav til utviklerne det er en jbb sm krever en gd del erfaring hvis det ikke skal bli fullstendig skjærereir, gså kalt write nly kde. Prsjekter sm bruker prttyping må huske på at dette ikke er en unnskyldning fr å kaste alle planer ver brd. Slike prsjekter må gså planlegges g styres. Inkrementell utvikling I denne utviklingsmetden er kravene kjent ved starten av prsjektet. Når systemet likevel leveres i inkrementer er det frdi kundene erfaringsmessig: Ikke helt vet hva de vil. I nen tilfeller leder dette til at systemet får fr mye funksjnalitet. Dette gjør systemene dyre g vanskelige å vedlikehlde. Endrer ppfatning etter sm tiden går de får mer erfaring de får erfaring med de delene av systemet de har fått levert ser nye muligheter Inkrementell utvikling vil vanligvis gjøres slik at man implementerer de viktigste funksjnene først. Etter hvert legger man til ny funksjnalitet g lar kundene prøve denne fr å se m den er nyttig. Dette setter grenser fr hvr lite et inkrement kan være det må gi kunden ny funksjnalitet. RAD RAD Rapid Applicaitn Develpment - har mye til felles med evlusjnær prttyping g inkrementell utvikling. I tillegg kmmer time bxing, sm ikke finnes i de andre metdene. En metde sm bruker time bxing har følgende egenskaper: Lengden på tidsbksen blir bestemt først dermed ligger leveringstiden fast. Hvis vi ppdager at vi ikke kan bli ferdige med det vi hadde planlagt innenfr tidsbksen fjerner vi ne funksjnalitet. Denne blir da verført til en annen tidsbks. RAD har fire faser i følgende rekkefølge: 1. Kravplanlegging 2. Brukerdesign 3. Knstruksjn 4. Idriftsetting Kravplanlegging g brukerdesign blir gjrt i samarbeid ned kunden. Til det bruker vi wrkshp er. Kravplanlegging JRP (Jint Requirement Planning). Her prøver man å bli enige m så mange sm mulig av kravene slik at de ikke må endres senere. I tillegg blir krava priritert.

6 Brukerdesign JAD (Jint Applicatin Design). Det er vanlig å ha t slike wrkshper. Første JAD første, initiell design av systemet, sm er basis fr en prttyp. Brukerne får denne fr å eksperimentere med. Andre JAD brukernes evaluering av prttypen fra første JAD. Ut fra dette lager vi den endelige designbeskrivelsen. Utviklingen av systemet skjer i en sekvens av tidsbkser sm lager evlusjnære prttyper. Disse blir evaluert av brukerne g utviklerne i felleskap ved slutten av hver tidsbks. Spiralmdellen Hvedideen i spiralmdellen er å utvikle prsjektet ved å: Identifisere de prblemene i prsjektet sm fr øyeblikket har den største tilhørende risik Finne løsninger på disse prblemene. Mdellen er derfr prblem / risik-drevet. Se fig 3.6. Selve prgramvareutviklingen fregår ved å lage et sett av prttyper sm brukes til å identifisere prblemer g kartlegge risik Kapittel 7 All kstnadsestimering kan sees fra t sider: Utviklerne g prsjektleder hva vil det kst ss. Selgerne hva skal vi ta sm utgangspunkt fr salget Det er uansett viktig å vite hva det kmmer til å kste g hvr lang tid det vil ta. Hvis vi ikke vet det så blir det vanskelig å planlegge prsjektet. Lærebka mener at det har katastrfale følger å bruke plitiske beslutninger når man estimerer. Hverdagen fr mange firmaer er nk fte annerledes. Det er flere hensyn enn de reint datafaglige sm spiller inn. Det etterfølgende er nen eksempler: Hva må vi by hvis vi skal få prsjektet. Hvis vi ikke får det, hva er alternativet? Har vi ne annet prduktivt arbeid å sette flk til eller må vi si pp flk g hvilke knsekvenser har det? Hvis vi får dette prsjektet, hvilke nye muligheter gir det ss g hva er de verdt? Vi må kmme på markedet med ne før knkurrenten ellers vil han ta en str del av markedet. Eller tilsvarende vi må ha ne å demnstrere på Hannvermessa. Selv m disse punktene er viktige må vi skille skarpt mellm t ting: Det vi vil selge prduktet fr Det sm det kster å utvikle det. Tilsvarende: Hva vil det kste å lage all funksjnaliteten vi har planlagt Hva vil det kste å få til en første versjn med nk funksjnalitet til at det er interessant fr kundene Generelt gjelder at de fleste kanskje alle estimeringsmdeller er det vi kan kalle bruttmdeller. Dette innebærer at selv m de tar utgangspunkt i linjer kde, antall skjermbilder eller liknende, så er alt det andre dkumentasjn, design, testing sv inkludert i sluttestimatet. Nye algritmiske mdeller Walstne g Felix Vis generell frm E = (a + b*kloc c )*(f(x 1, X 2, X n ). Frklar parameterne g hvrdan man kan kmme fram til tallverdier fr disse lineær regresjn fra tidligere prsjekter. De enkleste frmlene er den første versjnen av Walstne g Felix frmel: E = 5.2*KLOC På denne frmen vil første knstanten vise prduktiviteten i frm av månedsverk / 1000 linjer kde. b = 5.2 betyr derfr at vi har en prduktivitet på 0.19 * 1000 linjer = 190 linjer kde pr. månedsverk eller 9 10 linjer pr. dagsverk. De fleste av dere vet at dere skriver mye mer kde enn det på en dag gjerne nen hundre linjer, fr eksempel linjer kde pr. dagsverk. I et industrielt prsjekt vil imidlertid mesteparten av tida ikke gå med til

7 kding, men til interaksjn med kunder, design, dkumentasjn, dkumentgransking sv. 250 linjer kde pr dagsverk tilsvarer 5000 linjer kde - altså 5 KSLOC - pr månedsverk. Dette gir en knstant på 0.2 i stedet fr 5.2 sm Walstne g Felix bruker. Hvedprblemet med disse metdene er å finne brukbare estimater fr KLOC tidlig i prsessen.. Det vanligste er å bryte det planlagte systemet ned i prsedyrer / mduler g bruke erfaring fra tidligere systemer til å anslå KLOC fr hver prsedyre. Denne måten å estimere på tar ikke hensyn til at frskjellige prsedyrer eller subsystemer har ulik kmpleksitet g derfr vil kreve ulike mengder ressurser. Fr å ta hensyn til dette fant Walstne g Felix et sett med faktrer sm de mente hadde str påvirkning på prduktiviteten se fig Vis g kmmenter. De definerte en prduktivitetsindeks PC definert sm Abs(maks min) g derfra en vekt W = 0.5*lg(PC). Videre innførte de en X, gitt sm X = +1 fr mindre enn nrmalt, 0 fr nrmalt g -1 fr mer enn nrmalt. På den måten gir mer enn nrmalt lavere prduktivitetsindeks, mens nrmalt (0) gir ufrandret prduktivitet. Prduktivitetsindeksen er gitt sm I = Sum(X i W i ). Eksempel: Vi har anslått at vi trenger ca linjer kde. Den enkle mdellen gir ss da E = 5.2* sm gir E lik ca. 10 månedsverk. COCOMO Tar utgangspunkt i same frmen sm Walstne g Felix, men pererer med tre typer prsjekter: Organisk lite team med mye erfaring i kjente mgivelser. Vanligvis små prsjekter, b = 2.4, c = 1.05 Embedded stre beskrankninger gitt av mgivelsene, fr eksempel maskinvare, b = 3.6, c = 1.20 Semidetached mellmfrm mellm de t frgående, b = 3.0, c = 1.12 Selv m de alle bruker samme frmel vil knstantene a g c variere. Fr å ta hensyn til frskjeller i krav g kmpleksitet fr de enkelte mdulene innfører COCOMO et sett av kstnadsdrivere Xi. Den kmplette frmelen blir E = b*kloc c * Prd(X i ). Denne tabellen har ne til felles med den vi så tidligere. Vis tabellen fra COCOMO I. Kmmenter g regn gjennm et eksempel Funksjnspunkter Basere seg på et vlummål sm kan finnes ut fra brukergrensesnittet. De bruker følgende egenskaper: Antall input typer (I) gjelder bare input sm endrer data i en datastruktur, ikke input sm bare styrer prgrammets ppførsel. Hver type sm har et nytt frmat eller blir behandlet ulikt blir regnet med. Antall utput typer (O) samme frbehld sm ver. Antall spørsmålstyper (E) frespørsler til systemet m infrmasjn. Dette er spørsmål sm ikke frandrer data i prgrammet, fr eksempel valg i menyer. Antall interne lgiske filer (L). Vi bryr ss ikke m hvrdan filene er fysisk rganisert, men bare m antall lgiske filer. Antall grensesnitt mt andre applikasjner (F) bruk eller utveksling. Ujusterte funksjnspunkter UFP = 4I + 5O + 4E + 10L + 7F. De vektene vi har brukt her er nrmalverdier. Det er mulig å i stedet bruke ulike verdier fr m fr eksempel en inputtype er enkel, nrmal (gjennmsnittlig) eller kmpleks. Se fig 7.9 g eksemplet fr input type g antall dataelementer i fig Fr å ta hensyn til en del faktrer sm påvirker prsjektet fr eksempel data kmmunikasjn, distribuert funksjnalitet g krav til ytelse blir det beregnet en justeringsfaktr. Hver påvirkningsfaktr skal graderes på en skala fra 0 til 5. Summen av disse faktrene kalles DI (Degree f Influence) g vi finner en ttal justeringsfaktr gitt sm TCF = *DI. Derfra finner vi justerte funksjnspunkter sm UP = UFP*TCF. Det finns en tilsvarende estimeringsmetde sm bygger på use case punkter. Her teller man use case enheter i stedet fr funksjnspunkter. Metden er ny g det finnes lite erfaring med å bruke den. Vi vil derfr ikke gå inn på denne metden her. Eksempel: Antall input typer (I) - 5. Alle er enkle (3)

8 Antall utput typer (O) 5. T enkle (4) g t nrmale (5) Antall spørsmålstyper (E) 12. Tre enkle (3), t nrmale (4) g fem kmplekse (6) Antall interne lgiske filer (L) 8. Alle nrmale (10) Antall grensesnitt mt andre applikasjner (F) - 0 Dette gir UFP = 5*3 + (2*4 + 2*5) + (3*3 + 2*4 + 5*6) + 8*10 = 160 Data kmmunikasjn - 3 Distribuerte funksjner - 3 Ytelse - 0 Mye brukt - 1 Transaksjnsrate - 0 Online data input - 5 Sluttbruker effektivitet - 0 On-line ppdatering - 0 Kmpleks prsessering - 0 Gjenbruk - 0 Lett å installere - 4 Lett å drive / perere - 3 Flere installasjner - 1 Lett å endre 0 DI = 20 g TCF = * 20 = 0.85 FP = 160 * 0.85 = 136 Prduktivitet 0.1 FP pr dagsverk => E = 136 / 0.1 = 1360 dagsverk = 68 månedsverk eller 6.2 årsverk COCOMO II COCOMO II er en videreutvikling av COCOMO I. Den pererer med tre detaljeringsnivåer: Applicaitn cmpsitin mdell (APM), sm hvedsakelig er beregna fr prttyping. Tidlig design mdell, sm kan brukes når vi har en arkitektur design Pst arkitektur mdell, sm brukes fr utviklingen av prgramsystemet. Det er dette sm er den mdellen sm er en videreutvikling av COCOMO I. Fr APM går vi fram sm følger: 1. Finn antall skjermbilder, rapprter g 3GL kmpnenter i systemet. 2. Fr skjermbilder g rapprter må vi bestemme kmpleksitetsgraden sm enkel, middels eller vanskelig. Fr rapprter finnes det en tabell fr å anslå kmpleksiteten. 3. Bruk tabellen i fig 7.13 fr å finnes bjektpunktene fr hvert enkelt bjekt (ikke bjekt i OO betydning) 4. Summer bjektpunktene sm gir ss OP 5. Estimer gjenbruksprsenten g finn nye bjektpunkter sm: NOP = OP*(1 gjenbruksandelen) 6. Finn prduktiviteten fr bedriften: PROD = NOP / antall månedsverk. PROD vil avhenge av erfaring, verktøy sv g kan variere fra 4 til 50. Hver bedrift må finne sin PROD verdi. 7. Nødvendig kstnad er E = NOP / PROD Tidlig designmdell bruke UFP. Deretter blir UFP knvertert til SLOC (antall kildekdelinjer). Knverteringsfaktren vil avhenge av språk, mgivelser, måten man legger ut kden på etc. Nen typiske verdier er 128 linjer C g 29 linjer C++ per funksjnspunkt. Hver bedrift må finne sin egen knverteringsfaktr. Fr å finne det endelige estimatet bruker COCOMO II sju kstnadsdrivere:

9 En kmbinasjn av kravene til pålitelighet, databasestørrelse, prduktkmpleksitet g dkumentasjnsbehv. Gjenbruk samme sm fr pst arkitektur mdellen Plattfrm sm er en kmbinasjn av krav til eksekveringstid, lagerplass g erfaring med utviklingsverktøy Utviklernes erfaring med applikasjn, plattfrm g utviklingsverktøy Utviklernes dyktighet sm systemanalytikere, prgrammerere g hvr lenge de har vært i bedriften Utviklingsverktøy g gegrafisk spredning av prsjektet. Kravene til kalendertid Hver av disse sju kstnadsdriverne graders på en sjupunkts skala fra Ekstra lav til ekstra høy. Ut fra dette finner man er verdi fr hver kstnadsdriver sm multipliseres sammen fr å justere estimatet. Pst arkitektur mdellen er den samme sm COCOMO I brtsett fra t ting: Nen av kstnadsdriverne er frandret. Isteden fr å ha tre typer utvikling har den en krreksjnsfaktr sm bygger på et sett av skaleringsfaktrer sm kan ha verdier fra 0 (svært høy) til 5 (svært lav). Kstnadsdriverne er sm vist i fig Krreksjnsfaktren b blir beregnet ut fra følgende fem skaleringsfaktrer: 1. Graden av ukjent nytt arbeid, applikasjnsmråde etc. Alt nytt = 5, ingenting nytt = 0 2. Behvet fr å være knfrm med tidligere systemer. Bundet pp av gamle systemer = 5, helt fritt = I hvr str grad vi eliminert i bende risik i utviklingen g hvr mye av arkitekturen er spesifisert. Lite (20% eller mindre) = 5, alt = I hvr str grad fungerer prsjektteamet. Dårlig kmmunikasjn g samarbeid = 5, meget gdt samarbeid = Hvr mden er rganisasjnene når det gjelder planlegging, estimering g utvikling. Helt umden = 5, meget mden = 0. COCOMO II bruker CMM her, men har gså ei egen sjekkliste til dette bruket. VI finner da b = *Sum(W i ) g E = a*ksloc b *Prd(kstdrivere). Antall kdelinjer er her det tallet vi får ved å knvertere funksjnspunkter til kdelinjer. Vi kan ta hensyn til gjenbruk ved å justere anslaget fr antall linjer kde. I COCOMO antar man at man har følgende frdeling: Design. 40% - DM Kding (utvikling) 30% - CM Integrasjn av kmpnentene 30% - IM Man må så anslå hvr mye av systemet sm må designes, kdes g integreres på nytt. Ut fra dette får,man en ny krreksjnsfaktr AAF = 0.4DM + 0.3CM + 0.3IM. I COCOMO I nøyde man seg med dette. I COCOMO II ser man i tillegg på t andre frhld. SU sm tar hensyn til graden av mdularitet i kden. Dette er et tall varierer fra 0.10 til 0.50 fr meget ustrukturert, tett kblet kde. AA sm tar hensyn til innsatsen vi trenger fr å vurdere m kmpnenten er brukbar fr det planlagte systemet.

10 Vi kan nå finne et justert antall kdelinjer gitt sm AKLOC = KLOC * (AAF + SU + AA). Vi kan nå bruke ALOC i stedet fr KLOC i de frmlene vi har sett på tidligere. Kst / nytte analyse Når man har en kstnadsmdell sm fungerer gir frnuftige svar kan den brukes til å se på nytten av endringer i prsjekt, metder eller pplæring. Fra tabellen ver kstnadsdrivere i COCOMO II ser vi at faktren fr prgrammerernes kunnskap varierer fra 1.37 (dårligst kunnskap) til 0.74 (best kunnskap). Dette vil utgjøre en faktr 1.85 fra dårligste til beste prgrammerer. Har vi fr eksempel et prsjekt på 100 årsverk med dårlige prgrammerer kan vi redusere det til 54 årsverk ved å bruke de beste prgrammererne. Ett årsverk kster ca. 1 millin krner slik at besparelsen er på 46 milliner. Tilsvarende betraktninger kan gjøre fr andre faktrer fr eksempel kstnader ved en ekstra fil eller et ekstra skjermbilde. Eksempel Vi har et system med kstnadsdrivere sm vist i fig. Ut fra de vurderingene sm er gjrt finner vi at Prd(kstnadsdrivere) = 1 * 0.93 * 1 * 0.91 * 0.95 * 1.11 * 1 * 0.87 * 1.22 * 1 * 1.10 * 1 * 1.12 * 1 * 1.12 * 1.25 * 1 = 1.63 Fr å bestemme b ser vi på skaleringsfaktrene: 1. Graden av ukjent nytt arbeid, applikasjnsmråde etc. Alt nytt = 5, ingenting nytt = Behvet fr å være knfrm med tidligere systemer. Bundet pp av gamle systemer = 5, helt fritt = I hvr str grad vi eliminert i bende risik i utviklingen g hvr mye av arkitekturen er spesifisert. Lite (20% eller mindre) = 5, alt = I hvr str grad fungerer prsjektteamet. Dårlig kmmunikasjn g samarbeid = 5, meget gdt samarbeid = Hvr mden er rganisasjnene når det gjelder planlegging, estimering g utvikling. Helt umden = 5, meget mden = 0. COCOMO II bruker CMM her, men har gså ei egen sjekkliste til dette bruket. 5 b = *( ) = 1.15 I det frrige eksemplet fant vi UFP = 160. Hvis vi skal utvikle prduktet i C finner vi at dette tilsvarer kdelinjer g KSLOC = E = a * KSLOC b * Prd(kstnadsdrivere) gir ss 3* *1.63 = månedsverk eller 14 årsverk. Hvis vi bruker a = 0.2 sm eksempel på et studentprsjekt med studentkvalitet finner vi i stedet E = 10.5 månedsverk. Kalendertid De fleste estimeringsmdeller har en frmel sm gjør at man kan utlede kalendertid fra utviklingskstnader. Det er ikke slik at prsjektet må ta denne tiden det kan gdt ta lengre tid hvis vi vil det. Det er imidlertid vanskelig å få gjennmført prsjektet på krtere tid. Walstne g Felix: T = 2.5*E 0.35 COCOMO I rgansikk prsjekt T = 2.5*E *(b 1.01) COCOMO II nminell tid T = 3.0*E

11 Det er t hvedgrunner til at vi ikke kan krte ned på tida på et pågående prsjekt ved å sette inn flere flk: Mengden av nødvendig kmmunikasjn g krdinering øker. Dette krever tid. Når vi tar inn nye flk et prsjekt må de ha pplæring. Dette betyr at de ikke er spesielt prduktive den første tiden. I tillegg tar de ressurser fra prsjektet ved at de sm kjenner prsjektet må fungere sm veiledere fr de nyansatte. Data sm er samlet inn tyder på at prduktiviteten L antall linjer pr. månedsverk er avhengig av temastørrelsen P på følgende måte: L = 777*P Mange synes nk 777 linjer per månedsverk er lite. Dette tallet inkluderer imidlertid ikke bare kding, men gså verrdna design, detaljert design, integrasjn, alle typer dkumentasjn, prsjektmøter interne g med kunde g så videre. Mange bedrifter bruker lavere tall fr eksempel 200 linjer kde pr. månedsverk ttalt ver hele prsjektet. Eksempel I frrige eksempel fant vi at det prsjektet vi så på ville kreve 158 månedsverk. Fr COCOMO II vil dette gi en gjennmføringstid på T = 3.0* *( ). Dette gir ss T = 18.4 måneder. Dette tilsvarer en bemanning på fr eksempel 8 persner på full tid g en persn på deltid. Å sette på flere persner vil antakelig ikke være effektivt. Men bare føre til større kstnader. Studentprsjektet hadde 10.5 månedsverk g den samme frmelen gir i dette tilfellet T = 7 måneder Kapittel 8 Prsjektkntrll behandler tre elementer: Det vi skal kntrllere selve prsjektet Det sm kntrllerer prsjekt prsjektleder, den rganisasjnen han har bak seg g de reglene g metdene han bruker Den infrmasjnen han bruker til å styre sine beslutninger g dermed prsjektprsessen. Denne infrmasjnen kmmer fra t kilder: Fra prsjektet fr eksempel et ntat m et prblem sm har ppstått Fra prsjektets mgivelser fr eksempel rdre m å fjerne funksjnalitet, kutte kstnader eller levere tidligere. Fr å kunne kntrllere et prsjekt effektivt er det viktig å kjenne prsjektets mål. De fleste prsjekter har flere mål. Typiske prsjektmål kan være: Krtest mulig utviklingstid Mest mulig frnøyde kunder Mest mulig frnøyde sluttbrukere Mest mulig gjenbruk Mest mulig gjenbrukbar kde Størst mulig frtjeneste Det er ikke alltid mulig å ppfylle all prsjektets mål i like str grad. Nen ganger vil t eller flere mål til g med kunne være mtstridende fr eksempel gd vedlikehldbarhet g str tidseffektivitet. Nen ganger vil ledelsen være i stand til å priritere, andre ganger er det umulig å få til Alt er like viktig. Fr å få effektiv prsjektledelse må følgende betingelser være ppfylt. vi må Kjenne målene til prsjektet Ha tilstrekkelige virkemidler sm vi kan bruke slik vi mener det er nødvendig Kjenne prsjektets tilstand ressursfrbruk, hva er gjrt. Vite hvrdan en endring i prsjektets parametere påvirker resultatene g målene. Hvis vi hadde visst alt dette kunne prsjektledelse vært en enkel, rasjnell prsess. Antakelig kunne den vært helt eller delvis autmatisert. Dessverre er de fire betingelsene ver bare delvis ppfylt. Mulige prblemer er at vi ikke: Kjenner alle målene eller hvrdan de egentlig er priritert

12 Har tilstrekkelig med virkemidler. Vi er begrenset av lver (interne g eksterne), vi har de flkene vi har g kan ikke få nen andre, det er bare 24 timer i døgnet, flk kan bli syke eller tatt av prsjektet fr å gjøre ne sm haster mer brannslukking. Kjenner prsjektets tilstand. Det er vanskelig å vite hvr langt har X kmmet med mdul Y når vi får svaret at han er snart ferdig eller er 90% ferdig med kdingen. Vet hva sm vil skje når vi endrer en grensebetingelse fr eksempel pålegger alle i prsjektet 2 timer vertid pr. dag. Nen vil prdusere fr t timeverk ekstra, nen vil jbbe langsmmere, nen vil bli småsyke sv. Mennesker er ikke maskiner selv m prsjektleder gjerne vil tr det. Tre viktige faktrer: Prduktvisshet Hvr klart er kravene spesifisert vet vi hva vi skal lage Hvr stabile er kravene har kunden bestemt seg fr hva han vil ha Prsessvisshet Kan vi endre prsessen. Dette er viktig fr våre muligheter til å styre / påvirke prsjektet Er det mulig å måle viktige parametere i prsessen. Dette er viktig fr å kjenne prsjektstatus. Hvr gdt frstå vi effekten av endringer i en eller flere prsessparametere. Dette er viktig fr våre muligheter til å påvirke prsessen i den retningen vi ønsker. Ressursvisshet Hvr gdt kjenne vi tilgangen på ressursene i prsjektet. Dette gjelder primært persnell, men i mindre grad gså maskinvare særlig viss prsjektet er avhengig av spesiell maskinvare. Hvrdan vi vil estimere avhenger av graden av ressursvisshet g prsessvisshet. Når denne er lav vil det være gunstig å gjøre en følsmhetsanalyse. Dette skjer sm følger: En hver estimering bygger på et sett av frutsetninger. Disse må identifiseres g dkumenteres. Eksempler er kvalifikasjnene til persnellet, antall utviklere, kundens krav til fr eksempel pålitelighet eller tilgjengelige verktøy. Hva skjer med estimatet hvis en av disse frutsetningene må frandres? De frutsetningene sm fører til stre endringer i estimatet er kritiske. De må derfr vurderes ekstra nøye g vervåkes under hele prsjektet slik at vi kan passe på at de hlder stikk eller freta nødvendig replanlegging av (deler av) prsjektet hvis de svikter. Fire viktige typer av prsjektsituasjner avhengig av de tre faktrene ver g hvrvidt de tre typene visshet er høy eller lav: Realisering Allkering Design Eksplrering Prduktvisshet Høy Høy Høy Lav Prsessvisshet Høy Høy Lav Lav Ressursvisshet Høy Lav Lav Lav Ved å kmbinere rimelige situasjner får vi fram fire prblemsituasjner med hvert sitt fkus: Realisering hvrdan ppnå måla på den mest effektive måten. Dette er et ønskeprsjekt g frekmmer dessverre sjelden. Vi kan bruke en enkel, lineær prsessmdell. Prsess g nødvendig kunnskap kan fastsettes på frhånd. Jbben kan deles pp i et sett av arbeidsppgaver sm kan styres g kntrllers. En av de frslåtte metdene fr kstnadsestimering kan brukes direkte. Allkering usikkerhet med hensyn til ressurser. Hvedprblemet er tilgjengelighet av persnell. Hvem vil jbbe på prsjektet, hvr mye vil de jbbe, når kan de gjøre det? Viktige mmenter her er å standardisere så mye sm mulig. Dette vil gjøre det lettere å bytte flk. Vi kan stadig bruke en enkel utviklingsmdell g en av de estimeringsmetdene vi har snakka m tidligere, men når vi ikke vet hvem sm skal gjøre jbben vil det være flere parametere sm er ukjente eller vil variere ver tid. Fr eksempel COCOMO kstnadsdrivere g hvrdan de avhenger av bemanningen til prsjektet. Design. Design refererer her til design av prsjektet ikke til design av prduktet / systemet. Krava er fastlagt, men vi har ikke bestem ss fr hvrdan vi vil realisere systemet lav visshet på prsess g ressurser. Viktige spørsmål er valg av milepæler, valg av dkumenter sm skal lages, valg av persnell g frdeling av ansvar. Vi trenger standardiserte løsninger, dkumenter g prsedyrer. Dermed er utput gitt g vi kan styre gjennm valg av prsess g ressurstilgang. Vi trenger generell verkapasitet siden det kan bli mye skifte av persner g dårlig tilgang i nen perider. Siden vi ikke kan regne med verkapasitet i persner, må vi prøve å få ekstra resurser i frm av mer tid timeverk g kalendertid.

13 Vi kan ikke bruke nen av de beskrevne estimeringsmdellene. I stedet må vi bruke det vi har av erfaringer g data fra tidligere, liknende prsjekter. Viktig med følsmhetsanalyse. Dette vil frtelle hva sm er kritisk g hvilke muligheter man har fr å endre prsjektet. Eksplrering lite kunnskap m krav, ressurser g prsess. Dette er en vanskelig, men slett ikke uvanlig situasjn. Innenfr enkelte markedssegmenter er dette nesten den mest vanlige måten å jbbe på. Dette gjelder fr eksempel SME i deler av internettmarkedet. Styring g prsess vil være ad hc. Den kritiske suksessfaktren er i hvr str grad deltakerne er engasjert i å få til et gdt prdukt. Prttyping g tett kbling mellm utviklere g kunder er abslutt nødvendig. Estimering vil strt sett måtte skje via ekspertvurderinger. Eksperter er flk sm har deltatt i slike prsjekter før. Viser til fig 8.2, sm ppsummer hele prblemstillingen. Risikstyring Risikanalyse g risikkntrll er viktig i all prsjektstyring. Det har vært en tendens i mange prgramvareprsjekter til å ignrere risik vi vil bekymre ss m det viss det hender er en vanlig respns. Praktisk erfaring viser imidlertid at det da fte er fr seint. Vanligvis vil en risikanalyse fregå sm følger: 1. Identifiser mulige risikfaktrer. Dette skjer via en eller annen frm fr idemyldring alt fra helt ufrmelt til det å følge en eller annen dkumentert prsess. Dersm det er mulig bør vi gså prøve å identifisere risikindikatrer altså ting vi kan bservere når risiken er på vei til å inntreffe. Dette vil gi ss en tidlig advarsel g gi ss bedre tid til å finne g iverksette tiltak. 2. Finn effekt (K fr kstnad) g sannsynlighet (p). Risiken (R) er da gitt sm R = K*p. I prinsippet kunne man tenke seg å finne tallverdier fr eksempel tapet er NOK g sannsyneligheten er 0.01 men dette er vanligvis vanskelig. Derfr pererer de fleste med en eller annen skåringsmekanisme, fr eksempel bruke H, M g L (høy, middels g lav) eller tallverdier, fr eksempel 10, 5 g 1. Tallverdiene gjør det lettere å beregne et risiktall. Dette gjør at man ikke kan finne nen absluttverdi fr hver risikfaktr, men må nøye seg med å gradere g rangere de. Dette er nk fr å lage ei priritert liste ver risiker g tiltak. 3. Fr alle viktige risiker må vi definere tiltak. Disse vil tilhøre en av følgende kategrier: Unngå innføre tiltak fr å fjerne risiken. Er det en spesiell funksjn vi trr det blir vanskelig å implementere kan vi ha et frprsjekt fr å frstå den bedre eller vi kan prøve å frhandle den brt med kunden. Er det prblemer med å bruke et spesielt verktøy kan vi gjøre en rådgiving g veiledningsavtale med en knsulent eller et firma sv. Overfør flytt risiken ut av prsjektet, fr eksempel til et frprsjekt vanlig måte å behandle ustabile krav på - eller et parallelt frskningsprsjekt. Aksepter dette er ne vi ikke kan gjøre ne med nå. Det må lages en plan fr hva vi skal gjøre hvis det inntreffer g sørge fr at en persn er ansvarlig fr å sette den i verk hvis risiken skulle gå ver til å bli et prblem. 4. Håndter risiken. Overvåk de viktige risiker g eventuelt deres indikatrer. Siden et prsjekt ikke er en statisk enhet er det viktig å gjenta prsessens trinn 1 3 med jevne mellmrm. Det kan dukke pp nye risiker, nen risiker vil kunne frsvinne eller deres sannsynlighet eller knsekvens vil frandre seg. Resultatet bør dkumenteres i en risiktabell sm minimum bør innehlde følgende infrmasjn: Aktivitet Kstnad (K) Sannsynlighet (P) Risik (R = K * P) Tiltak Ansvarlig Bruk et regneark. Da er det lett å ppdatere g srtere. Dersm det er mulig bør man gså ta med indikatrer fr hver enkelt risik. Prsjektplanlegging Prsjektet består av mange aktiviteter. Det er viktig å få versikt ver aktivitetene før vi begynner å planlegge. En måte å få versikt ver disse på er å lage en WBS Wrk Breakdwn Structure.

14 Det er viktig at alle i prsjektet er med på denne prsessen. Aktiviteter sm blir glemt må legges inn i prsjektet seinere fte med stre ekstrakstnader. Det kan være lurt å lage WBS i flere mganger etter at man har laget det øverste nivået hvedaktivitetene. Viktig input er: Den erfaringa hver enkelt deltaker har Resultater WBSer - fra tidligere prsjekter. Den utviklingsmdellen / prsessen vi har valgt T tmmelfingerregler fr å lage en WBS: Ingen arbeidspakke bør være større enn timeverk Bryt alltid ned til et nivå der du frstår hva sm skal gjøres, enten frdi det er pplagt eller frdi den sm skal gjøre jbben kjenner den igjen. I henhld til disse reglene vil et prsjekt på ett årsverk (1600 tv) bestå av 16 til 40 arbeidspakker. Når vi har identifisert alle arbeidspakkene må vi: Finne ut hvr mye ressurser (Dagsverk - Dv)vi trenger fr å lage hver enkelt pakke. Deretter må vi bestemme hvr mange persner (n) vi sette på jbben. Dette vil definere varigheten (T) på aktiviteten ved at T = Dv / n. Her må vi passe på t ting: Det er ikke alle Dv / n sm er meningsfylte. Fr eksempel vil det være urimelig å tr at vi kan få gjrt unna en 100 Dv jbb på en dag ved å sette på 100 persner. I tillegg er det en del aktiviteter sm er avhengige av en mdningsprsess. Slike aktiviteter er det vanskelig å gjennmføre på krt tid. Vi har gjrt en del frutsetninger under estimeringa m kvalifikasjnene til de sm skal gjøre jbbene. Disse frutsetningene må respekteres, eller må vi estimere m igjen. Fr hver arbeidspakke, bestemme hvilke andre arbeidspakker sm må være ferdige før vi kan starte arbeidet med denne pakka avhengigheter. Denne prsessen kan føre til at vi må endre WBS eller estimatene. Dette er en frdel, ikke et prblem: Eksempel på et tilfelle der vi må endre WBS er hvis vi finner ut at pakke B må starte etter pakke A, men ikke hele pakke A må være ferdig, bare nen deler. Da er det lurt å dele pakke A pp i t pakker A1 g A2 g si at B kan starte når pakke A1 er ferdig. Endring av estimatene kan være aktuelt i flere tilfeller. Vi vil se på t slike: Vi har en ferdig WBS g har kstnadssatt alle pakkene slik at summen blir lik det ttale estimatet. Det viser seg imidlertid at flere av pakkene ser ut sm de er svært mye underestimert. Løsningen på dette er å identifisere de underestimerte pakkene, gi de et realistisk estimat g summere på nytt. Vi har en frdelingsnøkkel, fr eksempel at design tar 40% - 10% på verrdna design g 30% på detaljert design - g kding g testing tar 30% hver. Da kan vi benytte samme strategi sm ver, men mer detaljert. Resultatet skal ppsummeres i en tabell med følgende frmat: Arbeidspakke Før-jbber Dagsverk (Dv) Antall persner (n) Varighet (T = Dv / n) Ut fra denne tabellen kan vi nå lage PERT diagram g Gantt diagram sm er de vanligste diagrammene fr å planlegge et prsjekt. Sm eksempel kan vi se på følgende tabell: Arbeidspakke Før-jbber Dagsverk (Dv) Antall persner (n) Varighet (T = Dv / n) Design Test plan Design Kde A Design Kde B Design 5 1 5

15 Testing Test plan Kde A Kde B Dette gir følgende PERT diagram., Se fig Dette gir ss en kritisk vei sm er 30 dager lang. Dette må sees sammen med den varigheten vi estimerte eller lvet kunden tidligere. Hvis kritisk vei er krtere enn den estimerte / lvede tiden er alt OK. Dersm dette ikke er tilfelle må vi prøve å fikse det ved å: Prøve å krte ned på varigheten til en eller flere aktiviteter på den kritiske veien ved å sette på flere flk. Prøve å fjerne avhengigheter sm gjør at vi kan ppnå en større grad av parallellitet i prsjektet. Dele pp aktiviteter slik at vi får redusert aktivitetene på den kritiske veien. De aktivitetene sm ligger på den kritiske veien i PERT diagrammet må vervåkes ekstra nøye. En hver frsinkelse på en av disse vil frsinke hele prsjektet. De andre aktivitetene har det vi kaller en slakk. Dette medfører at frsinkelser i disse aktivitetene ikke er kritiske siden de ikke påvirker den ttale varigheten av prsjektet. De kan imidlertid raskt bli så mye frsinka at vi må redefinere den kritiske veien g sluttidspunktet. Ut fra PERT diagrammet kan vi lage et Gantt-diagram se fig Ut fra Gantt-diagrammet kan vi lage ss en bemanningsprfil ved å summere antall planlagte dagsverk pr. dag eller måned. Denne prfilen er viktig frdi den kan hjelpe ss med å fretelle når vi: Trenger ekstra flk Kan avgi flk til andre prsjekter Fr det eksemplet vi så på i fig. 8.7 finner vi følgende bemanningsprfil. Aktivitet Design 1 1 Testplan 1 Kde A 1 1 Kde B Test Sum Vi ser at vi bare trenger en persn unntatt i dag 10 15, der vi trenger tre persner. Da er det viktig at det virkelig er tre persner tilgjengelig på det planlagte starttidspunktet altså etter 10 dager. Dersm de ikke er tilgjengelig vil det medføre frsinkelser i hele prsjektet en dag fr hver dag de ikke er tilgjengelig. Nen trr at det går an å ta igjen dette, men erfaring viser at det skjer bare i nen få tilfeller. WBSen, PERT diagrammet g Gantt-diagrammet bør ppdateres med jamne mellmrm. Det er derfr viktig med verktøystøtte i disse aktivitetene. Diagrammene gir ss en gd mulighet til å følge pp prsjektet. Dette kan skje på flere måter: Når nen aktiviteter er ferdige kan vi sammenlikne medgåtte resurser mt estimerte ressurser. Dersm det er en systematisk frskjell bør vi vurdere å justere resten av estimatene gså. Denne justeringa vil gi en gd pekepinn på hvrdan vi ligger an i frhld til planen. Vi kan la det estimerte ressursfrbruket fr hver pakke representere verdien av pakka. Dette er rimelig viss vi har slgt prsjektet fr den estimerte verdien. Hvis vi er ferdige med arbeidspakker sm representerer X % av estimatet vil det være rimelig å si at prsjektet er X % ferdig. Hvis det er aktiviteter på kritske vei sm ikke er ferdige når de skulle være det, bør man vurdere å flytte flk fra ikke-kritiske til kritiske aktiviteter. Pass på at de virkelig kan gjøre nytte fr seg i denne aktiviteten ellers går det bare fra galt til verre. Trenger de fr eksempel pplæring? Fwler kapittel 2 UML er et mdelleringsspråk, ikke en utviklingsmetde. RUP Ratinal Unified Prcess er en metde sm er spesielt utviklet fr å gå sammen med UML. Man kan imidlertid bruke UML uansett hva slags prsess g utviklingsmetde man velger. Fwler har definert en liten, enkel, iterativ prsess sm passer gdt fr mange små g middels stre prsjekter. Grvt sett består denne prsessen av følgende:

16 Inceptin finner ut m det freslåtte prsjektet er nyttig g mulig å realisere innenfr rimelig tid g ressursfrbruk Elabratin samle inn krav g lage en verrdnet analyse g design Knstruksjn en serie av iterasjner fr å realisere systemet Transisjn vi slipper ut første versjn betaversjnen Vi vil se på hver av disse fasene i mer detalj. Inceptin Det er mange måter å gjennmføre dette på, måten avhenger av hvem kundene er g hvr strt prsjektet er. Viktige ting å få på plass på et verrdnet nivå er: Hva skal vi lage Hvem skal ha det Hva skal det kste Trr vi at vi kan få det til Hvis det ser ut til at det er la-seg-gjørlig så går vi ver til neste fase, ellers er det bare å glemme hele greia. Elabratin Dette er primært en risikdrevet fase. Vi trenger versikt ver de risiki sm ligger i prsjektet. Det kan være praktisk å perere med fire risikkategrier: Kravrisiki analysen av kravrisiki begynner med use-case. Teknlgiske risiki Ferdighetsrisiki Plitiske risiki Kravrisik hva er krava til systemet, bygger vi det riktige systemet Teknlgisk risik har vi den riktige teknlgien fr denne jbben Kunnskapsrisik har vi den kunnskapen vi trenger tilgjengelig fr dette prsjektet Plitisk risik finnes det plitiske (her i betydningen intern bedriftsplitikk) krefter sm kan kmme i veien fr prsjektet. Vurdering g handtering av disse risiki kan gjøres slik vi har snakket m før. Kategriene g det vi sier m de her, kan brukes sm ei sjekkliste fr å øke sannsynligheten fr at vi har fått med ss alle de viktige risikfaktrene. Vi skal se litt på hver av disse kategriene. Kravrisik Før vi kan se på kravrisik må vi raskt definere et use case. Et use case er en funksjn sm brukeren trenger, sm har verdi fr han g sm er beskrevet på en måte sm han frestår. Use case er i UML den viktigste måten å kmmunisere med kundene på. På dette tidspunktet behøver ikke use casene å være detaljert nen avsnitt med tekst er nk. Det frteller hva funksjnen skal hete g hva kunden ønsker å ppnå med funksjnen. I tillegg til et sett av - de viktigste use case, trenger vi en knseptuel mdell av dmenet (fagmrådet). En av ppgavene til denne mdellen er å beskrive g definere hvrdan dette fagmrådet bruker en del viktige termer. Dette er viktig fr å frstå den verden systemet skal fungere i. Tre teknikker er viktige. Vi skal se på de i mer detalj senere. Klassediagram, tegnet fra et knseptuelt perspektiv. Aktivitetsdiagram, fr å identifisere hva sm skal gjøres. Interaksjnsdiagram, fr å identifisere hva sm skal gjøres. Fr alle disse diagrammene gjelder at man på dette stadiet i prsjektet kan g bør være svært ufrmell. I tillegg til diagrammene g den tilhørende ntasjnen kan det være lurt å ha en del frklarende, ufrmell ntasjn. Hvedpenget er å få versikt ver dmenet, ikke å lage en krrekt, rigrøs mdell. Mdellen skal være et skjellet, ikke en verrdna mdell. En verrdna mdell er en høynivå beskrivelse av systemet g innehlder derfr ingen detaljer. Et skjellett kan gdt innehlde detaljer, men bare de vi synes er viktige fr øyeblikket.

17 Fr å få til en brukbar dmenemdell er det viktig å lage mdellen sammen med kunden. Dette er nk en viktig grunn til å hlde ntasjnen enkel g ufrmell. Klassediagram Klassediagrammer beskriver typer av bjekter i systemet g de statiske relasjnene sm kan være mellm de. Det finnes t typer av relasjner: Asssiasjner, fr eksempel en kunde leier en vide Subtyper, fr eksempel und-ass er en subtype av student. Vis fig. 4-1 fra Fwler. Nen kmmentarer på en del egenskaper, i det minste generalisering, klassebetegnelse med navn, attributter g perasjner g relasjner g multiplisitet. Aktivitetsdiagram Aktivitetsdiagrammer består ikke uventa av et sett av aktiviteter g hvrdan de er kbla sammen. Aktivitetsdiagrammer kan i nen tilfeller være et gdt alternativ til interaksjnsdiagrammer. Hver aktivitet er enten en prsess nen gjør ne - eller en eksekvering av et prgram. Diagrammet viser sekvenseringen av aktivitetene. Vis fig. 9-1 fra Fwler. Kmmenter sentrale begreper sm Frk, Branch g Jin. Aktivitetsdiagrammer blir ikke behandla i kurset ut ver dette. Interaksjnsdiagram Av samarbeidsdiagrammer er det interaksjnsdiagrammer sm blir priritert i dette kurset. Disse diagrammene viser hvrdan klassene arbeider sammen g utveksler meldinger. Klassediagrammer g interaksjnsdiagrammer blir utvikla i en iterativ prsess. Vis fig 5-1 i Fwler. Kmmenter sentrale begreper sm Objekt, Message g Creatin. Mer m kravrisik - 1 Kmbinasjnen av dmenemdell g use case gir en gd kmbinasjn fr å frstå kravrisiken i prsjektet. Husk at frmålet er å frstå risik g gjøre ne med den, ikke å lage et systemdesign. Dette impliserer at vi bruker mye ufrmell ntasjn g ekstra kmmentarer i tillegg til de diagrammene vi har nevnt tidligere. Når vi har en gd dmenefrståelse kan vi ta en runde til på use casene g til slutt ta en freløpig siste runde på dmenemdellen. I dette arbeidet må vi inkludere en eller t dmeneeksperter. Dersm dmenemdellen er str kan vi prøve å dele den pp i pakker g gjerne begynne å se på tilstandsdiagrammene til klasser sm har særlig interessant eller vanskelig ppførsel. Pakker Et pakkediagram er et klassediagram sm viser bare pakker av klasser g avhengigheter mellm de. Vi har en avhengighet mellm t klasser viss endringer i definisjnen i den ene medfører endringer i den andre. Avhengighetene kan være at den ene sender en melding til den andre, en klasse bruker deler av en annen klasse sm parametere i en perasjn eller ved at den ene bruker den andres grensesnitt. Vis fig 7-1 i Fwler. Vi har avhengigheter mellm pakker viss vi har avhengigheter mellm en klasse i den ene pakka g en klasse i den andre. Tilstandsdiagrammer Et tilstandsdiagram viser alle tilstandene til et bjekt g hvrdan tilstanden til bjektet endrer seg sm resultat av hendelser. Tilstandsdiagrammet berører altså bjekter instansinerte klasser g ikke de definerte klassene. Vis fig 8-1 fra Fwler g kmmenter. Overgangene er merket med Hendelse [Betingelse] / Handling. Handling er det samme sm en tilstandsendring transisjn. Mer m kravrisik 2 Pass hele tiden på at vi lager et skjellett, ikke en verrdna høyere rdens mdell. Viss vi prøver å ta med alle detaljer ver alt på dette tidspunktet vil det ta alt fr lang tid g vi kan lett glemme hensikten, nemlig å få en versikt ver kravrisiken. Vi må passe på å hele tiden jbbe videre med use casene fr å se m de intrduserer elementer sm gjør at vi må endre nen av de andre diagrammene i skjellettet.

18 Viss vi føler ss usikre på hvrdan vi skal realisere en del av dmenemdellen, er det lurt å lage en prttyp. Ikke lag prttyper av alt, men bruk dmenemdellen til å ppdage ting sm dere føler dere usikre på. Den kritiske delen av arbeidet med kravrisik g dmenemdellen, er tilgang på dmeneekspertise. Vanligvis betyr dette tilgang på eksperter / brukere fra kunden. Vi må altså jbbe tett sammen med kunden i denne periden. Teknlgisk risik Det viktigste vi kan gjøre her er å lage en eller flere prttyper fr å prøve ut den teknlgien vi skal bruke senere i prsjektet. Eksempler på slik teknlgi kan være databaser, kmmunikasjnspakker g brukergrensesnittpakker. Den største risiken er ikke hvrdan hver pakke fungerer eller er designet, men hvrdan pakkene passer sammen med hverandre g med det du skal lage selv. Dette må derfr prøves ut så tidlig sm mulig. Vi må gså vurdere arkitekturbeslutningene på dette trinnet. Dette er særlig viktig viss vi skal lage et distribuert system. Det er viktig å se på de beslutningene sm det er vanskelige å gjøre m seinere. Tre viktige spørsmål: Hva vil skje viss en del av teknlgien ikke fungerer Hva må vi gjøre viss t dele av teknlgien ikke fungerer sammen Hvr sannsynlig er det at ne går galt her g hva kan vi gjøre viss det inntreffer. I denne prsessen er det igjen viktig å se på use case, klassediagrammene g pakkediagrammene fr å se m det er ne du har versett. Kunnskapsrisik At vi mangler ekspertise er en vanlig grunn til at prsjekter går galt. Vanligvis er årsaken at man ikke vil bruke penger på kurs rett g slett frdi det kster penger. På den andre siden ser det ikke ut til at de bryr seg m at verskridelsene vanligvis kster langt mer. Kursing av prsjektdeltakerne g av ansatte generelt er en gd investering. Prblemet er imidlertid fte at mange prsjektrienterte bedrifter mangler et investeringsbegrep g investeringspplegg. Det beste er å ha et pplegg med krte, målretta kurs etterfulgt av eget arbeid med hjelp av en mentr. I begynnelsen vil mentren være en del av prsjektet fr så seinere å trekke seg tilbake g fungere sm rakel g rådgiver. Viss man ikke kan skaffe en mentr så pass på å hld hyppige gjennmganger av det sm blir gjrt slik at man kan gi hverandre råd, diskutere prblemer g lære av hverandres tabber g suksesser. Vær på utkikk etter mråder i prsjektet der du mangler kunnskap selv. Dette er mråder der vi trenger kurs, en eller flere mentrer eller å leie inn en erfaren knsulent. Plitisk risik Dette angår risik sm ppstår internt i bedriften g i frhldet mellm bedriften g kundene. De mest vanlige knfliktene g dermed risikfaktrer er: Allkering av persnell. Vi har blitt lvet fire persner, men får bare tre, eller vi får persner med lavere eller annen kmpetanse enn den vi hadde regnet med. Tilgang til persnell. Vi må avgi flk før vi hadde tenkt pga. at et annet prsjekt blir priritert høyere av ledelsen eller frdi det brenner i et annet prsjekt eller frdi en viktig kunde har rapprtert en feil. Andre risiki sm hører til her er at vi blir lvet kurs sm så blir kutta pga. kstnader eller viss vi skal lage prdukter til et generelt marked bedriften bytter markedsstrategi. Endring i pririteter pga. at vi blir ppkjøpt er gså ne sm har blitt vanlig gså i nrsk industri. Dette er prblemer sm må løses av ledelsen, ikke av de sm jbber i prsjektene. Det kan imidlertid være lurt å vurdere de g bestemme seg fr hva man skal gjøre på et tidlig tidspunkt. Det kan være nyttig å infrmere ledelsen på et tidlig tidspunkt m at disse risiki finnes g hva sm kan bli knsekvensen viss de inntreffer. Når er Elabratin ferdig Tmmelfingerregel: Denne fasen tar ca. en femtedel av det ttale prsjektet. Det finnes t indikatrer sm sier at vi er ferdige:

19 Utviklerne synes det er OK å prøve å estimere hvert use case kstnader g kalendertid til nærmeste ukeverk. Alle signifikante risiki har blitt identifisert g vurdert så gdt at du føler at du kan handtere de uten å se stre prblemer. Knstruksjnsfasen Planlegging Knstruksjnsfasen består ev en serie av iterasjner. Det kan være lurt å lage mange små use case g realisere et use case pr. iterasjn. Igjen må vi passe på å invlvere kundene. Begynn med å kategrisere use casene. Dette gjøres sm følger: 1. Kunden deler pp use casene i henhld til deres verdi fr bedriften bruk kategriene høy, middels g lav 2. Utviklerne deler pp de samme use casene i henhld til risik samme kategriene. 3. Utviklerne estimerer hvert use case kstnad g ledetid. Dette er nett tid full tid på prduktivt arbeid. Etter sm vi får erfaring f.eks. etter første iterasjn må vi justere fr verhead. 4. Bestem hvr lang du vil ha hver iterasjn dette må være nk til å gjennmføre 3 6 use caser. Uansett bør en iterasjn ikke være mye lenger enn en til halvannen måned. 5. Bestem prsjektets hastighet. Dette gjøres på følgende måte: N = antall utviklere L = lengde på en iterasjn se punkt 4. F = last faktr se punkt 3. Viss vi f.eks. bruker fire ukeverk på å få gjrt det sm er estimert til å ta tre ukeverk er lad faktren 4/3 = 1.3 Dette gir hastigheten V = N * L / F. Viss vi har fem utviklere g t ukers iterasjner med en lastfaktr på 1.3 finner vi V = 5 * 2 / 1.3 = 7.7, sm er innsats pr. iterasjn. 6. Når vi har prsjekthastigheten V kan vi finne antall iterasjner IT sm følger: IT = 1 + Sum(Ukeverk pr. use case) / V. Viss vi har funnet at vi ttalt trenger 77 ukeverk fr å realisere alle use casene finner vi IT = / 7.7 = 11 iterasjner. Ut fra kundens g utviklernes vurderinger kan vi nå lage følgende tabell ver use casene Utviklernes vurdering av risik H M L Kundens vurdering av verdi fr kunden H M L De use casene sm havner i høy risik g / eller str verdi må taes tidlig i prsjektet. Sett av tid fr integrasjn g levering av betaversjn. Sett av 10% viss du har gjrt det (mange ganger) før g 35% viss dette er nytt fr deg. Til slutt bør du legge til 10 20% sm reserveressurser. Lag en releaseplan når kan vi demnstrere hvert inkrement g hvilke use case vil det innehlde. Knstruksjn Hver iterasjn kan sees sm et miniprsjekt med analyse, design g kding etterfulgt av testing g integrasjn. Når iterasjnen er realisert kan du demnstrere det nye systemet fr kunden. Iterasjnene er både inkrementelle g iterative. Inkrementell frdi den legger til ne ny funksjnalitet hver gang. Iterativ frdi vi hver gang må skrive m ne av den kden vi allerede har fr å tilpasse nye inkrementer. Tre aktiviteter sm må gå kntinuerlig: Refaktring. Når vi jbber med inkrementer må vi vanligvis endre ne kde fr hvert inkrement vi legger til. Refaktring er endringer sm ikke påvirker funksjnaliteten, men i stedet rydder pp i kden, fte ved å endre klasser, gjøre enkel redesign sv. Det finns nen regler de tre viktigste kmmer her: 1. Ikke gjør refaktring g implementasjn samtidig eller m hverandre. Ha er klart skille mellm disse t aktivitetene

20 2. Pass på å ha et kmplett sett tester før du begynner refaktring slik at du kan validere at det sm var OK før stadig er OK. 3. Ta krte steg sm bare innehlder nen få endringer i kden. Test etter hvert steg. Integrering. Integrer ny kde så snart den er tilgjengelig. Kjør alle tester etter hver integrasjn. Testing. Lag tester kntinuerlig slik at du til en hver tid kan teste det du har implementert pluss all tidligere funksjnalitet. Lag et pplegg fr autmatisk testing slik at du slipper å sjekke alt fr hånd. Knstruksjn begynner med design. Første skritt i design er å gå gjennm alle klassene sm er beskrevet tidligere g se hvrdan de bidrar til å realisere den funksjnaliteten sm er beskrevet i use casene. Fwler anbefaler CRC krt. Vis fig 5-6 i Fwler g frklar. Ut fra CRC krta finner vi ansvar g perasjner sm skal inkluderes i et eller flere klassediagram. Diskuter klassediagrammene videre utarbeidet fra de skjelettene vi laget tidligere med klleger. Nå er vi klare til å kde. Kding g etterfølgende testing vil vanligvis føre til endringer i design. Lag ikke kmplett designdkumentasjn i det minste ikke nå. De vil sikkert bli endra seinere. Bruk heller Javadc eller likende fr eksempel BlueJ - til å generere designdkumentasjn ut fra den kden sm finnes. Da blir det enkelt å ppdatere dkumentasjnen g den vil alltid være riktig - så lenge vi ikke får feil i Javadc. Pakkediagrammene viser hvrdan systemet er satt sammen g hvilke lgiske deler det har. Dette diagrammet er vanligvis mer stabilt enn de mer detaljerte klassediagrammene. I tillegg vil det være praktisk / nyttig å ppdatere de viktigste, mest kmpliserte tilstandsdiagrammene. I slike tilfeller bør man gså vurdere m man trenger aktivitetsdiagrammene. Transisjn I denne fasen skal det ikke legges til funksjnalitet, unntatt viss endingene er små g abslutt nødvendige. I tillegg må vi rette feil. Det kan være aktuelt å gjøre ptimalisering viss systemet er fr tregt så tregt at det irriterer kunden. Husk at ptimalisering både fr tid g plassfrbruk har en tendens til å gjøre kden vanskeligere å frstå, g dermed å endre(fr eksempel fr å rette feil eller legge til ny funksjnalitet senere) Kapittel 13 På et verrdnet nivå finnes det bare t typer testing: Testing fr å se m vi har feil i kden, fr å hjelpe til med å finne de g sørge fr at feilene blir rettet. Dette er den testingen sm bedriften gjør under utvikling. Hele pplegget er internt g under bedriftens kntrll. Testing fr å bygge tillit til at prduktet gjør jbben sin eller tilfredsstiller kundens krav. Ofte vil kunden si at Vi gdkjenner systemet når følgende tester er kjørt uten feil. Det finnes mange måter å test på. Alle har sm frmål å gi et best mulig utbytte av testingen. Nen interessante varianter er: Dekningsbasert testing. Det finnes mange måter å definere dekningsgraden på, fr eksempel kdedekningsgrad alle kdesetninger er kjørt minst en gang. stidekningsgrad alle mulige veier er kjørt minst en gang. Stidekning g kdedekning er ikke det samme. Vis g kmmenter fig Linje 7 har en if-setning. Hva skjer hvis betingelsen ikke er sann? løkkedekning fr eksempel alle løkker skal kjøres null, en g N ganger definisjn bruk dekningsgrad alle par av tilrdninger g bruk av en variable skal utføres. kravdekningsgrad alle krav skal dekkes. Hva vi må gjøre avhenger av hvr detaljerte vi er med hensyn på hvert krav. Feilbasert testing. Vi setter inn en del feil i kden i tillegg til de sm allerede er der. Vi sier at kden er gdt nk testet når vi har funnet en gitt andel fr eksempel 99% - av alle innsatte feil. Prblembasert testing. Vi bruker den kunnskapen vi har m hva sm er vanskelig dvs. fte feiler g setter inn mesteparten av innsatsen der. Risikbasert testing. Vi ser på hva sm medfører de alvrligste knsekvensene fr kunden hvis det feiler g tester mest der. Dette vil fr eksempel bli gjrt fr sikkerhetskritiske systemer. Det kriteriet vi velger vil bestemme når vi er ferdige med å teste. Vi behøver ikke å kreve 100% dekning. I mange tilfeller vil det ikke engang være realistisk. Dette gjelder bla. fr stidekning siden antall mulige veier gjennm et prgram frt blir strt.

Oppfølging av funksjonskontrakter SOPP SOPP 2 15.04.2008

Oppfølging av funksjonskontrakter SOPP SOPP 2 15.04.2008 Oppfølging av funksjnskntrakter Regelverk g rutiner fr kntraktppfølging, avviksbehandling g sanksjner finnes i hvedsak i følgende dkumenter: Kntrakten, bl.a. kap. D2 pkt 38 Sanksjner Instruks fr håndtering

Detaljer

1 Bakgrunn og formål med forvaltningsrevisjon... 2. 2 Om planlegging av forvaltningsrevisjon... 2

1 Bakgrunn og formål med forvaltningsrevisjon... 2. 2 Om planlegging av forvaltningsrevisjon... 2 PLAN FOR GJENNOMFØRING AV FORVALTNINGSREVISJONSPROSJEKT 2008-2011 - STJØRDAL KOMMUNE - 2008 Innhldsfrtegnelse 1 Bakgrunn g frmål med frvaltningsrevisjn... 2 2 Om planlegging av frvaltningsrevisjn... 2

Detaljer

1 Om forvaltningsrevisjon

1 Om forvaltningsrevisjon PLAN FOR FORVALTNINGSREVISJON 2015-2016 Malvik kmmune Vedtatt i sak 85/14 i kmmunestyret den 15.12.14. 1 Om frvaltningsrevisjn I henhld til kmmunelven 77 er kntrllutvalget ansvarlig fr å påse at kmmunens

Detaljer

Pensum for Kvalitetsrevisorer og Revisjonsledere Kvalitet

Pensum for Kvalitetsrevisorer og Revisjonsledere Kvalitet Pensum fr Kvalitetsrevisr, 01-07-2014 Side 1 Pensum fr Kvalitetsrevisrer g Revisjnsledere Kvalitet Quality Auditr (QA), Quality Lead Auditr (QLA) ette dkumentet gjengir krav til kandidatens kmpetanse i

Detaljer

Utkast Notat Brukers hverdagssituasjoner og tiltak for trygghet, mestring og sosial deltakelse sett i lys av kommunal tjenesteinnovasjon

Utkast Notat Brukers hverdagssituasjoner og tiltak for trygghet, mestring og sosial deltakelse sett i lys av kommunal tjenesteinnovasjon Utkast Ntat Brukers hverdagssituasjner g tiltak fr trygghet, mestring g ssial deltakelse sett i lys av kmmunal tjenesteinnvasjn Metdentat utarbeidet av Ulf Harry Evensen med bistand fra Thmas Andersen,

Detaljer

Fjerne prosess og produkt rapport som overskrift. Ha det som bunntekst.

Fjerne prosess og produkt rapport som overskrift. Ha det som bunntekst. Milepælsplan Uke 21 Henvise til alt vi kan. VIKTIG fr karakteren ;) Sensr vektlegger fancy teknlgi, få med mer Punkter på effektmål. Fjerne prsess g prdukt rapprt sm verskrift. Ha det sm bunntekst. Vis/nevn

Detaljer

BALANSERT MÅLSTYRING I VADSØ KOMMUNE - VALG AV MÅLEOMRÅDER

BALANSERT MÅLSTYRING I VADSØ KOMMUNE - VALG AV MÅLEOMRÅDER VADSØ KOMMUNE ORDFØREREN Utvalg: Bystyret Møtested: Vårbrudd Møtedat: 16.06.2005 Klkkeslett: 0900 MØTEINNKALLING Eventuelt frfall meldes på tlf. 78 94 23 13. Fr varamedlemmenes vedkmmende gjelder sakslista

Detaljer

Ingeniørenes hverdag

Ingeniørenes hverdag Ingeniørenes hverdag Ingeniøren Tillegges ppgaver sm: - er diffust frmulerte - fte er en del av en større helhet (flerfaglige av karakter) - skal løses innenfr gitte tids- g kstnadsrammer 1 Ingeniørenes

Detaljer

Håndbok i autorisasjon og autorisasjonssamtale

Håndbok i autorisasjon og autorisasjonssamtale Nasjnal sikkerhetsmyndighet Håndbk i autrisasjn g autrisasjnssamtale Utgitt av Nasjnal sikkerhetsmyndighet Autrisasjn av persner sm skal ha tilgang til sikkerhetsgradert infrmasjn er et av de viktigste

Detaljer

Rapport fra kompetansenettverket Opplæring av ungdom med kort botid

Rapport fra kompetansenettverket Opplæring av ungdom med kort botid Østfld 23.06.14 Rapprt fra kmpetansenettverket Opplæring av ungdm med krt btid -et kmpetanseprsjekt rettet mt ungdmsskler, videregående skler g vksenpplæring 1. Bakgrunn g rganisering Prsjektfrberedelsene

Detaljer

UNIVERSITETET l OSLO Det matematisk-naturvitenskapelige fakultet

UNIVERSITETET l OSLO Det matematisk-naturvitenskapelige fakultet UNIVERSITETET l OSLO Det matematisk-naturvitenskapelige fakultet Eksamen i IN 105 - Grunnkurs i prgrammering Eksamensdag: Onsdag 7. juni 1995 Tid fr eksamen: 9.00-15.00 Oppgavesettet er på 6 sider. Vedlegg:

Detaljer

STYRING OPPFØLGING AV LOVKRAV OG ØVRIGE MYNDIGHETSKRAV

STYRING OPPFØLGING AV LOVKRAV OG ØVRIGE MYNDIGHETSKRAV Saksbehandler: Tr-Arne Haug, tlf. 75 51 29 20 Vår dat: Vår referanse: Arkivnr: 31.1.2005 200300272 109 Vår referanse må ppgis ved alle henvendelser Deres dat: Deres referanse: STYRESAK 09-2005 PRAKTISERING

Detaljer

RAMMER FOR MUNTLIG-PRAKTISK EKSAMEN I INFORMASJONSTEKNOLOGI ELEVER OG PRIVATISTER 2015

RAMMER FOR MUNTLIG-PRAKTISK EKSAMEN I INFORMASJONSTEKNOLOGI ELEVER OG PRIVATISTER 2015 RAMMER FOR MUNTLIG-PRAKTISK EKSAMEN I INFORMASJONSTEKNOLOGI ELEVER OG PRIVATISTER 2015 Utdanningsprgram: Studiespesialisering Fagkder: REA3014, REA3016 Prgrammråde: Realfag Valgfrie prgramfag Årstrinn:

Detaljer

RAPPORT FRA PROSJEKTET RUS OG PSYKIATRI I HJEMMEBASERTE TJENESTER I HAUGESUND KOMMUNE 2012

RAPPORT FRA PROSJEKTET RUS OG PSYKIATRI I HJEMMEBASERTE TJENESTER I HAUGESUND KOMMUNE 2012 RAPPORT FRA PROSJEKTET RUS OG PSYKIATRI I HJEMMEBASERTE TJENESTER I HAUGESUND KOMMUNE 212 Et utvalg av ansatte i ressursgruppen i hjemmebaserte tjenester. 1 Innhld Frrd... 3 Prsjektets frhistrie... 3 Prsjektets

Detaljer

IKT-Strategi og handlingsplan 2013-2016 For felles IKT-satsning i Gjøvikregionen

IKT-Strategi og handlingsplan 2013-2016 For felles IKT-satsning i Gjøvikregionen IKT-Strategi g handlingsplan 2013-2016 Fr felles IKT-satsning i Gjøvikreginen Side 1 Innhld 1 Bakgrunn... 3 1.1 Mandat... 3 1.2 Dispsisjn g ppbygning... 3 1.3 Sektrmål, suksessfaktrer g frutsetninger...

Detaljer

PROSJEKTBESKRIVELSE ROS-ANALYSE FOR BRANN- OG REDNINGSTJENESTEN HAMMERFEST KOMMUNE

PROSJEKTBESKRIVELSE ROS-ANALYSE FOR BRANN- OG REDNINGSTJENESTEN HAMMERFEST KOMMUNE PROSJEKTBESKRIVELSE ROS-ANALYSE FOR BRANN- OG REDNINGSTJENESTEN HAMMERFEST KOMMUNE 2010 INNHOLDSFORTEGNELSE 1. INNLEDNING 1.1. Målsetning/hensikt 1.2. Ajurhld 1.3. Definisjner 2. ORGANISERING AV OG MANDAT

Detaljer

Årsrapport 2013 - BOLYST

Årsrapport 2013 - BOLYST Frist: 24. april Sendes til: pstmttak@krd.dep.n Til: KMD Årsrapprt 2013 - BOLYST Fra: Vest-Finnmark reginråd Dat: 23.4.2014 Kmmune: Prsjektnavn: Prsjektleder: Leder i styringsgruppen: Kntaktpersn i fylkeskmmunen:

Detaljer

ReadIT. Sluttrapport

ReadIT. Sluttrapport ReadIT Sluttrapprt 1 SLUTTRAPPORT Prsjekt: ReadIT Prsjektnr.: Startdat: 06.09.2012 Sluttdat: 16.12.2012 Prsjektleder: Tbias Feiring Medarbeidere: Grennes, Chris-Thmas Lundem Gudmundsen, Eivind Årvik Kvamme,

Detaljer

Høring NOU 2011:11 Innovasjon i omsorg. Høring fra Trondheim Helseklynge

Høring NOU 2011:11 Innovasjon i omsorg. Høring fra Trondheim Helseklynge Trndheim Helseklynge Frskning g utdanning innen samhandling g innvasjn Trndheim 14. nvember 2011 Til Helse- g msrgsdepartementet Kmmunetjenesteavdelingen Pstbks 8011 Dep 0030 Osl. (pstmttak@hd.dep.n) Høring

Detaljer

ENGASJERE GENERASJON Y

ENGASJERE GENERASJON Y ENGASJERE GENERASJON Y Hva er likt, g hvrdan skiller de seg fra andre generasjner? Dale Carnegie Training White Paper The New Bm. Generasjn Y. Milenniumsgenerasjnen. Kjært barn har mange navn. Generasjnen

Detaljer

Personvernsreglene. Bruk og beskyttelse av personopplysninger. Vår Policy om Personvern

Personvernsreglene. Bruk og beskyttelse av personopplysninger. Vår Policy om Personvern Persnvernsreglene Persnvern er viktig fr ss i Genwrth Financial. Vi verdsetter den tillitt du har til ss, g ønsker med dette å hjelpe deg til å frstå hvrdan vi samler inn, beskytter g bruker persnlige

Detaljer

KOMPETANSEUTVIKLINGSPLAN FOR DET SAMFUNNSVITENSKAPELIGE FAKULTETET

KOMPETANSEUTVIKLINGSPLAN FOR DET SAMFUNNSVITENSKAPELIGE FAKULTETET Innledning KOMPETANSEUTVIKLINGSPLAN FOR DET SAMFUNNSVITENSKAPELIGE FAKULTETET FAKULTETSADMINISTRASJONEN Kmpetanseutviklingsplanen er en rammeplan fr arbeid med individuell g kllektiv kmpetanseutvikling

Detaljer

Tips til oppstartsfasen

Tips til oppstartsfasen 1 Tips til ppstartsfasen Friluftslivskartlegging i Buskerud 2015-2017 Dette tipsheftet bygger på viktige erfaringer fra andre fylker g prblemstillinger sm ble tatt pp på ppstartsseminaret i Buskerud 12.

Detaljer

Retningslinjer for søknad om og tildeling av klinisk korttidsstipend 2014

Retningslinjer for søknad om og tildeling av klinisk korttidsstipend 2014 Retningslinjer fr søknad m g tildeling av klinisk krttidsstipend 2014 Søknadsfrist mandag 2. juni 2014 kl. 13.00 Innhld Om stipendet. 1 Definisjner... 2 Søknadens vedlegg.. 2 Innsending av elektrnisk søknadsskjema...

Detaljer

SAMORDNA RÅDGIVING I LANDBRUKET. Evalueringsrapport for kurs i coachende kommunikasjon og veiledning i grupper

SAMORDNA RÅDGIVING I LANDBRUKET. Evalueringsrapport for kurs i coachende kommunikasjon og veiledning i grupper SAMORDNA RÅDGIVING I LANDBRUKET Evalueringsrapprt fr kurs i cachende kmmunikasjn g veiledning i grupper Steinkjer kmmune, landbruksfrvaltningen, inviterte i ktber 2010 rådgivere innen landbruket til utprøving

Detaljer

Praksisgjennomgang. Rapport. Stiftelsen Hvasser

Praksisgjennomgang. Rapport. Stiftelsen Hvasser Praksisgjennmgang Rapprt Stiftelsen Hvasser Pega Human as Trettestykket 51 1388 Brgen Organisasjnsnr. 986 228 179 MVA Telefn 66 78 50 11 Mbiltelefn 962 21 270 e-pst pst@pegahuman.n www.pegahuman.n 2 Rapprtansvarlig:

Detaljer

Fagkurs for inkludering av innvandrere i arbeidslivet. Læreplan Fagkurs for assistenter i barnehage 2015

Fagkurs for inkludering av innvandrere i arbeidslivet. Læreplan Fagkurs for assistenter i barnehage 2015 Levanger kmmune Innvandrertjenesten Levanger v Fagkurs fr inkludering av innvandrere i arbeidslivet frprsjekt 2013 Læreplan Fagkurs fr assistenter i barnehage 2015 Deltakere: Therese Granås, Eva Winnberg,

Detaljer

Beregnet til Halden kommune. Dokument type Notat. Dato Juni 2012 HALDEN KOMMUNE BRUKERUNDERSØKELSE PERSONER MED REDUSERT FUNKSJONSEVNE

Beregnet til Halden kommune. Dokument type Notat. Dato Juni 2012 HALDEN KOMMUNE BRUKERUNDERSØKELSE PERSONER MED REDUSERT FUNKSJONSEVNE Beregnet til Halden kmmune Dkument type Ntat Dat Juni 01 HALDEN KOMMUNE BRUKERUNDERSØKELSE PERSONER MED REDUSERT FUNKSJONSEVNE HALDEN KOMMUNE BRUKERUNDERSØKELSE PERSONER MED REDUSERT FUNKSJONSEVNE Rambøll

Detaljer

Boligpolitisk handlingsplan 2015 2018 Leirfjord kommune

Boligpolitisk handlingsplan 2015 2018 Leirfjord kommune Bligplitisk handlingsplan 2015 2018 Bligplitisk handlingsplan 2015 2018 side 1 Innhldsfrtegnelse Frrd Innledning Målsetting Om bligplitisk handlingsplan 2015 2018 Statusbeskrivelse Rlleavklaringer stat,

Detaljer

FREMTID for Seniornett Norge. et bakgrunnsnotat for diskusjonen

FREMTID for Seniornett Norge. et bakgrunnsnotat for diskusjonen FREMTID fr Senirnett Nrge. et bakgrunnsntat fr diskusjnen 12.04.2013 BUDSKAP: Senirnett har et sterkt behv fr selv å kunne frme sin egen fremtid! Vi kan vanskelig leve fra år til år med str uvisshet rundt

Detaljer

Forslag til rutiner PLANLEGGING, TILRETTELEGGING OG OPPFØLGING VED IKKE BESTÅTTE PRØVER I AFR 11.05.2010

Forslag til rutiner PLANLEGGING, TILRETTELEGGING OG OPPFØLGING VED IKKE BESTÅTTE PRØVER I AFR 11.05.2010 Frslag til rutiner PLANLEGGING, TILRETTELEGGING OG OPPFØLGING VED IKKE BESTÅTTE PRØVER I AFR 11.05.2010 Innhld Innhld... 1 1. INNLEDNING... 2 Bakgrunn... 2 2 KUNNSKAPSPRØVEN... 3 2.1 Første kunnskapsprøve...

Detaljer

Flytoget AS TILSYNSRAPPORT NR. 2014-04

Flytoget AS TILSYNSRAPPORT NR. 2014-04 Flytget AS TILSYNSRAPPORT NR. 2014-04 Beredskap, ppfølging av avvik g pplæring av mbrdpersnell g førere, bruk av erfaringsdata g risikanalysedata i pplæring/kjøring. 1 Bakgrunn g mål... 3 2 Knklusjn...

Detaljer

Sikkerhets- og samhandlingsarkitektur ved intern samhandling

Sikkerhets- og samhandlingsarkitektur ved intern samhandling Utgitt med støtte av: Nrm fr infrmasjnssikkerhet www.nrmen.n Sikkerhets- g samhandlingsarkitektur ved intern samhandling Støttedkument Faktaark nr 20b Versjn: 3.0 Dat: 14.10.2015 Frmål Virksmheten skal

Detaljer

Nettverksmøte. Trondheim-Oslo. 26. november 2010

Nettverksmøte. Trondheim-Oslo. 26. november 2010 Nettverksmøte Trndheim-Osl 26. nvember 2010 Myldrende samarbeid m gdt inneklima g termitt inspirert byutvikling ved bl.a. MVRDV i Gwanggy Sør-Krea. Hvrfr er vi her? Det er viktige tema sm tas pp g jeg

Detaljer

Trender og utvikling i logistikkbetydning

Trender og utvikling i logistikkbetydning Vi kmbinerer frretningsfrståelse g teknlgi Trender g utvikling i lgistikkbetydning fr nrsk næringsliv Tllpst Futurum, 20. 22. april Marianne Rygvld, Idea Cnsulting AS Innhld Lgistikk g knkurranseevne Hva

Detaljer

Gjerpen vår menighet!

Gjerpen vår menighet! Gjerpen vår menighet! På trygg grunn, med åpne dører g mye varme Visjnsdkument 2014 Menighetsprfil (kt. 2013) Pririterte tiltak Sammen m gudstjenestefeiring Gudstjenesten sm viktigste fellesarena i møte

Detaljer

1 Oppsummering og konklusjoner

1 Oppsummering og konklusjoner Rapprt fra Brukerundersøkelse 2009-03-27 Back App 1 Oppsummering g knklusjner Siden våren 2006 har Back App vært markedsført sm et treningsapparat sm trener musklene sm støtter ryggsøylen mens du sitter.

Detaljer

Så har vi fått et nytt medlem i klubben. Hvordan skal vi beholde medlemmet?

Så har vi fått et nytt medlem i klubben. Hvordan skal vi beholde medlemmet? Så har vi fått et nytt medlem i klubben Og erfaring viser: Mange slutter før de har vært 3 år De sm blir 3 til 5 år, - blir lenge. Hvrdan skal vi behlde medlemmet? Fadderskapet i Rtary Nen tanker m fadderskapet

Detaljer

Evaluering av tiltak i skjermet virksomhet. AB-tiltaket

Evaluering av tiltak i skjermet virksomhet. AB-tiltaket Evaluering av tiltak i skjermet virksmhet AB-tiltaket Geir Møller 5. nv. 2009 telemarksfrsking.n 1 TEMA Varigheten på AB-tiltaket Hva skjer før g etter AB Utstrømming fra trygdesystemet Overgang til jbb

Detaljer

VEILEDER FOR EXTRANET

VEILEDER FOR EXTRANET VEILEDER FOR EXTRANET Extranet er et nettbasert dkumentasjns- g analyseverktøy fr målinger sm deltakende enheter i det nasjnale pasientsikkerhetsprgrammet kan benytte fritt i frbindelse med eget frbedringsarbeid

Detaljer

Høringssvar Mulighetsstudie fra Klinikk for Lunge- og arbeidsmedisin, Medisinsk avd. Orkdal

Høringssvar Mulighetsstudie fra Klinikk for Lunge- og arbeidsmedisin, Medisinsk avd. Orkdal Til Samhandlingsdirektør St. Olavs Hspital Trndheim 10. februar 2015 Høringssvar Mulighetsstudie fra Klinikk fr Lunge- g arbeidsmedisin, Medisinsk avd. Orkdal Vi er verrasket ver at St. Olavs Hspital har

Detaljer

Pasientsikkerhetsprogrammet i trygge hender

Pasientsikkerhetsprogrammet i trygge hender Pasientsikkerhetsprgrammet i trygge hender Læringsnettverk fr kmmuner i Hrdaland Fylke Kmpendium til frbedringsteamene September 2015 - mars 2016 1 Innhldsfrtegnelse Side Velkmmen til læringsnettverk Hva

Detaljer

Trivsel i Ringerikes kommunale barnehager. Barnehagenes plan for å sikre barna et godt psykososialt miljø.

Trivsel i Ringerikes kommunale barnehager. Barnehagenes plan for å sikre barna et godt psykososialt miljø. Trivsel i Ringerikes kmmunale barnehager Barnehagenes plan fr å sikre barna et gdt psykssialt miljø. Innhld Innledning... 4 Definisjner av mbbing... 4 Hvrdan kan vi ansatte støtte barnas ssiale utvikling

Detaljer

D2-K Krav til kvalitetssystem

D2-K Krav til kvalitetssystem Filnavn: D2-K-Krav_til_kvalitetssystem-20100614 Henvisning: Kap. C3, pkt 8.1 g 8.2 Dat: 2010-06-14 Innhld Kvalitetssystem (kap. C3, pkt. 8.1) Ressurs- g rganisasjnsplan (kap. C3, pkt. 8.2) Side 1 av 5

Detaljer

Miljørapport fra Norsk Skogsertifisering

Miljørapport fra Norsk Skogsertifisering Miljørapprt fra Nrsk Skgsertifisering Fr virksmheten fram til g med 2013 Osl, april 2014 Nrsk Skgsertifisering 1 Omfang g virksmhet. Nrsk Skgsertifisering ble pprinnelig sertifisert av Det Nrske Veritas

Detaljer

Dataforeningens vedlikeholdskontrakt for programvare. Veiledning for kontraktsutarbeidelse

Dataforeningens vedlikeholdskontrakt for programvare. Veiledning for kontraktsutarbeidelse Datafreningens vedlikehldskntrakt fr prgramvare Veiledning fr kntraktsutarbeidelse DEN NORSKE DATAFORENING Versjn : 2.10 Dat ppdatert : 105.11.201008 Datafreningens vedlikehldskntrakt fr prgramvare Side

Detaljer

Spørsmål i medarbeiderundersøkelsen 2016 strukturert etter politikkområder i Statens personalhåndbok

Spørsmål i medarbeiderundersøkelsen 2016 strukturert etter politikkområder i Statens personalhåndbok Spørsmål i medarbeiderundersøkelsen 2016 strukturert etter plitikkmråder i Statens persnalhåndbk 1. Bemanning 1.1 Spørsmål g svaralternativer 1. Hvilken type virksmhet arbeider du i nå? (ett svar mulig)

Detaljer

Høringsuttalelse NOU 2015:2 Å høre til

Høringsuttalelse NOU 2015:2 Å høre til Høringsuttalelse NOU 2015:2 Å høre til Barnembudets høringsgruppe på til sammen 10 elever i alderen 10-16 år har sammen laget denne høringsuttalelsen. Elevene kmmer fra kmmuner ver hele landet, g har erfaring

Detaljer

HM S -PERM oljevern HMS OLJEVERN, DEL 1 ORGANISERING, REGLER OG KRAV 0 Rev. 3 2014

HM S -PERM oljevern HMS OLJEVERN, DEL 1 ORGANISERING, REGLER OG KRAV 0 Rev. 3 2014 HMS-PERM ljevern HMS OLJEVERN, DEL 1 ORGANISERING, REGLER OG KRAV 0 Rev. 3 2014 FORORD Vår viktigste målsetning er å gjennmføre all vår virksmhet på en sikker g frsvarlig måte uten skade på persnell, ytterligere

Detaljer

Sluttrapport. Prosjekt Samhandlingsreform for ROR 01.05.2011-01.05.2013. v/hege-beate Edvardsen Prosjektleder/koordinator ROR

Sluttrapport. Prosjekt Samhandlingsreform for ROR 01.05.2011-01.05.2013. v/hege-beate Edvardsen Prosjektleder/koordinator ROR SLUTTRAPPORT ROR 2011-2013 Redigert 25.04.2013 Sluttrapprt Prsjekt Samhandlingsrefrm fr ROR 01.05.2011-01.05.2013 v/hege-beate Edvardsen Prsjektleder/krdinatr ROR Prsjektet skulle etter planen avsluttes

Detaljer

FOKUS-virksomhetenes arbeid med flerspråklige barn og ungdommer

FOKUS-virksomhetenes arbeid med flerspråklige barn og ungdommer FOKUS-virksmhetenes arbeid med flerspråklige barn g ungdmmer NAFOs Østfldknferanse 13.11.12 Observasjn g samtaler fra Kjølberg, Os, Malakff g Verket skler, tspråklige lærere g FRIS i Østfld, Kulås g Prestenga

Detaljer

STATUSRAPPORT Familieprosjekt i 2006

STATUSRAPPORT Familieprosjekt i 2006 STATUSRAPPORT Familieprsjekt i 2006 Tittel på tiltak/prsjekt: Familieprsjektet 2006 ved Helgelandssykehuset M i Rana. Prsjektleder: Tve Lill Røreng Falstad Frist: 1. mars 2007. Rapprten sendes per pst

Detaljer

Samfunnsviternes kommunikasjonsplattform

Samfunnsviternes kommunikasjonsplattform Samfunnsviternes kmmunikasjnsplattfrm Innledning Alle rganisasjner, uansett størrelse, har behv fr gd kmmunikasjn fr å løse sine ppgaver. Det å ønske å benytte kmmunikasjn strategisk innebærer et frmål

Detaljer

Kvalitetshåndbok BVS. for. Basert på ISO 9001;2008. Utgave Nr. Revisjons dato. 01 01.11.09 Første utgave F. Hinrichsen

Kvalitetshåndbok BVS. for. Basert på ISO 9001;2008. Utgave Nr. Revisjons dato. 01 01.11.09 Første utgave F. Hinrichsen Kvalitetshåndbk fr BVS Basert på ISO 90;2008 Utgave Nr. Revisjns dat Kmmentarer Gdkjent.11.09 Første utgave Dk. nr. Nivå 1- Revisjn: BVS Kvalitets Håndbk Dat:.11.09 Gdkjent av: 1. Omfang... 4 1.1. Litt

Detaljer

Belbinrapport Samspill i par

Belbinrapport Samspill i par Belbinrapprt Samspill i par Oppsummerende beskrivelse Teamrlle Bidrag Tillatte svakheter Ideskaper Kreativ, fantasirik, utradisjnell. Løser vanskelige utfrdringer. Overser detaljer. Kan være fr pptatt

Detaljer

Rapport fra rådgivningsgruppe for økonomistyring ved St. Olavs Hospital HF

Rapport fra rådgivningsgruppe for økonomistyring ved St. Olavs Hospital HF Rapprt fra rådgivingsgruppe fr øknmistyring ved St. Olavs Hspital HF 1 av 38 Rapprt fra rådgivningsgruppe fr øknmistyring ved St. Olavs Hspital HF 5. februar 2007 Rapprt fra rådgivingsgruppe fr øknmistyring

Detaljer

Internrevisjon. Dokumentflyt i pasientarbeidet Henvisningsrutiner. Sykehuset i Vestfold HF

Internrevisjon. Dokumentflyt i pasientarbeidet Henvisningsrutiner. Sykehuset i Vestfold HF Internrevisjn Dkumentflyt i pasientarbeidet Henvisningsrutiner Sykehuset i Vestfld HF Innhldsfrtegnelse 1. Innledning frmål g prblemstillinger...3 2. Beskrivelse av virksmheten...4 Særlig m de reviderte

Detaljer

Forberedende kurs for. VG3 eksamen. Energioperatør

Forberedende kurs for. VG3 eksamen. Energioperatør Frberedende kurs fr VG3 eksamen Energiperatør Bakgrunn Energi Nrge har på vegne av energibransjen ver en peride arbeidet med å perasjnalisere energifagene fr på den måten tilrettelegge fr en mer målrettet

Detaljer

Pasientsikkerhetsprogrammet i trygge hender

Pasientsikkerhetsprogrammet i trygge hender Pasientsikkerhetsprgrammet i trygge hender Riktig legemiddelbruk i sykehjem g hjemmetjeneste Kmpendium til frbedringsteamene i Rgaland Januar 2014 Innhldsfrtegnelse Side Velkmmen til læringsnettverk Hva

Detaljer

ÅS KOMMUNE PERIODEPLAN FRYDENHAUG BARNEHAGE AVD. EIKA

ÅS KOMMUNE PERIODEPLAN FRYDENHAUG BARNEHAGE AVD. EIKA ÅS KOMMUNE PERIODEPLAN FRYDENHAUG BARNEHAGE AVD. EIKA Januar Mars 2011 GODT NYTTÅR! Så er vi klare fr et nytt år med mange nye muligheter! Den første tiden i høst ble brukt til å få alle barna på plass

Detaljer

Smarte målere (AMS) Status og planer for installasjon og oppstart per 1. kvartal 2015. Arne Venjum, Cathrine Åsegg Hagen 77

Smarte målere (AMS) Status og planer for installasjon og oppstart per 1. kvartal 2015. Arne Venjum, Cathrine Åsegg Hagen 77 Smarte målere (AMS) Status g planer fr installasjn g ppstart per 1. kvartal 2015 Arne Venjum, Cathrine Åsegg Hagen 77 2015 R A P P O R T Smarte målere (AMS) Utgitt av: Redaktør: Frfattere: Nrges vassdrags-

Detaljer

LEIRFJORD KOMMUNE SAKSFRAMLEGG. Saksbehandler: Britt Jonassen Arkiv: 030 Arkivsaksnr.: 14/203-16 Klageadgang: Nei

LEIRFJORD KOMMUNE SAKSFRAMLEGG. Saksbehandler: Britt Jonassen Arkiv: 030 Arkivsaksnr.: 14/203-16 Klageadgang: Nei LEIRFJORD KOMMUNE SAKSFRAMLEGG Saksbehandler: Britt Jnassen Arkiv: 030 Arkivsaksnr.: 14/203-16 Klageadgang: Nei ORGANISASJONSSTRUKTUR LEIRFJORD KOMMUNE Administrasjnssjefens innstilling: ::: &&& Sett inn

Detaljer

Invitasjon til dialogkonferanse. Tema: Ny rammeavtale på kundeinformasjonselementer til bruk i Jernbaneverkets infrastruktur.

Invitasjon til dialogkonferanse. Tema: Ny rammeavtale på kundeinformasjonselementer til bruk i Jernbaneverkets infrastruktur. Invitasjn til dialgknferanse Tema: Ny rammeavtale på kundeinfrmasjnselementer til bruk i Jernbaneverkets infrastruktur. Innledning Omfanget g kmpleksiteten i ffentlig transprt er knstant økende stadig

Detaljer

Styremøte 5. mars 2015

Styremøte 5. mars 2015 Styremøte 5. mars 2015 Sted: Ruter, Drnningens gate 40 Tid: Kl. 10.00 14.00 Saker.: 11 /15 23/15 Sakliste til styremøte 5. mars 2015 Saksnr.: Sak Sak 11/15 Referat fra styremøte 29. januar 2015 Sak 12/15

Detaljer

Kommunens utfordringer knyttet til informasjonsforvaltning

Kommunens utfordringer knyttet til informasjonsforvaltning KS - Arkivgruppe Kmmunens utfrdringer knyttet til infrmasjnsfrvaltning Sjekkliste fr anskaffelse av sak-/arkivsystem Side 2 av 13 Innhld 1 Innledning... 3 2 Bakteppe... 3 3 Sjekkliste... 4 3.1 Behvsavklaring...

Detaljer

Konkurransegrunnlag Bistand til kartlegging og analyse av arbeidsprosesser samt utvikling av funksjonell prototyp

Konkurransegrunnlag Bistand til kartlegging og analyse av arbeidsprosesser samt utvikling av funksjonell prototyp Knkurransegrunnlag Bistand til kartlegging g analyse av arbeidsprsesser samt utvikling av funksjnell prttyp Side 1 av 12 Innhldsfrtegnelse INNHOLDSFORTEGNELSE 2 1. OPPLYSNINGER OM ANSKAFFELSEN 3 1.1 OPPDRAGSGIVER

Detaljer

INNHOLDSFORTEGNELSE. DEL 2: BAKGRUNN.. 10 2a. Mandat. 11 2b. Definisjoner og teoretisk forankring 12 2c. Avgrensing. 14

INNHOLDSFORTEGNELSE. DEL 2: BAKGRUNN.. 10 2a. Mandat. 11 2b. Definisjoner og teoretisk forankring 12 2c. Avgrensing. 14 INNHOLDSFORTEGNELSE DEL 1: INNLEDNING OG OPPSUMMERING 3 1a. Innledning.. 4 1b. Oppsummering.. 6 1c. Arbeidsmåte i frprsjektet.. 8 1d. Oppbygging av dkumentet.. 9 1 DEL 2: BAKGRUNN.. 10 2a. Mandat. 11 2b.

Detaljer

Årsplan. 2011-2013. MØLLEPLASSEN Kanvas-barnehage. Små barn store muligheter. www.kanvas.n o

Årsplan. 2011-2013. MØLLEPLASSEN Kanvas-barnehage. Små barn store muligheter. www.kanvas.n o Årsplan. 2011-2013 MØLLEPLASSEN Kanvas-barnehage Små barn stre Kanvas pedaggisk plattfrm Læring g Læringssyn - I Kanvas ser vi på barn sm aktive, kmpetente g ressurssterke individ. Barns nysgjerrighet

Detaljer

DELRAPPORT 3/2011 KOMPETANSE

DELRAPPORT 3/2011 KOMPETANSE JEG VET HVA SOM FORVENTES AV MEG PÅ JOBBEN DELRAPPORT 3/2011 KOMPETANSE STRAFFEGJENNOMFØRING MED ELEKTRONISK KONTROLL Tre Rkkan senirrådgiver Kriminalmsrgens utdanningssenter KRUS Avdeling fr frskning

Detaljer

Et forslag til moduler. Lesing og skriving

Et forslag til moduler. Lesing og skriving Et frslag til mduler Lesing g skriving INNHOLDSFORTEGNELSE Frrd Grunnlaget Kartlegging Mdulene Lesing Mdul 1: Lesemåter Mdul 2: Målretting g førfrståelse Mdul 3: Lesefrståelse g metakgnisjn Mdul 4: Ordfrråd

Detaljer

Dagens situasjon... 1 Hano... 1. Systemet inneholder følgende funksjonalitet:... 6. Problemer:... 4 Fixit... 4

Dagens situasjon... 1 Hano... 1. Systemet inneholder følgende funksjonalitet:... 6. Problemer:... 4 Fixit... 4 Analyse Innhld Dagens situasjn... 1 Han... 1 Systemet innehlder følgende funksjnalitet:... 2 Prblemer:... 4 Fixit... 4 Systemet innehlder følgende funksjnalitet:... 6 Prblemer:... 8 Følgende funksjnalitet

Detaljer

PROSJEKTET SPoR VESTFOLD SAMHANDLING RUS OG PSYKIATRI

PROSJEKTET SPoR VESTFOLD SAMHANDLING RUS OG PSYKIATRI STATUSRAPPORT JUNI 2012 PROSJEKTET SPR VESTFOLD SAMHANDLING RUS OG PSYKIATRI Ved prsjektleder Vidar Bjørn Prsjektet løper ver fire år 2010-2013. I tillegg til ne egen finansiering, er prsjektet gjrt mulig

Detaljer

TILLITSVALGTE: Intervjuguide

TILLITSVALGTE: Intervjuguide TILLITSVALGTE: Intervjuguide 1. Om prsjektet, annymitet 2. Bakgrunnsinfrmasjn Erfaring sm tillitsvalgt antall år i vervet, ppgaver Ansatte rganisasjnsgrad, frhld til eventuelle andre klubber i virksmheten

Detaljer

Spørsmål som skal besvares og dokumenters av Tilbyder

Spørsmål som skal besvares og dokumenters av Tilbyder Vedlegg 8.1 Til pkt 8 i knkurransegrunnlaget «Krav til Tilbudets innhld» Spørsmål sm skal besvares g dkumenters av Tilbyder i frbindelse med anskaffelse av System fr behandling av skleskysselever i Vestfld

Detaljer

SAKSFRAMLEGG. Sluttbehandlende vedtaksinstans (underinstans): Kommunestyret Dok. offentlig: Ja Nei. Hjemmel:

SAKSFRAMLEGG. Sluttbehandlende vedtaksinstans (underinstans): Kommunestyret Dok. offentlig: Ja Nei. Hjemmel: IKKE RØR LINJA Saksbehandler: Inga Marie Lund SAKSFRAMLEGG Sluttbehandlende vedtaksinstans (underinstans): Kmmunestyret Dk. ffentlig: Ja Nei. Hjemmel: Møte ffentlig Ja Nei. Hjemmel: Kmm.l 31 Klageadgang:

Detaljer

David Hyerles 8 Tenkekart

David Hyerles 8 Tenkekart David Hyerles 8 Tenkekart Dr. Hyerle s Tenkekart: Verktøy fr arbeid med grunnleggende ferdigheter g styrket rdkunnskap. Bakgrunn: I 2010 startet Utdanningsadministrasjnen g 4 Oslskler et utviklingsprsjekt

Detaljer

1 GENERELL INFORMASJON 3 2 MODULER 5 3 HOVEDMENY 6 4 WORK WITH DOCUMENT LOG 7 5 UPDATE PARTNER INFORMATION 9 6 UPDATE COMPANY PARAMETERS 18

1 GENERELL INFORMASJON 3 2 MODULER 5 3 HOVEDMENY 6 4 WORK WITH DOCUMENT LOG 7 5 UPDATE PARTNER INFORMATION 9 6 UPDATE COMPANY PARAMETERS 18 beskrivelse/brukerdkumentasjn ECP sftware ECP supprt 1 f 39 1 GENERELL INFORMASJON 3 1.1 DEFINISJONER BRUKT I DETTE DOKUMENT 3 1.2 FORKORTELSER 3 1.3 SYSTEMPARAMETER 3 1.4 PARTNERINFORMASJON 3 1.5 UTVEKSLINGSLOGG

Detaljer

Innhold. 1. Innledning... 3. 2. Strategi og overordnede retningslinjer... 4. 2.1 Strategi... 4 2.2 Risikorammer... 5 2.3 Sentrale retningslinjer...

Innhold. 1. Innledning... 3. 2. Strategi og overordnede retningslinjer... 4. 2.1 Strategi... 4 2.2 Risikorammer... 5 2.3 Sentrale retningslinjer... Risikbasert tilsyn Mdul fr markeds- g kredittrisik i frsikring Evaluering av styring g kntrll DATO: 10.09.2010 Mdul fr markeds- g kredittrisik i frsikring Innhld 1. Innledning... 3 2. Strategi g verrdnede

Detaljer

UNIVERSITETET I OSLO PROSJEKT NIKE «NY, INTEGRERT KALENDER OG E-POST» RESULTATER AV BRUKERUNDERSØKELSEN. NIKE Brukerundersøkelse 1

UNIVERSITETET I OSLO PROSJEKT NIKE «NY, INTEGRERT KALENDER OG E-POST» RESULTATER AV BRUKERUNDERSØKELSEN. NIKE Brukerundersøkelse 1 UNIVERSITETET I OSLO PROSJEKT NIKE «NY, INTEGRERT KALENDER OG E-POST» RESULTATER AV BRUKERUNDERSØKELSEN NIKE Brukerundersøkelse 1 FORORD Universitetet i Osl satte i 211 gang prsjektet NIKE (Ny Integrert

Detaljer

SLUTTRAPPORT «HVORDAN FÅ UNGE TIL Å ØNSKE SEG EN KARRIERE I VAREHANDEL?»

SLUTTRAPPORT «HVORDAN FÅ UNGE TIL Å ØNSKE SEG EN KARRIERE I VAREHANDEL?» SLUTTRAPPORT «HVORDAN FÅ UNGE TIL Å ØNSKE SEG EN KARRIERE I VAREHANDEL?» Laget av: Inger Karin Engdal Rådgiver Oktber 2014 1 Bakgrunn: Varehandelen er Nrges største private arbeidsplass g karrieremulighetene

Detaljer

Universitetet i Oslo Institutt for statsvitenskap

Universitetet i Oslo Institutt for statsvitenskap Universitetet i Osl Institutt fr statsvitenskap Referat fra prgramrådsmøtet fr Offentlig administrasjn g ledelse - 3. juni 2015 Til stede: Jan Erling Klausen, Karine Nybrg, Haldr Byrkjeflt, Malin Haglund,

Detaljer

Forebygging og håndtering av vold og trusler mot ansatte

Forebygging og håndtering av vold og trusler mot ansatte Frebygging g håndtering av vld g trusler mt ansatte - retningslinjer i Gausdal kmmune Innhld: A. Generelt, - m begrepet vld g trusler - m arbeidsmiljølven. B. Kartlegging av risik fr vld g trusler - vurdere

Detaljer

KARLSØY KOMMUNE - KOMMUNEPLAN 2007 2020

KARLSØY KOMMUNE - KOMMUNEPLAN 2007 2020 KARLSØY KOMMUNE - KOMMUNEPLAN 2007 2020 PLANPROGRAM Sammen m utviklingen av Karlsøy-samfunnet - hva er våre viktigste utfrdringer? Karlsøy kmmunes beflkning inviteres til flkemøter iht. følgende møteplan:

Detaljer

Kartlegging av kommunikasjonsarbeid i kommunesektoren

Kartlegging av kommunikasjonsarbeid i kommunesektoren Kartlegging av kmmunikasjnsarbeid i kmmunesektren 1) Svarer du fr en Kmmune Fylkeskmmune 2) Navn på kmmunen/fylkeskmmunen Følgende kriterier må være ppfylt fr at spørsmålet skal vises fr respndenten: Hvis

Detaljer

BUSP II Kvalitetssikring av konseptutredning

BUSP II Kvalitetssikring av konseptutredning www.pwc.n BUSP II Kvalitetssikring av knseptutredning Rapprt til Helse Bergen HF 25. september 2013 Frrd Denne rapprten er et resultat av kvalitetssikring KSK av Frnyet knseptutredning fr BUSP2 i Helse

Detaljer

INNHOLDSFORTEGNELSE: ØSTMOJORDET BARNEHAGE... 3 HVITVEISEN..3 BLÅKLOKKA OG SMØRBLOMSTEN 4 LEK GIR LÆRING ET UTVIKLINGSARBEID 4 LEKEGRUPPER.

INNHOLDSFORTEGNELSE: ØSTMOJORDET BARNEHAGE... 3 HVITVEISEN..3 BLÅKLOKKA OG SMØRBLOMSTEN 4 LEK GIR LÆRING ET UTVIKLINGSARBEID 4 LEKEGRUPPER. 1 INNHOLDSFORTEGNELSE: ØSTMOJORDET BARNEHAGE... 3 HVITVEISEN..3 BLÅKLOKKA OG SMØRBLOMSTEN 4 LEK GIR LÆRING ET UTVIKLINGSARBEID 4 LEKEGRUPPER.4 HJERTEPROGRAMMET.5 FAGOMRÅDER I FOKUS..5 ÅRSOVERSIKT BLÅKLOKKA

Detaljer

Veileder Arrangering av Landsstyremøter Vedtatt: 30.08.2015 av Nasjonalt styre, Norsk medisinstudentforening

Veileder Arrangering av Landsstyremøter Vedtatt: 30.08.2015 av Nasjonalt styre, Norsk medisinstudentforening Veileder Arrangering av Landsstyremøter Vedtatt: 30.08.2015 av Nasjnalt styre, Nrsk medisinstudentfrening Fr å sikre at det er tydelig hvilken planlegging sm er nødvendig fr et møte i Landsstyret etableres

Detaljer

Bakgrunnsdokumentasjon om efaktura. Portwin og efaktura. Versjon: 0,8

Bakgrunnsdokumentasjon om efaktura. Portwin og efaktura. Versjon: 0,8 Bakgrunnsdkumentasjn m efaktura Prtwin g efaktura Frfatter: Aud Eva Haugrs g Olav Madland Versjn: 0,8 1 1. Bakgrunn Fra 01.07.2012 krever statlige g kmmunale fretak g mtta fakturaer i frm av efaktura.

Detaljer

Rektors spørsmål om avdelingenes planer

Rektors spørsmål om avdelingenes planer Vedlegg 1 til ntat m årsrapprt 27.06.14 Rektrs spørsmål m avdelingenes planer Svarene sendes inn sammen med andre innspill sm har frist 7.ktber. Hvedutfrdring AFT: Få til daglig drift i byggeperiden nytt

Detaljer

DELMÅL 1: ØKE OPPSLUTNINGEN OM ALKOVETT OG ALKOHOLFRIE SONER GJENNOM HOLDNINGSSKAPENDE ARBEID... 3

DELMÅL 1: ØKE OPPSLUTNINGEN OM ALKOVETT OG ALKOHOLFRIE SONER GJENNOM HOLDNINGSSKAPENDE ARBEID... 3 HANDLINGSPLAN 2015 INNHOLD HOVEDMÅL... 2 DELMÅL 1: ØKE OPPSLUTNINGEN OM ALKOVETT OG ALKOHOLFRIE SONER GJENNOM HOLDNINGSSKAPENDE ARBEID... 3 Alkvett... 3 Arbeidsliv:... 4 Båt- g badeliv:... 5 Graviditet:...

Detaljer

«Barna skal få utfolde skaperglede, undring og utforskertrang. De skal lære å ta vare

«Barna skal få utfolde skaperglede, undring og utforskertrang. De skal lære å ta vare «Barna skal få utflde skaperglede, undring g utfrskertrang. De skal lære å ta vare på seg selv, hverandre g naturen. Barna skal utvikle grunnleggende kunnskaper g ferdigheter. De skal ha rett til medvirkning

Detaljer

Styringsgruppen for prosjekt Kvalitet i praksisstudier

Styringsgruppen for prosjekt Kvalitet i praksisstudier Styringsgruppen fr prsjekt Kvalitet i praksisstudier Deltakere i styringsgruppen: Bente Skulstad, leder (Helsedirektratet), Nina Langeland (medisinutdanning), Pål Barkvll (dntlgiutdanning), Ingunn Skre

Detaljer

NY VURDERING AV SELVKOSTPRINSIPPET

NY VURDERING AV SELVKOSTPRINSIPPET Saksfremlegg Saksnr.: 10/3966-6 Arkiv: 611 &52 Sakbeh.: Berit Erdal Sakstittel: NY VURDERING AV SELVKOSTPRINSIPPET Planlagt behandling: Frmannskapet Innstilling: ::: &&& Sett inn innstillingen under IKKE

Detaljer

Matindustriens Opplæringskontor i Oslo og Akershus OPPLÆRINGSBOK FOR AUTOMATISERINGSFAGET

Matindustriens Opplæringskontor i Oslo og Akershus OPPLÆRINGSBOK FOR AUTOMATISERINGSFAGET Matindustriens Opplæringskntr i Osl g Akershus OPPLÆRINGSBOK FOR AUTOMATISERINGSFAGET Gjennmføringsskjema fr pplæring i bedrift Autmatiseringsfaget Navn: Bedrift: Læretid: Prgramfag: Autmatiseringssystemer

Detaljer

BRUKERVEILEDNING - P360 VED NMBU. 1 Skjerming og tilgangsgrupper Versjon/dato for revisjon: 25.09.2014

BRUKERVEILEDNING - P360 VED NMBU. 1 Skjerming og tilgangsgrupper Versjon/dato for revisjon: 25.09.2014 BRUKERVEILEDNING - P360 VED NMBU 1 Skjerming g tilgangsgrupper Versjn/dat fr revisjn: 25.09.2014 P360-klient: Outlk g web Utarbeidet av: Mnica Narum Dat: 25.09.2014 Ansvarlig: Arkivet/Dkumentsenteret Frmålet

Detaljer