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
Projektarbete
163
Johan Eliasson
Projekt
Roller i ett industriellt projekt
• Ett projekt är en engångsföreteelse!
Beställare
– Dokumentation är mycket viktigt
Kund
Styrgrupp
• 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
Projektledare
M
M
Referensgrupp
TL
M
M
M = projektmedlem
TL= teamledare, eller
delprojektledare
M
Bilden hämtad från projektplanemallen
Roller
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
• 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.
• Projektmedlem
– kan vara ansvarig för att en aktivitet utförs
– kan också utses till dokumentansvarig,
kvalitetsansvarig, testansvarig, kundansvarig,
designansvarig,...
166
167
Organisation i vårt projekt
Beställare
Projektgrupp
M
• Specifikation av hur projektet ska
genomföras
• Dokumenterar till exempel
Referensgrupp
M
Projektplan
– Mål
– Resurser
– Tidplan
Beställare = kursansvarig
Referensgrupp= handledarna
M = medlem i projektgruppen
168
169
LIPS begrepp
Projektstyrningsmodell
• Milstolpar
• 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
– 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.
– Konfidentiell (konkurrensmedel!)
– Ericsson använder en modell som heter PROPS
– Saab använder en modell som heter PSM
• Vi kommer att använda LIPS
– Lätt Interaktiv ProjektStyrning
• Granskningar
– Varje dokument måste granskas innan de godkänns.
170
171
Huvudfaser i LIPS - Före
• I denna fas ges uppdraget och utförandet planeras.
• En projektplan skapas
• V-modell av projektmodellen
–
–
–
–
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, MS1 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
• MS2 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
Bilden hämtad från: http://www.liu.se/cul-resurser/lips/kartor/under.htm
Huvudfaser i LIPS - Under
• 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
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.
• Man kan behöva revidera projektplanen.
• Krav under kursen
– Utföra individuell tidsrapportering
– Redovisa pågående arbete och reviderad projektplan
(OU5).
• Milstolparna 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
177
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
• 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
Versionshantering
Jan Erik Moströ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
Johan Eliasson
2.While not finished
1.Edit
2.Update
3.Commit
Johan Eliasson
Dokumentera program
• Viktigt att dokumentera program!
• Ett program används sällan endast av den som
utvecklat den
Dokumentation
– 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
186
187
Javadoc
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
• 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
• Må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
•
•
•
•
•
•
•
•
•
@author
@version
@param
@return
@exception
@see
@since
@serial
@deprecated
Javadoc 2
(endast klasser och
(endast klasser och
(endast metoder och
(endast metoder)
(även @throws sedan
interface)
interface)
konstruktorer)
Javadoc 1.2)
(eller @serialField eller @serialData)
• API beskrivningen på nätet är uppbyggd
med hjälp av javadoc
• För mer info se: http://java.sun.com/j2se/
javadoc/
190
189
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
Innehållsförteckning
• 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
Å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.
• 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
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.
194
Systembeskrivning
195
Algoritmbeskrivning
• 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
• 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
Lösningens begränsningar
• 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
• 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
Källkod
Testkörningar
• Ordbehandlare har en tendens att misshandla källkod
ganska rejält vad gäller indentering, stavning etc.
• 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
– 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
Övrigt
• 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
• Mer info se:
http://java.sun.com/docs/codeconv/
202
• 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.
203
