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
- 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.
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: 14480URL: http://ntl.bts.gov/lib/31000/31000/31051/14480.htm
Average User Rating