8 Part 8: Annex

8.3 Glossary

Acquirer

The user is understood to be the acquirer in a contract, i. e. the recipient of a »Work Product provided by the »Supplier (DIN EN ISO 8402).

Acquirer/Supplier Interface

The »Acquirer/Supplier Interface describes explicitly which »Work Products are exchanged between the user and the supplier V-Modell project. These products are called »Interface Products.

Activity

A distinction is made between the »Activity Type and the »Activity Instance. In the context of the V-Modell the term Activity generally denotes an »Activity Type.

Activity Group

see »Discipline.

Activity Instance

An »Activity Instance is understood to be the concrete form of an »Activity Type, for example the realization of a certain software unit.

Activity Structure

The term »Activity Structure is understood to be the quantity of »Activity Instance of a project and their relations.

Activity Type

An »Activity Type (in the following briefly called "activity") describes »Activity Instance that may be executed during a development process.

Activities are part of exactly one »Discipline and thus always assigned to a »Process Module. Each »Work Product is assigned to an activity by which it is processed. Thus activities modify products. Product used only as an input for an activity are not explicitly assigned to an activity. When a product is finished, it is in the »Product State »Finished, and the finishing conditions assigned to the product apply. Activities are further subdivided in sub-activities.

Advanced V-Modell

See »V-Modell, Advanced.

Application Profile

An »Application Profile indicates the values adopted for the individual »Project Characteristics in concrete projects. On the basis of this application profile an initial »Tailoring is performed.

Component-Based Development

see »Development, Component-Based.

Consistency State

A »Work Product assumes one of the two consistency states Consistency Checked or Consistency Unclear. This state is assigned to the product depending on whether the conditions defined within the framework of a »Product Dependency are fulfilled.

Content-Related Product Dependencies

See »Product Dependencies, Content-Related.

Contributor

The term Contributor describes those roles whose consultation is absolutely necessary for the processing of a »Work Product.

Data Protection

The purpose of data protection is to protect the individual against his right to privacy being impaired through the handling of his personal data. (Reference: Bundesdatenschutzgesetz (Federal Data Protection Act)).

Decision Gate

At a »Decision Gate a decision is made whether a »Project Progress Stage is reached. This decision is made on the basis of the »Finished »Work Products defined for the decision gate.

The order in which the decision gates have to be passed through in a project is determined in the »Project Execution Strategy.

Degree of Risk

Within the framework of risk management, the »Degree of Risk is the »Risk Damage weighted with the »Risk Probability.

Degree of Risk = Risk Probability * Risk Damage

Development, Component-Based

The develoopment strategy »Component-Based Development is based on the idea that the new system will largely be developed by integrating existing system elements. A »System Element intended for integration (e.g. a segment or a hardware/software unit) has a clearly defined external interface, includes design and implementation and can be connected to other system elements. It is functionally and technically independent and has a certain size (i.e. economic value).

Generally a system element intended for integration must have the following characteristics:

  • Availability of clear, accurately defined interfaces
  • Communication with the environment (e.g. other components) exclusively via the defined interfaces
  • Adaptation to certain application environments (Customizing) exclusively via the interfaces
  • Realization specifications not visible for the user (Blackbox)

Development, Incremental

Development strategy which at first defines the overall system in an »Overall System Specification . Afterwards, the system will be continually refined in accordance with the Divide & Conquer principle until the »Software Specification has been developed, which will then be implemented and integrated by means of a suitable »Software Architecture.

The Supplier designs, realizes and delivers the system in individual steps, which are also called »Increment. Each increment will be accepted individually by the Acquirer and laid down contractually in advance, or additional contracts on the development of complementing increments will be concluded. Before an increment will be delivered to the Acquirer, the Supplier may complete several internal iterations.

Within the framework of this development strategy, the Acquirer should avoid changes within one increment. Changes should be integrated into the following increment by means of change management procedures. The Supplier should be informed as soon as possible about important changes which may have a significant influence, e.g., on the architecture of the system. For the Acquirer, this approach has the advantage that he will have an early preliminary system which already realizes the basic functionalities of the entire system.

This development strategy is particulary suitable if the system requirements are regarded as relatively stable and the technological risks are rather low. It is possible to use off-the-shelf products, but the main portion of the system will be developed within the framework of the project.

Development, Prototypic

The »Prototypic Development Strategy is based on the knowledge that it is frequently impossible to define the system requirements in advance. In addition, it ensures that nothing will be specified unless it has proven its feasibility. Therefore, this strategy is used particularly if the project includes realization risks. Changes of the requirements will be managed by the Problem and Change Management.

Another typical feature of this development strategy is the fact that the Acquirer is present at the site of the Supplier during the development. This enables the Acquirer to directly express his change proposals. The Supplier designs, realizes and delivers the system in individual steps, which is similar to the development strategy »Incremental Development. Each step will be accepted individually by the Acquirer. For the Acquirer, this approach has the advantage that he will have an early operable system which already realizes most important the basic functionalities. In addition, this strategy enables the Acquirer to give an early feedback, which minimizes the development risks of the Supplier.

Development Standards for IT Systems of the Federal Republic of Germany

See the »V-Modell.

Discipline

The »Work Products and »Activity of the »V-Modell are hierarchically structured. At the highest level are Disciplines. A Discipline is a grouping of a number of products that, with regard to contents, are closely connected with each other and of activities that prepare the respective products.

Examples of Disciplines include »Supply and Contracting and »System Design. Each Discipline is unambiguously assigned to one »Process Module.

Earlier V-Modell XT versions represented Disciplines by means of Product Groups and Activity Groups. This subdivision is no longer used.

Dynamic Tailoring

Dynamic »Tailoring is understood to be the tailoring activities that are carried out during the project duration to further adjust the list of the activities to be carried out and the products to be prepared, which is drawn up at the start of the project, to the project.

External Hardware Module

see »Hardware Module, External

External Product

See »Work Product, External.

External Software Module

see »Software Module, external

External Unit

The Product »External Unit comprises system elements which are not developed within the scope of the project. An »External Unit may be an off-the-shelf product, a unit furnished by the user, a re-usable system or segment developed in advance, an adjacent system or the result of a sub-contract. An external unit may comprise hardware and software portions.

Finished

Defines a »Product State of a »Work Product that is finished. For the term "finished" frequently also the term "released" or "valid". This product state is set in the »Product Library.

finishes

An »Activity finishes a »Work Product. An »Activity Instance is only finished, when the corresponding »Product Instance is in the »Product State »Finished.

Functional Safety

Functional safety comprises procedural or operational safety and the aspects of reliability, fault tolerance and correctness. This status depends on measures limiting the risk of a personal injury or material or immaterial damage to an acceptable level.

Generative Product Dependency

See »Product Dependency, Generative.

Hardware Element

The term »Hardware Element is a generic term which may designate all system elements beginning with the »Hardware Unit level in the hierarchy of »System Elements: »Hardware Unit, »Hardware Component, »Hardware Module, and »External Hardware Module.

Hardware Module, External

The product »External Hardware Module comprises system elements (»Hardware Modules , »Hardware Components) which are not developed within the scope of the project. An »External Hardware Module is a functional element which can be described autonomously. An external hardware module may be an off-the-shelf product, a unit furnished by the supplier, a re-usable component developed in advance, an adjacent system or the result of a sub-contract.

Increment

In the »Project Type Variant »Project (Acquirer) Including Development, Enhancement or Migration , the software/hardware item to be prepared will be developed by a step-by-step approach. The development is conducted in » Iterations, i.e., the steps will be developed successively. Since the contents of each »Increment is largely independent of the other increments, an operational »System will be available if a completed » Increment is delivered. An »Increment may be subject of an »Iteration.

Incremental Development

see »Development, Incremental.

Information Security

Information security describes the condition, which ensures the confidentiality, integrity, authenticity, and availability of information. This condition is achieved by suitable technical, personal, material (including structural) and organizational measures.

Initial Product

See »Work Product, Initial.

In Processing

Defines a »Product State of a »Work Product that is currently being processed. This product state is set in the »Product Library.

Integrity

Integrity is the state that excludes unauthorized and forbidden modifications of information and IT systems or components.

Interface between V-Modell Projects

See »Acquirer/Supplier Interface.

Interface Product

A »Work Product that is exchanged between the »V-Modell Projects of the »Acquirer and the »Supplier is called an »Interface Product. Interface products are defined in the »Acquirer/Supplier Interface.

Iteration

An »Iteration designates one system development cycle. An iterative approach leads to periodically recurring similar system development tasks, with the subject either chainging in each »Iteration (e.g. development of different sub-systems in successive »Increment s) or being refined in successive »Iterations (e.g. the step-by-step refinement and further development of systems).

Mapping to Standards

»Mapping to Standards represents the connection of the »V-Modell to current (quasi-) standards and regulations.

For this purpose, »Mapping to Standards relates the terms defined in the standard to the system of concepts of the V-Modell.

Measurement Data Type

Synonymous to: basic data, measurable quantities

Each measurement data type describes a measure that is directly determined (e. g. by counting faults, counting hours, measuring a duration) and that is entered as an actually measured value (measurement datum) in the determination of a »Metric.

Measurement data types

  • are absolute values,
  • are obtained by measurements on the project, product or process,
  • may refer for example to times, phases, products or organizational areas.

»Measurement Data Types may also be "soft", i. e. they result from informal surveys and individual assessments, for example »Risk Probability low/medium/high.

Measurement Data Types

See »Measurement Data Types.

Method Reference

A »Method Reference describes a class of methods that may be used to carry out activities or prepare products.

Metric

Synonymous to: characteristic numbers

A »Metric describes a quantitative measure for a feature of a project, a »Work Product or a process.

  • Metrics are derived from »Measurement Data Types or other metrics (e. g. formulas, percentages, comparisons).
  • A measurement data type may also be a metric.

Organization-Specific Process Model

See »Process Model, Organization-Specific.

Process Compliant to the V-Modell

A process is said to be compliant to the V-Modell if it fulfills the quality requirements of the V-Modell XT with regard to description techniques, results and sequences. The expected results and the requirements posed on the sequences are determined by the V-Modell XT »Reference Model. The »V-Modell®XT Konformität is demonstrated within the framework of a »V-Modell XT Compliance Test.

Processed

A »Work Step processes a topic, i. e. it participates in its completion.

Process Model, Organization-Specific

The Organization-Specific Process Model is used to introduce, establish and continuously improve a process improvement method in an organization. The approach defined at this point is used in two situations:

  • During the initial introduction of organization-wide process descriptions and their implementation.
  • During repeated execution of an organization-wide process improvement program.

The continuous improvement process is based on the »V-Modell with all its subprocesses, »Work Products and Activities. Within the framework of the introduction of an Organization-Specific Process Model, the V-Modell may be adapted to the organization and also supplemented by the organization's own processes. The units that in this connection belong to the organization have to be determined at the start of the improvement project.

Process Module

The modular unit of the »V-Modell. The V-Modell consists of »Process Modules. Process Modules are also used to prepare a project-specific or »Organization-Specific Process Model.

A process module combines different activity process modules to a modular unit. Therefore also »Work Products are indirectly assigned to a process module, because these products are in turn unambiguously assigned to continuing activities or to finishing activities.

Process Module Map

In the »Process Module Map the dependencies of the individual »Process Modules are graphically visualized to give the user quickly a general idea.

Product Dependencies, Content-Related

A content-related product dependency describes the connection between several »Work Products with regard to contents. A »Content-Related Product Dependencies exists for example if a change of a »Work Product will entail a change of another product.

Product Dependency

A »Product Dependency describes a condition that two or more »Work Products have to meet to be consistent. A product dependency may exist both within a »Process Module and between products of different process modules.

A distinction is made between tailoring-related product dependencies, generative product dependencies, relevant product dependencies, structural product dependencies and content-related product dependencies.

Product Dependency, Generative

Based on an initial product, a generative product dependency describes a condition; when this condition occurs, a target product has to be generated.

Product Dependency, Relevant

A »Product Dependency is called relevant, if the »Work Products concerned have the state »Finished. Besides only those product dependencies are considered that are included in the selected »Process Modules.

Product Dependency, Structural

Structural product dependencies (also called structural dependencies) structure products and relate them to each other. Thus there is for example a structural dependency that states that a »Software Unit consists of »Software Components.

Product Dependency, Tailoring-Related

Tailoring Product Dependencies describe the relations of »Work Products to process modules that are relevant to »Tailoring. Thus for example the identification of hardware parts within the framework of system design entails the use of the »Process Module »Hardware Development.

Product Group

see »Discipline.

Product Instance

A Product Instance is understood to be a concrete occurrence of a product type, for example a specific document. Refer to »Product Type for an example.

Product State

»Work Products have a product state that may be changed by activities. A distinction is made between the three product states »In Processing, »Submitted and »Finished.

Product Structure

The term »Product Structure is understood to be the number of »Product Instances of a project and their relations.

Product Type

A Product Type generically describes »Product Instance that may emerge during a development process.

Example: The product (more exact: Product Type) Meeting Document describes all meeting documents created within the project. A single minutes of a meeting document is a product instance of the product type Meeting Document.

Product Version

The Product Version is an identifyable and reproducable processing state of a product artefact. A Product Version has exactly one product state.

Project

According to »IPMA, a project is understood to be a singular entirety of coordinated activities with specific starting and end points that are carried out by a person or organization with the aim to achieve specific targets with regard to schedule, cost and performance.

Project Characteristic

A project is characterized by several »Project Characteristics. For the preparation of an »Application Profile, a value that has to be selected from a number of possible values is inserted into each Project Characteristic. Examples of Project Characteristics include »Security (Acquirer) or »Subject of the Project. The selected »Project Type and the selected »Project Type Variant determine if the »V-Modell User must assign a value to the respective Project Characteristic during the Tailoring process.

Project Compliant to the V-Modell

A project is said to be compliant to the V-Modell, if it includes at least the »Process Modules and »Work Products of the »V-Modell Core and if it takes into account each »Relevant Product Dependency during the development.

Project Execution Strategy

A »Project Execution Strategy defines a sequence in which the »Decision Gates relevant to the project have to be passed through. It is determined based on the selection of a »Project Type Variant and the assignment of all conditional »Project Characteristics.

Project Progress Stage

A »Project Progress Stage characterizes a particular time in the project at which a specific decision is made and thus a »Project Section is finished. Therefore a Project Progress Stage is always achieved when a »Decision Gate is successfully passed through.

Project Section

A »Project Section is the period of time between two successive »Decision Gates.

Project-Specific Adaptation of the V-Modell

See »Tailoring.

Project-Specific V-Modell

See »Tailoring Result.

Project Stage

A »Project Stage is the time interval between two (partial) deliveries by a supplier.

Project Type

In the V-Modell essentially a distinction is made between four different »Project Types:

  • System Development Project (Acquirer),
  • System Development Project (Supplier),
  • System Development Project (Acquirer/Supplier) - aquirer and supplier within the same organization (without contract),
  • Introduction and maintenance of an organization-specific process model.

The Project Type also determines the minimum quantity of project characteristcs, which must be provided with a value during the Tailoring process.

Project Type Variant

A Project Type Variant shapes a »Project Type . In the Tailoring process, the selection of the Project Type Variant finally determines the selection of the »Process Module , »Project Characteristic and sequence of operations (components of the »Project Execution Strategy ), which complement the Project Type.

Prototypic Development

see »Development, Prototypic.

Reference Model

The V-Modell XT Reference Model defines the minimum contents and relations required to ensure compliance, which must be covered by a process compliant to the V-Modell.

Relevant Product Dependency

See »Product Dependency, Relevant.

Residual Risk

In risk management the risk that remains after the implementation of appropriate preventive measures is called »Residual Risk.

Responsible Person

The term responsible is used for such »Role, which are responsible for the contents of a »Work Product and are liable for the decisions documentet within those products. Upon creation the responsible person assumes the main role in coordination and distribution of the necessary tasks and in tracing product state.

Responsible for an »External Product are those roles, which are responsible for the reception of the product and their further distribution within the Project.

Risk Class

»Risk Class es permit the priorization of potential risks. They are determined individually in an organization or a project. Risk classes facilitate the decision on whether and what measures are to be selected as a reaction to risks. Within the framework of risk management, risk classes are frequently based on the degree of risk and the project volume. Typical risk classes are for example:

  • Tolerable: the degree of risk involved is less than 0.1 percent of the project volume,
  • Undesirable: the degree of risk involved is larger than 0.1 percent and lesser than 1 percent of the project volume,
  • Critical: the degree of risk involved is larger than 1 percent and lesser than 10 percent of the project volume,
  • Catastrophic: the degree of risk involved is larger than 10 percent of the project volume.

Risk Damage

The »Risk Damage is the estimated damage connected with a risk in the project in case of damage. The possible damage is shown in monetary units (e. g. in T). Damage that cannot be estimated in monetary units (for example image loss) is to be monetarized to the maximum extent by using auxiliary quantities, e. g. image loss may lead to a drop in sales that can be expressed in monetary units.

Risk Probability

The »Risk Probability is the estimated probability of the occurrence of a risk.

Role

A role is a description of a number of tasks and responsibilities within the framework of a project and an organization.

By defining roles it is achieved that the »V-Modell is independent of the organizational and project-specific framework conditions. The assignment of organizational units and people to the roles is made at the start of a project.

Safety

See »Functional Safety.

Safety and Security

The term Safety and Security includes the terms functional safety (Safety), information security (Security) and data protection.

In this context Safety stands for procedural or operational safety and the aspects of reliability, fault tolerance and correctness. This status depends on measures limiting the risk of a personal injury or material or immaterial damage to an acceptable level.

On the other hand, Security describes the state that ensures the availability, integrity, authenticity and confidentiality of information when IT systems are used. This state results from IT measures and personal, material and organizational measures. In this context

  • availability is the state that guarantees the required usability of information, IT systems and components;
  • integrity is the state that excludes unauthorized and forbidden modifications of information and IT systems or components;
  • authenticity is the state in which required or assured characteristics or features of information and physical connections can be both authentically identified by the user and proven to third parties;
  • confidentiality is the state that excludes unauthorized collection or gathering of information.

The purpose of data protection is to protect the individual against his right to privacy being impaired through the handling of his personal data. (Reference: Bundesdatenschutzgesetz (Federal Data Protection Act)).

Safety and Security Level

A safety and security level is a level which is assigned to a unit considered (physical system/system element or logic function/functional chain) and provides a discrete measure

  • for a potential hazard (towards the outside) for persons, environment or goods during the operation of or in case of a loss of availability (failure, non-accessibility, etc.) or malfunction of the respective unit considered and
  • for the threat to the system (from the outside) during operation if the unit considered is attacked by espionage, sabotage, manipulation etc. in combination with the sensitivity (the value) of the information to be protected, which is handled (processed, transmitted, stored) by the unit considered.

In addition to the known hazards resulting from failures or malfunctions, the operation of a system alone may already pose a hazard: Due to their design and function, vehicles, rocket launchers or X-ray machines endanger operators, bystanders and environment even if they function properly.

The sensitivity of informationen can be specified by laws (Data Protection Act etc.) or official regulations (protection of classified material etc.) or result from business operations (e.g. account data in banks or insurance companies, patent administrations in a research enterprise). In any case, it is important to protect (high) material and immaterial values against (significant) risks (manipulation, misuse, espionage, etc.).

Security

See »Information Security .

Segment

A »Segment is an important part of a »System, presenting a hierarchy level below the »System itself. It is the realization of a part of the »System. »Segments may be subdivided hierarchically into additional »Segments.

Software Element

The term »Software Element is a generic term which may designate all system elements beginning with the »Software Unit level in the hierarchy of »System Elements: »Software Unit, »Software Component, »Software Module, and »External Software Module.

Software Module, external

The product »External Software Module comprises system elements (»Software Module , »Software Component) which are not developed within the scope of the project. An »External Software Module is a functional element which can be described autonomously. An external software module may be an off-the-shelf product, a unit furnished by the supplier, a re-usable component developed in advance, an adjacent system or the result of a sub-contract.

Static Tailoring

Static »Tailoring are the tailoring activities carried out during project initialization in order to draw up as soon as the projects starts a list that includes the activities to be carried out and the products to be prepared and that is clear and can be handled.

Structural Product Dependency

See »Product Dependency, Structural.

Sub-Acquirer

A »Supplier is called a »Sub-Acquirer if he himself awards parts of the subject matter of the contract as »Acquirer to a »Sub-Supplier in order to fulfill the »Contract with his »Acquirer.

Submitted

This defines a »Product State of a »Work Product that is submitted for evaluation through independet quality assurance. Depending on the results of the evaluation, the subsequent product state is set in the »Product Library.

Sub-Supplier

A »Sub-Supplier is the supplier in a contract, i. e. the organization that provides a »System Element or subsystem to the »Sub-Acquirer (DIN EN ISO 8402).

Supplier

A supplier is understood to be the supplier in a contract, i. e. the organization that provides the »Acquirer with a »Work Product (DIN EN ISO 8402).

System

The system is an integral whole with the capability to meet specified requirements or targets. It represents the subject matter of the order agreed between the acquirer and the supplier. The system consists of descriptions and/or realizations of hardware, software and/or logistic elements.

System Element

The term »System Element is a generic term which may designate all elements to be realized during »System Development. This may include »System, »Enabling System, »Segment, »External Unit, »Hardware Unit , »Software Unit, »Hardware Component, »Software Component, »Hardware Module, and »Software Module.

Tailoring

Beyond the literal meaning of the term itself, »Tailoring means in the context of the»V-Modell not only "cutting off" parts, but also "adapting" the V-Modell. Usually the V-Modell is adapted to a concrete project by adding »Process Modules. Adaptations within the process modules are to be considered exceptions to the rule. In addition to the selection of the process modules, the Tailoring process also determines the »Project Execution Strategy . The selection of the »Project Type and a »Project Type Variant determine the selection of the process modules and the project execution strategy.

Depending on the progress of the project, a distinction is made between

Tailoring-Related Product Dependency

See »Product Dependency, Tailoring-Related.

Tailoring Result

The »Tailoring Result determines the »Process Modules that are to be used in the project. The Tailoring Result may be both a result of the static »Tailoring at the start of the project and a changed Tailoring Result caused by »Dynamic Tailoring during the execution of the project.

Test

Tests are regarded as special form of evaluation which evaluates the execution behavior of »Software Elements.

Test case

A test case is a special form of evaluation case intended to evaluate the execution behavior of »Software Element s.

Tool Reference

A »Tool Reference describes a class of tools that may be used for carrying out activities or preparing products.

Topic

A topic is unambiguously assigned to a »Work Product, which for its part may consist of any number of topics. A topic is content-related and complete in itself. The topics of a product have to be seen as a listing of the essential contents of the product. Topics are processed by »Work Step.

Topics

See »Topics.

Trigger

A »Trigger describes an event that triggers an »Activity. Triggers are used for example during the planning and execution of risk avoidance and risk reduction measures.

V-Modell

The V-Modell is a guideline for the planning and execution of development projects, which takes into account the whole life cycle of the system. In this process the V-Modell defines the results that have to be prepared in a project and describes the concrete approaches that are used to achieve these results. The V-Modell also defines the responsibilities of the individual participants in the project.

V-Modell, Advanced

For the maintenance and the further development of the »V-Modell a procedure is defined that consists of two stages. The V-Modell may be changed and extended in comparatively short intervals that are suitable for the short innovation cycles of information technology.

For this purpose accordingly to the preparation of an organization-specific process model an advanced V-Modell, respectively parts of an advanced V-Modell, is developed. These change proposals and suggestions for further development are submitted to the »V-Modell Change Conference (Änderungskonferenz des V-Modells (Äko)). »Äko then decides whether the changes are adopted in the V-Modell. In this process changes and extensions may only affect »Process Modules, Project Execution Strategies, »Decision Gates, »Project Characteristics and »Mapping to Standards.

Changes that go beyond these limits, such as changes to these »Fundamentals of the V-Modell, fall under the second stage of this procedure. Such changes have to be made in a separate review and coordination process together with the »V-Modell Users within the framework of an update project.

V-Modell Core

The »V-Modell Core forms the basis of each »Application Profile. It determines a number of »Process Modules that have to be used in each »Project Compliant to the V-Modell.

V-Modell Project

A »V-Modell Project is a project that is executed as »Project Compliant to the V-Modell .

V-Modell Reference

A V-Modell Reference defines a specific grouping of the contents of the »V-Modell. The descriptions and relations of the individual »Work Products, Activities, »Roles etc. do not change. However, they are regrouped within the framework of their dependencies and, if required, presented in a shortened form. Thus adapted presentations of the same contents can be provided for different application purposes.

V-Modell References are implemented in the printed version of the V-Modell in different parts of the V-Modell.

V-Modell User

Persons who are concerned with the execution of »V-Modell Projects, i. e. who are involved in V-Modell projects, are called »V-Modell Users.

V-Modell XT

The addendum "XT" to »V-Modell stands for "extreme tailoring" or for "extendable".

V-Modell XT Assessment

The V-Modell XT Assessment checks if a »Process Compliant to the V-Modell of an organization is really applied. Thus, it provides the practical part, which is not included in the »V-Modell XT Compliance Test. After successful completion of an assessment, the certificate "V-Modell XT Pur" (cf. »Zertifizierungsprogramm) will be awarded.

V-Modell XT Compliance Test

A V-Modell XT Compliance Test is intended to check the »V-Modell®XT Konformität of a process deviating from the (Standard) V-Modell XT. If the process is compliant to the V-Modell XT, it may be used - in consultation with the Acquirer - instead of the V-Modell XT in projects, for which the V-Modell XT is required.

In the Compliance Test, a questionnaire is used in order to determine if the respective process fulfills the quality requirements of the V-Modell XT with regard to description techniques, results and sequences. The expected results and the requirements posed on the sequences are determined by V-Modell XT »Reference Model.

Weit e.V.

The Weit e.V. is a registered association. The main focus of this assosiation lies in the maintenance and further development of the V-Modell XT. The Weit e.V. was foundet in 2008 by the "Weit" development project partners. Members of the Weit e.V. consist of representatives of industry, government institutions and universities.

Work Package

A »Work Package is a project-specific grouping of activity models with regard to contents.

For example, configuration management »Activity Instance may be grouped into a work package, because a detailed scheduling of these activity models may possibly not be necessary.

Work Product

A distinction is made between »Product Type and »Product Instance. The exact meaning of the term Work Product depends on the context it is used in. Not only the system to be developed, but also all documents, evaluation protocols, software modules, in short: All kinds of artefacts are named Product Type or even just Product within the context of the V-Modell XT.

Work Product, External

»Work Products (e.g. »External Unit, »External Hardware Module, or »External Software Module) that may be prepared outside the framework of the »V-Modell Project. The »V-Modell XT defines responsible »Role for external products, but it does not necessarily define participating roles and activities.

Work Product, Initial

The term »Initial Product stands for a »Work Product that has to be prepared in each case and exactly once.

Work Step

A Work Step belongs to exactly one »Process Module and is always assigned to an »Activity. Work Steps process »Work Products and »Topics. A Work Step is a description of how a task, which typically turns up in a project or an organization, has to be performed. Thus Work Steps are comparable with a work instruction that has to be executed fully for the processing of one or more product process modules.