1 / 28

T-76.115 Project Review

T-76.115 Project Review. Festival / mGroup I2 Iteration Progress Report 29.11.2004. Project status Used work practices Work results Demo. Agenda. Introduction to the project . We are developing an application called mGroup. Full name: mGroup powered by DiMaS mGroup

hamish-hernandez
Télécharger la présentation

T-76.115 Project Review

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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

More Related