Defensa TFG predicción y optimización en sistemas de trading automáticos para mercados financieros

TRABAJO FIN DE GRADO
ESCUELA UNIVERSITARIA POLITECNICA
Departamento de Ciencias Politécnicas
Grado en Ingeniería Informática
Desarrollo de un software de predicción financiera
Autor:
D. José Carlos Cano Lorente
Directores:
Dr. D. José María Cecilia Canales
Dr. D. Horacio Pérez Sánchez
Murcia, Junio de 2015

Autorización
Dr. D. José María Cecilia Canales y Dr. D. Horacio Pérez Sánchez,
profesores de la UCAM
CERTIFICAN: que el Trabajo Fin de Grado titulado “Desarrollo de un
software de predicción financiera” que presenta D. José Carlos Cano Lorente,
para optar al título oficial de Grado en Ingeniería Informática, ha sido realizado
bajo su dirección.
A su juicio reúne las condiciones necesarias para ser presentado en la
Universidad Católica San Antonio de Murcia y ser juzgado por el tribunal
correspondiente.
Murcia, a de Junio de 2015

Agradecimientos
A mis directores de proyecto, José María Cecilia y Horacio Pérez, que
desde nuestra primera reunión para tratar el desarrollo de este TFG, mostraron
una gran confianza en lo que podríamos conseguir, y supieron transmitirme esa
ilusión. Sus enseñanzas e indicaciones han sido fundamentales para enfocar la
metodología y no perder de vista nunca los objetivos que perseguíamos.
A la empresa Artificial Intelligence Talentum, S.L., por haber colaborado
con la UCAM en definir este proyecto, y por darme la oportunidad de contribuir
humildemente en una parte del ambicioso proyecto del desarrollo de
herramientas de trading. Sus ánimos, desde nuestra primera entrevista, han
sido muy gratificantes.
A la Universidad Católica San Antonio de Murcia, por ofrecerme la
posibilidad de actualizar mi formación. Su plan de estudios on-line es de gran
calidad, y permite compaginar la vida profesional, familiar y académica de
muchas personas como yo.
Y a mi esposa y mis tres hijas, que me han acompañado con resignación
durante los dos últimos años en mis dedicación al estudio de las asignaturas y
a la elaboración de este TFG.

Índice de contenidos
Índice de contenidos ............................................................................................. 11
1 Introducción .................................................................................................... 25
1.1 Motivación ..................................................................................................25
1.2 Definición....................................................................................................26
1.3 Objetivos propuestos..................................................................................26
2 Estudio del mercado ....................................................................................... 29
2.1 Conceptos relevantes del dominio de la aplicación ...................................29
2.2 Relación con proyectos con la misma funcionalidad..................................35
2.3 Estudio de viabilidad...................................................................................37
2.3.1 Alcance del proyecto.............................................................................37
2.3.2 Estudio de la situación actual................................................................37
2.3.3 Estudio y valoración de las alternativas de solución.............................38
2.3.4 Selección de la solución.........................................................................38
3 Metodologías usadas...................................................................................... 41
3.1 Desarrollo en cascada o secuencial ............................................................41
3.2 Metodología Ágil.........................................................................................42
3.2.1 XP (Extreme Programming)...................................................................44
3.2.2 SCRUM...................................................................................................44
3.2.3 Otras metodologías ágiles.....................................................................47
3.3 Metodología elegida...................................................................................47
3.3.1 Los roles.................................................................................................48
3.3.2 Los eventos............................................................................................49
3.3.3 Seguimiento...........................................................................................49
4 Tecnologías y herramientas utilizadas en el proyecto .................................... 51
4.1 Cygwin.........................................................................................................51
4.2 VMWare Player...........................................................................................52

4.3 Eclipse .........................................................................................................52
4.4 Subversion...................................................................................................52
4.5 Python y Matplotlib ....................................................................................53
4.6 Libconfig......................................................................................................53
4.7 TA-Lib ..........................................................................................................54
4.8 Kunagi .........................................................................................................54
5 Estimación de recursos y planificación ........................................................... 57
5.1 Método de estimación utilizado.................................................................57
5.2 Planificación................................................................................................59
5.3 Valoración de la dedicación y coste económico.........................................64
5.3.1 Costes de material.................................................................................64
5.3.2 Costes de consultoría ............................................................................65
6 Desarrollo del proyecto................................................................................... 67
6.1 Preparativos................................................................................................67
6.2 Sprint 1........................................................................................................71
6.2.1 Sprint Planning ......................................................................................71
6.2.2 Sprint Review.........................................................................................74
6.2.3 Sprint Retrospective..............................................................................76
6.2.4 Demos....................................................................................................77
6.3 Sprint 2........................................................................................................79
6.3.1 Sprint Planning ......................................................................................79
6.3.2 Sprint Review.........................................................................................83
6.3.4 Demos....................................................................................................86
6.4 Sprint 3........................................................................................................89
6.4.1 Sprint Planning ......................................................................................89
6.4.2 Sprint Review.........................................................................................92
6.4.4 Demos....................................................................................................94

6.5 Sprint 4........................................................................................................95
6.5.1 Sprint Planning ......................................................................................95
6.5.2 Sprint Review.......................................................................................101
6.5.3 Sprint Retrospective............................................................................102
6.5.4 Demos..................................................................................................102
6.6 Sprint 5......................................................................................................104
6.6.1 Sprint Planning ....................................................................................104
6.6.2 Sprint Review.......................................................................................110
6.6.4 Demos..................................................................................................111
6.7 Sprint 6......................................................................................................113
6.7.1 Sprint Planning ....................................................................................113
6.7.2 Sprint Review.......................................................................................117
6.7.4 Demos..................................................................................................119
7 Pruebas y Despliegue de la solución............................................................ 121
7.1 Pruebas .....................................................................................................121
7.2 Despliegue.................................................................................................136
8 Conclusiones ................................................................................................ 137
8.1 Objetivos alcanzados ................................................................................137
8.2 Conclusiones del trabajo y personales .....................................................138
8.3 Vías futuras ...............................................................................................138
9 Bibliografía.................................................................................................... 141
10 Anexo I Diseño de la aplicación................................................................. 145
10.1 Gestión de memoria..............................................................................145
10.1.1 Datos históricos.................................................................................145
10.1.2 Nuevos indicadores ...........................................................................146
10.1.3 Datos de configuración y control del proceso...................................148
10.2 Proceso..................................................................................................151

10.3 Módulos.................................................................................................152
11 Anexo II Manual de Usuario ...................................................................... 155
11.1 Introducción ..........................................................................................155
11.2 Preparando la ejecución........................................................................156
11.3 Indicadores técnicos..............................................................................159
11.4 Definiendo los escenarios .....................................................................161
11.4.1 Indicadores técnicos..........................................................................161
11.4.2 Gráficos..............................................................................................163
11.4.3 Constantes.........................................................................................165
11.4.4 Operaciones.......................................................................................166
11.4.5 Precios ...............................................................................................168
11.4.6 Uniéndolo todo..................................................................................168
11.5 Escritura de fórmulas ............................................................................169
11.6 Ejecución ...............................................................................................170
11.7 Manejo de errores.................................................................................175
12 Anexo III Manual de Instalación................................................................. 177
12.1 Instalación en Linux...............................................................................177
12.1.1 Linux como máquina virtual sobre Windows (opcional)...................177
12.1.2 Instalación del IDE Eclipse (opcional)................................................188
12.1.3 Instalación de TA-Lib .........................................................................191
12.1.4 Instalación de libconfig......................................................................193
12.1.5 Instalación de Python........................................................................195
12.1.6 Instalación de matplotlib...................................................................196
12.1.7 Instalación de MySQL........................................................................197
12.2 Instalación en Windows ........................................................................197
12.2.1 Instalación del compilador ................................................................197
12.2.2 Instalación de TA-lib..........................................................................205
12.2.3 Instalación de libconfig......................................................................209
12.2.4 Instalación de python........................................................................210

12.2.5 Instalación de matplotlib...................................................................211
12.2.6 Instalación de subversion..................................................................211
12.2.7 Instalación del cliente MySql.............................................................213
12.3 Instalación de la aplicación “Trading”...................................................213
12.3.1 Instalación de un ejecutable .............................................................213
12.3.2 Instalación del código fuente ............................................................214
13 Lista de colores definidos en matplotlib..................................................... 219
14 Lista de errores de ejecución..................................................................... 221
15 Índice de figuras ........................................................................................ 223
16 Índice de tablas ......................................................................................... 231
17 Glosario de términos ................................................................................. 235

21
Resumen
Los inversores, cuando actúan en el mercado, se mueven guiados por
las perspectivas de evolución de una u otra empresa, tipos de cambio, etc.
Estas perspectivas se ven influenciadas por datos fundamentales como pueden
ser resultados anuales, evolución del volumen de facturación o capacidad de
crecimiento, cuando trabajamos con empresas, o datos macroeconómicos y
acontecimientos a nivel mundial, cuando trabajamos en el Mercado de Divisas.
El éxito o fracaso de las inversiones vienen determinados por el
momento en el que el inversor entra o sale de los mercados, por lo que la
búsqueda de buenas estrategias de trading, entendidas éstas como una serie
de reglas (matemáticas, algorítmicas, analíticas o gráficas) que definan la
forma de operar, se ha convertido en objetivo primordial de los inversores.
El avance de la tecnología e Internet ha puesto al alcance de cualquier
persona suficiente información sobre empresas, naciones y mercados como
para que todos seamos potenciales inversores.
Pero también ha facilitado la creación de ingentes repositorios
informatizados de datos históricos, favoreciendo con ello el denominado
“análisis técnico”, encargado de predecir tendencias futuras basándose en la
evolución pasada de las cotizaciones.
Es en este punto donde se ha desarrollado este TFG, ofreciendo al
cliente una herramienta de software que evalúa varias estrategias o escenarios,
aplicando diferentes reglas e indicadores a un conjunto de datos de entrada,
simulando cómo se hubiera comportado y qué beneficios o pérdidas se
hubieran obtenido en cada caso.
Un buena estrategia de trading puede ser posteriormente el núcleo de
un sistema de trading automatizado (que opere sin intervención humana)
decidiendo cuándo entrar y salir del mercado, e interactuando con el mercado
real.
Palabras clave:
Mercado, Divisa, Bolsa, Análisis Técnico, Indicador

23
Abstract
Investors, when acting in the financial markets, are moved by the
evolutions perspective of the companies, exchange rates, etc. These
perspectives are influenced by fundamental data such as annual results,
evolution in turnover and growth capacity, (when working with company stocks)
or macroeconomic data and worldwide events (when working in the Forex
market).
The success or failure of investments are determined by the time at
which the investor enters or leaves the markets, so finding good trading
strategies, understanding these as a set of rules (mathematical, algorithmic,
analytical or graphical) that define the way we operate, has become a primary
target of investors.
The advancement of technology and the Internet has provided to anyone
with required information about companies, nations and markets to make we all
potential investors.
But it has also facilitated the creation of huge databases storing historical
data, favoring the so-called "technical analysis" in charge of predicting future
trends based on past prices development.
The present work has been developed in this area, offering the customer
a software tool that evaluates several strategies or scenarios by applying
different rules and indicators to a set of input data, simulating the behavior and
which profits or losses could have been obtained in each case.
A good trading strategy can subsequently be the nucleus of an
automated trading system (which operate without human intervention) deciding
when to enter and exit the market, and interacting with the real market.
Keywords:
Market, Currency, Exchange, Technical Analysis, Indicator.

25
1 Introducción
1.1 Motivación
Un operador de bolsa (o trader) puede realizar operaciones basándose
en decisiones individuales, considerando cuándo y qué comprar o vender en
cada momento. Sus decisiones se basarán en el conocimiento del que
disponga sobre la evolución de los diferentes valores bursátiles o tipos de
cambio. También debe ser capaz de inferir comportamientos futuros tomando
como base información económica precisa, pero también el “estado de ánimo”
de los mercados. Adicionalmente, un trader experimentado podrá aplicar
experiencias basadas, que influenciarán sus decisiones en un sentido u otro.
De esta forma, toda la responsabilidad recae en el individuo, por lo que
las emociones podrían influir en la toma de decisiones. Además, su eficacia
operativa estará relacionada con la capacidad que tenga de estar vigilando el
mercado continuamente, pero siempre concentrándose en unos productos, que
tenderán a ser unos pocos.
Sin embargo, un trading automático puede vigilar el mercado
continuamente, para tantos productos como se diseñe y, basándose en un
conjunto de reglas, actuará en los mercados, eliminado el componente de las
emociones en la toma de decisiones.
Obviamente, una y otra metodología presentan ventajas y desventajas, y
siempre podemos pensar que una combinación de ambas ofrecerá mejores
resultados.
A la hora de elaborar una estrategia, los profesionales del trading utilizan
diversos indicadores que, aplicados sobre un conjunto de datos, nos pueden
indicar la tendencia que puedan seguir los precios. El trader, usará su
creatividad para elegir la combinación de indicadores que determinarán las
entrada en el mercado. Las salidas del mercado vendrán determinados por lo
puntos de máxima pérdida aceptada (lo que se denomina Stop Loss) y del nivel
de recogida de beneficios (conocido como Take Profit).
La principal motivación de este proyecto ha sido ayudar al trader en la
fase del backtesting o, según define Holland [1], “[…] la evaluación de las
rentabilidades que caben esperar de una estrategia de trading basada en los
rendimientos calculados a partir de datos históricos”. Con una herramienta de
este tipo, se puede probar si una determinada combinación de parámetros
funcionó en el pasado e indica al trader lo acertado o equivocada que puede
ser una estrategia.

26
El desarrollo de una herramienta de backtesting, principal objetivo de
este proyecto, engloba varias disciplinas, incluyendo la economía, la
informática y la estadística. Este hecho contribuyó de manera decisiva a que el
autor lo seleccionara como TFG.
1.2 Definición
Durante este TFG se ha desarrollado la aplicación “Trading”, una
aplicación de escritorio enfocada principalmente a entornos de
supercomputación sobre Linux.
Se ha desarrollo en lenguaje C, buscando rapidez de ejecución y
eficiencia en el manejo de grandes volúmenes de datos.
Funcionalmente este software permite la lectura de datos históricos de
operaciones en mercados financieros, desde fichero o desde una base de
datos. Sobre esta información, y en base a archivos de configuración creados
por el usuario, es capaz de calcular índices financieros y, en combinación con
un conjunto de reglas, decidir entradas y salidas del mercado. Finalmente
reporta el rendimiento de las operaciones para decidir qué reglas son las más
beneficiosas.
Adicionalmente ofrece una salida gráfica donde, sobre diagramas de
velas con los precios, se pueden mostrar los indicadores técnicos y las
operaciones de entrada/salida.
1.3 Objetivos propuestos
Los objetivos marcados por nuestro cliente (Artificial Intelligence
Talentum, S.L.) para este proyecto quedan detallados a continuación:
 Objetivo General 1 (OG1): Desarrollo de una aplicación eficiente
o Objetivos Específico 1 (OE1): Desarrollo de un programa
automatizable (mediante el uso de archivos de
configuración), para el funcionamiento en
supercomputadoras
o Objetivos Específico 2 (OE2): Uso de un lenguaje de
programación eficiente en términos de velocidad y
memoria
 Objetivo General 2 (OG2): Desarrollo de una herramienta de
análisis visual de operaciones en los mercados
o Objetivos Específico 3 (OE3): Lectura de datos a través de
un fichero o directamente desde una base de datos

27
o Objetivos Específico 4 (OE4): Representación gráfica de
datos históricos e indicadores técnicos, mediante gráficos
de velas y líneas
 Objetivo General 3 (OG3): Desarrollo de una herramienta de
backtesting
o Objetivo Específico 5 (OE5): Calcular indicadores técnicos
sobre un conjunto de datos históricos
o Objetivo Específico 6 (OE6): En base a un conjunto de
reglas, decidir el momento de realizar una operación en el
mercado y de finalizar la misma
o Objetivo Específico 7 (OE7): calcular el beneficio neto del
conjunto de operaciones que se produzcan en el periodo
de tiempo establecido
o Objetivo Específico 8 (OE8): elaborar un informe con datos
estadísticos sobre las operaciones realizadas

29
2 Estudio del mercado
2.1 Conceptos relevantes del dominio de la aplicación
Según podemos consultar en el “Diccionario Económico” de la edición
digital del diario expansión [8], “El mercado financiero es el lugar, mecanismo
o sistema electrónico donde se negocian los activos, productos e instrumentos
financieros o se ponen en contacto los demandantes y los oferentes del activo
y es donde se fija un precio público de los activos por la confluencia de la oferta
y la demanda”.
Otra definición la podemos encontrar en la enciclopedia financiera on-
line, donde se nos indica que “Un Mercado Financiero pude definirse como un
conjunto de mercados en los que los agentes deficitarios de fondos los
obtienen de los agentes con superávit” [9].
Según esta misma fuente, los principales mercados financieros son los
siguientes:
 Bolsas de Valores: Una bolsa de valores es una organización que
establece "sistemas de negociación" para que los inversores
puedan comprar y vender acciones, derivados y otros valores.
Las bolsas de valores también proporcionan las instalaciones
para la emisión y amortización de valores, así como otros
instrumentos financieros y los rendimientos de capital incluyendo
el pago de dividendos. Se trata de una de las fuentes más
importantes de recaudación de capital para las empresas.
 Mercados de Renta Fija: El mercado de bonos (también conocido
como de deuda, de crédito, o mercado de renta fija) es un
mercado financiero, donde los participantes compran y venden
títulos de deuda, normalmente en forma de bonos. Los mercados
de renta fija, en la mayoría de los países siguen siendo
descentralizados, al contrario del mercado de acciones, futuros y
del mercado de factores. Esto ha ocurrido, en parte, porque no
hay dos emisiones de bonos exactamente iguales, lo que hace
que el número de títulos en el mercado sea inmenso.
 Mercados de Divisas: El mercado de divisas o FOREX, permite
que los bancos, empresas y otras instituciones fácilmente
compren y vendan divisas. El propósito del mercado de divisas es
facilitar el comercio internacional y la inversión. El mercado de
divisas ayuda a las empresas a convertir una moneda en otra.

30
 Mercados de Factores: El comercio de materias primas consiste
en el comercio físico directo y a través de derivados financieros
para la compra/venta a plazo permitiendo asegurar un precio de
venta o compra en el futuro a productores y/o clientes.
El análisis técnico, como herramienta para analizar los mercados y los
movimientos de precios, viene siendo utilizado desde el siglo XIX, en tiempos
del analista Chales Dow (que da nombre a la teoría considerada el origen de
los sistemas de inversión que usan como base esta metodología). Dow publicó
sus ideas en una serie de editoriales que escribió para el diario Wal Street
Journal.
Según John J. Murphy, autor de una publicación conocida y considerada
por muchos en este ámbito como la Biblia del Análisis Técnico, “La teoría de
Dow todavía es la piedra angular del estudio de análisis técnico, incluso ante la
sofisticada tecnología informática actual y la proliferación de indicadores
técnicos supuestamente nuevos y mejores” [4]
Murphy define el análisis técnico como “[…]el estudio de los
movimientos del mercado, principalmente mediante el uso de gráficos, con el
propósito de pronosticar las futuras tendencias de los precios” [5] y entiende
que los fundamentos que lo soportan son:
 Los movimientos del mercado los descuentan todo. Según esto, el técnico
cree que cualquier cosas que posiblemente pueda afectar al precio (por
razones fundamentales, políticas, psicológicas u otras) se refleja
realmente en el precio de ese mercado. Concluye por tanto que todo lo
que hace falta es un estudio de los movimientos de los precios, sin
importar la razón de los mismos.
 Los precios se mueven por tendencias, y es el propósito de este enfoque
identificarlas dentro de sus primeras etapas de desarrollo, con el fin de
que las transacciones vayan en la dirección de dichas tendencias hasta
que los precios muestren señales de variar la dirección que llevan.
 La historia se repite y una gran parte del análisis técnico y del estudio del
movimiento de los mercados tiene que ver con el estudio de la psicología
humana. Por ejemplo, los patrones gráficos recogidos durante los últimos
cien años reflejan imágenes concretas que aparecen en los gráficos de
precios y reflejan la psicología alcista o bajista del mercado y, dado que
la psicología humana tiene tendencia a no cambiar, podemos pensar que,
si ha funcionado bien en el pasado, también funcionará en el futuro.

31
En el estudio del comportamiento del mercado la principal herramienta
son los gráficos, donde se representan las cotizaciones del mercado. Los más
utilizados son las velas japonesas, pues aportan una idea de la volatilidad de
los precios, el precio de cierre, de apertura, el máximo y el mínimo en cada
período. Una vela corresponde a un período y, de un vistazo, se observa si al
terminar el período se ha elevado el precio o ha disminuido. La vela verde
indica una tendencia alcista y la roja una bajista:
Figura 2 Gráfico de velas. Evolución de los precios
John J. Murphy dedica varios capítulos de su libro “Análisis técnico de
los mercados financieros” a describir diferentes tipos de gráficos y su utilidad
[6].
Ahora bien, el análisis mediante gráficos suele ser subjetivo ya que
puede darse el caso de que dos analistas, analizando la misma información,
extraigan conclusiones diferentes sobre la situación del mercado.
Figura 1 Gráfico de velas. Descripción

32
La otra herramienta que ofrece el análisis técnico, y que busca eliminar
en lo posible esa subjetividad, son los indicadores, que podríamos considerar
como ejemplo de comportamiento objetivo de forma que, mediante unas
determinadas reglas, se decidirán operaciones de entrada y salida del
mercado. Los indicadores hacen uso únicamente de instrumentos matemáticos
y estadísticos lo que permite su inclusión en herramientas de software que
ejecutan automáticamente decisiones basándose en las tendencias.
Se debe tener en cuenta que la mayoría de estos indicadores analizan la
naturaleza de las tendencias. Es por ello que se desaconseja su uso en el caso
de períodos temporales donde los mercados apenas muestran tendencia (por
ejemplo en momentos que se denominan “de movimiento lateral”).
A la hora de definir una estrategia de trading basada en indicadores
técnicos, el trader dispone de una gran cantidad de ellos donde elegir (por
ejemplo, TAlib, librería usada en este proyecto, ofrece 200 indicadores [37]). Es
fácil encontrar abundante bibliografía y Sites en internet sobre este tema pero
hay coincidencia sobre cuáles son los más utilizados:
 Media móvil simple: aplicada a los precios de apertura o cierre de las
cotizaciones. Para generar órdenes de compra y venta se utiliza una regla
sencilla: las señales de compra se usan cuando la media móvil corta por
arriba la línea de precios y las de venta, cuando corta por abajo la línea
de precios.
 RSI: Índice de fuerza relativa. Marca aquellos momentos en los que el
mercado tiene un estado de sobrecompra o sobreventa y en los cuales
hay que entrar a operar. En un rango de valores de 0 a 100 lo normal es
comprar cuando este indicador es menor a 70 y vender cuando sobrepasa
el valor de 30.
 MME: media móvil exponencial. Se utiliza este tipo de medias porque
asigna más importancia a los precios de cierre más cercanos y menor
importancia a los más alejados.
 Bandas de Bollinger: analiza las fluctuaciones del mercado, mediante una
línea central obtenida con una media móvil y dos bandas laterales,
obtenidas sumando y restando un determinado número de desviaciones
típicas.
Una vez diseñada la estrategia basada en el análisis técnico hay que
evaluar su fiabilidad, ejecutando con herramientas informáticas una simulación
contra datos históricos y analizando las ganancias y pérdidas del sistema, y

33
también el modo en que la estrategia opera (por ejemplo, se podría querer
conocer si la estrategia inicia muchas operaciones de pocos márgenes o pocas
de grandes márgenes). Estamos hablando del backtesting, objetivo principal
del software desarrollado en este TFG y que ayuda al trader a “afinar” el
sistema, permitiendo cambios en los parámetros y relanzar la simulaciones
para observar el impacto en el comportamiento.
Para evaluar la bondad de un sistema de trading se utilizan varios
ratios. De entre todos ellos, podemos destacar:
 Beneficio Neto (o Profit): en principio ésta debería ser la medida
principal del rendimiento o efectividad de un sistema. Cuanto más
beneficio neto, mejor. Sin embargo surge una duda: si escogemos
el sistema que gana más ¿podemos asegurar que esto se
repetirá en el futuro?. Por eso, este ratio, usado por sí solo
presenta dos inconvenientes:
o Pudiera ser que la ganancia que ha entregado se haya
debido a una única operación de mucho beneficio, aunque
el resto de operaciones hayan sido pérdidas ¿se repetirá
en el futuro una operación de este tipo?
o Aunque el sistema tenga ganancias constantes, si en un
momento determinado ocasiona una pérdida de capital
muy elevada será muy probable que se piense que ha
dejado de funcionar (aunque no sea así) y se deje de
operar. Para manejar esta situación se introduce un nuevo
ratio.
 Drawdown: es la máxima disminución de capital desde un
máximo anterior. Mide cuánto dinero se está perdiendo en un
momento determinado respecto de un momento anterior en el que
el sistema tuvo su máxima ganancia. Cuando miremos el
beneficio neto de un sistema deberíamos mirar también el
drawdown que vamos a tener que soportar para conseguir dicho
beneficio
 Recovery Factor: relaciona los dos anteriores (divide la ganancia
neta entre el máximo drawdown del sistema). Un sistema que
genera un beneficio de 100 con un máximo drawdown de 10,
tiene un Recovery Factor de 10:1. A mayor ratio mejor estrategia.
 Profit Factor: se calcula dividiendo la ganancia de las operaciones
ganadores entre la pérdida de las operaciones perdedoras. Por

34
definición, si la estrategia es rentable, el Profit Factor sería mayor
que 1.
 Número de operaciones: indica el total de operaciones realizadas
en los mercados. Si nos interesa que nuestro sistema no genere
demasiadas operaciones, hay que incluir este ratio en el análisis.
Basándose en todos esos indicadores, un trader puede decidir si un
sistema es bueno o no. Así, por ejemplo, podría pedir que tuviera un Profit
Factor > 2 y un Recovery Factor > 7.
Como ejemplo, Oscar Cagigas en su blog [7], considera que las
características de un sistema que merece la pena ser operado con dinero real
son que:
 Tiene menos de 4 o 5 parámetros (es sencillo)
 Está evaluado en suficientes datos. Al menos 2 años si es intradía
y al menos 10 años si es diario. Como mínimo buscando unas
200 operaciones.
 Genera ganancias año tras año, aunque sean limitadas y es
robusto, o sea que, variando ligeramente sus parámetros, sus
resultados varían ligeramente (es decir, no está construido sobre
un pico de ganancia).
 Funciona en la mayoría de instrumentos con características
similares (otra forma de robustez).
 Recovery Factor >= 6
 Profit Factor >= 2
Dependiendo de la complejidad de la estrategia (número de indicadores
y reglas de decisión) y del volumen de datos históricos sobre los que se quiere
simular, podría ser necesario disponer de un software que pueda ejecutarse en
sistemas de alto poder de computación, y esperar como resultado un informe
con las estrategias victoriosas de entre todas las ejecutadas basándose en los
indicadores usados (cuantas más veces se evalúe un sistema, y contra cuantos
más datos, más seguros podremos estar de su eficacia).

35
2.2 Relación con proyectos con la misma funcionalidad
Podemos encontrar en el mercado herramientas comerciales de
backtesting y también otras que, siendo herramientas de trading, incluyen
módulos de backtesting y optimización. Podemos destacar:
 Metatrader (http://www.metatrader4.com/en): una plataforma de trading
creada en 2005 por MetaQuotes software para operar inicialmente en
Forex. Su punto más fuerte es la capacidad gráfica y la facilidad de uso.
Dispone de una gran variedad de indicadores y de un lenguaje de
programación que permite crear nuevos indicadores. Ofrece la opción de
realizar backtesting (y optimización) para comprobar el sistema que
programemos y una gestión incorporada de bases de datos históricos con
una función de importación/exportación de dichos datos.
 TradeStation (http://www.tradestation.com/): creada en 1991 como tal, si
bien provenía de la compañía Omega Research, fundada en 1982.
Dispone de todo lo necesario para el backtesting y conexiones con los
servidores que operan en el mercado. Al igual que Metatrader, provee de
datos históricos y permite su descarga. Es posible también crear y
almacenar estrategias.
 Wealth-Lab (http://www.wealth-lab.com): Es una plataforma de trading
propiedad de Fidelity Investments. Los usuarios pueden programar y
probar estrategias. Dispone de un entorno de programación basado en
C#. Se pueden tener varias fuentes de datos y es posible importar datos
de otras plataformas incluso de ficheros ASCII.
 QuantConnect: (https://www.quantconnect.com/) proyecto que cuenta con
el apoyo de Fundación Chile y CORFO. Permite a los usuarios programar
en un entorno local y luego recibir un correo electrónico con el resultado
de su simulación, la cual se trabaja a través de la nube. Los traders que
usan este software deben tener conocimientos de programación para
poder sacar partido e interactuar con la API que comparte.
 MultiCharts (http://www.multicharts.com/). Creada en 2005. Cuenta con un
lenguaje de programación llamado PowerLanguage y ofrece backtesting y
optimización.
 NinjaTrader (http://www.ninjatrader.com/) . Empresa creada en 2004 y con
sede en Denver. Es gratuita cuando se usa para representación gráfica,
análisis de mercados y desarrollo y simulación de sistemas de trading y
únicamente se paga por la funcionalidad de interactuar con los mercados
para colocar órdenes.

36
Figura 8 Web Site de NinjaTrader
Figura 3 Web Site de MetaTrader Figura 4 Web Site de TradeStation
Figura 5 Web Site de Wealth-Lab Web Figura 6 Web Site de QuantConnect
Figura 7 Web Site de MultiCharts

37
2.3 Estudio de viabilidad
2.3.1 Alcance del proyecto
El resultado de este proyecto es un software financiero de backtesting
desarrollado en C y orientado a sistemas Linux, especialmente a
computadoras de alto rendimiento. El alcance lo hemos establecido en lograr
una buena capacidad de procesamiento, el manejo de grandes volúmenes de
datos históricos y la posibilidad de configuración flexible, en concreto
especificar de una manera sencilla combinaciones de parámetros que generen
un elevado número de combinaciones (escenarios) a probar.
El interfaz gráfico de usuario está excluido del producto, siendo la
ejecución desatendida el modo normal de explotación de este software. Una
vez suministrados los datos de entrada y las reglas que deben operar sobres
esos datos, el programa debe poder ejecutarse sin intervención del usuario,
ofreciendo como salida un informe con las mejores estrategias de trading.
2.3.2 Estudio de la situación actual
El backtesting es una herramienta de gran importancia en el diseño de
estrategias de trading, por lo que casi todo el software comercial existente
incorpora la capacidad de optimización.
Ahora bien, las herramientas disponibles en el mercado aportan como
ventaja para los usuarios la interfaz gráfica y los lenguajes de programación
propios que, si bien permiten elaborar complejas estrategias de trading,
también dificultan la curva de aprendizaje de las herramientas. Además,
aunque todas ellas manejan datos
históricos, lo hacen en formatos propietarios o en formatos públicos, pero con
poca flexibilidad.
El software desarrollado en el marco de este proyecto quiere ser una
alternativa:
 Priorizando la velocidad de cálculo, eliminando el interfaz de
usuario

38
 Posibilitando el acceso a bases de datos propias donde el cliente
pueda componer sus propios conjunto de datos, permitiendo así
analizar estrategias testeadas sobre valores agregados.
2.3.3 Estudio y valoración de las alternativas de solución
En función de las consideraciones expuestas en el apartado anterior, el
uso de software comercial queda excluido como una solución para las
necesidades de nuestro cliente.
Como alternativa, decidimos desarrollar una nueva herramienta que nos
aporte la funcionalidad que necesitamos, lo cual nos lleva a tener que
seleccionar entre varias alternativas:
 El lenguaje de programación adecuado
 el sistema operativo sobre el que ejecutar la aplicación: Windows,
Linux
 Persistencia de datos: motores de bases de datos (Sql Server,
MySQL, Oracle), ficheros
Nuestro cliente tiene identificadas sus necesidades, con especial
hincapié en la rapidez de ejecución en un proceso iterativo de búsqueda del/los
mejores escenarios dentro de los diseñados. No tiene requerimientos
especiales en cuanto al interfaz de usuario, que será el objeto de otra
aplicación.
2.3.4 Selección de la solución
Descartamos, por tanto, desarrollar la herramienta para explotarla en un
entorno web. El objetivo de la aplicación, el proceso de optimización en sí, será
más rápido y consumirá menos memoria en una aplicación de escritorio.
A la hora de seleccionar el lenguaje de programación para un software
de escritorio, nos hemos decantado por el C (Ansi C), principalmente por su
rapidez (está cercano a los lenguajes de bajo nivel por lo que es muy popular
para la creación de software de sistema) y eficiencia.
Otras opciones habrían sido C++, C# o Java. Java lo descartamos por
ser un lenguaje interpretado, lo que lo hace más lento. C# lo descartamos por
estar enfocado a sistemas Windows. Sin embargo, C++, siendo también un
buen candidato, no lo hemos seleccionado porque es más complejo y porque la
orientación a objetos realmente no es un requerimiento en este proyecto.

39
En cuanto al sistema operativo, hemos seleccionado Linux por ser muy
robusto, estable y rápido. Además requiere poco hardware y el manejo de la
memoria de Linux evita que los errores de las aplicaciones detengan el núcleo
de Linux. Como última ventaja, aportamos que es un sistema operativo libre.
No obstante, también puede ser ejecutado sobre Windows (en concreto sobre
Cygwin [22]), que proporciona un entorno de funcionamiento similar a los
sistemas Unix, pero dentro de Microsoft Windows).
Para el cálculo de indicadores se ha confiado en la librería TA-lib [37],
que implementa el cálculo de 200 de estos indicadores y que ofrece interfaces
para diferentes lenguajes de programación.
Para facilitar su explotación en supercomputadores, la aplicación
“Trading” se lanza desde una consola de comandos, aceptando como entrada
los archivos de configuración que contienen las estrategias a probar y ofrece
como salida archivos de texto informando sobre los resultados de las pruebas y
también gráficos para un análisis visual del comportamiento de las estrategias.
La elaboración de los gráficos recae en matplotlib [34]. La lectura y análisis
sintáctico de los archivos de configuración se realiza mediante la librería
libconfig [36].
En cuanto al almacenamiento de información, realmente no es
necesaria, por lo que no usaremos ninguna. Únicamente debemos permitir el
acceso, en modo lectura, a bases de datos MySQL del cliente para recoger
datos históricos.

41
3 Metodologías usadas
Nos enfrentamos en este punto a la decisión de adoptar una de las dos
grandes corrientes metodológicas en el desarrollo de software existentes: o “En
Cascada” (o secuencial) o “Ágil”. Presentamos brevemente las características
de una y otra, con objeto de conocer las motivaciones que nos han hecho
decantarnos por la segunda.
3.1 Desarrollo en cascada o secuencial
El esquema de desarrollo en cascada propone actividades secuenciales,
donde el desarrollo fluye del punto inicial al final con varias etapas
diferenciadas, y el inicio de una etapa espera la finalización de la anterior:
 Análisis de Requisitos
 Diseño del Sistema
 Implementación
 Verificación
 Mantenimiento
Nos propone realizar con antelación un análisis intensivo de
requerimientos. Esto es debido a que se hace complicado volver a etapas
previas cuando se encuentran diferencias en el alcance del proyecto. Una vez
que una fase se ha completado es casi imposible hacer cambios.
A pesar de que este modelo es el paradigma más antiguo utilizado en la
ingeniería del software, su eficacia se pone en duda por los problemas que se
encuentran algunas veces [10]. Mencionamos dos en concreto expuestos por
Pressman (2002) en su libro sobre Ingeniería del Software:
“A menudo es difícil que el cliente exponga explícitamente todos los
requisitos El modelo lineal secuencial lo requiere y tiene dificultades a la hora
de acomodar la incertidumbre natural al comienzo de muchos proyectos
El cliente debe tener paciencia. Una versión del programa no estará
disponible hasta que el proyecto esté muy avanzado. Un grave error puede ser
desastroso si no se detecta hasta que se revisa el programa”
Pero, a pesar de estos problemas, sigue siendo el modelo más utilizado
porque, frente a un desarrollo desorganizado, ofrece algunas ventajas, como
son el hecho de estar centrado en la planificación (exigiendo un plan y visión
claras), lo que facilita la estimación de costes y plazo. Además, en caso de que

42
un diseñador abandonara el equipo, el reemplazo sería fácil siguiendo el plan
de desarrollo que siempre está previamente documentado.
3.2 Metodología Ágil
Propone un diseño de software incremental e iterativo. Fue la respuesta
a las limitaciones de la metodología en cascada, dotando a los diseñadores de
una mayor libertad de responder a cambios en los requisitos a medida que
surgen.
Los doce principios que constituyen esta metodología son públicos y
están recogidos en el Manifiesto por el Desarrollo Ágil de Software [11] pero se
podrían resumir en la siguiente tabla, extraída de la misma fuente:
Tabla 1 Filosofía de desarrollo Ágil
Es importante Pero todavía lo es mas
Procesos y herramientas Individuos e interacciones
Documentación extensiva Software funcionando
Negociación contractual Colaboración con el cliente
Seguir un plan Respuesta ante el cambio
En definitiva, se ofrece un modelo de diseño flexible, donde se fomentan
planes adaptables y desarrollo evolutivo. Los desarrolladores trabajan en
pequeños módulos cada vez.
Especialmente destacable es la interacción con el cliente. Éste ofrece
realimentación simultáneamente al desarrollo, como las pruebas de software.
Por este motivo las metodologías ágiles son especialmente beneficiosas en los
casos en los que los objetivos finales de los proyectos no están claramente
definidos (casos de clientes cuyas necesidades y objetivos sean un poco
vagos). En estos casos los requisitos se clarifican a medida que el proyecto
evoluciona, dejando que el desarrollo pueda ser modificado para adaptarse a
los nuevos evolutivos.
Por el contrario, los plazos y costes son a priori difíciles de predecir
pues, sin un plan claro, todo presenta un aspecto de indefinición.

43
Los doce principios mencionado previamente son los siguientes [11]:
 Nuestra mayor prioridad es satisfacer al cliente mediante la
entrega temprana y continua de software con valor.
 Aceptamos que los requisitos cambien, incluso en etapas tardías
del desarrollo. Los procesos Ágiles aprovechan el cambio para
proporcionar ventaja competitiva al cliente.
 Entregamos software funcional frecuentemente, entre dos
semanas y dos meses, con preferencia al periodo de tiempo más
corto posible.
 Los responsables de negocio y los desarrolladores trabajan juntos
de forma cotidiana durante todo el proyecto.
 Los proyectos se desarrollan en torno a individuos motivados.
Hay que darles el entorno y el apoyo que necesitan, y confiarles
la ejecución del trabajo.
 El método más eficiente y efectivo de comunicar información al
equipo de desarrollo y entre sus miembros es la conversación
cara a cara.
 El software funcionando es la medida principal de progreso.
 Los procesos Ágiles promueven el desarrollo sostenible. Los
promotores, desarrolladores y usuarios debemos ser capaces de
mantener un ritmo constante de forma indefinida.
 La atención continua a la excelencia técnica y al buen diseño
mejora la Agilidad.
 La simplicidad, o el arte de maximizar la cantidad de trabajo no
realizado, es esencial.
 Las mejores arquitecturas, requisitos y diseños emergen de
equipos auto-organizados.
 A intervalos regulares el equipo reflexiona sobre cómo ser más
efectivo para, a continuación, ajustar y perfeccionar su
comportamiento en consecuencia.
Son varios los métodos ágiles existentes. XP (Extreme Programming) es
quizás el más conocido junto a SCRUM.

44
3.2.1 XP (Extreme Programming)
XP es un método que trata del “cómo se trabaja” en el proyecto. Fue
formulado por Kent Beck [12] y se basa en doce prácticas de obligado
cumplimiento que se pueden encontrar en la web [13]. Las características
fundamentales son [14]:
 Desarrollo iterativo e incremental: pequeñas mejoras, unas tras
otras.
 Pruebas unitarias continuas, frecuentemente repetidas y
automatizadas, incluyendo pruebas de regresión. Se aconseja
escribir el código de la prueba antes de la codificación.
 Programación en parejas: se recomienda que las tareas de
desarrollo se lleven a cabo por dos personas en un mismo
puesto.
 Frecuente integración del equipo de programación con el cliente o
usuario. Se recomienda que un representante del cliente trabaje
junto al equipo de desarrollo.
 Corrección de todos los errores antes de añadir nueva
funcionalidad. Hacer entregas frecuentes.
 Refactorización del código, es decir, reescribir ciertas partes del
código para aumentar su legibilidad y mantenimiento, pero sin
modificar su comportamiento. Las pruebas han de garantizar que
en la refactorización no se ha introducido ningún fallo.
 Propiedad del código compartida: en vez de dividir la
responsabilidad en el desarrollo de cada módulo en grupos de
trabajo distintos, este método promueve el que todo el personal
pueda corregir y extender cualquier parte del proyecto.
 Simplicidad en el código: es la mejor manera de que las cosas
funcionen.
3.2.2 SCRUM
Como hemos comentado, otro método ágil muy extendido es SCRUM
[15], que incide en “cómo se organiza y planifica” el proyecto. Consiste en un
conjunto de buenas prácticas para trabajar colaborativamente en equipo, y
obtener el mejor resultado posible de un proyecto. En SCRUM se realizan
entregas parciales y regulares del producto final, priorizadas por el beneficio

45
que aportan al receptor del proyecto. Por ello, SCRUM está especialmente
indicado para proyectos en entornos complejos, donde se necesita obtener
resultados pronto y donde los requisitos son cambiantes o poco definidos.
En SCRUM, un proyecto se ejecuta en bloques temporales cortos y fijos
(iteraciones de entre dos semanas y un mes natural). Cada iteración tiene que
proporcionar un resultado completo, un incremento de producto final que sea
susceptible de ser entregado con el mínimo esfuerzo al cliente cuando lo
solicite.
Figura 9 El Proceso en Scrum
El proceso se inicia con una lista de objetivos/requisitos del producto,
que actúa como plan del proyecto. En esta lista, denominada en SCRUM
Product Backlog, el cliente prioriza los objetivos balanceando el valor que le
aportan respecto a su coste y quedan repartidos en iteraciones y entregas.
Estos requisitos se denominan Historias de Usuario y están descritos en un
lenguaje no técnico, tal y como el cliente lo ve.
Los requisitos y prioridades se revisan y ajustan durante el curso del
proyecto a intervalos regulares.
Existen 4 eventos que caracterizan SCRUM y que se ven reflejados en
la figura 9:
1. Reunión de Planificación (Sprint Planning) [16]: Reunión durante
la cual el Product Owner presenta las historias de usuario por
orden de prioridad, según el valor que aporte al negocio. El
equipo determina la cantidad de historias que puede
comprometerse a completar en ese sprint para, en una segunda
parte de la reunión, decidir y organizar cómo lo va a conseguir.

46
2. SCRUM Diario (Daily SCRUM) [16]: Reunión de, como máximo,
15 minutos en la que el equipo se sincroniza para trabajar de
forma coordinada. Cada miembro comenta lo que hizo el día
anterior, que hará hoy y si hay impedimentos.
3. Revisión del Sprint (Sprint Review) [16]: Reunión que se celebra
al final del sprint y en la que el equipo presenta las historias
conseguidas mediante una demostración del producto
4. Retrospectiva del Sprint (Sprint Retrospective) [16]: Reunión
durante la cual el equipo analiza qué se hizo bien, qué procesos
serían mejorables y discute acerca de cómo perfeccionarlos.
El equipo de proyecto debe constar de al menos de tres personas, para
desempeñar como mínimo los tres roles que caracterizan SCRUM:
 el SCRUM Master
 el Producto Owner
 el equipo de desarrollo.
En la siguiente tabla observamos un breve resumen de las tareas
principales de cada rol:
Tabla 2 Roles en SCRUM
SCRUM MASTER PRODUCT OWNER EQUIPO DE DESARROLLO
Lidera al equipo para que
cumpla las reglas y procesos
de SCRUM
Representa al cliente y se
asegura de que el equipo
trabaja en los temas
correctos, desde el punto
de vista del negocio
Tienen los conocimientos
técnicos necesarios para
llevar a cabo las historias a
las que se comprometen al
inicio de cada sprint
Elimina impedimentos,
asegurando el mejor
entorno para el desempeño
del equipo
Traslada la visión del
proyecto al equipo
Deciden cómo ordenar y
cómo asignar las tareas
Formaliza las
prestaciones en historias
a incorporar en el Product
Backlog y las reprioriza de
forma regular.
Cada uno debería
intercambiar tareas con
otro miembro del equipo
(no existen roles)

47
3.2.3 Otras metodologías ágiles
Aparte de la dos mencionadas, existen otras metodologías ágiles que
tiene como factor común el carácter iterativo y la entrega rápida al cliente de
versiones del producto para obtener una retroalimentación lo antes posible.
No entraremos en detalles de cada una, pero podemos mencionar las
siguientes:
 RUP [17]
 Kanban [18]
 Lean-Agile [19]
3.3 Metodología elegida
A la hora de decantarnos por una u otra metodología hemos tenido en
cuenta la naturaleza de nuestro proyecto:
 Tenemos una idea general del objetivo del proyecto, pero sin
detalles. Entendemos que el cliente irá concretando los requisitos
conforme vaya viendo las primeras versiones, ya que podrá
hacerse mejor una idea del potencial del software.
 Dado el horizonte temporal del desarrollo del TFG, no queremos
invertir mucho tiempo en elaborar un plan detallado y
especificaciones a bajo nivel
 Nos gustaría poder mantener contacto con el cliente durante el
proyecto, para asegurarnos de la satisfacción del mismo con el
producto final. Nos motiva establecer una comunicación frecuente
con el cliente, y aprender de sus ideas
 El equipo de proyecto lo constituyen tres personas, los dos
tutores y el autor del TFG
 Por disponibilidad del autor del TFG, preferimos establecer un
seguimiento periódico del proyecto, revisando las versiones
ejecutables disponibles en cada encuentro
Todas estas características quedarían cubiertas usando una
metodología Ágil, eliminando la restricción marcada por los métodos en
cascada de conocer de antemano todos los detalles del proyecto y disponer de
una documentación detallada previa al inicio del desarrollo del software. Esto

48
dilataría mucho el tiempo de entrega al cliente de las primeras versiones del
software.
Finalmente, entre XP y SCRUM nos decantamos por SCRUM,
principalmente porque el equipo de desarrollo lo forma únicamente el autor del
TFG, lo que violaría una de las reglas de XP (el pair programming, o
programación en parejas).
Una vez acordada la metodología, debemos tomar algunas decisiones
en cuanto a la configuración del equipo y a la planificación de los eventos que
marca SCRUM.
3.3.1 Los roles
Como indicábamos anteriormente, SCRUM marca claramente 3 roles,
que deben respetarse y que cumplen una misión muy concreta en esta
metodología.
Durante una reunión de coordinación previa del equipo de este TFG,
decidimos realizar la siguiente asignación de personas a roles, en función del
perfil de cada miembro:
Tabla 3 Asignación de roles en proyecto Trading
SCRUM MASTER PRODUCT OWNER EQUIPO DE DESARROLLO
José María Cecilia Horacio Pérez José Carlos Cano
Con este modo de organizarnos, Horacio Pérez (tutor del TFG) será el
punto de contacto con el cliente, la empresa Artificial Intelligence Talentum,
S.L, y por tanto será quien traduzca en historias de usuario los requerimientos
del negocio y validará las sucesivas entregas del producto.
José María Cecilia (tutor del TFG) será el facilitador del desarrollo del
proyecto, instruyendo al resto del equipo en la metodología SCRUM y
monitorizando el cumplimiento de los estándares. Ante cualquier impedimento
que pudiera surgir y que pudiera poner en riesgo el desarrollo normal del
proyecto, será el encargado de proveer soluciones.
José Carlos Cano (autor del TFG) será el único miembro de Equipo de
Desarrollo, que codificará y probará el software.

49
3.3.2 Los eventos
SCRUM nos marca algunos hitos esenciales durante el desarrollo del
proyecto, en concreto las reuniones de planificación y revisión del sprint.
Entendemos que estas reuniones serán presenciales por lo que buscamos una
frecuencia que sea sostenible en el tiempo, tanto por disponibilidad de los
tutores como del propio autor del TFG.
En esta línea, acordamos realizar sprints de 4 semanas de duración
(SCRUM recomienda una duración de entre 2-4 semanas) y cada reunión será
a la vez Sprint Planning y Sprint Review.
Los SCRUM Diarios y La Retrospectivas de cada sprint, con un marcado
carácter técnico, las realizará el autor del TFG, como miembro único del Equipo
de Desarrollo.
3.3.3 Seguimiento
Javier Garzás en su libro "Gestión de proyectos ágil”, [20] recomienda el
uso de tableros Kanban, como herramienta visual de seguimiento de las tareas
de cada sprint. Se pueden ver algunos ejemplos del uso de tableros en varias
instituciones que siguen metodología SCRUM para algunos proyectos visitando
la página web del autor [21].
Los tableros Kanban están enmarcados en una técnica del mismo
nombre que se creó en Toyota, y que se utiliza para controlar el avance del
trabajo, en el contexto de una línea de producción. Los componen tarjetas o
Post-It, que contienen una tarea con su descripción. Las tarjetas se colocan en
varias columnas, que componen el tablero, según se esté trabajando en ella,
esté pendiente o ya acabada.
Figura 10 Tablero Kanban

50
Estos tableros se pueden colocar en grandes paneles e incluso en
paredes, lo que las hace visibles a todo el equipo del proyecto, incluido al
cliente, ofreciendo de esta manera transparencia sobre lo que se está haciendo
y el ritmo al que se hace, lo que incrementa la confianza y la sensación de
equipo.
Pero también existen herramientas informáticas para el manejo de
tableros Kanban, especialmente útiles para:
 Trabajo con equipos distribuidos, donde no es posible consultar
físicamente un tablero real
 Conservar históricos
 Realizar gráficos automatizados de evolución y carga de trabajo
En este proyecto utilizaremos una herramienta que nos facilitará la
creación y seguimientos de los tableros y nos creará en tiempo real los gráficos
Burn Down de cada sprint, que grafican el trabajo pendiente a lo largo del
tiempo y por tanto la velocidad a la que se están completando los
objetivos/requisitos. Permite extrapolar si el Equipo de Desarrollo podrá
completar el trabajo en el tiempo estimado.
Un ejemplo de este tipo de gráfico se puede observar en la imagen
adjunta
Figura 11 Burn Down Chart
Observamos en el gráfico que, dentro de un sprint, el Equipo de
Desarrollo controla su desempeño basándose en días de trabajo.
En nuestro proyecto, siguiendo las prácticas que se pueden encontrar en
la mayoría de los libros y artículos sobre SCRUM, estimaremos las tareas en
horas.

51
4 Tecnologías y herramientas utilizadas en el proyecto
4.1 Cygwin
En el apartado “4.3.4 Selección de la solución” de esta memoria
decidimos el desarrollo de una herramienta en C (Ansi C) con objeto de ser
explotada en entornos Linux.
Dado que el autor del TFG también trabaja en proyectos de desarrollo
para plataformas Microsoft Windows, y que las herramientas de documentación
utilizadas son de la familia Office, vamos a tomar como plataforma habitual la
de Microsoft, pero instalando los componentes necesario que nos permitan
portar el desarrollo a Linux.
En un intento de crear un entorno UNIX/POSIX completo sobre Windows
surgió en 1995 Cygwin [22], como un proyecto de Steve Chamberlain (un
ingeniero de Cygnus). En la actualidad, el paquete está mantenido
principalmente por trabajadores de Red Hat.
Al instalar un sistema Cygwin, se obtiene [23]:
 Una biblioteca de enlace dinámico (cygwin1.dll) que implementa
la interfaz de programación de aplicaciones POSIX, usando para
ello llamadas a la API nativa de Windows.
 Una cadena de desarrollo GNU (que incluye entre otras utilidades
GCC y GDB) para facilitar las tareas básicas de programación.
 Aplicaciones equivalentes a los programas más comunes de los
sistemas UNIX. Incluso, cuenta con un sistema X (Cygwin/X)
desde 2001.
Existe otra alternativa similar a Cygwin, en concreto MinGW.
La diferencia está en que MinGW es una portabilidad a Windows de las
utilidades de compilación GNU, como son GCC, Make y Bash, pero sin
embargo no emula ni pretende aportar compatibilidad con sistemas UNIX. Es
decir, si compilamos algo usando MinGW lo estaremos haciendo para
Windows.
Sin embargo, cuando lo hacemos con Cygwin, lo haremos para el
entorno UNIX que proporcina Cygwin, y necesita la librería cygwin1.dll para
ejecutarse en Windows.

52
4.2 VMWare Player
VMWare player [24] es un sistema de virtualización por software que en
nuestro caso nos permitirá un ambiente de ejecución Linux corriendo en un
equipo con sistema operativo Windows, como si de otro hardware se tratara. Al
tratarse de una capa de software intermedia entre el hardware físico real y el
virtual, la velocidad de ejecución es evidentemente menor pero, para probar
nuestro desarrollo en un entorno Linux real, es suficiente.
Existen otras alternativas a VMWare Player, como puede ser Virtual PC.
La funcionalidad es similar pero varía en cómo se implementa. En el
caso de Virtual PC se está emulado una plataforma x86, mientras que VMWare
la virtualiza. La mayor parte de las instrucciones en VMware se ejecutan
directamente sobre el hardware físico, mientras que en el caso de Virtual PC se
traducen en llamadas al sistema operativo que se ejecuta en el sistema físico
[25].
4.3 Eclipse
Hemos seleccionado Eclipse [26] como IDE de desarrollo por ser una
herramienta muy extendida en el mundo de la programación, principalmente
para los lenguajes JAVA y C. Inicialmente creada por IBM, ahora es mantenida
y evolucionada por la Fundación Eclipse.
Ofrece gran cantidad de funcionalidades mediante la instalación de
módulos (extensión a múltiples lenguajes de programación, control de
versiones, sistemas de gestión de bases de datos, modelado de datos,
herramientas de red, etc) [27].
A favor de este IDE también ha jugado la fácil integración con el entorno
Cygwin, requerido para nuestro proyecto y con el control de versiones
Subversion por medio del módulo subversive [30].
4.4 Subversion
También reconocido por las siglas SVN [28] es una herramienta de
control de versiones Open Source basada en un repositorio cuyo
funcionamiento se asemeja enormemente al de un sistema de ficheros.
Utiliza el concepto de revisión para guardar los cambios producidos en el
repositorio. Entre dos revisiones sólo guarda el conjunto de modificaciones
(delta), optimizando así al máximo el uso de espacio en disco. SVN permite al
usuario crear, copiar y borrar carpetas con la misma flexibilidad con la que lo
haría si estuviese en su disco duro local.

53
Puede acceder al repositorio a través de redes, lo que le permite ser
usado por personas que se encuentran en distintas localizaciones [29].
La integración de Subversion (SVN) con Eclipse se realiza por medio del
plug-in desarrollado en el proyecto Subversive
GIT y CVS son alternativas a Subversion como herramienta de control
de versiones, aunque existen muchas más [31].
4.5 Python y Matplotlib
Python [32] es un lenguaje de programación interpretado y
multiplataforma. Es administrado por la Python Software Foundation y posee
una licencia de código abierto. Fue creado a finales de los ochenta por Guido
van Rossum. Se caracteriza principalmente por que hace hincapié en una
sintaxis que favorezca un código legible [33].
Matplotlib [34] es una biblioteca para la generación de gráficos a partir
de datos contenidos en listas o arrays, desarrollado en el lenguaje de
programación Python. Proporciona una API, pylab, diseñada para recordar a la
que ofrece MATLAB. Fue desarrollada por John D. Hunter en 2012. [35]
Hemos usado la combinación de Python y Matplotlib para generar los
gráficos de velas y de los indicadores técnicos en el desarrollo de nuestra
aplicación
4.6 Libconfig
Libconfig [36] es una librería simple para el procesado de ficheros de
configuración que contienen alguna estructura. El formato admitido es más
legible que un XML y, además, distingue entre tipos de datos, por lo que evita
que tengamos que realizar un análisis gramatical en nuestro código.
Ofrece interfaces tanto para C como para C++ y funciona en sistemas
UNIX compatibles con POSIX (GNU/Linux, Mac OS X, Solaris, FreeBSD) y
Windows (2000, XP, Windows 7, ….).
Observamos un ejemplo de la sintaxis en la siguiente imagen:

54
Figura 12 Fichero de ejemplo para uso con libconfig
4.7 TA-Lib
TA-Lib [37] es una librería que incluye el cálculo de 200 indicadores
(ADX, MACD, RSI, Stochastic, Bollinger Bands etc.) y que ofrece una API open
source para C/C++, Java, Perl, Python y .NET.
Constituye el núcleo encargado de los cálculos que se utilizan en
nuestra aplicación.
Una alternativa a TA-Lib es el paquete Quantmod [38] que se ofrece
para la librería R (un paquete estadístico y gráfico compatible con sistemas
UNIX, Windows y MAC OS [39]).
4.8 Kunagi
Como comentamos en el apartado “3.3.3 Seguimiento” vamos a
complementar la metodología SCRUM con los tableros propuestos por Kanban
y, para ello, nos decidimos por una herramienta accesible por Web, dado que

55
los miembros del Equipo, el Product Owner y el SCRUM Master no trabajan en
el mismo lugar. Queremos poder registrar el Product Backlog, los sucesivos
Sprint Backlogs y sus tareas asociadas.
Una búsqueda en Internet arroja bastantes resultados en lo referido a
herramienta Ágiles, incluso algunas realizan recopilaciones de las más usadas,
con comparativas en cuanto a funcionalidad y prestaciones (un ejemplo de ello
es http://agilescout.com/best-agile-scrum-tools [40]).
Revisando varias de estas recopilaciones y siempre buscando ediciones
freeware, seleccionamos, en base a las opiniones de usuarios, tres de ellas:
Sprintometer, Scrinch y Kunagi.
De entre ellas, la más intuitiva y con menos requerimientos de hardware
es Kunagi [41]. Contempla todos los aspectos de SCRUM y gráficamente es
sencilla, muy parecida a los tableros que recomienda Javier Garzás en su libro.
Es fácilmente desplegable (por medio de un archivo war) compatible con
Apache Tomcat [42] (un contenedor web de servlets open source que
implementa las especificaciones de los Java Servlets y de Java server Pages).
Apache Tomcat está desarrollado en Java, lo que facilita su portabilidad a
múltiples entornos. En nuestro caso lo hemos instalado en nuestro ordenador
de desarrollo en Microsoft Windows.
No requiere ninguna base de datos para almacenar información. Por el
contrario, usa ficheros XML que se almacenan en el directorio de la aplicación
del servidor donde se ejecuta Apache Tomcat.

57
5 Estimación de recursos y planificación
Como hemos indicado en el capítulo “5.3 Metodología elegida”, en este
proyecto no conocemos de antemano los detalles exactos del producto final,
por lo que hemos apostado por emplear la metodología SCRUM, que nos
permita tener el cliente vinculado al proyecto, entregándole regularmente
versiones del producto para que pueda ver a corto plazo el fruto de su inversión
y afine sus requerimientos, haciéndole partícipe del desarrollo y creando una
relación de confianza con el equipo.
Según Roman Pichler [2], una planificación conlleva una decisión
acerca de qué factores no deberían verse comprometidos de cara al
lanzamiento de un producto de éxito, lo cual nos lleva a hacernos una serie de
preguntas:
 Tiempo: ¿es necesario respetar una fecha de lanzamiento o
finalización?
 Coste: ¿hay un presupuesto fijo para el desarrollo del producto?
 Funcionalidad: ¿deben desarrollarse todos los requerimientos que
figuran en la Pila de Producto?
Las tres restricciones no pueden satisfacerse de manera conjunta (al
menos una de ellas debe quedar libre como válvula de escape).
Fijar la funcionalidad no es una buena idea y, además, va en contra de
los principios de la metodología Ágil, donde esperamos evolucionar el producto
en base a las indicaciones del cliente.
Sin embargo, fijar la fecha de entrega de las diferentes versiones lleva a
una disciplina en el equipo de desarrollo, una mentalidad de producir resultados
periódicamente. Además, de esta manera, si el equipo de desarrollo es estable,
la elaboración del presupuesto es sencilla pues se reduce al cálculo: Nº de
desarrolladores x tiempo.
Flexibilizando el requisito de la funcionalidad permitimos que, en caso de
que el presupuesto se vea comprometido, el Propietario del Producto pueda
aceptar liberar un producto tras una reducción en las prestaciones.
5.1 Método de estimación utilizado
En SCRUM las tareas se estiman en Puntos Historia o Story Points (SP
a partir de ahora), que son una medida “relativa” del esfuerzo que es necesario
aplicar para desarrollar una Historia de Usuario. Cuando decimos “relativa”

58
estamos reflejando que una tarea etiquetada como 2SP conlleva el doble de
esfuerzo que otra etiquetada como 1SP.
Según Garzás [21], “un punto historia es una fusión entre la cantidad de
esfuerzo que supone desarrollar la historia de usuario, la complejidad de su
desarrollo y el riesgo inherente”. Al ser una medida relativa permite adaptarse
al equipo y nos deja libertad a la hora de asignar valores. Dado que debemos
usar rangos acotados, fijando un tope máximo, nos decantamos por la
siguiente serie: 1, 2, 3 ,5, 8, 13.
A la hora de calcular la duración del proyecto, sólo los Puntos Historia no
son suficientes, sino que necesitamos saber con qué rapidez el equipo es
capaz de desarrollar las Historias de Usuario. A este concepto se la denomina
Velocidad, que se calcula sumando el número de Puntos Historia de cada
Historia de Usuario “terminada” durante un Sprint. Dado que el Dueño del
Producto no consigue valor de las Historias de Usuario no acabadas, se
excluyen del cálculo todas aquéllas parcialmente desarrolladas.
Según Kenneth S. Rubin [3], “la velocidad mide el output (el tamaño de
lo que se entrega), no el outcome (el valor de lo que se entrega)”. Es decir,
completar una Historia de Usuario de 8SP no significa necesariamente que
aporte más valor al cliente que una de 5SP. Quizás interese trabajar más en la
de 5SP porque aporta más valor y es menos costosa.
La velocidad se suele mantener durante todo el proyecto, ya que es
inherente a la naturaleza de nuestro equipo y es conocida por proyectos
anteriores, o por sprints anteriores dentro del mismo proyecto. En nuestro caso,
esta información no está disponible y debemos realizar una estimación
adoptando alguna asunciones:
 Nuestro equipo de desarrollo está compuesto por una persona
 La jornada de trabajo dedicada al proyecto es 3 Horas/Día
 El factor de disponibilidad será del 80% de esas 3 horas, donde el
20% restante lo dejamos como colchón para mejoras técnicas
que no aportan aparentemente valor al cliente, o bien para
imprevistos
 Consideramos como punto de partida en nuestros cálculos que,
basándonos en nuestra experiencia, una Historia de Usuario de
1SP necesita una media de 3 horas para su desarrollo y prueba

59
Garzás [21] recomienda no considerar más de ese 80% de
disponibilidad.
Teniendo en cuenta que el Equipo de Desarrollo se compone de una
sola persona, con una dedicación de 3 horas al día durante 6 días a la semana,
durante 4 semanas, el número de horas de desarrollo es de 3 * 6 * 4 = 72 que,
aplicando un factor de disponibilidad del 80% nos deja el valor real de 58 horas
en cada iteración.
Por tanto la velocidad estimada será de 58 horas / 3 Horas por SP = 19
SP en cada Sprint.
5.2 Planificación
Sabemos que SCRUM trabaja en iteraciones o ciclos de, como máximo,
un mes de duración, llamados sprints, que presentan como características más
relevantes:
 Tienen una fecha de inicio y de fin
 Deben ser de corta duración (entre una semana y un mes)
 Preferiblemente todos los Sprints deben tener la misma duración
 El objetivo a cubrir durante cada ciclo no puede ser alterado y
debe ser completado al llegar el fin del Sprint
Según Kenneth S. Rubin [3], las ventajas de tener en mente una fecha
de fin son que:
 Permite limitar el trabajo en curso (no terminado) porque el equipo
planificará sólo aquello que sabe que puede entregar en el Sprint
 Fuerza la priorización y el llevar a cabo pequeños trabajos,
focalizándose en lo que aporta valor rápidamente al cliente
 Muestra avances entregando nuevas versiones al fin de cada
ciclo
 Evita perfeccionismos innecesarios, evitando perder tiempo
buscando algo “perfecto” cuando “suficientemente bueno” podría
valer
 Motiva la conclusión de las tareas ya que los equipos tienen en
mente una fecha límite conocida

60
 Mejora las predicciones sobre lo que se puede entregar porque es
razonable pensar que será parecido a lo entregado en el sprint
anterior
Por otro lado, una duración corta:
 Facilita la planificación
 Ofrece retroalimentación frecuente sobre el trabajo ya realizado y
en curso
 Mejora el retorno de la inversión en el desarrollo al tener, al final
de cada sprint, una release
 Limita la propagación de los posibles errores
 Mantiene al equipo activo (en oposición a los proyecto de larga
duración, donde se pierde entusiasmo por el esfuerzo empleado)
Siguiendo esta indicaciones, nosotros nos decantamos por sprints de
cuatro semanas, que se alinean muy bien con la disponibilidad tanto del
Propietario del Producto, del SCRUM Master y del equipo de desarrollo.
En nuestra reunión inicial con el cliente queremos proponerle y acordar
una estimación de tiempos, en este caso, el número de sprints y, para ello,
basándonos en el documento de requerimientos proporcionados por la
empresa, se han podido identificar las siguientes Historias de Usuario:
 STO001: Como cliente quiero poder leer un archivo con datos
históricos en formato csv para calcular sobre ellos indicadores
técnicos
 STO002: Como cliente quiero que el software detecte el intervalo
de tiempos del archivo de datos para poder generar gráficos
intradía / interdía
 STO003: Como cliente quiero que el software pueda manejar
grandes cantidades de datos para poder leer series históricas
 STO004: Como cliente quiero poder leer uno o más archivos de
configuración para poder lanzar ejecuciones desatendidas
 STO005: Como cliente quiero disponer de una lista de
indicadores técnicos disponibles, que sea ampliable para poder
utilizarla a la hora de declarar los escenarios

61
 STO006: Como cliente quiero poder indicar rangos o listas de
parámetros de los indicadores para poder lanzar simulaciones
masivas
 STO007: Como cliente quiero poder incluir constantes en los
ficheros de configuración de los escenarios para simplificar la
lectura de los mismos
 STO008: Como cliente quiero poder escribir fórmulas o reglas en
formato matemático para que el software pueda interpretarlas
para dar versatilidad
 STO009: Como cliente quiero poder indicar las fórmulas de
decisión en los archivos de configuración para poder generar
diferentes escenarios
 STO010: Como cliente quiero poder generar un gráfico con
información diaria a partir de un archivo CSV (desde script) para
disponer de una herramienta visual de análisis
 STO011: Como cliente quiero que los gráficos se puedan generar
dinámicamente en función a parámetros (estudiar solución
técnica) para decidir si se usan ficheros de configuración de
gráficos
 STO012: Como cliente quiero que cada gráfico que se genere
lleve asociado un fichero csv con la información representada
para poder ser tratada con otras herramientas analíticas
 STO013: Como cliente quiero que los gráficos puedan contener
varias ventanas, y se puedan asociar variables a cada ventana,
con tipos y colores parametrizables y que se pueda definir el
tamaño de la imagen resultante para ofrecer de esta manera
mayor versatilidad
 STO014: Como cliente quiero indicar al software que me genere
gráficos siempre, nunca o en los n casos más favorables para no
sobrecargar en el caso de ejecución de escenarios masivos
 STO015: Como cliente quiero poder mostrar en el gráfico las
operaciones de entrada/salida del mercado para permitir un
análisis visual
 STO016: Como cliente quiero guardar en una matriz el resultado
de la ejecución de todos los escenarios para poder realizar
estudios posteriores

62
 STO017: Como cliente quiero que el software ordene los
escenarios según uno o más ratios calculados tras su ejecución
para conocer las reglas de mercado más ventajosas
 STO018: Como cliente quiero que, además de decidir entradas /
salidas del mercado en base a unas fórmulas, también contemple
Stop Loss y Take Profit para asimilarlo a las operaciones reales
del mercado
 STO019: Como cliente quiero disponer de un LOG en un archivo
de texto indicando tiempos de ejecución para conocer el
rendimiento de la librería de indicadores técnicos usada y del
software en general
Ahora bien, ¿cómo calculamos el tamaño de cada historia en esta fase
inicial para poder presentar a la empresa un plan de proyecto? En realidad sólo
podemos hacerlo basarnos en estimaciones, seleccionando de la lista de
Historias de Usuario aquéllas con las que nos sintamos más confiados a la
hora de valorar su duración en Puntos de Historia y, haciendo uso de la
naturaleza relativa de este indicador, ponderando a continuación el resto.
Así, basándonos en nuestra experiencia como desarrolladores, sabemos
que STO001 (lectura de un fichero con cierto formato) no es una tarea
compleja y podríamos asignarle una duración de 1SP. Asimismo la ST008, que
supone el desarrollo de un analizador sintáctico (o parser), sin duda es una
tarea más compleja que la anterior, tanto en el desarrollo como en la fase de
pruebas, y creemos que debemos asignarle una duración de 5SP.
Mostramos a continuación una tabla donde hemos reflejado todas las
Historias de Usuario identificadas hasta la fecha y una estimación de
duración/complejidad en Puntos Historia tomando como referencia las
anteriores.
La columna nombrada como “Justificación” explica el razonamiento
seguido para asignar los Puntos de Historia a cada caso:

63
Tabla 4 Historias de usuario identificadas al inicio del proyecto
Historias de
Usuario
(STO)
Puntos de
Historia
(SP)
Justificación
STO001
Como cliente quiero poder leer un archivo con datos históricos en
formato csv para calcular sobre ellos indicadores técnicos
1 Tomada como base para el resto de estimaciones
STO002
Como cliente quiero que el software detecte el intervalo de tiempos
del archivo de datos para poder generar gráficos intradía/interdía
1
Serán cálculos sobre el campo de fecha extraído del
archivo de entrada
STO003
Como cliente quiero que el software pueda manejar grandes
cantidades de datos para poder leer series históricas
8
Esta tarea supone el diseño de la arquitectura y
gestión de la memoria que almacenará los datos
STO004
Como cliente quiero poder leer uno o más archivos de configuración
para poder lanzar ejecuciones desatendidas
13
En esta fase inicial debemos decidir si desarrollar
código para leer archivos con sintaxis a definir o
buscar soluciones en el mercado
STO005
Como cliente quiero disponer de una lista de indicadores técnicos
disponibles, que sea ampliable para poder utilizarla al declarar los
1 Usaremos un nuevo fichero de configuración
STO006
Como cliente quiero poder indicar rangos o listas de parámetros de
los indicadores para poder lanzar simulaciones masivas
5
El uso de rango y/o bucles aparentemente nos va a
llevar a elaborar algún proceso de llamada recursiva
STO007
Como cliente quiero poder incluir constantes en los ficheros de
configuración de los escenarios para simplificar la lectura de los
1 Duración parecida a la STO005
STO008
Como cliente quiero poder escribir fórmulas o reglas en formato
matemático y que el software pueda interpretarlas para dar
versatilidad
5
Tomada como base para el resto de estimaciones.
Compleja.
STO009
Como cliente quiero poder indicar las fórmulas de decisión en los
archivos de configuración para poder generar diferentes escenarios
1 Duración estimada parecida a la STO005
STO010
Como cliente quiero poder generar un gráfico con información diaria a
partir de un archivo csv (desde script)
8
En esta fase inicial sabemos la herramienta que
utilizaremos pero no tenemos el conocimiento sobre
su uso y debemos tener en cuenta el trabajo de
investigación
STO011
Como cliente quiero que los gráficos se puedan generar
dinámicamente en función a parámetros (estudiar solución técnica)
para decidir si se usan ficheros de configuración de gráficos
13
Supone la lectura del archivo de configuración, su
interpretación y la generación de sentencias que
generen el gráfico
STO012
Como cliente quiero que cada gráfico que se genere lleve asociado un
fichero csv con la información representada para tratamientos en
otras herramientas
1 Similar en duración a la STO001
STO013
Como cliente quiero que los gráficos puedan contener varias ventanas,
y se puedan asociar variables a cada ventana, con tipos y colores
parametrizables y que se pueda definir el tamaño en pixels para
ofrecer mayor versatilidad
8 Similar en duración a la STO011
STO014
Como cliente quiero indicar al software que me genere gráficos
siempre, nunca o en los n casos más favorables para no sobrecargar en
el caso de escenarios masivos
5
Habrá que generar un módulo específico para gráficos.
La complejidad vendrá dada por la necesidad de
almacenar todos los parámetros usados en cada
escenario para reutilizarlos a la hora de graficar los
mejores
STO015
Como cliente quiero poder mostrar en el gráfico las operaciones de
entrada/salida del mercado para permitir un análisis visual
3 Similar a la STO013
STO016
Como cliente quiero guardar en una matriz el resultado de la ejecución
de todos los escenarios para poder realizar estudios posteriores
5
Almacenar los valores no es en sí complejo pero sí el
trabajo posterior sobre ellos
STO017
Como cliente quiero que el software ordene los escenarios según uno
o más ratios calculados tras la ejecución para conocer las reglas más
ventajosas
5 Trabajo sobre cálculos de ratios
STO018
Como cliente quiero que, además de decidir entradas / salidas del
mercado en base a unas fórmulas, también contemple StopLoss y
TakeProfit para asimilarlo a las operaciones reales
13
A tener en cuenta junto a las reglas de entrada / salida
del mercado que se guiarán en base a las fórmulas
almacenadas en los archivos de los scripts
STO019
Como cliente quiero disponer de un LOG de ejecución indicando
tiempos para conocer el rendimiento de la librería de indicadores
técnicos usada
5
Desde cualquier punto del programa puede ser
necesario enviar mensajes al fichero LOG
(especialmente en caso de errores)
La suma de todos los SP arroja un total de 102 Puntos de Historia para
el desarrollo completo del proyecto que, convertido a horas por el factor
convenido en el apartado 7.1 de 1SP = 3 horas, nos da un valor de 306 horas
de trabajo del equipo de desarrollo.
Por tanto, ya estamos en disposición de estimar la duración del proyecto
en número de Sprints pues conocemos los Puntos de Historia totales y la
velocidad del equipo calculada al final del apartado 5.1:

64
102 SP / 19SP por Sprint = 5,4 ciclos, por lo que decidimos informar al
cliente de que vamos a trabajar durante 6 Sprints, con un margen de error
equivalente a 0,6 ciclos para imprevistos o nuevas Historias de Usuario que
pudieran ir surgiendo a lo largo del proyecto en la reuniones de revisión y
planificación de los sprints.
En la naturaleza de SCRUM está el hecho de revisar, al final de cada
Sprint, las desviaciones de la velocidad estimada frente a la real. Para ello
utilizaremos el gráfico del Sprint Burndown, que nos mostrará las tareas
estimadas durante el sprint y las desviaciones. La velocidad real en cada Sprint
se tomará como nueva velocidad del equipo para los siguientes Sprints y será
un factor decisivo a la hora de seleccionar Historias de Usuario para cada
nuevo Sprint cuando confeccionemos el Sprint Backlog.
5.3 Valoración de la dedicación y coste económico
En nuestro cálculos del coste económico del proyecto vamos a
considerar dos grupos:
 Costes de material, donde reflejaremos el coste del material
empleado durante la realización del proyecto
 Costes de consultoría, donde reflejaremos el coste de personal
basado en horas de trabajo
5.3.1 Costes de material
Incluiremos todos los costes de hardware y software empleados, que
son independientes de la duración del proyecto. Estos costes no se aplicarán al
cliente dado que esta misma infraestructura es utilizada para proyectos con
otros clientes.
La siguiente tabla identifica los distintos elementos considerados:

65
Tabla 5 Costes de material no facturables
Hardware Euros
Ordenador portátil Lenovo T420 800
Monitor Lenovo 24'' 350
Impresora HP Deskjet H450 60
HDD externo para copias de seguridad 60
Periféricos 50
1.320
Software Euros
Licencia Windows 7 Professional SP1 149
Licencia Microsoft Office 2010 Profesional (MS Word y MSExcel) 393
Virtual Machines Player (VMWare) 0
Linux (Ubuntu) 0
Entorno de desarrollo (Eclipse) 0
Entorno Linux para Windows (CygWin) 0
542
5.3.2 Costes de consultoría
Como indicamos en el capítulo 5 (metodología), en SCRUM
identificamos 3 roles: el SCRUM Mater, El Propietario del Producto y el Equipo
de Desarrollo.
Los roles de SCRUM Master y Propietario del Producto no implican una
dedicación completa al proyecto sino que requiere su intervención durante
momentos clave bien definidos dentro del proceso de SCRUM. Sin embargo, el
coste de los miembros del Equipo de Desarrollo asignados a este proyecto se
aplicará íntegramente al mismo.
De cara a negociar con un cliente el coste de un proyecto desarrollado
siguiendo la metodología SCRUM podemos ofrecer facturar cada Sprint
basándonos en los Puntos de Historia completados y aceptados. De esta
manera estamos creando una relación con el cliente en la que se asegura de
pagar únicamente por las funcionalidades que recibe y que previamente se han
solicitado y acordado al principio de cada sprint.
Usaremos el factor de conversión “1 Punto de Historia” = “3 Horas de
desarrollo”, sobre un coste de horas de consultoría de 30 Euros/Hora.
Según este criterio, y basándonos en la estimación inicial de 102 Puntos
de Historia, podremos informar al cliente de un coste del proyecto aproximado
de 7.500 Euros.

66
Tabla 6 Estimación de costes iniciales facturables al cliente
Puntos de
Historia
Horas de
desarrollo Euros
Sprint 1 19 57 1.710
Sprint 2 19 57 1.710
Sprint 3 19 57 1.710
Sprint 4 19 57 1.710
Sprint 5 19 57 1.710
Sprint 6 7 21 630
102 306 7.470
Consultoría
Como hemos comentado, la facturación real de cada Sprint se adaptará
a lo realmente entregado, e incluirá los impuestos aplicables en cada momento.
Si se decidiera un incremento en la funcionalidad que conllevara nuevos
Sprints o nuevos Puntos de Historia, se seguiría el mismo criterio a la hora de
facturarlo (así quedará reflejado en el contrato entre ambas partes).

67
6 Desarrollo del proyecto
6.1 Preparativos
Existe una gran controversia sobre cómo incluir en la metodología
SCRUM las tareas técnicas y no técnicas previas al inicio del desarrollo y, por
tanto, a la entrega de alguna funcionalidad al cliente.
Podríamos incluir en este grupo las siguientes:
 preparar los entornos de desarrollo.
 trabajar en el Product Backlog, principalmente en dejar listas las
historias de usuario, priorizadas y estimadas.
 Hacer una previsión del reparto de historias de usuario por
iteración.
 Hacer un estudio de la arquitectura.
 Alcanzar un acuerdo sobre la definición de “Done”, es decir, de
cuándo una Historia de Usuario está acabada y aceptada
Existen tres corrientes que ofrecen diferentes soluciones:
1. Una corriente aboga por la existencia de un sprint 0, a pesar de
que no desarrolle ninguna Historia de Usuario, pero respetando la
naturaleza de SCRUM (asignándole una duración fija, realizando
SCRUM diarios y la Revisión del Sprint).
2. Otra corriente, contraria a la anterior, opina que un sprint de este
tipo presenta los siguientes inconvenientes:
 No genera código funcional
 Elimina el sentido de urgencia
 Conduce a malentendidos sobre cómo funciona SCRUM
 Disgusta al cliente
y aboga por evitar denominar como sprint a esta fase porque
considera que, si lo llamáramos así, estaríamos ejecutando SCRUM,
pero eso sería incompatible con los citados cuatro inconvenientes.
3. La tercera vía es incluirlas como tareas técnicas en el sprint 1,
junto a otras que sí aporten valor al cliente. De esta manera, en la
revisión del sprint, el Product Owner puede obtener una primera

68
versión entregable del software, aunque con funcionalidades
reducidas.
En este proyecto preferimos ceñirnos completamente a la metodología
SCRUM y, de acuerdo con el cliente, no comenzar el proyecto en su fase de
desarrollo hasta no estar en disposición de generar valor.
Por tanto, durante las primeras semanas, mantuvimos dos reuniones
para conocer los requerimientos del cliente, traducirlos a Historias de Usuario,
decidir la arquitectura e instalar los entornos de desarrollo y pruebas
necesarios.
Tabla 7 Fase inicial: Objetivos del cliente
OG1 Objetivo General 1: Desarrollo de una aplicación eficiente
OE1
Objetivos Específico 1: Desarrollo de un programa scriptable, mediante archivos de configuración,
para el funcionamiento en supercomputadoras
OE2 Objetivos Específico 2: Lenguaje de programación eficiente en términos de velocidad y memoria
OG2 Objetivo General 2: Desarrollo de una herramienta de análisis visual de operaciones en los mercados
OE3 Objetivos Específico 3: Lectura de datos históricos
OE4 Objetivos Específico 4: Representación gráfica de datos históricos e indicadores técnicos
OG3 Objetivo General 3: Desarrollo de una herramienta de backtesting
OE5 Objetivo Específico 5: Cálculo de indicadores técnicos sobre un conjunto de datos históricos
OE6
Objetivo Específico 6: Decisión acerca del momento de realizar una operación en el mercado y de
finalizar la misma
OE7
Objetivo Específico 7: Calcular el beneficio neto del conjunto de operaciones que se produzcan en
el periodo de tiempo que se ha extraído de los históricos
OE8 Objetivo Específico 8: Elaborar un informe con datos estadísticos sobre las operaciones realizadas
Tabla 8 Fase inicial. Traducción a Historias de Usuario
Historias de
Usuario
(STO)
Puntos
de
Historia
(SP)
STO001 Como cliente quiero poder leer un archivo con datos históricos en
formato CSV para calcular sobre ellos indicadores técnicos
1
STO002 Como cliente quiero que el software detecte el intervalo de tiempos
del archivo de datos para poder generar gráficos intradía/interdía
1
STO003 Como cliente quiero que el software pueda manejar grandes
cantidades de datos para poder leer series históricas
8
STO004 Como cliente quiero poder leer uno o más archivos de configuración
para poder lanzar ejecuciones desatendidas
13

69
STO005 Como cliente quiero disponer de una lista de indicadores técnicos
disponibles, que sea ampliable para poder utilizarla al declarar los
escenarios
1
STO006 Como cliente quiero poder indicar rangos o listas de parámetros de los
indicadores para poder lanzar simulaciones masivas
5
STO007 Como cliente quiero poder incluir constantes en los ficheros de
configuración de los escenarios para simplificar la lectura de los
mismos
1
STO008 Como cliente quiero poder escribir fórmulas o reglas en formato
matemático y que el software pueda interpretarlas para dar
versatilidad
5
STO009 Como cliente quiero poder indicar las fórmulas de decisión en los
archivos de configuración para poder generar diferentes escenarios
1
STO010 Como cliente quiero poder generar un gráfico con información diaria a
partir de un archivo CSV (desde script)
8
STO011 Como cliente quiero que los gráficos se puedan generar
dinámicamente en función a parámetros (estudiar solución técnica)
para decidir si se usan ficheros de configuración de gráficos
13
STO012 Como cliente quiero que cada gráfico que se genere lleve asociado un
fichero CSV con la información representada para tratamientos en
otras herramientas
1
STO013 Como cliente quiero que los gráficos puedan contener varias ventanas,
y se puedan asociar variables a cada ventana, con tipos y colores
parametrizables y que se pueda definir el tamaño en pixels para
ofrecer mayor versatilidad
8
STO014 Como cliente quiero indicar al software que me genere gráficos
siempre, nunca o en los n casos más favorables para no sobrecargar en
el caso de escenarios masivos
5
STO015 Como cliente quiero poder mostrar en el gráfico las operaciones de
entrada/salida del mercado para permitir un análisis visual
3
STO016 Como cliente quiero guardar en una matriz el resultado de la ejecución
de todos los escenarios para poder realizar estudios posteriores
5
STO017 Como cliente quiero que el software ordene los escenarios según uno o
más ratios calculados tras la ejecución para conocer las reglas más
ventajosas
5
STO018 Como cliente quiero que, además de decidir entradas / salidas del
mercado en base a unas fórmulas, también contemple StopLoss y
TakeProfit para asimilarlo a las operaciones reales
13
STO019 Como cliente quiero disponer de un LOG de ejecución indicando
tiempos para conocer el rendimiento de la librería de indicadores
técnicos usada
5
Por último, y no menos importante, también acordamos entre el Product
Owner y el el Equipo de Desarrollo que, en cada Historia de Usuario,
incluiremos un campo que especifique la definición de “Terminado” en modo de
criterios de aceptación, porque nos resulta difícil encontrar una definición
aplicable a todas en conjunto.

70
En este punto ya teníamos toda la información necesaria para plantear
al cliente los costes estimados del proyecto, el número de sprints y, por tanto,
una primera estimación de duración del proyecto. Los costes de esta fase de
análisis no se trasladaron al cliente.
También inicializamos en Kunagi el proyecto Trading, creando los
usuarios y asignando los roles a cada miembro del equipo:
Asimismo, dimos de alta las Historias de Usuario con su estimación en
Puntos de Historia y la velocidad estimada del Equipo de Desarrollo (Kunagi
realiza con toda esa información una estimación de fechas de entrega):
Figura 13 Trading en Kunagi: Roles

71
Figura 14 Trading en Kunagi: Historias de Usuario
Ya estábamos preparados para el Sprint 1.
6.2 Sprint 1
6.2.1 Sprint Planning
En la reunión de planificación de este primer sprint, el Product Owner ha
seleccionado dos Historias de Usuario estimadas en un total de 14 Puntos de
Historia.

72

 STO001: Como cliente quiero poder leer un archivo con datos
históricos en formato csv para calcular sobre ellos indicadores
técnicos
 STO004: Como cliente quiero poder leer uno o más archivos de
configuración para poder lanzar ejecuciones desatendidas
Una aclaración: la velocidad del equipo calculada en el aparatado “5.1
Método de estimación utilizado” era de 19 SP, que supera en 5 SP a la suma
de la duración estimada de las dos historias seleccionadas. Podríamos haber
incluido otra Historia de Usuario más pero, para el cliente, la siguiente en
prioridad tiene una duración de 8 SP, lo cual superaría la capacidad de trabajo
del equipo. Una opción podría haber sido fragmentar la tercera historia en dos
partes, una de las cuales hubiera entrado en este sprint. Pero en este primer
ciclo optamos por ser conservadores y no incluir nada. En el Sprint Review
podremos ajustar este dato.
Figura 15 Sprint 1 Backlog

Defensa TFG predicción y optimización en sistemas de trading automáticos para mercados financieros

Defensa TFG predicción y optimización en sistemas de trading automáticos para mercados financieros

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a Defensa TFG predicción y optimización en sistemas de trading automáticos para mercados financieros

Similar a Defensa TFG predicción y optimización en sistemas de trading automáticos para mercados financieros (20)

Último

Último (20)

Defensa TFG predicción y optimización en sistemas de trading automáticos para mercados financieros