BabeLLab Et netværksbaseret sproglaboratorium

Størrelse: px
Starte visningen fra side:

Download "BabeLLab Et netværksbaseret sproglaboratorium"

Transkript

1 BabeLLab Et netværksbaseret sproglaboratorium Eksamensopgave i: Projektkursus Systemudvikling 2011 Søren Frejstrup Grav Petersen, CPR: KU-Bruger: cng863, Eksamensnummer: 21 Instruktor: Andreas Frisch Gruppe-id: A0-4 Gruppemedlemmer: Thomas Nørskov Nielsen Martin Simon Haugaard Ruben Nielsen Kursus-id: 5100-B3-Førsteårsprojekt/Fl/01 Afleveret d. 20 juni 2011

2 Dette værk er en eksamensopgave omhandlende et førsteårsprojektkursus i datalogi skrevet af Søren Frejstrup Grav Petersen, Datalogisk Institut, Det Naturvidenskabelig Fakultet, Københavns Universitet, Danmark. Dokumentet, herunder layout og typografi er trykt ved hjælp af L A TEX2 ε i dokumentklassen extarticle. Brødteksten er trykt med Computer Modern 12pt med margin på 1.08in. Forsidebilledet er en skitse over udbredelsen af de forskellige sprogstammer i verden.[7] Layout og typografi er fremstillet af forfatterne ved hjælp af følgende L A TEX2 ε pakker: inputenc, fontenc, babel, amsfonts, amsmath, float, geometry, graphicx, color, url, tikz, multirow, rotating, sidecap, caption, listings. Alle figurer benyttet i dokumentet, bortset fra forsidebilledet, er originale, og er konstrueret med freeware programmet Diagram Designer[20] og L A TEX2 ε s egne funktioner. i

3 Indhold 1 IT-projektet Oversigt Uddrag af problemområdet Anvendelsesområdet Endelig model Brugergrænsefladen Programdokumentation Uddrag af implementationen Om samarbejdet Forholdet udadtil Forholdet indbyrdes i gruppen Refleksion over resultat og forløb Styrker og svagheder samt samspil mellem projektaktiviteterne Forbedringer Diskussion af udvalgt artikel Tilgang til systemudvikling og erfaringer Ligheder og forskelle mellem artikel og kursuslitteratur Litteraturliste 20 A Første prototype 22 A.1 Valg af prototype A.2 En elev og en lærers brugergrænseflade A.3 Navigeringsdiagrammer A.4 Evaluering og resultat af første prototype A.5 Analyse og diskussion af evaluering A.6 Konklusion af første prototype B Anden prototype 27 B.1 Navigeringsdiagram B.2 Evaluering af anden prototype B.3 Resultat af evaluering B.4 Analyse og diskussion af evaluering B.5 Konklusion af anden prototype C Eksempel på kode 36 C.1 Online_db_mod klassen D Uddrag af Javadoc 49 D.1 Package control D.2 Package database D.3 Package exceptions D.4 Package makedatabases D.5 Package view ii

4 E Referater 50 E.1 Første møde med ITMEDIA, KUA 9/ E.2 Sproglaboratoriebesøg v. Nina Møller Andersen 16/ E.3 Sproglaboratoriebesøg v. Elena Lorentzen 21/ E.4 Workshop v. ITMEDIA for alle interesserede 23/ E.5 Møde med ITMEDIA, KUA 4/ E.6 Møde med ITMEDIA, KUA 6/ iii

5 Figurer 1 MVC-klassediagram Tilstandsdiagram for elev Tilstandsdiagram for lærer Klassediagram Navigeringsdiagram for system lærer Interface - Classroom Editor Brugergrænseflade for en elev Brugergrænseflade - Øvelse Samarbejde og kommunikation Elev grænseflade Elev grænseflade - Open Exercise Elev grænseflade - Submit Answer Lærer grænseflade - Create Exercise Lærer grænseflade - Classroom Editor Lærer grænseflade - Add Student Lærer navigeringsdiagram Lærer navigeringsdiagram Login Skærm Velkomstskærm Brugergrænseflade for en elev Brugergrænseflade - Øvelse Brugergrænseflade - Optag Brugergrænseflade - Hide overview Brugergrænseflade - Change Brugergrænseflade - Change Navigeringsdiagram anden prototype iv

6 Ordliste Til at begynde med, vil jeg kort komme med en række grundbegreber, som jeg vil benytte mig af i opgaven. Grunden til at jeg nævner disse her, er for klart at definere, hvem/hvad jeg hentyder til, når jeg fremover benytter nedenstående begreber, samt at introducere begreber, som det ikke kan forventes, at læseren er bekendt med på forhånd. Kunden ITMEDIA, som er en underafdeling af Det Humanistiske Fakultet ved Københavns Universitet( ITMEDIA [12]). Systemet/programmet IT-systemet, som jeg, i samarbejde med min gruppe, har fremstillet under navnet BabeLLab. Sproglaboratorium Et undervisningslokale med arbejdsstationer beregnet til brug af sprogstuderende. Øvelseselement Et element der repræsenterer en side i en øvelse. Elementet kan indeholde alt fra lydafspillere, lydoptagere til helt almindelig tekst. 1 IT-projektet Jeg vil i dette afsnit forklare om IT-projektet, og hvad dette indebar af analyse og udvikling. 1.1 Oversigt Jeg vil her komme med en skematisk oversigt over projektforløbet. Dette vil jeg gøre i form af figur 1 på side 2. For at lægge ekstra vægt på brugerkontakt, har jeg valgt at beskrive disse i følgende, som også kan findes i figuren under samme nummerering: 1 Indledende møde med kunde. Her tog vi ud og mødte vores kunde for første gang. Se bilag E.1 for referat. 2 Møde m. bruger. En del af analysen af problemområdet. Her fik vi fortalt hvorledes det nuværende system fungerede og kom selv ud og prøvede systemet. Se bilag E.2 for referat. 3 Møde m. bruger. En del af analysen af anvendelsesområdet. Her mødtes vi med en bruger, som allerede anvendte et computerbaseret sproglaboratorium, men godt kunne tænke sig udvidet funktionalitet. Se bilag E.3 for referat. 4 Workshop. En del af analysen af anvendelsesområdet. Her lavede vi en workshop sammen med mulige brugere af vores system. Til denne udførte vi en såkaldt Affinity Diagramming (fra What is Affinity Diagramming? [8]). Se bilag E.4 for referat. 5 Møde m. kunde. Evaluering af papirsprototype. Her mødtes vi med vores kunde for at evaluere vores første prototype. Se bilag E.6 for referat og A for beskrivelse. 6 Møde m. bruger. Evaluering af den kørbare prototype. Her mødtes vi med en bruger for at evaluere vores anden prototype. Se bilag B for beskrivelse.

7 2 1 IT-PROJEKTET Brugerkontakt Analyse Design Prototyper Evaluering Analysedel Udviklingsdel Problemområde Anvendelsesområde 1. prototype 2. prototype 2Møde m. bruger 3Møde m. bruger 6Møde m. bruger 1Indledende møde m. kunde 4Workshop 5Møde m. kunde Analyse af problemområde Analyse af anvendelsesområde Design af komponenter Design af arkitektur Papirsprototype Kørbar prototype Papirsprototype Kørbar prototype Tid Figur 1: Oversigt over projektforløb. Alle tilfælde af brugerkontakt er yderligere uddybet på side 1.

8 1.2 Uddrag af problemområdet Uddrag af problemområdet Jeg vil her beskrive nogle af de centrale fænomener fra analysen af problemområdet: Aktørerne Elev og Lærer. De to brugertyper vi endte med at have med i vores system, var eleven og læreren. Vi valgte kun at have disse to med, da disse var de eneste der skulle interagere med vores system, og der således ikke var brug for f.eks. en administrator. Den eneste væsentlige forskel der er på en elev og en lærer, er at eleven har begrænsede muligheder i forhold til læreren. Dette afspejler sig i, at en lærer har adgang til at administrere hold af elever, fremstille nye øvelser, samt at rette elevers besvarelser, hvorimod en elev grundlæggende kun kan besvare øvelser. Objektet Øvelse. Det mest centrale fænomen fra vores problemområde viste sig at være en øvelse. En øvelse består i abstrakt forstand af en skal, som i princippet kan indeholde en vilkårlig mængde eller type af information, det være sig video, lyd, interaktive medier eller blot tekst. Sproglaboratorierne på Humanistisk Fakultet ved Københavns Universitet fungerer i øjeblikket kun med tekst og lyd, hvortil vi i vores projekt derfor har valgt at koncentrere os om disse, dog med senere mulig udvidelse af video og interaktive medier. En øvelse kan derfor bestå af tekst og lyd, som en elev kan besvare også enten i form af tekst eller lyd. Hændelsen Indtale besvarelse. Det sidste centrale fænomen fra vores problemområde er muligheden for at besvare en øvelse. En elev skal i form af tekst eller lyd kunne besvare en øvelse. Dette foregår ved at eleven efter afspilning af en fremmedsproget tekst, selv skal forsøge at udtale teksten. Dette forsøg optages i systemet, og eleven kan herefter vælge om han/hun vil gemme sit forsøg til senere rettelse af en lærer. 1.3 Anvendelsesområdet Jeg vil her komme ind på i hvilke situationer vores system skal anvendes. Vores system skal anvendes i tre forskellige områder. Det første område involverer både læreren og eleven, hvor de to andre vil være fokuseret på læreren hhv. eleven. Disse tre områder vil have nogle fælles egenskaber, men da de fysisk fungerer på vidt forskellige måde, vil jeg beskrive hver af disse seperat i følgende: Første anvendelsesområde - Sproglaboratorium Det første område er det sædvanlige sproglaboratorium miljø, der består af en eller flere lærere og en eller flere elever. Vores system kan i denne situation indgå på samme måde, som det er tilfældet i et oprindeligt sproglaboratoriumlokale. I dette tilfælde skal vores system tage over for båndoptagere og tekst i form af papir. Lærerne og eleverne behøver ikke nødvendigvis at være placeret i samme lokale, da vores system også er åbent overfor fjernlæring. Dette ses i form af, at der ikke nødvendigvis skal være fysisk kontakt mellem lærer og elev, men at denne kontakt blot kan ske via internettet. Den fysiske kontakt vil selvfølgelig fjerne nogle umiddelbare problemer, da eleven i så fald kan få hjælp direkte af læreren både til programmet og til øvelserne, men den er ikke nødvendig for at systemet fungerer.

9 4 1 IT-PROJEKTET Andet anvendelsesområde - Selvundervisning Det andet område vores system skal fungere i, er situationen, hvor en studerende besvarer en øvelse uden en lærer til at vejlede sig. Der er i dette område ikke noget krav om, at den studerende skal have internetforbindelse, da alt materiale blot kan gemmes lokalt til senere synkronisering med den centrale database. I denne forstand skal vores IT-løsning altså fungere som en offline-klient, der omtrent giver den studerende de samme muligheder, som en almindelig undervisningssituation vil give. I dette anvendelsesområde indgår læreren altså ikke Tredje anvendelsesområde - Administrering Det tredje problemområde omhandler situationen, hvor en lærer ønsker at fremstille øvelser til brug i undervisningssituationer. Her skal læreren have mulighed for at uploade lydfiler til den centrale database, lave øvelser, der kan tilgå databasen for at hente lydfiler, samt administrere disse øvelser. I dette anvendelsesområde indgår eleven altså ikke Brugsscenarier Her vil jeg beskrive to forskellige scenarier, som systemet bl.a. skal bruges til. Dette vil jeg gøre ud fra følgende tilstandsdiagrammer (se figur 2 og figur 3) og de efterfølgende forklaringer. Til tilstandsdiagrammerne skal det bemærkes, at lærer udover de viste mulighder også har samme muligheder som en elev. Disse har jeg dog ikke valgt at tage med i figur 3, da de lige så tydeligt kan ses ud fra figur 2. Endvidere skal det også bemærkes, at både en elev og en lærer til enhver tid kan vende tilbage til startskærmen, dog vil dette i de fleste tilfælde resultere i et tab af data. Figur 2: Tilstandsdiagram for elev.

10 1.4 Endelig model 5 Figur 3: Tilstandsdiagram for lærer. De to scenarier som jeg vil beskrive følger nu, hvor jeg vil gå ud fra, at læreren eller eleven har udgangspunkt ved startskærmen: Fremstille øvelse Når en lærer vælger at fremstille en øvelse, skal han/hun åbne et Ny øvelse -vindue. I dette vindue kan læreren tilføje eller fjerne såkaldte øvelseselementer, som vil blive repræsenteret i øvelsen som én side. Et øvelseselement kan indeholde både lyd og tekst, som læreren selv vælger. Læreren tilføjer nu de ønskede øvelseselementer og øvelsen gemmes, hvortil læreren bliver returneret til startskærmen. Besvare øvelse Når en elev ønsker at besvare en øvelse, skal elev først og fremmest åbne den ønskede øvelse. Herfra kan eleven bladre igennem øvelsens øvelseselementer, og give en besvarelse på hver enkelt af dem. Når eleven er tilfreds med sin besvarelse, kan han/hun vælge at afslutte øvelsen og aflevere sin besvarelse, som altså består af en besvarelse til hver enkelt øvelseselement i øvelsen, eller eleven kan vælge at gemme de svar han/hun har lavet og aflevere dem på et andet tidspunkt. Sidstnævnte mulighed er brugbar, hvis eleven ikke har tid eller lyst til at besvare samtlige øvelseselementer på det givne tidspunkt, hvortil eleven senere hen vil kunne genoptage besvarelsen af øvelsen. 1.4 Endelig model Her vil jeg beskrive den endelig model over IT-projektet. For at beskrive modellen, har jeg valgt at fremstille et klassediagram, der viser strukturen mellem klasserne i

11 6 1 IT-PROJEKTET det endelige system, som ses på figur 4. I denne model har jeg valgt at benytte mig af associaseringsstrukturen til at vise de indbyrdes relationer mellem klasserne. Endvidere har jeg benyttet aggregeringsstrukturen mellem en øvelse og dets øvelseselementer, en øvelse og en besvarelse, samt en delbesvarelse og en besvarelse. Grunden til at jeg har gjort dette er, at både et øvelseselement samt en besvarelse ikke kan eksistere uden at være tilknyttet én bestemt øvelse, da et øvelseselement er en del af en øvelse, og en besvarelse kan ses som en udvidelse af en øvelse. Endvidere kan en delbesvarelse heller ikke eksistere uafhængigt af en besvarelse. Øvelse-Øvelseselement -aggregeringen er af typen Helhed-Del, Øvelse-Besvarelse -aggregeringen er af typen Beholder-Indhold, og Besvarelse-Delbesvarelse er af typen Helhed-Del som defineret i Objektorienteret analyse & design [14, s. 77]. Til sidst har jeg valgt at beskrive en lærer og en elev som generaliseringer af en bruger. Dette har jeg gjort, da en lærer og en elev deler mange egenskaber, som derfor kan opsummeres i en abstrakt klasse, nemlig brugerklassen. Figur 4: Jeg vil nu beskrive de centrale fænomener, som jeg beskrev i sektion 1.2, ved følgende: Aktørerne Elev og Lærer. Disse to indgår som klasser i den endelige model, og er en generalisering af brugerklassen. En lærer er forbundet til en øvelse og en lydfil som forfatter af disse, og er forbundet til en klasse som underviser for denne. En elev er forbundet til en besvarelse som forfatter og til en klasse som medlem i klassen. Sidstnævnte relation vil normalt blive betragtet som en aggregering,

12 1.5 Brugergrænsefladen 7 men da en elev både kan eksistere uden at være tilmeldt en klasse, og kan være tilmeldt flere klasser på samme tid, vil aggregeringsstrukturen ikke virke her. Objektet Øvelse. En øvelse er forbundet til en klasse som lektie for klassens medlemmer. En øvelse har to andre klasser (øvelseselement og besvarelse), som er aggregeret op i klassen, som beskrevet tidligere. Hændelsen Indtale besvarelse. Denne hændelse er beskrevet ved klasserne Besvarelse, Øvelseselement og Øvelse. En elev opretter en besvarelse ved at oprette en række delbesvarelser til øvelseselementer og aflevere dem i en samlet besvarelse. 1.5 Brugergrænsefladen Jeg vil her komme med en række af eksempler på hvorledes brugergrænsefladen til vores system ser ud. Dyberegående forklaring af alle eksemplerne ses i figurteksten under den tilhørende figur. Før jeg kommer med konkrete skærmbilleder, vil jeg dog først vise et navigeringsdiagram for at vise hvorledes skærmbillederne hænger sammen. Dette følger i figur 5. Figur 5: Navigeringsdiagram for system. Dette diagram repræsenterer mulighederne i vores system. En lærer har adgang til alle mulighederne, mens en elev ikke har adgang til mulighederne omkranset med stiplede linier. Det første eksempel jeg vil komme ind på, er et uddrag fra vores første prototype. Den første prototype vi fremstillede, var en papirsprototype, og uddraget som jeg har valgt, ses på figur 6. Uddraget omhandler klasseeditoren, som er yderst vigtig for en lærer, da det bl.a. er her en lærer kan tilgå sine klasser og give eleverne lektier for. Grunden til, at jeg har valgt dette eksempel, er at udover at lave øvelser, er det her læreren vil komme til at bruge mest tid i vores system.

13 8 1 IT-PROJEKTET Figur 6: Dette vindue repræsenterer klasseeditoren, hvor en lærer kan administrere sin klasser. I dette kan læreren se sine aktuelle klasser, og ved at trykke på New Class -knappen kan læreren oprette en ny klasse. Ved at markere en bestemt klasse kan læreren se klassen elever til højre. Herfra kan læreren fjerne eller tilføje en eller flere elever ved knapperne Remove From Class og Add Student(s) To Class. Figur 7: Ovenstående vindue er brugergrænsefladen for en elev. I venstre side har eleven et overblik og sine klasser og øvelser. Eleven kan herfra vælge at åbne en øvelse eller navigere rundt i den træbaserede menu, samt se en velkomstbesked i højre side.

14 1.6 Programdokumentation 9 Resten af eksemplerne på brugergrænsefladen er fra vores anden prototype, som er en kørbar Java-prototype. Det første eksempel jeg vil komme ind på, er startskærmen for en elev, som ses på figur 7, hvorfra en elev kan benytte alle de funktionaliteter, som vores system giver ham/hende adgang til. Jeg har valgt at tage dette med her, da det er væsentligt at vise, hvorledes systemet åbnes op for brugeren for at give et helhedsindtryk af systemets udseende. Figur 8: Ovenstående vindue repræsenterer, at en elev har åbnet en øvelse fra menuen til venstre i vinduet. Eleven kan herfra vælge at afspille lydøvelsen med Play -knappen eller indspille sin egen lyd med Record -knappen. Til sidst kan eleven vælge at bladre mellem øvelsens sider ved at benytte Next - og Previous -knapperne i bunden af skærmen, og trykke submit for at aflevere sin besvarelse. Det sidste eksempel jeg vil komme ind på, er øvelsesvinduet, som ses på figur 8. Dette er den mest centrale del for en elev, da det er her eleven læser og lytter til øvelser, og giver sin besvarelse. Det er dette vindue, som vil være det en elev vil bruge langt størstedelen af sin tid på under brugen af vores system, hvilket er grunden til at jeg har taget det med her. 1.6 Programdokumentation Jeg har valgt at beskrive, hvilke Java-klasser i vores program der svarer til klasserne i analysedelen som programdokumentation. Derudover kan resten af klasserne og deres sammenhæng ses i et udsnit af vores Javadoc, som jeg har vedlagt i bilag D. Det skal her bemærkes, at alle klasserne overført fra analysedelen er placeret i pakken database, hvor de fungerer som en indre struktur for systemet. Udover denne pakke, er der pakkerne control, som indeholder opstartsklasserne, view, som indeholder grænsefladen, exceptions, som indeholder undtagelser og makedatabases, som indeholder funktionaliteten til at skrive til og fra databaser. Klasserne overført fra analysedelen er som følger:

15 10 1 IT-PROJEKTET Exercise Svarer til øvelsesklassen. ExElement Svarer til øvelseselementklassen. Group Svarer til klasseklassen. Solution Svarer til besvarelsesklassen. Teacher Svarer til lærerklassen. Student Svarer til elevklassen. User Svarer til den abstrakte brugerklasse. En udførbar udgave af programmet, samt hele javadoc en kan hentes på denne url 1. Zip-filen skal udpakkes og herefter kan BabelLap.jar åbnes for at åbne systemet. Systemet er testet til at køre på Windows Vista, Windows XP og Ubuntu alle med den nyeste opdatering af Java. Javadoc en er at finde i mappen javadoc, og kan åbnes via filen index.html. 1.7 Uddrag af implementationen Delopgaven som jeg har udvalgt, omhandler hvorledes vi kunne oprette forbindelse til vores server via vores system uden at brugeren blev involveret rent teknisk, samt hvorledes vi vil kunne sørge for at data i databasen på serveren er konsistent. Da vores system er afhængigt af, at alt data kan hentes og gemmes på serveren, er dette en vital opgave for at systemet kommer til at virke. Dette er en relativ vanskelig opgave via Java, og da ingen af os i gruppen havde erfaring med dette, synes jeg at denne opgave både var udfordrende og interessant. Selve problemet bestod altså i at skrive en klasse, som både kunne varetage forbindelsen til serveren, men samtidig også holde styr på de relevante SQL-kald til databasen på serveren. Måden vi løste dette problem på, var ved at skrive en klasse kaldet Online_db_mod (Se bilag C.1). Når en instans af denne klasse bliver oprettet, vil vores system forsøge at oprette forbindelse til serveren via Java-pakken com.mysql.jdbc.driver som kan hentes fra (se [6]). Ved at indlæse denne pakke kan vi nu oprette en sikker forbindelse til serveren, og endvidere kan vi også via denne pakke kalde præcis de SQL-kald som vi ønsker til serveren. Det eneste problem der nu manglede, er hvorledes vi kunne holde data på serveren konsistent. Med konsistent mener jeg her, hvorledes vi kan sørge for f.eks. at en lærer ikke modificerer en øvelse samtidig med, at en elev henter denne øvelse. I dette tilfælde og lignende kan vi altså risikere, at elever og lærere ikke ser samme indhold i systemet. Måden vi løste dette på, var ved at benytte os af transaktioner og ved at holde forbindelsen til serveren på et minimum. For at holde forbindelsen til serveren i så kort tid som muligt, har vi lavet en funktion i klassen Online_db_mod, som sørger for at afbryde forbindelsen. Denne funktion kan man nu kalde, lige så snart man har kaldt de ønskede SQL-kald. Samtidig kan vi ved at benytte transaktioner sørge for, at kun én klient har adgang til serveren ad gangen, hvortil vi undgår inkonsistens. Der er dog en enkelt hage ved denne metode, nemlig såkaldt lag forbundet ved transaktioner. Men da vi kun benytter forbindelsen til simple SQL-kald, og disse er yderst hurtige, er dette ikke et problem, som brugerne af systemet vil lægge mærke til. 1 Hvis denne imod forventning skulle være nede kan Java_Prototype.html alternativt benyttes.

16 11 2 Om samarbejdet Jeg vil i dette afsnit komme ind på samarbejdet mellem de berørte parter i udviklingsprocessen bag systemet, samt det indbyrdes forhold i vores gruppe som systemudviklere. 2.1 Forholdet udadtil I forbindelse med vores projekt har der været tre parter involveret: Vores kunde, brugere og os selv i gruppen som udviklere. Kommunikationen der har foregået mellem de tre parter i løbet af projektet illustreres på figur 9. De to sorte pile illustrerer den primære faktiske kommunikation, mens den grå pil illustrerer kommunikation, der måske burde have foregået eller kun foregik i mindre grad, men dette vil jeg komme ind på senere. Jeg vil først beskrive forholdet mellem kunden og os som udviklere og derefter forholdet mellem brugerne og os som udviklere. Til sidste vil jeg runde af med fortælle, hvorledes kommunikationsprocesserne i fællesskab havde fungeret, hvis der havde været en højere grad af kommunikation mellem kunde og brugere. Figur 9: Samarbejde og kommunikation Vi har i løbet af vores projekt både mødt vores kunde fysisk samt kommunikeret med kunden via . kommunikationen er kun foregået ved mindre spørgsmål, som vi skulle have afklaret samt planlægning af møder og forløb. Dette har gjort, at kunden har kunnet følge med i alle faser af udviklingsforløbet, uden at vi har måtte mødes unødigt ofte. Den fysiske kontakt mellem kunden og os er foregået ved møder, hvor vi primært har talt, om hvad kunden ønskede af produktet. I løbet af disse møder er der særligt et enkelt emne der springer ud, og bortset fra dette har vores kunde ikke blandet sig i vores udviklingsproces, medmindre vi har taget kontakt til dem. Dette anser vi som værende positivt, da vi så har kunnet koncentrere os fuldstændig om det analytiske arbejde og udviklingsprocessen bag systemet. Jeg vil nu forklare om emnet, der særligt sprang ud: Under workshoppen (som nævnt på side 1) som vi holdte med brugerne, fortalte en af brugerne, at han benyttede sig af en webbaseret løsning (kaldet Moodle [16]), der næsten opfyldte vores kundes ønske. Da vores kunde ønskede at være til stede ved denne workshop, både for at hjælpe os med projektet, og for at møde et lille udvalg af de mulige brugere, blev kunden her klar over denne løsning fandtes. Vores kunde ønskede herefter, at vi skulle lave en Java-baseret løsning, så brugere kunne benytte Moodle s funktionaliteter, men ikke behøvede at have en webbrowser åben, som er kravet ved Moodle. Dette krævede at vi både lavede en PHP-del samt en Java-del, og til gengæld

17 12 2 OM SAMARBEJDET ville vi så slippe for at skulle arbejde med databasedesign. Vi begyndte herefter så småt i udviklingsgruppen at sætte os ind i Moodle s opbygning og kildekode. Vores kunde fandt dog senere hen ud af i samarbejde med os i udviklingsgruppen, at de alligevel ikke ønskede, at vi skulle benytte os af Moodle. Dette resulterede i, at vi herefter skulle skifte fra at arbejde med PHP og Java til nu at arbejde med SQL og Java. Grunden til dette ønske var, både af hensyn til os som udviklere, og vi dermed ikke behøvede at koncentrere os om at få PHP og Java til at arbejde sammen, men også af hensyn til dem selv, da det omkostningsmæssigt er langt sværere at få en Moodle-server op at køre end en SQL-server. Til gengæld måtte vi nu selv sørge for at sætte databasen på serveren op. Om dette skifte har resulteret i mere eller mindre arbejde for os som udviklere er svært at sige, da vi ikke nåede at planlægge vores udviklingsarbejde i første omgang før skiftet, men vi har i hvert fald brugt unødigt meget tid på at sætte os ind i Moodle s opbygning. Man kan så diskutere om vi har fået noget ud af at undersøge Moodle s system rent analytisk, men dette mener jeg ikke er relevant at tage op her. Vi har igennem IT-projektet også mødtes med en række brugere, hvor vi primært har valgt at koncentrere os om at interviewe lærere, da vi mener, at lærere har mere at bidrage med i modsætning til elever til vores system i udviklingsfasen. Dette ses bl.a. i at en stor del af vores system er direkte henvendt til lærerne og ikke eleverne. Disse møder har foregået i diverse sproglaboratorier tilhørende Humanistisk Fakultet ved Købehavns Universitet, hvor vi har på førstehånd har kunnet erfare, hvorledes sproglaboratorier virker og er bygget op. Vi har mødtes med mange forskellige brugere i løbet af projektet. Da disse brugere indbyrdes har været forskellige, vil jeg forsøge at beskrive forholdet til vores brugere ved at trække på fælles egenskaber blandt brugerne. Grundlæggende har brugerne været meget interesserede i vores projekt, da nye ITløsninger ofte har et positivt klang over sig, og vores system specielt vil komme dem til stor gavn i undervisningen. Dette gjorde det selvfølgelig langt nemmere for os i udviklingsgruppen via interviews at få interessante detaljer med både i analysedelen samt udviklingsdelen, da brugerne da var langt mere engagerede i at vores projekt skulle lykkes. I løbet af projektet sørgede vi for kun at mødes med én bruger ad gangen, da vi på denne måde kunne koncentrere os fuldt om, hvad den enkelte bruger havde at sige til projektet. Det eneste tidspunkt vi mødtes med flere bruger på en gang var ved vores workshop. Ved denne workshop fremgik det tydeligt, at brugerne ikke var klar over hvad de i fællesskab ønskede sig af vores projekt. De havde hver især en given undervisningsmetode, som de gerne vil have trumfet igennem i vores system. Dette afspejler sig i, at mange af vores potentielle brugere før vores workshop ikke havde mødt hinanden til trods for, at de alle var ivrige brugere af sproglaboratorier på Humanistisk Fakultet. Det var derfor op til os som udviklere at samle brugernes ønsker til et fælles sæt af ønsker, som derfor blev målet med workshoppen. Til sidst vil jeg som sagt runde af med at fortælle lidt om, hvordan det fælles forhold kunne have fungeret bedre. Hvis der havde været en større grad af kommunikation mellem kunde og brugere, havde vi som udviklere ikke behøvet at bruge tid på at opsøge brugerne selv, og kunden havde ydermere også haft lang større indflydelse på projektets forløb. Endvidere havde kunden også i fællesskab med brugerne kunne sætte en kravsspecifikation op til os, før vi overhovedet gik i gang med projeket. Dette havde gjort, at vi ikke havde haft brug for at lave den samme mængde undersøgelser før udviklings-

18 2.2 Forholdet indbyrdes i gruppen 13 processen, samt at brugerne havde haft en bedre fornemmelse af hvad projektet i sidste ende ville komme til at omhandle. Til gengæld var det på denne måde ikke sikkert, at vi ville ende op med et produkt af samme kvalitet, da vores kravsspecifikation jo har været igennem en analytisk proces, som man ikke kan forvente af kunden og brugerne i fællesskab. Ligeledes kan det heller ikke forventes af kunden, at de har gjort denne slags forarbejde inden de sætter projektet igang. Alt i alt ville vi både før og under projektet have haft stor gavn af, at kunden havde taget initiativ til at tage kontakt med brugerne, da dette ville have taget noget arbejdsbyrden fra os. Dog hører denne arbejdsbyrde ofte også med til et IT-projekt, så det er ikke noget vi kunne forvente af vores kunde, men hvis kunden havde ønsket mere indflydelse i projektforløbet, var dette klart vejen at gå. 2.2 Forholdet indbyrdes i gruppen Det indbyrdes forhold i gruppen er meget karakteriseret ved, at vi alle havde meget forskellige kvalifikationer samt arbejdesmetoder. For ikke at hænge nogen ud her i opgaven, vil jeg ikke beskrive specifikke personer, men snarere beskrive personernes egenskaber som en del af fællesskabet i gruppen. Generelt var vi som sagt meget forskellige individer, som resulterede i at vi påtog os forskellige roller under forløbet. Nogle var gode til at beskrive ting analytisk, mens andre var bedre til den tekniske del af projektet. Denne rollefordeling skete i løbet af projektet, og alle medlemmer faldt automatisk ind i den rolle de var bedst til. Dette havde både positive og negative sider. På den positive side resulterede dette i, at dem der lavede tingene også var de bedste til det, mens det på den negative side resulterede i, at alle ikke fik lov at være med hele vejen rundt i alle de aspekter af projektet de ønskede. Endvidere er en negativ konsekvens af dette også, at projektet manglede en klart defineret leder, der kunne holde overblik og fortælle alle hvad de skulle lave. I stedet lavede folk bare det de var bedst til, hvortil nogle områder måske blev forsømt på tidspunkter de ikke burde. Med hensyn til planlægning af forløbet, gjorde vi allerede i begyndelsen af projektet meget ud af at lave en dagsorden for hvert møde, vi havde internt i gruppen. Dette gjorde vi bl.a. for at sikre, at vi nåede de tidsfrister der var sat for os, samt at få overblik over opgaverne der skulle laves. Dagsordnerne blev lavet i et fælles medium ( Google Docs [10]), så alle kunne være med til at planlægge. Disse dagsordner brugte vi senere i projektforløbet til at uddelegere arbejdsopgaver, ved at folk kunne skrive sig på en ting, der skulle laves ved næste møde. Nogle medlemmer havde i løbet af projektet svært ved at holde sig til tidsplanen mht. mødetider og var svære at kommunikere med. Dette skabte en smule splid i begyndelsen, da nogle medlemmer så pådrog sig flere arbejdsbyrder end andre til visse tider, for at være sikker på at tingene blev lavet. Vi erkendte at dette var et problem, og vi fik afhjulpet dette under selve udviklingsfasen ved at indføre en ny arbejdsmetode, hvor vi benyttede en CVS-server til at arbejde sammen over (mht. programmering). Dette gjorde at vi ikke i samme grad behøvedes at mødes, for at det gik fremad med projektet, samtidig med at arbejdsbyrden blev nogenlunde ligeligt fordelt, da man så kunne følge med i at andre fik lavet de uddelegerede opgaver. Når nøgleopgaver under forløbet ikke blev løst tilfredsstillende, forsøgte andre at tage over for at opgaven blev løst indenfor tidsrammen. Bagefter diskuterede vi så i fælles-

19 14 3 REFLEKSION OVER RESULTAT OG FORLØB skab hvorledes vi kunne undgå disse, og om det var et resultat af forkert uddelegering af opgaver. Et konkret eksempel på dette, er review-opgaverne vi fik stillet i forbindelse med at skulle aflevere rapporter. Her var det ikke altid at disse blev prioriteret højst af medlemmerne, der havde fået dem uddelegeret, og andre måtte derfor i sidste ende træde til og hjælpe med at få strikket et review sammen. Denne arbejdsmetode er ikke holdbar i længden, men da projektet strakte sig over et relativt kort forløb, og metoden til dels var et resultat af de indlagte tidsrammer, føler jeg at denne metode var den rigtige at anvende i den givne situation. 3 Refleksion over resultat og forløb Jeg vil i dette afsnit reflektere over resultatet og forløbet af IT-projektet. Til dette vil jeg først komme ind på nogle af de styrker og svagheder, der var omkring planlægningen af projektforløbet, samt samspillet mellem de forskellige projektaktiviteter. 3.1 Styrker og svagheder samt samspil mellem projektaktiviteterne En af de væsentligste styrker ved de tidlige aktiviter i projektforløbet, nemlig analysedelen, var at den gav os en solid bund både teoretisk men også analytisk i forhold til projektet vi kastede os ud i. Analysen gjorde os i stand til at påbegynde modelleringen af systemet, inden vi overhovedet havde nået at komme til enighed om et fælles programmeringssprog, hvilket endvidere sørgede for, at vi fik tænkt systemet igennem før vi nåede til at konkretisere det. Endvidere sørgede planlægningen af projektforløbet også, at vi under hele forløbet havde overblik over de ting vi havde nået, og stadig skulle nå. Ydermere virkede de indlagte deadlines meget positivt, da forløbet således blev splittet op i mindre overskuelige dele, i stedet for at alting skulle laves til en fælles deadline til sidst i forløbet. Dette kan sammenlignes lidt med Extreme Programming [11], hvor man tilstræber mange små releases og altså dermed mange små deadlines. Igennem projektforløbet kan man sige, at vi fulgte en noget forsimplet udgave af spiral modellen A spiral model of software development and enhancement [4], hvor vi nåede at fremstille og evaluere to prototyper. Vores udgave af modellen var forsimplet, da vi således kun nåede igennem to iterationer, og ikke havde risiko analyser med i vores spiral, som de er påtænkt i modellen, dog benyttede vi os samtidig også af de sædvanlige OOAD-aktiviteter, såsom analyse og design, som vi fik indopereret i de tidlige stadier af spiralen. En ulempe ved ikke at følge spiralmodellen i denne forsimplede udgave var, at vi ikke nåede særlig mange iterationer, hvilket netop er styrken ved spiralmodellen. Vores planlægning var derimod fokuseret på at grundlaget skulle være sikret, før vi overhovedet gik igang med de iterative udviklingsfaser. På denne måde kan man sige at vi lagde os tæt op af vandfaldsmodellen A spiral model of software development and enhancement [4] i begyndelsen, og senere hen skiftede til spiralmodellen. Vi nåede dertil altså ikke at få særlig mange forbedringer ud af vores prototypeevalueringer, men opnåede dog alligevel en indsigt i styrken af disse. En svaghed ved projektforløbet var den manglende projektetablering i begyndelsen. Her kunne jeg godt have ønsket, at rollerne blandt gruppemedlemmerne var mere fastlagte,

20 3.1 Styrker og svagheder samt samspil mellem projektaktiviteterne 15 og jeg kunne godt have ønsket en leder, som kunne holde overblik og fortælle hvad de forskellige medlemmer skulle arbejde med i de forskellige faser. Med hensyn til samspillet mellem systemaktiviteterne, kan man sige at analysen grundlagde klasserne for design af modelkomponenten samt selve implementationen. Den gav overblik, over hvilke fokusområder der var nødvendige, og hvilke funktionaliteter der var påkrævede, hvilket hjalp til at mindske byrden under selve designfasen, da vi så ikke behøvede at analysere og designe samtidig. Selve designfasen gav indblik i hvor arbejdsfokus skulle lægges under de efterfølgende aktiviteter, dog kunne jeg godt have ønsket at denne fase lå tidligere. I vores forløb (jvf. afsnit 1.1), lå denne fase oveni udviklingen af den første prototype, hvilket trak fokus væk fra vigtigheden af at designe en god model og arkitektur til systemet, som det er tilskyndet i What is Software Architecture? [3]. Endvidere trak implementationsfasen også meget på designfasen, og da disse to faser noget af tiden overlappede, blev designet i visse tilfældet lavet ad hoc til løsninger i implementationen. Dette er ikke positivt, da vi i så fald kommer til at trække på sprogspecifikke løsninger, i stedet for løsninger som virker uafhængigt af implementationen, som det er tilfældet i Programming as theory building [15]. I takt med at vi fik udviklet vores prototyper, erfarede vi, at væsentlige dele af vores model måtte omstruktureres. Dette indebar bl.a. muligheden om en superlærer med specielle rettigheder i vores system, som dog viste sig unødvendig under evaluering af den anden prototype (se bilag B). På denne måde fik evalueringsprocessen væsentlig indflydelse på designfasen, som derved resulterede i den tidligere nævnte spiral model, som vi fulgte. Selve dokumentationen af projektet, og her tænker jeg analyse- og designdokumenter, hjalp medlemmerne til at holde fælles overblik og arbejde sammen. Disse gjorde at vi konkret kunne diskutere og designe løsninger i fællesskab, hvortil flere perspektiver blev vendt, end hvis et enkelt medlem f.eks. havde stået for designfasen. Endvidere forsøgte vi også i høj grad at dokumentere implementationen, her i form af Javadoc, så andre gruppemedlemmer nemt kunne sætte sig ind i specifikke programmeringsmetoder et bestemt gruppemedlem havde foretaget sig. Dette gjorde det f.eks. muligt for en udvikler at benytte sig af en anden udviklers klasser og funktioner uden at sætte sig ind i selve programmeringen af denne klasse. Med hensyn til kommunikation og samarbejde blev disse to aktiviteter væsentligt forbedret efter vi fik oprettet en fælles CVS-server (Concurrent Versions System), som det også er nævnt i afsnit 2.2. Før oprettelsen af CVS-serveren benyttede vi i langt større grad dagbogsformen, som den er beskrevet i Back to thinking mode: diaries for the management of information systems development projects [13], til at samarbejde og kommunikere igennem. I [13] er kommunikation igennem dagbøger ikke et emne, men da vores dagbøger blev lavet i et fælles medie ( Google Docs [10]), følte vi, at vi på denne måde nemt kunne strukturere kommunikationen samt holde styr på, hvad der var blevet aftalt mellem de forskellige medlemmer. Til sidst fungerede samarbejdet ofte som en slags mini-scrum, hvor ordet scrum er som defineret i Extreme Programming [11]. I stedet for den oprindelige definition af scrum, som består af en gruppe af udviklere, benyttede vi os ofte af muligheden for at planlægge i fællesskab, uddelegere opgaver og efter disse er fuldført, planlægge nye opgaver. På denne måde kan man opfatte medlemmerne i min gruppe som mini-

21 16 3 REFLEKSION OVER RESULTAT OG FORLØB scrums, som altså fungerede på samme måde som scrums i Extreme Programming [11]. 3.2 Forbedringer For at vores projekt ville være forløbet mere optimalt, er der en række forbedringer, som man i et tilsvarende forløb med fordel kunne inkludere. En af disse er en klar projektetableringsfase i begyndelsen af forløbet, som det er nævnt i Professionel Systemudvikling [1]. I denne fase kunne man undersøge hinandens styrker og svagheder, og ud fra dette kunne man opsætte nogle roller som skulle holde igennem projektet. Endvidere kunne man også udnævne en ansvarlig, som havde til opgave at holde overblik over processen og lede de fælles møder i gruppen. Til sidstnævnte tænker jeg en form for scrumleder, som det er nævnt i Extreme Programming [11]. Herudover kunne man også forsøge at gøre designfasen mere uafhængig og ikke lave den samtidig med udviklingen af prototyper, da den så ofte bliver til ad hoc løsninger. Udviklerne bør derfor tilstræbe at gøre som i Programming as theory building [15], hvor designløsningerne er uafhængige af implementeringen af disse. Strukturen af kommunikationen, som vi foretog via Google Docs [10], kunne forbedres på mange måder. Nogle af disse kunne være at sikre at data ikke forsvandt, hvis f.eks. et medlem kom til at fjerne noget fra et dokument, som ikke skulle have været fjernet. Mens andre kunne være at gå over til en anden kommunikationsstruktur, hvor man oprettede en forum-lignende struktur, hvor man kunne oprette indlæg under forskellige emner, og disse indlæg bliver gemt i en fælles database. På denne måde kunne man strukturere samtalerne mellem medlemmerne, og hermed sørge for at holde irrelevant information væk fra vigtige emner. Dette ville også gøre, at medlemmerne bedre ville kunne holde overblik over hvilke områder, der mangler arbejdsfokus på. Metoden jeg derfor ville foreslå, ville være en blanding af dagbøger, som foreslået i Back to thinking mode: diaries for the management of information systems development projects [13], og et fælles forum for diskussion af vigtige emner vedrørende de forskellige udviklingsfaser. Endvidere oplevede vi også situationer, hvor programdokumentationen ikke levede op til den standard den burde. Dette skabte komplikationer og spildt tid i forbindelse med implementeringen, hvortil en klar forbedring var, at alle lavede klar og tydelig dokumentation i programmeringsfasen (i vores tilfælde Javadoc) på en fælles måde. Til sidst kunne en forbedring være at gennemløbe flere iterationer i forbindelse med prototype- og evalueringsfaserne, som det ses i A spiral model of software development and enhancement [4]. Disse gav tydelige resultater, og forbedrede på mange måde systemet, hvortil en forøgelse af disse ville være med til at give et langt bedre slutresultat. Dog skal mængden af iterationer ikke påvirke de andre udviklingsfaser negativt, så de skal selvfølgelig gøres med måde. Betingelserne for at disse forbedringer kan opsættes som retningslinier for et andet systemudviklingsprojekt, er at der er ordentlig tid til den analytiske del, hvilket kræver, at den udenforstående ledelse af projektet har tillid til udviklerne, da der ikke kommer nogle konkrete resultater i denne fase. Endvidere kræver det også, at der er tid nok til at et passende antal iterationer af prototyper og evaluering kan foregå for at opnå det bedst mulige resultat. En udenforstående ledelse kunne sagtens kræve at få udleveret en aktuel prototype som slutprodukt, hvor der måske i virkeligheden var brug for flere iterationer til trods for at produktet vir-

22 17 ker færdigt. Dette kræver selvfølgelig at den udenforstående ledelse igen har tiltro til udviklerne. Til sidst kræver den gode analytiske bund før selve udviklingsprocessen påbegyndes, at problemområdet og anvendelsesområdet ikke er uoverskueligt stort, da analysedelen i så fald vil blive en kæmpe opgave, og resten af faserne kan komme til at bukke under for denne. 4 Diskussion af udvalgt artikel Jeg vil i dette afsnit diskutere den udleverede artikel The M.A.D. Experience: Multiperspective Application Development in evolutionary prototyping [19], som jeg fremover vil betegne M.A.D. 4.1 Tilgang til systemudvikling og erfaringer Jeg vil her kort på punktform beskrive de tilgange, som udviklerne i artiklen har anvendt til systemudvikling: Hurtig, evolutionær udvikling af prototyper s. 9 En metode, hvor man så hurtigt som muligt udvikler nye prototyper og evaluerer disse, og herefter gentager processen med de nye betragtninger i forbehold. Samarbejdsdesign (Cooperative design) s. 12 En udviklingsmetode, hvor brugerne bliver taget med i både designfasen samt udviklingen af brugergrænseflader, for at opnå et bedre resultat, der er mere i stil med det brugerne ønsker. UML s. 20 En metode til at fremstille modellen i form af klasser og sammenhænge mellem disse. De benytter sig bl.a. af UML-begreber som aggregering, nedarvning og associasering. Model-View-Control lignede model s. 25 En metode, som minder om Model- View-Control -metoden (se Objektorienteret analyse & design [14, s. 186] (OO- AD)), som der bl.a. gives udtryk for i følgende: (...) to achieve independence between the user interface, the model and functionality layer. [19, s. 25] Parallel modellering, design og udvikling af prototyper s. 28 En proces, hvor modellering, design og udvikling af prototyper foregår parallelt i modsætning til sekventielt. Multiperspektivitet s. 29 En metode, hvor udviklingsgruppen ikke kun består af OO-udviklere med også f.eks. etnografer o. lign. 4.2 Ligheder og forskelle mellem artikel og kursuslitteratur I dette afsnit vil jeg komme ind på forskellene mellem metoder brugt i artiklen og metoderne fra kursuslitteraturen og diskutere disse. Måden jeg vil gøre dette på, er ved at diskutere tilgangene i samme rækkefølge, som de fremgår i afsnit 4.1. Dog vil jeg kort først komme ind på hvorledes opbygningen af projeket i M.A.D kan sammenlignes med kursuslitteraturen.

23 18 4 DISKUSSION AF UDVALGT ARTIKEL Selve projektetableringsfasen, som det fremgår af Professionel Systemudvikling [1], er ikke så tydelig i M.A.D. Dog bruger de relativt meget tid i artiklen på at forklare hvad de forskellige medlemmer af udviklingsgruppen havde af roller. På denne måde kan man sige, at der i forbindelse med M.A.D -projektet blev gennemgået en projektetableringsfase, men at den blev afviklet af højere instanser, som havde til ansvar at sætte udviklingsgruppen sammen, og ikke af selve udviklingsgruppen som det er tilfældet i Professionel Systemudvikling [1]. Den hurtige og evolutionære udvikling af prototyper ses mange forskellige steder i kursuslitteraturen. Selve metoden står i stærk kontrast til OOAD-metoden, hvor det er vigtigt, at analysen af problemområdet og anvendelsesområdet, samt andre udviklingsfaser såsom design og modellering, bliver gennemført før udviklingen af prototyper. Selve metoden minder lidt om spiralmodellen fra A spiral model of software development and enhancement [4], hvor udviklingsprocessen foregår som en iterativ proces koncentreret om udviklingen af prototyper og evalueringen af disse. På samme måde er den evolutionære udvikling af prototyper i M.A.D fokuseret på, at evalueringen af en prototype hele tiden er med til at skabe og forme den næste prototype, og på denne måde opnår man en evolutionær proces, hvor resultatet hele tiden er en bedre og bedre prototype kun med de nødvendige funktionaliteter. Metoden bliver også beskrevet i No silver bullet [5, s. 180], som et middel til at fastlægge systemets krav. Dette er er også tilfælde i M.A.D, som bl.a. ses ved [19, s. 14], hvor artiklens forfattere beskriver en iterationsproces. I denne proces fremviste de en prototype overfor en række potentielle brugere, som resulterede i en evaluering af prototypen. Ud fra resultatet af denne evaluering kunne udviklerne hurtigt implementere de nye idéer og fjerne ubrugelige idéer, alt sammen indenfor en tidsgrænse på få dage. Således er systemets krav ikke fastlagt fra begyndelsen, men bliver formet alt afhængigt af hvor evalueringerne af prototyperne trækker systemet hen. Til sidste bliver den hurtige, evolutionære proces også beskrevet i fænomenet Extreme Programming [11] (XP), dog ikke direkte. I XP er en af de grundlæggende metoder at have mindre releases af prototyper og en løbende integration af funktionaliteter, som disse prototyper giver anledning til. Dette stemmer fint overens med metoden i M.A.D, hvortil man kan argumentere for, at metoden brugt i M.A.D er en blanding af OOAD og XP. Samarbejdsdesignprocessen foregår som sagt, ved at brugere og kunden er til stede i designfasen og udviklingen af brugergrænsefladen. Dette ses især i XP, hvor en anden af de grundlæggende metoder er, at man i høj grad ønsker at kunden er til stede i forbindelse med udviklingen af systemet. Dette forhindrer mange misforståelser, som kunne opstå, hvis udviklerne har fejltoklet nogle grundlæggende hændelser i problemområdet, og ligeledes vil dette også øge effektiviteten i udviklingsprocessen, da alle spørgsmål kan stilles direkte verbalt til kunden, og ikke skal igennem andre mere tidskrævende kommunikationsprocesser. I M.A.D benytter de sig også af UML til at beskrive deres model, som også er beskrevet i kursuslitteraturen ved Objektorienteret analyse & design [14, s. 324]. De beskriver selv, at de ønsker at begrænse brugen af avanceret UML, da deres model i høj grad skal kunne fortolkes tilbage til mere almindeligt menneskesprog, så udviklerne kan trække på erfaringer fra folk uden forstand på det objektorienterede paradigme. De benytter sig dog af nogle generelle UML-begreber som aggregering, associasering og

24 4.2 Ligheder og forskelle mellem artikel og kursuslitteratur 19 nedarvning, som også ses i kursuslitteraturen ved Objektorienteret analyse & design [14, Kap. 4]. Endvidere benytter de i M.A.D modellen, som ofte er beskrevet ved hjælp af UML, til at opbygge deres softwarearkitektur. I What is Software Architecture? [3] beskriver forfatterne hvorfor det er vigtigt at have softwarearkitektur med fra begyndelsen af et projekt, samt hvad arkitekturen kan gøre for udviklingsprocessen. I M.A.D benytter de sig af netop denne tilgang. De begyndte et konkret sted, og lavede ud fra dette arkitekturen ved brug af UML på blackboards, for at konkretisere udviklingsprocessen. På denne måde opnår de en let tilgang til både at forklare udenforstående hvad konkrete dele af projektet går ud på, samt internt at holde overblik over hvor i processen de er nået til. Model-View-Control-metoden Objektorienteret analyse & design [14, s. 186] består i at opdele selve arkitekturen af deres system i tre næsten uafhængige dele, nemlig modellen, brugergrænsefladen og funktionaliteten. Dette forsøger udviklerne i M.A.D også at gøre, som det ses i citatet i afsnit 4.1. De beskriver i M.A.D, hvorledes de måtte sætte meget tid af til udvikle denne uafhængighed, men at den så også gjorde dem i stand til at udvikle hver af delene hurtigere, da komplekse sammenhænge mellem f.eks. modellen og funktionaliteten så ikke behøvedes at blive taget med i betragtning. Den parallelle udvikling af modellering, design og udvikling af prototyper ses ikke i kursuslitteraturen. Denne er i direkte modstrid med den sædvanlige OOAD-metode, som det også er argumenteret for i den hurtige udvikling af prototyper. Denne metode spiller derfor også godt sammen med den hurtige metode, da disse langt fra udelukker hinanden. Endvidere er metoden også i modstrid med vandfaldsmetoden, som beskrevet i A spiral model of software development and enhancement [4], da denne påkræver at det forrige led i en kæde er fuldført og valideret før det næste led i kæden kan påbegyndes. I den parallelle metode udvikles model, design og prototype simultant og er således ikke bundet af hinanden. Dette kan både have positive og negative aspekter. De positive aspekter består i, at processen ikke forsinkes af en stor kompleks model der skal udvikles før man kan gå igang med at designe løsninger til systemet. Dette kræver selvfølgelig en hvis form for brug af scrums som nævnt i Scrum and CMMI Level 5: The Magic Potion for Code Warriors [18], som kan klare hver udviklingsdel for sig selv. De negative aspekter består derimod i, at den naturlige følge af processer i OOAD er ødelagt, hvortil forrige faser, såsom modellering og design, ikke får den retmæssige indflydelse på senere faser, såsom udvikling af prototyper. Dette er et problem, hvis man følger vandfaldsmodellen, men ikke så meget hvis man følger spiralmodellen. I spiralmodellen vil konsekvenserne af modelleringen og designfasen slå igennem i den efterfølgende iteration, og selve problematikken bag ved det at udvikle model, design og prototyper simultant vil forsvinde. I M.A.D er det derfor en yderst brugbar metode, da de ikke benytter sig af vandfaldsmodellen, og den derfor kan være med til at øge effektiviteten gevaldigt. Den sidste metode er multiperspektiviteten bag deres udviklingsproces. De øvre instanser bag projektet M.A.D har fra begyndelsen af været klar over, at dette kunne få afgørende betydning, da de sammensatte holdet af udviklere. Udviklingsgruppen bestod både af folk med systemudviklingsuddannelser, samt folk med helt andre uddannelser, som kunne være til stor nytte i visse faser af projektet. Denne metode ses

25 20 LITTERATURLISTE ikke direkte i kursuslitteraturen, men vil dog altid være til stede i et projekt, omend ikke i lige så udtænkt grad som det er tilfældet i M.A.D, da medlemmer af en udviklingsgruppe altid vil have forskellige kvalifikationer med sig. Dog er det de klart definerede roller i M.A.D, som etnograf, samarbejdsdesigner og OO-folk, der udgør det multiperspektive indblik i de forskellige faser, som udviklingsgruppen nyder godt af. Litteraturliste [1] N. E. Andersen. Professionel Systemudvikling. Teknisk Forlag, [2] D. Barnes and Kölling M. Objects First with Java. Pearson Education International, 4 edition, [3] L. Bass, P. Clements, R. Kazman, and L. Northrop. Software Architecture in Practice, chapter What is Software Architecture?, pages Pearson Education Inc., 2 edition, [4] B. Boehm. A spiral model of software development and enhancement. IEEE Computer, 21:61 72, [5] F. P. Brooks. No silver bullet. Proc. of the IFIP Tenth World Computing Conference, edited by H.-J. Kugler (1986), pages , Reprinted version from the book Brooks, F. P. (1995), The mythical man-month: Essays on software engineering, Addison-Wesley Publishing. [6] Oracle Corporation. Mysql, jdbc connector. connector/j/, Juni [7] Forsidebillede. A map which shows the distribution of all the language families in the world. the_world-3.png, Februar [8] Gerry Gaffney. What is affinity diagramming? Usability Techniques series, [9] H. Garcia-Molina, J. D. Ullman, and J. Widom. Database Systems - The Complete Book. Pearson Education International, 2 edition, [10] Google. Google docs. juni [11] J. Highsmith. Extreme programming. ead (e-business application delivery), 12:1 16, Cutter Consortium, [12] ITMEDIA. juni [13] Leif Obel Jepsen, Lars Mathiassen, and Peter Axel Nielsen. Back to thinking mode: diaries for the management of information systems development projects. Behaviour and information technology, vol. 8, 1989.

26 LITTERATURLISTE 21 [14] L. Mathiassen, A. Munk-madsen, P. A. Nielsen, and J. Stage. Objektorienteret analyse & design. Forlaget Marko ApS, 3 edition, [15] P. Naur. Programming as theory building. Microprocessing and Microprogramming, 15: , Reprinted version from Naur, P. (1992), Computing: a Human Activity, ACM, pp [16] Open Source. Moodle. april [17] SUN. Sun s hjemmeside vedrørende internationalisering af javasystemer. http: //java.sun.com/javase/technologies/core/basic/intl/faq.jsp, april [18] J. Sutherland, C. R. Jakobsen, and K. Johnsons. Scrum and cmmi level 5: The magic potion for code warriors. Proceedings of the 41st Annual Hawaii International Conference on System Sciences (HICSS 08), IEEE Computer Society, page 9 pages, [19] Michael Christensen & Andy Crabtree & Christian Heide Damm & Klaus Marius Hansen & Ole Lehrmann Madsen & Pernille Marqvardsen & Preben Mogensen & Elmer Sandvad & Lennert Sloth & Michael Thomsen. The m.a.d. experience: Multiperspective application development in evolutionary prototyping. In Proceedings of the 12th European Conference on Object-Oriented Programming (ECCOP 98), Eric Jul (Ed.). Springer- Verlag, London, UK, 13-40, [20] Michael Vinther. Diagram designer. juni 2011.

27 22 A FØRSTE PROTOTYPE A Første prototype A.1 Valg af prototype I vores første prototype har vi valgt kun at inddrage 2 af vores 3 brugergrænseflader. Dette skyldes at alle væsentlige funktioner for at køre og bruge programmet er indeholdt i de to brugere: Lærer og elev. Vi vil satse på at få disse to grænseflader fuldt implementeret inden vi tænker på det sidste, for uden disse to kan programmet ikke fungere. Udover disse to har vi tænkt os at have et administrator-grænseflade. Administratorgrænsefladen er den mest avancerede af de 3 grænseflader i det, at det skal have fuld adgang til alle funktioner, og tilmed skal have et grafisk modelleringsværktøj til at administrere MySql databasen. Der vil herunder følge en række skærmbilleder fra vores første prototype, først fra en elevs synspunkt og herefter fra en lærers synspunkt. A.2 En elev og en lærers brugergrænseflade Figur 10: Ovenstående vindue repræsenterer vores brugergrænseflade, når en elev åbner det. Fra dette vindue har en elev via en træbaseret menu til venstre i billedet adgang til de forskellige mapper med øvelser. Eleven kan herfra klikke på en valgt øvelse og benytte Open Exercise -knappen til at åbne denne i hovedvinduet (vinduet til højre). Eleven har også mulighed for ændre lydniveauet for afspilning via slideren placeret nederst i højre hjørne af vinduet. Endvidere kan eleven vælge at få mappeoversigten til at forsvinde for at få bedre overblik over en øvelse ved at benytte knappen Hide Overlay.

28 A.2 En elev og en lærers brugergrænseflade 23 Figur 11: Dette vindue viser, at en elev har åbnet en øvelse. Øvelsen består i dette tilfælde af tekst og lyd med højtlæsning af teksten. Eleven kan via Record -knappen optage sit eget forsøg på højtlæsning, herefter bliver forsøget gemt i dropdown menuen Recorded Answers, og efter nogle forsøg, kan eleven vælge at aflevere den optagelse han/hun synes ønsker. Figur 12: I dette vindue kan eleven aflevere sin besvarelse, som han optog i forrige vindue. Han kan her høre alle sine besvarelse via dropdown menuen Recorded Answers, og kan aflevere den han synes bedst om ved at trykke på Submit Answer.

29 24 A FØRSTE PROTOTYPE Figur 13: Her kan en lærer oprette en ny øvelse ved at indsætte titel, tekst og lydfiler efter behov. Herefter kan læreren vælge om øvelsen skal være tilgængelig for alle via Public/Private, se et eksempel via Preview Exercise -knappen, og afslutte med Done -knappen. Figur 14: I dette kan læreren se sine aktuelle hold under menuen Classes, og via New Class -knappen kan læreren oprette et nyt hold. Ved at markere et bestemt hold kan læreren se eleverne, der er tilmeldt holdet. Herfra kan læreren tilføje eller fjerne elever via Remove From Class - og Add New Student(s) To Class -knapperne.

30 A.3 Navigeringsdiagrammer 25 Figur 15: For at komme til dette pop-up vindue ønsker en lærer at tilføje en eller flere elever til et hold via Super Teacher grænseflade - Classroom Overview -vinduet. I dette vindue kan en lærer søge på elever via enten ID er, holdtilmeldinger, navn eller andet ved at benytte søgefeltet øverst til venstre i pop-up vinduet. Læreren vil da få returneret en liste at elever i feltet til venstre under søgefeltet som han/hun kan markere. Ved at markere disse elever kan læreren tilføje disse elever til en liste ved at benytte Add -knappen og fjerne dem igen fra denne list ved at benytte Remove -knappen. Når læreren er tilfreds med sit valg af elever, kan han/hun enten trykke på Cancel -knappen for at annullere sit valg, eller trykke på Done -knappen for at tilføje de valgte elever til det aktuelle hold. A.3 Navigeringsdiagrammer Jeg vil her komme med nogle navigeringsdiagrammer for at vise, hvorledes de tidligere viste skærmbilleder hænger sammen. A.3.1 For en lærer Figur 16: Lærer navigeringsdiagram: En lærer kan fra sit Main Window gå to veje. Han kan ændre eller lave en øvelse og han kan gå ind i sit Classroom Overview. I sidstnævnt har læreren adgang til at se sine hold, samt ændrer hvilke elever der skal være i de forskellige hold.

31 26 A FØRSTE PROTOTYPE A.3.2 For en elev Figur 17: Elev navigeringsdiagram: En elev har via sit Main Window mulighed for at åbne en øvelse. Herfra kan eleven da vælge at aflevere en besvarelse på øvelsen og/eller lukke øvelsen, hvorpå eleven bliver returneret til sit Main Window. A.4 Evaluering og resultat af første prototype For at evaluere vores første prototype holdte vi d. 6/ et møde med ITMEDIA, hvor vi præsenterede vores papirprototype for dem. Dette gjorde vi ved at udskrive ovenstående prototypevinduer på A4 ark og herefter fremvise disse for vores kunde samtidig med, at vi forklarede hvordan vinduerne hang sammen. Grunden til at vi valgte netop denne metode til at evaluere vores første prototype, er at vi på denne måde får bekræftet, at vores prototype er på rette spor i forhold til hvad vores kunder ønsker. Endvidere kan vi ved denne metode også demonstrere, hvorledes vi har tænkt de meste basale funktionaliteter ind i vores program. Disse kan vores kunde så kommentere på, og på denne måde kan vi nemt komme uden om grundlæggende misforståelser, som senere kan blive til store problemer. De tog ude på ITMEDIA godt imod vores prototype kun med få indvendinger. Vi havde oprindeligt tænkt os at basere vores system på et allerede eksisterende databasesystem (Moodle), men kom efter en kort diskussion med ITMEDIA frem til, at vi hellere selv ville konstruere en MySQL database, som vores system kan benytte. De kom også med en enkelt indvending til selve designet af prototypen. De påpegede, at det var vigtigt under vores øvelsesvindue, at scrollbaren blev erstattet med to knapper, der kunne skifte frem og tilbage mellem de forskellige sider i en øvelse. Grunden til denne modifikation er, at en elev, som skal besvare en opgave med mange sider, let kommer til at miste overblikket over opgaven, hvis vedkommende skal scrolle sig vej igennem opgaven. Det er derfor en fordel at lave knapper i stedet, så eleven let kan skifte mellem de forskellige dele af opgaven og samtidig hele tiden have overblik over, hvor han/hun er i opgaven. A.5 Analyse og diskussion af evaluering Umiddelbart er det ikke nogen særlig kompliceret opgave at ændre måden, hvorpå en elev navigerer mellem de forskellige dele af en opgave. Dette kræver, at vi splitter øvelserne op i øvelseselementer i stedet for at have hele øvelsen samlet i et objekt. Dette vil vi gøre på den måde, at man i hvert øvelseselement kan have tekst og/eller lydelementer. Ved at binde disse øvelseselementer sammen, kan man på den måde danne

32 A.6 Konklusion af første prototype 27 en hel øvelse. Endvidere kan vi herudfra også let ordne en elevs besvarelse på en øvelse efter samme stil, da dette så blot vil inkludere at kæde en besvarelse i form af en lydfil til et specifikt øvelseselement i en øvelse. A.6 Konklusion af første prototype Alt i alt skal vi til vores næste prototype ændre på vores øvelsesklasse, så en øvelse nu indeholder ét eller flere øvelseselementer. Ud over dette skal vi også kæde disse elementer sammen, men dette kan jo passende ske i øvelsesklassen, da ethvert øvelseselement er forbundet til et objekt af øvelsesklassen. Endvidere skal vi også i vores fremtidige prototyper tænke på at designe vores database. Dette kræver en smule mere arbejde af os end tidligere, men sammenlignet med arbejdet i af sætte os ind i en allerede eksisterende database, er dette klart af foretrække. B Anden prototype Den anden prototype vi har valgt at lave, er en kørbar java-udgave af den første prototype. Vi har således baseret vores brugergrænseflader på de grænseflader vi nåede frem til under udviklingen af den første prototype. Samtidig har vi også videreudviklet vores system, med henblik på de kommentarer vi fik under evalueringen af den første prototype. Dette indebærer specielt muligheden for at bladre i en øvelse for at få vist forskellige øvelseselementer. Figur 18: Ovenstående vindue repræsenterer login skærmen, som er den første skærm brugeren får vist efter systemet bliver åbnet. Her kan en bruger vælge at køre programmet i offline mode, hvorpå han/hun ikke forbinder direkte til serveren. Brugeren kan også vælge at indtaste et forudbestemt brugernavn og en hertilhørende adgangskode og på denne måde logge ind i systemet.

33 28 B ANDEN PROTOTYPE Figur 19: Ovenstående vindue giver en kort velkomstmeddelelse, samt muligheden for at brugeren kan vælge (afhængigt af brugerens rettigheder) hvilke hovedvinduer han/hun vil åbne. Figur 20: Ovenstående vindue er brugergrænsefladen for en elev. I venstre side har eleven et overblik og sine klasser og øvelserne, der hører til de valgte klasser. Endvidere bliver eleven også mødt men en velkomstbesked i højre side, når han/hun åbner dette vindue op.

34 29 Figur 21: Ovenstående vindue repræsenterer, at en elev har åbnet en øvelse fra databasen til venstre i vinduet. Eleven kan nu vælge at afspille lydøvelsen med Play -knappen eller indspille sin egen lyd med Record -knappen. Til sidst kan eleven vælge at bladre mellem øvelsens sider ved at benytte Next - og Previous -knapperne i bunden af skærmen. Figur 22: Ovenstående vindue repræsenterer, at en elev har optaget tre forsøg på en øvelse. Eleven kan nu se de tidligere optagede forsøg, og afspille dem enkeltvis ved at vælge dem fra dropdown menuen.

35 30 B ANDEN PROTOTYPE Figur 23: Ovenstående vindue repræsenterer, at en elev har en øvelse åben og derefter trykker på knappen Hide overview. Herved skjules oversigten, og gives mere plads til selve opgaven. Oversigten kan åbnes igen ved at trykke på Open overview. Figur 24: Dette vindue samt næste vindue figur 25 demonstrerer, hvorledes Change - knappen fungerer. Knappen fungerer ved at ændre oversigten fra at indholde mapper med øvelser til at indeholde mapper med elever og lærere. Det kan nu ses hvilke opgaver en elev har lavet, og hvilke klasser denne elev er tilmeldt.

36 B.1 Navigeringsdiagram 31 Figur 25: Her har brugeren trykket på Change -knappen og får nu vist en oversigt over elever og lærere. B.1 Navigeringsdiagram Figur 26: Navigeringsdiagram for anden prototype. I denne iteration af vores system, har vi ikke nået at dække alle disse funktioner, som vores papirprototype viste. Hvis vi havde, ville dette diagram ligne dem ovenfor. I forhold til ovenfor er dette diagram altså mangelfuldt, dog er vinduerne login window og user interface chooser tilføjet. B.2 Evaluering af anden prototype For at evaluere vores anden prototype, aftalte vi et møde med Christian Jensen fra Center for Internationalisering og Parallelsproglighed ved Københavns Universitet. Til dette møde præsenterede vi kort Christian for tænke-højt metoden, hvorefter vi med Christian som testperson benyttede denne metode til at teste vores system. Grunden til at vi valgte netop denne metode er, udover at vi har erfaring med den fra øvelsestimerne, at metoden giver et godt indblik i hvorledes en bruger ofte vil benytte et program af vores type.

Objektorienteret Analyse & Design

Objektorienteret Analyse & Design Objektorienteret Analyse & Design Lars Mathiassen, Andreas Munk-Madsen, Peter Axel Nielsen og Jan Stage ISBN: 87-7751-153-0 Udgave: 3. udgave Udgivelsesår: 2001 Antal sider: 452 Pris: Kr. 410,00 På de

Læs mere

1 Ordliste 2. 2 Indledning 3 2.1 Problemstillinger... 3 2.2 Problemformulering... 4 2.3 Problemafgrænsning... 4 2.4 Mål med projektet...

1 Ordliste 2. 2 Indledning 3 2.1 Problemstillinger... 3 2.2 Problemformulering... 4 2.3 Problemafgrænsning... 4 2.4 Mål med projektet... Indhold 1 Ordliste 2 2 Indledning 3 2.1 Problemstillinger.................................. 3 2.2 Problemformulering................................ 4 2.3 Problemafgrænsning................................

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

Om forretningsmæssige kompetencer

Om forretningsmæssige kompetencer Om forretningsmæssige kompetencer Uddanner universiteterne kun i det de forsker i? DI, Industriens Hus - 22. september 2009 Jørn Johansen JoJ@delta.dk www.deltaaxiom.com www.delta.dk Tlf.: 72194421 1 Delta

Læs mere

Bilag 2. Studieforløbsbeskrivelsen: Det faglige indhold I projektet

Bilag 2. Studieforløbsbeskrivelsen: Det faglige indhold I projektet Bilag 2 Studieforløbsbeskrivelsen: Det faglige indhold I projektet I de følgende spørgsmål skal I som gruppe reflektere over, hvad I har gjort for at indfri de faglige krav til projektet. Hvordan har husets

Læs mere

Svendeprøve Projekt Tyveri alarm

Svendeprøve Projekt Tyveri alarm Svendeprøve Projekt Tyveri alarm Påbegyndt.: 8/2-1999 Afleveret.: 4/3-1999 Projektet er lavet af.: Kasper Kirkeby Brian Andersen Thomas Bojer Nielsen Søren Vang Jørgensen Indholds fortegnelse 1. INDLEDNING...3

Læs mere

Indhold. 1 Indledning... 3. 1.1 Kompatible browsere... 3. 2 Log ind i Umbraco... 3. 3 Content-delen... 4. 3.1 Indholdstræet... 4

Indhold. 1 Indledning... 3. 1.1 Kompatible browsere... 3. 2 Log ind i Umbraco... 3. 3 Content-delen... 4. 3.1 Indholdstræet... 4 Indhold 1 Indledning... 3 1.1 Kompatible browsere... 3 2 Log ind i Umbraco... 3 3 Content-delen... 4 3.1 Indholdstræet... 4 3.2 Ændring af indhold... 5 3.3 Tilføjelse af en side/sektion... 6 3.4. At arbejde

Læs mere

Miniprojekt2011. Formålet er at lære og indlære god objektorienteret programudvikling og programmering med Java, samt undervejs at opfylde studiekrav.

Miniprojekt2011. Formålet er at lære og indlære god objektorienteret programudvikling og programmering med Java, samt undervejs at opfylde studiekrav. Miniprojekt2011 Projektbeskrivelse Der skal fremstilles en lille java application på PC, hvor brugeren kan foretage interaktioner med en simpel database på disken via et grafisk brugerinterface. Formålet

Læs mere

Indholdsfortegnelse Valg af opgave... 2 Introduktion... 2 Problem... 2 Målgruppe... 2 Afsender... 2 Budskab... 2 Kodning... 3 Effekt...

Indholdsfortegnelse Valg af opgave... 2 Introduktion... 2 Problem... 2 Målgruppe... 2 Afsender... 2 Budskab... 2 Kodning... 3 Effekt... Indholdsfortegnelse Valg af opgave... 2 Introduktion... 2 Problem... 2 Målgruppe... 2 Afsender... 2 Budskab... 2 Kodning... 3 Effekt... 3 Information... 3 Programmering... 3 Design... 4 Brochure... 4 Hjemmeside...

Læs mere

Roskilde Tekniske Gymnasium. Eksamensprojekt. Programmering C niveau

Roskilde Tekniske Gymnasium. Eksamensprojekt. Programmering C niveau Roskilde Tekniske Gymnasium Eksamensprojekt Programmering C niveau Andreas Sode 09-05-2014 Indhold Eksamensprojekt Programmering C niveau... 2 Forord... 2 Indledning... 2 Problemformulering... 2 Krav til

Læs mere

Hassansalem.dk/delpin User: admin Pass: admin INTERFACE DESIGN

Hassansalem.dk/delpin User: admin Pass: admin INTERFACE DESIGN Hassansalem.dk/delpin User: admin Pass: admin INTERFACE DESIGN 1/20 Indledning Dette projekt er den afsluttende del af webudvikling-studiet på Erhvervs Lillebælt 1. semester. Projektet er udarbejdet med

Læs mere

Dynamicweb Quickguide

Dynamicweb Quickguide Brugervejledning Dynamicweb Quickguide Version: 1.1 2012.03.15 Dansk JURIDISK MEDDELELSE Copyright 2012 Dynamicweb Software A/S. Alle rettigheder forbeholdes. Dette dokument eller dele heraf må på ingen

Læs mere

Web 2.0. Af Frederik Adamsen. Definitionen af Web 2.0... 2 Problemstilling og løsning... 2 Udvikling af produkt... 3 Tankegang... 4 Konklusion...

Web 2.0. Af Frederik Adamsen. Definitionen af Web 2.0... 2 Problemstilling og løsning... 2 Udvikling af produkt... 3 Tankegang... 4 Konklusion... Web 2.0 Af Frederik Adamsen Indholdsfortegnelse Definitionen af Web 2.0... 2 Problemstilling og løsning... 2 Udvikling af produkt... 3 Tankegang... 4 Konklusion... 6 Frederik Adamsen Kom/IT Web 2.0 Side

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

Umbraco installationsvejledning

Umbraco installationsvejledning på et ScanNet ASP Webhotel Indledning Beskrivelse Denne vejledning vil indeholde installation af CMS systemet Umbraco på et ASP Webhotel. Det dansk grundlagt Content Management System (CMS) Umbraco er

Læs mere

INTERAKTIONSDESIGN PROCESSEN (KAP 9), REPETITION, KÅRING AF ÅRETS BEDSTE MUSIKVIDEO OG PROJETK

INTERAKTIONSDESIGN PROCESSEN (KAP 9), REPETITION, KÅRING AF ÅRETS BEDSTE MUSIKVIDEO OG PROJETK INTERAKTIONSDESIGN PROCESSEN (KAP 9), REPETITION, KÅRING AF ÅRETS BEDSTE MUSIKVIDEO OG PROJETK Marianne Graves Petersen Associate Professor Computer Science Dept, University of Aarhus Center for Interactive

Læs mere

PHP kode til hjemmeside menu.

PHP kode til hjemmeside menu. PHP kode til hjemmeside menu. Home Hovedmenu 1 Hovedmenu 2 Hovedmenu 3 Hovedmenu 4 Undermenu 1 Breadcrumb Her vises indholdet af den valgte side Undermenu 2 Undermenu 3 Undermenu 4 Evt. en mulighed for

Læs mere

Programmering C Eksamensprojekt. Lavet af Suayb Köse & Nikolaj Egholk Jakobsen

Programmering C Eksamensprojekt. Lavet af Suayb Köse & Nikolaj Egholk Jakobsen Programmering C Eksamensprojekt Lavet af Suayb Köse & Nikolaj Egholk Jakobsen Indledning Analyse Læring er en svær størrelse. Der er hele tiden fokus fra politikerne på, hvordan de danske skoleelever kan

Læs mere

INDHOLDSFORTEGNELSE. INDLEDNING... 7 Kristian Langborg-Hansen. KAPITEL ET... 9 I gang med App Inventor. KAPITEL TO...

INDHOLDSFORTEGNELSE. INDLEDNING... 7 Kristian Langborg-Hansen. KAPITEL ET... 9 I gang med App Inventor. KAPITEL TO... INDHOLDSFORTEGNELSE INDLEDNING... 7 Kristian Langborg-Hansen KAPITEL ET... 9 I gang med App Inventor Installation af App Inventor... 10 Trådløs installation... 11 Installation af emulator (Windows)...

Læs mere

Supermarkedsmodellen for design af brugergrænseflade

Supermarkedsmodellen for design af brugergrænseflade Supermarkedsmodellen for design af brugergrænseflade Denne note er skrevet frit efter Peter Huber, som på et kursus i Efteruddannelsescenteret fortalte om supermarkedsmodellen til design af brugergrænseflader.

Læs mere

Studieordning del 4-2014

Studieordning del 4-2014 Studieordning del 4-2014 Fagbeskrivelser Datamatiker AP Graduate in Computer Science Version 1.1 Revideret august 2014 Side 0 af 8 Indhold del 4 Fagbeskrivelser 1. Faget Programmering (PRO)...2 2. Faget

Læs mere

Installation af MySQL server på PC

Installation af MySQL server på PC Installation af MySQL server på PC (Udgave 0.02 2013-Oktober-06 @ 22:30 Chris Bagge, Mindre rettelser) Dette er en kort beskrivelse af hvordan man får installeret en MySQL server på en PC med Windows 7.

Læs mere

Database for udviklere. Jan Lund Madsen PBS10107

Database for udviklere. Jan Lund Madsen PBS10107 Database for udviklere Jan Lund Madsen PBS10107 Indhold LINQ... 3 LINQ to SQL og Arkitektur... 3 O/R designere... 5 LINQ Den store introduktion med.net 3.5 er uden tvivl LINQ(udtales link): Language-INtegrated

Læs mere

BAAN IVc. Brugervejledning til BAAN Data Navigator

BAAN IVc. Brugervejledning til BAAN Data Navigator BAAN IVc Brugervejledning til BAAN Data Navigator En udgivelse af: Baan Development B.V. P.O.Box 143 3770 AC Barneveld Holland Trykt i Holland Baan Development B.V. 1997. Alle rettigheder forbeholdes.

Læs mere

DIKUs Undervisningsudvalg. Vedr.: 41. møde den 1. november 2012. Sagsbehandler: Lisa Ibenfeldt Schultz

DIKUs Undervisningsudvalg. Vedr.: 41. møde den 1. november 2012. Sagsbehandler: Lisa Ibenfeldt Schultz D A T A L O G I S K I N S T I T U T K Ø B E N H A V N S U N I V E R S I T ET DIKUs Undervisningsudvalg R E F E R A T 28. NOVEMBER 2012 Vedr.: 41. møde den 1. november 2012 DATALOGISK INSTITUT Sagsbehandler:

Læs mere

VELKOMMEN 3. KOM GODT I GANG 4 Log ind 5 Kontrolpanel 6 Tilpas profil 7 Tilknyt hold 8 Tilknyt fag 9

VELKOMMEN 3. KOM GODT I GANG 4 Log ind 5 Kontrolpanel 6 Tilpas profil 7 Tilknyt hold 8 Tilknyt fag 9 VEJLEDNING 1.0 Indhold VELKOMMEN 3 KOM GODT I GANG 4 Log ind 5 Kontrolpanel 6 Tilpas profil 7 Tilknyt hold 8 Tilknyt fag 9 SÅDAN OPRETTER DU EN QUIZ 10 Quiz info 11 Tilføj spørgsmål 12 Tilføj formel til

Læs mere

Dagens program. Domæner. change log- screen shots hver gang I har arbejdet med themet. Arkitekturen bag en wp blog. Hvad er widgets.

Dagens program. Domæner. change log- screen shots hver gang I har arbejdet med themet. Arkitekturen bag en wp blog. Hvad er widgets. Dagens program Har alle fået? Har nogen betalt for meget? Hav jeres koder klar Domæner change log- screen shots hver gang I har arbejdet med themet. Arkitekturen bag en wp blog Hvad er widgets Hvad er

Læs mere

Martin Geisler. Uge 49, 2001

Martin Geisler. Uge 49, 2001 Min dintprog-browser Martin Geisler Uge 49, 2001 Resumé Dette dokument beskriver tankerne bag min dintprog-browser, en browser skrevet i Java der skal kunne fortolke en mindre delmængde af HTML 4, kaldet

Læs mere

From Human Factors to Human Actors - The Role of Psychology and Human-Computer Interaction Studies in System Design

From Human Factors to Human Actors - The Role of Psychology and Human-Computer Interaction Studies in System Design ? VAD From Human Factors to Human Actors - The Role of Psychology and Human-Computer Interaction Studies in System Design? VEM Skrevet af Liam J. Bannon Director of the IDC and Professor of Computer Science,

Læs mere

BackEnd Programmering PHP

BackEnd Programmering PHP 17708 08/ 02/ 2013 BackEnd Programmering PHP Prototype (CMS system) 371615m02dka.sub.ots.dk/historyspot eller linket CMS system på: qrguide.mmd.eal.dk Login CMS Username: admin Password: 1234 Source kode

Læs mere

Indhold. Evalueringsvejledning. En undersøgelse fra start til slut involverer 4 programmer: - SurveyXact - Excel - E-learn - SiteCore

Indhold. Evalueringsvejledning. En undersøgelse fra start til slut involverer 4 programmer: - SurveyXact - Excel - E-learn - SiteCore Evalueringsvejledning En undersøgelse fra start til slut involverer 4 programmer: - SurveyXact - Excel - E-learn - SiteCore Indhold 1 - Respondentgruppe hentes... 2 2 Undersøgelsen oprettes i SX... 4 3.

Læs mere

ipad for let øvede, modul 10 ipad og Computer

ipad for let øvede, modul 10 ipad og Computer 17112014AS ipad for let øvede modul 10 ipad og computer Indledning I dette modul gennemgås nogle af de muligheder, der er for samspil mellem computeren og ipad'en. På ipad'en findes app'en itunes Store.

Læs mere

SmartFraming Et vindue til nationale sundhedssystemer. Version 3.0

SmartFraming Et vindue til nationale sundhedssystemer. Version 3.0 SmartFraming Et vindue til nationale sundhedssystemer Version 3.0 Infrastruktur i dagens sundheds IT Det sundhedsfaglige personale benytter sig i dag af en række forskellige systemer i forbindelse med

Læs mere

Lavet af Danni jensen og David Olsen

Lavet af Danni jensen og David Olsen Projekt Delfin Lavet af Danni jensen og David Olsen 19/5-2008 Indholdsfortegnelse. Side 1: Indholdsfortegnelse og forord. Side 2: Kravsliste. Side 3: Use Case Model. Side 4: Formandens aktørbeskrivelse

Læs mere

1.8.2 Overblik over releasens

1.8.2 Overblik over releasens 1.8.2 Overblik over releasens Marts 2013 Releasedato 21. marts 2013, mellem kl. 7:00 og 10:00 GMT Indholdsfortegnelse Forbedringer... 3 Find Us - bekræft beliggenhed på kort... 3 LinkedIn føjet til muligheder

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

Databasesystemer, forår 2005 IT Universitetet i København. Forelæsning 3: E-R modellering. 17. februar 2005. Forelæser: Rasmus Pagh

Databasesystemer, forår 2005 IT Universitetet i København. Forelæsning 3: E-R modellering. 17. februar 2005. Forelæser: Rasmus Pagh Databasesystemer, forår 2005 IT Universitetet i København Forelæsning 3: E-R modellering 17. februar 2005 Forelæser: Rasmus Pagh Forelæsningen i dag Datamodellering hvad, hvornår, hvorfor og hvordan? Business

Læs mere

Responsivt Design - DMAA0213. Afgangsprojekt DMAA0213

Responsivt Design - DMAA0213. Afgangsprojekt DMAA0213 Responsivt Design - DMAA0213 Afgangsprojekt DMAA0213 Jesper Bjørn Andersen 18-06-2015 5. semester, afgangsprojekt - Responsivt Design Vejleder: Gunhild Marie Andersen Afsluttet: 18 Juni 2015 Deltager:

Læs mere

Streame fra Winamp til Dreambox/pc på netværk.

Streame fra Winamp til Dreambox/pc på netværk. Streame fra Winamp til Dreambox/pc på netværk. 1. Formål 2. Forudsætninger og installationer 3. Opsætning 4. Start streaming 5. Aflyt streaming 6. Kontakt 1. Formål Mange benytter Winamp ( Nullsoft, Inc.)

Læs mere

Side 1. Databaser og SQL. Dagens gang. Databasebegreber. Introduktion til SQL Kap 1-5

Side 1. Databaser og SQL. Dagens gang. Databasebegreber. Introduktion til SQL Kap 1-5 Databaser og SQL Introduktion til SQL Kap 1-5 1 Dagens gang Databaser Database begreber Mapning af klasser til relationel model Normalisering Opgaver til næste gang 2 Databasebegreber A database is a:

Læs mere

GUIDE TIL CLOUD DRIVE

GUIDE TIL CLOUD DRIVE GUIDE TIL CLOUD DRIVE Dette er en guide du kan anvende til nemt at komme effektivt i gang med at anvende Cloud Drive Indholdsfortegnelse 1. Tilgængelige Cloud Drive klienter 2. Guide til Windows klienten

Læs mere

J2ME portabilitet. J2ME portabilitet. Afgangsprojekt på IT-Diplomuddannelsen ved Center for Videreuddannelse på Ingeniørhøjskolen i København

J2ME portabilitet. J2ME portabilitet. Afgangsprojekt på IT-Diplomuddannelsen ved Center for Videreuddannelse på Ingeniørhøjskolen i København J2ME portabilitet Afgangsprojekt på IT-Diplomuddannelsen ved Ingeniørhøjskolen i København Eksamen: 10-06-2005 kl. 10:30 Studerende: Kenn A. Thisted (K4297) Vejleder: Birger Andersen J2ME portabilitet

Læs mere

Repræsentationer af handlinger og sproghandlinger

Repræsentationer af handlinger og sproghandlinger Repræsentationer af handlinger og sproghandlinger Generelt: I denne opgave omhandler pensum generelt koblingen mellem IT-systemer, som et medium hvorved brugerne af disse systemer udfører sproghandlinger.

Læs mere

Grundlæggende OOA - OOD

Grundlæggende OOA - OOD Grundlæggende OOA - OOD Dette kursus henvender sig til personer, der har lille eller ingen erfaring med softwareudvikling. Med udgangspunkt i UML opbygges et solidt kendskab til softwareudviklingens kunst

Læs mere

Dm071 / Dm072 - Obligatorisk projekt 3: Design af model

Dm071 / Dm072 - Obligatorisk projekt 3: Design af model Dm071 / Dm072 - Obligatorisk projekt 3: Design af model Fag: Projektet omhandler emner fra fagene Software Design og Software Konstruktion. Formål: Formålet med projektet er at give dig mulighed for sammen

Læs mere

Typo3 vejledning BMI af 1 Typo3 vejledning for redaktører og skribenter i BMI

Typo3 vejledning BMI af 1 Typo3 vejledning for redaktører og skribenter i BMI af 1 side 1 Typo3 vejledning for redaktører og skribenter i BMI GENERELT...3 LOGIN...3 STARTSIDEN...4 SIDE...5 SIDE ELEMENTER...6 SIDE LAYOUT...7 STJÆL MED ARME OG BEN HEL SIDE...8 STJÆL MED ARME OG BEN

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

Vejledning til Mozart Viewer 12

Vejledning til Mozart Viewer 12 Vejledning til Mozart Viewer 12 Programmet kan downloades gratis på http://www.mozart.co.uk Husk at det er den der hedder Mozart Viewer du skal hente. Den er gratis, i modsætning til Mozart som koster

Læs mere

Hvorfor E-business løsninger ofte ikke lever op til forventningerne og hvordan man kan undgå det

Hvorfor E-business løsninger ofte ikke lever op til forventningerne og hvordan man kan undgå det ARTIKEL De svageste led Hvorfor E-business løsninger ofte ikke lever op til forventningerne og hvordan man kan undgå det Dato: 24 aug 2000 Ver.: Draft Rev.: 11 Forfatter: Anders Munck I den seneste tids

Læs mere

Skriftlig opgave. Designtanker i database-nære systemer

Skriftlig opgave. Designtanker i database-nære systemer Skriftlig opgave til eksamen for faget»databaser«designtanker i database-nære systemer Martin Ancher Holm Juni 2010 1 Intro Denne skriftlige opgave indeholder kort de daglige tanker jeg har omkring design

Læs mere

Hos Lasse Ahm Consult vurderer vi at følgende supplerende krav i de enkelte kravelementer er væsentlige at bemærke:

Hos Lasse Ahm Consult vurderer vi at følgende supplerende krav i de enkelte kravelementer er væsentlige at bemærke: ISO 9001:2015 (Draft) Side 1 af 9 Så ligger udkastet klar til den kommende version af ISO 9001. Der er sket en række strukturelle ændringer i form af standardens opbygning ligesom kravene er blevet yderligere

Læs mere

Indstillinger. 1. Built-in viewer 2. Built-in viewer embedded 3. Ekstern viewer

Indstillinger. 1. Built-in viewer 2. Built-in viewer embedded 3. Ekstern viewer TeXMaker guide TeXMaker er den editor, som vi anbefaler til at skrive LaTeX i. Det er en såkaldt cross-platform editor og kan benyttes til både Windows, Mac og Linux. TeXMaker er en ret almindelig editor

Læs mere

Tidsregistrering. Jacob E., Jacob H., Mathias, Mads H., Jonatan og Dan 3.4. Informationsteknologi B. Roskilde Tekniske Gymnasium 25-11-2014

Tidsregistrering. Jacob E., Jacob H., Mathias, Mads H., Jonatan og Dan 3.4. Informationsteknologi B. Roskilde Tekniske Gymnasium 25-11-2014 2014 Tidsregistrering Jacob E., Jacob H., Mathias, Mads H., Jonatan og Dan 3.4 Informationsteknologi B Roskilde Tekniske Gymnasium 25-11-2014 Indholdsfortegnelse 1 Indledning... 3 2 User stories... 3 3

Læs mere

Informationsteknologi B Forsøgslæreplan, december 2010

Informationsteknologi B Forsøgslæreplan, december 2010 Informationsteknologi B Forsøgslæreplan, december 2010 1.1 Identitet Informationsteknologi bygger på abstraktion og logisk tænkning. Faget beskæftiger sig med itudvikling i et samspil mellem model/teori

Læs mere

Studieordning del 4-2014

Studieordning del 4-2014 Studieordning del 4-2014 Fagbeskrivelser Datamatiker AP Graduate in Computer Science Version 1.2 Revideret januar 2015 Side 0 af 10 Indhold del 4 Fagbeskrivelser 1. Faget Programmering (PRO)...2 2. Faget

Læs mere

Opgavestyring, op og download af mange filer

Opgavestyring, op og download af mange filer 1 Opgavestyring, op og download af mange filer Det er muligt at downloade alle besvarelser i en arbejdsgang til din PC, hvorefter der kan rettes og kommenteres på besvarelserne, til sidst kan alle de kommenterede

Læs mere

IsenTekst Indhold til Internettet. Manual til Wordpress.

IsenTekst Indhold til Internettet. Manual til Wordpress. Manual til Wordpress Sådan opdaterer du din hjemmeside i Wordpress. Dette er en manual til de mest grundlæggende ting, så du selv kan redigere indholdet eller tilføje nyt på din hjemmeside. Guiden er skrevet

Læs mere

Rejsekort A/S idekonkurence Glemt check ud

Rejsekort A/S idekonkurence Glemt check ud Rejsekort A/S idekonkurence Glemt check ud 9. marts 2015 1 Indhold 1 Introduktion 4 1.1 Problembeskrivelse........................ 4 1.2 Rapportens opbygning...................... 4 2 Ordliste 5 3 Løsning

Læs mere

Indholdsfortegnelse. Hvorfor skal jeg tage backup af min blog? Side 3. Tag backup med UpDraft Side 4. Tag manuelt backup Side 8 - 2 -

Indholdsfortegnelse. Hvorfor skal jeg tage backup af min blog? Side 3. Tag backup med UpDraft Side 4. Tag manuelt backup Side 8 - 2 - - 1 - Indholdsfortegnelse Hvorfor skal jeg tage backup af min blog? Side 3 Tag backup med UpDraft Side 4 Tag manuelt backup Side 8-2 - Hvorfor skal jeg tage backup af min blog? Lige meget om du har opbygget

Læs mere

II. Beskrivelse af kandidatuddannelsens discipliner

II. Beskrivelse af kandidatuddannelsens discipliner II. Beskrivelse af kandidatuddannelsens discipliner Særfag 18. Agenter, handlinger og normer (Agents, actions and norms) a. Undervisningens omfang: 4 ugentlige timer i 2. semester. Efter gennemførelsen

Læs mere

INSTALLATIONSVEJLEDNING

INSTALLATIONSVEJLEDNING INSTALLATIONSVEJLEDNING Bemærk! At under installeringen, vil der, hvis du benytter Norton Antivirus, komme en meddelelse om en script-virus. Hertil skal du blot accepterer denne meddelelse, for at kunne

Læs mere

Det Naturvidenskabelige Fakultet. Introduktion til Blackboard (Øvelser) Naturvidenskabeligt Projekt 2006 Prøv at forske

Det Naturvidenskabelige Fakultet. Introduktion til Blackboard (Øvelser) Naturvidenskabeligt Projekt 2006 Prøv at forske Det Naturvidenskabelige Fakultet Introduktion til Blackboard (Øvelser) Naturvidenskabeligt Projekt 2006 Prøv at forske Indholdsfortegnelse Introduktion til Blackboard Content System...3 Øvelse 01 individuel:

Læs mere

Konsulent resume. Referencer Svend Holm Henriksen IT-udviklingschef Region Syddanmark +45/76631169 svend.holm.henriksen@regionsyddanmark.

Konsulent resume. Referencer Svend Holm Henriksen IT-udviklingschef Region Syddanmark +45/76631169 svend.holm.henriksen@regionsyddanmark. Konsulent resume Navn: Adresse: Kemal Pajevic Klingstrupvænget 105, 2-tv 5230 Odense M Telefon: 29726221 / 63130411 Email: kemal@pajevic.dk Født: 31.07.1982 Civilstand: Gift Jeg er en meget åben og udadvendt

Læs mere

15. oktober. Maskine Udlejning. Jacob Weng, Jeppe Boese og Mads Anthony. Udlejningsvirksomhed. Roskilde Tekniske Gymnasium 3.4

15. oktober. Maskine Udlejning. Jacob Weng, Jeppe Boese og Mads Anthony. Udlejningsvirksomhed. Roskilde Tekniske Gymnasium 3.4 Maskine Udlejning 15. oktober 2010 Jacob Weng, Jeppe Boese og Mads Anthony Roskilde Tekniske Gymnasium Udlejningsvirksomhed 3.4 Indholdsfortegnelse Problemformulering:... 2 Planlægning:... 2 Analyse af

Læs mere

educasoft - en professionel samarbejdspartner med speciale i uddannelse!

educasoft - en professionel samarbejdspartner med speciale i uddannelse! Velkommen til educasoft's hjemmeside educasoft - en professionel samarbejdspartner med speciale i uddannelse! Professionelle undervisere Undervisning i virksomheden Undervisning dag/aften eller week-end

Læs mere

ROSKILDE TEKNISKE GYMNASIUM. Læringsprogram. Lommeregner

ROSKILDE TEKNISKE GYMNASIUM. Læringsprogram. Lommeregner ROSKILDE TEKNISKE GYMNASIUM Læringsprogram Lommeregner Programmering Malte Fibiger, Rasmus Ketelsen, Nicojal Jensen og Leon Bøgelund, Klasse 3.36 04-12-2012 Indholdsfortegnelse Indledende afsnit... 3 Problemformulering...

Læs mere

Velkomstmappe ectrl. Deloitte Birkerød Kongevej 25C 3460 Birkerød Telefon 45 94 50 00

Velkomstmappe ectrl. Deloitte Birkerød Kongevej 25C 3460 Birkerød Telefon 45 94 50 00 Velkomstmappe ectrl Deloitte Birkerød Kongevej 25C 3460 Birkerød Telefon 45 94 50 00 Indholdsfortegnelse HVAD ER ECTRL?... 3 SUPPORT... 3 INSTALLATIONSVEJLEDNING TIL ECTRL... 4 OPRETTELSE OG ADMINISTRATION

Læs mere

Object-Relational Mapping

Object-Relational Mapping Databaser for udviklere () Datamatiker TietgenSkolen Underviser: Allan Helboe 06-06-2010 Problemformulering Denne opgave er et forsøg på at beskrive problemerne der opstår ved anvendelsen af en relationel

Læs mere

Internet Information Services (IIS)

Internet Information Services (IIS) Internet Information Services (IIS) Casper Simonsen & Yulia Sadovskaya H1we080113 06-11-2013 Indholdsfortegnelse Problemformulering... 2 Hvorfor:... 2 Hvad:... 2 Hvordan:... 2 Problembehandling... 3 Introduktion...

Læs mere

Lilleby Kommunebibliotek

Lilleby Kommunebibliotek Lilleby Kommunebibliotek Første projekt i Systemudvikling Arne Jørgensen, Christian Skovgaard, Lotte Simonsen og Sonny Petersen 3. november 2003 Indledning... Problemformulering... Problemanalyse... Projektafgrænsning...

Læs mere

Hvordan udarbejdes en strategi

Hvordan udarbejdes en strategi LENNART SVENSTRUP Hvordan udarbejdes en strategi LENNART@KYOEVAENGET.DK 2011 Strategi Alle kan udarbejde en strategi! MEN: For at en strategi er noget værd i praksis, skal den tage udgangspunkt i virkeligheden,

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

Sådan redigerer du en hjemmeside i Umbraco

Sådan redigerer du en hjemmeside i Umbraco Brugermanual til din boligafdelings hjemmeside Sådan redigerer du en hjemmeside i Umbraco Indhold Introduktion... 2 Log på Umbraco og redigér din hjemmeside... 3 Opret ny side... 7 Gem side uden at udgive/publicere

Læs mere

Quick Guide V8.0 - 1 -

Quick Guide V8.0 - 1 - Quick Guide V8.0-1 - Indholdsfortegnelse Generel information...3 Liveview...4 Optagelse af Videosekvenser...5 Afspilning af Videosekvenser...6 Menupanelet...7 Backup...11 Webcam...16 Trouble Shooting...21

Læs mere

LW313 Sweex Wireless 300N Adapter USB

LW313 Sweex Wireless 300N Adapter USB LW313 Sweex Wireless 300N Adapter USB Bemærk venligst! Udsæt ikke Sweex Wireless 300N Adapter USB for ekstreme temperaturer. Placér ikke adapteren i direkte sollys eller i nærheden af radiatorer eller

Læs mere

Brugersiderne for renteberegninger. Indhold. 1. Indledning. Anvendelse af. (Version 28. september 2014)

Brugersiderne for renteberegninger. Indhold. 1. Indledning. Anvendelse af. (Version 28. september 2014) Anvendelse af Brugersiderne for renteberegninger. (Version 28. september 2014) Indhold Brugersiderne for renteberegninger.... 1 1. Indledning... 1 2. Forudsætninger... 4 3. Indtastning af udbetaling/skyldigt

Læs mere

Trimble Access Service (Sync)

Trimble Access Service (Sync) Vejledning i opsætning af Trimble AccessSync Trimble har ved Dimensions November 2012 ændret deres forretningsmodel med hensyn til deres AccessSync funktionalitet. Tidligere har det krævet et særskilt

Læs mere

Installation af Oracle 10g Release 2 database

Installation af Oracle 10g Release 2 database Installation af Oracle 10g Release 2 database Oracle 10g database indeholder databasesoftware, enterprise manager, SQL*Plus m.m., HTML DB (i dag kendt som Application Express) og tilhørende HTTP Server

Læs mere

Rapport. Udarbejdet af: Mayianne Nøks Pedersen. Skole login: knmape68. E-mail: mypedersen@gmail.com

Rapport. Udarbejdet af: Mayianne Nøks Pedersen. Skole login: knmape68. E-mail: mypedersen@gmail.com Rapport Udarbejdet af: Mayianne Nøks Pedersen Skole login: knmape68 E-mail: mypedersen@gmail.com URL til brugerundersøgelsen: http://web328.webkn.dk/hjemmeside/image/laering/sem2brugerundersogelse/brugerundersogelse/

Læs mere

Manual til Groupcare: Indhold, formål og brug

Manual til Groupcare: Indhold, formål og brug Manual til Groupcare: Indhold, formål og brug Indledning Groupcare er en elektronisk, internetbaseret kommunikationsform som vi bruger i forbindelse med din DOL-uddannelse. Grundlæggende set er Groupcare

Læs mere

Kom godt i gang med internettet

Kom godt i gang med internettet Kom godt i gang med internettet Hver udgave af Kom godt i gang med internettet introducerer til et nyttigt eller interessant sted på internettet eller en lidt mere avanceret funktionalitet på dukapc en.

Læs mere

SmartWeb Brugermanual

SmartWeb Brugermanual SmartWeb Brugermanual Table of Content Table of Content... 1 Best Practice SmartWeb:... 2 Implementering... 4 Egenskaber:... 5 Filer:... 7 Oprettelse af Kategori... 9 Sider og Tekster:... 11 Slideshow...

Læs mere

Brugermanual til MOBI:DO Make på Internettet

Brugermanual til MOBI:DO Make på Internettet Brugermanual til MOBI:DO Make på Internettet Introduktion Med MOBI:DO Make kan du oprette guides, som kan ses i MOBI:DO. En guide virker som en checkliste, der fører brugeren hele vejen igennem en arbejdsopgave.

Læs mere

Et krav til portfolien var at det skulle udvikles fra bunden uden brug af CSS-frameworks, samt HTML og CSS skulle valideres uden fejl.

Et krav til portfolien var at det skulle udvikles fra bunden uden brug af CSS-frameworks, samt HTML og CSS skulle valideres uden fejl. Indledning Mit sidste projekt her på 1.semester gik ud på at jeg skulle lave et redesign af mit første portfolio, som jeg lavede i starten af semesteret. Formålet var at vise hvad jeg havde lært siden

Læs mere

Undervisningsbeskrivelse

Undervisningsbeskrivelse Undervisningsbeskrivelse Stamoplysninger til brug ved prøver til gymnasiale uddannelser Termin Maj-juni 12/15 Institution Uddannelse Fag og niveau Lærer(e) Hold Campus Vejle HHX Informationsteknologi niveau

Læs mere

Brugermanual til MOBI:DO Make på ipad

Brugermanual til MOBI:DO Make på ipad Brugermanual til MOBI:DO Make på ipad Introduktion Med MOBI:DO Make kan du oprette guides, som kan ses i MOBI:DO. En guide virker som en checkliste, der fører brugeren hele vejen igennem en arbejdsopgave.

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

Gruppe: 2 Hold: MulB Årgang 2013 Lærere: Merete Geldermann Lützen & Jesper Hinchely

Gruppe: 2 Hold: MulB Årgang 2013 Lærere: Merete Geldermann Lützen & Jesper Hinchely Bannerpage: http://spicegirls.creativefolder.dk/bannerpage/ Landingpage: http://spicegirls.creativefolder.dk/ René Skovgaard Andersen cph-ra73@cphbusiness.dk Stig Hamborg Nielsen cph-sn9@cphbusiness.dk

Læs mere

10 gode grunde. - derfor skal du vælge Office365

10 gode grunde. - derfor skal du vælge Office365 10 gode grunde - derfor skal du vælge Office365 1. Bedre samarbejde på tværs af lokationer En stor del af arbejdsstyrken tilbringer i dag langt mere tid væk fra deres kontor end hidtil. Dine ansatte kan

Læs mere

Indholdsfortegnelse for kapitel 1

Indholdsfortegnelse for kapitel 1 Indholdsfortegnelse for kapitel 1 Forord.................................................................... 2 Kapitel 1.................................................................. 3 Formål............................................................

Læs mere

Lav animationer i undervisningen det er sjovt og lærerigt!

Lav animationer i undervisningen det er sjovt og lærerigt! Lav animationer i undervisningen det er sjovt og lærerigt! Af Pernille Ulla Andersen & Benny Lindblad Johansen, lektorer I biologiundervisningen ved Læreruddannelsen i Århus arbejder de studerende med

Læs mere

IT-UNIVERSITETET I KØBENHAVN

IT-UNIVERSITETET I KØBENHAVN IT-UNIVERSITETET I KØBENHAVN MASTER I SOFTWARE ENGINEERING itu.dk/master/software MASTER I SOFTWARE ENGINEERING Master i Software Engineering er til dig, som allerede er en erfaren software- og systemudvikler,

Læs mere

Programmering 2. dprog2 E2012. http://www.cs.au.dk/dprog2/

Programmering 2. dprog2 E2012. http://www.cs.au.dk/dprog2/ Programmering 2 dprog2 E2012 http://www.cs.au.dk/dprog2/ Læringsmål Deltagerne skal ved afslutningen af kurset kunne: forklare og anvende både basale og videregående elementer af et moderne programmeringssprog,

Læs mere

Opstart. I gang med Dreamweaver. Læs mere om... Generelle bemærkninger. Hvilken skærmopløsning? OBS

Opstart. I gang med Dreamweaver. Læs mere om... Generelle bemærkninger. Hvilken skærmopløsning? OBS Generelle bemærkninger Programmet Dreamweaver har været på markedet i nogle år efterhånden. Den seneste version hedder Dreamweaver CS4, og programmet er på engelsk. Dreamweaver er en såkaldt grafisk editor,

Læs mere

Brugermanual til MOBI:DO Make på Android

Brugermanual til MOBI:DO Make på Android Brugermanual til MOBI:DO Make på Android Introduktion Med MOBI:DO Make kan du oprette guides, som kan ses i MOBI:DO. En guide virker som en guide der fører brugeren hele vejen igennem en arbejdsopgave.

Læs mere

poedit og oversættelse af sprogfiler

poedit og oversættelse af sprogfiler poedit og oversættelse af sprogfiler af Georg S. Adamsen WordPress.Blogos.dk 2009 http://kortlink.dk/wordpressblogosdk/6g38 1 af 11 14-04-2009 14:55 Jeg får af og til spørgsmål om, hvordan man bruger poedit,

Læs mere

Vejledning til Teknisk opsætning

Vejledning til Teknisk opsætning Vejledning til Teknisk opsætning v. 1.0 Adm4you, 2010. Indhold Kort om denne vejledning... 3 Generelt om easyourtime... 3 Installation af databasen... 3 Sikkerhed og rettigheder... 4 SQL Login... 4 Rettigheder

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

Prototypeprojekt. Lisbeth Ammitzbøll, Arne Jørgensen, Rene Jørgensen og Lotte Simonsen (gruppe 4) 20. april 2005. Indhold

Prototypeprojekt. Lisbeth Ammitzbøll, Arne Jørgensen, Rene Jørgensen og Lotte Simonsen (gruppe 4) 20. april 2005. Indhold Prototypeprojekt Lisbeth Ammitzbøll, Arne Jørgensen, Rene Jørgensen og Lotte Simonsen (gruppe 4) 20. april 2005 Indhold 1. Indledning/problemformulering 2 2. Kravspecifikation og evalueringsteknikker 2

Læs mere

It- fagets metoder, version 0.3

It- fagets metoder, version 0.3 It- fagets metoder, version 0.3 Et notat der beskriver it- fagenes metoder med specielt fokus på det nye forsøgsfag informationsteknologi i de gymnasiale uddannelser: stx, hhx, htx og hf. Michael E. Caspersen

Læs mere