1 / 20

SunGuide SM Software – Florida's ITS Software ITS America Palm Springs, CA June 6, 2007

SunGuide SM Software – Florida's ITS Software ITS America Palm Springs, CA June 6, 2007. Trey Tillander, P.E. Florida Department of Transportation Intelligent Transportation Systems Program. First, some background info…. An Advanced Traffic Management Systems (ATMS) central software

clark
Télécharger la présentation

SunGuide SM Software – Florida's ITS Software ITS America Palm Springs, CA June 6, 2007

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. SunGuideSM Software – Florida's ITS SoftwareITS AmericaPalm Springs, CAJune 6, 2007 Trey Tillander, P.E.Florida Department of TransportationIntelligent Transportation Systems Program

  2. First, some background info….

  3. An Advanced Traffic Management Systems (ATMS) central software SunGuideSM provides…. Field ITS Device Control Event Management Road Ranger dispatch and monitoring Incident Management Incident Detection Incident Verification Incident Response Information Exchange between transportation agencies (Center-to-Center) Data collection and reporting Performance Measures What?

  4. SunGuideSM Software was designed and developed to…. Allow Statewide integrated use by being highly configurable (personalized) Promote software re-use to achieve economies of scale Allow flexibility and expansion by being modular Provide a high degree of supportability for long-term use with evolving technologies Comply with State and National standards to lower costs and risk What – Purpose

  5. Recommended by the FDOT/MDOT TMC Software Study, November 2001 Procured through an Invitation to Negotiate process Project Kicked Off on October 7, 2003 Initially Based on Texas DOT TransGuide and TRF Open architecture with open, documented interfaces Source Code owned by FDOT and TxDOT FDOT owns 21 Subsystems/11 Drivers, TxDOT owns 8 Subsystems/3 Drivers 614 Functional Requirements / 162 Sub-requirements Lines of Code: 1.7M SLOC What – Quick Facts

  6. SunGuideSM Release 3.0 Architecture

  7. When and Where – Deployments June 2005: Ft. Lauderdale November 2005: Miami October 2005: Jacksonville

  8. When and Where – Deployments October 2006: TERL - Tallahassee December 2006: Tampa October 2006: Orlando

  9. How does FDOT ensure quality for major software upgrades….

  10. Idea SunGuideSM Software Systems Engineering Process ConOps System Functional Requirements Specification Draft Functional Analysis System Requirements Review System Functional Requirements Specification Final Requirements allocation System / Software Design Document Preliminary Design Review Design a solution System Integration & Test Plan/Procedures Build it Critical Design Review Acceptance Test Report Deviations and Waivers Acceptance Test Plan/Procedures Test Readiness Review Test it Accept it Hot Wash-up

  11. ConOps: What – When – Who • Concept of Operations documents the User needs in a format understandable to the Users • ConOps describes the What, not necessarily the How • ConOps Document is based on IEEE 1362 – 1998 standard • Any FDOT ITS project using FHWA funds must follow the Statewide Statewide System Engineering Process (SEMP) • SunGuideSM Software development follows SEMP • Concept of Operations is initial systems engineering document developed by Users

  12. Requirements Traceability • Important so that no user need is missed and no additional expense is incurred building features that were not asked for • User needs come from many sources – ConOps is the best source if written by the Users • Requirements developed via consensus from 7 Districts and Florida’s Turnpike Enterprise IV&V FAT System function System design System behavior User Need Functional Requirements Specification System/Software Design Specification Test & Integration Plan/Procedures ConOps

  13. IV&V: What – When – Who • Independent Verification and Validation tests User Needs (ConOps) as interpreted into Functional Requirements • IV&V currently conducted for major Releases (i.e., Release 1.0, 2.0, 3.0, etc.) • Future FDOT IV&V efforts will include major upgrades (i.e., Release 3.1, 3.2, etc.) • IV&V conducted by FDOT Central Office and its Consultants • Conducted at an independent, non-operational FDOT test lab – Traffic Engineering Research Lab in Tallahassee • IV&V requires Time and $$$$’s (and patience)!

  14. Configuration Management • Baseline establishes the configuration for major steps in the development • Baseline freezes are used to manage scope creep • Baseline freezes establish the criteria that defines the end of each step and the start of the next in the development. • Four baselines are used: • Requirements baseline • Design baseline • Integration baseline • Production baseline • No changes to the configuration after a baseline freeze Milestone SRR PDR CDR (FDR) FAT / IV&V

  15. Change Management Process • Change Management Board consisting of representatives from 7 FDOT Districts, Florida’s Turnpike Enterprise, and 3 representatives from FDOT Central Office initially met on April 6, 2004 • Change Management Process for the Deployment of ITS in the State of Florida developed on April 12, 2005 • Current ITS programs under configuration management are Florida’s Statewide ITS Architecture and SunGuideSM Software • Statewide ITS Standard Specifications, primarily for field equipment, are anticipated to be put under configuration control in 2007

  16. Why is there a Change Management Board? • To control change of a program or project used by different users / stakeholders • To maintain the same level of quality in the project • To ensure the documentation on the project remains up to date • To review and approve changes to a program or project used by all the members of the CMB • To ensure we don’t violate license requirements for the software that we are re-using

  17. Role of CMB • CMB exists to provide direction and guidance, not to manage the program or project • CMB is representative of the project Users and is a way to ensure User input is captured • CMB focused on the What?, not the How? • Typically, CMB will approve or disapprove, via formal majority vote, System and Functional requirements • CMB meets at least 3 times per year, but during active program/project software development, meetings may occur as frequently as monthly • Meeting notes are documented and distributed to attendees

  18. Process for CMB • Review ConOps and decide what features are desired • Requirements are developed that express what functionality is desired • Review the functional and system requirements and decide if they clearly express WHAT is described by the ConOps • Design requirements are derived from the functional and system requirements that express HOW the system will do WHAT is required by the user

  19. On-line Web Resources • SunGuide SoftwareSM – http://www.dot.state.fl.us/TrafficOperations/ITS/Projects_Arch/SunGuide.htm • FDOT System Engineering –http://www.dot.state.fl.us/TrafficOperations/ITS/Projects_Deploy/SEMP.htm • FDOT Change Management –http://www.dot.state.fl.us/TrafficOperations/ITS/Projects_Deploy/CMB.htm

  20. Thank you!ITS AmericaPalm Springs, CAJune 6, 2007 Trey Tillander, P.E.Florida Department of TransportationIntelligent Transportation Systems Program

More Related