1 / 14

Distributed Monitoring & Mining

Distributed Monitoring & Mining. OMSE PRACTICUM I FINAL PRESENTATION. M arch 21, 2013. Thomas mooney shailesh shimpi ahmed Osman isaac pendergass. Architect . Project Manager . QA Manager/ Test engineer . Requirements engineer.

ezhno
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 I FINAL PRESENTATION March 21, 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 • Prototype and Demo • Lessons learned so far • Planned changes for next term • Upcoming plans

  4. Project Status • Deliverables • Planned • Project Proposal • Software Project Management Plan (SPMP) • Concept of Operations (ConOps) • Software Requirements Specification (SRS) • Prototype

  5. Project Status (cont.) • Deliverables • Completed • Project Proposal • Software Project Management Plan (SPMP) • Concept of Operations (ConOps) • Software Requirements Specification (SRS) • Prototype • In Progress • Software Architecture Document (SAD) • QA Plan/Test Plans • Metrics Document

  6. Prototype • Prototype Technical Details • ASP.net Application • MySQL Database • Mono Server for Deployment • SVN for Source Control • Assembla- Distributed Software Colloboration Tool • AssemblaProjects are called Projects Spaces • OAuth2 Authentication • Data downloaded from approximately 68,000 public project • Google Predictor - Prediction Engine • Firstly, the metric is trained with training data • Selected project space data is sent from DMM application • Predictor responses back with results (project is on track or failing)

  7. Demonstration

  8. Lessons Learned       “You can’t always get what you want.” • Initial metric definitions scrapped due to API restrictions. • Approximately half of secondary metrics unavailable due to incomplete project record entries. • Current Redmine usage confirms pattern. • Email preferred over forum communication. • Outside document revision systems preferred. • SkyDrive and Google Docs offer greater flexibility in terms of team collaboration. 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.

  9. Lessons Learned (cont.)            “…don’t let me be misunderstood.” • Less tractable communication issues arise more often from misinterpretation than from simple omission. • Special care must be taken to ensure that transmissions are precise and to the point. • Problems arising from misinterpretation are generally tougher to remedy as they are closer to the specific natures of the individuals involved. This is an important point as it serves to illuminate the main difficulty encountered in distributed development.  Learning to cope with deficiencies in communication will help our own effort as well as providing insight that may help our customers as well.

  10. Lessons Learned (cont.)                  “If you don’t know me by now…” • Inadequately Defined Problem Space • We had an idea, but needed more context. • Forced to explore problem space to get better understanding of requirements. • Delay in completion of SRS

  11. Planned Changes • Tightening of Process Controls • Adaptation of current process to reflect preferred modes of operation where possible. • Methods that do not promote our end goal will be discontinued and replaced. • Potentially increased usage of “Issues” feature in Redmine • Issue tracking • Responsibility tracking • Schedule

  12. Upcoming Plans • Finalizing the Software Architecture Document SAD • Developing the actual application with more development iteration • Use the requirements traceability matrix to keep track of the requirements and implementation and testing • Quality Plan • Establishing Quality plan • Adding integration testing and unit testing • Adding Deployment and packaging plans

  13. Upcoming Plans (Cont.) • Complete Infrastructure Build-out • Complete Risk Management activities • Implement Continuous Integration • Web Server Setup • Work with IT to enable database on Mono for local cache • Adding More Metrics • Adding tickets opened per milestones metrics and retrain the data at Google • Adding more seamless connection between The application and Google Predictive

  14. Questions?

More Related