Johan Eliasson Projektarbete Projekt Definition: En grupp av projektdeltagare utför under ledning av en projektledare en klart definierad uppgift, på en viss tid, med begränsade resurser Resurserna kan vara i form av människor, material, pengar, eller lokaler Projekt ska ha mätbara mål 163 Projekt Ett projekt är en engångsföreteelse! Dokumentation är mycket viktigt Fördelar med projekt Arbetsuppgifter kan utföras parallellt och därmed slutföras på kortare tid Skapar arrangemang genom att arbetet utförs i en eller flera grupper Projekt bemannas ofta med personer med kompletterande kunskaper 164 Roller i ett industriellt projekt Beställare Styrgrupp Projektledare TL Bilden hämtad från projektplanemallen Kund Referensgrupp = projektmedlem TL= teamledare, eller delprojektledare 165 Roller Beställare Kan vara en extern kund till ett företag eller en intern beställare (ex produktchef) Ansvarig för nyttan med projektet, om det är värt investeringen Projektledare Ansvarar för att projektets utförs och slutförs enligt givna direktiv Projektmedlem kan vara ansvarig för att en aktivitet utförs kan också utses till dokumentansvarig, kvalitetsansvarig, testansvarig, kundansvarig, 166 designansvarig,... Roller Styrgrupp Utses av beställaren för att styra och bevaka att projektet når målen. Referensgrupp Personer som stöttar projektledaren och projektmedlemmarna (utan beslutanderätt). Leverantör Person/företag utanför projektgruppen som kontrakteras för att utföra arbete/leverera utrustning. 167
Organisation i vårt projekt Projektplan Beställare Projektgrupp Referensgrupp Beställare = kursansvarig Referensgrupp= handledarna = medlem i projektgruppen Specifikation av hur projektet ska genomföras Dokumenterar till exempel ål Resurser Tidplan 168 169 LIPS begrepp Projektstyrningsmodell ilstolpar En signifikant mätbar händelse Etappmål Definieras oftast av projektgruppen själv Beslutspunkter Punkter där beställaren bestämmer om projektet får fortsätta in i nästa fas. Ofta resultat vid en milstolpe som ligger till grund för beslut. Aktiviteter De arbetsuppgifter som ska utföras under projektet och plan för tidsåtgången för var och en av dessa. Granskningar Varje dokument måste granskas innan de godkänns. Regler och hjälpmedel för att bedriva ett projektarbete Gemensamma definitioner och beskrivningar av flöden, aktiviteter, roller, dokument, etc Varje företag har oftast en egen projektmodell Konfidentiell (konkurrensmedel!) Ericsson använder en modell som heter PROPS Saab använder en modell som heter PS Vi kommer att använda LIPS Lätt Interaktiv ProjektStyrning 170 171 Huvudfaser i LIPS - Före V-modell av projektmodellen I denna fas ges uppdraget och utförandet planeras. En projektplan skapas Kravspecifikation definierar vad man ska göra Systemskiss visar hur man ska göra det Aktiviteter identifieras Resurser och tid planeras Viktig fas! Görs planeringen fel kan projektet inte bli lyckat. Tar tid men man går inte på djupet i detaljerna 172 173
bilden hämtad från: http://www.liu.se/cul-resurser/lips/kartor/fore.htm Före-fasen under kursen: Projektidé och förstudie har redan gjorts och BP0, S1 och BP1 har passerats. Dokumentet Projektdirektiv och Kravspecifikation finns på projektsidan. Ni får uppdraget (OU3) att förbereda projektet inför utförandefasen. Kraven studeras och man beskriver hur man ska göra i en systemskiss/funktionsspecifikation. Projektplan upprättas S2 består av projektplan och kravspecifikation BP2 är rättningen av er inlämnade projektplan endast U medför att projektet ej får fortsätta 174 175 Huvudfaser i LIPS - Under Bilden hämtad från: http://www.liu.se/cul-resurser/lips/kartor/under.htm Utför projektet och dess aktiviteter Detaljerade specifikationer skapas Aktiviteterna utförs, dokumenteras och resultatet testas. Kontinuerlig rapport till beställaren (mötesprotokoll och statusrapporter) Fasen avslutas med ett systemtest. Arbetet går i cykler Upptäcka att ett krav påverkar designen, måste göra ny design tex. 176 177 Under-fasen under kursen: Testplan där man funderar på vad som ska testas och hur är viktigt för att garantera fungerande slutresultat. Viktigt att lägga in många milstolpar och stämma av tidsplan och testplan för att se eventuella problem tidigt. an kan behöva revidera projektplanen. Krav under kursen Utföra individuell tidsrapportering Redovisa pågående arbete och reviderad projektplan (OU5). ilstolparna ni beslutar er för att ha ska synas i projektplanen Vi använder endast BP5 som är rättningen er uppdaterade projektplan, och genomgången av ert arbete med handledarna. 178 Huvudfaser i LIPS - Efter Projektresultatet överförs till beställaren och projektet avslutas. Utvärdering utförs. Ofta det svåraste i ett projekt... Att få det betalt och avslutat! 179
Bilden hämtad från: http://www.liu.se/cul-resurser/lips/kartor/efter.htm Efter-fasen under kursen: Här lämnar ni in slutversionen tillsammans med dokumentation av systemet och efterstudien direkt. Handledarna utför acceptanstestet utifrån kravspecifikationen och kan komma med en restlista... BP6 är med andra ord rättningen av det ni lämnat in i er slutrapport 180 181 Versionssystem Versionshantering Gjorda för att användas av en eller flera personer på en eller flera platser tex: För en ensam användare som jobbar med ett projekt från flera datorer För att veta att förändringar inte skrivs över av andra då man jobbar flera tillsammans Om man jobbar många tillsammans med samma filer för att veta att dokumenten är senaste versionen. För att gå tillbaka i tiden och se tidigare versioner av dokumenten Jan Erik oström Johan Eliasson Programvara Arbetsflöde git CVS SVN (Subversion) Senare programvara. Har försökt adressera några av problemen som fanns i CVS Eclipse i labben har plugin för att jobba med SVN. CVS stöd finns med som standard. På följande adress finns en guide hur man kan komma igång med SVN i eclipse: http://help.collab.net/index.jsp?topic=/org.tigris.subclipse.doc/ topics/toc.html Vill ni använda detta i projektet så maila support att ni vill använda det samt användarnamn på alla medlemmar i gruppen och kurskod (5dv109) 1.Check out or share 2.While not finished 1.Edit 2.Update 3.Commit Johan Eliasson Johan Eliasson
Dokumentera program Dokumentation 186 Viktigt att dokumentera program! Ett program används sällan endast av den som utvecklat den Användaren behöver få veta hur programmet fungerar Ett program underhålls inte alltid av den som skrivit det Den som ska underhålla programmet behöver info Ett program utvecklas ofta av många personer Den De andra i utvecklingstemet behöver info 187 Dokumentation Dokumentation i form av kommentarer behövs i koden Kommentarer räcker dock inte (rätt jobbigt att alltid behöva läsa källkod) Läsning på en del av problematiken att man vill ha två olika typer av dokumentation som till stor del innehåller samma info: Javadoc Javadoc Speciella kommentarer som kan användas för att generera dokumentation av koden man har skrivit Eclipse har möjlighet att generera denna dokumentation /** startar en javadoc kommentar åste skrivas innan en klass, attribut, konstruktor eller metod deklaration Första raden skall vara en kort förklaring av vad metoden gör Efter den första raden som börjar med @ så slutar den allmänna beskrivningen av metoden 188 189 Javadoc 2 @author (endast klasser och interface) @version (endast klasser och interface) @param (endast metoder och konstruktorer) @return (endast metoder) @exception (även @throws sedan Javadoc 1.2) @see @since @serial (eller @serialfield eller @serialdata) @deprecated API beskrivningen på nätet är uppbyggd med hjälp av javadoc För mer info se: http://java.sun.com/j2se/ javadoc/ 190 Vad kan behöva dokumenteras Exempel på punkter från vår rapportmall: Framsida Innehållsförteckning Åtkomst och användarhandledning Problembeskrivning Systembeskrivning Algoritmbeskrivning Lösningens begränsning Problem och reflektioner Testkörningar Källkod 191
Framsidan Framsidan på din labrapport kan du utforma ganska fritt. Tänk bara på att den ska vara läsbar, och innehålla (minst) följande information: Ditt namn Din e-mail adress här på CS! Kursens namn samt vilken termin det är (t.ex. vt08) Vilken laboration det är Handledarens/handledarnas namn Datum Vilken inlämning det är (första/andra/uppsamling etc.) Lämna plats för kommentarer 192 Innehållsförteckning Viktigt då man snabbt vill hitta till ett visst avsnitt (dokumentationen av ett program är sällan något man läser från start till slut) Innehållsförteckningen ska innehålla alla rubriker i rapporten, och eventuellt en del underrubriker, beroende på hur rörigt det blir. Tänk på att innehållsförteckningen inte bör vara listad i innehållsförteckningen... Använd gärna de funktioner som finns för att generera innehållsförteckning automatiskt i de olika ordbehandlingsprogrammen 193 Åtkomst & användarhandledning Kan ibland delas upp i två avdelningar Hur kan någon komma åt ditt program (inkl källkod). Vad heter de olika filerna som programmet är uppbyggt av. Viktigt för alla Hur används programmet. Viktigt för användare av programmet Hur ska man gå till väga för att kompilera din källkod. 194 Problemspecifikation Beskrivning av vad uppgiften går ut på. Ska kunna ge en bild av uppgiften utan att man ska behöva läsa hela orginalspecifikationen Beskriv problemet med egna ord. Sammanfatta problemet. Hänvisa till orginalspecifikationen. Gör specifikationen att vissa antaganden måste göras? Ta upp dessa i sådana fall Har du gjort några utökningar av uppgiften? Redovisa i sådana fall dessa. 195 Systembeskrivning Ska beskriva systemets interna uppbyggnad och struktur. Beskriv varje klass och syftet med denna och dess del av helheten.! För att beskriva klassen behöver man också beskriva tex de metoder som finns i den. Här kan det gå bra att använda sig av javadoc för att automatgenerera delar av beskrivningen (klistra inte in dessa i rapporten utan hänvisa istället till vart man kan hitta dessa). Beskriv relationer mellan klasser, med figurer och kommentarer till dessa. 196 Algoritmbeskrivning Om du har använt några icke självklara algoritmer, t.ex. en sorteringsalgoritm, en sökalgoritm eller något annat, ska du beskriva den/dem här. Lämpligt med en numrerad lista (i flera nivåer) Försök undvika att använda element som är direkt kopplade till koden, t ex variabelnamn och dylikt Syftet med detta avsnitt är att en läsare ska kunna få förståelse för hur en komplicerad del löses utan att behöva lusläsa kod och utifrån denna inse vad som händer 197
Algoritmbeskrivning Kort och koncist Entydigt Högnivåliknande syntax 1 Kontrollera att antalet personer är mindre än tio 1.1 Om antalet personer överstiger tio, avsluta med ett felmeddelande 2 För varje person: 2.1 Skriv ut personens namn med röd text 2.2 Skriv ut personens födelsenummer med blå text 2.3 Skriv ut personens adress med grön text 3 Vänta på att användaren trycker på tangenten N 4 Avsluta funktionen Lösningens begränsningar Beskriver alla begränsningar som du kan komma att tänka på, eller har stött på under testningen. Du bör tala om alla de begränsningar som strider mot specifikationen. Nästan alla lösningar innehåller någon begränsning, tänk till lite bara. Hur kan/kunde begränsningarna undvikas? 198 199 Testkörningar Du måste testa din lösning innan du lämnar in den. För att visa att du gjort det, och för att ge handledarna ett snabbt sätt att kontrollera att din lösning ser OK ut så bifogar man testkörningarna i rapporten. Tänk ut vettiga testfall. Vad kan tänkas vara svårt för programmet? Kommentera testfallen. Varför valde du detta testfall? Blev resultatet som det var meningen att det skulle bli? 200 Källkod Ordbehandlare har en tendens att misshandla källkod ganska rejält vad gäller indentering, stavning etc. Det finns vissa verktyg vars syfte enbart är att skriva ut källkod snyggt (t ex atp, a2ps och enscript) Ska vara utskriven med ett icke-proportionellt typsnitt, t.ex. Courier. Koden ska vara indenterad på ett konsekvent sätt Tänk på att koden ska se bra ut även på papper då ni skriver den. Koden ska vara kommenterad där det inte är klart vad du gjort. Varje metod föregås av kommentarer som beskriver dess syfte, in-/utdata o s v. 201 Källkod/Indentering Hur man formaterar sin kod Flytta alltid in all kod som står ett block 3-4 tecken Detsamma för enkel sats som hör till t.ex. if- whileoch for- satser Tänk på att inte skriva för långa rader Om du måste bryta upp ett uttryck/sats p.g.a. att raden skulle ha blivit för lång så flytta in resten av uttrycket minst till positionen för starten av uttrycket/satsen er info se: Övrigt Använd ett korrekt och formellt språk Sidhuvud och sidfot. Använd dessa, men ha inte för mycket information i dem. I sidhuvudet kan du t.ex. ha ditt namn, datum, kursens namn och vilken laboration det är. I sidfoten kan du ha sidnumret. Tänk på att förstasidan inte bör vara numrerad eller ha samma sidhuvud som resten av rapporten. Läs igenom det du skrivit innan du lämnar det ifrån dig. http://java.sun.com/docs/codeconv/ 202 203