T Project Final Demo BigBrother

T Project Review 2 Agenda  Introduction (5 min)  Watchdog Presentation (10 min)  Hourlogger Presentation (5 min)  Project Evaluation (15 min)  Realization of project goals  Software metrics  Working practices and tools  Problem analysis

T Project Review 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 were under development:  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

T Project Review 4 Overview of the problem domain

Watchdog Presentation

T Project Review 6 Watchdog  Problem  Surveillance views had to be gone through manually to check the camera statuses.  Solution: Watchdog  Monitors status of network camera on predefined intervals  Latest ASAN configuration is downloaded from ASAN’s databese  A snap-shot of all the camera images fetched via HTTP  If an image can be retrieved it is analyzed for error situations:  Blackness: error if camera image is black during day time  No video: error if analog camera is not connected to video server  Status of the currently active malfunctions is kept up to date  New malfunctions are sent to the operator via .  The status data is recorded and too old data is erased.  All system parameters are editable via web interface  The system has been built to accommodate easy adding of new camera models  Developed with Java and MySQL 3.26  Running on Linux server

T Project Review 7 Demonstration  Watchdog  Configuring ASAN database  This configuration can be changed on the fly  Global configuration options  Interval lengths, addresses, sleeping period, and other settings  Main View  Status of each camera and an overview of the errors in past  A new check can be forced manually  Camera info view  Detailed history of a camera and its latest image  Some statistics about the errors in the history.  Malfunctions view  List of all malfunctions that have occurred  Technical data in this demo has been censored to protect customer IP

HourLogger Presentation

T Project Review 9 HourLogger  Problem  Beconnected engineers have to check the statuses of the systems in the customer permises  These actions are currently logged to Excel sheets causing a hassle with the files.  Solution: HourLogger  A web based tool for logging and reporting technician's maintenance and support work hours per customer, per target and per work type  Produces monthly reports of the recorded work tasks in Excel format  Developed with Java and MySQL 3.26  Running on Linux server

T Project Review 10 Demonstration  HourLogger  Customer/target/employee management  Inserting a new performed check  Edit task  Reporting  Excel-export

Project Evaluation

T Project Review 12 Realization of Customer Goals  Goal 1: Create business value by reducing costs in Beconnected's maintenance / support work for its customers  Achieved!  Goal 2: The software should be ready for production use during the project  Failed – customer acceptance testing still not performed  Goal 3: The software should fulfill the minimum requirements and avoid unnecessary complexity  Mostly achieved. LogAnalyzer did not finish.  Goal 4: The software should be usable, reliable and maintainable  Achieved/not sure.  Goal 6: Execute project with minimum costs  Achieved: only 3250 Euro total and less than 3 hours per week on average  Goal 7: Minimum critical information leakage  Achieved: The project team was careful with this.  Goal 8: Get contacts to TKK students  Achieved: Team members were good.

T Project Review 13 Realization of Project Team Goals  Goal 1: Return all deliverables on time  Achieved!  Goal 2: Get good grade  Dunno yet.  Goal 3: Produce useful software  Achieved.  Goal 4: High customer satisfaction  Achieved.  Goal 5: Learn more about software projects  Achieved.  Goal 6: Have a working team  Could have worked better…  Goal 7: Keep the work in the defined resources  Mostly achieved.  Goal 8: Learn to use new tools  Achieved.  Goal 9: To have fun  Achieved. Maybe it wasn’t as easy as expected, but challenging is fun too.

Software Metrics

T Project Review 15 Realization of the working hours

T Project Review 16 Realization of budget  Monthly allowance of € 100 for miscellaneous well justified project costs  Final costs in the allowance were from:  NDA mailing  Java books  Pizza and coke for group working sessions  Total costs were around 250 Euro

T Project Review 17 Quality metrics SeverityNumberOpenClosed Blocker000 Critical404 Major12210 Normal13211 Minor14212 Trivial202 TOTAL45639 Watchdog defect summary Hourlogger defect summary SeverityNumberOpenClosed Blocker202 Critical606 Major505 Normal25223 Minor1138 Trivial404 TOTAL53548

T Project Review 18 Quality assessment Functional areaCoverageQualityComments Logging3  Errors not handled Alarming3 Monitoring2 Presenting3  Minor (usability) issues Configuration2 Input validation not tested thoroughly Help2 Legend Coverage: 0 = nothing 1 = we looked at it 2 = we checked all functions 3 = it’s tested Quality:  = quality is good  = not sure  = quality is bad Functional areaCoverageQualityComments Logging3 Presenting3  Exporting1  Not working at all in IE. Scandics not shown. Management3 Help2  Not thoroughly reviewed. Watchdog Hourlogger

T Project Review 19 Software size in Lines of Code (LOC)  Not all the lines here are actual live code  The graph shows that the development was weighted towards the end of the iterations I1I2FD Watchdog java classes Watchdog JSPs Hourlogger java classes HourLogger JSPs LogAnalyzer java classes LogAnalyzer JSPs Testing and example JSPs 201 Utils Other Total (NCLOC + COM)

Working practices and tools

T Project Review 21 Used work practices  Document vs. communication driven development  Iterative development  Chief engineer centered development  Roles and responsibilities assignment  Customer on-duty session  Risk management  Group working sessions  NDA and information publishing process  Documentation in English and in HTML

T Project Review 22 SEPAs  Meetings Practices  Success  Pair Programming  Total disaster  Usability Tests  Lightweight but useful  Design Patterns  Didn’t apply that much for this project

T Project Review 23 Used tools  Development Server  Severe problems due to low performance and no debugging facilities  CVS at HUT CC  Worked well  Eclipe IDE  Handy. CVS cliend could be better  Trapoli  Sucks! Poor usability!  Tiki and Bugzilla  Worked well

Problem Analysis

T Project Review 25 Risks and Problems Summary  One group member had to leave abroad for a month in I1  Customer was often too busy to answer questions and provide feedback  Development server had very low performance  No separate testing environment  Quality problems occurred often in the deliverables of team members  Problems with used tools: usability problems, corrupting data, forgetting CVS commits, etc.  Compatibility problems between member goals, working habits, preferences, schedules occurred often, which slowed down development.  Customer could not provide a good development server on time  Customer did not start acceptance testing on time

T Project Review 26 Changes to the project along the way  Small changes to requirements  Natural process of refining customer needs and finding out new requirements  I1 iteration was turned into prototyping and architecture implementation  Customer testing period had to be moved from I2 to FD due to busy customer schedule  Watchdog and Hourlogger features kept surprisingly well considering the difficulties in the project  LogAnalyzer was not finished  This decision was made very late in the project

T Project Review 27 Questions?