ThrustFlow Management Brunvoll AS

ThrustFlow Management
Aleksander Barstad
Utarbeidet av
Eivind Hestnes Ole Jørgen Eide
i

Innholdsfortegnelse
FORPROSJEKT .................................................................................................................................... 1
1. Mål og rammer ......................................................................................................................................... 1
1.1. Bakgrunn ................................................................................................................................................. 1
1.2. Prosjektmål ............................................................................................................................................. 1
1.3. Rammer ................................................................................................................................................... 2
2. Omfang ..................................................................................................................................................... 2
2.1. Detaljert oppgavebeskrivelse .................................................................................................................. 2
3. Prosjektorganisering ................................................................................................................................. 4
3.1. Ansvarsforhold ........................................................................................................................................ 4
3.2. Øvrige roller og bemanning..................................................................................................................... 4
4. Planlegging, oppfølging og rapportering ................................................................................................... 5
4.1. Hovedinndeling av prosjektet ................................................................................................................. 5
5. Statusmøter og beslutningspunkt ............................................................................................................. 7
5.1. Statusmøter ............................................................................................................................................. 7
5.2. Beslutningspunkt ..................................................................................................................................... 7
6. Risikoanalyse ............................................................................................................................................ 7
7. Gjennomføring ......................................................................................................................................... 9
KRAVSPESIFIKASJON .................................................................................................................... 10
8. Use case diagram .................................................................................................................................... 10
8.1. Kommentarer til Use case-diagrammet ................................................................................................ 10
8.2. Risikoanalyse av use-case diagrammet ................................................................................................. 11
8.3. Høy-nivå use case beskrivelser .............................................................................................................. 11
9. Detaljert use case beskrivelse og sekvensdiagram .................................................................................. 13
10. Kvalitetsmessige krav ......................................................................................................................... 15
11. Konseptuelt klassediagram ................................................................................................................. 16
11.1. Illustrasjon ............................................................................................................................................. 16
11.2. Kommentarer til konseptuelt klassediagram ........................................................................................ 16
ARKITEKTUR ................................................................................................................................... 17
12. Strukturorganisering ........................................................................................................................... 17
12.1. Konklusjon ............................................................................................................................................. 18
13. RUP 4+1 .............................................................................................................................................. 19
13.1. Process View ......................................................................................................................................... 19
13.2. Logical- og Implemenation View ........................................................................................................... 20
13.3. Deployment View .................................................................................................................................. 23
EVALUERING AV EGET ARBEID ..................................................................................................... I
ii

Forprosjekt
1. Mål og rammer
1.1. Bakgrunn
Brunvoll AS produserer komplette thruster-produkter (sidepropell for båter) med service fra A til Å. Med en
thruster fra Brunvoll AS får en solid kontroll over skipet, om det så skulle være å ligge posisjonert i kraftig
sjøgang eller bare manøvrere til kais. Brunvoll AS skreddersyr thrusteren etter kundens behov, noe som gjør
bedriften konkurransedyktig da dette kutter ned på installasjonstid og arbeidskostnader for kunden.
Brunvoll AS tilbyr et komplett teknologisk miljø med ekspertise innen hydraulik, hydrodynamikk, elektronikk og
mekanikk.
Bedriften ble opprettet i 1912 av brødrene Andreas og Anders Brunvoll. Siden den gang har bedriften vokst og
blitt en av verdens ledende leverandører av thruster-produkter.
Siden år 2000 har virksomheten ekspandert i stor grad. Fabrikken er utvidet med to nye produksjonshaller og
leter stadig etter flere ansatte på alle plan. Dette igjen øker behovet for et nytt salgs-, produksjons- og
servicesystem.
I dag eksisterer det ingen integrasjon i systemene mellom salgs-, produksjons- og serviceavdelingen. De
ordrene som salg registrerer, blir skriftlig overført til produksjonslederne, som igjen fordeler oppgavene
muntlig etter hvilke ordrer som haster. Enkelte oppgaver tar få timer, mens andre kan være av lengre varighet.
Problemet er at det oppstår mye dødtid da produksjonslederne har liten oversikt over hvem som gjør hva, og
hvem som eventuelt har ledig kapasitet til nye oppgaver. Da aktivitetene ikke loggføres systematisk, er det
tidkrevende for serviceavdelingen å gå inn på en spesifikk leveranse for å se hva som er gjort. Dette gjør at mye
tid går med på å innhente informasjon om leveransen før vedlikehold kan utføres.
Dette er faktorer som gjør at Brunvoll AS har et behov for å få effektivisert og systematisert arbeidsflyten
mellom de ulike avdelingene.
1.2. Prosjektmål
Resultatmål
Informasjonssystemet (”TrustFlow Management”) skal gjøre arbeidsflyten mellom de ulike avdelingene i
Brunvoll AS mer effektiv og systematisert.
- Et arbeidsflytsystem som effektiviserer produksjon av thrustere og leveranse av tjenester.
- En elektronisk arbeidsplan for den enkelte arbeider slik at arbeidstiden kan disponeres bedre.
- En tett integrasjon av systemet for materiellageret, slik at oppgaveprioritering i produksjonen kan gjøres
etter hva som er mulig å produsere.
- Loggføring av alle hendelser tilknyttet livsløpet til et produkt
Effektmål
- Redusere dødtid i produksjon med 40%
- Effektivisere produksjonen med 10%
- Motivasjonskapende for produksjonsarbeiderne da det gis større innblikk i hva som produseres til hvilke
kunder, noe som på sikt vil kunne føre til økt effektivitet.
- Kundeservice vil kunne bedres da det holdes full kontroll på hvor langt et produkt har kommet i
tilvirkningen.
1

1.3. Rammer
Utviklingen av systemet har en tidsramme på 7 måneder. Den 24. oktober innvier Brunvoll AS sine nye
produksjonshaller og det er et ønske om at informasjonssystemet er i drift til da.
Det vil totalt være 11 personer involvert i utviklingen av systemet. Det vil faktureres 6 millioner på grunnlag av
personellet og 2 millioner i rene investeringsutgifter i software og annet utstyr som trengs. Dette gjør at det
budsjetteres med ca. 8 millioner kroner.
Brunvoll AS bruker fra før IBM Lotus som plattform for distribuert programvare, og IBM DB2 som database. Til
design av thrustere benyttes det IBM Catia. Ettersom det er kompetanse og eksisterende systemer på denne
plattformen, er det et ønske om å bruke IBM Lotus som plattform for det nye informasjonssystemet.
2. Omfang
2.1. Detaljert oppgavebeskrivelse
Brunvoll AS er i sterk vekst på alle områder, men har ikke et felles informasjonssystem som sørger for at
arbeidsflyten mellom de ulike avdelingene kan foregå over samme plattform. Hver avdeling jobber mot egne
systemer, og det er ikke mulig å loggføre et sammenhengende livsløp til et produkt. Oppgaven er derfor å lage
et informasjonssystem (”TrustFlow Management”) som skal gjøre arbeidsflyten mellom de ulike avdelingene i
Brunvoll AS mer effektiv, systematisert og sammenhengende. Det skal legges stor vekt på at flyten skal gå
kontinuerlig fra en ordre er registrert til produktet er ferdig levert. I produkttilvirkningen skal
produksjonslederne ha god oversikt over hvilket materiell og personell som er tilgjengelig, slik at den enkelte
arbeider alltid har en definert arbeidsplan. Systemet vil involvere alle avdelinger i bedriften, og skal integreres
mot eksisterende løsninger for lagerbeholdning, personelloversikt og faktura- og regnskapsadministrasjon. Da
systemet vil involvere alle avdelinger, må systemet tilpasses den enkelte brukergruppes behov slik at de
eksisterende forretningsprosessene kan foregå som før.
Salgsavdelingen har kontakt med kunder over telefon og e-post, og deres primæroppgave er å selge produkter-
og tjenester med leveranse til riktig pris og avtalt tid. De har derfor behov for å kunne ajourføre et
kunderegister, slik at det kan holdes oversikt over hvilke kunder som er i omløp og hvem som er potensielt nye
kjøpere. I tillegg skal de kunne knytte ordrer opp mot kunder, og velge ut produkter- og tjenester fra en
varekatalog utarbeidet av designavdelingen. I ordren er det ønske om at pris og leveringsbetingelser skal
fremkomme slik at datautveksling mot eksisterende faktura- og regnskapssystem kan gjøres automatisk. Dette
vil bidra til at fakturering kan gjøres fortløpende og at detaljeringsgraden og kvaliteten økes betraktelig.
Det er designavdelingen sitt ansvar å utarbeide produktbeskrivelser og CAD-utlegg, og de jobber derfor tett
med salgsavdelingen ved spesialbestillinger. Designavdelingen skal kunne utarbeide en varekatalog med de
vanligste produktene, og samtidig legge inn spesialprodukter for kunder som har behov for dette. Dette utgjør
et paradigmeskifte for Brunvoll AS da salgsavdelingen velger ut produkter- og tjenester fra en varekatalog
direkte i ordren, fremfor at designavdelingen må involveres ved hver enkelt ordre. Dette vil utgjøre en
betydelig effektivisering i begge avdelinger. Produkter i varekatalogen som må tilvirkes av
produksjonsavdelingen ønskes integrert med lagersystemet slik at materiellbehovet kan leses ut direkte.
Når ordren er lagt inn i systemet, skal den kunne frigjøres for produksjon slik at den havner under
produksjonsavdelingen sitt domene. Produksjonslederne skal kunne få fram en prioritert oversikt over hvilke
produkter som skal tilvirkes, og et materiellbehov med lagerstatus for den enkelte komponent. Det er et ønske
å integrere systemet opp mot personelloversikt, slik at produksjonslederen kan tilordre oppgaver til den
enkelte arbeider etter hva som er på lager, og lar seg produsere. Gjennom en elektronisk arbeidsplan, får den
enkelte arbeider opp sine arbeidsoppgaver for dagen. På den måten vet hver enkelt arbeider hva som skal
2

gjøres, hvor komponentene som skal monteres befinner seg, og hva som er neste oppgave etter fullføring. Det
er også et ønske om at det skal være mulig å få frem informasjon om hvilken kunde som har bestilt produktet,
og hvilket skip det skal installeres i. Intensjonen med dette er å skape motivasjon, da den enkelte arbeider ser
sin rolle og oppgave i en større kontekst.
Når produktet er ferdig tilvirket, er det ønske om at lageravdelingen skal kunne gå inn og tilordre en
lagerplassering for midlertidig oppbevaring. Videre skal de kunne koordinere transportbestilling for leveranse
av ferdigstilte produkter.
I etterkant av leveranse, er det behov for serviceoppfølging. Serviceavdelingen har derfor behov for å kunne
framskaffe informasjon om leverte produkter, slik at de vet hvilken løsning som er benyttet, hvor den er
installert og hva som eventuelt trengs av utstyr og materiell for å utføre servicen. Det vil også være ønskelig å
kunne se hva som er gjort av tidligere service.
Da alle avdelinger i Brunvoll AS vil benytte systemet, vil det være mulig å loggføre all aktivitet som er gjort i
tilvirkningen av produktet gjennom hele livsløpet. På den måten kan det leses ut statistikk på feilprosenter,
tidsforbruk, arbeidsbelastning og annen data som kan bidra til å effektivisere produksjonen.
Ordre Service
Salg og design i tett
samarbeid
Figur 1: Informasjonsflyten mellom avdelingene
Produksjon tilvirker
produkt
Vi ser for oss at informasjonssystemet deles opp i 2 hovedleveranser, slik at utviklingstiden kan reduseres.
- Leveranse 1
o Rammeverk og database: Rammeverket er en felles plattform for de øvrige leveransene, og
tilbyr et felles grensesnitt for kommunikasjon med databasen. Dette muliggjør en langt mer
effektiv utvikling, og gjør at systemet kan utvides i ettertid.
- Leveranse 2 (består av tre brukerspesifikke aktiviteter som går parallelt)
o Salg og design: Brukerfunksjoner rettet mot salg- og designavdeling.
o Produksjon: Planleggingsverktøy for produksjonsledere og integrasjon mot lagersystem.
Elektronisk arbeidsplan for arbeidere med oppgavebeskrivelser og materielloversikt.
o Lager og service: Verktøy for koordinering av transport og midlertidig lagerplassering av
ferdige produkter. Servicehistorikk på leverte produkter.
Det stilles følgende krav fra Brunvoll AS til systemet.
Koordinering transport og
leveranse av ferdig produkt
- Prestasjonskrav: Systemet må være brukervennlig for en aldersgruppe fra 16 til 70 år og for personer
fra ulike nasjonaliteter. Brukervennlighet gjelder spesielt for produksjonsarbeiderne. Enkelte deler av
systemet må være tolerant for feil, og ha en garantert oppetid på 99,9% per år.
- Offentlige krav: Personvernloven må overholdes når det gjelder loggføring av aktiviteter tilknyttet
produksjonen.
3

3. Prosjektorganisering
3.1. Ansvarsforhold
Bedriften AEO consulting er en IT-bedrift bedrift med spesialkompetanse iinnen
nnen prosjektkoordinering av
informasjonssystemer. systemer. AEO consulting har blitt innleid av Brunvoll AS for å utvikle informasjonssystemet
(”ThrustFlow Management”). . For å kunne realisere dette må AEO EO consulting leie inn ekstern arbeidskraft på
områdene programmering, SU (systemutv (systemutvikling) design/arkitektur og QA (kvalitet og forsikring forsikring).
3.2. Øvrige roller og bemanning
S.U
design/arkitektur
Figur 2: Prosjektorganisering
Økonomi/Innkjøp
Gruppeleder
Rammeverk og
database
Styringsgruppe
Prosjektleder
Teknisk sjef
Styringsgruppen
Styringsgruppen i prosjektet består av følgende personer personer:
- Administrerende direktør: Terje Dyrseth (Brunvoll AS)
- Prosjektleder: Ole Jørgen Eide (AEO consulting)
- Avdelingsleder lager/service: John Pettersen (Brunvoll AS)
- Avdelingsleder produksjon: Robert Sesseng (Brunvoll AS)
- Avdelingsleder leder salg/design: Kåre Johansen (Brunvoll AS)
- IT-sjef: Lars Kristian Flor (Brunvoll AS)
Prosjektleder er Ole Jørgen Eide fra AEO consulting, da han har domenekunnskap om bedriften.
Styringsgruppen består kun av én person fra AEO consulting, resten er personell fra Brunvoll AS. Inndeling av
styringsgruppen er tatt på bakgrunn av at prosjektet skal gå med nære bånd til bedriften og de ansatte, slik at
produktet blir tilpasset de ulike brukergrupper som skal bruke dette i sitt daglige virk virke.
Styringsgruppen er med på statusmøter og beslutningspunkt av strategisk karakter.
Arbeidsgruppen
Arbeidsgruppen har møter på 15 minutter hver morgen kl. 09.00 slik at status på prosjektet kan følges
kontinuerlig. Her benyttes det ”whiteboard”, og det er ikke tillatt å sitte slik at noen kan ”sove seg gjennom”
møtene.
Arbeidsgruppen n består av følgende personer:
Gruppeleder
Brukermodul 1
- Prosjektleder: Ole le Jørgen Eide (AEO consulting)
- Teknisk sjef: Eivind Hestnes (AEO consulting)
- SU design/arkitektur: (Ekstern/innleid)
QA
Gruppeleder
Brukermodul 2
Gruppeleder
Brukermodul 3
4

- Gruppeleder ”leveranse 1” og ”leveranse 2: salg og design”: Frank Berntsen (Ekstern/innleid fra IBM
Consulting)
- Gruppeleder ”leveranse 2: produksjon”: Hege Mørch (Ekstern/innleid fra Accenture)
- Gruppeleder ”leveranse 2: lager og service”: Trond Sæther (Ekstern/innleid fra Accenture)
- QA (Kvalitetssikrer og forsikring): Gaute Myklebust (Ekstern/innleid)
- Økonomi/innkjøpsansvarlig: Aleksander Barstad (AEO consulting)
Det er viktig å bemerke at QA og SU design/arkitektur kun er tilgjengelig i begrensede perioder. Det samme
gjelder økonomi/innkjøpsansvarlig da han er tilknyttet flere prosjekter. De resterende i arbeidsgruppen må
derimot møte hver mandag kl. 09.00 for diskusjon av fremdriften i prosjektet.
Ansvarlig for økonomi og innkjøp er Aleksander Barstad fra AEO consulting. Han vil være ansvarlig for innkjøp
underveis i prosjektet, og har det overordnende økonomiske ansvaret for at budsjettrammene holdes. Et nært
samarbeid med økonomidirektøren i Brunvoll AS sørger for at de nødvendige fullmakter og midler kan skaffes
til veie underveis i prosjektet.
Teknisk sjef er Eivind Hestnes fra AEO consulting, og har det overordnede ansvaret for de forskjellige
leveransene og SU design/arkitektur. Stillingen vil være å koordinere de forskjellige ansvarsområdene som
følger under han, og følgelig er de daglige statusmøtene hans ansvar. Personellansvaret til teknisk sjef er
gruppeledere og SU design/arkitekturansvarlig.
Alle som befinner seg under teknisk sjef er innleide personer. Dette er gjort bevisst for å få inn den beste
kompetansen på de forskjellige områdene. Gruppelederen fra IBM Consulting har ansvaret for to leveranser, da
”leveranse 1” og ”leveranse 2: salg og design” ikke går parallelt tidsmessig, noe som gjør at kompetansen
utnyttes til det maksimale. Det er ønskelig at prosjektet skal være robust mot personellendringer, så som et
tiltak mot dette er alle gruppelederne med i utviklingen av ”leveranse 1” da dette er grunnlaget for den videre
utviklingen.
Når utviklingen av leveranse 2 igangsettes, skal de tre gruppelederne for hvert delprosjekt ha en åpen
kommunikasjon med de respektive avdelingene hos Brunvoll AS. Dette gjøres for å sikre maksimal forståelse av
forretningsprosesser og brukerbehov, slik at systemet virkelig oppfattes av brukerne som et verktøy i
hverdagen.
QA er også innleid i en begrenset periode, men vil delta kontinuerlig rundt ferdigstilling av leveranser.
Primæransvaret er å kvalitetssikre arbeidet, og sørge for at utviklingen går i henhold til kravspesifikasjon.
4. Planlegging, oppfølging og rapportering
4.1. Hovedinndeling av prosjektet
I utviklingen av systemet, mener vi det vil være mest hensiktsmessig å benytte arbeidsprosessen ”fossefall med
delprosjekter” med innslag av planutvikling. Før vi kom fram til denne arbeidsprosessen, vurderte vi en del
andre som vi kommer tilbake til i slutten av dette avsnittet.
- Systemet er delt opp i to hovedleveranser: ”leveranse 1: rammeverk/database” og tre
Leveranse 1: Rammeverk/database
Figur 3: Tidsforløp
Leveranse 2:
Salg og design
Produksjon
Lager og service
5

ukerspesifikke aktiviteter i leveranse 2. I planutvikling blir systemet utviklet i suksessive stadier etter
prioritet. Ettersom det eksisterer en hierarkisk avhengighet mellom de to leveransene, er det viktig at
tidsfristen for den første overholdes. Det er mange brukergrupper som involveres i neste leveranse,
så forskyving av tidsfristen i første fase av prosjektet er ikke ønskelig. Planutvikling gir oss en god
strategi ved å legge hovedfokus på den viktigste aktiviteten, som i dette tilfellet er
rammeverk/database. Det vil ikke være mulig å påbegynne utviklingen av neste leveranse før det er
mulig å hente/lagre data fra/til databasen gjennom rammeverket. Det er derimot mulig å utvide
rammeverk/database underveis og i etterkant av prosjektet, dersom det er ønskelig med mer
funksjonalitet.
- Når første leveranse er ferdigstilt, kan de brukerspesifikke aktivitetene i leveranse 2 påbegynnes. Da
det ikke eksisterer utviklingsmessige avhengigheter mellom disse aktivitetene, kan de foregå parallelt
slik at det jobbes direkte mot hver brukergruppe samtidig. Vi kan derfor dele utviklingen av denne
leveransen inn i delprosjekter. Dette vil være tidsbesparende, og en sørger samtidig for at leveransen
tilpasses brukergruppens behov. Da prosessen både er iterativ og inkrementell er det mulighet for
endringer underveis etter ønske fra brukerne. Det vil da være mulighet for å teste leveransene
enkeltvis, slik at tilpassinger og feilretting kan gjøres direkte mot brukergruppen. Det å utvikle og teste
enkeltmoduler separat er også en måte å spre risiko på, slik at det ikke oppdages store feil i slutten av
utviklingen.
- Hovedrisikoen ved denne arbeidsprosessen er uforutsette gjensidige avhengigheter mellom
delprosjektene. Ettersom siste leveranse er tilknyttet rammeverket, og aksesserer databasen gjennom
dette, vil det ikke være noen gjensidighet mellom de brukerspesifikke delprosjektene. Den gjensidige
avhengigheten ligger følgelig mellom delprosjektene og rammeverk/database, og som nevnt er det
her mulighet for å gjøre utvidelser.
- Arbeidsprosessen er strukturert og ivaretar systemdokumentasjon så vel som brukerdokumentasjon
på en tilfredsstillende måte. God dokumentasjon er med på å sikre driftsstabilitet, og gjør det mulig å
videreutvikle den siste leveransen i etterkant av prosjektet.
- Ved å investere tid i rammeverk/database vil de brukerspesifikke aktivitetene kunne gå mer effektivt,
da det ikke trengs å ta høyde for grunnleggende arkitekturmessige spørsmål.
- Svakheten er at arbeidsprosessen tillater ferdigstilling av delprosjektene til forskjellig tid. Selv om det
ikke eksisterer noen arkitekturmessig gjensidighet innbyrdes i den brukerspesifikke leveransen, må det
for eksempel være mulig for salg/design å kunne legge inn oppdrag før produksjon kan benytte
systemet. Systemet kan derfor ikke benyttes fullt i produksjon før delprosjektene salg/design og
produksjon er ferdigstilt.
I den første leveransen, finnes det eksisterende systemer i den programvareplattformen som er valgt. Det er
ønskelig å benytte databasen uten større modifikasjoner, og heller ha fokus på design av datastruktur. Vi vil
separat vurdere kost/nytteeffekt av ferdige komponenter til rammeverket.
En meget nærliggende arbeidsmetode er å benytte fossefallsmetoden rent suksessivt. Modellen er god på
struktur og dokumentasjon, og gjør utviklingsprosessen svært oversiktlig. Det vil heller ikke være nødvendig å
involvere like mye personell samtidig da hver leveranse og aktivitet utvikles suksessivt. Ulempen er at
prosjektet blir strekt ut i tid på grunn av størrelsen, og muligheten for endringer blir sterkt redusert. Da den
siste leveransen er svært brukerspesifikk, må den gjerne tilpasses i flere omganger. Vi har kommet frem til at
det vil være vanskelig å spesifisere den siste leveransen så godt at endringer ikke vil oppstå, og modellen blir
dermed vanskelig å benytte.
6

På grunn av tidsaspektet har eXtreme Programming vært til vurdering. XP er en rask utviklingsmetode hvor
sluttresultatet er i fokus, og har flere praksiser som passer godt inn i utviklingsprosjektet. Av gunstige forhold
kan det nevnes ”on-site customer”, som betyr nær kontakt med kunden. Tre av modulene i prosjektet er svært
brukerspesifikke, og bør tilpasses brukergruppene i stor grad. Det at brukeren får være en del av
systemutviklingsprosessen skaper et felles eierskap, og gjør at brukeren føler en tilhørighet til systemet. Videre
er det fordelaktig med et modulbasert system (små releaser) og en enkel arkitektur som kan utvides. Dette vil
redusere risikoen for avhengighetsfeil, og sørger samtidig for fleksibilitet med tanke på utvidelse av systemet til
å gjelde flere brukergrupper. XP er ikke spesielt kraftig med tanke på dokumentasjon, men tar dette igjen ved å
benytte en metaforisk oppbygging slik at det lett å forstå programkoden.
Selv om XP tilbyr nær kontakt med kunden, er det her økonomiske forhold som må tas i betraktning. Det at
kunden kontinuerlig må være tilstede i utviklingen legger beslag på arbeidskapasitet som ellers kunne vært
benyttet til produksjon. Ettersom kravene for systemet er oversiktlige, vil det være mulig å foreta en
konsentrert spesifisering slik at det ikke er nødvendig å involvere kunden kontinuerlig. En annen fare med XP
er at brukerne i for stor grad styrer prosjektet, slik at det blir for mye fokus på detaljer, og ikke helheten til
systemet. Det siste punktet er at prosjektet vårt er ganske stort i forhold til hva XP er egnet for. Den muntlige
kommunikasjonen vil være vanskelig å gjennomføre da eksterne konsulenter vil bli innleid som nødvendigvis
ikke befinner seg på samme sted.
5. Statusmøter og beslutningspunkt
5.1. Statusmøter
Det vil være separate statusmøter for arbeids- og styringsgruppen. Styringsgruppen vil ha statusmøter ved
strategiske ferdigstillinger, etterfulgt av beslutningspunkt i henhold til gjennomføringsplanen. Arbeidsgruppen
vil også gjennomføre statusmøter etter ferdigstillinger, men vil ha fokus på kvaliteten på systemet og hva som
kan gjøres bedre i neste fase. I tillegg til statusmøter ihht. gjennomføringsplan, vil arbeidsgruppen ha møte
hver mandag kl. 09.00 for diskusjon av framdriften i prosjektet.
5.2. Beslutningspunkt
Som i likhet med statusmøtene, vil styringsgruppen fatte de strategiske beslutningspunktene. De viktigste
beslutningspunktene er om prosjektet skal realiseres, og om modulene er ihht. de krav som er satt.
Arbeidsgruppa vil i forkant av beslutningspunktene ta en vurdering på om systemet innehar ønsket kvalitet, og
hvis nødvendig utføre en ny iterasjon. Beslutningspunktene skal betraktes som fastsatte datoer.
6. Risikoanalyse
Når en skal etablere et systemutviklingsprosjekt og drifte (yte de nødvendige tjenestene til brukerne) dette,
innebærer dette aktiviteter med en viss risiko. I vår risikovurdering har vi vært nødt til å ta hensyn til de mest
kritiske faktorer og muligens sløyfe de som ikke er fult så kritiske. Det er viktig å presisere at det er vanskelig
eller umulig å beskytte seg mot alt.
Analysen vår tar utgangspunkt i følgende figur hvor hvitt område er lav risiko, lys er middels risiko og mørkt er
høy risiko.
7

Tabell 1: Grader av risiko (kilde Risikohåndtering, Øksnes og Furuseth – hentet fra Norbud-prosjekt)
Sannsynlighet
Lite sannsynlig
Sannsynlig
Meget sannsynlig
Svært sannsynlig
Konsekvens
Liten Middels Kritisk Katastrofal
I vår analyse har vi sammen med Brunvoll AS kommet frem til at vi vil akseptere middels risiko eller lavere.
Dette innebærer da at dersom vi kommer frem til punkter som utgjør større risiko er vi nødt til å iverksette
forbyggende tiltak for at denne skal bli mindre sannsynlig eller forsvinne helt. Dersom det viser seg å være
lønnsomt å gjøre noe med risikoer som har mindre enn høy risiko vil vi også prøve å finne tiltak for disse.
Tabell 2: Risikotabell
Pri Risiko Sannsynlighet Konsekvens Risiko-
innvirkning
1 Datatap Meget
sannsynlig
2 Nedetid på Svært
system sannsynlig
3 Interoperabilit
et mellom
eksisterendeog
nytt system
svikter
4 Overskride
budsjett
Meget
sannsynlig
5 Fravær Meget
6 Overskride
tidsfrist
7 Mangel på
kompetanse
Tiltak
Katastrofal Høy Klare krav til hvordan systemet er
bygd opp.
Kristisk Høy Separerte systemer, testing. Klare
krav til hvordan systemet skal være
oppbygd for å unngå dette i størst
mulig grad.
Kritisk Høy Istedenfor sanntidsintegrasjon kan
data repliseres på times- eller
døgnbasis.
Sannsynlig Kristisk Middels Kommer an på omfanget, gode
rutiner når det gjelder styring
underveis. Egen økonomiansvarlig.
sannsynlig
Middels Middels Oppfølging og tilkallings-personell.
Sannsynlig Middels Middels Tidsplan med mindre ”delprosjekter”
underveis. Se ut ifra disse om det er
nødvendig med ekstra bemanning.
Statusmøter.
Sannsynlig Middels Middels Kursing, alle som jobber med
prosjektet har bra innblikk i hva de
andre som programmerer gjør.
Risikotabellen er skrevet i prioritert rekkefølge hvor risikoen er synkende. Risikoinnvirkning er produktet av
konsekvens og sannsynlighet. Her tenker vi da konsekvens i det økonomiske, og det er ut ifra konsekvensen vi
beregner prioritet. Risikotabellen viser en generell fremstilling av risikobildet i prosjektet, og denne brukes som
utgangspunkt videre i prosjektet da det kan oppdages andre risikoer som krever at tabellen må ajourføres.
Risikorapportering vil være en egen del under statusmøtene arbeidsgruppen vil ha daglig i prosjektet.
8

7. Gjennomføring
9

Kravspesifikasjon
8. Use case diagram
Figur 3: Use-case diagram utarbeidet i IBM Rational
8.1. Kommentarer til Use case-diagrammet
Vi vil spesielt kommentere Use casen ”Hent produkteksemplar” da denne er rettet mot flere aktører. Et
produkteksemplar gjennomgår flere livsfaser, og vi har sortert disse til å være ”på vent”, ”venter på
produksjon”, ”under produksjon”, ”på lager” og ”ferdig levert”. Det er aktøren ”Salgsperson” som oppretter
bestillingsordren, og vil følgelig være den initierende part til produksjon av eksemplaret. I livsfasene ”venter på
produksjon” og ”under produksjon” er det aktørene ”Produksjonsleder” og ”Produksjonsarbeider” som i
hovedsak er involvert. I etterkant av produksjon vil ”Serviceavdeling” være primæraktør. Det er her viktig å
presisere at informasjonsbehovet er tilnærmet det samme, så det vil ikke være store forskjeller i
hendelsesforløpet. Det er kun aktørene i produksjon som har behov for mer utfyllende informasjon om
materiellbehov, og dette er vist som en initiering til aktøren ”Lagersystem”.
Videre er det nødvendig å kommentere følgende assosiasjoner.
- (produktkatalog): Når aktøren ”Designingeniør” skal behandle produktkatalogen åpnes da
den eksisterende katalogen, slik at det kan velges produkt som skal oppdateres.
10

- (registrere lagerplassering): Når aktøren ”Lagerarbeider” skal registrere lagerplassering
hentes det først ut data om ferdigstilte produkteksemplar, slik at kriterier for plassering kan gjøres ut i
fra størrelse og vekt på produktet.
- (administrere arbeidsplan): Administrere arbeidsplan er en utøkning (endring) av
eksisterende arbeidsplan (vis arbeidsplan), da det vil være behov for å ha en totaloversikt på den
eksisterende arbeidsplan før det gjøres endringer.
8.2. Risikoanalyse av use-case diagrammet
Vi har delt inn hvert enkelt use case i tre forskjellige risikoområder, og utarbeidet høy-nivå beskrivelser for de
mest risikable. Vi har klassifisert risiko etter:
- Teknologisk risiko: I hvilken grad er det mulig at vi ikke har teknologien til å gjennomføre hvert use
case.
- Forretningsmessig risiko: Hvor viktige er use casene sett ut fra de krav kunden har satt
- Prosjektmessig risiko: I hvilken grad use casene kan føre til problemer da med tanke på samarbeid og
organisering.
Use Case Teknologisk Forretning Prosjekt Sum/total
Vis produksjonsstatistikk Lav Lav Lav Lav
Hent produkteksemplar Høy Høy Høy Høy
Administrere arbeidsfordeling Middels Høy Høy Høy
Personelloversikt Middels Middels Lav Middels
Vis arbeidsplan Høy Høy Høy Høy
Oversikt produksjonsmateriell Middels Middels Middels Middels
Ajourføre servicehistorikk Lav Middels Middels Middels
Registrere lagerplassering Middels Lav Lav Lav
Transportkoordinering Lav Lav Lav Lav
Kundeadministrasjon Lav Høy Høy Middels
Ordrebehandling Middels Høy Høy Høy
Vis produktkatalog Lav Middels Middels Middels
Behandle produktkatalog Middels Lav Middels Middels
8.3. Høy-nivå use case beskrivelser
Use Case Administrere arbeidsfordeling
Aktør Produksjonsleder
Hensikt Effektivisere arbeidsflyt og få mer kontroll over produksjonsgangen.
Beskrivelse Produksjonsleder skal ha mulighet til å organisere/utarbeide arbeidsfordeling for
produksjonsarbeiderne. Aktør forespør ”Administrere arbeidsfordeling” og systemet
responderer med å gi aktøren to ulike valg; eksisterende arbeidsfordeling eller opprett ny.
Velger aktør eksisterende arbeidsfordeling vil systemet gi en oversikt over fordeling av
oppgaver blant produksjonsarbeiderne. Aktør forespør så en bestemt fordeling og systemet
åpner da denne med mulighet for redigering. Aktør gjør eventuelt de endringer som ønskes,
og systemet avslutter med å oppdatere ”Vis arbeidsplan”. Dersom aktør velger ny
arbeidsfordeling, vil systemet åpne en fast mal. Aktøren kan her legge inn en
oppgavebeskrivelse og må spesifisere hvilken produksjonsarbeider planen skal gjelde for.
Når aktør har gjort dette vil systemet oppdatere ”Vis arbeidsplan.”
Use Case Vis arbeidsplan
Aktør Produksjonsarbeidere
Hensikt Effektivisere produksjonsavdelingen og gi større rom for å planlegge arbeidsdagen.
Beskrivelse Aktør skal kunne få en oversikt over hva arbeidsplanen inneholder. Det blir utført en
forespørsel til systemet om å vise arbeidsplan, og systemet åpner da en oversikt over den
gjeldende arbeidsplan for aktøren. Aktøren kan så velge en bestemt arbeidsoppgave, og
systemet returnerer en beskrivelse av den valgte oppgaven. Deretter foretar aktøren en
kvittering av den oppgaven som velges.
11

Use Case Hent produkteksemplar
Aktør Produksjonsleder, salgsperson, servicearbeider, produksjonsarbeider og ”lagersystem”.
Hensikt Gi de enkelte en oversikt over produktet med spesifikasjoner og materielloversikt.
Beskrivelse Aktør forespør produkteksemplar til systemet, og systemet svarer da med å gi en oversikt
over de produkter som er frigjort til produksjon. Aktør kan da lete seg frem til det ønskede
produktet samt velge dette, og systemet vil returnere
produktinformasjonen/spesifikasjonen til det valgte produktet.
Use Case Transportkoordinering
Aktør Lagerarbeider
Hensikt Ha oversikt over transport av produkter til og fra bedriften
Beskrivelse Aktør forespør en oversikt over ferdigstilte produkter, og systemet svarer med å gi en
oversikt over alle produkter og produksjonsstatus. Ved hjelp av denne informasjonen er det
mulig å koordinere transport av ferdigstilte produkter. Aktøren forspør det produktet som
ønskes, systemet gir da aktør mulighet til å legge inn datoer for transport.
Use Case Ordrebehandling
Aktør Salgsarbeider
Hensikt Behandle ordre fra kunder
Beskrivelse Aktøren skal kunne legge inn en ordre og tilknytte artikler fra varekatalogen til den enkelte
ordrelinje. Aktøren forespør systemet om ordrebehandling, systemet åpner da et
ordreskjema, med mulighet for å inkludere ordrelinjer. For den enkelte ordrelinje
spesifiseres det hvilket produkt som ønskes, og systemet foretar en oppdatering av
ordreskjema. Aktør kan så velge å godkjenne ordren, og systemet vil da lagre ordren, og
omgjøre de valgte produktene til konkrete eksemplar.
Use Case Behandle produktkatalog
Aktør Designingeniør
Hensikt Skal ha mulighet til å oppdatere produktkatalogen kontinuerlig
Beskrivelse Aktør forespør behandling av produktkatalog, systemet åpner da for at aktør kan legge inn
nye produkter eventuelt redigere/slette gamle produkter. Da dette er gjort vil systemet
oppdatere produktkatalogen.
12

9. Detaljert use case beskrivelse og sekvensdiagram
Use Case Vis arbeidsplan
Hensikt Senke dødtid i produksjonsavdelingen, samt fremskaffe en oversikt over hvem som gjør hva.
Aktør Produksjonsarbeider
Pre betingelser Aktør av arbeidsplanen må være autentisert.
Post betingelser Use caset henter ut informasjon fra systemet om autorisert brukers arbeidsplan.
Normal
Hendelsesflyt
(”Main success
scenario”)
1. Use caset begynner når bruker autoriserer seg, og sender forespørsel om å
generere dagens arbeidsplan.
2. Systemet viser dagens arbeidsplan, med utlisting av tilgjengelig arbeidsoppgaver
for tidsrommet.
3. Aktøren kan velge å gå direkte til sekvens 5 (velg arbeidsoppgave) eller angi nytt
tidsområdet for arbeidsplan.
4. Systemet viser arbeidsplan for valgt tidsområde, med utlisting av tilgjengelig
arbeidsoppgaver for tidsrommet.
5. Aktør velger arbeidsoppgave fra utlistingen.
6. Systemet viser detaljert beskrivelse av arbeidsoppgaver med CAD-utlegg.
7. Dersom aktør velger å begynne på oppgaven, kvitteres det tilbake til systemet.
Variasjoner 1. Aktør ikke autorisert. Systemet gir aktør en feilmelding om ugyldig autentisering og
ber aktør autentisere seg på nytt.
2. Systemet får ikke hentet arbeidsplan. Systemet vil da gjenta forespørselen opptil 3
ganger med et mellomrom på 3 sekunder. Dersom arbeidsplan fremdeles ikke er
tilgjengelig vil aktør få frem en feilmelding.
3. Aktør spesifiserer et ugyldig tidsrom. Systemet vil da vise en feilmelding med hva
som er gyldig formatering/gyldig tidsrom.
4. Samme som pkt. 2.
6. Systemet får ikke åpnet detaljert beskrivelse av arbeidsoppgave. Systemet vil da
gjenta forespørselen opptil 3 ganger med et mellomrom på 3 sekunder, dersom det
fremdeles ikke foreligger en detaljert beskrivelse vil aktør få frem en feilmelding.
Figur 4: Sekvensdiagram for Use case "Vis arbeidsplan"
13

Use Case Vis produkteksemplar
Hensikt Effektivisere produksjonsavdelingen
Aktør Flere
Pre betingelser Det må spesifiseres hvilket produkteksemplar som skal vises
Post betingelser Aktørene vil kunne hente produkteksemplarer, og etter hvert oppdatere status på produkt.
Normal
1. Use caset starter når aktøren har spesifisert eksemplarnummer, og sendt
Hendelsesflyt
forespørsel om beskrivelse av valgt eksemplar.
(”Main success
1.1. Systemet sender forespørsel om materiellbehov for valgt eksemplar til
scenario”)
lagersystemet. I forespørselen blir det spesifisert hvilket katalognummer
eksemplaret har, slik at lagersystemet kan undersøke status på nødvendig
produksjonsmateriell.
1.2. Lagersystemet returnerer materiellbehov for valgt eksemplar.
2. Systemet viser beskrivelse av valgt produkteksemplar med tilhørende
spesifikasjoner, og materiellbehov sorterer etter materiellgruppe.
3. Aktøren velger materiellgruppe
4. Systemet viser komponentutlisting for valgt materiellgruppe.
5. Aktøren velger komponent for detaljert beskrivelse
6. Systemet viser lagerplassering og monteringsanvising for valgt komponent, slik at
brukeren har nok informasjon til å kunne til å påbegynne produksjonen.
7. Aktøren kvitterer for at komponenten er plukket og montert.
8. Systemet sender materiellforbruk til lagersystem, og gir kvittering på oppdatering
til aktør.
Variasjoner 1. Eksemplarnummer ikke spesifisert eller feil. Systemet gir aktør en utlisting av alle
tilgjengelige eksemplar, slik at det kan velges på nytt fra en liste.
1.1. Lagersystemet svarer ikke på forespørsel. Systemet vil da gjenta forespørselen
opptil 3 ganger med et mellomrom på 1 sekund. Dersom lagersystemet fremdeles
ikke svarer, vil aktør få opp en feilmelding.
1.2. Lagersystemet finner ikke materiellbehov for gjeldende katalognummer, og
returnerer en tom liste. Systemet fortsetter på sekvens 2, men viser ikke
materiellbehov. Det vil ikke være mulig å gå videre til sekvens 3.
8. Lagersystemet svarer ikke. Systemet vil da gjenta forespørselen opptil 3 ganger
med et mellomrom på 1 sekund. Dersom lagersystemet fremdeles ikke svarer, vil
aktør få opp kvittering på oppdatering, og systemet vil gjenta forsøk på
oppdatering i bakgrunnen hvert minutt.
Figur 5: Sekvensdiagram for Use case "Vis produkteksemplar"
14

10. Kvalitetsmessige krav
Brukervennlighet
Brukergrensesnittet for systemet blir forskjellig ut i fra hvilken målgruppe den er beregnet:
- Produksjonslederne har kompetanse på databehandling slik at et komplekst brukergrensesnitt kan
tillates. Kursing i dette systemet skal ikke ta mer enn en uke. Det skal være hjelpedokumentasjon
tilgjengelig.
- Produksjonsarbeiderne har varierende dataferdigheter, og har et alderspenn fra 16 til 65 år.
Brukergrensesnittet til arbeidsplanen må derfor være enkelt og intuitivt å håndtere. Det må også tas
hensyn til brukere med forskjellig nasjonalitet. Arbeidsspråket i bedriften er primært norsk, hvor
sekundær språket er polsk og engelsk. Det skal være mulig å skifte mellom disse tre språkene med et
tastetrykk. Kursing med varighet lengre enn en dag, skal ikke være nødvendig.
- Salg- og designavdelingen har stor kompetanse på databehandling, og kan også tillates et komplekst
brukergrensesnitt. Fokus bør være å få likhet med systemer de har fra før. Kursing skal ikke være
nødvendig.
- Lager- og serviceavdeling har middels kompetanse på databehandling, men brukergrensesnittet bør
være lett å bruke. Det skal ikke være nødvendig med mer enn en enkel innføring.
Ytelse
- Systemet må kunne lagre 10 000 ordrer med historikk, men samtidig være skalerbart.
- Systemet skal operere i sanntid, selv på tvers av brukermoduler.
- Systemet skal takle minst 60 simultane brukersesjoner uten at det går utover andre krav.
Pålitelighet
- Minimumskrav til oppetid på systemet er 99.9% per år.
- Lagret data skal repliseres i sanntid til sekundærsystem.
- Inkrementell sikkerhetskopi skal gjennomføres 1 gang daglig. Full sikkerhetskopi gjøres 1 gang i uken.
Sikkerhet
- Systemet skal kun være mulig å aksessere innenfor Brunvoll AS sitt datanettverk. Ekstern tilgang skal
kun være mulig over kryptert VPN-forbindelse.
- Personopplysninger om kunder og ansatte skal være iht. personopplysningsloven §28
Vedlikeholdslettende krav
- Systemet skal utvikles på plattformen IBM Lotus/DB2
- Systemet skal kunne kjøres på Windows XP eller høyere, og må kunne emuleres på plattformer som
OS X og Linux.
Standardiserte krav
- All data som ved vekt og mål, skal det brukes SI-eneheter (meter, sekunder, osv…).
Dokumentasjon
- All dokumentasjon om systemet skal samles i en teknisk rapport.
Intraoperabilitet
- Systemet skal kunne kommunisere med eksisterende systemer ved å benytte seg av XML-RPC.
15

11. Konseptuelt klassediagram
11.1. Illustrasjon
Figur 6: Konseptuelt klassediagram
11.2. Kommentarer til konseptuelt klassediagram
Det ble gjennomført en diskusjon i arbeidsgruppa på hvilke konseptuelle klasser forretningsbildet i Brunvoll AS i
hovedsak består av. De hjelpemidlene som ble benyttet var å delta i de ulike produksjonsleddene i bedriften,
slik at klassediagrammet i størst mulig grad samsvarer med forretningsbildet. Deretter ble metoden Class
Responsibility Colaboration (CRC) benyttet internt i arbeidsgruppa for å sortere og knytte klassene sammen.
Primæroppgaven til salgsavdelingen er å bedrive salg av produkter- og tjenester. De daglige oppgavene består
følgelig av å registrere ordrer tilknyttet en kunde. I diagrammet er dette illustrert med klassene ”Kunde” og
”Ordre”. Den enkelte kunde kan ha ordrer knyttet til seg, hvor det i ordren legges inn ordrelinjer, som har
direkte relasjon til konkrete produkter- og tjenester (heretter ”artikkel”) som ligger lagret i en katalog. Disse to
objektene er beskrevet med klassene ”Ordrelinje” og ”Katalog”. Det er salg sin oppgave å finne frem til den
artikkelen som kunden etterspør, som utgjør et direkte forhold mellom ordrelinje og en artikkel i katalogen.
Når det er valgt en artikkel fra katalogen, blir den valgte artikkelen omgjort til et konkret eksemplar. På den
måten kan det logges hendelser i produksjonen av eksemplaret, eller leveransen av tjenesten. Hendelser legges
inn i alle ledd av forretningsprosessene, og er kjennetegnet ved klassen ”Eksemplarlogg” som har direkte
relasjon til klassene ”Personell” og ”Eksemplar”.
Det oppstod her en diskusjon hvorvidt hendelsesloggen skulle knyttes til ordren eller eksemplaret. Da
produksjonsavdelingen kun er interessert i produktbeskrivelsen, fant vi det mer komplekst og unødvendig å
knytte hendelsesloggen til ordre.
Designavdelingen er ansvarlig for ajourhold og oppretting av nye artikler i katalogen. Da salg er nærmeste
samarbeidspartner, vil det ved spesielle kundebehov bli laget spesifikke artikler som salg kan legge inn i ordren
på normert måte. Det viktigste objektet for design er katalogen, og er i diagrammet beskrevet med
superklassen ”Katalog”. Grunnen til at det benyttet en superklasse, er at det må skilles mellom produkter som
16

skal gå til produksjon, og tjenester som eksempelvis konsulentleveranse. Superklassen generaliseres derfor av
klassene ”Produkt” og ”Tjeneste”, som har hver sine spesifikke attributter. Som vedlegg til CAD-designet i
klassen ”Produkt” ligger det relasjoner til produksjonsmateriell, slik at produksjonsavdelingen kan planlegge sin
aktivitet etter hva som er på lager.
Hos produksjonsavdelingen er det arbeidslederne som fordeler ansvaret i tilvirkningen av konkrete
produkteksemplar. Det opprettes da en arbeidsbeskrivelse som tilordnes den arbeideren som har slik ledig
kapasitet at tidsfristen overholdes. Dette er beskrevet med klassen ”Arbeidsfordeling”, som har relasjon til
klassene ”Personell” og ”Eksemplar” (da fortrinnsvis ”Produkteksemplar”)
Serviceavdelingen kan etter initiativ fra salg lete frem spesifikke produkteksemplar, og se hva som er gjort
under produksjonen slik at eventuell feilretting i etterkant av leveranse kan gå mer effektivt.
Arkitektur
12. Strukturorganisering
Da Brunvoll AS per i dag har et godt utbygget trådbundet TCP/IP-nettverk, og eksisterende systemer benytter
seg av denne plattformen, vil det være hensiktsmessig at det nye systemet implementeres på samme
plattform. De eksisterende systemene har dessuten mulighet til å utveksle data med andre systemer vha. XML-
RPC. Alle klienter benytter seg av Microsoft Windows XP eller nyere som plattform.
Vår diskusjon går ut på hvilken strukturmodell som passer best til vår løsning når vi i utgangspunktet ønsker å
beholde det meste av klienter. Vi kan ta for oss løsningen i ytterpunktene; å legge all prosessering på
klientsiden, eller et distribuert system fra en sentral tjener. Brunvoll AS har i dag datamaskiner som kan
rangeres fra helt moderne til utdaterte maskiner. De har også et ønske om å ta i bruk smarte telefoner/PDAer i
sin drift. Dette gir oss en del begrensninger i forhold til akkurat hvor mye prosessering som kan gjøres på
klientsiden. Fra programmererens synspunkt vil det også være mye mer arbeid å få programmert egne
applikasjoner tilpasset de forskjellige klientene. Dette kan tyde på at vi må gå bort fra en typisk tungdrevet
klient og mer i retning et distribuert system, med enkle klienter hvor det meste av prosessering skjer på
tjenersiden. En løsning som fyller disse kriteriene er for eksempel en webløsning. Denne løsningen gjør oss
veldig knyttet opp mot et nettverk, men her må vi legge følgende argumentasjon til grunne; Systemet skal
kunne kommunisere med forskjellige avdelinger på tvers av bedriften, og følgelig vil det eksistere et
kommunikasjonsbehov. Hvorvidt vi legger mye av systemet på klient eller tjener, vil dette behovet alltid
eksistere.
Vi har gjort følgende vurderinger ut fra de forskjellige strukturmodellene:
- Repository modell er en av strukturorganiseringene vi kan velge. Denne modellen kan tolkes på to
måter; Systemet kan legges i sin helhet på hver enkelt klient, og utveksle informasjon seg i mellom
uten at vi har en sentral tjener innblandet. Dette vil gjøre at svært mange av klientene må byttes ut,
da det vil være et behov for tyngre klienter. Denne modellen vil også lett kunne føre til inkonsistens,
da hver klient er avhengig av å få oppdateringer fra andre klienter. Går en klient ned må det også lages
en mekanisme for å håndtere etterslep av data. Den andre varianten av Repository modell kan tolkes
slik at vi introduserer en tjener som håndterer en felles database for systemet. Data vil da lagres på en
sentral tjener, men mesteparten av prosessering ligger fortsatt på klienten.
- Klient- tjener modellen kan benyttes som en distribuert modell hvor all prosessering skjer på
tjenersiden. Det gjør at systemet kan implementeres uten større endring eller oppgradering på
klientsiden, og at integrasjon mot eksisterende systemer kan gjøres mens de er i drift. Det er også
uproblematisk at klienter benytter av seg av forskjellig operativsystem/plattform, da det kun er
17

nødvendig med en nettleser for å kunne benytte løsningen. Det vil også være mulig å benytte mobile
klienter, såfremt disse kan kobles til nettverket med VPN eller lignende.
- Lagdelingsmodellen er en grei måte å organisere systemet i sin helhet da den deler systemet inn i lag
hvor hvert tilbyr et sett med tjenester. Modellen egner seg ikke til bruk i et distribuert system, men
den forklarer godt hvordan systemet på én datamaskin er organisert.
I henhold til ikke-funksjonelle krav er vi låst til programvareplattformen IBM Lotus/DB2. Dette gjør at vi må
benytte oss av XML som datautvekslingsformat noe som er grunnlaget for vår konklusjon.
12.1. Konklusjon
Rent overordnet har vi valgt å basere oss på Gartner Group sin distribuerte ”klient- tjener modell”. Alt av data
ligger lagret på tjeneren, og klienten sørger kun for visning av presentasjon.
Figur 7: Klient-tjener modell distribuert versjon
For å beskrive systemet i detalj, har vi valgt å benytte oss av en 4-lags lagdelingsmodell. Løsningen vår blir
derfor en kombinasjon av to modeller; klient-tjener og lagdeling. Da utfordringen ligger i arkitektur til systemet,
vil videre beskrivelser ta utgangspunkt i lagdelingsmodellen.
Figur 8: Lagdelingsmodell for systemet
Presentasjonslaget er bindeleddet mellom applikasjonslag og klient, og skal gi brukeren en grafisk fremstilling
av data etter klienttype. Fra applikasjonslaget utveksles det XML-data, som i presentasjonslaget omsettes til
XHTML vha. XSLT-stilark. Det skal være to separate stilark tilpasset de ulike klienttypene (PC og PDA), hvor det i
presentasjonen skal legges vekt på skjermstørrelse og grafikk.
Vi har valgt å skille applikasjons- og domenelag fra hverandre, for å vise hvilken(-n) klasse(r) som tilhører de
ulike delprosjektene i leveranse 2 av gjennomføring. I applikasjonslaget har vi ulike moduler som reflekterer
forretningsprosessene systemet skal kunne håndtere. Disse modulene vi vil se nærmere på i det
18

objektorienterte klassediagrammet (OOD). Modulene har en direkte tilknytning til ulike domener, og i disse vil
det implementeres operasjoner for de tilknyttede modulene.
All data som genereres på applikasjons- og domenelag, lagres og hentes til/fra relasjonsdatabasen gjennom
DB2-forbindelser. Ved informasjonsutveksling mot eksterne systemer (lagersystem, personell, faktura og
regnskap), vil det benyttes XML-RPC forespørsler. Det er viktig å presisere at data som genereres ved en slik
informasjonsutveksling lagres i relasjonsdatabasen.
13. RUP 4+1
13.1. Process View
Vi skal fra dette perspektivet diskutere utveksling av data mellom ulike prosesser i systemet, og hvilke
kontrollmodeller som er fornuftig å benytte. Vi skal i denne diskusjonen forholde oss til kontrollmetodene
sentralisert og hendelsesbasert.
13.1.1. Samhandling i lagmodellen
Forespørsler fra klientene blir konsentrert inn til presentasjonslaget gjennom HTTP-forespørsler. Utfordringen
fra dette stadiet er å finne en fornuftig kontrollmodell for kommunikasjon mellom lagene nedover i modellen.
Datautvekslingsformatet er låst til XML iht. ikke-funksjonelle krav, så kontrollmodellen må være forenlig med
dette formatet. I kommunikasjonen mot relasjonsdatabasen er vi bundet til kontrollmodellen return-call som
DB2 Connections benytter seg av.
- Da klienten gjør HTTP-forespørsler, har vi sentralisert kontroll etter call-return modellen fra
klientsiden. Dette låser oss noe i valget av kontrollmodell da klienten alltid forventer et svar.
- Dersom vi velger å benytte oss av hendelsesbasert kontroll, må vi iverksette en handling umiddelbart
etter vi har fått en forespørsel mot presentasjonslaget. Da en forespørsel er sterkt knyttet til en
bestemt sesjon, er det utelukket å benytte broadcast-modellen. En slik modell vil ikke gi oss
muligheten til å spesifisere sesjonsdata videre nedover i lagene. En modell vi kan velge å benytte oss
av er interrupt-basert. Denne vil dog være noe begrenset i omfang da den ikke tilbyr noe svar – kun en
igangsettelse av en prosess.
- Et nærliggende valg er å benytte oss av samme kontrollmodell som HTTP – nemlig call-return.
Ulempen med call-return er at den kan introdusere ytelsesproblemer dersom forespørsler henger seg
opp nedover i lagene. Vi må derfor benytte en kommunikasjonsprotokoll hvor det er mulig å overvåke
forespørsler, og eliminere de som tar for lang tid.
Konklusjon
Vi har valgt å gå for call-return som kontrollmodell for kommunikasjonen mellom lagene. Som
kommunikasjonsprotokoll har vi valgt å benytte HTTP på applikasjonslag, da dette gjør at vi slipper å utvikle vår
egen server på dette laget.
Figur 9: Kommunikasjon mellom lagene
19

Kommunikasjon mot eksterne systemer
I kommunikasjonen mot eksterne systemer er vi låst til XML-RPC, som er basert på call-return modellen.
Uansett er det behov for å diskutere om data skal hentes ut hver gang ved forespørsel, om det skal
mellomlagres (caches), eller overføres i form av en dump med programmerte intervaller.
- De systemene vi skal kommunisere mot er ”Lagersystem”, ”Personellsystem” og ”Faktura og
regnskap”. Disse systemene opererer med sin egen database, og det er viktig at konsistens bevares
dersom det blir initiert oppdatering av data fra vårt system.
- Dersom vi går for dump med programmerte intervaller vil konsistens kun være opprettholdt rett etter
oppdatering. Det krever også at vi utvikler verktøy som differensierer endringer gjort i begge
systemer. Fordelen med en slik løsning er at systemet vårt ikke er avhengig av det eksterne systemet
er oppe, og at ytelse kun begrenses av vårt system.
- Dersom vi henter ut data hver gang ved forespørsel, vil data alltid være konsistent. Problemet er at
ytelse kan bli et problem dersom det eksterne systemet er belastet/nede, eller det blir initiert mange
forespørsler samtidig. Vi har mulighet til å mellomlagre data (cache), men dette introduserer
kompliserte kommunikasjonsklasser da det må holdes oversikt på hvilken data som er oppdatert.
Konklusjon
Fra ”Lagersystem” og ”Personellsystem” er det behov for sanntidsdata, så data må hentes ut hver gang ved
forespørsel. Forespørsler som genererer stor datatrafikk, skal mellomlagres (caches) så langt det lar seg gjøre.
Da det ikke er behov for sanntidsoversikt mot ”Faktura og regnskap” skal det kjøres en daglig ”dump” av
ordregrunnlaget.
13.2. Logical- og Implemenation View
Fra dette perspektivet har vi sett på hvilke klasser løsningen bør bestå av, og prøvd å sortere disse inn under de
ulike lagene. På grunnlag av dette har vi utarbeidet et objekt orientert klassediagram (OOD). Vi har bevisst
utelatt presentasjonslaget fra diagrammet, da dette kun består av en formateringsprosess som allerede er
implementert i programvareplattformen. Diagrammet er ikke detaljspesifikt på alle punkter, og det kan
argumenteres for at enkelte attributter/operasjoner er utelatt. Dette er gjort bevisst da vi ikke har mulighet til
å spesifisere hele løsningen da den er såpass omfattende. Vi har på tross av dette prøvd å vektlegge at hver
klasse skal ha så høy funksjonell styrke som mulig. Hovedtanken med diagrammet er at en programmerer skal
kunne gå inn, og få et oversiktbilde på hvordan de ulike klassene skal samhandle og navngis.
20

13.2.1. Kommentarer til objekt orientert klassediagram (OOD)
Klassene i applikasjonslaget er i praksis kontrollklasser, som påkaller operasjoner fra klassene i domenelaget.
Navn og operasjoner på applikasjonsklassene skal reflektere de ”use casene” som ble utarbeidet i
kravspesifikasjon. Pakkeinndelingen er gjort på grunnlag av delprosjektene i leveranse 2, iht. til
gjennomføringsplan. Videre har vi markert klassene som utgjør rammeverket (operasjoner som er felles for alle
klasser) i rødt. GUI-klassen benyttes av applikasjonsklassene for å utforme brukergrensesnittet.
21

13.2.2. Ekspandert sekvensdiagram
Vi har utarbeidet et eksempel på hvordan interaksjonen mellom de ulike klassene fungerer for applikasjonen
Produktrealisering. I en fullstendig arkitekturbeskrivelse ville vi gjort lignende beskrivelser for de mest
komplekse applikasjonene.
22

13.3. Deployment View
Som i likhet med den arkitekturiske oppbyggingen av programvaren, er også implementering av hardware gjort
lagdelt. Dette er gjort for å sikre driftsstabilitet og ytelse, og vi har kommentert de ulike komponentene i
løsningen nedenfor.
Figur 10: Deployment View for ThrustFlow Management
Klient
Med klient menes en enhet (arbeidsstasjon, laptop, PDA) som er tilkoblet nettverket og betjenes av én person.
Klienten skal benytte seg av en nettleser, og gjøre forespørsler mot systemet vha. HTTP. Det eneste klienten
skal foreta av prosessering er XHTML-tolkning vha. nettleseren. Programvare er Microsoft Internet Explorer.
Lastfordeling
Klientene skal foreta HTTP-forespørsler mot en felles nettadresse, som i praksis er adressen til en lastfordeler.
Denne skal fordele forespørsler til presentasjonsserverne, etter kriterier som status, belastning og kapasitet.
Lastfordeleren skal huske sesjoner, og sørge for at klienten så langt det gjør seg mulig kommuniserer med
samme presentasjonsserver, slik at det mulig å lagre data tilknyttet sesjonen (via Cookies). For å sikre
redundans, skal det være en primær- og sekundær (backup) lastfordeler. Programvare på tjener er WebSphere
Loadbalancer.
Presentasjon
Presentasjonsserverne skal utgjøre bindeleddet mellom applikasjon og klient, og tilpasse presentasjon etter
klienttype. Dette laget vil utføre forespørsler mot applikasjonslaget, og omforme returnert XML til XHTML vha.
XSLT-stilark. Det skal være to noder slik at redundans bevares. Programvare på tjener er IBM HTTP Server.
23

Applikasjon
Applikasjonsserverne utgjør kjernen i systemet, og skal generere applikasjonsdata på XML-format etter
forespørsel fra presentasjonsserverne. All data som genereres skal lagres og hentes fra databasen, og
forespørsler mot eksisterende vha. XML-RPC skal utføres mot eksisterende systemer. Det skal være to noder
slik at redundans bevares. Programvare er IBM Lotus og IBM HTTP Server.
Database
Databaserserverne skal drive en relasjonsdatabase, som applikasjonsserverne skal kunne benytte til å lagre og
hente generert data. Det skal være to noder slik at redundans bevares, og replisering skal gjøres i sanntid. Ved
skriveoperasjoner skal det benyttes låsing på tabellnivå for å bevare konsistens. Programvare er IBM DB2 Suite.
Management
Administrasjonsserverne skal sørge for oppdatering av systemet, og utføre sikkerhetskopi etter fastsatte
intervaller.
24

Evaluering av eget arbeid
Generelt om arbeidet
Straks vi ble informert om prosjektarbeidet, dannet vi gruppen og begynte med forarbeid. Vi hadde
innledningsvis en forventningsavklaring om ambisjonsnivå og hva vi ville ha ut av prosjektet. Vi var alle enige
om at vi ønsket å ha fokus på faget, fremfor å bruke mye tid på å finne opp et helt nytt produkt. Utfordringen
ble da å finne en relevant problemstilling som simulerer en reel situasjon. Med dette som utgangspunkt
diskuterte vi oss gjennom tidligere arbeidsplasser vi selv hadde erfaring fra. Her fant vi mange interessante
problemstillinger, og valget falt på å lage et arbeidsflytsystem for å effektivisere produksjonen ved Brunvoll AS.
Dette var en bedrift Eide hadde god kjennskap til, og som vi kunne få ut nøkkelopplysninger fra. Når vi ser
tilbake, er vi godt fornøyd med valget. Det har vært relativt lett å identifisere krav til systemet, da vi har hatt
kontakt med ansatte i bedriften.
Vi snakket sammen før hvert delprosjekt, fordelte oppgavene noenlunde likt, og satte deadlines for når første
utkast skulle være ferdig. Den meste av tiden på skolen gikk med til dette. Underveis gikk vi gjennom det vi var
usikre på i fellesskap. Måten vi har gjort det på, ser ut til å ha fungert. Vi har jobbet kontinuerlig og har ikke
hatt noe problem med tidsfristene. Noe vi kunne gjort bedre fra starten av, var å ha forhåndsdefinert
grupperollene. Disse rollene har ikke vært fastsatt underveis i prosjektet, og det ville nok vært fordel med en
prosjektleder.
Delinnleveringene
Innledningsvis tok vi et noe for teknisk perspektiv på forprosjektet. Vi tenkte for mye løsning, og glemte at
dette egentlig er en slags salgsoppgave som skal overbevise en potensiell kjøper. Etter den første
tilbakemeldingsseansen leste vi over forprosjektet vårt, og prøvde å ha fokus på at dette skal virke tiltalende
for en person uten teknisk bakgrunn. Dette resulterte i en total omskriving av oppgavebeskrivelsen, og
omforming av flere mindre punkter. Vi er nå godt fornøyd med resultatet, og mener det gir en utenforstående
en god presentasjon av hva oppgaven går ut på.
Når vi gikk løs på kravspesifikasjon, var vi sett i lys av forprosjektet noe forsiktig med å tenke løsning. Dette
resulterte i ”use case”-beskrivelser som var mer fokusert på hensikt, enn beskrivelse. Vi måtte derfor revidere
disse beskrivelsene i etterkant. I de detaljerte use case beskrivelsene, ble det noe lite brukervariasjoner. Dette
er en direkte følge av at brukerinteraksjonen er relativt enkel, sett i sammenheng med hva systemet skal gjøre.
Vi er fornøyd med det vi har gjort, men vi kan se at beskrivelsene har blitt noe generelle. Dette har med
bakgrunn i at prosjektet vårt er svært omfattende, og at det ikke er mulig å beskrive alt i detalj med de
rammene faget setter.
Når det gjelder arkitektur, brukte vi mye tid på å komme frem til en disposisjon av stoffet. Vi måtte jobbe mye
sammen, da alt hadde en svært tett knytning og alle måtte ha en dypere forståelse for å kunne bidra til
prosjektet. Etter hvert som vi kom inn i stoffet, utviklet arkitektur seg til et spennende område som vi har
jobbet mye med. Vi tok tidlig en avgjørelse på at vi ønsket å beskrive selve oppbyggingen av systemet, fremfor
å bruke tid på design av brukergrensesnitt. Vi er svært tilfreds med det vi har kommet frem til, og mener at
arkitektur er den sterkeste delen av prosjektet.
Hovedinntrykk
Vi føler vi har lagt mye arbeid i prosjektet i forhold til størrelsen på faget. Når vi nå ser på produktet, er vi
særdeles fornøyd. Vi ser at enkelte ting har blitt noe overfladisk grunnet prosjektstørrelsen, men føler på tross
av dette at vi har klart å understreke prinsippene i systemutvikling. Det har vært lett å spørre faglærer om råd
underveis, noe vi setter stor pris på. Faglærer har i tilbakemeldingene fremprovosert selvstendig tankegang
fremfor å servere oss fasiten. Dette har fungert bra for gruppas læring.
I