1 / 22

Distributed Monitoring & Mining

Distributed Monitoring & Mining. OMSE PRACTICUM II FINAL PRESENTATION. June 6 , 2013. Thomas mooney shailesh shimpi ahmed Osman isaac pendergass. Architect . Project Manager . QA Manager/ Test engineer . Requirements engineer.

mari
Download Presentation

Distributed Monitoring & Mining

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. Distributed Monitoring & Mining OMSE PRACTICUM II FINAL PRESENTATION June 6, 2013 Thomas mooney shailesh shimpi ahmed Osman isaac pendergass Architect Project Manager QA Manager/ Test engineer Requirements engineer

  2. … as software systems become more complex, automated analysis may be the only way that we can keep up with their size and scope.

  3. Our Purpose To augment current collaboration tools by collecting and modeling historical project data to alert project stakeholders when signs of trouble are detected. • Project Status • Architecture • Google Prediction Engine • Application Demonstration • Project Review • What’s next?

  4. Project Status • Deliverables • Planned • Project Proposal • Software Project Management Plan (SPMP) • Concept of Operations (ConOps) • Software Requirements Specification (SRS) • Software Architecture Document (SAD) • Software Quality Assurance Plan (SQAP) • User Manual • Metrics Document • Prediction Application

  5. Project Status (cont.) • Deliverables • Completed • Project Proposal • Software Project Management Plan (SPMP) • Concept of Operations (ConOps) • Software Requirements Specification (SRS) • Software Architecture Document (SAD) • Software Quality Assurance Plan (SQAP) • User Manual • Metrics Document • Prediction Application

  6. Architecture • Architectural Highlights– Goals and Constraints • Useful to future architects and designers • Written with MS .NET, but deployed with open source technologies (Mono, MySQL). • Interfaces with 3rd party APIs (Google, Assembla). • Minimize the impact of anticipated changes • Changes to the Assembla API • Changes to the Google API • Changes to the metrics used to construct the predictive model • Changes to the content of the prediction report.

  7. Architecture – Components

  8. Google Prediction Engine • What is Google Predictive API ? • The Prediction API provides pattern-matching and machine learning capabilities. Given a set of data examples to train against. • It is using supervised learning • It uses classification and regression pattern recognition • https://developers.google.com/prediction/docs/getting-started • Why do we use it? • We need to classify projects either in risk or in the right path • Free to use (for 6 months) and has many API flavors (.NET, python …)

  9. Google Prediction Engine • How is it working?

  10. Demonstration

  11. Project Review       Model Fidelity • Probably the most important aspect • How do we define success? • Is it constant? • DMMs Criterion: • 75% of completed milestones, completed on-time.

  12. Project Review Metrics Selection • The “right” metrics are not always available. • Extra care and, in some cases, additional infrastructure is required in the gathering of the metrics and their handling during analysis. • Extending the system to support more repositories increases this challenge due to differing formats. • Repository usage does not always reflect serious development effort. We must choose metrics based on data that has a reasonable probability of being recorded in order to build models that are useful in determining user-project status.

  13. Project Review  A Look at the Metrics • Total Number of Milestones • Opened Tickets per Milestone • Closed Tickets per Milestone • Abandoned Tickets per Milestone • Average Ticket Priority • Opened Tickets per Day • Mean Time Between Tickets • Mean Time Between High Priority Tickets

  14. Project Review (cont.)       Organization • Roles assigned on volunteer basis • Vote would be cast in the event two members wanted same role • Every voice held the same weight • Design and Development Infrastructure • Documents housed on Skydrive • Wiki Contains references to all documents and project information • Mirrored code repository • Continuous Integration Server

  15. Project Review (cont.)       Communication • Decided to perform duties in distributed manner • The DMM Team has never met face to face • Email supplanted forums to become main medium of communication • Relatively few misunderstandings • Always held meetings for issues that required "complex" communications

  16. What's Next? • Increase metric relevancy and quantity • Incorporate auto-notification scheme • Provide more reporting options • Provide mechanism for user defined analysis

  17. Questions?

  18. DMM Home Page

  19. Assembla Login Screen

  20. Select Project Space

  21. Analysis Report

  22. PDF Report

More Related