By Thomas LeFebvre
The Rapid Prototype Project (RPP) is a collaboration between FSL developers and National Weather Service (NWS) forecasters at selected field offices to evolve the Graphical Forecase Editor Suite (GFESuite) software as quickly as possible. The project’s cornerstone is frequent communication between forecasters and developers via face-to-face meetings, conference calls, and electronic mail messages to convey opinions about various aspects of the GFESuite software. This communication plan results in software that is more efficient and effective at defining variables that represent the state of the atmosphere, from which forecasters create modernized graphical products.
In the AWIPS arena, software updates occur approximately every 6–12 months. Because AWIPS software requires several months of integration and testing, new software installed at a forecast office is nearly 12 months old by the time forecasters have the opportunity to comment on its usefulness. The long period between iterations made it very difficult to improve the software in a timely manner. The RPP attempts to solve this problem by providing software updates approximately every 6–8 weeks. Once the software is installed, users comment via conference calls and E-mail so that developers can receive rapid feedback. Software problems can be quickly resolved and delivered back to field weather offices so that users can see and test their suggested changes within hours, days, or weeks, rather than months or longer. This process leads to a rapid evolution of the software more directed toward its users.
From the beginning, the GFESuite software was targeted to run on the AWIPS platform. During the early years of development, a working group composed of forecasters from each NWS region met approximately every 9–12 months to learn about the new system and suggest new features and changes. Much was accomplished in the 3–4 years while this group met, and despite the fact that they met somewhat infrequently, the system quickly evolved.
In December 1996 the NWS made a decision to consolidate the GFE software with another IFP system called the Interactive Computer Worded Forecast (ICWF) system. Together these two systems were to provide a process by which forecasters would create gridded weather elements and then sample those elements to create the standard suite of NWS text products. Since the merging of these two disparate systems proved to be very complex and time-consuming, very little was accomplished in the area of new functionality for about 2 years. Nearly all of this time was devoted to simply "glueing" the two systems together. Developers could not spend much time enhancing the functionality, and very few forecasters were given an opportunity to use and comment on the system.
In June 1999 the the NWS Meteorological Services Division (MSD) chiefs from each of six regions met to discuss IFP and focus on a plan to accelerate the current schedule. They expressed genuine concern about the lack of progess with respect to modernized products. If the NWS did not radically modernize its product suite within the next few years, they feared that the public would no longer consider their services important and funding might soon decline. Another concern was that vast resources had been invested in the NWS modernization with little to show in the areas of new products and services. In their view, corrective action to the IFP program was required in order to accelerate its schedule so that a viable system could be delivered to NWS field offices in a shorter timeframe.
Recognizing that the GFESuite software had not been used in an operational setting, the MSD chiefs devised the RPP, whereby an experimental prototype system is installed at selected field offices. Forecasters use this system to define detailed digital weather elements in gridded form and then produce modernized graphical products. Once posted to a Website, these experimental products could be viewed by anyone with Internet access.
At the core of the RPP is the interaction between forecasters and software developers. Communication via e-mail messages, conference calls, and face-to-face meetings allow forecasters to convey their requirements directly to developers. Once tasks are identified, field forecasters prioritize them giving developers clear instructions on how to proceed. Once a significant number of requirements are implemented, a version of the software is made available to download via the internet. Forecasters then evaluate the changes and comment directly to developers, thus continuing the cycle. Each of these evaluate, comment, code cycles occur approximately every 6 to 8 weeks resulting in rapid evolution of the software. Since GFESuite is a component of AWIPS, the latest GFESuite software is included with each new AWIPS software build.
The RPP development team has accomplished much since its initiation. Focal points from each selected RPP office traveled to FSL for an intensive three-day training course. The course included familiarization with the GFE user interface, a session that covered how to configure the GFE and the database to meet the needs of the local forecast office, and a short course on the Smart Tools concept. By the time the training was completed, RPP focal points gained enough information to train forecasters at their local office. The computers on which RPP tasks are performed arrived shortly after the training. The focal points configured these systems for the local office and trained the forecasters who would be using the system to define meteorological fields and generate moderized products.
Since the project began, RPP forecasters and developers have met face-to-face two times, conference calls with focal points and developers have occured once per month, and the e-mail-based listserver has been very active with literally hundreds of e-mail messages posted to it regarding myriad issues.
The GFESuite has been installed in 15 NWS field offices to date (Figure 1). The RPP sites are scattered throughout the country so that forecasters from a variety of climate regimes can use it and provide feedback from a variety of perspectives. This feedback has led to many software changes, each of which helps make the GFESuite more efficient and easier to use. For example, the GFE menu layout before implementation of the RPP was organized into major functional categories. After the initial training, feedback from the field sites encouraged us to reorganize the menu such that the forecast process is easier to follow. Most forecasters now agree that the GFE is significantly easier to use than its predecessor. Table 1 documents the number of software changes of various categories that were made since the inception of the RPP. We estimate that less than 20% of those changes would have been made without valuable feedback from RPP forecasters.
The Rapid Prototype Project is less than a year old with forecasters using the GFESuite software for about 8 months. During this short time dozens of software bugs have been identified and fixed. The user interface has been reorganized to better support the forecast process. New approaches to editing gridded fields, such as Smart tools, have been further refined, making them easier to use and more powerful. All of those involved with the RPP consider it an unqualified success.
Defining the weather forecast as a set of gridded weather elements has not been done operationally before. The paradigm shift from expressing the forecast in text form to expressing the forecast as digital grids fundamentally changes the forecaster’s thought process. This radical shift in the way forecasts are produced demands that those using this new system continue to play a strong role in directing its evolution. The RPP makes this possible by bringing together the forecasters and developers and enhancing the communication between them. It is through frequent communication and immense cooperation that we have made rapid progress toward the eventual goal of nationwide digital forecasts.
(Tom LeFebvre can be reached at firstname.lastname@example.org or (303)497-6582.)