Röna fingrar e gött o ha:) SLUTRAPPORT BUDGETSYSTEM LNU

Transkript

1 Röna fingrar e gött o ha:) SLUTRAPPORT BUDGETSYSTEM LNU FÖRFATTARE Viktor Karlsson Jarmo Baltzar DATUM

2 Sammanfattning I rapporten återfinns en detaljerad beskrivning om webbapplikation Budgetsystem som utvecklades i syfte att underlätta och förbättra budgethanteringen bland lärare och administratörer på Linnéuniversitetet. Rapporten följer projektets utveckling från början till slut med diskussioner angående projektets idéer, mål, genomförande och problem. Vi finner även en punkt för punkt baserad utvärdering och tankar kring projektets resultat och kundens återkoppling.

3 Förord Budgetsystemets uppkomst härstammar från en önskan av Linneuniversitetet att få tillgång till ett användarvänligt, grafiskt system där dem kan hantera sina budgetar. Utvecklingen skedde i PHP med speciell önskan om att MSSQL skulle ligga som grund för databasen. En möjlighet att enkelt och virtuellt bokföra resurser och fördela pengar och rättigheter i en tilltalade applikation var huvud målet för projektet. Applikationen kom att utvecklas, presenteras av fem distans studenter vid LNU och levereras till Johan Leitet i slutet av Mars 2011.

4 Innehållsförteckning S 4.0 Innehållsförteckning S 5.0 Inledning S 5.1 Bakgrund S 6.0 Mål S 6.1 Val av teknik S 6.2 Genomförande S 8.0 Resultatet S 8.1 Avvikelser S 8.2 Utvärdering

5 Inledning Projektet utvecklades inom ramarna för kursen Webbprojekt 1 (2011) vid Linnéuniversitet under drygt två månaders tid och som en del av webbprogrammerings-programmets andra år. Handledare och kursansvarig under projektperioden var Tobias Olsson. Kursen: Kursen inleddes med en introduktionsföreläsning där vi delades in olika grupper för att sedan tilldelas varsin kundkontakt. Grupp 4 bestående av Viktor, Martin, Jarmo, Rikard och Marta tilldelades ett uppdrag åt Staffan Karius vid LNU genom kundkontakterna Sven-Åke Johansson och Johan Leitet. Bakgrund Linnéuniversitetet använder sedan en längre tid tillbaka Excel-ark för att genomföra och hantera diverse budgetar, så önskan om ett förbättrat och mer användarvänligt system uppstod snart. I tidigare skede var användarområdet begränsat då systemet var väldigt kryptiskt och endast användes fullt ut av ett fåtal personer. Man ville alltså få tillgång till ett system som kunde nyttjas och användas av flera personer på ett lättsamt och smidigt sätt, samtidigt som man begränsade rättigheter och tillgångar utefter önskemål. Grupp 4 tilldelades uppdraget att påbörja utvecklingen av en användarvänlig och smidig webbapplikation med möjlighet att hantera och redigera diverse budgetar. Applikationen kom att gå under namnet Budgetsystem och utvecklades åt Linnéuniversitet. Inledningsvis träffade gruppen Sven-Åke Johansson för att få en överblick av deras vision och önskemål angående applikationen. Utifrån återkommande möten etablerades snabbt ett antal baskrav som kom att bli stommen för hela applikationen. Baskrav 1. Systemet skall presentera informationen på ett användarvänligt sätt, och låta användaren ta del av och uppdatera informationen på ett enkelt och smidigt sätt. 2. Administratören ska kunna hantera och fördela budgetar mellan institutioner, lärare och kurser. 3. Applikationen ska skrivas på ett sådant sätt att andra webbutvecklare ska ha lätt att

6 Syfte sätta sig in i hur den fungerar för uppdatering och underhåll. 4. En hierarki med olika nivåer för användarna skall etableras via ett rättighetssystem. Underlätta budgetsystemet för lärare och administratörer genom att organisera upp systemet med ett användarvänligt och stilrent gränssnitt mot en väl strukturerad databas. Mål Leverera en fungerande produkt för budgetadministrering som kan utnyttjas på ett effektivare sätt än det nuvarande Excel-systemet som är ganska kryptiskt och otillgängligt. Möjlighet för kunden att bygga vidare på produkten i framtiden. Val av teknik och teori Kunden önskade att hemsidan skulle följa Linnéuniversitetets designmanual vad det gäller grafiken och att applikationen skulle byggas mot en Mssql-server för att underlätta för skolan vid underhåll. Vi var fria att välja utvecklingsmiljö själva och efter granskning av gruppens kompetens inom olika områden valde vi att utveckla applikationen i Php och Javascript. Med hjälp av projektmodellen Unified Processes delades de tio projektveckorna upp i en mängd iterationer, där varje iteration grupperades in i fyra olika faser. Inception - Här knyts kundkontakten samtidigt som man påbörjar en gemensam vision för projektet. Elaboration - Projektet planeras in detalj samtidigt som mjukvaruarkitektur fastställs och risker undanröjs. Construction - Constructionfasen innebär främst kodande där all planerning verkställs. Transition - Projektet finslipas, slutförs och levereras till kund enligt överenskommelse. Genomförande Nedan följer en redogörelse hur vi har jobbat genom de olika faserna. Inception (vecka 3-5) Första tiden gick åt att dels lära känna gruppen, sitta och prata i skype men även att ta kontakt och boka in ett möte med kontaktpersonen. En del av den inledande tiden gick åt att lära sig versionshanteringen, samt få arbetsflödet och tekniken att fungera på ett lämpligt sätt.

7 Efter mötet med kund så började planeringen ta fart ordentligt. Vi skapade en snabb mockup för att visualisera hur själva projektet skulle se ut. Sedan hade vi diskussioner om vilken programmeringsteknik vi skulle använda, gruppen kom överens om att använda PHP efter en tids utvärdering av gruppens kompetens. Vi pratade även om konventioner, så att koden skulle se likadan ut genom hela projektet, så vi bestämde oss för en standard. Alla dokument som kom att behövas skapades inledningsvis och vi använde oss av SVN samt Google Docs för att jobba i realtid tillsammans och reda ut eventuella oklarheter. I detta stadiet så skapade vi en fysisk modell av databasen, dessutom försökte vi stryka ut eventuella fel vi kunde hitta i databasens upplägg. Vi utgick från en tidig AKS som vi hade fått av vår kundkontakt. Vi hade dock inte helt klart för oss hur vi skulle utforma applikationen de första veckorna på grund av bortfall och strul med kontaktpersonen. Detta ledde till att vi inledningsvis famlade en del i mörkret då vi inte kunde få några som helst svar på våra frågor och tankar kring projektet. Elaboration (vecka 6-7) När vi väl kom till elaborationsfasen efter alla om och men under första fasen så började vi att programmera på projektarbetet. Inledningsvis uppstod ett problem när vi skulle kommunicera mellan PHP-kod och en MSSQL-server då detta inte är integrerat på samma sätt som MySQL. Gruppen genomförde en undersökning för att hitta bästa möjliga teknik att använda och landade tillslut på PDO som är en uppsättning kommandon för att kommunicera mellan PHP-kod och en MSSQL-databas. Det visade sig att det behövdes lite drivrutiner för att få allt att fungera på servern, samma sak gällde på skolans applikationsrot. Sedan var det bara en fråga om att lära sig syntaxen, vilket var lite ovant för oss alla i början, men efter några dagar så var det inga större problem. Gruppen bestämde sig i alla fall att börja programmeringen och utformning av applikationen då vi insåg att vi inte kunde stå och trampa på ruta 1 eftersom detta skulle kosta oss mycket värdefull tid oavsett om vi gjorde rätt eller fel, så vi satte igång. Nu när vi äntligen hade kommit igång med själva programmeringen så bestämde vi oss att vi skulle ta en bit i taget, databasen som vi skulle jobba mot var relativt stor och komplex så vi bestämde oss för att skapa databasen del för del allteftersom vi kodade delar till projektet. Här uppstod även många frågetecken kring databasen som kostade oss en hel del tid då vi fortfarande hade problem med att få kontakt med vår kontaktperson. Efter många om och men fick vi en ny kontaktperson. Vi började inse att detta projektet var stort och att vi förmodligen får börja prioritera vilka funktioner vi skulle få med samt vilka vi fick helt enkelt prioritera bort. Vi försökte att hålla dokumentationen uppdaterad, vilket vi lyckades relativt bra med. Samtidigt så började programmeringen att ta mer och mer tid från dokumentationen.

8 Construction (vecka 8-10) I denna fasen hade vi verkligen farten uppe. Vi implementerade funktion efter funktion i projektet, dock fick dokumentationen lida lite för att vi fokuserade hårt på programmeringen. Samtidigt som vi lade till nya funktioner i projektet så slipade vi på funktioner som redan var implementerade för att få så bra funktionalitet i applikationen som möjligt. Gruppen kände att nu började projektet att flyta på som det borde ha gjort från början och motivationen steg betydligt. Transition (vecka 11-12) I detta skedet har vi slutat lägga till funktioner i projektet, och endast slipat funktionaliteten, samt dubbel och trippelkollat att allt fungerar som det skall. Slutgiltiga leveransen till kunden gjordes måndagen den 28/3. Resultat Vi hade en hel del motgångar som höll i sig rätt långt in i projektet, sedan att projektet i sig är ett stort och komplext projektarbete så känner vi oss nöjda med resultatet vi har presterat. Självklart hade det varit mycket roligare att kunna färdigställa hela projektet och kunnat leverera en komplett applikation, men det fanns helt enkelt inte tid för det. Som grupp har vi fungerat bra, bättre än många av oss ens trodde från början. Det har varit många o långa givande diskussioner hur vi ska lösa ett problem, och vi har haft en bra och nära samarbete från dag ett. Kursen har varit givande, vi har lärt oss mycket att jobba i en större grupp, allt ifrån att komma fram till en lösning på ett problem genom diskussioner när det har funnits flera olika förslag till lösningar, till att fördela jobb mellan gruppmedlemmarna, samt prioritera vad som behöver göras just nu. Avvikelser På grund av tidsbrist och diverse problem med kunden de första veckorna fick vi tyvärr prioritera en del fram emot slutet. Möjligheten att visa en mängd olika vyer för en eventuell sökning i databasen var något vi inte hann med innan slutleveransen och även en del menyfunktionalitet utelämnades för extra tid att knyta ihop säcken och rätta till eventuella buggar. Utvärdering Positivt och negativt

9 Under projektets gång har vi stött på en del negativa bitar så som förlorad kundkontakt och lite misstag med konventioner och program. Konventionerna insåg vi snabbt skapade en ostrukturerad kod, därav etablerade vi en hel del standarder som vi kom att följa. Inledningsvis fick vi även lite problem med versionshanteringen men detta löste vi också snabbt. Vi är nöjda med att kommunikationen har funkat bra och att alla har deltagit och gjort sitt bästa samtidigt som vi förvärvat en hel del kunskaper inom PHP, MSSQL, PDO och hur man hanterar ett projekt i sin helhet med tillhörande dokumentation. Tidsplanen Tidsplanen höll men på grund av våra inledande kund problem och ett mycket omfattade system att sätta sig in i fick vi spendera en hel del timmar åt att bara gå igenom strukturen för budgetsystemet, detta då utan någon direkt feedback. Nyckeln till att vi tog oss igenom svårigheterna i projektet var möten och en god vilja från gruppen varje dag. Även användarhandledningen har fungerat bra under projektets gång. Samarbete, informationsflödet Informationsflödet mellan kund och projektgrupp har fungerat utmärkt under den tid då vi haft aktiva möten. Det har varit givande samtidigt som gruppen har varit frågvis när det kommer till systemets vision och mål. Internt mellan gruppmedlemmarna har samarbetet fungerat mycket bra, kommunikationen har varit god och gruppen har haft dagliga möten sedan projektstarten. Möten, riktlinjer Möten generellt med både handledare, kund och grupp har fungerat utmärkt och det är något som vi känner har fungerat bra och kontinuerligt igenom hela projektet samtidigt som riktlinjerna för projektet har varit givande och till stor hjälp för att organisera och utveckla applikationen i sin helhet. Kundkrav Kundens vision för projektet i sin helhet var ganska omfattande och vår uppgift var att först och främst leverera en grundstomme med basfunktionalitet för budgetadministrering samtidigt som designen skulle likna LNU och använda sig av MSSQL. Utifrån kundens synpunkter på vår slutleverans och dem krav som ställdes på oss anser vi oss ha levt upp till kraven för projektet trotts en hel del motgångar i form av teknik, kontakt. Förslag på lösningar Då gruppen spenderade en hel del tid bara för att sätta sig in i systemet så resulterade detta även naturligt i en kreativ kundkontakt med realistiska förslag på förbättringar och ändringar i applikationen, något som vi inte anser att vi kunde gjort särskilt annorlunda. System för varningar

10 En risklista etablerades tidigt för att förhindra och förbereda oss på eventuella problem som kunde förekomma. Listan kom att uppdateras allt eftersom projektet fortlöpte och den har varit hjälpsam för att begränsa konsekvenserna av eventuella problem.