Forprosjekt. Alumni Comunication system. Bacheloroppgave Høgskolen i Gjøvik. Lasse K. Vanebo. Petter A. Busterud. Oddbjørn U.

Transkript

1 Forprosjekt Alumni Comunication system Bacheloroppgave Høgskolen i Gjøvik Lasse K. Vanebo Petter A. Busterud Oddbjørn U. Bakke

2 Innholdsfortegnelse 1. Mål og rammer Bakgrunn Prosjektmål Rammer: Omfang Oppgavebeskrivelse Avgrensning Prosjektorganisering Ansvarsforhold og roller Rutiner og regler i gruppen Veiledere og kontaktpersoner Planlegging, oppfølging og rapportering SU modell Plan for statusmøter Organisering av kvalitetssikring Dokumentasjon, kodestandard og kildekode Konfigurasjonsstyring Risikoanalyse: Plan for gjennomføring... 7 I

3 1. Mål og rammer Bakgrunn Alumni er latin og betyr tidligere student ved en skole. Mange skoler utenfor Norden har hatt lang tradisjon for å holde tett kontakt med sine alumni og danne alumniorganisasjoner, spesielt i USA og Storbritannia er dette veldig utbredt. Alumniorganisasjonene utgjør store ressurser for skolene og er kritisk for finansiering av skoler som ikke kan basere seg på statsstøtte. Skolene kan vise til hva deres alumni jobber med og trekker ofte frem alumni med spesielt stor suksess når de reklamerer for seg selv. Alumniorganisasjonene jobber gjerne for å hjelpe skolen med foredragsholdere, donasjoner, pengeinnsamlinger og rekruttering. Mange alumni fungerer og som mentorer for nyutdannete studenter i arbeidslivet, alumniorganisasjonen tilbyr dermed studenter ved skolen et stort kontaktnettverk når de kommer ut i arbeidslivet. Nordiske skoler har tradisjonelt vært statsfinansierte og har derfor ikke hatt økonomisk behov for alumniorganisasjoner. De Nordiske skolene ser nå behovet for alumniorganisasjoner på grunn av fordelene de gir med tanke på markedsføring, tilgang til foredragsholdere og nettverk i arbeidslivet som deres studenter kan dra nytte av. Med dagens teknologi er den naturlige og mest effektive måten å organisere alumni på med et social-nettworking-system. Slike alumnisystem er i bruk i dag hos mange skoler, men det er behov for å lage egne system for Norge der fokuset ikke er på finansiering, men på den sosiale verdien et alumninettverk gir i seg selv for elever og skole. 1.2 Prosjektmål Resultatmål: Gruppens mål i dette prosjektet er å utvikle en prototype/beta løsning til et alumnisystem for Høgskolen i Gjøvik. Målet er å få opp alle kritiske elementene til et alumnisystem, databasen, web frontenden for administratorer/alumnier med et innloggingssystem. Dette inkluderer registrering av nye brukere, oppdattering av profil og hente ut informasjon om andre brukere. Dokumentasjon er også en viktig del av prosjektet, for å sikre mulighetene for videreutvikling. Dette vil si at systemet skal kunne være kjørenes, men ikke ferdig nok til å settes i drift, med tanke på bugs, ekstra komponeter som ønskes å bli lagt inn i systemet, designet på web frontenden eller andre ikke kritiske elementer. Vi skal utvikle et system som gjør det mulig å bygge videre på, og senere lanseres som en ferdig løsning til Høgskolen i Gjøvik og eventuelle andre høgskoler/universitet som ønsker et slikt system. Effektmål: Prosjektet er å lage «grunnmuren» til et norskutviklet alumnisystem, som kan bygges videre på å lanseres som et ferdig produkt til Høgskolen i Gjøvik (HiG). Effekten som ønskes å oppnås i dette prosjektet, er at HiG skal få et system som vil hjelpe de ansatte å opprettholde kontakten med tidligere studenter. Noe som vil hjelpe til å effektivisere kontakten med arbeidsplasser samt gjøre det lettere å skaffe mentorer/foredragsholdere til skolen. Skape et slikt nettverk er viktig både for skolen og studentene, både under og etter studietiden. 1

4 Lærningsmål: Gruppen sitter allerede i dag med en rekke kunnskaper innenfor databaser og web-utvikling. Vi vil i store deler av prosjektet anvende denne kunnskapen. Men kunnskapen på de forskjellige områdene sitter litt spredd i gruppen, noe som gjør at vi må ta lærdom av hverandre og sette oss inn i samkjøringen av disse. Vi vil også bruke bøker/internett for å forbedre oss på disse områdene, spesielt med tanke på Facebook-applikasjonutvikling som ingen på gruppen har kunnskaper om per i dag. 1.3 Rammer: Rammer gruppe: Gruppen skal ha en god kommunikasjon over hvilke arbeidsoppgaver som skal gjøres, dette blir blant annet gjort ved ukentlige møter samt daglige samtaler gruppen imellom. Disse arbeidsoppgavene skal gjøres, dokumenteres og loggføres. Rammer skole: HIG har gitt enkelte tidsfrister, disse er ført opp i planen for gjennomføring. Oppgavene skal gjøres og dokumenteres både i hovedrapport og i form av loggføring av arbeidet. Prosjektet skal basere seg på teknologier uten lisenskostnader, for å holde eventuelle ekstrakostnader nede. Skolen stiller krav til at all programmeringskode er godt kommentert og strukturert for å gjøre videreutvikling mulig for en eventuell annen gruppe. Rammer arbeidsgiver: Arbeidsgiver krever ukentlige møter for å følge med på prosessen, samt for å kunne komme med innspill. Systemet skal kunne hente ut informasjon om tidligere studenter. Arbeidsgiver har et krav om at prosjektet må være nettleserbasert og plattformuavhengig på brukersiden. 2. Omfang 2.1 Oppgavebeskrivelse Gruppen skal i prosjektperioden utvikle en tidlig versjon av et social-nettworking-datasystem som skal gi HIG og andre læringsinstitusjoner en effektiv måte å holde kontakt med sine alumni. Datasystemet, heretter kalt ACS (Alumni Communication System), skal være en form for database som inneholder kontakt- og jobbrelatert informasjon, med to webfrontender en for alumnibrukerne og en for administratorer fra skolen. Databasen skal kunne generere rapporter til administrasjonen ved skolen. 2

5 For å gi initiativ til alumniene selv å holde informasjonen om seg selv oppdatert skal det lages en social-nerworking-frontend mot dem som brukere. Denne frontenden skal fungere på en lignende måte som Facebook og LinkedIn i at den lar brukerne dele sosial-, kontakt- og jobbrelatert informasjon med andre alumni de ønsker å gjøre dette med. Det er og ønskelig med en Facebook-plugin som overfører informasjon mellom Facebook og alumni. 2.2 Avgrensning Systemet gruppen skal utvikle skal være en tidlig versjon av et eventuelt ferdig system. Derfor stilles det ikke strenge krav til stabilitet og testing, samt mengde av funksjoner som web-frontend og Facebook-plugin skal inneholde. Facebook-pluginen er en tilleggsfunksjon og ikke en del av kjernesystemet, den vil derfor kunne bli kuttet ved tidsnød. Gruppen skal ikke ta seg av å legge inn nye alumnier i systemet utover importering av skolens database over tidligere elever. Administrasjon av systemet skal foretas av skolen. 3. Prosjektorganisering 3.1 Ansvarsforhold og roller Lasse K. Vanebo er prosjektets leder og har ansvar for den ukentlige tidsdisponeringen. Petter A. Busterud har ansvar for å holde orden på rapport og dokumentasjon. Han vil fungere som gruppens sekretær, og skal føre ukentlig logg for gruppen. Oddbjørn U. Bakke har ansvar for websiden til gruppen, konfigurasjonsstyring, samt gruppens programvare og utstyr. 3.2 Rutiner og regler i gruppen Arbeids rutiner - Ved første felles arbeidsøkt hver uke holdes det statusmøte for arbeidet som ble gjort forrige uke. - Ved oppstart av felles arbeidsøkt gjennomgås det kjapt en liste med arbeidsoppgaver de ulike gruppemedlemmene skal gjennomføre. - Ved alle møter fører sekretær for gruppa møterefferat. Arbeidsmengde - Hvert medlem i gruppa skal legge ned ca. 30 timer med arbeid hver uke. - Det legges opp til at 20 av disse timene gjøres sammen i skoletiden, gruppemedlemmene skal søke å delta på disse felles timene. 3

6 - Hvert gruppemedlem fører logg over hva de bruker timene til og dokumenterer arbeidet de har gjort hver enkelt uke. Det er et krav at det enkelte gruppemedlem skal dokumentere sitt arbeid og at de har jobbet det påkrevde antall timer hver uke. Arbeidsregler - Ved felles arbeidsøkter skal det konsentreres om arbeid. Bruk av tiden til personlige interesser ikke relatert til arbeidet er ikke tillatt. - Møteplikt på prosjektmøter, statusmøter, møter med arbeidsgiver og møter med veileder. - Det skrives referat etter alle prosjekt- og statusmøter, møter med arbeidsgiver, møter med veileder og når viktige beslutninger tas og problemer drøftes. - Det kan gis dispensasjon fra møteplikten ved god grunn og varsel i forkant. - Ulike arbeidsoppgaver fordeles og gis tidsfrister. Medlemmet med denne oppgaven må informere gruppen hvis arbeidet henger etter, da kan gruppen ta standpunkt til utsatt frist eller om det tas igjen senere. - Ved faglige uenigheter søkes det å oppnå løsning ved drøfting, hvis ikke dette går blir uenigheten avgjort ved stemmegivning. - Gruppen plikter tidlig å informere dersom de ikke er fornøyd med innsatsen til enkelt gruppemedlemmer. Rutine ved ( alvorlige nok ) brudd på reglene: a. Samtale(r) mellom alle gruppedeltagerne om problemet. b. Deretter en skriftlig advarsel fra de andre (evt. bare lederen) der: i. regelbruddet blir påpekt. ii. konkret (tidsfrister, forventet arbeid(sinnsats), m.m.) om hva som kreves for å bøte på skaden. iii. konkret om konsekvensene (samtale m/faglærer/veileder, ekskludering o.l.) av manglende kravoppfyllelse. c. Så: samtale mellom hele gruppen og faglærer/veileder o.l. d. Til slutt: skriftlig ekskludering fra gruppen via dekanen. Faglærer informeres. 3.3 Veiledere og kontaktpersoner Harald Liodden Prosjektveileder Simon McCallum Teknisk veileder Rachael Gibb Ekstern konsulent Hilde Bakke Kontaktperson ved HiG 4. Planlegging, oppfølging og rapportering 4.1 SU modell Som beskrevet tidligere vil prosjektet vårt bestå av tre hovedelementer; Database, Webfrontend og Facebook applikasjon. Hvor utviklingen av grunnsystemet vil foregå i denne 4

7 rekkefølgen på grunn av disse modullenes funksjonelle krav til hverandre. Vi har sett for oss at vi ønsker å jobbe med prosjektet i faser, hvor vi vil først definere mål som skal utføres gjennom en periode, disse utføres i samsvar med valgt utviklingsmodell før vi går over på nye mål. I møter med oppdragsgiver og veileder er det også kommet fram at det er ønsket at vi kan utgi prototyper av systemet med jevne mellomrom, slik at de kan komme med tilbakemelding om eventuelle tilleggfunksjoner, endring av enkelte løsninger eller andre generelle ønsker de kunne tenke seg i systemet. Dette gjør at vi må ha en fleksibel utviklingsmodell, slik at vi kan være mer åpne for endringer underveis. En slik løsing vil også være til hjelp for oss som prosjektgruppe, ved at vi her får konkrete mål som må utføres innenfor en tidsramme. Vi så for oss SCRUM som en passende kandidat som utviklingsmodell, men de strenge kravene til rollefordeling og hvor lange periodene hver sprint skulle være på gjorde at den ikke passet inn i vår prosjektgruppe på 3 med en tidsramme på 3-4 måneder. Vi så og litt på XP, men kom fort fram til at den ikke passet ved våres gruppestørrelse og ikke hjalp oss i noen særlig grad med å dele prosjektet inn i fornuftige faser. Fossefall og lignende modeller har vi og sett bort fra grunnet at de ikke tilrettelegger for å dele prosjektet inn i faser og at de ikke gir noen god måte å håndtere endringer på. Valget falt til slutt på spiralmodellen. Denne løsningen gir oss det vi ønsker i en systemutviklings modell. Hvor vi starter med å fastsette mål ved hver nye fase vi går inn i, og ender med at oppdragsgiveren kan gi sin vurdering av prosjektet ved hver fase slutt. Det vil også bli gjort korte risikoanalyser gjennom fasene noe som gjør at vi får redusert risikoer som eventuelt kan dukke opp i hver enkelt fase. 4.2 Plan for statusmøter Det er planlagt statusmøter med prosjektveileder annenhver tirsdag kl. 14:30 f.o.m med forbehold om endring, grunnet veileder har kun 80% stilling ved HiG. Møter utover dette vil bli satt ved behov. Møte med oppdragsgiver og teknisk veileder vil skje hver fredag klokken 08:00 f.o.m , samt møter vil bli satt opp med ekstern konsulent ved ønske og behov. Disse møtene med teknisk veileder vil fungere som beslutningspunkter. Vi vil som beskrevet i punktet om rutiner holde interne møter med oppsummering av forrige ukes arbeid ved første felles arbeidsøkt hver uke. 5

8 5. Organisering av kvalitetssikring 5.2 Dokumentasjon, kodestandard og kildekode Database: Utviklingen av databasen vil foregå ved å benytte MySQL. MySQL er en gratis løsning og går som den mest populære Open Source databasen, noe som gjør at vi ikke må betale dyrt for å utvikle og bruke en database. MySQL er også den databasen som blir benyttet mest i kombinasjon med PHP når det gjelder andre prosjekter, noe som også gjør dette til ett fornuftig valg. Web-frontend: For web-frontenden vil det bli brukt HTML, PHP og CSS. HTML vil brukes for å lage selve grunnmuren av web-frontenden, oppsettet på siden og lignende. CSS for å få ønsket utseende på siden, og PHP vil ta seg av skripting som innloggingssystem, kommunisering med database og lignende. Facebook-applikasjon: Kodestandarden for utvikling av en Facebook-applikasjon blir lagt opp etter APIen til Facebook. Dette er noe vi vil se mer inn i når vi kommer til selve utviklingen av en applikasjon. 5.2 Konfigurasjonsstyring En stor del av prosjektet vil være å jobbe med kode. For å sikre at vi holder hverandre oppdatert og sikring av koden, skal gruppen her benytte seg av Subversion (SVN). Høgskolen i Gjøvik har tilrettelagt bruken av dette for alle bacheloroppgaver, hvor vi får vårt eget SVNområde til bruk under prosjektet. Programmet TortoiseSVN vil bli installert på alle prosjektdeltagers PCer, og er det som blir brukt for å administrere SVN. Til backup av kode og dokumentasjon blir det brukt Dropbox; dette gir oss en kopi av all kode og dokumentasjon på hjemmesiden til Dropbox, med versjonshåndtering ved uheldig overskriving. Samt at dette gir oss en kopi av alt arbeidet på hver deltagers PC. 5.3 Risikoanalyse: Prosjektets kritiske elementer blir ikke ferdig før tiden: Sannsynlighet: lav Konsekvens: høy Håndtering: Ved å dele prosjektet inn i faser og ha klare mål for hver fase vil vi tidlig oppdage hvis vi ikke klarer å holde tidsplan. Vi kan da justere inn arbeidet og forsøke å rette opp dette. Det at de kritiske fasene gjøres først i prosjektet gjør og at vi kan kutte de ikke-kritiske ved tidsnød. 6

9 Tapt dokumentasjon: Sannsynlighet: lav Konsekvens: høy Håndtering: Vi vil bruke både subversion og dropbox for å lagre dokumentasjonen. Dette vil gi en god sikkerhet mot tap, da alt av dokumentasjon er lagret på flere plasser og med rollback-funksjonalitet. Systemet innfrir ikke skolens krav: Sannsynlighet: lav Konsekvens: middels Håndtering: Vi vil utføre ukentlige møter med representanter fra HiG. Dette vil gjøre at skolen kan komme med innspill under prosessen. Vi har og møter med konsulenter som har erfaring med slike systemer og slik at vi kan få på plass realistiske krav og forventninger til systemet. Problemer med overføring av eksisterende register over tidligere studenter: Sannsynlighet: middels Konsekvens: middels Håndtering: Konsekvensen av denne risikoen er dempet ved at skolen kan legge til dette manuelt eller ved andre metoder senere. En eller flere medlemmer i gruppen blir inndisponert: Sannsynlighet: middels Konsekvens: middels Håndtering: Nedskalering av ikke-kritiske funksjoner av prosjektet. 6. Plan for gjennomføring Se vedlegg. 7