Group 1 Remote Computer Monitoring System Nick Conway Doug Lother James Haggard Wes Reinhart 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 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) 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. 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. 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 Team Mr. Felix Hamza-Lup The RCMS Team Software Requirements Specification (USE Case Diagram) Compute CPU load utili zation Start Program Compute GPU load utili zation Fil e User Find free and used memory End Progra m Find ne twork data Output 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. 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.) Project Management Plan (Team Organization) Development Team: Documentation Team: Doug Lother Wes Reinhart Nick Conway James Haggard Scheduled weekly group and client meetings to increase chances of a successful project. 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. 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. Questions? Thank you for your time.