Page 37 - Methodology for inter-operator and cross-border P2P money transfers
P. 37
17.2.2 DAL and TAL validity checking validation is required to make sure this indicator is
In order to correctly combine the data from different indeed unique, and data can be assigned without
sources (e.g., T1 to T6 from the A-party side with T7 creating gaps or duplicates.
from the B-party side), information about the pairing It is also helpful to produce unique scenario identi-
of teams, and temporal assignment to DFS testing fiers as numbers. A scenario name will typically be
scenarios, is required. This information is provid- a rather long string of text which may be impracti-
ed by the DAL (see also section 11.7) and TAL (see cal to be used in dense tables or graphs. A scenario
section 11.1). Therefore, DAL and TAL are also import- index, in combination with a look-up table, makes
ed to the database, and after validity checking, typi- labelling easier.
cally processed into respective internal tables with For TAL validation, it is helpful to create a visualiza-
added (constructed) content. tion of the TAL in the form of a GANTT diagram as
In order to process data, a unique scenario descrip- shown in the example below. With the help of such
tor is required which is used to aggregate (group) a visualization, it can easily be checked if all scenar-
data to respective KPI. Depending on the actual TAL io/time ranges are present and consistent. Also, the
structure, such a descriptor can either be included source table for this visualization can be used to
in the TAL directly, or – preferably – be constructed check the scenario names for uniqueness.
in the data base from basic elements. In any case,
Figure 14 – Example of a GANTT visualization of a TAL
17�3 Data Processing The basis of these join operations is information
A good practice for data processing is to import data relating the data items to scenarios. This is done in a
from MSW and network background testing into a multi-step operation. In the first step, technical iden-
central database, and run the final processing there. tifiers are used to connect to the configurations or
In the first step of processing, MSW and network owner teams. This can be done by creating a look-up
KPI are combined (joined) with respective scenario table from the DAL with respective join operations,
and team information. In the second step, respective or by assigning these elements directly in respec-
grouping of DFS and network KPI is done based on tive SQL statements when the processed MSW and
this information. network KPI tables are created.
Methodology for inter-operator and cross-border P2P money transfers 35