t-76.115 project review festival / mgroup i2 iteration progress report 29.11.2004

T-76.115 Project Review

Festival / mGroupI2 Iteration

Progress Report

29.11.2004

2

T-76.115 Project ReviewT-76.115 Project Review

Agenda

Project status Used work practices Work results Demo

3


Introduction to the project

We are developing an application called mGroup.

Full name: mGroup 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. (Won’t have time to implement.)

4


Status of the iteration’s goals

A feature-complete product Partial/Fail Some must have requirements still not implemented Still a couple of features to implement in FD

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 iteration’s deliverables

Project Plan OK

Requirements Specification OK

Technical Specification OK (at least better than before?)

QA Plan OK

Test cases, test report OK

SEPA diaries Diaries OK, SEPAs have not been that successful

6


Evaluation

Christmas iteration didn’t 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

Significantly less hours than planned, primarily due to christmas iteration not being executed.

Some hours are moved to final iteration…

Realized hours in this 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

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.

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

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

44 open bugs 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.

Open bugs

Server 7

Client 22

Process 8

Resolved / Verified bugs in I2

Major Normal Minor Enh

Server 2 5 1

Client 7 10 8 7

Process 4

Total 9 19 9 7

12


Software Size in Lines of Code

Client: 5758 lines (previously 2656 lines) Server: 8527 lines (previously 3744 lines) Rougly 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. 2 7 5 14

H 0 1 1 2

M 1 5 0 6

L 1 1 4 6

L M H

Severity

Pro

babili

ty

Risk matrix

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, we’re 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

1. We start with a budget of X hours for the iteration.2. 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.

3. During the meeting the customer selects those use cases and other tasks he/she wishes to have implemented

4. Development estimates the time taken to complete each of the tasks the customer has selected

1. Customer can change her selection based on this information

5. 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.

17


Work Burndown Graph – I1

0

50

100

150

200

250

300

350

400

8.11. 13.11. 18.11. 23.11. 28.11.

Date

Wo

rk le

ft

18


Work Burndown Graph – Christmas

Work burndown for Christmas iteration

0

20

40

60

80

100

120

6.12. 13.12. 20.12. 27.12. 3.1. 10.1.

Date

Wo

rk l

eft

19


Work Burndown Graph – I2

Work burndown for I2

0

50

100

150

200

250

300

350

400

10.1.2005 17.1.2005 24.1.2005 31.1.2005 7.2.2005

Date

Es

tim

ate

20


Scrum-style meetings

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

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.

21


Bugzilla for Tasks

We have all tasks in Bugzilla We don’t 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

UPDATE in I2 Latest working build is automatically

deployed on a public URL to simplify testing of it.

Automatic version numbering.

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

Date: Thu, 25 Nov 2004 20:01:50 +0200 (EET)

From: [email protected]

To: [email protected]

Subject: FESTIVAL BUILD: mDimas Build Failed

View results here -> https://festivaal.dyndns.org:8443/cc/buildresults/mDimas?log=log20041125200106

BUILD FAILED

Ant Error Message: /home/cruisecontrol/builds/cc-build.xml:8: The following error occurred while executing this line:

/home/cruisecontrol/builds/checkout/mdimas/build.xml:106: Compile failed; see the compiler error output for details.

Date of build: 11/25/2004 20:01:06

Time to build: 32 seconds

Last changed: 11/25/2004 19:59:55

Last log entry: Added date-to-string conversions.

[…]

Date: Thu, 25 Nov 2004 20:08:07 +0200 (EET)

From: [email protected]

To: [email protected]

Subject: FESTIVAL BUILD: mDimas build.11 Build Fixed

View results here -> https://festivaal.dyndns.org:8443/cc/buildresults/mDimas?log=log20041125200714Lbuild.11

BUILD COMPLETE - build.11

Date of build: 11/25/2004 20:07:14

Time to build: 40 seconds

Last changed: 11/25/2004 20:06:38

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

User’s 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

t-76.115 project review festival / mgroup i2 iteration progress report 29.11.2004

Documents

project reviewworking

project reviewstatus

project reviewrealization

project reviewintroduction

documentation tasks

project reviewplanned

general tasks

completetwo tasks