Afleveringsdag!

...af produkt

Inden kl.15:00 skal produktet være afleveret.

Det kræver, at man er fysisk til stede.

Vi skal have det overført på et eksternt ssd, som vi opbevarer frem til prøven (og efter) Afhængig af produktets art aftaler vi individuelt, hvad der skal overføres og hvordan.

Rapporten skal afleveres i morgen (11/4) senest 15:00

Skulle man have opdaget fejl/mangler på produktet, er der mulighed for at aflevere en opdatering inden deadline for rapporten.

FAQ

Hvordan afleverer man rapporten?

Den skal afleveres 

1. 1 stk. på Lectio som pdf på opgaven: "Eksamensprojekt - rapport"

2. 1 stk. i udprintet version

Sørg for at indføje tro og love erklæringen i underskrevet stand. 

Hvordan afleverer man produktet?

Det afhænger lidt af hvilken type produkt, man har lavet. For alle gælder det dog, at det skal afleveres på en måde så skolen kan opbevare og køre det uafhængigt af projektgruppen, der heller ikke har adgang til at ændre på det frem til eksamen. Vi skal bruge produktet i en eksekverbar version samt projektfilerne (hvis nogle sådanne eksisterer). Der skal være en read-me fil med, der instruerer os (og evt. udenforstående) i, hvordan produktet f.eks. skal installeres, gældende systemkrav o.s.v. så man teknisk set vil kunne afprøve produktet

Vi har en ekstern ssd liggende, hvortil hver gruppe overfører produktets digitale komponenter.

Fysiske komponenter opbevarer jeres lærere.

På et tidspunkt inden eksamen vil der blive mulighed for at klargøre sine ting, så de kan køres under prøven.

Skal man have al sin kildekode med i rapporten?

Ja, i det omfang det er muligt. Når man lægger sin kildekode ind som bilag, dokumenterer man til dels også overfor eksterne læsere (f.eks. censor), at man selv har stået for udviklingsarbejdet.  I nogle tilfælde er der tale om meget omfattende programkode. Her kan man prioritere de centrale og principielle dele. I rapportens hovetekst vil det typisk være relevant at uddrage eksempler på de væsentligste operationer, der har betydning for den tekniske løsning - og så henvise til den udfoldede kode i bilagene. Er det helt uoverskueligt i omfang, kan man henvise til GitHub e.l. sted hvor man har adgang til resten af kodearbejdet

Må der indgå komponenter i produktet, man ikke selv har lavet - eller som man selv har fremstillet tidligere?

Ja, MEN på den betingelse, at det tydeligt er angivet, at den del ikke har indgået i jeres projektarbejde i eksamensforløbet og markant afgrænset fra det, jeres projektarbejde reelt har beskæftiget sig med. Alt udefrakommende materiale - om det er fra en selv eller andre (api'er, biblioteker o.l. - skal være angivet som kilde. Er det ikke på plads, risikerer man at få en plagiatsag på halsen).

Må man have noget med til prøven, man har lavet efter afleveringen?

Ja, til prøven må man tage materiale med, der kan understøtte præsentationen. I har selvfølgelig jeres produkt klar til demonstration, men derudover kan der være slides, plancher, handouts, cue-cards o.s.v. Tilføjelser til produktet kan være problematisk, medmindre man meget tydeligt demonstrerer at det er en tilføjelse, der er udarbejdet til ære for præsentationen. Inden prøven sørger vi for at arrangere en "spørgetime", hvor man kan få svar på de sidste praktiske spørgsmål og måske nogle gode tips. Det er også her, man kan klargøre sit produkt og teste at det tekniske kører som det skal i eksamenslokalet (som gerne skulle være MediaLab). 

Skal man op som samlet gruppe?

Ja. Der er afsat 30 minutter pr. elev. For hver elev i gruppen må man fratrække 6 minutter. D.v.s. at for en gruppe på f.eks. 3 personer vil den samlede eksaminationstid være (3x30)min. -(3x6)min. = 72 min. Op til halvdelen af tiden skal gå med jeres præsentation. Resten er uddybende spørgsmål og dialog med eksaminator og evt. censor.

Hvordan bliver projektet bedømt?

I bliver bedømt på, i hvilket omfang jeres præstation lever op til de faglige mål, der er angivet under pkt. 2.1 i læreplanen (pdf)

Eksamenskarakteren - der er individuel - gives ud fra en helhedsvurdering af rapporten, det praktiske arbejde (herunder produkt) samt den mundtlige præsentation/eksamination. Der lægges jf. læreplan vægt på flg.:

 Generelt

̶ evne til at arbejde problemorienteret

̶ evne til at kombinere teori og praktisk arbejde i et projekt

̶ perspektivering til relevante emner inden for teknikfaget

Rapportens form og indhold

̶ bearbejdning af projektets problemstillinger

̶ planlægning og vurdering af projektforløbet

̶ dokumentations- og kommunikationsværdi, herunder overskuelighed, sammenhæng, kildehenvisninger og teknisk dokumentation

̶ fordybelsesgraden

̶ specificerede krav til produktet

̶ en fagligt begrundet argumentation for de foretagne valg

Produktet/procesforløbet

̶ omhu og professionalisme ved fremstilling

̶ kvalitet i forhold til de opstillede krav

̶ argumentation for til- og fravalg

Mundtlig eksamination

̶ den mundtlige præsentation af projektet

̶ redegørelse for de valgte løsninger

̶ demonstration af ejerskab i forhold til projektets indhold

̶ besvarelse af uddybende og supplerende spørgsmål.

Tro og love.docx

Tro og love erklæring, der skal lægges ved rapporten

Teknikfag-A-digitalt-design-og-udvikling-htx-august-2017.pdf

Læreplanen for DDU

Idag har vi 3 moduler, hvor der bør være et målrettet fokus på at nå frem til et tydeligt POC. Jeg kommer rundt til jer i løbet af dagen for at se og diskutere disse op imod de tekniske mål/udfordringer i har identificeret til dette sprint 1 (POC kan fint begtragtes som sprint 1 i processen!).

Sprint 0 og POC

En del grupper er stadig ikke færdige med Sprint 0/forberedelses delen. Fokus er for disse grupper at nå denne del hurtigst muligt, og senest inden næste gang!

Herefter er næste mål POC. Her kan man allerede nu begynde at forholde sig til de hårde krav der er til POC, og hvordan man vil teste for om disse er blevet opfyldt!

Færdiggørelse af "sprint 0"/forberedelse

Sidste gang brugte I tiden på at konkretisere jeres case, hvorved I også gerne skulle være kommet frem til en god afgrænsning af product vision og scope. Jeg kommer rundt og læser/hører om jeres case og tankerne bag i løbet af idag.

Når casen er på plads er det for alvor tid at planlægge og sikre vi kommer godt i mål indenfor den afsatte tid til projektet. Det betyder at I skal have fokus på 'product roadmap' og 'release plan'. I praksis bør dette arbejde munde ud i en sprint plan med datoer for deadlines og færdiggørelse af hhv. POC og MVP. POC bør ligge indenfor den første 3. del af den afsatte tid, og MVP cirka halvvejs. Herefter handler det om at lave de fornødne iterationer med tilhørende forbedringer i de efterfølgende sprints.

Herefter fokus på POC

Når sprint0 (forberedelsesfasen) er gennemført og dokumenteret, bør gruppen sætte fokus på POC. Husk også at vende tilbage med eventuelle ønsker om indkøb til brug for projektet så hurtigt som muligt - det kan nogle gange tage lidt tid at få ting hjem.

Husk også at der sideløbende med arbejdet på POC sagtens fortsat kan researches og indsættes behov/features i gruppens product backlog, til brug for evt. senere implementering. Jo før I når frem til MVP jo hurtigere vil det sjove med produktoptimering komme til jer ;)

Hjælp til udarbejdelse af casen

Herunder har jeg indsat en (inspirations)guide til brug for udviklingen, og den efterfølgende anvendelse af jeres case. Den skal ikke nødvendigvis følges slavisk, men kan hjælpe jer til at overveje de vigtigste ting i forhold til jeres projekt.

1. Definér projektets formål og omfang:

• Problemidentifikation: Casen beskriver et specifikt problem eller en udfordring. Brug casen til at identificere kerneproblemet, som projektet skal løse. Dette hjælper med at definere projektets formål.

• Målsætning: Ud fra casen kan du formulere klare og målbare mål for projektet. Hvad skal projektet opnå? Hvilke resultater forventes?

• Omfangsafgrænsning: Casen hjælper med at afgrænse projektets omfang. Hvad er inden for projektets rammer, og hvad er udenfor? Dette forhindrer "scope creep" og sikrer, at projektet holder sig fokuseret.

2. Identificér eventuelle interessenter og deres behov:

• Interessentanalyse: Casen giver indsigt i de forskellige interessenter, der er involveret i situationen. Identificér/beskriv deres behov, forventninger og potentielle indflydelse på projektet gennem brug af userstories

3. Planlæg ressourcer og tidslinje:

• Ressourcebehov: Casen kan give en indikation af de ressourcer, der er nødvendige for at gennemføre projektet, herunder tid, budget, udstyr og kompetencer.

• Tidslinje: Brug casen til at udvikle en realistisk tidslinje for projektet, herunder vigtige milepæle og deadlines. Husk at POC skal falde tidligt i forløbet, og at første MVP gerne skulle være opnået senest halvvejs i forløbet. Herefter itereres der med efterfølgende sprints.

4. Evaluering og læring:

• Succeskriterier: Casen kan hjælpe med at definere succeskriterier for projektet. Hvordan vil succes blive målt?

• Læringspunkter: Efter projektets afslutning kan casen bruges til at evaluere projektets resultater og identificere læringspunkter, der kan bruges i fremtidige projekter.

Sidste gang fik vi grupperne  på plads, og det er derfor blevet tid til at researche rammerne for det nye projekt, og konkretisere hvad man ønsker at arbejde med, hvilken teori/metode der skal tages fat i, og måske i særdæleshed, hvad gruppen IKKE ønsker at komme nærmere ind på.