T Iteration Demo OSLC 2.0 I1 Iteration

T Iteration demo 2 Agenda  Project status (10 min)  achieving the goals of the iteration  project metrics  Used work practices (5 min)  Work results (30 min)  presenting the iteration’s results  demo  For general information on the project  see Project Planning Phase Progress Review slides

T Iteration demo 3 Introduction to I1  26th Oct – 12th Dec  6 weeks  Three sub-iterations:  Sub-iteration 1: –  Sub-iteration 2: –  Sub-iteration 3: – 8.12  Detail iteration plan can be found in detailed sub-iteration plan: Note: additional work for sub- iterations to the course requirement. The main idea is to visualize the working result and get constant feedback from customer!

T Iteration demo 4 Status of the iteration’s goals  Goal 1: implement and carry out sub-iteration development work  OK  Goal 2: deliver promised features to the customer  OK  Goal 3: Architecture design complete and approved by customer  OK  Truest building with customer and mentor  OK  Visualize intermediate development result to customer and get early feedback  OK (3 sub-iterations with specific deliveries to customer)  Finish all deliveries with high quality  OK  Achieve a good iteration result  OK (development result is acknowledged by both customer and mentor)

T Iteration demo 5 Status of the iteration’s deliverables  Project plan  OK, except chapter 6.4 – iteration plan for next phase  Requirements document  OK, all important requirements documented in detail  Use cases 1, 2, 3, 5, 6,7,8 implemented and tested  OK  Functional requirements F1, F2, F5.1, F6.1, F6.2, F7, F8.1, F8.2, F9, F10, F11, F12, F14, F15, F16, F17, F19, F20 are implemented (18 out of 27 reqs in total)  OK  General Technical specification  OK (approved by customer)  Test charter  OK  Test result and log  OK  Progress result  OK  OSLC 2.0 source and build for Implementation 1  OK

T Iteration demo 6 Realization of the tasks  Show status and effort distribution per task or task group  (not on too detailed level)  discuss major discrepancies between the plan and realizations  unfinished/removed tasks?  any unplanned tasks? Status RealizedPlanned Diff(Left) Project ManagementOk 36,22313,2N/A Requirement EngineeringOk 615-9N/A Architecture DesignOk 14,2520-5,75N/A QA and testingNot ok 82,573,59N/A Development workOk N/A MeetingsOk 89,2592,5-3,25N/A Other ActivitiesOk 16,533-16,5N/A Totalok 536,250333,7

T Iteration demo 7 Resource usage  We decide to implement most of the features this year. (2/3 of all feature implemented)  Yuan: lots of time spent on updating documentation according to mentor comments  Veli-Jussi: GUI design took more time than expected as implementation with Java Swing is more completed than other approach  Jussi was traveling and not available for more than 2 weeks.  Mika: the Java source file parsing is complicated. The original plan is not realistic for the amount of implementation work. Original plan (in the beginning of the iteration) Realization and updated plan (realized hours and updates) JingYuanSakariLauriMikaXieVeli-JussiJussiSUM PP ,520, ,3 I ,5502,5 I2 52,56051,574, ,5512,2 Total JingYuanSakariLauriMikaXieVeli-JussiJussiSUM PP 50,55068,520, ,3 I1 50,27758,7571,2576,562, ,20 I2 49,34342,7578,455565, ,5 Total

T Iteration demo 8 Defects and other quality metrics  Description of blocker and critical bugs found and open  None open blocker bugs  None open critical bugs  One open minor bug: References-checkbox becomes out-of-synch  Other QA metrics  Test coverage: 100% (test cases cover all the proposed requirements that can be tested)  Development progress: 64% (22 test cases designed for the whole system and 14 test cases carried out by the end of Iteration 1)  Current quality based on test cases: 100% (No failed test cases before delivery)  Defects solution: 97% (33 bugs found, out of which 32 resolved by ) BlockerCriticalMajorNormalMinorTrivialTotal Found in Iteration Open

T Iteration demo 9 Quality dashboard  Evaluate the quality of the parts of the system  QA practices:  Pair code review  Continuous refactoring  Documentation review  Heuristic review  Testing  JUnit testing: 6 critical modules unit tested  Test case based testing  Exploratory testing  Performance testing  Confidence on quality is based on testing and test results  Defects management: Bugzilla, bug report systemized Functional AreaProgressCoverageQualityComments License matchingHigh3 Works well Directory processing High2 Works well Package processingHigh2  Slow when opening large packages; being improved Multiple source file support Start2 Java source file support completed; Other source files not implemented yet Command line option Ready3 Works well GUIReady1 Works all right; being improved

T Iteration demo 10 Quality goals  Evaluation of the status of the project's quality goals Quality goalsStatusReasoning Functionality The system performs all the functionalities as planned for Iteration 1. Functionalities are tested and got expected results. Correctness No serious errors before delivery. Critical defects are fixed. Maintainability  Comments are written with Javadoc convention, but there should be more and better comments. Usability  User interfaces still have room for improvement.

T Iteration demo 11 Software size in Lines of Code (LOC)  No source code reuse from last year’s project  lots of new functinality was implemented  Good commenting habit in general  Unit testing done for integration PPI1 (Source code)I1 (Test code)I2 Event /comments 032 /0 -N/A Filepackage /comments 0618/ / 20 N/A Gui /comments 01482/ N/A License /comments 0400 /106 91/ 10 N/A Matching /comments /465 59/ 22 N/A Repository /comments 097 /41 - N/A Sourceparser /comments / / 88 N/A Sourcetree /comments 0227 /106 70/ 25 N/A general /comments /585 - N/A Total (NCLOC + COM) N/A Comments (COM) N/A

T Iteration demo 12 Changes to the project  End user business review  to get early customer feedback and increase confidence of the final delivery  Note: This is additional work to the course requirements  Lauri took over the integration development  this is something we did not think thorough enough  Few requirements are moved to next year’s development  CVS integration  Next year  special matching feature  Next year  Few new requirements:  Calculation on match finger print  next year  Use keyword matching to narrow down the license matching possibilities  next year  Consideration for upcoming GPL 3 license

T Iteration demo 13 Changes to the architecture from initial draft  Events to the GUI  generated when processing of the package starts or stops  also when a single file has been processed  used to implement progress bar  Iterator for file packages  speeds up opening compressed packages (no need to unpack to temporary directory first)  currently slows down opening single files  improvement has been proposed  Matching  exact and partial matching is now implemented in same algorithm  if match-% is 100% -> exact match  caching of internal data structures to improve performance  Small additions  some extra methods and variables in other module interfaces Architecture has mostly been stable, a few changes have been made:

T Iteration demo 14 Risks RiskRealizedControlling actionsResponsible Running low on resource Veli-Jussi’s task effort under estimated Adjust his work amount for the next phase Jing The project scope grows continuously noFreeze requirementsYuan, Re-scoping the projectSakari Technical difficulties or impossible feature to implement noRe-negotiate with our customer about the requirements Jing, Yuan, Sakari Yuan Group progress invisible to customer and mentor noSub-iteration demo and get feedback from customers. Demonstrate the result to Seppo Jing Jing-Helles Yuan Sakari Kääriäinen Project group members unavailability Jussi was travelling for more than 2 weeks. Other team member had to took his tasks. Let all group member inform early enough in such situation. Jing Strictly monitoring the development progress Group progress invisible to customer and mentor noHold regular meeting with customers and mentor Jing Jing-Helles Publish weekly progress report to them Communication problem noContinue with the current communication framework. Jing Jing-Helles

T Iteration demo 15 Used work practices  Work practices carried out  Bugzilla for implementation task management and defect management  TikiWiki – group documentation, discussion forum, communication, task distribution, group calendar  Build process  ant  Version control  CVS  Code review  Skype meeting – saves time and money  Weekly time tracking  Weekly internal meeting for task planning, status report and risk management  meeting agenda & minutes  Agile process  two-week iterations  2-weeks tested build delivery to customer  Unit testing  provide the first level of quality confidence  Get early feedback from customer  Our overall process framework is very good and every member follows the process  we will continue with this process in the next year

T Iteration demo 16 Results of the iteration  The major deliverables of the iteration  project plan (Implementation 1 Section)  requirements (with detailed use cases)  General system architecture  QA plan  Test session charter  Test Cases, test result, and test log  QA report  Progress report  Working application and source code  Software Demonstration  Demonstration brief  distributing a demo script to the audience helps following the demo  GUI Demo  Command line demo

T Iteration demo 17 DEMO SCRIPT FOR OSLC GUI  Use the Azureus package as an example  Open the package, demo progress indicator. While it unpacks tell something about the UI design decisions  CLI for power users  GUI for everyone (Browser paradigm, tree for navigation, keep it uncluttered, overview for global results, tree&preview panel for details)  Show file contents, click ChangeLog.txt, point out "not a source file"  Toggle overview, toggle word wrap  Demo scalability, drag the splitter around  Explain the overview panel  Explain the tree view  Icons with red indicators -> conflicts  Surf to EntityHandler  Expand node, show conflicts  Double click EntityHandler  Point out conflicts  Click details  Double click AEMonitor, point out the "hyperlink"-behavior

T Iteration demo 18 DEMO SCRIPT FOR OSLC Command Line  Handles the same file formats as the GUI version  Easy to use oslc2cli [path to files]  Configurable output  Found licenses  License conflicts  File dependencies (references)  Summary of results  Help screen!

T Iteration demo 19 Thank you very much Questions or Comments?