Prosjekt nr. 2011 22 Kravspesifikasjon Hovedprosjektets tittel Implementering av plugin og utvikling av wizard for Det Norske Veritas Prosjektdeltakere Magnus Strand Nekstad s156159 Jørgen Rønbeck s135779 Dato 22. Februar 2011 Antall sider 14 Intern veileder Steinar Johannesen Oppdragsgiver Det Norske Veritas DNV Software (www.dnvsoftware.com) Kontaktperson Ole Jan Nekstad 1
1. Innledning 1.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. I tillegg til dette skal vi også lage en funksjon for å kunne velge mellom forhåndsbestemte verdier som så skal finne frem til den 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 og C#, mer om prosjektets oppgaver og detaljer kommer lenger ned i kravspesifikasjonen. 1.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 de har også vunnet markedsandeler for salg av programvare for styrkeberegning av faste installasjoner. 1.3 Bakgrunn 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. 2
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
2. Forord 2.1 Forord Denne kravspesifikasjonen beskriver betingelsene for prosjektet vårt; Implementering av plugin og utvikling av wizard for Det Norske Veritas. Krav til funksjonalitet, rammebetingelser og design er beskrevet i dette dokumentet. Hovedkravene om funksjonalitet og rammer er gitt av DNV Software, mens krav til design er lagt opp til oss selv, med andre ord vi har frie tøyler til å komme frem til den beste løsning, så lenge utseende på siden er lik nåværende utviklede sider. Det er også opp til gruppen selv å løse oppgaven på best mulig måte, det er relativt få eller tilnærmet ingen krav til hvordan prosjektarbeidet skal legges opp så lenge vi holder kontaktperson Ole Jan Nekstad informert om progresjon og fremgang i oppgaven, ellers har vi et stort ansvar her selv. 4
3. Innholdsfortegnelse 1. Innledning... 2 1.1 Innledning... 2 1.2 Om bedriften... 2 1.3 Bakgrunn for prosjektet... 2 2. Forord... 4 2.1 Forord... 4 3. Innholdsfortegnelse... 5 4. Krav til system... 6 4.1 Funksjonskrav... 6 5. Krav til design... 9 5.1 Generelle design mål... 9 5.2 Designmål Predefined Models... 9 5.3 Designmål Selfdefined Models... 9 6. Krav til kode... 10 7. Krav til rammer og programvare... 11 8. Krav til dokumentasjon... 12 9. Krav til bruk/utvidelse av systemet... 13 10. Ordliste... 14 5
4. Krav til system 4.1 Funksjonskrav 4.1.1 Krav til bruk av 3D Galleri Det som er ønskelig når en bruker skal ta i bruk 3D galleriet er at det skal være enkelt å bruke, enkelt å skjønne, enkelt å navigere rundt på siden uten å bli forvirret over hvordan en skal gå frem. Dette har vi tenkt til å få til ved å ta i hjelp dropdowns over store deler av galleriene for pluginen, det vil si at vi velger å hjemme alle gallerier helt til en bruker velger å åpne et galleri. Dette gjøres ikke bare for å gjøre det enkelt for brukeren å skjønne, men også for plass-sparing i den forstand av at dette skal kunne ses på notebooks/laptoper og da er det vinduet for plass mindre enn på en stasjonær. Dette er et ønske fra DNV som vi selvfølgelig skal ta til ettertanke og vi skal prøve å gjennomføre dette på best mulig og ønskelig måte. Nå skal vi ikke gå får mye inn på selve design-biten av oppgaven her, dette dukker opp under brukerdokumentasjon som leveres inn sammen med denne kravspesifikasjonen. Men for å gå litt inn på hvilke krav vi har satt til oss selv for å øke brukervennlighet og minske faren for at en bruker blir frustrert og ikke vil bruke denne siden, skal vi ta for oss en del scenarioer en bruker skal kunne ha muligheten til å utføre. - En bruker skal kun kunne velge en vtfx-fil om gangen, det vil si at en ikke har muligheten til å velge flere filer på en gang i plugin-vinduet. - Når en bruker har valgt en modell/fil, skal brukeren umiddelbart bli dirigert til plugin-vinduet for at en skal forstå at her har det skjedd noe ved valget brukeren har gjort. Dette er på grunn av størrelse på filene kan variere og det er stor variasjon på innlasting av filene i pluginen, derfor blir brukeren dirigert til vinduet slik at brukeren ikke trykker flere ganger fordi en kanskje har trodd at det ikke har skjedd noe. - De 3 forskjellig galleriene (Jackets and Topsides, Offshore Floaters, SURF) skal være tilgjengelig ved dropdown-bokser hvor de ulike filene av relevanse skal fremvises med tittel, størrelse, beskrivelse og bilde av modellen. - Det skal også være forklarende tekst til galleriet og plugin, slik at en bruker er klar over muligheten en har ved dette. Det kan være alt fra verktøy og hva man kan gjøre i plugin-vinduet til hvordan en navigerer rundt på siden og åpner/lukker gallerier. - I tillegg til dette skal brukeren få beskjed på toppen om han/hun kjører ulike nettlesere og da skal en få muligheten til å laste ned og installere riktig plugin til den bestemte nettleseren. De ulike versjonene for forskjellige nettlesere utvikles i skrivende stund, dette kan ta litt før vi får tilgang til de forskjellige, med tanke på feiltesting og risiko ved å slippe et uferdig produkt. Forhåpentligvis skal vi få tilgang til disse så snart som mulig slik at vi kan få oppfylt DNVs krav til siden. 6
4.1.2 Krav til bruk av Predefined og Selfdefined Models Det som er ønskelig med tanke på oppgavene angående predefined og selfdefined models, er at en bruker skal skjønne hva som skjer på siden med en gang man kommer inn på den. Det vil si at det ikke skal være forvirring ved valg av verdier, modeller eller variabler. Der det kan være vanskelig å forstå enkelte ting, ser vi får oss at vi får forklart med lyspærer eller informasjonsfigurer hvor man får opp informasjonsrubrikker når man flytter musen over eller klikker på figurene. Vi anser dette som en god og smart løsning på et problem som kan bli stort og hvis det oppstår kan dette få konsekvenser som vil medføre at en bruker ikke vil bruke siden så ofte som man håper på. Det som er viktig for oss er å imøtekomme krav og ønsker fra arbeidsgiver slik at oppgaven blir mest mulig slik de hadde forventet den og at vi kan forbedre den å gjøre den enda bedre enn det som i utgangspunktet er ønskelig. Den designmessige biten skal vi selvfølgelig ikke gå inn på her heller, men for å nevne noe ser vi for oss dropdown, lister, radioknapper, tekstfelter og en del forklarende bilder for å nevne noe, dette er for at siden skal få den beste brukervennlige opplevelsen og skal være appellerende for en bruker. Det er veldig kjedelig og lite gøy å bruke noe som ser kjedelig og grått ut for å sette det på spissen, men det er slik vi ser på det og derfor er et av våre mål for oppgaven og motvirke dette å legge høyt fokus på brukervennlighet og brukeropplevelse. I predefined models skal en bruker få listet opp flere forskjellige modeller, under hver av disse modellene skal det være et forklarende bilde, tekst og mange verdier som en bruker skal kunne velge fra for å lage sin forhåndsdefinerte modell. Til stort sett hver av de ulike modelltypene er det mellom 3 og 5 ulike scenarioer å velge imellom for å kunne se en forhåndsdefinert modell. Her skal det selvsagt være forklarende tekst for hva den spesielle modellen er og hva som er hensikten med å lage et scenario for denne. I tillegg til dette skal det også være forklarende tekst for hva man kan velge, hvorfor og hva som skjer ved valg av variabler i et bestemt scenario. I selfdefined models skal en bruker få listet opp flere forskjellige modeller, under hver av disse modellene skal det være et forklarende bilde, tekst og mange verdier som en bruker skal kunne velge fra for å lage sin egendefinerte modell. Til stort sett hver av de ulike skal en bruker kunne velge helt forskjellige verdier i forhold til i egendefinerte modeller, her skal en bruker også få beskjed hvis man velger verdier langt utenfor de restriksjoner som er tillatt. Dette er slik at det ikke skal oppstå problemer med opprettelse av modell i plugin-vinduet. Her skal det selvsagt være forklarende tekst for hva den spesielle modellen er og hva som er hensikten med å lage et scenario for denne egendefinerte modellen. I tillegg til dette skal det også være forklarende tekst for hva man kan velge, hvorfor og hva som skjer ved valg av variabler i et bestemt scenario. Med andre ord, vi ser for oss at selfdefined og predefined models blir relativt like i utseende, slik at en bruker skal kunne føle seg vant med siden. Dette gjør for at en bruker ikke skal være avhengig av å sette seg inn i noe nytt når man kanskje har satt seg inn i det ene valget til å begynne med. Dette ser vi på som den smarteste løsningen, men selvfølgelig, hvis arbeidsgiver har andre ønsker så skal vi ta med det i vår løsning. Mer om design ligger i vår produktdokumentasjon. 7
4.1.4 Tekniske krav 1. Kan utvikles i Microsoft Visual Studio i ASP.NET plattformen sammen med C# eller ved hjelp av PHP. 2. For å gjøre brukeropplevelsen og brukervennligheten best mulig skal vi bruke CSS-filer og en del Javascripter. 3. Plugin som brukes er tilgjengelig fra DNV, dette gjelder alle versjoner som hører til de ulike nettleserne. 4. Dette systemet skal kunne kjøres i de største nettlesere, men først og fremst i Internet Explorer, fungerer alt som det skal der, skal det også være mulig å gjennomføre i de andre store nettleserne (Google Chrome, Mozilla Firefox og Opera). 5. GeniE modelleringsprogram fra DNV fremskaffes av DNV og gjøres tilgjengelig på en av våre pc-er, dette er så vi kan få laget de reelle vtfx-filer som skal være tilgjengelig fra vårt system. 6. Xtract program for å kunne eksportere modelleringsfilene fra GeniE over til vtfx-filer er også tilgjengelig fra DNV. Mer om hvordan programvaren fungerer kommer i vår produktdokumentasjon om hvordan vi lager disse filene. 7. Andre tekniske krav og aspekter er opp til oss selv, her vil vi ta i bruk Visual Studio for selve samhandlingen med dynamikk og events, mens for HTML/CSS-koding er det enklest og raskest og ta i bruk Notepad++, dette er gratisprogram som er tilgjengelig via internett. 8
5. Krav til design 5.1 Generelle design mål Siden skal være enkel og innbydende. Informasjonen siden inneholder, skal være lett tilgjengelig så brukeren ikke må bruke tid på å lete frem informasjonen som han/hun er ute etter. Får å gjøre den enklere i en eventuelt senere videreutvikling vil vi holde kode og design avskilt. Til dette bruker vi CSS-filer og programmet Microsoft Visual studio. Vi er veldig opptatt av at siden skal være dynamisk og at brukeren skal få en så god opplevelse som overhodet mulig ved bruk. Det vil si som eksempel, at en bruker ikke skal prestere og rote seg bort på sidene våre og ikke klare å finne veien tilbake. At en bruker skal kunne velge den filen en er ute etter og ikke klare å velge flere filer om gangen. Dette er for å nevne noen eksempler. Det vil bli laget feilmeldinger som vil komme opp hvis en bruker gjør ting som ikke er tillatt eller som ikke kan utføres. Mer om dette står i produktdokumentasjonen vår. 5.2 Designmål Predefined Models Målene for både predefined models og selfdefined models er de samme, at det skal være funksjonelt, enkelt og bruke, enkelt å navigere, enkelt å endre og enkelt å utvikle videre for arbeidsgiver. Vi er ute etter at brukeren skal få umiddelbar god oversikt over hvor filer, variabler og verdier er tilgjengelig og hvordan de kan endre de pre-definerte variablene. Når det gjelder valg av variabler skal vi bruke radiobuttons og dropdown lister. Bruk av dropdown list gir en ryddig og oversiktlig utseende. Mer om dette står i produktdokumentasjonen vår. 5.3 Designmål Selfdefined Models Målene for både predefined models og selfdefined models er de samme, at det skal være funksjonelt, enkelt og bruke, enkelt å navigere, enkelt å endre og enkelt å utvikle videre for arbeidsgiver. I likhet med predefined har vi valgt å bruke dropdown lister her også ved åpning av forskjellige kategorier for hvilken modell brukeren vil lage. Innenfor dette igjen skal vi enten ha tekstbokser eller listbokser for valg av verdier. Når det gjelder input av variabler bruker vi tekstbokser og en funksjon som gjør at brukeren får beskjed om verdien som er skrevet inn er innen for de gitte begrensninger som er satt. I tillegg vil verdiene ikke forsvinne før en bruker velger å lage modellen, dette er for at brukeren skal enkelt kunne endre på hva en har valgt som verdier i tilfelle en vil endre på dette før opprettelse av modell. Mer om dette står i produktdokumentasjonen vår. 9
6. Krav til kode ASP-kontroller(Labels, TextBoxer etc), metoder og variabler skal ha naturlige navn i forhold til den konteksten de er i. F. Eks en tekstboks med input for en variabel kalles: lengthtextbox og så videre. Kodefilene skal kommenteres i henhold til C# standard som det er støtte for i C# kompilatoren vår som er Microsoft Visual Studio. Vi ser at viktigheten i å kommentere koding i filene våre er høyt prioritert, dette er på grunn av videreutvikling. Gode dokumenterte filer og koder gjør jobben enklere for ansatte i DNV ved videreutvikling og oppdateringer. Det er ikke bare viktig med tanke på videreutvikling, men også for vår egen del for å ha oversikt over hvor vi er, hva vi koder på og hva som skjer i forskjellige metoder. I eksempelet under har vi vist hvordan vi kodefilene kommenteres ved nullstilling av tekstfelter. /// ///Her er metoden for når brukeren trykker på tøm-felter -knapp. /// /// /// Her blir lenge og bredde felter satt til blanke. /// ///object vclicked/selected ///EventArgs private voide Clear_Click(object sender, EventRgs e) { lengthtextbox.text= ; widthtextbox.text= ; } Dette er selvfølgelig bare et eksempel i henhold til eksempelfiler i dokumentasjonsstandarden som ligger ute på nettet i våre prosjektsider. Vi har kun brukt denne koden for å vise frem eksempel på koding, ikke for videre distribusjon. (henviser til linken nedenfor, denne linken ligger inne i standarddokumentasjon for hovedprosjekter ved HiO. Så skal vi her skal inn på side 8 i deres eksempel på kravspesifikasjon). http://student.iu.hio.no/hovedprosjekter/2006/data/28/linker/produkt.htm 10
7. Krav til rammer og programvare Det er ønskelig at alt skal være tilgjengelig i alle nettlesere (Internet Explorer, Google Chrome, Opera, Mozilla Firefox) og skal det skal være mulig og aksessere via vanlig internett teknologi. Alle sider som blir laget må være mest mulig lik DNVs profil og ha samme look and feel som eksisterende GeniE Snack Pack. Alt som blir gjort må dokumenteres nøye slik at DNVs egne utviklere kan drive vedlikehold uten domenekunnskap. Inne på siden skal det være forklarende tekst om hva dette er, hva siden gjør, og hva brukeren kan gjøre på siden. Hvilke valg og muligheter en bruker har, og hva som skjer når en bruker fyller ut verdier. Programvare som benyttes: - Mesteparten vtfx-filene lages av oss på studentgruppen, ved oppretting av filer for K-Joint og T-Joint kan lages fra GeniE Wizard som er tilgjengelig for oss. - Filer for Supply vessel og Tanker kan lages fra en js-fil som ligger i GeniE Snackpack som er tilgjengelig for oss. - Filer for Jacket og Topside lages av DNV eller at vi får standalone programvare, så lenge de to utdaterte modelleringsverktøy som er laget i Excel ikke blir oppdatert til å fungere. - Det blir også gjort tilgjengelig en versjon av GeniE som er et av deres modelleringsprogrammer slik at opprettelse av vtfx-filer skal kunne være mulig for alle typer vi skal ha med, dette er med tanke på om de utdaterte modelleringsverktøyene ikke blir oppdatert. Programmeringsspråkene vi har tenk til å bruke er: PHP, C#, JavaScript og HTML. Vi kommer til å bruke Visual Studio og Netbeans til store deler av kodingen. 11
8. Krav til dokumentasjon Det skal skrives en dagbok etter hverdag det er blitt gjort noe i forbindelse med prosjektet. Etter hvert møte skal det skrives et referat som også skal være med i prosjektrapporten. Det er ikke sikkert det blir nødvendig med så mange møtereferater med tanke på at gruppedeltakerne bor sammen og da kan ta mesteparten av møtene muntlig og nødvendigvis ikke ha så store møter. Derfor er det ikke alltid nødvendig å dokumentere møtene. Vi kommer selvfølgelig til å skrive referater fra alle møter med veileder Steinar Johanessen og møter med kontaktperson Ole Jan Nekstad. Den endelige rapporten skal inneholde: Prosjektbeskrivelse/skisse Prosessrapport Produktdokumentasjon Kravspesifikasjon Testrapport Brukerdokumentasjon Forprosjektrapport Statusrapport 12
9. Krav til bruk/utvidelse av systemet Som nevnt tidligere legger vi stor vekt på design og brukergrensesnitt. Vi er opptatt av at siden skal være ryddig og pen å se på. Umiddelbart når brukeren kommer inn på siden skal de forstå hvor ting er og hvordan man lettest bruker siden. Vedlikehold av siden er viktig og vi kommer derfor til å gjøre kodingen så oversiktlig som overhodet mulig. Det vil bli gjort i form av indeksering og kommentering inne i selve kodingen, god oversikt over filer og kategorisering av innhold slik at de ansatte hos DNV kan lett sette seg inn i kodingen, finne filer og drive vedlikehold, oppdatering og videreutvikling av siden. Vi ser for oss at videreutvikling av siden kan gjelde flere kategorier, flere sider ved opprettelse av flere gallerier. Flere filer til 3d galleriet, nye måter å gå frem på ved valg av verdier og variabler i selfdefined og predefined models. Det kan jo hende at en plugin av DNVs program GeniE som brukes til å lage disse vtfx filen lages en dag sånn at en kan få hentet opp hele programmet på nett. Dette var i utgangspunktet en av oppgavene våre i hovedprosjektet, men ikke realiserbart med tanke på tidsaspekt, omfang av oppgave og kompetanse i gruppa. Derfor kan vi ta dette til ettertanken og foreslå at DNV, hvis mulig, får laget en plugin som er enda mer omfattende en dagens plugin. Slik at en bruker kan få enda bedre innsyn i hva GeniE er og hva DNV kan og står for, som igjen kan brukes som markedsføring slik at DNV blir enda større og får presentert til nåværende og fremtidige arbeidspartnere, mulighetene en har ved bruk av deres programvare. 13
10. Ordliste Jacket: En type fast plattform som brukes til produksjon av olje eller gass. Disse plattformene er bygd på betong og/eller stål-ben forankret direkte på havbunnen. Dette gir god støtte for borerigger, produksjonsfasiliteter eller lokaler for mannskap. Basert på langsiktig bruk på et sted. Semisub: Et marinefartøy med god stabilitet og sjøegenskaper. Brukes i en rekke konkrete roller innenfor offshore, som for eksempel borerigger, safety vessels, oljeplattformer og offshore kraner. Pipe: Ulike typer rør K-Joint: Flere materialer koblet sammen så det ser ut som en K, eksempel på materiale: Rør T- Joint: Flere materialer koblet sammen så det ser ut som en T, eksempel på materiale: Rør Tanker: Tank skip Supply vessel: Laste skip Predefined models: Forhåndsdefinerte modeller Selfdefined models: Egendefinerte modeller Vtfx-filer: En type modell-fil som brukes vi DNV og Ceetrons 3D plugin for å vise modeller for modelleringsprogrammer 14