1 / 62

DOCVIEWER

DOCVIEWER. FPP | 10 th December 2009 | IKARUPROJECTS. Agenda. Introduction Project Overview Architecture and Design Demo Process Planning and Tracking Reflection. Introductions. Client Bharat Gorantla Mentor Phil Bianco Team iGreen Sai Sharan Donthi Vignesh Murugesan

dante
Download Presentation

DOCVIEWER

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. DOCVIEWER FPP | 10th December 2009 | IKARUPROJECTS

  2. Agenda • Introduction • Project Overview • Architecture and Design • Demo • Process • Planning and Tracking • Reflection Team iGreen

  3. Introductions • Client • Bharat Gorantla • Mentor • Phil Bianco • Team iGreen • Sai Sharan Donthi • Vignesh Murugesan • Vikram Subramanian Team iGreen

  4. Project Overview Microsoft Office, Adobe Reader, Open Office, ?? Internet PDF PPT DOC ODT Learner Teacher Data Transfer Team iGreen

  5. Goals • Business Goals for IKaru Projects • Develop a universal document viewer • Make IKaru 'The You Tube of Education’ • Enable development beyond the organization borders. • Project Goals • Develop document converter and viewer that supports popular document formats • Provide them as a documented API that can be hooked into the client application and extended to add new features. Team iGreen

  6. Context Diagram Viewer Web Application Converter Legend Developed by Team iGreen Client Application Uses Team iGreen

  7. C&C View Team iGreen

  8. Viewer Design Spoke indicates a new screen Team iGreen

  9. Deliverables Team iGreen

  10. DocViewer - Demo Team iGreen Team iGreen

  11. Process • Extreme Programming • Pair Programming • Process for Bug Tracking • Google code repository • Continuous Risk Management | SRE • Risk Identification – At the beginning of Iteration • Risk mitigation strategies | Contingency plans immediately Team iGreen

  12. Planning, Estimation and Tracking Team iGreen

  13. Planning And Estimation data • Planning Data • Available Number of Hours in Fall 09 : 504 hrs • Number of hours planned for : 485 hrs • (buffer included) • Number of hours kept in Buffer : 134 hrs • Number of iterations : 4 • 3 Iterations for ‘Must have’s • 1 Iteration for ‘Nice to have’ is the buffer Team iGreen

  14. Earned Value Analysis Deployment Iteration 4 Iteration 3 Iteration 2 Iteration 1 Deployment SAD SRS Iteration 4 SOW Iteration 2&3 Iteration 1 SRS & SOW SAD Planned Achieved Weeks Team iGreen

  15. Fall ‘09 EV Analysis Buffer completely utilized Backlog - Iteration 2 Backlog – Iteration 3 Team iGreen

  16. Effort Spent - Activities Team iGreen

  17. Reflections Team iGreen

  18. Reflections • Evaluation parameters of a POC  • Flex training plan  • Tracking enabled revisions in plan • Negotiation of must have features  • Re prioritization of features  • Re allocation of resources after second plan revision  • QAW helped us on focusing on client priority  • - Satisfactory |  - Excellent|  - Didn’t go well Team iGreen

  19. Reflections • Buffer time that spanned a complete iteration  • Lack of common timing hours  • Pair programming for critical features with code review  • Penalties work great in a flat team structure  • Roles and responsibilities made sure the team members were accountable  • Bug tracking system brought about a discipline in the team. • - Satisfactory |  - Excellent|  - Didn’t go well Team iGreen

  20. Client Feedback “The iGreen team did a good job in delivering an application that met our needs. The project posed a number of challenges, but the team overcame them with great enthusiasm and delivered it when it mattered. Overall, Sai, Vignesh and Vikram should be proud of the effort that they have put forward, and I have enjoyed working with them during these last 8 months. “ 1- Can Improve 2-Matched Expectations 3-Exceeded Expectations Team iGreen

  21. Thank You & Questions Acknowledgements: • Design and implementation inputs by Phil Bianco • Estimation and Tracking inputs - Eduaro Miranda • Risk Management inputs - Gil Taran • FPP guidance by Mel and Linda Pesante Bharat Gorantla for his excellent support Team iGreen

  22. Back Up Slides Back Up Slides Team iGreen

  23. Architecture Team iGreen

  24. Document Formats • Adobe PDF • Microsoft Word – doc & docx • Microsoft Powerpoint – ppt & pptx • Open Office Text Document - .odt & .sxw • Open Office Presentation - .odp & .sxi • Adobe Postscript • Microsoft Excel • Open Office Spreadsheet • Plain Text • Rich Text Format Team iGreen

  25. Module & Package View Team iGreen

  26. Allocation View Team iGreen

  27. Functional Requirements & QAs Performance – Priority 1 A 2MB File should be converted within 10 seconds Converter Extensibility – Priority 2 A newly developed document converter should be integrated in to the converter component within 40 person days . Team iGreen

  28. Constraints • Technical • Should be provided as an API to hook in to the client web application. • Should be developed using Java. • Business • Should be developed only using open source tools. • Should be developed in two semesters. Team iGreen

  29. C&C View Team iGreen

  30. C&C View Team iGreen

  31. Requirements Team iGreen

  32. Requirements Team iGreen

  33. Requirements Engineering • Requirements Development • Functional User Quality Attributes Technical • Business • Requirements Analysis • Prioritization of • Features Quality Attributes • Must Haves and Nice to Haves • Requirements Specification • IEEE SRS Format • Use cases for functional requirements • 6 part scenario documentation for quality attributes Team iGreen

  34. Process • Extreme Programming • Iterative delivery | Two semesters | Small Team • Project Characteristics • Selected Agile Life Cycle Model. • Frequent delivery & continuous client interaction • Short span of the project • Small Team • Possibility of changes in requirements Team iGreen

  35. Planning and Tracking Beware! So much of numbers Team iGreen

  36. Iterations and Features Team iGreen

  37. Tracking Process • Earned Value Tracking • Granularized Tasks | Effort | Value • Planned Value Baseline • Effort Available | Features | Iterations • Weekly Tracking and Backlog list • Planned Value Baseline | Earned Value for 2 weeks • Example : Once upon a time…in the next slide • Tracking helped us! • Backlog List | Allocation | Time box Team iGreen

  38. Estimated Effort Split-up Team iGreen

  39. Planned Effort for Phases Team iGreen

  40. Effort Spent on Phases Team iGreen

  41. Effort Split in Iteration 2 Team iGreen

  42. Effort split for Iteration 3 Team iGreen

  43. Effort Spent Split – Iteration 4 Team iGreen

  44. Reflections -Requirements • Quality Attributes  • Client was familiar with Quality Attribute Workshop, so we could directly start from • Business Goals • Scenario Brainstorming • Scenario Consolidation, Prioritization and Refinement • Identifying the system boundary and scope. • Clarity between technical constraints and quality attributes •  - Satisfactory |  - Went well |  - Didn’t go well Team iGreen

  45. Process Team iGreen

  46. Process Matrix Team iGreen

  47. Process Team iGreen

  48. Architecture Design Process Gather Architectural Drivers Identify Notional Architecture Apply ADD and Refine Architecture Develop Run-Time, Static and Allocation views Review Architecture Legend Activities Control Flow Team iGreen

  49. Implementation • Low – Level Design • Test Driven Development Team iGreen

  50. Project Management • People • Project Plan • Tracking and Revising Plan • Risk Management • Reflections Team iGreen

More Related