T-76.115 Project Review

1. T-76.115 Project Review Festival / mGroup I2 Iteration Progress Report29.11.2004

2. Project status Used work practices Work results Demo Agenda

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. 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 Realization of the tasks

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

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.

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 Resolved / Verified bugs in I2

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. Risk matrix Probability Severity I1 Risk matrix

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

17. Work Burndown Graph – I1

18. Work Burndown Graph – Christmas

19. Work Burndown Graph – I2

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 Date: Thu, 25 Nov 2004 20:01:50 +0200 (EET) From: lnaulapa@pp.htv.fi To: tolappal@cc.hut.fi 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. […] • 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:08:07 +0200 (EET) From: lnaulapa@pp.htv.fi To: tolappal@cc.hut.fi 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

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