-
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)
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).