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 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.

 

Innehållsförteckning

1 Inledning *

 

1.1 Bakgrund *

1.2 Mål *

1.3 Krav *

1.4 Referenser *

2 Organisation *

3 Projektmodell *

3.1 Milstolpar *

3.2 Grindhål *

4 Riskanalys *

5 Dokumenthantering *

5.1 Utfärdare *

5.2 Klassificering *

5.3 Godkännare *

5.4 Dokumentbeteckning *

5.5 Utgåva *

Bilagor
  1. Kravspecifikation
  2. Tidsplan
  1. Inledning
    1. Bakgrund

    2.  

       

      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.

    3. 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:
    1. Krav

    2.  

       

      Se krav specifikation, bilaga 1.

    3. Referenser
Se litteraturstudie, som är ett separat dokument.
  1. Organisation

  2.  

     

    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

  4.  

     

    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).

    1. Milstolpar

    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.
           

    3. 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.

     
  5. Riskanalys

  6.  

     

    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.
       

     

  7. Dokumenthantering
    1. Utfärdare

    2.  

       

      Vem det är som skriver (ger ut) dokumentet.

    3. Klassificering

    4.  

       

      Ett exjobb är alltid öppet och allmänt tillgängligt, därav klassificeringen Öppet.

    5. Godkännes

    6.  

       

      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.

    7. Dokumentbeteckning

    8.  

       

      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"

      1. Bilaga

      2.  

         

        Bara om dokumentet är en bilaga används bilagsprefixet, som är ett löpnummer för antalet bilagor.

      3. Dokumenttyp

      4.  

         

        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. Projektbeteckning

      6.  

         

        Projektbeteckningen är "ip4dsp".

      7. 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
      004 Specifikation av Implementation
      Osv.  
    9. Utgåva
Utgåva skrivs på formatet "Px.y.z" eller "Rx.y", där: