Slutrapport - Intranät

Transkript

1 Slutrapport - Intranät Grupp 2. DesignOnline 1DV411 - Webbprojekt I Martin Fohlin, Tobias Holst, Andreas Fridlund, Måns Schütz, Anton Ledström & Sherief Badran 1

2 Sammanfattning I denna rapport beskriver vi det projekt vi har utfört i kursen Webbprojekt I. Kursen gick ut på att göra ett projekt åt en riktig kund för att vi ska kunna praktisera det vi har lärt oss under så verkliga förhållanden som möjligt. Själva uppgiften gick ut på att skapa ett intranät där vår kund har möjlighet att sammanställa information som visas på TV skärmar med syftet att de andra medarbetarna ska var medvetna om vad som görs i andra avdelningar. Rapporten beskriver projektet och våra tankar och reflektioner som uppstått under projektets gång. 2

3 Innehållsförtäckning Sammanfattning 2 Inledning/background 4 Syfte och mål 4 Projektorganisation 4 Genomförande Metodik 5 Genomförande Teknik 6 Resultatbeskrivning Måluppfyllelse 7 Avvikelser Efterkalkyl 8 Slutsats 8 Eventuell övertagande organisation 8 Dokumentationshänvisning/Bilagor 9 Förslag till förbättringar inför kommande projekt 9 3

4 Inledning/bakgrund DesignOnline är en inredningsbutik på webben som säljer allt från möbler och smycken till köksredskap. De lägger stor tyngd på snygg design och kvalitet. DesignOnline efterfrågar ett sätt att förbättra kommunikationen mellan företagets olika avdelningar och öka transparensen inom företaget. De vill även förenkla spridningen av information och statistik till företagets olika kunder och DesignOnline s anställda. Man hoppas att detta medför att företagets medarbetare känner sig mer motiverade och mer delaktiga i företaget. Syfte och mål Kunden vill optimera informationsflödet på företaget med ett intranät som har till uppgift att visa information och statistik på olika skärmar i företagets lokaler. Man hoppas därmed få en större förståelse mellan företagets olika avdelningar. Aktuell statistik behandlar främst inkommande och utgående ordrar inom ett givet tidsintervall, tex. veckovis, månadsvis, och kvartal. Man vill att anställda ska få ta del av information som på ett snyggt sätt presenteras med inkommande och utgående ordrar inom ett visst tidsintervall. Tillsammans med detta vill man också presentera en budgeteringsnivå som ett optimeringsmål för de anställda. I entrén vill kunden även ha en välkomstskärm där de kan skriva meddelanden till besökare och leverantörer. Vi har utvecklat en webbaserad applikation som är kopplad till kundens databaser. Applikationen kan på så sätt få ut deras data i form av text, bilder eller diagram. De olika skärmarna kan dessutom växla mellan olika sidor och därmed visa en varierad mängd information. För att hantera systemet har vi implementerat ett administrationsgränssnitt där kunden har möjlighet att skapa mallar, skärmar och dess innehåll. Projektorganisation I projektorganisationen ingår 6 medarbetare, alla är studenter på campus vid Linnéuniversitetet. I projektgruppen ingår Martin Fohlin, Tobias Holst, Andreas Fridlund, Måns Schütz, Anton Ledström och Sherief Badran. Till vårt förfogande har vi kursansvarig och vår handledare Tobias Olsson och Emil Carlsson. 4

5 Genomförande - Metodik Vi har använt arbetsmetoder som Unified Process och SCRUM. Utvecklingen av projektet har delats in i de fyra faserna inception, elaboration, construction och transition. Varje vecka har resulterat i en iteration och varje iteration har innehållit återkommande element så som kund, grupp och handledningsmöten. Roller och ansvarsområden inom gruppen har varit fasta genom hela projektet. Gruppmedlemmarna har då haft ansvar över sina arbetsuppgifter inom ramarna för det ansvarsområdet de tilldelats. Vi har också veckovis haft kontinuerlig kontakt med kunden. Vi bestämde oss snabbt för vilka tekniker vi ville använda och började med att testa diagram som skulle användas i projektet. Detta resulterade i att vi snabbt elimenerade några av de stora riskerna. Kommunikationen mellan oss i gruppen har fungerat bra då alla har varit på plats i datorsalarna mer eller mindre dagligen, samt att vi använts oss av en SMS grupp och mail grupp för snabb och effektiv kontakt. För att kunna organisera vilkar uppgifter medlemmarna jobbade med så har vi använt oss av en product backlog med sprintar. Dessa innehåller id, status och initialer för att enklare kunna få en överblick om vad som pågår i projektet. Medlemmarna rapporterade även hur lång tid de jobbade med uppgifterna, vilket gav oss information om hur mycket varje individ jobbat samt hur lång tid dennes uppgift tog att lösa. Som versionshanterare har vi använt oss av Github, och för att hålla all dokumentation på ett ställe har vi använt oss av Google Drive. Eftersom vår kund inte hade en riktigt klar bild på vad man ville ha, så var det upp till oss att komma på ideér för hur applikationens olika delar skulle se ut, vilket gjorde arbetet svårare. Det fanns bra instruktioner från kursledningen om vad som skulle göras under de olika faserna, vår handledare hjälpte oss även att bättre förstå vad som förväntades av oss varje vecka. Det som vi saknade var mer exakt vad som skulle ingå för dokumentation i de olika faserna. I det stora hela har vi hållt tidsplanen och vi lyckades få en färdig produkt som går att använda färdig och pulicerad på kundens servrar. Vi har fått dra in på en del funktioner då det visat sig att andra funktioner har tagit mer tid än vad som förväntades, och en hel del buggar har gjort att vi bestämde oss att dra ner vissa mindre krav och få de viktigaste att fungera felfritt. Mot slutet har vi också blivit bättre på att sätta upp och genomföra tidsplaneringen, och det blev även bättre när vi uppdaterade våre sprintar så de även innehöll information om vem som för närvarande jobbade med vad. 5

6 Genomförande - Teknik Första mötet med kunden berättade de att de var intresserade av att se vad man kan göra med nya tekniker inom webbprogrammering. Vi blev därför uppmuntrade till att använda nya tekniker/ramverk för att bygga den efterfrågade produkten. Frontend Angular js som frontend ramverk tillsammans med angular charts för att rendera diagram vid presentation av data från kundens order och leverans databaser. Backend Ett REST api byggt i ASP.net 5 och Web API. Uppdelat med en domänmodell som implemeterar ett facade mönster som exponerar de olika service lagren. Testning Vi har använt oss av unit test som det primära testramverket. Tanken med unit tester är att man ska kunna isolera valda delar av applikationen och testa dessa delar för sig. Vi har valt att lyfta ut ett context interface och implementera ett testcontext och därmed plocka bort databasen och sql delen ur testerna. Detta har en del nackdelar och en del anser att detta medför att man inte genomför sina tester på ett tillfredsställande sätt. Man använder sig inte av den underliggande sql:en och beteendet i applikation kan i vissa speciella fall ändras när man kör mot en skarp databas. Vi har däremot ett ganska stort Service lager med mycket funktionalitet, vi är medveten om unit testernas brister och vi ställer inte så komplexa frågor till databasen, vi anser att service lagret är det viktigaste att testa. En fake context förenklar detta avsevärt och gör även testningen snabbare. Det finns också på plats att utveckla testningen mycket i framtida iterationer, applikationen är designad med mycket goda testmöjligheter. Det som primärt saknas i vår testsvit är end to end tester och browser tester som också bör täcka in front end, men detta är något som inte har hunnits med. Projektet har använt en hel del nya tekniker och vi har inte haft någon tidigare erfarenhet från testramverk som hade kunnat underlätta den biten. Versionshantering Versionshanteringen har hanterats med hjälp av git. 6

7 Resultatbeskrivning Måluppfyllelse Intranätet är byggt så att kunden kan skapa presentationer som visas i webbläsaren på en skärm. Från varje skärm adresseras en presentation med hjälp av en url som anges i webbläsaren. En skärm visar en presentation som växlar mellan olika sidor där varje sida har en vald mall med utrymme för texter, diagram och bilder. Systemet är mycket dynamiskt eftersom kunden via ett administrationsgränssnitt själv kan skapa skärmpresentationer, sidor och mallar samt fylla dessa med önskad data. Skärmpresentationer och sidor är helt separerade från varandra vilket innebär att kunden exempelvis kan återanvända skapade sidor på flertalet olika skärmpresentationer. Applikationen är kodmässigt strukturerad på ett sätt som gör det lätt att bygga ut och vidareutveckla den med mer funktionalitet. Avvikelser - Efterkalkyl I samråd med kunden kunde vi i ett tidigt skede avgränsa vilka användningsfall som skulle ingå som minimikrav. I stora drag motsvarar dessa ett antal hårdkodade skärmpresentationer som kan presentera det som beskrivs under rubriken ovan. Eftersom vi tidigt i construction fasen hann med att implementera minimikraven kunde vi gå vidare med krav och användarfall för att skapa ett administrationsgränssnitt som gör applikationen mer dynamisk. Där har ett fåtal avvikelser varit nödvändiga då administrationsgränssnittet gjorde applikationen mycket mer komplex. Vi har inte gjort några större avvikelser och uppfyllt alla de högst prioriterade kraven. Ett krav som ej har uppfyllts är kundens önskemål om kunna lägga in/presentera en youtube film, detta var dock ett krav som vi gav låg prioritet redan från start. Det finns inte heller möjlighet att redigera befintligt innehåll på skrämarna, man måste då ta bort och skapa nya. 7

8 Slutsats Samarbetet mellan alla i gruppen har fungerat bra, och en stor faktor till att arbetet gick så bra var nog för att alla arbetat tillsammans på campus och på så sätt kunnat kommunicera lättare med varandra. Vi har lärt oss mycket av varandra, att koda på ett sätt som underlättar för alla i gruppen och att komplettera varandra på ett bra sätt. Kunden har varit väldigt abstrakta i sina krav, vi har själva varit tvungna att ta fram kraven för applikationen. Detta har varit ganska krävande. Vi har haft kundmöten och handledningsmöten varje vecka och fått återkoppling om vad som skulle göras och vad som behövts göras, vi har även haft kontinuerlig kontakt med kund om både problem och sådant som har uppstått. Vi har varit lite dåliga på att uppdatera våra dokument kontinuerligt och vi hade inte så bra struktur i början på våra dokument. Med tiden gick även detta bättre och vi fick bättre struktur på våra dokument. Testning var något vi borde ha börjat göra tidigare och vi hittade många buggar att lösa på kort tid för att få en bra produkt. Allt som allt så är vi nöjda med vad vi har gjort under denna tid och vi blev nöjda med hur vårt projekt slutade och hur vår slutprodukt blev. Förslag på vidareutveckling Text ska kunna ha olika typsnitt Text ska kunna "rulla" över fältet En sida ska kunna rendera bilder i olika storlekar(full storlek, bredd eller höjd i %) En del av en sida ska kunna spela upp en film från youtube En sida ska kunna tas bort från en skärmpresentation (för närvarande går det endast att ta bort en skärmpresentation). Bristfälliga automatiska tester både på servern och saknas helt på klientsidan. Det krävs manuell handpåläggning för att skapa templates som senare kan läggas in i systemet via admin. 8

9 Eventuell övertagande organisation Vi lämnar över all kod och dokumentation till Design Online att vidare utveckla denna applikation. Dokumentationshänvisning/Bilagor Vi har inte använt oss av någon litteratur under vår utveckling och hänvisar därför till vår dokumentation. Vision Projektplan Användarfall Mjukvaruarkitektur Förslag till förbättring inför kommande projekt Vi känner att vi har arbetat efter en bra modell men ett problem som vi hade i början var att vi inte hade så bra struktur på vem som gjorde vad i projektet vilket resulterade i att man arbetade på samma sak och överlappade varandra. Detta är något som ordnade upp sig en bit in i projektet men kunde ha undvikits helt om vi direkt från början hade strukturerat upp vårt dokument för tidrapportering. Den andra stora delen av projektet som var väldigt jobbig var att vi skulle lägga upp hela applikationen på en webbserver som inte var konfigurerad. Detta var något vi inte testat om det fungerade från början vilket resulterade i många timmar av att försöka få igång applikationen på webbservern. Lärdommen vi tar med oss är att en deploy mot webbserver ska testas i ett så tidigt skede som möjligt för att minimera risk och verifiera att saker går som planerat. Problemet med en relativt sen deploy är att det blir avsevärt svårare att utesluta tänkbara fel. 9