Kandidatnummer: 2625, 2634, 2624, 2619, 2638 Emnekode: Emnenavn: Emneansvarlig: IS-304 Prosjektoppgave/Applikasjonsutvikling/Kvalitetssikring Hallgeir Nilsen Innleveringsfrist: 15. mai 2009 kl 12.00 Antall sider (inkl. forside): Merknader: Jeg/vi bekrefter at jeg/vi ikke siterer eller på annen måte bruker andres arbeider uten at dette er oppgitt, og at alle referanser er oppgitt i litteraturlisten. Ja Nei Vi bekrefter at alle i gruppa har bidratt til besvarelsen (gjelder kun ved gruppeeksamen) Ja Nei Kan besvarelsen brukes til undervisningsformål? Ja Nei
2009 [År] Post Project Review [Skriv[ Elkem inn Research undertittel ProssessIT for dokument] ] [Skriv Av : Elkem inn dokumentsammendrag Bacon her. Sammendraget kan være en kort oppsummering Hognestad, Arvid av Ranestad, innholdet Nawar i dokumentet. George Wisam, Skriv inn dokumentsammendrag her. Sammendraget Ronny Eldor Karlsen kan være og Maria en kort Kuznetsova-Tønnessen. oppsummering av innholdet i dokumentet.] En Batchelor-Prosjekt utført på UIA, Universitetet i Agder Terje Applikasjon : Ressurs Planlegging NITH 15. [Velg mai dato] 2009
Project Managment... 6 Quality Assurance... 7 Process Improvement... 9
Project Managment Vi har brukt Scrum prosjektstyrings metodikk til vårt prosjekt. Vi mente denne metodikken passet bra til vårt prosjekt. Elkem bruker allerede Scrum og vi har hatt en gjesteforelesing i Scrum og derfor følte vi det var naturlig for oss å velge Scrum. Prosjektet er også ganske stort og mye var ukjent, derfor følte vi det vare bedre å dele prosjektet i mindre iterasjoner slik at vi får bedre kontroll over fremgang og lettere og gjøre endringer underveis. Vi har alltid hatt en Scrummaster i gruppen, men rollen har gått på rundgang slik at alle kunne prøve seg som gruppeleder. Morgenmøtene har vært veldig effektive hvor vi har hatt status på hver enkeltperson hvor de forteller hva de har gjort siden forrige morgenmøte, hva de skal gjøre i dag og eventuelle problemer. Det har fungert veldig bra og vi føler vi har hatt god kontroll. Vi har alltid prøvd å hjelpe hverandre hvis noen har problemer slik at vi kan bli så produktive så mulig. På møtet har vi også fordelt oppgaver hvis noen skulle være ferdige med sin brukerhistorie. Backloggen ble oppdatert etter hvert morgenmøte slik at vi fikk bedre oversikt over fremgang og status. Forberedelse til Scrum har vært veldig ressurskrevende. Vi fikk en gjesteforelesing av Pragma om Scrum, men vi følte ikke vi hadde tilstrekelig med opplæring for å begynne selv med denne metodikken. Derfor brukte vi mye tid på opplæring av Scrum og backlog gjennom video opplæringer på nettet slik at vi skulle få en bedre start på denne metodikken, og det mener vi at vi har fått. Vi var veldig heldig at vi fikk en IT-leder som kontaktperson hos Elkem og dette har gjort at vi fikk en bra kravspesifikasjon. Med kunden har vi satt opp en backlog med brukerhistorier med tidsestimering og prioritet liste. Estimeringen av de forskjellige brukerhistoriene gikk bra med kunden, men som forventet ble noen av estimeringene feil. Dette mye pga vi var helt uerfarne med både Scrum og ASP.NET. Vi brukte og mye lengre tid på opplæringen enn forventet. Når vi valgte dette prosjektet viste vi det var en del risikoer i bildet. Derfor har vi tatt en risikotest i hovedrapporten.
Quality Assurance Kvalitetsatributter, sammenlikning Attributt Vårt arbeid Forbedringsmuligheter Korrekthet, pålitelighet og robusthet Elkems kodestandard har blitt brukt. Kontinuerlig testing under utvikling. Integreringstesting har blitt foretatt på manuell metode. Tatt når den har blitt lagt inn i masterpage. Automatiske tester ble ikke utført pga tidsmangel og kunde ville ikke at vi skulle bruke tid på det. Automatiserte tester kunne ha blitt utført. NUnit skal være et av de beste og mest brukte programmene til unittesting. Dette hadde blitt brukt med bedre tidshorisont. Andre til å teste applikasjonen. Stresstesting. Akseptansetest blir foretatt den 25.mai Brukervennelighet Max fokus på enkelthet, krav fra kunde. Registrering på prosjekt viktigst hvis systemet skal tas i bruk. Helt i fra starten av fikk vi greie på at noe av det viktigste for at de skulle kunne bruke prosjektet vårt var brukervenneligheten. At vi hadde stor fokus på at det var så enkelt som mulig. Tidsmessig så er det forbedringsmuligheter her. Gui'et fikk vi motsatt beskjed på. Der skulle vi ikke ha så stor fokus, for det kunne de ta seg av. Derfor er det mulighet til forbedringsmulighet her fra vår side. Usabillity-testing, dersom vi hadde hatt tid. Tabellen forsetter på neste side.
Kvalitetsatributter, sammenlikning Attributt Vårt arbeid Forbedringsmuligheter Vedlikeholdbarhet Elkems kodestruktur. Selvforklarende kode er brukt etter kurset med kommentarer hvor det er nødvendig Uavhengighet mellom modulene. Kunde-involvering Tidlig og iterativ involvering. Tilbakemeldinger, sortering og prioritering gjennom hele system utviklingsprosessen. Dette har fungert bra, men nå skal det sies at Frank hos Elkem har bra kunnskaper innen dette feltet, og har hjulpet til. I en reell arbeidssituasjon så er det viktig at vi har med kunden tidlig og ofte nok. De første styringsgruppemøtene kunne ha blitt planlagt bedre. Levert etter avtale (kravspec/backlog) (har de fått det de ønsket?) Høyt prioritert av oss. Utført i samarbeid med Frank/Elkem Leveringstid Applikasjonen skal være leveringsklar til akseptansetest 25. Mai. Vi har fulgt Elkems tilbakemeldinger hele tiden og ser derfor ikke noen forbedringsmuligheter. Lenger leveringstid hadde helt klart økt kvaliteten, og spesielt pga. opplæringen. Pris / Budsjett Gratis prosjektarb. Med økt erfaring, utføres nok mye kjappere og dermed rimeligere eller gir rom for økt kvalitet. Tabell 1 - Kvalitets tabell (Hansen & Hjertrø 2003)
Process Improvement Hvis vi skulle utført et tilsvarende prosjekt ville vi gjort det meste på samme måte siden vi er fornøyd med vår utviklingsprosess. Men vi kan alltid forbedre oss og vi har funnet noen svakheter som vi ville gjort prosessene enda bedre: Område Forbedring Opplæring ASP.NET med C# Det gikk veldig mye tid på opplæring og det burde vært en egen brukerhistorie i backloggen, for å måle hvor mye ressurser som har blitt brukt på opplæringen. Styringsmøtene Burde hatt møteleder på de første møtene. Burde sendt agenda første møtet Burde hatt tydeligere møteleder på de første møtene. Fordeling av arbeidsoppgaver Begynt på rapporten tidigere, kunne hatt noen dager ekstra siden fellesarbeidet tok lengre tid enn forventet. Masterstudent Kunne ha blitt brukt bedre Litt for lite utbytte, har prøvd og vær selvgående Veileder Flere møter med vår veileder, avdekking av flere feil på rapporten, bedre strukturering mm. Tabellen forsetter på neste side.
Område Forbedring Bachelor Rapporten Burde kanskje vær eget punkt i backloggen slik at tidsestimeringen kunne vært bedre. Vi mangler noen referanser på bilder og i teksten. Bedre tydeliggjøring av hvorfor vi tok med mye teori på noen tema, og lite på noen andre. F. eks Testing:hvorfor vi ikke har uført så mye testing på vår applikasjon. Vi har ikke hatt tid til å prioritere testing og kunde mente at det var viktigere å få en funksjonell prototype enn at det ikke var noen feil. Derfor har vi tatt med mye teori siden dette er et viktig tema i prosjektet. Enklere layout: Vi prøvde og få til en bra layout, men viste seg og kollapse fullstendig når vi redigerte dokumentet på slutten. Ved redigering, innlegging, flytting eller fjerning av sider midt i dokumentet er faren for formatteringsfeil større på komplekse stiloppsett. Mulig en formattering ble slettet ved uhell, dagen før innlevering. Sidenummereringen og layout burde kanskje blitt tatt på slutten. Enklere jo bedre. Glemte å lime inn kodestandarden fra Elkem i rapporten. Vi kunne hatt noen skjermbilder fra applikasjonen, men ville heller vise når produktet er mer ferdig. Tilbakemelding på styringsgruppemøtene. (ble utført i fjor, men ikke i år.) Usikkerheten gjorde at vi ikke fikk lagt inn dette.) Bedre korrektursjekk på rapporten. Forsiden kom 2 ganger, og blank mellomside før innholdsfortegnelse. (formatterings-/printerfeil?) Scrum Vi kunne brukt Scrum tavle med post-it lapper for bedre oversikt Vi kunne oppdatert backloggen oftere hvor vi registrerte forbruk på de forskjellige brukerhistoriene
Elkem No tat Til : UiA Kopi : Trygve Hanssen og elektronisk arkiv Elkem Fra : Frank Martin Olsen Midlertidig versjon. Dato : 15.05.2009 Endeling versjon kommer senest 27. mai 2009 Prosjektevaluering av web-løsning for ressursoppfølging Elkem Research ved ProsessIT har våren 2009 gjennomført et prosjekt sammen med studenter fra Bachelorutdanningen til Universitet i Agder (UiA). ProsessIT har vært kunde og studentene leverandør. Dette er første gang ProsessIT gjennomfører slikt prosjekt sammen med UiA. Målet med prosjektet var å erstatte eksisterende Excel-ark for ressursoppfølging med en web-løsning. Den nye løsningen skulle inneholde høyere detaljeringsgrad og rapporteringsfunksjoner som ikke er tilgjengelig i dagens løsning. Prosjektet startet opp med følgende forutsetninger fra ProsessIT: C# skulle benyttes som utviklingsspråk Oracle skulle benyttes som database Utviklingsmetode som ble valgt var Scrum. Dette har ProsessIT noe erfaring med fra egne prosjekt mens studentene har fått opplæring på dette gjennom diverse fag, men de har ikke noe praktisk erfaring. I de første møtene ble det etablert en prioritert produktreserve (product backlog). Denne reserven inneholdt både oppgaver for etablering av utviklingsmiljø og rene utviklingsoppgaver. Prosjektet er gjennomført ved at studentene har tatt initiativ til de møtene som de har funnet nødvendig. Møtene har blitt gjennomført hos Elkem på Fiskaa. Studentene har mellom møtene jobbet med oppgaver knyttet til prosjektet og presentert resultatet av arbeidet på neste møte. Det har vært stor framgang å spore gjennom de møtene som har blitt gjennomført. De første møtene hadde ikke noe klar agenda og det var bare deler av prosjektgruppa som deltok aktivt. I de siste møtene har det blitt sendt ut agenda i forkant av møtene og studentene har fordelt oppgavene slik at alle har deltatt aktivt på møtene. Studentene er pr. dagsdato (15. mai) ikke helt ferdig med prosjektgjennomføringen. Det gjenstår fortsatt noen oppgaver som skal presenteres på test 25. mai. ProsessIT vil derfor komme med en oppdatert versjon av evalueringen etter nevnte test. Den oppdaterte evalueringen vil inneholde vurdering av selve produktutviklingen. Studentene har gjennom dette prosjektet måtte sette seg inn i både Scrum som utviklingsmetode og C# som utviklingsspråk. En stor del av prosjektet har gått med på denne kompetansehevingen. I ettertid vurderer ProsessIT det slik at C# ikke burde ha vært gitt som forutsetning som utviklingsspråk. Studentene burde ha stått fritt til å benytte det språket de kjenner best. De ville da ha kunne ha fokusert mer på Scrum og selve prosjektgjennomføringen. Ulempen kunne da ha blitt at ProsessIT hadde fått et produkt utviklet i et utviklingsspråk som er utenfor ProsessITs prioriterte utviklingsspråk. Mvh Frank Martin Olsen Elkem Research ProsessIT