1 / 49

DOCVIEWER

DOCVIEWER. MPP | 6 th August 2009 | IKARUPROJECTS. Agenda. Introduction Overview Architecture Planning and Estimation Reflections Next Step. Introductions. Client Bharat Gorantla Mentor Phil Bianco Team iGreen Sai Sharan Donthi Vignesh Murugesan Vikram Subramanian.

gibson
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 MPP | 6th August 2009 | IKARUPROJECTS

  2. Agenda • Introduction • Overview • Architecture • Planning and Estimation • Reflections • Next Step Team iGreen

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

  4. Project Context 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’ • Present content the same way as the original document viewers. • 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. Accomplishments • Statement of Work & Project Proposal • Software Requirements Specification • Software Architecture Document • Iteration 1 • Converter API (PDF converter) • Documentation for Converter • Viewer Prototype Delivered Team iGreen

  7. SDLC & Process • Project Characteristics • Frequent delivery & continuous client interaction • Short span of the project • Small Team • Possibility of changes in requirements • Selected Agile Life Cycle Model. • Extreme Programming • Suits the project characteristics as per “Choosing your weapon wisely” Team iGreen

  8. System Context Web Application Viewer Converter Legend To be Developed by Team iGreen Client Application Uses Team iGreen

  9. 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

  10. 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

  11. C&C View Team iGreen

  12. C&C View Team iGreen

  13. Project Plan • Planning Process • Interim plan initially • Quickly develop the MACRO plan • Delphi Estimation Method • Activities | ‘Expert’ Opinion | Consensus • Granularized Activities and Tasks for Tracking • Release Plan & Iterations Plan • Requirements | Iterations | Plan Team iGreen

  14. Planning And Estimation data • Planning Data • Available Number of Hours : 1198 • Number of hours planned for : 1013 • Number of hours kept in Buffer : 185 • Number of iterations : 4 • 3 Iterations for ‘Must have’s and 1 Iteration for ‘Nice to have’ Team iGreen

  15. 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

  16. CPV Vs. EV and Actual Effort Deployment Iteration 4 Iteration 3 Iteration 2 Iteration 1 SAD Planned SRS SOW ITR - 1 Achieved Iteration 1 SRS & SOW SAD Weeks Team iGreen

  17. Iteration 1 EV Analysis Value Achieved! Backlog: Task1 Task2 Task3 Task4 . . . Team iGreen

  18. Reflections • Quality Attribute Workshop  • Scope | Clarity between technical constraints and QA’s. • Extreme Programming • Spike Solutions • Technical Feasibility | Estimation for Iteration 2  • Technology Experiments GWT and SVG  • Test Driven Development  • IEEE specification for SRS and SAD | Use cases   - Went well |  - Satisfactory |  - Didn’t go well Team iGreen

  19. Reflections • Lack of discipline in recording effort data  • Should have applied right at the start  • Penalties and Randy Pausch Time-log Sheet for effective tracking  • Continuous RMMM at an early stage  • Tracking helped us to come back on schedule  • Effort Tracking Repository   - Satisfactory |  - Went well |  - Didn’t go well Team iGreen

  20. Reflections - Experts • QAW facilitated by Phil Bianco and Matt Bass • Architecture Review by Phil Bianco and Tony Lattanze • Estimation and Tracking by Eduaro Miranda • Process selection guidance by Mel RossoLlopart • Risk Identification session by Gil Taran • MPP guidance by David Root and Linda Pesante • Shigeru and Siddharth for their inputs Team iGreen

  21. Next Step • Pair Comparison for Iteration 2 • Pair Programming • Focus on quality assurance • Smiling customer , Happy mentor and Cohesive team Team iGreen

  22. Client Feedback • “The IGreen team has done an excellent job in creating an application that meets with both IKaru’s product and business goals. It must not have been easy for the team to interact with a client who is remote, but the team did a great job in managing the meetings and being flexible at the same time. I am very pleased with the effort that the team has made so far. “ 1- Can Improve 2-Matched Expectations 3-Exceeded Expectations Team iGreen

  23. Thank You Team iGreen

  24. Back Up Slides Back Up Slides Team iGreen

  25. 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

  26. Requirements Team iGreen

  27. 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

  28. Requirements • Functional Requirements – 13 • Business Constraints - 2 • Technical Constraints – 2 • Quality Attributes Team iGreen

  29. Functional Requirements • Functional • Support multiple formats • Convert document from source to target format • Layout of should be similar to any other reader Team iGreen

  30. User Requirements • User Requirements • Full Screen and Regular Modes • Search Text • Highlight Text • Copy Text • Pagination • Zoom • Save Original Document • Print Document • View Meta Data of the project • Embed Link Team iGreen

  31. Iterations and Features Team iGreen

  32. 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

  33. Process Matrix Team iGreen

  34. Process Team iGreen

  35. 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

  36. Module & Package View Team iGreen

  37. Allocation View Team iGreen

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

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

  40. People • Team iGreen is self-organized • Roles and Responsibilities • Roles - SAI | VIGNESH | VIKRAM – No Team Leader • Single role and multiple responsibilities • Cross Functionality and Team Work • Review Processes • Artifact is baselined with one round of Internal Review • Code | Unit tested | Peer Reviewed | Team Code Review Team iGreen

  41. Planned Effort for Phases Team iGreen

  42. Effort Spent on Phases Team iGreen

  43. Effort Split in Iteration 1 Team iGreen

  44. What Now? • Analyze why the Earned Value is more/less • Productivity | Estimation | Process • Activities that have not added value but consumed effort • Backlog List | Buffer Time | Allocation | Time-box • Update the Project Overhead Activities / Tasks • Estimate and revise plan • Steps to achieve productivity • Training | CPI| Evaluation | Feedback Team iGreen

  45. Project Plan • Planning Process • Interim plan initially • Quickly develop the MACRO plan • Delphi Estimation Method • Activities | ‘Expert’ Opinion | Consensus • “Granularized” Activities and Tasks for Tracking • Release Plan & Iterations Plan - Deliverable based Planning • Requirements | Iterations | Plan Team iGreen

  46. Risk Management • Risk Management Process • Informal Risk Management Plan • Identify | Prioritize | Mitigate | Contingency plan • Learning FLEX |Unplanned activities| Delphi Estimation • For example: • FLEX is new | Learning curve| Training • Training is our mitigation strategy • Entry Criteria | Exit Criteria • No contingency plan for the Risk Team iGreen

  47. Risks • Risk1 • Condition: Team Not comfortable with flex. • Consequence: The team is still learning itMight not be able to estimate and not deliver certain components on time. • Risk2 • Condition: Configuration of the server machine where the client application runs is not elicited • Consequence: The performance of the converter might not satisfy the performance Team iGreen

  48. Wide Band Delphi • Architecture • Estimated – 71 hours • Actual – 125 hours • Iteration 1 • Estimated – 190 hours • Actual – 94 hours Team iGreen

  49. Iteration Value • Iteration 1 – 45% • Iteration 2 and 3 will achieve 55% Team iGreen

More Related