1.1 Overview of the Vee Technical Development

The Vee Development Model is the recommended development model for ITS projects. This model for systems development combines the important features of the classic Waterfall model and the Spiral Development Model used primarily for software development. Both models are briefly described below.

Illustrated in Figure 1‑2 is the Vee Development Model in the context of the life cycle framework. This model has gained wide acceptance in the systems engineering community and has been illustrated [or its equivalent] as part of the most recent Systems Engineering Process Standards ISO15288, ISO/IEC TR 19760, and EIA 632. It is also found in many of the current leading Systems Engineering texts. The reason for this acceptance is that the model illustrates some key systems principles about the relationship of the early phases of the development to the end results of the project. It is described in more detail in the step-by-step description below. This overview also serves as a primer for the reader who is not familiar with the systems development process.

The following are step-by-step descriptions of the life cycle model and cross-cutting activities that support the steps of the life cycle. The title of each chapter is followed by the number of the chapter in this Guidebook which contains more descriptive detail. In addition to this description, observations about the Vee Development Model, some basic systems engineering principles, plus terms and definitions will be discussed. This will give the reader a starting point with this chapter of the Guidebook. A more comprehensive list of terms and definitions are included in the appendix. The Vee portion of the illustration is the project level development phase. This discussion starts with a description of the left "wing" of the illustration, the Vee technical model itself, and finishes with the right "wing" of the life cycle framework. It should be noted that the "Changes & Upgrades" step [right "wing"] is performed using the Vee technical model but is not illustrated that way for the purposes described below.

Figure 1‑2 ITS Project Life cycle Phases and the Life cycle Tasks in this Guidebook

Process Activities

The following is a summary of the process steps in the Vee
technical model.

This initial step interfaces with the ITS architecture for a
region. Development of a regional ITS architecture is not covered by this Guidebook
since it is well described in the Regional ITS
Architecture Guidance Document. Key activities of this phase are: 1] the identification of the regional stakeholders and 2] the building of consensus for the purposes of information sharing and long term operations & maintenance. The architecture is coordinated with the long range transportation plan and candidate ITS projects are programmed through the Transportation Improvement Program, Statewide Transportation Improvement Program, and agency capital plans. For more information on developing a regional ITS architecture please refer to
Regional ITS Architecture
Guidance Document at: http://www.its.dot.gov/research_archives/arch/.

Concept Exploration is used to perform an initial feasibility & benefits analysis and needs assessment for the candidate projects from the regional ITS architecture. This results in a business case and specific cost benefit analyses for alternative project concepts. The output of this stage is a definition of the problem space, key technical metrics, and refinements to the needs, goals, objectives, and vision. This stage identifies the highest cost/benefit concept [best business case] project to move forward into development. This activity may result in combining or dividing candidate projects based on the best cost/benefit analysis. The decision gate is to gain management support & approval for the project to move into the planning and definition phases of the project.

Systems Engineering
Planning [3.4.1 & 3.4.2]

Each project that moves forward into development must be
planned. Planning takes place in two parts. In part one, the system's owner
develops a set of master plans and schedules that identifies what plans are
needed and, at a high level, the schedule for implementation of the project. This
becomes the framework for what is developed in part two. In part two, the plans
are completed during the steps from the concept of operations to the high level
design. These plans, once approved by the system's owner, become the control
documents for completion of the development and implementation of the project.

Concept of Operations is the initial definition of the system. At this stage, the project team documents the way the envisioned system is to operate and how the envisioned system will meet the needs and expectations of the stakeholders. The envisioned operation is defined from multiple viewpoints consisting of operators, maintainers, and managers. The focus is on how the system will be validated [proof that the envisioned system meets the intended needs]. A refinement of the problem space, definition, needs, goals, expectations, stakeholder lists, and project constraints is placed into the concept of operations document. This document contains the updated, refined summary of work done at the Concept Exploration phase.

System Level
Requirements [3.5.1]

Requirements are developed for the system. At the system
level; the definitions of what
the system is to do, how
well it is to do it, and under what conditions are documented. System requirements are based on the user needs from the Concept of Operations. Requirements do not state
how [design
statements] the system will be implemented unless it is intended to constrain
the development team to a specific solution.

The High Level Design stage defines the project level architecture for the system. System level requirements are further refined and allocated [assigned] to the sub-systems of hardware, software, databases, and people.

Requirements for each sub-system element are documented the
same way as the system level requirements. This process is repeated until the
system is fully defined and decomposed. Each layer will have its own set of interfaces
defined. Each layer will require an integration step that is needed when the sub-system
is developed. The control gate that is used for this final review is sometimes
called the Preliminary Design Review [PDR].

At the Component Level Detailed Design step the development team defines
how the system will be built. Each sub-system has been decomposed into components of hardware, software, database elements, firmware, and/or processes. For these components, Detailed Design specialists in the respective fields create documentation ["build-to" specifications] which will be used to build or procure the individual components. A final check is done on the "buildâ€“to" specifications before the design moves forward to the actual coding and hardware fabrication. At this level, the specific commercial off-the-shelf [COTS] hardware and software products are specified. They are not purchased until the review is completed and approved by the system's owner and stakeholders. The control gate used for this final review is sometimes called the Critical Design Review [CDR].

Hardware/Software
Procurement or Development & Unit Testing [3.6.1]

This stage involves hardware fabrication, software coding,
database implementation, and the procurement & configuration of COTS products.
This stage is primarily the work of the development team. The system's owner
and stakeholders monitor this process with planned periodic reviews, e.g. code
walkthroughs and technical review meetings. Concurrent with this effort, unit
test procedures are developed that will be used to demonstrate how the products
will meet the detailed design. At the completion of this stage, the developed
products are ready for unit test.

Unit Testing [3.6.1]

The components from the hardware and software development are verified in accordance with the unit Verification Plan. The purpose of unit testing is to verify that the delivered components match the documented Component Level Detailed Design. This is done by the development team in preparation for the next level of integration. It is also a good review point for the system's owner and stakeholders.

At this step, the components are integrated and verified at the lowest level of the sub-systems. The first level of verification is done in accordance with the Verification Plan and is carried out in accordance with the Verification Procedures [step-by-step method for carrying out the verification] developed in this stage. Prior to the actual verification, a Test Readiness Review is held to determine the readiness of the sub-systems for verification. When it has been determined that verification can proceed, the sub-systems are then verified. When the integration and verification are completed, the next level of sub-system is integrated and verified in the same manner. This process continues until all sub-systems are integrated and verified.

System verification is done in two parts. The first part is done under a controlled environment [sometimes called a "factory test"]. The second part is done within the environment that the system is intended to operate [sometimes called "on-site testing/verification"] after initial system deployment. At this stage, the system is verified in accordance with the Verification Plan developed as part of the system level requirements performed early in the development. The system acceptance will continue through the next stage, Initial System Deployment. The final part of system verification is then completed. A control gate is used for this conditional system acceptance.

At Initial System Deployment, the system is finally integrated into its intended operational environment. This step may take several weeks to complete to ensure that the system operates satisfactorily in the long term. This is sometimes called a "system burn-in". Many system issues surface when the system is operating in the real world environment for an extended period of time. This is due to the uncontrollable nature of inputs to the system, such as long term "memory" leaks in software coding and race conditions [unexpected delays between signals] that may only occur under specific and infrequent conditions. Once the system verification is completed, the system is accepted by the system's owner and stakeholders and then moves into the system validation and operations & maintenance phases.

Validating the system is a key activity of the system's owner and stakeholders. It is here that they will assess the system's performance against the intended needs, goals, and expectations documented in the Concept of Operations and the Validation Plan. It is important that this validation takes place as early as possible [after the acceptance of the system] in order to assess its strengths, weaknesses, and new opportunities. This activity does not check on the work of the system integrator or the component supplier [that is the role of System Verification]. It is performed after the system has been accepted and paid for. As a result of validation, new needs and requirements may be identified. This evaluation sets the stage for the next evolution of the system.

Operations & Maintenance [3.7.2]

After the initial deployment and system acceptance, the
system moves into the Operations & Maintenance phase. In this phase the
system will carry out the intended operations for which it was designed. During
this phase routine maintenance is performed as well as staff training. This
phase is the longest phase, extending through the evolution of the system and
ends when the system is retired or replaced. This phase may continue for
decades. It is important that there are adequate resources to carry out the
needed Operations & Maintenance activities; otherwise, the life of the
system could be significantly shortened due to neglect.

Changes & Upgrades [3.7.3]

Changes & upgrades should be implemented in accordance with the Vee technical process recommended by this Guidebook. Using the Vee process for changes & upgrades will help maintain system integrity [synchronization between the system components and supporting documentation]. When the existing system is not well documented, start by reverse engineering the affected area of the system in order to develop the needed documentation for the forward engineering process.

Retirement/Replacement [3.8.1]

Eventually, every ITS system will be retired or replaced for
one of the following reasons:

The system may no longer be needed.

It may not be cost effective to operate.

It may no longer be maintainable due to obsolescence of key
system elements

It might be an interim system that is being replaced by a more
permanent system.

This phase looks at how to monitor, assess needed changes,
and make change/upgrade decisions.

A number of cross-cutting activities are needed to support
the development of Intelligent Transportation Systems. The following are the enabling
activities used to support one or more of the life-cycle process steps.

Stakeholder involvement is regarded as one of the most
critical enablers within the development and life-cycle of the project and
system. Without effective stakeholder involvement, the systems engineering and
development team will not gain the insight needed to understand the key issues
and needs of the system's owner and stakeholders. This increases the risk of
not getting a valid set of requirements to build the system or to obtain buy-in
on changes & upgrades.

Elicitation is an activity that when performed correctly, effectively, and accurately, gathers and documents information needed to develop the system. The typical types of information include needs, goals, objectives, requirements, and stakeholder expectations. Some information may be in a documented form or stated clearly by the stakeholders, but much of the needed information may be implied or assumed. The Elicitation processes help draw out and resolve this information, resolve conflicting information, build consensus, and validate the information.

Various project management practices are needed to support
the development of the system. Project management practices provide a
supportive environment for the various development activities. It provides the
needed resources, then monitors and controls costs and schedules. It also
communicates status between and across the development team members, system's
owner, and stakeholders.

Project metrics are measures that are used by both the
project manager and systems engineer to track and monitor the project and the
expected technical performance of the system development effort. The
identification and monitoring of metrics allow the team to determine if the project
is "on-track" both programmatically and technically.

Managing change to the system is a key process that occurs
throughout the life of the system. Configuration management is the process that
supports the establishment of system integrity [the documentation matches the
functional and physical attributes of the system]. It maintains this integrity
throughout the life of the system [synchronizes changes to the system with its
documentation]. A lack of change management will shorten the life of the system
and may prevent a system from being implemented and deployed.

Process Improvement [3.9.7]

A quality aspect of the system's life cycle is to
continuously improve the process. This is done by learning from previous
efforts how to improve future work. Process improvement is an enabler that
provides insight about what worked and what needs improvement in the processes.
This activity is used to improve the documented processes over time.

Decision Gates are formal decision points along the life cycle that are used by the system's owner and stakeholders to determine if the current phase of work has been completed and if the team is ready to move onto the next phase of the life cycle. By setting entrance and exit criteria for each phase of work, the control gates are used to review and accept the work products done for the current phase of work. They also evaluate the readiness for moving to the next phase of the project.

Technical decisions on alternative solutions are a key
enabler for each phase of system development. This starts when alternative
concepts are evaluated and continues through the system definition and design
phases. This chapter provides a method to perform a trade study.

Technical reviews are used to assess the completeness of a
product, identify defects in work, and align team members in a common technical
direction. This chapter provides a process for conducting a technical review.

Traceability is a key cross-cutting process that supports verification & validation of requirements by ensuring that all needs are traced to requirements and that all requirements are implemented, verified, and validated. Traceability supports impact analysis for changes, upgrades, and replacement.

Key
Observations for the Vee

Â Development
Model

The left side is the definition and decomposition of the system into components that can be built or procured. The bottom of the Vee is the construction, fabrication, and procurement of the component items. The right side of the Vee integrates the components into sub-systems then into the final system. Each level of integration is verified against the left side of the Vee through the Verification Plans [verification process [3.6.3]].

Decision
gates [3.9.8] provide the system's owner with formal decision points for proceeding
to the next step of the process. A decision gate is an interface from one phase
of the project to the next. There is an interface between each phase from the
left side to the right side.

There
is a relationship of the activities performed on the left side of the Vee to
the products being produced, integrated, and verified on the right side of the
Vee [model versus reality].

The most important view of the system for the system's owner and stakeholders is at the Concept of Operations level. Below that level is the area of most interest to the development team. It is the area for which they are responsible [system's owner responsibility versus the development team responsibility].

Importance of stakeholder involvement is shown on both sides of the Vee. It is shown on
the left side by defining the system and on the right side by the verification
of the system.