T-76.115 Project Review

1. T-76.115 Project Review SOLIData I2 Iteration2005-FEB-08

2. Project status (20min) - Arttu Overview on the iteration – Arttu Goals – Arttu Realization of Tasks – Arttu Working Hours – Arttu LOCs – Janne Quality - Mikko Risks – Markus Change management – Markus Work practices – Arttu Work results (25 min) presenting the iteration’s results Releases DEMO Plan for Next Iteration FD (5 min) - Arttu Questions/Discussion etc (10 min) Agenda

3. Introduction to the project • This project focuses on producing single-click Bluetooth connectivity between Symbian OS mobile device and Bluegiga server. The idea is to enable video streaming for smart phones in public places (e.g. train, bus).

4. Overview on the iteration • A successfully two mini-increment’s plan conducted in the I2 iteration (not successful in I1) • Increased quality • The 1st test round revealed nasty bugs which we were not aware  we had time to fix some of founded bugs of 1st testing round • Motivation • The motivation was kept up because of clear mid-milestones • Early in move • The mid-milestones forced continuous work • We had good start in the I2, better than in I1 • Plan + requirements were all set before Christmas vacation • Design + implementation was started during Christmas time • Original plan was to start implementation before Christmas  this was over-optimisms • We (almost everybody) had relaxing Christmas vacation – as planned • The team members have had long absences (unreachable) • Arttu: 2004-DEC-15 – 2005-JAN-16 • Heikki: 2005-JAN-13 – 2005-FEB-21 • Pekka: 2005-FEB-01  • Internal milestones were updated once during iteration • We had buffer in internal plan as response to changing conditions • Testing was completed on time • 1st round: 6 bugs found (2 critical, 2 major) • 2nd round: 5 bugs found (0 critical, 2 major) • Two additional testing packets released • The goal of the iteration is very well filled

5. Overview on the iteration – milestone update Updated

6. Status of the iteration’s goals • Goal 1: Easy delivery • ”Two empty access points can be set up using memory stick. The YES mobile application can be used from the both access points so that re-installation is not needed when changing the access point ” • Goal 2: Configurable • New requirements to make the APP configurable • Goal 3: Fix bugs founded in I1 • Mainly fixed (bug #5 not fixed)

7. Status of the iteration’s deliverables • Configurable version of the system implemented • OK, selected requirements filled •  some bugs still open • Added 2 smaller requirements during the iteration • Project Plan • Minor updates to update iteration plans, current version 1.44 • OK, except detailed plans for FD iteration • Risk Management • 3 closed risks • Requirements document • 3 CRs (change request), current version 1.41 • Technical Specification • Complete, review held for version 1.1 (current 1.2) • Admin user manual • Complete, review held for version 0.2 (current 0.4) • Testing overview for I2 • System Test Plan and Report (includes test log) • 2 plans+reports from both testing rounds • Progress Report for I2 • Architecture Design • No updates

8. Realization of the tasks Unplanned

9. Realization of the tasks • Design workshop was used • Efficient • Implementation time was overrun by 37% • Extremely difficult to estimate • Bug fixes etc was not taken care well enough in the beginning • New subtasks were added during iteration (e.g. INF:Maintenance) • This includes also some ‘studying’ hours, because it's hard to separate between studying and implementation. Learn by doing

10. Working hours by person Realized hours in this iteration • Janne was sick for 1 week • Markus moved to new apartment  no internet connection, yet • Pekka’s hours were counted incorrectly  -6 hours for the iteration (383h vs. 377h)

11. Working hours by person Realized hours in this iteration Plan in the beginning of this iteration • Overall, we followed the plan quite well! • Markus, Janne have more to do in FD iteration • more resources in peer-testing Latest plan (inc. realized hours and other updates)

12. Software size in Lines of Code (LOC) More detailed table

13. Software size (Continued) • The basis for the YES-App is OfficeAgent • Current implementation has reduced the dependencies for the original code •  practically everything has been written again, own code •  this is reason for reduced number of LOCs •  Removed unneeded code from OfficeAgent

14. Bug history

15. Open bugs and estimated cost to fix

16. Quality assessment • We could not test with many phones (>2) because additional phones were not available early enough. •  to be conducted in FD iteration 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

17. Quality - Description of configurable version? • YES Application • UI improved – nicer graphics • Improved BT connection handling, e.g. in closing the App. • Tested with multiple phones, and with very ‘nasty’ settings in them • Testing was performed also from security point of view  more ‘interesting’ test cases • Access Point • Can be released using USB stick • Does not include WRAP upgrading • Streaming Server • No modifications during I2.

18. Risks • Open risks • Technology – 0 risks • Development environment – 2 risks • Requirements – 1 risk • Resources - 3 risks • Implementation – 1 risk • Changes • Tech_Risk_1 (”Bluetooth driver”)  CLOSED • Tech_Risk_2 (”Properties of devices”)  CLOSED • Rsc_Risk_1 (”Too many hours planned for iteration I1”)  CLOSED • Impl_Risk_1 (”Responsibilities unknown”), propability MEDIUM  LOW

19. Change Management • Change request (CR1) opened to improve ’one-click’ requirement • Opened in I1 • CANCELLED  CR2 has another approach for that one (configurable) • Change request (CR2) opened to improve requirements for I2 • ACCEPTED • Missing implementation for improved one-click configurable • Change request (CR3) opened to define BT connection requirement better, and add GPL license text into the APP • ACCEPTED

20. Requirement Management • WLAN requirements are still in req spec • Streaming server has requirement for broadcast streaming  not going to be done • Non-functional requirements (NFRs) almost implemented  not tested Legend N (M) N = # of requirements implemented M = total # of requirements

21. Used work practices • New practices used in I2 • Started to use own task for bug fixings (mentor proposed) • Improved bug analyzing  price added for each bug (mentor proposed) • Weekly code release for the customer • Pair programming in mobile application • Requirement matrix  status of each requirement

22. Results of the iteration • Major deliverables of the I2 iteration • Configurable version of the system • Missing implementation for improved one-click configurable • Admin user manual • Test plan & reports • Minor deliverables • Review report • Change requests (3 pcs) • Updates • Project Plan • Requirements Specification • Architecture Design • Technical Specification • SEPAs

23. DEMO

24. FD iteration • Risks in FD iteration: • Pekka in Australia (not available anymore for the project) • absence of Mikko, Markus & Tommy at end of iteration. Especially Mikko missing at second testing phase •  Janne, Heikki to cover

25. Questions/Discussion DEMO Implementation Results – used effort Requirements FD iteration Testing