T-76.115%20Project%20Review

1
T-76.115 Project Review

• Festival / mGroup
• I2 Iteration
• Progress Report29.11.2004

2
Agenda

• Project status
• Used work practices
• Work results
• Demo

3
Introduction to the project

• We are developing an application called mGroup.
• The application name has changed from m3Festival
  tomGroup powered by DiMaS
• mGroup
• is an application for mobile phones,
• lets groups of people chat with text and images,
• is intended to be used in festival-type events.
• More about mGroup
• It features a server, the mDiMaS server, which
  relays the messages between mGroup applications.
• Information from mGroup is visible in the DiMaS
  peer network.
• Has more advanced features, such as group
  management and some support for commercial
  content creators. (Wont have time to implement.)

4
Status of the iterations goals

• A feature-complete product
• Partial/Fail Some must have requirements still
  not implemented
• Still a couple of features to implement in FD,
  but mostly tuning
• Nightly builds continuously running
• OK
• One service break due to change of IP on build
  server, but otherwise ok.
• User's Manual first draft written
• OK

5
Status of the iterations deliverables

• Project Plan
• OK
• Requirements Specification
• OK
• Technical Specification
• Probably OK
• QA Plan
• OK
• Test cases, test report
• OK
• SEPA diaries
• Diaries OK, SEPAs have not been that successful

6
Verbal Statement

• Christmas iteration didnt happen
• Everybody was busy with exams
• January
• Implementation proceeded ok
• Communication with customer was better than in I1
• Not enough time to implement all planned items
• Implementation on phones is slower than for
  desktop apps

7
Realization of the tasks

• Iteration not quite complete
• Two tasks were not started.
• Three tasks not yet completed.
• Short-range transmission was dropped.
• Estimation errors
• 67 avg absolute estimation error (was 48)
• 21 total estimation error (was 4)
• Error increased with coarser task-division
• Iteration was also longer

8
Planned Actions to Improve Task Planning

• To include Documentation tasks to have them
  included in estimates
• Somehow we managed to avoid properly estimating
  the time gone into documentation, and we also
  forgot to enter the documentation tasks into
  Bugzilla for the iteration plan.
• To enter all tasks into Bugzilla
• This is going well
• Trapoli tasks will not be as detailed as in the
  previous iteration
• This time it was perhaps the other way around we
  had so general tasks it made it somewhat
  difficult to close them.

9
Working hours by person
Realized hours in this iteration

• Significantly less hours than planned, primarily
  due to christmas iteration not being executed.
• Some hours are moved to final iteration

Real Plan Diff
Jouni 44 86 -42
Lauri 45 50 -5
Manne 40 30 7
Sam 58 95 -39
Sami 36 85 -49
Tommi 53 60 -7
Tuomas 44 78 -37
Total 320 484 -164
10
Working hours by person
PP I1 Chr I2 FD Tot
Jouni 31 50 30 56 24 190
Lauri 56 72 20 30 12 190
Manne 88 49 15 15 23 190
Sam 19 44 33 62 33 190
Sami 54 26 30 55 25 190
Tommi 37 69 10 50 25 190
Tuomas 47 46 30 47 20 190
Total 330 355 168 315 162 132

PP I1 Chr I2 FD Tot
Jouni 31 50 0 44 66 190
Lauri 56 72 0 45 18 190
Manne 88 49 0 40 13 190
Sam 19 44 0 58 70 190
Sami 54 26 0 36 75 190
Tommi 37 69 0 53 32 190
Tuomas 47 46 0 44 54 190
Total 330 355 0 320 326 133

• Due to the missing Christmas iteration, we have
  some working hours left for the FD iteration.
• Lauri and Manne have almost used up their hours.
• Jouni, Sam, and Sami have more hours to spend.

11
Quality Metrics

• System tests last run 6.2.2005
• Client revision 2.40
• 11 tests run, 3 failures, 1 skipped
• All unit tests pass for the server
• Bug status shown below
• Slightly unrealistic, since there is only the
  division between server and client
• Most features are visible primarily in client,
  while still requiring server work, putting
  additional entries on the client.
• A better division would be per functional
  requirement, for example.
• List includes also tasks.

  Major Normal Minor Enh
Server 2 5 1
Client 7 10 8 7
Process 4
12
Software Size in Lines of Code

• Client 5758 lines (previously 2656 lines)
• Server 8527 lines (previously 3744 lines)
• Almost doubled in the iteration, which is
  reasonable.

13
Risks

• The situation with the risks is pretty much the
  same as in previous iterations.
• Possibly realized risk 7.4.3 Member(s) unable
  to devote sufficient amount of time to project
• We need to make a spurt in the last iteration.
• In last iteration, we identified risk 7.1.1
  Changing or misunderstood requirements as
  worrying for the customer.
• I think we now understand each other about what
  the requirements are
• The concern at the moment is that we might not
  have time to implement the functionality required.

Risk matrix
  2 7 5 14
H 0 1 1 2
M 1 5 0 6
L 1 1 4 6
  L M H  
Probability
Severity
I1 Risk matrix
  2 7 5 14
H 0 1 1 2
M 1 5 0 6
L 1 1 4 6
  L M H  
14
Used Work Practices

• Time Reporting
• Version Control
• Coding Conventions
• Risk Management
• Meeting Memos
• Planning Game
• Two planning games held one in christmas, one in
  january
• Tasks in Forums (details)
• Scrum-style meetings
• Not working too well, were going to drop these.
• We will go through the open tasks instead.
• Work burndown graph (details)
• Continuous integration (details)

15
Planning Game

• XP-style planning game
• Used to select tasks for the current iteration
• We start with a budget of X hours for the
  iteration.
• Development writes down a selection of most
  important use cases and other tasks onto pieces
  of paper, based on the requirements spec
• We wrote the use cases on A4-papers, and broke
  them down into tasks on post-it notes.
• During the meeting the customer selects those use
  cases and other tasks he/she wishes to have
  implemented
• Development estimates the time taken to complete
  each of the tasks the customer has selected
• Customer can change her selection based on this
  information
• The process is continued until the X hours have
  been filled.
• The order of the use cases selected indicates
  their priority.

16
Work Burndown Graph

• Iteration time on the x-axis
• Estimated time left for this iteration on y-axis
• Generated directly from the Trapoli report
  Tasks, realization
• Placed on the front page of the Wiki so it is
  visible to everyone
• Pros
• Very easy to maintain
• Communicates many variables Time into iteration,
  Completion status, Working velocity, Time
  Reporting activity
• Cons
• No automated tool for creating it.
• Does not tell you which tasks are being
  overlooked.
• We made some mistakes
• At first, there were problems with time reporting
  (estimating tasks to zero-hours-left)
• Later on, some Trapoli tasks were left dangling
  with a nonzero left-field even after they were
  completed.
• In the future, we will go through all started,
  non-completed tasks in meetings
• Make sure they are not dangling

17
Work Burndown Graph I1
18
Work Burndown Graph Christmas
19
Work Burndown Graph I2
20
Scrum-style meetings

• Everybody answers three questions
• 1. What have I completed since the last meeting?
• 2. What will I do until the next meeting?
• 3. What hinders me from doing my work?
• Pros
• Fast and straightforward format for task
  distribution
• Cons
• Questions seem unnatural and hard to answer
• Executed over IRC, the meeting still takes a long
  time, even though it is intended to be short.
• We have decided to drop this practice
• Instead go though presently open tasks with
  Bugzilla as a base
• Deal new tasks to those who have completed
  previous tasks

21
Bugzilla for Tasks

• We have all tasks in Bugzilla
• We dont want to have tasks in three places
  (Bugzilla, Trapoli, Forums)
• Bugzilla features discussions
• We can prioritize bugs together with tasks.
• Systematizes verification of task completion as
  well as feature completion.
• This has been working well, and we will continue
  to use it.
• Example Verification of tasks
• Bugs / tasks are marked as RESOLVED FIXED when
  programmer is done.
• QA periodically checks the items in the RESOLVED
  FIXED list.
• System tests are updated.
• Documentation is updated.
• If everything is ok, the task is marked VERIFIED
  FIXED
• If something is wrong, comments are added and the
  task is marked REOPENED

22
Continuous Integration
Date Thu, 25 Nov 2004 200150 0200 (EET) From
lnaulapa_at_pp.htv.fi To tolappal_at_cc.hut.fi Subject
FESTIVAL BUILD mDimas Build Failed View
results here -gt https//festivaal.dyndns.org8443/
cc/buildresults/mDimas?loglog20041125200106 BUIL
D FAILED Ant Error Message /home/cruisecontrol/bu
ilds/cc-build.xml8 The following error occurred
while executing this line /home/cruisecontrol/bui
lds/checkout/mdimas/build.xml106 Compile
failed see the compiler error output for
details. Date of build 11/25/2004 200106 Time
to build 32 seconds Last changed 11/25/2004
195955 Last log entry Added date-to-string
conversions.

• Installed a tool called CruiseControl
• It monitors the code repository
• When there are changes in source control, it
  builds the code and runs all the tests
• If there are errors in build or tests, it emails
  the person who performed the check-in.
• Pros
• Developers get instant feedback if they break
  something
• Easier to fix problems, since the changes are
  fresh in memory
• No broken code in source control
• UPDATE in I2
• Latest working build is automatically deployed on
  a public URL to simplify testing of it.
• Automatic version numbering.

Date Thu, 25 Nov 2004 200807 0200 (EET) From
lnaulapa_at_pp.htv.fi To tolappal_at_cc.hut.fi Subject
FESTIVAL BUILD mDimas build.11 Build
Fixed View results here -gt https//festivaal.dynd
ns.org8443/cc/buildresults/mDimas?loglog20041125
200714Lbuild.11 BUILD COMPLETE -  build.11 Date
of build 11/25/2004 200714 Time to build 40
seconds Last changed 11/25/2004 200638 Last
log entry Added option to start the client
without networking (for testing purposes).  Unit
Tests (8) All Tests Passed
23
Results of the iteration

• Project Plan and Requirements Specification
  updated
• Technical Specification updated
• Diagrams for server and client and overall
• User Interface navigation map
• Body text updated
• mGroup features
• Add Existing Pictures
• Multiple Story Support
• Threaded view for messages
• Media Show support (many pictures and text in
  same messages)
• First Launch / Installation
• Numerous small changes 37 tasks/bugs resolved
  and verified
• Users Manual (draft)

24
Project Plan Update

• Small tuning to Work Practice documentation
• Remaining verification criteria documented

25
Requirements Specification Update

• Current situation regarding requirements

  Implemented Approved Deleted Total
Functional  
Must 5 2 7
Should 17 13 3 33
Nice to have 4 15 2 21
Total 26 30 5 61

  Implemented Approved Deleted Total
Non-functional  
Must 4 4
Should 3 2 5
Nice to have 1 6   7
Total 8 8 0 16
26
UI Navigation Map
27
QA Approach

• Every implemented feature goes through a
  verification step when it moves from RESOLVED to
  VERIFIED
• System-level tests
• Incrementally refined and improved
• 23 system tests
• New tests arise when verifying tasks / bugs
• We have a few automated unit tests
• Run every time someone checks in code

28
Demo (new features)

• First Launch / Installation
• Show first launch questions
• Add Existing Pictures
• Take a snapshot and include it in message.
• Multiple Story Support
• Create a Story
• Join a Story
• Threaded view for messages
• Show how threaded view groups messages
• Media Show support (many pictures and text in
  same messages)
• Create a message containing multiple items
• Move items around
• Delete items
• Send and view items