Red Inc. Förstudie till. Inkrementell uppbyggnad av Webbdatabas för småföretag. Uppdragsgivare: Harald Kjellin

Transkript

1 Förstudie till Red Inc Inkrementell uppbyggnad av Webbdatabas för småföretag Uppdragsgivare: Harald Kjellin Projektmedlemmar: Mikael Nyqvist Ulf Rustas Thomas Jansson Rikard Laxhammar Daniel Oscarsson Emil Stridfeldt Alexander Ahl Karin Råde

2 Innehållsfärteckning Innehållsfärteckning Problembeskrivning Bakgrund Problemet Syfte Krav och avgränsningar Krav från uppdragsgivare Användare Funktioner Datormiljö Ordlista Förslag till lösning Systemskiss Moduler Diagram Preliminär användarhandledning Sökningar/Rapporter Objektformulären - Visa/Ändra/Lägg till objekt Genomförande Projektets styrning och genomförande Ansvarsfördelning Projektledare Vice projektledare Informationsansvarig Databasansvarig JSP/XML-ansvarig Testningsansvarig Sekreterare Administration och möten Dokumentation Preliminär tidsplanering Riskanalys Tidsplanering Felaktig tidsplan Ofullständig tidsplan Tidsplanen ej följs Sjukdom eller annan frånvaro av gruppmedlem Dokumentationen hamnar på efterkälke Produkten Att projektet ej uppfyller specifikationen Beställaren Beställaren ändrar direktiv under projektets gång / Missförstånd mellan beställare och grupp Gruppen Missförstånd inom gruppen Gruppen inte kommunicerar tillräckligt Gruppen ägnar för mycket tid åt möten För låg kunskapsnivå i gruppen

3 1 Problembeskrivning 1.1 Bakgrund Alltmer företag upptäcker att de har behov att samla in, lagra och söka information via webben. Det kan handla om att anställda rapporterar arbetsresultat genom att fylla i ett webbformulär, reseräkningar sköts via formulärhantering, man använder webben för att göra det möjligt för kunder att boka en tjänst t ex en resa, en biobiljett, anmäla sig till en kurs på universitetet etc. De flesta sådana system använder MS-asp eller Java-Servlets och dessutom någon form av relationsdatabas för att sköta kommunikationen med slutanvändaren som via sitt webbgränssnitt kommunicerar med databasen. De flesta sådan system är uppbyggda runt en relativt enkel vision av hur tjänsten bör utformas. Varje gång företaget behöver lägga till en ny webbtjänst så måste ett nytt system för detta byggas eftersom tidigare system har blivit specialkonstruerade och hårdkodade för bara ett enda syfte. Dessutom blir det svårt att få informationen från de olika databaserna att samverka. För mycket stora företag är detta inget problem. De kan använda stora standardsystem i kombination med SAP, Oracle m.m. för att bygga upp en enhetlig portal mot anställda och kunder. 1.2 Problemet Man skulle önska att det vore möjligt att ha en generell design på en databas för webbtjänster. Att man kunde ha samma databas för olika webbtjänster och att mindre företag kunde bygga upp sina webbtjänster steg för steg på denna. Fördelarna med detta skulle vara att man då kunde göra kombinerade sökningar (utan att behöva 3

4 tillämpa ett "Data-Warehouse" perspektiv på databaserna eller köpa svindyr applikation typ SAP). En sådan generell databas skulle dock ställa stora krav på enhetlig standard för hur data lagrades och hämtades i databasen. 1.3 Syfte Vårt syfte är att designa en metod som utifrån en XML-standard skapar enhetliga objekt för lagring i en standardiserad databas och sedan implementera ett system som accepterar XML-sidor som input och ur dessa sidor skapar en output av färdiga webbapplikationer för lagring och sökning av data. Vårt mål är att leverera en fungerande prototyp, kallad Red Inc, som är en inkrementell databas för småföretag. All erforderlig dokumentation skall dessutom skrivas enligt god sed och levereras inom givna tidsramar. 1.4 Krav och avgränsningar Krav från uppdragsgivare Språket bör vara Java och Java-Servlets. Databasen bör var open-source, gärna skriven i Postgress. Slutprodukten bör vara freeware och open source med dokumenterad kod. Detta betyder att enda sättet för projektgruppen att kapitalisera resultatet är att implementera systemet hos de kunder som vill betala för att få systemet installerat Användare Red Inc kommer att ha två användare, administratören och övriga användare. Administratören skall ha minst 3 veckors erfarenhet av att programmera med XML, och kommer att ha fullständiga rättigheter. Övriga användare t ex anställda skall behärska en webbrowser, och kommer att ha begränsade rättigheter. 4

5 Red Inc kommer att stödja administratören, i ett företag, i dess arbete att ta fram specifika system som sedan de anställda kan nyttja. Hur användarna och system interagerar visa i figur 1. Red Inc Specifikt system Administratör Slutanvändare Figur 1: Användarna Funktioner Red Inc är en generell databas och kommer därför stödja de funktioner som är typiska för en databas; lagra, editera och söka information. Red Inc är dessutom inkrementell, dvs. administratören skall kunna skapa och editera formulär med hjälp av XML-filer. Formulären används sedan som in- och utmatningsformulär av de anställda för att behandla information Datormiljö Hårdvara Systemet skall verka på en plattformsoberoende miljö. Den föreslås användas i en PC-miljö i nätverk Mjukvara För att behandla data behövs en webbrowser. Till databasen skall Postgress användas. Kommunikationen mellan webbgränssnittet och databasen skall skötas av JSP. 1.5 Ordlista För att underlätta förståelsen av de uttryck vi kommer att använda oss av i de dokument som kommer att presenteras inom projektet följer nedan en mindre ordlista. 5

6 Freeware; ett gratis program som är fritt att använda av alla. HTML; HyperText Markup Language, standard språket för programmering av hemsidor på internet idag. Java; Ett objekt-orienterat programmeringsspråk Java-Servlets; generar html sidor med hjälp av javakod. JSP; Java Server Pages, se Java-Servlets Metadatabas; en databas över en databas Open Source; Innebär att alla får använda och sprida ett program fritt och att källkoden är öppen, med andra ord tillgänglig för de intresserade. Likt freeware men inte samma krav på källkoden. Postgress; databasprogram som får användas fritt (freeware) Specifikt system; skapas av administratör utifrån Red Inc SQL; Structured Query Language programmeringsspråk som används vid hantering av databaser. Webbtjänst; tjänst som erbjuds på internet. Webbformulär; formulär på internet. Webbrowser; Verktyget/programmet som används för att surfa på webben XML; Extensible Markup Language, ett språk som gör det möjligt att definiera innehåll och innehållets innebörd i ett dokument. 2 Förslag till lösning 2.1 Systemskiss Systemet byggs upp av tre funktionalitetsnivåer med olika roller att uppfylla i samverkan: XML-nivå, Servlet/JSP-nivå samt databasnivå. XML-nivån är administratörens kontakt med systemet. Härigenom kan han/hon definiera funktionaliteten för det specifika systemet. Denna funktionalitet kan således ändras/uppdateras/utökas när som 6

7 helst av administratören, allt efter behov, genom editering av XMLfilerna. Servlet-nivån utgör kärnan och motorn i systemet. På denna nivå utförs det som specificeras av administratörens XML-filer, dvs. kommunikation med användaren och med databasen. Servleten genererar alltså html mot användaren och initierar förfrågningar mot databasen. På databasnivå sker all lagring av information. Här hamnar eventuella tyngre algoritmer för sökning och lagring Moduler För att ge en mer specifik bild av vilka aktörer som samarbetar i ett färdigt system så visar vi i figur 2 ett modulschema. Av dessa moduler tillhör XML-spec, JSP samt DB Red Inc, dvs. det system vi utvecklar. Modulerna XML-filer och WebServer bidrar administratören med och browsermodulen finns hos slutanvändaren. Det generella användarfallet som förklarar modulschemat är som följer: slutanvändaren navigerar in på en webbadress som är till för att accessa det specifika systemet. Här kan användaren göra olika saker som innebär sökning eller ändring i databasen, som t ex bokning av biljett. För att kunna visa något behöver browsern HTML-kod från webservermodulen. JSP-modulen står för genereringen av denna HTML-kod. XML-filermodulen bestämmer vilken HTML-kod som JSP-modulen skall generera. XML-filerna skrivs av administratören efter den mall som XML-specmodulen utgör. När användaren vill få tillgång till databasen så gör JSPmodulen uppslagningar i DB-modulen. 7

8 Administratör XML-fil XML spec. Klient/Browser WebServer JSP Slutanvändare DB Red Inc Figur 2: Moduler Diagram Roller och kontrollflöde i de generella användarfallen Vi tänker oss tre generella användarfall för slutanvändaren som systemet skall stödja, nämligen att ändra data i databasen (t.ex. boka biobiljett), att söka i databasen, med en objektlista som resultat (t.ex. visa lediga föreställningar), samt att visa detaljer om ett objekt (t.ex. läs om en viss film eller visa lediga platser på en föreställning). I figurerna 3 och 4 visar vi hur vilka roller de olika aktörerna spelar i arbetsgången i dessa tre fall. Figur 3 visar arbetsgången för fallen ändra data och visa detaljer (då båda opererar på enskilda objekt) och figur 4 visar arbetsgången för sökningar som opererar på hela databasen, dvs. objektmängder. 8

9 Användare JSP DB Klickar på länk Läser in XML filen som är knuten till den adress som användaren klickar på. Ska man lägga till nytt data, eller editera/visa befintligt objet? NYTT Läser in data från databasen för det objekts fält man vill visa. Dessa anges i XML-filen. VISA Förvandla XML till HTML. Visa HTML Ska man editera objektet eller bara visa det? Om man ska editera genereras ett HTMLformulär, annars bara en vanlig HTML-sida. Visa HTML-formuläret. Fyller i HTML-formuläret och postar det Tar emot och översätter till SQL JA Lägg in data. Fanns alla de fält som användaren fyllt i redan i databasen? Visa HTML Parsa resultaten till HTML med hjälp av XML filen. NEJ Uppdatera databas med nya fält. Lägg in data Visa HTML Parsa resultaten till HTML med hjälp av XML filen. Figur 3: Visa och ändra data 9

10 Användare JSP DB Klickar på länk Läser in XML filen som är knuten till den adress som användaren klickar på. Generera ett HTML-formulär med textrutor som kan användas till att specifiera värden man vill söka efter. Fyller i sökrutorna HTML formuläret och postar det Tar emot och generera ett SQLuppslag. Kör SQL-uppslaget. Returrnera resultaten Översätt resultaten till HTML med hjälp av XML filen. Visa HTML. Figur 4: Söka data 10

11 Metadatabasgrund För att kunna realisera ett dynamiskt inkrementellt databassystem behöver vi en relationsdatabas i grunden som beskriver relationerna mellan objekt, attribut, relationer, mallar, datatyper, osv. för all data vi vill lagra. I figur 5 visar vi en preliminär konceptuell bild av hur vi tänkt oss denna metadatabas. * PossibleValues 1 MultiValueAttribute TextAttribute Attribute Template Area * 1 * 1 NumericAttribute 1 1 * * MultiValueRelation Relation * 1 Object TextRelation {Subtypen av Relation måste ha rätt subtyp av Atrtibute} NumericRelation Figur 5: Underliggande relationsdatabas I tabellen Object lagras alla enskilda instanser av objekt i databasen. Varje objekt är av en typ (t.ex. patient, biobiljett, bil, fordon), vilket beskrivs i tabellen Template. Varje objekttyp/mall har en viss mängd attribut, vilket beskrivs med kopplingen till Attributetabellen, där alla tänkbara attribut för objekt i databasen lagras. I tabellen Relation lagras slutligen alla attributvärden för alla objekt. Denna klass bär alltså i viss mening datamassan för hela databasen. Attribut- och relationstabellerna behöver förmodligen delas upp i 11

12 subklasser för att vi ska kunna hantera olika datatyper på ett effektivt sätt. Vi har dessutom en Area-tabell där man kan knyta objekttyper till områden inom en organisation, vilket tillåter sammanslagning av databaser avsedda för vitt skilda uppgifter inom organisationen (t.ex. löneavdelning och marknadsföringsavdelning). 2.2 Preliminär användarhandledning Den enda användarhandledning som är väsentlig i vårt fall är gentemot administratören eftersom det är han/hon som sedan vidarebefordrar service till slutanvändaren. Denna handledning utgörs till stor del av XML-specen vi skapar. Administratören kommer dock att få vägledning i hur dessa skall tolkas, men i nuvarande läge är det för tidigt att gå in på XML-specen. Däremot kan vi här visa lite hur vi har tänkt att gränssnittet för slutanvändaren kan se ut Sökningar/Rapporter Systemet är tänkt att kunna generera sök/rapportsidor, där man ska kunna söka på olika attributvärden och få fram de objekt som matchar. Man ska kunna söka på specifika attribut och objekt, men det ska också finnas en allmän sökning, där man söker igenom alla objekts alla attribut efter matchande värden. Utseendet på söksidorna specificeras i särskilda XML-sidor av webbsidans administratör. I dessa ska man kunna välja t ex. vilka attribut och objekt man kan söka på, vilka attribut som ska presenteras i resultatet och även vilka kommandokolumner (Visa/Ändra/Ta Bort/Lägg till ny/...) som ska visas. OBS! Bilderna nedan ska bara ses som förslag på vilken funktionalitet en rapport skulle kunna ha, det är mycket möjligt att 12

13 det färdiga systemets utseende kommer att skilja sig avsevärt från dessa. Figur 6 - Sökning på specifikt objekt (person). Om man klickar på Visa eller Lägg till ny person tas man till resp. objektformulär. Figur 7 - Allmän sökning, det fanns både Personer och Bilar som matchade sökningen. 13

14 2.2.2 Objektformulären - Visa/Ändra/Lägg till objekt. Den andra huvudtypen av formulär som genereras av systemet är objektformulär som visar ett objekt hos en specifik objekttyp i taget. Utseendet av dessa bestäms av webbsidans administratör genom att editera XML-filer. De tre olika funktionernas formulär är såpass lika så att det är mycket möjligt att man skulle kunna generera HTML-koden från samma XML-fil för en given objekttyp. Däremot har olika objekttyper olika XML-filer. I XML-filerna ska man kunna välja vilka fält som ska visas. Figur 8 - Visa objekt (person) Figur 9 - Ändra objekt (Person) 14

15 Figur 10 -Lägg till objekt (Person) 3 Genomförande 3.1 Projektets styrning och genomförande Som övergripande styrmodell för vårt projekt har vi valt PPSmetoden, utvecklad av TietoEnator. PPS-metoden är ganska omfattande och projektmedlemmarna har en begränsad kunskap och erfarenhet kring nyttjandet av metoden. Endast en översiktlig föreläsning om metoden har hållits för projektets medlemmar. Därför kommer i praktiken endast ett urval av alla de mallar som finns att användas i detta projekt. Projektet kommer att följa de allmänna beslutspunkter som finns i PPS-metoden, där varje beslutspunkt kan ses som en milstolpe i utvecklingen. I och med att denna förstudie är färdigskriven och överlämnad till beställaren har projektet nått fram till beslutspunkt 4, där beslut om projektets genomförande skall fattas. I nästa fas, design och implementation av mjukvaran, kommer några beslutpunkter följa som avstämningspunkter för projektets utveckling. I projektets slutskede, leverans och slutlig överlämning av mjukvaran, kommer även här ett fåtal beslutspunkter styra arbetet. 15

16 Projektets programmering kommer att till största delen ske i UNIX miljö, då vi använder oss av KTH:s resurser för programmering. Versionshantering är tänkt att ske med sunt förnuft och att använda oss av daterade ZIP-filer. 3.2 Ansvarsfördelning Projektledare Har det övergripande ansvaret för projektet och dess genomförande. Tillsammans med vice projektledaren skall denna ansvara för att den övergripande planeringen följs, att deadlines respekteras och att den beställda produkten levereras till kund enligt överenskommelse Vice projektledare Arbetar tillsammans med projektledaren samt tar över dennes uppgifter och ansvar vid projektledarens frånvaro Informationsansvarig Ansvarar för dokumentation, samordning av data och projektets webbplats Databasansvarig Ansvarar för definition och funktionalitet för databasen samt dess gränssnitt mot andra moduler JSP/XML-ansvarig Ansvarar för definition och funktionalitet för de moduler som hanterar gränssnittet mellan användare och databas Testningsansvarig Utför tester på produkten för att undersöka dess funktionalitet innan leverans till kund. Produktens funktionalitet godkänns av projektledaren innan leverans. 16

17 3.2.7 Sekreterare Dokumenterar och för protokoll vid mötena. I projektet används roterande sekreterare. 3.3 Administration och möten Bortsett från möten i samband med beslutspunkter kommer projektledaren att en gång i veckan sammankalla gruppen till informella möten. Under dessa möten kommer framgång, problem och lösningar i projektarbetet att diskuteras samt uppställning av nya delmål. Målet är att kunna fastställa en återkommande tid i veckan för möten, men det troliga är att mötestiden ibland kommer att variera från vecka till vecka. Under mötet, som leds av projektledaren, utses i vanlig ordning en sekreterare. Sekreteraren ansvarar för att mötesanteckningar görs och att dessa vidarebefordras till informationsansvarige, som i sin tur lägger upp dem på projektets hemsida Dokumentation Projektets informationsansvarige har det övergripande ansvaret för all dokumentation. Skrivarbetet inom de olika delarna av dokumentationen kommer dock att delegeras till lämpliga projektmedlemmar, för att sedan sammanställas av informationsansvarige som ser till att dokumenten blir färdiga i tid. Nedan följer en kort beskrivning av projektets dokumentation. 1. Förstudie; innehåller preliminära specifikationer. 2. Lägesrapport; summarisk situationsstatus. 3. Projektpresentation 4. Användarhandledning 5. Minnesanteckningar; skall föras vid alla möten. 1 Projekthemsidans adress: 17

18 3.5 Preliminär tidsplanering V Initiering av projekt där projektledare utses. Genomgång tillsammans med beställaren och en första kravspecifikation av produkten görs. En motspecifikation levereras och överenskommelse nås om slutlig kravspecifikation. Indelning av ansvarsområden för projektets medlemmar. Inlämning av kravspecifikation till beställare och kursansvarig skall ske senast den 15 december. Beräknad tidsåtgång är 20 timmar per projektmedlem varav åtta timmar möten. V Preliminär bedömning av förstudie den 10 januari. Muntlig lägesrapport till beställaren skall ske i början av mars. Implementation av de olika modulerna skall ske. Löpande arbete med dokumentation. Beräknad tidsåtgång timmar per projektmedlem varav tio timmar är möten. V Förberedelser av förhandsvisning och sammanställning av dokumentation skall utföras. Förhandsvisning skall ske i början av april och inlämning av dokumentation. Sluttestning av produkt. Beräknad tidsåtgång 30 timmar per projektmedlem varav sex timmar är möten. V. 16 Påsklov 18

19 V. 17 Muntlig slutredovisning sker i månadsskifte april/maj. Förberedelse inför slutredovisning och opposition (2 stycken) Beräknad tidsåtgång 20 timmar per projektmedlem varav 10 timmar är möten. 4 Riskanalys 4.1 Tidsplanering Felaktig tidsplan Effekt: En oöverlagd eller orealistisk tidsplan leder till felprioriteringar av tillgänglig tid, vilket i sin tur kan leda till att mindre viktiga delar upptar tid som borde ha allokerats till mer kritiska delar av projektet. Detta leder typiskt till hög arbetsbelastning i slutet av projektet och onödiga brister i genomförandet. Sannolikhet: Hög Åtgärd: Att noggrant gå igenom de olika delarna av projektet, prioritera dem och tilldela dem troligt tidsutrymme. Följa upp att delmomenten hinns med och i nödvändiga fall omprioritera dem Ofullständig tidsplan Effekt: Om delar av projektet missats i tidsplanen, riskerar vi tidsbrist eller att inte uppfylla kravspecifikationen. Sannolikhet: Medel Åtgärd: Kolla tidsplan mot kravspecifikationen Tidsplanen ej följs Effekt: Projektet ej klart i tid eller inte uppfyller kravspecifikationen. Sannolikhet. Medel 19

20 Åtgärd: Uppföljning av tidsplanen, omplanering och omprioritering. Dessutom bör tempot i början av projektet hållas uppe, vilket kan ge extratid mot slutet till oförutsedda problem Sjukdom eller annan frånvaro av gruppmedlem Effekt: Arbetsbelastningen ökar för resten av gruppen. Kunskap eller material oåtkomligt för resten av gruppen. Sannolikhet: Medel Åtgärd: Genom att arbeta i par, dokumentera utfört arbete och sända det till informationsansvarig alternativt lägga arbetet i gemensam mapp, kan problem minimeras, Dokumentationen hamnar på efterkälke Effekt: fullständig dokumentation saknas vid slutpresentationen. Restuppgift för gruppen. Sannolikhet: Medel Åtgärd: Kontinuerlig dokumentation allteftersom delar färdigställs. 4.2 Produkten Att projektet ej uppfyller specifikationen Effekt: Beställaren blir ledsen, gruppen underkänd. Sannolikhet: Låg Åtgärd: Sköta återkoppling till beställaren och noggrant redovisa framsteg i projektet. 4.3 Beställaren Beställaren ändrar direktiv under projektets gång / Missförstånd mellan beställare och grupp Effekt: Tidsplaneringen måste ändras. Tidsbrist kan uppstå. Arbete kan ha utförts i onödan. Sannolikhet: Låg Åtgärd: God och kontinuerlig kontakt med beställaren ska hållas. Bra projektbeskrivning så att alla inblandade vet vad som skall utföras. 20

21 4.4 Gruppen Missförstånd inom gruppen Effekt: Dubbelarbete eller att vissa moment missas. Tidsbrist kan uppstå. Sannolikhet: Medel Åtgärd: Kommunikation inom gruppen hålls ständigt. Tydlig arbetsfördelning görs. Projektledaren följer upp arbetet och håller kontakt med gruppmedlemmarna Gruppen inte kommunicerar tillräckligt Effekt: Det kan bli besvärligt att sammanfoga delarna till en fungerande enhet. Tidsbrist eller en dåligt fungerande produkt. Sannolikhet: Medel Åtgärd: Möten med god avrapportering och en bra projektplan som kontinuerligt följs upp Gruppen ägnar för mycket tid åt möten Effekt: Ineffektiv tidsanvändning. Riskerar att komma efter i tidsplan. Sannolikhet: Låg Åtgärd: Gruppmedlemmarna dokumenterar vad de gjort sen sist, så att man kan hålla sig uppdaterad på vad de andra gjort. Effektiv avrapportering på mötena För låg kunskapsnivå i gruppen Effekt: Lösningar på problem i speciellt implementeringsfasen blir onödigt krångliga eftersom kunskapen saknas för att lösa problemet på ett effektivt sätt. Problemet kanske löses effektivt men orsakar förseningar vilket kan leda till att projektet inte blir klart i tid eller att projektet inte uppfyller de krav som är ställda. Sannolikhet: Hög Ätgärd: Genom att avsätta mer tid till förstudie ökas kunskapsnivån inom implementationsteamet innan utvecklingsfasen 21

22 startar. Att sedan göra små prototyper med användande av olika typer av tekniker för att sedan göra en utvärdering av dem ger ett bättre beslutsunderlag vid val av teknik än enbart genom instudering av källmaterial. 22