1.      GENERAL












1.     General

The Electronic Toll System (ETS) Contractor (Integrator) will develop a detailed and comprehensive System Development Plan (Plan.) The Plan will describe the management methodology required to ensure that the I-680 Smart Lane (Smart Lane) system development work is conducted properly. The Plan will also include the Integratorís approach to managing the project and the planned software development and integration processes.

2.       Roles and Responsibilities

The Integrator will be solely responsible for designing and developing the Smart Lane software in a manner that complies with all of the functional system and equipment requirements presented in the RFP and the other contract documents.† The Integrator will make certain that the subsystem and full system integration process is conducted to ensure all requirements are met by the delivered tolling system.† The JPA will closely monitor and approve, in writing, all system design, integration, testing and deployment activities by the Integrator.

3.       Program Management Document

The Integrator will be requested to develop a Program Management Document (PMD) to provide the framework for developing and implementing the ETS for the Smart Lane in a controlled and managed environment.† The PMD will describe the project management goals, structure, methods, and reporting process that will be used to monitor and control the overall program.† The Integrator shall provide with the PMD a detailed Integrator Project Schedule.† The purpose of the PMD is to ensure that the Smart Lane ETS is delivered on schedule and within the established budget.

3.1         Referenced Project Documents

The PMD shall explain the relationships between the following documents, which will be developed subsequently on the Project:

         The Project Installation Plan;

         The System Verification (Test) Plan; and

         The System Design Documents, including the Preliminary Design Document (PDD) and the Detailed Design Document (DDD).

3.2         Program Management Approach

The Integrator will examine the technology risk areas and the management requirements that need to be considered as part of the PMD for implementing the ETS contract specifications within the stated time periods.† The Integrator will then detail all of the features and benefits of their program management approach to ensure that the system is delivered on schedule, within the established budget, and that it operates according to the system specification requirements.

4.       Program Management Implementation

4.1         JPA Program Responsibilities

Overall scheduling of all field construction activities will be under the direction of the JPA. †Caltrans will manage the roadway construction activities and has the responsibility to make sure that the roadway contractor coordinates work with the Integrator.† Resolution of any conflicts that might arise between the Integrator and the Caltrans contractor will be administered by the JPA.† The Integrator shall be responsible to the JPA for compliance with the ETS RFP and other contract documentation requirements, all drawings, work quality, project schedule, etc.† Any subsequent reference to the JPA in this document shall also include the possible involvement of their representatives.

4.2         JPA Weekly Meetings

It is expected that the JPA will conduct regular meetings with all contractors on the Smart Lane Project.† The meetings will typically be held weekly at a location to be determined by the JPA. †The purpose of the meetings will be to review the scheduling and coordination of each of the contractor's work within the requirements of the overall Smart Lane construction and implementation program.

The Integrator shall be involved with these meetings during the phases of the Smart Lane Program in which they will be involved.† The Integrator shall provide an on-site manager during the ETS equipment and system installation phase of the project.

4.3         Key Contacts

The key Integrator program contacts shall be listed in the PMD.† The list, which will be subject to approval by the JPA, will be updated as changes occur during the project. All requests for changes must be made in writing to the JPA. Approval by the JPA shall also be in writing. The Integratorís Program Manager, who shall also be approved by the JPA, will be made accessible to the JPA on a 24 hour-per-day, 7 day-per-week basis, either in person or via mobile telephone.

4.4         Integrator Project Schedule

The Integrator Project Schedule will define a normal design and development process, the timeline for required program phases and milestones, documentation deliverables, meeting dates, and other deliverables/milestones defined in the JPAís Overall Project Schedule (see 4.9 below).† To avoid any confusion, the approved JPA Overall Project Schedule will supersede all other schedule-related requirements presented by the Integrator on this project.† The Integrator Project Schedule shall include the system development activities, tasks, dates, and milestones described in Section 7 below.

4.5         Communications

The communication requirements between the Integrator and other project staff will be discussed at the Project Kick-Off Meeting.† The Integrator will communicate all project-related matters to the JPA and consultant staff as directed by the JPA ED.† The ED will determine whether to hold weekly conference calls with the Integrator and consultant staff, and when these calls will be held.

4.5.1        E-mail

E-mail will likely be the preferred method of communication for all program correspondence.† The Integrator Project Manager (PM) will be instructed as to which project staff should be copied on correspondence.

4.6         Status Reporting

The Integrator shall provide a Monthly Status Report to the JPA, to be submitted on the first working day after the 15th of each month.† Reports will be presented according to the status reporting requirements established in the RFP.

4.7         On Site Installation

The Integrator will develop an Installation Plan containing detailed plans and the management approach for the on-site installation team and related activities.† The Installation Plan will be subject to the review and approval of the JPA.

During the installation phase of the program, the Integrator will provide a resident installation manager accessible to the JPA from a local office.† This person is a local resource for the JPA, their engineers, and other contractors.† With direction from the Integratorís PM, the installation manager will assist and follow the program through the initial design, installation, and commissioning phases.† The installation manager will be knowledgeable in all aspects of the program, including scope, schedule, and systems.

4.8         Smart Lane System Testing

The Integrator will develop and provide detailed test documents in support of the various equipment and system tests that will be performed on this project.† The Integratorís test plans and test procedures will contain testing activities, criteria, and the management approach for all system testing, as presented in the System Verification (Test) Plan.

4.9         System Design and Development

Creation of the Smart Lane ETS, as detailed in the Integrator Project Schedule, will follow the V-Cycle Software Development system design and development process, as described below.† Project phases and milestones, including those specific to the Integrator, are defined in the Overall Project Schedule.† To avoid any confusion, the JPA approved Overall Project Schedule shall supersede all other schedule-related requirements and it must be adhered to by the Integrator.

4.9.1        Work Breakdown Structure

The Integrator will develop, submit and routinely update a comprehensive work breakdown structure (WBS), which will be used in the Integrator Project Schedule, and will separate large tasks into manageable units for all aspects of the required work to be accomplished by the Integrator. †The Integrator will be required to submit WBS details, when requested by the ED, that clearly and concisely describe all facets of the Smart Lane project administration, toll system design, system development, testing and implementation work that will be conducted.

4.10     Management Reporting and Monitoring

The Integrator shall be expected to use a range of management reports to track the progress of all work activities. †The PM will review reports to monitor each activity to troubleshoot real or potential schedule and budgetary issues so they can be addressed before they become problems.† When this analysis reveals that work on any single milestone is trending toward greater cost or time than planned, the report(s) will flag the problem, which will then be discussed by the PM with the ED.† In the event that there is an affect on the project cost and/or schedule, these issues can be immediately addressed by the JPA.

The Integrator will, on a monthly basis, re-assess the number of calendar days required to complete the remaining work of each task.† This assessment will identify the appropriate resources necessary to complete each task, in order to avoid shortages of resources.† To supplement the continuing evaluation of each work task, the critical path of the entire program will be evaluated at least monthly to identify any changes or potential scheduling problems.

The Integrator PM will be expected to organize their resources to complete the design, development, integration, test, installation, field test, and commissioning of the †Smart Lane ETS in accordance with the requirements in the RFP and the Contract documents.† The Integrator team will execute the program to fulfill the JPAís requirements.

4.11     Smart Lane Program Action Items

For the Smart Lane ETS, Integrator staff will record, monitor, and control all program action items.† The Integrator will be expected to track and provide the status of all action items on at least a weekly basis.

5.       SYSTEM Configuration Management

The Integrator shall provide strict configuration control on the Smart Lane ETS Project. †Any changes to the tolling system shall be approved, in writing by the JPA, and properly documented.† A method shall be used to identify the relationship of configuration items to the overall system.† System configuration guidelines shall be developed by the Integrator and a copy supplied, for review and approval, to the JPA.

Each configuration item, whether delivered to the JPA or only used internally by the Integrator, will be issued a control number from the system configuration management database.

5.1         System Configuration Approval

Each configuration document will have a specially formatted approval sign-off coversheet added.† The coversheet will clearly identify the document name, the control number, the project number, revision history, and a list of required names of those people that will be reviewing, providing comments and approving that specific document.† Adequate space will be made available on the form for signature and date.† The signed approval page will then be filed with the hardcopy of the document.† Once a document has been approved, an electronic file (PDF) will be made so that no further changes can be made.


The Integrator will check to make sure that all equipment, supplies, components, systems, subsystems, and any other services procured from subcontractors and vendors conform to the RFP and all other contract requirements. †These responsibilities include the establishment of procedures for the selection of qualified suppliers, the flow down of all system design and operating requirements, the internal technical evaluation of the procured item to ensure that it meets all necessary requirements, etc.

7.       integrator project schedule

A comprehensive Integrator Project Schedule detailing all system related development tasks, inputs and outputs, shall be submitted by the Integrator as part of the PDD phase of the ETS Development.† The Integrator Project Schedule shall be prepared using Microsoft Project, or an equivalent program that has been approved by the JPA, and will show easily measurable aspects of work that have clear requirements to be met within the indicated time frames established in the Overall Project Schedule.

If a Critical Path task begins to run behind schedule, all of the following Critical Path tasks might be altered, which would jeopardize all of the remaining work items under that category of the Integrator Project Schedule.† Therefore, all Critical Path items shall be kept on schedule by the Integrator.† To prevent Critical Path items from disrupting the Overall Project Schedule, the Integrator shall add any and all necessary project staff in order to keep those tasks from slipping.

8.       Software development

The software development process will ensure that the Smart Lane ETS operates according to the requirements outlined in the RFP and the Contract documents.† Software development procedures are typically represented by a phased, chronology-based model.† Each software development work phase corresponds to certain development activities, which need to be performed in a sequential manner to ensure program success.† The model that will be used on this Project for the software development process is the V-Cycle Model, which is presented below.








V-Cycle software development model.


The V-Cycle software development model involves a two phase process.† The first phase includes the development of the software (the downward leg) and the second phase pertains to the software integration and testing process (the upward leg).†

During the first phase, the initial task is to develop the software specifications, which is directly linked to the system functional requirements that are presented in the RFP and the Contract documents.† Once the specification is completed, the process leads directly to the preliminary and detailed design tasks.† Once the system design is complete, the Integrator then develops the actual software code.

The second phase of the software development process integrates the newly developed software with the system hardware to fully integrate the entire Smart Lane ETS.† To ensure that the system is properly integrated and complies with the various requirements, the software (and system) is subjected to an extensive test and validation process.† Once the testing process proves that the software is developed properly and is fully integrated into the entire tolling system, it will be ready to be deployed in a live environment.

8.1         Software Specification Development

At the beginning of the software development process it is important to verify and document the definition of requirements. This step allows for the correct development of the software specification.† The Integrator shall carefully define the various interfaces between the pieces of system hardware, between the internal subsystems and with external systems.† The Integrator shall also be required to separate the software development process into functional components and subsystems and define the information flow between the functions, sub-functions and subsystems.† At this point, the Integrator staff shall verify that the hardware and software requirements that are to be implemented are consistent with the required functionality of each component.

One of the most important tasks is to develop the Software Specification Document (SSD).† This initial work effort will clearly and comprehensively define all of the ETS related software requirements.† This would include each piece of equipment and subsystem in the tolling system, the roadside ETC antennas and readers, the tolling zone lane controllers, the vehicle detection station equipment, the video surveillance subsystems, the Mobile Enforcement Readers (MERs), the hand-held enforcement devices, the tolling zone beacons, the TDC hardware and software, the interfaces to the BATA RCSC and the FasTrak account management system, the interface to the Caltrans TMC, the interface to the MERs and held-held units, etc.

The various requirements should be gleaned from the RFP and the other pertinent Contract documents.† The next step is to define the various interfaces between all of the system components and the subsystems.† During this task it will be important to identify any potential constraints that might impede system operations.

At this point, it is also important to start laying out the various activities that will be incorporated into the Integratorís internal software validation test process.† The outline for this process should be initiated early on in the process since a heavy emphasis of the first phase is to determine the requirements and how the software will be developed to allow the system to operate to meet the stated requirements.

8.2         Preliminary and Detailed System Design

The next step will define the system software architecture by strategically breaking the software into modules.† This will enhance the software development, integration and validation processes.† The next task is to verify that all the requirements that are stipulated in the SSD have been taken into account.

The Integrator shall define the overall structure of the ETS and data.† Integrator staff shall set up the software integration and validation strategy, as well as the different scenarios and implementation methods that will be used.† It will be important to take into account various maintainability and testability constraints, if there are any.

The design process then continues with the development of the PDD, specifying the internal software and hardware structure and detailing the various interfaces of the components and subsystems that were previously identified in the SSD.† At this time, the Integrator should prepare whatever equipment shop tests will be required, such as the software that will be required to support the operation of those pieces of equipment.

Once the PDD has been reviewed, brought to final form by the Integrator and approved by the JPA, the next step will be to develop the Detailed Design Documents (DDD).† This task will also include coding components and documenting the source code.† In particular, the following activities will be addressed, at a minimum, during this task:

         Verifying and completing module interfaces;

         Defining the internal structure of the modules;

         Installing detailed design codes in the shape of comments in the source list; and

         Creating a list of tests to be applied to each of the modules.

8.3         Software Code Development

This task includes the actual development of the Smart Lane software.† This involves translating each DDD module into the programming language that the Integrator has chosen.† It will also include developing software to support the various dynamic pricing algorithms that will support the toll price determinations as they are described in the DDD.† The Integrator software development group will also ensure that the resulting compilation does not contain any mistakes and is compliant with all known software programming norms.

As the software is being developed, the Integrator software group will also be required to complete the equipment/shop tests to ensure that the newly developed software and Smart Lane hardware operates within the specified requirements (from the RFP and the Contract documents).† The test scripts used for the equipment/shop tests will be updated by the Integrator by finalizing the procedures defined during the previous phases of the software development process.

8.4         Software Integration and Testing

The next task in the process is to conduct full integration testing of the entire Smart Lane system.† At this point in the process, the software has been developed to about an 80% level and the Integrator software group shall conduct the system and subsystem integration testing process.† The integration tests will be performed to ensure that the newly developed software and Smart Lane hardware is fully integrated and operates within the specified ETS requirements.† The test scripts used for these integration tests will be updated by the Integrator by finalizing the procedures defined during the previous phases of the software development process.

Various work activities during this task are to assemble the software modules and make sure that the software architecture complies with the DDD of the tolling system.† Integrator software staff will also prepare for the equipment, subsystem and full system test and validation tasks.† Integrator staff shall then carefully test each software component individually and verify conformity to the DDD for each stated operating requirement.

In support of full integration testing, the Integrator software group will integrate the software modules according to the procedures defined in the integration test procedures, as they previously developed.† The software group will also validate the system architecture defined during the PPD and DDD phases of the project.† Integrator staff shall also ensure that the various software exchanges between the components and subsystems that were identified during the preliminary and detailed design phases are functioning correctly.

If the integration tests reveal any inconsistencies, then corrective measures shall be taken by the Integrator software group.† They shall conduct the integration tests again for those areas in which the problems were discovered and corrected to ensure that the defined operating requirements are met.† The equipment and system integration process shall be verified via the performance of factory testing by the JPA.

Regression testing will be conducted by the Integrator once the software modifications are made to ensure that basic system functionality has not been compromised as a result of a software modification.† The integration test documents shall be used as the basis for regression testing.† The regression testing will be complete when the results correspond to those expected, and the software modification can then be deployed into the production system.

8.5         Software Validation

This task will confirm that the functionality of the software complies with the SSD, the DDD and the other relevant Contract documents.† The Integrator will draw up a reference version of the validated software.† This will involve running additional tests, by the Integrator, to verify that the software complies with the various requirements.† Previously used system test scripts will be used for this testing.

These validation tests will focus mainly on the functionality of each component, subsystem and the overall system as well as the various interface requirements with the BATA RCSC, the TMC, the MER units, the hand-held devices, the JPA website, etc.† The validation tests shall also verify the performance and endurance of the system equipment and various subsystems and also determine that the full system data loads can be effectively handled.

When validation has been approved, the first software reference version can be created.† The validation test results and the state of the software documentation can then be verified.† If this review proves satisfactory, progress to the subsequent system qualification phases can then be authorized, which includes performance of the Factory Acceptance Test (FAT) and the follow up on-site system acceptance tests.


Software documentation will be provided for each applicable component. This will include textual descriptions, pseudo code, data flow diagrams, flowcharts and functional diagrams.† For third-party software, vendor documentation shall be provided.† Custom software documentation will include User Manuals and Technical Manuals with operational and module-level descriptions embedded with the source code.


The Integrator shall identify which product will be used for software configuration control and source code management.† The chosen version control product should support team development of the software applications.† It should also be able to automatically track and store changes to a file so the software code developers are able to view the history of each file, return to earlier versions of that file, and develop programs concurrently.† It would also be beneficial to have a product that uses reverse delta technology in order to store only the changes to a file, not each complete version of the file itself.

10.1     Process Versioning

All software processes should have a version number associated with them.† The version number should be easily obtained by locating the file in question and clicking on the file.

11.  Conclusion

The System Development Plan, which will be developed by the Integrator, shall include all of the required information to clearly describe the management approach that will be implemented to ensure that the Smart Lane ETS development work is conducted properly.† The Plan shall include all required information regarding the Integratorís approach to managing the Project, including planned hardware and software development, integration, and deployment processes.