1DV411 Webbprojekt I Slutrapport

Transkript

1 1DV411 Webbprojekt I Slutrapport Jens Evertsson Michelle Leite Santana Henrik Norberg Pontus Pettersson Danijel Pilipovic Kurskod: 1DV411

2 Sammanfattning I samband med Webbprojekt 1 inom Webbprogrammerareprogrammets andra år och tredje läsperiod, skapades en webbapplikation gentemot en riktig kund. Kund bestånde av Intensivvårdsavdelningen vid Landstinget i Kalmar var i behov av ett system för hantering av information (nyheter/händelser) av icke akut natur. Denna rapport innehåller information om arbetet med framtagningen av denna produkt. Krav som främst efterfrågades från kund var inläggning av nyheter, uppdatering av nyheter, borttagning av nyheter, inläggning av kalenderhändelser, uppdatering av kalenderhändelser, borttagning av kalenderhändelser och att systemet skulle vara användarvänligt och anpassat för användning på en pekskärm. Samtliga insamlade krav har tagits hand om och implementerats helt efter kundens önskemål. Arbetet resulterade i en produkt vars utseende och liknande ni kan läsa mer om i denna rapport. 1

3 Förord Rapporten av detta arbete beskriver under olika rubriker hur arbetet med projektet Inflow genomfördes inom ramarna för kursen 1DV411 Webbprojekt 1 vid Linnéuniversitet. Systemet som utvecklats består av ett nyhetshanteringssystem och kalenderhanteringssystem skapat för Intensivvårdsavdelningen vid Landstinget i Kalmar. Tanken är även att andra nationella landsting ska kunna använda sig av detta system om det krävs. Vi anser att projektet varit både roligt, intressant och lärorikt. Vi vill slutligen även passa på att tacka vår kund Intensivvårdsavdelningen i Kalmar för ett spännande och utmanande projekt. Tack även till vår handledare Tobias Ohlsson för den handledning du givit oss. 2

4 Innehållsförteckning Sammanfattning... 1 Förord... 2 Innehållsförteckning... 3 Inledning, Bakgrund, syfte och mål... 4 Projektorganisation... 5 Genomförande... 6 Resultat... 8 Avvikelser...17 Slutsats...18 Förslag på vidare utveckling...19 Eventuell övertagande organisation...19 Förslag till förbättringar inför kommande projekt

5 Inledning, Bakgrund, syfte och mål Inledning och Bakgrund I samband med kursen Webbprojekt I som ges vid Webbprogrammerareprogrammet på Linnéuniversitets andra år och fjärde läsperiod, fick gruppen i uppdrag att utveckla ett nytt system. Kund bestånde av Landstinget i Kalmar, efterfrågade ett system vars uppgift främst bestod av ett verktyg för hantering av icke akuta nyheter och liknande. Tanken med systemet är att det ska kunna användas som ett verktyg för olika avdelningar inom olika Landsting, men framförallt av Intensivvårdsavdelningen vid Landstinget i Kalmar. Syfte Huvudsakliga syftet med projektet är att ta fram en fungerande produkt som kund kan använda. Annat syfte består av att gruppen i sin helhet ska lära sig att samarbeta som grupp och därtill ta fram kod, dokumentation och liknande för att projektet ska kunna färdigställas. Eftersom en iterativ arbetsprocess kommer användas är det också ett bra tillfälle att lära sig arbeta efter detta gentemot ett riktigt projekt. Mål De slutgiltiga målen är att få fram en fungerande produkt med funktionalitet innehållandes nyhets- och kalenderhantering av icke akut natur. Andra mål är att få fram den dokumentation som krävs för att samtliga intressenter ska förstå projektets alla delar i form av struktur, tidsåtgång och liknande. 4

6 Projektorganisation Projektorganisationen är ett dokument vars syfte beskriver hur strukturen i projektet mellan de olika intressenterna i form av kund, handledare, uppdragstagare och liknande har sett ut. InFlows projektorganisation har sett ut såhär: Linnéuniversitet, Institutionen för datavetenskap, fysik och matematik Handledare: Tobias Ohlsson Projektgruppen: uppdragstagarna Kontaktpersoner: Ingrid Wåhlin, Karin Rommedahl Intensivvårdsavdelni ngen vid Landstinget i Kalmar 5

7 Genomförande Metodik Efter kontakt tagits med kunden ifråga, påbörjades under vecka , arbetet med att planera och ta fram en fungerade slutprodukt. Under samtliga projektets veckor har vi arbetat iterativt, vilket innebär att man gör lite varje vecka och därefter visar upp veckans arbete för sin kund och därefter får ta del av dennes nya synpunkter. Från början var det tänkt att vi skulle använda en av projektgruppens ena medlems färdiga system att bygga vidare på, eftersom det ansågs kunna spara en hel del tid. Vidareutvecklingen av detta system skedde under några veckor, men pågrund av brist på förståelse utvecklades senare ett nytt helt från grunden. Under varje vecka därefter framskred utvecklingen till det som skulle komma att bli slutprodukten. Vilket även gjorde att vi träffade kunden mer frekvent, uppvisade det vi hade gjort sedan sist och därefter fick nya krav att ta ställning till. I början av varje iteration genomfördes även ett möte med handledaren där vi diskuterade det som hade hänt under föregående vecka. Handledaren var även en källa till hjälp gällande skrivandet av dokumentationen och annat som vi behövde rådfråga denne om. De krav som kund inledningsvis efterfrågade bestod främst av möjlighet till att lägga in nya nyheter, uppdatera gamla nyheter, ta bort gamla nyheter, lägga till nya kalenderhändelser (event), uppdatera gamla kalenderhändelser, ta bort gamla kalenderhändelser och att få fram ett system som både var väldigt användarvänligt att använda och anpassat till att använda på en pekskärm. 6

8 Teknik Eftersom kunden inte hade några önskemål på teknik att använda, fick vi därför rätt fria händer till att välja en teknik som passade oss. Valet föll på serverprogrammeringsspråket PHP för utvecklingen av systemet ( Och för lagring av data, på databashanteraren MySQL ( Mycket eftersom vi sedan tidigare kände oss rätt bekväma med dessa tekniker. Det tekniska underlaget består förutom ovanstående av vanlig HTML (HyperText Markup Language) och CSS (Cascading Style Sheet) för utseendebitarna av applikationen. Även delar av språket Javascript, eller dess enklare variant JQuery, har använts till vissa delar som exempelvis kalendern. Allt för att göra användarupplevelsen av applikationens vissa delar mer bestånde utan att behöva hoppa mellan olika sidor. Och därför undvika ytterliggare likvärdig inladdning av samma bilder och text igen. Vilket i slutändan sparar resurser iform av tid och liknande. För att kunna dela filer mellan varandra och enklare sammarbeta tillsammans, så har vi använt oss av versionshanteringssystemet subversion. Genom användning av ett versionshanteringssystem har förändringar av applikationen och dess dokument lätt kunnat ångras utifall detta har uppstått. Versionhanteringssystemet har även varit en viktig del i att varje projektmedlem haft tillgång till den senaste versionen av systemet. 7

9 Resultat Det slutgiltiga resultatet av arbetet har resulterat i en färdig produkt. Nedan följer några skärmdumpar från applikationen med tillhörande förklaringar över vad som visas. 1. Utseende vid installation av systemet 8

10 2. Utseende vid inloggning till systemet. 9

11 3. Startsidan av systemet efter inloggning (visas även som icke inloggad fast i det fallet utan menyvalen Nytt inlägg, Administrera och Logga ut ) 10

12 4. Månadsvisning av händelser i Kalendern efter inloggning (visas även som icke inloggad fast i det fallet utan knappen Lägg till längst ned i bild) 11

13 5. Dagsvisning av händelser i Kalendern efter inloggning (visas även som icke inloggad fast i det fallet utan knappen Lägg till längst ned i bild) 12

14 6. Avancerad sökning med möjlighet till val av olika inställningar i detta fall efter inloggning (visas även som icke inloggad) 13

15 7. Vy för inläggning av en nyhet (visas enbart efter inloggning). 14

16 8. Vy för administrering av diverse inställningar i systemet (visas endast för inloggade användare som är inställda som administratörer) 15

17 9. Vy för avinstallation av installerat system 16

18 Avvikelser Samtliga krav har enligt kravspecifikationen implementerats och därför har inga speciella avvikelser gjorts. Se medföljande kravspecifikation för mer information gällande applikationens krav. Icke inledningsvis planerad funktionalitet, som inte efterfrågats av kund har även valt att implementerats. Detta bestående främst av ett system för installation och avinstallation av slutprodukten. Vars uppgift främst består av att göra det enklare att installera systemet innan användning. 17

19 Slutsats Projektet har i sin helhet fungerat väldigt bra. Vi är framförallt väldigt nöjda med att systemet blivit färdigt och att det fungerar så som det från början var tänkt fungera. Det som fungerat bra i projektet är att samtliga projektmedlemmar har varit delaktiga i att ta fram en fungerande slutprodukt, lyssnat lyhört på kunden och med stor vilja arbetat med projektet gentemot de förbestämda målen. Mindre bra är att det tog några veckor inledningsvis av projektet innan samtliga projektmedlemmar kom igång med själva implementationen. Detta pågrund av att det system vi hade tänkt använda oss av, var allt för avancerat för ett fåtal projektmedlemmar att förstå. Efter några veckor påbörjades dock en ny version som sedan löste problemet. Något som hade varit bra är att vi borde ha haft ett extra möte varje vecka, där alla projektmedlemmar hade kunnat visa upp sitt arbete vilket inte skedde. Vi borde även ha fokuserat mer på tester i början av projektet. Men eftersom det tog lite tid innan en mer färdig produkt kunde användas, så är det ändå i viss mån förståeligt att det blev som det blev. När det gäller handledning, möten med kund och liknande så bokades de in på förbestämda tidpunkter med riktiga träffar där varje möte tog ungefär 30 minuter. Samtliga möten var bra, vi känner också att de gav den information vi behövde både i form av hjälp med dokumentationen, kodfel och förslag på ny funktionalitet att implementera. Även om vi säkert hade kunnat ställa fler frågor än vad som gjordes. Vi hade också kunnat träffa kund vid fler tillfällen än vad som gjordes, men pågrund av produktens varierande utveckling så är det ändå förståeligt att så inte blev fallet. På de arbetsdelarna där vi jobbade kontinuerligt så kunde vi hålla oss enligt tidsplanen i princip fullständigt. De viktiga deadlines som vi hade hölls för det mesta. Dock så kunde de avvika sig lite pga. att vi ändrade oss från att bygga på ett redan halvfärdigt system till att börja om från grunden. Vi tog hänsyn vad kunden ville ha i form utav krav och har implementerat dessa i det befintliga systemet. 18

20 Förslag på vidare utveckling Den implementerade funktionaliteten anses som tillräcklig för de krav som kund efterfrågat, men för att påvisa förslag på vidare utveckling följer här en lista på mer funktionalitet som skulle kunna implementerats: Utskick av e-post vid inläggning av nytt inlägg i nyheter och/eller kalender Användning av fler databashanterare än enbart MySQL, exempelvis Microsoft SQL Server Justering av utseendet via administrationsgränssnittet Mer uppdelad indelning av rättigheter för olika användare av olika delar i systemet Kommentering av nyheter och/eller kalenderhändelser för inloggade användare Utskick av påminnelse för kalenderhändelse via SMS och/eller e-post Eventuell övertagande organisation Eftersom kund skall använda den framtagna produkten, innebär detta att kund bestående av Intensivvårdsavdelningen vid Landstinget i Kalmar, är den kund som anses som den övertagande organisationen. Övriga intressenter är i dagsläget inte kända. 19

21 Förslag till förbättringar inför kommande projekt Under projektets gång har vi kommit att lära oss en hel del. En av de viktigaste och mest lärorika sakerna vi lärt oss är hur olika individer fungerar tillsammans i ett projekt. Även om problem ibland uppstod, som det förmodligen gör i alla projekt, så fungerade arbetet i gruppen väldigt bra. Gruppen i sin helhet hade säkert kunna lägga mer tid på vissa saker i början av projektet. Men pågrund av allehanda orsaker så kom vi inte igång enligt den uppsatta tidsplanen för projektet. Detta är också en av anledningarna till att vi som enskilda individer lärt oss förstå hur projekt i gruppform kan fungera. Vilket varit väldigt lärorikt inför framtiden. Vad gäller kundkommunikationen så fungerade den till en början bra och vi träffades enligt förbestämda tidpunkter. På slutet blev ett par möten inställda av kunden vilket inte spelade så stor roll för vår del, men som innebar att kunden inte fick ta del av vår nya design förrän på redovisningstillfället. Nu i efterhand tycker vi att vi kanske borde haft lite mer kommunikation med kunden, kanske inte i form av personliga möten utan via e-post och/eller telefon. När det gäller lösningen av problemet till hands anser vi att vi, enligt de fördefinierade kraven och den teknik vi använt oss av, gett förslag på lösningar som både var realistiska och genomförbara. Oftast var det kund som kom med idéer och förslag som denne ville ha genomfört, men när vi ansåg att det fanns funktionalitet som skulle kunna förbättra systemet ännu bättre, så var vi inte heller sena med att lägga fram dessa för kund. För det mesta överrensstämde våra förslag och implementerades därefter. Därför anser vi att egentligen inget under denna punkt kunnat göras annorlunda. Riktlinjerna var ganska klara för oss i början om vad vi skulle göra. Att studenter vid programmet Interaktionsdesign, året innan, arbetade med samma kund var till en stor hjälp för oss. Mycket eftersom delar av deras framtagna material tidigt fick oss att förstå hur själva applikationen skulle kunna tänkas se ut och fungera. 20

22 Bilagor Nedan följer de bilagor som hör till projektet, men som inte passar in i rapportens övriga delar. 1. Fysisk databasmodell över den implementerade databasen 21

23 2. Tabellspecifikationer för den implementerade databasen med tillhörande exempeldata Tabell: inflow_calendar Tabell: inflow_user Tabell: inflow_news Tabell: inflow_taged Tabell: inflow_tag Tabell: inflow_file 22

24 3. Tidsplan (Planerad) Förklaringar: Röda markeringar = Gröna markeringar = Viktigt hårt hållna deadlines Kontinuerligt arbete med samtliga uppgifter Planerad tidsplan: Uppgift Samtliga projektmedlemmar är medvetna om allt Projektledare utsedd Färdigt visionsdokument (vision signerad av kund) Stora tekniska risker undanröjda Projektet anses vara genomförbart Mjukvaruarkitektur fastställd och levererad Alla tekniska risker undanröjda Rutiner för testning fastställda Projektet uppskattas vara genomförbart enligt mjukvaruarkitekturen Systemtest och testrapport Leverans till kund Avsluta implementation av ny funktionalitet Iterationsplaner Tidsrapporter Etablera kontakt med kund Handledarmöte Kontinuerlig dokumentation Implementation Projektpresentation Aktiv påvisning av färdigställd inceptionfas Aktiv påvisning av färdigställd elaborationfas Testning av systemet Deadlines & Kontinuerligt arbete Riskhantering Veckor för arbete med projektet:

25 4. Tidsplan (Slutgiltig ungefärlig tidsplan) Förklaringar: Röda markeringar = Gröna markeringar = Viktigt hårt hållna deadlines Kontinuerligt arbete med samtliga uppgifter Slutgiltig ungefärlig tidsplan: Uppgift Samtliga projektmedlemmar är medvetna om allt Projektledare utsedd Färdigt visionsdokument (vision signerad av kund) Stora tekniska risker undanröjda Projektet anses vara genomförbart Mjukvaruarkitektur fastställd och levererad Alla tekniska risker undanröjda Rutiner för testning fastställda Projektet uppskattas vara genomförbart enligt mjukvaruarkitekturen Testrapport Leverans till kund Avsluta implementation av ny funktionalitet Iterationsplaner Tidsrapporter Etablera kontakt med kund Handledarmöte Kontinuerlig dokumentation Implementation Projektpresentation Aktiv påvisning av färdigställd inceptionfas Aktiv påvisning av färdigställd elaborationfas Testning av systemet Deadlines & Kontinuerligt arbete Riskhantering Veckor för arbete med projektet: