-
Notifications
You must be signed in to change notification settings - Fork 0
Logbog Gruppe 12
Vi mødtes alle kl 8 på discord og skabte et overblik over hvad dagen skulle gå med. Dernæst påbegyndte vi vores gruppekontrakt på Overleaf, hvortil vi alle lærte basisk syntaks for LaTeX. Efter gruppekontrakten skrev vi vores vejleder kontrakt og dernæst påbegyndte vi vores projektforslag dokument. Dette blev ikke færdiggjort. Det bliver lagt weekenden i det nuværende stadie, hvis nye gode tanker skulle opstå.
- Videre arbejde på nuværende viden i Projektforslag
Vi har arbejdet på problemstilling og motivation, samt skrevet de sidste ting færdig i projektgrundlaget. Forberedelse til vejledermødet. Vi har efter vejledermødet rettet vores problemstilling til, da vi havde fået en bedre forståelse for hvordan den skrives.
Rune Introducerer sig selv som første punkt på vejledermødet. Vejledningsmøder: 14:15-18:00 som en rotation for hvornår man har møde. Mødeindkaldelse: Send dagsorden på mail senest søndag kl. 12. Her sendes materiale, indkaldelse og ordstyrer/referent. Faste punkter: Hvad har vi lavet siden sidst? Hvordan går det i gruppen? Hvad skal laves til næste gang? Ideen: Vi skal finde den del af casen som vi synes er spændende.
Vi læste vores Belbin rapporter, og vi udarbejdede en team-circle og snakkede om gruppens styrker og svagheder. Derefter rettede vi det sidste til på vores projektforslag og sendte det til godkendelse ved vejleder sammen med en invitation til møde tirsdag d.16.
Gruppen har i dag udarbejdet forskellige dele af inceptionsdokumentet. Max og Mikkel har arbejdet på det faglige videns grundlag, hvor de har beskrevet adgangskodesikkerhed og gui. Thomas og Magnus lavede problemtræ, og indledningen på dokumentet. Janik og Alex har udarbejdet use case diagram samt beskrivelse til dette. Vi fortsætter de samme ting fredag.
Sørg for at fagligvidensgrundlag ikke bliver en lang snak, men en kort beskrivelse. Scrum er en del af det fagligevidens grundlag hvor der skal beskrives hvad det er, hvor i metodeafsnittet skal der beskrives hvordan vi bruger Scrum. Han kan lide vores problemformulering <3 :D (den er godkendt). Han kan også godt lide vores projektforslag, og det er godkendt. Han har skrevet til Lone omkring det der med integration til flere systemer. Vores "use cases" er ikke helt use cases, så de skal tilpasses så de bliver mere use cases.
Hvad menes der med: "The prototype must be prepared for one of TV 2’s own consumer Systems, for instance TV 2 Play."? Svaret kommer næste gang
Kære logbog Alle stod op. Kl 7:47 Alex spiste en bolle (uden smør) med pålægschokolade. Kl 7:47-8:05 Max spiste en nutellasandwich bygget af to stykker hvidt toastbrød med et lag nutella imellem. Toppen skorpen er frataget. Janik lavede spejlæg og Thomas lavede kaffe. Mikkel fik ikke spist morgenmad. kl 8:45 Åbner Janik en banan. Kl 8:48 Janik har nu spist bananen Gruppen arbejde videre på inceptionsdokumentet. Der er blevet udarbejdet en mail til vejleder, for at få vurderet dele af vores arbejde. Kærlig hilsen Thomas <3 ;)
skal vi kun igennem elaborationsfasen? (ingen konstruktionsfase) Er vores problemtræ fyldestgørende? (Vedlagt i emailen)
Projektindledningen er blevet færdigudarbejdet. Alle arbejder samme på afsnittet Overordnet kravspecifikation for at få styr på den del. Gruppen har diskuteret hvordan kritisk risici og prioritering skal udarbejdes. Vejledermødet er blevet afholdt (læs referat), hvorfra gruppen kan planlægge fredagens arbejde på baggrund af feedback.
Problemtræ:
Indenfor scopet er det et fint træ. Det er fint til at vise det vi vil arbejde med.
Fagligt vidensgrundlag:
Det tjener os til ære at vi har sat os ind i fagtingene såsom UX og adgangskode sikkerhed. Synes det er okay, at det er der til at vi kan forklare det, men hvis vi mangler plads kan det godt forkortes. UX afsnit er meget snakkende: Man, vil, måske, ønskes. Det er meget talesprog, det gør afsnittet svært.
Referering til kilder er lidt mos.
Vi skal ikke bruge for meget mere tid på det.
Krav afsnit og use case diagram:
Han synes det er en god idé den måde vi har opstillet det på, det giver god mening.
Vi bør have alle brugsmønstrene på diagrammet. Tænk over om noget arver noget funktionalitet fra hinanden. Hvis brugsmønstrerne har et komplet overlap, så kan man arve, så fx hvis system admin kan alt det producer kan, så kan man lave en pil der viser det.
F03 & F04: Det er en usecase der hedder 'See credits'. Funktionelle krav kan tit blive til brugsmønstre.
Spørg TV2 om det er meningen at en producer skal kunne noget bestemt såsom at søge efter krediteringer osv.
Alt hvad der kan være en usecase, som også giver mening, bør være en usecase grundet vores scope.
Stil evt. spørgsmål til Lone om det.
Vores moscow skal laves ud fra forskellige faktorer, blandt andet business modellen, risiko vurdering, kan vi det her endnu og hvad er det læringsmæssige udbytte. Fx: Det er make or break for TV2 at hver person er unik. Vi skal ikke tænke på moscow endnu, da vi ikke ved hvad der er vigtigst endnu.
Der er tekniske risici såsom om java kan lave password hashing. Sociale risici såsom at vi som gruppe ikke kan fungere. Den tekniske risici er den risici der er mest "rigtig" som vi skal have mest fokus på.
Afsnit 4 og 5 arbejder sammen, meget kritiske ting, vil have højere prioritet. Ting der kræver en lille google søgning, skal ikke i risici. Det er mere, hvis man er i tvivl om noget reelt kan lade sig gøre og skal undersøges dybere.
Kig lidt på det med mange-til-1 og 1-til-1
Man kan skrive i en lille del i indledningen at alle henvisninger findes i litteraturlisten osv. På en måde som en lille læsevejledning.
Når de snakker om at det skal være forberedt, så skal det være lagdelt og API'en skal være et seperat lag. Hvis vi har lagdelt projektet så er det super.
- Lone har ikke svaret på ovenstående.
Det forventes at vi har lavet spørgsmål til problem domænet. Vi har udvalgt 1 person der skal stille spørgsmålende.
Der blev lavet små ændringer på det faglige vidensgrundlag, og derefter arbejdede alle videre med krav. Her blev nogle krav flyttet fra supplerende krav til brugsmønstermodellen, og der blev tilføjet supplerende funktionelle og ikke-funktionelle krav.
Referat: Der blev arbejdet med kritiske ricisi. Derudover blev der arbejdet videre med krav - hovedsagelig (foreløbig) prioritering af kravene. Derefter var der virksomhedsmøde - referat herfra ligger på overleaf.
Referat: Der blev lavet et gantt-diagram til planlægning, og takeoff og inceptionsfasens opgaver blev skrevet ind. Derefter blev der diskuteret afværgelse at kritiske risici
Gruppen blev opdateret omkring review session, hvortil der blev udvalgt 3 "reviewer" roller, ved brug af lykkehjulet, henholdsvis Alex, Max og Mikkel. Dernæst påbegyndte gruppen at færdiggøre resterende afsnit, herunder beskrivelse af relevante eksisterende løsninger, metode, samt prioritering af kravene. Med dem færdiggjort tog gruppen samlet fat i konklusionen. Til vejledermødet fik vi diskuteret diverse spørgsmål (se resumé), og rundet af ved at rette på diverse detaljer.
Spørgsmål:
-
Scrum-master og product-owner, er det nogle af os, der skal have de roller?
- Gruppemedlemmerne styrer selv hvem der agerer SCRUM-master og product owner. Morten fra TV2 er product owner, men man har også en product owner i projektgruppen, som har en tæt kontakt med kunden, som man kan spørge i stedet for kunden. Vi må kører SCRUM som vi vil. Vi må selv bestemme hvor mange SCRUM-masters vi vil have. Når vi er færdige med projektet, vil vi evaluere på om vi manglede en specifik rolle osv. Vi vil ikke blive slået i hovedet af at kører SCRUM som vi vil, bare at vi kan forklare hvad vi forventer at SCRUM giver os, hvorfor det er smart og hvordan vi vil kører det. Han vil forklare mere detaljeret om SCRUM senere.
-
Resurser afsnit, skal vi da kun lave arbejdstidsindsats for det vi har lavet her i inceptionsfacen eller hele projektet? Der står ikke noget konkret i checklisten.
- Det er for hele projektet. Vi skal planlægge vores ressourcer. Det er ikke et Gant diagram, da et Gant diagram ikke tager ressourcer i betragtning. Gant diagram er en tidsplanlægning. Her skal vi skrive hvor mange timer der bliver brugt per uge, altså forklarer vores ressourcer. Den er fremadrettet. ”Vi har så mange ressourcer til rådighed, så vi forventer at arbejde så meget, og opnå dette”. Vi skal ikke skrive ned hvad vi har lavet. Vi skal skrive ned hvor mange timer vi har tænkt os at bruge på det, og hvad vi forventer at opnå i løbet af den tid.
-
Må vi lave to brugerflader en til producer og en til brugeren
- Ja det må vi godt. Han er ikke sikker på at vi får så meget ud af det. Det er en prototype. Vi skal bare demonstrere det. Der er ingen hindring i at lave to forskellige GUI’s, hvis det giver en værdi. Vi må gøre hvad vi synes er bedst.
-
Er det rigtig, at gruppekontrakt og vejlederkontrakt ikke skal være en del af bilagene - de tæller altså med i de 25 sider, vi maks må skrive?
- Gruppekontrakt og vejlederkontrakt tæller ikke med i de 25 sider. De skal bare med i inceptionsdokumentet, de giver ikke nogen værdi.
-
Metodeafsnit - beskriver vi én metode, eller er det en samling af flere metoder (f.eks. analysemetode og designmetode)
- Det er flere metoder. Hvis i kan flette flere afsnit sammen, så må i godt det. Vi kan gøre det med overskrifter, det synes han er mest overskueligt.
Noter til review Tirsdag 16/03
Man får bare feedback, man skal ikke forsvare dokumentet. Vi går tilbage i vores grupper og kigger på feedbacken vi har fået fra de andre grupper. Vi tager også erfaringen fra at have set de andres dokumenter, og bruger det til at rette vores dokument.
Discord + Zoom
14:15 - 17:30
Reviewers reviewer inceptions dokumenter Producerenter lytter til Review Gruppen gennemgår feedback Gruppen retter i rapporten som muligt
Gruppen satte sig ned før review skulle begynde og snakkede om dagens plan. Som de forskellige reviews blev gennemgået, sad resten af gruppen og rettede eventuelle småfejl på rapport. Der blev spillet Skribbl.io Gruppen gik samlet til review for egen Inceptionsdokument På baggrund af nedskrevet referat gennemgår gruppen dokumentet, alt efter hvad vi føler der reelt set er mangler.
Brugsmønster - login mangler Manage af kredits brugsmønster forvirrende? Kritiske Risici: Mangler nogle “rigtige” kritiske risici Mangler risici vi kan håndtere (Ligesom søgeoptimeringen vi har) Løsning til hvis EPG ikke virker Prioritering: Mange i must have (Hvis man ser på det kun er til første fase) evt. dele det op Er hashing og login vigtigt i første omgang Konklusion Gamle mennesker bruger ikke internettet? Begrundelse til hvorfor det er en grund til der ikke er udviklet løsning. (Burde måske have en anden grund) detaljeret brugsmønster post konditioner: krediter skal godkende krediteringen mere metoder, mindre værktøjer
Referat: Konklussion blev uddybet, brugsmønstermodel rettet til, metodeafsnit rettet til, underspørgsmål til problemformulering, kritiske risici rettet til
Ekstra arbejde for at rette inceptionsdokument til på baggrund af review + korrektur + aflevering af review
Tilstede: Magnus, Janik og Thomas (Resten fik fri, da de havde skrevet reviews og det blev vurderet, at vi ikke alle behøvede at læse korrektur og aflevere.
Referat: Inden mødet var der blevet læst korrektur på inceptionsdokumentet. Til mødet blev det sidste rettet til på baggrund af et sent modtaget review.
We use scrum but: Vi holder kun daily scrum de dage, hvor vi arbejder Vi har ikke nogen product owner / Vi er alle sammen product owners Vi tænker at det er smart, at der er én der er scrum master. Mikkel er blevet valgt til scrum master Vi regner med at holde sprint review og retrospective samtidig
Gruppen har arbejdet med at starte op på elaborationsfasen. (Vi har været tæt på at droppe ud, men ikke just) Dertil er blevet udarbejdet sekvensdiagrammer og operationskontrakter. Der er også blevet udarbejdet analyseklassediagram og påbegyndt et reelt klassediagram. Gruppen har diskuteret fremtidig arbejdsmåde, samt skrevet spørgsmål til vores alle sammens TV-2 Morten.
Gennemgang af, hvad vi har lavet siden sidst. vi er forvirrede... Vi skal bruge det meste af materialet fra inceptionsdokument - Vi må gerne ændre i det Hvor mange diagrammer skal med i rapporten - Brug evt. et brugsmønster fra hver iteration og vis alle artefakter fra dem. Måske nogle ekstra diagrammer, hvis det har en god grund. Vi burde egentlig være i gang med design - Vi skal også gerne have implementeret. Vi skal egentlig have et kørende program, som implementerer udvalgte brugsmønstre fuldt ud. vi indfanger viden i analyse fasen - ingen beslutninger I designfasen der benytter vi den fundne viden til at lave vores system - her tager vi beslutninger Vi skal fokusere på produktet, men vi skal stadig følge analyse-design-implementering
Få opsat design diagrammer Lav 1 sprint beskrivelse Beskriv Sekvensdiagrammer og operationskontrakter
Alle
Sekvensdiagrammer blev blev opdateret, samt retning af analyseklasse diagram til engelsk. Gruppen delte sig op i to, og begyndte henholdsvis at lave design klasse diagram og beskrive allerede opstillede analyse diagrammer.
Skal design explicit være en del af 1 sprint, eller er det en del af planlægningen til sprint 1? skal vi tage hele systemet med i designet i første iteration, eller skal vi undlade ting som søgning, som vi først skal have med i anden iteration?
Alle
Gruppen har skrevet tekst til sekvensdiagrammer og operationskontrakter. Dertil er også blevet rettet småfejl. Klassediagram er blevet udbygget så det implementerer komponentdiagrammet. Gruppen har opstillet design mockups.
Hvad vi har lavet siden sidst Design, klassediagram, state diagram ( til at holde styr på UI ), mockups, komponent diagram over domænelag med subsystemer og interfaces (Tag alle interfaces med hvis vi alle forstår dem, og forstår hvorfor det er en god ide), Lavet et klassediagram på baggrund af komponentdiagram og forrige klassediagram.
Rune mener at arbejdet ser godt ud,
Produktion entitet kunne have et samlet interface som benyttes på alle lag hvor alle entiteter findes. Gør at man kan sende objektet rundt uden at skulle mappe det om, indtil det finder det sted hvor den skal bruges. Hvis vi ikke helt forstår det, skal vi ikke bruge det. Vi skal bare overholde lagdeling.
Fremvisning af mockups Rune: Det ser godt ud. Sørg for at vi får skrevet de overvejelser vi har lavet i hovedrapporten, da der er lagt tid i. Læs op på low fidelity prototyping (For extra credits).
1 iteration skal være færdig den 27 april. Kode og rapport. Der vil komme overordnet feedback på rapporten.
Planlægning for sprint. Rune vil klart ligge planlægning af sprint i rapporten. Ikke en pingpong samtale, men hvilke overvejelser der har lagt grund for planlægning. Hvorfor vi har overbooket, eller underbooket sprintet osv. Forklaringer for hvorfor vi er kommet frem til den planlægning vi er kommet frem til. I logbogen er det mere hvem sagde hvad.
Side 8 metode. Planlægning må gerne skrives under metode, ikke under scrum.
Kunne eventuelt lave en iteration 1 overskrift.
Når der står metode i SDU dokumenter, betyder det videnskabelige metoder. Hvordan har vi tænkt os at arbejde med data, fremgangsmåde. Det fungere godt nok ikke 100 med ingeinører, men det er nu sådan det er.
Der design del af sprint, eller forarbejde? Det er en del af begge iterationer. I elaborations sprint tager OO analyse på brugsmønstre, design på brugsmønstre og implementering på brugsmønstre. Første sprint slutter med at vi afleverer brugsmønstrene i virkende kode. Det forventes at et sprint kan starte med analyse, design og implementation. Delivery burde være klar til kunden. (Selvfølgelig ikke forventet vi på 2 semester gør det 100).
Komponentdiagram, skal hele systemet med fra starten, eller skal det kun være de dele vi implementerer i sprinten? Rune: Vent med at sætte subsystemer ind på diagrammer til de skal laves i sprintet.
Hvad skal vi lave til næste gang? IMPLEMENTERING Rapport
Fysisk vejledning: Vi skal beskrive i indkaldelse om vi vil mødes fysisk, og hvis det, skal vi give lokalenummer med.
Implementering
Grundlæggende lagdeling og implementering lavet.
Resume fra vejledning 20/4: Spørgsmål omkring production på præsentationslaget: Må gerne instanteres på præsentationslaget. Skal sendes ned som IPresentation. Problem på persistence lag: må ikke have pege opad, derfor skal der instantieres på data laget. Interfaces bruges så der er klar separering mellem lagene. Domain lager får fylde når vi skal tjekke for passwords og andre tilladelser. Det er ikke sikkert der kommer nogle klasser som skal instantiseres på domainlaget, da den bare sender det videre. Grasp patterns, eller facade er godt til eksamen. Hvis en constructor tager et interface som parameter er der en afhængighed, dette skal vises på diagrammet. Aflever kode og rapport.
Discord
09:00 - XX:XX
Implementering
Alle
Viderearbejde med implementering. Her blev der først fokuseret på UI, hvor de underliggende lag dernæst blev bundet op på. Da alle ikke kunne sidde og arbejde med dette, satte Janik, Thomas og Max sig ned og skrev rapport, mens Alex, Magnus og Mikkel arbejdede videre med implementering. I rapporten blev sekvensdiagrammer beskrevet, samt begyndelse på beskrivelse af implementering
Gør projekt klar til tirsdags seminar
Alle minus Magnus (Syg)
Implementering er blevet fikset, og diverse småfejl er rettet. Powerpoint er blevet lavet, og der er blevet valgt person som skal fremlægge. Vi blev enige om også at mødes hver mandag, udover store bededag.
Få styr på hvad der skal sige til seminar Hold seminar
Alle til 14, derefter gik Magnus
Der blev udelt roller til powerpointen, som blev fremlagt til seminaret.
Alle
ALT I JAVA SLUT. Der blev arbejdet med databasedesign og sekvensdiagrammer
Skal vi lave analyse igen i denne iteration. (Havde vi lavet for meget analyse i sidste iteration) Rapport - er det bedst kronologisk analyse1-design1-implementering1-analyse2-design2-implementering2 eer kun beskrive det færdige produkt (et af hvert afsnit)
Vejledermøde Diagrammer
Gruppen splittede sig op, hvor Janik og Magnus arbejdede henholdsvis med database design. Alex, Max, Mikkel og Thomas begyndte at lave interfaces baseret på komponentdiagrammet, og tilføje dem til design klassediagrammet.
Kopi af tables for midlertidlig data svar: Kan godt gå hvis i kan forklare at vi har ændringer i en anden tabel, således vi stadig har det gamle data inden det bliver approved (ved oprettelse vil alle informationer selvfølgelig ligge i midlertidligere tabeller).
Vi skal lave et EER diagram (det ligger i kursus beskrivelsen).
Findt vi bruger Hiroku til database ligger i skyen.
Det er en low-fidelity mockup og ikke prototype (godt vi snakkede og fandt ud af det :^)).
Del iterationer op i rapporten
- iteration - analyse, design, implementering
- iteration - analyse, design, implementering Så bliver det kronologisk, hvor man kan starter hver iteration med at beskrive sin prioitering og hvilke brugsmønstre man tager med.
Helst skulle vi fra iteration til iteration tilføje og forbedre analyse klassediagrammet ud fra de brugsmønstre man har valgt i en iteration. Så det vil sige vi skal tage vores lidt for langt udviklet analyse klassediagram fra iteration 1 og tilpasse til hvordan iteration 2 faktisk skal laves ud fra de valgte brugsmønstre.
Vi fik 10 med pil ned for inceptionsdokumentet
Vores valgte grene i problemtræet passer ikke særlig godt til problemformuleringen.
Vi skal lære at holde os til dansk eller engelsk i brugsmønstrerne, altså være ensartet med sproget vi bruger.
Kritisk risici burde have været en tabel. Den "catch all" i kritisk risici er dum at have. Generelt er det afsnit noget af det dårligste. Hvorfor har vi ikke taget brugervenlighed osv. med i kritisk risici. Burde have skrevet en risiko og så beskrevet hvordan vi vil undgå den.
Metode i elaborationsfasen mangler der et afsnit der beskriver hvorfor vi bruger Scrum og UP sammen, men det kom så under projektstyringsmetode. Mangler et afsnit der beskriver hvordan VI bruger Scrum. (Generelt har vi fået bonus point for metodeafsnittet, fordi vi har været gode til at beskrive hvordan vi vil bruge det, så det har talt op i karakteren).
Mangler en opsummering af inceptionsdokumentet. Fx "Har det givet noget til jer for at komme igen?". Normalt vil det ikke høre hjemme en konklusion, men der er ikke andre afsnit hvor man kan placere det i. (dog har det ikke minusset, fordi det ikke er et krav til projektet, men Rune kan godt lide det).
09:00-12:00
Alle
Begyndte og færdiggjorde (næsten) EER diagram. Påbegyndt nyt design klassediagram.
Discord
09:00 - 14:00
Arbejd videre på EER, Tabel diagrammer og Design klasse diagrammer
Alle. Magnus skulle gå i midten af arbejdet men kom tilbage senere.
EER & Tabel diagram
Da Magnus gik var Janik og Max i tvivl om hvad not_viewed tabllen i sql scriptet var til, fordi dette ikke fremgik af tabel diagrammet.
Janik og Max tilføjede not_view til diagrammet og gik ud fra at alle systemadministratorer ikke skulle have deres notifikationer læst.
Det viser sig så at der måske har været tale om fra d. 07-05-2021 at denne tabel ikke skulle være der alligevel, men ikke er fjernet fra scriptet, fordi gruppen åbenbart synes at alle administratorer skal have deres notifikationer læst når én administratorer har set én notifikation. Der står intet overhovedet i loggen for sidste gang så det er ikke til at finde ud af.
Vi besluttede til sidst ved hjælp fra Magnus der er kommet tilbage, at fjerne not_viewed tabllen igen. Spildt arbejde.
Vi har færdiggjort de forskellige diagrammer, fået lavet multiplicitet på EER diagrammet.
Vi har sat diagrammerne ind i rapporten og begyndt at skrive rapport til diagrammerne.
Design klassediagram Alex, Mikkel og Thomas lavede Designdiagrammets interfaces færdigt.
Tek projektrum Ø5-616A-1
10-17
Fortsæt på det vi lavede sidst.
Alle
Mikkel har lavet GUI farmes. Mikkel, Alex og Thomas har lavet associationer og sat interfaces på klassediagrammet. Janik har lavet hele product backloggen i github Janik, Magnus og Max har skrevet en god sjat Rapport og overvejet deres valg.
Anbefales at vi holder os fra arv i DB. Vi skal skrive ned til rapporten hvad det giver os at lave issues og kanban osv i Github etc. Vi skal nok ikke skrive at det både er sprint og product backlog i én. Vores EER fx skal vi helst ikke have som dokumentation men i stedet som en mapping til en grov DB, hvis vi vedligeholder det konstant igennem projektet kan man sige det kan være dokumentation. Det er en god idé at gemme tidligere versioner af diagrammer osv, som man kan bruge i rapporten til at vise hvad man troede til hvad det blev, og det er godt i rapporten. Det er korrekt at vi sådan set har lavet subsystemer igenenm vores klasser i klassediagrammet. Vi vil blive spurgt om hvorfor vi har gjort som vi har gjort i diagrammet i design osv. Vi skal kunne forklare hvad det er at vi ønsker at opnå gennem vores valg. Vi plejer ikke at skulle have sidetal på de første sider, så forside etc tæller ikke med. Nogle gange går det at rapporten er fint. Vi skal sørge for at få vores overvejelser osv i rapporten. Vi skal ikke bruge rapporten til at skrive hvad de forskellige fag termer er fordi det ved censor osv godt. Vi skal fortælle hvordan vi er kommet frem til resultatet. Ved store billeder såso klassediagram kan vi have en ulæselig udgave i bilag, og have det som billede ved siden af og skrive i bilaget at man kan se det i fulde format i den følgene fil etc.
Referat: Der blev lavet GUI frames og der blev arbejdet på userhandling og "credits" og "notifications" pakkerne i persistenslaget
Vi fandt ud af at der var problemer i implementeringen, da gruppen ikke har tænkt på at have sessionsstyring i programmet. Dette er et vigtigt punkt da man skulle kunne finde ud af hvem der er logget ind på nuværende tidspunkt, så man kan få brugernavn osv til log o.lign. Gruppen besluttede her at lave sessionstyringen som en sessionssystem ved i domaine laget, dette skal have en klasse, som indeholder informationer om brugerens session. Gruppen har opdateret diagrammet efterfølgende. Vi diskuterede meget om det skulle ligge i authenticationHandler klassen eller være et seperart system. Gruppen fandt ud af at det gav mest mening at skille tingene fra hinanden, da de ikke som sådan havde noget med hinanden at gøre. Det virker mærkeligt at gøre i vores projekt fordi vi ikke har så mange sessionsinformationer at gemme, men ved tanke om at det var et større system vil dette give mest mening.
Han synes det er korrekt det vi har skrevet til diagrammerne.
- Godt at vi har skrevet baggrunden til vores beslutninger.
- Han kan godt lide hvad vi har skrevet til diagrammerne Første del af afsnittet over ER diagrammet er forvirrende, på side 43
- Hvad menes der med kursiv
- Den måde vi springer imellem dansk og engelsk er lidt sketchy. o Det er svært at gøre det på andre måder.
- Skriv om normalisering. o Skriv om til hvilken grad vi har normaliseret. o Hjælper til eksamen. Begge afsnit er ganske fine. Vi kan løfte yderligere ved at tage disse ændringer med. Analyseklassediagram
- Det er godt at vi forklarer hvorfor at vi har overanalyseret, men i et rigtigt agilt projekt, vil man ikke kunne arbejde forud. Der er kun ros til hvad vi har bedt ham om at gennemgå. Hvis resten af rapporten er sådan, vil den ligge på 10. Behold figurbeskrivelserne i rapporten, og IKKE smid det ned i billag. Øv gruppefremlæggelsen, og forbered jer på hvad i vil snakke om i én til én delen. Lad være med at tage den del af rapporten som man synes er nemmest, da man skal hele rapporten igennem. Det er bedre at tage en del af rapporten, som der er meget kød på, som man kan snakke længe om. Prøv at holde en rød tråd. Sikre dig at du forstår det vigtige, altså det som man SKAL vide som ingeniør. Du skal kunne forklare hvis der er noget i koden som er opsat forkert. Du vil også blive spurgt til ting i rapporten som du ikke har været med til at skrive, da alle skal kunne stå ved hvad de har arbejdet på. Det er mere okay ikke at kunne forklare ting i koden som man ikke har været med til, men man skal kunne forklare ting som er en selvfølge. Kodens kvalitet trækker minimalt ned. Det er mere interessant at høre tankegangen bag det. Når vi reflekterer over gruppens arbejde sammen, så kan man kigge på belbin rollerne, og så om der var noget man kunne have forudset. Hvis gruppen var perfekt, kunne man reflektere over hvordan man har undgået problemer, eller hvad man vil gøre til 3. semester.
Implementering
Alle undtagen Mikkel, som har det dårligt
Fik diskuteret hvorfor søgealgoritmen skal ligge på domæne laget. Dette er grundet at vi henter alle productions op i domæne laget, og vi derfor lige så godt kan sortere i dem der, end at hente en helt ny liste op fra persistenslaget.
Vi har aftalt at vi arbejder med at vi prøver kun at arbejde en til to personer på hvert lag, således at når vi lægger det ind i master oplever vi mindre problemer, og der opstår kun problemer på et lag.
NB: På searchController og manageuserController skal der tjekkes for hvem der er logget ind når man går tilbage så man ikke logger ud.
ProductionHandler - Approval and normal table: Det ønskes ikke at man kan overskrive ændringer der ikke er blevet approved endnu. Der kunne oprettes et check der ser om der ligger en ændring og venter i approval tabellen, og baseret på hvilken bruger der anmoder om dataen, vil den vise den ene eller den anden tabel.
Dagens forløb har været meget smertefuldt, selvmordstanker har været til stedet.
Implementering
Alle
Implementering
Alle
Spørgsmål til næste møde: Hvordan viser man at et interface 'bruger' et andet interface fx i en metode? Der er stiplede linjer og fulde linjer. Oversigt over kildekode, er det bare et billede af pakkerne med klasser, eller hvad indeholder det?
https://drive.google.com/open?id=1aCq0VTihTyleL5MaE52yIiuum3Y9vmNTzZZG1ClJFPU HVAD FANDEN ER DET FOR NOGET OL TING "Project variation for software engineering students "?
Debugging af den samlede implementering Rapportskrivning
Alle
09:00 - 16:00
Videre skrivning på rapport Vejledermøde
Alle tilstede
Stort fokus på rapportskrivning. Gruppen har valgt at dele rapporten op i to dele, iteration 1 og iteration 2, hvor det før var delt op sådan i respektivt design, analyse og implementering. Alex og Thomas har arbejdet med analyse. Janik og Max har arbejdet med implementerings afsnit.
hvad har vi lavet siden sidst: implementering og noget rapport - implementeringen skulle gerne være færdig - det er den også Interfaces : det er dependency inversion og seperated interfaces afhængigheder skal vendes om for at det er dependency inversion vi skal forstå hvad dependency inversion er - vi kan også bare skrive, at vi bruger interfaces til at undgå afhængighed. LAD VÆRE MED AT SKRIVE OM TING VI IKKE KAN FORKLARE - måske censor har skrevet en bog om det ;) Anbefalingen er at holde os til separated interface pattern - forklar at det løser et problem
metode: styrker og svagheder ved resultaterne
Mål skal gerne være målbare
Rune ved ikke hvad vi skal gøre med pilene på vores designklassediagram Det er egentlig ikke så vigtig om noget er en fejl eller ej - de vil helst høre om processen Man laver typisk facader mellem pakker - det er lidt for grov opdeling at lave facader mellem lag Når facade interfacet bare nedarver fra de enkelte interfaces får vi ikke abstraheret væk Så domæne og persistens facaderne burde ikke nedarve fra subsystemernes facaders interfaces Vi kan sende spørgsmål til Rune indtil lørdag
Referat Thomas:
Metode : (bla scrum) Vi skrev hvordan vi havde tænkt os at bruge scrum. Vi skal ikke ændre selve afsnittet. Diskussionen er hvordan gik det med det. Vi gjorde det forskelligt fra hvad vi havde tænkt os at gøre. Metode modsat hvad der sket. Sammenfatter på metoder, og kigger på hvad vi ikke gjorde, og hvad “vi ikke ramte rigtigt”. Også med hvorfor. Processevaluering er puha vi kunne godt have gjort det bedre. Vi kigger tilbage og ser på nogle af udfordringerne og ser hvad vi faktisk skulle have gjort. Ser hvad det kunne have givet os at vi havde gjort det. Hvad ville vi ønske vi ikke have gjort m.m. (hindsigt)
Forskel er at i evalueringen kan man drømme, “bare vi havde…”.
Kopiering fra inceptionsdokument - Skriv i læsevejledning hvilke afsnit vi har smidt ind fra inceptionsdokumentet. Jo mere vi kan kopiere ind, jo bedre har vi ramt. (Hvis det giver mening). “Følgende afsnit er taget fra følgende afsnit fra dette bilag”.
Problemanalyse skal være i indledning.
Formål og mål: Hvor detaljeret skal målene være. Det skal ikke specificeres meget. Laver det så vi kan konkludere på det. Der er en underforståethed om at det skal nås.
Skrivning på Rapport
Alle - Undtagen Max
Rapportskrivning
Alle
Rapportskrivning
Rapportskrivning
Alle
Rapportskrivning