Sommeroppgave MFO Tele 2013

Transkript

1 Sommeroppgave MFO Tele 2013 Morten Øvrebø og Lars-Martin Hejll 8/15/2013

2 Innhold Introduksjon:... 3 Oppgave Tema og problemstilling for oppgaveideen Hva skal sluttproduktet være etter at studentens oppdrag er over? Hvilket fagområde er oppgaveideen relevant for Hva slags omfang og tidsperspektiv har oppgaveideen? Tid og ressurser MFO Tele har til oppfølging Spesielle krav til hemmelighold Ønsker virksomheten å stille med kontorplass/arbeidssted til studentene i egne lokaler?... 7 Initiale Vurderinger... 8 Sentralisert database... 8 Utfordringer ved bruk av sentralisert database:... 9 Fordel ved å benytte skanning av strekkoder:... 9 Utfordringer ved å benytte skanning av strekkoder:... 9 Brukertilgang, autorisering og autentisering:... 9 Tilgangsmatrise Database Introduksjon Initial databasestruktur Endelig versjon av databasestruktur Applikasjon utvikling Introduksjon Fossefallsmodellen: Inkrementell utviklings prosess: Inkrementell modell Inkrementell utvikling metode Agile utvikling Extreme Programming Programmering Oppsummering applikasjons utvikling Serverbruk Utviklings miljø Test miljø Produksjons miljø

3 Oversikt Videre bruk av applikasjonen Optimal bruk Videreutvikling Oppsummering Konklusjon

4 Introduksjon: MultiField Operations Tele har ansvaret for teleutstyret (vedlikehold og integriteten) på 29 ulike anlegg offshore. Til nå har det vært veldig ulik praksis for å holde oversikt og registrering av UHF, VHF og personsøkere. Noen installasjoner har ikke hatt registrering av denne type utstyr, mens andre har opprettet ulike databaser for å holde oversikt over radioene og krav til FV på utstyret. Det har ikke vært noe felles struktur eller format på disse databasene. Noen av de databasene som har vært benyttet er utdatert og supporteres ikke lengre, i tillegg er flere av databasenen ikke uten videre kompatibel med nyere operativ system som Statoil standardiserer på. Statoil ønsket en ny felles løsning for dette: Et produkt som består av en database i bunn, web basert grensesnitt, en registreringsmodul med relevante data, en rapport generator som dekker vårt behov med en opsjon på strekkode registrering. Importere og eksportere eksisterende data/databaser til nytt verktøy. Vi er to studenter, Morten Øvrebø og Lars-Martin Hejll hhv. fra Universitetet i Bergen og Høgskolen i Telemark som har fått tilbringe sommeren 2013 hos Statoil avd. Sandsliveien. Vi studerer begge Informatikk systemutvikling og programmering ved våre respektive skoler, vi føler oss heldige og privilegerte som har fått bruke sommeren på et slikt spennende prosjekt. Før oppstart i juni var vi begge spent på hva som ville møte oss, og hvordan vi skulle løse oppgaven. Ved oppstart ble vi raskt introdusert til oppgaven og vi ble begge overrasket over hvor godt denne passet med våre studier. De første dagene ved sandsliveien ble vi introdusert til mange nye fjes som skulle bli viktige støttespillere utover sommeren. Vi ble også introdusert for flere ulike avdelinger utover MFO tele, dette var interessant og ga oss et bilde over Statoil som organisasjon. De siste årene på skolen har vi blitt satt inn i mange simulerte oppgaver hvor vi har skulle levere et fiktivt produkt. Disse oppgavene har vi lært mye av, men situasjonene blir ofte i overkant kunstige og vi forholder oss ofte kun til en person (faglærer) og leverer ofte kun programmet, ikke tilhørende materiale. I denne oppgaven har vi virkelig fått utfordret oss og situasjonen har vært langt fra kunstig. Det har vært et reelt behov for et produkt vi har vært i stand til å produsere. Vi har forholdt oss til ulike parter under produksjonen, oppdragsgiver, forbrukere, medarbeidere, server administratorer. Applikasjonen har under utvikling parallelt hatt en evolusjon. Gjennom presentasjon for oppdragsgiver og forbrukere har nye ideer og bedre løsninger kommet frem i lyset. Software engineering er ikke kun programmering, vi har i tillegg til applikasjonen produsert teknisk dokumentasjon, brukerveiledning, og ulike Tutorials for å komplementere applikasjonen. Vi har blitt utfordret til å bruke et programmerings språk og en arkitektur som er mye benyttet i utviklingsmiljøer men som vi ikke før har benyttet. (C# & MVC) 3

5 Første uke var vi lokalisert ved sandsliveien 90 før vi i uke 2 ble flyttet til sandslighaugen datahallen E1. Her ble vi tildelt hver vår arbeidsstasjon med nødvendig programvare installert og to-skjermløsning, kort sagt gode fasiliteter! Vi fikk et crash kurs i MVC (Model View Controller) conseptet, Visual studio 2012 (C#), TFS (Team Fundation Server) og SQL Server 2008R2. Dette er programvare og konsepter som GBS benytter og som de ønsket at vi også skulle benytte, slik at applikasjonen kan driftes og videreutvikles også etter sommeren Vi hadde i utgangpunktet gjort oss noen tanker om hvordan vi hadde tenkt å løse oppgave, da vi begge hadde hatt lignende oppgaver på skolen tidligere. Etter denne innføringen forandret dette seg, og vi så muligheten til å bli kjent med en ny måte å utvikle web applikasjoner på. Microsoft Visual Studio 2012 er et integrert utviklingsmiljø som brukes til å skrive og lage programvare også forkortet til IDE (Integrated Development Environment). Dette utviklermiljøet inneholder: Teksteditor, kompilator debugger og ulike verktøy bla. for publisering av applikasjoner. Visual studio er beregnet for Microsofts.NET plattform og støtter ulike programmeringsspråk bla. Visual Basic, C++, C# og j#. Vi har valgt å benytte C#, primært fordi dette språket er mye brukt internt i GBS, sekundært for å bli kjent med et nytt språk da ingen av oss har kodet i dette språket tidligere. TFS (Team Foundation Server), et Microsoft produkt som tilbyr kildekontroll datainnsamling, rapportering og prosjektoppfølging. Produktet er laget for å forenkle samarbeid under utviklingsprosjekter for programvare. TFS har vært viktig for oss under utviklingen av denne applikasjonen, da vi har vært to utviklere som har samarbeidet fra to ulike arbeidsstasjoner. I praksis fungerer TFS godt, etter at en utvikler har gjort endringer i kildekoden oppdaterer han TFS med en «Check In» TFS tar da til seg de nye endringene i den aktuelle filen. Videre kan utvikleren annonsere at han har gjort endringer og at de øvrige i utviklermiljøet må oppdatere sine filer «Get Latest Version». TFS synkronisering er integrert i Visual Studio MVC er en programvare arkitektur som differensierer representasjon av informasjon fra brukerens interaksjoner. Modellen representerer strukturen på ulike objecter i applikasjonen, forretningsregler, logikk og funksjoner, view representerer cshtml filer som er det visuelle brukeren møter. Controlleren er knyttet mot Model og view og formidler input fra applikasjonen og konverterer det til kommandoer for modellen eller viewet. Den sentrale tanken bak MVC konseptet er mulighet for gjenbruk av kode og separasjon av input, logikk, funksjoner og det visuelle. Visual Studio 2012 inneholder funksjonalitet for å konstruere MVC 4 web applikasjoner. Model Controller View 4

6 Oppgave 1. Tema og problemstilling for oppgaveideen På de 29 anleggene offshore hvor MFO Tele har ansvaret for teleutstyret (vedlikeholdet og integriteten av dette) er det veldig ulik praksis med tanke på oversikt og registrering av UHF, VHF og personsøkere. Noen installasjoner har ingen registrering av denne type utstyr, mens andre har opprettet forskjellige databaser for å holde oversikten over radioene og krav til FV på utstyret. Noen av de databasene som har vært benyttet er utdaterte og supporteres ikke lenger i tillegg til at de ikke uten videre er kompatibel med nyere operativ system som Statoil standardiserer på. Spørsmål som Statoil ønsker bedriften å få løst, hva MFO Tele håper at studentene skal finne ut av: Vi ønsker å finne en egnet database som dekker vårt behov for å sikre en oversikt over dette utstyret (utlån, lager og reparasjon) og i tillegg når siste FV var utført. Vi ønsker en vurdering av fordelen med en sentral database for hele UPN eller en database pr installasjon. Vurdering av å ha en database for alle tre utstyrstyper UHF, VHF og personsøkere. Vurdering av nytten av å benytte skanning av strekkoder for å sikre at korrekte data blir registrert i databasen, og at riktige oppslag gjøres ved endring. En vurdering av brukertilganger (en bruker pr Site/anlegg, eller personlig bruker med tilgang til et anlegg), passord krav etc. Spesielle utfordringer, fremtidsplaner, produksjonsendringer, utvidelser eller andre faktorer som er relevante for problemstillingen: Vi står i disse dager ovenfor en endring av porteføljen av UHF radioer og ny teknologi (Tetra systemet) og om dette vil påvirke hvilke data som bør registreres må vurderes. Staffs og services prosjektet har innført frys av applikasjoner og skaper nå litt utfordringer som må løses for å få etablert en database løsning. Hva skal produktet fra oppgaven brukes til? Hvem skal bruke det? Produktet som utvikles skal være et databaseverktøy, med rapportgenerator, vurdere mulighet for strekkode innlesing av utstyrsdata. Produktet bør ha web grensesnitt, tilgangskontroll (felles bruker, personlig brukere vurderes). Produktet skal i det daglige benyttes av Automatiker med telekompetanse og av teleingeniører/fagstøtte ved årlig FV på dette utstyret. Oppgaveideen faglig og akademisk relevant for de utvalgte sommerstudentene: Begge kandidatene som er valgt har en datafaglig utdanningsretning og da oppgaven omhandler databaseløsninger og behandling av data så burde dette passe bra med den akademiske bakgrunnen. 5

7 2. Hva skal sluttproduktet være etter at studentens oppdrag er over? Forventninger til studentene: Et produkt som består av en database i bunn, web basert grensesnitt, en registreringsmodul med relevante data, en rapport generator som dekker vårt behov med en opsjon på strekkode registrering. Importere og eksportere eksisterende data/databaser til nytt verktøy. Kandidatene skal foreta en opplæring via videokonferanse i bruken av verktøyet for et utvalg av brukere. I tillegg forventes det at kandidatene leverer en beskrivende og utfyllende bruksanvisning av verktøyet og dets funksjonalitet som en integrert del av verktøyet. Hvordan vet dere og studentene om samarbeidet har vært vellykket eller ikke? At leveransen inneholder de ovenfor nevnte elementene (database i bunn, en registreringsmodul med relevante data en rapport generator som dekker vårt behov med en opsjon på strekkode registrering). Utført import og eksport av eksisterende data/databaser til nytt verktøy. Kandidatene skal ha foretatt en runde med opplæring via videokonferanse i bruken av verktøyet for et utvalg av brukere. I tillegg en integrert brukermanual som en hjelpefunksjon, som en bruker uten en innføring i systemet vil kunne ta verktøyet i bruk. 3. Hvilket fagområde er oppgaveideen relevant for Studenter i høyere utdanning innehar mye generell utredningskompetanse trenger dere ikke tenke på et spesielt fagfelt i det hele tatt. Men valgte kandidater har en relevant utdanning og bakgrunn i forhold til oppgaven. 4. Hva slags omfang og tidsperspektiv har oppgaveideen? Vi har satt av åtte uker til å ferdigstille produktet inkludert, brukermanual og kursing av deltagere. Vi har behov for en rapport etter at oppdraget er utført (oppsummering). Status og hvor langt en har kommet. Deadline: 15. august

8 5. Tid og ressurser MFO Tele har til oppfølging Hvor lang tid og hvor ofte har dere mulighet til å følge opp studentene: Vi allokerer ressurser i hele perioden (8 uker), der Svein Ove er hovedkontakt for studentene. I tiden han er på ferie ( ) vil Øystein Fjelldal være kontaktpunktet til studentene. Studentene og oppgaven vil bli presentert i neste nyhetsbrev i MFO Tele, dette vil muligens gjøre terskelen mindre for studentene å ta kontakt med MFO personell. Samhandlingen vil bli lettere andre veien også da oppgaven og studentene presentert for tele miljøet. Vi har fått følgende navn på ressurser i GBS (Global Business Service) som kan konsulteres av studentene ved behov underveis i utarbeidelsen av oppgaven: - Fredrik Gundersen - Anne-Grethe Ekornåsvåg - Arnvid Underlid - Tore Raum - Tove Mathiassen Hvor mange av virksomhetens ansatte vil studentene kunne ha kontakt med? Da oppdraget pågår i sommermånedene med avvikling av sommerferie vil det være nødvendig å ha to primærkontakter for å dekke ferietiden. I tillegg til disse vil det være naturlig at brukere både teleingeniører offshore, fagstøtte og automatikere med telekompetanse blir konferert/involvert under utviklingen av produktet. I hvor stor grad får studentene mulighet til å gjøre seg kjent med virksomhetens aktiviteter? Får de muligheten til å delta i det daglige arbeidet? I forbindelse med morgenmøter vil sommerstudentene bli presentert og de vil få en mulighet til å presentere oppgaven sin i noen avdelingsmøter i løpet av sommeren. 6. Spesielle krav til hemmelighold Nei ingen krav til hemmelighold. 7. Ønsker virksomheten å stille med kontorplass/arbeidssted til studentene i egne lokaler? Her må vi finne fornuftige arbeidsplasser for studentene integrert i miljøet. Se på ferieplanen og mulighetene for å sitte på samme celle kontor i fagstøtte. 7

9 Initiale Vurderinger Det nåværende systemet for utlån av UHF, VHF og personsøkere er plattform avhengig. Flere forskjellige løsninger brukes for å organisere utlån av disse enhetene. Noen bruker en database løsning, mens andre plattformer ikke har noe overordnet system. Det som nå ønskes er et felles system som brukes på tvers av plattformene. Slik at registrering av utlån, reparasjon og forrige FV på utstyr kan utføres effektivt og likt på alle plattformene. Vi vil oppnå dette ved å etablere en sentralisert database for hele UPN. Hvor vi ønsker å registrere data for alle tre utstyrstypene UHF, VHF og personsøkere. Etablering av en skanner løsning ser vi på som hensiktsmessig, for å effektivisere, redusere mulighet for feilregistrering og gjøre systemet mer intuitivt for brukeren. Det bør også være mulighet for manuell registrering, det vil gjøre systemet mer fleksibelt og robust. Ved for eksempel skade på skanner eller strekkode. Vi ser ikke behovet for autentisering av den enkelte bruker, men vi ønsker autorisering for å differensiere rettighetene til de ulike brukerne. Spesielt med tanke på at dette vil være en «åpen» webløsning. Sentralisert database En sentralisert database for hele UPN og for alle tre utstyrstyper vil kunne gi mange fordeler sammenlignet med nåværende løsninger og enkeltløsninger pr installasjon: Brukere av systemet vil på denne måten møte det samme grensesnittet på alle installasjonene, personell vil være kjent med systemet og vil da ikke ha behov for ekstra opplæring ved plattform bytte. Det trengs kun en felles teknisk brukerveiledning og en felles instruks for bruk som vil kunne dekke hele systemet. Adgangskontroll og Rettighetskontroll vil bli bedre organisert gjennom et tydelig hierarki, dette vil kunne bli styrt sentralt. Integriteten til databasen i et sentralisert system vil bli sterkere (konsistente data) en ved bruk av flere desentraliserte systemer. Ved å samle all data sentralt, vil det bli mulig å generere statistikk over bruk og vedlikehold på tvers av installasjonene. For eksempel gjennomsnittlig levetid til en enhet. Enhetene kan enkelt fordeles etter behov på de ulike plattformene.(flåtestyring) 8

10 Backup krever mindre ressurser. Ved at det kun er en database som skal håndteres. Bruker mindre serverkapasitet, ved å unngå replikering av data på flere ulike servere. Vedlikehold blir enklere med kun en database å forholde seg til. For eksempel hvis det kommer en ny type/modell så vil denne kunne installeres ved en operasjon. I et system der hver installasjon har sin egen database vil en slik installasjon føre til 29 ulike installasjoner. Dette vil kreve mer ressurser, tid og kapasitet. Utfordringer ved bruk av sentralisert database: Mer kompleksitet, flere nøstede spørringer mot databasen, krevende spørreoptimalisering. Samle dataen fra alle installasjonene. Mer datatrafikk mot samme database. Samtidige brukere, må sørge for at to brukere ikke starter en transaksjon og oppdaterer samme data til samme tid. Unngå kø/vranglås mot databasen. Feilregistrering, feil enhet på feil plattform. Fordel ved å benytte skanning av strekkoder: Enkel og rask identifisering. Etter skann av enhet er all informasjonen om den aktuelle enheten i web applikasjonen. Utfordringer ved å benytte skanning av strekkoder: Økt kostnad, skanner og eventuelt etikett printer. Mer kompleksitet mellom Software og hardware Forskjellige standard på skannere. Etiketter kan bli ødelagt over tid. Enheter som i dag mangler etikett/strekkode. Brukertilgang, autorisering og autentisering: Systemet vil ikke knytte utlån til enkelt personer, det er derfor ikke nødvendig med personlig brukertilgang for hver enkelt bruker. Enheter er ofte utlånt lengre en personens skift og blir ofte i avdelinger over lengre perioder. Utlån vil derfor bli knyttet opp mot avdeling ved den aktuelle installasjonen, hver avdeling vil ha oppført en kontaktperson / materiell ansvarlig. Det vil bli opprettet 9

11 autorisasjonsbrukere på tre ulike nivåer som beskrevet nedenfor, autorisasjonen vil bli gitt ved autentisering gjennom brukernavn og passord. Tilgangsmatrise 10

12 Database Introduksjon Microsoft SQL Server er en relasjons database utviklet av Microsoft og kommer i mange ulike versjoner. Språket som benyttes i SQL server er Transact- SQL. I samtlige tabeller har vi valgt å benytte «løpe nummer» som primærnøkkel og som indeks. Dette fordi: Essensiell data i hver enkelt rad, for eksempel, serienummer, modell, type etc, kan endres uten å påvirke primærnøkkelen. Et heltall som primærnøkkel (int) er en mer kompakt datatype en string/tekst som ville vært alternativet i de fleste tabellene. En kompakt datatype gjør at oppslag og indeksering vil gå raskere. Størrelsen på fremmednøkkelen som vil bli kopiert på tvers av ulike tabeller vil bli mindre en ved tekst strenger noe som vil minske veksten av databasen i fremtiden. Heltall vil heller ikke bli påvirket av hvordan brukeren taster inn navnet på en ny: modell, type etc, med tanke på små/store bokstaver. (Cascading problems) Vi har valgt å ha en sentralisert database for hele UPN og for alle de tre utstyrstypene (VHF, UHF, personsøkere). Dette vil gi mange fordeler både økonomiske og praktiske, sammenlignet med å desentralisere enhetene etter utstyrstype, anlegg etc. Databasen er lokalisert på en Microsoft SQL Server (ST- PM611) database navn: TYR. Server Versjon SQL Server 2008 R2 SP2 Databasen har flere integrerte trigger for å redusere antall transaksjoner mot databasen. For eksempel ved oppdatering av FV eller Serienummer på en enhet vil denne informasjonen automatisk bli skrevet til loggen. Under utviklingen av applikasjonen ble databasen flere ganger omstrukturert for å prøve ut nye løsninger og for å møte oppdragsgivers forventninger. Den største endringen gjennom utviklinger var definitivt endringen av forholdet mellom plattform og avdeling. Initiellt ønsket vi å skille avdelinger og plattformer i to ulike uavhengige tabeller, på denne måten slapp vi replikering av data. Eksempelvis ville avdelingen «Tele» med avdelings id «4» kunne være en avdeling på en hvilken som helst plattform, avdelings id sammen med plattform id ville avgjøre hvor enheten faktisk var plassert. I oppfølgings møte med oppdragsgiver senere i utviklingsprosessen etter at oppdragsgiver hadde fått første utkast av applikasjonen, ble det besluttet at en avdeling skulle være knyttet til en plattform. Det medførte at det i tabellen AVDELINGs vil bli flere replikeringer av samme avdelinger vis de har samme navn på tvers av plattformer. Løpe nummer strategien sørger her for at det ikke oppstår konflikter med primærnøkkel eller fremmednøkler. Vi ser ikke på replikeringen av data i denne tabellen som et problem, datamengden er liten, kapasiteten er stor og potensiale for vekst er liten. I praksis vil det kunne eksistere rundt 30 avdelinger på de største anleggene, noe som vil gi ca 900 rader totalt (ca 30 anlegg). Det er heller ingen risiko for integritet eller konflikter i tabellen. Det bør nevnes at dette er en av valgene som har ført til at databasen ikke er normalisert til BCNF (Boyce-Codd normal form). Ytligere informasjon om databasen er beskrevet i Teknisk brukermanual for UHF Utstyrsbase. 11

13 Initial databasestruktur 12

14 Endelig versjon av databasestruktur 13

15 Applikasjon utvikling Introduksjon Vi har valgt en Agile / inkrementell utviklings prosess i motsetning til Fossefallsmodellen, dette har gitt oss mange fordeler og noen utfordringer. Oppgaven var i utgangspunktet godt definert, spesifikasjonene, kravene og forventningene til produktet var ikke til å misforstå. Dette var et godt grunnlag til å velge en plan-styrt utviklings prosess, Fossefallsmodellen. Komponentene var definert og dette kunne bli satt opp i en lignende, gjerne mer detaljert fremdriftsplan: Fossefallsmodellen: Kilde: Det er flere fordelen med fossefallsmodellen som fremdriftsplan, først av alt er det enkelt for utviklere og for oppdragsgiver å måle fremdriften. Hvor langt har dere kommet, hvor mye gjenstår. Ulempen med fossefallsmodellen er fleksibiliteten. Vi har hatt kontinuerlig kommunikasjon og status møter med oppdragsgiver og forbrukere (Forbrukere defineres her som tele ingeniører som skal bruke applikasjonen i fremtiden) noe som har ført til at veien har blitt til underveis. Vi har presentert nye versjoner av applikasjonen og åpnet for tilbakemeldinger og innspill gjentatte ganger for videre utvikling. Denne evolusjonen er mye av grunnen til at applikasjonen har blitt slik den er i dag. Selv om oppgaven var godt definert har utviklere, oppdragsgiver og forbrukere sammen skapt et godt sluttprodukt. 14

16 Inkrementell utviklings prosess: Kilde: Software Engineering 9, Ian sommerville Inkrementell modell Outline Description, var vårt utgangspunkt som er beskrevet i oppgaven: Et produkt som består av en database i bunn, web basert grensesnitt, en registreringsmodul med relevante data, en rapport generator som dekker vårt behov med en opsjon på strekkode registrering. Importere og eksportere eksisterende data/databaser til nytt verktøy. Specification, representer spesifikasjonene beskrevet i oppgaven, disse har blitt endret underveis. Development, utvikling og koding. Validation, verifisering av produktet. Initial version, Første utkast som ble lansert i uke 4 Intermediate versions, vi har daglig oppdatert og stadig lansert nye versjoner av applikasjonen på utviklings serveren, oppdatering av applikasjonen på QA (Quality Assurance) serveren har blitt utført ca 2 ganger i uken og i forkant av møter. Dette har vært svært gunstig i forbindelse med testing og kartlegging av eventuelle utfordringer med drift i ulike miljøer og på ulike plattformer. Final version, siste versjon som ble levert etter sommeren, «produktet». Inkrementell utvikling metode Inkrementell utvikling skiller som modellen viser aktivitetene spesifikasjon, utvikling og validering. Produktet blir utviklet gjennom en serie av utgivelses versjoner hvor hver versjon inneholder ny funksjonalitet sammenlignet med tidligere versjoner. 15

17 Inkrementell utvikling baserer seg på en ide om å konstruere en initiell versjon ut i fra en Outline Description, så fremvise dette til brukeren og åpne for kommentarer og tilbakemeldinger. Denne prosessen repeteres helt til en tilfredsstillende versjon av produktet har blitt utviklet. Inkrementell utvikling har ikke uten grunn de siste årene blitt mer og mer populært, og er en fundamental del av en Agile approach. En av grunnene til at inkrementell utvikling har vokst mye de siste årene er at denne tankemåten tar utgangspunkt i hvordan vi løser problemer praktisk generelt. Vi finner sjeldent den beste løsningen på et problem i forkant, men steg for steg løser problemet seg, gjør vi noe feil, tar vi et steg tilbake og prøver igjen. Ved å utvikle et produkt på denne måten er det enklere og rimeligere å gjøre endringer. Hver gang en ny versjon av produktet blir lansert blir mer funksjonalitet lag til, de viktigste funksjonene blir lagt til først. På denne måten kan brukeren på et tidlig stadige i utviklingsprosessen få et generelt inntrykk av om systemet leverer det som er forventet. Det vil også være enklere og rimeligere å kun gjøre endringer av siste versjon vis brukeren/oppdragsgiver ikke er fornøyd med nyeste funksjon som er lagt til. Alternativt vil applikasjonen i sin helhet bli vurdert etter lansering med en plan-styrt utvikling, endringer på dette tidspunktet vil være dyrere og mer omstendelige å få gjennomført. Sist men ikke minst vil inkrementell utvikling føre til raskere levering av brukbar programvare en for eksempel plan-styrt applikasjons utvikling. Deployering av applikasjonen kan gjøres selv om ikke alle funksjoner er implementert. Agile utvikling Programvareutvikling prosesser som baserer seg på en plan som spesifiserer produktet fra design til test helt og fult, fungerer dårlig for nåtidens hurtige programvare utvikling. Forventningen i dag er en helt annen en for bare ti år siden. IT har alltid vært i en konstant utvikling, men den hastigheten dette beveger seg med i dag, har aldri tidligere vært så høy, dette stiller stadig nye krav til utviklerne. Et behov for programvare som defineres i dag, er det behov for i dag og oppdragsgiver skulle gjerne sett at programvaren var implementert dagen før, om en uke igjen er behovet kanskje forandret. Dette er den tiden vi lever i og vi må tilpasse oss disse behovene. Det er viktig her å presisere at det i denne sommeroppgaven er blitt avsatt avtalt tid og det har ikke under noen omstendeligheter vært press for å få utgitt et produkt. Den mest kjente Agile utviklings metode er Extreme Programming (XP). Dette er en utviklings strategi som er ment for å forbedre kvaliteten på programvaren og for å raskt underveis tilpasse seg forbrukerens behov, vi har valgt å benytte denne strategien. Extreme Programming XP er den mest kjente og brukte strategien ved Agile Software utvikling. I XP er kravene til systemet uttrykket ved ulike scenarioer (user stories), i våres oppgave var deler av oppgaven definert som ulike scenarioer (lån, levering, rapportgenerering). XP kjennetegnes ved at det blir utgitt/publisert mange versjoner av produktet underveis for vurdering og evaluering. Publiseringen er 16

18 ikke offentlig men intern i et lukket utvikler miljø for intern testing og bruk. Vi har utgitt mer en 40 ulike publiseringer i løpet av sommeren i utviklingsmiljøet vi har brukt. Dette for å teste, vurdere og verifisere ulik funksjonalitet som har blitt lagt til applikasjonen underveis. Det er også viktig ved XP at utviklerne hele tiden er åpne for å endre produktet, brukerne og oppdragsgiver er i konstant dialog med utviklerne og kan komme med endringskrav når som helst. Andre kjennetegn ved XP: Programmering Respekt Mot Tilbakemeldinger Enkelhet Kommunikasjon Første uke på GBS (uke 2) ble mye av tiden brukt til å bli kjent med Visual Studio, C# og MVC konseptet. Vi jobbet individuelt med hver vår test applikasjon i eget tempo og brukte mye tid på forståelse rundt programvaren. Vi ser tilbake på denne tiden som viktig og vis tidsrammene hadde vært større ville vi gjerne brukt mer tid på dette. I slutten av uken samlet vi oss rundt en applikasjon og et område på TFS serveren og startet produksjonen av «brukbar» kode. De siste ukene før levering måtte vi refrakturer (skrive om) noe av den koden som ble produsert i denne perioden, for optimalisering av brukeropplevelse og forbedring av struktur. Vi ser positivt på dette, utbytte og læringen gjennom disse ukene har vært enorm, og naturligvis finner vi bedre løsninger underveis. Dette er helt i tråd og fundamentalt i inkrementell utvikling. Oppsummering applikasjons utvikling Vi har valgt en inkrementell agile utviklings metode, hvor vi har praktisert strategien Extreme Programming (XP). Serverbruk Utviklings miljø Vi har benyttet en Development server fra uke to hvor vi har «rullet ut» mer en 40 ulike deploeringer. Dette har vært et område vi har jobbet dirkete på, vi har hatt «full control» rettigheter for å kunne slette endre og publisere ulike versjoner direkte fra våres arbeidsstasjoner. Dette har vært et viktig samlingspunkt for oss to i kombinasjon med TFS. Her har vi hatt mulighet til å teste nye funksjoner i applikasjonen i et miljø som er svært likt det endelige miljøet applikasjonen vil bli publisert på. 17

19 Test miljø Quality Assurance / test miljøet ble satt opp i uke fem og har vært satt opp identisk med produksjon miljøet applikasjonen endelig skal deploeres til. Dette miljøet har ikke vært tilgjengelig for sluttbrukerne og har vært våres «nivå 2» deployerings nivå. Frekvensen på deployering til QA har vært langt lavere en til utviklingsmiljøet. Vi har oppdatert QA 1-2 ganger i uken, dette er en større prosess og må gjøres med «enquiry» via serivce@statoil.no Produksjons miljø Vi har ved overlevering av applikasjonen ikke fått tildelt en produksjons server, applikasjonen er å anse som klar for produksjon. Oversikt 18

20 Videre bruk av applikasjonen Optimal bruk For optimal brukeropplevelse av applikasjonen bør applikasjonen brukes med strek kode leser kombinert med strek kode etiketter. Funksjonalitet for utskrift av etiketter fra applikasjonen er under overlevering i august kun delvis implementert. Derimot kan standard «gult nummer» etikett fra Statoil benyttes. Disse kan leses manuelt eller med strekkodeleser og kan benyttes som serie nummer i applikasjonen. Det er viktig å presisere at valg av serie nummer (primær) som skal benyttes i applikasjonen til å identifisere en enhet er opp til den aktuelle plattformen. Serienummeret kan være produsentens serienummer, et lokalt serienummer som installasjonen benytter for å merke enheter eller «gult nummer» etikett fra Statoil. Serienummeret som velges bør være unikt per enhet, det bør også være et nummer som er godt synlig på enheten slik at ulike brukere av applikasjonen ikke vil forveksle numrene. Applikasjonen vil fungere i alle nettlesere, under testing har det vist seg at brukeropplevelsen er best i nettleseren Google Chrome denne nettleseren er installert på alle Statoils maskiner. I Internet Explorer bør IE Browser Mode være satt til IE9 ikke IE9 Compatibility View, Document Mode bør settes til IE9 Standards. Disse innstillingene er ikke standard på Statoil sine maskiner og gjøres ved å trykke F12 +utføre valg i Internet Explorer. Videreutvikling En Software applikasjon er aldri «ferdig» den er konstant under utvikling og evolusjon. Vi er helt sikre på at det vil oppstå mangler og utfordringer med applikasjonen i framtiden. Vi vil på ingen måte fraskrive oss applikasjonen og vi vil være tilgjengelig for utbedring, optimalisering og overføring av eksisterende data i fremtiden, ukebasert i løpet av semester eller en annen sommer. 19