1 / 14

Group 1 Remote Computer Monitoring System

Group 1 Remote Computer Monitoring System. Concept of Operations (System Needs). The application must… Monitor CPU load for multiple CPUs Monitor RAM utilization Monitor GPU load Monitor network traffic Store the date/time for each of the above data points

wynne-gregory
Download Presentation

Group 1 Remote Computer Monitoring System

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. Group 1Remote Computer Monitoring System

  2. Concept of Operations(System Needs) The application must… • Monitor CPU load for multiple CPUs • Monitor RAM utilization • Monitor GPU load • Monitor network traffic • Store the date/time for each of the above data points • Collect data points for the above every 10ms • Write the data collected to a file on the hard drive • Monitor the above with minimal system load

  3. Concept of Operations(Current System, Modes, & Operational Scenarios) Current System • There is no current system being used. Users • One user to start, run, and stop the application. Modes of Operation • Startup (preconfigure data storage) • Running (collecting data) • Stopped (write out data stored in memory to file)

  4. Concept of Operations(Expected Impacts) Background • Client is developing a interactive 3D environment that 4 users on 4 different workstations can interact in a cooperative environment. Expected Impacts • Data collected will be used to tune applications to use the least amount of memory and system resources while maintaining a high level of quality.

  5. Concept of Operations(Proposed System Analysis) Disadvantages • No real time display of resource levels. • Monitoring application generates system load. Limitations • Data may be skewed because of load generated by monitoring app. Risks • Client could require a faster collection rate than kernel • The client might want to know values in close to real time. Alternatives • Develop a hardware based monitoring system.

  6. Software Requirements Specification(Introduction) Applicable Standards • The system must run on Red Hat 7.2 • Systems will be dual x86 processors w/ 1gb of RAM • The system proc files will be available to be read. Stakeholders • Optical Diagnostics & Applications TeamMr. Felix Hamza-Lup • The RCMS Team

  7. Software Requirements Specification(USE Case Diagram)

  8. Software Requirements Specification(Requirements) Documentation Requirements • To obtain maximum accuracy the system must take as many readings as possible without bogging down the system and therefore altering results. • A simple average formula will be used to show the system over time. Resource Requirements • Have the specification phase complete by October 3, 2003. • Have the design phase complete by October 21, 2003. • Have the integration phase complete by November 18, 2003.

  9. Project Management Plan(Applicable Standards) • We will be following the Coding and Documentation Standards of the CREOL Optical Development Lab. • Artifact Size Metric Standard • Size: LOC • Quality: number of faults detected • Other Size measurements less useful because of constraints on project (ie. limited time frame, budget, etc.)

  10. Project Management Plan(Team Organization) • Development Team: • Doug Lother • Wes Reinhart • Documentation Team: • Nick Conway • James Haggard • Scheduled weekly group and client meetings to increase chances of a successful project.

  11. Project Management Plan(Software Life Cycle Model) • Considered Waterfall, Build-and-Fix, and Incremental models. • Decided to use Incremental. • Small size & low complexity of project. • Waterfall – documentation more work than project necessitates, project not heavily document-driven. • Build-and-fix – client deserves better.

  12. Test Plan • Nature of project makes developing a test plan difficult. • Simulator? • Project scope doesn’t necessitate and timeline doesn’t allow. • Will test incremental builds on client machine.

  13. Questions? Thank you for your time.

More Related