P-uppgift

Programmeringsteknik

Hoppa till: navigering, sök
       Information          Kodskelett          Prototyp          Granskning          Redovisning          Exempel      

Innehåll:

  • P-uppgift
  • P-uppgiftens delmoment
  • Betyg
  • Krav på P-uppgiftslösningen
  • Fiktiv P-uppgift: Bibliotek

Kursens sista moment är en större, personlig programmeringsuppgift i Python; en P-uppgift. Uppgifterna är tänkta att vara något så när svåra och tidskrävande, räkna med 40-80 timmar. Betyget i kursen ges av detta moment.

P-uppgiften redovisas i fyra steg: kodskelett, prototyp, granskning och redovisning. Slutredovisningen görs på KTH eller via Skype och du kan boka en tid när du är klar med de tre första momenten.

Uppgiftslydelsen till din P-uppgift hämtar du från studentportalen. I den nya plattformen (från 15 dec 2017) finns uppgiftlydelserna under "P-uppgift: Uppgiftsbeskrivning och kodskelett".

P-uppgiftens delmoment

Kodskelett

Innan programmet skrivs ska en specifikation i form av ett kodskelett lämnas in. Syftet är att du ska tänka igenom problemet innan du försöker lösa det.

Kodskelettet ska innehålla följande delar:

  • En inledande kommentar som kortfattat beskriver vad programmet gör och hur det är implementerat.
  • Funktioner (utan kod) med kommentarer.
  • Klasser med attribut och metoder, men utan kod.
  • Man måste ha en (bra) klass, alla uppgifter sen 2015-06 har åtminstone en lämplig klass.

Prototyp

När ditt kodskelett har blivit godkänt så är det dags att börja arbeta med en prototyp av programmet. En prototyp är en första körbar version av programmet som innehåller den mest grundläggande funktionaliteten. Syftet med att lämna in en prototyp är att vi ska kunna ge tips och råd om förbättringar och ändringar redan innan programmet är helt klart.

Granskning

Innan det färdiga programmet kan redovisas för en handledare på KTH ska det testas (granskas) av en kurskamrat. Vid testen ska din granskare kritiskt granska ditt program, testköra det och fylla i ett granskningsprotokoll. Syftet med granskningen är att du genom att kritiskt granska en annans program ska få en ökad förståelse för hur man ska (och inte ska) programmera.

Slutredovisning

När du är klar med de tre första momenten så är det dags att välja en tid för slutredovisning. Observera att vi (för att förhindra fusk) jämför din lösning mot en databas som innehåller alla tidigare inlämningar som gjorts på kursen.

Betyg

Betyget på kursen bestäms i samband med slutredovisningen. Det finns sex betygssteg, A-F, där A är det högsta betyget. A-E är alla godkända betyg och F är underkänt.

P-uppgifterna är uppdelade i en grunduppgift och tre extrauppgifter som du kan göra för att få högre betyg. Extrauppgiften för C går att lösa med hjälp av de delar av Python som vi gått igenom hittills i kursen. Extrauppgiften för B kan kräva att du läser på mer om nya moduler i Pythondokumentationen (länk finns under "Länklista") och/eller att du utvecklar en lite klurigare algoritm.

I extrauppgiften för betyg A ska du göra ett grafiskt användargränssnitt med hjälp av tkinter till ditt program och det ingår i uppgiften att lära sig detta på egen hand. En samling bra länkar finns under rubriken GUI-länkar under "Länklista".

Man får betyg

  • F om man har fler än 3 påpekanden eller inte uppfyller samtliga nödvändiga punkter i granskningsprotokollet.
  • E om man har 1-3 påpekanden och uppfyller samtliga nödvändiga punkter i granskningsprotokollet.
  • D om man har ett perfekt program (ett program utan påpekanden).
  • C om man har uppfyllt villkoren för betyg D och dessutom har gjort extrauppgift C.
  • B om man har uppfyllt villkoren för betyg C och dessutom har gjort extrauppgift B.
  • A om man har uppfyllt villkoren för betyg B och dessutom har gjort extrauppgift A.

Krav på P-uppgiftslösningen

Utöver kraven på funktionalitet som finns i uppgiftslydelsen gäller detta alltid:

  • Programmet ska vara kommenterat upptill med författare, datum och ev revisionsdatum. Överkommentera inte programmet i övrigt. Tänk på att det är kvalitet och inte kvantitet på kommentarer som räknas.
  • Programmet ska vara användarvänligt och presentera sig vid programstart. Tydliga instruktioner ska ges på skärmen. Det ska vara lätt att förstå vad programmet skriver ut. Det är tillåtet att anta att indatafiler är felfria om inte annat anges i uppgiftslydelsen.
  • Programmet ska vara vettigt uppdelat i funktioner och klasser. Funktioner ska inte vara alltför långa, exakt längd beror på vad funktionen gör men kortare är nästan alltid bättre (MAX 50 rader, 5-15 brukar vara en bra längd). Det ska vara lätt att i efterhand gå in och förstå och ändra i programmet. Robust, flexibelt och lättläst är nyckelord.
  • Varje variabel och funktion ska vara försedd med kommentarer. Ange vad variabeln representerar och vad funktionen gör. För funktioner bör man också ange vad indata (parametrar) och utdata (retur-värde) betyder. Det ska räcka att läsa kommentar och funktionshuvud för att förstå hur en funktion ska användas.
  • Namn på variabler och funktioner ska vara vettiga. Alla deklarerade namn ska vara på samma språk, liksom alla kommentarer (engelska namn och svenska kommentarer är OK). Koden skall vara snyggt formaterad.
  • Nästan identiska kodstycken ska inte upprepas. Gör i stället generella funktioner. Inför inte i onödan begränsningar. Inför konstanter för sådant som man kan tänkas vilja ändra framöver (om man skulle vilja arbeta vidare med din lösning) och för tal som inte ska ändras och går att beskriva med namn.


Fiktiv P-uppgift

I de sista avsnitten av kursen kommer vi att gå igenom ett exempel som visar hur en P-uppgiften kan se ut och hur de olika inlämningsmomenten är tänkta att fungera. Den fiktiva uppgiften går ut på att göra ett program för hantering av enklare biblioteksrutiner. Uppgiftslydelsen finner du här: Bibliotek