Recent Changes - Search:

Project Status

Project Documents


Bug Tracking

edit SideBar




This project is intended to provide a software package for GW Scientific that will enable the importation, analysis, and QA/QC of meteorlogical sensor and operation data.


  • Facility to edit station and sensor profiles
    • Most likely a web application, although a GUI has not been ruled out.
  • Facility to define and create tests
    • Part of the above, but also entails a flexible architecture for defining tests.
  • Facility to import data
    • Uses station and sensor profiles
    • Imports data into the database so it is available to the QA/QC part of the software, as well as the data display and retrieval interface.
  • Facility to analyze data and send alerts on arbitrary conditions
    • Uses station and sensor profiles.
    • Analyzes data, and looks for data that fails tests defined in item two.
  • Facility to display graphs and data
    • 24-hour data tables
    • 7 day plots
    • Period of record plots
    • User-defined time plots and data

Assumptions and Constraints


  • The designers/programmers will have access to all needed documentation during the course of the project.
  • The designers/programmers will have access to all needed software and hardware during the course of the project.


  • Potential users (and future developers) of the software must have a working knowledge of the layout and operation of the sensor networks for which they are entering and editing rules and information.
  • Potential users (and future developers) of the software may need training in the programming language of choice in order to implement test plugins, as well as other plugins.
  • The software must function at a speed deemed reasonable on the given hardware.


Project Life Cycle

This project will, ideally, be completed with the scope of CS 690/691, and delivered, tested and demonstrated by May 1, 2007. The project will then become the property of EEI/GWS to do with as they wish.

Organization Structure

Committee Chair: Dr. Knoke

Co-chairs: Dr. Nance and Dr. Roth

Chief Designer/Programmer: Joshua Kugler

Co-programmer: Matthew Arnold

Matthew Arnold will be implementing things that do not fall directly in the scope of my project. These include HTML page generation, graph generation, page design, etc.

Risk Management

Changing requirementsModerateModerate, but depends on change scopeAfter requirements cut-off date, allowances will be made at project head's discretion. Changes deemed too large may be postponed until after completion of the Master's portion of the project.
Low quality softwareLowHighCareful planning, coding, and documentation
Unable to meet scheduleModerateHighOvertime, Scope re-evaluation
Loss of team memberLowHighIf I'm dead, the project might be too, but do best effort with documentation and training team members
Data not availableLowModerateSample data can be created. Years of data are already readily available.
Hardware incompatibilityLowHighWe are not working at the hardware level, so should not be an issue.
Product unusableLowHighWill be working closely with customer.


Resource Allocation

The most significant resource for this project is the time of the project team members, mostly the project head. Other resources are the knowledge of the EE Internet and GW Scientific personnel (especially the stakeholders), EEI/GWS documentation, past data records, and a readily available testing environment.


Testing will begin even before the project is in a usable state. Test driven development (TDD) will be used. This entails defining the tests to be run against various modules before they are even written. This also requires that interfaces be thought out in advance. While this does not preclude changes to the interfaces as implementation progresses, this does make sure that any changes made are tested, and that future changes to not break working code.


The final implementation of the software will be installed on EEI/GWS server and put into production. Full source code will naturally be made available to EEI/GWS to do with as they wish.


Project Planning: September 1 - September 30

Project Requirements: October 1 - December 3

Project Design & Test Plan: December 4 - January 15

Project Implementation: January 16 - March 12

Project Testing: March 13 - April 16

Project Documentation: September 1 - May 1


  • Implementation and testing will most likely overlap a fair bit for two reasons:
    • TDD will test functions an modules as they are written.
    • Testing will be done simply to "make sure things work" as they are written.


Edit - History - Print - Recent Changes - Search
Page last modified on February 06, 2007, at 11:45 PM