Define a vision for software operations upfront and follow sound systems engineering practices for successfully deploying a complex software system.

Experience from iFlorida Model Deployment

Florida,United States

Background (Show)

Lesson Learned

Some of the challenges faced by FDOT centered on limitations and failures of the Condition Reporting System (CRS) software. FDOT, aware of the problems with the CRS and anticipating the potential that it might fail, began testing SunGuide, a replacement for the CRS, in November 2006. First, FDOT installed an existing version of the SunGuide software and configured it to manage recently deployed ITS equipment on and near I-95. When the CRS failed in May 2007, FDOT began expediting a transition to this new software. By September 2007, FDOT was operating a Beta release of the SunGuide 3.0 software and sharing its operational experiences with the software developers. This close interaction enabled FDOT to continue to use the SunGuide software and regain the operational advantages that could not be obtained through the CRS. Lessons learned from this experience involving the software development process provide the following insights.
  • Follow sound systems engineering practices for successfully deploying a complex software system like the CRS. The CRS project began with high-level requirements defined, and the CRS contractor did not refine those broad requirements into more detailed ones. Systems engineering approaches that are less reliant on detailed requirements, such as a spiral model, were not employed. Inadequate requirements led to misunderstandings about the capabilities expected from the CRS and to insufficient testing of the software. The software development process spiraled out of control and ended with CRS software that was not usable and that ultimately was abandoned. Applying sound systems engineering practices more rigorously could have resulted in more usable code or helped FDOT more quickly determine that the contractor was not performing. Better requirement definitions up front might have prevented changes that occurred throughout the development phase. More stringent testing by the contractor might have identified problems earlier in the development cycle when they could be more easily corrected. Closer monitoring of this testing might have allowed FDOT to more quickly determine that the software was not meeting requirements.
  • Devote a significant amount of time at the beginning of a software development project to ensure that all parties share a mutual vision for how the resulting software should operate. The starting point of the CRS project was a set of high-level requirements developed by FDOT. A number of meetings were held between FDOT and CRS contractor staff to review these requirements. Despite this, the requirements often left room for interpretation, and differences of opinion between FDOT and the CRS contractor about how the CRS should operate continued throughout most of the time the CRS was under development. No mutual vision of how the software should operate was developed. With SunGuide, FDOT was provided with an early version of the software and FDOT configured the software to work with a set of recently installed FDOT hardware. FDOT worked directly with SunGuide technical staff to resolve difficulties and to define enhancements to current features needed to meet FDOT needs. This evolutionary approach resulted in a shared vision of how the software should operate.
  • Ensure that the software must be capable of interfacing with subsystems and the nature of the interaction must be well-defined. With the CRS, long-standing problems occurred with the interfaces between the CRS and almost every other external system with which it interfaced-the FHP CAD system, the weather provider, the travel time server, and the DMS signs. Only the interface between the CRS and the 511 system worked reliably.
These lessons from the iFlorida experience reveal the need for following sound systems engineering processes in developing a complex software system. Parties involved should take adequate time upfront to develop a mutually shared vision for how the final software system will operate interfacing with the subsystems. A well developed and functional software system is a key to achieving the desired improvements in efficiency and mobility in transportation operations.

Lesson Comments

No comments posted to date

Comment on this Lesson

To comment on this lesson, fill in the information below and click on submit. An asterisk (*) indicates a required field. Your name and email address, if provided, will not be posted, but are to contact you, if needed to clarify your comments.


iFlorida Model Deployment Final Evaluation Report

Author: Robert Haas (SAC); Mark Carter (SAIC); Eric Perry (SAIC); Jeff Trombly (SAIC); Elisabeth Bedsole (SAIC): Rich Margiotta (Cambridge Systematics)

Published By: United States Department of Transportation Federal Highway Administration 1200 New Jersey Avenue, SE Washington, DC 20590

Source Date: 01/30/2009

EDL Number: 14480

URL: https://rosap.ntl.bts.gov/view/dot/3977

Other Lessons From this Source

Lesson Contacts

Lesson Analyst:

Firoz Kabir


Average User Rating

0 ( ratings)

Rate this Lesson

(click stars to rate)

Lessons From This Source

Assess security risks, threats, vulnerabilities, and identify countermeasures to ensure operations of transportation management centers.

Be flexible to use data from various sources, such as the highway police patrol’s incident data, user feedback, and monitoring stations, to develop a statewide traveler information system.

Beware of challenges involved in developing an integrated statewide operations system for traffic monitoring, incident data capture, weather information, and traveler information—all seamlessly controlled by a central software system.

Beware of costs, utility, reliability, and maintenance issues in deploying a statewide transportation network monitoring system.

Beware of the limitations of using toll tags in order to calculate travel time on limited access roadways and arterials.

Beware that software development for ITS projects can be utterly complex, which demands avoiding pitfalls by following a rigorous systems engineering process.

Define a vision for software operations upfront and follow sound systems engineering practices for successfully deploying a complex software system.

Deploy a variable speed limit system only after the software systems required to support it are mature and reliable.

Design traffic video transmission systems around the constraints of bandwidth limitations and provide provisions for remote configuration of video compression hardware.

Develop an accurate, map-based fiber network inventory and engage ITS team in the construction approval process.

Develop an effective evacuation plan for special event that gathers a large audience and consider co-locating the responding agencies in a joint command center.

Ensure compatibility of data format of the field-weather monitoring sensors with the central software in the transportation management center.

Ensure that experienced staff oversee the development of a complex software system and thoroughly follow systems engineering process.

Ensure that Highway Patrol's CAD system operators enter key information needed by the transportation management center operators.

Establish a well defined process for monitoring and maintenance before expanding the base of field equipment.

Estimate life-cycle cost of ITS technologies as part of procurement estimates in order to assess the range of yearly maintenance costs.

In developing software for automated posting of messages on dynamic message signs, focus on the types of messages that are used often and changed frequently, and also include manual methods for posting.

Incorporate diagnostic tools to identify and verify problems in the transmission of video in a transit bus security system.

Perform adequate analyses and tests to design, calibrate and validate the capabilities of a bridge security monitoring system in order to reduce false alarms.

To support statewide traveler information services, design and implement reliable interface software processes to capture incident data from the local and highway patrol police’s computer aided dispatch systems.

Use simple menu choices for 511 traveler information and realize that the majority of callers are seeking en route information while already encountering congestion.

Application Areas

None defined




United States

Focus Areas

None defined

Goal Areas



None defined

Lesson ID: 2009-00486