2015KomItC16

From rtgkomArkiv
Jump to: navigation, search

Contents

Aflevering af Afsluttende opgave, Gkb 14:59, 17 May 2016 (CEST)[edit]

I dag skal den afsluttende opgave i faget afleveres. Her kommer nogle tips i forbindelse med afleveringen:

  • På Lectio skal du aflevere en .txt fil med link (URL) til din aflevering på dit StudieWeb. Den URL kommer at se ud lidt som her: http://rtgkom.dk/~dit_userID/afsluttende_opgave_2016. Brug ikke DOCX, ODT, PDF, RTF eller andre smarte filformater!
  • På dit StudieWeb skal du aflevere både et produkt og en webbaseret rapport. Der er oprettet en mappe i din html mappe til afleveringen. Den hedder afsluttende_opgave_2016. I det omfang det kan lade sig gøre, så skal du aflevere både produkt og rapport i den mappe. Præsenter afleveringen gerne i en index.html fil i denne mappe og link til den fra jeres opgaveoversigt på jeres StudieWeb.
  • Fysiske produkter skal afleveres i MediaLab i løbet af onsdag d. 18. maj, inden ca. kl. 13:30.
  • Den webbaserede rapport kan frembringes ved manuelt arbejde i plain HTML helt uden CSS, eller med CSS hvis du vil. Men hvis du har begyndt at skrive rapporten i et tekstbehandlingssystem som f.eks. TeXnicCenter, Texmaker, eller med LatTeX direkte i din programeditor, LibreOffice Writer, Apache OpenOffice Writer, Google Drive Docs editor (File - Download as - Web Page) eller i Microsoft Word, -så kan du eksportere til HTML format og aflevere de resulterende filer. Det gøre ikke noget at placering af billeder og tekst måske ændres lidt.
  • Husk, hvis du har arbejdet i en gruppe, at alle gruppens medlemer skal aflevere på sit eget StudieWeb. Det er selvfølgelig det samme produkt og den samme rapport, -helt samme! Men du bestemmer selv hvordan du præsenterer afleveringen på dit StudieWeb.
  • Den plakat, som vi har talt om at lave til at præsentere jeres projekter, kan laves efter afleveringen. Den skal hænges op på en af opslagstavlerne på gangen udenfor MediaLab. Brug nogle billeder og noget af teksten fra rapporten, giv det lidt layout i Inkscape eller Scribus, exporter til PNG format og bruge Posterazor, http://posterazor.sourceforge.net, til at lave en PDF fil bestående af fire stykker A3, stående eller liggende. Send den til udskrivning på en af skolens printere, klip og klistr plakaten samme og hæng den op på C3 gangen! I må gerne lave både flere og større plakater hvis I synes det giver mening for præsentationen af jeres projekt.
  • Opdater gerne informationen om dig eller din gruppe i tabellen hvor grupperne er registreret: http://www.rtgkom.dk/wiki/2015KomItC16#Afsluttende_opgave_-_projektarbejdet_i_gang.2C_Gkb_09:09.2C_26_April_2016_.28CEST.29

Afsluttende opgave - projektarbejdet i gang, Gkb 09:09, 26 April 2016 (CEST)[edit]

I dag registrerer vi projektgrupperne. Log ind i wiki'en og udfyld en række i tabellen nedenfor.

Konflikt når to eller flere editerer samtidig - kan løses med copy+paste eller vha. history-funktionen[edit]

Bemærk at hvis to eller flere editerer samtidig, så spørger wiki'en hvilken version skal være den nyeste. I kan altså vælge at jeres version skal gemmes og blive den "nyeste" version af artiklen, -men det kan de andre også gøre, så det er en god idé at forsøge at give andres ændringer lov at være i fred. En teknik er at tage kopi af det du har skrevet siden sidste "save" og så bruge "Cancel", editere igen og indsætte (paste) dine tilføjelser og forsøge at gemme ("Save page") igen. Hvis den anden person som editerede i artiklen er færdig, så kan du nu gemme dine ændringer uden at der opstår nogen konflikt.

Men alle versioner af artiklerne bliver gemt, så selv om du bruger "Save page" mens andre editerer, så bliver deres og dine ændringer alle gemt i artiklens "history" (View history), og du kan f.eks. løse problemer ved at gå ind på en tidligere version, kopiere indhold og indsætte i den nyeste version. Men det bedste er at vise andre respekt og ikke ændre (ofte fjærne) deres indhold fra artiklen.

Hold: 2015KomItC16 - Afsluttende opgave - registrering af arbejdsgrupper
Udfyld nedenstående skema...
Gruppenr. Gruppemedlemmernes navne Valgt mediekategori Links til afleveringsmapperne Problemformulering Titel Undertitel Afsender Budskab Modtager (målgruppe) Kanal (medie) Effekt hos modtageren Tools
0 Karl Bjarnason Automatisering http://www.rtgkom.dk/~gkb/2013_afsluttende_opgave/ Det problem som jeg vil forsøge at løse i mit projekt er at mange gymnasieelever har svært at forstå betydningen af størrelsen og fortegnet på konstanterne a, b og c i en andengradsligning. Stor eller lille, positiv eller negativ Konstanternes betydning i en andengradsligning Forlaget Virtuel Læring AS Du kan godt lære matematik, du kan lære på egen hånd, ... Gymnasieelever i Danmark Program som formidles over WWW. Bedre kundskaber om andengradsligningen og deraf bedre selvtillid og ... Lazarus (open source efterligning af Delphi!)
1 ,Andreas Johan Bergström
Michael Maurer,
Thomas Alexander Mike Collin Nissen
2 Ludvig Valdemar Krochin Goldschmidt Sørensen Hjemmeside Link til Produkt: Her
Link til dokumentation: (kommer snart)
Link til Github repo: Her
Jeg vil hjælpe mennesker i alle aldre, at lære om ballonens historie samt hvad den bliver brugt til i dag. Lær ballonens historie Lær om ballonens historie gennem en interaktiv hjemmeside Budskabet med hjemmesiden er at lære nysgerrige folk, i alle aldersgrupper om ballonens historie. Min målgruppe skal være interesserede i at lære om ballonens historie og hvad den bliver brugt til i dag. Hjemmeside Effekten af dette produkt er at lære nysgerrige folk mere om ballonens historie, ved at hjemmesiden har en masse fakta samt historie, og udover det skal det være designet på en ”mærkelig” måde. Jekyll, HTML, CSS, Javascript, jQuery, Atom, iTerm, Sketch og Google Chrome
3 Sebastian Samsø Sørensen,
Peter Schmitz Salomonsen,
Lukas Hammerlund Christophersen
Guide Problemet er det at mange 1. års elever ikke kender til at skrive kode i HTML5 og CSS3, dette vil vi gerne Medialab guidance Videoguide til HTML5 og CSS3 Afsenderen er en gruppe af 1. års HTX-elever som gerne vil lave en guide til fremtidige HTX-elever som skal til at lave deres studieweb. Budskabet er at det ikke er ret svært at lære at kode HTML5 og CSS3, så længe du har nogle gode guides til at hjælpe dig i gang, og lære dig det mest basale du skal bruge til at lave en simpel hjemmeside. Målgruppen er 1. års HTX-elever på RTG, som skal bruge en guide til at lære at kode HTML5 og CSS3 for at lave deres studiewebsider i faget kom/it. vi har valgt at lave en videoguide, så vores medie er i form af videoer. vores produkt skal meget gerne have den effekt at hjælpe elever på HTX til at få noget viden omkring kodning til en hjemmeside, så de har noget basis viden til at begynde med. Sublime text 2, Icecream screen recorder.
4 Rasmus Bo Dybdahl,
Oscar Samsø Sørensen,
Magnus Thor Troest
Spil Vi valgte at lave et spil omkring ballonprojektet, fordi det ikke er alle som synes det er sjovt eller spændende at bygge en ballon ud fra formler og ligninger. Derfor laver vi et spil som en sjovere måde at lave sin ballon på, mens du samtidigt lærer. The Quest for the Balloon Ballonfabrikken Lave et sjovt alternativ til ligninger og formler, som kan få eleverne til bedre at holde fokus. Førsteårselever på HTX Spil til computer Dette spil skal kunne hjælpe modtageren med at lære noget matematik og fysik, som fx kan bruges til ballonprojektet.
5 Fornavn Mellemnavn Efternavn,
Fornavn Mellemnavn Efternavn,
Fornavn Mellemnavn Efternavn
6 Jakob Andkjær Poulsgærd,
Mads Paludan,
Mads Østergaard Jørgensen
Boundary Objekt http://www.rtgkom.dk/~madsp15/it_hjemmeside/page_h1/pageh1.html
http://rtgkom.dk/~madsoj15/Kommunikation,It.html
Det kan være svært for folkeskoleelever at sætte sig ind hvad faget kommunikation/it på RTG går ud på, og om det stemmer overens med ens egne forventninger. Medialab Få den fulde oplevelse af medialab RTG At de folkeskoleelever som er i gang med at skulle vælge hvad de vil efter skolen, kan lærer om medialabs funktion og metoden hvorpå vi lærer her, og muligvis inspirere dem til at vælge denne skole over nogle andre. 7-10 klasses folkeskoleelever www.rts.dk De skal opnå en større viden om hvordan medialab’s funktion og kommunikation/it faget på RTG, så de kan tage stilling til om det er et fag de ønsker. Unity
7 Fornavn Mellemnavn Efternavn,
Fornavn Mellemnavn Efternavn,
Fornavn Mellemnavn Efternavn
8 Fornavn Mellemnavn Efternavn,
Fornavn Mellemnavn Efternavn,
Fornavn Mellemnavn Efternavn
9 Fornavn Mellemnavn Efternavn,
Fornavn Mellemnavn Efternavn,
Fornavn Mellemnavn Efternavn
10 Fornavn Mellemnavn Efternavn,
Fornavn Mellemnavn Efternavn,
Fornavn Mellemnavn Efternavn
Hjemmeside
11 Fornavn Mellemnavn Efternavn,
Fornavn Mellemnavn Efternavn,
Fornavn Mellemnavn Efternavn
12 Fornavn Mellemnavn Efternavn,
Fornavn Mellemnavn Efternavn,
Fornavn Mellemnavn Efternavn
13 Fornavn Mellemnavn Efternavn,
Fornavn Mellemnavn Efternavn,
Fornavn Mellemnavn Efternavn
14 Fornavn Mellemnavn Efternavn,
Fornavn Mellemnavn Efternavn,
Fornavn Mellemnavn Efternavn
15 Fornavn Mellemnavn Efternavn,
Fornavn Mellemnavn Efternavn,
Fornavn Mellemnavn Efternavn
16 Fornavn Mellemnavn Efternavn,
Fornavn Mellemnavn Efternavn,
Fornavn Mellemnavn Efternavn
17 Fornavn Mellemnavn Efternavn,
Fornavn Mellemnavn Efternavn,
Fornavn Mellemnavn Efternavn
18 Fornavn Mellemnavn Efternavn,
Fornavn Mellemnavn Efternavn,
Fornavn Mellemnavn Efternavn
19 Fornavn Mellemnavn Efternavn,
Fornavn Mellemnavn Efternavn,
Fornavn Mellemnavn Efternavn
20 Fornavn Mellemnavn Efternavn,
Fornavn Mellemnavn Efternavn,
Fornavn Mellemnavn Efternavn
21 Fornavn Mellemnavn Efternavn,
Fornavn Mellemnavn Efternavn,
Fornavn Mellemnavn Efternavn
22 Fornavn Mellemnavn Efternavn,
Fornavn Mellemnavn Efternavn,
Fornavn Mellemnavn Efternavn
23 Fornavn Mellemnavn Efternavn,
Fornavn Mellemnavn Efternavn,
Fornavn Mellemnavn Efternavn
24 Fornavn Mellemnavn Efternavn,
Fornavn Mellemnavn Efternavn,
Fornavn Mellemnavn Efternavn

Modul 3, fredag 18. marts 2016, Gkb 16:49, 18 March 2016 (CET)[edit]

Arbejdet med skrivning af rapporten og finpudsning af produkterne fortsatte.

Afklaring af forhold i forbindelse med afleveringen[edit]

Afleveringstidspunktet for projektet var i aften kl. 23:30, men det er nu flyttet til den 23. marts kl. 23:30.

Mappen computerspil er oprettet i jeres html mappe. I den skal I aflevere:

  • Rapport og
  • Produkt

Husk at hver enkelt gruppemedlem skal er ansvarlig for afleveringen på sit eget StudieWeb, altså i mappen computerspil. Husk at aflevere produktet både i køre klar form og i en form som gør det muligt at udvikle videre, -hvis det altså er relevant for jeres produktform. F.eks. hvis I har brugt GameMaker til udviklingsarbejdet, så skal I både aflevere en eksekverbar fil, f.eks. en .EXE fil, og en komprimeret fil med hele directory-træet som indeholder jeres udviklingsprojekt.

Lav også en index.html fil til at præsentere afleveringen og link til den fra jeres overordnede præsentation af jeres StudieWeb (altså fra den index.html som ligger i html mappen).

På Lectio aflever du en tekstfil med link til din aflevering på dit StudieWeb, altså til mappen computerspil.

Forslag til indhold i rapporten[edit]

Her er et forslag til hvilket indhold evt. kan være i rapporten.

Bemærk at dette kun er et forslag, I kan og skal selv bestemme hvad I skriver i jeres rapporter.

Se også gerne vores lidt mere udbyggede skabelon for rapporter her: http://rtgkom.dk/wiki/Guide:Projektbeskrivelse_og_rapport

En rapport kan godt være en god rapport, selv om den er opbygget på en helt anden måde!!!

  1. Forside (Titel, undertitel, relevant ILLUSTRATION/BILLED!!!, projektoplæg, klasse, gruppemedlemmernes navne (ALLE!!!), skole, år, projektperiodens start og slut, osv., altså ordentlig ID info for rapporten.)
  2. Problemformulering
  3. Målgruppevalg ()
  4. Kommunikationsplanlægning
    1. Diskussion af Lasswell's fem spørgsmål
    2. Medieplan (lanceringsplan, altså hvor skal målgruppen møde/se produktet eller eventuelle reklamer for det?)
  5. Løsningsforslag(et) (Det rækker med kun at beskrive den løsning på problemet som I har valgt at forsøge at implementere. I behøver altså ikke beskrive alternative løsninger.)
  6. Krav til løsningen
  7. Design
  8. Implementering (sandsynligvis det største afsnit. Her viser I skærmbilleder fra udviklingsarbejdet og forklarer hvordan I brugte udviklingsmiljøet og hvordan I løste de problemer som opstod.)
  9. Test
  10. Konklusion
  11. Bilag (F.eks. kildekoden, hvis den er så omfattende at den ikke let kan præsenteres inde i selve rapportens tekst.)

God påskeferie! Karl

Modul 3, tirsdag 15. marts 2016, Gkb 12:20, 15 March 2016 (CET)[edit]

Plan for modulet[edit]

  1. 12.00 Grupparbejdet fortsætter. Der er fokus på resultater indenfor følgende to områder.
    1. Færdiggørelse af produktet og afprøvning af produktet.
    2. Færdiggørelse af rapporten. Se gerne vores skabelon for rapporter her: http://rtgkom.dk/wiki/Guide:Projektbeskrivelse_og_rapport

Som før, så brug vores systemudviklingsmetode som generel støtte til at skabe struktur i jeres projektarbejde, - den beskrives her: http://www.rtgkom.dk/wiki/MediaLab:_Systemudviklingsmetode

Modul 3, fredag 11. marts 2016, Gkb 12:02, 11 March 2016 (CET)[edit]

Plan for modulet[edit]

  1. 12.00 Plenummøde med fokus afprøvning, altså test af om kravene til produktet er opfyldt.
  2. 12.15 Grupparbejdet fortsætter. Der er fokus på resultater indenfor følgende to områder.
    1. Implementering af krav til produktet.
    2. Dokumentation af afprøvningen af produktet.

Som før, så brug vores systemudviklingsmetode som generel støtte til at skabe struktur i jeres projektarbejde, - den beskrives her: http://www.rtgkom.dk/wiki/MediaLab:_Systemudviklingsmetode

Modul 3, tirsdag 8. marts 2016, Gkb 13:22, 8 March 2016 (CET)[edit]

Plan for modulet[edit]

  1. 12.00 Grupparbejdet fortsætter. Der er fokus på resultater indenfor følgende to områder.
    1. Produktion, altså implementering af krav til produktet.
    2. Dokumentation, altså skrivning af rapporten. Se gerne vores skabelon for en rapport for et projekt hvor vores systemudviklingsmetode er blevet brugt til at strukturere arbejdet. Her er et link til en wikiartikel som indeholder skabelon for projektbeskrivelse (husk at der ikke er noget krav om at I laver sådan en i KomItC) og rapport. Husk også at dette kun er forslag!!!

Som generel støtte til at skabe struktur i jeres projektarbejde se en gang til vores egen systemudviklingsmetode: http://www.rtgkom.dk/wiki/MediaLab:_Systemudviklingsmetode

Modul 3, fredag 4. marts 2016, Gkb 12:00, 4 March 2016 (CET)[edit]

Plan for modulet[edit]

  1. 12:00 Plenummøde
    1. Diskussion om krav og test
    2. Statusrapporter fra arbejdsgrupperne
  2. ca. 12:15 Gruppearbejdet fortsætter.
    1. Skrive user stories (gerne tre) og formulerer krav (gerne tre) til hver user story.
    2. Rapportskirvning
  3. ca. 13:15 Video om krav og test.

Modul 3, tirsdag 1. marts 2016, Gkb 12:00, 1 March 2016 (CET)[edit]

Plan for modulet[edit]

  1. 12:00 Status og feedback i plenum på registrering af projektgrupperne og den kommunikationsmæssige sammenhæng (svar på Lasswells fem spørgsmål).
  2. ca. 12:15 User Stories og formulering af krav.
  3. ca. 12:30 Grupperne skriver user stories og formulerer krav til produktet.
  4. ca. 13:00 Video om krav og test.
  5. ca. 13:15 Plenumdiskussion om karv og test.

Referat af modulet[edit]

Vi startede med at konstatere at vi har seks moduler tilbage indtil projektet skal afsluttes, og at vi således har relativt god tid til at lave to iterationer og træne arbejdet med at dokumentere udviklingsarbejdet i en rapport.

Projektbeskrivelser på 3 år[edit]

Til inspiration og perspektivering så startede vi med at skimme i gennem en projektbeskrivelse som tre 3. års elever er ved at skrive for deres eksamensprojekt i Informationsteknologi B og Programmering C. I eksamensprojekterne i disse fag er projektbeskrivelsen en slags aftale mellem eleverne og skolen om hvilket problem de vil forsøge at løse og på hvilken måde og ved hjælp af hvilke værktøjer. Derfor er det vigtigt at projektbeskrivelsen beskriver tydeligt hvad eleverne vil lave og hvilke værktøjer de tænker sig at anvende.

Omfanget skal være passende, hverken for meget eller for lidt og skolen har ansvar at stille relevant vejledning til rådighed for eleverne. Projektbeskrivelsen var på 6 sider inkl. forside. Rapporten i IT skal være max 20 sider per elev og journalen i Programmering C skal være max 10 sider per elev.

Dette kan ses i relation til at i Kommunikation/IT C skal der udarbejdes en mindre skriftlig rapport for den afsluttende opgave. Der angives ikke noget max eller min antal sider, men ca. ti sider per elev er almindeligt. Når vi nu er i gang med information om den afsluttende opgave, så står der også følgende i bekendtgørelsens bilag for faget:

Den afsluttende opgave består af et kommunikationsprodukt med tilhørende rapport, der dokumenterer elevens teoretiske og praktiske overvejelser med at udforme produktet. Elevens arbejde med den afsluttende opgave skal kunne indgå i grundlaget for den afsluttende standpunktskarakter i faget.

I projektforløbet som vi er i gang med nu, altså Computerspil, træner vi nettop fremstilling af et medieprodukt og skrivning af en rapport. Indholdet i rapporten skal afspejle hvordan I har brugt vores systemudviklingsmetode og modeller for design (model I og model II), samt teori om grafisk design (se kompendiet: XXX) og typografi, farver, kravfangst med User Stories og kravspecifikation og testspecifikation osv. Altså I skal bruge faget sprog og begereber når I skriver rapporten!

Se gerne hele bilaget i bekendtgørelsen for faget her: https://www.retsinformation.dk/forms/r0710.aspx?id=152550#Bil20

Status og feedback i plenum på registrering af projektgrupperne[edit]

Vi diskuterede status på gruppernes registrering i tabellen her i holdets wikiartikel. Vi repeterede kort at vi IKKE kan sige at målgruppen er ALLE og at vi selv normalt ikke er den helt oplagte afsender af budskabet som skal formidles til modtageren. Det giver ofte bedre mening forestille sig at I er producenten og så finde på (opdigte, ja det må I godt) en eller anden anden kontekst (case) hvor f.eks. en organisation, firma eller myndighed er afsender. Modtageren er så brugeren. I faget har samspillet mellem producenten og brugeren stor betydning. Det er således vigtigt at øve anvendelsen af disse begreber og de øvrige kommunikationsbegreber til at beskrive den kommunikationsmæssige sammenhæng som I forestiller jer at jeres medieprodukt skal eksistere i.

Jeg bad de grupper som endnu ikke har registreret sig i tabellen og besvaret Lasswell´s fem spørgsmål om deres projekt, at gøre det nu i dette modul. Ved at anvende vores wiki til denne registrering, så lærer vi at bruge et nyt IT produkt. Det er MediaWiki, https://www.mediawiki.org/wiki/MediaWiki, altså den software som bruges til mange wiki'er på nettet. Wikipedia på https://www.wikipedia.org er en af dem. Ved at bruge wikien til denne opgave, så er I altså ved at opfylde et af kravene i bekendtgørelsens bilag for faget. Vi mangler fortsat et par grupper!!! Gør dette arbejde nu færdigt så snart som muligt!!!

User Stories og formulering af krav[edit]

Jeg tog nu fat hvor vi sluttede sidste gang, hvor jeg introducerede user stories som redskab til at fange krav til vores produkt. Jeg forklarede at en user story normalt ikke rækker alene som vejledning for en udvikler. Han eller hun har behov for mere detaljeret beskrivelse af kravene til produktet som skal være opfyldt til at tilgodese den pågældende user story.

Derfor er der ofte behov for at gå tilbage til brugeren (målgruppen) og høre nærmere hvad han tænkte på når han skrev, eller var med til at skrive user story'en. En user story kan således opfattes som en huskeseddel om at vi skal have en mere uddybende samtale med brugeren.

Denne samtale afslører ofte flere krav til produktet som vi kan skrive op i en liste. Denne liste af krav kaldes for en kravspecifikation. Der kan være flere krav for hver user story. Karvene skal nummereres således at vi let kan henvise til dem i tale og tekst.

For senere at kunne afgøre om disse krav er opfyldt, så skal der skrives en testprocedure for hvert krav. Alle testprocedurerne samles i en liste og de nummereres på sammen måde som kravene i kravspecifikationen, således at man let kan se hvilke testprocedurer hører til hvilket krav. Denne liste kaldes for en testspecifikation. Testprocedurerne skal entydigt angive hvordan en testperson skal gå til værks for at afgøre om kravet er opfyldt. Testpersonen skal så registrere om testprocedurene er bestået eller ikke bestået og evt. skrive en kort forklaring. I vores systemudviklingsmetode, http://www.rtgkom.dk/wiki/MediaLab:_Systemudviklingsmetode, så skal denne test gennemføres som den sidste aktivitet i hver iteration.

Der kan være behov for at definere krav som ikke direkte udløber fra user stories.

Det kan også være nødvendigt at definere hvilke forudsætninger, som f.eks. hvilke datafiler eller udstyr der skal bruges, inden testbrugeren kan påbegynde testen.

Det kan være en god idé at gruppere kravene ved hjælp af den ene eller den anden af vores designmodeller. Altså f.eks. at samle de krav som har mest med det visuelle design at gøre, og dem som har mest med interaktionsdesignet at gøre og dem som har mest med informationsdesignet at gøre. Eller man kan bruge model II som deler designovervejelserne op i estetik, funktion og teknik og økonomi. Se min beskrivelse af vores designmodeller her: http://rtgkom.dk/~gkb/pubdoc/to-designmodeller04.pdf.

Som eksempler på krav som normalt ikke vil udløbe fra en user story nævnede jeg i mit oplæg:

  • krav til kontrast mellem forgrundsfarve og baggrundsfarve for teksten i produktet.
  • krav til valg af skrift, (på engelsk: font), f.eks. en antikva eller en grotesk skrift. Grotesk har ikke de spidse detaljer og er derfor lettere at gengive på computerskærme som har en lavere opløsning (typisk 72 dpi til max ca. 300 dpi) end printere og trykeriernes maskiner (fra ca. 600 dpi til 2400 dpi eller mere?). Antikva skrifter har seriffer og de kommer bedre til udtryk i tryksager. Se gerne i vores grafiske kompendium for mere information om typgrafi. Her er kompendiet: http://rtgkom.dk/~jan/kompendium.pdf.

Det var i fortsættelse af denne diskussion som jeg påpegede at I skal kunne argumentere for de designbeslutninger som I tager for jeres produkter. Det gælder både farver, form, indhold, interaktion, billeder, tekst osv. Og denne argumentation skal selvfølgelig føres vha. fagets sprog som til stor del defineres af vores kommunikationsmodeller, designmodeller, systemudviklingsmetode og i vores kompendium for grafisk design, samt af de værktøjer (f.eks. Inkscape og Gimp) og teknologier (f.eks. HTML og CSS) I har brugt til at lave billeder og jeres StudieWeb.

Grupperne skriver user stories og formulerer krav til produktet[edit]

Kl. 12:37 begyndte arbejdsgrupperne at formulere og nedskrive user stories. Tre, eller to, eller kun en enkelt user story var ok, men grupperne skulle diskutere hvilke krav der skulle stilles til produktet til at sikre at deres user stories kunne opfyldes. Det var ok med f.eks. et enkelt eller to krav per user story.

Der var ikke noget krav om at skrive testprocedure for kravene. Det tager vi næste gang, hvor vi også skal prøve at skrive både user stories og krav ind i en tabel i wikien.

Det var livlig aktivitet og grupperne arbejdede også med andre opgaver i relation til udviklingsarbejdet, som f.eks. at komponere, d.v.s. programmere interaktionslyde og musik vha. Sonic Pi.

Video om krav og test[edit]

Vi sluttede modulet ved kl. ca. 13:20 at se en kort tegnefilm/video med navnet Agile In Practice: StoryCards/User Stories, her er et link til den: https://www.youtube.com/watch?v=LGeDZmrWwsw.

Denne video handler om kravfangst ved hjælp af user stories i agile systemudviklingsmetoder (https://da.wikipedia.org/wiki/Agil_systemudvikling).

Systemudviklingsmetoden SCRUM, som vi så en video om sidste gang, er en af de agile metoder og den bruger også user stories til kravfangst.

Der var ikke tid til plenumdiskussionen om krav og test.

Modul 1, torsdag 18. februar 2016, Gkb 02:05, 18 February 2016 (CET)[edit]

Plan for modulet[edit]

  1. 08:10 Status og feedback i plenum på registrering af projektgrupperne og den kommunikationsmæssige sammenhæng (svar på Lasswells fem spørgsmål). Tabellen som grupperne skal registrere sig i er her: http://rtgkom.dk/wiki/2015KomItC16#Indledende_aktivitet:_Kommunikationsplanl.C3.A6gning_og_Resurseplanl.C3.A6gning.2C_Gkb_08:26.2C_11_February_2016_.28CET.29
  2. ca. 08:30 Gæsteforelæsning: Emil Dichmann fra klasse 1.4 kommer på besøg og viser hvordan han har brugt programmet GanttProject til tidsplanlægning i KomIT og teknologi. Hvis du ikke allerede har installeret programmet, så finder du det her: https://www.ganttproject.biz/,
  3. ca. 08:45 Om krav og test. Oplæg og plenumdiskussion. Se sektionen Kravfangst med User Stories nedenfor, hvor jeg har forsøgt at definere de vigtigste begreber.
  4. ca. 09:00 Arbejde i projektgrupperne fortsætter. Grupperne vælger selv hvilke systemudviklingsaktiviteter de arbejder med, men det er en god idé at nogle af gruppens medlemmer arbejder med
    1. forbedring af kommunikationsplanlægningen og resurseplanen og
    2. skrivning af user stories (forsøg at lave tre).

Kravfangst med User Stories[edit]

En måde at fange krav og fastholde dem er at få brugerne til at skrive korte fortellinger eller historier som beskriver deres forventninger til produktet. Man kalder den slags historier for bruger-fortællinger eller brugerhistorier. På engelsk kaldes begrebet for user story. Her er en anden meget kortere forklaring på user story, hvor der svares på seks centrale spørgsmål om begrebet.

I de agile systemudviklingsmetoder bruges user stories ofte som den primære teknik eller værktøj til at fange og fastholde krav til produket. I SCRUM er det produkt-ejeren, product owner, som har ansvaret at fylde user stories i product backlog listen. Det er så fra denne liste som man vælger hvilken funktionalitet skal inkluderes i næste prototype. Her er et link til en ca. 8 minutter lang tegnefilm på YouTube om SCRUM. Det er faktisk en reklame for et IT firma, men den er sjov og forklare godt hvad SCRUM går ud på.

Det er ikke altid muligt at få de virkelige brugere til at skrive user stories. Ofte må du som udvikler eller producent prøve at sætte dig ind i brugerens situation og forsøge at skrive user storie'en sådan som du tror at det giver mest mening.

En user story skal skrives uden teknsik jargon og den består af tre dele:

  1. Identificering af brugeren (som vi forestiller os at) forteller historien.
  2. Definition af hans ønske om noget som produktet skal gøre for ham når han gør noget ved produktet.
  3. Begrundelse eller forklaring af hvorfor dette er vigtigt for brugeren.

En user story for et læringsprogram, f.eks. et computerspil, som skal hjælpe seks år gamle børn at lære at læse og skrive kunne være:

User story nr. 01:
Som en seks år gammel (aktiv, evt. hyperaktiv?) dreng 
har jeg behov for at spillet giver mig umiddelbar feedback på om jeg har valgt de rigtige bogstaver når jeg skal stave til et ord, 
fordi ellers mister jeg interessen for spillet.

Det kan ofte være nødvendigt at dele en user story op i to eller flere user stories til at afdække dens funktionsmæssige indhold, -altså hvordan den påvirker designet og implementeringen af produktet.

Det kan også være nødvendigt at lave en liste over mere tydelige (entydigt formulerede) krav til produktet, som skal være opfyldt for at den pågældende user story kan implementeres i produktet.

Sådan en liste kaldes for kravspecifikation, og den indeholder altså entydigt formulerede krav. Kravene kan handle om følgende aspekter ved produktet:

  • Brugerfladens udseende og funktioner.
  • Produktets indre logik og opbygning, f.eks. variabler, databaser mm.
  • Tekniske krav som f.eks. krav om produktets evne til at svare hurtigt (svartider).

I vores tilfælde kan det være nødvendigt at definere nogle tekniske krav til stavespillet for den seks år gamle bruger i user story'en ovenfor. Det kunne f.eks. være:

GUI krav til supplering af user story nr. 01:
1. Farven som brugs til at markere kanterne på felterne som bogstaverne skal trækkes til, skal være komplimenterfarven til baggrundsfarven.
2. asdf
3. asdf

Krav til indre design til supplering af user story nr. 01:
1. Hver enkelt af de sprites som brugs til bogstaverne må ikke fylde mere end 10 KB.
2. asdf
3. asdf

Tekniske krav til supplering af user story nr. 01:
1. Når brugeren slipper venstre musetast efter at have trukket et bogstav til et bogstavsfelt, så skal der højst gå et halvt sekund inden han får feedback om hvorvidt det var rigtigt som han gjorde.
2. asdf
3. asdf

Indledende aktivitet: Kommunikationsplanlægning og Resurseplanlægning, Gkb 08:26, 11 February 2016 (CET)[edit]

Hold: 2015KomItC16 - Computerspil - registrering af arbejdsgrupper
Udfyld nedenstående skema...
Gruppenr. Gruppemedlemmernes navne Valgt platform (Web, iOS, Win, ...) Links til afleveringsmapperne Problemformulering Titel Undertitel Afsender Budskab Modtager (målgruppe) Kanal (medie) Effekt hos modtageren Tools
0 Karl Bjarnason Android http://www.rtgkom.dk/~gkb/computerspil/ Det problem som jeg vil forsøge at løse i mit projekt er at mange gymnasieelever har svært at forstå betydningen af størrelsen og fortegnet på konstanterne a, b og c i en andengradsligning. Stor eller lille, positiv eller negativ Konstanternes betydning i en andengradsligning Forlaget Virtuel Læring ApS Du kan godt lære matematik, du kan lære på egen hånd, ... Gymnasieelever i Danmark Android Applikation Bedre kundskaber om andengradsligningen og deraf bedre selvtillid og ... MIT App Inventor, eller Android Studio
1 Andreas Johan Bergström, Frederick Schou, Frederik Lemvig Hansen, Thomas Alexander Mike Collin Nissen Windows http://rtgkom.dk/~brugerID/computerspil/ Hvordan kan vi fremstille et produkt som kan tage fokus væk fra de mange timers klasseundervisning, og over på noget mere tankemæssigt udfoldelse? På hvilke metode skal spillet kreeres og fremstilles, så det fremmer den kreative tankegang, og stadig være lærerigt. The Student Principle Paradox Studenter med jag på i hverdagen Vi vil fremme kreativ udfoldelse, og berolige folkeskoleelever som stresser med lange skoledage Folkeskoleelever med lange skoledage Gratis interaktiv applikation Beroligende, lærerigt men samtidig afslappende og tankevækkende Unity student trial(Gratis mens man studere), og word
2 Mads Jørgensen, Mads Paludan, Piet Gravesen og Peter Schierbech windows http://www.rtgkom.dk/~madsp15/it_hjemmeside/page_g1/pageg1.html Man hører ofte at børn i de små folkeskoleklasser kan have svært ved at koncentrerer sig eller er restløse i timerne, især efter de længere skoledage. Vi vil lave et spil der kan bruges i stedet for normal undervisning, som kan være mere spændende og aktiverne for eleverne. Det kan udfordre eleverne på hukommelse og grammatisk. ABC Labyrinth Learning in a fun way. skoleforeninger. At lære behøves ikke bare at være tavleundervisning eller opgaver, man kan også lære på en sjov og aktiv måde. Skoleelever omkring 0. 1. og 2. klasse. Plakater på skoler, introduktion fra lærer og eventuelt tv reklamer. Læring på en alternativ måde, så man for en lyst til at forsætte med at lære og man kan genvinde koncentrationen. Gamemaker, Gimp og Sonic Pi.
3 Martin Wind, Jakob Poulsgærd, Jannik Nilsen og Michael Kayser Web http://rtgkom.dk/~jakobap15/computerspil/ Vi ser ofte at folk konkurer om at blive den bedste i et spil. Til det har vi lavet et spil som bygger på highscore. SpellWave S.W Studenter i et gruppe projekt Vores budskab er, at give folk chancen for at få afgjort, hvem der er den bedste til spil. Unge mennesker mellem 9-18 Udfordrende og konkurence baseret app. Spilleren får lyst til at slå sin rivals highscore. Unity 5, Blender, Garageband
4 Mathias BT, Mathias EP, Magnus og Rasmus Windows http://rtgkom.dk/~rasmusbd15/computerspil/ Vi vil lave et spil, der kan hjælpe børn med matematik på en sjovere og interaktiv måde. Haj til matematik RMMM studios Lære børn med fx koncentrationsbesvær, at udregne simpel matematik. Børn Gratis program. Lære basisk matematik. Gamemaker Studio
5 Michael M, Kristian, Jens og Oscar Windows http://rtgkom.dk/~brugerID/computerspil/ Børn mangler en sjovere måde at lære på Knowledge Labyrinth Lærer / Skoler At lære børn om diverse fag på en sjov måde fra 2. til 5. årgang Spil Læring på en sjov måde Gamemaker, Sonic pi
6 Nicky Lund,
Lukas H. Christophersen,
Oliver K. Sewohl,
Peter S. Salomonsen,
Sebastian S. Sørensen og
Ludvig V. K. G. Sørensen
http://rtgkom.dk/~brugerID/computerspil/
7 http://rtgkom.dk/~brugerID/computerspil/

Ændret plan, kun et projekt!, 28. januar, gkb[edit]

Vi aftalte ikke at forsøge at gennemføre begge projekter, men nøjes med det ene. Der bliver således bedre tid til arbejdet.

Afleveringsdatoen bliver den 18. marts.

Grupperne kan selv vælge hvilket af de to projekter de ønsker at lave. Hvis nogen er begyndt på Computerens anatomi og egentlig gerne vil lave projektet om computerspillet, så kan gruppen oftest uden nogen større problemer omdefinere produktet således at de kan lave et spil, måske enda et spil i relation til computerens anatomi.

Tekster om kommunikationsteori blev uddelt på papir.

  • 25 spørgsmål - en moderne retorik til planlægning af kommunikation, Jan Krag Jacobsen, kopi af indledningen og den første side i kapitlerne for de fem spørgsmål, som Lasswell stillede.
  • Den nye bollemodel, Bruno Ingemann, 11 sider PDF fil. Se her: http://akira.ruc.dk/~bruno/ingemannkomm/2002_nyebollemodel.pdf

Fortsat arbejde på de to projekter, 21. jan, gkb[edit]

Grupperne afprøvede værktøjer.

Vi diskuterede at alle dele af produkterne, f.eks. lyd og grafik (sprites) skal fremstilles af gruppemedlemmerne. Også musik, hvis man ønsker at inkludere den.

Jeg præciserede at der er et krav om originalitet, men kvaliteten behøver ikke være så stor. Det vigtigste er at I selv laver alle medie-elementerne i jeres produkt. I skal kunne sige at I selv har lavet hele jeres produkt.

For musik så kan vi f.eks. bruge Sonic Pi til at programmere lidt musik og lave .wav filer. Audacity kan bruges både til at rekordere og editere lyd. Man kan også bruge en guitar og helt enkelt rekordere lidt vha. telefonen eller computeren.

Planlægning med et planlægningsprogram, 14. jan, gkb[edit]

MediaLabs systemudviklingsmetode blev nu forklaret lidt nærmere. De syv systemudviklingsaktiviteter og de to delaktiviteter som er defineret for hver enkelt af dem, belv gennemgået. Begreber som prototype, iteration, krav og test, implementering og design blev forklaret med afsæt i beskrivelsen af metoden. Den er her: http://www.rtgkom.dk/wiki/MediaLab:_Systemudviklingsmetode

Den første aktivitet i metoden er den Indledende aktivitet, som består af kommunikationsplanlægning og resurseplanlægning. Og det var disse aktiviteter der var fokus på i resten af modulet.

  • Kommunikationsplanlægning, vha. Lasswell's fem spørgsmål og
  • Resurseplanlægning vha. Gantt Projekct. Vi så hvordan programmet Gantt Project kan bruges til at definere opgaver (task) og tildele resurser og hvordan Gantt-diagrammet vokser frem når vi definerer for hvert enkelt task hvilke task's skal udføres før.

Flere grupper gik selvfølgelig direkte i gang med at afprøve værktøjer til at lave spillet eller medieproduktet, -det er helt ok, men husk at lave skærmbilleder og skrive lidt forklarende tekst, således at I senere kan inkludere en beskrivelse af dette arbejde i rapporten.

Projektarbejde: Computerspil og Computerens anatomi, 7 Januar 2016[edit]

Vi startede arbejdet med de to projekter Computerspil og Computerens anatomi.

  • Der arbejdes i makkerskabsgrupperne.
  • Grupperne kan selv vælge hvilket projekt de vil gennemføre først.
  • Anledningen til at vi kører to projekter på en gang er at så bliver der ikke så mange grupper som på en gang skal låne computere til at åbne, undersøge og fotografere.

Vi gennemgik følgende i et plenummøde:

  • Formålet med projekterne, nemlig at træne planlægning og fremstilling af et medieprodukt og skrivning af rapport om forløbet.
  • At oplæggene kan findes på MediaLab's webserver under Opgaver og oplæg, se her http://rtgkom.dk/wiki/Opgaver
  • Grundlæggende kommunikationsteori med afsæt i Harold Dwight Lasswell's fem spørgsmål og Jan Krag Jacobsen's 25 spørgsmål.
  • RTG MediaLab's systemudviklingsmetode og den tilhørende systemudviklingsmodel, samt skabeloner for projektbeskrivelse og rapport. Systemudviklingsmodellen skal bruges i projekterne til at gøre arbejdet med
    • planlægning,
    • implementering og
    • dokumentation mere målrettet.
  • At systemudviklingsmoetoden også kan bruges til at skabe struktur for eventuel præsentation af projektarbejdet for resten af klassen.
  • At skabelonerne for projektbeskrivelsen og rapporten kun er et tilbud. Der er ikke noget bestemt krav om hvordan rapporten skal skrives. Der er heller ikke noget krav om en selvstændig projektbeskrivelse.