Group 1 Remote Computer Monitoring System

1
Group 1Remote Computer Monitoring System
Nick Conway Doug Lother
James Haggard Wes Reinhart
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 doesnt necessitate and timeline
  doesnt allow.
• Will test incremental builds on client machine.

13
Questions?

• Thank you for your time.

14
(No Transcript)