NRAO Home  >  Green Bank  |  Wiki Topic:    GB > Dynamic > SoftwareSuite

Changes | Index | Search | Go

GBT Dynamic Scheduling Software Overview

• A User's Perspective
• A Software Engineer's Perspective
• A Project Manager's Perspective

A User's Perspective

In addition to the policies, algorithms, and scheduling software needed to select candidate sessions for observing, the DSS also needs to provide a suite of support software which will ease the use of the Dynamic Scheduling System for both observers and Green Bank staff. This suite of software is primarily geared toward satisfying all of the support operations that go with dynamic scheduling. Most importantly, this suite of software should engage the observer in the dynamic scheduling process and ensure that he/she knows what is happening with his or her project at any given moment. This software suite includes, but is not limited to: a means for an investigator/observer to know the probability of his/her project being run in the near future, a means of ready communication among the observer, operator, scheduling software, and support staff regarding ongoing, future, and past observations, and easy means for observers to change their contact information and availability.

Quick Links:

• Astronomy requirements

A Software Engineer's Perspective

As noted in the User's Perspective above, the Dynamic Scheduling Software comprises much more than the scheduling algorithm proper. In fact, most of the code base is dedicated to user communication in the form of e-mails and web pages. Our starting point for the software suite was the JCMT/UKIRT software suite. Because the JCMT/UKIRT has experienced great success with their queue scheduling system and is also a single dish telescope, it is a good system from which to gain inspiration. The JCMT/UKIRT software engineers made a convincing case for the importance of the user support software (e.g. e-mails, web pages) for the simple reason that it is critical to keep the observer informed of their project's status in the dynamic scheduling system. Otherwise, the system becomes a frustrating black box. Based upon our discussions with the JCMT/UKIRT group, we put together an original concept for the software suite and then further refined it into a strawman software suite. The strawman software suite is what we are currently using as our plan forward for the Dynamic Scheduling Software. As we learn more, we will be evolving that page to track our current understanding of the requisite functionality. Although we are heavily drawing from the "lessons learned" at the JCMT/UKIRT, we have looked at other telescopes' dynamic scheduling systems as well. A listing of relevant reference materials from other telescopes/observatories can be found in our research into OtherObservatories.

As the project has progressed, we have evolved our approach to tackling the design and implementation of the software suite. Initially we attempted to create a software requirements specification, which pulled together requirements listed on various wiki pages as well as the memories of project team members. Although we had a relatively clear overall vision for the functionality of the system, the details were in a state of flux - much like building a structure on gelatin, firm but jiggly. At that time, we were also very early in the conceptual phase of the project and responding to NRAO staff comments. Because of a tight development timeline (testing of the initial system is scheduled for September 2007), we now are developing functionality in an iterative fashion. The iterative approach has served us well to date. We have prioritized functionality for the upcoming September 2007 tests (see ActionPlan for the full project timeline) and are working closely with scientific staff to flesh out requirements and to get quick feedback on our software products. By tackling the most important pieces of functionality first, we ensure that the upcoming tests this fall are focused to produce the most benefit from user feedback. We meet weekly with the project manager, KarenONeil, and biweekly with the entire project team. We also initiate other ad hoc meetings as necessary with other project team members, scientific staff, and other stakeholders.

We are leveraging a rapid web development framework, TurboGears, for the software suite. Our choice of TurboGears is based three factors: (1) JCMT/UKIRT successfully utilizes web interfaces to keep their observers well-informed of the dynamic scheduling process and we wish to achieve the same goal, (2) the Green Bank Software Development Division is already familiar with Python and has a significant Python code-base already established from which we can draw as needed, and (3) other Green Bank software products are already leveraging TurboGears (the BusinessOfficeSystem, the RfiDataBase Interface) and the e2e Division will be leveraging it to interface to the NRAO-wide User Database. TurboGears contains a built-in user authentication system called Identity. Initially, we plan to use Identity to control the viewable content for each user of the system. We believe that eventually we could directly use the AD domain (an NRAO user account domain) authentication instead of Identity. Observer applications will be written using TurboGears. At this time, it is unclear whether the administrative interfaces to the DSS for GBT operators and the Telescope Scheduler should also use TurboGears or be implemented as a standalone application.

We are also working hard to ensure that contact information for the Dynamic Scheduling software is shared with the Proposal Submission Tool and with the BusinessOfficeSystem (observers will use this software when making reservations for site visits). We will interface to the NRAO-wide User Database, which is a central repository for all static contact information for observers. The Dynamic Scheduling software has additional requirements for transitory contact information and black-out calendars which indicate when observers are not available for scheduling. In the case of the transitory contact information, the schema of the NRAO-wide User Database can be reused to capture this temporary information. Additional DSS-only tables will be created to capture the calendar information for each observer.

In addition to function, we have also identified several critical attributes which are required for the software suite. First and foremost, the software must support 24/7 operation. Secondly (and just about as important), the software must be easy to use. What we mean by "easy to use" is that project and scheduling information must be easily accessible to the users. This is accomplished in a number of ways which include utilizing familiarly-styled interfaces and minimization (or elimination) of repetitive data entry. Another critical attribute, which goes hand-in-hand with ease of use, is ensuring that the software keeps scheduling a transparent, open process for observers. To ensure satisfied users, we must keep observers informed of their project status at all times including the likelihood of scheduling their sessions in the short term. Finally, the software suite must protect proprietary project information; observer must be only allowed to view their own project and session information.

Quick Links:

• DSSSoftwareSuite - Description of the components of the Dynamic Scheduling Software Suite
• DSSSoftwareUseCase - Scenario of how the components of the Dynamic Scheduling Software Suite interact
• OtherObservatories - Dynamic Scheduling at other telescopes/observatories

A Project Manager's Perspective

See the SoftwareWorkBreakdownStructure.