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 format
|
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. |
Innehållsförteckning
1 Inledning *
1.1 Bakgrund *
1.2 Mål *
1.3 Krav *
1.4 Referenser *
3 Projektmodell *
3.2 Grindhål *
5 Dokumenthantering *
5.2 Klassificering *
5.3 Godkännare *
5.4 Dokumentbeteckning *
5.5 Utgåva *
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.
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
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).
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.
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. | |
Slut | 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. | |
Slut | När projektplan och tidsplan är godkända av min examinator. | |
3 | 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. | |
Slut | När källförteckningen till litteraturstudien är godkänd av min examinator. | |
4 | 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. | |
Slut | När dokumentet Specifikation av Protokoll är färdigskrivet. | |
5 | 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. | |
Slut | När all källkod och dokumentet Specifikation av Implementation är färdigskrivet. | |
6 | Integration och Test | |
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. | |
Slut | 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. | |
Slut | Preliminära exjobbsrapporten är skickad. | |
8 | 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. | |
Slut | Opposition genomförd och godkänd av andra examinatorn. | |
9 | 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. | |
Slut | Slutliga exjobbsrapporten är skickad. | |
10 | Exjobbspresentation | |
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. | |
Slut | 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. | |
Slut | Alla resurser återlämnade, alla inblandade avtackade och rent och snyggt på min tillfälliga arbetsplats. | |
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. |
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. | |
Före | 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. |
Efter | 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. | |
Före | 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. |
Efter | 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. |
Vem det är som skriver (ger ut) dokumentet.
Ett exjobb är alltid öppet och allmänt tillgängligt, därav klassificeringen Öppet.
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.
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"
Bara om dokumentet är en bilaga används bilagsprefixet, som är ett löpnummer för antalet bilagor.
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 |
Projektbeteckningen är "ip4dsp".
001 | Projektplan |
002 | Litteraturstudie |
003 | Specifikation av Protokoll |
004 | Specifikation av Implementation |
Osv. |