Universidade de Brasília FGA Medição e Análise de Software Alunos: Cleiton Gomes e Hebert Douglas. Expert FGA: Medição no Mercado de Moedas E3M



Documentos relacionados
ENGENHARIA DE SOFTWARE I

Conteúdo. Disciplina: INF Engenharia de Software. Monalessa Perini Barcellos

Seção 2/E Monitoramento, Avaliação e Aprendizagem

APLICACAÇÃO DE METRICAS E INDICADORES NO MODELO DE REFERENCIA CMMI-Dev NIVEL 2

ISO/IEC 12207: Gerência de Configuração

PLANOS DE CONTINGÊNCIAS

3 Qualidade de Software

O processo de melhoria de processo

MODELO CMM MATURIDADE DE SOFTWARE

ADM041 / EPR806 Sistemas de Informação

Gerenciamento de Projetos Modulo II Ciclo de Vida e Organização do Projeto

MUDANÇAS NA ISO 9001: A VERSÃO 2015

UNIVERSIDADE FEDERAL DO PARANÁ UFPR Bacharelado em Ciência da Computação

PROCESSO DE DESENVOLVIMENTO DE SOFTWARE. Modelos de Processo de Desenvolvimento de Software

AUTOR: DAVID DE MIRANDA RODRIGUES CONTATO: CURSO FIC DE PROGRAMADOR WEB VERSÃO: 1.0

Pós-Graduação em Gerenciamento de Projetos práticas do PMI

Governança de TI. ITIL v.2&3. parte 1

ADMINISTRAÇÃO I. Família Pai, mãe, filhos. Criar condições para a perpetuação da espécie

ARCO - Associação Recreativa dos Correios. Sistema para Gerenciamento de Associações Recreativas Plano de Desenvolvimento de Software Versão <1.

Pontos de Função. André Chastel Lima Andréia Ferreira Pinto Diego Souza Campos. Engenharia de Software Mestrado Ciência da Computação - UFMS

DIMENSIONANDO PROJETOS DE WEB-ENABLING. Uma aplicação da Análise de Pontos de Função. Dimensionando projetos de Web- Enabling

QUALIDADE DE SOFTWARE

UNIVERSIDADE FEDERAL DO PARANÁ UFPR Bacharelado em Ciência da Computação

GARANTIA DA QUALIDADE DE SOFTWARE

Gestão do Conhecimento A Chave para o Sucesso Empresarial. José Renato Sátiro Santiago Jr.

Podemos encontrar uma figura interessante no PMBOK (Capítulo 7) sobre a necessidade de organizarmos o fluxo de caixa em um projeto.

Análise e Desenvolvimento de Sistemas ADS Programação Orientada a Obejeto POO 3º Semestre AULA 03 - INTRODUÇÃO À PROGRAMAÇÃO ORIENTADA A OBJETO (POO)

Modelo Cascata ou Clássico

Introdução Visão Geral Processos de gerenciamento de qualidade. Entradas Ferramentas e Técnicas Saídas

OCOMON PRIMEIROS PASSOS

Processos Técnicos - Aulas 4 e 5

Requisitos de Software. Teresa Maciel DEINFO/UFRPE

Modelos de Sistema by Pearson Education. Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 8 Slide 1.

PLANEJAMENTO OPERACIONAL: RECURSOS HUMANOS E FINANÇAS MÓDULO 16

Mídias sociais como apoio aos negócios B2C

Projeto de Sistemas I

CHECK - LIST - ISO 9001:2000

Introdução ao Aplicativo de Programação LEGO MINDSTORMS Education EV3

Decidir como medir cada característica. Definir as características de qualidade. Estabelecer padrões de qualidade

Referências internas são os artefatos usados para ajudar na elaboração do PT tais como:

Engenharia de Software III

Tecnologia em Gestão Pública Desenvolvimento de Projetos - Aula 9 Prof. Rafael Roesler

Fábrica de Software 29/04/2015

No mundo atual, globalizado e competitivo, as organizações têm buscado cada vez mais, meios de se destacar no mercado. Uma estratégia para o

Solitaire Interglobal

COMO FAZER A TRANSIÇÃO

)HUUDPHQWDV &RPSXWDFLRQDLV SDUD 6LPXODomR

Estratégia de TI. Posicionamento Estratégico da TI: como atingir o alinhamento com o negócio. Conhecimento em Tecnologia da Informação

QUALIDADE DE SOFTWARE. Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 27 Slide 1

Wilson Moraes Góes. Novatec

Exemplos: Análise de Valor Agregado (Ex_vagregado.SPRJ)

Introdução à Computação

TRABALHOS TÉCNICOS Coordenação de Documentação e Informação INOVAÇÃO E GERENCIAMENTO DE PROCESSOS: UMA ANÁLISE BASEADA NA GESTÃO DO CONHECIMENTO

Ajuda ao SciEn-Produção O Artigo Científico da Pesquisa Experimental

Roteiro para a escrita do documento de Especificação de Requisitos de Software (ERS)

Na medida em que se cria um produto, o sistema de software, que será usado e mantido, nos aproximamos da engenharia.

Pesquisa com Professores de Escolas e com Alunos da Graduação em Matemática

Implantação de um Processo de Medições de Software

Sistemas Distribuídos

Projeto 2.47 QUALIDADE DE SOFTWARE WEB

Pesquisa Mercadológica. Prof. Renato Resende Borges


FATEC Cruzeiro José da Silva. Ferramenta CRM como estratégia de negócios

Atividade: COBIT : Entendendo seus principais fundamentos

3 Um Framework Orientado a Aspectos para Monitoramento e Análise de Processos de Negócio

Glossário Apresenta a definição dos termos, siglas e abreviações utilizadas no contexto do projeto Citsmart.

Processos de gerenciamento de projetos em um projeto

Guia para RFP de Outsourcing

Análise Estruturada de Sistemas

Algoritmos e Programação (Prática) Profa. Andreza Leite andreza.leite@univasf.edu.br

FACULDADE DE ADMINISTRAÇÃO E NEGÓCIOS - FAN CEUNSP SALTO /SP CURSO DE TECNOLOGIA EM MARKETING TRABALHO INTERDISCIPLINAR

Ponto de vista. Metodologia para um índice de confiança. E expectativas das seguradoras no Brasil

Manual do Painel Administrativo

Gerenciador de Log. Documento Visão. Projeto Integrador 2015/2. Engenharia de Software. Versão 2.0. Engenharia de Software

Análise de Sistemas. Visão Geral: Orientação a Objetos. Prof. José Honorato Ferreira Nunes honorato.nunes@bonfim.ifbaiano.edu.br

Por que sua organização deve implementar a ABR - Auditoria Baseada em Riscos

Feature-Driven Development

Requisitos de Software

MANUAL DE SUPORTE. Controle de Suporte. Este manual descreve as funcionalidades do controle de suporte.

Modelos de Qualidade de Produto de Software

Pós-Graduação em Gerenciamento de Projetos práticas do PMI

22/02/2009. Supply Chain Management. É a integração dos processos do negócio desde o usuário final até os fornecedores originais que

1. Introdução. 1.1 Apresentação

O modelo unificado de processo. O Rational Unified Process, RUP.

2 Diagrama de Caso de Uso

FACULDADE DE ENGENHARIA DE COMPUTAÇÃO. PROJETO FINAL I e II PLANO DE TRABALHO <NOME DO TRABALHO> <Nome do Aluno> <Nome do Orientador>

ISO Aécio Costa

Profissionais de Alta Performance

Análise do Ambiente estudo aprofundado

Engenharia de Software e Gerência de Projetos Prof. Esp. André Luís Belini Bacharel em Sistemas de Informações MBA em Gestão Estratégica de Negócios

Gerenciador de Log Documento Visão. Versão 2.0

Módulo 4. Construindo uma solução OLAP

Curso superior de Tecnologia em Gastronomia

Engenharia de Software

CAPABILITY MATURITY MODEL FOR SOFTWARE. Eduardo Mayer Fagundes

Prof. Marcelo Henrique dos Santos

SERVIÇO DE ANÁLISE DE REDES DE TELECOMUNICAÇÕES APLICABILIDADE PARA CALL-CENTERS VISÃO DA EMPRESA

Transcrição:

Universidade de Brasília FGA Medição e Análise de Software Alunos: Cleiton Gomes e Hebert Douglas Expert FGA: Medição no Mercado de Moedas E3M

1. Considerações iniciais Mensuração é uma tecnologia chave de todo programa de melhoramento. O paradigma Goal /Question /Metric (GQM) [BDR97,BCR94b,BW84] é uma abordagem orientada a metas para a mensuração de produtos e processos de software, suportando a definição top down de um programa de mensuração e a análise e interpretação bottom up dos dados de mensuração. Ela foi utilizada com sucesso em diversas empresas, como NASA SEL (EUA), Robert Bosch GmbH (Alemanha) [BDT96], Allianz Lebensversicherungs AG (Alemanha) [GRR94], Digital SPA (Itália) [FLM96], Motorola [Das92], Schlumberger (Holanda) [HOLR96]. O paradigma GQM é baseado no requisito de que a mensuração deveria ser orientada a metas, por exemplo., toda coleta dos dados deve ser baseada num fundamento lógico, que é documentado explicitamente. Essa abordagem tem várias vantagens: ela suporta a identificação das métricas úteis e relevantes tanto quanto suporta a análise e interpretação dos dados coletados. Ela permite um assessoramento da validade das conclusões a que se chegou e evita a resistência contra programas de mensuração. A figura 1 ilustra a abordagem do GQM. Figura 1: abordagem do GQM O projeto E3M surgiu na disciplina de Medição e Análise na Universidade de Brasília (campus Gama) e possui o GQM como paradigma abordado. No decorrer desse documento variáveis relacionadas ao projeto E3M serão descritas de forma simples e coesa.

2. Modelo de qualidade de Software A qualidade de um sistema de software pode ser entendida de diversas formas e utilizando diferentes abordagens. Entrentanto, a norma ISO/IEC 9126, ou conjunto de normas que trata deste assunto no âmbito da ISO, estabelece um modelo de qualidade com os seguintes componentes: Processo de desenvolvimento, cuja qualidade afeta a qualidade do produto de software gerado e é influenciado pela natureza do produto desenvolvido; Produto, compreendendo os atributos de qualidade do produto (sistema) de software. Estes atributos de qualidade podem ser divididos entre atributos internos e externos. Estes se diferenciam pela forma como são aferidos (interna ou externamente ao produto de software) e em conjunto compõem a qualidade do produto de software em si; Qualidade em uso que consiste na aferição da qualidade do software em cada contexto específico de usuário. Esta é, também, a qualidade percebida pelo usuário. 2.1 Modelo de Qualidade da Norma ISO 9126 A norma 9126 se foca na qualidade do produto de software, propondo Atributos de Qualidade, distribuídos em seis características principais, com cada uma delas divididas em sub características, conforme podemos ver na figura 2: Figura 2: norma 9126 no foco na qualidade do produto de software No nível mais alto temos as características de qualidade e nos quadros abaixo as suas sub características. Cada característica/sub característica compõe um Atributo de Qualidade

do software. As características temos uma sub categoria com o nome de Conformidade. A conformidade é utilizada para avaliar o quanto o software obedece aos requisitos de legislação e todo o tipo de padronização ou normalização aplicável ao contexto. 3. Mercado de Moedas O comércio de moedas ou foreign exchange (FOREX) é um dos mais antigos mercados do mundo e na atualidade o mais ativo e volumoso. Na época do império romano já existiam cambistas trocando moedas, que eram comuns nas feiras ou onde houvesse aglomerações de pessoas, especialmente viajantes. No mercado de moedas o especulador ou negociador não compra ou vende moeda como no mercado manual em que o negociador liga por telefone para um responsável realizar uma operação, apenas negocia a taxa de câmbio derivada das transações entre os bancos. No mercado interbancário, mais de três trilhões de dólares são negociados diariamente ao redor do mundo. O forex é todo eletrônico e abre na segunda feira pela manhã, no horário da Nova Zelândia, e só fecha as 17 horas de sexta feira, no horário dos Estados Unidos. Trata se de um mercado dinâmico porque as taxas de câmbio podem ser negociadas de qualquer lugar onde houver conexão com a internet. Uma prática bastante utilizada no tempos atuais são as pessoas utilizarem experts para realizarem operações. Experts são softwares que possuem modelos matemáticos como condições para entrar no mercado com uma compra ou venda. Em outras palavras, o expert recebe os dados do mercado dos preços das moedas no passado e com base nesses dados, efetua cálculos para prever o preço futuro da moeda e com base nessas informações realiza uma operação de compra ou venda. Sendo assim, é possível ganhar ou perder dinheiro com a operação efetuada. Se, por exemplo, o negociador compra dólar e o dólar começa a subir, o mesmo começa a ganhar dinheiro. Se o contrário ocorre, o dólar começa a cair e o negociador está comprado, ele começa a perder dinheiro. Várias moedas podem ser negociadas, como dólar, euro, yenen (moeda japonesa), dólar canadense e etc.

4. Projeto E3M O modelo de qualidade de software é essencial em diversos contextos da Engenharia de Software. No projeto E3M, isso não é diferente. O projeto E3M irá abstrair um atributo de qualidade de acordo com o tópico 2 deste documento. É importante ressaltar que outros atributos de qualidade podem ser levemente relacionadas no projeto, mas o foco é o atributo de desempenho. Logo, o projeto E3M irá abstrair as melhores métricas relacionadas ao desempenho do Expert Medição no mercado de moedas. Relacionado a isso, o processo GQM será incorporado pelo projeto E3M. 5. Visão Geral do Processo GQM O método GQM descreve o planejamento e execução de um programa de mensuração baseado no paradigma GQM. O escopo do método GQM inclui o planejamento, a execução do programa de mensuração, e a captura das experiências ganhas durante esse programa sob forma de modelos. As fases do processo GQM são orientadas ao Paradigma de Melhoria de Qualidade (QIP). Uma visão geral dos passos do processo de um programa de mensuração é dada na figura 3. Figura 3: Visão geral do GQM No começo do programa de mensuração, um estudo prévio é realizado para encontrar modelos de experiência relevantes baseados nas metas e características da organização e dos projetos. Um projeto piloto para a introdução do programa de mensuração é selecionado e caracterizado. Com base nessa informação, uma meta a ser atingida pelo programa de

mensuração é especificada, definindo precisamente objeto, objetivo, enfoque de qualidade, ponto de vista e contexto da análise. Com respeito à meta, um conjunto das medidas elevantes é derivado via perguntas e modelos, resultando em um plano GQM consistindo de uma meta, perguntas, modelos e medidas. 5.1. Visão Geral do Processo GQM do Projeto E3M A Visão Geral do Processo GQM do Projeto E3M é similar a visão tradicional do GQM, claro com suas características próprias. No projeto E3M, também é realizado o estudo prévio, identificação de metas para o desenvolvimento do plano GQM, desenvolvimento do plano de mensuração, análise e interpretação e o capturamento de experiências. Nesse estágio do projeto, a coleta de dados não seria viável e logo a mesma não irá ser especificada. 5.2. Estudo prévio E3M O objetivo do estudo prévio é a coleta de informação que é pertinente à introdução de um programa de mensuração na organização. No inicio da disciplina de Medição e Análise, realizada na UnB Gama, foi realizado um estudo prévio sobre o E3M para se verificar a viabilidade da realização do projeto. Como o expert, nada mais é que um software que realiza operações no forex e o mesmo pode ter atributos de qualidade muito bem explicitos, ficou evidente a viabilidade do projeto. 5.3. Identificação de Metas do GQM E3M Com base nas metas organizacionais e do projeto piloto, as metas a serem alcançadas pelo processo de mensuração são determinadas como uma base para o desenvolvimento de um processo de mensuração efetivo. Em outras palavras, depois de feito o estudo prévio é realizado um processo de mensuração para deixar mais claro o processo do GQM do projeto E3M. A tabela abaixo evidencia a dimensão, a definição e o exemplo para identificação das metas. Dimensão Definição Exemplo

Objeto de estudo Expert Medição Expert (software) que realiza operações de compra e venda Objetivo O objeto será analisado pelo motivo do mercado de moedas movimentar 3 trilhões de dólares por dia e diversos experts utilizados no mercado possuem atributos de qualidade inconsistentes. Minimizar as perdas ou maximas os ganhos no mercado. Enfoque de qualidade Os atributos que serão analisados será desempenho e confiabilidade. O fato de um expert ter um tempo de resposta maior pode significar milhões. Ponto de vista Os dados podem ser coletados pela própria ferramenta de negociação do mercado de moedas. Contexto O ambiente em que está sendo desenvolvido o projeto E3M é universitário, entretanto as métricas estudadas e/ou desenvolvidas podem ser aplicadas ao mercado. Os dados são fornecidados em.csv ou.txt e podem ser utilizados facilmente Uma operação de compra ou venda pode ser realizada com maior segurança em diversos contextos que o mercado de moedas oferecer. O quadro acima pode ser encapsulado de forma que as informações fiquem mais diretas conforme segue abaixo. Analisar Com o propósito de Com respeito a Do ponto de vista da No contexto de Robos Experts Entender desempenho nas transações equipe do projeto Mercado de moedas e Engenharia de Software

Analisar Com o propósito de Com respeito a Do ponto de vista da No contexto de Robos Experts Melhorar percentual de lucro investidor Mercado de moedas e Engenharia de Software 6. Desenvolvimento do Plano de Mensuração Planos GQM contém a informação necessária para planejar mensuração e analisar e interpretar os dados coletados. O plano define precisamente porque as medidas são definidas e como elas serão usadas. As perguntas identificam a informação necessária para atingir a meta e as medidas definem operacionalmente os dados a serem coletados para responder as perguntas. O modelo usa os dados coletados como entrada para gerar respostas às perguntas. Uma ferramenta para a aquisição e estruturação de conhecimento durante as entrevistas é o Abstraction Sheet. O abstraction sheet é um documento de uma página com quatro quadrantes. A seguir segue a tabela Abstraction Sheet do projeto E3M. Objeto Objetivo Enfoque de Qualidade Ponto de vista Contexto Robo Expert Entender Desempenho nas transações Equipe de projeto Mercado de moedas/engenharia de Software Fatores de Qualidade Fatores de Variação Eficiência do programa Eficácia do programa Tempo de resposta O faturamento do robô tipo de paradigma adotado: OO ou estruturado Modelo matemático utilizado Plataforma Corretora (instituição financeira) País onde está a corretora Hipotese de Linha Base Impacto na Hipotese de Linha Base

Tempo de resposta em linguagem estruturada 0,2 segundos Tempo de resposta em linguagem orientada a objetos 0,7 segundos Lucro em linguagem estruturada em 1 ano é de 10% Lucro em linguagem orientada a objetos em 1 ano é de 7% O paradigma de programação utilizado influencia no desempenho do programa. O paradigma de programação utilizado altera a margem de lucro. Plataforma utilizada altera pouco a margem de lucro do robô. O modelo matemático influencia no lucro obtido. 6.1. Refinamento do Plano GQM do E3M O objetivo é a definição quantitativa da meta GQM em um conjunto de medidas via perguntas e modelos, com base nos fatores de qualidade e fatores de variação adquiridos durante as entrevistas. Neste passo o plano GQM é desenvolvido. Primeiro, as perguntas são derivadas, expressando a necessidade de informação em linguagem natural. Um exemplo de uma pergunta é: Quantos defeitos são detectados dependente do tipo da inspeção usada? A resposta para uma pergunta pode ser atingida através dos dados coletados e interpretados para as medidas derivadas através de modelos de qualidade. Através do Abstraction Sheet do projeto E3M é possivel derivar as perguntas no contexto do projeto conforme segue abaixo: 6.1.1. Questões Q1: O paradigma utilizado para a construção do projeto interfere no desempenho do software? Hipotése: Espera se um maior desempenho com a linguagem estruturada devido a menor complexidade dos programas. Q2: O padrão MVC melhora o desempenho do programa? Hipotése: A principio o padrão MVC não altera o desempenho do programa. Q3: O horário em que as transações são realizadas faz com que o robô realize mais operações? Hipotése: O mercado no período da manhã (horário da Inglaterra) é mais rápido, logo é de se esperar que o robô entre mais vezes no mercado. Q4. A máquina utilizada para rodar o expert pode influenciar no expert? Hipótese: A princípio não, pois a plataforma do mercado Forex não é pesada. Entretanto, é recomadável seguir as especificações fornecidas pelas corretoras do mercado.

Q5. O robô funciona em vários sistemas operacionais? Hipótese: O robô roda pelo menos no windows. Q6. A plataforma utilizada altera a lucratividade dos robôs? Hipótese: Com a mudança de plataformas pode ocorrer uma pequena variação no lucro. Q7. O modelo matemático pode influenciar na comparação das plataformas? Hipótese: O modelo matemático irá influenciar pelo fato de ter outros critérios de entrada e saída do mercado. Q8. A velocidade dos robos em paradigmas diferentes garantem maior lucratividade? Hipótese: Robôs que respondem mais rápido tem maior lucratividade. 7. Medidas M1 Tempo de resposta Nome Entidade Escala de medição Tipo de medição Classificação da medida Descrição Como medir Quando medir Diretrizes para interpretação Tempo de resposta Código (Produto) (interno) Absoluta Direta Objetiva O tempo de resposta do sistema é medido a partir do ponto no qual o usuário realiza alguma ação de controle até que o software responda com a saída ou a ação desejada. Contar o tempo que o sistema leva para executar o modelo matemático e realizar um evento de compra ou venda. Para realizar a contagem associar ao MQL4 e MQL5 um programa em C com a função de clock. Sempre que os robôs estiverem em execução. Deve se coletar no minimo 10 tempos. M2 Lucro por período de tempo

Nome Entidade Escala de medição Tipo de medição Classificação da medida Descrição Como medir Quando medir Diretrizes para interpretação Lucro por período de tempo selecionado. Produto Absoluta Indireta Objetiva Lucro é o retorno positivo de um investimento feito por um indivíduo, robô ou uma pessoa nos negócios. Calcular o valor de retorno do investimento de acordo com a margem de lucro, alavancagem e a variação do valor das moedas em um período de tempo previamente determinado. Fazer uso do simulador da própria ferramenta para realizar a medição. Quando o código estiver implementado e pronto para uso. Lucro deve ser maior que zero. 6. Coleta de Dados 6.1. Dinâmica da coleta Foram criados 4 robôs (dois com MQL4 e dois em MQL5), sendo que um robô era o MediaMovel. O mediamovel possui o modelo matemático a média móvel como critério de entrada no mercado. Foi feito um robô média móvel em MQL4 e um robô mediamovel em MQL5 e ambos foram comparados. Eles são exatamente iguais, os mesmos parâmetros, os mesmos critérios de entrada.a única diferença entre eles é o paradigma, pois o mediamovel MQL4 é estruturado (parecido com C) e o mediamovel MQL5 é orientado a objetos (muito parecido com C++). A mesma dinâmica foi adotada para o robô MacSimple. Foi feito um robô MacdSimple em MQL4 e outro em MLQ5 e ambos foram comparados para se obter o tempo de resposta e depois o lucro. O modelo matemático usado no MacdSimple é o stochastic. Os testes dos robos foram gravados e podem ser vistos no site: http://forex medicao.webnode.com/. Durante os testes foi escolhido o Robô MediaMovel para linguagem estruturada e linguagem OO. Foram usados diversos períodos de tempo para efeitos comparativos. Por exemplo, o robô mediamovel foi simulado na plataforma MQL4 com o período de tempo de um ano e o mesmo robô só que em MQL5 foi simulado também no mesmo período de um ano e os

resultado eram comparados. Outros períodos de tempo foram utilizados como 5 anos, 10 anos e todo o histórico do mercado de moedas. A mesma lógica foi utilizada com outro robô denominado MACDSimple. A seguir segue a imagem de uma simulação na plataforma FXDD com o robô MacdSimple. 6.3. Resultados do robôs em tempo de resposta Para se obter o tempo de resposta foi utilizado o robô MediaMovel como referência. Os tempos de resposta do robô mediamovel foram coletados tanto para o MQL4 quanto para o MQL5. Como a linguagem MQL4/MQL5 não possui nenhum recurso para medir o tempo de resposta, foi utilizado um programa em C para auxiliar nessa atividade. Quando o robô media móvel realiza um evento de compra ou venda, o programa em C começa a contar o tempo através da função clock. Após a venda ou compra ser efeada com sucesso, o programa C calculava o tempo de resposta do robô mediamovel. A seguir pode ser visualizado o código em C que coletava o tempo de resposta do robo mediamovel.

Quando o robô mediamovel faz uma operação de compra ou venda, ele registra no arquivo mediamovel.txt o valor de 1. Quando essa compra ou venda é feita com sucesso o robô vai no arquivo e muda esse valor para 0. Isso permite o programa em C ler o arquivo e obter o tempo de resposta. A seguir pode ser visualiza a tabela com o tempo de resposta do robô mediamovel tanto em MQl4 quanto em MQL5.

Tempo de resposta em segundos MQL4 Tempo de resposta em segundos MQL5 Data Horário 0,066000 0,4800 15/11/2013 03:57 0,067000 0,6130 18/11/2013 04:12 0,066000 0,7240 18/11/2013 05:23 0,066000 0,6140 20/11/2013 02:14 0,096000 0,4800 21/11/2013 09:45 0,067000 0,6170 21/11/2013 15:32 0,066000 0,7220 22/11/2013 01:13 0,066000 0,6180 25/11/2013 03:42 0,066000 0,4800 26/11/2013 03:45 0,067000 0,7240 26/11/2013 04:18 0,066000 0,7240 27/11/2013 05:12 0,066000 0,6140 27/11/2013 07:43 0,066000 0,7210 27/11/2013 09:42 0,067000 0,6170 27/11/2013 17:45 0,066000 0,7220 28/11/2013 02:43 0,066000 0,6190 28/11/2013 05:11 6.3. Resultados do robôs em lucro A seguir pode ser visualizada a tabela de desempenho do Robo MacdSimple na corretora Alpari. Linguagem Período em anos Lucro/Prejuizo em USD Corretora Forex MQL4 1 ano 212 Alpari Mt4

MQL5 1 ano 321 Alpari Mt5 MQL4 5 anos 1313 Alpari Mt4 MQL5 5 anos 1330 Alpari Mt5 MQL4 10 anos 2443 Alpari Mt4 MQL5 10 anos 1095 Alpari Mt5 MQL4 todo histórico 3579 Alpari Mt4 MQL5 todo histórico 2321 Alpari Mt5 A seguir pode ser visualizada a tabela de desempenho do Robo MacdSimple na corretora FXDD. Linguagem Período em anos Lucro/Prejuizo em USD Corretora Forex MQL4 1 ano 214 FxDD Mt4 MQL5 1 ano 323 FxDD Mt5 MQL4 5 anos 1304 FxDD Mt4 MQL5 5 anos 1321 FxDD Mt5 MQL4 10 anos 2439 FxDD Mt4 MQL5 10 anos 1082 FxDD Mt5 MQL4 todo histórico 3584 FxDD Mt4 MQL5 todo histórico 2337 FxDD Mt5 A seguir pode ser visualizada a tabela de desempenho do Robo MediaMovel na corretora Alpari. Linguagem Período em anos Lucro/Prejuizo em USD Corretora Forex MQL4 1 ano 2716 Alpari Mt4 MQL5 1 ano 338 Alpari Mt5 MQL4 5 anos 9280 Alpari Mt4

MQL5 5 anos 3328 Alpari Mt5 MQL4 10 anos 8447 Alpari Mt4 MQL5 10 anos 2213 Alpari Mt5 MQL4 todo histórico 1092 Alpari Mt4 MQL5 todo histórico 3211 Alpari Mt5 A seguir pode ser visualizada a tabela de desempenho do Robo MediaMovel na corretora FxDD. Linguagem Período em anos Lucro/Prejuizo em USD Corretora Forex MQL4 1 ano 2713 FxDD Mt4 MQL5 1 ano 339 FxDD Mt5 MQL4 5 anos 9289 FxDD Mt4 MQL5 5 anos 3321 FxDD Mt5 MQL4 10 anos 8452 FxDD Mt4 MQL5 10 anos 2221 FxDD Mt5 MQL4 todo histórico 1098 FxDD Mt4 MQL5 todo histórico 3231 FxDD Mt5 7. Análise e Interpretação Iniciou se a análise comparando se os tempos de resposta dos programas, para isso foram utilizados os robôs media móvel para MQL4 e MQL5.

O MQL4 apresentou uma média de tempo de 0,066 segundos com um desvio padrão de 0,0074, já o MQL5 possui uma média de tempo de 0,6175 com um desvio padrão de 0,0896. Comparando os tempos médios de cada uma das linguagens verifica se que o tempo de resposta do MQL5 é 9,35 vezes maior que o MQL4 (835% maior). Com base nisso e realizando a análise do gráfico acima verificou se que os tempos de resposta no MQL4 foram menores que no MQL5 em todas as datas analisadas. Esta análise confirma nosso hipótese inicial que o MQL4 estruturado é mais rápido que o MQL5. Conhecendo o tempo de resposta deu se inicio a coleta de dados para realizar a comparação entre os lucros gerados por cada plataforma em um determinado período de tempo. O objetivo principal é analisar se os dois robos com o mesmo modelo matemático e linguagens diferentes teriam uma margem de lucro diferente. Utilizando a tabela abaixo criou se um gráfico com a comparação entre o MQL4 e MQL5. Linguagem \ Período 1 ano 5 anos 10 anos Todo histórico MQL4 MacdSimple 212 1313 2443 3579 MQL5 MacdSimple 321 1330 1095 2321 MQL4 MediaMovel 2716 9280 8447 1092 MQL5 MediaMovel 338 3328 2213 3211

O gráfico acima deixa evidente que comparando se a as linguagens MQL4 e MQL5 com o mesmo modelo matemático, o MQL5 teve os resultados mais favoráveis em todos os períodos de tempo simulados. Essa confirmação se opõe a nossa hipotese que o programa em linguagem estruturada teria uma lucratividade maior que um orientado a objetos. O gráfico também confirma nossa hipótese inicial que com a mudança de modelo matemático os resultados seriam bastante diferentes. A exemplo se for analisado apenas as linhas do MQL5 o robô com o modelo média móvel teve lucro inferior em três das quatro simulações realizadas sendo melhor apenas na ultima simulaçao que leva em conta tod o período de tempo. Estas variações são normais e garante que a escolha de um modelo matemático é um fator muito importante para o êxito do investidor. As mesmas simulações foram efetuadas com o modelo matemático stochastic e em corretoras diferentes, para verificar se este fator de variação modificaria a lucratividade dos robôs utilizados. A partir dos dados da tabela abaixo plotou se um gráfico para verificar o comportamento das corretoras FxDD e Alpari. Corretora \ Periodo 1 ano 5 anos 10 anos Todo histórico Alpari Mt4 212 1313 2443 3579 FxDD Mt4 214 1304 2439 3584 Alpari Mt5 321 1330 1095 2321 FxDD Mt5 323 1321 1082 2337

Em ambas as linguagens percebe se através do gráfico que com a mudança de corretora os valores variam muito pouco, apresentando uma diferença quase imperceptível. A linha de comparação entre o Alpari Mt4 com o FxDD Mt4 estão quase sobrepostas evidenciando a pequena mudança de valores na troca de corretoras, o mesmo ocorre para o MQL5. A comparação entre as corretoras confirma nossa hipótese inicial que se houvesse diferença entre os resultados obtidos por diferentes corretoras eles seriam irrelevantes. Baseado em todas as análises efetuadas foi verificado que apesar da linguagem MQL4 ter um tempo de resposta menor em todas as simulações a MQL5 conseguiu obter uma margem de lucro maior. Ficou evidente que o tempo de resposta não é um fator determinante na escolha de um robô de linguagens e plataformas diferentes, o MQL5 se mostrou mais estável pois mesmo com um tempo maior de resposta sua lucratividade foi superior. Percebe se com a análise que não há apenas uma mudança de paradigma de programação entre o MQL4 e MQL5. A principio pode ter ocorrido apenas uma evolução na plataforma tornando o MQL5 melhor, mesmo com tempos de respostas maiores, ou pode ser que os simuladores do MQL5 não estão estáveis o suficiente. Para obter essas respostas é necessário a criação de um novo GQM que levasse em consideração estas duas variáveis e que a análise seja realizada com os robôs operando no mercado em tempo real. 7.1 Teoria de Rough Sets Para análise de dados podem ser aplicados, por exemplo, os testes ao respeito às hipóteses propostas no plano GQM do projeto E3M. O objetivo da análise é identificar padrões e relações entre atributos para permitir o estabelecimento de linhas base e a identificação de áreas problemáticas. A análise estatística pode ser aprimorada através de uma análise qualitativa, por

exemplo, usando a teoria de Rough Sets. O objetivo é gerar regras descrevendo e agregando resultados experimentais. A teoria de Rough Sets deriva regras se então agregadas que podem ser usadas formalmente como a base para a integração de conhecimento de um perito humano com as regras derivadas da análise de dados experimentais. Um exemplo dessas regras pode ser, SE (Tipo de versão = A) E (Número de modules novos = baixo) E (Número de LOC mudado = médio) ENTÃO (esforço = muito alto). No contexto do projeto E3M, pode abstrair as seguintes vertentes: Contexto 1 Contexto 2 Contexto 3 Contexto 4 SE o expert MediaMovel ou MACDSimple estiver sendo simulado na corretora FXDD ou Alpari E estiverem com as mesmas configuração, ENTÃO o desempenho deve ser similar. SE o expert em linguagem estruturada for mais rápida que o expert em linguagem OO E ambos os robôs estiverem com a mesma configuração, ENTÃO não significa que o expert mais rápido vai ganhar mais dinheiro. SE o período em que o robô expert em MQL4 e MQL5 forem atuar seja modificado E eles estejam utilizando o mesmo modelo matemático ENTÃO o MQL5 terá uma maior lucratividade. SE em uma simulação no mercado real o MQL4 obter mais lucro que o MQL5 ENTÃO os simuladores estão atuando de forma equivocada. 8. Capturação de experiências O objetivo do projeto E3M também é capturar explicitamente as experiências ganhas durante o programa de mensuração para reutilizar esse conhecimento em projetos de software futuros. Os dados coletados, analisados e interpretados no programa de mensuração são usados para construir modelos organizacionais, como, por exemplo, modelos de perfis tradicionais ou não (experts que agregam mais risco ou não). Em suma, o modelo GQM do projeto E3M pode trazer experiências para que possivelmente no futuro se elabore modelos mais consistentes. 9. Considerações finais O projeto E3M buscou através do GQM mensurar as variáveis atreladas ao projeto. Foi possível obter uma melhor compreensão do processo, como por exemplo, o entendimento da diferença dos resultados da comparação do paradigma OO com o paradigma estruturado.

Após serem definidas as metas e as questões do projeto E3M, foi possível realizar a coleta de dados e interpretar as mesmas de maneira adequada. Foi encontrado dificuldades no decorrer do projeto, como por exemplo, a falta de recurso para se medir o tempo de resposta na MQL4 ou MQL5. Mas, nesse caso utilizou se um programa em C como auxilio para se medir o tempo de resposta do robôs. Ou seja, linguagem C que mediu o tempo de resposta dos robôs através de uma comunicação de arquivos. O robô soltou resposta em um arquivo, o programa em C lia o arquivo e calculava o tempo resposta. Todos os resultados do trabalho E3M, estão no seguinte site http://forex medicao.webnode.com No site contém videos de vários testes, todo o material teórico, entre outras coisas interessantes para auxiliar no entendimento do projeto. De fato, só se pode controlar aquilo que pode ser medido. 10. Referências bibliográficas BASILI, Victor R. Software modeling and measurement: the Goal/Question/Metric paradigm. 1992. Paradigm. Technical Report CS TR 2956, Department of Computer Science, University of Maryland, MD 20742, September 1992. Software Engineering Laboratory An Operational Software Experience Factory. ACM,1992. Marciniak, editor, Encyclopedia of Software Engineering, volume 1. GQM no desenvolvimento de Software, Christiane Gresse von Wangenheim, 2000.