T-76.115 Project Review

1. T-76.115 Project Review BigBrother I1 Iteration1.12.2004

2. Introduction (5 min) Skipped if all review attendees are familiar with the project Project status (15 min) Achieving the goals of the iteration Project metrics Work results (10 min) Presenting the iteration’s results Demo Used work practices (5 min) Next iteration planning (5 min) Discussion Agenda 1 5 min 15min 10min 5min 5min

3. Introduction to the project • Customer: Beconnected Finland Ltd. • Produces IP-based video surveillance systems for international market • Main product: ASAN = Automatic Surveillance and Alarming Network • Customer representative: PhD Michael Samarin • Project team: • Aino Lahdenperä, Maija Kangas, Outi Syysjoki, Janne Ojala, Antti Alestalo, Juhani Nokela, Ville Vatén • GOAL: Produce tools, which help Beconnected in their customer support work and reduce costs through increased productivity • Three tools will be created: • Watchdog – Automatic monitoring of network cameras • HourLogger – Log support person’s work hours per customer/target • LogAnalyzer – Search for error patterns from ASAN logs • Beconnected’s goals: • Working software is the only thing that matters • KISS – Concentrate on simplicity, maintainability, quality. No fancy features • Very busy making business – we should bother them as little as possible • Minimize costs – all costs should be covered by the attendance fee to SoberIT 3 5 min 15min 10min 5min 5min

4. Overview of the problem domain 5 5 min 15min 10min 5min 5min

5. Status of the iteration’s goals • Goal 1: Set up development environment • OK, except servlet debugger still does not work • Goal 2: Watchdog core functionality • We had a slight misroute on the way but are now on the right track • Almost there but no QA performed. • Goal 3: Hourlogger core functionality • OK, except only minor QA performed yet • Goal 4: LogAnalyzer architecture • We have planned, but no official documents exist yet • LogAnalyzer UI has not been planned yet • Goal 5: Requirements maintained and detail level increased • OK • Goal 6: SEPA practices used and revised • Not OK, Usability Tests postponed, No time for Design Patterns, Pair Programming used slightly, Meeting practices used, but not revised. • Goal 7: Quality Assurance plan • OK, but actual QA hasn’t started yet due to resources problems 7 5 min 15min 10min 5min 5min

6. Status of the iteration’s deliverables • Project Plan • Quality Assurance plan: problems due to Maija’s absense • OK • Requirements document • OK • Watchdog core functionality • Almost there, demonstrated to Beconnected this morning • Watchdog technical specification • Sent documentation to Beconnected, but is somewhat outdated • Hourlogger core functionality • OK • Hourlogger technical specification • OK, sent documentation to Beconnected • Test case document • POSTPONED: QA activities have not been started yet • Agreement on legal rights to project deliverables • NOT OK. We still don’t have a written contract about the legal rights to the project deliverables with the customer. 9 5 min 15min 10min 5min 5min

7. Realization of the tasks • Major discrepancies • Architectural design of too complex system takes time… • Programming slower due to slow debugging cycle… • Development environment setup has really been pain in the ***. • A lot of miscellaneous project communication not budgeted • Not started: • Systematic QA postponed to I2 due to Maija’s absense and slower progress than expected • Still not much effort on SEPAs 11 5 min 15min 10min 5min 5min

8. Realization of budget • Monthly allowance of € 100 for miscellaneous well justified project costs • October costs: • € 1 for mailing the NDAs • $ 43 for buying Core Servlets and JavaServer Pages, Vol. 1 from Amazon • November costs: • € 22 for pizza and coke for long weekend coding session • € 17.30 for pizza and coke for the final crunch coding session on Monday 12 5 min 15min 10min 5min 5min

9. Working hours by person Realized hours in this iteration • Maija had to leave Finland and haven’t been able to work at all for the project • Ville had to write the QA plan and has also performed design, testing and development environment setup. • Aino’s figure is more than 38 hours… • Work distribution among members has equalized since PP 13 5 min 15min 10min 5min 5min

10. Working hours by person • Shifted weight from the FD iteration to I2 iteration. • It’ll be interesting to see can Maija gain on us her lost hours in I1 Realized hours in this iteration Plan in the beginning of this iteration Latest plan (realized hours, updates up and down) 14 5 min 15min 10min 5min 5min

11. Quality metrics • Full controlled QA has not started yet • Concentration on the architecture and core functionality • Only minimal error handling implemented currently Bug metrics 15 5 min 15min 10min 5min 5min

12. Quality assessment 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 16 5 min 15min 10min 5min 5min

13. Software size in Lines of Code (LOC) • Concentrated on architecture and core functionality • Not all the lines here are actual live code • Code refactoring needed 17 5 min 15min 10min 5min 5min

14. Risks • Risks • Maija’s absense affects our QA activities => forced to postpone most of it to I2 • Development environment • An old computer running in Ville’s wardrobe • Work is highly dependent on working Trinet and Aalto • Also needed for the demo in the project review • NDA is very strict • We can not publish something critical to the course • We may publish something that breaches the NDA • Busy schedules among group members • Potential communication problems • Quality problems among team member deliverables 19 5 min 15min 10min 5min 5min

15. Changes to the project • Iteration 1 was turned into prototyping and architecture implementation • QA was postponed to I2-FD due to Maija’s absence • More critical to get the functionality working than QA at this point • Small changes to requirements • Natural process of refining customer needs and finding out new requirements 20 5 min 15min 10min 5min 5min

16. Results of the iteration • Watchdog demonstration • HourLogger demonstration 20 5 min 15min 10min 5min 5min

17. Watchdog • Watchdog • Monitors status of network camera on predefined intervals • Alarms when malfunction occurs • Records historical data of network camera statuses and erases old data • Architecture • We were building too complex system and wasted time • Now everything seems to be on the right track… • Implemented functionality • Background process: Fetches images from cameras and analyzes them • Camera list: Lists cameras and their current and past status • Camera info: Basic functionality is there, easy to expand • Configuration • User is able to change some parameters • Not all parameters implemented yet • Not implemented • Alarms and their configuration • QA has not started yet due to Maija’s absense 22 5 min 15min 10min 5min 5min

18. Demonstration • Watchdog • We’ll show you how background process works (by breaking up cameras!) • You’ll see the main view of the system and camera info view • Camera IPs have been censored to protect customer IP 27 5 min 15min 10min 5min 5min

19. HourLogger • HourLogger • Logs technician's work hours per customer, per target and per work type • Produces reports of the recorded work tasks • Architecture • This is not rocket science • More focus will be paid on the usability • Implemented functionality • Input work tasks and types • Overview of worktypes • Usability tuning still needed. This will be continued in I2 • Not implemented • Reports, Exporting, Customer/target management • Only minimal QA performed • All problems found have been easily fixed 28 5 min 15min 10min 5min 5min

20. Demonstration • HourLogger • Inserting a new performed check • Showing the overview of performed checks per customer and target 30 5 min 15min 10min 5min 5min

21. Used work practices • Time reporting in Trapoli • Still difficulties in time logging: dividing working hours and usability • Development server in Ville’s clothes closet • Problems with Trinet… • Long development cycle • Difficult debugging • Meetings • Worked well, but still scheduling problems among group members • Risk management • Risks have been managed, but not documented very well… • Requirements elicitation and analysis • Continued with the same style than in PP phase • Group working sessions • Group architectural design sessions • Group user interface design sessions • Group coding sessions with a couple of pair programmin sessions • Coding convention • Not complete • Nobody has completely followed the guidelines 35 5 min 15min 10min 5min 5min

22. Iteration I2 Goals • Generic goals: • Quality Assurance really started now • Code refactoring needed • Coding convention, commenting, documenting improved • Watchdog & HourLogger & LogAnalyzer goals • Minimum requirements functionality ready and fully tested • Test installation in customer’s test environment • Usability tests performed with customer representative with actual work tasks • SEPA goals: • Pair programming sessions on most critical use cases • Usability tests performed for all deliverables • Design patterns used in refactoring • Meeting practices are reviewed and improved • Iteration I2 divided to two sub-iterations • Three weeks development, then installation to customers environment • One week for customers internal testing and commenting • One week for applying customer’s feedback back into the products 39 5 min 15min 10min 5min 5min

23. Questions? 40 5 min 15min 10min 5min 5min