software development plan draft - …sunguidesoftware.com/.../stmcsls-sdp-1.0.0-draft.pdf ·...

Statewide Transportation Management Center Software Library System: Software Development Plan Draft STMCSLS-SDP-1.0.0-Draft

Prepared for: Florida Department of Transportation ITS Office 605 Suwannee Street, M.S. 90 Tallahassee, Florida 32399-0450 (850) 410-5600 November 25, 2003

Software Development Plan

STMCSLS-SDP-1.0.0-Draft i

Document Control Panel

File Name: STMCSLS-SDP-1.0.0.doc File Location: STMCSLS CM Repository CDRL: 2-4.1

Name Initial Date

Robert Heller, SwRI RWH 11/20/03 Created By: Steve Dellenback, SwRI SWD 11/23/03 Susan Crumrine, SwRI SBC 11/24/03

Reviewed By:

Modified By:

Completed By:


STMCSLS-SDP-1.0.0-Draft iii

Table of Contents

1. Scope.................................................................................................. 1 1.1 Document Identification............................................................................ 1 1.2 Project Overview ....................................................................................... 2 1.3 Related Documents ................................................................................... 3 1.4 Contacts ..................................................................................................... 3

2. Baseline Items ................................................................................... 5 2.1 Software Baseline Items ........................................................................... 5 2.2 Documents ................................................................................................. 5

3. Project Management ....................................................................... 12 3.1 Work Breakdown Structure .................................................................... 12 3.2 Project Schedule ..................................................................................... 12 3.3 Project Deliverables ................................................................................ 12 3.4 Staffing Plan............................................................................................. 12 3.5 Project Tracking ...................................................................................... 12 3.6 Risk Management Plan............................................................................ 13 3.7 Software Process Effectiveness Documentation ................................. 13

4. Development Procedures ............................................................... 14 4.1 Environment and Resources .................................................................. 14

4.1.1 Critical Computer Resources ...................................................14 4.1.2 Hardware Resources ................................................................14 4.1.3 Software Resources..................................................................15

4.2 Software Development Lifecycle............................................................ 16 4.3 Requirements Management.................................................................... 17 4.4 Analysis and Design................................................................................ 17 4.5 Coding ...................................................................................................... 19 4.6 Testing...................................................................................................... 19 4.7 Software Development Folders .............................................................. 20

5. Peer Review Plan............................................................................. 21

6. Configuration Management Plan (CMP) ........................................ 24

7. Software QA Plan (SQAP)............................................................... 25

8. Software Subcontracting Plan (SSP) ............................................. 26 8.1 PBF Statement of Work........................................................................... 26 8.2 Software Process .................................................................................... 27

8.2.1 PBF Internal Process................................................................27 8.2.2 PBF/SwRI Integrated Process..................................................28

8.3 Deliverables and Reporting Requirements to SwRI ............................. 28 8.4 Modifications to Statement of Work....................................................... 28


STMCSLS-SDP-1.0.0-Draft iv

9. Security Plan.................................................................................... 29

10. Notes................................................................................................. 30


STMCSLS-SDP-1.0.0-Draft v

List of Tables

Table 2.1 – Software Baseline Items .............................................................................................. 5 Table 2.2 – Project Documents....................................................................................................... 6 Table 3.1 – Project Reviews ......................................................................................................... 13 Table 4.1 – Hardware Resources .................................................................................................. 14 Table 4.2 – Software Resources.................................................................................................... 15 Table 4.3 – Software Development Lifecycle .............................................................................. 17 Table 4.4 – Requirements Management ....................................................................................... 17 Table 4.5 – Software Design Methodology .................................................................................. 18 Table 4.6 – Coding Standards....................................................................................................... 19 Table 4.7 – Software Test Plan ..................................................................................................... 20 Table 5.1 – Peer Reviews.............................................................................................................. 21


STMCSLS-SDP-1.0.0-Draft vi

REVISION HISTORY

Revision Date Changes 1.0.0-Draft November 25, 2003 Initial Release


STMCSLS-SDP-1.0.0-Draft vii

List of Acronyms

ADS............................Automation and Data Systems ATP............................Acceptance Test Plan BAFO.........................Best and Final Offer CCTV.........................Closed Circuit Television CD..............................Compact Disk CDRL.........................Contract Data Requirements List CMP ...........................Configuration Management Plan CMM..........................Capability Maturity Model DMS...........................Dynamic Message Sign DOT ...........................Department of Transportation DPM...........................Deputy Project Manager ECR............................Engineering Change Request ETLA .........................Extended Three Letter Acronym FDOT .........................Florida Department of Transportation HAR ...........................Highway Advisory Radio HTML ........................Hyper Text Markup Language ICD.............................Interface Design Document ITS..............................Intelligent Transportation Systems ITN.............................Invitation to Negotiate MS..............................Microsoft NTCIP........................National Transportation Communications for ITS Protocol ODBC ........................Open Data Base Connectivity OOAD........................Object Oriented Analysis & Design PBF ............................P.B. Farradyne PM..............................Project Manager QA..............................Quality Assurance RAID..........................Redundant Array of Inexpensive Disks RMP ...........................Risk Management Plan RWIS..........................Roadway Weather Information Station SCMP.........................Software Configuration Management Plan SDD............................Software Design Document SDF ............................Software Development Folder SDP ............................Software Development Plan SEI..............................Software Engineering Institute SEO............................Software Engineering Organization


STMCSLS-SDP-1.0.0-Draft viii

SCIP ...........................Software Integration Case Procedures SOW...........................Statement of Work SPM............................Software Project Manager SQAP .........................Software Quality Assurance Plan SRS ............................Software Requirements Specification SP ...............................Staffing Plan SSP.............................Software Subcontracting Plan STMCSLS..................Statewide Transportation Management Center Software Library System STR ............................Software Test Reports SVG............................Scalable Vector Graphics SwRI ..........................Southwest Research Institute TBD............................To Be Determined TDS............................Traffic Detection Subsystem TLA............................Three Letter Acronym TRR............................Test Readiness Review TSS.............................Transportation Sensor Subsystem TxDOT SDI ...............Texas Department of Transportation Statewide Development and

Integration UI ...............................User Interface WBS...........................Work Breakdown Structure WP..............................Work Plan XML...........................eXtensible Markup Language


STMCSLS-SDP-1.0.0-Draft 1

1. Scope

1.1 Document Identification This Software Development Plan (SDP) describes the plans for conducting the Florida Department of Transportation (FDOT) Statewide Traffic Management Center Software Library System software development effort. The SDP provides insight into, and a tool for monitoring, the processes to be followed for software development, the methods to be used, the approach to be followed for each activity, and project schedules, organization, and resources. Normally, the SDP produced by Southwest Research Institute (SwRI) contains all of the information that is used by the project management team to manage the project. Because of FDOT’s requirement to maintain this information in separate documents, the SDP that follows contains a number of references to other documents. For individuals who wish to gain insight into the SwRI project management process, each of the following documents will need to be reviewed (because combined as a “whole” they provide an overview of the project management approach):

Software Development Plan (SDP) Staffing Plan (SP) Detailed Work Plan (WP) Software Configuration Management Plan (SCMP) Software Quality Assurance Plan (SQAP) Risk Management Plan (RMP)

The Software Engineering Organization (SEO) of SwRI has been evaluated as a Level 3 organization in accordance with the Software Engineering Institute’s Capability Maturity Model. As a result of the Institute’s software process initiative, a formal project management approach has been defined; this approach has a number of activities that the project management team must perform to assure that the project is proceeding as planned. A high-level summary of what occurs over a life cycle of a project is as follows:

Develop process documents (SDP, SP, WP, SCMP, SQAP, RMP) Every four weeks:

o Hold a team meeting to discuss overall project status and detailed progress evaluations

o Review and update project schedule o Review and evaluate costs (determine cost to complete) o Document project status in project team meeting minutes (internal to SwRI) –

capture any significant changes in these minutes for discussion with SwRI management and the client (through the status report and status meeting)

o Hold a management meeting with SwRI management to discuss the project status o Develop status report for client o Hold a status meeting with the client

Bi-monthly basis: review project status with Software Quality Assurance Yearly: review the implementation of software process on the project



1.2 Project Overview

The Florida Department of Transportation (FDOT) is conducting a program that is developing an STMCSLS. The STMCSLS is a set of Intelligent Transportation System (ITS) software that allows the control of roadway devices as well as information exchange across a variety of transportation agencies. The goal of the STMCSLS is to have a common software base that can be deployed throughout the state of Florida. The STMCSLS development effort is based on ITS software available from both the states of Texas and Maryland; significant customization of the software is being performed as well as the development of new software modules. The following figure provides a graphical view of the software to be developed:

Figure 1.1 – High-Level Architectural Concept The STMCSLS development effort spans approximately two years. After the development, the software will be deployed to a number of Districts and Expressway Authorities throughout Florida and support activities will be performed.



1.3 Related Documents

The following documents were used to develop this document:

Southwest Research Institute (SwRI) Qualification Response: Response to the Invitation to Negotiate (ITN): Statewide Transportation Management Center Software Library System, Negotiation Number: ITN-DOT-02/03-9025-RR, SwRI Proposal No. 10-35924, dated: November 18, 2002.

SwRI Technical Proposal: Technical Proposal for Invitation to Negotiate (ITN): Statewide Transportation Management Center Software Library System, Negotiation Number: ITN-DOT-02/03-9025-RR, SwRI Proposal No. 10-35924, dated: January 31, 2003.

SwRI Cost Proposal: Cost Proposal for Invitation to Negotiate (ITN): Statewide Transportation Management Center Software Library System, Negotiation Number: ITN-DOT-02/03-9025-RR, SwRI Proposal No. 10-35924, dated: January 31, 2003.

SwRI BAFO letter: Southwest Research Institute Proposal No. 10-35924, “Invitation to Negotiate (ITN): Statewide Transportation Management Center Software Library System”, Reference: Negotiation Number: ITN-DOT-02/03-9025-RR, dated: May 5, 2003.

FDOT procurement document: Invitation To Negotiate (ITN), Negotiation Number: ITN-DOT-02/03-9025-RR, Statewide Transportation Management Center Software Library System, dated: October 21, 2002.

FDOT Scope of Services: Statewide Transportation Management Center Software Library System: Scope of Services, September 22, 2003.

FDOT Requirements Document: Statewide Transportation Management Center Software Library System: Requirements Specification, June 3, 2003.

STMCSLS Project web site (contains schedule and various planning documents): http://stmcsls.datasys.swri.edu

1.4 Contacts The following are contact persons for the STMCSLS project:

Chester Chandler, ITS Central Office, [email protected], 850-410-5600 Liang Hsia, FDOT Project Manager, [email protected], 850-410-5615 John Bonds, Senior ITS Specialist, [email protected], 408-873-2514 David Chang, ITS Specialist, [email protected], 850-410-5622 Steve Dellenback, SwRI Project Manager, [email protected], 210-522-3914 Robert Heller, SwRI Software Project Manager, [email protected], 210-522-3824 Charlie Wallace, PBF Deputy Project Manager, [email protected], 352-374-6635 John Schumitz, PBF Software Project Manager, [email protected], 301-816-1852

The following are contacts that will be used by the STMCSLS project team to assure consistency with other FDOT projects and FDOT procedures:



Dan Baxter, PB Farradyne, FDOT C2C Project, [email protected], 407-587-7809 David Lambert, University of North Florida, RWIS, [email protected], 904-620-3881 Bob Colins, PBS&J, Emergency Evacuation, [email protected], 850-575-1800 John Fain, FDOT, Comptroller, [email protected], 850-921-7332 Jerry Bloodgood, McCain, Ramp Metering Leslie Jacobson, PB Farradyne, Ramp Metering, [email protected], 206-382-5290



2. Baseline Items The following sections contain tables listing the baseline items for each category of baseline material. The tables also indicate, where appropriate, which items will be delivered to the FDOT, which items will be peer reviewed, which items will be placed under Development or SEO configuration management, and the estimated size of the baseline item.

2.1 Software Baseline Items

Table 2.1 – Software Baseline Items Size

Software Baseline Item Baseline IdentifierEstimate Actual

Process Viewer TBD Small Status Logger TBD Small Data Bus TBD Large Map TBD Large User Interface TBD Large Dynamic Message Sign (DMS) Subsystem TBD Moderate DMS NTCIP Driver TBD Moderate DMS Mark IV Driver TBD Moderate Closed Circuit Television (CCTV) subsystem TBD Large CCTV NTCIP Driver TBD Large CCTV SunGuide Driver TBD Large CCTV American Dynamics Driver TBD Large Traffic Sensor Subsystem (TSS) TBD Large Traffic Detection Subsystem (TDS) BiTrans Driver

TBD Large

Incident Management Subsystem TBD Large Ramp Metering Subsystem TBD Large Roadway Weather Information Subsystem (RWIS) Subsystem

TBD Large

Archive Data Subsystem TBD Large Highway Advisory Radio (HAR) Subsystem TBD Large Web Server Subsystem TBD Large Emergency Evacuation Subsystem TBD Large Inventory and Maintenance Subsystem TBD Large

2.2 Documents Table 2.2 lists the baseline documents that will be generated during the project.



Table 2.2 – Project Documents

Document

Del

iver

able

CD

RL

Num

ber

Document Identifier

Due Date

SQA

R

evie

w

Cop

ies

to

SQ

A

Estim

ated

si

ze (p

ages

)

Act

ual s

ize

(pag

es)

Detailed Work Plan Draft 1-1.1 STMCSLS-WP-1.0.0-Draft Oct 21, 2003 35

Detailed Work Plan Final 1-1.2 STMCSLS-WP-1.0.0 Nov 19, 2003 50

Staffing Plan 1-2 STMCSLS-SP-1.0.0 Oct 21, 2003 25

Pert Schedule 1-3 STMCSLS-SCD-1.0.0 Nov 4, 2003 10

Gantt and CPM Summary Schedule 1-4 STMCSLS-SCD-1.0.0 Nov 4, 2003 10

Status Reports 1-5.n STMCSLS-SR-X.Y.0 See note 1 10

Kickoff Meeting Materials 1-6.1 N/A – PowerPoint slides Nov 6, 2003 100

Risk Management Plan Draft 1-7.1 STMCSLS-RMP-1.0.0-Draft Nov 4, 2003 25

Risk Management Plan Final 1-7.2 STMCSLS-RMP-1.0.0 Dec 2, 2003 20

Risk Management Plan Revision 1-7.2.n STMCSLS-RMP-1.n.0 As Necessary 25

Administrative Meeting Minutes Draft 1-8.1.n STMCSLS-AMM-n.0.0-Draft As Necessary 5

Administrative Meeting Minutes Final 1-8.2.n STMCSLS-AMM-n.0.0 As Necessary 5

Administrative Meeting Presentation Materials 1-8.3.n STMCSLS-AMP-n.0.0 As Necessary 30

Action Items 1-8.3n STMCSLS-AI-n.0.0 As Necessary 5

Software Requirements Specification Draft 2-1.1 STMCSLS-SRS-1.0.0-Draft Dec 3, 2003 75

Software Requirements Specification Final 2-1.2 STMCSLS-SRS-1.0.0 Jan 16, 2004 125



Document

Del

iver

able

CD

RL

Num

ber

Document Identifier

Due Date

SQA

R

evie

w

Cop

ies

to

SQ

A

Estim

ated

si

ze (p

ages

)

Act

ual s

ize

(pag

es)

Concept of Operations Draft 2-10.1 STMCSLS-COO-1.0.0-Draft Nov 25, 2003 75

Concept of Operations Final 2-10.2 STMCSLS-COO-1.0.0 Dec 23,2003 75

Output from Requisite Pro 2-2.n STMCSLS-PRO-n.0.0 See note 2 NA

Logical Database Design Preliminary 2-3.1 STMCSLS-LDB-1.0.0-Prelim Nov 27, 2003 30

Database Design Document 2-3.2 STMCSLS-LDB-1.0.0 Nov 7, 2005 75

Software Development Plan Draft 2-4.1 STMCSLS-SDP-1.0.0-Draft Nov 22, 2003 50

Software Development Plan Final 2-4.2 STMCSLS-SDP-1.0.0 Dec 20, 2003 50

Software Quality Assurance Plan Draft 2-5.1 STMCSLS-SQAP-1.0.0-Draft Dec 2, 2003 25

Software Quality Assurance Plan Final 2-5.2 STMCSLS-SQAP-1.0.0 Dec 30,2003 25

Software Security Plan Draft 2-6.1 STMCSLS-SSP-1.0.0-Draft Dec 9, 2003 25

Software Security Plan Final 2-6.2 STMCSLS-SSP-1.0.0 Jan 16, 2003 25

Software Design Document Draft 2-7.1 STMCSLS-SDD-1.0.0-Draft May 18, 2004 200

Software Design Document Final 2-7.2 STMCSLS-SDD-1.0.0 Jun 15, 2004 200

Interface Control Document Design (named “Interface Control Specification” in the Scope of Services)

2-7.3 STMCSLS-ICD-1.0.0-Design Nov 22, 2004 200

Interface Control Document Draft 2-8.1 STMCSLS-ICS-1.0.0-Draft Jan 13, 2004 200

Interface Control Document Final 2-8.2 STMCSLS-ICS-1.0.0 Feb 10, 2004 200



Document

Del

iver

able

CD

RL

Num

ber

Document Identifier

Due Date

SQA

R

evie

w

Cop

ies

to

SQ

A

Estim

ated

si

ze (p

ages

)

Act

ual s

ize

(pag

es)

Software Configuration Management Plan Draft 2-9.1 STMCSLS-CMP-1.0.0-Draft Nov 4, 2003 25

Software Configuration Management Plan Final 2-9.2 STMCSLS-CMP-1.0.0 Dec 2, 2003 25

Software Integration Plan Draft 3-1.1. STMCSLS-SIP-1.0.0-Draft Mar 5, 2004 25

Software Integration Plan Final 3-1.2 STMCSLS-SIP-1.0.0 Apr 2, 2004 25

Software Integration Plan Draft Update 3-1.3 STMCSLS-SIP-2.0.0-Draft Mar 9, 2005 25

Software Integration Plan Final Update 1 3-1.4 STMCSLS-SIP-2.0.0 Mar 9, 2005 25

Software Integration Plan Final Update 2 3-1.5 STMCSLS-SIP-3.0.0 Sep 9, 2005 25

Software Integration Case Procedure Draft 3-1.6 STMCSLS-SICP-1.0.0-Draft May 18, 2004 100

Software Integration Case Procedure Final 3-1.7 STMCSLS-SICP-1.0.0 Jun 18, 2004 100

Software Integration Case Procedure Final Update

3-1.8 STMCSLS-SICP-1.n.0 Sep 9, 2005 100

Software Acceptance Test Plan Draft 3-2.1 STMCSLS-ATP-1.0.0-Draft Mar 5, 2004 200

Software Acceptance Test Plan Final 3-2.2 STMCSLS-ATP-1.0.0 Apr 2, 2004 200

System Acceptance Test Plan Comments 3-2.3 STMCSLS-SATC-1.0.0 Receipt + 10d 15

Software Acceptance Test Corrective Action Plan

3-2.4 STMCSLS-CAP-1.0.0 FAT + 20d 20

Software Test Procedures Draft 3-3.1.n STMCSLS-STPr-1.0.0-Draft Jun 15, 2004 200

Software Test Procedure Final 3-3.2.n STMCSLS-STPr-1.0.0 Jul 20, 2004 200

Software Test Report 1 3-4.n STMCSLS-STR-n.0.0 Sep 3, 2004 10

Training Plan 1 Draft 5-1.1 STMCSLS-TP-1.0.0-Draft Jun 25, 2004 25



Document

Del

iver

able

CD

RL

Num

ber

Document Identifier

Due Date

SQA

R

evie

w

Cop

ies

to

SQ

A

Estim

ated

si

ze (p

ages

)

Act

ual s

ize

(pag

es)

Training Plan 1 Final 5-1.2 STMCSLS-TP-1.0.0 Comments + 10d 25

Training Materials 1 5-1.3 STMCSLS-TM-1.0.0 Jun 25, 2004 100

Training Progress Report 1 5-1.4 STMCSLS-TR-1.0.0 Sep 3, 2004 25

Training Plan 2a Draft 5-2.1 STMCSLS-TP-2.0.0-Draft Jul 12, 2005 25

Training Plan 2a Final 5-2.2 STMCSLS-TP-2.0.0 Comments + 10d 25

Training Materials 2a 5-2.3 STMCSLS-TM-2.0.0 Jul 12, 2005 100

Training Progress Report 2a 5-2.4 STMCSLS-TR-2.0.0 Sep 20, 2005 25

Training Plan 2b Draft 5-3.1 STMCSLS-TP-3.0.0-Draft Sep 9, 2005 25

Training Plan 2b Final 5-3.2 STMCSLS-TP-3.0.0 Comments + 10d 25

Training Materials 2b 5-3.3 STMCSLS-TM-3.0.0 Sep 9, 2005 150

Training Progress Report 2b 5-3.4 STMCSLS-TR-3.0.0 Nov 18, 2005 25

Interface Control Document 6-1 STMCSLS-ICD-1.0.0 Sep 14, 2005 300

Functional Configuration Audit 6-2 See note 3 Sep 28, 2005 NA

Final Acceptance Test Readiness Review 6-3 See note 3 Oct 3, 2005 NA

Hot Wash-Up Minutes (Comments) 6-4 STMCSLS-HW-1.0.0 Receipt + 5d 15

Final Acceptance Test Report (Comments) 6-5 STMCSLS-ATR-1.0.0 Receipt + 10d 15

Version Description Document 1 6-6.1 STMCSLS-VDD-1.0.0 Sep 7, 2004 40



Document

Del

iver

able

CD

RL

Num

ber

Document Identifier

Due Date

SQA

R

evie

w

Cop

ies

to

SQ

A

Estim

ated

si

ze (p

ages

)

Act

ual s

ize

(pag

es)

Version Description Document 2a 6-6.2 STMCSLS-VDD-2.0.0 Sep 21, 2005 40

Version Description Document 2b 6-6.3 STMCSLS-VDD-3.0.0 Nov 18, 2005 40

SUM Release 1 6-7.1 STMCSLS-SUM-1.0.0 Sep 7, 2004 50

SUM Release 2a 6-7.2 STMCSLS-SUM-2.0.0 Sep 21, 2005 125

SUM Release 2b 6-7.3 STMCSLS-SUM-3.0.0 Nov 18, 2005 150

Final Project Report NA STMCSLS-FRP-1.0.0 NA 25

Lessons Learned Report NA STMCSLS-LLR-X.0.0 NA 5

Team / Management Meeting Minutes NA STMCSLS-TM-X.0.0 NA 25

Notes:

1. Status reports are due 5 working days after the close of an SwRI accounting period. Each accounting period is 4 weeks in duration, giving 13 status reports during an SwRI fiscal year. FDOT has indicated to SwRI that it is acceptable to deliver status reports more often that required in the Scope of Services (which require them the first Monday of each month).

2. Output from Requisite Pro is required first with delivery of the Software Requirements Specification and then with delivery of each technical deliverable. SwRI interprets these to be the Software Design Document, Interface Control Documents, Database Design Documents and Version Description Document.

3. These items in the CDRL table, 6-2 and 6-3, are reviews not documents. They are included in this table for completeness though they require no delivery per se.

4. Many of the CDRL due dates are based on as yet unscheduled reviews minus some delta in days. The dates within the table were computed based on the expectation that these reviews would occur as follows



Review Projected Date CDRLs Dependent on Date

Kickoff Meeting Nov 13, 200 1-6.1

Release 1 Software Requirements Review Dec 18, 2003 2-1.1, 2-1.2, 2-3.1, 2-4.1, 2-4.2, 2-7.1, 2-7.2, 2-8.1, 2-8.2,

Software Design Document Feb 03, 2004 3-1.1, 3-1.2, 3-2.1, 3-2.2

Training Aug 20, 2004 5-1.1, 5-1.2, 5-1.3, 5-1.4

Release Sep 7, 2004 6-6.1, 6-7.1

Release 2a Training Sep 6, 2005 5-2.1, 5-2.2, 5-2.3, 5-2.4

Release Sep 21, 2005 6-6.2, 6-7.2

Release 2b Functional Configuration Audit Sep 28, 2005 6-1

Training Nov 04, 2005 5-3.1, 5-3.2, 5-3.3, 5-3.4

Release Nov 18, 2005 6-6.3, 6-7.3

5. Some deliverables, most marked Final, are due after a cycle of comments. Comments are to be received from FDOT, then after receipt of the comments, SwRI is obligated to revise and reissue a document in Final form.

6. Two deliverables, 6-4 and 6-5, are comments on FDOT produced documents. Their deliveries are based on receipt of those documents.



3. Project Management

3.1 Work Breakdown Structure Refer to the STMCSLS Detailed Work Plan Document, Document identifier: STMCSLS-WP-X.X.X where X.X.X is the current version number; the initial delivery was STMCSLS-WP-1.0.0.

3.2 Project Schedule Refer to the STMCSLS Schedule Document, Document identifier: STMCSLS-SCD-X.X.X where X.X.X is the current version number; the initial delivery was STMCSLS-SCD-1.0.0.

3.3 Project Deliverables Table 2.2 contains a list of project deliverables and due dates.

3.4 Staffing Plan The staffing and training plan is contained in the STMCSLS Staffing Plan document, Document identifier: STMCSLS-SP-X.X.X where X.X.X is the current version number; the initial delivery is STMCSLS-SP-1.0.0.

3.5 Project Tracking This section describes how the project will perform activities related to cost, schedule, and resource management.

Each month the SwRI project management perform monthly financial and schedule analysis. This analysis is performed at the task level and below and consists of evaluating several cost and schedule factors.

Schedule analysis examines start date, completion date, and task completion percentages. New task completion data projections are performed if necessary based on availability of staff. Finally, the new projected completion dates are compared to the project/release critical path. If necessary, adjustments in resources are made to counter possible adverse effects on overall schedule.

Cost analysis examines task budget, task funds expenditure, task funds remaining and task completion percentage. Those tasks that are expending funds faster than work is being completed are flagged for further investigation. Adjustments may be made in resources to rectify adverse spending curves.

The results of these analyses are reported monthly to SwRI management through management meetings and to FDOT through monthly status reports.

Table 3.1 lists the reviews that will be conducted during the development period of the project. For each type of review, the frequency (e.g., weekly, monthly, quarterly, every four weeks, mid-project) and attendees are shown. The number planned and number held will be recorded in the management review minutes.



Table 3.1 – Project Reviews Number Reviews

Review Type

Parties Involved

Frequency Planned Actual Periodic Team PM, SPM, project team members Four-weeks 27 Event-driven Team

PM, SPM, project team members As-needed 20

Periodic Management

PM, SPM, section manager Four-weeks 27

Event-driven Management

PM, SPM, section manager As-needed 6

Lessons Learned

PM, SPM, section manager, process specialist, director

Annually 2

FDOT Status Report Meeting

FDOT representative(s), project manager, deputy project manager, software project manager, section manager.

Monthly 25

3.6 Risk Management Plan Refer to the STMCSLS Risk Management Plan, Document identifier: STMCSLS-RMP-X.X.X where X.X.X is the current version number; the initial delivery was STMCSLS-RMP-1.0.0.

3.7 Software Process Effectiveness Documentation The SEO collects various metrics about the effectiveness of the software process applied to a project. Updates to the SEO Historical Database will be made following each software release (1, 2a and 2b) so that comparisons between estimates and actuals can be recorded. Additionally, the process effectiveness questionnaire will be completed monthly by the SPM.



4. Development Procedures The following sections contain the development procedures that will be used on the project. These include the development environment and resources, the development lifecycle, analysis and design methods, coding standards, and testing methods.

4.1 Environment and Resources The following sections describe the hardware and software resources that will be used during the project.

4.1.1 Critical Computer Resources The only known critical computer resource is the project reliance on the SwRI Automation and Data Systems (ADS) Division backup procedures. As such the “development server” listed must be configured for inclusion in the ADS backups.

4.1.2 Hardware Resources Table 4.1 lists the hardware resources that will be used during the project.

Table 4.1 – Hardware Resources Description Supplier Owner Date

Required Purpose

6 Development PCs FDOT SwRI Other:

FDOT SwRI Other:

Within 2 weeks of contract award

Used for development

2 Laptop Computers FDOT SwRI Other:

FDOT SwRI Other:


Used for development as well as demonstration on FDOT locations

1 Development Server (RAID disks)

FDOT SwRI Other:

FDOT SwRI Other:


Used for software configuration management and development archives

3 Deployment test servers

FDOT SwRI Other:

FDOT SwRI Other:


Used for deployment testing

1 web server FDOT SwRI Other:

FDOT SwRI Other:


Support web site to be used for communication with FDOT

Mark IV DMS FDOT SwRI Other:

FDOT SwRI Other:


Used to test DMS driver



Description Supplier Owner Date Required

Purpose

American Dynamics Video Switch

FDOT SwRI Other:

FDOT SwRI Other:


Used to test CCTV video switch driver

Vicon NTCIP Camera FDOT SwRI Other:

FDOT SwRI Other:


Used to test CCTV camera driver

Pelco Camera with SunGuide converter

FDOT SwRI Other:

FDOT SwRI Other:


Used to test CCTV camera driver

RWIS station - NTCIP compliant

FDOT SwRI Other:

FDOT SwRI Other:


Used to test RWIS driver

4.1.3 Software Resources Table 4.2 lists the software resources that will be used during the project.

Table 4.2 – Software Resources Description Supplier Owner Date

Required Purpose

Microsoft Windows XP Workstation

FDOT SwRI Other:

FDOT SwRI Other:

2 weeks after NTP

Used on the development workstations

Microsoft Visual Studio FDOT SwRI Other:

FDOT SwRI Other:

2 weeks after NTP


Microsoft Visual Source Safe

FDOT SwRI Other:

FDOT SwRI Other:

2 weeks after NTP

Used on the development server for development CM

Java Development Environment

FDOT SwRI Other:

FDOT SwRI Other:

2 weeks after NTP


Install Shield FDOT SwRI Other:

FDOT SwRI Other:

2 weeks after NTP

Used to prepare distribution/install disks with each release

Rogue Wave FDOT SwRI Other:

FDOT SwRI Other:

2 weeks after NTP

Used on the development workstations for XML parsing



Description Supplier Owner Date Required

Purpose

XML Spy FDOT SwRI Other:

FDOT SwRI Other:

2 weeks after NTP

Used for XML definition as part of ICD development

Microsoft Windows 2000 Sever

FDOT SwRI Other:

FDOT SwRI Other:

2 weeks after NTP

Used on the servers

Microsoft Office XP FDOT SwRI Other:

FDOT SwRI Other:

2 weeks after NTP

Used for word processing

Microsoft VISIO FDOT SwRI Other:

FDOT SwRI Other:

2 weeks after NTP

Used to create design drawings

Microsoft FrontPage FDOT SwRI Other:

FDOT SwRI Other:

2 weeks after NTP

Used to manage the project web server

Rational DevStudio (contains a copy of all Rational products)

FDOT SwRI Other:

FDOT SwRI Other:

2 weeks after NTP

Used to manage requirements, issues, and software configuration management

Rational RequisitePro FDOT SwRI Other:

FDOT SwRI Other:

2 weeks after NTP

Used to manage requirements

Rational ClearQuest FDOT SwRI Other:

FDOT SwRI Other:

4 weeks after NTP

Used to manage issues

Rational ClearCase FDOT SwRI Other:

FDOT SwRI Other:

2 weeks after NTP

Used to implement software configuration management

Oracle Database Engine

FDOT SwRI Other:

FDOT SwRI Other:

4 weeks after NTP

Used for storage of initialization and runtime parameters for STMCSLS

Oracle Developer (contains Oracle Designer)

FDOT SwRI Other:

FDOT SwRI Other:

4 weeks after NTP

Used for logical and physical database design

4.2 Software Development Lifecycle Software development will occur in three releases: 1, 2a and 2b. Each release will follow a waterfall model. A large portion of the code to be delivered is not new code, but code that will be reused from that developed under the TxDOT SDI (Texas Department of



Transportation Statewide Intelligent Transportation Systems Development and Integration) Program. The reuse includes requirements, design, coding and test procedures. Hence, in release 1 there are no requirements or design phases for many of the reused modules. In this respect, the waterfall lifecycle is “tailored,” however those phases exist for other modules and the work product documents associated with those phases are produced and delivered (SRS, SDD, ICD, etc.).

Table 4.3 – Software Development Lifecycle Lifecycle Rationale

Waterfall Spiral Iterative Prototype Other: _____________ None applicable

The project as proposed and accepted by FDOT is based on three releases, each release building on the previous release with added functionality. The development cycle within each release is waterfall; consisting of requirements specification, design, coding and test.

4.3 Requirements Management

Initial system requirements were developed by FDOT and were included as an attachment to the Invitation to Negotiate (ITN). SwRI and PBF will derive testable requirements from those within the ITN Requirements Document. Those requirements will be entered into the Rational Requisite Pro requirements tracking tool with the original FDOT requirement set. Requirements will be documented as described in Table 4.4.

Changes in technical requirements will be entered into the Rational Clear Quest tool and may require contract modifications. Changes in program requirements (Scope of Services) will be documented via contract modifications.

Table 4.4 – Requirements Management Activity Method

Software requirements will be documented in the following manner:

Proposal, No SRS Other: Requisite Pro

Changes to requirements will be documented in the following manner:

ECR Letter Other: Clear Quest/Contract Modification

4.4 Analysis and Design A variety of analysis and design methods will be utilized during the design phase for STMCSLS project as noted in Table 4.5



Table 4.5 – Software Design Methodology Activity Method Rationale

The following design methodology(s) will be used:

OOAD Structured Functional

Decomposition Other:

Rationale: For existing documentation, the same methods used in the production of the original code (existing documentation) will be used to modify that documentation. For new code, either OOAD utilizing Rational Rose or Functional Decomposition using Microsoft Visio and Word will be used. The decision for which of these to be used will be made based on the expected code model to be produced. I.e., a module that is expected to be heavily OO in nature would naturally follow an OOAD methodology utilizing Rational Rose.

The following elements will be developed during the design process:

High-level design Detailed design User interface prototype

Rationale: High level and detailed design will be developed for all new development efforts. User Interface Prototypes will be developed and demonstrated to FDOT for approval.

Drawing tools: Visio Software Engineering tools: Rational Rose

The following techniques and products will be used to document the design: Documentation Tools:

Microsoft Word and Rational SoDA

Rationale: Final documentation (SDD) delivered to FDOT will be produced using Microsoft Word. Input to and conversion tools from Rational Products (SoDA) will be utilized as much as possible to avoid rework of existing artifacts.



4.5 Coding Table 4.6 shows the languages utilized and the coding conventions that will be applied throughout the project.

Table 4.6 – Coding Standards Language(s) Style Guide(s) Rationale C MFC SQL C++ X Windows ODBC Visual Basic TeleUSE ActiveX Java Other: PHP Other: XML Other: HTML Other: C#

SwRI Java Coding Standards Sun Javasoft Coding

Conventions SwRI C++ Coding Standards Ellemtel Telecom C++ Rules JMCIS Re-engineering

C/C++ Guide Indian Hill C Standard GUI Ltd Visual Basic

Standard Other: Other: SwRI C#

Existing code includes modules written in C++ and Java. New code development will be in C#. The browser based user interface may include Active X, PHP, HTML. Due to reuse, large amounts of pre-existing code will become part of the STMCSLS. Changes to that code will be made consistent with the existing coding standards used. Style guides for PHP, XML and HTML have not yet been determined.

4.6 Testing This section describes the software testing processes and procedures, which will be used on the project. The test objectives, strategies, test schedules, responsibilities, required resources, and reporting procedures for each level of testing are described in the following sections. Table 4.7 summarizes the test levels and attributes of each level.

All SwRI testing will make use of the project deployment servers. Use of these servers allows “clean install” testing to occur within our lab environment. Furthermore, sufficient “ITS field devices” are being procured to allow credible testing of device drivers and subsystems.



Table 4.7 – Software Test Plan Level Description

Objective: Establish the stability and reliability of the software at the individual computer software component (CSC) level. Responsibilities: Developer Documentation: SDF Location/Environment: Development lab. Test Exceptions: Corrected and retested.

Uni

t

Completion Criteria: Passes unit test. Objective: Integrate tested and baselined CSCs into a complete computer software configuration item (CSCI), and tune the system so that it operates as designed. Responsibilities: Development team under supervision of Integration Leader. Documentation: SDF. Responsibility of Integration Leader with developers to develop test strategy for integration testing. Applicable portions of Software Integration Case Procedures (SICP) will be run as well as tests to verify interfaces. Location/Environment: SwRI development lab utilizing SwRI ITS field equipment. Test Exceptions: Correct faulty software component, update and rerun unit test, Integration Leader will determine necessary regression testing (usually limited to subsystem under integration and other subsystems which it may “touch”, resume integration testing.

Inte

grat

ion

Completion Criteria: Successful completion of integration testing; dry run of Acceptance Test Plan (ATP). Objective: Ensure that the software meets the requirements as documented in the SRS (verification) and that it operates as intended in the target environment (validation). Responsibilities: Release 1 and 2a will be conducted by SwRI with FDOT witnesses. Release 2b will be conducted by independent team from FDOT with SwRI witness. Documentation: Release 1 and 2a test procedures documented in SICP developed by SwRI. Release 2b test procedures will be developed by independent agency and documented in an ATP. Test results will be documented in Hot Wash Up Minutes and Software Test Reports (STR). Location/Environment: Acceptance testing will be conducted at SwRI for Release 1. Subsequent releases are TBD. Test Exceptions: Test failures will be documented in STR and a Corrective Action Plan will be written to address retest issues.

Acc

epta

nce

Completion Criteria: Successful completion of the SICP (release 1 or 2a) or ATP (release 2b).

4.7 Software Development Folders Members of the software development team will maintain software development folders (SDF) that will document design decisions, unit testing, integration testing, etc. SDFs will be kept in paper or electronic form. Electronic SDFs will utilize any of the common documentation preparation tools available to team members including MS Office suite, MS Visio, or Rational suite of tools.



5. Peer Review Plan This section contains the peer review plan for the project.

Table 5.1 – Peer Reviews

Peer Review Method

Baseline Item or Portion of Baseline Item

Wal

k-th

roug

h

Man

agem

ent

Rev

iew

Form

al

Tech

nica

l R

evie

w

Bud

dy C

heck

Rationale

Detailed Work Plan Process document

review by PM, SPM and SM

Staffing Plan Process document


Pert Schedule Process document


Gantt and CPM Summary Schedule Process document


Status Reports Process document


Kickoff Meeting Materials Review by PM, SPM and SM

Risk Management Plan Review by PM, SPM and SM

Administrative Meeting Minutes Review by PM, SPM and SM

Administrative Meeting Presentation Materials

Review by PM, SPM and SM

Software Requirements Specification Walkthrough for team

Concept of Operations Review by PM, SPM and SM

Logical Database Design Preliminary Walkthrough for team

Database Design Document As built buddy check

Software Development Plan Process document




Peer Review Method


Wal

k-th

roug

h

Man

agem

ent

Rev

iew

Form

al

Tech

nica

l R

evie

w

Bud

dy C

heck

Rationale

Software Quality Assurance Plan Process document


Software Security Plan Process document


Software Design Document Walkthrough for team

Interface Control Document Buddy checked by

other subsystem designers

Software Configuration Management Plan Process document


Software Integration Plan Senior development team review

Software Integration Case Procedure Review by team

Software Acceptance Test Plan Review by team

Software Test Procedure Review by team

Software Test Report PM, SPM, SM review

Training Plan Utilize non-developers

Training Materials Utilize non-developers

Training Progress Report PM, SPM, SM review

Interface Control Document As built buddy checked

Hot Wash-Up Minutes (Comments) Process document


Final Acceptance Test Report (Comments) Process document


Version Description Document Walk through necessary

SUM Walk through necessary

Final Project Report Process document




Peer Review Method


Wal

k-th

roug

h

Man

agem

ent

Rev

iew

Form

al

Tech

nica

l R

evie

w

Bud

dy C

heck

Rationale

Process Viewer Exiting code very little modification necessary

Status Logger Exiting code very little modification necessary

Data Bus Includes ICD, design changes and code

Data Base Includes ICD, design changes and code

Map Includes ICD, design changes and code

User Interface Includes ICD, design changes and code

CCTV Subsystem Includes ICD, design changes and code

TSS Subsystem Includes ICD, design changes and code

DMS Subsystem Includes ICD, design changes and code

Incident Management Subsystem Includes ICD, design changes and code

C2C Subsystem Exiting code very little modification necessary

Ramp Metering Subsystem Includes ICD, design changes and code

RWIS Subsystem Includes ICD, design changes and code

Archive Data Subsystem Includes ICD, design changes and code

HAR Subsystem Includes ICD, design changes and code

Web Server Subsystem Includes ICD, design changes and code

Emergency Evacuation Subsystem Includes ICD, design changes and code

Inventory & Maintenance Subsystem Includes ICD, design changes and code



6. Configuration Management Plan (CMP) Refer to the STMCSLS Configuration Management Plan, Document identifier: STMCSLS-CMP-X.X.X where X.X.X is the current version number; the initial delivery was STMCSLS-CMP-1.0.0.



7. Software QA Plan (SQAP) Refer to the STMCSLS Software Quality Assurance Plan, Document identifier: STMCSLS-SQAP-X.X.X where X.X.X is the current version number; the initial delivery was STMCSLS-SQAP-1.0.0.



8. Software Subcontracting Plan (SSP) The SwRI Project Manager, Steve Dellenback has been assigned to manage the PBF subcontract; he has the responsibilities of the Software Subcontract Manager (SSM) as defined in the SwRI SEO procedures.

PBF was identified during the STMCSLS proposal development period as a software subcontractor. SwRI identified portions of the requirements for which PBF would be responsible. PBF provided cost estimates for this work scope during the proposal development period.

8.1 PBF Statement of Work.

Based on the SwRI Best and Final Offer scope of services, SwRI gave PBF a final statement of work. PBF provided a proposal to SwRI in response to that statement of work, and a subcontract has been issued to PBF for the statement of work.

The following tasks have been identified within the statement of work for PBF to perform:

Release 1:

• Project Management: Project management time needed of PBF to oversee development efforts. Project management should be a continuous process that is monitoring the cost and schedule of the development efforts. SwRI requests that the PBF project manager plan on attending at least 75% of the client status meetings (to be held in Tallahassee or other Florida locations) during the development period.

• NTCIP CCTV Driver: Provide device command/control/status of a NTCIP compliant CCTV device. This driver will be integrated into the SwRI provided CCTV subsystem.

• American Dynamics Video Switch Driver: Provide device command/control/status of an American Dynamics video switch. This driver will be integrated into the SwRI provided CCTV subsystem.

• BiTrans 285I-95 Traffic Detection Driver: Provide device command/control/status of detection devices using the BiTrans protocol. This driver will be integrated into the SwRI provided TSS subsystem.

• Incident Management: Develop an incident management subsystem which is based on the Maryland CHART incident management software. The subsystem shall be capable of receiving a “detection notice” (i.e. it is believed that an incident has occurred), generating a recommended response (with operator interaction) and then providing this response to other subsystems (provided by SwRI) so that the actual device change requests can be implemented.

• Testing Support: provide four (4) weeks of a PBF software developer on-site in the SwRI development laboratories.



Release 2:

• Project Management: Project management time needed of PBF to oversee development efforts. Project management should be a continuous process that is monitoring the cost and schedule of the development efforts. SwRI requests that the PBF project manager plan on attending at least 75% of the client status meetings (to be held in Tallahassee) during the development period.

• Archive Data Module: Develop a module that archives data from the Data Bus into a relational database (Oracle is FDOT’s database). Simple retrieval screens shall be provided so that the data archived can be queried.

• Ramp Meter Module: Develop a Ramp Meter subsystem that allows a user to alter the timing plans on a ramp meter device. This will require the management of ramp meter plans (stored in a database) as well as providing the capability to communicate with the Ramp Meter device driver.

• Web Server Module: Provide a web server application that is capable of displaying traffic conditions data on a Microsoft IIS server. The data for this module will be provided by the Data Bus and will include data such as: traffic conditions, video snap shots, incidents, lane closures, device status (e.g. message on a DMS sign).

• Testing Support: provide six (6) weeks of a PBF software developer on-site in the SwRI development laboratories.

8.2 Software Process

8.2.1 PBF Internal Process PBF has been assessed as a SEI CMM Level 2 organization and is actively pursuing SEI CMM Level 3. As such, PBF will utilize their internal processes augmented with processes from SwRI which constitute the delta between level 2 and level 3. Specifically, PBF will utilize their own internal processes for planning, resource management, development, testing (through unit and integration test), development configuration management, and software quality assurance.

SwRI expects the following to be performed by the PBF development staff:

• Maintain SDFs (Software Development Folders) at the subsystem level by each developer – electronic or paper are acceptable but SwRI prefers electronic SDFs.

• Peer Reviews: o PBF will peer review all new development (ramp metering server side “fuzzy

logic” algorithm). o PBF will peer review major modifications to existing code when judged

necessary or advantageous in opinion of PBF/SPM. • Coding standards:

o Modification or adaptation of existing code will use the coding standard previously used.

o For code development PBF will submit prepared coding standard to SwRI for approval.



8.2.2 PBF/SwRI Integrated Process SwRI is responsible for overall execution of the STMCSLS program. SwRI will integrate inputs from PBF as noted in the PBF SOW into documents to be submitted to FDOT. All work products will enter the STMCSLS baseline as described in STMCSLS-CMP-1.0.0. The acceptance testing described in this document is relevant to all software work products produced by PBF.

8.3 Deliverables and Reporting Requirements to SwRI

The following deliverables will be required by SwRI of PBF:

• Software • Design Documentation: high-level software design document • Monthly Status Reports, including:

o Activities performed during the reporting period o Activities planned for next two reporting periods o Issues that need resolution o Subcontractor expenditures

8.4 Modifications to Statement of Work

If changes are required to PBF's SOW, terms and conditions, or commitments, the affected groups must be made aware of the changes. Changes may originate with PBF, SwRI, or FDOT. All changes will be synchronized between PBF and SwRI.



9. Security Plan Refer to the STMCSLS Software Security Plan, Document identifier: STMCSLS-SSP-X.X.X where X.X.X is the current version number, the initial release will be STMCSLS-SSP-1.0.0.



10. Notes None.