20
1 SunGuide SM Software – Florida's ITS Software ITS America ITS America Palm Springs, CA Palm Springs, CA June 6, 2007 June 6, 2007 rey Tillander, P.E. rey Tillander, P.E. lorida Department of Transportation lorida Department of Transportation ntelligent Transportation Systems Program ntelligent Transportation Systems Program

1 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

Embed Size (px)

Citation preview

1

SunGuideSM Software – Florida's ITS SoftwareITS AmericaITS America

Palm Springs, CAPalm Springs, CAJune 6, 2007June 6, 2007

Trey Tillander, P.E.Trey Tillander, P.E.Florida Department of TransportationFlorida Department of TransportationIntelligent Transportation Systems ProgramIntelligent Transportation Systems Program

2

First, some background info….First, some background info….

3

What?What?

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

4

What – PurposeWhat – Purpose

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

5

What – Quick FactsWhat – Quick Facts

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

6

SunGuideSunGuideSMSM Release 3.0 Architecture Release 3.0 Architecture

7

When and Where – DeploymentsWhen and Where – Deployments

June 2005: Ft. Lauderdale

November 2005:Miami

October 2005:Jacksonville

8

When and Where – DeploymentsWhen and Where – Deployments

October 2006: TERL - Tallahassee

December 2006:Tampa

October 2006:Orlando

9

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

10

SunGuideSunGuideSMSM Software Software Systems Engineering ProcessSystems Engineering Process

IdeaIdea

Functional Functional AnalysisAnalysis

Requirements Requirements allocationallocation

Design a Design a solutionsolution

Build itBuild it

Test itTest it

Accept itAccept it

ConOps

System Functional Requirements

Specification Draft

System Functional Requirements

Specification Final

System / Software Design Document

System Integration & Test Plan/Procedures

Acceptance Test Plan/Procedures

Acceptance Test Report

Deviations and Waivers

System Requirements

Review

Preliminary Design Review

Critical Design Review

Test Readiness

Review

Hot Wash-up

11

ConOps: ConOps: What – When – WhoWhat – 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 TraceabilityRequirements 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

User NeedSystem function

System design

System behavior

ConOps

Functional Requirements Specification

System/Software Design

Specification

FAT IV&V

Test & Integration Plan/Procedures

13

IV&V: IV&V: What – When – WhoWhat – 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 ManagementConfiguration 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

SRRSRRPDR PDR CDR (FDR)CDR (FDR)FAT / IV&VFAT / IV&V

Milestone

15

Change Management ProcessChange 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 Why is there a Change Management Board?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 CMBRole 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 CMBProcess 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 ResourcesOn-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 AmericaITS AmericaPalm Springs, CAPalm Springs, CA

June 6, 2007June 6, 2007

Trey Tillander, P.E.Trey Tillander, P.E.Florida Department of TransportationFlorida Department of TransportationIntelligent Transportation Systems ProgramIntelligent Transportation Systems Program