2.2 Relações Conhecidas (Visualização e Informação)

2.2 Relações Conhecidas

2.2 Podemos identificar as relações conhecidas destes dados através de técnicas de visualização?

Antes de visualizar as relações já conhecidas descritas no item 1.3 vamos eliminar alguns dos ruídos que podem nos atrapalhar na interpretação dos dados.

Remover dados de falhas, uma vez que as relações conhecidas não necessariamente são válidas nos casos de falhas.
Aplicar, nesta etapa, as técnicas apenas aos atributos pertencentes às relações conhecidas e não ao conjunto de dados todo.
Ordenar os dados pela hora de forma crescente (campo Data).

Vamos agora observar os gráficos de dispersão para as relações conhecidas:

RndTrp:

RndTrp = KPI1 + KPI2 + KPI3 + KPI4:

Note que, com exceção da KPI3, é possível perceber uma certa relação entre as KPIs e o RndTrp. O fato da relação da KPI3 não aparecer é justificável, pois a KPI3 é a unica que não depende de tempo da rede, assim, possui tempos de 30 a 50 vezes menor que os tempos das demais KPIs, explicando sua pouca ou quase nula expressão na resultante RndTrp.

Pudemos assim observar, através da visualização do gráfico de dispersão, as relações já conhecidas das KPIs e do RndTrp.

KPI1:

KPI1 = R-TonePlayTime - R-KeyPressTime + X

Note que não foi possível observar as relações entre KPI1 e os outros parâmetros. Recorremos ao gráfico de glifos estrela para buscar alguma explicação para esta incoerência:

Observamos neste gráfico que um "leque" vai crescendo. Os atributos relacionados ao "leque" são justamente os que mapeiam "tempo". O tempo mapeado tem sua origem no momento em que o telefone é ligado (note que os telefones foram ligados 4 vezes durante a coleta, fazendo com que o leque desaparecesse 3 vezes no gráfico). Percebemos assim a necessidade de converter os dados absolutos de tempo em dados relativos. Para converter de forma correta temos que levar em conta as "constantes de hardware" e as "constantes de sincronismo", lembrando que as constantes de sincronismo podem variar de teste para teste.

Constante de HW:

Sendo KPI1 = [R-TonePlayTime] - [R-KeyPressTime] + Constante de HW, então:

Constante de HW = KPI1 - ([R-TonePlayTime] - [R-KeyPressTime] )

consideremos 3 amostras:

Constante de HW = 4444 - (100997 - 96553) = 0

Constante de HW = 1337 - (164102 - 162765) = 0

Constante de HW = 1205 - (2460788 - 2459583) = 0

Constatamos que as constantes de hardware não estavam sendo consideradas nestas amostras.

Constante de Sincronismo:

Sendo KPI2 = [L-RTPRecTime] - [R-RTPRecord] - Constante de Sincronismo

Constante de Sincronismo = [L-RTPRecTime] - [R-RTPRecord] - KPI2

Calcularemos a constante de sincronismo para cada amostra.

Vamos utilizar como referência o primeiro dado de tempo de cada amostra, no caso, R-KeyPressTime, lembrando que, para os dados do telefone 2, será necessário utilizar a constante de sincronismo.

Após a conversão dos dados o gráfico de glifos estrela ficou assim:

É possível notar agora que os glifos estão mais uniformes, e o "leque" crescente desapareceu. Agora poderemos continuar nossas validações.

KPI1:

KPI1 = R-TonePlayTime - R-KeyPressTime + X

Agora a relação fica evidente, lembrando que como R-KeyPressTime continua absoluto, não é possível relacioná-lo.

KPI2:

KPI2 = L-RTPRecTime - R-RTPRecord + X

Aqui também é possível identificar facilmente a relação entre KPI2 e L-RTPRecTime, identificando este como possuindo o maior peso na composição do valor da KPI2.

KPI3:

KPI3 = L-TonePlayTime - L-KeyPressTime + X

Neste caso, como a KPI3 é composta apenas por tempos de processamento interno do telefone, tanto L-KeyPressTime como L-TonePlayTime possuem valores muito próximos, dificultando assim a observação da relação entre os dados.

KPI4:

KPI4 = R-RTPRecTime - L-RTPRecord - X

Aqui também é possível identificar facilmente a relação entre KPI4 e R-RTPRecTime, identificando este como possuindo o maior peso na composição do valor da KPI4.