Projektplan, Cykelgarage

Storlek: px

Starta visningen från sidan:

Download "Projektplan, Cykelgarage"

Lovisa Axelsson
för 9 år sedan
Visningar:

1 Projektplan, Cykelgarage Johan Anderholm, Jon Andersen Marcus Carlberg Simon Ekvy Stefan Johansson Angelica Gabasio Grupp 15 Projekthandledare: Richard Berntsson Svensson 29 april 2009

lth.se) Stefan Johansson (dt08sj7@student.lth.se) Angelica Gabasio (dt08ag8@student.

2 Innehåll 1 Ändringshistorik 2 2 Introduktion Projektmodell Syfte Mål Begränsningar Projektorganisation Utvecklingsorganisation Intressenter Hårdvara och mjukvaruresurser 3 5 Arbetsfördelning Aktiviteter Leveranser Milstolpar Schema och beräknat arbete Rapportering, uppföljning och kvalitetsförsäkring 5 7 Riskanalys 6 1

............................. 3 4 Hårdvara och mjukvaruresurser 3 5 Arbetsfördelning 3 5.1 Aktiviteter.............................. 3 5.2 Leveranser............................... 4 5.

3 1 Ändringshistorik Ver. Datum Förf. Förklaring MC Första utdrag JA Korrigerad enligt synpunker från Richard 1.0a JA Uppdaterade affärsmål Referenser [1] Project and Exercises in the Software Engineering Process, Software Engineering Research Group Department of Computer Science Lund University [2] A Concise Introduction to Software Engineering, Pankaj Jalote 2 Introduktion 2.1 Projektmodell Vi följer projektmodellen specificerad i kapitel 3[1]. 2.2 Syfte Syftet med projektet är att utveckla mjukvara för ett kösystem i ett cykelgarage. Hårdvaran utvecklas parallellt med mjukvaran. Systemet ska vara lätt att underhålla och vidareutveckla. 2.3 Mål Affärsmål En kommun vill erbjuda säker och tillförlitlig cykelförvaring. Detta för att minska den kraftiga ökningen av cykelstölder inom komunen. Produktmål Produkten ska klara av hög belastning i form av många cyklar samt att bibehålla en hög säkerhetsnivå. Mjukvaran ska sköta en ingång med pinkodsterminal och streckkodsterminal, samt en utgång. Utgången har streckkodsläsare och tillåter utgång med cykel. Det finns även en obevakad dörr som endast är till för utgång utan cykel. In- och uttagning av cyklar sköts med streckkod för att identifiera cykeln och pinkod för att identifiera ägaren. Projektmål Målet är att utveckla mjukvara till ett kontrollsystem för ett cykelgarage. 2.4 Begränsningar Hårdvaran utvecklas parallellt och kan därför inte testas under tiden för projektet. Detta innebär att väldigt utförliga tester måste utföras. Deadline är bestämd och går inte att ändra. Projektet har ingen budget, således kan personalen inte utökas. 2

Concise Introduction to Software Engineering, Pankaj Jalote 2 Introduktion 2.1 Projektmodell Vi följer projektmodellen specificerad i kapitel 3[1]. 2.2 Syfte Syftet med projektet är att utveckla mjukvara för ett kösystem i ett cykelgarage.

4 3 Projektorganisation 3.1 Utvecklingsorganisation Deltagarna i projektet är: Johan Anderholm (Projektledare och mjukvaruutvecklare) Stefan Johansson (Kravspecifikationsansvarig och mjukvaruutvecklare) Simon Ekvy (Testplansansvarig och mjukvaruutvecklare) Angelica Gabasio (Huvudansvarig för designdokumenten och mjukvaruutvecklare) Jon Andersen (Mjukvaruutvecklare) Marcus Carlberg (Mjukvaruutvecklare) 3.2 Intressenter Beställare, ETSA01 som är en lund baserad kurs. Utvecklare, samtliga deltagare som ovan. Kursansvarig, Martin Höst. Projekthandledare, Richard Berntsson Svensson. 4 Hårdvara och mjukvaruresurser Följande verktyg kommer att användas till utvecklingen: Latex, ordbehandling för alla dokument. Eclipse, används vid programering. Subversion mot Google Code, används för att ha koll på de olika versionerna av samtliga filer inom projektet. Testdrivrutiner, används för att simulerar hårdvaran vid systemtest. 5 Arbetsfördelning 5.1 Aktiviteter Projektplanering: Planeringen av projektet. Denna rapport. Kravspecifikation: Kraven för projektet identifieras och definieras. Detta resulterar i en kravspecifikation. Testplanering: Planering av alla test som ska utföras. Detta resulterar i en testplan. 3

(Testplansansvarig och mjukvaruutvecklare) Angelica Gabasio (Huvudansvarig för designdokumenten och mjukvaruutvecklare) Jon Andersen (Mjukvaruutvecklare) Marcus Carlberg (Mjukvaruutvecklare) 3.

5 Design: En översiktlig beskrivning av systemets struktur. Detta resulterar i ett designdokument. Olika personer blir ansvariga för olika delar av koden. Implementering och enhetstest: Implementering och test av samtliga delar av systemet. Detta utförs enligt design. Integrering: Denna del färdigställer systemet, detta resulterar i ett körbart program. Systemtest: Systemet testas i sin helhet. Detta sker i en testmiljö som är så lik som möjligt den riktiga miljön. 5.2 Leveranser Projektplan: Detta dokumentet, här står vad som ska göras och när. Huvudansvarig: Johan Anderholm. Kravspecifikation: Ett dokument där alla kraven på produkten är ställda. Huvudansvarig: Stefan Johansson. Designdokument: Här framställs designen på de olika klasserna i systemet. Huvudansvarig: Angelica Gabasio. Källkod: Den slutgiltliga implementeringen av systemet. Testplan: Instruktioner om hur man testar systemet. Huvudansvarig Simon Ekvy. 5.3 Milstolpar Milstople 1: Specifikation Milstople 2: Design Milstople 3: Implementation och enhetstest Milstople 4: Systemtest 5.4 Schema och beräknat arbete Tiderna för samtliga aktiviteter har blivit uppskattade till följande tabell (tiderna är angivna i arbetsdagar per person): Uppgift Tid (arbetsdagar) Projektplanering 5 Kravspecifikation 10 Testplanering 5 Design 10 Implementering och enhetstest 10 Integrering 5 Systemtest 5 4

Systemtest: Systemet testas i sin helhet. Detta sker i en testmiljö som är så lik som möjligt den riktiga miljön. 5.2 Leveranser Projektplan: Detta dokumentet, här står vad som ska göras och när.

Följande uppföljningspunkter är planerade: Uppgift Start Avklarad Projektplan 18 mars 2009 25 mars 2009 Milstolpe 1-25 mars 2009 Kravspecifikation 25 mars 2009 1 april 2009 Testplan 1 april 2009 6

6 Följande uppföljningspunkter är planerade: Uppgift Start Avklarad Projektplan 18 mars mars 2009 Milstolpe 1-25 mars 2009 Kravspecifikation 25 mars april 2009 Testplan 1 april maj 2009 Designdokument 1 april maj 2009 Milstolpe 2-6 maj 2009 Implementering och enhetstest 6 maj maj 2009 Integrering 8 maj maj 2009 Milstolpe 3-15 maj 2009 Systemtest 15 maj maj 2009 Milstolpe 4-22 maj Rapportering, uppföljning och kvalitetsförsäkring För att alla alltid ska ha tillgång till den senaste versionen av källkoden så använder vi oss av google code och subversion används som versionshanteringssystem. Det finns en Wiki att tillgå, för information som inte direkt ingår i projektet. Latex källfiler hanteras på samma sätt som källkoden. På projektets googlesida finns möjlighet att buggrapportera, detta kommer att användas för både källkod och dokumentfiler. I första hand är det dokumentansvarige som ska rätta till felet. Man kan också se vem som har ändrat vad och vid vilken tidpunkt ändringen har skett. Det går även att gå tillbaka till äldre versioner. Färdiga dokument laddas upp i pdf-format under Downloads. Varje onsdag har vi ett planerat veckomöte. Syftet med mötet är att gå igenom vad som har gjorts under föregående vecka och planera inför kommande vecka utifrån tidsplanen. Projektledaren är ordförande under dessa möten och håller i dagordningen. Färdiga dokument godkänns även under mötet. Då projektet är litet är det inga problem att kommunicera med och telefon. Dessutom träffas projektmedelmmarna dagligen. Samtliga dokument ska kontrolläsas av alla projektdeltagare och godkännas, det slutliga godkännandets utförs av den som har ansvaret för dokumentet. 5

2009 22 maj 2009 Milstolpe 4-22 maj 2009 6 Rapportering, uppföljning och kvalitetsförsäkring För att alla alltid ska ha tillgång till den senaste versionen av källkoden så använder vi oss av google

7 Det kommer ske en inspektion av projekthandledaren vid varje inlämning som finns ovan i kapitel Riskanalys Hårdvarufel: Hårdvaran följer inte specifikationen. Effekt: Hög Åtgärd: Kommunikation med kund, vid förändringar krävs omplanering. Riskindikator: Systemtesten med hårdvaran blir felaktikga, vid den virtuella testning gick alla test igenom. Dokumentändringar: Filer försvinner eller blir överskrivna av misstag. Effekt: Medel Åtgärd: Versionshanteringsprogram används vilket minimerar risken. Återgång till tidigare versioner är möjlig. Riskindikator: Dokumentens versionens nummer stämmer inte. Frånvaro av personal: Sjukdom och avhopp. Effekt: Medel Åtgärd: Omplanering av arbetsuppgifter. Riskindikator: Folk är inte närvarande som planerat. Ändringar av kravspecifikation: Beställaren tillför nya krav på produkten. Effekt: Medel - hög beror på hur omfattande ändringen är. Åtgärd: Ett extramöte sätts in där omplanering av projektet sker. Riskindikator: Beställaren kontakar oss med nya krav. Tidsbrist: Alla projektmedlemmar har andra studier vilka kan komma att ta mer tid. Effekt: Väldigt hög Åtgärd: Detta bör inte hända. Projektmedlemmarna har mycket fritid. Riskindikator: Folk är inte närvarande som planerat. Bristande kravspecifikation: Alla krav har inte identifierats. Risk: Medel Effekt: Låg - hög beroende på hur långt projektet kommit. Åtgärd: Extra noga planering av kravspecifikation. Omplanering om något nytt upptäcks. Riskindikator: Beställaren godkänner inte kravspecifikationen, eller programmet saknar funktioner vid test. 6

Dokumentändringar: Filer försvinner eller blir överskrivna av misstag. Effekt: Medel Åtgärd: Versionshanteringsprogram används vilket minimerar risken. Återgång till tidigare versioner är möjlig.

Relevanta dokument

Testplan Cykelgarage

Testplan Cykelgarage Stefan Johansson D08 (dt08sj7@student.lth.se) Johan Anderholm D08 (dt08ja5@student.lth.se) Angelica Gabasio D08 (dt08ag8@student.lth.se) Marcus Carlberg D08 (dt08mc4@student.lth.se)