DaISy – Datacast Information System Group: Sotanorsu Customer: Digita Oy T Final Demonstration and Review

T Final demonstration 2 Agenda  Product presentation (5 min)  Demonstration (15 min)  Project evaluation (15 min)  Questions and comments (5 min)

T Final demonstration 3 DaISy – Datacast Information System Future: DigiTV Internet (DVB-T) Upload pictures and movies Create slide shows Attach PDA content Manage displaying content based on location View location based slide shows and movies (e.g. advertisements) Browse internet and extra content using PDA CoDSy DB Bluetooth CoDSy GPS CoMSy DB HTTP WWW CoMSy

T Final demonstration 4 Product Demonstration

T Final demonstration 5 Project Evaluation

T Final demonstration 6 Team Sotanorsu  Aleksi Ahtiainen (AA) – Project management 2004, Quality Control, Documentation, Development  Jussi Koponen (JK) – Architecture, Development  Kirsi Louhisuo (KL) – Requirement engineering, Configuration management, Development  Simo Neuvonen (SN) – Project management 2003, Infrastructure, Development  Esa Puttonen (EP) – User Interface, Development  Eiri Valanto (EVa) – Risk management, Development  Essi Vehmersalo (EVe) – Testing, Peer Testing, Development

T Final demonstration 7 Project Progress [1/4]  In total: 1412 hours  Documentation, meetings and project management took 52% of total work  Many hours of programming still in DE phase (minor improvements and unexpected bugs) Meetings 22 % Design 8 % Programming 26 % Testing 6 % Documentation 12 % Comp. Maintenance 4 % Studying 3 % Lectures 1 % Proj.Management 18 %

T Final demonstration 8 Project Progress [2/4] PP Iteration – Meetings and requirement design  Work practices documented  Requirements specified and prioritized with the customer  Infrastructure built (TWiki collaboration platform, mailing list, IRC channel)  Problem: Bugs in Trapoli system -> Own hour reporting practice using CVS I1 Iteration – Design and basic features  Architecture designed  11 more requirements implemented and tested  Problem: Bugzilla had no module division -> Own bug reporting within Twiki  Problem: Work hour estimates exceeded -> Had to decrease hours from plans in following iterations  Problem: Some hardware was delayed -> Had to concentrate on other issues AAEPEVaEVeJKKLSN PP phase personal hours PP planned PP actual AAEPEVaEVeJKKLSN I1 phase personal hours I1 planned I1 actual

T Final demonstration 9 Project Progress [3/4] I2 Iteration – Programming  Lot of programming  More focus on demonstrational use in meeting room -> DVB-T internet in moving vehicle dropped  17 more requirements implemented and tested  Problem: Work hours underrun -> Had to increase work share for some members in I3 and DE  Problem: Unit testing not working as planned -> Did code review and increased weight of system testing  Problem: GPS module and DVB-T cards not functioning -> Had to delay implementation  Problem: Too heavy risk management practice -> specified a lighter one I3 Iteration – Concentrating on requirements for final configuration  26 more requirements implemented and tested  Group and customer thought more about final demonstrational use:  some new requirements specified and implemented for easier demonstrational use  visualization of moving vehicle (GPS) -> demo preparation took time  had to drop specification of large system issues AAEPEVaEVeJKKLSN I2 phase personal hours I2 planned I2 actual AAEPEVaEVeJKKLSN I3 phase personal hours I3 planned I3 actual

T Final demonstration 10 Project Progress [4/4] DE Iteration – Finalization  6 more requirements implemented and tested  Attainment of goals and project practices analyzed with the customer and within the Sotanorsu team  Problem: Contract not signed, decided on postponing physical delivery to after easter -> easier to run final demonstrations. Customer has been able to test system through internet  Problem: More bugs found than expected, major problem in exception situation handling as well -> Some minor and trivial bug fixes after the preplanned final code freeze on Sun 28th March, major bugs well documented. The system was retested after these AAEPEVaEVeJKKLSN DE phase personal hours DE planned DE actual

T Final demonstration 11 Goal attainment  Out of the original 10 customer goals:  4 were reached:  Using GPS information  WWW interface for management  Scalable architecture  Easily extendable (some refactoring needed, though)  4 were dropped in I2:  Use of DVB-T internet  Well adapted for DVB-T internet use  External internet connection on PDA  Automatic content transfer (user triggered now in demonstration environment)  2 low priority goals were not reached:  The system is not error-prone and can recover from errors  The system is secure

T Final demonstration 12 Work share between team members  Project management: AA and SN managers, EVa and KL created demonstration content  Design: JK responsible for architecture design  Programming: EP and JK did the most  Documentation: AA did most of the project plan and reports, KL responsible for user guide and requirements document  AA: Did plenty of implementation work during the fall 2003, not as many hours left for project management in the spring. Spent a lot of time managing the techinical aspects of the project in addition to secretarial management AAEPEVaEVeJKKLSN Worktype share of team members Documentation Testing Programming Design Comp. Mgmt Lectures Studying Project mgmt Meetings

T Final demonstration 13 Software size  Total: 103 requirements, of which 60 implemented  Line count is not very good estimation method, but:  Total: 9100 NCLOC, 4900 COM  Would have been average size on course  Well commented (1/3 of lines in comments) PPI1I2I3DE Number of requirements across iterations High priority reqs Implemented High priority reqs Medium priority reqs Implemented medium priority reqs PPI1I2I3DE Software size in lines of code SQL code lines JSP code lines Java code lines

T Final demonstration 14 Quality assurance Requirements and testcases PPI1I2I3DE Implemented requirements Testcases TrivialMinorMajorCriticalBlocker Total bugs by severity Open Closed  In addition: 182 code review issues, of which 156 fixed  remaining ones are related to bug below and also some non-prioritized unit test class issues  1 major bug remains in exception situation handling  Wasn’t noticed well enough until DE iteration code review. This second code review should have been done in I3 instead.  Not a problem in proof-of-concept demonstration environment

T Final demonstration 15 Evaluation of used practices  Good at all other process related issues instead of risk management  Most critical about implementation related practices. Speculation:  Built-in perfectionism in every technology-oriented computer science student?  Easy for coders to think that it is their fault, that even one bug remains in the software, although that might have originally been caused by some trouble in the process Our use of practice 0,001,002,003,004,005,00 Unit testing User interface planning Risk management Static methods Assessment of architecture Architectural planning Bug management Refactoring System testing Coding convention Communication within the group Use cases Communication with the mentor Meeting practices Requirements prioritization Team organization Hour reporting Project reviews Scheduling Requirement management Communication with the customer Version control Iteration planning Iterative development process Documentation

T Final demonstration 16 Evaluation of used tools  Good tools to keep in mind in the future:  CVS  TWiki collaboration platform  Not so fun tools to work with:  WWW user interface, but I guess in our place and time we just have to live with it…

T Final demonstration 17 Lessons learned  Great introduction to iterative software development process  It was very helpful to plan the work practices in the beginning of the project instead of just starting to write code  Good experience in making work estimates  It takes a lot of work to both lead the people and manage the technical issues of the project in this course’s setting If only...  If final code review had been done already in I3, no major problems would remain in the software  The user interface and especially it’s architectural connection to the software should have been planned better  A person with more visual skills and enthusiasim would probably have gotten our final product prettier  Maybe a clearly a separate person being responsible for leading and managing technical details would have made the process more efficient and taken some of the stress out of the project manager  A separate server at the customer premises would have made it possible for the customer to test software on site instead of over the network Course feedback  Couple surprise mentor visits per iteration to the team meetings, customer meetings and computer classrooms might give mentors better inside information in the process. Progress reports and reviews are only the showcase  Arranging 4 demonstrations of the software, when it is not totally physically movable, takes a lot of effort. Maybe demonstrations at the actual production or development environment?  The calendar time of 7 months is long for this process and makes it very difficult and also more unrealistic to control. Maybe the course could be done in a single spring term?

Thank you for listening! Questions? Answers?