T-76.115 Project Review

1. T-76.115 Project Review ITSUPS Implementation 12.12.2004

2. Project status (15min) achieving the goals of the iteration project metrics Work results (20 min) presenting the iteration’s results demo Used work practices (5 min) Agenda

3. Introduction to the project • Project plan: ”The purpose of the project is to make the traffic simulation system of the laboratory of transportation engineering, HUTSIM, to collaborate with ViaSys’s city planning tool” HuVi: Positions, speeds and directions of vehicles NovaPoint Virtual Map HutSim ViHu: Borders of streets, trafficlines, traffic lights etc.

4. Integration of Traffic Simulation with 3D-Visualization Traffic Simulation 3D-Visualization Coord-Interface HUTSIM Microsimulation System NovaPoint Virtual Map XYZ-coords XML Vehicle Data (Dynamic) Conversion Path-Interface CNF-file Conversion & Edit Land-XML Configuration Data (Static) Line-Interface I.Kosonen, HUT

5. Status of the iteration’s goals • Goal 1: Design HUTSIM->Virtual Map architecture • OK • Goal 2: Design Virtual Map->HUTSIM architecture • NOT OK, because ViaSys hasn’t been able to provide us their output • Goal 3: Discuss what data is needed from the LandXML • ViaSys hasn’t provided the LandXML, but we have discussed about it on formal level. • Goal 4: Pipes are planned but not implemented • We have discussed about the pipes and there is some documentation about, but because even the lines are not fully implemented the pipes have been in smaller role.

6. Status of the iteration’s deliverables • Implementation of HUTSIM->Virtual Map • Plan standard for for data transfer format for visualization and simulation programs. Format must upgradeable. • not OK • Implementation of Virtual Map->HUTSIM • roads to HUTSIM as lines • Not totally completed, because we don’t have the Virtual Map output • simple HUTSIM-model • Not totally completed, because we don’t have the Virtual Map output • Documents: • updated project plan (especially ch. 5.3 QA plan) • OK, QA plan as separate document • updated requirements document • OK, no great updates required • technical specification • OK • test cases • OK • test report and test log • OK • progress report • OK • updated SEPA diaries • OK, refactoring and test automation on system level not used as planned • risk management document • OK, updated weekly • resource management document • OK, updated when needed (2 times per iteration)

7. Realization of the tasks • We got the output of Virtual Map 29.11. so hours were moved to the next iterations

8. Working hours by person Realized hours in this iteration Plan in the beginning of this iteration Latest plan (inc. realized hours and other updates) • It was decided with the customer that lot of implementation (hours) is moved to the next iterations • Hours were not equally divided due to trips and work given from other courses

9. Quality metrics Deffects in code Deffects found in document reviews

10. Quality assessment • HuVi (Hutsim -> Virtual Map) • Implementation started • Output format still not defined • Unit testing done while coding • Module testing was done on draft level • ViHu (Virtual Map -> Hutsim) • Implementation started • Input format still not defined • Unit testing done while coding • Module testing was done 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

11. Quality assurance –plan (1/3) • Project management • Iterative lifecycle -> team and customer have same goals • Scheduling and time tracking -> project is in time • Communication -> all communication channels works • Risk management -> better project quality • Documentation • Language -> product can be developed in future • Templates -> all important issues are discussed • Document version control ->Everyone knows that has been changed since last time • Iterative process in documenting ->documents better • Review -> ensure quality

12. Quality assurance –plan (2/3) • Implementation • Design -> implementation in two groups • Practices -> improve code quality • Iterative process • Code conventions • Refactoring • Testing • Unit level -> coders • Module, Integration and System level -> organized • Acceptance level -> customer with group • Error management and documentation • Bugzilla -> reported defects and their states • Test log -> report used test cases • Tools • CVS • Eclipse • TikiWiki • Bugzilla

13. Quality assurance –plan (3/3) • This iteration • Tested implemented parts of ViHu & HuVi • Not tested • Not totally implemented functionalities • Effeciency -> product still draft • Metrics • Deffects and their states • Review results • Environment -> Eclipse • Recourses • 2 testers • Test not own part of the code • Test rounds • Not yet, in future smoke tests

14. Software size in Lines of Code (LOC) • Any remarks on this metric? • Not so much was implemented as planned

15. Changes to the project • Implementation hours moved from Implementation 1 to Impementation 2 • We still don’t have the output of Virtual Map

16. Risks • Materialized risks • Other courses take time • Group member missing • Equipment not got in time • Preventative action: Hours moved to the next iterations • Time lost because we had to make demos in other way • Communication problems with ViaSys • Problem: We don’t know when we are going to get the output of Virtual Map • Greatest risks • Output of Virtual Map • Are we going to get? • If we get, when we are going to get it?

17. Results of the iteration • Virtual Map -> HUTSIM (ViHu) • Niko Setälä • HUTSIM -> Virtual Map (HuVi) • Minttu Mustonen

18. ViHu Module

19. ViHu Module

20. HuVi module • Converts data from Hutsim to 3D-animation application • Supports real-time animation • Can write data firrst to file and then run the animation • Converter for Virtual Map

21. Running the application • Parse data from Hutsim (use Ampel) • objects • pipes • Convert pipes to paths and positions • Make the XML output • Convert data to .ani-file

22. State Diagram of HuVi module

23. Class diagram of HuVi module

24. Used work practices • Week meetings • Time reporting • At least once a week (Sunday) • Version Control • CVS, server at SoberIT • Defect Tracking • Bugzilla • Risk Management • Separate document • Resource Management • Separate document • Sepas • Meeting practices • Static Methods • Still not used • Refactoring • Test Automation on System Level Testing