3.1 Samling av materiale
For å i det hele tatt kunne begynne å produsere meningsfylt arbeid, måtte prosjektgruppen fordype seg i temaene gjennom den dokumentasjonen som var tilgjengelig. Heldigvis har IBM dokumentert
systemene sine godt både på nettet og i egne bøker. Ut ifra dette lagde vi et kondensert utdrag av dokumentasjonen i en egen fil for å få oversikt over hvordan temaene hang sammen. Vi har dermed i stor grad brukt både internett og publiserte bøker som grunnlag for arbeidet i bachelorprosjektet. Da vi hadde brukt de første ukene i prosjektet på å lese oss opp på stoffet, var vi mye bedre forberedt på å takle de praktiske oppgavene med å sette opp et testsystem.
3.2 Dokumentasjon
Helt fra begynnelsen i prosjektet har gruppen jobbet iherdig med å sette sammen dokumentasjon som både dekker prosjektmålene, og formidler den viktigste kunnskapen om systemet til leseren. Resultatet av dette ble som sagt to rapporter, en forstudierapport og en hovedrapport. Hovedrapporten ble dokumentet som inneholdt mesteparten av den tilegnede kunnskapen, da forstudiet handlet mest om å få et overblikk.
3.3 Installasjon av testsystem
Med god kunnskap om systemets funksjoner og sammenheng ble det ingen stor utfordring å sette opp et fungerende testsystem. Ved hjelp av en instruksjonsvideo og dokumentasjonen på nettet fant vi ut hvordan vi skulle laste ned og installere programmet. Spectrum Scale er kompatibelt med Ubuntu, og vi fant alt vi trengte av forhåndsinstallasjon i dokumentasjonen. Dermed gikk dette relativt raskt unna.
3.4 Samarbeidet i gruppen
Samarbeidet i prosjektgruppen har gjennomgående vært bra. Begge deltakerne har møtt opp til avtalt tid, og gjort sitt beste for å bidra positivt til gjennomføringen av prosjektet. Helt fra begynnelsen har vi vært enige om å møte opp på skolen, og jobbe som om det var en normal arbeidssituasjon. Selv om timeantallet generelt ble noe lavere enn antatt, har vi stort sett jobbet fulle arbeidsdager, og med god flyt gjennom hele prosjektet. Arbeidsrutinen og interessen for emnet gjorde at vi kunne jobbe med høy effektivitet. Vi er begge fornøyde med arbeidsinnsatsen og kvaliteten på sluttproduktet.
3.4.1 Arbeidsfordeling
Selv om det ikke har eksistert noen klar rollefordeling i gruppen, og medlemmene har tatt for seg de arbeidsoppgavene som krevdes av dem underveis, har fordelingen av oppgavene mellom deltakerne vært noe forskjellig.
Amund Hauglie-Hanssen
Amund har jobbet mest med Spectrum Scale-produktets oppbygning og tekniske detaljer. Han har satt seg grundig inn i dokumentasjonen til IBM om hvordan de ulike komponentene fungerer og utgjør programmets funksjoner. Videre har han overført denne kunnskapen både i installasjonen av
programvaren på en virtuell testløsning og den tekniske dokumentasjonen av programmet i rapportene.
Han har dokumentert mange av de praktiske oppgavene som kan gjennomføres med Spectrum Scale gjennom det grafiske brukergrensesnittet, og satt dette i sammenheng med bedriftens behov.
NTNU Prosjektgruppe 115 15-May-20
10 Sluttrapport
Sveinung Bergum
Sveinung har i hovedsak tatt for seg et mer helhetlig bilde av et lagringssystem med IBM Spectrum Scale, og har hatt større fokus på støttesystemene rundt en installasjon enn de tekniske detaljene. Han har sett på temaer som dreier seg rundt tapeløsninger med IBM Spectrum Archive og tilleggsfunksjoner som CES (Cluster Export Services) med NFS og brukerdatabase med LDAP. I rapportene har han bidratt med å installere og dokumentere disse funksjonene og sette dem i sammenheng med Spectrum Scale.
Felles
Sammen har Amund og Sveinung tatt for seg Kongsbergs problemstilling, og diskutert hvilken løsning som kan være den beste for bedriften. Gruppens medlemmer har sammen stått for å sette sammen dokumentasjon med et helhetlig fokus, og har brukt mye tid på å skape sammenheng i teksten. Dette har ført til mange timer med omstrukturering og vurdering av den røde tråden i dokumentasjonen.
3.5 Utfordringer underveis
Prosjektgruppen har naturligvis støtt på noen utfordringer underveis i arbeidet. Vi har erfart at det er krevende å jobbe i store prosjekter, og å skrive store rapporter. Dette krever god planlegging og struktur for å produsere et tilfredsstillende resultat, og det er viktig at man kommer fort i gang med prosessen slik at man best mulig kan kartlegge prosjektets utfordringer. Her ser vi litt på hvilke problemer vi har støtt på i prosjektet, og hvordan vi gikk frem for å løse disse.
3.5.1 Utforme en konkret hensikt
Oppdragsgiveren, Kongsberg Seatex, hadde et konkret problem med sine datamengder. Kravene til selve systemet var klare. Det som derimot ikke var klart, var hva som skulle til for å dekke disse behovene. I begynnelsen var hensikten med prosjektet å sette opp et pilotprosjekt for bedriften som skulle fungere som en slags testløsning eller en «salgspitch» for et virkelig Spectrum Scale-system. Prototypen skulle speile bedriftens virkelige implementasjon i størst mulig grad, og i prinsippet kunne overføres til deres datasystemer.
Senere i prosjektet innså vi etter hvert at dette ble for omfattende for to studenter uten
forhåndskunnskaper om systemet. Et system som skal håndtere bedriftskritisk informasjon må igjennom en formell prosess utenfor vårt kunnskaps- eller ressursområde. I tillegg fant vi ut i møte med IBM at de sannsynligvis leverer en egen skreddersydd løsning for bedriften, og at vårt testsystem dermed i stor grad ble overflødig. Vi valgte derfor å kurse prosjektet i en annen retning, der hensikten i større grad dreide seg rundt å eksperimentere med Spectrum Scale, og demonstrere noe av nytteverdien systemet kunne ha for Kongsberg Seatex i fremtiden. I prosjektet valgte vi derfor å fokusere på å illustrere konseptene og grunnleggende funksjonalitet i løsningen på et mer abstrakt nivå, for best mulig å gjøre en nytteverdi for bedriften. Denne forandringen i prosjektmålene gjorde at vi måtte revurdere mange av punktene vi hadde planlagt, og skrive om en del i rapportene.
3.5.2 Avgrensning av prosjektet
Det er vanskelig å si noe om det man ikke vet noe om. Da vi satte i gang med prosjektet, hadde vi kun en svært abstrakt forståelse av hva systemet gikk ut på. Vi hadde ingen anelse om omfanget til de ulike områdene av den tekniske løsningen, og slik det ble nevnt tidligere visste vi ikke engang om vi kom til å greie å laste ned og installere Spectrum Scale i det hele tatt. Den eneste måten å finne ut dette på, var å sette seg ned og lese om temaet. Dermed ble det også vanskelig å gjøre en realistisk avgrensning av
11 Sluttrapport
prosjektet, noe som førte til at vi i flere omganger måtte gå tilbake til prosjektmålene og endre på dem i forhold til kunnskapen vi tilegnet oss underveis.
Det var mange retninger vi kunne tatt prosjektet i, og det gjaldt dermed å finne middelveien mellom de ulike temaene rundt problemstillingen. For eksempel måtte vi etter hvert beslutte at fokuset måtte holde seg til kun selve datasystemet, og ikke for eksempel transport av data fra båten. Det ble også viktig at vi ikke brukte for mye tid på å utdype hvert tema og funksjon, da man kunne ha skrevet flere bacheloroppgaver om noen av disse temaene. Heller fokuserte vi på å vise litt av hvert, slik at leseren får en oversikt over hva som er mulig å gjøre.
3.5.3 Balanse mellom det tekniske og konseptuelle
Et av de temaene vi har brukt mest tid på å diskutere er utformingen av prosjektet, og da også
dokumentasjonen som helhet i forhold til grad av teknisk fokus. I begynnelsen av prosjektet lå fokuset veldig på det tekniske bak Spectrum Scale som produkt. Vi så på hvordan de ulike komponentene i løsningen var bygget opp og hvilke oppgaver de hadde. Selv om dette var veldig nyttig i å danne forståelse for programmet, noe som kom til hjelp i å videreformidle kunnskapen, ble fokuset fort for snevert og arbeidsomfanget ble stort og uoversiktlig.
Problemet med å bli for orientert rundt detaljene er at arbeidsmengden blir uendelig stor. Vi hadde rett og slett ikke tid til å sette oss inn i og dokumentere alle funksjonene i Spectrum Scale. Vi tror heller ikke at dette hadde vært spesielt nyttig for bedriften. Dette henger også tett sammen med selve
oppgavedefinisjonen, og hva som er hensikten med prosjektet.
Slik endte vi med å måtte justere fokuset fra detaljnivå til abstrakt nivå. Dette ble gjort ved å inkludere flere illustrasjoner av konseptene, forklare dem så enkelt som mulig, og fjerne unødvendige tekniske detaljer. Det var her viktig å hele tiden holde prosjektmålene og selve hensikten med rapporten i bakhodet for å ikke skli ut i en sidegate som ikke var relevant for prosjektet.
Å skrive rapporten på denne måten var også essensielt for å gjøre den mest mulig forståelig for leseren.
Vi har erfart at det er utfordrende å sette seg inn i hvordan det er å lese teknisk dokumentasjon når man ikke har den samme kunnskapen som den som har skrevet den. Igjen har vi derfor brukt mye tid på strukturering, og å forsøke å holde en rød tråd gjennom rapportene på best mulig vis, uten å gjenta oss selv for mange ganger.
3.5.4 Coronaviruset
Effektiviteten i prosjektet ble mot slutten noe rammet av Covid-19-situasjonen. Da vi ikke fikk sitte på skolen lenger, merket vi fort at det ble vanskeligere å stå opp til riktig tid og jobbe effektivt. For å håndtere dette justerte vi ned målet fra 8 timer til 6 timer om dagen, og inkluderte heller tirsdager som arbeidsdag i tillegg. Dette har hjulpet litt på effektiviteten, da vi kunne jobbe mer intensivt på denne måten. Likevel har dette problemet sakket ned på prosessen, og tærte på motivasjonen i gruppen.
NTNU Prosjektgruppe 115 15-May-20
12 Sluttrapport