Prosessdokumentasjon

Transkript

1 Prosjekt nr Prosessdokumentasjon Hovedprosjektets tittel Implementering av plugin og utvikling av wizard for Det Norske Veritas Prosjektdeltakere Magnus Strand Nekstad s Jørgen Rønbeck s Dato 20. Mai 2011 Antall sider 17 Intern veileder Steinar Johannesen Oppdragsgiver Det Norske Veritas DNV Software ( Kontaktperson Ole Jan Nekstad 1

2 1. Prosessdokumentasjon 1.1 Forord Denne prosessrapporten forteller om hvordan gruppen har jobbet for å komme frem til det endelige resultatet og produktet. Rapporten er beregnet for sensor, veileder, oppdragsgiver og andre som har interesse av å sette seg inn i våre utfordringer underveis, løsninger på disse og ulike arbeidsmetoder som vi har tatt i bruk i vårt prosjekt. Det blir i rapporten gjort rede for samsvaret mellom sluttproduktet i forhold til hva som ble planlagt i kravspesifikasjonen. Det blir også gjort rede for endringer som er gjort underveis som følge av løsninger på oppståtte problemer i prosjektperioden. Det kreves liten/noenlunde kompetanse til data/programmeringsfaget for å sette seg inn i denne rapporten med tanke på problemer som er oppstått og løsningene vi har kommet frem til. For tilgang til kildekode og live visning av Sesam Showroom vennligst gå til linken: 2

3 2. Innholdsfortegnelse 1. Prosessdokumentasjon Forord Innholdsfortegnelse Innledning Innledning Om bedriften Bakgrunn og mål for prosjektet Rammebetingelser Planleggingsfasen Generelt Fremdriftsplan og arbeidsplan Utviklingsfasen Prosjektfaser Forprosjekt Kompetanse og kunnskap Utvikling og implementasjonsfasen Testing Utfordringer underveis Prosjektets kvalitet Sikkerhet og Fleksibilitet ved utvikling Kravspesifikasjon Generelt Endringer Oppsummering og Konklusjon Oppsummering Ønsker for videreutvikling i fremtiden Hva kunne vært gjort annerledes?

4 3. Innledning 3.1 Innledning Prosjektet skal gjennomføres som hovedprosjekt ved HiO avdeling for Ingeniøravdelingen i samarbeid med Det Norske Veritas og deres software avdeling DNV Software. Oppgaven består av å utvikle et 3d galleri ved hjelp av deres plugin, dette galleriet skal vise 3d-filer av ulike modeller produsert av DNVs programvare. 3D galleriet skal publiseres over DNV s hjemmeside I tillegg til dette skal vi også lage en funksjon for å kunne velge mellom forhåndsbestemte verdier som så skal finne frem til den modell filen som tilhører disse verdiene. Når det er gjort skal det lages en funksjon hvor brukeren skal kunne velge egenbestemte verdier hvor våre sider skal beregne og finne frem til den filen som tilnærmet lik disse verdiene og vise frem filen. Vi vil utvikle systemet vårt ved hjelp av HTML/CSS-kode, JavaScript, PHP og C#. 3.2 Om bedriften DNV (Det Norske Veritas) er en uavhengig stiftelse med det formål å sikre liv, eiendom og miljø. Deres historie går tilbake til 1864, da stiftelsen ble etablert i Norge for å inspisere og vurdere den tekniske tilstanden til norske handelsskip. Siden da, har deres kjernekompetanse vært å identifisere, vurdere og gi råd om hvordan å håndtere risiko. Enten de klassifiserer skip, sertifiserer styringssystemer, eller gi råd om hvordan man best skal vedlikeholde en aldrende oljeplattform, er deres fokus rettet mot pålitelig og ansvarlig forbedring av forretningsdrift. Sesam er markedsleder world wide for styrkeberegninger av offshore faste og flytende konstruksjoner. Beregningene utføres av ledende ingeniørselskaper ved bruk av Sesam som er DNV's kommersielle programvare for styrkeberegninger. Sesam har vært en kommersiell suksess i over 40 år. Tradisjonelt har de hatt sin styrke på analyse av flytende strukturer, men i løpet av de 3 siste årene har de også vunnet markedsandeler for salg av programvare for styrkeberegning av faste installasjoner. 3.3 Bakgrunn og mål for prosjektet Det Norske Veritas er en stor bedrift som er viden kjent i verden, men allikevel er det mange som ikke vet om eller har hørt om DNV og Sesam. Det som er ønskelig med denne bacheloroppgaven er å tilrettelegge en tjeneste som gjør det lettere for Sesam selgere i salgs-situasjoner world wide, samt å promotere Sesam bedre på nett(www) enn det som er dagens situasjon. DNV Software utvikler programvare som skal hjelpe ingeniører til å designe sikre offshore konstruksjoner og fartøy som tilfredsstiller ulike regelkrav avhengig av geografisk lokasjon. I tillegg til dette brukes programvaren til å se hva som skjer ved worst case scenarios eller ved langvarig slitasje og lignende scenarios, slik at man kan forebygge ulykker ved slike tilfeller. Denne typen programvare vil arbeidsgiver gjerne få vist frem til firmaer, både nåværende samarbeidspartnere og fremtidige partnere. DNV har som mål å øke omsetningen av Sesam med mer enn 20% de neste 3 år og et av markedsføringsmidlene for slik promotering vil være leveransen fra denne oppgaven. En attraktiv internett-tjeneste skaper også interesse hos potensielle arbeidstakere; det viser at DNV ikke bare satser på tung teknologi, men også på moderne programmeringsspråk og grafisk design. 4

5 Vår utvikling av 3D galleriet har fulgt en iterativ prosess-model(eller en kontrollert variant av scrum hvor hovedmålet ikke endres underveis) og DNV har hele tiden vært tett involvert i å endre og å prioritere innholdet underveis. Dette har medført at DNV har sett flere nytteverdier av 3D galleriet i forhold til oppstart og har således besluttet at tjenesten skal kalles Sesam Showroom. For å sitere Ole Jan Nekstad Product Manager Sesam: Sesam is a market leader worldwide for strength assessment and sea keeping analysis of marine and offshore structures. To use it as well as to sell it the engineers need to have competence in both how to use our software as well as domain knowledge (to appreciate the challenges within our market segment). In today s situation, many of those who graduate from universities do not have such competence. The benefits of the Sesam Showroom are multiple. First of all it will give young sales personnel an easy and appealing way of showing Sesam s capabilities. Secondly, those who search for information on internet will have a unique opportunity to graphically and in 3D see typical Sesam models and their analysis results no other tools in the world can do this. A unique benefit of Sesam is its support of parametric modeling. The Sesam Showroom allows the unfamiliar audience (as well as younger sales personnel) to easily understand this concept by altering model parameters and immediately see the result again using the plug-in component facilitating for 3D viewing and manipulation. Finally, for those who are existing Sesam users the Sesam Showroom also opens up for download of parametric script files and model view files by this they can modify the script files to their own design needs. We are confident that the Sesam Showroom will be of help in our marketing efforts of Sesam. 3.4 Rammebetingelser Skal være mulig å få tilgang via vanlig internett teknologi. Skal være mest mulig lik DNVs profil og ha look and feel som eksisterende GeniE Snack Pack Skal være dokumentert slik DNVs utviklere kan drive vedlikehold uten domenekunnskap. 3D-Plugin som benyttes skal benyttes er levert av DNVs underleverandør Ceetron 5

6 4. Planleggingsfasen 4.1 Generelt Gruppesammensetning og arbeidsgiver var avklart en god stund før man i det hele tatt skulle få tak i en oppdragsgiver. Dette var veldig positivt for oss for da kunne vi gå rett på samarbeid med arbeidsgiver så vi raskt kunne få planlagt en oppgave hos dem som gagnet både oss og oppdragsgiver fullt ut. I samarbeid med oppdragsgiver DNV og deres kontaktperson Ole Jan Nekstad, kom vi raskt i gang med planlegging av oppgaven og ikke lenge etterpå var prosjektoppgaven snekret ferdig og klar for oss å ta fatt på. Med kravspesifikasjonen i fokus som neste punkt på planen, hadde vi flere samtaler i person, e-post og over telefon slik at vi fikk klare punkter på hvordan funksjonaliteten skulle være. Her fikk vi ganske frie tøyler, men noen ønsker hadde også arbeidsgiver. Disse samtalene ser vi på som utrolig viktige igjennom prosjektperioden, dette er med tanke på at vi vil utfylle de ønsker som arbeidsgiver har. Med andre ord, det kom mye verdifull og lønnsom informasjon ut av disse samtalene. Det Norske Veritas har mye IT/Web/Programmeringskunnskaper, og derfor har vi fått rimelige frie tøyler til hvordan vi vil utvikle slik at vi kommer til en løsning. Et av basiskravene var at det skulle være enkelt og forstå, som for eksempel koden skulle være oversiktlig og variabelnavn skulle ha intuitive navn slik at en utvikler som kanskje skal ta opp dette og videreutvikle dette skal kunne gjøre dette uten å måtte sette seg inn i hele koden. Kontakten med oppdragsgiver var utrolig viktig under planleggingsfasen, her fikk vi avklart mange spørsmål og krav som vi ville ha på papiret for å fjerne noen tvil på hva vi skulle gjøre og hvordan vi skulle gå frem. Dette ble gjort med bra kvalitet og minimaliserte behovet for spørsmål og avklaringer senere i prosjektet, men selvfølgelige dukker det alltid opp spørsmål underveis. Man kan ikke helgardere seg for alle forutsetninger på forhånd, noe som vi opplevde et par ganger. Under planleggingsarbeidet jobbet hele gruppen, med andre ord gruppebesetningen på 2 mann, sammen slik at det skulle være enighet oss imellom på hvordan prosjektet skulle løses og alle kunne stå bak de kravene som gjaldt. Med andre ord, vi skulle begge ha kunnskaper om det DNV satt som krav for utvikling og utførelse av prosjektoppgaven. Vi skulle begge ha kunnskaper om det vi valgte for utviklingsmetoder, dette gjaldt særlig ved benyttelse av ulike programmeringsspråk. Videre i planleggingen ble det tatt utgangspunkt i hvordan vi skulle legge opp de ulike deloppgavene innenfor prosjektoppgaven, her kom vi frem til en løsning hvor vi skulle ha ulike faner for de ulike oppgavene (3D gallery, Predefined Models og Selfdefined Models). Planlegging av ulike programmeringsspråk og utførelse av disse oppgavene ble gjort etter at planen for utførelse av oppgavedelen var fastsatt. 4.2 Fremdriftsplan og arbeidsplan Fremdriftsplanen ble satt opp tidlig i prosjektet for å få en god oversikt på hva vi skulle gjøre når og hvordan det skulle gjøres. Sammen med denne ble det også laget en arbeidsplan som ga oss mer oversikt på et detaljert plan på hva, hvem og hvordan utførelse av ulike delegerte oppgaver i prosjektet. Begge disse dokumentene har blitt brukt aktivt gjennom hele prosjektet, men samtidig har det dukket opp uforutsette hendelser og problemer som har ført til at vi til tider har måttet gå litt ut av de planlagte tidsmålene for hvert punkt i planene. 6

7 5. Utviklingsfasen 5.1 Prosjektfaser Forprosjekt I starten av prosjektet hadde vi mange ideer og tanker på hvordan vi ville løse oppgaven. Vi hadde jo fått avklart at vi hadde en prosjektoppgave hos DNV lenge før noen frist skulle møtes, dette førte jo til at gruppens 2 medlemmer hadde mange tanker om hvordan vi skulle gjøre ting, hva som skulle gjøres, problemer som kunne oppstå ved utførelse og hvordan man skulle hindre eller løse dette. Under forprosjektet ble krav og rammebetingelser fastslått, både de eksterne kravene fra oppdragsgiver og mellom oss i gruppen internt. Kravene fra oppdragsgiver er mer rammebetingelser og ønsker på hvordan oppgaven skal løses, ved funksjonalitet og noe kosmetisk. Mellom oss internt gikk det mye mer grundig inn på funksjonalitet, brukervennlighet og det kosmetiske utseende ved oppgaven slik at en bruker skal ville bruke oppgaven vår. Oppdragsgiver hadde som sagt mest ønsker rundt funksjonalitet og rammekrav, hvordan vi valgte å løse oppgaven rent teknisk var helt opp til oss å velge så lenge det var forståelig for videreutvikling av DNVs egne ansatte. Vi valgte i fellesskap å bruke mye HTML-kode og JavaScript til oppgavene med 3D-gallery og Predefined Models, dette er fordi det ikke var så mye mer som krevdes for å kunne løse disse. I tillegg til dette er plugin koden fra DNV levert av Ceetron skrevet med C# og ASP så dette brukes jo selvsagt på de ulike sidene. Med noe modifisering i koden deres fungerer pluginen etter sånn vi og DNV vil bruke den. Ut ifra at vi har utdanning fra Ingeniør ved Datalinjen har vi kunnskaper innenfor de fleste programmeringsspråk som er tilgjengelig for oss, samt at de språkene vi velger har vi hatt som fag tidligere, bortsett fra PHP som foregår samtidig med prosjektoppgaven. Derfor velger vi å bruke mye PHP i siste oppgave som er Selfdefined Models, dette gjør vi slik at vi skal kunne bruke et nytt språk og vise at vi er allsidige innenfor flere forskjellige programmeringsspråk. PHP og JavaScript var helt nytt for oss på starten av dette semesteret og det er derfor utfordrende og spennende for oss å ta fatt på noe helt nytt. Vi har brukt JavaScript mye for den funksjonelle og kosmetiske delen av oppgaven mens PHP brukes mye i Selfdefined Models for validering av input og for å få frem plugin ved utfyllelse input. Tidlige samtaler med oppdragsgiver gjorde at vi kom frem til at siden skal være intuitiv, det skal være lett å forstå hva man skal gjøre og hvor man skal gå for å komme dit man vil etter hva man vil gjøre. Dette ser vi på som veldig viktig, med tanke på at det skal være tidsbesparende for ansatte ved DNV slik at de skal slippe å bruke unødvendig tid ved og ikke finne frem i oppgaven vår. Derfor må sidene våre lett å forstå slik at en bruker ikke skal legge det fra seg fordi en ikke finner frem. Etter samtaler med oppdragsgiver ble det også klart at de hadde ulike ønsker med tanke på utseendet, vi skulle bruke en eksisterende CSS og utseende som de brukte i flere løsninger de hadde slik at det skulle se mest mulig likt ut. Dette er for at en bruker skal bli vant med et utseende å slippe å måtte lete fram på ulike sider som kanskje ikke er satt opp likt. Dette har vi tatt utgangspunkt i slik at oppgaven vår er lagt til rette for brukeren og slik at det senere skal være enklere å videreutvikle denne oppgaven. 7

8 5.1.2 Kompetanse og kunnskap Ut ifra at vi har tenkt til å ta i bruk PHP, JavaScript, C# og HTML som språk i programmering vår er det mye å sette seg inn i. Vi har hatt mye HTML og C# før ved hjelp av tidligere fag ved HiO. I tillegg til dette så vi muligheten med JavaScript siden vi hadde Java-programmering hele førsteåret ved Ingeniørutdanningen ved HiO, at forståelsen skulle går greit med tanke på at Java ved programmering er bygd opp på samme måte som Java for nettutvikling. Men som sagt, det er mye å sette seg inn i og dette tok vi som våre personlige oppgaver og ved samarbeid og kollektivt ansvar skulle vi klare dette med glans. Verktøy vi har brukt underveis er Visual Studio, Netbeans og Notepad++, der de to sistnevnte er gratis mens Visual Studio tilbys fra skolens studentsider ved samarbeid med Microsoft. For å ha mest mulig kompetanse om de ulike språkene tok vi fatt på gamle skolebøker fra tidligere fag, samt en del tutorials på nett. Samtidig som vi deltok i forelesninger og utførte oppgaver i PHP som er det semesterfaget vi hadde i tillegg til prosjektoppgaven. Ved bruken av de ulike språkene kreves det en viss kompetanse innenfor de ulike områdene, her fant vi ut at begge 2 skulle kunne litt om alt, men samtidig skulle vi utdype oss i språkene fordelt mellom oss, dette ble gjort kollektivt. Det er blitt mye nettressurser underveis i prosjektet, siden internettet er den største leverandøren av informasjon og gir som regel raskest svar på spørsmål en har. Ved implementering av 3D-pluginen kreves det noe C# og ASP.NET kunnskaper, noe som vi hadde tilegnet oss på forhånd ved å ha faget Web-applikasjoner ved Tor Krattebøl som gikk i høstsemesteret før vi gikk løs på prosjektoppgaven. Dette var vi veldig heldig med, med tanke på at vi ikke hadde noen ide om hva vi skulle ha som oppgave da vi valgte dette faget. 8

9 5.1.3 Utvikling og implementasjonsfasen Da vi endelig var ferdig med planleggingsfasen var det på tide å ta fatt på selve utformingen og utviklingen av oppgaven. Før vi kunne gjøre dette måtte ha noen samtaler med vår kontaktperson Ole Jan Nekstad, dette var for at vi skulle få alle ønsker og detaljer på det rene før vi kastet oss ut i utviklingsprosessen. Det endte til slutt opp med at vi kom frem til en løsning som vi alle var fornøyde med utseendemessig, endringer er også gjort i senere tid ved utseende og funksjonalitet da vi da kom på bedre løsninger eller andre uforutsette problemer underveis. Dropdown tabellene som vises i Sesam Showroom, er blitt laget 3 ganger, på 3 forskjellige metoder. Mer om dette senere. Før koding og utvikling ble satt i gang for fullt, ble det diskutert innad i gruppa hvordan vi skulle kunne holde oss oppdatert med de siste utviklede filene når vi begge satt og programmerte på like filer på forskjellig tidspunkt. Med andre ord om vi trengte et revisjonsverktøy for å holde oversikt på ulike versjoner av web siden vår. Dette er egentlig en ganske smart løsning hvis man utvikler programmer, men siden vi ikke utvikler et program avskrev vi dette siden begge gruppemedlemmer bor under samme tak og kommunikasjonen alltid er tilstedet. Dette antok vi var en stor fordel for oss med tanke på at vi ikke hadde problemer med å møtes for å diskutere eller jobbe. En annen grunn til at vi valgte og ikke ha et revisjonsverktøy var at gruppen vår består av kun to medlemmer, derfor var det ikke så mye informasjon som videreformidles til flere forskjellige personer. Dette gjorde det også enklere for oss å fordele oppgavene oss imellom slik at vi begge hadde forskjellig arbeid å holde på med underveis. Vi hadde også et eget eksternt domene hvor vi la ut ulike versjoner etter hvert som vi kom videre i utviklingsprosessen, dette gjorde vi for at DNV og Ole Jan Nekstad kunne følge med på progresjonen underveis. Ved å gjøre dette la vi et større press på oss selv ved at det stadig skulle komme nye utviklingsversjoner siden oppdragsgiver hadde full tilgang til det vi utviklet underveis. Samtidig kom vi frem til at dette var veldig smart av oss med tanke på kontinuerlig tilbakemelding fra oppdragsgiver. Problematikk med felles filer var derfor ikke tilstedet for oss og tiden som ville gått med på å finne og holde styr på filversjoner ble borte og kunne brukes på andre ting. I starten av utviklingsfasen og kodefasen ble det lagt mest vekt på funksjonaliteten som oppdragsgiver var ute etter. Hvordan skulle vi gjøre det med intuitivt? Hva skal vi ta hensyn til for at det skal være oversiktlig og lett å bruke? Dette var spørsmål som ble satt internt i gruppen. Senere kom brukergrensesnitt i andre rekke. Startfasen ble også preget av hvordan vi skulle ta fatt på koden vi hadde fått fra DNV og Ceetron om 3D plugin og implementering av denne. Oppsett og kildekode for å vise denne på nett var skrevet i C#.NET og for at vi skulle få den best mulige funksjonalitet og utseende måtte det flere e-post mellom DNV, Ceetron og oss. Underveis i denne startfasen har funksjonaliteten blitt forbedret i flere versjoner, i tillegg har det oppstått uforutsette problemer underveis, dette gjelder særlig i siste deloppgave som er Selfdefined Models. Med problemer med plugin på dotnet server måtte vi finne en ny løsning, der hvor PHP ble svaret, dette har ført til at det har blitt noen små endringer i kravspesifikasjonen. Mer detaljert om problemer og løsninger kommer lengre ned i dokumentet. Arbeid i oppgaven har blitt fordelt og derfor jobbet med en del hver for oss, for så å samkjøre filene våre for å diskutere videre utvikling på ulike deler i prosjektet. Med tanke på testing som er gjort har det ved slutt av hver deloppgave, vært funksjonalitet og kvalitet som har vært i fokus. Her har det vært ulike løsninger som har blitt utarbeidet hver for oss og så i fellesskap for å bli enige om den beste løsningen. 9

10 5.1.4 Testing Sesam Showroom har vært under grundig testing underveis i utviklingsprosessen, det har blitt testet i avslutningsperioden av hver deloppgave. Før selve Sesam Showroom var påbegynt, ble det avtalt møte hvor vi satt oss ned med kontaktperson fra DNV, Ole Jan Nekstad. Her kom han frem med ulike ideer og ønsker etter hvordan DNV ville ha det og de åpnet også for våre ideer, det ble gitt stort sett frie tøyler underveis så lenge vi oppnådde de ønsker DNV hadde. Etter disse møtene, fikk vi en indikasjon på hva oppdragsgiver var ute etter og hvordan Sesam Showroom burde se ut. For at resultatet for hver deloppgave skulle bli best mulig, ble dette også testet underveis av Ole Jan Nekstad(DNV), Kristina Eckholdt(Student på Husøkonomilinjen ved HiAK) og Mathias Rasmussen(Student på datalinjen ved HiST), noe som har vært utrolig viktig for utviklingsprosessen vår. Både testing fra oppdragsgiver og utenforstående studenter er utrolig viktig, dette er for at vi skal kunne se om Sesam Showroom oppnådde de ønsker vi hadde angående funksjonalitet og hvor lett det var å forstå hvordan en skulle bruke siden. Det ble ikke filmet underveis i testingen, eller ikke et spesifikt testskjema som en bruker skulle gå igjennom. Dette var fordi det ble testet av de samme tre personene ved endt slutt av hver deloppgave, da testing ble gjennomført valgte vi heller å gi testbruker muligheten til å teste på det som gikk an å teste på. Tilbakemelding fra bruker om hver deloppgave ble da mer detaljert og dette gjorde det enklere for oss underveis å endre på en oppgave om gangen, og ikke alle samtidig. Det var ulik tilbakemelding fra de forskjellige testpersonene, siden Ole Jan Nekstad er fra DNV og vet hva de er ute etter, skille denne tilbakemeldingen seg fra de to andre testpersonene og er nok den mest relevante med tanke på at han vet hva DNV vil ha. De to andre testpersonene, Kristina Eckholdt og Mathias Rasmussen har gitt oss tilbakemelding på dette med forståelse, funksjonalitet og at Sesam Showroom skal være lett å bruke, ikke minst forstå. Mer detaljert om testing av deloppgavene kan leses om i testdokumentasjonen. 10

11 5.2 Utfordringer underveis I løpet av prosjektperioden har det oppstått en del utfordringer og problemer som har måttet bli løst underveis. Viktigheten og størrelsene på utfordringene har vært varierende og noen av disse har vært avgjørende for hvordan sluttproduktet har endt opp den dag i dag. Men takket være å ha møtt mange av disse utfordringene underveis, sitter gruppen i dag igjen med større kompetanse enn da vi tok fatt på oppgaven. Noen av utfordringene underveis ser kanskje ut som om de ikke har skapt så store problemer, men er tatt med grunnet at vi tok på oss den utfordringen det ville være å få utviklet produktet slik vi ville ha det. Det er blitt laget en liste over de viktigste og de største utfordringene vi har støtt på og hvordan vi har løst dem Dropdown menyer Det har underveis i utviklingen av 3D gallery blitt laget to ulike dropdown tabeller som skal vise både bilde, tekst og link til forskjellige vtfx-filer. Dette skapte en del problemer med å kjøre vanlige tabeller inne i dropdownen, siden det er så mye ulikt innhold måtte vi bygge opp tabellene på en litt annen måte enn vi vanligvis ville gjort. Grunnen til dette er for at det skulle være både funksjonelt og utseendemessig en smart løsning, dropdownen skulle jo også designes etter designet DNV hadde bestemt at vi skulle følge. Grunnen til at det ble laget to forskjellige på dette tidspunkt var for å finne den beste måten å vise frem innholdet på. Etter hvert som vi laget den første dropdown tabellen fant vi ut at denne ikke holdt mål og var alt for enkel, den holdt rett og slett ikke den standarden vi var ute etter. Herfra valgte vi en ny løsning med bildemeny som en klikket på for å få opp dropdown tabellen, denne var mer etter vårt kaliber, men allikevel ikke helt det vi var ute etter designmessig. Det skulle allikevel vise seg at den endelige dropdown tabellen kom først under utviklingen av Predefined models, neste deloppgave i prosjektet. Her ble bildemenyen designet i Photoshop, flere ganger før vi ble fornøyde med resultatet, det ble opprettet ny CSS-kode for selve droptable funksjonen vi hadde i JavaScriptet for dropdown tabellene. Endelig var vi kommet til en løsning vi og oppdragsgiver var fornøyde med, denne skulle også forme oppgaven vår videre, med tanke på at vi erstattet gammel dropdown i 3D gallery med denne nye. Den ble også implementert i deler i siste del av oppgaven Selfdefined models C#.Net mot PHP og JavaScript - Predefined En større beskrivelse av utfordringene med C# nevnes i neste punkt, men den utfordringen vi møtte her, gjelder mer det designmessige og ikke så mye det funksjonelle. Grunnen til dette er at det kreves en dotnet server for å kunne kjøre C#.Net-programmerte sider(.asp) på nett. Da vi fikk lastet opp den koden vi hadde for Predefined models til C#, ble utseende på sidene våres vridd og ulik content ble satt på andre steder enn det gjorde når vi skrev i HTML som i 3D gallery. Dette gjaldt spesielt med de nyutviklede dropdown tabellene vi hadde kommet frem til i 3D gallery. Ut ifra at vi valgte og ikke redesigne den løsningen vi allerede hadde funnet til dropdown tabellene, var løsningen at vi flyttet oss vekk fra asp sider og gikk tilbake til HTML med JavaScript. Dette problemet oppsto også under utvikling av Selfdefined models, men der valgte vi PHP med JavaScript, les mer om dette i neste punkt. 11

12 5.2.3 C#.Net mot PHP og JavaScript - Selfdefined Dette var kanskje vårt største problem som tok oss omtrent en uke å løse. Ifølge prosjektbeskrivelse og kravspesifikasjon hadde vi tatt utgangspunkt i kunne bruke C#.Net i utvikling av siste del av oppgaven Selfdefined models. Her skulle en bruker kunne skrive inn manuell brukerinput på forskjellige verdier som programmet vårt så skulle kunne beregne hvilke filer vi hadde laget som kom nærmest disse verdiene. Dette skulle så vises frem i plugin vindu, samt at en bruker skulle kunne laste ned scriptfil og vtfx-fil. I utgangspunktet i prosjektplanleggingen virket dette veldig greit, men dette var før vi begynte å ta fatt på denne oppgaven. Problemet oppsto når vi skulle begynne å programmere i C#, vi fant jo ut at vi selvfølgelig måtte ha en dotnet server for å kunne kjøre dette på nett. Her hadde vi et lite problem med at vår server var nede, men denne ble gjenopprettet dagen etterpå, takket være systemansvarlige Tor Krattebøl og Amir Ahmed. Men som sagt, dette var det minste problemet vi støttet på. 3D pluginen krevde at vi hadde full administratortilgang for å kunne hente ut filene vi ville vise, noe som vi absolutt ikke kan få ved HiO siden dette vil før til at vi har tilgang på mer enn våre egne filer. Dette er jo forståelig, men skapte et stort problem for oss. Vi prøvde oss med uttallige måter for å få tilgang til filer uten at det skulle kreves administratortilgang og flere e-post ble sendt frem og tilbake til utvikler av plugin. Uten at det var noe hjelp å få siden de ikke hadde hatt dette problemet, de hadde jo tross alt egne servere med administratorrettigheter. Etter flere dager med knoting, både i C# og JavaScript var vi blitt ganske desperate etter å finne en løsning, da vi kom på det at vi kunne gjøre det igjennom PHP. PHP krevde ikke dotnet server og da var problemet løst, nå var det bare å finne måten vi kunne bruke PHP, JavaScript og C# kode i en og samme løsning. Det å bruke flere språk på en gang var i bunn og grunn et lite problem, løsningen vi kom frem til var at vi kjørte testing på variabler via JavaScript som gjorde det tilgjengelig for PHP delen å gi aksess til de riktige filene ved input, som da ble gjort tilgjengelig ved dropdown meny. Denne menyen igjen brukte C# koden som gjorde det tilgjengelig å åpne riktig vtfx-fil i 3D plugin D Brukerinput for mange filer Så kom vi til delene med validering av brukerinput og uttallige filer som skulle utvikles til Selfdefined models. Selve utviklingen av filene står det mer om i produktdokumentasjonen. Det at en bruker skulle kunne skrive inn flere inputs til hver type case, gjorde at det ble uttallige filer som måtte ha samme inputvariabler for hver case, samtidig som det skulle endres en variabel etter hva en bruker skrev inn. For eksempel hvis vinkel A var 50 og vinkel B var 30 i Kjoint, måtte det også lages filer som var fra vinkel A 30 til 60 og vinkel B 30 til 60, dette var for at vi skulle kunne sjekke og treffe korrekt på den brukerinputen som ble gitt og at valideringen var gitt mellom 30 og 60 grader. Totalt har vi kommet opp i 111 vtfx-filer, 93 script-filer og 73 zip-filer ved validering på to input per case. Hvis vi skulle sjekket på mer enn to input per case ville vi vært oppe langt over tusen filer av hver type for å tilfredsstille validering av brukerinputen. Omfanget av denne valideringen var noe vi ikke kunne ta fatt på, dette var en felles beslutning vi kom frem til sammen med Ole Jan Nekstad og DNV, at løsningen var å sjekke på to input. 12

13 D Plugin støttes kun i Internet Explorer I starten av prosjektfasen ble det tatt forutsetninger for at vi skulle få en 3D plugin som skulle fungere i flere nettlesere, dette gjaldt Internet Explorer, Google Chrome, Mozilla Firefox og Opera. Dessverre har ikke denne forutsetningen gått helt den veien vi ønsket, verken for oss eller DNV. Grunnen til dette er at Ceetron jobber med utvikling av dette og har kun betaversjoner som de ikke vil stå for hvis det skal brukes offisielt. Dette er jo så klart forståelig, men litt synd siden dette var et av våre ønsker for oppgaven, at siden vår skulle fungere i flere nettlesere. CSS-en og dropdown tabellene er laget slik at de skal være like i flere nettlesere, noe som har gjort at vi har brukt en del tid på dette. Dette er jo ikke verdens største problem for oss siden det ikke er vår feil, men heller sett fra DNV sitt ståsted, at de nå får Sesam Showroom som de da må si at en kun kan bruke Internet Explorer foreløpig. Selv om dette er den mest brukte nettleseren innad i DNV er det fortsatt litt kjedelig å ikke kunne ta i bruk dette i andre nettlesere. Men til senere tider er det jo muligheter for videreutvikling hvor de da kanskje har fått en plugin som fungerer i forskjellige nettlesere, da skal det heller ikke være så vanskelig å implementere ny kode i vår kode. Dette ble da vårt hovedfokus, at det skal være lett å se hvor plugin koden er i våre dokumenter. Dette ble gjort slik: <!-- HER FØLGER PLUGIN-KODE!!! --> <!-- The main table containing the component, thumbnails and model info --> <table cellspacing="0" cellpadding="2" width="100%" > <tbody> <tr> <td colspan="4"> <!-- Insert GLview 3D Plug-in --> <!-- Insert GLview 3D Plug-in (Internet Explorer) --> <!--[if IE]> <object border="1" id="glview3dplugin" classid="clsid:d37577a1-960c-11d5-a eb12e8" codebase=" type="application/x-oleobject" width="800" height="500" > <param name="fileurl" value="3dgallery/launching_2arm_new.vtf"> <param name="toolbar" value="on"> <param name="swrendering" value="off"> </object> <![endif]--> <![if!ie]> <object id="glview3dplugin" TYPE=application/vtfx-plugin WIDTH=800 HEIGHT=600> <param name="fileurl" value=""> <param name="toolbar" value="on"> <param name="swrendering" value="off"> <!-- No plugin found --> <b>note:</b> This page requires Microsoft Internet Explorer. </object> <![endif]> </td> </tr> </table> 13

14 5.3 Prosjektets kvalitet Brukervennlighet I gjennom hele prosjektperioden har det vært systematisk arbeid og testing med hver og en av deloppgavene ettersom de er blitt utviklet. Det har både blitt testet ved ferdigstilt versjon og testversjoner underveis, gjennom dette har vi oppnådd et veldig godt resultat og et sluttprodukt som oppfyller de ønsker vi og DNV hadde ved prosjektstart. Målgruppen Sesam Showroom er basert på er kvalifiserte, utdannete mennesker som har kompetanse innenfor data ser vi at vi oppfyller tilfredsstillende krav ved at testpersoner med generelle datakompetanse kan bruke siden vår. Oppdragsgiver er konkurranseutsatt på markedet, de er ikke det eneste firmaet som driver med sertifisering og sikring, og er av den grunn nødt til å tiltrekke seg kunder på flest mulig måter gjennom ulike midler. Internett er som kjent et av de største midlene en kan bruke og er derfor et naturlig sted å promotere seg selv og møte nye kunder. Sesam Showroom er derfor laget sånn vi ser på det, som et sted en kunde kan komme og se hva DNV kan gjøre og litt hva de står for. Dette kan være avgjørende for en kunde, det kan være vektet som skålen til å tippe i DNV sin favør, brukerkvaliteten er med andre ord et tema vi har lagt ned mye arbeid igjennom hele prosjektperioden. Dette er en av grunnene til at våre testpersoner har fått full tilgang til alt som utvikles underveis, slik at testene blir så grundige som mulig. Arbeidet vi har gjort og testpersonene har gjort underveis, har gjort at Sesam Showroom har forbedret seg under hele perioden, både designmessig og funksjonalitetsmessig Sikkerhet og Fleksibilitet ved utvikling Ut ifra at vår oppgave er basert på en plugin som ligger ute på Ceetron sine hjemmesider hvor en kan laste ned denne gratis, og at filene som en kan se og laste ned i Sesam Showroom er åpne for alle, har det ikke vært et krav om sikkerhetstiltak i oppgaven vår. En av grunnene til dette er også at dette skal brukes som promotering til kunder og da skal kunden ha tilgang på det som ligger i Sesam Showroom. En annen grunn er at dette skal kunne brukes internt i DNV, også under presentasjoner ved foredrag eller seminarer. Det er validering i feltene som testes i Selfdefined models, siden vi heller ikke har noen databaser trenger vi ikke være redd for injections av forskjellige slag. Sesam Showroom er utviklet med tanke på promotering og bruk på nett, derfor skal det kunne brukes av en større gruppe med personer, både kunder og ansatte. Ut ifra at koden vår er enkel og oversiktlig, er den lett å forstå, noe som igjen fører til at det er enkelt å videreutvikle. Sesam Showroom er fleksibel for utvikling og det skal være enkelt for en ansatt ved DNV å videreutvikle dette. Et eksempel på videreutvikling kan gjelde for eksempel hvis det blir utlevert en plugin versjon som støtter flere nettlesere, er det så enkelt at en bare kan bytte ut koden nevnt ovenfor med ny kode. Det er også laget en About fane som dekker hvordan en bruker skal kunne lage egne vtfx-filer ved hjelp av DNV sin programvare, dette forutsetter at man er en kunde av DNV selvfølgelig. 14

15 6. Kravspesifikasjon 6.1 Generelt Kravspesifikasjonen som ble utviklet tidlig i prosjektfasen har selvfølgelig vært et av de viktigste dokumentene underveis i utviklingsfasen i prosjektet. Vi gjorde en god jobb sammen med oppdragsgiver under arbeidet da kravspesifikasjonen ble skrevet. Dette var tross alt den viktigste prosessen i planleggingsfasen, her ble funksjonalitet og design fastsatt etter de ønsker som ble gitt fra oppdragsgiver, noe som førte til at vårt fokus ble satt på å tilfredsstille oppdragsgiver fra starten av. Det var ganske generelt hva DNV hadde ønsker om, men viktig for at vi ikke skulle spore av i en annen retning enn det som var ønsket. Resten av utviklingen var opp til oss og det ble gitt ganske frie tøyler, så lenge vi holdt oss innenfor de rammekrav som ble gitt. 6.1 Endringer Det har selvfølgelig blitt gjort endringer i kravspesifikasjonen, dette er på grunn av de uforutsette problemene som har vært nevnt ovenfor, se punkt 5.2. Dette gjelder utviklingsspråk som er brukt underveis, det vil si PHP istedenfor C#.Net. I tillegg til dette hadde vi ikke regnet med at det skulle bli problemer med design og krav til administratorrettigheter ved aksess av filer til 3D plugin ved bruk av dotnet server. Sluttproduktet har kanskje ikke blitt utviklet slik vi så for oss i starten av prosjektfasen, men vi mener det har blitt utviklet til et bedre resultat enn de vi hadde forestilt oss. De resterende av de nevnte problemene og utfordringene som vi har støtt på har ikke hatt noen påvirkning for kravspesifikasjonen og bortsett fra endringer gjort ut ifra nevnte problemer/utfordringer, samsvarer produktet vårt med kravspesifikasjonen. Dette er takket være kvaliteten i kravspesifikasjonen og det gode arbeidet vi gjorde i starten av prosjektfasen som har ført til at det har vært minimale endringer på den opprinnelige kravspesifikasjonen. Noe som vi er veldig fornøyde med. 15

16 7. Oppsummering og Konklusjon 7.1 Oppsummering Vi er veldig godt fornøyde med det sluttproduktet vi har endt opp med, samtidig som det har vært en utfordrende prosess med problemer og utfordringer, har det også vært en utrolig lærerik prosess. Det har vært positivt givende å være ansvarlig for et prosjekt fra start til slutt og at vi har vært ansvarlig for et sluttprodukt som skal brukes til promotering av et firma som er kjent på verdensbasis, noe som har vært spennende og vært et stort bidrag til motivasjon. Gruppesammensetningen, samarbeid og kvalitet på arbeid innad i gruppen har fungert bra, grunnen til at vi har kommet frem til dette er at det har vært flere løsninger på forskjellige utfordringer. Noe som gjør at vi kan komme frem i enighet til den beste løsningen, dette har igjen bidratt til økt kvalitet på sluttproduktet. Vi er også fornøyde med den tekniske kunnskapen vi har tilegnet oss i denne prosessen, selv om mye kun trengtes å friskes opp fra tidligere studieår. Men dette er kunnskap vi kan ta med oss videre i arbeidslivet, om det så skal gjelde å videreutvikle denne siden eller om det er andre bedrifter som skal promotere seg selv på nett. 7.2 Ønsker for videreutvikling i fremtiden Sesam Showroom blir tatt i bruk umiddelbart etter leveranse, vi håper jo selvfølgelig at dette skal bli en suksess som både kunder og ansatte vil ta i bruk. Dette kan være ved presentasjon eller til bruk i arbeidet. Vi håper derfor at produktet skal være tilfredsstillende, at vi oppfyller de krav som var ønsket og at DNV er fornøyd med løsningene vi har valgt underveis. Til videreutvikling ville vi anbefalt å åpne for flere input felter i Selfdefined models slik at brukeren kan få akkurat den input man er ute etter. Dette åpner igjen for flere filer som må lages og mer validering, men dette bidrar jo bare positivt til størrelse og omfang på oppgaven. Det andre forslaget vi vil komme med er at det blir utviklet en plugin som kan brukes i flere nettlesere slik at en bruker ikke er låst til kun Internet Explorer. Dette er jo tross alt et problem for mennesker som bruker Mac og ikke har tilgang til Internet Explorer. Helt til slutt håper vi at vår oppdragsgiver kommer til å få stor nytte av dette produktet som vi har utviklet og at det oppfordres til bruk i arbeidet siden det forenkler læringsprosessen for ansatte som kanskje ikke vet så mye om de forskjellige casene som DNV jobber med. 16

17 7.3 Hva kunne vært gjort annerledes? Vi har hele tiden vært klar over at omfanget på oppgaven har vært ulik for hver av de forskjellige deloppgavene, dette har muligens ført til at vi har brukt litt for lang tid på enkelte oppgaver som skulle vært brukt på andre. Et godt eksempel er eks antall dropdown tabeller som ble laget før vi ble fornøyde. Det vi kunne gjort her i stedet, var å lage et forslag hvor all funksjonalitet var med og så gå tilbake til design når funksjonaliteten i hver oppgave var ferdig utviklet. Det kunne vært mer fokus på deloppgaven Selfdefined models, her kunne vi startet tidligere med opprettelse av filer slik at vi kanskje kunne fått validering på flere input felter. Men over tusen filer hadde nok vært litt i meste laget med tanke på omfanget av oppgaven vår uansett. Det burde også vært gjort mer testing på hva som skjedde ved at en bruker trykket og navigerte vilt rundt, her kan det hende siden vil henge seg opp siden pluginen er såpass tungkjørt ved innlasting av filer. Dette har vi i senere tid oppdaget at er noe som kan oppstå, men som vi heller ikke kunne gjort så mye med siden det ikke er vi som utvikler pluginen. Vi har også kommet frem til at vi kunne ha satt av mer tid i tilfelle problemer, slik at vi ikke ender opp litt dårligere tid enn nødvendig i slutten av prosjektperioden. Dette er nyttig lærdom som vi tar med oss videre. 17