2. PROCESSERNE. 2.1 De mange perspektiver

Save this PDF as:
 WORD  PNG  TXT  JPG

Størrelse: px
Starte visningen fra side:

Download "2. PROCESSERNE. 2.1 De mange perspektiver"

Transkript

1 2. PROCESSERNE I dette kapitel vil vi kigge nærmere på processerne: dels selve projektledelsesprocessen, dels udviklingsprocessen som er den måde man udvikler software på, og endelig de læreprocesser som er involveret. Projektledelse er nemlig en multiperspektivisk disciplin. 2.1 De mange perspektiver En historie som ofte bruges til at beskrive nødvendigheden af et multiperspektivisk syn, er historien om de blinde mænd og elefanten. Den stammer fra et digt af den amerikanske digter John Godfrey Saxe ( ) som igen baserer sig på en gammel indisk fortælling. Digtet er langt, så her genfortælles det kun (find det evt. selv på nettet): De blinde mænd og elefanten Seks blinde mænd bliver præsenteret for en elefant. Den første ramler ind i siden på dyret og udbryder: En elefant er som en mur. Den næste kommer til at føle på stødtanden og mener at en elefant er som et spyd. Den tredje føler på snabelen og udtaler kategorisk at en elefant er som en slange. Den fjerde får fat i et ben, så en elefant må være som et træ. Den femte rører ved øret og er overbevist om at der er tale om en vifte, mens den sjette som rører halen, synes at en elefant er som et reb. Herefter skændes de så om hvordan en elefant egentlig er. Projektledelse er ligesom en elefant: det afhænger af den vinkel man ser det fra, og et perspektiv (eng.: view) er netop en synsvinkel, dvs. måden at se tingene på ud fra et bestemt ståsted. Overordnet kan vi anlægge tre hovedperspektiver: PRODUKTPERSPEKTIVET ser projektet som noget der skal frembringe et produkt med bestemte egenskaber. INTERESSENTPERSPEKTIVET eller samarbejdsperspektivet ser projektet som et samspil mellem mennesker. PROCESPERSPEKTIVET ser projektet som en løbende proces der bringer os fra en situation til en anden. 2 PROCESSERNE 29

2 Herunder kan anlægges forskellige specialperspektiver som typisk afhænger af hvad man mener er vigtigt i projektet: STYRINGSPERSPEKTIVET ser projektet som en række aktiviteter der gennemføres i en nærmere planlagt rækkefølge. FORRETNINGSPERSPEKTIVET ser projektet som et middel til at understøtte virksomhedens forretning. Her kan der f.eks. være fokus på effektivisering og profitmaksimering. BRUGERPERSPEKTIVET ser projektet som noget der skal opfylde brugernes behov. Her drejer det sig om at involvere brugerne i projektet, brugbarhed og brugervenlighed osv. LÆRINGSPERSPEKTIVET ser projektet som en række læreprocesser hvor vi gradvist bliver klogere mht. de forskellige dele. KVALITETSPERSPEKTIVET ser projektet som en række delprodukter som hver for sig skal leve op til aftalte kvalitetskriterier. Her er der fokus på inspektioner og test. INFORMATIONSPERSPEKTIVET ser projektet som en række informationer (data) som skal indsamles, gemmes og behandles. ARKITEKTURPERSPEKTIVET ser projektet som en struktur opbygget af en række komponenter der arbejder sammen. osv. Nogle af disse perspektiver kan være sammenhængende, men de afspejler hver for sig en måde at opfatte projektet på, et ståsted at se det fra, et verdensbillede. Man ser det samme projekt, men fra vidt forskellige synsvinkler. Nogle af perspektiverne kan bruges til at drive projektet, dvs. til at styre hvad der skal ske hvornår. Der er således udviklingsmodeller som er use case-drevne, arkitekturdrevne eller risikodrevne. Ligesom med de blinde mænd er alle perspektiverne en del af helheden. Og det er en god ide at bruge flere perspektiver. Forskellighed gør stærk. Vi vender senere tilbage til disse specialsyn i afsnittet om Interessentanalyse. Disse perspektiver kan også have andre navne, f.eks. dimensioner, aspekter, facetter, parametre, fokusområder eller discipliner. 2.2 Andre brancher Mennesker organiserer udviklingsprocessen på mange forskellige måder, afhængigt af hvad man skal lave. Alligevel er der visse fælles træk, og man kan lære meget af at se hvordan andre gør, så lad os starte med at se hvordan man griber udviklingsprocessen 30 2 PROCESSERNE

3 an uden for it-branchen i nogle af de brancher som man ofte sammenligner it-udvikling med. Se i øvrigt også det senere afsnit om Store ledere (side 68). Brobygning Ofte sammenlignes it-udvikling med brobygning. Ikke, at vi i it-branchen skal falde på halen for de dygtige brobyggere der kan levere til tiden, bare sådan lige og helt uden problemer. For det kan de som bekendt ikke. Fejl, dårlig kvalitet, fordyrelser og store forsinkelser finder også sted i brobygningsbranchen. Jf. Storebæltstunnelen der først blev oversvømmet og siden brandhærget (havde det så endda blot været samtidig!). Alligevel kan it-udviklere lære meget af brobyggere. Tacoma-broen I staten Washington i det nordvestlige USA havde man bygget en hængebro over Tacoma-snævringen, Tacoma Narrows Bridge. Det var en af de første hængebroer, så man havde ikke mange erfaringer med denne brotype. Den 7. november 1940 gik det helt galt. Når vindhastigheden bliver for høj, kan hængebroer nemlig sættes i en voldsom kombination af vridninger og lodrette svingninger (såkaldt flutter). Dette kan forhindres ved at gøre brodækket tilstrækkeligt vridningsstabilt. Imidlertid havde designeren af Tacoma-broen i øvrigt på trods af advarsler valgt en mindre vridningsstabil løsning for derved at gøre broen billigere. Broen blev simpelthen vredet itu og faldt ned. Heldigvis kom ingen mennesker noget til (har du ikke set de spektakulære billeder, findes der videoklip på nettet). Brobyggerne lærte en masse af den historie, og i dag er det normalt at den slags anlæg testes i en vindtunnel, så man ved hvordan de opfører sig i blæsevejr. Tilsvarende burde det være helt normalt at alle større it-systemer gennemgik performancetest og test i et brugervenlighedslaboratorium før de blev sluppet løs. Et af de steder hvor it-udvikling adskiller sig mest fra brobygning, er at vi ofte har muligheden for at udvikle systemerne i mindre bidder. Som bekendt kan man ikke starte en bro med et frit spænd på meter ved at sige: Nu lægger vi lige en planke over, og så tager vi det lidt ad gangen. Og når ankerblokkene er støbt i mange tusind tons beton, kan man heller ikke lige komme og bede om at få dem flyttet et par meter mod nord. Men ved udvikling af et it-system kan man som regel lave det i en iterativ proces hvor man i gentagne 2 PROCESSERNE 31

4 delleverancer føjer mere og mere funktionalitet til systemet. Denne teknik åbner desuden mulighed for at måle på kvaliteten af systemet undervejs. Desværre åbner fastpriskontrakter sjældent mulighed for en sådan iterativ proces, og det er egentlig synd for alle parter. Men der er ikke noget i vejen for at en fastpriskontrakt kan stille krav om kvalitetsmålinger undervejs (se historien side 329 om Øresundsbroens pyloner). Ofte bruges ingeniørdisciplin generelt som metafor for it-udvikling. Tidligere talte man ligefrem om software engineering. Det vi kan lære af ingeniørernes tilgang, er den detaljerede planlægning før vi går i gang (i det omfang det er muligt) samt den præcise kvalitetsstyring undervejs. Og at vi skal kende vores teknikker før vi bruger dem i stor skala. Man skal kravle før man kan gå. Krigskunst Ordet kunst i denne forbindelse, hvor det handler om at slå mennesker ihjel, er ilde valgt. Alligevel er det den betegnelse man sommetider ser anvendt af dem som gør sig tanker om det at føre krig. Ofte drages også paralleller mellem krigskunst og it-udvikling. Sammenligningen er forståelig. Begge dele handler om at: gennemføre en ofte svær opgave som ikke er prøvet før mange menneskers koordinerede indsats er nødvendig planlægning, koordinering og kommunikation er essentiel handlekraft når virkeligheden viser sig at være anderledes end planerne, er lige så essentiel ord som strategisk, taktisk og operationel er anvendelige til at anskue processen fra forskellige detaljeringsniveauer. Og så kan vi lære noget fordi tingene bliver tydeligere (mere accentuerede) når de kommer ud i ekstremerne. I [Munk-Madsen96] fremhæves således et af de vægtigste militærteoretiske bidrag i moderne tid, von Clausewitz bog Vom Kriege, der beskriver strategiens betydning ved ledelse af vanskelige og usikre opgaver. Det var her forståelsen af krigen som politikkens fortsættelse blev introduceret. Her slås det bl.a. fast at vi ikke kan planlægge i detaljer præcist hvordan slaget vil forløbe der er for mange ukendte faktorer, og virkeligheden ser alligevel altid helt anderledes ud end vi tror. Det vi ikke bør lære af krigskunsten, som den er praktiseret op gennem historien, er den militæriske kadaverdisciplin og kæft-trit-og-retning-mentalitet hvor en ordre skal følges, uanset hvad. Det virker sjældent på it-udviklere som bare kan tage deres gode tøj og gå over til et andet firma. Og som man i den moderne militærverden har erkendt, virker det heller ikke på nutidens soldater PROCESSERNE

5 Flyvning Der er mange lighedspunkter mellem en flypilot og en projektleder: begge har det overordnede ansvar for opgaven ingen af dem kan løse opgaven tilfredsstillende uden andre ingen af opgaverne kan løses uden dem begge er underlagt højere myndigheder i udførelsen af opgaven det er i dårligt vejr og med brand i den ene motor at de for alvor skal vise hvad de dur til. Det vi kan lære af piloterne, er den udelte opmærksomhed på at materiellet og forudsætningerne er på plads, gennemprøvede og i orden inden vi går i gang. Også brugen af tjeklister og fornuftige systemer som løbende forbedres når vi opdager fejl og uhensigtsmæssigheder. Det vi ikke bør lære, er de nøje fastlagte flyruter som moderne flyvning gør brug af. Hertil er it-udvikling for uforudsigelig. Filmproduktion Når der skal produceres en film, skal man først have en god historie: den fælles vision. Her bruges et story board (opfundet af Walt Disney til brug ved tegnefilmproduktion). Der laves detaljerede planer for optagelser af de enkelte scener. Ofte i total forvirring i forhold til den færdige film. Skal der bruges to scener i den samme kulisse, men to forskellige steder i filmen, er det smartest at optage begge scener når man har hele holdet samlet det rigtige sted. Og så klippe det sammen senere. Men det kræver en detaljeret planlægning (scripting). Holdet forsøges også sammensat så optimalt som muligt i en casting hvor man finder de bedste skuespillere til rollerne. Så her kan vi lære noget om detaljeret planlægning af de enkelte scener (i it-sammenhæng: planlægning af de enkelte iterationer), men sandelig også om nødvendigheden af improvisation undervejs. F.eks. når skuespillerne begynder at leve sig ind i rollen og kommer med ændringsforslag. Det vi ikke bør lære af filmproduktion, er at hele manuskriptet skal være detaljeret fastlagt inden vi går i gang. Det kan kun sjældent lade sig gøre ved it-udvikling. Planteavl Selv holder jeg meget af at betragte projektlederen som en gartner. Der er en række gode paralleller mellem gartneri og projektledelse: Man høster som man sår. Dvs. udbyttet er afhængigt af de frø man starter med. En god gødning er med til at få planterne til at udvikle sig. 2 PROCESSERNE 33

6 Gartneren skal beskytte planterne mod angreb fra skadedyr. Det betaler sig at forebygge angreb f.eks. ved sprøjtning. Et godt (rod-)netværk er vigtigt for plantens vækst. Mange planter elsker sol og varme. Af gartneren kan vi lære at tålmodighed og forudseenhed betaler sig. Gartneren kan ikke selv lave frugter, det kan kun planterne. 2.3 Projektledelsesprocessen Selve projektledelsesprocessen er en generisk proces som det kan være hensigtsmæssigt at have gjort sig klart. Den vil vi se på i dette afsnit, og i det senere afsnit om Udviklingsprocessen vil vi se på hvordan den udmøntes til softwareudvikling. Vi skelner mellem ledelse og styring. Ledelse handler om at gøre de rigtige ting, mens styring handler om at gøre tingene rigtigt. Begge dele er vigtige at kunne for en projektleder. Men faktisk har vi tre niveauer: Fig. 2.1: De tre styringsniveauer For god ordens skyld skal du vide at denne trekant normalt bruges på hele virksomheden. Her bruger vi den dog kun på projektet. I A guide to the project management body of knowledge den såkaldte PMBOK Guide fra Project Management Institute ([PMI2000]) skelnes mellem fem projektledelsesprocesser: 34 2 PROCESSERNE

7 OPSTART hvor projektet etableres PLANLÆGNING hvor målet lægges fast, og kursen udstikkes UDFØRELSE hvor arbejdet rent faktisk udføres OPFØLGNING hvor det sikres at vi laver det vi aftalte NEDLUKNING hvor projektet bringes til en kontrolleret afslutning. Denne opdeling kan også bruges på mindre faser i et større projekt. Og du vil kunne genfinde alle elementerne i de kommende kapitler. Der findes andre bud på en generisk projektledelsesproces, f.eks. den engelske PRINCE2 (bl.a. beskrevet i [Hughes99]) Kunsten at styre Når vi bruger ordet styre, har vi allerede en intuitiv fornemmelse af hvad der menes. Det er nærliggende at lave analogier til andre situationer hvor vi styrer, f.eks.: når vi kører bil, styrer vi. Vi gør det for at komme det rigtige sted hen og for at komme uden om forhindringer når man flyver, sidder der en pilot forrest i flyet og styrer det. Men styring er ikke bare at dreje på rattet. Styring involverer flere discipliner: Før turen: Hvor skal vi hen? Der skal ske en fastlæggelse af målet. Hvordan kommer vi det? Hvilken vej skal vi? Er der evt. risiko for uvejr eller andre forhindringer på en del af ruten, så vi skal lægge vejen udenom? Der skal ske en planlægning. Hvor lang tid tager det? Der skal ske en tidsestimering. Undervejs: Er der forhindringer forude? I bilen kan vi blot kigge ud ad forruden for at opdage eventuelle forhindringer. I fly kan vi bruge radar og automatiske landingssystemer, i ubåde kan vi bruge sonar osv. I projektet må vi også benytte os af indirekte metoder til at kigge fremad. Vi må synliggøre vejen foran os. Og det er betydeligt vanskeligere at synliggøre it-udvikling end mere fysiske fænomener (som f.eks. klippeskæret foran ubåden). Vi gør det i form af projektplaner, statusrapporter, reviews, kravspecifikationer, evalueringer osv. 2 PROCESSERNE 35

8 Aktiv styring: drej på rattet når der skal skiftes kurs. I projektet foretages ændring af bemanding, ændring af opgaver, igangsættelse af nye aktiviteter osv. Er vi hvor vi tror? Uforudsete ting kan bringe os ud af kurs (kastevinde, vildspor), og en gang imellem skal vi kontrollere at vi er der hvor vi tror vi er. Vi bruger her milepælene langs vejen eller andre kendingsmærker på landkortet. På havet, hvor der ingen kendingsmærker er, må vi navigere efter andre pejlemærker, f.eks. stjerner. Og i dag har de fleste installeret en GPS-navigator som bestemmer positionen ved hjælp af satellitter. I projektet må vi bruge de fastlagte tjekpunkter til at finde ud af hvor vi er. Efter turen: Kan vi gøre det bedre næste gang? Her skilles de professionelle fra amatørerne. De sidste er glade for at være kommet frem, men de professionelle ved at de skal på den igen. Så de sætter sig ned sammen med kollegerne og diskuterer hvad der skete på turen, og om det var gået bedre hvis de havde handlet anderledes end de gjorde. Det gælder også i projektet hvor der skal foretages en projekt-evaluering når projektet er slut, for at finde ud af hvilke ting vi kan gøre bedre næste gang Syvlagsmodellen Det kan være nyttigt at betragte selve styringsprocessen ud fra følgende syvlags-model som står for min egen regning (HIPEVOD-modellen): Fig. 2.2: Syvlagsmodellen Lagnavn Handlingslaget Informationslaget Planlaget Estimeringslaget Vilkårslaget Opgavelaget Domænelaget Aktiviteter Styring Opfølgning, status Planlægning, tjekpunkter Bestemmelse af omfang Risikoanalyse, interessentanalyse Kravspecifikation Foranalyse 36 2 PROCESSERNE

9 Hovedformålet med styringsaktiviteterne er at blive i stand til at foretage den egentlige styring (øverst i modellen) når det viser sig nødvendigt. Altså at ændre på prioritering, bemanding, planer osv. Det kan vi kalde handlingslaget. Her finder vi også aktiviteter som kontraktstyring, underleverandørstyring, kvalitetsstyring osv. Men for at kunne styre er det nødvendigt at have noget information at styre ud fra. Det får vi via det næste lag, informationslaget, som f.eks. forsyner os med rapporter indeholdende grafiske oversigter, tabeller og nøgletal for projektets status. Heraf kan vi f.eks. læse at en bestemt aktivitet er ved at blive forsinket i forhold til planen, og at en anden aktivitet der netop skal til at starte, godt kan vente uden derfor at forsinke projektet. Dette sætter os i stand til at træffe beslutningen ( foretage styringen ) om at ombemande således at hende der netop skulle til at starte på den ikke-kritiske aktivitet, i stedet hjælper med til at afslutte den kritiske. Men denne beslutning er vi kun i stand til at træffe fordi vi har vores rapporter, planer osv. For at vi kan frembringe informationerne i rapporterne, må vi tidligere have lavet en planlægning. Planerne er nemlig forudsætningen for at vi kan udtale os om hvorvidt en aktivitet er forsinket eller ej. Uden en plan ville vi ikke vide hvad aktiviteten var forsinket i forhold til. Bemærk i øvrigt at planerne næsten altid ændres undervejs fordi målet ofte flytter sig. Og en forudsætning for denne planlægning er nogle gode og realistiske estimater. Planerne bliver nemlig kun så realistiske som de estimater de baserer sig på. Estimeringen indgår ofte som en integreret del af planlægningen. En forudsætning for realistiske estimater og planer er kendskab til det vi skal lave samt de vilkår vi skal arbejde under. I vilkårslaget laver vi risikoanalyse og interessentanalyse for at få uddybet opgavebeskrivelsen (kravspecifikationen). I opgavelaget finder vi kravspecifikationen som handler om det det hele drejer sig om, genstanden for vores projekt, domænet med dets mennesker og/eller maskiner i den rigtige verden. Grunden til at så mange projekter er blevet forsinkede i tidens løb, er ofte at man har taget for let på ét eller flere af trinene i modellen. Hvis man f.eks. begynder med en utilstrækkelig kravspecifikation, vil dette forplante sig opad således at også tidsestimaterne bliver for små. Og dermed vil planerne ikke afspejle virkeligheden. Så når man styrer efter disse (for korte) planer, vil man selvfølgelig blive forsinket i forhold til dem. Når et projekt er forsinket, er det nemlig altid i forhold til en plan. Så i stedet for at tale om forsinkede projekter, burde man hellere tale om forkerte planer. Derfor er det vigtigt at de hele tiden holdes opdaterede. Ovenstående proces kan gennemføres ad flere gange, som vi skal se i det senere af- 2 PROCESSERNE 37

10 snit om iterative modeller. Den viste proces kan f.eks. benyttes til softwareudviklingsprojekter. Der findes andre projektledelsesprocesser til andre typer af projekter. Mestrer du alle de ovenstående lag, er der en god chance for at du vil undgå nogle af de værste katastrofer. For det er det bedste man kan opnå. Der kan ikke gives nogen kogebogsopskrift på hvordan man får succes hver gang. Men hvis du følger rådene og arbejdsmetoderne i denne bog, vil du aldrig komme helt galt af sted Trekanten Traditionelt taler man om trekanten, bestående af tid, omkostninger og funktionalitet. Ideen er at man ikke kan nøjes med at ændre én af dimensionerne de hænger uløseligt sammen. En klassisk projektledervits siger: Jeg kan lave systemer billigt, hurtigt og med megen funktionalitet. Vælg selv to! Fordi projektlederens opgave bl.a. er at have styr på at den givne funktionalitet leveres til den givne tid med de givne omkostninger, kaldes projektlederen af nogle ligefrem for trekantsbestyrer. Fig. 2.3: Styringstrekanten Bemærk at der med tid menes kalendertid ikke persontid som er en del af omkostningerne. Funktionalitetsdimensionen omfatter også kvaliteten af systemet. Hvis kvaliteten er lige meget, kan vi lave hvad som helst på ingen tid (også kendt som den nulte softwarelov, se [Weinberg97]). Som regel vægtes de tre dimensioner i trekanten forskelligt. I nogle projekter kan det være altafgørende at nå en bestemt deadline, så her er tiden vigtigst. Andre gange er det omkostningerne. Endelig kan funktionaliteten være det helt afgørende. Derud PROCESSERNE

11 over skal man vide hvad det mindst vigtige er her har vi nemlig vores reserve det som vi eventuelt kan fire på. Så hvis tiden f.eks. er vigtigere end funktionaliteten, kan vi udskyde nogle af funktionerne for dermed at blive færdige til tiden. Der kan dog ligge en fare i den mekanistiske betragtning omkring resurseforbrug (omkostninger) som trekanten lægger op til. Hvis man f.eks. bliver presset på tiden, forsøger man måske at vælge the chinese army approach : man sætter mange udviklere på projektet i håb om dermed at gøre det hurtigere. Ud fra en ide om at hvis 2 mand kan grave en grøft på 10 dage, så kan 20 mand grave den på 1 dag. Det holder imidlertid ikke altid for it-projekter, bl.a. på grund af læreprocesserne som vi skal se på i et senere afsnit. Sammenligningen skal snarere være at to kaniner løber ikke dobbelt så hurtigt som én kanin. Eller: hvis 1 kvinde kan føde 1 barn på 9 måneder, hvor mange kvinder skal der så til for at føde 1 barn på 1 måned? Det er en central problemstilling i it-projekter at forholdet mellem trekantens sider (tid, funktionalitet og omkostninger) låses fast på et tidspunkt hvor grundlaget slet ikke er til stede. Adskillige projekter er kommet galt af sted fordi man har lavet en fastpriskontrakt hvor både pris og afleveringsdato lå helt fast, men reelt kendte man ikke funktionaliteten. Det går galt. Hver gang. Vi skal senere vende tilbage til denne problemstilling og se på andre metoder til at løse den. 2.4 Udviklingsprocessen I dette afsnit vil vi se på den proces som gennemgås når man udvikler software. En udviklingsmodel er en beskrivelse af udviklingsprocessens forløb, dvs. Hvem gør hvad hvornår? Vi opererer også med begrebet livscyklusmodeller som er tiden fra produktideen fødes, og til sidste version er faset ud (hvor udviklingsmodellen kun omfatter tiden indtil afleveringen til kunden). En hel livscyklus kan typisk se således ud: Forundersøgelse Udvikling Udrulning Vedligeholdelse Udfasning Der kan indgå mange elementer i en udviklingsmodel. Mest typisk er at modellen beskriver: 2 PROCESSERNE 39

12 PROCES, hvilke aktiviteter gennemføres i hvilken rækkefølge. ROLLER, hvem laver hvad? METODER til f.eks. analyse, krav, design, test. VÆRKTØJER, f.eks. CASE, programmering, test. TEKNISKE AKTIVITETER. KVALITETSSTYRINGSAKTIVITETER, f.eks. hvornår laves test og inspektioner. KONFIGURATIONS-, VERSIONS- og DOKUMENTSTYRING. MELLEMPRODUKTER (eng.: artifacts), hvilke skal laves hvornår, og hvad skal de indeholde. DOKUMENTER (som også er mellemprodukter), herunder specifikationer og planer. Formålet med overhovedet at have en udviklingsmodel er først og fremmest at have en fælles referenceramme for udviklingsprocessen Sådan gør vi her. Det giver dels en billigere uddannelse når der kommer nye projektdeltagere, dels sparer det mange diskussioner i kampens hede. Ikke, at vi skal undertrykke diskussionerne vi tager dem bare på andre tidspunkter end midt under projektet. Og når vi alle sammen i hele virksomheden gør tingene på samme måde, har vi bedre mulighed for procesrelateret erfaringsudveksling. Endelig giver det alt andet lige en lettere planlægning samt en mulighed for at måle på processen og dermed en større sandsynlighed for succes. Overordnet set findes der to typer udviklingsmodeller: fasemodeller og iterative modeller Fasemodeller En klassisk kopifitti om projektfaser lyder: De seks projektfaser: Vild entusiasme Desillusionering Total forvirring Jagt på de skyldige Afstraffelse af de uskyldige Forfremmelse af dem der ikke deltog Mere seriøst inddeler vi i fasemodellerne udviklingen i et antal faser, typisk: Analyse Kravspecifikation 40 2 PROCESSERNE

13 Design Kodning Test Udrulning Disse modeller kaldes ofte for vandfaldsmodeller fordi man falder fra den ene fase til den næste. Dette er dog en sandhed med modifikationer, for de fleste fasemodeller rummer mulighed for tilbageløb. Hvis man således i kodningsfasen opdager et nyt krav, kan man gå tilbage til kravfasen og tage det med. Struktureret ProgramUdvikling (SPU) er et eksempel på en fasemodel (med tilbageløb) se [Biering-Sørensen88]. Alt flyder At udvikle systemer ud fra en specifikation er ligesom at gå på vandet: det hjælper hvis det er frosset! I øvrigt er det som regel en illusion at man kan fastfryse kravene. I de fleste situationer vil der være en person med tilpas mange stjerner (om ikke andet, den administrerende direktør) som kan overrule beslutningen og beordre et nyt krav medtaget og så er vi lige vidt. Ved du i øvrigt hvad ligheden er mellem fastfrosne krav og den afskyelige snemand? Jo, begge er myter, og begge smelter når det bliver tilstrækkeligt varmt. Nogle siger ligefrem at kravspecifikationen er at opfatte som en kontrakt der skal genforhandles dagligt med alle interessenter. Det vender vi tilbage til i det senere afsnit om Kravstyring. Mekanismen har været kendt længe: den græske filosof Heraklit, som levede omkring 500 f.kr., sagde at alt flyder hvormed han mente at intet er uforanderligt, alting ændres hele tiden. Det gælder også systemkrav Iterative modeller De iterative modeller går frem med små skridt. Først udvikler vi en lille bid af systemet. Så leverer vi det til brugerne og ser hvordan det virker. Og så udvider vi det med lidt mere. Derfor kan du også høre ordene inkrementel, gradvis eller trinvis udvikling brugt om iterativ udvikling. Tidligere kaldte man de iterative modeller for RAD (Rapid Application Development). I nogle udviklingsmodeller starter man (som i en vandfaldsmodel) med at gennemanalysere og designe hele systemet hvorefter man udvikler det i mindre bidder. Man kan også starte med at udvikle en lille del af systemet og så lade systemdelen vokse sig gradvis større og større gennem en række iterationer. Det kaldes evolutionær udvikling. Her kan vi opfatte hver iteration som et gennemløb af faserne i en fasemodel: 2 PROCESSERNE 41

14 først finder vi ud af hvad vi skal lave (analyse og krav) så finder vi ud af hvordan vi skal lave det (design) så laver vi det (kodning) og så tester vi det. Denne måde at arbejde på er ikke nogen ny ide. Allerede i 1950 erne udarbejdede den amerikanske kvalitetsekspert Dr. W. Edwards Deming sin såkaldte Deming-cycle: Planlægge-Udføre-Vurdere-Ændre (eng.: PDSA-cycle, Plan-Do-Study-Act. Nogle siger dog Check i stedet for Study : PDCA.). Den illustrerer at man i en stadig vekslen mellem disse fire aktiviteter vedvarende forbedrer sine processer. Den blev i starten en stor succes i japansk kvalitetsledelse hvor begrebet kaizen (løbende forbedringer, alting kan altid gøres lidt bedre) i dag er kendt verden over. Den er grundlaget for mange moderne forbedringsprocesser og altså også for iterative it-udviklingsprocesser. Fig. 2.4: Deming-cyklen De forskellige iterative modeller har hver deres bud på hvordan denne proces foregår. Af fremherskende modeller kan nævnes: Rational Unified Process (RUP), se side 44. Microsoft Solution Framework (MSF), se side 45. extreme Programming (XP), se side 46. Objektorienteret Analyse og Design (OOA&D, også kaldet Aalborgmetoden. Se [Mathiassen01]). Dynamic System Development Model (DSDM, se [Stapleton97]). Structured Systems Analysis and Design Method (SSADM, se [Weaver02]). Scrum (se [Beedle01]) PROCESSERNE

15 Mange virksomheder har i tidens løb udviklet deres egne modeller (eventuelt med afsæt i en af de etablerede). Der er forskellige bud på hvad en iteration omfatter. I nogle iterative modeller fastholder man f.eks. tiden: den næste iteration skal være færdig om (f.eks.) 6 måneder. Med andre ord: vi når det vi når. Og når tiden er gået så er vi færdige. Det kaldes time boxing. Man kan også fastholde omkostningerne (resurserne). Det kaldes money boxing. Og endelig kan man fastholde funktionaliteten (function boxing) i en use case-drevet proces: den næste iteration implementerer disse to use cases. Ofte lader man den første iteration omfatte det helt basale system, dvs. f.eks. platformen, database-serveren, web-serveren osv. Man starter med andre ord med at få hul igennem. I RAD lægger man vægt på at få den første release søsat så hurtigt som muligt (deraf navnet). Derfor var det også i forbindelse med RAD man første gang introducerede begrebet time box. En af grundene til at det som regel forholdsvis hurtigt lykkes at få lavet et brugbart system, er Paretos 80/20-regel som siger at den funktionalitet som af brugerne vil blive brugt i 80% af tiden, laves på 20% af udviklingstiden. De iterative processer virker så godt fordi de har indbygget feedback. Vi får mulighed for at tage højde for det vi lærer undervejs i processen. Med vandfaldsmodellerne skal vi vide det hele på forhånd hvad man meget sjældent gør. Og vi må vente til allersidst med at drage nytte af det vi lærer undervejs. Vi skal senere se på disse læreprocesser og på hvor nyttigt det er at kunne få feedback undervejs. Adrætte metoder Mange udviklingsmodeller indeholder detaljerede retningslinjer for præcis hvilke skridt man skal udføre. Sådanne præskriptive modeller har nærmest karakter af kogebøger. Som modvægt mod disse overvægtige metoder har der i 1990 erne (samtidig med den fedtfrie slankebølge!) været en tendens hen mod modeller med mindre gør-dit-og-gør-dat (f.eks. XP, DSDM og Scrum). De kaldtes tidligere letvægtsmetoder (eng.: lean), men i dag kaldes de adrætte metoder (eng.: agile). Det har givet anledning til det adrætte manifest (se samt [Cockburn01]): Individer og samspil frem for processer og værktøjer. Kørende software frem for fuldstændig dokumentation. Samarbejde med kunden frem for kontraktforhandling. Reaktion på forandring frem for at følge en plan. Det kan ses som en modreaktion mod de meget store og tunge metoder (lidt i stil med 2 PROCESSERNE 43

16 dogmereglerne for filmproduktion: tilbage til rødderne). Ideen er at projektet skal fokusere på de værdiskabende aktiviteter og så i øvrigt være tunet til at kunne reagere hurtigt når tingene ændrer sig Rational Unified Process Rational Unified Process (forkortet RUP ) er en konkretisering af Unified Process (se [Jacobson99]). RUP har opnået stor udbredelse fordi den er både operationel og værktøjsunderstøttet, men andre virksomheder har også lavet deres bud på hvorledes Unified Process kan instantieres. RUP er en use case-drevet, arkitekturcentreret, iterativ udviklingsmodel. Den rummer følgende hovedfaser: BEGYNDELSE (eng.: inception) hvor ideen fødes, de vigtigste use cases beskrives og der laves overordnet arkitektur og plan. UDDYBNING (eng.: elaboration) hvor de fleste use cases beskrives, arkitekturen udarbejdes og resten af projektet estimeres og planlægges. KONSTRUKTION (eng.: construction) hvor implementeringen foregår. OVERGANG (eng.: transition) hvor der laves betatest, rettes fejl, trænes brugere og rulles ud i organisationen. Dette er med andre ord produktmodningsfasen. At modellen er iterativ, betyder at man i de enkelte hovedfaser gennemløber et antal iterationer. Hver iteration består af kravfastlæggelse, analyse, design, kodning og test. De fleste iterationer foregår af gode grunde i konstruktionsfasen. Gennem hele udviklingsforløbet udføres ni aktiviteter (eng.: work flows). Dels seks kerneaktiviteter: FORRETNINGSMODELLERING som sørger for koblingen mellem de forretningsprocesser som it-systemet indgår i, og selve it-systemet. Er det det rigtige vi udvikler? KRAV som beskæftiger sig med en grundig forståelse og beskrivelse af kravene til systemet. Der laves vision, identificeres aktører og beskrives use cases. Hvad skal vi lave? ANALYSE og DESIGN beskæftiger sig med hvordan vi rent faktisk vil implementere systemet. Det er her vi tænker på delsystemer, arkitektur og grænseflader. IMPLEMENTERING hvor vi udvikler koden og tester at enkeltkomponenter virker. TEST hvor vi tester at komponenter og delsystemer virker sammen, at hele systemet virker og at alle krav er implementeret korrekt. UDRULNING hvor vi i en række delleverancer indfører systemet i brugerorganisationen og hjælper brugerne med at tage det i anvendelse PROCESSERNE

17 Dels tre støtteaktiviteter: PROJEKTLEDELSE som handler om faktisk at få gennemført de nævnte aktiviteter på en afbalanceret måde. KONFIGURATIONS- og ÆNDRINGSSTYRING som holder styr på alle de mange krav, mellemprodukter og releases undervejs. UDVIKLINGSMILJØ som sørger for at dels udviklingsprocessen, dels de værktøjer som projektgruppen har behov for, er til stede og tunet til opgaven. Men det er vigtigt at understrege at disse ni aktiviteter forløber gennem hele projektet. Der bliver dog ikke lagt lige meget arbejde i dem i alle faserne. F.eks. lægges der flere kræfter i arbejdsgangen implementering i konstruktionsfasen. Du kan læse mere om RUP i f.eks. [Kruchten00] Microsoft Solution Framework MSF er en ramme for systemudvikling, det er ikke en egentlig metode. Den er udviklet af Microsoft gennem mange år og indeholder essensen af hvad Microsoft mener er best practice. MSF består af en række modeller: PROCESMODELLEN som beskriver hvordan udviklingsprocessen forløber. ROLLEMODELLEN som beskriver de forskellige roller i projektgruppen. Den vender vi tilbage til i det senere afsnit om Organisation (side 164 ). APPLIKATIONSMODELLEN som beskriver applikationens arkitektur. RISIKOMODELLEN som beskriver hvordan projektet skal forholde sig til risici gennem hele forløbet. Procesmodellen beskriver at projektet overordnet inddeles i fire faser: VISIONSFASEN (eng.: Envisioning phase) hvor vi danner overblikket over projektets omgivelser og mål: Hvad går det ud på? Planlægningsfasen (eng.: Planning phase) hvor vi laver kravspecifikation og overordnet projektplan. UDVIKLINGSFASEN (eng.: Developing phase) hvor produktet udvikles og testes. Udviklingen sker iterativt, evt. i parallelle forløb. MODNINGSFASEN (eng.: Stabilizing phase eller Deployment phase) hvor produktet testes i den virkelige verden og gradvist tages i brug. Bemærk at MSF, ligesom RUP, er en hybrid mellem en vandfaldsmodel og en iterativ model. Man har taget det bedste fra begge verdener. 2 PROCESSERNE 45

18 MSF er i øvrigt en del af et endnu større koncept, nemlig ESF, Enterprise Services Framework. Det omfatter: Microsoft Readiness Framework (MRF) som er en foranalyse der skal afdække de forskellige løsningsmuligheder og deres egnethed i relation til de forretningsmæssige mål. Microsoft Solution Framework (MSF). Microsoft Operations Framework (MOF) som omfatter drift og vedligehold. Se i øvrigt mere om MSF på extrem Programmering extrem Programmering (eng.: extreme Programming, XP) er et eksempel på en adræt metode. Her gives en kort oversigt over metoden. Det centrale styringsredskab er de såkaldte user stories som er meget små funktionalitetsbeskrivelser. XP består af 12 selvstændige teknikker som tilsammen udgør XP: PLANLÆGNINGSSPILLET (eng.: The Planning Game). Kunden og projektgruppen fastlægger i fællesskab hvad den næste aflevering skal indeholde. Det er et tæt samspil mellem kundens forretningsmæssige prioritering og udviklernes estimater. SMÅ DELLEVERANCER er nødvendige for hele tiden at have et kørende system. METAFOREN er et billede på systemet som alle kan referere til. Hvad handler systemet om, fortalt på to linjer. Den fælles vision. SIMPELT DESIGN betyder at vi under hele opbygningen holder designet på det simplest mulige. Vi tager altså ikke hensyn til at vi i næste uge skal lave en tilføjelse som kræver et mere kompliceret design. Så laver vi det mere kompliceret til den tid. Men ikke nu. Dette er KISS-reglen: Keep It Small and Simple som vi senere vender tilbage til i andre sammenhænge. TEST FØR KODNING. Hvis test er godt, så må vi teste hele tiden. Og her laver vi så testen før vi laver den kode der skal testes. Testen fejler (fordi koden den skal teste ikke er skrevet endnu), men når vi får skrevet koden, så virker testen. Alle disse tests automatiseres så vi hurtigt kan verificere at hele systemet virker indtil nu. OMBRYDNING (eng.: Refactoring) betyder at vi hele tiden bliver klogere mht. hvordan designet af systemet skal være og så tilpasser vi det løbende. Hvilket vi også er nødt til fordi designet skal holdes på det simplest mulige hele tiden. Vi er altså ikke bange for at lave noget om. Og det behøver vi heller ikke at være for med den automatiske test har vi vished for at det virker, også efter ombrydningen PROCESSERNE

19 PARPROGRAMMERING (eng.: Pair Programming) er nok den mest kendte af XP-teknikkerne. Det betyder helt bogstaveligt at to programmører sidder samtidig ved den samme skærm og hjælpes ad med at kode. Oftest skiftes de til at sidde med tastaturet, og så koder og skriver den ene, mens den anden løbende tjekker at det er korrekt. Hvis review er godt, så lad os reviewe koden hele tiden. FÆLLES EJERSKAB betyder at der ikke findes dine moduler og mine moduler. Det er vores moduler alle sammen, og hvis jeg har brug for at rette et sted i koden, så gør jeg det. Den automatiske test sikrer at der ikke sker ulykker. Egofri programmering er i øvrigt et gammelt begreb som er omtalt allerede i 1971 (se [Weinberg98]). FORTLØBENDE INTEGRATION betyder at vi integrerer hele systemet hele tiden. Så er vi sikre på at det vi har lavet, hele tiden virker. 37-TIMERS UGE. De fleste udviklere elsker denne regel. Baggrunden er den at når udviklere har været kreative en hel arbejdsdag, er de trætte. Og hvis de koder videre, laver de fejl. Det er billigere og bedre bare at lade dem gå hjem og hvile ud til næste dag. KUNDEN TIL STEDE betyder helt bogstaveligt at kunden skal være umiddelbart tilgængelig for udviklerne. Når vi ikke har en egentlig nedskreven detaljeret kravspecifikation, må vi kunne få afklaret alle tvivlsspørgsmål her og nu. KODESTANDARDER er helt nødvendige når vi har fælles ejerskab til koden. Ellers bliver det noget rod. Bemærk at alle disse teknikker skal være i anvendelse før man taler om extrem Programmering. Hvis én eller flere mangler, virker metoden ikke optimalt. I det senere afsnit om Organisation (side 167) ser vi på de roller som findes i extrem Programmering. Du kan i øvrigt læse mere om XP i [Beck00] og [Beck01]. I øvrigt findes der en konkretisering af Unified Process som til forveksling ligner extrem Programmering. Den kaldes dx (læs det på hovedet). Den kan bruges hvis man skal bruge Unified Process, men gerne vil bruge XP Foranalyse Inden der er taget endelig stilling til om projektet overhovedet skal startes, laves sommetider et foranalyseprojekt. Det kaldes også et forprojekt, et feasibility study eller et præjekt. Det svarer lidt til at vi starter med at lave jordbundsanalyser inden vi påbegynder et byggeprojekt. Som resultat udarbejdes en foranalyserapport (en business case) som fastlægger om projektet rent forretningsmæssigt kan bære. Den skal danne beslutningsgrundlag for hvorvidt projektet overhovedet skal sættes i gang. 2 PROCESSERNE 47

20 Rapporten indeholder f.eks.: Formålet med projektet. Hvorfor laver vi egentlig det her? Hvilket problem vil vi løse? Overordnet beskrivelse af hvad det er vi vil lave. Beskrivelse af teknologien (hvis relevant). Risikoanalyse. Beskrivelse af projektets finansiering. Anslået tid og pris. Cost/benefit-analyse, kan det betale sig? Dette dokument kan senere udbygges til at blive projektgrundlaget. En del af arbejdet med foranalysen går ud på at få opbygget en forståelse for den opgave der skal løses. I diskussionen med brugerne om et eventuelt nyt system kan f.eks. anvendes mock-ups, dvs. skærmbilleder på papir. Eller man kan lave egentlige prototyper for at demonstrere og afprøve systemets grænseflader. Men at analysere for længe er også farligt (eng.: analysis paralysis). I en misforstået angst for ikke at gøre det godt og grundigt nok bliver vi ved med at analysere langt efter at vi skulle være gået videre til næste fase. Det gælder både foranalysen og en eventuel senere analysefase. Flere udviklingsmodeller omfatter en foranalyse (f.eks. DSDM og Microsoft Readiness Framework). Du kan læse mere om foranalyse i f.eks. [Bødker00] Kravspecifikationen Inden vi går i gang med selve udviklingen, skal vi have styr på hvad det er vi vil lave. Denne aktivitet kaldes kravspecifikation, og det er en videnskab i sig selv. Da det samtidig er en af de væsentligste forudsætninger for projektets succes, er der al mulig grund til at tage kravspecifikationen alvorligt. Tidligere lavede man næsten altid kravspecifikationen (eng.: SRS, Software Requirement Specification) som en opremsning af produktkrav, dvs. præcise beskrivelser af funktionerne i systemet. I dag har man flere strenge at spille på, og også i forståelsen af kravene til systemet anvender vi en multiperspektivisk tilgang: FORRETNINGSANALYSEN udarbejder en forretningsmodel som giver overblik over domænet og indplacerer it-systemet i den rigtige sammenhæng. DOMÆNEBESKRIVELSEN er en beskrivelse af de kommende brugeres arbejde det arbejde som det nye system skal understøtte. Dette kan også omfatte en arbejdsgangsanalyse PROCESSERNE

21 FUNKTIONELLE KRAV beskriver de enkeltkrav der kan opstilles til systemets funktionalitet. Ofte beskrives disse i form af Use Cases (brugsmønstre). BRUGERGRÆNSEFLADEKRAVENE beskriver kravene til systemet set fra brugerens side. INFORMATIONSMODELLEN giver overblik over hvilke informationer systemet skal holde styr på. YDELSESKRAVENE (eng.: performance) skal også beskrives. Det kan være krav til transaktionsmængder (eng.: throughput), antal samtidige brugere, spidsbelastning (eng.: peak), databasestørrelse osv. SIKKERHEDSKRAVENE beskriver hvilke krav der stilles til datasikkerhed, adgangskontrol, recovery osv. ORDLISTEN indeholder en alfabetisk liste over alle domænets ord, termer og begreber, med tilhørende definition og beskrivelse. Selve arbejdsprocessen med at udarbejde ordlisten vil som regel altid ske i samarbejde med en domæneekspert. Det kan i øvrigt også være en læreproces for domæneeksperten at lave ordlisten. Begreber man har gået og brugt i det daglige, er ikke altid helt så enkle når de skal forklares, formuleres og nedskrives. I erkendelse af at det kan være særdeles vanskeligt at give fastpristilbud på et stort system uden at kende kravene, ses det ofte at udviklingen af selve kravspecifikationen laves som et forprojekt (eventuelt til fast pris). Når kravspecifikationen så foreligger, kan der gives tilbud på udviklingen af det egentlige system. Omvendt skal vi også være klar over at det sjældent er en god ide at forsøge at detailspecificere ned til den mindste detalje. Hvis vi ikke kender området, er det bedre at holde kravene overordnet så vi kan drage fordel af læreprocessen undervejs. Proportionalitetsreglen Ved udarbejdelse af kravspecifikationer gælder proportionalitetsreglen: Små systemer lille kravspecifikationsindsats. Store systemer stor indsats. Proportionalitetsreglen siger generelt at der skal være sammenhæng mellem tingene, og der skal være måde med galskaben. Vi skal hverken skyde gråspurve med kanoner eller skyde elefanter med ærtebøsser. I forbindelse med kravspecifikationen betyder det altså at vi ikke skal køre det helt store apparat i stilling for at lave en lillebitte opgave. Men at det på den anden side er i orden at bruge mange kræfter på at finde ud af hvad systemet går ud på hvis det er meget stort. 2 PROCESSERNE 49

22 Videre studier Du kan læse mere i [Lauesen00] som er en introduktion til området, eller i [Lauesen02] som er den autoritative bog om kravspecifikation. Også [Wiegers99] og [Robertson99] rummer god indsigt i området. Use Case-teknikken er beskrevet i [Schneider98]. [Biering-Sørensen88] rummer også et kapitel om kravspecifikation. Bruger du RUP, kan [Leffingwell99] anbefales. Endelig rummer [IEEE830] et udmærket forslag til en indholdsfortegnelse for kravspecifikationer Valg af udviklingsmodel Et af de klassiske problemer i it-projekter er at man glemmer at være bevidst om sin udviklingsmodel. Man behøver ikke nødvendigvis vælge en af de etablerede (selv om det er det letteste fordi de er så velbeskrevne). Man kan sagtens lave sin egen tilpassede (eng.: tailoring). Bare man har en. Når projektet (eller virksomheden) står over for at skulle vælge en udviklingsmodel, er der flere hensyn at tage: Hvor godt forstår vi (og kunden) anvendelsesområdet? Vil kravene ændre sig undervejs? Hvor godt kender vi udviklingsmiljøet? Hvor godt kender vi den organisation som skal modtage systemet? Hvor meget styr har vi på designet af denne type applikationer? Kræves der fast pris, tid og funktionalitet? Hvor mange personer skal deltage i udviklingen? Er der tale om udvikling til fast pris og tid inden for et velkendt domæne, kan det være mest praktisk med en vandfaldsmodel. Er der derimod tale om ukendt land, vil en iterativ model med indbygget udnyttelse af læreprocesserne være at foretrække. Det kan godt være at det kræver nogen pædagogisk overtalelse af projektsponsoren, men tro mig: det er det værd. Skift af model Det tager ofte lang tid at få en udviklingsmodel ind under huden. Så man skal ikke skifte udviklingsmodel for tit man når simpelthen ikke at lære dens styrker og svagheder tilstrækkeligt godt at kende, og man går glip af læreprocessen med at anvende modellen. Men behersker man flere modeller, og er der tale om et stort system inden for et ukendt område, kan man også vælge en adræt model i starten, for siden at gå over til f.eks. RUP PROCESSERNE

23 Regler eller ej? Når mange mennesker skal arbejde sammen, er et vist mål af regler nødvendigt. Hvis alle blot gør hvad der passer dem, ender det hele i anarki. Vi har behov for nogle færdselsregler som sikrer at vi ikke modarbejder hinanden. Nogle regler er lette at få udviklerne til at forstå og følge. F.eks. at vi skal benytte et fælles versionsstyringsværktøj så vi undgår problemer med at flere udviklere vil rette i de samme filer samtidig, og så vi altid kan genskabe tidligere releases. Andre regler kan det være sværere at håndhæve. F.eks. regler omkring kodestandarder ( Jeg har altid lavet 4 indrykninger efter en if! ). Se også det senere afsnit om Standarder (side 173) i kapitlet om Projektetablering. Jo flere personer der er involveret i projektet, jo større er behovet for fælles regler. 2-4 udviklere kan sagtens koordinere ved at snakke sammen hele tiden. Når vi bliver ret mange flere, går der alt for lang tid med diskussion hvis vi ikke følger de samme retningslinjer. Imidlertid er vi her oppe imod store kræfter. For det første menneskets iboende dovenskab. De fleste vil helst springe over hvor gærdet er lavest (eng.: Path of least resistance). Dette kaldes dovenskabsreglen eller reglen om den mindste modstand. Det ses f.eks. når der trædes stier den direkte vej hen over en græsplæne selv om der er anlagt officielle flisegange. For det andet er vi oppe imod menneskets særdeles kreative evner når det handler om at omgå love og regler. Jeg vil illustrere dette med en berømt fangeflugt: Hvor der er en vilje I 1949 brød fangen Carl August Lorentzen ud fra sin celle i Horsens Statsfængsel. Han havde fjernet bagklædningen i det lille skab i cellen og kunne derved bryde gennem muren til et lille trapperum. Ad den vej tilbragte han nætterne i det meste af et år med at grave en 20 meter lang tunnel ud under fængselsmuren. Den bortgravede jord gemte han på loftet. Efter flugten fandt man i det lille skab i cellen en seddel hvor han havde skrevet de senere så berømte ord: Hvor der er en vilje, er der også en vej! For god ordens skyld: det er ikke Lorentzen der har fundet på dette ordsprog det er ældgammelt og findes i flere kulturer. 2 PROCESSERNE 51

24 Så hvis du tror at du kan styre folk gennem regler som de ikke er enige i, så husk på hvor der er en vilje -syndromet. I den virkelige verden finder den ofte anvendelse omkring omgåelse af skattelovene. I naturen finder den anvendelse når mælkebøtterne bryder frem gennem asfalten (derfor kaldes det også undertiden mælkebøttesyndromet). Og ofte ledsages den af bemærkninger som Så må vi jo finde på noget andet, Det skal de i hvert fald ikke bestemme og lignende. Men bevidstløst regelrytteri er også galt. Det er tilladt at bruge indersiden af hovedet og træffe velovervejede beslutninger også selv om reglerne siger noget andet (eng.: Engage your brain) Softwarehåndbogen Udviklingsmodellen beskrives typisk i en softwarehåndbog (også kaldet en projekthåndbog). Den skal helst være tilgængelig online på virksomhedens intranet. Softwarehåndbøger på papir er for vanskelige at holde opdateret, og så forældes de lynhurtigt. Men selv en nok så god softwarehåndbog er intet værd hvis udviklerne ikke kender dens indhold. Så den skal under alle omstændigheder suppleres med undervisning i dens brug når der kommer nye udviklere. Og de gamle kan formentlig også trænge til at få den frisket op en gang imellem. 2.5 Læreprocesserne Forestil dig at du hver den 1. i måneden bliver bedt om at være projektleder på udviklingen af et givet system. Og det er nøjagtigt det samme system du skal udvikle måned efter måned. Det er naturligvis en tænkt situation, men mit gæt er at du vil blive i stand til at udvikle systemet på stadig kortere tid indtil en vis grænse. Denne grænse kan vi kalde idealtiden, dvs. den tid det tager at udvikle systemet hvis alting bare flasker sig, og hvis vi ved det hele. Tiden som du de første gange bruger ud over idealtiden, kan vi kalde overtiden. Altså den tid du bruger for meget. Lad os kigge på hvad overtiden egentlig bruges til. Den bruges nemlig til en række læreprocesser. Vi skal blive klogere mht. PIP: Produktet, dvs. f.eks. anvendelsesområdet og den konkrete applikations design. Interessenterne, dvs. f.eks. kundens forhold og samarbejdet i projektgruppen. Processen, dvs. f.eks. udviklingsmiljøet PROCESSERNE

25 Produktet Læreprocesserne omkring anvendelsesområdet (domænet) handler om at vi skal tilegne os viden om den verden systemet skal virke indenfor. Er det f.eks. et system til patientadministration, skal vi vide noget om hvordan et hospital fungerer. Er det et system til styring af et kraftværk, skal vi vide noget om hvordan et kraftværk fungerer. Derfor kan det sommetider være en god ide at tilbringe nogle dage i det miljø hvor systemet skal bruges ([Bødker00]). Vi skal opbygge den konkrete applikations design. Vi skal lave en arkitektur som egner sig til denne applikation. Vi skal finde ud af hvilke komponenter systemet skal bestå af. Og hvordan de snakker sammen. Vi skal måske opbygge (eller genbruge) hele application frameworks, dvs. standardarkitekturer for denne type systemer. Interessenterne Projekter er bl.a. kendetegnet ved at det er forskellige personer der deltager fra gang til gang. Kunden er sjældent den samme. Brugerne er forskellige. Og projektgruppen sammensættes ofte på ny hver gang. Derfor skal vi lære os hvordan projektets interessenter denne gang er skruet sammen. Hvilke behov de har. Hvordan de kan takles bedst muligt. Hvordan vi sikrer at så mange af deres interesser som muligt opfyldes. Vel vidende at de kan være modstridende. Processen Læreprocesserne omkring udviklingsmiljøet handler om at vi skal sætte os ind i udviklingsværktøj, compiler, standardkomponenter, biblioteker, udviklingsplatform, konfigurationsstyringsværktøjer osv. Læreprocesser tager tid Det er ofte læreprocesserne som er skyld i at it-udvikling underestimeres. Vi glemmer simpelthen at tage højde for alle de ting som vi ikke ved, og som vi skal sætte os ind i (lære) hen ad vejen. I andre brancher kaldes fænomenet begyndervanskeligheder eller børnesygdomme begreber som dækker over at vi udmærket godt ved at ting kan gå galt når vi starter på noget nyt. Vi snakker om at al begyndelse er svær. I øvrigt siger man lidt i spøg at det først er det tredje system (af samme slags) man udvikler som rammer rigtigt, både hvad angår funktionalitet og resurseforbrug. På det tidspunkt har man nemlig gennemført så mange af læreprocesserne at overtiden og skæverterne er kommet ned på et acceptabelt niveau. Det minder lidt om følgende historie om at tegne en hane: 2 PROCESSERNE 53

Hvad er en referencelinie? Tidsligt fastlagt Veldefineret tilstand af mellemprodukter Mellemprodukter vurderes Sandhedens øjeblik

Hvad er en referencelinie? Tidsligt fastlagt Veldefineret tilstand af mellemprodukter Mellemprodukter vurderes Sandhedens øjeblik Hvad er en referencelinie? Tidsligt fastlagt Veldefineret tilstand af mellemprodukter Mellemprodukter vurderes Sandhedens øjeblik En referencelinie er en koordineret og veldefineret tilstand i et projekt,

Læs mere

Introduktion til projekter

Introduktion til projekter Introduktion til projekter v. 1.0.3 Introduktion I dette materiale ser vi overordnet på, hvad projekter egentlig er, hvordan de er skruet sammen og hvilke begreber, som relaterer sig til projekter. Vi

Læs mere

ARBEJDET MED UDVIKLING AF EN AGIL STANDARDKONTRAKT

ARBEJDET MED UDVIKLING AF EN AGIL STANDARDKONTRAKT Executive summary 1. ARBEJDET MED UDVIKLING AF EN AGIL STANDARDKONTRAKT Regeringen har et mål om, at den offentlige sektor skal være blandt de mest effektive og mindst bureaukratiske i verden, og for at

Læs mere

Rollespil Projektsamarbejde Instruktioner til mødeleder

Rollespil Projektsamarbejde Instruktioner til mødeleder Instruktioner til mødeleder Introduktion Med dette rollespil træner I det lærte i lektionen Hjælp en kollega i konflikt. Der skal medvirke to personer, der skal spille henholdsvis Christian og Bente, hvor

Læs mere

Hassansalem.dk/delpin User: admin Pass: admin BACKEND

Hassansalem.dk/delpin User: admin Pass: admin BACKEND Hassansalem.dk/delpin User: admin Pass: admin BACKEND 1/10 Indledning Dette projekt er den afsluttende del af web udvikling studiet på Erhvervs Lillebælt 1. semester. Projektet er udarbejdet med Del-pin

Læs mere

Proces orientering af IT organisationer (ITIL - implementering)

Proces orientering af IT organisationer (ITIL - implementering) Proces orientering af IT organisationer (ITIL - implementering) Af Lars Zobbe Mortensen Indholdsfortegnelse 1 Indledning... 3 1.1 Hvorfor bedst practice processer (f.eks. ITIL)?... 3 2 Beslutning om forandring...

Læs mere

Eksempler på alternative leveregler

Eksempler på alternative leveregler Eksempler på alternative leveregler 1. Jeg skal være afholdt af alle. NEJ, det kan ikke lade sig gøre! Jeg ville foretrække at det var sådan, men det er ikke realistisk for nogen. Jeg kan jo heller ikke

Læs mere

IT Service Management (ITIL) i en agil verden. Lars Zobbe Mortensen

IT Service Management (ITIL) i en agil verden. Lars Zobbe Mortensen IT Service Management (ITIL) i en agil verden Lars Zobbe Mortensen Om Lars It service management konsulent ITIL ekspert og underviser Projekt leder PRINCE2 agile og underviser Tidligere leder for udviklings

Læs mere

Kvalitetssikring af IT udvikling hos TDC

Kvalitetssikring af IT udvikling hos TDC Kvalitetssikring af IT udvikling hos TDC Kvalitetsrevisor Henning Sams Har være ansat hos TDC siden 1976 og har arbejdet med kvalitet i ca. 10 år, primært som QAér og Proceskonsulent. Underviser bl.a på

Læs mere

Det vigtigste først! Dette er måske den vigtigste bog der nogensinde er skrevet om agile vs. vandfald. Muligvis fordi det vel stadig er den eneste

Det vigtigste først! Dette er måske den vigtigste bog der nogensinde er skrevet om agile vs. vandfald. Muligvis fordi det vel stadig er den eneste WTF? Thomas Schou-Moldt, Miracle A/S (siden 2008) Arkitekt, udvikler, teknisk projektleder, mv. Indtil videre afsonet lidt over 20 år i branchen, ingen udsigt til prøveløsladelse tsm@miracleas.dk, 5374

Læs mere

IT-projektledelse F2006. Opfølgning og kvalitetssikring

IT-projektledelse F2006. Opfølgning og kvalitetssikring IT-projektledelse F2006 Opfølgning og kvalitetssikring Hvorfor planlægge når projekter sjældent følger planen? Hvad er opfølgning? Hvad skal der følges op på? Levels of control checkpoint reports project

Læs mere

7. Referencer til andre værktøjer. 8. Sammenhæng med internationale standarder. 9. Referencer til Projektledelse Teori og praksis. 10.

7. Referencer til andre værktøjer. 8. Sammenhæng med internationale standarder. 9. Referencer til Projektledelse Teori og praksis. 10. Projektlederens værktøj 7. Referencer til andre værktøjer Nr. Navn Sammenhæng med Kritisk sti (CPM) 4.3.3 Tidsplan Udarbejdelse af tidsplan er forudsætningen for at kritisk sti kan findes 4.4.2 Successiv

Læs mere

Lean gammel vin på nye flasker SCKK Excellence om Lean og arbejdsgange

Lean gammel vin på nye flasker SCKK Excellence om Lean og arbejdsgange Lean gammel vin på nye flasker SCKK Excellence om Lean og arbejdsgange 3. april 2006 Jørgen Kjærgaard Lean i historisk perspektiv en del af kvalitetstraditionen med TQM og Excellence 2 Toyota Production

Læs mere

It-håndbogen. Uddrag af artikel trykt i It-håndbogen. Gengivelse af denne artikel eller dele heraf er ikke tilladt ifølge dansk lov om ophavsret.

It-håndbogen. Uddrag af artikel trykt i It-håndbogen. Gengivelse af denne artikel eller dele heraf er ikke tilladt ifølge dansk lov om ophavsret. It-håndbogen Uddrag af artikel trykt i It-håndbogen. Gengivelse af denne artikel eller dele heraf er ikke tilladt ifølge dansk lov om ophavsret. Børsen Ledelseshåndbøger er Danmarks største og stærkeste

Læs mere

LEADING. Hvorfor skal du læse artiklen? Hvis du er klar til at blive udfordret på, hvordan du udvikler talent - så er det følgende din tid værd.

LEADING. Hvorfor skal du læse artiklen? Hvis du er klar til at blive udfordret på, hvordan du udvikler talent - så er det følgende din tid værd. LEADING Hvorfor skal du læse artiklen? Hvis du er klar til at blive udfordret på, hvordan du udvikler talent - så er det følgende din tid værd. HAR DU TALENT FOR AT UDVIKLE TALENT? DU SKAL SE DET, DER

Læs mere

Arbejdsformer i datalogiske forundersøgelser

Arbejdsformer i datalogiske forundersøgelser Arbejdsformer i datalogiske forundersøgelser Keld Bødker, Finn Kensing og Jesper Simonsen, RUC/datalogi Projektet foregår i et samarbejde mellem Danmarks Radio, H:S Informatik, WMdata Consulting A/S og

Læs mere

Procedurer for styring af softwarearkitektur og koordinering af udvikling

Procedurer for styring af softwarearkitektur og koordinering af udvikling LEVERANCE 2.3 Procedurer for styring af softwarearkitektur og koordinering af udvikling Procedurerne vil omfatte: Planlægning af udfasning af gamle versioner af OpenTele Planlægning af modning af kode

Læs mere

Teknologianvendelse. - En overset ledelsesopgave. Af Christine Secher, Villa Venire A/S Marts 2013

Teknologianvendelse. - En overset ledelsesopgave. Af Christine Secher, Villa Venire A/S Marts 2013 Teknologianvendelse - En overset ledelsesopgave Af Christine Secher, Villa Venire A/S Marts 2013 Udviklingen i retning af smarte, selvbetjente it-løsninger accelererer overalt i frontlinien, hvor borgere

Læs mere

IT projekt. sæt et mål og nå det med omtanke!

IT projekt. sæt et mål og nå det med omtanke! IT projekt sæt et mål og nå det med omtanke! Det overordnede FORMÅL med dias-showet er at fortælle hvordan vi gennemfører IT projekter med succes ved hjælp af Microsoft Solutions Framework MSF modeller:

Læs mere

21. søndag efter trinitatis

21. søndag efter trinitatis 21. søndag efter trinitatis Sneum kirke, søndag den 9. november kl.10.15-21.søndag efter trinitatis Gud Fader, Søn og Helligånd, du som er i himlen og på jorden, alle menneskers liv tilhører dig. Tak fordi

Læs mere

EA3 eller EA Cube rammeværktøjet fremstilles visuelt som en 3-dimensionel terning:

EA3 eller EA Cube rammeværktøjet fremstilles visuelt som en 3-dimensionel terning: Introduktion til EA3 Mit navn er Marc de Oliveira. Jeg er systemanalytiker og datalog fra Københavns Universitet og denne artikel hører til min artikelserie, Forsimpling (som også er et podcast), hvor

Læs mere

Projektets karakteristika

Projektets karakteristika Projektets karakteristika Gruppeopgave Projektledelse DTU 1999 Projektets karakteristika Formål At give en karakteristik af projektets stærke og svage sider, som kan lægge til grund for den senere mere

Læs mere

At give og modtage konstruktiv feedback

At give og modtage konstruktiv feedback At give og modtage konstruktiv feedback 07.05.06 Hvor svært kan det være? Ret svært åbenbart. Det lyder nemt, men en sikker topscorer i arbejdsklimaundersøgelser er en udbredt oplevelse af, at man ikke

Læs mere

Strategisk projektejerskab

Strategisk projektejerskab Strategisk projektejerskab Spørgsmål til diskussion Hvordan ved jeg som projektejer, at vi chefer har et fælles mandat om projektets resultat? Hvad kan vi som chefer konkret efterspørge, for at styrke

Læs mere

10 gode råd. Vælg den rette model. af konsulent Morten Korsaa, DELTA

10 gode råd. Vælg den rette model. af konsulent Morten Korsaa, DELTA 10 gode råd af konsulent Morten Korsaa, DELTA Vælg den rette model SKI rammekontrakten giver mulighed for at bruge to udviklingsmodeller den klassiske og den nye. Dit valg er afgørende for succes. Den

Læs mere

Sådan bliver du en god "ekstramor" "Sig fra" lyder et af ekspertens råd til, hvordan du nagiverer i din sammenbragte familie.

Sådan bliver du en god ekstramor Sig fra lyder et af ekspertens råd til, hvordan du nagiverer i din sammenbragte familie. Sådan bliver du en god "ekstramor" "Sig fra" lyder et af ekspertens råd til, hvordan du nagiverer i din sammenbragte familie. Af: Janne Førgaard, I lære som ekstramor At leve i en sammenbragt familie er

Læs mere

sådan kører vi processen

sådan kører vi processen VERTICA sådan kører vi processen Når du som ny kunde skal have udviklet en ny e-handelsløsning eller app til din virksomhed, kan det være svært at overskue den proces, der følger. Hos Vertica har vi været

Læs mere

Søren Lauesen IT-Universitetet i København

Søren Lauesen IT-Universitetet i København Hvorfor elektronisk tinglysning startede som en katastrofe Hvordan kunne det være undgået? Hvorfor deres sagsbehandlingssystem blev lukket Søren Lauesen IT-University of Copenhagen E-mail: slauesen@itu.dk

Læs mere

Syv veje til kærligheden

Syv veje til kærligheden Syv veje til kærligheden Pouline Middleton 1. udgave, 1. oplag 2014 Fiction Works Aps Omslagsfoto: Fotograf Steen Larsen ISBN 9788799662999 Alle rettigheder forbeholdes. Enhver form for kommerciel gengivelse

Læs mere

Socialisering. - Hvordan og hvorfor det er så vigtigt. Hunden har et medført socialt behov. Racens betydning for socialisering.

Socialisering. - Hvordan og hvorfor det er så vigtigt. Hunden har et medført socialt behov. Racens betydning for socialisering. Socialisering - Hvordan og hvorfor det er så vigtigt Skrevet af Eksamineret Hundeadfærdsinstruktør & -specialist Ane Weinkouff WEINKOUFF HUNDEADFÆRDSCENTER Hunden har et medført socialt behov Socialisering

Læs mere

FORANDRING FORANDRINGER FOREKOMMER ALLE STEDER TÆLL3R OGSÅ! Leder/arbejdsgiver

FORANDRING FORANDRINGER FOREKOMMER ALLE STEDER TÆLL3R OGSÅ! Leder/arbejdsgiver Om psykisk arbejdsmiljø i detailhandlen Læs mere på www.detdumærker.dk TÆLL3R OGSÅ! Leder/arbejdsgiver FORANDRING FORANDRINGER FOREKOMMER ALLE STEDER Helle og Trine er til personalemøde, hvor deres chef

Læs mere

Iterativ og Agil udvikling

Iterativ og Agil udvikling Iterativ og Agil udvikling 1 2 Udfordringer i hverdagen En liste over de udfordringer man står overfor ved implementering af iterativ og agil udvikling. 3 Udfordringer med Iterationer 4 Iterationer, I

Læs mere

Uge 5.3: (Search,) Select & implement and development methods

Uge 5.3: (Search,) Select & implement and development methods Innovationsprocesser Uge 5.3: (Search,) Select & implement and development methods A A R H U S U N I V E R S I T E T Department of Computer Science 1 Innovation & ICT development *** Innovation *** * ***

Læs mere

Lean Construction-DK s. Guide til bedre planlægning med Last Planner System

Lean Construction-DK s. Guide til bedre planlægning med Last Planner System Lean Construction-DK s Guide til bedre planlægning med Last Planner System Introduktion Last Planner System er et værktøj i Lean Construction udviklet specielt til byggeriet og med hensyn til byggeriets

Læs mere

Et bud på regulatorisk strategi og niveau(er) for nye MedTech virksomheder

Et bud på regulatorisk strategi og niveau(er) for nye MedTech virksomheder Presentation title 1 Et bud på regulatorisk strategi og niveau(er) for nye MedTech virksomheder Peter Bøge Senior Controls manager, Novo Nordisk; Formand for Medicoindustriens ekspertgruppe for Safety

Læs mere

Forandringer i et menneskes liv sker igennem dets relation til andre mennesker. Derfor er det fornuftigt - eller måske bare naturligt - at drage de

Forandringer i et menneskes liv sker igennem dets relation til andre mennesker. Derfor er det fornuftigt - eller måske bare naturligt - at drage de Frirum for forældre Hvis man rykker i den ene side af en uro, kommer hele uroen i ubalance. Sådan er det også i en familie, når familiens unge får problemer med rusmidler. Skal balancen genoprettes, giver

Læs mere

Accelerace og Green Tech Center kommer nu med et unikt tilbud om udvikling af din virksomhed Green Scale Up

Accelerace og Green Tech Center kommer nu med et unikt tilbud om udvikling af din virksomhed Green Scale Up Accelerace og Green Tech Center kommer nu med et unikt tilbud om udvikling af din virksomhed Green Scale Up Accelerace har gennem de seneste 7 år arbejdet tæt sammen med mere end 250 af de mest lovende

Læs mere

Tirsdag: PROJEKTLEDELSE OG -ARBEJDE

Tirsdag: PROJEKTLEDELSE OG -ARBEJDE Tirsdag: PROJEKTLEDELSE OG -ARBEJDE Hvad Er det en god har idé? vi lært? (CBA/BC) Hvad har vi lavet? (projektevaluering) Hvornår har vi et projekt? (projektgeografi) Hvad skal vi levere? (produktmål) Interessentanalyse

Læs mere

UC Effektiviseringsprogrammet. Projektgrundlag. Business Intelligence. version 1.2

UC Effektiviseringsprogrammet. Projektgrundlag. Business Intelligence. version 1.2 UC Effektiviseringsprogrammet Projektgrundlag Business Intelligence version 1.2 9. september 2014 1 Stamdata Stamdata Projektnavn (forventet): Projektejer: Projekttype: Business Intelligence It-chef Hans-Henrik

Læs mere

Sådan får du anvendt dit kursus i praksis. - Guide til at maksimere dit udbytte så du får størst værdi ud af dit kursus

Sådan får du anvendt dit kursus i praksis. - Guide til at maksimere dit udbytte så du får størst værdi ud af dit kursus Sådan får du anvendt dit kursus i praksis - Guide til at maksimere dit udbytte så du får størst værdi ud af dit kursus Introduktion Ifølge Robert Brinkerhoffs, studier om effekten af læring på kurser,

Læs mere

Hensigten har været at træne de studerende i at dele dokumenter hvor der er mulighed for inkorporering af alle former for multimodale tekster.

Hensigten har været at træne de studerende i at dele dokumenter hvor der er mulighed for inkorporering af alle former for multimodale tekster. Projekt edidaktik Forsøg med multimodal tekstproduktion På Viden Djurs er der I to klasser blevet gennemført et forsøg med anvendelse af Microsoft Office 365. Hensigten har været at træne de studerende

Læs mere

PRODUKTIONSSTYRING OG -PLANLÆGNING

PRODUKTIONSSTYRING OG -PLANLÆGNING PRODUKTIONSSTYRING OG -PLANLÆGNING Introduktion Er det egentlig præcist at tale om produktion når temaet er spiludvikling? For produktion dufter jo af faste procedurer, kendte milepæle, og definerede krav

Læs mere

ETC sæt strøm til projektstyringen

ETC sæt strøm til projektstyringen ETC sæt strøm til projektstyringen Sådan får du succes med projektestimering Få styr på projekter og deadlines Denne publikation indeholder en gennemgang af den nye ETC-funktion i TimeLog Project. Med

Læs mere

Fadervor. Abba. Bruger du Fadervor? Beder du Fadervor? Hvornår? Hvor ofte? Hvorfor?

Fadervor. Abba. Bruger du Fadervor? Beder du Fadervor? Hvornår? Hvor ofte? Hvorfor? Fadervor Trosbekendelsen beskriver, hvordan Gud kommer til os. Man kan sige, at bøn handler om det modsatte: Vi kommer til Gud. (Selvom Gud faktisk også kommer til os, når vi beder!) Da Jesu disciple spørger

Læs mere

Introduktion. Jan Brown Maj, 2010

Introduktion. Jan Brown Maj, 2010 Jan Brown Maj, 2010 Introduktion OIOXML har eksisteret som det centrale datastandardiseringsparadigme siden 2002. Til OIOXML-konceptet er der et regelsæt betegnet OIO Navngivnings- og Deignregler (NDR),

Læs mere

Projektarbejde med scrum- metoden

Projektarbejde med scrum- metoden Projektarbejde med scrum- metoden Indhold Indhold... 1 1 Indledning... 2 2 Roller og terminologi i scrum... 3 Opgavestilleren... 3 Scrum Masteren... 3 Projektgruppen... 3 Sprint... 3 3 Møder... 3 Planlægningsmødet...

Læs mere

Mangelfuldt dokumenterede it-systemer. Hvordan løses udfordringen?

Mangelfuldt dokumenterede it-systemer. Hvordan løses udfordringen? Mangelfuldt dokumenterede it-systemer Hvordan løses udfordringen? Indholdsfortegnelse 1. Resume... 3 2. Introduktion... 3 3. Fordelene ved at løse udfordringen... 3 4. Løsningen... 4 4.1 Hvordan?... 4

Læs mere

Informationsforvaltning i det offentlige

Informationsforvaltning i det offentlige Informationsforvaltning i det offentlige 1 Baggrund Den omfattende digitalisering af den offentlige sektor i Danmark er årsag til, at det offentlige i dag skal håndtere større og større mængder digital

Læs mere

Vi vil meget gerne arbejde med gevinstrealisering, men der er så mange udfordringer og modstand. Survey om Business Case og Gevinstrealisering

Vi vil meget gerne arbejde med gevinstrealisering, men der er så mange udfordringer og modstand. Survey om Business Case og Gevinstrealisering Vi vil meget gerne arbejde med gevinstrealisering, men der er så mange udfordringer og modstand Survey om Business Case og Gevinstrealisering Mads Lomholt Reference Peak 2013 Brug af undersøgelsen er tilladt

Læs mere

Afstande, skæringer og vinkler i rummet

Afstande, skæringer og vinkler i rummet Afstande, skæringer og vinkler i rummet Frank Villa 2. maj 202 c 2008-20. Dette dokument må kun anvendes til undervisning i klasser som abonnerer på MatBog.dk. Se yderligere betingelser for brug her. Indhold

Læs mere

2. Metode. 2.1 Interessentanalyse Interessenterne i projektet er vist i nedenstående figur: Aftalekalenderprojektet. Indledning

2. Metode. 2.1 Interessentanalyse Interessenterne i projektet er vist i nedenstående figur: Aftalekalenderprojektet. Indledning 2. Metode Indledning Projektet er udført med flg. faser: Foranalyse (uden iterationer) Analyse (udarbejdelse af kravspecifikation afsnit 9.1, herunder use case beskrivelser afsnit 9.2) Design af skærmbilleder

Læs mere

Bilag 16. Den Iterative Model. Til Kontrakt. Den Nationale Henvisningsformidling

Bilag 16. Den Iterative Model. Til Kontrakt. Den Nationale Henvisningsformidling Bilag 16 Den terative Model Til Kontrakt OM Den Nationale Henvisningsformidling Bilag 16 Den terative Model Side 1/9 NSTRUKTON TL TLBUDSGVER: Teksten i dette afsnit er ikke en del af Kontrakten og vil

Læs mere

Afstande, skæringer og vinkler i rummet

Afstande, skæringer og vinkler i rummet Afstande, skæringer og vinkler i rummet Frank Nasser 9. april 20 c 2008-20. Dette dokument må kun anvendes til undervisning i klasser som abonnerer på MatBog.dk. Se yderligere betingelser for brug her.

Læs mere

Projektplan for DIKU studenterprojekter

Projektplan for DIKU studenterprojekter Projektplan for DIKU studenterprojekter Forfatter: Anders Johansen, Softwareudvikler, Det Kongelige Bibliotek 29. januar, 2007 Projektplan version 1.0 Det Kongelige Bibliotek Postboks 2149, DK-1016 København

Læs mere

Sta Stem! ga! - hvordan far vi et bedre la eringmiljo? O M

Sta Stem! ga! - hvordan far vi et bedre la eringmiljo? O M o Sta Stem! ga! o - hvordan far vi et bedre la eringmiljo? / o T D A O M K E R I Indhold En bevægelsesøvelse hvor eleverne får mulighed for aktivt og på gulvet at udtrykke holdninger, fremsætte forslag

Læs mere

Scope Management ITU 11-09-2013 @janhmadsen #ituscpmgt

Scope Management ITU 11-09-2013 @janhmadsen #ituscpmgt Scope Management ITU 11-09-2013 @janhmadsen Dagsorden Oplægsholder Projektstyring Scope Management i en fælles kontekst Definitioner Scope Management - styring af omfang ved projektets start under projektets

Læs mere

Løsning af simple Ligninger

Løsning af simple Ligninger Løsning af simple Ligninger Frank Nasser 19. april 2011 c 2008-2011. Dette dokument må kun anvendes til undervisning i klasser som abonnerer på MatBog.dk. Se yderligere betingelser for brug her. Bemærk:

Læs mere

Objektorienterede metoder

Objektorienterede metoder Objektorienterede metoder Gang 12. Kvalitet i større systemer Evt.: Ekstremprogrammering (XP) Dette materiale er under Åben Dokumentlicens, se http://www.sslug.dk/linuxbog/licens.html projektopgaven i

Læs mere

Kaninhop for begyndere trin 1 10 Læs mere på www.fionas.dk

Kaninhop for begyndere trin 1 10 Læs mere på www.fionas.dk Side 1 Trin 1. Seletræning. Kaninen er minimum 10 uger gammel og du har brugt masser af tid på at oprette et tillidsforhold til den. Den er tryg ved at du tager den ud af buret så nu er tiden kommet hvor

Læs mere

IT-Universitetet, Projekt- og Programledelse November 2013 AGIL PROGRAMLEDELSE 13-11-2013 1

IT-Universitetet, Projekt- og Programledelse November 2013 AGIL PROGRAMLEDELSE 13-11-2013 1 IT-Universitetet, Projekt- og Programledelse November 2013 AGIL PROGRAMLEDELSE 1 AGENDA Hvem snakker? De betydende faktorer Agil forretningsudvikling D60 leverancemodel - Bedrock Opsamling og? 2 Hvem snakker?

Læs mere

System Arkitekt Practitioner

System Arkitekt Practitioner System Arkitekt Practitioner Kompetencebeskrivelsee DISAC Danish IT Society s Architectural Certification DANSK IT 2012 1 IT arkitekt Practitioner System Arkitekt Denne certificering repræsenterer det

Læs mere

Angle-flying Sikkerhedskrav?! Hvad er flyveretningen? Hvor kraftig og hvad retning er vindene på jorden og i højden?

Angle-flying Sikkerhedskrav?! Hvad er flyveretningen? Hvor kraftig og hvad retning er vindene på jorden og i højden? Angle-flying Som i så mange andre lande er tracking eller angle-flying blevet rigtig populært, og det forstår man godt. For mange mennesker er det at eksperimentere med ens vinkel, hastighed og kropsposition

Læs mere

Selvevaluering 2016: Den pædagogiske strategi

Selvevaluering 2016: Den pædagogiske strategi Selvevaluering 2016: Den pædagogiske strategi Indhold Indledning... 2 Skolens pædagogiske strategi... 3 Første del af selvevalueringen... 4 Kendskab til den pædagogiske strategi... 4 Sammenhæng mellem

Læs mere

LEVERANCE 1.3. Model for kvalitetssikring

LEVERANCE 1.3. Model for kvalitetssikring LEVERANCE 1.3 Model for kvalitetssikring Udarbejdelse af kvalitetssikringsmodel, krav til open source kode og dokumentation og godkendelsesprocedurer m.v. Samt fokus på understøttelse af CE-mærkning. 1

Læs mere

Tjeklisten for bedre indtjening

Tjeklisten for bedre indtjening Tak fordi du har downloadet Den ultimative tjekliste for bedre indtjening. Manglende indtjening hænger ofte sammen med, at der er ting i dit workflow, du kan forbedre. En tjekliste er uvurderlig, for den

Læs mere

Idekatalog. Så vidt jeg husker fremgik det ret tydeligt hvad der skulle være i ansøgningen. Der var bare virkelig mange informationer der skulle med.

Idekatalog. Så vidt jeg husker fremgik det ret tydeligt hvad der skulle være i ansøgningen. Der var bare virkelig mange informationer der skulle med. Ansøgning Yderligere bemærkninger til ansøgningen Det var fedt at rammerne var så åbne, som jeg så det var der kun to krav til projektet: Det skulle være open source og det skulle have det offentliges

Læs mere

Model i fire trin Overordnet kan arbejdspladsen arbejde med en model i fire trin, som er afbilledet herunder.

Model i fire trin Overordnet kan arbejdspladsen arbejde med en model i fire trin, som er afbilledet herunder. PROCESVÆRKTØJ Hvordan kan arbejdspladsen arbejde med at lave retningslinjer? - Forslag til et forløb i fire trin Retningslinjer giver ikke i sig selv bedre forflytninger. Men de rummer fælles aftaler som

Læs mere

IT og økonomi. Organisering af IT. Strategi og planlægning. Systemudvikling 3 Systemudvikling og systemanskaffelse. Hovedopgaver

IT og økonomi. Organisering af IT. Strategi og planlægning. Systemudvikling 3 Systemudvikling og systemanskaffelse. Hovedopgaver IT og økonomi Systemudvikling 3 Systemudvikling og systemanskaffelse Organisering af IT Hovedopgaver Strategi og planlægning Udvikling og anskaffelse Drift Brugersupport Strategi og planlægning Topledelsen

Læs mere

Opkvalificering i et samarbejde den usikre sikkerhed TUP 11, en sikker kommunikation!

Opkvalificering i et samarbejde den usikre sikkerhed TUP 11, en sikker kommunikation! Opkvalificering i et samarbejde den usikre sikkerhed TUP 11, en sikker kommunikation! Simon Schulin, 2013, Adjunkt, Udvikling og Forskning ved Videncenter for Ledelse og Organisationsudvikling Forandring

Læs mere

Sådan oversætter du centrale budskaber

Sådan oversætter du centrale budskaber Sådan oversætter du centrale budskaber Dette er et værktøj for dig, som Vil blive bedre til at kommunikere overordnede budskaber til dine medarbejdere, så de giver mening for dem Har brug for en simpel

Læs mere

INDHOLDSFORTEGNELSE. Skriv selv: 1. Mit liv med alkohol... 238 2. Dagbog om at lære at drikke med måde... 241

INDHOLDSFORTEGNELSE. Skriv selv: 1. Mit liv med alkohol... 238 2. Dagbog om at lære at drikke med måde... 241 INDHOLDSFORTEGNELSE 1. Indledning............................................ 6 2. Læsevejledning......................................... 14 3. Min egen historie.......................................

Læs mere

Best Practice for it og automationsprojekter Huskeliste med råd og erfaringer

Best Practice for it og automationsprojekter Huskeliste med råd og erfaringer Best Practice for it og automationsprojekter Huskeliste med råd og erfaringer Allan P. Kjær, Ph.D. (E), senior specialist IT og automation, COWI A/S Der er mange måder at planlægge og gennemføre et industrielt

Læs mere

GLOBETEAM. SOA Seminar 19.06.2007

GLOBETEAM. SOA Seminar 19.06.2007 SOA Seminar 19.06.2007 Agenda Kl. 08.30 09.00 Registrering og morgenmad Kl. 09.00 09.15 Velkomst Kl. 09.15 09.30 Indledning Kl. 09.30 10.30 Hvad er SOA og hvad er Enterprise Arkitektur? Kl. 10.30 10.45

Læs mere

Håndbog til projektledelse

Håndbog til projektledelse Mere info kontakt Julie Kirstine Olsen Udviklingskonsulent juols@ikast-brande.dk Tlf.: 9960 4153 Mads Ballegaard Konsulent mabal@ikast-brande.dk Tlf.: 9960 4021 Produceret af Håndbog til projektledelse

Læs mere

Spil Rapport. Spil lavet i GameMaker. Kevin, Mads og Thor 03-02-2011

Spil Rapport. Spil lavet i GameMaker. Kevin, Mads og Thor 03-02-2011 Spil Rapport Spil lavet i GameMaker Kevin, Mads og Thor 03-02-2011 Indholdsfortegnelse Indledning... 2 HCI... 2 Planlægning / Elementær systemudvikling... 2 Kravspecifikationer... 4 Spil beskrivelse...

Læs mere

Omfang af beføjelser til at træffe beslutninger (for eksempel anbefaling eller implementering)

Omfang af beføjelser til at træffe beslutninger (for eksempel anbefaling eller implementering) Skema til brug ved oprettelse af et team Formålet med teamet Forventede aktiviteter Tilsigtede resultater Tilgængelige ressourcer Begrænsninger Nødvendige færdigheder og kvaliteter Forventede teammedlemmer

Læs mere

1 Stress af! - Få energien tilbage Malte Lange, Mind-Set.dk. Alle rettigheder forbeholdes

1 Stress af! - Få energien tilbage Malte Lange, Mind-Set.dk. Alle rettigheder forbeholdes 1 Stress af! - Få energien tilbage Dette er en light version Indholdet og indholdsfortegnelsen er STÆRKT begrænset Køb den fulde version her: http://stress.mind-set.dk 2 Stress af! - Få energien tilbage

Læs mere

Agile holdninger, ved Jesper Nielsen

Agile holdninger, ved Jesper Nielsen Agile holdninger, ved Jesper Nielsen AAU april 2007 Historien om Henrik der gik til styregruppemøder Færdig med fase 1, brugt for mange timer. Grundig omkring X Færdig med fase 2, også brugt for mange

Læs mere

Guide til succes med målinger i kommuner

Guide til succes med målinger i kommuner Guide til succes med målinger i kommuner Af Kresten Bjerg, kommunikationsrådgiver, Bjerg K Kommunikation måles af forskellige grunde. Derfor skal kommunikation også måles på forskellige måder. Dit første

Læs mere

Ud af krisen. Software på tværs, 15. juni 2009

Ud af krisen. Software på tværs, 15. juni 2009 Ud af krisen Software på tværs, 15. juni 2009 Om Ative Agile udvikling og rådgivning Klassisk udviklingsmodel Krav Design Ændrer sig Implementering Tager for lang tid Springes over Mareridt Test Deployment

Læs mere

BILAG 1: Interview med den centrale studievejledning på RUC

BILAG 1: Interview med den centrale studievejledning på RUC BILAG 1: Interview med den centrale studievejledning på RUC 27.04.2015 Interviewer 1 (I1) Interviewer 2 (I2) Respondent (R) I1: Ja, vi vil jo lave en app, som skal vejlede den studerende igennem sit studieforløb.

Læs mere

UNDERVISNING I PROBLEMLØSNING

UNDERVISNING I PROBLEMLØSNING UNDERVISNING I PROBLEMLØSNING Fra Pernille Pinds hjemmeside: www.pindogbjerre.dk Kapitel 1 af min bog "Gode grublere og sikre strategier" Bogen kan købes i min online-butik, i boghandlere og kan lånes

Læs mere

Vejledning - Udarbejdelse af gevinstdiagram

Vejledning - Udarbejdelse af gevinstdiagram Vejledning - Udarbejdelse af gevinstdiagram Maj 2015 INDHOLD 1. INDLEDNING... 1 1.1 FORMÅL... 1 1.2 VEJLEDNINGENS SAMMENHÆNG MED DEN FÆLLESSTATSLIGE IT-PROJEKTMODEL... 1 1.3 GEVINSTDIAGRAMMET... 2 1.4

Læs mere

BILAG TIL STANDARDVILKÅR OG BETINGELSER

BILAG TIL STANDARDVILKÅR OG BETINGELSER BILAG TIL STANDARDVILKÅR OG BETINGELSER FOR DIGITALE PROJEKTER - en del af Leveringsaftalen for digitale projekter INDHOLDSFORTEGNELSE Bilag 1: Prismodeller... 2 Indledende... 2 1. Fast pris, fast leverance

Læs mere

Straffekast. Jerôme Baltzersen jerome@falconbasket.dk. Indledning. Det tekniske aspekt. Hvordan bliver jeg en god (bedre) straffekastskytte?

Straffekast. Jerôme Baltzersen jerome@falconbasket.dk. Indledning. Det tekniske aspekt. Hvordan bliver jeg en god (bedre) straffekastskytte? Hvordan bliver jeg en god (bedre) straffekastskytte? jerome@falconbasket.dk 6. november 2006 Version 1.03 Indledning I løbet af den tid jeg har været træner, er det blevet klart, at utrolig mange ungdomsspillere

Læs mere

Værktøj 2 - Milepælsplan

Værktøj 2 - Milepælsplan Værktøj 2 - Milepælsplan Formål Ved at udarbejde en milepælsplan for projektet deles projektet op i mindre og mere håndterbare bidder. Formålet er bl.a. at sikre, at de leverancer og delleverancer, som

Læs mere

Backcasting for Dummies

Backcasting for Dummies JOHN BERN & CO. Backcasting for Dummies Alle mennesker kan have glæde af tankerne bag fremtidsviften og troen på, at man kan skabe sin egen fremtid. Men mange har ikke tålmodighed eller evner til at sætte

Læs mere

(Bilaget ligger på i pdfformat og word-format.)

(Bilaget ligger på  i pdfformat og word-format.) BILAG 7 DEN AGILE METODE OG SAMARBEJDSORGANISATION (Bilaget ligger på http://silkeborgkommune.dk/erhverv/udbud/varer-og-tjenesteydelser i pdfformat og word-format.) Skemaer udfyldes af Tilbudsgiver. Besvarelsen

Læs mere

Avisforside. Vi har skrevet en avis om studier ved Aarhus Universitet

Avisforside. Vi har skrevet en avis om studier ved Aarhus Universitet Avisforside Vi har skrevet en avis om studier ved Aarhus Universitet Vi vil meget gerne høre dine umiddelbare tanker om forsiden til avisen. Hvad forventer du dig af indholdet og giver den dig lyst til

Læs mere

Tietgenskolen - Nørrehus. Data warehouse. Database for udviklere. Thor Harloff Lynggaard DM08125

Tietgenskolen - Nørrehus. Data warehouse. Database for udviklere. Thor Harloff Lynggaard DM08125 Tietgenskolen - Nørrehus Data warehouse Database for udviklere Thor Harloff Lynggaard DM08125 Juni 2010 Indhold Beskrivelse... 3 Data warehouse... 3 Generelt... 3 Sammenligning... 3 Gode sider ved DW...

Læs mere

Med sjælen som coach. vejen til dit drømmeliv

Med sjælen som coach. vejen til dit drømmeliv Susan Nielsen Med sjælen som coach vejen til dit drømmeliv Tænker du nogle gange: Der må være noget mere? Længes du indimellem efter noget større? Prøver du at fastholde de glimt af jubel og lykke, som

Læs mere

SYNOPSIS 1. SEMESTER 2013 E-CONCEPT DEVELOPMENT

SYNOPSIS 1. SEMESTER 2013 E-CONCEPT DEVELOPMENT SYNOPSIS E-CONCEPT DEVELOPMENT INDHOLD 1. JONAS KROGSLUND HVEM ER JEG?... Side 3 2. PRÆSENTATION & MOTIVATION... Side 3 3. FAGLIGE UDFORDRINGER & PROBLEMER... Side 4 3.1 SCRUM...... Side 4 3.2 KRAVSPECOFIKATION...

Læs mere

Arbejde med Regioner Lister, Playlists, og Cutlists i Sound Forge Pro

Arbejde med Regioner Lister, Playlists, og Cutlists i Sound Forge Pro Arbejde med Regioner Lister, Playlists, og Cutlists i Sound Forge Pro Gary Rebholz Du har sikkert allerede ved, at Sound Forge Pro software kan bruges til en imponerende række af audio opgaver. Alt fra

Læs mere

TALENT BESKRIVELSER SÆT DIT TALENT I SPIL V. IRIS ENGELUND SÆT DIT TALENT I SPIL SÅ FALDER BRIKKERNE NEMMERE PÅ PLADS IRIS ENGELUND

TALENT BESKRIVELSER SÆT DIT TALENT I SPIL V. IRIS ENGELUND SÆT DIT TALENT I SPIL SÅ FALDER BRIKKERNE NEMMERE PÅ PLADS IRIS ENGELUND TALENT BESKRIVELSER SÆT DIT TALENT I SPIL V. IRIS ENGELUND T A L E N T B E S K R I V E L S E HVORDAN OPFØRER TALENTET SIG? 1. Strategisk Du har strategisk overblik, kan forudse forhindringer og finder

Læs mere

Jeg ved det ikke. Hvordan kan vi forstå, hvad det kan handle om, og hvad kan vi så tilbyde?

Jeg ved det ikke. Hvordan kan vi forstå, hvad det kan handle om, og hvad kan vi så tilbyde? Jeg ved det ikke Hvordan kan vi forstå, hvad det kan handle om, og hvad kan vi så tilbyde? Spørg barnet De bedste kurser, vi kan gå på, er hos dem, vi arbejder med Børn er typisk objekter, der bliver studeret

Læs mere

Værktøj 1 Projektbeskrivelse

Værktøj 1 Projektbeskrivelse Værktøj 1 Projektbeskrivelse En projektbeskrivelse er oftest knyttet til bibliotekets mission og vision. Projektbeskrivelsen er et dynamisk dokument, som tjener flere formål, alt efter hvilken af projektets

Læs mere

Design dit eget computerspil med Kodu

Design dit eget computerspil med Kodu Design dit eget computerspil med Kodu I sensommeren var vi to CFU-konsulenter ude i SFO en på Borup Ris Skolens Grønbro-afdeling. Her var vi sammen med børnene for at få erfaringer i arbejdet med platformen

Læs mere

Den Kreative Platform i DGI Uhæmmet anvendelse af viden fra forening til forening

Den Kreative Platform i DGI Uhæmmet anvendelse af viden fra forening til forening Den Kreative Platform i DGI Uhæmmet anvendelse af viden fra forening til forening I må gerne sætte jer ned Det vi ser og forstår er styret af mønstre I hjerne og krop Vi ser det vi plejer at se Vi forstår

Læs mere

Branchens perspektiv på den gode indkøbs organisation. En måling er bedre end 100 mavefornemmelser. Per Hartlev

Branchens perspektiv på den gode indkøbs organisation. En måling er bedre end 100 mavefornemmelser. Per Hartlev KL s Dialogforum for it-leverandører og konsulenthuse 7. november 2016 Branchens perspektiv på den gode indkøbs organisation En måling er bedre end 100 mavefornemmelser Per Hartlev ph@whitebox.dk 7/11-2016

Læs mere

Vejledningen til proces for design af fremtidsmodellen

Vejledningen til proces for design af fremtidsmodellen Vejledningen til proces for design af fremtidsmodellen Januar 2014 Indhold 1. FORMÅL... 3 FORMÅLET MED DENNE PROCESVEJLEDNING... 3 2. FREMTIDSMODELLENS OMRÅDER... 3 2.1. AKTIVITETER... 4 DEFINER OVERORDNEDE

Læs mere