Dokumentation och presentation av ert arbete Daniel Axehill Reglerteknik Linköpings universitet
Dagens föreläsning Första timmen Kursens mål. Projektmodellen LIPS och dess användning i kursen. Olika former av redovisning av ert arbete. Allmänna tips och kommentarer. Andra timmen Jan Palmqvist, f.d. projektledare för Gripenprojektet på SAAB talar om att arbeta i projekt.
Kursens mål 1. Lära sig jobba i projekt Projektroller. Grundläggande insikt i en projektmodell: LIPS. Samarbeta i en grupp. 2. Tillämpa sina ämneskunskaper Hur kan ni utnyttja teorin ni har lärt er i praktiken? Att lösa problem i praktiken kräver ofta viss improvisation 3. Ha kul!
Organisation av projekten (repetition) Kund Beställare Examinator Studenter Lärare Extern personal Projektledare Projektmedlemmar Handledare Expert Expert Expert Expert
Projektroller Obligatoriska roller Projektledare: leder projektet och gruppen, ansvarar för att målet nås. Dokumentansvarig: ansv. för att dokumenten finns och blir klara i tid samt är versionshanterade. Testansvarig: planerar tester, ansv. för testplan och testprotokoll, mm. Designansvarig: lägger upp riktlinjer för design, sammankallar komponentansvariga. Mjukvaruansvarig: ansv. för att koden följer anvisad kodstandard, är välstrukturerad, versionshanterad och dokumenterad/kommenterad.
Projektroller, forts. Frivilliga roller Komponentansvarig: ansv. för vissa komponenters design (motorstyrning, SLAM, etc.). Leveransansvarig: ansvarar för leveransen; vad och hur? Informationsansvarig: ansv. för hemsida, film, presentation, mm. Information om projektroller finns på kurshemsidan och i boken Projektmodellen LIPS.
Projektfaser Planering Utförande Avslut Faser: BP: Prel. 17 dec BP2: Efter 3 veckor Leverans ca 3 dec Detaljnivå Ca 10 veckor
Beslutspunkter Beställaren fattar beslut om projektets fortsättning baserat på underlag från projektledare/projektgrupp. Enligt LIPS-modellen. BP2 Här tas beslut om att starta utförandefasen av projektet. Underlag: Kravspecifikation, projektplan inklusive tidsplan och utkast av designspecifikation.
Beslutspunkter, forts. BP3 BP5 Här tas beslut om detaljerad design och hur kraven ska testas. Underlag: Designspecifikation och testplan. Här fattas beslut om att projektet är redo för leverans. BP5 hålls således strax innan leverans. Underlag: All funktionalitet, testprotokoll, användarhandledning och föredrag där det visas att de viktigaste delarna av kravspecifikationen är uppfyllda.
Beslutspunkter, forts. BP6 (precis innan projektkonferensen) Här fattas beslut om att avsluta projektet. Här levereras: teknisk rapport, efterstudie med uppföljning av resultat och använd tid, poster, hemsida och demofilm.
LIPS Agil eller inte? SCRUM är ett exempel på en agil metod. Agil = lättrörlig: kan enkelt följa ändrade förutsättningar (mm.). Det finns klara agila inslag i vår implementation av LIPS, men dessa kan förstärkas genom att t.ex. Delleveranser som grund för vägval i projektet. Att alltid ha en leverabel produkt (som förbättras iterativt). Omförhandlingar av kravspecifikation. Utelämna självklara detaljer i projektplanen och låt den vara dynamisk under projektets gång. Köra t.ex. SCRUM i inre loopen (dock utan kursstöd).
LIPS Agil eller inte?, forts. Men Det finns poänger med att planera ordentligt från början och att dokumentera detta noga. Det är lätt att göra kostsamma misstag om en design inte är noga genomtänkt innan implementationen börjar. Man måste designa för hela produktlivscykeln, och den slutar inte förrän skrotning. Speciellt när hårdvara och arkitekturer med längre ledtider ingår i designen är det svårt att vara agil i de delarna.
Verktyg för projekthantering LIPS-hemsidan (länk från kurshemsidan) har Wordoch Excel-mallar för projektplanering och uppföljning. Även LaTeX kan användas av de som önskar, dock inte samma utbud av färdiga mallar. Se hemsidan.
Granskning av rapporter Alla rapporter/dokument godkänns av beställaren. Tekniska rapporter itereras med handledare innan de skickas till beställaren: enkel testplan. designspecifikation (inkl. utkastet till BP2). testprotokoll. användarhandledning. teknisk rapport.
Teknisk rapport Varför? Utförlig dokumentation av arbetet. Beskrivning av uppgifter och specifikationer. Vilka mål nåddes, vilka inte, varför. Misslyckade ansatser samt förklaring till varför de inte fungerade. Metoder som har använts för att lösa uppgiften. Resultat.
Teknisk rapport, forts. Se gärna tidigare års rapporter! Skrivs i Word/OpenOffice eller LaTeX.
Poster Varför? Ett vanligt sätt att presentera ett arbete på (t.ex. på konferenser). Ett bra sätt att förklara något på kort tid. Mer personligt än vanlig muntlig presentation.
Poster, forts. Att tänka på vid design Inte för mycket text. Ska gå att förstå i stora drag utan att någon står vid den men, i princip ska det krävas någon som presenterar. Ska locka folk, uppmuntra till frågor. Ska vara lätt att förstå. En bild säger ofta mer än många ekvationer.
Poster, forts. Se Reglertekniks korridor! Görs i valfritt program. LaTeX ett alternativ.
Tryck av poster Format: A1. Beställning sker genom Beställaren som vill ha postern i PDF-format i god tid (ca en vecka innan BP6). Skrivs ut av beställaren på LiU-Tryck, betalas av Reglerteknik. Tekniska detaljer: Handledare.
Webbsida Varför? Ett bra sätt att presentera sitt företag och sina produkter med inriktning mot olika målgrupper. Interaktiv. Olika typer av medier kan användas. Lätt att underhålla, kan finnas tillgänglig under lång tid. Mycket stor spridning.
Webbsida, forts. Läggs upp på ISY:s webbplats, se instruktioner från Beställaren. Görs i valfritt program, måste dock fungera på ISY:s server. Bra om den uppdateras löpande under projektet.
Demofilm Varför? Modernt sätt att förmedla sitt budskap. Kan få liknande effekt som en posterpresentation, men det behövs ingen presentatör. Möjliggör en häftig och säljande presentation. Får mycket bra potentiell spridning om den publiceras på Youtube.
Demofilm, forts. Använd kamera från någon projektmedlem. Editera med t.ex. Windows Live Movie Maker, imovie,... Ska godkännas av beställaren innan den publiceras på Youtube. Respektera copyright på ev. musik etc.
Muntlig presentation Varför? Möjliggör en ganska detaljerad presentation på ett för åhörarna smidigt sätt. Frågor kan besvaras direkt. Når oftast fler samtidiga åhörare än en posterpresentation.
Muntlig presentation, forts. I den här kursen Ges vid leveransen (och ev. vid BP5). Saklig och korrekt, men ändå säljande presentation. Kort beskriva systemet, dess prestanda (speciellt kravställd prestanda), samt de viktigaste tekniska lösningarna ni har använt för att uppnå kraven. Tala inte om lösningar som inte har fungerat. Endast några få personer bör tala, blir annars rörigt.
Målgrupper Teknisk rapport Vänder sig ofta till personer som redan är intresserade. Typiskt, de som vill lösa liknande tekniska problem. Poster Vänder sig till de som vill köpa en produkt eller lösa ett liknande tekniskt problem. Webbsida Vänder sig till de som vill investera i ett företag, vill köpa en produkt eller vill lösa ett liknande problem.
Målgrupper, forts. Demofilm Som för webbsida. Kan göras mycket lockande. Mycket av det ni ska göra är häftigt! Presentation Vänder sig ofta till människor som redan är intresserade (de har ju kommit). Sammanfattar ofta en rapport.
Efterstudie Mycket viktigt dokument! Analysera hur projektarbetet fungerade Arbetssätt. Samarbete. Arbetsfördelning. Hur fungerade beställare/kund? Önskemål om någon förändring till kommande år?
Kodstandard och dokumentation av kod All ny (C++, Python och Java) kod ska följa Googles kodstandard. Se nätet! All ny kod ska kommenteras och dokumenteras med t.ex. Doxygen. Det kommer med stor säkerhet finnas både mjukoch hårdvaruproblem då ni är klara. Dokumentera dessa för kommande grupper! Lämna koden som ni själva skulle velat ha fått den!
Versionshanteringsverktyg: Git I kursen använder vi Git (GitLab). Dokumentation och länk till inloggning finns på: http://www.ida.liu.se/gitlab/ Beställaren ger er rättigheter till respektive grupps repository. Ev. kan det krävas att ni loggar in och ut från GitLab en gång (om ni inte använt det innan) innan rättigheterna kan sättas.
Några viktiga lärdomar från tidigare år Hårdvara är ofta orsak till ev. problem, verifiera funktionalitet snarast. Lita inte på att den fungerar! Provkör systemet innan skrivandet av kravspecifikationen. Sätt er tidigt in i koden och läs igenom dokumentationen. Planera klasser och skriv deras header-filer tidigt! Det kan vara svårt att planera i detalj tidigt. Gör en lagom grov planering och förfina efter hand!
Några viktiga lärdomar från tidigare år, forts. Tänk kritiskt! Fungerar det verkligen, eller hade vi bara tur? Identifiera flaskhalsar/delade resurser och schemalägg smart.
Kursavslutning Projektkonferens Preliminärt kl. 13-16 den 17/12 med första timmen i Ada Lovelace och sedan fortsättning i arenan Visionen. Genomgång av efterstudie. Posterpresentationer för gruppen och externa gäster. Tårta. Obligatorisk närvaro! Lägg in preliminärt i er kalender redan nu!
Ansvar gentemot gruppen Diskutera inom gruppen för att formulera gemensamma mål. Kan du inte utföra din uppgift för att den är för stor, du har blivit sjuk, du är tvungen att göra en labb Säg till projektledaren direkt! Ha alltid gruppens bästa i åtanke!
Feedback Om ni är missnöjda, nöjda eller bara vill diskutera något angående kursen, prata med mig! Det är inte ovanligt med konflikter under ett projektarbete. Om det uppstår, diskutera gärna med handledare, beställare eller mig.