SPECIFIKATION 1(11) Projektplan Distribution Detta dokument är ej under kontrollerad distribution. Innehavaren ansvarar själv för att den senaste utgåvan av detta dokument används och att inaktuella kopior (utskrifter) förstörs. Senaste version kan hämtas från Internet i PDF 1 format Http://www.e.kth.se/~e92_sli/exjobb/projektplan/projektplan.pdf Revisionshistorik Revision Datum Kommentar P1.0.0 1999-09-30 Första preliminära utgåva. P1.0.1 1999-10-14 Uppdaterad enligt Enea Data standard. P1.0.2 1999-11-01 Allmän uppsnyggning. 1 Portable Document Format (PDF). Läses med t.ex. Acrobat Reader, som hämtas gratis från http://www.adobe.com
SPECIFIKATION 2(11) Innehållsförteckning 1 Inledning...3 1.1 Bakgrund...3 1.2 Mål...3 1.3 Krav...3 1.4 Referenser...3 2 Organisation...4 3 Projektmodell...4 3.1 Milstolpar...4 3.2 Grindhål...7 4 Riskanalys...7 5 Dokumenthantering...9 5.1 Utfärdare...9 5.2 Klassificering...10 5.3 Godkännare...10 5.4 Dokumentbeteckning...10 5.5 Utgåva...11 Bilagor 1. Kravspecifikation 2. Tidsplan
SPECIFIKATION 3(11) 1 Inledning 1.1 Bakgrund Tack vare Internets popularitet har protokollsviten TCP/IP, som är ryggraden i Internet, blivit trendigt och nästan alla maskinvaruplattformar stöder det. En annan tydlig trend är att allt mindre enheter kommunicerar med TCP/IP och kan kopplas till Internet. I förlängningen skulle då en DSP kopplas till Internet med hjälp av TCP/IP. Mer konkret idag är behovet för debugging, som idag kommunicerar med JTAG, som är en synkron seriell förbindelse. Sådana är dyra och ovanliga och begränsar överföringshastigheten till 20 kbps. Det är i många fall alldeles för lite och något bättre alternativ behövs. Helst ska DSP tillämpningen kunna debuggas från en vanlig PC. Nästan alla PC som säljs idag har en asynkron seriell port med överföringshastighet på 115 kbps. De är vanliga, billiga och ger betydlig högre överföringskapacitet än JTAG. Naturligtvis ska TCP/IP användas för kommunikationen, eftersom det är ett standardiserat protokoll som finns till så gott som alla operativsystem som kan köras på en PC och gör att tillämpningen kan kopplas upp mot Internet eller ett Intranet. 1.2 Mål Det finns flera mål med projektet och alla inblandade har egna mål. Enea vill antagligen ha en bra prototyp som de sedan kan vidareutveckla till en produkt. KTH vill kanske ha ett bra exjobb som är klart på avsatt tid och jag har flera egna mål med projektet: Att skriva en prototyp som uppfyller kravspecifikationen. Att slutföra projektet på avsatt tid. Att få exjobbet godkänt. Att lära mig mer om Enea Data och dess företagskultur. Att lära mig mer om TCP/IP, realtidssystem, digitala signalprocessorer (DSP) och OSE for DSPs 2. 1.3 Krav Se krav specifikation, bilaga 1. 1.4 Referenser Se litteraturstudie, som är ett separat dokument. 2 OSE for DSPs: Ett resurssnålt operativsystem för DSP:er. Se litteraturstudie artikel 5.
SPECIFIKATION 4(11) 2 Organisation Fredrik Orava Examinator KTH Teleinformatik Kista <fredrik@it.kth.se> +46-8-752 14 90 +46-70-548 54 02 Ulf Bilting Handledare KTH Teleinformatik Kista <ulf@it.kth.se> +46-8-752 14 37 Fredrik Markström Handledare Enea Data AB Realtidssystem Täby <frma@enea.se> +46-8-50 714 322 +46-70-9 714 322 Anders Ravnborg Chef Enea Data AB Realtidssystem Täby <anra@enea.se> +46-8-50 714 386 +46-70-9 714 386 Stefan Lindblad Exjobbare Enea Data AB Realtidssystem Täby <xstli@enea.se> +46-8-50 714 201 +46-70-9 714 201 KTH/IT Institutionen för Teleinformatik Electrum 204 SE-164 40 Kista +46-8-752 14 00 växel Enea Data AB Realtids System Nytorpsvägen 5B Box 232 SE-183 23 Täby +46-8-50 714 000 växel 3 Projektmodell Jag har delat upp projektmålet i 11 delmål, som beskrivs under rubriken milstolpar nedan. Varje delmål har ett väldefinierat slut, vilket brukar betyda att ett visst dokument ska vara färdigt eller viss källkod ska vara testad och klar. Vid ett tillfälle har jag lagt in ett beslut om projektets fortsättning. Det tillfället för beslut finns beskrivet under rubriken Grindhål nedan. Alla delmål och beslut är uppräknade i någorlunda tidsordning, men för mer exakt tidsföljd se tidsplanen (bilaga 2). 3.1 Milstolpar En milstolpe är ett mätbart delmål i ett projekt. Att delmålet är mätbart betyder att det går att definiera när delmålet är uppnått. Varje milstolpe börjar med en kursiv sammanfattning och sedan definitionerna för när milstolpen börjar och slutar.
SPECIFIKATION 5(11) 1 Projektstart Jag har fått ett jobb, som också är antaget som exjobb. Start När jag påbörjar mitt jobba på Enea. När projektet är antaget som exjobb av min examinator. 2 Projektplan I projektplanen beskriver jag hur exjobbet är upplagt med delmål och tidsplan. Start När projektet är antaget som exjobb. När projektplan och tidsplan är godkända av min examinator. 3 4 5 Litteraturstudie Jag söker efter relevant information och lär mig det som behövs för att lösa uppgiften. Den litteratur som jag använder för exjobbet dokumenteras i en källförteckning för litteraturstudien. Start När jag börjar jobba på Enea. När källförteckningen till litteraturstudien är godkänd av min examinator. Specifikation av Protokoll Jag beskriver vilka protokoll som ska ingå i exjobbet och varför. Eventuella avsteg från protokollstandarden förklaras och effekterna beskrivs. Start Vartefter protokollen är studerade i litteraturstudien. När dokumentet Specifikation av Protokoll är färdigskrivet. Utveckling Källkod och dokumentation skrivs inkrementellt i en trestegs cirkulär loop med stegen specifikation, implementation och test. Start Efter att Specifikation av Protokoll är klar. När all källkod och dokumentet Specifikation av Implementation är färdigskrivet. 6 Integration och Test
SPECIFIKATION 6(11) Prototypen är skriven och ska nu flyttas till en maskinvaruplattform där kompatibilitet och prestanda ska testas. Dessutom ska beteendet vid nätverksfel och datorstopp dokumenteras. Som prov på kompatibilitet ska protokollsviten kunna kommunicera med WindowsNT och Linux. Prestandatester av den typ som ingår i Inet för OSE-delta ska genomföras för att få så pass jämförbara värden som möjligt. Start När Utvecklingen är klar. Prototypen ska uppfylla alla kraven i kravspecifikationen. 7 Preliminär Exjobbsrapport Under hela projektets gång har exjobbsrapporten på av de dokument och källkod som ingår i exjobbet. En preliminär sammanställning av alla dokument ska skickas till examinator, båda handledare och opposition. Senast 3 veckor före presentationen. Start När projektet är antaget som ett exjobb. Preliminära exjobbsrapporten är skickad. 8 9 Opposition Under projektets gång ska ett annat exjobb väljas för opposition. Inom en vecka från att jag fått den preliminära rapporten ska ett skriftligt oppositionsprotokoll lämnas till examinatorn för det andra exjobbet. Senast fem dagar innan dennes presentation ska jag ha fått den slutliga versionen och ska då förbereda cirka 10 minuter muntliga frågor till presentationen. Start Ett exjobb att opponera på har valts. Opposition genomförd och godkänd av andra examinatorn. Exjobbsrapport Senast fem dagar innan min presentation ska den slutliga exjobbsrapporten vara klar. Den ska ha uppdaterats och korrigerats efter den återkoppling jag fått från handledare, examinator och opposition. Start Preliminära exjobbsrapporten är skickad. liga exjobbsrapporten är skickad. 10 Exjobbspresentation
SPECIFIKATION 7(11) En presentation av exjobbet ska hållas där det färdiga projektet redovisas och opponeras på. Dessutom krävs närvaro och påskrift vid två andra exjobbspresentationer. Start När projektet är antaget som ett exjobb. När presentationen är godkänd och två påskrifter för närvaro erhållits. 11 Avslutning Efter att protokollsviten klarat kravspecifikatioen är det dags att börja städa upp efter sig och lämna tillbaka de resurser som jag har utnyttjat. Så fort exjobbsrapporten är klar ska den skickas till alla inblandade och till dem som är intresserade. Start När Test och Korrigeringar är klar. Alla resurser återlämnade, alla inblandade avtackade och rent och snyggt på min tillfälliga arbetsplats. 3.2 Grindhål Ett grindhål är ett tillfälle i projektet då ett beslut måste tas som påverkar projektets fortsättning. Det kan innebära att delmål försvinner eller ändras eller till och med tillkommer. I det här projektet finns det ett grindhål: 1 TCP Eftersom det är stora krav på minnessnålhet och TCP är det protokoll som kräver störst resurser, så implementeras TCP till sist. När alla andra delar är klara så mäts minnesbehovet och om det anses för stort så kan TCP strykas från kraven och inte implementeras. Inträffar Under milstolpe 5 Utveckling. 4 Riskanalys Projektet är ett exjobb och alltså inte affärskritiskt på något sätt, men det finns i alla fall risk för att projektet kan bli försenat. Här kommer jag att rada upp några risker och förklara vad som menas med dem, samt vad som kan göras åt dem både före de inträffar och efter att de har inträffat. Missar i specifikationen En ogenomtänkt eller dåligt skriven specifikation kan innebära att delar av specifikationen måste ändras eller skrivas om. Koden bygger på specifikationen och måste därför också ändras eller skrivas om.
SPECIFIKATION 8(11) Före Efter Se till att förstå protokollet och miljön innan specifikationen skrivs. Låt andra läsa och ge återkoppling på specifikationen. Prata om alla oklarheter med någon som kan tänkas veta mer om problemet. Justera tidsplanen så snarast som missen upptäckts och informera alla som berörs av förseningen. Buggar i implementationen Koden kommer att innehålla buggar, men om specifikationen är bra skriven bör det vara få. Även om buggarna är få så kan de ta lång tid att hitta och åtgärda. En bugg kan betyda att delar av koden måste skrivas om. Före Diskutera alla oklarheter på ett tidigt skede. Låt andra läsa och kommentera specifikationen. Se till att förstå protokollen innan specifikationen skrivs. Efter Justera tidsplanen om för många buggar upptäcks och informera alla som berörs av förseningen. Maskinvara saknas Det kanske inte finns någon maskinvara tillgänglig att prova koden på när det är dags för milstolpe 7 (Integration och test). Det kanske är svårt att hitta maskinvara som uppfyller kraven. Före Se till att i god tid innan göra handledare och chef observanta på att maskinvara ännu inte finns tillgänglig. Diskutera om det finns alternativa källor från vilka maskinvara kan fås, så att det inte saknas om det inte går som väntat. Efter Skjut upp maskinvaruporteringen och försök istället att bygga någon koppling från den emulerade miljön. Fortsätt att test tillförlitlighet och beteendet vid fel. Undersök alternativa källor för tillfälligt låna maskinvara, kanske bara vissa tider eller dagar. Snålt tilltagen tidsplan En dålig tidsplan kan vara omöjlig att hålla. Det är ofta svårt att uppskatta tidsåtgången för olika moment och då speciellt för utveckling.
SPECIFIKATION 9(11) Före Efter Gå igenom tidsplanen med någon som har mer erfarenhet av att skapa tidsplaner. Diskutera oklarheter med någon som kanske vet bättre. Lägg alltid till lite extra tid för saker tar ofta lite mer tid än man tror. Revidera tidsplanen så snart det upptäcks att den inte går att hålla. Se om det finns delar av projektet som kanske inte är så viktiga och vänta med de delarna för att göra dem i mån av tid. Ingen opponent Det kanske inte kommer att finnas någon som är villig att oppponera på mitt exjobb. Till exempel kanske det känns svårt att sätta sig in i exjobbet eller så kanske det inte passar tidsmässigt. Före Se till att information om mitt exjobb finns tillgängligt i god tid och att det är lätt att hitta. Det måste vara lätt att förstå vad exjobbet handlar om för annars kan opponenter bli avskräckta. Efter Avsluta alla andra milstolpar som inte är beroende av opponent. Se till att förbättra informationen om mitt exjobb. Inget exjobb att opponera på Det är möjligt att det inte finns något exjobb att opponera på när jag vill opponera. Om det finns några så kanske de inte passar mig så bra i tid eller kunskap. Före Se till att i god tid hitta ett exjobb att opponera på. Om det ser mörkt ut försök att hitta exjobb att opponera på hos någon annan examinator. Efter Kontrollera ofta om något nytt exjobb för opposition finns, även hos andra examinatorer på andra institutioner. 5 Dokumenthantering 5.1 Utfärdare Vem det är som skriver (ger ut) dokumentet.
SPECIFIKATION 10(11) 5.2 Klassificering Ett exjobb är alltid öppet och allmänt tillgängligt, därav klassificeringen Öppet. 5.3 Godkännes Om dokumentet behöver godkännas av något annan än utfärdaren, så måste namn och tillhörighet specificeras. Utan att dokumentet har blivit godkänt kan utgåvan inte ändras från P till R, se Utgåva. 5.4 Dokumentbeteckning Varje producerat dokument får en dokumentbeteckning som unikt identifierar dokumentet och samtidigt berättar vad dokumentet handlar om. Formatet på beteckningarna är som följer: bilaga/dokumenttyp/projektbeteckning-löpnummer 5.4.1 Bilaga Bara om dokumentet är en bilaga används bilagsprefixet, som är ett löpnummer för antalet bilagor. 5.4.2 Dokumenttyp I projektet används ett begränsat antal dokumenttyper och de förkortas enligt följande: fört FÖRTECKNING info INFORMATION käll KÄLLKOD prot PROTOKOLL rapp RAPPORT spec SPECIFIKATION 5.4.3 Projektbeteckning Projektbeteckningen är ip4dsp. 5.4.4 Löpnummer Numret ökas med ett för varje nytt dokument som skrivs och börjar på ett. 001 Projektplan 002 Litteraturstudie 003 Specifikation av Protokoll
SPECIFIKATION 11(11) 004 Specifikation av Implementation Osv. 5.5 Utgåva Utgåva skrivs på formatet Px.y.z eller Rx.y, där: P eller R betecknar preliminära respektive godkända dokument. x.y är revisionsläge. z är preliminärt löpnummer.