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.