Anbefalt arbeidsplan og Prosjektkrav må leses nøye før dere begynner å løse oppgaven.

Det vil bli foretatt oppdateringer og rettelser av oppgaveteksten i prosjektperioden. Pass derfor på å oppdatere siden ofte, særlig i begynnelsen av perioden.

Oppgavealternativer

Det blir gitt tre alternativer oppgaver:

Alternativ 1: FORSIKRING

Alternativ 2: VIKARBYÅ

Alternativ 3: KULTURHUS

Anbefalt arbeidsplan

Arbeidet med oppgaven kan deles opp i forskjellige faser:

Planleggingsfasen

Denne fasen av arbeidet er svært viktig og har avgjørende betydning kvaliteten på oppgaven og for hvor lang tid dere kommer til å bruke på den. Dersom dere ikke har oversikt over hvordan programmet skal bygges opp før dere går i gang med programmeringen, risikerer dere å "møte veggen" etter en tid og må begynne helt på nytt igjen.

Oppgaven kan løses på mange måter og er ikke så klart spesifisert som de oppgavene dere har arbeidet med tidligere. Dessuten må dere selv velge hvor mye dere vil implementere av det som er nevnt i oppgaven og om dere eventuelt vil ta med noe som ikke er nevnt. Det er viktig at dere avgrenser oppgaven slik at dere kommer i mål med et kjørbart program som har den funksjonalitet som dere eller oppdragsgiver anser som den viktigste. Hvis dere ser muligheter og løsninger som er bedre enn ønskene til oppdragsgiveren, kan dere velge dem under forutsetning av at dere begrunner dem godt. (Dere må jo i så fall overbevise sensor om at dere har valgt en bedre løsning!)

Alle i gruppen deltar i planleggingsfasen. Her må dere diskutere

Legg vekt på å designe et oversiktlig program med en fornuftig datastruktur. Valg av klasser må gjøres ut fra hvilke operasjoner som skal gjøres på datastrukturen. (Operasjoner som utføres ofte bør prioriteres med hensyn til effektivitet foran de som utføres sjeldent.) Samtidig bør dobbeltlagring av data i størst mulig grad unngås.

Det er viktig at rekkefølgen av del-oppgavene prioriteres riktig i tilfelle dere ikke blir ferdig. I så fall gjelder det å sette strek i tide, slik at dere får levert et kjørbart program, der de viktigste operasjonene lar seg utføre.

NB! Under planleggingsfasen er det lurt å samle stoff til dokumentasjonen. Bl.a. vil noen av figurerene/diagrammene fra planleggingsfasen kunne inngå som en del av dokumentasjonen.

Planleggingsfasen skal resultere i en kravspesifikasjon som skal leveres i uke 16.

Implementeringsfasen

Når planleggingen er ferdig, kan implementeringen av datastrukturen begynne. Også i denne fasen av arbeidet er det viktig at alle i gruppa arbeider sammen. Start med å implementere registreringsmetodene. Ved hjelp av utskriftsmetoder kan dere kontrollere at innsettingen av objekter i datastrukturen fungerer som den skal. Først når dette fungerer, og ikke før, kan dere gå videre til neste fase.

Når dere er kommet så langt at dere har et kjørbart program der alle dataene lar seg lagre i en passende datastruktur, er tida inne for å implementere resten av operasjonene. Disse kan fordeles mellom gruppas medlemmer og implementeres hver for seg. Men husk at når dere skal sette programmet sammen, må dere legge inn metodene for én operasjon om gangen, slik at dere får testet ut hver operasjon for seg.

Dokumentasjonsfasen

Programmet skal dokumenteres (jfr. Uke 21: Prosjektoppgaven, punkt 2 og 3). Innholdet av dokumentasjonen må gruppa diskutere sammen. Sørg for at det blir avsatt nok tid til denne delen av oppgaven, da den har betydning for karakteren får, spesielt hvis dere befinner dere i en vippeposisjon.

PROSJEKTKRAV

Gruppearbeid

Prosjektet skal løses av en gruppe på 2 eller 3 studenter og gruppen leverer en felles løsning. Alle gruppemedlemmene må har bestått arbeidskravene i kurset. Studentene velger selv gruppeinndeling. (Grupper med bare én student tillates normalt ikke!) Programmeringsarbeidet skal fordeles så likt som mulig mellom gruppens medlemmer. Alle må programmere!

Faglig innhold

Programmet skal følge regler for objektorientert programmering og synliggjøre at gruppenmedlemmene har tilegnet seg pensum i kurset, herunder:

Rammebetingelser

Kommentarer i programmet

Det skal være kommentarer i programmet. Skriv kommentarer etter følgende retningslinjer:

  1. Øverst på hver fil skal det stå en kort oversikt over hva filen inneholder, hvem som har laget filen og når den (siste versjonen) ble skrevet.

  2. Foran hver klassedefinisjon skal det stå en kort forklaring på hva som er hensikten med klassen.

  3. Foran hver metodesignatur (eller rett etter på samme linje dersom det er nok plass) skal det stå en kort kommentar om hva metoden gjør og hva parametrene står for. Eventuelle andre ting som en bruker av metoden bør kjenne til skal også stå (f.eks. hvilke forutsetninger som må være oppfylt eller hvilke typer feil som kan oppstå). Metodene bør listes opp i en fornuftig rekkefølge.

  4. Det skal stå kommentarer i programkoden dersom koden inneholder konstruksjoner som ikke er selvforklarende. En lang kommentar (mér enn én linje) skal rammes inn med /* ... */, mens kommentarer som får plass på én linje starter med //... .

De som ønsker det, kan skrive kommentarer etter Javadoc-standarden og generere Javadoc-dokumentasjon for kildekoden. Men dette er ikke noe krav. I tilfelle dere velger å generere Javadoc-dokumentasjon, så er det ikke nødvendig at denne skrives ut på papir. Det er tilstrekkelig at den leveres på fil, se beskrivelsen av hva som skal leveres.

Kommentarer i programmet og eventuell Javadoc-dokumentasjon er imidlertid ikke tilstrekkelig til å dokumentere oppbyggingen av selve datastrukturen. Til dette formål er figurer bedre egnet.

Like viktig som kommentarer er bruk av innrykk og tilstrekkelig med "luft", slik at programkoden blir oversiktlig og lettlest. Slutten (}) på en blokk bør være på samme vertikale linje som begynnelsen på den konstruksjonen den avslutter. Eksempel: 

		 while ( ... ) {
		   ...
		 }

eller 

		 while ( ... )
		 {
		   ...
		 }

Det letter også oversikten at større blokker avsluttes med kommentarer av typen 

		     } // end of while
		 } // end of class < Klassenavn >

Hva skal leveres?

Uke 16: Kravspesifikasjon

(sendes på mail til evav@hioa.no)

En kravspesifikasjon skal inneholde en beskrivelse hvilke krav det settes til programmet og hvordan dere skal oppfylle dem:

Prosjektgruppene blir registrert i forbindelse med innlevering av kravspesifikasjonen. Den må derfor inneholde opplysninger om gruppedeltagerne (navn, studentnummer, linje og klasse).

Uke 21: Prosjektoppgaven

  1. Programkode som gjør det mulig for sensor (og faglærer) å utprøve (prøvekjøre) programmet. Dette skal være i form av en minnepinne eller en CD som inneholder alle filene som inngår i prosjektet. Minnepinnen/CD-en skal inneholde en kjørbar jar-fil som kan brukes til å starte opp programmet. (Hvordan dette kan gjøres, er forklart i notatet Distribuering av javaprogrammer. ) Test det ut før du leverer, slik at du er sikker på at det virker som det skal! NB! Minnepinnen/CD-en skal også inneholde alle java-filene til programmet.
    NB! Det skal være lagt inn data i systemet, slik at det er lett å teste ut hvordan programmet virker i praktisk bruk.
    Husk å sette tydelige og fullstendige navn og studentnummer på minnepinne/CD (og selvfølgelig på selve prosjektdokumentasjonen) som dere leverer inn.

  2. En produktdokumentasjon som beskriver hvordan systemet (programmet) er bygget opp og hvordan ting virker sammen. Dette "dokumentet" er til for den som vil sette seg inn i systemet, f.eks. for å kunne vedlikeholde det, videreutvikle det, endre det, eller evaluere det ved sensur! Legg ved utskrift av alle skjembildene her. Dere bør derfor ha med figurer som illustrerer hvordan datastrukturen og eventuelle klassehierarkier er bygget opp. Hvis dere ikke har rukket å innfri alle ønskene oppdragsgiveren har til programmet, må dere her skrive noe om hvilken funksjonalitet dere har prioritert og hvorfor, og hva som bør gjøres videre med programmet slik at andre programmerere kan fortsette der dere slapp. Har dere derimot lagt inn funksjonalitet utover oppdragsgiverens ønsker, bør dere også skrive noe om det. Ta utgangspunkt i kravspesifikasjonen dere leverte i uke 16 og oppdater denne. Hvis dere gjorde et grundig arbeid da, er mye av arbeidet gjort.

  3. En kort prosessdokumentasjon som beskriver gruppens arbeid, hvilke valg som er gjort og hvorfor det ble valgt nettopp slik, samt eventuelle andre ting som kan være av interesse for den som skal vurdere den delen av gruppens arbeid som ikke er synlig gjennom den øvrige dokumentasjon. Det skal gå fram av dokumentasjonen hvem som har gjort hva av prosjektets forskjellige deler.

Den skriftlige dokumentasjonen kan godt leveres i et "hefte". Legg vekt på å skrive kort og presist. Det er ikke et mål å skrive mest mulig, men få med dere punktene over! Husk at dere skal "selge" produktet til sensor!

Hva blir det lagt vekt på ved sensur?

Det vil være mulig å få topp-karakter uten at alle ønsker fra oppdragsgiveren er implementert, under forutsetning av at prioriteringene dere har gjort er fornuftige og at programmet lett kan utvides på et seinere tidspunkt. Ved karaktersetting vil imidlertid omfanget av det som er gjort bli vurdert i forhold til antall studenter i gruppa som har utført arbeidet. I de tilfeller der dokumentasjonen ikke gir tilstrekkelig informasjon kan gruppen bli bedt om å gi sensor en muntlig redegjørelse/presentasjon av programmet før endelig karakter settes.

Karakterbeskrivelser

Ved karakterfastsettelsen er det Universitets- og høgskolerådets generelle, kvalitative beskrivelser av karakterene som vil bli lagt til grunn. Beskrivelsene er som følger:

Symbol Betegnelse Generell, kvalitativ beskrivelse av vurderingskriterier
A Fremragende Fremragende prestasjon som klart utmerker seg. Viser stor grad av selvstendighet.
B Meget god Meget god prestasjon som ligger over gjennomsnittet. Viser evne til selvstendighet.
C God Gjennomsnittlig prestasjon som er tilfredsstillende på de fleste områder.
D Nokså god Prestasjon under gjennomsnittet, med en del vesentlige mangler.
E Tilstrekkelig Prestasjon som tilfredsstiller minimumskravene, men heller ikke mer.
F Ikke bestått Prestasjon som ikke tilfredsstiller minimumskravene (hvis det i det hele tatt er nødvendig med noen beskrivelse her).

Obs: Dere får ikke besvarelsen tilbake. Den vil bli arkivert i likhet med vanlige eksamensoppgaver.