Acceptance: An action by an authorized representative of the acquirer by which the acquirer assumes ownership of products as a partial or complete performance of contract.
Acceptance criteria: The criteria a product must meet to successfully complete a test phase or meet delivery requirements.
Acceptance test: Formal testing conducted to determine whether or not a system satisfies its acceptance criteria and to enable the acquirer to determine whether or not to accept the system.
Acquirer: An organization that procures products for itself or another organization.
Appraisal: In CMMI, an examination of one or more processes by a trained team of professionals using an appraisal reference model as the basis for determining, at a minimum, strengths and weaknesses. (See also assessment.)
Approval: Written notification by an authorized representative of the acquirer that the developer’s plans, design, or other aspects of the project appear to be sound and can be used as the basis for further work. Such approval does not shift responsibility from the developer to meet contractual requirements.
Architecture: The organizational structure of a system, identifying its components, their interfaces, and a concept of execution among them.
Assembly: A number of parts or sub-assemblies, or any combination thereof joined together, to perform a specific function and capable of disassembly.
Assessment: In CMMI, an appraisal that an organization does internally for the purposes of process improvement.
Audit: An independent examination of a work product/process or set of work products/processes to assess compliance with specifications, standards, contractual agreements, or other criteria.
Authentication: The procedure [essentially approval] used by the approval authority in verifying that specification content is acceptable. Authentication does not imply acceptance or responsibility for the specified item to perform successfully.
Baseline: An approved product at a point in time. Any changes made to this product must go through a formal change process.
Components: Components are the named "pieces" of design and/or actual entities [sub-systems, hardware units, software units] of the system/sub-system. In system/sub-system architectures, components consist of sub-systems [or other variations], hardware units, software units, and manual operations.
Concept [project concept]: A high-level conceptual project description, including services provided and the operational structure.
Concept exploration: The process of developing and comparing alternative conceptual approaches to meeting the needs that drive the project.
Concept of Operations: A document that defines the way the system is envisioned to work from multiple stakeholder viewpoints [Users including operators, maintenance, management].
Configuration item [CI]: A product such as a document or a unit of software or hardware that performs a complete function and has been chosen to be placed under change control. That means that any changes that are to be made must go through a change management process. A baseline is a configuration item.
Configuration management: A discipline applying technical and administrative direction and surveillance to identify and document the functional and physical characteristics of Configuration Items [CI’s]; audit the CI’s to verify conformance to specifications, manage interface control documents and other contract requirements control changes to CI’s and their related documentation; and record and report information needed to manage CI’s effectively, including the status of proposed changes and the implementation status of approved changes.
Configuration Management Plan: A plan defining the implementation [including policies and methods] of configuration management on a particular program/project.
Contract: A mutually binding legal relationship obligating a seller to furnish the supplies or services [including construction] and a buyer to accept and pay for them. It includes all types of commitments, in writing, that obligate the buyer to an expenditure of appropriate funds. In addition to bilateral agreements, contracts include, but are not limited to, awards and notices of awards; job orders or task letters issued under purchase orders under which the contract becomes effective by written acceptance or performance; and bilateral modifications.
Contractor: An individual, partnership, company, corporation, association or other service, having a contract with a buyer for the design, development, manufacture, maintenance, modification, or supply of items under the terms of a contract.
Control gates: 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 that the team is ready to move into the next phase of the life cycle.
Cross-cutting activities: Enabling activities used to support one or more of the life cycle process steps.
Data: Recorded information, regardless of medium or characteristics, of any nature, including administrative, managerial, financial, and technical.
Data product: Information that is inherently generated as the result of work tasks cited in a Statement of Work [SOW] or in a source document invoked in the contract. Such information is produced as a separate entity [for example, drawing, specification, manual, report, records, and parts list].
Database: A collection of related data stored in one or more computerized files in a manner that can be accessed by users or computer programs via a database management system.
Database management system: An integrated set of computer programs that provide the capabilities needed to establish, modify, make available, and maintain the integrity of a database.
Decomposition: The process of successively breaking down the system into components that can be built or procured. Functional and physical decomposition are the key activities that are used. Functional decomposition is breaking a function down into its smallest parts. For example, the function ramp metering decomposes into a number of sub-functions, e.g. detection, meter rate control, main line metering, ramp queuing, time of day, and communications. Physical decomposition defines the physical elements needed to carry out the function. For example, the ramp metering physical decomposition includes loops or video detection, WWV time [worldwide standard clock for accurate time], fiber or twisted pair for communications, 2070 or 170 controllers, and host computer.
Design: Those characteristics of a system or components that are selected by the developer in response to the requirements.
Detailed Design Document: The product baseline used to develop the hardware and software components of the system.
Developer: An organization that develops products ["develops" may include new development, modification, reuse, reengineering, maintenance, or any other activity that results in products] for itself or another organization.
Development model: A specific portion of the life cycle model that relates to the definition, decomposition, development, and implementation of a system or a part of a system.
Development strategy: The way the development and deployment of the overall system will be carried out. For example, an evolutionary development strategy means that the system will be developed and deployed in multiple segments over time. These pieces are complete functional units that will perform independently from other functional pieces. Incremental development is the development of pieces that are done concurrently or nearly concurrently by the same or different development teams.
Elicitation: The process to draw out, to discover and to make known so to gain knowledge and information, often used in defining needs.
Enabling products: Products that enable the end product to be developed, supported, and maintained. For example, these products typically are the software compilers, prototypes, development workstations, plans, specifications, requirements, and training materials.
End products: Products that perform the desired capability e.g. the hardware, software, communications, and databases.
End-item: A deliverable item that is formally accepted by the acquirer in accordance with requirements of a detail specification.
Evaluation: The process of determining whether an item or activity meets specified criteria.
Evolutionary development: Breaking a project down into parts and developing them in serial fashion.
Feasibility assessment: A pre-development activity to evaluate alternative system concepts, selects the best one, and verifies that it is feasible within all of the project and system constraints.
Firmware: The combination of a hardware device and computer instructions and/or computer data that resides as read-only software on the hardware device.
Gap analysis: A technique to assess how far current [legacy] capabilities are from meeting the identified needs, to be used to prioritize development activities. This is based both on how far the current capabilities are from meeting the needs [because of insufficient functionality, capabilities, performance or capacity] and whether the need is met in some places and not others.
Hardware: Articles made of material, such as aircraft, ships, tools, computers, vehicles, fittings, and their components [mechanical, electrical, electronic, hydraulic, and pneumatic]. Computer software and technical documentation are excluded.
Integrated product team: A team consisting of agency and contractor representatives working together.
Integrity: A system characteristic that means that the system’s functional, performance, physical, and enabling products are accurately documented by its requirements, design, and support specifications.
Intelligent Transportation Systems: A broad range of diverse technologies which, when applied to our current transportation system, can help improve safety, reduce congestion, enhance mobility, minimize environmental impacts, save energy, and promote economic productivity. ITS technologies are varied and include information processing, communications, control, and electronics.
Interface: The functional and physical characteristics required to exist at a common boundary - in development, a relationship among two or more entities [such as software-software, hardware-hardware, hardware-software, hardware-user, or software-user].
Interface control: Interface control comprises the delineation of the procedures and documentation, both administrative and technical, contractually necessary for identification of functional and physical characteristics between two or more configuration items that are provided by different contractors/acquiring agencies, and the resolution of the problems thereto.
Item: A non-specific term used to denote any product, including systems, sub-systems, assemblies, subassemblies, units, sets, accessories, computer programs, computer software, or parts.
Legacy system: The existing system to which the upgrade or change will be applied.
Life cycle: The end-to-end process from conception of a system to its retirement or disposal.
Life cycle model: A representation of the steps involved in the development and other phases of an ITS project.
Metrics: Measures used to indicate progress or achievement.
Model: An abstraction of reality. Examples: A road map is an abstraction of the real road network. A globe is a model of the world. A simulation is a dynamic model of a time sequence of events.
Module: A self-contained part of a hardware item designed as a single replaceable unit, with a specific integral electronic function. It should require no installation other than mechanical mounting and completion of electrical connection.
National ITS Architecture: A general framework for planning, defining, and integrating ITS. It was developed to support ITS implementations over a 20-year time period in urban, interurban, and rural environments across the country. The National ITS Architecture is available as a resource for any region and is maintained by the USDOT independently of any specific system design or region in the nation.
Needs assessment: An activity accomplished early in system development to ensure that the system will meet the most important needs of the project’s stakeholders, specifically that the needs are well understood, de-conflicted, and prioritized.
Non-conformance: The failure of a unit or product to conform to specified requirements.
Operational baseline: The system that is currently in use, including all of the design, development, test, support, and requirements documentation.
Operational concept: In the ITS industry, the operational concept defines the roles and responsibilities of the primary stakeholders and the systems they operate.
Part: One piece, or two or more pieces joined together which are not normally subjected to disassembly without destruction or impairment of designed use [examples: gear, screws, transistors, capacitors, integrated circuits].
Performance: A quantitative measure characterizing a physical or functional attribute relating to the execution of a mission/operation or function.
Policy: A guiding principle, typically established by senior management, which is adopted by an organization or project to influence and determine decisions.
Process: An organized set of activities
Process Area: A cluster of related practices in an area that, when implemented collectively, satisfies a set of goals considered important for making improvement in that area. All CMMI process areas are common to both continuous and staged representations.
Product: A product is a given set of items. The set could consist of system, sub-system, hardware or software items, and their documentation.
Project: An undertaking requiring concerted effort, which is focused on developing and/or maintaining a specific product. The product may include hardware, software, and other components. Typically, a project has its own funding, cost accounting, and delivery schedule with the acquirer [customer].
Project architecture: High-level design
Project life cycle: See Life cycle
Project Plan: A description [what is to be done, what funds are available, when it will be done and by whom] of the entire set of tasks that the project requires.
Qualification testing: Testing performed to demonstrate to the acquirer that an item, system, or sub-system meets its specified requirements.
Quality assurance: A planned and systematic pattern of all actions necessary to provide adequate confidence that management, technical planning, and controls are adequate to establish correct technical requirements for design and manufacturing. And to manage design activity standards, drawings, specifications, or other documents referenced on drawings, lists or technical documents.
Reengineering: The process of examining and altering an existing system to reconstitute it in a new form. This may include reverse engineering [analyzing a system and producing a representation at a higher level of abstraction, such as design from code], restructuring [transforming a system from one representation to another at the same level of abstraction], recommendation [analyzing a system and producing user and support documentation], forward engineering [using software products derived from an existing system, together with new requirements, to produce a new system], and translation [transforming source code from one language to another or from one version of a language to another].
Regional ITS Architecture: A specific regional framework for ensuring institutional agreement and technical integration for the implementation of ITS projects in a particular region.
Regression Testing: Is a process that tests not only the area of change but also tests those areas that were not changed but are affected by the change.
Requirements: The total consideration as to WHAT is to be done [functional], HOW well it is to perform [performance], and under WHAT CONDITIONS it is to operate. [Environmental and non-functional].
Reverse engineering: The process of documenting an existing Intelligent Transportation Systems functional [what it does – requirements], physical [how it does it – design], and support [the way it was built and maintained – enabling products] characteristics.
Risk management: An organized process to identify what can go wrong, to quantify and access associated risks, and to implement/control the appropriate approach for preventing or handling each risk.
Service packages: Service packages provide an accessible, service-oriented perspective to ARC-IT. They are tailored to fit, separately or in combination, real world transportation problems and needs. They identify the pieces of the ARC-IT physical view that are required to implement a particular ITS service. Service packages are implemented through projects (or groups of projects, aka programs) and in transportation planning, are directly related to ITS strategies used to meet regional goals and objectives.
Software development: A set of activities that result in software products. Software development may include new development, modification, reuse, re-engineering, maintenance, or any other activities that result in software products.
Specification: A document that describes the essential technical requirements for items, materials or services including the procedures for determining whether or not the requirements have been met.
Stakeholders: The people for whom the system is being built, as well as anyone who will manage, develop, operate, maintain, use, benefit from, or otherwise be affected by the system.
Statement of Work: A document primarily for use in procurement, which specifies the work requirements for a project or program. It is used in conjunction with specifications and standards as a basis for a contract. The SOW will be used to determine whether the contractor meets stated performance requirements.
Subcontractor: An individual, partnership, corporation, or an association that contracts with an organization [i.e., the prime contractor] to design, develop, and/or manufacture one or more products.
Suppliers: The term 'suppliers' includes contractors, sub-contractors, vendors, developers, sellers or any other term used to identify the source from which products or services are obtained.
Synthesis: The translation of input requirements [including performance, function, and interface] into possible solutions [resources and techniques] satisfying those inputs. This defines a physical architecture of people, product, and process solutions for logical groupings of requirements [performance, functions, and interface] and their designs for those solutions.
System elements: A system element is a balanced solution to a functional requirement or a set of functional requirements and must satisfy the performance requirements of the associated item. A system element is part of the system [hardware, software, facilities, personnel, data, material, services, and techniques] that, individually or in combination, satisfies a function [task] the system must perform.
System: An integrated composite of people, products, and processes, which provide a capability to satisfy a stated need or objective.
System of systems: A system whose elements are themselves systems. A system of systems (SoS) brings together a group of systems to accomplish a mission that none of the systems can accomplish on their own. A regional transportation system is actually an SoS that is made up of signal control system(s), a freeway management system, public transportation system(s), freight distribution and logistics systems, and many others.
Systems engineering: An inter-disciplinary approach and a means to enable the realization of successful systems. Systems engineering requires a broad knowledge, a mindset that keeps the big picture in mind, a facilitator, and a skilled conductor of a team.
System specification: A top level set of requirements for a system. A system specification may be a system/sub-system specification, Prime Item Development Specification, or a Critical Item Development Specification.
Tailoring: Planning systems engineering activities that are appropriate and cost-effective for the size and complexity of the project. It may be based on cost, size, the number of stakeholders, the supporting relationships between them, complexity of systems [large number of interfaces to other systems, a large number of functions to perform, or the degree of coupling between systems.], level of ownership of system products [custom development of software owned by the agency or commercial off the shelf products], existing software products, resources, risks.
Technical reviews: A series of systems engineering activities by which the technical progress on a project is assessed relative to its technical or contractual requirements. The formal reviews are conducted at logical transition points in the development effort to identify and correct problems resulting from the work completed thus far before the problem can disrupt or delay the technical progress. The reviews provide a method for the contractor and procuring activity to determine that the identification and development of a CI have met contract requirements.
Testable: A requirement or set of requirements is considered to be testable if an objective and feasible test can be designed to determine whether each requirement has been met.
Trade-off Study: An objective evaluation of alternative requirements, architectures, design approaches, or solutions using identical ground rules and criteria.
User: The organization[s] or persons within those organizations who will operate and/or use the system for its intended purpose.
User services: User services documented what ITS should do from the user's perspective. A broad range of users were considered, including the traveling public as well as many different types of system operators. User services, including the corresponding user service requirements, formed the basis for the original National ITS Architecture development effort. The initial user services were jointly defined by USDOT and ITS America with significant stakeholder input and documented in the National Program Plan. The concept of user services allows system or project definition to begin by establishing the high level services that will be provided to address identified problems and needs.
Validation: The process of determining that the requirements are the correct requirements and that they form a complete set of requirements this is done at the early stages of the development process. Validation of the end product or system determines if the system meets the user’s needs.
Vendor: A manufacturer or supplier of an item.
Verification: The process of determining whether or not the products of a given phase of the system/software life cycle fulfill the requirements established during the preceding phase.
Work breakdown structure: A product-oriented listing, in family tree order, of the hardware, software, services, and other work tasks, which completely defines a product or program. The listing results from project engineering during the development and production of a materiel item. A WBS relates the elements of work to be accomplished to each other and to the end product.
