Labbredovisningar, 2D1385 programutvecklings teknik

Labredovisning

På labredovisningen är scenariet detta att ni i labgruppen är konsulter
och labassistenten er gruppchef på konsultfirman. Ni arbetar åt en kund
och ska redovisa veckans arbete. Ni arbetar enligt en plan där det är 
leverans (labredovisning) varje vecka, och som i XP och liknande modeller
levererar man ALLTID (inga krachade deadlines). Ni presenterar ert arbete,
assistenten lyssnar. Ni måste alltså planera hur ni vill använda 4 min
för att få godkänt. Som hjälp finns en checklista, och det är denna som 
assitenten följer, men ni fyller punkterna med meningsfullt innehåll. 
Som ni ser av listan är själva programmeringen bara en del av arbetet.
Skriv ner vad ni vill säga på papper så att det går snabbt att redovisa.


Checklista för redovisning:
1

*Vilken arbetsmodell/managementmodell har använts? Några lärdomar?
*Visa ditt UML-diagram av labben.
*Visa med en körning att funktionsspecen och designspecen
(labinstruktionen) uppfylls.

2
*På vilket sätt uppfylls robusthet, anpassningsbarhet och återanvändbarhet?
*Hur har du utfört/uppnått abstraktion, inkapsling och modularitet?
*Vilka designmönster har du använt?

3
*Vilka klasser från tidigare labbar har du återanvänt (någon refactoring)?
*Vilka nya klasser har du gjort, varför var du tvungen till detta?
*Visa uppdaterade listan med alla dina klasser från labbarna.

4
*Hur har du funktionstestat ditt program?
*Hur har du dokumenterat ditt program (kommentarer, javadoc, mm)?
*Visa koden och peka på speciellt viktiga avsnitt.

*Så här i efterhand, nu när ni blivit klokare, vad hade ni gjort annorlunda
eller ändrat på ifall ni hade fortsatt projektet?

------------------------------------------------------------------------------

Exempel på redovisning:
1
*Vi har använt XP/Agile i labbandet. Det är bra att kravspecen
(labpeket) är målet så man vet vad som skall göras. Det känns
fortfarande jobbigt att focusera på testning, men vi vänjer oss nog.
*Titta på vårt UML-diagram. Så här tänkte vi oss att det skulle funka...
*Nu kör jag programmet, se hur bra det funkar (klick, klick, knapp knapp).

2
*Skulle man skicka in ett negativt tal i den här metoden kollar vi det
så det inte blir fel i programmet. Skulle man ändra i den här klassen
så påverkar det inte den där klassen eftersom...
*Eftersom vi har separata klasser för ... och ... så får vi mer
modularitet och klassen XX skulle kunna användas i andra sammanhang.
*Vi har använt Model-View-Controller och Observer i vår design.

3
*Vi har inte återanvänt några tidigare klasser.
*Vi var tvugna att göra N nya klasser eftersom ditt och datt inte
fanns i java API eller i tidigare klasser.
*Titta på listan med alla våra klasser.

4


*Vi har gjort en testklass som testar klassen XX och ffa metoderna YY
och ZZ för de är viktigast att testa därför att...
*Vi har skrivit lagom mycket kommentarer på bra ställen, titta här i emacs.
*Här är en av de centrala delarna av koden, den gör att... Här är den
andra viktiga delen som ...

*Hade vi vetat att man måste vara bra på ... hade vi läst mer i
boken/referenserna på nätet som finns på kurshemsidan innan vi
startade att labba.
Klar!


Upp till prutte05:s hemsida.