InstallAnywhere

Figur 4.22: Installasjonsprogram laget av InstallAnywhere

For å installere ICC3D har vi valgt å bruke installAnywhere. Dette er et program som ligger fritt til nedlasting på nettet, og gir oss muligheten til enkelt å lage et installasjon- sprogram for programmet. Dette er Java basert, og derfor er den lik for både Linux og

Windows versjonen. Dette krever selvfølgelig at du har Java installert på forhånd, så det er viktig at du gjør ting i riktig rekkefølge under installasjonen. InstallAnywhere pakken kjøres fra vårt eget install program.

Kapittel 5

Testing / kvalitetssikring

5.1

For at man skal ende opp med et stabilt produkt som oppfører seg som forventet, er det viktig at man foretar testing og kvalitetssikring gjennom hele utviklingsprosessen.

Dette er spesielt nødvendig i et komplekst systemutviklingsprosjekt som baserer seg på vanskelige algoritmer og inneholder mye funksjonalitet, slik som i vårt tilfelle. Dersom man gjennomfører testing kontinuerlig fra man begynner implementeringen til man er ferdig, reduserer man risikoen for å få et resultat som er preget av bugs og kode som ikke håndterer ulike unntakstilfeller som kan dukke opp en gang iblant, samtidig som det tillater optimalisering av kode i alle faser av prosjektet, ikke kun rett før prosjektets slutt.

Ekstremprogrammering erkjenner denne problemstillingen, og gir en helhetlig løsning som dekker de fleste aspekter ved systemutviklingen.

Fortløpende realisering av nye versjoner med små mellomrom sørger for at prob- lem blir oppdaget så raskt som mulig, og lar utviklerne ta tak i problemet før det påvirker andre elementer i applikasjonen.

Kravet om at man hele tiden skal satse på et enkelt design såfremt dette er mulig, minsker muligheten for at deler av programmets kode kan bli tungrodd etter hvert som applikasjonen utvides. Dersom man når man skal legge til funksjonalitet ser at man kunne forenklet måten noe gjennomføres på, kreves det at man rydder opp i koden. Ved å benytte en viss andel av tiden til å foreta slike reorganiseringer, ender man opp med et bedre resultat som er mindre utsatt for bugs som oppstår grunnet misforståelser.

Alle nye deler av programmet skal implementeres og testes utenfor selve app- likasjonen før de inkluderes i resten av koden. Vi fant at dette ga mange fordeler med tanke på oppdaging av småfeil eller potensielle problemer ved de forskjel- lige algoritmene vi implementerte. For grundig uttesting av koden for Quick Hull, alpha shapes og Delaunaytrianguleringer lagde vi en klasse som kunne kon- struere punkter med forskjellige tilfeldige fordelinger som følger et visst møn- ster, for eksempel punkter på overflaten til en kule. Dermed var det enkelt å gi

tilfeldig inputdata til algoritmene, samtidig som initialisering av generatoren som lager tilfeldige tall sørget for at vi kunne gjenta det samme forsøket flere ganger.

Dermed var det enklere å optimalisere koden ved eksperimentering, fordi tid- takning av operasjoner var direkte sammenlignbare, noe det ikke ville vært med forskjellige tallverdier hver gang man kjørte testprogrammet.

Vår erfaring var at parprogrammering medførte at sannsynligheten for bugs min- ket temmelig drastisk, da det ofte hendte at den personen som ikke benyttet tastaturet oppdaget feil mens de ble skrevet, i motsetning til å måtte foreta en kompiler-test-fiks syklus som er vanlig ved andre typer programmering. Det at to personer samarbeidet om å skrive en funksjon, førte også i flere tilfeller til en bedre implementasjon enn hva man ville fått dersom de arbeidet hver for seg, siden vi kunne foreslå forskjellige innfallsvinkler på problemene og diskutere oss frem til en løsning.

Kunden, i vårt tilfelle oppdragsgiver og veileder, fungerte som betatestere for vår applikasjon. De var meget aktive og hjelpsomme, og kom stadig med innspill om feil og forbedringer som vi deretter forsøkte å ta hensyn til i den videre utviklingen av produktet.

Automatiserte tester ble gjennomført for flere deler av applikasjonen. Vi kodet en test for ulike fargerom, som fungerer ved at farger spredt utover hele farg- erommet ble konvertert til og fra XYZ. Dersom verdiene man får etter å ha utført disse to konverteringene er forskjellige fra de opprinnelige verdiene (distansen i 3D er større enn en valgt lengde), betyr dette at fargerommets konverteringsruti- ner ikke fungerer som de skal. Tetraederstrukturen som bygges av flipalgoritmen og segment maxima visualiseringen blir testet for å se om alle tetraedernene er konvekse, samt at nabolinkene er korrekt plassert. Denne testen avslørte flere problemer ved segment maxima, som verken vi eller oppdragsgiver/veileder var klar over, men som vi etterpå kunne løse. I løpet av utviklingsfasen benyttet vi mange andre tester lagt inn i koden, som sørget for at vi fikk meldinger dersom det oppstod uventede situasjoner.

Manuell testing i form av aksepteringstester ble foretatt for å forsikre at våre løsninger på brukerhistoriene ellers var i samsvar med spesifikasjonene.

Vi konsentrerte oss om å optimalisere de funksjoner som var mest tidskritiske, og forsøkte å benytte de muligheter som eksisterer i Java på best mulig måte.

Dette ga utslag i blant annet koden som prosesserer bildet, som benytter et BitSet (en lang rekke bits som kan settes til 1/0) og innebygde funksjoner for for rask sortering og binærsøk for å indeksere pikslene. Java er i seg selv ikke beregnet for programmer som krever høy ytelse, men etter optimaliseringen bør stort sett alle operasjoner utføres uten venting som oppfattes som slitsomt for brukeren.