ThrustFlow Management Brunvoll AS

More documents

Recommendations

Info

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
Page 1 and 2: ThrustFlow Management Aleksander Ba
Page 3 and 4: Forprosjekt 1. Mål og rammer 1.1.
Page 5 and 6: gjøres, hvor komponentene som skal
Page 7: - Gruppeleder ”leveranse 1” og
Page 11 and 12: 7. Gjennomføring 9
Page 13 and 14: - (registrere lagerplassering): N
Page 15 and 16: 9. Detaljert use case beskrivelse o
Page 17 and 18: 10. Kvalitetsmessige krav Brukerven
Page 19 and 20: skal gå til produksjon, og tjenest
Page 21 and 22: objektorienterte klassediagrammet (
Page 23 and 24: 13.2.1. Kommentarer til objekt orie
Page 25 and 26: 13.3. Deployment View Som i likhet
Page 27: Evaluering av eget arbeid Generelt

ThrustFlow Management Brunvoll AS

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?