1. No category

Procesanalyse
28. maj 2010
A312
Jens Stokholm Høngaard
Kristian Pilegaard Jensen
Thomas Birch Mogensen
Niels Asger Aunsborg
Nicolai Vesterholt Søndergaard
Daniel Agerskov Heidemann Jensen
Indhold
1 Projektplanlægning
1
2 Samarbejdet i gruppen
4
3 Samarbejdet med vejledere
6
A møder
A.1 Mandag 1. Feb .
A.2 Fredag 5. Feb . .
A.3 Onsdag 10. Feb .
A.4 Mandag 8. Mar .
A.5 Onsdag 10. Mar .
A.6 Onsdag 17. Mar .
A.7 Onsdag 24. Mar
A.8 Onsdag 31. Mar
A.9 Onsdag 7. Apr .
A.10 Onsdag 5. Maj .
A.11 Torsdag 6. maj .
A.12 Onsdag 12. Maj .
A.13 Fredag 14. Mar .
A.14 Torsdag. 20 Maj
A.15 Fredag. 21 maj .
A.16 Samarbejdsaftale
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
I
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
8
8
8
8
9
9
10
11
11
12
13
14
15
15
16
16
16
1
Projektplanlægning
I projektarbejdet har vi benyttet Google kalender som kalender, Google SVN til
versionsstyring og Google Wave til referater af møder samt anden information.
LaTeX har vi brugt til at skrive i og tavlen har, vi brugt til at skrive ting som
dagsorden og ligende op p˚
a. Disse værktøjer har bidraget til en strukturering af
møder og rapporten. Vi har haft en dagordenen til hvert møde, som skulle sikre,
at vi fik gennemg˚
aet de punkter, vi gerne ville diskutere. Gruppearbejdet har
best˚
aet af inddeling i mindre grupper og individuel arbejdsdeling. Google SVN
brugte vi i stedet for universitets egen versionsstyring, hvilket vi har været glade
for.
Vi har haft en rollefordeling, hvor der har været en sekretær, en ansvarlig for
kalender, en ansvarlig for google wave, en der st˚
ar for LaTeX, en ansvarlig for at
tage kontakt til vejleder og en der er ansvarlig for dagsordenen.
Vi har ikke haft en projektleder, men nogle gruppemedlemmer syntes at især
to fra gruppen af og til har virket dominerende.
Vi brugte LaTeX til at skrive selve rapporten i, vi havde en fil for hvert kapitel,
som blev inkluderet i vores hovedfil.
Vi har haft svært ved at finde en fast problemformulering. Det har medført,
at det har været svært at komme igang med de forskellige afsnit i rapporten. Det
var først til sidst, vi fik lavet den endelige problemformulering.
Vi har været meget d˚
arlige til at lave projektplanlægning, da vi ikke engang
har lavet en tidsplan. Grunden til dette er, at vi ikke har haft overblik over projektet som et færdig produkt.
Senere i projektet fandt vi ud af, at det var en god ide at skrive arbejdsopgaverne op p˚
a en tavle, p˚
a den m˚
ade havde alle i gruppen overblik over, hvad de
andre var i gang med og hvilke opgaver man kunne begynde p˚
a. Vi er overbeviste
om, at dette har styrket arbejdsmoralen, da man kunne se at rapporten rykke
sig. Nogle i gruppen mener ikke vi brugte Google Wave nok, især i slutningen af
projektet, hvor nogle føler, at man kunne skrive noget og det s˚
a aldrig blev læst
af andre. Endvidere mener sekræteren i gruppen heller ikke af nok af gruppemedlerne læste referaterne igennem. Google kalender var et rigtig godt værktøj, som
vi ikke blev gode nok til at udnytte, det eneste der stod p˚
a kalenderen var det
møde, vi havde hver onsdag med vores hovedevejleder, og s˚
a vores status møde
om mandagen. Vi burde have været meget bedre til, n˚
ar arbejdsopgaver blev delt
ud at skrive dem p˚
a kalender ogs˚
a samt skrive p˚
a, hvorn˚
ar gruppemedlemmer var
forhindret i fremmøde.
LaTeX har vi været rigtigt glade for, da vi har været i stand til at dele
projektet op i flere filer, har det været nemt at dele gruppen op i mindre grupper
og arbejde for forskellige dele. Det eneste problem vi har haft med LaTeX er,
at flere i gruppen fik nogle kompilerings fejl, som vi ikke kunne forklare, hvilket
resulterede i kun to fra gruppen kunne kompilere til sidst. Dette har dog ikke
1
været nok til at ødelægge vores opfattelse af LaTeX og vi regner med det har
været en fejl fra vores side, s˚
a vi h˚
aber det ikke kommer igen i næste projekt.
Google SVN har vi oplevet at være nemmere at sætte op p˚
a computeren og
vi har kun haft f˚
a server problemer. P˚
a universitets SVN har flere været træt af,
at man hver gang man ville opdatere, skulle man taste sit kodeordet ind igen,
hvilket ikke er tilfældet med Google SVN, som godt kan huske kodeordet, hvilket
er utrolig dejligt, n˚
ar man n˚
ar op p˚
a 800 revisions.
Tavlerne i vores gruppelokale har vi haft rigtigt meget gavn af, vi har haft
fem tavler og vi kunne godt have brugt flere, hvis vi fik lov. Vi skrev alle de
vigtigste arbejdsopgaver op p˚
a tavlen, s˚
a gruppemedlemmerne kunne g˚
a op og
skrive sig selv p˚
a, n˚
ar de gik i gang med at arbejde p˚
a dem. Vi brugte meget
en opsætning, hvor opgaverne stod opskrevet i tabel form, hvor vi har haft en
kolonne med opgaverne, en med hvem der har rettet opgaven igennem, en med
status over opgaven og en med kommentarer. Det har været nemt og overskueligt
at finde rundt i, vi førsøgte i starten at føre det samme system p˚
a Google Wave,
men uden den samme sucess.
At ikke have en bestemt projektleder er noget vi har været glade for, da der
ikke har været en enkelt person, som havde retten til at bestemme. Vi har i
stedet brugt diskussion til at finde frem til, hvad der var rigtigt, men i enkelte
tilfælde har vi ikke kunne blive enige og har valgt at bruge afstemning til at
afgøre diskutionen. Vi har derfor indført demokrati som vores ledelsesform.
De to fra gruppen der af og til virkede dominerne, mener gruppen har været til
fordel, det meste af tiden, da de har kunne sætte skub i diskussioner, der har kørt
i ring, og været med til at sætte folk i gang, hvis det er g˚
aet lidt for langsomt,
de har dermed været med til at tage intiativ og sikre at projekt kom videre. Men
det er sket i nogle situationer, at det har taget lidt overh˚
and, s˚
a nogle i gruppen
mener, det har virket som om de ikke længere havde den ønskede inflydelse. Dette
har ogs˚
a været noget, der blevet taget op til en enkelt gruppemøde, har de to
blevet gjort opmærkesomme p˚
a det. De i gruppen der ikke har været dominerende
mener dog ogs˚
a de selv har været en del af problemet, da de ikke altid selv har
været gode til at komme p˚
a banene i diskussioner og ikke rigtigt har førsøgt at
tage styringen.
Vi forsøgte fra starten at prøve at f˚
a en problemformulering p˚
a plads, men
det lykkedes ikke. Vi forsøgte med flere forskellige vinklinger p˚
a problemet, for
til sidst at finde frem til den endelige, men selv da denne var fundet, havde vi
problemer med strukturen p˚
a vores problemanalyse samt problemer med at f˚
a
beskrevet det initierende problem ordentligt. Alt dette har medført vi kom alt for
sent i gang med mange dele af projektet, da det var svært at tilrettelægge, hvilke
dele der skulle laves før, vi vidste præcist, hvad vores problem var. S˚
a modsat
vores ønske som oprindeligt var have en problemanalyse næsten p˚
a plads efter en
m˚
anede, havde vi den først næsten p˚
a plads da projekt perioden næsten var slut.
At vi ikke har været s˚
a gode til at planlægge projektet har medført, at der
l˚
a meget arbejde i slutningen af projektet. Vi prøvede i starten at forhindre det2
te ved at have en tidslinje med de største m˚
al, som for eksempel hvorn˚
ar vores
problemformulering og problemanalyse skulle være færdige, og til hvilken dato
hele projektet skulle være klar til rettelser. Men da problemanalysen skred, som
beskrevet tidligere, var det som om vi helt glemt tidslinjen, hvilket førte til vi
ikke rigtigt havde nogle deadlines for de forskellige dele af projekt. Dette var et
problem, da vi fik en rodet overordnet struktur p˚
a vores projekt, og derfor brugte
meget tid p˚
a at omskrive afsnitet, flytte dem rundt i projektet og tilpasse dem.
Alt dette har været med til at trække den samlede kvalitet af projektet ned, da
vi ikke havde nær s˚
a meget tid til at g˚
a i dybten med afsnittende.
Til at f˚
ar de sidste gruppemedlemmer mere p˚
a banen, har vi ikke nogen konkret løsning p˚
a. Man kunne prøve at bede de to, der var dominerende om at
være mere passive i diskutionerne, men vi mener ikke dette er løsningen, da diskutioner da ofte ikke vil komme nogle vejne. Derfor mener vi ikke, at dette vil
være en løsning. Styringsformen demokrati har dog virket godt og vi vil helt klart
bibeholde denne.
Vi vil lave en liste med arbejdsopgaver, deres status, og hvem der arbejder p˚
a
dem fra starten af projektet. Dette vil være med til at sikre, at vi kommer godt
igang med projektet, at vi f˚
ar lavet noget og at vi føler dette. Et vigtigt m˚
al for
næste projekt vil være at f˚
a dette til at køre, ogs˚
a i starten af projektet, selvom
der ikke er nogle lige s˚
a konkrete arbejdsopgaver.
Vi har været glade for vores værktøjer, s˚
a vi vil nok fortsætte med at bruge
disse. Og sikkert endda udvide brugen af nogle. Især Google kalender vil vi benytte
mere til begivenheder, der ikke sker hver uge, som f.eks. gruppearbejde, eller
deadlines for arbejdsopgaver.
Vi kan ikke forestille os at g˚
a væk fra brugen af LaTeX og vil helt sikkert
benytte det i projekter fremover. Sammen med SVN har det gjort det utrolig
nemt at f˚
a flere til at skrive p˚
a projektet p˚
a en gang. Vi ser heller ingen grund
til at skifte fra at bruge Google SVN, da denne har virket rigtig godt.
Vi vil have meget hurtigere og bedre styr p˚
a vores problemformulering. Dette
vil vi gøre ved at tage fat i et konkret problem og arbejde ud fra at løse det, i
stedet for at vælge et emne og finde et problem der passer til projektet. Dette
skulle ogs˚
a hjælpe til at give rapporten en naturlig kontekst.
Vi vil lave en bedre tidsplan, der dækker hele projektet. Dette vil give os et
bedre overblik over projektet. Vi vil desuden, hvis det skulle ske at tidsplanen
skred, revurdere den i stedet for helt at glemme den. Selve problemet med at
tidsplanen skred, kan krediteres andre problemer vi har haft, som f.eks. den tidligere nævnte manglende problemformulering og mangel p˚
a en konkret liste af
arbejdsopgaver.
3
2
Samarbejdet i gruppen
Samarbejdet har for det meste g˚
aet godt. I starten af projektet snakkede vi om
vores fælles erfaringer fra det tidligere projekt, hvilket senere blev ført til en
samarbejdsaftale. Vi lavede samarbejdsaftalen s˚
aledes at vi ikke var i tvivl om
hvad der skulle gøres ved forskellige situationer. Der har ikke været nogen straf
for at komme for sent. Det har været den enkeltes eget ansvar selv at møde,
s˚
a hvis man ikke møder, f˚
ar man ikke udbytte af mødet. Der st˚
ar dog i vores
samarbejdsaftale, at man skal skrive til to fra gruppen, hvis man er mere end 15
minutter for sent, hvilket for det meste har virket. Vores samarbejdsaftale har
fungeret som et værktøj til at takle problemer og hvordan gruppen skal forholde
sig i forskellige situationer. Vi har valgt, at skrive den p˚
a vores google wave, s˚
a
vi senere kan vende tilbage til den.
Et andet problem var at en fra gruppen, ikke brød sig om at arbejde i grupper. Endvidere følte gruppen, at diskutionerne med personen ikke førte os frem
mod en løsning, men blot kørte i ring og var spild af tid. De andre i gruppen diskuterede om, personen skulle ud af gruppen, men personen valgte selv at g˚
a ud
af gruppen. Vi havde især mange diskutioner om hvordan gruppearbejdet skulle
foreg˚
a, personen der gik ud mente at møder og krisemøder skulle planlægges 48
timer før. Dog var alle andre meget uenige med at gøre dette p˚
a den m˚
ade, da der
kunne dukke noget op som man ikke havde forventet. Dette er kun et eksempel
p˚
a en lille ting, personen ikke var enige med resten af gruppen i, hvordan dette
skulle h˚
andteres, som personen s˚
a gjorde et stort nummer ud af. Det gav en d˚
arlig
stemning i gruppen, da vi gerne ville igang med projekt.
Vi holdte et statusmøde i gruppen hver mandag, hvor vi snakkede om, hvad
der skulle ske i denne uge. I starten havde vi ofte en ordstyrer, som styrede
diskutionen, dette gik vi dog fra senere. Grunden til at vi stoppede med at have
en ordstyrer var, at efter et medlem af gruppen gik, havde vi ikke nogen problemer
med dette. I starten snakkede vi bare om det, vi mente var relevant, men senere
fik vi lavet en dagsorden til hvert møde.
Vi har ikke gjort noget særligt for motivere hinanden i gruppen, dog har de,
som har styret projektet fortalt andre i gruppen, at de burde arbejde, n˚
ar de sad
og lavede noget useriøst.
Vores arbejdsindsats har været meget svingene, da vi har valgt at tillade at
have lange pauser. De lange pauser var et bevidst valg, da vi ville sikre, at der
ogs˚
a var plads til at slappe af. Det skulle ogs˚
a fungere som en motiverende faktor.
Dette har ikke altid fungeret efter hensigten da pauserne af og til er blevet for
lange.
Vores gruppearbejde har fungeret godt, da vi i de sm˚
a grupper har kunnet
hjælpe hinanden med at skrive de komplicerede afsnit. I andre tilfælde har det
været smartere at arbejde enkeltvis.
Men vi har dog haft problemer med, at folk ikke har mødt til tiden. Dette kan
4
være pga. at folk ikke kan st˚
a op til tiden. Vi er sikker p˚
a, at dette ikke bliver
et problem i fremtiden, n˚
ar folk ikke er afhængig af busser og da vi p˚
a datalogi
kommer til at bo tættere p˚
a universiteten. Alle deltager til vores møder, men der
er selvfølgelig nogen, der siger mere end andre.
Vores problemer med det tidligere medlem kunne muligvis være lyst mere
elegant. Utrolig mange af diskutionerne degenerede hurtigt til skænderier i stedet
for at forsøge at finde en konstruktiv løsning. Der var dog nok ingen vej udenom
at han skulle ud af gruppen, da vi havde nogle meget forskellige opfattelser af
hvad det ville sige at arbejde sammen som en gruppe om et projekt. Det eneste
man kan sige er at vi muligvis kunne have spottet problemerne tidligere, s˚
a det
ikke have optaget s˚
a meget af projektskrivningstiden, og vi ikke var blevet s˚
a
irritable.
Vores ugentlige statusmøde var godt at have af flere grunde. Hovedsageligt
holdt vi mødet for at f˚
a gjort status over projektet og udelt arbejdsopgaver, samt
snakke om der var nogen problemer med samarbejdet eller det sociale der skulle
tages h˚
and om. Men det at møde hinanden struktureret en gang om ugen var
ogs˚
a en god m˚
ade at vidensdele p˚
a, og sørge for at vi ikke arbejdede i forskellige
retninger. Manglen p˚
a struktur p˚
a møderne var et problem, da vi sjældent fik
gennemg˚
aet det vi ville, og stod bagefter uden at have f˚
aet noget ud af det. Vi
udnævnte derfor en person til at st˚
a for at lave dagsorden til hvert møde, hvilket
gjorde at møderne blev mere strukturerede og blev til noget vi fik noget ud af og
blev glade for.
De lange pauser har b˚
ade været med til at skabe et godt socialt miljø og
gjort at man gjort at man tit fik lyst at lave noget, da det ikke føltes s˚
a tvunget.
Til gengæld krævede det ogs˚
a en høj diciplin, hvilket nogle gange har været et
problem, b˚
ade for de enkelte medlemmer af gruppen, men ogs˚
a for gruppen som
helhed.
Vores samarbejde, hvor vi har arbejdet i sm˚
a grupper, har fungeret rigtig
godt, s˚
a det vil vi blive ved med. Vi vil vende tibage til vores samarbejdsaftale
løbende for at sikre, at vi f˚
ar det fulde udbytte ud af den. Samarbejdsaftalen
har været gemt lidt væk og ikke brugt i hverdagen. Ved at vende tilbage til
samarbejdsaftale, vil den kunne blive brugt mere.
Man vil kunne forvente i fremtidige projekter at folk er mere vant til gruppearbejde, og der derfor ikke vil være lige s˚
a stor forskel p˚
a hvordan folk syntes
gruppearbejde skal foreg˚
a. En god m˚
ade at sikre sig at dette problem ikke ødelægger projektet mere end højst nødvendigt, ville være at f˚
a lavet en omfattende
samarbejdsaftale som alle kan g˚
a med til som det allerførste.
Det ugentlige statusmøde vil vi fortsætte med i fremtidige projekter. Vi vil
dog i fremtiden sørge for at vi fra starten af projektet sørger for at der er en
dagsorden til hver gang, s˚
a vi ikke risikerer at spilde tiden. Og selvom fordelingen
af arbejdsopgaver nok vil ske mere løbende ved altid at have en liste af ting man
5
kan skrive sig p˚
a og g˚
a i gang med bestemte evner, vil det nok alligevel være godt
at f˚
a samlet op en gang om ugen.
3
Samarbejdet med vejledere
Vi har valgt at have møde to gange om ugen, hvoraf det ene møde har været
med hovedevejlederen og det andet har været et møde med gruppen, derudover
har vi haft møder med vores bivejleder efter behov. Vi har op til hvert møde haft
en fast dagsorden, som vi har holdt os til. Det sidste punkt p˚
a dagsordenen var
”Evaluering”, punktet kom p˚
a dagsorden, fordi vores vejleder mente, det var en
god id´e. Vi har brugt evalueringen til at finde ud af og vi har f˚
aet fuldt udbytte af
mødet. Selvom vi altid var enige om, at vi havde f˚
aet masser ud af mødet, synes
vi stadig at punktet var en god id´e, da det jo ikke var en selvfølge. Dette punkt
skulle være med til at forbedre møderne, s˚
a vejlederen og gruppen fik det ud af
mødet de gerne ville. Vi lavede en aftale med vejlederne om at vi skulle sende det
materiale, vi ville have rettet igennem 2 dage før mødet, s˚
a vejlederne havde tid
til at læse det ordentligt igennem. Aftalen fungerede helt udmærket, ud over at
vi blev forsinket et par gange og ikke fik sendt det til tiden. Dette var dog kun
et problem i starten af projektet.
Vi har haft stor glæde af vores hovedvejleder, der har givet os konstruktiv
kritik løbende og hjulpet til strukturen af afsnittene, samt hjulpet os med kompliserede dele af projektet. Bivejlederen har vi brugt til den kontekstuelle del af
rapporten. Der er enkelte fra gruppe, der har oplevet at f˚
a mere ud af bivejleder
end, de tidligere har gjort. Andre i gruppen som var i en anden gruppe tidligere,
oplevede samme niveau fra bivejlederen. Vi har ikke haft s˚
a mange møder med
vores bivejleder, da vi hovedesageligt p˚
abegyndte den kontekstuelle del i slutningen af projektet. Set i bakspejlet burde vi nok have startet tideligere p˚
a den del
af rapporten, for at udnytte vores bivejleder bedre.
Til vejledermøderne har vi gennemg˚
aet det, vi har sendt til vejlederne. Dog
har vi været for d˚
arlige til at læse udkastet til vejlederen igennem, hvilket har
været vores fejl alene. P˚
a trods af det mener vi, at vi har f˚
aet meget ud af vores
møder, hvis dette ikke havde været tilfældet, kunne vi have diskuteret dette under punktet evaluering. Vi burde have brugt meget mere tid p˚
a at læse rapporten
igennem flere gange, da vi tit afleverede arbejdsblade med mange fejl som sl˚
afejl
og manglede kommaer. S˚
a de fleste fejl kunne vi have undg˚
aet ved at gennemlæsning arbejdsbladet, før vi sendte det til hovedvejlederen. Vi blev i løbet af
projektet bedre til at gennemlæse, hvilket det er vores opfattelse af vores vejleder
satte pris p˚
a. Men fik ikke løst problemet.
Forventningerne til vores vejledere har været, at de læser det vi sender igennem og kommer med konstruktiv kritik, som vi kunne drage nytte af. Vi mener
6
da ogs˚
a at vores vejledere har været rigtig gode p˚
a dette punkt. Nogen fra gruppen havde en mindre god hovedvejleder i sidste projekt, s˚
a de var meget glade
for, at hovedvejlederen i dette projekt gav konstruktiv kritik. Deres tidligere hovedvejleder var meget tilbageholdt og gav ikke kritik, hvis ikke de spurte ind til
det. Alle i gruppen har været glade for, at begge vejledere har været s˚
a kritiske,
da det er det vi lærer noget af. Derfor er vi enige i gruppen om at, den meget
direkte vejledning er langt bedre. Det skal dog siges at vores hovedevejleder, har
været mere direkte end vores bivejleder, men ikke i en s˚
adan grad at vi føler, at
vi ikke har f˚
aet lige s˚
a meget ud af vores bivejleder.
Vi vil være bedre til at læse udkastet til vejledermødet igennem, inden vi
sender det. Dette vil gøre, at vi kan fokusere p˚
a vigtigere fejl til mødet frem
for de sm˚
a fejl som stavefejl og sl˚
afejl, som vi sagtens selv kunne have undg˚
aet,
ved selv at have styr p˚
a tingene. Da vi har været meget tilfredse med vores to
vejledere, vil vi ikke stille yderligere krav til vores vejledere fremover. Vi forventer,
at vi fremover vil f˚
a kritik af, hvad vi har skrevet, som det er tilfældet nu, og at
vi fortsat vil kunne f˚
a ugentlige møder og hjælp, hvis vi har problemer eller p˚
a
anden m˚
ade mangler vejledning.
7
A
A.1
møder
Mandag 1. Feb
Fra første møde: Samarbejdsaftale: Hvis man kommer for sent: Man g˚
ar i gang
til tiden (08:30), s˚
a m˚
a de andre kommer ind i det. Hvis en person kommer
Hvis noget ikke fungere i gruppen: Luft det for de andre. Hvis de andre ser
problemet ogs˚
a tag det om til et statusmøde.
Ideer: Start hver dag med at opstille en dagsorden. Vi skriver p˚
a google calender hvorn˚
ar vi skal mødes. God ide, at arbejde to og to. Start ud med at f˚
a
lavet en projektanalyse. Flere vejledermøder.
Dagsorden til hvert møde. En sekretær: ind til videre mig (Birch)
Tidsplan i google calender. Deadlines. Møder om status, s˚
a som hvordan g˚
ar
det i gruppen, ikke nødvendigvis om projektet.
A.2
Fredag 5. Feb
Møde med hovedvejleder:
vi har tænkt meget over flugtveje i denne bygning. Hvilken bygning er vi i?
hvormange mennesker er der?
hans: prøv først at f˚
a formuleret problemet helt præcist det er jo en hel anden
situation hvis der kun er en udgang om gange mennesker frem for en bygning med
mange udgange og f˚
a mennesker. . mange parameter. grafteori og diskret matematik. simpelt formulering er flugtvejsproblemet = kortestevejproblemet Flaskehalse
problemet.
første skridt er model af grafteori. grafteori, nogle knuder er udgange. det man
leder efter er givet en bygning beskrevet som graf hvor knuderne er udgang. kan
man beregne flugtveje.
hvad skal vi gøre nu?: f˚
a indentificeret problemet hvad er det for nogle problemer? Litteratur: bogen til leif’s kursus.
til at findes to algoritmer drejkstars algortime bellman og ford evt. floyed
forst˚
a kortestvej og f˚
a læst lidt grafteori.
problemer i luften: hvilken udvej skal jeg vælge hvad nu hvis bygningen ændre
sig hvor hurtigt er det at ændre evakueringsplanen hvordan forbedre man flugtveje
folks opførsel under brænd m.m. hvordan laver man evakueringsplaner i dag, og
hvad tager de højde for
vi kan bruge grafteori hvor gange b˚
ade har en afstand og en kapasitet.
næste møde: onsdag altid.. klokken 8.15
vi skal have en fast dagsorden.
A.3
Onsdag 10. Feb
Møde med hovedvejleder:
8
Dagsorden - godkendelse af dagsorden godkendt - respons p˚
a problemformulering vores program spørgsm˚
al skal omformuleres der er forskel p˚
a hvad vi vil
finde og hvordan vi har formuleret det først hvad, derefter metode.
Vi vil opstille matematisk model. Hvordan kan vi implamatere den.
vigtigt trin i mellem matematisk model og algoritme. Kan man finde en effektiv algoritme?
hvad mener vi med optimal? effektiv algoritme,, hvad mener vi ved det?
- Status
- Hvad gør vi nu? Først lav en god problemformulering S˚
a lav graf model over
basis
Læse mere om grafteori Læse mere om emnet Tænk over løsning p˚
a falskehalseproblemet i forhold til døre hvordan kan vi vise dette i grafteori Hver kant
har to oplysninger.
http : //en.wikipedia.org/wiki/Dijkstra0 sa lgorithm
http : //en.wikipedia.org/wiki/Bellman − F orda lgorithm
Prøve at modellere basic som graf
evt. en knude et sted man kan være, en strej viser man kan bevæge sig vi skal
skældne i mellem hvordan vi representere situationen og hvordan vi formulere
problemet nogle knuder kunne være udveje
Sidste problem skal omformuleres: Hvilket problem er der? Problemerne er
s˚
adan og s˚
adan. H/V spørgsm˚
al, det skal kunne diskuteres.
- Samarbejde Vi skal lave en form for minifremlæggelse. Vi skal huske at læse
hinandensarbejdsblade. Vi skal fokusere p˚
a de to overst˚
aende
Vi skal have formuleret en samarbejdsaftale. bla ud fra første referat
ifølge hans: vil den f˚
a gjort os bevidste om vores m˚
al.
Vi skal have lavet vores tidsplan
- Næstemøde sammetid
- E.v.t
A.4
Mandag 8. Mar
Statusmøde i gruppen:
Søren skal huske at skrive sit info det rigtige sted p˚
a google Wave Hvis mere
end halvdelen er enig om at holde møde skal det holdes Hvis mere end halvdelen
af gruppen kan komme aflyses møder ikke Demokrati i gruppen.
A.5
Onsdag 10. Mar
Møde med hovedvejleder:
Godkendelse af dagsorden
status Vi skal ikke vente s˚
a meget p˚
a vores problemanalyse er færdigt, vi kan
bare g˚
a i gang med det vi ved vi skal lave
9
kommentarer Vi skal sende vores ting til hans i god tid. Senest morgenfør og
kun hvis det er lidt. Vi skal sende læsevejledning.
problemanalyse: vi mangler struktur, skrevet d˚
arligt.
vi opstiller det mere som modeller, vi skal have noget over det skal vi lave
et program, hvem skal bruge det? skal vi kun lave beregningen en gang eller i
realtime
overvej grafteori før de overvejelser om optimal vej.
for f˚
a kildehenvisning.
vores modelovervejelser, hvad forst˚
ar man med optimalevej vi skriver aldrig
hvad en dørskapacitet er skal beskrives bedre, hvorfor er det kun sidste dør. evt
i antal enheder pr sek.
grafteori emne strømningsproblemer / flowproblemer
VI SKAL have helt styr p˚
a kapacitet i problemanalyse FØRST: STRUKTUR
˚
SA: KRAV TIL LØSNING S˚
A: METODE OG VALG AF MODEL S˚
A: evt flow
OG: indfør og overvej, hvad er afstand, optimal MEGET mere precis i hvad
vi mener.
forbud mod snakke problemet
F˚
a nu de f*** kilder p˚
a. Grafteori: skal kaseres og skrives igen. skal skrives
mere precist.. mere definition
samarbejde Skrevet konkrete eks ned til næste møde.
hvad sker der s˚
a Kigget p˚
a problemanalyse. -tænk over m˚
al og arbejdsplan
Nogle laver nyt grafteori afsnit grafer veje m.m.
evt send senest mandag eftermiddag, arbejdsblad.
evaluering
A.6
Onsdag 17. Mar
status:
kommentarer: indledning: lidt bedre, men struktur er ikke tydelig, initierende problem, s˚
a er der krav til produkt, mulig brugere, overvejelser over model,
overvejelser om metode. vi kommer til at blande det sammen vi bør: lave under
overskrifter.
antagelser om forskelle slags bruger er ikke helt klare. komisk? omkring brug
at programmet og om guider skal have det. formuleres bedre. guider m˚
a heller
ikke brænde inde, hvor skal de være?
bruge algortime, m˚
aske allerede før det brænder? meget store bygniger. man
ved hvor der typisk opst˚
ar brænd. m˚
aske et hjælpe middel for arkitekter. beskriv
hellere at det kan bruges, her og her og her og her, i stedet for at ligge fast.
krav til flugt ruter i dag bør vi have lidt om ikke nødvendigvis i indledning.
vores antagelser om kapacitet og længde, analyser, vurder, formuler precist.
vi skal først forst˚
a problemet og have en ordetlig model, s˚
a kan vi introducere
vores antagelse.
SNART: LAV precis beskrivelse af vores model.
10
en model: med kap og længde anden model: hastighed langs kant, optimal vej
i de to forskellige, en løsning i vores verden = løsning i de to modeller.
ikke store antagelser p˚
a tideligt tidspunkt.
Grafteori: det noget lort, d˚
arligt set.
svært ved at dæmpe eksempel snart. flyder ind og ud af definitioner
skal laves om.
numerede definationer.
skriv grafteori, ikke om grafteori.
Orienterede graf og ikke orienterede graf.
GØR: læs op p˚
a mængde/sets.
algortimer: fjern dem. definationer p˚
a samme m˚
ade som i grafteori.
samarbejde søren ude af gruppen.
hvad sker der nu? læs mængder, skrevet grafteori om, revideret problemanalyse og skrottet algortimer.
evt
evaluering
A.7
Onsdag 24. Mar
godkendelse af dagsorden:
Status:
Kommentarer: indledning - grafteori / flow er det vores bud? lidt fortidligt.
flugvejs problemer et antal udgange og et antal sted man skal flygte fra, skal
med i flugtvejsproblem og ikke kun i flow problem. specifisere hvorfor 2 knuder i
korteste vej.
optilmal vej, som om vi glemmer alt vi har skrevet forinden og starter med
snak. f˚
a formuleret vores flugtproblem, en kombination af korteste og hurtigstevej.
grafteori - def 4 lav om til vej. def 5 & 6 væk, forfra.
sidste kommentar: lad problemanalyse ligge lidt. f˚
a gjort noget ved grafteori.
F˚
a lavet det.
lav 3 arbejdsblade. i artikel(latex).
Samarbejde: hvad sker der nu: optimal vej skal skrives om, eller ændres. f˚
a
formuleret flutproblem korrekt. st˚
ar der stadig orienteretgraf??
i formulering: definer dem i løsningen.
til løsning: sæt begrænsninger p˚
a C(PI), og finde evt bedre løsning skriv først
om passagefunktion s˚
a om stømningsfunktion og s˚
a begge samlet.
Evt:
Evaluering:
A.8
Onsdag 31. Mar
godkendelse af dagsorden
status
11
kommentarer problemer med at formulere precist. nogle latex fejl, læs igennem. det meste giver d˚
arlig mening eller ingen mening.
Læs det hele igennem... igen igen igen igen..
Der er et flugtvejs problem og s˚
a nogle defintioner.. det bliver ikke gjort explicit. vi føre noget vi har brugt.
defintion et: definere vi lille eller store T.
def2: vi bruger ikke k til noget. k er ikke vel defineret. hvad er s d og f? teta
er en vej i en graf, n˚
ar jeg bruger f p˚
a nogle kanter f˚
ar jeg nogle tal.
def3: hvad er s? kan der være flere mængder af kilder. hvad er b? en funktion.
hvad er m?
de sidste 10 linjer giver ingen mening.
hvad vi vil definere gør vi ikke klart.
fodnoter er ikke gode.
hvis noget af dette st˚
ar i et færdig projekt vil det trække ned og kunne ikke
best˚
a.
samarbejde
vidensdeling: n˚
ar der skal overdrages ansvar, skal man sige disse dokumenter
følger med. med læsevejledning
hvad sker der nu
evt
A.9
Onsdag 7. Apr
Hans: Godkendelse af dagsorden
status
kommentarer Se p˚
a flugtplanen.. man kan se hvem der har godkendt den.
det er godt vi har f˚
aet skrevet noget om algortimer og tidskompleksitet.
men arbejdes bladet er af meget lav kvalitet.. vi kan ikke best˚
a som den er
nu... skriftlig fremstilling er d˚
arlig. flere steder ulæslig.
tidskompleksitet.. meget upræsise sammenhæng.. lange upræcise kritik.. s˚
a
tallet.. det skal være omvendt.. først tallet, s˚
a vurdere.
Fra teori til model 1.1. skal have ny overskrift..
det kan godt være vi kalder det basis, men i virkeligheden er det alts˚
a strandvej
12 etage 2.. gange hedder * og ikke kryds..
Husk nu mathmode..
Antagelse om summen.. se hans ark.
afsnit om algortimer: kortestevej, kommer før antagelse om kortestevej.! Dijkstras algortimer og bellmanford algortime mangler. man kan først sige en algoritme er hurtig n˚
ar vi kender tidskompleksiteten
Store O bruges til at sammenligne vekstrate..
bellman ford - vi skal fortælle hvad det er og hvad dens tidskompleksitet er.
floyed - en vægtet nabo matrix, graf om til matrix multiplikation. har vi
skrevet noget om engang.
12
side 7. principperne om relation.. hvad mener vi ?
fordele og ulemper om floyed.. FIX det søren har skrevet.! hvis ikke men ved
hvad der er kilder og dræn kunne floyed have fordele.
men hvis antallet er kilder og dræn er meget lille er dijkstras en fordel.
hvis vi har knuder med fælles kanter, kan vi snakke om noget fra stømning
der hedder snit..
Først afsnit om model a og dens antagelser..
S˚
a skriv - her kommer algortimer til model a
s˚
a skriv løsning til løsning af model a
gentag med b.
gør noget ved alle vores sjuskefejl LAD OS NU FFS F˚
A LÆST LORTET
IGENNEM INDEN VI SENDER! OG hvorfor er der stadig ikke læsevejledning
med ?
samarbejde Vælg evt to til at rette det hele igennem.. hvis der er fejl ligger
det p˚
a dem n˚
ar de har læst igennem og rette.. s˚
a gør vi det igen med to nye.
hvad sker der nu? G˚
ar væk fra skrive nyt og ret fejl.. gør det vi har godt. Vi
skal have rettet igennem for fejl. I det hele.
lavede en ordentlig sammenligning af algortimer. skriv evt i starten af nogle
afsnit, i dette afsnit n˚
ar der st˚
ar G(v,E) er det altid bla bla bla.
evt?
Evaluering.
Marion: vi skal have adfære med ind i det..
man laver jo ikke en krypekælder som nødudgang..
flugtveje skal alts˚
a være naturlige og oplagte..
Userbility, kan vi indrage ogs˚
a selv om vi ikke har et produkt.. men vi kan jo
antage hvis det blev lavet hvad s˚
a? evt flere muligeløsninger..
vi ved en masse.. men ingen struktur..
Snak evt med nogle p˚
a arktektur og design.. bruger de nogle værktøjer? hvorfor nogle ? hvordan gør de? hvad skal et program minimum kunne afhjælpe for
at de ville bruge det?
spørgsm˚
al: Er det noglesinde sket i har designet en bygning og brandmyndighederne har sagt nej. føler i noglesinde det er nødvendigt at g˚
a p˚
a kompromi?
det vil næsten forære os et afsnit at snakke med dem: vi skal snakke om
metode, og hvordan vi har gjort, hvad vi har gjort og med hvem.
inden vi g˚
ar ud, skriv spørgsm˚
alene sender dem til marian/on?? og s˚
a har hun
mulighed for at komme med noget feedback.
A.10
Onsdag 5. Maj
godkendelse af dagsorden
status:
kommentarer: arbejdsfejl: værste fejl er væk,
samme notation over alt,
13
alle 3 algortimer har noget til fælles.. trekantsulighed.. bruges til at ”justere”
afsnit om hvad kompelksitet m˚
aler. man m˚
aler hvormange justeringer man
skal lave.
fix defintion 8, den definere intet. p er testrækkelig for m. hvis man har at
følgende 2 betængelser gælder.
vejen er kantdesjungde:S ?
(n2 )
APSP algortimen input. den skal bruge en vægtet nabomatrix
slet 2 første linjer efter algoritmen floyd.
figur tekst til figur 2 skal rettes. husk kilde.
figur 9, uden varsel hopper vi til eksempel. skriv det er for at deMandagstrere.
man gennemløber floyds en gang. det er en løkke man gennemløber pr knude.
den indereste løkke.
tidskompleksiteten er O(n3 ). hvorfor ? lav samme tegne regnestykke.
3.6 fix. den er ikke meget langsom..
samarbejde:
hvad sker der nu?
eksempler skal fremst˚
a som eksempler.
fixset notation. tilpads afsnit 3 til 1 og 2.
skriv afsnit om kompleksitet. ogs˚
a justering her.. antal justeringer.
indfør justering ind i det.
fixet 3.2.1 den er forkert.
nogle skal læse forst˚
a og rette alt om store O notation.
3.6 skriv om.
3.7 skriv det.
massere af kræft p˚
a kapacitet. nu har vi en algoritme som kan finde korteste
vej fra kilder til dræn. hvordan for man kap ind i det. liste over veje m˚
aske. vælg
den med højest gevinst m˚
aske.
evt.
evaluering
A.11
Torsdag 6. maj
godkendelse af dagsorden
status
kommentarer konteksttualiser vores problem.. hvad kan det faktisk bruges til?
psykologi en god ting. indrag svensk undersøgelse evt udsnit..
usability? hvis det skulle designes, hvordan skulle det s˚
a være.
find arktitekt produkter. analyse, hvad mangler det?
samarbejde
hvad sker der nu?
evt.
evaluering.
14
A.12
Onsdag 12. Maj
godkendelse af dagsorden
status
kommentarer
niveauet er blevet lavere igen.. Store O og tidskompleksitet skal skrives om.
vi blander tidskompleksitet og store o sammen.. 2 forskellige ting..
tidskompleksitet’s analyse af funktioner.. hvad er n? den til bellman-ford er
3
o(n ).
husk at fortælle det er et java program vi laver.
gør afsnittet om vores framework klarer.. vi har kanter s˚
adan her, knuder
s˚
adan her.
vores egen algortime: strømning: godt. egen algoritme: vi vælger magisk k? k
gøre mindre? en algortime skal terminer(stoppe igen).
hvis vi har tidsgrænse. skal man bare finde en vej som er ”kort nok”.
folk ud i flere bølger. k ska vælges determanistisk. evt 1. brug fordfulkason til
at finde strøming, s˚
a dijkstras til at vælge veje.
samarbejde fejlede. inden vi sender noget ud, compiles det, s˚
a læser to det
igennem, og sammenligner noter.
hvad sker der nu? lav et mere struktureret skema over arbejdsopgaver. Store-O
og tidskompleksitet om igen. Precis defination. egen algoritme frameworket skal
struktureres.
evt.
evaluering
A.13
Fredag 14. Mar
godkendelse af dagsorden
status
kommentarer vi mangler end indledning. Marion vil gerne have det hele!(af
projektet) side 5, vi skal huske vores indledning skal vise hvem er m˚
alretter vores
projekt til. det skal flyttes op i indledningen.
vores metode afsnit, hvorfor er det relevant at bruge grafteori.
arkitekt værktøjer op i problem analysen.
cat13 afsnit skal skrives mere konkret.
side 19 finde den optimale flugtvej.. hvorfor? frem for den korteste. ogs˚
a problem analyse
begrundelser ind undervej.
bedre argomenter i afsnit og spørgsm˚
al.
afsnit om hvordan vi bedst f˚
ar noget ud af interviewet.
samarbejde
hvad sker der nu? Tilføjet til listen vi skal have lavet problemformulering
færdig. Fokus p˚
a rødtr˚
ad. Rettet sl˚
afejl.
15
EVt.
Evaluering.
A.14
Torsdag. 20 Maj
Møde med Hans
Egen algoritme: Problemer - evakuerer kilder med størst befolkning først
Anden variant: Start med at finde korteste veje Kør Ford-Fulkersons algoritme
- vælg kun reste veje fra den mængde af veje Bud p˚
a hvor mange der kan evakueres
inden for en tidsgrænse
Fælles kanter - problem Hvordan kan det løses? Maximum Flow
Beskriv to type løsninger og kritiserer dem
A.15
Fredag. 21 maj
godkendelse af dagsorden
status
kommentarer mere kontektst.. mere hvorfor er det her samfund.
evt flyt det om programmerne til lige før interview
breder introduktion, objektiv undersøgelse, flygtveje generelt hvorfor er det
relevant at g˚
a ind allerede i design af bygning og kigge p˚
a det.. hvorfor er vores
problem et samfundsmæssigt problem.
indsnævring skal være afgrænsning
efter hvorfor det relavant at kigge p˚
a design, kan vi skrive om de arktiekt
værktøjer der findes.
det med de 5skriv en afgrænsning om vi kun tager lidt højde for
taksonomi, først eller før literatur listen.
kap 7(interview) længere frem.. skriv om overvejelser om spørgsm˚
alet, i et
metode afsnit
et metode afsnit. evt vi vil prøve at dokumentere problemet via et interview.
meget gerne 12-15 siders kontekst
modeldannelse.. g˚
a ind i brugervenlighed for mere kontekst
samarbejde
hvad sker der nu?
E.v.t.
evaluering
A.16
Samarbejdsaftale
Gruppearbejde: - Vi vil blive bedre til programmering. - ogs˚
a som gruppe. Afmelding ved sygdom. Man skriver p˚
a waven at man er syg eller sender en sms
til to mennesker. - Hvis man sender den til en der er syg, sende denne person
den videre til to andre. - Man skal forsøge at komme til tiden. - Hvis du kommer
16
mere end 15 min forsent skriver man det som nævnt ovenfor. - Hvis fleretallet
er fremmødt, starter arbejdet - Man kan forvente at have weekenden fri - Ellers
skal det planlægges -Møder kan indkaldes til dagen efter n˚
ar mere end halvdelen
er enig. -Gruppearbejde kan forventes 8 til 16 -Gruppen har demokrati
Dagsorden med tidsplan: - Dagsorden med tidsplan hver dag - Status møde
hver mandag - Statusmøde skal have en seperat dagorden - Vi skal have planlægt
pauser - Vi skal sætte tidspunkt for hvorn˚
ar vi regner med at være færdig. - Max
+ en time - Sidste punkt p˚
a dagsordenen bliver at lave dagsorden til dagen efter.
Forelæsninger: - Forelæsning er frivilige - De fremmøde regner opgave regning
- Hvis man ikke kan koncentrer sig, m˚
a man sidde stille for sig selv. Hvis man ikke
kan det m˚
a man finde et andet sted. - Forelæsninger overtrumfer gruppearbejde.
17