T-76.115 P2PDigiTV

1. T-76.115 P2PDigiTV Team Medialiima I2 Iteration08.02.2005

2. Project status (15min) Achieving the goals of the iteration Status of the deliverables Used resources Project metrics Quality issues Risks Used work practices Work results (25 min) Iteration results Demonstration Question/discussion (5 min) Agenda

3. Introduction to The Project • Goals • Develop a prototype of an extended digi-TV set-top-box • Tight integration to P2P-networks • Multimedia-ready centre for home entertainment (DVD, DivX, MP3 etc.) • Integration to the existing DiMaS content management system • Teach the project group good software project practices • Pass the Software Project course with good grades • Project team: Seven computer science students from HUT • Customer: Helsinki Institute for Information Technology (HIIT) • Schedule: September 2004 – March 2005 • Budget: constant, 1330 man-hours from the project group

4. DiMaS Environment

5. Status of The Iteration’s Goals • Add more specific functionality, improve existing architecture • OK: Technical decision refined, core structure stable and working • Gain knowledge about unfamiliar tehcnologies (MHP, digi-TV, TPM) • OK: Quite a lot of time was spent on investigating various techniques and their suitability for the project’s use (phase 1 of the I2 iteration) • Implement selected functionality during the phase 2 • Partially OK: Handling of DPs still partially not implemented due to lack of properly constructed DP implementation • Find and purchase final hardware • OK: Hardware purchased and working properly • Fix existing defects • OK: Most of the previously found defects fixed, some still pending • Improve the installation CD • OK: Installation is now much faster and used user interface has also been improved

6. Status of The Iteration’s Deliverables • Code components • Mostly OK: • All UI layouts not ready yet • DP search/download only partially implemented (no license nor feedback) due to lack of complete DPs and DP metadata parser • iPAQ UI still not fully functional • Demonstration manuscript (User’s manual) • OK, not deeply detailed yet and will be refined later • Test plan, test cases, test report and test log • OK, not much negative test cases due to nature of the project • Progress Report • OK • Revised Project Plan, Revised Requirements Specification, Revised Quality Handbook, Revised Risk Scenarios, Revised Technical Spec • OK, updated all documents to represent the current situation • Technical specification still on quite high level, will be defined in more detail later • Revised SEPAs • OK, all implementations started.

7. Realization of The Tasks • Uncertainty of technologies clearly seen on estimates • Some of the estimates are vastly too small • Many tasks were badly underestimated (e.g. Remote controlling, VS communication, WLAN proof-of-concept) • Big underestimation for the UI work • Work could not be started as it was planned due to late delivery of reference DP and some HTML layouts

8. Working Hours by Person Realized hours in this iteration (situation on 07.02.2005) • Reasons for differences • The biggest task for Antti (MHP-implementation) was cancelled by the customer • It was hard to divide other parts of the project • ”Adding more people to the late project makes it even more late” • Antti will be the main responsible for the peer testing to make difference smaller

9. Working Hours by Person Realized hours in this iteration Plan in the beginning of this iteration • Apart from Antti the plan is holding quite nicely • When approximating the amount of implementation work left and time left, it seems that the project will approximately be in budget and most of the customer goals can still be met Latest plan (inc. realized hours and other updates)

10. Working Hours by Person per Week • Most of the lines nicely together • Concentration of hours towards the end of the iterations is remarkable • Should be tried to avoid • Suggests that it is hard to estimate the amount of work left Note: Weeks run through New Year (Week 54 is actually week 1)

11. Working Hours by Person per Week (Revisited)

12. Working Hours by Work Type • Generally huge amount of time was spent on studying • At the beginning of the I2 lots of meetings were held with the customer to decide the implemented functionality • At the end of iteration programming took over • General “non-productive” tasks didn’t need much time • PP & I1 iterations were successful on defining practices and tools

13. Project Metrics • More than 410 SVN revisions • 735 emails since 15.09. • 20 formal meetings • 7 customer • 4 mentor • 9 group • 120+ pages of delivered documents • 1022 hours spent (ca. 75% of the budget) • ~190 Wiki pages • More than 1 800 separate updates • More than 14 000 views • More than 140 file uploads

14. Software Size in Lines of Code (LOC) • The amount of lines of code doubled during the I2 iteration • In many cases the amount of comment lines decreased

15. Quality Metrics (1 / 2) • Coding conventions are mostly used. There is some variance in the coding style of different persons  All code will be run through a formatter during the last iteration • Commenting of the code is not satisfactory. All code must be checked and more thorough comments written during the last iteration • Static checking tools were used (FindBugs, Metrics) • Only minor issues were found • Some refactoring of the code is needed (better field names, etc.) • Refactoring SEPA supports this • All new documents have been reviewed at least by two group members

16. Quality Metrics (2 / 2) Bug metrics Test case statistics • 30 new test cases were introduced. • Focus area: functional tests suite (based on use cases) • Old main menu test cases that relate to keyboard control were not executed, because the STB is not meant to be used with the keyboard (13 tests) • Only 6 bugs were found during the system tests • Note that UI issues are not considered as bugs. The UI is under major transformation and there still are many UI issues • One known major bug was left to the iteration end product • CD track information is fetched from the Internet when building a track list. If Internet connection is not available the track list cannot be formed

17. Quality Assessment • Testing was not thorough enough • Quality goals were mostly fulfilled • One major bug was found Legend Coverage: 0 = nothing 1 = we looked at it 2 = we checked all functions 3 = it’s tested Quality: J = quality is good K = not sure L = quality is bad

18. Risks • Risks are controlled as planned in the Risk Management Plan • List of relevant risks maintained in Wiki • Risk management and review session every second week in the project meeting • Most serious risks at the moment • Severe dependencies on other groups • Implementation speed already suffered due to these reasons • Lots of extra work needs to be done to cope with missing pieces • Time schedule slip • Implementation was harder than expected • Studying used technologies took more time than expected • Insufficient testing • Due to time constraints the testing coverage is not as good as was wanted • Much more effort needs to be put on testing in FD iteration

19. Used Work Practices • Most of the practices used during the PP and I1 iterations still in use • Wiki Task Tracker plugin was abandoned, since it didn’t provide enough value • No new tools introduced • Communication and meeting practices • IRC has become the main communication channel • Wiki is not used that much as it is too slow for communicating implementation issues • Time reporting & task tracking • Due to restrictions of Trapoli the project manager still keeps own history data in Excel about used resources

20. Results of The Iteration • Mandatory results required by the course • User’s manual (Demonstration Manuscript) • Test Plan, Test cases, Test Log • Progress Report • Other already delivered documents revised • Developed Software • Installation CD • UI component (main menu, playlist, content search, settings etc.) • P2P Peer component (also stand-alone versions) • XML Database component • Content transfer component • Remote Control support • WLAN support component

21. System Architecture • Some keywords about the system architecture • Based on standard Debian Linux distribution • Most of the coding done using Java • Some shell scripts etc. done also • Highly modular architecture where user interface and core components are well separated • User interface implemented using pure Web technologies • Allows extremely fast UI implementation in general • However, lots of Javascript needed to implement remote control navigation -> slows down UI development remarkably • Provide an extremely simple way to customize the UI (using templates) • Customized WWW browser completely hides the operating system from the end used (cf. Kiosk type terminals) • P2P networking implemented using JXTA platform developed by Sun Microsystems • Lots of open source components used to increase the speed of development • Jetty servlet engine • Velocity template engine • Log4J logging framework • Xerces XML parser

22. Demonstration • P2P networking functionality • Searching distribution packages • Publishing a new distribution package • Playing distribution packages • Using playlist • Organizing playlist • Playing content • Watching digi-TV • Controlling STB with remote control • Accessing STB with iPaq

23. What Next? • Finalize all functionality • No new big features anymore • Much care and communication effort is needed to integrate all HIIT groups together • More effort on stabilizing the code and fine tuning the system • Pay more attention on testing especially using the demonstration manuscript • Next tasks • Plan the FD iteration in more detail with the customer • Have a group meeting to share responsibilities for the last iteration • Organize peer testing with Festival group