4.2.3 Vee Development Model

Figure 4‑3 Vee Development Model

Highlights of the Vee Development Model:

• Illustrates the influence of the early phases of the project on the end of the project
• Emphasizes the planning, stakeholder involvement, validation of the requirements, as well as the validation of the product
• Illustrates the relationship of the model of the system to be built [left side] with the realization of the end product [right side]
• Illustrates planning, defining, performing integration, and verification. Emphasizes the need to begin verification planning at the time requirements are first defined at every level.
• Encourages the "Starting at the Finish Line" mindset, by looking at the validation of the product at the same time as developing the Concept of Operations, as well as the development of Verification Plans with the requirements at every level
• Encourages definition and control of the evolving baseline at each phase of the project
• Illustrates "top down" definition and decomposition [the breaking down of the project architecture into small building blocks from the top most level to the lowest component]. A specification is written for it to be built as a key systems engineering activity. It shows a "bottoms up" building, integration and verification [building the developed components up in a step wise manner from the components to the top most system]

A complete description of the Vee technical model is provided in Chapter 3.1.

The following development strategies are different ways that a project is implemented and deployed:

Single evolution Figure 4‑4. Single delivery; one single pass through the Vee

Incremental with single or multiple deliveries Figure 4‑5. Developing independent sub-systems and then integrating them together before delivery of a completed system is incremental with single delivery. Multiple developments of sub-systems that are integrated into an operational environment are called multiple deliveries deployment strategy. [See below for examples of each]

Evolutionary development Figure 4‑6. Developing sub-systems in a serial fashion as follows:

1. develop and deploy the servers, software, and communications

2. develop and deploy the workstations and software,

3. develop and deploy the field devices and software

One can mix and match these tactics into a hybrid approach such as an evolutionary development in which each evolution can be incremental with single or multiple deliveries.

The strategy selected for development is usually driven by one the following conditions:

• Funding level – project built in multiple phases to accommodate funding increments
• System size and complexity – large projects broken down into manageable developments
• Institutional issues – inter-agency agreement on interfaces, operations, maintenance responsibilities, and consensus on system features

The selection and tailoring of the strategy is done before or during the project planning phase. If funding is the driving factor, the agency may choose evolutionary development because of yearly funding increments. With large, complex projects, or the need to get the project deployed quickly, agencies may elect to use the incremental strategy. There, sub-systems are developed by different development teams and brought together.

Figure 4‑4 Single Evolution – Single Delivery

Brief commentary on single evolution- single delivery

• All requirements must be known up-front
• Used on simple projects having few requirements
• Used on projects that cannot evolve or that need to be developed in a single pass
• This was the classic development strategy in the early days of large military projects

This is not recommended for developments that can evolve over time.

Example ITS projects that may consider this strategy:

• Signal control system
• CMS, CCTV, detection sub-systems
• Small incident management systems
• Single agency minor ITS projects

Figure 4‑5 Incremental Development with single and multiple deliveries

Brief commentary on incremental development with single or multiple deliveries

• Used on large systems that can be divided into clear sub-systems
• Works with multiple development teams
• Used when significant or full system capabilities can be delivered by the sub-systems one at a time and offer useable capabilities on their own
• Need a significant amount of coordination between projects to ensure integration
• Risk of finger pointing if different development teams are developing different part of the system
• Use of multiple deliveries if each increment can be verified in a stand alone configuration
• Use of single delivery would occur if there are dependencies between the increments that need to be verified prior to delivery

Example ITS projects for incremental development with single delivery strategy:

• Reversible Control lane system
• Communications infrastructure [major sub-system]
• Toll Collections system [Major sub-system, collection system, tag processing, and enforcement]

This strategy is used for systems or major sub-systems that need to be fully functional before being deployed into service.

Example ITS projects multiple delivery strategy:

Traffic signal system

• Central management system followed by:
• Intersection group 1 [1-5] then
• Intersection group 2 [6-10] then
• Intersection group 3 [11-15]

Motorist information systems

• Central management system followed by:
• Distribution to partner agencies then
• Internet service providers, etc.
• Extending additional changeable messages signs to an existing control system.

This strategy is used when partial expansion of an existing system can be deployed over time. It should be noted that in the case of the multiple delivery strategy, the initial sub-system [in this example, the central management system for both the traffic control and motorist information system] needed to be fully functional. It needed to use the single delivery strategy and the expansion of the system elements followed by use of a multiple delivery strategy.

Figure 4‑6 Evolutionary development

Brief commentary on evolutionary development

• Used when funding is limited but can be obtained in multi-year cycles
• Large projects where not all of the requirements are known but enough are known to build initial capabilities
• Multi-regional systems where stakeholders need to develop systems internally to join with a broader set of stakeholders
• Where institutional issues are complex and initial capabilities are needed to resolve them
• Projects may or may not provide capability that will go into service. However, they will be building blocks for the next evolution of the system

Evolutionary development is recommended for ITS projects.

Example of ITS projects that may consider this strategy:

Incident Management System [single or multi-agency]

Possible Sequencing:

• Sub-system 1-The Communications backbone
• Sub-system 2-Surveillance [CCTV]
• Sub-system 3-Changeable Message signs
• Sub-system 4-Detection system

Sub-system 5-Incident Management Software

Regional Advanced Motorist Information System

Possible sequencing:

• Sub-system 1-The Communications backbone [agency interfaces and agreements]
• Sub-system 2- Detection system
• Sub-system 3- Data Process software
• Sub-system 4- Media Interfaces
• Sub-system 5 Surveillance [CCTV]
• Sub-system 6-Video interface to Media

Note:

Any projects that are done incrementally can be done using evolutionary deployment. In some cases, it may take several evolutions of development before it is ready to be commissioned into service. The interim evolutions would not be put into service until the whole system is completed. For example, a reversible lane control system may be implemented using evolutionary deployment but would not be commissioned into service until all essential sub-systems have been developed and integrated.